That is all well and good for Google, but what does that mean for me, the guy who just wants to lay on his sofa and watch cute kittens? At this point, pretty much nothing.
This is a short excerpt from an otherwise well balanced article explaining the players, roles, and technologies involved in Google’s decision to remove H.264 support from their HTML5 video tag implementation in Chrome. The sentiment expressed is that it doesn’t matter much to us mere mortals. That couldn’t be further from the truth. If Google is successful in pushing WebM as the standard means of encoding video on the web, it will render millions of devices obsolete, impacting the millions of consumers who own those devices. How?
In many articles on this topic, you’ll find passing mention of something called “hardware decoders”. Since my goal is to explain what Google’s actions mean to the Average Joe, I’m going to go through the trouble of backing up a bit and explaining a few things about video, and how it is played back on various devices.
All this talk about video codecs, what does it mean? A codec (short for coder/decoder) could be thought of as a process definition. Say you had a letter that you wanted to send to a friend, but the post office charged based on the length of the letter. You have two choices: you either shorten your message, or you find a method by which you can reduce the number of characters required to communicate the same information. Expressing the same information using fewer characters is something computer scientists call compression. In addition to compressing the message to save on costs, you’d want to make sure the letter was written in a language that the recipient understands. And what about his ability to open it and access the contents? You need to make sure the envelope is accessible and allows the recipient to easily access what’s inside. That sounds like a silly requirement, but it’s relevant when you look at the details. You could think of all these details as a “codec” for writing and delivering a letter†.
† I’ve lumped codec together with file format here, which is technically incorrect, but trivial for understanding this issue from an end-user perspective.
So how does this relate to web video? All of the seemingly inane details expressed above are the type of things that computer scientists think about when they design a video file format. Interestingly, codec is just one aspect of a video format. I won’t go in to the others, but it’s worth understanding that the problem is very complex and covers many different areas of knowledge. For the moment, let’s look at the compression part.
Inside your computer is a very, very powerful microprocessor called a CPU. Your CPU is capable of computing solutions to a very wide variety of problems. Because of this, we call it a general purpose microprocessor. It is possible, however, to build a kind of CPU that is optimized to perform a very specific task. In the various articles written about Google’s WebM decision, you’ll find mention of an “H.264 hardware decoder”. What does that mean?
H.264 hardware decoder: a specialized microprocessor that is purpose-built to decode the target codec.
Examples of H.264 hardware decoders:
- The video card in your computer probably has one
- The iPhone has one
- The iPod has one
- Most Android phones have one
- If your TV can play video from an SD card or computer, it has one
- If your digital camera shoots video, it probably has one
- Your digital camcorder probably records in AVCHD (incorporates H.264)
- Virtually every video production suite on the market can utilize an H.264 hardware encoder-decoder
So what does an H.264 hardware decoder do for you? In short, it allows you to watch high-resolution video while using far less battery than it would if you used your device’s CPU. When sitting at your desk, you’d think this wouldn’t matter, but playing back a 1080p video encoded using H.264 can peak even modern processors at 80%-90% utilization. That means the loud fan in your computer is going to turn on and make noise while you’re trying to watch your movie. On laptops, the consequence is even more severe. You can lose hours of battery life by not using H.264 hardware decoders. On mobile devices, it’s game over. Your phone doesn’t have a powerful dual-core CPU. It has a tiny mobile CPU that simply doesn’t have the horsepower to decode high-resolution video on the fly. You’ll be stuck with lower resolution, larger-size video that requires less computing power.
Feel that pit developing in your stomach? Yeah, I’m right there with you.
Let’s look at some numbers:
- 50 million iPhones 
- 450,000 iPads 
- 220 million iPods (as of Sept 2009) 
- 8.5 million Android phones (as of Feb 2010) 
That’s close to 280 million devices with H.264 hardware support, and I haven’t scratched the surface. There are no televisions on that list. Remember CES and all the hype over Android tablets? None of them have WebM hardware decoders. On every one of these devices, the cost of WebM video playback will be:
- Greatly reduced battery life
- Larger file-sizes (less compression will be required for smooth playback)
- Lower resolution
We’re talking about falling back from every major milestone met by mobile device manufacturers in the last three years, and millions of devices rendered obsolete for video encoded in WebM. What happens if Google goes WebM-only for YouTube? Right now, Apple supports H.264 exclusively on their mobile devices? Why is that? Because Apple considers user experience to be first priority. Even if Apple were to implement WebM on their mobile devices, the consequence would be jittery video playback that sucked your battery dry in no time. That’s not a good user experience.
So, what does this mean for the Average Joe? If Google is successful, it means that your user experience will be significantly degraded on any device you own that contains H.264 hardware, but no WebM hardware. Have a look at the specs for your phone, portable media player, television, and home theater media devices. Any of them that rely on H.264 hardware are at risk for becoming obsolete.