Hi, and thank you for forwarding the mails. Note: gmail sends to both you and libav ml, so maybe an equivalent of "reply all" may be needed to avoid private replies.
2016-04-29 9:52 GMT+02:00 Alexandra Hájková <[email protected]>: > All the work is here: > https://github.com/sasshka/libav/tree/get_bits0 More info from me: stripped binary size goes from 10639872, for libav/master, to 11278336, ie around 600K. This makes me think that, whatever inlining or reason for code size increase there is, the cause would better be isolated, and ideally restricted to performance-sensitive code (other parts ideally not using what causes that size increase, like there is, iirc, av_cold). The threshold could be low, maybe 600K is not something to care about. Now that I have understood that not all codecs are yet converted in the patchset, I have looked at a typical interesting case, huffyuv. Example: -i <large sequence> -s 1920x1080 -an -sn -c:v ffvhuff -vframes 500 -y out.avi The results are interesting: time / size / decode_gray_bitstream _TIMER 4.16 / 34236 / 190887 UNITS in gray, 262143 runs, 1 skips 6.41 / 16080 / 283210 UNITS in gray, 262144 runs, 0 skips I think this looks good and warrants attention (for those that care). -- Christophe _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
