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

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  
> DRM
> 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.

[1]  
http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Thursday, 8 March 2012 15:46:23 UTC