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

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

From: Glenn Adams <glenn@skynav.com>
Date: Thu, 8 Mar 2012 15:04:18 -0700
Message-ID: <CACQ=j+cSqM_yLEnUXTQq8efJBOXHySe=mMWYvEzgZBqFmT2JqQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Philip J├Ągenstedt <philipj@opera.com>, public-html@w3.org
On Thu, Mar 8, 2012 at 12:54 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Thu, Mar 8, 2012 at 8:13 AM, Glenn Adams <glenn@skynav.com> wrote:>
> 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.


There is nothing in the proposal that mandates any of:

(1) "the DRM component controls the entire rendering pipeline"
(2) "providing the video to the browser as an overlay"

If what you say is true, then the same comment would equally apply to
canvas.getContext().

The facts are that whether or not (1) or (2) is true depends on (A) how the
browser implements the proposal, the media pipeline, and video frame
compositing, and (B) what control features the browser is willing to
delegate to a CDM instance.

A browser implementer may choose (A) or (B) based on their own criteria,
which is not specified in the proposal. Some browsers may choose (A) or (B)
in a manner that precludes the use of certain CDMs. That's fine, and that's
outside the scope of the proposal as far as I'm concerned. That is a
business decision that should not be dictated by a W3C specification.
Received on Thursday, 8 March 2012 22:05:06 GMT

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