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

On Thu, Mar 8, 2012 at 8:45 AM, Philip Jägenstedt <philipj@opera.com> wrote:

> 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?


In general, they MPEG-2 or MPEG-4 are used at this time. Any transition to
WebM or other non-encumbered formats is a future activity.

All I can state are the requirements from a commercial video provider
perspective. If some browser vendors do not want to support this usage,
then that is a business decision they make; nor can I comment on the timing
on transitioning to newer, non-encumbered format support. From Cox's
perspective, that is a future possible activity, but not something with a
date on it.


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


>From our perspective, the core component of this proposal is *not* specific
the DRM clients (i.e., CDM instances), it is:

(1) the overall CDM architecture
(2) the JS looking APIs and semantics

If specific browser vendors wish to discuss specific CDM instances (other
than ClearKey), then that may be done in concert with your commercial
partners and DRM licensors.


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

First, (2) is not the same as the proposal under discussion, since it
entails non-standard architecture, non-standard JS or other interfaces. The
current proposal is an advance over (2) because it defines a standards
based architecture and JS looking interfaces.

Secondly, it doesn't matter whether you object to citing accessibility. The
fact is that <object> has fewer accessibility features than <video> (e.g.,
text tracks), and if commercial video providers are forced to use <object>,
then they won't be able to use those features.

Thirdly, your claim "a necessary side-effect, makes it impossible to
provide accessibility improvements like brightness/contrast controls or
audio filtering" is factually wrong.

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