[Bug 27067] Define what to do when CDM crashes

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

--- Comment #9 from Chris Pearce <cpearce@mozilla.com> ---

(In reply to David Dorwin from comment #7)
> (In reply to Joe Steele from comment #6)
> > (In reply to David Dorwin from comment #4)
> > > This might be better phrased as "when the CDM fails or becomes
> > > unresponsive." Since the CDM is a separate entity in the spec and many
> > > implementations, this could be a real possibility. This should also cover
> > > cases where the "context" is lost, such as on some mobile platforms when the
> > > device goes to sleep.
> > > 
> > > For contrast/comparison: The HTML5 spec does not say what to do when a
> > > hardware video decoder fails, but there is a generic mechanism for reporting
> > > decode errors:
> > >   MEDIA_ERR_DECODE (numeric value 3)
> > >     An error of some description occurred while decoding the media resource,
> > > after the resource was established to be usable.
> > > 
> > > We may want to identify a similar mechanism. For example, maybe the first
> > > paragraph of the Session Close algorithm section should be broadened. The
> > > Encrypted Block Encountered algorithm should already cover the behavior
> > > resulting from the keys being unavailable.
> > 
> > I think the idea is right and I would expect both things to happen, i.e. a
> > MEDIA_ERR_DECODE to be reported and the Session Close algorithm to run. The
> > app could catch the error and respond appropriately then. 
> 
> Note that a MEDIA_ERR_DECODE would not occur in this case. The waiting for a
> key path would be executed per my last sentence above.

Well, if we were executing step 2.2 of the Encrypted Block Encountered
algorithm, and the CDM tried to decrypt and decode something and crashed, then
the spec says we should report a MEDIA_ERR_DECODE error. If the CDM crashed
while it wasn't in the act of decoding, or if it didn't have a usable keyid,
then we're supposed to wait for keys.

Those keys will never become usable if the CDM has crashed, unless script
detects this situation and re-created the MediaKeys (I assume).


> > However we may need more. In some cases the MediaKeys object itself may no
> > longer be valid. Currently we don't have a MediaKeys Close algorithm
> > defined. I think we may need that as well, to inform the application that it
> > needs to go through the Key System selection again.
> 
> We shouldn't over-engineer this corner case. It seems unlikely that
> applications would bother listening for such an event on MediaKeys anyway.

It seems to me that treating CDM crash as a decode error makes sense, as if the
CDM crashes or is otherwise unusable, as there's no way further video samples
can be played, and no more keyrequests that can be generated. Webdevs already
listen for "error" events on HTMLMediaElements, so I think it makes sense to
fire that event here.

On the other hand, the video element could be made capable of decoding if it
re-creates a new MediaKeys object and sets it on the media element, but script
would have to detect this condition, and it seems unlikely that script would
make the effort given it's (hopefully!) and uncommon occurrence.

> However, we could have createSession() reject the promise with
> "InvalidStateError". If all the sessions are closed and you can't create a
> new session, something is clearly wrong with the MediaKeys.

Sure. If the CDM is in a state where it can't create a new session,
MediaKeys.createSession should fail. But we should still have an explicit
notification that the media element can't decode any more.

How much does what we're talking about here overlap with bug 26776?

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

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