[MPlayer-dev-eng] Re: [xine-devel] Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API

[D Richard Felker III]

On Sun, Jun 29, 2003 at 11:36:52PM +0200, Guenter Bartsch wrote:
> hallo benjamin,
> 
> > > 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). If you set up
> > > all the data as XML-like structs with messages that
> > > tell you what you're expecting to see I think it can
> > > be done language and platform independant at the
> > > same time. Yes there will be some bloat from the ID
> > > overhead, but as long as you're passing frames and
> > > not say, individual pixels, it should be ok. There's
> > > no reason you can't pass video frames, config info,
> > > etc basicly as XML documents through an API designed
> > > to handle them.
> > >
> > 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?

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

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

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