KeyHoleTV開発者のブログ

日々の質問や開発の日記

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開発秘話(その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

で。

Windows10でKeyHoleTV動作しなくなった

利用者からWindows10 でインストールしたKeyHoleTVが、動作しなくなったとの報告を受ける。 ダブルクリックしても、アプリケーションが起動しないとのこと。

アプリケーションが起動しないのは、起動しない理由がある。もし、アプリケーションがエラーや「アプリケーションに問題が発生しました」などのメッセージを表示せず、動作しなくなったのは,大きく分けて二つの原因がある。 一つは、アプリケーションが入っているフォルダが何らの原因で壊れている可能性。
もう一つは、OSがアプリケーションの動作を停止している可能性。 アプリケーションが格納されているフォルダが壊れている場合、OSがアプリケーションをピックして、実行させようとして、正しいライブラリがピックできないか、実行中ファイルが壊れていて、中に格納されている命令が正しく動作しない。 この場合、ファルダが壊れているので、別のフォルダにインストールすると、動作する可能性がある。 しかし、フォルダが壊れる現象は、ハードディスクが何らかのエラーがあるので、そのうちPCが動作しなくなる可能性が高い。

OSがアプリケーションの動作を停止している場合、殆どはセキュリティソフトウェアが通信の許可リストに入っているアプリケーションを外しているのが原因。 現在、3例の報告があり、その全てが、SOURCENEXTのウィルスソフトウェアである。 過去にも、ここのソフトウェアは、他のセキュリティソフトウェアと比べて、反映が遅く、他のセキュリティソフトウェアがウィルスではないというソフトウェアをウィルスと判断したことが多々ある。

報告をした利用者のセキュリティソフトウェアもSOURCENEXT製である。おそらく、通信の例外リストに載っているソフトウェアを利用者の許可なしに消してしまう。 消してしまった、通信の許可リストにKeyHoleTVを追加すれば、解決する。

通信の許可は、

に詳しい。 

KeyHoleTVは、

C:\Program Files (X86)\ KeyHoleTV

にKeyHoleTV.exe がある。 このEXEを通信を許可するリストに追加すれば、よい。

 

また、何らか理由でアプリがローカルグループポリシーのアプリ項目の拒否リストに載る場合もある。 何故このようなことになるのかは、原因が分からないが、おそらくセキュリティソフトウェアが何らかのメッセージを出して、それに答えたことが原因だと思う。 マイクロソフトは、自分が認知していないソフトウェアや例外設定の場合、多くの場合、「拒否」がデフォルトになっている。 このため、OKを押すと「拒否」が設定される。 また、セキュリティソフトウェアもおそらく、「拒否」がデフォルトになっていて、「OK」を押すと、拒否されると予想する。

ローカルグループポリシーの実行拒否リストに登録された場合、そのログイン名では、ソフトの実行ができない。 

answers.microsoft.com

上記の記事を読むと、別のユーザを作ってみると、アプリが動作したとある。 おそらく、これは、ローカルグループポリシーで、アプリを起動させないような設定になっていると思う。 そこで、解決方法は、ローカルグループポリシーエディタを起動して、KeyHoleTVを許可するか、新しくユーザを作る以外方法がない。 

Windows10では、ローカルグループポリシーを編集するのに、OSの種類によっては、エディタが内包されていないようだ。

appli-world.jp

ローカルグループポリシーエディタが開いたら、

www.livefree.jp

の 

https://www.livefree.jp/wp-content/uploads/2019/04/spr02.png

https://www.livefree.jp/windows10_srp_store/からの転用) 

で、追加の規則の中におそらくKeyHoleTVが入っているので、制限を解除すればよいはず。 また、KeyHoleTVは、32bit アプリケーションなので 32bit アプリが全て実行不可能になっている可能性もある。 その場合、KeyHoleTVに例外を設定すればよい。 ローカルグループポリシーに実行拒否が設定されれば、アプリケーションを再インストールしても無駄で、 ローカルグループポリシーを変更するか、新しくユーザをWindows10で作る以外おそらく対処する方法がない。

 

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

www.oiseyer.com

で。

Cydia への対応

脱獄事始め

顧客から JB(脱獄)したiPhoneをiOS12に上げたら、 前のバージョンのi-KeyHoleTVが動作しなくなったと報告を受ける。 でiOS12では、AD-HOC版のネットでのインストールがうまく行かない不具合がある(この不具合は、 XCdoe10.2.1でやっと解消されました)。 この不具合は、 Code Signの埋め込みの不具合で、Appleが直さなければ、開発者としては、どうしようもない。

それで、Cydia でインストールできるようにするために、

putidevelopersblog.blogspot.com

を参考にして、i-keyholetvをアップロードした。 すると、顧客からは、 error 404 が出てくるとの報告を受ける。 

Cydiaでは、Debianのパッケージ読み取りをCydiaのリポジトリで行っている。 このため、Packages.gz2 と XXX.deb ファイルがあると、パッケージとして認識して、 404のエラーはでないはず。 一般に404のエラーは、HTMLのブラウザが表示する。

こちらとしては、顧客が何をしているかのか分からないし、手元に脱獄した iPhoneがないため、

本当のことが分からない。 また、Cydiaのリポジトリをアップする情報が極端に少ないため、どうすれば、正解なのかが分からない。

で、手元に古いiPhone 5があったので、それを脱獄して、Cydiaのリポジトリの表示がどうなるか調べてみた。 また、脱獄した iPhoneで i-keyholetvがインストールできるか調べてみた。

iPhoneの脱獄

一般に IOSのデバイスは、 AppleStoreにあるアプリケーションとAD-HOCと呼ばれるUDID(機器に付随するユニークな番号)を登録している機器に対して、有効なアプリケーションしかインストールすることができない。 しかし、脱獄すると、AppleStoreにないアプリケーションや AD-HOCのアプリケーションをインストールすることができる。

脱獄には、様々な方法が存在するようだが、

ja.wikipedia.orgCydiaで脱獄したアプリケーションをインストールを調べる目的があるので、 Cydiaを使った脱獄を試みる。

Cydiaのインストール

iPhoneにCydiaを入れるためには、Cydia Impactor を使う

cydia-app.comCydia Impactorで、Cydiaアプリが入ったIPAファイルをiPhoneに入れる。 Cydiaアプリは、iOSのバージョンによって、インストールするIPAが異なっている。

cydia-app.com手持ちのiPhone 5にCydiaを入れる際、 Cydia Impactorが動作する。Linux (CentOS 64 bits, Ubuntu 32bits)Windows32bits,Windows64bits, MacOSが存在するが、私の環境では、 Windows 32bitでしかインストール出来なかった。 Linuxでは、 Cydia Impactorが

lockdown.cpp:57 LOCKDOWN_E_INVALID_CONF

のエラーを吐き出して、処理が進まなかった。 Cydia Imapctor を動作させて、 IPAを入れる際、 Apple のAPP SPECIFIC PASSWORDSが必要で、AppleIDを管理するサイトにログインして、APP SPECIFIC PASSWORDSをCentOS, UbuntuのFireFoxで作ってみたが、Cydia Impactor で、作ったパスワードを入れても、上記のエラーがでてしまう。

yalujailbreak.net直す方法をいろいろ試してみて、iTunsが必要になって、 結局 MacOSで、サファリを使って、

APP SPECIFIC PASSWORDSを構築した。 Windowsの32bitsでは、iTunesを使って、

Appleにサインインしようとすると、なぜか、iTunesがエラーを出して、停止してしまう。 しかたがないので、 Macを使って、 iTunesを起動して、そこから Safariでログインした。 それで、構築した APP SPECIFIC PASSWORDS を Windows32 bitsのCyida Impactorで入力すると、インストールが始まった。 関係があるのかないのか分からないが、APP SPECIFIC PASSWORDS を構築する際、適当な名前を入力する必要があるが、Linuxでは、本当に適当な名前を入れて、 MacOSでは、Cydiaと入れた。 

脱獄開始と問題発生

インストールが始まってしばらくしてから、Cydia Impactorが Generating Application Mapを表示して停止した。 iPhoneには、h3lixのアイコンが表示されていた。 脱獄する際、 対象のIPAは、IOSのバージョンで異なる。 h3lixは、 iOS10.3.3 用のIPAで、別のバージョンのiOSは、他のIPAを利用する。 一旦iPhoneを再起動してみて、 h3lixをタップしてみる。 h3lixが起動できたので、うまくいったと思って、 Jail Break のボタンをタップしようして、確認のため、脱獄のサイトを見てみると、

www.iphonehacks.comTrust Developer Profile とある。 iPhoneを調べてみても、General > Profile(s) & Device Managementが表示されない。 で、iPhoneにDeveloper Profile をインストールする。 Developer Profileがインストールされいないと、Profile(s) & Device Managementが表示されないようだ。 Profile をインストールするためには、 iPhoneでSafariを起動して、

beta.apple.com をアクセスする。 AppleIDでログインする。

developer.apple.comログインした後、Appleからセキュリティコードを聞かれる場合がある。 これは、登録している iPhoneに送られてくる番号をiPhoneで受信して、その番号を入れる。 サイトに入って

Enroll Your Device を選んでダウンロードプロファイルをタップすると、iPhoneにProfile が入る。

iOS10.3.3では、General のVPNの下にプロファイルが表示される。

これで、h3lixをタップして、 Jail Break ボタンをタップする。 タップすると Cydiaがインストールされ、 iPhoneを再起動するか聞いてくる。 再起動して、 Cydiaのアイコンをタップすると、

Cydia が起動して、 脱獄が完了。

 

Cydia でのリポジトリの設定

Cydiaを起動して、下にある Sourceをタップする。 すると、リポジトリが表示される。 リポジトリを追加するには、 Edit をタップして、Addをタップする。 すると、URLを聞いてくるので,

www.oiseyer.com/iOS12/

を入力する。 すると、リポジトリは、

f:id:KeyHoleTV:20190402101040p:plain

Cydiaリポジトリ

と表示される。 www.oiseyer.com をタップして、i-KeyHoleTVのインストールを行う。 また、ここまで、404のエラーは、表示されない。 

i-KeyHoleTVのインストール

リポジトリのwww.oiseyer.comをタップする。 すると All Packages とVideo Player と表示される。 アプリは、 Video Playerなので、 Video Player をタップする。 すると、画面の左上にInstallが表示されるので、タップする。 最後に確認してくるので、許可してインストールを続行する。 すると、エラーが表示された。

f:id:KeyHoleTV:20190402110021p:plain

Cydia Install Error

表示されるエラーは、404ではなく、 dpkg-deb が吐き出すエラーで、置いているファイルの.deb の認識ができないようだ。 Ubuntu で Cydia用の Packages.gz2は、正しく構築されているが、 XXXX.debの解凍ができいない。 Ubuntuで解凍を試したらできたので、解凍する仕組みか圧縮の方法がCydiaとUbuntuでは異なっている。 おそらくCydiaの方が古いと予想して、

dpkg-deb -b で作る  .deb を -Zgzip のオプションを付けて、行う。

dpkg-deb -b -Zgzip  Appのデレクトリ

とした。 これを www.oiseyer.com/iOS12

にアップして、再びCydiaでインストールを試みる。 すると、今度は正しくインストールできた。

f:id:KeyHoleTV:20190402111032p:plain

 

で、結局、404のエラーは、表示されない。 またCydiaでi-keyholetvが正しくインストールも

できた。

Cydiaでインストールしたアプリの運用

iOS10用のCydia は、h3lixをCydiaImpactor を使って導入する。 導入した後、 iPhoneの電源を入れ直すと、Cyida や Cydia を介してインストールしたアプリが動作しなくなる。 タップしても、一瞬は立ち上がるが、すぐにアプリケーションが終了してしまう。 他のバージョンの Cydia では、どうなるか分からない。 

h3lixの脱獄は、恒久的に反映されるのではないようだ。 CydiaやCydiaを介してインストールしたアプリを再び動作させるためには、h3lixのアイコンをタップして、起動しする。

起動すると、「Kickstart」というボタンが表示されるので、それをタップする。 タップすると、 iOSが再起動する。 これで、CydiaやCydiaを介してインストールしたアプリケーションが利用可能な状態になる。

 

なお、Cydia 対応のi-KeyHoleTVのインストール、プレミアムモジュールキーの購入は、

www.oiseyer.com

で。