Recherche avancée

Sur d’autres sites (4771)

• swresample/resample : speed up build_filter for Blackman-Nuttall filter

  5 novembre 2015, par Ganesh Ajjanagadde

  swresample/resample : speed up build_filter for Blackman-Nuttall filter
  This uses the trigonometric double and triple angle formulae to avoid
  
  repeated (expensive) evaluation of libc’s cos().
  Sample benchmark (x86-64, Haswell, GNU/Linux)
  
  test : fate-swr-resample-dblp-44100-2626
  
  old :
  
  1104466600 decicycles in build_filter(loop 1000),     256 runs,      0 skips
  
  1096765286 decicycles in build_filter(loop 1000),     512 runs,      0 skips
  
  1070479590 decicycles in build_filter(loop 1000),    1024 runs,      0 skips
  new :
  
  588861423 decicycles in build_filter(loop 1000),     256 runs,      0 skips
  
  591262754 decicycles in build_filter(loop 1000),     512 runs,      0 skips
  
  577355145 decicycles in build_filter(loop 1000),    1024 runs,      0 skips
  This results in small differences with the old expression :
  
  difference (worst case on [0, 2*M_PI]), argmax 0.008 :
  
  max diff (relative) : 0.000000000000157289807188
  
  blackman_old(0.008) : 0.000363951585488813192382
  
  blackman_new(0.008) : 0.000363951585488755946507
  These are judged to be insignificant for the performance gain. PSNR to
  
  reference file is unchanged up to second decimal point for instance.
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libswresample/resample.c

• Animation speed adjustment using ffmpeg in Python

  5 novembre 2015, par neither-nor

  I’m been for years using stock ffmpeg script to sequentially snitch together temporal plots in Python. However, I cannot figure out the trivial issue of how to, for instance, slow down the animation speed so that the resultant video file has a longer duration.

  Example :

  import matplotlib.pyplot as plt
  
  import os, sys
  
  
  
  for t in range(100):
  
      plt.cla()
  
      plt.text(0.5, 0.5, 'time %02d'%(t+1))
  
      plt.draw()
  
  
  
      fname = '_tmp%02d.png'%(t+1)
  
      plt.savefig(fname)
  
  
  
  os.system("ffmpeg -i _tmp%02d.png -pix_fmt yuv420p -r 20 -b:v 20M flipbook.mp4")
  
  os.system("rm _tmp*.png")    

  The resulting "flip book" takes 4s and the time stamp increases steadily. However, I tried to make the animation last twice as long by testing the following :

  1. Change 20 after -r to 1 : this still lasts 4s but now the time stamp "leaps" nonlinearly

  2. Change 20M to 1M : no discernible effect

  I can’t find much information about this line of code, either the usage of each flag or how to modify aspects of it (e.g.,speed).

• 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