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

Pamel paul at msn.com
Thu Jan 23 17:41:05 CET 2003


"Steve Lhomme" <steve.lhomme at free.fr> wrote
> En réponse   Pamel <Paul at msn.com>:

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

It is not 'impossible' with matroska.  Thats the point of matroska, you just
add another EBML element.

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

This could be done using P frames as it would request frames back until it
got to the keyframe.  I just think that its silly to use this 'workaround'
when matroska could be easily extended to accomodate this new structure.
The P frames idea is basicaly tricking the interface to work with the codec,
but the extra work is being done and extra transfers of information.  Why
not just define a way to do it that is what the codec needs.

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

I agree.

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

How about one of these?  Let the BlockAdditional be another element on the
same level as Block.  But BlockAdditional just contains sub-elements such as
timecode(s), track#, and where the block with the information is located.
This would mean there is 0 overhead for cases where these are not used.  Or,
could you just make BlockAdditional a sub-element of the existing Block
design?  So, again, it would not be taking space in cases where it is not
used.  This would have the added benefit of all relevant timecodes being
under the keyframe.  So, if a seek was done inbetween two timecodes, it
would go to the first one, see that there were sub-timecodes, and use the
most accurate one.


Pamel



http://matroska.org



More information about the Matroska-devel mailing list