- From: ddorwin via GitHub <sysbot+gh@w3.org>
- Date: Fri, 20 May 2016 00:42:30 +0000
- To: public-html-media@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