- From: Oliver Hunt <oliver@apple.com>
- Date: Tue, 29 Jan 2008 15:16:03 -0800
> 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 > >
Received on Tuesday, 29 January 2008 15:16:03 UTC