[Matroska-devel] Representation of payload for SeekHead entries
matthewjheaney at gmail.com
Fri Nov 18 19:54:23 CET 2011
On Fri, Nov 18, 2011 at 3:37 AM, Moritz Bunkus <moritz at bunkus.org> wrote:
> For the SeekID element the type is a binary, hence you do a dumb
> "read(buffer, element_size)" call on the file and slurp in a number of
> bytes. If the buffer contains e.g. the bytes "0x1F 43 B6 75" then you
> know that this seek head refers to a cluster element.
But that's exactly what I'm asking about. You're saying that the
payload ("content") has the "Matroska unsigned integer
representation". This is not the same as simply "slurping bytes from
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).
> The reason a binary is used is because the storage of an EBML ID is
> different than the storage of an unsigned integer (UTF-8 like variable
> length encoding vs known length, omit leading 0s). However, in
> practice an the storage of both look the same.
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. 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
Can the content of the SeekID element have any of these values?
0x08 0F 43 B6 75
0x04 00 0F 43 B6 75
0x02 00 00 0F 43 B6 75
0x01 00 00 00 0F 43 B6 75
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?
More information about the Matroska-devel