At Google IO, the Google team talked repeatedly about having done "a thorough legal analysis" into the VP8 video codec to make sure it doesn't infringe any patents . "We're very confident with the technology," product manager Mike Jazaeri told us; "that's why we're open sourcing it". The licence is BSD-consistent - rather than the standard BSD licence - because "there's some additional language around patent provision to make sure that the community that adopts this will be protected."
That sounds confident and practical and it's obviously enough to get Broadcom and Intel and Microsoft taking VP8 seriously. Google's team won’t have looked at the H.264 code itself to avoid accusations of knowingly infringing patents (it's never written an H.264 codec), but someone must have. So I wonder a lot about the comments from Jason Garrett-Glaser where he suggests that VP8 is remarkably similar to H.264 in a number of areas. He is the primary developer of x264 - an open source implementation of H.264 - so he has in-depth knowledge but he's also competing with VP8. None the less, if the spec really does include large portions of obfuscated code, it does make it hard to do a thorough analysis of what is and isn't covered by a patent.
I also wonder why Google told us that "no open source stuff is indemnified"; Microsoft's agreements to indemnify some Linux vendors like Novell has certainly been controversial and Sun's indemnification of Solaris didn't give it a huge market advantage - but the idea that open source indemnification just doesn't happen isn't quite true.
Jim Bankoski came to Google from On2 along with the VP8 codec and he's very keen on the quality. "We think the video quality is great; it's not blurry, it's sharp, there's not blocks. We have strong playback performance and fast playback - we'll play on low-end processors like your Atoms and your Snapdragons. We also have great live two-way encoder performance; we do very well in real time performance. We don’t have anything that does lossless compression like H264 does but I think we compare pretty favourably across the wide spectrum - not to say we’re always going to win but we do well." Skype uses the codec (and is popular enough that not having been sued for the patents is certainly a good sign) and good performance on mobile phones and the Atom-driven Google TV sets would be a big advantage. But it does worry me that Bankoski talks about the test set for VP8 being around 70 videos - which he calls a wide test set. To my mind, a wide test set is more like 1,000 clips, maybe a lot more. Obviously, they'll have a lot more videos to work with as YouTube sets about VP8-encoding new content...
The other thing I wonder about is how Google will balance innovation and acceleration. Intel doesn't have a VP8 hardware accelerator at the moment, so the first Google TV models will do VP8 entirely in software. Broadcom and QUALCOMM and the other companies who are going to deliver hardware acceleration of VP8 will do it for the codec as it is now - but Google is also keen to have the benefits of open source development improving the codec. That means there are going to be two versions of VP8 - one for the hardware folk and one for the software folk. Managing the code tree for that and bringing those improvements through into the hardware-accelerated world will be an interesting problem.
I'm also wondering exactly how IE9 will support this; Microsoft evangelist Tim Sneath told us it will use the DirectShow VP8 codec (there's a QuickTime VP8 codec on the way as well) and he expects that means it will just work in a Web page rather than needing to pop up in a media player (and codec on your system is supported if the video is set to play in a media player in IE9). The IE9 team says they're working through the technical issues - and there's no word on whether VP8 support will be in Platform Preview 3 when IE9 gets the VIDEO tag.
Whether VP8 becomes a significant codec is going to depend on the quality, on whether the MPEG-LA group goes after it the way Steve Jobs claims someone will go after Ogg - and on how useful developers find it for their Web sites given that it has no DRM so you can't protect content. It all proves John Chambers of Cisco right: video is going to be even bigger online than it already is.