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

Re: [Bug 20944] New: EME should do more to encourage/ensure CDM-level interop

From: Mark Watson <watsonm@netflix.com>
Date: Sat, 2 Mar 2013 18:10:15 +0000
To: Fred Andrews <fredandw@live.com>
CC: "robert@ocallahan.org" <robert@ocallahan.org>, "public-html-media@w3.org" <public-html-media@w3.org>
Message-ID: <B2454CB4-471C-4B4F-9EA1-7186FF86737B@netflix.com>


Sent from my iPhone

On Mar 2, 2013, at 2:28 AM, "Fred Andrews" <fredandw@live.com<mailto:fredandw@live.com>> wrote:



> Date: Sat, 2 Mar 2013 22:25:13 +1300
> From: robert@ocallahan.org<mailto:robert@ocallahan.org>
>
>> On Sat, Mar 2, 2013 at 3:28 PM, Fred Andrews <fredandw@live.com<mailto:fredandw@live.com>> wrote:
>> There does not appear to be anything that a 'standard' can do to compel a CDM
>> author to publicly reveal the operation of a CDM or even the interface.
>
> IANA does this kind of thing with its "specification required" policy and there's
> no reason something like that couldn't work for us too.

Perhaps if I understood how the specification would support
independent implementation it would be clearer to me.

>> The proposed solution 'to enable independent implementation in user-agents'
>> does not appear to be generally practical because this assumes that it is
>> possible to maintain 'protection' when implemented in this context.  For example,
>> a CDM implemented in a web browser would give the browser access to the
>> decoded stream allowing the content to be saved, and alternatively an open
>> source stack could have an OS level 'stream access' feature to save content.
>
> It is definitely possible to have a CDM that does not give the browser access
> to the decoded stream.

Yes, but it not clear to me how this could be possible when the CDM is
part of 'independently implemented' web browser, or when the CDM
runs in a context hosted by an independently implemented operating
system?

If you know a way then it would be appreciated if you could explain the
architecture?


I think you are assuming that 'independently implemented' implies 'does not contain non-user modifiable components'.

As I have said before, we are faced with two groups of people. One group does not allow the software they author to be 'tivoized' (for want of a better term). We can also include those who choose not to use 'tivoized' software in this group. Another group does not allow the media content they author to be viewed on devices that do not include 'tivoized' components. And never the twain shall meet.

This is fine. I fully respect and understand the choices these people have made. We should not take sides and indeed I cannot see how doing so would be compatible with the basic moral rights of authors with respect to their own works.

So, lets assume that at least the stronger CDMs include non-user-modifiable components. This is not incompatible with independent implementation or with the source of those components being licensed under an open source license, though obviously not GPLv3.

Also note that EME can also support weaker CDMs.

...Mark

>> B. A proprietary stack that provides a protected context for the CDM
>> that an open source web browser can defer to, and that does not permit
>> the open source web browser to access the decoded stream for
>> implementing a convenient 'save as' option.
>
> That's one way to do it.

In this case only the interface to the CDM is part of the 'independently
implemented' code and the CDM is still proprietary code running on
a proprietary OS.

>> None of these would be compatible with Roberts proposal.
>
> Your options A, B and C are all compatible with my proposal. Why wouldn't they be?

Because they all depend on proprietary operating components
that are can not be 'independently implemented'.

Perhaps you have a different definition than me of what
'independent implementation in user-agents' means for a
CDM, and it would help me if you could clarify this so I know
what you are talking about?

cheers
Fred
Received on Saturday, 2 March 2013 18:10:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:58 UTC