Re: [Cellar] CodecIDs for non-standard and unregistered data formats

[Jerome Martinez <[e-mail]>]

Le 26/02/2017 à 17:29, Steve Lhomme a écrit :
> 2017-02-14 7:46 GMT+01:00 Matt Gruenke <[e-mail]>:
>> Related to my recent query about TrackTypes for non-standard data formats,
>> I'd like to discuss CodecIDs.  I had previously raised this issue, on the
>> matroska-devel list, and was advised to take it up, here.  In the interim,
>> my thinking on the matter has evolved.
>>
>> I wonder why not allow IANA Media Types (aka MIME types), as a sub-class of
>> CodecIDs?  Of course, the official Matroska CodecID would be preferred, for
>> all formats for which one has been designated.  However, this would enable
>> broader use of Matroska files, including for private, application-specific
>> data stream formats.
> The main goal of Matroska is multimedia interleaved/timestamped data.
> It's possible to have "complex" track and put in it whatever you want.
> If a timestamp is required. If it's not, using attachment is what you
> want and it already has a MIME type.
>
>> Perhaps a prefix like 'X_MEDIATYPE/' could simply be prepended to media type
>> names conforming with RFC 6838.  The value of TrackType would still
>> determine whether video, audio, or any other type-specific elements can be
>> used in such tracks.
> Although tempting I think it's better to avoid interleaving all kinds
> of stuff with audio/video. You could want to embed a "video/quicktime"
> but it would not be interleaved, or you'd need to parse/mux the data
> and then it's not a clean "video/quicktime" you get anymore.

I don't think this is the point.
Let's imagine we don't have any AVI compatibility layer (for whatever 
reason, e.g. lawyers convinced a country that BITMAPINFOHEADER / 
WAVEFORMATEX structure are patented), we have no other way for having 
e.g. AMR, G719, G729 and so on because it is not defined in native 
Matroska codec identifiers, but IANA media types have them (so a muxer 
could use "X_MEDIATYPE/audio/G729").
Consider Matt suggestion as similar to the AVI compatibility layer: this 
is just another way to define a codec identifier, also for 
interleaved/timestamped video and audio content.

Right now, I am thinking to TTML fragments (subtitles), instead of 
defining any TTML stuff in Matroska specs, 
"X_MEDIATYPE/application/ttml+xml" could be used and we rely on 
https://www.iana.org/assignments/media-types/application/ttml+xml .
For crazy ideas but we should not forbid crazy ideas :), someone may 
want to use PDF as a video format with one PDF page per video frame 
(similar to MJPEG), and instead of defining and requesting a "V_PDF" 
codec identifier, one would use "X_MEDIATYPE/application/pdf".

At long term, a potential decision would be to delegate codec 
identifiers management to IANA as they already do the job (for RTP and 
so on) in order to not duplicate efforts, and use Matroska list only 
when IANA does not fit Matroska needs, i.e. why should we care of having 
a spec about "V_MPEG4/ISO/AVC" (note: it is not on the codec spec page 
but a lot used) if we could rely on "video/H264" registration? (this is 
theoretical, "V_MPEG4/ISO/AVC" is already used. but we could do that for 
upcoming AV1 defined by IETF).

Jérôme