- From: James Graham <jg307@cam.ac.uk>
- Date: Tue, 29 Jan 2008 23:20:28 +0000
Charles wrote: >> [James] Can you explain it again, because I'm not sure I fully >> understand what you're trying to say and I don't seem to be the >> only one. >> > > The <video> element doesn't appear solve the problem of how to embed video > content in a player- and browser- agnostic fashion. > > HTML 5 provides an opportunity to normalize how video embedding is done for > most scenarios, making it as easy to embed video as it is an image. But as > designed, <video> appears to only address an as-yet-undiscovered combination > of container and media formats. > > This seems like a missed opportunity at best. Technically, it doesn't seem > like it'd be difficult to allow various media runtimes to register as > first-class <video> clients I'm not sure exactly what you want the spec to say here (perhaps because I'm no clear what a "media runtime" is - is a codec a media runtime? Is Flash? Is a Java applet? Is the mplayer plugin?). Since browsers are free to implement native <video> support with a pluggable backend (which, indeed, WebKit is doing by leveraging Quicktime and which Opera and Mozilla could in principle do by using e.g. gStreamer), registering different codecs to provide first-class video clients is already possible. A good implementation would prompt for codec download when no suitable installed codecs were found. However I get the impression that this is not what you are after. Are you looking for a way for plugins, rather than the browser itself, to handle <video>? If so, why? It seems to me that plugins are limited in scope and provide a poor user experience compared to native support and it's not clear what advantages they would have.
Received on Tuesday, 29 January 2008 15:20:28 UTC