[Matroska-devel] Clarification on CueRelativePosition

Bernie Habermeier bernt at wulfram.com
Fri Jul 19 03:45:58 CEST 2013

I'm implementing a matroska based video player, and would like to make use of CueRelativePosition for fast seeking, but I'm a bit confused by the specification.

From the documentation, a CueRelativePosition does this:

	The relative position of the referenced block inside the cluster with 0 being the first possible position for an element inside that cluster.

But the Cluster contains a BlockGroup, which in turn contains a Block.  To really make use of a Block, you'd need the BlockGroup, given that the BlockGroup may contain information vital to the use of the Block itself, such as the BlockDuration.

Having said all that, it appears that my use case uses SimpleBlock vs. BlockGroup/Block.  Would the CueRelativePosition point to the SimpleBlock?  

It was my impression that the order of the child elements of a Cluster is not specific, so I do also wonder about the implicit nature of hoping that the first child of the Cluster is TimeCode, which is certainly needed to make use of any block data.

Also, the second half of the description is vague:

	with 0 being the first possible position for an element inside that cluster

This implies two things:

	1) if 0 is the first possible position for the block in the cluster, I would assume the TimeCode is not the first child, because it would in fact be a SimpleBlock
	2) we're talking about SimpleBlocks, because if we are talking about Blocks, then a 0 byte offset for the Block itself is impossible given that a Block sits inside of a BlockGroup

Overall, how to make good use of the CueRelativePosition is unclear to me.  From a standards perspective, if in practice a certain ordering of EBML child elements is practical, it would really be beneficial to lock the positioning down for some elements.

In interest of fast seeking, and because I'm in control over how I encode the video files that will go to my video player, it has been suggested that an easier implementation would be to simply force the start of a new Cluster.  Of course, in this use-case I would suppress generating cuepoints where I knew I didn't need to implement a fast seek point (which in my particular use case I certainly do).  If a cuepoint starts at the beginning of a new Cluster, the remaining implementation because quite easy.  In doing so, I can actually avoid using CueRelativePosition.

Bernie Habermeier

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20130718/8586cb30/attachment.html>

More information about the Matroska-devel mailing list