けっこうあっさりと進んでしまった。
ベースのドライバを Buz 用のものに変更して、Philips SAA7111 用の設定を Samsung KS0127 用の設定に書き換えただけで無事に動くようになってしまった。（関数名などはぶつからないように適当に変更）
同じく Buz 用の lavtool というものを使うと、音声と同期した MJPEG AVI ファイルが簡単に取り込めてしまう。
うーん、今まで LML33 相手に苦労していたのはなんだったのだろうと考えないでもない。
とりあえず、Bt866 への対応がまだ済んでいないので公開は無理だけど、それさえ終れば公開可能かも。
７月頃から延々やってたことだけに、こういうふうに結果が出てくれるとかなり嬉しい。
現在ドはまり中。
MV-300 の Linux 用ドライバだが、KS0127 への I2C バスを通した読込みで常に失敗して 0x00 を返してくる。
悲しいことに、LML33 のドライバを使ってカードを初期化し、LML33 のドライバを外してから MV-300 のドライバ（Buz 改造）を入れると無事に KS0127 からの読込みに成功するようになる。
また、Windows 側で一度 MJPEG ファイルを再生するなどしてカードを動かしてから loadlin を使って Linux を起動しても同様の効果があるようだ。
まあ、これはカードの初期化に失敗しているのだろうから、LML33 のコードと Buz のコードを見比べていけばいずれ解決できることだろう。（これに気が付くまで半日無駄にしてしまった）
この連休の間に片付けておきたかったのだけど、この調子では明日までかかっても無理かも知れない。
しかし、こういうふうにハードを制御するプログラム書いているとテスタが欲しくなってくるね。
単純な導通テストと I/R/V/C の測定が出来れば十分なんだけど……。基盤上のパターンを読んで結線状況を確認するのは辛すぎる。MV-300 は片面１層、両面で２層だけみたいだから表面からの観察でもなんとかなるけど、テスターがあればチップ上のピンとピンの繋がりが簡単に確認できるのに。
バイト先にはテスターもあるのだけどこれを借りることはできないだろうし……、とりあえず単純な導通テストだけで済むから乾電池と豆電球をテスターがわりに使ってみようかな〜。（これならテスターを常備しているような変態ではないと言うことができるし）
とりあえず、KS0127 の RST ピン（ハードウェアリセットピン）と ZR36060 の GPIO ピンのどれが繋がっているのかだけでも試しておくかと考えて前日の日記に記述した乾電池＋豆電球の導通テスターを使用してみた（ああ、どんどん逸汎化している）ところ、どうやら GPIO 0 であっていたようだ。
ただ、使用したのが 9V の箱形電池であったためか、テストが終ったときにはカードに電荷が溜っていたようで、カードを差し直そうと PCI スロットにカードが触れたとたんに PC が起動を開始（ATX 電源を OFF にしてなかった）見事に FastTrak66 が認識されなくなってしまった。
FastTrak66 の RAID に入っている ン G のデータはどーなってしまうのだろーと青くなりながら、一旦 FT66 を抜いて祈りながら再度同じスロットに差し直したところ無事に動くようになってくれたから良いのだけど。
教訓、PC のハードをいじるときは ATX 電源のケーブルを抜いておくか、それが面倒ならせめて電源の方のスイッチを切っておくことにしよう。導通テストをするなら出来る限り低い電圧でやろう。
とりあえず、GPIO 0 が接続されているのはビデオデコーダの RST ピンであることが判ったわけで、これは Buz と変わらない。
GPIO 0 の電圧を落とした後も udelay(100) を入れているから、多分時間的にも十分だろう。
とすると、初期化自体は正しく行われているが、SDA ラインにスレーブデバイスが返してくる電圧値が低いかなにかで閾値を超えることができず、全ビットが 0 に落ちていると考えるのが正しそう。
これは ZORAN のリファレンスカードの PDF を見て、標準ではどのような結線にしているのかを確認して、当りをつけてから他の GPIO などについて結線状況を確認した方が良いかもしれない。
まあ、MV-300 の Linux 用ドライバも（各種おまじないをすれば）何とか動くようになって、MJPEG 形式の AVI が普通に取り込めるようになったのだが、いくつかの問題点がある。
まず Bt866 のサポートが済んでいないため、再生が出来ない。次に、何故か 29.6 〜 29.7 fps 程度でしか取り込めない。そして最後に、ZR36060 が VSF モード（可変 JPEG サイズ）で動いているのでブラックアウトやホワイトアウトのきついところでドロップフレームが発生する。
と、このように問題が山積み（I2C の読み込みで失敗する問題もまだ解決していない）なので、どーしたものだろーという気分だ。
それぞれに優先順序をつけて解決していくしかないのだろうけど。（あー、チャーリー・ブラウン方式という手もあるか……）
とりあえず最優先にしなければいけないのは Bt866 への対応だと言うことは判ってはいるのだけど、キャプチャ出来る環境が構築できてしまうとついついキャプチャして画質の確認とかをしてしまって作業が進まない。（キャプチャ出来ない状態だと SAA7111 のコードを KS0127 用に書き換えるまで半日かからなかったからなぁ。LML33 相手に解析してた時代の蓄積があったとはいえ）
ま、愚痴はこれくらいにして、少しは建設的な考察を。29.6 〜 29.7 fps でしか取り込めない問題だが少し恐ろしい数字に気が付いてしまった。
26800000 / (858 x 525) = 59.496
59.496 / 2 = 29.748
たぶん偶然だと思う。偶然だと思いたい。
ちょっと結果として出てきた数字が 352x240 キャプチャ実験 での数字と近いから不安になってくるけど、まさかそんな訳はないだろう。
KS0127 に接続されているクリスタル（だよな、クロックじゃないと思う）は 24.576 MHz で 26.8 MHz のものじゃ無いから、大丈夫のはずだ。
そーとも、KS0127 が 24.576 MHz と 26.8 MHz でしか VCL x 2 を出力できなくて、そのせいで 29.70 でしかキャプチャ出来ないなんて事があって良いはずがないんだ。
気をとりなおしてちょっとマニアックな実験をしてみた。
ひょっとしたら NTSC のソースに使用している TV のビデオ出力の段階で 29.7 fps になってしまっているのではないかと疑い、ビデオ出力から出ている NTSC 信号の波形を観察してみた。
と言っても、私はオシロスコープを個人で所持しているようなマニアックな人間ではないので波形の観察にはサウンドカードの PCM 録音機能を使わせてもらった。（なんだかさらに逸般化してしまったような……）
とりあえず、サンプルレート 48000 Hz で 16 bit モノラルレコードを試みたところ、なんとか読みとれる形で VSync が出てくれていたので一安心。（NTSC CCIR-601 は 27 MHz で 1pix を処理するので 48 kHz では完全に機能が足りず、ひょっとしたら VSync は見えないかもと危惧していた）
えーと、ここでは画像を張らずに説明するけど、自分でもやってみたいという興味がある人のために、VSync は 16bit PCM データでは 0 の Low-MAX として現れて結構判りやすい形になってる。
で、VSync の出現から次の VSync の出現までを測ってみると、これは 801 サンプルとなっている。VSync 50 個で平均を取ってみると 800.8 サンプルになっていた。
取り込み時には 48000 Hz でやったから、48000 サンプルで丁度 1 秒間。
48000 / 800.8 = 59.94
59.94 / 2 = 29.97
というわけで、NTSC 信号のソースとして利用している TV のビデオ出力の段階では問題がないと言うことがあきらかになった。（これで 29.7 とかに近い値になってくれたら、実は NTSC は 29.7 fps だったんだと納得して突き進む事ができたのにな〜）
とりあえず、ZR36067 の GPIO ピンのうち、接続先が判明したもの。
GPIO 0 - KS0127, Bt866, ZR36060 の RESET ピン
GPIO 1 - Bt866 の SLEEP ピン
GPIO 2 - Bt866 の SLAVE ピン
GPIO 3 - ZR36060 の FLAME ピン
これ以外は接続先が不明のまま。それから GPIO 1 & 2 についてはちょっと確信を持てずにいる。これは導通テストに使用している機材（と呼ぶことに抵抗を感じるのはなぜだろう）があれだから仕方が無いことだけど。
とりあえず I2C で読込み失敗を起こしそうな原因としては GPIO 1 の Bt866 SLEEP ピンぐらいだけど、なんだか関係なさそうな気もするんだよな〜。
ま、今日はちょっと Linux を起動している時間はなさそうだから（前日キャプチャした ES 5 話のエンコード中）テスト出来ないけど、明日時間がとれたら試してみることにしよう。
I2C バス経由での読み出しで常に 0x00 しか返ってこない問題は ZR36067 の GPIO 4 を 0 に設定する事で解決できた。（何処につながっているのかは不明のまま）
現在残っている問題点は以下の点
ZR36067 の GPIO ピンの結線状況だが、以前記述したものは間違っていたようだ。正しくは以下の模様。
GPIO 0 - KS127, Bt866, ZR36060 の RESET ピン
GPIO 1 - ZR36060 の SLEEP ピン
GPIO 2 - Bt866 の SLAVE ピン
GPIO 3 - ZR36060 の FRAME ピン
GPIO 4 - Bt866 の SLEEP ピン
5 〜 7 については未だに不明。saa7158.c を参考に Bt866.c を書いてみたけれども未だに再生は出来ないまま。どうも ZR36060 の辺りで詰まっている様子。
29.6 fps でしか取り込めない問題については lavrec で音声を同時にキャプチャするばあい、オリジナルより音声が長くなっているためだと判明。動画側は正しく 29.97 fps で取り込めている模様。いずれ lavtool の方も改造する必要があるかも。
フィールドオーダーが時々反転してしまう問題については未だに解決できていない。とりあえず、KS0127 の ODD ピンは ZR36060 の FI (Field Indicater) ピンに接続されていることが確認できた。
FRAME ピンが 0 になっている場合、ZR36060 は ODD フィールドしか取り込まないので、FRAME を 0 にしていたままだとフレームを取り込むことが出来ない。どうやら正しい動作は START シグナルを送った後で FRAME ピンを 1 に戻すことだったらしい。
しかし、それをやってもフィールドオーダーは 1/2 の確立で狂ってしまう。
なにが〜いけないと〜いうの〜る〜る〜♪
もちろん歌ったところで解決しない。現状で出来る事と言えば KS0127 で ODD Pol をいじったり VSE や VALIGN を変更したり、ZR36060 で FIPol を変更したり FIExt を変更したりするだけだ。
な〜に、(1+3+3+1)*(1+2+1) でたったの 32 通りだ。総当たりすればいずれ正しいのが見つかるだろう。
……ちょっとこれは気が滅入るな〜。
あー、本気で AVerMedia にメール書きたくなってきた。（現実逃避の妄想はそれがリアルであるほど効果的である──京極夏彦「魍魎の筺」）
MV-300 の Linux でのキャプチャに関しての問題点はほぼ解決の目処が立った。
フィールドの固定に関しては KS0127 側で VALIGN を 0 にしておくことで解決が出来（設定変更総当たりを試した）、29.6 fps でしか取り込めないのも錯覚であると判った以上残る問題点は再生のみ。
多少ノイズぽいものが入る現象もあったが、それは KS0127 側でフィルタをかけないようにすれば解決できそう。細かいパラメータに関してはもう少しベストな値を詰めておく必要があるけど、それさえ終れば MJPEG キャプチャに関しては完璧かな。
問題点は再生に関することなんだけど、それはどーしよーかなー。元々目的はキャプチャだけだったから（Linux で編集しようとかまでは考えてなかった）現段階のドライバでもほぼ満足してしまってるのだけど、流石にこの状況で公開するのは問題があるだろうし……。
とりあえず今日はダイガード OP の Linux による生キャプチャなど試してみて、画質面のチェックなどをしてみる予定。セルアニメ を VHS で録画したテープからキャプチャして試したことはあるけど、生キャプチャはなかなかタイミングが合わなくて出来ないから……、一発で上手く行ってくれると良いのだけど。
えーと、今の所 1/6 圧縮で試している限りでは Linux でも特にコマ落ちのような現象は発生していない。CC さくらの OP（地上波の再放送版を VHS 標準録画）をソースにして 80 秒間、2399 フレームすべてドロップ無しに 720x480 でキャプチャできている。
Windows 用の MV-300 のドライバでは切り落とされている左右の画像部分や、どうしても入ってしまう VBI 領域も確かに削除できているので画質面さえ解決できれば今後のキャプチャ環境は Linux の方に完全移行できそうだ。
MV-300 実験に新しい 記事 を追加した。Linux 上でキャプチャしてみた動画の１カットをサンプルとしておいてある。
あと、リンクミスを幾つか修正。DeInt の SniF さんのページへのリンクが間違っていたのと Buz の Linux 版ドライバページへのリンクでチルダをよけいに入れていたミスを直した。
今日からは再びエンコード作業が開始されるので MV-300 を Linux 上で弄れなくなるのが結構悲しかったりする。
しかし、いつになったら Linux 上で MJPEG AVI を再生できるようになるのかな〜。
こんな調子で作業している限り永遠に無理なのではないかと悲しくなってしまふ。
MV-300 のドライバも lavtool でこそキャプチャできるものの buz のドライバに付属していた example 系では全滅状態だし……。
今週はこれ以上状況は進まないだろうけれども、来週こそは何とかしたいものだ。
AVerMedia の馬鹿野郎。あー、腐ったドライバだとは思っていたがこれほどだとは思わなかったよ。
ODD は奇数で EVEN は偶数だと連中は知ってるのかな〜。
えーと、MV-300 の Ver. 1.3 のドライバを使ってる場合、ODD First の設定だと偶数フィールドが先に取りこまれ、EVEN First の設定だと奇数フィールドが先に取りこまれるようだ。
確認方法。
１．適当な 24fps のアニメを MV-300 で ODD First の設定で取りこむ。
２．TMPGEnc で読みこみ、奇数→偶数のフィールドオーダで 24fps 化を起動する。
３．１枚づつ画像を確認し、X - X' - X - X' となっている部分を探す。
（X は横縞のあるフレーム。X' は直前のフレームと同じ横縞フレーム）
４．偶数→奇数のフィールドオーダに変更して再度 24fps 化を起動する。
５．前回見つけた X - X' - X - X' の部分に移動する。
６．今回は X - O - X に変わっているはず（O は縞の無いフレーム）
何も言う気になれない。今度から EVEN First の設定で取りこむことにしよう。
何がいけないのか判らない。
が、何故か Linux 用の MV-300 ドライバでは偶数フィールドからしか MJPEG を取り込めない。
混乱してきたので少し状況を整理しよう。
まず、現在の Linux 用 MV-300 のドライバは偶数フィールドから MJPEG 圧縮を開始してキャプチャしている。
これは争いが無い事実。根拠は根拠は縦 496 で取り込んだ MJPEG ファイルを Morgan の Codec でフィールド順を逆転して表示させた所、奇数行の最後が行の半ばで空黒に変化していることだ。NTSC では奇数フィールドの最終行では半分の所で偶数フィールド用の垂直同期信号が来るため、垂直同期と重ねてデータを送る事は出来ず黒くなる。
もしも奇数フィールドから取り込めているとしたら、フィールド順を逆転した画像では奇数フィールドの最終行は偶数行へ来るはずだから半分しかデータの無い行は偶数行となっているはずである。現実には奇数行が半分で終了しているのだからこれは争いが無い。
そして、ZR36060 のレジスタには FIDet (Field Indicater Detection) やら FIExt（Field Indicater Existance）、FIVedg（Field Indicater VSync Edge）、FIPol（Field Indicater Polarity）など如何にもという感じのレジスタがあるのに、これをどのパターンで組み合わせてみても偶数フィールドを先頭にしてしか圧縮を開始してくれない。
ここに関しては多少自信がないので今後も検証を続けて行く必要があるが、ZR36060 のデータシートを読む限りでは EVEN First や ODD First を切り替えたい場合は FIDet を変更してくれと書いてあるのに、ここを変更しても取り込めるデータに変化が見られないのはどうしてなのだろう。
FIPol や FIExt の値が不正なためかと考えて少くとも 8 通りの組合わせで試したというのに状況には変化が出なかった。要検証ではあるが訳が判らないのは事実。
KS0127 にも ODFST とか ODDPOL とかそれっぽいレジスタはあるので、一通り試してみたけどやはり状況には変化が見られない。
以前 KS0127 で VALIGN を 1 に設定していた場合は偶数フィールドから取り込みを開始したり、奇数フィールドから取り込みを開始したりと 1/2 で変化していた（これはこれで非常に嫌だけど）というのに一体どうしてなのだろう。
さらに、どちらのフィールドから取り込みを開始するかを不定とするために FRAME ピンに接続されているはずの ZR36067 の GPIO ピンを 1 のまま変化させずに START シグナルを送ってみても偶数フィールドからキャプチャされている現実は変化しない。FRAME ピンに接続されているのは GPIO 3 では無いのか？
無関係だとは思うのだがひょっとしたら ZR36067 の方を少し変更する必要があるのかもしれない。この辺要検証。
あと、未だに接続先が不明のままの GPIO 5 - 7 番ピンの接続先を調査すべく、一つずつ 0 に落としてみて調査してみたのだが、どうやら GPIO 6 は何処かに接続されているようで、ここを 0 に落とすと JPEG 圧縮が機能しなかった。
ひょっとしたらもう一度ケースから MV-300 を引きずり出して例のテスターで導通テストをしなければいけないかもしれない。（出来ればやりたくないな〜危険だから）
MV-300 の方に一つ 実験 を追加。
本当はもう少しデータを集めてからまとめようかと考えていたのだけど、どうも NHK が深夜の再放送期間に入ってしまったようで試験電波を生キャプチャするのが難しいために、現状のままで公開。
そのうちデータが取れた時点で追加すれば良いと思い直した。
しかし、サンプルを置きすぎているのでそろそろ容量が心配。MV-300 以下だけで 2M を超えてしまっているのでどーしようかと悩んでいる。
とりあえず ML を減らせばもう少し容量に余裕も出てくるのだが……。
完璧に ROM になってしまっている ML から抜けることにしようかしら。