On Sun, 22 Mar 2015 18:11:34 +0200 Ivan Kalvachev <ikalvac...@gmail.com> wrote:
> On 3/22/15, wm4 <nfx...@googlemail.com> wrote: > > On Sun, 22 Mar 2015 15:12:04 +0100 > > Michael Niedermayer <michae...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
