The video element in HTML5 – great possibilities, but also codec and licensing problems

Man has always been inspired by things moving around and giving away noises, so it was just a matter of time before video content showed up on the web. For a number of years, Flash was the de-facto standard of showing video, but now, with HTML5, the video element has made its way into our lives.

The video element

The video element is as simple as can be:

<video src="swedish-flag.ogv"></video>

Then you can add a number of attributes for if controls should be visible, if it should autoplay when the visitor loads the containing web page etc. The applicable attributes are:

Loads the entire file if this attribute is enabled, but is ignored if autoplay is set.
Video starts playing as soon as it is ready.
If video controls should be displayed – looks dependent on web browser.
Height of the element
If the video playback should loop.
The video file to play
Width of the element

So, another example could look like this:

<video src="swedish-flag.ogv" controls width="320" height="240"></video>

What is also nice is that web browsers won’t automatically download the entire video file, but just a part of it to be able to display the first frame. Also, you could write your custom controls and control the video via script – this is more described in Using audio and video in Firefox.

Different treats for different web browsers

This all sounds good and well; just specify the source of your video file and you are good to go! Well, it could have been like that, but unfortunately isn’t. Just as before in history, it comes down to video codecs – yes, exactly that hassle we got around with having video in Flash.

  • Firefox supports the Ogg/Theora encoding.
  • Google Chrome supports the H.264 and theOgg/Theora encoding.
  • Safari supports the H.264 encoding.
  • Opera will support the Ogg/Theora encoding (no final release with video element support yet).

So, what the video element offers us is to specify various video sources for different web browsers, like this:

<video controls="controls">
	<source src="swedish-flag.mp4">
	<source src="swedish-flag.ogv">
	Sorry, your web browser doesn't support the video element

This video above should play in Firefox, Google Chrome and Safari on Mac. You can also check out a demo targeting both Ogg/Theora and H.264 in a stand-alone page.

And, instead of the “sorry”-phrase above, we could also go to the length of offering QuickTime and Flash fallbacks instead for web browsers not supporting the video element at all.

Codecs and licenses

I think it’s fair enough that we can offer content to please every web browser, but at this point it becomes cumbersome. Maintenance, it’s a nightmare, since we need to maintain and store at least three formats for each video to be able to offer it to a vast majority of our visitors. The reasoning behind codec support is that Apple has invested a lot of time and money into H.264 so they want to push that, Google Chrome has bought licenses for H.264 (which means the only version of Google Chrome that supports it is the one downloaded from the Google web site – Chromium and others don’t support that license) and support Ogg/Theora as well, while others like Mozilla (with Firefox) and Opera believe that the open standard element video should naturally support open codecs and therefore only support Ogg/Theora.

What we don’t want with a new standard/element and de-facto way of doing is to go into the situation of GIF again, but instead avoid closed formats that requires a number of expensive and limited licenses. I believe Robert O’Callahan explains it beautifully in Video, Freedom And Mozilla just why H.264 is not a viable option, and why it is not on par with the open web and web standards.

And, to make matters worse, in my eyes, Google just started offering the HTML5 video element on YouTube and Vimeo announced HTML5 video element support as well. Great news, but the big big problem with this, though, especially being two of the most visited video web sites on the web, is that they only support the H.264 encoding. This means that only Google Chrome and Safari users (and, oh, those three IE users in the world with Google Chrome Frame) can see it, excluding a vast portion of the web browser market with Firefox and Opera (the initial complaints were also that fullscreen video wasn’t there – well, Firefox 3.6 supports fullscreen video, so if they would have chosen another format that would have been there too).

What is bothering me with the H.264 approach, and is quite saddening, is that Google Chrome supports the Ogg/Theora codec as well, so they could have chosen the open route instead. Their move of introducing the video element on YouTube is a very important decision, and I believe it’s great to move away from Flash and into HTML5 elements. But as long as they do it with closed-in licensed codecs, it has been all in vain, if you ask me.

Mozilla VP Engineering Mike Shaver expresses his opinions in HTML5 video and codecs and Mozilla’s Christopher Blizzard talks more about in HTML5 video and H.264 – what history tells us and why we’re standing with the web.


The whole reason video on the web took off in the first place with YouTube and others is because it just worked as long as you had Flash installed, no matter the web browser and no matter the platform. If just end up in another codec war again, the video element will never take off – don’t waste our time with web browser-specific solutions and proprietary attitudes. If we ever truly want to use the video element on the web, it has to be open. Period.


Related reading

Leave a Reply

Your email address will not be published. Required fields are marked *