Re: EBML specification component for review - Element Data Size

On Fri, May 1, 2015 at 2:46 PM, wm4 <[email protected]> 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

_______________________________________________
Matroska-devel mailing list
[email protected]
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel