How to Integrate Video Into an HTML5 Page

And how do you insert a video inside a web page with HTML5 syntax? Very easy:

And that’s it! This is all we need to add a video player to our website without having to go to third-party add-ons or add code from other sites: just a simple tag.

I wish it were all that simple!

The complexity of HTML5 comes not from its syntax, but from the support offered by the browser itself and the encoding of the video. Developers have so far seen them black to resolve compatibility issues between different browsers, but there are also much wider-than-normal discrepancies between different browser manufacturers about it coding standards (the “codecs”) of video. In order to make an HTML5 site that works well we will need to take into account the way in which current browsers, such as Chrome 4, Firefox 4 and Internet Explorer 9 implement video standards for the web and we will also have to solve the problem of the playback in older browsers.

Limitations and benefits

First of all, just to put our expectations in its right end, we need to know what the limitations of HTML5 are in the topic of video playback.

Full-screen playback is not included today in the HTML5 specification. At this time quite a few but not all- browsers support full screen playback.

The default menus of the player are very basic and we may have to dedicate a little more than a little bit to give it a touch-up so that its appearance improves, either with skins, logos, corporate image or more or less sophisticated ornaments. To make it even more complicated, each browser continues to implement HTML5 and CSS differently. Add rounded corners, for example, and your video player may look round in IE and Firefox and yet remain square in Chrome and Safari.

Nowhere in the specification is it talked about smooth or adaptive streaming, a fundamental functionality if we want to launch a serious video playback system.

And per least for some: the specification doesn’t include (and obviously never will), Digital Rights Management (called DRM, Digital Rights Management). This means that copyrighted content will never be distributed via HTML5 (by its owners, it is understood).

And of course, the issue of codecs. But we’ll talk about this in a moment.

And in exchange for giving up all this, what do we have? Well, quite a bit, no doubt.

The first thing is that occasional developers who don’t focus especially on the subject of the video are going to have it a lot, but much easier to incorporate video into their pages without having to rely on what’s offered on other specialized video sites , such as YouTube or Vimeo. Until now, the developers had basically three options when it came to embedding video directly on the page:

Integrate a file directly (no streaming) that would have to be fully downloaded before starting playback
Buy a plug-in from some manufacturer (which may or may not work in all browsers).
Use a dedicated media server, too expensive and/or complicated solution for many sites.

HTML5 remedy these evils by offering developers an option to play video on a customizable player without adding third-party software.

Second, the HTML5 specification allows developers to have video on platforms that had traditionally been very problematic, such as Apple iOS products (iPhone, iPad). But we can also consider this aspect from another point of view: programmers remove the dependence they have today with respect to proprietary platforms, which can restrict or control the way the video is distributed on the web. This is, after all, the objective for which open standards are defined.

Finally, HTML5 is not an extraterrestrial technology, it is the latest version of HTML. This means that Javascript and CSS will work well here with the video. Developers will be able to manipulate it from the client and server side, just like the current HTML.

Video codecs

As I said before, the sharpest problem with HTML5 video is preparing and incorporating content into multiple codecs. Today each browser has its own preferred video format. And it looks like the fragmented implementation of the HTML5 video is going to get worse before it’s finally resolved.

Right now we have three possibilities to encode a video:

264 a well-known format that leverages hardware acceleration, supported by graphics processors on desktops, laptops, and devices. It is also the default recording format for most current video and mobile devices sold. However, it is a patented format and although it is still freely accessible for non-commercial use, this situation complicates things and can be a potentially very expensive solution. You can read this documentto learn in detail if you want to publish content for commercial purposes. It is supported in IE 9, Safari 3.1 and Chrome (for now).
Ogg Theora is an open, non-patented, royal-free standard. Supported in Firefox 3.5, Chrome 4, Opera 10.5
VP8 (WebM) a very new standard, recently purchased by Google and published as an open source and royal-free format (but patented after all). Supported in Firefox 4.0, Chrome 6.0, Opera 10.6.

This table summarizes all supported formats:

The Chrome case deserves special attention, since Google will stop supporting one of the three HTML5 video formats. Following the purchase of On2, a developer and sponsor of the WebM format, Google announced that future versions of Chrome will no longer support H.264. Instead they have published WebM under the BSD license, which universally guarantees a free, non-exclusive and royal rights-free use of their patent license. Thus, although Chrome is currently in only browser that supports all three formats, the market will have to decide very soon between the two default browsers of operating systems (Internet Explorer and Safari), which only support H.264 and all others, which support all formats except H.264.

Important note: To simplify my explanation in this article, I’m not getting into the topic of the many variants that exist from the three basic formats. When we start talking about the different possibilities of audio and video profiles and the distinction between audio and video containers and codecs, things get even more complicated. For example, although iPhone4 records video in H.264 format, we can’t put it directly into an HTML5 website: we have to convert it to a compatible profile.

It would be idea to be able to proclaim to the world that the X video standard is universally supported and that that is the format that we have to use with HTML5. But unfortunately, as seen in the table above, things are not exactly like that. If you include an installation of browser extensions for the user to do, the video format with more widespread support would be the Ogg Theora. However, we cannot assume that users, especially those who connect to the web from enterprise computers, have the knowledge or capacity to install additional video codecs, or browser extensions only to be able to watch videos with HTML5. If for some reason you are forced to have to choose a specific codec for your videos which one would you choose? Well, it depends. Let’s see what options there are:

H.264

Of the three standards, H.264 has the fame, quality and recognition of media professionals. It also has the backing of a colossal consortium involving some of the industry’s giants, such as Microsoft and Apple, through MPEG licensing agreements. And herein lies the strongest objection of critics: H.264 is not freely accessible.

For consumers it is free, and most developers should not worry about licensing issues(for now). However, this may not be the case on video distribution sites. The comings and goings of the H.264 patent license goes beyond the pretensions of this article (and, in truth, following them is quite complicated),but I think for now it will suffice to say that people have doubts.

For most developers, the patent theme will be masked, for quite some time, within a philosophical discussion between the concept of open standards and image quality. H.264 offers superior image quality and better streaming than Ogg (see below), and VP8(WebM). It also benefits from the benefits of hardware acceleration on many platforms, such as PCs and mobile devices.

Finally, we must take into account the ease of production, which is not a minor issue. All major video editing programs, such as Final Cut, Adobe Premiere, and Avid, export to H.264 format. We can’t say the same in the case of Ogg Theora and VP8. If your company produces its own videos and there are many, it will definitely help you to save a lot of time and work.

Ogg Theora

Ogg is the only standard that is not really protected in any way by patent. However, it can also be said that it is the one that offers the lowest quality,although it is also true that the difference is not very large. Several face-to-face comparisons with H.264 have given the latter as the victor. Although Ogg encodes files of slightly smaller size, it produces worse image quality than H.264 and is even more noticeable when we compare its ability to relay over the network.

VP8 (WebM)

Between both extremes of high quality but subject to patent (H.264) and worse quality but duty free (Ogg) we have VP8, probably the standard that generates the most controversy of the three. So far tests show that H.264 offers slightly higher video quality compared to VP8,but this difference is invaluable for most commercial applications.

The main question arises regarding open standards. On one side of the debate we have Google, who departs from H.264 in favor of its “open” WebM standard to the point of publishing WebM under the Creative Commons license. On the other hand, we have everyone denying the biggest, as they say that, in this case, “open” may not actually mean “open”. By setting jpeg litigation as an example, Microsoft warns that even if WebM is not subject to a patent on Google’s behalf, without an explicit clause by Google safeguarding the user, many companies and individuals may be involved in patent infringement litigation, specifically the MPEG license agreement, when distributing videos in WebM format.

In short, in most situations we do not find a solution that solves all the needs of all projects under all circumstances. But for most projects and under most circumstances, the best option is most likely H.264. Not only is it the most widespread video format, both in the world of production and consumption, but it maintains a clear advantage thanks to hardware acceleration. On commercial video sites, the possible costs of licensing will be offset by their increased potential market.

But this whole debate tends to fall by its own weight for a very good reason: in the short to medium term all browsers will support HTML5. Anyway, not all of them will support all browsers. Just as we wouldn’t prepare a style template that looks good in IE but fails in Firefox, it makes sense to think that we’re going to want to create video tags that are also compatible with all browsers.

Video converters

What this means, in practical terms for you, the developer, is that your video content will have to be encoded in at least two (ideally in three) video formats so that they can work with the HTML5 specification. Luckily we have several tools that can help us with this work.

I watch Video Converter: It’s your reference tool: this open source converter, available in Mac and Windows versions, converts virtually any source video format to all the HTML5 formats you want to use and also to other device- and platform-specific formats.

Handbrake: Another good open source converter for Mac and Windows (and Linux too). Handbrake is a good choice specifically for converting to H.264.

MPEG Streamclip(): Although not open source, MPEG Streamclip can be obtained for free in versions for Mac and Windows. It is also handled with H.264, although it can convert videos to many other formats that can be used to use them outside the HTML5 specification.

Firefogg: It is a more specialized tool. Firefogg is a Firefox extension that converts videos only to Ogg format, hence the name. In order to use it you will need to download Firefox before and then install this extension.

The <video>

As you’ll remember, in HTML5, including video on a page basically comes down to using a single tag: <video>. But as with all HTML tags, you have tons of parameters that can be configured. Here are the most important ones that go inside the label itself:

src: The name and location of the video to be played. It works the same as the same parameter in the <Ing.> tag. Keep in mind, however, that instead of identifying the source of the video here you can, and surely will, indicate this data from outside the tag (we see it now).

width and height: (optional): Indicate the dimensions of the video. More specifically, here are the width and height of the viewing window, not the video itself. As with the <img> tag, if we leave these two data undefined, the browser opens a default window whose dimensions match those of the video to be played. However, unlike <img>, if we indicate a different size than the original, the video scales while maintaining the proportions, rather than deforming. In other ways, the embedded video keeps the original ratio recalculating from one dimension, the other. If we write a smaller size than the original, the whole video becomes smaller, but if we indicate a larger size, the video appears in its original size and the rest of the viewer surface is filled with empty space (usually black).

controls – Addsa default video control component to the page. It is very useful if you do not want to create your own control, but if you need to customize your controls, you can use Javascript and CSS. The specification allows handling of methods and properties such as play(), pause(), currentTime, volume, muted, etc.

preload– Starts downloading the video as soon as the user opens the page. To indicate that the video is preloaded, simply include the attribute. In order not to be preloaded, the attribute value must be set to “none”.

autoplay: obvious and dangerous. Instructs the browser to start playing the video as soon as the page loads. I don’t recommend you use it.

And now comes the magic part. The HTML5 specification includes a particularly useful solution to compensate for current browser dysfunctions regarding video formats. Instead of using the src attribute, you can nest multiple tags within the <video> tag itself, each with a different source. The browser will automatically scroll through the list and take the first one that is available to play it. For example:

If you try this code in Chrome, you’ll be able to watch the video in H.264. If it’s in Firefox, however, we’ll see the video in Ogg format on the same site.

In theory, although it is not strictly necessary in all browsers, we should include a MIME type in the type parameter to ensure compatibility with all browsers. This parameter should indicate the video type as well as the corresponding video and audio codec. The specific values of the parameter will depend only on how the video was encoded. In the following link there is a list of the many possibilities offered:

If you want to see all three types of video in action, visit my own website.

On this page you can see the source code for three different video types: H.264, Ogg, and WebPM. The names of the videos themselves indicate their codec, so you can know which one is playing in your browser.

A pointing about MIME types: Your server must be configured to recognize the different types. In the case of Windows Server this means that the corresponding entries must be added to IIS. In Apache we need to add the AddType directive to the httpd.conf file or to the local .ht access:

AddType video/ogg .ogv
AddType video/mp4 .mp4
AddType video/webm .webm

Elegant degradation

Although a multi-source <video> tag may work well in many HTML5-compatible browsers, we’re not good at solving the problem that arises with older browsers, which don’t support HTML5. Luckily the specification includes a mechanism to facilitate backward compatibility.

Grab any <object> tags you use right now or that you could use before HTML5, and put it at the end of the <source> parameter list. Normally this object will indicate the player you use (presumably it will be an external plug-in), and the parameters and source required for that player. The following examples use Flowplayer, a well-known player of which there is a free version.