Flash Still Rules in Chrome’s WebM-Only World


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 (s goog) 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 (s adbe) 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 (s aapl) 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 (s msft) 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 (s MSFT) 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 (s AAPL) 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.

Image courtesy of Flickr user Cameron Russell.

Related content on GigaOM Pro: (subscription required)


Nathan Murro

“as well as the support of open source browsers such as Firefox and Opera”

Opera isn’t open source.

Iain Richardson

Encoding twice to support both H.264 and WebM? That’s very bad news for content providers and consumers. Plus don’t forget that every re-encoding step degrades video quality, since H.264 and WebM/VP8 are both lossy formats. Isn’t it time that we (the techies) started coming up with solutions to this problem?
– Iain @ onecodec


The biggest obstacle for HTML5, like all other internet standards before it, is Internet Explorer. Even the current beta version of IE only supports a tiny minority of HTML5 and CSS3 features. IE’s widespread use is the biggest threat to internet standards, and always has been.

As for the web video debate, we’re all being punked. There is no urgency to distill web video down to a single choice. In fact, we have that already in Flash as a delivery vehicle, and it’s worked great for both providers and consumers until now. The only people complaining about it are Mac users, following Steve Job’s politically motivated lead, and who represent a tiny minority of internet traffic. They SHOULD be turning their anger towards Apple for not making their OS work better with something so ubiquitous as Flash. But ego has gotten in the way and here we sit, trying to shift the entire internet to suit a tiny minority of people at the overwhelming expense of content providers and browser developers. How does this make any sense?

Freedom of choice is far more vital to the health of the internet than rigid, narrow standards are. This entire argument of “Flash vs. h.264 vs. Other” is based on a false premise that we must choose one. That doesn’t really serve anyone’s best interest except patent holders. Content providers should be able to choose what works for them based on their situation and their customer’s needs. If the browser developers want to implement their own native video players that’s fine, but they should be prepared to support a variety of codecs or stay out of the playback game entirely.

If someone can explain which internet users are actually being served by narrowing our video playback and codec options to just one, I’d love to hear it. I’d also love to hear how this will positively impact the future of online video, given that software developers will have no incentive to develop new, more efficient codecs and containers once a single format is declared “sole choice of the internet.”

Comments are closed.