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