KeyHoleTV開発秘話（その4）
Windows版KeyHoleVideoの開発
前回(KeyHoleTV開発秘話（その３） - KeyHoleTV開発者のブログ)で、インターネット上で高速に送信できるUDP/IPを使い、フレームを貯めることなしに動画の圧縮とエンコードを行うKeyHoleシステムの基本的な仕組みについて、説明をしました。 この仕組みは、GUIがないテストアプリケーションで検証を行ないました。 動画や音声に関しては、SDL
を用いて、Linuxでテストしていました。 また、WindowsにもMinGW
を利用していました。 また、この時、MinGWでは、Video For WindowsのライブラリがMinGWで利用できたので、ウェブカメラのキャプチャが可能でした。 この時、実験用のアプリは、gcc でコンパイルし、 Video For Windowsのライブラリがgcc で利用可能でした。 これは、 MinGWの開発用ライブラリに video for windows のライブラリが入っていたので、それを利用できました。
当時は、Windows用のビデオキャプチャは、DirectShow がありましたが、 これは、MicroSoftのVisual C++ の開発環境でしか、利用できませんでした。
.Net FrameWork の悲劇
実験用では、MinGWで十分なのですが、これでは、アプリのリリースをするとき、MinGWやGCCのDLL（ダイナミックリンクライブラリ）が必要になります。 また、GUIを構築する場合、文字列の表示が不可欠になりますが、当時のMinGWでは、Windows用のTrueTypeの利用が利用しずらい状況でした。
Windowsには、文字列を表示するのに、２つの方法があります。 一つは、Windows GDIと呼ばれる方法で、Windows GDIは、モニタのみならずプリンターにも対応できる仮想の出力ライブラリです。 MinGWは、Windows GDIのライブラリが用意されていたので、アプリケーションからの利用が可能でした。 しかし、当時のWindows GDI は、ビットマップフォントしか用意されていなかったため、小さい文字の表示（特に漢字など）が見づらい状況になっていました。 これを解決する方法は、 GDI Plus というライブラリで、Windows XPが登場してからWindowsの表示で殆ど利用されています。 Windows XPが登場したとき、 インターネットエクスプローラの表示で文字列が綺麗に表示されていたので、記憶にある方も多いと思います。 しかし、このライブラリもMinGWから利用できない状況でした。 (正確には、 MinGWでもCreateFont 関数を利用すれば可能で、GDI32ライブラリをリンクする必要があります。 しかし、 Video For Windowsは、別のライブラリが必要で、このライブラリとGDI32が競合したため、結局は利用できませんでした。）
当時は、あまりGUIに時間をかけたくなかったので、 .Net FrameWork を利用することにしました。 .Net FrameWorkは、 MicorSoftが提供している新しいアプリケーション開発・実行環境です。 当時MicroSoft は、 .Net Framework に力を入れており、全てのWindows機器で利用可能であると、謳っていました。 当然、 .Net Framework は、GDI plusも標準で装備されており、 簡単に文字列を表示したり、 ボタン等を配置することが可能でした。 また、根幹となる動画の圧縮エンコーダやサーバと通信するKeyHoleシステムのライブラリは、C言語で開発されており、そのライブラリとの親和性も良好でした。
一見いいことずくめに見える .Net Framework ですが、 .Net Framework は、開発環境であるだけではなく、実行環境でもあるということです。 実行環境というと .Net Framework のエンジンが搭載されていないWindows機器では、当然.Net Frameworkで開発されたアプリが動作しまません。 当時、著者は、MicroSoftの謳い文句を信用していて、 XPにはすべて .Net Framework のエンジンが搭載されていると信じていました。 ところが、 Windows XP Pro や自分でWindowsXPをインストールした場合、 .Net Framework は、オプションでインストールしない場合もありました。 これは、テストで、利用者にリリースした時、はじめて分かりました。 利用者が .Net Framework をインストールしないと、アプリが動作しないのです。
更に、利用者からボタンの配置やインタフェースへの要求が来て、それを変更しなけばならない場合がありました。 .Net Framework は、開発環境でもあるわけですから、表示されているボタンなどの配置は、 GUIエディタで行います。 GUIエディタでボタンを動的に動かしたり、あたらなボタンを配置したりします。 この変更を保存すれば、アプリケーションに反映されます。 しかし、 配置を失敗したり新しく作ったタブやボタンを消去したりしているうちに、突然GUIエディタが異常終了する場合がありました。 こうなれば、異常終了するまえの修正が保存していないと全て消え去ります。 こまめに保存して対応していましたが、 それでも異常終了するケースが増加して行き、殆ど修正ができなくなってきました。 GUIの部品の修正は、GUIエディタでできますが、 それを操作するためのは、 プログラムを修正しなくてはなりません。 プログラムの修正もGUIエディタと同一プログラムの Visual C++という開発環境ですから、 一つが異常終了すると、 すべてなくなります。
異常終了する原因の一つに、他のライブラリとの融合が考えられます。 通信や動画エンコードするライブラリは、 .Net Framework アプリケーションから呼び出しされるだけですが、動画を表示する処理は、DirectXを利用していました。 更にDirectXのサブ機能である DirectShow もライブラリ呼び出しをしています。 表示を司る .Net Framework に DirectX用の領域を儲けて、そこにデコードした動画を貼り付ける必要があります。 DirectX用の領域は、 .Net Framework で、別オブジェクトとして管理されいますが、 表示を扱う上での新和性が低い可能性があります。 DirectXは、CやC++で開発された表示を重視したアプリケーション用のライブラリで、Windowsが提供する表示に関する殆どのAPIが別ウィンドウとして表示する以外方法がありません。
このため、KeyHoleVideoのGUIは、C++で新たに構築し直し、GUIエディタを利用しないで、プログラムだけで、構築するようにしました。 ビデオの表示には、DirectXを使っています。
添付した図がWin32APIとDirectShow, DirectXで作ったKeyHoleVideoです。 全てのボタンは、Win32APIのWindowです。 それに、GDI Plusを用いて文字列を張り付けています。 また、表示している文字列も、GDI Plusで表示されています。
KeyHoleTVのダウンロード・プレミアムモジュールキーの購入は、
で。
