Bug 16857 - Revisit causes of MEDIA_ERR_ENCRYPTED
Summary: Revisit causes of MEDIA_ERR_ENCRYPTED
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: David Dorwin
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 16617 21203
  Show dependency treegraph
 
Reported: 2012-04-25 19:45 UTC by Ami Fischman
Modified: 2014-01-28 00:01 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ami Fischman 2012-04-25 19:45:33 UTC
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).
Comment 1 Adrian Bateman [MSFT] 2012-08-28 21:22:22 UTC
Agreed. Need to update spec. Assigned to Adrian.
Comment 2 David Dorwin 2013-04-24 17:02:50 UTC
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().
Comment 3 David Dorwin 2013-05-07 00:16:27 UTC
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.
Comment 4 Mark Watson 2013-05-07 15:59:59 UTC
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.
Comment 5 David Dorwin 2013-05-21 15:26:06 UTC
As discussed in the May 21st telecon, we will resolve per Mark's comment.
Comment 6 David Dorwin 2013-05-24 23:41:04 UTC
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.
Comment 7 David Dorwin 2014-01-28 00:01:51 UTC
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