適応ストリーミングクライアントの操作を遠隔管理する方法
【課題】サーバと受信機フィールドとの間の伝送データレートを制御する方法を提供する。
【解決手段】サーバ１は、視聴覚コンテンツを表すデータを送信するように適応され、視聴覚コンテンツは、前記サーバ１から少なくとも２つのバージョンで入手可能であり、バージョンはそれぞれ、異なる伝送ビットレートに対応し、サーバ１は、視聴覚コンテンツを連続した部分で送信するように適応され、連続した部分はそれぞれ、受信機４、６、８によって送られた送信要求に応答して少なくとも２つのバージョンのうちの１つとして選択され、前記送信要求は送信パラメータを備え、この方法は、コントローラ２によって受信機４、６、８から監視情報を受信するステップと、コントローラ２から受信機４、６、８に制御パラメータを送信するステップとを備える。
【解決手段】サーバ１は、視聴覚コンテンツを表すデータを送信するように適応され、視聴覚コンテンツは、前記サーバ１から少なくとも２つのバージョンで入手可能であり、バージョンはそれぞれ、異なる伝送ビットレートに対応し、サーバ１は、視聴覚コンテンツを連続した部分で送信するように適応され、連続した部分はそれぞれ、受信機４、６、８によって送られた送信要求に応答して少なくとも２つのバージョンのうちの１つとして選択され、前記送信要求は送信パラメータを備え、この方法は、コントローラ２によって受信機４、６、８から監視情報を受信するステップと、コントローラ２から受信機４、６、８に制御パラメータを送信するステップとを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般には、ビデオストリーミングコンテンツ配信に関し、より詳細には、サーバと受信機の間のビデオストリーミングによって使用される帯域幅を扱うことに関する。
【背景技術】
【０００２】
このセクションは、下記に述べられ、かつ／または特許請求される本発明の様々な態様に関し得る技術の様々な態様を読者に紹介するためのものである。この議論は、本発明の様々な態様についてより理解を促すために背景情報を読者に提供する助けとなると考えられる。したがって、これらの説明は、従来技術を認めるものとしてではなく、この観点から読むべきである。
【０００３】
メディア配信ストリーミングのソリューショは主として、ＩＴＥＦ ＲＦＣ ２３２６に定義されたリアルタイムストリーミングプロトコル（ＲＴＳＰ）、ＭｉｃｒｏｓｏｆｔからのＭｉｃｒｏｓｏｆｔ Ｍｅｄｉａ Ｓｅｒｖｅｒ（ＭＭＳ）プロプライエタリプロトコル、またはＡｄｏｂｅ ＳｙｓｔｅｍｓからのＲｅａｌ Ｔｉｍｅ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ（ＲＴＭＰ）プロプライエタリプロトコルなどのプロトコルに基づく。
【０００４】
インターネットを介したコンテンツ配信を可能にするために、ＨＴＴＰプロトコルに基づくストリーミング技法が現れた。これらの技法は、チャンクと呼ばれる、数秒の長さの連続した小さいセグメントの形式でビデオをクライアントデバイスが受信することを可能にする。それぞれのセグメントは、ＨＴＴＰプロトコルを介して要求され、様々な変形で存在することができ、ネットワークおよびそれ自体の制約に一致する適切なビットレートをクライアントデバイスがいつでも選ぶことを可能にする。それぞれ異なるビットレートは、配信されるコンテンツのそれぞれ異なる品質レベルに対応する。クライアントデバイスは、それが測定したネットワーク帯域幅が減少するとすぐに、ネットワーク帯域幅条件に対してそれほど制限的でないチャンクを要求する。クライアントデバイスは、それが測定したネットワーク帯域幅が増加する場合は、ネットワーク帯域幅条件に対してより制限的なチャンクを要求する。
【０００５】
使用可能なチャンクは一般に、ストリーミングサーバによって生成され提供されたプレイリスト内にリストされる。プレイリストは、フォーマットのタイプごとに１つなど、他のプレイリストを指すことができる。プレイリストは、コーデックや、プレイリストをダウンロードするのに必要な帯域幅など、チャンクの内容、およびプレイリストを要求する方法について記述する。プレイリストフォーマットは、様々なＳＶＣ層について記述するコーデック情報で拡張された、文献「HTTP Live Streaming draft, pantos, http-live-streaming, 06」に記載されたフォーマットとすることができる。
【０００６】
様々なＨＴＴＰストリーム技法が使用可能である。Ａｐｐｌｅ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）は、ドラフトＲＦＣとして発行されており、主としてＡｐｐｌｅデバイスで使用されている。Ｍｉｃｒｏｓｏｆｔ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇは、Ｍｉｃｒｏｓｏｆｔ Ｓｉｌｖｅｒｌｉｇｈｔプラットフォームの一部であり、仕様書は、公的に入手可能である。Ａｄｏｂｅ Ｏｐｅｎ Ｓｏｕｒｃｅ Ｍｅｄｉａ Ｆｒａｍｅｗｏｒｋ（ＯＳＭＦ）は、Ｍｉｃｒｏｓｏｆｔソリューションに近いものである。３ＧＰＰは、パケット交換ストリーミング（ＰＳＳ）システムの仕様を公開している。Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）の定義に関しては、ＭＰＥＧワーキンググループも作成されている。これらのストリーミングソリューションにおいてＨＴＴＰプロトコルを使用する利点は、それがＮＡＴとファイアウォールをシームレスに横断できることである。これらのＨＴＴＰストリーミング技術は、帯域幅制約に適合するためにビデオ品質を連続的かつ体裁よく（ｇｒａｃｅｆｕｌｌｙ）アップグレードまたはダウングレードすることによって、使用可能な帯域幅に関する不安定なネットワークの動作を補償する方法を提供する。
【０００７】
一般的なＨＴＴＰでは、諸ストリーム技法は、同じ概念に基づく。諸ストリーム技法は、プレイリストファイルフォーマット、コンテンツオプション（ビットレート、画像寸法、フレーム率…）を示すために提供されるメタデータ、セグメント内のコンテンツの使用可能な表現の構成、サポートされるコーデック、およびコンテンツ保護技術がそれぞれ異なっている。
【０００８】
クライアントデバイスは、何らかのオーディオ／ビデオコンテンツを再生したい場合、この特定のコンテンツをどのように取得できるか示すファイルをまず取得しなければならない。これは、ＨＴＴＰを介して、ＵＲＬから何らかの「ファイル」を取得することによって行われる。このファイルは基本的に、（ビットレートおよび他の特性に関する）コンテンツの使用可能な表現をリストし、またコンテンツごとに、各タイムスライスの間にコンテンツセグメントのロードを可能にするＵＲＬをリストする。たとえばビデオオンデマンドのコンテンツでは、映画の全記述が提供されるが、ライブ放送のコンテンツでは、記述は、短期間だけをカバーし、時間が経過するときに、新しいアイテムを発見するために周期的に再ロードする必要がある。
【０００９】
クライアントデバイスは、その能力、およびそれがネットワーク環境から得る知識に応じて、（典型的にはそのビットレートに基づいて）何らかの表現を選択し、コンテンツの第１のセグメント（複数可）をロードする。クライアントデバイスは、ネットワーク障害に対処可能である数個のセグメントをバッファリングする。次いで、受信された各セグメントからのコンテンツが、次々に再生される。同時に、クライアントデバイスは、受信レートを測定し、より高いまたは低いビットレートにすることを決定することができる。こうした場合、クライアントデバイスは、別の表現からの次のセグメント（複数可）を単に要求する。あらゆるＨＴＴＰストリーミングシステムは、あるビットレートのセグメントから別のビットレートの「次の」セグメントに進みながら、クライアントが連続再生し続けるというものである。
【００１０】
このように、ネットワーク上のトラフィックによってコンテンツ受信のレートの変化がもたらされる場合、クライアントは、安全なレベルにまでクライアントバッファの充填を維持することを可能にするビットレートを有するセグメントを選択することによって反応することができる。実際に、クライアントは通常、よりよい表示品質を提供するために、またマクロブロックまたはピクチャのフリーズを引き起こすデータ受信の遅れをレンダリングが受けないレベルにとどまるために、できるだけ高いビットレートに達しようと試みる。
【００１１】
ネットワークでは、複数のクライアントデバイスが、ＨＴＴＰストリーミングを同時に実行することができる。ネットワークまたはブロードバンドネットワークで使用可能な帯域幅がトラフィック全体をサポートするのに十分でない場合、クライアントデバイスは、使用可能な帯域幅の分配を得ようと競合する。ＨＴＴＰストリーミングアルゴリズムは、各デバイスで独立に実行され、帯域幅の最適な分配を提供できない。以下の状況が生じることがある。ビデオストリームのうちの１つが高い一定のビットレートを使用し、別のビデオストリームが低いビットレートにとどまるので、帯域幅の分配は不公平となり得る。あるいは、各デバイスが高ビットレートおよび低ビットレートを二者択一的に使用する変動（ｏｓｃｉｌｌａｔｉｏｎ）が生じることがある。それらのデバイスは時々、それが不都合と判断するネットワーク状態に同時に過剰反応して、結果として、各デバイスについて非常に低いビットレートが選択され、帯域幅が大きく浪費されることがある。それは、十分な帯域幅が使用可能な場合でも生じることがあり、ＨＴＴＰプロトコルの基礎となるＴＣＰ機構は、各ストリームのパケット受信が暗黙的競合を受けることがあり、これによって、不変の不公平な状況または永続的な変動という同じ結果がもたらされる。こうした振舞いは、表示されるビデオ品質が、使用されたビットレートに関連しているので、エンドユーザの体験の品質に直接影響を及ぼす。
【先行技術文献】
【非特許文献】
【００１２】
【非特許文献１】HTTP Live Streaming draft, pantos, http-live-streaming, 06
【非特許文献２】CPE WAN Management Protocol v1.1, Issue 1, Amendment 2、2007年12月2日
【発明の概要】
【課題を解決するための手段】
【００１３】
本発明は、ストリーミングコンテンツを受信する多くの受信機間の帯域幅分配に対処することによって、従来技術の適応ストリーミングにおける帯域幅分配に関連する問題の少なくとも一部を取り除こうとするものである。
【００１４】
本発明は、サーバと少なくとも２つの受信機との間の伝送データレートを制御するための方法に関する。サーバは、視聴覚コンテンツを表すデータを送信するように適応される。サーバ上に格納された視聴覚コンテンツは、少なくとも２つのバージョンでサーバから入手可能である。バージョンはそれぞれ、異なる伝送ビットレートに対応する。サーバは、連続した部分の視聴覚コンテンツを送信するように適応される。連続した部分はそれぞれ、受信機によって送られた送信要求に応答して、少なくとも２つのバージョンのうちの１つとして選択される。送信要求は、送信パラメータを備える。有利なことに、この方法は、
コントローラによって第１の受信機から第１の監視情報を受信するステップであって、第１の監視情報は、第１の受信機による視聴覚コンテンツのレンダリングを表す、ステップと、
コントローラによって第２の受信機から第２の監視情報を受信するステップであって、第２の監視情報が、第２の受信機による視聴覚コンテンツのレンダリングを表す、ステップと、
コントローラから受信機のうちの少なくとも１つに制御パラメータを送信するステップであって、パラメータが、制御パラメータから、送信パラメータまたは受信パラメータを定義するために第１の監視情報および第２の監視情報から定義される、ステップと、
を含む。
【００１５】
本発明の一実施形態によれば、第１の監視情報および第２の監視情報のそれぞれは、
サーバと少なくとも２つの受信機のうちの１つとの間のデータ伝送ビットレートと、
少なくとも２つの受信機のうちの１つの受信機のデータ受信バッファのサイズと、
少なくとも２つの受信機のうちの１つによる視聴覚コンテンツのレンダリングの品質指標と、
少なくとも２つの受信機のうちの１つが所与の時間間隔の間にバージョンのうちのあるバージョンからバージョンのうちの別のバージョンに切り換わる回数と、
定義された時間間隔の間に少なくとも２つの受信機のうちの１つによって受信されたバイト数と、
視聴覚コンテンツの少なくとも２つのバージョンのそれぞれについて、事前定義された時間範囲の間に少なくとも２つの受信機のうちの１つによって受信されたバイト数とを備えるパラメータグループに属する。
【００１６】
本発明の一実施形態によれば、制御パラメータは、
サーバに要求されるビットレートの最大値と、
サーバに要求される許容されたバージョンのリストと、
受信バッファの最大サイズと、
要求内にサーバに示される最高速度係数と、
少なくとも２つの受信機のうちのいずれかの受信機の適応ストリーミングアルゴリズムのパラメータと、を備えるパラメータグループに属する。
【００１７】
本発明は、データを受信するための受信機装置にも関係し、データは視聴覚コンテンツを表し、視聴覚コンテンツは少なくとも２つのバージョンで入手可能であり、バージョンはそれぞれ、異なる伝送ビットレートに対応し、視聴覚コンテンツの送信は連続した部分で実行され、連続した部分はそれぞれ、受信機によって送られた送信要求に応答して少なくとも２つのバージョンのうちの１つとして選択され、送信要求は送信パラメータを備える。有利なことに、この装置は、
装置による視聴覚コンテンツのレンダリングを表す監視情報を送るための通信インターフェースと、
制御パラメータを受信するための通信インターフェースであって、制御パラメータは、装置による視聴覚コンテンツのレンダリングを表す情報から定義される、通信インターフェースと、
制御パラメータから送信要求の送信パラメータを計算するためのコンピューティングモジュールと、を備える。
【００１８】
本発明の一実施形態によれば、この装置は、制御パラメータ、および視聴覚コンテンツのレンダリングを表す情報を格納するためのメモリを備える。
【００１９】
本発明の一実施形態によれば、この装置はラップトップ機器である。
【００２０】
本発明の一実施形態によれば、この装置はセットトップボックス機器である。
【００２１】
本発明の一実施形態によれば、この装置はモバイル端末機器である。
【００２２】
本発明は、サーバと少なくとも２つの受信機との間のデータ伝送レートを制御するためのコントローラ装置にも関し、データは視聴覚コンテンツを表し、視聴覚コンテンツは少なくとも２つのバージョンでサーバから入手可能であり、バージョンはそれぞれ、異なる伝送ビットレートに対応し、サーバは、視聴覚コンテンツを連続した部分で送信するように適応され、連続した部分はそれぞれ、受信機によって送られた送信要求に応答して少なくとも２つのバージョンのうちの１つとして選択され、送信要求は送信パラメータを備える。有利なことに、この装置は、
第１の受信機による視聴覚コンテンツのレンダリングを表す第１の監視情報を受信するための通信インターフェースと、
第２の受信機による視聴覚コンテンツのレンダリングを表す第２の監視情報を受信するための通信インターフェースと、
少なくとも第１の監視情報および第２の監視情報から制御パラメータを計算するためのコンピューティングモジュールと、
受信機のうちの少なくとも１つに制御パラメータを送信するための通信インターフェースと、を備える。
【００２３】
本発明の一実施形態によれば、コントローラ装置は、住宅用ゲートウェイ機器内に置かれる。
【００２４】
本発明の一実施形態によれば、コントローラ装置は、デジタル加入者線アクセス多重化（ＤＳＬＡＭ）機器に置かれる。
【００２５】
本発明は、サーバからデータを受信するための受信機における方法にさらに関係し、データは視聴覚コンテンツを表し、視聴覚コンテンツは、少なくとも２つのバージョンでサーバから入手可能であり、バージョンはそれぞれ、異なる伝送ビットレートに対応し、サーバは、視聴覚コンテンツを連続した部分で送信するように適応され、連続した部分はそれぞれ、受信機によって送られた送信要求に応答して少なくとも２つのバージョンのうちの１つとして選択され、送信要求は送信パラメータを備える。有利なことに、この方法は、
受信機による視聴覚コンテンツのレンダリングを表す監視情報を送信するステップと、
制御パラメータを受信するステップであって、制御パラメータは、受信機による視聴覚コンテンツのレンダリングを表す情報から定義される、ステップと、
少なくとも制御パラメータから定義された送信パラメータを備える要求をサーバに送信するステップと、
を含む。
【００２６】
本発明の一実施形態によれば、制御パラメータを受信するステップは、受信機の受信パラメータの少なくとも１つを更新するステップをさらに含む。
【００２７】
この説明では用語「視聴覚コンテンツのレンダリングを表す情報」（または「レンダリングの品質レベル」）は、視聴覚コンテンツのレンダリングの品質に関連する任意の情報に対応する。たとえば、ピクチャの品質はビットレートに依存するので、コンテンツのバージョン（または対応するビットレート）は、このコンテンツのレンダリングの品質を表すものと見なされる。また、あるバージョンと別のバージョンの間の切換えの数は、レンダリング中にコンテンツを表示する間、ユーザが気付くほどなので、コンテンツのレンダリングの品質を表すものと見なされる一例である。受信機の受信バッファ内にデータがないことによるフリーズの数は、視聴覚コンテンツのレンダリングの品質を表す監視情報の別の例である。
【００２８】
開示された実施形態と範囲が等しい特定の態様について、以下に述べる。これらの態様は、本発明が取り得る特定の形についての概要を読者に単に提供するために提示されており、またこれらの態様は、本発明の範囲を制限するためのものでないことを理解されたい。実際に、本発明は、以下に記載されていない様々な態様を包含することができる。
【図面の簡単な説明】
【００２９】
本発明は、決して限定的にではなく、添付の図を参照して、下記の実施形態および実行例によってよりよく理解され示される。
【図１】本発明の一実施形態による、適応ストリーミングが行われるネットワークアーキテクチャ全体を示す図である。
【図２】図１に示されたネットワーク内で使用される受信機を示す図である。
【図３】図１に示されたネットワーク内で使用されるコントローラを示す図である。
【図４】図１に示されたネットワーク内で使用されるサーバを示す図である。
【図５】本発明の一実施形態による、図１および図３のコントローラにおける方法を示す図である。
【図６】本発明の一実施形態による、図１に表された受信機における方法を示す図である。
【００３０】
図１、図２、図３および図４で、表されたブロックは、必ずしも物理的に別個のエンティティに対応しない単に機能的なエンティティである。すなわち、それらは、ハードウェアまたはソフトウェアの形式で開発されてもよいし、１つまたはいくつかの集積回路で実装されてもよい。
【発明を実施するための形態】
【００３１】
本発明の図および説明は、明確にするために、典型的なデジタルマルチメディアコンテンツ配信方法で見られる他の多くの要素を取り除き、本発明の理解を明瞭にするために、関連性のある要素を示すように簡略化されていることを理解されたい。しかし、こうした要素は当技術分野においてよく知られているので、こうした要素の詳細な議論は、本明細書では提供されない。本発明の開示は、当業者に知られているすべてのこうした変更および修正を対象とする。
【００３２】
本発明の実施形態によるシステムが、図１に表されている。このシステムは、受信機とも呼ばれる３つのクライアントデバイス４、６、および８と、適応ストリーミングサーバ１と、コントローラ２とを備える。受信機４、６、および８は、ネットワーク３に接続される。ネットワーク３は、インターネットなどの広域ネットワークと、受信機を相互接続するためのいくつかのローカルエリアサブネットワークとを備える。実施形態の一変形によれば、ネットワーク３は、広域ネットワーク（ＷＡＮ）だけを備え、受信機はそれぞれ、ネットワーク３への接続のためのゲートウェイを備える。実施形態の別の変形によれば、ネットワーク３は、ホームネットワークなど、ローカルエリアネットワーク（ＬＡＮ）だけを備え、サーバ１とコントローラ２は両方とも、ホームネットワークに接続される。実施形態の別の変形によれば、サーバ１は、ＷＡＮネットワークに接続され、受信機４、６、および８は、コントローラ２を備えるゲートウェイによりＬＡＮネットワークに接続される。
【００３３】
サーバは、受信機によって送られたいくつかの要求に従って視聴覚コンテンツを受信機４、６、および８に配信する。サーバから受信機への視聴覚コンテンツの配信は、当業者にはよく知られているＨＴＴＰ適応ストリーム技法を使用する。
【００３４】
受信機４、６、および８はそれぞれ、適応ストリーミング方法を使用して受信された視聴覚コンテンツをレンダリングするために、表示装置（それぞれ５、７および９）に接続される。
【００３５】
本発明の実施形態によれば、受信機は、進行中の適応ストリーミングに関連する情報をコントローラ２に周期的に（または反復して）送る。
【００３６】
受信機４、６、および８はそれぞれ、サーバ１から受信された視聴覚コンテンツ表すデータの受信用に使用されるメモリバッファの充填レベル、現在受信されている視聴覚コンテンツ部分のバージョン（すなわち低品質、中品質、高品質または対応するビットレート）、バッファの使用可能なサイズ、受信バッファのアンダーフロー（枯渇）の数、または適応ストリーミングの間の受信バッファオーバーフローの数をコントローラ２に周期的に送信する。あるいは、上記にリストされた情報の一部だけがコントローラに送られる。実施形態の一変形によれば、受信機４、６、および８によってコントローラ２に送信された情報は、受信機に関連する他の何らかの情報である。たとえば、情報は、時間間隔の間に受信機が視聴覚コンテンツの別のバージョンに切り換わる回数、視聴覚コンテンツ送信全体の間のバージョン切換えの数であってよく、また情報は、視聴覚コンテンツの各バージョンの時間間隔の間のデータ量であってもよい。
【００３７】
より一般には、受信機から見たネットワーク状態を表す任意の情報（すなわち使用可能な帯域幅、輻輳）は、ストリーミングされたコンテンツをレンダリングするのに良好な性能をどの受信機が有するか、またネットワーク状況のせいでどの受信機が悪い性能を有するかを定義するために、コントローラ２に関連する。
【００３８】
別の変形によれば、情報は、視聴覚コンテンツのあるバージョン（または品質）から別のバージョンに切り換わる能力として定義される適応ストリーミングアルゴリズムの積極性（ａｇｇｒｅｓｓｉｖｅｎｅｓｓ）である。低い積極性のパラメータでは、受信システムは保守的になり、高い積極性のパラメータでは、あるコンテンツバージョンから別のコンテンツバージョンに受信機がより頻繁に切り換わることが可能となる。積極性は、本発明の実施形態による受信機の適応ストリーミングアルゴリズムのパラメータである。
【００３９】
受信機４、６、および８から受信された情報によれば、コントローラ２は、どの受信機が良好な適応ストリーミング状態か、またどの受信機が悪い状態か決定する（計算する）。良好な状態は、中断が生じない、中位または高い品質を有する視聴覚コンテンツのレンダリングと定義される。悪い状態は、中断が生じ、常に低い品質レベルを有する視聴覚コンテンツのレンダリングと定義される。どの受信機のストリーミング状態も、ネットワーク３、および他の受信機によるネットワーク３の使用に依存する。
【００４０】
データ受信の状態が分かると、コントローラ２は、ネットワーク３の使用を調整するために、受信機の一部に制御パラメータを送る。コントローラ２は、ユニキャスト伝送を使用することによって受信機を個々にアドレッシングすることによって受信機に１つまたは複数の制御パラメータを送る。実施形態の一変形によれば、コントローラ２は、たとえばマルチキャスト伝送を使用することによって受信機のグループをアドレッシングする。マルチキャスト伝送は、多くの受信機を同時にアドレッシングすることを可能にする。パラメータは、たとえば、バッファサイズを制限し、視聴覚コンテンツの一部の要求されたバージョンの品質を制限し、または受信機の適応ストリーミングアルゴリズム（たとえば積極性）のパラメータを調整するために決定してもよい。
【００４１】
より一般には、コントローラ２によって受信機のうちのいずれかに送られる制御パラメータは、受信パラメータであってもよいし、受信パラメータ（すなわち受信バッファサイズ、適応ストリーミングアルゴリズムの積極性）に関連してもよい。制御パラメータは、受信機からサーバ１へ送られる要求のパラメータ（すなわちコンテンツのバージョン、ビットレート、サーバの配信速度）に関連することもある。
【００４２】
受信機の受信バッファサイズの制御は、適応ストリーミングアルゴリズムが受信バッファのサイズを考慮に入れるので、受信機の（ダウンロードおよびレンダリングのための）挙動全体を制御する容易な方法である。
【００４３】
実施形態によれば、コントローラ２は、リモート制御プロトコルに従って構造化されたいくつかのメッセージで制御パラメータを送る。
【００４４】
受信機４、６、および８から受信された情報に基づいて、リモート管理サーバ（またはリモートコントローラ）として動作するコントローラ２は、受信された視聴覚コンテンツのレンダリングの品質を監視するために、受信機の設定（たとえば適応ストリーミングアルゴリズムの積極性、バッファサイズ、データ伝送に必要な最大ビットレート）を構成する。実施形態によれば、受信機４、６、および８の全体的なレンダリング品質は、各受信機の以前に計算された品質を加えて受信機の数で割ることによって計算される。
【００４５】
より一般には、本発明の実施形態は、サーバ１と受信機４、６、および８との間の伝送データレートを制御するための方法にある。サーバ１は、視聴覚コンテンツを表すデータを送信するように適応される。視聴覚コンテンツはそれぞれ、サーバ１で少なくとも２つのバージョンで入手可能である。視聴覚コンテンツの異なるバージョンはそれぞれ、異なる伝送ビットレートに対応する。サーバ１は、連続した部分（チャンクとも呼ばれる）の視聴覚コンテンツを送信するように適応される。連続した部分はそれぞれ、対応する受信機４、６または８からサーバ１によって受信された送信要求に応答して、使用可能なバージョン間で選択される。サーバから視聴覚コンテンツの一部を受信するために受信機によって送られた送信要求は、たとえばデータ配信速度または（所与のビットレートに対応する）バージョンなど、送信パラメータを備える。
【００４６】
コントローラ２は、受信機４、６、および８から情報を周期的に受信する。情報は、受信機によって受信されレンダリングされた視聴覚コンテンツのレンダリングを表す。視聴覚コンテンツは、すべての受信機について同じであってもよいし、視聴覚コンテンツは、受信機にそれぞれ異なる視聴覚コンテンツであってもよい。
【００４７】
すべての受信機から受信された情報によれば、コントローラ２は、全帯域幅のよりよい分配を見つけるために、いくつかの受信機のいくつかの制御パラメータを計算する。所与のときの帯域幅の現在の分配に従って、制御パラメータの送信が、１つの受信機のためだけに行われることも、受信機グループのために行われることも、すべての受信機のために行われることもある。
【００４８】
コントローラ２によって受信された情報は、たとえば、受信メモリバッファサイズ、受信された視聴覚コンテンツのあるバージョンから別のバージョンへの切換えの回数、メモリバッファのアンダーフローまたはオーバーフローの回数、受信機の適応ストリーミングアルゴリズムの積極性パラメータである。
【００４９】
受信機に１つまたは複数の制御パラメータを送ることによって、コントローラ２は、たとえば、データ受信バッファの最大サイズ、適応ストリーミングアルゴリズムの積極性パラメータ、または所与の受信機について（所与の時間間隔に）新しい調整が行われると受信機から要求され得る向上した品質を強制することができる。
【００５０】
本発明の実施形態によれば、受信機４、６、および８からコントローラ２への情報、およびコントローラ２から受信機４、６、および８への制御パラメータは、ＴＲ−０６９（CPE WAN Management Protocol v1.1, Issue 1, Amendment 2、2007年12月2日）に基づくリモート制御プロトコルによって搬送される。リモート制御プロトコルは、この実施形態について定義されたいくつかの新しいコマンドおよびパラメータを伴う、既存のＴＲ−０６９プロトコルの拡張である。実施形態の一変形によれば、制御パラメータは、ＴＲ−０６９プロトコルの拡張によって搬送され、受信機からコントローラ２に送られたレンダリングを表す情報は、１つまたは複数の異なるプロトコルに基づいて搬送される。この場合、コントローラ２は、情報を送るために受信機によって使用される異なるプロトコルのいずれとも互換性がある。
【００５１】
本発明の実施形態による受信機４が、図２に示されている。適応ストリーミングクライアント装置とも呼ばれる受信機は、リンク１２を介してネットワーク３に接続するための通信インターフェース４４を備える。受信機は、サーバ１およびコントローラ２に対して通信するためのプロトコルスタックを備える通信モジュール４３を備える。特に、通信モジュールは、本技術分野においてよく知られているＴＣＰ／ＩＰスタックを備える。もちろん、通信モジュールは、適応ストリーミングクライアントがサーバ１およびコントローラ２に通信することを可能にする他の任意のタイプのネットワークおよび／または通信手段とすることができる。実施形態によれば、制御パラメータを受信し、レンダリングを表す情報を送るために、単一の通信インターフェースが使用される。実施形態の一変形によれば、２つの異なる通信インターフェースが使用される。受信機４は、コンピューティングモジュールである適応ストリーミングモジュール４５も備える。コンピューティングモジュール４５は、サーバ１からＨＴＴＰストリーミングコンテンツを受信するＨＴＴＰストリーミングクライアントである。コンピューティングモジュール４５は、ネットワークの制約およびそれ自体の制約によりよく一致するビットレートのチャンクを継続的に選択する。チャンクは、適応ストリーミングについて定義された所与のビットレートに対応するバージョンで、サーバ１からの受信された視聴覚コンテンツの一部として定義される。受信機４は、リモート制御モジュール４８のおかげでコントローラ２から制御パラメータを受信する。制御パラメータは、バッファ４２に格納され、コンピューティングモジュールである適応ストリーミングモジュール４５から読み出すことができる。バッファ４２は、視聴覚コンテンツのレンダリングを表す情報を格納するためにも使用される。情報は、適応ストリーミングモジュール４５によってバッファ４２内に書き込まれ、通信インターフェースを介してコントローラ２に送るために、リモート制御モジュール４８によって読み出される。受信機４は、受信された視聴覚コンテンツを復号しレンダリングするように適応されたビデオプレーヤー４６を備える。受信機４は、プロセッサ４１とバッファ４２とをさらに備える。プロセッサ４１は、受信機４に格納されたアプリケーションおよびプログラムを実行するために使用される。メモリまたはメモリの一部であるバッファ４２は、サーバ１から受信されたチャンクを、それがビデオプレーヤー４６に送信される前にバッファリングするのに使用される。特に、メモリは、揮発性メモリである。受信機４は、クライアント上で実行されるアプリケーションおよびプログラムを格納するための不揮発性メモリ４７をも備える。受信機４は、ポータブルメディア装置（モバイル機器）であってもよいし、ラップトップであってもよい。
【００５２】
受信機４の上述のモジュールはすべて、内部バス４９を介して相互接続される。
【００５３】
あるいは、受信機４は、ビデオプレーヤーを備えず、ビデオプレーヤーを接続するインターフェースを備える。このとき、受信機４は、セットトップボックスなどのビデオデコーダである。
【００５４】
実施形態によれば、受信機６および８は、受信機４と同様である。
【００５５】
図３は、本発明の実施形態による適応ストリーミングシステムのコントローラ２を示している。コントローラは、ネットワーク３に接続するための、したがってリンク１１を介して受信機４、６、および８と通信するための通信インターフェース２４を備える。受信機と同様に、コントローラは、受信機（適応ストリーミングクライアント）と通信するためのプロトコルスタックを備える通信モジュール２３を備える。実施形態によれば、レンダリングを表す情報を受信し、制御パラメータを送るために単一の通信インターフェースが使用される。実施形態の一変形によれば、２つの異なる通信インターフェースが使用される。コントローラは、処理装置２１と、メモリモジュール２７と、バッファ２２とを備える。処理装置２１は、コントローラ２に格納されたアプリケーションおよびプログラムを実行するために使用される。メモリまたはメモリの一部であるバッファ２２は、受信機４、６、８から受信された情報および情報メッセージ、ならびに受信機に送られる制御メッセージ（およびパラメータ）をバッファリングするために使用される。コントローラ２は、コントローラ上で実行されるアプリケーションおよびプログラムを格納するための不揮発性メモリ２７をも備える。リモート制御モジュール２８は、受信機から視聴覚コンテンツのレンダリングを表す情報を受信すること、および受信機のパラメータを強制するために制御パラメータを送ることを備える、コントローラと受信機の間のメッセージングのためのリモート制御プロトコルを扱うために使用される。本発明の実施形態によれば、リモート制御モジュールは、メッセージを受信機４、６、および８に対して送受信するために、ＴＲ−０６９に基づいてリモート制御プロトコルを扱う。コントローラ２は、適応ストリーミングモジュール２５をさらに備え、この適応ストリーミングモジュール２５は、（受信機上の視聴覚コンテンツのレンダリングを表す）受信された情報に従って受信機に送られる制御パラメータを計算するためのコンピューティングモジュールである。コントローラ２の上述されたモジュールはすべて、内部バス２９によって相互接続される。
【００５６】
図４は、適応ストリーミングサーバ１を示している。サーバ１は、リンク１０を介してネットワーク３に接続し、受信機４、６、８と通信するための通信インターフェース１４を備える。通信モジュール１３は、たとえばＴＣＰ／ＩＰスタックなど、プロトコルスタックを備える。処理装置１１は、サーバのアプリケーションおよびルーチンを実行する。不揮発性メモリ１７は、処理装置１１によって実行されるソフトウェアおよびアプリケーションを備え、メモリバッファ１２は、アプリケーションを実行する間、データを格納するための揮発性メモリである。バッファ１２は、適応ストリーミング（要求）に関連するものを含めて、受信機からのメッセージを格納するためにも使用される。記憶モジュール１５は、受信機４、６、８に配信されるすべての視聴覚コンテンツを格納するための媒体を備える。記憶モジュール１５は、視聴覚コンテンツのそれぞれについて、（それぞれ異なるビットレートに対応する）すべてのバージョンを備える。視聴覚コンテンツのバージョンは、単一のファイルとして格納することも、ファイルの他のバージョンと連結することもできる。視聴覚コンテンツは、音声コンテンツ、ビデオコンテンツ、またはその両方であってよい。適応ストリーミングモジュール１６は、記憶モジュール１５上に格納された任意のコンテンツの適応ストリームのために受信機４、６、８から入ってくるメッセージを扱う役割を担う。適応ストリーミングモジュール１６は、視聴覚コンテンツに対応するマニフェストファイルを配信し、受信機から入ってくる要求に対処する。適応ストリーミングモジュール１６は、要求のパラメータを解釈し、コンテンツの対応する一部（チャンク）を、対応する受信機に通信インターフェース１４を介して配信する。サーバ１の上記のモジュールはすべて、内部バス１８によって相互接続される。
【００５７】
したがって、（図４によって示された）サーバ１、（図３によって示された）コントローラ２、および（図２によって示された）受信機４、６、８は、実施形態による本発明の適応ストリーミングシステム全体を構成する。
【００５８】
以下の行では、実施形態による、適応ストリーミングセッションの初期化、およびシステム全体がどのように対話するかの一例を提示している。
【００５９】
適応ストリーミングの本質的なパラメータの制御は、適応ストリーミングセッションの開始時に受信機がまずダウンロードするマニフェストファイル（プレイリストを備える）を使用することによって実現される。マニフェストファイルは、たとえばチャンクの継続期間、各チャンクが符号化されたバージョンの数（または品質、またはビットレート）、ファイルのサイズ、ビデオフォーマット（たとえばＭＰＥＧ２−ＴＳやＭＰ４など）を含む。
【００６０】
適応ストリーミングは、どんな中断も生じないが、ビデオ品質がネットワーク輻輳時は劣化し、輻輳がなくなるときは向上する、サーバ１と受信機２、４、８との間の連続したストリームを提案する。それぞれ異なるビットレートをターゲットとするビデオファイルまたはストリームが複数回符号化され、サーバ１の記憶モジュール１５内に格納される。符号化は、たとえばＭＰＥＧ２−ＴＳまたはＨ２６４である。それぞれのファイルは、マイクロファイルセットを形成する同じ持続時間（たとえば２秒）のチャンクに分割される。すべてのマイクロファイルセット（ビットレート当たり１セット）は、単一のＨＴＴＰサーバに格納される。ＨＴＴＰサーバは、サーバ１によって実装される。規則的に（たとえば２秒ごとに）視聴覚コンテンツをダウンロードする受信機（受信機４、６または８）は、サーバで使用可能な帯域幅を推定する。したがって、受信機の適応ストリーミングモジュール４４は、対応するビットレートで符号化されたコンテンツ部分（チャンク）を要求し、ビデオプレーヤー４６の復号器に漸次供給する。本発明の実施形態によれば、制御プロトコルおよび最終的なトランスポートプロトコルは、ＨＴＴＰである。あるいは、それは、ＲＴＳＰであってよい。
【００６１】
マニフェストファイルに加えて、受信機の適応ストリーミング４４モジュールは、システムを微調整するのに必要であり、またネットワーク３が使用される方法に影響を及ぼすいくつかの制御パラメータを収集する。マニフェストファイルは、ネットワーク状態（たとえば輻輳および全帯域幅）に依存したビデオ品質の劣化／向上を平滑化するためのアルゴリズムを備える。受信機の適応ストリーミングモジュール４５の適応ストリーミングアルゴリズムは、最も保守的なものから最も積極的なものまでいくつかの手法を操作することができる。動作モードは、ユーザ体験およびネットワーク３使用に直接影響を及ぼす。
【００６２】
サーバ１に対する受信機４、６、および８の要求の送信パラメータを含めて、受信機４、６、および８のいくつかの制御パラメータを定義するためにコントローラ２を使用することによって、エンドユーザ体験だけでなく、ネットワーク３トラフィック、したがってシステム性能全体にも影響を及ぼす、適応ストリーミングクライアントのいくつかのパラメータを構成することが可能となる。
【００６３】
コントローラ２から受信機４、６、および８のいずれかに送られた制御パラメータは、ネットワーク状態に応じて異なることがある。コントローラは、受信バッファのサイズを制限するパラメータを第１の受信機に、また適応ストリーミングセッションのビットレートを制限するパラメータを第２の受信機に送ることができる。さらに、コントローラは、所与の受信機にとって異なる２つの連続した制御パラメータを送ることができる。たとえば、コントローラは、ストリームセッションのビットレートを制限するための制御パラメータを受信機２に送り、次いで、（受信機２によって）サーバ１に送られる要求のスピード配信係数を制限するための制御パラメータを受信機２に送ることができる。コントローラ２は、受信された情報を計算し、それに応じて設定されるパラメータを（受信機側で）選択する。コントローラ２は、これらのパラメータの値をも定義する。
【００６４】
従来技術では、これらのパラメータは、クライアントによって自律的に定義され、または適応ストリーミングクライアント実装内にハードコピーされ、変更不可能である。
【００６５】
コントローラ２は、受信機から周期的に受信されたステータス情報に従って受信機４、６、および８に適した制御パラメータ（および制御パラメータの対応する値）を定義し、リモート制御プロトコルを使用することによって制御パラメータを構成する。コントローラ２は、エンドユーザが受け取る、完全な受信機フィールドの品質に対する各受信機の影響を「観測し」監視する。受信機から受信された情報を計算した後、コントローラ２は、最適なシステム構成を決定し、１つの受信機または受信機グループに制御パラメータを送る。制御パラメータは、必要であれば、すべての受信機に送ることができる。
【００６６】
下記は、ネットワーク３を介した適応ストリーミングサーバ１と受信機４、６、８の間の適応ストリーミングの性能全体をコントローラ２がどのように監視するかの一例である。
【００６７】
時間Ｔ０で、受信機４、６、および８はどれも、適応ストリーミングの達成のためにサーバ１に接続されてない。時間Ｔ１で、受信機４は、サーバ１からの視聴覚コンテンツＡＶ１の適応ストリーミングダウンロードの初期化を求める要求を送る。サーバ１は、ＡＶ１コンテンツの３つの使用可能なバージョンを示すマニフェストファイルを送ることによって、受信機４からの初期化要求に答える。３つのバージョンは、５００キロビット／秒（低品質）、１メガビット／秒（中品質）および２メガビット／秒（高品質）のビットレートにそれぞれ対応する。受信機４は、Ｔ２で、中品質バージョン（１メガビット／秒）のコンテンツＡＶ１の第１の部分（または第１のチャンク）の取得を求める要求を送る。受信機４は、ＡＶ１の第１の部分を受信し、サーバ１とそれ自体の間のネットワークリンクの帯域幅を評価する。評価された帯域幅が２メガビット／秒超であるので、受信機４は、高品質バージョン（２メガビット／秒）のＡＶ１コンテンツの第２の部分を要求し、サーバ１とそれ自体の間の使用可能な帯域幅を再び評価する。使用可能な帯域幅が２メガビット／秒よりも良い値で評価され、２メガビット／秒超のビットレートで符号化されたＡＶ１のバージョンはないので、受信機４は、高品質バージョンで、かつ２倍の配信速度でＡＶ１コンテンツの第３の部分を要求する。適応ストリーミングシステムは、コンテンツのダウンロードされた部分のバージョンに加えて、速度制御パラメータを送信することを可能にする。次いで、受信機４は、サーバ１とそれ自体の間で倍速でＡＶ１コンテンツの高品質バージョンを要求し続け、ダウンロードが継続する。ストリーミングと並列に、受信機４は、コントローラ２に情報を周期的に送る。たとえば、受信機は、コントローラ２に情報を毎分送る。受信機４は、最後の瞬間にＡＶ１のあるバージョンから別のバージョンに切り換わる回数を示し、ダウンロードされたバージョンおよびマニフェストファイル情報、平均配信速度パラメータ、およびサーバ１とそれ自体の間の計算された帯域幅に従って平均ビットレートが計算される。計算された帯域幅は、受信機４によって、時間間隔（１分）の間のデータ量に基づいて計算されている。
【００６８】
コントローラ２は、受信された情報を計算し、サーバ１からの適応ストリーミングを実施する他の受信機が検出されないので、受信機４に制御パラメータをまだ送らない。
【００６９】
Ｔ３で、受信機６は、サーバ１から視聴覚コンテンツＡＶ２をダウンロードするために、適応ストリーミングセッションを初期化する。サーバ１は、ＡＶ２の使用可能なバージョンを示すマニフェストファイルを受信機６に送ることによって初期化要求に答える。ＡＶ２は、１メガビット／秒のバージョンおよび２メガビット／秒のバージョンで入手可能である。受信機６は、１メガビット／秒のバージョンのＡＶ２コンテンツの第１の部分を要求する。受信機６は、ＡＶ２コンテンツの第１の部分を受信し、サーバ１とそれ自体の間の使用可能な帯域幅を評価する。受信機６は、サーバ１とそれ自体の間で、帯域幅が約１．５メガビット／秒であることを検出する。次いで、受信機６は、ＡＶ２の１メガビット／秒のバージョンで、ＡＶ２の次の部分を要求し続ける。適応ストリーミングダウンロードを継続する受信機４に関して、受信機６は、コントローラ２にも情報を報告する。コントローラ２はこの時点で、受信機４および受信機６から情報を受信する。コントローラ２は、情報を計算し、評価された使用可能な帯域幅が受信機４と受信機６で同じでないことを検出する。その後、コントローラ２は、要求されたバージョンを１メガビット／秒の最大のビットレートに、また配信速度係数を１に強制するための制御パラメータを備えるリモート制御メッセージを受信機４に送る。受信機４は、制御パラメータを受信し、それに応じてサーバ１に、ＡＶ１の次の部分を求める次の要求を送る。受信機４および６は、受信機４および６のそれぞれの情報を周期的に報告し続け、コントローラ２は、適応ストリーミングビットレートがこの時点で、両方の受信機（４と６）でおよそ同じであることを検出する。
【００７０】
コントローラ２は、反復して受信された情報を計算し、それに従って受信機の制御パラメータを反復して調整する。コントローラ２は、受信機を構成し、システムの全体的な性能に影響を及ぼす。
【００７１】
別の例は、サーバ１と受信機４、６との間の総帯域幅が、受信機４と６の両方から受信された監視情報から計算された約３メガビット／秒であり、２つの受信機４と６だけが、サーバ１からの同じ視聴覚コンテンツの適応ストリーミングセッションを処理している場合、コントローラ２は、１．５メガビット／秒（３メガビット／秒を２で割った値）の最大のビットレートに対応するバージョンで視聴覚コンテンツの連続した部分を要求すべきであることを示す制御パラメータを受信機４、６に送ることによってこれらの受信機４および６を制御することができる。
【００７２】
コントローラ２は、たとえば、受信バッファにデータがないために視聴覚コンテンツのレンダリング（再生）が反復していくらか中断することを（監視情報を送ることによって）報告するいずれかの受信機（４、６、８）の受信バッファサイズを制御することもできる。
【００７３】
より一般には、図１に示された適応ストリーミングシステムの上記の例では、コントローラ２は、サーバ１と受信機４、６の間の伝送データレートを制御する。サーバ１は、視聴覚コンテンツＡＶ１、ＡＶ２を表すデータを送信するように適応される。視聴覚コンテンツＡＶ１は、３つのバージョンでサーバ１から入手可能であり、またコンテンツＡＶ２は、２つのバージョンで入手可能である。ＡＶ１およびＡＶ２の使用可能なバージョンは、それぞれ異なる送信ビットレートに対応する。サーバ１は、連続した部分の視聴覚コンテンツＡＶ１、ＡＶ２を送信するように適応される。ＡＶ１とＡＶ２の連続した部分はそれぞれ、送信パラメータ（バージョン（ビットレート）や配信速度など）を備える要求をサーバ１に送信することによって、対応する受信機（４、６）によって選ばれる。コントローラ２は、受信機４から報告された情報、および受信機６からの情報を受信する。受信機からの情報は、レンダリングの品質に関連するので、視聴覚コンテンツＡＶ１、ＡＶ２のレンダリングをそれぞれ表す。低いビットレートでは、エンドユーザへのレンダリングの品質が低くなるが、高いビットレートでは、レンダリングの品質が高くなる。
【００７４】
コントローラ２は、受信機の状態およびネットワーク３の状態に従って、１つまたは複数の受信機に１つまたは複数の制御パラメータを送信する。制御パラメータは、コントローラ２によって、受信機４、６、８により報告された情報から定義される。制御パラメータは、それを受信した受信機を構成し、パラメータに応じて、受信パラメータまたは次の要求用の送信パラメータを定義するために受信機によって使用される。定義された送信パラメータは、たとえば、視聴覚コンテンツのバージョン、サーバによるコンテンツの次の部分の配信のため要求されるビットレートまたは配信速度である。コントローラ２によって受信機に送られる制御パラメータは、たとえば受信バッファ最大サイズなど受信機のパラメータを、サーバへの要求とは独立に構成することもできる。この場合、制御パラメータは受信パラメータである。
【００７５】
図５は、本発明の実施形態によるコントローラ２内の方法を示す図である。
【００７６】
ステップＳ１は、適応ストリーミングシステムの初期化である。少なくとも２つの受信機が、サーバ１に要求を送り、サーバ１からの視聴覚コンテンツをダウンロードし、視聴覚コンテンツのレンダリングを達成するために２つの適応ストリーミングセッションを初期化する。少なくとも２つの受信機が、視聴覚コンテンツのいくつかの部分を受信している。２つの受信機は、同じ視聴覚コンテンツをダウンロードしてもよいし、２つの異なる視聴覚コンテンツをそれぞれダウンロードしてもよい。
【００７７】
ステップＳ２で、２つの受信機のうちの１つが、視聴覚コンテンツの受信された部分のレンダリングを表す情報をコントローラ２に報告する。
【００７８】
ステップＳ３で、第２の受信機が、視聴覚コンテンツの受信された部分のレンダリングを表す情報をコントローラ２に報告する。
【００７９】
受信された情報に基づいて、コントローラ２は、適応ストリーミングシステムの性能全体を評価し、ステップＳ４で、１つまたは複数の受信機に送られる少なくとも１つの制御パラメータを評価する。
【００８０】
次いで、コントローラ２は、受信機を構成し、ネットワーク３の使用可能な帯域幅をよりよく分配するために、少なくとも１つの受信機に少なくとも１つの制御パラメータを送る。
【００８１】
有利なことに、実施形態による方法は、１つの受信機または受信機グループによる帯域幅使用の要求を制限し、より使用可能な帯域幅を他の受信機に提供するように１つの受信機または受信機グループを構成させる。
【００８２】
図６は、本発明の実施形態による、受信機内の方法を示す図である。
【００８３】
ステップＳ’１で、受信機は、サーバ１との適応ストリーミングセッションを初期化し、視聴覚コンテンツのダウンロードおよびレンダリングを開始する。
【００８４】
ステップＳ’２で、視聴覚コンテンツの第１の部分を受信した後、受信機は、コントローラ２に、レンダリングを表す１つまたは複数の情報を報告する。情報は、たとえば、コントローラに毎分報告される。コントローラは、多くの（少なくとも２つの）受信機から受信された情報を計算し、受信機に制御パラメータを送る。この制御パラメータは。ステップＳ’３で、受信機によって受信される。
【００８５】
ステップＳ’４で、受信機は、視聴覚コンテンツのバージョンや、サーバ１による配信速度などの送信パラメータを備える要求を送る。要求の送信パラメータは、コントローラ２によって以前に定義された制御パラメータに従って定義される。たとえば、制御パラメータは、次の部分について要求されるコンテンツのバージョンが所与の値より低いビットレートを有さなければならないことを受信機に示す。
【００８６】
ＴＲ−０６９プロトコルの拡張を使用して、コントローラ２から受信機に制御パラメータを運ぶ制御メッセージのデータモデルのいくつかの例が、下記に示される。
【００８７】
【表１】
【００８８】
実施形態によれば、コントローラ２は、視聴覚コンテンツを公平に配信するために、サーバ１と、受信機４、６または８のいずれかとの間のビットレートを調整することができる。
【００８９】
本発明は、実施形態について上記に述べられた実施形態に限定されない。特に、本発明は、多くのサーバと受信機フィールドの間の適応ストリーミングを制御するための方法にも関する。変形によれば、コントローラは、受信機フィールド内のいくつかの受信機グループのパラメータを事前に定義し、次いで、受信された情報に従って受信機の一部を個々に制御する。
【００９０】
別の変形によれば、コントローラは、ランダムアルゴリズムをまず使用して、制御パラメータを定義し、受信機を初期化し、次いで、受信された情報に従って受信機の一部を制御する。
【００９１】
別の変形によれば、コントローラは、いくつかの受信機グループをアドレッシングすることによって受信機を制御し、グループを周期的に再定義する。
【００９２】
有利なことに、コントローラは、受信機の一部に優先権または特権を与える。それは、たとえば、サービスプロバイダへの加入のレベルに従って行われてもよいし、受信機のサブセットに期待されたレンダリングの品質のレベル（たとえばＨＤ品質対通常品質）に応じて行われてもよい。
【００９３】
本発明は、少なくとも１つのサーバから少なくとも２つの受信機に何らかのコンテンツを配信する適応ストリーミングの任意のシステムにも関する。有利なことに、視聴覚コンテンツは、テキスト、マップ、音楽、ビデオ、メタデータ、バイナリデータ（すなわち実行可能アプリケーション）など、任意の種類のコンテンツを備える。
【００９４】
本発明は一般に、データ受信機に関する。本発明は、セットトップボックス、オーディオ／ビデオデコーダを含むゲートウェイ、ラップトップ、およびモバイル機器（携帯電話、携帯情報端末、測位システム）などの装置を備える。
【００９５】
本明細書では、「一実施形態（ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ、ａｎ ｅｍｂｏｄｉｍｅｎｔ）」への言及は、実施形態に関連して述べられた特定の特徴、構造または特性が本発明の少なくとも１つの実装形態に含まれ得ることを意味する。本明細書の様々な場所に「一実施形態では」の語句が現れることは、必ずしもすべてが同じ実施形態に言及するとは限らず、また別個の実施形態または代替的実施形態が、他の実施形態と必ずしも相互排他的であるとは限らない。
【００９６】
特許請求の範囲に現れる参照符号は、例示するためのものにすぎず、特許請求の範囲を制限する効果はないものとする。
【技術分野】
【０００１】
本発明は、一般には、ビデオストリーミングコンテンツ配信に関し、より詳細には、サーバと受信機の間のビデオストリーミングによって使用される帯域幅を扱うことに関する。
【背景技術】
【０００２】
このセクションは、下記に述べられ、かつ／または特許請求される本発明の様々な態様に関し得る技術の様々な態様を読者に紹介するためのものである。この議論は、本発明の様々な態様についてより理解を促すために背景情報を読者に提供する助けとなると考えられる。したがって、これらの説明は、従来技術を認めるものとしてではなく、この観点から読むべきである。
【０００３】
メディア配信ストリーミングのソリューショは主として、ＩＴＥＦ ＲＦＣ ２３２６に定義されたリアルタイムストリーミングプロトコル（ＲＴＳＰ）、ＭｉｃｒｏｓｏｆｔからのＭｉｃｒｏｓｏｆｔ Ｍｅｄｉａ Ｓｅｒｖｅｒ（ＭＭＳ）プロプライエタリプロトコル、またはＡｄｏｂｅ ＳｙｓｔｅｍｓからのＲｅａｌ Ｔｉｍｅ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ（ＲＴＭＰ）プロプライエタリプロトコルなどのプロトコルに基づく。
【０００４】
インターネットを介したコンテンツ配信を可能にするために、ＨＴＴＰプロトコルに基づくストリーミング技法が現れた。これらの技法は、チャンクと呼ばれる、数秒の長さの連続した小さいセグメントの形式でビデオをクライアントデバイスが受信することを可能にする。それぞれのセグメントは、ＨＴＴＰプロトコルを介して要求され、様々な変形で存在することができ、ネットワークおよびそれ自体の制約に一致する適切なビットレートをクライアントデバイスがいつでも選ぶことを可能にする。それぞれ異なるビットレートは、配信されるコンテンツのそれぞれ異なる品質レベルに対応する。クライアントデバイスは、それが測定したネットワーク帯域幅が減少するとすぐに、ネットワーク帯域幅条件に対してそれほど制限的でないチャンクを要求する。クライアントデバイスは、それが測定したネットワーク帯域幅が増加する場合は、ネットワーク帯域幅条件に対してより制限的なチャンクを要求する。
【０００５】
使用可能なチャンクは一般に、ストリーミングサーバによって生成され提供されたプレイリスト内にリストされる。プレイリストは、フォーマットのタイプごとに１つなど、他のプレイリストを指すことができる。プレイリストは、コーデックや、プレイリストをダウンロードするのに必要な帯域幅など、チャンクの内容、およびプレイリストを要求する方法について記述する。プレイリストフォーマットは、様々なＳＶＣ層について記述するコーデック情報で拡張された、文献「HTTP Live Streaming draft, pantos, http-live-streaming, 06」に記載されたフォーマットとすることができる。
【０００６】
様々なＨＴＴＰストリーム技法が使用可能である。Ａｐｐｌｅ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）は、ドラフトＲＦＣとして発行されており、主としてＡｐｐｌｅデバイスで使用されている。Ｍｉｃｒｏｓｏｆｔ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇは、Ｍｉｃｒｏｓｏｆｔ Ｓｉｌｖｅｒｌｉｇｈｔプラットフォームの一部であり、仕様書は、公的に入手可能である。Ａｄｏｂｅ Ｏｐｅｎ Ｓｏｕｒｃｅ Ｍｅｄｉａ Ｆｒａｍｅｗｏｒｋ（ＯＳＭＦ）は、Ｍｉｃｒｏｓｏｆｔソリューションに近いものである。３ＧＰＰは、パケット交換ストリーミング（ＰＳＳ）システムの仕様を公開している。Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）の定義に関しては、ＭＰＥＧワーキンググループも作成されている。これらのストリーミングソリューションにおいてＨＴＴＰプロトコルを使用する利点は、それがＮＡＴとファイアウォールをシームレスに横断できることである。これらのＨＴＴＰストリーミング技術は、帯域幅制約に適合するためにビデオ品質を連続的かつ体裁よく（ｇｒａｃｅｆｕｌｌｙ）アップグレードまたはダウングレードすることによって、使用可能な帯域幅に関する不安定なネットワークの動作を補償する方法を提供する。
【０００７】
一般的なＨＴＴＰでは、諸ストリーム技法は、同じ概念に基づく。諸ストリーム技法は、プレイリストファイルフォーマット、コンテンツオプション（ビットレート、画像寸法、フレーム率…）を示すために提供されるメタデータ、セグメント内のコンテンツの使用可能な表現の構成、サポートされるコーデック、およびコンテンツ保護技術がそれぞれ異なっている。
【０００８】
クライアントデバイスは、何らかのオーディオ／ビデオコンテンツを再生したい場合、この特定のコンテンツをどのように取得できるか示すファイルをまず取得しなければならない。これは、ＨＴＴＰを介して、ＵＲＬから何らかの「ファイル」を取得することによって行われる。このファイルは基本的に、（ビットレートおよび他の特性に関する）コンテンツの使用可能な表現をリストし、またコンテンツごとに、各タイムスライスの間にコンテンツセグメントのロードを可能にするＵＲＬをリストする。たとえばビデオオンデマンドのコンテンツでは、映画の全記述が提供されるが、ライブ放送のコンテンツでは、記述は、短期間だけをカバーし、時間が経過するときに、新しいアイテムを発見するために周期的に再ロードする必要がある。
【０００９】
クライアントデバイスは、その能力、およびそれがネットワーク環境から得る知識に応じて、（典型的にはそのビットレートに基づいて）何らかの表現を選択し、コンテンツの第１のセグメント（複数可）をロードする。クライアントデバイスは、ネットワーク障害に対処可能である数個のセグメントをバッファリングする。次いで、受信された各セグメントからのコンテンツが、次々に再生される。同時に、クライアントデバイスは、受信レートを測定し、より高いまたは低いビットレートにすることを決定することができる。こうした場合、クライアントデバイスは、別の表現からの次のセグメント（複数可）を単に要求する。あらゆるＨＴＴＰストリーミングシステムは、あるビットレートのセグメントから別のビットレートの「次の」セグメントに進みながら、クライアントが連続再生し続けるというものである。
【００１０】
このように、ネットワーク上のトラフィックによってコンテンツ受信のレートの変化がもたらされる場合、クライアントは、安全なレベルにまでクライアントバッファの充填を維持することを可能にするビットレートを有するセグメントを選択することによって反応することができる。実際に、クライアントは通常、よりよい表示品質を提供するために、またマクロブロックまたはピクチャのフリーズを引き起こすデータ受信の遅れをレンダリングが受けないレベルにとどまるために、できるだけ高いビットレートに達しようと試みる。
【００１１】
ネットワークでは、複数のクライアントデバイスが、ＨＴＴＰストリーミングを同時に実行することができる。ネットワークまたはブロードバンドネットワークで使用可能な帯域幅がトラフィック全体をサポートするのに十分でない場合、クライアントデバイスは、使用可能な帯域幅の分配を得ようと競合する。ＨＴＴＰストリーミングアルゴリズムは、各デバイスで独立に実行され、帯域幅の最適な分配を提供できない。以下の状況が生じることがある。ビデオストリームのうちの１つが高い一定のビットレートを使用し、別のビデオストリームが低いビットレートにとどまるので、帯域幅の分配は不公平となり得る。あるいは、各デバイスが高ビットレートおよび低ビットレートを二者択一的に使用する変動（ｏｓｃｉｌｌａｔｉｏｎ）が生じることがある。それらのデバイスは時々、それが不都合と判断するネットワーク状態に同時に過剰反応して、結果として、各デバイスについて非常に低いビットレートが選択され、帯域幅が大きく浪費されることがある。それは、十分な帯域幅が使用可能な場合でも生じることがあり、ＨＴＴＰプロトコルの基礎となるＴＣＰ機構は、各ストリームのパケット受信が暗黙的競合を受けることがあり、これによって、不変の不公平な状況または永続的な変動という同じ結果がもたらされる。こうした振舞いは、表示されるビデオ品質が、使用されたビットレートに関連しているので、エンドユーザの体験の品質に直接影響を及ぼす。
【先行技術文献】
【非特許文献】
【００１２】
【非特許文献１】HTTP Live Streaming draft, pantos, http-live-streaming, 06
【非特許文献２】CPE WAN Management Protocol v1.1, Issue 1, Amendment 2、2007年12月2日
【発明の概要】
【課題を解決するための手段】
【００１３】
本発明は、ストリーミングコンテンツを受信する多くの受信機間の帯域幅分配に対処することによって、従来技術の適応ストリーミングにおける帯域幅分配に関連する問題の少なくとも一部を取り除こうとするものである。
【００１４】
本発明は、サーバと少なくとも２つの受信機との間の伝送データレートを制御するための方法に関する。サーバは、視聴覚コンテンツを表すデータを送信するように適応される。サーバ上に格納された視聴覚コンテンツは、少なくとも２つのバージョンでサーバから入手可能である。バージョンはそれぞれ、異なる伝送ビットレートに対応する。サーバは、連続した部分の視聴覚コンテンツを送信するように適応される。連続した部分はそれぞれ、受信機によって送られた送信要求に応答して、少なくとも２つのバージョンのうちの１つとして選択される。送信要求は、送信パラメータを備える。有利なことに、この方法は、
コントローラによって第１の受信機から第１の監視情報を受信するステップであって、第１の監視情報は、第１の受信機による視聴覚コンテンツのレンダリングを表す、ステップと、
コントローラによって第２の受信機から第２の監視情報を受信するステップであって、第２の監視情報が、第２の受信機による視聴覚コンテンツのレンダリングを表す、ステップと、
コントローラから受信機のうちの少なくとも１つに制御パラメータを送信するステップであって、パラメータが、制御パラメータから、送信パラメータまたは受信パラメータを定義するために第１の監視情報および第２の監視情報から定義される、ステップと、
を含む。
【００１５】
本発明の一実施形態によれば、第１の監視情報および第２の監視情報のそれぞれは、
サーバと少なくとも２つの受信機のうちの１つとの間のデータ伝送ビットレートと、
少なくとも２つの受信機のうちの１つの受信機のデータ受信バッファのサイズと、
少なくとも２つの受信機のうちの１つによる視聴覚コンテンツのレンダリングの品質指標と、
少なくとも２つの受信機のうちの１つが所与の時間間隔の間にバージョンのうちのあるバージョンからバージョンのうちの別のバージョンに切り換わる回数と、
定義された時間間隔の間に少なくとも２つの受信機のうちの１つによって受信されたバイト数と、
視聴覚コンテンツの少なくとも２つのバージョンのそれぞれについて、事前定義された時間範囲の間に少なくとも２つの受信機のうちの１つによって受信されたバイト数とを備えるパラメータグループに属する。
【００１６】
本発明の一実施形態によれば、制御パラメータは、
サーバに要求されるビットレートの最大値と、
サーバに要求される許容されたバージョンのリストと、
受信バッファの最大サイズと、
要求内にサーバに示される最高速度係数と、
少なくとも２つの受信機のうちのいずれかの受信機の適応ストリーミングアルゴリズムのパラメータと、を備えるパラメータグループに属する。
【００１７】
本発明は、データを受信するための受信機装置にも関係し、データは視聴覚コンテンツを表し、視聴覚コンテンツは少なくとも２つのバージョンで入手可能であり、バージョンはそれぞれ、異なる伝送ビットレートに対応し、視聴覚コンテンツの送信は連続した部分で実行され、連続した部分はそれぞれ、受信機によって送られた送信要求に応答して少なくとも２つのバージョンのうちの１つとして選択され、送信要求は送信パラメータを備える。有利なことに、この装置は、
装置による視聴覚コンテンツのレンダリングを表す監視情報を送るための通信インターフェースと、
制御パラメータを受信するための通信インターフェースであって、制御パラメータは、装置による視聴覚コンテンツのレンダリングを表す情報から定義される、通信インターフェースと、
制御パラメータから送信要求の送信パラメータを計算するためのコンピューティングモジュールと、を備える。
【００１８】
本発明の一実施形態によれば、この装置は、制御パラメータ、および視聴覚コンテンツのレンダリングを表す情報を格納するためのメモリを備える。
【００１９】
本発明の一実施形態によれば、この装置はラップトップ機器である。
【００２０】
本発明の一実施形態によれば、この装置はセットトップボックス機器である。
【００２１】
本発明の一実施形態によれば、この装置はモバイル端末機器である。
【００２２】
本発明は、サーバと少なくとも２つの受信機との間のデータ伝送レートを制御するためのコントローラ装置にも関し、データは視聴覚コンテンツを表し、視聴覚コンテンツは少なくとも２つのバージョンでサーバから入手可能であり、バージョンはそれぞれ、異なる伝送ビットレートに対応し、サーバは、視聴覚コンテンツを連続した部分で送信するように適応され、連続した部分はそれぞれ、受信機によって送られた送信要求に応答して少なくとも２つのバージョンのうちの１つとして選択され、送信要求は送信パラメータを備える。有利なことに、この装置は、
第１の受信機による視聴覚コンテンツのレンダリングを表す第１の監視情報を受信するための通信インターフェースと、
第２の受信機による視聴覚コンテンツのレンダリングを表す第２の監視情報を受信するための通信インターフェースと、
少なくとも第１の監視情報および第２の監視情報から制御パラメータを計算するためのコンピューティングモジュールと、
受信機のうちの少なくとも１つに制御パラメータを送信するための通信インターフェースと、を備える。
【００２３】
本発明の一実施形態によれば、コントローラ装置は、住宅用ゲートウェイ機器内に置かれる。
【００２４】
本発明の一実施形態によれば、コントローラ装置は、デジタル加入者線アクセス多重化（ＤＳＬＡＭ）機器に置かれる。
【００２５】
本発明は、サーバからデータを受信するための受信機における方法にさらに関係し、データは視聴覚コンテンツを表し、視聴覚コンテンツは、少なくとも２つのバージョンでサーバから入手可能であり、バージョンはそれぞれ、異なる伝送ビットレートに対応し、サーバは、視聴覚コンテンツを連続した部分で送信するように適応され、連続した部分はそれぞれ、受信機によって送られた送信要求に応答して少なくとも２つのバージョンのうちの１つとして選択され、送信要求は送信パラメータを備える。有利なことに、この方法は、
受信機による視聴覚コンテンツのレンダリングを表す監視情報を送信するステップと、
制御パラメータを受信するステップであって、制御パラメータは、受信機による視聴覚コンテンツのレンダリングを表す情報から定義される、ステップと、
少なくとも制御パラメータから定義された送信パラメータを備える要求をサーバに送信するステップと、
を含む。
【００２６】
本発明の一実施形態によれば、制御パラメータを受信するステップは、受信機の受信パラメータの少なくとも１つを更新するステップをさらに含む。
【００２７】
この説明では用語「視聴覚コンテンツのレンダリングを表す情報」（または「レンダリングの品質レベル」）は、視聴覚コンテンツのレンダリングの品質に関連する任意の情報に対応する。たとえば、ピクチャの品質はビットレートに依存するので、コンテンツのバージョン（または対応するビットレート）は、このコンテンツのレンダリングの品質を表すものと見なされる。また、あるバージョンと別のバージョンの間の切換えの数は、レンダリング中にコンテンツを表示する間、ユーザが気付くほどなので、コンテンツのレンダリングの品質を表すものと見なされる一例である。受信機の受信バッファ内にデータがないことによるフリーズの数は、視聴覚コンテンツのレンダリングの品質を表す監視情報の別の例である。
【００２８】
開示された実施形態と範囲が等しい特定の態様について、以下に述べる。これらの態様は、本発明が取り得る特定の形についての概要を読者に単に提供するために提示されており、またこれらの態様は、本発明の範囲を制限するためのものでないことを理解されたい。実際に、本発明は、以下に記載されていない様々な態様を包含することができる。
【図面の簡単な説明】
【００２９】
本発明は、決して限定的にではなく、添付の図を参照して、下記の実施形態および実行例によってよりよく理解され示される。
【図１】本発明の一実施形態による、適応ストリーミングが行われるネットワークアーキテクチャ全体を示す図である。
【図２】図１に示されたネットワーク内で使用される受信機を示す図である。
【図３】図１に示されたネットワーク内で使用されるコントローラを示す図である。
【図４】図１に示されたネットワーク内で使用されるサーバを示す図である。
【図５】本発明の一実施形態による、図１および図３のコントローラにおける方法を示す図である。
【図６】本発明の一実施形態による、図１に表された受信機における方法を示す図である。
【００３０】
図１、図２、図３および図４で、表されたブロックは、必ずしも物理的に別個のエンティティに対応しない単に機能的なエンティティである。すなわち、それらは、ハードウェアまたはソフトウェアの形式で開発されてもよいし、１つまたはいくつかの集積回路で実装されてもよい。
【発明を実施するための形態】
【００３１】
本発明の図および説明は、明確にするために、典型的なデジタルマルチメディアコンテンツ配信方法で見られる他の多くの要素を取り除き、本発明の理解を明瞭にするために、関連性のある要素を示すように簡略化されていることを理解されたい。しかし、こうした要素は当技術分野においてよく知られているので、こうした要素の詳細な議論は、本明細書では提供されない。本発明の開示は、当業者に知られているすべてのこうした変更および修正を対象とする。
【００３２】
本発明の実施形態によるシステムが、図１に表されている。このシステムは、受信機とも呼ばれる３つのクライアントデバイス４、６、および８と、適応ストリーミングサーバ１と、コントローラ２とを備える。受信機４、６、および８は、ネットワーク３に接続される。ネットワーク３は、インターネットなどの広域ネットワークと、受信機を相互接続するためのいくつかのローカルエリアサブネットワークとを備える。実施形態の一変形によれば、ネットワーク３は、広域ネットワーク（ＷＡＮ）だけを備え、受信機はそれぞれ、ネットワーク３への接続のためのゲートウェイを備える。実施形態の別の変形によれば、ネットワーク３は、ホームネットワークなど、ローカルエリアネットワーク（ＬＡＮ）だけを備え、サーバ１とコントローラ２は両方とも、ホームネットワークに接続される。実施形態の別の変形によれば、サーバ１は、ＷＡＮネットワークに接続され、受信機４、６、および８は、コントローラ２を備えるゲートウェイによりＬＡＮネットワークに接続される。
【００３３】
サーバは、受信機によって送られたいくつかの要求に従って視聴覚コンテンツを受信機４、６、および８に配信する。サーバから受信機への視聴覚コンテンツの配信は、当業者にはよく知られているＨＴＴＰ適応ストリーム技法を使用する。
【００３４】
受信機４、６、および８はそれぞれ、適応ストリーミング方法を使用して受信された視聴覚コンテンツをレンダリングするために、表示装置（それぞれ５、７および９）に接続される。
【００３５】
本発明の実施形態によれば、受信機は、進行中の適応ストリーミングに関連する情報をコントローラ２に周期的に（または反復して）送る。
【００３６】
受信機４、６、および８はそれぞれ、サーバ１から受信された視聴覚コンテンツ表すデータの受信用に使用されるメモリバッファの充填レベル、現在受信されている視聴覚コンテンツ部分のバージョン（すなわち低品質、中品質、高品質または対応するビットレート）、バッファの使用可能なサイズ、受信バッファのアンダーフロー（枯渇）の数、または適応ストリーミングの間の受信バッファオーバーフローの数をコントローラ２に周期的に送信する。あるいは、上記にリストされた情報の一部だけがコントローラに送られる。実施形態の一変形によれば、受信機４、６、および８によってコントローラ２に送信された情報は、受信機に関連する他の何らかの情報である。たとえば、情報は、時間間隔の間に受信機が視聴覚コンテンツの別のバージョンに切り換わる回数、視聴覚コンテンツ送信全体の間のバージョン切換えの数であってよく、また情報は、視聴覚コンテンツの各バージョンの時間間隔の間のデータ量であってもよい。
【００３７】
より一般には、受信機から見たネットワーク状態を表す任意の情報（すなわち使用可能な帯域幅、輻輳）は、ストリーミングされたコンテンツをレンダリングするのに良好な性能をどの受信機が有するか、またネットワーク状況のせいでどの受信機が悪い性能を有するかを定義するために、コントローラ２に関連する。
【００３８】
別の変形によれば、情報は、視聴覚コンテンツのあるバージョン（または品質）から別のバージョンに切り換わる能力として定義される適応ストリーミングアルゴリズムの積極性（ａｇｇｒｅｓｓｉｖｅｎｅｓｓ）である。低い積極性のパラメータでは、受信システムは保守的になり、高い積極性のパラメータでは、あるコンテンツバージョンから別のコンテンツバージョンに受信機がより頻繁に切り換わることが可能となる。積極性は、本発明の実施形態による受信機の適応ストリーミングアルゴリズムのパラメータである。
【００３９】
受信機４、６、および８から受信された情報によれば、コントローラ２は、どの受信機が良好な適応ストリーミング状態か、またどの受信機が悪い状態か決定する（計算する）。良好な状態は、中断が生じない、中位または高い品質を有する視聴覚コンテンツのレンダリングと定義される。悪い状態は、中断が生じ、常に低い品質レベルを有する視聴覚コンテンツのレンダリングと定義される。どの受信機のストリーミング状態も、ネットワーク３、および他の受信機によるネットワーク３の使用に依存する。
【００４０】
データ受信の状態が分かると、コントローラ２は、ネットワーク３の使用を調整するために、受信機の一部に制御パラメータを送る。コントローラ２は、ユニキャスト伝送を使用することによって受信機を個々にアドレッシングすることによって受信機に１つまたは複数の制御パラメータを送る。実施形態の一変形によれば、コントローラ２は、たとえばマルチキャスト伝送を使用することによって受信機のグループをアドレッシングする。マルチキャスト伝送は、多くの受信機を同時にアドレッシングすることを可能にする。パラメータは、たとえば、バッファサイズを制限し、視聴覚コンテンツの一部の要求されたバージョンの品質を制限し、または受信機の適応ストリーミングアルゴリズム（たとえば積極性）のパラメータを調整するために決定してもよい。
【００４１】
より一般には、コントローラ２によって受信機のうちのいずれかに送られる制御パラメータは、受信パラメータであってもよいし、受信パラメータ（すなわち受信バッファサイズ、適応ストリーミングアルゴリズムの積極性）に関連してもよい。制御パラメータは、受信機からサーバ１へ送られる要求のパラメータ（すなわちコンテンツのバージョン、ビットレート、サーバの配信速度）に関連することもある。
【００４２】
受信機の受信バッファサイズの制御は、適応ストリーミングアルゴリズムが受信バッファのサイズを考慮に入れるので、受信機の（ダウンロードおよびレンダリングのための）挙動全体を制御する容易な方法である。
【００４３】
実施形態によれば、コントローラ２は、リモート制御プロトコルに従って構造化されたいくつかのメッセージで制御パラメータを送る。
【００４４】
受信機４、６、および８から受信された情報に基づいて、リモート管理サーバ（またはリモートコントローラ）として動作するコントローラ２は、受信された視聴覚コンテンツのレンダリングの品質を監視するために、受信機の設定（たとえば適応ストリーミングアルゴリズムの積極性、バッファサイズ、データ伝送に必要な最大ビットレート）を構成する。実施形態によれば、受信機４、６、および８の全体的なレンダリング品質は、各受信機の以前に計算された品質を加えて受信機の数で割ることによって計算される。
【００４５】
より一般には、本発明の実施形態は、サーバ１と受信機４、６、および８との間の伝送データレートを制御するための方法にある。サーバ１は、視聴覚コンテンツを表すデータを送信するように適応される。視聴覚コンテンツはそれぞれ、サーバ１で少なくとも２つのバージョンで入手可能である。視聴覚コンテンツの異なるバージョンはそれぞれ、異なる伝送ビットレートに対応する。サーバ１は、連続した部分（チャンクとも呼ばれる）の視聴覚コンテンツを送信するように適応される。連続した部分はそれぞれ、対応する受信機４、６または８からサーバ１によって受信された送信要求に応答して、使用可能なバージョン間で選択される。サーバから視聴覚コンテンツの一部を受信するために受信機によって送られた送信要求は、たとえばデータ配信速度または（所与のビットレートに対応する）バージョンなど、送信パラメータを備える。
【００４６】
コントローラ２は、受信機４、６、および８から情報を周期的に受信する。情報は、受信機によって受信されレンダリングされた視聴覚コンテンツのレンダリングを表す。視聴覚コンテンツは、すべての受信機について同じであってもよいし、視聴覚コンテンツは、受信機にそれぞれ異なる視聴覚コンテンツであってもよい。
【００４７】
すべての受信機から受信された情報によれば、コントローラ２は、全帯域幅のよりよい分配を見つけるために、いくつかの受信機のいくつかの制御パラメータを計算する。所与のときの帯域幅の現在の分配に従って、制御パラメータの送信が、１つの受信機のためだけに行われることも、受信機グループのために行われることも、すべての受信機のために行われることもある。
【００４８】
コントローラ２によって受信された情報は、たとえば、受信メモリバッファサイズ、受信された視聴覚コンテンツのあるバージョンから別のバージョンへの切換えの回数、メモリバッファのアンダーフローまたはオーバーフローの回数、受信機の適応ストリーミングアルゴリズムの積極性パラメータである。
【００４９】
受信機に１つまたは複数の制御パラメータを送ることによって、コントローラ２は、たとえば、データ受信バッファの最大サイズ、適応ストリーミングアルゴリズムの積極性パラメータ、または所与の受信機について（所与の時間間隔に）新しい調整が行われると受信機から要求され得る向上した品質を強制することができる。
【００５０】
本発明の実施形態によれば、受信機４、６、および８からコントローラ２への情報、およびコントローラ２から受信機４、６、および８への制御パラメータは、ＴＲ−０６９（CPE WAN Management Protocol v1.1, Issue 1, Amendment 2、2007年12月2日）に基づくリモート制御プロトコルによって搬送される。リモート制御プロトコルは、この実施形態について定義されたいくつかの新しいコマンドおよびパラメータを伴う、既存のＴＲ−０６９プロトコルの拡張である。実施形態の一変形によれば、制御パラメータは、ＴＲ−０６９プロトコルの拡張によって搬送され、受信機からコントローラ２に送られたレンダリングを表す情報は、１つまたは複数の異なるプロトコルに基づいて搬送される。この場合、コントローラ２は、情報を送るために受信機によって使用される異なるプロトコルのいずれとも互換性がある。
【００５１】
本発明の実施形態による受信機４が、図２に示されている。適応ストリーミングクライアント装置とも呼ばれる受信機は、リンク１２を介してネットワーク３に接続するための通信インターフェース４４を備える。受信機は、サーバ１およびコントローラ２に対して通信するためのプロトコルスタックを備える通信モジュール４３を備える。特に、通信モジュールは、本技術分野においてよく知られているＴＣＰ／ＩＰスタックを備える。もちろん、通信モジュールは、適応ストリーミングクライアントがサーバ１およびコントローラ２に通信することを可能にする他の任意のタイプのネットワークおよび／または通信手段とすることができる。実施形態によれば、制御パラメータを受信し、レンダリングを表す情報を送るために、単一の通信インターフェースが使用される。実施形態の一変形によれば、２つの異なる通信インターフェースが使用される。受信機４は、コンピューティングモジュールである適応ストリーミングモジュール４５も備える。コンピューティングモジュール４５は、サーバ１からＨＴＴＰストリーミングコンテンツを受信するＨＴＴＰストリーミングクライアントである。コンピューティングモジュール４５は、ネットワークの制約およびそれ自体の制約によりよく一致するビットレートのチャンクを継続的に選択する。チャンクは、適応ストリーミングについて定義された所与のビットレートに対応するバージョンで、サーバ１からの受信された視聴覚コンテンツの一部として定義される。受信機４は、リモート制御モジュール４８のおかげでコントローラ２から制御パラメータを受信する。制御パラメータは、バッファ４２に格納され、コンピューティングモジュールである適応ストリーミングモジュール４５から読み出すことができる。バッファ４２は、視聴覚コンテンツのレンダリングを表す情報を格納するためにも使用される。情報は、適応ストリーミングモジュール４５によってバッファ４２内に書き込まれ、通信インターフェースを介してコントローラ２に送るために、リモート制御モジュール４８によって読み出される。受信機４は、受信された視聴覚コンテンツを復号しレンダリングするように適応されたビデオプレーヤー４６を備える。受信機４は、プロセッサ４１とバッファ４２とをさらに備える。プロセッサ４１は、受信機４に格納されたアプリケーションおよびプログラムを実行するために使用される。メモリまたはメモリの一部であるバッファ４２は、サーバ１から受信されたチャンクを、それがビデオプレーヤー４６に送信される前にバッファリングするのに使用される。特に、メモリは、揮発性メモリである。受信機４は、クライアント上で実行されるアプリケーションおよびプログラムを格納するための不揮発性メモリ４７をも備える。受信機４は、ポータブルメディア装置（モバイル機器）であってもよいし、ラップトップであってもよい。
【００５２】
受信機４の上述のモジュールはすべて、内部バス４９を介して相互接続される。
【００５３】
あるいは、受信機４は、ビデオプレーヤーを備えず、ビデオプレーヤーを接続するインターフェースを備える。このとき、受信機４は、セットトップボックスなどのビデオデコーダである。
【００５４】
実施形態によれば、受信機６および８は、受信機４と同様である。
【００５５】
図３は、本発明の実施形態による適応ストリーミングシステムのコントローラ２を示している。コントローラは、ネットワーク３に接続するための、したがってリンク１１を介して受信機４、６、および８と通信するための通信インターフェース２４を備える。受信機と同様に、コントローラは、受信機（適応ストリーミングクライアント）と通信するためのプロトコルスタックを備える通信モジュール２３を備える。実施形態によれば、レンダリングを表す情報を受信し、制御パラメータを送るために単一の通信インターフェースが使用される。実施形態の一変形によれば、２つの異なる通信インターフェースが使用される。コントローラは、処理装置２１と、メモリモジュール２７と、バッファ２２とを備える。処理装置２１は、コントローラ２に格納されたアプリケーションおよびプログラムを実行するために使用される。メモリまたはメモリの一部であるバッファ２２は、受信機４、６、８から受信された情報および情報メッセージ、ならびに受信機に送られる制御メッセージ（およびパラメータ）をバッファリングするために使用される。コントローラ２は、コントローラ上で実行されるアプリケーションおよびプログラムを格納するための不揮発性メモリ２７をも備える。リモート制御モジュール２８は、受信機から視聴覚コンテンツのレンダリングを表す情報を受信すること、および受信機のパラメータを強制するために制御パラメータを送ることを備える、コントローラと受信機の間のメッセージングのためのリモート制御プロトコルを扱うために使用される。本発明の実施形態によれば、リモート制御モジュールは、メッセージを受信機４、６、および８に対して送受信するために、ＴＲ−０６９に基づいてリモート制御プロトコルを扱う。コントローラ２は、適応ストリーミングモジュール２５をさらに備え、この適応ストリーミングモジュール２５は、（受信機上の視聴覚コンテンツのレンダリングを表す）受信された情報に従って受信機に送られる制御パラメータを計算するためのコンピューティングモジュールである。コントローラ２の上述されたモジュールはすべて、内部バス２９によって相互接続される。
【００５６】
図４は、適応ストリーミングサーバ１を示している。サーバ１は、リンク１０を介してネットワーク３に接続し、受信機４、６、８と通信するための通信インターフェース１４を備える。通信モジュール１３は、たとえばＴＣＰ／ＩＰスタックなど、プロトコルスタックを備える。処理装置１１は、サーバのアプリケーションおよびルーチンを実行する。不揮発性メモリ１７は、処理装置１１によって実行されるソフトウェアおよびアプリケーションを備え、メモリバッファ１２は、アプリケーションを実行する間、データを格納するための揮発性メモリである。バッファ１２は、適応ストリーミング（要求）に関連するものを含めて、受信機からのメッセージを格納するためにも使用される。記憶モジュール１５は、受信機４、６、８に配信されるすべての視聴覚コンテンツを格納するための媒体を備える。記憶モジュール１５は、視聴覚コンテンツのそれぞれについて、（それぞれ異なるビットレートに対応する）すべてのバージョンを備える。視聴覚コンテンツのバージョンは、単一のファイルとして格納することも、ファイルの他のバージョンと連結することもできる。視聴覚コンテンツは、音声コンテンツ、ビデオコンテンツ、またはその両方であってよい。適応ストリーミングモジュール１６は、記憶モジュール１５上に格納された任意のコンテンツの適応ストリームのために受信機４、６、８から入ってくるメッセージを扱う役割を担う。適応ストリーミングモジュール１６は、視聴覚コンテンツに対応するマニフェストファイルを配信し、受信機から入ってくる要求に対処する。適応ストリーミングモジュール１６は、要求のパラメータを解釈し、コンテンツの対応する一部（チャンク）を、対応する受信機に通信インターフェース１４を介して配信する。サーバ１の上記のモジュールはすべて、内部バス１８によって相互接続される。
【００５７】
したがって、（図４によって示された）サーバ１、（図３によって示された）コントローラ２、および（図２によって示された）受信機４、６、８は、実施形態による本発明の適応ストリーミングシステム全体を構成する。
【００５８】
以下の行では、実施形態による、適応ストリーミングセッションの初期化、およびシステム全体がどのように対話するかの一例を提示している。
【００５９】
適応ストリーミングの本質的なパラメータの制御は、適応ストリーミングセッションの開始時に受信機がまずダウンロードするマニフェストファイル（プレイリストを備える）を使用することによって実現される。マニフェストファイルは、たとえばチャンクの継続期間、各チャンクが符号化されたバージョンの数（または品質、またはビットレート）、ファイルのサイズ、ビデオフォーマット（たとえばＭＰＥＧ２−ＴＳやＭＰ４など）を含む。
【００６０】
適応ストリーミングは、どんな中断も生じないが、ビデオ品質がネットワーク輻輳時は劣化し、輻輳がなくなるときは向上する、サーバ１と受信機２、４、８との間の連続したストリームを提案する。それぞれ異なるビットレートをターゲットとするビデオファイルまたはストリームが複数回符号化され、サーバ１の記憶モジュール１５内に格納される。符号化は、たとえばＭＰＥＧ２−ＴＳまたはＨ２６４である。それぞれのファイルは、マイクロファイルセットを形成する同じ持続時間（たとえば２秒）のチャンクに分割される。すべてのマイクロファイルセット（ビットレート当たり１セット）は、単一のＨＴＴＰサーバに格納される。ＨＴＴＰサーバは、サーバ１によって実装される。規則的に（たとえば２秒ごとに）視聴覚コンテンツをダウンロードする受信機（受信機４、６または８）は、サーバで使用可能な帯域幅を推定する。したがって、受信機の適応ストリーミングモジュール４４は、対応するビットレートで符号化されたコンテンツ部分（チャンク）を要求し、ビデオプレーヤー４６の復号器に漸次供給する。本発明の実施形態によれば、制御プロトコルおよび最終的なトランスポートプロトコルは、ＨＴＴＰである。あるいは、それは、ＲＴＳＰであってよい。
【００６１】
マニフェストファイルに加えて、受信機の適応ストリーミング４４モジュールは、システムを微調整するのに必要であり、またネットワーク３が使用される方法に影響を及ぼすいくつかの制御パラメータを収集する。マニフェストファイルは、ネットワーク状態（たとえば輻輳および全帯域幅）に依存したビデオ品質の劣化／向上を平滑化するためのアルゴリズムを備える。受信機の適応ストリーミングモジュール４５の適応ストリーミングアルゴリズムは、最も保守的なものから最も積極的なものまでいくつかの手法を操作することができる。動作モードは、ユーザ体験およびネットワーク３使用に直接影響を及ぼす。
【００６２】
サーバ１に対する受信機４、６、および８の要求の送信パラメータを含めて、受信機４、６、および８のいくつかの制御パラメータを定義するためにコントローラ２を使用することによって、エンドユーザ体験だけでなく、ネットワーク３トラフィック、したがってシステム性能全体にも影響を及ぼす、適応ストリーミングクライアントのいくつかのパラメータを構成することが可能となる。
【００６３】
コントローラ２から受信機４、６、および８のいずれかに送られた制御パラメータは、ネットワーク状態に応じて異なることがある。コントローラは、受信バッファのサイズを制限するパラメータを第１の受信機に、また適応ストリーミングセッションのビットレートを制限するパラメータを第２の受信機に送ることができる。さらに、コントローラは、所与の受信機にとって異なる２つの連続した制御パラメータを送ることができる。たとえば、コントローラは、ストリームセッションのビットレートを制限するための制御パラメータを受信機２に送り、次いで、（受信機２によって）サーバ１に送られる要求のスピード配信係数を制限するための制御パラメータを受信機２に送ることができる。コントローラ２は、受信された情報を計算し、それに応じて設定されるパラメータを（受信機側で）選択する。コントローラ２は、これらのパラメータの値をも定義する。
【００６４】
従来技術では、これらのパラメータは、クライアントによって自律的に定義され、または適応ストリーミングクライアント実装内にハードコピーされ、変更不可能である。
【００６５】
コントローラ２は、受信機から周期的に受信されたステータス情報に従って受信機４、６、および８に適した制御パラメータ（および制御パラメータの対応する値）を定義し、リモート制御プロトコルを使用することによって制御パラメータを構成する。コントローラ２は、エンドユーザが受け取る、完全な受信機フィールドの品質に対する各受信機の影響を「観測し」監視する。受信機から受信された情報を計算した後、コントローラ２は、最適なシステム構成を決定し、１つの受信機または受信機グループに制御パラメータを送る。制御パラメータは、必要であれば、すべての受信機に送ることができる。
【００６６】
下記は、ネットワーク３を介した適応ストリーミングサーバ１と受信機４、６、８の間の適応ストリーミングの性能全体をコントローラ２がどのように監視するかの一例である。
【００６７】
時間Ｔ０で、受信機４、６、および８はどれも、適応ストリーミングの達成のためにサーバ１に接続されてない。時間Ｔ１で、受信機４は、サーバ１からの視聴覚コンテンツＡＶ１の適応ストリーミングダウンロードの初期化を求める要求を送る。サーバ１は、ＡＶ１コンテンツの３つの使用可能なバージョンを示すマニフェストファイルを送ることによって、受信機４からの初期化要求に答える。３つのバージョンは、５００キロビット／秒（低品質）、１メガビット／秒（中品質）および２メガビット／秒（高品質）のビットレートにそれぞれ対応する。受信機４は、Ｔ２で、中品質バージョン（１メガビット／秒）のコンテンツＡＶ１の第１の部分（または第１のチャンク）の取得を求める要求を送る。受信機４は、ＡＶ１の第１の部分を受信し、サーバ１とそれ自体の間のネットワークリンクの帯域幅を評価する。評価された帯域幅が２メガビット／秒超であるので、受信機４は、高品質バージョン（２メガビット／秒）のＡＶ１コンテンツの第２の部分を要求し、サーバ１とそれ自体の間の使用可能な帯域幅を再び評価する。使用可能な帯域幅が２メガビット／秒よりも良い値で評価され、２メガビット／秒超のビットレートで符号化されたＡＶ１のバージョンはないので、受信機４は、高品質バージョンで、かつ２倍の配信速度でＡＶ１コンテンツの第３の部分を要求する。適応ストリーミングシステムは、コンテンツのダウンロードされた部分のバージョンに加えて、速度制御パラメータを送信することを可能にする。次いで、受信機４は、サーバ１とそれ自体の間で倍速でＡＶ１コンテンツの高品質バージョンを要求し続け、ダウンロードが継続する。ストリーミングと並列に、受信機４は、コントローラ２に情報を周期的に送る。たとえば、受信機は、コントローラ２に情報を毎分送る。受信機４は、最後の瞬間にＡＶ１のあるバージョンから別のバージョンに切り換わる回数を示し、ダウンロードされたバージョンおよびマニフェストファイル情報、平均配信速度パラメータ、およびサーバ１とそれ自体の間の計算された帯域幅に従って平均ビットレートが計算される。計算された帯域幅は、受信機４によって、時間間隔（１分）の間のデータ量に基づいて計算されている。
【００６８】
コントローラ２は、受信された情報を計算し、サーバ１からの適応ストリーミングを実施する他の受信機が検出されないので、受信機４に制御パラメータをまだ送らない。
【００６９】
Ｔ３で、受信機６は、サーバ１から視聴覚コンテンツＡＶ２をダウンロードするために、適応ストリーミングセッションを初期化する。サーバ１は、ＡＶ２の使用可能なバージョンを示すマニフェストファイルを受信機６に送ることによって初期化要求に答える。ＡＶ２は、１メガビット／秒のバージョンおよび２メガビット／秒のバージョンで入手可能である。受信機６は、１メガビット／秒のバージョンのＡＶ２コンテンツの第１の部分を要求する。受信機６は、ＡＶ２コンテンツの第１の部分を受信し、サーバ１とそれ自体の間の使用可能な帯域幅を評価する。受信機６は、サーバ１とそれ自体の間で、帯域幅が約１．５メガビット／秒であることを検出する。次いで、受信機６は、ＡＶ２の１メガビット／秒のバージョンで、ＡＶ２の次の部分を要求し続ける。適応ストリーミングダウンロードを継続する受信機４に関して、受信機６は、コントローラ２にも情報を報告する。コントローラ２はこの時点で、受信機４および受信機６から情報を受信する。コントローラ２は、情報を計算し、評価された使用可能な帯域幅が受信機４と受信機６で同じでないことを検出する。その後、コントローラ２は、要求されたバージョンを１メガビット／秒の最大のビットレートに、また配信速度係数を１に強制するための制御パラメータを備えるリモート制御メッセージを受信機４に送る。受信機４は、制御パラメータを受信し、それに応じてサーバ１に、ＡＶ１の次の部分を求める次の要求を送る。受信機４および６は、受信機４および６のそれぞれの情報を周期的に報告し続け、コントローラ２は、適応ストリーミングビットレートがこの時点で、両方の受信機（４と６）でおよそ同じであることを検出する。
【００７０】
コントローラ２は、反復して受信された情報を計算し、それに従って受信機の制御パラメータを反復して調整する。コントローラ２は、受信機を構成し、システムの全体的な性能に影響を及ぼす。
【００７１】
別の例は、サーバ１と受信機４、６との間の総帯域幅が、受信機４と６の両方から受信された監視情報から計算された約３メガビット／秒であり、２つの受信機４と６だけが、サーバ１からの同じ視聴覚コンテンツの適応ストリーミングセッションを処理している場合、コントローラ２は、１．５メガビット／秒（３メガビット／秒を２で割った値）の最大のビットレートに対応するバージョンで視聴覚コンテンツの連続した部分を要求すべきであることを示す制御パラメータを受信機４、６に送ることによってこれらの受信機４および６を制御することができる。
【００７２】
コントローラ２は、たとえば、受信バッファにデータがないために視聴覚コンテンツのレンダリング（再生）が反復していくらか中断することを（監視情報を送ることによって）報告するいずれかの受信機（４、６、８）の受信バッファサイズを制御することもできる。
【００７３】
より一般には、図１に示された適応ストリーミングシステムの上記の例では、コントローラ２は、サーバ１と受信機４、６の間の伝送データレートを制御する。サーバ１は、視聴覚コンテンツＡＶ１、ＡＶ２を表すデータを送信するように適応される。視聴覚コンテンツＡＶ１は、３つのバージョンでサーバ１から入手可能であり、またコンテンツＡＶ２は、２つのバージョンで入手可能である。ＡＶ１およびＡＶ２の使用可能なバージョンは、それぞれ異なる送信ビットレートに対応する。サーバ１は、連続した部分の視聴覚コンテンツＡＶ１、ＡＶ２を送信するように適応される。ＡＶ１とＡＶ２の連続した部分はそれぞれ、送信パラメータ（バージョン（ビットレート）や配信速度など）を備える要求をサーバ１に送信することによって、対応する受信機（４、６）によって選ばれる。コントローラ２は、受信機４から報告された情報、および受信機６からの情報を受信する。受信機からの情報は、レンダリングの品質に関連するので、視聴覚コンテンツＡＶ１、ＡＶ２のレンダリングをそれぞれ表す。低いビットレートでは、エンドユーザへのレンダリングの品質が低くなるが、高いビットレートでは、レンダリングの品質が高くなる。
【００７４】
コントローラ２は、受信機の状態およびネットワーク３の状態に従って、１つまたは複数の受信機に１つまたは複数の制御パラメータを送信する。制御パラメータは、コントローラ２によって、受信機４、６、８により報告された情報から定義される。制御パラメータは、それを受信した受信機を構成し、パラメータに応じて、受信パラメータまたは次の要求用の送信パラメータを定義するために受信機によって使用される。定義された送信パラメータは、たとえば、視聴覚コンテンツのバージョン、サーバによるコンテンツの次の部分の配信のため要求されるビットレートまたは配信速度である。コントローラ２によって受信機に送られる制御パラメータは、たとえば受信バッファ最大サイズなど受信機のパラメータを、サーバへの要求とは独立に構成することもできる。この場合、制御パラメータは受信パラメータである。
【００７５】
図５は、本発明の実施形態によるコントローラ２内の方法を示す図である。
【００７６】
ステップＳ１は、適応ストリーミングシステムの初期化である。少なくとも２つの受信機が、サーバ１に要求を送り、サーバ１からの視聴覚コンテンツをダウンロードし、視聴覚コンテンツのレンダリングを達成するために２つの適応ストリーミングセッションを初期化する。少なくとも２つの受信機が、視聴覚コンテンツのいくつかの部分を受信している。２つの受信機は、同じ視聴覚コンテンツをダウンロードしてもよいし、２つの異なる視聴覚コンテンツをそれぞれダウンロードしてもよい。
【００７７】
ステップＳ２で、２つの受信機のうちの１つが、視聴覚コンテンツの受信された部分のレンダリングを表す情報をコントローラ２に報告する。
【００７８】
ステップＳ３で、第２の受信機が、視聴覚コンテンツの受信された部分のレンダリングを表す情報をコントローラ２に報告する。
【００７９】
受信された情報に基づいて、コントローラ２は、適応ストリーミングシステムの性能全体を評価し、ステップＳ４で、１つまたは複数の受信機に送られる少なくとも１つの制御パラメータを評価する。
【００８０】
次いで、コントローラ２は、受信機を構成し、ネットワーク３の使用可能な帯域幅をよりよく分配するために、少なくとも１つの受信機に少なくとも１つの制御パラメータを送る。
【００８１】
有利なことに、実施形態による方法は、１つの受信機または受信機グループによる帯域幅使用の要求を制限し、より使用可能な帯域幅を他の受信機に提供するように１つの受信機または受信機グループを構成させる。
【００８２】
図６は、本発明の実施形態による、受信機内の方法を示す図である。
【００８３】
ステップＳ’１で、受信機は、サーバ１との適応ストリーミングセッションを初期化し、視聴覚コンテンツのダウンロードおよびレンダリングを開始する。
【００８４】
ステップＳ’２で、視聴覚コンテンツの第１の部分を受信した後、受信機は、コントローラ２に、レンダリングを表す１つまたは複数の情報を報告する。情報は、たとえば、コントローラに毎分報告される。コントローラは、多くの（少なくとも２つの）受信機から受信された情報を計算し、受信機に制御パラメータを送る。この制御パラメータは。ステップＳ’３で、受信機によって受信される。
【００８５】
ステップＳ’４で、受信機は、視聴覚コンテンツのバージョンや、サーバ１による配信速度などの送信パラメータを備える要求を送る。要求の送信パラメータは、コントローラ２によって以前に定義された制御パラメータに従って定義される。たとえば、制御パラメータは、次の部分について要求されるコンテンツのバージョンが所与の値より低いビットレートを有さなければならないことを受信機に示す。
【００８６】
ＴＲ−０６９プロトコルの拡張を使用して、コントローラ２から受信機に制御パラメータを運ぶ制御メッセージのデータモデルのいくつかの例が、下記に示される。
【００８７】
【表１】
【００８８】
実施形態によれば、コントローラ２は、視聴覚コンテンツを公平に配信するために、サーバ１と、受信機４、６または８のいずれかとの間のビットレートを調整することができる。
【００８９】
本発明は、実施形態について上記に述べられた実施形態に限定されない。特に、本発明は、多くのサーバと受信機フィールドの間の適応ストリーミングを制御するための方法にも関する。変形によれば、コントローラは、受信機フィールド内のいくつかの受信機グループのパラメータを事前に定義し、次いで、受信された情報に従って受信機の一部を個々に制御する。
【００９０】
別の変形によれば、コントローラは、ランダムアルゴリズムをまず使用して、制御パラメータを定義し、受信機を初期化し、次いで、受信された情報に従って受信機の一部を制御する。
【００９１】
別の変形によれば、コントローラは、いくつかの受信機グループをアドレッシングすることによって受信機を制御し、グループを周期的に再定義する。
【００９２】
有利なことに、コントローラは、受信機の一部に優先権または特権を与える。それは、たとえば、サービスプロバイダへの加入のレベルに従って行われてもよいし、受信機のサブセットに期待されたレンダリングの品質のレベル（たとえばＨＤ品質対通常品質）に応じて行われてもよい。
【００９３】
本発明は、少なくとも１つのサーバから少なくとも２つの受信機に何らかのコンテンツを配信する適応ストリーミングの任意のシステムにも関する。有利なことに、視聴覚コンテンツは、テキスト、マップ、音楽、ビデオ、メタデータ、バイナリデータ（すなわち実行可能アプリケーション）など、任意の種類のコンテンツを備える。
【００９４】
本発明は一般に、データ受信機に関する。本発明は、セットトップボックス、オーディオ／ビデオデコーダを含むゲートウェイ、ラップトップ、およびモバイル機器（携帯電話、携帯情報端末、測位システム）などの装置を備える。
【００９５】
本明細書では、「一実施形態（ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ、ａｎ ｅｍｂｏｄｉｍｅｎｔ）」への言及は、実施形態に関連して述べられた特定の特徴、構造または特性が本発明の少なくとも１つの実装形態に含まれ得ることを意味する。本明細書の様々な場所に「一実施形態では」の語句が現れることは、必ずしもすべてが同じ実施形態に言及するとは限らず、また別個の実施形態または代替的実施形態が、他の実施形態と必ずしも相互排他的であるとは限らない。
【００９６】
特許請求の範囲に現れる参照符号は、例示するためのものにすぎず、特許請求の範囲を制限する効果はないものとする。
【特許請求の範囲】
【請求項１】
サーバ（１）と少なくとも２つの受信機（４、６、８）との間の伝送データレートを制御するためのコントローラ（２）における方法であって、前記サーバ（１）、前記コントローラ（２）および前記少なくとも２つの受信機（４、６、８）はネットワーク（３）に接続され、前記サーバ（１）は、視聴覚コンテンツを表すデータを送信するように適応され、前記視聴覚コンテンツは、前記サーバ（１）から少なくとも２つのバージョンで入手可能であり、前記バージョンはそれぞれ、異なる送信ビットレートに対応し、前記サーバ（１）は、前記視聴覚コンテンツを連続した部分で送信するように適応され、前記連続した部分はそれぞれ、前記少なくとも２つの受信機（４、６、８）によって送られた送信要求に応答して少なくとも２つのバージョンのうちの１つとして選択され、前記送信要求は、送信パラメータを備え、前記方法は、コントローラ（２）において、
第１の受信機（４、６、８）から第１の監視情報を反復して受信するステップであって、前記第１の監視情報は、前記第１の受信機による視聴覚コンテンツのレンダリングの品質レベルを表す、ステップと、
第２の受信機（４、６、８）から第２の監視情報を反復して受信するステップであって、前記第２の監視情報は、前記第２の受信機による視聴覚コンテンツのレンダリングの品質レベルを表す、ステップと、
前記コントローラ（２）から前記受信機（４、６、８）のうちの少なくとも１つに制御パラメータを送信するステップであって、前記制御パラメータは、前記受信機（４、６、８）のうちの少なくとも１つにおいて前記制御パラメータから前記送信要求のうちの少なくとも１つの送信要求の前記送信パラメータ、または前記受信機（４、６、８）のうちの少なくとも１つの受信機の受信パラメータを定義するために前記第１の監視情報および前記第２の監視情報に依存する、ステップと、
を備える、前記方法。
【請求項２】
前記第１の監視情報および前記第２の監視情報のそれぞれは、
前記サーバと前記少なくとも２つの受信機（４、６、８）のうちの１つとの間のデータ伝送ビットレートと、
前記少なくとも２つの受信機（４、６、８）のうちの１つの受信機のデータ受信バッファのサイズと、
前記少なくとも２つの受信機（４、６、８）のうちの１つによる前記視聴覚コンテンツのレンダリングの品質指標と、
所与の時間間隔の間に前記少なくとも２つの受信機（４、６、８）のうちの１つが前記バージョンのうちの１つから前記バージョンのうちの別の１つに切り換わる回数と、
定義された時間間隔の間に少なくとも２つの受信機（４、６、８）のうちの１つによって受信されたバイト数と、
前記視聴覚コンテンツの前記少なくとも２つのバージョンのそれぞれについて、事前定義された時間範囲の間に少なくとも２つの受信機（４、６、８）のうちの１つによって受信されたバイト数と、
を備えるパラメータグループに属する、請求項１に記載の方法。
【請求項３】
前記制御パラメータは、
前記少なくとも２つの受信機（４、６、８）のうちの１つによって前記サーバ（１）に要求されるビットレートの最大値と、
前記少なくとも２つの受信機（４、６、８）のうちの１つによって前記サーバ（１）に要求される前記バージョンのうちの許容されたバージョンのリストと、
前記少なくとも２つの受信機（４、６、８）のうちの１つの受信機の受信バッファの最大サイズと、
前記少なくとも２つの受信機（４、６、８）のうちの１つによって送られた前記要求内で前記サーバ（１）に示される最高速度係数と、
前記少なくとも２つの受信機（４、６、８）のいずれかの受信機の適応ストリーミングアルゴリズムのパラメータと、
を備えるパラメータグループに属する、請求項１または２に記載の方法。
【請求項４】
データを受信するための装置（４）であって、前記データは視聴覚コンテンツを表し、前記視聴覚コンテンツは、異なる送信ビットレートにそれぞれ対応する少なくとも２つのバージョンで入手可能であり、前記視聴覚コンテンツの送信は連続した部分で実行され、前記連続した部分はそれぞれ、前記少なくとも２つの受信機（４、６、８）によって送られた送信要求に応答して、少なくとも２つのバージョンのうちの１つとして選択され、前記送信要求は送信パラメータを備え、前記装置（４）は、
前記装置によって、視聴覚コンテンツのレンダリングの品質を表す監視情報を送るための通信インターフェース（４４）と、
制御パラメータを受信するための通信インターフェース（４４）であって、前記制御パラメータは、前記装置による視聴覚コンテンツのレンダリングの品質を表す前記監視情報に依存する、通信インターフェース（４４）と、
前記受信された制御パラメータから、前記送信要求の前記送信パラメータを計算するためのコンピューティングモジュール（４５）と、
を備える、前記装置。
【請求項５】
前記受信された制御パラメータ、および視聴覚コンテンツのレンダリングの品質を表す前記監視情報を格納するためのメモリ（４２）を備える、請求項４に記載の装置。
【請求項６】
ラップトップ機器である、請求項４または５に記載の装置。
【請求項７】
セットトップボックスである、請求項４または５に記載の装置。
【請求項８】
モバイル端末である、請求項４または５に記載の装置。
【請求項９】
ネットワーク（３）に接続されたサーバ（１）と、前記ネットワーク（３）に接続された少なくとも２つの受信機（４、６、８）との間のデータ伝送レートを制御するための装置（２）であって、前記データは視聴覚コンテンツを表し、前記視聴覚コンテンツは前記サーバ（１）から少なくとも２つのバージョンで入手可能であり、前記バージョンはそれぞれ、異なる伝送ビットレートに対応し、前記サーバ（１）は、前記視聴覚コンテンツを連続した部分で送信するように適応され、前記連続した部分はそれぞれ、前記少なくとも２つの受信機（４、６、８）によって送られた送信要求に応答して、少なくとも２つのバージョンのうちの１つとして選ばれ、前記送信要求は送信パラメータを備え、前記装置は、
第１の受信機（４、６、８）から、前記第１の受信機（４、６、８）による視聴覚コンテンツのレンダリングの品質を表す第１の監視情報を反復して受信するための通信インターフェース（２４）と、
第２の受信機（４、６、８）から、前記第２の受信機（４、６、８）による視聴覚コンテンツのレンダリングの品質を表す第２の監視情報を反復して受信するための通信インターフェース（２４）と、
少なくとも前記第１の反復して受信された監視情報および前記第２の反復して受信された監視情報から制御パラメータを計算するためのコンピューティングモジュール（２５）と、
前記受信機（４、６、８）のうちの少なくとも１つに前記制御パラメータを送信するための通信インターフェース（２４）と、
を備える、前記装置。
【請求項１０】
住宅用ゲートウェイ機器内に置かれる、請求項９に記載の装置。
【請求項１１】
デジタル加入者線アクセス多重化機器内に置かれる、請求項９に記載の装置。
【請求項１２】
サーバ（１）からデータを受信するための受信機（４、６、８）における方法であって、前記データは視聴覚コンテンツを表し、前記視聴覚コンテンツは、前記サーバ（１）から少なくとも２つのバージョンで入手可能であり、前記バージョンはそれぞれ、異なる伝送ビットレートに対応し、前記サーバ（１）は、前記視聴覚コンテンツを連続した部分で送信するように適応され、前記連続した部分はそれぞれ、前記少なくとも２つの受信機（４、６、８）によって送られた送信要求に応答して少なくとも２つのバージョンのうちの１つとして選択され、前記送信要求は送信パラメータを備え、前記方法は、
前記受信機によって、前記視聴覚コンテンツのレンダリングを表す監視情報をリモートコントローラ（２）に送信するステップと、
前記リモートコントローラ（２）から制御パラメータを受信するステップであって、前記制御パラメータは、前記受信機（４、６、８）による前記視聴覚コンテンツのレンダリングを表す前記監視情報に依存する、ステップと、
少なくとも前記制御パラメータから定義された前記送信パラメータを備える要求を前記サーバ（１）に送信するステップと、
を備える、前記方法。
【請求項１３】
制御パラメータを受信する前記ステップは、前記受信機（４、６、８）の少なくとも１つの受信パラメータを更新するステップをさらに備える、請求項１２に記載の方法。
【請求項１】
サーバ（１）と少なくとも２つの受信機（４、６、８）との間の伝送データレートを制御するためのコントローラ（２）における方法であって、前記サーバ（１）、前記コントローラ（２）および前記少なくとも２つの受信機（４、６、８）はネットワーク（３）に接続され、前記サーバ（１）は、視聴覚コンテンツを表すデータを送信するように適応され、前記視聴覚コンテンツは、前記サーバ（１）から少なくとも２つのバージョンで入手可能であり、前記バージョンはそれぞれ、異なる送信ビットレートに対応し、前記サーバ（１）は、前記視聴覚コンテンツを連続した部分で送信するように適応され、前記連続した部分はそれぞれ、前記少なくとも２つの受信機（４、６、８）によって送られた送信要求に応答して少なくとも２つのバージョンのうちの１つとして選択され、前記送信要求は、送信パラメータを備え、前記方法は、コントローラ（２）において、
第１の受信機（４、６、８）から第１の監視情報を反復して受信するステップであって、前記第１の監視情報は、前記第１の受信機による視聴覚コンテンツのレンダリングの品質レベルを表す、ステップと、
第２の受信機（４、６、８）から第２の監視情報を反復して受信するステップであって、前記第２の監視情報は、前記第２の受信機による視聴覚コンテンツのレンダリングの品質レベルを表す、ステップと、
前記コントローラ（２）から前記受信機（４、６、８）のうちの少なくとも１つに制御パラメータを送信するステップであって、前記制御パラメータは、前記受信機（４、６、８）のうちの少なくとも１つにおいて前記制御パラメータから前記送信要求のうちの少なくとも１つの送信要求の前記送信パラメータ、または前記受信機（４、６、８）のうちの少なくとも１つの受信機の受信パラメータを定義するために前記第１の監視情報および前記第２の監視情報に依存する、ステップと、
を備える、前記方法。
【請求項２】
前記第１の監視情報および前記第２の監視情報のそれぞれは、
前記サーバと前記少なくとも２つの受信機（４、６、８）のうちの１つとの間のデータ伝送ビットレートと、
前記少なくとも２つの受信機（４、６、８）のうちの１つの受信機のデータ受信バッファのサイズと、
前記少なくとも２つの受信機（４、６、８）のうちの１つによる前記視聴覚コンテンツのレンダリングの品質指標と、
所与の時間間隔の間に前記少なくとも２つの受信機（４、６、８）のうちの１つが前記バージョンのうちの１つから前記バージョンのうちの別の１つに切り換わる回数と、
定義された時間間隔の間に少なくとも２つの受信機（４、６、８）のうちの１つによって受信されたバイト数と、
前記視聴覚コンテンツの前記少なくとも２つのバージョンのそれぞれについて、事前定義された時間範囲の間に少なくとも２つの受信機（４、６、８）のうちの１つによって受信されたバイト数と、
を備えるパラメータグループに属する、請求項１に記載の方法。
【請求項３】
前記制御パラメータは、
前記少なくとも２つの受信機（４、６、８）のうちの１つによって前記サーバ（１）に要求されるビットレートの最大値と、
前記少なくとも２つの受信機（４、６、８）のうちの１つによって前記サーバ（１）に要求される前記バージョンのうちの許容されたバージョンのリストと、
前記少なくとも２つの受信機（４、６、８）のうちの１つの受信機の受信バッファの最大サイズと、
前記少なくとも２つの受信機（４、６、８）のうちの１つによって送られた前記要求内で前記サーバ（１）に示される最高速度係数と、
前記少なくとも２つの受信機（４、６、８）のいずれかの受信機の適応ストリーミングアルゴリズムのパラメータと、
を備えるパラメータグループに属する、請求項１または２に記載の方法。
【請求項４】
データを受信するための装置（４）であって、前記データは視聴覚コンテンツを表し、前記視聴覚コンテンツは、異なる送信ビットレートにそれぞれ対応する少なくとも２つのバージョンで入手可能であり、前記視聴覚コンテンツの送信は連続した部分で実行され、前記連続した部分はそれぞれ、前記少なくとも２つの受信機（４、６、８）によって送られた送信要求に応答して、少なくとも２つのバージョンのうちの１つとして選択され、前記送信要求は送信パラメータを備え、前記装置（４）は、
前記装置によって、視聴覚コンテンツのレンダリングの品質を表す監視情報を送るための通信インターフェース（４４）と、
制御パラメータを受信するための通信インターフェース（４４）であって、前記制御パラメータは、前記装置による視聴覚コンテンツのレンダリングの品質を表す前記監視情報に依存する、通信インターフェース（４４）と、
前記受信された制御パラメータから、前記送信要求の前記送信パラメータを計算するためのコンピューティングモジュール（４５）と、
を備える、前記装置。
【請求項５】
前記受信された制御パラメータ、および視聴覚コンテンツのレンダリングの品質を表す前記監視情報を格納するためのメモリ（４２）を備える、請求項４に記載の装置。
【請求項６】
ラップトップ機器である、請求項４または５に記載の装置。
【請求項７】
セットトップボックスである、請求項４または５に記載の装置。
【請求項８】
モバイル端末である、請求項４または５に記載の装置。
【請求項９】
ネットワーク（３）に接続されたサーバ（１）と、前記ネットワーク（３）に接続された少なくとも２つの受信機（４、６、８）との間のデータ伝送レートを制御するための装置（２）であって、前記データは視聴覚コンテンツを表し、前記視聴覚コンテンツは前記サーバ（１）から少なくとも２つのバージョンで入手可能であり、前記バージョンはそれぞれ、異なる伝送ビットレートに対応し、前記サーバ（１）は、前記視聴覚コンテンツを連続した部分で送信するように適応され、前記連続した部分はそれぞれ、前記少なくとも２つの受信機（４、６、８）によって送られた送信要求に応答して、少なくとも２つのバージョンのうちの１つとして選ばれ、前記送信要求は送信パラメータを備え、前記装置は、
第１の受信機（４、６、８）から、前記第１の受信機（４、６、８）による視聴覚コンテンツのレンダリングの品質を表す第１の監視情報を反復して受信するための通信インターフェース（２４）と、
第２の受信機（４、６、８）から、前記第２の受信機（４、６、８）による視聴覚コンテンツのレンダリングの品質を表す第２の監視情報を反復して受信するための通信インターフェース（２４）と、
少なくとも前記第１の反復して受信された監視情報および前記第２の反復して受信された監視情報から制御パラメータを計算するためのコンピューティングモジュール（２５）と、
前記受信機（４、６、８）のうちの少なくとも１つに前記制御パラメータを送信するための通信インターフェース（２４）と、
を備える、前記装置。
【請求項１０】
住宅用ゲートウェイ機器内に置かれる、請求項９に記載の装置。
【請求項１１】
デジタル加入者線アクセス多重化機器内に置かれる、請求項９に記載の装置。
【請求項１２】
サーバ（１）からデータを受信するための受信機（４、６、８）における方法であって、前記データは視聴覚コンテンツを表し、前記視聴覚コンテンツは、前記サーバ（１）から少なくとも２つのバージョンで入手可能であり、前記バージョンはそれぞれ、異なる伝送ビットレートに対応し、前記サーバ（１）は、前記視聴覚コンテンツを連続した部分で送信するように適応され、前記連続した部分はそれぞれ、前記少なくとも２つの受信機（４、６、８）によって送られた送信要求に応答して少なくとも２つのバージョンのうちの１つとして選択され、前記送信要求は送信パラメータを備え、前記方法は、
前記受信機によって、前記視聴覚コンテンツのレンダリングを表す監視情報をリモートコントローラ（２）に送信するステップと、
前記リモートコントローラ（２）から制御パラメータを受信するステップであって、前記制御パラメータは、前記受信機（４、６、８）による前記視聴覚コンテンツのレンダリングを表す前記監視情報に依存する、ステップと、
少なくとも前記制御パラメータから定義された前記送信パラメータを備える要求を前記サーバ（１）に送信するステップと、
を備える、前記方法。
【請求項１３】
制御パラメータを受信する前記ステップは、前記受信機（４、６、８）の少なくとも１つの受信パラメータを更新するステップをさらに備える、請求項１２に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１３−９８９８２（Ｐ２０１３−９８９８２Ａ）
【公開日】平成２５年５月２０日（２０１３．５．２０）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−２３４７５５（Ｐ２０１２−２３４７５５）
【出願日】平成２４年１０月２４日（２０１２．１０．２４）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
【公開日】平成２５年５月２０日（２０１３．５．２０）
【国際特許分類】
【出願番号】特願２０１２−２３４７５５（Ｐ２０１２−２３４７５５）
【出願日】平成２４年１０月２４日（２０１２．１０．２４）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
[ Back to top ]