X264 developer says Google's new VP8 WebM codec is a mess

"The spec," Garrett-Glaser says, "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. In many places it is simply outright opaque. Copy-pasted C code is not a spec.

"I may have complained about the H.264 spec being overly verbose, but at least its precise. The VP8 spec, by comparison, is imprecise, unclear, and overly short, leaving many portions of the format very vaguely explained. Some parts even explicitly refuse to fully explain a particular feature, pointing to highly-optimized, nigh-impossible-to-understand reference code for an explanation. Theres no way in hell anyone could write a decoder solely with this spec alone."

Garrett-Glaser noted that "On2 claimed [its VP8 encoder was] 50% better than H.264, but On2 has always made absurd claims that they were never able to back up with results, so such a number is almost surely wrong. VP7, for example, was claimed to be 15% better than H.264 while being much faster, but was in reality neither faster nor higher quality."

The VP8 implementation is a mess

"Irrespective of how good the spec is, is the implementation good," Garrett-Glaser asked, "or is this going to be just like VP3, where On2 releases an unusably bad implementation with the hope that the community will fix it for them? Lets hope not; it took 6 years to fix Theora!"

Other commentators have also noted that Google is largely just releasing code that it obtained without doing the work to actually make it high quality or easy to use, assuming that once the code is available, developers in the community will fix it. But that strategy has rarely worked. Mozilla's failure to fix and release anything functional other than portions of the Netscape web browser over the last decade is a notable example. The majority of Netscape's code, including Communicator, collapsed along with its big plans to deliver XUL as a platform and brand out into mail viewers and media players.

Garrett-Glaser launches into an in-depth technical analysis of VP8, describing the limitations in the design of VP8 while noting many similarities with H.264. Among his conclusions:

"VP8, as a spec, should be a bit better than H.264 Baseline Profile and VC-1. Its not even close to competitive with H.264 Main or High Profile." (H.264 has multiple profiles, each acting as a a separate encoder, making the "standard" really a broad family of related encoding standards, each suited to a particular task. Baseline is for web or mobile applications, Main is targeted at standard definition TV, and High applies to high definition applications such as Blu-Ray.)
"VP8, as an encoder, is somewhere between Xvid and Microsofts VC-1 in terms of visual quality. This can definitely be improved a lot, but not via conventional means.
"VP8, as a decoder, decodes even slower than ffmpegs H.264. This probably cant be improved that much.
"VP8 copies way too much from H.264 for anyone sane to be comfortable with it, no matter whose word is behind the claim of being patent-free.
"VP8 is not ready for prime-time; the spec is a pile of copy-pasted C code and the encoders interface is lacking in features and buggy. They arent even ready to finalize the bitstream format, let alone switch the world over to VP8."

Outlook not so good

If Google can rapidly improve upon the VP8 codebase and specification, and can push chip makers to incorporate support for the new codec immediately, it is possible that Apple will eventually support the new codec in its products.

However, the similarities with H.264 suggest that the real technology licensees behind the world's advanced video processing technology aren't likely to give Google a free pass at erasing their revenue streams. While Apple is largely neutral in this issue as a minor player in the codec business, there are many major players who are going to test the new codec before anyone in the industry with deep pockets is likely to buy into Google's new plans.

That's why Microsoft isn't offering any voice of commitment supporting the free new codec, and why Apple is not likely to get involved unless Google can promise to take the heat by indemnifying all of its partners from patent attacks.

I think it would be correct to say the quality won't be as good as H.264 codec just like xvid/divx given the patent issues. I guess time will tell. As it is already noted, if it become widely available and free (and vastly improved) Apple will support it down the line.

Can some explain what "open (but not free)" means? In what way is something open if you have to pay for it? Regardless of any other measures of the term "open", surely the final arbiter that you have to actually pay for it precludes the use of the term?

BTW, Somehow, the OPs again managed to fire a shot about Flash on completely unrelated topic matter. Bee in his bonnet?

Interesting. I don't know v8 from x264 or whatever, but I am sure there will be improvements down the line.

No. If Jason Garrett-Glaser is correct--and I have no doubt that he is--the issues with VP8 are numerous. They can't be fixed unless significant changes to the format are made to the specification. The result will be that a fixed VP8 will be a different format that is substantially incompatible with most implementations of the current standard.

This article could clearly use some editing...
In several places, the author says VP6 when it seems like they mean VP8
x264 is a video ENCODER not decoder
Everyone got all high on VP8 but without indemnification its not going anywhere. There will be a patent pool and before long VP8 will be subject to the same licensing issues as x264.

Until software patents either get more tightly regulated or abolished completely, there isn't much hope for an open video spec.

There is a difference between open source and open standard. Open source software is generally free, H.264 is an open standard. The reason it is open is because it is not owned by any one company. H.264 is a collaberation between many different companies and organizations.

Quote:

Originally Posted by djsherly

Can some explain what "open (but not free)" means? In what way is something open if you have to pay for it? Regardless of any other measures of the term "open", surely the final arbiter that you have to actually pay for it precludes the use of the term?

can someone PLEASE explain why google is bothering doing this. why create all this hassle and confusion? what is in it for them? what was wrong with how H.264 was going? it seems pretty good with hardware acceleration and everything. i know there are some licensing issues, but they do not seem to be that significant.

Can some explain what "open (but not free)" means? In what way is something open if you have to pay for it? Regardless of any other measures of the term "open", surely the final arbiter that you have to actually pay for it precludes the use of the term?

Open but not free means anyone can write a H.264 video encoder or decoder because the specification is open. However if you use one of those encoders or decoders you're subject to licensing fees paid to MPEG-LA.

Quote:

Originally Posted by yuusharo

Anyone else notice that the author incorrectly wrote "VP6" twice, when they meant to say "VP8?" Sorta makes me wonder if even the author understands what the heck is going on here.

That and the second page was just about all quote from DS without much substantial added.

Granted, understanding video encoding is f*cking hard. 99% of people here wouldn't know CAVLC from CABAC if it bit them in the butt.