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

Re: [MEDIA_PIPELINE_TF] Common content security requirements

From: Mark Watson <watsonm@netflix.com>
Date: Thu, 1 Sep 2011 15:03:19 -0700
To: Mo McRoberts <mo.mcroberts@nexgenta.com>
CC: "Mays, David" <David_Mays@Comcast.com>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Message-ID: <ED56226D-376F-4E73-958A-E1E0E0E05315@netflix.com>


Sent from my iPhone

On Sep 1, 2011, at 2:54 PM, "Mo McRoberts" <mo.mcroberts@nexgenta.com> wrote:

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

Whilst I understand you can design applications where the script has access to detailed content metadata such as codecs, profiles etc. there are also use-cases where the page has just a URL, perhaps for an adaptive streaming manifest describing multiple alternative encodings and in this case the page is not aware of all the various permutations of encoding parameters in the presentation.

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

Yes, that's exactly the way forward I'm advocating: move responsibility for authentication and authorization to the application, where it belongs.

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

Received on Thursday, 1 September 2011 22:04:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 1 September 2011 22:04:36 GMT