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

[Steve Lhomme <[e-mail]>]

2017-02-26 17:59 GMT+01:00 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".

But if the goal is to be played as a video, it should use the video
track type. And so it should probably use a V_SOMETHING name.

I don't think there's anything in the specs that forbid using your own
V_SOMETHING name. Adding V_MIME/your-mime/here may be a good idea
though.

> 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



-- 
Steve Lhomme
Matroska association Chairman