Re: The subject line is irrelevant these days

On Thu, Oct 24, 2013 at 2:32 AM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:

> On Wed, Oct 23, 2013 at 6:53 PM, Mark Watson <watsonm@netflix.com> wrote:
> > On Wed, Oct 23, 2013 at 8:14 AM, Henri Sivonen <hsivonen@hsivonen.fi>
> wrote:
> >> On Wed, Oct 23, 2013 at 5:22 PM, Mark Watson <watsonm@netflix.com>
> wrote:
> >> > That's always going to be a business decision based on the costs and
> >> > benefits of supporting an additional platform.
> >>
> >> That this is the case is part of the mismatch between EME and how W3C
> >> specs normally are supposed to work and a source of a lot of grief.
> >
> > I understand. But it's the same with <object> and plugins (for all
> > applications of those, not just DRM).
>
> No, <object> and plug-ins are different from EME and CDMs. Indeed, the
> DRM-related NPAPI plug-ins themselves are not independently
> interoperable implementable.


I agree that EME/CDMs and plugins are different. But we were talking about
a specific point: whether the whole stack can be independently implemented
and on this point they are the same.



> However, an NPAPI plug-in host for a
> given operating system is independently interoperable implementable
> and so far DRMs have actually been available for NPAPI. That is not to
> say that things are all good with NPAPI plug-ins (there's a lot that's
> wrong with them), but there *is* a difference compared to the EME
> situation.
>

NPAPI was created by browser implementors after the fact of the <object>
standard. The same thing could happen with EME if you and the other browser
implementors choose. Or indeed a de-facto standard may emerge based on the
early open-source implementations of EME. I don't think we would want to go
the route of user-downloadable plugins for EME, but it would certainly make
the integration of third-party CDMs with UAs simpler.


> When a site like Netflix decides to use PlayReady via <object>,
> Microsoft ships the PlayReady implementation inside an NPAPI plug-in
> for free to users of versions of Windows that still receive security
> patches (XP and up) and OS X. That means that any browser on Windows
> all the way from and including XP and any browser on OS X can work
> with Netflix by implementing NPAPI (32-bit NPAPI on OS X, but still).
> Likewise, when a site like HBO Nordic decides to use pre-EME Widevine
> via <object>, Google ships the NPAPI Widevine Media Optimizer for free
> to users of any browser on Windows or OS X. This is not the case with
> EME-flavored PlayReady or EME-flavored Widevine.
>
> That is, with the NPAPI way of doing video DRM, browsers entering the
> market may do so by implementing the host side of NPAPI and gain
> compatibility with Netflix or HBO equal to other browsers on the same
> OS without there having to be a business decision by the sites to
> support a DRM that's coupled with an additional browser. (That doesn't
> help *operating systems* entering the market, of course.)
>
> EME may level the playing field for Tivoized devices for which
> Silverlight isn't available, but it very much unlevels the playing
> field for browsers on Windows and OS X (and even desktop Linux to the
> extent there's content available to the Flash Player 10.2 level of
> Adobe Access with Linux use not banned; I expect there exists some on
> Voddler).
>

I think that's why we have this bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944 and the spec is not
going to progress until that bug is resolved. It's certainly not in our
interests lose support for an OS/browser combination that we have today.

...Mark



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