[FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it

[James Almer]

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?