動的ストリームインターリービングおよびサブストリームベースの配信
【課題】複数のストリームを動的にインターリーブする方法を提供する。
【解決手段】受信機と第１の送信機との間のコネクションを形成することと、第１の送信機から送信された、インターリービングの初期量を含む第１のコンテンツストリームを受信機で受信することと、第１のコンテンツストリームのソースブロック構造とは関係なく、第１のコンテンツストリームの伝送中に、第１のコンテンツストリームに含まれるインターリービングの量を調整することと、第１のコンテンツストリーム内の現在の伝送位置に基づいて、インターリービングの量をインターリービングの初期量から増加させる、を含む。
【解決手段】受信機と第１の送信機との間のコネクションを形成することと、第１の送信機から送信された、インターリービングの初期量を含む第１のコンテンツストリームを受信機で受信することと、第１のコンテンツストリームのソースブロック構造とは関係なく、第１のコンテンツストリームの伝送中に、第１のコンテンツストリームに含まれるインターリービングの量を調整することと、第１のコンテンツストリーム内の現在の伝送位置に基づいて、インターリービングの量をインターリービングの初期量から増加させる、を含む。
【発明の詳細な説明】
【優先権の主張】
【０００１】
本出願は、２００７年４月１６日出願の「Dynamic Stream Interleaving and Sub-Stream Based Delivery」という名称の米国特許仮出願第６０／９１２１４５号明細書の利益を主張する。本出願の内容は、すべての目的でその全体が参照により本明細書に組み込まれる。
【０００２】
また、本開示は、すべての目的で、全部本書内で記載のように、参照により以下の同出願人による出願／特許を組み込む。
【０００３】
Ｌｕｂｙによる米国特許第６，３０７，４８７号明細書（以下「Ｌｕｂｙ Ｉ」と呼ぶ）
Ｓｈｏｋｒｏｌｌａｈｉらによる米国特許第７，０６８，７２９号明細書（以下「Ｓｈｏｋｒｏｌｌａｈｉ Ｉ」と呼ぶ）
Ｌｕｂｙらによる２００６年６月９日出願の「Forward Error-Correcting (FEC) Coding and Streaming」という名称の米国特許出願第１１／４２３，３９１号明細書（以下「Ｌｕｂｙ ＩＩ」と呼ぶ）
Ｗａｔｓｏｎらによる２００７年２月１３日出願の「Streaming and Buffering Using Variable FEC Overhead and Protection Periods」という名称の米国特許出願第１１／６７４，６２５号明細書（以下「Ｗａｔｓｏｎ」と呼ぶ）
【技術分野】
【０００４】
本発明は、ストリーミング品質配信、コンテンツザッピング時間（content zapping time）、ストリームの拡張可能な分散配信、およびＦＥＣ符号化の使用を、あらゆる側面において向上させ、ストリーミングソリューションを向上させることに関する。ストリーミングは、オンデマンドのプレイリストコンテンツまたはライブプレゼンテーションの、一定のまたは可変のビットレートでの音声、映像、およびデータのストリーミングを含む。
【背景技術】
【０００５】
インターネット、セルラーおよび無線ネットワーク、電力線ネットワーク、および他の多くのネットワークなど、パケットベースのネットワークを介して高品質の音声および映像が配信されることがますます一般的になるにつれて、ストリーミングメディア配信は、ますます重要になりつつある。配信されたストリーミングメディアの品質は、元のコンテンツの品質、元のコンテンツの符号化品質、映像を復号し表示する受信装置の能力、受信機で受信された信号の適時性および品質などを含めて、いくつかの要因に依存する。認められる良いストリーミングメディア経験を作り出すために、受信機で受信された信号のトランスポートおよび適時性は、特に重要である。良いトランスポートは、送信機から送信されたものに比べて、受信機で受信されたストリームの忠実度を提供し、一方、適時性は、そのコンテンツの最初の要求後、受信機がコンテンツの再生をどれだけ迅速に開始できるかを表す。
【０００６】
最近では、伝送中、ストリーミングメディアの保護のために、順方向誤り訂正（ＦＥＣ）符号の使用を考えることが一般的な方法になっている。３ＧＰＰ、３ＧＰＰ２およびＤＶＢなどのグループによって標準化されたものなど、インターネットおよび無線ネットワークなどを例として含むパケットネットワークを介して送信されるとき、ソースストリームは、生成されたように、あるいは使用可能なように、パケットに入れられ、したがって、パケットは、ソースまたはコンテンツストリームを、生成された順または使用可能になる順に受信機に運ぶために使用される。
【０００７】
これらのタイプのシナリオへのＦＥＣ符号の一般的な適用では、符号器は、リペアパケット（repair packet）の作成にＦＥＣ符号を使用し、リペアパケットは、次いで、ソースストリームを含む元のソースパケットに加えて送信される。リペアパケットは、ソースパケットの損失が起こると、失われたソースパケットに含まれるデータを回復するために、受信したリペアパケットを使用することができるという特性を有する。リペアパケットは、完全に紛失した、失われたソースパケットの内容を回復するために使用することができるが、リペアパケットは、完全に受信されたリペアパケット、または部分的に受信されたリペアパケットでさえ、部分的なパケット損失の発生から回復するために使用することもできる。したがって、全部または部分的に失われたソースパケットを回復するために、全部または部分的に受信されたリペアパケットを使用することができる。
【０００８】
さらに他の例では、例えば、ビットの値が反転され得るなど、送信データに他のタイプの破損が起こる可能性があり、したがって、こうした破損を修正し、できるだけ正確なソースパケットの回復を提供するために、リペアパケットを使用することができる。他の例では、ソースストリームは、必ずしも個別のパケットで送信されるわけではなく、代わりに、例えば連続するビットストリームとして送信され得る。
【０００９】
ソースストリームの保護を提供するために使用することができるＦＥＣ符号の例が数多くある。リードソロモン符号は、通信システムにおける誤りおよび消去訂正のためのよく知られている符号である。例えば、パケットデータネットワークを介した消去訂正の場合、リードソロモン符号のよく知られている効率的な実装は、Ｌ．Ｒｉｚｚｏによる「Effective Erasure Codes for Reliable Computer Communication Protocols」、Computer Communication Review, 27(2):24-36 (April 1997)（以下「Ｒｉｚｚｏ」）およびＢｌｏｅｍｅｒらによる「An XOR-Based Erasure-Resilient Coding Scheme」、Technical Report TR-95-48, International Computer Science Institute, Berkeley, California (1995)（以下「ＸＯＲ−Ｒｅｅｄ−Ｓｏｌｏｍｏｎ」）他に記載されているように、ＣａｕｃｈｙまたはＶａｎｄｅｒｍｏｎｄｅ行列を使用する。
【００１０】
ＦＥＣ符号の他の例には、例えばＬＤＰＣ符号、Ｌｕｂｙ Ｉに記載されているものなどの連鎖反応符号（chain reaction code）、およびＳｈｏｋｒｏｌｌａｈｉ Ｉのマルチステージ連鎖反応符号（multi-stage chain reaction code）などがある。
【００１１】
リードソロモン符号の変形のＦＥＣ復号プロセスの例は、ＲｉｚｚｏおよびＸＯＲ−Ｒｅｅｄ−Ｓｏｌｏｍｏｎに記載されている。これらの例では、十分なソースおよびリペアデータパケットが受信された後で復号が適用される。復号プロセスは、計算量が多い可能性があり、使用可能なＣＰＵリソースに応じて、ブロック内のメディアに要する時間の長さに対して、終了するのにかなりの時間がかかり得る。受信機は、メディアストリームの受信の開始とメディアの再生との間に要する遅延を計算するとき、復号に必要なこの時間長を考慮に入れる必要がある。復号によるこの遅延は、ユーザによって、特定のメディアストリームの要求と再生の開始との間の遅延として知覚される。したがって、この遅延を最低限に抑えることが望ましい。
【００１２】
多くの用途では、パケットは、ＦＥＣプロセスが適用されるシンボルにさらに細分される。パケットは、１つまたは複数のシンボル（または１つ未満のシンボルであるが、通常、シンボルはパケットにわたって分割されない）を含み得る。シンボルは、任意のサイズを有し得るが、シンボルのサイズは、多くてもパケットのサイズに等しいことが多い。ソースシンボルとは、送信されるデータを符号化するシンボルである。リペアシンボルとは、ソースシンボルに加えて、ソースシンボルから直接または間接的に生成されるシンボルである（すなわち、ソースシンボルのすべてが使用可能であり、リペアシンボルが使用不可である場合、送信されるデータは、完全に回復することができる）。
【００１３】
符号化操作が、あるブロック内のシンボルに依存し、そのブロックにないシンボルとは無関係であり得るという点で、一部のＦＥＣ符号は、ブロックベースである。ブロックベースの符号化では、ＦＥＣ符号器は、あるブロック内のソースシンボルからそのブロックのリペアシンボルを生成することができ、次いで次のブロックに進み、符号化されている現在のブロックのもの以外のソースシンボルを参照する必要はない。伝送では、ソースシンボルを備えるソースブロックは、符号化されたシンボル（いくつかのソースシンボル、いくつかのリペアシンボル、またはその両方とすることができる）を含む符号化されたブロックによって表すことができる。リペアシンボルの存在と共に、すべてのソースシンボルがすべての符号化されたブロックで必要というわけではない。
【００１４】
一部のＦＥＣ符号、特にリードソロモン符号では、符号化および復号の時間は、ソースブロック当たりの符号化シンボルの数が増えるにつれて増加して非現実的になる。したがって、実際には、特に、リードソロモン符号化または復号プロセスがカスタムハードウェアによって実行される一般的な場合には、ソースブロック当たり生成することができる符号化シンボルの総数に、実用上の上限（２５５がいくつかの用途でのおおよその実用上の制限）があることが多い。例えば、パケット損失からストリームを保護するためのＤＶＢ−Ｈ標準の一部として含まれるリードソロモン符号を使用するＭＰＥ−ＦＥＣプロセスは、ソースブロック当たり合計２５５個のリードソロモン符号化シンボルに制限されたセル方式の電話内の専用ハードウェアに実装される。シンボルを別々のパケットペイロードに入れる必要があることが多いため、これによって、符号化されるソースブロックの最大長に実用上の上限が設けられる。例えば、パケットペイロードが１０２４バイト以下に制限され、各パケットが１つの符号化シンボルを運ぶ場合、符号化ソースブロックは、多くて２５５ＫＢ（キロバイト）とすることができ、これは、当然、ソースブロック自体のサイズの上限でもある。
【００１５】
ソースストリーミングレートについていけるほど十分速くソースブロックを復号することができること、ＦＥＣ復号によってもたらされる復号待ち時間を最低限に抑えることができること、ＦＥＣ復号中の任意の時点で受信装置上の使用可能なほんのわずかなＣＰＵのみを使用することができることなど、他の関心事が問題である。
【００１６】
他の問題は、ストリームの再生を開始する機能を含む。例えば、パーソナルコンピュータを使用して受信したオーディオおよびビデオストリームを復号及びレンダリングし、コンピュータ画面にビデオを表示し、内蔵スピーカを介して音声を再生したり、または他の例として、セットトップボックスを使用して受信した音声および映像ストリームを復号及びレンダリングし、テレビ表示装置に映像を表示し、ステレオシステムを介して音声を再生したり、などである。第１の問題は、ストリームとして配信された新しいコンテンツをユーザが見ることを決めたときと、コンテンツが再生開始したときとの間の遅延を最低限に抑えることであり、以下「コンテンツザッピング時間」と呼ぶ。コンテンツザッピングの一例は、ユーザが、第１のストリームを介して配信された第１のコンテンツを見ており、次いでユーザが、第２のストリームを介して配信された第２のコンテンツを見ることを決め、第２のコンテンツを見始めるためにアクションを開始するときである。第２のストリームは、第１のストリームと同じかまたは異なるサーバセットから送信され得る。コンテンツザッピングの別の例は、ユーザがあるＷｅｂサイトを見ており、ブラウザウィンドウ内のリンクをクリックすることによって、第１のストリームを介して配信された第１のコンテンツを見始めることを決めたときである。コンテンツザッピングの別の例は、ユーザが、同じコンテンツストリーム内で順方向または逆方向のいずれかの新しい位置に移動して表示を開始したいときである。使用可能な様々なコンテンツを検索して試写する際に高品質の高速コンテンツサーフィン経験をユーザにとって可能にするためには、コンテンツザッピング時間を最低限に抑えることが、映像を見る上で重要である。高品質の高速コンテンツサーフィン経験は、ユーザが消費するコンテンツの量と正の相関を有することが多い。
【００１７】
コンテンツザッピング時間の主な誘因は、基礎を成すＦＥＣ構造である場合がしばしばある。別の問題は、あるコンテンツの再生の終わりと、別のコンテンツの再生の開始との間の時間のギャップを最低限に抑えることであり、ほとんどまたはまったく停止することなく連続することが好ましい。例えば、あるコンテンツが放送番組であり、次のコンテンツが広告である場合、または逆の場合、それらの再生の間の長いギャップ（以下「コンテンツ遷移時間（content transition time）」と呼ぶ）は、望ましくない。
【００１８】
明らかに、コンテンツ遷移時間を最低限に抑えると共に、遷移周辺の期間中の受信機へのストリームのレートを最低限に抑えることが望ましい。
【００１９】
別の問題は、パケットをドロップする可能性があり、パケットの配信にかかる時間量の広範な変動をもたらす可能性がある、インターネットなどのベストエフォート型の配信ネットワークを使用するとき、配信されたストリームの品質を最大にすると共に、帯域幅などのネットワークリソースの使用量を最低限に抑えることである。
【００２０】
別の問題は、受信機に配信されるストリームの品質に悪影響を与えること無く、システムの構成要素が故障することが可能である、頑強で拡張可能なストリーミング配信ソリューションを提供することである。
【００２１】
インターリービングは、断続的なパケット損失など、チャネルの不完全性に対する優れた保護を提供するために使用することができる。例えば、パケット損失は、ある程度バースト的であることが多く、したがって、より長い期間にわたってソースブロックを分配することが有利となり得る。一部のＦＥＣ符号では、大きいソースブロックの本来の使用は、実用的であるが、リードソロモン符号など、他のＦＥＣ符号では、使用することができるソースブロックのサイズの実用上の制限があることが多い。したがって、より長い時間にわたってソースブロックに関連付けられているパケットの伝送を分配するために、異なるソースブロックについての符号化シンボルを含むパケットの送信をインターリーブすることが有利となり得る。
【００２２】
以前に、上述した問題の一部に対処する方法が紹介されている。例えば、いくつかの新規のＦＥＣソースブロックの形成およびインターリービングの方法がＬｕｂｙ ＩＩに記載されている。いくつかのインターリービング方法は、インターリービングの量が全ストリームについて固定されているという意味で、静的である。したがって、時として、こうした方法によって提供される保護の品質に影響を与えるインターリービングの量と、コンテンツザッピング時間との間のトレードオフがあり、すなわち、より多い量のインターリービングは、より良いストリーム保護を提供するが、より長いコンテンツザッピング時間を提供し、このトレードオフは、受信機へのストリーミングの全継続時間の間、固定された方法で決定される。
【００２３】
例えば、Ｗａｔｓｏｎに記載されている一部の方法など、ストリーム送信プロセスの大部分の間、短いコンテンツザッピング時間およびより多い量のインターリービングを提供する方法がいくつかある。Ｗａｔｓｏｎに記載されている方法の一部は、短い初期ソースブロックから徐々により長いソースブロックに動的に遷移し、遷移期間中、コンテンツストリーミングレートよりわずかに速いレートで送信する。こうした方法は、短いコンテンツザッピング時間を提供すると共に、ストリームが進むにつれて提供される保護の品質の強化を可能にする。例えば、Ｗａｔｓｏｎに記載されている方法の一部を適用する１つの方法は、ソースブロック構造を決定し、ストリームが送信されている間にＦＥＣ符号化を実行することであり、すなわち、短−長ソースブロック構造は、それらがアクセスされる各点で、個々の受信機に送信されながら決定され、ＦＥＣ符号化され、したがって、ソースブロック構造の形成およびＦＥＣ符号化は、受信機ごとに一意に実行され、各受信機に送信されるストリームは、一意である。しかし、時として、ストリームの配信に関係なく、例えば、受信機に関係なく、コンテンツが表示されるときおよびコンテンツストリームにおいて表示を開始する場所に関係なく、およびどの順でストリーム内のデータが配信されるかに関係なく決定されるコンテンツストリームのソースブロック構造を有することが望ましい。これは、コンテンツストリームが複数のサーバから単一の受信機に配信される場合、特に重要である。
【００２４】
したがって、改良されたプロセスおよび装置を有することが望まれる。
【発明の概要】
【００２５】
本発明の態様による符号器、復号器、および通信システムの実施形態は、複数のストリームを動的にインターリーブする方法を提供し、該方法は、任意のソースブロック構造とは関係なく、ストリームが送信されるとき、より多くの量のインターリービングを動的に導入するための方法を含む。これらの方法のいくつかの利点は、チャネルの損失または誤りを、インターリービングが導入されなかった場合よりかなり長い期間にわたって元のストリーム内で分配し、ＦＥＣ符号化と共に使用するとき、パケット損失またはパケット破損に対する優れた保護を提供し、ネットワークジッタに対する優れた保護を提供し、コンテンツザッピング時間およびコンテンツ遷移時間を最小値に低減することができることである。これらの方法のいくつかの追加の利点は、あるコンテンツのストリーミングから別のコンテンツのストリーミングへの遷移を含めて、送信ストリーミングレートを平滑化すること、および最小のコンテンツ遷移時間を含む。
【００２６】
本発明の態様による符号器、復号器、および通信システムの実施形態は、データのストリームを複数のサブストリームに分割し、ネットワークを介して、異なるパスに沿って、該複数のサブストリームを受信機に配信し、受信機で、潜在的に異なる複数のサーバから送信された異なる複数のサブストリームを同時に受信することを提供することもできる。ＦＥＣ符号化と共に使用されるとき、これらの方法は、潜在的に異なる複数のサーバから各ソースブロックの符号化の部分を配信することを含む。これらの方法のいくつかの利点は、改良されたコンテンツザッピング時間、サーバ障害およびパス障害に対する頑強性、ディスク障害に対する頑強性、パケットの損失および／または破損に対する改良された頑強性、ストリーミング配信ソリューション全体の改良された拡張可能性、および複数のサーバ間での改良されたコンテンツの格納とストリーミングレートとの均衡化を含む。
【００２７】
本発明の態様による符号器、復号器、および通信システムの実施形態は、動的インターリーブとサブストリームの配信との結合も提供し得る。例えば、動的インターリーブを使用して、ソースブロック構造およびＦＥＣ符号化を決定することができ、符号化されたストリームを、複数のサブストリームに分割することができ、動的インターリーブを使用して、サブストリームの組合せを受信機に配信して、最低コンテンツザッピング時間を提供する頑強なストリーミング配信システムを提供することができる。これらの結合方法の利点は、動的インターリーブおよびサブストリーム配信の利点の組合せである。
【００２８】
以下の詳細な説明を添付の図面と併せ読めば、本発明の本質および利点をよりよく理解できよう。
【図面の簡単な説明】
【００２９】
【図１】本発明の一実施形態による通信システムを示すブロック図。
【図２】コンテンツザッピング時間を示す図。
【図３Ａ】コンテンツザッピング時間の構成要素を例示する図。
【図３Ｂ】復号中のＦＥＣについてのＣＰＵ使用率を例示する図。
【図４】コンテンツストリームのソースブロック構造およびソースブロックごとの対応するコンテンツストリームレートの表現を例示する図。
【図５】図４のコンテンツストリームに対応する符号化ブロック構造を例示する図。
【図６】基本的な送信器の方法に対応する受信機およびコンテンツザッピング時間を例示する図。
【図７】ストリーム送信のテープ方法を例示する図。
【図８】ストリーム送信のテープ方法による静的インターリービングを例示する図。
【図９】静的インターリービングの送信器の方法に対応する受信機およびコンテンツザッピング時間を例示する図。
【図１０】新しいストリームが受信機に送信されるときの動的インターリービングの送信機の方法を例示する図。
【図１１】動的インターリービングの送信機の方法での、受信機によって経験されるコンテンツザッピング時間および長期保護期間を例示する図。
【図１２】動的インターリービングの送信機の方法での、２つの連続するコンテンツセグメント間のコンテンツ遷移を例示する図。
【図１３】動的インターリービングの送信機の方法での、２つの非連続のコンテンツセグメント間のコンテンツ遷移を例示する図。
【図１４】ヘッドエンドサーバからサブストリームベースの配信方法で使用される分散された様々なサーバに分散される符号化コンテンツストリームを例示する図。
【図１５】サブストリームベースの配信方法において、受信機が、分散された様々なサーバにコンテンツストリームを要求し、こうしたサーバの一部から符号化コンテンツストリームを受信することを例示する図。
【発明を実施するための形態】
【００３０】
実施形態は、伝送がネットワークなどを介する場合、任意のソースブロック構造とは関係なく、ストリームが送信されるとき、より多くの量のインターリービングを動的に導入する方法を含めて、ストリームを動的にインターリーブする新規の方法を提示する。また、実施形態は、データのストリームを複数のサブストリームに分割し、ネットワークを介して、異なるパスに沿って、該複数のサブストリームを受信機に配信し、受信機で、潜在的に異なる複数のサーバから送信された異なる複数のサブストリームを同時に受信する新規の方法も提示する。ＦＥＣ符号化と共に使用されるとき、これらの方法は、潜在的に異なる複数のサーバから各ソースブロックの符号化の部分を配信することを含む。また、実施形態は、動的インターリービングをサブストリームの配信と結合する新規の方法も提示する。
【００３１】
以下、本明細書における説明を簡単にするために、データを運ぶネットワークは、パケットベースと仮定し、本明細書に記載されたプロセスおよび方法を、連続するビットストリームネットワークなど、他のタイプの送信ネットワークに適用できる方法を当業者が容易に理解できることを認識されたい。以下、本明細書における説明を簡単にするために、ＦＥＣ符号は、失われたパケットまたはパケット内の失われた部分的なデータに対する保護を提供すると仮定し、本明細書に記載されたプロセスおよび方法を、ビットフリップなど、他のタイプのデータ送信の破損に適用できる方法を当業者が容易に理解できることを認識されたい。この説明において、符号化すべきデータ（ソースデータ）は、（単一ビットまでの）任意の長さのものであるが、データの異なる部分について異なる長さのものとすることができる等しい長さの複数の「シンボル」に分割されていると仮定する。
【００３２】
シンボルは、パケットでデータネットワークを介して運ぶことができ、各パケットには、整数のシンボルが明示的に入れられ、または暗に含まれる。いくつかの場合、ソースパケットは、シンボル長の倍数ではないことが可能であり、この場合、パケット内の最後のシンボルは、切り捨てることができる。この場合、ＦＥＣ符号化の目的で、この最後のシンボルは、これらのビットがパケットで運ばれない場合でも、依然として、受信機が切り捨てられた最後のこのシンボルを充填して完全なシンボルとすることができるように、例えば、ゼロ値のビットなど、固定されたパターンのビットで埋められるものと暗黙的に見なされる。他の実施形態において、固定されたパターンのビットは、パケットに入れることができ、それによって、シンボルを、パケットのものと等しい長さまで効果的に埋めることができる。シンボルのサイズは、しばしばビットで測定することができ、この場合、シンボルは、Ｍビットのサイズを有し、シンボルは、２~Ｍ（２のＭ乗）個のシンボルのアルファベットから選択される。非２進数も企図されるが、２進数は、より一般的に使用されるので、好ましい。
【００３３】
ストリーミングとの使用を考慮されるＦＥＣ符号は、一般に、システマチックＦＥＣ符号であり、すなわち、ソースブロックのソースシンボルがソースブロックの符号化の一部として含まれ、したがって、ソースシンボルが送信される。当業者であれば認識するように、本明細書に記載された方法およびプロセスは、システマチックではないＦＥＣ符号にも十分等しく適用される。システマチックＦＥＣ符号器は、ソースシンボルのソースブロックから、いくつかのリペアシンボルを生成し、少なくともいくつかのソースシンボルとリペアシンボルとの組合せは、ソースブロックを表す、チャネルを介して送信される符号化シンボルである。いくつかのＦＥＣ符号は、例えば「情報付加符号（information additive code）」や「ファウンテンコード（fountain code）」など、必要なだけのリペアシンボルを効率的に生成するのに有用であり、これらの符号の例には、「連鎖反応符号」および「マルチステージ連鎖反応符号」などがある。リードソロモン符号など他のＦＥＣ符号は、実際に、ソースブロックごとに制限された数のリペアシンボルを生成することしかできない。
【００３４】
シンボルを運ぶための他の多くの方法があり、以下の説明は、簡単にするために、パケットの方法を使用するが、これは、限定的または包括的であるものではない。以下の説明の文脈で、「パケット」という用語は、単一単位のデータとして何が送信されるかを文字通り意味することに制約されるものではない。代わりに、単一単位のデータとして送信され得る、またはされ得ない、シンボルおよび部分的シンボルの論理的なグループ分けを定義する、より広い概念を含むものとする。
【００３５】
また、例えば、以下に記載する方法が等しく適用される、伝送においてその値を変えるシンボルや、他の方法で破損されるシンボルなど、シンボルの損失以外のデータの破損の形態もある。したがって、以下の記載は、しばしばシンボルの損失について説明しているが、方法は、他のタイプの破損、およびＦＥＣ誤り訂正符号など、ＦＥＣ消去符号を超えた他のタイプのＦＥＣ符号にも十分等しく適用される。
【００３６】
＜ＦＥＣ符号例＞
図１は、連鎖反応ＦＥＣ符号化を使用する通信システム１００のブロック図である。通信システム１００には、入力ファイル１０１、または入力ストリーム１０５が入力シンボルジェネレータ１１０に提供される。入力シンボルジェネレータ１１０は、入力ファイルまたはストリームから１つまたは複数の入力シンボル系列（ＩＳ（０），ＩＳ（１），ＩＳ（２），・・・）を生成し、各入力シンボルは、値および位置を有する（図１に括弧内の数字として示されている）。入力シンボルの可能な値、すなわちそのアルファベットは、各入力シンボルが入力ファイルのＭ個分のビットを符号化するように、一般に、２００万個のシンボルのアルファベットである。Ｍの値は、一般に、通信システム１００の使用によって決定されるが、汎用システムは、Ｍを使用によって変えることができるように、入力シンボルジェネレータ１１０のためにシンボルサイズの入力を含み得る。入力シンボルジェネレータ１１０の出力は、符号器１１５に提供される。
【００３７】
キージェネレータ１２０は、符号器１１５によって生成される出力シンボルごとにキーを生成する。各キーは、Ｌｕｂｙ ＩまたはＳｈｏｋｒｏｌｌａｈｉ Ｉに記載されている方法、またはキーがこれによって生成されたか、他のキージェネレータによって生成されたかにかかわらず、同じ入力ファイルまたはストリーム内のデータのブロックのために生成されたキーの大半が一意であることを保証する任意の同等の方法のうちの１つに従って生成することができる。例えば、キージェネレータ１２０は、カウンタ１２５の出力、一意のストリーム識別子１３０、および／またはランダムジェネレータ１３５の出力の組合せを使用して、各キーを生成することができる。キージェネレータ１２０の出力は、符号器１１５に提供される。他の例では、例えば、一部のストリーミングの用途では、キーの組を固定し、ストリーム内のデータのブロックごとに、再度、再利用することができる。一般的な実施形態では、生成することができるキーの数は、入力ファイルまたはストリームのサイズや他の特徴ではなく、キージェネレータの解像度によって指示される。例えば、入力がしばしば１０００シンボル程度以下であると予想される場合、キーの解像度は、３２ビットとすることができ、それによって、最高４０億個の一意のキーが可能になる。これらの相対数の１つの結果は、キーに従って符号化する符号器は、４０００個のシンボルの入力について、４０億個の一意の出力シンボルを生成することができ得ることである。実際問題として、ほとんどの通信システムが、シンボルの０．９９９９９９部を失うことはないため、約４０億個の出力シンボルを生成する必要はなく、したがって、可能なキーの数は、事実上無制限として扱うことができ、繰り返す必要がなく、キーの２つの独立した選択が同じキーを掴む可能性は、無視できるほど小さい。しかし、それが何らかの理由のためにそうである場合、キーを使用するプロセスがまるでキーの無限の提供があるかのように振る舞うことができるように、キージェネレータの解像度を増やすことができる。
【００３８】
キージェネレータ１２０によって提供された各キーＩから、符号器１１５は、入力シンボルジェネレータによって提供される入力シンボルから、値Ｂ（Ｉ）の出力シンボルを生成する。
【００３９】
各出力シンボルの値は、そのキーと、本明細書において出力シンボルの「関連入力シンボル」または単にその「関連」と呼ぶ１つまたは複数の入力シンボルの何らかの関数とに基づいて生成される。しかし常にではないが、一般に、Ｍは、入力シンボルおよび出力シンボルについて同じであり、すなわち、これらはいずれも、同じビット数分符号化する。いくつかの実施形態では、関連を選択するために、入力シンボル数Ｋが符号器によって使用される。例えば、入力がストリームであり、Ｋがストリームにおける各ブロック間で変わり得る場合など、Ｋが前もってわからない場合、Ｋは、単に推定値とすることができる。値Ｋは、入力シンボルにストレージを割り振るために、符号器１１５によって使用することもできる。
【００４０】
符号器１１５は、出力シンボルを送信モジュール１４０に提供し、キージェネレータ１２０は、こうした各出力シンボルのキーを送信モジュール１４０に提供する。送信モジュール１４０は、出力シンボルを送信し、使用されるキーイング方法に応じて、送信モジュール１４０は、送信された出力シンボルのキーについての何らかのデータを、チャネル１４５を介して受信モジュール１５０に送信することもできる。チャネル１４５は、消去チャネルと仮定されるが、これは、通信システム１００の適切な操作のための必要条件ではない。送信モジュール１４０が出力シンボルおよびそのキーについての任意の必要なデータをチャネル１４５に送信するよう構成され、受信モジュール１５０がシンボルおよびそのキーについての潜在的な何らかのデータをチャネル１４５から受信するように構成されている限り、モジュール１４０、１４５および１５０は、任意の適したハードウェア構成要素、ソフトウェア構成要素、物理媒体、またはその任意の組合せとすることができる。Ｋの値は、関連を決定するために使用される場合、チャネル１４５を介して送信することができ、または、符号器１１５および復号器１５５の合意によって前もって設定することができる。
【００４１】
チャネル１４５は、テレビ送信機からテレビ受信機へのインターネットまたはブロードキャストリンクを介したパス、またはある地点から別の地点への電話接続など、リアルタイムチャネルとすることができ、または、チャネル１４５は、ＣＤ−ＲＯＭ、ディスクドライブ、Ｗｅｂサイトなどのストレージチャネルとすることができる。チャネル１４５は、ある人物が入力ファイルを電話回線を介してパーソナルコンピュータからインターネットサービスプロバイダ（ＩＳＰ）に送信し、入力ファイルがＷｅｂサーバに格納され、その後インターネットを介して受信者に送信されるときに形成されるチャネルなど、リアルタイムチャネルおよびストレージチャネルの組合せとすることさえできる。
【００４２】
チャネル１４５がパケットネットワークを備える場合、通信システム１００は、任意の２つ以上のパケットの相対的順序がチャネル１４５を介して送信中に保持されると仮定することができない場合がある。したがって、出力シンボルのキーは、上述したキーイング方式のうちの１つまたは複数を使用して決定され、必ずしも出力シンボルが受信モジュール１５０を出る順序によって決定されるわけではない。
【００４３】
受信モジュール１５０は、出力シンボルを復号器１５５に提供し、これらの出力シンボルのキーについて受信モジュール１５０が受信する任意のデータは、キーリジェネレータ１６０に提供される。キーリジェネレータ１６０は、受信された出力シンボルのキーを再度生成し、これらのキーを復号器１５５に提供する。復号器１５５は、対応する出力シンボルと共に、キーリジェネレータ１６０によって提供されるキーを使用して、入力シンボルを回復する（この場合も、ＩＳ（０），ＩＳ（１），ＩＳ（２），・・・）。復号器１５５は、回復した入力シンボルを入力ファイルリアセンブラ１６５に提供し、これは、入力ファイル１０１のコピー１７０または入力ストリーム１０５のコピー１７５を生成する。
【００４４】
メディアストリーミングの用途
メディアストリーミングの用途で使用するとき、ソースメディアストリームを形成するソースパケットは、時として、ソースブロックと呼ばれるグループに集められる。例えば、ソースブロックは、一定の時間長に及ぶソースパケット群とすることができ、例えば、リードソロモン消去符号は、これらのソースブロックに別々に適用されて、ソースブロックの元のソースパケットと共に、受信機に送信されるリペアパケットを生成することができる。
【００４５】
送信機では、ソースパケットが到着するにつれて、ソースストリームをソースブロックに連続的に分割することができ、ソースブロックごとにリペアパケットが生成され、送信される。時として、特に、ライブまたは対話型のストリーミングの用途の場合、ＦＥＣ符号の使用によって追加された合計エンドツーエンド遅延を最低限に抑えることが好ましく、したがって、ＦＥＣソリューションの設計全体を、送信される前にソースパケットの遅延が送信機でできるだけ小さくなるようにし、１つのソースブロックに対しすべてのソースパケットおよびリペアパケットができるだけ小さい合計遅延で送信されるようにすると好ましい場合もある。また、ＦＥＣ符号化ストリームのレートができるだけスムーズであることが好ましい。すなわち、ＦＥＣ符号化ストリームレートにある変動ができるだけ小さいか、または少なくとも、元のソースストリームにすでに存在する任意の変動の拡大がないことが好ましい。というのは、これによって、ＦＥＣ符号化ストリームの帯域幅の使用量がより予測可能になり、ネットワークおよび場合によっては競合する他のストリームへの影響が最低限に抑えられるからである。また、あるソースブロックについて複数のパケットで送信されたデータが、そのソースブロックについて複数のパケットが送信される期間にわたってできるだけ一様に分配されると好ましい。というのは、これは、バースト損失に対して最適な保護を提供するからである。また、コンテンツザッピング時間およびコンテンツ遷移時間を最低限に抑えるような方法でソースブロックが構築されることも好ましい。また、受信機でのロジックができるだけ簡単であることも好ましい。
【００４６】
受信機で、パケットが失われた、または誤りを含んで（例えば、ＣＲＣ検査を使用して検出し、破棄することができる）受信された場合、十分なリペアパケットが受信されていると仮定して、リペアパケットを使用して、失われたソースパケットを回復することができる。
【００４７】
いくつかの用途では、パケットは、ＦＥＣプロセスが適用される複数のシンボルにさらに細分される。いくつかのＦＥＣ符号、特にリードソロモン符号では、符号化および復号の時間は、ソースブロック当たりの符号化シンボルの数が増えるにつれて増加して非現実的になり、ソースブロック当たり生成することができる符号化シンボルの総数に上限があることが多い。シンボルは、別々のパケットペイロードに入れられるため、これによって、ソースブロックの符号化の最大長に実用上の上限が設けられ、また、当然、ソースブロック自体のサイズにも上限が設けられる。
【００４８】
いくつかの用途では、長い期間にわたって保護が提供されるとき、またはメディアストリーミングレートが高いとき、最大ソースブロックサイズを超えるデータに対する保護を提供することが有利となり得る。これらの場合、最大ソースブロックサイズより短いソースブロックを使用し、次いで、異なるソースブロックからのソースパケットをインターリーブすることは、送信される個々のソースブロックからの複数のソースパケットがより長い期間にわたって分配されるソリューションを提供する。他の用途では、短いコンテンツザッピング時間が望ましく、ソースブロック構造がインターリービング方法とは関係なく決定される場合、コンテンツが受信機によってアクセスされたときは、最初に、より短いソースブロックを使用して、それらを順次的に送信し、次いでコンテンツストリーミングが続くにつれて、ソースブロックの送信をより長い時間間隔にわたって分配するためにインターリービング量を増やして、バースト的損失に対する保護のレベルを増やすことが望ましい。
【００４９】
他の問題は、例えばソースストリーミングレートについていけるほど十分速くソースブロックを復号し、ＦＥＣ復号によってもたらされる復号待ち時間を最低限に抑え、ＦＥＣ復号中の任意の時点で受信装置上の使用可能なＣＰＵのわずかな部分のみを使用することができることである。したがって、各ソースブロックのＦＥＣ復号を時間にわたってできるだけ等しく分配することができるようにし、ＦＥＣ復号待ち時間を最低限に抑えるソースブロックインターリービングを使用することが望ましい。
【００５０】
本明細書に記載された様々な実施形態は、これらの利点のうちの１つまたは複数を提供する。
【００５１】
＜ストリーミングおよびＦＥＣ符号＞
ソースストリームのＦＥＣ保護を提供する目的で、ソースストリームは、１つまたは複数の論理的ストリームの組合せとすることができ、その例には、音声ＲＴＰストリームと映像ＲＴＰストリームとの組合せ、ＭＩＫＥＹストリームとＲＴＰストリームとの組合せ、２つ以上の映像ストリームの組合せ、および制御ＲＴＣＰトラフィックとＲＴＰストリームとの組合せなどがある。ソースストリームが、例えばソースビットストリーム、ソースシンボルストリーム、またはソースパケットストリームのフォーマットで送信機に到着すると、送信機は、該ストリームを複数のソースブロックにバッファリングし、該複数のソースブロックからリペアストリームを生成することができる。送信機は、ソースストリームおよびリペアストリームをスケジューリングし、例えば、パケットネットワークを介して送信されるべきパケットで送信することができる。ＦＥＣ符号化ストリームは、結合されたソースおよびリペアストリームである。ＦＥＣ受信機は、例えば、損失またはビットフリップによって破損された可能性があるＦＥＣ符号化ストリームを受信する。ＦＥＣ受信機は、ソースストリームの元のソースブロックを再構築しようと試み、元のソースストリームをスケジューリングし、受信機で使用できるようにする。
【００５２】
多くの用途の場合、ソースブロック構造は、例えば、ＧＯＰ構造および／またはＨ．２６４ＡＶＣ映像ストリームのフレーム構造など、基礎を成すストリームの構造と共に決定される。これらの用途のいくつかでは、ソースブロック構造は、パケットのストリーム送信順の前に、および／またはパケットのストリーム送信順とは関係なく決定され、この場合、パケットのストリーム送信順は、受信機が、ストリームを受信するために、いつどこでストリームにアクセスするかに依存し得る。こうした用途では、コンテンツザッピング時間およびコンテンツ遷移時間を最低限に抑えることができるようにするために、各ソースブロックがストリームからの連続する１組のソースパケットを備えるように、ソースブロック構造が決定されることが好ましい。
【００５３】
いくつかの用途では、ソースブロック構造の形成およびストリームのＦＥＣ符号化は、ストリームの送信前に行われることが好ましい。この１つの理由は、ストリームが多くの受信機に送信される可能性があり、したがって、ソースブロック構造の形成およびＦＥＣ符号化がすべての受信機について１回行われるからであり、これは、拡張性の利益をいくつか提供する。
【００５４】
ストリーミングの用途では、ソースストリームと、通常最適化することが重要ないくつかの主要メトリクスを保護するためのＦＥＣ符号の使用方法の設計への入力であるいくつかの主要パラメータがある。
【００５５】
ソースブロック構造の設計における１つの可能な主要入力パラメータは、ソースブロック継続時間である。あるソースブロックのソースブロック継続時間は、ソースブロックが順次、すなわち、インターリーブされずに送信され、通常の速度で、すなわち、本質的に通常の再生速度で送信される場合、そのソースブロックから生成されるシンボルが送信されることになる継続時間として定義することができる。あるいは、ソースブロック継続時間は、ソースブロックによって表される映像の再生時間になるように定義することができる。いくつかの場合、これら２つの定義は、一致するが、一致しない場合もある。しかし、簡単にするために、本明細書における説明では、どの定義を意味するかを指定することなく、２つの定義が一致すると簡単に仮定して、ソースブロック継続時間を使用する。２つの定義が一致しない場合でさえ、またソースブロックがその再生レートよりかなり速く送信され得る一部の場合でさえ、本明細書に記載した方法およびプロセスがソースブロック継続時間のいずれかの定義に関することを、当業者であれば認識されよう。さらに、例えば、ソースブロック内のシンボル数、およびソースブロックのシンボルサイズを指定することによって、ソースブロックのサイズまたは再生時間を指定する他の方法があることを、当業者であれば認識されよう。
【００５６】
ソースブロック送信が、いくつかのソースブロックからの複数のパケットの送信と他のいくつかのソースブロックからの複数のパケットの送信をインターリーブするかどうかにかかわらず、ソースブロックの保護期間はソースブロックが送信される期間である。ソースブロックインターリービングが使用されない場合、保護期間は、一般に、ソースブロック継続時間に等しいが、保護期間は、インターリービングが使用されるときのソースブロック継続時間より長く、時として、かなり長い可能性があることに留意されたい。
【００５７】
ソースブロックの保護量は、該ソースブロック内のソースシンボルの数の分数または割合として表される、該ソースブロックで送信されるＦＥＣリペアシンボルの数である。例えば、保護量が２０％であり、ソースブロック内に１０，０００個のソースシンボルがある場合、該ソースブロックから生成されたリペアシンボルは２，０００個ある。保護量は、相対的な概念であり、すなわち、同じソースブロックの保護量は、ソースブロックがどこから送信されるか、およびソースブロックがどこに送信されるかによって変わり得る。例えば、ソースブロックは、保護量５０％で第１のサーバから別のサーバに送信される可能性があり、一方で、同じソースブロックは、保護量１０％で第２のサーバから受信機に送信される可能性がある。
【００５８】
ソースブロック継続時間およびソースブロック当たりの保護量は、ソースブロックによって変わり得る。例えば、ソースブロックが、あるソースストリームのいくつかのソースパケット間にまたがらないことが好ましいとき、例えば、第１のパケットがＭＰＥＧ２ビデオストリームにおけるＧｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ（ＧＯＰ）の最後のパケットであり、第２の連続するパケットが次のＧＯＰの最初のパケットであるとき、ソースブロックは、第１のパケットの後に終了し、新しいソースブロックが第２のパケットで開始することがある。これによって、ＦＥＣ符号化ブロックをビデオ符号化ブロックに揃えることができ、これは、受信機でのビデオバッファリングとＦＥＣバッファリングとの組合せを最低限に抑える可能性のために、受信機待ち時間またはチャネルザッピング時間を最低限に抑えることができるという利点を含めて、多くの利点があり得る。他の用途では、様々な理由のために、連続する各ソースブロックについて、同じソースブロック継続時間および／またはソースブロックサイズを常に維持することが有利であり得る。以下の説明の一部では、簡単にするために、ソースブロック継続時間および保護量は、その後の各ソースブロックについて同じと仮定される。当業者には、本開示を読んだ後、これは、限定的ではないことが明らかであるはずである。というのは、本開示を読むと、保護量またはソースブロック継続時間のいずれか、またはその両方がソースブロックによって変わるとき、およびソースブロックサイズが変わるとき、本明細書に記載されたプロセスおよび方法をどのように適用するかも容易に決定することができるからである。
【００５９】
以降の説明の一部を簡単にするために、ソースシンボルが受信される第１のソースブロックにおいて、ソースシンボル損失がなく、その後の各ソースブロックにおいて、符号化シンボルの損失が、多くてもＦＥＣ復号が成功することを可能にする最大値であることを前提として、時として、元のストリームの複数のソースシンボルが、安定したレートで、ソースブロック形成およびＦＥＣ符号化を行うための送信機に到着し、いったんＦＥＣ受信機が、まず受信機でソースシンボルを使用できるようにすると、その後のソースシンボルは、ＦＥＣ受信機によって、同じ安定したレートで使用可能になると仮定される。この簡素化の仮定は、引き続き説明するプロセスおよび方法の動作または設計に固有ではなく、決してこれらのプロセスをこの仮定に制限するものではなく、単に、プロセスおよび方法の特性の説明の一部を簡単にするためのツールとして導入される。例えば、様々なレートストリームでは、対応する条件は、ソースシンボルが、送信機に到着するのと同じレート、またはそれに近いレートで、ＦＥＣ受信機によって使用可能になることである。いくつかの用途では、コンテンツザッピング時間を最低限に抑えるために、受信機で復号されたソースシンボルをできるだけ早くビデオプレーヤに配信することが好ましく、こうした場合、ソースシンボルは、複数のソースブロックのバーストで配信され得る。いくつかの用途では、ソースブロックの形成、ＦＥＣ符号化、および送信のステップを２つ以上の異なるステップに分けることが望ましい。例えば、後述するように、ソースブロックの形成およびＦＥＣ符号化は、１つのサーバで行うことができ、符号化ストリームは、次いで、複数のサブストリームに分割され、次いで、該複数のサブストリームは、１つまたは複数の分散サーバに送信され、ローカルにキャッシュされ、その後、該複数のサブストリームの一部またはすべては、１つまたは複数の分散サーバのうちのいくつかから受信機に送信される。
【００６０】
最低限に抑えることが重要ないくつかの主要メトリクスは、送信機によってもたらされる待ち時間である送信機待ち時間を含む。送信機待ち時間を最低限に抑えることは、ライブビデオストリーミングなどのいくつかの用途、またはテレビ会議など対話型の用途で望ましい。送信機待ち時間を最低限に抑えるのを助ける総合的な設計の１つの態様は、送信機が、あるストリームの最初のソースブロック（群）の符号化シンボルを連続する順序で受信機に送信することである。送信機待ち時間を最低限に抑える他の設計の態様については後述する。
【００６１】
別の重要なメトリクスは、コンテンツザッピング時間である。図２に示すように、これは、受信機がストリームに加わり、またはストリームを要求したときと、ＦＥＣ受信機が最初にストリームからソースシンボルを使用可能にしたときまでの間の時間である。一般に、例えば、ビデオストリームの再生の場合など、ストリームに受信機が参加したときと、ストリームが最初に受信機で使用可能になり始めたときとの間の時間量を最低限に抑えるため、コンテンツザッピング時間を最低限に抑えることが望ましい。コンテンツザッピング時間を最低限に抑える１つの重要な態様は、送信機が最初のソースブロックの符号化シンボルの元の送信順を維持することであるが、後述するように、コンテンツザッピング時間に大きい影響を与える他の多くの重要な設計態様がある。
【００６２】
コンテンツザッピング時間は、一般に複数の成分を備える。図３Ａおよび図３Ｂに、連続した複数のソースブロックに分割されるストリームについてのこれらの成分の一例が示されており、ここではインターリービングは使用されていない。図３Ａは、保護期間当たりの単一ソースブロックを示し、この例は、ソースブロックの先頭で受信機がストリームに参加する場合を示す。この例では、コンテンツザッピング時間の２つの成分は、保護期間およびＦＥＣ復号待ち時間である。ソースブロックの受信機保護期間は、受信機がソースブロックから受信した符号化シンボルをバッファリングしている時間である。送信機保護期間および受信機保護期間は、送信機と受信機との間のチャネルが、各ビット、バイト、シンボル、パケットが送信機から受信機に移動するためにかかる時間量においてどんな変動も有していない場合、同じであることに留意されたい。したがって、実際には、配信におけるネットワークタイミングの変動のために、送信機保護期間は、同じソースブロックについて、受信機保護期間と異なり得る。
【００６３】
ここでの説明を簡単にするために、送信機保護期間および受信機保護期間は、ソースブロックごとに同じである（および「保護期間」は、送信機保護期間および受信機保護期間について同意語として使用される）と仮定するが、これは、常にそうでならなければいけないというわけではない。言い換えれば、ネットワーク配信時間がすべてのデータについて同じであるという仮定がある。当業者であれば、本開示を読んだ後、ネットワーク配信の変動のために、送信機保護期間と受信機保護期間との差を考慮に入れるために、必要な変更を、本明細書に記載した方法および装置に加えることができる。
【００６４】
コンテンツザッピング時間の保護期間成分は、不可避である。というのは、第１のソースブロックにおいて、任意のソースシンボルの損失がない場合でさえ、その後のソースブロックにおける符号化シンボルの損失があるとき、すべてのその後のソースシンボルのスムーズなソースシンボルの配信を確実にするために、少なくとも保護期間の間、ソースシンボルを使用可能にするのを送らせる必要が依然としてあるからである。保護期間中、ソースブロックのＦＥＣ復号の一部、ほとんど、またはすべては、符号化シンボルの受信と同時に起こり得る。保護期間の最後に、ソースブロックの第１のソースシンボルがＦＥＣ受信機から使用可能になる前に起こる追加のＦＥＣ復号がある可能性があり、この期間は、図３Ａにおいて、ＦＥＣ復号待ち時間と表記されている。さらに、第１のソースシンボルが使用可能になった後でさえ、ソースブロックの第２のソースシンボルおよびその後のソースシンボルが使用可能になる前に行われる追加のＦＥＣ復号があり得る。簡単にするために、この追加のＦＥＣ復号は、図３Ａには示されておらず、この例では、第１のものの後のすべてのソースシンボルを十分速いレートで復号するのに十分使用可能なＣＰＵリソースがあると仮定する。
【００６５】
コンテンツザッピング時間の別の可能な成分は、受信機がストリームに加わることを要求したときと、そのストリームの第１のパケットが受信機に到着したときとの間の時間とすることができる。この時間量は、可変であり、受信機と、そのストリームのパケットの１つまたは複数の送信機との間の往復時間に依存し得る。コンテンツザッピング時間のこの成分は、本明細書には詳しく記載されていないが、時として、これは、考慮されるべきコンテンツザッピング時間の重要な誘因であり得ること、およびコンテンツザッピング時間のこの潜在的な誘因を考慮に入れるために、本明細書に記載した方法およびプロセスを容易に変更できることを当業者であれば認識されよう。
【００６６】
図３Ｂは、図３Ａに示される例に対応し得る２つの潜在的なＦＥＣ復号のＣＰＵ使用率曲線を示す。図３Ｂに示される２つの曲線のうちの１つにおいて、ＦＥＣ復号に使用されるＣＰＵ使用率は、各時点において同じであり、すなわち、ＣＰＵ使用率は、一様に分散される。各時点で同じ量のＣＰＵリソースを予測的に使用し、ソースブロック全体を復号するのに、同じ量の総ＣＰＵリソースが必要とされると仮定して、最大ＣＰＵリソースを最低限に抑えるため、これは、望ましいＣＰＵ使用率曲線である。図３Ｂに示した２つの曲線のうちの他方では、ＦＥＣ復号に使用されるＣＰＵ使用率は、各時点で同じではなく、特に、ソースブロックの符号化シンボルの受信の最後に向かう、およびその直後でのＣＰＵ使用率は、他の時点よりかなり高い。ＣＰＵリソース使用量が、他のプロセス、例えばビデオプレーヤなどもＣＰＵに負担をかける時点であり得るある時点でスパイクし、したがって、例えば、映像ストリームの再生におけるトラブルをもたらす可能性を引き起こすため、これは、望ましいＣＰＵ使用率曲線ではない。したがって、ストリームを保護するＦＥＣソリューションの設計は、ＦＥＣ復号器ができるだけ時間にわたってスムーズで一様にＣＰＵを使用するソリューションを提供することである。一例として、設計基準は、符号化シンボル損失の最悪の場合のパターン下のＦＥＣ復号プロセスにおいて、任意の時点の最大ＣＰＵ使用率がある閾値を下回ること、例えば、各１００ミリ秒の間隔にわたってＣＰＵの多くて１０％を使用することであり得る。
【００６７】
いくつかのストリーミングの用途では、受信機がソースブロックの途中でストリームに加わってしまった場合、元の送信順およびソースパケットの配信速度が最初に送信機によって維持される限り、コンテンツザッピング時間は、ソースブロック継続時間と、その第１の部分的ソースブロックからのソースシンボルの損失がないときの復号待ち時間とを加算したのと同じほど小さくなり得る。他のビデオストリーミングの用途では、送信機は常に、ＧＯＰの先頭から受信機にストリームを送信し始め、この場合、ソースブロックの先頭は、ＧＯＰの先頭に揃えられることが好ましい。したがって、コンテンツザッピング遅延を最低限に抑えるために、送信機が、最初のソースブロックのソースシンボルの元の送信順を維持することが望ましい。
【００６８】
ＦＥＣエンドツーエンド待ち時間を最低限に抑えるために、ＦＥＣストリーミングソリューションを使用することもできる。ＦＥＣエンドツーエンド待ち時間は、ライブストリーミングの用途の場合、ソースパケットがＦＥＣ符号化の適用前に送信機でのストリーミングの用意ができているときと、ＦＥＣ復号の適用後、受信側での再生に使用可能であるときとの間にＦＥＣの使用によってもたらされる最悪の場合の全待ち時間である。オンデマンドのストリーミングまたはプレイリストコンテンツストリーミングなど、他のタイプのストリーミングの用途の場合、ＦＥＣエンドツーエンド待ち時間は、大きな問題ではない。
【００６９】
すべてのタイプのストリーミングの用途では、コンテンツザッピング時間およびコンテンツ遷移時間を最低限に抑えることが重要である。同時に、ストリームの送信レートを最低限に抑えること、すなわち、コンテンツザッピング中およびコンテンツ遷移中も含めて、常に送信レートを制約して、コンテンツストリーミングレートをほんのわずか上回るようにすることが重要である。
【００７０】
ＦＥＣストリーミングソリューションは、ＦＥＣが使用されるとき、送信レートの変動を最低限に抑えるために使用することもできる。この１つの利点は、パケットネットワーク内で、ストリームの送信レートのピークと他のトラフィックのピークとが、制限された容量のネットワークにおける地点で一致するとき、送信レートが変動するストリームが、輻輳またはバッファオーバーフローが原因のパケット損失をより受けやすいことである。少なくとも、ＦＥＣ符号化ストリームのレートの変動は、元のソースストリームのレートの変動より悪くないものとし、より多くのＦＥＣ保護が元のソースストリームに適用されると、ＦＥＣ符号化ストリームのレートの変動がより小さくなることが好ましい。特別な場合として、元のストリームが一定のレートで送信する場合、ＦＥＣ符号化ストリームができるだけ定数に近いレートで送信されることが好ましい。
【００７１】
その後の各ソースブロックの最後の符号化シンボルが受信されるときが時間にわたってできるだけ一様に分配されるという特性は、望ましい特性である。あるソースブロックの最後の符号化シンボルが受信されたときは、ソースブロックの復号についてのすべての情報がＦＥＣ復号器から使用可能であるときであり、これは、一般に、ＦＥＣ復号器が所定の復号待ち時間バジェット内で復号を終えるために、最も激しく働く必要があるという最悪の場合の損失条件下のときである。したがって、ソースブロックの最後の符号化シンボルの受信を一様に分配することによって、ＦＥＣ復号のためのＣＰＵの使用をスムーズにすることができる。
【００７２】
ＦＥＣストリーミングソリューションは、ＦＥＣ受信機でできるだけ簡単なロジックを提供するものとする。ＦＥＣ受信機を、制限された計算、メモリ、および他のリソース機能を備える装置に構築することができるため、これは、多くの状況で重要である。さらに、いくつかの場合、伝送時にシンボルのかなりの損失または破損がある可能性があり、したがって、ＦＥＣ受信機は、条件が向上したとき、ストリームの受信が続く場所を理解するためのコンテキストがほとんどあるいはまったくない、破局的損失または破損シナリオから回復しなければならない場合がある。したがって、ＦＥＣ受信機ロジックが簡単で頑強であればあるほど、ＦＥＣ受信機は、迅速かつ確実に、回復を開始し、ＦＥＣ符号化ストリームの受信からソースストリームのソースシンボルを再度使用可能にすることができる。
【００７３】
ソースブロックのリペアパケットを送信するのは、ソースブロックのソースパケット前、後、または混合のいずれでもよく、本明細書で説明するように、それぞれの戦略に利点がある。
【００７４】
ＦＥＣストリーミングソリューションの包括的な望ましい特徴のうちの一部は、以下を含む。
【００７５】
１．短いコンテンツザッピング時間。
【００７６】
２．短いコンテンツ遷移時間。
【００７７】
３．常に送信ストリームレートを制約して、すなわち、コンテンツストリームレートをほんのわずか上回るようにするものとする。
【００７８】
４．送信ストリームレートは、スムーズであるものとし、少なくともコンテンツストリームレートと同じぐらいスムーズであるものとする。
【００７９】
５．ＦＥＣ符号化が使用されるとき、ソースブロックの形成およびＦＥＣ符号化を、あるストリームに実行することができ、同じ符号化ストリームを、場合によっては異なる時に多くの受信機に送信することができる。
【００８０】
６．ＦＥＣ符号化が使用されるとき、特に、損失が本質的に多少バースト的であるとき、必要な最低限の保護量を有する小さいソースブロック継続時間を使用して、パケット損失に対する保護を高いものとする。
【００８１】
７．ＦＥＣ符号化が使用されるとき、複数のソースブロックは、１つのストリームの隣接した部分を含むものとする。
【００８２】
８．ライブストリーミングの用途のＦＥＣ符号化のとき、ＦＥＣエンドツーエンド待ち時間は、小さいものとする。
【００８３】
９．ＦＥＣ符号化が使用されるとき、ＦＥＣ復号は、ＣＰＵ使用率をスムーズに分配するものとする。
【００８４】
＜ＦＥＣ符号化ストリームの基本的な送信＞
本セクションでは、送信機が、ＦＥＣ符号化することができるストリームのパケットの送信の時間を決める基本的な方法およびプロセスを説明する。ｋをソースブロックにおけるソースシンボルの数とし、Ｔをそのソースブロックについてのソースブロック継続時間とし、ｐを分数として表される保護量とすると、そのソースブロックについて、ｐ＊ｋ個のリペアシンボルが送信される。ｋ、Ｔおよびｐの値は、各ソースブロックが形成されているときに、動的に決定することができ、したがって、そのソースブロックのソースシンボルのほとんどまたはすべてがプロセスに到着したとき、ソースブロックのｋおよびＴの値は、ソースブロックの形成プロセスのみに知られるようにし、ｐの値は、ソースブロックのすべてのソースシンボルがソースブロック形成プロセスに到着した後、または個別のプロセスによって決定することができる。また、ソースブロック形成プロセスは、異なるソースブロックごとにシンボルサイズを変え得る。したがって、特定のソースブロックのこれらのパラメータの多くまたはすべては、そのソースブロックのデータを受信中のソースブロック形成プロセスに知られている可能性がある。
【００８５】
以下のプロセスでは、インターリービングを使用しない基本的な送信機について説明する。簡単にするために、この基本的な送信機について、ソースブロック形成プロセスがストリームにすでに適用されており、それが連続するソースブロックに分割されており、こうしたソースブロックの各個がｋ個のソースシンボルを含み、Ｔ秒のソースブロック継続時間で、こうしたソースブロックごとに、ｐ＊ｋ個のリペアシンボルがすでに生成されていると仮定する。
【００８６】
受信機がストリームを特定のソースブロックからの開始を要求する（または受信機からの明示的な開始要求によってストリームを先行送信させる）と、基本的な送信機は、Ｔ秒の期間にわたって、要求されたソースブロックの（１＋ｐ）＊ｋ個の符号化シンボルの送信を開始し、その後、要求されたソースブロックの後、次のソースブロックの符号化シンボルを送信する、といった具合である。
【００８７】
基本的な送信機は、以下の特性を有する。
【００８８】
１．保護期間はＴであり、これは、ソースブロック継続時間と同じである。
【００８９】
２．送信されたソースブロックのシンボルは、Ｔ秒の期間にわたって一様に分配される。これは、一定の継続時間のバースト停止（burst outage）があるとき、損失に対して提供される保護のレベルは、シンボルの送信中に停止が起こるときに依存しないことを含意し、これは望ましい。
【００９０】
３．送信機は、シンボルの全体的な送信レートの変動をもたらさない。特に、ソースシンボルの元の送信レートが一定である場合、すべてのシンボルの送信レートは、依然として一定であり、送信機でのソースシンボルの元の到着レートが可変であるとき、少なくともソースブロック当たりのシンボルの一定の送信レートが変動を減衰させる。これは、望ましい特性である。
【００９１】
４．コンテンツザッピング時間は、Ｔと同じぐらい小さくすることができる。これは、（すべてのソースブロックがｋ個のソースシンボルを含むと仮定すると）（１＋ｐ）＊ｋ個のシンボルの最低バッファリングを含意し、これは、所与の保護期間について可能な最低値であり、したがって望ましい。
【００９２】
基本的な送信機が有する１つの特性は、コンテンツザッピング時間は、少なくとも１保護期間分の時間であり、保護期間は、バースト的損失に対する保護の品質に直接関係するということである。したがって、保護期間とコンテンツザッピング時間との間で行う必要がある妥協がある場合がある。例えば、１秒未満のコンテンツザッピング時間を有することが望ましく、一方で、一時的なネットワーク停止、または数１０あるいは数１００ミリ秒程度、およびいくつかの場合では数秒続く可能性がある、バースト的パケット損失をもたらす他のタイプの断続的なネットワーク問題に対してより良い保護を提供するために、数秒にまたがる保護期間を有すると共に、同時に１０％などの適度に小さい保護量を使用することも望ましい。コンテンツザッピング時間よりかなり大きい保護期間を有することができることが望ましく、これは、次のセクションで説明するインターリービング方法が提供する多くの利点のうちの１つである。
【００９３】
＜ストリームインターリービング＞
このセクションでは、データのストリームをとり、送信プロセスで、ある部分が他の部分より多く遅延するように、差分時間遅延をデータストリームの異なる部分に適用するための新規の方法およびプロセスについて説明する。これらの方法およびプロセスのうちのより重要な態様のうちの１つは、データストリームが送信されるときに、ストリームの異なる部分に含まれる遅延の量を動的に調整するための手段である。
【００９４】
コンテンツザッピング時間を最低限に抑え、ストリームのより良い保護を提供するために、ソースブロックをＧｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ（ＧＯＰ）構造またはビデオストリームの他のフレーム構造に揃えることがしばしば好ましい。いくつかの用途では、インターリービングプロセスが、ソースブロック形成プロセスとは関係なく、場合によっては、異なる時間に行われる、または場合によっては、異なる場所で行われることができることが望ましい。いくつかの場合、例えばＦＥＣ符号化が使用されないために、たとえソースブロック形成プロセスが使用されなくても、例えば、ストリームを介してバースト的誤りをより均等に分配するために、場合によっては、インターリービングプロセスが望ましい。当業者であれば認識されるように、本明細書に記載した方法は、ソースブロック形成およびＦＥＣ符号化が使用されないときでさえも適用される。
【００９５】
いくつかの場合、各ソースブロックのシンボルをソースブロック継続時間より長い保護期間にわたって分配することができるように、送信機が異なるソースブロックからシンボルの送信をインターリーブするのを可能にするための利点があり得る。これを行う１つの理由は、時間に依存した損失（例えば、バースト的損失）に対して、より良い保護が提供されるからであり、すなわち、ソースブロックの保護期間が大きくなるにつれて、一定の継続時間のバースト損失に対して保護を提供するのに、より小さい保護量が必要とされるからである。ソースブロック継続時間は、ｔ秒とすることができ、ソースブロックの望ましい保護期間は、ｐ秒とすることができ、この場合、ｐ＞＞ｔである。インターリービングを使用する送信機の他の望ましい特性は、以下を含む。（１）ソースパケットがソースブロック内の元の順で送信される、（２）その後の各ソースブロックの最後の符号化シンボルが受信される時間は、時間にわたってできるだけ一様に分配される。
【００９６】
ＦＥＣ符号化が使用されるとき、ソースブロックの符号化シンボルの送信を静的にインターリーブする方法が導入され、ストリームが送信されるにつれてインターリービングの量を動的に調整する方法が導入され、一般には、ストリームの送信の開始時にはインターリービングがほとんどあるいはまったくなく、したがって、ソースブロック継続時間とほぼ同じ保護期間で、ストリームの送信が進むにつれて、ますます多くのインターリービングがスムーズに導入され、したがって、保護期間は、ソースブロック継続時間よりかなり長くなるまで増大する。これによって、コンテンツザッピング時間を、受信機で最低限に抑えると共に、送信が進むにつれてバースト的損失または破損に対する保護をますます増やすことができる。記載した方法の他の利点は、ストリームの送信が進むにつれて、ますます多くのネットワークジッタに対して徐々に保護を行うことができることである。
【００９７】
以下の説明を簡単にするために、ストリームの送信前にソースブロック形成およびＦＥＣ符号化プロセスが行われると仮定する。これは、方法の限定ではなく、当業者であれば認識されるように、ソースブロックを形成し、これらのソースブロックにＦＥＣ符号化を実行し、後述するようにストリームを送信するプロセスは、同時に行うことができ、一部の場合、これは、有利である。さらに、いくつかの用途では、ソースブロック形成、ＦＥＣ符号化プロセス、およびストリームのインターリーブ式の送信について後述する方法は、動的に独立していてよく、すなわち、ソースブロックがどのように形成され、ＦＥＣ符号化されるかは、いくつかの場合、送信ストリーム戦略に依存し得る。
【００９８】
＜ストリーム送信のテープ（tape）方法＞
新しいインターリービング方法を説明するために、以下のストリーム送信のテープ方法を述べることが有用である。図４は、ソースブロック構造がすでに決定されているコンテンツストリームの例示的な図である。各ソースブロック４０５（１），４０５（２），・・・について、幅４１０（１），４１０（２），・・・は、そのソースブロックのコンテンツ再生継続時間を示し、各ソースブロックの高さ４１５（１），４１５（２）は、各コンテンツストリームソースブロックの平均再生レートを示し、この例では、異なるソースブロックは、異なる再生レートを有する。
【００９９】
図５は、図４に対応する符号化ブロック構造を示しており、すなわち、ＦＥＣ符号化が各ソースブロックに適用されて、ソースブロックごとに追加のリペアデータ５１０（１），５１０（２），・・・を生成し、符号化ブロックを形成する。５１０（１），５１０（２），・・・の高さ５１５（１），５１５（２），・・・は、各符号化ブロックにおけるソースブロックごとに生成された追加のリペアデータの量を示し、すなわち、対応するソースブロックと同じ継続時間にわたって符号化ブロックが送信される場合、高さは、符号化ソースブロックの平均送信レートを示す。この図は、例示にすぎず、これに限定するものではなく、例えば、符号化ブロックごとに生成されたリペアデータの量は、符号化ブロックごとに送信された量よりかなり大きくてもよく、符号化ブロックごとに送信された量は、受信機によって変わり得る。さらに、図５は、符号化ソースブロック内のソースシンボルおよびリペアシンボルの順序の表示を示唆するものではない。
【０１００】
図６は、基本的な送信機の方法に対応する受信機によるコンテンツザッピング時間経験を示す例示的な図である。コンテンツザッピング時間６０５の複数の成分のいくつかは、受信機が、第１のソースブロックを復号するのに十分なだけ、ストリームの第１の符号化ブロックを受信するためにかかる時間６１０、受信機が第１の符号化ブロック６２０の受信された部分から第１のソースブロックを復号するためにかかる時間、およびネットワークジッタ、ソースブロック継続時間の変動、およびストリームの受信中に受信された符号化ブロックの部分からのソースブロックの復号時間を吸収するために確保される予備バッファ時間６３０を含む。
【０１０１】
ストリームを送信するテープ方法について説明しており、類似の方法を生成する同等の説明や、本明細書に記載される方法の変形を生成するこの説明の変形が多く存在することを当業者であれば認識されよう。図７は、図５に示される符号化ブロック構造に対応するテープ方法の一例を示す。該テープ方法において、データのストリームの送信は、ストリームがテープ７０５として送信されることを表すことによって示され、ここでは、テープのＸ軸に沿った各位置７１０が符号化ブロック構造における異なる時点に対応し、テープの高さは、常に同じであり、例えば、テープに沿ったその時点での符号化ソースブロックのレートに関係なく、名目上高さ１など、常に同じである。テープによって表されるストリームの送信は、テープの最上部７２５からテープの最下部７３０に至る移動線７２０（１），７２０（２）によって示すことができる。一表現において、時間にわたる線７２０（１），７２０（２）の移動は、ストリームの符号化ブロックからのデータの送信順を表す。テープ内の各点７４０（１），７４０（２），・・・は、送信すべきストリームデータ片を表し、例えば、各点は、符号化ブロックの符号化シンボルのパケットを表し、または各点は、符号化ブロックの個々の符号化シンボルを表し得る。符号化ブロック７５０（１），７５０（２），・・・に対応する領域内に含まれる点は、その符号化ブロックに関連付けられるデータを表す。
【０１０２】
ストリームを送信するテープ方法による送信のプロセスは、ストリームが送信されるにつれて、時間にわたってテープを横切って線７２０（１），７２０（２）をスィープ（sweep）することによって表され、線が点をスィープするたびに、その点に対応するストリームのデータが送信される。図７は、送信プロセスにおける異なる２つの時点での線を示し、線７２０（１）は、第１の時刻におけるその構成であり、線７２０（２）は、第２の時刻におけるその構成である。したがって、送信プロセスは、第１の時刻と第２の時刻との間の時間間隔中、７２０（１），７２０（２）、７２５および７３０によって囲まれた領域内の点に関連付けられているすべてのデータを送信する。各符号化ブロック内の点の分散は、その重さに従って、その符号化ブロックについて、テープエリア内で一様に分散されることが好ましく、例えば、ランダムに分散される、または疑似ランダムに分散される、または点の重さがその点によって表されるデータの量である場合、各点の重さに従って点が一様に分散されることを確実にするプロセスによって決定論的に分散される。
【０１０３】
上述したように、線７２０は、直線であるが、当業者であれば認識するように、多くの変形があり、例えば、線は、曲線でもよく、または連続する線セグメント系列を備えていてもよい。また、線は、送信プロセス中に横切ってスィープするとき、その形状を変えてもよい。テープ送信方法は他にもいくつかの変形があり、そのなかには、変形テープが同じ高さのものではなく、代わりに、その高さは、テープのその位置７１０でのストリームのレートに従って変わるようにテープを表すことを含む。
【０１０４】
以下で詳述されるように、送信プロセス中、テープにわたる線の移動を指定する様々な方法がある。
【０１０５】
＜静的インターリービング方法＞
ストリームを送信するテープ方法は、ＦＥＣ符号化が使用されるかどうかにかかわらず、またソースブロック構造が使用されるかどうかにかかわらず、任意のタイプのコンテンツストリームまたは符号化コンテンツストリームについて、任意の深さの静的インターリービングを達成するために使用することができる。説明上、ソースブロック構造は、すでに定義されており、ＦＥＣ符号化が使用されると仮定する。
【０１０６】
ストリームを送信するテープ方法を使用した所与の量の静的インターリービングを達成する１つの方法について、一例により図７を参照して説明する。この例では、各符号化ブロックは、時間量Ｄごとに他の隣接する符号化ブロックでインターリーブされ、すなわち、インターリービング深さはＤである。この例では、ストリームを要求するとき、受信機は、位置ＸおよびＤの値を伝える。次いで、送信機での送信プロセスは、最初に線７２０とテープの最下部７３０とが位置Ｘ−Ｄで交差し、最初に線７２０とテープの最上部７２５とが位置Ｘで交差するように線７２０を構成し、次いで、送信プロセスが、ストリームの再生レートと同じレートで、時間を順方向に線７２０をスィープする、すなわち、送信プロセス開始後の時刻ｔで、線７２０とテープの最下部７３０とが位置Ｘ−Ｄ＋ｔで交差し、線７２０とテープの最上部７２５とが位置Ｘ＋ｔで交差するように、線７２０が横切ってスィープしていることによって説明される。
【０１０７】
静的インターリービング方法のこの説明において、新しく要求されたストリームを受信機に送信するために該方法が使用されている場合、ストリームにおいて、受信機で再生が開始する位置にＸがあることが有利であり、例えば、Ｘは、符号化ブロックの先頭の位置、またはＸは、ビデオストリームにおけるＧＯＰの先頭の位置であり、符号化ブロックの先頭は、ＧＯＰの先頭に揃えられる。さらに、こうした場合、一般に、受信機は、符号化ブロックのある一部分のみを受信し、部分的に受信された符号化ブロックを完全に復号するのに十分ではない可能性が高いため、送信機が、テープに沿って位置Ｘの前に、受信機に任意のデータを送信しないことが有利である。
【０１０８】
図８は、送信機が先に説明した静的インターリービング方法を使用しているとき、送信されたストリームの形状を例示する例示的な図である。この場合、静的インターリービング方法は、図５に示された符号化ストリームに対応する、図７に示されるテープに適用される。この例では、受信機は、Ｘの値を、図７における第１の符号化ブロック７５０（１）の開始の位置と指定し、したがって、この例では、位置Ｘの前に、テープに沿って送信されるべきデータはない。この例では、受信機は、Ｄの値も指定し、これは、１０秒などの値とすることができる。このプロセスに従って送信機によって送信された結果として得られたストリームは、図８に示され、この場合、８５０（１），８５０（２），・・・のエリアは、それぞれ図５の４０５（１）＋５１０（１）、４０５（２）＋５１０（２），・・・などのエリアと同じである。図８に示すような送信レートは、図５に示すような元のコンテンツレートの平滑化されたバージョンであることに留意されたい。
【０１０９】
図９は、上述した静的インターリービング方法に対応する受信機によって経験されるコンテンツザッピング時間を示す例示的な図である。コンテンツザッピング時間９０５の成分の一部は、受信機が、第１のソースブロックを復号するのに十分なだけストリームの第１の符号化ブロックを受信するためにかかる時間であって、ソースブロック継続時間とインターリービング深さＤとの合計である時間９１０、受信機が第１の符号化ブロック９２０の受信された部分から第１のソースブロックを復号するためにかかる時間、および予想されるネットワークジッタ遅延、ソースブロック継続時間の変動、およびストリームの受信中に受信された符号化ブロックの部分からのソースブロックの復号時間のために確保される予備バッファ時間９３０を含む。保護期間は、この場合、ソースブロック継続時間＋インターリービング深さＤであり、ソースブロック継続時間よりかなり大きくなり得るため、コンテンツザッピング時間９０５は、記載したように、この方法を使用すると、ソースブロック継続時間よりかなり大きくなり得ることに留意されたい。
【０１１０】
＜動的インターリービング方法＞
ストリームを送信するテープ方法は、ＦＥＣ符号化が使用されるかどうかにかかわらず、またソースブロック構造が使用されるかどうかにかかわらず、任意のタイプのコンテンツストリームまたは符号化コンテンツストリームについて、任意のペースの任意のインターリービング深さで、動的インターリービングを達成するために使用することができる。説明上、ソースブロック構造は、すでに定義されており、ＦＥＣ符号化が使用されると仮定する。
【０１１１】
ストリームを送信するテープ方法を使用し、インターリービング無しで開始して、所与のインターリービング深さまで進む動的インターリービングを達成する１つの方法について、一例を図７を参照して説明する。この方法の一般的な使用では、第１の符号化ブロックは、わずかのインターリービングで送信され、次いで、インターリービング深さＤが達成されるまで、徐々に、時間が経つにつれて、他の隣接する符号化ブロックでその後の符号化ブロックがますますスムーズにインターリーブされる。しかし、この方法の他の使用についても、以下で説明し、当業者であれば認識されるように、他の様々な変形もある。方法のパラメータを表すこの例の方法では、ストリームを要求すると、受信機は、線７２０についての最初の上部位置ＵＩ、線７２０についての最初の下部位置ＬＩ、線７２０についての最後の上部位置ＵＦ、線７２０についての最後の下部位置ＬＦ、および時間値Ｔを伝える。簡単にするために、以下、ＵＦ≧ＵＩ、ＬＦ≧ＬＩ、ＵＦ≧ＬＦ、ＵＩ≧ＬＩ、Ｔ≧０と仮定する。一般に、必要に応じて受信機でのデータが常に使用可能であることを確実にするのを助けるために、ＵＦ≧ＵＩ＋ＴおよびＬＦ≧ＬＩ＋Ｔであることが好ましい。以下、この例で説明するように、ＵＦ、ＵＩ、ＬＦ、ＬＩ、およびＴのこれらの値は、インターリービングが動的に調整されるにつれて、コンテンツの予備バッファを受信機でスムーズに増加することができるようにする。
【０１１２】
送信機での送信方法は、パラメータＬＩ、ＵＩ、ＬＦ、ＵＦ、およびＴを使用して以下のようにテープ方法を実行する。まず、図７の線７２０は、最初に送信時刻ｔ＝０で、最初に線７２０とテープの最下部７３０とが位置ＬＩで交差し、最初に線７２０とテープの最上部７２５とが位置ＵＩで交差し、次いで、送信時刻ｔ＝０からｔ＝Ｔまでの間、時刻ｔで、線７２０とテープの最下部７３０とが位置ｔ＊（ＬＦ−ＬＩ）／Ｔ＋ＬＩで交差し、時刻ｔで、線７２０とテープの最上部７２５とが位置ｔ＊（ＵＦ−ＵＩ）／Ｔ＋ＵＩで交差するように、線７２０がテープを横切ってスィープされるように構成される。次いで、送信時刻ｔ＞Ｔのすべてにおいて、時刻ｔで、線７２０とテープの最下部７３０とが位置ｔ−Ｔ＋ＬＦで交差し、時刻ｔで、線７２０とテープの最上部７２５とが位置ｔ−Ｔ＋ＵＦで交差するように、線７２０がテープを横切ってスィープされ、すなわち、ｔ＞Ｔの場合、インターリービングは、静的であり、Ｄ＝ＵＦ−ＬＦのインターリービング深さが使用される。
【０１１３】
＜新しく要求されたストリームについての動的インターリービング方法＞
動的インターリービング方法の一使用例は、受信機に新しく要求されたストリームを送信することである。一例として、図１０に示されるように、初期値はすべて、同じ値Ｉ＝ＵＩ＝ＬＩに設定することができ、すなわち、最初は、インターリービングがなく、受信機がコンテンツストリームを再生し始める位置Ｓは、Ｓ＝Ｉを満たす。これにより、位置Ｓ以降のコンテンツの全テープが受信機に送信されたことが確実になる。図１０に示されるように、好ましくは、Ｓ＝ＵＩ＝ＬＩであり、この場合Ｓは、それが再生され得るコンテンツストリームにおける位置であり、例えば、Ｓは、その開始がＧＯＰの開始に揃えられる符号化ブロックの開始である。さらに、Ｔ≦ＬＦ−Ｓであることが有利である。これにより確実になるのは、受信機がコンテンツレートでコンテンツを再生する場合、コンテンツの送信が、少なくとも受信機でのコンテンツの再生と同じ速さのレートでのものであり、Ｒ＝ＬＦ−Ｓ−Ｔ秒の予備バッファ時間がスムーズに増加し、受信機への送信開始から送信時刻Ｔで静的インターリービングに到達するにつれて続き、この場合、予備バッファは、ネットワークジッタ、変化するソースブロック継続時間、および復号時間を吸収することができることである。インターリービング量は、インターリービング無しからＤ＝ＵＦ−ＬＦ秒のインターリービングまで、スムーズに増加する。
【０１１４】
動的インターリービング方法の特定の例として、受信機がごく最初からコンテンツにアクセスしており、定常状態で、５秒の予備バッファに到達し、定常状態で１０秒のインターリービング深さが望まれ、送信のレートは、インターリービングおよび予備バッファが増加している期間中、符号化ストリームレートの約１０％以上と仮定する。次いで、パラメータの可能な設定は、所望の開始位置であるＳ＝ＵＩ＝ＬＩ、Ｔ＝１００秒、ＬＦ＝Ｓ＋Ｔ＋５秒、およびＵＦ＝ＬＦ＋１０秒である。したがって、この例で、コンテンツストリームレートが１Ｍｂｐｓであり、１０％の保護量が使用される場合、符号化ストリームレートは、１．１Ｍｂｐｓとなる。次いで、ストリームの１００＋（５＋１５）／２＝１１０秒が最初の１００秒内で送信されるため、前に説明したパラメータ設定を使用した動的インターリービング方法を使用した送信の最初の１００秒間、送信レートは、約１．２１Ｍｂｐｓとなる。１００秒の送信の後、予備バッファは、５秒、インターリービング深さは、１０となり、次いで、送信レートは、その後、１．１Ｍｂｐｓとなることになる。１００秒のストリーミングが行われる直前の２、３秒の間、送信レートは、１．２１Ｍｂｐｓレートから１．１Ｍｂｐｓレートにスムーズに遷移する。最初に、送信レートは、符号化ストリームレートに従い、インターリービング深さおよび予備バッファがスムーズに増えるにつれて、送信レートは、平滑化され、ますます厳密に平均符号化ストリームレートと一致するようになることにも留意されたい。
【０１１５】
上述した動的インターリービング方法に対応する受信機によって経験されるコンテンツザッピング時間について、図１１を参照して説明する。コンテンツザッピング時間１１０５の成分の一部は、受信機が第１のソースブロックを復号するのに十分なだけ、ストリームの第１の符号化ブロックを受信するためにかかる時間１１１０、受信機が第１の符号化ブロック１１２０の受信された部分から第１のソースブロックを復号するためにかかる時間、および予想されるネットワークジッタ遅延、ソースブロック継続時間の変動、およびストリームの受信中に受信された符号化ブロックの部分からのソースブロックの復号時間のために確保される初期予備バッファ時間１１３０を含む。
【０１１６】
動的インターリービングを使用するとき、予備バッファは時間が経つにつれて増加するため、動的インターリービングを使用するとき、初期予備バッファ時間１１３０は、ストリーム送信の全継続時間の間、予備バッファサイズが固定される場合よりかなり短くなり得る。例えば、基本的なストリーム送信機を使用すると、最高２秒までの長期ネットワークジッタに対してバッファリングするために、予備バッファサイズは、２秒に設定することができる。一方、動的インターリービング式の送信方法では、ストリーム送信の最初の２、３秒の間、ネットワークジッタがわずかである可能性があり、その時点では、予備バッファは、かなり増加しているため、初期予備バッファ時間１１３０は、例えば２００ミリ秒など、かなり短い何らかの値に設定することができる。
【０１１７】
動的インターリービングを使用したとき、各ソースブロックの保護期間が徐々に増加するため、初期ソースブロック継続時間は、動的インターリービングを使用したとき、保護期間がストリーム送信の全継続時間の間そのソースブロック継続時間であるときよりかなり短くなり得る。例えば、基本的なストリーム送信機を使用すると、ソースブロック継続時間は、５秒に設定することができ、保護量は、５００ミリ秒の短いバースト的パケット損失から保護するために、２０％に設定することができる。一方、動的インターリーブ式の送信方法では、ソースブロック継続時間は、約５００ミリ秒など、かなり短い何らかの値に設定することができ、保護量は、こうしたバーストに対する同じレベルの保護を提供するために、約５％など、かなり小さい値に設定することができる。というのは、ストリームを送信する最初の２、３秒の間、こうしたバーストが起こる可能性は低く、その時点では、保護期間は、こうしたバーストから保護するために、実質的に、例えば、元のソースブロック継続時間＋１０秒のインターリービング深さまで増加している。
【０１１８】
したがって、全体的に、動的インターリービング方法を使用すると、例えば、１秒未満のコンテンツザッピング時間など、コンテンツザッピング時間は短くてよく、これに対して、同じネットワーク条件において、基本的なストリーム送信方法を使用すると、数秒であり、さらに、動的インターリービング方法は、ネットワークジッタおよびバースト的パケット損失に対して優れた長期保護を提供することができる。
【０１１９】
パラメータの指定方法には多くの変形がある。例えば、テープにおける初期開始位置を指定する代わりに、インターリービングの初期量、インターリービングの最後の量、および初期インターリービングから最後のインターリービングまでスムーズに遷移する期間を指定することができる。あるいは、初期インターリービングから最後のインターリービングまでスムーズに遷移する期間を指定する代わりに、遷移を行うためのコンテンツストリームレートに対するレートを指定することができる。変形の別の例として、追加のパラメータを送信機が知っておく、または受信機によって指定することができ、例えば、受信機は、受信機がコンテンツの再生を開始する開始位置Ｓを明示的に信号で伝えることができる。
【０１２０】
当業者であれば認識されるように、動的インターリービング方法の多くの変形がある。例えば、受信機が損失をあまり経験していないために、例えば送信機は、符号化ブロックの一部またはすべてからの符号化データの一部をフィルタにかけて除去し、個々の受信機に送信しないことを決定することができる。別の変形として、ソースブロック構造を事前に決定することができる。しかし、送信プロセスが動作するにつれて、ＦＥＣ符号化が動作して、個々の受信機のために符号化ブロックを生成していたり、以前の受信機より大きい保護量を必要とする受信機に遭遇するにつれて、時として、一部の符号化ブロックのためにリペアシンボルの大量供給を生成したりしている。
【０１２１】
しばしば好ましい別の変形として、受信機は、動的インターリービング方法の初期パラメータの設定を制御することができ、サーバまたは複数のサーバのセットは、動的インターリービング方法の最後の対象パラメータを決定することができる。例えば、受信機は、コンテンツストリームが２秒のインターリービング深さおよび１秒の予備バッファで開始されると指定することができ、次いでサーバは、２０秒のインターリービング深さおよび１０秒の予備バッファが送信の最初の２分で達成されるように送信することを決定することができる。サーバまたはサーバ群に動的インターリービング方法の最後のパラメータを指示させる１つの利点は、コンテンツストリームの現在の時間以降の部分は、使用不可であるライブストリーミングをサポートするにははるかに容易であるので、サーバは、動的インターリービングパラメータを所与の制約下で使える最後の設定に導くことができることである。サーバに最後のパラメータを指示させる利点の別の例は、サーバが、いくつかの場合、ストリーム内の基本的に同じ位置からの同じコンテンツストリームが提供されている複数のクライアントのパラメータを、最終的に受信機の多くが同じ最終パラメータに導かれるように調整することができ、これによって、同じ時点に、同じパケットが、コンテンツストリームからこれらの受信機のすべてに送信されるため、受信機にパケットを送信する際のサーバ効率につながることである。
【０１２２】
＜コンテンツセグメント遷移の動的インターリービング方法＞
動的インターリービング方法の一使用例は、受信機がコンテンツセグメントリスト内のあるコンテンツセグメントから次のコンテンツセグメントに遷移するとき、例えば、ある番組の一エピソードの一セグメントから広告に遷移し、次いで、その番組の次のセグメントに戻るときなどであり、この場合、すべての遷移は、任意の受信機の対話無しに行われる。複数の差分コンテンツセグメントは、異なる送信機によって送信することができ、例えば、番組エピソードの複数のセグメントは、コンテンツサーバによって受信機に送信することができ、一方で、間に入る広告は、広告サーバによって受信機に送信することができる。
【０１２３】
第１の例は、受信機が上述した動的インターリービング方法を使用して第１の送信機によって送信されている第１のコンテンツセグメントを見ており、第１の送信機が、完全にインターリービング深さＤおよび予備バッファ時間Ｒが増加するのに十分長い間送信しているときである。次いで、動的インターリービング方法を使用して、以下のように、第２のコンテンツセグメントへのスムーズな遷移を達成することができる。
【０１２４】
１．第１のコンテンツセグメントの送信の終了前Ｄ＋Ｒ秒に、第１のセグメントの送信レートは、Ｄ秒の期間にわたって符号化ストリームレートからゼロまで直線的に低減し、その時点で、第１の送信機は、第１のセグメントについての送信を停止する。
【０１２５】
２．第１のコンテンツセグメントが再生を終了する前のＤ＋Ｒ秒で、受信機は、ＵＩ＝０、ＬＩ＝−Ｄ、ＵＦ＝０、ＬＦ＝−Ｄ、Ｔ＝０のパラメータで、第２のサーバに第２のコンテンツセグメントを要求する。ネットワーク待ち時間が無いと仮定すると、第２のサーバは、第２のコンテンツセグメントのストリームの送信を開始し、送信の最初のＤ秒にわたってレートを直線的に増加させ、その後、送信が符号化ストリームレートになる。
【０１２６】
３．第１のコンテンツセグメントが再生を終了したとき、第２のコンテンツの予備バッファは、Ｒ秒に増加しており、インターリーブ深さは、Ｄ秒に増加している。この時点で、第２のコンテンツの再生を開始することができる。
【０１２７】
したがって、第１のコンテンツセグメントから第２のコンテンツセグメントへの遷移は、受信機での受信レートを符号化ストリームレートに保ち、すなわち、遷移にわたる結合されたレートが、１つのコンテンツセグメントが連続して送信されているのと同じになるように、第１のコンテンツセグメントの送信レートが直線的に減少している間、第２のコンテンツセグメントの送信レートが直線的に増加する。さらに、第２のストリームの予備バッファ保護およびインターリーブ保護は、定常状態での第１のストリームの場合と同じである。図１２は、この例である。
【０１２８】
第１のコンテンツセグメントの送信の終了に比べて、第２のコンテンツセグメントのストリームの送信の開始時について、タイミングがわずかにはずれていたとしても、減少レートおよび増加レートがなだらかな直線であるため、ストリーミングレートの正味の誤りは、軽微である。例えば、２つのストリームの間の遷移のタイミングに５００ミリ秒の誤りがあり、インターリービング深さが１０秒である場合、ストリーミングレートの誤りは、多くて５％である。これは、第２のコンテンツセグメントのパラメータを上述したより少し控えめに、すなわち、これらの値を単に第１のストリームと同じに保持しようとする代わりに、予備バッファおよびインターリーブ時間を少し多く増やそうとするように設定することができ、その結果のコンテンツセグメント遷移間の結合されたストリーミングレートの増加は、軽微になることも意味している。
【０１２９】
コンテンツセグメント遷移の第２の例は、受信機が上述した動的インターリービング方法を使用して第１の送信機によって送信されている第１のコンテンツセグメントを見ており、しかし、第１の送信機が、完全にインターリービング深さＤおよび予備バッファ時間Ｒが増加するのに十分長い間送信していないときである。次いで、第２のコンテンツセグメントへのスムーズな遷移は、動的インターリービング方法を使用して、以下のように達成することができ、この場合、受信機が行うことは、第１のストリームから第２のストリームへの遷移は、２つのコンテンツセグメントが共に連結され、１つのサーバによって送信されるかのように、パラメータを設定し、また第２のストリームを要求することである。当業者であれば、動的インターリービング方法を使用して、このタイプの遷移を達成する方法の詳細を考え出すことができる。
【０１３０】
コンテンツセグメント遷移の第３の例は、上記の動的インターリービング方法を使用して第１の送信機によって送信されている第１のコンテンツセグメントを受信機が見ており、そして、第１のコンテンツセグメントの再生が受信機で終了したときと、第２のコンテンツセグメントの再生が始まるときとの間の期間にギャップがあるときである。例えば、これは、再生を終了する番組の一エピソードの第１のセグメントがあり、次いで例えば期間３０秒の非ストリーミング広告が続き、番組の当該エピソードの第２のコンテンツセグメントの即座の再生が続くときの好ましい挙動であり得る。この場合、動的インターリービング方法は、以下のように使用することができ、簡単にするために、完全にインターリービング深さＤおよび予備バッファ時間Ｒが増加するのに十分長い間、第１のコンテンツセグメントが受信機に送信されていると仮定する。この場合、上記の第１の例の場合のように、受信機は、パラメータＵＩ＝０、ＬＩ＝−Ｄ、ＵＦ＝０、ＬＦ＝−Ｄ、Ｔ＝０で、第１のコンテンツセグメントの再生終了前に、第２のコンテンツセグメントＤ＋Ｒ秒の要求を送信する。これにより、第２のサーバは、第１のサーバから送信されている第１のコンテンツセグメントのレートと結合されたときの総合レートが単一の送信ストリームのレートになるレートで、第２のコンテンツセグメントの送信を開始する。次いで、第１のコンテンツセグメントが受信機での再生をちょうど終了したとき、受信機は、第２のコンテンツセグメントのストリームの送信を停止するよう第２のサーバに信号で伝え、受信機への送信レートがすぐにゼロになる。次いで、約３０秒のギャップが生じる。ギャップの最後に、受信機は、第２のコンテンツセグメントの再生をすぐに開始すると同時に、パラメータＵＩ＝Ｄ＋Ｒ、ＬＩ＝Ｒ、ＵＦ＝Ｄ＋Ｒ、ＬＦ＝Ｒ、Ｔ＝０で、第２のコンテンツについての第２のサーバへの送信開始要求を送信する。これによって、第２のサーバは、ギャップの直前にそれが終えたところから、第２のコンテンツの送信を続ける。全体的な効果は、スケジュールされた時間に第２のコンテンツをすぐに再生すること、そして同時に、２つのコンテンツセグメントの再生中、遷移中のすべての時点における受信機への結合された送信レートは、１つの符号化ストリームレートと同じであり、２つのコンテンツセグメントのいずれも再生されていないとき、送信レートはゼロである。図１３は、この例である。
【０１３１】
当業者であれば認識されるように、上述した動的インターリービング方法の他の多くの使用および変形がある。
【０１３２】
＜サブストリームベースの配信方法＞
サブストリームベースの配信は、ＦＥＣ符号化ストリームをとり、それを複数のサブストリームに分割するための方法であり、ここで各サブストリームには、例えば、ほぼ等しい量の各符号化ブロックが含まれるように分割される。例えば、符号化ストリームは、４０のサブストリームに分割することができ、各サブストリームは、各ソースブロックの約５％から成り、したがって、この例では、ＦＥＣ符号化を使用して各ソースブロックについて生成されたリペアデータの量は、当該ソースブロックのサイズにほぼ等しい。より一般的には、ＦＥＣ符号化が各ソースブロックに適用され、次いで、サブストリームベースの配信が適用されるとき、各サブストリームに含まれる各ソースブロックの符号化の量がほぼ等しくなるように、各ソースブロックについての合計符号化データが複数のサブストリームに分割される。ここで、ＦＥＣ符号化がシステマチックである場合、各ソースブロックの符号化データは、各ソースブロックの元のデータ＋生成されたリペアデータを含むことがあり、ＦＥＣ符号化がシステマチックでない場合、各ソースブロックの符号化データは、リペアデータを含むことがある。
【０１３３】
サブストリームベースの配信の主な概念のうちの１つは、いくつかの所望の目的を達成するために、潜在的に異なるパスに沿って、潜在的に異なるサーバを介して、ストリームの複数のサブストリームを送信することである。一例として、コンテンツストリームをサブストリームベースの配信システムに取り入れる、以下ヘッドエンドサーバ（ＨＥＳ：Hed-End Server）と呼ぶサーバがあり、ＨＥＳが行うプロセスの一部は、コンテンツストリームのソースブロック構造を生成すること、ストリームのＦＥＣ符号化、符号化ストリームを複数のサブストリームに分割すること、次いで、該複数のサブストリームを、異なる複数のデータセンター内または個別の複数のネットワーク位置に分散され得る、以下分散サーバ（ＤＳ：Distributer Server）と呼ぶ他のサーバに送信することである。この一例は、図１４で見ることができる。図１４では、ＤＳ１４３０のそれぞれは、ＨＥＳ１４１０から符号化コンテンツストリーム１４２０の異なるセグメントを受信する。ＤＳが実行するプロセスの一部には、コンテンツストリームのサブストリームが受信機へ向かって通過するときにキャッシュすること、受信機からの特定のコンテンツストリームのサブストリームの要求を受け付けること、サブストリームを、例えば、特定のサブストリームについての受信機の要求に基づいて、または受信機の申し込みに基づいて、受信機に送信することが含まれる。サブストリーミングの特別な場合は、それ以上分割されない元の符号化ストリームを含む。
【０１３４】
サブストリームベースの配信システムにおける受信機は、同じ開始位置で開始する同じコンテンツセグメントについてのサブストリームを要求し、受信することができ、ここで、該要求は、異なるサブストリームごとに異なるＤＳに送信することができ、この場合、同じ開始位置を有する同じ符号化ストリームのいくつかの異なるサブストリームを、異なるＤＳから同じ受信機に送信することができる。この一例は、図１５で見ることができる。図１５において、受信機１５３０は、様々なＤＳ１５１０、１５２０にコンテンツストリームを要求する。この例では、ＤＳ１５２０のうちの１つは、受信機からの要求に応答せず、他のＤＳ１５１０は、受信機にサブストリームを送信する。応答するＤＳがこれを達成するのに十分なデータを受信機に送信する場合、受信機は、ＦＥＣ符号化を使用して、コンテンツストリームを完全に回復することが可能であり得る。
【０１３５】
一例として、元の１Ｍｂｐｓのコンテンツストリームを、ＨＥＳで取り入れることができ、ＨＥＳは、コンテンツストリームが通過するとき、ソースブロック構造を形成し、元のストリームにソースデータがあるのと同じ量のリペアデータを追加し（１００％リペア）、２Ｍｂｐｓの符号化ストリームを１００Ｋｂｐｓの複数のサブストリームに分割し、結果として得られた２０個のサブストリームを２０個の異なるＤＳに送信する。ストリーム内の特定の位置から開始するコンテンツストリームを再生したい受信機は、２０個のＤＳのうちの１２個に要求を送信し、指定された開始位置で開始するコンテンツについてＤＳが有するサブストリームを要求することができる。これに応答して、全１２個のＤＳは、指定された開始点から開始する、符号化ストリームについてそれらが有するサブストリームを受信機に同時に送信し、したがって、１２個のＤＳのそれぞれは、合計レートが１．２Ｍｂｐｓであるように、受信機に、１００Ｋｂｐｓのレートで送信する。
【０１３６】
前に説明したように、サブストリームベースの配信システムには、いくつかの利点があり、そのうちの一部または全部は、以下を含めて、本発明の実施形態で見ることができる。１）人気のあるものと無いものとを結合し、サーバに帯域幅容量およびストレージ容量を提供する自然な負荷バランシングの利点を有する、コンテンツの自然な負荷バランシング、２）パス障害の回復力、すなわち、１つのパスが低下し、コンテンツストリームがＦＥＣ復号を使用して依然として完全に埋め合わせることができるように、受信機が他のパスから受信している十分なデータが依然としてあること、３）ＤＳクラッシュ、ＤＳディスク障害などに対する頑強さ、４）複数のＤＳからデータを送信することは、単一サーバから送信する場合に比べて、総送信レートが受信機に維持され、受信機にバッファの欠乏が発生しない確率をより大きく提供する。これは特に、ＤＳから受信機へのサブストリームの送信に、ＴＣＰまたはＨＴＴＰが使用される場合に該当するが、これは、ＵＤＰが、ＤＳから受信機にサブストリームを送信するために使用される場合でさえも該当し、５）システム全体における単一障害点は、ＨＥＳおよび受信機の入口点にあり、他にある必要はない。
【０１３７】
＜動的インターリービング方法とサブストリームベースの配信方法との結合＞
本明細書に記載した動的インターリービング方法およびサブストリームベースの配信方法は、結合してかなりの利点を得ることができる。すなわち、両方の方法のすべての利点は、結合されたソリューションに見られる。例えば、コンテンツストリームがシステムに取り入れられるとき、動的インターリービング方法を使用して、コンテンツストリームのソースブロック構造およびＦＥＣ符号化を、ＨＥＳによって実行することができる。サブストリーム方法は、ＨＥＳでＦＥＣ符号化ストリームの複数のサブストリームを生成するために使用することができ、これらのサブストリームは、次いで異なるＤＳに送信されて格納することができる。受信機がストリーム内の特定の位置からコンテンツストリームを受信することを望むとき、受信機は、適切な動的インターリービングパラメータを、サブストリームを受信機に送信するすべてのＤＳに送信することができ、当該ＤＳは、これらのパラメータに従って、サブストリームを受信機に送信する。受信機は、ソースブロックのサブストリームからのパケットをひとまとめにして、再生するために、元のコンテンツストリームを再度作成することができる。動的インターリービング方法によって、予備バッファおよびインターリービング深さは、ストリーミング中に増加させることができ、バースト的パケット損失およびネットワークジッタに優れた保護を提供すると共に、受信機に迅速なチャネルザッピング時間を提供する。この例のソリューションにおけるＤＳは、ＦＥＣ符号化を行う必要はなく、それにもかかわらず、ネットワークの異なる部分から分散パスを介してコンテンツストリームを受信機に配信することができ、したがって、配信におけるサーバの多様性およびパスの多様性を増加させ、それによって、サーバおよびネットワーク障害への信頼性および頑強性を増加させる。
【０１３８】
さらに、各ソースブロックの保護量は、複数のＤＳと受信機との間より、この例のＨＥＳと複数のＤＳとの間で、かなり高い可能性がある。例えば、２０個のサブストリームが生成されて、ＨＥＳから２０個のＤＳに送信することができるが、元のコンテンツストリームを回復するのに１０個のサブストリームしか必要ではないし（１００％の保護量）、受信機は、２０個のＤＳのうちの１２個から例えば１２個のサブストリームしか要求しない（１００％の保護量）。１００％の保護量は、すなわち、当該ＤＳのうちの１つが故障して、受信機がサブストリームを受信する残りの１１個のＤＳからすべてのパスを介して総合的に１０％にも及ぶパケット損失があるとしても、依然として元のコンテンツストリームを回復することができる。
【０１３９】
上記で概説したソリューション例には、２０個のＤＳのうちの１２個を超えるＤＳのリストを有する受信機に適切な論理を組み込んでおけば、受信機がサブストリームを受信している１２個のＤＳのうちの１つが故障したとき、受信機は、これを自動的に検出し、受信機が現在サブストリームを受信していない他のＤＳのうちの１つに、別のサブストリームを要求することができ、それによって、１１個のサブストリームのバックアップを受信することから、異なる１２個のＤＳからの１２個のサブストリームを受信することへと、ストリームの信頼性を増すという追加の特性がある。
【０１４０】
動的インターリービング方法およびサブストリーム方法を結合するために必要な方法の変更は、比較的軽微である。例えば、動的インターリービング方法の送信時間を決定するために、符号化ブロック内に複数のデータ点を分配する方法を強化して、各ＤＳが、符号化ブロック内のサブストリームごとに、それが有するデータを、符号化ストリームテープ内の符号化ブロックエリアにわたって一様に分配する方法を決定することができるようにする必要がある（図７参照）。データを一様に分配するという、ＤＳによって行われる決定を、他のＤＳによる決定とは関係ない方法で行い、受信機に送信しているすべてのＤＳの符号化ブロック内のすべてのサブストリームからのデータの総分配が、符号化ストリームテープ内の符号化ブロックエリアにわたってまったく一様になるようにすることができる（図７参照）。
【０１４１】
それらを結合するのに必要な方法の変更の別の例として、各パケットで送信された情報を増大して、受信機がそれにサブストリームを送信するＤＳにストリーム内の特定の位置を指定するとき、すべてのＤＳが、同じコンテンツのサブストリームを受信機に送信する他のすべてのＤＳの解釈と一致する方法で、それらが受信機に送信するサブストリームの特定の位置を解釈することができるようにすることが有利である。当業者であれば認識されるように、これらおよび潜在的にいくつかの他の軽微の変更によって、インターリーブでのストリーミング方法およびサブストリームベースの配信方法を結合して、より大きい利益を得ることができる。
【０１４２】
本発明は、実施形態例を参照して説明してきたが、多数の変更が可能であることを当業者であれば認識され、こうした当業者の認識は、本開示を読むことによってもたらされる。例えば、本明細書に記載したプロセスは、ハードウェア構成要素、ソフトウェア構成要素、および／またはその組合せを使用して実装され得る。したがって、本発明は、実施形態例を参照して記載されているが、本発明は、以下の特許請求の範囲内に含まれるすべての変更および均等物をカバーするものとすることを理解されたい。
【優先権の主張】
【０００１】
本出願は、２００７年４月１６日出願の「Dynamic Stream Interleaving and Sub-Stream Based Delivery」という名称の米国特許仮出願第６０／９１２１４５号明細書の利益を主張する。本出願の内容は、すべての目的でその全体が参照により本明細書に組み込まれる。
【０００２】
また、本開示は、すべての目的で、全部本書内で記載のように、参照により以下の同出願人による出願／特許を組み込む。
【０００３】
Ｌｕｂｙによる米国特許第６，３０７，４８７号明細書（以下「Ｌｕｂｙ Ｉ」と呼ぶ）
Ｓｈｏｋｒｏｌｌａｈｉらによる米国特許第７，０６８，７２９号明細書（以下「Ｓｈｏｋｒｏｌｌａｈｉ Ｉ」と呼ぶ）
Ｌｕｂｙらによる２００６年６月９日出願の「Forward Error-Correcting (FEC) Coding and Streaming」という名称の米国特許出願第１１／４２３，３９１号明細書（以下「Ｌｕｂｙ ＩＩ」と呼ぶ）
Ｗａｔｓｏｎらによる２００７年２月１３日出願の「Streaming and Buffering Using Variable FEC Overhead and Protection Periods」という名称の米国特許出願第１１／６７４，６２５号明細書（以下「Ｗａｔｓｏｎ」と呼ぶ）
【技術分野】
【０００４】
本発明は、ストリーミング品質配信、コンテンツザッピング時間（content zapping time）、ストリームの拡張可能な分散配信、およびＦＥＣ符号化の使用を、あらゆる側面において向上させ、ストリーミングソリューションを向上させることに関する。ストリーミングは、オンデマンドのプレイリストコンテンツまたはライブプレゼンテーションの、一定のまたは可変のビットレートでの音声、映像、およびデータのストリーミングを含む。
【背景技術】
【０００５】
インターネット、セルラーおよび無線ネットワーク、電力線ネットワーク、および他の多くのネットワークなど、パケットベースのネットワークを介して高品質の音声および映像が配信されることがますます一般的になるにつれて、ストリーミングメディア配信は、ますます重要になりつつある。配信されたストリーミングメディアの品質は、元のコンテンツの品質、元のコンテンツの符号化品質、映像を復号し表示する受信装置の能力、受信機で受信された信号の適時性および品質などを含めて、いくつかの要因に依存する。認められる良いストリーミングメディア経験を作り出すために、受信機で受信された信号のトランスポートおよび適時性は、特に重要である。良いトランスポートは、送信機から送信されたものに比べて、受信機で受信されたストリームの忠実度を提供し、一方、適時性は、そのコンテンツの最初の要求後、受信機がコンテンツの再生をどれだけ迅速に開始できるかを表す。
【０００６】
最近では、伝送中、ストリーミングメディアの保護のために、順方向誤り訂正（ＦＥＣ）符号の使用を考えることが一般的な方法になっている。３ＧＰＰ、３ＧＰＰ２およびＤＶＢなどのグループによって標準化されたものなど、インターネットおよび無線ネットワークなどを例として含むパケットネットワークを介して送信されるとき、ソースストリームは、生成されたように、あるいは使用可能なように、パケットに入れられ、したがって、パケットは、ソースまたはコンテンツストリームを、生成された順または使用可能になる順に受信機に運ぶために使用される。
【０００７】
これらのタイプのシナリオへのＦＥＣ符号の一般的な適用では、符号器は、リペアパケット（repair packet）の作成にＦＥＣ符号を使用し、リペアパケットは、次いで、ソースストリームを含む元のソースパケットに加えて送信される。リペアパケットは、ソースパケットの損失が起こると、失われたソースパケットに含まれるデータを回復するために、受信したリペアパケットを使用することができるという特性を有する。リペアパケットは、完全に紛失した、失われたソースパケットの内容を回復するために使用することができるが、リペアパケットは、完全に受信されたリペアパケット、または部分的に受信されたリペアパケットでさえ、部分的なパケット損失の発生から回復するために使用することもできる。したがって、全部または部分的に失われたソースパケットを回復するために、全部または部分的に受信されたリペアパケットを使用することができる。
【０００８】
さらに他の例では、例えば、ビットの値が反転され得るなど、送信データに他のタイプの破損が起こる可能性があり、したがって、こうした破損を修正し、できるだけ正確なソースパケットの回復を提供するために、リペアパケットを使用することができる。他の例では、ソースストリームは、必ずしも個別のパケットで送信されるわけではなく、代わりに、例えば連続するビットストリームとして送信され得る。
【０００９】
ソースストリームの保護を提供するために使用することができるＦＥＣ符号の例が数多くある。リードソロモン符号は、通信システムにおける誤りおよび消去訂正のためのよく知られている符号である。例えば、パケットデータネットワークを介した消去訂正の場合、リードソロモン符号のよく知られている効率的な実装は、Ｌ．Ｒｉｚｚｏによる「Effective Erasure Codes for Reliable Computer Communication Protocols」、Computer Communication Review, 27(2):24-36 (April 1997)（以下「Ｒｉｚｚｏ」）およびＢｌｏｅｍｅｒらによる「An XOR-Based Erasure-Resilient Coding Scheme」、Technical Report TR-95-48, International Computer Science Institute, Berkeley, California (1995)（以下「ＸＯＲ−Ｒｅｅｄ−Ｓｏｌｏｍｏｎ」）他に記載されているように、ＣａｕｃｈｙまたはＶａｎｄｅｒｍｏｎｄｅ行列を使用する。
【００１０】
ＦＥＣ符号の他の例には、例えばＬＤＰＣ符号、Ｌｕｂｙ Ｉに記載されているものなどの連鎖反応符号（chain reaction code）、およびＳｈｏｋｒｏｌｌａｈｉ Ｉのマルチステージ連鎖反応符号（multi-stage chain reaction code）などがある。
【００１１】
リードソロモン符号の変形のＦＥＣ復号プロセスの例は、ＲｉｚｚｏおよびＸＯＲ−Ｒｅｅｄ−Ｓｏｌｏｍｏｎに記載されている。これらの例では、十分なソースおよびリペアデータパケットが受信された後で復号が適用される。復号プロセスは、計算量が多い可能性があり、使用可能なＣＰＵリソースに応じて、ブロック内のメディアに要する時間の長さに対して、終了するのにかなりの時間がかかり得る。受信機は、メディアストリームの受信の開始とメディアの再生との間に要する遅延を計算するとき、復号に必要なこの時間長を考慮に入れる必要がある。復号によるこの遅延は、ユーザによって、特定のメディアストリームの要求と再生の開始との間の遅延として知覚される。したがって、この遅延を最低限に抑えることが望ましい。
【００１２】
多くの用途では、パケットは、ＦＥＣプロセスが適用されるシンボルにさらに細分される。パケットは、１つまたは複数のシンボル（または１つ未満のシンボルであるが、通常、シンボルはパケットにわたって分割されない）を含み得る。シンボルは、任意のサイズを有し得るが、シンボルのサイズは、多くてもパケットのサイズに等しいことが多い。ソースシンボルとは、送信されるデータを符号化するシンボルである。リペアシンボルとは、ソースシンボルに加えて、ソースシンボルから直接または間接的に生成されるシンボルである（すなわち、ソースシンボルのすべてが使用可能であり、リペアシンボルが使用不可である場合、送信されるデータは、完全に回復することができる）。
【００１３】
符号化操作が、あるブロック内のシンボルに依存し、そのブロックにないシンボルとは無関係であり得るという点で、一部のＦＥＣ符号は、ブロックベースである。ブロックベースの符号化では、ＦＥＣ符号器は、あるブロック内のソースシンボルからそのブロックのリペアシンボルを生成することができ、次いで次のブロックに進み、符号化されている現在のブロックのもの以外のソースシンボルを参照する必要はない。伝送では、ソースシンボルを備えるソースブロックは、符号化されたシンボル（いくつかのソースシンボル、いくつかのリペアシンボル、またはその両方とすることができる）を含む符号化されたブロックによって表すことができる。リペアシンボルの存在と共に、すべてのソースシンボルがすべての符号化されたブロックで必要というわけではない。
【００１４】
一部のＦＥＣ符号、特にリードソロモン符号では、符号化および復号の時間は、ソースブロック当たりの符号化シンボルの数が増えるにつれて増加して非現実的になる。したがって、実際には、特に、リードソロモン符号化または復号プロセスがカスタムハードウェアによって実行される一般的な場合には、ソースブロック当たり生成することができる符号化シンボルの総数に、実用上の上限（２５５がいくつかの用途でのおおよその実用上の制限）があることが多い。例えば、パケット損失からストリームを保護するためのＤＶＢ−Ｈ標準の一部として含まれるリードソロモン符号を使用するＭＰＥ−ＦＥＣプロセスは、ソースブロック当たり合計２５５個のリードソロモン符号化シンボルに制限されたセル方式の電話内の専用ハードウェアに実装される。シンボルを別々のパケットペイロードに入れる必要があることが多いため、これによって、符号化されるソースブロックの最大長に実用上の上限が設けられる。例えば、パケットペイロードが１０２４バイト以下に制限され、各パケットが１つの符号化シンボルを運ぶ場合、符号化ソースブロックは、多くて２５５ＫＢ（キロバイト）とすることができ、これは、当然、ソースブロック自体のサイズの上限でもある。
【００１５】
ソースストリーミングレートについていけるほど十分速くソースブロックを復号することができること、ＦＥＣ復号によってもたらされる復号待ち時間を最低限に抑えることができること、ＦＥＣ復号中の任意の時点で受信装置上の使用可能なほんのわずかなＣＰＵのみを使用することができることなど、他の関心事が問題である。
【００１６】
他の問題は、ストリームの再生を開始する機能を含む。例えば、パーソナルコンピュータを使用して受信したオーディオおよびビデオストリームを復号及びレンダリングし、コンピュータ画面にビデオを表示し、内蔵スピーカを介して音声を再生したり、または他の例として、セットトップボックスを使用して受信した音声および映像ストリームを復号及びレンダリングし、テレビ表示装置に映像を表示し、ステレオシステムを介して音声を再生したり、などである。第１の問題は、ストリームとして配信された新しいコンテンツをユーザが見ることを決めたときと、コンテンツが再生開始したときとの間の遅延を最低限に抑えることであり、以下「コンテンツザッピング時間」と呼ぶ。コンテンツザッピングの一例は、ユーザが、第１のストリームを介して配信された第１のコンテンツを見ており、次いでユーザが、第２のストリームを介して配信された第２のコンテンツを見ることを決め、第２のコンテンツを見始めるためにアクションを開始するときである。第２のストリームは、第１のストリームと同じかまたは異なるサーバセットから送信され得る。コンテンツザッピングの別の例は、ユーザがあるＷｅｂサイトを見ており、ブラウザウィンドウ内のリンクをクリックすることによって、第１のストリームを介して配信された第１のコンテンツを見始めることを決めたときである。コンテンツザッピングの別の例は、ユーザが、同じコンテンツストリーム内で順方向または逆方向のいずれかの新しい位置に移動して表示を開始したいときである。使用可能な様々なコンテンツを検索して試写する際に高品質の高速コンテンツサーフィン経験をユーザにとって可能にするためには、コンテンツザッピング時間を最低限に抑えることが、映像を見る上で重要である。高品質の高速コンテンツサーフィン経験は、ユーザが消費するコンテンツの量と正の相関を有することが多い。
【００１７】
コンテンツザッピング時間の主な誘因は、基礎を成すＦＥＣ構造である場合がしばしばある。別の問題は、あるコンテンツの再生の終わりと、別のコンテンツの再生の開始との間の時間のギャップを最低限に抑えることであり、ほとんどまたはまったく停止することなく連続することが好ましい。例えば、あるコンテンツが放送番組であり、次のコンテンツが広告である場合、または逆の場合、それらの再生の間の長いギャップ（以下「コンテンツ遷移時間（content transition time）」と呼ぶ）は、望ましくない。
【００１８】
明らかに、コンテンツ遷移時間を最低限に抑えると共に、遷移周辺の期間中の受信機へのストリームのレートを最低限に抑えることが望ましい。
【００１９】
別の問題は、パケットをドロップする可能性があり、パケットの配信にかかる時間量の広範な変動をもたらす可能性がある、インターネットなどのベストエフォート型の配信ネットワークを使用するとき、配信されたストリームの品質を最大にすると共に、帯域幅などのネットワークリソースの使用量を最低限に抑えることである。
【００２０】
別の問題は、受信機に配信されるストリームの品質に悪影響を与えること無く、システムの構成要素が故障することが可能である、頑強で拡張可能なストリーミング配信ソリューションを提供することである。
【００２１】
インターリービングは、断続的なパケット損失など、チャネルの不完全性に対する優れた保護を提供するために使用することができる。例えば、パケット損失は、ある程度バースト的であることが多く、したがって、より長い期間にわたってソースブロックを分配することが有利となり得る。一部のＦＥＣ符号では、大きいソースブロックの本来の使用は、実用的であるが、リードソロモン符号など、他のＦＥＣ符号では、使用することができるソースブロックのサイズの実用上の制限があることが多い。したがって、より長い時間にわたってソースブロックに関連付けられているパケットの伝送を分配するために、異なるソースブロックについての符号化シンボルを含むパケットの送信をインターリーブすることが有利となり得る。
【００２２】
以前に、上述した問題の一部に対処する方法が紹介されている。例えば、いくつかの新規のＦＥＣソースブロックの形成およびインターリービングの方法がＬｕｂｙ ＩＩに記載されている。いくつかのインターリービング方法は、インターリービングの量が全ストリームについて固定されているという意味で、静的である。したがって、時として、こうした方法によって提供される保護の品質に影響を与えるインターリービングの量と、コンテンツザッピング時間との間のトレードオフがあり、すなわち、より多い量のインターリービングは、より良いストリーム保護を提供するが、より長いコンテンツザッピング時間を提供し、このトレードオフは、受信機へのストリーミングの全継続時間の間、固定された方法で決定される。
【００２３】
例えば、Ｗａｔｓｏｎに記載されている一部の方法など、ストリーム送信プロセスの大部分の間、短いコンテンツザッピング時間およびより多い量のインターリービングを提供する方法がいくつかある。Ｗａｔｓｏｎに記載されている方法の一部は、短い初期ソースブロックから徐々により長いソースブロックに動的に遷移し、遷移期間中、コンテンツストリーミングレートよりわずかに速いレートで送信する。こうした方法は、短いコンテンツザッピング時間を提供すると共に、ストリームが進むにつれて提供される保護の品質の強化を可能にする。例えば、Ｗａｔｓｏｎに記載されている方法の一部を適用する１つの方法は、ソースブロック構造を決定し、ストリームが送信されている間にＦＥＣ符号化を実行することであり、すなわち、短−長ソースブロック構造は、それらがアクセスされる各点で、個々の受信機に送信されながら決定され、ＦＥＣ符号化され、したがって、ソースブロック構造の形成およびＦＥＣ符号化は、受信機ごとに一意に実行され、各受信機に送信されるストリームは、一意である。しかし、時として、ストリームの配信に関係なく、例えば、受信機に関係なく、コンテンツが表示されるときおよびコンテンツストリームにおいて表示を開始する場所に関係なく、およびどの順でストリーム内のデータが配信されるかに関係なく決定されるコンテンツストリームのソースブロック構造を有することが望ましい。これは、コンテンツストリームが複数のサーバから単一の受信機に配信される場合、特に重要である。
【００２４】
したがって、改良されたプロセスおよび装置を有することが望まれる。
【発明の概要】
【００２５】
本発明の態様による符号器、復号器、および通信システムの実施形態は、複数のストリームを動的にインターリーブする方法を提供し、該方法は、任意のソースブロック構造とは関係なく、ストリームが送信されるとき、より多くの量のインターリービングを動的に導入するための方法を含む。これらの方法のいくつかの利点は、チャネルの損失または誤りを、インターリービングが導入されなかった場合よりかなり長い期間にわたって元のストリーム内で分配し、ＦＥＣ符号化と共に使用するとき、パケット損失またはパケット破損に対する優れた保護を提供し、ネットワークジッタに対する優れた保護を提供し、コンテンツザッピング時間およびコンテンツ遷移時間を最小値に低減することができることである。これらの方法のいくつかの追加の利点は、あるコンテンツのストリーミングから別のコンテンツのストリーミングへの遷移を含めて、送信ストリーミングレートを平滑化すること、および最小のコンテンツ遷移時間を含む。
【００２６】
本発明の態様による符号器、復号器、および通信システムの実施形態は、データのストリームを複数のサブストリームに分割し、ネットワークを介して、異なるパスに沿って、該複数のサブストリームを受信機に配信し、受信機で、潜在的に異なる複数のサーバから送信された異なる複数のサブストリームを同時に受信することを提供することもできる。ＦＥＣ符号化と共に使用されるとき、これらの方法は、潜在的に異なる複数のサーバから各ソースブロックの符号化の部分を配信することを含む。これらの方法のいくつかの利点は、改良されたコンテンツザッピング時間、サーバ障害およびパス障害に対する頑強性、ディスク障害に対する頑強性、パケットの損失および／または破損に対する改良された頑強性、ストリーミング配信ソリューション全体の改良された拡張可能性、および複数のサーバ間での改良されたコンテンツの格納とストリーミングレートとの均衡化を含む。
【００２７】
本発明の態様による符号器、復号器、および通信システムの実施形態は、動的インターリーブとサブストリームの配信との結合も提供し得る。例えば、動的インターリーブを使用して、ソースブロック構造およびＦＥＣ符号化を決定することができ、符号化されたストリームを、複数のサブストリームに分割することができ、動的インターリーブを使用して、サブストリームの組合せを受信機に配信して、最低コンテンツザッピング時間を提供する頑強なストリーミング配信システムを提供することができる。これらの結合方法の利点は、動的インターリーブおよびサブストリーム配信の利点の組合せである。
【００２８】
以下の詳細な説明を添付の図面と併せ読めば、本発明の本質および利点をよりよく理解できよう。
【図面の簡単な説明】
【００２９】
【図１】本発明の一実施形態による通信システムを示すブロック図。
【図２】コンテンツザッピング時間を示す図。
【図３Ａ】コンテンツザッピング時間の構成要素を例示する図。
【図３Ｂ】復号中のＦＥＣについてのＣＰＵ使用率を例示する図。
【図４】コンテンツストリームのソースブロック構造およびソースブロックごとの対応するコンテンツストリームレートの表現を例示する図。
【図５】図４のコンテンツストリームに対応する符号化ブロック構造を例示する図。
【図６】基本的な送信器の方法に対応する受信機およびコンテンツザッピング時間を例示する図。
【図７】ストリーム送信のテープ方法を例示する図。
【図８】ストリーム送信のテープ方法による静的インターリービングを例示する図。
【図９】静的インターリービングの送信器の方法に対応する受信機およびコンテンツザッピング時間を例示する図。
【図１０】新しいストリームが受信機に送信されるときの動的インターリービングの送信機の方法を例示する図。
【図１１】動的インターリービングの送信機の方法での、受信機によって経験されるコンテンツザッピング時間および長期保護期間を例示する図。
【図１２】動的インターリービングの送信機の方法での、２つの連続するコンテンツセグメント間のコンテンツ遷移を例示する図。
【図１３】動的インターリービングの送信機の方法での、２つの非連続のコンテンツセグメント間のコンテンツ遷移を例示する図。
【図１４】ヘッドエンドサーバからサブストリームベースの配信方法で使用される分散された様々なサーバに分散される符号化コンテンツストリームを例示する図。
【図１５】サブストリームベースの配信方法において、受信機が、分散された様々なサーバにコンテンツストリームを要求し、こうしたサーバの一部から符号化コンテンツストリームを受信することを例示する図。
【発明を実施するための形態】
【００３０】
実施形態は、伝送がネットワークなどを介する場合、任意のソースブロック構造とは関係なく、ストリームが送信されるとき、より多くの量のインターリービングを動的に導入する方法を含めて、ストリームを動的にインターリーブする新規の方法を提示する。また、実施形態は、データのストリームを複数のサブストリームに分割し、ネットワークを介して、異なるパスに沿って、該複数のサブストリームを受信機に配信し、受信機で、潜在的に異なる複数のサーバから送信された異なる複数のサブストリームを同時に受信する新規の方法も提示する。ＦＥＣ符号化と共に使用されるとき、これらの方法は、潜在的に異なる複数のサーバから各ソースブロックの符号化の部分を配信することを含む。また、実施形態は、動的インターリービングをサブストリームの配信と結合する新規の方法も提示する。
【００３１】
以下、本明細書における説明を簡単にするために、データを運ぶネットワークは、パケットベースと仮定し、本明細書に記載されたプロセスおよび方法を、連続するビットストリームネットワークなど、他のタイプの送信ネットワークに適用できる方法を当業者が容易に理解できることを認識されたい。以下、本明細書における説明を簡単にするために、ＦＥＣ符号は、失われたパケットまたはパケット内の失われた部分的なデータに対する保護を提供すると仮定し、本明細書に記載されたプロセスおよび方法を、ビットフリップなど、他のタイプのデータ送信の破損に適用できる方法を当業者が容易に理解できることを認識されたい。この説明において、符号化すべきデータ（ソースデータ）は、（単一ビットまでの）任意の長さのものであるが、データの異なる部分について異なる長さのものとすることができる等しい長さの複数の「シンボル」に分割されていると仮定する。
【００３２】
シンボルは、パケットでデータネットワークを介して運ぶことができ、各パケットには、整数のシンボルが明示的に入れられ、または暗に含まれる。いくつかの場合、ソースパケットは、シンボル長の倍数ではないことが可能であり、この場合、パケット内の最後のシンボルは、切り捨てることができる。この場合、ＦＥＣ符号化の目的で、この最後のシンボルは、これらのビットがパケットで運ばれない場合でも、依然として、受信機が切り捨てられた最後のこのシンボルを充填して完全なシンボルとすることができるように、例えば、ゼロ値のビットなど、固定されたパターンのビットで埋められるものと暗黙的に見なされる。他の実施形態において、固定されたパターンのビットは、パケットに入れることができ、それによって、シンボルを、パケットのものと等しい長さまで効果的に埋めることができる。シンボルのサイズは、しばしばビットで測定することができ、この場合、シンボルは、Ｍビットのサイズを有し、シンボルは、２~Ｍ（２のＭ乗）個のシンボルのアルファベットから選択される。非２進数も企図されるが、２進数は、より一般的に使用されるので、好ましい。
【００３３】
ストリーミングとの使用を考慮されるＦＥＣ符号は、一般に、システマチックＦＥＣ符号であり、すなわち、ソースブロックのソースシンボルがソースブロックの符号化の一部として含まれ、したがって、ソースシンボルが送信される。当業者であれば認識するように、本明細書に記載された方法およびプロセスは、システマチックではないＦＥＣ符号にも十分等しく適用される。システマチックＦＥＣ符号器は、ソースシンボルのソースブロックから、いくつかのリペアシンボルを生成し、少なくともいくつかのソースシンボルとリペアシンボルとの組合せは、ソースブロックを表す、チャネルを介して送信される符号化シンボルである。いくつかのＦＥＣ符号は、例えば「情報付加符号（information additive code）」や「ファウンテンコード（fountain code）」など、必要なだけのリペアシンボルを効率的に生成するのに有用であり、これらの符号の例には、「連鎖反応符号」および「マルチステージ連鎖反応符号」などがある。リードソロモン符号など他のＦＥＣ符号は、実際に、ソースブロックごとに制限された数のリペアシンボルを生成することしかできない。
【００３４】
シンボルを運ぶための他の多くの方法があり、以下の説明は、簡単にするために、パケットの方法を使用するが、これは、限定的または包括的であるものではない。以下の説明の文脈で、「パケット」という用語は、単一単位のデータとして何が送信されるかを文字通り意味することに制約されるものではない。代わりに、単一単位のデータとして送信され得る、またはされ得ない、シンボルおよび部分的シンボルの論理的なグループ分けを定義する、より広い概念を含むものとする。
【００３５】
また、例えば、以下に記載する方法が等しく適用される、伝送においてその値を変えるシンボルや、他の方法で破損されるシンボルなど、シンボルの損失以外のデータの破損の形態もある。したがって、以下の記載は、しばしばシンボルの損失について説明しているが、方法は、他のタイプの破損、およびＦＥＣ誤り訂正符号など、ＦＥＣ消去符号を超えた他のタイプのＦＥＣ符号にも十分等しく適用される。
【００３６】
＜ＦＥＣ符号例＞
図１は、連鎖反応ＦＥＣ符号化を使用する通信システム１００のブロック図である。通信システム１００には、入力ファイル１０１、または入力ストリーム１０５が入力シンボルジェネレータ１１０に提供される。入力シンボルジェネレータ１１０は、入力ファイルまたはストリームから１つまたは複数の入力シンボル系列（ＩＳ（０），ＩＳ（１），ＩＳ（２），・・・）を生成し、各入力シンボルは、値および位置を有する（図１に括弧内の数字として示されている）。入力シンボルの可能な値、すなわちそのアルファベットは、各入力シンボルが入力ファイルのＭ個分のビットを符号化するように、一般に、２００万個のシンボルのアルファベットである。Ｍの値は、一般に、通信システム１００の使用によって決定されるが、汎用システムは、Ｍを使用によって変えることができるように、入力シンボルジェネレータ１１０のためにシンボルサイズの入力を含み得る。入力シンボルジェネレータ１１０の出力は、符号器１１５に提供される。
【００３７】
キージェネレータ１２０は、符号器１１５によって生成される出力シンボルごとにキーを生成する。各キーは、Ｌｕｂｙ ＩまたはＳｈｏｋｒｏｌｌａｈｉ Ｉに記載されている方法、またはキーがこれによって生成されたか、他のキージェネレータによって生成されたかにかかわらず、同じ入力ファイルまたはストリーム内のデータのブロックのために生成されたキーの大半が一意であることを保証する任意の同等の方法のうちの１つに従って生成することができる。例えば、キージェネレータ１２０は、カウンタ１２５の出力、一意のストリーム識別子１３０、および／またはランダムジェネレータ１３５の出力の組合せを使用して、各キーを生成することができる。キージェネレータ１２０の出力は、符号器１１５に提供される。他の例では、例えば、一部のストリーミングの用途では、キーの組を固定し、ストリーム内のデータのブロックごとに、再度、再利用することができる。一般的な実施形態では、生成することができるキーの数は、入力ファイルまたはストリームのサイズや他の特徴ではなく、キージェネレータの解像度によって指示される。例えば、入力がしばしば１０００シンボル程度以下であると予想される場合、キーの解像度は、３２ビットとすることができ、それによって、最高４０億個の一意のキーが可能になる。これらの相対数の１つの結果は、キーに従って符号化する符号器は、４０００個のシンボルの入力について、４０億個の一意の出力シンボルを生成することができ得ることである。実際問題として、ほとんどの通信システムが、シンボルの０．９９９９９９部を失うことはないため、約４０億個の出力シンボルを生成する必要はなく、したがって、可能なキーの数は、事実上無制限として扱うことができ、繰り返す必要がなく、キーの２つの独立した選択が同じキーを掴む可能性は、無視できるほど小さい。しかし、それが何らかの理由のためにそうである場合、キーを使用するプロセスがまるでキーの無限の提供があるかのように振る舞うことができるように、キージェネレータの解像度を増やすことができる。
【００３８】
キージェネレータ１２０によって提供された各キーＩから、符号器１１５は、入力シンボルジェネレータによって提供される入力シンボルから、値Ｂ（Ｉ）の出力シンボルを生成する。
【００３９】
各出力シンボルの値は、そのキーと、本明細書において出力シンボルの「関連入力シンボル」または単にその「関連」と呼ぶ１つまたは複数の入力シンボルの何らかの関数とに基づいて生成される。しかし常にではないが、一般に、Ｍは、入力シンボルおよび出力シンボルについて同じであり、すなわち、これらはいずれも、同じビット数分符号化する。いくつかの実施形態では、関連を選択するために、入力シンボル数Ｋが符号器によって使用される。例えば、入力がストリームであり、Ｋがストリームにおける各ブロック間で変わり得る場合など、Ｋが前もってわからない場合、Ｋは、単に推定値とすることができる。値Ｋは、入力シンボルにストレージを割り振るために、符号器１１５によって使用することもできる。
【００４０】
符号器１１５は、出力シンボルを送信モジュール１４０に提供し、キージェネレータ１２０は、こうした各出力シンボルのキーを送信モジュール１４０に提供する。送信モジュール１４０は、出力シンボルを送信し、使用されるキーイング方法に応じて、送信モジュール１４０は、送信された出力シンボルのキーについての何らかのデータを、チャネル１４５を介して受信モジュール１５０に送信することもできる。チャネル１４５は、消去チャネルと仮定されるが、これは、通信システム１００の適切な操作のための必要条件ではない。送信モジュール１４０が出力シンボルおよびそのキーについての任意の必要なデータをチャネル１４５に送信するよう構成され、受信モジュール１５０がシンボルおよびそのキーについての潜在的な何らかのデータをチャネル１４５から受信するように構成されている限り、モジュール１４０、１４５および１５０は、任意の適したハードウェア構成要素、ソフトウェア構成要素、物理媒体、またはその任意の組合せとすることができる。Ｋの値は、関連を決定するために使用される場合、チャネル１４５を介して送信することができ、または、符号器１１５および復号器１５５の合意によって前もって設定することができる。
【００４１】
チャネル１４５は、テレビ送信機からテレビ受信機へのインターネットまたはブロードキャストリンクを介したパス、またはある地点から別の地点への電話接続など、リアルタイムチャネルとすることができ、または、チャネル１４５は、ＣＤ−ＲＯＭ、ディスクドライブ、Ｗｅｂサイトなどのストレージチャネルとすることができる。チャネル１４５は、ある人物が入力ファイルを電話回線を介してパーソナルコンピュータからインターネットサービスプロバイダ（ＩＳＰ）に送信し、入力ファイルがＷｅｂサーバに格納され、その後インターネットを介して受信者に送信されるときに形成されるチャネルなど、リアルタイムチャネルおよびストレージチャネルの組合せとすることさえできる。
【００４２】
チャネル１４５がパケットネットワークを備える場合、通信システム１００は、任意の２つ以上のパケットの相対的順序がチャネル１４５を介して送信中に保持されると仮定することができない場合がある。したがって、出力シンボルのキーは、上述したキーイング方式のうちの１つまたは複数を使用して決定され、必ずしも出力シンボルが受信モジュール１５０を出る順序によって決定されるわけではない。
【００４３】
受信モジュール１５０は、出力シンボルを復号器１５５に提供し、これらの出力シンボルのキーについて受信モジュール１５０が受信する任意のデータは、キーリジェネレータ１６０に提供される。キーリジェネレータ１６０は、受信された出力シンボルのキーを再度生成し、これらのキーを復号器１５５に提供する。復号器１５５は、対応する出力シンボルと共に、キーリジェネレータ１６０によって提供されるキーを使用して、入力シンボルを回復する（この場合も、ＩＳ（０），ＩＳ（１），ＩＳ（２），・・・）。復号器１５５は、回復した入力シンボルを入力ファイルリアセンブラ１６５に提供し、これは、入力ファイル１０１のコピー１７０または入力ストリーム１０５のコピー１７５を生成する。
【００４４】
メディアストリーミングの用途
メディアストリーミングの用途で使用するとき、ソースメディアストリームを形成するソースパケットは、時として、ソースブロックと呼ばれるグループに集められる。例えば、ソースブロックは、一定の時間長に及ぶソースパケット群とすることができ、例えば、リードソロモン消去符号は、これらのソースブロックに別々に適用されて、ソースブロックの元のソースパケットと共に、受信機に送信されるリペアパケットを生成することができる。
【００４５】
送信機では、ソースパケットが到着するにつれて、ソースストリームをソースブロックに連続的に分割することができ、ソースブロックごとにリペアパケットが生成され、送信される。時として、特に、ライブまたは対話型のストリーミングの用途の場合、ＦＥＣ符号の使用によって追加された合計エンドツーエンド遅延を最低限に抑えることが好ましく、したがって、ＦＥＣソリューションの設計全体を、送信される前にソースパケットの遅延が送信機でできるだけ小さくなるようにし、１つのソースブロックに対しすべてのソースパケットおよびリペアパケットができるだけ小さい合計遅延で送信されるようにすると好ましい場合もある。また、ＦＥＣ符号化ストリームのレートができるだけスムーズであることが好ましい。すなわち、ＦＥＣ符号化ストリームレートにある変動ができるだけ小さいか、または少なくとも、元のソースストリームにすでに存在する任意の変動の拡大がないことが好ましい。というのは、これによって、ＦＥＣ符号化ストリームの帯域幅の使用量がより予測可能になり、ネットワークおよび場合によっては競合する他のストリームへの影響が最低限に抑えられるからである。また、あるソースブロックについて複数のパケットで送信されたデータが、そのソースブロックについて複数のパケットが送信される期間にわたってできるだけ一様に分配されると好ましい。というのは、これは、バースト損失に対して最適な保護を提供するからである。また、コンテンツザッピング時間およびコンテンツ遷移時間を最低限に抑えるような方法でソースブロックが構築されることも好ましい。また、受信機でのロジックができるだけ簡単であることも好ましい。
【００４６】
受信機で、パケットが失われた、または誤りを含んで（例えば、ＣＲＣ検査を使用して検出し、破棄することができる）受信された場合、十分なリペアパケットが受信されていると仮定して、リペアパケットを使用して、失われたソースパケットを回復することができる。
【００４７】
いくつかの用途では、パケットは、ＦＥＣプロセスが適用される複数のシンボルにさらに細分される。いくつかのＦＥＣ符号、特にリードソロモン符号では、符号化および復号の時間は、ソースブロック当たりの符号化シンボルの数が増えるにつれて増加して非現実的になり、ソースブロック当たり生成することができる符号化シンボルの総数に上限があることが多い。シンボルは、別々のパケットペイロードに入れられるため、これによって、ソースブロックの符号化の最大長に実用上の上限が設けられ、また、当然、ソースブロック自体のサイズにも上限が設けられる。
【００４８】
いくつかの用途では、長い期間にわたって保護が提供されるとき、またはメディアストリーミングレートが高いとき、最大ソースブロックサイズを超えるデータに対する保護を提供することが有利となり得る。これらの場合、最大ソースブロックサイズより短いソースブロックを使用し、次いで、異なるソースブロックからのソースパケットをインターリーブすることは、送信される個々のソースブロックからの複数のソースパケットがより長い期間にわたって分配されるソリューションを提供する。他の用途では、短いコンテンツザッピング時間が望ましく、ソースブロック構造がインターリービング方法とは関係なく決定される場合、コンテンツが受信機によってアクセスされたときは、最初に、より短いソースブロックを使用して、それらを順次的に送信し、次いでコンテンツストリーミングが続くにつれて、ソースブロックの送信をより長い時間間隔にわたって分配するためにインターリービング量を増やして、バースト的損失に対する保護のレベルを増やすことが望ましい。
【００４９】
他の問題は、例えばソースストリーミングレートについていけるほど十分速くソースブロックを復号し、ＦＥＣ復号によってもたらされる復号待ち時間を最低限に抑え、ＦＥＣ復号中の任意の時点で受信装置上の使用可能なＣＰＵのわずかな部分のみを使用することができることである。したがって、各ソースブロックのＦＥＣ復号を時間にわたってできるだけ等しく分配することができるようにし、ＦＥＣ復号待ち時間を最低限に抑えるソースブロックインターリービングを使用することが望ましい。
【００５０】
本明細書に記載された様々な実施形態は、これらの利点のうちの１つまたは複数を提供する。
【００５１】
＜ストリーミングおよびＦＥＣ符号＞
ソースストリームのＦＥＣ保護を提供する目的で、ソースストリームは、１つまたは複数の論理的ストリームの組合せとすることができ、その例には、音声ＲＴＰストリームと映像ＲＴＰストリームとの組合せ、ＭＩＫＥＹストリームとＲＴＰストリームとの組合せ、２つ以上の映像ストリームの組合せ、および制御ＲＴＣＰトラフィックとＲＴＰストリームとの組合せなどがある。ソースストリームが、例えばソースビットストリーム、ソースシンボルストリーム、またはソースパケットストリームのフォーマットで送信機に到着すると、送信機は、該ストリームを複数のソースブロックにバッファリングし、該複数のソースブロックからリペアストリームを生成することができる。送信機は、ソースストリームおよびリペアストリームをスケジューリングし、例えば、パケットネットワークを介して送信されるべきパケットで送信することができる。ＦＥＣ符号化ストリームは、結合されたソースおよびリペアストリームである。ＦＥＣ受信機は、例えば、損失またはビットフリップによって破損された可能性があるＦＥＣ符号化ストリームを受信する。ＦＥＣ受信機は、ソースストリームの元のソースブロックを再構築しようと試み、元のソースストリームをスケジューリングし、受信機で使用できるようにする。
【００５２】
多くの用途の場合、ソースブロック構造は、例えば、ＧＯＰ構造および／またはＨ．２６４ＡＶＣ映像ストリームのフレーム構造など、基礎を成すストリームの構造と共に決定される。これらの用途のいくつかでは、ソースブロック構造は、パケットのストリーム送信順の前に、および／またはパケットのストリーム送信順とは関係なく決定され、この場合、パケットのストリーム送信順は、受信機が、ストリームを受信するために、いつどこでストリームにアクセスするかに依存し得る。こうした用途では、コンテンツザッピング時間およびコンテンツ遷移時間を最低限に抑えることができるようにするために、各ソースブロックがストリームからの連続する１組のソースパケットを備えるように、ソースブロック構造が決定されることが好ましい。
【００５３】
いくつかの用途では、ソースブロック構造の形成およびストリームのＦＥＣ符号化は、ストリームの送信前に行われることが好ましい。この１つの理由は、ストリームが多くの受信機に送信される可能性があり、したがって、ソースブロック構造の形成およびＦＥＣ符号化がすべての受信機について１回行われるからであり、これは、拡張性の利益をいくつか提供する。
【００５４】
ストリーミングの用途では、ソースストリームと、通常最適化することが重要ないくつかの主要メトリクスを保護するためのＦＥＣ符号の使用方法の設計への入力であるいくつかの主要パラメータがある。
【００５５】
ソースブロック構造の設計における１つの可能な主要入力パラメータは、ソースブロック継続時間である。あるソースブロックのソースブロック継続時間は、ソースブロックが順次、すなわち、インターリーブされずに送信され、通常の速度で、すなわち、本質的に通常の再生速度で送信される場合、そのソースブロックから生成されるシンボルが送信されることになる継続時間として定義することができる。あるいは、ソースブロック継続時間は、ソースブロックによって表される映像の再生時間になるように定義することができる。いくつかの場合、これら２つの定義は、一致するが、一致しない場合もある。しかし、簡単にするために、本明細書における説明では、どの定義を意味するかを指定することなく、２つの定義が一致すると簡単に仮定して、ソースブロック継続時間を使用する。２つの定義が一致しない場合でさえ、またソースブロックがその再生レートよりかなり速く送信され得る一部の場合でさえ、本明細書に記載した方法およびプロセスがソースブロック継続時間のいずれかの定義に関することを、当業者であれば認識されよう。さらに、例えば、ソースブロック内のシンボル数、およびソースブロックのシンボルサイズを指定することによって、ソースブロックのサイズまたは再生時間を指定する他の方法があることを、当業者であれば認識されよう。
【００５６】
ソースブロック送信が、いくつかのソースブロックからの複数のパケットの送信と他のいくつかのソースブロックからの複数のパケットの送信をインターリーブするかどうかにかかわらず、ソースブロックの保護期間はソースブロックが送信される期間である。ソースブロックインターリービングが使用されない場合、保護期間は、一般に、ソースブロック継続時間に等しいが、保護期間は、インターリービングが使用されるときのソースブロック継続時間より長く、時として、かなり長い可能性があることに留意されたい。
【００５７】
ソースブロックの保護量は、該ソースブロック内のソースシンボルの数の分数または割合として表される、該ソースブロックで送信されるＦＥＣリペアシンボルの数である。例えば、保護量が２０％であり、ソースブロック内に１０，０００個のソースシンボルがある場合、該ソースブロックから生成されたリペアシンボルは２，０００個ある。保護量は、相対的な概念であり、すなわち、同じソースブロックの保護量は、ソースブロックがどこから送信されるか、およびソースブロックがどこに送信されるかによって変わり得る。例えば、ソースブロックは、保護量５０％で第１のサーバから別のサーバに送信される可能性があり、一方で、同じソースブロックは、保護量１０％で第２のサーバから受信機に送信される可能性がある。
【００５８】
ソースブロック継続時間およびソースブロック当たりの保護量は、ソースブロックによって変わり得る。例えば、ソースブロックが、あるソースストリームのいくつかのソースパケット間にまたがらないことが好ましいとき、例えば、第１のパケットがＭＰＥＧ２ビデオストリームにおけるＧｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ（ＧＯＰ）の最後のパケットであり、第２の連続するパケットが次のＧＯＰの最初のパケットであるとき、ソースブロックは、第１のパケットの後に終了し、新しいソースブロックが第２のパケットで開始することがある。これによって、ＦＥＣ符号化ブロックをビデオ符号化ブロックに揃えることができ、これは、受信機でのビデオバッファリングとＦＥＣバッファリングとの組合せを最低限に抑える可能性のために、受信機待ち時間またはチャネルザッピング時間を最低限に抑えることができるという利点を含めて、多くの利点があり得る。他の用途では、様々な理由のために、連続する各ソースブロックについて、同じソースブロック継続時間および／またはソースブロックサイズを常に維持することが有利であり得る。以下の説明の一部では、簡単にするために、ソースブロック継続時間および保護量は、その後の各ソースブロックについて同じと仮定される。当業者には、本開示を読んだ後、これは、限定的ではないことが明らかであるはずである。というのは、本開示を読むと、保護量またはソースブロック継続時間のいずれか、またはその両方がソースブロックによって変わるとき、およびソースブロックサイズが変わるとき、本明細書に記載されたプロセスおよび方法をどのように適用するかも容易に決定することができるからである。
【００５９】
以降の説明の一部を簡単にするために、ソースシンボルが受信される第１のソースブロックにおいて、ソースシンボル損失がなく、その後の各ソースブロックにおいて、符号化シンボルの損失が、多くてもＦＥＣ復号が成功することを可能にする最大値であることを前提として、時として、元のストリームの複数のソースシンボルが、安定したレートで、ソースブロック形成およびＦＥＣ符号化を行うための送信機に到着し、いったんＦＥＣ受信機が、まず受信機でソースシンボルを使用できるようにすると、その後のソースシンボルは、ＦＥＣ受信機によって、同じ安定したレートで使用可能になると仮定される。この簡素化の仮定は、引き続き説明するプロセスおよび方法の動作または設計に固有ではなく、決してこれらのプロセスをこの仮定に制限するものではなく、単に、プロセスおよび方法の特性の説明の一部を簡単にするためのツールとして導入される。例えば、様々なレートストリームでは、対応する条件は、ソースシンボルが、送信機に到着するのと同じレート、またはそれに近いレートで、ＦＥＣ受信機によって使用可能になることである。いくつかの用途では、コンテンツザッピング時間を最低限に抑えるために、受信機で復号されたソースシンボルをできるだけ早くビデオプレーヤに配信することが好ましく、こうした場合、ソースシンボルは、複数のソースブロックのバーストで配信され得る。いくつかの用途では、ソースブロックの形成、ＦＥＣ符号化、および送信のステップを２つ以上の異なるステップに分けることが望ましい。例えば、後述するように、ソースブロックの形成およびＦＥＣ符号化は、１つのサーバで行うことができ、符号化ストリームは、次いで、複数のサブストリームに分割され、次いで、該複数のサブストリームは、１つまたは複数の分散サーバに送信され、ローカルにキャッシュされ、その後、該複数のサブストリームの一部またはすべては、１つまたは複数の分散サーバのうちのいくつかから受信機に送信される。
【００６０】
最低限に抑えることが重要ないくつかの主要メトリクスは、送信機によってもたらされる待ち時間である送信機待ち時間を含む。送信機待ち時間を最低限に抑えることは、ライブビデオストリーミングなどのいくつかの用途、またはテレビ会議など対話型の用途で望ましい。送信機待ち時間を最低限に抑えるのを助ける総合的な設計の１つの態様は、送信機が、あるストリームの最初のソースブロック（群）の符号化シンボルを連続する順序で受信機に送信することである。送信機待ち時間を最低限に抑える他の設計の態様については後述する。
【００６１】
別の重要なメトリクスは、コンテンツザッピング時間である。図２に示すように、これは、受信機がストリームに加わり、またはストリームを要求したときと、ＦＥＣ受信機が最初にストリームからソースシンボルを使用可能にしたときまでの間の時間である。一般に、例えば、ビデオストリームの再生の場合など、ストリームに受信機が参加したときと、ストリームが最初に受信機で使用可能になり始めたときとの間の時間量を最低限に抑えるため、コンテンツザッピング時間を最低限に抑えることが望ましい。コンテンツザッピング時間を最低限に抑える１つの重要な態様は、送信機が最初のソースブロックの符号化シンボルの元の送信順を維持することであるが、後述するように、コンテンツザッピング時間に大きい影響を与える他の多くの重要な設計態様がある。
【００６２】
コンテンツザッピング時間は、一般に複数の成分を備える。図３Ａおよび図３Ｂに、連続した複数のソースブロックに分割されるストリームについてのこれらの成分の一例が示されており、ここではインターリービングは使用されていない。図３Ａは、保護期間当たりの単一ソースブロックを示し、この例は、ソースブロックの先頭で受信機がストリームに参加する場合を示す。この例では、コンテンツザッピング時間の２つの成分は、保護期間およびＦＥＣ復号待ち時間である。ソースブロックの受信機保護期間は、受信機がソースブロックから受信した符号化シンボルをバッファリングしている時間である。送信機保護期間および受信機保護期間は、送信機と受信機との間のチャネルが、各ビット、バイト、シンボル、パケットが送信機から受信機に移動するためにかかる時間量においてどんな変動も有していない場合、同じであることに留意されたい。したがって、実際には、配信におけるネットワークタイミングの変動のために、送信機保護期間は、同じソースブロックについて、受信機保護期間と異なり得る。
【００６３】
ここでの説明を簡単にするために、送信機保護期間および受信機保護期間は、ソースブロックごとに同じである（および「保護期間」は、送信機保護期間および受信機保護期間について同意語として使用される）と仮定するが、これは、常にそうでならなければいけないというわけではない。言い換えれば、ネットワーク配信時間がすべてのデータについて同じであるという仮定がある。当業者であれば、本開示を読んだ後、ネットワーク配信の変動のために、送信機保護期間と受信機保護期間との差を考慮に入れるために、必要な変更を、本明細書に記載した方法および装置に加えることができる。
【００６４】
コンテンツザッピング時間の保護期間成分は、不可避である。というのは、第１のソースブロックにおいて、任意のソースシンボルの損失がない場合でさえ、その後のソースブロックにおける符号化シンボルの損失があるとき、すべてのその後のソースシンボルのスムーズなソースシンボルの配信を確実にするために、少なくとも保護期間の間、ソースシンボルを使用可能にするのを送らせる必要が依然としてあるからである。保護期間中、ソースブロックのＦＥＣ復号の一部、ほとんど、またはすべては、符号化シンボルの受信と同時に起こり得る。保護期間の最後に、ソースブロックの第１のソースシンボルがＦＥＣ受信機から使用可能になる前に起こる追加のＦＥＣ復号がある可能性があり、この期間は、図３Ａにおいて、ＦＥＣ復号待ち時間と表記されている。さらに、第１のソースシンボルが使用可能になった後でさえ、ソースブロックの第２のソースシンボルおよびその後のソースシンボルが使用可能になる前に行われる追加のＦＥＣ復号があり得る。簡単にするために、この追加のＦＥＣ復号は、図３Ａには示されておらず、この例では、第１のものの後のすべてのソースシンボルを十分速いレートで復号するのに十分使用可能なＣＰＵリソースがあると仮定する。
【００６５】
コンテンツザッピング時間の別の可能な成分は、受信機がストリームに加わることを要求したときと、そのストリームの第１のパケットが受信機に到着したときとの間の時間とすることができる。この時間量は、可変であり、受信機と、そのストリームのパケットの１つまたは複数の送信機との間の往復時間に依存し得る。コンテンツザッピング時間のこの成分は、本明細書には詳しく記載されていないが、時として、これは、考慮されるべきコンテンツザッピング時間の重要な誘因であり得ること、およびコンテンツザッピング時間のこの潜在的な誘因を考慮に入れるために、本明細書に記載した方法およびプロセスを容易に変更できることを当業者であれば認識されよう。
【００６６】
図３Ｂは、図３Ａに示される例に対応し得る２つの潜在的なＦＥＣ復号のＣＰＵ使用率曲線を示す。図３Ｂに示される２つの曲線のうちの１つにおいて、ＦＥＣ復号に使用されるＣＰＵ使用率は、各時点において同じであり、すなわち、ＣＰＵ使用率は、一様に分散される。各時点で同じ量のＣＰＵリソースを予測的に使用し、ソースブロック全体を復号するのに、同じ量の総ＣＰＵリソースが必要とされると仮定して、最大ＣＰＵリソースを最低限に抑えるため、これは、望ましいＣＰＵ使用率曲線である。図３Ｂに示した２つの曲線のうちの他方では、ＦＥＣ復号に使用されるＣＰＵ使用率は、各時点で同じではなく、特に、ソースブロックの符号化シンボルの受信の最後に向かう、およびその直後でのＣＰＵ使用率は、他の時点よりかなり高い。ＣＰＵリソース使用量が、他のプロセス、例えばビデオプレーヤなどもＣＰＵに負担をかける時点であり得るある時点でスパイクし、したがって、例えば、映像ストリームの再生におけるトラブルをもたらす可能性を引き起こすため、これは、望ましいＣＰＵ使用率曲線ではない。したがって、ストリームを保護するＦＥＣソリューションの設計は、ＦＥＣ復号器ができるだけ時間にわたってスムーズで一様にＣＰＵを使用するソリューションを提供することである。一例として、設計基準は、符号化シンボル損失の最悪の場合のパターン下のＦＥＣ復号プロセスにおいて、任意の時点の最大ＣＰＵ使用率がある閾値を下回ること、例えば、各１００ミリ秒の間隔にわたってＣＰＵの多くて１０％を使用することであり得る。
【００６７】
いくつかのストリーミングの用途では、受信機がソースブロックの途中でストリームに加わってしまった場合、元の送信順およびソースパケットの配信速度が最初に送信機によって維持される限り、コンテンツザッピング時間は、ソースブロック継続時間と、その第１の部分的ソースブロックからのソースシンボルの損失がないときの復号待ち時間とを加算したのと同じほど小さくなり得る。他のビデオストリーミングの用途では、送信機は常に、ＧＯＰの先頭から受信機にストリームを送信し始め、この場合、ソースブロックの先頭は、ＧＯＰの先頭に揃えられることが好ましい。したがって、コンテンツザッピング遅延を最低限に抑えるために、送信機が、最初のソースブロックのソースシンボルの元の送信順を維持することが望ましい。
【００６８】
ＦＥＣエンドツーエンド待ち時間を最低限に抑えるために、ＦＥＣストリーミングソリューションを使用することもできる。ＦＥＣエンドツーエンド待ち時間は、ライブストリーミングの用途の場合、ソースパケットがＦＥＣ符号化の適用前に送信機でのストリーミングの用意ができているときと、ＦＥＣ復号の適用後、受信側での再生に使用可能であるときとの間にＦＥＣの使用によってもたらされる最悪の場合の全待ち時間である。オンデマンドのストリーミングまたはプレイリストコンテンツストリーミングなど、他のタイプのストリーミングの用途の場合、ＦＥＣエンドツーエンド待ち時間は、大きな問題ではない。
【００６９】
すべてのタイプのストリーミングの用途では、コンテンツザッピング時間およびコンテンツ遷移時間を最低限に抑えることが重要である。同時に、ストリームの送信レートを最低限に抑えること、すなわち、コンテンツザッピング中およびコンテンツ遷移中も含めて、常に送信レートを制約して、コンテンツストリーミングレートをほんのわずか上回るようにすることが重要である。
【００７０】
ＦＥＣストリーミングソリューションは、ＦＥＣが使用されるとき、送信レートの変動を最低限に抑えるために使用することもできる。この１つの利点は、パケットネットワーク内で、ストリームの送信レートのピークと他のトラフィックのピークとが、制限された容量のネットワークにおける地点で一致するとき、送信レートが変動するストリームが、輻輳またはバッファオーバーフローが原因のパケット損失をより受けやすいことである。少なくとも、ＦＥＣ符号化ストリームのレートの変動は、元のソースストリームのレートの変動より悪くないものとし、より多くのＦＥＣ保護が元のソースストリームに適用されると、ＦＥＣ符号化ストリームのレートの変動がより小さくなることが好ましい。特別な場合として、元のストリームが一定のレートで送信する場合、ＦＥＣ符号化ストリームができるだけ定数に近いレートで送信されることが好ましい。
【００７１】
その後の各ソースブロックの最後の符号化シンボルが受信されるときが時間にわたってできるだけ一様に分配されるという特性は、望ましい特性である。あるソースブロックの最後の符号化シンボルが受信されたときは、ソースブロックの復号についてのすべての情報がＦＥＣ復号器から使用可能であるときであり、これは、一般に、ＦＥＣ復号器が所定の復号待ち時間バジェット内で復号を終えるために、最も激しく働く必要があるという最悪の場合の損失条件下のときである。したがって、ソースブロックの最後の符号化シンボルの受信を一様に分配することによって、ＦＥＣ復号のためのＣＰＵの使用をスムーズにすることができる。
【００７２】
ＦＥＣストリーミングソリューションは、ＦＥＣ受信機でできるだけ簡単なロジックを提供するものとする。ＦＥＣ受信機を、制限された計算、メモリ、および他のリソース機能を備える装置に構築することができるため、これは、多くの状況で重要である。さらに、いくつかの場合、伝送時にシンボルのかなりの損失または破損がある可能性があり、したがって、ＦＥＣ受信機は、条件が向上したとき、ストリームの受信が続く場所を理解するためのコンテキストがほとんどあるいはまったくない、破局的損失または破損シナリオから回復しなければならない場合がある。したがって、ＦＥＣ受信機ロジックが簡単で頑強であればあるほど、ＦＥＣ受信機は、迅速かつ確実に、回復を開始し、ＦＥＣ符号化ストリームの受信からソースストリームのソースシンボルを再度使用可能にすることができる。
【００７３】
ソースブロックのリペアパケットを送信するのは、ソースブロックのソースパケット前、後、または混合のいずれでもよく、本明細書で説明するように、それぞれの戦略に利点がある。
【００７４】
ＦＥＣストリーミングソリューションの包括的な望ましい特徴のうちの一部は、以下を含む。
【００７５】
１．短いコンテンツザッピング時間。
【００７６】
２．短いコンテンツ遷移時間。
【００７７】
３．常に送信ストリームレートを制約して、すなわち、コンテンツストリームレートをほんのわずか上回るようにするものとする。
【００７８】
４．送信ストリームレートは、スムーズであるものとし、少なくともコンテンツストリームレートと同じぐらいスムーズであるものとする。
【００７９】
５．ＦＥＣ符号化が使用されるとき、ソースブロックの形成およびＦＥＣ符号化を、あるストリームに実行することができ、同じ符号化ストリームを、場合によっては異なる時に多くの受信機に送信することができる。
【００８０】
６．ＦＥＣ符号化が使用されるとき、特に、損失が本質的に多少バースト的であるとき、必要な最低限の保護量を有する小さいソースブロック継続時間を使用して、パケット損失に対する保護を高いものとする。
【００８１】
７．ＦＥＣ符号化が使用されるとき、複数のソースブロックは、１つのストリームの隣接した部分を含むものとする。
【００８２】
８．ライブストリーミングの用途のＦＥＣ符号化のとき、ＦＥＣエンドツーエンド待ち時間は、小さいものとする。
【００８３】
９．ＦＥＣ符号化が使用されるとき、ＦＥＣ復号は、ＣＰＵ使用率をスムーズに分配するものとする。
【００８４】
＜ＦＥＣ符号化ストリームの基本的な送信＞
本セクションでは、送信機が、ＦＥＣ符号化することができるストリームのパケットの送信の時間を決める基本的な方法およびプロセスを説明する。ｋをソースブロックにおけるソースシンボルの数とし、Ｔをそのソースブロックについてのソースブロック継続時間とし、ｐを分数として表される保護量とすると、そのソースブロックについて、ｐ＊ｋ個のリペアシンボルが送信される。ｋ、Ｔおよびｐの値は、各ソースブロックが形成されているときに、動的に決定することができ、したがって、そのソースブロックのソースシンボルのほとんどまたはすべてがプロセスに到着したとき、ソースブロックのｋおよびＴの値は、ソースブロックの形成プロセスのみに知られるようにし、ｐの値は、ソースブロックのすべてのソースシンボルがソースブロック形成プロセスに到着した後、または個別のプロセスによって決定することができる。また、ソースブロック形成プロセスは、異なるソースブロックごとにシンボルサイズを変え得る。したがって、特定のソースブロックのこれらのパラメータの多くまたはすべては、そのソースブロックのデータを受信中のソースブロック形成プロセスに知られている可能性がある。
【００８５】
以下のプロセスでは、インターリービングを使用しない基本的な送信機について説明する。簡単にするために、この基本的な送信機について、ソースブロック形成プロセスがストリームにすでに適用されており、それが連続するソースブロックに分割されており、こうしたソースブロックの各個がｋ個のソースシンボルを含み、Ｔ秒のソースブロック継続時間で、こうしたソースブロックごとに、ｐ＊ｋ個のリペアシンボルがすでに生成されていると仮定する。
【００８６】
受信機がストリームを特定のソースブロックからの開始を要求する（または受信機からの明示的な開始要求によってストリームを先行送信させる）と、基本的な送信機は、Ｔ秒の期間にわたって、要求されたソースブロックの（１＋ｐ）＊ｋ個の符号化シンボルの送信を開始し、その後、要求されたソースブロックの後、次のソースブロックの符号化シンボルを送信する、といった具合である。
【００８７】
基本的な送信機は、以下の特性を有する。
【００８８】
１．保護期間はＴであり、これは、ソースブロック継続時間と同じである。
【００８９】
２．送信されたソースブロックのシンボルは、Ｔ秒の期間にわたって一様に分配される。これは、一定の継続時間のバースト停止（burst outage）があるとき、損失に対して提供される保護のレベルは、シンボルの送信中に停止が起こるときに依存しないことを含意し、これは望ましい。
【００９０】
３．送信機は、シンボルの全体的な送信レートの変動をもたらさない。特に、ソースシンボルの元の送信レートが一定である場合、すべてのシンボルの送信レートは、依然として一定であり、送信機でのソースシンボルの元の到着レートが可変であるとき、少なくともソースブロック当たりのシンボルの一定の送信レートが変動を減衰させる。これは、望ましい特性である。
【００９１】
４．コンテンツザッピング時間は、Ｔと同じぐらい小さくすることができる。これは、（すべてのソースブロックがｋ個のソースシンボルを含むと仮定すると）（１＋ｐ）＊ｋ個のシンボルの最低バッファリングを含意し、これは、所与の保護期間について可能な最低値であり、したがって望ましい。
【００９２】
基本的な送信機が有する１つの特性は、コンテンツザッピング時間は、少なくとも１保護期間分の時間であり、保護期間は、バースト的損失に対する保護の品質に直接関係するということである。したがって、保護期間とコンテンツザッピング時間との間で行う必要がある妥協がある場合がある。例えば、１秒未満のコンテンツザッピング時間を有することが望ましく、一方で、一時的なネットワーク停止、または数１０あるいは数１００ミリ秒程度、およびいくつかの場合では数秒続く可能性がある、バースト的パケット損失をもたらす他のタイプの断続的なネットワーク問題に対してより良い保護を提供するために、数秒にまたがる保護期間を有すると共に、同時に１０％などの適度に小さい保護量を使用することも望ましい。コンテンツザッピング時間よりかなり大きい保護期間を有することができることが望ましく、これは、次のセクションで説明するインターリービング方法が提供する多くの利点のうちの１つである。
【００９３】
＜ストリームインターリービング＞
このセクションでは、データのストリームをとり、送信プロセスで、ある部分が他の部分より多く遅延するように、差分時間遅延をデータストリームの異なる部分に適用するための新規の方法およびプロセスについて説明する。これらの方法およびプロセスのうちのより重要な態様のうちの１つは、データストリームが送信されるときに、ストリームの異なる部分に含まれる遅延の量を動的に調整するための手段である。
【００９４】
コンテンツザッピング時間を最低限に抑え、ストリームのより良い保護を提供するために、ソースブロックをＧｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ（ＧＯＰ）構造またはビデオストリームの他のフレーム構造に揃えることがしばしば好ましい。いくつかの用途では、インターリービングプロセスが、ソースブロック形成プロセスとは関係なく、場合によっては、異なる時間に行われる、または場合によっては、異なる場所で行われることができることが望ましい。いくつかの場合、例えばＦＥＣ符号化が使用されないために、たとえソースブロック形成プロセスが使用されなくても、例えば、ストリームを介してバースト的誤りをより均等に分配するために、場合によっては、インターリービングプロセスが望ましい。当業者であれば認識されるように、本明細書に記載した方法は、ソースブロック形成およびＦＥＣ符号化が使用されないときでさえも適用される。
【００９５】
いくつかの場合、各ソースブロックのシンボルをソースブロック継続時間より長い保護期間にわたって分配することができるように、送信機が異なるソースブロックからシンボルの送信をインターリーブするのを可能にするための利点があり得る。これを行う１つの理由は、時間に依存した損失（例えば、バースト的損失）に対して、より良い保護が提供されるからであり、すなわち、ソースブロックの保護期間が大きくなるにつれて、一定の継続時間のバースト損失に対して保護を提供するのに、より小さい保護量が必要とされるからである。ソースブロック継続時間は、ｔ秒とすることができ、ソースブロックの望ましい保護期間は、ｐ秒とすることができ、この場合、ｐ＞＞ｔである。インターリービングを使用する送信機の他の望ましい特性は、以下を含む。（１）ソースパケットがソースブロック内の元の順で送信される、（２）その後の各ソースブロックの最後の符号化シンボルが受信される時間は、時間にわたってできるだけ一様に分配される。
【００９６】
ＦＥＣ符号化が使用されるとき、ソースブロックの符号化シンボルの送信を静的にインターリーブする方法が導入され、ストリームが送信されるにつれてインターリービングの量を動的に調整する方法が導入され、一般には、ストリームの送信の開始時にはインターリービングがほとんどあるいはまったくなく、したがって、ソースブロック継続時間とほぼ同じ保護期間で、ストリームの送信が進むにつれて、ますます多くのインターリービングがスムーズに導入され、したがって、保護期間は、ソースブロック継続時間よりかなり長くなるまで増大する。これによって、コンテンツザッピング時間を、受信機で最低限に抑えると共に、送信が進むにつれてバースト的損失または破損に対する保護をますます増やすことができる。記載した方法の他の利点は、ストリームの送信が進むにつれて、ますます多くのネットワークジッタに対して徐々に保護を行うことができることである。
【００９７】
以下の説明を簡単にするために、ストリームの送信前にソースブロック形成およびＦＥＣ符号化プロセスが行われると仮定する。これは、方法の限定ではなく、当業者であれば認識されるように、ソースブロックを形成し、これらのソースブロックにＦＥＣ符号化を実行し、後述するようにストリームを送信するプロセスは、同時に行うことができ、一部の場合、これは、有利である。さらに、いくつかの用途では、ソースブロック形成、ＦＥＣ符号化プロセス、およびストリームのインターリーブ式の送信について後述する方法は、動的に独立していてよく、すなわち、ソースブロックがどのように形成され、ＦＥＣ符号化されるかは、いくつかの場合、送信ストリーム戦略に依存し得る。
【００９８】
＜ストリーム送信のテープ（tape）方法＞
新しいインターリービング方法を説明するために、以下のストリーム送信のテープ方法を述べることが有用である。図４は、ソースブロック構造がすでに決定されているコンテンツストリームの例示的な図である。各ソースブロック４０５（１），４０５（２），・・・について、幅４１０（１），４１０（２），・・・は、そのソースブロックのコンテンツ再生継続時間を示し、各ソースブロックの高さ４１５（１），４１５（２）は、各コンテンツストリームソースブロックの平均再生レートを示し、この例では、異なるソースブロックは、異なる再生レートを有する。
【００９９】
図５は、図４に対応する符号化ブロック構造を示しており、すなわち、ＦＥＣ符号化が各ソースブロックに適用されて、ソースブロックごとに追加のリペアデータ５１０（１），５１０（２），・・・を生成し、符号化ブロックを形成する。５１０（１），５１０（２），・・・の高さ５１５（１），５１５（２），・・・は、各符号化ブロックにおけるソースブロックごとに生成された追加のリペアデータの量を示し、すなわち、対応するソースブロックと同じ継続時間にわたって符号化ブロックが送信される場合、高さは、符号化ソースブロックの平均送信レートを示す。この図は、例示にすぎず、これに限定するものではなく、例えば、符号化ブロックごとに生成されたリペアデータの量は、符号化ブロックごとに送信された量よりかなり大きくてもよく、符号化ブロックごとに送信された量は、受信機によって変わり得る。さらに、図５は、符号化ソースブロック内のソースシンボルおよびリペアシンボルの順序の表示を示唆するものではない。
【０１００】
図６は、基本的な送信機の方法に対応する受信機によるコンテンツザッピング時間経験を示す例示的な図である。コンテンツザッピング時間６０５の複数の成分のいくつかは、受信機が、第１のソースブロックを復号するのに十分なだけ、ストリームの第１の符号化ブロックを受信するためにかかる時間６１０、受信機が第１の符号化ブロック６２０の受信された部分から第１のソースブロックを復号するためにかかる時間、およびネットワークジッタ、ソースブロック継続時間の変動、およびストリームの受信中に受信された符号化ブロックの部分からのソースブロックの復号時間を吸収するために確保される予備バッファ時間６３０を含む。
【０１０１】
ストリームを送信するテープ方法について説明しており、類似の方法を生成する同等の説明や、本明細書に記載される方法の変形を生成するこの説明の変形が多く存在することを当業者であれば認識されよう。図７は、図５に示される符号化ブロック構造に対応するテープ方法の一例を示す。該テープ方法において、データのストリームの送信は、ストリームがテープ７０５として送信されることを表すことによって示され、ここでは、テープのＸ軸に沿った各位置７１０が符号化ブロック構造における異なる時点に対応し、テープの高さは、常に同じであり、例えば、テープに沿ったその時点での符号化ソースブロックのレートに関係なく、名目上高さ１など、常に同じである。テープによって表されるストリームの送信は、テープの最上部７２５からテープの最下部７３０に至る移動線７２０（１），７２０（２）によって示すことができる。一表現において、時間にわたる線７２０（１），７２０（２）の移動は、ストリームの符号化ブロックからのデータの送信順を表す。テープ内の各点７４０（１），７４０（２），・・・は、送信すべきストリームデータ片を表し、例えば、各点は、符号化ブロックの符号化シンボルのパケットを表し、または各点は、符号化ブロックの個々の符号化シンボルを表し得る。符号化ブロック７５０（１），７５０（２），・・・に対応する領域内に含まれる点は、その符号化ブロックに関連付けられるデータを表す。
【０１０２】
ストリームを送信するテープ方法による送信のプロセスは、ストリームが送信されるにつれて、時間にわたってテープを横切って線７２０（１），７２０（２）をスィープ（sweep）することによって表され、線が点をスィープするたびに、その点に対応するストリームのデータが送信される。図７は、送信プロセスにおける異なる２つの時点での線を示し、線７２０（１）は、第１の時刻におけるその構成であり、線７２０（２）は、第２の時刻におけるその構成である。したがって、送信プロセスは、第１の時刻と第２の時刻との間の時間間隔中、７２０（１），７２０（２）、７２５および７３０によって囲まれた領域内の点に関連付けられているすべてのデータを送信する。各符号化ブロック内の点の分散は、その重さに従って、その符号化ブロックについて、テープエリア内で一様に分散されることが好ましく、例えば、ランダムに分散される、または疑似ランダムに分散される、または点の重さがその点によって表されるデータの量である場合、各点の重さに従って点が一様に分散されることを確実にするプロセスによって決定論的に分散される。
【０１０３】
上述したように、線７２０は、直線であるが、当業者であれば認識するように、多くの変形があり、例えば、線は、曲線でもよく、または連続する線セグメント系列を備えていてもよい。また、線は、送信プロセス中に横切ってスィープするとき、その形状を変えてもよい。テープ送信方法は他にもいくつかの変形があり、そのなかには、変形テープが同じ高さのものではなく、代わりに、その高さは、テープのその位置７１０でのストリームのレートに従って変わるようにテープを表すことを含む。
【０１０４】
以下で詳述されるように、送信プロセス中、テープにわたる線の移動を指定する様々な方法がある。
【０１０５】
＜静的インターリービング方法＞
ストリームを送信するテープ方法は、ＦＥＣ符号化が使用されるかどうかにかかわらず、またソースブロック構造が使用されるかどうかにかかわらず、任意のタイプのコンテンツストリームまたは符号化コンテンツストリームについて、任意の深さの静的インターリービングを達成するために使用することができる。説明上、ソースブロック構造は、すでに定義されており、ＦＥＣ符号化が使用されると仮定する。
【０１０６】
ストリームを送信するテープ方法を使用した所与の量の静的インターリービングを達成する１つの方法について、一例により図７を参照して説明する。この例では、各符号化ブロックは、時間量Ｄごとに他の隣接する符号化ブロックでインターリーブされ、すなわち、インターリービング深さはＤである。この例では、ストリームを要求するとき、受信機は、位置ＸおよびＤの値を伝える。次いで、送信機での送信プロセスは、最初に線７２０とテープの最下部７３０とが位置Ｘ−Ｄで交差し、最初に線７２０とテープの最上部７２５とが位置Ｘで交差するように線７２０を構成し、次いで、送信プロセスが、ストリームの再生レートと同じレートで、時間を順方向に線７２０をスィープする、すなわち、送信プロセス開始後の時刻ｔで、線７２０とテープの最下部７３０とが位置Ｘ−Ｄ＋ｔで交差し、線７２０とテープの最上部７２５とが位置Ｘ＋ｔで交差するように、線７２０が横切ってスィープしていることによって説明される。
【０１０７】
静的インターリービング方法のこの説明において、新しく要求されたストリームを受信機に送信するために該方法が使用されている場合、ストリームにおいて、受信機で再生が開始する位置にＸがあることが有利であり、例えば、Ｘは、符号化ブロックの先頭の位置、またはＸは、ビデオストリームにおけるＧＯＰの先頭の位置であり、符号化ブロックの先頭は、ＧＯＰの先頭に揃えられる。さらに、こうした場合、一般に、受信機は、符号化ブロックのある一部分のみを受信し、部分的に受信された符号化ブロックを完全に復号するのに十分ではない可能性が高いため、送信機が、テープに沿って位置Ｘの前に、受信機に任意のデータを送信しないことが有利である。
【０１０８】
図８は、送信機が先に説明した静的インターリービング方法を使用しているとき、送信されたストリームの形状を例示する例示的な図である。この場合、静的インターリービング方法は、図５に示された符号化ストリームに対応する、図７に示されるテープに適用される。この例では、受信機は、Ｘの値を、図７における第１の符号化ブロック７５０（１）の開始の位置と指定し、したがって、この例では、位置Ｘの前に、テープに沿って送信されるべきデータはない。この例では、受信機は、Ｄの値も指定し、これは、１０秒などの値とすることができる。このプロセスに従って送信機によって送信された結果として得られたストリームは、図８に示され、この場合、８５０（１），８５０（２），・・・のエリアは、それぞれ図５の４０５（１）＋５１０（１）、４０５（２）＋５１０（２），・・・などのエリアと同じである。図８に示すような送信レートは、図５に示すような元のコンテンツレートの平滑化されたバージョンであることに留意されたい。
【０１０９】
図９は、上述した静的インターリービング方法に対応する受信機によって経験されるコンテンツザッピング時間を示す例示的な図である。コンテンツザッピング時間９０５の成分の一部は、受信機が、第１のソースブロックを復号するのに十分なだけストリームの第１の符号化ブロックを受信するためにかかる時間であって、ソースブロック継続時間とインターリービング深さＤとの合計である時間９１０、受信機が第１の符号化ブロック９２０の受信された部分から第１のソースブロックを復号するためにかかる時間、および予想されるネットワークジッタ遅延、ソースブロック継続時間の変動、およびストリームの受信中に受信された符号化ブロックの部分からのソースブロックの復号時間のために確保される予備バッファ時間９３０を含む。保護期間は、この場合、ソースブロック継続時間＋インターリービング深さＤであり、ソースブロック継続時間よりかなり大きくなり得るため、コンテンツザッピング時間９０５は、記載したように、この方法を使用すると、ソースブロック継続時間よりかなり大きくなり得ることに留意されたい。
【０１１０】
＜動的インターリービング方法＞
ストリームを送信するテープ方法は、ＦＥＣ符号化が使用されるかどうかにかかわらず、またソースブロック構造が使用されるかどうかにかかわらず、任意のタイプのコンテンツストリームまたは符号化コンテンツストリームについて、任意のペースの任意のインターリービング深さで、動的インターリービングを達成するために使用することができる。説明上、ソースブロック構造は、すでに定義されており、ＦＥＣ符号化が使用されると仮定する。
【０１１１】
ストリームを送信するテープ方法を使用し、インターリービング無しで開始して、所与のインターリービング深さまで進む動的インターリービングを達成する１つの方法について、一例を図７を参照して説明する。この方法の一般的な使用では、第１の符号化ブロックは、わずかのインターリービングで送信され、次いで、インターリービング深さＤが達成されるまで、徐々に、時間が経つにつれて、他の隣接する符号化ブロックでその後の符号化ブロックがますますスムーズにインターリーブされる。しかし、この方法の他の使用についても、以下で説明し、当業者であれば認識されるように、他の様々な変形もある。方法のパラメータを表すこの例の方法では、ストリームを要求すると、受信機は、線７２０についての最初の上部位置ＵＩ、線７２０についての最初の下部位置ＬＩ、線７２０についての最後の上部位置ＵＦ、線７２０についての最後の下部位置ＬＦ、および時間値Ｔを伝える。簡単にするために、以下、ＵＦ≧ＵＩ、ＬＦ≧ＬＩ、ＵＦ≧ＬＦ、ＵＩ≧ＬＩ、Ｔ≧０と仮定する。一般に、必要に応じて受信機でのデータが常に使用可能であることを確実にするのを助けるために、ＵＦ≧ＵＩ＋ＴおよびＬＦ≧ＬＩ＋Ｔであることが好ましい。以下、この例で説明するように、ＵＦ、ＵＩ、ＬＦ、ＬＩ、およびＴのこれらの値は、インターリービングが動的に調整されるにつれて、コンテンツの予備バッファを受信機でスムーズに増加することができるようにする。
【０１１２】
送信機での送信方法は、パラメータＬＩ、ＵＩ、ＬＦ、ＵＦ、およびＴを使用して以下のようにテープ方法を実行する。まず、図７の線７２０は、最初に送信時刻ｔ＝０で、最初に線７２０とテープの最下部７３０とが位置ＬＩで交差し、最初に線７２０とテープの最上部７２５とが位置ＵＩで交差し、次いで、送信時刻ｔ＝０からｔ＝Ｔまでの間、時刻ｔで、線７２０とテープの最下部７３０とが位置ｔ＊（ＬＦ−ＬＩ）／Ｔ＋ＬＩで交差し、時刻ｔで、線７２０とテープの最上部７２５とが位置ｔ＊（ＵＦ−ＵＩ）／Ｔ＋ＵＩで交差するように、線７２０がテープを横切ってスィープされるように構成される。次いで、送信時刻ｔ＞Ｔのすべてにおいて、時刻ｔで、線７２０とテープの最下部７３０とが位置ｔ−Ｔ＋ＬＦで交差し、時刻ｔで、線７２０とテープの最上部７２５とが位置ｔ−Ｔ＋ＵＦで交差するように、線７２０がテープを横切ってスィープされ、すなわち、ｔ＞Ｔの場合、インターリービングは、静的であり、Ｄ＝ＵＦ−ＬＦのインターリービング深さが使用される。
【０１１３】
＜新しく要求されたストリームについての動的インターリービング方法＞
動的インターリービング方法の一使用例は、受信機に新しく要求されたストリームを送信することである。一例として、図１０に示されるように、初期値はすべて、同じ値Ｉ＝ＵＩ＝ＬＩに設定することができ、すなわち、最初は、インターリービングがなく、受信機がコンテンツストリームを再生し始める位置Ｓは、Ｓ＝Ｉを満たす。これにより、位置Ｓ以降のコンテンツの全テープが受信機に送信されたことが確実になる。図１０に示されるように、好ましくは、Ｓ＝ＵＩ＝ＬＩであり、この場合Ｓは、それが再生され得るコンテンツストリームにおける位置であり、例えば、Ｓは、その開始がＧＯＰの開始に揃えられる符号化ブロックの開始である。さらに、Ｔ≦ＬＦ−Ｓであることが有利である。これにより確実になるのは、受信機がコンテンツレートでコンテンツを再生する場合、コンテンツの送信が、少なくとも受信機でのコンテンツの再生と同じ速さのレートでのものであり、Ｒ＝ＬＦ−Ｓ−Ｔ秒の予備バッファ時間がスムーズに増加し、受信機への送信開始から送信時刻Ｔで静的インターリービングに到達するにつれて続き、この場合、予備バッファは、ネットワークジッタ、変化するソースブロック継続時間、および復号時間を吸収することができることである。インターリービング量は、インターリービング無しからＤ＝ＵＦ−ＬＦ秒のインターリービングまで、スムーズに増加する。
【０１１４】
動的インターリービング方法の特定の例として、受信機がごく最初からコンテンツにアクセスしており、定常状態で、５秒の予備バッファに到達し、定常状態で１０秒のインターリービング深さが望まれ、送信のレートは、インターリービングおよび予備バッファが増加している期間中、符号化ストリームレートの約１０％以上と仮定する。次いで、パラメータの可能な設定は、所望の開始位置であるＳ＝ＵＩ＝ＬＩ、Ｔ＝１００秒、ＬＦ＝Ｓ＋Ｔ＋５秒、およびＵＦ＝ＬＦ＋１０秒である。したがって、この例で、コンテンツストリームレートが１Ｍｂｐｓであり、１０％の保護量が使用される場合、符号化ストリームレートは、１．１Ｍｂｐｓとなる。次いで、ストリームの１００＋（５＋１５）／２＝１１０秒が最初の１００秒内で送信されるため、前に説明したパラメータ設定を使用した動的インターリービング方法を使用した送信の最初の１００秒間、送信レートは、約１．２１Ｍｂｐｓとなる。１００秒の送信の後、予備バッファは、５秒、インターリービング深さは、１０となり、次いで、送信レートは、その後、１．１Ｍｂｐｓとなることになる。１００秒のストリーミングが行われる直前の２、３秒の間、送信レートは、１．２１Ｍｂｐｓレートから１．１Ｍｂｐｓレートにスムーズに遷移する。最初に、送信レートは、符号化ストリームレートに従い、インターリービング深さおよび予備バッファがスムーズに増えるにつれて、送信レートは、平滑化され、ますます厳密に平均符号化ストリームレートと一致するようになることにも留意されたい。
【０１１５】
上述した動的インターリービング方法に対応する受信機によって経験されるコンテンツザッピング時間について、図１１を参照して説明する。コンテンツザッピング時間１１０５の成分の一部は、受信機が第１のソースブロックを復号するのに十分なだけ、ストリームの第１の符号化ブロックを受信するためにかかる時間１１１０、受信機が第１の符号化ブロック１１２０の受信された部分から第１のソースブロックを復号するためにかかる時間、および予想されるネットワークジッタ遅延、ソースブロック継続時間の変動、およびストリームの受信中に受信された符号化ブロックの部分からのソースブロックの復号時間のために確保される初期予備バッファ時間１１３０を含む。
【０１１６】
動的インターリービングを使用するとき、予備バッファは時間が経つにつれて増加するため、動的インターリービングを使用するとき、初期予備バッファ時間１１３０は、ストリーム送信の全継続時間の間、予備バッファサイズが固定される場合よりかなり短くなり得る。例えば、基本的なストリーム送信機を使用すると、最高２秒までの長期ネットワークジッタに対してバッファリングするために、予備バッファサイズは、２秒に設定することができる。一方、動的インターリービング式の送信方法では、ストリーム送信の最初の２、３秒の間、ネットワークジッタがわずかである可能性があり、その時点では、予備バッファは、かなり増加しているため、初期予備バッファ時間１１３０は、例えば２００ミリ秒など、かなり短い何らかの値に設定することができる。
【０１１７】
動的インターリービングを使用したとき、各ソースブロックの保護期間が徐々に増加するため、初期ソースブロック継続時間は、動的インターリービングを使用したとき、保護期間がストリーム送信の全継続時間の間そのソースブロック継続時間であるときよりかなり短くなり得る。例えば、基本的なストリーム送信機を使用すると、ソースブロック継続時間は、５秒に設定することができ、保護量は、５００ミリ秒の短いバースト的パケット損失から保護するために、２０％に設定することができる。一方、動的インターリーブ式の送信方法では、ソースブロック継続時間は、約５００ミリ秒など、かなり短い何らかの値に設定することができ、保護量は、こうしたバーストに対する同じレベルの保護を提供するために、約５％など、かなり小さい値に設定することができる。というのは、ストリームを送信する最初の２、３秒の間、こうしたバーストが起こる可能性は低く、その時点では、保護期間は、こうしたバーストから保護するために、実質的に、例えば、元のソースブロック継続時間＋１０秒のインターリービング深さまで増加している。
【０１１８】
したがって、全体的に、動的インターリービング方法を使用すると、例えば、１秒未満のコンテンツザッピング時間など、コンテンツザッピング時間は短くてよく、これに対して、同じネットワーク条件において、基本的なストリーム送信方法を使用すると、数秒であり、さらに、動的インターリービング方法は、ネットワークジッタおよびバースト的パケット損失に対して優れた長期保護を提供することができる。
【０１１９】
パラメータの指定方法には多くの変形がある。例えば、テープにおける初期開始位置を指定する代わりに、インターリービングの初期量、インターリービングの最後の量、および初期インターリービングから最後のインターリービングまでスムーズに遷移する期間を指定することができる。あるいは、初期インターリービングから最後のインターリービングまでスムーズに遷移する期間を指定する代わりに、遷移を行うためのコンテンツストリームレートに対するレートを指定することができる。変形の別の例として、追加のパラメータを送信機が知っておく、または受信機によって指定することができ、例えば、受信機は、受信機がコンテンツの再生を開始する開始位置Ｓを明示的に信号で伝えることができる。
【０１２０】
当業者であれば認識されるように、動的インターリービング方法の多くの変形がある。例えば、受信機が損失をあまり経験していないために、例えば送信機は、符号化ブロックの一部またはすべてからの符号化データの一部をフィルタにかけて除去し、個々の受信機に送信しないことを決定することができる。別の変形として、ソースブロック構造を事前に決定することができる。しかし、送信プロセスが動作するにつれて、ＦＥＣ符号化が動作して、個々の受信機のために符号化ブロックを生成していたり、以前の受信機より大きい保護量を必要とする受信機に遭遇するにつれて、時として、一部の符号化ブロックのためにリペアシンボルの大量供給を生成したりしている。
【０１２１】
しばしば好ましい別の変形として、受信機は、動的インターリービング方法の初期パラメータの設定を制御することができ、サーバまたは複数のサーバのセットは、動的インターリービング方法の最後の対象パラメータを決定することができる。例えば、受信機は、コンテンツストリームが２秒のインターリービング深さおよび１秒の予備バッファで開始されると指定することができ、次いでサーバは、２０秒のインターリービング深さおよび１０秒の予備バッファが送信の最初の２分で達成されるように送信することを決定することができる。サーバまたはサーバ群に動的インターリービング方法の最後のパラメータを指示させる１つの利点は、コンテンツストリームの現在の時間以降の部分は、使用不可であるライブストリーミングをサポートするにははるかに容易であるので、サーバは、動的インターリービングパラメータを所与の制約下で使える最後の設定に導くことができることである。サーバに最後のパラメータを指示させる利点の別の例は、サーバが、いくつかの場合、ストリーム内の基本的に同じ位置からの同じコンテンツストリームが提供されている複数のクライアントのパラメータを、最終的に受信機の多くが同じ最終パラメータに導かれるように調整することができ、これによって、同じ時点に、同じパケットが、コンテンツストリームからこれらの受信機のすべてに送信されるため、受信機にパケットを送信する際のサーバ効率につながることである。
【０１２２】
＜コンテンツセグメント遷移の動的インターリービング方法＞
動的インターリービング方法の一使用例は、受信機がコンテンツセグメントリスト内のあるコンテンツセグメントから次のコンテンツセグメントに遷移するとき、例えば、ある番組の一エピソードの一セグメントから広告に遷移し、次いで、その番組の次のセグメントに戻るときなどであり、この場合、すべての遷移は、任意の受信機の対話無しに行われる。複数の差分コンテンツセグメントは、異なる送信機によって送信することができ、例えば、番組エピソードの複数のセグメントは、コンテンツサーバによって受信機に送信することができ、一方で、間に入る広告は、広告サーバによって受信機に送信することができる。
【０１２３】
第１の例は、受信機が上述した動的インターリービング方法を使用して第１の送信機によって送信されている第１のコンテンツセグメントを見ており、第１の送信機が、完全にインターリービング深さＤおよび予備バッファ時間Ｒが増加するのに十分長い間送信しているときである。次いで、動的インターリービング方法を使用して、以下のように、第２のコンテンツセグメントへのスムーズな遷移を達成することができる。
【０１２４】
１．第１のコンテンツセグメントの送信の終了前Ｄ＋Ｒ秒に、第１のセグメントの送信レートは、Ｄ秒の期間にわたって符号化ストリームレートからゼロまで直線的に低減し、その時点で、第１の送信機は、第１のセグメントについての送信を停止する。
【０１２５】
２．第１のコンテンツセグメントが再生を終了する前のＤ＋Ｒ秒で、受信機は、ＵＩ＝０、ＬＩ＝−Ｄ、ＵＦ＝０、ＬＦ＝−Ｄ、Ｔ＝０のパラメータで、第２のサーバに第２のコンテンツセグメントを要求する。ネットワーク待ち時間が無いと仮定すると、第２のサーバは、第２のコンテンツセグメントのストリームの送信を開始し、送信の最初のＤ秒にわたってレートを直線的に増加させ、その後、送信が符号化ストリームレートになる。
【０１２６】
３．第１のコンテンツセグメントが再生を終了したとき、第２のコンテンツの予備バッファは、Ｒ秒に増加しており、インターリーブ深さは、Ｄ秒に増加している。この時点で、第２のコンテンツの再生を開始することができる。
【０１２７】
したがって、第１のコンテンツセグメントから第２のコンテンツセグメントへの遷移は、受信機での受信レートを符号化ストリームレートに保ち、すなわち、遷移にわたる結合されたレートが、１つのコンテンツセグメントが連続して送信されているのと同じになるように、第１のコンテンツセグメントの送信レートが直線的に減少している間、第２のコンテンツセグメントの送信レートが直線的に増加する。さらに、第２のストリームの予備バッファ保護およびインターリーブ保護は、定常状態での第１のストリームの場合と同じである。図１２は、この例である。
【０１２８】
第１のコンテンツセグメントの送信の終了に比べて、第２のコンテンツセグメントのストリームの送信の開始時について、タイミングがわずかにはずれていたとしても、減少レートおよび増加レートがなだらかな直線であるため、ストリーミングレートの正味の誤りは、軽微である。例えば、２つのストリームの間の遷移のタイミングに５００ミリ秒の誤りがあり、インターリービング深さが１０秒である場合、ストリーミングレートの誤りは、多くて５％である。これは、第２のコンテンツセグメントのパラメータを上述したより少し控えめに、すなわち、これらの値を単に第１のストリームと同じに保持しようとする代わりに、予備バッファおよびインターリーブ時間を少し多く増やそうとするように設定することができ、その結果のコンテンツセグメント遷移間の結合されたストリーミングレートの増加は、軽微になることも意味している。
【０１２９】
コンテンツセグメント遷移の第２の例は、受信機が上述した動的インターリービング方法を使用して第１の送信機によって送信されている第１のコンテンツセグメントを見ており、しかし、第１の送信機が、完全にインターリービング深さＤおよび予備バッファ時間Ｒが増加するのに十分長い間送信していないときである。次いで、第２のコンテンツセグメントへのスムーズな遷移は、動的インターリービング方法を使用して、以下のように達成することができ、この場合、受信機が行うことは、第１のストリームから第２のストリームへの遷移は、２つのコンテンツセグメントが共に連結され、１つのサーバによって送信されるかのように、パラメータを設定し、また第２のストリームを要求することである。当業者であれば、動的インターリービング方法を使用して、このタイプの遷移を達成する方法の詳細を考え出すことができる。
【０１３０】
コンテンツセグメント遷移の第３の例は、上記の動的インターリービング方法を使用して第１の送信機によって送信されている第１のコンテンツセグメントを受信機が見ており、そして、第１のコンテンツセグメントの再生が受信機で終了したときと、第２のコンテンツセグメントの再生が始まるときとの間の期間にギャップがあるときである。例えば、これは、再生を終了する番組の一エピソードの第１のセグメントがあり、次いで例えば期間３０秒の非ストリーミング広告が続き、番組の当該エピソードの第２のコンテンツセグメントの即座の再生が続くときの好ましい挙動であり得る。この場合、動的インターリービング方法は、以下のように使用することができ、簡単にするために、完全にインターリービング深さＤおよび予備バッファ時間Ｒが増加するのに十分長い間、第１のコンテンツセグメントが受信機に送信されていると仮定する。この場合、上記の第１の例の場合のように、受信機は、パラメータＵＩ＝０、ＬＩ＝−Ｄ、ＵＦ＝０、ＬＦ＝−Ｄ、Ｔ＝０で、第１のコンテンツセグメントの再生終了前に、第２のコンテンツセグメントＤ＋Ｒ秒の要求を送信する。これにより、第２のサーバは、第１のサーバから送信されている第１のコンテンツセグメントのレートと結合されたときの総合レートが単一の送信ストリームのレートになるレートで、第２のコンテンツセグメントの送信を開始する。次いで、第１のコンテンツセグメントが受信機での再生をちょうど終了したとき、受信機は、第２のコンテンツセグメントのストリームの送信を停止するよう第２のサーバに信号で伝え、受信機への送信レートがすぐにゼロになる。次いで、約３０秒のギャップが生じる。ギャップの最後に、受信機は、第２のコンテンツセグメントの再生をすぐに開始すると同時に、パラメータＵＩ＝Ｄ＋Ｒ、ＬＩ＝Ｒ、ＵＦ＝Ｄ＋Ｒ、ＬＦ＝Ｒ、Ｔ＝０で、第２のコンテンツについての第２のサーバへの送信開始要求を送信する。これによって、第２のサーバは、ギャップの直前にそれが終えたところから、第２のコンテンツの送信を続ける。全体的な効果は、スケジュールされた時間に第２のコンテンツをすぐに再生すること、そして同時に、２つのコンテンツセグメントの再生中、遷移中のすべての時点における受信機への結合された送信レートは、１つの符号化ストリームレートと同じであり、２つのコンテンツセグメントのいずれも再生されていないとき、送信レートはゼロである。図１３は、この例である。
【０１３１】
当業者であれば認識されるように、上述した動的インターリービング方法の他の多くの使用および変形がある。
【０１３２】
＜サブストリームベースの配信方法＞
サブストリームベースの配信は、ＦＥＣ符号化ストリームをとり、それを複数のサブストリームに分割するための方法であり、ここで各サブストリームには、例えば、ほぼ等しい量の各符号化ブロックが含まれるように分割される。例えば、符号化ストリームは、４０のサブストリームに分割することができ、各サブストリームは、各ソースブロックの約５％から成り、したがって、この例では、ＦＥＣ符号化を使用して各ソースブロックについて生成されたリペアデータの量は、当該ソースブロックのサイズにほぼ等しい。より一般的には、ＦＥＣ符号化が各ソースブロックに適用され、次いで、サブストリームベースの配信が適用されるとき、各サブストリームに含まれる各ソースブロックの符号化の量がほぼ等しくなるように、各ソースブロックについての合計符号化データが複数のサブストリームに分割される。ここで、ＦＥＣ符号化がシステマチックである場合、各ソースブロックの符号化データは、各ソースブロックの元のデータ＋生成されたリペアデータを含むことがあり、ＦＥＣ符号化がシステマチックでない場合、各ソースブロックの符号化データは、リペアデータを含むことがある。
【０１３３】
サブストリームベースの配信の主な概念のうちの１つは、いくつかの所望の目的を達成するために、潜在的に異なるパスに沿って、潜在的に異なるサーバを介して、ストリームの複数のサブストリームを送信することである。一例として、コンテンツストリームをサブストリームベースの配信システムに取り入れる、以下ヘッドエンドサーバ（ＨＥＳ：Hed-End Server）と呼ぶサーバがあり、ＨＥＳが行うプロセスの一部は、コンテンツストリームのソースブロック構造を生成すること、ストリームのＦＥＣ符号化、符号化ストリームを複数のサブストリームに分割すること、次いで、該複数のサブストリームを、異なる複数のデータセンター内または個別の複数のネットワーク位置に分散され得る、以下分散サーバ（ＤＳ：Distributer Server）と呼ぶ他のサーバに送信することである。この一例は、図１４で見ることができる。図１４では、ＤＳ１４３０のそれぞれは、ＨＥＳ１４１０から符号化コンテンツストリーム１４２０の異なるセグメントを受信する。ＤＳが実行するプロセスの一部には、コンテンツストリームのサブストリームが受信機へ向かって通過するときにキャッシュすること、受信機からの特定のコンテンツストリームのサブストリームの要求を受け付けること、サブストリームを、例えば、特定のサブストリームについての受信機の要求に基づいて、または受信機の申し込みに基づいて、受信機に送信することが含まれる。サブストリーミングの特別な場合は、それ以上分割されない元の符号化ストリームを含む。
【０１３４】
サブストリームベースの配信システムにおける受信機は、同じ開始位置で開始する同じコンテンツセグメントについてのサブストリームを要求し、受信することができ、ここで、該要求は、異なるサブストリームごとに異なるＤＳに送信することができ、この場合、同じ開始位置を有する同じ符号化ストリームのいくつかの異なるサブストリームを、異なるＤＳから同じ受信機に送信することができる。この一例は、図１５で見ることができる。図１５において、受信機１５３０は、様々なＤＳ１５１０、１５２０にコンテンツストリームを要求する。この例では、ＤＳ１５２０のうちの１つは、受信機からの要求に応答せず、他のＤＳ１５１０は、受信機にサブストリームを送信する。応答するＤＳがこれを達成するのに十分なデータを受信機に送信する場合、受信機は、ＦＥＣ符号化を使用して、コンテンツストリームを完全に回復することが可能であり得る。
【０１３５】
一例として、元の１Ｍｂｐｓのコンテンツストリームを、ＨＥＳで取り入れることができ、ＨＥＳは、コンテンツストリームが通過するとき、ソースブロック構造を形成し、元のストリームにソースデータがあるのと同じ量のリペアデータを追加し（１００％リペア）、２Ｍｂｐｓの符号化ストリームを１００Ｋｂｐｓの複数のサブストリームに分割し、結果として得られた２０個のサブストリームを２０個の異なるＤＳに送信する。ストリーム内の特定の位置から開始するコンテンツストリームを再生したい受信機は、２０個のＤＳのうちの１２個に要求を送信し、指定された開始位置で開始するコンテンツについてＤＳが有するサブストリームを要求することができる。これに応答して、全１２個のＤＳは、指定された開始点から開始する、符号化ストリームについてそれらが有するサブストリームを受信機に同時に送信し、したがって、１２個のＤＳのそれぞれは、合計レートが１．２Ｍｂｐｓであるように、受信機に、１００Ｋｂｐｓのレートで送信する。
【０１３６】
前に説明したように、サブストリームベースの配信システムには、いくつかの利点があり、そのうちの一部または全部は、以下を含めて、本発明の実施形態で見ることができる。１）人気のあるものと無いものとを結合し、サーバに帯域幅容量およびストレージ容量を提供する自然な負荷バランシングの利点を有する、コンテンツの自然な負荷バランシング、２）パス障害の回復力、すなわち、１つのパスが低下し、コンテンツストリームがＦＥＣ復号を使用して依然として完全に埋め合わせることができるように、受信機が他のパスから受信している十分なデータが依然としてあること、３）ＤＳクラッシュ、ＤＳディスク障害などに対する頑強さ、４）複数のＤＳからデータを送信することは、単一サーバから送信する場合に比べて、総送信レートが受信機に維持され、受信機にバッファの欠乏が発生しない確率をより大きく提供する。これは特に、ＤＳから受信機へのサブストリームの送信に、ＴＣＰまたはＨＴＴＰが使用される場合に該当するが、これは、ＵＤＰが、ＤＳから受信機にサブストリームを送信するために使用される場合でさえも該当し、５）システム全体における単一障害点は、ＨＥＳおよび受信機の入口点にあり、他にある必要はない。
【０１３７】
＜動的インターリービング方法とサブストリームベースの配信方法との結合＞
本明細書に記載した動的インターリービング方法およびサブストリームベースの配信方法は、結合してかなりの利点を得ることができる。すなわち、両方の方法のすべての利点は、結合されたソリューションに見られる。例えば、コンテンツストリームがシステムに取り入れられるとき、動的インターリービング方法を使用して、コンテンツストリームのソースブロック構造およびＦＥＣ符号化を、ＨＥＳによって実行することができる。サブストリーム方法は、ＨＥＳでＦＥＣ符号化ストリームの複数のサブストリームを生成するために使用することができ、これらのサブストリームは、次いで異なるＤＳに送信されて格納することができる。受信機がストリーム内の特定の位置からコンテンツストリームを受信することを望むとき、受信機は、適切な動的インターリービングパラメータを、サブストリームを受信機に送信するすべてのＤＳに送信することができ、当該ＤＳは、これらのパラメータに従って、サブストリームを受信機に送信する。受信機は、ソースブロックのサブストリームからのパケットをひとまとめにして、再生するために、元のコンテンツストリームを再度作成することができる。動的インターリービング方法によって、予備バッファおよびインターリービング深さは、ストリーミング中に増加させることができ、バースト的パケット損失およびネットワークジッタに優れた保護を提供すると共に、受信機に迅速なチャネルザッピング時間を提供する。この例のソリューションにおけるＤＳは、ＦＥＣ符号化を行う必要はなく、それにもかかわらず、ネットワークの異なる部分から分散パスを介してコンテンツストリームを受信機に配信することができ、したがって、配信におけるサーバの多様性およびパスの多様性を増加させ、それによって、サーバおよびネットワーク障害への信頼性および頑強性を増加させる。
【０１３８】
さらに、各ソースブロックの保護量は、複数のＤＳと受信機との間より、この例のＨＥＳと複数のＤＳとの間で、かなり高い可能性がある。例えば、２０個のサブストリームが生成されて、ＨＥＳから２０個のＤＳに送信することができるが、元のコンテンツストリームを回復するのに１０個のサブストリームしか必要ではないし（１００％の保護量）、受信機は、２０個のＤＳのうちの１２個から例えば１２個のサブストリームしか要求しない（１００％の保護量）。１００％の保護量は、すなわち、当該ＤＳのうちの１つが故障して、受信機がサブストリームを受信する残りの１１個のＤＳからすべてのパスを介して総合的に１０％にも及ぶパケット損失があるとしても、依然として元のコンテンツストリームを回復することができる。
【０１３９】
上記で概説したソリューション例には、２０個のＤＳのうちの１２個を超えるＤＳのリストを有する受信機に適切な論理を組み込んでおけば、受信機がサブストリームを受信している１２個のＤＳのうちの１つが故障したとき、受信機は、これを自動的に検出し、受信機が現在サブストリームを受信していない他のＤＳのうちの１つに、別のサブストリームを要求することができ、それによって、１１個のサブストリームのバックアップを受信することから、異なる１２個のＤＳからの１２個のサブストリームを受信することへと、ストリームの信頼性を増すという追加の特性がある。
【０１４０】
動的インターリービング方法およびサブストリーム方法を結合するために必要な方法の変更は、比較的軽微である。例えば、動的インターリービング方法の送信時間を決定するために、符号化ブロック内に複数のデータ点を分配する方法を強化して、各ＤＳが、符号化ブロック内のサブストリームごとに、それが有するデータを、符号化ストリームテープ内の符号化ブロックエリアにわたって一様に分配する方法を決定することができるようにする必要がある（図７参照）。データを一様に分配するという、ＤＳによって行われる決定を、他のＤＳによる決定とは関係ない方法で行い、受信機に送信しているすべてのＤＳの符号化ブロック内のすべてのサブストリームからのデータの総分配が、符号化ストリームテープ内の符号化ブロックエリアにわたってまったく一様になるようにすることができる（図７参照）。
【０１４１】
それらを結合するのに必要な方法の変更の別の例として、各パケットで送信された情報を増大して、受信機がそれにサブストリームを送信するＤＳにストリーム内の特定の位置を指定するとき、すべてのＤＳが、同じコンテンツのサブストリームを受信機に送信する他のすべてのＤＳの解釈と一致する方法で、それらが受信機に送信するサブストリームの特定の位置を解釈することができるようにすることが有利である。当業者であれば認識されるように、これらおよび潜在的にいくつかの他の軽微の変更によって、インターリーブでのストリーミング方法およびサブストリームベースの配信方法を結合して、より大きい利益を得ることができる。
【０１４２】
本発明は、実施形態例を参照して説明してきたが、多数の変更が可能であることを当業者であれば認識され、こうした当業者の認識は、本開示を読むことによってもたらされる。例えば、本明細書に記載したプロセスは、ハードウェア構成要素、ソフトウェア構成要素、および／またはその組合せを使用して実装され得る。したがって、本発明は、実施形態例を参照して記載されているが、本発明は、以下の特許請求の範囲内に含まれるすべての変更および均等物をカバーするものとすることを理解されたい。
【特許請求の範囲】
【請求項１】
少なくとも１つの送信機および少なくとも１つの受信機を含む通信システムにおける、コンテンツストリームを送信する方法であって、
受信機と第１の送信機との間のコネクションを形成することと、
前記第１の送信機から送信された、インターリービングの初期量を含む第１のコンテンツストリームを前記受信機で受信することと、
前記第１のコンテンツストリームのソースブロック構造とは関係なく、前記第１のコンテンツストリームの伝送中に、前記第１のコンテンツストリームに含まれる前記インターリービングの量を調整することと、
を含む方法。
【請求項２】
前記第１のコンテンツストリーム内の前記インターリービングの初期量は、前記第１のコンテンツストリームに初期インターリービングがないように構成される請求項１記載の方法。
【請求項３】
前記第１のコンテンツストリーム内の前記インターリービングの量は、前記初期量から定常状態量に調整される請求項１記載の方法。
【請求項４】
前記第１のコンテンツストリーム内の前記インターリービングは、前記初期量と前記定常状態量との間を直線的に遷移する請求項３記載の方法。
【請求項５】
前記第１のコンテンツストリームに含まれる前記インターリービングの量は、時間の関数として調整される請求項１記載の方法。
【請求項６】
前記第１のコンテンツストリームに含まれる前記インターリービングの量は、前記第１のコンテンツストリームの再生レートと、前記第１のコンテンツストリームの伝送レートとの間の差の関数として調整される請求項１記載の方法。
【請求項７】
前記第１のコンテンツストリームに含まれる前記インターリービングの量は、前記受信機で経験されるデータ損失の量の関数として調整される請求項１記載の方法。
【請求項８】
前記第１のコンテンツストリームの伝送中、前記第１のコンテンツストリームの前記ソースブロック構造は変化しない請求項１記載の方法。
【請求項９】
前記第１のコンテンツストリームからコンテンツの予備バッファを構築すること、
をさらに含む請求項１記載の方法。
【請求項１０】
前記予備バッファは、前記第１のコンテンツストリーム内の前記インターリービングの量に行われる任意の調整と同時に構築される請求項９記載の方法。
【請求項１１】
前記受信機と第２の送信機との間の第２のコネクションを形成することと、
前記受信機に接続された前記第２の送信機から送信された、インターリービングの初期量を含む第２のコンテンツストリームを前記受信機で受信すること、
前記第２のコンテンツストリームの前記ソースブロック構造とは関係なく、前記第２のコンテンツストリームの伝送中に、前記受信機に配信される前記第２のコンテンツストリームに含まれる前記インターリービングの量を調整することと、
前記第１のコンテンツストリームと前記第２のコンテンツストリームとの間を、前記コンテンツストリームの総伝送レートがほぼ同じレベルを維持するように遷移することと、
をさらに含む請求項１記載の方法。
【請求項１２】
前記第１のコンテンツストリームと前記第２のコンテンツストリームとの間の前記遷移は、前記２つのストリームに含まれる前記インターリービングの量の関数として、時間の経過にともない実行される請求項１１記載の方法。
【請求項１３】
チャネルを通じてデータを送信する送信機において、コンテンツストリームを送信する方法であって、
送信機と受信機との間のコネクションを形成することと、
インターリービングの初期量を含むコンテンツストリームを前記受信機に送信することと、
前記コンテンツストリームのソースブロック構造とは関係なく、前記コンテンツストリームの伝送中に、前記コンテンツストリームに含まれる前記インターリービングの量を調整することと、
を含む方法。
【請求項１４】
チャネルを通じてデータを受信する受信機において、コンテンツストリームを受信する方法であって、
受信機と第１の送信機との間のコネクションを形成することと、
前記第１の送信機から送信された第１のコンテンツストリームであって、前記コンテンツストリームのソースブロック構造とは関係なく、前記コンテンツストリームの伝送中に調整することができるインターリービングの初期量を含む前記第１のコンテンツストリームを受信することと、
を含む方法。
【請求項１５】
少なくとも１つの送信機および少なくとも１つの受信機を含む通信システムにおける、コンテンツストリームを送信する方法であって、
受信機と複数の送信機との間のコネクションを形成すること、
前記複数の送信機から送信されたコンテンツストリームを前記受信機で受信すること、ここで、各送信機は、前記受信機に前記コンテンツストリームの異なるサブストリームを送信し、各サブストリームは、インターリービングの初期量を含み、及び
前記コンテンツサブストリームのソースブロック構造とは関係なく、前記コンテンツサブストリームの伝送中に、各コンテンツサブストリームに含まれる前記インターリービングの量を調整すること、
を含む方法。
【請求項１６】
前記コンテンツサブストリームの伝送中、前記コンテンツサブストリームの前記ソースブロック構造は変化しない請求項１５記載の方法。
【請求項１７】
各コンテンツサブストリームに含まれる前記インターリービングの量は、他のコンテンツサブストリームに含まれる前記インターリービングの量とは関係ない請求項１５記載の方法。
【請求項１】
少なくとも１つの送信機および少なくとも１つの受信機を含む通信システムにおける、コンテンツストリームを送信する方法であって、
受信機と第１の送信機との間のコネクションを形成することと、
前記第１の送信機から送信された、インターリービングの初期量を含む第１のコンテンツストリームを前記受信機で受信することと、
前記第１のコンテンツストリームのソースブロック構造とは関係なく、前記第１のコンテンツストリームの伝送中に、前記第１のコンテンツストリームに含まれる前記インターリービングの量を調整することと、
を含む方法。
【請求項２】
前記第１のコンテンツストリーム内の前記インターリービングの初期量は、前記第１のコンテンツストリームに初期インターリービングがないように構成される請求項１記載の方法。
【請求項３】
前記第１のコンテンツストリーム内の前記インターリービングの量は、前記初期量から定常状態量に調整される請求項１記載の方法。
【請求項４】
前記第１のコンテンツストリーム内の前記インターリービングは、前記初期量と前記定常状態量との間を直線的に遷移する請求項３記載の方法。
【請求項５】
前記第１のコンテンツストリームに含まれる前記インターリービングの量は、時間の関数として調整される請求項１記載の方法。
【請求項６】
前記第１のコンテンツストリームに含まれる前記インターリービングの量は、前記第１のコンテンツストリームの再生レートと、前記第１のコンテンツストリームの伝送レートとの間の差の関数として調整される請求項１記載の方法。
【請求項７】
前記第１のコンテンツストリームに含まれる前記インターリービングの量は、前記受信機で経験されるデータ損失の量の関数として調整される請求項１記載の方法。
【請求項８】
前記第１のコンテンツストリームの伝送中、前記第１のコンテンツストリームの前記ソースブロック構造は変化しない請求項１記載の方法。
【請求項９】
前記第１のコンテンツストリームからコンテンツの予備バッファを構築すること、
をさらに含む請求項１記載の方法。
【請求項１０】
前記予備バッファは、前記第１のコンテンツストリーム内の前記インターリービングの量に行われる任意の調整と同時に構築される請求項９記載の方法。
【請求項１１】
前記受信機と第２の送信機との間の第２のコネクションを形成することと、
前記受信機に接続された前記第２の送信機から送信された、インターリービングの初期量を含む第２のコンテンツストリームを前記受信機で受信すること、
前記第２のコンテンツストリームの前記ソースブロック構造とは関係なく、前記第２のコンテンツストリームの伝送中に、前記受信機に配信される前記第２のコンテンツストリームに含まれる前記インターリービングの量を調整することと、
前記第１のコンテンツストリームと前記第２のコンテンツストリームとの間を、前記コンテンツストリームの総伝送レートがほぼ同じレベルを維持するように遷移することと、
をさらに含む請求項１記載の方法。
【請求項１２】
前記第１のコンテンツストリームと前記第２のコンテンツストリームとの間の前記遷移は、前記２つのストリームに含まれる前記インターリービングの量の関数として、時間の経過にともない実行される請求項１１記載の方法。
【請求項１３】
チャネルを通じてデータを送信する送信機において、コンテンツストリームを送信する方法であって、
送信機と受信機との間のコネクションを形成することと、
インターリービングの初期量を含むコンテンツストリームを前記受信機に送信することと、
前記コンテンツストリームのソースブロック構造とは関係なく、前記コンテンツストリームの伝送中に、前記コンテンツストリームに含まれる前記インターリービングの量を調整することと、
を含む方法。
【請求項１４】
チャネルを通じてデータを受信する受信機において、コンテンツストリームを受信する方法であって、
受信機と第１の送信機との間のコネクションを形成することと、
前記第１の送信機から送信された第１のコンテンツストリームであって、前記コンテンツストリームのソースブロック構造とは関係なく、前記コンテンツストリームの伝送中に調整することができるインターリービングの初期量を含む前記第１のコンテンツストリームを受信することと、
を含む方法。
【請求項１５】
少なくとも１つの送信機および少なくとも１つの受信機を含む通信システムにおける、コンテンツストリームを送信する方法であって、
受信機と複数の送信機との間のコネクションを形成すること、
前記複数の送信機から送信されたコンテンツストリームを前記受信機で受信すること、ここで、各送信機は、前記受信機に前記コンテンツストリームの異なるサブストリームを送信し、各サブストリームは、インターリービングの初期量を含み、及び
前記コンテンツサブストリームのソースブロック構造とは関係なく、前記コンテンツサブストリームの伝送中に、各コンテンツサブストリームに含まれる前記インターリービングの量を調整すること、
を含む方法。
【請求項１６】
前記コンテンツサブストリームの伝送中、前記コンテンツサブストリームの前記ソースブロック構造は変化しない請求項１５記載の方法。
【請求項１７】
各コンテンツサブストリームに含まれる前記インターリービングの量は、他のコンテンツサブストリームに含まれる前記インターリービングの量とは関係ない請求項１５記載の方法。
【図１】
【図２】
【図３Ａ】
【図３Ｂ】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３Ａ】
【図３Ｂ】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１３−３１１７３（Ｐ２０１３−３１１７３Ａ）
【公開日】平成２５年２月７日（２０１３．２．７）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−１６２８６５（Ｐ２０１２−１６２８６５）
【出願日】平成２４年７月２３日（２０１２．７．２３）
【分割の表示】特願２０１０−５０４２２４（Ｐ２０１０−５０４２２４）の分割
【原出願日】平成２０年４月１６日（２００８．４．１６）
【出願人】（５０１１１４８４４）デジタル ファウンテン， インコーポレイテッド (25)
【Ｆターム（参考）】
【公開日】平成２５年２月７日（２０１３．２．７）
【国際特許分類】
【出願番号】特願２０１２−１６２８６５（Ｐ２０１２−１６２８６５）
【出願日】平成２４年７月２３日（２０１２．７．２３）
【分割の表示】特願２０１０−５０４２２４（Ｐ２０１０−５０４２２４）の分割
【原出願日】平成２０年４月１６日（２００８．４．１６）
【出願人】（５０１１１４８４４）デジタル ファウンテン， インコーポレイテッド (25)
【Ｆターム（参考）】
[ Back to top ]