Re: EME: Rendering behavior undefined

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

Received on Sunday, 12 January 2014 23:51:54 UTC