[Matroska-devel] Question about Test Suite

Vignesh Venkatasubramanian vigneshv at google.com
Mon Jul 27 18:58:40 CEST 2015

On Fri, Jul 24, 2015 at 12:00 AM, Moritz Bunkus <moritz at bunkus.org> wrote:
> Hey,
>> How does mkvinfo get to 451452 to begin reading the next element
>> instead?
> mkvinfo uses libebml's EbmlMaster::Read() function for reading a cluster
> en bloc and then outputs which elements libebml has found.
> EbmlMaster::Read() uses EbmlEmenet::FindNextElement() under the hood
> for finding the next ID. And that function reads as many bytes as
> needed for forming a valid ID.
> So if the byte at position 451451 happens to be 0 (which I haven't
> verified, mind you) then it will probably be skipped as an EBML ID's
> first byte is never 0. Similar reasoning for other values for the
> first byte, e.g. anything smaller than 0x10 would be invalid as EBML
> IDs can only be four bytes long, and the position of first bit set to
> 1 determines the size of the EBML ID.

Thanks for the explanation. But the problem is, the byte at position
451451 is 0xEA which is a valid EBML ID right? How does mkvinfo skip
just that byte? FYI, here are the 100 bytes starting from position
451417: http://pastebin.com/jKxthKwF

I ran the file through ffmpeg's matroska parser. That resyncs to the
next level 1 element as soon as it sees the invalid track number (i.e.
position 451518) by doing a byte-by-byte search. So it merely ignores
the value at 451451 as it is not a valid level 1 id.

> Kind regards,
> mosu
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel


More information about the Matroska-devel mailing list