[Matroska-devel] Representation of payload for SeekHead entries

Moritz Bunkus moritz at bunkus.org
Fri Nov 18 20:21:38 CET 2011


> You're saying that the
> payload ("content") has the "Matroska unsigned integer
> representation".  This is not the same as simply "slurping bytes from
> the stream".

I'm saying that ONLY about the "position" element, not about the "seek
ID" element. Please read carefully what I'm referring to in each case.

> To follow through using your example, the question is specifically
> whether the content for the SeekID element is represented as "0x0F 43
> B6 75" vs. "0x1F 43 B6 75" (both assuming the size field of the
> element has the value 4).

seek ID content in the file = the bytes you see in the Matroska spec.
Meaning four bytes, "0x1f 34 b6 75", in that order.

Same is true for the "cluster" element's ID itself (the "cluster"
element, not the "seek ID" element). After having read an element ID
into memory you compare it with the bytes "0x1f 34 b5 75" in order to
know whether or not you've just read a cluster.

> I think what you're saying here is that, for the SeekID element, its
> content must have "matroska unsigned int" representation, the same as
> for the ID field and the size field.

No. The leading 1 is actually part of the ID and not only a marker for
the length of the ID. If this were "Matroska unsigned int
representation" then you would have to look for the byte sequence
"0x0f 34 b6 75" in the specs, but you won't find an element there.
Also note that the specs have a field in the EBML header called "max
ID length". Quote from the specs: "The maximum length of the IDs
you'll find in this file (4 or less in Matroska)." Therefore any of
the other representations you've listed are not valid.

> The size of the integer value
> implied by the first byte of the content (because the value in the
> stream has "Matroska representation") must match the size specified in
> the size field of the SeekID element.  Can you confirm whether this is
> the case?

For the "seek ID" element this is true. But why do you insist on
reading or treating the "seek ID"'s content as an integer?

> I also think that you're saying that for the SeekPos element, its
> content must have plain "unsigned int" representation, in network byte
> order.  Can you confirm whether this is the case?

The "Seek position" element is what the specs call "a basic EBML type
'unsigned integer'": (quote) "Unsigned Integer - Big-endian, any size
from 1 to 8 octets". The very same as e.g. the "cluster timecode"
element, the "track number" element, the "pixel width" element etc

Kind regards,

More information about the Matroska-devel mailing list