JP2010504652A - ビデオネットワークを管理する方法及びシステム - Google Patents

Abstract

リアルタイムコンテンツ送信機と１つ又は複数の受信機との間でのコンテンツ送信を調整すると共に、１つ又は複数の受信機からのコンテンツ再送信をさらに調整するようになっている帯域幅管理モジュールを備えるリアルタイムコンテンツ送信機が本発明において（herein）提供される。送信機は、コンテンツを符号化するようになっている符号化モジュールをさらに備えることができる。送信機は、コンテンツストリームをリアルタイムで結合するようになっているコンテンツトランスポータをさらに備えることができる。帯域幅管理モジュールからの信号に基づいて１つ又は複数のソースからのコンテンツを受信するようになっており、帯域幅管理モジュールからの信号に基づいて１つ又は複数の宛先に受信コンテンツを再送信するようにさらになっている通信モジュールを備えるリアルタイムコンテンツ受信機も提供される。受信機は、コンテンツストリームをリアルタイムで結合するようになっているコンテンツトランスポータをさらに備えることができる。受信機は、受信コンテンツの１つ又は複数の肯定応答メッセージを１つ又は複数の送信機に送信するようにさらになっているものとすることができる。

Description

ストリーミングメディアは、配信中に、大半はクリップの形態で消費される（聞かれるか、又は見られる）メディアである。ストリーミングは、メディア自体よりもむしろ配信システムの性質である。通常、この区別はコンピュータネットワークを介して配信されるメディアに適用される。メディアストリームはオンデマンド又はライブであることができる。オンデマンドストリームは、長期間にわたってサーバに記憶され、ユーザの要求に応じて送信に利用することができる。ライブストリームは、ライブスポーツイベントのビデオストリームにおけるように特定の時間にのみ利用可能である。

ストリーミングメディアをサポートするようにネットワークプロトコルを設計することは、多くの問題を発生させる。ユーザ・データグラム・プロトコル（ＵＤＰ）等のデータグラムプロトコルは、メディアストリームを一連の小さなパケットとして送信する。これは単純且つ効率的であるが、パケットは送信中に失われたり、又は破損したりすることがある。プロトコル及び損失の程度に応じて、クライアントは誤り訂正技法を使用してデータの復元が可能であったり、消失データを補間したり、又はドロップアウトを受けることがあり得る。

ユーザ・データグラム・プロトコル（ＵＤＰ）は、インターネット・プロトコル・スイートのコアプロトコルのうちの1つである。ＵＤＰを使用して、ネットワーク接続されたコンピュータ上のプログラムは、データグラムとして知られていることもあるショートメッセージを互いに送信することができる。ＵＤＰは、ＴＣＰが提供する信頼性及び順序保証を提供しない。データグラムは順不同で到着したり、気付かれることなく行方不明になる可能性がある。あらゆるパケットが実際に到着したか否かを調べることのオーバヘッドがないので、ＵＤＰは多くの軽量又は時間的制約のある目的に対して高速でより効率的である。また、そのステートレスな性質は、膨大な数のクライアントからの小さなクエリに応答するサーバにとって有用である。ＴＣＰと比較して、ＵＤＰはブロードキャスト（ローカルネットワーク上のすべてに送信する）及びマルチキャスト（すべての加入者に送信する）に要求される。

プロトコルスイートは、任意の所与の参照モデルの層を実施するすべてのプロトコルの層の集まりである。インターネット・プロトコル・スイートは、インターネット参照モデルの一例を提供する。インターネット・プロトコル・スイートは、インターネット及び大半の商業ネットワークが実行されるプロトコルスタックを実施する１組の通信プロトコルである。これは、最初に定義された２つでもある、２つの最も重要なプロトコルである伝送制御プロトコル（ＴＣＰ）及びインターネットプロトコル（ＩＰ）に因んでＴＣＰ／ＩＰプロトコルスイートと呼ばれることがある。

インターネットプロトコル（ＩＰ）は、パケット交換インターネットワークにわたってデータを通信するために使用されるデータ指向プロトコルである。ＩＰは、インターネット・プロトコル・スイート内のネットワーク層プロトコルであり、データリンク層プロトコル（例えば、イーサネット）内にカプセル化される。下位層プロトコルとして、ＩＰは、コンピュータ間での通信可能な一意で大域的なアドレッシングというサービスを提供する。これは、データリンク層がこのサービスを提供する必要がないことを暗示する。イーサネットは、大域的に通信可能でないことを除き、大域的に一意のアドレスを提供する。

リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）、リアルタイム・トランスポート・プロトコル（ＲＴＰ）、及びリアルタイム・トランスポート制御プロトコル（ＲＴＣＰ）は、ネットワークを介してメディアをストリーミングするように特定的に設計された。後者の２つはＵＤＰの上に構築される。

リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）は、「再生」及び「一時停止」等のＶＣＲのようなコマンドを発行することでクライアントがストリーミングメディアサーバを遠隔制御できるようにし、且つサーバ上のファイルに時間ベースでアクセスできるようにする、ストリーミング・メディア・システムで使用するためのプロトコルである。リアルタイム・トランスポート・プロトコル（すなわちＲＴＰ）は、インターネットを介してオーディオ及びビデオを配信する標準パケットフォーマットを定義する。ＲＴＣＰはリアルタイム・トランスポート制御プロトコルの略であり、ＲＴＰフローの帯域外制御情報を提供する。ＲＴＣＰは、マルチメディアデータの配信及びパッケージングに際してＲＴＰと協働するが、それ自体ではいかなるデータも搬送しない。ＲＴＣＰは、ストリーミングマルチメディアセッションの参加者に制御パケットを定期的に送信するために使用される。ＲＴＣＰの主な機能は、ＲＴＰによって提供されているサービスの品質についてのフィードバックを提供することである。

伝送制御プロトコル（ＴＣＰ）等の信頼性の高いプロトコルは、メディアストリーム内の各ビットの正確な配信を保証する。しかし、信頼性の高いプロトコルは、タイムアウト及び再試行のシステムを使用して正確な配信を達成する。このことによってそれらのプロトコルの実装がより複雑になる。これはまた、ネットワーク上でデータ損失があった場合、プロトコルハンドラが損失を検出し、消失データを再送信する間にメディアストリームがストールすることも意味する。クライアントは、表示のためにデータをバッファリングすることによってこの影響を最小に抑えることができる。別の問題は、ファイアウォールがＴＣＰベースのプロトコルよりもＵＤＰベースのプロトコルをブロックしがちであることである。

伝送制御プロトコル（ＴＣＰ）は、インターネット・プロトコル・スイートのコアプロトコルのうちの１つである仮想回線プロトコル（ｖｉｒｔｕａｌ ｃｉｒｃｕｉｔ ｐｒｏｔｏｃｏｌ）である。ＴＣＰを使用して、ネットワーク接続されたホスト上のアプリケーションは互いに接続することができ、その接続を介してデータをパケットで交換することができる。プロトコルは、センダから受信機へのデータの高信頼性且つ同順での配信を保証する。ＴＣＰはまた、同じホスト上で実行されている同時アプリケーション（例えば、ウェブサーバ及び電子メールサーバ）による複数の接続に関してデータを区別する。

ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、ワールドワイドウェブ上で情報を転送又は伝達するために使用される方法である。その当初の目的は、ＨＴＭＬページを公開して検索する方法を提供することであった。ＨＴＴＰの開発は、ワールドワイドウェブコンソーシアム及びインターネットエンジニアリングタスクフォースによって統合され、最終的に、一連のＲＦＣ、特に、今日一般的に使用されているＨＴＴＰのバージョンであるＨＴＴＰ／１．１を定義するＲＦＣ２６１６が公開された。ＨＴＴＰは、クライアントとサーバとの間の要求／応答プロトコルである。ウェブブラウザ、スパイダ、又は他のエンドユーザツール等の発信元クライアントをユーザエージェントと呼ぶ。ＨＴＭＬファイル及び画像等の資源を記憶又は作成する宛先サーバは、オリジン（ｏｒｉｇｉｎ）サーバと呼ばれる。ユーザエージェントとオリジンサーバとの間には、プロキシ、ゲートウェイ、及びトンネル等のいくつかの介在物があり得る。ＨＴＴＰクライアントは、リモートホスト上の特定のポートに対して伝送制御プロトコル（ＴＣＰ）接続を確立することによって要求を開始する。そのポートをリスン（ｌｉｓｔｅｎ）しているＨＴＴＰサーバは、クライアントが要求メッセージを送信するのを待つ。サーバは、要求を受信すると、ステータスライン及び本文が恐らくは要求されたファイル、エラーメッセージ、又は他の何等かの情報であるそれ自体のメッセージを返送する。

ハイパーテキスト転送プロトコル（セキュア）すなわちＨＴＴＰＳは、ワールドワイドウェブ上の標準暗号化通信メカニズムである。ＨＴＴＰＳは、ＨＴＴＰを使用して資源にアクセスする場合に通常使用されるｈｔｔｐ：スキームと構文的に同一であるＵＲＬスキームである。ｈｔｔｐｓ：を使用して、ＵＲＬは、ＨＴＴＰを使用すべきであるが、その際に異なるデフォルトポートを使用し、且つＨＴＴＰとＴＣＰとの間に追加の暗号化／認証層を使用することを示す。このシステムは、認証及び暗号化された通信を提供するために、Netscape Communications Corporationによって開発された。またこのシステムは、支払いトランザクション等のセキュリティが重要な通信に対してワールドワイドウェブ上で広く使用されている。

ユニキャストプロトコルは、メディアストリームの別個のコピーをサーバから各クライアントに送信する。これは単純であるが、ネットワーク上でのデータの大量の重複に繋がり得る。マルチキャストプロトコルは、任意の所与のネットワーク接続を介して、すなわち任意の２つのネットワークルータ間のパスに沿ってメディアストリームのただ１つのコピーの送信を行うようになっている。これはネットワーク容量をより効率的に使用するが、実装がはるかに複雑である。さらに、マルチキャストプロトコルはネットワークルータ及びサーバに実装しなければならない。

コンピュータネットワークでは、ユニキャストは単一の宛先への情報パケットの送信である。「ユニキャスト」は、ブロードキャストの対極であるため、ブロードキャストなる単語から派生したものである。コンピュータネットワーキングでは、マルチキャストは、ブロードキャストの効率のいくらかを取り戻すために使用される。これらの用語は、ストリーミングコンテンツプロバイダのサービスと同義でもある。ユニキャストサーバは、ストリームを一度に１人のユーザに提供するのに対して、マルチキャストサーバは、コンテンツを複数のユーザに同時に提供することによって、より大規模な視聴者をサポートすることができる。

２００５年の時点で、インターネット上の大半のルータはマルチキャストプロトコルをサポートしておらず、多くのファイアウォールがマルチキャストプロトコルをブロックする。マルチキャストは、大学及び企業等の自身のネットワークを実行する組織にとって最も実用的である。組織は各自のルータを購入し、自身のネットワークリンクを実行させるため、マルチキャストプロトコルをサポートするコスト及び労力が、結果として得られる帯域幅の節減で正当化されるか否かを判断することができる。

ピアツーピア（Ｐ２Ｐ）プロトコルは、メディアをすでに有しているクライアントからメディアを有していないクライアントへのメディアの送信をアレンジする。これは、サーバ及びそのネットワーク接続がボトルネックになることを防ぐ。しかし、これは技術的な問題、性能上の問題、品質上の問題、ビジネス上の問題、及び法的な問題を生じさせる。

ピアツーピア（すなわちＰ２Ｐ）コンピュータネットワークは、主に、比較的少数のサーバ内に計算能力を集中させるのではなく、ネットワーク内の参加者の計算能力及び帯域幅に依存するネットワークである。Ｐ２Ｐネットワークは、通常、既存の接続を介してノードを接続するために使用される。このようなネットワークは多くの目的で有用である。オーディオ、ビデオ、データ、又はデジタルフォーマットのいかなるものも含むコンテンツファイルを共有することは非常に一般的であり、また電話トラフィック等のリアルタイムデータもＰ２Ｐ技術を使用して渡される。

純粋なピアツーピアネットワークは、クライアント又はサーバという表記を有さず、ネットワーク上のその他のノードに対して「クライアント」及び「サーバ」の両方として同時に機能する等しいピアノードのみを有する。このモデルのネットワーク構成は、通常、通信が中央サーバを対象として行われるクライアント・サーバモデルと異なる。非ピアツーピアファイル転送の代表的な例は、クライアントプログラム及びサーバプログラムが大きく異なり、クライアントがダウンロード／アップロードを開始し、サーバがこれらの要求に応答して要求を満たすＦＴＰサーバである。

ＦＴＰ、すなわちファイル転送プロトコルは、ＴＣＰ／ＩＰプロトコルをサポートする任意のネットワーク（インターネット又はイントラネット等）を介してファイルを交換するために一般に使用されるプロトコルである。ＦＴＰ転送には２つのコンピュータ、すなわちサーバ及びクライアントが関わる。ＦＴＰサーバソフトウェアを実行しているＦＴＰサーバは、ネットワーク上で他のコンピュータからの接続要求をリスンする。ＦＴＰクライアントソフトウェアを実行しているクライアントコンピュータは、サーバへの接続を開始する。クライアントは、接続されると、サーバへのファイルアップロード、サーバからのファイルダウンロード、サーバ上のファイルの名前変更又は削除等の複数のファイル操作動作を行うことができる。

ピアツーピアネットワークの１つの可能な分類は、ネットワークの集中度による分類である。
ａ．純粋なピアツーピア：ピアは対等に動作し、クライアントの役割とサーバの役割とを併合する。ネットワークを管理する中央サーバはなく、中央ルータもない。

ｂ．ハイブリッドピアツーピア：ピアについての情報を保持し、その情報に対する要求に応答する中央サーバを有する。ピアは、利用可能な資源をホストし（中央サーバがこれらを有しないため）、共有したい資源を中央サーバに知らせ、また資源を要求したピアに共有可能な資源を提供する責任を負う。ルート端末は、絶対アドレスを得るための１組のインデックスによって参照される使用済みアドレスである。

ピアツーピアネットワークの重要な目標は、すべてのクライアントが、帯域幅、記憶空間、及び計算能力を含む資源を提供することである。したがって、ノードが到着してシステムに対する需要が増大するにつれ、システムの全容量も増大する。これは、クライアントの追加が全ユーザのデータ転送を遅らせることを意味し得る一定の組のサーバを有するクライアント・サーバアーキテクチャには当てはまらない。

ピアツーピアネットワークの分散性は、複数のピアにわたってデータを複製することによって、また純粋なＰ２Ｐシステムでは、ピアが中央インデックスサーバに頼らずにデータを見つけられるようにすることによって、故障への堅牢性も増大させる。後者の場合、システムに単一障害点がない。

ビデオホストサービスは、個人がビデオをインターネットウェブサイトにアップロードできるようにする。次いで、ビデオホストはビデオをサーバに記憶し、個々の異なるタイプのコードを示して、他人がそのビデオを閲覧できるようにする。多くのユーザは、有料サービス又はＩＳＰ提供を通じてのいずれとしても個人のウェブスペースを有しないため、ホストサービスへの需要が増大するにつれて、ビデオホストサービスはますます人気になりつつある。カメラ付き携帯電話の大量市場が、消費者によって生成されるビデオの供給を増大させた。ＤＶＤを作成して家で友人に見せる等の消費者がビデオを配布する従来の方法は、電話回線の低帯域幅による低解像度等、及びカメラ付き携帯電話クリップによって提供されるような大量のソースビデオ等に適さない。これとは対照的に、現在のブロードバンドインターネット接続は、携帯電話でのビデオショットの品質を提供するのによく適している。大半の消費者は自身のウェブサーバを所有せず、これが、消費者生成ビデオコンテンツをホストする需要を生み出した。

ビデオ共有は、ユーザが各自のビデオコンテンツを配信することができるウェブサイト又はソフトウェアを指す。サービスによっては料金を課すものがあるが、その大半は無料のサービスを提供している。多くのサービスは、プライベートで共有するオプション及び他の公開オプションを有する。ビデオ共有サービスは、本質的に２つのカテゴリ、すなわち中央サーバ配信及びピアツーピア（Ｐ２Ｐ）に分類することができる。

中央サーバ配信は、まず、ユーザにビデオをファイルサーバにアップロードするように求める。各ユーザには、ビデオファイルをホストするための中央サーバ内の特定量の空間を割り振ることができる。次いで、当業界において既知の技術を使用するストリーミングサーバを利用して、ビデオが多くの視聴者に提供される。この手法は、消費者がショートビデオを共有する必要があり、メディアの所有権が重要ではなく、且つインフラコストも同様に重要ではない場合に利用することができる。この手法では、通常、センターがビデオを調べて審査する。しかし、この方法の欠点は以下である。

ａ．ビデオを中央サーバにアップロードするのに時間がかかり、プロセスに遅れを生じさせる。
ｂ．ファイル所有者によるデータファイルに対する所有権及び制御権の問題がある。アップロードされてしまうと、ユーザはコンテンツに対する所有権を失い、コンテンツに対する著作権を放棄する必要があり得る。

ｃ．この方法は、多数のユーザにストリーミングする場合にストリーミングサーバに深刻なボトルネックを生じさせる。
ｄ．この方法は、多数のユーザへのストリーミングに必要な帯域幅とコストとの密接な関わりも有する。

ｅ．この手法では、通常、ユーザは送信されるビデオ長によって制限され得る。
ｆ．ホストは、許容されるコンテンツについてポリシーを有することがあり、これは、審査・承認サイクルに遅れを生じさせ、データファイルがホストされるのを待っているユーザを苛立たせ得る。

純粋なピアツーピア配信は、中央サーバ配信において必要な中央サーバの必要性をなくすが、むしろ、ノード−ノード間のパーソナルコンピュータ通信グリッドとして機能する。この手法の焦点は、コスト及びインフラの観点から中央に対する負荷を低減することであり得る。技術的な観点から、この方法は、各種のシーケンシング及びタイムスタンプのメカニズムを使用してビデオファイルを複数のセグメントに分けるプロセスに頼ることができる。次いで、これらのセグメントが各種パーソナルコンピュータに「供給（seeding)」され、その時点から、要求に応じてグリッドの周囲で送信及び交換される。この方法は、グリッド上のノードの帯域幅資源を利用して、グリッドの周囲でのセグメントの送信を支援する。すべてのセグメントが宛先ノードに到着すると、その時になって初めて、ビデオファイルを閲覧できるようにセグメントが組み立てられて並べられる。先の方法と比較しての利点は、中央サーバでのボトルネックの低減である。しかし、この方法の欠点は以下であり得る。

ａ．受信ノード、すなわちビデオ送信の場合のビューアは、ビデオを表示できるようにするには、ビデオのすべてのセグメントが到着するまで待つ必要がある。ファイルは、セグメントで、通常は低速モードで送信され得る。ファイル全体を受信した後でのみ、処理が可能である。そのため、ビデオの場合、全部を受信した場合でしか表示することができない。

ｂ．ここでも、ユーザは、送信したビデオに対して制御権を持たない。多くのセグメント及びときには全ファイルが複製されて、グリッドの周囲のノードに記憶され、後で送信される可能性がある。

ｃ．違法ファイル共有に関連する問題の原因になり得る匿名送信によって、この方法には多くの批判がある。
ハイブリッドピアツーピアは、純粋なピアツーピアの一変形であり、グリッドからのアップロード資源の助けによる中央サーバからのメディアストリーミングに基づく。サーバは、十分な帯域幅を有する場合にはノードにストリーミングし、帯域幅が限られている場合には、ノードが、グリッドの助けを介してダウンロード様式でファイルを受信する。この性質のシステムは、個人がストリーミングのための強力なサーバインフラを確立する手段を有しない場合に利用することができる。技術的な観点から、この方法は、中央サーバのファイルを供給又はホスティングして、ファイルを第１のノードに提供することに頼り得る。次に、第１のノードは連鎖モードで他のノードに「提供」する。中央サーバ配信と比較しての改良は、サーバへのボトルネックの低減及びコストの低減である。しかし、この方法の欠点は以下であり得る。

ａ．やはり、共有前にファイルをアップロードする必要がある。
ｂ．ファイルはホスト中央サーバに記憶されるため、ファイルの制御権及び所有権の問題があり得る。

ｃ．ビデオはコンテンツ審査を受ける可能性があり、配信の遅れに繋がる。
ｄ．ビデオの表示は、サーバがビジーであり、配信をグリッドの使用に頼らなければならない状況では、即時でないことがある。

ｅ．送信ノードでのグリッドアップロード資源の使用は、マルチポイント送信メカニズムでの制約によって効率的ではないことがある。
ビデオ共有サービスの一変形は、制限付きクライアントベースストリーミングの方法に基づく。このビデオ要求サービスは、送信ノードがビデオファイルをセグメントに分割し、これらのセグメントを「ストリーム」の形態で適切な順序で受信ノードに送信することに頼る。これは主に、通信が１対１様式で必要な場合、例えば、ユーザが旅行中であり、家にあるコンピュータ又はＤＶＤに記憶してあるメディアを自分に向けてストリーミングしたい場合に使用される。このビデオ共有サービスは、中央サーバの必要性、ビデオファイルアップロードステップの必要性、及びサーバのボトルネックをなくす。しかし、欠点は、通信が、送信ノードのみの利用可能なアップロード帯域幅を利用することであり得る。したがって、通常、送信は「１対１」モード又は同時に非常に少数のビューアに制限される。

ビデオ共有サービスの別の変形は、主に多数の送信アンテナから多数の受信アンテナへの無線送信の分野でのプッシュモードでのストリームを「バースト」に結合することに基づく。技術的な観点から、複数のセンダからのセグメントを共に加算してから送信することができる。受信されると、セグメントは復号化されて、元のセグメントに戻る。利点は、アンテナがデータを複数のソースから受信するように、特に、無線受信機等の受信ノードが移動体であり、複数のソースからデータを受信する必要がある場合に送信をより効率的にすることである。この方法の欠点は以下であり得る。

ａ．受信ノードで利用可能な空きアップロード帯域幅を使用しないこと。
ｂ．セグメントは常に加算方法を介して結合され、受信の肯定応答メカニズムは実施されないため、複製パケットの除去に対する関心がないこと。

データ圧縮又はソース符号化は、特定の符号化方式を使用して、符号化されない表現が使用するよりも少数のビット（又は他の情報搬送単位）を使用して情報を符号化するプロセスである。任意の形態の通信と同様に、圧縮データ通信は、情報のセンダ及び受信機の両方が符号化方式を理解する場合のみ機能する。圧縮アルゴリズムによっては、この性質を利用して、認可された当事者しか（パスワード又は他の何等かの種類の登録手続きの使用を通じて等で）復号化できないように、圧縮プロセス中にデータを暗号化するものがある。圧縮は、メモリ空間又は伝送帯域幅等の、高価な資源の消費の低減を助けるため有用である。圧縮されたデータは、見る（又は聞く）ために圧縮解除しなければならない。

ビデオを符号化するには、ビデオファイルに効率的な符号化フォーマットを見つける必要がある。通常、ビデオファイルは、視覚的情報のみならず、オーディオ、テキスト、メタデータ等を含む他のコンテンツも有することができ、ビデオ及びオーディオは、メモリ要求及び送信帯域幅に関して最大の要求を課す。そのため、ビデオデータ及びオーディオデータを圧縮する場合がある。不都合なことに、これは、可逆ビデオストリームのサイズが膨大であることによって、品質を損なわずに行われることは希であり得る（通常、データの品質が復元化後であっても有用である場合には、損失にかかわらず不可逆的圧縮が使用される）。ビデオ符号化には２つの別個の目標、すなわちビデオデータの記憶及び送信がある。ビデオ符号化のために開発されて成功している略すべての技法は、ＭＰＥＧ規格に統合されている。したがって、ＭＰＥＧ規格は、ビデオ符号化の包括的な知識ベースを表す。大半のビデオ符号化規格及び商業フォーマットはＭＰＥＧを変更したものである。

動画専門家グループ、すなわちＭＰＥＧは、映像及び音声の符号化規格の開発を担うＩＳＯ／ＩＥＣのワーキンググループである。ＭＰＥＧ（エムペグと発音される）は、以下の圧縮フォーマット及び補足規格を規格化している。

ＭＰＥＧ−１：初期の映像音声の圧縮規格。後に、ビデオＣＤの規格として使用され、普及しているレイヤ３（ＭＰ３）音声圧縮フォーマットを含む。
ＭＰＥＧ−２：ブロードキャスト品質のテレビジョン用のトランスポート映像音声規格。無線デジタルテレビジョンＡＴＳＣ、ＤＶＢ、及びＩＳＤＢ、Dish Networkのようなデジタル衛星ＴＶサービス、デジタルケーブルテレビジョン信号並びに、ＤＶＤに使用される（わずかな変更あり）。

ＭＰＥＧ−３：当初はＨＤＴＶ用に設計されたが、ＭＰＥＧ−２がＨＤＴＶ用に十分であることが分かると放棄された。
ＭＰＥＧ−４：映像／音声「オブジェクト」、３Ｄコンテンツ、低ビットレート符号化をサポートし、且つデジタル著作権管理をサポートするようにＭＰＥＧ−１を拡張。いくつかの新しく（ＭＰＥＧ−２ビデオよりも新しい）より効率の高いビデオ規格、特に、アドバンストシンプルプロファイル及びアドバンストビデオコーディングが含まれる（ＭＰＥＧ−２ビデオの代替）。

ＭＰＥＧ−７：マルチメディアコンテンツを記述する形式システム。
ＭＰＥＧ２１：ＭＰＥＧはこの将来の規格をマルチメディアフレームワークとして説明している。

ＭＰＥＧ−８：スタッグ（Stug）の個人的な楽しみのためにマルチメディアコンテンツを記述する将来のシステム。
不可逆データ圧縮方法は、データを圧縮し、それから復元化することによって、恐らくオリジナルと異なるが、どうにか有用なものに「十分に近い」データが回復される圧縮方法である。不可逆データ圧縮は、インターネット、特にストリーミングメディア及び電話用途で頻繁に使用されている。こういった方法は、通常、本文脈の中ではコーデックと呼ばれる。大半の不可逆データ圧縮フォーマットは生成損失を受け、ファイルを繰り返し圧縮して復元化すると、ファイルが累進的に品質を失うことになる。

２つの基本的な不可逆圧縮方式がある。不可逆変換コーデックでは、ピクチャ又は音のサンプルがとられ、小さなセグメントに刻まれ、新しい基本空間に変換されて量子化される。次に、結果得られる量子化された値がエントロピー符号化される。不可逆予測コーデックでは、先及び／又は後の復号化データが、現在の音サンプル又は画像フレームの予測に使用される。次に、予測データと実際データとの間の誤差は、予測の再現に必要な任意のさらなる情報と共に量子化及び符号化される。いくつかのシステムでは、２つの技法が組み合わせられ、変換コーデックが使用されて、予測段階によって生成される誤差信号が圧縮される。

可逆方法と比較しての不可逆方法の利点は、場合によっては、不可逆方法が、任意の既知の可逆方法よりもはるかに小さな圧縮ファイルを、用途の要件をやはり満たしながら作成することができることである。不可逆方法は、音、画像、又は映像の圧縮に最も頻繁に使用される。不可逆映像コーデックの圧縮比（すなわち、非圧縮ファイルのサイズと比較した圧縮ファイルのサイズ）は、音声及び静止画像の等価物の圧縮比よりも略常にはるかに優れている。音声は顕著な品質の損失なく１０：１で圧縮することができ、映像はわずかな可視品質損失でかなり、例えば３００：１に圧縮することができる。不可逆圧縮静止画像は、多くの場合、音声と同様に元のサイズの１／１０に圧縮されるが、より詳しく調べてみると品質損失はより顕著である。ユーザが（例えば、ダウンロード時間を短縮するために）不可逆圧縮ファイルを得る場合、回復されたファイルはビットレベルで元ファイルとかなり異なる場合があるが、大半の実用途では人間の耳又は目で区別できない。多くの方法が、例えば、人間の目が特定の周波数の光しか見ることができないことを考慮に入れて、人体構造の特異性に焦点を合わせている。心理音響モデルは、音の知覚品質を低下させずに音の大幅な圧縮を可能にする方法を述べている。

今日、ビデオファイルの共有及び閲覧のための多くの技法及びシステムが存在する。それにもかかわらず、インターネットを介しての高品質の長いビデオファイルのリアルタイムでの送信は依然として、今日でも問題となっている。この問題は、ＰＣ等のノードの限られたアップロード及びダウンロードの送信資源によって最小の遅延及びジッタで瞬時にリアルタイムモードで見たいビデオの場合に特に強調される。したがって、ビデオネットワーク内のノードのアップロード及びダウンロードの送信資源を管理し、可能な限り最大に利用できるようにし、それによって、リアルタイムでのストリーミングメディアの表示を可能にするシステム及び方法が必要である。

以下の実施の形態及びその態様を、範囲の限定ではなく例示的且つ説明を意図するシステム、ツール、及び方法と併せて説明し図示する。各種実施の形態では、上記問題のうちの１つ又は複数が低減されるか、又はなくなり、一方、他の実施の形態は他の利点又は改良を対象とする。

一実施の形態では、送信機と１つ又は複数の受信機との間でのコンテンツ送信を調整し、１つ又は複数の受信機からのコンテンツ再送信をさらに調整するようになっている帯域幅管理モジュールを備えるリアルタイムコンテンツ送信機が提供される。送信機は、コンテンツを符号化するようになっている符号化モジュールをさらに備えることができる。送信機は、コンテンツストリームをリアルタイムで結合するようになっているコンテンツトランスポータをさらに備えることができる。

別の実施の形態では、帯域幅管理モジュールからの信号に基づいて１つ又は複数のソースからのコンテンツを受信するようになっている通信モジュールを備えるリアルタイムコンテンツ受信機が提供され、当該通信モジュールは、帯域幅管理モジュールからの信号に基づいて１つ又は複数の宛先に受信コンテンツを再送信するようにさらになっている。受信機は、コンテンツストリームをリアルタイムで結合するようになっているコンテンツトランスポータをさらに備えることができる。受信機は、受信コンテンツの１つ又は複数の肯定応答メッセージを１つ又は複数の送信機に送信するようにさらになっているものとすることができる。

帯域幅管理モジュールは、コンテンツデータレートがコンテンツに関連する最小データレート以上であるように、コンテンツの送信及び再送信を調整するようになっているものとすることができる。帯域幅管理モジュールは、動的帯域幅を計算するようになっているものとすることができる。帯域幅管理モジュールは、計算された速度で通信するように１つ又は複数のノードに命令するようになっているものとすることができる。帯域幅管理モジュールは、データ送信に１つ又は複数のノードを割り当てるようになっているものとすることができる。帯域幅管理モジュールは、２つ以上のノード間で利用可能な通信オプションに基づいて、データ送信に１つ又は複数のノードを割り当てるようになっているものとすることができる。

コンテンツはメディアコンテンツを含むことができる。メディアコンテンツはビデオコンテンツを含むことができる。帯域幅管理モジュールは別のノードに転送可能であり得る。帯域幅管理モジュールは、ディセーブルノードを識別し、データの送信又は受信に別のノードを割り当てるようになっているものとすることができる。帯域幅管理モジュールは、ファイアウォールによって課される制約がある場合、中継ノード（トランジットノード）を確立するようになっているものとすることができる。帯域幅管理モジュールは、コンテンツを中央サーバにアップロードせずに送信機と１つ又は複数の受信機との間でのコンテンツ送信を調整するようになっているものとすることができる。

参照する図及び図面に例示的な実施形態を示す。本明細書に開示される実施形態及び図は限定ではなく例示とみなされるべきものである。

本開示は、高品質データの多くのセンダ及び受信機が存在し、データが適切な順序及びタイミングで到着しなければならない、コンテンツ、特にビデオコンテンツのデータ通信ネットワークを介してのリアルタイム送信に関する。さらに、本開示は、各センダのアップロード帯域幅及び各受信機のダウンロード帯域幅に関して資源の制約があり、データファイルの特定のホストが、データファイルの受信部分を有する他のノードからの助けによってデータを送信することができる場合の帯域幅管理の技法に関する。
１．システムアーキテクチャ
この実施形態で開示するシステムアーキテクチャは、本明細書において識別され説明される以下の要素及び構成要素を含む。

ａ．チャネル：２つのノードを接続する通信回線。チャネルは、或るノードから別のノードにビデオファイルを転送又は搬送できるようにする。チャネルは任意の有無線回線であってもよい。

ｂ．データ：テキスト、イメージ、オーディオ、ビデオ、又は他の情報を任意のフォーマットで表すビットの順序付き集まりである。
ｃ．マネージャ構成要素：ビデオネットワークの管理機能を有するソフトウェア構成要素（複数可）、特徴（複数可）、又は機能（複数可）。これらは、仮想ビデオライブラリ（複数可）と１つ又は複数のネットワーク内のビデオトランスポータ間の搬送又は送信とを管理する。マネージャ構成要素は、帯域幅管理を実行し、どの装置又は機能がデータをどの速度で他に送信するかを判断する。

ｄ．マネージャ：マネージャ構成要素を含むノード。マネージャ及びマネージャ構成要素なる用語は、本開示において同義で使用することができる。
ｅ．ノード：ＰＣ、サーバ、携帯電話、ハンドヘルド装置、又は他のコンピュータもしくは通信ユニットであってもよい。ノードは、マネージャ構成要素若しくはビデオトランスポータ、又はこれらの両方を含むことができる。ノードは、ビデオエンコーダ及びビデオプレーヤ等の任意の業界標準構成要素を含んでもよい。

ｆ．プロジェクタ：ビデオをホストすると共に他のノードへビデオを送信するノード。
ｇ．受信機：データを受信するノード。
ｈ．センダ：データを送信するノード。

ｉ．送信機：センダと同じであり、この用語はセンダと同義で使用することができる。
ｊ．ビデオネットワーク：データが送信されているノード及びチャネルの集まり。ビデオネットワークは、１つのビデオファイルを管理し、その搬送を処理する。

ｋ．ビデオトランスポータ（ＶＴ）：ノードに存在し、データの送信及び／又は受信を担当するソフトウェア構成要素。ビデオトランスポータは、プロジェクト及び表示にも使用される。ビデオトランスポータは多くのビデオネットワークに参加することができる。

ｌ．仮想ビデオライブラリ：ビデオネットワーク内の各種ビデオトランスポータでホストされるすべてのビデオファイルのリスト、データベース、又はインデックス。マネージャがこのライブラリをホストし管理することができる。

ｍ．ビューア：ビデオのビューアとして動作するビデオトランスポータ。
図１を参照すると、図１は、ビデオのリアルタイムコンテンツ送信のためのビデオネットワーク（１００）の例示的なシステムアーキテクチャの図であり、このビデオネットワークはマネージャ（１０１）及び４つのノード（１０２）を含むが、他の実施形態では、ビデオネットワークは１つのマネージャ（１０１）及び１つのみのノード（１０２）、又は１つのマネージャ（１０１）及び任意の複数のノード（１０２）から成ってもよい。

ビデオネットワーク（１００）はノード（１０２）で構成される。ノード（１０２）はマネージャ（１０１）であってもよく、この場合、マネージャ構成要素を含み、又はノード（１０２）は単純なノード（１０２）であってもよく、この場合、ビデオトランスポータを含む。各ビデオネットワーク（１００）は、特定のビデオファイルに向けて特に構築され、１つのみのマネージャ（１０１）によって管理されるが、ノード（１０２）は、それ自体のマネージャ（１０１）をそれぞれ有するいくつかのビデオネットワーク（１００）に参加することが可能である。マネージャ（１０１）はいくつかのビデオネットワーク（１００）を管理することができる。

マネージャ（１０１）は、ビデオネットワーク（１００）の管理、どのノード（１０２）がセンダとして動作するか、データ（１０５）をどこに送信するか、及びデータ（１０５）を送信すべき速度を判断する責任を負う。マネージャ（１０１）は、本質的に、各ノード（１０２）でのビデオトランスポータの状態を制御し、各センダが、受信機のアドレスを含む、送信すべきデータ（１０５）についての初期情報を知るようにコマンド（１０３）をノードに送信し、また入力チャネルに関連する情報を受信機に送信する。

ビデオネットワーク（１００）内の各ノード（１０２）は、どのデータ（１０５）を別のノード（１０２）に送信するか、どのように送信するかを判断する責任を負うと共に、他のノード（１０２）からデータ（１０５）を要求する責任も負う。各ノード（１０２）は、他のビデオネットワーク内の他のノードからデータ（１０５）を送受信することもできる。各ノード（１０２）は、データ（１０５）を他のビデオトランスポータへ／から送受信する責任を負うビデオトランスポータを含む。

ノード（１０２）は多くのファイルのホストであることができる。特定のファイル又はいくつかのファイルを要求している受信機は、要求（１０４）をマネージャ（１０１）に送信し、マネージャ（１０１）は、データ送信に利用可能なノードを識別し、この情報を受信機に通信する責任を負う。次に、受信機及びセンダは互いに直接通信する責任を負う。

ノード機能の柔軟性はシステム性能の向上を提供する。オリジナルホストとして動作するノード（１０２）は、必要があれば、ホストとして動作するように容易に配置される１つ又は複数のノード（１０２）で置換することができる。例えば、ファイアウォールが両ノードで使用される場合に発生し得るように、２つのノード（１０２）間にチャネルを構築することができない場合、第３のノード（１０２）又はより多くのノード（１０２）が、中間ビデオトランスポータとして機能することができる。同じビデオネットワーク（１００）内の２つ以上のノード（１０２）が、リアルタイムで見られるように同じビデオファイルを同時に送信することによってホストとして動作することができる。

ノード（１０２）間及びノード（１０２）とマネージャ（１０１）との間のビデオネットワーク（１００）内の接続手段は、インターネット接続のための標準インターネットプロトコル、例えば、ＴＣＰ／ＩＰ、ＵＤＰ、ＨＴＴＰ、ＨＴＴＰＳ等に基づく。マネージャ（１０１）及びビデオトランスポータが同じノード（１０２）上にある場合、ローカル接続で十分であり得る。ビデオネットワーク（１００）がローカルネットワーク上にある場合、ローカルネットワークプロトコルで十分であり得る。

図２を参照すると、図２は、本実施形態のオブジェクトモデルと、ビデオネットワークを管理すると共にビデオファイルを搬送するシステム内のオブジェクト要素の相互関係とを示す例示的な概略図である。この例は、説明のみを目的とし、システム内で相関する場合のある、桁違いであり得るオブジェクト要素数の限定を意図するものではない。

ビデオ（２０１）は、１つのみのビデオネットワーク、例えばビデオネットワーク（２０２）のみに参加することができる。ビデオネットワーク（２０２）は、１つのみのビデオ（２０１）のためのものである。マネージャ（２１５）は１つのビデオネットワーク、例えばビデオネットワーク（２０２）を管理するが、例えば図２に表すように、ビデオネットワーク（２０３）及び（２０４）のうちの一方又は両方を含めることによって、複数のビデオネットワークを同時に管理することができる。ビデオネットワーク、例えばビデオネットワーク（２０２）は、１つのみのマネージャ（２１５）によって管理される。ビデオネットワーク、例えばビデオネットワーク（２０２）は、例えば図２に表すように、１つ、２つ、又は３つのビデオトランスポータ（２０６）、（２０８）、及び（２１０）を含むことによって、１つ又は複数のビデオトランスポータを含む。ビデオトランスポータ、例えばビデオトランスポータ（２０６）は、１つのビデオネットワーク、例えばビデオネットワーク（２０６）に属することができるが、例えば図２に表すように、ビデオトランスポータ（２０８）及び（２１０）を含めることによって、複数のビデオネットワークに属することもできる。

図３Ａを参照すると、ビデオのリアルタイムコンテンツ送信のための例示的なビデオネットワーク（３００）の例示的な構造構成が示され、また図３Ｂを参照すると、例示的なビデオネットワーク（３００）によって説明される例示的な搬送システム（３５０）の同様のトポロジー構成が示される。ここで説明する例は限定を意図せず、他の実施形態は、１つ又は複数のノード及び／又はビデオトランスポータ、例えば、１〜５、５〜２５、２５〜１００、１００〜１０００、１０００〜１００００、１００００〜１０００００、１０００００〜５０００００、５０００００〜１００００００、１００００００〜５００００００を含むビデオネットワーク及び／又は搬送システムを含み得る。

例示的な構造構成は、４つのノード（３０２）、マネージャ（３０１）、コマンドチャネル（３０３）、要求チャネル（３０４）、及びデータチャネル（３０５）を含むビデオネットワーク（３００）を参照し、これらはすべて図１において（１００）、（１０２）、（１０１）、（１０３）、（１０４）、及び（１０５）で示すものと同様である。同様の例示的なトポロジー構成は、４つのビデオトランスポータ（３１６）、マネージャ構成要素（３１０）、マネージャ構成要素とビデオネットワーク（３１６）との間のコマンド／要求トランスポート層（３１４）、及びビデオトランスポータ（３１６）によって共有されるネットワーク内ファイルトランスポート層（３１８）で構成される搬送システム（３５０）を参照する。

マネージャ構成要素（３１０）は、ビデオネットワーク（３００）内の１つのノード（３０２）のみを専有することができるマネージャ（３０１）に含まれる。この例では４つあるビデオトランスポータ（３１６）は、ビデオネットワーク（３００）内の４つのノード（３０２）に含まれる。各ビデオネットワーク（３１２）は特定のビデオファイル（３２０）に向けて特に構築され、１つのみのマネージャ構成要素（３１０）によって管理される。

図４を参照すると、図４は、ビデオ管理・搬送システム内の各種類の要素間の管理及び機能に関する相互関係の組み合わせ例を示すいくつかのトポロジーマップを含む。ビデオ管理・搬送システム（以下、システムと呼ぶ）は、マネージャ構成要素、ビデオトランスポータ（複数可）、ビデオネットワーク（複数可）、以下、チャネルと同義で使用することができるトランスポート層（複数可）、及びビデオファイル（複数可）を含む。本明細書で説明する例は限定を意図せず、可能な管理と機能との相互関係の多くの組み合わせ及び１つ又は複数のシステム内で管理できる要素数のほんの小さな一例にすぎない。さらに、示される例で使用される上記要素は、すべての例で同様であってもよく、さらには同じであってもよく、１つ又は複数の搬送システムで可能な多くの相互関係の組み合わせで使用できる要素と同様又は同じであってもよい。

システム（４５０）は、マネージャ（４０４）が１つのビデオネットワーク、例えばビデオネットワーク（４０１）を管理し、１つのビデオファイル、例えばビデオファイル（４０３）がビデオネットワーク毎に搬送され、複数のビデオトランスポータ、例えば、ビデオトランスポータ（４０２）等の３つのビデオトランスポータが１つのビデオネットワーク内で参加している例示的なシステムである。チャネル（４０５）は、ビデオトランスポータ（４０２）等の複数のビデオトランスポータ間でデータ及び制御信号を搬送するチャネルの一例である。

システム（４６０）は、マネージャ（４０６）が複数のビデオネットワーク、例えば、ビデオネットワーク（４１２）、ビデオネットワーク（４０８）、及びビデオネットワーク（４０９）等の３つのビデオネットワークを管理し、複数のビデオトランスポータが複数のビデオネットワークに参加しており、例えば、２つのビデオトランスポータ（４１０）がビデオネットワーク（４０８）及びビデオネットワーク（４１２）の両ビデオネットワークに参加している例示的なシステムである。

システム（４７０）は例示的なシステム（４５０）及びシステム（４６０）の変形であり、マネージャ（４０７）が複数のビデオネットワーク、例えば、ビデオネットワーク（４１３）及びビデオネットワーク（４１４）等の２つのビデオネットワークを管理し、複数のビデオトランスポータが複数のビデオネットワークに参加しており、例えば、１つのビデオトランスポータ（４１１）がビデオネットワーク（４０９）及びビデオネットワーク（４１３）という２つのビデオネットワークに参加する。この変形では、複数のビデオネットワークに参加している複数のビデオトランスポータはそれぞれ、各ビデオネットワークの個々のマネージャによって管理され、例えば、ビデオトランスポータ（４１１）はマネージャ（４０６）及びマネージャ（４０７）という２つのマネージャによって管理される。

図５を参照すると、搬送システムのいくつかのトポロジーマップを、マネージャ構成要素（複数可）、ビデオトランスポータ（複数可）、ビデオネットワーク（複数可）、及びトランスポート層（複数可）を含むこのような搬送システム（複数可）に参加している各種要素間で可能な相互接続の例と共に示す。ここで説明する例は限定を意図せず、可能な多くの相互接続の組み合わせ、及び１つ又は複数の搬送システム内で相互接続できる要素数のほんの小さな一例にすぎない。さらに、示される例で使用される上記要素は、すべての例で同様であってもよく、さらには同じであってもよく、１つ又は複数の搬送システムで可能な多くの相互接続の組み合わせで使用できる要素と同様又は同じであってもよい。

搬送システム（５００）は、１つのマネージャ構成要素（５０２）によって管理される１つのビデオネットワーク（５１０）の一例である。コマンドデータが、マネージャ構成要素（５０２）からビデオネットワーク（５１０）内のビデオトランスポータ（５０３、５０４、５０５）に、すべてが同様の又は同じトランスポート層であってもよいトランスポート層（５０６、５０７）と同様又は同じであってもよいトランスポート層（５０１）を通じて送信され、要求がトランスポート層（５０１）を通じてビデオトランスポータ（５０３、５０４、５０５）から受信される。ビデオ（５０８）は、ビデオトランスポータ（５０３、５０４、５０５）のうちの任意の１つ、例えばビデオトランスポータ（５０３）によってプロジェクトすることができ、トランスポート層（５０６）を通じてビデオトランスポータ（５０４）に送信され、ビデオトランスポータ（５０５）はトランスポート層（５０７）を通じてビデオ（５０８）をビデオトランスポータ（５０４）に再送信する。

搬送システム（５３０）は、１つのマネージャ構成要素（５３１）によって管理される３つのビデオネットワーク（５３６、５３７、５６５）の一例であり、いくつかのビデオトランスポータ、例えば２つのビデオトランスポータ（５３９、５４０）が２つ以上のビデオネットワーク、例えば２つのビデオネットワーク（５３６、５３７）に参加する。ビデオネットワーク（５３６）では、コマンドデータが、マネージャ構成要素（５３１）からビデオトランスポータ（５３８、５３９、５４０）に、すべてが同様の又は同じトランスポート層であってもよいトランスポート層（５４５、５４６）と同様又は同じであってもよいトランスポート層（５３２）を通じて送信され、要求がトランスポート層（５３２）を通じてビデオトランスポータ（５３８、５３９、５４０）から受信される。ビデオ（５４９）は、ビデオトランスポータ（５３８、５３９、５４０）のうちの任意の１つ、例えばビデオトランスポータ（５３８）によってプロジェクトすることができ、トランスポート層（５４５）を通じてビデオトランスポータ（５３９）に送信され、ビデオトランスポータ（５３９）はトランスポート層（５４６）を通じてビデオ（５４９）をビデオトランスポータ（５４０）に再送信する。

ビデオネットワーク（５３７）では、コマンドデータが、マネージャ構成要素（５３１）からビデオトランスポータ（５３９、５４０、５４１、５４２）に、すべてが同様の又は同じトランスポート層であってもよいトランスポート層（５４３、５４４、５４６）と同様又は同じであってもよいトランスポート層（５３３）を通じて送信され、要求がトランスポート層（５３３）を通じてビデオトランスポータ（５３９、５４０、５４１、５４２）から受信される。ビデオ（５４８）は、ビデオトランスポータ（５３９、５４０、５４１、５４２）のうちの任意の１つ、例えばビデオトランスポータ（５３９）によってプロジェクトすることができ、トランスポート層（５４６）を通じてビデオトランスポータ（５４０）に送信され、ビデオトランスポータ（５４０）はトランスポート層（５４４）を通じてビデオ（５４８）をビデオトランスポータ（５４１）に再送信し、ビデオトランスポータ（５４１）はトランスポート層（５４３）を通じてビデオ（５４８）をビデオトランスポータ（５４２）に再送信する。

ビデオネットワーク（５６５）では、コマンドデータが、マネージャ構成要素（５３１）からビデオトランスポータ（５５４、５５５）に、すべてが同様の又は同じトランスポート層であってもよいトランスポート層（５５６）と同様又は同じであってもよいトランスポート層（５８０）を通じて送信され、要求がトランスポート層（５８０）を通じてビデオトランスポータ（５５４、５５５）から受信される。ビデオ（５６５）は、ビデオトランスポータ（５５４、５５５）のうちの任意の１つ、例えばビデオトランスポータ（５５４）によってプロジェクトすることができ、トランスポート層（５５６）を通じてビデオトランスポータ（５５５）に送信される。

２つのビデオネットワーク、すなわちビデオネットワーク（５３６）及びビデオネットワーク（５３７）が、両方のビデオネットワークで使用されるすべてのビデオトランスポータと本質的に同様又は同じであるビデオトランスポータ（５３９）及びビデオトランスポータ（５４０）を共有し、両方のビデオネットワークで使用される他のすべてのトランスポート層と本質的に同様又は同じである共通トランスポート層（５４６）を共有するが、ビデオ（５４９）は、ビデオネットワーク（５３６）に関連するビデオトランスポータのみによってプロジェクト、搬送及び表示されるのに対して、ビデオプロジェクタ（５４８））は、ビデオネットワーク（５３７）に関連するビデオトランスポータのみによってプロジェクト、搬送及び表示される。

搬送システム（５５０）は、２つのビデオネットワーク（５６０、５７１）が１つのマネージャ構成要素（５５１）によって管理され、いくつかのビデオトランスポータ、例えば１つのビデオトランスポータ（５５５）が２つ以上のビデオネットワーク、例えば、２つのビデオネットワーク（５６０、５６５）に参加し、第３のビデオネットワーク（５７１）が他の２つのビデオネットワーク（５６０、５６５）から完全に独立している例である。ビデオネットワーク（５６０）では、コマンドデータが、マネージャ構成要素（５５１）からビデオトランスポータ（５５５、５５７、５５９）に、すべてが同様の又は同じトランスポート層であってもよいトランスポート層（５５８、５８１）と同様又は同じであってもよいトランスポート層（５５３）を通じて送信され、要求がトランスポート層（５５３）を通じてビデオトランスポータ（５５５、５５７、５５９）から受信される。ビデオ（５６２）は、ビデオトランスポータ（５５５、５５７、５５９）のうちの任意の１つ、例えばビデオトランスポータ（５５７）によってプロジェクトすることができ、トランスポート層（５８１）を通じてビデオトランスポータ（５５５）に送信されると共に、トランスポート層（５５８）を通じてビデオトランスポータ（５５９）にも送信される。

ビデオネットワーク（２６０）から完全に独立しているビデオネットワーク（５７１）では、コマンドデータが、マネージャ構成要素（５５１）からビデオトランスポータ（５６６、５６８、５７０、５７５）に、すべてが同様の又は同じトランスポート層であってもよいトランスポート層（５６７、５６９、５７４）と同様又は同じであってもよいトランスポート層（５５２）を通じて送信され、要求がトランスポート層（５５２）を通じてビデオトランスポータ（５６６、５６８、５７０、５７５）から受信される。ビデオ（５７３）は、ビデオトランスポータ（５６６、５６８、５７０、５７５）のうちの任意の１つ、例えばビデオトランスポータ（５６８）によってプロジェクトすることができ、トランスポート層（５６７）を通じてビデオトランスポータ（５６６）に送信されると共に、トランスポート層（５６９）を通じてビデオトランスポータ（５７０）にも送信され、ビデオトランスポータ（５７０）はトランスポート層（５７４）を通じてビデオ（５７３）をビデオトランスポータ（５７５）に再送信する。

ビデオネットワーク（５６５）及びビデオネットワーク（５６０）の両方に含まれるビデオトランスポータ（５５５）は、マネージャ構成要素（５３１）及びマネージャ構成要素（５５１）の両方によって管理することができる。
２．ビデオネットワークの構築
システムは、ビデオトランスポータがネットワークのマネージャを容易に見つけることができるビデオネットワークの構築を必要とする。中央データベース又は複数のノードにわたって分散してもよい他の何等かの形態のデータ記憶手段が使用され、マネージャ及びノードの識別詳細が登録される。

図６を参照すると、図６は、ビデオネットワークを構築する例示的なプロセスを示すフローチャートである。マネージャ構成要素はまず、ログインプロセスによってデータベースに登録し（ログインプロセスは他の何等かの形態の登録プロセスであってもよい）、アドレス及びポート等のマネージャの接続詳細を含む情報をデータベースに入力する（ステップ６０１）。ビデオネットワークに入りたいビデオトランスポータは、データベースに接続して、マネージャの接続詳細を得る（ステップ６０２）。マネージャの接続詳細を使用して、ノードはマネージャに接続し、ビデオトランスポータはマネージャ構成要素にログインする。ログイン中、ビデオトランスポータは、ビデオネットワークについての必要情報が記憶されているマネージャの記憶領域であるメモリ領域に記憶されており、また、センダ、受信機、チャネルビットレート等についてのＩＰアドレス、ポート、及びビデオトランスポータ間のチャネルについての情報等のビデオトランスポータの接続パラメータを含み得るノードの接続詳細をマネージャ構成要素に提供する（ステップ６０３）。ノード（又はビデオトランスポータ、以下これらを同義で使用する）はここで、ビデオネットワークに接続される（ステップ６０４）。

ビデオネットワークに入るビデオトランスポータは、プロジェクタ（１つ又は複数のビデオファイルをホストする）及び／又はビューアとして機能することができ、ビューアの場合、ビデオトランスポータはビデオネットワークを通じてブロードキャストされているビデオファイルの閲覧を望む。この段階において、ビデオトランスポータは、次にどれをマネージャ構成要素に通信しなければならないかを判断しなければならない（ステップ６０５）。プロジェクタとして動作したいビデオトランスポータは、ノードの名称、アドレス、ポートを組み込んでいる情報並びにプロジェクタコンピュータ上のビデオファイルへのパス（以下、リンクと呼ぶ）、ファイルサイズ、及び他のメタデータを含むプロジェクトすべきビデオに関する情報を含むが、これらに限定されない要求をマネージャ構成要素に送信する（ステップ６０６）。マネージャ構成要素は、各ビデオネットワークで管理される各ビデオファイルへのリンクが記憶され、プロジェクタへのリンク並びにビデオファイルが、永久的であれ一時的であれ記憶されている他のノードへのリンクを含む仮想ビデオライブラリを管理する（ステップ６０７）。仮想ビデオライブラリは、マネージャ構成要素の一部であっても、マネージャ構成要素から独立してもよく、１つのノードに中央化されてもよく、又は複数のノードに分散してもよい。

ビューアとして動作したいビデオトランスポータは、仮想ビデオライブラリで利用可能なビデオファイルのリストに対する要求をマネージャ構成要素に送信する。ビューアはまた、ビデオファイルのリストを経由する必要なく特定のビデオファイルを要求してもよい（ステップ６０８）。次いで、マネージャ構成要素は、プロジェクタの場合にあり得るように永久的にであれ、他のビューアの場合であり得るように一時的にであれ、ビデオファイル又はその一部を記憶している他のビデオトランスポータであるセンダに、ファイル又はその一部を要求しているビューアに搬送するように命令する（ステップ６０９）。マネージャ構成要素から許可を受け取ったビューアは、将来にプロジェクタとして機能できるようにビデオファイルを永久的に記憶することができる。センダがビデオファイル又はその一部の送信を保留又は停止した状況では、マネージャ構成要素は代替のビデオトランスポータにセンダとして動作するように命令することができる。
３．帯域幅管理及び基本搬送
ビデオファイルの送信に先立ち、いずれかが使用制限対策を組み込み得るプロプラエタリアルゴリズム又は市販の圧縮アルゴリズム等の圧縮アルゴリズムを使用して、データを圧縮することができる。符号化方式は適応型であり、ビデオネットワーク内のチャネルの制約及びパラメータに基づき、符号化方式はユーザの好みに基づいてカスタムであってもよい。

独立且つ／又は一緒に動作するマネージャ及びマネージャ構成要素は、本実施形態によって説明されるシステム及び本開示で説明されないすべての可能な代替の実施形態において帯域幅アドミニストレータと呼ばれることもある帯域幅管理モジュールとして動作する。帯域幅管理モジュールは、本開示全体を通じてマネージャ及び／又はマネージャ構成要素と同義に使用することができ、各ノードの帯域幅利用を最大化する責任を負う。ビデオトランスポータは、ユーザ（ノードでの）がビデオファイルを連続して一見即座に見られるように、ビデオファイルのリアルタイムでのセグメント化、続く再結合及び併合の責任を負う。

図７を参照すると、ビデオネットワークの状態に依存する例示的な２つの搬送方法が示される。図示する例示的な各方法では、３つのビデオトランスポータが使用されるが、方法は複数のビデオトランスポータ、例えば２〜５、５〜５０、５０〜１０００、１０００〜１００００、１００００〜１０００００、１０００００〜５０００００、５０００００〜１００００００、１００００００〜５００００００を使用してもよい。ビデオファイルは複数の間隔、例えば、２０〜２００間隔に分けられるが、ファイルは２０〜５０、５０〜８０、８０〜１１０、１１０〜１４０、１４０〜１７０、１７０〜２００の範囲の間隔に分けてもよい（ステップ７０１）。次に、各間隔は複数のセグメント、例えば、２０〜２００セグメントに分けられるが、間隔は２０〜５０、５０〜８０、８０〜１１０、１１０〜１４０、１４０〜１７０、１７０〜２００の範囲のセグメントに分けてもよい（ステップ７０２）。各間隔は一度に１つずつ、間隔がビデオファイルから導出された順序で受信機によって処理される。

セグメントは、データ送信を可能な限り安全に保つために暗号化プロセスを経た後にビデオトランスポータ（センダ）間で送信される。ビデオトランスポータは、チャネル容量に依存する割り振りプロセスに基づいて送信すべきセグメントを割り振る責任を負う。例えば、ビデオトランスポータＡ、Ｂ、及びＣは、セグメント１〜３及び４〜６を順次にそれぞれ送信し、受信機によって同じ順序で受信される（ステップ７０３）。

どのデータを送信しなければならないかを判断するために、システムは２つのカーソル、すなわち受信データカーソル及びビデオカーソルを保持する。次いで、受信機は、処理におけるギャップを制限するために、受信データカーソルが常にビデオカーソルの前にあることを保証する。ビデオカーソルが受信データカーソルに近づくにつれ、受信機はセンダからの特定のタイプのセグメントの要求に対する緊急度を増大させることができる。

センダは、受信機からの要求があるとセグメントを送信する。セグメントが受信される場合、肯定応答がセンダに返信されて、受信が確認される。１つの間隔のすべてのセグメントが受信されると、受信機は新しい間隔の新しいセグメントの送信を要求する。データは、受信されると、処理前に許可に基づいて復号化される。これによって、ビデオファイルの保護及び適切な配信が保証される。

ビデオネットワーク内の各ノードは、アップロード帯域幅及びダウンロード帯域幅を有する。アップロード帯域幅は、特定のノードのすべての送信チャネルの最大可能速度である。ダウンロード帯域幅は、特定のノードのすべての受信チャネルの最大可能速度である。マネージャは、帯域幅管理の機能を実行しながら、システム全体の帯域幅利用を最大化する責任を負う。このプロセスでは、マネージャは、センダ及び受信機の両方としてチャネルビットレート、予約帯域幅容量、及びフリー帯域幅容量を含む各ノードのチャネル容量を考慮する。いくつかの実施形態では、システムはまず、優先度をフリー帯域幅に与えてから予約帯域幅を使用し、他の実施形態では、優先度がまず予約帯域幅の使用に与えられてから、フリー帯域幅が使用される。

チャネルビットレートは、ビデオファイルのデータビットレートの関数である。送信のタイミングは、データの適宜処理にとって非常に重要である。送信されるセグメントのタイミングは、２つの主な要因、すなわちチャネルの速度及びその特定のセグメントに対する特定の要件によって影響される。特定のセグメントに対して特定の要件がある場合、そのセグメントには最高の優先度が与えられて即座に送信される。しかし、通常の動作の過程では、ビデオトランスポータ「ａ」（センダ）がデータをビデオトランスポータ「ｂ」（受信機）に送信する必要があるときに、システムは最良のチャネルビットレートを計算する。

例えば、２つのビデオトランスポータ、すなわちセンダ及び受信機しかない状況を考える。センダが最大アップロード帯域幅Ｕ_ａを有すると仮定する。また、受信機が最大ダウンロード帯域幅Ｄ_ｂを有すると仮定する。送信する必要があるデータはビットレートｂを有する。チャネルのビットレートはｖであり、以下のように計算することができる。

データは複数のビットレートｂ_ｎで表すこともできる。この場合、システムは、上記式に適合するデータビットレートを選択することができる。これらの条件を満たすｂが存在しない場合、ビデオトランスポータ「ａ」からビデオトランスポータ「ｂ」への送信を行うことはできない。

チャネルの速度は静的ではなく、送信中に変化し得る。こういった変動は、ビデオネットワークの状態、ネットワークに追加されている、若しくは除去されているか、若しくは帯域幅を他の目的に割り振っている受信機及び／若しくはセンダの変化、又はチャネルに伴う問題があるか否かによって影響される。速度は増減し得るが、常に上記規則の限度内に留まる。

チャネルの予約帯域幅容量は、ビデオファイルのサイズ並びにビデオカーソル及び受信データカーソルの相対位置に対するファイルのデータビットレートの関数である。チャネルのビットレートは可変であり、ビデオネットワーク内の資源を最大化するように調整される。データストリームが送信時に固定端（サイズｓを有するファイル）を有する場合、最低速度Ｖ_ｍｉｎ：

が必要である。式中、ｂはデータビットレートであり、ｓはファイルサイズであり、ｒは受信データカーソルの現在位置であり、ｐはビデオカーソルの現在位置である。
これらの場合、

であり、チャネルでｖ＞Ｖ_ｍｉｎの場合、アップロード資源の予約Ｒはセンダによる使用に利用でき、以下のように計算することができる。

この予約は、要求に応じてデータを他のビデオトランスポータに送信するために使用することができる。旧チャネルのビットレートは、予約帯域幅を使用することによって低減する。

フリー帯域幅容量は、チャネルで使用されていない帯域幅の関数である。フリー帯域幅は使用されていない帯域幅であるため、センダによる使用に利用できる。これは、以下のように計算することができる。

式中、ｖ_ｃは、センダａが送信しているあらゆるチャネルのチャネルビットレートであり、Ｕ_ａはセンダａのアップロード帯域幅である。
図８を参照すると、例示的なビデオネットワークの帯域幅管理及び利用の例示的なプロセスが示される。図示のビデオネットワーク（８００）は、５つのノード、すなわちノードＡ（８０１）、ノードＢ（８０２）、ノードＣ（８０３）、ノードＤ（８０４）、及びノードＥ（８０５）を含むが、説明するプロセスは、多くのノード、例えば、２〜５、５〜５０、５０〜１０００、１０００〜１００００、１００００〜１０００００、１０００００〜５０００００、５０００００〜１００００００、１００００００〜５００００００を含む他のビデオネットワークに適用することも可能である。

ノードＡ（８０１）はプロジェクタであり、チャネル帯域幅容量３００ｋｂ／ｓを必要とするビデオファイルをホストし、チャネルアップロード帯域幅３８０ｋｂ／ｓを有する。ノードＢ（８０２）、ノードＣ（８０３）、ノードＤ（８０４）、及びノードＥ（８０５）はすべてビューア（受信機）であり、送信ビデオファイルの処理に適するダウンロード帯域幅（最小３００ｋｂ／ｓ）を有すると仮定される。ノードＢ（８０２）は、ノードＡ（８０１）のアップロード帯域幅３８０ｋｂ／ｓのうちの３００ｋｂ／ｓを占めるビデオファイルをノードＡ（８０１）から受信し、ノードＡ（８０１）の残りのフリーアップロード帯域幅は８０ｋｂ／ｓのみになる。ノードＣ（８０３）はノードＡ（８０１）から完全なビデオファイルを受信することができないため、ノードＡ（８０１）の残りのフリーアップロード帯域幅である５０ｋｂ／ｓを占める部分のみを受信する。ノードＢ（８０２）はアップロード帯域幅５２０ｋｂ／ｓを有するため、帯域幅のうちの２５０ｋｂ／ｓを占めるビデオファイルの残りの部分をノードＣ（８０３）に提供することができ、ノードＣ（８０３）はここで、ノードＡ（８０１）からの部分とノードＢ（８０２）からの部分とを結合することによって完全なビデオファイルを受信する。ノードＢ（８０２）には、ビデオファイルの部分をビデオネットワーク（８００）内の他のノードに送信するために２７０ｋｂ／ｓのフリーアップロード帯域幅が残っている。ノードＤ（８０４）は、フリーアップロード帯域幅３０ｋｂ／ｓを有するノードＡ（８０１）からビデオファイルの部分を受信し、ノードＤ（８０４）への送信にアップロード帯域幅２００ｋｂ／ｓを提供するノードＢ（８０２）からビデオファイルの他の部分を受信し、ビデオファイルの別の部分を、利用可能な３００ｋｂ／ｓからのアップロード帯域幅のうちの７０ｋｂ／ｓを提供するノードＣ（８０３）から受信する。ノードＤ（８０４）はここで、受信した各種部分を結合してビデオファイル全体を完成することができる。ノードＤ（８０４）は、ビデオファイル（又はその部分）をノードＥ（８０５）に送信するために利用できるフリーアップロード帯域幅をまったく有しない。したがって、ノードＢ（８０２）は、まだ７０ｋｂ／ｓのフリーアップロード帯域幅が利用可能であるため、ビデオファイルの部分を送信し、一方ノードＣ（８０３）は、まだ２３０ｋｂ／ｓのフリーアップロード帯域幅を有しているため、ビデオファイルの完成に必要な他の部分を送信する。

図９を参照すると、２つのストリームがリアルタイムで１つのストリームに併合される例示的なビデオネットワークが示される。ここで説明する例は限定を意図せず、１つのストリームに併合できる多くのストリームの組み合わせ、及び１つ又は複数のビデオシステム内で相互接続できるノード数又は要素数のほんの小さな一例にすぎない。

ビデオファイル（９０１）は、適切な送信にチャネル帯域幅容量５００ｋｂ／ｓを必要とする。プロジェクタ（９０２）であるノード１はアップロード帯域幅容量８００ｋｂ／ｓを有する。ビューア（９０４）であるノード２はダウンロード帯域幅容量１０００ｋｂ／ｓ及びアップロード帯域幅容量３００ｋｂ／ｓを有する。ビューア（９０３）であるノード３はダウンロード帯域幅容量１０００ｋｂ／ｓを有する。

ビデオファイル（９０１）はプロジェクタ（９０２）であるノード１のアップロード帯域幅容量８００ｋｂ／ｓのうちの５００ｋｂ／ｓを占めるため、ビューア（９０４）であるノード２の１０００ｋｂ／ｓ帯域幅容量の範囲内にありながら、プロジェクタ（９０２）であるノード１は、チャネル１（９０６）を通じて完全なビデオファイル（９０１）をビューア（９０４）であるノード２にストリーミングする。これは、プロジェクタであるノード１に、ビデオファイル（９０１）又はそのセグメントをビデオネットワーク（９００）内の他のビューアに送信するために使用する３００ｋｂ／ｓのフリーアップロード帯域幅を残す。ビューア（６０３）であるノード３はビデオファイル（９０１）を受信したいが、チャネル２（９０７）のアップロード帯域幅が、５００ｋｂ／ｓであるビデオファイル（９０１）の帯域幅要件未満の３００ｋｂ／ｓであるため、ビューア（９０４）であるノード２から完全なファイルを受信することができない。次いで、ビューア（９０４）であるノード２は、利用可能な３００ｋｂ／ｓアップロード帯域幅容量のうちの２００ｋｂ／ｓを利用してビデオファイル（９０１）のセグメントをストリーミングする。ビデオファイル（９０１）を完成するために、プロジェクタ（９０２）であるノード１は、３００ｋｂ／ｓの残りのフリー帯域幅容量を利用することによって、チャネル３（９０５）を通じてビデオファイル（９０１）の追加の部分をストリーミングする。ビューアであるノード３のダウンロード帯域幅容量は１０００ｋｂ／ｓであるため、セグメントを受信し、２つのストリームを結合して併合し、５００ｋｂ／ｓ帯域幅を占める完全なビデオファイル（９０１）を表示することに問題はない。

複数のセンダがデータを受信機に送信することが可能であり得る他の実施形態では、システムは、１組の規則を使用して、どれがデータを送信するかを判断することができる。図１０を参照すると、意思決定プロセスの流れ図が示される。システムはまず、ビデオトランスポータのファイアウォールを介して開いているポートの可用性を調べることによって、送信を実際に２つのビデオトランスポータ間で行うことができるか否かを判断することができる（ステップ１００１）。通信が可能な場合、優先度が、受信機に地理的に近いセンダに与えられ（ステップ１００２）、それからデータのオリジナル所有者としてリストされていないセンダに与えられ（ステップ１００３）、それからフリー帯域幅を有するセンダに与えられ（ステップ１００４）、最後に予約帯域幅を有するセンダに与えられる（ステップ１００５）。システムがこの優先付けプロセス後に複数のセンダを有する場合、それらセンダのうちの１つ又は複数をランダムに選択することができる（ステップ１００６）。以下は一例である。

ビデオネットワークには、いくつかのビデオトランスポータＮ_１，Ｎ_２，・・・，Ｎ_ｎがある。クラス「ａ」のビデオトランスポータは、入ポートが開いているものである。クラス「ｂ」のビデオトランスポータは、入ポートが閉じているものである。クラス「ｂ」のビデオトランスポータは、クラス「ａ」のビデオトランスポータからのみデータを受信することができ、クラス「ａ」のビデオトランスポータはビデオトランスポータクラス「ａ」及び「ｂ」からデータを受信することができると述べられる。クラス「ｂ」のビデオトランスポータは、データを必要とする場合、フリー帯域幅を有する「ａ」ビデオトランスポータからデータを受信し、それから予約帯域幅を有する「ａ」ビデオトランスポータからデータを受信する。クラス「ａ」のビデオトランスポータは、データを必要とする場合、まず、フリー帯域幅を有する「ｂ」ビデオトランスポータからデータを受信し、それから予約帯域幅を有する「ｂ」ビデオトランスポータからデータを受信し、それからフリー帯域幅を有する「ａ」ビデオトランスポータからデータを受信し、それから予約帯域幅を有する「ａ」ビデオトランスポータからデータを受信する。
４．アドバンスト搬送メカニズム
本開示の他の実施形態は、チャネル不安定性、歪み、干渉、及び或るセンダから時間通りに到着する他のデータに対して、受信機に遅れて到着する（又はまったく到着しない）データの原因となり得るチャネル特性に発生し得る他の変動の考えられる影響を考慮することができる。これは、ビデオ搬送受信機に到着するデータの重複（又は消失データ）に繋がる恐れがあり、これは受信ビデオトランスポータにおいてビデオに「穴」がある望ましくない状況を発生させる恐れがある。

重複を低減し、受信ビデオの「穴」をなくすために、システムは、ビデオデータの線形結合を受信機に送信することができる。次いで、受信機は受信データを分解して、受信データから元のデータを再構築する。

以下は、ビデオデータの線形結合の生成及び分解を行う方法の説明である。簡略にするために、方法をまず、２つのセンダの例として説明する。説明の残りの部分は、解を複数のセンダに向けて一般化する。

２つのセンダ及び１つの受信機あるとする。データは受信機に順序通りに適切なタイミングで到着しなければならない。センダは互いに独立しておらず、すでに送信されているデータの知識を有する。センダはデータの同様の範囲又は間隔からデータを送信するため、重複の可能性があり、システムの目標は重複を最小限に低減して、送信効率を増大させ、限られた資源の使用を最大化することである。任意の所与の瞬間に、２つのセンダが受信ビデオトランスポータのバッファ内の移動間隔を満たし得る。重複を低減するために、受信機は、センダが再送信しないように、どのセグメントをすでに受信しているかをセンダに通知（肯定応答を送信）する。送信遅延によって、肯定応答通知は時間通りに受信されないことがあり、この場合、重複が発生し得る。以下に状況を説明する。

この例の説明は以下である。
Ｓ_１が、セグメントＸ及びＹを受信機Ｒに送信する用意のできているセンダであると想定し、
Ｓ_２も、セグメントＸ及びＹを同じ受信機Ｒに送信する用意のできているセンダと想定し、
セグメントＸ及びＹは同じサイズであり、
最も効率的な送信のためには、各センダが重複せずにセグメントの１つのみを送信すべきであり、
第１の選択肢はＳ_１及びＳ_２がセグメント（Ｘ又はＹ）をランダムに選択することであり、
したがって、送信される各セグメントの確率は以下である。

ａ．２５％：Ｓ_１からセグメントＸ、Ｓ_２からセグメントＸ
ｂ．２５％：Ｓ_１からセグメントＸ、Ｓ_２からセグメントＹ
ｃ．２５％：Ｓ_１からセグメントＹ、Ｓ_２からセグメントＸ
ｄ．２５％：Ｓ_１からセグメントＹ、Ｓ_２からセグメントＹ
この選択肢では、上記の「ａ」及び「ｄ」のケースは、両方のセンダが同じセグメントを送信したため、効率的ではない。

他の選択肢は線形結合を使用することである。元のセグメントを送信することに代えて、システムはセグメントを変換したものを送信する。変換は、送信に無駄がないように同じサイズであることができる。システムは、この変換を線形結合として定義することができる。線形結合Ｚ_１及びＺ_２は以下のように定義することができる。

式中、α_１及びα_２は異なる乱数である。センダＳ_１はパッケージＺ_１を送信し、センダＳ_２はパッケージＺ_２を送信する。上記の加算演算子及び乗算演算子は任意の様式で、例えば、線形代数の従来の規則に従って定義することができる。受信端において、受信機は、それぞれＸ又はＹと同じサイズである２つのパッケージＺ_１及びＺ_２並びに２つの数α_１及びα_２を受信することができる。これらの数の長さはセグメントの長さと比較して非常に短くてもよい。方程式は以下のように解くことができる。

したがって、受信機は２つのセンダから一意のＸ及びＹを受信した。
この問題を２つ以上のセンダ及び送信しなければならない２つ以上のセグメントに向けて一般化するために、システムは線形結合の以下の一般化された定義を利用することができる。

式中、Ｚは各センダが受信機に送信し得る結果パッケージであり、Ｘ_ｉは１組の元のセグメントであり、α_ｉは１組の乱数である。
どのセグメントから線形結合を構築するかの判断は、受信される肯定応答メッセージに基づくと共に、以下のような確率にも基づく。

式中、ｎは、センダがデータを受信機に送信すべき間隔内のセグメント数であり、ｐ（ｎ）はセグメントｎを送信する確率であり、ｎ_０は間隔への最初のセグメント数であり、Γは間隔の幅であり、Ａは以下のように計算される係数である。

センダは、選択された間隔で（受信機の肯定応答に従って）、例えば、間隔がデータストリームへの最初の未受信ビデオトランスポータから開始される都度、すぐ上の式に従って、受信機が受信していないすべてのビデオトランスポータの和を計算することができる。

受信機ビデオトランスポータで連立線形方程式を解き、元のセグメントを復元するために、システムは、同値類の反映であるツリー構造を利用することができる。同値は、以下の規則、すなわちａ＝ｂの場合、ｂ＝ａであり、２）ａ＝ｂ且つｂ＝ｃの場合、ａ＝ｃを満たす２つのオブジェクト間に「＝」と表記される関係である。オブジェクト集合があり、同値関係をこれらのオブジェクト間で定義することができる場合、完全な集合を「同値類」と呼ばれるいくつかの部分集合に分けることができる。受信機によって受信される線形結合への、セグメント間のこの同値関係は、以下のように定義することができる。「ａ」が分かっているときに「ｂ」を計算することができる場合、セグメント「ａ」はセグメント「ｂ」と同値である。これは、システムにおいてツリー構造で表すことができる同値類を提供することができる。

図１１を参照すると、Ｎ＝２である（各線形結合中に２つのセグメントがある）例示的なケースのための例示的な線形結合ソルバの流れ図が示される。ここで説明する例は限定を意図せず、開示する実施形態及びさらなる実施形態において説明される方法の代表であり、また、Ｎが複数のセグメントを表し、解くべき多数の線形結合があるケースにも適用することができる。

例示的な線形結合ソルバは、要素１１０１〜１１０７並びにステップＡ、Ｂ、Ｃ、及びＤを含む。要素１１０１は、線形結合の形態で受信機に到着するデータのセグメントを表すことができる。ステップＡには、４つの線形結合、すなわちセグメント１及び２に１つ、セグメント２及び３に１つ、セグメント２及び４に１つ、並びにセグメント５及び６に１つの線形結合がある。要素１１０２は、システムが、ツリー構造の受信機に到着したセグメントを保持するメモリバッファを表すことができる。要素１１０３は、２つのセグメントを結ぶ線であり、システムにおいて、受信機がこれらの２つのセグメントの線形結合を受信したことを表すことができる。要素１１０４はセグメントとすることができ、番号はセグメントＩＤを識別する。要素１１０５は、連立線形方程式を解くプロセスであることができる。線又は方程式の数がセグメント数に等しい場合、方程式を解くことができる。要素１１０６は、受信機が受信する、解かれたセグメントであることができる。要素１１０７は、システムにおいて、送信される線形結合が１つのセグメントのみで構成することができる場合を表すことができる。

本開示のいくつかの実施形態によれば、通信システム内でデータを送信する方法は以下のステップを含むことができる。
ステップＡ：線形結合１及び２、２及び３、２及び４、並びに５及び６を得る。セグメント及びその線的表現をバッファ内のツリー構造に追加する。

ステップＢ：線形結合４及び６、７及び８、並びに８及び９を得る。セグメント及びその線的表現をバッファ内のツリー構造に追加する。
ステップＣ：線形結合３及び６並びに７及び１０を得る。ソルバプロセス及び受信機がこの時点でセグメント１〜６を有するため、システムはここで方程式を解くことができる。

ステップＤ：線形結合１１及び１２並びに９を得る。これらのセグメント及びその線的表現を同様にバッファ内のツリー構造に追加する。ここで、システムはセグメント７〜１０の方程式を解くことができ、受信機はここでこれらのセグメントを有する。プロセスは、すべてのセンダからすべてのセグメントａを受信して処理するまで続く。多くの受信機がある場合でも同様に、これと同じプロセスを繰り返すことができる。他の線形結合、方程式、セグメント、並びに／又は線形結合、方程式、及びセグメントの組み合わせを使用してもよい。

線形結合に含めるセグメントの選択はランダムであるため、いくつかのツリーのサイズは大きくなり得る。（例えば、性能向上のために）メモリバッファ及び線形方程式のサイズを低減するために、受信機は、大きなツリーで現れるセグメントを送信する要求を任意のセンダに送信することができる。要求された元のセグメントが受信されると、大きなツリーに含まれているすべてのセグメントを計算することができる。

図７を参照すると、ビデオネットワークの状態に依存する２つの例示的な搬送方法が示される。本開示の実施形態は、ビデオトランスポンダ間のデータ送信が途切れず、通信回線が安定している例示的なケースに対応する。しかし、送信が安定していない場合、ビデオトランスポータによっては、他のトランスポータがジョブを完了する前にジョブを完了するものがある。このような場合、ビデオトランスポータＡ及びＣはデータを送信して（ステップ７０４）セグメント５を埋め（ステップ７０５）、それによって、線形結合を介して２つのストリームをリアルタイムで結合して１つのセグメントを埋める。

図１２を参照すると、アップロード帯域幅１５０ｋｂｐｓを有し、ストリームを結合し併合する選択肢を付けずにそれぞれ同じビデオ（１２０１、１２０２）を２つのビューア（１２０７、１２０８）に送信する２つのプロジェクタ（１２０３、１２０４）が示される。プロジェクタ（１２０３）は、ビットレート１００ｋｂｐｓでビデオファイルをストリーミングするのに十分なチャネル（１２０５）を介してビデオをビューア（１２０７）に送信する。プロジェクタ（１２０４）は、ビットレート１００ｋｂｐｓでビデオファイルをストリーミングするのに十分なチャネル（１２０６）を介してビデオをビューア（１２０８）に送信する。利用可能な帯域幅は、現在の送信容量を超えるノードの帯域幅である。これは、予約帯域幅にフリー帯域幅を足したものである。ビデオネットワークで利用可能な帯域幅（フリー帯域幅に予約帯域幅を足したもの）は１００ｋｂｐｓに等しく、このうちの５０ｋｂｐｓはプロジェクタ（１２０３）からであり、５０ｋｂｐｓは（１２０４）からである。プロジェクタ（１２０３）及びプロジェクタ（１２０４）からの２つのストリームを結合することによって、この例では、ビデオ（１２０１、１２０２）の到達範囲を別の１つのビューアに拡張することが可能である。

図１３はストリームの結合及び併合の効果を示す。この例では、それぞれアップロード帯域幅１５０ｋｂｐｓを有する２つのプロジェクタ（１３０３、１３０４）が、同じビデオ（１３０１、１３０２）を３つのビューア（１３０７、１３０８、１３１１）に送信している。プロジェクタ（１３０３）は、ビットレート１００ｋｂｐｓでビデオファイルをストリーミングするのに十分なチャネル（１３０５）を介してビデオをビューア（１３０７）に送信する。プロジェクタ（１３０４）は、ビットレート１００ｋｂｐｓでビデオファイルをストリーミングするのに十分なチャネル（１３０６）を介してビデオをビューア（１３０８）に送信する。さらに、両方のプロジェクタ（１３０３、１３０４）は、新しいビューア（１３１１）がビデオを適宜且つリアルタイムで見るように、ストリームをリアルタイムで結合することによってビデオをビューア（１３１１）に送信する。プロジェクタ（１３０３）は、ビデオ（１２０１）をビューア（１３１１）に５０ｋｂｐｓで送信し、プロジェクタ（１３０４）もビデオ（１２０２）をビューア（１３１１）に５０ｋｂｐｓで送信する。一緒になって、これはビューア（１３１１）がビデオを結合されているビデオストリームとして見るのに十分である。

ストリームをリアルタイムで結合して併合することによって、ビデオネットワークの到達範囲を拡張する能力が提供される。ビデオ到達範囲は、ビデオネットワーク内でリアルタイムでビデオ送信を受信する受信機の数である。拡張ビデオ到達範囲（extended video reach）（ＥＶＲ）は、ビデオネットワークに参加することができ、複数の送信機の利用可能な帯域幅を結合する結果、リアルタイムストリームを受信することができる追加の受信機の数である。ビットレートｂでビデオを送信しているいくつかの送信機があり、送信機の利用可能な合計帯域幅がＵである場合、拡張ビデオ到達範囲はＵをｂで割った整数部分に等しい。

本開示の一実施形態が、２００５年９月２０日付けの「A Method And System For Realtime Media Streaming」と題する仮特許出願に記載されており、その全体を参照によって本命書に援用する。

いくつかの例示的な態様及び実施形態を上述したが、特定の変更、置換、追加、及び下位結合を当業者は認識しよう。したがって、添付の特許請求の範囲は、特許請求の範囲の真の精神及び範囲内にあるこのような変更、置換、追加、及び下位結合をすべて包含するものである。

ビデオファイルデータ転送システムの例示的なシステムアーキテクチャの図である。 本開示の一実施形態のオブジェクトモデルの例示的な概略図である。 Ａ ビデオのリアルタイムコンテンツ送信の例示的なビデオネットワークの例示的な構造構成の図である。Ｂ 図３Ａの例示的なビデオネットワークによって説明される例示的な搬送システムの同様のトポロジー構成を示す図である。 ビデオ管理・搬送システムでの管理及び機能に関する相互関係の組み合わせを示す例示的なトポロジーマップである。 本開示の一実施形態の搬送システムの例示的なトポロジーマップである。 ビデオネットワークを構築する例示的なプロセスの流れ図である。 ビデオネットワークの状態に依存する２つの例示的な搬送方法を示す図である。 本開示の一実施形態での帯域幅の管理及び利用の例示的なプロセスを示す図である。 例示的なビデオネットワーク及びリアルタイムで２つのストリームを１つのストリームに併合するプロセスを示す図である。 データを受信機に送信する際に関わる意思決定プロセスの流れ図である。 線形結合ソルバが使用するプロセスの流れ図である。 非結合ストリーミング構成を有する例示的なビデオネットワークを示す図である。 結合ストリーミング構成を有する例示的なビデオネットワークを示す図である。

Claims (28)

1. リアルタイムコンテンツ送信機であって、
   該送信機と1つ又は複数の受信機との間でのコンテンツ送信を調整すると共に、該1つ又は複数の受信機からのコンテンツ再送信をさらに調整するように構成されている帯域幅管理モジュールを備える、送信機。
2. 前記帯域幅管理モジュールは、コンテンツデータレートが前記コンテンツに関連する最小データレート以上であるようにコンテンツの送信及び再送信を調整するように構成されている、請求項１に記載の送信機。
3. 前記帯域幅管理モジュールは、動的帯域幅を計算するように構成されている、請求項１に記載の送信機。
4. 前記帯域幅管理モジュールは、計算された速度で通信するように1つ又は複数のノードに命令するように構成されている、請求項１に記載の送信機。
5. 前記帯域幅管理モジュールは、データを送信するために1つ又は複数のノードを割り当てるように構成されている、請求項１に記載の送信機。
6. 前記帯域幅管理モジュールは、２つ以上のノード間で利用可能な通信オプションに基づいてデータを送信するために1つ又は複数のノードを割り当てるように構成されている、請求項５に記載の送信機。
7. 前記コンテンツはメディアコンテンツを含む、請求項１に記載の送信機。
8. 前記メディアコンテンツはビデオコンテンツを含む、請求項７に記載の送信機。
9. 前記帯域幅管理モジュールは別のノードに転送可能である、請求項１に記載の送信機。
10. 前記帯域幅管理モジュールは、ディセーブルノードを識別すると共に、データを送信又は受信するために別のノードを割り当てるように構成されている、請求項１に記載の送信機。
11. 前記帯域幅管理モジュールは、ファイアウォールによって課される制約がある場合に中継ノードを確立するようになっている、請求項１に記載の送信機。
12. 前記帯域幅管理モジュールは、前記コンテンツを中央サーバにアップロードせずに前記送信機と前記1つ又は複数の受信機との間でのコンテンツ送信を調整するように構成されている、請求項１に記載の送信機。
13. コンテンツを符号化するように構成されている符号化モジュールをさらに備える、請求項１に記載の送信機。
14. コンテンツストリームをリアルタイムで結合するように構成されているコンテンツトランスポータをさらに備える、請求項１に記載の送信機。
15. リアルタイムコンテンツ受信機であって、
    帯域幅管理モジュールからの信号に基づいて1つ又は複数のソースからコンテンツを受信するように構成されている通信モジュールであって、前記帯域幅管理モジュールからの信号に基づいて1つ又は複数の宛先に受信コンテンツを再送信するようにさらに構成されている、通信モジュールを備える、受信機。
16. 前記帯域幅管理モジュールは、コンテンツデータレートが前記コンテンツに関連する最小データレート以上であるようにコンテンツの送信及び再送信を調整するように構成されている、請求項１５に記載の受信機。
17. 前記帯域幅管理モジュールは、動的帯域幅を計算するように構成されている、請求項１５に記載の受信機。
18. 前記帯域幅管理モジュールは、計算された速度で通信するように1つ又は複数のノードに命令するように構成されている、請求項１５に記載の受信機。
19. 前記帯域幅管理モジュールは、データを送信するために1つ又は複数のノードを割り当てるように構成されている、請求項１５に記載の受信機。
20. 前記帯域幅管理モジュールは、２つ以上のノード間で利用可能な通信オプションに基づいてデータを送信するために1つ又は複数のノードを割り当てるように構成されている、請求項１５に記載の受信機。
21. 前記コンテンツはメディアコンテンツを含む、請求項１５に記載の受信機。
22. 前記メディアコンテンツはビデオコンテンツを含む、請求項２１に記載の受信機。
23. 前記帯域幅管理モジュールは別のノードに転送可能である、請求項１５に記載の受信機。
24. 前記帯域幅管理モジュールは、ディセーブルノードを識別すると共に、データを送信又は受信するために別のノードを割り当てるように構成されている、請求項１５に記載の受信機。
25. 前記帯域幅管理モジュールは、ファイアウォールによって課される制約がある場合に中継ノードを確立するように構成されている、請求項１５に記載の受信機。
26. 前記帯域幅管理モジュールは、前記コンテンツを中央サーバにアップロードせずに送信機と1つ又は複数の受信機との間でのコンテンツ送信を調整するように構成されている、請求項１５に記載の受信機。
27. コンテンツストリームをリアルタイムで結合するように構成されているコンテンツトランスポータをさらに備える、請求項１５に記載の受信機。
28. 受信コンテンツについての１つ又は複数の肯定応答メッセージを１つ又は複数の送信機に送信するようにさらに構成されている、請求項１５に記載の受信機。

Images