[Matroska-devel] Re: EBML

[Steve Lhomme]

Martin Nilsson wrote:

> To instead invest a lot of time and effort into a lot of really clever 
> compatibility things in the standard, as we did in ID3v2, is not a good 
> way. It makes the standard really cluttered, hard to interpret and 
> implement and in the end it turned out that every new version had to be 
> incompatible anyway. So it's better to come clean up front and tell 
> everyone that the next version will be incompatible. If you don't want 
> to deal with it, use our lib.

The problem is that (almost) noone wants to use our lib (because it's 
C++) ;)

> What I do like to see is a reduced library dependency. To completely 
> support matroska I would have to support RSA and ECDSA. SHA1 and MD5.
> z-compression, bz-compression and lzo-compression. DES, 3DES, Twofish, 
> Blowfish and AES. To name a few standards.

Nop, because nothing is defined in this territory so far. And actually 
libebml+libmatroska just need a good C++ compiler, no other libraries.

> Similarly when something can be normalized into one unit or format I 
> think it should. Why allow for DisplayUnit to be both centimeters and 
> inches? Inch is _defined_ in centimeters. Or why have support for five 

I agree on that one. The authoring program can make the conversion anyway.

> different subtitle formats when two would be enough; One format which 

I don't agree on that one. We want to support as many codec as possible 
(audio, video, subtitles). We'll let the authors/users decide what they 
prefer. And that's why Matroska is getting successful you can use 
combinations that are otherwise impossible in other containers due to 
marketing/license pressures.

The problem you mention might be a problem for "standard" Matroska 
(hardware) players. Because they can't have an unlimited codec list. 
That's why we'll need to have some profiles for such players (and most 
of the time only a few format of audio/video/subs is actually in use).

> the textual formats could be normalized into (EBML based?) and one 

This already exists (theoretically) and is called USF.

> bitmap format (perhaps based on PNG with alpha channels?). I realize 
> that this is something that must have been up for discussion (sorry, I 
> have not had the time to read up in the list archive either), but I'll 
> just use these specific examples to back my general suggestion: reduce 
> dependencies, e.g. by disallowing things and normalizing data.

We have made the container codec independent (unlike OGG). So these 
dependencies are dealt elsewhere. Which doesn't mean we're not 
responsible for it...