KeyHoleTV開発者のブログ

日々の質問や開発の日記

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

 で。

 

KeyHoleTV開発秘話(その2)

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

KeyHoleTV開発秘話(その1) - KeyHoleTV開発者のブログで、KeyHoleTVは、関係省庁に再配信の申請をしたことを記述しました。 KeyHoleTVが地デジよりも早く受信できるので、配信基準を満たしていると考えています。 では、何故、KeyHoleTVは、地デジや他の配信システムと比べて早く受信できるのでしょうか? これを説明するためには、KeyHoleTVの開発初期について、語らなければなりません。

KeyHoleTVの開発はじめ

KeyHoleTVの開発当初は、日本のテレビは、アナログ放送で、近々にデジタル放送が始まるという時でした。 当時から地上波デジタル方法は、遅延が問題視されており、

matome.naver.jp

対策がない状態でした。 現在でもKeyHoleTVがもっとも早く送信できており、地デジでの対策は、未だ存在していません(2019年6月現在)

一般にインターネットを利用した通信は、遅いという認識でした。 しかし、ネットワークゲームに代表されるような通信では、あたかもリアルタイムで情報を共有しているようなシステムが存在していました。  ネットワークゲームのDoomなどが代表例です。 著者もいくつかのネットワークゲームの開発に参加して、リリースもしました。

ja.wikipedia.org

 これらのネットワークゲームの多くは、通信にUDP/IPを使っている点です。 RPGなどのゲームでは、TCP/IPを利用した場合もありますが、対戦型のゲームでは,UDP/IPを使うようです。

KeyHoleTVの開発の前身は、独自のサーバで、ネットワークを介して同じ映像や音声を伝搬させる機構を目指していました。 通信は、UDP/IPを使い、動画や音の圧縮は、Mpegに準じた設計をしていました。 端的にいうと、WebサーバのUDP/IP版です。 通常のWebサーバは、TCP/IPの通信を利用してHTMLという言語でWebブラウザと通信を行います。この仕組みは、利用者に情報を提供する仕組みとしては、十分ですが、TCP/IPを利用するため、通信の負荷がかかってしまう、速度が遅いという欠点があります。  では、なぜTCP/IPを利用すると、通信の負荷がかかって、速度が遅くなるのでしょうか? 

TCP/IPを利用したセッション

インターネットは、宛先と自分の住所、それと自分の荷物の大きさがかかれた荷札が付いたデータの送信を行います。 荷札が付いたデータをパケットと呼びます。 さて、パケットは、様々な経路を経由して相手に運ばれますが、それが正しく到着する保証はありません。 これが大前提です。 更に、パケットは、通過する機器により、分解される可能性もあります。 それぞれ分解されたパケットも送り先に正しく到着する保証はありません。

TCPは、パケットを利用して、上位層で、構築されています。 この上位層では、相手にデータが正しく到着を保証する機能が組み込まれています。 相手にちゃんと届いたかどうかは、相手が「到着しましたよ」という荷札の付いたデータを送信して、送り側が受信して、始めて成立します。 なかなか、相手から「到着した」というパケットが届かない、もしくは、後で送ったパケットが到着したという通知がきた場合、前のパケットを再送したりします。 これらの一連の動作は、

www.infraexpert.com

に詳しく記述されています。 

さて、TCP/IPでは、様々が作業をして、できるだけ効率よくデータを送信する仕組みができていますが、一体誰がその仕組みを動かしているのでしょうか。 この仕組みは、多くの場合OSが行っています。 ゲーム機などは、ゲーム自身がネットワーク機構を能動的に動かしている場合もあります。

大きさが決まったデータをTCP/IPで送信する場合、アプリケーション自身は、ファイル等を入力とするため、アプリケーションで、ファイルからの読み込みの大きさを操作できて、送るデータの大きさも、入力に合わせて操作できます。 実際に送信を行う機器(ネットワークカードか、マザーボードに組み込まれている。 これを通信デバイスと呼びます。)をOSが制御して、送信を行います。 送信するデータが相手に到着しない可能性があるので、OSは送信したデータを管理するバッファも持ちます。 OSは通信デバイスの空き情報を調べて、送るべきデータを設定します。 また、一定時間経過したり、相手から到着完了の情報が到着しない場合、再送を行います。 もし、OSが管理しているバッファが一杯になったら、アプリケーションに送れないと結果を返します。 多くのアプリケーションは、OSが管理しているバッファの状態を監視して、送信可能になったら、OSに送信データを送付します。

通信デバイスは、自身が持っているバッファが一杯になったら、それ以上のデータを受け付けません。 OSは、これを管理して、通信デバイスのバッファの空きが出れば、自分のバッファにあるデータを機器に送ります。 更に、複数のアプリケーションが送信を行う場合もありえます。 特に、Webサーバの場合、利用者からの接続ごとに、一つのアプリケーションとして実行されるので、複数の(同じ)アプリケーションがOSに送信データを送ります。

また、通常LANとインターネットの送信能力を比べると、LANの方が送信能力が高く、パケットの欠落が少ない。 更に、計算機で、通信デバイスにデータを転送する能力(内部バス)は、LANの送信速度より早い。

まとめると、

(1)OSがバッファを持って、送るデータを管理している。 

(2)相手からの返信によって、正しく到着したか分かる。

(3)OSが管理しているバッファが一杯になったら、送信ができないので、エラーを返し、アプリケーションに処理を任せる。

(4)データの送信速度は、 内部バス > LAN > インターネット となり、データの欠損率は、 インターネット > LAN > 内部バス

の順番になります。 

以上のことから、インターネットを利用したTCP/IPによるデータ送信は、計算機内部で閉じた通常のコンピュータプログラムの処理とは異なり、送信先の計算機や伝送路の状態により、伝達時間が変化し、 送信元の計算機の処理の負荷も相手や伝送路の状態により変化します。

ストリーミングによるTCP/IPを使った動画・音の伝達

テレビやラジオの受信は、受信機が視聴の必要があるチャンネルのデータを受信して、再生します。 視聴している間だけ、受信しています。 一方TCP/IPを使ったストリーミングは、視聴している間だけ、受信しているわけではありません。 伝送路や計算機(コンピュータ)の状態により送信時間がまちまちなるため、できるだけ多くのデータを送信し、受信した計算機は、バッファに蓄える仕組みを持っています。 例えば、パケットの容量により支払う価格が異なるような携帯電話では、 ストリーミングによる映像や音は、 利用者がたとえ少しだけしか視聴していない場合でも、 受信するデータ量は、実際に視聴したデータ量を越えてしまいます。 これは、現状のTCP/IPの送信では、必要な分だけを送信する機構ができにくく、通信経路の状態によっては、映像や音が停止してしまうのを防ぐため、できるだけ多くのデータの送信を行うため生じます。 更に、ライブ中継などでは、現在ライブが行われている映像や音が最新であり、未来の映像や音を送信することができません。 そこで、送信元では、ある程度映像や音を貯めてから送信を開始します。 従って、ライブやリアルタイムといったうたい文句のシステムの殆どは、実際に行われている現状とは、異なり遅れて配信をしています。 このため、TCP/IPを利用したインターネットによる、テレビの再配信は、必ず遅延が生じます。 結局、緊急時に情報をいち早く提供する義務を果たすことができません。

インターネットを使った音の再送信は、ラジコが行っています。 しかし、ラジコは、

faq.radiko.jp

の「パソコンでラジコを聴くには?」の回答で、述べられている様に、緊急速報には、対応していいません。 一方KeyHoleTVでは、 ラジオの再送も行っています。 KeyHoleTVの遅延は、およそ0.5秒であるため、アナログ放送(電波で放送)よりは遅いが、他のデジタル放送より早い。 

動画の圧縮

 現在、多くのストリーミングやダウンロードなどで計算機や携帯電話で動画を視聴できます。 動画は、様々なコーデックで圧縮されています。 MPEG-X(MPEGは、バージョンにより、MPEG1,MPENG2, MPEG4があります)やH26X(H261,H262,H264など)は、バージョンによって圧縮する方法が異なっていますが、多くは過去のデータを参照します。 動画は、複数枚の絵から構成され、おおよそ一秒間に30枚の絵が必要です。 一秒間に60枚の絵があると、動画に深みがでます。 これは、ゲームなどでも同様で、30フレームや60フレームといった呼び方があり、それぞれ、一秒間に30回、60回絵が変わります。 動画も同様に一枚の絵をフレームと呼びます。

MPEGやH26X等のコーデックは、

ja.wikipedia.org

 という具合に複数ありますが、動画を圧縮するための仕掛けとしては、ある程度フレームをまとめてエンコードを行います。 

tmpgenc.pegasys-inc.com

上記のリンクのGOPがフレームをまとめたものになります。  フレームをまとめたGOPの中には、フレームの映像が完全に再生できるものと、再生されたフレームの映像を利用して、再生されるものがあります。 GOPを一つの送信データとする場合、送信データが完全に相手に届かないと、映像がGOPのフレーム分再生できません。 地上波デジタル放送では、テレビ映像が停止する現象が頻繁に発生しませんが、衛星放送がデジタルで送信されている場合、天候などによって、映像が停止する場合があります。 これは、GOPのデータが完全に届いていないために発生しています。 停止してから、’再び映像が再開されるためには、次のGOPのデータが完全に届く必要があります。 また、地上波デジタル放送で、チャンネルを切り替えたときに、すぐに映像が映らない場合があります。 これもGOPのデータが完全に届いてから、映像が再開されるために起こる現象です。

インターネットを利用して、テレビやライブ会場の同時配信をしている多くのシステムは、MPEGやH26Xのエンコードを採用しているため、少なくとも、GOPを構成するフレーム分は、送信する時点で送れています。 更に、インターネットで送信して受信するまでの時間も必要ですから、決してリアルタイムではありません。 電波を使った地上波デジタル放送ですら、3秒程度の遅延が生じています。 インターネットを使った場合、通常のシステムは、3秒どころではなく、もっと送れています。 一方KeyHoleTVは、およそ 0.5 秒の遅延だけで、受信できています。 これは、KeyHoleTVシステムがGOP利用しないで、データを配信しているためです。

 

 

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

www.oiseyer.com

 で。

(つづく)

 

 

 

 

 

 

 

 

 

 

 

 

販売システムのネットワークのセキュリティについて

販売システムの種類

KeyHoleTVは、現在有料のプレミアムモジュールキーを販売して、運営しており、PayPalを使った決済を採用している。 殆どの決済を持ったサイトは、決済システムからの結果をリダイレクトで受け取る仕組みをもっている。 この仕組みは、商品を購入する際、一旦クレジットカード等の決済するシステムに商品の価格、個数の情報を渡す。 そして、決済が完了すると、ブラウザのリダイレクト機能を用いて、自分の販売サイトに購入結果の情報が届く。

一連の流れは、

(1)顧客がブラウザで、商品サイトをアクセスする。

(2)顧客が商品サイトで購入する商品を選ぶ

(3)選んだ商品を清算する

 ここで、決済システムに移行する。 購入サイトは、選んだ商品の名称(もしくは、固有の名前)、個数、価格を決済システムに伝える。 決済システムに伝える方法は、直接購入サイトが決済システムに伝える場合と、一旦顧客のブラウザを介して伝える方法がある。 KeyHoleTVのプレミアムモジュールキーの販売システムは、一旦顧客のブラウザを介して伝える方法を採用している。

(4)決済終了後、商品サイトに購入情報が伝達される

決済システムから、購入サイトに情報が伝達される。 これも、直接決済システムから購入サイトに情報を伝達する方法と、一旦顧客のブラウザを介して情報を伝達する方法がある。

 

https://s.yimg.jp/images/tecblog/2014-2H/hello_fastpay/1.png

上記の画像は、商品サイトが直接決済システム情報が伝達する仕組みを示している。

(https://gihyo.jp/dev/serial/01/paypal_api/0002の画像を転用)

また、

https://image.gihyo.co.jp/assets/images/dev/serial/01/paypal_api/0002/thumb/TH400_002.png

https://gihyo.jp/dev/serial/01/paypal_api/0002の画像を転用)

上記の画像は、一旦顧客のブラウザを介している仕組みを示している。 図中にあるリダイレクトがブラウザを介していることを示している。

販売システムと決算システムとの連携で生じるセキュリティの問題

販売システムと決算システムの連携は、直接連携する場合と、ブラウザを介して連携する場合があることを説明した。 どちらの場合もセキュリティ上一長一短がある。 まず、直接連携する場合について、問題点をあげていく。

多くの直接連携をするシステムの場合、購入サイトと決算システムが利用者のブラウザ上で、シームレスな画面遷移になっている。 シームレスな画面遷移とは、例えば同じロゴが画面上に現れていて、同一感を醸し出している。 購入に関しては、クレジットカードを使う場合が多い。 当然、クレジットカードの情報は、利用者が入力する必要があり、販売サイトを運営する企業がクレジットカード等の個人情報を管理する必要がある。 

ニュースで時折、顧客のクレジットカードの情報が流出する事件が報告される。 これは、企業が管理しているクレジットカードの情報がハッキングされて盗み出されることで起こる。 これを防止するためには、 一般に、大変が金額がかかる。 例えば、これに関連している作業をしている人の人事までも、関係する。 例えば、関連している作業を行っている人が企業を退職した場合、その人が知っていた情報をブロックしたり、変える必要があるし、人事的にも手厚くしないと、情報が漏れる可能性もある。

また、シームレスな画面が表示されることから、偽りのサイトに誘導されても、顧客は気づかない場合が多い。 ブラウザ上で表示されるすべての絵や文章は、簡単に取得できるので、 偽りサイトを構築するのは、容易に行える。 更に、サイトを改変する場合でも、殆どの場合、一ヶ所を改変できれば、偽りサイトに誘導できる。

一方、ブラウザを介して連携する場合、決済システムは、独自のノウハウを持っている会社が行っている。 例えば Paypal やF-REGI(エフレジ)などがある。 これらの会社は、顧客のクレジットカードの情報の管理のセキュリティが高い。 また、クレジットカードの番号などを毎回入力する必要がない。 更に、販売サイトを改変して、偽りサイトに誘導しても、顧客がそのサイトにログイン出来なかったりするので、気がつきやすい。 更に、決済後、販売システムに情報が届かないので、商品を発送したり、 顧客は、サービスが受けられない。 販売サイトを改変しようとしても、複数の場所を改版する必要があり、難易度が上がる。

 ブラウザを介して、販売システムと決算システムとの連携で、問題となるは、実はリダイレクトになる。

リダイレクトで発生するセキュリティの問題

ブラウザの暗号通信は、アドレスには適応されない。 ブラウザのアドレスバーに https://www と表示されている場合、通信内容が暗号化されている。 しかし、暗号化されているのは、通信の中身だけで、https://www.aaa.com/ のアドレスである www.aaa.com は、暗号化されているわけではない。 だから、だれかが通信を傍受している場合、 どこに接続しようしているかわかってしまう。

KeyHoleTVの販売システムは、決済が完了して、リダイレクトで、再び販売システムと通信して、プレミアムモジュールキーの設定を行う。 この時、不正なデータが場合によって何度も送られてくる場合がある。 販売サイトの対策が不十分である場合、同じ商品を2度発送したりするかもしれないし、在庫管理システムに誤った情報を送るかもしれない。

実は、不正なデータが送信されれば、そのことを報告するようなっている。 おそらく、全ての販売システムでも、不正データが送信されたとき、それを関知している。 しかし、関知しているだけで、それを利用者(購入者)に伝えていない。 KeyHoleTVでは、利用者(購入者)に伝えている。 これは、おそらく利用者が使っているネットワークが他人に勝手に利用されている可能性が高く、通信を逼迫させる原因の一つになるからで、結局KeyHoleTVの動作が不調に陥る可能性が高い。  おそらく他人のPCがウィルスに感染して、WiFiを経由して通信を監視している。 ウィルスに感染しているPCは、自分のネットワークを使わずに、他人のWiFiを利用しているため、感染者は、自分のネットワークが遅くなることがないので、気がつきにくい。 更に、 WiFiを勝手に利用するようなウィルスの場合、他のPCにウィルスを感染させる。 殆どのセキュリティソフトウェアは、 外からの攻撃や侵入に対して有効に働くが、LANから入ってくるウィルスには、ほとんど有効に働かない。 ある日突然、PCがのっとられたり、データが書き換わって、PCが利用できなくなる。 更に、このようなウィルスは、ウィルスの開発者の命令により、DoS攻撃(特定のアドレスに何度もデータを送信させて、サーバの処理やネットワークを遅延させたり、異常終了させる)をする場合もある。 たとえ、DoS攻撃をしても、感染者のPCは、あまり遅くならないので、気がつかない。 しかし、WIFiを勝手に利用されている人は、ネットワークが遅くなり、なぜだろうと悩む結果になる。

KeyHoleTVでは、購入時に不正なアクセスがあった場合、購入者にメールを送って、ネットワークに問題がある旨を報告している。 購入者がホテルやカフェ、もしくは空港のような公共なネットワークを利用している場合、ウィルスに感染しているPCが接続されていても、大きな問題に発展しにくい。 しかし、自宅や会社の場合、WiFiが勝手に利用されていたり、LANないにウィルスに感染したPCが存在する場合がある。 ただ、残念なことに、メールを送付しても、返信を頂けれる利用者が少ないのが現状である。 

WiFiを勝手に利用されないようにするためには、WiFiのパスワードだけでは、不十分だ。 なにしろ相手は、殆ど無限に時間があるし(ウィルスが勝手に行う)WiFiの種類によっては、パスワードが見えている場合もある。 これを防止するためには、 MACアドレスフィルタをルータやADSL,ケーブル、光モデムに設定する以外方法がない。 殆どのADSL、ケーブル、光モデムは、ルータ機能を保有しており、MACアドレスフィルタの設定ができる。 

MACアドレスは、WiFiを利用する機器に割り振られているユニークな番号で、AA:BB:CC:00:...もしくはAA-BB-CC-00-...のような形をしている。 この番号をモデムやルータに登録して、登録している機器以外の通信を許可しない。 これで、たとえ、近隣の人のPCがウィルスに犯され、WiFiに侵入しようとしても、侵入できない。 ただ、 ルータやモデムの設定をWiFiでは、可能にしないことが条件である。 

プレミアムモジュールキーを購入された利用者は、ネットワークの盗聴の可能性をできるだけ、伝えるようにしている。 なお、KeyHoleTVのダウンロード・プレミアムモジュールキーの購入は、

www.oiseyer.com

で。

KeyHoleTV開発秘話(その1)

なぜ、KeyHoleTVは、連続して11年間も配信できるのか

海外で、日本のテレビを視聴できるサービスは、数多くあります。 しかし、多くのサービスは、途中で止めたり、配信が停止したりします。 しかし、KeyHoleTVは、11年連続して配信をしています。 どうしてでしょうか?

答えは、KeyHoleTVのシステムの秘密にあります。

殆どのサイトは、日本から参照できない

海外で日本のテレビを視聴できるサービスを運営しているサイトのほとんどは、日本からは、参照できません。 例えば、

上記のサイトは、日本からは、アクセスできません。 海外からアクセスすると、以下のような表示がブラウザに現れます。

f:id:KeyHoleTV:20190613061656p:plain

SKYLINVE NET TVのスクリーンショット

これは、自分たちが日本の法律を犯していて、停止させらる可能性があるので、できるだけ日本からは、アクセスできないようにしているためです。 これらのサイトには、アクセスされた場所によって、サイトを表示したり、しなかったりする機能が埋め込まれています。

海外の人が上記のサイトにアクセスできない旨を確かめるためには、VPNを使う必要があります。 VPNサービスは、VPNサーバを置いている場所から、サイトにアクセスします。 自分のブラウザは、あくまでも VPNサービスのサーバとの間で暗号化した通信を行います。 このため、VPNサーバが置いている国(や地域)がサイトへのアクセスされた場所になります。

VPNの設定は、OSやVPNを使うアプリによって、難易度が変わります。 比較的容易に行えるのが、アンドロイド端末です。 VPNを使うアプリがあり、利用できるサイトが公開されています。

www.vpngate.net

アンドロイドで、日本のVPNを接続して、ブラウザでSKYLIVE NET TVをアクセスした結果は、

f:id:KeyHoleTV:20190613140847p:plain

日本のVPNを介してサイトにアクセス


となります。 左上に小さくError と出ています。 これは、アクセスしたアドレスが日本の場合、エラーを表示するようになっているためです。 また、VPNを使うことで、日本国内にいても、あたかも海外からアクセスできるようになります。

また、日本からVPNを使わないで、あたかも海外からアクセスしたようなサービスが、海外にはあります。

www.browserling.com

このサイトの入力バーに  http://skylivetv.net/ を入力すると、ページが正しく表示されます。

 

一方KeyHoleTVのサイト 

 

www.oiseyer.com


は、日本はもとより世界中からアクセスできます。 では、どうして、KeyHoleTVのサイトは日本からアクセスできるのでしょうか?

関係省庁に再配信の許可の依頼

おそらくKeyHoleTVが唯一関係省庁に再配信の許可の申請を出しています。 他のネットを使った視聴システムは、放送局が行っているもの以外、おそらくどこも申請をしていません。 ネットを使ったのシステムは、申請ができる条件を残念ながら満たしてません。 ケーブルテレビは、再配信の申請をして、再配信をしてます。 これは、地上波デジタル放送が場所によって、通常のアンテナでは視聴できないため、ケーブルテレビで難視聴地域を解消するためです。 ただ、難視聴地域を解消する目的だけで、ネットを利用した配信は許可されないようです。 日本における放送は、特殊な意味を持っています。 放送を行うには、当然認可が必要で、国の裁量によって、決定されます。 放送には、緊急時にいち早く情報を伝達する義務(法律で決まっています)があり、この義務を守れていない場合、許可が下りません。 多くのネットを使った再配信は、この義務を守ることができていません。 だから、再配信の許可が下りないのです。

KeyHoleTVは、他の配信システム(地上波デジタル放送を含む)より、早く情報の伝達ができるため、 関係省庁に再配信の許可の申請を行いました。 早く受信できる事実は、YouTUBEに掲載しています。

youtu.be

これは、地方で地デジをテレビで受信したものと、KeyHoleTVで受信したものを比較しています。 明らかにKeyHoleTVの方が早く受信できています。

次回は、なぜKeyHoleTVが早く送信できるかをお伝えします。

(つづく)

 

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

www.oiseyer.com

で。