iOS15によるKeyHoleTV の修正
KeyHoleTVがIOS15で動作しない
iOS１５がリリースされた。 iOS14まで動作していたKeyHoleTVは、完全に動作しなくなった。KeyHoleTVを起動すると、以下のようなダイアログが表示された。
これらは、利用者から報告を受けたので、手持ちのiPhoneをiOS15にアップグレードして、XCode10で再コンパイルして動作させてみた。 同じダイアログが表示され動作しない。
XCodeのアップデートとMacOSのアップデートとMacの不具合
iOS15用のXCodeは、XCode13が必要で、XCode13は、MacOS 11.6 (BIg Sur)にしないといけない。 そこで、ます使っているMacMiniのOSを11.6にアップグレードし、その後、XCode13をインストールした。
XCode13を起動して、KeyHoleTVのXCodeのプロジェクトファイルを読み込ませてみると、すんなり読み込んで開発環境が整った。
デバックするためには、シミュレータを動作させる。 シミュレータは、XCodeのホタン一つで起動するので、起動して動作確認を行うと、シミュレータが起動せず、Macが落ちて再起動がかかる。何度やっても結果は同じ。 一応Macのセーフモードを起動してみた。 また、機器の動作確認を行うことができるので、それもやった見た。 特に問題は報告されない。 しかし、XCodeでシミュレータを動作させると、Macが落ちて再起動がかかる。 ここで、一応XCodeのバグ報告で現象をAppleに報告した。
KeyHoleTVが動作しない原因
シミュレータが動作しないので、手持ちのiPhoneで動作確認を行うことにした。 プログラムを実行させてみると、iPhoneのCPU消費が異常に増えていることが分かった。そして、プログラムが異常終了する。 iPhoneのアプリは、アプリが異常終了すると、main に戻ってどこで異常したかがよくわからない場合ある。少なくとも、KeyHoleTVのコードではなく、iOSのライブラリで異常終了している。
KeyHoleTVは、画面遷移のために、iOSのライブラリでUINavigationContoller, UIViewControllerを利用している。 KeyHoleTVは利用者名が登録されていない状態では、画面遷移して「既存の利用者名」と「利用者登録」のボタンを表示するUIViewControllerの画面に飛ぶ。 そこで、この画面に飛ぶ処理にブレークポイントを設置して動作させてみた。
すると、画面遷移をするライブラリメッソド(pushViewController:animated:)が画面遷移せず、何度も呼び出されていることが分かった。
KeyHoleTVはタイマーのメソッドを利用して、画面遷移の状態を管理する値により処理をする仕掛けを用いているからで、遷移した後、状態を変更して再び、遷移しないようしていた。 この仕掛けは、利用者名の入力やパスワードの入力をすると、ログインボタンが有効になるような処理を行っている。
iOS14までは、遷移をさせると、viewWillAppear: や viewDidAppear:のメソッドが呼び出されていた。KeyHoleTVは、viewWillAppearの処理の中で、遷移の状態の値を変更していた。 何度も画面遷移を呼び出していることから、viewWillAppearが呼び出されないことが判明した。 そこで、iOS開発のドキュメントを調べてみると、
Note
If a view controller is presented by a view controller inside of a popover, this method is not invoked on the presenting view controller after the presented controller is dismissed.
となっていた。 元の UIView Controller は閉じていないが、viewWillAppearが呼び出されない。 理由はわからないが、呼び出されないので、画面遷移のライブラリメッソドを呼び出した後で、画面の状態を管理する値を変更してみた。 すると、画面遷移が行われた。
画面遷移が行われたが、ボタンの表示が無茶苦茶になった。KeyHoleTVは、viewDidAppearで画面上のボタンの配置を行っているからで、viewDidAppearが呼ばれない状況では、正しく画面の配置がなされていない。 ここで、しばらくハマった。画面遷移が行われる直前に画面の内容を変更したいが、うまく行かない。 ここで、色々試してみたが殆どがうまく行かない。
Mac MINi SSDの問題発生
何度もプログラムを作りデバックしていたが、突然XCodeでコンパイルの最中にMacが落ちて再起動するようになった。 何度もハードウェアのチェックを行ったが、エラーは見られない。 セーフモードで起動した時だけうまく動作する。しかし、セーフモードで起動すると、iPhoneとの接続でデバッグが出来ない場合があった。 当然シミュレータは立ち上がらない。
遂にAppleにコンタクトを取って状況を説明してみたが、彼らは、私が出した不具合の報告を読んでおり、解決策が見つけられない。
そこで、フット気がついたことがあった。 Mac Miniは、SSDう。を使っている。SSDは、USBメモリと同様で書き込み回数に制限がある。例え使用したファイルなどがディスクの容量未満であっても、一度書き込んだデータは、絶対に消えず、消したというフラグが立つだけ。更にディスク管理のアプリは、どのくらいSSDの有効領域があるかを教えてくれないし、システムチェックでも引っかからない。
XCodeは、コンパイルしたデータを一旦保存しそれらをリンクする。この作業を繰り返し行うとSSDの寿命が減少する。 おそらく、これが原因でMacが落ちたりするのであろうと想定して、外付けのハードディスクを購入した。 外付けのハードディスクが当着した後、バックアップを取ったり、起動ディスクを構築したり、ホームフォルダを外付けディスクに移動した。 これらの作業の結果、XCodeでシミュレータが起動するようになり、Macも落ちなくなった。
viewDidLayoutSubviewsによる解決
開発ドキュメントを色々読んで見た結果、viewDidLayoutSubviewsが使えるかも知れないと思い、プログラムを実装した。 この結果pushViewController:animated で遷移した時は、一度だけ呼び出されることが分かった。また、デバイスが移転した時も呼び出される。 これは、AutoLayout と呼ばれる機構が実装されたからで、ストーリボードを使った場合、UIViewControllerに配置する部品の位置を関節的に設定でき、デバイスの大きさが変わっても、相対的にボタンなどがうまく配置される。 しかし、KeyHoleTV
は、ストーリボードを利用していないので、プログラムで設定する必要がある。 最初は、自動レイアウトするようにプログラムを記述したが全く動作しない。おそらく何らかの初期状態の設定が必要だと思う。
著作権法とKeyHoleTV （その２）他のシステムの場合（SKYLIVE NET TV)
現在、ネット上では日本のテレビ番組を見る、ラジオ番組を聴くために様々なシステムが存在している。 日本国内であれば、著作権法をクリアしているTVerやラジコ等があるがこれらのシステムは、残念ながら海外では利用できない。過去にはVPNを利用して視聴が可能な時期もあった。しかし、VPNはアドレスが特定されているので、TVerやラジコのシステムが特定のアドレスを排除すれば使えなくなる。 同様にアマゾンプライムビデオやNetFlixといった動画サイトでも、VPNからの接続に関して制限を設ければ海外からの利用はできなくなる。そのため、出張や赴任なので、海外にいる日本人は、他のシステムを利用せざる負えない。
また、ProxyとVPNを組み合わせのサービスがでてきている。これである程度Tverやアマゾンプライム、NetFlixの視聴は可能なる。しかし、Proxyとして番組を他の媒体で記憶させ、他の第三者にそれを渡してよいかという問題があり、ある程度時間が建てば、Tverやアマゾンプライム、NetFlixなどが対策をとる可能性がある。相手のアドレスがわかれば停止されるし、Proxyに蓄えないで利用者単位の個々の通信を行うようならば、大量の通信が特定のアドレスに偏る。そうなれば、対策され停止させられる。更に、Tverは契約がないため問題ががないと思う。しかし、NetFlixやアマゾンプライムビデオでは登録した国でしか基本的に視聴できない契約になっている。これを破って視聴すると、何らかの法的な問題を抱えることになる可能性がある（判って違反しているので、民事訴訟ではなくなる可能性もある。）。
全てのVPNシステムに共通する問題として、少数の利用に関しては特に問題は発生しない。しかし、利用者が増加し、その利用者がビデオ受信をするとあっという間、VPNサーバの通信帯域幅を超えてしまう。そうなると、当然視聴はできない。
KeyHoleTVシステムは、著作権法に対して回避できる法的な根拠がある。しかし、他のシステムでは著作権法を回避できる法的な根拠があるのかを調べてみた。
これから示す多くの海外から日本のテレビを視聴を提供するウェブサイトは、残念ながら日本国内からアクセスできない。アクセスすると、
や
のようになってしまう。上記の画像は、海外から日本にあるVPNを介してアクセスした結果を表示している。 KeyHoleTVは、海外からも日本からもアクセス可能で、日本のテレビを視聴するアプリケーションは、海外はもとより日本国内でも利用可能だ。
日本からのアクセスできないサイトを検証するためには、海外のVPNサーバまたはブラウザ検証サイトを用いればよい。 ブラウザ検証サイトは、browserlingと呼ばれていてアクセスすると以下のようなページを表示する。
アドレスバーにURLを入れると、そのサイトが表示される。 日本からアクセスしても表示されないサイトでもサイトの内容を確認できる。
このサイト(https://skylivetv.net/)にアクセスすると、Chromium ブラウザでは、安全な接続でなないと警告がでる。 また、このサイトは、日本からのアクセスができないので、
上記のbrowserlingを利用してアクセスする必要がある。
これを無視して内容を表示させると
となる。内容を見てみると、このサイトにはプライバシポリシーの記載がない。この記載がない場合、このサイトをアクセスしたり、アプリをダウンロードして実行すると、利用者の情報（クレジットカードの番号や住所等）がこのサイトを運営している会社にダダ漏れになる。
利用方法をクリックすると、
のような表示になる。少なくとも、現在はパスワードを取得しないと内容が確認出来ないようだ。 以前は、利用法を選択すると、
となっていた。Winodwsを選ぶと、SnowPlayerがインストールされる。Macを選ぶと
IPTV1.4 がダウンロードされる。IPTV1.4は、ZIP形式になっているので、展開してアイコンをディスクトップに移動すれば、アプリケーションが利用できる。 iPhoneやiPad
では、EasyAppIconをインストールする。
まず、Windows用のSnowPlayerから見てみよう。SnowPlayerは、インストーラが梱包されたEXE形式で配布される。 安全性が確認できないソフトウェアをインストール出来ないので、同様なアプリケーションがgithubに置いてあるので、それをダウンロードした。するとZIP形式のファイルになっている。 安全性を向上させるために、UbuntuでダウンロードしZIPファイルを展開した。
ZIP形式を展開すると、
となっている。これだけ見ると問題がないように見える。 しかし、問題は、plugins フォルダだ。 このフォルダを開くと、
と1つのフォルダと１つのファイルが表示される。 ここで問題なのが、misc_shelldll.dllだ。Googleでこのフィアルを調べると
と出てくる。 その内容は、3072 バイトのファイルで、プロセスを生み出すDLLとなっている。 プロセスの種類によっては、悪意のある場合もあるようだ。 misc_shelldll.dllのファイルの大きさは、3.1 kb となっている。しかし詳細を見てみると、
となり、3072 バイトの大きさであることから、上記のDLLと同じものだと想定できる。次にpluginsフォルダにあるbassの中身を見てみよう。
bassフォルダには、bassに関連したようなdllが入っている。 この中で、ファイルサイズが最も大きいのは、bass_aac.dll で、ファイルの詳細配下のようになっている。
また、bass_aac.dll の作成された日付は、
で、２０１０年となっていて、結構古いバージョンであると想定できる。 このbass_aac.dll は、複数のサイトで複数のバージョンのDLLをダウンロード可能になっている。 例えば、Bass_aac.dll Download - DLL 4 Freeでは、
３つのバージョンのダウンロードが可能になっている。 このサイトで示しているファイルサイズは、146.2 KB, 146.3 KB 147.0 KBとなっており、SnowPlayerで配布されるDLLのファイルサイズ（151.4 KB)とは異なっており、配布されるDLLの方が大きい。バージョンが古い場合があるので、おそらく最新のバージョンを配布しているあろうサイトでは、
となっている。 ファイルサイズが近いので、ダウンロードしてみてファイルの大きさを比べてみた。
新しいバージョンは、2019年の作成、ファイルの大きさはは、SnowPlayerで配布されているものより大きい。 何らかの機能が追加されたものと想定する。 では、SnowPlayerと一緒に配布されているbass_aac_dll は、何故古いバージョンにも拘わらずファイルサイズが大きのかという問題がある。これは、misc_shelldll.dll と密接な関係があると想定できる。 misc_shelldll.dll はプロセスを生成して実行するDLLだ。必要なDLLを実行する分には問題がない。しかし本来の機能以外に何らかの別の処理を行うようなDLLが合った場合、おそらくウィルスもしくはマルウェアという扱いになる。即ち、bass_aac.dllに余計な機能が付加されそれがmisc_shelldll.dllでプロセスとしてPC上で実行される。従って、SnowPlayerをダウンロードして実行するのは、大変危険でトロイの木馬の可能性も否定できない。
Mac版を見てみよう。 Mac版をダウンロードすると、IPTV_1.4.zip がダウンロードされる。これを解凍すると。
IPTVアプリケーションが得られる。 これをダブルクリックするとアプリケーションが起動する。Macの場合Windowsと異なって、アプリケーションだけがインストールされるので、基本的にOSに関連するファイルへの書き込みはない。
実行してみると、無料視聴用のNHK教育放送があったので視聴した。 視聴中どんな通信を行っているかをnetstat で調べてみた。すると
多くの通信が張られている。これらのアドレスを検索すると、通信相手は、中華人民共和国だった。通信の接続が達成（ESTABLISHED)されているので、Macに保存されている個人情報等のファイルが相手に送らられる可能性がある。視聴している間に個人情報が抜かれる金券性が高い。また、どこと通信しているのかをtcpdumpで調べた見た。
通信相手は、183.61.242.60からで中国の Dongguan市からだった。 テレビ映像の通信は、183.61.242.60で、通信を確立してるのが他のアドレスであるため、映像や音声のデータではなく確実に何らかの情報を送信もしくは受信している。 このため、IPTVを利用するのは、大変危険であると云わざる負えない。
iPhone, IPad用のアプリを見てみよう。 iPhoneやiPad用のアプリケーションは、EasyAppIconと呼ばれるアプリケーションをiOSデバイスにインストールするようだ。
過去EasyAppIconは、AppStoreに掲載されていた。しかし現在はなくなっているようだ。このアプリケーションは、アイコンを作るアプリケーションのはずで、TV番組の視聴を目的としていない。しかし、このアプリケーションは、アイコンの作成（丸に＋）ボタンをタップして、アイコン名を入れる際、「tv:www.allipcast.com」と入力してから、Playボタンをタップすると、ログイン名とパスワードを聞いてくる。 正しくログイン名とパスワードを入力すると番組表が表示されるようだ。 AppStoreから締め出されているような偽装アプリを利用する方法は、本システムが著作権法に対して有効な法的な根拠を持っているとは考えづらい。 同様に、SnowPlayerでは、トロイの木馬の可能性のあるアプリを配布、Mac版のIPTVでは、番組とは関係がない複数のサイトと勝手に通信を結ぶ、 これらのことからも著作権法に対して有効な法的な根拠がないものと想定できる。
IPTVの遅延を見てみる。
番組が表示している時間と時計を見くらべてみると、およそ２分以上の遅延がある。これでは、緊急時の速報として役に立たない。 ”リアルタイム”を謳い文句としているが、２分以上の遅延ではリアルタイムを謳うことはできない。２分遅れの電話の会話は、可能かどうか考えてみてほしい。 このような遅延があるようなシステムでは、
著作権法に対して有効な法的な根拠は存在しない。 これを利用されている利用者にも著作権法が適応される可能性が高い。
著作権法とKeyHoleTV （その１）
著作権法と放送の現状
著作権法が改正され、２０２１年１月１日に施行された。
これにより、配信者はもとより視聴者もこの法律に適応される可能性が出てきた。
KeyHoleシステムによる配信は、２００８年から行われている。 総務省にも再送信の許可を求めることを行い、在京のテレビ局にも説明をしている。 残念ながら、総務省から返答は未だない。 また、テレビ局や広告代理店も番組やコマーシャルに関する複雑な法的な問題（著作権だけではなく、動画に登場する人物の肖像権や品物の放映権など）により特別な場合を除いて、再配信が許可できないとの回答を得ている。
さて、特別な場合とは何を指すのかという点がある。 地上波がアナログ放送の時、ケーブルテレビは、それほど多くなかった。 更に電波の使用に関して地域性が重視されていた。このため、地域により電波の周波数が異なり電波が届く領域で同一の番組を視聴できるようにしていた。しかし、電波が届く範囲の末端では、複数の局の電波が受信できていた場合も存在した。
有線テレビ放送（ケーブルテレビ、光テレビ、IPTV）
ケーブルテレビは、電波の届く範囲を超えて放送を提供できるため、一部の地域を除いて、ケーブルテレビの認可は、されていなかったと推察できる。 ところが、地上波デジタル放送になってから、ケーブルテレビの認可が増えた。 これは、地上波デジタル放送がアナログ放送自体のVHFより高い周波数を用いたUHFを利用したためと考えられる。 周波数の高い電波は、直進性が増し、情報量が増える。 アナログ放送の場合、情報の損失があっても、受像機は映像や音声を表示や音を出すことができた。しかし、デジタル放送では、情報が欠落しすぎると情報の復元ができず、全く映らないといった現象が生じる。更にUHFにより直進性が増した電波では、高層建築物等の影響により都内であっても電波が届きにくい地域が生まれた。
これを解消するためにケーブルテレビ（光ファイバを利用したり、IPTVを利用したりする場合もある）が認可が増えたと考えられる。同時に東京スカイツリーが生まれた原因の一つには、高い塔から発信する電波は、高層建築物の影響を受けにくくするためであるとも推察できる。
情報伝達と放送法
放送業者は、免許制である。だれでも勝手に電波を使って放送することはできない。免許を与える上で、放送法があり、報奨業者はこの法律に適応しなければならない。
様々の条文が記載されているが、その中で国民生活に重要な点の一つとして
第百八条 基幹放送事業者は、国内基幹放送等を行うに当たり、暴風、豪雨、洪水、地震、大規模な火事その他による災害が発生し、又は発生するおそれがある場合には、その発生を予防し、又はその被害を軽減するために役立つ放送をするようにしなければならない。
がある。 この条文では、発生の予防や軽減のための放送を行うとある。このため、「緊急地震速報」はテレビ番組やコーマシャルの放送中でも視聴者に届けるようになっている。また、災害地域での情報をいち早く伝えている。
KeyHoleTVと地デジの配信速度
KeyHoleTVは、地上波デジタル放送を再送しているが、ワンセグに関しては、ワンセグ受信機より早く情報を伝達できる。
上記の動画は、ワンセグ端末とKeyHoleTVの受信時間の比較である。KeyHoleTVの方が早く受信できている。
東京の番組を地方で地デジで受信する場合、東京で地デジを受信し配信してもKeyHoleTVの方が早い場合がある。これは、地デジが地方局に情報を伝える場合、一度デコードして映像や音声情報を取り出し、地方の情報と取り出した映像や音声を再びエンコードするためだと想定する。 このため、東京でエンコードしたKeyHoleTVの方が早く情報の伝達ができる。
上記の動画は、大阪で受信した地デジの映像とKeyHoleTVを比較である。 KeyHoleTVの方が早く映像を受信しているのが分かる。東京から大阪まで、地デジで何回デコード’・エンコードをしているのか詳しくは分からない。しかし、距離が伸びればデコード・エンコードの回数が増えると想定でき、その結果遅延が更に増大すると予想できる。
KeyHoleTVの配信システムは、地上波デジタル放送を受信してから再送信しても、地域によっては基幹放送局で地上波を受信するより早い場合がある。このことから、仮に地上波にエンコードする前に基幹放送局がKeyHoleシステムを使って配信すれば、より早く情報の伝達が可能になる。また、インターネットを利用した地上波の受信の多くは、海外で利用可能で日本国内では利用できない。しかし、KeyHoleTVは、海外はもとより日本国内でも利用可能になっている。 日本国内で利用できないようなインターネットを利用した地上波の再配信は、自分たちが著作権法に何らかのかたちで抵触している可能性を考えていると想定する。 しかし、KeyHoleTVでは配信速度が地上波より早く送信できるため、「緊急避難」という法律が適応されると考えている。 この点は、法的な根拠があり、司法関係者からも同意を得ている。
KeyHoleVideoによる配信で情報共有の高速化
KeyHoleVideoによる配信は、「緊急避難」という法律の適応が可能なため、改正された著作権法でも配信の停止を著作権者が訴えることができない。また、改正された著作権法では、視聴者にも適応される可能性があるが、KeyHoleTvの視聴に限ってはKeyHoleVideoの配信と同様に「緊急避難」が適応されるため問題が発生しない。ただ、ここで、注意しなければならない点として、KeyHoleVideoを用いて、衛星放送の配信やケーブルTV等の有料放送の再配信だ。 これらの放送は緊急用の放送としては、受信するまでの遅延が大きいため役に立たない。 このため、KeyHoleVideo再配信を行うと、上記の「緊急避難」が適応されないので注意が必要だ。
KeyHoleVideoによる再配信は、無料のプレミアムモジュールキーを取得できるため、自分で配信した番組や他の番組を、自分の端末でどこでも視聴ができる。放送局がある地方がKeyHoleVideoで再配信を行えば、配信している地方はもとより他の地方では、地上波デジタル放送より早い情報が獲得できる。 KeyHoleVideoでプレミアムモジュールキーが無料で取得できるシステもを構築したのは、日本全国のテレビ番組やラジオ番組を再送信して、地域を超えた情報の共有を願っている結果に過ぎない。
意外と知られていない家庭内のパケット落ち
ルータやルータ機能付きモデム
KeyHoleTVを利用している利用者から、動画が止まったり、音が停止する現象があると、度々報告された。例えば、昨日まで問題なく利用できたのに、今日はダメといった具合だ。 この問題に対して、こちらの環境では、問題が発生していないため、利用者の環境を詳しく聞いた。
この結果、分かったことは、
（１）WiFiルータが他人に利用されている。
WiFiルータにパスワードを設定していれば、問題がないと思っている人は、数多くいる。 しかし、隣人のPCがウィルスに侵されている場合、パスワードの解析などは、ウィルスがバックグランドを行う。別に時間がかかっても構わない。また、解析できなくてもよく、気長に行っている。そして、ある日突然、他人のネットワーク環境が劣化する。
ウィルスが他人のWiFiを介して、DOS攻撃に利用されている場合もあるが、ウィルスに感染しているPCは、他人のWiFiを使っているため、使用者本人の環境では、通信速度の低減が見られないので、不都合がない。しかし、利用されている人には、たまったものではない。
この解決法は、MACアドレスフィルタを利用する以外方法がない。WiFiを利用する機器には、MACアドレスと呼ばれるアドレスがある。WindowsPCでは、AA-BB-00-.. といったWiFi機器の番号で表現される。 他のOSでは、AA:BB:00...といった形で、表現されている。
このアドレスをWiFiルータやWiFiルータ機能を持った光・ADSLモデムが持っているMACアドレスフィルタに登録して、登録している機器以外、WiFiの利用を禁止する。
MACアドレスフィルタにより、他人の介入がなくなり、KeyHoleTVも無事視聴することができた。
（２）ルータ内部で、パケットを捨てている。
ルータは、接続している機器のアドレスと対象機器で動作しているアプリケーションが利用するポート番号を管理して、インターネット側から送られてくるパケットを対象機器に送信する。 ルータやモデムの機種によっては、管理しているテーブルに送受信したパケットの数を管理しているのではないかと想定する。（これは、内部仕様がないため、確証が得られないので、確かめられない。）
自宅で利用している光ファイバ用のルータ機能付きモデムでは、WiFI接続を継続して利用している機器が徐々にKeyHoleTVの映像が乱れる現象が現れた。 他のWiFiを利用している機器や有線接続をしている機器では、同様の問題は発生しない。 このような現象から、当該機器のWiFiを一旦切って、再び接続すると、映像が乱れることもなく、視聴できた。
以上のことから、ある種のルータやルータ機能付きモデムは、内部に接続する端末を管理するテーブルがあり、到着したパケットの数をカウントする機能があると推察する。また、パケットの数をカウントし、その数が一定数以上を超えると、パケットが優先的に捨てられると推察できる。おそらく不具合だと思う。
WiFiを利用する端末によっては、端末がスリープモードになった場合にWiFiを自動的に切断し、スリープが解除されると再び接続する機器も存在する。 このような端末では、KeyHoleTVの通信障害が起こりにくい。また、TCP/IPを利用するブラウザなどでは、あたかも通信速度が低下しているように見える。 例えば、ローディング中を示すマークが頻繁に出たりする。
アップデート等を頻繁に行う機器では、スリープモード中もWiFiが常に生きており、パケットの数をカウントアップして、ある日突然通信が遅くなったりする場合がある。このような現象を改善するためには、WiFiの接続を一旦切って、再び接続すると改善する。
中国からインターネットを利用する場合
中国国内から、ブラウザを使って、google.com や YouTUBEへのアクセスは、基本的にできない。中国国内から、暗号化されたパケットを海外のサイトにブラウザを使ってアクセスすると、多くの場合応答がない。 これは、ブラウザのアクセスがTCP/IPと呼ばれる通信プロトコルを利用しているため、発生する現象である。
TCP/IPの通信は、必ず成功し、失敗する場合、エラーを相手に返す仕組みである。TCP/IPの通信が成功する仕組みは、パケットが届いた場合、届いたことを知らせるパケットを送り返すことで達成する。また、届いていないパケットがあると、再送する。
さて、中国国内から、インターネットのアクセスは、中国のプロバイダを介して行っている。 プロバイダは、どうも一定の量の通信が特定のアドレスに暗号化したパケットを送信する場合、一部のパケットを欠落させる仕組みがあるようだ。また、通信量が増えれば増えるほど、欠落するパケットが増える。
中国国内から、goolge.com へのアクセスは、google 側から送信したパケットがいくつか到着しないので、再送を繰り返し行うことになる。 更に、再送してもパケットが到着しないので、サーバ側が通信を切断する。 これが、中国国内からgoogle.com へのアクセスができない原因である。
インターネットのパケットは、必ず相手に到着するという保証がない。 このため、中国のプロバイダがたとえ意図的にパケットを損失させても、問題がないと言える。また、日本国内でも、帯域制限と謳って、意図的にパケットを損失させる機構が存在する。これは、日本国内で、WiFiルータを借りて、通信を行い、KeyHoleTVのサーバと通信させてみて分かった点である。
KeyHoleTVの場合、ある程度パケットが損失しても、問題が無いように設計している。当然パケットが届かないので、動画乱れたり、音が飛んだりする場合もある。しかし、何日も利用していると、音が止まったり、動画が完全に停止してしまう。これを解決するためには、自分のアドレスを変える以外方法がない。プロバイダが意図的にパケットを欠落させているので、アドレスを変えて、一定以上のパケットが到着しないようにするしか方法がない。
アドレスを変える方法は、モデムの電源を切って、再び入れる。 携帯電話の場合も電源を切って再び入れる。 これで、プロバイダにより割り振られるアドレスが変わる。 残念なことに、集合住宅では、通用しない場合が多い。 これは、集合住宅にメインのモデムがあり、それがプロバイダよりアドレスが割り振られ、個々の居室にあるモデムは、独自のアドレスになっているためで、居室にあるモデムの電源を切って、再び入れても、内部のアドレレスが変わるだけで、メインのアドレスが変わらない。このような場合、携帯電話のデザリングを利用して３G/4Gを経由携帯電話をルータとしてPCを利用するしか方法がない。
KeyHoleTVは、他の動画システムに比べて圧倒的に通信量が少ない。 また、ほとんどの動画サイトでは、最初に大量にダウンロードするため、途中で動画を停止しても、すでにダウンロード済みとなってしまう。 このため、動画サイトの動画をザッピングすると、あっという間に制限容量を超えてしまう。 一方、KeyHoleTVは使った時間しか通信を行わない。このため、使用量が利用者にとってわかりやすい。
ポケットWiFiのパケット落ち
日本は、住民登録を証明する書類などがないと、携帯電話を所有することは基本的にできない。海外からの旅行者などは、空港などで、貸出携帯などを利用する。また、インターネットを利用するためには、ポケットWiFiまたはWiMAXと呼ばれる３G/４G回線などを利用した小型のWiFiルータをレンタルする。
ポケットWiFiは、様々な契約プランが用意されている。 この契約プランのなかで、定額サービスの場合が曲者だ。定額サービスでは、一定以上の通信を行うと、通信速度が低下する。 著者が調べた結果、サーバ側で、およそ128Kbps以下の通信を行う仕組みを提供しても、決して128Kbps の通信をせず、単純にパケットを捨てている点が曲者である所以だ。
例えば、KeyHoleTVは、音だけの番組では、通信速度は128Kbps 以下になる。これは、著者がT-Mobile（当時の通信速度は、64kpbs)の端末で音だけの番組を視聴した結果、長時間利用可能であったことによる。当時のT-Mobile の端末は、Windows Moble の端末でKeyHoleTVでは、古いWindows Mobile でも動作させていた。KeyHoleTV開発秘話（その５） - KeyHoleTV開発者のブログ
しかし、ポケットWiFiの通信制限を超えた場合で、KeyHoleTVを利用すると、音が飛び飛びになることで、パケットを意図的に捨てていることが明らかになった。
オーストラリアでのパケット落ち
オーストラリアでは、インターネットの利用は基本的に従量制である。これは、ポケットWiFiの利用と似ている。 また、プロバイダによっては、定額料金で一定以上の通信を行うと、通信速度が低下する契約も存在する。 ここでも、通信速度の低下が問題になる。通信速度の低下は、単純にパケットを捨てているので、サーバ側がいくら通信速度をプログラム的に落としても、決して端末にパケットが届かない。
オーストラリアでは、従量制のインターネットを利用するほうが、KeyHoleTVを利用する上では、有効であると思う。 この場合、3G/4G 回線を利用したKeyHoleTVの利用が有効だ。 KeyHoleTVの場合、通信速度は、動画でも350 Kbps以下で必ず抑えている。
日本のテレビを見ることができるKeYHoleTVとOISEYER Inc.で、示したように、KeyHoleTVの通信量は、他のシステムよりはるかに少なくて住む。このため通信容量に制限があっても、一月で超えることは少ない。 また、他の動画システムの場合、開始直後にダウンロードする量が比較的多いため、単純にザッピングを行うと、視聴した動画のデータ容量に比べて、ダウンロードする量が多い。 このため、少ししか観ていないのにも拘わらず、通信量が増える結果になってしまう。一方、KeyHoleTVは、視聴した時間だけの通信を行うので、視聴時間で通信量が分かる。
KeyHoleTVのダウンロード・プレミアムモジュールキーの購入は、
Android Native Activityによるキーボード処理 （その１）
Native Activityでのソフトウェアキーボードの利用の困難さ
Native Activity のOpenGL ESを使ったアプリケーションは、Androidが提供する様々な機能が利用できない。最も大きいのは、ソフトウェアキーボードだろう。 Androidアプリケーションで、名前の入力やURLの入力には、ソフトウェアキーボードが表示され、そこで、入力した文字や記号が入力領域(EditText)に反映される。 日本語対応のソフトウェアキーボードでは、連文節かな漢字変換をおこなったり、予測変換の文字列が表示されたりする。 候補をタップすることで、候補の文字列が入力領域にはいる。
ソフトウェアキーボードをNative Activity のOpenGL ES環境下で、表示するには、
に示されているが、NDKでイベントを扱うには、結局
の回答にあるように、
static int32_t engine_handle_input(struct android_app* app, AInputEvent* event)
{
if (AInputEvent_getType(event) == AINPUT_EVENT_TYPE_KEY)
{
lint32_t key_val = AKeyEvent_getKeyCode(event);
fprintf("Received key event: %d\n", key_val);
if*1
{
fprintf("Got a letter");
}
}
return 0;
}
となる。
AKeyEvent_getKeyCode(event); で、全てのコードが取得できればよいが、取得できるコードは、
で定義されているコードだけになるようだ。 例えば、！マークや％記号のコードは、定義されていない。これらの記号は、お使いのキーボードをご覧になれば、一目瞭然で、シフトキーを押したときのコードになる。 更に、かなや漢字などの文字列が、上記の入力処理のeventに送られてくるはずがない。
AndroidのJAVAの入力領域(EditText)とキーボードは、別のアプリケーションになっている。 しかし、その間を取り持つインターフェースは、inputconnection となっていて、両者が密接に関係している。 下記のサイトは、独自のキーボードの実装をコードベースで説明している。
上記のNewKeyboard.java中の、commitText("1", 1); で、文字列を入力領域に送っている。 この入力をNative Activity のOpenGL・ESのアプリで取得するためには、JNIを使って取得する必要がありそうだ。さて、JAVAのアプリでは，どのような記述でキーボードを表示しているか見てみる。
上記のサイトによると、JAVAのコードでは、
public class MainActivity extends AppCompatActivity {
private EditText editText;
@Override
protected void onCreate(Bundle savedInstanceState) {
...
editText = findViewById(R.id.edit_text);
...
となっていている。 ソフトウェアキーボードは、アクティビティの起動時に既に表示されている。で、自動的に入力領域(EditText)にソフトウェアキーボードで入力した文字や記号が反映される仕組みになっているようだ。 すなわちソフトウェアキーボードで入力した文字や記号は、
commitText("入力した文字や記号、文字列など", X); でどこかに送信され、アプリケーションがその情報を取得して、入力領域(EditText)に反映していることになる。 JAVAのアプリケーションプログラマは、commitTextで送信された情報を取得したり、入力領域(EditText)に表示する処理を記述する必要はない。 これらは、Android用JAVAの部品が行っている。 しかし、Native Activity のOpneGL・ESで構築されたアプリケーションでは、この一連の処理を自分で記述する必要がある。
Native Activity では、OpenGL の表示処理やイベントの入力のためのメインループがある。 このメインループは、何らかの処理を呼び出して、その処理が終了するまで、待機させることができない。 待機させると、画面の書き換えが起こらないため、フリーズしたようになる。 他のアプリケーションが、commitText を発行した時に、どのようなイベントが発生するのか、また、何かのコールバックが呼ばれるのか、ネットで検索しても記述を発見できなかった。
単純に英数字だけの入力なら、ソフトウェアキーボードを利用することができると予想する。 しかし、かなや漢字がある場合、その利用が困難になる。 記号の場合も同様で、
Input | Android NDK | Android Developersに表現されてる場合、コードが求まるが、そうでない記号は、上述のcommitTextで記号が送られてくると予想される。
GUIライブラリでのソフトウェアキーボードの実装
Androidに付属しているソフトウェアキーボードは、Native Activity のOpenGL ES環境下のアプリケーションでは、表示ができても、記号などの入力を獲得することが難しい。 更に日本語などは、実装が更にハードルが上がり、殆ど不可能に近い。 そこで、GUIライブラリ（
Android, WindowsCE KeyHoleTV - KeyHoleTV開発者のブログ)の表示機能を使ったキーボードを実装した。 実装にあたり、次の要件を満たすようにした。
（１）英字キーボードの配列は、１０１と同じにする。
（２）記号と数値は、Shitを押して操作するのではなく、記号や数値ボタンをタップして、記号キーボードや数値キーボードを表示する。
（３）UTF-16LEの入力機構をもち、コードで文字の入力を可能にする。
（４）ひらがな２文字までの漢字辞書を持ち、候補を表示する。
（５）ひらがな３文字以上は、連文節かな漢字変換を用いる。 連文節かな漢字変換は、ネットワークを利用したエンジンを利用する。
（６）入力領域の移動（キーボードとか重ならないように）
GUIライブラリで、実装したキーボードは、
となっている。 qが少し濃くなっているのは、WindowsCEやLinuxのナビゲーションボタンや帰ボードの矢印キーで、キーを移動させる現在選択されてるキーを示している。 また、「文字列を入れる」と表示されている入力領域は、キーボードの表示に伴い移動する。 仮名文字の入力のための「KANA」キー、全角入力のための「WIDE」キー、数値とUTF-16LEを入力する「１２３」キー、記号を入力する「＃＠」キーがある。 こらのキーをタップすることで、キーボードが変換する。 「KANA」キーをタップした時、
上記のようなキーボードになる。 かなを連続タップすることで、「あ」→「い」→「う」→「え」→「お」と入力文字が変わる。 一定時間経過すると連続タップ期間が終了して、文字が固定される。 上記の例では、２文字入力されて、その候補が表示されている。 この候補はGUIライブラリに内臓されている辞書を使っている。
「ローマ字」ボタンをタップすると、
となる。 3文字以上入力されているので、ネットのかな漢字変換のエンジンを利用した結果を表示している。
GUIライブラリは、ネット上にあるGoogleのかな漢字変換を利用している。 このかな漢字変換は、
で、CGIに元の文字列を送って、リスト形式の結果をもらって、それらを表示している。 CGIで「へんかん」という文字列を送信するためには、TCP/IPを使って、http://www.google.comに接続し、
GET /transliterate?langpair=ja-Hira|ja&text==%E3%81%B8%E3%82%93%E3%81%8B%E3%82%93
HTTP/1.1
User-Agent: kanakanji [ja]
の文字列を送信すればよい。 すると、相手からから
HTTP/1.1 200 OK
Date: xx, day month year time GMT
Pragma: no-cache
Expires: xx, day month year time GMT
Cache-Control: no-cache, must-revalidate
Content-Type: text/javascript; charset=UTF-8
X-Content-Type-Options: nosniff
Content-Disposition: attachment; filename="f.txt"
Server: Google Input Server/1.0
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Alternate-Protocol: 80:quic,p=0.Transfer-Encoding: chunkedmak
4d
"へんかん",["変換","返還","偏官","へんかん","ヘンカン"]
0
が送られてくるので、["変換","返還","偏官","へんかん","ヘンカン"]の部分を取り出して、それぞれ”変換","返還","偏官","へんかん","ヘンカン"を表示する。 ただ、文節を移動する機構を作っていないので、連文節かな漢字変換は、厳密にはできない。
英字キーボードの状態で、「WIDE」をタップすると、
となって、全角入力ができる。 キーボードに←と→がついて、全角を表している。 また、日本語入力キーボードやローマ字入力のキーボードの状態で、「１２３」や「＃＠」をタップすると、全角モードの数値や記号の入力になる。 「半角」をタップすると、全角入力が解除される。
全角入力が解除された状態で、「１２３」キーをタップすると、
数値・UTF-16LEキーボード
となって、数値や数値に関係する記号が入力できる。 「TAP HERE」をタップすると、UTF-16LE入力モードになる。
０ー９までの数値と、A-Fまでの記号で、１６進数のUTF-16LEのコードを入力できる。 UTF-16LEのコード入力で、グリフが定義されていない場合、16進表記が入力領域に表示される。
上記の例では、009Eと入力した結果が表示されている。
全角入力が解除された状態で、「＃＠」キーをタップすると、記号入力になり、
となる。 三角をたっぷすると、別の記号が表示される。
なお、KeyHoleTVのダウンロード・プレミアムモジュールキーのご購入は、
まで。 また、GUIライブラリは、無償で提供していますので、メールにてお知らせください。
メールで ZIP か tar.gz でお送りします。
*1:key_val >= AKEYCODE_A && key_val <= AKEYCODE_Z
KeyHoleTV開発秘話（その５）
Windows版KeyHoleTVの開発
前回(KeyHoleTV開発秘話（その4） - KeyHoleTV開発者のブログ)で、Windows版KeyHoleVideoの開発について、述べました。 最初は、.Net Framework を利用してましたが、それをあきらめ、全てをWin32 を用いてC,C++で開発を行いました。 KeyHoleVideoは、発信も受信もできるシステムですが、機能が多すぎるため、受信専用のアプリケーションが必要となります。 これがKeyHoleTVです。
KeyHoleTVは、KeyHoleVideoの開発で失敗した .Net Framework を利用しないで、Win32APIだけを使って開発することをめざしました。 しかし、ビデオの表示には、DirectXを利用する形式をとっていました。
計算機の種類によるDirectXの動作のばらつき
KeyHoleVideoやKeyHoleTVで利用していたDirectXは、Direct2Dと呼ばれるもので、平面画像を扱うAPIです。 ビデオの表示には、別に３Dのレンダリングは必要ありません。 KeyHoleTVのアプリケーションの開発を進めて、利用者にリリースした時、 特定の計算機でビデオの表示をしない不具合の報告を受けました。 利用者が近所の住まわれていたので、 動かないKeyHoleTVを見せてもらいました。 すると、確かに動画が表示されません。
DirectXには、診断用のプログラム dxdiag があります。 これは、計算機が持っているビデオカードの性能を調べるもので、 どのようになっているか分かるプログラムです。 計算機は、SONY製の日本仕様で、DirectX９を完全サポートと謳われているPCでした。
で、dxdiag で調べてみると、Direct2DのハードウェアアクセレレターがONになっていました。 他の機器では、ハードウェアアクセレレターがONになっていても、特に問題なく表示します。 しかし、SONY製のPCでは、表示されません。 試しにハードウェアアクセレレターをOFFにすると、KeyHoleTVの動画が正しく表示されました。
このようなPCの不具合は、日本製のPCでまれに起こる現象のようです。 著者は、SONY製のPCで一度、 東芝製のAndroidタブレットで表示の不具合を体験しました。 これは、想像ですが、DirectXは、MicroSoftが提供するAPIでそのAPIの性能を引き出すようなビデオカードの設計が行われます。 APIの性能を引き出すための設計は、 APIの仕様が変わった場合、十分に対応できません。 おそくらSONY製のPCは、DirectX9の仕様が完全に固まる前のAPIを利用したビデオカードの設計をおこなった結果だと思っています。 新商品には、仕様の優位性が販売の実績となることが多いため、 このような結果になったと思っています。
東芝のタブレットもOpenGL2.0 の規格では、 任意の大きさの表示領域に対して、テキスチャの貼り付けができるとなっていますが、 東芝製は、横幅が４のべき乗になっていないと、テキスチャの貼り付けができません。 これも、ソフトの仕様が完全に決まる前に仕様の優位性を全面に押し出した結果だと思います。 ひょっとすると、SONY製のPCでも表示領域が前画面の場合などでは、うまく表示できた可能性があります。
SONY製の問題で、DirectXを利用する場合、アプリの挙動が保証できない場合あることが分かりました。 ハードウェアの問題なので、PCのメーカが対応できるデバイスドライバを出したりする可能性が低いことも想定できます。 そこで、KeyHoleTVとKeyHoleVideoは、DirectXを利用しないで、GDIだけで動画を表示するようにしました。
ボタンなどの殆どの部品は、KeyHoleVideoで作ったプログラムを流用しています。 部品は、CやC++で記述されているので、単にテキストをコピー・ペーストすれば、そのまま利用できます。 また、開発には、VisualC++ 8を利用しました。 このGUIは、.Net Frameworkで構築したKeyHoleVideoのボタンやタブをWin32で実装しただけです。 文字列の表示は、GDI Plusを利用して、 その他はGDIを使っています。 GDIを使って表示しているので、音の大きさを表示する斜め線がギザギザになっています。
現在のWindows版KeyHoleTVは、ボタンをすべてアイコンにしています。それが、
上記の画像になります。 KeyHoleTVがオンラインかどうかは、左上の緑の丸で表現しています。 オフラインになると赤い丸になります。 また、KeyHoleTVのウィンドウが何時も一番上で表示を行う Top Most は、ウィンドウの絵のアイコンになっており、クリックすると、KeyHoleTVが他のウィンドウより下に表示されるアイコンになっています。 これらのアイコンは、透明色があるイメージです。 GUI Plusは、イメージ中の透明色を扱うことができます。 スライダーは、デフォルトの表示を使わず、KeyholeTVで表示していて、つまみをドラッグすると、音の大きさが変わります。 スライダーの動きに合わせて右側の音の大きさを表示するアイコンが変化します。 また、音の大きさを表示するアイコンをクリックすると、MUTE（消音）になります。
全ての部品は、C・C++のソースコードで記述されています。 部品一つ一つは、すべてWin32のCreateWindowで構築されたWindowで、Window自身を表示する処理を記述してあります。 表示する処理は、以前、背景の描画と文字列の描画を行っていましたが、現在は、イメージの表示にしています。 また、Windowの表示位置の変更を行っています。
また、KeyHoleVideoもKeyHoleTVの部品を使って、ボタンをできるだけ、アイコンにしました。
その変更を加えたKeyHoleVideoは、
上記の画像になります。 オンライン、オフラインを示すアイコン、TOP MOSTを示すアイコン、音の調整を行うスライダーなど、KeyHoleTVと共通しています。 これも、ボタン等の部品をC・C++のソースコードで記述しているのと、部品化する時、他のソフトでも利用可能なコードにしているため、簡単に移植可能になっています。
WindowsCEへの移植
VisualC++ 8は、作ったアプリケーションをWIndowsCEに移植できる仕組みがあります。WindowsCEは、GDI Plusの利用はできませんが、GDIを使うことができます。 また、GDI PlusからGDIへの変更は、 文字列の表示だけなので、比較的容易に変更可能です。 そこで、WindowsCE用のKeyHoleTVを作ってみました。
ボタンはタッチペンで押すインタフェースです。 WindowsCEには、画面をタップして操作できるタイプのデバイスには、タッチペンが付属していて、Windowsの基本操作もタッチペンで行います。 また、ナビゲーションボタンでも操作可能になっています。 表示しているGUIは、日本語のフォントがないため、日本語の表示ができていません。
Windows XP以降、フォントは、国際化対応されていますので、どこの国で販売されているPCでも日本語の表示が可能です。 しかし、WindowsCEは、販売している国に特化しているようで、国際化のフォントがインストールされていません。 また開発環境でも、VisualC++に付属しているWindowsCEのエミュレータにもフォントが搭載されていませんでした。 当時エミュレータは、MicroSoftからフォントのダウンロードができて、日本語表示ができたようでしたが、エミュレータ用のフォントを実機にインストール出来なかったという記憶があります。 また、入力でも日本語など入力は、日本で販売されているWidnowsCEでしか動作しません。 ですから、たとえ日本語のフォントがインストールされていて表示可能でも、日本語の入力（かな漢字変換）は、欧米で販売されているWindowsCEでは、できなかったと思います。
WindowsCE用のKeyHoleTVのボタン等をアイコン化は、通常のWindowsより困難になります。 一番の問題は、GUI Plusが利用できないことです。 このため、透明色をもったイメージの描画が通常のWindowsより難しくなります。 更に、日本の入力がWindowsCEが販売されている地域によってはできないため、通常のWindowを使ったプログラムでは、KeyHoleTVの実現が困難になります。
WindowsCE版KeyHoleTVのボタンのアイコン化は、アンドロイド用KeyHoleTVの開発を終了してから行いました。 通常アンドロイド用のアプリケーションは、JAVAを使って構築されています。 アンドロイドは、汎用OSで、CPUの種類を選ばないため、どの端末でもアプリが動作するための取り組みです。 しかし、JAVAを使うと、動画のデコーダの処理が重くなり、更に音のデコーダの処理が重くなってしまいます。
利用者からアンドロイド用のKeyHoleTV開発の要請があったのですが、NDK(Android NDK)だけでアプリが作れるまで、開発を中断していました。 NDKだけのアプリで、画面表示を行う場合、OpenGL ESを利用する必要があります。 アンドロイド用に提供されている表示の部品は、NDKだけのアプリでは利用できません。 そこで、OpenGL ESを使った２Dのライブラリを作りました。 このライブラリには、ボタン、スライダー、スライドするページなどの表示用の部品があります。 また、かな漢字変換（３文字以上は、Googleに通信して漢字変換を行います。Google 日本語入力 - CGI API デベロッパーガイド）用の辞書やインターフェースも用意して、日本語入力が出きるようにしました。 PNGのイメージを表示する機能やFreeType のベクターフォントを利用して、日本語の表示も行えるようにしました。 このライブラリを WindowsCEに移植しました。 この結果、アンドロイド用KeyHoleTVのソースコードがそのまま利用できて、アンドロイドと同等な操作ができるようにしました。 これは、
に記載しています。
フレームバッファを利用して表示しているので、全画面表示になっており、Windowのタイトルバーや終了ボタンもありません。 また、ボタンやスライダーは、指でも操作できるようなっています。 自前でフォントやかな漢字変換を用意したので、販売している国に関係なく、日本語の表示や日本語入力も可能です。 操作感覚は、iPhoneやアンドロイドと同様で、ナビゲーションボタンも利用可能です。
KeyHoleTVのダウンロードやプレミアムモジュールキーのご購入は、
で。
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のダウンロード・プレミアムモジュールキーの購入は、
で。
