W3C home > Mailing lists > Public > public-html-admin@w3.org > February 2013

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

From: Mark Watson <watsonm@netflix.com>
Date: Fri, 1 Feb 2013 19:51:27 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: Glenn Adams <glenn@skynav.com>, Jet Villegas W3C <w3c@junglecode.net>, "L. David Baron" <dbaron@dbaron.org>, Robert O'Callahan <robert@ocallahan.org>, Sam Ruby <rubys@intertwingly.net>, "public-html-admin@w3.org" <public-html-admin@w3.org>
Message-ID: <9A4E7111-B8B5-4546-9AB1-708A0D1AE71A@netflix.com>

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.


> ~TJ
Received on Friday, 1 February 2013 19:51:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:57:21 UTC