JP5701400B2 - アダプティブストリーミングサービスを提供する方法 - Google Patents

Description

本発明は、サーバからクライアントにストリーミングサービスを提供する方法に関する。

アダプティブストリーミングは、ビデオなどのコンテンツをフラグメントまたはセグメントに分割する解決策であり、例えば各ビデオセグメントごとにＮ種類の解像度を利用することができるなど、各ビデオフラグメントまたは各ビデオセグメントごとに異なる解像度または異なる品質レベルをサーバが利用できるようにする解決策である。クライアントは、利用可能な帯域幅の量を継続的にモニタリングし、例えばクライアントとサーバの間の接続で利用できる帯域幅が十分にあるビデオの特定の品質および／または解像度を表すフラグメントをｈｔｔｐ要求／ダウンロードする。異なる解像度を有する可能性もあるフラグメントを次々に要求することによって、これにより、帯域幅が変動しても滑らかなビデオ視聴体験がもたらされる。

ｈｔｔｐアダプティブストリーミングでは、ＨＴＴＰ ＧＥＴ要求は、通常は、直前のセグメントを完全に受信した後、次のセグメントに対して発行されるだけである。

この手法の問題点は、各セグメントごとに、往復時間の時間長の期間が無駄になることである。これは、この技術を用いるときに使用されるサーバとクライアントの間の総帯域幅に影響を及ぼす。特に、遅延の大きなネットワークでは、これは、得られる総帯域幅に明らかな影響を及ぼす。往復時間が長くなることの悪影響は、この場合には、要求／応答の総時間が固有の帯域幅制限自体ではなく往復時間の影響を大きく受ける可能性があるので、小さなセグメント、および帯域幅と遅延の積が大きいネットワークで大きくなる。ＨＴＴＰアダプティブストリーミングの解決策をＳＶＣ符号化ビデオセグメントの配信に用いる場合には、この効果は、さらに顕著になる。ＡＶＣ符号化セグメントが、ＳＶＣにおける１つのベースレイヤセグメントおよび１つまたは複数のエンハンスメントレイヤセグメントに相当する可能性があるからある。

したがって、本発明の実施形態の目的は、前述の問題を解決する解決策を提供することである。

本発明の実施形態によれば、この目的は、サーバからクライアントにストリーミングサービスを提供する方法であって、前記クライアントから前記サーバに連続するセグメントを要求するステップを含み、前記それぞれの連続するセグメントが、前記クライアントが直前のセグメントを完全に受信する前に次のセグメントを求める次の要求を前記クライアントが前記サーバに伝送することができるように、前記クライアントと前記サーバの間のチャネル占有率に関係する前記クライアントによって決定されるタイミングパラメータに基づいて前記クライアントによって決定されるそれぞれの時点に、関連する要求される品質で要求される方法によって達成される。

次のセグメントを要求する時点がクライアントとサーバの間のチャネル占有率に関係するタイミングパラメータによって決まるようにすることによって、帯域幅の無駄の少ないより滑らかな配信を実現するパイプライン式手法が得られる。

次のセグメントを要求する時点は、さらに、クライアント受信バッファの充填レベルまたは占有レベルによって決まるようにすることもできる。変形実施形態では、これは、決定される品質にも当てはまる。

タイミングパラメータは、サーバから提供される情報に基づいて決定することができる。あるいは、タイミングパラメータは、クライアントとサーバの間の通信チャネルの少なくとも１つの測定したパラメータに基づいて決定することもできる。

別の実施形態では、要求される品質も、クライアントとサーバの間の通信チャネルのこの少なくとも１つの測定したパラメータに基づいて決定することができる。

この少なくとも１つの測定したパラメータは、往復時間および帯域幅関連パラメータとすることができる。帯域幅関連パラメータは、既存の方法によって、受信したセグメントのサイズを、このセグメントの最後のバイトの受信時とこの直前のセグメントを求める要求の発行時の間の時間差で割ることによって得ることができる。あるいは、この帯域幅関連パラメータは、直前に受信したセグメントのサイズを、この直前に受信したセグメントの最初のバイトの受信時と最後のバイトの受信時の間の時間差で割ることによって、計算することもできる。

また、本発明は、前述の方法の実施形態を実現するように構成されたクライアントの実施形態にも関する。

さらなる変形形態は、添付の特許請求の範囲に記載されている。

なお、特許請求の範囲で使用される「結合された」という用語は、直接接続された状態のみに限定されるものと解釈すべきではないことに留意されたい。したがって、「装置Ｂに結合された装置Ａ」という表現の範囲は、装置Ａの出力が装置Ｂの入力に直接接続された装置またはシステムに限定されないものとする。この表現は、Ａの出力とＢの入力の間に、その他の装置または手段を含む経路である可能性もある経路が存在するということを意味している。

また、特許請求の範囲で使用される「含む」という用語は、その後に列挙される手段のみに限定されるものと解釈すべきではないことに留意されたい。したがって、「手段ＡおよびＢを含む装置」という表現の範囲は、構成要素ＡおよびＢのみからなる装置に限定されないものとする。この表現は、この装置の構成要素のうち、本発明に関わりがある構成要素がＡとＢだけであるということを意味している。

以下の実施形態の説明を添付の図面と関連付けて参照することにより、本発明の上記その他の目的および特徴はさらに明らかになり、本発明自体も最も良く理解されるであろう。

従来技術のアダプティブストリーミング方法の概略的なタイミング図である。 本発明の実施形態によって得られる概略的なタイミング図である。 本発明の実施形態によって得られる概略的なタイミング図である。 クライアントおよびサーバの両方における図２ａのタイミング事象をさらに説明する図である。 連続するビデオフラグメントを求める連続する要求を生成する時点を決定する概略的な流れ図である。 連続するビデオフラグメントを求める連続する要求を生成する時点を決定する概略的な流れ図である。 ＡＶＣ符号化ビデオのセグメントを要求するために実施される図４ａの流れ図の実施形態を示す図である。 ＳＶＣ符号化ビデオのセグメントを要求するために使用される図４ａの流れ図の別の実施形態を示す図である。 本発明の方法のｈｔｔｐアダプティブストリーミングの実施形態（図７ｂおよび図７ｃ）と従来のｈｔｔｐアダプティブストリーミングとの比較を示す図である。 従来のｈｔｔｐアダプティブストリーミング（図７ａ）と比較するために本発明の方法のｈｔｔｐアダプティブストリーミングの実施形態を示す図である。 従来のｈｔｔｐアダプティブストリーミング（図７ａ）と比較するために本発明の方法のｈｔｔｐアダプティブストリーミングの実施形態を示す図である。 本発明の方法の実施形態を実現するように構成されたクライアントの実施形態を示す概略図である。

本明細書および図面は、単に本発明の原理を例示するものに過ぎない。したがって、本明細書に明示的には記述または図示していなくても、本発明の趣旨および範囲に含まれる本発明の原理を実現する様々な構成を、当業者なら考案することができることを理解されたい。さらに、本明細書に記載する全ての実施例は、本発明の原理と、当技術分野をさらに進歩させるために発明者（等）が与える概念とを、読者が理解するのを助けるという教育的な目的のみを原則的に意図したものであって、これらの具体的に列挙した実施例および条件に限定されるわけではないものと解釈されたい。さらに、本発明の原理、態様および実施形態ならびに本発明の具体的な実施例について本明細書で述べる全ての記述は、その均等物を含むものとする。

当業者なら、本明細書に示す全てのブロック図は、本発明の原理を実施する例示的な回路の概念図を表していることを理解するであろう。同様に、全てのフローチャート、流れ図、状態遷移図、擬似コードなども、コンピュータ可読媒体中に実質的に表現され、明示してある場合もしていない場合もあるコンピュータまたはプロセッサによって実質的に実行される様々な処理を表していることも理解されたい。

ＨＴＴＰアダプティブストリーミングなど、本発明によるアダプティブストリーミング技術は、例えばビデオまたはオーディオをいくつかの品質に符号化して、個々のチャンクにセグメント化する手法を用いている。ビデオセグメントの時間長は、通常は数秒程度である。これらのセグメントは、クライアントが順次すなわち次々に要求することによって、サーバからダウンロードする。これは、クライアントが、１つのセグメントを完全に受信したときにのみ、次のセグメントのＨＴＴＰ ＧＥＴ要求を発行するということである。その概略を、図１に示す。図１では、時点Ｔ１で、通常はＨＴＴＰ ＧＥＴ要求である第１の要求がクライアントからサーバに送信される。Ｔ２で、サーバがこの要求を受信し、この受信時に、サーバは、この第１のセグメントＳ１Ｑ１の最初のバイトのクライアントへの伝送を開始する。時点Ｔ３で、クライアントがこの最初のバイトを受信する。クライアントが第１の要求を送信してからこのセグメントＳ１Ｑ１の最初のバイトをクライアントが受信するまでの時間差、すなわちＴ３−Ｔ１は、通常は、往復時間と呼ばれ、ＲＴＴと略記される。時点Ｔ４で、このセグメントＳ１Ｑ１の最後のバイトを受信すると、直ちに、クライアントは、次のセグメントの次のＧＥＴ要求を発行する。その後、クライアントは、Ｔ４＋ＲＴＴ（往復時間）に等しい時点Ｔ５で、この次のセグメントＳ２Ｑ１を受信する。

このようにして得られる使用される帯域幅ＢＷｐ１は、従来技術によれば、このセグメントの測定／観察したサイズに基づいて決定し、Ｓ１Ｑ１のバイト数で表現し、図１の時間差Ｔ４−Ｔ１で分割することができる。実際には、第１のセグメントのこの決定した値は、一時的に記憶し、例えば指数加重平滑平均技術によって新たなパケットの受信時に更新することができる。図１ではＢＷｐ１で表される、この測定した帯域幅に関するパラメータは、従来技術の方法では、次に要求されるセグメントの品質を決定するために使用される。

この手法の問題点は、各セグメントごとに、往復時間ＲＴＴの時間長を有する期間が無駄になる点である。これが、Ｈｔｔｐアダプティブストリーミング技術を使用するときに、サーバとクライアントの間の総帯域幅に影響を及ぼす。特に、一部のモバイル技術で経験するような遅延の大きなネットワークでは、これは、実現できる総帯域幅に明らかな影響を及ぼすことになる。往復時間が長くなることの悪影響は、この場合には、要求／応答の総時間が往復時間の影響を大きく受けるので、小さなセグメント、および帯域幅と遅延の積が大きいネットワークで大きくなる。また、ＨＴＴＰアダプティブストリーミングなどをスケーラブルビデオコーディング（ＳＶＣ）セグメントの配信に使用する場合には、この影響はさらに顕著になる。これは、ＡＶＣコード化されたセグメントが、ＳＶＣコード化における１つのベースレイヤセグメントおよび１つまたは複数のエンハンスメントレイヤセグメントに相当するからである。したがって、ひとつのセグメントあたり複数のエンハンスメントレイヤが必要になる場合には、ただ１つのセグメントの間に、ＲＴＴの時間長の遅延が数回生じる可能性がある。

したがって、この遅延を低減するために、要求をパイプライン化する方法が提案されている。つまり、一般に、直前のセグメントＳｉ−１Ｑｉ−１の最後のバイトを受信した後でなければ、次のセグメントＳｉＱｉを求める要求がクライアントからサーバに伝送されることはないということである。これを、図２に示す。図２では、直前のセグメントＳ１Ｑ１が要求された時点であるＴ１からデルタｔＳ２だけ離れたＴ４で、第２のセグメントを求める要求が発行されている。同様に、図２では、第２のセグメントが要求された時点であるＴ４からデルタｔＳ２だけ離れたＴ８で、第３のセグメントを求める要求がクライアントによって発行されている。場合によっては、図２には示していないが、直前のセグメントのバイトを全く受信していないうちに、次の要求がクライアントから伝送されることもある。このように、各セグメントを求める要求の伝送は、直前のセグメントを受信したか否かに関わらずに行うことができる。これらの要求を行う時点の決定は、前記クライアントによる、タイミングパラメータの決定に基づいて行われる。このタイミングパラメータは、クライアントとサーバの間のチャネルの占有率に関係する。このタイミングパラメータを決定する方法については、本明細書の後半部分で説明する。

直前のセグメントを完全に受信する前に次のセグメントを要求することにより、改善されたセグメントに基づく配信が実現し、これは、遅延の大きな環境では特に有用である。したがって、クライアントは、連続する次のセグメントを求める次の要求を発行する時点を、このタイミングパラメータに基づいて計算するように構成され、また、前記クライアントと前記サーバの間の通信チャネルの往復時間および／または帯域幅関係パラメータなど、少なくとも１つの測定したパラメータに基づいてこれらの要求されるセグメントの品質を決定するように構成されることもある。したがって、各要求を行う時点は、クライアントとサーバの間のチャネル占有率を表す、それ自体もクライアントによって決定されるこのタイミングパラメータに基づいて、クライアントによって決定される。したがって、次のセグメントを求める次の要求は、クライアントが直前のセグメントを完全に受信する前に、クライアントからサーバに伝送することができる。

必要に応じて、さらに、これらの時点は、前記それぞれのセグメントが前記サーバから供給されるクライアント受信バッファの占有率レベルに基づいて決定することができる。例えばクライアントバッファ中の受信セグメントが十分である場合には、その結果、連続する要求の間の遅延が大きくなることがあり、その結果、直前のセグメントを完全に受信した後に、まだ要求が発行される可能性がある。

好ましい実施形態では、タイミングパラメータは、通信チャネルの少なくとも１つの測定したパラメータに基づいて決定される。ただし、これが必要とされないその他の実施形態もある。例えば、クライアントとサーバの間のクロックが同期しているシステムでは、クライアントは、サーバパイプラインが空き状態になるときに関する情報を直接受信して、これに基づいて要求を送信する時点を決定することもできる。この手順では、クライアントとサーバの間で余計な通信メッセージが必要になり、そのメッセージの間に、クライアントは、最初にこの情報についてサーバにポーリングを行い、これに対して、サーバは、例えば要求されたセグメントの配信の予想残り時間などを示すメッセージで応答する。

前述のように、この通信チャネルの少なくとも１つの測定したパラメータは、往復時間および／または帯域幅関連パラメータとすることができる。実施形態によっては、タイミングパラメータの計算に使用されるこの帯域幅関連パラメータは、従来技術の状況で使用される方法とは異なる方法で得ることができる。この帯域幅関連パラメータを計算する１つの方法は、一般にバイトで表される直前に受信したセグメントのサイズを、この直前に受信したセグメントの最後のバイトと最初のバイトの間の受信時間の差で割ることを含むことがある。この時間差は、図２ａに示すＴ６−Ｔ３である。この帯域幅関連パラメータは、図２ａではＢＷｎ１で示してある。したがって、これは、図１に示し、これを参照して説明した帯域幅ＢＷｎ１を決定する従来の方法とは異なる。

実施形態によっては、関連する要求される品質も、この少なくとも１つの測定したチャネルパラメータに基づいて、かつ／または前記クライアント受信バッファの占有率レベルに基づいて決定することができるが、両変形形態ともに任意選択のものである。

この帯域幅関連パラメータを決定するために、クライアントは、入来セグメントのタイミングおよびサイズをモニタリングし、それらから前述の方法またはさらに別の方法で帯域幅関連パラメータを計算する、モニタモジュールを含む。図８では、このモジュールをＢＷモニタとして示してある。往復時間を測定するために、特定のモジュールを含むことができる。このモジュールは、サーバに対してテスト信号を生成するように構成されており、このテスト信号は、サーバに受信されると、直ちにクライアントに返送される。これらの技術は、当業者には知られているので、ここではこれ以上詳述する必要はない。図８では、このモジュールは、ＲＴＴモニタとして示してある。

ただし、異なるモジュール間にこれほど明確な線引きがなく、例えば中央クライアントプロセッサが上記の全てのステップを実行するように構成されているような、その他のクライアントの実施態様も可能である。

サーバ自体は、従来のサーバであってもよい。すなわち、サーバが要求のパイプライン化、すなわちＲＦＣ ２６１６のＨＴＴＰ １．１に記載されている技術に対応していてもよい。

本発明の方法の実施形態による前述のパイプライン化技術を使用すると、次のセグメントを求める要求を、既にサーバに伝送されているそれより古いいくつかの要求をサーバが取り扱う、または処理する前に、クライアントからサーバに伝送することができる。帯域幅関連パラメータが図２ａに示すようなものである、これらの方法の実施形態では、往復時間は、それ以上の影響を及ぼさない。

要求をパイプライン化することの影響と、それに関連する利点を、図２ａおよび図２ｂならびに図３に示す。これらの図面は、自明な図面であり、両図面ともに、次の要求を生成する時点が、各要求セグメントＳｉＱｉについてデルタｔｉで表される計算した遅延分だけ、直前のセグメントＳｉ−１Ｑｉ−１の最初のバイトの受信時から遅れていることを示している。ただし、その他の実施形態では、それぞれの時点のみをそのように計算する。サーバは、図２ａおよび図２ｂに示すように、セグメントを次々にキューイングし、ＦＩＦＯの原理に従って最初に受信した要求が最初に処理されるように要求待ち行列を処理することにより、セグメントを次々に処理するようになっている。図３は、例えば第１のセグメントを求める要求がサーバ内で受信されたときに、このセグメントの最初のバイトが順次、したがって直前のセグメントの最後のバイトがクライアントに伝送された後で直ちに、サーバからクライアントに送信されることを示している。第１のセグメントは、この第１のセグメントが求める要求を時点Ｓ＿１で受信されるとほとんど直ちに、サーバから伝送される。しかし、次のセグメントは、それらの要求の受信時に、クライアントとサーバの間のチャネルが再度空き状態になるとすぐに、サーバから送信される。この概略を、図２ａおよび図３に示す。この図では、クライアントおよびサーバが、連続するセグメントをパイプライン式に受信し、応答を伝送する。したがって、セグメントＳ２Ｑ２は、サーバが時点Ｓ＿２などでこのセグメントを求める要求を受信してから少し時間が経過した時点Ｓ＿４から伝送される。図３に示す実施形態では、これは、ＲＦＣ２６１６のｈｔｔｐ１．１に記載されている技術である、サーバのいくつかのパイプライン化機能を必要とする。これにより、サーバは、最適なパイプライン方式で、したがって次々に、要求されたセグメントのバイトをこのチャネルを介して順次伝送するように構成される。ＴＣＰ／ＩＰプロトコルをこの機構と併用すると、クライアントまでのチャネルの帯域幅および輻輳が起きる可能性を確認するということになる。

ただし、実施形態によっては、要求を生成して伝送する時点をクライアントが慎重に計算し、この要求をサーバが直ちに処理して要求されたセグメントをチャネルを介して直ちに伝送することによって、この機能がサーバになくても、パイプライン式手法を実現することが可能である。これを、図２ｂに示す。図２ｂでは、直前のセグメントの最後のバイトがクライアントに向かって送信されたときに要求がサーバに到着するようにこれらの要求を慎重に伝送することにより、サーバがパイプライン化機能を有していなくても、パイプライン式手法を実現する。

このように、サーバによる配信が次々に滑らかに行われるようにクライアントが要求を生成して伝送する時点を慎重に計算することにより、チャネルを非常に効率的に使用することができる。

関連する決定した品質を有する符号化されたビデオセグメントを要求するこれらの時点を計算する方法を、図４ａに示す。

この実施形態は、初期決定品質Ｑ１を有する第１のセグメントＳ１Ｑ１を求める要求を送信することで開始される。初期決定品質Ｑ１は、初期デフォルト品質Ｑ１とすることができ、ユーザによって入力されたときにメモリに記憶される、またはデフォルトパラメータである。あるいは、この品質は、一般に帯域幅の可用性に関する情報に基づいて、以前のセッションで利用可能であった帯域幅に基づいて、またはその他の種類の測定値に基づいて、決定することができる。

一般に、この初期品質については、クライアントのモニタモジュールは、以前の測定値を考慮することができないので、最低品質のセグメントがいくつか要求される可能性がある。

図４ａでは、第１のセグメントを求める要求を伝送した後で、クライアントとサーバの間のチャネル占有率に関係する時間パラメータの初期値を決定する。このタイミングパラメータは、図５および図６では「ＰｉｐｅｌｉｎｅＥｍｐｔｙＥｓｔｉｍａｔｅ」として示してあり、その初期値は、第１の要求セグメントＳ１Ｑ１の要求または推定サイズを初期帯域幅関連パラメータＢＷ１で割った商に往復時間ＲＴＴ１の初期推定値を加えた値として計算される。ただし、その他の実施形態では、このタイミングパラメータは、例えば実際のサイズの情報がＰｉｐｅｌｉｎｅＥｍｐｔｙＥｓｔｉｍａｔｅの計算に利用できない場合には、実際のサイズの代わりに平均セグメントサイズを使用するなど、異なる方法で計算することもできる。サーバがその機能に対応していれば、パイプライン中に何があるかを推定した情報およびパイプラインがいつ空き状態になるかを推定した情報をサーバからクライアントに通信することができる別の変形形態も、クライアントサーバ通信によって実現することもできる。このような変形形態では、タイミングパラメータは、サーバからクライアントに通信するだけでよい。

図４ａの次のステップでは、タイミングパラメータの値と往復時間ＲＴＴの実際の測定値の差を、所定のしきい値と比較する。このしきい値は、通常は、数ミリ秒または数十ミリ秒程度である。このしきい値によって、次のセグメントがどれくらい速く要求されるかが決まる。

この差が所定のしきい値より小さい場合には、チャネルが空き状態であることを示している可能性があり、クライアントのセグメント受信バッファがチェックされる。さらに詳細には、このバッファが例えば空である、または例えば５０％など所定の充填レベル未満である場合には、これは、新たなセグメントが要求されることを示す。逆に、このバッファの充填レベルがまだ５０％を超えている場合には、新たなセグメントは必要とされない。その他のクライアント受信バッファでは、この充填レベルは、最大値の百分率では表されず、ビデオの秒数で表される。この場合には、このバッファの充填レベルに鑑みて、新たなセグメントが必要とされるか否かを判定するために、例えば２０秒というしきい値を使用することができる。ただし、これは全てバッファのサイズに関係するので、クライアントによって変わる可能性がある。

バッファの充填レベルが新たなセグメントが不要であるようなレベルであり、例えばＡＶＣ符号化ビデオまたはその他の符号化コンテンツの安定なプレイアウトを保証するだけの十分なセグメントがまだあることを示している場合には、例えば１ｍｓなどの、一般にバッファの寸法に関係する任意の所定の待機時間を導入する。タイミングパラメータは、さらに、この所定の待機時間に応じて更新される。これは、図５の実施形態では、これらの図面の流れ図から分かるように、次のバッファのチェックサイクルを再度素早く行うために、所定の待機時間をタイミングパラメータの現在値から引くことによって行われる。ただし、その他の待機時間も可能であり、またタイミングパラメータをその他の方法で更新することも可能である。図４ａでは、要求されたビデオがＳＶＣを用いて符号化されている場合には、追加のチェックを実行して、ＳＶＣ規格で追加のレイヤに含めて提供される、さらに高品質のセグメントが必要であるかどうかを確認する。必要ない場合には、この場合も、ＡＶＣ符号化ビデオの場合と同じ待機時間を導入する。

例えばクライアントバッファ占有率のチェックによって次のセグメントが必要であることが判明した場合には、この次のセグメントの品質が決定される。これは、測定した往復時間およびバッファ充填レベルに基づく、ｈｔｔｐアダプティブストリーミングの規格で使用される本発明の方法によって、行うことができる。往復時間は、通常は、暗黙的に考慮され、システムは、帯域幅推定およびバッファ充填を使用して、次のセグメントの品質を計算する。例示的なシステムは、例えば、バッファ中のいくつかのしきい値に基づくことができる。例えば、バッファ中のビデオが５秒未満である場合には、システムは、常に最低品質を要求し、要求を送信することを待たない。バッファ中に５秒から１５秒のビデオがある場合には、バッファは、測定した帯域幅未満の帯域幅に対応する品質を要求するが、その品質は、直前に要求したセグメントの品質と最大でも１品質レベルしか違わない。バッファ中に１５秒から２０秒のビデオがある場合には、クライアントは、測定した帯域幅未満の帯域幅に対応する品質を要求する。

代替アルゴリズムは、クライアントが、利用可能な帯域幅に応じて可能な限り多くのセグメントをダウンロードしようとするアルゴリズムである。この場合には、クライアントは、１つのセグメントがダウンロードした後、次のセグメントは、直前のセグメントをダウンロードした帯域幅に対応する品質レベルでダウンロードするというストラテジを採用することができる。

どちらの例でも、測定した帯域幅と品質との間に直接的な関係がある。例えばこの関係を含む参照テーブルを、要求される品質を更新する実施態様で使用することができる。

次のセグメントは、この更新された品質で要求される。タイミングパラメータも、例えば新たに提案された方法のうちの１つにより、図５に示すように、要求されるセグメントのサイズを測定帯域幅で割った商をこのタイミング変数の現在値に足すことによって、更新される。このサイクルは、最後のセグメントが要求されるまで繰り返される。

図４ｂは、測定したパラメータに基づいてタイミングパラメータを変化させる追加ステップを含む代替方法を示している。その根拠は、ＲＴＴおよびＢＷが時間とともに変化するとき、このことがチャネルが空き状態になる時点にも影響を及ぼすということである。この機能がどのように機能することができるかという一例は、新たなＲＴＴであるＲＴＴ２が測定されたときに、元のＲＴＴと新たなＲＴＴであるＲＴＴ２との差を用いてタイミングパラメータが更新される。帯域幅については、クライアントは、要求されているが、そのバイトが受信されていないセグメントを追跡することができる。この場合には、セグメントのサイズを新たなＢＷで割って、古い帯域幅で割ったセグメントのサイズと比較する。次いで、タイミングパラメータを、これら２つの値の間の時間差を用いて更新する。必要に応じて、タイミングパラメータは、図４ａで更新したのと同様に、すなわち、更新された品質を有する次のセグメントを要求した後で、更新することもできる。

図５は、ＡＶＣ符号化ビデオに使用することができる、図４ａの実施態様のさらに詳細な実施形態を示している。

ＳＶＣと略記されるスケーラブルビデオコーディングで符号化されたビデオの場合の方法の実施形態を、図６に示す。受信バッファが新たなセグメントを必要としているか否かを確認するまでは、ＡＶＣ符号化ビデオの場合と同じステップを用いる。新たなセグメントが必要な場合には、セグメント識別子が大きくなり、ベース品質を決定する第１のベースレイヤはゼロとされる。新たなセグメント番号が必要とされない場合には、例えばさらに高い高解像度のものなど、いくつかのより高品質なレイヤが望ましいかどうかを確認する。これは、例えば、ＢＷおよびＲＴＴの推定値を用いて、いつ次のセグメントが受信されるか、およびその時点でのバッファ充填の値（プレイアウト時間換算）がどんな値であるかを決定することによって、確認される。例えば、この値が、例えば１０秒などの所与のしきい値未満である場合には、クライアントは、アプリケーション自体に応じて、新たな品質のセグメントを要求しないことに決定することができる。次いで、アプリケーションは、このエンハンスメントレイヤをダウンロードするリスクをとらないと決定し、次の時間的セグメントのダウンロードを既に開始することに決定する。このストラテジは、その他の構成要素が決定することもできる。例えば、単純な携帯電話など、解像度に限界がある端末では、アルゴリズムは、画面の解像度より高い解像度をダウンロードしないと決定することができる。リソースの制約がある装置では、高次レイヤをダウンロードすると余計なＣＰＵサイクルが必要になるので、アルゴリズムは、多くの高次レイヤをダウンロードしないと決定することができる。一方、現在のセグメントで実際に何らかのさらに高い解像度または品質が望ましいことが判明した場合には、この方法では、どのレイヤを要求するかを判定する。ここでは、様々なストラテジを採用することができる。第１のストラテジでは、最後の時間的セグメントで要求／ダウンロードされた最後のレイヤに基づく、場合によっては時間的レイヤ、品質レイヤまたは空間的レイヤとなる、次のエンハンスメントレイヤを要求する。各レイヤは、サーバ側ではここのファイルに含むことができる、あるいは、サーバは、要求されたレイヤに対応する１つのファイルを生成する機能を有する。ＳＶＣ ｈｔｔｐアダプティブストリーミングでは、時間的セグメントに利用できる品質レイヤは、個々に独立しているのではなく、互いの上に基づいている。その利点は、この場合、品質レイヤが実際に以前にダウンロードされたレイヤを機能強化する点である。例えば、ＳｉＱ２を表現するためには、ＳｉＱ１が利用可能でなければならない。その利点は、クライアント構成要素が大きなＳｉＱ２をダウンロードすると決定しなくても良く、帯域幅が利用可能である限り、品質を徐々に高めていくことができる点である。ＳＶＣレイヤは、通常、個々のＡＶＣセグメントよりもサイズが小さく、遅延の影響はサイズが小さいほど大きくなるので、この場合には、この技術の有利性がより高くなる。

セグメントの要求および伝送にｈｔｔｐ／ＴＣＰプロトコルを用いるパイプライン化の効果、ならびにその従来技術のｈｔｔｐ／ＴＣＰ実施態様との比較を、図７ａ、図７ｂおよび図７ｃに示す。

従来技術のｈｔｔｐ／ＴＣＰ実施態様は、クライアントでサーバに伝送されるｈｔｔｐ ＧＥＴ要求を用いる。図面に描き過ぎないために、セグメントは、それぞれの通し番号Ｓ１、Ｓ２、Ｓ３でのみ示してあるが、要求を発行するときには、要求される品質も示されることを理解されたい。

これ以前の図面との別の相違点は、これらの実施形態では、セグメントが異なる複数の部分として配信される点である。図７ａから図７ｃに示す実施形態では、各セグメントは、３つの異なる部分を含む。したがって、セグメントＳ１は、Ｓ１Ｐ１、Ｓ１Ｐ２およびＳ１Ｐ３の３つの部分として配信される。同様に、セグメントＳ２は、Ｓ２Ｐ１、Ｓ２Ｐ２およびＳ２Ｐ３で示される３つの部分として配信される。

従来技術の実施形態および新たな実施形態の全てにおいて、「ＧＥＴ Ｓ１」として示されるメッセージである第１のセグメントを求める要求が、クライアントからサーバに伝送される。一定時間後、この要求を受信すると、サーバは、このセグメントの第１の部分Ｓ１Ｐ１を伝送して応答する。クライアントは、この第１の部分が正しく受信されたことを示すＡＣＫ−Ｓ１Ｐ１メッセージをサーバに返送することによって、この部分を受信したことを確認する。第１の部分を伝送した後で、サーバは、引き続き第２の部分Ｓ１Ｐ２を伝送する。クライアントがこの部分を受信したことも、適当な確認メッセージによって確認される。最後の部分、この例ではＳ１Ｐ３をサーバが伝送すると、サーバは、これが要求されたセグメントの最後の部分に関することを示すことを伝送メッセージに含める。図７ａ、図７ｂおよび図７ｃでは、これは、サーバからクライアントに伝送される「Ｓ１Ｐ３−ＯＫ」として示してある。この部分がクライアントに正しく受信されると、クライアントは、「ＡＣＫ−Ｓ１Ｐ３−ＯＫ」で示される最後の確認メッセージによってサーバに応答する。

従来技術の解決策では、クライアントによる確認メッセージ伝送の直後に、「ＧＥＴ Ｓ２」で示される次のセグメントを求めるメッセージが発行される。この新たなＧＥＴ要求が受信されると、このセグメントについて上記手続きが繰り返され、最終的に、最後の部分Ｓ２Ｐ３が正しく受信され、クライアントによって確認される。

図７ａから分かるように、従来技術の解決策では、この図に示すように遅延が存在する。図７ｂおよび図７ｃに示すように、この遅延は、本発明による実施形態では存在しない。図７ｂは、要求が次々に伝送される実施形態を示しており、この場合には、サーバは、これらの要求を順次処理し、要求されたセグメントを要求された順序で遅延なく伝送するいくつかのパイプライン機能を有する。図７ｃは、サーバがこれらのパイプライン機能を有する必要はないが、サーバが直前の要求の最後の部分を伝送するまでに要求がサーバに到着するように、クライアントが適当な時点で要求を生成して伝送するように構成されている実施形態を示す。

どちらの実施形態でも、従来技術の解決策では存在していた遅延がなくなっていることが分かる。

図８は、受信バッファに結合されたデコーダを有するビデオプレーヤを含むクライアントの１実施形態を示す概略図である。受信バッファは、セグメントを受信する物理チャネルとのインタフェースとして作用し、セグメントを受信する個々のプロトコルに従ってパケットから有用なデータを抽出する、ＨＴＴＰ／ＵＤＰ／ＴＣＰ／ＩＰとして示されるデータ抽出／カプセル化モジュールに結合される。よく知られている通り、これらのプロトコルは、ＴＣＰ／ＩＰまたはＵＤＰ上のＨＴＴＰとすることができる。

クライアントは、往復時間が特定のテスト信号をサーバに送信し、それらが返送されるのを受信することによって得られるこれらの実施態様では、バッファおよびデータ抽出モジュールに結合された、ＲＴＴモニタとして示される、往復時間をモニタリングするモニタモジュールさらに含む。クライアントは、バッファおよび要求マネージャに結合され、前述の方法のうちの１つで帯域幅を計算するように構成された、ＢＷモニタとして示されるモジュールをさらに含む。要求マネージャは、ＲＴＴモニタ、帯域幅計算機および受信バッファからの入力に基づいて要求を生成するように構成されている。このようにして生成された要求は、次いで、データ抽出／カプセル化モジュールに供給され、データ抽出／カプセル化モジュールが、選択されたプロトコルの要求に応じて、これらの要求を適当な規格化フォーマットを有する要求パケットにカプセル化する。

言うまでもなく、多くの代替実施形態が可能である。要求マネージャ自体が入来セグメントを受信して、それらから帯域幅およびＲＴＴを計算するように構成されている実施形態も、可能である。さらに、全ての機能が１つのプロセッサによって実行される実施形態も存在する。

具体的な装置に関連して本発明の原理について説明したが、この説明は、例示のみを目的としたものであり、添付の特許請求の範囲に定義される本発明の範囲を限定するものではないことは、明白に理解されたい。

Claims (12)

1. サーバからクライアントにｈｔｔｐアダプティブストリーミングサービスを提供する方法であって、前記クライアントから前記サーバにそれぞれの連続するセグメント（Ｓ１Ｑ１、Ｓ２Ｑ２、Ｓ３Ｑ３）を要求するステップを含み、それぞれの連続するセグメントが、前記クライアントが直前のセグメントを完全に受信する前に次のセグメントを求める次の要求を前記クライアントが前記サーバに伝送するようになされるように、前記クライアントと前記サーバの間のチャネル占有率に関係するタイミングパラメータ（ＰｉｐｅｌｉｎｅＥｍｐｔｙＥｓｔｉｍａｔｅ）及び前記サーバから前記それぞれのセグメントが供給されるクライアント受信バッファの占有率レベルに基づいて前記クライアントによって決定されるそれぞれの時点に、関連する要求される品質（Ｑ１、Ｑ２、Ｑ３）で、前記クライアントによって要求される、方法。
2. 前記タイミングパラメータ（ＰｉｐｅｌｉｎｅＥｍｐｔｙＥｓｔｉｍａｔｅ）が、さらに、通信チャネルの少なくとも１つの測定したパラメータ（ＢＷｎ１、ＢＷｐ１、ＲＴＴ）に基づいて決定される、請求項１に記載の方法。
3. 前記少なくとも１つの測定したパラメータが、往復時間（ＲＴＴ）および／または帯域幅関連パラメータ（ＢＷｎ１、ＢＷｐ１）である、請求項２に記載の方法。
4. 前記帯域幅関連パラメータ（ＢＷｐ１）が、直前に受信したセグメントのサイズを、直前のセグメントの最後のバイトの受信と最初のバイトの受信の時間差で割った値として得られる、請求項３に記載の方法。
5. 前記関連する要求される品質が、さらに、前記クライアント受信バッファの前記占有率レベルに基づいて前記クライアントによって決定される、請求項１から４のいずれか一項に記載の方法。
6. 前記関連する要求される品質が、さらに、前記クライアントと前記サーバの間の通信チャネルの前記少なくとも１つの測定したパラメータ（ＢＷｎ１、ＢＷｐ１、ＲＴＴ）に基づいて前記クライアントによって決定される、請求項１から５のいずれか一項に記載の方法。
7. サーバ構成のｈｔｔｐアダプティブストリーミングサービスを受信するように構成されたクライアントであって、前記サーバにそれぞれ連続するセグメント（Ｓ１Ｑ１、Ｓ２Ｑ２、Ｓ３Ｑ３）をそれぞれの時点で要求するように構成されたクライアントであり、前記クライアントと前記サーバの間のチャネル占有率に関係するタイミングパラメータ（ＰｉｐｅｌｉｎｅＥｍｐｔｙＥｓｔｉｍａｔｅ）を決定するように構成され、かつ前記クライアントが直前のセグメントを完全に受信する前に次のセグメントを求める次の要求を前記クライアントが前記サーバに伝送するようになされるように、前記タイミングパラメータ及び前記サーバから前記それぞれのセグメントを受信して一時的に記憶しておくように構成された前記クライアント内のクライアント受信バッファの占有率レベルに基づいて前記連続するセグメントのそれぞれの要求の時点を決定するようにさらに適応された、クライアント。
8. 通信チャネルの少なくとも１つの測定したパラメータ（ＢＷｎ１、ＢＷｐ１、ＲＴＴ）に基づいて前記タイミングパラメータ（ＰｉｐｅｌｉｎｅＥｍｐｔｙＥｓｔｉｍａｔｅ）を決定するようにさらに適応された、請求項７に記載のクライアント。
9. 前記少なくとも１つの測定したパラメータが、往復時間（ＲＴＴ）および／または帯域幅関連パラメータ（ＢＷｎ１、ＢＷｐ１）である、請求項８に記載のクライアント。
10. 直前に受信したセグメント（Ｓ１Ｑ１）のサイズを測定し、該サイズを直前のセグメント（Ｓ１Ｑ１）の最後のバイトの受信と最初のバイトの受信の時間差（Ｔ６−Ｔ３）で割ることによって、前記帯域幅関連パラメータ（ＢＷｎ１）を決定するようにさらに適応された、請求項８に記載のクライアント。
11. 前記クライアント受信バッファの前記占有率レベルに基づいて前記関連する要求される品質を決定するようにさらに適応された、請求項７から１０のいずれか一項に記載のクライアント。
12. 通信チャネルの前記少なくとも１つの測定したパラメータに基づいて前記関連する要求される品質を決定するようにさらに適応された、請求項７から１１のいずれか一項に記載のクライアント。

Images