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

Steve Lhomme <> Sun, 12 June 2022 08:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66820C14F735 for <>; Sun, 12 Jun 2022 01:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.781
X-Spam-Status: No, score=-3.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.876, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y9C0imjbEy-g for <>; Sun, 12 Jun 2022 01:44:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::332]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id B3CBBC14F738 for <>; Sun, 12 Jun 2022 01:44:59 -0700 (PDT)
Received: by with SMTP id c130-20020a1c3588000000b0039c6fd897b4so45691wma.4 for <>; Sun, 12 Jun 2022 01:44:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=36S3ZAMuZZ359xnQ7bDVsKoGQvhnmdeAxMlYkRrc1Lw=; b=xAOc4GVlDGrWXqLmExmvV7Lm/LPREdl/gu7opOenaei3hmPv4R6WXKWwCoUDKtTk3J U3Anh1qTBkbwRz2tJ8yWTrfTD1pW6oqsCfjBJ9XSwZbqTVvVnCeA3CD7coNSDyVFDgjf rp1Dy+zKWuZkIQCF6V8DLjvXUrMr5OmrZ4pXoRVDdDjkuLpVCZaqk3l4NvvUBspk3tje X2ZPA0AUtOy8+rTBMLIhoeYQYUw8nY+w0Sok2A74sk/ID3GmiSrb28X5fvk9yaiKXUE5 yRWC835fWeJ9UKADLSL9+JR1oI+BmUurKShyAfzKnr/x5z3ialXG/n3cUO2yhtG1/rRh FXbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=36S3ZAMuZZ359xnQ7bDVsKoGQvhnmdeAxMlYkRrc1Lw=; b=bSSaSeCkGhmeb9ux8ZcOcb6mAYKS5DfNv2+UJdXbe2y6TwmGPHts7ykl7n/8FUOP9I bGNsux5H+GfqJxO7zVJY4uu+2SHuois7zS7Ihnu8z8RDy/NWWs5bwLOEP6hlCvPpXLlN L7rc0oeMcCvZtVW45aWtlw/6Rzxivh03IGBdg1v3BAHnQPaufyYIlDNJ1pXxekm3RiGq AE6WAn3bB96b5Z+rEO6lMnNLsxC/QDy1qSf1CAuZN03DtBBFHV0pUI04M9DCS8hzGGHY WEpTabI/+TMArlacOMzByYHBEYAHn2Pkj32GG4o7v3MAWN0UD+CfVPXchMjmK7iPyfWo Vj7Q==
X-Gm-Message-State: AOAM531yTDFnkT84frlEPsqGj5RSU/xl2IoSxUt4jHMwjb6op+yXrM/K iQADVGF5tvE1bcrBYTRzk/ykFxtyhF/vjQ==
X-Google-Smtp-Source: ABdhPJy06NStOCTA8wLYB/sl7D67JHdme6tYwjeQaSdu0uctfSN8egSTVcblzNOLZNRiqmv2U0ggYg==
X-Received: by 2002:a7b:c015:0:b0:397:3685:5148 with SMTP id c21-20020a7bc015000000b0039736855148mr8446346wmb.174.1655023497739; Sun, 12 Jun 2022 01:44:57 -0700 (PDT)
Received: from ?IPV6:2a01:cb0c:20:e900:810b:2a63:bdf1:10fc? ( [2a01:cb0c:20:e900:810b:2a63:bdf1:10fc]) by with ESMTPSA id g7-20020a5d4887000000b002184a3a3641sm4837229wrq.100.2022. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Jun 2022 01:44:57 -0700 (PDT)
Message-ID: <>
Date: Sun, 12 Jun 2022 10:44:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
References: <1216608.1654521891@dooku> <1219750.1654525107@dooku>
From: Steve Lhomme <>
In-Reply-To: <1219750.1654525107@dooku>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Cellar] shepherd review of Matroska: part 2
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 12 Jun 2022 08:45:03 -0000

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


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


> } 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,


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


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


> 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/ ?


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


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


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


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


> 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  [
> ]        |   ruby on rails    [
> --
> Michael Richardson <>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
> _______________________________________________
> Cellar mailing list