(57)【特許請求の範囲】
【請求項１】
リアルタイムのデータ送信器と、データ記憶装置を有するリアルタイムのデータディスプレイ装置と、前記リアルタイムのデータ送信器および前記リアルタイムのデータディスプレイ装置を接続するネットワークとを含むリアルタイムの通信装置を動作させる方法において、
前記リアルタイムのデータ送信器を動作させて、
第１のコード化レートでコード化され、且つリアルタイム表示の第1の部分を表す複数の第１のコード化レートのデータパケットを、前記リアルタイムのデータディスプレイ装置に、前記第１のコード化レートのデータパケットの前記第１のコード化レートよりも高い送信レートで送信するステップと、
前記リアルタイムのデータディスプレイ装置を動作させて、
前記第１のコード化レートのデータパケットを前記データ記憶装置に受信し、
第１のレベルの品質でユーザに前記リアルタイム表示の前記第１の部分を表示するようにデコードするために、前記第１のコード化レートのデータパケットの前記第１のコード化レートに等しいデータレートで、前記データ記憶装置から、前記受信された第１のコード化レートのデータパケットを読み出し、
前記データ記憶装置が前記第１のコード化レートのデータパケットで予定されたレベルまで満たされたときに、前記予定されたレベルに到達した指示を前記リアルタイムのデータ送信器に送るステップと、
前記リアルタイムのデータディスプレイ装置から前記指示を受信したときに、前記リアルタイムのデータ送信器を動作させて、
前記第１のコード化レートのデータパケットの前記第１のコード化レートよりも高い、第２のコード化レートのデータパケットの第２のコード化レートでコード化され、且つ前記リアルタイム表示の後続部分を表す第２のコード化レートのデータパケットを、前記リアルタイムのデータディスプレイ装置に送るステップと、
前記リアルタイムのデータディスプレイ装置を動作させて、
リアルタイム表示の後続部分を表す第２のコード化レートのデータパケットを前記データ記憶装置に受信し、
前記第１の品質レベルよりも高い第２の品質レベルで、前記リアルタイム表示の前記後続部分を前記ユーザに表示するようにデコードするために、前記第２のコード化レートのデータパケットの前記第２のコード化レートに等しいデータレートで、前記データ記憶装置から前記第２のコード化レートのデータパケットを読み出すステップと、
を含む方法。
【請求項２】
前記リアルタイムのデータディスプレイ装置は、パケット損失情報を前記リアルタイムのデータ送信器に送って、
パケット損失情報を受信したことに応答して、前記リアルタイムのデータ送信器は、前記リアルタイムのデータディスプレイ装置への前記第２のコード化レートのデータパケットの前記送信レートを下げる、請求項１に記載の方法。
【請求項３】
前記リアルタイムのデータ送信器は、
持続するパケット損失が発生しているかどうかを決定して、
前記決定に応答して、第１のコード化レートのデータパケットを前記リアルタイムのデータディスプレイ装置に送る、請求項２に記載の方法。
【請求項４】
リアルタイムのデータ送信器と、
データ記憶装置を有するリアルタイムのデータディスプレイ装置と、
前記リアルタイムのデータ送信器および前記リアルタイムのデータディスプレイ装置を接続するネットワークと、
を具備する、リアルタイムの通信システムであって、
前記リアルタイムのデータ送信器は、
第１のコード化レートでコード化され、且つリアルタイム表示の第1の部分を表す複数の第１のコード化レートのデータパケットを、前記リアルタイムのデータディスプレイ装置に、前記第１のコード化レートのデータパケットの前記第１のコード化レートよりも高い送信レートで送信するように動作可能であり、
前記リアルタイムのデータディスプレイ装置は、
前記第１のコード化レートのデータパケットを前記データ記憶装置に受信し、
第１のレベルの品質でユーザに前記リアルタイム表示の前記第１の部分を表示するようにデコードするために、前記第１のコード化レートのデータパケットの前記第１のコード化レートに等しいデータレートで、前記データ記憶装置から、前記受信された第１のコード化レートのデータパケットを読み出し、
前記データ記憶装置が前記第１のコード化レートのデータパケットで予定されたレベルまで満たされたときに、前記予定されたレベルに到達した指示を前記リアルタイムのデータ送信器に送るように動作可能であり、
前記リアルタイムのデータ送信器は、前記指示を受信したときに、
第２のコード化レートでコード化され、且つ前記リアルタイム表示の後続部分を表す第２のコード化レートのデータパケットを、前記リアルタイムのデータディスプレイ装置に送るように動作可能であり、
前記第２のコード化レートのデータパケットの前記第２のコード化レートは、前記第１のコード化レートのデータパケットの前記第１のコード化レートよりも高く、
更に、前記リアルタイムのデータディスプレイ装置は、
前記リアルタイム表示の後続部分を表す第２のコード化レートのデータパケットを前記データ記憶装置に受信し、
前記第１の品質レベルよりも高い第２の品質レベルで、前記リアルタイム表示の前記後続部分を前記ユーザに表示するようにデコードするために、前記第２のコード化レートのデータパケットの前記第２のコード化レートに等しいデータレートで、前記データ記憶装置から前記第２のコード化レートのデータパケットを読み出すように動作可能である、
リアルタイムの通信システム。
【請求項５】
前記リアルタイムのデータディスプレイ装置は、
パケット損失を検出して、パケット損失情報を前記リアルタイムのデータ送信器に送るパケット損失検出手段、を更に具備しており、
前記パケット損失情報を受信したことに応答して、前記リアルタイムのデータ送信器は、
前記リアルタイムのデータディスプレイ装置への前記第２のコード化レートのデータパケットの前記送信レートを下げるように更に動作可能である、請求項４に記載のリアルタイムの通信システム。
【請求項６】
前記リアルタイムのデータ送信器は、
持続するパケット損失が発生しているかどうかを決定する決定手段、を更に具備しており、
前記決定手段が持続するパケット損失の決定をしたことに応答して、第１のコード化レートのデータパケットを前記リアルタイムのデータディスプレイ装置に送る、請求項５に記載のリアルタイムの通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
発明はパケット交換ネットワーク上の時間に敏感なデータの取り扱いの分野であって、特にインターネット上のビデオデータを送信および受信することに関する。
【０００２】
発明はパケットネットワークを横切って顧客にビデオサービスの流れを提供するとともに、バッファの使用を維持している間にデータのバッファを準備することに通常関連づけられる始動遅れを減少させる方法に関連する。発明はまた、ネットワークで渋滞に順応するためビデオの流れの送信レートを制御する方法に関連する。
【背景技術】
【０００３】
伝統的に、インターネットはFTP、電子メール、およびウェブサーフィンなどのトラフィックを支持し、そこでは、全体の遅れはメディアの最終的なプレゼンテーションを本質的に損なわれない。より速い処理マルチメディアPCの到来はインターネット上にビデオを含むマルチメディアの配送を駆り立てた。しかしながら、時間に敏感なアプリケーションは、保証されたサービスの連続した質、高い帯域幅データチャンネルを必要とし、それは表面上インターネットのパケットベースの特質と相容れず、容認できないパケットジッター、即ち可変ルーティングによって引き起こされたパケットの相互到着時間の変化、および渋滞のために配送率の可変性により送信を中断する可能性を持っている。現在、商業ストリーミング技術は、再生ビデオデータの始まる前に大きいバッファ(5-30秒)を構成することによりジッターを克服した。この始動遅れはユーザにとって非最適であり、要求されたコンテンツが不正確であることがわかる前にユーザはこの期間を待たねばならないかもしれず、一般に、マルチメディアプレゼンテーションのユーザ経験を損ねる。
【発明の概要】
【０００４】
本発明の第１の態様によると、リアルタイムのデータ送信器と、記憶装置を持っているリアルタイムのデータディスプレイ装置と、前記送信器および前記ディスプレイ装置を接続するネットワークとを含むリアルタイムの通信装置を操作する方法が提供され、前記方法は以下のステップを含む：
リアルタイムのプレゼンテーションの第1の部分を表すデータパケットを複数の第１のコード化レートで前記ディスプレイ装置に送信するように前記送信器を操作し、送信レートが前記コード化レートより高くされ；
前記ディスプレイ装置は、
前記第１のコード化レートのデータパケットを前記記憶装置に受信し、
第１のレベルの品質で前記ユーザに前記リアルタイムのプレゼンテーションを表示するようにデコードするため、前記第１のコード化レートで前記記憶装置からの第１のコード化レートのデータパケットを移転し、
前記第１のコード化レートのデータで予定されたレベルに満たされる前記記憶装置において、前記レベルが到達した指示を前記送信器に送るように操作され、
前記指示を受けて、前記送信器は前記リアルタイムのプレゼンテーションのその後の部分を表している第２のコード化レートでデータパケットを前記ディスプレイ装置に送るように操作され、前記第２のコード化レートは前記第１のコード化レートより高くされ；
前記ディスプレイ装置は、
リアルタイムのプレゼンテーションのその後の部分を表す第２のコード化レートのデータパケットを前記記憶装置に受信し、
前記第１の品質レベルよりも高い第２の品質レベルで、前記リアルタイムのプレゼンテーションを前記ユーザに表示するようにデコードするために、前記第２のコード化レートで前記記憶装置から第２のコード化レートのデータパケットを移転するように操作される。
【０００５】
本発明の別の態様によると、時間に敏感なデータのバッファを構成して顧客に時間に敏感なデータを提供する方法が提供され、前記方法は、前記顧客に送られた時間に敏感なデータを受信し、前記時間に敏感なデータをデータバッファに送ることと、データバッファにある時間に敏感なデータの質を監視することと、見るために処理されるべきデータバッファの前記時間に依存したデータを読み出すこととを含み、方法は、時間に敏感なデータがデータバッファから読み出されるレートが時間に敏感なデータがデータバッファに送られるレートよりも低く、顧客が時間に敏感なデータを受け取り、時間に敏感なデータを利用可能にする間の遅れが実質的にないように、データがデータバッファに到着するとき時間に敏感なデータがデータバッファから読み出される、時間に敏感なデータを提示することを特徴とする。
【０００６】
データバッファが十分に満たされるようになる時点が来るであろう。そのとき送信のレートは、見る手段による消費のレートに等しいように減少され、バッファの中のデータの量は均衡にされるであろう。しかしながら、この状況では、接続の帯域幅は完全な容量で使われないかもしれない。
【０００７】
本発明のさらに別の態様において、顧客に時間に敏感なデータを提示する方法が提供され、ここに、コード化された時間に敏感なデータは、予定された量のデータがデータバッファを満たすまで、第１のビットレートで受信され、そのあとコード化された時間に敏感なデータは第２のビットレートで受信され、ここに第２のビットレートは第１のビットレートよりも高い。
【０００８】
本発明のさらに別の態様は、顧客へ時間に敏感なデータを提供する方法を提供し、ここに第１のビットレートでコード化された時間に敏感なデータは顧客に送信されるべき第１の送信レートで第１のデータバッファから読み出され、要求のあったときに、第２のビットレートでコード化された時間に敏感なデータは第２のレートで第２のデータバッファから読み出される。
【０００９】
ビデオデータのより高いビットレートでより良い質の再現をもたらすために、データを送信するためにできるだけ多くの利用可能なリンクの帯域幅を使用することが望ましい。しかしながら、ネットワークのデータの損失は、増加するビットレートの利益をはるかに追い越して、サービスの厳しい低下をもたらす。例えば、H.263およびMPEGなどの予測コード構成で、500kbits-1のビデオストリームの半分を受信することは、250のkbits-1のストリームのすべてよりはるかに悪い品質を与えそうである。したがって、ネットワークでデータを失わせるよりむしろ、制御された方法で送信レートを下げることが重要である。インターネットプロトコルTCPには、パケット損失が検出されるまでデータ送信レートを着実に増加させ、そのあとにデータレートを減少する組み込まれた制御メカニズムがある
。その後データレートはパケット損失が再び起るまで増加される。可変送信レートは弾力性があると言われ、ネットワーク状態に対応してデータの送信レートを制御することができるアプリケーションはTCPフレンドリイであると言われている。TCPフレンドリイな方法によるビデオデータを提供し、それによりどんな特定の時にも利用可能な帯域幅の多くが利用されることが望ましい。TCPフレンドリイなデータ配送のさらなる利点は、それぞれが帯域幅の正当な分け前をもつまで、個々のアプリケーション自体がデータレートを減少させるようにネットワークにおける渋滞が管理されるということである。
【００１０】
MPEG4またはH.263などの標準の圧縮技術はTCPフレンドリイなふるまいを示すように管理することができ、例えば出願人の係属中の出願番号GB9928023.2を参照されたい。しかしながら、この解決策はビデオストリームあたり高速で、専用のPCを必要とする。また、ネットワーク渋滞が探知されるとき、高いビットレートから低ビットレートまでのコード化されたデータストリームを完全にコード化することは計算上必要とされる問題に悩まされる。品質の適合はビデオストリームの層（layer）を加えるか、または落とすことによって達成されるので、ビデオストリームを層にする使用には別のアプローチがある。この方法の不都合は、利用可能な帯域幅のある割合が層を統合するための指示に割り当てられなければならないので効率が悪いということである。
【００１１】
本発明はさらに、時間に敏感なデータが第１および第２のバッファから読みだされるレートが顧客へのリンクの状態に依存してダイナミックに変えられる方法を提供し、さらに顧客へのリンクの状態に依存して、第１のビットレートでコード化された時間に敏感なデータが顧客に送信された第１の送信レートで第１のデータバッファから読み出され、または第２のビットレートでコード化された時間に敏感なデータが第２のレートで第２のデータバッファから読み出され、ここに前記第１のビットレートは第２のビットレートよりも低い。
【００１２】
発明の実施例が例示だけの方法で図を参照して説明される。
【図面の簡単な説明】
【００１３】
【図１】エンコーダと、ビデオストリーマおよび顧客間の関係の概要の概観である。
【図２】ビデオストリーマ配列を示す。
【図３】顧客の配列を示す。
【図４】本発明の1実施例のステップ的操作を示す。
【発明を実施するための形態】
【００１４】
図1に示されるように、本発明の第１の実施例は圧縮されたビデオデータのソース、エンコーダ1を含み、それは例えば500kbits-1の値を有する低いビットレート RLおよび例えば1500kbits-1の高いビットレートRHの両方のデータをコード化する。使用される圧縮コーデックはH.263であるが、等しくMPEG4などのいかなる他のコーデックであってもよい。エンコーダ1はその入力として、例えば、スポーツイベントの放送のような“生”ビデオデータを取る。
【００１５】
2つのコード化されたデータストリームが別々の論理的な接続を通して送信レートTEでビデオストリーマ2へ送信される。ビデオストリーマ2はエンコーダ1と同じ構内にあり、イントラネットを通して結合されるかもしれない。ビデオストリーマ2は、例えばインターネットにアクセスを有するペンティアム（登録商標）III 700MHz、256MB RAMを含むサーバコンピュータで実行する。
【００１６】
これまで顧客と呼ばれたビデオビューワは、インターネットにアクセスを持つために適当に構成されるPC(図1の3a、3b、3cなど)で実行し、インターネットを通してビデオストリーマ2に接続し、その結果、顧客はコンテンツにアクセスすることができる。適当なPC端末は266MHzペンティアム（登録商標）IIラップトップPCである。ビデオストリーマ2は、同じストリームを見る多くの顧客(最大通常1000)を支持することができる。
【００１７】
生放送のために、エンコーダ1はリアルタイムである送信レートTEで送信するであろう。異なるビットレートでコード化されたデータRLとRHの2つのストリームは異なる質のビデオ再現を提供するが、各データストリームは同じ送信レートTEを有する。データはリアルタイムで再生するプログラムためこのレートでデコードされなければならない。
【００１８】
図2はビデオストリーマ2の配列を示す。エンコーダ1から低いビットレートRLでコード化された低い質のコード化ビデオデータ、および高いビットレートRHでコード化された高い質のコード化ビデオデータが、それぞれ入力接続21および22で受け取られ、それぞれバッファ23および24に供給される。ビデオストリーマ2によって受け取られるコード化されたビデオデータのチャンネルあたり1つのバッファが提供されることに注意すべきである。コード化されたビデオデータは選択するスイッチ26を通して各バッファ23、24から読みだされ、コード化されたビデオデータストリームは出力接続27に送られることになっている。データが各バッファ23、24から読みだされるレートを制御することができるバッファマネージャ25が設けられ、その結果ビデオストリーマ2の送信レートTSを定義することができる。バッファマネージャはまたスイッチ26に接続され、かつさらに接続28から信号を受信することができる。TSがエンコーダ送信レートTEよりも小さく、等しく、または大きくすることができるように、TSはそれぞれのパケットの送信の間で時間の遅れを変えることにより選択される。技術に熟練した者は、S kbitsのサイズのバッファがS/2 kbitsのサイズのバッファの2倍長い間TS＝2TEの送信レートを維持することができるように、TS>TEである送信の持続性の制限要因が、バッファ23、24のサイズであることを理解するであろう。スイッチ26と送信レートTSの両方のコントロールを通して、バッファマネージャは2つのスケールでビデオストリーマ2から出力されるビットレートを制御することができ、送信レートTSを調整することによってビットレートの微制御を達成し、ビットレートRLおよびRHでコード化された2つのコード化されたデータストリーム間を切り換えることによって、粗スケールにおけるビットレートの制御を達成する。バッファマネージャ25はTSへの調整を行い、または接続28から受信される信号に対応してバッファの間の出力を切り換える。
【００１９】
図3はPC3a、3b、3cなどで実行している顧客の配列を示す。ビデオストリーマ2から送られるコード化されたビデオデータは、接続27を通して顧客に受け取られ、パケット損失検出器31によって完全性をチェックされる。そして、データはネットワークスループットにおける変動を吸収するために適当なサイズである顧客バッファ32に送られる。顧客バッファ32はデコーダ33に直接接続され、そこからデコードされたデータは顧客スクリーン(示されない)に表示されるために送られる。顧客状態モニター34はパケット損失検出器31と顧客バッファ32に接続される。顧客状態モニター34は接続28を通して信号を送ることができる。
【００２０】
パケット損失検出器31は入って来るパケットを監視する。パケット損失が検出されるなら、その時信号が顧客状態モニター34に送られ、それは接続28を通してビデオストリーマ2のバッファマネージャに知らせる。欠けているパケットを再送することができる。最大の帯域幅が利用されていることを示しているパケット損失の一貫したパターンが起こるまで、バッファマネージャ25は送信レートTSを着実に増加させる。渋滞のないネットワークを維持するために、送信レートTSは指数関数的に減少されるかもしれない。顧客バッファ32がデータで十分いっぱいになるとき、信号は接続28を通してビデオストリーマ2のバッファマネージャ25に送られるように、顧客状態モニター34が顧客バッファ32のデータ量を監視する。
【００２１】
上で説明したように、ビデオストリーマ2と顧客3のシステムはユーザフレンドリーなビデオの流れを許容し、即ち、顧客バッファ32はネットワーク状態の変化にもかかわらず、ビデオの品質をエネーブルにし、それはそうでなければメディアの総合的な知覚された品質に有害な影響を与えたかもしれない。
【００２２】
発明のこの実施例の動作は図4を参照して記述される。
【００２３】
ビデオストリーマ2が初期化され、それはエンコーダ1からのデータの量によりバッファ23、24を満たすことを含む。生放送のため、データは絶えずバッファ23、24に供給され、次に、バッファのサイズと受け取られるデータの質によって定義される時間量の後に捨てられる。
【００２４】
インターネットでウェブページをブラウズするためにブラウザソフトウェアを実行するPCは、例えば、流されたビデオを提供する実体によってホストされたサイトの生放送へのリンクを選択するために使用されているかもしれない。特定のクリップまたは放送を見ることに関心があると、ユーザはリンクをクリックする(選択する)。ブラウジングソフトウェアは、流されたビデオデータが要求されていたことを検出して、顧客3を具体化する顧客ソフトウェアを見てビデオを発送する。顧客3は接続28を経てバッファマネージャ25へ“send data”命令を発行し、バッファマネージャは低いビットレートデータバッファ23からのコード化されたビデオデータを読み出し、かつTS=2TEの送信レートを要求するようにスイッチ26を設定する。データはデータ接続27、そしてそこから顧客3に送られる。RLとして500kbits-1以上を引用されたビットレートでコード化する例を使用すると、
データは1000kbits-1のレートで顧客へネットワーク内を流れる。
【００２５】
顧客3はコード化されたビデオデータを受信し、それをパケット損失検出器31を通してレート2TEで供給される顧客バッファ32に送る。データがバッファ32に検出されるとき、コード化されたビデオデータはTEのレートで即座にデコーダ33に読みだされる。したがって、バッファ32はレートTEで満たされ、その間デコーダ33からのデコードされたデータが表示される。したがって、ユーザは顧客バッファ32が満たされるまで待つ必要はなくビデオ画像を提供される。
【００２６】
顧客モニター34は顧客バッファ32のRLデータの量が指定されたレベルに達するまで待っており、それ以上になると“switch buffer”命令を接続28を通してビデオストリーマ2のバッファマネージャ25に送る。バッファマネージャ25はそのとき、データの流れを低いビットレートのデータバッファ23から高いビットレートのデータバッファ24へ切り換えて、レートTS＝TEで送信を指示する。上で引用されたレートでコード化する例を使用すると、データは1500kbits-1でネットワークに送信される。
【００２７】
顧客バッファ32はそのとき高い質のデータで満たされ始め、それは低い質のデータの後ろに置かれるであろう。時間の長さの後に、RHデータがデコーダ33に読み取られ始めると、ユーザは画質の増加を知覚するであろう。このポイントについて、顧客3は十分なバッファを有し、ユーザはネットワークリンクの容量と一致した品質の画像を見守っている。
【００２８】
ビデオストリーマ2は多くの顧客(通常1000)を支持することができる。各顧客は初めに、始動フェーズのためのユニークな読み取りポイントを与えられ、そうすると、顧客バッファ32の均衡が達せられた後、ビデオストリーマ2がバッファ24から高いビットレートデータを供給し、読み取りポイントが他の顧客読み取りポイントと融合されることができる。読み取りポイントは、特定の顧客のために送信レートを増加するか、または減少させるかを要求されたネットワーク容量における不一致として委ねなくてはならないかもしれない。
【００２９】
熟練した者は、低いビットレートのデータバッファ23が、データの適当な量を顧客バッファ32に提供するに十分長い期間の間、2TEのレートでデータをバッファ23から読み出すことを許容するサイズのものであるべきであることを認識するであろう。例えば、バッファのために5秒が顧客3で500kbits-1データの価値があるとすると、ビデオストリーマ2は5秒間にデータの1000kbitsを供給しなければならず、その500kbitsは1秒あたりのデコーダ33によって消費され、500kbitsは5秒が経過するまで、1秒あたりバッファの中で増すであろう。したがって、低いビットレートのデータバッファは少なくとも5Mbitsのデータ(5x1000kbits)、または0.5Mbのすぐ上に保持できるに違いない。
【００３０】
熟練した者は、データがバッファから初めに読みだされるとき、コード化されたデータのストリームの“盗聴”と関連づけられた問題があると認識するであろう。エンコーダ1によって通常使われる圧縮技術は、アンカーフレームまたはＩ-フレームと呼ばれるビデオデータのフレームをコード化することを含み、このフレームから次のフレームが似ていることとして推定がなされ、推定されたフレームはB-フレームと呼ばれる。このように、一連のフレームを表すデータの量は大いに減少するかもしれない。しかしながら、データバッファ23、24のどちらかから読み出されるべき第１のフレームがB-フレームであるならば、デコードされたデータの第１の数フレームが推定に基づくフレームを再構成しようとするとき、デコーダとして難解であるかもしれない。発明のさらなる実施例では、データの余分なバッファが単にI-フレームからなるデータバッファ23、24と平行して供給される。送信されるべき第１のフレームがl-フレームバッファから読まれて、その結果、そこからデコードし始める信頼できるポイントをデコーダに与える。そして、データはデータバッファ23、24のどちらかから読み出されるように切り換えられる。
【００３１】
システムはユーザフレンドリーなビデオの流れを許容し、即ち、メディアの総合的な知覚された品質に有害な影響を及ぼすネットワーク状態変化の際に、ビデオの品質は急速に変動しない。顧客によって報告されるパケットの損失の場合に、システムはその送信レートを指数関数的に減少させることができる。顧客でバッファされるデータがあるとき、これはビデオソースの即座の切り換えをもたらす必要はない。パケットの損失の直後に、送信レートがコード化レートよりも低くなることが可能であり、ビデオデコーダの需要にこたえるために顧客がバッファされたデータで受信されたデータを補っているので、結果として顧客のバッファは空になる。孤立されたパケットの損失の場合、システムは、結局はバッファを満たす状態に戻る前に、初めに顧客のバッファが空になっているレートを遅く
して、再び送信レートを立ち上げることができる。
【００３２】
熟練した者は、しばらくは可変レートでデータを送信する能力が、流されたデータを弾性的にすることを可能にし、TCPフレンドリイな送信を許容することを認識するであろう。パケット損失検出器31による持続しているパケットの損失の検出はネットワーク渋滞を暗示している。ビデオストリーマ2のバッファマネージャ25は、高いビットレートデータバッファ24からのデータの送信レートの減少を指示することにより、パケットの損失の通知に反応する。高いビットレートデータバッファ24は、そのような出来事に対処するために適切な大きさにされるべきである。高いビットレートのデータバッファが支えることができるより長い間、減少された送信レートでパケットの損失が持続するなら、バッファマネージャ25は、低いビットレートのデータバッファ23からデータを供給するために切り換わるであろう。これは再生ビデオの知覚された品質の変化を引き起こすので、有効な管理プロトコルがネットワーク変動のデータ容量としてデータバッファ23および24間の急速な切り換えを防ぐ必要がある。ユーザが低い質の再生を許容する間、品質における急速な変化はユーザにとっていらだたしい場合がある。
【００３３】
ビデオストリーマに供給されるコード化されたデータストリームの数にはどんな制限もない。最大の帯域幅利用は、低いビットレートデータバッファからデータを読むことにより始まって、送信レートが増加されるようにして達成される。この送信レートでどんなパケットも失われないことの発見で、出力はより高いビットレートデータバッファに切り換えられ、そうすると送信レートが増加される。この送信レートがどんな障害にも遭遇しないならば、もっと高いビットレートのデータバッファが切り換えられ、そして、最大の帯域幅が採用されるまで続く。
【００３４】
ビデオストリーマ2に位置するバッファマネージャ25は、送信レートTSをどのように調整するか、およびいつバッファを切り換えるかを決めることが可能にされる。同様に、送信レートTSとどのバッファからデータを供給するかに関して顧客3からビデオストリーマ2へ指示が送られる。この場合ISPであるサービスについて請求に応答可能であるセンターの近くにコントロールセンターを位置させるのが実用的であるので、記述された実施例のバッファマネージャ25の位置は選択された。
【００３５】
ビデオデータの例は、上の実施例を例証するためにマルチメディアデータの例として選ばれる。発明は同様に、オーディオデータやマルチメディアプレゼンテーションなどの時間に敏感なデータのいかなる他の形にも適合する。
【００３６】
上記実施例において、データはエンコーダ1によって供給される。同様に、圧縮されたビデオデータはプログラムデータファイルのライブラリ、例えば呼び物フィルムのライブラリに保持され、必要なときにアクセスされるかもしれない。
【００３７】
ビデオストリーマ2とエンコーダ1はインターネットを通して接続されるように、ビデオストリーマ2がエンコーダ1から離れていてもよい。ビデオストリーマ2がインターネットサービスプロバイダ(ISP)により操作され、ビデオストリーマ2とエンコーダ1のと遠隔接続は、ISPが多くのエンコーダから顧客にコンテンツを利用可能にすることを許容するであろう。
【符号の説明】
【００３８】
１…エンコーダ  ２…ビデオストリーマ  ３…顧客
【図１】
0005373131.tif 000002
【図２】
0005373131.tif 000003
【図３】
0005373131.tif 000004
【図４】
0005373131.tif 000005