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

Steve Lhomme slhomme at matroska.org
Sat Oct 31 14:01:22 CET 2015

2015-10-28 17:44 GMT+01:00 Michael Bradshaw <mjbshaw at google.com>:
> On Wed, Oct 28, 2015 at 12:07 AM, Steve Lhomme <slhomme at matroska.org> wrote:
>> 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.
> And what about a mandatory element that's encoded with zero length? I assume
> they would work the same as optional elements: if a mandatory element has a
> zero length then its value is its default.

Yes, the same principle applies to every element with a default value.

>>>  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.
> Revmoving that text sounds reasonable to me.


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

Steve Lhomme
Matroska association Chairman

More information about the Matroska-devel mailing list