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

Steve Lhomme steve.lhomme at free.fr
Thu Jan 23 10:18:59 CET 2003

En réponse à Pamel <Paul at msn.com>:

> 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.

Mmmm. We already discussed the case of GLDM's codec (many frames packed in one).
But we didn't think of seeking at that time. And what you describe is impossible
with matroska (and other containers). A P frame has a backward reference. But to
decode the 31th frame you only need the data of that frame and the reference key
frame. If GLDM's codec really need all the frames in between, then we're not
talking about a P frame but something that doesn't exist yet. And so it should
be created and supported in matroska (and UCI).

In matroska there are 2 bits :
6 must P Frame - the frame depends on a backward frame (activate the prev timecode)
5 must N Frame - the frame depends on a forward frame (activate the next timecode)

And then follows the reference timecodes in the block (one for each bit).

That means we may need something more "complicated" and have multiple backward
and forward references. No bit would be required for that anymore. But the
reference timecodes should be extensible... like in EBML...

One solution I can see is that the Block element and BlockAdditional are grouped
into a master element BlockGroup that would contain both. And you would have to
read both to be able to render the Block... This was already the idea but they
were not grouped together (bad EBML design anyway). In this case, we can now
have as many backward and forward references in the BlockAdditional as needed.

That's a better design, but the drawback is that it will produce more overhead :
2 to 9 bytes (depending on the size of data) for each Block. So the Block size
would move from a 6-21 bytes range to a 8-30 bytes range... For high granularity
of data (a lot of small data packets) that means we would use more lacing than
in the previous case.

More information about the Matroska-devel mailing list