How Google Stuck a Dagger in HTML5 Video

Not sure if Google intentionally planned to rain on Apple's parade around the unveiling of the Verizon iPhone, but they sure have raised a lot of questions around the future of online video on 1/11/11. Yesterday Google announced that they would be dropping h.264 support from their Google Chrome web browser. This news has raised questions for our clients, so I would like to address them and give a bit of commentary on the whole situation.

A Brief History of Online Video

Since around the dawn of YouTube, embedding a bit of video on the web meant using nasty standards un-compliant code like the following:

The above chunk of code is a smorgasbord of an object tag and an embed tag, and it relies on the user having Adobe Flash installed on their device. While the above code is a bit ugly and doesn't conform to HTML standards, it was a big step up from the days of embedding Windows Media Player videos or RealVideo.

But with the spec for HTML5 having reached the stage of being a working draft, we get the treat of simple clean semantic markup to embed video on a page. One day in the future, when all is right with the world and we're all writing pure and clean HTML5 semantic markup, that chunk of video will look something like this:

I understand if you had to look away due to the blinding beauty that is that code. The promise of HTML5 is that you can point right at a video file, and let the browser do the rest. For extended reading on HTML5 video, I highly recommend the chapter Video On the Web from Dive Into HTML5.

Recent h.264 Adoption

Adoption for HTML5 video picked up a large head of steam about a year ago, when it was announced that Apple's iPad would not support Adobe Flash. This meant that many online video publishers needed to start supporting HTML5 video, and most did just that — visit YouTube, CNN, or The New York Times with an iPad, and you will see that they are using HTML5 video.

Now, all videos aren't created equal — the technology that is used to turn high-quality video masters into web-optimized files is called a codec, and h.264 has been the most popular when it comes to HTML5. Chrome and Safari both support h.264, and Apple has added h.264 hardware decoding (read: battery-saving stuff) into Mac computers, iPhone, iPad, iPod touch, etc. etc.

Heck, even Internet Explorer 9 is going to support h.264, and IE isn't a browser known for being the first to a party since Netscape bit the dust. The only hold-out has been Mozilla Firefox, as they support their own format, Ogg Theora, and Google's WebM, and have cautioned that one day in the future the creators of h.264 could start charging the browser-makers money to decode due to patents they hold on the technology.

Currently MPEG-LA doesn't charge browser-makers, and have guaranteed until 2015 that they won't, and have promised not to exercise their patents after 2015. And even if they could, it seems like folks like Apple, Google, Microsoft, and Mozilla could probably swing the royalty costs. With that, it looked like h.264 was all well and good, and adoption of the codec would continue at a steady pace.

So What is Google Doing and Why?

Google's statement, from the Chromium Blog, is as follows:

They are saying that they will not allow Chrome to decode h.264 video if it is used in an HTML5 <video> tag. The only way for h.264 to render in Chrome would be if it is wrapped up in a Flash player. Google says they are not advocating this, and instead are advocating that content publishers start using Google's own WebM codec. Google released WebM as an open standard in 2010, though it is largely untested, and its spec contains large amount of copy-and-pasted C source code. Not exactly something that the rest of the players in the industry are ready to jump onboard with.

Why are they doing it? It's either a power play against Apple, or is the case of ideologies getting in the way of common sense. I certainly understand pushing open standards, but not allowing hardware decoders to be used when they are available is just plain silly. One thing is for sure, the only winner here is Adobe Flash.

Lastly, Google's line regarding "technologies that are developed and licensed based on open web principles" (i.e., WebM) is more than a little questionable when you consider that they have packaged Flash into Chrome. While there is an open spec for processing Flash .SWF files, Adobe is the sole proprietor of Flash, and controls the future (or lagging) of that technology — far from being an open standard. Not to mention that Linux developers have had a hell of a time building an open source Flash player that works the same as Adobe's closed Flash Player, so there are questions around how correct Adobe's spec really is.

Who Should be Worried?

For our users that use video delivery platforms such as Brightcove and Ooyala, they will be fine — both will continue to send h.264 to iPhones, iPads, and wrap h.264 in Flash players for Chrome. Maybe one day they will serve WebM as well as h.264 (the HTML5 spec does allow for multiple files), though it is a shame that they would need to encode a video twice.

If you are an advocate of adoption for HTML5 and want to see the browser-makers converge on a proven technology, this is more than a bit worrying. This move is going to push back the adoption of non-Flash video by years — content publishers will now need to supply both an h.264 and WebM format of the video to appease all parties if they want to be able to support HTML5 video for all.