[FFmpeg-devel] [PATCH] simplify and fix ebml_read_num
Mon Sep 6 20:04:09 CEST 2010
On Sun, Sep 05, 2010 at 11:09:51PM +0200, Aurelien Jacobs wrote:
> On Thu, Sep 02, 2010 at 09:34:18PM +0200, Reimar D?ffinger wrote:
> > On Wed, Sep 01, 2010 at 11:20:38PM +0200, Aurelien Jacobs wrote:
> > > Except those remarks, this part of the patch (simplification) is OK.
> > Applied with changes.
> > > > while (n++ < read)
> > > > total = (total << 8) | get_byte(pb);
> > > >
> > > > + /* unknown length */
> > > > + if (total + 1 == 1ULL << (7 * read))
> > > > + total = 0xffffffffffffff;
> > >
> > > I'm not sure if this is strictly correct. The matroska spec is not a
> > > 100% clear, but I seem to understand that this rule don't apply to all
> > > kind of ebml number. It seems to only apply to element size.
> > > So maybe we need a new ebml_read_length() function, similar to this
> > > ebml_read_num(), but with this additionnal "unknown length" rule ?
> > Easy enough to do, and fixes parsing of test case 4 up to that point,
> Patch OK.
> > however I have no idea how one is supposed to parse the file from
> > there (except wildly trying to parse until it works).
> I've had a close look at that file, and I have no idea how it could be
> parsed correctly according to Matroska specs.
> The sample file can be trivially patched to be playable by converting
> the long string of 0x0A into a Void element (attached binary patch does
> this, and can be applied with bspatch).
Can't see anything attached, but I know what you mean.
mkvinfo doesn't provide any useful information on how it decided to skip
those bytes either. Unfortunately we know that it's not beyond them to
just make bugs in their software part of the specification...
More information about the ffmpeg-devel