Re: [MEDIA_PIPELINE_TF] Common content security requirements

On 1 Sep 2011, at 23:03, Mark Watson wrote:

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

Would you really generate a single adaptive streaming manifest containing both multiple bitrates *and* multiple formats and DRM wrappers? That seems, not to put too fine a point on it, crazy. And, if memory serves, the source list on <video> is ordered (though that might not be specified)?

But, in any case, if "let the application pick and choose from amongst the available resources [some of which are within a manifest] according to some custom heuristic” is a requirement, then DRM is just a sideshow: such a mechanism — were it to exist — should be a generic resource-selection hook, not a “pick a DRM scheme” hook.

However, I would wonder whether it'd be a damned sight easier to make the applications smarter with respect to resource availability rather than waiting for new APIs to trickle down :)

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

That's a pretty strong statement, and suggests an expectation of DRM schemes being developed which suffer from leaky abstractions… though that's not a foregone conclusion.

There are two kinds of scenarios, I guess:

Sony decides they're going to support Ultraviolet DRM in the browser of their Internet-connected Blu-Ray players. In their browser, they add support for a media type which gets handed off to the Ultraviolet runtime to deal with. If necessary, the UV implementation can present a login UI tailored to TV screens. Additional application-level control would almost certainly provide an inferior experience to the user.

Google enters into a partnership with Adobe to support Flash DRM in Chrome within <video>. For whatever reason, this requires an authentication key to be supplied and the site author has decided not to include it in the RTMPE video source URLs. When this happens the Flash DRM implementation fires a specific event on the video object which can be listened for if needed. The site author knows that event will be fired (because they know the specifics of Flash DRM - what with having decided to use it) and what to do when it is.

What needs to sit in the middle? Well, nothing, really. Whether it's through a plugin mechanism or rolled into the browser, a DRM handler can — in principle — do whatever the hell it likes in Javascript-land. It's an area where the web developer will necessarily HAVE to know about nuances of the particular codec because they chose to use it in the first place, and so there's a Chinese Wall between the application and the DRM runtime. Attempting to standardise and abstract that (as opposed to just properly documenting what the runtime does and requires) likely wouldn't achieve very much for anybody, really.

M.

PS. With apologies to Sony and Google.

Received on Thursday, 1 September 2011 23:02:00 UTC