The news yesterday that Google’s Chrome web browser would be dropping support for H.264 was seen by many as a big step backward for HTML5 adoption. Despite Google’s insistence that the announcement was about advancing openness for the future of video on the Web, the unintended consequence of the announcement is that now more than ever, publishers will rely on a proprietary technology rather than open standards to reach a mass audience on the web.
That’s because Chrome’s backing of its own open-source video codec at the expense of H.264 will only create more confusion for video publishers trying to balance the needs of reaching a wide audience while also embracing standards. In a tweet yesterday, Adobe’s John Dowdell had this to say about the news:
Practically speaking, today’s codec news changes nothing save the propaganda. To reach the world, you need Flash, then something for Apple.
Which is precisely true. But the common thread between Flash and Apple was support of H.264 — which is one reason why so many publishers have embraced the codec to this point. Encoding in H.264 meant you could serve in Flash, but also reach iOS devices with an HTML5 video implementation. Dowdell even admits as much in another tweet, suggesting “Apple needs Flash even more now, to help rationalize creators encoding to H.264.” Those HTML5 video streams could also be viewed by a growing number of browsers on the desktop, including such as Chrome, Microsoft’s Internet Explorer 9 and Apple’s Safari.
Because of this, the amount of video encoded in the HTML5-ready H.264 format doubled over the course of five months last year, and now accounts for more than half of all video on the web. But for publishers that have already bet heavily on HTML5 video — and on H.264 as the codec for most HTML5 delivery — Chrome’s decision throws a big monkey wrench in those plans and could force them to encode all their videos again.
One such publisher, Blip.tv, announced plans last year that it would default to HTML5 video when possible, delivering in Flash only when a viewer with an unsupported browser (like Firefox or an older version of Internet Explorer) tried to access its videos. Now that strategy is being thrown into question, as Chrome’s non-support of H.264 now means that it will either fall back to delivery via Flash when a future Chrome user tries to launch a video — or it will need to re-encode all its video assets in the WebM format.
In an email, Blip.tv founder and CTO Justin Day wrote:
“Our current HTML5 player in testing already uses Flash as a fallback video component so it’s likely we would rely on that rather than double encode everything. At the end of the day it doesn’t really change much since Firefox doesn’t support H.264 either. That said it’s frustrating to have another hurdle to get over in a technology already fraught with hurdles.”
The good and bad news for publishers is that with Chrome support, as well as the support of open source browsers such as Firefox and Opera, a majority of next-gen web users will be able to access WebM-encoded videos. Even Microsoft has said that, while WebM won’t be supported out-of-the-box on IE9, it will support the codec if users install it on their systems. That means Apple’s Safari will be the lone browser holdout, but Safari only holds a tiny amount of market share compared to the others.
But the codec war on the desktop is really just the tip of the iceberg; getting open standards embraced on future connected devices will be the real hurdle. H.264 support is near-ubiquitous on mobile devices and connected TVs, in part due to hardware acceleration already built into today’s device chipsets, but VP8 has a long way to go before it has anywhere near the hardware support.
For publishers looking to reach audiences on the next generation of screens, it will be a long time before VP8 is a suitable replacement for H.264. Until that time comes, they will need to either encode to support both WebM and H.264, or encode in H.264 and use Flash for delivery to most browsers while using HTML5 video to reach iOS devices.
Related content on GigaOM Pro: (subscription required)