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

[Toby Hudon]

----- Original Message -----
From: Benjamin Otte <in7y118 at public.uni-hamburg.de>
Date: Sun, 29 Jun 2003 22:08:32 +0200 (DFT) 
To: Cyrius <suiryc at yahoo.com>
Subject: Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API

> On Sat, 28 Jun 2003, Cyrius 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). 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? ;)
> 
> 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.
> 
> Benjamin
> 

Is one function simple enough? ;)

Seriously, do(UINT msg, pDOC data); That's it. Internal switch on the message to handle the data if needed. If you don't support a given message in the API, you go to the default case which is return(0). Whoever called you has the job of handling an unexpected return(0), such as trying an alternate method, and if they can't they also return(0) and pass it up the call stack until it gets to the application, which either decides to try something else or returns a message saying not supported or error or whatever is appropriate.

All components (by component I mean a generic object for the API that can be a container, filter, codec, muxer, etc) support this one function. The only other function in the entire API so far is the function to create a component based on information. I.e. the application sees it needs a codec to handle "XVID" output from the container component it just made. It performs a lookup (I'm still working on the exact details of how best to do it) and finds that it points to a DLL that handles this. It then calls an API function that creates the component associated with that dll, i.e. Component my_decoder = CreateComponent("xvid_x86.dll");

That's it, two functions. The complicated part is in defining the messages and their data, but as long as each component is only required to support the messages it can do something with, and not handle exceptions, it should be easy for component developers.

If you have a simpler idea please let me know, and BTW what is CORBA?
-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup