[MPlayer-dev-eng] Re: [MPlayer-users] Re: lavc-Options for *BEST*

[Steve Lhomme]

Michael Niedermayer wrote:
> Hi
> 
> On Saturday 08 February 2003 23:27, Steve Lhomme wrote:
> 
>>Alex Beregszaszi wrote:
>>
>>>if mplayer is so simple and little, why do you bother us?
>>
>>I just want to point out that I do use MPlayer (on Mac OSX)...
>>
>>Anyway we joined the discussion because :
>>- it has been brought to our attention that our work was badmouthed for
>>no apparent reason
>>- we are curious about what solutions other people can come with
>>regarding containers
>>- from what I've read I assume you're just creating something very
>>similar to matroska, so you might like to avoid reinventing the wheel
>>and contribute an existing project
> 
> 1. matroska is much too complex
> 	c++ lib

I've noticed during all the threads on your container that the first 
critic about matroska is that the core library is coded in C++. While I 
understand some people prefer their own languages for various reasons (C 
and C++ are very compatible AFAIK), I don't think that's what should be 
considered first about a container.

I remember the discussions between MCF and MPlayer some time ago where 
the conclusion was "then in MPlayer we'll code our own MCF parser". 
That's fien with me, even for matroska.

> 	xml whatever?!

Actuallt I noticed that what we called EBML seem to be close if not 
identical to what you call VLC (or TLV). And this is really a kind of 
binary XML.

> 	float types?!

What's wrong with floats ?
There are not many floats in the format. But there are where it makes 
sense !

> 	i even see SHA1+MD5+RSA+eliptic stuff mentioned?! why?

It's inside the signature element. So the use seems to be quite obvious.
We'd also like to have encryption inside the format. But we are no 
expert in that field. So it's not in the specs for the moment.

> i would like to know whats the advantage of using these, it would certainly 
> mean a 5-10x amount of time needed to support these in some simple 
> environments (embeded cpus with limited memory & slow cpu & no fpu, perhaps 
> with no available c++ compiler)

You probably skipped the Profile part of the specs then...

> there are many other formats (ogg,mpeg,avi,asf,nut :) ) which dont need these 
> so what can be done so much better with them?

ASF doesn't have DRM features ?
OGG is looking to have some too (have a look for OGGs).
VOB does have some encryption.

> it contains fields for forw / bakw reference frames, thats nice, but h264 uses 
> more then 2 reference frames,

We allow 1000 (or more) references for a frame and even overlapping of 
references, backward and forward. You probably had a wrong look at how 
it's done.

 > its allso not obvious why the container format
> needs to store these, i have the feeling that storing b frames in this will 
> be very very complex, i hope iam wrong

We would like codecs to give these informations to the container 
(although it's not currently the case anywhere). Because that allows 
some kind of check, reorganising, optimising, cutting at the container 
level without needing any codec installed. OH ! And I think some people 
mentioned fast seeking in the format.