On Tue, Apr 09, 2019 at 03:32:26PM -0300, James Almer wrote: > Fixes ticket #7174. > > Signed-off-by: James Almer <jamr...@gmail.com> > --- > This makes what's essentially a non spec compliant stream decodable again with > no visual artifacts, and without reintroducing the risk of overflows. >
> Alternatively, we could clip the luma and chroma values to the -128..127 > range instead of setting them to defaults. I think to awnser this we would need streams where there is an actual difference between these choices There are 2 possible sources of such non compliant values 1. damaged bitstream data 2. buggy encoders For handling 2. its likely best to narrowly detect the bug and handle it accordingly (which may be to ignore it if for example there are no MBs that use the values in the bug case) For handling 1. its likely best to set all values to some default or guessed not just the first and then continue parsing as the decoder state is already screwed and the following values even if they end in valid ranges likely would be no good. The low number of samples for these 2 cases makes testing what is best somewhat difficult. We could generate damaged streams though but still as theres a wide range of potential damage that may not match the distribution of real world damaged streams I would suggest to leave a request for samples in the codepath. As more samples (damaged as well as buggy encoders) would allow better evaluating which alternative solution would be best in practice and not just theory Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato
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".
