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 14:39:07 +0100
Message-ID: <CAMtPrS_fwazR9Mw8gvLCs9Zdg-O2L43Q18nVqSH2k97P8bbQcA@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>
Response from Paul on public-audio:

There is consensus to treat the audio stream as silent and it will be
eventually reflected by the spec. He'll bring it up again in the next

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

> 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/
Received on Wednesday, 15 January 2014 13:39:40 UTC

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