This post was originally written for the internal Sky Creative Technology blog.
Last night, Google put up a blogpost on it’s Chromium blog which may have wide-reaching implications for the way in which we publish video. In this post they outline their plan to drop support within the HTML5 <video> tag for the much-utilised H.264 codec in the Chrome browser, in favour of the open-source WebM and Theora codecs. This effectively means that future versions of Chrome will not be able to playback h.264 encoded video, except in 3rd party plugins (such as Flash).
For a major browser vendor, with it’s product in the ascendent, to suddenly drop support of the most widely used video codec on the web, however might not be as crazy a move as it first appears. Google are most certainly playing a long game over standards, and it’s a ballsy move for sure…but h.264 is not, and never has been free to adopt, and businesses, particularly those which might make commercial propositions out of their video content, are exposed to a liability by using it. Google clearly believes that a long-term adoption of an open-source standard is a better bet, than just going with what’s being used. This is similar to the replacement of GIF by PNG a few years ago. We might not have agreed at the time, but the better standard won out. They are also not alone – Firefox also does not support h.264.
This is, obviously, a gift for Adobe. Whilst the browser vendors beat their drum over open-source, licensing and standards, Flash will, for now, be the only sensible method of deploying cross-browser (excluding iOS), hardware accelerated (very important in the adoption of HD video) video. Plus, they will be supporting WebM in the near future. The much-trumped future dominance of the HTML5 video tag may have been a little premature. I suspect that our workflow for now will be h.264 video into flash, with fallback to HTML5 for iOS devices…and not a lot else, until the desktop browser standards war settles down.
WebM is a promising technology, but I don’t think it’s there yet. There’s no hardware acceleration for it at present which will be problematic for HD publishers, and a quick test in our dev team shows serious processing overhead on the client PC when playing back a youtube webM video. My biggest concern is that no production workflow for broadcast currently has WebM on their radar. I’m confident that few people outside the open-standards geek corps will have even heard of it. No commonly used production tools support it, and, of course, there is the small matter of our legacy video that is currently deployed. Fortunately, we haven’t done a massive amount of HTML5 video deployment in our team…apart from device specific work (such as the iPad version of skycreative.tv) which won’t be affected by this change.
Of course, our users and clients don’t really care about standards and technology platforms. When they click on a video, they expect it to play on the device of their choosing. In the short term, this is almost certainly going to create a lot more work for us as we struggle to support multiple platforms and multiple standards – the expectation of the end user is that they receive the content they have requested. We will have to work out how we are going to deliver that.
Whichever way you look at it…begun this standards war has.