[Matroska-devel] EBML specification component for review - Element Data Size

Steve Lhomme slhomme at matroska.org
Sat May 2 18:08:55 CEST 2015

On Fri, May 1, 2015 at 2:46 PM, wm4 <nfxjfg at googlemail.com> wrote:

> I know, EBML was supposed to be generic and flexible, but I would say
> experience with Matroska taught us that this specific aspect is not
> really needed.

Over the years many people contacted us to use EBML in other formats. I
have no idea if they did or not. But I wouldn't say that EBML, with all its
nice features, is tied to Matroska. It's OK if it has features that will
never be used in Matroska.

> > > It also makes extending the format harder: in my understanding, if a
> > > sub-element has an unknown element ID, the parser can't continue.
> >
> > No, if a sub-element has an unknown element ID then the parser should
> > skip the element and ignore it.
> >
> > If new elements are introduced into a DocType format like Matroska that
> > a Matroska parser must parse in order to play the file then the
> > EBMLReadVersion must be increased accordingly.
> Well, that leaves a very tricky implicit definition of when writing an
> unknown length element is unknown. The Matroska spec on the website also
> doesn't mention anything about this (just that you should "avoid"
> writing unknown sizes), so I wonder what that says about existing
> practice.

As said in one of the proposed text, unknown size elements MUST be
master/list elements. They cannot be binary blobs or numbers. I don't think
it's written anywhere, but it should. Although as in a lot of case with
these unwritten rules, they are pretty obvious.

Steve Lhomme
Matroska association Chairman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20150502/dd1beb0b/attachment.html>

More information about the Matroska-devel mailing list