2010年7月30日
By 1月时特约编辑
专题文章

WebM vs. H.第264集:细看

编码
For encoding, I looked at encoding speed and video quality; let's start with the former. As mentioned, I used a pre-release version of Sorenson Squeeze 6.0.4.63生产WebM和H.264个文件. I produced two test files-one SD, one HD-using long standardized encoding parameters. 对于SD文件, this meant a target data rate of 500Kbps (468 video/32Kbps audio), using 2-pass VBR encoding with all quality related settings set to the max. Squeeze界面使这变得简单, with only a few VP8 related encoding controls, 就像权衡大小和. 复杂性和压缩质量vs. 速度(图1).

图1. Key VP8-related encoding options in the Squeeze interface. 注意编码 Threads选项.

有趣的是, one of the benefits that Google touts about WebM on their web site is "Click and encode. Minimal codec profiles, sub-options; when possible, let the encoder make the tough choices." I was certainly willing to do that and used Sorenson-provided presets for the most part, along with the required adjustments to meet my resolution and data rate targets.

对H.264, 我用了高姿态, 启用CABAC, 有3个b帧和3个参考帧, 和编码努力设定最好的. 为了完成这个圆, I configured the HD test files at 720p at a VBR data rate of 800Kbps video/128Kbps audio (图2).

图2. H.264-related options used in the test comparison.

当产生WebM和H时.264, Squeeze lets you improve encoding speed by using multiple CPUs-WebM via the 编码 Threads option shown in 图1, H.264 by using multiple slices (not shown in 图2). 你可以看到表2, I tested using 1 thread/slice and 12 threads/slices on my Hewlett Packard Z800 with two 6-core 3.33 GHz Xeon processors, doubled to 24 total cores via hyper-threaded technology (HTT).

Ozer WebM表

选中1个线程, producing the WebM file was very inefficient, with only about 4% of available CPU utilized, and producing the WebM file took almost four times longer than H.264. 选择了12个线程/片, CPU利用率跃升至高达30%, and the differential dropped to under 25% for the SD file, though WebM still took 85% longer for the HD file. Note that I tried encoding with all 24 threads enabled, and it actually slowed encoding time.

The rap against using multiple threads/slices is that it can degrade quality, since the encoder doesn't search for interframe redundancies between slices, 就在每一片中. However, I compared the two WebM files and saw minimal, if any, quality differential. Run your own comparison on your content to verify this, 但如果你担心编码时间, buy a 24 core system like the Z800 and use multiple threads when producing your WebM files. Bottom line is that WebM takes longer to encode, 但差别并不是很大, and probably will only impact high volume shops.

质量试验
When WebM was first announced, I compared a WebM file against an H.264 file as produced by Sorenson Squish, and concluded that "I'd say 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 reach the same conclusion.

Note that Sorenson Squeeze uses the MainConcept codec, which has been the highest quality commercially available codec in my comparison tests. 为了补充这些测试, I also produced comparison files with the x264 codec, using the QuickTime-based x264Encoder version 1.2.13 (dated 6/27/2010) set to the highest quality, slowest encode preset (图3).