This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
Below is my proposal, which is adapted from https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092#c1. 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.
This seems like it would be an ideal way to facilitate bug#25218 as well. I think this is a great idea.
Implemented in https://dvcs.w3.org/hg/html-media/rev/7ae17d9a91f1. The event name is shortened to "keyschange".
Added clarifications in https://dvcs.w3.org/hg/html-media/rev/d426f69d04bc. It turns out we cannot use a read-only attribute. Resolving this is tracked in bug 25594.