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

On Fri, Feb 1, 2013 at 11:58 AM, Tab Atkins Jr. <jackalmage@gmail.com>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.
>

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

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.