JP4857379B2 - ストリーミングデータのサービス品質を強化するための予測的フレームドロッピング - Google Patents

Description

［優先権主張］
本出願は、２００６年６月２２日に出願された米国特許出願第１１／４２５，８７１号の優先権を主張し、その開示内容全体をここに参照により組み入れる。

本発明の実施の形態は、ストリーミングデータのサービス品質（ＱｏＳ）に関し、特に帯域幅制限を守りながらデータストリームの品質を最大化するための予測的フレームドロッピングに関する。

ストリーミングデータアプリケーションは帯域幅制限に適応するための様々な手段を用いる。しかしながら、リアルタイムストリーミングビデオのようなアプリケーションにとっては、システムにリアルタイム性のある制約が課せられるため、取り得る選択肢は少ない。リアルタイムストリーミングビデオアプリケーションに対しては、ビデオストリームに利用可能な帯域幅を制限するサービス品質（ＱｏＳ）ソフトウエアモジュールを実装してもよい。しばしばこの帯域幅は、ＱｏＳモジュールによって管理されるシステムの他の部分と共有されなければならない。

ビデオストリームが異なる帯域幅の限度容量をもついくつかの受信者向けにいったんエンコードされた場合に起こることであるが、ＱｏＳモジュールはそのストリームの他の属性（たとえば品質やビットレート）を変化させることができない。その場合、このタイプの帯域幅制限をすると、制限に達したときにビデオストリームの送信レートが低下する可能性が高くなる。しかしながら、ビデオデータは時間に敏感であるから、受信側に遅れて到着するビデオフレームはドロップされる。
こういった事情のもと、本発明の実施の形態が考えられた。

本発明のある態様は、ネットワーク上の第１ノードと第２ノードの間で送信されるストリーミングデータの品質を最適化する方法である。ストリーミングデータは１以上のフレームグループを含み、各フレームグループには、イントラフレーム（Ｉフレーム）を含む複数のフレームが含まれる。当該方法は、フレームグループから１以上のフレームを含む送信キューを第１ノードから第２ノードに順次送信するステップと、新しいＩフレームが送信のためにキューされるとき、現在送信中のＩフレームを除き、送信キューのまだ送信されていない任意のフレームを送信キューからドロップするステップとを含む。

ピクチャグループ（ＧｏＰ）の送信を説明するタイミング概略図である。 トラフィックシェーピングを用いたピクチャグループの送信を説明するタイミング概略図である。 本発明の実施の形態に係る、ネットワーク上で送信されるストリーミングデータの品質を最適化する方法を説明するフローダイアグラムである。 本発明の実施の形態に係る、ストリーミングデータのフレームの送信を説明するタイミング概略図である。 本発明の実施の形態に係る、ストリーミングデータのフレームの送信を説明するタイミング概略図である。 本発明の実施の形態に係る、ネットワーク上で送信されるストリーミングデータの品質を最適化する方法を説明するフローダイアグラムである。 本発明の実施の形態に係る、ネットワーク上で送信されるストリーミングデータの品質の最適化を説明するタイミング概略図である。 本発明の実施の形態に係る、ネットワーク上で送信されるストリーミングデータの品質の最適化を説明するタイミング概略図である。 本発明の実施の形態に係る、ネットワーク上で送信されるストリーミングデータの品質の最適化を説明するタイミング概略図である。 本発明の実施の形態に係る、ネットワーク上で送信されるストリーミングデータの品質の最適化を説明するタイミング概略図である。 本発明の実施の形態に係る、ネットワーク上で送信されるストリーミングデータの品質の最適化を説明するタイミング概略図である。 本発明の実施の形態に係る、ネットワーク上で送信されるストリーミングデータの品質の最適化を説明するタイミング概略図である。 本発明の実施の形態に係る、ネットワーク上で送信されるストリーミングデータの品質の最適化を説明するタイミング概略図である。 本発明の実施の形態に係る、ネットワーク上で送信されるストリーミングデータの品質を最適化する装置のブロック図である。 本発明の実施の形態に係る、ネットワーク上で送信されるストリーミングデータの品質を最適化する装置を利用するネットワークの概略図である。

これから述べる詳細な説明には、例示のために特定の詳細な内容が多く含まれるが、当業者であれば、これらの詳細な内容にいろいろなバリエーションや変更を加えても、本発明の範囲を超えないことは理解できよう。したがって、以下で説明する本発明の例示的な実施の形態は、権利請求された発明に対して、一般性を失わせることなく、また、何ら限定をすることもなく、述べられたものである。

本発明の実施の形態は、ビデオデータ、オーディオデータ、ゲームデータ、ファイル転送データを含むがこれらに限定しない任意の形式のストリーミングデータに適用することができる。例示の目的のために、ストリーミングデータがストリーミングビデオデータの形式である状況を前提に以下では議論する。

ＭＰＥＧ２、ＭＰＥＧ４およびＨ．２６４のような現代のビデオコーダ／デコーダ（コーデック）は一般にビデオフレームを３つの基本タイプに分割する。この３つの基本タイプは、イントラ（Ｉｎｔｒａ）フレーム、予測（Ｐｒｅｄｉｃｔｉｖｅ）フレームおよび双予測（Ｂｉｐｒｅｄｉｃｔｉｖｅ）フレームとして知られており、これらは、通常それぞれＩフレーム、ＰフレームおよびＢフレームと呼ばれる。

Ｉフレームは、それ自身を除いていずれのピクチャも参照することなく符号化されたピクチャである。Ｉフレームはランダムアクセスのために使用され、また、他のＰフレームまたはＢフレームを復号する際の参照として使用される。Ｉフレームは、（デコーダが任意のピクチャ位置においてゼロから復号を開始できるようにするための）ランダムアクセスポイントを生成するために、エンコーダによって生成される。Ｉフレームは、画像の詳細を差分化しても有効なＰまたはＢフレームを生成することができない場合に生成されてもよい。Ｉフレームは完全なピクチャであるから、Ｉフレームは、典型的にはＰフレームやＢフレームよりも符号化のためにより多くのビット数が必要である。

Ｐフレームをデコードするためには、いくつかの他のピクチャを先にデコードしておくことが必要である。Ｐフレームは典型的にはＩフレームよりもエンコードに必要なビット数は少ない。Ｐフレームは、復号順序において以前のＩフレームと比較した差分に関する符号化された情報を含む。Ｐフレームは典型的にはピクチャグループ（ＧｏＰ）において先行するＩフレームを参照する。Ｐフレームは、画像データと動きベクトル変位の両方、およびこれらの組み合わせを含む。ある標準のコーデック（たとえばＭＰＥＧ−２）では、Ｐフレームは、以前に復号された、ただ一つのピクチャを復号過程で参照として用い、そのピクチャが表示順で当該Ｐフレームに先行することを要求する。Ｈ．２６４では、Ｐフレームは復号過程の参照として、以前復号された複数のピクチャを用いることができ、その予測のために使われたピクチャに対して表示順で任意の順序関係をもつことができる。

Ｂフレームをデコードするためには、ＩフレームまたはＰフレームを先にデコードすることが必要である。Ｐフレームと同様、Ｂフレームは画像データと動きベクトル変位の両方、およびこれらの組み合わせを含む。Ｂフレームは、二つの異なる以前に復号された参照領域を用いて取得された予測値を平均することによって、動き領域（たとえば、マクロブロックまたはより小さな領域のようなフレームのセグメント）の予測を形成するいくつかの予測モードを含む。あるコーデック（たとえばＭＰＥＧ−２）では、Ｂフレームは他のピクチャの予測の際の参照として用いられることはない。その結果、より低い品質の符号化（結果的に、そうでなければ使われるであろうビット数よりも少ないビットを使用することになる）をＢピクチャに対して使うことができる。なぜなら詳細を失うことがあっても次のピクチャの予測品質に害を与えないからである。Ｈ．２６４のような他のコーデックでは、Ｂフレームを他のピクチャのデコードの際の参照として使ってもよく、使わなくてもよい（エンコーダの裁量である）。あるコーデック（たとえばＭＰＥＧ−２）は、正確に二つの以前に復号されたピクチャをデコード過程で参照として用い、これらのピクチャの一つは表示順で当該Ｂフレームの前であり、他方のピクチャは当該Ｂフレームの後であることが必要である。Ｈ．２６４のような他のコーデックでは、Ｂフレームは、１、２、または２よりも大きい以前に復号されたピクチャをデコード過程で参照として用いることができ、その予測で使われるピクチャに対して表示順で任意の順序関係をもつことができる。Ｂフレームは典型的には、ＩフレームまたはＰフレームに比べて、符号化に必要なビット数はより少ない。

ここでは、Ｉフレーム、Ｂフレーム、Ｐフレームという用語は、たとえば、ストリーミングビデオのコンテキストを参照して上述したような、Ｉフレーム、Ｂフレーム、Ｐフレームに似た特性をもつ任意のストリーミングデータユニットに適用することができる。

ストリーミングデータの関連するフレームの集合をここでは一般に「フレームグループ」と呼ぶ。フレームグループの一つの例として、ストリーミングビデオのコンテキストにおいてピクチャグループ（ＧｏＰ）として知られるものがある。ＧｏＰはＩフレームで始まり、次のＩフレームまで続くフレームタイプの繰り返しパターンとして定義される。ＧｏＰが大きいということは、単位時間あたりに求められるＩフレームが少ないことを意味し、その場合に得られるビデオストリームは帯域幅をあまり要求しない。一例を図１Ａに示すが、ＧｏＰは、下の表１に記述されるような１５フレームの配置をもつ。

このＧｏＰにおいて、各Ｐフレームはフレーム番号０のＩフレームを参照する。Ｂフレームはすぐ隣のＩおよび／またはＰフレームを参照する。たとえば、フレーム１４、１５のＢフレームは、フレーム１３のＰフレームと、次のＧｏＰのフレーム０のＩフレームを参照する。図１Ａからわかるように、Ｉフレーム、ＰフレームおよびＢフレームは、サイズが異なり、送信の際、異なる量のネットワーク帯域を要求する。

フレームを送信するネットワークの帯域幅が制限されるため、単位時間当たりに送信可能なフレーム数が制限される。１ノードが多数のノードにコンテンツをストリーミングしているトポロジーでは、ノード単位の帯域幅の変化に適応するようにＧｏＰのサイズおよび／またはフレームレートを変更することは難しい。そのような変化に関与してデコードおよび再エンコードをすると、送信ノードにおいて大きな処理能力が必要となるか、またはトランスコードをする潜在的に大きなサーバのインフラストラクチャが必要になる。このようなわけで、帯域幅制限に適応するために、送信側でＱｏＳモジュールがフレームをドロップすることがときには有益である。送信側が帯域幅制限のために送信レートを落とさなければならないために遅れを取っているならば、フレームをドロップして補償することをしないとしたら、単にさらにもっと大きな遅れを取ることになるだけである。残念ながら帯域幅制限を補償するためにフレームをドロップすると、受信側でビデオの品質に悪影響を及ぼすことがある。受信側において、参照フレーム（たとえば、ＩフレームまたはＰフレーム）が、非常に遅いために、ドロップされると、それを参照するすべてのフレームが役に立たなくなる。Ｐフレームがランダムにドロップされるなら、そのＰフレームを参照する送信されたＢフレームは受信側にとって役に立たない。

図１Ｂに示すように、より小さいフレーム、たとえばＢフレームを並列に送信することがときには可能である。図１Ｂに示す例では、Ｂフレーム１および２は並列に送信される。同様に、より大きなフレーム、たとえばＩフレームやＰフレームは、ネットワークの帯域幅が許容するレートではあるが、より長い時間をかけて送信してもよい。このような技術をここでは「トラフィックシェーピング」と呼ぶ。こういった技術は有益であるけれども、十分なネットワーク帯域が利用可能でない場合、その効果は限定的である。

本発明の実施の形態は、ストリーミングデータ送信の送信側においてフレームを予測的にドロップすることを実装する。本発明の実施の形態によれば、ネットワーク上で第１ノードと第２ノードの間で送信されるストリーミングデータの品質が最適化される。ストリーミングデータは１以上のフレームグループを含む。各フレームグループにはイントラフレーム（Ｉフレーム）を含む１以上のフレームが含まれる。あるフレームグループからの１以上のフレームを含む送信キューは、第１ノードから第２ノードに順次送信される。新しいＩフレームが送信のためにキューされると、送信キューにあるまだ送信されていない任意のフレームは送信キューからドロップされる。ただし、現在送信中のＩフレームは除く。

本発明の実施の形態に係る方法２００は、図２Ａのフローダイアグラムに示すように実装される。具体的には、ブロック２０２において、受信されたフレームグループから送信キューが生成される。送信キューからのフレームの送信がブロック２０４で示すように開始される。ブロック２０６において、次のフレームグループが受信される。これは、受信されたフレームグループからのフレームが依然として送信中であるときに起こることもある。ブロック２０７において、キューにある先行するフレームグループからのすべてのフレームが送信されたかどうかを判定する。もしそうであれば、この方法はブロック２０２に戻り、次のフレームグループに対する送信キューを生成する。もしそうでないなら、ブロック２０８においてまだ送信されていない任意のフレームが現在の送信キューからドロップされる（ただし現在送信中のＩフレームがあれば、それは除く）。そして、この方法はブロック２０２に戻り、次のフレームグループに対する送信キューを生成する。

ある状況では、帯域幅が限られているため、Ｉフレームしか送信することができない。もしＩフレームが送信のためにキューされるなら、他のキューされたフレームはすべてドロップしてよい（ただし現在送信中のＩフレームがあれば、それは除く）。それによって、データストリームは遅れを取ることなく、受信側ではデコード可能なフレームを受信する。たとえば、図２Ｂのタイミングダイアグラムに示すように、第１のＩフレームＩ_Ａを送信している間に、第２のＩフレームＩ_Ｂが時刻ｔ_１で送信のためにキューされたとする。第１のＩフレームＩ_Ａの送信が完了した後、第２のＩフレームＩ_Ｂが送信される。ある状況では、Ｉフレームの送信が妨げられるほどネットワーク帯域が減少することもある。たとえば、図２Ｃで示すように、第１のＩフレームＩ_Ａの送信が完了する前で第２のＩフレームＩ_Ｂが時刻ｔ_１でキューされた後、第３のＩフレームＩ_Ｃが時刻ｔ_２で送信のためにキューされることもありうる。そのような場合、第３のＩフレームＩ_Ｃがより最近のものであるから、第２のＩフレームＩ_Ｂは送信キューからドロップされる。

本発明の実施の形態において、図２Ａのブロック２０２の送信キューの生成ステップには、あるフレームグループに対して送信キューからドロップされたフレームの数および／またはタイプを用いて、次のフレームグループに対する送信キューから何枚のフレーム、あるいは、いずれのフレームをドロップすべきかを予測して決定することが含まれる。図３のフローダイアグラムは、図２Ａのブロック２０２の一部として実装することができる予測的フレームドロッピングを実装した方法３００の例を示す。フレームグループには、一つのＩフレームおよびＰ個のＰフレームが含まれる。新しいＩフレームがキューイングされることによって、以前のフレームグループ（たとえばビデオデータストリームからのピクチャグループ（ＧｏＰ））に対する送信キューからドロップされたＰフレームの数Ｐは、ブロック３０２で示されるように決定される。このカウントはブロック３０４で示すように、格納された「ドロップカウンタ」ＤＣに加算される。そして、ＤＣの値に等しい数のＰフレームには、次のフレームグループに対する転送キューからドロップするためにマークが付けられる。ドロップするためにマークが付けられたＰフレームを参照するＢフレームはいずれも同様にドロップするためにマークが付けられる。ドロップするためにマークされたフレームは、送信キューから破棄され、送信されることがない。次のフレームグループからのＩフレームと（Ｐ−ＤＣ）個のＰフレームを含む送信キューが、ブロック３０６で示されるように送信される。次のＩフレームをキューイングすることで上述のように送信が中断されることがある。したがって、ブロック３０８において、すべてのＰフレームが送られたかどうかを判定する。そうでない場合、ドロップカウンタＤＣがブロック３１０でインクリメントされる。一例として、ドロップカウンタは任意の量、たとえば１だけ、最大値Ｐになるまでデクリメントされる。すべてのＰフレームが送信されたなら、次に、送信キューにあるすべてのフレーム（たとえば任意のＢフレームを含む）が送信されたかどうかをブロック３１２で判定する。もしそうであれば、ドロップカウンタＤＣはブロック３１４で任意の量、たとえば１だけ、最小値０になるまでデクリメントされる。そうでないなら、ドロップカウントはブロック３１６において同じ値に留まる。この処理は各フレームグループに対して繰り返される。このようにしてドロップカウンタ値ＤＣは、ネットワークトラフィックの状態変化による帯域幅の変化に対して自動的に調整される。

図４Ａから図４Ｆのタイムダイアグラムは、図３を参照して上述した方法の動作例を説明する。これらの例において、各フレームグループにおけるフレームは、フレームタイプを示す文字Ｉ、ＰまたはＢ、フレームが属するフレームグループを特定する下付文字、およびフレームグループ内のフレームの位置を特定する上付文字によって識別される。具体的には、図４Ａは、ＩフレームＩ_Ａ ^０と、ＰフレームＰ_Ａ ^３，Ｐ_Ａ ^６，Ｐ_Ａ ^９，およびＰ_Ａ ^１２と、ＢフレームＢ_Ａ ^１，Ｂ_Ａ ^２，Ｂ_Ａ ^４，Ｂ_Ａ ^５，Ｂ_Ａ ^７，Ｂ_Ａ ^８，Ｂ_Ａ ^１０，Ｂ_Ａ ^１１，Ｂ_Ａ ^１３およびＢ_Ａ ^１４とを含むフレームグループに対する送信キュー４０２を示す。この例では、ドロップカウンタＤＣは最初ゼロである。この例において、図４Ｂに示すように、ＱｏＳのバンド幅の制限のために、ＩフレームＩ_Ａ ^０と、ＰフレームＰ_Ａ ^３と、ＢフレームＢ_Ａ ^１，Ｂ_Ａ ^３およびＢ_Ａ ^４とが、次のフレームグループが始まるＩフレームＩ_Ｂ ^０がキューされる前に送信される。このため、ＰフレームＰ_Ａ ^６，Ｐ_Ａ ^９，およびＰ_Ａ ^１２と、ＢフレームＢ_Ａ ^５，Ｂ_Ａ ^７，Ｂ_Ａ ^８，Ｂ_Ａ ^１０，Ｂ_Ａ ^１１，Ｂ_Ａ ^１３およびＢ_Ａ ^１４とがドロップされる。３つのＰフレームがドロップされたため、ドロップカウンタＤＣはゼロから３にインクリメントされる。新しいフレームグループが開始したため、３つのＰフレームとそれに依存するＢフレームをドロップするためにマークしてもよい。ドロップされるＰフレームをフレームグループにわたって実質的に均等に分散させることがしばしば望ましい。一例として、ドロップされるＰフレームを実質的に均等に分散させた結果の送信キュー４０４を図４Ｃに示す。この例では、Ｉフレームにもっとも近いＰフレームが優先的にドロップされる。この場合、ＩフレームＩ_Ｂ ^０とＰフレームＰ_Ｂ ^６だけが送信キュー４０４において送信される。この例では、次のＩフレームＩ_Ｃが送信のためにキューされる前に送信キュー４０４を送信することに成功する。結果として、ドロップカウンタＤＣは値２にデクリメントされる。

ＤＣ＝２であるから、二つのＰフレームだけが次のフレームグループに対する送信キュー４０６からドロップされる。ここでも、ドロップされるフレームはフレームグループにわたって均等に分散することが望ましい。たとえば、図４Ｄに示すように、送信キュー４０６はＩフレームＩ_Ｃ ^０と、ＰフレームＰ_Ｃ ^３，Ｐ_Ｃ ^９と、ＩフレームＩ_Ｃ ^０およびＰフレームＰ_Ｃ ^３を参照するＢフレームＢ_Ｃ ^１，Ｂ_Ｃ ^２とを含む。この例では、次のフレームグループに対するＩフレームＩ_Ｄ ^０が送信のためにキューされる前に送信キュー４０６全体を送信することに成功する。その結果、ドロップカウンタＤＣは値１にデクリメントされる。

ＤＣ＝１であるから、次のフレームグループに対する送信キュー４０８から一つのＰフレームだけがドロップされる。ここでもドロップされるフレームはフレームグループにわたって均等に分散させることが望ましい。たとえば、図４Ｅに示すように、送信キュー４０８は、ＩフレームＩ_Ｄ ^０と、ＰフレームＰ_Ｄ ^３，Ｐ_Ｄ ^６，Ｐ_Ｄ ^１２と、ＢフレームＢ_Ｄ ^１，Ｂ_Ｄ ^２（これらはＩフレームＩ_Ｄ ^０とＰフレームＰ_Ｄ ^３を参照する），Ｂ_Ｄ ^４，Ｂ_Ｄ ^５（これらはＰフレームＰ_Ｄ ^３およびＰ_Ｄ ^６を参照する）およびＢ_Ｄ ^１３，Ｂ_Ｄ ^１４（これらはＰフレームＰ_Ｄ ^１２および次のフレームグループに対するＩフレームＩ_Ｅ ^０を参照する）とを含む。この例では、ＢフレームＢ_Ｄ ^１３，Ｂ_Ｄ ^１４を送信する前に、次のフレームグループに対するＩフレームＩ_Ｅ ^０がキューされる。送信キュー４０８においてすべてのＰフレームが送信されたが、Ｂフレームはすべてが送信されたわけではないため、ドロップカウンタＤＣは変化しない。

ＤＣ＝１であるから、次のフレームグループに対する送信キュー４１０から一つのＰフレームだけがドロップされる。ここでもドロップされるフレームはフレームグループにわたって均等に分散させることが望ましい。たとえば、図４Ｆに示すように、送信キュー４１０は、ＩフレームＩ_Ｅ ^０と、ＰフレームＰ_Ｅ ^３，Ｐ_Ｅ ^６，Ｐ_Ｅ ^１２と、ＢフレームＢ_Ｅ ^１，Ｂ_Ｅ ^２（これらはＩフレームＩ_Ｅ ^０およびＰフレームＰ_Ｅ ^３を参照する）およびＢ_Ｅ ^４，Ｂ_Ｅ ^５（これらはＰフレームＰ_Ｅ ^３およびＰ_Ｅ ^６を参照する）とを含む。ＰフレームＰ_Ｄ ^１２を参照するＢフレームは送信キュー４１０からドロップされる。なぜなら、対応するＢフレームが以前の送信キュー４０８において送信されていなかったからである。この例では、ＰフレームＰ_Ｅ ^１２が送信される前に、次のフレームグループに対するＩフレームＩ_Ｆ ^０がキューされる。送信キュー４１０において一つのＰフレームが送信されなかったため、ドロップカウンタＤＣの値は、たとえば、ＤＣ＝２にインクリメントされる。

予測してドロップするべきフレームを選択するために様々な戦略を採用することができる。予測してドロップするフレームの選択を調整することによって、帯域幅の使用が最大化され、ストリーミングデータの品質も最適化される。送信されたフレームの最大数まで回復させることによって、ローカルな一時的な乱れに対処し、帯域幅の利用もまた、許容される最大値付近に保たれる。上述した予測的フレームドロッピングについて数多くのバリエーションが考えられることに留意すべきである。たとえば、ドロップされるフレームをフレームグループにわたって分散させる替わりに、フレームグループの最初または最後から始まるシーケンスにあるフレームをドロップしてもよい。さらに、他の予測的帯域幅調整技術を、予測的フレームドロッピングとともに、あるいはそれに替えて用いてもよい。たとえば、図４Ｇに示すように、トラフィックシェーピングをフレームドロッピングとともに用いてもよい。具体的には、帯域幅制限４１２が許すなら、以前のフレームグループに対する送信キューになされた調整にもとづいて、ＢフレームＢ^１，Ｂ^２，Ｂ^３およびＢ^５を並列に送信し、他方、ＩフレームＩとＰフレームＰ^３およびＰ^６とはパラレルに送信しないようにしてもよい。他のフレームは上述のように予測してドロップしてもよい。

本発明の実施の形態は、図５に示すような、ネットワーク上で転送されるストリーミングデータの品質を最適化するための装置５００の形で実装される。装置５００は、受信器モジュール５０２、ＱｏＳモジュール５０４、および送信器５０を一般に含む。受信器モジュールは上流ノードから一つ以上のフレームグループ５０１を受信するためのロジックを含む。ＱｏＳモジュール５０４はフレームグループ５０１から送信キュー５０３を生成するためのロジック５０８を含む。送信器５０６は下流ノード５１０に送信キュー５０３を送信するように構成される。

ＱｏＳモジュール５０４のロジック５０８は、たとえば図２Ａ〜２Ｃ、図３、図４Ａ〜４Ｇを参照して上述した予測的フレームドロッピング法を実装する。ロジックは適切な方法、たとえば、ハードウエア、ソフトウエア、ファームウエアあるいはこれらの２以上の組み合わせによって、実装される。特に、ＱｏＳモジュール５０４のロジック５０８は、新しいＩフレームが第１ノードから第２ノードに送信するためにキューされるとき、まだ送信されていないフレームを送信キュー５０３からドロップする、および／または、上述のように次の送信キューからフレームを予測的にドロップするように構成される。ロジック５０８はまた、送信キュー５０３を下流ノードに送信するのに利用可能な帯域幅の量を決定するように構成される。

図５で示したタイプの装置は、図６に示すようなネットワーク上でストリーミングデータを送信するのに役立つ。具体的には、ストリーミングデータ信号６０１はデータ生成モジュール６０２によって生成される。データ生成モジュール６０２は、ストリーミングデータが生成される信号源である。そのようなモジュールの具体例には、デジタルカメラ、デジタル音源、ソフトウエアメディアプレイヤおよびデコーダ、デジタルメディアストレージデバイスなどが含まれる。ある実施の形態では、コーデックにしたがって動作するコーデックモジュール６０４を用いて、信号６０１をストリーミングデータ６０３に変換する。一例として、ストリーミングデータ信号６０１がビデオ信号であるなら、コーデックは、ＭＰＥＧレイヤ２、ＭＰＥＧレイヤ４のシンプルプロファイル、Ｈ．２６３またはＨ．２６４のようなビデオ圧縮標準である。コーデックモジュール６０４は、クライアント−サーバまたはピア・ツウ・ピア（Ｐ２Ｐ）のネットワーキングライブラリ６０６への入力として用いられ、Ｐ２Ｐライブラリ６０６は、圧縮されたストリーミングデータ６０３を複数のＱｏＳモジュール６０８Ａ、６０８Ｂ、６０８Ｃに分配する。これらのＱｏＳモジュールは図５を参照して上述したように構成される。これらのＱｏＳモジュールは、異なるネットワークチャネル６１０Ａ、６１０Ｂ、６１０Ｃ上で下流６１２Ａ、６１２Ｂ、６１２Ｃに送信するために、圧縮されたストリーミングデータ６０３から送信キューを生成する。

各ネットワークチャネルは、ネットワークトラフィックに対して異なる帯域幅をもつ。一例として、各ＱｏＳモジュール６０８Ａ、６０８Ｂ、６０８Ｃは、新しいＩフレームが第１ノードから第２ノードに送信するためにキューされるとき、まだ送信されていないフレームを送信キュー５０３からドロップする、および／または、上述のように次の送信キューからフレームを予測的にドロップするように構成されたロジックを含む。ＱｏＳモジュール６０８Ａ、６０８Ｂ、６０８Ｃにおけるそのようなロジックは、上述の方法を実装するように構成される。各ＱｏＳモジュール６０８Ａ、６０８Ｂ、６０８Ｃは、それぞれネットワークチャネル６１０Ａ、６１０Ｂ、６１０Ｃ上で送信キューを送信するために利用可能な帯域幅の量を決定するように構成される。

本発明の実施の形態によれば、ビデオストリームによる帯域幅の使用はＱｏＳが課す制限まで最大化される。さらに、ビデオストリームにおけるギャップは時間に関して均等に分割される。それとは対照的に、新しいＩフレームについてＧｏＰの終わりでフレームを単純にドロップしたり、ＧｏＰの始まりまたは終わりからだけ予測してドロップするような単純なフレームドロッピングを実装すると、不均一な「ぎくしゃくした」ビデオになってしまう。さらに、本発明の実施の形態によれば、ＣＰＵ負荷、ネットワークの輻輳、あるいは一時的であるが異常にＱｏＳ帯域幅制限を低下させる他の要因による短期間のフレームドロッピングを正しく扱うことができる。本発明の実施の形態はまた、問題がなくなったときは、ビデオストリームを最適なドロップレートに回復させることができる。本発明の実施の形態のさらなる利点は、もしドロップされたフレームに依存する予測または双予測フレームが送信されていなくても、すべての送信されたフレームが受信側で復号可能なこともあることである。動き予測を用いて、受信側がもし十分な情報をもっているなら、使用できない予測フレームにおいて送信されたであろうデータを推測することもできる。

本発明の好ましい実施の形態を完全な形で説明してきたが、いろいろな代替物、変形、等価物を用いることができる。したがって、本発明の範囲は、上記の説明を参照して決められるものではなく、請求項により決められるべきであり、均等物の全範囲も含まれる。ここで述べた特徴はいずれも、好ましいかどうかを問わず、他の特徴と組み合わせてもよい。請求項において、明示的に断らない限り、各項目は１またはそれ以上の数量である。請求項において「〜のための手段」のような語句を用いて明示的に記載する場合を除いて、請求項がミーンズ・プラス・ファンクションの限定を含むものと解してはならない。

Claims (23)

1. ネットワーク上の第１ノードと第２ノードの間で送信されるストリーミングデータの品質を最適化する方法を実装するためのコンピュータ読み取り可能なインストラクションを格納したコンピュータ読み取り可能な記録媒体であって、
   前記ストリーミングデータは１以上のフレームグループを含み、
   前記フレームグループのそれぞれには、Ｉフレームと前記Ｉフレームを参照する１以上のＰフレームを含む複数のフレームが含まれ、当該方法は、
   前記フレームグループから１以上のフレームを含む送信キューを生成するステップと、
   前記送信キューを前記第１ノードから前記第２ノードに順次送信する送信ステップと、
   新しいＩフレームが送信のためにキューされるとき、現在送信中のＩフレームを除き、前記送信キューのまだ送信されていない任意のフレームを前記送信キューからドロップする第１ドロップステップと、
   前記送信キューからドロップされたＰフレームの数Ｐを判定するステップと、
   次に送信するフレームグループに対しては、その前のフレームグループに対して生成された送信キューからドロップされたＰフレームの個数にもとづいて、次に送信するフレームグループに対して生成された送信キューから０からＰ個のＰフレームをドロップする第２ドロップステップと
   を含むことを特徴とするコンピュータ読み取り可能な記録媒体。
2. 前記第２ドロップステップは、次のフレームグループに残るＰフレームが次のフレームグループにわたって実質的に均等に間隔を空けるように１以上のＰフレームを選択的にドロップするステップを含む請求項１のコンピュータ読み取り可能な記録媒体。
3. 前記フレームグループはそれぞれ、直近のＩフレームおよび／またはＰフレームを参照する１以上のＢフレームを含み、送信キューからドロップされたＰフレームを参照する任意のＢフレームを該送信キューからドロップするステップをさらに含む請求項１のコンピュータ読み取り可能な記録媒体。
4. 前記第２ドロップステップは、最初のフレームグループに対して生成された送信キューからドロップされた、最初のフレームグループのＰフレームの数に等しいドロップカウント（ＤＣ）を決定するステップを含む請求項１のコンピュータ読み取り可能な記録媒体。
5. 前記第２ドロップステップは、次のフレームグループの直前のフレームグループに対して生成された送信キューにあるすべてのＰフレームが送信されたならば、ドロップカウントをデクリメントするステップを含む請求項４のコンピュータ読み取り可能な記録媒体。
6. 前記第２ドロップステップは、次のフレームグループの直前のフレームグループに対して生成された送信キューにあるすべてのＰフレームよりも少ない数のＰフレームしか送信されなかったならば、ドロップカウントをインクリメントするステップを含む請求項４のコンピュータ読み取り可能な記録媒体。
7. 前記第２ドロップステップは、ドロップカウントＤＣに等しい数のフレームをドロップするステップを含む請求項４のコンピュータ読み取り可能な記録媒体。
8. 前記送信ステップは、最初のフレームグループの１以上のフレームをトラフィックシェーピングするステップを含む請求項１のコンピュータ読み取り可能な記録媒体。
9. 前記送信ステップは、現在送信中のＩフレームの送信を完了するステップと、それに続いてもっとも最近受信したＩフレームを送信するステップとを含む請求項１のコンピュータ読み取り可能な記録媒体。
10. 現在送信中のＩフレームともっとも最近受信したＩフレームの間に受信された中間のＩフレームを送信キューからドロップするステップをさらに含む請求項９のコンピュータ読み取り可能な記録媒体。
11. １以上の前記フレームグループは、ビデオストリームの１以上のピクチャグループ（ＧｏＰ）および／またはオーディオストリームの１以上のフレームおよび／またはゲームストリームの１以上のフレームおよび／またはファイル転送ストリームの１以上のフレームを含む請求項１のコンピュータ読み取り可能な記録媒体。
12. ネットワーク上の第１ノードと第２ノードの間で送信されるストリーミングデータの品質を最適化する装置であって、
    前記ストリーミングデータは、Ｉフレームと前記Ｉフレームを参照する１以上のＰフレームを含む複数のフレームが含まれるフレームグループを含み、当該装置は、
    前記フレームグループから送信キューを生成するよう構成されたロジックを含むＱｏＳモジュールを含み、
    前記ロジックは、さらに、新しいＩフレームが前記第１ノードから前記第２ノードに送信するためにキューされるとき、まだ送信されていないすべてのフレームを前記送信キューからドロップするように構成されており、
    前記ロジックは、
    前記送信キューからドロップされたＰフレームの数Ｐを判定し、
    次のフレームグループに対しては、その前のフレームグループに対して生成された送信キューからドロップされたＰフレームの個数にもとづいて、次のフレームグループに対して生成された送信キューから０からＰ個のＰフレームをドロップすることを特徴とする装置。
13. 前記ロジックは、次のフレームグループに残るＰフレームが実質的に均等に間隔を空けるように１以上のＰフレームを選択的にドロップするように構成される請求項１２の装置。
14. 前記ロジックは、送信キューからドロップされたＰフレームを参照する１以上のＢフレーム該送信キューからドロップするように構成される請求項１２の装置。
15. 前記ロジックは、最初のフレームグループに対して生成された送信キューからドロップされた、最初のフレームグループのＰフレームの数に等しいドロップカウント（ＤＣ）を決定するように構成される請求項１２の装置。
16. 前記ロジックは、次のフレームグループの直前のフレームグループに対して生成された送信キューにあるすべてのＰフレームが送信されたならば、ドロップカウントをデクリメントするように構成される請求項１５の装置。
17. 前記ロジックは、次のフレームグループの直前のフレームグループに対して生成された送信キューにあるすべてのＰフレームよりも少ない数のＰフレームしか送信されなかったならば、ドロップカウントをインクリメントするように構成される請求項１５の装置。
18. 前記ロジックは、ドロップカウントＤＣに等しい数のフレームをドロップするように構成される請求項１５の装置。
19. 前記ロジックは、最初のフレームグループの１以上のフレームをトラフィックシェーピングするように構成される請求項１２の装置。
20. 前記ロジックは、現在送信中のＩフレームの送信を完了し、それに続いてもっとも最近受信したＩフレームを送信するように構成される請求項１２の装置。
21. 前記ロジックは、現在送信中のＩフレームともっとも最近受信したＩフレームの間に受信された中間のＩフレームを、送信キューからドロップするように構成される請求項２０の装置。
22. 前記ＱｏＳモジュールに機能的に接続される受信器モジュールをさらに含み、前記受信器モジュールは上流ノードから前記フレームグループを受信するように構成される請求項１２の装置。
23. 前記ＱｏＳモジュールに機能的に接続される送信器モジュールをさらに含み、前記送信器モジュールは前記第１ノードから前記第２ノードに送信キューを送信するように構成される請求項１２の装置。

Images