--- Toby Hudon <gldm@...> wrote:
> From: "Toby Hudon" <gldm@...>
> To: uci-devel@...
> 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@...>
> Date: Sat, 28 Jun 2003 16:35:45 +0200
> To: matroska-devel@...
> 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!
From: Ronald Bultje <rbultje@ro...> - 2003-06-30 07:22:51
On Sun, 2003-06-29 at 02:38, Cyrius wrote:
> See I think the different operations like filters
> and muxing should just be subsets of the message
This was my idea exactly. The muxing/codec operation subsets themselves
should be described in the protocol, too, but shouldn't introduce any
new features or methods, they should just implement a specific way of
using the generalized methods for their specific task.
> 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.
Let's first keep it simple. ;).
Ronald Bultje <rbultje@...>