[Bug 24368] Define playback behavior when the key for an encrypted block is not available for a subset of streams

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

--- Comment #1 from David Dorwin <ddorwin@google.com> ---
I looked at MSE's handling of such a condition and looked for relevant text in
the HTML5 spec. (Thanks to Aaron for several pointers.) The summary is that the
lack of media data for one or more tracks appears to be covered by MSE and
HTML5, though it may make sense to add clarity to the HTML5 spec.

Details:
* An underflow should cause a transition to HAVE_CURRENT_DATA and playback
should stall.
  - This happens when the current playback position goes into an area not
covered by the TimeRanges reported by HTMLMediaElement.buffered (see [1).
  - [1] and [2] appear to define the stalling behavior as well as the firing of
the waiting event (relevant for bug 18515).
* In MSE, the behavior happens as part of the SourceBuffer monitoring algorithm
[3].
  - Note: It is possible this section could be simplified to depend on or
describe the interaction with the HTML5 algorithm.
* MSE is explicit about multiple active buffers but (unextended) HTML5 does not
appear to be explicit about how to handle the case where the "media resource"
and/or "media data" are available for one stream but not another.
  - This means that it is not obvious how to handle, for example, an underflow
in video but not audio when using .src.
  - It is probably safe to interpret the HTML5 spec as implying 'for all
selected video track(s), the enabled audio track(s), and the "showing" or
"hidden" text track(s)' like the MSE spec explicitly states in [3].
* I was not able to find an explicit step for suspending playback in the HTML5
spec like the "Playback is suspended" statement in MSE [3].


EME should have consistent behavior (stall if any track is blocked on
decryption). However, since we decided that decryption should not affect the
readyState in bug 18515 [4], EME cannot rely on those existing algorithms.

We might be able to address this in EME by adding a couple things to the
proposal in bug 18515.
For example (new text is surrounded by "***"):
   o  If media element was previously playing and had a waitingFor value of
“notwaiting”: 
   ...
      -  If new mediaKeys are needed to continue ***playback for any selected
video track(s), enabled audio track(s), or "showing" or "hidden" text
track(s)*** and the element has not ended play back, the user agent must set
the waitingFor attribute on the Media Element to “mediakeys”, queue a task to
fire a simple event named timeupdate at the element, queue a task to fire a
simple event named waiting at the element ***, and suspend playback***.


[1] http://www.w3.org/TR/html5/embedded-content-0.html#event-media-waiting
[2] Second bullet at
http://www.w3.org/TR/html5/embedded-content-0.html#handling-first-frame-available
[3]
https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source.html#buffer-monitoring
[4] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c15

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

Received on Thursday, 23 January 2014 02:14:13 UTC