AMVビデオコーデックのこと

2009年の時は他のコーデックの処理速度と比べて1.5倍から2倍早かったAMVビデオコーデックですが、2012年の結果ではその差がさらに3倍から4倍へと開いたのが意外でした。と同時にバランスを見直す時期に来たのかなと感じます。

注目したいのがAMV2MT:Y4（非可逆）です。Y4では二次圧縮をするのでその分処理は遅くなりますが、それでも今回の結果では他のコーデックより早く処理できています。
開発当初は二次圧縮までやるとHuffyuvより遅くなるためY4以外へは適用しませんでしたが、現状ならY2やY3へ二次圧縮を適用し圧縮効果を高める価値はあるのかなと思います。
また、フレーム間圧縮とフレーム内圧縮のどちらで処理するかを現在はフレーム単位で決めていますが、Ver2.11aまでは画素単位（処理ブロック単位）で有利な方を使うようになっていました。これも処理量が増えHuffyuvと同程度の処理速度になってしまうため改善した部分ですが、今なら画素単位で処理しても他のコーデックより早く処理できます。画面の上半分は動きがなくて、下半分は激しく動くような映像の場合、現在のAMVビデオコーデックでは全体をフレーム内圧縮で処理してしまいますが、画素単位で処理すると、動きの無い上半分をフレーム間圧縮、動きの激しい下半分をフレーム内圧縮にできることから圧縮効果の向上につながるのでありかなと思います。
（フレーム間圧縮は動きの少ないシーンで有利。フレーム内圧縮は動きの激しいシーンで有利な圧縮方法です。）

そしてAVX(Intel Advanced Vector eXtensions)
現在のAMVビデオコーデックはSSE2命令を使いSSEレジスタ(128bit)で殆どの処理を行っています。これが他のコーデックより早く処理できる最大の要因となっていますが、去年リリースされたSandy BridgeからAVX(Intel Advanced Vector eXtensions)と言う拡張命令が追加されました。
（私が思う）その一番の特徴はレジスタが256bitになっていることです。SSEレジスタと比べ一度に倍のデータを処理できるようになりますので、AMVビデオコーデック的にはさらに高速化することが可能となります。
ただし、Sandy Bridgeや今回購入したIvy Bridgeではまだ実数ユニットのみの実装にとどまっており、整数ユニットが実装されるのは来年(2013年)リリース予定のHaswellからとの事ですので本格始動するにはまだまだ時間がかかりそうですね。