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.
The purpose of the <video> element is to provide native support for
video content and
remove the need for external proprietary plugins, not to provide
<object> mk 2. The
<video> element is much more flexible in that it allows all controls,
etc to be defined using
full css, rather than requiring the controls to be embedded in the
plugin view.
Your assertion that <video> does not provide a browser agnostic
mechanism for providing
video content appears to be driven by the idea that html5 is
finalised -- it's not, we have yet
to make any decision on exactly which codecs and transport formats
will be expected.
Finally, the method through which content is decoded (once you know
the codec) in the
browser is an implementation detail -- WebKit uses QuickTime, WebKit/
Gtk uses gstreamer,
Firefox and Opera use builtin codecs (afaik) -- so it is not the
place of the html5 spec to
define it.
--Oliver
-- Charles
