[Matroska-devel] Re: EBML

[Martin Nilsson]

Steve Lhomme wrote:

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

That should be OK for most people if the interface is easy to use from 
C. I took a quick look at libebml, but couldn't find a C header file to 
use. But it is true that some of the embedded systems lack C++ compilers 
(though it is usually possible to compile one).

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

I don't understand what you mean by that. These standards are listed in 
the Matroska specification. To, as I said, completely support Matroska I 
would need to support these standards. Perhpas libmatroska doesn't 
support these standards, but then the application will.

> And actually 
> libebml+libmatroska just need a good C++ compiler, no other libraries.

Not even libc? :)

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

Let's not confuse different kinds of encoding here. You can not convert 
between different video encodings without distorting the data. You can 
not convert between different audio encodings without distorting data. 
You however can convert between different subtitle formats without 
distorting data. That's why I think the long term strategy should be to 
get rid of as many subtitle formats as possible on the player side.

You can compare this to character encodings. There are about 1200 
different character encodings that I am aware of 
(http://www.iana.org/assignments/character-sets has the major ones). 
Given the big amount of code and data needed to support all these 
encodings you would prefer to keep that away from the end user and 
instead use e.g. UTF-8 for all data going to the user.

> 
> This already exists (theoretically) and is called USF.
> 

It's not good enough.

/Martin Nilsson