simonbrenner.org

Collecting Information

VP8 vs. H.264

5/20/2010

There is a very interesting article about Google's video codec VP8 written by an x264 developer called Jason Garrett-Glaser (aka Dark Shikari) which you can completely read on:

http://x264dev.multimedia.cx/?p=377

The title is "The first in-depth technical analysis of VP8".

Here are some central statements out of it:

  • Verdict on Intra Prediction: Slightly modified ripoff of H.264. Somewhat worse than H.264 due to omission of i8×8.
  • Verdict on Inter Prediction: Similar partitioning structure to H.264. Much weaker referencing structure. More complex, slightly better interpolation filter. Mostly a wash — except for the lack of B-frames, which is seriously going to hurt compression.
  • Verdict on Transform: Similar to H.264. Slower, slightly more accurate 4×4 transform. Improved DC transform for luma (but not on chroma). No 8×8 transform. Overall, worse.
  • Verdict on Quantization: Lack of well-integrated adaptive quantization is going to be a killer when the time comes to implement psy optimizations. Overall, much worse.
  • Verdict on Entropy Coding: I’m not quite sure here. It’s better in some ways, worse in some ways, and just plain weird in others. My hunch is that it’s probably a very slight win for H.264; non-adaptive arithmetic coding has to have some serious penalties. It may also be a hardware implementation problem.
  • Verdict on Loop Filter: Definitely worse compression-wise than H.264’s due to the lack of adaptive strength. Especially with the “fast” mode, might be significantly faster. I worry about it being too blurry.
  • VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder”.
  • Before I tear the encoder apart, keep in mind that it isn’t bad. In fact, compression-wise, I don’t think they’re going to be able to get it that much better using standard methods.
  • The encoder and decoder share a staggering amount of code. This means that any bug in the common code will affect both, and thus won’t be spotted because it will affect them both in a matching fashion.
  • Google has chosen Matroska for their container format.

I definitely recommend reading at least the "Addendum C: Summary for the lazy".


Leave Comment