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

Anton Khirnov anton at khirnov.net
Thu May 28 21:30:16 EEST 2020


Quoting Michael Niedermayer (2020-05-28 20:09:15)
> 
> h264 is a specific use of this flag, and that might not be the only
> place it could be used in
> 
> But about h264 What this is about if i remember it correctly, is
> that the maximum input any crafted bitstream of a block can require is X,
> now you can if the input size is less than X copy that to a larger buffer or
> you can add lots of checks. Both of these slow the code down a bit.
> OTOH, if the stream is known to be valid that can be skipped.
> 
> It can also be skiped if the buffer is already big enough to begin with
> OR if the output goes to the parser and not the decoder.
> So even without the user having access to this, the codepath does not
> become unneeded
> the h264 case is more a "even if you cant proof its safe on case 123
> use it anyway"
> And quite possibly we can add more code detecting more cases where
> it is safe, this should be investigated either way probably.

It does not seem to me that there is a sufficient use case for "decode
as fast as possible, even at the cost of crashing sometimes". Big
transcoders like youtube have process untrusted input and therefore care
about correctness. End-user playback is either fast enough or
hardware-accelerated (and thus fast enough).

What kind of users do you believe warrants this extra complexity?

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list