[FFmpeg-devel] H264 cleanup performance effects

[Ivan Kalvachev]

On 3/22/15, wm4 <nfxjfg at googlemail.com> wrote:
> On Sun, 22 Mar 2015 15:12:04 +0100
> Michael Niedermayer <michaelni at gmx.at> wrote:
>
>> Hi anton, everyone else
>
> I appreciate that you contacted the author of these patches as well.
>
>> the "cosmetic" commits from yesterday
>> (665e0c10a63d31dd6c7b1fba14db074625d54614..fa7c08d5e192aea77fdfb7f52c44c196a3ba4452)
>> /
>> (d8a45d2d49f54fde042b195f9d5859251252493d..c28ed1d743443e783537d279ae721be3bbdf7646)
>>
>> cause a ~1% speed loss in the H.264 decoder which is probably the
>> most important decoder in the codebase
>>
>> after the patchset:
>> -threads 1 -benchmark -i cathedral-beta2-400extra-crop-avc.mp4 -an -f null
>> -
>> utime=5.448s
>> utime=5.424s
>> utime=5.436s
>> utime=5.428s
>> utime=5.448s
>>
>>
>> before the patchset:
>> -threads 1 -benchmark -i cathedral-beta2-400extra-crop-avc.mp4 -an -f null
>> -
>> utime=5.360s
>> utime=5.328s
>> utime=5.356s
>> utime=5.376s
>> utime=5.360s
>>
>> Testing has been done with a single thread as the results with
>> multiple threads where inconsistent/unstable
>>
>> The speedloss is reproduceable with ffmpeg as well as libav
>
> At this point I'd argue that 1% speedloss in exchange for much cleaner
> and saner code is not the world's end. Especially because ffmpeg is
> probably already the fastest software decoder on x86, and cleaner code
> may in fact help improving the decoder further. (But then I don't know
> the h264 decoder, and may be talking out of my ass.)

No, It won't help improve the decoder further. This code would never
be touched by anybody who can't navigate in it already.

Libav is the project that values pretty code.
I hope FFmpeg still values speed and durability.

Also, the speed loss is more like 2% and that's A LOT.

If anybody wants this cleanup included, then I recommend him to find a
clean way to compensate for this slowdown.

Good Luck.