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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 8 Mar 2012 11:54:16 -0800
Message-ID: <CAAWBYDC4e2Nk2nazgrxD_XeDW=ow2R6j_tZOi43Tw76PmdWCAg@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: Philip Jägenstedt <philipj@opera.com>, public-html@w3.org
On Thu, Mar 8, 2012 at 8:13 AM, Glenn Adams <glenn@skynav.com> wrote:
> 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.

So, based your and Mark's comments, commercial video providers:

* currently use royalty-encumbered video formats, but *might*
transition to RF formats in the future
* currently demand closed-source and/or royalty-encumbered CDMs, but
*might* transition to ClearKey or similarly open CDMs in the future

So right now commercial video is definitely in the worst-case
scenario, but it *might* get better in the future.  We have no
guarantees that it will.  If it *does* get better, we have no
guarantee that it will do so quickly enough to avoid baking the bad
stuff into the platform anyway for compat reasons.

This does not inspire confidence.


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

It is unacceptable to attempt to sidestep the *extremely* important
issue of what CDMs would *actually be used* with this proposal.
Whether or not you and your company finds it irrelevant, it's
definitely very relevant for those of us actually implementing it.


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

No, it's not.  Based on comments from you and Mark, current video
distributors will demand proprietary DRM components to plug into this
API.


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

Once again, nobody is forced to do anything.  They are free to use
<video> now; multiple examples show that it's completely viable.


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

Please explain how it is possible to provide accessibility
improvements like this if the DRM component controls the entire
rendering pipeline, providing the video to the browser as an overlay.

~TJ
Received on Thursday, 8 March 2012 19:55:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:46 GMT