W3C home > Mailing lists > Public > public-html-media@w3.org > May 2016

[encrypted-media] Be explicit about how the lack of audioCapabilities/videoCapabilities in a configuration is handled

From: ddorwin via GitHub <sysbot+gh@w3.org>
Date: Sun, 01 May 2016 02:21:10 +0000
To: public-html-media@w3.org
Message-ID: <issues.opened-152064326-1462069269-sysbot+gh@w3.org>
ddorwin has just created a new issue for 
https://github.com/w3c/encrypted-media:

== Be explicit about how the lack of 
audioCapabilities/videoCapabilities in a configuration is handled ==
The [Get Supported 
Configuration](https://w3c.github.io/encrypted-media/#get-supported-configuration)
 algorithm currently allows `audioCapabilities` and 
`videoCapabilities` to not be present in the 
`MediaKeySystemConfiguration`, but the spec does not specify how this 
is to be handled/interpreted.

When the capabilities member is present, the sequence must be 
non-empty and for each entry:
* `contentType` must be non-empty.
* `robustness` may be empty, in which case we rely on this text from 
the 
[definition](https://w3c.github.io/encrypted-media/#widl-MediaKeySystemMediaCapability-robustness)
 of this member: "The empty string indicates that any ability to 
decrypt and decode the content type is acceptable."

I see two options:

**Option 1: Require these members be present.**
There may not be sufficient reason to allow these members to be 
optional. Applications _should_ specify them in most cases, especially
 since this should improve the chances of success across client 
implementations.

I can think of two scenarios where they legitimately might not need to
 be specified:

1. Audio-only content: `videoCapabilities` is unnecessary.
1. Managing persistent state: Content type is irrelevant and it's 
simpler to not specify types to cover all implementations.

(1) can be supported by a) stating that content types not specified 
are not supported by the instance or b) requiring an explicit 
indication, such as an empty list. We could additonally prohibit not 
specifying _both_ members, which would ensure there is always a 
robustness specified (even if per the existing text regarding the 
empty string).

It may not be necessary to support (2):
* Even when media data won't be decrypted by the instance, robustness 
is still relevant as discussed above.
* It is probably better to fully specify the requirements so the 
`MediaKeySystemAccess` (and `MediaKeys`) object can be reused for 
playback and to avoid the potential for multiple user consent 
requests.

**Option 2: Specify the behavior.**
Specify something similar to the text for `robutstness` as the 
behavior when `audioCapabilities` or `videoCapabilities` - and perhaps
 both - are not present.

In such cases, there will be no guarantees of any audio or video type 
support, respectively. Thus, the most important clarification is the 
robustness level, perhaps especially when neither member is present. 
(We should consider that robustness could theoretically be relevant 
even when no content is to be decrypted. As a hypothetical example: 
case (2) above if there multiple pipelines.)

We could specify this in the two member definitions. Along with 
`robustness`, I wonder whether we should also normatively specify this
 in the algorithm steps or non-normatively refer to the definition at 
the appropriate step in the algorithm.

Please view or discuss this issue at 
https://github.com/w3c/encrypted-media/issues/178 using your GitHub 
account
Received on Sunday, 1 May 2016 02:21:12 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 1 May 2016 02:21:12 UTC