[gst-devel] Fwd: Re: [UCI-Devel] Re: [matroska-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: [matroska-devel] Re:
> Common Opensource codec API
> Date: Sat, 28 Jun 2003 13:56:33 -0500


> ----- Original Message -----
> From: ChristianHJW <christian at matroska.org>
> Date: Sat, 28 Jun 2003 16:35:45 +0200 
> To: matroska-devel at freelists.org
> Subject: [UCI-Devel] Re: [matroska-devel] Re: Common
> Opensource codec API
> 
> BBB, can you invest a couple of hours and come up
> with a small doc 
> describing such a protocol, so it could be
> discussed on the lists that 
> have been involved and were expressing interest in
> such a solution ?
>

I can do this if you wanna hear about my design. I
still have most of it around.
 
> > >And just to state clearly: our final goal is to
> propose a standardized
> > >API or interface of how codecs, muxer/demuxer
> libraries etc. should look
> > >to be usable by our applications. It is not to
> define how a bytestream
> > >should look. ;). Just so I (and you) know what
> we're actually talking
> > >about.
> > >
> > Alex had the following plans for UCI :
> > 
> > UCI : codec API
> > UFI : filter API
> > UMI : muxing API, so that various containers could
> be used from 
> > supporting apps
> > 

See I think the different operations like filters
and muxing should just be subsets of the message
space. Because a filter is going to have some
redundant use with a codec, such as
getting/recieving frames, colorspace conversion,
etc. It makes sense to just have them all share the
same functions, and just restrict which
messages/structs are valid to send to a given object
based on if it's a filter or a codec or whatever.
General type objects could accept any message, etc.
One of the reasons I was advocating a system with
2-way communication at each level was to do things
like have an app request an operation that a filter
does not support, and have the filter propose an
alternate operation by calling back other parts of
the system for more info. Thus programmers would be
free to do what they think is best for their code to
serve each message request.


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