On 26/05/16 16:32, Ronald S. Bultje wrote: > I think this misses the point. I tested 3 decoders, and 2 were slower. It > looks like something between 10 and 100 decoders were changed. I could blow > this up and say that this suggests that there may, in fact, be a > performance problem that might significantly affect the majority of the > decoders on a significant subset of systems.
I'm not seeing this way. A large speed gain (10-30%) on x86_64 (and on power8) for mezzanine formats dwarfs the fact they are 1-5% slower on platforms (arm32, x86_32) that are slow on reproducing that kind of content, no matter what you do, since they have tiny I/O, IMHO. Decoding non-mezzanine formats spends more time doing math operations so the speed gains/slowdowns in reading bits aren't as marked, but you are welcome to spend time on testing exhaustively. Bonus point if the method is reproducible and just uses avconv and perf. > I'm not going to make that claim just yet because I feel like I don't have > enough data. But claiming that this only affects dnxhd/prores decoding on > VLC on "some tablets" misses the point. I prefer Luca's approach (thanks!) > of testing arm32, even if it takes a little bit of effort. Well, you seem to miss the fact that I was not happy to spend more time on that since to me the trade-off is already in the good enough area and it required me about 1/2 day to set up and arm32 chroot on the odroid... For prores there is a 1% slowdown with a %0.4 uncertainty, huffyuv is a 20% slower or a 5% slower depending on the compiler (it takes 26s vs the 21s to decode 10s of test stream in the worst scenario), from what I can see much of it depends on the compiler choosing which function to inline in which one, on x86_32 (and x86_64) the compiler gets to do a better job by relaxing the constraint from force-inline to inline, on arm32 seems that the compiler isn't as good. I tested on arm32 h264 cavlc (that's the only codec with some bitreader impact I would consider for an arm32 platform) and there is no speed difference (0.6% difference with a 0.7% uncertainty). I'm still convinced the set is good enough to enter the tree, help in making huffyuv behave in a less unpredictable way is welcome independently since it seems to be quite hairy for compilers in a way or another (see the ancient gcc used by travis or the current clang from git master). lu _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
