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 12:42:16 -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: <D6B2D4FF-C2A2-48A5-A9A7-144F186F7CF7@netflix.com>

Sent from my iPhone

On Sep 1, 2011, at 7:58 AM, "Mo McRoberts" <mo.mcroberts@nexgenta.com> wrote:

> On 1 Sep 2011, at 15:37, Mays, David wrote:
>> What if the browser provided APIs that would allow a DRM vendor to
>> override the functionality of the <video> element?
>> Today, if I put a URL pointing to a Smooth/PlayReady manifest into a
>> <video> element, the browser has no idea what to do.
> Not strictly true — JS can detect that the browser doesn't know what to do, and can examine the sources. Responsibly-written <video> has handoff to Silverlight/Flash anyway, and the Javascript in question has an incredibly high likelihood of coming from the same place as the video itself so can be tailored to the situation.
> It strikes me that DRM issues are not in principle any different in handling to unknown wrapper formats or codecs. There's _already_ a mechanism — canPlayType() — which can accept any arbitrary MIME type and return a value indicating whether the UA believes it can play it or not (and later, if it attempts to, tell you whether it really did manage to).
> In short: why define a new API (or worse, set of APIs) when the existing mechanism does exactly what is required? 

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. There may be more than one scheme in the intersection of the schemes that can be used with the file and the schemes supported by the platform. The application needs to choose.

Then there is the question of delegating authentication and authorization to the application.

> There's nothing in any specs (that I'm aware of) which says the MIME type supplied has to be that matching the decrypted video — indeed, to the best of my knowledge, many “protected” formats are served up with a different MIME type to the unprotected format for reasons along these lines.
> Browsers will tell you _today_ that they can't play video/my-whizzy-drm-scheme because they can't, but if you register that type with IANA and persuade developers to build in support, then those APIs will start telling you that they can -- and this just so happens to be precisely what is needed for “DRM support in <video>” to be achieved.
> M.
Received on Thursday, 1 September 2011 19:43:27 UTC

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