RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Exploring HTML 5's Audio/Video Multimedia Support : Page 2

The <audio> and <video> tags were among the first features to be added to the HTML 5 specification. Find out how these elements enable the browser to work with both types of media in an easy-to-use manner.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Audio, Video, and the DOM

Both the <video> and <audio> elements use the same DOM interface, based on the abstract HTMLMediaElement (i.e., there is no formal <media> 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.

Table 4. Media User Interface Events
Event Name Interface Dispatched When... Preconditions
loadstart Event The user agent begins looking for media data, as part of the resource selection algorithm. networkState equals NETWORK_LOADING
progress Event The user agent is fetching media data. networkState equals NETWORK_LOADING
suspend Event The user agent is intentionally not currently fetching media data, but does not have the entire media resource downloaded. networkState equals NETWORK_IDLE
abort Event The user agent stops fetching the media data before it is completely downloaded, but not due to an error. error is an object with the code MEDIA_ERR_ABORTED. networkState equals either NETWORK_EMPTY or NETWORK_IDLE, depending on when the download was aborted.
error Event An error occurs while fetching the media data. error is an object with the code MEDIA_ERR_NETWORK or higher. networkState equals either NETWORK_EMPTY or NETWORK_IDLE, depending on when the download was aborted.
emptied Event A media element whose networkState was previously not in the NETWORK_EMPTY state has just switched to that state (either because of a fatal error during load that's about to be reported, or because the load() method was invoked while the resource selection algorithm was already running, in which case it is fired synchronously during the load() method call). networkState is NETWORK_EMPTY; all the IDL attributes are in their initial states.
stalled Event The user agent is trying to fetch media data, but data is unexpectedly not forthcoming. networkState is NETWORK_LOADING.
play Event Playback has begun. Fired after the play() method has returned. paused is newly false.
pause Event Playback has been paused. Fired after the pause method has returned. paused is newly true.
loadedmetadata Event The user agent has just determined the duration and dimensions of the media resource. readyState is newly equal to HAVE_METADATA or greater for the first time.
loadeddata Event The user agent can render the media data at the current playback position for the first time. readyState newly increased to HAVE_CURRENT_DATA or greater for the first time.
waiting Event Playback has stopped because the next frame is not available, but the user agent expects that frame to become available in due course. readyState is newly equal to or less than HAVE_CURRENT_DATA, and paused is false. Either seeking is true, or the current playback position is not contained in any of the ranges in buffered. It is possible for playback to stop for two other reasons without paused being false, but those two reasons do not fire this event: maybe playback ended, or playback stopped due to errors.
playing Event Playback has started. readyState is newly equal to or greater than HAVE_FUTURE_DATA, paused is false, seeking is false, or the current playback position is contained in one of the ranges in buffered.
canplay Event The user agent can resume playback of the media data, but estimates that if playback were to be started now, the media resource could not be rendered at the current playback rate up to its end without having to stop for further buffering of content. readyState newly increased to HAVE_FUTURE_DATA or greater.
canplaythrough Event The user agent estimates that if playback were to be started now, the media resource could be rendered at the current playback rate all the way to its end without having to stop for further buffering. readyState is newly equal to HAVE_ENOUGH_DATA.
seeking Event The seeking IDL attribute changed to true and the seek operation is taking long enough that the user agent has time to fire the event.  
seeked Event The seeking IDL attribute changed to false.  
timeupdate Event The current playback position changed as part of normal playback or in an especially interesting way, for example discontinuously.  
ended Event Playback has stopped because the end of the media resource was reached. the currentTime equals the end of the media resource; ended is true.
ratechange Event Either the defaultPlaybackRate or the playbackRate attribute has just been updated.  
durationchange Event The duration attribute has just been updated.  
volumechange Event Either the volume attribute or the muted attribute has changed. Fired after the relevant attribute's setter has returned.  

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 <video> and <audio> 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.

Kurt Cagle is the managing editor for XMLToday.org and a contributing editor for O'Reilly Media. He is currently working on a book about XBRL. Follow him on Twitter at twitter.com/kurt_cagle.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date