Re: Protected media element sources

It seems to me that it would be better to put a 'protected' attribute or
something similar on the individual track objects instead. Then Canvas,
WebAudio or whatever could use language along the lines of "If the
selected/enabled tracks have their protected attribute set, then ...". This
would also enable things like WebAudio to consume the enabled tracks that
are not protected even if one of the enabled tracks IS protected. Now this
may be a weird edge case, but I think it would provide maximum flexibility
for the application in the presence of mixed content.

Aaron


On Sat, Jan 18, 2014 at 3:57 AM, Hans Schmucker <hansschmucker@gmail.com>wrote:

> Hello,
>
> there's a slight problem with how Encrypted Media is handled by other web
> standards, if the user agent is unable to access the content, because the
> CDM is an external application/library.
>
> The easiest case is the case of the Canvas 2D context trying to draw a
> protected video, so I'm trying to solve this issue first and extrapolate
> from there. On the Canvas2DContext mailing list, I've asked about it and
> they think that it would probably be best if media elements in general
> would include attributes indicating protected content, that the 2D context
> and other standards could reference, instead of defining "if the element is
> a video element and the element is protected with EME and the CDM is
> indicating that the content can not be drawn to canvas" over and over again.
>
> There really aren't a lot of requirements for these attributes... about
> the only thing that would have to be decided is how many... do we need one
> for audio? A separate for subtitles or meta data? Or is it reasonable to
> assume that if  any one channel is protected, then an unprotected second
> channel wouldn't be much use anyway?
>
> 4.8.10 Media elements
>
> readonly attribute boolean videoProtected = false;
> readonly attribute boolean audioProtected = false;
>
> The videoProtected may be set by any implementation indicating to other
> APIs and script access that the content of the frame, including visual
> information such as subtitles will not be available for anything but direct
> drawing to the screen. The attribute may change value at any given time,
> depending on the result of video decoding process.
>
> The description of the audioProtectes attribute is mostly identical, but
> deals with audio processing.
>
> Seems like a useful set of attributes, but since video would also limit
> access to subtitles, there might be unintended and unnecessary
> accessibility issues.
>
> Does anybody see any other issues?
>
> --hans
>