fc2ブログ
 

ビデオコーデック・ベンチマーク2014夏

世界中のビデオコーデックが登録されているcodecs.comから可逆圧縮コーデックをピックアップし、ベンチマークテストを行いました。

今回はほとんどのコーデックに更新が無いため特筆すべき点がAMV4ビデオコーデック以外ありません。テストは公平に行いますが、記事はAMV4ビデオコーデック中心となることをご了承ください。
おそらく集約命令(Gather命令)が実用化されることで他のコーデックの性能も上がってくると思うので、それまではこんな状態が続くと思います。


1.テスト内容と条件
ベンチマークはHD(1280*720)のビデオキャプチャおよびPC画面のキャプチャを想定しています。
適当なサンプル動画(未圧縮YUY2および未圧縮RGB32)を用意して、Ut Videoの作者である梅澤さんが公開しているVC Testを使って処理速度と、圧縮効果を測定します。



1.1.テスト内容
次のPCを使い、3つのサンプル動画それぞれのテストと、マルチスレッドによる処理速度のテストを行います。


1.2.PCスペック

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によるものです。



1.3.サンプル動画

サンプル動画1 Nature Movie YUY2:動きの激しい比較的低画質な実写映像
 タイトル Mystery of the Nile
 情報 1280*720、2082frames、1分26秒、3,837,598,360Byte
sample1_nature.png
 備考  AviUtlを使ってYUY2未圧縮に変換。
 動きが激しくて、画質も悪いため圧縮しにくい不利な条件のそろった動画によるテスト。
 いつものベンチマークで使っている動画と同じものです。

サンプル動画2 CG Movie YUY2:動きの少ない高画質なCG映像
 タイトル The LEGOR Movie - Official Main Trailer [HD]  
 情報 1280*720、4321frames、3分00秒、7,964,559,144Byte
sample2_lego.png
 備考  youtubeから720p版をダウンロードしてAviUtlでYUY2未圧縮に変換
 動きが少なく、画質もいいため圧縮しやすい有利な条件のテスト。
 また、上下に黒帯が付いているので、黒帯部分で高い圧縮効果が得られるコーデックに有利となります。

サンプル動画3 PC Game RGB32:ノイズが一切ないゲーム画面のキャプチャ
 タイトル Street Fighter IV 
 情報 1280*720、15820frames、4分23秒、58,319,119,660Byte
sample3_sf4.png
 備考  ゲームのベンチマークソフトを1280x720、60fpsに設定して実行。
 アマレコTVのウインドウキャプチャを使ってAMV2MT:R2の可逆圧縮で録画。
 Virtual Dubを使ってRGB32未圧縮に変換。
 PC画面を録画することを想定したRGB可逆圧縮のテストです。 
 参考動画



1.4.コーデック

コーデック一覧
コーデック名 bit内容設定
 AMV2MT Video Codec
 Ver 2.20i
 32 YUY2のテストでは「Y2標準可逆」を使用
 RGB32のテストでは「R2標準可逆」を使用
 ライセンス登録済(ロゴなし)
config_amv2mt.png
 NEW 
 AMV4 Video Codec
 Ver 4.00
 64 AVX2版を使用
 ライセンス登録済(ロゴなし)

 YUY2のテストでは「DY2:標準可逆(速度)」
 及び「DY3:高圧縮可逆(圧縮)」を使用

 RGB32のテストでは「DR2:標準可逆(速度)」
 及び「DR3:高圧縮可逆(圧縮)」を使用
config_amv4.png
 Huffyuv
 Ver 2.1.1
 32 Predict median(best)
 RGB32のテストではアルファチャネルが含まれます。
config_huffyuv.png
 NEW 
 UT Video Codec Suite
 Ver14.2.0
 64 「圧縮率優先」および
 「デコード速度優先」の2パターンをテスト

 YUY2のテストでは「ULY2」を使用
 RGB32のテストでは「ULRG」を使用
config_utvideo.png
 Lagarith Lossless Video Codec
 Ver 1.3.27
 64 YUY2のテストでは「YUY2」を使用
 RGB32のテストでは「RGB」を使用
config_lagarith.png
 Alparysoft Lossless Video
 Ver 2.0
 32 lossless compression
 enable prediction
 realtime
 ロゴあり
config_AlparySoft.png
 CorePNG
 Ver 0.8.2
 32 1-Fastestconfig_CorePNG.png
 NEW 
 MLC Codec
 Ver 1.2
 64 Muximum speed
 Use Multithreading off
config_MLC.png
 FastCodec
 Ver 1.0beta
 32 Absolutely lossless
config_FastCodec.png
 MSU Lossless Video Capture
 Ver 0.6.0
 32 Absolutely lossless
 Maximize speed
 RGB32には対応していない
config_msu.png

※ bitはvctest-x86でテストしたものを「32」、vctest-x64でテストしたものを「64」としています。 両方用意されているコーデックでは64bit版を優先してテストします。
※ 規定の手順でWindows8にインストールできないコーデックを除外しました(Huffyuvだけは手動でインストールしてテストしています)。




2.結果

2.1.動きの激しい比較的低画質な実写映像
result1_nature.png
※ fpsは1秒間に何フレーム処理できるかを示し、数値が高いほど優れています。
※ compression ratio(圧縮効果)は未圧縮のデータに対し何分の1に圧縮できるかを示し。数値が大きいほど優れています。

圧縮効果の面でMLCが4.3と非常に優れています。
AMVビデオコーデックにとってはあからさまに不利な条件でのテストなので、圧縮効果の面で最下位。
処理は速いけど圧縮効果が低いコーデックと言った位置づけになります。
一方、AMV4のDY3は不利な条件でもそこそこの圧縮効果を発揮しています。
また、AMV4のデコード処理は大幅に高速化されていて、AMV2MT:Y2の527fpsに対しAMV4:DY2(AVX版)のデコード速度は1802fps(3.4倍)です。
そのほかでは、UT Video速度優先のエンコード処理がHuffyuvに肉薄しています。この部分は過去のベンチマークをみると徐々に差を詰めてきています。


2.2.動きの少ない高画質なCG映像
result2_CG.png

処理速度を見ると、大半のコーデックにおいてサンプル動画1のテストよりエンコード処理が早くなっている事が解ります。
多くのコーデックにおいて圧縮し易い映像では処理が早くなる傾向があるようです。
それに対しAMVビデオコーデックはサンプル1とサンプル2を比較してもエンコード処理の差はわずかとなっています。
AMVのエンコードには条件分岐処理が存在しないため映像の内容による処理時間の変動が起きにくい特徴があります。

次に圧縮効果の面をみると、MSUが18.1と突出しています。
そのほかは圧縮効果が5.0前後の集団と、10.0前後の集団(MLC、Lagarith、AMV4DY3)の2つに分かれます。
5.0前後の集団は映像の内容によらず5.0辺りから圧縮効果が伸び悩み、好条件であってもなかなか高い圧縮効果が得られません。
一方、10.0前後の集団は映像の内容によってはもっと高い圧縮効果が狙えます。
AMV4のDY3は二次圧縮を適用したことで、動きが少なかったり、単調な画像(グラデーションやべた塗りなど)、黒帯があるなどの条件において高い圧縮効果が狙えます。

AMVビデオコーデックのYUY2可逆における圧縮効果
 
 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 黒帯あり




2.3.ノイズが一切ないゲーム画面のキャプチャ
result3_GAME.png

Huffyuvはアルファチャネルも処理しているため不利な結果となっています。
MSUはRGB24でないと使えないようです。



2.4.マルチスレッドによるテスト
最後に各コーデックをマルチスレッドに設定した場合の処理速度を観察します。
AMV4はSSE4.1版とAVX2.0版をテストしています。
カッコ内の数値はスレッド数(フレーム分割数)で、1となっているのはシングルスレッドで処理しています。
mは「マルチスレッドを使う」と言う項目が用意されているだけでスレッド数が不明のコーデックです。
テストにはサンプル動画1を使います。
result4_multithread.png


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についてもテストしています。


1.テスト概要
できるだけ同じ条件で観察したいので一つのキャプチャソフトでQSVとAMV4の両方が使えるものを探しましたが、見つかりませんでした。
なので、QSVに関してはOBS(Open Broadcaster Software)とキャプチャカードに付属するVideoKeeper2を使い、AMV4はアマレコTVを使うことにします。画像サイズやフレームレートを揃え、ドロップフレームが生じない条件でテストしましたが、やはりキャプチャソフトによる違いが無いとは言い切れないためその点はご容赦ください。

1.1.テスト方法
各キャプチャソフト(配信ソフト)にて録画を行い、その時のタスクマネージャのグラフ(CPU使用率)を観察します。
ビデオキャプチャにはマイコンソフト社のSC-512N1-L/DVIを使いPS4版のBATTLE FIELD 4のキャンペーンモードのオープニングシーン(※)を録画します。
この動画の冒頭1分50秒と同じ内容


下図はOBSを使ってソフトウエア・エンコーダのx264にてローカル録画した時のグラフになります。
キャプチャ条件はHDMI 1920x1080 60p YUY2です。
graph_obs_x264.png

グラフの下部にある5枚の画像はキャプチャ中のおおよその映像を示しています。グラフのこの地点ではこんな感じの映像を処理していると思ってください。
グラフの左端はプレビューも、録画も行っていないため、ほぼCPU使用率が0%となっています。
そこから録画を開始し画像1の付近では、真っ黒な画面に小さい文字でゲーム制作会社などのテロップが表示されるシーンとなります。
このシーンは単調(1枚の画像として見たとき複雑でない、べた塗りやグラデーションの面積が広いなど)かつ動きが全く無い映像なためかCPU使用率は20%強と低めです。

グラフの中盤(画像2、3付近)は普通に動きのあるシーンとなり、CPU使用率は約55%と跳ね上がります。
グラフの後半(画像4、5付近)はオープニングが終わり、プレイ中となりますが、操作を行っていないためほとんど動きのない映像が続きます。動きがほとんどない映像ではCPU使用率も30%強と低めになるようです。

このようなテストを、エンコーダを変えて行います。


2.テスト条件
パソコンのスペックとソフトウエア
OSWindows8 x64 Professional
CPUIntel(R) Core(TM) i7-4770 CPU @ 3.40GHz Haswell
GPUGeForce GTX 650 Driver 337.88
MBASRock H87 Performance (Intel H87)
MemoryDDR3 1600 16GB(8GBx2 Dual Channel)read=25.4GB/s write=14.8GB/s
HDD録画用のHDD WD30EZRX 3TB
SoftwareOBS 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 SourcePS4版BATTLE FIELD 4のオープニングシーンを
HDMI 1080 60p YUY2でキャプチャ
この動画の冒頭1分50秒と同じ内容
備考CPUは4コア、8スレッド、HTT対応、AVX2対応。動作クロックを3.4GHz(定格)で固定し、 省電力設定およびTurbo BoostはBIOSで無効化、動作クロックがテスト中に変動しないようにしています。


3.各キャプチャソフトの主な設定
詳細設定は長くなるので「続きを読む」に記載します。ここでは特に重要と思われる内容のみ記載します。

3.1.OBS
QSVおよびNVEncにてローカル録画するように設定します。
ビットレートは8Mbpsとしました。
サウンドはアマレコTVとできるだけ同じ条件となるようMP3 128kbps 2chとしています。
デスクトップの音とキャプチャカードの音がミキシングされます。
obs.png

3.2.VideoKeeper2
QSVを使って録画するように設定します。
ビットレートは20Mbps。
オーディオミキサーの処理はありません。
vk2.png

3.3.アマレコTV
AMV4ビデオコーデックをDY3(YUY2高圧縮可逆)に設定しSSE4版とAVX2版のそれぞれで録画します。
ビットレートの設定はありませんが出来上がった動画ファイルから逆算すると約320Mbpsとなります(今回のテスト条件では秒間約40MByteなのでHDD単体でもドロップなく録画可能)。
オーディオ圧縮にLAME MP3 128kbpsを使います。
オーディオミキサーの処理はありません。
amarec.png


4.テスト結果
各エンコーダで録画した際のタスクマネージャのグラフに色を付けて合成したのが下図になります。
graph.png

グラフの前半部は録画していない状態(プレビュー処理のみ)の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で読み込んだ画像です。
ゲーム側の都合によりプレイする度に完全に同じ映像がレンダリングされるわけではないようなので、類似するフレームを抜き出しての比較となります。
image.png

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編


パソコンのスペック
OSWindows8 x64 Professional
CPUIntel(R) Core(TM) i7-4770 CPU @ 3.40GHz Haswell
MBASRock H87 Performance (Intel H87)
MemoryDDR3 1600 16GB(8GBx2 Dual Cannel)read=25.4GB/s write=14.8GB/s
SoftwareVideo Codec Test 2.0.0
備考CPUは4コア、8スレッド、HTT対応、AVX2対応。動作クロックを3.4GHz(定格)で固定し、
省電力設定およびTurbo BoostはBIOSで無効化、動作クロックがテスト中に変動しないようにしています。



【ベンチマーク結果】
表1 シングルスレッドによるAMV2MT 32bit SSE2の結果(1スレッド、1コア)
 レベルエンコードデコード圧縮効果備考
時間FPS時間FPS
AMV2MT
32bit
SSE2
Y10.60 ms1648 fps0.80 ms1238 fps1.15YUY2可逆
Y21.24 ms801 fps1.90 ms523 fps2.09YUY2可逆
Y31.81 ms551 fps2.64 ms377 fps2.78YUY2非可逆
Y43.73 ms267 fps4.37 ms228 fps3.67YUY2非可逆 二次圧縮あり


表2 シングルスレッドによるAMV4 SSE4.1版の結果(1スレッド、1コア)
 レベルエンコードデコード圧縮効果備考
時間FPS時間FPS
AMV4
32bit
SSE4.1
DY21.09 ms910 fps1.17 ms850 fps2.52YUY2可逆
DY31.84 ms541 fps1.84 ms542 fps3.09YUY2可逆 二次圧縮あり
AMV4
64bit
SSE4.1
DY21.11 ms900 fps1.08 ms925 fps2.52YUY2可逆
DY31.78 ms558 fps1.66 ms601 fps3.09YUY2可逆 二次圧縮あり


表3 シングルスレッドによるAMV4 AVX2版の結果(1スレッド、1コア)
 レベルエンコードデコード圧縮効果備考
時間FPS時間FPS
AMV4
32bit
AVX2
DY20.84 ms1189 fps0.64 ms1557 fps2.52YUY2可逆
DY31.21 ms825 fps1.17 ms854 fps3.09YUY2可逆 二次圧縮あり
AMV4
64bit
AVX2
DY20.72 ms1386 fps0.55 ms1790 fps2.52YUY2可逆
DY31.07 ms 931 fps0.97 ms1029 fps3.09YUY2可逆 二次圧縮あり

※ 時間、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.AMVビデオコーデックの内部仕様
 AMV2MTAMV4
 Y2標準可逆Y3標準DY2標準可逆DY3高圧縮可逆
圧縮パターン4648
参照箇所1112
参照距離遠い遠い近い近い
二次圧縮無し無し無し有り
画質可逆非可逆可逆可逆
マルチスレッド最大8最大8非対応1非対応1
拡張命令SSE2SSE2SSE4.1
AVX2.0
SSE4.1
AVX2.0
黄色は変更箇所

表2.性能
 AMV2MTAMV4
 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の場合次の2つになります。

(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の公開まで、まだまだ時間がかかりますが、おいおい内容を書いていこうと思います。


AVX2対応デコーダーはなぜ3倍も高速化できたのか

端的に言えばAVX2を使っているからとなりますが、AVX2による性能向上は(理論上の)最大でも2倍までなのでもう一つの要因としてSIMD化があげられます。

AMV2MTのY2設定には4つの圧縮パターン(AからD)があり、最少処理単位(2x2画素,32bit分のデータ)に対しどのパターンか調べて対応するデコード処理を行うのですが、32bit版はパターンAならAの処理、パターンBならBの処理と条件分岐で処理を分けて必要な処理のみを行うようになっています。

それに対し、AVX2版は圧縮パターンが何かにかかわらず4通りすべての処理をAVXレジスタ上に並べて行います(これをSIMD化と言います)。
そして、処理が終わったらシャッフル命令で必要なデータだけをAVXレジスタの下位に移動させます。

simd.png


32bit版と比べ条件分岐を行わないためその部分のパフォーマンス低下がないメリットの反面、計算が不要な場合でもすべての圧縮パターンを処理するため必ず(無駄な)計算を行うことになります。
例えば、圧縮パターンAは「参照データ(左の画素や1フレーム前の画素)と完全に一致する」なので参照データをコピーするだけで計算する必要はないのですが、この場合でもAVX2版は他のパターンの計算を行います。
結局、条件分岐しないメリットと無駄な計算をするデメリットとのトレードオフになりどちらが有利かと言うところで、今までは条件分岐の方を採用していましたが、今回ようやくSIMD化で好い結果がでた次第です。

simd_avx2.png

もう少し詳しく書くと、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版
bench_cmp.png
32bit版の方は条件分岐による分岐予測の成否や計算の必要なパターンか、計算の不要なパターンかの違いによりフレームごとにデコード時間にばらつきが生じます(2066フレーム目は2.8ms、2071フレーム目は2.2msと約0.6ms差があります)。
また、最後の2079から2082フレームまでの4フレームは0.9msと著しく早くなっています。これはテストに使った動画の最後4フレームが2078の画像と完全に一致するためであり、その場合はパターンAの「参照データをコピーする処理」ばかりが実行されます。
このようなケースでは、分岐予測も高い確率で成功し、高速、かつ、ばらつきの少ない結果が出ます。


AVX2版
bench_simd.png
一方、AVX2版は分岐予測や計算の有無による差が出ないため、どのフレームもほぼ同じ時間でデコードすることができ、
最後の4フレームも特別早い結果とはならないことがわかります。


3倍高速 AVX2対応 AMVデコーダー デモ版

インテルCPUの新拡張命令AVX2の性能を評価するため、AVX2命令を使ったAVX2専用のAMVビデオデコーダーを作りました。ただし、ベンチマークテスト用に作成したので対応しているのはAMV2MTのY2(YUY2可逆圧縮)のみと実用性は低いです。ベンチマークテスト用と割り切ってご覧ください。
また、実行するには2013年6月に発売されたHaswell以降の比較的新しいCPUでAVX2に対応したものが必要です。
OSはWindows7 SP1またはWindows8以降となります。

cpu-Z.png 


1.ベンチマークテスト
1.1.テスト環境

パソコンのスペック
OSWindows8 x64 Professional
CPUIntel(R) Core(TM) i7-4770 CPU @ 3.40GHz Haswell
MBASRock H87 Performance (Intel H87)
MemoryDDR3 1600 16GB(8GBx2 Dual Cannel)read=25.4GB/s write=14.8GB/s
SoftwareDecBench86.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と各コーデックを使ってエンコードしてテスト用の動画ファイルを作成



1.2.結果
AMV2MT Y2(標準可逆) 1コア、1スレッド
コーデック時間FPS32bit版に対する性能
32bit2.59 ms384 fps100 %
64bit2.23 ms446 fps116 %
64bit AVX20.88 ms1131 fps294 %
※ FPSは処理時間をもとに算出した値です。数値が大きいほど優れています。

32bit版と比べAVX2版は約3倍高速という結果がでました。年末に公開した64bit版と比べても約2.6倍高速なので、AMVビデオコーデックのデコード処理にAVX2を使うと劇的に高速化されることがわかります。
なぜこんなに早くなるのか、AVX2って何?についてはおいおい書いていけたらと思います。

※  何倍速いかは画像サイズにより変わってきます。画像サイズが小さいとより大きな差がでます。例えば同梱されているサンプル動画の320x240では3.2倍高速となります。逆に画像サイズが大きくなると3倍を下回ります。



【2014.3.10追記】
電源オプションでパフォーマンスが変わってくるので、追試をしました。
AVX2対応 AMVデコーダー デモ版の追試







2.使い方
ダウンロードしたファイルを解凍します。
64bit版をインストールしていない人は、先に同梱されている64bit版をインストールします。
すでに前回の64bit版をインストールしている人は新しくインストールする必要はありません(同じものです)。
AVX2デモ版をテストするときはavx2フォルダにある"Amv2mtDec64.dll"をインストール先のdllファイルと差し換えてください。

下記のように同梱されているベンチマークソフトを実行して
DecBench64.exe フルパス\sample_amv2mt_y2.avi

avx2.png

結果のコーデック情報に"AVX2" "DEMO"と表記があればAVX2デモ版となります。


CPUがAVX2に対応していない場合は下記のように「コーデックの初期化に失敗」となります。
(OSのチェックは行っていないのでOSが対応していない場合はエラー落ちするかもしれません)
error_20140208182053e24.png 



3.ダウンロード
今回はデモ版です、Y2設定しか使えないため実用性は低いです。
本当にAVX2版は早いのか実際に試してみたい人向けと思ってください。

AMVビデオデコーダー64 AVX2対応デモ版


 
 
あまラボへようこそ
このブログでは自作ソフトの最新情報やtips、PC動画に関する話題を掲載していきます。各記事へは下にあるカテゴリからアクセスして下さい。

ファイルのダウンロードはホームページの方でお願い致します。

質問・要望・不具合報告はこちら
アマレコTV
アマミキ!
アマレココ
アマレコ・ライト
ファンタジーリモート
AMVコーデック



ホームページ
カテゴリ
最新コメント
カレンダー
08 | 2023/09 | 10
- - - - - 1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
最新記事
最新トラックバック
ブログ内タグ

アマレコTV ビデオキャプチャ アマレコVR AMVコーデック Oculus アマレココ Quest アマミキ! コーデック gQuest SC500 動画配信 Pico GO ファンタジーリモート 4K アマレコライト Unity プラグイン G2 AMV4 oculus ライブ機能 SC512 パススルー機能 デスクトップキャプチャ Passthrough AVX2 リモートソフト FAQ 質問コーナー アセット機能 ニコニコ動画 HDキャプチャ DirectShow 背景透過 120Hz Asset レゴ 遅延 解説動画 組み換え 可変再生速度 Meta LEGO MetaQuest VR GV-USB2 XL2420T 2 Pico4 倍速液晶 液晶モニター デインターレース ベンチマーク アマステ Intensity VRonVR AMV2MT MonsterX3A Pro PS4 VideoKeeper2 designs インストール Alternate AVX XCAPTURE-1 RDT233WX-Z GV-USB SD-USB2CAP4 31024 32ZP2 31006 ffmpeg 画像処理 60fps Robust Matting RGBキャプチャ Rift Video Shadow Play WindowsMR RYZEN UtVideo T2 HDMI NVEnc HDCP QSV LameACM OBS 音遅延 MP3 Haswell 電源オプション 音ズレ 録画 オーバーレイ XCapture-1 MonsterXU3.0R フィギュア ハイパースレッディングテクノロジー HT 31021 MPC 液晶テレビ DirectShowFilter プレビュー 擬似NTSCキャプチャ SD-USB2CUP4 Livetube AtomでHDキャプチャ キャプチャーツール シンクライアント イベント IntensityPro DC-HD1 額縁遅延 REGZA ZP3 倍速補完処理 32ZP32 Kabelake リプレイ機能 モノステ 倍速駆動 ゲームスムーズモード LAVFilters SkyBox Hand Tracking 2.0 ファイルマネージャプラス pytorch APIパススルー機能 API python ハンドジェスチャー パカラーススルー機能 アルファ付き動画 アルファ付きVR動画 RVM クロマキー ダウンロード AssetBundle 物理処理 download passthrough 検証 Preferred Filter Tweaker SteamVR GPU使用率 可逆圧縮 SKnet GV-USB3 キャプチャカード VR動画 フレーム間圧縮 新プレイヤー機能 AMPlayer 60Hz 新アマレコVR 90Hz VRコントローラー MR Windows SSE 

ブログ内検索
月別アーカイブ
アマレココに関するリンク
お世話になっているソフトのリンク
RSSリンクの表示
管理画面
  • 管理画面