[Matroska-devel] EBML specification component for review - Element Data Size
slhomme at matroska.org
Sat May 2 17:49:50 CEST 2015
On Fri, May 1, 2015 at 12:15 PM, Moritz Bunkus <moritz at bunkus.org> wrote:
> > > Element Data Size
> > >
> > > The EBML element data size is encoded as a variable size integer with,
> > > default, widths up to 8. Another maximum width value can be set by
> > > another value to EBMLMaxSizeWidth in the EBML header. See section 5.1.
> > What's the point of such a header?
> 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.
IIRC at least in mkvalidator I make such a check. Any reading app will
attempt to read the file even though the file says it shouldn't. At least
for Matroska which states that it will remain backward compatible.
> > 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
> > best.
> 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
> at all).
Unknown sizes are good for streaming with low latency. It was used for some
OSS live broadcasting. But I think the industry is going other ways with
WebRTC (low latency) or adaptive streaming (generic streaming).
Matroska association Chairman
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Matroska-devel