[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 #19 from Jerry Smith <jdsmith@microsoft.com> ---
In reply to David from comment #18:

These suggestions all seem fine to me:
-    Set waitingFor to readonly
-    Use waitingFor “none” instead of “notwaiting”
-    Use waitingFor "key" instead of "mediakeys"
-    Put "data" second in the waitingFor enum order
-    Substitute "media keys/decryption keys" for "media keys" in the algorithm
language
-    Change one from “playing protected media” to “playing media” to allow for
the case where encrypted frames are encountered generally.
-    Altered wording to apply algorithm steps generally (not just to key
related waiting).

Left open:
-    Whether to specify “audiodata” or “videodata” under “waitingFor”.  Depends
on bug 24368.
-    Whether to add waitingFor directly to the HTMLMediaElement in the HTML5.x
spec.  I put it in the EME document because that’s where the need arose.  I
agree it might be used more broadly.

Questions:
-    Where should new text be added?  A:  The intent was to add it with the
referenced existing text in the same section as the current addition (under
“Playing the media resource”).
-    Should ReadState states be explicitly described?  A: My intent was to key
on ReadyState changes that triggered “waiting” and “canplay” events.  I believe
that completely describes what is intended.
-    How can this be extended for seeking?  On seeking, the normal “seeking”
event would be triggered, reflecting the new state.  Is this not sufficient?

Clarification:  Existing text is intended to be retained, with “new” text added
below it.

========

Updated change description:

  readonly attribute waitingFor;

With these states defined:

  enum waitingFor {
    “none”,
    “data”
    “key”,
  }; 

Add to the playing condition text under 4.2 Encrypted Block Encountered.

Following this existing text:
----------------------------
The following paragraph is added to Playing the media resource.
A media element is said to be waiting for a key when it would be potentially
playing but the user agent has reached a point in the media resource that must
be decrypted for the resource to continue and the CDM does not have the
necessary key. 
The media element leaves this state when seeking but could re-enter it if the
same conditions exist.

Add this new text:
-----------------
It is possible for media element to be playing media and encounter content that
requires media keys/decryption keys.  To accommodate changes caused by key
status, apply the first appropriate substeps from the following list:

o    If media element was previously playing and had a waitingFor value of
“none”: 
    If a readyState change queues a task to fire a waiting event, the user
agent must also set the waitingFor attribute on the Media Element to “data”.
    If a media key(s) /decryption key(s) is needed to continue and the element
has not ended playback, the user agent must set the waitingFor attribute on the
Media Element to “key”, queue a task to fire a simple event named timeupdate at
the element, and queue a task to fire a simple event named waiting at the
element.
o    If media element was previously waiting and had a waitingFor value of
“data”: 
    If a readyState change queues a task to fire a canplay event, the user
agent must also set the waitingFor attribute on the Media Element to “none”.
o    If media element was previously waiting and had a waitingFor value of
“key”: 
    If a media key(s) /decryption key(s) becomes available for playback to
proceed, the user agent must set the waitingFor attribute on the Media Element
to “none”, queue a task to fire a simple event named timeupdate at the element,
and queue a task to fire a simple event named canplay at the element.

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

Received on Monday, 27 January 2014 23:18:51 UTC