[matroska-devel] Re: [UCI-Devel] Re: How UCI and Matroska could interact

Kondoros Attila cookieman_k at yahoo.com
Thu Jan 23 17:04:27 CET 2003


Hi!

You just wrote (almoust) the same scenario that I was
asserting in my very first email.I guess that this
must be the simplest scenario, and we must streave for
simplicity.

That was my impression too, that the countainers
should not be linked directly to the UCILIB (UCI is an
interface to codecs and on the other part interface to
the Application.)
Also in the UCI I do not see any thing that can be
used directly by the containers, but I maybe
mistaking... :( 
What UCI contains right now:
1. An interface to the "Applications"
2. An interface to the "Codecs"
3. -) missing (-: An interface to the "Containers" :(

Maybe a standard interface could be added to UCI that
would unify the containers too... An "Unified
Container Interface" per se. If this would be added
then the application could use UCILIB to enumerate/use
the available containers, and the Aplication would
only call UCI to handle the codecs and the containers.
This could be workable...
If every container would have it's own interface
exposed than the application must be modified every
time a new container becomes used by the users.

All in all, then matroska would have to adhere to the
(non existent) UCI container interface.

Am I talking stupid things here? What others think
about this?
B.R.
 Kondoros Attila


--- Cyrius <suiryc at yahoo.com> wrote:
> In my mind there were two parts :
> 1) the matroska (or any other) library, called by
> the
> program (editing tool, player, whatever) to read a
> file.
> 2) the UCI (or any other) API also called by the
> program to handle/decode the data in the file.
> 
> So in my mind the API wouldn't be directly linked to
> any container (e.g. matroska) because this would be
> strange (since UCI is meant to be 'universal' why is
> it linked to matroska or MCF ?, in this case it
> should
> be linked to any other container too).
> 
> Then what happens is that the program read data from
> the file, give the data to the library to get only
> the
> useful things.
> Those useful things include stream headers and codec
> specific data (if any). The information contained in
> the header (Video codec type, ...) are sent to the
> API
> (e.g. UCI) to know if there is an available codec to
> decode those data. If so the data are sent to this
> codec through the API, decoded and returned to the
> program (through the API again).
> 
> As I don't know all the background about
> matroska/MCF
> (and what was planned to be used before : Transors)
> maybe my idea is just wrong and then maybe Steve or
> John can explain here why and how the library
> (matroska for instance) and the API (UCI) should be
> linked :)
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up
> now.
> http://mailplus.yahoo.com
> 
> 
>
-------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =
> Something 2 See!
> http://www.vasoftware.com
>
===========================================================================
> Universal Codec Interface (UCI) maillist,
> UCI-Devel at lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/uci-devel
> http://uci.sourceforge.net/


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
http://matroska.org



More information about the Matroska-devel mailing list