・ 最終更新日 2007年8月4日
より忠実で軽快な映像を得るために、キャプチャやプレビュー時に行われる処理の分析を試みました。
分析はIntensity ProとGameSwitchの組み合わせによるオールデジタル処理環境で行いましたが、コンポーネント入力や他のキャプチャ
ボードでも共通するところはあるので、参考になればと思います。
○ ソース
○ ふぬああによる非圧縮キャプチャ
○ ふぬああによるHuffyuv可逆圧縮キャプチャ
○ ふぬああによるプレビュー（ビデオフィルタなし）
○ ふぬああによるプレビュー（Color Space Converter適用）
○ Media Player Classic Homecinemaによるプレビュー
○ 気になる点
○ まとめ
「Intensity Pro レビュー」参照
・使用ソフト
ふぬああ ver2.5.6.3
AviUtl ver0.99
GraphEdit （ふぬああのフィルタグラフ推定などに使用）
Media Player Homecinema ver6.4.9.0-Mod Casimir666 v1.0.9.0 （フィルタ入出力ピンのメディアタイプチェックなどに使用）
 |
 |
 |
|
 |
|
| ・ RGB ・ 0-255 |
・ HDYC4:2:2 ・ 0-235,240 ・ BT.709 |
1280×720、60fpsレンダリングで、それと同じ信号をHDMI（RGBフルレンジ）出力します。
PS3から出力された信号はIntensity ProでHDYC4:2:2にハードウェア変換されます。
HDYCというのはBlackmagic社製品特有のフォーマットで、データ構造はUYVYと同じですが、RGB→UYVY変換の際、
BT.709の変換式を用いています。（参考：FOURCC.org）
以後、各ケースにおいて、この信号からどう変わっていくかを分析します。
画質のチェックはゲーム中の静止シーンで行います。
|
 |
|
 |
|
 |
|
 |
| ・ UYVY4:2:2 | ・ 内部YUV4:4:4 | ・ RGB32 ・ 0-255 ・ sRGB |
AviUtlに読み込ませるとき、まずBlackmagic Design Decoderによりデコードされますが、映像データに何ら変化はないはずです。
AviUtlではフィルタを何もかけなければ左オリジナルの色補間がなされますが、データに忠実な表示を得るためにYUY2フィルタをかけています。
ディスプレイでの表示を行うにはディスプレイのモードであるRGB32に変換する必要があります。
この変換で、上の画像左下のような破綻が数箇所見られました。
これはYUV→RGB変換時の計算で0-255を逸脱してしまったときに見られる現象です。
この破綻を除けば、後述のBT.709変換結果とほとんど同じです。
BT.709色域とほぼ同じ色域を持つ規格としてsRGBがあります。（参考：Mac.una Matata!!））
ここでの破綻は、YUV→RGB変換の式にsRGBのものが使われ、BT.709とsRGBとのわずかな差が祟ったのではないでしょうか？
なお、AviUtlではなくQuickTime Proで読み込むと、この破綻は起きませんでしたので、データ自体は大丈夫です。
（QT Proでは破綻はないものの、ガンマ調整のためか暗部の諧調が低いです）
|
 |
|
 |
|
|
|
|
|
|
|
|
| ・ UYVY4:2:2 | ・ YUY2 4:2:2 | ・ 内部YUV4:4:4 | ・ RGB32 ・ 0-255 ・ sRGB（?） |
このAVI Decompressorは先述のBlackmagicDesign Decoderを呼び出してUYVYに変換させているものと思われます。
Huffyuvは変換された映像データをそのままハフマン符号化するだけなので、AVIファイルには劣化無しで保存されます。
AviUtlに読み込ませようとすると、HuffyuvコーデックがAviUtlに渡せるYUY2 4:2:2にします。
Huffyuvの挙動はHuffyuvのログ表示機能で確認しました。
次にAviUtlで内部YUV4:4:4変換、表示のためのRGB変換と続きますが、このときAviUtl ver0.99特有の色ゴースト現象が起きます。
この現象はYUY2フィルタや4:2:2→4:4:4補間で回避することができます。（上の画像はYUY2フィルタを適用）
その他、非圧縮時との違いは、変換破綻が見られないのと、色が異なるところです。
赤が若干黒っぽくなった感じです。
これは後述のBT.601変換結果とほとんど同じです。
このBT.601変換がどこで行われているかが分かりません。
RGB→YUV変換があると考えられるのはAviUtlが表示用のRGBを用意するときしか考えられませんが、そうすると、先の非圧縮キャプチャの説明と
辻褄が合わなくなります。
どこかに見落としや勘違いがあるのかもしれません。
|
|
|
 |
|
|
| ・ UYVY4:2:2 | ・ RGB32 ・ オーバーレイ |
当方の環境では色補間は無く、初期設定では16-235,240レンジでコントラストの低い映像になりました。
グラボのドライバで画質を調整してやれば、フルレンジで鮮やかな画質にできます。
ハーフHDサイズ時の動きは滑らかで60fpsの動きです。
フルスクリーンになると、若干フレームレートが落ちます。
ゲームに支障が出るほどではありません。
|
|
|
 |
|
|
|
|
| ・ RGB32 ・ 0-255 ・ sRGB ・ 色補間（右） |
非圧縮キャプ映像のAviUtl表示と、破綻部を含め、まったくと言っていいほど同じです。
このColor Space Converter、実は何も仕事をしていません。
このフィルタはRGBしか受け付けないので、AVI DecompressorがYUV→RGB変換し、それをスルーさせているだけです。
一度RGB32になれば、後はディスプレイまで変換なく進みます。
映像に変換破綻が見られることから、AVI Decompressorは例のごとくBlackmagic Design Decoderを使ってUYVY4:2:2にし、それをsRGB変換式で
RGB32にして後のフィルタに渡したのでしょう。
（Blackmagic Design DecoderはRGB32も吐けるとDecklink DirectShow SDK 5.6のヘルプファイルに書いてありますが、もしそうならBT.709変換
した破綻のない映像になるはずです）
なお、SDK付属のサンプルコードを見るとDVプレビュー時に、AVI DecompressorとColor Space Converterの間にSmart Tee（Preview）を挟んだ
グラフを構築していました。
公的なやり方のようです。
このColor Space Converterを使った方法はフレームレートに問題があります。
ふぬああのビデオフィルタに設定すると、ハーフHDサイズ時、CPU使用率は30%ほどですが、60fpsと十数fpsとを繰り返す動きになりました。
フルスクリーンにすると、CPU使用率が片コアをほぼ占有する50%になってコマ落ちと酷い遅れを生じました。
GraphEditだと、ハーフHDサイズでは問題なく表示されますが、少しサイズを大きくするとコマ落ちが発生します。
それじゃあ、とPC画面の解像度を1280×800にしたところ、ハーフHDサイズでもコマ落ちが発生しました。
CPU使用率は低いですが、グラフィックボード側に問題がありそうです。
|
|
|
 |
|
|
||
| ・ UYVY4:2:2 | ・ RGB32 ・ BT.709 ・ 0-255 ・ 色補間（左右） |
Haali Video RendererはHaali Media Splitterのインストールで登録されるDirectShowフィルタです。
これをレンダラーの指定が可能なMedia Player Classic Homecinemaで利用し、プレビューします。
Haali Video RendererはUYVYを受けますが、それをディスプレイに表示できるRGB32に変換する際、変換方法の指定ができます。
プリントスクリーンで取得しました。
非圧縮キャプ映像のAviUtl表示やColor Space Converterを適用したふぬああプレビューとほぼ同じですが、変換破綻はありません。
なお、色信号の補間は左オリジナル、右補間ではなく、左右どちらも補間処理により更新されています。
個人的に左オリジナルじゃないのは残念ですが、このレンダラーは拡大したとき、Video Rendererより若干シャープなのでトレードオフです。
Huffyuvキャプ映像のAviUtl表示とほぼ同じです。
Intensity ProでBT.709の変換がなされることから、忠実再現という点ではBT.709を選ぶべきですが、好み次第ではBT.601もアリだと思います。
次にフレームレートを見てみます。
Haali Video Rendererはfpsを表示できるOSD機能がありますので、これを利用します。
BT.709変換でサイズはハーフHDドットバイドット、これでフレームレートは59fps出ており、可能な中では最も再現度の高い状態かと思われます。
ただ、当方の環境ではフルスクリーン表示したときに50数fpsになってしまうのが残念です。
CPU使用率は40%ほどなので、グラフィックボード側の問題のようです。
フルスクリーンでの動きが良いのはColor Space ConverterとVMR9(windowed)の組み合わせです。
ふぬああのときは正常に動作しませんでしたが、MPC Homecinemaでは問題無く動きます。
レンダラーのプロパティで見ると約56fpsで、変動も小さいため先のケースよりも滑らかに感じます。
画質的に厳密には破綻が起こる可能性がありますが、無いと言っていいほど気付きにくいものですし、それを除けばBT.709変換と変わりません。
フルスクリーンでゲームを楽しむのに最も良いプレビュー方法だと思います。
少し特殊ですが、デスクトップ解像度を1280×800にして上記二つのフルスクリーン時フレームレートとの違いをチェックします。
モニタの3007WFP-HCは最大解像度が2560×1600ですが、これの縦横半分の1280×800に設定すると、データの1ピクセルをモニタの4ピクセル
で表示する仕様のため、ハーフHD動画をフルスクリーンかつドットバイドットなクオリティで視聴することができます。
このときのBT.709変換フルスクリーンでの動きはとても滑らかで、OSD機能でfpsをチェックしたところ55〜59fpsで変動していました。
Color Space Converter時の動きも同様でした。
解像感を忠実再現しつつ画面いっぱいに映せるのは嬉しいですが、アンチエイリアスがかかっている次世代機映像のような趣ある映像には
不向きに感じました。
・ 解像度によってBT.601変換式とBT709変換式を使い分けるDirectShowフィルタがある？
・ Windows Vistaに付くレンダラーはBT.709選択が可能？
キャプチャに関しては非圧縮時とHuffyuv可逆圧縮時とでAviUtlの表示が異なる点に注意が必要です。
色にこだわる場合は色域変換フィルタを使うなどして調整すると良いでしょう。
プレビューに関しては、Media Player Classic Homecinemaで適切なフィルタを適用して行うのがオススメです。