The State of HTML5 Video Sucks | Localtype

Welcome to the moribund Localtype

RSS follow me on twitter

The State of HTML5 Video Sucks

Originally written on: May 7, 2011 at 8:22 pm

Last Updated: May 7, 2011 at 8:22 pm


I’m sure we all remember when video on the web meant installing a huge number of plugins in order to play a myriad of video formats. Plugins limited your audience to only those who could download the appropriate plugin. People behind corporate firewalls were often not permitted to download plugins, and plugins were browser and platform specific. Worst of all, installing plugins lead to browser instability. Back in those days, a rogue plugin could actually cause your entire system to crash. Video quality has improved immensely over the last 16 years, sadly, the technical requirements for delivering web video are just as daunting as they were back in the day.

HTML5 added the <video> tag, theoretically freeing us from using the current de facto standard for video playback, the notoriously crashy Adobe Flash. The reality is sadly, much different. Of all the major browsers, not one of them fully support the tag. Firefox and Chrome can only play HTML5 video if it uses the WebM codec, while IE and Safari will only play back H264-encoded video. This means that if you want to use only HTML 5 video, you have to encode twice. Conceptually, multiple encodings isn’t such a huge problem. There are fantastic encoders for H264. The WebM encoders in contrast, are pretty weak and difficult to insert into many existing workflows. Then there is the majority of desktop browsers in use that don’t support the tag at all.

When you throw mobile browsers into the mix, things get even more confusing. Most mobile browsers use Webkit, the open source browser platform on which Apple’s Safari and Google’s Chrome is based. This would be great, but different mobile devices support different profiles and aspects of the highly complex H264 codec, which means potentially more encoding for those devices.

Once you have all this encoding stuff worked out, you’re still faced with the reality of the browser implementation. From what I’ve observed, all the major browsers fail to properly buffer content. Inevitably, the buffer stops filling, and the video stops playing, with no way to force it to continue. Often, the playhead continues to move forward, even though the video is not playing. Full screen playback is also a problem, in that it often doesn’t work, or it has strange interface anomalies.

Some browsers don’t even properly follow the parameters passed in the <video> tag. Safari, for example, will automatically download the entire video when the web page is loaded, even if you explicitly set auto-buffering to ‘false’. That will cost both content providers and users for exceeding their data transfer caps.

It all falls back to Flash. The Flash plugin ships standard with most browsers, and has an installed base that is something in the high-ninty-percentile of desktop systems. The more recent versions of the Flash plugin can understand H264 encoded video, when called through the Flash interface. While the plugin is becoming more well behaved, it’s still crash-prone, and notoriously resource intensive. On mobile devices, Flash is still far from ubiquitous, and still unreliable.

So where does that leave us? Unfortunately, for content creators, it means a lot of extra work doing multiple encodings for each permutation of browser, and a huge chunk of HTML, Javascript, and CSS coding to get all of it to work. Luckily, there are some emerging solutions that help get all of this in order.

Video for Everybody is a simple chunk of HTML that will properly cascade a variety of video options based on the browser. It even properly substitutes an image for those browsers that don’t support the <video> tag, and it even works for those who have disabled javascript. It doesn’t however, offer any options like skinning, or fixes for the various browser deficiencies.

VideoJS takes Video for Everybody, and adds the ability to skin the HTML5 player and javascript to fix browser deficiencies such as the auto-buffering bug in Safari. It also incorporates Flow Player, the freely available Flash video player which references the H264 video as a fallback. There are other HTML5 drop-in solutions, but VideoJS seems to be the least buggy.

So this is what I’m doing: I’m using a VideoJS Pro plugin for WordPress, but I am only encoding H264 video, as I can’t find a WebM encoder that will fit into my current workflow. Right now, I am only encoding a single video profile which works on the iPad, IE9, and Safari on the desktop, while the Flash fallback will be shown in Firefox, and Chrome. In the future, I will create reference movies in H264, so iPhones, and those with lower bandwidth will still be able to play back the video. I don’t foresee encoding into WebM until the codec can be integrated into my workflow. By then, I expect to see H265 to be in common use.




7 Responses to “The State of HTML5 Video Sucks”

  1. Thanks for this! I have been reading up on this for a while and mostly just dealt with using multiple encodes and falling back to flash. But you are right, WAY too much work and really ruins the routine. Thanks for the great info! :) Right up my alley. :)

    btw, this is danielquasar from LJ, I’ve just switched to signing in with my Google ID instead. :)

    • CM Harrington says:

      You’re very welcome!

      The unfortunate thing about all of this is that it’s a problem that isn’t going to be solved easily. The W3C is insanely slow to ratify anything, and the browser manufacturers seem more interested in ideology than playing nice, and giving the user the best experience.

      This puts all the burden on the content creators, and that really sucks.

  2. heff says:

    Great overview.

  3. Great article! Web video has always been, and will continue to be a headache, though for free, it will almost always be the best option. For paid video, unfortunately, companies who don’t read articles like this continue to waste hundreds of thousands of dollars on systems to try and sell video on the web, or subscription systems that fail under their own weight.

  4. […] Read full article: […]

  5. CM Harrington says:

    @google-e1743259c82a2422b783b25cd1c366df:disqus @heffernan:disqus Thanks to you both. I do hope this whole thing can be resolved soon, but I think, like IE6, this is going to be a problem for awhile.

  6. […] version of Safari/Chrome/Firefox and the Flash plug-in. Most streaming video is still Flash, and HTML5 video isn’t quite as good an alternative as I had hoped.I chose PLEX, as it seemed to be the most mature of the 10′ interfaces available for the Mac. […]