From: Cyrius <su...@ya...> - 2003-06-29 00:36:07
|
--- Toby Hudon <gl...@ma...> wrote: > From: "Toby Hudon" <gl...@ma...> > To: uci...@li... > Subject: Re: [UCI-Devel] Re: Common Opensource codec > API > Date: Sat, 28 Jun 2003 13:51:23 -0500 > ----- Original Message ----- > From: Ronald Bultje <rb...@ro...> > Date: 27 Jun 2003 15:13:14 +0200 > To: bar...@ra... > 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 |