[encrypted-media] Clarify the meaning of "do[es] not support" a media capability

ddorwin has just created a new issue for 
https://github.com/w3c/encrypted-media:

== Clarify the meaning of "do[es] not support" a media capability ==
Step 12 of the [_Get Supported Capabilities for Audio/Video 
Type_](https://w3c.github.io/encrypted-media/#get-supported-capabilities-for-audio-video-type)
 algorithm says
>If the user agent and implementation do not support playback of 
encrypted media data for the combination of _container_, _media 
types_, _robustness_ and _local accumulated configuration_, continue 
to the next iteration.

In practice, _media types_ means codecs. The question is whether "do 
not support" means (a) "is **certain it does not** support" or (b) "is
 **not certain** it can support." This is mainly relevant when a codec
 string is ambiguous or otherwise not known to be supported. These are
 likely the cases where `canPlayType()` would return `"maybe"` rather 
than `""` or `"probably"`.

If (a), ambiguous or potentially-supported codec strings would cause 
the current configuration to be selected. If (b), they would not be 
included and may cause the current configuration to be skipped.

While (a) might be seen as friendly, it also:
* Prevents an application from using certain patterns.
  * For example, one configuration may include a codec string that 
indicates advanced features (about which some UAs may not be certain) 
may be followed by a configuration containing a more common codec 
string.
  * If the UA does not reject the first codec string, the application 
cannot differentiate.
* Encourages bad practices (i.e. using incomplete codec strings), 
which could prevent implementations from providing accurate and 
specific responses.
  * By being strict in a new API, we can avoid some of the issues we 
are now stuck with for `canPlayType()`.

We have been more "strict" than friendly before (i.e. requiring all 
`sessionTypes` to be supported) in order to enable application control
 similar to the example above.

Note: Part of the issue here is the liberal handling of codec strings 
(e.g. by `canPlayType()`) in many implementations, that the 
differentiation between `"maybe"` and `"probably"` is often 
irrelevant, and that the EME API has two states instead of three. 
MSE’s `isTypeSupported()`  also only has two states and appears to be 
liberal, but it does not explicitly need to support a series of 
configurations like EME does. If it was possible, being strict would 
probably be better there as well. Perhaps more importantly, 
`canPlayType()` and `isTypeSupported()` are designed to allow the 
application to walk a tree of capabilities whereas EME is designed to 
check lists of specific codecs and get a response. Furthermore, EME 
allows a subset of the listed types to be selected (and thus satisfy 
the configuration).

The following are some examples that frequently occur today for 
`canPlayType()` and MSE's `isTypeSupported()`:
* `"avc1"` - [valid RFC6381 
syntax](https://tools.ietf.org/html/rfc6381#section-3.4) but very 
ambiguous.
* `"mp4a.40"` - [valid RFC6381 
syntax](https://tools.ietf.org/html/rfc6381#section-3.4) but very 
ambiguous.
* `"mp4a"` - [**invalid** RFC6381 
syntax](https://tools.ietf.org/html/rfc6381#section-3.4) and very 
ambiguous.
* `"avc1.58A01E"` - Extended profile. Probably not supported but 
returns `"maybe"` in Chrome and likely elsewhere.

Chrome currently implements (b), which is basically implemented by 
determining whether the codec string would result in `"probably"` if 
passed to `canPlayType()`. (Chrome's handling and filtering of codec 
strings in `canPlayType()` has been improved recently.) Based on 
sample code, it appears that Edge implements (a), even allowing 
`"mp4a"`.

Thus, we have an interoperability issue that should be resolved in the
 spec.


Please view or discuss this issue at 
https://github.com/w3c/encrypted-media/issues/151 using your GitHub 
account

Received on Monday, 7 March 2016 20:01:36 UTC