KeyHoleTV開発秘話（その３）
KeyHoleTVがなぜ地デジより早く情報を伝えられるのか（その２）
前回(KeyHoleTV開発秘話（その２） - 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環境では、 パケットの欠落が起きて、動画が停止したり、デコード出来ずにアプリケーションが異常終了したりする結果になりました。
これを解決すべく、 UDP/IPに到着保証を儲けたRUDPで情報の送信を行いました。 RUDPは、サーバで送信量や送信タイミングを操作できるようになりましたが、結果TCP/IPを使った場合と比べて、多少は早くなったものの、十分な速度が出ません。 また、受信側である程度のバッファリングを行わないと、動画途中で停止する場合が生じました。
現在でも、殆どの動画配信サービスを利用する場合、受信者側でバッファリングを行っていますし、 視聴した動画の時間以上のデータを受信しています。
ここで、少し余談ですが、このバッファリングは、多くの場合、ファイルを利用しています。 機械式のハードディスクを利用されている場合、バッファリングためのファイルは、消去することができます。 しかし、シリコンディスクやスマートフォーン、タブレットの場合、揮発性のメモリをバッファリングで利用しているアプリ以外、ファイルを利用します。 シリコンディスクやスマートフォーン、タブレットは、データをファイルに書き込むと、そのデータは実質消えません。 消えたというフラグが立っているだけで、データ自体は、シリコンディスク、スマートフォーンやタブレットに残っています。 このため、頻繁に動画や音楽をストリーミングで楽しんでいる方で、記憶容量が小さいスマートフォーンやタブレットをお持ちの場合、ファイルの書き込みが出来なくなる時期が早まる可能性があります。 シリコンディスクの基本設計では、一日に最大４０Gバイトのデータを書き込むことを想定していますので、それを越えるような使い方をする場合注意が必要です。 動画の種類によっては、５分で、１Gバイトを越える場合もありますし、一般のストリーミングの場合、データをとにかく送信してしまう方式がとられているので、視聴時間に関係なくバッファリングしていきます。
ストリーミングファイルの書き込みが出来なくなると、タブレットやスマートフォーンは、実質利用出来なくなります。 iPhoneの発売当初、YouTUBEの動画を見るためにアプリが存在しました。 ブラウザで視聴しないで、アプリとしたのは、公式には、FlushがiPhone上で、動作するの防ぐためと言われていますが、バッファリングが一つの問題であると著者は思っています。
KeyHoleTVは、ファイルを使ったバッファリングを一切行っていませんので、一日に何時間視聴しても、問題は起こりません。 著者の家庭では、KeyHoleTVを用いて、スマートフォーンで一日に少なくとも５時間程度視聴してます。
動画の圧縮技術の開発
MPEG-XやH26Xの方法で動画をエンコードする方法は、いくつかのフレームを貯めてからエンコードするため、エンコードした時点で、実際の映像とは、遅れています。 また、送信するデータの中には、まとまったフレームのデータがあり、まとまったフレーム間で総合参照するために、データの欠落は、許せません。 更に、インターネットでデータを送信する場合、パケット単位にしかデータを送信できないので、まとまったフレームのデータをエンコードした結果、複数のパケットに分割される可能性が高くなります。 このため、UDP/IPだけで、データを送信すると、パケットの欠落が起こった場合、対処出来にくくなります。 RUDPを利用しても、送信速度は、多少向上しますが、UDP/IPだけで、送信するより遅くなります。 このため、新しい動画の圧縮方式が必要になります。
通信は、放送と違って、受信者からのフィードバックが得られます。 KeyHoleTVのシステムは、このフィードバックを利用しています。 KeyHoleTVは、他の動画視聴システムとは異なり、動画の途中から再生できたり、映像がでるまで、他のシステムと比べて時間が短いと思います。 これは、番組の視聴に参加したというフィードバックを動画を圧縮してエンコードするKeyHoleVideoというアプリケーションに伝えているからです。 KeyHoleVideoがこの情報が届くと、強制的に他のフレームを参照しないモードで、圧縮をしてエンコードします。
KeyHoleシステムの動画の圧縮とエンコードは、フレームをためず、毎フレーム送信します。 KeyHoleシステムの圧縮とエンコードは、他のフレームを参照しないモードと前のフレームを参照するモードの２種類しかありません。 MPEG-XやH26Xでは、他のフレームを参照しないIフレームと、前のフレームを参照するBフレーム、次のフレームを参照するPフレームの３種類あります。
また、送信するデータの量によって、KeyHoleVideoで指定するビットレートを越えて送信することはありません。 ビットレートを越えると分かっている場合、そのフレームを送信しません。 これがKeyHoleTVがカクカクする原因です。 多くの場合、パン（カメラを左右に動かす）やズームをする場合に、カクカクします。
KeyHoleTVシステムの圧縮は、
（１）離散コサイン変換で求まった輝度、色差データの間引きと量子化による値の縮小とビットデータの偏りを利用（小さい数値を少ないビットで表現します。 大きい数値は、多いビットで表現します。）
（２）同じ位置にあるブロックの離散コサイン変換をした結果が前のフレームと同じようなデータである場合、そのブロックのデータを同じとし、これを少ないビットで表現（米国特許取得）
（３）隣接もしくは、一つ前のフレームのブロックの比較と差分による値の縮小化とビットデータの偏りを利用
で構成されています。
（２）の特許は、固定したWebカメラやハンディ型のムービーカメラでとった壁の映像を解析しているとき、同じ条件であるにも拘らず、生データの値が変わっていたこと。 フレームを越えて生データの値が元に戻ったりするすること。 これらから、アナログ情報をデジタル変換するときに発生するノイズであろうと判断しました。 また、ビデオカメラ初心者が撮影する映像は、頻繁にパン（意図しないパン。すなわち手ぶれなど）やズームを行うので、視聴者にとって、あまりよい印象がないと考えました。 更に、テレビ番組の映像にも、それほど頻繁にパンやズームを行うことも少ないことが分かりました（スポーツ中継の場合は、パンやズームが頻繁に行われる場合があります。 残念ながら現状のKeyHoleTVは、あまり得意ではありません。）
また、（２）の特許は、MPEG2やMPEG4に対して、ノイズフィルターとしても有効です。 生画像を（２）の特許を用いたフィルタ処理した後、MPEG２やMPEG4で圧縮をかけると、
図に示したような結果になります。 オレンジが元データの大きさで単位はバイトです。 紫は、MS-MPEG４で圧縮した結果。 灰色は、H264（X264)で圧縮した結果、 薄い紫は、ノイズフィルターをかけてからMS-MPEG4で圧縮した結果です。 圧縮率は、最低の設定で圧縮を行いました。 結果が示すように、フィルタを用いてMS-MPEG4で圧縮した結果は、H264よりも圧倒的に圧縮されています。 元データにいかにノイズが多いかを示していると思います。
このフィルタをかけてH264で圧縮するともっと圧縮ができるのではないかと、予想される方もおられると思います。 残念ながらそうなりません。 MEPGの圧縮は、８x８の領域に対して、輝度、色さで処理を行っています。 一方H264は、４x４の領域に対して行っています。 MPEGの圧縮では、その処理の中に同一場所のフレーム間をまたいだ８x８の画像の比較があって、同じ画像である場合、少ないビットで、エンコードする仕組みが入っています。 この仕組みがフィルタをかけた場合に有効に働いて、圧縮が効いています。 一方H264では、４x４の輝度領域で、画像のパターン化を行います。 このパターン化のため、フレーム間をまたがった画像でも、ある程度ノイズが除去されている結果になります。 しかし、４x４のため、たとえ少ないビットで表現できても、４x４のブロックの数が増えるので、８x８の領域を用いたMPEG４にはかなわない結果になります。
MPEGでは、フレーム間で、同一位置の８x８の領域が同じでない場合、差分をエンコードします。このため、圧縮されたデータ量が増加しますが、フィルタによって、ノイズを除去すると、図に示した結果になります。
動画フレーム用UDP/IPの改良とデコーダ
KeyHoleシステムは、動画をエンコードするのに、一フレーム単位に行っています。 エンコードした結果、複数のパケットに分割されれる可能性がありますので、 送信時にできるだけインターネットの途中でパケットが分割されない大きさで送出します。 また、パケットには、エンコードしたフレーム番号、エンコードに必要なパケット数と自分のパケット番号を付加しています。 これで、受信した側は、届いていないパケットが認識できます。
受信側（KeyHoleTV）は、一つのフレームで、届いていないパケットが判明すると、届いていないと通知します。 パケットの順番が飛ばしたり、次のフレームのパケット届いた時に、通知します。
この通知は、一度限りで、2度通知することはありません。 通知が届いたら、再送します。
KeyHoleTVは、できるだけ待ってからデコードを試みますが、待てない場合、以前のフレームの絵を表示し、そのフレームのデコードを諦めます。
KeyHoleTVのデコーダは、一つ前のフレームの情報を参照しますが、それが実際に一つ目でなくても、よいように設計されています。 映像自身は、一部壊れますが、そのうち修正されるようになっています。 これは、緊急情報をいち早く伝えるための仕掛けになっています。
まとめ
KeyHoleTVのシステムは、 UDP/IP を利用することで、ほぼインターネットの送信速度と同等な速度でデータを送信可能にしました。 さらに、動画の圧縮とエンコーダを開発して、フレーム単位の圧縮とエンコードと送信、２フレームによる差分の送信、フレーム間にまたがる同じ位置のブロックを同一とする仕組みとそれをエンコードして送信、 前のフレームを参照しないで、画像の圧縮とエンコードを状態によって操作出来る仕組み、パケットが到着されない場合、再送を一度だけ行う仕組みを組み合わせることで、地上波デジタル放送より早く情報の伝達が可能になっています。
KeyHoleTVのシステムは、他の動画配信システムなどとは、根本的に違うシステムです。
KeyHoleTVのダウンロード・プレミアムモジュールキーの購入は、
で。
