The purpose of EME is to replace existing DRM solutions
implemented using non-HTML technologies such as Flash or
Silverlight with a HTML-based solution. Both these existing
technologies have at their core a platform-independent VM.
To not include a platform-independent VM in EME would be a
A platform-independent VM could be included either by
reference to an existing standard (e.g. Java or .NET) or by
defining a new VM. If a single VM cannot be agreed upon,
another option would be to allow several different VMs.
If a new VM was to be defined, one approach would be to use
ECMAScript + Typed Arrays as the VM. This would be
advantageous in that many browsers already have very good
ECMAScript VMs. A binary encoding for ECMAScript (or a
subset thereof) could be defined to help satisfy CDM providers'
concerns for obfuscation. Existing browsers could easily
translate this binary encoding to standard ECMAScript, or bypass
the textual representation and convert it directly to their own
internal representations of compiled ECMAScript.
Any CDM implemented on a platform-independent VM will
inevitably need to access native services. While these
services themselves are platform-specific, it is possible to
define bindings between VM and native code which are mostly
platform-independent. Consider for example P/Invoke on .NET,
or JNI or JNA under Java. If one or both of these existing
VMs were to be adopted, then these existing technologies
could be used to provide this facility. Alternatively, were
a new VM to be defined (such as my suggestion to base one on
ECMAScript + Typed Arrays), one could define a native
binding API for it based on the model of P/Invoke and JNA.
Some small platform-specific extensions may be required
(e.g. platforms that support multiple calling conventions,
such as Windows), but the binding could be defined in an
extensible manner, and such extensions could be standardised
for all the major platforms. One might also need to provide
an object-oriented binding for those platforms where
object-oriented APIs are prevalent (e.g. COM on Windows,
Objective C on MacOS/iOS), but again the cores of these OO
technologies are similar enough that a common extensible
binding could be shared between them, with some small
A single CDM could operate on multiple platforms by
dynamically determining what platform it was running on, and
then invoking the appropriate native services for that
(In reply to comment #0)
> A platform-independent VM could be included either by
> reference to an existing standard (e.g. Java or .NET) or by
> defining a new VM.
I object to using DRM as a pretext to make the Web Platform dependent on a massive additional execution environment that's strongly affiliated with a single vendor (Java, .NET or NaCl). The Web already has a standards body-defined VM that has multiple independent implementations: JS.
> If a single VM cannot be agreed upon,
> another option would be to allow several different VMs.
That's not particularly great compared to several different CDMs.
> If a new VM was to be defined, one approach would be to use
> ECMAScript + Typed Arrays as the VM. This would be
> advantageous in that many browsers already have very good
> ECMAScript VMs.
Using asm.js (http://asmjs.org/spec/latest/) in a Web Worker with a special-purpose global scope that provides integration points into the <video> pipeline would make much more sense than relying on Java, .NET or NaCl. asm.js performance as implemented in OdinMonkey is currently roughly half as fast as native compilation of the same C code, so the performance of asm.js is already in the Java/.NET ballpark.
> A binary encoding for ECMAScript (or a
> subset thereof) could be defined to help satisfy CDM providers'
> concerns for obfuscation. Existing browsers could easily
> translate this binary encoding to standard ECMAScript, or bypass
> the textual representation and convert it directly to their own
> internal representations of compiled ECMAScript.
Gzipped JS is an easily translatable binary representation of JS. Another binary representation is not worthwhile, because if the mapping from the binary representation to the normal representation is known, it wouldn't really provide true obfuscation, as it would be possible to provide tools that translate the primary representation to the normal representation.
> Any CDM implemented on a platform-independent VM will
> inevitably need to access native services.
If the input the the Worker is the bytes of an ISO Common Encryption file and the key messages of the nature outlined in EME, the output can be buffers representing frames or audio samples without any access to native services.
Discussed on the telcon:
This is one proposal for how to deal with CDM interop. Making a duplicate of 20944, which addresses this issue.
Note that the task force disagrees with the notion that the purpose of EME is to replace existing DRM solutions.
*** This bug has been marked as a duplicate of bug 20944 ***