[Matroska-devel] Representation of payload for SeekHead entries
matthewjheaney at gmail.com
Fri Nov 18 21:25:58 CET 2011
On Fri, Nov 18, 2011 at 2:21 PM, Moritz Bunkus <moritz at bunkus.org> wrote:
> 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.
Well now I'm doubly confused. I think you're saying that:
(1) The content of the SeekID is represented as a "Matroska unsigned
int" (but with a fixed length).
(2) The content of the SeekPos element is represented as a "basic EBML
type unsigned int".
>> 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.
I think you're saying that yes, the content of the SeekID element is
represented in the stream as a "Matroska unsigned int".
Can the value for a Cluster ID to be represented in the stream using
more than 4 bytes? Forget about what the Matroska spec says. Is it
valid, for example, for a Cluster ID to be represented as 0x01 00 00
00 0F 34 B6 75", if the EBML header says that element IDs are 8 bytes
> 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.
But IDs are represented in the stream using "Matroska unsigned int"
representation. Is it valid to use more bytes in the stream than the
values specified in the Matroska spec?
For example, are any of these equally valid ways of representing a
Void element ID?
0x20 00 6C
0x10 00 00 6C
0x08 00 00 00 6C
0x04 00 00 00 00 6C
0x02 00 00 00 00 00 6C
0x01 00 00 00 00 00 00 6C
> No. The leading 1 is actually part of the ID and not only a marker for
> the length of the ID.
But that's my very question.
You are not only saying an ID value is an integer with "Matroska
unsigned int" representation. You're making a stronger claim: that
this is a Matroska unsigned int" and it has a representation whose
size matches the EBML IDs listed in the Matroska spec.
Let's make another example. Suppose we have a SeekID whose content is
a Void element. (Weird but accept my premise for now.) Which of
these element values are valid? All of them, or only the first?
0x20 00 6C
0x10 00 00 6C
> If this were "Matroska unsigned int
> representation" then you would have to look for the byte sequence
> "0x0f 34 b6 75" in the specs,
Yes, that's what I do already. The Google parser for WebM
canonicalizes all Matroska integer values, irrespective of whether
they happen to be IDs or size fields (and, apparently, the content of
a SeekID element).
Certainly I write IDs using the values listed in the Matroska spec.
("Be conservative about what you write, but liberal about what you
read.") The question is how liberal a reader needs to be. As long as
the EBML header says that the max length of an EBML ID is 8 bytes or
less, then I'll parse any ID as if it could be represented using 8
You seem to be saying that a ClusterID represented any way other than
as 0x1F 34 B6 75 is not valid. But that's not my reading of the spec.
(Hence this post.)
> but you won't find an element there.
You will if you canonicalize the value you read from the stream.
> 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.
But does that apply to the values in the spec itself, or to any file?
If the file says in the EBML header that the max length of the IDs is
"8 or less", then does make the values in the file valid, if they
happen to be represented using a longer stream of bytes than the
values listed in the spec?
Consider the example for Void element above. Let's also assume that
the max length of the IDs is 4 or less. Then are all of the first 4
> 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?
Because it's an integer -- the same as all IDs!
But I'm confused about what the spec says about the representation of
the SeekID content.
The reason I'm confused is because the SeekID element has redundant
information. The size field of the SeekID element must match the size
implied by the value of the content field. There are no conditions
under which they could be different, n'est-ce pas?
But again you are saying something more, in the sense of an additional
constraint: not only does the SeekID content have a Matroska unsigned
int representation, but also that its size matches the values listed
in the Matroska spec. (My parser relaxes this constraint, but that is
a separate matter.)
> 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
OK, so the content for a SeekPos element does not have "Matroska
unsigned int" representation. I figured as such. My question is
mostly about the content of the SeekID element.
More information about the Matroska-devel