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

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.
>>
>>
>>
>