結果はともかく、試験が終わって多少余裕が出てきたので、次の散財を DVRapter と GV-DVC のどちらにするかを考えているのだが……。
む〜、カノプー のページに Rapter の 写真があったので、使ってるチップとか調べてみた。
まず、Philips の SAA7111A と SAA7146A が目に付くけど、これはアナログキャプチャ部分のはず。
次に、ALTERA のチップが見えるけど、多分これは FLEX 10k。何に使ってるのかは……なんとなく想像がつくけど、できれば考えたく無かったりする。
で、内部 IEEE1394 ポートのそばにあるのが、富士通の MB86611A。これは IEEE1394 コントローラで間違い無い。
とりあえず、全部データシートとかは手に入るのだけど……問題は ALTERA FLEX 10k なんだよな〜。
次に書くのはチップ構成から見た DVRapter の構造だけど、推測がかなり入るから間違っているかもしれない。
まず、PCI コントローラは Philips SAA7146A。
これは PowerCapture シリーズから使ってる IC だし、細部もわかってるから採用したのだと思う。
で、SAA7146A に接続されているのが Philips SAA7111A と ALTERA FLEX 10k。
SAA7111A はアナログ端子からのビデオ信号をオーバレイするために使用し、FLEX 10k は…… 富士通 MV86611A と SAA7146A の仲介兼 IEEE1394 用のバッファコントローラとして使われてる。
最後に富士通 MB86611A は IEEE1394 経由での通信を制御するための専用チップ。FLEX 10k と接続されていて、そちらから操作される。
多分こんな形だと思う。Linux で使おうとか考える場合、最大の障害になるのが ALTERA FLEX 10k。
なにしろプログラマブルロジックデバイスだから canopus 側で好きなように設定して使えるので、情報提供が無い限り絶対にドライバは作れない。（設定用 EPROM の中読んで解析……は無理だろう）
アナログキャプチャキット相当の事ならデータシートは完全に公開されてるからなんとかドライバ書けそうな気がするけど、肝心の DV 部分が駄目だとな〜。
しかし、プログラマブルロジックデバイスで独自に DV サポートですか……。カノープスの技術力ってすごいわ。（リファレンスデザイン通りのボードすらまともに組めない所と比べるのが間違っているのかもしれないけど）
もっとも MB86611A の方の制限で 100 Mbps が通信速度としては目一杯みたいだけど、これは DVRapter 登場時期の（予算等の）制限があったから仕方ないか。
カノープスの DVRapter は linux からふがほげするのはちょっと無理っぽい（いろいろと遊べるからその点は楽しそうだけど）ということが判ったので、GV-DVC/PCI の使用チップについてしらべてみた。
GV-DVC/PCI が使ってるのは NEC のチップとの事（詳細は不明）なので、NEC 半導体デバイス へ。
えーと、今あるのは物理層とリンク層でチップが分かれてるタイプ（μPD72850A + μPD72860/1/2）と１チップに集積されてるタイプ（μPD72870/1）の２系統しかなくて、どちらも 400 Mbps までは対応しているらしい（この辺は後発の強みというか、Rapter よりも唯一優れてるところだよな〜）
一応データシートを用意してるみたいだけど、外為法の関係かリンク層を含むチップのデータシートはメールで要求しなきゃもらえないらしい。
ふむ〜、話題は変わるけど、DVRapter の ALTERA FLEX 10k はリンク層チップに相当する機能を持たされてるのっかな〜？
まあ MB86611A は物理層の機能しか持ってないみたいだから、多分これはあってるだろう。
えーと、MV-300 の linux 用ドライバについてやるべきこととしては……。
1. lavplay がまともに動作するようにする。
2. lavrec で audio overrun が出ないようにする。
3. bttv 等の V4L アプリケーションでの動作確認を取る。
4. V4L に MJPEG Extention が取りこまれたので、ドライバを書きなおす。
5. Buz のドライバの作者と連絡を取る。
とかかな〜。
とりあえず ALSA プログラミングについて調べるのがまず最初かな？ どうも lavplay は audiolib.c のあたりで詰まってるみたいだし。
日本語で解説してる判りやすいページがあればそれが一番なのだけど、まず見つからないのだろうな〜。
嗚呼、言葉の壁。
どうやら lavplay が動かないのは audiolib.c の何処かで引っかかっているらしいという結論に達っしたので、ALSA のライブラリの使い方を解説してるページを探してみたのだが、本家のページにもあまりそう言うドキュメントが見つからない。
つまりは /usr/include/sys/asoundlib.h を読めと言うことなのかと判断し、挑戦してみたがあえなく挫折。
仕方が無いので適当なサンプルから使い方を学ぼうと alsa-util の aplay/arecord をコンパイルし、動かして様子を見ようとしたのだが……。
何故に無音の wav ファイルしか作れないのかな〜。
いわゆる一つのミュート状態かと思ってミキサー側の設定を再生のみから録音にぽちっとなと変更するも効果無し。訳が判らない。
0.5.2 を落としてきてそちらで再挑戦してみたが libc5 なため search.h に hsearch_r() 関連の構造体が無く alsa-lib がコンパイル出来ず。
いい加減 glibc に移行するためセリオウェアから全部インストールし直そうかという現実逃避じみた妄想を楽しんでしまった。
で、何となく goo で snd_pcm_read を検索。（これで参考になる物が見つかればめっけものぐらいの感覚。既に諦めモードレベル２）
見っけたページで ALSA の日本語ユーザメイリングリストがあることに気が付き、入会方法はどこだ〜と探してみると……。
わはは、最終更新が 1998, 12 なためにトップ以外は見ようとも思わなかった ALSA の日本語ページに書いてありやがる。
とりあえず登録して過去ログ取り寄せだな〜。検索サービスは公開されてないみたいだし。
どうして登録したその日に alsa-user ML (ja) は移転するのだろ〜。
う〜ん、一応ログは眺めてみたけど投稿が少ないから有効な返事が貰えるか心配だな〜。
知りたいのは「ALSA の digital audio interface (PCM) で非同期モードで capture する際の一般的なサンプルとか（できれば解説も）の在処」なんだけど。
素直に linux-users に聞いた方がはやいかな〜？
ecasound のソース読めという返事が返ってきそうな気もするが、まあ駄目元でやってみるか。
audiolib.c の録音モードでの動作が大体理解できた（と思う）
まず、[256][バッファサイズ] のリングバッファを持ち、サブプロセスがブロッキングモードで OSS/ALSA ドライバからリングバッファに PCM データを読み込む。
で、データを読み込んだならばリングバッファの USED フラグを立ててから、バッファを進めておく。
一般アプリから呼ばれる audio_read 関数は、リングバッファの USED フラグが立っていればそのバッファからデータを持っていき、USED フラグを落としてからバッファを一つ進める。
アクティブなバッファの USED フラグがまだ立っていない場合は、戻り値で取れなかった旨伝えて、そのまますぐにアプリケーションに制御を戻す。
つまり、サブプロセスを利用することでブロッキングモードをノンブロッキングモードとして使おうという目的で作られた物のようだ。
……ここまでは理解できた。
だが、だとすると何故 audiolib.c がバッファオーバランを警告してくるのかが理解できない。
audiolib.c のサブプロセスは snd_pcm_read() を使って while ループをぶん回してるだけだから、本来ならフラグメントが１つ一杯になった時点ですぐにバッファにデータを読み込んで行くはずだし…… DMA バッファが溢れる事はおこらないはずなのに。
まあ、バッファオーバランを警告するときと言うのはディスクバッファからひたすら実ディスクに書き込んでる時だから、その辺の処理で CPU が食われてしまい、snd_pcm_read() まで回らない……なんてことあるのかな？
良く分からない。while() ループの中身をもう少し減量すればひょっとしたら改善するのかもしれないけど、どうせなら折角 ALSA 使ってるのだし、ネイティブな非同期モードで読み書きできないかと思うのだが。
うーん、もう少し調べて見なきゃいけないみたいだ。
今回はちょっぴり看板に偽りあり。実際は「Linux でビデオ編集？」程度の内容しかない。
まあ、あんまりこういうことを書くのは誉められたことではない（文句を言うなら手前でやれという素晴らしい常識が UNIX の世界にはある）のだけど、まあ MV-300 のドライバいじってるという実績に甘えて書いてしまう。
閑話休題。
「Linux でマルチメディア？ 正気か？」というのが私の現状認識だったりする。
現在 Linux でオリジナルの機能を制限なしに使えるのは Bt848/878 チップを採用したビデオキャプチャボードだけだけど、これは無圧縮での取り込みしかサポートしていない。
こういうハードウェアの制限から、V4L という API はキャプチャデバイスから取りこんだ無圧縮データを X やらフレームバッファに垂れ流す仕様しか考えられていないものだったりする。
これで ビデオキャプチャ と名乗るのはちょっと……と私は考えてしまう。最低でも linux で閉じた形で、取りこみ・編集・圧縮まで実現できなければと考えるのは贅沢なのだろうか？
……ちょうど切りもいいし、まだ考えもまとまってないので続きは明日。
前回の日記で「続きは明日」などと書いたにも関わらず、裏をとっていたらこんなに遅くなってしまった。まあ、それはそれとして前回の続き。
Iomega Buz のドライバが行った MJPEG Extension は既に Linux Kernel 2.2 系列の V4L セクションに取り込まれている。
昔は、ドライバ開発者が独自の API を設計し、その API を利用するアプリケーションをそれぞれで作製しなければいけなかったが、今は MJPEG Extension に従ったドライバさえ書けば既存の MJPEG Extension 対応アプリケーションをそのまま利用することでキャプチャや再生が可能になる。
つまり、MJPEG Extension によって、特定のドライバでしか動かないアプリケーションと、特定のアプリケーションでしか扱えないドライバの組み合わせが無数にできあがるという事態は避けられるのだ。（開発力の分散という、バザールタイプオープンソース開発モデルの暗黒面が今後表出することは避けられる）
だから、今後 MJPEG キャプチャボードの Linux 用ドライバがいろいろと出てくる可能性はある。（私があれこれと試しているように）
さて、MJPEG 形式が V4L MJPEG Extension として Linux 上でサポートされた事で、ビデオ信号をディスプレイに垂れ流すだけでなく HDD 上にビデオ信号を記録し、再びビデオ信号として出力する事は可能になった。（MV-300 ではまだ再生ができない）
しかし、編集が出来ない。Linux 上では、簡単なカット編集すら出来ない。Linux をサポートしたただ一つのオープンソースビデオ編集アプリケーションである Broadcast2000 は AVI には対応していない。（QuickTime や XAnime 経由での読みこみには対応しているが、その場合 720x480 では扱えない）
録画と再生しか出来ない、果てしなく使い難いビデオデッキ並の機能しか今の Linux は持っていないのだ。
編集したい場合はどうするか、VFAT パーテーションを linux 上からマウントして、延々数 G にも及ぶファイルを Windows から見える所にコピーしてやるか、あるいは、もう一台 PC を用意し SAMBA を利用したネットワークドライブから動画ファイルを操作するぐらいしか方法がない。
これが、Linux のマルチメディアの現状だ。
720x480 ではディスプレイに垂れ流すことしかできないビデオキャプチャと 720x480 で記録できるが編集ができないビデオキャプチャ（MV-300 に至っては再生すらできず、録画しかできない）
私はそれでも構わないと納得の上で行動しているからいい。
AverMedia 製の Windows 用ドライバよりもまともな物を得るための手段として Linux を利用しているに過ぎないから、今は Linux 上で編集できなくても、再生すらできなくてもいいと考えている。
だが、普通の人が期待するビデオキャプチャとは、コマンドラインからキャプチャアプリを起動して、ドロップフレームの発生やオーディオバッファのオーバーランを監視している事ではないはずだ。
むしろ、そこよりも次の工程である、（ノンリニア）編集作業こそがビデオキャプチャだと考えている人の方が大半だろう。
それなのに、Linux での MJPEG キャプチャはその期待に応えることができる形にはなっていない。
それでも、Linux でマルチメディアなどという幻想を抱く人がいるのはなぜなのだろう。
