[whatwg] Some <video> questions

[Martin Atkins]

Charles wrote:
> Maciej,
> 
>> 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 
framework.
  * 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:[1]
    <video src="/player2.swf">
but rather something like:
    <video src="/videos/Z73xtJN6IdA.flv">

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) 
achieves this.

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.



[1] I've simplified the <video> syntax here for the sake of illustration.