Re: [Cellar] shepherd review of Matroska: part 2

[Steve Lhomme <[e-mail]>]

On 2022-06-06 16:18, Michael Richardson wrote:
> 
> Section 6.1 says:
> 
> } The Info Element is the only REQUIRED Top-Level Element in a Matroska
> } file. To be playable, Matroska MUST also contain at least one Tracks Element
> } and Cluster Element. The first Info Element and the first Tracks Element MUST
> } either be stored before the first Cluster Element or both SHALL be referenced
> } by a SeekHead Element occurring before the first Cluster Element.
> 
> Since REQUIRED == MUST, and SHALL==SHOULD...
> 1) It seems that actually Tracks Element and Cluster Element are SHOULD.
>     Because, if they aren't playable, then they need not exist.
> 2) Are there examples where this makes sense to not have it?
>     (I'm assuming that transcoders, for instance are not players?)

There can be some chapter-only files (via chapter codecs). So without 
Cluster. Tracks is a little more tricky as a chapter-only file should 
probably have the same tracks as the previous/next files it references 
so the track selection is consistent.


> I would write:
>> The Info Element is a REQUIRED Top-Level Element in all Matroska files.

OK

>> Players MUST refuse to operate if the Matroska file lacks at least one Tracks Element
>> and Cluster Element.

Not so OK.

>> A valid Matroska has an Info Element and the first Tracks Element
>> before the first Cluster Element, or are both referenced
>> by a SeekHead Element occurring before the first Cluster Element.
>> Files which do not follow this pattern are unplayable.
> 
> (They are not invalid, because you said Info Element is only required..)

I'm not following this comment.

> } therefore, it is RECOMMENDED to use Void Elements as padding in between
> } Top-Level Elements.
> 
> This seems like really good implementation advice.
> I would not use the word RECOMMENDED here.
> 
> I would start a new paragraph:
>> Editing, removing, or adding Elements to a Matroska file often requires
>> that some existing Elements be voided or extended.
>> Transforming the existing Elements into a Void Elements as padding can be
>> used as a method to avoid moving large amounts of data around.

OK

> } 6.2. CRC-32
>> As noted by the EBML specification, if a CRC-32 Element is used, then the
>> CRC-32 Element MUST be the first ordered Element within its Parent
>> Element. The Matroska specification recommends that CRC-32 Elements SHOULD
>> NOT be used as an immediate Child Element of the Segment Element; however
>> all Top-Level Elements of an EBML Document SHOULD include a CRC-32 Element
>> as a Child Element.
> 
> It feels here like _The Matroska specification_ is some other document.
> I think it's *This specification*.  Is there an exception to this SHOULD NOT?

You could have one CRC per attachment, one CRC per TrackEntry (which can 
contain binary blobs), one CRC per BlockGroup, etc. It's really up to 
the creator to know what of safety s.he wants in the file.

> } CRC-32 Elements MUST NOT be used as an immediate Child Element of the
> } Segment Element;
> } however all *other* Top-Level Elements of an EBML Document MUST include a CRC-32 Element
> } as a Child Element.
> 
> or:
> 
> } All Top-Level Elements of an EBML Document SHOULD include a CRC-32 Element
> } as a Child Element, except for Segment Elements which SHOULD not have such
> } an Element.

Better, although it should be SHOULD NOT.

> } 6.3. SeekHead
> } If used, the first SeekHead Element SHOULD be the first non-CRC-32 Child
> } Element of the Segment Element.
> 
> What happens if it does not follow the CRC-32?

It should probably say MUST. My concern is that if we add an element in 
the future with even more importance than SeekHead, we break this rule.

> (Can there be more than one CRC-32?)

No, according to Section 11.3.1 of the EBML RFC.

> } It is RECOMMENDED that the first SeekHead Element be followed by a Void
> } Element to allow for the SeekHead Element to be expanded to cover new
> } Top-Level Elements that could be added to the Matroska file, such as Tags,
> } Chapters, and Attachments Elements.
> 
> This is interesting advice, can it also be collected into an Implementation
> Advice section?

That could be done. We have to collect all of them to put in there.

> Is there a recommended size?  32 bytes, 320 bytes? 2K? 16K?

Not really. I think each program uses its own, depending on what they 
know what will be put in there. We could give a hint though so people 
aren't left wondering.

> 6.4:
>> If the Cues Element is present, then it SHOULD either be stored before the
>> first Cluster Element or be referenced by a SeekHead Element.
> 
> the plurarity of "Cues Element" feels wrong.
> s/is/are/ ??

Cues is the name of the element. As a general rule, should we use a 
quote around element names ?

> 6.5 SHOULD seems okay.
> 6.6 SHOULD or MUST?

It's a bonus if the chapters are before the data. But in reality nobody 
does that. It also makes editing/expanding them harder. So it's just a 
bonus when a file is really finalized.

> } 6.8. Tags
> } The Tags Element is most subject to changes after the file was originally created.
> 
> also plurarity concern.

Same answer. Either we quote the element names, or we rename them.

> Sections 6.9,6.10,6.11 should be a new section about Optimum Layouts,

Indeed.

> with those orders as subsections, or perhaps a table.
> Some text is needed here to advise about which one to pick.

Yup

> And "from a muxer", is not the same as "for a muxer"

Yup

> Section 7, Unknown Elements should have the word "Version" in the heading.

You mean in the title section ?

> paragraph two of it is really quite critical, and maybe needs to be mentioned
> in the Introduction with a forward pointer.   Maybe combine with section 14.

Section 14 might be moved/merged with this. They should at least be 
close to each other.

> 
> 9.4.5:
>          s/undertermined/underdetermined/ ?

Yup

> section 9.5 would benefit from some examples, or references to some.

OK

> section 12 is inadequate for encryption.
> I don't mind if the section says that encryption is a topic of future work.
> (It's okay if we don't expect to have interoperable encrypted files)

Some of it has been deprecated. But some of it is actually used in WebM.
I think we need a section about it, maybe less broad/generic ?

> 13.2 Rotation.  Are values other than 0/90/180/270 supported?

Yes. For 360 videos, you could have any float values. The 0/90/180/270 
specific values may be useful for 2D values.

> section 15 looks like it might be a media-type registration.
> Probably just move that to section 25.3?

Isn't the IANA section only for things that will need IANA registry ? Is 
there a IANA registry for file extensions ?
At least Section 15 can be moved closer to 25.3 (probably after).

> section 16.2, maybe could be changed like:
> 
>       0                             1                             2
>       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  6  7  8  9  0
>       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>     0 |1A|45|DF|A3|8B|42|82|88|6D|61|74|72|6F|73|6B|61|
>                                                        18|53|80|67| -- Segment Element
>    20 |93|                                                          - Element Data Size
>           15|                                                       - start of Element Data
>              49|A9|66|8E|4D|80|84|69|65|74|66|57|41|84|69|65|74|66|
> 

OK

> If section 19 is non-normative (an example), then don't use BCP14 language.

There are two SHOULD and one MAY. I guess it's a guideline it doesn't 
have to be "normative" although it would be better if everyone follows 
the same rule.

> Section 20.4, are there IANA Considerations?

Same answer as with all the enums we define.

> 20.5.1 perhaps we need to say somewhere that the XML is not literal?
> that it's a representation of the EBML?

Yes

> Section 24 needs to say something about encryption, even if it's just that
> it's not fully specified, and subject to future work.

OK

> Are there things that a Matroska file could cause?  For instance, I see
> reference to system fonts... is it possible for them to be URLs or something
> would cause the player to reach out to some arbitrary place?
> (I think not, but it would be nice to summarize this)

I agree it's a little vague. Fonts can be either attachments, so fall in 
of the `Attachements` section of that paragraph. Or they can be 
referenced by name in a (subtitle) codec. We should say something about 
this. Although it's not in the Matroska file anymore but data handled by 
the codec.

> section 25.1, it's odd that the shorter ones are last, but whatever.

The larger ones (4-byte) are the most important ones. Then the 1-byte 
ones are supposed to be more common. IIRC I had trouble with generating 
this table with a fancy order, but I can have a look.

> I decided not to review section 26, the historic elements.
> Should the tbale in 25.1 say that more clearly that some items are historic?

Table 25.1 doesn't have any of the deprecated elements. That's why they 
don't have a reference to 26.1

> It can be inferred from the reference, but should it have an additional
> column?

They are two mutually exclusive tables/sections.

> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________
> Cellar mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cellar