Re: EME: Rendering behavior undefined

Then the spec should reflect that.

Right now there are special provisions dealing with direct rendering by the
CDM. If presentation is entirely outside the scope of EME, we should and
cannot imply that any part of the normal rendering pipeline may be
circumvented, just because EME is used to decrypt the content. This would
actually be exactly what I'm hoping for, it's just not what the currently
published document says.

--hans


On Mon, Jan 13, 2014 at 1:18 AM, John Simmons <johnsim@microsoft.com> wrote:

>  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 <hansschmucker@gmail.com>
> Sent: ‎1/‎12/‎2014 4:01 PM
> To: David Singer <singer@apple.com>
> Cc: <public-html-media@w3.org> <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> 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>
>> 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.
>>
>>
>