クライアント装置で、コンテンツの時間長に対応する複数のチャンクに分割されたコンテンツを受信する適応型のストリーミング方法であって、該チャンクはサーバで少なくとも第1および第2のフォーマットに符号化され、該第2のフォーマットが該第1のフォーマットよりも良好なコンテンツのレンダリング品質に対応し、チャンクがチャンク受信期間に受信され、当該方法は、該クライアント装置において、次のチャンク受信期間に前記クライアントと前記サーバとの間で利用可能な帯域幅を測定するステップと、前記次のチャンク受信期間にチャンクを受信できるように、前記少なくとも第1または第2のフォーマットのうちのいずれか一方に符号化された該チャンクを送信するように前記サーバにリクエストするステップと、前記第1のフォーマットで符号化された前記チャンクが受信されている場合であって、前記次のチャンク受信期間に幾らかの帯域幅が利用可能である場合には、第2のフォーマットで符号化されたチャンクの部分を送信するように前記サーバにリクエストするステップと、を含む、前記方法。前記チャンクを受信するステップと、前記チャンクをレンダリング装置に送信するステップと、を含む、請求項1に記載の方法。前記チャンクをメモリに記憶するステップを含む、請求項1または2に記載の方法。前記利用可能な帯域幅を複数の連続的なチャンク受信期間に使用して前記第2のフォーマットで符号化された前記チャンクの全部分をリクエストするステップを含む、請求項1~3のいずれか1項に記載の方法。第2のフォーマットで符号化されたチャンクの全部分が受信されると、前記メモリにおいて、前記第1のフォーマットで符号化されたチャンクと第2のフォーマットで符号化された前記チャンクとを入れ替えるステップを含む、請求項4に記載の方法。クライアント装置で、コンテンツの時間長に対応する複数のチャンクに分割されたコンテンツを受信する適応型のストリーミング方法であって、前記チャンクはサーバでスケーラブルビデオ符号化SVC技術に従って基本レイヤーと少なくとも1つの拡張レイヤーに符号化され、チャンクがチャンク受信期間に受信され、当該方法は、該クライアント装置で、前記次のチャンク受信期間に前記クライアントと前記サーバとの間で利用可能な帯域幅を測定するステップと、前記次のチャンク受信期間にチャンクを受信できるように、少なくとも1つのSVCレイヤーを用いて符号化された該チャンクを送信するように前記サーバにリクエストするステップと、前記次のチャンク受信期間に幾らかの帯域幅が利用可能である場合には、少なくとも1つの拡張レイヤー無しで前に受信されたチャンクの前記少なくとも1つの拡張レイヤーを送信するように前記サーバにリクエストするステップと、を含む、前記方法。前記チャンクを受信するステップと、前記チャンクをレンダリング装置に送信するステップと、を含む請求項6に記載の方法。前記チャンクをメモリに記憶するステップを含む、請求項6または7に記載の方法。前記チャンクは、HTTPリクエストを通じてリクエストされる、請求項1~8のいずれか1項に記載の方法。コンピュータプログラムプロダクツであって、コンピュータ上で当該コンピュータプログラムプロダクツのプログラムが実行されたときに、請求項1~9に従った方法の各ステップを実行するプログラムコードインストラクションを含むことを特徴とする、前記コンピュータプログラムプロダクツ。図3において、示されたブロックは、純粋に、機能的なものであり、これらは、必ずしも物理的に別個のものに対応するものではない。即ち、これらは、ハードウエアの形態でもよく、ソフトウエアの形態でもよく、1つまたは幾つかの集積回路において実施されていてもよい。本発明の各図面および記載は、本発明の明確な理解のために関連のある各要素を例示するように簡略化されており、分かりやすくする目的で、通常のディジタルマルチメディアコンテンツ配信の方法およびシステムにおいて存在する多くの他の要素を削除していることを理解すべきである。しかしながら、これらの各要素は、本技術分野においてよく知られており、このような各要素についての詳細な説明は、本明細書において提供されていない。本発明の開示内容は、当業者にとって公知なこのような変形および改変の全てに関する。以下、2つの実施形態について説明する。第1の実施形態では、コンテンツは、幾つかのビットレートで符号化され、第2の実施形態では、コンテンツは、スケーラブルビデオ符号化を用いて符号化される。各実施形態に従ったシステムは、図2に表されている。このシステムは、インターネットを介して接続されたクライアント1およびサーバ3を含む。ビデオファイルスプリッタ5は、圧縮されたビデオおよびオーディオを複数のチャンクにする。さらに、クライアントは、プレイヤー4に接続される。サーバ側でチャンクは、クライアントからのリクエストがあると、HTTPプロトコルを使用して、TCP/IP接続を介してストリーミングにより送信される。クライアントは、以下に記載する方法に従って、および、ネットワーク帯域幅の推定、特に、余裕のある帯域幅に基づいて、チャンクをリクエストする。実施形態に従ったクライアントは、図3に例示されている。クライアントは、ネットワークに対する第1のインタフェース14、および通信手段13を含み、この通信手段13は、ネットワーク上に存在するサーバと通信するプロトコルスタックを含む。特に、ネットワークは、インターネットであり、通信手段は、本技術分野において良く知られているTCP/IPスタックである。勿論、クライアントとサーバとの通信を可能にするどのような他のタイプのネットワークおよび/または通信手段でもよい。さらに、クライアントは、コンテンツを復号し、レンダリングするように構成されたビデオプレイヤーに接続するための第2のインタフェース16を含む。勿論、第2のインタフェースは、複数のプレイヤーに接続できるようにするものであってもよい。第2のインタフェースは、1つ以上のプレイヤーに接続できるようにするためのネットワークに対するインタフェースであってもよい。さらに、クライアントは、このクライアントに記憶されたアプリケーションを処理するプロセッサ11を含む。クライアントは、サーバから受信されるチャンクを、チャンクがSVCプレイヤーに送信される前にバッファリングするバッファ12を含む。さらに、クライアントは、サーバから受信されたチャンクが送信されるメモリ17を含む。好ましくは、このメモリ17は、不揮発性メモリである。さらに、クライアントは、クライアントで動作するアプリケーションを記憶するための、図示しない不揮発性メモリを含む。チャンクセレクタ15は、以下に説明するような、チャンク選択を実行するように構成されたアプリケーションである。クライアントは、ゲートウエイ装置において実施することができる。代替的には、クライアントは、埋め込まれたSVCプレイヤーを含む。その場合、セットトップボックスなどの装置がクライアントとなることがある。代替的には、メモリは、クライアント装置に結合された記憶装置に存在することがある。そこで、以下に説明する方法は、記憶装置がクライアントに結合されている場合にのみ実行される。この方法は、結合されている記憶装置を検出すると自動的に実行されるようにすることができる。さらに、この方法は、エンドユーザからのリクエストにより実行されてもよい。クライアント側でチャンクを受信する方法は、以下のように要約することができる。チャンクセレクタは、以下に説明する方法に従ってチャンクを選択する。通信手段は、選択されたチャンクを受信するために、サーバに対してリクエストを送信する。通信手段は、チャンクを受信する。チャンクは、バッファリングされる。チャンクは、ビデオプレイヤーに送信される。実施形態によれば、さらに、各チャンクがメモリ17に送信される。これらの記憶されたチャンクの品質を向上させるために、クライアントは、余っている利用可能な帯域幅を使用して以下に示されたようなより高品質のチャンクをリクエストする。次に、より高品質のチャンクは、メモリ17に記憶される。第1の実施形態に従った方法は、図4に例示されている。チャンクの時間長は、チャンクに関連付けられたビデオの時間長に対応する。クライアントは、チャンクの時間長の期間ごとに特定のビットレートに対応するチャンクをリクエストする。クライアントは、チャンクch1~ch14を受信する。以下の説明において、チャンクの時間長は2秒に設定されているものとする。余裕を持ったアプローチにおいては、クライアントは、特定の時間が経過してはじめて、より高いビットレートのチャンクをリクエストし、スムーズなアップグレードの移行が確実に行われるようにする。クライアントが次のチャンクのために利用可能な帯域幅を推定すると、余裕を持ったアプローチの後、クライアントは、チャンクをリクエストするが、リクエストされるチャンクは、このリクエストを行う期間と同じ期間内にアップグレードの対象となるチャンクの部分をリクエストするために十分な帯域幅が残されるようなビットレートに対応するものである。図4は、図1に例示されたような、低ビットレートから高ビットレートの、4つのレベルのチャンクビットレートを示している。説明を簡略化するために、同一のビットレートに対応するチャンクは、同一のサイズを有するようにしている。即ち、所与のビットレートの全てのチャンクを同じ面積で表す。図4に例示されているように、クライアントは、より多くの情報を同時にダウンロードする機会を提供するビットレートに関連付けられたチャンク番号3をリクエスト済である。クライアントは、利用可能な帯域幅を使用して、1に設定されたインデックスを有するブロックを用いて例示された、当初、低ビットレートのチャンクとして受信されたチャンク1の第1の中間ビットレートのバージョンの部分をリクエストする。チャンク4をリクエストする場合も同じである。このとき、クライアントは、チャンク1の第1の中間ビットレートのバージョンの最後の部分を取得している。さらに、チャンク6、7、8、および9もまた、次第にそれぞれの第1の完全な中間ビットレートのバージョンに置き換えられる。勿論、対応するアップグレードされたチャンクが完全に受信されている場合にのみ、チャンクが置き換えられる。代替的には、クライアントのホスト内にローカルにキャッシュされたビデオの総合品質をアップグレードするために他の方法が使用される。図4に示された例は、平均的な品質の向上を提供する方法に対応し、この方法では、まず、最低のビットレートのチャンクをアップグレードすることに優先度が置かれる。別の方法は、まず、例えば、動きの激しいシーケンスを含むチャンクとして、特定のチャンクをアップグレードすることに優先度が置かれることがある。ここで、緩やかな動きのシーケンスは、品質またはユーザ体験に対して過度の影響を与えることなく、低ビットレートで配信することができる一方で、動きの激しいシーケンスは、安定した品質のために、より高いビットレートを必要とする。第1の実施形態のシステムにおいては、ビデオファイルスプリッタは、複数の異なるフォーマットでH.264/MPEG-4AVC規格に従って符号化され、MP4ファイルフォーマットのコンテナ内部に記憶されるチャンクを生成する。各フォーマットは、300kbps、600kbps、1000kbps、または、2000kbpsのいずれかのビットレートに対応する。ビデオファイルスプリッタは、サポートされたビットレート毎に、MPEGトランスポートストリームの一連のチャンクを生成するためにチャンクを多重化する。これらのチャンクの全ては、HTTPサーバに記憶される。サポートされたビットレート、チャンクの数、さらに、それぞれのチャンクのサイズのリストを含む、マニフェストファイルがクライアントに送信される。ここで、クライアントは、チャンク配信のリクエストを開始することができる。クライアントは、2秒毎に、1つのリクエストを送信する。この2秒は、ビデオチャンクの時間長に対応する。実際には、クライアントは、帯域幅を推定し、推定された帯域幅から余裕を持たせるための備えの分を差し引いた帯域幅に対応するチャンクをリクエストする。従って、HTTPサーバから受信したレスポンスは、チャンクのビットレートに直接リンクされた特定の時間の後に、到着する。レスポンスが受信されると、クライアントは、次のチャンクをリクエストするまでに残っている残存時間timeleftを計算する。次に、クライアントは、アップグレードすることが望まれる、前のチャンクに関連付けられた、リクエストできるバイトの数BytesMaxNumを取得する。残存時間=2秒―チャンクの往復の伝送時間BytesMaxNum=推定された帯域幅/秒残存時間秒次に、クライアントは、アップグレードの対象となるチャンクから特定のバイトの範囲をダウンロードするために、他のHTTPリクエストを送信する。HTTPリクエストのフォーマットは、ファイルの特定のバイトの範囲の要求をサポートする。しかしながら、これには、全てのHTTPリクエスト/レスポンス処理のシリアル化が必要となる。HTTP処理が、推定されている処理よりも長い場合には、これにより、次のチャンクのリクエストが遅延することがあるため、プレイヤーに対して与えられるデータが不足することが危惧される。代替的には、クライアントは、第2のTCP接続をセットアップする。チャンクをアップグレードする処理に関連付けられたHTTPリクエストは、第2のTCP接続を介して送信される。クライアントは、上述したものと同じ処理を行う。クライアントは、帯域幅を推定し、推定された帯域幅から余裕を持たせるための備えの分を差し引いた帯域幅に対応するチャンクをメインとなるTCP接続を介してリクエストする。余裕を持たされた推定値に従って、クライアントは、アップグレードすることが望まれる、前のチャンクに関連付けられたリクエストできるバイト数を計算する。BytesMaxNum=推定された帯域幅-チャンクビットレート2秒クライアントは、第2のTCP接続を介して、メインとなる接続と並列的に、アップグレードの対象となるチャンクの部分に対応するバイトを求める幾つかの連鎖的なリクエストを行うことができる。クライアントは、メインの接続に依存することなく、第2のTCP接続をシャットダウンすることができる。これは、帯域幅が減少した際にスムーズな再生を維持するためにメインの接続に優先度を置くことを望む場合に該当する。本発明の第2の実施形態においては、各チャンクは、H.264/MPEG-4AVC付属文書Gで規定されるスケーラブルビデオ符号化ScalableVideoCodingSVC圧縮技術に従って符号化される。SVCは、3つの細かさのレベル程度のパラメータとして、時間スケーラビリティ、空間スケーラビリティ、さらに、SN比SNRスケーラビリティを規定する。ターゲットの多様性や帯域幅の負荷などの基準に従って、ストリームの符号化は、必ずしも、全ての既存のタイプのスケーラビリティでの符号化を必要としない。これは、スケーラビリティの各タイプについて、レイヤーの数を条件付けるものである。HTTPストリーミングのために、SVCコンテンツは、ファイルとして記憶される。SVCファイルは、MPEG-2トランスポートストリームまたはMP4ファイルでフォーマットされる。これらのフォーマットは、特に、レンダリングのためのタイミング情報を管理できるようにする。MPEG2トランスポートストリームは、通常、追加的なデータ無しにTVチャンネルを放送するために生成される。SVCビデオを用いたTVチャンネルの放送は、規格情報技術-動画およびオーディオの汎用符号化:システム:ITU-T勧告H.222.0|ISO/IEC13818-1でのスケーラブルなビデオのトランスポート、修正32009年3月に規定されている。これは、通常のTVチャンネルC1つのエレメンタリストリームESAVCおよび1つのESオーディオのプログラムマップテーブルPMTを、各拡張レイヤー1について、ESを用いて規定する。MP4ファイルフォーマットのコンテナは、ISO/IECFDIS14496-14:2003Eにおいて、情報技術-オーディオ、ピクチャ、マルチメディアおよびハイパーメディア情報の符号化-パート14:MP4ファイルフォーマットで規定されている。MP4ファイルフォーマットのコンテナは、ISO/IEC14496-15:2004/FDAM2:2008Eにおいて、情報技術-AVオブジェクト-パート15:アドバンスドビデオ符号化ファイルフォーマットAVCfileformat、修正2:スケーラブルビデオ符号化のためのファイルフォーマットサポートで規定されているように、SVCコンテンツに適応している。例えば、SVCファイルフォーマットの説明は、P.Amon氏、T.Rathgen氏、D.Singer氏の文献スケーラブルビデオ符号化のためのファイルフォーマットIEEETransactionsoncircuitsSystemsforvideoTechnology、vol.17、2007年9月に例示されている。第2の実施形態では、SVC符号化されたビデオが複数のチャンクに分割される。チャンクは、1つのSVCサンプルを含むだけでなく、1つの連続したストリームのセグメント、即ち、連続したピクチャを集めたものである。従って、チャンクは、以下、チャンクオフセットと呼ぶ開始時間を有し、さらに、以下、チャンクの時間長と呼ぶ時間長を有する。さらに、チャンクは、GOPgroupofpictures、または、整数の数のGOPに並べられている。通常、チャンクサイズの範囲は、1~10秒の時間長である。これは、各チャンクがキーフレームで開始することを意味する。チャンクのコンテンツもまた、スケーラビリティのような種類の1つのレイヤーのみに対応する。全てのチャンクファイルは、同一のフォーマットを有する。各チャンクは、独自のURIUniformResourceIdentifierを有する。ストレージフォーマットMPEG2-TSやMP4ファイルに関わらず、SVCコンテンツをチャンク毎のファイルに分割してもよいし、サーバ上に現状のまま、記憶してもよい。前者の場合には、クライアントは、URIをリクエストし、後者の場合には、クライアントは、タイムコードおよび時間長、または、バイトオフセットファイルの最初からのオフセットおよびバイト範囲をリクエストする。利用可能なチャンクは、ストリーミングサーバによって生成、提供されたプレイリストに列挙される。このプレイリストは、フォーマットのタイプ毎のものなど、他のプレイリストを参照することもできる。プレイリストには、コーデックまたは必要な帯域幅などのチャンクのコンテンツ、さらに、これらをリクエストする方法を記載する。プレイリストフォーマットは、HTTPLiveStreamingdraft-pantos-http-live-streaming-02に記載されているものとすることができ、様々なSVCレイヤーを記載するためにコーデック情報を用いて拡張される。第2の実施形態のシステムは、第1の実施形態のシステムと同様であるが、第2の実施形態では、コンテンツは、複数の異なる品質のレベルに符号化されるのではなく、SVCレイヤーに符号化される。特に、ビデオファイルスプリッタは、4つの相補的なレイヤー、即ち、1つの基本レイヤーおよび3つの拡張レイヤーを使用して、チャンクを作成する。第1の実施形態においては、より高品質のチャンクがメモリに送信される。第2の実施形態においては、チャンクの全てがメモリに送信される。第2の実施形態に従った方法は、図5に例示されている。クライアントは、インデックスによって識別されない基本レイヤーおよび拡張レイヤーによって表されるチャンクch1~ch14を受信する。回復されたチャンクは、インデックスを用いて表される。ここで、クライアントは、より多くの情報を同時にダウンロードする機会を提供するビットレートに関連付けられたチャンク3をリクエスト済である。クライアントは、利用可能な帯域幅を使用して、基本レイヤーのチャンクとして当初受信された、チャンク1の第1の拡張レイヤーのピースをリクエストしている。チャンク4をリクエストする際も同様である。チャンク1および2の第2の拡張レイヤーがリクエストされる。チャンク5を用いて、クライアントは、チャンク1の第3の拡張レイヤーをリクエストする。チャンク2の第3の拡張レイヤーがリクエストされるチャンク6の場合も同様である。チャンク6の時点では、クライアントは、拡張レイヤー1および2を用いて全体のシーケンスのアップグレードを受けることができ、拡張レイヤー3を用いて幾らかのチャンクがさらに改善される。さらに、やがて、チャンク3、5、6、7、8もまた、アップグレードされる。簡略化のため、基本レイヤーおよび拡張レイヤーのチャンクをそれぞれ同じサイズで表す。第2の実施形態は、拡張レイヤー1が基本レイヤーに依存し、拡張レイヤー2が拡張レイヤー1に依存するなどの、SVCレイヤーの特定の構成を示している。代替的には、全ての拡張レイヤーが基本レイヤーに依存する別のSVCスキームを使用することができる。これは勿論、フレキシビリティが低くなるが、発生する負荷が小さくなる。明細書、請求項、および図面において開示された参照内容は、独立して提供されることも、適切な組み合わせにより提供されることもある。各特徴事項は、適宜、ハードウエア、ソフトウエア、または、ハードウエアおよびソフトウエアを組み合わせた形態で実施される。本明細書において、一実施形態または実施形態と参照している場合、実施形態に係る特定の特徴事項、構造、または特性が本発明の少なくとも一実施態様に含まれることを意味する。明細書の様々な箇所に存在する一実施形態においてはという記載は、必ずしも、全てが同一の実施形態について言及するものではなく、別個の実施形態または代替的な実施形態が他の実施形態に対して相互に排他的であるものではない。各請求項に存在する参照符号は例示的な目的のためのものに過ぎず、請求の範囲に限定的な影響を与えるものではない。