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

Dave Rice dave at dericed.com
Sat Oct 24 15:40:43 CEST 2015


> On Oct 24, 2015, at 9:28 AM, Steve Lhomme <slhomme at matroska.org> wrote:
> 
> 2015-10-24 1:44 GMT+02:00 Michael Bradshaw <mjbshaw at google.com>:
>> On Mon, Oct 12, 2015 at 10:10 AM, Michael Bradshaw <mjbshaw at google.com>
>> wrote:
>>> 
>>> On Sun, Oct 11, 2015 at 12:13 AM, Steve Lhomme <slhomme at matroska.org>
>>> wrote:
>>>> 
>>>> 2015-10-05 18:07 GMT+02:00 Michael Bradshaw <mjbshaw at google.com>:
>>>>> On Sun, Oct 4, 2015 at 6:43 AM, Steve Lhomme <slhomme at matroska.org>
>>>>> wrote:
>>>>>> 
>>>>>> On Sep 29, 2015 03:04, "Michael Bradshaw" <mjbshaw at google.com> wrote:
>>>>>> 
>>>>>>> What’s the point of default values for non-mandatory elements in the
>>>>>>> MKV
>>>>>>> spec? Why not make them mandatory if they have a default value?
>>>>>> 
>>>>>> You could set the element in the file if you want, but if it's the
>>>>>> default
>>>>>> value (likely a very common value) you don't have to write it, the
>>>>>> semantic
>>>>>> reader will get it.
>>>>> 
>>>>> 
>>>>> But is there any real difference between a non-mandatory element with a
>>>>> default value, and a mandatory element with a default value? The two
>>>>> seem
>>>>> effectively equivalent. If there's no meaningful difference, why not
>>>>> just
>>>>> make any element with a default value a mandatory element?
>>>> 
>>>> In the of mandatory, you don't even have to write it in the file at
>>>> all. Whenever you read the parent element, either it's there and you
>>>> read the value (if there's one) or you assume you have the default
>>>> value.
>>>> 
>>>> If it's not mandatory and not written, then you do not have the
>>>> element and its value. So if you want the element you have to write at
>>>> least the ID and a size of 0. Each time you want it.
>>> 
>>> 
>>> Interesting. The current EBML spec says signed/unsigned integers, dates,
>>> and float elements have the value 0 if their octet length is zero[1]. To
>>> make sure I'm understanding you correctly, you're saying that optional
>>> elements can have a default value (specified by the document spec) that is
>>> used if their octet length is zero (even if their default value is not 0),
>>> correct? If that's the case, could this be clarified in the EBML/MKV specs?
>>> I don't see that behavior mentioned in the MKV spec, and the EBML spec makes
>>> it sound like these elements always get the value of 0 (with no indication
>>> of other default values being possible).
>>> 
>>> [1]:
>>> https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown#ebml-element-types
>> 
>> 
>> Any clarifications on this point?
> 
> This is something that Dave added and that was not specificed in the
> original spec. I don't remember if it was debated or not to end up
> like that.

Yes there was some discussion on the PR, see this comment and the discussion around it.

My understand was that zero-length values default to zero, but elements that non-present and mandatory use their default value (if no default value and the element is mandatory and non-present, I suppose it's an error).

> That would break Matroska parsers as CueBlockNumber has a default
> value of 1 and is not mandatory. (CueRefNumber too but is deprecated)
> TargetTypeValue has a default value of 50.

Is this right?
CueBlockNumber element is present but with data size of zero indicates of CueBlockNumber of 0.
CueBlockNumber element is not present indicates of CueBlockNumber of 1 (default value).

> An element like Language has a default value of "eng" and is not mandatory.
> 
> Dave, can we fix this ?

Sure. Though I may need some clarification at how this thread can resolve with the discussion at https://github.com/Matroska-Org/ebml-specification/pull/17#discussion_r34961723 <https://github.com/Matroska-Org/ebml-specification/pull/17#discussion_r34961723>.
Dave Rice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20151024/87f3da02/attachment.html>


More information about the Matroska-devel mailing list