[FFmpeg-devel] [PATCH] mkv 0-byte integer parsing

Michael Niedermayer michaelni
Tue Sep 7 22:00:01 CEST 2010

On Tue, Sep 07, 2010 at 09:52:02PM +0200, Reimar D?ffinger wrote:
> On Tue, Sep 07, 2010 at 08:19:28PM +0100, M?ns Rullg?rd wrote:
> > Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> > 
> > > On Tue, Sep 07, 2010 at 08:12:49PM +0200, Sebastian Hagen wrote:
> > >> On 2010-09-05 16:22, Sebastian Hagen wrote:
> > >> >with a length of 0 bytes correctly, even though those are valid
> > >> >according to the Matroska specs[1] and mkv files containing them can be
> > >> My bad, that statement was incorrect. Such integers are valid
> > >> according to the EBML specs[1], but not the matroska ones[2], since
> > >> the latter gratuituously set a minimum uint size of 1 byte.
> > >> Nevertheless, while such elements are technically invalid, some
> > >> demuxers will happily accept them, and the robust thing to do would
> > >> be for ffmpeg to do the same.
> > >
> > > In that case it would actually be good to warn, it is preferable
> > > to warn about technically invalid files otherwise people will generate
> > > them without noticing and the format will over time become more and
> > > more painful to support.
> > 
> > This assumes people pay any heed whatsoever to warnings.  In actual
> > practice they do not.  It is thus in my opinion preferable to fail
> > with an error message for such files, optionally providing an
> > unwieldy, hard to find setting to reluctantly accept these files
> > regardless.  It is the only way to be sure.  Unless we nuke them from
> > orbit.
> Well, a warning at least gives those a chance that try.
> Everyone else will probably test only against a single implementation
> anyway.
> But yes, it might make sense to error out for uncommon errors unless
> -strict is set to an appropriate value.

on demuxing/decoding we try our best to support all input no matter if it
complies to specs or not

people are free to fork and provide a ffmpeg that fails instead of
working for files not compliant to specs.
we could add a branch for that
maybe ffmpeg-not_working?
or even a compile time option in main svn? i wouldnt mind ...

the only thing we non fatally fail on is things that look like bitstream
errors , that is so error concealment / resync is done
and this can be adjusted with AVCodecContext parameters ,..
but ffmpeg should never reject input just because its not compliant to some
spec, warn is ok, big blinking red if you like but dont fail

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100907/3a464355/attachment.pgp>

More information about the ffmpeg-devel mailing list