高解像度でキャプチャするには

1440x1080にリサイズしてエンコードするのなら、キャプチャする際にはなるべく高解像度の方が画質が綺麗ですよという書き出しで今回のブログを書く予定でしたが、前回のブログ「キャプチャ解像度に関する検証」で、東方Projectのゲームは960x720よりも640x480でキャプチャした方が画質が綺麗である事が検証されたため少々困ったことに(汗　PCゲームによっては高解像度に設定した方が画質が綺麗なものもあるので、今回はなるべく高画質・高解像度でドロップフレームなしでキャプチャにする方法について紹介します。

まず、私が使っているPCのスペック、キャプチャソフト、キャプチャコーデックについて。

OS：WinXP SP2、CPU：Core 2 Duo E8400(3.00GHz)、メモリ：4GB
キャプチャソフト：Display2AVI 1.1.0
キャプチャコーデック：上記ソフト付属のRUnlength Sato Huffman(RuSH)

今回は960x720の高解像度＆60fpsの条件でコーデックの種類と設定を変えてキャプチャします。目標はドロップフレームなしです。まずは、今まで使ってきたRUnlength Sato Huffman(RuSH)のコーデック。東方地霊殿の設定で960x720のウィンドウモードで起動して60fpsでキャプチャすると、最初からドロップフレームが発生してしまいました。Display2AVI上のCPU使用率を見ると40%前後で、ゲーム中のフレームレートが60fpsをなかなか維持できずによく60fpsを下回る時がありました。キャプチャ1分間のファイル容量は約2.79GB(47.6MB/s、ドロップフレーム有)。

今度はサイズそのままで30fpsに落としてキャプチャしてみたところ、ドロップフレームは発生しませんでした。こちらもDisplay2AVI上のCPU使用率は30%前後で、ゲーム中のフレームレートはギリギリ60fpsを何とか維持しているような感じ。キャプチャ1分間のファイル容量は約2.32GB(39.6MB/s)。60fpsキャプチャでフレームレート低下の原因がCPU処理速度がボトルネックなのか、HDD転送速度がボトルネックなのか判断が難しいです。

ハードディスクの書き込み速度について調べるため、CrystalDiskMarkを使い、キャプチャデータを保存するパーティションの各種転送速度を調べてみました。



-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

Sequential Read : 113.323 MB/s
Sequential Write : 111.836 MB/s
Random Read 512KB : 43.937 MB/s
Random Write 512KB : 65.496 MB/s
Random Read 4KB (QD=1) : 0.642 MB/s [ 156.6 IOPS]
Random Write 4KB (QD=1) : 1.535 MB/s [ 374.7 IOPS]
Random Read 4KB (QD=32) : 0.699 MB/s [ 170.8 IOPS]
Random Write 4KB (QD=32) : 1.527 MB/s [ 372.7 IOPS]

Test : 1000 MB [F: 0.1% (0.1/81.1 GB)] (x5)
Date : 2011/08/13 2:16:11
OS : Windows XP Professional SP2 [5.1 Build 2600] (x86)


サンプルとして、

640*480*32bit*60fpsの非圧縮で大体73MB/sの帯域が必要

非圧縮
1280*720p 　59.94fps　106.8MB/s　6409.7MB/m　375.6GB/h
1920*1080i　29.97fps　100.3MB/s　6020.5MB/m　352.8GB/h
1920*1080p　59.94fps　120.0MB/s　7199.9MB/m　421.9GB/h

代表的な可逆圧縮コーデックを使うと最低でも容量が非圧縮の半分以下になるので、このベンチマークテストを見る限りだと書き込み速度は十分に足りていると思うので、そうなるとCPUのパワー不足が濃厚な可能性が高いです。

そこで、高速だけどそこそこ高圧縮な可逆圧縮コーデック！「Ut Video Codec Suite」を使ってキャプチャしてみる事にしました。結果から先に言いますと、デコード速度優先・圧縮率優先のどちらを選んでも、容量とともにRuSHとほぼ同じで、CPU使用率については状況によってUtの方がCPU使用率が高くなり、こちらも60fpsでキャプチャするとドロップフレームが発生しました。うーむ・・・。Huffyuvでもキャプチャしようと思いましたが、Display2AVIではなぜか選択可能なコーデック一覧に項目が出てこなくて選べませんでした。

いろいろ調べた結果、AMVビデオコーデック(シェアウェア)が画質と軽さのバランスが良く、同じコーデックで圧縮率がいろいろ選べるとの事なので、このコーデックを使って検証します。AMVビデオコーデックは元々アマレココというキャプチャソフトに付属していたコーデックなのですが(今は付属していない)、アマレココの対応OSがWinXPの場合SP3となっています。私のパソコンはWinXP SP2で多分使えるだろうと思って、アマレココとAMVコーデックをインストールしてアマレココを立ち上げようとすると、

AmaRecCo.exe エントリ ポイントが見つかりません

プロシージャ エントリ ポイント GetLogicalProcessorInformation がダイナミック リンク ライブラリ KERNEL32.dll から見つかりませんでした。

というエラーメッセージが表示され、OK押しても何度も同じエラーメッセージが表示されます。何度かOKを押したところでアマレココが立ち上がり、AMVコーデックの設定画面に映ろうとするとまた同じ現象が発生します。どうやら、WinXP SP3じゃないとこのメッセージが出るようです。以前SP3にアップグレードした時に、IE系のWebブラウザのアクセスが重くなって元に戻したのですが、今回もう一度SP3のアップデートに挑戦してみました。元に戻せるようにAcronis True Imageでバックアップを取り、SP3のファイルをダウンロードしてきてアップデート開始！・・・、「インストールを終了しています　　詳細　クリーンアップを実行しています」のまま進まない。



暫く待っても様子が変わらず、HDDのアクセスランプは一定間隔で点灯するだけで作業している様子が無かったのでシャットダウンし、手動で再起動したところ無事立ち上がりました。自動更新によるセキュリティ更新プログラムを45個ほど当てて再起動してアマレココを起動したところ、今度はエラーメッセージが出なくなりました。しかし、以前SP3を当てた直後に発生したIE系のWebブラウザのアクセスが重くなる症状が出てしまいました。私はDonut RAPTというIE系のタブブラウザを使っているのですが、リンク先にアクセスしてページを切り替えた直後に暫くプチフリーズしてしまって操作を受け付けなくなってしまいます。新たなページにアクセスする際に高頻度でこの症状が出るので、これが非常にストレス。我慢できなくってAcronis True ImageでSP2に戻してしまいました。

その後、インストールしている「AVG Anti-Virus Free Edtion 2011」というアンチウイルスソフトが悪さをしているのかなと思い、このソフトをアンインストールしてからSP3のパッチを当てることに。そしたら、例の「インストールを終了しています　　詳細　クリーンアップを実行しています」の画面で、今度はHDDのアクセスランプが付きっぱなしになってしまいました。暫く様子を見てましたが、これまた終わる気配が無かったので、手動でシャットダウンして再起動。今度は以前よりページが切り替える際のプチフリーズ時間が短くなりましたが、それでも気になります。タスクマネージャーのプロセスを監視したところ、アクセスした直後にCPU使用率が60%に上がり、プチフリーズしている間はCPU使用率が高いままになっていました。SP2だと一瞬50%ほどになりすぐに数%に落ちるのに。PCに詳しい友人に聞いたところ、その現象ならIEのコンポーネントバグなのでSP3適応すると回避できなくて、修正予定も無いため、SP3を使わないかWin7、Vistaに移行しない限り解決しない問題と回答が帰ってきたので、SP3を使うのを諦めて、結局SP2に戻して使うことにしました。

アマレココを使わなければ問題ないと思って、いつも使っているキャプチャソフト「Display2AVI」でAMVコーデックを使おうと思って同ソフトを立ち上げると、こっちも

プロシージャ エントリ ポイント GetLogicalProcessorInformation がダイナミック リンク ライブラリ KERNEL32.dll から見つかりませんでした。

のエラーメッセージが。何度かOKすれば使えるだろうと思って強引にAMVコーデックを使い検証しました。AMVコーデックには2種類あって、AMV3がどのモードでもYV12に色空間を圧縮するのに対し、AMV2は入力と同じ形式のまま、あるいはYUY2を使って圧縮することができます。レジストしないとキャプチャした動画にAMVのロゴが入るものの、機能そのものはフルに使うことが出来るので、検証するだけなら未レジストで十分です。AMV2とAMV3のコーデックの設定画面はこんな感じ。





では、東方地霊殿を960x720のウィンドウモードで立ち上げ、リプレイを60fpsで1分間録画する条件で、コーデックを圧縮率を変えてキャプチャして検証してみました。

codec	モード	画質	圧縮率	処理速度	圧縮 ﾌｫｰﾏｯﾄ	1分間録画の ファイル容量	CPU 使用率	ﾄﾞﾛｯﾌﾟ ﾌﾚｰﾑ
RuSH	(60fps)					2.79GB (47.6MB/s)	40%	×
RuSH	(30fps)					2.32GB (39.6MB/s)	30%	○
AMV2	R2:標準可逆	可逆	約1/3	普通	RGB YUY2	2.20GB (37.5MB/s)	25%	×
AMV2	R3:標準	高	約1/4	普通	YUV444 YUY2	1.84GB (31.4MB/s)	28%	○
AMV3	S2:可逆標準	可逆	約1/6	普通	YV12	1.17GB (20.0MB/s)	18%	○

※補足　ドロップフレーム　○：コマ落ちなし(ドロップフレーム無)、×：コマ落ちあり(ドロップフレーム有)

AMV2 R2ですが序盤はドロップフレームが無かったのですが、45秒を過ぎた辺りからドロップフレームが発生、AMV2 R3とAMV3 S2はドロップフレームは発生しませんでした。HDDは円盤状のメディアを回転させてヘッドを移動させることでデータの読み書きを行なう構造から、外周にあるデータほど(1周のデータ量が多いことから)ヘッドの移動量が少なくて線速度も速いので、外周では読み書きが高速に行なわれ、逆に内周ほど遅くなるという性質があります。



HD Tune: ST3500320AS Benchmark

Transfer Rate Minimum : 51.6 MB/sec
Transfer Rate Maximum : 109.7 MB/sec
Transfer Rate Average : 84.3 MB/sec
Access Time : 14.0 ms
Burst Rate : 107.9 MB/sec
CPU Usage : 4.9%


私はHDDのパーティションを切って、読み書きが高速に行われる外周の領域にキャプチャ専用のパーティションを作成して使用しています。AMV R2にキャプチャの後半でドロップフレームが発生したのは、途中で書き込みの速度が間に合わなくなって発生したのが原因だと思います。これと、AMV2 R2の方がAMV3 R3よりもCPU使用率が低かったのにもかかわらずドロップフレームが発生した事から、CPU処理速度よりもHDD転送速度がボトルネックになってドロップフレームが発生したという結果となりました。ただ、CrystalDiskMarkのSequential Writeでは111.836 MB/s、さらにHD TuneでTransfer Rate Minimum : 51.6 MB/secという数字が出ているのにもかかわらず、データ転送量37.5MB/sでHDDへの書き込みが間に合わないというのは数値的に納得がいきませんが。HDDに書き込むまでの経路のどこかでボトルネックが発生しているのか？また、RUnlength Sato Huffman(RuSH)コーデックだと、30fpsで約2.32GB(39.6MB/s)でドロップフレームが(ギリギリ)発生していない事から、このデータ転送量以上はドロップフレームが発生すると容易に決める事ができません。

RUnlength Sato Huffman(RuSH)コーデックは、AMVコーデックと比べると圧縮率が低くてデータ転送量が多いのがよくわかります。AMV3コーデックは、S2:可逆圧縮でもCPU使用率が低くてデータ転送量が少ないので、とても優秀なコーデックですね。960x720の60fpsでこの結果ですから、YouTubeにアップロードする前提で640x480の30fpsでキャプチャすれば、マシンパワーがあまり高くないパソコンでもドロップフレームが発生せずにキャプチャできると思います。色空間がRGBではなくYV12ですが、YouTubeにアップロードするのならそれほど問題にならないでしょう。

以上の事から、私の環境下ではCPU処理速度よりもHDD転送速度がボトルネックになる事がわかり、高解像度・高フレームレートでキャプチャするには、RUnlength Sato Huffman(RuSH)コーデックよりもAMVコーデックの方がドロップフレームが発生しにくいという結果となりました。厳しい条件下でのキャプチャではコーデック選びと設定が更に重要になり、条件によってはハイスペックなパソコンも必要になってきますので、自分のパソコンのスペックと相談してキャプチャする条件を決めましょう。

フォトギャラリー
https://minkara.carview.co.jp/userid/507493/car/488014/2733571/photo.aspx