How should the capability to decode unencrypted media data be checked?

[ddorwin]

The spec currently assumes that all MediaKeySystemMediaCapability values refer to encrypted media data. However, it is possible (i.e. #178 (comment)) 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').

[mwatson2]

Another option here would be to make support of unencrypted content mandatory.

Are there any implementations that support only encrypted content once a MediaKeys object has been attached to a video element ?

[baconz]

Chrome works this way, though it is a little more nuanced than that. My understanding is that they will play unencrypted content until you start passing encrypted content. After that, unencrypted content will no longer play.

https://bugs.chromium.org/p/chromium/issues/detail?id=597443

[ddorwin]

I think we do assume that unencrypted blocks can be decoded - even "encrypted streams" may not be entirely encrypted.

However, both scenarios refer to codecs that can be played by the user agent but not if they are encrypted (or at least in the specified configuration).

[ddorwin]

@baconz, this is a different issue. Chrome does support, for example, encrypted video and unencrypted audio. Switching between encrypted and unencrypted streams is issue #251.

[steelejoe]

This could definitely be an issue for ad splicing scenarios. Ads will typically not be encrypted. Although to be fair, I believe it is fairly easy to have multiple video elements and swap visibility to handle this case. I believe our player implementations do this.

[ddorwin]

Since the empty robustness string has been addressed (see #196) and will not be used for this, I don't think this needs to be addressed in V1. Therefore, I'll move it to VNext for consideration.

[joeyparrish]

This does not appear to be an actual issue. Clear content through an encrypted pipeline is a degenerate case of clear lead.