(57)【要約】【課題】大型テレビ会議用複数レベルの渋滞制御。【解決手段】データをストリームする方法が説明される。方法において、タイミング・パケットのペアが定期的にクライアントに伝送され、ペアの内第２パケットは既知の遅延をもって第１パケットの後に伝送される。複数の報告がクライアントから受信され、各報告はクライアントによりタイミング・パケットのペアの内第１パケットおよび第２パケットが受信される時間の経過の長さを表す時間間隔Δｔ値を含む。時間間隔Δｔ値が減少した場合追加帯域幅が利用可能であると判定される。追加帯域幅が利用可能であると判定された場合、より高いビットレートを有する新データ・ストリームがクライアントへの伝送用に選択される。ストリーミング・データのサーバも説明される。【選択図】図４
2008099276.tif 000002
【特許請求の範囲】
【請求項１】
クライアントにデータをストリームする方法で、
クライアントにより受信されるデータ・ストリームをコンピュータ・ネットワーク上で伝送するステップで、複数のデータ・ストリームから選択され、前記複数のデータ・ストリームの各々は異なったビットレートを有し、前記データ・ストリームは一連のデータ・パケットの形で伝送される、ステップと、
クライアントにより受信されるタイミング・パケットのペアを伝送するステップで、前記タイミング・パケットが第１パケットおよび第２パケットを含み、前記第２パケットが既知の遅延をもって第１パケットの後に伝送される、ステップと、
複数の報告パケットを受信するステップで、前記報告パケットが各々対応するタイミング・パケットのペアの内、前記第１パケットの受信時間および前記第２パケットの受信時間の間に経過した時間の長さを表すΔｔ値を含む、ステップと、
時間が経過するにつれ前記Δｔ値が減少した場合追加帯域幅が利用可能であることを判定するステップと、
前記追加帯域幅が利用可能であると判定された場合クライアントが受信する新データ・ストリームを選択するステップで、新データ・ストリームはデータ・ストリームより高いビットレートを有する、ステップとを含む方法。
【請求項２】
前記第１パケットおよび第２パケットは互いに５ミリ秒未満離れて伝送されるが、前記第１および第２パケットが共通のネットワーク・パケットに組み合わされる可能性が少ないよう時間的に充分に離されている、請求項１に記載される方法。
【請求項３】
前記第１パケットは前記データ・パケットの１つでストリーミング・メディアのデータを含み、前記ストリーミング・メディアは音声ストリームおよびビデオ・ストリームの内少なくとも１つを含む、請求項１に記載される方法。
【請求項４】
前記第２パケットはストリーミング・データのデータを含まない模造パケットである、請求項３に記載される方法。
【請求項５】
前記第２パケットは前記クライアントがタイミング・パケットの受信順序を確認できるよう前記第１パケットのシーケンス番号を含む、請求項３に記載される方法。
【請求項６】
さらに前記Δｔ値を垂直軸に、受信時間を水平軸にプロットするグラフに受信された前記複数のΔｔ値を線にプロットした場合最も良く適合した線の勾配を推定するステップを含む請求項１に記載される方法で、前記追加帯域幅が利用可能であることの判定ステップは線の勾配が負であることを判定するステップを含む方法。
【請求項７】
前記推定ステップは、線の勾配を判定するために最小二乗回帰計算を行なうステップを含む、請求項６に記載される方法。
【請求項８】
さらに、前記クライアントに未処理パケットの増加があるか判定するステップと、
前記クライアントに未処理パケットの増加があった場合、伝送されている現在のデータ・ストリームより低いビットレートを有するデータ・ストリームを選択するステップと、を含む、請求項１に記載される方法。
【請求項９】
前記クライアントに未処理パケットの増加があるかの判定ステップは、前記クライアントが受信したパケット数を前記サーバから伝送されたパケット数と比較するステップを含み、前記受信されたパケット数が報告パケットで前記サーバに報告される、請求項８に記載される方法。
【請求項１０】
より高いビットレートを有する前記新データ・ストリームは、前記追加帯域幅が利用可能であると判定され、前記クライアントの未処理パケット数が減少している場合にのみ選択される、請求項８に記載される方法。
【請求項１１】
前記方法の各ステップがコンピュータ・システムにより、機械読み取り可能な媒体に具現されるプログラム命令に応答して実施される、請求項１に記載される方法。
【請求項１２】
ストリーミング・データ用のサーバで、メディア・コンテンツを表す高ビットレートのデータ・ストリームを受信するように構成されるメディア・コーデックで、前記メディア・コーデックは少なくとも１つのより低いビットレートのデータ・ストリームを生成し、より低いビットレートのデータ・ストリームは各々メディア・コンテンツを表すメディア・コーデックと、
前記高ビットレートのデータ・ストリームおよび前記より低いビットレートのデータ・ストリーム各々をネットワーク・パケットにカプセル化するパケッタイザと、
前記データ・ストリームの現在の１つをクライアントに受信されるようネットワーク上で伝送するよう構成される伝送回路で、前記データ・ストリームの現在の１つは複数のネットワーク・パケットの形で伝送される、伝送回路と、
前記クライアントから通信を受信するよう構成される受信回路と、
前記クライアントに受信されるよう前記伝送回路にタイミング・パケットのペアを定期的に伝送させるよう構成されるコントローラで、タイミング・パケットのペアは各々第１パケットおよび第２パケットを含み、前記第２パケットは既知の遅延をもって前記第１パケットの後に伝送され、前記コントローラは前記受信回路と通信しており、前記コントローラは前記クライアントから各タイミング・パケットに応答して報告を受信するよう構成され、前記各報告はタイミング・パケットの前記ペアの内、前記第１パケットの受信および前記第２パケットの受信の間に経過した時間の長さを表すΔｔ値を含み、前記コントローラはさらに前記Δｔ値が減少した場合追加帯域幅が利用可能であることを判定し、追加帯域幅が利用可能であると判定された時点の前記データ・ストリームのうちの現在のデータ・ストリームより高いビットレートのデータ・ストリームをクライアントの受信用に前記伝送回路に伝送させるよう構成される、コントローラと、を含むサーバ。
【請求項１３】
前記第１パケットおよび第２パケットは５ミリ秒未満離れて伝送され、前記第１および第２パケットが共通のネットワーク・パケットに組み合わされる可能性が少ないよう時間的に充分に離されている、請求項１２に記載されるサーバ。
【請求項１４】
前記第１パケットは前記データ・パケットの１つで前記データ・ストリームのうちの現在のデータ・ストリームからのデータを含み、前記データ・ストリームは各々音声ストリームおよびビデオ・ストリームの内少なくとも１つを含む、請求項１２に記載されるサーバ。
【請求項１５】
前記第２パケットは前記データ・ストリームの１つからのデータを含まない模造パケットである、請求項１４に記載されるサーバ。
【請求項１６】
前記第２パケットは前記クライアントが前記タイミング・パケットのペアの受信順序を確認できるよう前記第１パケットのシーケンス番号を含む、請求項１４に記載されるサーバ。
【請求項１７】
前記コントローラはさらに、前記Δｔ値を垂直軸に、受信時間を水平軸にプロットするグラフに受信された複数の前記Δｔ値を線にプロットした場合最も良く適合した前記線の勾配を推定するよう構成され、前記線の勾配が負である場合追加帯域幅が利用可能であると判定される、請求項１２に記載されるサーバ。
【請求項１８】
前記コントローラは最小二乗回帰計算に基づき前記勾配を推定する、請求項１７に記載されるサーバ。
【請求項１９】
前記コントローラはさらに、前記クライアントに未処理パケットの増加があるか判定し、前記クライアントに未処理パケットの増加があった場合前記データ・ストリームのうちより低いビットレートを有するデータ・ストリームを伝送するよう構成される、請求項１２に記載されるサーバ。
【請求項２０】
前記コントローラは前記クライアントが受信したパケット数を前記サーバから伝送したパケット数と比較することにより前記クライアントに未処理パケットの増加があるか判定するよう構成され、受信された前記パケット数は報告パケットで前記サーバに報告される、請求項１９に記載されるサーバ。
【請求項２１】
前記コントローラは前記追加帯域幅が利用可能であると判定され、前記クライアントの未処理パケット数が減少している場合にのみ、前記データ・ストリームのうちより高いビットレートを有するデータ・ストリームを伝送する、請求項１９に記載されるサーバ。
【請求項２２】
クライアントに伝送されるストリーミング・データのビットレートを調節する方法で、方法は、
前記クライアントに受信されるようコンピュータ・ネットワーク上で複数のデータ・ストリームの最初の１つを伝送するステップで、前記複数のデータ・ストリームの各々は複数のデータ・パケットの形でマルチメディア信号を表すストリーミング・データを含み、前記複数のデータ・ストリームの各々は他のデータ・ストリームとは異なるビットレートを有するステップと、
前記データ・パケットのうち未処理のものをいくつかモニタするステップと、
前記未処理のデータ・パケットの数が増加した場合複数のデータ・ストリームの内前記最初の１つの伝送を停止し、前記複数のデータ・ストリームの内より低いビットレートのものを伝送するステップと、
追加帯域幅が利用可能か判定するステップと、
前記未処理のデータ・パケット数が減少し前記追加帯域幅が利用可能である場合、前記より低いビットレートのデータ・ストリームの伝送を停止し、前記データ・ストリームの内より高いビットレートのものの伝送を開始するステップと、を含む方法。
【請求項２３】
前記データ・パケットの未処理のものの数は前記クライアントから報告される処理されたデータ・パケット数を前記伝送されたデータ・パケット数と比較することによりモニタされる、請求項２２に記載される方法。
【請求項２４】
前記追加帯域幅は、タイミング・パケットのペアをクライアントに定期的に伝送するステップで、各タイミング・パケットは第１パケットおよび第２パケットを含み、前記第２パケットは既知の遅延をもって前記第１パケットの後の伝送される、ステップと、
前記クライアントから複数の報告パケットを受信するステップで、前記各報告パケットはタイミング・パケットの前記ペアの１つに対応し、前記クライアントによる前記第１パケットおよび前記第２パケットの受信の間の時間の前記長さを表すΔｔ値を含む、ステップと、
時間の経過につれ前記Δｔ値が減少する場合、追加帯域幅が利用可能であると判定するステップと、
により利用可能と判定される、請求項２３に記載される方法。
【請求項２５】
前記ストリーミング・データは複数のクライアントに伝送され、各クライアントは前記データ・ストリームの１つを受信する、請求項２２に記載される方法で、方法はさらに、
選択された時間間隔にわたりより低いビットレートのデータ・ストリームからより高いビットレートのデータ・ストリームに変更されるクライアントの数を制限すること、を含む方法。
【請求項２６】
さらに、ストリーミング・データのバーストが検出された場合現在のデータ・ストリームの伝送を停止し、より低いビットレートのデータ・ストリームを限定期間伝送することで、前記より低いビットレートのデータ・ストリームは前記現在のデータ・ストリームより低いビットレートを有すること、
を含む、請求項２２に記載される方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、離れた場所の２人以上の参加者間のコミュニケーションを促進するために用いられる会議システムに関する。
【背景技術】
【０００２】
会議システムは離れた場所の２人以上の参加者間のコミュニケーションを促進するために用いられる。ライブ・ビデオ、音声、および他のデータを各参加者と見、聞き、または別途協力するために交換するシステムが存在する。会議の一般的な用途にはミーティング／作業グループ、プレゼンテーション、およびトレーニング／教育が含まれる。現在、テレビ会議ソフトウェアのおかげで、安価なカメラとマイクロホンを有するパソコンを用いて他の会議参加者と接続することができる。ピアツーピア・テレビ会議ソフトウェア・アプリケーションは各参加者が別の参加者を見、聞き、別の参加者とやりとりすることを可能にし、別個安価に購入することができる。ソフトウェアや安価なカメラ／マイクロホン装置が利用できることに刺激され、テレビ会議はますます普及してきている。
【０００３】
ビデオ通信は動画の大量情報コンテンツに対応するために充分に高速なネットワークに依存している。音声およびビデオのデータ通信は参加者数およびデータ交換のサイズが増加するにつれより大きな帯域幅を要求する。圧縮技術やコンテンツ・サイズの制限を考慮に入れても、帯域幅の制限は複数当事者の会議において互いにやりとりできる参加者の数を非常に限定する。
【０００４】
１つの音声・ビデオ・ソースを多数の人間が見ることのできるビデオ・ストリーミング技術は既に存在する。これは１人の発表者が多数の受動的な視聴者に話すことができる「一対多数システム」（「one to many systems」）と呼ばれる会議システムをもたらした。一対多数会議において、「一」は典型的に話し手または発表者と呼ばれ、「多数」は出席する「聴衆」または視聴者である。一対多数会議は主として一方向のやりとりで、聴衆の全員が話し手を聴くことができ、動きを見ることができる必要がある（すなわち話し手のメディアはすべての参加者に伝送される）。
【０００５】
【特許文献１】米国特許出願公開第２００４０２４３８０５号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００６】
会議システムにおいては、他のある種のデータ・ストリーミング技術の用途とともに、できる限り質の高いデータ・ストリームを提供することが重要である。一般的により質の高いデータ・ストリームは元の信号により忠実である。例えば高画質のビデオ・データ・ストリームはビデオ・カメラから直接の元のフィードとほとんど区別できないビデオ画像を提供するが、低画質のビデオ・データ・ストリームは途切れもしくはぼやけて見えることがあり、または他の高率圧縮のアーティファクトを含むことがある。より質の高いデータ・ストリームはより高いデータ・スループットを必要としがちで、従ってしばしば［低ビットレート・データ・ストリーム］に対し「高ビットレート・データ・ストリーム」と呼ばれる。ストリーミング・クライアントはしばしばデータ・ストリームを受信するために利用できる帯域幅が限定されており、またストリーミング・クライアントは質の高いデータ・ストリームを復号化するのに必要な処理能力が限定されているかもしれないため、ストリーミング・クライアントに送信されるデータ・ストリームのビットレートが最適化され、利用できる帯域幅または処理能力を最大限に用い、使用される特定の接続および特定のハードウェアを通してエンド・ユーザに可能な限り最高の質のユーザ体験を提供することが重要である。
【０００７】
既存のストリーミング・サーバにおいて、ユーザは通常自己のシステムに対し適したビットレートを選択することを要求される。例えば、「ケーブル」、「ＤＳＬ」、および「ダイアル・アップ」から選ぶよう要求されるかもしれず、これらは各々ストリーミング・データの特定の質を表している。他のシステムでは、接続がテストされ、ユーザ向けにビットレートが自動的に選択される。しかしこれらのシステムは一旦ストリーミングが始まり帯域幅の条件または状況が変化するにつれ進行中にデータ・ストリームを高ビットレートから低ビットレートに、またはその逆に変更することができない。さらに、これらのシステムは一般的クライアントがデータ・ストリームを処理するための処理能力を考慮にいれていない。例えば、高ビットレートのビデオ・ストリームはユーザのモニタで復号化し表示するのに相当の処理能力を要するかもしれない。高ビットレート・ビデオをダウンロードするために利用できる帯域幅が充分にあってもユーザはリアルタイムでそれを視聴することはできない。
【０００８】
多数のストリーミング・クライアントの各ストリーミング・クライアントに伝送されるビットレートを最適化でき、利用可能な帯域幅の個々の変化とともに帯域幅の条件に反応できるリアルタイムのデータ・ストリーミング技術が必要とされる。
【課題を解決するための手段】
【０００９】
おおまかに言って本発明は大型テレビ会議用の複数レベルの渋滞制御を提供することによりこれらのニーズを満たす。
【００１０】
本発明はプロセス、装置、システム、デバイス、または方法を含み多数の形で実施できることが理解されよう。以下に本発明の創意工夫に満ちた実施形態が説明される。
【００１１】
一実施形態で、データをストリームする方法が提供される。方法において、タイミング・パケットのぺアが周期的にクライアントに伝送され、ペアの内第２パケットは既知の遅延後第１パケットの後に伝送される。クライアントから複数の報告が受信され、各報告はクライアントがタイミング・パケットのペアの内第１パケットを受信した後第２パケットを受信するまでの経過時間を表すΔｔ値を含む。Δｔ値が減少すると追加帯域幅が利用可能であると判定される。追加帯域幅が利用可能であると判定されると、より高いビットレートを有する新しいデータ・ストリームがクライアントへの伝送に選ばれる。
【００１２】
別の実施形態で、データをストリームするサーバが提供される。サーバは高ビットレートのデータ・ストリームを受信し、より低いビットレートのデータ・ストリームを少なくとも１つ生成するよう構成されたメディア・コーデックを含む。
【００１３】
また、高ビットレートのデータ・ストリームおよびより低いビットレートのデータ・ストリーム各々はメディア・コンテンツを表す。サーバはさらにパケッタイザと伝送回路を含む。
【００１４】
パケッタイザは高ビットレートのデータ・ストリームおよびより低いビットレートのデータ・ストリーム各々をネットワーク・パケットにカプセル化するよう構成される。伝送回路はネットワーク・パケットの形でデータ・ストリームの１つをクライアントに伝送するよう構成される。
【００１５】
また、サーバはさらに受信回路およびコントローラを含む。
【００１６】
受信回路はクライアントからの通信を受信するよう構成される。コントローラは伝送回路に周期的にタイミング・パケットのペアをクライアントに伝送させるよう構成される。各タイミング・パケットのペアは第１パケットおよび第２パケットを含み、第２パケットは既知の遅延後第１パケットの後に伝送される。
【００１７】
また、コントローラはさらに各タイミング・パケットのペアに応答してクライアントから報告を受信するよう構成され、各報告はクライアントが対応するタイミング・パケットのペアの内第１パケットを受信した後第２パケットを受信するまでの経過時間を表すΔｔ値を含む。
【００１８】
コントローラはさらにΔｔ値が減少すると追加帯域幅が利用可能であると判定し、追加帯域幅が利用可能であると判定された時点でクライアントが受信しているビットレートより高いビットレートのデータ・ストリームを伝送回路に伝送させるよう構成される。
【００１９】
さらに別の実施形態で、伝送されるストリーミング・データのビットレートを調節する方法が提供される。方法において、複数データ・ストリームの１つが複数のデータ・パケットの形でクライアントに伝送される。各データ・ストリームは異なったビットレートにおけるマルチメディア信号を表すストリーミング・データを含む。データ・パケットで未処理分の数が監視される。未処理データ・パケットの数が増加すると、データ・ストリームのビットレートが減少する。加えて、追加帯域幅が利用可能であるかの判定がなされる。未処理データ・パケットの数が減少して追加帯域幅が利用可能の場合、データ・ストリームのビットレートが増加する。
【００２０】
本発明の一態様である、クライアントにデータをストリームする方法は、クライアントにより受信されるデータ・ストリームをコンピュータ・ネットワーク上で伝送するステップで、複数のデータ・ストリームから選択され、複数のデータ・ストリームの各々は異なったビットレートを有し、データ・ストリームは一連のデータ・パケットの形で伝送される、ステップと、クライアントにより受信されるタイミング・パケットのペアを伝送するステップで、タイミング・パケットが第１パケットおよび第２パケットを含み、第２パケットが既知の遅延をもって第１パケットの後に伝送される、ステップと、複数の報告パケットを受信するステップで、報告パケットが各々対応するタイミング・パケットのペアの内、第１パケットの受信時間および第２パケットの受信時間の間に経過した時間の長さを表すΔｔ値を含む、ステップと、時間が経過するにつれΔｔ値が減少した場合追加帯域幅が利用可能であることを判定するステップと、追加帯域幅が利用可能であると判定された場合クライアントが受信する新データ・ストリームを選択するステップで、新データ・ストリームはデータ・ストリームより高いビットレートを有する、ステップとを含む。
【００２１】
また、第１パケットおよび第２パケットは互いに５ミリ秒未満離れて伝送されるが、第１および第２パケットが共通のネットワーク・パケットに組み合わされる可能性が少ないよう時間的に充分に離されているものでもよい。
【００２２】
また、第１パケットはデータ・パケットの１つでストリーミング・メディアのデータを含み、ストリーミング・メディアは音声ストリームおよびビデオ・ストリームの内少なくとも１つを含むものでもよい。
【００２３】
また、第２パケットはストリーミング・データのデータを含まない模造パケットであるものでもよい。
【００２４】
また、第２パケットはクライアントがタイミング・パケットの受信順序を確認できるよう第１パケットのシーケンス番号を含むものでもよい。
【００２５】
また、さらにΔｔ値を垂直軸に、受信時間を水平軸にプロットするグラフに受信された複数のΔｔ値を線にプロットした場合最も良く適合した線の勾配を推定するステップを含む請求項１に記載される方法で、追加帯域幅が利用可能であることの判定ステップは線の勾配が負であることを判定するステップを含むものでもよい。
【００２６】
また、推定ステップは、線の勾配を判定するために最小二乗回帰計算を行なうステップを含むものでもよい。
【００２７】
また、クライアントに未処理パケットの増加があるか判定するステップと、クライアントに未処理パケットの増加があった場合、伝送されている現在のデータ・ストリームより低いビットレートを有するデータ・ストリームを選択するステップと、を含むものでもよい。
【００２８】
また、クライアントに未処理パケットの増加があるかの判定ステップは、クライアントが受信したパケット数をサーバから伝送されたパケット数と比較するステップを含み、受信されたパケット数が報告パケットでサーバに報告されるものでもよい。
【００２９】
また、より高いビットレートを有する新データ・ストリームは、追加帯域幅が利用可能であると判定され、クライアントの未処理パケット数が減少している場合にのみ選択されるものでもよい。
【００３０】
また、方法の各ステップがコンピュータ・システムにより、機械読み取り可能な媒体に具現されるプログラム命令に応答して実施されるものでもよい。
【００３１】
本発明の一態様である、ストリーミング・データ用のサーバは、メディア・コンテンツを表す高ビットレートのデータ・ストリームを受信するように構成されるメディア・コーデックで、メディア・コーデックは少なくとも１つのより低いビットレートのデータ・ストリームを生成し、より低いビットレートのデータ・ストリームは各々メディア・コンテンツを表すメディア・コーデックと、高ビットレートのデータ・ストリームおよびより低いビットレートのデータ・ストリーム各々をネットワーク・パケットにカプセル化するパケッタイザと、データ・ストリームの現在の１つをクライアントに受信されるようネットワーク上で伝送するよう構成される伝送回路で、データ・ストリームの現在の１つは複数のネットワーク・パケットの形で伝送される、伝送回路と、クライアントから通信を受信するよう構成される受信回路と、クライアントに受信されるよう伝送回路にタイミング・パケットのペアを定期的に伝送させるよう構成されるコントローラで、タイミング・パケットのペアは各々第１パケットおよび第２パケットを含み、第２パケットは既知の遅延をもって第１パケットの後に伝送され、コントローラは受信回路と通信しており、コントローラはクライアントから各タイミング・パケットに応答して報告を受信するよう構成され、各報告はタイミング・パケットのペアの内、第１パケットの受信および第２パケットの受信の間に経過した時間の長さを表すΔｔ値を含み、コントローラはさらにΔｔ値が減少した場合追加帯域幅が利用可能であることを判定し、追加帯域幅が利用可能であると判定された時点のデータ・ストリームのうちの現在のデータ・ストリームより高いビットレートのデータ・ストリームをクライアントの受信用に伝送回路に伝送させるよう構成される、コントローラと、を含む。
【００３２】
また、第１パケットおよび第２パケットは５ミリ秒未満離れて伝送され、第１および第２パケットが共通のネットワーク・パケットに組み合わされる可能性が少ないよう時間的に充分に離されているものでもよい。
【００３３】
また、第１パケットはデータ・パケットの１つでデータ・ストリームのうちの現在のデータ・ストリームからのデータを含み、データ・ストリームは各々音声ストリームおよびビデオ・ストリームの内少なくとも１つを含むものでもよい。
【００３４】
また、第２パケットはデータ・ストリームの１つからのデータを含まない模造パケットであるものでもよい。また、第２パケットはクライアントがタイミング・パケットのペアの受信順序を確認できるよう第１パケットのシーケンス番号を含むものでもよい。
【００３５】
また、コントローラはさらに、Δｔ値を垂直軸に、受信時間を水平軸にプロットするグラフに受信された複数のΔｔ値を線にプロットした場合最も良く適合した線の勾配を推定するよう構成され、線の勾配が負である場合追加帯域幅が利用可能であると判定されるものでもよい。
【００３６】
また、コントローラは最小二乗回帰計算に基づき勾配を推定するものでもよい。
【００３７】
また、コントローラはさらに、クライアントに未処理パケットの増加があるか判定し、クライアントに未処理パケットの増加があった場合データ・ストリームのうちより低いビットレートを有するデータ・ストリームを伝送するよう構成されるものでもよい。
【００３８】
また、コントローラはクライアントが受信したパケット数をサーバから伝送したパケット数と比較することによりクライアントに未処理パケットの増加があるか判定するよう構成され、受信されたパケット数は報告パケットでサーバに報告されるものでもよい。
【００３９】
また、コントローラは追加帯域幅が利用可能であると判定され、クライアントの未処理パケット数が減少している場合にのみ、データ・ストリームのうちより高いビットレートを有するデータ・ストリームを伝送するものでもよい。
【００４０】
本発明の一態様である、クライアントに伝送されるストリーミング・データのビットレートを調節する方法は、クライアントに受信されるようコンピュータ・ネットワーク上で複数のデータ・ストリームの最初の１つを伝送するステップで、複数のデータ・ストリームの各々は複数のデータ・パケットの形でマルチメディア信号を表すストリーミング・データを含み、複数のデータ・ストリームの各々は他のデータ・ストリームとは異なるビットレートを有するステップと、データ・パケットのうち未処理のものをいくつかモニタするステップと、未処理のデータ・パケットの数が増加した場合複数のデータ・ストリームの内最初の１つの伝送を停止し、複数のデータ・ストリームの内より低いビットレートのものを伝送するステップと、追加帯域幅が利用可能か判定するステップと、未処理のデータ・パケット数が減少し追加帯域幅が利用可能である場合、より低いビットレートのデータ・ストリームの伝送を停止し、データ・ストリームの内より高いビットレートのものの伝送を開始するステップと、を含む。
【００４１】
また、データ・パケットの未処理のものの数はクライアントから報告される処理されたデータ・パケット数を伝送されたデータ・パケット数と比較することによりモニタされるものでもよい。
【００４２】
また、追加帯域幅は、タイミング・パケットのペアをクライアントに定期的に伝送するステップで、各タイミング・パケットは第１パケットおよび第２パケットを含み、第２パケットは既知の遅延をもって第１パケットの後の伝送される、ステップと、クライアントから複数の報告パケットを受信するステップで、各報告パケットはタイミング・パケットのペアの１つに対応し、クライアントによる第１パケットおよび第２パケットの受信の間の時間の長さを表すΔｔ値を含む、ステップと、時間の経過につれΔｔ値が減少する場合、追加帯域幅が利用可能であると判定するステップと、により利用可能と判定されるものでもよい。
【００４３】
また、ストリーミング・データは複数のクライアントに伝送され、各クライアントはデータ・ストリームの１つを受信する、請求項２２に記載される方法で、方法はさらに、選択された時間間隔にわたりより低いビットレートのデータ・ストリームからより高いビットレートのデータ・ストリームに変更されるクライアントの数を制限すること、を含むものでもよい。
【００４４】
また、ストリーミング・データのバーストが検出された場合現在のデータ・ストリームの伝送を停止し、より低いビットレートのデータ・ストリームを限定期間伝送することで、より低いビットレートのデータ・ストリームは現在のデータ・ストリームより低いビットレートを有すること、含むものでもよい。
【００４５】
本発明の利点は、発明の原理を例示する添付図面と併せて以下の詳細な説明から明らかになろう。
【発明を実施するための最良の形態】
【００４６】
本発明は添付図面と併せて以下の詳細な説明により容易に理解されよう。類似した符号は類似した構成要素を指定している。
【００４７】
以下の説明において、本発明の完全な理解を提供するために多数の具体的な詳細が提示される。しかし、当業者であれば、本発明はこれら具体的な詳細なしで実施できることを理解しよう。逆に、発明を不必要に分かりにくくしないよう周知のプロセス手順および実施の詳細は詳しく説明していない。
【００４８】
図１は複数の会議参加者１３０および複数のストリーミング・クライアント１５０を有する典型的な「少数対多数」（「few to many」）会議システムを示す。会議参加者１３０はパネル討論、または他のイベントに参加するために会議サーバ１１０にアクセスする。本明細書において会議参加者は共同作業者、話し手、または発表者である者を識別するために用いられる。会議参加者は自由に口を差し挟み、他の会議参加者とやりとりすることができる。一実施形態で、各会議参加者１３０はリアルタイムの高ビットレートのビデオおよび音声データ、および／あるいは画像、アプリケーション共有、文書、およびアノテーションなど他のマルチメディア・コンテンツを提供して討論に貢献でき、他の任意の会議参加者はこれらを受信することができる。各会議参加者は議長から許可をまず得る必要なく、会話に割り込んで寄与することができる。このように、会議参加者とは他の１人以上の会議参加者と自由に会話ができる者である。
【００４９】
ストリーミング・クライアント１５０はデータ・ストリーミング・サーバ（以降、ＤＳＳという）１２０にアクセスして音声、ビデオ、ならびに画像、文書、およびアノテーションなど他のマルチメディア・コンテンツをリアルタイムで受信する。複数のビットレートで符号化できる限りＤＳＳ１２０を用いて任意のメディアを伝送することができる。一実施形態で、ＤＳＳ１２０は音声、ビデオ、および他のマルチメディア・コンテンツをローカル・エリア・ネットワーク（以降、ＬＡＮという）接続１４６経由で直接会議サーバ１１０から受信することができる。ストリーミング・クライアント１５０は一般的にすべての会議参加者１３０からの音声ストリームで構成される複合音声ストリームを受信することができる。しかし一実施形態で、各ストリーミング・クライアント１５０は会議参加者の１人からの高ビデオ・ストリームを１つ、または複数のビデオ・ストリームから形成される合成ビデオ・ストリームしか視聴することができず、一般的にどの会議参加者を視聴するか選択することができない。さらに、ストリーミング・クライアントは逆方向パス１５７でＤＳＳ１２０に信号を送り質問をする希望を示すことにより質問をする機会を与えられ、許可されるとその人間の質問を符号化した低ビットレートのビデオおよび／あるいは音声信号がストリーミング・クライアントからＤＳＳ１２０に送信される。
【００５０】
どのビデオ・フィードをストリーミング・クライアント１５０に送信するか選択し、ストリーミング・クライアント１５０からの質問またはフィードバックを許可するために、本明細書でコントローラ・クライアント１４０と呼ばれる特別の会議参加者に、制御パネルが提供される。コントローラ・クライアント１４０は会議サーバ１１０およびＤＳＳ１２０双方に接続されている。
【００５１】
コントローラ・クライアント１４０は制御パネルを用いて会議参加者１３０からのどのビデオ・ストリームをストリーミング・クライアント１５０に送信するかを指定し、会議サーバ１１０に通信することができる。加えて、コントローラ・クライアント１４０はＤＳＳ１２０に接続してストリーミング・クライアント１５０とやりとりする。このようなやりとりは例えばストリーミング・クライアント１５０により音声およびビデオ信号が受信されていることを確認し、質問がなされる際、ストリーミング・クライアント１５０からどの音声および／あるいはビデオ・フィードを選択するかなどの設定の支援が含まれる。
【００５２】
チャットなど、他のやりとりも可能である。チャットとは参加者同士でインスタント・テキスト・メッセージを送受信することである。会議システム１００のさらなる詳細は関連米国特許出願番号１１／４５７２８５号明細書で提供され、引用により本明細書に組み入れられる。
【００５３】
図２はバス１６８で電子通信するＣＰＵ１６２、出入力（以降、Ｉ／Ｏという）ポート１６４、およびメモリ１６６を有する典型的なコンピュータ１６０を示す。コンピュータ１６０、ＤＳＳ１２０、ストリーミング・クライアント１５０、または会議システム１００に接続される他のコンピュータ・システムとして用いることのできる汎用コンピュータ・システムである。メモリ１６６はオペレーション・システム１７０およびサーバまたはクライアントのアプリケーション１７２を含む。
【００５４】
コンピュータ１６０がサーバの場合、アプリケーション１７２はサーバ・ソフトウェアを含む。コンピュータ１６０がクライアントの場合、アプリケーション１７２はクライアント・ソフトウェアを含む。コンピュータ１６０がサーバとクライアント双方の役割を果たすことも可能であり、この場合、アプリケーション１７２はサーバ・ソフトウェアとともにクライアント・ソフトウェアを含むことになる。
【００５５】
本明細書において、「サーバ」の用語は主にサーバの機能を果たすコンピュータ・システムを指し、「クライアント」の用語は主にクライアントの機能を果たすコンピュータ・システムを指すが、実行されるソフトウェアによって各々いずれの機能も果たすことができ、または同時に双方の機能を果たすこともできることが理解されよう。各サーバは複数の機能を果たすことができる。
【００５６】
Ｉ／Ｏポート１６４はユーザ・インタフェース１７４およびネットワーク・インタフェース１７６を含む外付け装置に接続することができる。ユーザ・インタフェース１７４はキーボード、ビデオ画面、およびマウスなどポインティング・デバイスなど、ユーザ・インタフェース装置を含むことができる。ネットワーク・インタフェース１７６は外部ネットワーク経由で通信するために１つ以上のネットワーク・インタフェース・カード（ＮＩＣ）を含むことができる。
【００５７】
図３は図１の会議システム１００の別の図で、ＤＳＳ１２０の運用をより良く説明している。
【００５８】
何名かの会議参加者１３０（１名のみ図示）各々は音声／ビデオ・モニタとしてのビデオ・ディスプレー１３４を用いてストリーミング音声およびビデオ・データを発信する。会議サーバ１１０はこのストリーミング音声およびビデオ・データをネットワーク１５５経由で受信し、ネットワークはインターネットなどの広域ネットワークであり得る。
【００５９】
各会議参加者からの音声信号は混合され、他の会議参加者１３０とともにコントローラ・クライアント１４０（図１参照）により選択されたプリファレンスに従ってＤＳＳ１２０に再伝送される。加えて、各会議参加者からのビデオ信号は選択的に会議参加者１３０に再伝送され、ビデオ・ディスプレー１３４で表示することができる。
【００６０】
あるいは、会議サーバ１１０が受信した複数のビデオ信号を合成し複数のビデオ信号を組み入れた合成ビデオ信号を生成することもでき、各々のビデオ信号は合成ビデオ画像の生成に対応画像のサイズが縮小されている。
【００６１】
例えば、合成信号は各ビデオ・ストリームのビデオ画像を合成ビデオ画像の別個のクワドラントに配置することにより４つのビデオ・ストリームを組み合わせることができる。
【００６２】
一実施形態で、各会議参加者１３０は合成信号にどのビデオ信号を含めるか選択し、ビデオのいくつかが他より大きくなるようにレイアウトを操作することができる。
【００６３】
このように、会議サーバ１１０は各ビデオ信号を受信することができ、会議サーバ１１０は各参加者が選択したプリファレンスにより各受信者向けに新しい合成信号を復号化、合成、および再符号化することができる。
【００６４】
ＤＳＳ１２０に対し、コントローラ・クライアント１４０（図１）は合成信号にどのビデオ信号を含めるか選択することができる。ＤＳＳ１２０に伝送される混合音声および合成ビデオ信号はＬＡＮ接続１４６経由で伝送することができる。
【００６５】
ＤＳＳ１２０は混合音声および合成ビデオ信号を会議サーバ１１０から受信する。音声およびビデオ信号のフォーマットは具体的な実施により異なり得る。
【００６６】
例えば、音声およびビデオ信号は圧縮フォーマットまたは非圧縮フォーマットとして提供され得る。
【００６７】
一実施形態で、音声およびビデオ信号は高品質、高ビットレートの圧縮信号としてＬＡＮ接続１４６経由でＤＳＳ１２０に伝送される。高品質圧縮音声およびビデオ信号は受信された形で高品質、高ビットレート信号を受信し、処理できる１つ以上のストリーミング・クライアント１５０に直接再伝送されることができる。
【００６８】
これらの受信者向けに音声およびビデオ信号は音声およびビデオ・コーデック１２１、音声・コーデック１２２経由でパケッタイザ１２３，１２４および伝送回路１２５に送られる。
【００６９】
ビデオ・コーデック１２１、音声・コーデック１２２、パケッタイザ１２３，１２４、および伝送回路１２５は各々ＤＳＳ１２０のハードウェアまたはソフトウェア・コンポーネントとして実施され得ることが特記される。
【００７０】
一実施形態で、コーデック、パケッタイザ、ならびに伝送および受信回路はすべてハードウェア・コンポーネントとして実施され、ソフトウェア・サーバ・アプリケーションの指示で動作する。
【００７１】
ストリーミング・クライアント１５０のいくつかは信号に対応するネットワーク帯域幅を充分に有しないか、または高品質信号をリアルタイムで復号化するのに充分なプロセッサ能力を有しないため高品質、高ビットレートの音声およびビデオ信号を受信できないかもしれない。
【００７２】
「リアルタイム」とはビデオの具体的なフレームを表すデータの受信および、ビデオ・フレームの実際の表示間の遅延時間を増加させることなく、入信データが受信と同じ速さで処理されることを意味する。
【００７３】
高品質、高ビットレートの音声およびビデオ信号を受信する能力のないストリーミング・クライアント向けに、音声およびビデオ・コーデック１２１、音声・コーデック１２２は各々ビデオ信号および音声信号を復号化し、信号をより高圧縮、低品質、低ビットレート信号に再符号化する。
【００７４】
例えば４０以上など多数のストリーミング・クライアントが存在し、各々異なった利用可能な帯域幅および処理能力を有している可能性があるので、各ストリーミング・クライアント用にコンテンツの質を最適化するためにビットレートを微細に調整することはできないかもしれない。従って、ＤＳＳ１２０は所定数のビットレートで音声およびビデオ・データを伝送することができる。
【００７５】
一実施形態で、ＤＳＳ１２０は会議サーバ１１０から受信した高品質、高ビットレートの音声およびビデオ信号を再伝送し、高品質、高ビットレート信号を受信できない１つ以上のストリーミング・クライアント１５０向けに２つのより低品質、低ビットレート信号を発信する。
【００７６】
例えば、高ビットレート信号の半分のビットレートの第２データ・ストリームがビデオ・コーデック１２１、音声・コーデック１２２により生成され、高ビットレート信号の４分の１のビットレートの第３データ・ストリームがビデオ・コーデック１２１、音声・コーデック１２２により生成され得る。低減されたビットレートのデータ・ストリームはより高圧縮アルゴリズムを用い、および／あるいは音声チャンネルを落とすか組み合わせ、および／あるいはフレームを落としてビデオのリフレッシュ率を削減することにより生成できる。
【００７７】
受信回路１２８はさらに詳細に後述されるように、ストリーミング・クライアント１５０から連絡を受信してこの連絡をＤＳＳ１２０のハードウェアまたはソフトウェア・コンポーネントであり得るコントローラ１２６に渡し、各ストリーミング・クライアント１５０についてどのレベルのビットレートを受信できるか特定する。
【００７８】
本明細書においてＤＳＳ１２０はテレビ会議システムの関係で説明されているが、他の形で実施できることが理解されよう。例えば、インターネット上でスポーツ・イベントをリアルタイムで生中継するなどである。
【００７９】
図４は特定のストリーミング・クライアント１５０（図１、図３）の１つ向けに受信可能な帯域幅を特定する典型的な手順を描いたフローチャート２００を示す。フローチャートは開始ブロック２０２で示すように開始され、操作２０４に進み、ここで１つ以上の音声情報および／あるいはビデオ情報を含み得るデータ・ストリームが高ビットレートで開始される。
【００８０】
操作２０６において、ＤＳＳ１２０は図５〜図７に関連してより詳細に後述される方法で未処理のデータ・パケットの数を監視する。未処理のデータ・パケットはＤＳＳ１２０からストリーミング・クライアント１５０に伝送中であるか、またはストリーミング・クライアント１５０に受信されているがまだ確認されユーザに提示されるなど処理されていないパケットである。
【００８１】
操作２０８において、ＤＳＳ１２０は未処理のパケット数が増加したか判定する。未処理データ・パケット数が図５〜図７に関連して後述されるアルゴリズムに従って増加した場合、手順は操作２１０に進み、より低いビットレートのデータ・ストリームがストリーミング・クライアントに送信される。
【００８２】
より低いビットレートのデータ・ストリームを選択すると終了ブロック２２２で示されるように手順は終了する。
【００８３】
この手順はデータ・ストリームの過程において各ストリーミング・クライアントに対し繰り返し実施できることが特記される。
【００８４】
操作２０８において、未処理のパケット数が増加していない場合、手順は操作２１２に流れ、未処理パケットの数が減少したか判定する。
【００８５】
未処理パケットの数が図５〜図７に関連して後述されるアルゴリズムに従って減少した場合、手順は操作２１４に流れる。
【００８６】
未処理のパケット数が減少しなかった場合、すなわち実質的に同じであった場合、手順は操作２１６に流れる。
【００８７】
操作２１４において、ＤＳＳ１２０はサーバからストリーミング・クライアントへの接続に相当の利用可能な帯域幅があるか判定する。相当の利用可能な帯域幅があるかの判定は図８および図９に関連して後述されるように実施することができる。
【００８８】
利用可能な帯域幅がある場合、手順は操作２１８に流れ、クライアントへの伝送に増加したビットレートのデータ・ストリームが選択される。クライアントへの伝送に増加されたビットレートのデータ・ストリームが選択された後、手順は終了ブロック２２２に示されるように終了する。
【００８９】
操作２１６は利用可能な帯域幅が不十分であると操作２１４で判定された場合、または未処理パケットの数が減少していないと操作２１２で判定された場合に実施される。
【００９０】
操作２１６において、ストリーミング・クライアントに送信された現行のデータ・ストリームが維持される。後述されるように、操作２２０においてＤＳＳ１２０の動作が選択された、または所定の期間安定している場合状況により１つ以上のストリーミング・クライアントがランダムに選択されビットレートが増加される。
【００９１】
手順は次に終了ブロック２２２に示されるように終了する。
【００９２】
図５はＤＳＳ１２０（図１、図３）により伝送されストリーミング・クライアント１５０により未処理のままのパケット数が増加したか、または減少したか判定する手順を図示するフローチャート３００を示す。
【００９３】
この判定は現在移動中で未処理の伝送制御プロトコル（ＴＣＰ）ビデオ・パケット数の推定に基づく。
【００９４】
操作３０２において、コントローラ１２６（図３）は所定間隔にわたり伝送回路１２５により伝送されたビデオ・データのＴＣＰパケット数と受信機により受信されたビデオ・データのＴＣＰパケット数との差ＤＩＦＦ値を判定する。
【００９５】
受信機により受信されるストリーミング・マルチメディア・データのＴＣＰパケット数は受信機から、好ましくは定期的に受信機により送信され受信回路１２８により受信されるリアルタイム伝送制御プロトコル（ＲＴＣＰ）受信機報告パケットとして、得られる。
【００９６】
会議システム１００により伝送されるビデオ・データのＴＣＰパケット数は会議システムから得られる。
【００９７】
好ましい実施形態で、ＲＴＣＰ報告間隔は２秒で、パケット数はたとえば現行のテレビ会議セッションの開始など初期化イベントにはじまり数えられる。
【００９８】
図６はＤＳＳ１２０およびストリーミング・クライアント１５０間の典型的なトランザクションを示す。
【００９９】
ＤＳＳ１２０はビデオ・データなどのストリーミング・データを含むデータ・パケット４０４を連続的にストリーミング・クライアント１５０に伝送する。
【０１００】
定期的、例えば２秒毎、にストリーミング・クライアント１５０は報告パケット４０２をＤＳＳ１２０に伝送し返す。各報告パケットは受信されたデータ・パケット４０４の数を示す。
【０１０１】
ＤＳＳ１２０は受信されたデータ・パケット数Ｒを送信されたデータ・パケット数Ｓから差し引き差のＤＩＦＦ値が得られる。
【０１０２】
ネットワーク渋滞期間中、データ・パケットの受信および処理の遅延が増加するためＤＩＦＦ値がより大きくなる。
【０１０３】
図６は実際のテスト・データを提供しているのではなく、例示の目的からのみ説明されることが特記される。
【０１０４】
実際の実施において、２秒間隔毎のストリーミング・データのデータ・パケット数は平均約３０パケットであり得る。
【０１０５】
図５に戻り、操作３０４においてコントローラ１２６（図３）は伝送され、ネットワーク１５５上で移動中のビデオ・データのパケットの数Ｄ値を推定する。
【０１０６】
推定値であるＤ値はこれまでの５０のＤＩＦＦ値の中央値として計算されることが好ましいが、異なったＤＩＦＦ値の数字を用いることができ、中央値の代わりに平均値、最頻値、またはＤＩＦＦ値の他の関数を用いることができる。
【０１０７】
初期化の際はＤ値を計算するために利用できるＤＩＦＦ値の数が不十分である。
【０１０８】
一実施形態で、ＤＩＦＦ値が７つ計算されるまで最初のＤＩＦＦ値が使用される。その後、５０のＤＩＦＦ値が計算されるまですべてのＤＩＦＦ値の中央値が使用され、その後は上述のように最新５０のＤＩＦＦ値のスライド式枠が使用される。
【０１０９】
ネットワーク１５５（図３）が遅い場合、最初のいくつかのＤ値の推定値は大き過ぎるかもしれない。例えば、初期のビデオ・ビットレートはネットワーク１５５の平均ビットレートよりはるかに大きいかもしれない。従って、一実施形態で、初期のビデオ・ビットレートは会議システム１００により伝送されるビデオ・データの平均パケットのサイズＤＳに基づき最初は制限される。
【０１１０】
一実施形態で、平均のパケット・サイズがＫビットを越える場合、ビットレートはＤＳ＜ＫになるまでＫ／ＤＳ分減らされ、ここでＫ＝４０，０００である。もちろんＫに他の値を用いることもできる。
【０１１１】
フローチャート３００に図示される手順はＤ値が安定していることで益を得る。従って好ましい実施形態で、Ｄ値の新しい値が計算されると、その前のＤ値と比較される。新しいＤ値が前のＤ値を囲む推定窓内にある場合、新しいＤ値は捨てられ、Ｄ値の前の値が用いられる。
【０１１２】
一実施形態で、推定窓はＤＩＦＦ値の±１標準偏差である。この実施形態で、ＤＩＦＦ値の標準偏差はその前の５０のＤＩＦＦ値の中央絶対偏差として演算されるが、他の演算方法を用いることもできる。
【０１１３】
操作３０６において、移動中のビデオ・データのパケットの標準偏差が計算される。
【０１１４】
一実施形態で、標準偏差ＳＤｅｖは前の５０のＤＩＦＦ値の中央絶対偏差として演算されるが、他の演算方法を用いることもできる。初期化の際はＤ値を計算するために利用できるＤＩＦＦ値の数が不十分である。この場合、ＤＩＦＦ値のサンプルが７つ受信されるまで標準偏差ＳｄｅｖはＤＩＦＦ値の最大値および最小値の平均として演算されるが、他の演算方法を用いることもできる。その後、標準偏差ＳＤｅｖは上述のように演算することができる。
【０１１５】
ＤＩＦＦ値およびＤ値に基づき複数の閾値が判定される。さらに各閾値に対しカウンタＩが維持される。
【０１１６】
一実施形態で、４つの閾値が用いられ、カウンタＩ１，Ｉ２，Ｉ３，Ｉ４が維持される。加えて、ビデオのビットレート調節がなされない受信機報告の数を数えるためにカウンタＩ５を用いることができる。
【０１１７】
操作３０８において、ＤＩＦＦ値がＤ値およびＳＤｅｖの２倍の合計を越えるか判定される。ＤＩＦＦ値がＤ＋２Ｓｄｅｖを越える場合、手順は操作３１０に流れ、コントローラ１２６はカウンタＩ１を増分し、手順は操作３１２に流れる。
【０１１８】
操作３１２において、Ｉ１＝３であるか判定される。この場合３つの連続受信機報告においてＤＩＦＦ＞Ｄ＋２Ｓｄｅｖであり、手順は操作３１４に流れ、コントローラ１２６は未処理のパケット数が増加したことを特定する。この情報は図４におけるフローチャート２００の操作２０８の結果を判定するために用いられる。ＤＩＦＦ＞Ｄ＋２Ｓｄｅｖの場合、手順は操作３１４に流れ、そうでない場合手順は操作３２２に飛ぶ。
【０１１９】
操作３１４において、手順は一定期間一時停止して図４のフローチャート２００に従ってビットレートになされた変更が新データに反映されるようにする。
【０１２０】
一実施形態で、一時停止は所定数のＲＴＣＰ報告パケット、例えば２つのＲＴＣＰ報告、を飛ばすことにより実施される。
【０１２１】
次に操作３１６において、カウンタＩ１，Ｉ２，Ｉ３，Ｉ４，Ｉ５がすべてリセットされる。手順は次に上述の操作３０２に再度流れる。
【０１２２】
操作３０８においてＤＩＦＦ≦Ｄ＋２ＳＤｅｖの場合、手順は操作３２０に流れ、カウンタＩ１がＤＩＦＦ＞Ｄ＋２ＳＤｅｖの場合の連続ＲＴＣＰ受信機報告のみを数えることを保証するためにカウンタＩ１はゼロにリセットされる。手順は次に操作３２２に流れる。
【０１２３】
操作３２２において、ＤＩＦＦ値がＤ値および標準偏差ＳＤｅｖの値の合計を越えるか判定される。ＤＩＦＦ＞Ｄ＋Ｓｄｅｖの場合、手順は操作３２４に流れ、コントローラ１２６はカウンタＩ２を増分する。手順は次に操作３２６に流れ、Ｉ２＝５であるか判定される。Ｉ２＝５の場合、５つの連続ＲＴＣＰ受信機報告においてＤＩＦＦ＞Ｄ＋Ｓｄｅｖであり、手順は上述のように操作３１４に流れる。Ｉ２＜＞５の場合、手順は操作３３０に飛ぶ。
【０１２４】
操作３２２においてＤＩＦＦ≦Ｄ＋Ｓｄｅｖの場合、手順は操作３２８に流れ、カウンタＩ２がＤＩＦＦ＞Ｄ＋Ｓｄｅｖの場合の連続ＲＴＣＰ受信機報告のみを数えることを保証するためにカウンタＩ２はゼロにリセットされる。手順は次に操作３３０に流れる。
【０１２５】
操作３３０において、ＤＩＦＦ値がＤ値を越えるか判定される。ＤＩＦＦ＞Ｄの場合、手順は操作３３２に流れ、コントローラ１２６はカウンタＩ３を増分する。手順は次に操作３３４に流れ、Ｉ３＝９であるか判定される。Ｉ３＝９の場合、９つの連続ＲＴＣＰ受信機報告においてＤＩＦＦ＞Ｄであり、手順は上述のように操作３１４に流れる。Ｉ３＜＞９の場合、手順は操作３３８に飛ぶ。
【０１２６】
操作３３０においてＤＩＦＦ≦Ｄの場合、手順は操作３３６に流れ、カウンタＩ３がＤＩＦＦ＞Ｄの場合の連続ＲＴＣＰ受信機報告のみを数えることを保証するためにカウンタＩ３はゼロにリセットされる。手順は操作３３８に流れる。
【０１２７】
操作３３８において、ＤＩＦＦ値がＤ値未満であるか判定する。ＤＩＦＦ＜Ｄの場合、手順は操作３４０に流れ、コントローラ１２６はカウンタＩ４に増分する。手順は次に操作３４２に流れ、６つの連続ＲＴＣＰ受信機報告においてＤＩＦＦ＜Ｄであることを意味するＩ４＝６であるか判定される。Ｉ４＝６の場合、６つの連続ＲＴＣＰ受信機報告でＤＩＦＦ＜Ｄであり、手順は操作３４４に流れ未処理パケットの数が減少したことを示す。操作３４２においてＩ４＜＞６の場合、手順は操作３４８に飛ぶ。
【０１２８】
操作３４４において、未処理パケット数の減少が示されたことはフローチャート２００（図４）で用いられ、操作２１２の結果を判定する。操作３４４から手順は操作３１６に流れ、上述のように２つのＲＴＣＰ報告を飛ばしカウンタをリセットする。
【０１２９】
操作３３８においてＤＩＦＦ≧Ｄの場合手順は操作３４６に流れ、カウンタＩ４がＤＩＦＦ＜Ｄの場合の連続ＲＴＣＰ受信機報告のみ数えることを保証するためにカウンタＩ４はゼロにリセットされる。手順は次に操作３４８に流れる。
【０１３０】
操作３４８においてカウンタＩ５が増分される。この状態で未処理のパケット数は著しく増加もせず、減少もしていない。例えば、ＤＩＦＦ値はＤ値未満からＤ値を越えて変動しているかもしれず、全般的に安定した動作を示している。ビットレートが不必要に低い値で安定化しないことを保証するために、カウンタＩ５を用いて未処理のパケット数がカウンタ１６の連続ＤＩＦＦ値に対し（すなわちＪ個のＲＴＣＰ受信機報告パケットに対し）安定しているかを判定する。操作３５０において、Ｉ５＝１６であるか判定される。Ｉ５＝１６の場合、手順は上述の操作３４４に流れる。そうでない場合、手順は操作３０２に戻る。カウンタＩ１〜Ｉ５各々の他の閾値を用いることが特記される。
【０１３１】
図７は上述のフローチャート３００の典型的な運用を図示する典型的なグラフ４２０を示す。
【０１３２】
グラフ４２０は水平軸にプロットされる時間に対して変化するＤ値を垂直軸にプロットしたものを示す。時間ｔ0において、手順はＤ値の初期値で初期化される。新しいＤ値４２２はその前の５０の値のスライド式枠に基づき計算される。しかし、新しいＤ値４２２がＤ値から標準偏差４２４分を越えるまで新しいＤ値４２２は捨てられる。
【０１３３】
時間ｔ1において、新しいＤ値４２２はＤ値から標準偏差４２４分を越え、Ｄ値は新しい値に飛ぶ。その間、ＤＩＦＦ値４２６は継続的に計算されＤ値と比較される。３つの連続パケットにおいてＤＩＦＦ値４２６が２標準偏差（２σ）４２８に相当する値よりＤ値を越えると未処理パケット数の増加が特定される。
【０１３４】
図５のフローチャート３００を参照すると、操作３０８，３１０，３１２，３１４で定義される経路がたどられる。図４を参照すると、操作２０８において未処理パケット数が増加すると操作２１０においてデータ・ストリームのビットレートの減少につながる。
【０１３５】
図７に戻り、時間ｔ2においてＤＩＦＦ値４２６は３サイクルを越えて、２標準偏差分（２σ）に相当するＤ値を越えており、ビットレートの減少をもたらす。図５のフローチャート３００で図示される手順は時間ｔ2において短時間停止し、時間ｔ3において新しいＤ値で再開する。図７で表されるデータは実際のテスト・データを反映しているのではなく、例示の目的から説明されているだけであることが特記される。
【０１３６】
このアルゴリズムの一利点はストリーミング・クライアントの処理能力を考慮に入れることである。ストリーミング・クライアントが遅いパソコンを使用している場合、まだ流れているパケット数が増加し、それに対応してビットレートは減少することになる。
【０１３７】
前述のとおり、ＤＳＳ１２０（図１、図３）は多数のストリーミング・クライアントにデータをストリームする必要があるかもしれず、それ故、プロセッサおよび帯域幅の制限から、各ストリーミング・クライアントのデータを受信し処理する能力により各ストリーミング・クライアントを複数のカテゴリーの１つに分類する。
【０１３８】
フローチャート２００（図４）はフローチャート３００（図５）のプロセスを利用してストリーミング・クライアントに供給されるビットレートを次に低いカテゴリーに減らす必要があるようなネットワーク渋滞を特定する。
【０１３９】
ビットレートを増加することは未処理のパケット数が減少するだけではなく、ビットレートの増加に対応できる利用可能な帯域幅が充分にあることを保証する必要がある。すべてのストリーミング・クライアント１５０がストリーミング・データを受信し処理する能力に応じて例えば３カテゴリーなど、確定したカテゴリー数に分類されなければならないためＤＳＳ１２０は、会議サーバ１１０から会議参加者１３０（図１、図３）にメディアをストリームすることに向けられた関連米国特許出願番号１１／０５１６７４号明細書で説明されるように、各ストリーミング・クライアントに対し個別的に増分量で徐々にビットレートを増加することはできない。
【０１４０】
従って一実施形態で、特定のチャンネルに次のより高いビットレートのデータストリームに対応するために利用可能な帯域幅が充分にあるか特定するメカニズムが提供される。
【０１４１】
図８はフレーム間パケット・タイミングを用いたネットワーク帯域幅の相対的計量を測定する手順を図示するフローチャート４５０を示す。
【０１４２】
手順は開始ブロック４５２で示すように始まり、操作４５４に流れ模造のビデオ・パケットが作成される。本明細書に説明される測定手法は所定または既知の時間間隔を間に置いて続けて伝送される２つの類似サイズのパケットを用いる。
【０１４３】
一実施形態で、所定時間間隔は５ミリ秒であることができる。あいにく、データ・ストリームにおいて必ずしも適切なサイズのパケットが複数提供されない。例えば、データ・ストリームがビデオ・データを表す場合、ビデオに動きが少なく各フレームに対し１パケットのみ送信されるかもしれない。ある程度の動きがある場合でも、送信されるビデオ・パケットはしばしば小さく、１つの組み合わされたネットワーク・パケットとしてネットワークを通過する。
【０１４４】
これを解決するために、模造のビデオ・パケットがストリームに注入される。模造パケットは先行ビデオ・パケットと同じサイズで、先行ビデオ・パケットと組み合わさらないようやや遅延される。模造パケットはさらに受信の順が確認できるよう、例えばビデオ・パケットなど、先行データ・パケットのシーケンス番号を含む。従って操作４５６において、タイミング・パケットのペアが伝送される。
【０１４５】
一実施形態で、タイミング・パケットのペアは適切なサイズとして選ばれたビデオ・パケットの１つと模造ビデオ・パケットを含む。他の実施形態で、タイミング・パケットは適切なサイズでネットワークを通して伝送される際単一のネットワーク・パケットに組み合わされないよう時間的に間隔が開いている限り、２つの模造パケットまたは２つのビデオ・パケットを含むことができる。
【０１４６】
図９はＤＳＳ１２０およびストリーミング・クライアント１５０間の典型的なトランザクションを示す。
【０１４７】
この例で、２ペアのタイミング・パケット４８２Ａ，４８２ＢがＤＳＳ１２０からストリーミング・クライアント１５０に伝送される。タイミング・パケットの各ペアはビデオ・データを含むビデオ・パケット４８６および操作４５４において説明されたように生成された模造パケット４８８を含む。
【０１４８】
ストリーミング・クライアント１５０がタイミング・パケットを受信すると、タイミング・パケットの各ペアの第１パケットが受信された時間からタイミング・パケットのペアの第２パケットが受信された時間までに経過した時間間隔Δｔを計算する。このように、受信されたタイミング・パケットの各ペアに対し報告４８４Ａ，４８４Ｂがストリーミング・クライアントから返信され、報告は時間間隔Δｔを表す値を含む。
【０１４９】
順序が逆に受信されたタイミング・パケットを認識するために模造タイミング・パケットは先行ビデオ・パケットのシーケンス番号がマークされて含まれる。ストリーミング・クライアント１５０により受信された先行パケットが同じシーケンス番号を有しない場合、パケットは正しい順序になく時間間隔Δｔ値は計算されない。一実施形態で、順序が逆に受信されたことを示すエラー・パケットがＤＳＳ１２０に返送される。
【０１５０】
図８に戻り、ＤＳＳ１２０が操作４５６においてタイミング・パケットを伝送した後、操作４５８においてタイミング報告がストリーミング・クライアントから受信される。
【０１５１】
次に、操作４６０において、最小二乗回帰計算が受信された時間間隔Δｔ値に対し実施され、時間間隔Δｔ値に最も良く適合する線の勾配が特定される。勾配は時間間隔Δｔ値が垂直軸に、受信時間を水平軸にプロットされるグラフにプロットされる線に対し推定される。実際のプロットが必ずしも作成されるのではないことが特記される。
【０１５２】
最も良く適合した線の勾配は入手できたデータおよび既知の最小二乗回帰計算を用いて抽象的に計算される。最も良く適合した線の勾配が正である場合、時間間隔Δｔ値が全体的に増加しており、ネットワークの帯域幅が限定されていることを意味する。最も良く適合した線の勾配が負である場合、時間間隔Δｔ値が全体的に減少しており、ネットワークの帯域幅が増加していることを意味する。
【０１５３】
一実施形態で、先行する１０秒で集められた時間間隔Δｔ値が最小二乗回帰に用いられ勾配が特定される。一旦勾配が計算されると手順は操作４６２に流れる。
【０１５４】
操作４６２において、最も良く適合した線の勾配が負であるか判定される。勾配が負の場合、手順は操作４６４に流れ、追加帯域幅が利用可能であることが判定される。この判定は図４のフローチャート２００で図示される手順の操作２１４で用いられる。
【０１５５】
操作４６２において勾配が、例えば正または平坦であるなど、負でないと判定された場合、手順は操作４６６に流れ追加帯域幅が利用可能でないことが判定される。この判定も上述のように操作２１４（図４）で用いられる。いずれの場合も手順は終了ブロック４６８で示されるように終了する。
【０１５６】
上記図８および図９に関連して説明されたアルゴリズムはクライアント、すなわちストリーミング・クライアント、の処理能力を考慮に入れていない。従って、図４に関連して上記に説明された手順はストリーミング・クライアントのローカルな処理能力を考慮に入れているので、図８および図９に関連して上記に説明された利用可能な帯域幅および図５〜図７に関連して上記に説明した処理済みパケットの減少双方を必要とする。
【０１５７】
計量は推定だけであり、ネットワーク条件は常に変化しているので、ビットレート増加の数は限定されるかもしれない。一実施形態で、接続を引き上げ得る速度は最高ビットレート・レベルからのレベル数で２分を割ったものに等しい。従って、ストリーミング・クライアントが最高ビットレートから２番目に高いビットレートに落とされた場合、増加は２分／第２レベル＝毎分１増加起こり得る。ストリーミング・クライアントが最高ビットレートから３番目に高いビットレートに落とされた場合、増加は２分／第３レベル＝４０秒毎に１増加となる。
【０１５８】
一実施形態で、ＤＳＳ１２０に接続されたストリーミング・クライアントの増加し得る数は選択された時間間隔にわたり限定されることができる。例えば、増加し得るストリーミング・クライアントの数は５秒毎に１つに限定されることができる。これにより各クライアントはビットレートを増加することができ、ネットワークは安定化するために短時間与えられ、１２までのストリーミング・クライアントが毎分ビットレートを増加することができる。
【０１５９】
加えて一実施形態はデータ・バーストの影響を削減するためにバースト検出ルーチンを含むことができる。例えば、ストリーミング・データがビデオ・データを含む場合、ビデオが重要な動きを含む際定期的にＩ−フレームを伝送するかもしれない。ビデオ圧縮技術において周知のように、Ｉ−フレームは先行するビデオ・フレーム用に前以て伝送されたデータに依存することなく完全なビデオ・フレームを構築するのに充分な情報を含んでいる。このため、Ｉ−フレームは典型的なビデオ・フレームよりデータ条件がかなり大きい。このようなバーストが起こると、コントローラ１２６は各ストリームのビットレートを半分に削減するか、または接続された各クライアントに対しより低いビットレートのデータ・ストリームを選択せしめ、その値を３つのＲＴＣＰ受信機報告パケットに対し維持した後、通常のビットレートを再開することができる。
【０１６０】
時折、ネットワークが最適でないビットレートで安定化する可能性がある。アルゴリズムはネットワークが最適化されているように挙動するかもしれないが、実際にはビットレートが増加するかもしれない。これを考慮に入れるため一実施形態で、ネットワーク調節がある期間あまり多くない場合ストリーミング・クライアントの１つへの接続がランダムに選ばれ、次に高いビットレートを有するデータ・ストリームに切り替えられる。あまり頻繁に実施されない限り、これは各接続が最適なビットレート・レベルに到達するのに役立ち得る。
【０１６１】
上述の実施形態を念頭に、発明はコンピュータ・システムに格納されるデータに関する各種コンピュータ実施の操作を用い得ることが理解されよう。これらの操作は物理量の物理的操作を必要とするものである。必ずではないが、これらの量は通常格納、転送、組み合わせ、比較、およびその他の方法で操作できる電気的または磁気的信号の形を取る。さらに、実施される操作はしばしば生み出す、識別する、判定する、または比較するなどの用語で呼ばれる。
【０１６２】
本明細書で説明され、発明の一部をなす操作は有用な機械操作である。発明はさらにこれらの操作を行なうデバイスまたは装置に関する。装置は要求される目的用に特別に構成することができ、または汎用コンピュータでコンピュータ内に格納されるコンピュータ・プログラムにより選択的に稼動されまたは設定されるものであっても良い。特に、各種汎用機を本明細書の教示に従って書かれたコンピュータ・プログラムと共に用いることができ、または要求される操作を実施するためにより特化された装置を構築する方が便利かもしれない。
【０１６３】
発明はさらにコンピュータ読み取り可能な媒体上のコンピュータ読み取り可能なコードとして具現することもできる。コンピュータ読み取り可能な媒体はデータを格納できる任意のデータ記憶装置で、データはその後コンピュータ・システムにより読み取られる。コンピュータ読み取り可能な媒体の例としてはハード・ドライブ、ネットワーク接続記憶装置（ＮＡＳ）、読み取り専用メモリ、ランダムアクセス・メモリ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、および他の光学および非光学データ記憶装置が挙げられる。コンピュータ読み取り可能な媒体はさらにコンピュータ読み取り可能なコードが分散的に格納され実行されるようにネットワーク接続コンピュータ・システム上に分散されることもできる。
【０１６４】
本発明の実施形態は単一のコンピュータ、または相互接続された複数のコンピュータもしくはコンピュータ・コンポーネントを用いて処理することができる。本明細書で用いられるコンピュータとは、独自のプロセッサ、独自のメモリ、および独自の記憶装置を有する独立型コンピュータ・システム、またはネットワークに接続された端末装置にコンピュータ・リソースを提供する分散型コンピュータ・システムを含むものとする。分散型コンピュータ・システムのいくつかにおいて、コンピュータ・システムのユーザは、実際には何人かのユーザで共有されるコンポーネント部分をアクセスしているかもしれない。従って、ユーザはネットワーク上で仮想コンピュータをアクセスすることができ、これはユーザにとって単一ユーザ向けにカスタマイズされた単一の専用コンピュータとみなされる。
【０１６５】
前述の発明は明快な理解の目的からかなり詳細に説明されたが、添付クレームの範囲内で特定の変更および修正が可能であることが理解されよう。従って本実施形態は限定的ではなく例示的であるとみなすべきで、発明は本明細書で提供される詳細に限定されず、添付クレームの範囲およびその相当内で修正できる。
【図面の簡単な説明】
【０１６６】
【図１】複数の会議参加者および複数のストリーミング・クライアントを有する典型的な「少数対多数」（「few to many」）会議システムを示す。
【図２】図１の会議システムとの使用に適した典型的なコンピュータを示す。
【図３】図１の会議システムの別の図である。
【図４】ストリーミング・クライアント用の受信可能な帯域幅を特定する典型的な手順を描くフローチャートを示す。
【図５】伝送されたがクライアントにより未処理のパケットの数が増加したが減少したかを判定する手順を図示したフローチャートを示す。
【図６】図５の方法によるデータ・ストリーミング・サーバおよびストリーミング・クライアント間の典型的なトランザクションを示す。
【図７】図５のフローチャートの典型的な運用を図示する典型的なグラフである。
【図８】フレーム間パケット・タイミングを用いたネットワーク帯域幅の相対的計量を測定する手順を図示するフローチャートを示す。
【図９】データ・ストリーミング・サーバおよびストリーミング・クライアント間の典型的なトランザクションを示す。
【符号の説明】
【０１６７】
１７４…ユーザ・インタフェース、１７６…ネットワーク・インタフェース、１６６…メモリ、１７２…アプリケーション、１１０…会議サーバ、１２０…データ・ストリーミング・サーバ、１２１…ビデオ・コーデック、１２２…音声・コーデック、１２３…パケッタイザ、１２４…パケッタイザ、１２５…伝送回路、１２６…コントローラ、１２８…受信回路、１３０…会議参加者、１５０…ストリーミング・クライアント、１５５…ネットワーク、１５０…ストリーミング・クライアント、１５０…ストリーミング・クライアント。
【図１】
2008099276.tif 000003
【図２】
2008099276.tif 000004
【図３】
2008099276.tif 000005
【図４】
2008099276.tif 000006
【図５】
2008099276.tif 000007
【図６】
2008099276.tif 000008
【図７】
2008099276.tif 000009
【図８】
2008099276.tif 000010
【図９】
2008099276.tif 000011