Introducing HTML5: Video and Audio

This chapter is from the book

Introducing HTML5

Learn More Buy

This chapter is from the book

This chapter is from the book 

Introducing HTML5

Learn More Buy

Rolling custom controls

One truly spiffing aspect of the media element, and therefore the audio and video elements, is that the JavaScript API is super easy. The API for both audio and video descend from the same media API, so they're nearly exactly the same. The only difference in these elements is that the video element has height and width attributes and a poster attribute. The events, the methods, and all other attributes are the same. With that in mind, we'll stick with the sexier media element: the <video> element for our JavaScript discussion.

As you saw at the start of this chapter, Anne van Kesteren talks about the new API and that we have new simple methods such as play(), pause() (there's no stop method: simply pause and and move to the start), load(), and canPlayType(). In fact, that's all the methods on the media element. Everything else is events and attributes.

Table 4.1 provides a reference list of media attributes and events.

Table 4.1. Media Attributes and Events

Using JavaScript and the new media API you can create and manage your own video player controls. In our example, we walk you through some of the ways to control the video element and create a simple set of controls. Our example won't blow your mind—it isn't nearly as sexy as the video element itself (and is a little contrived!)—but you'll get a good idea of what's possible through scripting. The best bit is that the UI will be all CSS and HTML. So if you want to style it your own way, it's easy with just a bit of web standards knowledge—no need to edit an external Flash player or similar.

Our hand-rolled basic video player controls will have a play/pause toggle button and allow the user to scrub along the timeline of the video to skip to a specific section, as shown in Figure 4.3.

Figure 4.3 Our simple but custom video player controls.

Our starting point will be a video with native controls enabled. We'll then use JavaScript to strip the native controls and add our own, so that if JavaScript is disabled, the user still has a way to control the video as we intended:

<video controls>
  <source src="leverage-a-synergy.ogv" type="video/ogg" />
  <source src="leverage-a-synergy.ogv" type="video/mp4" />
  Your browser doesn't support video.
  Please download the video in <a href="leverage-a-synergy.ogv">Ogg</a> or <a href="leverage-a-synergy.mp4">MP4</a> format.
</video>
<script>
var video = document.getElementsByTagName('video')[0];
video.removeAttribute('controls');
</script>

Play, pause, and toggling playback

Next, we want to be able to play and pause the video from a custom control. We've included a button element that we're going to bind a click handler and do the play/pause functionality from. Throughout my code examples, when I refer to the play variable it will refer to the button element:

<button class="play" title="play">&#x25BA;</button/>

We're using &#25BA;, which is a geometric XML entity that looks like a play button. Once the button is clicked, we'll start the video and switch the value to two pipes using &#x2590;, which looks (a little) like a pause, as shown in Figure 4.4.

Figure 4.4 Using XML entities to represent play and pause buttons.

For simplicity, I've included the button element as markup, but as we're progressively enhancing our video controls, all of these additional elements (for play, pause, scrubbing, and so on) should be generated by the JavaScript.

In the play/pause toggle we have a number of things to do:

1. If the video is currently paused, start playing, or if the video has finished then we need to reset the current time to 0, that is, move the playhead back to the start of the video.
2. Change the toggle button's value to show that the next time the user clicks, it will toggle from pause to play or play to pause.
3. Finally, we play (or pause) the video:

if (video.paused || video.ended) {
  if (video.ended) {
     video.currentTime = 0;
  }  
  this.innerHTML = ' ';//▐▐ doesn't need escaping here
  this.title = 'pause';
  video.play();
} else {
  this.innerHTML = ''; // ►
  this.title = 'play';
  video.pause();
}

The problem with this logic is that we're relying entirely on our own script to determine the state of the play/pause button. What if the user was able to pause or play the video via the native video element controls somehow (some browsers allow the user to right click and select to play and pause the video)? Also, when the video comes to the end, the play/pause button would still show a pause icon. Ultimately we need our controls to always relate to the state of the video.

Eventful media elements

The media elements fire a broad range of events: when playback starts, when a video has finished loading, if the volume has changed, and so on. So, getting back to our custom play/pause button, we strip the part of the script that deals with changing its visible label:

if (video.ended) {
  video.currentTime = 0;
}
if (video.paused) {
  video.play();
} else {
  video.pause();
}
// which could be written as: video[video.paused ? 'play' : 'pause']();

In the simplified code if the video has ended, we reset it, then toggle the playback based on its current state. The label on the control itself is updated by separate (anonymous) functions we've hooked straight into the event handlers on our video element:

video.addEventListener('play', function () {
  play.title = 'pause';
  play.innerHTML = '  ';
}, false);
video.addEventListener('pause', function () {
  play.title = 'play';
  play.innerHTML = '';
}, false);
video.addEventListener('ended', function () {
  this.pause();
}, false);

Now whenever the video is played, paused, or has reached the end, the function associated with the relevant event is fired, making sure that our control shows the right label.

Now that we're handling playing and pausing, we want to show the user how much of the video has downloaded and therefore how much is playable. This would be the amount of buffered video available. We also want to catch the event that says how much video has been played, so we can move our visual slider to the appropriate location to show how far through the video we are, as shown in Figure 4.5. Finally, and most importantly, we need to capture the event that says the video is ready to be played, that is, there's enough video data to start watching.

Figure 4.5 Our custom video progress bar, including seekable content and the current playhead position.

Monitoring download progress

The media element has a "progress" event, which fires once the media has been fetched but potentially before the media has been processed. When this event fires, we can read the video.seekable object, which has a length, start(), and end() method. We can update our seek bar (shown in Figure 4.5 in the second frame with the whiter colour) using the following code (where the buffer variable is the element that shows how much of the video we can seek and has been downloaded):

video.addEventListener('progress', updateSeekable, false);
function updateSeekable() {
  var endVal = this.seekable && this.seekable.length ? this.seekable.end() : 0;
  buffer.style.width = (100 / (this.duration || 1) * endVal) + '%';
}

The code binds to the progress event, and when it fires, it gets the percentage of video that can be played back compared to the length of the video. Note that the keyword this refers to the video element, as that's the context in which the updateSeekable function will be executed, and the duration attribute is the length of the media in seconds

However, there's sometimes a subtle issue in Firefox in its video element that causes the video.seekable.end() value not to be the same as the duration. Or rather, once the media is fully downloaded and processed, the final duration doesn't match the video.seekable.end() value. To work around this issue, we can also listen for the durationchange event using the same updateSeekable function. This way, if the duration does change after the last process event, the durationchange event fires and our buffer element will have the correct width:

video.addEventListener('durationchange', updateSeekable, false);
video.addEventListener('progress', updateSeekable, false);
function updateSeekable() {
  buffer.style.width = (100 / (this.duration || 1) *
    (this.seekable && this.seekable.length ? this.seekable. end() : 0)) + '%';
}

When the media file is ready to play

When your browser first encounters the video (or audio) element on a page, the media file isn't ready to be played just yet. The browser needs to download and then decode the video (or audio) so it can be played. Once that's complete, the media element will fire the canplay event. Typically this is the time you would initialise your controls and remove any "loading" indicator. So our code to initialise the controls would typically look like this:

video.addEventListener('canplay', initialiseControls, false);

Nothing terribly exciting there. The control initialisation enables the play/pause toggle button and resets the playhead in the seek bar.

However, sometimes this event won't fire right away (or at least when you're expecting it to fire). Sometimes the video suspends download because the browser is trying to save downloading too much for you. That can be a headache if you're expecting the canplay event, which won't fire unless you give the media element a bit of a kicking. So instead, we've started listening for the loadeddata event. This says that there's some data that's been loaded, though not particularly all the data. This means that the metadata is available (height, width, duration, and so on) and some media content—but not all of it. By allowing the user to start to play the video at the point in which loadeddata has fired, it forces browsers like Firefox to go from a suspended state to downloading the rest of the media content, allowing it to play the whole video. So, in fact, the correct point in the event cycle to enable the user interface is the loadeddata:

video.addEventListener('loadeddata', initialiseControls, false);

Fast forward, slow motion, and reverse

The spec provides an attribute, playbackRate. By default the assumed playbackRate is 1, meaning normal playback at the intrinsic speed of the media file. Increasing this attribute speeds up the playback; decreasing it slows it down. Negative values indicate that the video will play in reverse.

Not all browsers support playbackRate yet (only Webkit-based browsers support it right now), so if you need to support fast forward and rewind, you can hack around this by programmatically changing currentTime:

function speedup(video, direction) {
  if (direction == undefined) direction = 1; // or -1 for reverse

  if (video.playbackRate != undefined) {
    video.playbackRate = direction == 1 ? 2 : -2;
  } else { // do it manually
  video.setAttribute('data-playbackRate', setInterval ((function () {
    video.currentTime += direction;
    return arguments.callee; // allows us to run once and setInterval
  })(), 500));
  }
}

function playnormal(video) {
  if (video.playbackRate != undefined) {
    video.playbackRate = 1;
  } else { // do it manually
    clearInterval(video.getAttribute('data-playbackRate'));
  }
}

As you can see from the previous example, if playbackRate is supported, you can set positive and negative numbers to control the direction of playback. In addition to being able to rewind and fast forward using the playbackRate, you can also use a fraction to play the media back in slow motion using video.playbackRate = 0.5, which plays at half the normal rate.