JP2017535133A - クライアントへのメディアコンテンツのアダプティブストリーミングのためのサーバ、方法、およびコンピュータプログラム製品 - Google Patents

Abstract

本発明の実施形態は、クライアントに向けたアダプティブストリーミングのためのサーバ、方法、およびコンピュータプログラム製品に関する。メディアコンテンツは品質レベルの異なる少なくとも２つのストリームとして符号化され、各ストリームには連続したセグメントが含まれる。サーバは以下の要素を備える：少なくとも２つのストリームのうちの第１のストリームの選択されたセグメントに対する要求をクライアントから受信するように構成される受信機。第１のストリームの選択されたセグメントに対する要求に応答して、第１のストリームの選択されたセグメントをクライアントに送信することと、少なくとも２つのストリームのうちの第２のストリームの対応するセグメントをクライアントにプッシュすることであって、第２のストリームは第１のストリームより低い品質レベルを有する、プッシュすることとを行うように構成される、送信機。

Description

本発明の分野は、サーバからクライアントへのメディアコンテンツのアダプティブストリーミングに関する。詳細には、本発明は、クライアントへのメディアコンテンツのアダプティブストリーミングのためのサーバ、サーバからクライアントへのメディアコンテンツのアダプティブストリーミングのための方法、および前記方法のステップを実行するように構成されたコンピュータプログラム製品に関する。

近年、動画や音声コンテンツなど、メディアコンテンツのストリーミングに対する需要が急速に高まっている。特に、ＹｏｕＴｕｂｅ（登録商標）やＮｅｔＦｌｉｘなど、ＯＴＴ（Ｏｖｅｒ Ｔｈｅ Ｔｏｐ）動画配信アプリケーションの数が増加している。ＯＴＴコンテンツ配信とは、公衆インターネット上でコンテンツを配信することを指す。

特に、ＨＴＴＰアダプティブストリーミング（ＨＡＳ）は、メディアコンテンツをストリーミングするための最も普及した方法に急速になりつつある。ＨＡＳが持つ主な利点の１つは、プレイアウトのフリーズにつながる動画の再バッファリングを回避するために、動画品質をネットワークの帯域幅（ＢＷ）条件に適応させる機能である。

ＨＴＴＰを介してアダプティブストリーミングを行うための技術としては、Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ（Ｍｉｃｒｏｓｏｆｔ）、ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（Ａｐｐｌｅ）、およびＤｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＭＰＥＧ−ＤＡＳＨ）が挙げられる。本発明の関連において、ＨＡＳという用語は、ＨＴＴＰ技術を介して行われる、あらゆるアダプティブストリーミングを表現するために用いられる。さらに、ＨＡＳという用語は、ＨＴＴＰプロトコルの関連プロトコルである、ＳＰＤＹプロトコルを介したストリーミングについても用いられる。

ＨＡＳの導入は、過去に存在した漸進的なダウンロード方法と比較すれば大幅な進歩であるが、エンドユーザのユーザ体感品質（ＱｏＥ）は、まだ向上させることができる。具体的に述べると、従来のＨＡＳ実装では依然として、フリーズが時々発生する。

本発明による実施形態の目的は、プレイアウトのフリーズ発生を抑えることにより、サーバからクライアントへのメディアコンテンツのストリーミングを向上させることである。

本発明の一実施形態によれば、クライアントにメディアコンテンツをストリーミングするためのサーバが提供される。メディアコンテンツは、たとえば、動画、音声、および／または文字であり得る。

メディアコンテンツは、品質レベルの異なる少なくとも２つのストリームとして符号化される。各ストリームは、連続したセグメントを含む。サーバは、受信機と、送信機とを備える。受信機は、少なくとも２つのストリームのうちの第１のストリームの選択されたセグメントに対する要求をクライアントから受信するように構成される。送信機は、第１のストリームの選択されたセグメントに対する要求に応答して、第１のストリームの選択されたセグメントをクライアントへと送信するように構成される。送信機は、第１のストリームより低い品質レベルを有するストリームである、少なくとも２つのストリームのうちの第２のストリームの対応するセグメントを、クライアントにプッシュするようにさらに構成される。

換言すれば、選択されたセグメントについて、要求された品質のバージョンをクライアントに送信することに加えて、サーバは、選択されたセグメントの低品質バージョンをクライアントにプッシュする。

このセグメントについて、要求された品質のバージョンだけでなく低品質バージョンもプッシュすることにより、プルされる高品質セグメントが時間内に到着しない場合のセーフティネットが確立される。それにより、バッファアンダーランおよびこれに対応する再生のフリーズに関するリスクが低減される。

たとえば、従来のＨＡＳ実装形態であれば、帯域幅が突然狭まった場合に、バッファアンダーランが起こり得る。最悪のシナリオでは、新たな高品質セグメント（すなわち、比較的データサイズの大きいセグメント）のダウンロードを開始している最中に帯域幅が突然狭くなる。クライアントは、そのセグメント全体のダウンロードを完了してからでなければ、新たな低品質セグメントを要求することができない。その間、クライアントは、クライアントバッファに格納されたセグメントを消費することになる。高品質セグメントの受信完了時には、バッファ充填が、低品質レベルに切り換えるための閾値（「パニック」閾値としても知られる）を既に下回っている可能性もある。その場合、クライアントは、次のセグメントについては最低品質のものへと移行する。時間内のセグメントの配信が不可能であり、クライアントバッファが枯渇していれば、プレイアウトはフリーズすることになる。しかし、本発明の実施形態では、サーバプッシュにより、クライアントはセグメントの低品質バージョンを利用することが可能となる。それにより、クライアントはフリーズを回避することができる。

第２のストリームは、たとえば、少なくとも２つのストリームの中で最低の品質レベルとなり得る。たとえば、メディアコンテンツは、それぞれ３００Ｋｂｐｓ、１５００Ｋｂｐｓ、および３Ｍｂｐｓという、３つのストリームとして提供され得る。その場合、送信機は、１５００Ｋｂｐｓまたは３Ｍｂｐｓのセグメントが要求されたとき、常に３００Ｋｂｐｓのセグメント（利用可能となる最低品質）をプッシュすることができる。

一実施形態では、サーバは、サーバプッシュをサポートするウェブプロトコルに従ってクライアントと通信するように構成される。

ウェブプロトコルを使用することの利点は、インターネットの既存のインフラを使用できるということにある。さらに、ストリームのセグメントを、問題なくファイアウォールを通して転送することも可能である。

別の実施形態では、ウェブプロトコルは、ＨＴＴＰプロトコルまたはＳＰＤＹプロトコル、好ましくはＨＴＴＰ ２．０またはそれ以降のプロトコルである。

ＨＴＴＰまたはＳＰＤＹプロトコルを使用することの利点は、インターネットの既存のＨＴＴＰインフラを使用できるということにある。たとえば、ＨＡＳコンテンツの配信には、ＨＴＴＰサーバ、ＨＴＴＰプロキシ、およびコンテンツ配信ネットワーク（ＣＤＮ：Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ）が再利用できる。さらに、ストリームのセグメントを、問題なくファイアウォールを通して転送することも可能である。

技術的に言えば、ＳＳＬ／ＴＬＳプロトコルの上層に存在するＨＴＴＰはＨＴＴＰＳであることから、本発明の関連において、ＨＴＴＰという用語はＨＴＴＰＳも包含している。

サーバは、サーバプッシュをサポートするＨＴＴＰベースのプロトコル（ＨＴＴＰ ２．０やそれ以降のプロトコル）またはＳＰＤＹプロトコルを用いた、ＨＴＴＰアダプティブストリーミング用に構成されることが好ましい。

一実施形態では、サーバは、サーバとクライアントの間に継続的接続を確立するように構成され得る。たとえば、この接続は、ＴＣＰ接続となり得る。

一実施形態では、送信機は、多重化を用いることにより、第２のストリームのセグメントを第１のストリームのセグメントと同時にプッシュするように構成される。

具体的には、ＨＴＴＰ ２．０やそれ以降のプロトコル、またはＳＰＤＹは、多重化機能を備えている。第１のストリームおよび第２のストリームのセグメント転送を多重化することにより、要求された品質を持つセグメントと同時に、低品質バージョンのセグメントも利用可能となる。よって、要求された品質のバージョンの転送が（突然の帯域幅の縮小などによって）予期せず減速した場合であっても、クライアントは、低品質セグメントを容易に利用することが可能となる。したがって、プレイアウトのフリーズが防止され得る。

代替的実施形態では、送信機は、要求されたセグメント（すなわち、第１のストリームのセグメント）の送信前に、低品質セグメント（すなわち、第２のストリームのセグメント）をプッシュするように構成される。

一実施形態では、送信機は、第２のストリームのセグメントのプッシュに対し、第１のストリームのセグメントの送信よりも高い優先度を割り当てるように構成される。

具体的には、ＨＴＴＰ ２．０やそれ以降のプロトコル、またはＳＰＤＹが、優先度制御をサポートする。

一実施形態では、送信機は、第１のストリームの品質レベルが品質閾値を超過する場合にのみ第２のストリームのセグメントをプッシュするように構成される。

一実施形態では、送信機は、サーバとクライアントの間で利用可能な帯域幅が帯域幅閾値を下回る場合にのみ第２のストリームのセグメントをプッシュするように構成される。

一実施形態では、送信機は、クライアントとサーバの間のラウンドトリップタイム（ＲＴＴ）がＲＴＴ閾値を上回る場合にのみ第２のストリームのセグメントをプッシュするように構成される。

一実施形態では、サーバがクライアントのバッファ充填を推定するように構成され、送信機は、推定されたバッファ充填がバッファ閾値を下回る場合にのみ第２のストリームのセグメントをプッシュするように構成される。

一実施形態では、サーバは、要求された各セグメントのクライアントへの配信時間を追跡するように構成されるトラッカをさらに備える。送信機は、第１のストリームの選択されたセグメントに対する要求に応答して、選択されたセグメントに先行するセグメントの追跡された配信時間が前記先行するセグメントの持続時間を超過する場合にのみ第２のストリームの対応するセグメントをプッシュするように構成される。

換言すれば、先行する要求についての配信時間が先行して要求されたセグメントの持続時間を超過した場合にのみ、高品質セグメントに対する要求に応答して低品質セグメントがプッシュされる。したがって、サーバは、クライアントのバッファが低減した場合にのみセブメントをプッシュする。送信機は、要求された品質のセグメントを送信する前に、低品質のセグメントをプッシュするように構成されることが好ましい。

たとえば、クライアントは、ＶＱ３のセグメントｎを要求し得る。サーバは、前記セグメントの配信時間を追跡する。それに続いて、クライアントは、ＶＱ＞０（たとえば、ＶＱ２またはＶＱ３）のセグメントｎ＋１を要求する。サーバは、セグメントｎの配信時間がセグメントｎの持続時間を超過したと判定した場合、ＶＱ０のセグメントｎ＋１をプッシュすることになる。この条件が満たされなければ、セグメントはプッシュされない。

サーバは、いくつかの先行するセグメントおよびそれらの持続時間に関して追跡した時間に基づき、低品質のセグメントをプッシュするかどうかを決定することもできる。

送信機は、配信時間が所定量の持続時間（たとえば、１−１０秒）を超過した場合にのみ、低品質のセグメントをプッシュするように構成され得る。

上記の基準は併用可能であることに留意されたい。たとえば、送信機は、ＲＴＴがＲＴＴ閾値を上回り、かつ第１のストリームの品質レベルが品質閾値を超過する場合にのみ、第２のストリームのセグメントをプッシュするように構成され得る。

本発明の別の実施形態は、サーバからクライアントへのメディアコンテンツのアダプティブストリーミングのための方法に関する。メディアコンテンツは、たとえば、動画、音声、および／または文字となり得る。

一実施形態では、メディアコンテンツは、品質レベルの異なる少なくとも２つのストリームとして符号化される。各ストリームは、連続したセグメントを含む。方法には、少なくとも２つのストリームのうちの第１のストリームの選択されたセグメントに対する要求をクライアントからサーバを用いて受信するステップが含まれる。方法には、第１のストリームの選択されたセグメントに対する前記要求に応答して、第１のストリームの選択されたセグメントをサーバからクライアントへと送信するステップがさらに含まれる。方法には、第１のストリームの選択されたセグメントに対する要求に応答して、サーバからクライアントに、少なくとも２つのストリームのうちの第２のストリームの対応するセグメントをプッシュするステップであって、第２のストリームは第１のストリームより低い品質レベルを有する、プッシュするステップがさらに含まれる。

一実施形態では、第２のストリームのセグメントは、第１のストリームの品質レベルが品質閾値を超過する場合にのみプッシュされる。

一実施形態では、第２のストリームのセグメントは、サーバとクライアントの間で利用可能な帯域幅が帯域幅閾値を下回る場合にのみプッシュされる。

一実施形態では、第２のストリームのセグメントは、クライアントとサーバの間のラウンドトリップタイム（ＲＴＴ）がＲＴＴ閾値を上回る場合にのみプッシュされる。

一実施形態では、方法には、サーバを用いてクライアントのバッファ充填を推定することがさらに含まれる。このとき、第２のストリームのセグメントは、推定したバッファ充填がバッファ閾値を下回る場合にのみプッシュされる。

一実施形態では、方法には、要求された各セグメントのクライアントへの配信時間を追跡することが含まれる。この実施形態では、方法には、第１のストリームの選択されたセグメントに対する要求に応答して、選択されたセグメントに先行するセグメントの追跡された配信時間が前記先行するセグメントの持続時間を超過する場合にのみ第２のストリームの対応するセグメントをプッシュすることがさらに含まれる。

低品質のセグメントをプッシュするかどうかは、いくつかの先行するセグメントおよびそれらの持続時間に関して追跡された時間に基づいて決定されてもよい。

配信時間が所定量の持続時間（たとえば、１−１０秒）を超過した場合にのみ、低品質のセグメントがプッシュされてもよい。

上記の基準は併用可能であることに留意されたい。たとえば、先行するセグメントの追跡された配信時間が前記先行するセグメントの持続時間を超過し、かつ第１のストリームの品質レベルが品質閾値を超過する場合にのみ、第２のストリームのセグメントをプッシュすることも可能である。

本発明の別の実施形態は、サーバからメディアコンテンツを受信するためのアダプティブストリーミングクライアントに関する。

一実施形態では、メディアコンテンツは、品質レベルの異なる少なくとも２つのストリームとして符号化される。各ストリームは、連続したセグメントを含む。クライアントは、レート決定構成要素、送信機、受信機、およびプレイアウト構成要素を備える。レート決定構成要素は、サーバとクライアントの間の帯域幅を決定するように構成される。レート決定構成要素は、決定した帯域幅に基づいて少なくとも２つのストリームの異なる品質レベルのうちから品質レベルを選択するようにさらに構成される。送信機は、第１のストリームの選択されたセグメントに対する要求をサーバに送信するように構成される。このとき、第１のストリームは選択された品質レベルに対応する。受信機は、前記要求に応答してサーバによって送信された、選択された品質レベルのストリームの選択されたセグメントを受信するように構成される。受信機は、第１のストリームより低い品質レベルを有するストリームである、少なくとも２つのストリームのうちの第２のストリームのプッシュされたセグメントを受信するようにさらに構成される。プレイアウト構成要素は、受信機によって受信されたセグメントを再生するのに適したものである。クライアントは、帯域幅が事前に決定した帯域幅を下回る場合、第１のストリームの対応するセグメントの代わりに、プッシュされたセグメントを再生するように構成される。

本発明の実施形態によるクライアントが持つ利点は、帯域幅が縮小した場合でも最低品質のセグメントがローカルで利用可能なため、より大きなリスクを取ってアダプティブストリーミングのＶＱを落とすまでの待ち時間を延長できることにある。よって、クライアントは、平均品質レベルを向上させることができる。さらに、従来のクライアントは、セグメントの低品質バージョンをサーバに要求する必要があるのに対し、本発明の実施形態によるクライアントであれば、プッシュされたセグメントが事前に読み込まれているため、このセグメントを即座に使用することができる。これにより、フリーズのリスクをさらに低減し得る。

本発明の実施形態は、アダプティブストリーミングクライアントにより、サーバからメディアコンテンツを受信するための方法にさらに関する。メディアコンテンツは、品質レベルの異なる少なくとも２つのストリームとして符号化される。各ストリームは、連続したセグメントを含む。方法には、サーバとクライアントの間の帯域幅を決定するステップが含まれる。方法には、決定した帯域幅に基づいて少なくとも２つのストリームの異なる品質レベルのうちから品質レベルを選択するステップがさらに含まれる。方法には、第１のストリームの選択されたセグメントに対する要求をサーバに送信するステップがさらに含まれる。このとき、第１のストリームは選択された品質レベルに対応する。方法には、前記要求に応答してサーバによって送信された、選択された品質レベルのストリームの選択されたセグメントを受信するステップがさらに含まれる。方法には、第１のストリームより低い品質レベルを有するストリームである、少なくとも２つのストリームのうちの第２のストリームのプッシュされたセグメントを受信するステップがさらに含まれる。方法には、帯域幅が事前に決定した帯域幅を下回る場合、第１のストリームの対応するセグメントの代わりに、プッシュされたセグメントを再生することがさらに含まれる。

本発明の別の実施形態は、実行されると、上記の方法のステップを実行するように構成される非一時的コンピュータ実行可能命令を含む、コンピュータプログラム製品に関する。

サーバに対する上記と同様の効果および利点は、方法およびコンピュータプログラム製品に対しても当てはまる。

添付の図面は、現在好ましいとされる、本発明に関する非限定的な例示的実施形態を例示するために使用されるものである。以下の詳細な説明を添付図面と併読することにより、本発明の特徴および目的が持つ上記および他の利点はより明瞭なものとなり、本発明がより良く理解されよう。

クライアントがロード状態にある、典型的なＨＡＳセッションの概略図である。 リニアストリーミングクライアントが定常状態にある、典型的なＨＡＳセッションの概略図である。 ビデオオンデマンド（ＶｏＤ）クライアントが定常状態にある、典型的なＨＡＳセッションの概略図である。 本発明の一実施形態による、異なる品質レベルを持つセグメントの転送を示す概略図である。 本発明の一実施形態による、ブラウザプラグインとしてのＨＴＴＰアダプティブストリーミングクライアントを示す概略図である。 本発明の一実施形態による、スタンドアロンアプリケーションとしてのＨＴＴＰアダプティブストリーミングクライアントを示す概略図である。 本発明の一実施形態による、コンテンツ配信ネットワークの配信機器を示す図である。 本発明による方法の第１の実施形態の流れ図である。 本発明による方法の第２の実施形態の流れ図である。 本発明による方法の第３の実施形態の流れ図である。

ＨＡＳの実装形態（図１Ａ−Ｃ）には、サーバ２およびクライアント４が含まれる。図１Ａは、初期状態のクライアントを示している。クライアント４は、要求「ＧＥＴ ｍａｎｉｆｅｓｔ」をサーバ４に送信する。サーバは、マニフェスト（ｍａｎｉｆｅｓｔ）ファイルをクライアントに返送することによって応答する。クライアントは、マニフェストファイルを読み取る。マニフェストファイルには、メディアコンテンツストリームのセグメントに関するメタデータが含まれるが、そのメディアコンテンツを再生するのに必要となるＤＲＭデータなど、さらなる情報が含まれてもよい。具体的に述べると、マニフェストファイルには、利用可能な品質レベルが記述されてよい。

図示の例では、マニフェストファイルには、ＤＲＭデータが利用可能であると示されている。よって、クライアントは、「ＧＥＴ ＤＲＭ ｉｎｆｏ」要求をサーバ２に送信することによって、ＤＲＭデータを要求する。サーバ２は、ＤＲＭデータをクライアント４に送信することによって応答する。ＤＲＭデータの要求およびＤＲＭデータの送信はオプションであることに留意されたい（たとえば、メディアコンテンツがＤＲＭによって保護されない場合もある）。

次に、クライアント４はロード状態へと切り換わる。ロード状態にあるクライアント４は、ストリームの第１のセグメントを、所望の品質レベルで要求することから始動する。この要求は、要求をサーバ２に送信することで行われる。品質レベルは、典型的にはクライアントに対して固定である初期品質とすることもできれば、利用可能な帯域幅および／または利用可能なＣＰＵ能力に基づき決定した品質レベルとすることもできる。ストリーミングは２つのタイプに区別される。すなわち、リニアストリーミング（ライブストリーミングとしても知られる）であるか、ビデオオンデマンド（ＶｏＤ）ストリーミングであるかの区別がなされる。大多数のリニアストリーミング配備において、マニフェストファイルは、サーバが利用を許可した新たなセグメントを含み入れるために、定期的に更新される。リニアストリーミングクライアントは、通常、クライアントのバッファを埋めるために、リニアストリームのライフサイクルにおいてＤ秒前のものとなったセグメントを要求することにより、新たなプレイアウトを開始することになる。ＶｏＤクライアントであれば、要求されたＶｏＤタイトルの第１のセグメントを選択するのが普通である。なお、ＶｏＤクライアントの場合、マニフェストファイルは静的なものとなる。

ロード状態において、クライアント４は、プレイアウトレートよりも素早く、連続的に後続のセグメントを取得する。すべてのセグメントダウンロードがプレイアウトレートよりも高速で受信されていれば、クライアントは自身のプレイアウトバッファを増大させることになる。このような状態であれば、リニアストリーミングクライアントは安定してリニアストリームを追っていく。

連続的なプレイアウトを保証するのに十分なセグメントがバッファに含まれると、クライアント４は定常状態になる。リニアストリーミングクライアント４の場合（図１Ｂ）、ライブストリームの最新のセグメントがサーバ２において利用可能となったときに直ちに同セグメントを受信する状態にクライアント４がある場合、バッファはほぼＤ秒という値に達する。通常、クライアント４は、新たなマニフェストファイルを周期的にフェッチすることになる。新たなセグメントがダウンロード可能であると新たなマニフェストファイルによって示されると、リニアストリーミングクライアント４は、直ちにその新たなセグメントを取得する。

ＶｏＤクライアント４の場合（図１Ｃ）、定常状態における挙動は異なったものとなる。特定のバッファレベルに到達すると（たとえば、３０秒）、そのバッファレベルを超過しないように、クライアント４は、２つのセグメント取得の間に、追加の待機時間を付与する。

例示的一実施形態（図２）では、サーバ２は、３Ｍｂｐｓでの高品質ストリームＡと、３００Ｋｂｐｓでの最低品質ストリームＢとを利用可能である。クライアント４が高品質ストリームＡのセグメントを要求するとき、サーバ２は、要求されたストリームＡのセグメントを送信することによって応答する。サーバ２はさらに、対応するストリームＢのセグメントをクライアント４にプッシュする。図示している通り、ストリームＡのセグメント１が要求されているときには、ストリームＢのセグメント１もプッシュされている。ストリームＡのセグメント２が要求されているときには、ストリームＢのセグメント２もプッシュされている。図示の例では、ストリームＢのセグメントはストリームＡのセグメントよりも高い優先度レベルでサーバ２によってプッシュされており、これによって、たとえば帯域幅が突然狭くなるような場合の「セーフティネット」として、低品質のセグメントをクライアント４が利用できるように保証している。図示の例では、サーバ２は、ＨＴＴＰ ２．０優先度制御を採用している。また、図２は、ストリームが（たとえばＨＴＴＰ多重化を用いて）多重化可能であることを表している。

図３はサーバ２およびクライアント４を示しており、図示のクライアント４には、ブラウザ６と、ＨＡＳ機能のためのブラウザプラグイン８とが含まれている。プラグイン８によるオブジェクトの要求は、ブラウザに対する、明確に定義されたソフトウェアインタフェースを経由することによってのみ可能となる。いくつかの実装形態では、オブジェクトがサーバ２によってブラウザ６へとプッシュされたということをプラグイン８に通知するインタフェースが存在していなくてもよい。ブラウザ６は、そのオブジェクトをブラウザキャッシュに追加するだけに留める。プッシュされたオブジェクトを後からプラグイン８が要求する場合、ブラウザは要求されたオブジェクトをローカルキャッシュから即座に提供する。

プラグイン８には、クライアントバッファ１２と通信する、レート決定アルゴリズム（ＲＤＡ）構成要素１０が含まれる。クライアントバッファは、プレイアウト構成要素１４と動作可能に接続される。ブラウザ６には、ブラウザキャッシュが含まれる。図示の例では、クライアント４は、サーバ２からの動画コンテンツをストリーミングしている。動画コンテンツは、異なる画質（ＶＱ）に対応した、異なるビットレートで符号化される。以下の例では、最低のＶＱをＶＱ０とし、最高のＶＱをＶＱ３とする。

クライアント４は、ＲＤＡ構成要素１０およびブラウザ６を経由してサーバ２に「ＧＥＴ ｓｅｇ ｎ ＶＱ３」要求を送信することにより、画質がＶＱ３であるセグメントｎをサーバ２に要求する。サーバ２は、要求されたセグメントである「Ｓｅｇ ｎ ＶＱ３」をブラウザ６に送信することによって応答する。ブラウザ６は、そのセグメントをＲＤＡ構成要素１０に配信する。サーバ２はまた、同要求に応答して、品質がＶＱ０のセグメントをブラウザキャッシュ１６にプッシュする。プッシュされたセグメント１８は、前記セグメントに対応する要求をＲＤＡ構成要素１０がブラウザに送信したときにプラグイン８へと配信可能となるように、ブラウザキャッシュ内に残される。クライアント４は、こうした要求を、たとえばセグメントｎを高品質なＶＱ３でダウンロード中に帯域幅が突然狭まったような場合に送信することができる。プッシュされたセグメント１８が既にブラウザキャッシュ１６内に存在しているため、ブラウザはセグメント１８を即座にＲＤＡ構成要素１０へと返すことができる。

図示の実施例では、ブラウザ６が実装されていることにより、オブジェクトをサーバ２からプラグイン８に直接プッシュすることはできない。しかし、本発明は、そのような実装形態に限定されるものではない。当業者であれば、ＮＰＡＰＩインタフェースなど、ブラウザのプラグインインタフェースに関する制限は、現在および今後のすべてのブラウザには存在しない場合があることは理解されよう。たとえば、ブラウザがＨＡＳをネイティブサポートする可能性もあり、これによりＨＡＳプラグイン８は不要となる。

図４はサーバ２およびクライアント４を示しており、図示のクライアント４は、一体型のスタンドアロンアプリケーションとして実装されている。したがって、図３の実施形態とは対照的に、ＲＤＡ構成要素１０は、サーバ２によってオブジェクトがいつプッシュされたかを直接通知されることができる。この例において、クライアント４は動画品質がＶＱ２であるセグメントｎを要求しており、これに対してサーバ２は、要求されたセグメントを返すとともに、ＶＱ０の低品質セグメントｎをクライアントにプッシュしている。

図５は、コンテンツ配信ネットワーク（ＣＤＮ：ｃｏｎｔｅｎｔ ｄｉｓｔｒｉｂｕｔｉｏｎ ｎｅｔｗｏｒｋ）配信機器２の一実施形態を示している。ＣＤＮ配信機器２には、キャッシュ２２と通信する、ＨＴＴＰサーバ２０が含まれる。ＨＴＴＰサーバ２０は、ＣＤＮ内部通信クライアント（ＣＩＣＣ）２４とも通信する。ＣＩＣＣ２４は、キャッシュ２２と通信する。ＨＴＴＰサーバ２０は、ＨＡＳセーフティプッシュアルゴリズム構成要素（ＨＳＰＡ）とも通信するものであり、このＨＳＰＡには、アルゴリズムへの入力用となる、クライアント状態および／またはセッション状態を記憶するためのメモリ構成要素２８がオプションで含まれる。ＣＤＮ配信機器には、ＨＳＰＡがアクセス可能な、構成ファイル３０がさらに含まれてもよい。ＨＳＰＡ構成要素２６は、さらにキャッシュ２２とも通信する。クライアントノード４には、ＨＴＴＰクライアント３２が含まれる。ＨＴＴＰサーバ構成要素２０は、クライアントとのＨＴＴＰ通信を処理する。ＨＴＴＰサーバ２０は、クライアントからＧＥＴ要求を受信する。ＨＴＴＰサーバ２０は、要求されたオブジェクト（たとえば、セグメント）がキャッシュ２２内に既に存在するかどうかを確認するためのチェックを実行する。存在すれば、そのオブジェクトをクライアント４に提供する。存在しなければ、上流のＣＤＮノードからオブジェクトをフェッチするように、ＣＤＮ内部通信クライアント２４に通知する。キャッシュ２２内にオブジェクトが見つからない場合、ＣＩＣＣは、上流のＣＤＮノードからオブジェクトをフェッチする。ＣＩＣＣは、要求されたオブジェクトを完全または部分的に取得したときに、ＨＴＴＰサーバ２０に通知を行う。その後、ＨＴＴＰサーバは、ＨＴＴＰクライアント３２を介したクライアント４への転送を処理する。

ＨＴＴＰ要求または応答がＨＴＴＰサーバによって受信されるたびに、ＨＡＳセーフティプッシュアルゴリズム（ＨＳＰＡ）と呼ばれる機能ブロックに通知される。ＨＳＰＡ構成要素２６は、ＨＡＳに関連しないすべての要求／応答を無視する。要求／応答がＨＡＳ関連のものであれば、ＨＳＰＡ構成要素２６は、１つ以上のアルゴリズムを使用して、要求元クライアントに対して追加オブジェクトをプッシュする必要があるかどうか、およびどの追加オブジェクトをプッシュしなくてはならないかを決定する。この特定の例では、ＨＳＰＡ構成要素２６は、最低ＶＱのセグメントを要求元クライアントにプッシュする必要があるかどうかを決定している。ＨＳＰＡ構成要素２６は、ＨＴＴＰサーバ２０に対し、追加セグメントをサーバプッシュによって配信するように命令する。

ＨＳＰＡ２６は、異なる方法に従って、低品質セグメントをいつプッシュするかを決定することができる。ＨＳＰＡ２６は、低品質セグメントをプッシュし続けることができる（たとえば、高品質セグメントが要求される場合に常に低品質セグメントをプッシュするなど）。あるいは、ＨＳＰＡ２６は、要求された品質が特定の閾値を上回るときのみ、低品質セグメント（たとえば、最低品質セグメント）をプッシュすることもできる。

さらに、ＨＳＰＡ２６は、特定の条件が満たされたとき（すなわち、クライアントがフリーズするという確かなリスクが存在するとき）のみ、低品質セグメントを送信することもできる。かかる条件の例を以下に示す：
− ノードとクライアントの間で利用可能な帯域幅が特定の帯域幅閾値を下回る。
− クライアントとサーバの間のＲＴＴが特定のＲＴＴ閾値を超過する。
− クライアントの推定バッファ充填が特定のバッファ閾値を下回る。サーバは「ＨＡＳセッション再構築」技術を使用して、クライアントにおけるバッファ充填の推定値を得る。
− 先行するセグメントまたは先行するセグメントグループの転送時間が、これらの少なくとも１つの先行するセグメントに関して、対応するプレイアウト持続時間よりも長くなる。これは、クライアントバッファが縮小しつつあることを意味する。
− サーバは、自身の決定を下すために、上記基準を併用してもよい。

本発明の方法による一実施形態では、ステップＳ１００において、サーバは、品質レベルがＶＱ３のセグメントｎに対する要求を受信する。サーバは、ステップＳ１０２でＶＱ３のセグメントｎを送信し、ステップＳ１０４でＶＱ０のセグメントｎをプッシュすることによって応答する。あるいは、多重化を用いて、ステップＳ１０２とＳ１０４の順序を逆転させたり、同時に実行させたりすることもできる。

一実施形態では、ステップＳ１１２において、サーバは、要求されたセグメントの品質（たとえば、動画品質）が品質閾値を超過するかどうかを判定する（図７）。超過しない場合、サーバは追加セグメントをプッシュしない。要求された品質が閾値を超過する場合、ステップＳ１１４において、サーバは、最低品質（たとえば、ＶＱ０）の対応セグメントのプッシュも行う。

一実施形態では、ステップＳ１１２ａにおいて、サーバは、自身とクライアントの間の帯域幅が帯域幅閾値を下回っているかどうかを判定する（図８）。ステップＳ１１２ｂにおいて、サーバは、ＲＴＴがＲＴＴ閾値を超過するかどうかを判定する。ステップＳ１１２ｃにおいて、サーバは、クライアントのバッファ充填を推定し、その推定バッファ充填がバッファ閾値を下回っているかどうかを判定する。ステップＳ１１２ｄにおいて、サーバは、ステップＳ１１２ａ、Ｓ１１２ｂ、および／またはＳ１１２ｃの結果に基づき、セグメントをプッシュする必要があるかどうかを決定する。サーバは、ステップＳ１１２ａ、Ｓ１１２ｂ、および／またはＳ１１２ｃの任意の組み合わせを採用可能であることに留意されたい。たとえば、サーバは、ステップＳ１１２ａとＳ１１２ｂだけを実行して、これら２つのステップの結果に基づいてセグメントＶＱ０をプッシュするかどうかを決定してもよい。サーバは、セグメントをプッシュすべきであると決定した場合、最終ステップＳ１１４において、動画品質ＶＱ０のセグメントをプッシュすることになる。

上述した種々の方法のステップは、プログラミングされたコンピュータおよび／または計算能力を持つ電子デバイスによって実行可能なものであることは、当業者であれば容易に認識されよう。本明細書において、いくつかの実施形態は、たとえばデジタルデータ記憶媒体など、プログラム記憶デバイスも対象に含むことが意図されている。かかるプログラム記憶デバイスは、機械可読またはコンピュータ可読でありかつ機械実行可能またはコンピュータ実行可能な命令プログラムの符号化を行う。前記命令は、前記上述した方法のステップの一部または全部を実行するものである。プログラム記憶デバイスは、たとえば、デジタルメモリ、磁気記憶媒体（磁気ディスク、磁気テープなど）、ハードドライブ、または光学的に読取可能なデジタルデータ記憶媒体とすることができる。また、各実施形態は、上述した方法が有する前記ステップを実行するように（ハードコードまたはソフトコードとして）プログラミングされた、コンピュータおよび／または計算能力を持つ電子デバイスを対象とすることを意図したものである。何らかの機能ブロックを含む、図面に示された種々の要素が持つ機能は、専用のハードウェアやソフトウェアの実行が可能なハードウェアを、適切なソフトウェアと連携させて使用することを通じて提供され得る。ハードウェアには、限定するものではないが、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するためのリードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、および不揮発性ストレージが含まれ得る。従来型および／またはカスタムの他のハードウェアもこれに含まれ得る。同様に、図面に示されたあらゆるスイッチは概念的なものにすぎない。それらの機能は、プログラムロジックの動作を通じて、専用ロジックを通じて、またはプログラム制御と専用ロジックの相互作用を通じて実行され得る。

本明細書のブロック図はいずれも、本発明の原理を体現する例示的回路の概念図を表すことは、当業者によって認められよう。同様に、フローチャートや流れ図はいずれも、コンピュータ可読媒体内で実質的に表現され得るものであって、明示的にコンピュータまたはプロセッサが示されているか否かを問わず、かかるコンピュータやプロセッサによる実行が可能な、種々の処理を表していることは理解されよう。

本発明の原理について、特定の実施形態と関連付けて上に記載したが、かかる記述は例証を目的になされたにすぎず、保護範囲を限定するものではないことを理解されたい。かかる保護範囲は、添付の請求項によって明確化される。

Claims (15)

1. クライアントへのメディアコンテンツのアダプティブストリーミングのためのサーバであって、メディアコンテンツが、品質レベルの異なる少なくとも２つのストリームとして符号化され、各ストリームが連続したセグメントを含むサーバにおいて、
   少なくとも２つのストリームのうちの第１のストリームの選択されたセグメントに対する要求をクライアントから受信するように構成される、受信機と、
   第１のストリームの選択されたセグメントに対する要求に応答して、
   第１のストリームの選択されたセグメントをクライアントに送信することと、
   少なくとも２つのストリームのうちの第２のストリームの対応するセグメントをクライアントにプッシュすることであって、第２のストリームは第１のストリームより低い品質レベルを有する、プッシュすることと
   を行うように構成される、送信機と
   を備える、サーバ。
2. サーバプッシュをサポートするウェブプロトコルに従ってクライアントと通信するように構成される、請求項１に記載のサーバ。
3. ウェブプロトコルが、ＨＴＴＰプロトコルまたはＳＰＤＹプロトコル、好ましくはＨＴＴＰ ２．０またはそれ以降のプロトコルである、請求項２に記載のサーバ。
4. 送信機が、多重化を用いることにより、第２のストリームのセグメントを第１のストリームのセグメントと同時にプッシュするように構成される、請求項１から３のいずれか一項に記載のサーバ。
5. 送信機が、第２のストリームのセグメントのプッシュに対し、第１のストリームのセグメントの送信よりも高い優先度を割り当てるように構成される、請求項１から４のいずれか一項に記載のサーバ。
6. 送信機が、第１のストリームの品質レベルが品質閾値を超過する場合にのみ第２のストリームのセグメントをプッシュするように構成される、請求項１から５のいずれか一項に記載のサーバ。
7. 送信機が、サーバとクライアントの間で利用可能な帯域幅が帯域幅閾値を下回る場合にのみ第２のストリームのセグメントをプッシュするように構成される、請求項１から６のいずれか一項に記載のサーバ。
8. 送信機が、クライアントとサーバの間のラウンドトリップタイム（ＲＴＴ）がＲＴＴ閾値を上回る場合にのみ第２のストリームのセグメントをプッシュするように構成される、請求項１から７のいずれか一項に記載のサーバ。
9. サーバが、クライアントのバッファ充填を推定するように構成され、送信機が、推定されたバッファ充填がバッファ閾値を下回る場合にのみ第２のストリームのセグメントをプッシュするように構成される、請求項１から８のいずれか一項に記載のサーバ。
10. 要求された各セグメントのクライアントへの配信時間を追跡するように構成されるトラッカをさらに備え、送信機が、第１のストリームの選択されたセグメントに対する要求に応答して、選択されたセグメントに先行するセグメントの追跡された配信時間が前記先行するセグメントの持続時間を超過する場合にのみ第２のストリームの対応するセグメントをプッシュするように構成される、請求項１から９のいずれか一項に記載のサーバ。
11. サーバからクライアントへのメディアコンテンツのアダプティブストリーミングのための方法であって、メディアコンテンツが、品質レベルの異なる少なくとも２つのストリームとして符号化され、各ストリームが連続したセグメントを含む方法において、
    少なくとも２つのストリームのうちの第１のストリームの選択されたセグメントに対する要求をクライアントからサーバを用いて受信するステップと、
    第１のストリームの選択されたセグメントに対する要求に応答して、第１のストリームの選択されたセグメントをサーバからクライアントへと送信するステップと、
    第１のストリームの選択されたセグメントに対する要求に応答して、少なくとも２つのストリームのうちの第２のストリームの対応するセグメントをサーバからクライアントにプッシュするステップであって、第２のストリームは第１のストリームより低い品質レベルを有する、プッシュするステップと
    を含む、方法。
12. サーバプッシュをサポートするウェブプロトコルに従ってクライアントと通信するステップであって、ウェブプロトコルが、ＨＴＴＰプロトコルまたはＳＰＤＹプロトコル、好ましくはＨＴＴＰ ２．０またはそれ以降のプロトコルである、通信するステップを含む、請求項１１に記載の方法。
13. サーバからメディアコンテンツを受信するためのアダプティブストリーミングクライアントであって、メディアコンテンツが、品質レベルの異なる少なくとも２つのストリームとして符号化され、各ストリームが連続したセグメントを含むアダプティブストリーミングクライアントにおいて、
    サーバとクライアントの間の帯域幅を決定し、決定した帯域幅に基づいて少なくとも２つのストリームの異なる品質レベルのうちから品質レベルを選択するように構成される、レート決定構成要素と、
    第１のストリームの選択されたセグメントに対する要求をサーバに送信するように構成される送信機であって、第１のストリームが選択された品質レベルに対応する、送信機と、
    前記要求に応答してサーバによって送信された、選択された品質レベルのストリームの選択されたセグメントを受信し、少なくとも２つのストリームのうちの第２のストリームのプッシュされたセグメントを受信するように構成される受信機であって、第２のストリームは第１のストリームより低い品質レベルを有する、受信機と、
    受信機によって受信されたセグメントを再生するためのプレイアウト構成要素と
    を備え、
    帯域幅が事前に決定した帯域幅を下回る場合、第１のストリームの対応するセグメントの代わりに、プッシュされたセグメントを再生するように構成される、アダプティブストリーミングクライアント。
14. アダプティブストリーミングクライアントによってサーバからメディアコンテンツを受信するための方法であって、メディアコンテンツが、品質レベルの異なる少なくとも２つのストリームとして符号化され、各ストリームが連続したセグメントを含む方法において、
    サーバとクライアントの間の帯域幅を決定するステップと、
    決定した帯域幅に基づいて少なくとも２つのストリームの異なる品質レベルのうちから品質レベルを選択するステップと、
    選択された品質レベルに対応する第１のストリームの選択されたセグメントに対する要求をサーバに送信するステップと、
    前記要求に応答してサーバによって送信された、選択された品質レベルのストリームの選択されたセグメントを受信するステップと、
    少なくとも２つのストリームのうちの第２のストリームのプッシュされたセグメントを受信するステップであって、第２のストリームは第１のストリームより低い品質レベルを有する、受信するステップと、
    帯域幅が事前に決定した帯域幅を下回る場合、第１のストリームの対応するセグメントの代わりに、プッシュされたセグメントを再生するステップと
    を含む、方法。
15. 実行されると、請求項１１、１２、または１４のいずれか一項に記載の方法のステップを実行するように構成される非一時的コンピュータ実行可能命令を含む、コンピュータプログラム製品。

Images