土日が潰れた。こんなにコンピュータにのめりこんだのは久しぶりだ。フロッピー1枚で Linux を作って、USB カメラサーバにしてみた。
私が今回フロッピーの Linux に手を出そうと思った理由は、四年前に買った VAIOノートのハードディスクがダメになり、捨てるのももったいないのでフロッピーだけで起動できるシステムを作りたかったからである。起動するだけでは面白くないので、何かに使いたい。
そういえばちょうどコレガのルータの調子が悪いので、VAIOノートをルータにしてしまうのも悪くないなと思った。しかしそれには LANカードが一枚足りない。ルータにするには二枚必要だ。それにハブもない。いや、あるにはあるが、昔使っていたスイッチングハブではない 10Base のダムハブだ。なんだかんだで、専用ルータを買った方が安くて信頼できそうな予感がする。一昔前の記事で、マシンをルータ化すると非常に高速なルータができあがるのでやってみる価値はある、というのを見たが、最近はメーカー製で高スループットをうたう製品が結構出ている。
もう一つの選択肢が、USB カメラサーバだった。USB カメラサーバにするとしたら、追加投資はいらない。ただし、USB を使うためのドライバと、Video4linux と、USB カメラのドライバを、組み込まなければならない。できるのだろうか。とにかく挑戦しがいのあるプロジェクトになりそうだ。のめりこんでいくと、VGA ライブラリでリアルタイムに画像を出す、なんてこともやりだしそうだ。ただ、こういう使い方はありがちな気もして、どっか探せばありそうに思えたので、念の為調べてみた。しかし、さすがにこういう限られた用途への需要は少ないようで、専用のパッケージは見つからなかった。
私の記憶によると、一時期フロッピー1枚だけで Linux システムを作るのが流行ったことがあった。当時私はあまり Linux に興味がなかったので詳しいことはよくわからないが、ルータにするだとか非常用ディスクとしてだとかの理由はあるにせよ、どちらかというと遊びに近いものがあったと思う。でなければ、既存のものを利用するだけで済んでしまうからだ。
いまでもフロッピー1枚あるいは数枚だけで起動できる Linux のパッケージはいくつかある。ちょっと調べてみたら、そういうパッケージを総括したページまであった。
だが、どれを使っていいか分からない。これぞ決定版! みたいなものはないのか。やはり用途が違うとベストチョイスも違ってくるのだろう。
次に見つけたのは、自分で作ろう! っていう 2ちゃんねるのスレッドだ。
ここではレベルの高い話が聞けた。後半ぐだぐだなのはいいとして、貴重なリンクがいくつか入手できた。
まず、ちゃんとした会社が作っている有名な製品。
製品版もあるがフリーのやつもある。頻繁にアップデートされているというから心強い。いま 3.40 らしい。ブラウザから設定できるというから、これ一つあればルータの機能は大丈夫だ。ただ、自分でカスタマイズできるのだろうか。
完成品ではなく、自分で作っちゃうというものもあった。
ベースキットだから、これをベースに色々作れるらしい。カーネルの入れ換えもできるみたいだ。これが一番興味深い。今回はこれを使うことにする。
まず、キットの中身を何も変更しないでそのままやってみることにした。
手順どおりにやってみたが、LILO のインストールにつまづく。作業は manuke.com のサーバでやってしまったのだが、どうやらこいつの LILO とキットの LILO の boot.b のバージョンが違っていたことが原因らしい。サーチエンジンで調べてみたら、キットの boot.b を母艦 manuke.com サーバの /boot/boot.b で置き換えればよいみたいだ。やってみたら成功した。
フロッピー作成スクリプトを実行し、フロッピーを作成した。VAIO にフロッピーを挿入して電源を入れる。立ち上がった。感動だ。フロッピー1枚でこんなにうまくいくなんて思わなかった。
ルータにするか USB カメラサーバにするか悩んだが、結局、追加投資の必要ない USB カメラサーバをやってみることにした。
それでまずやらなくてはならないのが、カーネルの入れ換えだ。キット付属のカーネルは 2.0.36 だった。USB をサポートするのは 2.4 以降、または 2.2.x に USB パッチ? を当てたものだけだ。カーネルが新しくなるとサイズが大きくなりそうだったので、manuke.com の Mandrake 7.2 と同じく 2.2.19 + USB パッチにした。
カーネルのコンパイルが一番大変だと思ったら、ぜんぜん大したことはなかった。make config で質問に答えていくだけ。だけど、最初にビルドしたカーネルは、キットでは動かなかった。どうやらこのキットは、initrd つまりいきなりマウントできる RAM DISK で動くらしいのだが、カーネルのその設定を忘れていた。RAM DISK を使うよう make config のときに返答しておいたらあっさり動いた。
カーネルを入れ換えると、pcmcia 関係が動かなくなった。調べてみたら、それも無理ないなと思った。pcmcia をサポートしているのは pcmcia-cs という独自パッケージみたいなのだが、カーネルに結構密接につながっているので、バージョンアップが欠かせないらしい。そこで最新の 3.1.34 だかを取ってきてビルドした。と同時に、せめて more, df, dmesg くらい欲しいと思ってキットにコピーしておいた。
それで起動してみると、どうやら pcmcia-cs がぜんぜん動いていないことが分かった。どうなっているのだ。サーチエンジンで調べてみると、modprobe などが入っている modutils のバージョンが 2.0.x のままなのが原因だということに気づく。こいつはカーネルとかなり密接に動くので、カーネルのバージョンを上げるなら入れ換えを必ずしなければならないようだ。
more も動かない。あれ? そこでマニュアルを調べてみたところ、ダイナミックリンクライブラリの問題だと分かった。Mandrake 7.2 は libc.so.6 なのだが、キットは libc.so.5 だった。じゃあ libc.so.6 に入れ換えだ、といきたいところだがそうはいかない。二つもライブラリを入れるほどスペースがない。では libc.so.6 に統一すればいいのかというと、入れ換える余裕すらない。なにせ Mandrake 7.2 に入っているライブラリは 1MB 近いサイズがあった。キットに含まれる libc.so.5 は 568KB なのにだ。
というわけで、modutils を libc.so.5 でビルドしなければならないことが分かった。modutils の最新版のほか、クロス開発をするために libc-5.4.46 をダウンロードしてきた。ソースのパッケージを取ってきたので、これらもビルドしなければならない。
ところが libc-5.4.46 のビルドがどうしてもできない。インラインアセンブラを処理する部分でエラーが出てしまう。あまり詳しくないので細かいことは分からないが、特に問題となるような部分は見当たらなかった。とはいえ私はそんじょそこらの人よりは詳しいはずだ。10年前に gcc のインラインアセンブラで組まれたライブラリをいじったことがある。…もう忘れてるか。
そこでまたサーチエンジンで調べてみたら、どうやら gcc のバグだということが分かった。古い gcc ならビルドできるらしいが、新しいのだと無理らしい。そこで libc-5.4.44 のバイナリを落としてそのまま使うことにした。キットの libc も 5.4.44 だったのでバッチリだろう。
次は modutils をその libc-5.4.44 でビルドしなければならない。これが今回一番のウルトラC だった。なにせ、manuke.com サーバには libc.so.6 の環境があって、それを上書きするわけにはいかない。だから、どこか別の場所にライブラリを置いて、それをオプションで指定して使うようにしなければならない。これには、glibc2 の使い方を紹介したページが役に立った。最新の glibc をテストで試しに使うときの方法が書かれていたので、それをそのまま libc-5.4.44 に置き換えて試してみた。ビルドのときにメイクオプションをいじらなければならないが、いろいろやっているうちにすっと動いてくれた。ビルドされた insmod を ldd で確認すると、ちゃんと libc.so.5 をリンクするようになっていたので、これでいいのだろう。
さて、これでもう問題はないはずだと。キットからディスクを作って動かしてみたが、今度はなんと modprobe のところで segmentation fault が発生した。はっきりした法則が分からないが、最初に pcmcia_core.o を入れたらうまくいくのだが、次に ds.o を入れたらセグメンテーションフォールトになる。だけど、最初に ds.o を入れたらうまくいって、次に pcmcia_core.o を入れたらフォールトになる。i82365.o を入れて ds.o も次に入るが、pcmcia_core.o を入れたらフォールトになる。意味不明。ところが ip_masq_* シリーズのモジュールは何の問題もなく何個も入る。
何回も試行錯誤を繰り返すが、結局問題は解決されなかった。
いま冷静に考えてみると、やはり pcmcia-cs が一番あやしい。modutils が一番ヤバそうだと思って、主にこいつを疑っていたのだが、Mandrake 7.2 の構成から一番はずれるのが pcmcia-cs だった。Mandrake 7.2 の構成からではなく最新のものを持ってきたからだ。
modprobe が一番怪しいと考えていたとき、modprobe を使わずに済めばいい、というアイデアを思いついた。pcmcia のサポートがカーネルに統一されているという話の 2.4.x 系のカーネルを入れることを思いつく。カーネルモジュールを外部からロードせずに、最初から全部いっしょにしてしまえば、modprobe はまったく必要ない。そこで 2.4.x のカーネルをダウンロードして展開し、make config をやってみたのだが、全然 PCMCIA の項目が出てこない。そのままだとダメなのか。パッチかなにかで実現するのだろうか。pcmcia-cs もカーネルのソースと一体でパッケージ配布されているのだろうか。そのへん、不勉強で何も分からない。
クロスコンパイルは面倒で難しい。Makefile のどこをどうやって書き換えたらいいのかで、ソフトごとにいちいち考えなければならない。configure の段階で設定できるのかもしれないが、クロスコンパイルのことまで考えてくれるのか怪しい。
やはりちゃんとハードディスクの入ったノートPC で、フロッピーを前提にした開発環境を一式揃えて、カーネルも modprobe も gcc も libc も pcmcia-cs もなにからなにまで古い環境で構築し、それをそのまま必要なものだけフロッピーに載せるようにしたほうが効率がいい。
今回の私と似たような企画でフロッピーベースのシステムを作ろうというのをやっていたページを見つけたのだが、そこの作者は動作環境のバージョンの低い TurboLinux 4.0 で作業していた。
それに、libc.so.5 を使うのには限界がある。libc.so.6 でも、glibc-2.0.7 なら数十キロバイトくらいしか増えないようなので、libc.so.6 で統一してしまったほうがいいかもしれない。となると、キットに含まれるバイナリをすべて入れ換えなければならないが、manuke.com サーバのバイナリをコピーするだけだから簡単だ。
肥大化した libc に対して、コンパクトなものを作っている人たちがいる。diet libc というらしい。ちょっと調べてみたところ、本格的なコードをこいつでリンクするのは危険みたいで、あらかじめこいつとリンクすることを考えてコードを書く人が多いようだ。
結局、これまでのカーネルやらドライバやらをすべて放棄し、manuke.com サーバで使っているカーネルとドライバをそのまま入れてみた。立ち上がらないはずがない。
…しかしディスクが一杯で、他のツールが入らない。ここからが、容量との戦いになる。
そこで、切り札の一つ、busybox を入れてみた。一個のバイナリで沢山のツールの代わりになるというやつだ。すごいすごい。200KB で大抵の基本ツールと insmod 系のツール、grep や sh の代わりになった。
立ち上がった。insmod 系のツールもちゃんと動いてる。おおい、わざわざ modutils をビルドしたのはなんだったのかと。まあ、depmod は含まれていなかったから、いいとしよう。って、depmod ごときなら、あらかじめ modules.dep を入れとけばいいってい話だから、むしろさっさと追い出したい気分だ。
ldconfig が 100KB 以上ある。このバイナリはスタティックリンクだ。ダイナミックリンクライブラリ関係の設定をしてくれるツールが、肝心のダイナミックリンク関係のエラーで立ち上がらないのでは話にならないから、これはしょうがない。
そういえば、実行形式を圧縮するツールが昔あったのを思い出した。いまでは廃れて誰も使っていないのだろうか。gzexe で圧縮できる実行形式の条件として、スタティックリンクでなければならない、という制限があったりするのだろうか。…と思って試しにやってみたらうまくいった。ちゃんと動く。ちなみに、圧縮された実行形式の中身は、シェルスクリプトと圧縮されたコードがくっついた実行可能なテキストファイルになる。
ところが、よく考えてみたら、initrd.tar.gz に圧縮してフロッピーに格納するので、ディスクの容量とはまったく関係ないどころか逆に増えるということにいまさらながらに気がついた。
ちなみにいまでは upx というツールの方が強いらしい。
2HD のフロッピーを使うから容量に苦しむのであって、もっと大きなメディアを使えば容量制限は緩和される。たとえば CD-R を使えば、700MB とか使えてしまう。ただし、ブート時に読めるのは最大で 2.88MB までで、残りは CD-ROM としてマウントしなければならない。マウントすると、システムが立ち上がっている間は CD-ROM を取り外すことができなくなり、用途が制限される。というか、試しに焼くたびに CD-R が無駄になるし、焼く時間も無駄だ。しかし、フロッピーと違って読み込みが非常に速いので、フロッピーでいろいろテストしてから最終的に CD-R に焼くという選択ができる。増えた容量でさらにコマンドを追加したりできてよさそうだ。
ネットに常時接続して母艦と一体で運用することを前提とするならば、NFS で母艦のファイルシステムを流用することもできる。どんなに大きいファイルも入れ放題だ。これができるということは、私の VAIO ノートはハードディスクがなくても十分 Linux マシンとして使えることになるのだが、母艦と常に一体化しなければならないのは趣味ではない。面白そうなので一度はやってみたいのだが…。
*
それにしても、なぜ Mandrake 7.2 の標準カーネルの方がサイズが大きいのだろうか。Mandrake 7.2 の標準カーネルは、さまざまな機能をモジュールとして外部から読み込むようになっている。それに対して、私が最初に自分でカーネルをビルドしようとしたときは、かなりモノリシックにしていた。
make config で質問の嵐に答えるときに、[m] と答えると外部モジュールから読み込むようになり、[n] と答えるとその機能は使えなくなり、[y] と答えると最初からカーネルに組み込まれる。カーネルでなんでもやってしまうのをモノリシックと呼ぶのだそうだが、こうすると自由度が減る代わりに外部モジュールのことを考えなくてすむ。しかし、そうやって作ったモノリシックなカーネルよりも、Mandrake 7.2 の標準カーネルの方がでかい。なぜなのだ。
ともかく、これでカーネルもドライバも Mandrake 7.2 のサブセットになったので、随分汎用的なものが作れそうだ。Mandrake 7.2 に含まれている大量のドライバのバイナリがそのまま使えるのは楽だ。ただし、Mandrake 7.2 に入っていないドライバは自分で作る必要がある。新たなドライバを作るためにはカーネルの設定が必要だった気がする。
USB カメラは非常にあっけなく動いた。usb-uhci.o と usbcore.o のほかに、videodev.o(Video4Linux) と mod_quickcam.o(Logitech QuickCam Express)で動いた。楽勝だ。ドライバ群は modprobe を使って手動で入れなくてはならないのだが、むしろそのほうが設定ファイルがいらないので都合がいい。ところがあとで友人に聞いてみたところ、いまでは usbmgr というコマンドが自動的にデバイスを監視してドライバを読み込んでくれるようになっているらしい。
USB カメラに関しては、以前 manuke.com サーバで非公式にウェブカメラを運用していたことがあり、そのとき既にドライバやらソフトやらを揃えて動かしていたので、今回はほとんど労力を使わなかった。特にフロッピー Linux のカーネルやドライバまで manuke.com サーバと同じものを使っていたので、問題が起きるはずがない。
余裕こいて usbmouse.o も入れておいた。input.o も要求されたので入れておいた。やはりせっかく USB が使えるようになったからマウスぐらい使えてもいいだろう、と思ったのだが、重要なことを忘れていた。このシステムにはどこにもマウスを使う場所がない。真っ黒な画面に文字を打ち込むだけだ。なんとマヌケなことだ。
ネットワークは当初 dhcp にした。その方が手軽だからだ。
クライアントには、最初は Mandrake 7.2 標準の dhclient をビルドしてみたのだが、なぜかバイナリのサイズが 300KB を超えてしまった。これでは容量の関係上入れられない。ひょっとして dhcp サーバも一緒の統一バイナリなのだろうか。当然すべてのバイナリは strip を掛けてデバッグ情報などを取り除いているのだが、それでも相変わらず 300KB 以上だったのには驚いた。
それで改めて今度は dhcpcd を入れてみた。今度は三十数キロバイトなので余裕で入った。いや余裕ではないのだが…。設定ファイルもシンプルで、非常に満足だ。同じ機能を実現するものなのに、なぜこうも違いがあるのだろうか。ちなみに dhcpcd は日本人が作ったらしい。
ftp はそのまま入れた。70KB 近くあるので侮れない。でも仕方ないのでとりあえず入れておいた。
ディスクがあふれたので、いくつかのコマンドに退場願った。loadkeys と jp106.map を追放した。本来は、キーボードによって異なるキー配列の違いを設定するためのコマンドとキーマップファイルなのだが、組み込みシステムなのだからそんなものはいらない。
一方で、一度追放したのだが戻ってきたヤツもいる。sh だ。busybox では ash なら作れるが、sh は無理だ。ash を sh として動かしたら、/etc/rc.d/init.d/pcmcia でポロポロエラーが出る。ash では if [ 式 ] ; then が使えないみたいだ。しょうがないので sh を呼び戻して、代わりに busybox から ash を抜いたら、差し引きで 20KB も増えなかった。
それでも /etc/rc.d/init.d/pcmcia で Syntax Error が出るので、調べてみたら、if ! `/sbin/modprobe ...` なんていう無謀な構文があった。sh で動くのだろうか。bash でしか動かないような気がする。しょうがないので書き換えた。
後日 /.jp (スラッシュドットJP http://slashdot.jp/)でこの話をしたら、debian を管理する日本のチームに所属していると思われる人が言うに、これは bashism というれっきとしたバグなのだそうだ。debian でこのような箇所が見つかったのだとしたらここへ連絡してくれとリンクまで張っていた。しかし私のは Mandrake 7.2 でしかも最新版でもないので、こういう現象があるといことを教えてくれたことに感謝しつつ無視することにした。
キットの中にはなぜか mke2fs が入っていた。こいつは確かにキットでフロッピーディスクをフォーマットするために必要なのだが、Linux システムにならほぼ必ず入っているので、わざわざこのキットに入っている必要はないはずだ。DOS で言えば FORMAT にあたるコマンドらしい。
このキットの唯一いまいちなところが、この余計な mke2fs を動かすためにわざわざ何個もダイナミックリンクライブラリも入れていたりするところである。
# ldd mke2fs
libext2fs.so.2 => /lib/libext2fs.so.2 (0x40013000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x40026000)
libuuid.so.1 => /lib/libuuid.so.1 (0x40029000)
libc.so.5 => /lib/libc.so.5 (0x4002d000)
libc.so.6 => /lib/libc.so.6 (0x400e9000)
ld-linux.so.2 => /lib/ld-linux.so.2 (0x401d0000)
不可解なことに、キットには ld-linux.so.2 はなくて ld-linux.so.1 が入っており、その ld-linux.so.1 は使われていないことになる。また、libc.so.5 と libc.so.6 の両方をリンクするという奇妙な形になっている。調べたのは母艦上だが、おそらくフロッピーブートしたシステムでは使えていないと思う。
ほかにもバイナリを調べた結果、どうやら使っていたのは libc.so.5 だけだということが分かった。使っていないダイナミックリンクライブラリをすべて削除すると随分容量があいた。
Video4Linux と QuickCam Express サポートはあくまでドライバレベルであり、キャプチャするにはクライアントが必要だ。今回、いろいろ調べてみたが、満足のいくものが見つからなかった。有名なクライアントは大体 X 上でリアルタイムに表示したり録画したりするタイプのものだ。
バックグラウンドで動かして定期的に落としたりするタイプのものも結構あったが、どれも作りこみが甘く、作った人間の環境に特化した傾向が強かった。これというものが見つからなかったので、私が自分でサンプルコードをもとに簡単なクライアントを書くことにした。といっても本当に簡単なもので、使用デバイスは固定だし、明るさやコントラストや色合いなどを引数で設定する機能をつけたし、うまく機能していなかった明るさ自動設定機能を取り除いたりしただけだ。
ブラウザで見ることのできる画像形式は限られている。主に使われているのは gif か jpeg である。上で私が作成した簡単なクライアントは、サンプルコードそのままに ppm 形式の画像ファイルを出力するものだったので、そいつを jpeg に変換することにした。gif よりも jpeg の方がノイジーな自然画に合う。
jpeg 関係のツールはたくさんあるだろうと思って調べてみたら、案の定簡単に見つかった。私が選んだのは jpeg4b というツールだった。こいつをビルドすると、いくつかのコマンドができた。その中で cjpeg がエンコーダだ。こいつにパイプで ppm 形式の画像を入れてやると、jpeg に変換して出力してくれる。簡単だ。
実例を挙げると、v4l という私の作ったクライアントに cjpeg を噛ませて image.jpg に書き込むのはこうだ。
v4l | cjpeg > image.jpg
今回はやらなかったが、画像を変換するコマンドはいくつかあって、まさに自由自在である。たとえば、カメラを逆さにぶら下げて運用していたときは、画像を上下逆にするフィルタコマンドを使用していた。やったことはないが、日付やメッセージを画像に埋め込むのだって多分簡単にできるだろう。こういう自動化が得意なのが Unix 系 OS の特徴だ。
ウェブカメラと言うからには、本当はサーバとして機能してほしかった。つまり、この小さなシステム内に Apache ほど巨大ではないコンパクトな httpd を入れて、cgi によってカメラからキャプチャして jpeg に変換して表示する、といったことができなければ、市価数万円のウェブカメラとは比較できない。現にこういったことを以前やったことはあるのだが、そのときは容量があったので Apache をそのまま使ったので、ちょっとスクリプトを書いただけで楽勝だった。
しかし今回は容量がないので、先に述べたように ftp を使ってどこかのサーバに転送するだけにした。
ftp はそのまま使うとインタラクティブつまり対話式の操作を行わなければならない。しかし、コマンドなのでパイプで入力を入れることができる。
echo "put image.jpg" | ftp manuke.com
これを 10分に一度動かしていれば転送してくれるはず。…しかしこのままでは、アカウントとパスワードを入力するようプロンプトが出てしまう。これらを入力せずにすますには、.netrc という設定ファイルを書けばよかった。非常に簡単な設定ファイルで、ホスト名にアカウントとパスワードといったものをただ一行にダラダラ書いておけばよかった。注意するのは、このファイルのアクセス権限を自分しか見れない状態にしておく必要がある。
できたスクリプトは以下のとおり。
#! /bin/sh while echo capture do v4l --brightness 25000 --contrast 30000 --colour 32000 --hue 28000 --captime 6 | cjpeg > tmp.jpg ftp www.***.******.**.jp <<EOF cd public_html bin delete tmp.jpg put tmp.jpg delete cap4.jpg rename cap3.jpg cap4.jpg rename cap2.jpg cap3.jpg rename cap1.jpg cap2.jpg rename tmp.jpg cap1.jpg quit EOF sleep 600 done
まず tmp.jpg を作成し、それを ftp で転送する。転送先では、過去四枚までの画像を保存しておく。あとは、画像を見るための html ページを作成しておく。
これで完成だ。
ネットワークケーブルさえあれば、バッテリーだけで動くウェブカメラができた。無線LAN にすれば、いや AirH" にすれば、どこででも動くウェブカメラになる。まあドライバの問題があってまた一仕事することになるのだろうが、いろいろな可能性を残してこのプロジェクトを終えることにした。
というか、作ったはいいが目的がない。いまこのカメラは私の会社に置いている。これを書いている今日は休日なのだが、どうやら朝早いせいか会社には誰もいないようだ。こういうこともすべて分かる。だけど、それがわかってどうするのか。
結婚してまだ日がたっていない会社の H先輩は、会社の自分のマシンにカメラを接続し、奥さんに自分の働いている姿を放送しているそうだ。ときどき奥さんからチャットまで飛んでくる。H先輩は変わった人で、「監視されているんだよ」と大げさなことを言っていたり、結婚の契約は三年ごとに更新なんだよ、家にいると会社に行けとうるさい、家で自分は赤ちゃんより序列が下なんだ、とか言っているのだが、よく聞いてみると楽しそうである。
同僚の女性の前にカメラを置いて「○○○カメラ」にしよう、という話を一人の女性にしてみたが絶句していた。代表電話を受ける総務の人が開発の人に電話をまわすときに、席にいなくてつかまらないことがあって困る、という話が H先輩との話で出たので、じゃあ開発フロア全体を放送しようという話にもなったが、よく考えてみれば 10分間隔では話にならない。リアルタイムにすればいいのだが、そうやってシステムを作っても、自分たちがカメラの画像を見るわけではないのでつまらない。じゃあ総務フロアを放送しようかと言ってみたが、カメラの画像が荒すぎてあまり意味がないし、設置場所にも困る。
極論を言うと、目的なんてどうでもいいのだ。作って満足。
なんとこのシステム、USB でカメラをつけ放題なので、Video4Linux の制限の数だけカメラを運用できる。8台は確実にイケるだろう。マシンパワーと USB の帯域さえあれば、8ヶ所同時放送すら可能なのだ。
と想像するだけで今回は終えることにする。