"同じ数のセグメントに分割され、かつ、2つのマルチキャストストリームで送信される2D部分およびメタデータ部分を含む3Dコンテンツを配信するための方法であって、前記2D部分の開始セグメントおよび前記メタデータ部分の開始セグメントに対応する開始時点を有する前記3Dコンテンツの要求を受け取るステップと、前記2D部分の前記開始セグメントを含む前記2D部分の少なくとも1つのセグメントの第1のマルチキャストストリームでの送信、および前記メタデータ部分の前記開始セグメントを含む前記メタデータ部分の少なくとも1つのセグメントの第2のマルチキャストストリームでの送信をスケジューリングするステップであって、前記2D部分の前記開始セグメントの送信および前記メタデータ部分の前記開始セグメントの送信が同期化される、スケジューリングするステップと、を含む、前記方法。前記2D部分の前記少なくとも1つのセグメントの送信、および前記メタデータ部分の前記少なくとも1つのセグメントの送信をスケジューリングする前記ステップは、前記2D部分の前記少なくとも1つのセグメントを送信するための少なくとも1つの時点を示す、前記2D部分のための仮スケジュール、および前記メタデータ部分の前記少なくとも1つのセグメントを送信するための少なくとも1つの時点を示す、前記メタデータ部分のための仮スケジュールを決定するステップと、前記2D部分のための前記仮スケジュールおよび前記メタデータ部分のための前記仮スケジュールに基づいて、前記2D部分のための確定スケジュールおよび前記メタデータ部分のための確定スケジュールを決定するステップと、を含む、請求項1に記載の方法。確定スケジュールを決定する前記ステップは、前記2D部分のための前記仮スケジュールによる、前記2D部分の前記開始セグメントを送信するための時点と、前記メタデータ部分のための前記仮スケジュールによる、前記メタデータ部分の前記開始セグメントを送信するための時点とのうちの遅い方を、前記2D部分の前記開始セグメントおよび前記メタデータ部分の開始セグメントを、前記2D部分のための前記確定スケジュールおよび前記メタデータ部分のための前記確定スケジュールで送信するための時点として選択するステップを含む、請求項2に記載の方法。前記要求された3Dコンテンツの前記開始時点は、前記3Dコンテンツの初期時間であり、前記2D部分の前記開始セグメントおよび前記メタデータ部分の前記開始セグメントは、前記2D部分の最初のセグメントおよび前記メタデータ部分の最初のセグメントである、請求項1から3のいずれか一項に記載の方法。前記2D部分または前記メタデータ部分の前記少なくとも1つのセグメントのうちの1つは、前記2D部分の前記開始セグメントおよび前記メタデータ部分の前記開始セグメントを送信した後、それが、同じセグメントのためのより早い要求に応答して前記マルチキャストストリームに存在している場合は送信されない、請求項1から4のいずれか一項に記載の方法。前記セグメントが送信されない場合、前記セグメントをいつ、どのマルチキャストストリームで得ることができるかに関する情報を送るステップをさらに含む、請求項5に記載の方法。開始時点からの要求に応じて3Dコンテンツを配信するためのデバイスであって、前記3Dコンテンツは、同じ数のセグメントに分割される2D部分およびメタデータ部分を含むデバイスにおいて、前記3Dコンテンツの前記開始時点に対応する前記2D部分の開始セグメントを含む前記2D部分の少なくとも1つのセグメントの第1のマルチキャストストリームでの送信をスケジューリングするための2Dスケジューリングモジュール102と、前記3Dコンテンツの前記開始時点に対応する前記メタデータ部分の開始セグメントを含む前記メタデータ部分の少なくとも1つのセグメントの第2のマルチキャストストリームでの送信をスケジューリングするためのメタデータスケジューリングモジュール103であって、前記2Dスケジューリングモジュール102および前記メタデータスケジューリングモジュール103は、前記2D部分の前記開始セグメントの送信および前記メタデータ部分の前記開始セグメントの送信を同期させる、メタデータスケジューリングモジュール103と、を備える、前記デバイス。前記2Dスケジューリングモジュール102は、前記2D部分の前記少なくとも1つのセグメントを送信するための少なくとも1つの時点を示す、前記2D部分のための仮スケジュールを決定するために使用され、前記メタデータスケジューリングモジュール103は、前記メタデータ部分の前記少なくとも1つのセグメントを送信するための少なくとも1つの時点を示す、前記メタデータ部分のための仮スケジュールを決定するために使用され、前記2Dスケジューリングモジュール102および前記メタデータスケジューリングモジュール103は、前記2D部分のための前記仮スケジュールおよび前記メタデータ部分のための前記仮スケジュールに基づいて、前記2D部分のための確定スケジュールおよび前記メタデータ部分のための確定スケジュールを決定するために個々に使用される、請求項7に記載のデバイス。確定スケジュールの決定は、前記2D部分のための前記仮スケジュールによる、前記2D部分の前記開始セグメントを送信するための時点と、前記メタデータ部分のための前記仮スケジュールによる、前記メタデータ部分の前記開始セグメントを送信するための時点とのうちの遅い方を、前記2D部分の前記開始セグメントおよび前記メタデータ部分の開始セグメントを、前記2D部分のための前記確定スケジュールおよび前記メタデータ部分のための前記確定スケジュールで送信するための時点として選択することを含む、請求項8に記載のデバイス。2Dクライアントおよび3Dクライアントから要求を受け取り、かつ、受け取った前記要求に応じて前記要求を前記2Dスケジューリングモジュール102および前記メタデータスケジューリングモジュール103に転送するための要求フォーキングモジュール104をさらに備える、請求項7に記載のデバイス。前記2D部分または前記メタデータ部分の前記少なくとも1つのセグメントのうちの1つが送信されない場合、前記セグメントをいつ得ることができるか、また、同じセグメントのためのより早い要求に応答するどのマルチキャストストリームで得ることができるかについて知らせるための通知モジュールをさらに備える、請求項7に記載のデバイス。本発明の態様によると、同じ数のセグメントに分割され、かつ、2つのマルチキャストストリームで送信される2D部分およびメタデータ部分を含む3Dコンテンツを配信するための方法が提供され、前記方法は、2D部分の開始セグメントおよびメタデータ部分の開始セグメントに対応する開始時点を有する3Dコンテンツの要求を受け取るステップと、2D部分の開始セグメントを含む前記2D部分の少なくとも1つのセグメントの第1のマルチキャストストリームでの送信、およびメタデータ部分の開始セグメントを含む前記メタデータ部分の少なくとも1つのセグメントの第2のマルチキャストストリームでの送信をスケジューリングするステップとを含み、2D部分の開始セグメントの送信およびメタデータ部分の開始セグメントの送信が同期化される。本発明の他の態様によると、開始時点からの要求に応じて3Dコンテンツを配信するためのデバイスが提供され、3Dコンテンツは、同じ数のセグメントに分割される2D部分およびメタデータ部分を含み、デバイスは、3Dコンテンツの開始時点に対応する2D部分の開始セグメントを含む前記2D部分の少なくとも1つのセグメントの第1のマルチキャストストリームでの送信をスケジューリングするための2Dスケジューリングモジュール102と、3Dコンテンツの開始時点に対応するメタデータ部分の開始セグメントを含む前記メタデータ部分の少なくとも1つのセグメントの第2のマルチキャストストリームでの送信をスケジューリングするためのメタデータスケジューリングモジュール103とを備えており、2Dスケジューリングモジュール102およびメタデータスケジューリングモジュール103は、2D部分の開始セグメントの送信およびメタデータ部分の開始セグメントの送信を同期させる。本発明の他の態様および利点は、添付の図面を参照して行う、本発明についての以下の詳細な説明の中で見出されよう。以下の説明は、本発明の範囲を制限するものではない実施形態に関していることを理解されたい。以下、本発明の実施形態について、図面に関連して詳細に説明する。以下の説明では、知られている機能および構成についてのいくつかの詳細な説明は、分かり易く、かつ、簡潔にするために省略されている。本発明の目的は、3DVoDシステムにおける3Dビデオを効率的に送信することであり、3Dビデオの2D部分およびメタデータ部分は、2つの独立したチャネルまたはデータストリームを介して送信される。図1は、本発明の実施形態による、2Dクライアントおよび3Dクライアントにコンテンツを配信するためのシステムを示す図である。図において、破線は、2Dまたは3Dビデオの要求などの信号の流れを表しており、また、実線は、2D部分およびメタデータ部分のデータなどのデータの流れを表している。システムは、VoDシステムにおける2Dビデオおよび3Dビデオの送信をスケジューリングするためのVoDサーバー101、および2Dクライアントおよび3Dクライアントを表す複数のデバイスを備えている。VoDサーバー101は、2Dスケジューリングモジュール102、メタデータスケジューリングモジュール103および要求フォーキングモジュール104を備えている。それらの機能は以下の通りである。-要求フォーキングモジュール104は、2Dクライアントおよび3Dクライアントから要求を受け取り、かつ、受け取った要求をそれに応じて2Dスケジューリングモジュール102およびメタデータスケジューリングモジュール103に転送するために使用される。つまり、2Dクライアントまたは3Dクライアントが2Dビデオの要求を発すると、その要求は、要求フォーキングモジュール104によって2Dスケジューリングモジュール102に転送され、また、3Dクライアントが3Dビデオの要求を発すると、その要求は、要求フォーキングモジュール104によって2Dスケジューリングモジュール102およびメタデータスケジューリングモジュール103の両方に転送される。-2Dスケジューリングモジュール102は、クライアントから2Dビデオまたは3Dビデオの要求を受け取ると、2D部分をクライアントに配信するための仮スケジュールおよび確定スケジュールを決定するために使用される。-メタデータスケジューリングモジュール103は、クライアントから3Dビデオの要求を受け取ると、メタデータ部分をクライアントに配信するための仮スケジュールおよび確定スケジュールを決定するために使用される。本明細書においては、2Dビデオの要求を受け取ると、2Dスケジューリングモジュール102のみが動作して、対応する3Dビデオの2D部分を配信するための仮スケジュールを決定する。また、この仮スケジュールは、サーバーによって、2D部分の配信をスケジュールするための確定スケジュールとして使用される。3Dビデオの要求を受け取ると、2Dスケジューリングモジュール102およびメタデータスケジューリングモジュール103は、それぞれ独立して動作して、2D部分およびメタデータ部分のための2つの仮スケジュールを決定し、また、共同して動作して、2つの仮スケジュールに基づいて2D部分およびメタデータ部分のための2つの確定スケジュールを決定し以下で詳細に説明する、また、サーバーは、これらの2つの確定スケジュールを使用して、2D部分およびメタデータ部分の送信をスケジューリングする。図2は、本発明の実施形態によるスケジューリングプロセスの例を示す図である。目的は、1要求を受け取ってからコンテンツの配信を開始するまでの間のスタートアップ遅延を最短にすること、および2同じコンテンツを要求しているクライアント間の帯域幅共有の程度を最大にすることである。図2に示されているように、プロセスはステップ201で開始され、ステップ202へ進行する。ステップ202で、同じコンテンツに対して、2D要求のインデックスiおよびメタデータ要求のインデックスjをゼロにセットし、次にステップ203へ進む。ステップ203で、サーバーがクライアントからの要求を聞く。それが2Dクライアントからの2Dコンテンツの要求である場合、ステップ204へ進み、また、それが3Dクライアントからの3Dコンテンツの要求である場合、ステップ205へ進む。ステップ204で、サーバーが2Dクライアントのためのスケジュールつまり確定スケジュールを決定し、かつ、決定されたスケジュールに基づいて2Dコンテンツの送信をスケジューリングし、次にステップ206へ進む。ステップ206で、2Dのインデックスiを1だけ大きくするよう要求し、プロセスは次にステップ203へ進む。ステップ205で、サーバーが、3Dクライアントのために、それぞれ3Dコンテンツの2D部分およびメタデータ部分のための2つのスケジュールを決定し、かつ、決定された2つのスケジュールに基づいて2D部分およびメタデータ部分の送信をスケジューリングし、ステップ207へ進む。ステップ207で、2Dのインデックスおよびメタデータのインデックスをそれぞれ1だけ大きくするよう要求し、プロセスはステップ203へ進む。本発明の原理によると、上で説明した方法により、3Dクライアントつまり3Dコンテンツを見るクライアントは、マルチキャストを使用することにより、2D部分のための帯域幅を2Dクライアントと共有することができる。さらに、マルチキャストを使用することにより、2D部分またはメタデータ部分のいずれかに対して、同じコンテンツを見るクライアント間でそのデータが共有される。したがってサーバーの帯域幅の必要性が減少する。上で説明した方法では、2Dクライアントのための2Dコンテンツのためのスケジュールの決定に関して、特許文献1に記載されている方法を使用することができる。これは、2D部分およびメタデータ部分が個別のマルチキャストストリームで送信されることによるものである。2Dクライアントにはメタデータに立体視野を生成させる必要がないため、2Dクライアントによって要求される2D部分の送信は、メタデータ部分の送信と同期させる必要はない。さらに、3Dクライアントのための3Dコンテンツのためのスケジュールの決定に関して、2D部分およびメタデータ部分の送信を同期させる必要があり、つまり3Dコンテンツの2D部分およびメタデータ部分に同じシーケンス番号を有するセグメントは、立体視野を生成するためには、同じ時点またはクライアントにとって許容可能な差を有する2つの時点で送信しなければならない。さもなければ3Dクライアントは、2D部分およびメタデータ部分に基づいて立体視野を生成することができない。図3は、本発明の実施形態による、3Dコンテンツの2D部分およびメタデータ部分の送信をスケジューリングするための方法を示す図である。目的は、2Dコンテンツ部分のため、およびメタデータ部分のための同期化マルチキャストストリームを使用して、3Dコンテンツ送信のための帯域幅必要条件を緩和し、かつ、スタートアップ遅延を最短化することである。この方法は、上で説明した方法に追加することができる。明瞭さを改善するために、いくつかの概念および定義を以下に示しておく。セグメント:3Dコンテンツのための2D部分がN個のセグメントに論理的に分割されると仮定し、すべてのセグメントは同じサイズすなわち時間長さを有し、同じ3Dコンテンツのためのメタデータ部分も同じくN個のセグメントに分割され、すべて同じサイズを有する。本明細書においては、セグメントの数がスケジューリングスキームの粒度を決定する。帯域幅制限:サーバー側における2D部分およびメタデータ部分のための送信帯域幅が制限されると仮定する。帯域幅制限は、平均速度の倍数の数として表される。2D部分の平均速度はb_2Dと表し、また、メタデータ部分の平均速度はb_metadataと表す。ストリームおよび要求:ストリームSiは、要求Riに応答して送信するためのスケジュールを有する所与のコンテンツのための一組の選択されたセグメントである。2Dクライアントが要求を発すると、その要求は2Dスケジューリングモジュールに転送される。また、サーバーは、その要求に応じてストリームをスケジューリングする。スケジュールされたストリームは、いつ、どのセグメントが送信されるのかを示している。2Dクライアントからの2Dコンテンツのすべての要求は、スケジュールされたストリームに対応している。3Dクライアントが要求を発すると、その要求は2Dスケジューリングモジュールおよびメタデータスケジューリングモジュールに転送される。サーバーは、その要求のための2つのストリーム、つまり2D部分のためのストリームおよびメタデータ部分のためのストリームをスケジューリングする。3Dクライアントからの3Dコンテンツのすべての要求は、2つのスケジュールされたストリームに対応している。タイムスロット:タイムスロットは、セグメントを適合する時間の継続期間である。同じタイムスロットに対応しているセグメントは同じ時間に送信される。すべてのタイムスロットは、特定の数のセグメントつまり帯域幅制限によって決定されるその容量を保持することができる。タイムスロットがその容量より多いセグメントを保持しなければならない場合、そのタイムスロットは過負荷タイムスロットと呼ばれ、一方、タイムスロットがその容量より少ないセグメントを保持しなければならない場合、そのタイムスロットは過少負荷タイムスロットと呼ばれる。例えばタイムスロットが1sであり、また、タイムスロット内に最大5個のセグメントを送信することができると仮定すると、送信機が特定のタイムスロットで6個以上のセグメントを送信しなければならない場合、このタイムスロットは過負荷タイムスロットであり、一方、5個未満のセグメントを送信しなければならない場合、そのタイムスロットは過少負荷タイムスロットである。図3に示されているステップ301および302で、3Dコンテンツの要求を受け取ると、サーバーは、3Dコンテンツの2D部分のための仮スケジュールこれを2D仮スケジュールと呼ぶを決定し、また、3Dコンテンツのメタデータ部分のための仮スケジュールこれをメタデータ仮スケジュールと呼ぶを決定する。詳細には、ステップ301で、後続する1つまたは複数の送信時点の決定以外に、サーバーは、帯域幅制限に基づいて、要求された3Dコンテンツの2D部分のための最短スタートアップ遅延、つまり2D部分のための第1の時点を決定する。これをd_2Dで表す。シフト後、要求Rkのための最短初期遅延dkを決定することができる。仮スケジュールでセグメントを配信するための時点をU={uk1,uk2,....,uky}で表すと、セグメントシフト後にセグメントを配信するための時点は、V={vk1,vk2、....,vky}で表され、が得られる。ステップ302で、後続する1つまたは複数の送信時点の決定以外に、サーバーは、帯域幅制限に基づいて、要求された3Dコンテンツのメタデータ部分のための最短スタートアップ遅延、つまりメタデータ部分のための第1の時点を決定する。これをd_metadataで表す。第1のメタデータ要求の場合、メタデータ部分のすべてのセグメントを使用して連続マルチキャストストリームが構成される。関連する2D要求が第1の2D要求ではない場合例えばR1/R1_3Dクライアント、メタデータ部分のためにスケジュールされた連続ストリームは、d_2Dの間、遅延される。非第1のメタデータ要求の場合、その決定は、非第1の2D要求と同様である。ステップ303で、サーバーは、2D仮スケジュールおよびメタデータ仮スケジュールを調整して、要求された3Dコンテンツのための2D確定スケジュールおよびメタデータ確定スケジュールを生成する。詳細には、サーバーは、d_2Dとd_metadataのうちの大きい方を選択することにより、統一された最短スタートアップ遅延d_minまたは2D部分およびメタデータ部分の両方のための統一された第1の時点と呼ぶを決定する。d_min=max{d_2D,d_metadata}2D部分に関しては、2D確定スケジュールは以下によって得られる。最初にd_minを使用して2D仮スケジュールが遅延され、つまりセグメントを送信するための時点は、Uk’={uk1d_min,uk2d_min,....,ukyd_min}で表される。メタデータ部分に関しては、メタデータ確定スケジュールは、2D確定スケジュールと同様の方法で得られる。ステップ304および305で、サーバーは、2D確定スケジュールに基づいて2D部分の送信をスケジューリングし、また、メタデータ確定スケジュールに基づいてメタデータ部分の送信をスケジューリングする。それぞれ3Dコンテンツの2D部分の仮スケジュールおよびメタデータ部分の仮スケジュールを示す図4A、4Bを参照して、また、それぞれ3Dコンテンツの2D部分の確定スケジュールおよびメタデータ部分の確定スケジュールを示す図5Aおよび5Bを参照して、例によってさらに本発明について説明する。図の中の個々の小さい円は要求を表している。実線の上の数字は、対応するセグメントのシーケンス番号を表している。2D部分およびメタデータ部分は、いずれも20個のセグメントに分割されている。クライアントからの4つの要求が存在しており、そのうちの1つは2Dクライアントからの要求であり、また、3つは3Dクライアントからの要求である。2Dクライアントからの要求はR0で表されている。3Dクライアントからの要求は、2D要求R1,R2,R3およびメタデータ要求R1_3D,R2_3D,R3_3Dで表されている。2D部分またはメタデータ部分のいずれかのための仮スケジュールは、2D部分またはメタデータ部分のどのセグメントが新しく生成されるマルチキャストストリームで送信されることになるのかを示す情報、新しく生成されるマルチキャストストリームでいつこれらのセグメントが送信されるのかを示す1つまたは複数の時点、および新しいマルチキャストストリームで送信されない残りのセグメントを得ることができる1つまたは複数の既存のマルチキャストストリームを含む。図4Aは、2D部分の仮スケジュールの例を示す。2Dビデオ部分は、0から19までのラベルが振られたシーケンス番号を有する20個のセグメントに分割されている。時点a0、a1、a2およびa3で生じる2Dビデオおよび3Dビデオの4つの要求が存在している。セグメント0に対応する開始時点を有するR2要求を例に取ると、R2クライアントのための2D部分の仮スケジュールは、セグメント0から4および8から12が新しいマルチキャストストリームで送信されることを示す情報、いつセグメント0および8が送信されるのかを示す2つの時点を含む。クライアントR2は、R1クライアントのための既存のマルチキャストストリームからセグメント5から7を得ることができ、また、R0クライアントのための既存のマルチキャストストリームからセグメント13から19を得ることができる。言い換えると、要求R2に対しては、システムは、要求R2に応答して開始セグメント0の送信と同じ時間に最も早くこれらのセグメントを送信する既存のマルチキャストストリームに加えて、セグメント5から7および13から19を送信しない。したがってサーバー側における帯域幅の使用が著しく最適化される。仮スケジュールは、セグメント毎に、それを新しいマルチキャストストリームで送信しなければならない場合に、それがいつ送信されるのかを示す情報、および新しいマルチキャストストリームで送信する必要がない場合、いつ、どこでそれを得ることができるかを示す情報を含む。変形態様によれば、サーバーが注意を払うのは、セグメントをいつ送信するか、に関してのみであるため、いつ、どの既存の1つまたは複数のマルチキャストストリームでセグメントが得られるかに関する情報を必ずしも仮スケジュールに含む必要はない。しかしながら、既存の1つまたは複数のマルチキャストストリームで運ばれるセグメントをクライアントが受け取るのを補助するために、このような情報を個別にクライアントに送信することができる。したがってサーバー101は、このような情報を1つまたは複数の要求しているクライアントに知らせるための通知モジュール図1には図示されていないを備えることができる。同じ方法を使用して、互いに独立した2D仮スケジュールおよびメタデータ仮スケジュールを決定することができる。例として特許文献1に記載されている方法を使用して2D仮スケジュールおよびメタデータ仮スケジュールを個々に決定することができる。2D部分に関しては、2D仮スケジュールは、2D部分の最初のセグメントつまり図4Aの0のシーケンス番号を有するセグメントの配信を開始するための第1の時点、および2D部分のいくつかの後続するセグメントの配信を開始するための1つまたは複数の後続する送信時点を含むことができ、第1の時点が、要求を受け取ってから2D部分の最初のセグメントの配信を開始するまでの遅延を最短化し、また、1つまたは複数の後続する送信時点が、配信遅延制限を満足し、かつ、2D部分の後続するセグメントの配信を開始するための遅延を長くする。1つまたは複数の後続する送信時点が、後続するセグメントを他の要求しているクライアントと共有することができるよう、後続するセグメントの送信を可能な限り遅くする。しかしながら、後続する時点は、クライアントの側で受け取られるコンテンツを連続的に再生することができ、あるいは許容不可能な中断を伴うことなく再生することができる方法で選択される。図4AのR3クライアントを例に取ると、2D仮スケジュールは、セグメント0~1の配信を開始するための第1の時点a3、およびそれぞれセグメント5~6および13~14の配信を開始するための2つの後続する送信時点を含む。2D部分の残りのセグメントは、既存のマルチキャストストリームから得ることができるセグメント2から4および8から12は、クライアントR2にリンクされているストリームから得ることができ、セグメント7は、R1にリンクされているストリームから得ることができ、また、セグメント15から19は、クライアントR0にリンクされているストリームから得ることができる。メタデータ仮スケジュールに関しては、それは、2D仮スケジュールにおけるコンテンツと同様のコンテンツを含む。帯域幅が3b_2Dであると仮定すると、それは、4つのストリームの間で、同時に最大3個のセグメントしか送信することができないことを意味する。言い換えると、同時に、クライアントR2のためのセグメント2、クライアントR1のためのセグメント7およびクライアントR0のためのセグメント15の送信が生じるため、時点a3における2D部分の最初のセグメント0の配信は不可能である。第1の可能な後続するタイムスロットでクライアントR3のための最初のセグメント0の配信を遅延させる必要があるセグメント0がクライアントR2のためのセグメント3およびクライアントR0のためのセグメント16と同じタイムスロットで送信される図5Aを参照されたい。図4BのR3_3DクライアントすなわちR3クライアントを例に取ると、R3_3Dクライアントのためのメタデータ仮スケジュールは、セグメント0から2を送信するための第1の時点つまり3Dコンテンツのメタデータ部分のセグメント0の配信を開始するための時点、およびセグメント5~6の配信を開始するための後続する送信時点を含む。メタデータの残りのセグメントは、既存のマルチキャストストリームから得ることができるセグメント3~4は、クライアントR2_3Dにリンクされているストリームから得ることができ、また、セグメント7から19は、R1_3Dにリンクされているストリームから得ることができる。帯域幅に対する仮定を、2D部分のための帯域幅と同じように仮定すると、3つのマルチキャストストリームの送信には問題はなく、また、メタデータのセグメント0の配信を遅延させる必要もない。立体視野を生成するためには、2D部分およびメタデータ部分は共同して動作する必要があるため、2D部分およびメタデータ部分の第1のセグメントの最初の送信を同期させなければならない。したがって以下の説明は、確定スケジュールにおける2D部分およびメタデータ部分のための第1の時点の決定に対してより的が絞られている。図5Bでは、メタデータ部分の最初のセグメント0の配信は、2D部分の最初のセグメント0の配信と同期させるために、1タイムスロットだけ遅延されている。次に、クライアントR3_3Dによる要求時に3Dコンテンツを配信するための2D部分およびメタデータ部分の確定スケジュールが得られる。本発明の性能を評価するための実験がなされている。本発明で紹介されている方法を使用しない場合、720個のクライアントが、ビデオ再生速度の6倍の帯域幅を有するサーバーに2時間3Dコンテンツを要求するべく試行すると、6個のクライアントにしかサービスすることができない。また、現在サービスされているクライアントがコンテンツを終了するまで、他のクライアントにサービスすることはできない。最悪の状況では、それは2時間待機しなければならない。しかしながら、本発明者らの発明を使用した実験では、VODサーバーによって2時間3Dコンテンツが提供される。2D部分およびメタデータ部分は、いずれもN=7200であるN個のブロックに分割されている。したがって個々のブロックは1秒間継続する。サーバーに要求を送ることによって2時間3Dコンテンツを要求している720個のクライアントが存在している。サーバーに到達するこれらの要求は、ポアソン分布に従い、平均到達間隔は10sである。帯域幅制限は、ビデオ再生速度の6倍である。すべてのクライアントが3Dである場合、平均スタートアップ遅延はちょうど17.6sであり、また、80スタートアップ遅延は30s未満、90スタートアップ遅延は50s未満である。2Dまたは3Dクライアントは、最初のセグメント以外の特定のセグメントからの2Dコンテンツすなわち2D部分または3Dコンテンツの開始を要求することができ、また、本発明は、依然としてこの場合に適用することができる。さらに、2Dまたは3Dクライアントは、セグメントのシーケンス番号を直接示している時点以外の特定の時点からの2Dコンテンツまたは3Dコンテンツの開始を要求することができる。この場合、サーバーは、受け取った時点とセグメントのための時点を比較することにより、2D部分およびメタデータ部分の開始セグメントを決定することができる。"