Re: Several (minor) issues or underspecified areas in the MKV spec

On 28/10/2015 01:14, Michael Bradshaw wrote:
> On Sun, Oct 25, 2015 at 1:10 AM, Steve Lhomme <[email protected]
> <mailto:[email protected]>> 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
> [email protected]
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>

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