Subject: Re: [Cellar] TrackTypes for non-standard data formats

From: Steve Lhomme <[email-masked]>
Date: Sun, 21 May 2017 16:02:02 +0200

2017-04-29 22:20 GMT+02:00 Matt Gruenke <[email-masked]>:
> On Fri, Apr 28, 2017 at 8:37 PM, Dave Rice <[email-masked]> wrote:
>
>>
>> I sent a pull request for review at
>> https://github.com/Matroska-Org/matroska-specification/pull/117, which adds
>> this to the Codec Mapping page.
>>
>> ## Recommendations for the Creation of New Codec Mappings
>>
>> Creators of new Codec Mappins to be used in the context of Matroska:
>>
>> - SHOULD assume that all Codec Mappings they create might become
>> standardized, public, commonly deployed, or usable across multiple
>> implementations.
>>
>> - SHOULD employ meaningful values for Codec ID and Codec Name that they
>> have reason to believe are currently unused.
>>
>> - SHOULD NOT prefix their Codec ID with "X-" or similar constructs.
>>
>> These recommendations are based upon Section 3 of [@!RFC6648].
>
>
> It's important to note that while IANA deprecated the X- prefix, they
> replaced it with the Vendor and Personal trees.
>
> https://tools.ietf.org/html/rfc6838#section-3
>
>
>
> So, you can certainly say "don't use X_".  But, if someone has an encoding
> that doesn't fit any of the existing prefixes, then using "Y_" is just as
> bad (or worse).

Copying my reply to PR #117 improving the Codec ID definition:
In fact I would add that they must adhere to the nomenclature in the
Codec ID section found upper in the specification (which doesn't seem
to render nicely in HTML). For already known codec types they just
follow this rule and use a fancy name (previous SHOULD in this
section). For unknown codec types maybe it's better to seek for a
consensus before using a new codec type. Maybe there are good reasons
it's not there.

How about adding <A_|V_|...>EXPERIMENTAL/<WHATEVERYOUWANT> names
and/or <A_|V_|...>PRIVATE/<WHATEVERYOUWANT>? Should we add the 4 types
of custom IDs like in https://tools.ietf.org/html/rfc6838#section-3 ?
(vendor, personal, unregistered, external)

Also as a side note, GoPro just defined a "custom" track in MP4 for
precise GPS handling.
https://github.com/gopro/gpmf-parser

Now that I think about it, the track type would have been better as a
bit field. So for example when audio and video are mixed it would be
1|2 (3). And various common types of metadata would have a bit
(subtitle, teletext, buttons, gps, etc). That would avoid having all
kinds of types for all kinds of combinations... Right now the GoPro
track would fall in the category of "complex"

> Matt

-- 
Steve Lhomme
Matroska association Chairman