MV-300 実験

FastTrak66 + 無圧縮キャプチャ

目的

IDE-RAID カードである Promise FastTrak66 を利用して YUV16, 704x480, 29.97 fps に必要な 20M/sec の転送速度を確保し、ドロップフレームの発生しないキャプチャ環境を構築する。

方法

Promise FastTrak66, IBM DJNA372200 x 2, により RAID-0 を構築。20M/sec を超えるデータ書きこみ速度を持つドライブを準備する。

MV-300 から YUV16 無圧縮形式、704x480, 29.97 fps 指定の設定にて、上で構築した RAID ドライブにビデオキャプチャを行い、ドロップフレーム無しの環境が構築可能か検証する。

実験環境

• ASUS P3B-F（440BX Main Board）
• Intel PIII 500 （定格動作）
• Matrox Milleniam G400 DH 32M（BIOS 1.5, PowerDesk5.30）
• AverMedia MV-300（PCI スロット 2, Driver 1.30）
• Promise FastTrak66（PCI スロット 3, Driver 1.13)
• Creative SoundBlaster PCI64（PCI スロット 4, Driver 4.05.1051）
• IBM DJNA372200 x 2（FastTrak66 にて RAID-0 利用）
• Microsoft Windows98
• Microsoft VidCap32 (Version 4.00)
• VideoShot (Version 1.14)

予備実験

FastTrak66 + (DJNA372200 x 2) RAID-0 の構成で、どれだけのデータ書きこみ速度が達成できるかを確認するため、HDBench2.61 を利用し 512M の設定でディスクのベンチマークを取る。

結果、READ: 34970 KB/s, WRITE: 32527 KB/s と充分な書きこみ速度を達成できている事が確認できた。

実験結果

失敗。MV-300 の PCI コントローラ Zoran ZR36067 の DMA 転送能力の上限がボトルネックとなり、YUV16 での 704x480 29.97 fps ドロップフレーム無しのキャプチャは不可能であることが判明した。

測定値

オーバレイオフ、29.97 fps 設定で 4 秒、8 秒、16 秒、32 秒間のキャプチャを行い各条件でのドロップフレーム数を記録し平均を取ってフレームレートの設定値から引き、実効 fps を求める。

上記測定値より 実効 fps は 19.59 fps と求まる。またキャプチャ中 システムモニタ で CPU 負荷を記録していたが 50% を超えることは無かった。

考察

まず、キャプチャ時の CPU 負荷の低さから、この結果は FastTrak66 がボトルネックとなっているわけでは無いと判断する。何故ならば、ベンチマーク時やファイルコピー時など、FastTrak66 で構成した RAID に対して無制限にデータを書きこむ場合、基本的に CPU 負荷は 100% に張り付き、余裕の無い状況まで行くからである。

では、何が原因かと考えると、MV-300 の使用している PCI コントローラ ZR36067 がボトルネックとなっていると考える。

その根拠として、ZR36067 のデータシート（PDF）1 ページ目にある "Bidirectional DMA transfer of compressed data up to 11M bytes/sec" という記述がある。現実には 12.63M bytes/sec の転送速度が達成できているが、この数字はデータシートの記述と非常に近い。またここに限界があるとすれば Motion JPEG の AVI ファイルをハードウェアを通して再生した場合にインタレースが目立つ原因も理解できる。

結論

Y = 480 クラスの動画の無圧縮キャプチャは（ソフトウェア圧縮キャプチャも） MV-300 を利用する限り不可能である。また ZR36067 を利用するビデオキャプチャカードではどれも同じ問題点があると推測できるので、Buz & MJ-600 でもこれらの症状は同様であると判断する。

以上の結果より、無圧縮キャプチャも選択肢に入れたい場合、ZR36067 を利用したカードは避けるべきであると結論できる。また、ハードウェア圧縮をサポートしたカードの場合、無圧縮でのキャプチャは期待しない方が賢明であると判断する。何故ならば、ハードウェア圧縮を行うキャプチャカードの場合、もともとデータ転送速度がそれほど必要とならないので PCI バスを通した DMA 転送能力に劣る可能性が高いからである。

さらに、704x480 クラスの Motion JPEG AVI をハードウェアで展開して表示する場合は、PC のディスプレイ上で再生して確認するよりも、ビデオ出力を通して TV に表示させた方が動画の動きについて適切な判断が出来ると考える。

352x240 無圧縮キャプチャ

目的

704x480 での YUV 無圧縮キャプチャは失敗したが、MV-300 で無圧縮キャプチャを行った場合どれだけのフレームレートが出せるのかを 352x240 のサイズで YUV 無圧縮キャプチャを行い測定する。（ハードの性能ではなく、キャプチャドライバの性能を測る）

方法

MV-300 から YUV16 無圧縮形式、352x240, 29.97 fps の設定でビデオキャプチャを行い、ドロップフレームを測定、実効 fps を算出する。

実験環境

FastTrak66 の実験時と同一

結果

FastTrak66 の実験時と同様に測定を行い次の値を得た。

これらのデータから実効 fps は 29.70 と測定される。29.97 fps は 352x240 でも達成することが出来なかった。

考察

YUV16 形式 352x240 29.97fps で必要となるデータ転送速度は 5M bytes/sec 程度であるため ZR36067 の DMA 転送速度範囲内で収まり、理論上はドロップフレームが発生しないはずである。しかし現実には 2 秒で 1 枚程度の欠落が発生してしまっている。

Motion JPEG 形式で取り込む場合は 29.97 fps を達成できる事から、これはハードウェアの問題などではなく、単純に Video for Windows キャプチャドライバの作り込みが甘いために欠落が発生していると考える。

感想

MV-300 は Motion JPEG キャプチャカードであり、Motion JPEG 以外のキャプチャ形式を選択した場合に問題が発生するのは仕方のないことなのかもしれない。しかし、それでもこれはひどすぎるのではないだろうか。

今後ドライバのバージョンアップなどでこの問題が解決する可能性もあるが、少なくとも現状では MV-300 には問題が多く購入を勧めることが出来ない。MV-300 の購入を考えているのならば、もう少し待った方が良いというのが私の考えである。

RGB24 キャプチャ

目的

YUV422 16bit 形式でのキャプチャでは上記のような結果となったが、より負荷の高い RGB 24bit 形式でのキャプチャを行い MV-300 の限界性能を見極める。

方法

RGB24 形式、704x480 29.97 fps の設定で FastTrak66 + DJNA372200 x 2 の RAID にキャプチャを行いドロップフレームを計測する事で実効 fps 及びデータ転送速度を測定する。

実験環境

FastTrak66 の実験時と同一

結果

FastTrak66 の実験時と同様に測定を行い次の値を得た。

これらの計測値より実効 fps は 19.39 fps と推定される。この時、RGB24 形式でのデータレートは 18.75 M bytes/sec となる。

考察

まず、YUV422 16bit 形式でキャプチャしたときと比較し、実効 fps は 19.59 から 19.39 に落ちただけと、16 bit データから 24 bit データへの増加（1.5 倍）と比較して変化が小さい事が指摘できる。

このためデータ転送速度は 12.63 M bytes/sec から 18.75 M bytes/sec と約 1.5 倍に増えている。

この結果から、FastTrak66 で構築した RAID は YUV16 形式でキャプチャを行った際にも十分な余裕があった事が言える。

では、なぜ RGB24 形式に変更しても fps が 2/3 に落ちなかったのかということを考えると、これは MV-300 で RGB24 形式のキャプチャを行った場合、MV-300 から送り出されるデータは YUV16 のままで、それを CPU で RGB に色空間変換を行ってからハードディスクに出力しているためであると考える。

この結果から、ZR36067 の DMA データ転送速度に制限があり、無圧縮キャプチャが上手く働かないという説の補強材料を得る事ができた。

NTSC 信号のチェック

目的

352 x 240 キャプチャ実験 でも 29.7 fps でしかキャプチャを行う事ができなかったが、そもそも NTSC の信号元として利用している TV のビデオ出力は 29.97 fps で送信しているのか確認する。

方法

今までキャプチャに利用していた NTSC 信号をサウンドカードのアナログ入力から 48000 Hz 16bit モノラル PCM 形式で録音し、記録された PCM の波形を観察する事でキャプチャに利用している NTSC 信号の fps を調査する。

実験環境

• AIWA VX-T14SX1 (14 インチテレビデオ)
• Creative SuondBlaster PCI64
• Creative WaveStudio 4.02

結果

TV から出力されているビデオ信号は、59.94 Hz で、29.97 fps であることが確認できた。

測定データ

録音できた PCM データは次の図１のようになっており、丸で囲んだ部分が垂直同期信号である。

図１ NTSC 信号

この垂直同期信号について、その間隔をしらべると、１つ目の垂直同期信号は 116 サンプルにあり、２つ目の垂直同期信号は 917 サンプルにあるので、その間隔は 801 サンプルである。

同様に、50 個の垂直同期信号についてその間隔の平均を取ると、800.8 サンプルとなった。これは 48000 Hz でサンプリングしたデータなので fps は次の式で計算できる。

48000 / 800.8 = 59.94
59.94 / 2 = 29.97

サンプルレートを垂直同期の間隔で割る事により、１秒間のフィールド数を求めることができ、これを２で割ったものがフレームレートとなる。

この結果から、少なくともキャプチャカードに入る段階のビデオ信号は 29.97 fps であり、NTSC 信号の規格に合致していることを確認できた。

Linux での利用

目的

Linux 用ドライバを作成し、AverMedia 製ドライバよりも安定かつ高画質なキャプチャが可能か検討する。

方法

The Iomega Buz under Linux で公開されている Iomega Buz のドライバを改変して MV-300 を Linux で利用できるようにする。

結果

現在実験中。とりあえず MJPEG 形式による動画のキャプチャに関してはほぼ不満の無い状況までドライバの完成度が上がっている。しかし、未だに Linux 上での再生はできない問題点が解決できていない。

成果

ドライバ

mv300-0.0.1a.tar.gz 1999, 12/31

キャプチャツール

lavtool-mv300-1.0.tar.gz 1999, 12/31

対象環境

• カーネルバージョン 2.2.x 以上（動作確認は 2.2.13）
• モジュールをサポートしたカーネルであること
• videodev をモジュールとしてサポートしていること
• カーネルの管理外に十分な空きメモリがあること（起動時にカーネルオプションとして mem=xxxM で実メモリよりも少ない値を指定していること）

インストール方法

1. デバイスファイルを作成する
   • cd /dev/
   • mknod video0 c 81 0
   • ln -s video0 video
2. ドライバをコンパイルし、モジュールを組みこむ
   • gzip -cd mv300-0.0.1a.tar.gz | tar xvf -
   • cd mv300/driver
   • su
   • make;make install;./update
3. キャプチャツールをコンパイルする
   • gzip -cd lavtools-mv300-1.0a.tar.gz | tar xvf -
   • cd lavtools-1.0a
   • make
4. キャプチャできるか確認する
   • ./lavrec -i n -t 3 test.avi

うまく動かなかった場合

kazhiro@a2.ocv.ne.jp まで、「どの段階で失敗したのか」「表示されたエラーメッセージ」を添えてメールをください。私に判ることでしたら助言します。

既知の問題点

1. Linux 上で再生ができない（lavplay が動かない）
2. V4L アプリケーションからの動作確認が取れていない
3. HDD への書き出しが忙しくなると音声の取りこみでバッファオーバランを起こす
4. es1370 と alsa の組み合せで使用している場合、44100 Hz 以外で音声を同時に取りこむと、音と映像の長さが合わなくなる

サンプル

以下に現在の Linux 用ドライバで取りこんだ AVI ファイルから、Windows 上で Pegasus Imaging Corp. の PICVideo Codec を利用してデコードした後 BMP から JPEG に再圧縮した画像をサンプルとして載せる。

いずれも SONY の CM より抜き出した 1 フレームであるが、一応引用として一般に認められる範囲内に収まっていると考えている。

	サンプル１ 自然画 フルサイズ
	サンプル２ CG フルサイズ
	サンプル３ フラッシュ フルサイズ

KS0127 のレジスタ

目的

MV-300 では PC の使用している電源やメインボードによって正方ピクセルで波打ち（水平）ノイズが発生する事がある。

AverMedia 製ドライバの動作時に KS0127 のレジスタ値を読みこみ、正方ピクセルと CCIR で比較を行ってこの原因がハードウェアにあるのか、ドライバにあるのかを考察する。

方法

Morry's Un'Gramming Page で公開されている PhysMap.c と V4L の I2C 通信コードを参考に、Windows 上で一般アプリケーションから ZR36067 のメモリ領域を直接マッピングし KS0127 のレジスタを読み出すプログラムを作成。それを用いて正方ピクセル時と CCIR 時のレジスタの変化を比較する。

比較の結果、特にノイズの原因となりそうな値があれば、ドライバの欠陥と判断する。

結果

正方ピクセルと CCIR でレジスタの値が異なるのは、次の表で示す場所だけであった。

このうち、0x01 の PIXSEL は正方ピクセルと CCIR を切り替えるためのものであり、ノイズに影響するとは考えられない。0x07, 0x08, 0x0C も水平同期信号の位置を指定するために使用されるレジスタなので、同じくノイズには影響しないと判断する。

少なくとも、KS0127 のレジスタに関しては、ドライバが波打ちノイズの原因であると結論するための証拠を得ることはできなかった。

測定値

AverMedia 製ドライバ動作時の KS0127 の全レジスタ値を下表５に示す。各レジスタの意味については、データシート を参照のこと。