But in our less-than-perfect world, the <VIDEO> tag sports a whole bevy of options that you choose from to ensure that your videos play back correctly across browsers and platforms. That said, most of this complexity exists for a good reason.
To illustrate this, here's an example of a <VIDEO> tag:
<video width="640" height="480" controls>
<source src="/video/video.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
<source src="/video/video.ogv" type='video/ogg; codecs="theora, vorbis"'>
<source src="/video/video.Webm" type='video/Webm; codecs="vp8, vorbis"'>
</video>
The outer elements of the <VIDEO> tag have several options:
* WIDTH / HEIGHT: The width and height of the video, in pixels.
* CONTROLS: Add this option to show playback controls on the video.
* PRELOAD: Tells the browser to start downloading (but not playing) the video as soon as the page is loaded. Use PRELOAD="none" to explicitly tell the browser not to preload the video.
* AUTOPLAY: Include this to start playback of the video automatically.
The <SOURCE> subtag lets you specify which video file, or files, to play back. If you specify more than one file via multiple <SOURCE> tags, the browser will attempt to load each file in turn. In the above example, the .MP4 file (an H.264 stream) will be loaded first; if the browser can't play that one, the .OGV (Theora) stream is loaded next, and so on. There's no practical limit to the number of <SOURCE> tags you can provide, but more than three is probably impractical.
The most complicated and problematic option for the <SOURCE> tag is the TYPE parameter, which describes to the browser the exact combination of codecs needed to play a particular video. This way the browser doesn't have to start downloading the video and perform its own codec detection on it (which may well be flawed) to figure out whether or not it can even play the video in question. If the browser knows in advance it can't play back a certain type of stream, it doesn't download it. You and the people viewing your videos will save a lot of bandwidth in exchange for a bit of hassle on your part.
For Theora and WebM codecs, the TYPE parameters are simple enough; the above examples encompass the most common scenarios. For H.264, though, the options become quite complicated because H.264 streams can be encoded in a number of profiles, and the TYPE descriptor has to match the profile used to encode the file. If you're using only one profile for all your videos, you can create the profile string once and forget about it; if not, you'll need to find some way to ensure the right TYPE string is associated with the file in question (e.g., via metadata in a content management system).
One other extremely important thing that many webmasters overlook is the MIME type for the files. Firefox, for instance, is extremely dependent on MIME types for determining what to do with a given file. To that end, use the following MIME types when configuring your Web server:
MIME Types
|
File |
MIME type |
Extension |
|
Theora |
video/ogg |
.ogv |
|
H.264 |
video/mp4 |
.mp4 |
|
WebM |
video/Webm |
.Webm |
Falling back to Flash
So what happens if the page is accessed by users who don't have <VIDEO> tag support in their browsers? For them, you'll need to provide a way to allow the page to serve up a Flash-encoded version of the video. The good news is that there's a way to do this that is a legitimate behavior of the <VIDEO> tag, not a byproduct of some other behavior or a browser-specific quirk.
The way this works is fairly clever: The Flash object is embedded within the <VIDEO> tag itself. If the browser supports <VIDEO>, it attempts to use a stream from the <SOURCE> tags. If none of those work, the <OBJECT> tag that points to a Flash player is invoked, and the other elements are automatically ignored.
For an example of this, check out a template called Video for Everybody, created by the folks at Camen Design. It not only falls back elegantly from HTML 5 to Flash but will also work in HTML 4 by degrading to Flash as a fallback, too.
Other third-party packages serve up the <VIDEO> tag in different sauces of HTML 5, JavaScript or Flash, depending on what additional effects you want to invoke. For example, the Projekktor project lets you embed a fairly advanced media player in a Web page with all sorts of extensions -- such as the ability to refer to an existing YouTube video. HTML 5 is used by default, but Flash works as a fallback when needed. Projekktor's code is GPL2-licensed, so it can be used and redistributed freely as-is.
Note that you have to supply the Flash player yourself: You can't just tell Flash to stream a video file. On the plus side, the current edition of Flash streams H.264 natively, so if you already have an H.264 encode you can simply re-use that.
Conclusion
The biggest obstacle the <VIDEO> tag faces is how each browser chooses to implement it -- what codecs are supported and how they're presented to the end user. It's all in flux, and that means any current implementation might change as the browsers themselves evolve over the next revision and beyond.
It's likely that we'll see two tiers of content that use the <VIDEO> tag: H.264-encoded content hosted by professional services and portals, such as YouTube and Vimeo, and open-standards content encoded in WebM and Theora, hosted wherever there's bandwidth and space to spare.
The important thing is that they'll exist side by side, powered by the same in-browser technology. If one does emerge as the standard, if only in a de facto fashion, it won't be for lack of competition.
Serdar Yegulalp has been writing about computers and information technology for over 15 years for a variety of publications, including InformationWeek and Windows Magazine.