(57)【要約】ネットワークへのデータ出力を制御するシステムが、所定の時間内にネットワークから読み取り可能のデータ量に基づいてネットワークへ出力可能のデータの最大量を決定し、次に、実際にネットワークへ出力したデータ量と最大量との差を得る。システムは、次に、その差に基づく量のデータパケットを所定の時間内にネットワークへ出力する。所定の時間内にネットワークへ出力すべき最後のデータパケットについて、システムが、そのデータパケットをネットワークへ出力するとデータ量が前記の差を超える場合に、前記の差を超えるビット数を示す第１の数を決定し、そのデータパケットをネットワークへ出力しないとデータ量が前記の差より少なくなる場合に、前記の差より少なくなるビット数を示す第２の数を決定し、第１の数が第２の数より小さい場合にデータパケットを出力する。
2004522325.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークへのデータ出力を制御する方法であって、
所定の時間内にネットワークから読み取り可能のデータ量に基づいて、ネットワークへ出力可能のデータの最大量を決定するステップ、
実際にネットワークへ出力したデータ量と最大量との差を得るステップ、及び、
前記差に基づく量のデータパケットを、所定の時間内にネットワークへ出力するステップ
を含む方法。
【請求項２】
所定の時間内にネットワークへ出力すべき最後のデータパケットについて、前記出力するステップが、
前記データパケットをネットワークへ出力するとデータ量が前記差を超える場合に、前記差を超えるビット数を示す第１の数を決定するステップ、
前記データパケットをネットワークへ出力しないとデータ量が前記差より少なくなる場合に、前記差より少なくなるビット数を示す第２の数を決定するステップ、及び、
第１の数が第２の数より小さい場合に、データパケットを出力するステップ
を含む、請求項１に記載の方法。
【請求項３】
前記決定するステップの前に、更に、
ネットワークのデータ容量を決定するステップ、及び、
ネットワークのデータ容量に実質的に対応する量のデータをネットワークへ出力するステップ
を含む、請求項１に記載の方法。
【請求項４】
ネットワークが複数のネットワークセグメントを含み、各ネットワークセグメントが異なる帯域幅を持ち、
前記決定するステップが、最小量の利用可能帯域幅を持つネットワークセグメントが処理可能のデータ量に基づいてネットワークへ出力可能のデータの最大量を決定する、
請求項１に記載の方法。
【請求項５】
データパケットが映像のイントラフレームを含み、更に少なくとも一つの予測フレーム及び双方向フレームを含み、
前記出力するステップが、イントラフレームを出力し、少なくとも一部分の予測フレーム及び／又は双方向フレームを出力しない、
請求項１に記載の方法。
【請求項６】
ネットワークへ出力可能のデータの最大量を部分的にネットワークの帯域幅に基づいて決定し、
ネットワークの帯域幅が時刻により変化し、
前記出力するステップが、ネットワークの帯域幅に基づいて、前記予測フレーム及び前記双方向フレームを出力すべきか否かを決定する、
請求項５に記載の方法。
【請求項７】
前記データパケットが、ＭＰＥＧ−１、ＭＰＥＧ−２及びＭＰＥＧ−４の一つを用いてコード化された映像を含み、ネットワークがインターネットを含む、請求項１に記載の方法。
【請求項８】
ネットワークへのデータパケット出力を、実質的にネットワークの帯域幅に対応するビットレートでコード化する、請求項１に記載の方法。
【請求項９】
ネットワークへのデータ出力を制御するための装置であって、
コンピュータが実行可能のプロセスステップを格納するメモリー、及び、
前記メモリーに格納されたプロセスステップを実行し、（ｉ）所定の時間内にネットワークから読み取り可能のデータ量に基づいてネットワークへ出力可能のデータの最大量を決定し、（ｉｉ）実際にネットワークへ出力したデータ量と最大量との差を得、且つ（ｉｉｉ）前記差に基づく量のデータパケットを所定の時間内にネットワークへ出力するプロセッサ
を具える装置。
【請求項１０】
所定の時間内にネットワークへ出力すべき最後のデータパケットについて、前記プロセッサが、（ｉ）前記データパケットをネットワークへ出力するとデータ量が前記差を超える場合に、前記差を超えるビット数を示す第１の数を決定し、（ｉｉ）前記データパケットをネットワークへ出力しないとデータ量が前記差より少なくなる場合に、前記差より少なくなるビット数を示す第２の数を決定し、且つ（ｉｉｉ）第１の数が第２の数より小さい場合に、データパケットを出力する、請求項９に記載の装置。
【請求項１１】
データの最大量を決定する前に、前記プロセッサが、（ｉ）ネットワークのデータ容量を決定し、且つ（ｉｉ）ネットワークのデータ容量に実質的に対応する量のデータをネットワークへ出力する、請求項９に記載の装置。
【請求項１２】
ネットワークが複数のネットワークセグメントを含み、各ネットワークセグメントが異なる帯域幅を持ち、
前記プロセッサが、最小量の利用可能帯域幅を持つネットワークセグメントが処理可能のデータ量に基づいてネットワークへ出力可能のデータの最大量を決定する、
請求項９に記載の装置。
【請求項１３】
データパケットが映像のイントラフレームを含み、更に少なくとも一つの予測フレーム及び双方向フレームを含み、
出力する間、前記プロセッサが、イントラフレームを出力し、少なくとも一部分の予測フレーム及び／又は双方向フレームを出力しない、
請求項９に記載の装置。
【請求項１４】
ネットワークへ出力可能のデータの最大量を部分的にネットワークの帯域幅に基づいて決定し、
ネットワークの帯域幅が時刻により変化し、
前記プロセッサが、ネットワークの帯域幅に基づいて、前記予測フレーム及び前記双方向フレームを出力すべきか否かを決定する、
請求項１３に記載の装置。
【請求項１５】
前記データパケットが、ＭＰＥＧ−１、ＭＰＥＧ−２及びＭＰＥＧ−４の一つを用いてコード化された映像を含み、ネットワークがインターネットを含む、請求項９に記載の装置。
【請求項１６】
ネットワークへのデータパケット出力が、実質的にネットワークの帯域幅に対応するビットレートでコード化される、請求項９に記載の装置。
【請求項１７】
コンピュータが読み取り可能の媒体に格納されたコンピュータ実行可能のプロセスステップであって、請求項１乃至８のいずれか１項に記載の方法の各ステップを遂行するためのコード、即ち、
所定の時間の間にネットワークから読み取り可能のデータ量に基づいて、ネットワークへ出力可能のデータの最大量を決定するためのコード、
実際にネットワークへ出力したデータ量と最大量との差を得るためのコード、及び、
前記差に基づく量のデータパケットを、所定の時間内にネットワークへ出力するためのコード
を含む、コンピュータ実行可能のプロセスステップ。
【請求項１８】
ネットワーク上のデータの輻輳を減らすために映像データのフローが制御されるネットワークシステムであって、
映像データをコード化し、コード化された映像データをネットワークへ出力する送信機、及び、
ネットワークから所定のレートでコード化された映像データを読み取り、コード化された映像データをデコードし、デコードされた映像データに基づいて映像を形成する受信機
を具え、
受信機がネットワークからコード化された映像データを読み取るレートと実質的に同一のレートで、送信機がコード化された映像データをネットワークへ出力するネットワークシステム。
【請求項１９】
送信機が、（ｉ）所定の時間内に受信機によりネットワークから読み取り可能のデータ量に基づいてネットワークへ出力可能のデータの最大量を決定し、（ｉｉ）実際にネットワークへ出力したデータ量と最大量との差を得、且つ（ｉｉｉ）前記差に基づく量のコード化された映像データを所定の時間内にネットワークへ出力することにより、コード化された映像データをネットワークへ出力する、請求項１８に記載のネットワークシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データがネットワークから読み取られるレートに基づいてネットワークへのデータのフローを制御するためのシステムを指向している。本発明は、データオーバーフロー、データアンダーフロー、及びネットワークの輻輳を減らし、それにより、映像の品質を向上させるので、インターネット上の映像データの送信に関して特別な用途を有する。
【０００２】
【従来の技術】
現在実在するネットワークシステムは、オーディオ−ビジュアルデータからなるリアルタイムの映像を異なるノード間に送信する機能を持つ。特にインターネットは、近年、転送される映像の量の劇的な増大を経験した。しかしながら、ネットワークの映像（特にインターネットの映像）を経験した人は誰でも、望み通りにならないことが多いことを知っている。例えば、映像中の動きが、度々、ぎくしゃくして流動的ではないように見える。更に、映像の動きとオーディオのデータとが一致せず、それにより、映像の品質を一層低下させている。
【０００３】
上述のネットワーク映像の問題の原因は多数ある。その一つは、ネットワーク中を動くデータのフロー制御に関する。インターネットを例にとると、インターネットは、例えば映像データの「ストリーム」をインターネットに出力するマルチメディアアプリケーションのような、「ストリーミング」アプリケーションからのデータを処理するために、ユーザーデータグラムプロトコル（ＵＤＰ）を用いる。しかしながら、ＵＤＰは固有のフロー制御機能を持っていない。即ち、ＵＤＰは、ネットワーク上に存在するデータの量に関係なく映像データを出力する。ネットワークが既に容量の限界に達している場合は、これは、映像データのロスを発生させる可能性があり、それにより上述のように映像の品質が低下する。他方、ネットワークの容量に余剰がある場合は、映像データにギャップが発生し、これも更に映像の品質を低下させる原因になる。
【０００４】
特にＵＤＰ適応のマルチメディアアプリケーションにおいて、固有のフロー制御機能を欠く場合に、他の問題が発生する。特に、これらのアプリケーションはネットワークの現在の容量に関係なく映像データを出力するため、それらは、転送制御プロトコル（ＴＣＰ）のような社会性のより高いプロトコルの上で動作しているｆｔｐ、ｔｅｌｎｅｔ等の他のアプリケーションにとって脅威となり得る。実際に、低品質設計のＵＤＰマルチメディアアプリケーションの蔓延により、インターネットが輻輳し、極端な場合は停止してしまう。
【０００５】
従来の開発者は、ネットワークにデータを出力する送信機の動作をネットワークからデータを読み取る受信機の動作に同期させることにより、上述の技術的な問題点に取り組んできた。例えば、マサチューセッツ大学でネットワーク上の音声会議用に開発されたＮｅｔｗｏｒｋ Ｖｏｉｃｅ Ｔｅｒｍｉｎａｌ（ＮｅＶｏＴ）アプリケーションは、入力装置（例えばマイクロホン）からネットワークへ及びネットワークから出力装置（例えばスピーカー）への音声データの転送を制御するために、同一の音声サンプリングクロックを用いる。即ち、毎回、入力装置が音声の全ブロックをアプリケーションに渡し、ネットワーク上の再生バッファから同一の長さの音声ブロックをコピーして出力装置に送る。
【０００６】
上述の解は入力と出力とのタイミングを合わせることにより、バッファのオーバーフロー及びアンダーフローを減らすが、中間のネットワークの特性を考慮していないという事実から生じるいくつかの欠点を持っている。例えば、上述の通常のフロー制御方法においては、ネットワークの帯域幅に関係なく、データは、ネットワークインターフェースが処理できる限度の高い速度でネットワークに送られる。ネットワークが高いビットレートを処理できない帯域幅を持つ場合には、これはネットワークの輻輳の原因となり、データのロスを発生させ、ネットワークの性能を低下させる。
【０００７】
【発明が解決しようとする課題】
従って、インターネットのようなネットワークの輻輳並びにバッファのオーバーフロー及びアンダーフローから生じる有害な効果を低減するため、ネットワークへのデータのフローを制御するシステムに対する必要性が存在する。
【０００８】
【課題を解決するための手段】
本発明は、所定の時間内にネットワーク（例えばインターネット）から読み取られたデータの量を決定し、同一の所定の時間内にネットワークへ実質的に同一量のデータを出力することにより、上述の必要性を解決する。このようにしてデータがネットワークへ出力されるレートを制御することにより、本発明は、バッファのオーバーフロー及び／又はアンダーフローをシステム中に殆ど持ち込むこと無しに、ネットワークの輻輳を低減することができる。
【０００９】
本発明は、一つの観点によれば、ネットワークへのデータ出力を制御するシステム（即ち、方法、装置、及びコンピュータが実行可能のプロセスステップ）である。このシステムは、所定の時間内にネットワークから読み取り可能のデータ量に基づいて、ネットワークへ出力可能のデータの最大量を決定し、次に、実際にネットワークへ出力したデータ量と最大量との差を得る。その後、システムは、その差に基づく量のデータパケットを、所定の時間内にネットワークへ出力する。
【００１０】
好ましい実施例においては、これらのデータパケットは、映像のイントラ（Ｉ）フレームを含み、更に、映像の予測（Ｐ）フレーム及び／又は双方向（Ｂ）フレームを含む。これらの実施例においては、イントラフレームがネットワークへ出力される。一方、予測フレーム及び／又は双方向フレームの少なくとも一部分は出力されない。予測フレーム及び／又は双方向フレームが出力されるか否かは、ネットワークの帯域幅によって変わる。本発明のこれらの特徴により、ネットワークの帯域幅が全てのフレームを収容するために充分ではない場合においても、最も重要なフレーム（即ちイントラフレーム）を保護することができる。これは、帯域幅が可変のネットワークにおいては、常にではないとしても、かなり頻繁に起きる。
【００１１】
本発明の他の好ましい実施例においては、所定の時間内にネットワークへ出力すべき最後のデータパケットについて、システムが、データパケットをネットワークへ出力するとデータ量が前記の差を超える場合に、前記の差を超えるビット数を示す第１の数を決定し、データパケットをネットワークへ出力しないとデータ量が前記の差より少なくなる場合に、前記の差より少なくなるビット数を示す第２の数を決定し、第１の数が第２の数より小さい場合にデータパケットを出力するが、第１の数が第２の数より大きい場合には出力しない。これらの特徴により、本発明においては、ネットワークの容量に極めて近い量のデータをネットワークへ出力することができる。従って、本発明は、実質的にバッファのオーバーフロー及び／又はアンダーフロー無しに、その環境において可能な最大のデータスループットを保持することができる。
【００１２】
更に他の好ましい実施例においては、本発明によれば、最小量の利用可能帯域幅を持つネットワークセグメントが処理可能のデータの最大量に基づいてネットワークへ出力可能のデータの最大量を決定する。即ち、この場合、「ボトルネック」（即ちネットワークにおける利用可能の帯域幅が最小の部分）が、ネットワークに対して出力及び読み取り可能の最大レートを決定する。このため、本発明によれば、ボトルネックの帯域幅によってネットワークに対する出力及び読み取りを行うデータのフローを制御する。これは、ボトルネックによって発生するネットワークの輻輳並びにバッファのオーバーフロー及びアンダーフローの機会を低減する。
【００１３】
他の観点によれば、本発明は、ネットワーク上のデータの輻輳が低減するように映像データのフローが制御されるネットワークシステムである。このネットワークシステムは、映像データをコード化し、コード化された映像データをネットワークへ出力する送信機を含む。更に、このシステムは、ネットワークから所定のレート（例えば、ネットワークのボトルネックの帯域幅によって決まる）でコード化された映像データを読み取り、コード化された映像データをデコードし、デコードされた映像データに基づいて映像を形成する受信機を含む。本発明によれば、受信機がネットワークからコード化された映像データを読み取るレートと実質的に同一のレートで、送信機がコード化された映像データをネットワークへ出力する。受信機がネットワークからコード化された映像データを読み取るレートと実質的に同一のレートで、コード化された映像データをネットワークへ出力することにより、本発明によれば、ネットワークの輻輳を低減させることができ、更に、バッファのオーバーフロー及びアンダーフローの発生を低減させることができる。
【００１４】
【発明の実施の形態】
以上の概要の説明は、本発明の性質が迅速に理解されるように行われた。本発明の完全な理解は、添付の図面を用いて以下に行われる好ましい実施例の詳細な説明によって得ることができる。
【００１５】
図１は、本発明を実現することができるネットワークシステム１の例を示す図である。図１に示されるように、ネットワークシステム１は、２及び４のような複数のノード及びネットワークメディア５を含む。ネットワークメディア５は、例えばイーサネットケーブル、無線リンク、又はそれらの組合せであり、それらの上を、映像データ（即ちオーディオ−ビジュアルデータ）及び他の情報からなるデータパケットが種々のノード間で送信される。この場合、ネットワーク１は、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、帯域幅可変ネットワーク、ＡＴＭネットワーク、インターネット等、どのような型のネットワークでも含むことができる。
【００１６】
本発明の目的のため、ノード２は、ディジタルビデオカメラその他（図示されていない）のような入力装置から映像データを受信し、映像データをコード化し、コード化された映像データをネットワークへ出力する送信機を具える。これに代えて、ノード２は、予め格納済みのコード化されたデータを含み、それをネットワークへ出力することができる。本発明の目的のため、ノード４は、コード化されたデータを受信する受信機を具える。ノード４が動作する場合、ネットワークからコード化された映像データを所定のレートで読み取り、コード化された映像データをデコードし、デコードされた映像データに基づいて、ディスプレイスクリーンその他のような出力装置上に映像を形成する。詳細に後述するように、フロー制御は、ノード２（送信機）により、ノード４（受信機）がネットワークからコード化された映像データを読み取るレートと実質的に同一のレートでコード化された映像データを出力することによって行われる。
【００１７】
ノード２及び４は、どのような型のディジタルデータ送受信装置でも具えることができる。これらは、映像会議装置及び、例えば１９９８年４月２０日に出願された米国特許出願第０９／０６２，９３９号”Ｄｉｇｉｔａｌ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍ Ｗｈｉｃｈ Ｓｅｌｅｃｔｓ Ｉｍａｇｅｓ Ｆｏｒ Ｄｉｓｐｌａｙ ｉｎ Ａ Ｖｉｄｅｏ Ｓｅｑｕｅｎｃｅ”に記載されているような、ディジタルテレビジョンシステム（例えば送信機及びディジタルテレビジョン及び／又はセットトップボックス）を含むが、これに限定されない。しかしながら、簡潔にするため、本発明は、それぞれが上述のように映像データをネットワークへ送信し且つネットワークから映像データを読み取る機能を具える、ネットワーク化された二つのコンピュータについて説明されるであろう。
【００１８】
図２は、ノード２及び４を含むネットワーク化されたコンピュータのためのコンピュータ装置６の代表的な例を示す図である。図２に示されるように、パーソナルコンピュータ（ＰＣ）７は、ネットワーク５に対するインターフェースであるネットワークコネクション９、及び、ネットワーク又はＰＣ７に映像データを入力するディジタルビデオカメラ（図示されていない）のような他の装置に対するインターフェースであるファックス／モデムコネクション１０を含む。ＰＣ７は更に、（映像を含む）情報をユーザーに表示するためのディスプレイスクリーン１１、テキスト及びユーザーコマンドを入力するためのキーボード１２、ディスプレイスクリーン１１上でカーソルの位置を決めユーザーコマンドを入力するためのマウス１４、挿入されたフロッピーディスクに対する読み取り及び書き込みを行うためのディスクドライブ１５、及び、ディジタルビデオディスク（ＤＶＤ）上に格納された映像について入力及びアクセスを行うためのディジタルビデオディスクドライブ１６を含む。ＰＣ７は更に、プリンター１７その他のような、それに接続された一又は複数の周辺装置を含むことがある。
【００１９】
図３は、ＰＣ７の内部構造を示す図である。図３に示されるように、ＰＣ７は、コンピュータハードディスク及び／又はＲＡＩＤ（ｒｅｄｕｎｄａｎｔ ａｒｒａｙ ｏｆ ｉｎｅｘｐｅｎｓｉｖｅ ｄｉｓｋ）のようなコンピュータが読み取り可能の媒体であるメモリー１９を含む。メモリー１９は、データ２０、アプリケーション２１、プリントドライバー２２、及びオペレーティングシステム２４を格納する。本発明の好ましい実施例においては、オペレーティングシステム２４は、マイクロソフトウィンドウズ９８のようなウィンドウ型のオペレーティングシステムであるが、他のオペレーティングシステムを用いても同様に本発明を実施することができる。メモリー１９に格納されたアプリケーションの中には、マルチメディアアプリケーション２５、ビデオコーダ２６、ビデオデコーダ２７、及びフローコントローラ２９がある。
【００２０】
要約すると、マルチメディアアプリケーション２５は、映像を処理、表示及び編集するための多くの既知のマルチメディアアプリケーションのいずれかを含むことができる。図４に示されるように、ビデオコーダ２６は、マルチメディアアプリケーション２５から出力される映像データをコード化するビデオエンコーディングアプリケーションを含む。ＤＶＢ、ＭＰＥＧ−１、ＭＰＥＧ−２及びＭＰＥＧ−４を含むがこれらに限定されない多くの既知のコード化技術のいずれでも利用することができる。ビデオデコーダ２７は、例えばこれらの技術の一つによりコード化された映像データをデコードする、ビデオデコーディングアプリケーションを含む。フローコントローラ２９は、詳細に後述するように、コード化された映像データのネットワーク５への出力を制御することにより、本発明を実現する。これに関し、本発明の好ましい実施例がコード化された映像データのフローを制御するために用いられるが、本発明は、コード化されていない映像（即ち非映像）データを制御するためにも同様に用いられる。
【００２１】
図３に戻ると、ＰＣ７は更にディスプレイインターフェース３０、キーボードインターフェース３１、マウスインターフェース３２、ディスクドライブインターフェース３４、ＤＶＤドライブインターフェース３５、コンピュータバス３６、ＲＡＭ３７、プロセッサ３９、及びプリンターインターフェース４０を含む。プロセッサ３９は、好ましくは、ＲＡＭ３７からの上述のようなアプリケーションを実行するためのマイクロプロセッサその他を含む。そのようなアプリケーションは、マルチメディアアプリケーション２５、ビデオコーダ２６、ビデオデコーダ２７、及びフローコントローラ２９を含み、（上述のように）メモリー１９に、又はこれに代えて、ディスクドライブ１５中のフロッピーディスク又はＤＶＤ１６中のＤＶＤに、格納することができる。プロセッサ３９は、ディスクドライブインターフェース３４を介してフロッピーディスク上に格納されたアプリケーション（又は他のデータ）にアクセスし、ＤＶＤドライブインターフェース３５を介してＤＶＤ上に格納されたアプリケーション（又は他のデータ）にアクセスする。
【００２２】
ＰＣ７のアプリケーションの実行及び他のタスクについては、キーボード１２又はマウス１４を用い、それぞれキーボードインターフェース３１又はマウスインターフェース３２を介して、プロセッサ３９にコマンドを送信してそれらを開始させることができる。ＰＣ７上で動作するアプリケーションからの出力結果は、ディスプレイインターフェース３０によって処理し、ディスプレイ１１上でユーザーに表示することができ、又はこれに代えて、ネットワークコネクション９を介してネットワーク５へ出力することができる。例えば、図４に示されるように、入力映像データは、典型的には、マルチメディアアプリケーション２５によって処理され、続いてビデオコーダ２６によってコード化され、フローコントローラ２９によりネットワークコネクション９を介して出力される。
【００２３】
他方、ネットワークから受信されたコード化されている映像データは、ビデオデコーダ２７によってデコードされ、続いてマルチメディアアプリケーションを用いてディスプレイ１１上に表示される。このため、ディスプレイインターフェース３０は、好ましくは、プロセッサ３９からコンピュータバス３６上に供給されたデコードされている映像データに基づいて、映像を形成し、それらの映像をディスプレイ１１に出力するためのディスプレイプロセッサを含む。ＰＣ７上で動作するワードプロセッシングプログラム等の他のアプリケーションからの出力結果は、プリンターインターフェース４０を介してプリンター１７（又はこれに代えて図示されていないネットワーク５上のプリンター）に供給することができる。プロセッサ３９は、プリンタドライバー２２を実行し、プリンターへの送信に先だって上記印刷ジョブの適当なフォーマッティングを行う。
【００２４】
フローコントローラ２９に戻ると、このアプリケーションは、コード化された映像（又は他の）データをネットワークへ送信するために、送信機２によって実行される。要約すると、フローコントローラ２９は、所定の時間内にネットワークから読み取り可能のデータ量に基づいてネットワークへ出力可能のデータの最大量を決定し、続いて実際にネットワークへ出力したデータ量と最大量との差を得ることにより、ネットワークへのデータ出力を制御するためにコンピュータが実行可能のコード（即ちプロセスステップ）を含む。その後、フローコントローラ２９は、前記の差に基づく量のデータパケットを所定の時間内にネットワークへ出力する。所定の時間内にネットワークへ出力すべき最後のデータパケットについて、フローコントローラ２９は、データパケットをネットワークへ出力するとデータ量が前記の差を超える場合に、その差を超えるビット数を示す第１の数を決定し、データパケットをネットワークへ出力しないとデータ量が前記の差より少なくなる場合に、その差より少なくなるビット数を示す第２の数を決定し、及び、第１の数が第２の数より小さい場合にデータパケットを出力する。他の場合は、データパケットをネットワークへ出力しない。
【００２５】
更に詳細に説明するため、フローコントローラ２９が実行するプロセスステップを図５に示す。先ず、ステップＳ５０１はネットワーク（例えばネットワーク５）のバッファ容量を決定する。この場合、データパケットがネットワーク上にある間はネットワークは実効的にバッファとして作用するが、その容量はネットワークの帯域幅及びネットワーク遅延に依存する。この場合、ネットワーク遅延は、データパケットがクライアントからサーバまでネットワーク上を一方向に移動するために必要な時間を含む。バッファ容量を計算するために用いられる帯域幅は、他のネットワークユーザー及び容量その他のようなネットワークに関連する他の要素を考慮に入れた場合のネットワークにおける最小利用可能帯域幅である。この最小利用可能帯域幅をここではネットワークの「ボトルネック」帯域幅と呼ぶ。この場合、それぞれが異なる帯域幅を持つ複数のセグメントからなるネットワークで、本発明を用いることができる。従って、ネットワークのバッファ容量を決定するために、最小の利用可能帯域幅を持つセグメントを利用し、他の帯域幅は考慮しない。他の帯域幅を利用せずに最小の利用可能帯域幅を利用する理由は、ボトルネック帯域幅が、ネットワークが相当量のデータロス及び／又は過度の輻輳なしに処理できる最大のビットレートを表すことによる。
【００２６】
図６に示すように、ネットワーク５は、帯域幅Ｂ１、Ｂ２及びＢ３を持つ複数のセグメントを含むことができる。この場合、帯域幅Ｂ２がネットワークの最小利用可能帯域幅、即ちボトルネック帯域幅とする。すると、本発明の目的のためには、ネットワーク５を図７に示すように抽象化することができる。即ち、ネットワーク５は、一つの帯域幅Ｂ２を持つと考えることができる。ステップＳ５０１は、ボトルネック帯域幅が決定されると、ボトルネック帯域幅及びネットワーク５についてのネットワーク遅延を用いてネットワーク５のバッファ容量を決定する。特に、ネットワーク５のバッファ容量は次のように決定される。
容量＝Ｂ２＊ネットワーク遅延  （１）
【００２７】
上述のように、ネットワーク遅延は、データパケットがクライアントからサーバまでネットワーク上を、往復ではなく、一方向に移動するために必要な時間を含む。
【００２８】
ステップＳ５０１に続いて、処理はステップＳ５０２に進む。ステップＳ５０２においては、本発明によれば、ネットワークのバッファ容量に実質的に対応する量のデータをネットワーク５へ出力する。例えば、出力されるデータ量は、ネットワークのバッファ容量の上及び下の双方の予め定められた範囲内とすることができる。データ量がネットワークのバッファ容量を超える場合は、過剰のデータをネットワークの各ノードに存在するバッファに吸収することができる。本発明の好ましい実施例においては、ステップＳ５０２は、ＤＶＢ、ＭＰＥＧ−１、ＭＰＥＧ−２、ＭＰＥＧ−４、その他のような多数の既知の技術の一つにより、ビデオコーダ２６によってコード化された映像データのパケットを出力する。
【００２９】
バックグラウンドとして、ＭＰＥＧコード化については、映像データのフレームを１６×１６ピクセルのマクロブロックに分割し、それぞれに個別の量子化スケール値を持たせることにより実行する。続いて、マクロブロックについて動き予測を実行し、それぞれのフレーム中のオブジェクト（即ち動いている映像）について動きベクトルを生成し、それにより送信すべきデータの量を減らす。続いて、マクロブロックを８×８ピクセルのブロックに分割する。これらの８×８ピクセルのブロックをそれぞれディスクリート余弦変換（ＤＣＴ）し、６４ピクセルの各々のＤＣＴ係数を発生する。続いて、８×８ピクセルブロック中のＤＣＴ係数を、対応するコード化パラメータ即ち量子化ウェイトによって除算する。
【００３０】
その後、更に、他の事項と共に量子化スケール値を考慮に入れるため、ＤＣＴ係数について計算を行う。続いて、ＤＣＴ係数について可変長コード化を行い、そのフレームについてのコード化された映像データを発生する。ＭＰＥＧコード化の更に完全な説明は、米国特許出願第０９／０９４，８２８号”Ｐｉｘｅｌ Ｄａｔａ Ｓｔｏｒａｇｅ Ｓｙｓｔｅｍ Ｆｏｒ Ｕｓｅ Ｉｎ Ｈａｌｆ−Ｐｅｌ Ｉｎｔｅｒｐｏｌａｔｉｏｎ”（１９９８．６．１５出願）で行われている。
【００３１】
上述の動きベクトルは、存在するフレームから映像のフレームを再生するために用いる。この場合、ＭＰＥＧはベースフレーム、即ちイントラ（Ｉ）フレームをコード化し、更に、動きベクトルにより前のＩ又はＰフレームから予測されるフレームからなる予測（Ｐ）フレーム、及び、前のＩ又はＰフレーム及び次のＩ又はＰフレームから内挿される双方向（Ｂ）フレームについのデータをコード化する。Ｉフレームは大部分のデータを含むため、正確な映像再生のキーである。本発明においては、ステップＳ５０２において、映像送信の全てのフレームを収容するために充分な帯域幅がネットワークに存在するか否かを決定することにより、これを認識する。充分な帯域幅が存在しない場合、本発明においては、Ｐ及びＢフレームから順に収容できないフレームを廃棄する。Ｉフレームは最後に廃棄する。従って、その環境において可能な限り多くのＩフレームが出力される。
【００３２】
次に、ステップＳ５０３においては、周期／期間（ｔ）を設定する。本発明においては、このステップにおいて１周期待機する。その間に受信機がネットワークからデータを読み取る。本発明においては、詳細に後述するように、データが読み取られた後、次のデータをネットワークへ出力することができる。ステップＳ５０３においては、周期は、メモリーから自動的に読み出すことができる。これに代えて、周期は、送信機のキーボード又はマウスを介して設定及び／又は変更することができる。この場合、周期を短縮することにより、映像の精細度（即ち解像度）を増すことができる。即ち、詳細に後述するように、本発明においては、毎周期ネットワークバッファを満たすように、コード化された映像データをネットワークへ出力する。周期の長さを短縮することによりバッファを満たす頻度が増す（即ち、バッファを満たす回数が増える）。これは、映像の精細度を増す。
【００３３】
ステップＳ５０３に続くステップＳ５０４においては、送信機がネットワークへ出力することができるデータの最大量を決定する。特に、ネットワークへ出力することができるデータの最大量ＥＴ（ｉ）は、送信機がｉ番目の（即ち現在の）周期までにネットワークへ出力できたデータ量に対応する。この最大量ＥＴ（ｉ）は、ｉ番目の周期に受信機によりネットワークから読み取ることができるデータ量（例えばビット数）に基づく。この場合、周期当たりに読み取ることができるデータ量は、次のように決定される。
読み取り量＝Ｂ２＊ｔ  （２）
ここでＢ２はネットワークのボトルネック帯域幅を示し、ｔは現在の周期ｉの長さを示す。
【００３４】
従って、送信機により出力することができるデータの最大量に対応するＥＴ（ｉ）は、
ＥＴ（ｉ）＝ＥＴ（ｉ−１）＋Ｂ２＊ｔ  （３）
によって決定される。ここで、ＥＴ（ｉ−１）は送信機がｉ−１番目の周期までにネットワークへ出力できたデータ量に対応する。従って、式（３）から明らかなように、ネットワークへ出力することができるデータの最大レート（即ち、現在の周期に出力することができるデータの最大量）は、ネットワークからデータが読み取られるレートに対応する。これは、本発明により、ネットワークの輻輳及び／又はバッファのオーバーフロー及びアンダーフローを回避するために設定される。
【００３５】
ステップＳ５０４に続いて処理はステップＳ５０５に進む。ステップＳ５０５は、周期ｉの開始時点で実際に既にネットワークへ出力したデータ量ＣＴ（ｉ−１）を決定する。この値は、現在の周期までにネットワークへ出力された全てのパケット中のビット数を合計することにより計算される。ＣＴ（ｉ−１）が決定された後、ステップＳ５０６では、ステップＳ５０４から得られるネットワークへ出力できるデータの最大量と、ステップＳ５０５から得られるネットワークへ実際に出力したデータ量との差を得る。この差Ｑ（ｉ）は、周期ｉに送信機（即ちデータソース）によってネットワークへ出力することができるデータの割当量を示す。Ｑ（ｉ）は、数学的に次のように定義される。
Ｑ（ｉ）＝ＥＴ（ｉ）＝ＣＴ（ｉ−１）  （４）
【００３６】
ステップＳ５０６に続いて処理はステップＳ５０７に進む。ステップＳ５０７においては、本発明によれば、ステップＳ５０６で決定された差に基づいて、送信機がＮ（Ｎ≧１）個のデータパケットを出力する。即ち、上記のネットワークへ出力できるデータの最大量とネットワークへ実際に出力したデータ量との差を計算することにより、ネットワークにおける現在の余剰容量、即ち、ネットワークが処理することができる追加のデータ量を得る。続いて、この値が送信機に送られ、送信機は、ネットワークの余剰容量より少ないか又はそれに等しい量のデータ（即ちＮ個のパケット）を出力する。このステップに続いて処理はステップＳ５０８に進む。
【００３７】
ステップＳ５０８は、Ｎ個のパケット（即ち、Ｎ個のサイズＴ（ｉ）のパケット）中のデータ量がネットワークの余剰容量（即ち、ステップＳ５０６で得られた差）に等しいか否かを決定する。等しい場合は処理はステップＳ５０９に進み、ステップＳ５０９ではタイマーがインクリメントされ、実際に出力されたデータ量ＣＴ（ｉ）が次のように更新される。
ＣＴ（ｉ）＝ＣＴ（ｉ−１）＋Ｔ（ｉ）  （５）
【００３８】
続いて処理はステップＳ５１０に進む。ステップＳ５１０では、送信すべきデータが残っているか否かを決定する。送信すべきデータが残っていない場合は処理を終了する。他方、送信すべきデータが残っている場合は、処理は、ステップＳ５０４に戻るか又はタイマーの期間を変更したい場合にはこれに代わってステップＳ５０３に戻り、上記のステップを繰り返す。
【００３９】
他方、ステップＳ５０８で、Ｎ個のパケット中のデータ量がネットワークの余剰容量に等しくないと場合（即ち、Ｔ（ｉ）がステップＳ５０６で得られた差に等しくない場合）は、ネットワークは追加のデータパケットを収容することができる。従って、この場合は、処理はステップＳ５１１乃至Ｓ５１４に進み、その環境で他のパケットを出力すべきか否かを決定する。
【００４０】
先ず、ステップＳ５１１で、もう一つ（即ち、Ｎ＋１番目）のデータパケットが出力されるとステップＳ５０６で決定された差（即ち、ネットワーク容量）を超えることになるビット数の第１の数Ｄ１を決定する。特に、Ｄ１は、Ｎ＋１番目のデータパケット中のデータ量（即ち、ビット数）、即ちＰ（Ｎ＋１）を、ステップＳ５０７で出力されたＮ個のパケットからなるビット数、即ちＴ（ｉ）に加算し、次に、その和からネットワーク容量、即ちＱ（ｉ）を減算することによって決定される。これは数学的に次のように表される。
Ｄ１＝Ｔ（ｉ）＋Ｐ（Ｎ＋１）−Ｑ（ｉ）（６）
【００４１】
その後、ステップＳ５１２で、もう一つ（即ち、Ｎ＋１番目）のデータパケットが出力されない場合におけるネットワーク容量超過量に対応するビット数の第２の数Ｄ２を決定する。換言すると、Ｄ２は、Ｎ＋１番目のデータパケットが出力されない場合にネットワーク上のデータ量がネットワーク容量を下回るビット数に等しい。特に、Ｄ２は、ステップＳ５０７で出力されたＮ個のパケットからなるビット数、即ちＴ（ｉ）をネットワーク容量、即ちＱ（ｉ）から減算することによって決定される。これは数学的に次のように表される。
Ｄ２＝Ｑ（ｉ）−Ｔ（ｉ）  （７）
【００４２】
次に、ステップＳ５１３で、Ｄ１がＤ２より小さいか否かを決定する。Ｄ１がＤ２より小さい場合は、Ｎ＋１番目のデータパケットによりネットワーク容量を超すこととなる量が、Ｎ＋１番目のデータパケットが出力されない場合にネットワークが容量不足になる量より小さいことを意味する。この場合は、Ｎ＋１番目のデータパケットを出力すれば、Ｎ＋１番目のデータパケットを出力しない場合に比較して、ネットワークはその容量により近くなるので、ステップＳ５１４でＮ＋１番目のデータパケットを出力する。ネットワークの容量を超えるデータ量は、ネットワークのノードでバッファに格納することができる。その後、ステップＳ５０９で、タイマーをインクリメントし、次のように、実際に出力したデータ量ＣＴを更新する。
ＣＴ（ｉ）＝ＣＴ（ｉ−１）＋Ｐ（Ｎ＋１）＋Ｔ（ｉ）  （８）
【００４３】
続いて処理はステップＳ５１０に進む。ステップＳ５１０では、送信すべきデータが残っているか否かを決定する。送信すべきデータが残っていない場合は処理を終了する。他方、送信すべきデータが残っている場合は、処理は、ステップＳ５０４に戻るか又はタイマーの期間を変更したい場合にはこれに代わってステップＳ５０３に戻り、次の周期の新しいデータについて上記のステップを繰り返す。
【００４４】
ステップＳ５１３に戻ると、Ｄ１がＤ２より大きい場合は、Ｎ＋１番目のデータパケットによりネットワーク容量を超すこととなる量が、Ｎ＋１番目のデータパケットが出力されない場合にネットワークが容量不足になる量より大きいことを意味する。この場合は、Ｎ＋１番目のデータパケットを出力しない場合に、Ｎ＋１番目のデータパケットを出力する場合に比較して、ネットワークはその容量により近くなるので、Ｎ＋１番目のデータパケットを出力しない。その後、処理はステップＳ５０９に進み、ステップＳ５０９で、次のように、実際に出力したデータ量ＣＴを更新する。
ＣＴ（ｉ）＝ＣＴ（ｉ−１）＋Ｔ（ｉ）  （９）
【００４５】
（上式（８）とは逆に）式（９）にはＰ（Ｎ＋１）についての値は含まれていないことに注意すべきである。これは、この場合、次のパケットが出力されないためである。続いて処理はステップＳ５１０に進む。ステップＳ５１０では、送信すべきデータが残っているか否かを決定する。送信すべきデータが残っていない場合は処理を終了する。他方、送信すべきデータが残っている場合は、処理は、ステップＳ５０４に戻るか又はタイマーの期間を変更したい場合にはこれに代わってステップＳ５０３に戻る。その後、次の周期の新しいデータについて上記のステップを繰り返す。この時点で、本発明は、一つのＮ＋１番目のデータパケットの出力に基づいて決定を行うことには限定されないことに注意すべきである。即ち、上述の決定は、最初のＮ個のデータパケットの後における複数のデータパケットの出力に基づいて同様に行うことができる。
【００４６】
ステップＳ５０８乃至Ｓ５１４によれば、本発明は、ネットワークの過度の輻輳を起こすことなく、また、ネットワークバッファの著しいアンダーフロー又はオーバーフロー起こすことなく、ネットワークを容量に（又はその環境において可能な限り容量の近くに）保持することができる。その結果、本発明によれば、利用可能のネットワーク帯域幅の量において実質的に最高の精細度を持つ映像を提供することができる。この場合、上述のように、本発明によれば、Ｉ、Ｐ及びＢフレームを含む、ＭＰＥＧコード化映像データを送信することが望ましい。ネットワークの帯域幅がビデオコーダ２６によって生成される全てのデータを収容できない場合は、本発明によれば、上述のように、ステップＳ５０２、Ｓ５０７及び／又はＳ５１４においてデータパケットを出力する際に、Ｐ及び／又はＢフレームの一部又は全てを「廃棄」し、Ｉフレームの帯域幅を確保する。
【００４７】
本発明が一定帯域のネットワークに適用される場合はネットワークのボトルネックに対応するビットレートで映像データをコード化することができるので、上記の廃棄は、本発明が可変帯域のネットワークに適用される場合に（常にではなく）しばしば起きる。可変帯域ネットワークの場合（実際には、一定帯域ネットワークの場合も）、受信機は、送信機から受信する一秒当たりのビット数をカウントすることにより、ネットワークのボトルネック帯域幅の近似測定値を得ることができる。続いて、このボトルネック帯域幅の測定は、ネットワークを介して（例えばＲＴＣＰ等を通して）送信機に返信され、図５に示すプロセスで利用される。
【００４８】
最後に、本発明の好ましい実施例は本発明をソフトウェアによって実行しているが、それらの観点は、ハードウェアによっても同様に実行することができる。例えば、ビデオコーダ、ビデオデコーダ、及びフローコントローラは、全て個別のハードウェア要素で構成することができる。フローコントローラの場合、これは、図５に示す機能を実行する加算器、乗算器、及びその他によってフローコントローラを構成することができることを意味する。
【００４９】
上記においては、特定の例示的な実施例によって本発明を説明した。本発明は上記の実施例及びその修正に限定されるものではないこと、及び、請求項の精神及び範囲を逸脱せずに当業者により種々の変更及び修正が可能であることが理解されるべきである。
【図面の簡単な説明】
【図１】本発明を実行することができるネットワークシステムの例を示す図である。
【図２】図１のネットワークシステム上の映像データ送受信ノードのためのコンピュータ装置の拡大図である。
【図３】図２のコンピュータ装置に含まれるＰＣのアーキテクチャを示す図である。
【図４】マルチメディアアプリケーションとネットワークとの間のデータストリームにおける本発明のフローコントローラの位置を示す図である。
【図５】本発明を実行するためのプロセスステップを示す図である。
【図６】図１に示されたネットワークのそれぞれ異なる帯域幅を持つ種々のセグメントを示す図である。
【図７】図６に示されたセグメントについての可変帯域幅の最小量である本発明の目的のためのネットワークの実効的な帯域幅を示す図である。
【国際公開パンフレット】
2004522325.tif 000003
2004522325.tif 000004
2004522325.tif 000005
2004522325.tif 000006
2004522325.tif 000007
2004522325.tif 000008
2004522325.tif 000009
2004522325.tif 000010
2004522325.tif 000011
2004522325.tif 000012
2004522325.tif 000013
2004522325.tif 000014
2004522325.tif 000015
2004522325.tif 000016
2004522325.tif 000017
2004522325.tif 000018
2004522325.tif 000019
2004522325.tif 000020
2004522325.tif 000021
2004522325.tif 000022
2004522325.tif 000023
2004522325.tif 000024
2004522325.tif 000025
2004522325.tif 000026
2004522325.tif 000027
【国際調査報告】
2004522325.tif 000028
2004522325.tif 000029
2004522325.tif 000030