[Bug 24873] Current isTypeSupported() definition does not provide sufficient information to applications

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24873

--- Comment #10 from David Dorwin <ddorwin@google.com> ---
With the introduction of initialization data type (bug 24951), we need to
somehow include this in the isTypeSupported() call.

I don't think we can just rely on the MIME type (e.g. "video/mp4") because
initialization data type allows multiple such types to be supported by a single
container. There is also the prospect of container-independent types, such as
proposed in bug 25269.

That seems to leave three options, both of which include an |initDataType|
parameter:
1) static IsTypeSupported isTypeSupported(DOMstring keySystem, *optional
DOMString initDataType,* optional DOMString contentType, optional DOMString
capability);
2) static IsTypeSupported isTypeSupported(DOMstring keySystem, *optional
DOMString initDataType, optional DOMString codecs,* optional DOMString
capability);
2) static IsTypeSupported isTypeSupported(DOMstring keySystem, *optional
DOMString initDataType, optional DOMString typeParameters,* optional DOMString
capability);

#1 is unchanged from the original proposal except for the addition of the
|initDataType| parameter. The MIME type in |contentType| is used similar to
canPlayType() (does the user agent support this container?). |initDataType| is
simply used to check whether |keySystem| can process initialization data in
that format. In general, |initDataType| would be one supported by the MIME type
container (or be container-independent). Codecs can continue to be specified in
|contentType|.

#2 replaces the MIME type-containing |contentType| with a |codecs| string that
only contains the value of the (optional) Codecs parameter from |contentType|.

#3 is a hybrid solution that replaces the |contentType| parameter with a string
containing only the RFC 6381 parameters (Codecs, Profiles). It would not
contain the the type and subtype type (container).


I lean towards #1 because:
* |contentType| is easily defined (RFCs 6838 and 6381)
* Applications are accustomed to passing the full MIME type, so retaining
|contentType| may be simplest for applications.

#2 has some advantages:
* Allows us to eliminate "content type" completely.
* Avoids redundant information and the potential for conflict between
|initDataType| and the MIME type.
But also disadvantages:
* It moves away from the standard MIME type supported by canPlayType() and
MSE's isTypeSupported() and already defined by RFCs.
* Other parameters, such as Profiles, are not supported. (I'm not aware of
existing support for these in browsers, but it does prevent future extension.)

#3 avoids the ambiguity, supports other parameters, and still somewhat relies
on an RFC, but it is non-standard.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 8 April 2014 19:24:41 UTC