Re: CfC: to publish Encrypted Media Extensions specification as a First Public Working Draft (FPWD)

On Feb 1, 2013 8:52 PM, "Mark Watson" <watsonm@netflix.com> wrote:
> The other is that Flash/Silverlight each
> bring an entire, proprietary,
> presentation environment, playback
> APIs etc. We would like to use HTML5.
> It seems wasteful and inefficient to
> maintain this hugh codebase (both the
> Flash/Silverlight code itself and
> application code that runs in it) that just
> duplicates the functionality of browsers
> in all respects except one: that Flash
> and Silverlight have DRM and HTML5
> does not.

What you say makes perfect sense from your point of view. However, from the
point of view of a browser, the interface between the CDM and the browser
can become quite complicated and maybe even more so than in the case of
NPAPI if the CDM places low trust in the browser.

If the role of a black box CDM is to hide the AES key from the browser and
the CDM provides the browser with the decrypted codec data, the EME model
might be considered an obvious improvement over NPAPI. However, in cases
where the CDM does not trust the browser with the decrypted codec data, the
CDM will have to reimplement large parts of the kind of code that currently
exists in the video pipelines in the browsers. Moreover, since that second
implementation inside a black box is still expected to be perfectly
controllable using the JavaScript APIs provided by HTML5 and composable
with other platform features like CSS Transformations, the interface
between the browser and the CDM may easily end up with tighter coupling
than NPAPI today.

This CDM stuff would look a lot less scary if Netflix was able to say that
a CDM that gives the decrypted codec data back to the browser was enough
for SD feature films on Netflix.