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

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

            Bug ID: 24873
           Summary: Current isTypeSupported() definition does not provide
                    sufficient information to applications
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Encrypted Media Extensions
          Assignee: adrianba@microsoft.com
          Reporter: ddorwin@google.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

*** Summary ***
I propose changing the isTypeSupported() signature from:
  static bool isTypeSupported(DOMstring keySystem, optional DOMString
contentType);
to:
  static IsTypeSupported isTypeSupported(DOMstring keySystem, optional
DOMString contentType, optional DOMString capability);

Note the change in the return value and the addition of an optional
|capability| parameter.
(There is ongoing discussion of the format of |contentType|. This proposal may
change as appropriate to accommodate the specification of Initialization Data
format and codecs.)

This addresses at least three use cases:
1) Providing a clear indication of the capabilities without any assumptions or
implied rules.
2) Applications can immediately provide the best supported streams without
waiting for the license exchange.
3) Platforms that cannot provide an immediate definitive response can replay
“maybe”, acknowledging the combination but telling the application to check the
license request for a definitive answer on availability.

Without such changes, applications will likely need to rely on user agent
string checks or provide a degraded experience.


*** Introduction ***
The purpose of isTypeSupported() is for applications to be able to select a
media stream and key system combination that the client supports. The spec
currently says, "The isTypeSupported(keySystem, contentType) method returns
whether keySystem is supported with the specified container and codec
contentType(s)” but does not define "supported".

In practice, selecting the right combination involves more than just the
checking the container or codecs. The current definition does not allow
applications to accurately determine whether many common scenarios are
supported on the wide range of platform/CDM implementations. Responses from the
current isTypeSupported() method may be ambiguous and represent many possible
capabilities. We should address the ambiguity to avoid compatibility issues
(and the likelihood of applications using user agent string checks to work
around them).

Content providers/applications will have varying robustness requirements that
may be different for audio and video. Likewise, implementations will have
varying robustness for each content type, ranging from simply supporting
decryption of blocks in the specified container to secure pipelines, yet there
is currently no way for applications to tell the difference.


*** Discussion ***
The one thing that all CDMs must explicitly support is the container
[protection scheme] (because they must be able to handle the corresponding
Initialization Data). When |contentType| is a supported container without
codecs, it is clear that isTypeSupported() should return true iff |keySystem|
supports parsing Initialization Data for the specified container.

In the case where a secure pipeline is required for audio and video, an
application would ask MediaKeys.isTypeSupported("com.example.somesystem",
"video/foo; codecs='baraudio,bazvideo'"). (Two separate queries could also be
used.) However, there is no guarantee that a true response indicates the
availability of a secure pipeline.

Likewise, it’s not clear what query to issue to get an affirmative response
from the largest set of clients when, for example, a secure pipeline is not
required, there are lesser requirements on the audio pipeline, or the audio is
not encrypted. In other words, how can an application know whether a 'true'
response indicates that a secure pipeline is available for both audio and
video, a secure pipeline is available for video but not audio, or the UA simply
knows how to decrypt blocks in the foo container and has baraudio and bazvideo
decoders? Without this information, an application doesn’t actually know
whether its requirements are supported by the client.


*** Proposal ***
The only unambiguous solution - one that would actually avoid user agent checks
- seems to be explicitly querying the capabilities/robustness levels:
  static IsTypeSupported isTypeSupported(DOMstring keySystem, optional
DOMString contentType, optional DOMString capability);
where IsTypeSupported is an enum with the same set of values as
CanPlayTypeEnum[1][2] and |capability| is a |keySystem|-specific string.

If |capability| is missing, the response would simply indicate whether the user
agent is at all capable of using |keySystem| with |contentType|. While it
doesn’t seem practical to standardize |capability| strings, it seems reasonable
for applications to know the capabilities they require. Also, this part of the
application already has key system-specific logic.

The synchronous and querying nature of IsTypeSupported() means that some
implementations may not be able to provide definitive responses or may only be
able to guarantee a minimum capability. Therefore, it makes sense to provide a
response of “maybe” as an indication that there is no definitive answer and the
application should confirm the answer with the license server. An application
can then look for a “probably” and try the “maybe” combination if there are no
“probably” responses and/or once the capability is determined to be available
(i.e. as indicated in the license request). Responses should also follow the
rules regarding “maybe”/”probably” that canPlayType() specifies for codecs.

** Different audio and video requirements **
When different capabilities are required for audio and video, the application
would need to make two separate calls, one for each content type.

Another option would be to have separate |audioCapability| and
|videoCapability| parameters.

Below are some drawbacks of separate calls. Separate parameters addresses all
of them.
* Applications often:
  - Check audio and video support together.
  - Pass the full MIME type, including the codec(s). (Note: This may be
obsoleted if we change |contentType|.)
* It is possible that querying audio and video separately could lead to false
positives if the types and capabilities are supported by separate pipelines
(and the UA can only use one at a time per media element). This mainly seems
likely in the case of clear audio and encrypted video.


[1]
http://www.w3.org/TR/2013/WD-html51-20130528/embedded-content-0.html#canplaytypeenum
[2] Unlike CanPlayTypeEnum, IsTypeSupported does not contain “Enum” per
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24190.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Saturday, 1 March 2014 01:48:20 UTC