スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


アマレコTVスレについて その4 4K録画

アマレコTVスレではなくキャプチャスレの方にあった話題ですが、4K録画についてできるかどうかと言うのがありましたので私なりの見解を書きます。
おおもとの質問は「PCゲームを4K 60fpsで録画できるコーデックはありますか?」ですがコーデックの話だけでは意味がないのでもっと広範囲について述べます。

4K録画についてはAMV4公開時に4K対応を謳おうかどうか迷った部分です。
理論上は可能ですが、実際に4K録画のテストをしてみたところ確実にできると言える結果とはならなかったため結局4K対応は謳わなかったと言う経緯がありますが、現状、一般的な環境において4K録画を行うにはビデオコーデックの処理能力、CPUの処理能力、ビデオファイルを書き出すストレージの処理能力の全てが4Kの要求スペックを満たす必要があります。
あと使い方によって変わってきてしまうため何とも言えませんが、キャプチャソフトの処理能力やビデオキャプチャカードを使うならそちらも4Kの要求スペックをクリアする必要がありますし、PCゲームをデスクトップキャプチャやDirectXキャプチャで録画するなら更にゲームを4Kで動作させるだけのスペックが必要となります。


1.コーデックとCPUについて4Kを満たすスペックとは?
ビデオコーデック・ベンチマーク2014夏

result1_nature.png

理論上はこのベンチマーク結果を9で割った数値(※)が60fpsを上回れば4Kを処理する能力のあるコーデックと言えます。
言い換えるとグラフ内のfpsが540fps以上なら良いとなります。
※ (3840x2160) ÷ (1280x720) = 9

AMV4は処理の遅いDY3でも9で割った値が100fpsを上回るため理論上エンコード、デコードとも4Kを十分処理できます。
他のコーデックについては一般的なCPUの処理能力(1スレッド)では無理であると言えます。

なお、UT Videoに関しては4コア8スレッドで処理することで理論上可能となってきます。
result4_multithread.png

このように現状における4Kの要求スペックは以外と高く、ほぼAVX2対応のCPUとAMV4一択なのではないでしょうかと言うのが私の見解です。


2.4K録画を可能とするストレージとは?
次に動画ファイルを書き出すストレージの処理能力ですが、無圧縮であった場合約1000MB/s(※1) 必要となります(RGBの場合約1500MB/s)。
なので、無圧縮で録画するには最低でもSSDを3台以上ストライピングする必要がありますが、それでも実際にできるかどうかはちょっと判りません。なので、コーデックを使って圧縮するのが現実的です。
圧縮した場合の要求スペックはYUY2フォーマットの場合 約333MB/s(※3) になりますので、理論上SSDを1台用意すれば可能なように思えます。RGBについては不明ですが適当に書くと600MB/s(※4) くらいでしょうか。圧縮したとしてもSSDは2台以上必要に思われます。

※1 4K(YUY2フォーマット) 60fpsの場合 3840x2160x2x60 = 約995 MByte
※2 4K(RGB24フォーマット) 60fpsの場合 3840x2160x3x60 = 約1492 MByte
※3 圧縮効果を3と仮定
※4 圧縮効果をYUY2より悪く2.5と仮定

3.実際のテスト
以上を踏まえ理論上4Kの要求スペックを満たす環境を用意してテストを行いました。

CPU: i7-4770 @3.4GHz固定 AVX2対応
コーデック: AMV4 DY3
ストレージ: CSSD-S6T256NHG5Q 公称値でシーケンシャルライト483MB/s
キャプチャソフト: アマレコTV
キャプチャカード: くるくるベンチ 3840x2160 YUY2 59.94fpsに設定

結果は録画を開始すると徐々に書込みバッファの空きが減っていき、書込みバッファの空きが0%になるとまともに録画できなくなります。
出来上がったビデオファイルを再生すると書込みバッファが枯渇するまでの部分は正常に見えましたが、後半は明らかにスペック不足でまともに録画できるとは言えない状態です。

アマレコTVのレポートファイル(書込みバッファが枯渇する前の正常な部分)をみると
VT=00:00:04.442s( 265f), Cap= 0f( 0D), Enc=13.077ms, Siz=4186KB( 25%)KEY, Drp=0, (+)0, (-)0, Buf= 1, o
IT=00:00:04.442s, HDD=244.8MB/s( 95%), fps=59.9f/s

となっているので、このテスト条件のストレージ要求スペックは244MB/sであることが判ります。
一方、エンコード処理は13ms前後なのでぎりぎり60fpsのリアルタイム処理をクリアしていると言えます。

以上より、CPUとコーデックは4Kの要求スペックを満たしていると判断しますが、アマレコTVのファイル処理とSSD 1台の構成は4Kの要求スペックを満たしていないようです。
録画失敗の原因はSSDが公称値を下回るかアマレコTVのファイル処理がSSDの性能を発揮しきれていないと言ったところでしょうか。


4.まとめ
現状、一般の人が4Kの録画を行うにはi7 AVX2対応以上のCPUとAMV4ビデオコーデックは必須のように思います。
それに加え、SSD複数台かアマレコTV以上のファイル処理が実装されたキャプチャソフトが必要と思われますので、まだまだ実現するのは難しいと私は感じました。
更にPCゲームとなると絶望的なように思いますが、NVidiaのShadowPlayのようにビデオカード上でエンコードするようなシステムであれば可能なようです。h264でエンコードすればストレージの要求スペックも大幅に下がりますので、そちらの方が現実的と言えなくもないけど、はやりそこそこ高価なGPUが必要なようですし、ビデオキャプチャでは使えないので、何とも言えないか。
あと、4K対応のビデオキャプチャカードも販売されているようですが要求スペック(CPU、コーデック、キャプチャソフト、ストレージ)が明記されていないので、どういった構成で運用できるのか私も知りたいところです。

4Kを扱うためのプラン
1) 無圧縮プラン: SSD 3台以上のストライピングが必要(実際はもっとかもしれない)
2) AMV4圧縮プラン: AVX2対応のCPUとSSDの性能を引き出せるキャプチャソフトかSSD 2台以上のストライピングが必要
3) ShadowPlayプラン: GTX900番台が必要?(PCゲーム専用、ビデオキャプチャは不可)、ストレージはHDD 1台で可(ただし画質次第)

スポンサーサイト


アマレコTVスレについて その3 書込みバッファが0%

録画中のみプレビューが重くなる(遅延が増える)という内容で、知恵袋の方で見かけた質問ですが、状況が明確に記載されていたのでついでに書きます。

録画中にアマレコTVのステータス欄のHDDの空きバッファが0%になってしまいうとのことなので、完全にHDDの書込み速度不足が原因です。
録画保存先を別のHDDへ変更するか、不要なファイルを削除してからデフラグ等でメンテナンスしてみてください。
そして、何より重要なのが圧縮効果の高いコーデックを使うことです。

処理速度の問題だと考えてAMV4をDY2へ設定して使っているとのことですが初期値は圧縮効果の高いDR3です。DY2へ変更するのは逆効果となってしまいます。
一般的にアマレコTVとAMVビデオコーデックに関してはCPUへほとんど負担がかかりません。なので通常の利用において処理を早くするような設定にする必要はありません(特にコーデックの設定を変更する必要はありません)。
むしろ、録画に関してはHDDへ負担がかかりますので圧縮効果の低い設定にしてはいけません。

DR2やDY2は極端にCPUが非力な場合や強力なストレージを用意する代わりに極端にCPU負荷を減らしたい場合に使う設定です。一般的な用途には不向きです。何よりファイルサイズがデカくなるデメリットがあります。

まとめると
・AMV4をDR3かDY3へ設定する
・録画先HDDの不要なファイルを削除した後、デフラグをする
・それでもだめなら、アマレコTVの録画設定でfpsの目安を30fpsとして妥協するか、HDDを買い足すしかない。もしくはMJPEG等の非可逆コーデックを使う。

と思ったけど、すでに30fpsにしても根本的な改善はみられないようなので、致命的にHDDへの書き込み速度が足りない可能性が高いです。
1280x720 YUY2 30fpsをAMV4のDY2で録画する場合、1秒間に30MB程度の書き込みができればいけると思いますが、30MBを下回るとなれば相当重症な気がします。(今どきのHDDなら大抵100MBを超える)

システムメモリが不足していてHDDの一部が仮想メモリとなってしまい、録画と仮想メモリでHDDが悲鳴を上げている可能性もあるし、セキュリティソフトなのどの常駐ソフトもHDDへ頻繁にアクセスしているかもしれません。そもそも、物理的な故障も視野に入る状況なので、小手先の対処は不可能です。
録画専用にHDDを増設、システムメモリの増設、セキュリティの見直し、常駐ソフトの見直しOSのクリーンインストール、マザーボードやストレージインターフェイスの交換などが必要かもしれません。

当初、質問者はHDDの空きバッファが0%になっていることに気が付いているので簡単に解決しそうに思いましたが、HDDに致命的なトラブルが生じていると解決は難しいかもしれません。一つ言えることはアマレコTVやAMV4ビデオコーデックの設定などでは改善されないでしょう。


AMV4ビデオコーデックとアマレコTV Ver3.10公開

AMV4ビデオコーデックとアマレコTVの新バージョンをホームページで公開しました。

AMV4ビデオコーデック
【概要】
AMV2MTビデオコーデックの後継にあたるビデオコーデックです。
最新のCPU拡張命令であるAVX2へ対応し、処理速度が大幅に向上しました※1。
アマレコTVと組み合わせることでソフトウエアエンコーダーながらIntelのQuick Sync VideoやNVIDIAのNVENCと言ったCPUをほとんど使わないエンコーダーよりも少ないCPU負荷でFullHDの録画が可能となります。
AMV4は動画エンコード支援機能QSVを凌ぐ超低負荷

また、圧縮効果も二次圧縮の適用(一度圧縮したデータをもう一度圧縮する)などにより性能が向上。
リアルタイムで動作する可逆圧縮ビデオコーデックとしてトップレベルの圧縮性能を誇るまでになりました。
ビデオコーデック・ベンチマーク2014夏

そのほか64bit版のWindows7/8へ対応※2。64bitOS上では32bitアプリケーションと64bitアプリケーションの両方で利用できます。32bitのキャプチャソフトで録画して64bitの編集ソフトで編集するなどがProxy Codec64なしに可能となります。

QSVやNVENCを凌ぐ圧倒的な処理速度と、可逆圧縮としてトップレベルの圧縮効果を併せ持つ究極のソフトウエアエンコーダーとなっています。

※1 AVX2が利用できないパソコンではCPU拡張命令のSSE4.1を使って動作します。SSE4.1の場合でもAMV2MTビデオコーデックより速い処理と、高い圧縮効果を実現します。
※2 32bitOS用のインストーラも用意していますが、動作確認がとれないため動作対象外としています。

【その他】
(1) 各アプリケーションについて
ファンタジーリモート、アマレココ、アマレコ・ライトを使うには今まで通りAMV3が必要です。
アマレコTVを使うにはAMV4が必要です。

(2) AMV4オンラインヘルプについて
http://amalabo.blog35.fc2.com/blog-entry-270.html

(3) AMV2MTとAMV4の違い まとめ
http://amalabo.blog35.fc2.com/blog-entry-271.html

(4) AMV4ビデオコーデック 内部仕様でみるAMV4とAMV2MTの違い
http://amalabo.blog35.fc2.com/blog-entry-263.html



アマレコTV Live アマミキ! Ver3.10
【更新内容】
アマレコTVがAMV4仕様になり、Windows7/8へ暫定対応しました。
録画やリプレイ機能でAMV4ビデオコーデックを使います。圧縮効果が向上したためファイルサイズをより小さくしたり、リングバッファの記録時間を延ばす効果があります。

(1) Windows7 sp1 64bit版およびWindows8.1 64bit版へ暫定対応。
(2) CPUの拡張機能SSE4.1が必須になります。
(3) メインのコーデックをAMV4ビデオコーデックへ変更。
(4) リプレイ機能がAMV4ビデオコーデックへ対応。
(5) 録画設定のハーフサイズを廃止。
(6) オーディオデバイスを使わない時にMP3で圧縮する設定になっているとエラー落ちする不具合を修正。
(7) 録画停止時に書き込みエラーが起こる不具合を修正。



ダウンロード
ホームページ


ビデオコーデック・ベンチマーク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レジスタへ対応した効果が得られています。




ビデオコーデック・ベンチマーク2009と2012夏の比較

2009年の結果と2012年の結果を比較しました。
 ・ビデオコーデック・ベンチマーク2009
 ・ビデオコーデック・ベンチマーク2012夏(2012.9.4修正版)


テスト環境の主な違い
 2009年2012年
OSWindows2000
Pro SP4
Windows7 x64
Professional SP1
-
CPUCeleron420
(Conroe-L) 1.6GHz
 i5-3470S
(Ivy Bridge) 2.9GHz
クロック 1.8倍
MemoryDDR2, 1GB
(single)
read=3.3GB/s
write=1.2GB/s
DDR3, 1600 8GB
(4GBx2 Dual Cannel)
read=23.7GB/s
write=12.2GB/s
read 7.1倍
write 10.1倍
AMVビデオコーデック Version2.20e
3.00e
2.20i
3.00i
 
UT Video Version5.2.211.1.1 
Lagarith Version1.3.191.3.27 
Huffyuv Version2.1.12.1.1 


1.圧縮効果について
2009年と2012年を比較してどのコーデックも大きな変更は見られず。
圧縮効果に付いてはパソコンの性能とは無関係なので、各コーデックのバージョンアップによる性能向上となりますが、今回テストしたコーデックの中で大きな変化は見られませんでした。

表1-1 圧縮効果の比較
 2009年2012年補足
AMV2MT:Y22.12.11.0倍 -
UT Video速度優先2.82.81.0倍2012年はx64版
UT Video圧縮優先3.43.41.0倍2012年はx64版
Lagarith3.83.81.0倍2012年はx64版
Huffyuv Predict Left2.52.51.0倍 同じバージョン

    

2.処理速度について
2009年と2012年を比較してCPUの処理能力が上がっているため各コーデックの処理能力も2倍から3倍と早くなっています。
クロックは1.6GHzから2.9GHz(1.8倍)なので段純なクロックアップだけでなくメモリの性能向上も大きいように思います。
特にLagarithは処理時間が大きく向上しています。これはLagarith自体のバージョンアップによる改善(2倍程度)が大きいようです。
一方、Huffyuvはエンコード速度が2009年のときより遅い結果となっています。


表2-1 処理速度の比較
 2009年2012年補足
AMV2MT:Y2Enc188 fps602 fps3.2倍 -
Dec170 fps404 fps2.3倍
UT Video速度優先Enc77 fps175 fps2.2倍2012年はx64版
Dec42 fps114 fps2.7倍
LagarithEnc20 fps90 fps4.5倍2012年はx64版
Dec14 fps54 fps3.8倍
Huffyuv Predict LeftEnc127 fps122 fps0.9倍 2009年より遅くなっている
Dec33 fps45 fps1.3倍

   
表2-2 2012年の環境におけるLagarith x64のバージョンの比較
 Ver1.3.19Ver1.3.27
Lagarith x64エンコード46 fps90 fps1.9倍
デコード32 fps54 fps1.6倍
圧縮比3.803.811.0倍

   


3.マルチスレッドでの動作について
2009年はAthlonX2の2スレッドで処理した場合に1スレッドでの処理の何倍になるのか、2012年はi5-3470Sの4スレッドで処理した場合に1スレッドでの処理の何倍になるのかを見ます。
基本的にスレッドの数が2倍になったら処理能力も2倍になって欲しいところですが、 実際はマルチスレッドで処理するために必要な処理が増えるので2.0倍より少なくなります。
2009年は2スレッドなので2.0倍、2012年は4スレッドでテストしたため4.0倍に近いほど良いと言えます。
AMVとUT Videoは高い適応力を持っていると言えますが、Lagarithはスレッド数やフレーム分割数と言った設定が無いためCPUが4スレッドに対応していても4スレッドで処理される訳ではないようです。この結果(2009年と2012年でほぼ同じ)を見る限り2スレッドで頭打ちされているように見えますので、マルチスレッドへの適応力は低いままと思います。

表3-1 マルチスレッドでの動作
 2009年
(2スレッド)
2012年
(4スレッド)
補足
AMV2MT:Y2Enc1.7倍3.0倍 -
Dec1.8倍3.4倍
UT Video速度優先Enc1.9倍3.1倍2012年はx64版
Dec1.9倍3.6倍
LagarithEnc1.5倍1.4倍2012年はx64版
Dec1.2倍1.2倍






ビデオコーデック・ベンチマーク2012夏(2012.9.4修正版)

新しいPCを購入したので最新のCPUでビデオコーデックがどう動作するかベンチマークを行いました。
基本的には「ビデオコーデック・ベンチマーク2009」と同じですがWindows7 x64での動作になります。  

ビデオコーデック・ベンチマーク2012夏」と同じ内容になりますが、テストに使った動画が2009年のものと僅かに違っていたため再テストしました(2009年に使った動画ファイルが見つかったのでそれを使用)。
再テストではLagarithの結果が多少変わってきます。AMV、UT Video、Huffyuvの結果は殆ど変わりません。
2009年のデータと比較する場合はこの記事(2012.9.4修正版)と比較してください。

 
【測定条件】
ベンチマークはHD(1280*720)のビデオキャプチャ(実写)を想定しています。動画ソースはマイクロソフトのサイトからダウンロードしたWMV形式のファイルをAviUtlを使ってYUY2未圧縮に変換したものを使います。 (2009年の「動きの激しい動画」と同じになります)
測定はUt Videoの作者が公開しているVC Test(2010年10月24日版)を使ってエンコード時間(圧縮にかかった時間)、デコード時間(復元にかかった時間)、圧縮比(未圧縮ファイルの何分の1に縮まったか)を測定します。


動画(動きの激しい動画)
タイトルMystery of the Nile
情報1280*720、2082frames、1分26秒、3,837,598,360Byte
備考AviUtlを使ってYUY2未圧縮に変換
   

パソコンのスペック
OSWindows7 x64 Professional SP1
CPUIntel(R) Core(TM) i5-3470S CPU @ 2.90GHz Ivy Bridge
MBASRock H77 Pro4-M (Intel H77)
MemoryDDR3 1600 8GB(4GBx2 Dual Cannel)read=23.7GB/s write=12.2GB/s
SoftwareVC Test(2010年10月24日版)
備考CPUは4コア、マルチスレッドテクノロジーには対応していません。動作クロックを2.9GHz(定格)で固定し、省電力設定およびTurbo BoostはBIOSで無効化、動作クロックがテスト中に変動しないようにしています。
※ メモリーのread,writeはCrystalMark 0.9.126.425によるものです。 


コーデック一覧
コーデック名バージョン32bit 64bit 設定
AMV2MT2.20i×Y2標準可逆
AMV33.00i×-
Ut Video Codec Suite (ULY2)11.1.1デコード速度優先
圧縮率優先
Huffyuv2.1.1×Predict median(best)
Predict Left(fastest) 
Lagarith Lossless Video Codec1.3.27○ Mode:YUY2
 

【結果1】
YUY2可逆圧縮に対応した各コーデックの結果です。
表1は全て1スレッド、1コアで処理した場合の結果です。表2は4スレッド、4コアのマルチスレッドで処理した場合の結果です。

表1 シングルスレッドによる各コーデックの結果(1スレッド、1コア)
 Bit エンコードデコード圧縮比備考
時間FPS時間FPS
AMV2MT:Y2321.66 ms602 fps2.47 ms404 fps2.10R2と同じ
UT Video速優326.87 ms145 fps9.14 ms109 fps2.82デコード速度優先
UT Video速優645.69 ms175 fps8.75 ms114 fps2.82デコード速度優先
UT Video圧優327.00 ms142 fps14.46 ms69 fps3.41圧縮率優先
UT Video圧優646.03 ms165 fps14.34 ms69 fps3.41圧縮率優先
Huffyuv圧優324.95 ms202 fps34.79 ms28 fps2.69Predict median(best)
Huffyuv速優328.18 ms122 fps21.98 ms45 fps2.52Predict left(fastest)
Lagarith3211.17 ms89 fps17.05 ms58 fps3.81YUY2
Lagarith6411.04 ms90 fps18.25 ms54 fps3.81YUY2
AMV2MT:Y2:PC64648.24 ms121 fps10.82 ms92 fps2.10Proxy Codec64使用

※ Bitはvctest-x86でテストしたものを「32」、vctest-x64でテストしたものを「64」としています。
※ FPSは時間を元に1秒間に何フレーム処理できるかを計算で求めた値です。数値が高いほど優れています。
※ 圧縮比は未圧縮の動画に対し何分の1に圧縮できるかを示す値です。数値が大きいほど優れています。
※ AMV2MT:Y2:PC64はProxy Codec64を使い32bit用のコーデックをvctest-x64でテストした結果です。Proxy Codec64の処理が加わる分、処理時間は遅くなります。


表2 マルチスレッドによる各コーデックの結果(4スレッド、4コア)
 Bit エンコードデコード圧縮比備考
時間FPS時間FPS
AMV2MT:Y2320.54 ms1851 fps0.70 ms1428 fps2.10R2と同じ
UT Video速優322.06 ms485 fps2.45 ms408 fps2.82デコード速度優先
UT Video速優641.84 ms543 fps2.36 ms423 fps2.82デコード速度優先
UT Video圧優322.06 ms485 fps3.75 ms266 fps3.41圧縮率優先
UT Video圧優641.80 ms555 fps3.74 ms267 fps3.41圧縮率優先
Huffyuv圧優32-----マルチスレッド非対応
Huffyuv速優32-----マルチスレッド非対応
Lagarith327.10 ms140 fps12.86 ms77 fps3.81※スレッド数指定できず
Lagarith647.04 ms142 fps13.68 ms73 fps3.81※スレッド数指定できず
AMV2MT:Y2:PC64648.94 ms111 fps 10.08 ms99 fps2.10Proxy Codec64使用
※ Lagarithに付いてはスレッド数等を指定できません。そのため4スレッド、4コア全てを使った結果ではありません。



【結果2】
AMVビデオコーデックにおける各圧縮レベルの結果です。

表3 シングルスレッドによるAMVビデオコーデックの結果(1スレッド、1コア)
 レベルエンコードデコード圧縮比備考
時間FPS時間FPS
AMV2MTY10.83 ms1204 fps1.01 ms990 fps1.16YUY2可逆
Y21.66 ms602 fps2.47 ms404 fps2.10YUY2可逆
Y32.39 ms418 fps3.34 ms299 fps2.79YUY2非可逆
Y44.69 ms213 fps5.41 ms184 fps3.68YUY2非可逆 二次圧縮あり
AMV3S00.28 ms3571 fps0.27 ms3703 fps1.33YV12未圧縮
S10.58 ms1724 fps0.68 ms 1470 fps1.44YV12可逆
S21.25 ms 800 fps1.75 ms571 fps2.36YV12可逆
S31.56 ms641 fps2.40 ms416 fps3.25YV12非可逆
S43.29 ms303 fps4.47 ms223 fps4.27YV12非可逆 二次圧縮あり

※ AMV3の圧縮比はYUY2未圧縮に対する値です。

表4 マルチスレッドによるAMVビデオコーデックの結果(4スレッド、4コア)
 レベルエンコードデコード圧縮比備考
時間FPS時間FPS
AMV2MTY10.45 ms2222 fps0.39 ms2564 fps1.16YUY2可逆
Y20.54 ms1851 fps0.70 ms1428 fps2.10YUY2可逆
Y30.69 ms1449 fps0.94 ms1063 fps2.79YUY2非可逆
Y43.07 ms325 fps3.21 ms311 fps3.68YUY2非可逆 二次圧縮あり
AMV3S00.19 ms5263 fps0.22 ms4545 fps1.33YV12未圧縮
S10.38 ms2631 fps0.33 ms3030 fps1.44YV12可逆
S20.43 ms2325 fps0.50 ms2000 fps2.36YV12可逆
S30.50 ms2000 fps0.70 ms1428 fps3.25YV12非可逆
S42.11 ms473 fps2.64 ms378 fps4.27YV12非可逆 二次圧縮あり
※ AMV3の圧縮比はYUY2未圧縮に対する値です。


【グラフ】
表1から表4をまとめたグラフです。 
result20120904  

【注意事項】
AMVビデオコーデックの結果は試用版(ロゴ挿入処理あり)によるものです。製品版ではロゴ挿入処理がなくなる分ほんの僅か(約0.02ms)早くなります。
AMVビデオコーデックの可逆圧縮に付いて、試用版ではロゴが入る関係でVC Testのロスレスチェックが通りません。ロゴが入らない製品版ではロスレスチェックはOKとなります。




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

新しいPCを購入したので最新のCPUでビデオコーデックがどう動作するかベンチマークを行いました。
基本的には「ビデオコーデック・ベンチマーク2009」と同じですがWindows7 x64での動作になります。  

2012.9.5追記
この記事の公開当初2009年と同じ動画としていましたが、AviUtlを使ってWMV形式からAVI未圧縮のファイルへ変換する部分をミスり完全に同じ動画ファイルとはなっていませんでした。2009年と完全に同じ動画ファイルを使った再テストを行いましたのでそちらを見てください。
ビデオコーデック・ベンチマーク2012夏(2012.9.4修正版)

 
【測定条件】
ベンチマークはHD(1280*720)のビデオキャプチャ(実写)を想定しています。動画ソースはマイクロソフトのサイトからダウンロードしたWMV形式のファイルをAviUtlを使ってYUY2未圧縮に変換したものを使います。 (2009年の「動きの激しい動画」と同じになります
測定はUt Videoの作者が公開しているVC Test(2010年10月24日版)を使ってエンコード時間(圧縮にかかった時間)、デコード時間(復元にかかった時間)、圧縮比(未圧縮ファイルの何分の1に縮まったか)を測定します。


動画(動きの激しい動画)
タイトルMystery of the Nile
情報1280*720、2082frames、1分26秒、3,837,598,360Byte
備考AviUtlを使ってYUY2未圧縮に変換
   

パソコンのスペック
OSWindows7 x64 Professional SP1
CPUIntel(R) Core(TM) i5-3470S CPU @ 2.90GHz Ivy Bridge
MBASRock H77 Pro4-M (Intel H77)
MemoryDDR3 1600 8GB(4GBx2 Dual Cannel)read=23.7GB/s write=12.2GB/s
SoftwareVC Test(2010年10月24日版)
備考CPUは4コア、マルチスレッドテクノロジーには対応していません。動作クロックを2.9GHz(定格)で固定し、省電力設定およびTurbo BoostはBIOSで無効化、動作クロックがテスト中に変動しないようにしています。
※ メモリーのread,writeはCrystalMark 0.9.126.425によるものです。 


コーデック一覧
コーデック名バージョン32bit 64bit 設定
AMV2MT2.20i×Y2標準可逆
AMV33.00i×-
Ut Video Codec Suite (ULY2)11.1.1デコード速度優先
圧縮率優先
Huffyuv2.1.1×Predict median(best)
Predict Left(fastest) 
Lagarith Lossless Video Codec1.3.27○ Mode:YUY2
 

【結果1】
YUY2可逆圧縮に対応した各コーデックの結果です。
表1は全て1スレッド、1コアで処理した場合の結果です。表2は4スレッド、4コアのマルチスレッドで処理した場合の結果です。

表1 シングルスレッドによる各コーデックの結果(1スレッド、1コア)
 Bit エンコードデコード圧縮比備考
時間FPS時間FPS
AMV2MT:Y2321.63 ms613 fps2.48 ms403 fps2.10R2と同じ
UT Video速優326.86 ms145 fps9.16 ms109 fps2.79デコード速度優先
UT Video速優645.64 ms177 fps8.75 ms114 fps2.79デコード速度優先
UT Video圧優327.10 ms140 fps14.44 ms69 fps3.41圧縮率優先
UT Video圧優646.21 ms161 fps14.29 ms69 fps3.41圧縮率優先
Huffyuv圧優324.99 ms200 fps34.81 ms28 fps2.65Predict median(best)
Huffyuv速優328.21 ms121 fps22.00 ms45 fps2.50Predict left(fastest)
Lagarith3210.56 ms94 fps16.21 ms61 fps4.00YUY2
Lagarith6410.43 ms95 fps17.30 ms57 fps4.00YUY2
AMV2MT:Y2:PC64648.20 ms121 fps10.82 ms92 fps2.10Proxy Codec64使用
※ Bitはvctest-x86でテストしたものを「32」、vctest-x64でテストしたものを「64」としています。
※ FPSは時間を元に1秒間に何フレーム処理できるかを計算で求めた値です。数値が高いほど優れています。
※ 圧縮比は未圧縮の動画に対し何分の1に圧縮できるかを示す値です。数値が大きいほど優れています。
※ AMV2MT:Y2:PC64はProxy Codec64を使い32bit用のコーデックをvctest-x64でテストした結果です。Proxy Codec64の処理が加わる分、処理時間は遅くなります。



表2 マルチスレッドによる各コーデックの結果(4スレッド、4コア)
 Bit エンコードデコード圧縮比備考
時間FPS時間FPS
AMV2MT:Y2320.54 ms1851 fps0.71 ms1408 fps2.10R2と同じ
UT Video速優322.07 ms483 fps2.45 ms408 fps2.79デコード速度優先
UT Video速優641.80 ms555 fps2.37 ms421 fps2.79デコード速度優先
UT Video圧優322.06 ms485 fps 3.78 ms264 fps3.40圧縮率優先
UT Video圧優641.81 ms552 fps3.74 ms267 fps3.40圧縮率優先
Huffyuv圧優32-----マルチスレッド非対応
Huffyuv速優32-----マルチスレッド非対応
Lagarith327.11 ms140 fps12.89 ms77 fps4.00※スレッド数指定できず
Lagarith647.05 ms141 fps13.70 ms72 fps4.00※スレッド数指定できず
AMV2MT:Y2:PC64648.85 ms112 fps10.09 ms99 fps2.10Proxy Codec64使用
※ Lagarithに付いてはスレッド数等を指定できません。そのため4スレッド、4コア全てを使った結果ではありません。


【結果2】
AMVビデオコーデックにおける各圧縮レベルの結果です。


表3 シングルスレッドによるAMVビデオコーデックの結果(1スレッド、1コア)
 レベルエンコードデコード圧縮比備考
時間FPS時間FPS
AMV2MTY10.83 ms1204 fps 1.03 ms970 fps1.16YUY2可逆
Y21.63 ms613 fps2.48 ms403 fps2.10YUY2可逆
Y32.36 ms423 fps3.36 ms297 fps2.80YUY2非可逆
Y44.69 ms213 fps5.42 ms184 fps3.69YUY2非可逆 二次圧縮あり
AMV3S00.27 ms 3703 fps0.27 ms3703 fps1.33YV12未圧縮
S10.58 ms1724 fps0.67 ms1492 fps1.43YV12可逆
S21.24 ms806 fps1.75 ms571 fps2.34YV12可逆
S31.56 ms641 fps2.40 ms 416 fps3.22YV12非可逆
S43.29 ms303 fps4.52 ms221 fps4.22YV12非可逆 二次圧縮あり
※ AMV3の圧縮比はYUY2未圧縮に対する値です。


表4 マルチスレッドによるAMVビデオコーデックの結果(4スレッド、4コア)
 レベルエンコードデコード圧縮比備考
時間FPS時間FPS
AMV2MTY10.45 ms2222 fps0.39 ms2564 fps1.16YUY2可逆
Y20.54 ms1851 fps0.71 ms1408 fps2.10YUY2可逆
Y30.72 ms1388 fps0.95 ms1052 fps2.80YUY2非可逆
Y43.06 ms326 fps3.23 ms309 fps3.69YUY2非可逆 二次圧縮あり
AMV3S00.18 ms5555 fps0.22 ms4545 fps1.33YV12未圧縮
S10.38 ms2631 fps0.33 ms3030 fps1.43YV12可逆
S20.43 ms2325 fps0.51 ms1960 fps2.33YV12可逆
S30.49 ms2040 fps0.71 ms1408 fps3.21YV12非可逆
S42.06 ms485 fps2.67 ms374 fps4.22YV12非可逆 二次圧縮あり
※ AMV3の圧縮比はYUY2未圧縮に対する値です。


【グラフ】
表1から表4をまとめたグラフです。
codec benchi 2012

【注意事項】
AMVビデオコーデックの結果は試用版(ロゴ挿入処理あり)によるものです。製品版ではロゴ挿入処理がなくなる分ほんの僅か(約0.02ms)早くなります。
AMVビデオコーデックの可逆圧縮に付いて、試用版ではロゴが入る関係でVC Testのロスレスチェックが通りません。ロゴが入らない製品版ではロスレスチェックはOKとなります。



Atom330でHDキャプチャ その5

今回はAtom330でAMVビデオコーデックのベンチマークテストを行いました。1280*720のYUY2画像を入力しYUY2のまま可逆圧縮した場合にAtomのマルチコアやハイパースレッドテクノロジ(HTT)の効果を調べます。
基本的な測定方法は以前に行ったコーデックのベンチマークテストと同じです。

 

 

YUY2の動画をYUY2のまま可逆圧縮
Intel Atom330
動きの激しい動画(YUY2)

コーデック
Enc
(ms)
Dec
(ms)
圧縮
率(%)
補足
AMV2MT:R2(1)
10.90
8.75
47.7
CPUは指定せず1スレッドで処理。
AMV2MT:R2(2)
 6.74
5.06
47.7
〃  2スレッドで処理。
最も万能で使いやすい設定。
AMV2MT:R2(3)
8.73
6.06
47.7
〃  3スレッドで処理。
HTTの効果を期待してスレッド数を増やしても
CPUを指定しないとパフォーマンスは低下する。
AMV2MT:R2(4)
6.89
5.04
47.7
〃  4スレッドで処理。
AMV2MT:R2(CPU0+CPU1)
6.77
5.04
47.7
カスタム設定にしてCPU0とCPU1を使って処理。
CPUを指定せず2スレッドで処理する場合と同じ結果。
AMV2MT:R2(CPU0+CPU2)
6.75
5.04
47.7
カスタム設定にしてCPU0とCPU2を使って処理。
AMV2MT:R2(CPU0+1+2+3)
5.91
4.72
47.7
カスタム設定にしてCPU0~3のそれぞれを使って処理。
CPUを指定する事でHTTの効果を
少しだけ得られる。

Atom330 AMV2MT スレッド設定 

Enc:エンコード時間、圧縮処理にかかった時間を示す。
Dec:デコード時間、復元処理にかかった時間を示す。
圧縮率:未圧縮の何パーセントに縮まったかを示す。 


以前に行ったIntel Celeron420の結果

コーデック
Enc
(ms)
Dec
(ms)
圧縮
率(%)
補足
AMV2MT:R2(1)
5.31
5.89
47.7
CPUは指定せず1スレッドで処理。

 Atom330とCeleron420を比較すると、Atom330の方がコア数やHTTにより有利になると思っていましたが、結果はCeleron420の方が1コア1スレッドでも高速な結果となりました。
なお、AMVビデオコーデックはハイパースレッドテクノロジを想定して設計されていないため、HTTの効果は殆ど得られないことも解りました。

 

付録測定条件

タイトルMystery of the Nile
情報1280*720、2082frames、1分26秒、3,837,598,360Byte
備考AviUtlを使ってYUY2未圧縮に変換



パソコンのスペック
 
PC1
Celeron
PC2
Atom
CPU
Intel Celeron 420
(Conroe-L) 1.6GHz
Socket 775LGA
Intel Atom330
(2core,HTT) 1.6GHz
 
Chipset
i945G/GZ
Intel 945GC + ICH7
Memory
DDR2-800, 1GB (single)
read=3.3GB/s
write=1.2GB/s
DDR2-533, 2GB(single)
 
OS
Windows2000
Pro SP4
Windows7 x86
Ultimate
補足
デスクトップPC
ミニキューブ

 



AMVコーデック/PrxyCodec64のインストールについて

以下の条件でインストールが失敗する事が判りました。

・Windows7で且つインストール先のパスに日本語が含まれている場合

Windows7(Vistaは未確認)にインストールする場合は日本語パスの含まれるフォルダーにはインストールできません。特に理由が無い場合はデフォルトのパスにインストールしてご利用ください。


次は小物

鋭意製作中のアプリがもうじき完成します。
内容は64bitアプリから32bitコーデックを扱えるようにするプロキシコーデックです。

AMVコーデックの64bit版に関する要望を頂いていますがそれはちょっと無理なので、姑息な手段を用いての対応となります。
その代わりAMVコーデックだけでなくほかの32bitコーデックも64bitアプリで使えるよ。  

プロキシ概要図


ご要望を頂いた方に人柱版を送って、問題なさそうなら週末あたりに公開を予定しています。


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

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

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



ホームページ
カテゴリ
最新コメント
カレンダー
08 | 2017/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 ビデオキャプチャ AMVコーデック アマレココ アマミキ! コーデック SC500 動画配信 ファンタジーリモート アマレコライト プラグイン AMV4 SC512 ライブ機能 デスクトップキャプチャ AVX2 FAQ リモートソフト 質問コーナー ニコニコ動画 DirectShow HDキャプチャ 組み換え 4K レゴ 遅延 可変再生速度 解説動画 LEGO XL2420T ベンチマーク Intensity AMV2MT 120Hz 倍速液晶 GV-USB2 アマステ 液晶モニター PS4 Pro デインターレース 32ZP2 Shadow VideoKeeper2 31024 RDT233WX-Z ffmpeg GV-USB AVX Play Alternate designs 31006 RGBキャプチャ RYZEN SD-USB2CAP4 XCAPTURE-1 DirectShowFilter キャプチャーツール Livetube シンクライアント イベント AtomでHDキャプチャ プレビュー 擬似NTSCキャプチャ IntensityPro SD-USB2CUP4 額縁遅延 MPC ハイパースレッディングテクノロジー HT インストール OBS QSV NVEnc 31021 フィギュア Kabelake SSE MonsterX3A XCapture-1 オーバーレイ 音ズレ 録画 HDMI HDCP 32ZP32 SKnet REGZA 液晶テレビ 倍速駆動 リプレイ機能 モノステ ZP3 倍速補完処理 MP3 Haswell 電源オプション LameACM 音遅延 ゲームスムーズモード MonsterXU3.0R DC-HD1 

ブログ内検索
月別アーカイブ
アマレココに関するリンク
お世話になっているソフトのリンク
RSSリンクの表示
管理画面
  • 管理画面
  • 上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。