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

2015-10-24 1:44 GMT+02:00 Michael Bradshaw <[email protected]>:
> On Mon, Oct 12, 2015 at 10:10 AM, Michael Bradshaw <[email protected]>
> wrote:
>>
>> On Sun, Oct 11, 2015 at 12:13 AM, Steve Lhomme <[email protected]>
>> wrote:
>>>
>>> 2015-10-05 18:07 GMT+02:00 Michael Bradshaw <[email protected]>:
>>> > On Sun, Oct 4, 2015 at 6:43 AM, Steve Lhomme <[email protected]>
>>> > wrote:
>>> >>
>>> >> On Sep 29, 2015 03:04, "Michael Bradshaw" <[email protected]> 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.

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.

An element like Language has a default value of "eng" and is not mandatory.

Dave, can we fix this ?

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