Re: [MEDIA_PIPELINE_TF] Common content security requirements

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? 

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 14:56:36 UTC