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.