Re: Protected media element sources

Aaron... sorry, I simply overlooked those attributes. You're right, that's
exactly where the protected attributes should live.

Philip:
There are many different answers to this:
The reason this came to be is actually not because script authors need to
know, but because other specifications shouldn't have to repeat the
definition of protected content over and over again.
Script-accessibility is merely a bonus.

But, it's also quite useful. The thing is, a video may contain different
sections with different restrictions. Just because EME is in use, doesn't
necessarily mean that the stream is protected all the time, and not
necessarily all streams.
EME has a relatively narrow use case, but within in that use case,
enumerating the streams and disallowing/allowing for example sharpen
filters or echo effects based on their protection level doesn't seem all
that unlikely.

--hans



On Sun, Jan 19, 2014 at 5:46 AM, Philip Jägenstedt <philipj@opera.com>wrote:

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