Simplifying how the initData format is identified (was: contentType: Are codecs allowed? Use a simpler string to identify the initData format?)

[I changed the subject to hopefully reduce confusion based on feedback in
the telecon this morning.]

The question is how we indicate the format of the corresponding initData
value in createSession() and the needkey event. (There is *no* proposed
change to the format of the isTypeSupported() parameter.)

During the telcon this morning, it was pointed out that the format is
defined by the relevant sections of the
spec<https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#containers>(currently
"Container Guildelines") and while these formats currently
correspond one-to-one to a container and related MIME type, this need not
be the case.^ There seemed to be some support in the telecon for specifying
the format identifier in the sections that describe the initData format.

As I noted earlier, we *could* use such a new identifier to specifically
identify the protection scheme in ISO BMFF and avoid the ambiguity or
generic solution being discussed in bug 17673.


^ If we choose not to use MIME type, we may need some way to detect what
format(s) are supported. However, we already have this issues with ISO
BMFF. Applications can query whether "video/mp4" is supported, but that
does not indicate whether "cenc" or some other protection scheme is
supported.


On Fri, Jan 10, 2014 at 4:46 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

>
> On 11 Jan 2014 05:41, "David Dorwin" <ddorwin@google.com> wrote:
> >
> > 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.
>
> Why not make this a quality of  implementation issue. You just need a
> regex that finds "/mp4" in the string and be done. Then users can use as
> much of the mime type as they want. Might be easier for js devs than having
> to manipulate the mime string to fit with what browsers expect.
>
> Just my 2c worth.
> Silvia.
>
> > 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.
> >>>
> >>>
> >>
> >
>