On 5/29/2020 10:10 AM, Michael Niedermayer wrote: > while, what you quote above was not about h264 at all > let me provide benchmarks of most fate h264 samples with and without > flag_unsafe > the script that made that is after it. a reply to the 2nd part of your mail is > also below > > > h264-444/444_10bit_cabac.h264 > 1874813 decicycles in ff_h2645_packet_split, 16 runs, 0 skips > 658715 decicycles in ff_h2645_packet_split, 16 runs, 0 skips
So the fast flag currently prevents ff_h2645_packet_split() from copying each NAL into a padded buffer (in the situations where there's are no emulation_prevention_three_byte to filter). Why is such padding needed to prevent overreads? cbs_h264 always calls ff_h2645_packet_split() with the small_padding argument as 1, and fuzzing has shown that it seemingly generated no issues whatsoever, so why can't the bitstream reading code in h264dec handle it safely? Or it could but it would be costly? And even if costly, wouldn't the the speedup gained in a normal run with no flags set (where most NALs would not be copied anymore to another buffer) offset the slowdown from the extra sanity checks? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
