Re: EME: Rendering behavior undefined

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