Re: [Cellar] Bug in Matroska spec?

On 2021-05-09 8:46, Steve Lhomme wrote:
> Hi Paul,
> 
> For discussions on the format, you should email the IETF mailing list 
> [1] which is still very active for Matroska, FFv1, etc.
> You can also raise issues on GitHub [2] [3].
> 
> I'm posting this reply to the CELLAR mailing list as we will need to 
> discuss your points further in the community.
> 
> On 2021-05-02 14:56, Paul Foley wrote:
>> EBML RFC 8794, Section 5 states that
>>
>>     The bits of the VINT_DATA component of the Element ID MUST NOT be all
>>     "0" values
>>
>> however, Matroska defines the ChapterDisplay element with id 0x80,
>> which, unless I'm very confused, has all "0" values in the VINT_DATA
>> component(!)
> 
> You are correct. That's a very good catch !
> Not sure yet how we can get around this issue. ChapterDisplay is a 
> widely used element. We should probably issue an errata on the IETF 
> spec. Even the IANA registry table is bogus in that regard...

Issue https://github.com/ietf-wg-cellar/ebml-specification/issues/407

>> [I wrote code to read and write EBML/Matroska based on the RFC and
>> parsing ebml_matroska.xml from
>> {https://github.com/ietf-wg-cellar/matroska-specification}, but had to
>> ignore the "not zero" rule, and add stuff to the xml file because it's
>> incomplete. Specifically, EditionFlagHidden 0x45DB, ChapterFlagEnabled
>> 0x4598, ChapterTrack 0x8F, ChapterTrackUID 0x89 are missing, and
> 
> These elements have been moved out as they are specific to control track 
> which are unused right now. See [4]
> This is not ideal for code generators though. The 2 XML files should be 
> concatenated before being processed.

Issue https://github.com/ietf-wg-cellar/matroska-specification/issues/509

>> TagDefault's element id was obviously changed from 0x44B4 to 0x4484
>> (typo?) at some point; I have many files written before the change ...
>> should there be there with maxver set?]
> 
> 0x44B4 is a bug in old versions of libavcodec. Or maybe that's not where 
> it originates but it's referenced there:
> #define MATROSKA_ID_TAGDEFAULT          0x4484
> #define MATROSKA_ID_TAGDEFAULT_BUG      0x44B4
> 
> Since we are putting in the RFC what is currently used, we should 
> probably add it in the XML as you suggest. Probably with a maxver="0" 
> making the element invalid in any case (it should have never been used). 
> But as for other such elements, it will be listed in the RFC with some 
> explanation on how to interpret it if it's found. [5]

Issue https://github.com/ietf-wg-cellar/matroska-specification/issues/508

> This value is not present in libmatroska so VLC and mkvmerge won't even 
> read the element when found.
> 
>> I also note that
>> {https://www.iana.org/assignments/ebml/ebml.xhtml#ebml-doctype} has no
>> registrations: surely "matroska" and "webm" ought to be registered.
> 
> They are mentioned in RFC text [6] but not in the IANA registry. This 
> issue was raised during the RFC editor phase but I can't find any answer 
> to this. My understanding was that the "matroska" would be added to the 
> registry once the RFC for Matroska is ready. And the "webm" one should 
> be done by WebM people.
> I think the word RESERVED would mean something else. But maybe I'm 
> wrong. Ultimately we will add the "matroska" one for sure.
> 
> Thanks a lot for your very useful feedback!
> 
> [1] https://www.ietf.org/mailman/listinfo/cellar
> [2] https://github.com/ietf-wg-cellar/ebml-specification/issues
> [3] https://github.com/ietf-wg-cellar/matroska-specification/issues
> [4] https://github.com/ietf-wg-cellar/matroska-specification/pull/461
> [5] https://github.com/ietf-wg-cellar/matroska-specification/pull/487
> [6] https://datatracker.ietf.org/doc/html/rfc8794#section-17.2