[Bug 16617] Consider more granular error reporting

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

David Dorwin <ddorwin@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |16857

--- Comment #2 from David Dorwin <ddorwin@google.com> 2012-04-27 21:01:02 UTC ---
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.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 27 April 2012 21:01:05 UTC