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

Re: Encrypted Media proposal: Summary of the discussion so far

From: Philip Jägenstedt <philipj@opera.com>
Date: Thu, 08 Mar 2012 16:45:44 +0100
To: public-html@w3.org
Message-ID: <op.wauzeii0sr6mfa@kirk>
On Thu, 08 Mar 2012 15:50:40 +0100, Glenn Adams <glenn@skynav.com> wrote:

> On Thu, Mar 8, 2012 at 7:25 AM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> I must ask, though, if the sponsors of this proposal truly believe that
>> the outcome of this will be a royalty-free CDM that can be implemented  
>> on
>> any platform, why bother with the intermediary steps?
> If commercial video providers are to make use of the <video> element to
> deliver *current* DRM encumbered content, then the browser must either
> implement a proprietary, non-standardized DRM-specific DRM client, or
> implement a standards based DRM client plugin. From the perspective of  
> Cox,
> as a commercial video provider, we prefer the latter over the former if  
> the
> mechanism for exposing this functionality is common across all browsers.
> Furthermore, if browser vendors should happen to mutually agree on the  
> client plugin mechanism as well, then that would enhance  
> interoperability.
> The current proposal satisfies the need of exposing a common interface to
> this functionality to the JS client code, and thus satisfies part of  
> these
> requirements.
> Regarding the use of non-IPR-encumbered CDM technologies, though that is
> something we would like to see happen over time, subject to content owner
> adoption, it won't happen overnight. There are huge investments in
> infrastructure and large libraries of content based on *current* DRM
> systems that would take considerable time to adopt even if the content
> owners began to authorize newer non-encumbered DRM systems.
> So the bottom line is that a solution that simultaneously requires
> transitioning to a new DRM solution is simply not an option at this time.
> It may become one over time, but business realities are otherwise.

Do current DRM content and systems use a royalty-free format like WebM?  
The answer is no, so it sounds like you're saying that browsers must  
support whatever format the content is in, presumably MPEG-4/H.264. Opera  
and Firefox don't and Google has stated that "H.264 [...] will be removed"  
[1] so how does this add up?

>> There's a huge difference in that we know what the current de facto
>> standard plug-ins are, but don't know what the de facto standard CDMs  
>> will
>> be or who will control them. As I have stated repeatedly, it would help
>> immensely to evaluate the risks if the details of the CDMs intended for
>> production use were publicly disclosed. Discussion without the full
>> information is frustrating for all parties.
> Many current DRM systems maintain non-disclosed aspects that cannot be
> revealed due to licensing restrictions, so this isn't going to happen.
> I would suggest browser vendors such as Opera discuss these matters with
> their commercial partners to (1) determine what the actual requirements  
> are
> at this time and (2) begin planning possible paths to transition to
> non-encumbered systems.

It's very troubling if the core component, the entire point of this  
proposal, cannot be discussed in the open.

> Just to be clear, the likely outcome of not proceeding with this proposal
> (or some equivalent) will be that:
> (1) commercial video providers will continue to use and rely on <object>
> and proprietary plugins (silverlight and flash), while reducing the  
> overall
> interoperability with HTML5 and while reducing access to new  
> accessibility,
> metadata, and media control functions of <video>;
> (2) commercial video providers will push browser vendors to implement
> proprietary DRM-specific DRM clients in order to add this functionality  
> to
> <video>;
> The current proposal avoids both of these outcomes while increasing
> interoperability and providing a path that can more readily lead to
> non-encumbered, fully disclosed DRM systems.

Isn't (2) exactly what this proposal is supposed to enable? I also object  
to citing accessibility in favor of something that has the sole purpose of  
preventing access to content and, as a necessary side-effect, makes it  
impossible to provide accessibility improvements like brightness/contrast  
controls or audio filtering.


Philip Jägenstedt
Core Developer
Opera Software
Received on Thursday, 8 March 2012 15:46:23 UTC

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