We’re in a codecs war, and the main event is going to be between H.264 and VP8. Who will win?
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
For a more thorough view, check out this more updated article: 🎲 Which video codec to use in your WebRTC application? 🎲
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:
“Legacy” systems
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:
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.
Let’s be clear here this isn’t about anything technical. Not even adoption of current codecs. Or hardware support by smartphones.
Here is the list of reasons:
1. Just look at Opus, it has had no adoption what so ever. Opus is completely new.
2. On of the people at the last IETF meeting mentioned there was a study which says hardware accelerated video encoding on (I think it was) an iPad 2 would drain the battery after 9 hours, while software encoding did it in 8. So hardware support isn’t really such a big issue after all.
3. VP8 has been shown to get pretty close to H.264 in quality.
Some other interesting facts:
A. Skype is one such ‘legacy system’ and it already uses VP8
B. Google has made a statement which says they won’t sue on patents around VP8.
So best remaining argument, as far as I can see from the H.264 camp is:
“We don’t know who else has patents on VP8. We’d rather pay for H.264 we know exactly what the price for that is.”
But I’m fairly certain the people from On2 who developed VP8 are the same people who worked on previous versions.
Here is an old recording with a discussion of the older codec from On2: https://hacks.mozilla.org/2009/07/open-video-codecs-discussion/
They are obviously very careful not to use anything which is covered by a patent. Their business relied on it, licensing their codecs to others was part of their business model.
But hey, that is just my opinion 😉
It seems like VP8 makes more sense. It may be free, and won’t be more than H.264 which should stimulate ideas and apps. This is about the future, not the past. It’s already partially implemented in browsers and WebRTC was moving fairly quickly prior to the codec battle. The ecosystem doesn’t matter – it is going to be new apps and endpoints that initially matter, and if you do count the ecosystem Skype has the most users.
If only life was that simple…
Skype has stated use of VP8, but I do believe that they still use H.264 for most of their calls and definitely for HD calls using cameras that encode the video.
I’d also question their continued support for VP8 now that they are a part of Microsoft.
Another point around cost reduction. If my information is correct H.264 SVC is a premium cost on top of regular licensing fees. VP8 provides a functional equivalent called Temporal Scalability, which is free. SVC / TS are useful because they add resiliency to network loss and provide for rate adaptation.