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

On Feb 1, 2013, at 1:24 PM, Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:


On Fri, Feb 1, 2013 at 11:58 AM, Tab Atkins Jr. <jackalmage@gmail.com<mailto:jackalmage@gmail.com>> wrote:
On Fri, Feb 1, 2013 at 9:15 AM, Glenn Adams <glenn@skynav.com<mailto: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.

Actually there is, and, in the U.S., it is mandated by FCC regulations, and it is either analog composite or component output, potentially with down resolution processing. Beyond that, devices are free to implement and service providers are free to use other outputs.

Also, to be noted, the present discussion has to do with media stream playback, and not media stream recording or downloading. The EME presently is defined to work in concert with a UAs HTMLMediaElement stack, and, as of now, there is no W3C defined mechanism for storing that stream.

So part of the DRM equation, namely, protecting downloaded|stored media doesn't yet come into play with EME.


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.

Since I represent a commercial video provider here, I can speak authoritatively that they are interested in providing services to the widest array of users in the widest array of platforms, etc. So you would be wrong to conclude that they will never provide alternative means of media delivery in the HTML5 context even if the UA doesn't  have a builtin CDM that is preferred and has no extension mechanism to permit 3rd party CDM installation.


> 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?

MarkW has commented on this, but I will repeat and extend:

 *   flash & silverlight are not available on all platforms that Cox would like to target, which, beyond traditional desktop platforms, includes set-top boxes, televisions, mobile phones, automobiles, airplanes; in other words, any platform that can or does support HTML5
 *   flash & silverlight carry a significant amount of baggage, which makes their use a much more expensive proposition regarding porting, maintaining, licensing, etc

 *   flash & silverlight don't necessarily support or represent the CP systems that Cox would prefer
 *   flash & silverlight are static solutions in respect to new CP systems under development, such as Ultraviolet and others

[steele] Adobe is a participant in the DECE and Adobe Access supports Ultraviolet content. I am not sure what you mean here. Can you clarify?

Overall, Cox *has* tried the flash/silverlight approach, and finds it lacking in many ways. EME provides a break from this path and introduces new opportunities and efficiencies that otherwise do not exist in the status quo.


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.

Firstly, it is content service providers, e.g., commercial video providers like Cox, Comcast, AT&T, etc., that make the decisions about how to deliver their services and what technologies to use. Sure, in some cases, their choices are restricted due to business terms from some content owners for some content, but that is not a universal restriction.

The goals of content service providers is to provide their services to the widest array of users under terms that they believe are reasonable. They wish to use HTML5 to do this in order to deliver video content, but HTML5 doesn't support encrypted media content, unless that process is built into specific media format decoders, which is an architectural mess and a high bar to providers that can identify and use solutions like EME where that problem doesn't exist.

What has occurred with some uses of CP/DRM in the past is not a predictor for how some or all uses of CP/DRM will occur in the future. EME creates new opportunities and thus a new future.