ATM http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-media_err_encrypted defines MEDIA_ERR_ENCRYPTED to encompass various problems including: "The provided key could not be successfully applied".
This condition is impossible to implement in some encryption schemes and difficult to implement in others. It implies authentication (to differentiate between a decryption error and a decode error where decryption "succeeded" but generated garbage plaintext b/c of corrupt/incorrect key material or ciphertext) and is thus misleading, so it should be dropped (and a decode error event fired, instead).
Agreed. Need to update spec. Assigned to Adrian.
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().
For the record, the FAQ said, "Without a new error code (MEDIA_ERR_ENCRYPTED), it is not possible for user agents to clearly indicate to an application that playback failed because the content was encrypted and user agents will likely need to fire a MEDIA_ERR_DECODE or MEDIA_ERR_SRC_NOT_SUPPORTED, which would be confusing."
Given the comments above, we should consider whether such confusion is actually a problem and worth addressing with a new error code.
It seems that the natural pattern is that createSession is dependent on the information in needkey (the initData) and so it is no great imposition to require that all EME-aware applications register a needkey handler.
It's true that an application which has out-of-band knowledge of the initData may not really need to register to handle the needkey event, but such out-of-band knowledge - whilst it may be common - is very application-specific. I don't see that it's necessary for us to provide special handling for this case vs having the application nevertheless register a needkey handler.
Given this, the MEDIE_ERR_ENCRYPTED would be used for the case where there is encrypted data and no needkey handler, meaning it's a non-EME-aware application.
As discussed in the May 21st telecon, we will resolve per Mark's comment.
MEDIA_ERR_ENCRYPTED is now only reported when the application does not support encrypted content.
Per the discussion, a needkey handler is one way to indicate support. I added use of setMediaKeys() as another way to indicate support. The latter will not work in declarative cases but may still be useful for some applications
See https://dvcs.w3.org/hg/html-media/rev/80be415b8be1 and https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#dom-media_err_encrypted.
For future reference:
MEDIA_ERR_ENCRYPTED was removed entirely in https://dvcs.w3.org/hg/html-media/rev/cb3a898bcd64 per https://www.w3.org/Bugs/Public/show_bug.cgi?id=21203#c30