Recherche avancée

Sur d’autres sites (10292)

• 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...

• avutil/lls : speed up performance of solve_lls

  24 novembre 2015, par Ganesh Ajjanagadde

  avutil/lls : speed up performance of solve_lls
  This is a trivial rewrite of the loops that results in better
  
  prefetching and associated cache efficiency. Essentially, the problem is
  
  that modern prefetching logic is based on finite state Markov memory, a reasonable
  
  assumption that is used elsewhere in CPU’s in for instance branch
  
  predictors.
  Surrounding loops all iterate forward through the array, making the
  
  predictor think of prefetching in the forward direction, but the
  
  intermediate loop is unnecessarily in the backward direction.
  Speedup is nontrivial. Benchmarks obtained by 10^6 iterations within
  
  solve_lls, with START/STOP_TIMER. File is tests/data/fate/flac-16-lpc-cholesky.err.
  
  Hardware : x86-64, Haswell, GNU/Linux.
  new :
  
    17291 decicycles in solve_lls, 2096706 runs,    446 skips
  
    17255 decicycles in solve_lls, 4193657 runs,    647 skips
  
    17231 decicycles in solve_lls, 8384997 runs,   3611 skips
  
    17189 decicycles in solve_lls,16771010 runs,   6206 skips
  
    17132 decicycles in solve_lls,33544757 runs,   9675 skips
  
    17092 decicycles in solve_lls,67092404 runs,  16460 skips
  
    17058 decicycles in solve_lls,134188213 runs,  29515 skips
  old :
  
    18009 decicycles in solve_lls, 2096665 runs,    487 skips
  
    17805 decicycles in solve_lls, 4193320 runs,    984 skips
  
    17779 decicycles in solve_lls, 8386855 runs,   1753 skips
  
    18289 decicycles in solve_lls,16774280 runs,   2936 skips
  
    18158 decicycles in solve_lls,33548104 runs,   6328 skips
  
    18420 decicycles in solve_lls,67091793 runs,  17071 skips
  
    18310 decicycles in solve_lls,134187219 runs,  30509 skips
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libavutil/lls.c

• avcodec/aac_tablegen : speed up table initialization

  26 novembre 2015, par Ganesh Ajjanagadde

  avcodec/aac_tablegen : speed up table initialization
  This speeds up aac_tablegen to a ludicruous degree ( 97%), i.e to the point
  
  where it can be argued that runtime initialization can always be done instead of
  
  hard-coded tables. The only cost is essentially a trivial increase in
  
  the stack size.
  Even if one does not care about this, the patch also improves accuracy
  
  as detailed below.
  Performance :
  
  Benchmark obtained by looping 10^4 times over ff_aac_tableinit.
  Sample benchmark (x86-64, Haswell, GNU/Linux) :
  
  old :
  
  1295292 decicycles in ff_aac_tableinit,     512 runs,      0 skips
  
  1275981 decicycles in ff_aac_tableinit,    1024 runs,      0 skips
  
  1272932 decicycles in ff_aac_tableinit,    2048 runs,      0 skips
  
  1262164 decicycles in ff_aac_tableinit,    4096 runs,      0 skips
  
  1256720 decicycles in ff_aac_tableinit,    8192 runs,      0 skips
  new :
  
  21112 decicycles in ff_aac_tableinit,     511 runs,      1 skips
  
  21269 decicycles in ff_aac_tableinit,    1023 runs,      1 skips
  
  21352 decicycles in ff_aac_tableinit,    2043 runs,      5 skips
  
  21386 decicycles in ff_aac_tableinit,    4080 runs,     16 skips
  
  21299 decicycles in ff_aac_tableinit,    8173 runs,     19 skips
  Accuracy :
  
  The previous code was resulting in needless loss of
  
  accuracy due to the pow being called in succession. As an illustration
  
  of this :
  
  ff_aac_pow34sf_tab[3]
  
  old : 0.000000000007598092294225
  
  new : 0.000000000007598091426864
  
  real : 0.000000000007598091778545
  truncated to float
  
  old : 0.000000000007598092294225
  
  new : 0.000000000007598091426864
  
  real : 0.000000000007598091426864
  showing that the old value was not correctly rounded. This affects a
  
  large number of elements of the array.
  Patch tested with FATE.
  Reviewed-by : Rostislav Pehlivanov <atomnuker@gmail.com>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libavcodec/aac_tablegen.h