[Matroska-devel] [proposal] new Matroska element CueRelativePosition

Moritz Bunkus moritz at bunkus.org
Fri Sep 14 09:22:15 CEST 2012


Hey,

Here's another proposal for a new element:

CueRelativePosition, child of CueTrackPositions (therefore sibling of
CueClusterPosition)
- not mandatory
- not multiple
- unsigned integer
- no default value (meaning "relative position is unknown if element
is missing" and NOT "relative position is 0 if missing")
- ID: 0xf0

Description: "The position of the block inside the cluster."

Rationale: At the moment seeking to a particular block requires
seeking to the cluster the block contains for two reasons: First, the
ClusterTimecode element has to be found. Second, the block's actual
position inside the cluster is unknown. A splitter usually finds the
ClusterTimecode as the first child in the cluster, but then it still
has to scan all children up to the required block.

With this proposal reading the ClusterTimecode would not change.
However, a splitter could then seek directly to the required block
skipping all the elements in between. This would speed up seeking
quite a bit.

Such a change becomes even more important if one considers two other things:

1. Subtitles. If the player wants to display the subtitles that should
be active directly after seeking it will have to retrieve the subtitle
block as well. This subtitle block might be contained in a different
cluster than the video block to be shown. Without this proposal the
worst case would mean a splitter would have to scan nearly two whole
clusters in order to find the track.

2. Advanced audio codecs like Opus. The new Opus codec requires a
certain preroll: the codec needs to be fed a certain amount of data
before it can start output properly decoded data after seeking.
Therefore in order to start playing from timecode T the codec would
need data starting from "T - preroll". This situation is similar to
the subitle situation: the required blocks might be located in a
different cluster which would require scanning another whole cluster
at worst.

Kind regards,
mosu


More information about the Matroska-devel mailing list