- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 13 May 2013 13:29:21 +0300
- To: Niels Thorwirth <nthorwirth@verimatrix.com>
- Cc: "public-html-media@w3.org" <public-html-media@w3.org>
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