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

[encrypted-media] 'waitingforkey' event has no inverse

From: Joey Parrish via GitHub <sysbot+gh@w3.org>
Date: Wed, 27 Jul 2016 18:05:08 +0000
To: public-html-media@w3.org
Message-ID: <issues.opened-167918259-1469642706-sysbot+gh@w3.org>
joeyparrish has just created a new issue for 
https://github.com/w3c/encrypted-media:

== 'waitingforkey' event has no inverse ==
As far as we've been able to tell, there's no inverse of the 
`waitingforkey` event to let an application know that the user agent 
is no longer waiting for a key.

We tried to do this with `keystatuseschange` events, supposing that a 
usable key status indicates that the browser is no longer waiting.  
However, for content without a clear lead, we found two big problems 
with this.

1. If the CDM just got a new key, but it's either the wrong key or 
there are still other keys needed, this is not the inverse of 
`waitingforkey`.  In most cases, though, another `waitingforkey` event
 fires after the `keystatuseschange` event.  Relying on an additional 
`waitingforkey` to convey that we are still waiting brings me to the 
second issue with this strategy...
2. The `waitingforkey` event does not always fire strictly before the 
`keystatuseschange` event.  In some cases, we have all the keys we 
need, but the `keystatuseschange` event fires first, followed by a 
`waitingforkey` that is now obsolete.  I assume there is a race 
between the decoder thread dispatching `waitingforkey` and the CDM 
thread dispatching `keystatuseschange`.  At the application level, 
there's no clear way to tell when this has happened, so it looks as if
 the wrong keys have been obtained.

Since using `keystatuseschange` as the inverse of `waitingforkey` 
seems to be dependent on timing, we have concluded that this is not a 
suitable solution.  We wanted to use `waitingforkey` as a diagnostic 
measure to tell application integrators when their license servers 
served the wrong keys, but without a matching event when the pipeline 
is unblocked, we will have to cut that feature.

Is there an inverse event we can use today?  If not, could a future 
version of EME include one?

Please view or discuss this issue at 
https://github.com/w3c/encrypted-media/issues/284 using your GitHub 
account
Received on Wednesday, 27 July 2016 18:05:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 27 July 2016 18:05:16 UTC