[Matroska-devel] validity?

Moritz Bunkus moritz at bunkus.org
Mon Aug 3 19:20:25 CEST 2015


Hey,

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

Not really. There's no reason to enforce the presence of meta seek
elements if all the other important level 1 elements are located before
the first cluster.

I guess that's what you actually meant.

> This is unnecessarily vague, and I'd say even completely incorrect.

Yeah you're right, the cases you've listed are important, too. I was
thinking about the order _within_ e.g. track, cues, meta seek heads,
attachments… Those don't matter, and demuxers must not rely on any
certain order within those elements.

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

I was talking about the order of clusters, not of the blocks of a single
track. As clusters contain packets of various differing tracks you
cannot impose an order on the clusters themselves that way, only for the
blocks belonging to a single track.

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

Correct.

> It would also be completely ridiculous to demand that the demuxer does
> any kind of reordering.

I areee for clusters and blocks agree, for other things (like the ones
mentioned above, even chapters should probably be sorted by their start
timecode within their hierarchy by the demuxer) I disagree.

Kind regards,
mosu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20150803/9aefbc79/attachment.sig>


More information about the Matroska-devel mailing list