W3C home > Mailing lists > Public > public-html-media@w3.org > January 2014

Re: EME: Rendering behavior undefined

From: Hans Schmucker <hansschmucker@gmail.com>
Date: Wed, 15 Jan 2014 11:34:38 +0100
Message-ID: <CAMtPrS__RKN5Ampd8WY_Gpk4-d-CWBjCdxbeCKsjM8NNu==+fA@mail.gmail.com>
To: Henri Sivonen <hsivonen@hsivonen.fi>
Cc: Pierre-Anthony Lemieux <pal@sandflow.com>, "<public-html-media@w3.org>" <public-html-media@w3.org>
The second paragraph mainly. The first one is actually unnecessary (and
slightly incorrect) since HTML5 defines such behavior:

http://www.w3.org/TR/2dcontext/#drawing-images-to-the-canvas
"If the image argument is an HTMLImageElement object that is not fully
decodable (...) then the implementation must return without drawing
anything."

I guess it's "may", because it's up to each CDM to decide. Some CDMs may
allow drawing its content to Canvas.

Reading the minutes of the last meeting, it seems that there is consensus
that dealing with rendering is outside the scope of the EME spec, BUT they
don't want to remove that section unless it is actually handled somewhere
else (I hope I'm reading this correctly).

Dealing with layering, transforms and so on is quite a bit more complex and
very likely outside the scope of HTML (certainly EME). Problem is that the
general fallback logic used in all other W3C standards can not be applied
here (unsupported instructions are ignored and fall back to the behavior
defined in the last supported version of the standard).
DOMImplementation.hasFeature might be a way to go, but it's dubious as
well, since it would change depending on the content of the document and
the EME element currently in use.

So far, the only correct way seems to be defining an exception to each and
every standard saying something along the lines of "If ANY descendent does
not support the feature (for example 2D transforms), then the instruction
is ignored on any parent". And provide a way to check for such cases with
something like Node.allowsFeature(transform|opacity|alpha|...).

--hans


On Wed, Jan 15, 2014 at 11:21 AM, Henri Sivonen <hsivonen@hsivonen.fi>wrote:

> On Wed, Jan 15, 2014 at 12:07 AM, Hans Schmucker
> <hansschmucker@gmail.com> wrote:
> > 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.
>
> Hmm. The draft has two sections 2.3. I take it that you mean the
> latter one of them.
>
> Do you object only to "Where media rendering is not performed by the
> UA, for example in the case of a hardware protected media pipeline,
> then the full set of HTML rendering capabilities, for example CSS
> Transforms, may not be available. One likely restriction is that video
> media may be constrained to appear only in rectangular regions with
> sides parallel to the edges of the window and with normal
> orientation."?
>
> Or do you also object to: "Media data processed by a CDM may not be
> available through Javascript APIs in the usual way (for example using
> the CanvasRenderingContext2D drawImage() method and the AudioContext
> MediaElementAudioSourceNode). This specification does not define
> conditions for such non-availability of media data, however, if media
> data is not available to Javascript APIs then these APIs may behave as
> if no media data was present at all."?
>
> Question to the editors: Why is the last part I quoted saying "may" in
> the last sentence instead of "must" and why is it marked
> non-normative?
>
> --
> Henri Sivonen
> hsivonen@hsivonen.fi
> https://hsivonen.fi/
>
Received on Wednesday, 15 January 2014 10:35:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:44 UTC