JP2016059037A - 少なくとも２つの連続するセグメントに分離されたマルチメディアコンテンツを受信するための方法およびクライアント端末、ならびに対応するコンピュータプログラム製品およびコンピュータ可読媒体 - Google Patents

Abstract

【課題】少なくとも２つの連続するセグメントに分離されたマルチメディアコンテンツを受信するための方法を提供する。【解決手段】セグメントの第１の表現の少なくとも１つのフラグメントを受信するステップ２１と、利用可能な帯域幅を考慮することによって、セグメントの第１の表現のすべての後続フラグメントの予想配送時間およびセグメントの少なくとも１つの代わりの表現のすべてのフラグメントの予想配送時間を決定するステップ２２と、予想配送時間を考慮することによって、セグメントの第１の表現の少なくとも１つの後続フラグメントを受信すること、またはセグメントの第２の表現の少なくとも第１のフラグメントの受信を選択するステップ２３とを含む。【選択図】図２

Description

本開示は、一般に、例えば、限定されないが、ＨＴＴＰ（ハイパーテキスト転送プロトコル）上の、適応ストリーミング技術の分野に関し、詳細には、セグメントに分離されたマルチメディアコンテンツの、クライアント端末による、受信に関する。

本開示は、特に、ライブイベントのストリーミングでの受信に適合される。

本セクションは、以下で説明および／または特許請求される本開示の様々な特徴に関連し得る、本技術分野の様々な特徴について読者に知ってもらうことを意図している。この説明は、本開示の様々な特徴のより良い理解を容易にする背景情報を読者に提供するうえで役立つものと思われる。加えて、これらの声明は、この観点から読まれるべきであり、先行技術の承認として読まれるべきではないことを理解されたい。

（マルチビットレートスイッチングまたはＨＡＳとも呼ばれる）ＨＴＴＰ上の適応ストリーミングは、マルチメディアコンテンツ配信用の主要技術に急速になりつつある。すでに使用されているＨＴＴＰ適応ストリーミングプロトコルの中で、最も有名なものに、アップルのＨＴＴＰライブストリーミング（ＨＬＳ）、マイクロソフトのシルバライトスムーズストリーミング（ＳＳＳ）、アドビのＨＴＴＰダイナミックストリーミング（ＨＤＳ）、３ＧＰＰおよびＭＰＥＧによって開発された（ＩＳＯ／ＩＥＣ２３００９−１：２０１２として規格化された）ダイナミックアダプティブストリーミングオーバＨＴＴＰ（ＤＡＳＨ）がある。

クライアント端末は、オーディオビジュアルコンテンツ（またはＡ／Ｖコンテンツ）を適応ストリーミングで再生することを望む場合、最初に、このＡ／Ｖコンテンツがどのように獲得され得るかを記述するファイルを取得しなければならない。これは、一般に、ＨＴＴＰプロトコルを通して、ＵＲＬ（ユニフォームリソースロケータ）から記述ファイル、いわゆるマニフェストを所得することによって行われるが、他の手段（例えば、ブロードキャスト、電子メールおよびＳＭＳなど）によっても達成され得る。事前に生成され、リモートサーバーによってクライアント端末に配送されるマニフェストは、基本的に、そのようなＡ／Ｖコンテンツの（ビットレート、解像度、および他の属性の観点から見た）利用可能な（インスタンスまたはバージョンとも呼ばれる）表現を列挙している。表現は、所定の品質レベル（ビットレート）に関連付けられる。

各表現の全データストリームは、クライアント端末が２つのセグメント間で１つの品質レベルから別のレベルにスムーズに切り換わることができるように作成された、（別個のＵＲＬによってアクセス可能な）持続時間が等しい（データチャンク（ｃｈｕｎｋ）とも呼ばれる）セグメントに分割される。結果として、ビデオ品質は、再生中に変化し得るが、（フリーズとも呼ばれる）中断を被ることはめったにない。

クライアント側では、送信経路の利用可能な帯域幅の測定値に基づいて、セグメントが選択される。特に、クライアント端末は、通常、ビットレート符号化に対応するセグメントの表現、したがって、測定された帯域幅に適合する品質を要求する。この説明全体でネットワーク帯域幅または帯域幅とも呼ばれる利用可能な帯域幅は、ｂｉｔ／ｓ単位のネットワークスループットのことを指す。

したがって、コンテンツをレンダリングするクライアント端末は、達成可能なスループットについて自ら推定を行わなくてはならず、同時に品質を最大化するよう試みる一方で、セグメントが提示時間にレンダリングされるのに十分な速さでダウンロードされ得るように表現を選択する。

ＨＴＴＰ適応ストリーミング技術によると、クライアント端末は、コンテンツ受信のために利用可能な帯域幅を継続的に評価しなければならず、連続的な表示にとってセグメントの受信が遅くなりすぎるリスクが最小化される一方で、ビデオ品質が最大化されるように、セグメントの表現を要求する前に適切なスループットを決定しなければならない。

しかしながら、リモートサーバーとクライアント端末との間の送信経路が変化した場合、利用可能な帯域幅は変化し得る（インターネットのスループットは一定ではない）ので、これは容易なトレードオフではない。

より具体的には、帯域幅が低下した場合、特定のビットレート符号化に対応するセグメントの表現をダウンロードするのに要する時間は、増加し得、Ａ／Ｖコンテンツのレンダリングプロセスにおいて中断を生じさせ得る。

例として、セグメント持続時間が１０秒であり、セグメントの表現が２００、４００、６００、１２００、１８００、２５００、４５００、６５００、および８５００ｋｂｉｔ／ｓ（ＨＬＳの場合にアップルによって推奨される数値）で得られ、一定の帯域幅が送信の開始時に８．５Ｍｂｉｔ／ｓである場合について考慮する。クライアント端末は、１０秒ごとに８５００ｋｂｉｔ／ｓでセグメントの１つの表現を要求することができる。帯域幅が、突然、２分の１（４２５０ｋｂｉｔ／ｓ）にされたと仮定する。帯域幅のこの低下が８５００ｋｂｉｔ／ｓでセグメントの表現を求める要求の直後に発生した場合、この表現は、２０秒を要してダウンロードされ、そのため、我々は、セグメント１つ分の遅れを経験する。

コンテンツのレンダリングのフリーズを克服するために、したがって、いくつかのセグメントがその中に事前にダウンロードされるバッファを使用して、帯域幅が低下したときに新しいセグメントをロードするためのより大きい余裕が得られるようにすることが可能である。

しかしながら、長いバッファは、エンドユーザに対して遅延を導入する。ライブイベントの場合、これらの遅延は望ましくなく、そのため、短いバッファの使用が好ましい。

さらに、セグメントの受信を求める要求がひとたびＨＴＴＰプロトコルを通してサーバーに送信されると、受信を中断するための唯一の方法は、下層のＴＣＰ接続をクローズすることだけである。

しかしながら、接続のそのようなクローズは、非効率的で時間を浪費する新しいＴＣＰセッションの再開を必要とする。

インターネットのスループットは一定ではなく、短い時間期間のうちに変化し得るので、局所的な変化に強く反応し過ぎないようにするために、認識される帯域幅に何らかの平均化を行うことが提案された。その場合、帯域幅低下がセグメントの終わり近くで生じた場合、計算される平均に対するその影響は小さい。

しかしながら、この平均に基づいて、クライアント端末は、新しい帯域幅よりも高い表現を依然として選択する。帯域幅がより高いレベルに戻らない場合、この決定は、セグメントにわたってダウンロード遅延を累積させ、これが抵抗するための大きいバッファを再び要求する。

本開示は、上述された短所のうちの少なくとも１つを克服する。

本開示は、少なくとも１つのサーバーから、クライアント端末によってマルチメディアコンテンツを受信するための方法に関し、上記マルチメディアコンテンツは、第１の持続時間の少なくとも２つの連続するセグメントに分離され、セグメントは、少なくとも２つの表現に関連付けられる。

本開示の実施形態によると、上記方法は、
− セグメントの第１の表現の少なくとも１つのフラグメントを受信するステップであって、上記セグメントの各表現は、第２の持続時間（上記第２の持続時間は上記第１の持続時間よりも短い）の少なくとも２つの連続するフラグメントに分離される、ステップと、
− 上記クライアント端末と上記少なくとも１つのサーバーの１つとの間の送信経路上において利用可能な帯域幅を考慮することによって、
・上記セグメントの上記第１の表現のすべての後続フラグメントの予想配送時間、および
・上記セグメントの少なくとも１つの代わりの表現のすべての上記フラグメントの予想配送時間
を決定するステップと、
− 上記予想配送時間を考慮することによって、
・上記セグメントの上記第１の表現の少なくとも１つの後続フラグメントを受信すること、または
・上記セグメントの第２の表現の少なくとも第１のフラグメントを受信することであって、上記第２の表現は、上記少なくとも１つの代わりの表現に属する、受信すること
の間で選択するステップと
を含む。

したがって、本開示は、マルチメディアコンテンツを受信するための新しい技法を提案し、マルチメディアコンテンツは、セグメントに分離され、クライアント端末は、このセグメント全体の代わりに、例えば、バイト単位で、セグメントの部分（またはセグメントの表現の部分）を要求することができる。

結果として、本開示による方法は、利用可能な帯域幅の増加または減少の際に、セグメントの同じ表現の他のフラグメントをロードするほうが良いか、またはセグメントの別の表現を最高もしくは最低のビットレートでロードするほうが良いかを決定するために、セグメントの全ての表現の代わりに、セグメントの表現のフラグメントをロードすることを提案する。

実際に、上述された難点のいくつかは、表現の受信についての決定は全セグメント持続時間を要して行われるのに、送信経路上における帯域幅は非常に短い時間期間のうちに変化し得るという事実に起因している。結果として、帯域幅が狭すぎる場合、クライアント端末は、セグメントの受信のために長い遅延という代償を払い、帯域幅が広すぎる場合、クライアント端末は、セグメントの受信のためのそのビットレートを最適化しない。

したがって、本開示の実施形態による方法は、クライアント端末が、先行技術の方法と比較して、より短い時間ベースで動作することを可能にし得る。結果として、帯域幅の減少（または増加）が検出された場合、セグメントの現在の表現のそのダウンロードを「アボート（abort）」し、変更を行わない場合よりも速やかに（またはより高い品質で）セグメントを準備できるようにする、より低い（またはより高い）ビットレートを有する上記セグメントの新しい表現をロードし始めることが決定され得る。

特に、本開示による方法は、上記少なくとも１つのフラグメントを受信するために、少なくとも１つのバイト範囲要求を上記少なくとも１つのサーバーに送信するステップを含むことができる。

これは、全セグメントを要求する代わりに（例えば、フラグメントのその予想ロード時間を５００ｍｓに短縮する）バイト範囲を要求することによって、現在のＨＴＴＰ実装、特に、ＨＴＴＰ／１．１オプションを用いて行われ得る。

上記バイト範囲要求の少なくとも１つはパイプライン化され得ることに留意されたい。セグメントを求める１つの要求と比較して、セグメントのフラグメントを求める複数の要求は、ＲＴＴの１倍の代わりに、ＲＴＴのＮ倍の累積遅延を暗示するので、そのようなパイプライン化は有益であり得る。ここで、Ｎは、セグメント当たりのフラグメントの数である。

本開示の実施形態によると、上記方法は、上記第２の持続時間に対応するタイムスケールで、上記利用可能な帯域幅の推定値を決定するステップを含むことができる。

言い換えると、上記利用可能な帯域幅は、そのフラグメントレベルで推定され得る。

本開示の別の実施形態によると、上記方法は、上記第１の持続時間に対応するタイムスケールで、上記利用可能な帯域幅の推定値を決定するステップを含むことができる。

言い換えると、上記利用可能な帯域幅は、そのセグメントレベルで推定され得る。

特に、１つが上記フラグメントレベルで、１つが上記セグメントレベルで、２つの帯域幅推定値が決定され得る。次に、セグメントの開始時には、上記表現は、より大きい平均化された推定によって選択され得るが、上記セグメントの上記フラグメントをロードしたとき、上記クライアント端末は、その短い期間の変動を考慮することができる。

特に、１つまたは複数の上記推定値は、各々、周期的に、または少なくとも１つのフラグメントを受信した後、または少なくとも１つのセグメントを受信した後、または上記送信経路の変化を検出した後に決定され得る。

第１の例によると、上記利用可能な帯域幅の減少が生じた場合、上記第２の表現は、上記第１の表現に関連付けられた第１のビットレートよりも低い第２のビットレートに関連付けられる。

したがって、本開示は、その帯域幅が激しく低下した場合にロバストネスを改善することを可能にし得る。

第２の例によると、上記利用可能な帯域幅の増加が生じた場合、上記第２の表現は、上記第１の表現に関連付けられた第１のビットレートよりも高い第２のビットレートに関連付けられる。

したがって、本開示は、その帯域幅が素早く上昇した場合により迅速な品質改善を得ることを可能にし得る。その場合、クライアント端末は、セグメントの第１の表現についての初期決定を変更し、任意のフラグメント境界において、より高い品質の表現（したがって、より高いビットレート）を選択することができる。

これは、そのストリーミングセッションの開始時に、特に有益であり得る。実際に、まさに第１のセグメントをロードしたとき、上記クライアント端末は、自由に使える、その帯域幅の正確な推定値を有し得ない。

先行技術によると、上記クライアント端末は、上記セッションが正しく開始し得ることを保証するために、低いビットレートを選択しなければならない。しかし、その場合、はるかに高い品質が達成され得ることが分かっても、第２の表現に変化するには、セグメントの持続時間が経過するのを待たなければならないことがある。

本開示の少なくとも１つの実施形態を用いると、上記クライアントは、上記利用可能な帯域幅を第１のフラグメントにおいて発見し、最適な品質を用いてそのビデオが開始するように、より良いビットレートに速やかに切り換わることを決定することができる。

本開示の実施形態によると、上記第１の表現の少なくとも１つの後続フラグメントを受信すること、または上記第２の表現の少なくとも第１のフラグメントを受信することの間で選択する上記ステップは、上記クライアント端末のバッファの現在のコンテンツの再生持続時間も考慮することができる。

言い換えると、上記クライアント端末は、セグメントの上記第１の表現を受信し続けること、または上記セグメントの第２の表現に変化することを決定する前に、上記バッファが消費されるかどうかをチェックすることができる。

本開示の実施形態によると、上記予想配送時間の上記決定と、上記第１の表現の少なくとも１つの後続フラグメントを受信すること、または上記第２の表現の少なくとも第１のフラグメントを受信することの間での上記選択とは、フラグメントごとに実装され得る。

したがって、上記帯域幅の増加または減少が生じた場合、別の表現に切り換わるほうが良いかどうかを各フラグメントにおいて決定することが可能である。

本開示は、少なくとも１つのサーバーからマルチメディアコンテンツを受信するためのクライアント端末にも関し、上記マルチメディアコンテンツは、第１の持続時間の少なくとも２つの連続するセグメントに分離され、セグメントは、少なくとも２つの表現に関連付けられる。

本開示の実施形態によると、上記クライアント端末は、
− セグメントの第１の表現の少なくとも１つのフラグメントを受信するように構成されたモジュールであって、上記セグメントの各表現は、第２の持続時間の少なくとも２つの連続するフラグメントに分離される、モジュールと、
− 上記クライアント端末と上記少なくとも１つのサーバーの１つとの間の送信経路上において利用可能な帯域幅を考慮することによって、
・上記セグメントの上記第１の表現のすべての後続フラグメントの予想配送時間、および
・上記セグメントの少なくとも１つの代わりの表現のすべての上記フラグメントの予想配送時間
を決定するように構成されたモジュールと、
− 上記予想配送時間を考慮することによって、
・上記セグメントの上記第１の表現の少なくとも１つの後続フラグメントを受信すること、または
・上記セグメントの第２の表現の少なくとも第１のフラグメントを受信することであって、上記第２の表現は、上記少なくとも１つの代わりの表現に属する、受信すること
の間で選択するように構成されたモジュールと
を備える。

そのようなクライアント端末は、本明細書の上で説明された上記受信方法を実装するように特に適合され得る。それは、もちろん、組み合わされ得る、または別々に利用され得る、本開示の実施形態による上記受信方法に関する異なる特徴を含むことができる。したがって、上記端末の上記特徴および利点は、上記受信方法のそれらと同じであり、より十分な詳細さで説明されない。

本開示の別の特徴は、マルチメディアコンテンツを受信するための方法を実行するように適合されたソフトウェアコードを含む、通信ネットワークからダウンロード可能であり、および／またはコンピュータによって可読な媒体上に記録され、および／またはプロセッサーによって実行可能な、コンピュータプログラム製品に関し、上記ソフトウェアコードは、上で説明された上記受信方法のステップを実行するように適合される。

加えて、本開示は、先に説明された上記受信方法の上記ステップを実施するためのプログラムコード命令を含む、プロセッサーによって実行されることが可能であり、その上に記録されるコンピュータプログラム製品を含む、非一時的なコンピュータ可読媒体に関する。

上記開示される実施形態と範囲が等しいいくつかの特徴が、以下で説明される。これらの特徴は、本開示が取り得るいくつかの形態の簡潔な要約をその読者に提供するために提示されるにすぎないこと、またこれらの特徴が本開示の範囲を限定することを意図していないことを理解されたい。実際に、本開示は、以下で説明されないであろう様々な特徴を包含することができる。

本開示は、添付の図面を参照する、決して限定的ではない、以下の実施形態および実行例によって、より良く理解され、説明される。
本開示が実装され得るクライアント−サーバーネットワークアーキテクチャの概略図である。 本開示によるマルチメディアコンテンツを受信するための方法の主要ステップを示すフローチャートである。 本開示の全般的なプロセスの例を示すフローチャートである。 図３の例によるマルチメディアコンテンツを受信するための方法を実装するクライアント端末の例のブロック図である。

図１および図４において、表されるブロックは、必ずしも物理的に別個のエンティティに対応しない、純粋に機能的なエンティティである。すなわち、それらは、ソフトウェア、ハードウェアの形態で開発され、または１もしくは複数のプロセッサーを備える１もしくは複数の集積回路内で実装され得る。

可能な場合はどこでも、同じ参照番号は、どの図面においても同一または同様の部分を指すために使用される。

本開示の図面および説明は、本開示の明確な理解に関連する要素を説明するために簡略化されており、一方で、明瞭にするために、典型的なディジタルマルチメディアコンテンツ配送方法およびシステムにおいて見出される他の多くの要素を排除してあることを理解されたい。

好ましい実施形態によると、本開示は、ＨＴＴＰ適応ストリーミングプロトコル（またはＨＡＳ）に関して、特に、ＭＰＥＧ−ＤＡＳＨに関して示される。当然に、本開示はそのような特定の環境に制約されず、他の適応ストリーミングプロトコルももちろん考慮および実装され得る。

図１に示されるように、本開示が実装され得る、１つまたは複数のネットワークＮ（図１にはただ１つが表されている）によってサポートされるクライアント−サーバーネットワークアーキテクチャは、１つまたは複数のクライアント端末ＣＴ（図１にはただ１つが表されている）と、１つまたは複数のＨＴＴＰサーバーＳＥとを備える。ＤＡＳＨによると、そのようなサーバーＳＥは、メディアオリジン（Ｍｅｄｉａ Ｏｒｉｇｉｎ）とも呼ばれる。それらは、例えば、メディアプレゼンテーション記述（またはＭＰＤ）、いわゆるマニフェストを生成する。これは、コンテンツ配信の配信元であり、マルチメディアコンテンツは、何らかの外部エンティティから来て、メディアオリジンにおいてＨＡＳフォーマットに変換され得る。

クライアント端末ＣＴは、ＨＴＴＰサーバーＳＥの１つからマルチメディアコンテンツを獲得することを望む。マルチメディアコンテンツは、第１の持続時間（例えば、セグメント当たり１０秒）の複数の連続したセグメントに分割される。マルチメディアコンテンツは、サーバーＳＥにおいて異なる表現で利用可能であることが仮定される。クライアント端末は、フラグメントごとにコンテンツを取り出すように、完全なセグメントを要求することができ、またはフラグメントとも呼ばれるセグメントの部分を要求することができる。セグメントのフラグメントに関する要求は、例えば、ＨＴＴＰプロトコルの周知のバイト範囲要求機能を使用することができる。したがって、クライアントは、第２の持続時間（例えば、５００ｍｓのフラグメント当たりのダウンロード持続時間）を目標にして、セグメントの部分をダウンロードすることができる。したがって、ＨＴＴＰサーバーＳＥは、１つまたは複数のＴＣＰ／ＩＰ接続上でＨＴＴＰ適応ストリーミングプロトコルを使用して、セグメント、またはクライアント要求に従って分離されたセグメントのフラグメントを、クライアント端末ＣＴに配送することができる。フラグメントのサイズは、クライアント端末ＣＴによってまたはサーバーＳＥによって決定することができる。クライアント端末ＣＴは、各フラグメントの受信時に、セグメントの表現を別のものに切り換えることを決定することができる。

クライアント端末ＣＴは、ポータブルメディアデバイス、モバイルフォン、タブレットもしくはラップトップ、ＴＶセット、セットトップボックス、ゲームデバイス、または集積回路とすることができる。もちろん、クライアント端末ＣＴは、メディアコンテンツを逆多重化および復号するためのものなど、いくつかのサブ要素を備えるのみで、完全なビデオプレーヤを備えず、外部手段に頼って、復号されたコンテンツをエンドユーザに表示することもある。この場合、クライアント端末ＣＴは、セットトップボックスなどのＨＡＳアウェアなビデオ復号器である。

以下では、所定のクライアント端末ＣＴが、マルチメディアコンテンツのセグメントの第１の表現の少なくとも１つのフラグメントを獲得するために、ネットワークＮ上で要求を送信することが仮定される。

本開示の実施形態によるマルチメディアコンテンツを受信するためのクライアント端末ＣＴによって実装される主要なステップが、図２に示されており、
− セグメントの第１の表現の少なくとも１つのフラグメントを、クライアント端末ＣＴによって、受信するステップ（２１）と、
− クライアント端末ＣＴとサーバーＳＥの１つとの間の送信経路上において利用可能な帯域幅を考慮することによって、
・セグメントの第１の表現のすべての後続フラグメントの予想配送時間ＤＴ１、および
・セグメントの少なくとも１つの代わりの表現のすべてのフラグメントの予想配送時間ＤＴｋ
を決定するステップ（２２）と、
− 予想配送時間を考慮することによって、
・セグメントの第１の表現の少なくとも１つの後続フラグメントを受信すること、または
・セグメントの第２の表現の少なくとも第１のフラグメントを受信することであって、第２の表現は、少なくとも１つの代わりの表現に属する、受信すること
の間で選択するステップ（２３）と
を含む。

すでに述べられたように、したがって、本開示は、セグメントの全表現の受信の代わりに、セグメントの表現の少なくとも１つのフラグメントの受信に依存する。

例として、セグメント持続時間が１０秒であり、セグメントの表現が２００、４００、６００、１２００、１８００、２５００、４５００、６５００、および８５００ｋｂｉｔ／ｓで得られ、一定の帯域幅がＨＴＴＰ適応ストリーミングマルチメディアコンテンツの送信の開始時に８．５Ｍｂｉｔ／ｓである場合について再び考慮する。セグメント（またはその表現）が２０個の部分に分割されるときについて考慮し、要求の開始直後に帯域幅が低下した（４２５０ｋｂｉｔ／ｓ）場合、クライアント端末は、時刻０．５秒において、ビットレート２５００ｋｂｉｔ／ｓに対応するセグメントの表現をロードすることを決定することができる。その場合、クライアント端末は、初期要求後７．３８秒で、そのため、コンテンツのレンダリング時刻と比較して２．６２秒前に、全セグメントを取得する。目標の２５００ｋｂｉｔ／ｓは、帯域幅低下が３．５秒よりも前である限り、クライアント端末にいくらかの先行を与える。

図３は、マルチメディアコンテンツを受信するためのクライアント端末ＣＴによって実装される全体的なプロセスの例を示している。

ステップＳ１の間、クライアント端末ＣＴは、Ｒ１_iとも呼ばれるセグメントｉの第１（又は初期）の表現を選択し、セグメントｉの第１の表現の少なくとも１つのフラグメントを求める要求を、少なくとも１つのサーバーＳＥに送信する。そのような要求は、バイト範囲を要求するＨＴＴＰ／１．１オプションを使用することができる。

セグメントの開始時には（すなわち、セグメントの第１のフラグメントについては）、セグメントの表現は、通常通りに選択され得る。

フラグメントの持続時間に関して、セグメント内のフラグメントの数は、クライアントが抵抗することを望む予想されるより悪い帯域幅分割よりも大きくなるように選択され得る。実際に、本開示に従ってロバストネスを改善する１つの重要なポイントは、決定のタイムスケールの短縮である。フラグメントの数が多くなるほど、方法はよりロバストになる。帯域幅がＮ分の１にされた場合、クライアントは、現在要求されているフラグメントの受信において、フラグメントの持続時間のＮ倍に等しい遅延を被る。各フラグメントを求める要求内のＨＴＴＰヘッダのオーバヘッドが制限されるように、および／または各フラグメントのサイズがＭＴＵ（「最大送信単位」）の数倍になるように、および／またはフラグメントのサイズがＲＴＴ（「ラウンドトリップタイム」）よりも長いダウンロード時間を必要とするように、フラグメントの数も制限され得る。

この例によると、要求されるバイト範囲は、セグメントサイズをフラグメントの数Ｎによって除算することによっても決定される。セグメントサイズは、全セグメントサイズを返す、セグメントの全コンテンツに関する初期ＨＴＴＰ ＨＥＡＤ要求を用いて獲得され得る。

Ｆ_j、Ｒ１_iと呼ばれるセグメントの第１の表現の少なくとも１つのフラグメントが、ステップＳ２においてクライアント端末ＣＴによって受信され、ステップＳ３においてクライアント端末ＣＴのバッファ内にダウンロードされる。

フラグメントＦ_j、Ｒ１_iが、セグメントｉの最後のフラグメントである場合（チェックＳ４）、クライアント端末ＣＴは、次のセグメントｉ＋１を対象と見なし（ステップＳ５）、ステップＳ１に戻る。

第１のフラグメントＦ_j、Ｒ１_iが、セグメントｉの最後のフラグメントでない場合（チェックＳ４）、クライアント端末ＣＴは、第２の持続時間に対応するタイムスケールで、および場合によっては、第１の持続時間に対応するタイムスケールで、クライアント端末ＣＴとサーバーＳＥとの間の送信経路上において利用可能な帯域幅の推定値を決定する（ステップＳ６）。

本開示による帯域幅推定値は、帯域幅の変化が速やかに（セグメント持続時間よりも速く）分かるように、好ましくは新しいタイムスケールに適合することができる。フラグメントレベルにおける利用可能な帯域幅の推定値は、周知のアルゴリズムを使用して、例えば、タイムスケールを短縮することにより、セグメントレベルにおいて利用可能な帯域幅を決定するために現在使用されているものを使用して、決定され得る。帯域幅推定パラメータは、推定値が、実際の変化にすぐに追随することを可能にすることができる。１つはフラグメントレベルにおいて、１つはセグメントレベルにおいて、２つの並列した帯域幅推定が行われ得る。

特に、帯域幅推定値は、周期的に、または少なくとも１つのフラグメントもしくは少なくとも１つのセグメントを受信した後、または送信経路の変化を検出した後に決定され得る。

その後、クライアント端末ＣＴは、ステップＳ７において、利用可能な帯域幅を考慮することによって、セグメントｉの第１の表現のすべての後続フラグメントＦ_m、Ｒ１_i、（ここで、ｍ∈［ｊ＋１，Ｎ］）の予想配送時間ＤＴ１（すなわち、クライアント端末が同じ表現Ｒ１_iをロードし続けた場合のセグメントｉの予想配送時間）、およびサーバーＳＥにおいて利用可能なセグメントｉの少なくとも１つの代わりの表現のすべてのフラグメントの予想配送時間ＤＴｋ（すなわち、クライアント端末が現在の表現Ｒ１_iのロードをアボートし、別の表現に切り換わる場合のセグメントｉの予想配送時間）を決定する。低減された帯域幅の場合に推定されたものよりも低いビットレートを有し、または増加された帯域幅の場合に推定されたものよりも高いビットレートを有する、セグメントｉのサーバーＳＥにおいて利用可能な各表現について計算すべき予想配送時間の値が１つ存在する。

第１のケースでは（すなわち、クライアント端末が同じ表現Ｒ１_iをロードし続ける場合）、クライアント端末は、すでにセグメントの一部をダウンロードしているため、ダウンロードを続行するが、第２のケースでは（すなわち、クライアント端末が現在の表現Ｒ１_iのロードをアボートし、別の表現に切り換わる場合）、クライアント端末は、先にダウンロードされたセグメントの一部を削除し、セグメントの新しい表現を最初からロードし始めるので、これらの計算は異なる。

チェックＳ８において、クライアント端末ＣＴは、予想配送時間ＤＴ１、ＤＴｋを考慮することによって、セグメントｉの第１の表現Ｒ１_iの少なくとも１つの後続フラグメントＦ_j+1を受信するほうが（すなわち、セグメントｉの同じ表現Ｒ１_iを継続するほうが）良いか、それともセグメントｉの第２の表現Ｒ２_iの少なくとも第１のフラグメントを受信するほうが（すなわち、セグメントｉの別の表現に切り換わるほうが）良いかを決定する。

クライアント端末ＣＴが、セグメントｉの第１の表現Ｒ１_iの少なくとも１つの後続フラグメントＦ_j+1を受信するほうが良いと決定した場合、アルゴリズムは、次のフラグメントＦ_j+1をダウンロードするために、ステップＳ３に戻る。

クライアント端末ＣＴが、セグメントｉの第２の表現Ｒ２_iの少なくとも第１のフラグメントを受信するほうが良いと決定した場合、クライアント端末は、セグメントｉの新しい表現を選択し（ステップＳ９）、アルゴリズムは、Ｆ_j、Ｒ２_iと呼ばれるセグメントｉの第２の表現の第１のフラグメントを受信するために、ステップＳ２に戻る。

この例によると、決定は、クライアント端末のバッファのサイズと、エンドユーザが被るビデオ品質の変化との間の、アプリケーションによって選択されるトレードオフに依存する。例えば、レンダリングのフリーズを回避するために、クライアント端末のバッファは、好ましくは決してエンプティになるべきではない。さらに、使用の状況に応じて、アプリケーションは、より長いバッファを選択することによって、バッファ維持においてより大きな余裕を保つことを決定することができる。

例えば、そのような決定は、簡略化されたアルゴリズムに従って行われ得る。
− クライアント端末が同じ第１の表現Ｒ１_iをロードし続ける場合、セグメントｉの予想配送時間ＤＴ１を決定する。言い換えると、クライアント端末は、帯域幅が今のままであることを仮定して、変わらずセグメントｉをロードするための時間を決定する。

○ ＤＴ１が、最大で、バッファ内に存在するセグメントの再生時間の持続時間に等しい場合（クライアント端末は、バッファが消費されるかどうかをチェックする）、クライアント端末は、その決定を変更せず、同じ表現をダウンロードし続ける。

○ ＤＴ１が、バッファ内に存在するセグメントの再生時間の持続時間よりも長い場合、サーバーＳＥにおいて利用可能なセグメントｉの少なくとも１つの代わりの表現ｋのすべてのフラグメントの予想配送時間ＤＴｋを決定する。予想配送時間は、全セグメントにおいて決定される。

・ ＤＴｋが、最大で、バッファ内に存在するセグメントの再生時間の持続時間に等しい場合、セグメントｉのこの表現ｋに切り換わることを決定する。言い換えると、クライアント端末は、表現ｋの対応するビットレートが、バッファ全体を消費することなく機能するかどうかをチェックする。低減された帯域幅の場合、クライアント端末は、推定されたものよりも低い最高のビットレートを有する表現を選択することができ、それに対しては、ＤＴｋが正しい。これは、最良の品質のための選択である。より低いビットレートもバッファ保護を保証するが、コンテンツ品質はより低い。

切り換わる決定が行われた場合、クライアント端末は、セグメントの新しい表現の受信を、すなわち、新しいビットレートを有するセグメントの受信を開始する。

増加された帯域幅の場合、異なる選択を評価するための計算は、現在のダウンロードが時間内に終了するという事実に関係なく、より高いレートについて、異なる選択肢をチェックすることを除いて、上のものと同様である。その後、クライアント端末のバッファ制約を満たすことが可能な最高のレートを選択する。

先行技術の技法は、セグメントのための表現を選択し、その後、後続セグメントのための別の表現を要求できるようになる前に、全セグメントをロードすることを提案するが、したがって、本開示のこの例によると、セグメントロードをそれの小さい部分に分割し、フラグメント持続時間に対応するタイムスケールにおいて利用可能な帯域幅の推定を行い、セグメントの別の表現に切り換わることを、帯域幅の減少または増加の後、これが有利である場合、各フラグメントにおいて決定することが可能である。

結果として、本開示によると、表現の変更がひとたび決定されると、新しいセグメントのダウンロードが開始する。決定の全プロセスが、新しいセグメント表現を用いて再開され得、帯域幅が増加または減少した場合、表現変更の新しい決定が行われ得る。

したがって、本開示の少なくとも１つの実施形態は、ＨＴＴＰストリーミング適応において、帯域幅の変化に対するより強いロバストネスを可能にする。これは、ビデオのフリーズを回避するのに役立つのと同時に、短いバッファの使用が視聴遅延を最小化することを可能にする。

本開示の一実施形態によると、フラグメントのサイズは相対的に小さくすることができるので、パイプライン化は、フラグメントの要求のために使用され得る。これを行わないと、要求されたフラグメントごとに、各フラグメントの開始時に、ネットワークＲＴＴに等しいアイドル時間が発生する。

しかしながら、要求がひとたびサーバーに送信されると、それはアボートさせることができない。そのため、毎回、パイプライン化された要求の数は制限されるべきである。その理由は、表現を変更する決定は、先行する要求が回答されるときに一度だけＨＴＴＰサーバーによって処理される新しい要求をパイプラインに入れるためである。

この実施形態の好ましい実装は、前もってただ１つの要求をパイプライン化することであろう。さらに、次のフラグメントを求める要求を送信する時刻は、現在のフラグメントの受信が完了される時刻の推定に基づく。推定されたＲＴＴは、この時刻から減算され、次の要求は、その時刻に送信される。

フラグメントがＲＴＴよりもはるかに長い場合、帯域幅推定は、各フラグメントロードの間の、次の要求を送信する時刻の直前に更新され得、次のフラグメントの前に表現を変更する決定を行う機会を増加させる。

図４は、本開示の実施形態によるマルチメディアコンテンツを受信するためのクライアント端末の例を示している。

図４に示されるように、クライアント端末ＣＴは、少なくとも、
− １つまたは複数の接続のインターフェース４１（例えば、Ｗｉ−Ｆｉ、イーサネット（登録商標）、ＡＤＳＬ、ケーブル、モバイル、および／もしくはブロードキャスト（例えば、ＤＶＢ、ＡＴＳＣ）インターフェースなどの有線ならびに／または無線）と；
− ＨＴＴＰサーバーＳＥと通信するためのプロトコルスタックを含む通信モジュール４２（特に、通信モジュール４２は、当技術分野においてよく知られたＴＣＰ／ＩＰスタックを備える。もちろん、クライアント端末ＣＴがＨＴＴＰサーバーＳＥと通信することを可能にする他の任意のタイプのネットワークおよび／または通信手段とすることもできる）と；
− セグメントの少なくとも１つのフラグメントを受信するための適応ストリーミングモジュール４３（ＨＴＴＰストリーミングマルチメディアコンテンツをＨＴＴＰサーバーＳＥから受信する）と；
− 送信経路上において利用可能な帯域幅を考慮することによって、
・セグメントの初期表現のすべての後続フラグメントの予想配送時間、および
・セグメントの代わりの表現のすべてのフラグメントの予想配送時間
を決定するための予想配送時間モジュール４４と；
− 予想配送時間を考慮することによって、
・セグメントの初期表現の少なくとも１つの後続フラグメントを受信すること、または
・セグメントの代わりの表現の少なくとも第１のフラグメントを受信すること
の間で選択するための選択モジュール４５（ネットワーク制約および自らの制約により良く一致するビットレートのフラグメントを継続的に選択する）と；
− マルチメディアコンテンツを復号およびレンダリングするように適合されたビデオプレーヤ４６と；
− クライアント端末ＣＴの不揮発性メモリ内に記憶されたアプリケーションおよびプログラムを実行するための１つまたは複数のプロセッサー４７と；
− ＨＴＴＰサーバーＳＥから受信したフラグメントをビデオプレーヤ４６に送る前にバッファリングするための、揮発性メモリなどの、記憶手段４８と；
− 送信経路の帯域幅を推定するように構成された帯域幅推定器４９と；
− 汎用的なクライアント端末機能を実行するために、当業者に周知の様々なモジュールおよびすべての手段を接続する内部バスＢ１と；
を備える。

本開示は、ＨＴＴＰ２．０など、進行中の要求をアボートすることを許可するプロトコルバージョンの使用にも供給される。これは、ＨＴＴＰ１．１の場合、（下層の接続の停止による以外は）提供されなかったが、ＨＴＴＰ２．０は、要求／応答のストリームを多重化することを可能にし、これらのストリームを駆動するための制御メッセージも提供する（特に、ＲＳＴコマンドは、既存のストリームを停止する）。

現在の最新デバイスは、１つのセグメントの表現を決定することによって動作し、その場合、別の表現に切り換わるには、後続のセグメント要求まで待たなければならないが、本開示の代わりの実施形態は、
− セグメント持続時間の細分に対応するタイムスケールで利用可能な帯域幅を推定するステップと；
− 新しい各推定において、推定された帯域幅を与えられるほうが（すなわち、帯域幅の変更後のほうが）有利である場合、表現の変更に進むことを決定するステップと；
− （特定の実施形態に関して説明されたものなど）変更の決定が行われた場合、現在受信中のセグメントの第１の表現の受信をアボートするステップと；
− セグメントの第２の表現を送信するようにサーバーに要求するステップと；
を含む方法に依存する。

特定の実施形態を参照して先に説明されたステップのいくつかは、代わりの実施形態の方法にも供給され得る。

代わりの実施形態の可能な実装として、Ｄが、セグメント持続時間であり、Ｎが、１つのセグメントの間の目標とされるチェックの選択された数であり（Ｎは、例えば、１０と２０の間に含まれる）、Ｓが、（ビット単位の）セグメントサイズであるとする。方法を実装するクライアント端末は、以下の２つのイベント、すなわち、
− 直前の推定以降、Ｓ／Ｎビットが受信された、
− 直前の推定以降、Ｄ／Ｎ秒の時間が経過した、
のどちらかが最初に生じたときに、帯域幅を再計算することができる。

さらに、代わりの実施形態の精緻化において、一連の「瞬時」測定を平均することによって、推定される帯域幅をならすことが可能であり得る。最近の測定により大きい重みを与える重み付け平均は、帯域幅の動向をより良く反映するので、好ましい。

図面のフローチャートおよび／またはブロック図は、本開示の様々な実施形態による、システム、方法、およびコンピュータプログラム製品の可能な実装の構成、動作、および機能を示している。この点で、フローチャートまたはブロック図の各ブロックは、指定された論理機能を実装するための１つまたは複数の実行可能命令を含む、モジュール、セグメント、またはコードの一部を表すことができる。いくつかの代わりの実装では、ブロック内で述べられる機能は、図面内で述べられる順序とは異なる順序で生じ得ることにも留意されたい。例えば、連続して示される２つのブロックは、実際には、実質的に同時に実行され得、またはブロックは、時には逆順で実行され得、またはブロックは、含まれる機能に応じて、代わりの順序で実行され得る。ブロック図および／またはフローチャート図の各ブロック、ならびにブロック図および／またはフローチャート図のブロックの組合せは、指定された機能もしくは行為を実行する専用ハードウェアベースシステム、または専用ハードウェアおよびコンピュータ命令の組合せによって実装され得ることにも留意されたい。明示的に説明されていないが、本実施形態は、任意のコンビネーションまたはサブコンビネーションで利用され得る。

当業者によって理解されるように、本発明の原理の特徴は、システム、方法、コンピュータプログラム、またはコンピュータ可読媒体として具体化され得る。したがって、本原理の特徴は、本明細書ではどれもが全体として「回路」、「モジュール」、または「システム」と呼ばれ得る、完全にハードウェアの実施形態、（ファームウェア、常駐ソフトウェア、およびマイクロコードなどを含む）完全にソフトウェアの実施形態、またはソフトウェア特徴とハードウェア特徴を組み合わせた実施形態の形態を取ることができる。さらに、本原理の特徴は、コンピュータ可読記憶媒体の形態を取ることができる。１つまたは複数のコンピュータ可読記憶媒体の任意の組合せが利用され得る。

コンピュータ可読記憶媒体は、１つまたは複数のコンピュータ可読媒体内で具体化され、コンピュータによって実行可能なその上で具体化されるコンピュータ可読プログラムコードを有する、コンピュータ可読プログラム製品の形態を取ることができる。本明細書で使用される場合、コンピュータ可読記憶媒体は、その中に情報を記憶する固有の能力、およびそこからの情報の取り出しを提供する固有の能力を与えられた、非一時的な記憶媒体と見なされる。コンピュータ可読記憶媒体は、例えば、限定されることなく、電子、磁気、光、電磁気、赤外線、もしくは半導体システム、装置、もしくはデバイス、または上記の任意の適切な組合せとすることができる。以下のもの、すなわち、ポータブルコンピュータディスク、ハードウェアディスク、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、消去可能プログラム可能リードオンリーメモリ（ＥＰＲＯＭもしくはフラッシュメモリ）、ポータブルコンパクトディスクリードオンリーメモリ（ＣＤ−ＲＯＭ）、光記憶デバイス、磁気記憶デバイス、または上記の任意の適切な組合せは、本原理が供給され得るコンピュータ可読記憶媒体のより特定の例を提供するが、当業者によって容易に理解されるように、例示的な網羅的ではないリストであるにすぎない。

Claims (15)

1. 少なくとも１つのサーバーから、クライアント端末によってマルチメディアコンテンツを受信するための方法であって、前記マルチメディアコンテンツは、第１の持続時間の少なくとも２つの連続するセグメントに分離され、セグメントは、少なくとも２つの表現に関連付けられ、前記方法は、
   − セグメントの第１の表現の少なくとも１つのフラグメントを受信するステップ（２１）であって、前記セグメントの各表現は、第２の持続時間の少なくとも２つの連続するフラグメントに分離される、ステップと、
   − 前記クライアント端末と前記少なくとも１つのサーバーのうちの１つとの間の送信経路上において利用可能な帯域幅を考慮することによって、
   ・前記セグメントの前記第１の表現のすべての後続フラグメントの予想配送時間、および
   ・前記セグメントの少なくとも１つの代わりの表現のすべての前記フラグメントの予想配送時間
   を決定するステップ（２２）と、
   − 前記予想配送時間を考慮することによって、
   ・前記セグメントの前記第１の表現の少なくとも１つの後続フラグメントを受信すること、または
   ・前記セグメントの第２の表現の少なくとも第１のフラグメントを受信することであって、前記第２の表現は、前記少なくとも１つの代わりの表現に属する、受信すること、
   の間で選択するステップ（２３）と、
   を含む、前記方法。
2. 前記第２の持続時間に対応するタイムスケールで、前記利用可能な帯域幅の推定値を決定するステップを含む、請求項１に記載の方法。
3. 前記第１の持続時間に対応するタイムスケールで、前記利用可能な帯域幅の推定値を決定するステップを含む、請求項２に記載の方法。
4. １つまたは複数の前記推定値は、各々、周期的に、または少なくとも１つのフラグメントを受信した後に、または少なくとも１つのセグメントを受信した後に、または前記送信経路の変化を検出した後に、決定される、請求項２又は３に記載の方法。
5. 前記利用可能な帯域幅の増加が生じた場合、前記第２の表現は、前記第１の表現に関連付けられた第１のビットレートよりも高い第２のビットレートに関連付けられる、請求項１乃至４のいずれかに記載の方法。
6. 前記利用可能な帯域幅の減少が生じた場合、前記第２の表現は、前記第１の表現に関連付けられた第１のビットレートよりも低い第２のビットレートに関連付けられる、請求項１乃至４のいずれかに記載の方法。
7. 前記第１の表現の少なくとも１つの後続フラグメントを受信すること、または前記第２の表現の少なくとも第１のフラグメントを受信すること、の間で前記選択するステップは、前記クライアント端末のバッファの現在のコンテンツの再生持続時間も考慮する、請求項１乃至６のいずれかに記載の方法。
8. 前記予想配送時間の前記決定と、前記第１の表現の少なくとも１つの後続フラグメントを受信することまたは前記第２の表現の少なくとも第１のフラグメントを受信することの間での前記選択とは、フラグメントごとに実装される、請求項１乃至７のいずれかに記載の方法。
9. 前記少なくとも１つのフラグメントを受信するために、少なくとも１つのバイト範囲要求を前記少なくとも１つのサーバーに送信するステップを含む、請求項１乃至８のいずれかに記載の方法。
10. 前記バイト範囲要求の少なくとも１つは、パイプライン化される、請求項９に記載の方法。
11. 前記マルチメディアコンテンツは、ＨＴＴＰ適応ストリームである、請求項１乃至１０のいずれかに記載の方法。
12. 少なくとも１つのサーバーからマルチメディアコンテンツを受信するためのクライアント端末（ＣＴ）であって、前記マルチメディアコンテンツは、第１の持続時間の少なくとも２つの連続するセグメントに分離され、セグメントは、少なくとも２つの表現に関連付けられ、前記クライアント端末は、
    − セグメントの第１の表現の少なくとも１つのフラグメントを受信するように構成されたモジュール（４３）であって、前記セグメントの各表現は、第２の持続時間の少なくとも２つの連続するフラグメントに分離される、モジュールと、
    − 前記クライアント端末と前記少なくとも１つのサーバーの１つとの間の送信経路上において利用可能な帯域幅を考慮することによって、
    ・前記セグメントの前記第１の表現のすべての後続フラグメントの予想配送時間、および
    ・前記セグメントの少なくとも１つの代わりの表現のすべての前記フラグメントの予想配送時間
    を決定するように構成されたモジュール（４４）と、
    − 前記予想配送時間を考慮することによって、
    ・前記セグメントの前記第１の表現の少なくとも１つの後続フラグメントを受信すること、または
    ・前記セグメントの第２の表現の少なくとも第１のフラグメントを受信することであって、前記第２の表現は、前記少なくとも１つの代わりの表現に属する、受信すること
    の間で選択するように構成されたモジュール（４５）と、
    を備えた、前記クライアント端末。
13. 前記決定するモジュールは、前記第２の持続時間に対応するタイムスケールで、前記利用可能な帯域幅の推定値を決定するようにさらに構成された、請求項１２に記載のクライアント端末。
14. 前記決定するモジュールは、前記第１の持続時間に対応するタイムスケールで、前記利用可能な帯域幅の推定値を決定するようにさらに構成された、請求項１３に記載のクライアント端末。
15. １つまたは複数の前記推定値は、各々、周期的に、または少なくとも１つのフラグメントを受信した後に、または少なくとも１つのセグメントを受信した後に、または前記送信経路の変化を検出した後に、決定される、請求項１３に記載のクライアント端末。