[Matroska-devel] Re: Re: EBML

Paul Bryson paul at msn.com
Mon Mar 15 06:10:18 CET 2004

"Martin Nilsson" wrote...
> 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

Oops, I didn't notice that.  I guess that page is correct, but Steve would know
for sure.

> 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.

Yes, it is not even going to be in the Matroska 1.0 specs.

> 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.

> > 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
> > 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.

This needs to be clarified within the specs, so I'll try to mention it to Steve.

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.

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

> 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.

> 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.

This is very problematic and can only be solved by the use of profiles.  For
instance, if you have a Matroska file containing only attachments, the only
things you would have are the EBML headers, Segment, Attachement related
elements, and the SeekHead.  At this point, the EBML headers and the Segment are
the only things that can definately be said are required.

> 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.


More information about the Matroska-devel mailing list