Re: EME-protected VIDEO element and drawImage

Thank you Rik,

I had simply overlooked that decodable has a proper definition in the spec.

There's a reason that origin-clean isn't enough... a EME CDM will typically
have to control all copies of a protected frame, which means that the
browser will often not have access to it, unless the CDM is part of the
browser itself and the vendor guarantees that the whole browser is secure.
So drawImage can't access the frame's content at all if the CDM doesn't
allow it. And we somehow have to make sure that this possibility is somehow
reflected in the spec. The difficult thing is that this is actually outside
the scope of EME, but it will be required by CDM vendors.

Changing VIDEO to have a protected state isn't a bad idea. I'll try to
raise the issue there... it would simply have been more convenient if it
could have been done in one spec instead of two and "decodable" seemed like
a good loophole. :)

--hans


On Wed, Jan 15, 2014 at 6:51 PM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
>
> On Wed, Jan 15, 2014 at 4:25 AM, Hans Schmucker <hansschmucker@gmail.com>wrote:
>
>> There is a slight issue wit EME protected and Canvas, since EME-protected
>> content may not be drawable, because it is protected.
>>
>> There are already provisions in the Canvas2DContext specification which
>> are already nearly able to deal with this issue, but they're a little to
>> narrowly defined.
>>
>> Specifically:
>>
>> http://www.w3.org/TR/2dcontext/#dom-context-2d-drawimage :
>> "If the image argument is an HTMLImageElement object that is not fully
>> decodable, or if the image argument is an HTMLVideoElement object whose
>> readyState attribute is either HAVE_NOTHING or HAVE_METADATA, then the
>> implementation must return without drawing anything."
>>
>> EME does not affect the readyState, but it may not be fully decodable.
>> Problem is, that condition only applies to HTMLImageElement.
>>
>
> How is it not decodable?
> From the spec:
>
> When an img<http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element> element
> is in the completely available<http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#img-all>
>  state *and* the user agent can decode the media data without errors,
> then the img<http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element> element
> is said to be fully decodable.
>
>
> Since the user agent can decode the encrypted video stream, this property
> doesn't apply.
>
>  I would suggest we change it, so that it applies to HTMLVideoElement as
>> well:
>>
>> "If the image argument is an HTMLImageElement or HTMLVideoElement object
>> that is not fully decodable, or if the image argument is an
>> HTMLVideoElement object whose readyState attribute is either HAVE_NOTHINGor
>> HAVE_METADATA, then the implementation must return without drawing
>> anything."
>>
>> Does anybody see any issues with that?
>>
>
> The text for  "fully decodable" is only for images.
> I believe you should request to update the <video> tag [1] so it can flag
> the protected state. The canvas spec can then refer to that flag.
> Is there a reason why this flag would disallow drawing? It seems that
> setting the *origin-clean* flag to false is sufficient.
>
> 1:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#the-video-element
>