KeyHoleTV開発者のブログ

日々の質問や開発の日記

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

 で。

(つづく)