WebM vs. H.264: A First Look
The rap against using multiple threads/slices is that it can degrade quality because the encoder doesn't search for interframe redundancies between slices, just within each slice. However, I compared the two WebM files and saw minimal, if any, quality differential. Run your own comparison on your content to verify this. But if encoding time is a concern for you, buy a 24-core system like the Z800 and use multiple threads when producing your WebM files. The bottom line is that WebM takes longer to encode, but the differential isn't that great and probably will only impact high-volume shops.
Quality Trials
When WebM was first announced, I compared a WebM file against an H.264 file produced by Sorenson Squish. I concluded that "H.264 still offers better quality, but the difference wouldn't be noticeable in most applications." Now, I've spent a bunch of time producing both formats, and I've reached the same conclusion.
Note that Sorenson Squeeze uses the MainConcept codec, which has been the highest quality commercially available codec in my comparison tests. To supplement these tests, I also produced comparison files with the x264 codec, using the QuickTime-based x264Encoder version 1.2.13 (dated 27 June 2010) set to the highest quality, slowest encode preset (Figure 3).
In my tests, x264 produced slightly higher quality than the H.264 files produced by Squeeze with the Main Concept encoder, which was slightly better than WebM (Figure 4). In my view, however, slight differences in quality are irrelevant if the typical viewer wouldn't notice the difference absent side-by-side comparisons at normal data rates.
To explain, I produce my 720p test file at 800Kbps, which means that I'm allocating .029 bits per pixel in the 29.97 frame per second file. In comparison, YouTube produces its 720p H.264 video at about 2Mbps, which means an allocation of .072 bits per pixel, 2.5 times higher than mine. Why are my test files compressed so highly? Because if the data rate is high enough, all technologies look good, and it's impossible to differentiate.
What's the most relevant test? In my recent review of video files produced by a range of broadcast and corporate sites, the lowest bits per pixel allocation that I found was 0.43, with most well above .07. Apple produces its iPad advertisements at .168 bits per pixel, about five times higher than my test file, while ESPN produces at .173 and CNN at .106. The notoriously penurious Tiger Woods publishes at .136, though perhaps he'll tighten this up after losing $750 million in his divorce.
Long story short, if YouTube produces its WebM-based 720p files at 2Mbps at 720p, only the most discriminating viewer will be able to distinguish it from H.264, and then, only with side-by-side comparisons, which, of course, viewers never have. It's not whether one technology is better than another; it's whether it's sufficiently better to make a difference for the typical viewer.
I should point out that some highly respected sources don't share this opinion. For example, the Graphics and Media Lab of Moscow State University produces a codec comparison every year; this year it included VP8 (http://compression.graphicon.ru/video/codec_
comparison/h264_2010/#Video_Codecs). In terms of H.264 encoding quality, the report concludes that "[t]he x264 encoder demonstrates better quality on average, and MainConcept shows slightly lower quality," which was my primary motivation for including x264 in this evaluation. Regarding VP8, the report concludes, "When comparing VP8 and x264 VP8 also shows 5-25% lower encoding speed with 20-30% lower quality at average." I just didn't see that.