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

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

--- Comment #12 from Chris Pearce <cpearce@mozilla.com> ---
(In reply to David Dorwin from comment #10)
> 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.


I think the idea of firing an error in the Encrypted Block Encountered
algorithm if the CDM is no longer available is good, but I don't think your
proposal will work. If the CDM becomes unavailable, presumably the
MediaKeySessions will close, so the steps you propose won't have the desired
effect; if the MediaKeySessions close, the Encrypted Block Encountered
algorithm will skip to a "waiting" state, bypassing the step you'd add.

How about we inject a step immediately after 1.2 "Let cdm be the CDM loaded
during the initialization of the media keys.":

"If cdm is no longer usable for any reason, abort the media element's resource
fetch algorithm, run the steps to report a MEDIA_ERR_DECODE error, and abort
these steps."



> 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.

This sounds good to me.

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

Received on Friday, 7 November 2014 01:17:33 UTC