[encrypted-media] Confirm `readyState` behavior when blocked waiting for a key is correct

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

== Confirm `readyState` behavior when blocked waiting for a key is 
correct ==
The value of `readyState` when blocked waiting for a key (causing the 
`waitingforkey` event) was raised by @cpearce-mozilla in #100. 
Although the EME spec is explicit about the expected behavior, it is 
not clear whether that is the correct behavior. This issue tracks 
confirming the specified behavior or modifying it to be correct. This 
likely depends on correctly interpreting the definition of 
`readyState`.

The EME spec currently says:
>The element is potentially playing and its `readyState` is equal to 
`HAVE_FUTURE_DATA` or greater.

This was based on an interpretation of `readyState` as relating only 
to the buffering of media data (see #7), which seems to be implied by 
the definitions of the [Ready 
states](https://html.spec.whatwg.org/multipage/embedded-content.html/#ready-states).

Among the questions to address are:
* Should being blocked on a key affect the media element's 
`readyState`?
  * Note that this would cause the HTMLMediaElement `waiting` and 
`canplay` events to be fired in response to key availability (see #7).
 In #7, we decided to avoid using these events and only fire an 
EME-specific event.
* Should the `readyState` indeed be "equal to `HAVE_FUTURE_DATA` or 
greater" when the Queue a "waitingforkey" Event algorithm is run?
  * More specifically, is the `readyState` "equal to 
`HAVE_FUTURE_DATA` or greater" when the Encrypted Block Encountered 
algorithm is run?

<br/>The HTML spec 
[says](https://html.spec.whatwg.org/multipage/embedded-content.html#ready-state):
>Media elements have a _ready state_, which describes to what degree 
they are ready to be rendered at the current playback position.

Based on that definition ("ready to be rendered"), it sounds like 
`readyState` should consider whether the media data can currently be 
rendered, which would include decryption _and decoding_. Furthermore, 
`HAVE_CURRENT_DATA` and higher would imply that the current data has 
already been (decrypted and) decoded. However, I do not believe that 
is the intent, so perhaps the definition needs to be corrected.

The [`HAVE_ENOUGH_DATA` 
definition](https://html.spec.whatwg.org/multipage/embedded-content.html#dom-media-have_enough_data)
 actually references the fetching of the data, which would seem to 
imply that `readyState` is indeed related to buffering (and the 
resource fetch algorithm).

If the "ready to be rendered" definition is correct, the definition of
 `HAVE_ENOUGH_DATA` should probably also include decoding:
> The user agent estimates that data is being fetched **and decoded** 
at a rate...

Still, it doesn't seem possible to address key availability since it 
is not generally possible for the user agent (or CDM) to determine 
whether it has all the necessary keys for future blocks. That would be
 an argument against such interpretation and changes.

@foolip, can you clarify the intended meaning of `readyState`?

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

Received on Wednesday, 25 November 2015 00:56:49 UTC