On 22.11.2016 01:35, Carl Eugen Hoyos wrote: > 2016-11-22 0:06 GMT+01:00 Andreas Cadhalpun > <andreas.cadhal...@googlemail.com>: >> I tend to silently accept zero, because I'd like a >> consistent solution and in some cases rejecting zero >> causes FATE failures. > > If there were a bug, you should of course fix fate, fate > alone is generally no argument in favour or against a patch.
The cases I mean don't look like bugs, just like cases, where it is expected that some files set certain codec parameters to 0. >> Because either our demuxer has a bug and should be fixed, >> or some other tool created broken files, and if ffmpeg >> informs it's users about that, they can try to get that >> tool fixed. > > (Träum weiter) > Seriously: We have an uncountable amount of files that > do not respect some "specification", many of them apparently > by intention, many written by applications that do not exist > since a long time, and some written by applications that have > fixed the issue meanwhile: Of course it can be a (very) good > thing to print warnings but in general, we should try to fix a > few of the thousands of known bugs in FFmpeg and not > spend infinite time on possible issues in other applications. > > Sorry if I just misunderstand you. I didn't want to suggest that we fix other applications, just that users of ffmpeg can realize there is a problem in another application, if files produced by that application trigger a warning in ffmpeg. (Of course this also applies to ffmpeg's muxers.) Best regards, Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
