[Matroska-devel] Re: Re: EBML

Steve Lhomme steve.lhomme at free.fr
Mon Mar 15 09:45:59 CET 2004


>>>A few quick questions, I had always thought that the CRC32 and Void elements
>>>were Matroska specific.  Is this the case, or are they in fact a part of the
>>>EBML spec?
>>
>>I obviously used the current EBML web page as basis for the
>>specification. I listed, besides the EBML header, CRC-32, Void
> 
> 
> Oops, I didn't notice that.  I guess that page is correct, but Steve would know
> for sure.

Void and CRC32 are indeed part of EBML.

>>Both CRC-32 and Void makes
>>sense in a general EBML perspective, so I let them stay. Though "my"
>>CRC-32 is different from the previous one (with different ID of course).
>>It's of course trivial to throw them out from the general context to
>>free some 1-byte IDs. Void is only useful in rewritable, big files.
> 
> 
> Void certainly makes sense, and I guess that CRC-32 does too.  However, if it is
> a general EBML element, it should probably be defined as what is already used.

They are both "services" for any EBML content and make sense to unify 
parsers with such features, regardless of the specific content of the 
file... Which doesn't mean you cannot add your own CRC in your format.

The Void element helps you correct any EBML file even if you don't 
understand the syntax.

The CRC32 let you have error detection that will be supported by all 
parsers (also helpful to know where an element can be voided).

> For the Tags:
> A SimpleTag always contains a single TagName and either a TagString or a
> TagBinary.  A SimpleTag can also contain another SimpleTag, which in turn MUST
> include a single TagName and either a TagString or a TagBinary.  A SimpleTag can
> contain any number of SimpleTag, and these levels can currently go to any depth.

MUST ? It cannot be void (just to indicate that the content exists with 
all "children" having the default value) ?

> For the Chapters:
> For Chapters I am a little unsure so I hope someone will correct me if I am
> wrong. A ChapterAtom always contains at least one ChapterUID and a
> ChapterTimeStart.  It can also contain a one or more ChapterAtoms.  Like the
> SimpleTag, there is currently no set limit to the number of ChapterAtoms a
> ChapterAtom can contain, nor the number of levels deep that they can be
> contained.

Correct.

>>Also note that the Matroska DTD says that the elements are ordered. I
>>assume that's not the case in reality, right? (Though it would be a very
>>good property IMHO)
> 
> 
> There was some debate about this recently, and I can't recall the outcome.  In
> many cases the ordering of the elements does not matter, however the way that
> the Blocks for different tracks is interleaved in Clusters, and the order that
> those Clusters are stored in will matter for smooth playback.  If I have time, I
> will search for that posting.  I know it is in the mailing list somewhere.

The order is needed for error correction (otherwise the CRC is wrong). 
But in the other hand when the nested EBML content is in memory (no CRC) 
the order should not matter... But in reality it imposes too much 
constraint on the parser like infinite memory. OK the CRC calculation 
also imposes this if you want to be able to handle *all* EBML files.

>>DTD. An EBML test suite is probably also a good idea, which I might
>>spend some time on after the draft has been officially accepted (which
>>brings the question who is to officially accept it...)
> 
> 
> I am really not sure.  At this point it would probably be Steve, but he has been
> busy and I guess that Christian could authorize someone else to accept it.

Well, a Matroska test suite would also be needed. And that's a *huge* 
task ! We need valid and invalid files that cover all possible cases of 
error/validity !

Right now I want to spend my time on coding other things (MPC).



More information about the Matroska-devel mailing list