KeyHoleTV開発者のブログ

日々の質問や開発の日記

著作権法とKeyHoleTV (その2)他のシステムの場合(SKYLIVE NET TV)

現在、ネット上では日本のテレビ番組を見る、ラジオ番組を聴くために様々なシステムが存在している。 日本国内であれば、著作権法をクリアしているTVerラジコ等があるがこれらのシステムは、残念ながら海外では利用できない。過去にはVPNを利用して視聴が可能な時期もあった。しかし、VPNはアドレスが特定されているので、TVerラジコのシステムが特定のアドレスを排除すれば使えなくなる。 同様にアマゾンプライムビデオNetFlixといった動画サイトでも、VPNからの接続に関して制限を設ければ海外からの利用はできなくなる。そのため、出張や赴任なので、海外にいる日本人は、他のシステムを利用せざる負えない。 

また、ProxyとVPNを組み合わせのサービスがでてきている。これである程度Tverやアマゾンプライム、NetFlixの視聴は可能なる。しかし、Proxyとして番組を他の媒体で記憶させ、他の第三者にそれを渡してよいかという問題があり、ある程度時間が建てば、Tverやアマゾンプライム、NetFlixなどが対策をとる可能性がある。相手のアドレスがわかれば停止されるし、Proxyに蓄えないで利用者単位の個々の通信を行うようならば、大量の通信が特定のアドレスに偏る。そうなれば、対策され停止させられる。更に、Tverは契約がないため問題ががないと思う。しかし、NetFlixやアマゾンプライムビデオでは登録した国でしか基本的に視聴できない契約になっている。これを破って視聴すると、何らかの法的な問題を抱えることになる可能性がある(判って違反しているので、民事訴訟ではなくなる可能性もある。)

全てのVPNシステムに共通する問題として、少数の利用に関しては特に問題は発生しない。しかし、利用者が増加し、その利用者がビデオ受信をするとあっという間、VPNサーバの通信帯域幅を超えてしまう。そうなると、当然視聴はできない。

KeyHoleTVシステムは、著作権法に対して回避できる法的な根拠がある。しかし、他のシステムでは著作権法を回避できる法的な根拠があるのかを調べてみた。

これから示す多くの海外から日本のテレビを視聴を提供するウェブサイトは、残念ながら日本国内からアクセスできない。アクセスすると、

f:id:KeyHoleTV:20210613033556p:plain

日本からアクセス その1

f:id:KeyHoleTV:20210613033648p:plain

日本からのアクセス その2

のようになってしまう。上記の画像は、海外から日本にあるVPNを介してアクセスした結果を表示している。 KeyHoleTVは、海外からも日本からもアクセス可能で、日本のテレビを視聴するアプリケーションは、海外はもとより日本国内でも利用可能だ。

日本からのアクセスできないサイトを検証するためには、海外のVPNサーバまたはブラウザ検証サイトを用いればよい。 ブラウザ検証サイトは、browserlingと呼ばれていてアクセスすると以下のようなページを表示する。

f:id:KeyHoleTV:20210613062826p:plain

ブラウザ検証サイト

アドレスバーにURLを入れると、そのサイトが表示される。 日本からアクセスしても表示されないサイトでもサイトの内容を確認できる。 

 

SKYLIVE NET TV

このサイト(https://skylivetv.net/)にアクセスすると、Chromium ブラウザでは、安全な接続でなないと警告がでる。 また、このサイトは、日本からのアクセスができないので、

上記のbrowserlingを利用してアクセスする必要がある。

f:id:KeyHoleTV:20210613141429p:plain

エラー表示

これを無視して内容を表示させると

f:id:KeyHoleTV:20210613141918p:plain

Sky Live Net TV

となる。内容を見てみると、このサイトにはプライバシポリシーの記載がない。この記載がない場合、このサイトをアクセスしたり、アプリをダウンロードして実行すると、利用者の情報(クレジットカードの番号や住所等)がこのサイトを運営している会社にダダ漏れになる。

利用方法をクリックすると、

f:id:KeyHoleTV:20210614024838p:plain

利用方法

のような表示になる。少なくとも、現在はパスワードを取得しないと内容が確認出来ないようだ。 以前は、利用法を選択すると、

f:id:KeyHoleTV:20210614095257p:plain

アプリケーションの選択

となっていた。Winodwsを選ぶと、SnowPlayerがインストールされる。Macを選ぶと

IPTV1.4 がダウンロードされる。IPTV1.4は、ZIP形式になっているので、展開してアイコンをディスクトップに移動すれば、アプリケーションが利用できる。 iPhoneやiPad

では、EasyAppIconをインストールする。

まず、Windows用のSnowPlayerから見てみよう。SnowPlayerは、インストーラが梱包されたEXE形式で配布される。 安全性が確認できないソフトウェアをインストール出来ないので、同様なアプリケーションがgithubに置いてあるので、それをダウンロードした。するとZIP形式のファイルになっている。 安全性を向上させるために、UbuntuでダウンロードしZIPファイルを展開した。

ZIP形式を展開すると、

f:id:KeyHoleTV:20210614103846p:plain

Windows用SnowPlayer

となっている。これだけ見ると問題がないように見える。 しかし、問題は、plugins フォルダだ。 このフォルダを開くと、

f:id:KeyHoleTV:20210617050446p:plain

pluginsフォルダ

と1つのフォルダと1つのファイルが表示される。 ここで問題なのが、misc_shelldll.dllだ。Googleでこのフィアルを調べると

と出てくる。 その内容は、3072 バイトのファイルで、プロセスを生み出すDLLとなっている。 プロセスの種類によっては、悪意のある場合もあるようだ。 misc_shelldll.dllのファイルの大きさは、3.1 kb となっている。しかし詳細を見てみると、

f:id:KeyHoleTV:20210617065138p:plain

miscshell_dill.dill サイズ

となり、3072 バイトの大きさであることから、上記のDLLと同じものだと想定できる。次にpluginsフォルダにあるbassの中身を見てみよう。

f:id:KeyHoleTV:20210617081954p:plain

bassフォルダ

bassフォルダには、bassに関連したようなdllが入っている。 この中で、ファイルサイズが最も大きいのは、bass_aac.dll で、ファイルの詳細配下のようになっている。

f:id:KeyHoleTV:20210617085351p:plain

bass_aac.dll

また、bass_aac.dll の作成された日付は、

f:id:KeyHoleTV:20210618073431p:plain

bass_aac.dll 作成日時

で、2010年となっていて、結構古いバージョンであると想定できる。 このbass_aac.dll は、複数のサイトで複数のバージョンのDLLをダウンロード可能になっている。 例えば、Bass_aac.dll Download - DLL 4 Freeでは、

f:id:KeyHoleTV:20210617100817p:plain

bass_aac.dll ダウンロード

3つのバージョンのダウンロードが可能になっている。 このサイトで示しているファイルサイズは、146.2 KB, 146.3 KB 147.0 KBとなっており、SnowPlayerで配布されるDLLのファイルサイズ(151.4 KB)とは異なっており、配布されるDLLの方が大きい。バージョンが古い場合があるので、おそらく最新のバージョンを配布しているあろうサイトでは、

f:id:KeyHoleTV:20210618073729p:plain

bass_aac.dll 最新バージョン

となっている。 ファイルサイズが近いので、ダウンロードしてみてファイルの大きさを比べてみた。

f:id:KeyHoleTV:20210618083620p:plain

bass_aac.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 がダウンロードされる。これを解凍すると。

f:id:KeyHoleTV:20210618124151p:plain

IPTV_1.4

IPTVアプリケーションが得られる。 これをダブルクリックするとアプリケーションが起動する。Macの場合Windowsと異なって、アプリケーションだけがインストールされるので、基本的にOSに関連するファイルへの書き込みはない。

実行してみると、無料視聴用のNHK教育放送があったので視聴した。 視聴中どんな通信を行っているかをnetstat で調べてみた。すると

f:id:KeyHoleTV:20210619024623p:plain

IPTVの通信の接続状況

多くの通信が張られている。これらのアドレスを検索すると、通信相手は、中華人民共和国だった。通信の接続が達成(ESTABLISHED)されているので、Macに保存されている個人情報等のファイルが相手に送らられる可能性がある。視聴している間に個人情報が抜かれる金券性が高い。また、どこと通信しているのかをtcpdumpで調べた見た。

f:id:KeyHoleTV:20210619030137p:plain

TCPDUMPの結果

通信相手は、183.61.242.60からで中国の Dongguan市からだった。 テレビ映像の通信は、183.61.242.60で、通信を確立してるのが他のアドレスであるため、映像や音声のデータではなく確実に何らかの情報を送信もしくは受信している。 このため、IPTVを利用するのは、大変危険であると云わざる負えない

 

iPhone, IPad用のアプリを見てみよう。 iPhoneやiPad用のアプリケーションは、EasyAppIconと呼ばれるアプリケーションをiOSデバイスにインストールするようだ。

f:id:KeyHoleTV:20210619072411p:plain

EasyAppIcon

過去EasyAppIconは、AppStoreに掲載されていた。しかし現在はなくなっているようだ。このアプリケーションは、アイコンを作るアプリケーションのはずで、TV番組の視聴を目的としていない。しかし、このアプリケーションは、アイコンの作成(丸に+)ボタンをタップして、アイコン名を入れる際、「tv:www.allipcast.com」と入力してから、Playボタンをタップすると、ログイン名とパスワードを聞いてくる。 正しくログイン名とパスワードを入力すると番組表が表示されるようだ。 AppStoreから締め出されているような偽装アプリを利用する方法は、本システムが著作権法に対して有効な法的な根拠を持っているとは考えづらい。 同様に、SnowPlayerでは、トロイの木馬の可能性のあるアプリを配布、Mac版のIPTVでは、番組とは関係がない複数のサイトと勝手に通信を結ぶ、 これらのことからも著作権法に対して有効な法的な根拠がないものと想定できる。

IPTVの遅延を見てみる。 

番組が表示している時間と時計を見くらべてみると、およそ2分以上の遅延がある。これでは、緊急時の速報として役に立たない。 ”リアルタイム”を謳い文句としているが、2分以上の遅延ではリアルタイムを謳うことはできない。2分遅れの電話の会話は、可能かどうか考えてみてほしい。 このような遅延があるようなシステムでは、

著作権法に対して有効な法的な根拠は存在しない。 これを利用されている利用者にも著作権法が適応される可能性が高い

 

著作権法とKeyHoleTV (その1)

著作権法と放送の現状

著作権法が改正され、2021年1月1日に施行された。

これにより、配信者はもとより視聴者もこの法律に適応される可能性が出てきた。

KeyHoleシステムによる配信は、2008年から行われている。 総務省にも再送信の許可を求めることを行い、在京のテレビ局にも説明をしている。 残念ながら、総務省から返答は未だない。 また、テレビ局や広告代理店も番組やコマーシャルに関する複雑な法的な問題(著作権だけではなく、動画に登場する人物の肖像権や品物の放映権など)により特別な場合を除いて、再配信が許可できないとの回答を得ている。

さて、特別な場合とは何を指すのかという点がある。 地上波がアナログ放送の時、ケーブルテレビは、それほど多くなかった。 更に電波の使用に関して地域性が重視されていた。このため、地域により電波の周波数が異なり電波が届く領域で同一の番組を視聴できるようにしていた。しかし、電波が届く範囲の末端では、複数の局の電波が受信できていた場合も存在した。

有線テレビ放送(ケーブルテレビ、光テレビ、IPTV)

ケーブルテレビは、電波の届く範囲を超えて放送を提供できるため、一部の地域を除いて、ケーブルテレビの認可は、されていなかったと推察できる。 ところが、地上波デジタル放送になってから、ケーブルテレビの認可が増えた。 これは、地上波デジタル放送がアナログ放送自体のVHFより高い周波数を用いたUHFを利用したためと考えられる。 周波数の高い電波は、直進性が増し、情報量が増える。 アナログ放送の場合、情報の損失があっても、受像機は映像や音声を表示や音を出すことができた。しかし、デジタル放送では、情報が欠落しすぎると情報の復元ができず、全く映らないといった現象が生じる。更にUHFにより直進性が増した電波では、高層建築物等の影響により都内であっても電波が届きにくい地域が生まれた。

これを解消するためにケーブルテレビ(光ファイバを利用したり、IPTVを利用したりする場合もある)が認可が増えたと考えられる。同時に東京スカイツリーが生まれた原因の一つには、高い塔から発信する電波は、高層建築物の影響を受けにくくするためであるとも推察できる。

情報伝達と放送法

放送業者は、免許制である。だれでも勝手に電波を使って放送することはできない。免許を与える上で、放送法があり、報奨業者はこの法律に適応しなければならない。

ja.wikipedia.org


様々の条文が記載されているが、その中で国民生活に重要な点の一つとして

第百八条 基幹放送事業者は、国内基幹放送等を行うに当たり、暴風、豪雨、洪水、地震、大規模な火事その他による災害が発生し、又は発生するおそれがある場合には、その発生を予防し、又はその被害を軽減するために役立つ放送をするようにしなければならない。

 がある。 この条文では、発生の予防や軽減のための放送を行うとある。このため、「緊急地震速報」はテレビ番組やコーマシャルの放送中でも視聴者に届けるようになっている。また、災害地域での情報をいち早く伝えている。

KeyHoleTVと地デジの配信速度

KeyHoleTVは、地上波デジタル放送を再送しているが、ワンセグに関しては、ワンセグ受信機より早く情報を伝達できる。

youtu.be

上記の動画は、ワンセグ端末とKeyHoleTVの受信時間の比較である。KeyHoleTVの方が早く受信できている。

東京の番組を地方で地デジで受信する場合、東京で地デジを受信し配信してもKeyHoleTVの方が早い場合がある。これは、地デジが地方局に情報を伝える場合、一度デコードして映像や音声情報を取り出し、地方の情報と取り出した映像や音声を再びエンコードするためだと想定する。 このため、東京でエンコードしたKeyHoleTVの方が早く情報の伝達ができる。

youtu.be

上記の動画は、大阪で受信した地デジの映像とKeyHoleTVを比較である。 KeyHoleTVの方が早く映像を受信しているのが分かる。東京から大阪まで、地デジで何回デコード’・エンコードをしているのか詳しくは分からない。しかし、距離が伸びればデコード・エンコードの回数が増えると想定でき、その結果遅延が更に増大すると予想できる。

KeyHoleTVの配信システムは、地上波デジタル放送を受信してから再送信しても、地域によっては基幹放送局で地上波を受信するより早い場合がある。このことから、仮に地上波にエンコードする前に基幹放送局がKeyHoleシステムを使って配信すれば、より早く情報の伝達が可能になる。また、インターネットを利用した地上波の受信の多くは、海外で利用可能で日本国内では利用できない。しかし、KeyHoleTVは、海外はもとより日本国内でも利用可能になっている。 日本国内で利用できないようなインターネットを利用した地上波の再配信は、自分たちが著作権法に何らかのかたちで抵触している可能性を考えていると想定する。 しかし、KeyHoleTVでは配信速度が地上波より早く送信できるため、「緊急避難」という法律が適応されると考えている。 この点は、法的な根拠があり、司法関係者からも同意を得ている。

KeyHoleVideoによる配信で情報共有の高速化

KeyHoleVideoによる配信は、「緊急避難」という法律の適応が可能なため、改正された著作権法でも配信の停止を著作権者が訴えることができない。また、改正された著作権法では、視聴者にも適応される可能性があるが、KeyHoleTvの視聴に限ってはKeyHoleVideoの配信と同様に「緊急避難」が適応されるため問題が発生しない。ただ、ここで、注意しなければならない点として、KeyHoleVideoを用いて、衛星放送の配信やケーブルTV等の有料放送の再配信だ。 これらの放送は緊急用の放送としては、受信するまでの遅延が大きいため役に立たない。 このため、KeyHoleVideo再配信を行うと、上記の「緊急避難」が適応されないので注意が必要だ。

KeyHoleVideoによる再配信は、無料のプレミアムモジュールキーを取得できるため、自分で配信した番組や他の番組を、自分の端末でどこでも視聴ができる。放送局がある地方がKeyHoleVideoで再配信を行えば、配信している地方はもとより他の地方では、地上波デジタル放送より早い情報が獲得できる。 KeyHoleVideoでプレミアムモジュールキーが無料で取得できるシステもを構築したのは、日本全国のテレビ番組やラジオ番組を再送信して、地域を超えた情報の共有を願っている結果に過ぎない。

 

意外と知られていない家庭内のパケット落ち

ルータやルータ機能付きモデム

KeyHoleTVを利用している利用者から、動画が止まったり、音が停止する現象があると、度々報告された。例えば、昨日まで問題なく利用できたのに、今日はダメといった具合だ。 この問題に対して、こちらの環境では、問題が発生していないため、利用者の環境を詳しく聞いた。

この結果、分かったことは、

(1)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も無事視聴することができた。

 

(2)ルータ内部で、パケットを捨てている。

ルータは、接続している機器のアドレスと対象機器で動作しているアプリケーションが利用するポート番号を管理して、インターネット側から送られてくるパケットを対象機器に送信する。 ルータやモデムの機種によっては、管理しているテーブルに送受信したパケットの数を管理しているのではないかと想定する。(これは、内部仕様がないため、確証が得られないので、確かめられない。)

自宅で利用している光ファイバ用のルータ機能付きモデムでは、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の場合、ある程度パケットが損失しても、問題が無いように設計している。当然パケットが届かないので、動画乱れたり、音が飛んだりする場合もある。しかし、何日も利用していると、音が止まったり、動画が完全に停止してしまう。これを解決するためには、自分のアドレスを変える以外方法がない。プロバイダが意図的にパケットを欠落させているので、アドレスを変えて、一定以上のパケットが到着しないようにするしか方法がない。

アドレスを変える方法は、モデムの電源を切って、再び入れる。 携帯電話の場合も電源を切って再び入れる。 これで、プロバイダにより割り振られるアドレスが変わる。 残念なことに、集合住宅では、通用しない場合が多い。 これは、集合住宅にメインのモデムがあり、それがプロバイダよりアドレスが割り振られ、個々の居室にあるモデムは、独自のアドレスになっているためで、居室にあるモデムの電源を切って、再び入れても、内部のアドレレスが変わるだけで、メインのアドレスが変わらない。このような場合、携帯電話のデザリングを利用して3G/4Gを経由携帯電話をルータとしてPCを利用するしか方法がない。

KeyHoleTVは、他の動画システムに比べて圧倒的に通信量が少ない。 また、ほとんどの動画サイトでは、最初に大量にダウンロードするため、途中で動画を停止しても、すでにダウンロード済みとなってしまう。 このため、動画サイトの動画をザッピングすると、あっという間に制限容量を超えてしまう。 一方、KeyHoleTVは使った時間しか通信を行わない。このため、使用量が利用者にとってわかりやすい。

 

ポケットWiFiのパケット落ち

日本は、住民登録を証明する書類などがないと、携帯電話を所有することは基本的にできない。海外からの旅行者などは、空港などで、貸出携帯などを利用する。また、インターネットを利用するためには、ポケットWiFiまたはWiMAXと呼ばれる3G/4G回線などを利用した小型のWiFiルータをレンタルする。

www.kashi-mo.com

ポケットWiFiは、様々な契約プランが用意されている。 この契約プランのなかで、定額サービスの場合が曲者だ。定額サービスでは、一定以上の通信を行うと、通信速度が低下する。 著者が調べた結果、サーバ側で、およそ128Kbps以下の通信を行う仕組みを提供しても、決して128Kbps の通信をせず、単純にパケットを捨てている点が曲者である所以だ

例えば、KeyHoleTVは、音だけの番組では、通信速度は128Kbps 以下になる。これは、著者がT-Mobile(当時の通信速度は、64kpbs)の端末で音だけの番組を視聴した結果、長時間利用可能であったことによる。当時のT-Mobile の端末は、Windows Moble の端末でKeyHoleTVでは、古いWindows Mobile でも動作させていた。KeyHoleTV開発秘話(その5) - KeyHoleTV開発者のブログ

 しかし、ポケットWiFiの通信制限を超えた場合で、KeyHoleTVを利用すると、音が飛び飛びになることで、パケットを意図的に捨てていることが明らかになった。

 

オーストラリアでのパケット落ち

オーストラリアでは、インターネットの利用は基本的に従量制である。これは、ポケットWiFiの利用と似ている。 また、プロバイダによっては、定額料金で一定以上の通信を行うと、通信速度が低下する契約も存在する。 ここでも、通信速度の低下が問題になる。通信速度の低下は、単純にパケットを捨てているので、サーバ側がいくら通信速度をプログラム的に落としても、決して端末にパケットが届かない

オーストラリアでは、従量制のインターネットを利用するほうが、KeyHoleTVを利用する上では、有効であると思う。 この場合、3G/4G 回線を利用したKeyHoleTVの利用が有効だ。 KeyHoleTVの場合、通信速度は、動画でも350 Kbps以下で必ず抑えている。

日本のテレビを見ることができるKeYHoleTVとOISEYER Inc.で、示したように、KeyHoleTVの通信量は、他のシステムよりはるかに少なくて住む。このため通信容量に制限があっても、一月で超えることは少ない。 また、他の動画システムの場合、開始直後にダウンロードする量が比較的多いため、単純にザッピングを行うと、視聴した動画のデータ容量に比べて、ダウンロードする量が多い。 このため、少ししか観ていないのにも拘わらず、通信量が増える結果になってしまう。一方、KeyHoleTVは、視聴した時間だけの通信を行うので、視聴時間で通信量が分かる。

 

KeyHoleTVのダウンロード・プレミアムモジュールキーの購入は、 

 

oiseyer.com

 

Android Native Activityによるキーボード処理 (その1)

Native Activityでのソフトウェアキーボードの利用の困難さ

Native Activity のOpenGL ESを使ったアプリケーションは、Androidが提供する様々な機能が利用できない。最も大きいのは、ソフトウェアキーボードだろう。 Androidアプリケーションで、名前の入力やURLの入力には、ソフトウェアキーボードが表示され、そこで、入力した文字や記号が入力領域(EditText)に反映される。 日本語対応のソフトウェアキーボードでは、連文節かな漢字変換をおこなったり、予測変換の文字列が表示されたりする。 候補をタップすることで、候補の文字列が入力領域にはいる。

ソフトウェアキーボードをNative Activity のOpenGL ES環境下で、表示するには、

groups.google.com

に示されているが、NDKでイベントを扱うには、結局

codeday.me

の回答にあるように、

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); で、全てのコードが取得できればよいが、取得できるコードは、

developer.android.com

で定義されているコードだけになるようだ。 例えば、!マークや%記号のコードは、定義されていない。これらの記号は、お使いのキーボードをご覧になれば、一目瞭然で、シフトキーを押したときのコードになる。 更に、かなや漢字などの文字列が、上記の入力処理のeventに送られてくるはずがない。

AndroidのJAVAの入力領域(EditText)とキーボードは、別のアプリケーションになっている。 しかし、その間を取り持つインターフェースは、inputconnection となっていて、両者が密接に関係している。 下記のサイトは、独自のキーボードの実装をコードベースで説明している。

qiita.com

上記のNewKeyboard.java中の、commitText("1", 1); で、文字列を入力領域に送っている。 この入力をNative Activity のOpenGL・ESのアプリで取得するためには、JNIを使って取得する必要がありそうだ。さて、JAVAのアプリでは,どのような記述でキーボードを表示しているか見てみる。

akira-watson.com

上記のサイトによると、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開発者のブログ)の表示機能を使ったキーボードを実装した。 実装にあたり、次の要件を満たすようにした。

(1)英字キーボードの配列は、101と同じにする。

(2)記号と数値は、Shitを押して操作するのではなく、記号や数値ボタンをタップして、記号キーボードや数値キーボードを表示する。

(3)UTF-16LEの入力機構をもち、コードで文字の入力を可能にする。

(4)ひらがな2文字までの漢字辞書を持ち、候補を表示する。

(5)ひらがな3文字以上は、連文節かな漢字変換を用いる。 連文節かな漢字変換は、ネットワークを利用したエンジンを利用する。

(6)入力領域の移動(キーボードとか重ならないように)

 GUIライブラリで、実装したキーボードは、

f:id:KeyHoleTV:20190819142204j:plain

GUIライブラリのキーボード

となっている。 qが少し濃くなっているのは、WindowsCEやLinuxのナビゲーションボタンや帰ボードの矢印キーで、キーを移動させる現在選択されてるキーを示している。 また、「文字列を入れる」と表示されている入力領域は、キーボードの表示に伴い移動する。 仮名文字の入力のための「KANA」キー、全角入力のための「WIDE」キー、数値とUTF-16LEを入力する「123」キー、記号を入力する「#@」キーがある。 こらのキーをタップすることで、キーボードが変換する。 「KANA」キーをタップした時、

f:id:KeyHoleTV:20190819143454j:plain

日本語キーボード

上記のようなキーボードになる。 かなを連続タップすることで、「あ」→「い」→「う」→「え」→「お」と入力文字が変わる。 一定時間経過すると連続タップ期間が終了して、文字が固定される。 上記の例では、2文字入力されて、その候補が表示されている。 この候補はGUIライブラリに内臓されている辞書を使っている。

「ローマ字」ボタンをタップすると、

f:id:KeyHoleTV:20190820043208j:plain

ローマ字キーボード

となる。 3文字以上入力されているので、ネットのかな漢字変換のエンジンを利用した結果を表示している。

GUIライブラリは、ネット上にあるGoogleのかな漢字変換を利用している。 このかな漢字変換は、

www.google.co.jp


で、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」をタップすると、

f:id:KeyHoleTV:20190820101129j:plain

全角キーボード

となって、全角入力ができる。 キーボードに←と→がついて、全角を表している。 また、日本語入力キーボードやローマ字入力のキーボードの状態で、「123」や「#@」をタップすると、全角モードの数値や記号の入力になる。 「半角」をタップすると、全角入力が解除される。 

全角入力が解除された状態で、「123」キーをタップすると、

f:id:KeyHoleTV:20190822094247j:plain

             数値・UTF-16LEキーボード

となって、数値や数値に関係する記号が入力できる。 「TAP HERE」をタップすると、UTF-16LE入力モードになる。

f:id:KeyHoleTV:20190823055504p:plain

UTF-16LF キーボード

0ー9までの数値と、A-Fまでの記号で、16進数のUTF-16LEのコードを入力できる。 UTF-16LEのコード入力で、グリフが定義されていない場合、16進表記が入力領域に表示される。

f:id:KeyHoleTV:20181209010504p:plain

上記の例では、009Eと入力した結果が表示されている。

全角入力が解除された状態で、「#@」キーをタップすると、記号入力になり、

f:id:KeyHoleTV:20190825124846p:plain

記号のキーボード

となる。 三角をたっぷすると、別の記号が表示される。 

 

なお、KeyHoleTVのダウンロード・プレミアムモジュールキーのご購入は、

www.oiseyer.com

 まで。 また、GUIライブラリは、無償で提供していますので、メールにてお知らせください。

メールで ZIP か tar.gz でお送りします。

 

*1:key_val >= AKEYCODE_A && key_val <= AKEYCODE_Z

KeyHoleTV開発秘話(その5)

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です。 ビデオの表示には、別に3Dのレンダリングは必要ありません。 KeyHoleTVのアプリケーションの開発を進めて、利用者にリリースした時、 特定の計算機でビデオの表示をしない不具合の報告を受けました。 利用者が近所の住まわれていたので、 動かないKeyHoleTVを見せてもらいました。 すると、確かに動画が表示されません。 

DirectXには、診断用のプログラム dxdiag があります。 これは、計算機が持っているビデオカードの性能を調べるもので、 どのようになっているか分かるプログラムです。 計算機は、SONY製の日本仕様で、DirectX9を完全サポートと謳われている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 の規格では、 任意の大きさの表示領域に対して、テキスチャの貼り付けができるとなっていますが、 東芝製は、横幅が4のべき乗になっていないと、テキスチャの貼り付けができません。 これも、ソフトの仕様が完全に決まる前に仕様の優位性を全面に押し出した結果だと思います。 ひょっとすると、SONY製のPCでも表示領域が前画面の場合などでは、うまく表示できた可能性があります。

SONY製の問題で、DirectXを利用する場合、アプリの挙動が保証できない場合あることが分かりました。 ハードウェアの問題なので、PCのメーカが対応できるデバイスドライバを出したりする可能性が低いことも想定できます。 そこで、KeyHoleTVとKeyHoleVideoは、DirectXを利用しないで、GDIだけで動画を表示するようにしました。

f:id:KeyHoleTV:20190713082347p:plain

DirectXを利用しないKeyHoleTV

ボタンなどの殆どの部品は、KeyHoleVideoで作ったプログラムを流用しています。 部品は、CやC++で記述されているので、単にテキストをコピー・ペーストすれば、そのまま利用できます。 また、開発には、VisualC++ 8を利用しました。 このGUIは、.Net Frameworkで構築したKeyHoleVideoのボタンやタブをWin32で実装しただけです。 文字列の表示は、GDI Plusを利用して、 その他はGDIを使っています。 GDIを使って表示しているので、音の大きさを表示する斜め線がギザギザになっています。 

現在のWindows版KeyHoleTVは、ボタンをすべてアイコンにしています。それが、

f:id:KeyHoleTV:20190717042851j:plain

ボタンをアイコン化したKeyHoleTV

上記の画像になります。 KeyHoleTVがオンラインかどうかは、左上の緑の丸で表現しています。 オフラインになると赤い丸になります。 また、KeyHoleTVのウィンドウが何時も一番上で表示を行う Top Most は、ウィンドウの絵のアイコンになっており、クリックすると、KeyHoleTVが他のウィンドウより下に表示されるアイコンになっています。 これらのアイコンは、透明色があるイメージです。 GUI Plusは、イメージ中の透明色を扱うことができます。 スライダーは、デフォルトの表示を使わず、KeyholeTVで表示していて、つまみをドラッグすると、音の大きさが変わります。 スライダーの動きに合わせて右側の音の大きさを表示するアイコンが変化します。 また、音の大きさを表示するアイコンをクリックすると、MUTE(消音)になります。

全ての部品は、C・C++のソースコードで記述されています。 部品一つ一つは、すべてWin32のCreateWindowで構築されたWindowで、Window自身を表示する処理を記述してあります。 表示する処理は、以前、背景の描画と文字列の描画を行っていましたが、現在は、イメージの表示にしています。 また、Windowの表示位置の変更を行っています。

また、KeyHoleVideoもKeyHoleTVの部品を使って、ボタンをできるだけ、アイコンにしました。

その変更を加えたKeyHoleVideoは、

f:id:KeyHoleTV:20190717114307j:plain

ボタンをアイコンにしたKeyHoleVodeo

上記の画像になります。 オンライン、オフラインを示すアイコン、TOP MOSTを示すアイコン、音の調整を行うスライダーなど、KeyHoleTVと共通しています。 これも、ボタン等の部品をC・C++のソースコードで記述しているのと、部品化する時、他のソフトでも利用可能なコードにしているため、簡単に移植可能になっています。

WindowsCEへの移植

VisualC++ 8は、作ったアプリケーションをWIndowsCEに移植できる仕組みがあります。WindowsCEは、GDI Plusの利用はできませんが、GDIを使うことができます。 また、GDI PlusからGDIへの変更は、 文字列の表示だけなので、比較的容易に変更可能です。 そこで、WindowsCE用のKeyHoleTVを作ってみました。

f:id:KeyHoleTV:20190713083529j:plain

古いWindows CE用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を使った2Dのライブラリを作りました。 このライブラリには、ボタン、スライダー、スライドするページなどの表示用の部品があります。 また、かな漢字変換(3文字以上は、Googleに通信して漢字変換を行います。Google 日本語入力 - CGI API デベロッパーガイド)用の辞書やインターフェースも用意して、日本語入力が出きるようにしました。 PNGのイメージを表示する機能やFreeType のベクターフォントを利用して、日本語の表示も行えるようにしました。 このライブラリを WindowsCEに移植しました。 この結果、アンドロイド用KeyHoleTVのソースコードがそのまま利用できて、アンドロイドと同等な操作ができるようにしました。 これは、

keyholetv.hatenablog.com

に記載しています。

f:id:KeyHoleTV:20190717135226j:plain

現在のWindowsCE用KeyHoleTV

 

フレームバッファを利用して表示しているので、全画面表示になっており、Windowのタイトルバーや終了ボタンもありません。 また、ボタンやスライダーは、指でも操作できるようなっています。 自前でフォントやかな漢字変換を用意したので、販売している国に関係なく、日本語の表示や日本語入力も可能です。  操作感覚は、iPhoneやアンドロイドと同様で、ナビゲーションボタンも利用可能です。

 

KeyHoleTVのダウンロードやプレミアムモジュールキーのご購入は、

www.oiseyer.com

で。

KeyHoleTV開発秘話(その4)

Windows版KeyHoleVideoの開発

前回(KeyHoleTV開発秘話(その3) - KeyHoleTV開発者のブログ)で、インターネット上で高速に送信できるUDP/IPを使い、フレームを貯めることなしに動画の圧縮とエンコードを行うKeyHoleシステムの基本的な仕組みについて、説明をしました。 この仕組みは、GUIがないテストアプリケーションで検証を行ないました。 動画や音声に関しては、SDL

www.libsdl.org

を用いて、Linuxでテストしていました。 また、WindowsにもMinGW 

www.mingw.org

を利用していました。 また、この時、MinGWでは、Video For WindowsのライブラリがMinGWで利用できたので、ウェブカメラのキャプチャが可能でした。 この時、実験用のアプリは、gcc でコンパイルし、 Video For Windowsのライブラリがgcc で利用可能でした。 これは、 MinGWの開発用ライブラリに video for windows のライブラリが入っていたので、それを利用できました。

gcc.gnu.org

当時は、Windows用のビデオキャプチャは、DirectShow がありましたが、 これは、MicroSoftのVisual C++ の開発環境でしか、利用できませんでした。

docs.microsoft.com

.Net FrameWork の悲劇

実験用では、MinGWで十分なのですが、これでは、アプリのリリースをするとき、MinGWやGCCのDLL(ダイナミックリンクライブラリ)が必要になります。 また、GUIを構築する場合、文字列の表示が不可欠になりますが、当時のMinGWでは、Windows用のTrueTypeの利用が利用しずらい状況でした。 

Windowsには、文字列を表示するのに、2つの方法があります。 一つは、Windows GDIと呼ばれる方法で、Windows GDIは、モニタのみならずプリンターにも対応できる仮想の出力ライブラリです。 MinGWは、Windows GDIのライブラリが用意されていたので、アプリケーションからの利用が可能でした。 しかし、当時のWindows GDI は、ビットマップフォントしか用意されていなかったため、小さい文字の表示(特に漢字など)が見づらい状況になっていました。 これを解決する方法は、 GDI Plus というライブラリで、Windows XPが登場してからWindowsの表示で殆ど利用されています。 Windows XPが登場したとき、 インターネットエクスプローラの表示で文字列が綺麗に表示されていたので、記憶にある方も多いと思います。 しかし、このライブラリもMinGWから利用できない状況でした。 (正確には、 MinGWでもCreateFont 関数を利用すれば可能で、GDI32ライブラリをリンクする必要があります。 しかし、 Video For Windowsは、別のライブラリが必要で、このライブラリとGDI32が競合したため、結局は利用できませんでした。)

 

ja.wikipedia.org

当時は、あまり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を使っています。

f:id:KeyHoleTV:20190713062828j:plain

Win32だけで作ったKeyHoleVideo


添付した図がWin32APIとDirectShow, DirectXで作ったKeyHoleVideoです。 全てのボタンは、Win32APIのWindowです。 それに、GDI Plusを用いて文字列を張り付けています。 また、表示している文字列も、GDI Plusで表示されています。

 

KeyHoleTVのダウンロード・プレミアムモジュールキーの購入は、 

www.oiseyer.com

で。 

 

 

KeyHoleTV開発秘話(その3)

KeyHoleTVがなぜ地デジより早く情報を伝えられるのか(その2)

 前回(KeyHoleTV開発秘話(その2) - KeyHoleTV開発者のブログ)で、TCP/IPはデータが到着するまでに、時間がかかり、MPEG-XやH26Xの方法では、GOPでフレームをまとめてエンコードしているので、エンコードが完了して、送信する時点で、すでに遅れが生じていることを述べました。 この遅れが更にインターネットの送信時間やTCP/IPによる送信の遅れが追加されることになります。 この結果、MPEG-XやH26Xでエンコードした情報をTCP/IPで送信すれば、地上波デジタル放送より確実に遅れて受信者に届く結果になります。

確実に遅れる情報の伝達は、特定の環境下では、十分役に立ちます。 例えば、近年テレビドラマなどが、インターネットで配信されていますし、HuluやNetFlexといった動画配信サービスでも利用されています。 しかし、この技術で、テレビ放送の再配信をおこなった場合、確実に法律に触れる結果になります。 放送には、災害等の情報をいち早く視聴者に伝える義務があります。 これが守れていないと、再配信の許可が下りません。 KeyHoleTVは、この点を厳守していますので、 再配信の許可の申請を行っています。

UDP/IPによる通信

著者は、インターネットによる遅延(特にTCP/IPによる遅延)のことは、以前ネットワークゲームを開発した時に知っていましたので、 TCP/IPを使わずUDP/IPで通信する仕組みを考えていました。 動画や音声を送信可能にするUDP/IPのサーバの開発を行っており、これがKeyHoleTVのシステムの前身になります。 

UDP/IPにしたことで、情報の到着時間は、短縮できました。 しかし、MPEG-XやH26Xのデータをそのまま送信すると、LAN環境では問題なく利用できましたが、インターネットを使ったWAN環境では、 パケットの欠落が起きて、動画が停止したり、デコード出来ずにアプリケーションが異常終了したりする結果になりました。 

ja.wikipedia.org

これを解決すべく、 UDP/IPに到着保証を儲けたRUDPで情報の送信を行いました。 RUDPは、サーバで送信量や送信タイミングを操作できるようになりましたが、結果TCP/IPを使った場合と比べて、多少は早くなったものの、十分な速度が出ません。 また、受信側である程度のバッファリングを行わないと、動画途中で停止する場合が生じました。

現在でも、殆どの動画配信サービスを利用する場合、受信者側でバッファリングを行っていますし、 視聴した動画の時間以上のデータを受信しています。 

ここで、少し余談ですが、このバッファリングは、多くの場合、ファイルを利用しています。 機械式のハードディスクを利用されている場合、バッファリングためのファイルは、消去することができます。 しかし、シリコンディスクやスマートフォーン、タブレットの場合、揮発性のメモリをバッファリングで利用しているアプリ以外、ファイルを利用します。 シリコンディスクやスマートフォーン、タブレットは、データをファイルに書き込むと、そのデータは実質消えません。 消えたというフラグが立っているだけで、データ自体は、シリコンディスク、スマートフォーンやタブレットに残っています。 このため、頻繁に動画や音楽をストリーミングで楽しんでいる方で、記憶容量が小さいスマートフォーンやタブレットをお持ちの場合、ファイルの書き込みが出来なくなる時期が早まる可能性があります。 シリコンディスクの基本設計では、一日に最大40Gバイトのデータを書き込むことを想定していますので、それを越えるような使い方をする場合注意が必要です。 動画の種類によっては、5分で、1Gバイトを越える場合もありますし、一般のストリーミングの場合、データをとにかく送信してしまう方式がとられているので、視聴時間に関係なくバッファリングしていきます。

navi.dropbox.jp

ストリーミングファイルの書き込みが出来なくなると、タブレットやスマートフォーンは、実質利用出来なくなります。 iPhoneの発売当初、YouTUBEの動画を見るためにアプリが存在しました。 ブラウザで視聴しないで、アプリとしたのは、公式には、FlushがiPhone上で、動作するの防ぐためと言われていますが、バッファリングが一つの問題であると著者は思っています。

news.mynavi.jp

KeyHoleTVは、ファイルを使ったバッファリングを一切行っていませんので、一日に何時間視聴しても、問題は起こりません。 著者の家庭では、KeyHoleTVを用いて、スマートフォーンで一日に少なくとも5時間程度視聴してます。

動画の圧縮技術の開発

MPEG-XやH26Xの方法で動画をエンコードする方法は、いくつかのフレームを貯めてからエンコードするため、エンコードした時点で、実際の映像とは、遅れています。 また、送信するデータの中には、まとまったフレームのデータがあり、まとまったフレーム間で総合参照するために、データの欠落は、許せません。 更に、インターネットでデータを送信する場合、パケット単位にしかデータを送信できないので、まとまったフレームのデータをエンコードした結果、複数のパケットに分割される可能性が高くなります。 このため、UDP/IPだけで、データを送信すると、パケットの欠落が起こった場合、対処出来にくくなります。 RUDPを利用しても、送信速度は、多少向上しますが、UDP/IPだけで、送信するより遅くなります。 このため、新しい動画の圧縮方式が必要になります。

通信は、放送と違って、受信者からのフィードバックが得られます。 KeyHoleTVのシステムは、このフィードバックを利用しています。 KeyHoleTVは、他の動画視聴システムとは異なり、動画の途中から再生できたり、映像がでるまで、他のシステムと比べて時間が短いと思います。 これは、番組の視聴に参加したというフィードバックを動画を圧縮してエンコードするKeyHoleVideoというアプリケーションに伝えているからです。 KeyHoleVideoがこの情報が届くと、強制的に他のフレームを参照しないモードで、圧縮をしてエンコードします。

KeyHoleシステムの動画の圧縮とエンコードは、フレームをためず、毎フレーム送信します。 KeyHoleシステムの圧縮とエンコードは、他のフレームを参照しないモードと前のフレームを参照するモードの2種類しかありません。 MPEG-XやH26Xでは、他のフレームを参照しないIフレームと、前のフレームを参照するBフレーム、次のフレームを参照するPフレームの3種類あります。 

また、送信するデータの量によって、KeyHoleVideoで指定するビットレートを越えて送信することはありません。 ビットレートを越えると分かっている場合、そのフレームを送信しません。 これがKeyHoleTVがカクカクする原因です。 多くの場合、パン(カメラを左右に動かす)やズームをする場合に、カクカクします。 

KeyHoleTVシステムの圧縮は、

(1)離散コサイン変換で求まった輝度、色差データの間引きと量子化による値の縮小とビットデータの偏りを利用(小さい数値を少ないビットで表現します。 大きい数値は、多いビットで表現します。)

(2)同じ位置にあるブロックの離散コサイン変換をした結果が前のフレームと同じようなデータである場合、そのブロックのデータを同じとし、これを少ないビットで表現(米国特許取得

(3)隣接もしくは、一つ前のフレームのブロックの比較と差分による値の縮小化とビットデータの偏りを利用

で構成されています。

(2)の特許は、固定したWebカメラやハンディ型のムービーカメラでとった壁の映像を解析しているとき、同じ条件であるにも拘らず、生データの値が変わっていたこと。 フレームを越えて生データの値が元に戻ったりするすること。 これらから、アナログ情報をデジタル変換するときに発生するノイズであろうと判断しました。 また、ビデオカメラ初心者が撮影する映像は、頻繁にパン(意図しないパン。すなわち手ぶれなど)やズームを行うので、視聴者にとって、あまりよい印象がないと考えました。 更に、テレビ番組の映像にも、それほど頻繁にパンやズームを行うことも少ないことが分かりました(スポーツ中継の場合は、パンやズームが頻繁に行われる場合があります。 残念ながら現状のKeyHoleTVは、あまり得意ではありません。)

また、(2)の特許は、MPEG2やMPEG4に対して、ノイズフィルターとしても有効です。 生画像を(2)の特許を用いたフィルタ処理した後、MPEG2やMPEG4で圧縮をかけると、

f:id:KeyHoleTV:20190710001316j:plain

図に示したような結果になります。 オレンジが元データの大きさで単位はバイトです。 紫は、MS-MPEG4で圧縮した結果。 灰色は、H264(X264)で圧縮した結果、 薄い紫は、ノイズフィルターをかけてからMS-MPEG4で圧縮した結果です。 圧縮率は、最低の設定で圧縮を行いました。 結果が示すように、フィルタを用いてMS-MPEG4で圧縮した結果は、H264よりも圧倒的に圧縮されています。 元データにいかにノイズが多いかを示していると思います。 

このフィルタをかけてH264で圧縮するともっと圧縮ができるのではないかと、予想される方もおられると思います。 残念ながらそうなりません。 MEPGの圧縮は、8x8の領域に対して、輝度、色さで処理を行っています。 一方H264は、4x4の領域に対して行っています。 MPEGの圧縮では、その処理の中に同一場所のフレーム間をまたいだ8x8の画像の比較があって、同じ画像である場合、少ないビットで、エンコードする仕組みが入っています。 この仕組みがフィルタをかけた場合に有効に働いて、圧縮が効いています。 一方H264では、4x4の輝度領域で、画像のパターン化を行います。 このパターン化のため、フレーム間をまたがった画像でも、ある程度ノイズが除去されている結果になります。 しかし、4x4のため、たとえ少ないビットで表現できても、4x4のブロックの数が増えるので、8x8の領域を用いたMPEG4にはかなわない結果になります。

MPEGでは、フレーム間で、同一位置の8x8の領域が同じでない場合、差分をエンコードします。このため、圧縮されたデータ量が増加しますが、フィルタによって、ノイズを除去すると、図に示した結果になります。 

動画フレーム用UDP/IPの改良とデコーダ

 KeyHoleシステムは、動画をエンコードするのに、一フレーム単位に行っています。 エンコードした結果、複数のパケットに分割されれる可能性がありますので、 送信時にできるだけインターネットの途中でパケットが分割されない大きさで送出します。 また、パケットには、エンコードしたフレーム番号、エンコードに必要なパケット数と自分のパケット番号を付加しています。 これで、受信した側は、届いていないパケットが認識できます。 

受信側(KeyHoleTV)は、一つのフレームで、届いていないパケットが判明すると、届いていないと通知します。 パケットの順番が飛ばしたり、次のフレームのパケット届いた時に、通知します。

この通知は、一度限りで、2度通知することはありません。 通知が届いたら、再送します。 

KeyHoleTVは、できるだけ待ってからデコードを試みますが、待てない場合、以前のフレームの絵を表示し、そのフレームのデコードを諦めます。

KeyHoleTVのデコーダは、一つ前のフレームの情報を参照しますが、それが実際に一つ目でなくても、よいように設計されています。 映像自身は、一部壊れますが、そのうち修正されるようになっています。 これは、緊急情報をいち早く伝えるための仕掛けになっています。

まとめ

KeyHoleTVのシステムは、 UDP/IP を利用することで、ほぼインターネットの送信速度と同等な速度でデータを送信可能にしました。 さらに、動画の圧縮とエンコーダを開発して、フレーム単位の圧縮とエンコードと送信、2フレームによる差分の送信、フレーム間にまたがる同じ位置のブロックを同一とする仕組みとそれをエンコードして送信、 前のフレームを参照しないで、画像の圧縮とエンコードを状態によって操作出来る仕組み、パケットが到着されない場合、再送を一度だけ行う仕組みを組み合わせることで、地上波デジタル放送より早く情報の伝達が可能になっています。

KeyHoleTVのシステムは、他の動画配信システムなどとは、根本的に違うシステムです。

 

KeyHoleTVのダウンロード・プレミアムモジュールキーの購入は、

www.oiseyer.com

 で。