[Matroska-devel] Representation of payload for SeekHead entries

Moritz Bunkus moritz at bunkus.org
Fri Nov 18 21:39:02 CET 2011


Well, I'm giving up because I honestly don't have the answer. Maybe
Steve Lhomme does.

The only thing that still comes to mind is that reading an element ID
and an element size is not the same, nor is the result the same from
the application's perspective (the "application" being the layer above
EBML, in this case Matroska). If an EBML parser reads a single byte
"0x81" as an element ID then it has to pass "0x81" to the layer above.
If it reads that same single byte "0x81" as the element's size then it
only passes "0x01" to the layer above.

Therefore there can only be two cases:

a) The byte sequence "0x40 01" represents a different EBML ID than the
byte sequence "0x81" does or
b) An EBML parser has to normalize element IDs to their shortest
possible representation before passing it upstream in which case "0x40
01" and "0x81" would be the same ID.

I guess b) is the intended case, but like I said I don't actually have
a definitive answer.

If the WebM parser already normalizes upon reading then I'd say just
leave it like it is. Accept as much weird cases as possible but only
write the byte sequences explicitly listed in the specs.

Oh and BTW:

> 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
> or less?

Valid to what? Either I should forget about the specs in which case I
don't have any basis to decide whether or not something is valid or I
can say it is valid (or not) according to the specs ;) Just

Kind regards,

More information about the Matroska-devel mailing list