Re: Protected media element sources

Problem I see (but maybe I'm overlooking something):

Is the actual track (except if its specified via TRACK) even accessible to
scripts? I think you're right, ideally this is something we'd want on a
per-track basis, but I'm not sure if the win is big enough to outweigh
inaccessibility by scripts.

--hans


On Sat, Jan 18, 2014 at 8:49 PM, Aaron Colwell <acolwell@google.com> wrote:

> 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
>>
>
>