[encrypted-media] waitingforkey as spec'd could fire at different times in different browsers

cpearce has just created a new issue for 
https://github.com/w3c/encrypted-media:

== waitingforkey as spec'd could fire at different times in different 
browsers ==
The "waitingforkey" event is spec'd in "7.3.4 Wait for Key" to be 
fired immediately once the algorithm is called. This algorithm is 
called from inside the "Attempt to decrypt" algorithm. I know that 
both Firefox and Chrome decode ahead of the current playback position 
in order to smooth over any irregularities in decoding timings. 
However, I note that Firefox (when decoding in software) decodes 10 
frames ahead but Chrome decodes 4 ahead (IIRC). So if we fire 
"waitingforkey" as soon as we hit a frame that we can't decode, we may
 end up still playing for 10 frames or so in Firefox and 4 frames in 
Chrome. This means we could also dispatch events such as "timeupdate" 
after the "waitingforkey". Confusingly, we'd be advancing the current 
playback position while the readyState is HAVE_METADATA.

I recall that the "waitingforkey" event is primarily as an indicator 
for developers that playback has stalled. 

So I propose we change the "Wait for Key" algorithm to have an extra 
step, inserted before step 4 which enqueues a task to dispatch the 
event:

> Wait until all decrypted and decoded media data has been played.
>>NOTE: As a result of this step, the "waitingforkey" event will not 
fire until all decryptable media data has been played, and playback 
has stalled.

This would enforce that browsers fire "waitingforkey" at a consistent 
time.


Please view or discuss this issue at 
https://github.com/w3c/encrypted-media/issues/336 using your GitHub 
account

Received on Monday, 17 October 2016 02:25:29 UTC