We’re in a codecs war, and the main event is going to be between H.264 and VP8. Who will win?[If you are new around here, then you should know I’ve been writing about WebRTC lately. You can skim through the WebRTC post series or just read what WebRTC is all about.]
A few disclaimers before we begin:
- I know video coding theory quite shallowly – at least compared to those developing codecs
- I am more familiar with H.264 than VP8
- I don’t know which of these codecs will win
But – at the end of the day, this isn’t going to matter.
If people tell you the selection of a video codec when it comes to H.264 or VP8 is done on a technical level, then they are lying. For the same amount of bitrate, the difference between the two codecs isn’t big enough to give any of them a real advantage – one that would make you select the one and not the other.
Now that we’ve got that one out of our system, it is time to see what the differences between the two are:
As much as Google would love to tell us, VP8 is not that widespread – especially not if you look into video calling solutions.
The world of enterprise video conferencing revolves around H.264 these days, with a roadmap looking into H.265.
If connectivity to existing video systems is of any importance, then the ability to interact with them directly without the need for transcoding (translating between H.264 and VP8) should be taken into consideration. Transcoding is a taxing task – it requires a lot of CPU, adds latency and can reduce video quality in the process as well. It means that the video stream needs to go through an intermediary media device in all scenarios.
When it comes to legacy systems, H.264 wins big time.
Existence of an ecosystem
When Google announced WebM (=VP8 for this purpose) they also announced a slew of companies endorsing it. The reason for that is that any codec requires an ecosystem of companies – especially the video codec ones. Codecs don’t live in closed systems – they require multiple companies to develop and work with, and that means having everyone on the same page – the same codec spec.
The H.264 ecosystem is larger than that of VP8 and is already in place for a lot of years now.
Need the best example?
That’s 75 times more links for a search of a codec implementation. Not the most accurate one, but it goes to show the power of an ecosystem.
When it comes to the ecosystem, H.264 wins.
Patent related issues
The reason for this post started from patent related issues and openness:
Open video codecs are a must for WebRTC to be successful. Google's VP8 codec is royalty free. http://t.co/M96RLipY
— Kumar Bhogaraju (@techdaemon) August 18, 2012
It is hard to stress the importance of this point. I’ve worked at a video company. Whenever the issue of patents and codecs came up, the delicate legal dance was played out: what are the costs, who pays, how it works.
H.264 is rigged with patents. Most of them are owned by a group called MPEG-LA. In the laundered language of their website:
Our goal is to provide a service that brings all parties together so that technical innovations can be made widely available at a reasonable price. Utilizing our collaborative approach, we help make markets for intellectual property that maximize profits for intellectual property owners and make utilization of intellectual property affordable for manufacturers, consumers and other users.
A simple translation would be that they simply take money from whoever wants to use H.264 because it is patented by a large number of companies – these include the likes of Apple, Microsoft, Ericsson, Samsung, Sony and others.
VP8? It has a free patent license from Google. That said, MPEG-LA stated in the past that it might hold patents over VP8 and it wishes to for a patent pool for it as well.
It is yet to be seen if VP8 will remain patent free or not, but for now, it is the cheaper alternative.
Availability of hardware support
This is the real crutch of VP8: hardware support.
Video codecs are voracious CPU consumers: the more you give them the better.
- To make set-top-boxes work, the manufacturers put specialized chipsets in them that decode the video on hardware, making sure the cost of the set-top box remains low.
- The 1080p video recording on the latest smartphones? It doesn’t come from the quad core ARM CPUs – it comes from hardware acceleration that is designed and built for this purpose – and it does that with H.264.
- Thinking of a new Intel PC? The latest Ivy Bridge series has H.264 encoding and decoding done with hardware acceleration and not using the CPU.
Encoding and decoding video today is a task left for specialized hardware accelerators. You can do it with software, but then you will need to reduce the resolution, frame rate or other tasks running at the same time – not the best of experiences. It will also eat more of your battery.
For VP8 to get the same hardware acceleration as H.264 will take time – a year or two to get there – assuming chipset vendors see this as important enough.
My view? It is going to be a hard decision to make. While openness is important, there’s the ecosystem and availability of hardware to take into consideration. I wouldn’t want to be the one making this decision.