W3C home > Mailing lists > Public > public-web-and-tv@w3.org > September 2011

Re: [MEDIA_PIPELINE_TF] Common content security requirements

From: Mo McRoberts <mo.mcroberts@nexgenta.com>
Date: Thu, 1 Sep 2011 21:53:47 +0100
Cc: "Mays, David" <David_Mays@Comcast.com>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Message-Id: <5922245A-3EC2-4FF2-AE41-43FD9C25E75F@nexgenta.com>
To: Mark Watson <watsonm@netflix.com>

On 1 Sep 2011, at 20:42, Mark Watson wrote:

> Regarding 'canPlayType' specifically, I'm not sure it does do what is required.
> When I specify a video/mp4 file as a source, I don't necessarily know what protection schemes can be used with that file.

Then don't specify video/mp4. Or specify "video/mp4; protection=foobar" (and if <video>-supporting browsers don't barf in canPlayType on unknown parameters, then they should be encouraged to…)

Or do specify it anyway and wait for the video object to throw an error.

There are lots of hypotheticals being bandied about regarding possible schemes which may or may not do X or Y at some point in the future, but the reality is that in every common case, you supply both the media resource and the markup — you know form the resource takes, and you describe it the markup. That markup might be <video>, or might be <object>, or might be <script>, or some combination of them.

It's difficult to say conclusively, because there's a distinct lack of concrete descriptions of scenarios, however it does seem that the only point at which it MIGHT become worthwhile exposing DRM scheme detail to the Javascript API in a more granular fashion is if you wanted the script itself to take an active role in obtaining and relaying authorisation keys… 

But if not, then DRM-protected video is still just 'an arbitrary video resource'. Whether a UA can perform playback or not depends on whether it — or the media plugins, frameworks, or whatever (they being implementation-defined) — support than scheme. You describe it, your determines whether it can be played, and takes action accordingly.

Received on Thursday, 1 September 2011 20:54:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:08 UTC