[whatwg] Some <video> questions
mart at degeneration.co.uk
Sun Mar 30 09:33:55 PDT 2008
>> But I think the premise of the question misses the point of the
>> <video> element.
> I may very well be completely missing the point.
> I'll be satisfied if someone tells me that <video> is not intended to be the
> preferred way to embed video on web pages, in which case I'll quietly return
> to my corner.
I may be misinterpreting your tone, but from reading this discussion it
seems that you're deliberately being difficult. Of course <video> is the
preferred way to embed video on web pages in HTML5.
It seems that you are either inadvertently or deliberately
misunderstanding the stack of components that implement audio and video
playback in browsers.
* The Quicktime browser plugin is a video player.
* The Windows Media browser plugin is a video player.
* The Totem Movie Player browser plugin is a video player.
* YouTube's "/player2.swf" is a video player.
* The video player used on channel9.msdn.com is a video player.
* A browser's implementation of <video> is a video player.
None of the above things are videos. They are used to play videos.
None of the above things are media frameworks, either:
* Quicktime's browser plugin is a front-end for the Quicktime media
* Windows Media browser plugin is a front-end for Microsoft's
DirectShow media framework.
* Totem Movie Player plugin is a front-end for either gstreamer or
xine, which are both media frameworks.
* YouTube's player is a front-end implemented in Flash to the media
framework built in to the flash plugin.
* The video player used on channel9.msdn.com is a front-end
implemented in Silverlight to Silverlight's video API. (which I suspect
uses DirectShow when running on on Windows.)
* <video> is a front-end to a media framework or some media frameworks
of the browser implementor's choice.
It is up to the page author to decide which video player they wish to
use. Currently, many authors create their own players in Flash or they
use someone else's player written in Flash. <video> is an alternative to
a video player implemented in Flash, and an alternative to embedding the
Windows Media browser plugin.
>> It is designed to embed video, not video players implemented in
>> other technologies.
> But in Safari, <video> = QuickTime. Is that not a player-centric rather
> than a content-centric design?
Please be careful to qualify "QuickTime" when you refer to it. It's
perhaps partially Apple's fault for calling everything by the same name,
but it's important to keep in mind the difference between:
* The QuickTime player, which is an application users can run.
* The QuickTime browser plugin, which is a browser plugin similar to
the QuickTime player.
* The QuickTime framework, which is an API provided by MacOS for video
playback, which is used by QuickTime player and is also used by iTunes,
Safari, and I imagine many other MacOS applications. (I'm not a Mac
user, so I hope you'll excuse the lack of an extensive list of examples.)
The same distinction exists in Windows. Windows Media Player, WinAmp,
Media Player Classic and several other applications are all front-ends
to DirectShow, which is the Windows equivalent of the QuickTime framework.
Likewise, there are several Gtk+ and GNOME applications that use gstreamer.
Neither QuickTime the framework, DirectShow nor gstreamer are video
players. They are frameworks on which players are built. One thing that
QuickTime the framework, DirectShow and gstreamer all have in common is
that all of the media decoding is done via pluggable modules, so any of
these frameworks can, assuming a suitable module is installed, play any
video format. (assuming that we define video to mean a non-interactive
sequence of images optionally synchronised with some audio.)
The HTML5 spec doesn't say "you must implement <video> with Quicktime",
it simply describes the behavior of a <video> element and how it
interacts with the page it's embedded in. It's up to the browser vendor
to decide how best to achieve the behavior that the specification requires.
I believe that it is correct to say that in the version of Safari under
discussion, the <video> element is implemented using the QuickTime
framework. However, you don't need to care about this. All you need to
care about is what video codecs it supports. The HTML5 spec should
ultimately require at least one video format that will be available in
all compliant implementations, which Apple is likely to implement by
simply supplying a Quicktime module that can decode that format. It is
an accepted open issue with the HTML5 spec that there is not currently
at least one standard video format required.
You remarked in an earlier thread that you think YouTube ought to be
able to embed their player via <video>. Here lies the confusion: <video>
doesn't embed players, it embeds video. What we want isn't this:
but rather something like:
That is, they would embed *the video itself*, not the player of the
video. It's a nonsense to suggest that <video> could be
"player-agnostic", because <video> *is* a player. What we might like it
to be is "format-agnostic", and implementing it on top of QuickTime
framework, DirectShow or gstreamer (as well as several other frameworks)
With all this said, if you disagree with anything I've asserted here
then I invite you to call me out on any specific points I've made.
General comments like "<video> is not the preferred way to embed video
on web pages", however, are not helpful and do not progress the discussion.
 I've simplified the <video> syntax here for the sake of illustration.
More information about the whatwg