My Product Requirements for VP10

Time to talk about the future of video codecs.

Current status?

• H.264 is ubiquitous, and exists everywhere. It is also heavily patented, which makes it hard to innovate with.
• VP8 is pushed hard by Google. Specifically for web video streaming and in WebRTC for video calling.
• H.265 got standardized recently. It is twice as better as H.264 and 2-3 times as heavy in CPU requirements. It is based on the same “business” recipe as H.264.
• VP9 is being worked on by Google. On par with H.265, but without the patent royalty issues.

If you ask me, these two trajectories of VP8/VP9 and H.264/H.265 bring nothing new to the table. They both take the same route: add some more processing tools that eat up more CPU and be able to crunch the video a bit better.

When the time comes for VP10 – I want it to be different.

If I were the Product Manager of VP10? Here’s the things I’d ask for from my development team:

1. More resolution and frame rate. Today it is all about 1080p and 30 frames per second. 4K displays are upon us, and this new VP10 codec of ours is 5-10 years down the road. Why not prepare for the next evolution after 4K? 16K or 60-120 frames per second? While it doesn’t make any real sense to me now, this is bound to happen.
2. Twice the CPU for half the bitrate. Another no-brainer. And the values should be when compared to VP9 for the same video stream and same end quality. We ask it from any next generation video codec, so VP10 should be no different.
3. 20% less resources than H.266. You didn’t think H.265 is the end of the road now did you? Next in line is H.266 or whatever name they give it, but it is our direct “competitor”. We want our codec to be a bit “thinner” in his requirements, making it a bit more efficient.
4. 10-15% less quality than H.266. Since we are reasonable, this less resource requirement comes with a price – one of quality. We’re going to leave out specific tools from the video codec that we know can improve the quality, but that their cost is going to be too taxing. The assumption is that VP9 is so good as it is, so doubling the quality and not putting it at the same quality level of H.266 should be fine. Remember that all other parameters around us are changing anyway – including available bandwidth.
5. JavaScript enabled. This is where I see the differentiation. I want this codec to have its initial implementation written in JavaScript on a web browser. Not as a wrapped implementation – it should access its heavyweight processing tools via JavaScript and have the brains and control of the codec done in JavaScript.

What is JavaScript important? Because it allows innovation to flourish, and ORBX is showing us the way already.

If we get this one right, then innovation can start happening in the codec level itself as well, and the building blocks we make can be used for other types of solutions – not only those I define as the Product Manager.

I want to take you back for a moment to one of the first interviews I did. The one with Serge Lachapelle, Group Product Manager at Google, where he answers my question about compelling services and demos he’d seen:

All the games, augmented reality and the gesture tracking have really surprised the whole team.

Think how people are going to surprise VP10 development team when they see what other uses, not in the initial list of use cases, people come up with.

The next generation of codecs after VP9 and H.265 should be JavaScript ones. Anything else will be too boring.