[FFmpeg-devel] [PATCHv3] VP4 video decoder

Reimar Döffinger Reimar.Doeffinger at gmx.de
Fri May 17 21:13:51 EEST 2019


On Fri, May 17, 2019 at 08:09:45PM +1000, Peter Ross wrote:
> ah, i see what you did there! it works perfectly, just missing
> UPDATE_CACHE at the start and in the loop.
>
> test results on i7 decoding 3 minute long 4k video with vp4.

Looks fairly close to noise to me, though for me
it seemed a bit more obvious how the encoding
works from it (which was the primary reason to suggest it).
If one really wanted to optimize it for performance the
arrangement of the conditions can probably be improved, e.g.
the 0x1ff check is now the very first one even though
it is the least likely one (but avoids duplicating code
or needing crazy goto or loop constructs and thus
is more readable), and depending on probabilities
doing the range checks in a more tree-like structure
might also be better.
But as said, optimizing this has probably at most
curiosity value :)

> vp4 patch v3:
> bench: utime=113.439s stime=0.414s rtime=30.161s
> bench: utime=113.406s stime=0.403s rtime=30.123s
> bench: utime=113.533s stime=0.310s rtime=30.104s
> bench: utime=113.691s stime=0.414s rtime=30.148s
> bench: utime=113.414s stime=0.435s rtime=30.102s
> bench: utime=113.449s stime=0.370s rtime=30.138s
> bench: utime=113.277s stime=0.470s rtime=30.139s
>
> your patch + UPDATE_CACHE:
> bench: utime=113.373s stime=0.386s rtime=30.109s
> bench: utime=113.284s stime=0.378s rtime=30.122s
> bench: utime=113.314s stime=0.414s rtime=30.125s
> bench: utime=113.369s stime=0.378s rtime=30.130s
> bench: utime=113.309s stime=0.394s rtime=30.108s
> bench: utime=113.285s stime=0.435s rtime=30.048s
> bench: utime=113.506s stime=0.362s rtime=30.182s


More information about the ffmpeg-devel mailing list