Re: Protected media element sources

I'm not convinced that such attributes would actually be of much use.
The web page is already in an excellent position to know whether or
not EME is in use, and it's likely that the answer to "does it work
with canvas" will be universally "no" for all kinds of encrypted media
and CDMs, no?

I guess that I'd like to see the problem shown in the wild before
trying to fix it.

Philip

On Sun, Jan 19, 2014 at 6:55 AM, Aaron Colwell <acolwell@google.com> wrote:
> The tracks are accessible to JavaScript via the audioTracks, videoTracks,
> textTracks attributes on the HTMLMediaElement. I'm suggesting that an
> attribute could be added to the AudioTrack, VideoTrack, and 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 spec adds a sourceBuffer attribute to these
> objects. The 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
>>>
>>>
>>
>

Received on Sunday, 19 January 2014 04:47:11 UTC