- From: David Dorwin <ddorwin@google.com>
- Date: Fri, 10 Jan 2014 10:39:49 -0800
- To: Xiaohan Wang (王消寒) <xhwang@google.com>
- Cc: David Singer <singer@apple.com>, "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <CAHD2rsgTnOZ2_S5sgqeh1tHCci+EPdCZ32_9QP=XJCgSEHcU0w@mail.gmail.com>
I agree that the extra parameters are generally useful. In these cases, though, we just want to know whether the data came from a WebM or MP4 or etc. stream. Supporting both audio/mp4 and video/mp4 works - it's just unnecessary complexity in every UA and application. One option for eliminating that complexity would be to specify that when there are audio/ and video/ variants, the video/ variant should always be used. It seems likely that UA implementations might always do so for the needkey event anyway. At a minimum, we should disallow anything other than type/subtype so that simple string comparisons can be used. Does it make sense to reference RFC 2045 with something like the following? > contentType should be a '*type "/" subtype*' string as defined for > the Content-Type Header Field specified in RFC 2045 without any additional " > *parameter*" values. > <non-normative>That is, contentType should not contain 'codecs' or > 'profiles'.</non-normative> With the reference to "Content-Type", the attribute/parameter name "contentType" makes a lot of sense as the parameter/attribute name. Even though isTypeSupported() also accepts valid Content-Type values, I think we should revert the name of the parameter to |type| to differentiate the intended use and be consistent with canPlayType and MSE's isTypeSupported(). David On Wed, Jan 8, 2014 at 5:09 PM, Xiaohan Wang (王消寒) <xhwang@google.com>wrote: > If we decide to go with the proposed > createSession(DOMString initDataType, Uint8Array initData); > > Can we change the order of the two parameters so that we have > createSession(*Uint8Array initData, **DOMString initDataType*) ? > > It seems more natural to me to have (data, datatype) than the other way. > > Xiaohan > > > On Wed, Jan 8, 2014 at 9:53 AM, David Singer <singer@apple.com> wrote: > >> 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 Friday, 10 January 2014 18:40:37 UTC