- From: ddorwin via GitHub <sysbot+gh@w3.org>
- Date: Mon, 07 Mar 2016 20:01:28 +0000
- To: public-html-media@w3.org
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