W3C home > Mailing lists > Public > public-html@w3.org > March 2012

RE: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

From: John Simmons <johnsim@microsoft.com>
Date: Mon, 5 Mar 2012 16:05:33 +0000
To: Henri Sivonen <hsivonen@iki.fi>, Mark Watson <watsonm@netflix.com>
CC: Tab Atkins Jr. <jackalmage@gmail.com>, Glenn Adams <glenn@skynav.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "<public-html@w3.org>" <public-html@w3.org>
Message-ID: <FF4EB51321FAE847A9650D1E9ABB57A4408E3BC8@TK5EX14MBXC301.redmond.corp.microsoft.com>

John C. Simmons | Media Platform Architect | Microsoft Corporation | direct 425-707-2911  | mobile 425-269-5759

> -----Original Message-----
> From: hsivonen@gmail.com [mailto:hsivonen@gmail.com] On Behalf Of Henri
> Sivonen
> Sent: Sunday, March 04, 2012 11:02 PM
> To: Mark Watson
> Cc: Tab Atkins Jr.; Glenn Adams; Silvia Pfeiffer; <public-html@w3.org>
> Subject: Re: Encrypted Media proposal (was RE: ISSUE-179: av_param -
> Chairs Solicit Alternate Proposals or Counter-Proposals)
> On Fri, Mar 2, 2012 at 10:17 PM, Mark Watson <watsonm@netflix.com>
> wrote:
> >
> > On Mar 2, 2012, at 10:59 AM, Tab Atkins Jr. wrote:
> >
> >> No.  Again, a working CDM is *required* for this API to be of any
> use.
> >> If implementing a working CDM is troublesome or impossible for
> >> various reasons, that makes the API itself useless.
> >
> > The clearkey keysystem was intended to provide a simple baseline. A
> working clearkey CDM would be easy to implement, requiring no trade
> secrets or closed source obscurity (Usual IANAL disclaimer about IPR).
> The clearkey keysystem baseline is entirely irrelevant if Netflix won't
> target Hollywood content to it. OTOH, if Netflix will target Hollywood
> content to it, we should only spec clearkey and not bother with other
> CDMs.

This is not a proposal to enable Netflix. This is a proposal to enable interoperable commercial video delivery, meeting the requirements of that industry, and that interoperability depends upon standards.

The consequences of not supporting this type of proposal will not be that the commercial video industry abandons DRM or adopts clearkey. The consequence will be that they continue to use native applications and plug-ins to support the level of content and service protection that they require. IMO this would be a disservice to the countless people who want to be consumers of those video services.

The reason why we promoted the "Common Encryption" standard was to enable interoperability between CDMs. This is a major technological breakthrough and it will be supported by every major CDM provider. The goal of this work has been to enable interoperable commercial video delivery - meeting both the needs of the commercial video industry and the users who want to consume those video services. 

The broad industry drive to create commercial video interoperability is highly laudable, and not the least bit "unethical" as some on this thread have stated.

The commercial video industry also drove the creation of an adaptive streaming standard. There are numerous non-interoperable adaptive streaming technologies used on the web, and they all support encryption. The Live and On-Demand ISOFF DASH specifications support common encryption, and the number of 'broadband-broadcast convergence' fora worldwide who are adopting these interoperable standards is testimony to their significance. That interoperability will mean different CDMs can consume the same live television stream on the internet. 
The commercial video industry requires the ability to support service and content protection, CDM interoperability is made possible by the new common encryption standard and enabling CDMs in HTML will have a profound, positive impact for embedded devices - such as televisions, DVD players and mobile phones. That is the backdrop of this proposal. 

It is a highly worthwhile and laudable goal.

> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/


Received on Monday, 5 March 2012 16:06:27 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:49 UTC