使ったサンプルが特殊でグラフは出せなくて申し訳ないのですが、WebM(VP8)のPSNRを計測したので雑感だけ書きます。計測手順は以下です。

まず、WebMのFTPサイトからvpx-vp8-debug-src-x86-win32mt-vs8-v0.9.0.zip libvpx 0.9.0 visual studio buildをダウンロードしてきて、コマンドラインエンコーダ&デコーダであるivfenc.exeとivfdec.exeを入手します。これらの入出力フォーマットはJMと同じRAW YUV形式です。計測に使ったサンプルは連番BMPなので、これをまず、imagemagickでyuv形式に変換します。例えばconvert 0000.bmp 0000.yuv。これをフレーム数分だけ実行して、出来上がったyuvファイルを全て単純に結合します。こうしてできたin.yuvをivfencに入力します。

コマンドラインオプションとしては、画像サイズと、クオリティを入力する必要があります。クオリティには--target-bitrateが使えますが、ビットレート制御を行うとPSNRが落ちて不公平な評価になってしまうので、--target-bitrate=1000000000と大きくしておいて、--max-q=10 --min-q=10のように固定qになるように制約します。qの範囲は[0,63]ですね。こうすると、ビットレート制御ではなくクオリティ制御になりますので、VBRになって性能が高くなります。

ivfenc --width=320 --height=240 --target-bitrate=1000000000 --max-q=10 --min-q=10 in.yuv out.webm

ということで、qを変えながらグラフを取っていくことになります。デコードは

ivfdec out.webm out.yuv

としてデコードした後、

convert -width 320 -height 240 out.yuv out.bmp

でフレーム単位で切り出して連番BMPに落とし、元の画像とのPSNRを計測します。

比較対象は、x.264とJM。x.264はHighProfile+ExhibitSearch+CABAC、JMもできるだけ最大オプションでエンコードしています。入力素材はVGAとQVGAサンプルです。

ということで結果なのですが、圧縮性能はほぼx264と同じか少し下ぐらいでした。エンコード速度はx264よりもそれなりに遅いかなという感じです。エンコードがとてつもなく遅い代わりに圧縮率が最高になるH.264のリファレンスモデル、JMに比べると少し低く出る感じですね。WebMがH.264から大分簡略化されていることを考えると、もっと低く出るかと思っていたんですが、想像以上によい結果でした。

ちなみにエントロピー符号化はバイナリ算術を使っているようです。昨日の記事で、DCT4x8を使っていると書いてしまいましたが、コードを見てみるとDCT4x8の関数の中でDCT4x4を二回呼び出していたので、そこは別に新しくは無かったようです。本当に、H.264の使える所だけを残した感じですね。高画質領域ではブロックサイズが小さくても問題なくて、高圧縮領域では重めのDCTやループフィルタでがんばっていると。

ということで、十分にH.264のHighProfileと競合するCODECな予感がします。Appleさんとしてもこれだけオープンであれば特に拒否する理由も無い気がするので、パテント問題さえ解決すれば一気に普及しそうですね。家電はH.264、インターネット&モバイルはWebMというのがありえそうな未来図です。ただ、ほとんど264なのでパテント問題は重そうです。

ちなみに、x264の中の人のまとめが早くて詳しすぎます。必読。description of VP8 would be “H.264 Baseline Profile with a better entropy coder”. というのは言い得て妙だな
と思いました。