- From: Hans Schmucker <hansschmucker@gmail.com>
- Date: Wed, 15 Jan 2014 14:04:33 +0100
- To: Henri Sivonen <hsivonen@hsivonen.fi>
- Cc: Pierre-Anthony Lemieux <pal@sandflow.com>, "<public-html-media@w3.org>" <public-html-media@w3.org>
- Message-ID: <CAMtPrS9_UC-LG6UziPawoMAcDSxL7uC2AHr5pWWamrXmBYm5Hg@mail.gmail.com>
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:05:05 UTC