Recherche avancée

Sur d’autres sites (4307)

• arm : Add NEON optimizations for 10 and 12 bit vp9 MC

  8 décembre 2016, par Martin Storsjö

  arm : Add NEON optimizations for 10 and 12 bit vp9 MC
  This work is sponsored by, and copyright, Google.
  The plain pixel put/copy functions are used from the 8 bit version,
  
  for the double size (e.g. put16 uses ff_vp9_copy32_neon), and a new
  
  copy128 is added.
  Compared with the 8 bit version, the filters can no longer use the
  
  trick to accumulate in 16 bit with only saturation at the end, but now
  
  the accumulators need to be 32 bit. This avoids the need to keep track
  
  of which filter index is the largest though, reducing the size of the
  
  executable code for these filters.
  For the horizontal filters, we only do 4 or 8 pixels wide in parallel
  
  (while doing two rows at a time), since we don’t have enough register
  
  space to filter 16 pixels wide.
  For the vertical filters, we still do 4 and 8 pixels in parallel just
  
  as in the 8 bit case, but we need to store the output after every 2
  
  rows instead of after every 4 rows.
  Examples of relative speedup compared to the C version, from checkasm :
  
                                 Cortex    A7     A8     A9    A53
  
  vp9_avg4_10bpp_neon :                   2.25   2.44   3.05   2.16
  
  vp9_avg8_10bpp_neon :                   3.66   8.48   3.86   3.50
  
  vp9_avg16_10bpp_neon :                  3.39   8.26   3.37   2.72
  
  vp9_avg32_10bpp_neon :                  4.03  10.20   4.07   3.42
  
  vp9_avg64_10bpp_neon :                  4.15  10.01   4.13   3.70
  
  vp9_avg_8tap_smooth_4h_10bpp_neon :     3.38   6.22   3.41   4.75
  
  vp9_avg_8tap_smooth_4hv_10bpp_neon :    3.89   6.39   4.30   5.32
  
  vp9_avg_8tap_smooth_4v_10bpp_neon :     5.32   9.73   6.34   7.31
  
  vp9_avg_8tap_smooth_8h_10bpp_neon :     4.45   9.40   4.68   6.87
  
  vp9_avg_8tap_smooth_8hv_10bpp_neon :    4.64   8.91   5.44   6.47
  
  vp9_avg_8tap_smooth_8v_10bpp_neon :     6.44  13.42   8.68   8.79
  
  vp9_avg_8tap_smooth_64h_10bpp_neon :    4.66   9.02   4.84   7.71
  
  vp9_avg_8tap_smooth_64hv_10bpp_neon :   4.61   9.14   4.92   7.10
  
  vp9_avg_8tap_smooth_64v_10bpp_neon :    6.90  14.13   9.57  10.41
  
  vp9_put4_10bpp_neon :                   1.33   1.46   2.09   1.33
  
  vp9_put8_10bpp_neon :                   1.57   3.42   1.83   1.84
  
  vp9_put16_10bpp_neon :                  1.55   4.78   2.17   1.89
  
  vp9_put32_10bpp_neon :                  2.06   5.35   2.14   2.30
  
  vp9_put64_10bpp_neon :                  3.00   2.41   1.95   1.66
  
  vp9_put_8tap_smooth_4h_10bpp_neon :     3.19   5.81   3.31   4.63
  
  vp9_put_8tap_smooth_4hv_10bpp_neon :    3.86   6.22   4.32   5.21
  
  vp9_put_8tap_smooth_4v_10bpp_neon :     5.40   9.77   6.08   7.21
  
  vp9_put_8tap_smooth_8h_10bpp_neon :     4.22   8.41   4.46   6.63
  
  vp9_put_8tap_smooth_8hv_10bpp_neon :    4.56   8.51   5.39   6.25
  
  vp9_put_8tap_smooth_8v_10bpp_neon :     6.60  12.43   8.17   8.89
  
  vp9_put_8tap_smooth_64h_10bpp_neon :    4.41   8.59   4.54   7.49
  
  vp9_put_8tap_smooth_64hv_10bpp_neon :   4.43   8.58   5.34   6.63
  
  vp9_put_8tap_smooth_64v_10bpp_neon :    7.26  13.92   9.27  10.92
  For the larger 8tap filters, the speedup vs C code is around 4-14x.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/arm/Makefile
  • [DH] libavcodec/arm/vp9dsp_init.h
  • [DH] libavcodec/arm/vp9dsp_init_10bpp_arm.c
  • [DH] libavcodec/arm/vp9dsp_init_12bpp_arm.c
  • [DH] libavcodec/arm/vp9dsp_init_16bpp_arm_template.c
  • [DH] libavcodec/arm/vp9dsp_init_arm.c
  • [DH] libavcodec/arm/vp9mc_16bpp_neon.S

• How do I properly enable ffmpeg for matplotlib.animation ?

  7 mars 2017, par spanishgum

  I have covered a lot of ground on stack so far trying to get ffmpeg going so I can make a timelapse video.

  I am on a CentOS 7 machine, running python3.7.0a0.

  python3
  
  >>> import numpy as np
  
  >>> np.__version__
  
  '1.12.0'
  
  >>> import matplotlib as mpl
  
  >>> mpl.__version__
  
  '2.0.0'
  
  >>> import mpl_toolkits.basemap as base
  
  >>> base.__version__
  
  '1.0.7'

  I found this github gist on installing ffmpeg. I used the chromium source, and installed without a prefix option (using the default).

  I have confirmed that ffmpeg is installed, although I don’t know anything about testing whether it works.

  which ffmpeg
  
  /usr/local/bin/ffmpeg
  
  
  
  ffmpeg -version
  
  ffmpeg version N-83533-gada281d Copyright (c) 2000-2017 the FFmpeg dev elopers
  
  built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-11
  
  configuration:
  
  libavutil      55. 47.100 / 55. 47.100
  
  libavcodec     57. 80.100 / 57. 80.100
  
  libavformat    57. 66.102 / 57. 66.102
  
  libavdevice    57.  2.100 / 57.  2.100
  
  libavfilter     6. 73.100 /  6. 73.100
  
  libswscale      4.  3.101 /  4.  3.101
  
  libswresample   2.  4.100 /  2.  4.100

  I tried to run a few sample examples I found online :

  [1] http://matplotlib.org/examples/animation/basic_example_writer.html

  [2] http://stackoverflow.com/a/23098090/3454650

  Everything works fine up until I try to save the animation file.

  [1]

   anim.save('basic_animation.mp4', writer = FFwriter, fps=30, extra_args=['-vcodec', 'libx264'])

  [2]

  im_ani.save('im.mp4', writer=writer)

  I found here that explictly setting the path to ffmpeg might be necessary so I added this to the top of the test scripts :

  plt.rcParams['animation.ffmpeg_path'] = '/usr/local/bin/ffmpeg'

  I tried a few more tweaks in the code but always get the same response, which I do not know how to begin deciphering :

  Traceback (most recent call last):
  
    File "testanim.py", line 27, in <module>
  
      writer.grab_frame()
  
    File "/usr/local/lib/python3.7/contextlib.py", line 100, in __exit__
  
      self.gen.throw(type, value, traceback)
  
    File "/usr/local/lib/python3.7/site-packages/matplotlib/animation.py", line 256, in saving
  
      self.finish()
  
    File "/usr/local/lib/python3.7/site-packages/matplotlib/animation.py", line 276, in finish
  
      self.cleanup()
  
    File "/usr/local/lib/python3.7/site-packages/matplotlib/animation.py", line 311, in cleanup
  
      out, err = self._proc.communicate()
  
    File "/usr/local/lib/python3.7/subprocess.py", line 836, in communicate
  
      stdout, stderr = self._communicate(input, endtime, timeout)
  
    File "/usr/local/lib/python3.7/subprocess.py", line 1474, in _communicate
  
      selector.register(self.stdout, selectors.EVENT_READ)
  
    File "/usr/local/lib/python3.7/selectors.py", line 351, in register
  
      key = super().register(fileobj, events, data)
  
    File "/usr/local/lib/python3.7/selectors.py", line 237, in register
  
      key = SelectorKey(fileobj, self._fileobj_lookup(fileobj), events, data)
  
    File "/usr/local/lib/python3.7/selectors.py", line 224, in _fileobj_lookup
  
      return _fileobj_to_fd(fileobj)
  
    File "/usr/local/lib/python3.7/selectors.py", line 39, in _fileobj_to_fd
  
      "{!r}".format(fileobj)) from None
  
  ValueError: Invalid file object: &lt;_io.BufferedReader name=6>
  
  </module>

  Is there something with my configuration that is malformed ? I searched google for this error for some time but never found anything relevant to animations / ffmpeg. Any help would be greatly appreciated.

  ---

  UPDATE :

  @LordNeckBeard pointed me here : https://trac.ffmpeg.org/wiki/CompilationGuide/Centos

  I ran into problems with installing the x264 encoding dependency. Some files in libavcodec/*.c (in the make output) were reporting undefined references to several functions. After a wild goose chase found this : https://mailman.videolan.org/pipermail/x264-devel/2015-February/010971.html

  To fix the x264 installation, I simply added some configure flags :

  ./configure --enable-static --enable-shared --extra-ldflags="-lswresample -llzma"

  ---

  UPDATE :

  So everything installed fine after fixing the libx264 problems. I went ahead and copied the ffmpeg binary from the ffmpeg_build folder into /usr/local/bin/ffmpeg.

  After running the script I was getting problems where ffmpeg could not find the libx264 shared object. I think I will have to recompile everything using different prefixes. My intuition tells me there are old files laying around after I have messed with everything, using some configuration that is broken.

  So I decided maybe I should just try to use NUX : http://linoxide.com/linux-how-to/install-ffmpeg-centos-7/
  I installed ffmpeg using the new rpm, but to no avail. I still was not able to run ffmpeg because of a missing shared object.

  Finally, instead of usiong files copied into my /usr/local/bin folder, I ran ffmpeg directly from the build bin directory. Turns out that this does work properly !

  So in essence, if I want to install ffmpeg system wide, I need to manually compile from sources again but using a nonlocal prefix.

• cinepakenc : fixes and improvements

  27 juin 2017, par addr-see-the-website@aetey.se

  cinepakenc : fixes and improvements
  version 2013-02-08 Rl
  
   fixes/optimization in multistrip encoding and codebook size choice,
  
    quality/bitrate is now better than that of the binary proprietary encoder
  version 2013-02-12 Rl
  
   separated codebook training sets, avoided the transfer of wasted bytes,
  
    which yields both better quality and smaller files
  
   now using the correct colorspace (TODO : move conversion to libswscale)
  version 2013-02-14 Rl "Valentine’s Day" version :
  
   made strip division more robust
  
   minimized bruteforcing the number of strips,
  
    (costs some R/D but speeds up compession a lot), the heuristic
  
    assumption is that score as a function of the number of strips has
  
    one wide minimum which moves slowly, of course not fully true
  
   simplified codebook generation,
  
    the old code was meant for other optimizations than we actually do
  
   optimized the codebook generation / error estimation for MODE_MC
  version 2013-04-28 Rl
  
   bugfixed codebook optimization logic
  version 2014-01-20 Rl
  
   made the encoder compatible with vintage decoders
  
    and added some yet unused code for possible future
  
    incremental codebook updates
  
   fixed a small memory leak
  version 2014-01-21 Rl
  
   believe it or not, now we get even smaller files, with better quality
  
    (which means I missed an optimization earlier :)
  Signed-off-by : Diego Biurrun <diego@biurrun.de>
  

  • [DBH] libavcodec/cinepakenc.c