[Bug 18515] Provide more details on behavior of the media element when the key for an encrypted block is not available

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515

--- Comment #25 from Jerry Smith <jdsmith@microsoft.com> ---
Since this is a distributed change, I'd like to confirm the approach before
committing changes.  The request is to update the Encrypted Block Encountered
section to indicate a waiting for keys event, and distribute the management of
the waitingFor attribute to other algorithms that queue canplay or waiting
events.

A possible approach:

1.  Add an algorithm to Queue a "waiting" Event similar to Queue an "error"
Event.  Something like:

The following steps are run:
1.    Let the media element be the specified media element object.
2.    Set the waitingFor attribute on the Media Element to "key".
3.    Queue a task to fire a simple event named timeupdate at the element.
4.    Queue a task to fire a simple event named waiting at the element.
5.    Suspend playback.

2.  Include language under Encrypted Block Encountered to run the waiting event
algorithm when no keys are available to decrypt the content.  Like:

Run the following steps: 
1.    Let media element be the media element associated with the
MediaKeySession.
2.    Run the Queue a "waiting" Event algorithm on the media element.
3.    Abort these steps.

3.  Update current algorithms that queue "canplay" and "waiting" events to
properly set the waitingFor attribute state.  This will affect the ReadyState
playback algorithms under Playing the Media Resource.

There are also two steps that attempt to resume playback when waiting for keys.
 If resumption succeeds, we'll need to reset waitingFor to none.  I haven't
found yet where to make that change.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 13 May 2014 01:23:33 UTC