[FFmpeg-devel] [PATCH] ffmdec: sanitize codec parameters
andreas.cadhalpun at googlemail.com
Tue Nov 22 01:40:52 EET 2016
On 21.11.2016 03:13, Michael Niedermayer wrote:
> On Sun, Nov 20, 2016 at 08:40:24PM +0100, Andreas Cadhalpun wrote:
>> Currently many demuxers silently accept wrong (i.e. negative) values
>> for channels, bit_rate, block_align and so on. I'd like to fix that,
>> so the question is now, how?
>> There are a few possibilities:
>> a) error out for negative values and also for zero
>> b) error out for negative values, silently accept zero
>> c) warn for negative values and also for zero
>> d) warn for negative values, silently accept zero
>> e) something else
>> Is there a consensus on which way is best?
> I think this depends on the format and what exists in real world files
> If X is allowed by the spec, clearly no error or warning should be
> produced for it
> If X is not allowed by the spec but occurs in some file then no error
> should occur by default but likely a warning. More strict compliance
> options can change this.
> If X does not work (demuxer failing in some form) then it should error
> Theres quite a bit between these and theres the problem of not knowing
> spec and file existence easily
In general that sounds reasonable, but what does it mean in practice?
For example what should be done about overflows, e.g. when calculating
the bit rate? Does this count as demuxer failing?
And what should be done if the spec says a field is unsigned, but
our framework only supports the signed variant?
More information about the ffmpeg-devel