Re: Protected media element sources

The tracks are accessible to JavaScript via the
audioTracks<http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#audiotracks>,
videoTracks<http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#videotracks>,
textTracks<http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#texttracks>
attributes
on the HTMLMediaElement. I'm suggesting that an attribute could be added to
the AudioTrack<http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#audiotrack>,
VideoTrack<http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#videotrack>,
and TextTrack<http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#texttrack>objects
that indicate the "protected" status of each track. It seems like
EME could define this extra attribute as an extension to these objects much
like the Media Source
Extensions<https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source.html#audio-track-extensions>
spec
adds a sourceBuffer attribute to these objects. The
public-html-media<http://lists.w3.org/Archives/Public/public-html-media/>list
is probably a better venue to discuss such a change to EME though.

Aaron


On Sat, Jan 18, 2014 at 12:14 PM, Hans Schmucker <hansschmucker@gmail.com>wrote:

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