[Matroska-general] EBML questions

Josh Green josh at resonance.org
Sat May 19 11:17:26 CEST 2007

On Mon, 2007-05-14 at 13:40 +0200, Steve Lhomme wrote:
> Josh Green wrote:
> > I noticed that Matroska files have the DocType as the first field in the
> > EBML chunk.  I think we should also have our DocType there (currently
> > its after the EBMLVersion and EBMLReadVersion), to ease file
> > identification.
> Well, a good code should not have problems with the position. But it's 
> surely safer to mimick matroska in that case.
> >>> We are currently breaking backwards compatibility with the CRAM spec due
> >>> to some other reasons, so I'd like to get things right this time :)
> >> OK.
> >>
> >> BTW what library do you use to write your files ? libebml ? something 
> >> you made yourself ?
> >>
> > 
> > The current CRAM implementation is part of libInstPatch
> > (http://libinstpatch.resonance.org).  We have our own routines for
> > handling the EBML, although its really not too complicated to begin
> > with.  It would be good to verify that CRAM is parsable by other
> > implementations such as libebml.  One of the reasons we are breaking
> > backwards compatibility, was because I had falsely assumed before that
> > all integers (even values in fields) were stored variable length
> > encoded.  After looking over a matroska file with a hex editor, I
> > realized that it isn't even necessary, since the size can already be
> > inferred from the EBML chunk.  *So embarrassed*  That of course wouldn't
> > have happened if I was using something like libebml.  Fortunately CRAM
> > really isn't widely (if at all?) used yet.
> If you want to try the implementation of your files you could pass the 
> file in mkvinfo (in mkvtoolnix). I think alexnoe also coded an EBML tree 
> browser in AVIMuxGUI (http://www.alexander-noe.com/video/amg/) (see "hex 
> viewer for EBML/RIFF tree"). And you can also try to load your files in 
> VLC (VideoLan Client) or in Media Player Classic to see if they assume 
> the files are matroska and fail to read them.
> Steve

Hello Steve,

I think at this point we have actually decided to use the CRC-32 for
some smaller information chunks, where it would be good to know if there
is something corrupted (file names for example).  The issue now is
knowing how to use the CRC-32 ([BF] chunk).  I see 3 seemingly
conflicting definitions of this:


I am assuming the 1st is likely the correct one.  In other words: the
CRC-32 chunk can appear anywhere in a master containing chunk and
applies to all data within that chunk.  At least that is how we are
planning on using it.  Thanks again for the clarifications.
	Josh Green

More information about the Matroska-general mailing list