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

           Summary: Provide more details on behavior of the media element
                    when the key for an encrypted block is not available
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Encrypted Media Extensions
        AssignedTo: adrianba@microsoft.com
        ReportedBy: ddorwin@google.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org


This relates to the "Key Presence" step of the Encrypted Block Encountered
algorithm [1]. We should provide more guidance on the behavior of the media
element when the key for an encrypted block is not available and what it means
to be "waiting for a key" [2].

v0.1 of says, "The media element is said to be potentially playing unless
playback stops because the stream cannot be decrypted, in which case the media
element is said to be waiting for a key." (Note that this is not a MediaError
because there are legitimate use cases where a key may have been requested as a
result of the needkey event from the Potentially Encrypted Stream Encountered
algorithm [3] but has not yet been received by the time the key is required.)
We should probably be explicit about how to handle multiple streams and whether
to drop frames.

Some questions to address:
1) What should be the state of media element?
2) What happens on seek?
   - Flush just like normal and make sure the decoders, etc. are unblocked?
   - Will waiting on the key cause non-EME events to be fired? Is that okay?
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.

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.


[1]
http://dvcs.w3.org/hg/html-media/raw-file/eme-v0.1a/encrypted-media/encrypted-media.html#algorithms-enrypted-block
[2]
http://dvcs.w3.org/hg/html-media/raw-file/eme-v0.1a/encrypted-media/encrypted-media.html#waiting-for-a-key
[3]
http://dvcs.w3.org/hg/html-media/raw-file/eme-v0.1a/encrypted-media/encrypted-media.html#algorithms-encrypted-stream

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Friday, 10 August 2012 04:12:58 UTC