[xine-devel] Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API
Guenter Bartsch
bartscgr at t-online.de
Sun Jun 29 14:38:10 CEST 2003
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
--
"Voraussagen sind ausserordentlich schwierig,
vor allem solche ueber die Zukunft." (N. Bohr)
More information about the gstreamer-devel
mailing list