[FFmpeg-devel] [PATCH 2/3] avcodec/h264: error out on ff_h264_pred_weight_table() only if strict spec compliance is requested
michael at niedermayer.cc
Wed Apr 10 11:24:19 EEST 2019
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
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: not available
More information about the ffmpeg-devel