[FFmpeg-devel] [PATCH 2/3] avcodec/h264: error out on ff_h264_pred_weight_table() only if strict spec compliance is requested

James Almer jamrial at gmail.com
Wed Apr 10 21:01:18 EEST 2019


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 <jamrial at 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> 



More information about the ffmpeg-devel mailing list