- From: ddorwin via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Nov 2015 00:56:47 +0000
- To: public-html-media@w3.org
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