Re: EME: Rendering behavior undefined

I've added a comment to the public-canvas-api on this issue. Let's see
what's the response there.

http://lists.w3.org/Archives/Public/public-canvas-api/2014JanMar/0042.html



On Wed, Jan 15, 2014 at 11:39 AM, Hans Schmucker <hansschmucker@gmail.com>wrote:

> Ah sorry, slight mistake on my part: The "not decodable" part only applies
> to Image elements, while VIDEO has another set of restrictions:
> "if the image argument is an HTMLVideoElement object whose readyStateattribute is either
> HAVE_NOTHING or HAVE_METADATA, then the implementation must return
> without drawing anything."
>
> That would have to be extended to include protected content (either via an
> internal or a public property).
>
>
> On Wed, Jan 15, 2014 at 11:34 AM, Hans Schmucker <hansschmucker@gmail.com>wrote:
>
>> 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/
>>>
>>
>>
>