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

[Cyrius]

--- Toby Hudon <gldm at mail.com> wrote:
> From: "Toby Hudon" <gldm at mail.com>
> To: uci-devel at lists.sourceforge.net
> Subject: Re: [UCI-Devel] Re: Common Opensource codec
> API
> Date: Sat, 28 Jun 2003 13:51:23 -0500
> 

----- Original Message -----
> From: Ronald Bultje <rbultje at ronald.bitfreak.net>
> Date: 27 Jun 2003 15:13:14 +0200 
> To: bartscgr at ra.informatik.uni-stuttgart.de
> Subject: [UCI-Devel] Re: Common Opensource codec API
> 
> What I'd love to see is the codec API not being an
> actual lib, but just
> a protocol, like X. Each application can then
> write it's own
> implementation code for this, and the codec API
> can, if wanted, provide
> a header file describing all structs (if any) etc.
> used in the protocol.
> Tying ourselves to one and the same lib likely
> won't work, even now
> we're already reproducing so much of the same
> code... Do people agree
> with this?


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.


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com