[FFmpeg-devel] [PATCH] ffmdec: sanitize codec parameters

[Michael Niedermayer]

On Sun, Nov 20, 2016 at 08:40:24PM +0100, Andreas Cadhalpun wrote:
> On 20.11.2016 13:42, Carl Eugen Hoyos wrote:
> > 2016-11-19 17:30 GMT+01:00 Andreas Cadhalpun <andreas.cadhalpun at googlemail.com>:
> > 
> >> A hard failure is unnecessary and Carl Eugen [1] and Hendrik [2]
> >> convinced me that it should be avoided.
> > 
> > I believe that ffm should (or at least can) indeed be treated differently
> > from all other containers.
> 
> OK, ffm is a special case, but I'm also interested in the general case.
> 
> 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
out


Theres quite a bit between these and theres the problem of not knowing
spec and file existence easily

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161121/fbc64124/attachment.sig>