W3C home > Mailing lists > Public > public-html@w3.org > March 2012

Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

From: Mark Watson <watsonm@netflix.com>
Date: Thu, 1 Mar 2012 20:17:45 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: Henri Sivonen <hsivonen@iki.fi>, "<public-html@w3.org>" <public-html@w3.org>
Message-ID: <C0A6DC36-328F-4BC1-9D42-AC347937048C@netflix.com>

On Mar 1, 2012, at 10:37 AM, Tab Atkins Jr. wrote:

> On Thu, Mar 1, 2012 at 10:06 AM, Mark Watson <watsonm@netflix.com> wrote:
>> Henri,
>> Reading your mail I have a feeling we are talking a little at crossed
>> purposes. Part of this could be because the proposal is not yet clear enough
>> on the nature of CDMs and these discussions are very helpful in eeking out
>> the issues which need to be explained/addressed.
>> To clarify:
>> - a browser can have multiple CDMs for different keysystems
>> - what we propose to standardize is the discovery, selection and interaction
>> with CDMs, not the CDMs themselves (not unlike the current situation with
>> codecs).
> One point that has been made multiple times is that the current
> situation with codecs is *horrible*.  It is not a good solution that
> we should attempt to emulate; it's a filthy, painful hack that was the
> best we could do if we wanted a <video> element, given the standoff
> between browsers on which to support.

People made different decisions for good reasons. I wouldn't call it a standoff, just the way it is.

>  If there was a way to go back
> in time and convince everyone to use a single codec, that would be
> *great*.

I could agree with that statement, though if I had a way to go back in time I think there's different things I would do with that power ;-)

> We should not add another codec-war-style situation to the web
> platform unless we absolutely can't avoid it and the payoff is
> sufficiently great.

I don't see this as being like a codec-war. In that case you have to make alternative encodings targeting different browsers/devices, which is a real pain. In the content protection case, as long the container format supports an agreed common encryption scheme, then a single file can be decrypted by different content protection systems. So you can make one file which works on browsers/devices that have chosen to support completely different CDMs. We could even mandate that the encryption scheme is specified by the media container format, not the CDM, to ensure this. The architecture we propose also avoids having separate front-end servers, protocols and authentication/authorization per protection system, so supporting multiple protection systems becomes much easier.

An architecture with content protection delegated to CDMs is clearly not worse than the current plugin/codec situation, horrible though that may be. I believe it's substantially better. I believe it's unavoidable, since due to the IPR situation an actual CDM meeting common content license requirements cannot be fully specified in W3C specifications. And the payoff is very great (orders of magnitude increase in the content playable with web technologies).


> ~TJ
Received on Thursday, 1 March 2012 20:18:18 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:49 UTC