Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


Looking at Today’s VP8 Open Sourcing

May 19th, 2010 by Multimedia Mike

The first thing I thought upon waking this morning was that today is not a good day to be on the internet. I knew that a video codec was going to be open sourced today. And I knew that it would pretty much dominate tech sites all day. And I knew that much of the ensuing discussion — when it strayed into the technical domain — would be misleading, misinformed, or just plain wrong. So why bother?

Fortunately, Dark Shikari posted a very thorough first look at the VP8 algorithm and analyzed how it stacks up, technically, to the currently recognized leading algorithm — H.264. Thus, he hopefully got out in front of the hype (I wouldn’t know; like I said, I haven’t read any discussion today). He dinged the algorithm in a number of areas but assessed that it has some potential and is obviously superior to VP3/Theora. Afterwards, I was able to find the source code, test vectors, and specification for download. Then I read the official announcement that the product I work on at my day job demo’d support for this codec. Then I saw that Sorenson has a product available that can encode VP8.

And then I was struck with a revelation. Put aside Dark Shikari’s learned criticism of VP8’s weaknesses as well as the ever-present patent uncertainty. Can you grasp how incredible this all is? Forgive my giddiness, but look at all we have, coordinated on the same day:

  • Google releases a decent video codec. Complain if you wish that it’s not as good as H.264 but preliminary tests demonstrate that it’s still pretty darn good, certainly better than its vaunted predecessor (VP3/Theora).
  • Google releases source code for it. Complain if you wish about the code’s quality, but it’s all there.
  • Google posts instructions to build the source code out of the box on day 1 with free tools. Compare this to VP3’s source code release late in 2001. Here’s what it took to build:
    • Microsoft Visual C++ 6.0 (Visual Studio 6.0)
    • Microsoft Visual Studio 6.0 Service Pack 4
    • Microsoft Visual C++ Processor Pack (VCPP)
    • Macro File for Microsoft Macro Assembler for Intel Streaming SIMD Extensions
    • QuickTime for Windows SDK (4.0 or 5.x)

    That was on Windows; building on Mac required CodeWarrior. The point is, this newly-freed source code was only immediately buildable using non-free tools. I eventually separated and hacked up just enough code to build under gcc and decode frames (and if I had written a blog at the time, I probably would have published it).

  • Google publishes a suite of test vectors. This is a huge sticking point for me as the volunteer QA manager for FFmpeg, especially since there has never been a good test suite published for other free codec technologies such as Theora and Vorbis.
  • Google publishes a specification. Complain if you wish that “The spec consists largely of C code copy-pasted from the VP8 source code, up to and including TODOs, ‘optimizations’, and even C-specific hacks, such as workarounds for the undefined behavior of signed right shift on negative numbers.” Having this kind of thorough documentation on day 1 boggles my mind.
  • Google releases patches to allow the encoder and decoder to interoperate on day 1 with leading open source multimedia programs such as FFmpeg and MPlayer. Google employees were also poised to engage these communities on day 1 to push these patches into upstream codebases (e.g., this patch and this patch from Google’s James Zern).
  • My company, Adobe, demos support for VP8 in the internet’s leading video delivery platform, Flash Player (the product I work on). Complain if you wish regarding Flash Player (heh, do it) but it’s the fastest way to make a video codec ubiquitous.
  • Sorenson makes an encoding product available on day 1.

All told, today’s VP8 release is nothing short of remarkable. Compare this to the last time a video codec was open sourced. That would be On2’s VP3 near the end of 2001. That was a code dump that was impossible to compile out of the box using free development tools, came with no test suite, had zero documentation outside of the code and nearly none inside the code, and was followed up with very little community engagement. It was over 2 years later that I finally started to understand the codec well enough to write the first scrap of high-level documentation as well as the first independent (and, still to this day, one of the very few) decoder implementation. I guess I was just sort of expecting the same kind of thing this time around.

The VP8 spec is titled “VP8 Data Format and Decoding Specification.” Sounds very similar to my “VP3 Bitstream Format and Decoding Process”. I like to think I helped set the standard for documentation as evidenced by the spec’s title. Is it arrogant to try to take credit for that? Which reminds me– I need to see if the Free Software Foundation has yet taken credit for Google’s open sourcing of VP8. Well, they have a press release praising the event while not taking credit.

Still, complaints that the VP8 spec might not be all that great, or that the code may be a bit weird or suboptimal or not fully C99-compliant, cause me to snicker when I put it in perspective. It makes me ecstatic to realize how far our collective community standards have evolved in the past 10 years. When VP3 was open sourced, On2 was praised for the gesture, even though the event had all the shortcomings I outlined above. If today’s open sourcing event had paralleled VP3’s event in execution, Google would be roundly (and rightfully) criticised, ridiculed, and generally dismissed. This open sourcing event has legs.

That’s progress. I’m happy.

Posted in VP8 | 4 Comments »

4 Responses

  1. Avenger_teambg Says:

    The documentation would probably be better if Google actually had time to work on it. But, as far as i know, they were viciously urged to “release”.

  2. Andrew Says:

    Mmmm, will have to see if it’s worth using for archival stuff (now I’m helping more actively at a computer history museum, I want to do some video of course!), both low and high bitrates. I’ve no idea what the patent restrictions really are for H264, even if it is superior it’s a kind of overhanging issue.

    You’re right, it’s pretty fun to read and see all this activity, and I hope the integration of it into all the different bits works well so I’ll see updated encoding of such videos (they do VP3 right now I guess), and some good way for me to use it thanks to the people doing the work :)

  3. Jim Leonard Says:

    I find Dark Shikari’s analysis very enlightening — as I suspected from the marketing material, it *is* a poor knockoff of H.264 (“H.264 Baseline Profile with a better entropy coder”) and I have no idea how it will escape litigation.

  4. DonDiego Says:

    @Andrew: For archival purposes you need not worry about patents, which have a very limited lifetime. You may want to consider lossles codecs though.