- From: <bugzilla@jessica.w3.org>
- Date: Fri, 17 Oct 2014 01:01:21 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27067 Joe Steele <steele@adobe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |steele@adobe.com --- Comment #6 from Joe Steele <steele@adobe.com> --- (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. 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. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 17 October 2014 01:01:23 UTC