[encrypted-media] Should Wait for Key set readyState to HAVE_CURRENT_DATA when playing?

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

== Should Wait for Key set readyState to HAVE_CURRENT_DATA when 
playing? ==
The [Wait for 
Key](https://w3c.github.io/encrypted-media/#wait-for-key) algorithm 
currently says to set `readyState` to `HAVE_METADATA`. This makes 
sense if no frames have been decoded, such as when playback starts or 
a seek occurs. However, what is the correct value when playback 
encounters block it cannot decrypt?

This appears to depend on whether "the immediate current playback 
position" is the frame for which we do not have the key or the frame 
before it. In other words, did the "current playback position" advance
 before the Encrypted Block Encountered algorithm was called.

If so, `HAVE_METADATA` is likely correct. Otherwise, `readyState` 
should probably be `HAVE_CURRENT_DATA`.

A note in the HTML spec says the following about the difference 
between the two states:
>In practice, the difference between HAVE_METADATA and 
HAVE_CURRENT_DATA is negligible. Really the only time the difference 
is relevant is when painting a video element onto a canvas, where it 
distinguishes the case where something will be drawn 
(HAVE_CURRENT_DATA or greater) from the case where nothing is drawn 
(HAVE_METADATA or less).

`readyState` changes were discussed in #129, but I don't believe this 
specific case was discussed.

@foolip and @cpearce for comments

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

Received on Monday, 17 October 2016 21:47:57 UTC