[Matroska-devel] [proposal] new Matroska element CueRelativePosition
slhomme at matroska.org
Sat Sep 15 16:03:28 CEST 2012
I agree, although example 2 for Opus may be solved in a different way
(see my other email).
This element could mark BlockNumber as deprecated. I doubt it's ever
written by anyone and even less used for playback.
My main concern for such elements is that remuxing data inside a
Cluster would mean you also have to rewrite the Cues. But I don't
think there are actual cases where you do one without the other. And
even though, that's still doable.
On Fri, Sep 14, 2012 at 9:22 AM, Moritz Bunkus <moritz at bunkus.org> wrote:
> Here's another proposal for a new element:
> CueRelativePosition, child of CueTrackPositions (therefore sibling of
> - 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,
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
Matroska association Chairman
More information about the Matroska-devel