[MPlayer-dev-eng] Re: Common Opensource codec API

[ChristianHJW]

D Richard Felker III wrote:

> On Sun, Jun 29, 2003 at 11:36:52PM +0200, Guenter Bartsch wrote:
>>>>I was working with this kind of design before, but
>>>>nobody seemed interested in doing it. Basicly the
>>>>language of the API layer is immaterial, what
>>>>matters is the messages and data getting passed
>>>>through it (my system used a message/struct 2
>>>>parameter function for everything). 
 >>>>
>>>So we basically wrap this in CORBA then? ;)
>>
>>*lol* ... yeah, overengineering seems to be quite common in those
>>"do-the-right-thing-fixed-forever-joined-effort" style aproaches :>
> 
> This is beyond just "lol". It's more to the point of "let's commit the
> drone who wrote such madness to an asylum". At the risk of getting
> flamed, may I ask if the person who wrote this was a Matroska
> developer?

Toby is not a matroska developer. He is the developer of a codec called 
WARP ( http://corecodec.org/projects/warp ), and he was not capable of 
finishing the codec because he was fighting months with the crappy, 
limited and inflexible VfW API.
WARP needs an interface that does allow it to load a big number of 
frames into a huge buffer, as the main compression algo of WARP will 
work in the time domaine, means on the variation of a single pixel over 
a number of frames.

This codec is very unusual in his basic functionality and Toby had to 
fight with a limited codec API to be able to work with it, so you might 
think that the developer behind it would know how a codec API should be 
looking like to be future compatible.

After all, all our discussions are, again and again, basically going 
about the same matter :

You guys always want to keep things extremely simple and performant, and 
i have no idea why that is. Maybe you cant afford new PCs with 
state-of-the-art CPUs, and are running your boxes on AMD K6's or 
similar, dont know. I have a pretty old Pentium III system, only 800 
MHz, with a 32 MB 4xAGP videocard, and even with crappy, bloated Windows 
+ plus even more bloated, even more crappier matroska i was never ever 
close to have CPU performance problems. So, there seems to be a clear 
conflict of interests, for whatever reason.

matroska people are primarily not interested in the performance of our 
code, not at all. We are thinking 10 years ahead, and compared to the 
necessary decoding power to play a HDTV ( 1280 x 960 ) h.264 ( AVC, 
MPEG4-10 ) video, the CPU cycles you will need to parse a matroska file 
or to use a CORBA wrapped codec API, will just be peanuts, so why should 
we care at all .... ??



>>>Seriously: We need a simple little set of functions that a plugin needs to
>>>implement. If it is not dead simple, nobody will implement it.
>>>That was the important part: If it is not dead simple, nobody will
>>>implement it. And that goes for apps _and_ plugins.
>>
>>my point exactly. this is just about defining simple, easy-to-use apis
>>for various multimedia plugins/modules. i too think we should just
>>define a basic set of functions which each plugin type should support,
>>not more. the api should be extensible, though - both, individual
>>implementations should be able to add fields and functions as well as
>>there should be a possibility to add (probably optional) functions 
>>to the api in the future 
>  
> This is stupid. You can just wrap the code instead. A basic/dumb
> filter will be easy to wrap, and a more complicated one will not
> easily fit into a common api anyway.

Again the same conflict. In your 'boneheaded' concentration on 
simplicity and performance, you are prefering to have an API that cant 
deal with some special filters. For us, a filter API that cant deal with 
*ANY* possible filter we can think of today, is just crap. If it cant 
deal with today's filters, how could you expect the API to hold longer 
than 2 years, with respect to today's development speed ?

I cant get rid of my impression that at least *some* devs here are so 
proud they finally understood how MPEG works ( i dont ;-) ), they are 
now much too focussed on the MPEG way and how things are generally done 
today. You may call matroska bloated and non-performant. Well, maybe 
thats the case. However, i promise you matroska will be still here in 5 
years, it will be looking completely different than today as we had to 
adapt it to the needs of tomorrow, but all old files will still be 100% 
compatible thanks to the very flexible ( = bloated, in your opinion ) 
underlying EBML structure. We'll see ....

>>over the weekend i have looked through mplayer g2's and xine's stream/input
>>and demux module apis and found them to be quite similar - it should
>>definitely be possible to define a common interface here. i'm planning
>>to set up a little website documenting the two aproaches, maybe i'll
>>also look at other media players (not sure how many aproaches i'll be
>>able to keep in my mind simultaneously ;) ). hope this will be a good
>>starting point for a common api
>  
> There will be no common api, unless xine wants to adopt mplayer api.

Fortunately, you are not the one deciding this. I am glad the discussion 
was started again, mainly with respect to Atilla's planned video 
developer meeting in Switzerland next year. I sincerely hope that the 
conversation about a new API will not stop, and that we can move things 
forward until then.

If the mplayer people will not be interested to set up a specific 
mailing list for that, we will do so soon.

> Common api means the EXACT same thing as a common player. If mplayer
> and xine are using the same stream layer, the same demuxer layer, the
> same codec and filter layer, and the same output modules, then the
> ONLY difference between the two is the 10 lines of wrapper code in
> main.c to put it all together. This is beyond idiotic. MPlayer is
> better than the stupid windows crap because it _doesn't_ just wrap
> DirectShow with gui widgets, but instead implements everything itself,
> and does so much more efficiently and more correctly. 
> Rich

Yes, maybe. So finally Linux players could start to improve and try to 
offer all the functionalities that are standard in the Windows world 
since ages. Why that is ? Because the main playback function, however 
crappy and bloated it is implemented, is done nicely by DirectShow and 
player developers can concentrate on improving the user interface and 
add more features, like live capturing, playlists, timeshifting, remote 
control, etc . ....

Christian
matroska project admin
http://www.matroska.org