Re: EME: Rendering behavior undefined

I came here under the same impressions that the authors of these bugs were
under:

That it would not be realistic to expect anything but totally opaque
behavior from CDM vendors. But as you said, that didn't happen. We know
now, that CDM vendors WILL and DID accept some level of integration.

The problem is that we're running around in circles here:
The paragraphs as they stand now go beyond mere decoding... they deal with
rendering and integration, so naturally any discussion about them will go
beyond what EME should deal with.

So, the best way forward might be to remove those paragraphs from EME in
order to make it into a real decoding-only spec again and move the issues
over to the media spec where they belong. There we can discuss how
protected content in general should be treated (not just EME-protected
content).

--hans





On Mon, Jan 13, 2014 at 3:51 PM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:

> On Mon, Jan 13, 2014 at 2:45 PM, Philip Jägenstedt <philipj@opera.com>
> wrote:
> > On Mon, Jan 13, 2014 at 6:32 PM, Hans Schmucker <hansschmucker@gmail.com>
> wrote:
> >> In summary, they should be removed and at best be replaced with a note
> >> saying that usage of a CDM does not change the behavior of the video
> element
> >> in any way. Correct?
> >
> > Probably not entirely correct, since a video element can normally have
> > its pixels drawn to a canvas and its audio samples fed into the Web
> > Audio API. I haven't checked, but I'd be surprised if either of these
> > are possible using EME...
>
> The current spec text on that topic was added in response to
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21155 . It seems that
> the position of the spec is that the interaction with canvas, the Web
> Audio API and the like depends on the Robustness & Compliance
> provisions each CDM is subject to instead of depending on EME itself.
>
> --
> Henri Sivonen
> hsivonen@hsivonen.fi
> https://hsivonen.fi/
>