ゲームエンジンやエディタを作っているとどうしてもフレーム遅延が気になってしまう。世間には HDMI → NTSCビデオ変換器 がそれなりにあるので、それを使って、 ビデオ信号をオーディオ信号として突っ込む ことでオーディオ信号レベルでフレーム遅延を測定できないだろうかと考えた。
オーディオ信号を使いたいのは、既にエンジンのインテグレーションテストとしてオーディオの音飛びテスト等の機材を用意していて、その機材を可能な限り流用してビデオ側のテストも実施したいため。
※ DO NOT TRY THIS AT HOME 。音声信号でない信号を音声として人間が聴取すると聴覚に 回復不能なダメージを受ける 可能性がある。また、デバイスが想定していない規格違いの信号を入力するとデバイスが 破損 する可能性がある。
コンポジットビデオ信号をオーディオ入力に入れる
つまり:
実際にAudacity(オーディオ編集ソフト)でキャプチャしたコンポジットビデオ信号がこちら:
この波形のタイミングでは、まっしろな画面を映している。
まっしろといっても周囲に黒枠が出ている。これはHDMI → コンポジットビデオ変換器の都合。
まっくろな画面では以下のようになる:
コンポジット映像信号では、黒は振幅が小さく観察される。つまり、この波形の差によって画面が白か黒かをオーディオ入力から判別することができ、もう片方の音声チャンネルに基準信号(ボタンとかゲームエンジンの音声出力とか)を入力することで、表示と基準信号間の遅延を測定できる。
波形の解釈
Audacityで観察できる波形は、VBLANK期間と実際の映像信号区間に分けられる:
このVBLANK期間の信号内容は例えば、 テクトロニクスのSD/HD デジタル・ビデオ信号測定入門 で解説されているように、 20ラインぶんの同期期間 となっている。
(オーディオ入力はオーディオ信号を想定したAC結合になっているので、波形はどうしてもゼロに向かうほうに歪んでしまう。いやまぁ ビデオ信号もAC結合なことが多い けど。。)
ビデオ信号における1秒あたりの走査線数が 525本 x30 = 15750 本 、 この20ラインぶんのVBLANK区間の長さは48kHzでサンプリングすると 20 本 x 15750 ÷ 48000 = 6.5625 サンプルに相当することがわかる。実際にAudacity上でサンプルを数えてみると 8 サンプル程度となっていて、おおよそ一致している。
実験
今回は、普通のSDL2プログラムからビデオとオーディオを出力し、その位相差を観察したい。ビデオ出力とオーディオ出力がよく同期していると言えれば、ビデオ出力と操作の遅延ではなく、オーディオ出力と操作の遅延を測定すればよくなり、より安価かつ安定して測定できることになる。
機材
機材は適当に手元の在庫で用意した:
- HDMI → コンポジットビデオ: VGA-CVHD3 (サンワサプライ) https://www.sanwa.co.jp/product/syohin.asp?code=VGA-CVHD3
- アナログオーディオ入力: 400-MEDI017 (サンワサプライ) http://direct.sanwa.co.jp/ItemPage/400-MEDI017
- USB → HDMI出力: USB-RGB3/H (アイ・オー・データ機器) https://www.iodata.jp/product/av/graphicsboard/usb-rgb3h/
- 出画確認用のアナログビデオキャプチャ: GV-USB2 (アイ・オー・データ機器) https://www.iodata.jp/product/av/capture/gv-usb2/
ソフト
適当にSDL2で書いた。
30フレームに一度2フレームだけ画面を白く光らせ、更にその期間の前半1フレームに1000Hzの矩形波を出力する。
結果
今回は左チャンネル(白コネクタ)に映像信号(黄プラグ)を差し、右チャンネル(赤コネクタ)に音声信号左チャンネル(白プラグ)を差した状態で、Audacityを使って録音した。
結果、左チャンネルと右チャンネルはほぼ同じ周期で信号を検出しており、 SDL2の出力は音声とビデオの同期が比較的良好 ということがわかった。
ただし、実際にはビデオ・オーディオ共にフレーム落ちが観察される。
ビデオのフレーム落ち
理想的な状況では、2 フィールドが白画面となることが期待される。しかし、実際には時折3 フィールドぶんが白いこともある。
3フィールドぶんが白くなるのはコマ落ちのせいと考えられるが、もう少しマジメにタイミングを合わせた方が良いかもしれない。
オーディオのフレーム落ち
SDLのオーディオ出力は、ユーザのコールバックがSDL側が与えたオーディオバッファ(= オーディオフレーム )全体を埋める形で実装されている。このため、今回のソフトではオーディオフレームのサイズが測定単位となる。
SDLを特に何も指定しない場合、Windows上では512サンプルのオーディオフレームが使用される。このため、実際に観察されるオーディオ信号も512サンプルぶんになる
(長さが1030サンプルある)
しかし、SDLはたまに1024サンプルを埋めさせてくるため、その場合はオーディオ信号の長さも倍になる。これがオーディオのフレーム落ちで、これも測定精度低下の要因になる。
かんそう
一応手元にはHDMI → コンポーネント信号もあるので、これを使えばNTSCのインターレースと戦う必要は無くなるためもうちょっと正確な測定が実施できるのではないかと思う。ただ、今度はHDCPと戦う必要はある。
HDMI → コンポジット変換でWebブラウズしたらVHSっぽくならないかなと思ってやってみたけど、CG系のにじみはかなりそれらしいが動画はなんかDVDっぽくてそれほど古い感じは出なかった。Amazonで買える変換はどれもS端子が無いので色のにじみがすごい。
実際の遅延を精密に測定したいとなると、オーディオキャプチャの誤差がおそらく無視できなくなる。経験的に、オーディオクロックは 1% とかズレているケースもあるため何らかの方法で補償する必要があるかもしれない。
また、一般的なオーディオ入力がたかだか2chなのも問題となる。片方のチャンネルが基準信号で占有されてしまうため、オーディオ入力デバイス1つで1chぶんの測定しかできない。たぶんFPGAとかで専用の測定ジグを作る方が効果的だろう。