Recherche avancée

Sur d’autres sites (5103)

• swresample/resample : speed up upsampling by precomputing sines

  9 novembre 2015, par Ganesh Ajjanagadde

  swresample/resample : speed up upsampling by precomputing sines
  When upsampling, factor is set to 1 and sines need to be evaluated only
  
  once for each phase, and the complexity should not depend on the number
  
  of filter taps. This does the desired precomputation, yielding
  
  significant speedups. Hard guarantees on the gain are not possible, but gains
  
  themselves are obvious and are illustrated below.
  Sample benchmark (x86-64, Haswell, GNU/Linux)
  
  test : fate-swr-resample-dblp-2626-44100
  
  old :
  
  29161085 decicycles in build_filter (loop 1000),     256 runs,      0 skips
  
  28821467 decicycles in build_filter (loop 1000),     512 runs,      0 skips
  
  28668201 decicycles in build_filter (loop 1000),    1000 runs,     24 skips
  new :
  
  14351936 decicycles in build_filter (loop 1000),     256 runs,      0 skips
  
  14306652 decicycles in build_filter (loop 1000),     512 runs,      0 skips
  
  14299923 decicycles in build_filter (loop 1000),    1000 runs,     24 skips
  Note that this does not statically allocate the sin lookup table. This
  
  may be done for the default 1024 phases, yielding a 512*8 = 4kB array
  
  which should be small enough.
  
  This should yield a small improvement. Nevertheless, this is separate from
  
  this patch, is more ambiguous due to the binary increase, and requires a
  
  lut to be generated offline.
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libswresample/resample.c

• How do I play back video on Android with custom playback speed ?

  13 novembre 2015, par guidow

  I want to play back a video in Android, rendering it to a SurfaceTexture or something else that is usable as an OpenGL ES texture, but I need very precise control over the playback speed of the video to synchronize it to a stream of external events. These events will happen at a roughly predictable speed, but the exact speed will depend on many small mechanical details, influenced by many small factors, including the weather (and possibly even the phase of the moon...).

  The android.media.MediaPlayer class provided by android allows rendering to a SurfaceTexture (and the 360Videos app from the Oculus Mobile SDK successfully uses that feature), but unfortunately does not seem to allow altering the playback speed, at least not as far as I could tell from the documentation here.

  I have tried pausing and resuming the playback using pause() and start() respectively, to influence the playback speed, but that leads to extremely choppy and slow playback. My idea here was to make the video have a higher framerate than would ever be needed, and to then manually retard every frame until it actually needs to be shown. From the messages in the log, it looks to me like the MediaPlayer class will release various needed resources on pause and rerequest them on resume, which obviously kills performance if you do that once per frame.

  Another option I am looking at is ffmpeg. This one seems like it will do what i want, it doesn’t do any timings itself, it just decodes frames whenever I tell it to to a buffer, leaving me to use it however I want, whenever I want. The obvious drawback is that ffmpeg, at least on android, doesn’t do hardware decoding and probably won’t be able to decode 4K media in realtime.

  Yet another thing I was looking at was OpenMAX AL. Unfortunately, OpenMax AL is pretty hard to get into. I haven’t found any good beginner’s documentation yet, only some old, maybe outdated, READMEs as well as the interface specification from Khronos. The latter is a very long and cumbersome read, though, and I couldn’t yet even figure out if OpenMAX AL will even allow me to do my own timings...

• avfilter/af_afade : improve accuracy and speed of gain computation

  25 novembre 2015, par Ganesh Ajjanagadde

  avfilter/af_afade : improve accuracy and speed of gain computation
  Gain computation for various curves was being done in a needlessly
  
  inaccurate fashion. Of course these are all subjective curves, but when
  
  a curve is advertised to the user, it should be matched as closely as
  
  possible within the limitations of libm. In particular, the constants
  
  kept here were pretty inaccurate for double precision.
  Speed improvements are mainly due to the avoidance of pow, the most
  
  notorious of the libm functions in terms of performance. To be fair, it
  
  is the GNU libm that is among the worst, but it is not really GNU libm’s fault
  
  since others simply yield a higher error as measured in ULP.
  "Magic" constants are also accordingly documented, since they take at
  
  least a minute of thought for a casual reader.
  Reviewed-by : Paul B Mahol <onemda@gmail.com>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libavfilter/af_afade.c