JP2016165134A - アダプティブ・ストリーミングのマルチパス配信 - Google Patents

Abstract

【課題】複数の通信経路を介してアダプティブ・ストリーミング技術によってコンテンツを配信する方法を提供する。
【解決手段】第１の経路Ｐ１上の第１の利用可能なビット・レートＢＲ１および前記第２の経路Ｐ２上の第２の利用可能なビット・レートＢＲ２を測定するステップと、前記ＢＲ１およびＢＲ２に基づいて、ビット・レートＢＲＡ、ＢＲＢの中の要求ビット・レートＲＢＲを決定するステップと、要求ビット・レートＲＢＲによって識別されるチャンクの第１の部分を受信するための第１の要求を前記第１の経路を介して送信し、前記チャンクの第２の部分を受信するための第２の要求を前記第２の経路を介して送信する、前記チャンクの前記第１の部分と前記第２の部分とが相補的であるステップと、前記第１の経路を介して前記要求した第１の部分を受信し、前記第２の経路を介して前記要求した第２の部分を受信するステップとを含む。
【選択図】図２

Description

本発明は、一般にアダプティブ・ストリーミングに関し、特に、複数の通信経路を介してアダプティブ・ストリーミング技術によってコンテンツを配信する方法およびこの方法を実施する装置に関する。

本項は、以下で述べ、且つ／または特許請求する本発明の様々な態様に関係する可能性がある様々な技術的態様を、読者に紹介するための項である。この議論は、本発明の様々な態様をより理解しやすくする背景情報を読者に与えるのに役立つと考えられる。従って、以下の記述は、この点に照らして読まれるべきものであり、従来技術を承認するものとして読まれるべきものではないことを理解されたい。

メディア配信ストリーミング解決方法は、主に、ＩＥＴＦ ＲＦＣ ２３２６に定義されるリアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）、Ｍｉｃｒｏｓｏｆｔ社のプロプライエタリ・プロトコルであるＭｉｃｒｏｓｏｆｔ Ｍｅｄｉａ Ｓｅｒｖｅｒ（ＭＭＳ）、またはＡｄｏｂｅ Ｓｙｓｔｅｍｓ社のプロプライエタリ・プロトコルであるＲｅａｌ Ｔｉｍｅ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｒｏｌ（ＲＴＭＰ）などのプロトコルに基づいている。

近年、ＨＴＴＰプロトコルに基づくアダプティブなストリーミング技術が、Ｍｏｖｅ Ｎｅｔｗｏｒｋｓ社の「Ｍｏｖｅ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍ」、Ａｐｐｌｅ社の「ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ」およびＭｉｃｒｏｓｏｆｔ社の「ＩＩＳ（Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅｓ） Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ」など、様々な種類（ｆｌａｖｏｒ）で出現している。これらのストリーミング解決方法でＨＴＴＰプロトコルを使用することの利点は、ＮＡＴとファイアウォールをシームレスにクロスオーバすることができる点である。ＨＴＴＰアダプティブ・ストリーミング技術は、帯域幅の制約に適合するように継続的且つ洗練された方法でビデオ品質をアップグレードまたはダウングレードすることにより、利用可能な帯域幅に関するネットワークの不規則な挙動を補償する方法を提供する。

さらに詳細には、Ｍｏｖｅ Ｎｅｔｗｏｒｋｓ社のＷＯ２００５／１０９２２４ Ａ２には、クライアント側にあり、ストリーミングするメディアを、低ビット・レートから高ビット・レートでそれぞれ符号化される複数のストリームレット（チャンクとも呼ばれる）として予め構成することにより変動するネットワーク帯域幅に適合することができるＡｇｅｎｔ Ｃｏｎｔｒｏｌｌｅｒ Ｍｏｄｕｌｅの機構が記載されている。利用可能なネットワーク帯域幅およびその他の何らかの追加情報に従って、Ａｇｅｎｔ Ｃｏｎｔｒｏｌｌｅｒ Ｍｏｄｕｌｅに組み込まれたモニタリング・ツールは、ＨＴＴＰプロトコルを使用して、ＴＣＰ／ＩＰ接続を介してストリーミングするのに最も適したチャンクを送信するようにサーバに要求する。基本チャンク毎に、Ａｇｅｎｔ Ｃｏｎｔｒｏｌｌｅｒ Ｍｏｄｕｌｅに従って、品質がアップシフト（ｕｐ−ｓｈｉｆｔ）またはダウンシフト（ｄｏｗｎ−ｓｈｉｆｔ）される。

Ｍｏｖｅ Ｎｅｔｗｏｒｋｓ社のＷＯ２００９／０２０５５２ Ａ１には、クライアントが、クライアントと単一のサーバの間の複数の接続を使用して、一度に複数のストリームレットまたはその複数の部分の「並列検索」方法を実行するシステムが開示されている。

２００９年３月のＭｉｃｒｏｓｏｆｔ社のＡｌｅｘ ＺａｍｂｅｌｌｉによるＩＩＳ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ Ｔｅｃｈｎｉｃａｌ Ｏｖｅｒｖｉｅｗには、ＴＣＰ／ＩＰ接続によるＨＴＴＰプロトコルに基づくＩＩＳ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ技術が記載されている。サーバによってストリーミングされるメディアは、例えば１秒から１０秒の持続時間を表す複数のチャンクに予め分割される。次いで、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣ規格に従って異なるビット・レートでこれらのチャンクを符号化し、ＭＰ４ファイル・フォーマット・コンテナ内に記憶する。ネットワーク帯域幅の変動に応じてビット・レートを選択し、対応するチャンクをサーバにシームレスに要求する機構は、アプリケーション・コード、すなわちＳｉｌｖｅｒｌｉｇｈｔアプリケーションを介して完全にクライアント側に実装される。ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇは、接続速度の変化に応じた異なるデータ・レートのストリーム間の動的切替えに対応している。

Ａｐｐｌｅ社は、２００９年１０月に、「ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ ｄｒａｆｔ−ｐａｎｔｏｓ−ｈｔｔｐ−ｌｉｖｅ−ｓｔｒｅａｍｉｎｇ−０２」と題する、ＨＴＴＰストリーミング方法の仕様に関するインターネット・ドラフトをＩＥＴＦに提出した。このＨＴＴＰストリーミング・アーキテクチャは、３つの柱を基礎としている。すなわち、サーバと、ウェブ・サーバまたはウェブ・キャッシュ・システムを介した配信と、クライアントである。ストリーミングされるメディアは、Ｈ．２６４で符号化されたビデオおよびＡＡＣで符号化されたオーディオである。サーバにおいて、当該メディアは、ＭＰＥＧ−ＴＳコンテナでカプセル化され、Ａｐｐｌｅストリーム・セグメンタ（ｓｔｒｅａｍ ｓｅｇｍｅｎｔｅｒ）と呼ばれる特定のツールで持続時間の等しい複数のチャンクにフラグメント化される。このツールは、チャンク・プレイリストを構成する^＊.ｔｓファイルおよびインデックス・ファイル^＊；ｍ３ｕ８にセーブされるチャンクを生成する。次いで、クライアントは、ＵＲＬポインタのおかげでこのインデックス・ファイルを最初にフェッチする。インデックス・ファイルは、利用可能なメディア・ファイルの位置、復号鍵、および利用可能な任意の代替ストリームを指定している。選択したストリームについて、クライアントは、利用可能なメディア・ファイルのそれぞれを順番にダウンロードする。

ＨＴＴＰアダプティブ・ストリーミング方法は、一般に、ネットワークの輻輳に応じてエンド・ユーザーのメディア視聴エクスペリエンスを適応させることを指向している。実際に、クライアント装置が測定するネットワーク帯域幅が減少するとすぐに、クライアント装置は、ネットワーク帯域幅要件に関する制限の少ないチャンク、すなわち「低帯域幅チャンク」を要求する。逆に、輻輳問題が軽減されると、クライアント装置は、ネットワーク帯域幅要件に関する制限の多いチャンク、すなわち「高帯域幅チャンク」を要求する。

図１ａは、従来技術によるアダプティブ・ストリーミング方法の主要なステップを示す図である。図１ａは、ビデオ・コンテンツが、対応ビット・レートが次第に増大していく（これは品質が漸進的に向上することを意味する）４つのバージョン（バージョンＡ、バージョンＢ、バージョンＣおよびバージョンＤ）に（事前）符号化されていることを示している。符号化ビデオ・コンテンツは、あるビット・レートから別のビット・レートへのシームレスな切替えを可能にする複数のチャンクに分割される。全てのビデオ・チャンクは、同一の一定の持続時間に対応する。これらのチャンクは、ある程度大きいチャンクであり、従って、対応ビット・レートに応じて、要求される帯域幅がより高く／低くなり、ビデオ品質はより高く／低くなる。サーバＣＳ１に記憶されるコンテンツの全てのバージョン（バージョンＡ、バージョンＢ、バージョンＣおよびバージョンＤ）が、決まった数のチャンク、図１ａでは１４個のチャンクに分割される。

図１ａには、従来技術による方法の第１のステップが示してある。すなわち、クライアント装置ＣＤが、クライアント装置ＣＤをサーバＣＳ１に接続する経路Ｐ１のビット・レートＢＲ１をモニタリングする。

第２のステップで、クライアント装置ＣＤは、測定したビット・レートＢＲ１に準拠した要求ビット・レートＲＢＲを決定する。例えば、要求ビット・レートＲＢＲは、測定したビット・レートＢＲ１以下となる、対応ビット・レートＢＲＡ、ＢＲＢ、ＢＲＣおよびＢＲＤのうちの最大のビット・レートである。

第３のステップで、クライアント装置は、経路Ｐ１を介して、時間指標ｉ（ここでは１＜ｉ＜１４）および要求ビット・レートＲＢＲによって識別されるチャンクを要求する。

第４のステップで、クライアント装置ＣＤは、やはり経路Ｐ１を介して、サーバＣＳ１から要求ビット・レートＲＢＲで前記チャンクｉを受信する。

これら４つのステップは、チャンクが必要とされるたびに繰り返される。

図１ｂは、上述した従来技術のアダプティブ・ストリーミング方法の場合のビット・レートの時間的進展を示す図である。

図１ｂの曲線は、モニタリングしたビット・レートＢＲ１を示している。この曲線の下に、サーバからダウンロードされるチャンクが示してある。通常のアダプティブ・クライアントは、利用可能なビット・レート（または帯域幅）を継続的にモニタリングして、次に取り出すチャンクに対して、利用可能なビット・レートＢＲ１以下となる要求ビット・レートを選択する。もちろん、実施態様および環境（ネットワーク技術、アプリケーション）に応じて、ストラテジが保守的になる、すなわち、クライアントが、一定時間が経った後でのみビット・レートの高いチャンクを要求して平滑なアップグレード遷移が確実に行われるようにし、急速なダウングレード遷移を意味する帯域幅の減少を検出すると直ちにビット・レートの低いチャンクを要求することもあるし、大胆になることもある。図１ｂでは、符号化コンテンツの４つのバージョンに対応するものとして示してある４つの異なるビット・レートがある。

上述のアダプティブ・ストリーミング解決方法では、クライアント装置ＣＤによってチャンク毎に取得されたビデオ・ストリームは、時間的に一貫した品質を有していない。帯域幅が減少したときには、ユーザーのエクスペリエンスが損なわれる可能性があることが分かる。ビデオが中断することはまったく、またはほとんどないが、品質は極めて低くなる可能性がある。転送されたコンテンツの品質を低下させる以外に、この状況を回避する具体的な解決方法はない。受信側のバッファを大きくすれば、チャンクの配信に予想以上の時間がかかるドライ・エフェクトは避けられるが、一時的に帯域幅の可用性が低下する問題に対しては役に立たない。

本発明の目的の１つは、ともにクライアントによって制御される少なくとも２つの（独立した）配信経路を使用することにより、帯域幅の一時的な不足（またはビット・レートの急速な低下）に対処しようとすることである。これらの配信経路は、可能な限り直交する伝送特性を呈していなければならない。これは、１つのクライアント（例えば端末）を、少なくとも２つの異なるアクセス・ネットワーク（例えばブロードバンドｘＤＳＬおよびセルラ３Ｇ／ＬＴＥ）を介してサーバに接続し、且つ／または少なくとも２つの同様のアクセス・ネットワーク（場合によっては２つの異なるインターネット・サービス・プロバイダによって管理されるものであることもある）に接続されたサーバに接続することで実現することができる。あるいは、１つのクライアントを、それぞれ異なるアクセス・ネットワークに接続された少なくとも２つのサーバに接続することで、実現することができる。後者の方が容易に実施できる可能性があり、発明者等は、本発明では、この実施態様に注目する。本明細書の以下では、サーバは、専用リンク／経路に接続された物理的なボックス、または専用経路／リンクを介して接続された論理的なエンティティでもあるものとみなす。

本発明は、少なくとも２つのリンク／経路を備えて適用されることが分かる。１つのマシンが複数のサーバのホストとなる場合には、当該マシンは、マルチホーミングに対応していなければならない（すなわち、専用ネットワーク・アドレス、例えばＩＰネットワーク・アドレスをそれぞれ有する複数のネットワーク・インタフェースに接続することができる）。

チャンク・ファイルを１つのサーバに記憶する代わりに、これらのチャンク・ファイルを、２つの異なる通信経路を介してアクセス可能な２つのサーバに記憶する（各サーバは、それ自体のネットワーク・アクセスおよびそれ自体のＩＰアドレスを有する）。

クライアントは、これらの経路の１つで利用可能なビット・レートが低下していることを検出すると、次のチャンクまたは現在のチャンクの次の部分を、代替のサーバからダウンロードすることができる。これは、フェイルオーバ・アルゴリズム（１つの主経路を使用し、主経路で問題が生じると代替経路を使用する）、負荷分割アルゴリズム（両方の経路を同時に使用し、チャンクの一部分を一方のサーバから配信し、残りの部分を他方のサーバから配信する）、または帯域幅制限アルゴリズム（大域的なビット・レートの目標を達成するために付加的なビット・レートが必要になる場合に備えて、主経路Ｐ１と追加経路Ｐ２およびＰ３とによって、最小の大域的なビット・レートを保証する）によって実施することができる。

本発明が達成しようとする技術的課題は、通信経路上での帯域幅の可用性の一時的な低下によって生じる諸問題の影響を受けにくくすることによって、アダプティブ・ストリーミング方法を改善することである。

従って、第１の態様によれば、本発明は、少なくとも第１および第２の通信インタフェースＣＩ１、ＣＩ２を含むクライアント装置ＣＤにおいてレンダリングされるコンテンツを提供する方法であり、前記第１および第２の通信インタフェースＣＩ１、ＣＩ２が通信アドレスを有し、前記コンテンツが、通信アドレスを有する少なくとも第１および第２のサーバ通信インタフェースＳＩ１、ＳＩ２を介して前記クライアント装置ＣＤからアクセス可能であり、第１の経路Ｐ１が、前記第１の通信インタフェースＣＩ１の通信アドレスおよび前記第１のサーバ通信インタフェースＳＩ１のアドレスによって識別され、第２の経路Ｐ２が、前記第２の通信インタフェースＣＩ２の通信アドレスおよび前記第２のサーバ通信インタフェースＳＩ２のアドレスによって識別され、前記コンテンツが、対応ビット・レートＢＲＡ、ＢＲＢの制約に対応する符号化品質を有する少なくとも２つのバージョンで利用可能であり、前記少なくとも２つのバージョンのそれぞれが、前記コンテンツの同一のレンダリング持続時間に対応する複数のチャンクに時間的に分割され、チャンクが、時間指標ｉおよび前記対応ビット・レートＢＲＡ、ＢＲＢのうちの１つによって識別され、前記コンテンツが、前記第１および第２の経路Ｐ１、Ｐ２を介して前記クライアント装置ＣＤから同時にアクセス可能である方法に関する。

本発明によれば、この方法は、前記クライアント装置ＣＤにおいて、
前記第１の経路Ｐ１上の第１の利用可能なビット・レートＢＲ１および前記第２の経路Ｐ２上の第２の利用可能なビット・レートＢＲ２を測定するステップＳ１と、
前記測定した第１の利用可能なビット・レートＢＲ１および前記測定した第２の利用可能なビット・レートＢＲ２に基づいて、前記対応ビット・レートＢＲＡ、ＢＲＢの中の要求ビット・レートＲＢＲを決定するステップＳ２と、
前記時間指標ｉおよび前記要求ビット・レートＲＢＲによって識別されるチャンクの第１の部分を受信するための第１の要求を前記第１の経路Ｐ１を介して送信し、前記チャンクの第２の部分を受信するための第２の要求を前記第２の経路Ｐ２を介して送信するステップＳ３であり、前記チャンクの前記第１の部分と前記第２の部分とが相補的であるステップＳ３と、
前記第１の経路Ｐ１を介して前記要求した第１の部分を受信し、前記第２の経路Ｐ２を介して前記要求した第２の部分を受信するステップＳ４と、を含む。

従って、第２の態様によれば、本発明は、少なくとも第１および第２の通信インタフェースＣＩ１、ＣＩ２を含む、レンダリングするコンテンツを受信するクライアント装置ＣＤであり、前記第１および第２の通信インタフェースＣＩ１、ＣＩ２が通信アドレスを有し、前記コンテンツが、通信アドレスを有する少なくとも第１および第２のサーバ通信インタフェースＳＩ１、ＳＩ２を介して前記クライアント装置ＣＤからアクセス可能であり、第１の経路Ｐ１が、前記第１の通信インタフェースＣＩ１の通信アドレスおよび前記第１のサーバ通信インタフェースＳＩ１のアドレスによって識別され、第２の経路Ｐ２が、前記第２の通信インタフェースＣＩ２の通信アドレスおよび前記第２のサーバ通信インタフェースＳＩ２のアドレスによって識別され、前記コンテンツが、対応ビット・レートＢＲＡ、ＢＲＢの制約に対応する符号化品質を有する少なくとも２つのバージョンで利用可能であり、前記少なくとも２つのバージョンのそれぞれが、前記コンテンツの同一の持続時間に対応する複数のチャンクに時間的に分割され、チャンクが、時間指標ｉおよび前記対応ビット・レートＢＲＡ、ＢＲＢによって識別され、前記コンテンツが、前記第１および第２の経路Ｐ１、Ｐ２を介して前記クライアント装置ＣＤから同時にアクセス可能であるクライアント装置ＣＤに関する。

本発明によれば、このクライアント装置ＣＤは、
前記第１の経路Ｐ１上の第１の利用可能なビット・レートＢＲ１および前記第２の経路Ｐ２上の第２の利用可能なビット・レートＢＲ２を測定する手段と、
前記測定した第１の利用可能なビット・レートＢＲ１および前記測定した第２の利用可能なビット・レートＢＲ２に基づいて、前記対応ビット・レートＢＲＡ、ＢＲＢの中の要求ビット・レートＲＢＲを決定する手段と、
前記時間指標ｉおよび前記要求ビット・レートＲＢＲによって識別されるチャンクの第１の部分を受信するための第１の要求を前記第１の経路Ｐ１を介して送信し、前記チャンクの第２の部分を受信するための第２の要求を前記第２の経路Ｐ２を介して送信する手段であり、前記チャンクの前記第１の部分と前記第２の部分とが相補的である手段と、
前記第１の経路Ｐ１を介して前記要求した第１の部分を受信し、前記第２の経路Ｐ２を介して前記要求した第２の部分を受信する手段と、を含む。

本発明は、複数のサーバを切り替えて使用する、または同時に使用することによって、従来技術のアダプティブ・ストリーミング方法を改善し、
全体的な品質の向上、
クライアント側から見たサービスのロバストネスの向上、および
ＳＶＣに従ってチャンクが符号化された場合のサーバ側から見たサービス・スケーラビリティの向上、
を可能にすることを提案する。

本発明の別の利点は、既知のストリーミング装置のアーキテクチャとの互換性にある。本発明による方法は、再生するストリームを受信するプレーヤにいかなる修正も加えることなく、従来技術によってサーバとクライアントの間で実施することができる。

本発明は、添付の図面を参照して、いかなる意味でも限定的ではない以下の実施例および実行例を用いて、本発明について説明する。これにより、本発明はよりよく理解されるであろう。

クライアント装置ＣＤが、上述の従来技術によるアダプティブ・ストリーミング方法を用いてコンテンツをサーバに要求する様子を示す図である。 評価ビット・レートに関して、上述の従来技術のアダプティブ・ストリーミング方法に対応するビット・レートの時間的進展を示す図である。 実施例によるマルチパス・アダプティブ・ストリーミング方法の実施態様を示す図である。 本実施例によるクライアント装置を示すブロック図である。 同時方法をこうして用いた、本実施例によるアダプティブ・ストリーミング方法の測定した利用可能なビット・レートの時間的進展を示す図である。 本実施例によるアダプティブ・ストリーミング方法のビット・レートの時間的進展を示す図である。 フェイルオーバ方法をこうして用いた、本実施例によるアダプティブ・ストリーミング方法のビット・レートの時間的進展を示す図である。

図３ｂに示すブロックは、純粋に機能的なエンティティであり、必ずしも物理的に分離したエンティティに対応するわけではない。すなわち、これらは、ハードウェアの形態で開発することもできるし、ソフトウェアの形態で開発することもできるし、あるいは１つまたは複数の集積回路として実施することもできる。

本発明の図面および説明は、本発明を明快に理解する上で関わりのある要素を例示するために簡略化してあり、分かりやすくするために、通常のディジタル・マルチメディア・コンテンツを配信する方法およびシステムに見られるその他の多くの要素が省略されていることを理解されたい。これらの要素は当技術分野では周知であるので、これらの要素の詳細な議論は、本明細書では与えていない。本明細書の開示は、当業者に既知のこれら全ての変形形態および修正形態も対象とする。

本項では、実施例による、クライアント装置ＣＤにコンテンツを配信するためのマルチパス・アダプティブ・ストリーミング方法について説明する。この方法は、図２に示してある。

本実施例によるクライアント装置が、図２に示してある。クライアント装置ＣＤは、第１の経路Ｐ１および第２の経路Ｐ２を介してコンテンツにアクセスする。第１の経路Ｐ１は、クライアント装置ＣＤの第１の通信インタフェースＣＩ１の通信アドレスおよび第１のサーバ通信インタフェースＳＩ１の通信アドレスによって定義される。従って、第２の経路Ｐ２は、クライアント装置ＣＤの第２の通信インタフェースＣＩ２の通信アドレスおよび第２のサーバ通信インタフェースＳＩ２の通信アドレスによって定義される。

単一のクライアント装置ＣＤが、第１の通信インタフェースＣＩ１および第２の通信インタフェースＣＩ２を含むので有利である。

第１のサーバ通信インタフェースＳＩ１および第２のサーバ通信インタフェースＳＩ２は、２つの異なるサーバＣＳ１およびＣＳ２に含まれる。この状況は、図２に示してある。

サーバＣＳ１およびＣＳ２は、ＨＴＴＰサーバであると有利である。

クライアントは、プレーヤ４（図示せず）にも接続されている。サーバ側では、クライアント要求に応じて、ＨＴＴＰプロトコルを用いてＴＣＰ／ＩＰ接続を介してチャンクがストリーミングされる。クライアントは、以下に述べるアルゴリズムに従って、且つ経路のビット・レート測定値に基づいて、チャンクの一部分を要求する。クライアントは、チャンクの全体を受信した後で、復号およびレンダリングしなければならない。クライアント装置ＣＤは、第１の通信インタフェースＣＩ１および第２の通信インタフェースＣＩ２を介して同時にコンテンツを要求することができる。

コンテンツは、前記経路Ｐ１およびＰ２を介してダウンロードすることができることが分かる。以下では、前記コンテンツが異なるサーバＣＳ１およびＣＳ２で複製される状況、換言すれば、２つのサーバ通信インタフェースＳＩ１およびＳＩ２が異なるサーバＣＳ１およびＣＳ２上に位置している状況について述べる。この状況は、サーバ通信インタフェースＳＩ１およびＳＩ２が、コンテンツが記憶されている単一のサーバＣＳ１上に位置している場合と同様であるが、ただ１つ、コンテンツが２つの異なるサーバ上に複製されない点が異なる。このことが、データ冗長性を与え、セキュリティに寄与する。

コンテンツは、例えば、ダウンロードされてクライアント側でレンダリングされるビデオ・コンテンツまたはオーディオ・コンテンツである。例えば、クライアント装置ＣＤは、ダウンロードしたならば、前記コンテンツを、再生するためにチャンク毎にプレーヤ（図２には図示せず）に伝送する。

コンテンツは、例えば、コンテンツ準備ツールによって生成される。このツールは、少なくとも２種類の目標（または対応）ビット・レート（例えばＢＲＡ＝３００ｋｂｐｓ、ＢＲＢ＝６００ｋｂｐｓ、ＢＲＣ＝１０００ｋｂｐｓ、ＢＲＤ＝２０００ｋｂｐｓ）で圧縮ビデオ・コンテンツおよび圧縮オーディオ・コンテンツ（それぞれＨ２６４およびＭＰ３）を生成する。コンテンツ準備ツールは、これらを多重化して、対応ビット・レート毎にＭＰＥＧ ＴＳ（トランスポート・ストリーム）チャンク・シリーズを生成する。

全てのチャンクは、例えば各目標ビット・レートで２秒など、コンテンツの同一の持続時間に対応する。チャンクは、例えば、時間指標ｉ（この例では１＜ｉ＜１４）と、対応ビット・レートＢＲＡ、ＢＲＢ、ＢＲＣおよびＢＲＤの１つとによって識別される。

以下の全ての図面において、チャンクは四角形の枠として表してある。前記枠の水平方向のサイズは全て同じであり、上述の「同一の持続時間」に対応する。前記四角形の枠の垂直方向のサイズは、前記チャンクの質を示しており、前記対応ビット・レートＢＲＡ、ＢＲＢ、ＢＲＣおよびＢＲＤのうちの１つに対応する。１つのチャンク・シリーズに属する全てのチャンクは、同一の垂直方向サイズを有する。しかし、１つのチャンク・シリーズに属するチャンクのサイズは、必ずしも同じでなくてもよい。１つのシリーズ内の異なる時間指標で識別されるチャンクのサイズは、コンテンツの時間的進展によって決まる。

チャンク・シリーズは、図２に示すように両サーバＣＳ１およびＣＳ２に記憶され、「バージョンＡ」、「バージョンＢ」、「バージョンＣ」および「バージョンＤ」で識別される。両サーバＣＳ１およびＣＳ２に記憶される、選択した１つの識別子で表されるチャンクは全て、時間指標ｉを除けば同じである。

２つのサーバＣＳ１およびＣＳ２は、２つの独立した経路（Ｐ１、Ｐ２）を構成する２つの異なるアクセス・ネットワークを介して、クライアント装置ＣＤに接続される。

接続の確立時には、クライアント装置ＣＤは、サーバＣＳ１およびＣＳ２のうちの少なくとも一方からマニフェスト・ファイルを受信する。このマニフェスト・ファイルは、対応ビット・レートＢＲＡ、ＢＲＢ、ＢＲＣおよびＢＲＤのリストを含み、このリストは、対応ビット・レートＢＲＡ、ＢＲＢ、ＢＲＣおよびＢＲＤのそれぞれについて、チャンクの総数およびチャンク・サイズを含む。

代替サーバ（または代替サーバの通信インタフェースのアドレス）のリストが前記マニフェスト・ファイルで提供されると有利である。

図３ａは、本実施例によるクライアント装置ＣＤにコンテンツを提供する方法の４つの主要ステップを示す図である。

第１のステップＳ１で、クライアント装置ＣＤは、経路Ｐ１およびＰ２上で利用可能なビット・レートをモニタリングする。利用可能なビット・レートＢＲ１は、経路Ｐ１上で継続的に測定され、利用可能なビット・レートＢＲ２は、経路Ｐ２上で測定される。

ビット・レートＢＲ１およびＢＲ２は、チャンク持続時間以下の周期で定期的に測定されると有利である。ここで述べる例では、この周期は２秒である。

第１の利用可能なビット・レートＢＲ１および第２の利用可能なビット・レートＢＲ２を測定するステップＳ１は、前記第１および第２の経路Ｐ１、Ｐ２を介してクライアント装置ＣＤから送信された要求ならびに前記要求に応答して前記第１および第２の経路Ｐ１、Ｐ２を介してサーバＣＳ１、ＣＳ２から送信される確認メッセージの往復時間を計算することにある。

第２のステップＳ２で、クライアント装置ＣＤは、第１および第２のビット・レートＢＲ１、ＢＲ２の測定値に基づいて、対応ビット・レートＢＲＡ、ＢＲＢ、ＢＲＣおよびＢＲＤの中から要求ビット・レートＲＢＲを決定する。要求ビット・レートＲＢＲは、マニフェスト・ファイルに定義されるように、対応ビット・レートＢＲＡ、ＢＲＢ、ＢＲＣおよびＢＲＤのみの中から選択される。要求ビット・レートＲＢＲは、要求されたチャンクのビット・レートを規定する。

この方法は、クライアント装置ＣＤが経路Ｐ１、Ｐ２のうちの少なくとも一方を介して対応ビット・レートＢＲＡ、ＢＲＢのリストを受信するステップと、各対応ビット・レートＢＲＡ、ＢＲＢ毎にチャンクのサイズを受信するステップとをさらに含むと有利である。

クライアント装置ＣＤは、第１および第２の経路Ｐ１、Ｐ２の少なくとも一方を介して対応ビット・レートＢＲＡ、ＢＲＢに関する情報を受信し、各対応ビット・レートＢＲＡ、ＢＲＢ毎にチャンクのサイズに関する情報を受信する手段をさらに含むと有利である。

要求ビット・レートＲＢＲを決定するステップＳ２は、測定した第１の利用可能なビット・レートＢＲ１と測定した第２の利用可能なビット・レートＢＲ２の和ＳＵＭからプロビジョン（ｐｒｏｖｉｓｉｏｎ）を引いた値以下となる、対応ビット・レートＢＲＡ、ＢＲＢ、ＢＲＣおよびＢＲＤの中で最大のビット・レートを選択することにある。

要求ビット・レートＲＢＲを決定する手段は、測定した第１の利用可能なビット・レートＢＲ１と測定した第２の利用可能なビット・レートＢＲ２の和ＳＵＭを評価するようになされており、この手段は、測定した第１の利用可能なビット・レートＢＲ１と測定した第２の利用可能なビット・レートＢＲ２の和ＳＵＭからプロビジョンを引いた値以下となる、対応ビット・レートＢＲＡ、ＢＲＢの中で最大のビット・レートを選択するようになされていると有利である。

第３のステップＳ３で、クライアント装置ＣＤは、時間指標ｉおよび要求ビット・レートＲＢＲで識別されるチャンクを求める要求を、両サーバＣＳ１およびＣＳ２にそれぞれ経路Ｐ１およびＰ２を介して送信する。さらに詳細には、クライアント装置ＣＤは、チャンクの第１の部分を求める要求を要求ビット・レートＲＢＲで経路Ｐ１を介してサーバＣＳ１に送信し、チャンクの第２の部分を求める要求を、経路Ｐ２を介して第２のサーバＣＳ２に送信する。チャンクの前記第１の部分と第２の部分は、相補的である。

「相補的」という用語は、第１の部分と第２の部分との間に重複がなく、第１の部分と第２の部分を合わせることで完全なチャンクができあがることを述べるための用語である。

第４のステップＳ４は、クライアント装置ＣＤが、要求した第１の部分と要求した第２の部分をそれぞれ第１の経路Ｐ１および第２の経路Ｐ２を介して同時に受信することにある。経路Ｐ１およびＰ２は、チャンクを提供するために同時に使用される。

「同時に」という用語は、１つのチャンクの全体をダウンロードするために、並列な経路Ｐ１およびＰ２の両方が同時に使用されることを強調するための用語である。経路Ｐ１とＰ２の両方でダウンロードされるチャンクの部分は存在しない。

本実施例によるクライアント装置ＣＤを、図３ｂに示す。クライアント装置ＣＤは、第１のネットワークを介して接続されるサーバＣＳ１の第１のサーバ通信インタフェースと通信するためのプロトコル・スタックを含む、第１のネットワークに対する第１のインタフェースＣＩ１と、第２のネットワークを介して接続されるサーバＣＳ２の第２のサーバ通信インタフェースと通信するためのプロトコル・スタックを含む、第２のネットワークに対する第２のインタフェースＣＩ２とを含む。具体的には、第１および第２のネットワークは、インターネットである。もちろん、第１および第２のネットワークは、クライアントがサーバと通信することを可能にするその他の任意のタイプのネットワークであってもよい。

クライアント装置ＣＤは、コンテンツを復号してレンダリングするようになされたプレーヤに接続するための第３のインタフェース１６も含む。もちろん、第３のインタフェースは、複数のプレーヤへの接続を可能にするものであってもよい。第３のインタフェースは、１つまたは複数のプレーヤへの接続を可能にするネットワークに対するインタフェースとすることができる。クライアント装置ＣＤは、クライアントに記憶されたアプリケーションを処理するためのプロセッサ１１も含む。クライアント装置ＣＤは、さらに、サーバから受信したチャンクまたはチャンクの一部分をプレーヤに伝送する前にバッファリングするためのメモリなどの記憶手段１２も含む。具体的には、メモリは、揮発性メモリである。もちろん、図示していないが、クライアントは、クライアント上で動作するアプリケーションを記憶するための不揮発性メモリを含む。クライアントは、ゲートウェイ装置において実施することができる。クライアント装置は、ソフトウェアとして実施することも、ハードウェアとして実施することもできる。

要求された第１の部分は、第１のサイズＮＢ１を有し、要求された第２の部分は、第２のサイズＮＢ２を有する。

前記第１のサイズＮＢ１と前記第２のサイズ（ＮＢ２）の比は、測定した第１の利用可能なビット・レートＢＲ１と測定した第２の利用可能なビット・レートＢＲ２の比に等しいと有利である。

要求ビット・レートＲＢＲを決定するステップＳ２は、測定した第１の利用可能なビット・レートＢＲ１と測定した第２の利用可能なビット・レートＢＲ２の和ＳＵＭを評価するステップを含み、要求ビット・レートＲＢＲは、この和ＳＵＭから決定されると有利である。

第１のサイズＮＢ１は、時間指標ｉおよび要求ビット・レートＲＢＲによって識別されるチャンクのサイズ、ならびに測定した第１の利用可能なビット・レートＢＲ１と和ＳＵＭの比に比例すると有利である。

もちろん、クライアント装置ＣＤが並列な経路Ｐ１、Ｐ２…Ｐｎを介してチャンクの一部分を要求する、本実施例によるこの方法の様々な実施態様が可能である。クライアント装置ＣＤは、２つの異なる対応ビット・レートＢＲ１およびＢＲＢにそれぞれ対応する少なくとも２つのバージョンでコンテンツを入手できるｎ個のサーバＣＳ１、ＣＳ２、…、ＣＳｎとの接続を開く。クライアント装置ＣＤは、これらのサーバＣＳ１、ＣＳ２、…、ＣＳｎに対して同時に、コンテンツのチャンクの重複しない部分を求める要求を並列に送信する。

この方法の利点は、利用可能なサーバＣＳ１、ＣＳ２、…、ＣＳｎの間でトラフィック負荷を分散することである。この負荷分散（ｌｏａｄ ｒｅｐａｒｔｉｔｉｏｎ）は、チャンク毎に再計算される。各サーバＣＳ１、ＣＳ２、…、ＣＳｎから要求される負荷は、当該サーバから要求されるチャンク部分のサイズによって決まる。クライアント装置ＣＤは、バイト・レンジ・ヘッダを含むことにより、各サーバから取り出したいバイト数を示す。このヘッダは、以下のフォーマットを有する。

クライアント装置から送信される要求は、ＨＴＴＰ要求であると有利である。
ＧＥＴ／ｐａｔｈ／ｅｘａｍｐｌｅ．ｊｐｇ ＨＴＴＰ／１．１
ホスト：ｅｘａｍｐｌｅ．ｃｏｍ
レンジ：バイト＝０〜９９９

上記の例では、この要求は、クライアント装置が、指定されたリソース「ｅｘａｍｐｌｅ．ｃｏｍ」の最初の１０００バイトを要求していることを意味している。サーバとの間の所与のチャンクの所与の範囲を求める要求／応答のそれぞれで、クライアント装置ＣＤは、以下のように、現在の利用可能なビット・レートＢＲ１、ＢＲ２、…、ＢＲｎを計算する。

ＢＲ１ｉ＝ｎｂｙｔｅｓＳＣ１、ｉ８÷ｔｉｍｅＣＳ１、ｉ

ここで、ｎｂｙｔｅｓＳＣ１、ｉは、時間指標ｉ（「反復」とも呼ぶ）を有するチャンクについてサーバＣＳ１から要求されたバイト数であり、ｔｉｍｅＣＳ１、ｉは、時間指標ｉを有するチャンクについて、要求されたチャンク部分をサーバＣＳ１からダウンロードするのに必要な持続時間である。

この瞬間的に利用可能なビット・レート測定値を使用して、漸進的な品質改善および深刻なネットワーク劣化に対する迅速な応答の両方を保証する平滑化アルゴリズムを送ることができる。平滑化アルゴリズムは、次のチャンクを要求するために使用することができる利用可能なビット・レート推定値を与える。

Ｅ１、ｉ＝ｆ（ＢＲ１、ｉ、ＢＲ１、ｉ−１、…ＢＲ１、ｉ−ｋ）

ｎ個のサーバが利用可能である場合には、次のチャンクをダウンロードするための利用可能なビット・レートの合計は、以下の通りである。

この方法は、経路Ｐ１およびＰ２で測定された第１および第２の利用可能なビット・レートＢＲ１およびＢＲ２が、しきい値ＢＲＴＨ１より大きいかどうかを判定する、図３ａには図示していないステップＳＡをさらに含むと有利である。この場合、４つのステップＳ１、Ｓ２、Ｓ３およびＳ４は、クライアント装置ＣＤが測定した利用可能なビット・レートＢＲ１、ＢＲ２がしきい値ＢＲＴＨ１より大きいかどうかを判定する経路Ｐ１、Ｐ２についてのみ実行される。

別の実施例では、この同時動作モードは、まさに、しきい値ＢＲＴＨ２以上である目標ビット・レートに到達するために実行する。この動作モードの使用事例としては、いかなる犠牲も払わずに、全ての利用可能な経路を活用する（ｍｏｂｉｌｉｓｅ）することにより、所与のビット・レートＢＲＴＨ２を保証することを可能にすることが挙げられる。これは、換言すれば、要求されたビット・レートＢＲＴＨ２に到達する必要がある場合にのみ、第２のサーバＣＳ２を使用することである。

コンテンツは、経路Ｐ１を介して単一のサーバＣＳ１からのみクライアント装置ＣＤにチャンク毎にダウンロードされる。経路Ｐ１の第１の利用可能なビット・レートＢＲ１は、クライアント装置ＣＤによって測定される。４つのステップＳ１、Ｓ２、Ｓ３およびＳ４は、クライアントＣＤが利用可能なビット・レートＢＲ１がしきい値ＢＲＴＨ２未満であると判定したときにのみ実行され、この場合、要求ビット・レートＲＢＲを決定するステップＳ２は、しきい値ＢＲＴＨ２からプロビジョンを引いた値以下である、対応ビット・レートＢＲＡ、ＢＲＢのうちの最大のビット・レートを選択することにある。

次にダウンロードするチャンクの要求ビット・レートＲＢＲは、利用可能なビット・レートの合計ＢＲ１＋ＢＲ２以下となる最大対応ビット・レート（マニフェスト・ファイルに規定される対応ビット・レートＢＲＡ、ＢＲＢ、ＢＲＣおよびＢＲＤの中で最大のビット・レート）である。チャンクのサイズ（バイト数で表される）は、以下のように近似することができる。

サイズ＝ＲＢＲ×持続時間÷８

最小ビット・レートのしきい値がないと、次の反復でｓ番目のサーバからダウンロードされるバイト数は、全帯域幅ＳＵＭに対する利用可能なビット・レートＢＲ１のｓ番目の測定値の比率に正比例する。

ｎｂｙｔｅｓ_{ｓ、ｉ＋１}＝サイズ×Ｅ_ｓ、ｉ÷ＳＵＭ

最小ビット・レートしきい値ＢＲＴＨ１が使用される場合には、各サーバの寄与に乗法子（ｍｕｌｔｉｐｌｉｃａｔｏｒ）ｋｓを割り当て、これにより、ビット・レートがしきい値未満であるサーバを使用不能にすることができる。クライアント装置ＣＤとサーバＣＳｓの間の経路Ｌｓに対応するビット・レートＢＲｓがしきい値以上である場合には、ｋｓ＝１である。ビット・レートＢＲｓがしきい値未満である場合には、ｋｓ＝０である。総ビット・レートを表す数式は、以下のようになる。

これは、しきい値なしで計算した総ビット・レートより、明らかに小さい。ｓ番目のサーバからダウンロードするバイト数は、以下のようになる。

ｎｂｙｔｅｓ_{ｓ、ｉ＋１}＝サイズ×ｋ_ｓ×Ｅ_ｓ、ｉ÷ＳＵＭ

これらのバイト数は、各サーバに適当なバイト・レンジを要求するために使用されるので、ｎ個のサーバがある場合には、クライアントは、
サーバＣＳ１にレンジ［０；ｎｂｙｔｅｓ１−１］を要求し、
サーバＣＳ２にレンジ［ｎｂｙｔｅｓ１；ｎｂｙｔｅｓ２−１］を要求し、
サーバＣＳ３にレンジ［ｎｂｙｔｅｓ１＋ｎｂｙｔｅｓ２；ｎｂｙｔｅｓ３−１］を要求し、
サーバＣＳｋ（ｋ＜ｎ）にレンジ

を要求し、
サーバＣＳｎにレンジ

を要求する。

最後のレンジは、チャンクのサイズが不等であることが多い事実に対処するために、特殊なレンジ終端指示を使用する。このようにして、最後のレンジは、クライアントがチャンクの正確なサイズを知らなくても、そのチャンクの終端を取り出すことができるようにしている。

全てのサーバからバイト・レンジを受信すると、クライアント装置ＣＤは、それらのバイト・レンジを単純に昇順に連結して、完全なチャンクを再構築する。このチャンクは、その後、単一のサーバから発せられた場合と同じように、プレーヤ・モジュールで通常通りに消費される。

４つのステップＳ１、Ｓ２、Ｓ３およびＳ４は、サーバＣＳ１、ＣＳ２からチャンクがダウンロードされるたびに実行されると有利である。

本実施例による方法は、経路の１つでのビット・レートの極端な低下を克服するようにもなされている。

クライアント装置ＣＤは、経路Ｐ１、Ｐ２、Ｐ３のうちの１つでの利用可能なビット・レートがしきい値ＢＲＴＨ２、ＢＲＴＨ３未満であるかどうかを判定する手段を含むと有利である。

クライアント装置ＣＤは、例えば、チャンクｉの前記要求された部分の配信持続時間がしきい値ＤＨＴを超えるかどうかを判定するようになされている。

その結果、クライアント装置ＣＤは、反復中に、進行中の要求（例えばバイト・レンジ）の終端の処理を停止（または無視）し、新たな要求を次のサーバに直ちに依頼して当該レンジの残りのバイトを完全にすることを判断することができる。この次のサーバは、例えば、最高のビット・レートで到達可能なサーバ、またはサーバ・グループである。その場合には、クライアントは、まだ受信していないチャンクの部分のフラグメントを受信するための要求を送信する。

例えば３つの独立した経路Ｐ１、Ｐ２、Ｐ３を介してクライアント装置ＣＤがコンテンツにアクセスすることができ、これらのコンテンツが、３つのサーバＣＳ１、ＣＳ２、ＣＳ３で複製され、要求ビット・レートＲＢＲが、第１の経路Ｐ１、第２の経路Ｐ２および第３の経路Ｐ３でそれぞれ測定された第１の利用可能なビット・レートＢＲ１、第２の利用可能なビット・レートＢＲ２および第３の利用可能なビット・レートＢＲ３から決定される例で、この方法を説明する。クライアント装置ＣＤは、第１の経路（Ｐ１）を介して時間指標ｉおよび要求ビット・レートＲＢＲで識別されるチャンクの第１の部分を要求し、第２の経路Ｐ２を介して該チャンクの第２の部分を要求し、第３の経路Ｐ３を介して該チャンクの第３の部分を要求している。

本実施例によるこの方法は、
前記クライアント装置ＣＤが、要求した第１の部分および第２の部分を完全に受信し、第３の部分の第１のフラグメントを受信中であり、経路Ｐ３での利用可能なビット・レートＢＲ３がしきい値ＢＲＴＨ３未満であると判定したときに、
時間指標ｉで識別されるチャンクの第３の部分の第３のフラグメントの第１の部分を受信するための要求を、経路Ｐ１を介して送信し、時間指標ｉで識別されるチャンクの第３の部分の第３のフラグメントの第２の部分を受信するための要求を、経路Ｐ２を介して送信するステップＳ５をさらに含む。前記第１の部分と第２の部分は、前記第３の部分の相補的な部分である。

しきい値ＢＲＴＨ３未満のビット・レートを有する経路Ｐ２では、クライアントは、チャンク（例えば現在のチャンク）のフラグメントを要求する。例えば、しきい値ＢＲＴＨ３にチャンク持続時間（例えば２秒）を掛けた積の半分のサイズを有するフラグメントである。

このフラグメントは、この特定の経路の正確なビット・レート評価を維持するためにのみ使用される。このフラグメントは、プレーヤに渡されない。

さらに別の実施例では、このアルゴリズムは、単一のチャンクの持続時間の間に負荷を再分配するようになされる。

測定したビット・レートＢＲ１、ＢＲ２の時間的進展を、図４ａに示す。

第１の曲線（実線）は、第１の経路Ｐ１上で測定したビット・レートＢＲ１の時間的進展を示している。第２の曲線（破線）は、第２の経路Ｐ２上で測定したビット・レートＢＲ２の進展を示している。第３の曲線（太い破線）は、測定したビット・レートの合計ＢＲ１＋ＢＲ２の進展を示している。ここでは、これは一定である。

上述の従来技術と比較した際の利点は、次のような点である。すなわち、１つの経路で測定したビット・レートに何らかの時間的変動があっても、ここでの総合ビット・レート（ａｇｇｒｅｇａｔｅｄ ｂｉｔ ｒａｔｅ ｈｅｒｅ）ＢＲ１＋ＢＲ２を考慮するときには、この変動が平均化される。相関的に、要求ビット・レートＲＢＲは一定であり、クライアント装置が受信するチャンクの質は、経路Ｐ１、Ｐ２でビット・レートの変動があるときでも一定になる。

同図に、クライアント装置ＣＤが経路Ｐ１および経路Ｐ２を介してそれぞれ受信するチャンクの第１の部分および第２の部分も示してある。横縞で示される枠は、第１の経路Ｐ１を介して受信されるチャンクの第１の部分を示し、白抜きの枠は、第２の経路Ｐ２を介して受信されるチャンクの第２の部分を示す。ここで、ここでの総合ビット・レートＢＲ１＋ＢＲ２が一定であるので、受信されるチャンクは、全て同じ要求ビット・レートＲＢＲを有する。ただし、測定したビット・レートＢＲ１およびＢＲ２の相対的変動に従って、測定した利用可能なビット・レートの時間的変動により、第１の部分のサイズと第２の部分のサイズの間の関係は、時間とともに変化する。

測定したビット・レートの時間的進展についても同様に仮定して、図４ｂは、しきい値ＢＲＴＨ２を考慮したときの、第１の経路Ｐ１および第２の経路Ｐ２を介してダウンロードされるチャンクの部分を示している。

ここでは、例えば経路Ｐ１で測定された利用可能なビット・レートＢＲ１がしきい値ＢＲＴＨ２未満であるときなど、特定の条件によってのみ同時ダウンロードを実施することを考える。通常動作では、単一のサーバでのダウンロードが実施される。この状況を、図４ｂに示す。この図では、実線の曲線がしきい値ＢＲＴＨ２未満であるときにのみ、クライアント装置ＣＤが単一の経路Ｐ１を介してチャンクを要求して受信している。

従って、測定したビット・レートＢＲ１が前記しきい値ＢＲＴＨ２未満になるとすぐに、クライアント装置は、他方の経路Ｐ２上の第２の利用可能なビット・レートＢＲ２を測定し、両経路を介してチャンクの各部分を要求する。

本明細書の開示する記述、特許請求の範囲および図面は、独立して提供することもできるし、任意の適当な組合せで提供することもできる。各特性は、必要に応じて、ハードウェアでも、ソフトウェアでも、またはその両者の組合せでも実施することができる。

本明細書において、「一実施例」または「実施例」と述べている場合、それは、当該実施例に関連して述べられる具体的な特性、構造または特徴が、本発明の原理の少なくとも１つの実施態様に含まれる可能性があるという意味である。本明細書の様々な箇所に見られる「一実施例において」という語句の表現は、その全てが必ずしも同じ実施例のことを指しているわけではなく、別個または代替とされる実施例も、必ずしも相互に排他的な実施例であるとは限らない。

Claims (15)

1. 少なくとも第１および第２の通信インタフェース（ＣＩ１、ＣＩ２）を含むクライアント装置（ＣＤ）においてレンダリングされるコンテンツを提供する方法であり、前記第１および第２の通信インタフェース（ＣＩ１、ＣＩ２）が通信アドレスを有し、前記コンテンツが、通信アドレスを有する少なくとも第１および第２のサーバ通信インタフェース（ＳＩ１、ＳＩ２）を介して前記クライアント装置（ＣＤ）からアクセス可能であり、第１の経路（Ｐ１）が、前記第１の通信インタフェース（ＣＩ１）の通信アドレスおよび前記第１のサーバ通信インタフェース（ＳＩ１）のアドレスによって識別され、第２の経路（Ｐ２）が、前記第２の通信インタフェース（ＣＩ２）の通信アドレスおよび前記第２のサーバ通信インタフェース（ＳＩ２）のアドレスによって識別され、前記コンテンツが、対応ビット・レート（ＢＲＡ、ＢＲＢ）の制約に対応する符号化品質を有する少なくとも２つのバージョンで利用可能であり、前記少なくとも２つのバージョンのそれぞれが、前記コンテンツの同一のレンダリング持続時間に対応する複数のチャンクに時間的に分割され、チャンクが、時間指標ｉおよび前記対応ビット・レート（ＢＲＡ、ＢＲＢ）のうちの１つによって識別され、前記コンテンツが、前記第１および第２の経路（Ｐ１、Ｐ２）を介して前記クライアント装置（ＣＤ）から同時にアクセス可能である方法であって、前記クライアント装置（ＣＤ）において、
   前記第１の経路（Ｐ１）上の第１の利用可能なビット・レート（ＢＲ１）および前記第２の経路（Ｐ２）上の第２の利用可能なビット・レート（ＢＲ２）を測定するステップ（Ｓ１）と、
   前記測定した第１の利用可能なビット・レート（ＢＲ１）および前記測定した第２の利用可能なビット・レート（ＢＲ２）に基づいて、前記対応ビット・レート（ＢＲＡ、ＢＲＢ）の中の要求ビット・レート（ＲＢＲ）を決定するステップ（Ｓ２）と、
   前記時間指標ｉおよび前記要求ビット・レート（ＲＢＲ）によって識別されるチャンクの第１の部分を受信するための第１の要求を前記第１の経路（Ｐ１）を介して送信し、前記チャンクの第２の部分を受信するための第２の要求を前記第２の経路（Ｐ２）を介して送信するステップ（Ｓ３）であって、前記チャンクの前記第１の部分と前記第２の部分とが相補的であるステップ（Ｓ３）と、
   前記第１の経路（Ｐ１）を介して前記要求した第１の部分を受信し、前記第２の経路（Ｐ２）を介して前記要求した第２の部分を受信するステップ（Ｓ４）と、を含む、前記方法。
2. 前記要求した第１の部分が第１のサイズ（ＮＢ１）を有し、前記要求した第２の部分が第２のサイズ（ＮＢ２）を有し、前記第１のサイズ（ＮＢ１）と前記第２のサイズ（ＮＢ２）の比が、前記測定した第１の利用可能なビット・レート（ＢＲ１）と前記測定した第２の利用可能なビット・レート（ＢＲ２）の比に等しい、請求項１に記載の方法。
3. 前記要求ビット・レート（ＲＢＲ）を決定する前記ステップ（Ｓ２）が、前記測定した第１の利用可能なビット・レート（ＢＲ１）と前記測定した第２の利用可能なビット・レート（ＢＲ２）の和（ＳＵＭ）を評価するステップを含み、前記要求ビット・レート（ＲＢＲ）が、前記和（ＳＵＭ）から決定される、請求項１または２に記載の方法。
4. 前記要求ビット・レート（ＲＢＲ）を決定する前記ステップ（Ｓ２）が、前記測定した第１の利用可能なビット・レート（ＢＲ１）と前記測定した第２の利用可能なビット・レート（ＢＲ２）の前記和（ＳＵＭ）からプロビジョンを引いた値以下となる、対応ビット・レート（ＢＲＡ、ＢＲＢ）の中の最大ビット・レートを選択することにある、請求項３に記載の方法。
5. 前記第１のサイズ（ＮＢ１）が、前記時間指標ｉおよび前記要求ビットレート（ＲＢＲ）によって識別されるチャンクのサイズ、ならびに前記測定した第１の利用可能なビット・レート（ＢＲ１）と前記和（ＳＵＭ）の比に比例する、請求項４に記載の方法。
6. 前記４つのステップ（Ｓ１、Ｓ２、Ｓ３、Ｓ４）が、前記クライアント装置（ＣＤ）がチャンクを完全に受信するたびに実行される、請求項１から５に記載の方法。
7. 前記経路（Ｐ１、Ｐ２）上で測定された前記第１および第２の利用可能なビット・レート（ＢＲ１、ＢＲ２）がしきい値（ＢＲＴＨ１）より大きいかどうかを判定する、前記ステップ（Ｓ１）の前に実行されるステップ（ＳＡ）をさらに含み、前記４つのステップ（Ｓ１、Ｓ２、Ｓ３、Ｓ４）が、前記クライアント装置（ＣＤ）が前記測定した利用可能なビット・レート（ＢＲ１、ＢＲ２）が前記しきい値（ＢＲＴＨ１）より大きいと判定した経路（Ｐ１、Ｐ２）についてのみ実行される、請求項１から６に記載の方法。
8. 前記ステップ（Ｓ１）が、前記クライアント装置（ＣＤ）から前記第１および第２の経路（Ｐ１、Ｐ２）を介して送信された要求、ならびに前記要求に応答して前記第１および第２の経路（Ｐ１、Ｐ２）を介して送信される確認メッセージの往復時間を計算することにある、請求項１から６に記載の方法。
9. 前記クライアント装置ＣＤが前記経路（Ｐ１、Ｐ２）のうちの少なくとも１つを介して前記対応ビット・レート（ＢＲＡ、ＢＲＢ）のリストを受信するステップと、対応ビットレート（ＢＲＡ、ＢＲＢ）毎に前記チャンクのサイズを受信するステップとをさらに含む、請求項１から８に記載の方法。
10. 前記クライアント装置（ＣＤ）が、第３の通信インタフェース（ＣＩ３）を含み、前記コンテンツが、第３のサーバ通信インタフェース（ＳＩ３）を介して前記クライアント装置（ＣＤ）からアクセス可能であり、第３の経路（Ｐ３）が、前記第３の通信インタフェース（ＣＩ３）の通信アドレスおよび前記第３のサーバ通信インタフェース（ＳＩ３）のアドレスによって識別され、前記要求ビット・レート（ＲＢＲ）が、前記第１、第２および第３の経路（Ｐ１、Ｐ２、Ｐ３）上でそれぞれ測定された前記第１、前記第２および第３の利用可能なビット・レート（ＢＲ１、ＢＲ２、ＢＲ３）から決定され、前記クライアント装置（ＣＤ）が、前記第１の経路（Ｐ１）を介して、前記時間指標ｉおよび前記要求ビット・レート（ＲＢＲ）によって識別される前記チャンクの第１の部分を要求し、前記第２の経路（Ｐ２）を介して前記チャンクの第２の部分を要求し、前記第３の経路（Ｐ３）を介して前記チャンクの第３の部分を要求しており、前記コンテンツが、前記第１、第２および第３の経路（Ｐ１、Ｐ２、Ｐ３）を介して前記クライアント装置（ＣＤ）から同時にアクセス可能であり、前記方法が、前記クライアント装置（ＣＤ）において、
    前記クライアント装置（ＣＤ）が前記要求した第１の部分および第２の部分を完全に受信し、前記第３の部分の第１のフラグメントを受信中であり、前記経路（Ｐ３）での前記利用可能なビット・レート（ＢＲ３）がしきい値（ＢＲＴＨ３）未満であると判定したときに、
    前記時間指標ｉによって識別される前記チャンクの前記第３の部分の第３のフラグメントの第１の部分を受信するための要求を前記経路（Ｐ１）を介して送信し、前記時間指標ｉによって識別される前記チャンクの前記第３の部分の前記第３のフラグメントの第２の部分を受信するための要求を前記経路（Ｐ２）を介して送信するステップ（Ｓ５）であり、前記第１の部分と前記第２の部分とが前記第３の部分の相補的な部分であるステップ（Ｓ５）をさらに含む、請求項１から７の何れか１項に記載の方法。
11. 少なくとも第１および第２の通信インタフェース（ＣＩ１、ＣＩ２）を含む、レンダリングするコンテンツを受信するクライアント装置（ＣＤ）であり、前記第１および第２の通信インタフェース（ＣＩ１、ＣＩ２）が通信アドレスを有し、前記コンテンツが、通信アドレスを有する少なくとも第１および第２のサーバ通信インタフェース（ＳＩ１、ＳＩ２）を介して前記クライアント装置（ＣＤ）からアクセス可能であり、第１の経路（Ｐ１）が、前記第１の通信インタフェース（ＣＩ１）の通信アドレスおよび前記第１のサーバ通信インタフェース（ＳＩ１）のアドレスによって識別され、第２の経路（Ｐ２）が、前記第２の通信インタフェース（ＣＩ２）の通信アドレスおよび前記第２のサーバ通信インタフェース（ＳＩ２）のアドレスによって識別され、前記コンテンツが、対応ビット・レート（ＢＲＡ、ＢＲＢ）の制約に対応する符号化品質を有する少なくとも２つのバージョンで利用可能であり、前記少なくとも２つのバージョンのそれぞれが、前記コンテンツの同一の持続時間に対応する複数のチャンクに時間的に分割され、チャンクが、時間指標ｉおよび前記対応ビット・レート（ＢＲＡ、ＢＲＢ）によって識別され、前記コンテンツが、前記第１および第２の経路（Ｐ１、Ｐ２）を介して前記クライアント装置（ＣＤ）から同時にアクセス可能であるクライアント装置（ＣＤ）であって、
    前記第１の経路（Ｐ１）上の第１の利用可能なビット・レート（ＢＲ１）および前記第２の経路（Ｐ２）上の第２の利用可能なビット・レート（ＢＲ２）を測定する手段と、
    前記測定した第１の利用可能なビット・レート（ＢＲ１）および前記測定した第２の利用可能なビット・レート（ＢＲ２）に基づいて、前記対応ビット・レート（ＢＲＡ、ＢＲＢ）の中の要求ビット・レート（ＲＢＲ）を決定する手段と、
    前記時間指標ｉおよび前記要求ビット・レート（ＲＢＲ）によって識別されるチャンクの第１の部分を受信するための第１の要求を前記第１の経路（Ｐ１）を介して送信し、前記チャンクの第２の部分を受信するための第２の要求を前記第２の経路（Ｐ２）を介して送信する手段であり、前記チャンクの前記第１の部分と前記第２の部分とが相補的である手段と、
    前記第１の経路（Ｐ１）を介して前記要求した第１の部分を受信し、前記第２の経路（Ｐ２）を介して前記要求した第２の部分を受信する手段と、を含む、前記クライアント装置（ＣＤ）。
12. 前記第１および第２の経路（Ｐ１、Ｐ２）のうちの少なくとも１つを介して、前記対応ビット・レート（ＢＲＡ、ＢＲＢ）に関する情報を受信し、且つ各対応ビット・レート（ＢＲＡ、ＢＲＢ）毎に、前記チャンクのサイズに関する情報を受信する手段をさらに含む、請求項１１に記載のクライアント装置。
13. 要求ビット・レート（ＲＢＲ）を決定する前記手段が、前記測定した第１の利用可能なビット・レート（ＢＲ１）と前記測定した第２の利用可能なビット・レート（ＢＲ２）の和（ＳＵＭ）を評価するようになっており、前記手段が、前記測定した第１の利用可能なビット・レート（ＢＲ１）と前記測定した第２の利用可能なビット・レート（ＢＲ２）の前記和（ＳＵＭ）からプロビジョンを引いた値以下となる、対応ビット・レート（ＢＲＡ、ＢＲＢ）の中の最大ビット・レートを選択するようになっている、請求項１１から１２に記載のクライアント装置。
14. 測定した利用可能なビットレート（ＢＲ１、ＢＲ２）がしきい値（ＢＲＴＨ１）を超えるかどうかを判定する手段をさらに含む、請求項１１から１３に記載のクライアント装置。
15. 前記経路（Ｐ１、Ｐ２、Ｐ３）のうちの１つでの利用可能なビット・レートがしきい値（ＢＲＴＨ３）未満であるかどうかを判定する手段をさらに含む、請求項１１から１４に記載のクライアント装置。

Images