Re: EME: Rendering behavior undefined

Requested input on public-audio about non-redirectable sources:

http://lists.w3.org/Archives/Public/public-audio/2014JanMar/0031.htm


On Wed, Jan 15, 2014 at 1:28 PM, Hans Schmucker <hansschmucker@gmail.com>wrote:

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