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

[Michael Niedermayer]

On Fri, May 29, 2020 at 10:37:59AM -0300, James Almer wrote:
> 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? 

yes, it would cause a slowdown


> 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?

When this code was written the copy was faster than the checks IIRC.
That said, it is very possible we could do a more inteligent mix of
checks and copying.
for example check after each MB that there is enough space left and
only copy the last few of a slice to a seperate buffer. but then
the max size we use is rather large so we need to calculate a tigher
bound there first and hope this is smaller than the average slice
Or maybe there are even other ways.

Now if we do a check per MB and copy, we could do a step beyond this
and also skip copy when unescaping is needed as long as we know the MB
is completely before or after all escaped points in the bitstream
maybe that complexity isnt worth it, maybe it is for some high bitrate
files.
We could also keep track of allocated sizes of the bitstream and
allocate more from where it comes from or have per codec padding
bitstream suggestions.
Or maybe theres even some other trick like there exist for mpeg1/2/4ASP
which avoids the whole need for checks

that all said, this is of course not going to make a huge difference
in speed, its just 1 copy of the compressed bitstream. but many use h264 ...

all just a bunch of random ideas, i hope something of this helps ...

Thanks


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200529/a51eae25/attachment.sig>