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 ..."
signature.asc
Description: PGP signature
_______________________________________________ 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".
