Subject: [Cellar] notes on Matroska.org's Specification Notes

From: Dave Rice <[email-masked]>
Date: Sat, 21 May 2016 20:37:19 -0400

Hi all,

These notes are specifically about http://matroska.org/technical/specs/notes.html which is now being worked on in the Matroska specification repository at https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/notes.md.

Here are comments and questions according to sections of https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/notes.md

Beginning of File:

The section notes "An EBML file always starts with 0x1A. The 0x1A makes the DOS command "type" ends display. That way you can include ASCII text before the EBML data and it can be displayed.” 

The concept of appending raw ASCII to the beginning of an EBML file is not part of the EBML spec. Is this feature intended to be a EBML feature or is it a specific feature of Matroska? Also I note that FFmpeg misdetects the format, when ASCII is prepended to the beginning of the file. VLC seems to work with ASCII at the beginning of the file. Is this feature used? IMHO, allowing potential garbage to be prepended to an EMBL or Matroska file should have more constraints if it is allowed.

Block Timecodes:

This section was discussed earlier as it states: "Blocks with a negative Raw Timecode are not valid.” Is this still considered to be true?

The phrases “Raw Timecode” and “timecode” are mixed here but is there any distinction? … Nevermind I see a definition of “Raw Timecode” later in the notes, I’ll re-order that section so that it precedes Block Timecodes.

Default decoded field duration:

The note for this Element says that it "can signal to the displaying application how often fields of a video sequence will be available for displaying”. But it is understand this correct the element is not about "how often” the field is available but for what default duration it is available. Is this right?

Is this field used at all during playback or it just here to allow for quick fps calculations? What are the consequences if this Element contains an incorrect value?

An example here uses the phrase "repeat_first_field = 1”, but in the context of a Matroska specification I’m not sure what this means.

Default Values and EBML Class: I suggest removing these sections and consolidating them into the EBML specification. Possibly in their place we can have a section which calls out specific parts of the EBML spec to read.

Matroska version:

There’s some language in this section about how a file with CueRelativePosition (a version 4 Matroska Element) could be used within a Matroska file and the DocTypeReadVersion could be set to 2 since  CueRelativePosition isn’t essential for playback. I think this approach leaves too much up to the judgement of the muxer. Should we have an attribute in EBML Schema that defines what DocTypeReadVersion should be used for a given Element? For instance, to have an official way to say how the use of any Element impacts DocTypeReadVersion?

Mime Types:
"There is no IETF endorsed MIME type for Matroska files.”
I’m curious how we could propose official MIME Types for Matroska.

Segment UID:
Here there’s a recommendation to use a computed MD5 of “some data parts of the file” as a unique id; however this doesn’t sounds like a good strategy to make a value that is “as unique as possible”.

Table Columns:
I think eventually this can be removed in favor of https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown#ebml-schema-element-attributes.

TimecodeScale Rounding:
The last paragraph has a broken link to https://www.matroska.org/technical/specs/matroska-tcscale.c. Is this needed or can the paragraph be cut?

I reviewed the Specification Notes document and send a pull request at https://github.com/Matroska-Org/matroska-specification/pull/12.
This contains two patches:

https://github.com/Matroska-Org/matroska-specification/pull/12/commits/feec6f43f289f917cdc7ba34c4e4dcd0dca231ec
cleans up some line breaks, spacing, and url issues from the html to markdown conversion.

https://github.com/Matroska-Org/matroska-specification/pull/12/commits/fb953df90731b2d56976c61333f4f62524d0ccb4
updates some of the vocabulary to EBML terminology and makes a few spelling and grammatical fixes.

Best Regards,
Dave Rice

---

From: Reto Kromer <[email-masked]>
Date: Sun, 22 May 2016 06:23:18 +0200

>I’m curious how we could propose official MIME Types for

IANA (Internet Assigned Numbers Authority) is the official
authority for the standardisation of media type
classifications:

  https://www.iana.org/assignments/media-types/media-types.xhtml

And they refer to:

  https://tools.ietf.org/html/rfc6838
  https://tools.ietf.org/html/rfc4855

Hope this helps! Reto

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Mon, 23 May 2016 06:38:53 -0700

> authority for the standardisation of media type

Specifically, RFCs which wish to update the IANA registry typically 
include an "IANA Considerations" section with details on what IANA is 
supposed to do.

For examples, see
https://tools.ietf.org/html/rfc5334#section-9 and
https://tools.ietf.org/html/rfc7845#section-10

---

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

> On May 23, 2016, at 9:38 AM, Timothy B. Terriberry <[email-masked]> wrote:
> 
> Reto Kromer wrote:
> Specifically, RFCs which wish to update the IANA registry typically include an "IANA Considerations" section with details on what IANA is supposed to do.
> 
> For examples, see

Thanks, is there any preference in the group between focusing mime types on EBML or the EBML DocType? Such as:

application/ebml; doctype=matroska
application/ebml; doctype=webm

vs

audio/matroska
video/matroska
video/webm

Also what is recommended for .mks?
Dave Rice

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Mon, 23 May 2016 14:34:39 -0700

> application/ebml; doctype=webm

Speaking as a browser vendor, I think experience has taught us that the 
latter is by-far preferred. The codecs= parameter is bad enough.