[xine-devel] Re: [gst-devel] Re: [UCI-Devel] Re: Common Opensource codec API

[Leif Johnson]

You all might find some inspiration in LADSPA, a pretty nice audio plugin
API hammered out on the linux-audio-dev mailing list : http://ladspa.org/.
It's written for audio plugins only, but I thought some of the concepts
might be helpful for more generic types of plugins.

leif

On Sun, 29 Jun 2003, 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 :>
> 
> > 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 
> 
> 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
> 
> guenter

--
Leif Morgan Johnson : http://ambient.2y.net/leif/