This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
MEDIA_ERR_ENCRYPTED covers three cases 1) No key was provided and no needkey handler was provided 2) The provided key could not be successfully applied 3) The user agent does not support decryption of this media data Consider whether these should be differentiated ? A single error is consistent with the current broad error codes, though that may be something that should be improved in general. It seems that except for #1, which should only occur in applications that do not support encrypted media, these are all application bugs and not something that would improve the user experience. Any unique handling of the error codes by an application would essentially be describing a bug type. Unique codes might be helpful in tracking down the cause of the bug, but there are probably other options. It is also possible that some of these cases should be reported via MediaKeyErrorEventInit.
Note that "MediaKeyErrorEventInit" in the above text should be "MediaKeyErrorEvent". This is covered by issue 16740.
We should also consider whether it makes sense to add any new MediaError values related to encryption. Consider the following for each of the use cases listed above. 1) Is there any precedent for checking for a handler this way? It seems to add complexity to user agent implementations. WebKit, for example, just queues events in the HTMLMediaElement and does not directly access the handlers. If we we cannot or do not want to have this check, we need to remove this use case. The purpose of this use case is reporting errors to pages that do not have a needkey handler, possibly because they were created before it was defined). Without an error, these pages might not be informed that playback will not succeed. Maybe we can fire another event or find some other way to address this. This would most likely be generic player pages rather than content provider pages since the latter would most likely update their pages before adding encrypted content. 2) As noted in bug 16857, we may need to remove this use case. If so, this scenario would result in MEDIA_ERR_DECODE. 3) This could be handled by existing error codes Possible causes include: A) The user agent not supporting encrypted media B) The user agent not support encrypted media in the container format C) The CDM does not support [decoding] the codec(s). (A) would require that the user agent can detect the media is encrypted even though it has no decryption capabilities. This seems unlikely. If it did, MEDIA_ERR_SRC_NOT_SUPPORTED could be used. (B) could be reported as MEDIA_ERR_SRC_NOT_SUPPORTED. (C) could be reported as MEDIA_ERR_SRC_NOT_SUPPORTED or maybe MEDIA_ERR_DECODE. On the other hand, as noted in the FAQ, MEDIA_ERR_ENCRYPTED was added to avoid confusion (ambiguity). The FAQ also notes that MediaKeyErrors may not be fatal to playback where as MediaErrors are fatal. Depending on the decisions, we may want to rename MEDIA_ERR_ENCRYPTED. Also, we should be more specific about what errors should be returned in the cases above.
Assigned to Adrian to follow-up. More errors is better but we need them to be consistent across CDMs.
Bug 21798 is the placeholder for considering what error codes we should have. *** This bug has been marked as a duplicate of bug 21798 ***
I was just about to add "MediaError" to the summary. This bug relates to the single new MediaError code that is added. Most of the cases are covered by other bugs, though, so we can probably leave this closed.