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

It is important to understand the interoperability made possible by the ISO MPEG Common Encryption standard. With this standard, two user agents using CDMs tied to different Key Systems may consume the same media providing the operator trusts that Key System. This was specifically created to enable commercial media interoperability, and all of the major DRM providers - including Microsoft - are supporting this new standard.

I believe W3C developing EME is a matter of good web stewardship. Let me explain why. 

Cisco recently predicted that by 2016 the gigabyte equivalent of all movies ever made will cross global IP networks every three minutes - it would take 138 years to watch the video crossing that network every second, with video on demand traffic equivalent to 4 billion DVDs per month (Cisco Visual Networking Index: Forecast and Methodology, 2011-2016, http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360_ns827_Networking_Solutions_White_Paper.html). 

Web delivered video is becoming more than an alternative pipe for delivering broadcast television content, it is becoming a primary entertainment platform in its own right. Over time web and broadcast commercial media will become relatively indistinguishable to consumers.

Rapid growth will be brought about by new  standards. 
- ISO/IEC 23001-7: 2011, "Information technology - MPEG systems technologies - Part 7: Common encryption in ISO base media file format files"
- ISO/IEC 23009-1:2012, "Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats"

Common Encryption provides commercial web media interoperability - something entirely new for the web - with significant efficiencies for content delivery networks (CDN) and both network and edge-cache efficiency.
DASH enables media presentations to be defined which support live and on-demand delivery supporting "late binding" of alternate tracks. Not just for "adaptive bitrate streaming", but also as an interoperable mechanism for media presentation descriptions. Again with significant CDN, network and edge cache efficiency.

These specifications are being adopted worldwide by organizations like the Hybrid Broadband-Broadcast TV Consortium (HbbTV), the Digital Television Group (UK), and others. The pace of this adoption has been nothing short of staggering, across broadcasters, device manufacturers, and service providers.
Consumer experience of commercial web media

The Media Source Extensions (MSE) and the Encrypted Media Extensions (EME) - when combined with DASH and Common Encryption - constitute central components of a commercial web media receiver standard. 

A commercial web media receiver standard will enable web-connected devices to be "receivers" of standardized web media "transmitters", without the need of a native application for each media service, removing a central friction point for wide distribution of commercial web media, both live and on demand, while removing the consumer-unfriendly "smart TV" application navigation problem.

The significance of this cannot be overstated. Here is why.

With broadcast television, optical media, TCP/IP and the World Wide Web, standards produced an inflection point which enabled large scale growth - commoditizing some technologies and creating new  horizontal markets. These earlier inflection points came about because standards adoption decoupled the 'transmitter' (broadcast station, optical media replicator, web server) from the 'receiver' (television set, optical media player, web browser).

The significance of this type of inflection point is generally understood only after the fact, because it is difficult to see beyond what seems obvious to realize a possibility which on hindsight will become the new obvious.

The ability to move from the native application model to an interoperable web "video receiver" model is precisely one of those transformative inflection points and will provide enormous value to web consumers.

This is why the W3C developing the MSE and EME specifications is good web stewardship, consumer friendly and important to both the web and the broadcast industries.

John 




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

> -----Original Message-----
> From: Mark Watson [mailto:watsonm@netflix.com]
> Sent: Friday, February 01, 2013 11:51 AM
> To: Tab Atkins Jr.
> Cc: Glenn Adams; Jet Villegas W3C; L. David Baron; Robert O'Callahan;
> Sam Ruby; public-html-admin@w3.org
> Subject: Re: CfC: to publish Encrypted Media Extensions specification as
> a First Public Working Draft (FPWD)
> 
> 
> On Feb 1, 2013, at 10:58 AM, Tab Atkins Jr. wrote:
> 
> > On Fri, Feb 1, 2013 at 9:15 AM, Glenn Adams <glenn@skynav.com> wrote:
> >> Jet,
> >>
> >> It is difficult to assess the likelihood of such fallback scenarios.
> >> They are certainly possible, so it is in the hands of the service
> >> provider to make that decision.
> >
> > However, we can look at history to see how common the kind of fallback
> > you describe is.  As far as I can tell, it's rare to nonexistent.  The
> > distribution contracts usually require the use of particular
> > technologies, so deferring to "whatever the browser has built-in" will
> > likely never fly, and in nearly every case I can recall, there is no
> > "low-quality, unencrypted" version made available by the distributor.
> >
> > It seems to be wishful thinking to assume the video distributors will
> > suddenly change their mind on these matters and start offering up
> > video in the ways you describe.
> >
> >> From the perspective of commercial video service providers, the
> >> Flash/Silverlight approach is significantly worse than the EME/CDM
> approach.
> >> It is worse because the use of any specific CP system requires every
> >> UA vendor to independently build a distinct solution and for every
> >> use of that system to deploy UA specific API at the client
> >> application layer. That would not be the case with EME/CDM. So,
> >> speaking for Cox, EME/CDM is a huge improvement over the status quo.
> >
> > I don't understand how using Flash or Silverlight to run your DRM
> > requires more work for the browser than anything else.  Can you
> > elaborate?
> 
> There are two issues with the existing Flash/Silverlight situation. One
> is that there is a general move away from plugins. Browsers would like
> to remove or at least restrict what plugins can do. Microsoft have
> announced end-of-life for Silverlight.
> 
> 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.
> 
> >
> > It looks like you're avoiding the concern that has been repeatedly
> > brought up, which is that individual DRM providers have a long history
> > of only providing their stuff on the most profitable subset of
> > platform (often just one or two versions of Windows, and perhaps the
> > current Mac version), which means that the UAs are still stuck without
> > the ability to play any video at all.
> 
> That's certainly an issue. We would like our content to be available as
> widely as possible.
> 
> But that's not an issue we can solve here. It's tautological that
> content which requires a certain kind of protection will only be
> available on platforms where that protection is available. We can't, in
> W3C, change either the requirements of the content's authors or the
> platforms on which that protection is provided by the DRM vendors.
> 
> We can, however, make it technically easier. For example, for Microsoft
> and Samsung to make SIlverlight work on a Samsung TV would be quite an
> effort. One that I am pretty sure they will not attempt. But to make a
> CDM available through the encrypted media extensions would be a much
> lighter undertaking. The same for other platforms where DRM is not
> presently available through web plugins. I'm not saying it will happen,
> but we remove some technical barriers.
> 
> .Mark
> 
> >
> > ~TJ
> >
> >
> 
> 
>

Received on Friday, 1 February 2013 21:36:37 UTC