From: Cyrius <su...@ya...> - 2003-06-29 00:38:05
|
--- Toby Hudon <gl...@ma...> wrote: > From: "Toby Hudon" <gl...@ma...> > To: uci...@li... > 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 <chr...@ma...> > Date: Sat, 28 Jun 2003 16:35:45 +0200 > To: mat...@fr... > 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 |