nfxjfg at googlemail.com
Mon Aug 3 19:12:16 CEST 2015
On Mon, 3 Aug 2015 17:58:50 +0200
Moritz Bunkus <moritz at bunkus.org> wrote:
> > - When is Element ordering important? Can EBML Elements be in any
> > order? I imagine having a bunch of Clusters in random order may make
> > playback difficult.
> For Matroska there are two aspects regarding order:
> 1. The level 1 elements: certain elements (track headers, segment info)
> should be found before the first cluster is found in order to enable
> playback. This is somewhat murky (e.g. linking via meta seek
The order is unimportant here. What matters is that a demuxer can find
them, without fully scanning the entire file. So if some elements like
tracks or tags come after the first cluster, they must be linked from a
seek head element before the first cluster. I'd say we should specify
that all level-1 elements that are not clusters, void, or crc elements
must be discoverable in this way.
It must also be specified that clusters form a single, continuous
segment. You can't have a chapters elements between two clusters.
> 2. The clusters should be ordered according to their timestamp in order
> to avoid excessive seeking (and streaming would also
> suffer). However, tiny clusters may actually violate that rule: the
> most extreme case would be a video track with B frames with a single
> frame per cluster. In that case the frame timecodes would be
> something like 0, 120, 40, 80… and so would the cluster
> timecodes. Those clusters would occur in the same order in the file
> violating this rule – but that would actually be OK.
> Otherwise the order is flexible.
This is unnecessarily vague, and I'd say even completely incorrect.
Packets must be in the order the encoder outputs them, and the decoder
expects them. Consequently, what is important is not necessarily the
order of timestamps.
The "Timecode" Cluster-subelement must come before any blocks, because
otherwise the demuxer would have to buffer blocks for completely
nonsensical reasons. (You can't feed packets to a decoder without
having the timestamp.)
It would also be completely ridiculous to demand that the demuxer does
any kind of reordering.
What you could do in theory is introducing timestamp resets between
ranges of packets. These would be equivalent to timestamp resets.
Expecting that a player somehow sorts "disjoint" ranges of the media by
their star timestamp is completely impractical; instead, such
timestamp resets would just reset the time display of the player, or
trigger timestamp rewriting in a remuxer.
(Also: "packets" vs. "blocks". I like "packets" better, because blocks
can further be sub-divided into lace elements, while a packet is the
unit a decoder takes as input.)
There are probably a bunch of other requirements that must be specified.
More information about the Matroska-devel