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 _______________________________________________ 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".
