サーバからクライアントにストリーミングサービスを提供する方法であって、前記クライアントから前記サーバに連続するセグメントS1Q1、S2Q2、S3Q3を要求するステップを含み、前記それぞれの連続するセグメントが、前記クライアントが直前のセグメントを完全に受信する前に次のセグメントを求める次の要求を前記クライアントが前記サーバに伝送することができるように、前記クライアントと前記サーバの間のチャネル占有率に関係するタイミングパラメータPipelineEmptyEstimateに基づいて前記クライアントによって決定されるそれぞれの時点に、関連する要求される品質Q1、Q2、Q3で、前記クライアントによって要求される、方法。前記時点が、さらに、前記サーバから前記それぞれのセグメントが供給されるクライアント受信バッファの占有率レベルに基づいて決定される、請求項1に記載の方法。前記タイミングパラメータPipelineEmptyEstimateが、さらに、通信チャネルの少なくとも1つの測定したパラメータBWn1、BWp1、RTTに基づいて決定される、請求項1または2に記載の方法。前記少なくとも1つの測定したパラメータが、往復時間RTTおよび/または帯域幅関連パラメータBWn1、BWp1である、請求項3に記載の方法。前記帯域幅関連パラメータBWp1が、直前に受信したセグメントのサイズを、直前のセグメントの最後のバイトの受信と最初のバイトの受信の時間差で割った値として得られる、請求項4に記載の方法。前記関連する要求される品質が、さらに、前記クライアント受信バッファの前記占有率レベルに基づいて前記クライアントによって決定される、請求項1から5のいずれか一項に記載の方法。前記関連する要求される品質が、さらに、前記クライアントと前記サーバの間の通信チャネルの前記少なくとも1つの測定したパラメータBWn1、BWp1、RTTに基づいて前記クライアントによって決定される、請求項1から6のいずれか一項に記載の方法。サーバ構成のストリーミングサービスを受信するように構成されたクライアントであって、前記サーバに連続するセグメントS1Q1、S2Q2、S3Q3をそれぞれの時点で要求するように構成されたクライアントであり、前記クライアントと前記サーバの間のチャネル占有率に関係するタイミングパラメータPipelineEmptyEstimateを決定するように構成され、かつ前記クライアントが直前のセグメントを完全に受信する前に次のセグメントを求める次の要求を前記クライアントが前記サーバに伝送することができるように、前記タイミングパラメータに基づいて前記連続するセグメントのそれぞれの要求の時点を決定するようにさらに適応された、クライアント。前記サーバから前記それぞれのセグメントを受信して一時的に記憶しておくように構成された前記クライアント内のクライアント受信バッファの占有率レベルに基づいて前記時点を決定するようにさらに適応された、請求項8に記載のクライアント。通信チャネルの少なくとも1つの測定したパラメータBWn1、BWp1、RTTに基づいて前記タイミングパラメータPipelineEmptyEstimateを決定するようにさらに適応された、請求項8または9に記載のクライアント。前記少なくとも1つの測定したパラメータが、往復時間RTTおよび/または帯域幅関連パラメータBWn1、BWp1である、請求項10に記載のクライアント。直前に受信したセグメントS1Q1のサイズを測定し、該サイズを直前のセグメントS1Q1の最後のバイトの受信と最初のバイトの受信の時間差T6-T3で割ることによって、前記帯域幅関連パラメータBWn1を決定するようにさらに適応された、請求項10に記載のクライアント。前記クライアント受信バッファの前記占有率レベルに基づいて前記関連する要求される品質を決定するようにさらに適応された、請求項8から12のいずれか一項に記載のクライアント。通信チャネルの前記少なくとも1つの測定したパラメータに基づいて前記関連する要求される品質を決定するようにさらに適応された、請求項8から13のいずれか一項に記載のクライアント。したがって、本発明の実施形態の目的は、前述の問題を解決する解決策を提供することである。本発明の実施形態によれば、この目的は、サーバからクライアントにストリーミングサービスを提供する方法であって、前記クライアントから前記サーバに連続するセグメントを要求するステップを含み、前記それぞれの連続するセグメントが、前記クライアントが直前のセグメントを完全に受信する前に次のセグメントを求める次の要求を前記クライアントが前記サーバに伝送することができるように、前記クライアントと前記サーバの間のチャネル占有率に関係する前記クライアントによって決定されるタイミングパラメータに基づいて前記クライアントによって決定されるそれぞれの時点に、関連する要求される品質で要求される方法によって達成される。次のセグメントを要求する時点がクライアントとサーバの間のチャネル占有率に関係するタイミングパラメータによって決まるようにすることによって、帯域幅の無駄の少ないより滑らかな配信を実現するパイプライン式手法が得られる。次のセグメントを要求する時点は、さらに、クライアント受信バッファの充填レベルまたは占有レベルによって決まるようにすることもできる。変形実施形態では、これは、決定される品質にも当てはまる。タイミングパラメータは、サーバから提供される情報に基づいて決定することができる。あるいは、タイミングパラメータは、クライアントとサーバの間の通信チャネルの少なくとも1つの測定したパラメータに基づいて決定することもできる。別の実施形態では、要求される品質も、クライアントとサーバの間の通信チャネルのこの少なくとも1つの測定したパラメータに基づいて決定することができる。この少なくとも1つの測定したパラメータは、往復時間および帯域幅関連パラメータとすることができる。帯域幅関連パラメータは、既存の方法によって、受信したセグメントのサイズを、このセグメントの最後のバイトの受信時とこの直前のセグメントを求める要求の発行時の間の時間差で割ることによって得ることができる。あるいは、この帯域幅関連パラメータは、直前に受信したセグメントのサイズを、この直前に受信したセグメントの最初のバイトの受信時と最後のバイトの受信時の間の時間差で割ることによって、計算することもできる。また、本発明は、前述の方法の実施形態を実現するように構成されたクライアントの実施形態にも関する。さらなる変形形態は、添付の特許請求の範囲に記載されている。なお、特許請求の範囲で使用される結合されたという用語は、直接接続された状態のみに限定されるものと解釈すべきではないことに留意されたい。したがって、装置Bに結合された装置Aという表現の範囲は、装置Aの出力が装置Bの入力に直接接続された装置またはシステムに限定されないものとする。この表現は、Aの出力とBの入力の間に、その他の装置または手段を含む経路である可能性もある経路が存在するということを意味している。また、特許請求の範囲で使用される含むという用語は、その後に列挙される手段のみに限定されるものと解釈すべきではないことに留意されたい。したがって、手段AおよびBを含む装置という表現の範囲は、構成要素AおよびBのみからなる装置に限定されないものとする。この表現は、この装置の構成要素のうち、本発明に関わりがある構成要素がAとBだけであるということを意味している。以下の実施形態の説明を添付の図面と関連付けて参照することにより、本発明の上記その他の目的および特徴はさらに明らかになり、本発明自体も最も良く理解されるであろう。本明細書および図面は、単に本発明の原理を例示するものに過ぎない。したがって、本明細書に明示的には記述または図示していなくても、本発明の趣旨および範囲に含まれる本発明の原理を実現する様々な構成を、当業者なら考案することができることを理解されたい。さらに、本明細書に記載する全ての実施例は、本発明の原理と、当技術分野をさらに進歩させるために発明者等が与える概念とを、読者が理解するのを助けるという教育的な目的のみを原則的に意図したものであって、これらの具体的に列挙した実施例および条件に限定されるわけではないものと解釈されたい。さらに、本発明の原理、態様および実施形態ならびに本発明の具体的な実施例について本明細書で述べる全ての記述は、その均等物を含むものとする。当業者なら、本明細書に示す全てのブロック図は、本発明の原理を実施する例示的な回路の概念図を表していることを理解するであろう。同様に、全てのフローチャート、流れ図、状態遷移図、擬似コードなども、コンピュータ可読媒体中に実質的に表現され、明示してある場合もしていない場合もあるコンピュータまたはプロセッサによって実質的に実行される様々な処理を表していることも理解されたい。HTTPアダプティブストリーミングなど、本発明によるアダプティブストリーミング技術は、例えばビデオまたはオーディオをいくつかの品質に符号化して、個々のチャンクにセグメント化する手法を用いている。ビデオセグメントの時間長は、通常は数秒程度である。これらのセグメントは、クライアントが順次すなわち次々に要求することによって、サーバからダウンロードする。これは、クライアントが、1つのセグメントを完全に受信したときにのみ、次のセグメントのHTTPGET要求を発行するということである。その概略を、図1に示す。図1では、時点T1で、通常はHTTPGET要求である第1の要求がクライアントからサーバに送信される。T2で、サーバがこの要求を受信し、この受信時に、サーバは、この第1のセグメントS1Q1の最初のバイトのクライアントへの伝送を開始する。時点T3で、クライアントがこの最初のバイトを受信する。クライアントが第1の要求を送信してからこのセグメントS1Q1の最初のバイトをクライアントが受信するまでの時間差、すなわちT3-T1は、通常は、往復時間と呼ばれ、RTTと略記される。時点T4で、このセグメントS1Q1の最後のバイトを受信すると、直ちに、クライアントは、次のセグメントの次のGET要求を発行する。その後、クライアントは、T4RTT往復時間に等しい時点T5で、この次のセグメントS2Q1を受信する。このようにして得られる使用される帯域幅BWp1は、従来技術によれば、このセグメントの測定/観察したサイズに基づいて決定し、S1Q1のバイト数で表現し、図1の時間差T4-T1で分割することができる。実際には、第1のセグメントのこの決定した値は、一時的に記憶し、例えば指数加重平滑平均技術によって新たなパケットの受信時に更新することができる。図1ではBWp1で表される、この測定した帯域幅に関するパラメータは、従来技術の方法では、次に要求されるセグメントの品質を決定するために使用される。この手法の問題点は、各セグメントごとに、往復時間RTTの時間長を有する期間が無駄になる点である。これが、Httpアダプティブストリーミング技術を使用するときに、サーバとクライアントの間の総帯域幅に影響を及ぼす。特に、一部のモバイル技術で経験するような遅延の大きなネットワークでは、これは、実現できる総帯域幅に明らかな影響を及ぼすことになる。往復時間が長くなることの悪影響は、この場合には、要求/応答の総時間が往復時間の影響を大きく受けるので、小さなセグメント、および帯域幅と遅延の積が大きいネットワークで大きくなる。また、HTTPアダプティブストリーミングなどをスケーラブルビデオコーディングSVCセグメントの配信に使用する場合には、この影響はさらに顕著になる。これは、AVCコード化されたセグメントが、SVCコード化における1つのベースレイヤセグメントおよび1つまたは複数のエンハンスメントレイヤセグメントに相当するからである。したがって、ひとつのセグメントあたり複数のエンハンスメントレイヤが必要になる場合には、ただ1つのセグメントの間に、RTTの時間長の遅延が数回生じる可能性がある。したがって、この遅延を低減するために、要求をパイプライン化する方法が提案されている。つまり、一般に、直前のセグメントSi-1Qi-1の最後のバイトを受信した後でなければ、次のセグメントSiQiを求める要求がクライアントからサーバに伝送されることはないということである。これを、図2に示す。図2では、直前のセグメントS1Q1が要求された時点であるT1からデルタtS2だけ離れたT4で、第2のセグメントを求める要求が発行されている。同様に、図2では、第2のセグメントが要求された時点であるT4からデルタtS2だけ離れたT8で、第3のセグメントを求める要求がクライアントによって発行されている。場合によっては、図2には示していないが、直前のセグメントのバイトを全く受信していないうちに、次の要求がクライアントから伝送されることもある。このように、各セグメントを求める要求の伝送は、直前のセグメントを受信したか否かに関わらずに行うことができる。これらの要求を行う時点の決定は、前記クライアントによる、タイミングパラメータの決定に基づいて行われる。このタイミングパラメータは、クライアントとサーバの間のチャネルの占有率に関係する。このタイミングパラメータを決定する方法については、本明細書の後半部分で説明する。直前のセグメントを完全に受信する前に次のセグメントを要求することにより、改善されたセグメントに基づく配信が実現し、これは、遅延の大きな環境では特に有用である。したがって、クライアントは、連続する次のセグメントを求める次の要求を発行する時点を、このタイミングパラメータに基づいて計算するように構成され、また、前記クライアントと前記サーバの間の通信チャネルの往復時間および/または帯域幅関係パラメータなど、少なくとも1つの測定したパラメータに基づいてこれらの要求されるセグメントの品質を決定するように構成されることもある。したがって、各要求を行う時点は、クライアントとサーバの間のチャネル占有率を表す、それ自体もクライアントによって決定されるこのタイミングパラメータに基づいて、クライアントによって決定される。したがって、次のセグメントを求める次の要求は、クライアントが直前のセグメントを完全に受信する前に、クライアントからサーバに伝送することができる。必要に応じて、さらに、これらの時点は、前記それぞれのセグメントが前記サーバから供給されるクライアント受信バッファの占有率レベルに基づいて決定することができる。例えばクライアントバッファ中の受信セグメントが十分である場合には、その結果、連続する要求の間の遅延が大きくなることがあり、その結果、直前のセグメントを完全に受信した後に、まだ要求が発行される可能性がある。好ましい実施形態では、タイミングパラメータは、通信チャネルの少なくとも1つの測定したパラメータに基づいて決定される。ただし、これが必要とされないその他の実施形態もある。例えば、クライアントとサーバの間のクロックが同期しているシステムでは、クライアントは、サーバパイプラインが空き状態になるときに関する情報を直接受信して、これに基づいて要求を送信する時点を決定することもできる。この手順では、クライアントとサーバの間で余計な通信メッセージが必要になり、そのメッセージの間に、クライアントは、最初にこの情報についてサーバにポーリングを行い、これに対して、サーバは、例えば要求されたセグメントの配信の予想残り時間などを示すメッセージで応答する。前述のように、この通信チャネルの少なくとも1つの測定したパラメータは、往復時間および/または帯域幅関連パラメータとすることができる。実施形態によっては、タイミングパラメータの計算に使用されるこの帯域幅関連パラメータは、従来技術の状況で使用される方法とは異なる方法で得ることができる。この帯域幅関連パラメータを計算する1つの方法は、一般にバイトで表される直前に受信したセグメントのサイズを、この直前に受信したセグメントの最後のバイトと最初のバイトの間の受信時間の差で割ることを含むことがある。この時間差は、図2aに示すT6-T3である。この帯域幅関連パラメータは、図2aではBWn1で示してある。したがって、これは、図1に示し、これを参照して説明した帯域幅BWn1を決定する従来の方法とは異なる。実施形態によっては、関連する要求される品質も、この少なくとも1つの測定したチャネルパラメータに基づいて、かつ/または前記クライアント受信バッファの占有率レベルに基づいて決定することができるが、両変形形態ともに任意選択のものである。この帯域幅関連パラメータを決定するために、クライアントは、入来セグメントのタイミングおよびサイズをモニタリングし、それらから前述の方法またはさらに別の方法で帯域幅関連パラメータを計算する、モニタモジュールを含む。図8では、このモジュールをBWモニタとして示してある。往復時間を測定するために、特定のモジュールを含むことができる。このモジュールは、サーバに対してテスト信号を生成するように構成されており、このテスト信号は、サーバに受信されると、直ちにクライアントに返送される。これらの技術は、当業者には知られているので、ここではこれ以上詳述する必要はない。図8では、このモジュールは、RTTモニタとして示してある。ただし、異なるモジュール間にこれほど明確な線引きがなく、例えば中央クライアントプロセッサが上記の全てのステップを実行するように構成されているような、その他のクライアントの実施態様も可能である。サーバ自体は、従来のサーバであってもよい。すなわち、サーバが要求のパイプライン化、すなわちRFC2616のHTTP1.1に記載されている技術に対応していてもよい。本発明の方法の実施形態による前述のパイプライン化技術を使用すると、次のセグメントを求める要求を、既にサーバに伝送されているそれより古いいくつかの要求をサーバが取り扱う、または処理する前に、クライアントからサーバに伝送することができる。帯域幅関連パラメータが図2aに示すようなものである、これらの方法の実施形態では、往復時間は、それ以上の影響を及ぼさない。要求をパイプライン化することの影響と、それに関連する利点を、図2aおよび図2bならびに図3に示す。これらの図面は、自明な図面であり、両図面ともに、次の要求を生成する時点が、各要求セグメントSiQiについてデルタtiで表される計算した遅延分だけ、直前のセグメントSi-1Qi-1の最初のバイトの受信時から遅れていることを示している。ただし、その他の実施形態では、それぞれの時点のみをそのように計算する。サーバは、図2aおよび図2bに示すように、セグメントを次々にキューイングし、FIFOの原理に従って最初に受信した要求が最初に処理されるように要求待ち行列を処理することにより、セグメントを次々に処理するようになっている。図3は、例えば第1のセグメントを求める要求がサーバ内で受信されたときに、このセグメントの最初のバイトが順次、したがって直前のセグメントの最後のバイトがクライアントに伝送された後で直ちに、サーバからクライアントに送信されることを示している。第1のセグメントは、この第1のセグメントが求める要求を時点S_1で受信されるとほとんど直ちに、サーバから伝送される。しかし、次のセグメントは、それらの要求の受信時に、クライアントとサーバの間のチャネルが再度空き状態になるとすぐに、サーバから送信される。この概略を、図2aおよび図3に示す。この図では、クライアントおよびサーバが、連続するセグメントをパイプライン式に受信し、応答を伝送する。したがって、セグメントS2Q2は、サーバが時点S_2などでこのセグメントを求める要求を受信してから少し時間が経過した時点S_4から伝送される。図3に示す実施形態では、これは、RFC2616のhttp1.1に記載されている技術である、サーバのいくつかのパイプライン化機能を必要とする。これにより、サーバは、最適なパイプライン方式で、したがって次々に、要求されたセグメントのバイトをこのチャネルを介して順次伝送するように構成される。TCP/IPプロトコルをこの機構と併用すると、クライアントまでのチャネルの帯域幅および輻輳が起きる可能性を確認するということになる。ただし、実施形態によっては、要求を生成して伝送する時点をクライアントが慎重に計算し、この要求をサーバが直ちに処理して要求されたセグメントをチャネルを介して直ちに伝送することによって、この機能がサーバになくても、パイプライン式手法を実現することが可能である。これを、図2bに示す。図2bでは、直前のセグメントの最後のバイトがクライアントに向かって送信されたときに要求がサーバに到着するようにこれらの要求を慎重に伝送することにより、サーバがパイプライン化機能を有していなくても、パイプライン式手法を実現する。このように、サーバによる配信が次々に滑らかに行われるようにクライアントが要求を生成して伝送する時点を慎重に計算することにより、チャネルを非常に効率的に使用することができる。関連する決定した品質を有する符号化されたビデオセグメントを要求するこれらの時点を計算する方法を、図4aに示す。この実施形態は、初期決定品質Q1を有する第1のセグメントS1Q1を求める要求を送信することで開始される。初期決定品質Q1は、初期デフォルト品質Q1とすることができ、ユーザによって入力されたときにメモリに記憶される、またはデフォルトパラメータである。あるいは、この品質は、一般に帯域幅の可用性に関する情報に基づいて、以前のセッションで利用可能であった帯域幅に基づいて、またはその他の種類の測定値に基づいて、決定することができる。一般に、この初期品質については、クライアントのモニタモジュールは、以前の測定値を考慮することができないので、最低品質のセグメントがいくつか要求される可能性がある。図4aでは、第1のセグメントを求める要求を伝送した後で、クライアントとサーバの間のチャネル占有率に関係する時間パラメータの初期値を決定する。このタイミングパラメータは、図5および図6ではPipelineEmptyEstimateとして示してあり、その初期値は、第1の要求セグメントS1Q1の要求または推定サイズを初期帯域幅関連パラメータBW1で割った商に往復時間RTT1の初期推定値を加えた値として計算される。ただし、その他の実施形態では、このタイミングパラメータは、例えば実際のサイズの情報がPipelineEmptyEstimateの計算に利用できない場合には、実際のサイズの代わりに平均セグメントサイズを使用するなど、異なる方法で計算することもできる。サーバがその機能に対応していれば、パイプライン中に何があるかを推定した情報およびパイプラインがいつ空き状態になるかを推定した情報をサーバからクライアントに通信することができる別の変形形態も、クライアントサーバ通信によって実現することもできる。このような変形形態では、タイミングパラメータは、サーバからクライアントに通信するだけでよい。図4aの次のステップでは、タイミングパラメータの値と往復時間RTTの実際の測定値の差を、所定のしきい値と比較する。このしきい値は、通常は、数ミリ秒または数十ミリ秒程度である。このしきい値によって、次のセグメントがどれくらい速く要求されるかが決まる。この差が所定のしきい値より小さい場合には、チャネルが空き状態であることを示している可能性があり、クライアントのセグメント受信バッファがチェックされる。さらに詳細には、このバッファが例えば空である、または例えば50など所定の充填レベル未満である場合には、これは、新たなセグメントが要求されることを示す。逆に、このバッファの充填レベルがまだ50を超えている場合には、新たなセグメントは必要とされない。その他のクライアント受信バッファでは、この充填レベルは、最大値の百分率では表されず、ビデオの秒数で表される。この場合には、このバッファの充填レベルに鑑みて、新たなセグメントが必要とされるか否かを判定するために、例えば20秒というしきい値を使用することができる。ただし、これは全てバッファのサイズに関係するので、クライアントによって変わる可能性がある。バッファの充填レベルが新たなセグメントが不要であるようなレベルであり、例えばAVC符号化ビデオまたはその他の符号化コンテンツの安定なプレイアウトを保証するだけの十分なセグメントがまだあることを示している場合には、例えば1msなどの、一般にバッファの寸法に関係する任意の所定の待機時間を導入する。タイミングパラメータは、さらに、この所定の待機時間に応じて更新される。これは、図5の実施形態では、これらの図面の流れ図から分かるように、次のバッファのチェックサイクルを再度素早く行うために、所定の待機時間をタイミングパラメータの現在値から引くことによって行われる。ただし、その他の待機時間も可能であり、またタイミングパラメータをその他の方法で更新することも可能である。図4aでは、要求されたビデオがSVCを用いて符号化されている場合には、追加のチェックを実行して、SVC規格で追加のレイヤに含めて提供される、さらに高品質のセグメントが必要であるかどうかを確認する。必要ない場合には、この場合も、AVC符号化ビデオの場合と同じ待機時間を導入する。例えばクライアントバッファ占有率のチェックによって次のセグメントが必要であることが判明した場合には、この次のセグメントの品質が決定される。これは、測定した往復時間およびバッファ充填レベルに基づく、httpアダプティブストリーミングの規格で使用される本発明の方法によって、行うことができる。往復時間は、通常は、暗黙的に考慮され、システムは、帯域幅推定およびバッファ充填を使用して、次のセグメントの品質を計算する。例示的なシステムは、例えば、バッファ中のいくつかのしきい値に基づくことができる。例えば、バッファ中のビデオが5秒未満である場合には、システムは、常に最低品質を要求し、要求を送信することを待たない。バッファ中に5秒から15秒のビデオがある場合には、バッファは、測定した帯域幅未満の帯域幅に対応する品質を要求するが、その品質は、直前に要求したセグメントの品質と最大でも1品質レベルしか違わない。バッファ中に15秒から20秒のビデオがある場合には、クライアントは、測定した帯域幅未満の帯域幅に対応する品質を要求する。代替アルゴリズムは、クライアントが、利用可能な帯域幅に応じて可能な限り多くのセグメントをダウンロードしようとするアルゴリズムである。この場合には、クライアントは、1つのセグメントがダウンロードした後、次のセグメントは、直前のセグメントをダウンロードした帯域幅に対応する品質レベルでダウンロードするというストラテジを採用することができる。どちらの例でも、測定した帯域幅と品質との間に直接的な関係がある。例えばこの関係を含む参照テーブルを、要求される品質を更新する実施態様で使用することができる。次のセグメントは、この更新された品質で要求される。タイミングパラメータも、例えば新たに提案された方法のうちの1つにより、図5に示すように、要求されるセグメントのサイズを測定帯域幅で割った商をこのタイミング変数の現在値に足すことによって、更新される。このサイクルは、最後のセグメントが要求されるまで繰り返される。図4bは、測定したパラメータに基づいてタイミングパラメータを変化させる追加ステップを含む代替方法を示している。その根拠は、RTTおよびBWが時間とともに変化するとき、このことがチャネルが空き状態になる時点にも影響を及ぼすということである。この機能がどのように機能することができるかという一例は、新たなRTTであるRTT2が測定されたときに、元のRTTと新たなRTTであるRTT2との差を用いてタイミングパラメータが更新される。帯域幅については、クライアントは、要求されているが、そのバイトが受信されていないセグメントを追跡することができる。この場合には、セグメントのサイズを新たなBWで割って、古い帯域幅で割ったセグメントのサイズと比較する。次いで、タイミングパラメータを、これら2つの値の間の時間差を用いて更新する。必要に応じて、タイミングパラメータは、図4aで更新したのと同様に、すなわち、更新された品質を有する次のセグメントを要求した後で、更新することもできる。図5は、AVC符号化ビデオに使用することができる、図4aの実施態様のさらに詳細な実施形態を示している。SVCと略記されるスケーラブルビデオコーディングで符号化されたビデオの場合の方法の実施形態を、図6に示す。受信バッファが新たなセグメントを必要としているか否かを確認するまでは、AVC符号化ビデオの場合と同じステップを用いる。新たなセグメントが必要な場合には、セグメント識別子が大きくなり、ベース品質を決定する第1のベースレイヤはゼロとされる。新たなセグメント番号が必要とされない場合には、例えばさらに高い高解像度のものなど、いくつかのより高品質なレイヤが望ましいかどうかを確認する。これは、例えば、BWおよびRTTの推定値を用いて、いつ次のセグメントが受信されるか、およびその時点でのバッファ充填の値プレイアウト時間換算がどんな値であるかを決定することによって、確認される。例えば、この値が、例えば10秒などの所与のしきい値未満である場合には、クライアントは、アプリケーション自体に応じて、新たな品質のセグメントを要求しないことに決定することができる。次いで、アプリケーションは、このエンハンスメントレイヤをダウンロードするリスクをとらないと決定し、次の時間的セグメントのダウンロードを既に開始することに決定する。このストラテジは、その他の構成要素が決定することもできる。例えば、単純な携帯電話など、解像度に限界がある端末では、アルゴリズムは、画面の解像度より高い解像度をダウンロードしないと決定することができる。リソースの制約がある装置では、高次レイヤをダウンロードすると余計なCPUサイクルが必要になるので、アルゴリズムは、多くの高次レイヤをダウンロードしないと決定することができる。一方、現在のセグメントで実際に何らかのさらに高い解像度または品質が望ましいことが判明した場合には、この方法では、どのレイヤを要求するかを判定する。ここでは、様々なストラテジを採用することができる。第1のストラテジでは、最後の時間的セグメントで要求/ダウンロードされた最後のレイヤに基づく、場合によっては時間的レイヤ、品質レイヤまたは空間的レイヤとなる、次のエンハンスメントレイヤを要求する。各レイヤは、サーバ側ではここのファイルに含むことができる、あるいは、サーバは、要求されたレイヤに対応する1つのファイルを生成する機能を有する。SVChttpアダプティブストリーミングでは、時間的セグメントに利用できる品質レイヤは、個々に独立しているのではなく、互いの上に基づいている。その利点は、この場合、品質レイヤが実際に以前にダウンロードされたレイヤを機能強化する点である。例えば、SiQ2を表現するためには、SiQ1が利用可能でなければならない。その利点は、クライアント構成要素が大きなSiQ2をダウンロードすると決定しなくても良く、帯域幅が利用可能である限り、品質を徐々に高めていくことができる点である。SVCレイヤは、通常、個々のAVCセグメントよりもサイズが小さく、遅延の影響はサイズが小さいほど大きくなるので、この場合には、この技術の有利性がより高くなる。セグメントの要求および伝送にhttp/TCPプロトコルを用いるパイプライン化の効果、ならびにその従来技術のhttp/TCP実施態様との比較を、図7a、図7bおよび図7cに示す。従来技術のhttp/TCP実施態様は、クライアントでサーバに伝送されるhttpGET要求を用いる。図面に描き過ぎないために、セグメントは、それぞれの通し番号S1、S2、S3でのみ示してあるが、要求を発行するときには、要求される品質も示されることを理解されたい。これ以前の図面との別の相違点は、これらの実施形態では、セグメントが異なる複数の部分として配信される点である。図7aから図7cに示す実施形態では、各セグメントは、3つの異なる部分を含む。したがって、セグメントS1は、S1P1、S1P2およびS1P3の3つの部分として配信される。同様に、セグメントS2は、S2P1、S2P2およびS2P3で示される3つの部分として配信される。従来技術の実施形態および新たな実施形態の全てにおいて、GETS1として示されるメッセージである第1のセグメントを求める要求が、クライアントからサーバに伝送される。一定時間後、この要求を受信すると、サーバは、このセグメントの第1の部分S1P1を伝送して応答する。クライアントは、この第1の部分が正しく受信されたことを示すACK-S1P1メッセージをサーバに返送することによって、この部分を受信したことを確認する。第1の部分を伝送した後で、サーバは、引き続き第2の部分S1P2を伝送する。クライアントがこの部分を受信したことも、適当な確認メッセージによって確認される。最後の部分、この例ではS1P3をサーバが伝送すると、サーバは、これが要求されたセグメントの最後の部分に関することを示すことを伝送メッセージに含める。図7a、図7bおよび図7cでは、これは、サーバからクライアントに伝送されるS1P3-OKとして示してある。この部分がクライアントに正しく受信されると、クライアントは、ACK-S1P3-OKで示される最後の確認メッセージによってサーバに応答する。従来技術の解決策では、クライアントによる確認メッセージ伝送の直後に、GETS2で示される次のセグメントを求めるメッセージが発行される。この新たなGET要求が受信されると、このセグメントについて上記手続きが繰り返され、最終的に、最後の部分S2P3が正しく受信され、クライアントによって確認される。図7aから分かるように、従来技術の解決策では、この図に示すように遅延が存在する。図7bおよび図7cに示すように、この遅延は、本発明による実施形態では存在しない。図7bは、要求が次々に伝送される実施形態を示しており、この場合には、サーバは、これらの要求を順次処理し、要求されたセグメントを要求された順序で遅延なく伝送するいくつかのパイプライン機能を有する。図7cは、サーバがこれらのパイプライン機能を有する必要はないが、サーバが直前の要求の最後の部分を伝送するまでに要求がサーバに到着するように、クライアントが適当な時点で要求を生成して伝送するように構成されている実施形態を示す。どちらの実施形態でも、従来技術の解決策では存在していた遅延がなくなっていることが分かる。図8は、受信バッファに結合されたデコーダを有するビデオプレーヤを含むクライアントの1実施形態を示す概略図である。受信バッファは、セグメントを受信する物理チャネルとのインタフェースとして作用し、セグメントを受信する個々のプロトコルに従ってパケットから有用なデータを抽出する、HTTP/UDP/TCP/IPとして示されるデータ抽出/カプセル化モジュールに結合される。よく知られている通り、これらのプロトコルは、TCP/IPまたはUDP上のHTTPとすることができる。クライアントは、往復時間が特定のテスト信号をサーバに送信し、それらが返送されるのを受信することによって得られるこれらの実施態様では、バッファおよびデータ抽出モジュールに結合された、RTTモニタとして示される、往復時間をモニタリングするモニタモジュールさらに含む。クライアントは、バッファおよび要求マネージャに結合され、前述の方法のうちの1つで帯域幅を計算するように構成された、BWモニタとして示されるモジュールをさらに含む。要求マネージャは、RTTモニタ、帯域幅計算機および受信バッファからの入力に基づいて要求を生成するように構成されている。このようにして生成された要求は、次いで、データ抽出/カプセル化モジュールに供給され、データ抽出/カプセル化モジュールが、選択されたプロトコルの要求に応じて、これらの要求を適当な規格化フォーマットを有する要求パケットにカプセル化する。言うまでもなく、多くの代替実施形態が可能である。要求マネージャ自体が入来セグメントを受信して、それらから帯域幅およびRTTを計算するように構成されている実施形態も、可能である。さらに、全ての機能が1つのプロセッサによって実行される実施形態も存在する。具体的な装置に関連して本発明の原理について説明したが、この説明は、例示のみを目的としたものであり、添付の特許請求の範囲に定義される本発明の範囲を限定するものではないことは、明白に理解されたい。