- From: Hans Schmucker <hansschmucker@gmail.com>
- Date: Wed, 15 Jan 2014 13:28:24 +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: <CAMtPrS_0WjvoWv93DmW+Vu=ky+P5e8e6nsGD4THHCQX=_MRTKg@mail.gmail.com>
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 12:28:54 UTC