(57)【要約】【課題】メディアデータをストリーミングするためのその方法（４００）およびシステム（３１０、３２０）を提供する。【解決手段】本発明にかかる方法は、メディアデータをストリーミングする方法（４００）であって、複数のデータパケットを含むメディアデータにアクセスすること（４１０）と、前記複数のデータパケットにおける各データパケットの特性を定量化する第１の情報にアクセスすること（４２０）と、前記第１の情報を使用すること（４３０）であって、それによって、ネットワークにおける前記データパケットの送信順序を決定する、前記第１の情報を使用すること（４３０）とを含む。【選択図】図３
2007522727.tif 000002
【特許請求の範囲】
【請求項１】
メディアデータをストリーミングする方法（４００）であって、
複数のデータパケットを含むメディアデータにアクセスすること（４１０）と、
前記複数のデータパケットにおける各データパケットの特性を定量化する第１の情報にアクセスすること（４２０）と、
前記第１の情報を使用すること（４３０）であって、それによって、ネットワークにおける前記データパケットの送信順序を決定する、前記第１の情報を使用すること（４３０）と
を含む方法。
【請求項２】
特定のデータパケットが前記ネットワークのノードに到着しなかったと判断すること（４３０）と、
前記第１の情報を使用すること（４３０）であって、それによって、前記特定のデータパケットを再送するかどうかを判断する、前記第１の情報を使用すること（４３０）と
をさらに含む請求項１に記載の方法。
【請求項３】
前記第１の情報を使用すること（４３０）であって、特定のデータパケットを送信するかどうかを判断すること
をさらに含む請求項１に記載の方法。
【請求項４】
前記第１の情報は、
各データパケットのデータの開始及び終了を特定する情報、
各データパケットのヘッダ情報、
各データパケットの長さを特定する情報、
各データパケットの送信時刻を特定する情報、
各データパケットの公称提示時刻を特定する情報、
各データパケットについて、そのデータパケットが送信又は受信されない場合に発生すると予測される歪みの量を定量化する情報、
前記データパケット間の符号化依存関係、各データパケットについて、そのデータパケットにいくつのデータパケットが依存するかを特定する情報、
どのデータパケットがエラー回復力を提供するかを特定する情報、および、
どのデータパケットが冗長性を提供するかを特定する情報
からなる群から選択される請求項１に記載の方法。
【請求項５】
前記第１の情報は、
各データパケットの配信期限を特定する情報
をさらに含む
請求項４に記載の方法。
【請求項６】
ネットワーク性能を特徴付ける第２の情報にアクセスすること（４３０）と、
前記第１の情報と共に前記第２の情報を使用すること（４３０）であって、それによって、前記データパケットの前記送信順序を決定する、前記第２の情報を使用すること（４３０）と
をさらに含む請求項１に記載の方法。
【請求項７】
前記第２の情報は、
前記ネットワークのパスに沿って利用可能な帯域幅、
前記パスに沿ったボトルネックリンクの容量、
データパケット配信速度、
データパケット喪失率、
データパケット受信パターン、
データパケット喪失パターン、
前記データパケットのいずれが前記パスに沿ったノードに受信されたかを特定する情報、
前記データパケットのいずれが前記パスに沿ったノードに到着しなかったかを特定する情報、
前記パスを横断するために必要な時間を定量化する情報、および、
前記パスに関連した遅延を定量化する情報
からなる群から選択される請求項６に記載の方法。
【請求項８】
前記データパケットは、予測符号化されたビデオデータのフレームを構成する
請求項１に記載の方法。
【請求項９】
前記データパケットは、スケーラブル符号化されたビデオデータを構成する
請求項１に記載の方法。
【請求項１０】
前記メディアデータおよび前記第１の情報は、単一のファイルに記憶される
請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施の形態は、メディアデータのストリーミングの分野に関する。
【背景技術】
【０００２】
ストリーミングメディアシステムは、ビデオデータや音響データ等のメディアデータをデータパケットで有線ネットワークおよび／または無線ネットワークにより送信する。
たとえば、利用可能な帯域幅の制約のために、ネットワークにより送信された一部のデータパケットは、途中で遅延を受ける可能性があり、おそらく宛先ノードに遅れて到着する。
また、一部のデータパケットは、途中で喪失する場合もある。
【０００３】
遅れたデータパケットまたは喪失したデータパケットの影響は、予測符号化（圧縮）されたビデオデータでは悪化する場合がある。
予測符号化は、符号化されたデータに依存関係を導入する。
この依存関係により、圧縮量は改善されるが、データパケットが喪失した場合または遅れて到着した場合には、エラー伝搬になる可能性もある。
【０００４】
ビデオフレームは、それらビデオフレームの表示（再生）時刻前に受信されることが好ましい。
予測符号化では、データの或るフレームの復号は、別のフレームの情報に依拠する場合があり、したがって、一部のフレームは、他のフレームの復号に使用できるように、それらフレームの表示時刻よりも早く受信される必要がある。
たとえば、ＭＰＥＧ（ムービングピクチャエキスパートグループ）符号化では、Ｐフレームは、先行するＰフレームまたはＩフレームから予測され、Ｂフレームは、２つのＰフレームまたはＩフレームおよびＰフレームから予測される。
【０００５】
復号器（たとえば、クライアントまたは宛先ノード）に到着しないか、または、送れて到着する符号化されたビデオフレームは、それらビデオフレームの各表示期限に間に合わないだけでなく、多数の他の後続フレームを適切に表示することを妨げる場合もある。
たとえば、ＩフレームまたはＰフレームを構成するデータパケットが喪失した場合、後続のＰフレームまたはＢフレームを復号して表示することができない場合がある。
先行するＩフレームまたはＰフレームが欠けているためにＰフレームを復号できない場合には、そのＰフレームに依存する他の後続フレームを復号することができない。
このように、単一の遅れたフレームまたは欠如したフレームのために、その遅れたフレームまたは欠如したフレームの特定の符号化依存関係に応じて、多数のフレームを適切に復号して表示することが妨げられる場合がある。
これは、全体的な表示品質に影響を与える可能性がある。
【０００６】
ビデオトランスコードは、符号化されたデータを利用可能な帯域幅およびパケット喪失に対応するように適合させることを可能にする１つのソリューションを提供する。
しかしながら、トランスコードは、複雑となる可能性があり、したがって、かなりの計算労力を必要とする場合がある。
【０００７】
スケーラブル符号化技法が開発されている。
このスケーラブル符号化技法では、符号化（圧縮）されたデータに優先順位が付けられ、この優先順位付けによって、圧縮データのどの部分を送信制約内で配信するかを選択するための自然な方法が提供される。
これに加えて、従来のＭＰＥＧ符号化も、データパケットを配信用に優先順位付けする自然な方法に向かっている（たとえば、Ｉフレームは、通常、ＰフレームおよびＢフレームよりも高い優先順位であるとみなされる）。
しかしながら、ＭＰＥＧ符号化は、一般に、所与のフレームタイプのすべてのフレームを同等に扱う。
たとえば、実際には、或るＰフレームが別のＰフレームよりも品質に大きな影響を与える場合にも、すべてのＰフレームは、等しい重要度を有するものとして扱われる）。
近年、データパケットを配信用に優先順位付けするための方法としてレート歪み最適化パケットスケジューリングが提案された。
これらの技法は、それぞれその利点を有するが、依然として比較的複雑なままであり、その結果、多量の計算を必要とする。
【特許文献１】独国特許出願公開第１０１４１５５３号
【特許文献２】国際公開第０２／０９８１０２号
【発明の開示】
【課題を解決するための手段】
【０００８】
［発明の開示］
本発明の実施の形態は、メディアデータをストリーミングするためのその方法およびシステムに関する。
複数のデータパケットを含むメディアデータがアクセスされる。
複数のデータパケットにおける各データパケットの特性を定量化する情報もアクセスされる。
その情報は、ネットワークによるデータパケットの送信順序を決定するのに使用される。
【０００９】
添付図面は、本明細書に援用されて、本明細書の一部を成す。
添付図面は、本発明の実施の形態を示し、その説明と共に本発明の原理を説明する働きをする。
【００１０】
本明細書で参照される図面は、特に言及がある場合を除き一律の縮尺で描かれていると理解されるべきではない。
【発明を実施するための最良の形態】
【００１１】
次に、本発明のさまざまな実施の形態を詳細に参照することにする。
さまざまな実施の形態の例は、添付図面に示されている。
本発明をこれらの実施の形態と共に説明するが、実施の形態は、本発明をこれらの実施の形態に限定することを目的とするものではないことが理解されよう。
逆に、本発明は、代替物、変更物、および均等物を網羅することを目的としている。
これらの代替物、変更物、および均等物は、添付の特許請求の範囲によって画定された本発明の趣旨および範囲内に含めることができる。
さらに、本発明の以下の説明では、本発明の十分な理解を提供するために、多数の具体的な詳細が述べられる。
それ以外の場合には、本発明の態様を不必要に不明確にしないように、既知の方法、手順、コンポーネント、および回路は詳細に説明されていない。
【００１２】
本明細書で提供する説明および例は、マルチメディアデータ（本明細書では、メディアデータまたはメディアコンテンツともいう）との関連で解説される。
マルチメディアデータの一例は、音響データを伴ったビデオデータであり、たとえば、サウンドトラックを有する映画である。
しかしながら、メディアデータは、ビデオのみ、音響のみ、またはビデオおよび音響の双方とすることができる。
【００１３】
一般に、本発明は、そのさまざまな実施の形態において、音声ベースのデータ、音響ベースのデータ、画像ベースのデータ、ウェブページベースのデータ、グラフィックデータ等、およびそれらの組み合わせとの使用によく適している。
また、本発明は、そのさまざまな実施の形態において、符号化（圧縮）若しくはトランスコードできるデータとの使用、または、符号化（圧縮）もトランスコードもできないデータとの使用にもよく適している。
【００１４】
詳細には、本発明の実施の形態は、ビデオデータについて説明され、特に、ＭＰＥＧ−１／２／４符号化およびＨ．２６１／２／３／４符号化で使用される符号化技法等の予測符号化技法を使用して符号化されるビデオデータについて説明される。
このような符号化技法によって導入される予測および時間依存関係のために、予測符号化されたビデオデータは、他のタイプのデータに対して、付加的な課題を導入する。
理解されるように、本発明のさまざまな特徴は、他のタイプのデータ、特に、予測符号化されたビデオデータほど困難ではないメディアデータにも適用することができる。
【００１５】
また、本発明の実施の形態は、歪みとの関連で解説され、詳細には、ビデオオブジェクトの表示で発生する歪みに関して解説される。
しかしながら、本発明は、そのように限定されるものではない。
ビデオデータに関して、メディアストリーミングの目的は、歪みの低減、または、歪みの最小化である。
「歪みの低減」および「歪みの最小化」は、「品質の増加」として等価的に述べることができる。
ビデオデータの場合、品質は、歪み以外の用語で表すことができる。
ビデオデータ以外のタイプのデータの場合、品質は、この技術分野において既知の多くの異なる用語を使用して表すことができる。
【００１６】
メディアデータは、通常、データブロックに分割される。
ビデオデータと同様に、ブロックは、通常、フレームと呼ばれる。
データは、データパケットとしてネットワークを通じてストリーミングされる。
データパケットは、１つまたは複数のフレーム用のデータを含むこともできるし、フレームを構成するデータが、２つ以上のデータパケットを必要とする場合もある。
【００１７】
図１は、本発明の実施の形態をインプリメントできるネットワーク１００を表したものである。
本実施の形態では、ネットワーク１００は、相互接続された複数のサーバノード１２０、１２１、１２２、および１２３に接続されているコンテンツソース１１０を含む。
もちろん、コンテンツソースおよびサーバノードの個数は、図示したものよりも多くてもよいし、少なくてもよい。
【００１８】
コンテンツソース１１０を含むこれらのノード間の相互接続は、有線接続、無線接続、またはそれらの組み合わせとすることができる。
ノード間の複数のストリーミングセッションが並列で生起できるように、各相互接続は１つまたは複数のチャネルを含む。
【００１９】
一般的に言えば、コンテンツソース１１０およびサーバノード１２０〜１２３は、データの処理および記憶、ならびに、このようなデータの送信および受信を行う能力を提供するタイプのデバイスである。
したがって、サーバノード１２０〜１２３は、コンピュータシステムとすることができるだけでなく、通常はコンピュータシステムとはみなされないが同様の能力を有することができる他のタイプのデバイスとすることもできる。
【００２０】
移動クライアントノード１３０や静止クライアントノード１３１等のクライアントデバイスは、ネットワーク１００と通信する。
一実施の形態では、ネットワーク１００は、クライアントノード１３０および／またはクライアントノード１３１へメディアデータをストリーミングするためのものである。
クライアントノードの個数は、図示したものよりも多くてもよいし、少なくてもよい。
クライアントノード１３０およびクライアントノード１３１は、有線接続、無線接続、またはそれらの組み合わせを介してネットワーク１００に接続することができる。
【００２１】
一般に、ネットワーク１００は、コンテンツソース１１０および／または中間のサーバノード１２０〜１２３のいずれかからクライアントノード１３０〜１３１へデータを提供する能力を提供する。
データがコンテンツソース１１０からクライアントノード１３０〜１３１へ進む際にデータが取るルート、すなわちパスは、任意の個数の介在ノードおよびそれらのノード間の相互接続を通過することができる。
一般的に言えば、本発明の実施の形態は、送信機から受信機へのデータパケットのストリーミングに関する。
ネットワーク１００のノードのいずれも、送信機とみなすことができ、同様に、ネットワーク１００のノードのいずれも、受信機とみなすことができる。
送信機ノードおよび受信機ノードは、隣接するノードの場合もあるし、介在するノードによって隔てられている場合もある。
【００２２】
図２Ａは、本発明の一実施の形態による、データパケットの送信順序を確立するのに使用できるキューを生成する符号化器２１０を示すブロック図である。
本実施の形態によれば、メディアオブジェクト（たとえば、ビデオシーケンス）が符号化（圧縮）される時、関連する一組の情報も作成される。
この関連する一組の情報は、本明細書では、「スケジューリングキュー（scheduling cue）」と呼ぶ。
このように、本実施の形態では、符号化器２１０の出力は、データパケットとして具体化される符号化されたビットストリーム、および、定量化可能な方法で各データパケットを特徴付ける一組のスケジューリングキューである。
スケジューリングキューは、パケット送信をスケジューリングするのに使用される。
これについては、以下でさらに詳細に説明することにする。
【００２３】
一実施の形態では、１つまたは複数のスケジューリングキューが、各データパケットに関連付けられる。
或いは、スケジューリングキューは、ビデオデータの各フレームに関連付けることもできる。
また、図２Ａの例は、データが符号化される際に、スケジューリングキューが生成されることも示している。
或いは、スケジューリングキューは、図２Ｂに示すように、事前に符号化されたデータまたは符号化されないデータについて生成することもできる。
【００２４】
図２Ｂでは、符号化器２１０は、メディアデータを符号化し、次いで、符号化されたデータは、キュー発生器２１５に送信される。
キュー発生器２１５は、事前に符号化されたデータのスケジューリングキューを生成する。
符号化器２１０は、符号化されたデータをキュー発生器２１５へ送信する前にメディアデータをすべて符号化することができる。
或いは、符号化されたデータは、データが符号化されるにつれて、キュー発生器２１５へストリーミングすることもできる。
これに加えて、符号化器２１０とキュー発生器２１５との間にストレージデバイスまたはバッファを置くこともできる。
後者の場合、符号化されたデータは、符号化後または符号化中にストレージデバイスへ送信することができる。
キュー発生器２１５は、その後、データが必要な際に、符号化されたデータをストレージデバイスから取り出すことができる。
【００２５】
一実施の形態では、スケジューリングキューは、メディアデータ（符号化されているか、または、そうでない）と同じファイルに記憶され、したがって、スケジューリングキューを「トラック」と呼ぶことができる。
しかしながら、メディアデータおよびスケジューリングキューは、別々に（別々のファイルとして、または、別々のストレージデバイスにも）記憶することもできる。
一般に、１つまたは複数のスケジューリングキューは、特定のデータパケットまたはフレームに一意に関連付けられ、スケジューリングキューを適切なデータパケット／フレームに関連付けるか、または、その逆に関連付けるのに、さまざまなメカニズムを使用することができる。
【００２６】
スケジューリングキューは、さまざまな情報を含むことができる。
さまざまな情報には、以下のものがあるが、これらに限定されるものではない。
−各パケットの公称提示（たとえば、表示）時間。
−各パケットの相対的な重要度。
ビデオデータパケットの場合、これは、そのパケットが喪失するか、遅れて到着するか、または送信されなかったときに、結果としてディスプレイに生成される歪みの点から測定することができる。
−予測符号化されたメディアデータ（たとえば、ビデオデータ）の符号化依存関係。
たとえば、どのパケットが他のパケットに依存しているか、どのパケットがＩフレーム、Ｐフレーム、またはＢフレームに対応するか、若しくは、スケーラブル符号化の場合、どのパケットが基本レイヤを形成し、どのパケットが各上位レイヤ（enhancement layer）用であるか、いくつのパケットがいずれかの所与のパケットに依存するか。
−どのパケットがエラー回復力（たとえば、圧縮ビデオのＩスライス）または冗長性（たとえば、喪失を克服することを助けるために送信できる前方エラー訂正パケット）を提供するか。
−ビットストリームにおける各データパケットのデータの開始および終了を特定する情報、各データパケットのリアルタイムプロトコル（ＲＴＰ）ヘッダ情報、パケットがメディアユニットを復号するのに必要な最後のデータユニットであるかどうか等のパケット情報。
−各パケットの（バイトによる）長さ；ならびに／または
−送信の開始（最初のデータパケットが送信された時）を基準とした各パケットの公称送信時刻。
たとえば、最初のパケットは時刻ゼロ（０）で送信され、次のパケットは時刻０＋Ｔで送信され、次のパケットは時刻０＋２Ｔで送信される、以下同様。
公称送信時刻は、一定または均一とすることができる。
しかしながら、一般に、単位時間当たりに送信されるデータパケットの個数は、各単位時間の圧縮ビットレートに応じて変化する。
【００２７】
符号化されたビデオデータを伴うアプリケーションでは、今説明したスケジューリングキューを使用して、或るＰフレームが別のＰフレームよりも重要であると判断することができる。
この判断は、たとえば、第１のＰフレームに対応するデータパケットが送信されなかった場合に結果として生じる歪みの量、対、第２のＰフレームのデータパケットが送信されなかった場合に結果として生じる歪みの量を考慮することにより、または、第１のＰフレームに依存する他のフレームの個数、対、第２のＰフレームに依存する他のフレームの個数を考慮することにより、行うことができる。
【００２８】
このように、スケジューリングキューは、たとえば、或る理由により、データパケットがその宛先に到着しない場合にどのデータパケットを再送すべきか、または、他のデータパケットを再送することが必要となった場合にどのデータパケットをスキップする（たとえば、送信しない）ことができるか、若しくは、遅延させることができるかについての、理由に基づいて決定を行うための基礎を提供する。
より重要なことは、スケジュールキューを使用すると、関連した情報の多くを（データがストリーミングされる時の）ストリーミング時間内に計算する必要がもはやないので、ストリーミングサーバは、多量の計算労力を必要とすることなくこのような決定を行うことができるということである。
【００２９】
図３は、本発明の一実施の形態による、ネットワークノード間のストリーミングオペレーションを示すブロック図である。
図３の例は、図１のネットワーク１００等のネットワークにより通信する第１のノード（ノードＡ３１０）および第２のノード（ノードＢ３１５）を示している。
上述したように、ノードＡ３１０とノードＢ３１５との間に他のノードが存在してもよい。
【００３０】
一般に、図３のノードＡ３１０は、ノードＢ３１５へメディアデータを送信するデバイスである。
ノードＢ３１５は、ネットワーク性能に関するフィードバックをノードＡ３１０にオプションとして提供することができる。
たとえば、ノードＢ３１５は、利用可能な帯域幅、平均データパケット喪失率、および／または、どのデータパケットが正しく受信されたかをノードＡ３１０に通知することができる。
また、フィードバックは、データパケット配信速度、ノードＢ３１５へのパスを横断するのに必要な時間、ノードＢ３１５へのパスに関連した遅延、データパケット喪失パターン（またはデータパケット受信パターン）等の情報も含むことができるが、これらに限定されるものではない。
ノードＡ３１０は、他のソースから、たとえば、ネットワーク管理デバイスまたはネットワーク監視デバイスからフィードバックを受信することもできる。
また、代替的に、ノードＡ３１０は、たとえばこれまでのストリーミングセッションに基づくネットワーク性能に関するアプオリな情報、または、ネットワーク性能に関する仮定を有することもできる。
【００３１】
図３の例では、ノードＡ３１０はストリーミングサーバであり、ノードＢ３１５はクライアントデバイスである。
図２Ａおよび図２Ｂも参照して、符号化器２１０の出力（たとえば、符号化されたメディアデータを構成するデータパケットおよびスケジューリングキュー）は、ストレージ３２０等の記憶素子に記憶することができる。
この場合、サーバ３１０はストレージ３２０にアクセスすることができる。
ストレージ３２０は、サーバ３１０とは別個の素子とすることもできるし、サーバ３１０内に統合することもできる。
後者の場合、符号化器２１０の出力は、サーバ３１０に提供され、サーバ３１０は、データパケットをクライアント３１５へストリーミングする前に、符号化器２１０の出力を全部または一部記憶することができる。
或いは、サーバ３１０は、符号化器２１０を統合することができる（たとえば、サーバ３１０および符号化器２１０は、単一のデバイス内に統合される）。
【００３２】
一般に、符号化オペレーションおよびストリーミングオペレーションは、重なり合うこともできるし、任意の時間を隔てて順次行うこともできる。
符号化オペレーションおよびストリーミングオペレーションは、単一のデバイスが行うこともできるし、複数のデバイスが行うこともできる。
符号化オペレーションの出力は、符号化デバイス、ストリーミングデバイス、またはそれらのデバイスとは別個のストレージ素子が全部または一部を記憶することができる。
【００３３】
図３の例では、クライアント３１５が、特定のメディアオブジェクト（たとえば、ビデオオブジェクト）をサーバ３１０に要求する。
サーバ３１０は、対応する圧縮ビットストリームをスケジューリングキューと共にストレージ３２０から読み出す。
サーバ３１０は、以下でさらに説明するように（図５および図６の解説を参照）、スケジューリングキューを使用して、圧縮ビットストリームを構成するデータパケットを送信するための「ベスト」スケジュールを決定する。
上記で提示したネットワーク性能情報は、送信スケジュールを決定する時にも使用することができる。
サーバ３１０は、次に、送信スケジュールに従ってデータパケットをクライアント３１５へ送信することができる。
理解されるように、このスケジュールは、必要に応じた頻度、または、要求に応じた頻度で改定することができる。
たとえば、ビデオデータの場合、より頻繁に更新を行うことによって、クライアント３１５の表示品質を改善することができる。
しかしながら、より頻繁に更新を行うことによって、サーバ３１０に与えられた計算負荷は増加する。
【００３４】
本発明による実施の形態は、さまざまな異なる動作シナリオによく適している。
送信スケジュールを決定する状況において、サーバ３１０は、次の送信機会にどのパケットを送信するか、次の複数の送信機会にどのパケットを送信するか、どのパケットを廃棄するかまたは送信しないか、および、どのパケットを再送するかを決定することができる。
また、サーバ３１０は、データパケット間に前方エラー訂正（ＦＥＣ）情報を割り当てるかどうか、割り当てる場合には、予測される品質を最大にするためにデータパケットにわたってＦＥＣ保護をどのように割り当てるか、および、データパケット間にＦＥＣ情報をどのように分散させるかを決定することもできる（たとえば、ＦＥＣ情報は、パケット間に分散させることもできるし、一定のデータパケットをＦＥＣ情報を運ぶように専用化することもできる）。
【００３５】
また、サーバ３１０は、現在の圧縮ビットストリームから、現在のネットワーク性能（たとえば、利用可能な帯域幅または必要なエラー回復力）によりよく適した別の圧縮ビットストリームに切り換えるかどうかも決定することができる。
たとえば、クライアントデバイスの多様性およびそれらクライアントデバイスの能力の相違（たとえば、異なるメモリサイズ、異なるスクリーンサイズ、異なるプロセッサ速度等）のために、メディアオブジェクトを異なる方法（たとえば、異なるビットレート、異なる解像度等）で符号化することができる。
所与のクライアントについて、要求されたメディアオブジェクトの圧縮ビットストリームをそのクライアントの属性に従って選択することができる。
一方、サーバ３１０は、ネットワーク性能の特性に基づいて、要求されたメディアオブジェクトの別の圧縮ビットストリームへ切り換えるかどうかを決定することができる。
【００３６】
上述したように、サーバ３１０は、クライアントまたは他のネットワークデバイスからフィードバックを受信する場合もあるし、受信しない場合もある。
フィードバックは、パケットごとの肯定応答メッセージ（ＡＣＫ）または否定応答メッセージ（ＮＡＣＫ）の形を取ることもできるし、おそらく、特定の時間ウィンドウについて指定される、統計的な性質（たとえば、最後の１０秒にわたる５％のパケット喪失率）の形とすることもできる。
帯域幅は、送信されたパケット数の点から測定することもできるし、送信されたバイト数の点から測定することもできる。
サーバ３１０は、フィードバックが利用可能でない場合に、ネットワーク性能の仮定された知識またはアプリオリな知識に基づいて動作することもできる。
【００３７】
図４は、本発明の一実施の形態による、メディアデータをストリーミングするための方法のフローチャート４００である。
図５は、本発明の一実施の形態による、データパケットの送信をスケジューリングするための方法のフローチャート５００である。
フローチャート４００および５００には、具体的なステップが開示されているが、このようなステップは例示である。
すなわち、本発明の実施の形態は、さまざまな他のステップまたはフローチャート４００および５００に列挙されたステップの変形を実行することにもよく適している。
フローチャート４００および５００のステップは、提示したものとは異なる順序で実行できること、および、フローチャート４００および５００のステップの必ずしもすべてを実行しなくてもよいことが理解されよう。
フローチャート４００および５００によって記述される方法のすべてまたは一部は、コンピュータ可読で且つコンピュータ実行可能な命令を使用してインプリメントすることができる。
こられの命令は、たとえば、コンピュータシステムのコンピュータ使用可能媒体に存在する。
一般に、フローチャート４００および５００は、図３のサーバ３１０によってインプリメントされる。
或いは、これらのフローチャートは、図３のノードＢ３１５がインプリメントすることもできるし、中間ネットワーク監視ノード、エッジサーバ、またはプロキシがインプリメントすることもでき、選択された送信スケジュールは、ストリーミングのためにサーバ３１０へ送信される。
【００３８】
まず図４を参照して、ステップ４１０において、複数のデータパケットとして具体化されたメディアデータがアクセスされる。
【００３９】
ステップ４２０において、複数のデータパケットにおける各データパケットの或る特性を定量化するスケジューリングキュー（「第１の情報」）もアクセスされる。
このスケジューリングキューには、各データパケットのデータの開始および終了を特定する情報、各データパケットのヘッダ情報、各データパケットの長さを特定する情報、各データパケットの送信時刻を特定する情報、各データパケットの公称提示時刻を特定する情報、各データパケットについて、そのデータパケットが送信または受信されない場合に発生すると予測される歪みの量を定量化する情報、データパケット間の符号化依存関係、各データパケットについて、そのデータパケットにいくつのデータパケットが依存するかを特定する情報、どのデータパケットがエラー回復力を提供するかを特定する情報、どのデータパケットが冗長性を提供するかを特定する情報、および、各データパケットの配信期限を特定する情報が含まれるが、これらに限定されるものではない。
【００４０】
ステップ４３０において、スケジューリングキューを使用して、ネットワークでのデータパケットの送信順序が決定される。
一実施の形態では、ネットワーク性能特性（「第２の情報」）も使用して、データパケットの送信順序が決定される。
ネットワーク性能特性には、ネットワークのパスに沿って利用可能な帯域幅、そのパスに沿ったボトルネックリンクの容量、データパケット配信速度、データパケット喪失率（喪失ヒストグラムも）、データパケット受信パターン、データパケット喪失パターン（喪失ヒストグラムも）、データパケットのいずれがパスに沿ったノードに受信されたかを特定する情報、データパケットのいずれがパスに沿ったノードに到着しなかったかを特定する情報、パスを横断するのに必要な時間を定量化する情報、および、パスに関連した遅延を定量化する情報が含まれるが、これらに限定されるものではない。
別の実施の形態では、配信期限が、各パケットについて特定され、この情報も、データパケットの送信順序を決定するのに使用される。
【００４１】
スケジューリングキューは、特定のデータパケットを送信するかどうかを決定するのに使用することができる。
また、スケジューリングキューは、特定のデータパケットを再送するかどうかを決定するのに使用することもできる（たとえば、重要なデータパケットがその宛先に到着しなかった）。
【００４２】
図５のフローチャート５００は、本発明の一実施の形態による、データパケットの送信スケジュールを決定するための方法のより詳細な図を提供し、図６も参照して解説される。
【００４３】
図５のステップ５１０において、スケジューリングされるデータパケットのリスト６１８、ならびに、配信プロセスの現在の状態および制約を記述する情報６１０を使用して、実現可能な送信スケジュール６１５が生成される。
現在の状態および制約の情報６１０は、上述したようなネットワーク性能特性（たとえば、帯域幅、パケット喪失率、遅延等）を含むことができる。
また、現在の状態および制約の情報６１０は、スケジューリング中のデータパケットのそれぞれに関連した配信期限等の情報も含むことができる。
【００４４】
データパケットのリスト６１８は、まだ送信されていないあらゆるデータパケット、送信されたが、送信中に喪失したことが判明したあらゆるデータパケット、および送信されたが、そのステータスが不明であるあらゆるデータパケットを含むことができる。
スケジューリングされるデータパケットのリスト６１８は、メディアオブジェクトに関連したすべてのデータパケットを含むこともできるし、それらすべてのデータパケットのサブセットのみを含むこともできる。
後者の場合には、データパケットの各サブセットの配信を順にスケジューリングすることができる。
いずれの場合も、送信スケジュールは、その後に改定することができる。
一般に、主な対象になるデータパケットは、近時に喪失したデータパケット、近時に送信されたが、そのステータスが不明である（たとえば、それらデータパケットが正しく配信されたかどうかが不明である）データパケット、および、まだ配信されていないが、（たとえば、その配信期限に対して測定された）比較的近い将来に配信する必要があるデータパケットである。
【００４５】
ステップ５２０において、スケジューリングキュー６２４がアクセスされる。
一実施の形態では、スケジューリングキュー６２４は、各データパケットについて、そのデータパケットが送信または受信されなかった場合に結果として生じる影響を定量化する。
ビデオデータパケットの場合、そのデータパケットが送信または受信されなかった場合に発生すると予測される歪みの量をスケジューリングキュー６２４は指定することができる。
【００４６】
各データパケットに関連した歪みは、測定歪みとすることもできるし、見積もり歪み（estimated distortion）とすることもできる。
一実施の形態では、特定のデータパケットの喪失に関連した測定歪みは、基本的に、ビットストリームからそのデータパケットを廃棄して、残りのデータパケットを復号した時に結果として生成される歪みを計算することにより計算される。
この測定は、メディアが（たとえば、図２Ａおよび図２Ｂの符号化器２１０によって）符号化される際に行うことができる。
事前に符号化されたデータの場合、データパケットを符号化（圧縮）されたビットストリームから廃棄することができ、パケットの残りの部分を復号することができ、その結果生じた歪みを計算することができる。
一実施の形態では、見積もり歪みは、結果として生成され得る歪みを示す情報を、符号化されたビットストリームから抽出することによって得られる。
たとえば、大きな動きベクトルを有するビデオデータの場合、データパケットの喪失によって、小さな動きベクトルまたは０の値の動きベクトルを有するビデオデータよりもはるかに大きな歪みがもたらされる可能性がある。
測定歪みは、見積もり歪みよりも正確である。
一方、測定歪みは、計算がより複雑である。
【００４７】
ビットストリームにおけるデータパケットの各シーケンスについて（たとえば、データパケットの各リスト６１８について）、そのシーケンスのデータパケットに関する情報（たとえば、スケジューリングキュー６２４）を含むテーブルを生成することができる。
各シーケンスについて、このようなテーブルが２つ以上存在する場合がある。
たとえば、１つのデータパケットの喪失に起因する歪みは、テーブルの１つに含めることができる。
Ｎ個のデータパケットの場合、テーブルのサイズはＮ×１となる。
このテーブルでは、テーブルのエントリーｊは、パケットｊが喪失した場合に結果として生じる歪みを記述する。
【００４８】
もう１つのテーブルは、あらゆる２つのデータパケットの喪失の結果生じる歪みを含むことができる。
Ｎ個のパケットの場合、テーブルのサイズはＮ×Ｎとなる。
このテーブルでは、エントリー（ｊ，ｋ）は、パケットｊおよびｋが共に喪失した場合に結果として生じる歪みを記述する（パケットｊおよびｋは、シーケンスにおいて連続したパケットである必要はない）。
３つ以上のパケットの喪失についても同様にしてテーブルを導出することができる。
一般に、Ｎ個のパケットの場合、これらのテーブルのサイズはＮＭとなる。
ここで、Ｍは、喪失したと仮定されるデータパケットの個数である。
【００４９】
しかしながら、同様の性能を達成しつつ、より小さく、且つ、より複雑度の少ないテーブルを使用することができる。
２つの喪失したパケットが、ビットストリームにおいて互いに十分離れている場合、それらパケットは、歪みに対して独立した影響を有する。
したがって、テーブルは、歪みに対して独立した影響を有する、喪失したパケットの組み合わせの情報を含む必要はない。
たとえば、Ｎ個のすべてのビデオフレームがＩフレームとして符号化される場合、それらビデオフレームは、歪みを独立にもたらすものとして取り扱うことができ、一般に、サイズＮ×１のテーブルで十分である。
また、Ｂフレームの喪失は、他のフレームを悩ますことはなく、したがって、Ｂフレームの場合、サイズＮ×１のテーブルで十分である。
【００５０】
また、ビデオデータが、周期的なＩフレーム（たとえば、１５個ごとのフレームがＩフレームである）で符号化される場合、各グループオブピクチャ（ＧＯＰ）を別々に取り扱うことができる。
たとえば、Ｎフレームの長さを有するビデオを考え、解説を簡単にするために、各フレームは単一のデータパケットに符号化されるものと仮定する。
たとえば、１５個のフレーム（データパケット）のＧＯＰの場合、ビデオは、Ｎ／１５のＧＯＰから構成される。
各ＧＯＰは、歪み情報の自身のテーブルを有することができる。
２つのデータパケットが喪失したと仮定する場合、各ＧＯＰテーブルは、サイズ１５×１５を有する。
したがって、Ｎ／１５個のテーブルが存在し、各テーブルはサイズ１５×１５を有し、全サイズはＮ×１５である。
各ＧＯＰの独立性を利用しないと、２つのパケットが喪失したと仮定される場合には、サイズＮ×Ｎのテーブルが必要とされる。
【００５１】
ビデオが、各フレームの部分イントラ符号化（partial intra-coding）で符号化される場合、周期的なＩフレームとは対照的に、時間的に間隔が十分離れた喪失も、独立した喪失として近似することができる。
【００５２】
また、ビデオが、次のＧＯＰとは独立の１５個のフレームのＧＯＰを含む例を考える。
このＧＯＰは、次の順序、すなわちＩ１、Ｂ２、Ｂ３、Ｂ４、Ｐ５、Ｂ６、Ｂ７、Ｂ８、Ｐ９、Ｂ１０、Ｂ１１、Ｂ１２、Ｐ１３、Ｂ１４、Ｂ１５のフレームを有する場合がある。
この例では、１５個のすべてのフレームは、最初のＩフレーム（Ｉ１）に依存し、１４個のフレームはＰ５に依存し、１０個のフレームはフレームＰ９に依存し、６個のフレームはフレームＰ１３に依存し、１つのフレームのみが各Ｂフレームに依存する。
このＧＯＰの例の歪みテーブルは、すべてのフレームについて１５×１のテーブルを含むこともできるし、すべてのフレームについて１５×１のフレームならびにＩフレームおよびＰフレームについてより大きな寸法のテーブル（たとえば、２つのパケット、３つのパケット等の喪失を仮定したテーブル）を含むこともできるし、ＩフレームおよびＰフレームについてより大きな寸法のテーブルと共に、１１個のＢフレームについて１１×１のテーブルを含むこともできる。
【００５３】
あらゆるパケットではなくデータパケットのサブセットについてのみテーブルに情報を含めることにより、テーブルのサイズを削減することもできる。
たとえば、テーブルは、サブサンプリングされた情報（たとえば、１０個ごとのパケットの情報）のみを含むこともできるし、比較的重要なパケット（たとえば、ＩフレームまたはＰフレームに関係したパケット）についてのみ情報を含むこともできる。
或いは、テーブルは、各パケット（たとえば、喪失した場合に最大の歪みを生じるパケット、または、利用できる顕著なレート歪みトレードオフを有するパケット）の相対的な重要度に基づいて慎重に選択された情報のみを含むこともできる。
【００５４】
上記解説は、よく知られているＩフレーム符号化モード、Ｐフレーム符号化モード、およびＢフレーム符号化モードを有するＭＰＥＧビデオ符号化に焦点を当てているが、本発明の実施の形態は、スケーラブル符号化等の他の符号化の形態にも適用される。
スケーラブル符号化では、この場合も、圧縮データは、異なる優先度、符号化依存関係、および関連した歪みを有するデータの異なるサブセットから成る。
【００５５】
図５および図６の参照を続けると、ステップ５３０において、符号化されたビットストリームをスケジューリングキュー（複数可）６２４と共に使用し、また、配信パスに沿ったネットワーク性能を特徴付ける情報６２６を使用して、送信スケジュールのそれぞれは、モデル６２５を使用して、選択された定量化可能なパラメータに対する送信スケジュールのそれぞれの影響を予測することで評価される。
一実施の形態では、モデル６２５は、各スケジュールについて歪み６２０を予測する。
たとえば、複数のデータパケットからの１つのデータパケットの喪失を仮定した歪みを求めることができる。
或いは、異なる個数および組み合わせのデータパケットの喪失を仮定した歪みを求めることもできる。
一実施の形態では、実現可能なスケジュールのそれぞれの予測歪みを記憶することができる（６３０）。
【００５６】
予測歪み６２０は、その予測歪みに対応する単一の数字（single number）とすることもできるし、或る分布の予測歪みまたはその中間的なもの（たとえば、或る標準偏差に対応する許容帯域を有する予測歪み等）とすることもできることに留意されたい。
或いは、歪みについての或る形態の累積分布関数を求めることもできる。
【００５７】
ステップ５４０において、全影響（たとえば、歪み）を最小（またはほぼ最小）にする送信スケジュール（ベストスケジュール６４０）が選択される。
或いは、指定されたしきい値を満たすスケジュールを選択することもできる。
たとえば、許容可能な歪みレベルを指定することができ、そのレベルを超えないスケジュールを選択することができる。
【００５８】
次に、選択されたスケジュールに従って、データパケットまたはその或る部分を送信することができる。
データパケットが既存のスケジュールの下で送信中であっても、上記ステップを繰り返して、より新しいスケジュールまたは更新されたスケジュールを決定することができる。
たとえば、新しいスケジュールは、各データパケットについて決定することもできるし、Ｎ個のパケットのあらゆるグループについて決定することもできるし、あらゆるグループオブピクチャについて決定することもできるし、Ｎ秒ごとに決定することもできる。
また、新しいスケジュールは、或る種のトリガイベントに応答して決定することもできる。
たとえば、クライアントデバイス（または他の任意の下流側ノード）からのフィードバックが、特定のデータパケットが到着しなかったことを示す場合がある。
このようなフィードバックが受信された場合、新しいスケジュールを決定することができる（新しいスケジュールは、データパケットの再送を含むことができる）。
また、更新されたネットワーク性能特性を受信することもでき、このような情報の受信の結果として、ネットワーク性能のあらゆる変化を考慮した新しいスケジュールを決定することができる。
たとえば、特定のデータパケットが、或る理由から、その配信期限までに受信されるように十分早く送信されなかった場合にも、新しいスケジュールを決定することができる（この場合、新しいスケジュールは、そのデータパケットが送信された場合に遅れて到着するので、そのデータパケットを送信しないように選択することができる）。
別の例として、更新されたネットワーク性能特性が、利用可能な帯域幅が減少したことを示す場合、帯域幅の制約を受ける予測歪みを最小にすることを試みる新しいスケジュールを作成することができる（この新しいスケジュールは、帯域幅の制約を満たすように、より少ない個数のパケットを送信することを含む場合がある。
ここで、その特定のパケット選択は、予測歪みを最小にするように選択される）。
【００５９】
上記解説は、１から５までの番号が付けられた５つのデータパケットが送信される単純化した例として示されている。
パケット１の喪失に関連した歪みはＤ１であり、パケット２について歪みはＤ２であり、以下同様である。
歪みＤ１〜Ｄ５は、パケット１〜５にそれぞれに関連したスケジューリングキュー６２４に含められる。
歪みを予測するための単純化したモデル６２５は、各データパケットの喪失の結果生じる歪みを合計することを伴うことができる。
このように、受信したデータパケットまたは喪失したデータパケットのあらゆるパターンの結果生じる歪みを見積もるために、喪失したパケットのそれぞれの歪みが合計される。
たとえば、データパケット３および５が喪失した場合、予測歪みはＤ３＋Ｄ５となる。
ベストスケジュールは、（ネットワーク性能特性に基づき）パケット喪失の予測パターンについて最小の予測歪みを生じるスケジュールである。
【００６０】
図７は、本発明の一実施の形態による、データパケットの送信をスケジューリングするためのプロセスの別の例を示している。
データパケットは、実現可能な送信スケジュールに列挙される。
実現可能な送信スケジュールは、先行する繰り返しで決定されたベストスケジュールとすることができる。
【００６１】
データパケット、各データパケットの関連した配信期限、スケジューリングキュー、および、データパケットの受信、喪失、または遅延配信に関して受信されたあらゆる情報のリストを使用して、まだ送信されずに残っているパケット、および、すでに送信されたが、おそらく正しく受信されていないあらゆるパケットについて、送信スケジュールを決定することができる。
【００６２】
図７の例では、パケット１〜６は、事前に送信されており、次はパケット７の処理である。
（たとえば、クライアントからの）フィードバック情報は、パケット１、２、３、および５が正しく受信され、パケット４が受信されなかったことを示す。
パケット６は、送信されたが、受信されたかどうかについての情報は利用可能でない。
この情報に基づいて、また、スケジューリングキューにも基づいて、ストリーミングサーバ（たとえば、図３のサーバ３１０）は、たとえば、次の送信機会にパケット４を再送するのか、それとも、パケット７を送信するのかを決定することができる。
より重要なことは、ストリーミングサーバが、かなりの量の計算労力を必要とする複雑なアルゴリズムを使用することなく、この決定を行えることである。
たとえば、パケット４およびパケット７のいずれかを選択するために、ストリーミングサーバは、スケジューリングキューによって提供された、量子化された歪み情報に基づき、歪みに対して最大の影響を有するパケットを単に選択するだけでよい。
このように、複雑な最適化技法を実施することなく、パケットスケジューリングにおける大幅な性能利得を達成することができる。
【００６３】
図８は、本発明の一実施の形態による、孤立フレーム（isolated frame）ｋの喪失に起因する、平均２乗誤差（ＭＳＥ）による歪みを示すグラフである。
Ｌ個のフレームを有するビデオシーケンスの場合、Ｌ個の可能な孤立した喪失が存在し、その結果、記憶コストはＬの数の線形となる。
図８は、フレームｋを喪失することによって引き起こされる歪みＤ（ｋ）を示している。
【００６４】
Ｄ（１）〜Ｄ（Ｌ）のみを与えられた任意の喪失パターンにより引き起こされる歪みをモデル化するのに、０次の歪みチェーンモデルＤＣ０を使用することができる。
ここで、０次は、メモリが前提とされず、喪失した各パケットの結果生じる歪みが、前のどの喪失したパケットからも独立していることを表す。
このモデルは、喪失の間隔が離れている場合（たとえば、喪失率が低い場合）には正確である。
Ｎ個のフレームＫ＝（ｋ１，ｋ２，…，ｋＮ）が喪失した場合、全予測歪みは、以下によって簡単に与えられる。
【００６５】
【数１】
2007522727.tif 000003
【００６６】
前述したように、送信帯域幅の制約を受けるビデオストリームのパケットのベスト送信スケジュールが探求される。
この問題は、次のように定式化することができる。
Ｗを、送信が考慮されるパケットのウィンドウとし、Ｒ＊を、ビットまたはパケット数のいずれかで測定される帯域幅の制約とする。
帯域幅の制約を満たすために送信すべきでない、パケットＫ∈Ｗのサブセットについての決定が探求される。
Ｒ（Ｗ＼Ｋ）を、送信されるＷからのパケットに関連したレートとする。
ここで、「＼」は、「差分設定（set difference）」演算子を示す。
したがって、サブセットＫは、帯域幅の制約を満たしつつ、Ｋを廃棄することによる全歪みが最小化されるように、以下によって与えられる。
【００６７】
【数２】
2007522727.tif 000004
【００６８】
次に、まず、送信帯域幅Ｒ＊がパケット数として表される場合の方程式（２）の解法を考える。
Ｒ＊＝ｋ、すなわち、ｋ個のパケットがＷから廃棄されるものと仮定する。
次に、各パケットの歪みを昇順でソートして、最初のｋ個のパケット（Ｋ個の最小の関連した歪みを有するパケット）を選択することにより、Ｋ＊が見つけられる。
これに加えて、問題が、廃棄する最良のｋ＋１個のパケットを決定することに変化した場合、この解は、先行する解に直接基づいたものとなる。
具体的には、廃棄するｋ個のパケットの最良のサブセットの選択は、廃棄するｋ＋１個のパケットの最良のサブセットに含まれる。
これとは対照的に、この性質を提供しない手法は、あらゆるｋについて完全に新しい検索を行わなければならない。
最適なスケジュールは、したがって、非常に少ない計算で得ることができる。
【００６９】
次に、Ｒ＊がビットで測定される代替的な場合を考える。
正確な最適解を得るのに必要な整数計画法は計算が困難である。
使用できる実用的な近似は、ビットごとに最小の歪みを個々に引き起こすパケットを廃棄することである。
具体的には、パケットｊ∈Ｗが、λｊ＝Ｄ（ｊ）／Ｒ（ｊ）のビットごとの歪みの点から有用度（utility）に関連付けられる。
Ｋ＊は、Ｗのパケットをλの降順でソートし、次いで、最も高い有用度（ビットごとの歪み）のパケットから開始してできるだけ多くのパケットを送信することにより得られる。
この方法では、この場合も、組み込み検索ストラテジーが、関連する低い複雑度の利益で達成される。
【００７０】
図９は、本発明の一実施の形態による、２つのフレームｋ１およびｋ２の喪失に起因する、ＭＳＥによる歪みを示すグラフである。
Ｄ（ｋ１，ｋ２）があらゆる可能な対｛ｋ１，ｋ２｝について記憶された場合、全記憶コストはＬの２次式となる。
しかしながら、廃棄されたパケット間を結び付ける歪みは、それらのパケット間の距離が増加するにつれて減少するので、１つの実用的な簡単化は、｜ｋ１−ｋ２｜＞Ｍの場合にＤ（ｋ１，ｋ２）＝Ｄ（ｋ１）＋Ｄ（ｋ２）と仮定することである。
ここで、Ｍは圧縮に依存する。
たとえば、１５個のフレームのＧＯＰの場合、Ｍは、多くとも、そのＧＯＰのパケット数である。
この近似によって、歪み情報の必要な記憶および計算は、Ｌ２からＬ×Ｍに削減される。
【００７１】
任意の喪失パターンの歪みは、多くの手法を使用して見積もることができる。
たとえば、喪失したパケットの歪みが、最後に喪失したパケットに依存する場合（１のメモリ（memory of one））、歪みは、１次歪みチェーンＤＣ１を使用して見積もることができる。
具体的には、ｋ１＜ｋ２＜…＜ｋＮについて、次のようになる。
【００７２】
【数３】
2007522727.tif 000005
【００７３】
上記歪みの見積もりを使用してパケットスケジュールを検索することは、喪失したパケット間の相互依存関係により計算の費用が高くなる可能性がある。
この複雑度は、多くの手法を通じて削減することができる。
たとえば、反復降下アルゴリズム（iterative descent algorithm）を使用することができる。
このアルゴリズムでは、収束するまで、目的関数
【００７４】
【数４】
2007522727.tif 000006
【００７５】
が１回に１変数について最小化される一方、それ以外の変数は一定に維持される。
詳細には、まず、Ｒ＊がパケット数で表される場合を考え、Ｒ＊＝ｍであるものと仮定する。
この場合、ｎ＝１，２，…の繰り返しｎにおいて、廃棄パターンＫ＝（ｋ１，…，ｋｍ）の個々のエントリーが、ｊ＝１，…，ｍについて、
【００７６】
【数５】
2007522727.tif 000007
【００７７】
を使用して計算される。
ここで、集合
【００７８】
【数６】
2007522727.tif 000008
【００７９】
である。
換言すれば、Ｋの妥当な初期解から開始して、各繰り返しにおいて、選択されたパケットＫのサブセットは、削減された歪みを生成するサブセットを見つけるために乱される。
各繰り返しにおいて、より少ない歪みまたは等しい歪みを有するサブセットが見つけられ、したがって、このアルゴリズムは、必ずしも大域的最適解に収束するとは限らないが、収束することが保証される。
Ｒ＊がビットで測定される場合は、上記と同様の勾配降下アルゴリズムを使用して解法することができる。
【００８０】
上記解説は、任意の一組のパケットの喪失に起因する全歪みを予測するための多くの方法を特定した。
この多くの方法は、異なるパケット喪失パターンの歪みを明示的に含むテーブルから、異なるパケット喪失パターンの歪みを予測するための潜在的により小さなテーブルおよび関連したアルゴリズムまで及んでいる。
これに加えて、歪みを予測するための他の手法も、図６のモジュール６２５に組み込むことができる。
【００８１】
要約すると、本発明は、そのさまざまな実施の形態において、スケジューリングキューの使用に基づきメディアをストリーミングするための方法およびシステムを提供する。
スケジューリングキューは、ストリーミングサーバがデータパケットを優先順位付けするのに使用することができる。
ストリーミングサーバは、スケジューリングキューを使用し、ネットワーク性能や配信期限等の情報も考慮して、受信機における品質を最大にすることができる（たとえば、歪みを削減することができる）パケット送信スケジュールを決定することができる。
本発明による実施の形態により、複雑度も計算労力も大幅に増加させることなく、はるかに複雑な技法で実現された性能利得に匹敵する性能利得が得られる。
【００８２】
本発明の実施の形態は上述のように説明される。
本発明を特定の実施の形態で説明したが、本発明は、このような実施の形態によって限定されるものと解釈されるべきではなく、添付の特許請求の範囲に従って解釈されるべきであることが理解されるはずである。
【図面の簡単な説明】
【００８３】
【図１】本発明の実施の形態をインプリメントできるネットワークを表した図である。
【図２Ａ】本発明の一実施の形態による、データパケットを順序付けるためのキューの生成を示すブロック図である。
【図２Ｂ】本発明の別の実施の形態による、データパケットを順序付けるためのキューの生成を示すブロック図である。
【図３】本発明の一実施の形態による、ネットワークノード間のストリーミングオペレーションを示すブロック図である。
【図４】本発明の一実施の形態による、メディアデータをストリーミングするための方法のフローチャートである。
【図５】本発明の一実施の形態による、データパケットの送信をスケジューリングするための方法のフローチャートである。
【図６】本発明の一実施の形態による、データパケットの送信をスケジューリングするためのプロセスのフロー図である。
【図７】本発明の一実施の形態による、データパケットの送信をスケジューリングするためのプロセスの一例を示す図である。
【図８】本発明の一実施の形態による、孤立フレームの喪失に起因する歪みを示すグラフである。
【図９】本発明の一実施の形態による、２つのフレームの喪失に起因する歪みを示すグラフである。
【符号の説明】
【００８４】
１１０・・・コンテンツソース，
１２０，１２１，１２２，１２３・・・サーバノード，
１３０・・・移動クライアントノード，
１３１・・・静止クライアントノード，
２１０・・・符号化器，
２１５・・・キュー発生器，
３１０・・・ノードＡ（ストリーミングサーバ），
３１５・・・ノードＢ（クライアント），
３２０・・・ストレージ，
【図１】
2007522727.tif 000009
【図２Ａ】
2007522727.tif 000010
【図２Ｂ】
2007522727.tif 000011
【図３】
2007522727.tif 000012
【図４】
2007522727.tif 000013
【図５】
2007522727.tif 000014
【図６】
2007522727.tif 000015
【図７】
2007522727.tif 000016
【図８】
2007522727.tif 000017
【図９】
2007522727.tif 000018
【国際調査報告】
2007522727.tif 000019
2007522727.tif 000020