It still struck me as odd: Why would Google claim that no one was interested in their platform when they wouldn’t give anyone a chance to try it out? A little digging reveals that Google did open it for general use back around May 18. That date sounds familiar… oh yeah, VP8 was open sourced right around the same time. Maybe that’s why I don’t remember hearing anything about Wave at the time.

But now I’m wondering about VP8 and WebM. How long do you think it might be before Google loses interest in these initiatives as well and reassigns their engineering resources? Fortunately, if they did do that, the technology would live on thanks to the efforts of FFmpeg developers. A multimedia format has a far more clear-cut use case than Google Wave.

Pictured: All the proof you need that VP8 is superior to H.264
Update: The preceding comment is meant in sarcastic jest. Read on

The Official VP8 Facts:

• VP8 is superior to H.264. Source: On2′s website, many PSNR graphs.
• VP8 is free from patent worries. Source: On2′s website (“no patent-pool royalty hassles”).
• VP8 delivers objectively better visual quality than H.264 at the same bitrate. Source: Video encoded in On2 VP6, created by On2, posted on On2′s website.
• VP8 can be implemented on low-power hardware. Source: DSP Design Line article authored by On2′s CTO.
• VP8 uses golden frames (just like every On2 video codec since VP3). Source: On2′s website.
• VP8 uses loop filtering (another cornerstone of every On2 video codec since VP3). Source: On2′s website.
• VP8 is scalable to many cores. Source: On2′s website.
• VP8 produces objectively better results than even x264. Source: Again, On2′s website. Sorry, my x264 pals, but they have charts and graphs to back them up, so, you know…

That’s pretty much all we know about On2 VP8. Notice a common theme? That’s right: Everything we know about On2 VP8 comes from On2′s own publicity material. As of yet, we have no samples encoded in the format, and we certainly don’t have any public encoders or decoders.

So, yeah, you can write me off as being consistently annoyed when the VP8 topic crops up. Take a look at the subtitle of this blog: “Topics on multimedia…” Codecs are my business (well, hobby, anyway) and my multimedia pals and I have cataloged around 200 different video codecs on our little wiki. Call us codec snobs but we like to know technical details surrounding codecs. Or, failing that, we like to have samples we can study along with maybe a binary decoder and/or encoder so we can evaluate the suitability of the codec for certain tasks. Thus far, all we have to go on is On2′s own word about how awesome their technology is. It’s a bit odd to see so many people taking a (non-Apple) company’s claims at face value.

Do you believe the marketing material? As a baseline, you’re invited to read the VP6 and VP7 whitepapers which provide similar objective proof of those algorithms’ superiority over H.264 and other standard codecs.

Different Requirements
From most of the stuff I have been reading (articles, blog posts, and ensuing comment debates), people are lapping up the marketing material. I was incredulous until I realized that most of these observers are simply interested in different things than I am.

I — and, I suspect, many of my multimedia colleagues — are salivating for some more solid technical details surrounding this codec. It’s what we live for. I need to recognize that most outside observers take the view that a video codec is a video codec is a video codec, i.e., they’re all more or less the same and fairly interchangeable. The hope is that On2 VP8 will, at long last, provide patent and license purity that all relevant stakeholders (Google, Apple, Microsoft, Mozilla) will be able to agree on. Quality? That would be nice too, but it seems to be a foregone conclusion that VP8 offers more than enough quality, especially when considering that Theora is based on VP3, which many consider good enough, and VP8 has a higher number than VP3. Ergo, VP8 must be 5 times better than VP3/Theora. Or 5 more better. Or something. And besides, On2′s own marketing materials explicitly state that VP8 is better than H.264.

Flash-Killa
It would be disingenuous to omit the Flash-killer angle driving so much of the fervent anticipation surrounding the VP8 speculation. VP8 goes open source => all major browsers adopt it overnight as a standard video codec for HTML5 video => blight of Adobe Flash is eradicated the following week, since Flash’s only use is as a naive video player. Things move just that quickly. I’ve covered this ground already, i.e., how all of this HTML5 stuff is totally going to crush the stuff I work on at my day job.

What Is It, Really?
There’s too much speculation out there surrounding On2 VP8… but that won’t stop me from adding my own: Since, to my knowledge, VP8 has never actually been licensed or used outside of On2, the engineers could still be tweaking it behind the scenes, or even overhauling large segments of the algorithm. The list of publicly discussed features doesn’t explain a whole lot about the overall codec operation.

Writing this article motivated me to re-read and carefully study that DSP Design Line article and I must confess that there are some interesting tidbits in there. One item that caught my attention was their concept of SIMD without dedicated SIMD instructions. It’s nice to see On2 getting back to their roots– this concept forms the basis of On2′s very first video codec, Duck TrueMotion 1 (effectively VP1).

The DSP Design Line article is far more fascinating than any of the literature on On2′s site. The article paints a picture of a powerful and flexible codec that is suitable for low, medium, and high bandwidth applications and whose decoding algorithm can be scaled to operate realtime on low power, mobile CPUs all the way up to beefy, multicore desktop machines, all while offering efficient and accurate compression. If the codec offers all of these technical benefits, plus truly free licensing terms and is satisfactorily patent-free (or indemnified), I look forward to singing VP8′s praises.

The most pressing reason for funding this effort is, of course, license purity.

The BBC article reports that the underlying chip technology is supposed to be similar to the stuff found in singing greeting cards. That sounds like an oversimplification. But the article also names the tech supplier– Americhip, the self-proclaimed leader in multisensory marketing. They have a YouTube channel with demos of this and related technology.

Who knows? Maybe they actually are using the classic Duck TrueMotion video codec in JavaFX.

Curiously, there is no word on what JavaFX will use for audio. Maybe logarithmic PCM in au/snd files?

Remember the days when CD-ROM storage capacities were expressed in terms of how many printed documents it could hold? Later, the benchmark was number of pictures, then songs. Now it’s movies. This article cites that a device built around the memory could hold the 3500 movies or 1/2 million songs. Thus, the average movie is ~140 times larger than the average song.

The weirdest aspect of the articles floating around is that the hypothetical device would come with 3500 movies prepackaged and the consumer would purchase codes to activate individual movies.

Given recent media consumption trends, there’s little reason to doubt this strategy.

It’s hard to find anything about this initiative that’s not a rehashed press release. But this Sun blog seems to have the most authoritative information, abstract though it may be. They present a fascinating design approach: Rather than evaluate algorithmic techniques based on their performance, evaluate them based on their legal status.

Good luck to them. Here’s a Wiki page to track it.

That’s nice. But let’s cut to what really matters — multimedia. The SDK specifies the Media API along with its MediaPlayer and MediaRecorder APIs. According to the AudioEncoder class, audio can be encoded to AMR-NB. The VideoEncoder class specifies H.263, H.264, and MPEG-4 SP. All pretty standard for a mobile application, I suppose.

Who handles the multimedia heavy lifting? Vitor noticed this press release and associated fluffy overview from PacketVideo

It’s Java, though, and that means obfuscated Java bytecode programs. Time for a renaissance for my Java de-obfuscator?

If you’re like me (and, let’s face it, if you read this blog then you probably are), you are interested in the multimedia features of this proposed platform.

The literature that I have perused thus far has not made any remarkable claims with respect to multimedia capabilities amidst all the other wish-granting facets of the phone framework. The above picture, which seems to be the mascot image, specifically sports that ubiquitous symbol of multimedia playback — the rightward-facing arrow in a circle.

Since “open source” is a key selling point of this platform, what are they going to use for a general multimedia backend? I can hardly imagine.