Primary eng (and PM) emails
xhw...@chromium.org, ddo...@chromium.org, qin...@chromium.org, jlu...@chromium.org, punya...@chromium.org
Spec
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
Summary
This feature intends to bring the baseline Encrypted Media Extension API (EME) with Clear Key to Chrome on Android. EME allows for playback of protected media content natively in the browser. This EME for Chrome on Android intent-to-ship addresses the baseline specification using a clear key system. The content can be protected and encrypted in numerous methods and the EME specification "does not define a content protection or Digital Rights Management system. Rather it defines a common API that may be used to discover, select, and interact with such systems as well as with simpler content encryption systems. Implementation of Digital Rights Management is not required for compliance with this specification: only the simple clear key system is required to be implement as a common baseline" (source: Abstract from EME specification http://goo.gl/3Df8h) "The clear key system indicates a plain-text clear (unencrypted) key will be used to decrypt the source. No additional client-side content protection is utilized." (source: http://goo.gl/27Hl3) A separate intent to ship will incorporate the EME API with the Widevine CDM for Chrome on Android.
Link to “Intent to Implement” blink-dev discussion
Not one specific to the Chrome on Android.
There was an intent to implement announcement to unprefix the EME API: http://goo.gl/Z9zo7V
The initial implementation on Chrome on Android will be prefixed. But once unprefixing is completed on desktop, it will carry over to Chrome on Android.
Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes
OWP launch tracking bug?
Row on feature dashboard?
Yes. (There isn't one specific to Chrome on Android but a general feature does exist for the EME API.)To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
I support having parity between our platforms. Android should not be
exposing a different web API from the rest of the Chrome platforms.
What implementation changes are required to add this support to
android? I assume you're just changing a #define or a
RuntimeEnabledFeature? Presumably just this line of code:
https://code.google.com/p/chromium/codesearch#chromium/src/content/child/runtime_features.cc&sq=package:chromium&rcl=1376997784&l=94
?
I'm actually not even sure why that line exists, given that encrypted
media is already enabled by default in:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/RuntimeEnabledFeatures.in&q=runtimeenab&sq=package:chromium&l=41
Maybe you're proposing changing this line?
https://code.google.com/p/chromium/codesearch#chromium/src/content/child/runtime_features.cc&sq=package:chromium&rcl=1376997784&l=27
This post was referencing the exposure of the EME APIs and Clear Key comes for free. It has already been implemented. It is being used for testing. I have created a separate post covering EME with the Widevine key system.
It's possible that Clear Key will be used for some real content. If that does not happen, then there would not be a problem removing it because there would not be any content depending on it.
Regardless, Clear Key is a required part of the spec [1].
On Thu, Aug 22, 2013 at 8:49 PM, <punya...@chromium.org> wrote:
It's possible that Clear Key will be used for some real content. If that does not happen, then there would not be a problem removing it because there would not be any content depending on it.Why would you want to use this for real content?
Regardless, Clear Key is a required part of the spec [1].Perhaps we should change the spec. It doesn't seem like anyone else has implemented this stuff yet so there's plenty of time to change it.
On Thu, Aug 22, 2013 at 10:10 PM, Elliott Sprehn <esp...@chromium.org> wrote:
On Thu, Aug 22, 2013 at 8:49 PM, <punya...@chromium.org> wrote:
It's possible that Clear Key will be used for some real content. If that does not happen, then there would not be a problem removing it because there would not be any content depending on it.Why would you want to use this for real content?Note that the ClearKey system as defined doesn't prevent one from using other cryptographic mechanisms to transport the key securely, e.g., WebCrypto. Only the hand off to the EME API would entail having decrypted the key. Encrypted content can then be decrypted by the ClearKey CDM. So I would not expect that it won't be used in some use cases.
PK
On Fri, Aug 23, 2013 at 12:20 AM, Peter Kasting <pkas...@google.com> wrote:
On Thu, Aug 22, 2013 at 9:43 PM, Glenn Adams <gl...@skynav.com> wrote:
On Thu, Aug 22, 2013 at 10:10 PM, Elliott Sprehn <esp...@chromium.org> wrote:
On Thu, Aug 22, 2013 at 8:49 PM, <punya...@chromium.org> wrote:
It's possible that Clear Key will be used for some real content. If that does not happen, then there would not be a problem removing it because there would not be any content depending on it.Why would you want to use this for real content?
Note that the ClearKey system as defined doesn't prevent one from using other cryptographic mechanisms to transport the key securely, e.g., WebCrypto. Only the hand off to the EME API would entail having decrypted the key. Encrypted content can then be decrypted by the ClearKey CDM. So I would not expect that it won't be used in some use cases.Has anyone expressed real interest in such an implementation?
I am not keen on the idea of having something in a spec because it serves a theoretical purpose. It would be easy to add this if it became practically desirable, but why not leave it out until then?
On Thu, Aug 22, 2013 at 11:29 PM, Glenn Adams <gl...@skynav.com> wrote:
On Fri, Aug 23, 2013 at 12:20 AM, Peter Kasting <pkas...@google.com> wrote:
Has anyone expressed real interest in such an implementation?
I am not keen on the idea of having something in a spec because it serves a theoretical purpose. It would be easy to add this if it became practically desirable, but why not leave it out until then?If it does not exist in implementations, people cannot use it and would be forced to use various other key systems.