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

2015-10-28 17:44 GMT+01:00 Michael Bradshaw <[email protected]>:
> On Wed, Oct 28, 2015 at 12:07 AM, Steve Lhomme <[email protected]> wrote:
>>
>> 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.
>
>
> 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.

Done

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



-- 
Steve Lhomme
Matroska association Chairman
_______________________________________________
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