[Bug 27067] Define what to do when CDM becomes unavailable

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

David Dorwin <ddorwin@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Define what to do when CDM  |Define what to do when CDM
                   |crashes                     |becomes unavailable

--- Comment #10 from David Dorwin <ddorwin@google.com> ---
As Chris noted, the crash could occur at a variety of points. If the crash
occurs during, for example, the UA's Decrypt() call to the CDM MEDIA_ERR_DECODE
makes sense.

However, if the crash occurred elsewhere, the next time Encrypted Block
Encountered is run, "cdm" will be invalid. Currently, there is no path in the
algorithm to handle this. We could add the following step after the CDM step
("2. Use the cdm to execute the following steps"):
3. If the previous step failed, abort the media element's resource fetch
algorithm, run the steps to report a MEDIA_ERR_DECODE error, and abort these
steps.

That should ensure that the media element always reports MEDIA_ERR_DECODE if
the attached MediaKeys becomes unusable. Separately, the MediaKeySession
objects may/should also be closed.

However, that still doesn't tell the application it needs to create and attach
a new MediaKeys object.

We could add a simple Event named "close" to MediaKeys to support unexpected
loss of the CDM, including due to device resource constraints. Since any
encrypted-event-driven application would need to see "encrypted" events again,
the application will probably need to reload the source even if the media
element is not in an error state.

Thus, if the CDM becomes unusable for whatever reason:
 1. The user agent should close all sessions.
 2. The user agent should fire a "close" event at the MediaKeys object.
 3. If the media is playing, a MEDIA_ERR_DECODE will almost certainly occur.
 4. The application should create a new MediaKeys object and call
setMediaKeys().
 5. If the application relies on "encrypted" events or a MEDIA_ERR_DECODE event
occurred, it must re-set .src.
  * If the CDM is also doing decoding and a MEDIA_ERR_DECODE event did not
occur (likely because the media was not playing), the user agent needs to
handle the change in decoders.
 6. The application should obtain new license(s).

Without the "close" event, the application may run step #5 but would not know
to run #4.

This is overkill for crashes (refresh accomplishes 4-6). However, I think this
could be an issue for some implementations that use platform-based CDMs on
devices (especially mobile) that support multitasking. It's unclear whether
applications would actually handle this, but a simple "close" event at least
gives them the option.

(In reply to Chris Pearce from comment #9)
> How much does what we're talking about here overlap with bug 26776?

I don't think there is any overlap. Those errors are always on
MediaKeySessions. MediaKeys only has the user agent-only createSession() and
setServerCertificate().

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

Received on Tuesday, 21 October 2014 20:33:41 UTC