ビデオコーデック・ベンチマーク2014夏
世界中のビデオコーデックが登録されているcodecs.comから可逆圧縮コーデックをピックアップし、ベンチマークテストを行いました。
今回はほとんどのコーデックに更新が無いため特筆すべき点がAMV4ビデオコーデック以外ありません。テストは公平に行いますが、記事はAMV4ビデオコーデック中心となることをご了承ください。
おそらく集約命令（Gather命令）が実用化されることで他のコーデックの性能も上がってくると思うので、それまではこんな状態が続くと思います。
１．テスト内容と条件
ベンチマークはHD（1280*720）のビデオキャプチャおよびPC画面のキャプチャを想定しています。
適当なサンプル動画（未圧縮YUY2および未圧縮RGB32）を用意して、Ut Videoの作者である梅澤さんが公開しているVC Testを使って処理速度と、圧縮効果を測定します。
今回はほとんどのコーデックに更新が無いため特筆すべき点がAMV4ビデオコーデック以外ありません。テストは公平に行いますが、記事はAMV4ビデオコーデック中心となることをご了承ください。
おそらく集約命令（Gather命令）が実用化されることで他のコーデックの性能も上がってくると思うので、それまではこんな状態が続くと思います。
１．テスト内容と条件
ベンチマークはHD（1280*720）のビデオキャプチャおよびPC画面のキャプチャを想定しています。
適当なサンプル動画（未圧縮YUY2および未圧縮RGB32）を用意して、Ut Videoの作者である梅澤さんが公開しているVC Testを使って処理速度と、圧縮効果を測定します。
１．１．テスト内容
次のPCを使い、3つのサンプル動画それぞれのテストと、マルチスレッドによる処理速度のテストを行います。
１．２．PCスペック
| OS | Windows8.1 x64 Professional |
| CPU | Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz Haswell |
| MB | ASRock H87 Performance (Intel H87) |
| Memory | DDR3 1600 16GB(8GBx2 Dual Cannel)read=25.4GB/s write=14.8GB/s |
| Software | Video Codec Test 2.0.0 |
| 備考 | CPUは4コア、8スレッド、HTT対応、AVX2対応。動作クロックを3.4GHz（定格）で固定し、省電力設定およびTurbo BoostはBIOSで無効化、動作クロックがテスト中に変動しないようにしています。 |
※ メモリーのread,writeはCrystalMark 0.9.114によるものです。
１．３．サンプル動画
| タイトル | Mystery of the Nile |
| 情報 | 1280*720、2082frames、1分26秒、3,837,598,360Byte  |
| 備考 | AviUtlを使ってYUY2未圧縮に変換。 動きが激しくて、画質も悪いため圧縮しにくい不利な条件のそろった動画によるテスト。 いつものベンチマークで使っている動画と同じものです。 |
| タイトル | The LEGOR Movie - Official Main Trailer [HD] |
| 情報 | 1280*720、4321frames、3分00秒、7,964,559,144Byte  |
| 備考 | youtubeから720p版をダウンロードしてAviUtlでYUY2未圧縮に変換 動きが少なく、画質もいいため圧縮しやすい有利な条件のテスト。 また、上下に黒帯が付いているので、黒帯部分で高い圧縮効果が得られるコーデックに有利となります。 |
| タイトル | Street Fighter IV |
| 情報 | 1280*720、15820frames、4分23秒、58,319,119,660Byte  |
| 備考 | ゲームのベンチマークソフトを1280x720、60fpsに設定して実行。 アマレコTVのウインドウキャプチャを使ってAMV2MT:R2の可逆圧縮で録画。 Virtual Dubを使ってRGB32未圧縮に変換。 PC画面を録画することを想定したRGB可逆圧縮のテストです。 参考動画 |
１．４．コーデック
| コーデック名 | bit | 内容 | 設定 |
| AMV2MT Video Codec Ver 2.20i | 32 | YUY2のテストでは「Y2標準可逆」を使用 RGB32のテストでは「R2標準可逆」を使用 ライセンス登録済（ロゴなし） |  |
| NEW AMV4 Video Codec Ver 4.00 | 64 | AVX2版を使用 ライセンス登録済（ロゴなし） YUY2のテストでは「DY2：標準可逆（速度）」 及び「DY3：高圧縮可逆（圧縮）」を使用 RGB32のテストでは「DR2：標準可逆（速度）」 及び「DR3：高圧縮可逆（圧縮）」を使用 |  |
| Huffyuv Ver 2.1.1 | 32 | Predict median(best) RGB32のテストではアルファチャネルが含まれます。 |  |
| NEW UT Video Codec Suite Ver14.2.0 | 64 | 「圧縮率優先」および 「デコード速度優先」の2パターンをテスト YUY2のテストでは「ULY2」を使用 RGB32のテストでは「ULRG」を使用 |  |
| Lagarith Lossless Video Codec Ver 1.3.27 | 64 | YUY2のテストでは「YUY2」を使用 RGB32のテストでは「RGB」を使用 |  |
| Alparysoft Lossless Video Ver 2.0 | 32 | lossless compression enable prediction realtime ロゴあり |  |
| CorePNG Ver 0.8.2 | 32 | 1-Fastest |  |
| NEW MLC Codec Ver 1.2 | 64 | Muximum speed Use Multithreading off |  |
| FastCodec Ver 1.0beta | 32 | Absolutely lossless |  |
| MSU Lossless Video Capture Ver 0.6.0 | 32 | Absolutely lossless Maximize speed RGB32には対応していない |  |
※ bitはvctest-x86でテストしたものを「32」、vctest-x64でテストしたものを「64」としています。 両方用意されているコーデックでは64bit版を優先してテストします。
※ 規定の手順でWindows8にインストールできないコーデックを除外しました（Huffyuvだけは手動でインストールしてテストしています）。
２．結果
２．１．動きの激しい比較的低画質な実写映像 
※ fpsは1秒間に何フレーム処理できるかを示し、数値が高いほど優れています。
※ compression ratio（圧縮効果）は未圧縮のデータに対し何分の1に圧縮できるかを示し。数値が大きいほど優れています。
圧縮効果の面でMLCが4.3と非常に優れています。
AMVビデオコーデックにとってはあからさまに不利な条件でのテストなので、圧縮効果の面で最下位。
処理は速いけど圧縮効果が低いコーデックと言った位置づけになります。
一方、AMV4のDY3は不利な条件でもそこそこの圧縮効果を発揮しています。
また、AMV4のデコード処理は大幅に高速化されていて、AMV2MT：Y2の527fpsに対しAMV4：DY2（AVX版）のデコード速度は1802fps（3.4倍）です。
そのほかでは、UT Video速度優先のエンコード処理がHuffyuvに肉薄しています。この部分は過去のベンチマークをみると徐々に差を詰めてきています。
２．２．動きの少ない高画質なCG映像 
処理速度を見ると、大半のコーデックにおいてサンプル動画１のテストよりエンコード処理が早くなっている事が解ります。
多くのコーデックにおいて圧縮し易い映像では処理が早くなる傾向があるようです。
それに対しAMVビデオコーデックはサンプル１とサンプル２を比較してもエンコード処理の差はわずかとなっています。
AMVのエンコードには条件分岐処理が存在しないため映像の内容による処理時間の変動が起きにくい特徴があります。
次に圧縮効果の面をみると、MSUが18.1と突出しています。
そのほかは圧縮効果が5.0前後の集団と、10.0前後の集団（MLC、Lagarith、AMV4DY3）の2つに分かれます。
5.0前後の集団は映像の内容によらず5.0辺りから圧縮効果が伸び悩み、好条件であってもなかなか高い圧縮効果が得られません。
一方、10.0前後の集団は映像の内容によってはもっと高い圧縮効果が狙えます。
AMV4のDY3は二次圧縮を適用したことで、動きが少なかったり、単調な画像（グラデーションやべた塗りなど）、黒帯があるなどの条件において高い圧縮効果が狙えます。
| | AMV2MT Y2 | AMV4 DY2 | AMV4 DY3 | 備考 |
| Mystery of the Nile | 2.09 | 2.52 | 3.09 | WMV |
| The Discoverers (IMAX) 720p | 4.13 | 4.16 | 4.95 | WMV |
| The Book Thief Trailer | 4.32 | 4.95 | 7.37 | H264 |
| RoboCop TRAILER 1 | 4.17 | 4.92 | 7.54 | H264 |
| The LEGOR Movie | 5.35 | 5.93 | 9.44 | H264 黒帯あり |
| Transformers 4 | 5.38 | 6.32 | 10.33 | H264 黒帯あり |
| Veronica Mars | 7.09 | 7.72 | 13.66 | H264 黒帯あり |
２．３．ノイズが一切ないゲーム画面のキャプチャ 
Huffyuvはアルファチャネルも処理しているため不利な結果となっています。
MSUはRGB24でないと使えないようです。
２．４．マルチスレッドによるテスト
最後に各コーデックをマルチスレッドに設定した場合の処理速度を観察します。
AMV4はSSE4.1版とAVX2.0版をテストしています。
カッコ内の数値はスレッド数（フレーム分割数）で、1となっているのはシングルスレッドで処理しています。
mは「マルチスレッドを使う」と言う項目が用意されているだけでスレッド数が不明のコーデックです。
テストにはサンプル動画1を使います。 
Lagarithはマルチスレッドオプションを有効にすることで1.5倍程度fpsが向上しています。
MLCはマルチスレッドを有効にすることで約2倍fpsが向上。シングルスレッドでは720p 60fpsの録画は処理が間に合わず無理ですがマルチスレッドに設定することで可能性が出てきます。
UT Videoは分割数を増やす毎にfpsが上がっていくのがわかります。
4コア8スレッドのCPUによるテストなので、4分割あたりで頭打ちされるかと思いましたが、ハイパースレッドテクノロジーも有効に働くようです。
fpsが最も高くなるのはAMV2MTを8スレッドに設定した場合で2000fpsを超えます。
AMV4のAVX2版はSSE4版に対しエンコードで約1.4倍、デコードで約1.8倍の性能。128bitのSSEレジスタから256bitのAVXレジスタへ対応した効果が得られています。
AMV4は動画エンコード支援機能QSVを凌ぐ超低負荷
Intel製CPUに搭載されている動画エンコード支援機能Intel Quick Sync Video（以下QSV）はエンコード処理のほとんどを専用のハードウエアで処理するため、録画中のCPU使用率を大幅に軽減することができます。
一方、AMV4ビデオコーデックも極まった処理速度によりCPUの負荷を大幅に軽減できますので、どちらがよりCPU負荷が低いのか実際に録画中の様子を観察して比較してみました。
また、QSVと同様にCPU負荷を軽減できるNVIDIAのNVEncについてもテストしています。
１．テスト概要
できるだけ同じ条件で観察したいので一つのキャプチャソフトでQSVとAMV4の両方が使えるものを探しましたが、見つかりませんでした。
なので、QSVに関してはOBS（Open Broadcaster Software）とキャプチャカードに付属するVideoKeeper2を使い、AMV4はアマレコTVを使うことにします。画像サイズやフレームレートを揃え、ドロップフレームが生じない条件でテストしましたが、やはりキャプチャソフトによる違いが無いとは言い切れないためその点はご容赦ください。
１．１．テスト方法
各キャプチャソフト（配信ソフト）にて録画を行い、その時のタスクマネージャのグラフ（CPU使用率）を観察します。
ビデオキャプチャにはマイコンソフト社のSC-512N1-L/DVIを使いPS4版のBATTLE FIELD 4のキャンペーンモードのオープニングシーン（※）を録画します。
※ この動画の冒頭1分50秒と同じ内容
下図はOBSを使ってソフトウエア・エンコーダのx264にてローカル録画した時のグラフになります。
キャプチャ条件はHDMI 1920x1080 60p YUY2です。
グラフの下部にある5枚の画像はキャプチャ中のおおよその映像を示しています。グラフのこの地点ではこんな感じの映像を処理していると思ってください。
グラフの左端はプレビューも、録画も行っていないため、ほぼCPU使用率が0％となっています。
そこから録画を開始し画像1の付近では、真っ黒な画面に小さい文字でゲーム制作会社などのテロップが表示されるシーンとなります。
このシーンは単調（1枚の画像として見たとき複雑でない、べた塗りやグラデーションの面積が広いなど）かつ動きが全く無い映像なためかCPU使用率は20％強と低めです。
グラフの中盤（画像2、3付近）は普通に動きのあるシーンとなり、CPU使用率は約55％と跳ね上がります。
グラフの後半（画像4、5付近）はオープニングが終わり、プレイ中となりますが、操作を行っていないためほとんど動きのない映像が続きます。動きがほとんどない映像ではCPU使用率も30％強と低めになるようです。
このようなテストを、エンコーダを変えて行います。
２．テスト条件
３．各キャプチャソフトの主な設定
詳細設定は長くなるので「続きを読む」に記載します。ここでは特に重要と思われる内容のみ記載します。
３．１．OBS
QSVおよびNVEncにてローカル録画するように設定します。
ビットレートは8Mbpsとしました。
サウンドはアマレコTVとできるだけ同じ条件となるようMP3 128kbps 2chとしています。
デスクトップの音とキャプチャカードの音がミキシングされます。
３．２．VideoKeeper2
QSVを使って録画するように設定します。
ビットレートは20Mbps。
オーディオミキサーの処理はありません。
３．３．アマレコTV
AMV4ビデオコーデックをDY3（YUY2高圧縮可逆）に設定しSSE4版とAVX2版のそれぞれで録画します。
ビットレートの設定はありませんが出来上がった動画ファイルから逆算すると約320Mbpsとなります(今回のテスト条件では秒間約40MByteなのでHDD単体でもドロップなく録画可能)。
オーディオ圧縮にLAME MP3 128kbpsを使います。
オーディオミキサーの処理はありません。
４．テスト結果
各エンコーダで録画した際のタスクマネージャのグラフに色を付けて合成したのが下図になります。
グラフの前半部は録画していない状態（プレビュー処理のみ）のCPU使用率です。OBSの前半は停止状態（プレビューもしていない）です。
プレビュー中はPCを操作しているためグラフが少し乱れていますが、アマレコTV、VideoKeeper2ともにCPU使用率は約4％から5％です。
グラフの後半は録画中のCPU使用率となります。録画中はPCを一切操作していないためグラフが安定しています。
また、いずれのエンコーダも映像の内容によるCPU使用率の変動がほとんど生じていないこともわかります。
録画中のCPU使用率は全体的に6％から10％の間にひしめき合っていて僅差となりますが、最もCPU使用率を抑えられたのはアマレコTVとAMV4（AVX2版）の組み合わせとなりました。
二番手はVideoKeeper2のQSVとなります。同じQSVを使ったOBSよりCPU使用率が少ないことがわかります。
AMV4のSSE4版は処理が遅い分CPU使用率も少し高くなります。
OBSは他と比べるとCPU負荷が若干高めという結果になりました。純粋な録画とプレビュー処理のほかに、何かしら処理を行っていると推測されます（少なくともオーディオミキサーの処理が行われています）。
また、OBSのQSVとNVEncを比較するとNVEncの方がCPU負荷を抑えられています。
最後に録画したビデオファイルの画質を比較します。
下図は録画したビデオファイルをAviUtlで読み込んだ画像です。
ゲーム側の都合によりプレイする度に完全に同じ映像がレンダリングされるわけではないようなので、類似するフレームを抜き出しての比較となります。
AMV4はYUY2の可逆なのでオリジナルの画質に忠実です。
VideoKeeper2はビットレートが高い分、OBSより若干画質はよくなっています。
OBSの3つはこの例ではほとんど差が無いように感じますが、一般的にはx264、QSV、NVEncの順に画質が良いと言われています。
OBSの3つの色味が他と違っていますが原因は不明です。OBS側の設定で何かあるのか、AviUtlでmp4ファイルを読み込む際の入力プラグインの都合なのか・・・
一方、AMV4ビデオコーデックも極まった処理速度によりCPUの負荷を大幅に軽減できますので、どちらがよりCPU負荷が低いのか実際に録画中の様子を観察して比較してみました。
また、QSVと同様にCPU負荷を軽減できるNVIDIAのNVEncについてもテストしています。
１．テスト概要
できるだけ同じ条件で観察したいので一つのキャプチャソフトでQSVとAMV4の両方が使えるものを探しましたが、見つかりませんでした。
なので、QSVに関してはOBS（Open Broadcaster Software）とキャプチャカードに付属するVideoKeeper2を使い、AMV4はアマレコTVを使うことにします。画像サイズやフレームレートを揃え、ドロップフレームが生じない条件でテストしましたが、やはりキャプチャソフトによる違いが無いとは言い切れないためその点はご容赦ください。
１．１．テスト方法
各キャプチャソフト（配信ソフト）にて録画を行い、その時のタスクマネージャのグラフ（CPU使用率）を観察します。
ビデオキャプチャにはマイコンソフト社のSC-512N1-L/DVIを使いPS4版のBATTLE FIELD 4のキャンペーンモードのオープニングシーン（※）を録画します。
※ この動画の冒頭1分50秒と同じ内容
下図はOBSを使ってソフトウエア・エンコーダのx264にてローカル録画した時のグラフになります。
キャプチャ条件はHDMI 1920x1080 60p YUY2です。
グラフの下部にある5枚の画像はキャプチャ中のおおよその映像を示しています。グラフのこの地点ではこんな感じの映像を処理していると思ってください。
グラフの左端はプレビューも、録画も行っていないため、ほぼCPU使用率が0％となっています。
そこから録画を開始し画像1の付近では、真っ黒な画面に小さい文字でゲーム制作会社などのテロップが表示されるシーンとなります。
このシーンは単調（1枚の画像として見たとき複雑でない、べた塗りやグラデーションの面積が広いなど）かつ動きが全く無い映像なためかCPU使用率は20％強と低めです。
グラフの中盤（画像2、3付近）は普通に動きのあるシーンとなり、CPU使用率は約55％と跳ね上がります。
グラフの後半（画像4、5付近）はオープニングが終わり、プレイ中となりますが、操作を行っていないためほとんど動きのない映像が続きます。動きがほとんどない映像ではCPU使用率も30％強と低めになるようです。
このようなテストを、エンコーダを変えて行います。
２．テスト条件
| OS | Windows8 x64 Professional | |
| CPU | Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz Haswell | |
| GPU | GeForce GTX 650 Driver 337.88 | |
| MB | ASRock H87 Performance (Intel H87) | |
| Memory | DDR3 1600 16GB(8GBx2 Dual Channel)read=25.4GB/s write=14.8GB/s | |
| HDD | 録画用のHDD WD30EZRX 3TB | |
| Software | OBS Ver0.624b 32bit版 Video keeper2 ver1.1.0.124.4 （SC512のキャプチャソフト） AmaRecTV Ver3.00e (Ver3.00cと同じ) | |
| Capture Card | ||
| SC-512N1-L/DVI DVI-D Driver:1.1.0.125.0, 2013.11.12 | ||
| Video Souｒce | PS4版BATTLE FIELD 4のオープニングシーンを HDMI 1080 60p YUY2でキャプチャ この動画の冒頭1分50秒と同じ内容 | |
| 備考 | CPUは4コア、8スレッド、HTT対応、AVX2対応。動作クロックを3.4GHz（定格）で固定し、 省電力設定およびTurbo BoostはBIOSで無効化、動作クロックがテスト中に変動しないようにしています。 | |
３．各キャプチャソフトの主な設定
詳細設定は長くなるので「続きを読む」に記載します。ここでは特に重要と思われる内容のみ記載します。
３．１．OBS
QSVおよびNVEncにてローカル録画するように設定します。
ビットレートは8Mbpsとしました。
サウンドはアマレコTVとできるだけ同じ条件となるようMP3 128kbps 2chとしています。
デスクトップの音とキャプチャカードの音がミキシングされます。
３．２．VideoKeeper2
QSVを使って録画するように設定します。
ビットレートは20Mbps。
オーディオミキサーの処理はありません。
３．３．アマレコTV
AMV4ビデオコーデックをDY3（YUY2高圧縮可逆）に設定しSSE4版とAVX2版のそれぞれで録画します。
ビットレートの設定はありませんが出来上がった動画ファイルから逆算すると約320Mbpsとなります(今回のテスト条件では秒間約40MByteなのでHDD単体でもドロップなく録画可能)。
オーディオ圧縮にLAME MP3 128kbpsを使います。
オーディオミキサーの処理はありません。
４．テスト結果
各エンコーダで録画した際のタスクマネージャのグラフに色を付けて合成したのが下図になります。
グラフの前半部は録画していない状態（プレビュー処理のみ）のCPU使用率です。OBSの前半は停止状態（プレビューもしていない）です。
プレビュー中はPCを操作しているためグラフが少し乱れていますが、アマレコTV、VideoKeeper2ともにCPU使用率は約4％から5％です。
グラフの後半は録画中のCPU使用率となります。録画中はPCを一切操作していないためグラフが安定しています。
また、いずれのエンコーダも映像の内容によるCPU使用率の変動がほとんど生じていないこともわかります。
録画中のCPU使用率は全体的に6％から10％の間にひしめき合っていて僅差となりますが、最もCPU使用率を抑えられたのはアマレコTVとAMV4（AVX2版）の組み合わせとなりました。
二番手はVideoKeeper2のQSVとなります。同じQSVを使ったOBSよりCPU使用率が少ないことがわかります。
AMV4のSSE4版は処理が遅い分CPU使用率も少し高くなります。
OBSは他と比べるとCPU負荷が若干高めという結果になりました。純粋な録画とプレビュー処理のほかに、何かしら処理を行っていると推測されます（少なくともオーディオミキサーの処理が行われています）。
また、OBSのQSVとNVEncを比較するとNVEncの方がCPU負荷を抑えられています。
最後に録画したビデオファイルの画質を比較します。
下図は録画したビデオファイルをAviUtlで読み込んだ画像です。
ゲーム側の都合によりプレイする度に完全に同じ映像がレンダリングされるわけではないようなので、類似するフレームを抜き出しての比較となります。
AMV4はYUY2の可逆なのでオリジナルの画質に忠実です。
VideoKeeper2はビットレートが高い分、OBSより若干画質はよくなっています。
OBSの3つはこの例ではほとんど差が無いように感じますが、一般的にはx264、QSV、NVEncの順に画質が良いと言われています。
OBSの3つの色味が他と違っていますが原因は不明です。OBS側の設定で何かあるのか、AviUtlでmp4ファイルを読み込む際の入力プラグインの都合なのか・・・
AMV4ビデオコーデック ベンチマーク暫定版 もはや反則AVX2編
AVX2に対応したCPU「Haswell」でAMV4ビデオコーデックのAVX2版をテストします。
テスト条件は前回のSSE編と同じですのでパソコンのスペック以外は以前の記事を参照してください。
AMV4ビデオコーデック ベンチマーク暫定版 SSE編
なお、AMV4ビデオコーデックについては開発途中のバージョンによるテストですので、
最終的なバージョンと異なる場合があります。
完成後にもう一度ベンチマークをやり直し結果を掲載しますのでそちらも確認してください。
【ベンチマーク条件】
パソコンのスペック以外はSSE編と同じ
AMV4ビデオコーデック ベンチマーク暫定版 SSE編
【ベンチマーク結果】
テスト条件は前回のSSE編と同じですのでパソコンのスペック以外は以前の記事を参照してください。
AMV4ビデオコーデック ベンチマーク暫定版 SSE編
なお、AMV4ビデオコーデックについては開発途中のバージョンによるテストですので、
最終的なバージョンと異なる場合があります。
完成後にもう一度ベンチマークをやり直し結果を掲載しますのでそちらも確認してください。
【ベンチマーク条件】
パソコンのスペック以外はSSE編と同じ
AMV4ビデオコーデック ベンチマーク暫定版 SSE編
| OS | Windows8 x64 Professional |
| CPU | Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz Haswell |
| MB | ASRock H87 Performance (Intel H87) |
| Memory | DDR3 1600 16GB(8GBx2 Dual Cannel)read=25.4GB/s write=14.8GB/s |
| Software | Video Codec Test 2.0.0 |
| 備考 | CPUは4コア、8スレッド、HTT対応、AVX2対応。動作クロックを3.4GHz（定格）で固定し、 省電力設定およびTurbo BoostはBIOSで無効化、動作クロックがテスト中に変動しないようにしています。 |
【ベンチマーク結果】
| レベル | エンコード | デコード | 圧縮効果 | 備考 | |||
| 時間 | FPS | 時間 | FPS | ||||
| AMV2MT 32bit SSE2 | Y1 | 0.60 ms | 1648 fps | 0.80 ms | 1238 fps | 1.15 | YUY2可逆 |
| Y2 | 1.24 ms | 801 fps | 1.90 ms | 523 fps | 2.09 | YUY2可逆 | |
| Y3 | 1.81 ms | 551 fps | 2.64 ms | 377 fps | 2.78 | YUY2非可逆 | |
| Y4 | 3.73 ms | 267 fps | 4.37 ms | 228 fps | 3.67 | YUY2非可逆 二次圧縮あり | |
| レベル | エンコード | デコード | 圧縮効果 | 備考 | |||
| 時間 | FPS | 時間 | FPS | ||||
AMV4 32bit SSE4.1 | DY2 | 1.09 ms | 910 fps | 1.17 ms | 850 fps | 2.52 | YUY2可逆 |
| DY3 | 1.84 ms | 541 fps | 1.84 ms | 542 fps | 3.09 | YUY2可逆 二次圧縮あり | |
| AMV4 64bit SSE4.1 | DY2 | 1.11 ms | 900 fps | 1.08 ms | 925 fps | 2.52 | YUY2可逆 |
| DY3 | 1.78 ms | 558 fps | 1.66 ms | 601 fps | 3.09 | YUY2可逆 二次圧縮あり | |
| レベル | エンコード | デコード | 圧縮効果 | 備考 | |||
| 時間 | FPS | 時間 | FPS | ||||
AMV4 32bit AVX2 | DY2 | 0.84 ms | 1189 fps | 0.64 ms | 1557 fps | 2.52 | YUY2可逆 |
| DY3 | 1.21 ms | 825 fps | 1.17 ms | 854 fps | 3.09 | YUY2可逆 二次圧縮あり | |
| AMV4 64bit AVX2 | DY2 | 0.72 ms | 1386 fps | 0.55 ms | 1790 fps | 2.52 | YUY2可逆 |
| DY3 | 1.07 ms | 931 fps | 0.97 ms | 1029 fps | 3.09 | YUY2可逆 二次圧縮あり | |
※ 時間、FPS：1フレーム処理するのにかかった時間、FPSは1秒間に何フレーム処理できるかを示しています。この2つは同じ情報です。FPSの数値が大きいほど優れています。
※ 圧縮効果：未圧縮に対しデータ（ファイルサイズ）を何分の1に圧縮できるかを示しています。数値が大きいほど優れています。
例 圧縮効果が2.00の場合、未圧縮で録画した場合と比べファイルサイズを半分（2分の1）に減らす能力があります。
処理速度と圧縮効果について
圧縮効果についてはSSE版とAVX2版とで同じ結果となりますので前回のSSE編を参照してください。
処理速度についてはAMV2MTとAMV4 64bit AVX2版を比較します。
Y2とDY2を比較するとDY2の方がエンコード処理で約73％、デコード処理で約242％（3.4倍）性能が向上しています。
Y3とDY3を比較するとエンコード処理で約68％、デコード処理で172％（2.7倍）の性能向上となっています。
なお、AVX2 32bit SSE版のDY3のエンコードがY3より1％程度遅い結果となっています。前回のIvy BridgeでのテストではDY3の方が約8％速い結果となっているので、Y3とDY3のSSE版はCPUの違いにより優劣が入れ替わるくらいの僅差と言えます。
まとめ
以前公開したAMV2MTデコーダーのAVX2対応デモ版で3倍速いというのを示しましたが、
「3倍高速 AVX2対応 AMVデコーダー デモ版」
「AVX2対応 AMVデコーダー デモ版の追試」
AMV4はさらにその上を行く3.4倍の性能（デコード処理）に達します。これはデモ版の時はAMV2の仕様に合わせてコーディングする必要があった（AMV2の仕様は2008年にSSEを前提に作成したのでAVX2には向かない部分が含まれる）のに対し、AMV4ではAVX2の特性に合わせ仕様の作成段階から取り組んだためです。
その結果、仕様とコーディングの両面でAVX2の性能を 相当高いレベルまで引き出せたと思います。
AMV4のAVX2版を簡単にまとめると
(1) エンコード処理の処理速度が約70％程度向上する
(2) デコード処理の処理速度が200％程度向上する
(3) 可逆圧縮の圧縮効果がDY2で最大約20％、DY3で平均約50％向上する
(4) AVX2が使えるPCでは処理速度と圧縮効果の両面で大幅に性能が向上する
※ 記事の内容は開発中のものです。公開時の仕様と異なる場合があります。
最終的な仕様については、公開時の記事を見てください。
AMV4ビデオコーデック 内部仕様でみるAMV4とAMV2MTの違い
AMV4とAMV2MTの違いを内部仕様で比較しながら、AMV4ビデオコーデックがどんなコーデックになるか紹介します。
黄色は変更箇所
【圧縮パターン】
「どのように圧縮するか」といった圧縮パターンの数。
パターン数が多いほど好条件で圧縮できる可能性があがるため高い圧縮効果が得られます。
【参照箇所】
基本的には左に位置する画素、または1フレーム前の同じ位置の画素のどちらか一方を参照して処理します。
DY3ではキーフレームの場合、左と上の二箇所、差分フレームの場合は左と1フレーム前の同じ位置の二箇所を参照して処理します。
参照箇所が多いほど好条件を選択できるため高い圧縮効果が得られます。
【参照距離】
フレーム内の画素を参照する際の距離（何画素離れたデータを参照するか）です。
近いデータを参照するほどデータの相関関係が強まるため圧縮効果が高くなります。
Y2,Y3では最大で8画素離れたデータを参照します。遠いデータを参照してしまうため圧縮効果は低めになります。
DY2,DY3は常に隣の画素を参照するため、参照距離は常に1となり、高い圧縮効果が得られます。
【二次圧縮】
一度圧縮したデータを再度圧縮します。主に動きの少ない部分や単調なデータの圧縮効果が非常に高くなります。
処理がとても遅くなるためAMV2MTでは処理速度より圧縮効果を優先するY4高圧縮にのみ適用していましたが、AMV4では大幅に処理速度が向上するためDY3に適用しました。
【画質】
AMV4ではDY3も可逆になります。
【マルチスレッド】
CPUリソースを複数使うことで処理時間を短くします。その代りCPUへの負荷は増えます。
AMV2MTはマルチスレッドで処理することができましたが、マルチスレッドで処理するメリットはありませんでした。
AMV4はさらに処理速度が向上するためシングルスレッドでも十分リアルタイム処理が可能となります。そのためマルチスレッドでの処理を廃止します。
【拡張命令】
AMV2MTはSSE2までの拡張命令を使って処理します。
AMV4はSSE版とAVX2版があり、SSE版はSSE4.1までの拡張命令を使って処理します。
AVX2版はAVX2までの拡張命令を使って処理します。
内部仕様で比較するとDY2とY2は参照距離が違うだけですが、参照距離が短くなるだけでも10％から20％ほど圧縮効果が向上します。
一方、DY3はY3と比べ大幅に処理が増えます。
(1) 圧縮パターンの増加
(2) 参照箇所の増加
(3) より近いデータを参照する （これも同じレジスタ内のデータを参照するため処理が増えます）
(4) 二次圧縮の適用
これらの効果によりDY3は非可逆圧縮のY3より高い圧縮効果が得られます。
これだけ処理が増えると、処理に時間がかかりパフォーマンスが低下するところですが、SSE版のDY3でもY3とほぼ同じかほんの少し早く処理することができます。
そして、AVX2版のDY3はY2よりも早く処理でき、非常に高いパフォーマンスを発揮します。
YUY2に関しては一通り動作するところまできました、仕様もほぼ固まりましたので、次回は（まだ開発途中ですが）簡単なベンチマークテストを行いおおよその処理速度、圧縮効果を紹介します。
※ 記事の内容は開発中のものです。公開時の仕様と異なる場合があります。
最終的な仕様については、公開時の記事を見てください。
| AMV2MT | AMV4 | |||
| Y2標準可逆 | Y3標準 | DY2標準可逆 | DY3高圧縮可逆 | |
| 圧縮パターン | 4 | 6 | 4 | 8 |
| 参照箇所 | 1 | 1 | 1 | 2 |
| 参照距離 | 遠い | 遠い | 近い | 近い |
| 二次圧縮 | 無し | 無し | 無し | 有り |
| 画質 | 可逆 | 非可逆 | 可逆 | 可逆 |
| マルチスレッド | 最大8 | 最大8 | 非対応1 | 非対応1 |
| 拡張命令 | SSE2 | SSE2 | SSE4.1 AVX2.0 | SSE4.1 AVX2.0 |
| AMV2MT | AMV4 | |||
| Y2標準可逆 | Y3標準 | DY2標準可逆 | DY3高圧縮可逆 | |
| 圧縮効果 | 低い | 高い | Y2より高い | Y3より高い |
| 処理速度SSE | 速い | 普通 | Y2より速い | Y3とほぼ同じ |
| 処理速度AVX2 | - | - | もっとも速い | Y2より速い |
【圧縮パターン】
「どのように圧縮するか」といった圧縮パターンの数。
パターン数が多いほど好条件で圧縮できる可能性があがるため高い圧縮効果が得られます。
【参照箇所】
基本的には左に位置する画素、または1フレーム前の同じ位置の画素のどちらか一方を参照して処理します。
DY3ではキーフレームの場合、左と上の二箇所、差分フレームの場合は左と1フレーム前の同じ位置の二箇所を参照して処理します。
参照箇所が多いほど好条件を選択できるため高い圧縮効果が得られます。
【参照距離】
フレーム内の画素を参照する際の距離（何画素離れたデータを参照するか）です。
近いデータを参照するほどデータの相関関係が強まるため圧縮効果が高くなります。
Y2,Y3では最大で8画素離れたデータを参照します。遠いデータを参照してしまうため圧縮効果は低めになります。
DY2,DY3は常に隣の画素を参照するため、参照距離は常に1となり、高い圧縮効果が得られます。
【二次圧縮】
一度圧縮したデータを再度圧縮します。主に動きの少ない部分や単調なデータの圧縮効果が非常に高くなります。
処理がとても遅くなるためAMV2MTでは処理速度より圧縮効果を優先するY4高圧縮にのみ適用していましたが、AMV4では大幅に処理速度が向上するためDY3に適用しました。
【画質】
AMV4ではDY3も可逆になります。
【マルチスレッド】
CPUリソースを複数使うことで処理時間を短くします。その代りCPUへの負荷は増えます。
AMV2MTはマルチスレッドで処理することができましたが、マルチスレッドで処理するメリットはありませんでした。
AMV4はさらに処理速度が向上するためシングルスレッドでも十分リアルタイム処理が可能となります。そのためマルチスレッドでの処理を廃止します。
【拡張命令】
AMV2MTはSSE2までの拡張命令を使って処理します。
AMV4はSSE版とAVX2版があり、SSE版はSSE4.1までの拡張命令を使って処理します。
AVX2版はAVX2までの拡張命令を使って処理します。
内部仕様で比較するとDY2とY2は参照距離が違うだけですが、参照距離が短くなるだけでも10％から20％ほど圧縮効果が向上します。
一方、DY3はY3と比べ大幅に処理が増えます。
(1) 圧縮パターンの増加
(2) 参照箇所の増加
(3) より近いデータを参照する （これも同じレジスタ内のデータを参照するため処理が増えます）
(4) 二次圧縮の適用
これらの効果によりDY3は非可逆圧縮のY3より高い圧縮効果が得られます。
これだけ処理が増えると、処理に時間がかかりパフォーマンスが低下するところですが、SSE版のDY3でもY3とほぼ同じかほんの少し早く処理することができます。
そして、AVX2版のDY3はY2よりも早く処理でき、非常に高いパフォーマンスを発揮します。
YUY2に関しては一通り動作するところまできました、仕様もほぼ固まりましたので、次回は（まだ開発途中ですが）簡単なベンチマークテストを行いおおよその処理速度、圧縮効果を紹介します。
※ 記事の内容は開発中のものです。公開時の仕様と異なる場合があります。
最終的な仕様については、公開時の記事を見てください。
AMV4ビデオコーデック 概要
AMV4ビデオコーデックの主な仕様はAMV2MTがベースとなっており、RGBとYUY2、UYVY、HDYCに対応します。
圧縮設定については非可逆圧縮を廃止し可逆圧縮のみとなります。
非可逆圧縮の廃止については、AMV2MTの「Y3:標準」の非可逆圧縮よりAMV4では可逆圧縮のまま高い圧縮効果が得られるようになるためです。同様にAMV3の圧縮フォーマットであるYV12もAMV4のYUY2の方が圧縮効果が高く画質も良いため、現状YV12についても非対応です。
AMV4の圧縮設定はYUY2の場合次の２つになります。
(1) DY2:標準可逆（Y2:標準可逆 相当）
(2) DY3:高圧縮可逆（Y3:標準 相当）
DY2はAMV2MTのY2とほぼ同じ内容になりますが少しだけ圧縮効果が向上します（DY2はY2よりファイルサイズを小さくできる）。
DY3は圧縮パターンの増加や二次圧縮の適用により非可逆圧縮のY3よりも高い圧縮効果が得られます。可逆圧縮なので画質もY3より良くなりますので「DY3はY3よりファイルサイズを小さくしつつ画質も良い」と言うことになります。
一方、処理速度はAMV4のSSE版はSSE4.1対応(SSE4.1必須)となり、AMV2MTとほぼ同じか若干速く処理できます（DY2とY2、DY3とY3を比べた場合、ほぼ同じか若干AMV4の方が速い）。
さらに、AMV4のAVX2版は大幅に処理速度が向上、AVX2版のDY3はY2より高速で動作します。
AMV4ビデオコーデックについて簡単にまとめると
(1) 可逆圧縮専用
(2) 圧縮効果が高まる（非可逆圧縮のY3より圧縮効果が高い「高圧縮可逆」を追加）
(3) SSE版はSSE4.1対応になりAMV2MTとほぼ同じか若干速く処理できる
(4) AVX2版は大幅に処理速度が向上する
※ 記事の内容は開発中のものです。公開時の仕様と異なる場合があります。
最終的な仕様については、公開時の記事を見てください。
圧縮設定については非可逆圧縮を廃止し可逆圧縮のみとなります。
非可逆圧縮の廃止については、AMV2MTの「Y3:標準」の非可逆圧縮よりAMV4では可逆圧縮のまま高い圧縮効果が得られるようになるためです。同様にAMV3の圧縮フォーマットであるYV12もAMV4のYUY2の方が圧縮効果が高く画質も良いため、現状YV12についても非対応です。
AMV4の圧縮設定はYUY2の場合次の２つになります。
(1) DY2:標準可逆（Y2:標準可逆 相当）
(2) DY3:高圧縮可逆（Y3:標準 相当）
DY2はAMV2MTのY2とほぼ同じ内容になりますが少しだけ圧縮効果が向上します（DY2はY2よりファイルサイズを小さくできる）。
DY3は圧縮パターンの増加や二次圧縮の適用により非可逆圧縮のY3よりも高い圧縮効果が得られます。可逆圧縮なので画質もY3より良くなりますので「DY3はY3よりファイルサイズを小さくしつつ画質も良い」と言うことになります。
一方、処理速度はAMV4のSSE版はSSE4.1対応(SSE4.1必須)となり、AMV2MTとほぼ同じか若干速く処理できます（DY2とY2、DY3とY3を比べた場合、ほぼ同じか若干AMV4の方が速い）。
さらに、AMV4のAVX2版は大幅に処理速度が向上、AVX2版のDY3はY2より高速で動作します。
AMV4ビデオコーデックについて簡単にまとめると
(1) 可逆圧縮専用
(2) 圧縮効果が高まる（非可逆圧縮のY3より圧縮効果が高い「高圧縮可逆」を追加）
(3) SSE版はSSE4.1対応になりAMV2MTとほぼ同じか若干速く処理できる
(4) AVX2版は大幅に処理速度が向上する
※ 記事の内容は開発中のものです。公開時の仕様と異なる場合があります。
最終的な仕様については、公開時の記事を見てください。
AVX2って何？ そしてAMV4ビデオコーデック
AVX2は2013年6月に発売されたインテルのCPU Haswellに搭載された拡張命令で、それまでSSE命令を使って128bitずつ処理していたものをAVX2では256bitずつ処理することができます。
単純に考えるとSSE命令中心で作成されたプログラムをAVX2へ移行することで2倍の処理能力（処理時間が半分で済む）
が期待できます。
AVX（AVX1？）については2011年1月に発売されたSandy Bridgeから搭載されていて実数演算が中心でしたが、今回のHaswellで搭載されたAVX2は整数演算が中心の拡張命令となっています。
また、SSE命令にはなかった命令もいくつか追加されていて、例えばデータ要素毎に異なるシフト値を指定できるシフト命令「VPSLLVQ」なんかは便利だと思いました。
AVX2ってどう？（良いの？）
AVX2自体の性能はとても優秀で、簡単なプログラムであれば、ほぼSSEの倍の性能を達成できるようです。
「3倍高速 AVX2対応 AMVデコーダー デモ版」
しかし、一般的なプログラムにおいてAVX2の性能を引き出そうと思うと、一筋縄ではいかないのかな。AVX2へ対応したプログラムと言うのは9か月経った今でも極めて少ないように思います。
また、Haswell自体の評価が低くいのも開発者からするとつらいところで、AVX2に対応したCPUの普及が進まないと、積極的にAVX2へ対応しづらいですよね。
AVX2に対応したプログラムが充実してくればHaswellに対する評価も上がってくると思いますが、しばらくは
「AVX2を生かせるプログラムが少ない」
↓
「AVX2を活かせないとHaswellの評価が低く普及しない」
↓
「開発者はAVX2へ対応しても利用できるユーザーが限られる（需要が少ない）」
と言った負の連鎖が続くのかなと思います。
そしてAMV4ビデオコーデックへ
1年半ほど前に「AVXによりパフォーマンスが向上するかも、パフォーマンスが向上したら圧縮効果を高める方向で調整できるかも」と言った内容の記事を書きました。
「AMVビデオコーデックのこと」
このときは期待とか予測でしたが、実際にテストしたAVX2の性能は私の期待以上のもので、その開発は趣味であればとても楽しく刺激的です。
現時点でAVX2へ対応しても、利用できるCPUを所有している人が極僅かなため需要は少ないと思いますが、デコード処理が3倍早くなるなどAVX2の性能の高さはとても魅力的ですので、AVX2へ完全対応した新しいビデオコーデック「AMV4 ビデオコーデック」を制作することにしました。
なお、AMVビデオコーデックはシェアウエアなので継続して利用される場合ライセンスを購入して頂くことになりますが、AMV2、AMV2MT、AMV3、AMV4でライセンスを共通としますので、すでにライセンスを購入された方、および、これから購入される場合も、AMV4のために追加で購入する必要はありません。
AMV4の公開まで、まだまだ時間がかかりますが、おいおい内容を書いていこうと思います。
単純に考えるとSSE命令中心で作成されたプログラムをAVX2へ移行することで2倍の処理能力（処理時間が半分で済む）
が期待できます。
AVX（AVX1？）については2011年1月に発売されたSandy Bridgeから搭載されていて実数演算が中心でしたが、今回のHaswellで搭載されたAVX2は整数演算が中心の拡張命令となっています。
また、SSE命令にはなかった命令もいくつか追加されていて、例えばデータ要素毎に異なるシフト値を指定できるシフト命令「VPSLLVQ」なんかは便利だと思いました。
AVX2ってどう？（良いの？）
AVX2自体の性能はとても優秀で、簡単なプログラムであれば、ほぼSSEの倍の性能を達成できるようです。
「3倍高速 AVX2対応 AMVデコーダー デモ版」
しかし、一般的なプログラムにおいてAVX2の性能を引き出そうと思うと、一筋縄ではいかないのかな。AVX2へ対応したプログラムと言うのは9か月経った今でも極めて少ないように思います。
また、Haswell自体の評価が低くいのも開発者からするとつらいところで、AVX2に対応したCPUの普及が進まないと、積極的にAVX2へ対応しづらいですよね。
AVX2に対応したプログラムが充実してくればHaswellに対する評価も上がってくると思いますが、しばらくは
「AVX2を生かせるプログラムが少ない」
↓
「AVX2を活かせないとHaswellの評価が低く普及しない」
↓
「開発者はAVX2へ対応しても利用できるユーザーが限られる（需要が少ない）」
と言った負の連鎖が続くのかなと思います。
そしてAMV4ビデオコーデックへ
1年半ほど前に「AVXによりパフォーマンスが向上するかも、パフォーマンスが向上したら圧縮効果を高める方向で調整できるかも」と言った内容の記事を書きました。
「AMVビデオコーデックのこと」
このときは期待とか予測でしたが、実際にテストしたAVX2の性能は私の期待以上のもので、その開発は趣味であればとても楽しく刺激的です。
現時点でAVX2へ対応しても、利用できるCPUを所有している人が極僅かなため需要は少ないと思いますが、デコード処理が3倍早くなるなどAVX2の性能の高さはとても魅力的ですので、AVX2へ完全対応した新しいビデオコーデック「AMV4 ビデオコーデック」を制作することにしました。
なお、AMVビデオコーデックはシェアウエアなので継続して利用される場合ライセンスを購入して頂くことになりますが、AMV2、AMV2MT、AMV3、AMV4でライセンスを共通としますので、すでにライセンスを購入された方、および、これから購入される場合も、AMV4のために追加で購入する必要はありません。
AMV4の公開まで、まだまだ時間がかかりますが、おいおい内容を書いていこうと思います。
AVX2対応デコーダーはなぜ3倍も高速化できたのか
端的に言えばAVX2を使っているからとなりますが、AVX2による性能向上は（理論上の）最大でも2倍までなのでもう一つの要因としてSIMD化があげられます。
AMV2MTのY2設定には4つの圧縮パターン（AからD）があり、最少処理単位（2x2画素,32bit分のデータ）に対しどのパターンか調べて対応するデコード処理を行うのですが、32bit版はパターンAならAの処理、パターンBならBの処理と条件分岐で処理を分けて必要な処理のみを行うようになっています。
それに対し、AVX2版は圧縮パターンが何かにかかわらず4通りすべての処理をAVXレジスタ上に並べて行います（これをSIMD化と言います）。
そして、処理が終わったらシャッフル命令で必要なデータだけをAVXレジスタの下位に移動させます。
32bit版と比べ条件分岐を行わないためその部分のパフォーマンス低下がないメリットの反面、計算が不要な場合でもすべての圧縮パターンを処理するため必ず（無駄な）計算を行うことになります。
例えば、圧縮パターンAは「参照データ（左の画素や1フレーム前の画素）と完全に一致する」なので参照データをコピーするだけで計算する必要はないのですが、この場合でもAVX2版は他のパターンの計算を行います。
結局、条件分岐しないメリットと無駄な計算をするデメリットとのトレードオフになりどちらが有利かと言うところで、今までは条件分岐の方を採用していましたが、今回ようやくSIMD化で好い結果がでた次第です。
もう少し詳しく書くと、256bitのAVXレジスタにより、2セット分を同時にSIMD処理できるようになったことと、処理の最後に必要となるシャッフル命令がSSE2縛りでは複雑な処理になってしまっていたのが、AVX2命令一つで可能になったこと、さらにパターンCとDを同時に計算できるようになったことが高速化の決め手となりました。
1) 256bitレジスタによるSIMD処理により2セット同時に処理できるようになった
2) それにより、分岐命令を使わなくなった
3) シャッフル命令による特定のデータ抽出が1命令で可能になった
4) パターンCとDの同時計算ができるようになった
ちなみに、エンコード処理の方は2008年10月に公開したVer2.11aから条件分岐を無くしSIMD化できています。すでにSSEレジスタにより高速なエンコード処理を実現しているため、さすがに3倍は無理ですがAVXレジスタを使って2倍程度までエンコード処理を早くすることは可能です。
条件分岐による処理と、SIMDによる処理とではベンチマーク結果にも異なる特徴が見て取れます。
32bit版
32bit版の方は条件分岐による分岐予測の成否や計算の必要なパターンか、計算の不要なパターンかの違いによりフレームごとにデコード時間にばらつきが生じます（2066フレーム目は2.8ms、2071フレーム目は2.2msと約0.6ms差があります）。
また、最後の2079から2082フレームまでの4フレームは0.9msと著しく早くなっています。これはテストに使った動画の最後4フレームが2078の画像と完全に一致するためであり、その場合はパターンAの「参照データをコピーする処理」ばかりが実行されます。
このようなケースでは、分岐予測も高い確率で成功し、高速、かつ、ばらつきの少ない結果が出ます。
AVX2版
一方、AVX2版は分岐予測や計算の有無による差が出ないため、どのフレームもほぼ同じ時間でデコードすることができ、
最後の4フレームも特別早い結果とはならないことがわかります。
AMV2MTのY2設定には4つの圧縮パターン（AからD）があり、最少処理単位（2x2画素,32bit分のデータ）に対しどのパターンか調べて対応するデコード処理を行うのですが、32bit版はパターンAならAの処理、パターンBならBの処理と条件分岐で処理を分けて必要な処理のみを行うようになっています。
それに対し、AVX2版は圧縮パターンが何かにかかわらず4通りすべての処理をAVXレジスタ上に並べて行います（これをSIMD化と言います）。
そして、処理が終わったらシャッフル命令で必要なデータだけをAVXレジスタの下位に移動させます。
32bit版と比べ条件分岐を行わないためその部分のパフォーマンス低下がないメリットの反面、計算が不要な場合でもすべての圧縮パターンを処理するため必ず（無駄な）計算を行うことになります。
例えば、圧縮パターンAは「参照データ（左の画素や1フレーム前の画素）と完全に一致する」なので参照データをコピーするだけで計算する必要はないのですが、この場合でもAVX2版は他のパターンの計算を行います。
結局、条件分岐しないメリットと無駄な計算をするデメリットとのトレードオフになりどちらが有利かと言うところで、今までは条件分岐の方を採用していましたが、今回ようやくSIMD化で好い結果がでた次第です。
もう少し詳しく書くと、256bitのAVXレジスタにより、2セット分を同時にSIMD処理できるようになったことと、処理の最後に必要となるシャッフル命令がSSE2縛りでは複雑な処理になってしまっていたのが、AVX2命令一つで可能になったこと、さらにパターンCとDを同時に計算できるようになったことが高速化の決め手となりました。
1) 256bitレジスタによるSIMD処理により2セット同時に処理できるようになった
2) それにより、分岐命令を使わなくなった
3) シャッフル命令による特定のデータ抽出が1命令で可能になった
4) パターンCとDの同時計算ができるようになった
ちなみに、エンコード処理の方は2008年10月に公開したVer2.11aから条件分岐を無くしSIMD化できています。すでにSSEレジスタにより高速なエンコード処理を実現しているため、さすがに3倍は無理ですがAVXレジスタを使って2倍程度までエンコード処理を早くすることは可能です。
条件分岐による処理と、SIMDによる処理とではベンチマーク結果にも異なる特徴が見て取れます。
32bit版
32bit版の方は条件分岐による分岐予測の成否や計算の必要なパターンか、計算の不要なパターンかの違いによりフレームごとにデコード時間にばらつきが生じます（2066フレーム目は2.8ms、2071フレーム目は2.2msと約0.6ms差があります）。
また、最後の2079から2082フレームまでの4フレームは0.9msと著しく早くなっています。これはテストに使った動画の最後4フレームが2078の画像と完全に一致するためであり、その場合はパターンAの「参照データをコピーする処理」ばかりが実行されます。
このようなケースでは、分岐予測も高い確率で成功し、高速、かつ、ばらつきの少ない結果が出ます。
AVX2版
一方、AVX2版は分岐予測や計算の有無による差が出ないため、どのフレームもほぼ同じ時間でデコードすることができ、
最後の4フレームも特別早い結果とはならないことがわかります。
3倍高速 AVX2対応 AMVデコーダー デモ版
インテルCPUの新拡張命令AVX2の性能を評価するため、AVX2命令を使ったAVX2専用のAMVビデオデコーダーを作りました。ただし、ベンチマークテスト用に作成したので対応しているのはAMV2MTのY2（YUY2可逆圧縮）のみと実用性は低いです。ベンチマークテスト用と割り切ってご覧ください。
また、実行するには2013年6月に発売されたHaswell以降の比較的新しいCPUでAVX2に対応したものが必要です。
OSはWindows7 SP1またはWindows8以降となります。
１．ベンチマークテスト
１．１．テスト環境
１．２．結果
※ FPSは処理時間をもとに算出した値です。数値が大きいほど優れています。
32bit版と比べAVX2版は約3倍高速という結果がでました。年末に公開した64bit版と比べても約2.6倍高速なので、AMVビデオコーデックのデコード処理にAVX2を使うと劇的に高速化されることがわかります。
なぜこんなに早くなるのか、AVX2って何？についてはおいおい書いていけたらと思います。
※ 何倍速いかは画像サイズにより変わってきます。画像サイズが小さいとより大きな差がでます。例えば同梱されているサンプル動画の320x240では3.2倍高速となります。逆に画像サイズが大きくなると3倍を下回ります。
【2014.3.10追記】
電源オプションでパフォーマンスが変わってくるので、追試をしました。
AVX2対応 AMVデコーダー デモ版の追試
２．使い方
ダウンロードしたファイルを解凍します。
64bit版をインストールしていない人は、先に同梱されている64bit版をインストールします。
すでに前回の64bit版をインストールしている人は新しくインストールする必要はありません（同じものです）。
AVX2デモ版をテストするときはavx2フォルダにある"Amv2mtDec64.dll"をインストール先のdllファイルと差し換えてください。
下記のように同梱されているベンチマークソフトを実行して
結果のコーデック情報に"AVX2" "DEMO"と表記があればAVX2デモ版となります。
CPUがAVX2に対応していない場合は下記のように「コーデックの初期化に失敗」となります。
（OSのチェックは行っていないのでOSが対応していない場合はエラー落ちするかもしれません）
３．ダウンロード
今回はデモ版です、Y2設定しか使えないため実用性は低いです。
本当にAVX2版は早いのか実際に試してみたい人向けと思ってください。
AMVビデオデコーダー64 AVX2対応デモ版
また、実行するには2013年6月に発売されたHaswell以降の比較的新しいCPUでAVX2に対応したものが必要です。
OSはWindows7 SP1またはWindows8以降となります。
１．ベンチマークテスト
１．１．テスト環境
| OS | Windows8 x64 Professional |
| CPU | Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz Haswell |
| MB | ASRock H87 Performance (Intel H87) |
| Memory | DDR3 1600 16GB(8GBx2 Dual Cannel)read=25.4GB/s write=14.8GB/s |
| Software | DecBench86.exe Ver1.01 DecBench64.exe Ver1.01 |
| 備考 | CPUは4コア、8スレッド、HTT対応、AVX2対応。動作クロックを3.4GHz（定格）で固定し、 省電力設定およびTurbo BoostはBIOSで無効化、動作クロックがテスト中に変動しないようにしています。 |
| タイトル | Mystery of the Nile |
| 情報 | 1280*720、2082frames、1分26秒 |
| 備考 | AviUtlと各コーデックを使ってエンコードしてテスト用の動画ファイルを作成 |
１．２．結果
| コーデック | 時間 | FPS | 32bit版に対する性能 |
| 32bit | 2.59 ms | 384 fps | 100 ％ |
| 64bit | 2.23 ms | 446 fps | 116 ％ |
| 64bit AVX2 | 0.88 ms | 1131 fps | 294 ％ |
32bit版と比べAVX2版は約3倍高速という結果がでました。年末に公開した64bit版と比べても約2.6倍高速なので、AMVビデオコーデックのデコード処理にAVX2を使うと劇的に高速化されることがわかります。
なぜこんなに早くなるのか、AVX2って何？についてはおいおい書いていけたらと思います。
※ 何倍速いかは画像サイズにより変わってきます。画像サイズが小さいとより大きな差がでます。例えば同梱されているサンプル動画の320x240では3.2倍高速となります。逆に画像サイズが大きくなると3倍を下回ります。
【2014.3.10追記】
電源オプションでパフォーマンスが変わってくるので、追試をしました。
AVX2対応 AMVデコーダー デモ版の追試
２．使い方
ダウンロードしたファイルを解凍します。
64bit版をインストールしていない人は、先に同梱されている64bit版をインストールします。
すでに前回の64bit版をインストールしている人は新しくインストールする必要はありません（同じものです）。
AVX2デモ版をテストするときはavx2フォルダにある"Amv2mtDec64.dll"をインストール先のdllファイルと差し換えてください。
下記のように同梱されているベンチマークソフトを実行して
| DecBench64.exe フルパス\sample_amv2mt_y2.avi |
結果のコーデック情報に"AVX2" "DEMO"と表記があればAVX2デモ版となります。
CPUがAVX2に対応していない場合は下記のように「コーデックの初期化に失敗」となります。
（OSのチェックは行っていないのでOSが対応していない場合はエラー落ちするかもしれません）
３．ダウンロード
今回はデモ版です、Y2設定しか使えないため実用性は低いです。
本当にAVX2版は早いのか実際に試してみたい人向けと思ってください。
AMVビデオデコーダー64 AVX2対応デモ版
