[encrypted-media] Is "running the Encrypted Block Encountered algorithm" the correct way to Attempt to Resume Playback If Necessary?

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

== Is "running the Encrypted Block Encountered algorithm" the correct 
way to Attempt to Resume Playback If Necessary? ==
The Initialization Data Encountered and Encrypted Block Encountered 
algorithms have steps to "Wait for a signal to resume playback."

This wait prevents further processing of the media data, which is an 
easy way to ensure we know the state of playback. However, this 
entirely blocks the resource fetch algorithm, and it's weird to block 
in an algorithm. So, the first question is whether this is correct.

Second, the Attempt to Resume Playback If Necessary algorithm 
"Attempt[s] to resume the resource fetch algorithm by running the 
Encrypted Block Encountered algorithm." Running this algorithm while 
currently waiting in the algorithm doesn't seem correct. It seems even
 more incorrect when waiting in a different algorithm, which is what 
happens when the `setMediaKeys()` algorithm invokes Attempt to Resume 
Playback If Necessary algorithm after the Initialization Data 
Encountered algorithm ends in the waiting step. It's also not clear 
that running the Encrypted Block Encountered algorithm is the next 
logical step after unblocking the Initialization Data Encountered 
algorithm. (Note that it is also possible that `setMediaKeys()` would 
unblock the wait in the Encrypted Block Encountered algorithm in some 
implementations.)

We should a) consider another way of stalling the processing of media 
data and b) determine the best way to resume based on the outcome of 
(a).

See https://github.com/w3c/encrypted-media/issues/100

Received on Monday, 19 October 2015 18:07:37 UTC