第59回　いまさらながらVNC［その1］

先月からPlamo Linuxの主要メンテナの一人である加藤さんがLXC（LinuX Container）についての連載記事を始められたように、最近のLinux界隈では「仮想化」技術の開発が盛んです。

「仮想化」技術は一台のマシン上に複数の仮想PCや仮想OSを構築することを可能にし、あちこちに散らばったサーバを集約したり、開発用やテスト用のマシンを一台に統合したりできるので、ビジネス的にも大きな注目を集めています。

手元でも、Plamo Linuxの開発やテスト用に仮想環境は欠かせませんし、最近のマルチコアなCPUと大容量メモリを使えば、4、5年前の古いPCよりも仮想環境の方が快適に使える気がします。

しかし、仮想環境では対応できない仕事も残っています。たとえば、Windows用のドライバしか存在しない周辺機器を使いたいような場合、ソフトウェアとしてのドライバは仮想環境上でも動作するものの、仮想環境からハードウェアにアクセスできなければ、その周辺機器を利用することはできません。最近そういう問題に直面することがあったので、その経緯を紹介してみましょう。

VHDカラオケシステム

筆者の実家は、兵庫南部の山あいで古くから料理屋を営んでいます。そこでは、宴会の二次会等で遊べるように、90年代の始めごろからVHDのカラオケシステムを使っていました。

若い読者はご存知ないかもしれないので念のために説明しておくと、VHD（Video High Density Disc）とは、DVDが生まれる以前、1980年代に日本ビクターが開発したビデオディスクシステムで、LPレコードよりも一回りぐらい小さいディスクに記録した動画や音声のデータを、接触式センサーで読み取って再生する「ビデオディスク」システムです。

写真では紹介のために中身のディスクを取り出していますが、本来、このディスクは下に写っている「キャディー」と呼ばれるプラスチック製の薄いケース（ジャケット）に収められ、プレイヤーへの抜き差しもキャディーごと行うので、普通に使う限り、ディスク本体を目にしたり触れることはありません。

VHDは、ビデオテープに代わるセルビデオ用のメディアとして開発され、パイオニアが開発したレーザーディスクとセルビデオ市場を争いました。当初はVHDを支持するメーカーが多かったものの、画面の解像度が高く、CD同様「レーザー」で読み出すレーザーディスクの方が、AVマニアの間に受けがよく、80年代の後半には、ビデオディスク市場はほぼレーザーディスクが支配することになりました。

一方、VHDはチャプター単位の頭出し（ランダムアクセス）機能に優れ、ディスクも上記のようにキャディーに入っていて直接手で触れることがなく、埃や汚れに強いこともあって、スナック等の「ビデオカラオケ」の分野では長く生き残っていました。筆者の実家にあったのも、このようなVHDカラオケシステムの1台でした。

長く生き残ったといっても、2003年にはVHDカラオケの新譜は出なくなり、それに応じて実家のカラオケシステムも、ドリームキャストのカラオケシステム（ドリカラ）を経て、インターネット配信の「セガカラ」に移行して、VHDカラオケは5、6年前から撤去した状態になっていました。

しばらく前から、会計帳簿上に残っているVHDカラオケシステムを除却して、かさばるプレイヤーやディスクも処分しないといけないなぁ……、と思ってはいたものの、当時、1万数千円していたVHDディスクをそのまま捨ててしまうのは、ちょっともったいない気がします。

そこで、廃棄する前にディスクの内容をキャプチャしてmpegファイルで残してやろうか、と目論んだのが泥沼の始まりでした（苦笑⁠）⁠。

ノイズの多いメディアのキャプチャ

筆者は最近、すっかりテレビから離れてしまって、地デジ移行後のビデオキャプチャ事情には疎いものの、手元にはアナログビデオをキャプチャするには十分な、Linuxで動作するハードウェアキャプチャカードが残っています。まずはこのキャプチャカードを使ってVHDカラオケのキャプチャ作業を始めてみました。

手元にあるのは、Conexant Systems製のCX23416というMPEG2エンコーダチップを積んだPCI接続のキャプチャカードです。Linuxでは、カーネルレベルでサポートしているキャプチャカードは、V4L2（Video for Linux version2）という仕組みで操作するようになっています。V4L2の設定や情報の表示にはv4l2-ctlというコマンドを使います。

$ v4l2-ctl -D
Driver Info (not using libv4l2):
        Driver name   : ivtv
        Card type     : I/O Data GV-MVP/RX, GV-MVP/RX2W
        Bus info      : PCI:0000:05:03.0
        Driver version: 3.12.5
        Capabilities  : 0x81030051
                Video Capture
                VBI Capture
                Sliced VBI Capture
                Tuner
                Audio
                Read/Write

たとえば入力先を切り替えるには、v4l2-ctlに-iオプションを用います。

$ v4l2-ctl -I
Video input : 0 (Tuner 1: ok)
$ v4l2-ctl -i 2
Video input set to 2 (Composite 1: ok)

V4L2で使う場合、キャプチャカードからのmpeg形式のデータは直接/dev/video0に現われるので、特に専用のソフトウェアを用意しなくても、このデバイスファイルの内容をcat等でファイルにリダイレクトするだけで動画をキャプチャできます。

$ cat /dev/video0 > ~/BD-01.mpg &
$ smplayer ~/BD-01.mpg

VHDでは、ディスクの表裏それぞれに1時間ずつ、計2時間の動画が収録できる仕様になっています。そこで、1時間ほどスリープしてからキャプチャを止めるようなシェルスクリプトを書いて、自動運転でVHDカラオケのmpeg化を試してみました。

ところがキャプチャしたファイルを調べてみると、しばしば録画が途中で途切れています。時には、録画中にPC自体がリブートしてしまうこともありました。

使っているのがだいぶ年季の入ったキャプチャカードなので、ハードウェアレベルでおかしくなってるのかなと思って、キャプチャ中の状況を眺めていると、酷使されてきたせいか、VHDカラオケの中にはずいぶん状態の悪いディスクもあり、LPレコードの針飛びのように音と画面が飛んだり、くり返し同じところを再生してしまうことがあります。

また、画面全体にひどいノイズが走り、再生不能になって終了してしまうようなディスクもありました。どうやらその種のノイズがキャプチャカード経由でPCIバスに影響を与え、システム全体が不安定になるようです。

さて困ったな……、とあれこれ考え、USB接続タイプの外付けキャプチャボックスを試してみることにしました。USB接続ならば、マザーボード直結のPCIキャプチャカードに比べて、ノイズ源を電気的に隔離できるので耐性が高そうです。手元にはLinuxでは使えなくて放置していたUSBキャプチャボックスもあったので、余っているパーツでWindowsマシンを組んで試してみることにしました。

Windows機でのキャプチャ

急遽でっちあげたWindows機で試してみたところ、予想通り、USB経由でのキャプチャならば、少々ひどい画面ノイズが生じてもPCやOSが影響を受けることは無さそうです。

そこでWindows機とUSBキャプチャボックスで本格的にVHDカラオケのキャプチャを始めたものの、普段はLinux上で暮しているため、キャプチャの開始や終了、キャプチャしたファイルの移動等のために、一々Windowsに切り替えるのが面倒です。

手元では一組のディスプレイとキーボード、マウスを、キーボード切替器（KVMスイッチ）経由で複数のマシンから使っています。Linux（というよりはX Window System）の場合、管理が大らかなのか、KVMスイッチで出力先を変更してもXサーバやディスプレイドライバは構わず出力を続けるのに対し、Windowsではディスプレイドライバがリアルタイムで出力先をチェックしていて、KVMスイッチで画面を切り替えると「出力先が無くなった」と判断して画面出力が抑制されるようです。これ自体は妥当な動作と思うものの、キャプチャボックスに付属している専用ソフトウェアには抑制された画面出力を復帰させる機能が無いようで、一度KVMスイッチで画面を切り替えるとキャプチャ中のモニタ表示ができなくなってしまいます。

これでは使いもんにならんなぁ……、とボヤきながら、使っている液晶ディスプレイを調べてみると、VGA端子以外にDVI端子も用意されていることに気づきました。そこで、ディスプレイはKVMスイッチから切り離し、普段使っているLinux機をDVI側に、Windows機をVGA側に接続して、Windows機にも常にディスプレイを認識させてやることで、画面を切り替えてもキャプチャ中のモニタ表示は消えなくなりました。

しかしながら、KVMスイッチとディスプレイを分離した結果、今度はLinux機とWindows機を切り替える際、KVMスイッチでキーボードとマウスを切り替えると共に、液晶ディスプレイの入力選択スイッチまで手を伸ばさなくてはならなくなって、ひどく面倒です。

画面を切り替えるのにもう少し楽な方法はないかなぁ…、と考えていて思い出したのが、Windowsの画面をLinux環境に持ち込むことができるVNC（Virtual Network Computing）というソフトウェアです。

VNCは、いわゆる「仮想化」ソフトウェアとは異なり、あるマシンで動いている画面そのものを、別のマシン上に表示するためのソフトウェアです。

ネットワーク透過的に設計されているX Window Systemでは、出力先をDISPLAY環境変数で指定してやれば、任意のソフトウェアの画面を別のマシンに飛ばすことができます。一方、Windowsには「ネットワーク透過」という概念は存在せず、「⁠リモートデスクトップ」というサービスを使って、あるマシンで動いている画面全体を、別のマシン上に表示するような機能が提供されています。

VNCは、この「リモートデスクトップ」とほぼ同等の機能を提供するフリーなソフトウェアで、VNCサーバを動かしているマシンにVNCクライアントで接続すれば、サーバ側の画面をクライアント側に表示して、その中でマウスやキーボードを操作することができます。

Windowsの「リモートデスクトップ」機能が基本的にWindowsマシン間でしか使えないのに対し、VNCはフリーソフトウェアとして公開されているので、サーバとクライアントが異なるOSで動いていても接続することができたはずです。

実のところ、VNCは90年代の末ごろに最初のバージョンが公開された長い歴史を持つソフトウェアで、当初は「Linuxから（Windowsで動いている）Excelを使う」ことができるソフトウェアとして紹介されていたように思います。そのころ少しイジった記憶はあるものの、Linux上でWindowsアプリを使うことにあまり関心が無かったせいもあって、VNCのことはすっかり忘れてしまっていました。そこでVNCの現状について調べるところから始めることにしました。