Recherche avancée

Sur d’autres sites (4978)

• cpu.c:253 : x264_cpu_detect : Assertion

  12 octobre 2017, par user6341251

  environment :
  ubuntu 16.04_x64 server
  install ffmpeg through apt-get install
  python 3
  

  when I try

  from moviepy.editor import *
clip = VideoFileClip("/root/video.mp4")
clip.ipython_display(width=280)

  Traceback (most recent call last) :
  File "", line 1, in
  File "/usr/local/lib/python2.7/dist-packages/moviepy/video/io/html_tools.py", line 219, in ipython_display
  center=center, rd_kwargs=rd_kwargs, **html_kwargs))
  File "/usr/local/lib/python2.7/dist-packages/moviepy/video/io/html_tools.py", line 97, in html_embed
  clip.write_videofile(**kwargs)
  File "", line 2, in write_videofile
  File "/usr/local/lib/python2.7/dist-packages/moviepy/decorators.py", line 54, in requires_duration
  return f(clip, *a, **k)
  File "", line 2, in write_videofile
  File "/usr/local/lib/python2.7/dist-packages/moviepy/decorators.py", line 137, in use_clip_fps_by_default
  return f(clip, *new_a, **new_kw)
  File "", line 2, in write_videofile
  File "/usr/local/lib/python2.7/dist-packages/moviepy/decorators.py", line 22, in convert_masks_to_RGB
  return f(clip, *a, **k)
  File "/usr/local/lib/python2.7/dist-packages/moviepy/video/VideoClip.py", line 349, in write_videofile
  progress_bar=progress_bar)
  File "/usr/local/lib/python2.7/dist-packages/moviepy/video/io/ffmpeg_writer.py", line 216, in ffmpeg_write_video
  writer.write_frame(frame)
  File "/usr/local/lib/python2.7/dist-packages/moviepy/video/io/ffmpeg_writer.py", line 178, in write_frame
  raise IOError(error)
  IOError : [Errno 32] Broken pipe

  MoviePy error : FFMPEG encountered the following error while writing file temp.mp4 :

  ffmpeg : common/cpu.c:253 : x264_cpu_detect : Assertion ` !(cpu&(0x0000040|0x0000080))’ failed.

  what happend ?

  ---

  @Ronald S. Bultje
  

  I am using a virtual machine

  processor : 0
  vendor_id : GenuineIntel
  cpu family : 6
  model : 13
  model name : QEMU Virtual CPU version (cpu64-rhel6)
  stepping : 3
  microcode : 0x1
  cpu MHz : 3504.000
  cache size : 4096 KB
  physical id : 0
  siblings : 1
  core id : 0
  cpu cores : 1
  apicid : 0
  initial apicid : 0
  fpu : yes
  fpu_exception : yes
  cpuid level : 13
  wp : yes
  flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm fsgsbase bmi1 avx2 smep bmi2 xsaveopt
  bugs :
  bogomips : 7008.00
  clflush size : 64
  cache_alignment : 64
  address sizes : 39 bits physical, 48 bits virtual
  power management :
  

• swresample/resample : speed up build_filter by 50%

  4 novembre 2015, par Ganesh Ajjanagadde

  swresample/resample : speed up build_filter by 50%
  This speeds up build_filter by 50%. This gain should be pretty
  
  consistent across all architectures and platforms.
  Essentially, this relies on a observation that the filters have some
  
  even/odd symmetry that may be exploited during the construction of the
  
  polyphase filter bank. In particular, phases (scaled to [0, 1]) in [0.5, 1] are
  
  easily derived from [0, 0.5] and expensive reevaluation of function
  
  points are unnecessary. This requires some rather annoying even/odd
  
  bookkeeping as can be seen from the patch.
  I vaguely recall from signal processing theory more general symmetries allowing even greater
  
  optimization of the construction. At a high level, "even functions"
  
  correspond to 2, and one can imagine variations. Nevertheless, for the sake
  
  of some generality and because of existing filters, this is all that is
  
  being exploited.
  Currently, this patch relies on phase_count being even or (trivially) 1,
  
  though this is not an inherent limitation to the approach. This
  
  assumption is safe as phase_count is 1 << phase_bits, and is hence a
  
  power of two. There is no way for user API to set it to a nontrivial odd
  
  number. This assumption has been placed as an assert in the code.
  To repeat, this assumes even symmetry of the filters, which is the most common
  
  way to get generalized linear phase anyway and is true of all currently
  
  supported filters.
  As a side note, accuracy should be identical or perhaps slightly better
  
  due to this "forcing" filter symmetries leading to a better phase
  
  characteristic. As before, I can’t test this claim easily, though it may
  
  be of interest.
  Patch tested with FATE.
  Sample benchmark (x86-64, Haswell, GNU/Linux) :
  test : swr-resample-dblp-44100-2626
  new :
  
  527376779 decicycles in build_filter(loop 1000),     256 runs,      0 skips
  
  524361765 decicycles in build_filter(loop 1000),     512 runs,      0 skips
  
  516552574 decicycles in build_filter(loop 1000),    1024 runs,      0 skips
  old :
  
  974178658 decicycles in build_filter(loop 1000),     256 runs,      0 skips
  
  972794408 decicycles in build_filter(loop 1000),     512 runs,      0 skips
  
  954350046 decicycles in build_filter(loop 1000),    1024 runs,      0 skips
  Note that lower level optimizations are entirely possible, I focussed on
  
  getting the high level semantics correct. In any case, this should
  
  provide a good foundation.
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libswresample/resample.c

• Revision 35733 : ne pas passer par la fonction d’ajout lorsqu’on supprime un tag sinon le ...

  2 mars 2010, par brunobergot@… — Log

  ne pas passer par la fonction d’ajout lorsqu’on supprime un tag sinon le message de retour et l’invalideur ne sont pas pris en compte