[matroska-devel] How UCI and Matroska could interact

Pamel Paul at msn.com
Thu Jan 23 04:39:51 CET 2003


"Kondoros Attila" <cookieman_k at yahoo.com> wrote
> I'm not sure what is the direct connection between UCI
> and matroska. Is this supose to work in the following
> basic way? :
> 1. An UCI-aware application opens some codec through
> UCI.
> 2. Feeds its data to compress-it.
> 3. Then the compresed data is handled to matroskalib,
> to store it.
> And everything revesed for decoding, right?
>
> Or matroskalib will be called through UCI by the
> application? I'm not in clear with this...

In my head, I have a view of how things work together.  I'll explain how I
think it would all work out, and someone could correct me if I'm wrong.

For a playback application:

*  The UCI-aware application send UCI a message saying it wants to read file
XXXXX.zav and to return track information
*  UCI sends libmatroska a message saying to open file XXXXX.zav and return
track information.
*  Libmatroska opens the file and determines what tracks of what types
exists and returns this information to UCI.
*  UCI then returns the list of tracks to the application.
*  The application can also request other basic information such as author,
encode date, etc through the above process.
*  The application decides which tracks to play (probably through user
intervention) and tells UCI which tracks to play, and what timecode to start
at.
*  UCI then tells libmatroska the tracks to begin feeding out and what
timecode to start with.
*  Libmatroska then feeds out the Codec-ID and 'private codec data' for each
track to UCI.
*  UCI passes the 'private codec data' to each of the respective codecs to
initialize them.
(This is where it gets tricky and there is a good chance I'm off)
*  Libmatroska then passes out a block, along with the timecode, at (or just
before) the timecode specified for the specified track(s) to UCI.
*  UCI passes the block to the codec and requests a frame back.
*  The codec then passes a frame back to UCI.  (For video, an uncompressed
frame in whatever format is specified.  For audio, uncompressed audio in
whatever format is specified, though possibly just a passthrough for cases
such as passing AC3 to a reciever.  For subtitles, an uncompressed alpha
frame in (hopefuly) the same format as the video.)
*  UCI combines frames as necessary, such as the video with the subtitle
screen alpha blended over it.
*  UCI passes the frame to the application.
*  UCI requests the next timecode(s) for the appropriate track(s) from
libmatroska.
*  Libmatroska passes the next timecode, and block if applicable, to UCI.
*  UCI then passes the block, if it got one, to the codec and requests a
frame back.
*  The codec returns a frame, and UCI does whatever it did previously with
the streams.
*  UCI passes the frame to the application with the appropriate timecode

For cases where a seek is done to a P frame:

*  After UCI passes the timecode to libmatroska and requests a block,
libmatroska determines that it needs to render the 31 previous frames to
render this one P frame.
*  Libmatroska passes a variable to UCI indicating it needs to have 31
frames rendered to render the wanted frame.
*  Libmatroska then passes the first block (no timecode needed) to UCI.
*  UCI passes the block to the codec and requests a frame.
*  UCI discards the frame and requests the next block.
*  Libmatroska passes the next block to UCI and the process is repeated
until the needed block is passed to the codec and frame is passed back to
UCI.

For cases where a seek is done to a Null timecode.

*  After UCI passes the timecode to libmatroska and requests a block,
libmatroska determines that it needs to render block 31 timecodes previous
to render this null timecode.
*  Libmatroska passes a variable to UCI indicating it needs to have the
block 31 timecodes ahead sent to the codec to render the wanted frame.
*  Libmatroska passes the block to UCI.
*  UCI passes the blcok to the codec and requests the 32nd frame from the
codec.
*  The codec passes the appropriate frame to UCI.


In this, the 'null frame' is used where a single block would contain all
information for the next several frames.  In this case a timecode is stored,
for when to play back the next frame, but no data.

Okay, I didn't get to the part about how the encoder should work because I
need to leave now, but I will post that tomorrow.  It should be clear enough
now to be able to poke holes in my thought process now.


Pamel



http://matroska.org



More information about the Matroska-devel mailing list