[Matroska-devel] Re: EBML

[Martin Nilsson]

Paul Bryson wrote:

> The format is certainly not perfect, but it is to late to make major changes to
> the basic design as there is already to large of a user base.  Additions are the
> most likely thing to work.  There is actually a push to formalize a version 1.0
> specification so that changes can be made for version 2 or 3 featuring
> improvements, without breaking current tools.

I have not had the time to read through and evaluate everything 
carefully yet, but I'm really happy with most of what I've seen. One of 
the good lessons from ID3v2 was to put a lot of effort in making a well 
documented, easy to use, feature complete, cross platform library. If 
you do that, and keep the library able to handle all versions of your 
format, you are free to do pretty much anything with the format.

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.

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.

I don't think there is something wrong with deciding for the user in 
some of these issues. AES is proven better than the other cipher 
algorithms. SHA1 is proven better than MD5. The NIST reports are there 
for everyone to read, so there is really no technical reason to allow 
all of these algorithms.

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 
different subtitle formats when two would be enough; One format which 
the textual formats could be normalized into (EBML based?) and one 
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.

These are of course things that can be done at any time ("From version 7 
of matroska X is no longer allowed"). I can easily see why no one would 
like to have a generic subtitle binary format as blocker for matroska 
1.0, but the more dependencies we get rid of before 1.0 the better. The 
smaller libmatroska gets the less you'll have to pay for your 
matroska-aware DVD-player.

/Martin Nilsson