HTML Video

In the last chapter, HTML Media — Audio, we saw the <audio> element in detail. We learned how to embed audio in an HTML document, and the various features we could play with, e.g. adding controls, looping the audio, etc.

Now in this chapter, our focus shall be on exploring <video>. The <video> element is similar in many ways to <audio>. In fact, if you know about <audio> well enough, understanding <video> would be a breeze.

After all, video is more or less audio with a big bunch of pictures (or better to say, frames).

Prior to HTML5, just like audio, embedding video in HTML was some grunt work. Developers had to reply on external plugins to get video content working; plugins like Quick Time, Flash, and Windows Media Player.

However, because of crappy support of plugins across browsers, and the inherent complexity in offering video content, it was still a dream back then to embed a video in one line of HTML markup.

Thankfully, HTML5 anticipated this desire and brought forth exactly that what was needed — a superbly a simple way to embed a video, using the <video> element.

In the following discussion, we shall learn how to use <video> to embed a video file in an HTML document and also learn about numerous modulations we could apply to the video. These include muting the audio in the video, if any; providing a custom thumbnail image; adding a subtitle track; and much more.

Just like for audio, we have the <audio> element, for video, we have the... well... <video> element.

As stated earlier, the <video> element is similar to <audio> in many ways. To name a few:

• <video> is also a container element.
• A minimal <video> is made up of the src attribute, pointing to the source video file to embed.
• Multiple video files in differing formats holding the same video data can be specified using individual <source>s inside <video>. (We'll see examples of this later in this chapter.)

Let's now consider an example of embedding a video in an HTML document.

Suppose we have an MP4 video, name waterfall.mp4 (more on video formats later below). To add this video to a document, the minimal HTML code we need is as follows:

<video src="waterfall.mp4"></video>

Now while this does embed the video, it does NOT allow us to play or interact with the video in any way, as you can see in the linked page.

Live Example

Given that you know about <audio>, can you think about what's missing in the <video> above due to which we can't interact with it?

The controls attribute serves to add controls to an HTML <video>.

By default, a video is embedded in HTML without any controlling interface rendered alongside it. This is the job of controls.

Let's add controls to our example above:

<video src="waterfall.mp4" controls></video>

Live Example

Now, as the webpage and thereafter the video loads, we can play it by pressing the play button.

Perfect!

As with audio, the video player interfaces differ from browser to browser. Shown below are the interfaces in Chrome and Firefox.

Just like we have a loop attribute for <audio>, to keep it playing again and again, we have the loop attribute for the <video> element as well.

That is, loop causes a video to restart as soon as it ends — in other words, to loop.

Consider the following example where we apply this attribute to our waterfall video:

<video src="waterfall.mp4" controls loop></video>

Live Example

As soon as the video ends, it automatically starts playing again from the very beginning, all thanks to the application of the loop attribute.

When a video is rendered on an HTML document, it occupies some space (on the document) and needs an initial image to render. This is often referred to as the thumbnail or the poster of the video.

The poster helps us quickly see what the video is about.

By default, the browser itself tries to create a poster for <video>. This is typically taken from the very first frame of the video (recall that a frame is merely an image).

However, to manually provide a poster image, we use the poster attribute. Expectedly, poster points to an image file which is the poster for the underlying video.

Consider the following example:

<video src="waterfall.mp4" controls></video>

Live Example

Here, we just have our previous waterfall video rendered with controls, nothing else, and no custom posters. The initial image rendered for the video is the waterfall scenery (taken from the video).

Now, let's provide the following image, waterfall-poster.png, as the poster to use instead:

Let's see the output produced:

<video src="waterfall.mp4" controls poster="waterfall-poster.png"></video>

Live Example

As you can see, as the page loads, the initial image rendered for the video frame is precisely the one shown above, courtesy of the poster attribute.

By default, when a video is in the process of being loaded, the browser renders its frame (completely black) in the following dimensions: 300px width and 150px height.

Then, as soon as the video loads, its first frame is rendered to the width and height of the video.

For example, the waterfall video we're using above has dimensions of 426px (width) and 240px (height). As soon as the video loads, the video frame's width becomes 426px and its height becomes 240px.

Similarly, if the video was 1000px by 400px, the video's frame would boil down to these very dimensions as soon as its data gets loaded.

To specify custom dimensions for a video, we can leverage the familiar width and height attributes. They specify the absolute width and height, in units of pixels.

For example, let's change the dimensions of our <video> to 213px by 120px — half in both dimensions:

<video src="waterfall.mp4" controls width="213" height="120"></video>

Live Example

The benefit of specifying custom dimensions is pretty obvious — even when the video's data is in the process of being loaded, the rendered blank frame takes on the specified dimensions.

In other words, there is no layout shift as soon as the video loads if we have a custom width and height set up.

Without a custom width and height, when the video isn't loaded, its frame is 300px by 150px. Then when the video does get loaded, its frame's dimensions become the very natural dimensions of the video.

By default, videos in HTML are unmuted to begin with. However, the muted attribute can be used to change this.

That is, with the muted attribute set on <video>, the video is muted initially if we start playing it. If controls are provided, we can thereafter also unmute it by pressing the speaker icon on the video interface.

Consider the following code where we set muted on our waterfall video.

<video src="waterfall.mp4" controls muted></video>

Live Example

Open up the link above and play the video. As you do so, notice the speaker icon on the rendered video player.

The speaker icon, with a line cutting through it, indicates that the underlying video is muted; clicking on it unmutes the video.

You might've seen websites today that have crazy animations and motion design going on above the fold as soon as the page loads.

Most of the times, these are simply autoplaying videos.

Speaking of which, to autoplay a <video>, we use the autoplay attribute.

However, there is one important thing to note regarding autoplay. That is, browsers disallow autoplaying a video if the video is not muted, or has an audio track in it.

If you think about it, this is a good design decision. It doesn't make much sense to allow websites to autoplay videos with sound without the user's consent in any way.

Imagine visiting a webpage to learn about a recent news and suddenly you hear audio playing from nowhere on the page. Curiously, you try to find where that sound is coming from and deep down in the page you notice a newsroom video presenting the latest news coverage.

Pretty weird, won't it be?

Ideally, it would be more sensible to have the user — that is, you — control whether an autoplaying video should be unmuted or not. A sudden surge of audio from nowhere is the last thing any user wants!

So browsers only allow a video to be autoplayed if:

• it is muted, via the muted attribute as we learned above, or
• it doesn't have any audio track in it at all.

An exception case where browsers tend to allow autoplay is when a webpage (with an autoplaying video that's not muted and that does have an audio track in it) is loaded by manually clicking on a link. (The following discussion helps clarify what this means.)

It's time for an example.

In the code below, we embed our waterfall video that should autoplay as soon as the underlying document loads because of the autoplay attribute:

<video src="waterfall.mp4" autoplay></video>

However, notice how the video neither has muted set, nor is without an audio track (as we know, the video has corresponding audio in it), but still it autoplays as we click on the following link and the webpage loads.

Live Example

This happens precisely because of the exception case stated above. We click on the link here to land on the webpage with the autoplaying video, and ultimately we get the video autoplaying (with audio).

Now, try to refresh the same page. What do you see?

Well, this time, the video does NOT autoplay. And the reason is because we didn't land on the webpage directly via a link's click but rather via a reload.

I personally find this to be a little bit counterintuitive. I don't understand how clicking on a link to land on the webpage (with the video) differs from manually landing on it.

Either way, we land up on the same webpage with the same intention, more or less, without expecting a video to automatically start playing with audio from nowhere.

The easiest way to keep this notion intuitive is to:

In this way, we ensure consistent autoplay behavior regardless of how we land up on a webpage (i.e. due to a link click, or a refresh, or a manual navigation, etc.).

Why use something browsers allow which is slightly counterintuitive? Right?

Consider the following addition of muted to the <video> above:

<video src="waterfall.mp4" autoplay muted></video>

Once again, click on the link below and notice what happens. Expectedly, the video should autoplay as before.

Live Example

But now also try refreshing the page. What do you notice now?

This time too, when we refresh the webpage, the video autoplays because it is muted. The browser has no issue in autoplaying videos with no sound (either a consequence of muted or there being no audio track in the video in the first place).

Similar to how we could provide multiple, competing images to the <picture> element, or multiple, competing audio files to the <audio> element via <source>, we could do so for <video>.

Multiple formats for the same video data could be simply provided using multiple <source> elements nested inside <video>.

<video controls>
   <source src="waterfall.webm" type="video/webm">
   <source src="waterfall.mp4" type="video/mp4">
</video>

Here we have a video with two sources of different formats. The first one is a WebM video and the second one is a widely supported, MP4 video. We preferably want the WebM video to be loaded if the browser supports it, hence the first appearance of it in the markup.

Notice the type attribute added to each <source> element. This is important because we want to signal the type of the underlying source to the browser so that it can quickly determine whether it supports it or not.

In case we omit the type, the browser tries to roughly guess the type from the source's extension, if any. For example, waterfall.mp4 would be taken as an MP4 file due to its .mp4 extension.