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.

Reply via email to