Subject: [Cellar] can Mandatory Elements be Empty Elements?

From: Dave Rice <[email-masked]>
Date: Mon, 23 May 2016 20:41:22 -0400

Hi all,
I’m not sure if this has been addressed but the EBML specification didn’t appear to make this clear. In some cases mandatory elements have no default defined, as is the case with MuxingApp and WritingApp. For instance here is an empty element for MuxingApp: 0x4D8080. Is it valid if an element like this is Empty? When I create an empty mandatory element that has no defined default, mkvalidator seem to mind.
Dave Rice

---

From: Michael Bradshaw <[email-masked]>
Date: Mon, 23 May 2016 17:59:02 -0700

On Mon, May 23, 2016 at 5:41 PM, Dave Rice <[email-masked]> wrote:

> Hi all,
> I’m not sure if this has been addressed but the EBML specification didn’t
> appear to make this clear. In some cases mandatory elements have no default
> defined, as is the case with MuxingApp and WritingApp. For instance here is
> an empty element for MuxingApp: 0x4D8080. Is it valid if an element like
> this is Empty? When I create an empty mandatory element that has no defined
> default, mkvalidator seem to mind.

>From the current reading, mandatory elements should be able to be empty
elements. In this situation, for UTF-8/String elements, the EBML spec says
the elements may declare any length from zero to `VINTMAX`, so an empty
value for MuxingApp/WritingApp should be considered as valid.

---

From: Dave Rice <[email-masked]>
Date: Mon, 23 May 2016 21:03:21 -0400

> On May 23, 2016, at 8:59 PM, Michael Bradshaw <[email-masked]> wrote:
> 
> On Mon, May 23, 2016 at 5:41 PM, Dave Rice <[email-masked] <mailto:[email-masked]>> wrote:
> Hi all,
> From the current reading, mandatory elements should be able to be empty elements. In this situation, for UTF-8/String elements, the EBML spec says the elements may declare any length from zero to `VINTMAX`, so an empty value for MuxingApp/WritingApp should be considered as valid.

Thanks. I agree. With all the requirements, this is the smallest valid Matroska file. Only 21 bytes!

0x1A45DFA380185380678B1549A966864D8080574180

The smallest valid webm file would be a little larger.

Dave Rice

---

From: Jerome Martinez <[email-masked]>
Date: Tue, 24 May 2016 09:19:15 +0200

Le 24/05/2016 à 02:59, Michael Bradshaw a écrit :
>     I’m not sure if this has been addressed but the EBML specification
>     didn’t appear to make this clear. In some cases mandatory elements
>     have no default defined, as is the case with MuxingApp and
>     WritingApp. For instance here is an empty element for MuxingApp:
>     0x4D8080. Is it valid if an element like this is Empty? When I
>     create an empty mandatory element that has no defined default,
>     mkvalidator seem to mind.
>
>
> From the current reading, mandatory elements should be able to be 
> empty elements. In this situation, for UTF-8/String elements, the EBML 
> spec says the elements may declare any length from zero to `VINTMAX`, 
> so an empty value for MuxingApp/WritingApp should be considered as valid.

I propose that MuxingApp/WritingApp should be optional, as it is not 
relevant for generic demuxing/parsing of the file and a muxer could 
avoid to fill it with empty data (or junk if we forbid empty mandatory 
elements, bad in both cases), or mandatory with "" as default.

Bonus: the tiniest valid file would be just 0x1A45DFA3801853806780.

---

From: Dave Rice <[email-masked]>
Date: Tue, 24 May 2016 09:16:18 -0400

> On May 24, 2016, at 3:19 AM, Jerome Martinez <[email-masked]> wrote:
> 
> I propose that MuxingApp/WritingApp should be optional, as it is not relevant for generic demuxing/parsing of the file and a muxer could avoid to fill it with empty data (or junk if we forbid empty mandatory elements, bad in both cases), or mandatory with "" as default.

Removing this requirement would reduce a tiny amount of space but cause a lot of confusion. Compared to other audiovisual containers, I'm glad that almost all Matroska files can be traced back to the tools used to create them. Also nearly every Matroska file follows the requirement and uses MuxingApp and WritingApp. Some Handbrake files do not follow the rule though.

> Bonus: the tiniest valid file would be just 0x1A45DFA3801853806780.

Not a very valuable bonus.
Dave Rice

---

From: Jerome Martinez <[email-masked]>
Date: Tue, 24 May 2016 15:24:28 +0200

Le 24/05/2016 à 15:16, Dave Rice a écrit :
>
>> On May 24, 2016, at 3:19 AM, Jerome Martinez <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>>     I’m not sure if this has been addressed but the EBML
>>>     specification didn’t appear to make this clear. In some cases
>>>     mandatory elements have no default defined, as is the case with
>>>     MuxingApp and WritingApp. For instance here is an empty element
>>>     for MuxingApp: 0x4D8080. Is it valid if an element like this is
>>>     Empty? When I create an empty mandatory element that has no
>>>     defined default, mkvalidator seem to mind.
>>>
>>>
>>> empty elements. In this situation, for UTF-8/String elements, the 
>>> EBML spec says the elements may declare any length from zero to 
>>> `VINTMAX`, so an empty value for MuxingApp/WritingApp should be 
>>> considered as valid.
>>
>> avoid to fill it with empty data (or junk if we forbid empty 
>> mandatory elements, bad in both cases), or mandatory with "" as default.
>
> Removing this requirement would reduce a tiny amount of space but 
> cause a lot of confusion.

A tool willing to hide without having an implementation checker failure 
will just put an empty string. You'll still get the confusion.

> Compared to other audiovisual containers, I'm glad that almost all 
> Matroska files can be traced back to the tools used to create them. 
> Also nearly every Matroska file follows the requirement and uses 
> MuxingApp and WritingApp. Some Handbrake files do not follow the rule 
> though.

And they are playable without problem. Not sure it is worth that an 
implementation checker says that the file is invalid in the case this 
piece of info is missing.
Maybe a "SHOULD" so we put a warning instead of an error in an 
implementation checker?

---

From: Luca Barbato <[email-masked]>
Date: Tue, 24 May 2016 15:39:29 +0200

On 24/05/16 15:16, Dave Rice wrote:
> cause a lot of confusion. Compared to other audiovisual containers,
> I'm glad that almost all Matroska files can be traced back to the
> tools used to create them. Also nearly every Matroska file follows
> the requirement and uses MuxingApp and WritingApp. Some Handbrake
> files do not follow the rule though.

The information is not trustworthy anyway.

If a file is readable w/out certain information it should stay optional
IMHO.

Usual warning:

"Relying on certain strings to enable quirk-modes is a recipe for a
disaster, please do not do that. If you want to support a quirk make so
you detect the quirk and fallback when possible"

lu