[Matroska-devel] Several (minor) issues or underspecified areas in the MKV spec

Steve Lhomme slhomme at matroska.org
Wed Oct 28 08:07:37 CET 2015


On 28/10/2015 01:14, Michael Bradshaw wrote:
> On Sun, Oct 25, 2015 at 1:10 AM, Steve Lhomme <slhomme at matroska.org
> <mailto:slhomme at matroska.org>> wrote:
>
>     ...
>
>
> Some follow up questions:
>
>  1. If the DocType spec (e.g. the MKV spec or WebM spec) doesn't define
>     a default value for an optional element, and that element is encoded
>     with a zero length, does its default value fall back to the EBML
>     spec (so it would be 0 for int/float types)?

If the element doesn't have a default value it should not be encoded 
with zero length. This is considered invalid. At least that's how it's 
currently supposed to be handled.

In real life libebml with use a value of zero. And I think it should be 
that way from now on. That allows a cheap way to save space in most cases.

>  2. BlockDuration defaults to TrackDuration, but there is no element
>     named TrackDuration. Is TrackDuration meant to refer
>     to DefaultDuration for the corresponding track (as referenced by the
>     block's header)?

Mh. That's odd. Theoretically yes. Except DefaultDuration is for a frame 
whereas BlockDuration is for a Block that can contain many frames. So if 
the Block corresponding to the BlockDuration contains many frames, it 
doesn't say if it's the Block or the frame.

This is mostly an issue for audio as video or subtitle frames are 
usually not grouped into a single Block.

It should be the duration of the whole Block. The idea is that the 
Matroska parser/demuxer/muxer doesn't need to parse inside the Block and 
see how many frames is in there and divide accordingly. As per our 
previous discussion that division is also an approximation for some 
codec anyway.

>  3. BlockDuration's description is kinda confusing. Specifically the
>     following sentence: "When not written and with no DefaultDuration,
>     the value is assumed to be the difference between the timestamp of
>     this Block and the timestamp of the next Block in "display" order
>     (not coding order)." If BlockDuration is not written, and there is
>     no DefaultDuration (thus it's not mandatory), I'm not sure it makes
>     sense to talk about its value and make assumptions about it. If it's

You're right.

>     not written it doesn't exist and can't have a value. I'm guessing
>     the sentence is trying to talk about how users can compute the
>     duration of the block, in which case I might suggest replacing "the
>     value is assumed to be" with "the duration of the block is". I think
>     this helps separate the distinction between the literal element
>     itself and the semantic value it's attempting to represent (the
>     BlockDuration element may not exist, but the semantic value it
>     represents (the block's duration) still does (philosophically
>     speaking) and can be computed).

I'd rather completely remove it. In the end you may have video with B 
frames (not in WebM) which timestamp order is not always growing. So you 
cannot even try to find the duration of the Block/frames that way. If 
you don't have the value, then you don't have it. That's all.

>
>
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>



More information about the Matroska-devel mailing list