[FFmpeg-devel] H264 cleanup performance effects

[wm4]

On Sun, 22 Mar 2015 18:11:34 +0200
Ivan Kalvachev <ikalvachev at gmail.com> wrote:

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

I hope FFmpeg doesn't value speed over clean code. (Oh who am I
kidding, the worst abuse is ok if it makes it 1% faster!)

I can assure you, in the end simpler code wins, because it's actually
maintainable and hackable. Just generally speaking.

What's "durability" in this context even?

> 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.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel