Re: Encrypted Media proposal

On Wed, 22 Feb 2012 00:16:42 +0100, Adrian Bateman  
<adrianba@microsoft.com> wrote:

> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

The core component upon which the impact of the proposal depends is the  
CDM. It seems clear that the "Clear Key" system is not enough to make all  
content providers happy, and that they will want more. For the proposal to  
work at the scale of the Web, there must emerge one or a few de facto  
standard CDMs that become required for viewing popular Web content.

The effect on barriers to entry to and competition within the browser  
market depends, of course, on who controls the CDMs and under what  
conditions they can be integrated with browser engines. If the de facto  
standard CDM cannot be freely (re-)implemented and shipped on any platform  
by any browser vendor, that may hinder competition and do damage to the  
long-term health of the Web. To evaluate this risk, it would help  
immensely if the details of the CDMs intended for production use, which  
surely must already exist, were publicly disclosed.

The second issue I want to highlight is the interaction between the CDM  
and the media stack, which are not as cleanly separated as the  
introductory figure suggests. In some scenarios discussed the CDM takes on  
a large part of what I would consider the media stack, including at least  
decoding and presentation of video. Presumably the situation is similar  
for audio. Not having full control over the audio/video decoders and their  
raw output means that:

1. We cannot fix bugs in the CDM or perform optimizations without  
coordination with the CDM provider. This is a problem with plug-ins that  
we would like to not repeat.

2. Audio/video sync must involve the CDM. Low-level control over this  
between different <video> elements is very important for the new  
multitrack API.

3. Rendering must likely use some form of overlay. Opera has this for some  
platforms, but it limits the functionality of the <video> element, e.g.  
CSS transforms (other than scale+translate) and CSS opacity won't work. We  
consider this a platform limitation and it is not something we really want  
to make a core requirement for <video>.

Finally, like several others in this thread, we would welcome clear  
documentation of requirements and use cases. If making it (nearly)  
impossible for the user to copy the data is not a design goal, then a more  
generic solution for encrypted (but cache-able) HTTP along the lines  
suggested by Henri Sivonen and Ian Hickson seems like a better starting  
point.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Friday, 2 March 2012 11:28:19 UTC