[encrypted-media]

 has just created a new issue for :  == EME should not fire waiting or
canplay events - use a separate mechanism == There are a couple issues
with the “waiting for a key” solution currently specified by EME. (See
[bug 18515](https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515) for
background.) The first is the most important.    1) In the main HTML
spec, the `waiting` and `canplay` events are fired on transitions in a
`readyState` state machine.    The current EME spec fires these events
but does not interact with the `readyState` state machine. This is
problematic spec-wise and potentially for implementations (i.e. if
they rely on readyState changes to fire events).     I believe we
previously decided not to modify `readyState` because it was perceived
as related to network. If that is the case, we probably shouldn’t be
using events based on `readyState` and thus network.    2) Maintaining
the state of waitingFor is complex - in both the spec and potentially
implementations - and, as previously noted, may have timing issues.
This is perhaps a side effect of trying to inject into the
`readyState` state machine.      For the replacement, we have two
options:  A) Fully integrate into the `readyState` state machine.  B)
Define independent event(s).    Since this is primarily intended to
indicate problems with playback (vs. being actionable by the
application), I propose we start with a simple to implement and
understand solution:  * Revert the two changes made for [bug
18515](https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515). This
includes removal of the waitingFor attribute.  * Change the Queue a
"waiting" Event algorithm to just fire a “waitingforkey” simple event
(and rename it as such).  * Change the Attempt to Resume Playback If
Necessary algorithm to not fire any events.  See
https://github.com/w3c/encrypted-media/issues/7

Received on Monday, 5 January 2015 08:40:53 UTC