On 4/10/2019 5:24 AM, Michael Niedermayer wrote: > 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
At least with the sample in the ticket, it's a buggy encoder that for some reason coded a -129 value in a field with a -128,127 valid range. The rest of the bitstream appears correct, including byte alignment padding bits and such. I'll replace the av_log lines with request sample ones then. > > Thanks > > [...] > > > _______________________________________________ > 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". > _______________________________________________ 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".
