[Matroska-devel] Re: EBML

[Steve Lhomme]

Martin Nilsson wrote:

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

Well, there is no point in making a C wrapper at the moment. If one's 
platform has a C++ compiler, one can make a minimal wrapper with only 
the needed part (or even use C++ directly). If not the code won't 
compile anyway.

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

Well, OK. It *is* written in the specs but I'm not sure it's in use 
anywhere so far. We'll have to ask Jory who made an 
encryption/decryption filter in DirectShow. Otherwise we can probably 
safely drop them from that place and move it to the Matroska specs and 
not in the 1. freezed version.

>> And actually libebml+libmatroska just need a good C++ compiler, no 
>> other libraries.
> 
> 
> Not even libc? :)

I consider this as part of the compiler. Otherwise no code would ever run...

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

This is not true, because some subs format are in image formats. For the 
text based ones it's not even true neither. Because some formats support 
some features and others don't (outlines, fonts, icons, etc). That would 
mean *the* one we chose has to support everything and more. Of course 
USF is the closer.

>> This already exists (theoretically) and is called USF.
> 
> It's not good enough.

Then propose the missing parts. Because the format is still in alpha 
stage. I'm sure they will welcome any additions changes. (of course if 
you have the time to).