RE: EME: Rendering behavior undefined

Hi Hans,
EME is about key management. Obviously decrypted content is intended to be rendered, but that is out of scope to the EME spec. It is a decoding level issue, as Dave suggested, below.
John

Sent from my Windows Phone
________________________________
From: Hans Schmucker<mailto:hansschmucker@gmail.com>
Sent: ‎1/‎12/‎2014 4:01 PM
To: David Singer<mailto:singer@apple.com>
Cc: <public-html-media@w3.org><mailto:public-html-media@w3.org>
Subject: Re: EME: Rendering behavior undefined

Thanks for the input David

I'm not sure it is correct though: The diagram right at the top says that CDM implementations may render the frame directly and 2.3 even deals with some of the fallout. Just not in a useful and normative way.

The correct way in my opinion would be disallowing direct rendering by the CDM entirely, but I don't think that's realistic at this point. But by allowing rendering outside of the browser we're introducing something that's not covered by the html media spec (naturally, because that's exactly what it was meant to replace), and as such we have to standardize it here.

--hans


On Mon, Jan 13, 2014 at 12:51 AM, David Singer <singer@apple.com<mailto:singer@apple.com>> wrote:
Hi Hans

since the handling of protected content is a decoding-level question and has no impact on presentation, I am unclear why we should say anything at all about rendering.  In fact, I am fairly sure we should say nothing, or at most what I just wrote.

The only ones that maybe we need to discuss are making the content available to other web apps, because the re-capture problem.

On Jan 10, 2014, at 6:18 , Hans Schmucker <hansschmucker@gmail.com<mailto:hansschmucker@gmail.com>> wrote:

> Reading through the current specification, it is pretty obvious that rendering the decrypted content may have different results if any of these change: surrounding web content, CDC module or user agent. This pretty much eliminates the need for any standard at all, since the result is entirely unpredictable, unless you control all three variables. Any combination of these would have to be tested and certified individually.
>
> The current text only explains what is likely to happen (2.3), based on experience from previous plugin-APIs, but it does not define an expected behavior, not even one that is in line with what we think is most likely to happen. EME is a practical standard, driven by a specific need, but that doesn't have to mean that it's a bad one.
>
> I suggest that we define a rendering behavior and do make it normative.
> Some ideas:
>
> 1. EME-protected content rendering happens in a separate frame, which overlays any HTML, SVG or other content that the user-agent may be able to process. However, a user-agent may display its own controls above the EME-protected content.
>
> 2. EME-protected content is not clipped, except against the primary viewport (not, for example, that of an iframe). The area of the EME-protected element is defined as the rectangle (as the defined by the HTML box model) occupied by the element.
>
> 3. The Coordinates that define the EME-protected rendering area are derived from the VIDEO element. However the transformation is not applied on a visual basis, meaning that for example an SVG offset filter would not play into the calculation. The result is identical to the result of getBoundingClientRect.
>
> 4. EME-protected content is not transparent. The user-agent must fill the area with solid black first.
>
> 5. Rendering happens in content-order. Where two EME-protected elements overlap, the last element will be shown.
>
> 6. It is inaccessible to any other web apis. No CSS filters, SVG Filters, transformations, zoom controls and so on affect it
>
> 7. Even if the user-agent is tasked with rendering the image, the behavior remains unchanged.
>
> Of course, that's not up to spec-standards yet. Just ideas to fix an issue that, in my opinion, tremendously diminishes the value of the standard. Any comments?
>
> --hans

David Singer
Multimedia and Software Standards, Apple Inc.