W3C home > Mailing lists > Public > public-html@w3.org > March 2012

Re: Encrypted Media proposal: Summary of the discussion so far

From: Mark Watson <watsonm@netflix.com>
Date: Mon, 5 Mar 2012 20:42:15 +0000
To: Charles Pritchard <chuck@jumis.com>
CC: Tab Atkins Jr. <jackalmage@gmail.com>, Christian Kaiser <kaiserc@google.com>, "<public-html@w3.org>" <public-html@w3.org>
Message-ID: <C0154257-88A8-48D6-BD7C-EF2D285EC8A4@netflix.com>

On Mar 5, 2012, at 12:17 PM, Charles Pritchard wrote:

> On 3/5/2012 11:19 AM, Mark Watson wrote:
>>>> >>  Today we have non-RF plugins and codecs. You want to remove support for those ?
>>> >  >  Ideally, yes.  Practically, we can't right now.  However, we can work
>>> >  toward making them irrelevant, and try out best to ensure that we
>>> >  don't introduce any new opportunities for them to take hold.
>> So, I think this would be a very bad thing, since these have been venues for innovation in the past and it would be detrimental to progress in general to remove such venues.
> Is there a technical reason why you can not use <object> to pass the CDM information, and the <video> tag to play movie streams today?

AFAIK, there's no way for a plugin to interact with a <video> tag in this way. If browsers were to provide one it would be browser-specific. If we were going the browser-specific route we might as well have browser-specific methods on the <video> element - this would be cleaner. If we standardized such an interaction we might as well standardize it on <video> for the same reason.

> Is there a limitation for supplying video codecs via the <object> tag?

I'm not sure what you mean. AFAIK you can't modify browser <video> capabilities using existing plugin APIs.

> As I've stated, I'd prefer to have a robust means of passing information through the media subsystem, and we've sure got a lot of APIs working towards those goals; but in the meantime, in the very near meantime, will a hybrid solution work for <video>? HTML display has worked for audio. I'm assuming that Pandora dropped support of the <audio> tag because it was poorly implemented by many vendors; bugs are still very-much around.
> -Charles
Received on Monday, 5 March 2012 20:42:47 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:49 UTC