Re: EME: Rendering behavior undefined

> 6. It is inaccessible to any other web apis. No CSS filters,
> SVG Filters, transformations, zoom controls and so on affect it

I am not sure this will be true for all combinations of content, CDM
implementation and UA.

More generally, I would think that, independently of EME, not all UAs
will implement all "CSS filters, SVG Filters, transformations, zoom
controls" for all types of content and/or objects.

If so, isn't the question of determining the capabilities supported by
a UA for a given content broader than EME? Does such a mechanism exist
in HTML 5 (loosely speaking)?

Thanks,

-- Pierre

On Fri, Jan 10, 2014 at 6:18 AM, 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

Received on Tuesday, 14 January 2014 21:57:22 UTC