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

On Thu, Mar 8, 2012 at 11:54 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> 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.
>
> Chrome and YouTube plan to support encrypted WebM. Hopefully others will
as well.
This option is not available in the current plugin-based environment.

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

Who said "the DRM component controls the entire rendering pipeline"? The
proposal does not require that the entire rendering pipeline be controlled
by the CDM; it just acknowledges that this is possible. It seems very
likely that at least some CDMs (in addition to Clear Key) will not control
the entire pipeline. Such CDMs will have advantages for accessibility, CSS,
etc.

Aren't accessibility features less likely if the content remains locked in
all-inclusive stacks? Features such as captions might require both the
stack and custom application to add support. If providers used <video>
instead, they could just use the same <track> implementation on all
platforms.

It's also worth noting that audio is not necessarily protected in the same
way as the video it accompanies. It might be worth calling out the
importance of such choices to accessibility.

>
> ~TJ
>
>