Re: [Cellar] Bug in Matroska spec?

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

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

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

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