Re: EME: Rendering behavior undefined

Hallo Pierre-Anthony,

You're correct, the problem is broader than EME. The hints from the rest of
the group were very helpful establishing that... my initial attempt at
fixing it inside the EME spec was just plain wrong.
So now, the first order of business is making sure that the EME spec does
not say anything about it, unlike what it currently does in the
introduction and 2.3.

Once we've established that and actually made that change, we should take a
look at HTML5.1 and see if we can slip the necessary changes in there.

--hans


On Tue, Jan 14, 2014 at 10:56 PM, Pierre-Anthony Lemieux
<pal@sandflow.com>wrote:

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