[Bug 24368] New: 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

            Bug ID: 24368
           Summary: Define playback behavior when the key for an encrypted
                    block is not available for a subset of streams
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Encrypted Media Extensions
          Assignee: adrianba@microsoft.com
          Reporter: ddorwin@google.com
        QA Contact: public-html-bugzilla@w3.org
                CC: acolwell@google.com, jdsmith@microsoft.com,
                    mike@w3.org, public-html-media@w3.org

This bug is half of what bug 18515 was originally. I'm breaking playback
behavior out because it seems to be a sizable issue not related to the current
text proposal in the other bug.

Bug 18515 covers the app-visible events and attributes when blocked waiting for
the key for an encrypted block.

This bug tracks the user-visible playback experience in that case. Most
importantly, what happens when only a subset of the streams are blocked waiting
for a key.

(From my original description in bug 18515)
> Some questions to address:
...
> 3) What should happen to playback if not all streams need a key to continue?
> 4) If playback is suspended in one media element, how does this affect an
> associated MediaController?
> 
> Related to the last two questions above, should user agents drop frames or
> suspend playback when at least one but not all streams need a key to
> continue? Dropping frames may be desirable if some content (i.e. audio) can
> be played without the missing key, but continuing one stream may not be
> possible in some implementations (i.e. if an audio stream needs a key).
> Choosing to drop frames may also mean that, for example, the initial video
> frames are never displayed in some use case and media combinations.
> 
> Some specific scenarios to consider:
>  A) Video needs a key but audio does not.
>  B) Audio needs a key but video does not.
>  C) There is more than one audio or video stream.
>  D) A video or audio stream that is not being rendered needs a key.
New:
E) Do we need to worry about text track data? Is there a scenario where we
should block for such data?
> 
> Note that if audio is driving playback (time) then playback will probably
> continue in the first scenario unless explicitly paused. This behavior would
> be different than the opposite (second) scenario.
> 
> In all cases, playback should resume when the key is provided.


We also need to decide where this behavior should be described. It seems that
that issue might be better resolved outside of EME, especially in light of
similar issues in MSE, which also makes such scenarios (audio frames but not
video frames) possible. We may eventually file a bug against HTML to cover all
such scenarios.

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

Received on Wednesday, 22 January 2014 23:12:56 UTC