[Matroska-general] EBML questions
steve.lhomme at free.fr
Mon May 14 13:40:29 CEST 2007
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
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 :)
>> 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.
More information about the Matroska-general