Guest post by Chris Mounsey, Product Manager
Some of our readers may have heard of the exciting possibilities offered by HTML5, particularly in the area of native audio and video playback.
The idea is that we will no longer have to rely on plugins—such as Adobe Flash (currently the most widespread), Windows Media Player or Apple Quicktime—to be immersed in the wonderful world of online multimedia.
The problem is that, like many great ideas, the devil is in the details—or, in this case, the war between a number of different codecs.
Despite the fact that it is necessary for me to get a little technical in places, I hope that by the end of this (admittedly slightly lengthy) post, you will have a decent understanding of the problems facing HTML5 media playback.
Not only will this impress your friends (possibly), but it will also enable you to appreciate the good news nestling at the end of this small essay...
Without trying to be too techie, playing video on the web depends on two main elements:
the codec under which the video file was compressed (or encoded), and
the container used to bring all of the elements (e.g. video and audio) together.
The benefits of the latter very much depend on the format of the former.
The HTML5 <video> tag provides a standardised container for playing video codecs, and for providing various controls, e.g. play, pause, etc. And, of course, the audio tag does the same for sounds.
Up until now, publishers have had to use Flash containers—which, of course, require Adobe’s Flash plugin. Flash is near ubiquitous on modern computers but the inaccessibility of many Flash players—combined with some rather serious security bugs and the plugin’s large appetite for memory—has made it a less than ideal solution.
Not only this, but the code for embedding an HTML5 video is very simple, e.g. <video src="someclip.mp4" controls /> embeds your video and delivers standard controls.
Whereas embedding a Flash video requires something more like this:
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0" width="400" height="300" id="movie" align=""><param name="movie" value="movie.swf""><embed src="movie.swf" quality="high" width="400" height="300" name="movie" align="" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer"></object>
Anyway, the HTML5 video tag is supported in all modern browsers—Safari, Firefox, Chrome, and IE9+—but, unfortunately, we have been largely unable to take advantage of this.
Because of a fight between browser vendors over the codecs.
Over time, a number of video codecs have been developed for use on the web.
Ogg Theora is generally acknowledged to deliver pretty poor quality video, but it is open-source.
H.264 (or MP4) was developed by the MPEG LA organisation (which includes a number of hardware and software corporations, and which also developed MP3) and delivers very high-quality video with decent compression.
WebM is a Google-sponsored open source codec, the quality of which is rather better than Ogg.
Broadly speaking, what has happened is this...
The Mozilla Foundation—which develops Firefox—is immensely committed to open source codebases and, as such, refused to adopt H.264; instead, they relied on Ogg Theora (in the early days) but their browsers will now also play WebM.
Apple enthusiastically embraced H.264—believing (rightly, in my opinion) that it delivered the best experience for its customers. Any videos you buy or rent from iTunes are delivered in H.264 format (as are most DVD movies for that matter). Further, since iOS devices (i.e. iPhones and iPads) do not have Flash, H.264 embedded in the <video> tag is the way of delivering web video to these devices.
Google Chrome supported both Ogg and H.264; however, a couple of years ago, the company stated that they would, in future, only support Ogg and WebM.
Until IE9, Microsoft's browsers simply did not support the <video> tag at all: IE9, however, supports all of the above formats.
In other words, in order to be able to deliver HTML5 video to all compatible browsers, you would have to encode your video at least twice—once as H.264 and once as WebM (or, possibly, Ogg)—upload both versions to your website, and link to both versions when embedding it in your page.
And you would still have to provide a Flash fallback to cater for older browsers.
HTML5 video and VerseOne CMS
That was the state of play at the time that the VerseOne Development team decided to develop the standard media player in VerseOne CMS (back around June 2011).
Believing that our customers—not usually technical—would not want to encode, upload and embed two video formats, we decided on the following course of action.
The media player would support embedded Flash videos (as before).
Users could also upload H.264 (or MP4) format files too. When these were embedded into the page, the system would detect what browser viewers were using.
Those using IE9, Chrome or Safari (on Mac or Windows) will be served the HTML5 <video> version. And, critically, those using iPhones and iPads are able to view the videos using the HTML5 <video> tag.
All other browsers would be provided with a Flash container.
This last catered (in theory) for mobile phones running Android or Windows since Adobe were working on—and had (sort of) delivered—a Flash plugin for mobile devices.
Unfortunately, this always ran pretty poorly on low-power mobiles and Adobe cancelled that project in January 2012.
(As a result, we will be revisiting our policy for these devices.)
The Good News
So, we currently have two browsers that support HTML5 video: IE9 and Safari (including Mobile Safari).
And, despite their announcement a couple of years ago, Google have not dropped support for H.264 in Chrome—nor do they show any sign of actually doing so.
So that leaves Firefox and the Mozilla Foundation. It's just one browser, but Firefox now is used by about 25% of web users—a significant number of people to leave out in the cold. (By comparison, IE now has around 35%, Chrome 20% and Safari of all flavours 12%.)
So, we welcome the news that the Mozilla Foundation is finally debating enabling support for H.264. Provided that Mozilla push ahead, all of the major browsers will shortly support the H.264 codec.
We can then provide a reliable, standards-based recommendation to our customers as regards their video options, i.e. that they should encode their video as H.264 MP4 files (as they should currently do if they wish to deliver to iOS devices).
We can modify our media player to serve video via the HTML5 <video> tag, and support more platforms and more systems (whilst still providing the Flash fallback for less capable browsers).
This will remove a thoroughly thorny problem for us (and for our users) and allow the industry to move forward in providing an excellent, standardised and flexible delivery method for video on the web.