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

[encrypted-media] How should the capability to decode unencrypted media data be checked?

From: ddorwin via GitHub <sysbot+gh@w3.org>
Date: Fri, 20 May 2016 00:42:30 +0000
To: public-html-media@w3.org
Message-ID: <issues.opened-155865724-1463704949-sysbot+gh@w3.org>
ddorwin has just created a new issue for 
https://github.com/w3c/encrypted-media:

== How should the capability to decode unencrypted media data be 
checked? ==
The spec currently assumes that all `MediaKeySystemMediaCapability` 
values refer to encrypted media data. However, it is possible (i.e. 
https://github.com/w3c/encrypted-media/issues/178#issuecomment-216124376)
 that an application wants to use unencrypted stream(s) along with 
encrypted stream(s). Currently, even an empty `robustness` string 
"indicates that any ability to **decrypt** and decode the content type
 is acceptable." Thus, there is currently no way to explicitly test 
for support of clear content.

Scenarios where this might be relevant include:
* An implementation supports a codec but not decryption of it. (This 
would be a positive response.)
* Same as the above scenario but support requires use of a different 
pipeline. (This would be a negative response.)

While it might seem that `canPlayType()` or MSE's `isTypeSupported()` 
could provide this information, this would not provide the appropriate
 response for the second scenario above.

One option would be to redefine the meaning of the empty `robustness` 
string (see #196). Alternatively, we could pick a `robustness` string 
that always means clear content for all Key Systems (i.e. `'clear'`).

Please view or discuss this issue at 
https://github.com/w3c/encrypted-media/issues/197 using your GitHub 
account
Received on Friday, 20 May 2016 00:42:31 UTC

This archive was generated by hypermail 2.3.1 : Friday, 20 May 2016 00:42:32 UTC