(57)【特許請求の範囲】
【請求項１】
複数のサーバを有するネットワーク環境においてマルチパスアダプティブストリーミングを用いてマルチメディアコンテンツを伝送するシステムであって、
各サーバはそれぞれのデータパスにより、クライアントに、ＲＴＰ／ＲＴＳＰ準拠通信プロトコルに基づき、前記マルチメディアコンテンツを伝送するように構成され、
前記クライアントは、各データパスに関連するそれぞれの帯域幅を決定し、決定されたそれぞれの帯域幅と、前記マルチメディアコンテンツのレンダリング時間とにより各サーバに前記マルチメディアコンテンツのチャンクを要求するために、前記各データパスをプローブできるコントローラを含み、
前記クライアントは、最も遅いパスを用いて、時間的に遅くレンダリングされるチャンクを取得し、最も速いパスを用いて、すぐにレンダリングされるチャンクを取得することを特徴とする、システム。
【請求項２】
前記コントローラは、各サーバと前記クライアントとの間の各データパスの利用可能ビットレートを推定する手段を含み、サーバ送信スピード制御を行うように構成されることを特徴とする、
請求項１に記載のシステム。
【請求項３】
前記コントローラは、利用可能なビットレートにより、それぞれのサーバにより配信される次のチャンクを選択するチャンク選択手段を含むことを特徴とする、
請求項１または２に記載のシステム。
【請求項４】
前記コントローラは、正しい消費順序を実現するために、リンクされたリストから割り当てられたビンに、前記サーバの１つのチャンクをリンクするように構成されたビン割り当て手段を含むことを特徴とする、
請求項１ないし３いずれか一項に記載のシステム。
【請求項５】
前記コントローラは、単一のコヒーレントストリームを構成するために、ＲＴＰタイムスタンプとシーケンス番号を更新するＲＴＰリナンバリング及びリタイムスタンピング手段を含むことを特徴とする、
請求項１ないし４いずれか一項に記載のシステム。
【請求項６】
マルチパス環境におけるアダプティブストリーミングの方法であって、
−クライアントを設けるステップと；
−複数のサーバであって、それぞれが前記クライアントにそれぞれのデータパスにより、ＲＴＰ／ＲＴＳＰ環境で、マルチメディアコンテンツを送信するように構成された複数のサーバを設けるステップとを有し、
前記クライアントは、各データパスに関連するそれぞれの帯域幅を決定し、決定されたそれぞれの帯域幅と、前記マルチメディアコンテンツのレンダリング時間とによりいずれかのサーバに前記マルチメディアコンテンツのチャンクを要求するために、前記各データパスをプローブするコントローラを含み、
前記クライアントは、最も遅いパスを用いて、時間的に遅くレンダリングされるチャンクを取得し、最も速いパスを用いて、すぐにレンダリングされるチャンクを取得することを特徴とする、方法。
【請求項７】
前記コントローラは、マルチパスストリーミングセッションで用いられる各サーバについて、サーバ送信スピード制御と、帯域幅測定と、帯域幅推定とを並行して行うために、パスのビットレート推定をする手段を含むことを特徴とする、
請求項６に記載の方法。
【請求項８】
パスのビットレート推定は周期的に繰り返されることを特徴とする、
請求項７に記載の方法。
【請求項９】
パスのビットレート推定は、再生要求に送信スピードパラメータを付加することにより、対応するサーバの送信スピードを制御し、前記送信スピードパラメータは前記対応するサーバにより用いられることを特徴とする、
請求項７または８に記載の方法。
【請求項１０】
各サーバについて、現在のレートがスムージングアルゴリズムにより用いられ、推定値を繰り返し決定し、前の繰り返し期間中に測定したビットレートから到達可能ビットレートを求めることを特徴とする、
請求項９に記載の方法。
【請求項１１】
各サーバについて、現在レートの分散を計算することを特徴とする、
請求項９に記載の方法。
【請求項１２】
前記コントローラは、それぞれのサーバにより配信される次のチャンクのビットレート選択を行えるチャンクスケジューリング手段を含むことを特徴とする、
請求項６ないし１１いずれか一項に記載の方法。
【請求項１３】
すべてのサーバの個別のビットレート推定値が合計され、合計ビットレートが求められ、チャンクの再生レートが合計ビットレートのすぐ下のエンコーディングビットレートに選択されることを特徴とする、
請求項１２に記載の方法。
【請求項１４】
前記コントローラは、正しい消費順序を実現するために、リンクされたリストから割り当てられたビンに、前記サーバの１つのチャンクをリンクするビン割り当て手段を含むことを特徴とする、
請求項６ないし１１いずれか一項に記載の方法。
【請求項１５】
前記コントローラは、単一のコヒーレントストリームを構成するために、ＲＴＰタイムスタンプとシーケンス番号を更新するＲＴＰリナンバリング及びリタイムスタンピング手段を含むことを特徴とする、
請求項６ないし９いずれか一項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、マルチパス環境におけるアダプティブストリーミングのためのシステムに関する。この発明は、より具体的には、オーディオ／ビデオストリーミングを改良するための、ネットワーク帯域幅条件が保証されておらず、そのため変動するマルチパス環境におけるアダプティブストリーミングのためのシステムに関する。この発明はさらに、マルチパス環境におけるアダプティブストリーミングのための方法に関する。
【背景技術】
【０００２】
ストリーミングは、ダウンロードとは対照的に、クライアントが消費するコンテンツを、クライアントに、小さく分けて送信するプロセスである。ダウンロードでは、マルチメディアファイル全体がクライアントに再生前に転送される。既存のストリーミングプロトコルには、リアルタイムトランスポートプロトコル（ＲＴＰ）や、ユーザデータグラムプロトコルによるＭＰＥＧトランスポートストリーム（ＭＰＥＧ  ＴＳ／ＵＤＰ）などがある。一方、一般的に、ダウンロードは、ハイパーテキストトランスファプロトコル（ＨＴＴＰプロトコル）を用いて行われる。
【０００３】
エンターテイメントシステムや通信システムでは、ＲＴＳＰプロトコル（リアルタイムトランスポートストリーミング）が、ストリーミングメディアサーバを制御するネットワークコントロールプロトコルとして設けられている。ＲＴＳＰサーバによるストリーミングデータの送信は、リアルタイムトランスポートプロトコル（ＲＴＰ）を介して行われる。ＲＴＳＰは、ストリーミングデータの再生を制御するのに有用な制御シーケンスを定義している。制御シーケンスは、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）によるＲＦＣ２３２６標準で定義されている。
【０００４】
ストリーミングセッションはクライアントによりストリーミングサーバに対して開始される。ストリーミングサーバはクライアントに対してユニキャストリンクで、要求されたビデオを届ける。ストリーミングセッションの確立には、クライアントとストリーミングサーバとの間で、一般的には、コンテンツ選択と、画面サイズ、ビットレート、最大バッファサイズなどのクライアントの特性の表示とを含む、複数のＲＴＳＰメッセージが必要である。最後に、ユニキャストＲＴＰストリーミングセッションが、その前にネゴシエーションされたパラメータを用いて確立される。一般的に、ストリーミングセッションパラメータは、クライアントが別のコンテンツを選択したり、ストリーミングセッションを終了するまで、変化しない。明らかに、この種の環境は、ネットワーク特性の変化にはうまく適合していない。ある運営者は、問題を避けるために、単に、実際に必要な帯域幅に加えて余分な帯域幅を有するクライアントに、あるサービスへのアクセスを制限することを選択する。
【０００５】
リアルタイムストリーミングは、インターネットを介してテレビチャンネルを送信する（ＩＰＴＶ）ために、ますます人気を得ている。しかし、マルチメディアプロバイダとクライアントとの間の帯域幅レートの変動に対処する手段を設ける必要がある。そうしないと、マルチメディアストリームの「フリーズ（freezing）」が発生する。これは一般的にカスタマにより不愉快なものと見なされる。
【０００６】
上記の帯域幅レートが変動するという問題を解決する様々な試みがなされている。
【０００７】
特許文献１では、１つのファイルを複数のサブファイルに分割し、そのサブファイルを１つ又は複数のサーバに配信して格納する。サブファイルは、１つ又は複数のサーバから並行して同時に送信される。これにより、データを配信できるレートが大きくなる。さらに、少なくとも１つのサブファイルを２つ以上のサーバに格納して、冗長化することができる。あるサーバが利用できなかったり、送信リンクが遅く、又は利用できなかったりする場合、他のサーバからサブファイルをストリーミングできる。
【０００８】
特許文献２では、複数のコントローラと複数のサーバとを含む、分散型のスケーラブルなコンテンツストリーミングアーキテクチャが示されている。コントローラは、個々のデバイスとリアルタイムストリーミングプロトコル（ＲＴＳＰ）セッションを確立するよう動作可能である。コントローラは、デバイスに、要求されたメディアストリームを提供するサーバを選択する。サーバは、デバイスへの近さ、帯域幅の利用可能性、又はレイテンシなどの特性に基づき、選択される。システムの動作を妨げずに、システムにサーバを追加することができる。
【０００９】
特許文献３は、動的レート調整を用いるストリーミングメディアシステムを示す。これは、持続的な接続によりメディアを配信するレガシーＨＴＴＰインフラストラクチャと互換性のあるファイルフォーマットを含む。レガシークライアントメディアプレーヤは、持続的接続によるメディアの符号化配信レートを動的に変更できる。
【００１０】
特許文献４では、少なくとも１つのアセンブリングデバイスの各グループに対して、少なくとも１つの基準に基づくフラクショナルストレージＣＤＮサーバのサブグループが選択される分散記憶が示されている。複数のサーバサブグループが、複数のアセンブリングデバイスグループに対して選択される。各セグメントを配信するのに用いられる帯域幅の合計が、そのセグメントから生成されたフラグメントを格納しているサーバの帯域幅の合計を越えない限り、フラグメントを読み出すのに用いる帯域幅の合計がサーバのサブグループに含まれるサーバの帯域幅の合計に近づくまで、そのサーバのサブグループから、アセンブリングデバイスにより複数のコンテンツセグメントに関連するイレージャコーデェドフラグメントを読み出す。
【００１１】
特許文献５は、マルチメディアサーバなどのデバイスの転送レート調整が示されている。これらのレート調整は、マルチメディアサーバによる、他の２つのネットワークノード間の、例えばアクセスポイントとビデオプレーヤ間の無線リンクから様々なサービス品質パラメータの決定に基づく。
【００１２】
特許文献６には、１つ以上のキャッシングサーバを有する通信ネットワークによりクライアントデバイスに接続されたネットワークサーバによるデータストリーミング伝送が開示されている。ネットワークサーバはデータストリーミングアプリケーションと、データを記憶するメモリとを有する。ソースネットワークとクライアントデバイスとの間の経路に、キャッシングサーバにより、それぞれがデータストリーミング装置を用いる一連の接続を形成する。各キャッシングサーバは、ストリーミングされたデータの追加的セグメントを記憶する拡張可能バッファを利用して、ダウンストリーム接続における伝送データレートを可変することにより、そのダウンストリーム接続におけるネットワーク輻輳を吸収できる。
【００１３】
さらに、３ＧＰＰ（３rd Generation Partnership Project）は、ネットワーク状態の変化に対応でき、ストリーミングサーバ側のスマート制御ロジックに関連する、同じコンテンツの（異なる符号化ビットストリームを有する）複数のバージョンを格納できるコンテナフォーマットを含む配信フレームワークを標準化した。しかし、この制御ロジックは３ＧＰＰにより仕様化されていない。
【００１４】
ＨＴＴＰストリーミングは、Ａｐｐｌｅ社によりｉＰｈｏｎｅで、Ｍｉｃｒｏｓｏｆｔ社によりＳｍｏｏｔｈｓｔｒｅａｍｉｎｇとして、又は３ＧＰＰによりＨＴＴＰアダプティブストリーミングとして宣伝されている。
【００１５】
最近の技術では、ＨＴＴＰプロトコルを用いて、クライアントからサーバに、現在のネットワーク状態に関するフィードバックを定期的に提供する。アダプティブコンテンツは、長さが固定だがビットレートが可変であるマルチメディアコンテンツの小さいチャンクであるが、ネットワーク状態に適合されて、クライアントに提供される。
【００１６】
明らかな欠点として、帯域幅が変化すると、クライアントにより知覚される品質が非常に悪くなることがある。さらに、これらの手法では、ＲＴＰ／ＲＴＳＰプロトコルに依存する既存のＩＰＴＶ機器を利用できない。
【００１７】
したがって、先行技術のシステムに関連する問題を、少なくとも部分的にでも、解決する、マルチパス環境におけるアダプティブストリーミングの方法及びシステムを提供する必要がある。
【先行技術文献】
【特許文献】
【００１８】
【特許文献１】国際出願公開第２００２／０７３４４１Ａ１号
【特許文献２】米国特許出願公開第２００９／０２５９７６２Ａ１号
【特許文献３】国際出願公開第２０１０／１１１２６１Ａ１号
【特許文献４】米国特許出願公開第２０１０／００９４９５５Ａ１号
【特許文献５】米国特許出願公開第２００６／０２１５５９６Ａ１号
【特許文献６】米国特許第６４０５２５６Ｂ１号
【発明の概要】
【課題を解決するための手段】
【００１９】
本発明によると、マルチパス環境におけるアダプティブストリーミングのためのシステムが提供される。該システムは、複数のサーバであって、それぞれがクライアントにそれぞれのデータパスにより、ＲＴＰ／ＲＴＳＰ環境で、マルチメディアコンテンツを送信するように構成された複数のサーバを有し、クライアントは、各データパスに関連するそれぞれの帯域幅を決定し、決定したそれぞれの帯域幅により各サーバにマルチメディアコンテンツのチャンクを要求するために、各データパスをプローブできるコントローラ手段を含む。
【００２０】
本発明の一実施形態では、コントローラ手段は、各サーバとデータパスに対して、サーバ速さ制御、帯域幅測定、及び帯域幅推定を実行できるパスレート推定手段を含む。
【００２１】
本発明の別の一実施形態では、コントローラ手段は、それぞれのサーバにより配信される次のチャンクのビットレート選択を実行できるチャンクスケジューリング手段を含む。
【００２２】
本発明の別の一実施形態では、コントローラ手段は、正しい消費順序を実現するために、リンクされたリストから割り当てられたビンに、サーバの１つのチャンクをリンクできるビン割り当て手段を含む。
【００２３】
本発明の別の一実施形態では、コントローラ手段は、デコーダが複数のサーバから受信したストリームを単一のサーバから受信したストリームと区別できないように、ＲＴＰタイムスタンプとシーケンス番号とを更新できるＲＴＰリナンバリング及びリタイムスタンピング手段を含む。
【００２４】
本発明のさらに別の一態様において、マルチパス環境におけるアダプティブストリーミングする方法が提供される。該方法は、クライアントを設けるステップと、複数のサーバであって、それぞれがクライアントにそれぞれのデータパスにより、ＲＴＰ／ＲＴＳＰ環境で、マルチメディアコンテンツを送信するように構成された複数のサーバを設けるステップとを有し、クライアントは、各データパスに関連するそれぞれの帯域幅を決定し、決定したそれぞれの帯域幅により各サーバにマルチメディアコンテンツのチャンクを要求するために、各データパスをプローブできるコントローラ手段を含む。
【００２５】
本発明の一実施形態では、コントローラ手段は、マルチパスストリーミングセッションで用いられる各サーバに対して、並行して、サーバ速さ制御、帯域幅測定、及び帯域幅推定を実行するパスレート推定手段を含む。
【００２６】
本発明の一実施形態では、パスレート推定は周期的に繰り返される。
【００２７】
本発明の一実施形態では、パスレート推定は、それぞれのデータパスが現在のレートより高いレートでの送信を持ちこたえるか判断するため、再生要求にスピードＲＴＳ標準属性を付加することにより、各サーバのスピードを制御する。
【００２８】
本発明の一実施形態では、各サーバについて、現在のレートがスムージングアルゴリズムにより用いられ、信頼できる推定値を繰り返し決定し、前の繰り返し期間中に測定したビットレートから到達可能ビットレートを求める。
【００２９】
本発明の一実施形態では、各サーバについて、現在レートの分散を計算する。
【００３０】
本発明の一実施形態では、コントローラ手段は、それぞれのサーバにより配信される次のチャンクのビットレート選択を実行できるチャンクスケジューリング手段を含む。
【００３１】
本発明の一実施形態では、すべてのサーバの個別のビットレート推定値が合計され、合計ビットレートが求められ、チャンクの再生レートが合計ビットレートのすぐ下のエンコーディングビットレートに選択される。
【００３２】
本発明の一実施形態では、コントローラ手段は、正しい消費順序を実現するために、リンクされたリストから割り当てられたビンに、サーバの１つのチャンクをリンクできるビン割り当て手段を含む。
【００３３】
本発明の一実施形態では、コントローラ手段は、デコーダが複数のサーバから受信したストリームを単一のサーバから受信したストリームと区別できないように、ＲＴＰタイムスタンプとシーケンス番号とを更新できるＲＴＰリナンバリング及びリタイムスタンピング手段を含む。
【００３４】
本発明は、ＲＴＳＰ／ＲＴＰプロトコルを用いて既存のＩＰＴＶインフラストラクチャを利用しつつ、クライアントへのストリーミングレートに対する即時制御を提供するメカニズムを提案する。ＲＴＳＰ（ＲＦＣ２３２６）は、メディアストリーミングを確立して制御するプロトコルである。ＲＴＳＰは、データ自体のトランスポートプロトコルはカバーしておらず、トランスポートプロトコルとしては一般的にはＲＴＰが使われる。さらに、複数の通信パスの同時使用により、ネットワーク変動を補償し、全体的な受信レートと、それに伴うユーザ体験をスムーズにする。
【００３５】
本発明は、ファイルフォーマットも提案し、これにより、ＨＴＴＰアダプティブストリーミングと同様に、ビットレートが異なるバージョン間でのシームレスなスイッチングが可能である。
【００３６】
ＲＴＳＰプロトコルをうまく使うことにより、既存のサーバインフラストラクチャを変更することなく、マルチパス通信を活用して、ネットワーク状態をプローブし、クライアントによるストリーミングレートを制御できる。レガシーＩＰＴＶのようにストリーム全体を要求する替わりに、クライアントは、マルチパス通信の利益により、複数のサーバからストリームの独立な断片を受信する。ネットワーク輻輳のリスクを最小化するため、各サーバの個別の送信レートを調整する。
【００３７】
さらに、クライアントは、サーバに、通常レートより高いレートでストリームの小さいフラグメントをストリーミングし、自機とサーバとの間のネットワークのキャパシティを評価し、コンテンツのより重要なシェアを配信するように周期的に要求する。すべてのネットワークパスの合計キャパシティがより高いビットレートのストリームとするのに十分である場合、クライアントは、すべてのサーバに、ストリームのより高いビットレートのバージョンを選択する異なる要求を送信する。現在の再生レートにとってストリーム受信レートが遅すぎる場合、クライアントはサーバにコンテンツのより低いビットレートのバージョンを選択するように要求する。
【００３８】
本発明は、機器の置き換えを要さずに、ＲＴＳＰ／ＲＴＰに基づくプロトコルスイートと完全に互換的にすることにより、いわゆるＩＰＴＶ（管理された）環境おけるネットワーク変動を合わせる機能を追加する。さらに、複数のネットワークパスにより通信を配信することにより、単一のネットワークパスの急激な帯域幅変動を取り除くことができる。
【図面の簡単な説明】
【００３９】
以下の図面を参照して実施例により本発明をより詳細に説明する。
【図１】本発明の一実施形態による、マルチパス環境におけるアダプティブストリーミングのシステムを示す図である。
【図２】本発明の一実施形態による、マルチパス環境におけるアダプティブストリーミングのシステムを示す別の図である。
【図３】本発明の一実施形態によるクライアント・サーバ通信を示す図である。
【図４】本発明の一実施形態によるクライアント・サーバ通信を示す別の図である。
【図５】本発明の一実施形態によるクライアント・サーバ通信を示すさらに別の図である。
【図６】本発明の一実施形態によるクライアント・サーバ通信を示すさらに別の図である。
【図７】本発明の一実施形態によるクライアントを示す図である。
【発明を実施するための形態】
【００４０】
図中、別段の記載がなければ、同じ参照数字は同じパーツを指す。
【００４１】
具体的に、ここで図１を参照して、ここに実施される発明は、マルチパス環境におけるアダプティブストリーミングをするシステム１０を含む。このシステム１０は、クライアント１２と、このクライアント１２にそれぞれのデータパスによりＲＴＰ／ＲＴＳＰプロトコルでマルチメディアコンテンツを送信できる複数のサーバとを含む。クライアント１２は、ディスプレイを有するセットトップボックスとして図示されている。図１において、第１サーバ１４、第２サーバ１６、及び第３サーバ１８は一例であり、それぞれ第１パス２０、第２パス２２、及び第３パス２４によりクライアントに接続されている。
【００４２】
ほとんどのアダプティブストリーミング技術と同様に、コンテンツは、アダプティブ配信をサポートするように、複数のビットレートで事前エンコードされていなければならない。また、異なるバージョンのストリームは、「GOP aligned」である。これは、その異なるビットレートストリームの全てに対して、ストリームへのランダムアクセスを可能にする基準フレームの位置が同じ時間インスタントにあることを意味する。この特性により、デコーダは、ビジュアルアーティファクト無しに、あるロケーション（基準フレーム）において、異なるストリーム間を切り換えることができる。そして、クライアント１２は、これらのストリームバージョンのどれかのチャンクを要求／ダウンロードできる。チャンクは一組のＧＯＰであり、長さが一定で例えば２秒である。
【００４３】
このマルチビットレートは、利用可能なビットレートを列記したディスクリプションファイルとともに、サーバ１４、１６、１８に配信される。このディスクリプションファイルは、一般的なアダプティブストリーミングの実施形態で用いられているマニフェストファイルと同様である。本実施形態では、ディスクリプションファイルはＳＤＰファイルとして実施される。
【００４４】
図２はコンテンツの準備段階を示す。マルチメディアコンテンツ３０は、エンコーダ３２により、すべての基準フレームが、エンコードされた各ストリーム中の同じ時点に現れるとの付加的制約の下で、複数のビットレートでエンコードされる。あるビットレートから他のビットレートへの移行は各ＧＯＰより高い頻度で起こり得ることを考慮して、基準フレームのアライメントは、数十ミリ秒（本実施例では２秒）の周期で要求されうる。本実施形態では、コンテンツはＨ．２６４とＡＡＣコーデックを用いてエンコードされ、基準フレームは２秒ごとに現れ、ＭＰＥＧトランスポートストリームにカプセル化される。本実施形態を説明するために用いられるコンテンツ例は、次のトータルビットレートの組でエンコードされる：５００ｋｂｐｓ，１０００ｋｂｐｓ，１５００ｋｂｐｓ及び２０００ｋｂｐｓ。ストリームディスクリプションはＳＤＰプロトコルを用いて表される。
【００４５】
この例では、４つのＭＰＥＧ  ＴＳトラックが伝送され、そのビットレートはＳＤＰプロトコルのｂ＝ＴＩＡＳ属性を用いてアドバタイズされる。また、「X-altservers」属性が、クライアント１２に、コンテンツ３０を受信できる代替的ロケーションのリストを提供する。これらの代替的ロケーションは、まったく同じものを保持しているので、メインロケーションの替わりに用いてもよい。
【００４６】
ストリーミングセッションを制御する通常のＲＴＳＰ動作を図３に示す。第１のメッセージにより、クライアント１２はストリームの特性をディスカバリできる。第２のメッセージは、ＳＥＴＵＰと呼ばれ、ストリーミングセッションを準備し、ＰＬＡＹメッセージが最終的にサーバ１４に、マルチメディアストリームの送信を開始させる。
【００４７】
本発明では、クライアントは、ストリーミングセッション中に、あるストリームから他のストリームにスイッチする。この実施形態では、明瞭性のために、クライアントは、ストリーミングセッションの開始時に複数のSETUPメッセージを発行するものとする。トラックごとに１つの設定が行われる。しかし、明らかに、各トラックのＳＥＴＵＰメッセージは、クライアントがそのトラックを実際に受信する必要がある直前に、そのクライアントにより発行されてもよい。
【００４８】
このマルチトラック設定フェーズを図４に示す。ある最適化として、クライアント１２は、セッションの個別のトラックに対する別々のＳＥＴＵＰメッセージではなく、セッションのＵＲＬに対してＳＥＴＵＰメッセージも発行することにより、一度にすべてのトラックを設定してもよい。クライアント１２は、マルチサーバ動作をサポートするため、X-altservers属性に列記されたすべてのサーバに対してこの初期化フェーズを実行する。
【００４９】
すべてのトラックが設定されると、クライアント１２は、図５に示したように、所望のトラックの所望の時間区間に対するＰＬＡＹ要求を発行することにより、マルチメディアコンテンツの小さなチャンクを要求する
トラックは、ＳＤＰにあるトラックＩＤを用いて選択される。時間区間は、Ｒａｎｇｅ：ヘッダを用いてサーバに示される。例えば、時間区間２−４秒を選択するため、クライアントは次のヘッダを再生要求に負荷する：
PLAY
rtsp://multimedia.example.com/stream/trackID=1 RTSP/1.0 Range: npt=2-4
ストリームチャンク間のプレイアウト中断を避けるため、クライアントは、先に次のチャンクに対する新しいＲＴＳＰ  ＰＬＡＹ要求を発行し、プレイアウトバッファに十分なデータを維持する。我々の実施形態では、プレイアウトバッファは、予めダウンロードされた２秒分のマルチメディアストリームを含む。
【００５０】
マルチパス、マルチサーバ動作の場合、クライアント１２は、図６に示したように、異なるチャンクが、クライアントが推定したそのネットワークパスの容量に対応するレートで、各サーバ１４，１６及び１８から並行してストリーミングされることを要求する。
【００５１】
図７は、クライアント１２のマルチパス・マルチサーバ動作に適したコントローラ４０を示す。コントローラ４０は、各サーバとデータパスに対して、サーバ速さ制御、帯域幅測定、及び帯域幅推定を実行できるパスレート推定手段４２を含む。さらに、コントローラ４０は、それぞれのサーバにより配信される次のチャンクのビットレート選択を実行できるチャンクスケジューリング手段４４を含む。コントローラ４０は、さらに、正しい消費順序を実現するために、リンクされたリストから割り当てられたビンに、サーバの１つのチャンクをリンクできるビン割り当て手段４６を含む。コントローラ４０は、ＲＴＰリナンバリング・リタイムスタンピング手段を含む。また、受信したストリームを表示させる消費ユニット５０がある。
【００５２】
クライアント１２は、受信したこれらの複数のストリームを、１つのサーバから受信したストリームと同じになるように、すなわち、シーケンス番号とＲＴＰタイムスタンプが単調に増加するように、１つのストリームにアグリゲートする。このタスクには、異なるサーバから受信したＲＴＰパケットのバッファリングとリナンバリングが必要である。これは、図７に示したビン割り当て及びＲＴＰリナンバリングステップにより解決される。最後に、アグリゲートされたこのストリームは、クライアントのデコードバッファに入れられる。
【００５３】
パスレート（パスに対して利用可能なビットレート）は、各サーバ１４，１６及び１８に対して、及びそれに関連するネットワークパス２０，２２及び２４に対して、独立にパスレート推定手段４２により推定される。以下に説明するプロセスは、マルチパスストリーミングセッションで用いられる各サーバに対して、並行して実行される。
【００５４】
帯域幅推定プロセスは次のステップよりなる。第１に、サーバ速さ制御を行う。したがって、サーバ１４，１６及び１８の送信スピードは、ネットワークパス２０，２２及び２４の実際に利用可能なビットレートを測定するクライアント１２により管理される。第２に、帯域幅測定を行う。したがって、現在のチャンクのために現在のネットワークビットレートを決定するために、サーバ１４，１６及び１８の送信スピードと比較したクライアント１２により受信されるストリームの特性が決定される。第３に、帯域幅推定を行う。個別の帯域幅測定値をスムーズにして、続くチャンクを選択するのに使える正確な値を求める。
【００５５】
サーバの送信スピードは、ネットワークの実際に利用できるビットレートを測定するため、クライアントにより管理される。
【００５６】
帯域幅測定は、現在のチャンクのために現在のネットワークビットレートを決定する、サーバ送信スピードと比較したクライアントにより受信されたストリームの特性の決定にある。
【００５７】
帯域幅推定は、後続のチャンクを選択するのに使える正確な値を求めるために、個別の帯域幅推定値をスムーズにする点にある。
【００５８】
帯域幅推定プロセス全体は、周期的に繰り返えされるが、ネットワーク状態が非常にゆっくりと変化する場合には、必ずしもチャンクごとに繰り返す必要はない。
【００５９】
有利にも、最も遅いパスを用いて時間的に「遅く（far）」レンダリングされるチャンクを取得し、最も早いパスを用いて「すぐに」レンダリングされるチャンクを取得することができる。
【００６０】
サーバ１４，１６及び１８のスピードは、PLAY要求に既に標準となっている属性「Speed」を付加することにより、制御される。サーバスピードを修正するということの背景にあるアイデアは、ネットワークが、現在のレートより高いレートでの送信を維持するかどうか判断することである。図６と図７の実施形態では、クライアント１２は、ネットワークのキャパシティを定期的に検知して、サーバに、現在のスピードの１．２倍のスピードでチャンクを送信するように依頼して、２０％速く送信する。
【００６１】
ＲＴＳＰ要求の一例は：
PLAY
rtsp://multimedia.example.com/stream/trackID=1 RTSP/1.0
CSeq: 833
Range:npt=2-4
Speed: 1.2
サーバは、上記の要求に対して次のように応答する：
RTSP/1.0 200 OK
CSeq: 834
Range:npt=2-4
RTP
Info:url=rtsp://multimedia.example.com/stream/trackID=1;seq=45102;rtptime=12345678
ｒｔｐｔｉｍｅと呼ぶパラメータは、選択されたｎｐｔレンジの開始に対応するＲＴＰタイムスタンプを示す。クライアントは、クロックレートを用いて、要求されたチャンクに対応するrtptimeレンジを決定する。現在のビットレートＢｉを計算するため、クライアント１２は、上記のrtptimeインターバルに受信したＲＴＰパケットバイトを合計する。これを、（最初に受信したバイトと最後に受信したバイトの間の）そのバイトの伝送時間で割る。
【数１】
0006308718.tif 000002
この現在のビットレートをスムージングアルゴリズムで用いて、信頼できる推定をする。この実施形態で用いるアルゴリズムは、反復的であり、前の繰り返しで測定されたビットレートから達成可能なビットレートを求めようとするものである。
【００６２】
次の繰り返しの平均ビットレートは、次の式に示すように、現在のビットレート平均と現在の測定値の重み付け平均として計算される。
【数２】
0006308718.tif 000003
ここで、Ｂｉは測定されたビットレートであり、ａｖｇｉは現在の繰り返しについて計算された平均ビットレートであり、αは現在のビットレート測定値に与えられる重みである。一例では、重みはα＝１／１６と選択される。
【００６３】
このアルゴリズムは、平均ビットレートに加えて、ビットレートの分散を推定する。分散は、以下の通り、ビットレートと同様にスムージングされる：
【数３】
0006308718.tif 000004
ここで、Δｉは測定ビットレートと現在の繰り返しにおける平均ビットレートとの間の差分であり、ｖａｒｉは現在の推定について計算される分散であり、βは現在の分散測定値に与えられる重みである。プロトタイプの実施形態では、βは１／８とした。
【００６４】
各繰り返しに対して、現在の推定値（または到達可能ビットレート）は次のように計算される：
【数４】
0006308718.tif 000005
これは、分散が大きいと、クライアント１２は平均帯域幅より非常に狭い帯域幅を用いることを意味する。一方、帯域幅が安定していて、分散が小さい場合、クライアント１２は、そのリンクで利用可能な全帯域幅を用いるように収束する。
【００６５】
推定がリセットされる２つの例外的な場合を検討する：すなわち、分散が大きすぎる（例えば、平均ビットレートの半分より大きい）場合、または、ＲＴＰシーケンス番号が不連続である（すなわち、ＲＴＰパケットを喪失した）場合である。
【００６６】
上記の場合、平均と分散の推定値は次のようにリセットされる：
【数５】
0006308718.tif 000006
ＲＴＰが不連続になると、問題のパス／サーバのために新しいビットレート推定が行われ、及び／又は以前にスケジューリングされたチャンクすべてのリスケジューリングが行われる。
【００６７】
サーバとチャンクのスケジューリングは、サーバ及びチャンクスケジューリング手段４４により行われる。クライアント１２は、あるサーバの要求したチャンクの受信が終わるたびに（サーバはアイドル状態となる）、そのサーバの帯域幅推定を更新し、再度その接続を用いて他のチャンクを読み出す。すべてのサーバパスの利用可能性と相対的ビットレートとに応じて、サーバ接続を用いて、再生する次のチャンクや後で再生するチャンクを読み出すことができる。スケジューリングアルゴリズムを以下に説明する。
【００６８】
第１に、サーバ及びチャンクスケジューリング手段４４が次のチャンクのビットレートを選択する。そうするため、すべてのサーバは並行して使われるので、サーバ及びチャンクスケジューリング手段４４は、すべてのサーバ１４，１６，及び１８の個々のビットレート推定値（下記参照）を合計し、合計ビットレートを求める。選択されたチャンクの再生レートは、合計ビットレート以下のエンコーディングビットレート（the encoding bit rate immediately inferior to the aggregate bit rate）である。
【００６９】
デコーダバッファが空になる時間ｔｅにおいて、最初に、現在の再生及びストリーミングのパラメータを用いて、各サーバ１４，１６，及び１８のチャンク到着時間を計算する：ａｋはパスｋがアイドルになる（最後の又はスケジューリングされたチャンクの受信が終了する）時間であり、ｄはチャンクの長さであり、Ｂは再生ビットレートであり、Ｂｋはサーバ／パスｋの現在のビットレート推定値である。サーバｋから次のチャンクをダウンロードするのにかかる時間をＤｋとすると、Ｄｋ＝ｄ×Ｂ／Ｂｋである。サーバｋを用いる場合、チャンクの到着時間は：Ｒｋ＝ａｋ＋Ｄｋ
アルゴリズムは、Ｒｋが最低になるサーバを選択する。また、チャンクの到着時間は、デコーダバッファが空になる時間（ｔｅ）より早くなければならず、すなわちＲｋ＜ｔｅが満たされなければならない。そうしないと、バッファが空になり、再生に中断が生じてしまう。かかる場合、再生ビットレートは次に低いビットレートに下げられる。到着時間の条件が満たされる場合、サーバｋにおけるチャンク読み出しがスケジューリングされる。送信レートは、サーバ／パスｋの現在のビットレートの推定値と一致するように調整しなければならない。これは、ＲＴＳＰ  ＰＬＡＹ要求のＳｐｅｅｄ：ヘッダを用いてＳｐｅｅｄ＝Ｂｋ／Ｂとして行う。
【００７０】
例えば、再生レートＢが１Ｍｂｐｓであり（ｔｒａｃｋＩＤ１が再生されている）、現在のビットレートの推定値Ｂｋは４００ｋｂｐｓと仮定すると、Ｓｐｅｅｄ＝０．４となる。ちなみに、現在のチャンクに対して定期的帯域幅推定プロセスがトリガーされると、得られるスピードを１．２倍にする。
【００７１】
以下は、サーバｋに送信される対応する要求である。
PLAY
rtsp://multimedia.example.com/stream/trackID=1 RTSP/1.0
CSeq: 838
Range:npt=40-42
Speed: 0.4
現在サーバがアイドル状態にあると、ＲＴＳＰ要求が続けてすぐに発行される。さもなければ、サーバが使用中の時は、サーバがアイドル状態になるまで、ＲＴＳＰ要求は遅らされる。
【００７２】
最後に、新しいチャンクがバッファにプッシュされ、それゆえ値ｔｅがチャンクの長さ（ｄ）だけインクリメントされる：ｔｅ＝ｔｅ＋ｄ。いずれかのサーバがアイドルであれば、すべてのサーバ１４，１６，及び１８がビジーになるまで、前のステップが繰り返される。さもなければ、サーバ及びチャンクスケジューリング手段４４は、サーバが再びアイドル状態になるのを待つ。
【００７３】
ビン割り当て手段４６によりビン割り当てがなされる。サーバ１４，１６，及び１８に向けてチャンクを求める要求が送信されるたびに、リンクされたリストから割り当てられたビンに応答がリンクされ、正しい消費順序を保証する。すなわち、リストのヘッドが、デコーダに与えられる次のパケットを含むビンである。リストのテールは、デコードする最後のパケットを含むビンである。
【００７４】
ＲＴＰリナンバリング・リタイムスタンピング手段４８により、ＲＴＰリナンバリングとリタイムスタンピングが行われる。ビデオデコーダ／デマルチプレクサに配信される最後のＲＴＰストリームを規格化する必要がある。サーバ１４，１６，及び１８に送信される各要求ごとに、正しい消費順序で、受信ビンが割り当てられている。その要求に対応するＲＴＰパケットが受信されると、デコーダが、複数のサーバから受信したストリームを１つのサーバから受信したストリームと区別できないように、ＲＴＰタイムスタンプとシーケンス番号が更新される。
【００７５】
実際には、すべてのパケットのシーケンス番号とＲＴＰタイムスタンプは、デコーディングバッファに格納するのに用いた最後のシーケンス番号とＲＴＰタイムスタンプで始まるように、利ナンバーされる。
【００７６】
したがって、本発明により、ＲＴＳＰ／ＲＴＰプロトコルスイートに適用されるマルチパスアダプティブストリーミングができる。ＲＴＳＰプロトコルのＳｐｅｅｄパラメータをうまく使うことにより、複数のサーバを並行して使用でき、ネットワークの状態を検知できる。クライアントによる複数のＲＴＳＰサーバの並行使用により、変化するネットワーク状態に素早く反応して、ユーザ体験を最大化できる。本発明は、ＩＰＴＶインフラストラクチャに用いられる既存のＲＴＳＰ／ＲＴＰに適用できる。
【００７７】
言い換えると、本発明の好ましい実施形態に対応するシステムは、複数のサーバ１４，１６，１８を有するネットワーク環境において、マルチパスアダプティブストリーミング技術を用いてオーディオビジュアルコンテンツを伝送するシステムであり、各サーバはそれぞれのデータパス２０，２２，２４により、クライアント１２に、ＲＴＰ／ＲＴＳＰ準拠の通信プロトコルに基づき、前記マルチメディアコンテンツを伝送するように構成され、クライアント１２は、各データパス２０，２２，及び２４に関連するそれぞれの帯域幅を決定し、決定した帯域幅により各サーバ１４，１６，及び１８に前記マルチメディアコンテンツのチャンクを要求するために、前記各データパス２０，２２，及び２４をプローブできる。
【００７８】
コントローラ４０は、各サーバ１４，１６，１８とクライアント１２との間の各データパス２０，２２，２４の利用可能ビットレートを推定する手段４２を含み、サーバ１４，１６，１８のサーバスピード制御を行うように構成されている。
【００７９】
また、コントローラ４０は、利用可能なビットレートにより、それぞれのサーバ１４，１６，１８により配信される次のチャンクを選択するチャンク選択手段４４を含む。
【００８０】
コントローラ４０は、さらに、クライアント（レシーバ）側において正しい消費順序を実現するために、リンクされたリストから割り当てられたビンに、サーバ１４，１６，１８の１つのチャンクをリンクするように構成されたビン割り当て手段４６を含む。
【００８１】
１つのコヒーレントストリームを構成するため、コントローラ４０は、ＲＴＰタイムスタンプとシーケンス番号を更新するＲＴＰリナンバリング及びリタイムスタンピング手段４８を含む。これにより、例えば、１つのサーバから受信したかのように、クライアント側で単一のコヒーレントストリームを形成できる。
【００８２】
本発明の好ましい実施形態により用いられる方法は、マルチパス環境におけるアダプティブストリーミングの方法であって、
−クライアントを設けるステップと；
−複数のサーバ１４，１６，１８であって、それぞれがクライアントにそれぞれのデータパス２０，２２，２４により、ＲＴＰ／ＲＴＳＰ環境で、マルチメディアコンテンツを送信するように構成された複数のサーバ１４，１６，１８を設けるステップとを有し、クライアント１２は、各データパス２０，２２，及び２４に関連するそれぞれの帯域幅を決定し、それぞれ決定した帯域幅により各サーバ１４，１６，及び１８にマルチメディアコンテンツのチャンクを要求するために、各データパス２０，２２，及び２４をプローブするコントローラ４０を含む。
【００８３】
コントローラは、マルチパスストリーミングセッションで用いられる各サーバ１４，１６，１８について、サーバ１４，１６，１８におけるサーバスピード制御と、帯域幅測定と、帯域幅推定とを並行して行うために、パスのビットレート推定手段４２を含む。
【００８４】
他の好ましい一実施形態では、パスのビットレート推定は周期的に繰り返される。
【００８５】
パスのビットレート推定４２は、再生要求にスピードＲＴＳ標準属性を付加することにより、対応するサーバ１４，１６，１８のスピードを制御するステップを有する。
【００８６】
各サーバ１４，１６，１８について、現在のレートがスムージングアルゴリズムにより用いられ、推定値を繰り返し決定し、前の繰り返し期間中に測定したビットレートから到達可能ビットレートを求める。
【００８７】
各サーバ１４，１６，１８について、現在レートの分散を計算する。
【００８８】
コントローラ手段４０は、それぞれのサーバ１４，１６，１８により配信される次のチャンクのビットレート選択を行うチャンクスケジューリング（又はチャンク選択）手段４４を含む。
【００８９】
すべてのサーバの個別のビットレート推定値が合計され、合計ビットレートが求められ、チャンクの再生レートが合計ビットレートのすぐ下のエンコーディングビットレートに選択される。
【００９０】
本発明の主要要素は、（ＨＴＴＰストリーミングとは対照的に）標準的ＲＴＳＰプロトコルと、それゆえの既存エコシステムの再利用と、標準的ＳＤＰによるコンテンツの複数のバージョンのシグナリング（新しい属性が複数のサーバ上のコンテンツの利用可能性を示す）と、ＲＴＳＰシグナリングによる複数のサーバ及び複数のネットワークパスの同時動作と、ＲＴＳＰプロトコルに基づく個別のネットワークパス上の利用可能帯域幅の連続的評価と、予想配信方式に基づく複数のパス上のデータレートの連続的バランシングである。
【００９１】
本発明のある実施形態のみをここに説明したが、当業者には言うまでもないが、本発明のその他の修正、変形、実現性が可能である。それゆえ、かかる修正、変形、及び実現性は、本発明の精神と範囲内にあり、ここに説明し及び／又は例示した本発明の一部を形成すると考えるべきである。
【００９２】
本発明を、好ましい実施形態で説明したので、発明力を行使しなくとも、当業者の能力内で多くの修正と実施形態を考えることができることは明らかである。したがって、本発明の範囲は下記の特許請求の範囲により画定される。
【００９３】
ここに記載したすべての例と条件付きの言葉は、発明者が技術発展に対してなした本発明の原理とコンセプトとを、読者が理解しやすいようにするためのものであり、その解釈は具体的に記載した実施例や条件に限定されるべきではない。
【００９４】
さらに、本原理の原理、態様、実施形態、及びその実施例のすべての記載は、その構成的等価物及び機能的等価物の両方を含むものである。また、かかる等価物は、現在知られている等価物及び将来開発される等価物を含み、すなわち、構成にかかわらず同じ機能を発揮する開発されるすべての要素を含む。
【００９５】
よって、例えば、当業者には言うまでもなく、ここに説明したブロック図は本原理を化体する回路を概念的に示すものである。同様に、言うまでもなく、フローチャート、フロー図、状態遷移図、擬似コード等は、様々な方法（processes）を表し、これらの方法をコンピュータ読み取り可能媒体に実質的に表しても、（明示的に示していようがいまいが）コンピュータやプロセッサで実行してもよい。
【００９６】
図示した様々な要素の機能は、専用ハードウェアを用いても、ソフトウェアを実行可能なハードウェアと適当なソフトウェアとを組み合わせても提供できる。プロセッサを設けるとき、機能を単一の専用プロセッサで提供してもよいし、共有された単一のプロセッサで提供してもよいし、一部が共有された複数の個別プロセッサで提供してもよい。さらに、「デコーダ」、「コントローラ」、「スケジューラ」、「推定器」という用語又はこれらの等価表現を明示的に使用した場合、ソフトウェアを実行できるハードウェアのみを指すと解釈してはならず、限定はされないが、デジタルシグナルプロセッサ（ＤＳＰ）ハードウェア、ソフトウェアを記憶するリードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、及び不揮発性記憶装置を黙示的に含んでもよい。
【００９７】
その他のハードウェアを従来のものでもカスタムのものであっても含んでもよい。同様に、本明細書中に記載したスイッチングは、プログラムロジックの動作、専用ロジックの動作、プログラム制御や専用ロジックのインターラクションで実行されてもよく、具体的な方法は実施者が状況に応じて判断して選択できる。
【００９８】
請求項において、特定の機能を実行する手段として表した要素は、その機能を実行するいかなる方法も含み、例えば、ａ）その機能を実行する回路要素の組合せと、ｂ）ファームウェアやマイクロコード等を含む任意の形式のソフトウェア及びそれと組み合わせたその機能を実行する適当な回路とを含む。請求項に記載した本原理は、記載した様々な手段が提供する機能を、請求項に記載したように組み合わせることにある。よって、これらの機能を提供できる手段はどれでも、ここに示したものと等化であると見なせる。
【００９９】
明細書において、本発明の「一実施形態」、またはそのバリエーションと言う場合、本発明の少なくとも１つの実施形態に含まれるその実施形態に関して説明する具体的な特徴、構造、特性などを意味する。それゆえ、本明細書を通していろいろなところに記載した「一実施形態において」またはそのバリエーションは、必ずしもすべてが同じ実施形態を参照するものではない。
【０１００】
言うまでもなく、本原理は、ハードウェア、ソフトウェア、ファームウェア、特殊用途プロセッサ、またはこれらの組み合わせなどのいろいろな形体で実施することができる。好ましくは、本原理は、ハードウェアとソフトウェアを組み合わせて実施できる。また、プログラム記録装置に有体的に化体されたアプリケーションプログラムとしてソフトウェアを実施してもよい。そのアプリケーションプログラムは、好適なアーキテクチャを有する機械にアップロードされ、実行される。好ましくは、機械は、中央処理装置（ＣＰＵ）、ランダムアクセスメモリ（ＲＡＭ）、及び入出力（Ｉ／Ｏ）インターフェイス等のハードウェアを有するコンピュータプラットフォームで実施される。コンピュータプラットフォームはオペレーティングシステムとマイクロコードも含んでもよい。ここに説明した様々なプロセスや機能は、オペレーティングシステムにより実行できる、マイクロ命令コードの一部やアプリケーションプログラムの一部（またはこれらの組み合わせ）であってもよい。また、追加的データ記憶装置や印刷装置等その他の様々な周辺装置をコンピュータプラットフォームに接続してもよい。
【０１０１】
さらに言うまでもなく、添付した図面に示したシステム構成要素や方法ステップの一部はソフトウェアで実施されてもよいので、システム構成要素（または方法ステップ）間の実際的な結合は本原理をプログラムするそのプログラム方法に応じて異なる。ここに開示された教示を受けて、関連技術分野の当業者は、本原理の同様な実施形態や構成を考えることができるであろう。
実施形態について、次の付記を記す。
（付記１）  複数のサーバを有するネットワーク環境においてマルチパスアダプティブストリーミングを用いてオーディオビジュアルコンテンツを伝送するシステムであって、
各サーバはそれぞれのデータパスにより、クライアントに、ＲＴＰ／ＲＴＳＰ準拠通信プロトコルに基づき、前記マルチメディアコンテンツを伝送するように構成され、
前記クライアントは、各データパスに関連するそれぞれの帯域幅を決定し、決定したそれぞれの帯域幅により各サーバに前記マルチメディアコンテンツのチャンクを要求するために、前記各データパスをプローブできるコントローラを含むことを特徴とする、システム。
（付記２）  前記コントローラは、各サーバと前記クライアントとの間の各データパスの利用可能ビットレートを推定する手段を含み、サーバスピード制御を行うように構成されたことを特徴とする、
付記１に記載のシステム。
（付記３）  前記コントローラは、利用可能なビットレートにより、それぞれのサーバにより配信される次のチャンクを選択するチャンク選択手段を含むことを特徴とする、
付記１または２に記載のシステム。
（付記４）  前記コントローラは、正しい消費順序を実現するために、リンクされたリストから割り当てられたビンに、前記サーバの１つのチャンクをリンクするように構成されたビン割り当て手段を含むことを特徴とする、
付記１ないし３いずれか一項に記載のシステム。
（付記５）  前記コントローラは、単一のコヒーレントストリームを構成するために、ＲＴＰタイムスタンプとシーケンス番号を更新するＲＴＰリナンバリング及びリタイムスタンピング手段を含むことを特徴とする、
付記１ないし４いずれか一項に記載のシステム。
（付記６）  マルチパス環境におけるアダプティブストリーミングの方法であって、
−クライアントを設けるステップと；
−複数のサーバであって、それぞれが前記クライアントにそれぞれのデータパスにより、ＲＴＰ／ＲＴＳＰ環境で、マルチメディアコンテンツを送信するように構成された複数のサーバを設けるステップとを有し、
前記クライアントは、各データパスに関連するそれぞれの帯域幅を決定し、決定したそれぞれの帯域幅により各サーバに前記マルチメディアコンテンツのチャンクを要求するために、前記各データパスをプローブするコントローラを含むことを特徴とする、方法。
（付記７）  前記コントローラは、マルチパスストリーミングセッションで用いられる各サーバについて、サーバスピード制御と、帯域幅測定と、帯域幅推定とを並行して行うために、パスビットレート推定手段を含むことを特徴とする、
付記６に記載の方法。
（付記８）  パスビットレート推定は周期的に繰り返されることを特徴とする、
付記７に記載の方法。
（付記９）  パスビットレート推定は、再生要求にスピードＲＴＳ標準属性を付加することにより、対応するサーバのスピードを制御することを特徴とする、
付記７または８に記載の方法。
（付記１０）  各サーバについて、現在のレートがスムージングアルゴリズムにより用いられ、推定値を繰り返し決定し、前の繰り返し期間中に測定したビットレートから到達可能ビットレートを求めることを特徴とする、
付記９に記載の方法。
（付記１１）  各サーバについて、現在レートの分散を計算することを特徴とする、
付記９に記載の方法。
（付記１２）  前記コントローラは、それぞれのサーバにより配信される次のチャンクのビットレート選択を行えるチャンクスケジューリング手段を含むことを特徴とする、
付記６ないし１１いずれか一項に記載の方法。
（付記１３）  すべてのサーバの個別のビットレート推定値が合計され、合計ビットレートが求められ、チャンクの再生レートが合計ビットレートのすぐ下のエンコーディングビットレートに選択されることを特徴とする、
付記１２に記載の方法。
（付記１４）  前記コントローラは、正しい消費順序を実現するために、リンクされたリストから割り当てられたビンに、前記サーバの１つのチャンクをリンクするビン割り当て手段を含むことを特徴とする、
付記６ないし１１いずれか一項に記載の方法。
（付記１５）  前記コントローラは、単一のコヒーレントストリームを構成するために、ＲＴＰタイムスタンプとシーケンス番号を更新するＲＴＰリナンバリング及びリタイムスタンピング手段を含むことを特徴とする、
付記６ないし９いずれか一項に記載の方法。
【図１】
0006308718.tif 000007
【図２】
0006308718.tif 000008
【図３】
0006308718.tif 000009
【図４】
0006308718.tif 000010
【図５】
0006308718.tif 000011
【図６】
0006308718.tif 000012
【図７】
0006308718.tif 000013