The element incorporates all the attributes that the element does, plus three others (see Table 2).

The poster is effectively a placeholder image used while the video is buffering. It’s not always necessary. A number of video codecs automatically extract a particular frame from the video to use as the poster for the video prior to downloading and front-load this (either the first frame or a random frame from mid-way through). Not all codecs are capable of this function, however.

Using a poster in this particular case is also useful for creating an alternate “brand” for the video while it’s loading, rather than relying upon the host to supply it. When the video actually starts to play, the poster image is irrelevant, even when paused. In the latter case, either the last frame that was displayed before pausing will be shown or if the video plays all the way through, the last frame of the video will be shown.

Ordinarily, video and audio formats use whatever codec the given media source is compressed and formatted in, but sometimes the browser agent does not support that particular codec. In this case, as an alternative to using the @src attribute, HTML 5 also defines a secondary element, which defines both the locations of a given resource as well as the codec type that the resource exposes. Table 3 lists the element definitions.

In the case of multiple elements, if the web browser can’t play the first codec (it’s not supported), it will go down the list until it finds one on which it can play.

Thus, the following bit of HTML 5 code shows a video element with three different codecs:

The first element describes an mp4 resource (the most typical MPEG video types, though these often have just a straight “mpg” extension), which uses the baseline profile video codec. The second is a video encoded with the simple profile video codec, while the third is encoded with the Ogg-vorbis codec. Most typically, the @type attribute will contain the associated mime-type. If it doesn’t, the @media attribute can be given with this information. Note that you have an either/or type of situation with regard to the @src attribute: it will be used preferentially even if elements exist, but you must have one or the other in your media elements.

Theoretically, the and elements should be able to handle most of the codecs currently in use. In practice, however, the browsers that do currently support these elements do so only for the open source Ogg Vorbis and Theora standards. The names may not be familiar to you?though fans of Terry Pratchett’s Diskworld series may recognize the Ogg Vorbis name from the Exquisitor Vorbis character in “Small Gods” and (perhaps) the Nanny Ogg character featured in many of his books. Theora (Jones), on the other hand, was the name of the controller of the Max Headroom character in the series of the same name.

The Ogg Vorbis standard is both open source and high fidelity, compared with the better-known MPEG formats. As such, Ogg Vorbis is a popular format for storing audio tracks for games and online applications. The HTML 5 specification does not give any preference to Ogg Vorbis/Theora over other formats, but it is the one supported by Firefox (exclusively, at this point). The Chrome and Safari teams both have announced intentions to support the two standards in addition to others.

Audio, Video, and the DOM

Both the and elements use the same DOM interface, based on the abstract HTMLMediaElement (i.e., there is no formal element). You can then use this interface to control the various video and audio streams within the page. Listing 1 shows the IDL for this interface.

From the IDL, the API for the media elements breaks cleanly into the following tasks:

• Controlling the network retrieval of resources
• Controlling the buffering
• Controlling the playback
• Setting the attributes of the various controls.

The src property is for setting the @src attribute on the media, but changing src by itself doesn’t automatically change the current video. Instead, after you change src, you then need to call the load() function to load the element with the new media, and then invoke play() when the video has loaded and finished buffering. In a purely synchronous world, this particular task would be relatively easy. If you’re pulling media off a local file with a locally running web page, this code will in fact work:

myMedia.src="http://www.mymedia.com/mediasrc.ogg";myMedia.load();myMedia.play();

However, media by its very nature is a time-spanning process. You’re working with both the need to load and cache audio and video files and the network connection, which itself can prove to be a challenge that’s usually not a factor for most non-temporal resources. For these reasons, when dealing with video and audio on the web, if you want to take control of the process in any way, you have to work asynchronously, tying into the various events that are passed back to the client from the media-serving website. Table 4 (taken directly from the HTML 5 documentation) provides a full listing of the various events and when they are dispatched.

Of all the events in Table 4, perhaps the most useful are the canplay and canplaythrough events. The first, canplay, will fire when enough data has been loaded for the video player to start actually rendering content constructively, even if not all of the data has been loaded. The canplaythrough event, on the other hand, will fire when the data has essentially completely loaded into the browser’s buffer, making it possible to play the video all the way through without the need to pause and retrieve more content.

Listing 2 provides an example of this: a person enters the URL to an OGV movie then presses the “Load” button.

When the video reaches a point where it has enough to play, it intercepts the oncanplay event, which enables the Play button. In turn, when the user presses the Play button, it will actually play the video just downloaded.

At least that’s the theory. In practice, the and tags are not fully implemented even in Firefox. As such, many of the events are not being passed back up to the JavaScript level yet. This means that, as crude as it is, calling load() and then play() still seems to be the best way of playing externally loaded video resources. This area is very likely to change as the implementations (and the XHTML standards) become more fully fleshed out.

Browser Vendors Very Interested

By all indications, the browser vendors view the multimedia aspects as perhaps the most crucial in the developing HTML 5 standard. Given the complexity of both types of media and the prospect of being able to better promote video and audio usage within web browsers, it’s hardly surprising. However, before HTML 5 multimedia becomes ubiquitous, the state of the art for these browser implementations still has a ways to go technically.