[Matroska-devel] EBML specification component for review - Element Data Size
moritz at bunkus.org
Fri May 1 12:15:04 CEST 2015
> > Element Data Size
> > The EBML element data size is encoded as a variable size integer with, by
> > default, widths up to 8. Another maximum width value can be set by setting
> > another value to EBMLMaxSizeWidth in the EBML header. See section 5.1.
> What's the point of such a header?
Do you mean the general EBML header or the EBMLMaxSizeWidth element?
You need a general EBML header in order to tell the parser which type of
content this file carries. Remember, EBML does not only carry
Matroska. It's similar to XML files where you need some namespace
declarations so that the parser can actually understand where the
element names come from and what they mean; in our case: so that the
parser knows what EBML ID 0x4711 is semantically.
EBMLMaxSizeWidth on the other hand is… Well… I guess it can be useful
for allowing even more element IDs if you ever invent such a crazy
format. It's good to be flexible here. I'm pretty sure, though, that no
existing parser has ever been tested with EBML IDs (and with
EBMLMaxSizeWidth by extension) being longer than four bytes, especially
as Matroska only uses four-byte long IDs.
> In the context of Matroska, I'd disallow unknown lengths in almost all
> contexts (i.e. disallow them by default, allow them only when
> explicitly specifified). Because they make demuxing a pain, and most
> Matroska demuxers probably support unknown length at a few places at
While this being true we have to be careful not to invalidate existing
files retroactively. Unknown sizes have been in the specs since the
beginning; changing them now is not something we should do on a whim (if
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Matroska-devel