This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25409 - Allow applications to detect whether a key is usable before using it to decrypt content
Summary: Allow applications to detect whether a key is usable before using it to decry...
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: David Dorwin
QA Contact: HTML WG Bugzilla archive list
Depends on: 25594
Blocks: 25092
  Show dependency treegraph
Reported: 2014-04-21 22:50 UTC by David Dorwin
Modified: 2014-05-07 23:16 UTC (History)
3 users (show)

See Also:


Description David Dorwin 2014-04-21 22:50:15 UTC
Currently, the only way to detect whether a key is usable is to try to play content that requires that key and see if it succeeds. When the answer is "no", this may result in a jarring user experience (i.e. dropped frames, pause, rebuffering). Such a scenario could be common in an adaptive streaming scenario.

Instead, EME should allow the application to determine ahead of time which key(s) can be used and thus which stream(s) are playable. Since the answers depend on the license, CDM, and/or hardware, the results cannot be returned synchronously, and they could even vary during playback.
Comment 1 David Dorwin 2014-04-21 22:54:06 UTC
Below is my proposal, which is adapted from This bug addresses use cases other than the original scenario in that bug, and I think we should considered solutions independent of the outcome of bug 25092.

* Add a simple event named something to the effect of “usablekeyschange”.
* Add an attribute to MediaKeySession: usableKeyIds.
  - readonly attribute Array<Uint8Array> usableKeyIds; // An array of usable key IDs, which are Uint8Arrays.
* Whenever the set of usable keys in a session changes - whether through a new license, license expiration, output changes, etc. - the CDM will update the usableKeyIds attribute and fire the “usablekeyschange” event.
* When an application receives the “usablekeyschange” event (or at any other time), it checks the usableKeyIds attribute for the usable key IDs.
  - The application should probably stop fetching and providing content requiring any missing key IDs or request a new license.

Content using key IDs not listed in usableKeyIds does not necessarily fail (this would be indicated by an error event), but the application should stop providing such content.

In addition to some of the more obvious use cases, this also addresses some of the use cases associated with the removed “ready” event (without the ambiguity that led it to be removed).

It could also address things like license expiration (currently a proposed error in bug 21798). The only issue is that there is no indication of why a key ID is not usable. (We might be able to add this later if implementation experience shows that it is really necessary. Or, we can also fire an “error” event.)

This may even address the use cases for adding a |capability| parameter to isTypeSupported() as outlined in bug 24873.
Comment 2 Joe Steele 2014-04-29 20:21:28 UTC
This seems like it would be an ideal way to facilitate bug#25218 as well. I think this is a great idea.
Comment 3 David Dorwin 2014-05-05 21:10:13 UTC
Implemented in The event name is shortened to "keyschange".
Comment 4 David Dorwin 2014-05-07 23:16:49 UTC
Added clarifications in

It turns out we cannot use a read-only attribute. Resolving this is tracked in bug 25594.