[Bug 16857] Revisit causes of MEDIA_ERR_ENCRYPTED

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

David Dorwin <ddorwin@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|MEDIA_ERR_ENCRYPTED should  |Revisit causes of
                   |exclude decrypt failure     |MEDIA_ERR_ENCRYPTED

--- Comment #2 from David Dorwin <ddorwin@google.com> ---
Another listed cause is "The user agent does not support decryption of this
media data". One problem with this is that the UA may not know whether content
is encrypted if it doesn't support decrypting a given container. Therefore, I
think this case should be handled by the existing MEDIA_ERR_SRC_NOT_SUPPORTED.
If there is agreement, we would just remove it.

That would leave "The stream could not be played because it is encrypted and no
key was provided and no needkey handler was provided."

However, it seems there might be valid scenarios that don't fall into the above
condition. For example, an application might be in the process of acquiring
keys but not be using needkey.

The goal of the remaining case was to provide some level of backwards
compatibility for apps that are not aware of or do not support EME or encrypted
streams. Without an error, the media element may just hang with no notification
(handled event) to the app.

If we want to continue to provide this capability, we need to figure out a way
to detect (without false negatives) that an application is aware of EME. We
could add "and the keys attribute is null", but that would not cover all cases
either since loading (and thus encountering of an encrypted stream) could occur
before the application has the chance to call setMediaKeys().

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

Received on Wednesday, 24 April 2013 17:02:56 UTC