Note for OV511 on FreeBSD

2002/04/08

たとえば320×240の画像をYUV422の16bitで取り込む場合には、153600バイトに なり、960バイトのFIFOの160倍となる。

現在使っている、LifeViewの機器ではOV511 PLUSとSAA7111Aの組合せになってい る。上記のフォーマットでキャプチャーするには、SAA7111AをYUV422に設定して、 OV511についてもYUV422に設定する事で可能なのだと思う。(ちなみにBT848では このセットが一つのチップの中に入っているので、処理はずいぶんと楽なような 気がする)

2002/04/09

SAA7111AではVBI-DATAをサンプリングしてI2Cから拾い出せるようである。ライン の指定は、I2Cのサブアドレス15(SA15)と16で行なう。しかし、いくらデータ量が 少ないといってもI2Cで、すべてのデータを転送できるのだろうか？？？

NTSCでは水平走査線周波数が15.734KHzで1フレームあたりの走査線が525なので、 割算をすると29.97フレーム/secとなる。

SAA7111Aでは外部接続が4本ありADコンバータが2つあって、S端子の場合にはYとC をそれぞれに接続するた入力が2系統等なり、コンポジットだけの場合には4系統の 入力から選べるようになるいようである。

OV511PLUSでの961バイトの転送の場合、先頭に0が8バイトあり、その次にヘッダー が1バイト存在し、その次にサイズを示す2バイトのデータがある。また最後にパケ ット番号の1バイトがあるので、実質パケットでのビデオデータは949バイトとなる。

2002/04/10

NTSCの信号を表示するためには、まず水平同期を見つけ出してラインを確定して、 そのラインが垂直同期の場合には、続いて流れてくる奇数か偶数のフィールドを処 理することになります。

2002/04/13

SAA7111Aの初期化パラメータををLinuxのソースから借用して、コードを修正した ところデータが流れるようになったので、データを保存してMacで表示させたとこ ろ、ノイズだけが表示された。ところが、この後に同じバイナリでキャプチャーを 行なったところ、データが流れてこなくなり、できなくなった。なにも変えていな いはずなのだが？？？

LifeView TVではSAA7111AのAI11にコンポジット入力がつながれていて(Mode0)、AI12, AI22がS端子になっていて(Mode5,7)、AI21がTVチューナからの入力に(Mode2)なるよ うである。

2002/04/19

Macでみると、320×240はわりときれいですが、640×480はかなり荒いです。これは ハードの制約なのであろうか？

2002/04/29

思考錯誤の結果、YUV420の320×240でキャプチャすることができるようになった。し かし青色が抜けているようで、へんな色になる。また何故かユニットのボタンを押し た後でないと、データが流れてこない。（OV511のハードウエアキャプチャのレジスタ をいじったのが原因と思われるが、これをいじらないとそもそもデータが全く流れて こない。）

デジカメ(DS20)のNTSC信号のキャプチャ

2002/05/04

どうにか320×240で正常にキャプチャできるようになった。問題になっていたのは、 OV511側のレジスタ11hの設定で、デフォルト値が01hであったのだがSAA7111Aでは 00hで設定しなければいけなかった。

結局のところSAA7111AからOV511へはYUV422の16bitでデータが送られ、OV511からUSB へはYUV420で転送するような設定になっている。

320×240ではキャプチャできるようになったが640×480ではいまだにおなしなデータ になる。LinuxでもこのサイズはサポートとされていないのでSAA7111Aの仕様でサポー トできないのかもしれない。

手元にあるLifeView TVにはチューナとしてPhilipsのFI1236MK2が使われているよう だ。オーディオの処理にはPTCという会社のPT2313Lというチップを使っている。この チップはSTという会社のTDA7313というチップのコンパチ品であるようだ。両方のチッ プともI2Cで制御するようだ。

2002/05/06

いろいろ試してみて、チューナの制御ができるようになった。チューナはI2Cの0xC2, 0xC3にあり、これにコマンドを送ると制御できるようだ。しかし周波数とコントロー ルのデータを送る前に、読み出しをしないと正常に設定できなかった。

チューナの設定のデバッグの際LifeViewTVのチューナモジュールの23番ピンとグラン ドをテレビのビデオ入力につないで試していた。以前Macで見ていた時にはTVの映像が あまり奇麗でなかったように思えたのだが、今回いろいろ試していてわりと奇麗であ ると思った。

あとはとあえずオーディオのの処理の制御をみてみようと思う。

制御とは関係ないが、PT2313からの出力をヘッドフォンアンプのAPA2308というもの に接続しているようだ。

PT2313LはおそらくI2Cの0x4Aにあると思われるのだが、データシートにもI2Cについ ては説明がなく、コマンドが全くわからない。ちょっと制御は難しいのかもしれな い。

オーディオの処理のテスト用のコードなども入っていますが、とりあえず今のとこ ろのソースの修正箇所は下のpatchの様になります。

2002/05/06現在のvid 1.0.1へのパッチ

2002/05/13

ov511からのデータは最初と最後のパケットのみにヘッダーが付き、それ以外は生の データが直接はいっている。たとえばOV511+でパケットサイズが961に設定されてい てYUV420の圧縮なしの場合、320×240×12÷8=115200のデータが、パケットとしては 121パケットになり、961-10+119×(961-1)+961-12の構成で送られてくることになる。 ちなみに、YUV420のブロック(384バイト)では300ブロックとなる。

Linuxのドライバに入っていた圧縮ルーチンを追加してみたのだが、うまく使えてい ない。パケットをまとめて、ルーチンに渡すと115200バイトに展開されたり、されな かったりする。うまくいった場合のデータもおかしなものになる。

2002/05/15

OV511でデータを圧縮した場合、32バイトのアライメントですべてのバイトが0の非デ ータ部分がパケットに含まれるようである。ホスト側で展開を行なう場合、この部分 を削除したデータにして、展開ルーチンに引き渡す必要があるようだ。

最初のパケット


中間のパケット


最後のパケット

圧縮したデータをどうにか展開して、画像にすることができたのだが、モザイクの 様な画像になる。もとのデータ(YUV420)の10%位のデータ量なので、このようなもの なのであろうか？

2002/05/16

圧縮したデータもほぼ正常に画像にすることができた。問題はLinuxのコードで行な っていた圧縮のクオタイズテーブルの設定が抜けていただけだった。

2002/05/16現在のvid 1.0.1へのパッチ Linuxのドライバのov511_decomp.cが必要です

ちょうど、某放送局でテスト信号が出ていたので、うちの安いテレビからのビ デオ出力をOV511でキャプチャしたデータ。圧縮なしですが、それほど奇麗では ないですね。

2002/05/22

NTSC出力のあるデジカメに上記のようなテストパターンのJPEGファイルをダウンロ ードして出力する事で、簡易テストパターンジェネレータになるのではないかな？

320×240のデータであればov511の外部メモリにYUV422で取り込む事も可能であると 思われる。(640×480の場合には足りないようであるが)こんとYUV422を試してみよう。

2002/05/25

422のデータはUVが各々64バイトに続きYが128バイトで1ブロックになるようである。

2002/05/29

YUV422でデータを処理できるようになったが、奇麗さでは420のデータとそれほど変 わらないように思える。

SAA7111A,YUV422,圧縮,チューナをサポートしたvidのソース (2002/05/29)

2013/02/09

今更なのだが、手元のUSB機器の情報を整理していて、OV511なモジュールがmacamで 使えなかったので、ハードの故障の確認のためビルドしてみたがこのソースは netpbmというライブラリを使っていた。