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

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.


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

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.