[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 #17 from David Dorwin <ddorwin@google.com> ---
(In reply to David Dorwin from comment #0)
> Some questions to address:
> 1) What should be the state of media element?
This proposed change in comment #16 addresses this issue, at least from an
attribute/event point of view.
The overall idea seems fine. I'd like hear more feedback since this affects
HTMLMediaElement.

> 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?
The proposal probably needs to be extended to cover seeking (question #2), both
as it relates to the waitingFor attribute, any EME state, flushing, etc.

> 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?
The proposed change tells app developers how to detect the condition, but they
still don't know what playback behavior to expect, especially when a subset of
streams is unavailable.


I broke the second part (basically, questions #3 and #4) of the original bug
into bug 24368 to avoid having two separate threads in this bug. Let's continue
to work on #1 and #2 in this bug.

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

Received on Wednesday, 22 January 2014 23:13:55 UTC