[Matroska-devel] Re: EBML

Martin Nilsson matroska at mani.user.lysator.liu.se
Mon Mar 15 01:15:28 CET 2004

Paul Bryson wrote:

> 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 and the 
signature complex. I dropped the signature stuff because I found it to 
complicated and underspecified to have in the core EBML, and I didn't 
feel like making a proper definition for it. 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.

> For "Appendix D.  Matroska DTD", the Chapters and Tags can each be nested
> several layers deep within each other.  Is there any clean way to indicate this,
> or am I missing it?

Yes, you just declare the insertion point as parent to the element you 
would like to nest. Tell me which elements can be nested how and I'll 
fix it.


Table := 81 container [ parent:Row; ] {
   Row := 82 container {
     Cell := 83 string;

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) Further it is possible to make the DTD even better 
by improving the cardinality of stuff. Pretty much all elements are 
optional as it is now.

> Is it necessary to define things such as how exactly a "Signed EBML Integer"
> works?

It doesn't hurt. I've added some more references now, though I can't log 
in to the webserver and update the one on the web for some reason...

> And only slightly related to this, is the EBML project ever going to be moved to
> Corecodec.org, or is it going to stay on SourceForge?

And somewhat related to that is how to proceed with this EBML 
specification. I will not update it further in substance exception for 
whatever feedback I get. I will finish my DTD verifier and combine it 
with my EBML parser so that it can validate EBML data against an EBML 
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...)

/Martin Nilsson

More information about the Matroska-devel mailing list