特許 5890517 ３Ｄコンテンツを配信するための方法およびデバイス

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5890517

(24)【登録日】2016年2月26日

(45)【発行日】2016年3月22日

(54)【発明の名称】３Ｄコンテンツを配信するための方法およびデバイス

(51)【国際特許分類】

   G06F 13/00 20060101AFI20160308BHJP

   H04N 21/262 20110101ALI20160308BHJP

   H04N 13/00 20060101ALI20160308BHJP

【ＦＩ】

   G06F13/00 540A

   H04N21/262

   G06F13/00 520B

   H04N13/00

【請求項の数】4

【全頁数】14

(21)【出願番号】特願2014-516160(P2014-516160)

(86)(22)【出願日】2011年6月24日

(65)【公表番号】特表2014-527211(P2014-527211A)

(43)【公表日】2014年10月9日

(86)【国際出願番号】CN2011076276

(87)【国際公開番号】WO2012174739

(87)【国際公開日】20121227

【審査請求日】2014年6月2日

(73)【特許権者】

【識別番号】501263810

【氏名又は名称】トムソン ライセンシング

【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ

(74)【代理人】

【識別番号】110001243

【氏名又は名称】特許業務法人 谷・阿部特許事務所

(72)【発明者】

【氏名】シュー イエン

(72)【発明者】

【氏名】ドゥー リン

(72)【発明者】

【氏名】ソン ジエンピン

【審査官】 木村 雅也

(56)【参考文献】

【文献】 特表２０１０−５１６１２５（ＪＰ，Ａ）

【文献】 国際公開第２０１１／０６２５７２（ＷＯ，Ａ１）

【文献】 国際公開第２０１１／０１３９９５（ＷＯ，Ａ１）

【文献】 特開２０１１−０９７２２７（ＪＰ，Ａ）

【文献】 特開２００６−１０８８３１（ＪＰ，Ａ）

【文献】 特表２０１０−５１２０９６（ＪＰ，Ａ）

【文献】 国際公開第２００８／０８３５２３（ＷＯ，Ａ１）

【文献】 米国特許出願公開第２０１０／００５８４０６（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１０／０３２５６７６（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

Ｈ０４Ｎ １３／００

Ｈ０４Ｎ ２１／２６２

(57)【特許請求の範囲】

【請求項1】

等しい数のセグメントに分割され、かつ、２つのマルチキャストストリームで送信される２Ｄ部分およびメタデータ部分を含む３Ｄコンテンツを配信するための方法であって、
第１のクライアントデバイスからの前記３Ｄコンテンツの第１の要求を、前記３Ｄコンテンツの前記２Ｄ部分の最初でないセグメントを第１のマルチキャストストリームで第２のクライアントデバイスに配信する際に受信するステップと、
前記２Ｄ部分の最初のセグメントから最初でないセグメントまでのセグメントを第２のマルチキャストストリームで、および前記メタデータ部分の最初のセグメントから最後のセグメントまでのセグメントを第３のマルチキャストストリームで送信するステップと、
前記２Ｄ部分の最初のセグメントから最初でないセグメントまでのセグメントを送信する時点を決定するステップと、
前記２Ｄ部分のセグメントに対する遅延の値を決定するステップと、
前記メタデータ部分の最初のセグメントから最後のセグメントまでのセグメントを送信する時点を決定するステップと、
前記２Ｄ部分の最初のセグメントから最初でないセグメントまでのセグメントを送信する時点を、前記遅延の値だけ遅延させるステップと、
前記メタデータ部分の最初のセグメントから最後のセグメントまでのセグメントを送信する時点を、前記遅延の値だけ遅延させるステップと、
を含む、前記方法。

【請求項2】

前記第１のクライアントデバイスに、前記２Ｄ部分の最初でないセグメントから最後のセグメントまでのセグメントを前記第１のマルチキャストストリームから受信させるステップを更に含む、請求項１に記載の方法。

【請求項3】

要求に応じて開始時点から３Ｄコンテンツを配信するためのデバイスであって、前記３Ｄコンテンツは、等しい数のセグメントに分割される２Ｄ部分およびメタデータ部分を含むデバイスにおいて、
第１のクライアントデバイスから前記３Ｄコンテンツの第１の要求を受信し、前記要求を２Ｄスケジューリングモジュールおよびメタデータスケジューリングモジュールへ転送する要求フォーキングモジュールであって、前記要求は、前記デバイスが前記３Ｄコンテンツの前記２Ｄ部分の最初でないセグメントを第１のマルチキャストストリームで第２のクライアントデバイスへ配信する際に受信される、要求フォーキングモジュールと、
第２のマルチキャストストリームにおいて前記２Ｄ部分の最初のセグメントから最初でないセグメントまでのセグメントを前記第１のクライアントデバイスに送信する時点を決定し、前記２Ｄ部分のセグメントに対する遅延の値を決定し、前記２Ｄ部分の最初のセグメントから最初でないセグメントまでのセグメントを送信する時点を、前記遅延の値だけ遅延させる２Ｄスケジューリングモジュールと、
第３のマルチキャストストリームにおいて前記メタデータ部分の最初のセグメントから最後のセグメントまでのセグメントを送信する時点を決定し、前記メタデータ部分の最初のセグメントから最後のセグメントまでのセグメントを送信する時点を、前記遅延の値だけ遅延させるメタデータスケジューリングモジュールと、
を備える、前記デバイス。

【請求項4】

前記２Ｄ部分の最初のセグメントから最初でないセグメントまでのセグメントを前記第１のマルチキャストストリームから取得することができることを前記第１のクライアントデバイスに知らせる通知モジュールを更に備える、請求項３に記載のデバイス。

【発明の詳細な説明】

【技術分野】

【0001】

本発明はネットワーク通信に関し、より詳細には３Ｄコンテンツを配信するための方法およびデバイスに関する。

【背景技術】

【0002】

ビデオオンデマンド（ＶｏＤ）またはオーディオおよびビデオオンデマンド（ＡＶｏＤ）システムは、要求時におけるクライアントによるビデオまたはオーディオコンテンツの選択および再生を可能にしている。ＩＰＴＶ技術は、要求時にビデオをテレビジョンおよびパーソナルコンピュータにもたらすためにしばしば使用されている。

【0003】

ＶｏＤサーバーの側における帯域幅などの制限された送信資源は、大規模なクライアントを同時に許容しないことがある。

【0004】

公開されたＰＣＴ出願である特許文献１に、制限された資源をより有効に利用するための解決法が記載されており、２Ｄビデオコンテンツ（または記述を短くするために２Ｄコンテンツ）のＶｏＤサーバーのためのスケジューリング方法を提供している。２Ｄコンテンツは、複数の部分すなわちブロックに分割される。この方法は、要求された２Ｄコンテンツのうち、要求しているクライアントのための部分の送信をスケジュールし直し、かつ、マルチキャストを使用して送信するため、同じ２Ｄコンテンツを要求しているクライアントの間でいくつかの部分を共有することができる。詳細には、この方法は、２Ｄコンテンツの要求を受け取るステップ、および２Ｄコンテンツの最初の部分に対しては第１の遅延で、また、２Ｄコンテンツの後続する部分に対しては第２の遅延で２Ｄコンテンツを配信するためのスケジュールを生成するステップを含む。スケジュールを生成するステップは、要求を受け取ってから２Ｄコンテンツの最初の部分を配信するまでの時間期間を最短にする第１の遅延を選択するステップ、および要求に関連する遅延パラメータを満足し、かつ、後続する部分の配信を開始するための遅延を長くする第２の遅延を選択するステップを含む。この文献においては、第２の遅延が、後続する部分の送信を可能な限り遅くしているが、それは、クライアントの側によって受け取られるコンテンツを連続的に再生することができ、あるいは少なくとも許容不可能な中断を伴うことなく再生することができる方法で選択される。

【0005】

３Ｄシステムでは、立体視野を生成するために、クライアント側での左目視野および右目視野（または左視野および右視野と呼ばれる）が一緒に使用される。左視野および右視野をクライアント側に送信するための最も簡単な方法は、完全に独立したデータストリームとして左目視野および右目視野を送信することである。代替は、２Ｄビデオおよびメタデータを送信することであり、メタデータは三次元の情報を表す。

【0006】

２つのタイプの２Ｄおよびメタデータ、つまり２Ｄプラスデルタ（すなわち２Ｄプラス差）および２Ｄプラス深さ（すなわち２Ｄ＋Ｚ）が存在している。２Ｄプラスデルタに関しては、それは、とりわけマルチビュービデオ符号化拡張のＨ．２６４実施態様に対するＭＰＥＧ２およびＭＰＥＧ４の一部としての標準リスト化方法である。それは、２Ｄバージョン（または２Ｄ部分と呼ばれる）として左視野または右視野（それらは左チャネルおよび右チャネルと呼ばれることもある）を利用しており、また、左視野と右視野の間の最適化された差すなわち視差（デルタ）がｃｌｉｅｎｔ＿ｄａｔａ、二次ストリーム、独立ストリームまたはエンハンスメント層としてビデオストリームに挿入される。したがって２Ｄバージョンおよびデルタを使用することにより、立体視野を生成することができる。デルタデータは、空間立体的不一致、時間的予測、双方向または最適化された動き補償のいずれであってもよい。２Ｄプラス深さに関しては、個々の２Ｄ画像フレームが、２Ｄ画像中の特定のピクセルをスクリーン平面の前面または背面に示す必要があるかどうかを示すデプスマップで補足される。２Ｄプラス深さは、ＭＰＥＧ規格によってサポートされている。ＭＰＥＧ−Ｃパート３は、「補助ビデオ」としてのデプスマップの処理を可能にし、また、既存のビデオ符号化技法（例えばＨ．２６４／ＡＶＣ）を使用した圧縮を可能にしている。

【0007】

３Ｄシステムでは、最も使用されるフォーマットは、ケーブル、衛星、インターネットまたは地上同報通信を介してＶｏＤなどの既存のコンテンツ分散および管理システムに容易に統合することができる２Ｄプラスメタデータである。また、それは、従来の２Ｄセット−トップボックスと上位互換性があり、また、ディスプレイフォーマットには無関係である。これらの３Ｄシステムでは、２Ｄおよびメタデータは、通常、多重化され、かつ、単一のチャネルまたはデータストリームを介して送信される。したがって３Ｄ ＶｏＤサービスは、いくつかの既存の２Ｄコンテンツ配信システムを使用することによって容易に提供することができる。Ｎｕｍｅｒｉｃａｂｌｅ、Ｖｉｒｇｉｎ Ｍｅｄｉａ、Ｐｈｉｌｉｐ、等の多くの会社がこの方法で３Ｄ ＶｏＤサービスを提供している。

【0008】

２Ｄプラスメタデータを２つの異なるチャネルまたはデータストリームで送信することにより、２Ｄビデオプレーヤーと３Ｄビデオプレーヤーを共存させることができる。２Ｄビデオプレーヤーを有する視聴者は、通常、２Ｄデータしか受け取ることができず、また、２Ｄビデオしか見ることができない。視聴者は、関連するメタデータを受け取るか否かを選択することができるが、これは、２Ｄおよびメタデータが多重化されると不可能である。３Ｄビデオプレーヤーを有する視聴者は、２Ｄデータおよびメタデータの両方を受け取ることができる。

【0009】

しかしながら、２Ｄプラスメタデータを送信するための従来の方法は、帯域幅を有効に利用していないため、同じ３Ｄコンテンツを要求しているクライアント間で３Ｄコンテンツを有効に送信する方法が望ましい。

【先行技術文献】

【特許文献】

【0010】

【特許文献1】国際公開第ＷＯ２００８／０８３５２３号

【発明の概要】

【課題を解決するための手段】

【0011】

本発明の態様によると、同じ数のセグメントに分割され、かつ、２つのマルチキャストストリームで送信される２Ｄ部分およびメタデータ部分を含む３Ｄコンテンツを配信するための方法が提供され、前記方法は、２Ｄ部分の開始セグメントおよびメタデータ部分の開始セグメントに対応する開始時点を有する３Ｄコンテンツの要求を受け取るステップと、２Ｄ部分の開始セグメントを含む前記２Ｄ部分の少なくとも１つのセグメントの第１のマルチキャストストリームでの送信、およびメタデータ部分の開始セグメントを含む前記メタデータ部分の少なくとも１つのセグメントの第２のマルチキャストストリームでの送信をスケジューリングするステップとを含み、２Ｄ部分の開始セグメントの送信およびメタデータ部分の開始セグメントの送信が同期化される。

【0012】

本発明の他の態様によると、要求に応じて開始時点から３Ｄコンテンツを配信するためのデバイスが提供され、３Ｄコンテンツは、同じ数のセグメントに分割される２Ｄ部分およびメタデータ部分を含み、デバイスは、３Ｄコンテンツの開始時点に対応する２Ｄ部分の開始セグメントを含む前記２Ｄ部分の少なくとも１つのセグメントの第１のマルチキャストストリームでの送信をスケジューリングするための２Ｄスケジューリングモジュール（１０２）と、３Ｄコンテンツの開始時点に対応するメタデータ部分の開始セグメントを含む前記メタデータ部分の少なくとも１つのセグメントの第２のマルチキャストストリームでの送信をスケジューリングするためのメタデータスケジューリングモジュール（１０３）とを備えており、２Ｄスケジューリングモジュール（１０２）およびメタデータスケジューリングモジュール（１０３）は、２Ｄ部分の開始セグメントの送信およびメタデータ部分の開始セグメントの送信を同期させる。

【0013】

本発明の他の態様および利点は、添付の図面を参照して行う、本発明についての以下の詳細な説明の中で見出されよう。以下の説明は、本発明の範囲を制限するものではない実施形態に関していることを理解されたい。

【図面の簡単な説明】

【0014】

【図1】本発明の実施形態による、２Ｄクライアントおよび３Ｄクライアントにコンテンツを配信するためのシステムを示す図である。

【図2】本発明の実施形態によるスケジューリングプロセスの例を示す図である。

【図3】本発明の実施形態による、３Ｄコンテンツの２Ｄ部分およびメタデータ部分の送信をスケジューリングするための方法を示す図である。

【図4A】本発明の実施形態による、２Ｄ仮スケジュールの例を示す図である。

【図4B】本発明の実施形態による、メタデータ仮スケジュールの例を示す図である。

【図5A】本発明の実施形態による、４Ａに示されている仮スケジュールに基づく２Ｄ確定スケジュールの例を示す図である。

【図5B】本発明の実施形態による、４Ｂに示されている仮スケジュールに基づくメタデータ確定スケジュールの例を示す図である。

【発明を実施するための形態】

【0015】

以下、本発明の実施形態について、図面に関連して詳細に説明する。以下の説明では、知られている機能および構成についてのいくつかの詳細な説明は、分かり易く、かつ、簡潔にするために省略されている。

【0016】

本発明の目的は、３Ｄ ＶｏＤシステムにおける３Ｄビデオを効率的に送信することであり、３Ｄビデオの２Ｄ部分およびメタデータ部分は、２つの独立したチャネルまたはデータストリームを介して送信される。

【0017】

図１は、本発明の実施形態による、２Ｄクライアントおよび３Ｄクライアントにコンテンツを配信するためのシステムを示す図である。図において、破線は、２Ｄまたは３Ｄビデオの要求などの信号の流れを表しており、また、実線は、２Ｄ部分およびメタデータ部分のデータなどのデータの流れを表している。システムは、ＶｏＤシステムにおける２Ｄビデオおよび３Ｄビデオの送信をスケジューリングするためのＶｏＤサーバー１０１、および２Ｄクライアントおよび３Ｄクライアントを表す複数のデバイスを備えている。ＶｏＤサーバー１０１は、２Ｄスケジューリングモジュール１０２、メタデータスケジューリングモジュール１０３および要求フォーキングモジュール１０４を備えている。それらの機能は以下の通りである。

【0018】

−要求フォーキングモジュール１０４は、２Ｄクライアントおよび３Ｄクライアントから要求を受け取り、かつ、受け取った要求をそれに応じて２Ｄスケジューリングモジュール１０２およびメタデータスケジューリングモジュール１０３に転送するために使用される。つまり、２Ｄクライアントまたは３Ｄクライアントが２Ｄビデオの要求を発すると、その要求は、要求フォーキングモジュール１０４によって２Ｄスケジューリングモジュール１０２に転送され、また、３Ｄクライアントが３Ｄビデオの要求を発すると、その要求は、要求フォーキングモジュール１０４によって２Ｄスケジューリングモジュール１０２およびメタデータスケジューリングモジュール１０３の両方に転送される。

【0019】

−２Ｄスケジューリングモジュール１０２は、クライアントから２Ｄビデオまたは３Ｄビデオの要求を受け取ると、２Ｄ部分をクライアントに配信するための仮スケジュールおよび確定スケジュールを決定するために使用される。

【0020】

−メタデータスケジューリングモジュール１０３は、クライアントから３Ｄビデオの要求を受け取ると、メタデータ部分をクライアントに配信するための仮スケジュールおよび確定スケジュールを決定するために使用される。

【0021】

本明細書においては、２Ｄビデオの要求を受け取ると、２Ｄスケジューリングモジュール１０２のみが動作して、対応する３Ｄビデオの２Ｄ部分を配信するための仮スケジュールを決定する。また、この仮スケジュールは、サーバーによって、２Ｄ部分の配信をスケジュールするための確定スケジュールとして使用される。３Ｄビデオの要求を受け取ると、２Ｄスケジューリングモジュール１０２およびメタデータスケジューリングモジュール１０３は、それぞれ独立して動作して、２Ｄ部分およびメタデータ部分のための２つの仮スケジュールを決定し、また、共同して動作して、２つの仮スケジュールに基づいて２Ｄ部分およびメタデータ部分のための２つの確定スケジュールを決定し（以下で詳細に説明する）、また、サーバーは、これらの２つの確定スケジュールを使用して、２Ｄ部分およびメタデータ部分の送信をスケジューリングする。

【0022】

図２は、本発明の実施形態によるスケジューリングプロセスの例を示す図である。目的は、１）要求を受け取ってからコンテンツの配信を開始するまでの間のスタートアップ遅延を最短にすること、および２）同じコンテンツを要求しているクライアント間の帯域幅共有の程度を最大にすることである。

【0023】

図２に示されているように、プロセスはステップ２０１で開始され、ステップ２０２へ進行する。ステップ２０２で、同じコンテンツに対して、２Ｄ要求のインデックスｉおよびメタデータ要求のインデックスｊをゼロにセットし、次にステップ２０３へ進む。ステップ２０３で、サーバーがクライアントからの要求を聞く。それが２Ｄクライアントからの２Ｄコンテンツの要求である場合、ステップ２０４へ進み、また、それが３Ｄクライアントからの３Ｄコンテンツの要求である場合、ステップ２０５へ進む。ステップ２０４で、サーバーが２Ｄクライアントのためのスケジュール（つまり確定スケジュール）を決定し、かつ、決定されたスケジュールに基づいて２Ｄコンテンツの送信をスケジューリングし、次にステップ２０６へ進む。ステップ２０６で、２Ｄのインデックスｉを１だけ大きくするよう要求し、プロセスは次にステップ２０３へ進む。ステップ２０５で、サーバーが、３Ｄクライアントのために、それぞれ３Ｄコンテンツの２Ｄ部分およびメタデータ部分のための２つのスケジュールを決定し、かつ、決定された２つのスケジュールに基づいて２Ｄ部分およびメタデータ部分の送信をスケジューリングし、ステップ２０７へ進む。ステップ２０７で、２Ｄのインデックスおよびメタデータのインデックスをそれぞれ１だけ大きくするよう要求し、プロセスはステップ２０３へ進む。

【0024】

本発明の原理によると、上で説明した方法により、３Ｄクライアント（つまり３Ｄコンテンツを見るクライアント）は、マルチキャストを使用することにより、２Ｄ部分のための帯域幅を２Ｄクライアントと共有することができる。さらに、マルチキャストを使用することにより、２Ｄ部分またはメタデータ部分のいずれかに対して、同じコンテンツを見るクライアント間でそのデータが共有される。したがってサーバーの帯域幅の必要性が減少する。

【0025】

上で説明した方法では、２Ｄクライアントのための２Ｄコンテンツのためのスケジュールの決定に関して、特許文献１に記載されている方法を使用することができる。これは、２Ｄ部分およびメタデータ部分が個別のマルチキャストストリームで送信されることによるものである。２Ｄクライアントにはメタデータに立体視野を生成させる必要がないため、２Ｄクライアントによって要求される２Ｄ部分の送信は、メタデータ部分の送信と同期させる必要はない。

【0026】

さらに、３Ｄクライアントのための３Ｄコンテンツのためのスケジュールの決定に関して、２Ｄ部分およびメタデータ部分の送信を同期させる必要があり、つまり３Ｄコンテンツの２Ｄ部分およびメタデータ部分に同じシーケンス番号を有するセグメントは、立体視野を生成するためには、同じ時点またはクライアントにとって許容可能な差を有する２つの時点で送信しなければならない。さもなければ３Ｄクライアントは、２Ｄ部分およびメタデータ部分に基づいて立体視野を生成することができない。

【0027】

図３は、本発明の実施形態による、３Ｄコンテンツの２Ｄ部分およびメタデータ部分の送信をスケジューリングするための方法を示す図である。目的は、２Ｄコンテンツ部分のため、およびメタデータ部分のための同期化マルチキャストストリームを使用して、３Ｄコンテンツ送信のための帯域幅必要条件を緩和し、かつ、スタートアップ遅延を最短化することである。この方法は、上で説明した方法に追加することができる。

【0028】

明瞭さを改善するために、いくつかの概念および定義を以下に示しておく。

【0029】

・セグメント：３Ｄコンテンツのための２Ｄ部分がＮ個のセグメントに論理的に分割されると仮定し、すべてのセグメントは同じサイズ（すなわち時間長さ）を有し、同じ３Ｄコンテンツのためのメタデータ部分も同じくＮ個のセグメントに分割され、すべて同じサイズを有する。本明細書においては、セグメントの数がスケジューリングスキームの粒度を決定する。

【0030】

・帯域幅制限：サーバー側における２Ｄ部分およびメタデータ部分のための送信帯域幅が制限されると仮定する。帯域幅制限は、平均速度の倍数の数として表される。２Ｄ部分の平均速度はｂ＿２Ｄと表し、また、メタデータ部分の平均速度はｂ＿ｍｅｔａｄａｔａと表す。

【0031】

・ストリームおよび要求：ストリーム（Ｓｉ）は、要求（Ｒｉ）に応答して送信するためのスケジュールを有する所与のコンテンツのための一組の選択されたセグメントである。２Ｄクライアントが要求を発すると、その要求は２Ｄスケジューリングモジュールに転送される。また、サーバーは、その要求に応じてストリームをスケジューリングする。スケジュールされたストリームは、いつ、どのセグメントが送信されるのかを示している。２Ｄクライアントからの２Ｄコンテンツのすべての要求は、スケジュールされたストリームに対応している。３Ｄクライアントが要求を発すると、その要求は２Ｄスケジューリングモジュールおよびメタデータスケジューリングモジュールに転送される。サーバーは、その要求のための２つのストリーム、つまり２Ｄ部分のためのストリームおよびメタデータ部分のためのストリームをスケジューリングする。３Ｄクライアントからの３Ｄコンテンツのすべての要求は、２つのスケジュールされたストリームに対応している。

【0032】

・タイムスロット：タイムスロットは、セグメントを適合する時間の継続期間である。同じタイムスロットに対応しているセグメントは同じ時間に送信される。すべてのタイムスロットは、特定の数のセグメント（つまり帯域幅制限によって決定されるその容量）を「保持」することができる。タイムスロットがその容量より多いセグメントを「保持」しなければならない場合、そのタイムスロットは過負荷タイムスロットと呼ばれ、一方、タイムスロットがその容量より少ないセグメントを「保持」しなければならない場合、そのタイムスロットは過少負荷タイムスロットと呼ばれる。例えばタイムスロットが１ｓであり、また、タイムスロット内に最大５個のセグメントを送信することができると仮定すると、送信機が特定のタイムスロットで６個以上のセグメントを送信しなければならない場合、このタイムスロットは過負荷タイムスロットであり、一方、５個未満のセグメントを送信しなければならない場合、そのタイムスロットは過少負荷タイムスロットである。

【0033】

図３に示されているステップ３０１および３０２で、３Ｄコンテンツの要求を受け取ると、サーバーは、３Ｄコンテンツの２Ｄ部分のための仮スケジュール（これを２Ｄ仮スケジュールと呼ぶ）を決定し、また、３Ｄコンテンツのメタデータ部分のための仮スケジュール（これをメタデータ仮スケジュールと呼ぶ）を決定する。詳細には、ステップ３０１で、後続する１つまたは複数の送信時点の決定以外に、サーバーは、帯域幅制限に基づいて、要求された３Ｄコンテンツの２Ｄ部分のための最短スタートアップ遅延、つまり２Ｄ部分のための第１の時点を決定する。これをｄ＿２Ｄで表す。シフト後、要求Ｒ_ｋのための最短初期遅延ｄ_ｋを決定することができる。仮スケジュールでセグメントを配信するための時点をＵ＝｛ｕ_ｋ１，ｕ_ｋ２，．．．．，ｕ_ｋｙ｝で表すと、セグメントシフト後にセグメントを配信するための時点は、Ｖ＝｛ｖ_ｋ１，ｖ_ｋ２、．．．．，ｖ_ｋｙ｝で表され、

【0034】

【数1】

【0035】

が得られる。

【0036】

ステップ３０２で、後続する１つまたは複数の送信時点の決定以外に、サーバーは、帯域幅制限に基づいて、要求された３Ｄコンテンツのメタデータ部分のための最短スタートアップ遅延、つまりメタデータ部分のための第１の時点を決定する。これをｄ＿ｍｅｔａｄａｔａで表す。第１のメタデータ要求の場合、メタデータ部分のすべてのセグメントを使用して連続マルチキャストストリームが構成される。関連する２Ｄ要求が第１の２Ｄ要求ではない場合（例えばＲ１／Ｒ１＿３Ｄクライアント）、メタデータ部分のためにスケジュールされた連続ストリームは、ｄ＿２Ｄの間、遅延される。第１でないメタデータ要求の場合、その決定は、第１でない２Ｄ要求と同様である。

【0037】

ステップ３０３で、サーバーは、２Ｄ仮スケジュールおよびメタデータ仮スケジュールを調整して、要求された３Ｄコンテンツのための２Ｄ確定スケジュールおよびメタデータ確定スケジュールを生成する。詳細には、サーバーは、ｄ＿２Ｄとｄ＿ｍｅｔａｄａｔａのうちの大きい方を選択することにより、統一された最短スタートアップ遅延ｄ＿ｍｉｎ（または２Ｄ部分およびメタデータ部分の両方のための統一された第１の時点と呼ぶ）を決定する。
ｄ＿ｍｉｎ＝ｍａｘ｛ｄ＿２Ｄ，ｄ＿ｍｅｔａｄａｔａ｝

【0038】

２Ｄ部分に関しては、２Ｄ確定スケジュールは以下によって得られる。最初にｄ＿ｍｉｎを使用して２Ｄ仮スケジュールが遅延され、つまりセグメントを送信するための時点は、Ｕｋ’＝｛ｕ_ｋ１＋ｄ＿ｍｉｎ，ｕ_ｋ２＋ｄ＿ｍｉｎ，．．．．，ｕ_ｋｙ＋ｄ＿ｍｉｎ｝で表される。

【0039】

メタデータ部分に関しては、メタデータ確定スケジュールは、２Ｄ確定スケジュールと同様の方法で得られる。

【0040】

ステップ３０４および３０５で、サーバーは、２Ｄ確定スケジュールに基づいて２Ｄ部分の送信をスケジューリングし、また、メタデータ確定スケジュールに基づいてメタデータ部分の送信をスケジューリングする。

【0041】

それぞれ３Ｄコンテンツの２Ｄ部分の仮スケジュールおよびメタデータ部分の仮スケジュールを示す図４Ａ、４Ｂを参照して、また、それぞれ３Ｄコンテンツの２Ｄ部分の確定スケジュールおよびメタデータ部分の確定スケジュールを示す図５Ａおよび５Ｂを参照して、例によってさらに本発明について説明する。図の中の個々の小さい円は要求を表している。実線の上の数字は、対応するセグメントのシーケンス番号を表している。２Ｄ部分およびメタデータ部分は、いずれも２０個のセグメントに分割されている。クライアントからの４つの要求が存在しており、そのうちの１つは２Ｄクライアントからの要求であり、また、３つは３Ｄクライアントからの要求である。２Ｄクライアントからの要求はＲ０で表されている。３Ｄクライアントからの要求は、２Ｄ要求（Ｒ１，Ｒ２，Ｒ３）およびメタデータ要求（Ｒ１＿３Ｄ，Ｒ２＿３Ｄ，Ｒ３＿３Ｄ）で表されている。

【0042】

２Ｄ部分またはメタデータ部分のいずれかのための仮スケジュールは、２Ｄ部分またはメタデータ部分のどのセグメントが新しく生成されるマルチキャストストリームで送信されることになるのかを示す情報、新しく生成されるマルチキャストストリームでいつこれらのセグメントが送信されるのかを示す１つまたは複数の時点、および新しいマルチキャストストリームで送信されない残りのセグメントを得ることができる１つまたは複数の既存のマルチキャストストリームを含む。図４Ａは、２Ｄ部分の仮スケジュールの例を示す。２Ｄビデオ部分は、０から１９までのラベルが振られたシーケンス番号を有する２０個のセグメントに分割されている。時点ａ０、ａ１、ａ２およびａ３で生じる２Ｄビデオおよび３Ｄビデオの４つの要求が存在している。セグメント０に対応する開始時点を有するＲ２要求を例に取ると、Ｒ２クライアントのための２Ｄ部分の仮スケジュールは、セグメント０から４および８から１２が新しいマルチキャストストリームで送信されることを示す情報、いつセグメント０および８が送信されるのかを示す２つの時点を含む。クライアントＲ２は、Ｒ１クライアントのための既存のマルチキャストストリームからセグメント５から７を得ることができ、また、Ｒ０クライアントのための既存のマルチキャストストリームからセグメント１３から１９を得ることができる。言い換えると、要求Ｒ２に対しては、システムは、要求Ｒ２に応答して開始セグメント０の送信と同じ時間に最も早くこれらのセグメントを送信する既存のマルチキャストストリームに加えて、セグメント５から７および１３から１９を送信しない。したがってサーバー側における帯域幅の使用が著しく最適化される。

【0043】

仮スケジュールは、セグメント毎に、それを新しいマルチキャストストリームで送信しなければならない場合に、それがいつ送信されるのかを示す情報、および新しいマルチキャストストリームで送信する必要がない場合、いつ、どこでそれを得ることができるかを示す情報を含む。変形態様によれば、サーバーが注意を払うのは、セグメントをいつ送信するか、に関してのみであるため、いつ、どの既存の１つまたは複数のマルチキャストストリームでセグメントが得られるかに関する情報を必ずしも仮スケジュールに含む必要はない。しかしながら、既存の１つまたは複数のマルチキャストストリームで運ばれるセグメントをクライアントが受け取るのを補助するために、このような情報を個別にクライアントに送信することができる。したがってサーバー１０１は、このような情報を１つまたは複数の要求しているクライアントに知らせるための通知モジュール（図１には図示されていない）を備えることができる。

【0044】

同じ方法を使用して、互いに独立した２Ｄ仮スケジュールおよびメタデータ仮スケジュールを決定することができる。例として特許文献１に記載されている方法を使用して２Ｄ仮スケジュールおよびメタデータ仮スケジュールを個々に決定することができる。２Ｄ部分に関しては、２Ｄ仮スケジュールは、２Ｄ部分の最初のセグメント（つまり図４Ａの０のシーケンス番号を有するセグメント）の配信を開始するための第１の時点、および２Ｄ部分のいくつかの後続するセグメントの配信を開始するための１つまたは複数の後続する送信時点を含むことができ、第１の時点が、要求を受け取ってから２Ｄ部分の最初のセグメントの配信を開始するまでの遅延を最短化し、また、１つまたは複数の後続する送信時点が、配信遅延制限を満足し、かつ、２Ｄ部分の後続するセグメントの配信を開始するための遅延を長くする。１つまたは複数の後続する送信時点が、後続するセグメントを他の要求しているクライアントと共有することができるよう、後続するセグメントの送信を可能な限り遅くする。しかしながら、後続する時点は、クライアントの側で受け取られるコンテンツを連続的に再生することができ、あるいは許容不可能な中断を伴うことなく再生することができる方法で選択される。

【0045】

図４ＡのＲ３クライアントを例に取ると、２Ｄ仮スケジュールは、セグメント０〜１の配信を開始するための第１の時点ａ３、およびそれぞれセグメント５〜６および１３〜１４の配信を開始するための２つの後続する送信時点を含む。２Ｄ部分の残りのセグメントは、既存のマルチキャストストリームから得ることができる（セグメント２から４および８から１２は、クライアントＲ２にリンクされているストリームから得ることができ、セグメント７は、Ｒ１にリンクされているストリームから得ることができ、また、セグメント１５から１９は、クライアントＲ０にリンクされているストリームから得ることができる）。メタデータ仮スケジュールに関しては、それは、２Ｄ仮スケジュールにおけるコンテンツと同様のコンテンツを含む。帯域幅が３^＊ｂ＿２Ｄであると仮定すると、それは、４つのストリームの間で、同時に最大３個のセグメントしか送信することができないことを意味する。言い換えると、同時に、クライアントＲ２のためのセグメント２、クライアントＲ１のためのセグメント７およびクライアントＲ０のためのセグメント１５の送信が生じるため、時点ａ３における２Ｄ部分の最初のセグメント０の配信は不可能である。第１の可能な後続するタイムスロットでクライアントＲ３のための最初のセグメント０の配信を遅延させる必要がある（セグメント０がクライアントＲ２のためのセグメント３およびクライアントＲ０のためのセグメント１６と同じタイムスロットで送信される図５Ａを参照されたい）。

【0046】

図４ＢのＲ３＿３Ｄクライアント（すなわちＲ３クライアント）を例に取ると、Ｒ３＿３Ｄクライアントのためのメタデータ仮スケジュールは、セグメント０から２を送信するための第１の時点（つまり３Ｄコンテンツのメタデータ部分のセグメント０の配信を開始するための時点）、およびセグメント５〜６の配信を開始するための後続する送信時点を含む。メタデータの残りのセグメントは、既存のマルチキャストストリームから得ることができる（セグメント３〜４は、クライアントＲ２＿３Ｄにリンクされているストリームから得ることができ、また、セグメント７から１９は、Ｒ１＿３Ｄにリンクされているストリームから得ることができる）。帯域幅に対する仮定を、２Ｄ部分のための帯域幅と同じように仮定すると、３つのマルチキャストストリームの送信には問題はなく、また、メタデータのセグメント０の配信を遅延させる必要もない。

【0047】

立体視野を生成するためには、２Ｄ部分およびメタデータ部分は共同して動作する必要があるため、２Ｄ部分およびメタデータ部分の第１のセグメントの最初の送信を同期させなければならない。したがって以下の説明は、確定スケジュールにおける２Ｄ部分およびメタデータ部分のための第１の時点の決定に対してより的が絞られている。図５Ｂでは、メタデータ部分の最初のセグメント０の配信は、２Ｄ部分の最初のセグメント０の配信と同期させるために、１タイムスロットだけ遅延されている。次に、クライアントＲ３＿３Ｄによる要求時に３Ｄコンテンツを配信するための２Ｄ部分およびメタデータ部分の確定スケジュールが得られる。

【0048】

本発明の性能を評価するための実験がなされている。本発明で紹介されている方法を使用しない場合、７２０個のクライアントが、ビデオ再生速度の６倍の帯域幅を有するサーバーに２時間３Ｄコンテンツを要求するべく試行すると、６個のクライアントにしかサービスすることができない。また、現在サービスされているクライアントがコンテンツを終了するまで、他のクライアントにサービスすることはできない。最悪の状況では、それは２時間待機しなければならない。しかしながら、本発明者らの発明を使用した実験では、ＶＯＤサーバーによって２時間３Ｄコンテンツが提供される。２Ｄ部分およびメタデータ部分は、いずれもＮ＝７２００であるＮ個のブロックに分割されている。したがって個々のブロックは１秒間継続する。サーバーに要求を送ることによって２時間３Ｄコンテンツを要求している７２０個のクライアントが存在している。サーバーに到達するこれらの要求は、ポアソン分布に従い、平均到達間隔は１０ｓである。帯域幅制限は、ビデオ再生速度の６倍である。すべてのクライアントが３Ｄである場合、平均スタートアップ遅延はちょうど１７．６ｓであり、また、８０％スタートアップ遅延は３０ｓ未満、９０％スタートアップ遅延は５０ｓ未満である。

【0049】

２Ｄまたは３Ｄクライアントは、最初のセグメント以外の特定のセグメントからの２Ｄコンテンツ（すなわち２Ｄ部分）または３Ｄコンテンツの開始を要求することができ、また、本発明は、依然としてこの場合に適用することができる。さらに、２Ｄまたは３Ｄクライアントは、セグメントのシーケンス番号を直接示している時点以外の特定の時点からの２Ｄコンテンツまたは３Ｄコンテンツの開始を要求することができる。この場合、サーバーは、受け取った時点とセグメントのための時点を比較することにより、２Ｄ部分およびメタデータ部分の開始セグメントを決定することができる。
本発明は以下の態様を含む。
（付記１）
同じ数のセグメントに分割され、かつ、２つのマルチキャストストリームで送信される２Ｄ部分およびメタデータ部分を含む３Ｄコンテンツを配信するための方法であって、
前記２Ｄ部分の開始セグメントおよび前記メタデータ部分の開始セグメントに対応する開始時点を有する前記３Ｄコンテンツの要求を受け取るステップと、
前記２Ｄ部分の前記開始セグメントを含む前記２Ｄ部分の少なくとも１つのセグメントの第１のマルチキャストストリームでの送信、および前記メタデータ部分の前記開始セグメントを含む前記メタデータ部分の少なくとも１つのセグメントの第２のマルチキャストストリームでの送信をスケジューリングするステップであって、前記２Ｄ部分の前記開始セグメントの送信および前記メタデータ部分の前記開始セグメントの送信が同期化される、スケジューリングするステップと、
を含む、前記方法。
（付記２）
前記２Ｄ部分の前記少なくとも１つのセグメントの送信、および前記メタデータ部分の前記少なくとも１つのセグメントの送信をスケジューリングする前記ステップは、
前記２Ｄ部分の前記少なくとも１つのセグメントを送信するための少なくとも１つの時点を示す、前記２Ｄ部分のための仮スケジュール、および前記メタデータ部分の前記少なくとも１つのセグメントを送信するための少なくとも１つの時点を示す、前記メタデータ部分のための仮スケジュールを決定するステップと、
前記２Ｄ部分のための前記仮スケジュールおよび前記メタデータ部分のための前記仮スケジュールに基づいて、前記２Ｄ部分のための確定スケジュールおよび前記メタデータ部分のための確定スケジュールを決定するステップと、
を含む、付記１に記載の方法。
（付記３）
確定スケジュールを決定する前記ステップは、前記２Ｄ部分のための前記仮スケジュールによる、前記２Ｄ部分の前記開始セグメントを送信するための時点と、前記メタデータ部分のための前記仮スケジュールによる、前記メタデータ部分の前記開始セグメントを送信するための時点とのうちの遅い方を、前記２Ｄ部分の前記開始セグメントおよび前記メタデータ部分の開始セグメントを、前記２Ｄ部分のための前記確定スケジュールおよび前記メタデータ部分のための前記確定スケジュールで送信するための時点として選択するステップを含む、付記２に記載の方法。
（付記４）
前記要求された３Ｄコンテンツの前記開始時点は、前記３Ｄコンテンツの初期時間であり、前記２Ｄ部分の前記開始セグメントおよび前記メタデータ部分の前記開始セグメントは、前記２Ｄ部分の最初のセグメントおよび前記メタデータ部分の最初のセグメントである、付記１から３のいずれか一つに記載の方法。
（付記５）
前記２Ｄ部分または前記メタデータ部分の前記少なくとも１つのセグメントのうちの１つは、前記２Ｄ部分の前記開始セグメントおよび前記メタデータ部分の前記開始セグメントを送信した後、それが、同じセグメントのためのより早い要求に応答して前記マルチキャストストリームに存在している場合は送信されない、付記１から４のいずれか一つに記載の方法。
（付記６）
前記セグメントが送信されない場合、前記セグメントをいつ、どのマルチキャストストリームで得ることができるかに関する情報を送るステップをさらに含む、付記５に記載の方法。
（付記７）
要求に応じて開始時点から３Ｄコンテンツを配信するためのデバイスであって、前記３Ｄコンテンツは、同じ数のセグメントに分割される２Ｄ部分およびメタデータ部分を含むデバイスにおいて、
前記３Ｄコンテンツの前記開始時点に対応する前記２Ｄ部分の開始セグメントを含む前記２Ｄ部分の少なくとも１つのセグメントの第１のマルチキャストストリームでの送信をスケジューリングするための２Ｄスケジューリングモジュール（１０２）と、
前記３Ｄコンテンツの前記開始時点に対応する前記メタデータ部分の開始セグメントを含む前記メタデータ部分の少なくとも１つのセグメントの第２のマルチキャストストリームでの送信をスケジューリングするためのメタデータスケジューリングモジュール（１０３）であって、前記２Ｄスケジューリングモジュール（１０２）および前記メタデータスケジューリングモジュール（１０３）は、前記２Ｄ部分の前記開始セグメントの送信および前記メタデータ部分の前記開始セグメントの送信を同期させる、メタデータスケジューリングモジュール（１０３）と、
を備える、前記デバイス。
（付記８）
前記２Ｄスケジューリングモジュール（１０２）は、前記２Ｄ部分の前記少なくとも１つのセグメントを送信するための少なくとも１つの時点を示す、前記２Ｄ部分のための仮スケジュールを決定するために使用され、前記メタデータスケジューリングモジュール（１０３）は、前記メタデータ部分の前記少なくとも１つのセグメントを送信するための少なくとも１つの時点を示す、前記メタデータ部分のための仮スケジュールを決定するために使用され、
前記２Ｄスケジューリングモジュール（１０２）および前記メタデータスケジューリングモジュール（１０３）は、前記２Ｄ部分のための前記仮スケジュールおよび前記メタデータ部分のための前記仮スケジュールに基づいて、前記２Ｄ部分のための確定スケジュールおよび前記メタデータ部分のための確定スケジュールを決定するために個々に使用される、
付記７に記載のデバイス。
（付記９）
確定スケジュールの決定は、前記２Ｄ部分のための前記仮スケジュールによる、前記２Ｄ部分の前記開始セグメントを送信するための時点と、前記メタデータ部分のための前記仮スケジュールによる、前記メタデータ部分の前記開始セグメントを送信するための時点とのうちの遅い方を、前記２Ｄ部分の前記開始セグメントおよび前記メタデータ部分の開始セグメントを、前記２Ｄ部分のための前記確定スケジュールおよび前記メタデータ部分のための前記確定スケジュールで送信するための時点として選択することを含む、付記８に記載のデバイス。
（付記１０）
２Ｄクライアントおよび３Ｄクライアントから要求を受け取り、かつ、受け取った前記要求に応じて前記要求を前記２Ｄスケジューリングモジュール（１０２）および前記メタデータスケジューリングモジュール（１０３）に転送するための要求フォーキングモジュール（１０４）をさらに備える、付記７に記載のデバイス。
（付記１１）
前記２Ｄ部分または前記メタデータ部分の前記少なくとも１つのセグメントのうちの１つが送信されない場合、前記セグメントをいつ得ることができるか、また、同じセグメントのためのより早い要求に応答するどのマルチキャストストリームで得ることができるかについて知らせるための通知モジュールをさらに備える、付記７に記載のデバイス。

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5A】

【図5B】