Re: EME compatibility with existing DRM systems

On Sat, May 11, 2013 at 2:15 AM, Niels Thorwirth
<nthorwirth@verimatrix.com> wrote:
> [NT]  I believe, in that case we’d lose the desired interoperability enabled
> by the EME where the JS client has visibility into the different DRMs
> supported by the content and the client and can chose a best match on a
> broad range of devices, or is there another way to coexist with other EME
> DRMs?

Treating DRMs that open a side channel and don't need the EME API
surface as distinct codecs for the purpose of the existing
canPlayType() method and the <source> selection algorithm.

> [NT] It may be desirable or necessary for authentication and authorization
> to be handled by the DRM client

Why might it be desirable (other than reusing existing side channel-based DRMs)?

Why might it be necessary?

> If it’s not required or desired it’s still the choice of the
> service provider to use the fitting DRM systems, e.g. those that are able to
> support a single front end license server.

Supporting only one DRM scheme would be even more harmful to
interoperability than supporting a multi-DRM solution like EME. I
think the W3C should reject requirements arising from single-DRM
scenarios.

> I see another significant advantage of supporting existing DRM systems and
> that is broad reach and quick adoption of EME.

It might lead to broach reach and quick adoption of *DRM* but not
*EME*, since making the communications between the CDM and the license
server mediated by the browser and the JS app is the fundamental
design of EME.

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

Received on Monday, 13 May 2013 10:29:49 UTC