W3C home > Mailing lists > Public > public-html-media@w3.org > January 2014

Re: contentType: Are codecs allowed? Use a simpler string to identify the initData format?

From: David Singer <singer@apple.com>
Date: Wed, 08 Jan 2014 09:53:59 -0800
Cc: "public-html-media@w3.org" <public-html-media@w3.org>
Message-id: <77D72C53-F1E5-496C-9851-B078AC1EF273@apple.com>
To: David Dorwin <ddorwin@google.com>
I am not sure that I agree here.

The reason that we use MIME types is that they have a registry and well-defined meanings.  I really donít want to use Ďcasualí names here, and I really donít want to invent another registry.

The extra parameters are absolutely useful for any of the many formats that are Ďgeneral containersí such as AVI, QT, MP4, 3GPP, and so on;  when you are determining, for example, if you can play a file, knowing (at least) the codecs in it is kinda important.  The MIME extensions (Ďbuckets RFC, 6381) was written for a good reason.

I am fine with restricting it to a simple type in contexts where thatís all that is plausibly needed, of course.

I donít think itís very hard to recognize both (for example) audio/mp4 and video/mp4, is it?

Am I missing something (and if so, I apologize)?

On Jan 7, 2014, at 18:17 , David Dorwin <ddorwin@google.com> wrote:

> [Note: |type| was renamed to |contentType| this morning to resolve bug 24213.]
> I have always assumed that contentType - as reported in the needkey event and passed to createSession() - would be a simple MIME type containing only the container type. For example, "video/webm" or "audio/mp4". However, I don't think the spec actually has this restriction.
> Such a restriction would make both browser and app implementations simpler (and slightly reduce confusion about the meaning of the values). I suppose it's possible that an app developer might want to pass the same codec-containing string to isTypeSupported() and createSession(), but at the cost of forcing all apps to parse the value rather than doing a simple string compare. Does anyone object to adding an explicit restriction?
> The use of "MIME type" also means that the needkey event could report either the audio/ or video/ variant regardless of the actual stream(s) in the media data. This is noted twice in the spec (example). Maybe this all would be simpler if we stopped using a MIME type and just passed the container name. such as "webm" or "mp4". The exact string to use would be specified in the relevant Container Guidelines. (We could potentially even use "cenc" and avoid the ambiguity discussed in bug 17673.)
> Given the intended values and use, I wonder if we should change the |contentType| attribute and parameter name to |containerType| or just |container|. |initDataType| is another option, since that's really what the value indicates. (This makes even more sense if we use just the container name as discussed above.) We could revert then isTypeSupported()'s parameter name to |type| to again be consistent with canPlayType() and MSE's isTypeSupported(), all of which accept full MIME types with optional codecs.
> If we made both changes, we would have the following signatures:
> static bool isTypeSupported(DOMstring keySystem, DOMString? type);
> MediaKeyNeededEvent.initDataType
> MediaKeySession createSession(DOMString initDataType, Uint8Array initData);
> Example uses:
> MediaKeys.isTypeSupported('org.w3.clearkey', 'video/mp4');  // Unchanged
> MediaKeys.isTypeSupported('org.w3.clearkey', 'video/mp4; codecs="avc1"');  // Unchanged
> if (event.initDataType = 'mp4') {...}
> MediaKeys.createSession(event.initDataType, event.initData);
> MediaKeys.createSession('mp4', initDataArray);
> Thoughts? Other suggestions?
> David

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Wednesday, 8 January 2014 17:54:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:44 UTC