本発明の一実施例によれば、360°ビデオ送信装置により行われる360°ビデオデータ処理方法が提供される。この方法は、少なくとも一つのイメージ獲得装置によりキャプチャーされた360°ビデオデータを得る段階、360°ビデオデータを処理して全方向イメージ(omnidirectional image)を含む2次元(two−dimensional)ピクチャを導き出す段階、360°ビデオデータに関するメタデータを生成する段階、2次元ピクチャに関する情報を符号化する段階、及び2次元ピクチャに関する情報及びメタデータに基づいてカプセル化(encapsulation)を行う段階を含み、このメタデータは360°ビデオデータ内のビューポイントグループに含まれた少なくとも一つのビューポイントが互いに非近接(non−contiguous)であるか否かを示す非近接フラグ情報を含むことを特徴とする。
以下の技術的特徴はMPEG(Moving Picture Experts Group)標準化機構による標準規格などに適用でき、ビデオ、イメージ又はオーディオを扱う技術分野で利用することができる。例えば、以下に説明する方法又は実施例は、MPEG−I標準(ISO/IEC23090)又はMPEG−I標準(ISO/IEC23090)以後の次世代標準の開示内容に関連する。
本発明は、多様な変更を加えることができ、様々な実施例を有することができ、特定の実施例を図面に例示して詳細に説明する。しかし、これは本発明を特定の実施形態に限定するものではない。本明細書で使用する用語は、単に特定の実施例を説明するために使われたものであり、本発明の技術的思想を限定するために使われるものではない。単数の表現は、文脈上明白に異なる意味ではない限り、複数の表現を含む。本明細書で「含む」又は「有する」などの用語は、明細書上に記載された特徴、数字、ステップ、動作、構成要素、部品又はこれらを組合せたものが存在することを指定するものであり、一つ又はそれ以上の他の特徴、数字、ステップ、動作、構成要素、部品又はこれらを組合せたものの存在又は付加の可能性を予め排除しないと理解しなければならない。
一方、本発明で説明される図面上の各構成は、互いに異なる特徴的な機能に関する説明の便宜のために独立的に図示したものであり、各構成が互いに別個のハードウェアや別個のソフトウェアで具現されるということを意味しない。例えば、各構成のうち、二つ以上の構成が統合されて一つの構成になることもでき、一つの構成が複数の構成に分けられることもできる。各構成が統合及び/又は分離された実施例も本発明の本質から外れない限り本発明の権利範囲に含まれる。
以下、添付図面を参照して、本発明の好ましい実施例についてより詳しく説明する。以下、図面上、同一の構成要素に対しては同一の参照符号を使用し、同一の構成要素に対して重複した説明は省略する。
図1は一実施例による360°コンテンツ提供のための全体アーキテクチャを示す図である。
この明細書において、“イメージ(image)”は停止映像及び時間の流れによる一連の停止映像の集合であるビデオを含む概念を意味する。また、“ビデオ(video)”も必ず時間の流れによる一連の停止映像の集合のみを意味することではなく、場合によっては停止映像がビデオに含まれる概念として解釈することができる。
ユーザに仮想現実(Virtual Reality、VR)を提供するために、360°コンテンツを提供する方案が考えられる。ここで、360°コンテンツは3DoF(three Degrees of Freedom)コンテンツとも呼ばれ、VRは実際又は仮想の環境を複製(replicates)するために技術とその環境を意味する。VRは人工的にユーザに感覚的経験を提供し、これによりユーザは電子的にプロジェクションされた環境にいるような経験をすることができる。
360°コンテンツはVRを具現、提供するためのコンテンツ全般を意味し、360°ビデオ及び/又は360°オーディオを含む。360°ビデオ及び/又は360オーディオは、3次元ビデオ及び/又は3次元オーディオとも呼ばれる。360°ビデオはVRを提供するために必要な、全方向(360°)が同時にキャプチャー又は再生されるビデオ又はイメージコンテンツを意味する。以下、360°ビデオとは360°ビデオを意味する。360°ビデオは3Dモデルによって様々な形態の3D空間上に表されるビデオ又はイメージを意味し、例えば、360°ビデオは球形(Spherical)面上に表されることができる。360°オーディオもVRを提供するためのオーディオコンテンツであって、音響発生地が3次元の特定の空間上に位置すると認知できる、空間的(Spatial)オーディオコンテンツを意味する。360オーディオは3次元オーディオとも呼ばれる。360°コンテンツは生成、処理されてユーザに送信され、ユーザは360°コンテンツを用いてVR経験を消費する。360ビデオは全方向(omnidirectional)ビデオとも呼ばれ、360イメージは全方向イメージとも呼ばれる。
360°ビデオを提供するために、まず1つ以上のカメラにより360°ビデオがキャプチャーされる。キャプチャーされた360°ビデオは一連の過程を経て送信され、受信側では受信されたデータを再び元来の360°ビデオに加工してレンダリングすることができる。これにより360°ビデオがユーザに提供される。
具体的には、360°ビデオ提供のための全過程はキャプチャー過程(process)、準備過程、送信過程、プロセシング過程、レンダリング過程及び/又はフィードバック過程を含む。
キャプチャー過程は、1つ以上のカメラで複数のビューポイントの各々に対するイメージ又はビデオをキャプチャーする過程を意味する。キャプチャー過程により図示された図1の(110)のようなイメージ/ビデオデータが生成される。図示した図1の(110)の各平面は各ビューポイントに対するイメージ/ビデオを意味する。このキャプチャーされた複数のイメージ/ビデオをロー(raw)データとも言える。キャプチャー過程ではキャプチャーに関連するメタデータが生成されることができる。
このキャプチャーのためには、VRのための特殊カメラが使用される。実施例によってコンピューターで生成された仮想の空間に対する360°ビデオを提供しようとする場合、実際カメラによるキャプチャーではないことがある。この場合、単に関連データが生成される過程をもって該当キャプチャー過程に代えることができる。
準備過程は、キャプチャーされたイメージ/ビデオ及びキャプチャー過程で発生したメタデータを処理する過程である。キャプチャーされたイメージ/ビデオは、この準備過程において、スティチング(Stitching)過程、プロジェクション(projection)過程、リージョンごとのパッキング過程(Region−wise Packing)及び/又は符号化過程などを経る。
まず各々のイメージ/ビデオはスティチング(Stitching)過程を経る。スティチング過程は、各々のキャプチャーされたイメージ/ビデオを連結して1つのパノラマイメージ/ビデオ又は球形のイメージ/ビデオを形成する過程である。
その後、スティチングされたイメージ/ビデオは、プロジェクション(Projection)過程を経る。プロジェクション過程において、スティチングされたイメージ/ビデオは2Dイメージ上にプロジェクションされる。この2Dイメージは、文脈により2Dイメージフレームとも呼ばれる。2Dイメージにプロジェクションすることは、2Dイメージにマッピングするとも表現できる。プロジェクションされたイメージ/ビデオデータは、図示した図1の(120)のような2Dイメージ形態になることもできる。
2Dイメージ上にプロジェクションされたビデオデータは、ビデオコーディング効率などを高めるために、リージョンごとのパッキング過程(Region−wise Packing)を経る。リージョンごとのパッキングとは、2Dイメージ上にプロジェクションされたビデオデータをリージョン(Region)ごとに分けて処理を加える過程を意味する。ここで、リージョン(Region)とは、360°ビデオデータがプロジェクションされた2Dイメージが分かれた領域を意味する。このリージョンは、実施例によって、2Dイメージを均等に分けて区分するか、或いは任意に分かれて区分されることができる。また実施例によってリージョンはプロジェクションスキームにより区分されることもできる。リージョンごとのパッキング過程は選択的(optional)過程であり、準備過程で省略することもできる。
実施例によって、この処理過程は、ビデオコーディングの効率を高めるために、各々のリージョンを回転したり2Dイメージ上に再配列したりする過程を含む。例えば、リージョンを回転してリージョンの特定の辺を互いに近接させることにより、コーディング時の効率を向上させることができる。
実施例によって、この処理過程は、360°ビデオ上の領域ごとに解像度(resolution)を差等化するために、特定のリージョンに対する解像度を上げるか或いは下げる過程を含む。例えば、360°ビデオ上において相対的にもっと重要な領域に該当するリージョンは、他のリージョンより解像度を上げることができる。2Dイメージ上にプロジェクションされたビデオデータ又はリージョンごとのパッキングされたビデオデータは、ビデオコーデックを通じた符号化過程を経ることができる。
実施例によって、準備過程はさらにエディット(editing)過程などを含むことができる。このエディット過程においては、さらにプロジェクション前後のイメージ/ビデオデータに対する編集などが行われる。準備過程でも同様に、スティチング/プロジェクション/符号化/エディットなどに関するメタデータが生成されることができる。また、2Dイメージ上にプロジェクションされたビデオデータの初期ビューポイント、或いはROI(Region of Interest)などに関するメタデータが生成されることができる。
送信過程は、準備過程を経たイメージ/ビデオデータ及びメタデータを処理して送信する過程である。送信のために任意の送信プロトコルによる処理が行われる。送信のための処理が行われたデータは、放送網及び/又は広帯域を介して伝達される。このデータはオン・デマンド(On Demand)方式で受信側に伝達されることもできる。受信側では様々な経路を通じて該当データを受信する。
プロセシング過程は、受信したデータを復号し、プロジェクションされているイメージ/ビデオデータを3Dモデル上にリプロジェクション(Re−projection)する過程を意味する。この過程において、2Dイメージ上にプロジェクションされているイメージ/ビデオデータが3D空間上にリプロジェクションされることができる。この過程を文脈により、マッピング、プロジェクションとも呼ぶ。この時、マッピングされる3D空間は、3Dモデルによって異なる形態を有する。例えば、3Dモデルとしては、球形(Sphere)、キューブ(Cube)、シリンダー(Cylinder)又はピラミッド(Pyramid)などがある。
実施例によって、プロセシング過程は、さらにエディット(editing)過程、アップスケーリング(upscaling)過程など含む。このエディット過程においては、さらにリプロジェクション前後のイメージ/ビデオデータに対する編集などが行われる。イメージ/ビデオデータが縮小されている場合は、アップスケーリング過程においてサンプルのアップスケーリングによりそのサイズを拡大することができる。必要な場合、ダウンスケーリングによりサイズを縮小する作業を行うこともできる。
レンダリング過程は、3D空間上にリプロジェクションされたイメージ/ビデオデータをレンダリングしてディスプレイする過程を意味する。リプロジェクションとレンダリングを合わせて、3Dモデル上にレンダリングするとも表現できる。3Dモデル上にリプロジェクションされた(又は3Dモデル上にレンダリングされた)イメージ/ビデオは、図示された図1の(130)のような形態を有することができる。図示された図1の(130)は球形(Sphere)の3Dモデルにリプロジェクションされた場合である。ユーザはVRディスプレイなどによりレンダリングされたイメージ/ビデオの一部領域を見ることができる。この時、ユーザが見る領域は図示された図1(140)のような形態であることができる。
フィードバック過程は、ディスプレイ過程から得られる様々なフィードバック情報を送信側に伝達する過程を意味する。フィードバック過程により、360°ビデオの消費において双方向性(Interactivity)が提供される。実施例によって、フィードバック過程でヘッド方向(Head Orientation)情報、ユーザが現在見ている領域を示すビューポート(Viewport)情報などが送信側に伝達される。実施例によって、ユーザはVR環境上に具現されたものと相互作用することもできるが、この場合、その相互作用に関連する情報がフィードバック過程で送信側或いはサービス供給者に伝達される。実施例によって、フィードバック過程は省略できる。
ヘッド方向情報はユーザのヘッド位置、角度、動きなどに関する情報を意味する。これらの情報に基づいてユーザが現在360°ビデオで見ている領域に関する情報、即ち、ビューポート情報を計算することができる。
ビューポート情報は、現在ユーザが360°ビデオで見ている領域に関する情報である。これによりゲイズ分析(Gaze Analysis)が行われ、ユーザがどのような方式で360°ビデオを消費するか、360°ビデオのどの領域をどのくらい凝視するかなどを確認できる。ゲイズ分析は、受信側で行われて送信側にフィードバックチャネルを介して伝達される。VRディスプレイなどの装置は、ユーザのヘッド位置/方向、装置が支援する垂直(vertical)或いは水平(Horizontal)FOVなどに基づいて、ビューポート領域を抽出することができる。
実施例によって、上述したフィードバック情報は送信側に伝達されるだけではなく、受信側で消費されることもできる。即ち、上述したフィードバック情報を用いて受信側の復号、リプロジェクション、レンダリング過程などが行われる。例えば、ヘッド方向情報及び/又はビューポート情報を用いて現在ユーザが見ている領域に対する360°ビデオのみを優先して復号及びレンダリングすることができる。
ここで、ビューポート(viewport)又はビューポート領域は、ユーザが360°ビデオで見ている領域を意味する。ビューポイント(viewpoint)はユーザが360°ビデオで見ているところであって、ビューポート領域の真ん中を意味する。即ち、ビューポートはビューポイントを中心とする領域であるが、その領域が占めるサイズ、形態などは後述するFOV(Field Of View)により決定される。
上述した360°ビデオ提供のための全体アーキテクチャ内において、キャプチャー/プロジェクション/符号化/送信/復号/リプロジェクション/レンダリングの一連の過程を経るイメージ/ビデオデータを、360°ビデオデータと呼ぶ。また360°ビデオデータという用語は、かかるイメージ/ビデオデータに関連するメタデータ或いはシグナリング情報を含む概念としても使用される。
上記オーディオ又はビデオなどのメディアデータを格納して送信するために、定型化されたメディアファイルフォーマットを定義できる。実施例によってメディアファイルは、ISO BMFF(ISO base media file format)に基づくファイルフォーマットを有することができる。
図2及び図3は一部の一実施例によるメディアファイルの構造を示す図である。
本発明によるメディアファイルは、少なくとも一つ以上のボックスを含む。ここで、ボックス(box)は、メディアデータ又はメディアデータに関連するメタデータなどを含むデータブロック或いはオブジェクトである。複数のボックスは互いに階層的構造を有し、これによりデータが分類されてメディアファイルが大容量メディアデータの格納及び/又は送信に適合した形態になる。またメディアファイルは、ユーザがメディアコンテンツの特定の地点に移動するなど、メディア情報への接近に容易な構造を有する。
一実施例によるメディアファイルはftypボックス、moovボックス及び/又はmdatボックスを含む。
ftypボックス(ファイルタイプボックス)は、該当メディアファイルに対するファイルタイプ又は互換性関連情報を提供する。ftypボックスは該当メディアファイルのメディアデータに対する構成バージョン情報を含む。復号器はftypボックスを参照して該当メディアファイルを区分することができる。
moovボックス(ムービーボックス)は、該当メディアファイルのメディアデータに関するメタデータを含むボックスである。moovボックスは全てのメタデータのためのコンテナの役割を果たす。moovボックスはメタデータ関連ボックスのうち、最上位階層のボックスである。実施例によって、moovボックスはメディアファイル内に一つのみ存在する。
mdatボックス(メディアデータボックス)は、該当メディアファイルの実際メディアデータを入れるボックスである。メディアデータはオーディオサンプル及び/又はビデオサンプルを含むが、mdatボックスはかかるメディアサンプルを入れるコンテナの役割を果たす。
実施例によっては、上述したmoovボックスは、さらにmvhdボックス、trakボックス及び/又はmvexボックスなどを下位ボックスとして含むことができる。
mvhdボックス(ムービーヘッダーボックス)は、該当メディアファイルに含まれるメディアデータのメディアプレゼンテーション関連情報を含む。即ち、mvhdボックスは該当メディアプレゼンテーションのメディア生成時間、変更時間、時間規格、期間などの情報を含む。
trakボックス(トラックボックス)は、該当メディアデータのトラックに関連する情報を提供する。trakボックスはオーディオトラック又はビデオトラックに対するストリーム関連情報、プレゼンテーション関連情報、アクセス関連情報などの情報を含む。Trakボックスはトラックの数によって複数個存在する。
trakボックスは、実施例によって、さらにtkhdボックス(トラックヘッダボックス)を下位ボックスとして含む。tkhdボックスはtrakボックスが示す該当トラックに関する情報を含む。tkhdボックスは該当トラックの生成時間、変更時間、トラック識別子などの情報を含む。
mvexボックス(ムービー延長(extend)ボックス)は、該当メディアファイルに後述するmoofボックスがあり得ることを指示する。特定トラックの全てのメディアサンプルを知るために、moofボックスをスキャンする必要がある。
一実施例によるメディアファイルは、実施例によって、複数のフラグメントに分かれることができる(200)。これにより、メディアファイルが分割されて格納又は送信される。メディアファイルのメディアデータ(mdatボックス)は複数のフラグメントに分かれ、各々のフラグメントはmoofボックスと分かれたmdatボックスを含む。実施例によって、フラグメントを活用するためには、ftypボックス及び/又はmoovボックスの情報が必要である。
moofボックス(ムービーフラグメントボックス)は、該当フラグメントのメディアデータに関するメタデータを提供する。moofボックスは該当フラグメントのメタデータ関連ボックスのうちの最上位階層のボックスである。
mdatボックス(メディアデータボックス)は、上述したように、実際のメディアデータを含む。このmdatボックスは、各々の該当フラグメントに該当するメディアデータのメディアサンプルを含む。
実施例によって、上述したmoofボックスは、さらにmfhdボックス及び/又はtrafボックスなどを下位ボックスとして含むことができる。
mfhdボックス(ムービーフラグメントヘッダボックス)は、分割された複数のフラグメントの連関性に関連する情報を含む。mfhdボックスはシーケンス番号(Sequence number)を含み、該当フラグメントのメディアデータが分割された何番目のデータであるかを示す。また、mfhdボックスを用いて、分割されたデータのうち、漏れたものがあるか否かを確認することができる。
trafボックス(トラックフラグメントボックス)は、該当トラックフラグメントに関する情報を含む。trafボックスは該当フラグメントに含まれる分割されたトラックフラグメントに関するメタデータを提供する。trafボックスは該当トラックフラグメント内のメディアサンプルが復号化/再生されるようにメタデータを提供する。trafボックスはトラックフラグメントの数によって複数個が存在することができる。
実施例によって、上述したtrafボックスは、さらにtfhdボックス及び/又はtrunボックスなどを下位ボックスとして含むことができる。
tfhdボックス(トラックフラグメントヘッダーボックス)は、該当トラックフラグメントのヘッダー情報を含む。tfhdボックスは上述したtrafボックスが示すトラックフラグメントのメディアサンプルに対して、基本的なサンプルサイズ、期間、オフセット、識別子などの情報を提供する。
trunボックス(トラックフラグメントランボックス)は、該当トラックフラグメント関連情報を含む。trunボックスはメディアサンプルごとの期間、サイズ、再生時点などのような情報を含む。
上述したメディアファイル或いはメディアファイルのフラグメントは、セグメントで処理されて送信されることができる。セグメントには初期化セグメント(initialization Segment)及び/又はメディアセグメント(media Segment)がある。
図示された実施例(210)のファイルは、メディアデータを除いて、メディア復号器の初期化に関連する情報などを含むファイルである。このファイルは、例えば、上述した初期化セグメントに該当する。初期化セグメントは上述したftypボックス及び/又はmoovボックスを含む。
図示された実施例(220)のファイルは、上述したフラグメントを含むファイルである。このファイルは、例えば、上述したメディアセグメントに該当する。メディアセグメントは上述したmoofボックス及び/又はmdatボックスを含む。さらにメディアセグメントはstypボックス及び/又はsidxボックスを含むことができる。
stypボックス(セグメントタイプボックス)は、分割されたフラグメントのメディアデータを識別するための情報を提供する。stypボックスは分割されたフラグメントに対して、上述したftypボックスのような役割を果たす。実施例によって、stypボックスはftypボックスと同じフォーマットを有することができる。
sidxボックス(セグメントインデックスボックス)は、分割されたフラグメントに対するインデックスを示す情報を提供する。これにより、該当分割されたフラグメントが何番目のフラグメントであるかが指示される。
実施例によって(230)、さらにssixボックスを含むことができるが、ssixボックス(サブセグメントインデックスボックス)は、セグメントがサブセグメントにさらに分かれる場合において、そのサブセグメントのインデックスを示す情報を提供する。
メディアファイル内のボックスは、図示された実施例(250)のようなボックス或いはフルボックス(FullBox)の形態に基づいて、より拡張した情報を含むことができる。この実施例において、sizeフィールド、largesizeフィールドは該当ボックスの長さをバイト単位などで示す。versionフィールドは該当ボックスフォーマットのバージョンを示す。typeフィールドは該当ボックスのタイプ或いは識別子を示す。flagsフィールドは該当ボックスに関連するフラッグなどを示す。
一方、一実施例による360°ビデオに対するフィールド(属性)は、DASH基盤の適応型(Adaptive)ストリーミングモデルに含まれて伝達されることができる。
図4はDASH基盤の適応型ストリーミングモデルの全般的な動作の一例を示す図である。
示された実施例(400)によるDASH基盤の適応型ストリーミングモデルは、HTTPサーバーとDASHクライアントの間の動作について記載している。ここで、DASH(Dynamic Adaptive Streaming over HTTP)は、HTTP基盤の適応型ストリーミングを支援するためのプロトコルであって、ネットワーク状況によって動的にストリーミングを支援する。これにより、AVコンテンツ再生を続けて提供することができる。
まずDASHクライアントはMPDを得ることができる。MPDはHTTPサーバーなどのサービス供給者から伝達される。DASHクライアントはMPDに記載されたセグメントへの接近情報を用いてサーバーに該当セグメントを要請することができる。ここで、この要請はネットワーク状態を反映して行われる。
DASHクライアントは該当セグメントを得た後、これをメディアエンジンで処理して画面にディスプレイする。DASHクライアントは再生時間及び/又はネットワーク状況などを実時間に反映して、必要なセグメントを要請して得ることができる(Adaptive Streaming)。これにより、コンテンツを続けて再生することができる。
MPD(Media Presentation Description)は、DASHクライアントがセグメントを動的に獲得するための詳細情報を含むファイルであり、XML形態で表現できる。
DASHクライアントコントローラー(DASH Client Controller)は、ネットワーク状況を反映してMPD及び/又はセグメントを要請するコマンドを生成する。また、このコントローラーは得られた情報をメディアエンジンなどの内部ブロックで使用できるように制御する。
MPDパーサー(Parser)は得られたMPDを実時間にパーシングする。これにより、DASHクライアントコントローラーは必要なセグメントを得るコマンドを生成することができる。
セグメントパーサーは得られたセグメントを実時間にパーシングする。セグメントに含まれた情報によってメディアエンジンなどの内部ブロックは特定の動作を行うことができる。
HTTPクライアントは必要なMPD及び/又はセグメントなどをHTTPサーバーに要請する。またHTTPクライアントはサーバーから獲得したMPD及び/又はセグメントをMPDパーサー又はセグメントパーサーに伝達する。
メディアエンジン(Media Engine)はセグメントに含まれたメディアデータを用いてコンテンツを画面上に示す。この時、MPDの情報が活用される。
DASHデータモデルは階層的構造(410)を有することができる。メディアプレゼンテーションはMPDにより記述される。MPDはメディアプレゼンテーションを形成する複数の区間(Period)の時間的なシーケンスを記述する。ピリオドはメディアコンテンツの一区間を示す。
1つの区間において、データはアダプテーションセットに含まれることができる。アダプテーションセットは、互いに交換可能な複数のメディアコンテンツコンポーネントの集合である。アダプテーションはレプリゼンテーションの集合を含む。レプリゼンテーションはメディアコンテンツコンポーネントに該当する。1つのレプリゼンテーション内において、コンテンツは複数のセグメントに時間的に分かれる。これは適切な接近性と伝達(delivery)のためである。各々のセグメントに接近するために、各セグメントのURLが提供される。
MPDはメディアプレゼンテーションに関連する情報を提供し、期間エレメント、アダプテーションセットエレメント、レプリゼンテーションエレメントは各々、該当期間、アダプテーションセット、レプリゼンテーションについて記述できる。レプリゼンテーションはサブ−レプリゼンテーションに分かれるが、サブ−レプリゼンテーションエレメントは該当サブ−レプリゼンテーションについて記述することができる。
ここで、共通(Common)属性/エレメントが定義されるが、これらはアダプテーションセット、レプリゼンテーション、サブ−レプリゼンテーションなどに適用できる(含まれることができる)。共通属性/エレメントのうちには、エッセンシャルプロパティー(Essential Property)及び/又は補足プロパティー(Supplemental Property)があり得る。
エッセンシャルプロパティーは、該当メディアプレゼンテーション関連データを処理するにおいて、必須であると思われるエレメントを含む情報である。補足プロパティーは該当メディアプレゼンテーション関連データを処理するにおいて、使用可能なエレメントを含む情報である。実施例によって、後述するディスクリプタは、MPDを通じて伝達される場合、エッセンシャルプロパティー及び/又は補足プロパティー内に定義されて伝達される。
図5は一実施例による360ビデオ送信装置の構成を概略的に説明する図である。
一実施例による360°ビデオ送信装置は、上述した準備過程或いは送信過程に関連する動作を行う。360°ビデオ送信装置は、データ入力部、ステッチャー(Stitcher)、プロジェクション処理部、リージョンごとのパッキング処理部(図示せず)、メタデータ処理部、(送信側)フィードバック処理部、データ符号器、カプセル化処理部、送信処理部及び/又は送信部を内/外部エレメントとして含む。
データ入力部にはキャプチャーされた各ビューポイントに対するイメージ/ビデオが入力される。このビューポイントごとのイメージ/ビデオは、一つ以上のカメラによりキャプチャーされたイメージ/ビデオである。またデータ入力部にはキャプチャー過程で発生したメタデータが入力される。データ入力部は入力された視点ごとのイメージ/ビデオをステッチャーに伝達し、キャプチャー過程のメタデータをシグナリング処理部に伝達する。
ステッチャーはキャプチャーされた視点ごとのイメージ/ビデオに対するスティチング作業を行う。ステッチャーはスティチングされた360°ビデオデータをプロジェクション処理部に伝達する。必要な場合、ステッチャーはメタデータ処理部から必要なメタデータを受けてスティチング作業に使用する。ステッチャーはスティチング過程で発生したメタデータをメタデータ処理部に伝達する。スティチング過程のメタデータとしては、スティチングが行われたか否か、スティチングタイプなどの情報がある。
プロジェクション処理部はスティチングされた360°ビデオデータを2Dイメージ上にプロジェクションする。プロジェクション処理部は様々なスキーム(Scheme)によってプロジェクションを行うが、これについては後述する。プロジェクション処理部は各視点ごとの360°ビデオデータの該当深さを考慮してマッピングを行う。必要な場合、プロジェクション処理部はメタデータ処理部からプロジェクションに必要なメタデータを受けてプロジェクション作業に使用する。プロジェクション処理部はプロジェクション過程で発生したメタデータをメタデータ処理部に伝達する。プロジェクション処理部のメタデータとしては、プロジェクションスキームの種類などがある。
リージョンごとのパッキング処理部(図示せず)は上述したリージョンごとのパッキング過程を行う。即ち、リージョンごとのパッキング処理部はプロジェクションされた360°ビデオデータをリージョンごとに分け、各リージョンを回転、再配列するか、或いは各リージョンの解像度(resolution)を変更するなどの処理を行う。上述したように、リージョンごとのパッキング過程は選択的(optional)な過程であり、リージョンごとのパッキングが行われない場合は、リージョンごとのパッキング処理部は省略できる。必要な場合、リージョンごとのパッキング処理部はメタデータ処理部からリージョンごとのパッキングに必要なメタデータを受けてリージョンごとのパッキング作業に使用することができる。リージョンごとのパッキング処理部はリージョンごとのパッキング過程で発生したメタデータをメタデータ処理部に伝達する。リージョンごとのパッキング処理部のメタデータとしては、各リージョンの回転程度、サイズなどがある。
上述したステッチャー、プロジェクション処理部及び/又はリージョンごとのパッキング処理部は、実施例によっては、一つのハードウェアコンポーネントで行われることもできる。
メタデータ処理部は、キャプチャー過程、スティチング過程、プロジェクション過程、リージョンごとのパッキング過程、符号化過程、カプセル化過程及び/又は送信のための処理過程で発生し得るメタデータを処理する。メタデータ処理部では、かかるメタデータを用いて360°ビデオ関連メタデータを生成する。実施例によって、メタデータ処理部は360°ビデオ関連メタデータをシグナリングテーブルの形態で生成することもできる。シグナリング文脈により、360°ビデオ関連メタデータは、メタデータ又は360°ビデオ関連シグナリング情報とも呼ばれる。また、メタデータ処理部は獲得又は生成したメタデータを必要によって360°ビデオ送信装置の内部エレメントに伝達する。メタデータ処理部は360°ビデオ関連メタデータが受信側に送信されるように、データ符号器、カプセル化処理部及び/又は送信処理部に伝達することができる。
データ符号器は、2Dイメージ上にプロジェクションされた360°ビデオデータ及び/又はリージョンごとのパッキングされた360°ビデオデータを符号化する。360°ビデオデータは様々なフォーマットに符号化できる。
カプセル化処理部は、符号化された360ビデオデータ及び/又は360ビデオ関連メタデータをファイルなどの形態でカプセル化することができる。ここで、360ビデオ関連メタデータは、上述したメタデータ処理部から伝達されたものである。カプセル化処理部は、該当データをISOBMFF、CFFなどのファイルフォーマットにカプセル化したり、その他のDASHセグメントなどの形態に処理したりすることができる。カプセル化処理部は、実施例によって360ビデオ関連メタデータをファイルフォーマットに含ませることができる。360関連メタデータは、例えば、ISOBMFFファイルフォーマット上の様々なレベルのボックスに含まれるか、或いはファイル内で所定のトラック内のデータに含まれる。実施例によって、カプセル化処理部は、360ビデオ関連メタデータ自体をファイルにカプセル化する。送信処理部は、ファイルフォーマットによってカプセル化された360ビデオデータに送信のための処理を行う。送信処理部は、任意の送信プロトコルによって360ビデオデータを処理する。送信のための処理は、放送網を介した伝達のための処理、広帯域を介した伝達のための処理を含む。実施例によって、送信処理部には、360ビデオデータだけではなく、メタデータ処理部から360ビデオ関連メタデータが伝達され、そこに送信のための処理を加えることもできる。
送信部は送信処理された360°ビデオデータ及び/又は360°ビデオ関連メタデータを放送網及び/又は広帯域を介して送信する。送信部は放送網を介した送信のためのエレメント及び/又は広帯域による送信のためのエレメントを含む。
360°ビデオの送信装置の一実施例によれば、さらに360°ビデオの送信装置は、データ格納部(図示せず)を内/外部エレメントとして含む。データ格納部は、符号化された360°ビデオデータ及び/又は360°ビデオ関連メタデータを送信処理部に伝達する前に格納する。このデータが格納される形態はISOBMFFなどのファイル形態である。実時間に360°ビデオを送信する場合にはデータ格納部が不要であるが、オン・デマンド、NRT(Non Real Time)、広帯域などを介して伝達する場合にはカプセル化された360データがデータ格納部に一定期間格納された後に送信されることができる。
360ビデオの送信装置の他の実施例によれば、さらに360ビデオの送信装置は、(送信側)フィードバック処理部及び/又はネットワークインターフェース(図示せず)を内/外部エレメントとして含む。ネットワークインターフェースには、本発明による360ビデオ受信装置からフィードバック情報が伝達され、これを送信側フィードバック処理部に伝達する。送信側フィードバック処理部は、フィードバック情報をステッチャー、プロジェクション処理部、リージョンごとのパッキング処理部、データ符号器、カプセル化処理部、メタデータ処理部及び/又は送信処理部に伝達する。実施例によって、フィードバック情報はメタデータ処理部に一旦伝達された後、再び各々の内部エレメントに伝達される。フィードバック情報が伝達された内部エレメントは、今後の360°ビデオデータ処理にフィードバック情報を反映することができる。
360ビデオの送信装置のさらに他の実施例によれば、リージョンごとのパッキング処理部は、各リージョンを回転して2Dイメージ上にマッピングする。この時、各リージョンは互いに異なる方向、互いに異なる角度に回転して2Dイメージ上にマッピングされる。リージョンの回転は、360°ビデオデータが球面上においてプロジェクション前に隣接した部分、スティチングされた部分などを考慮して行われる。リージョンの回転に関する情報、即ち、回転方向、角度などは、360ビデオ関連メタデータによりシグナリングされる。360ビデオの送信装置のさらに他の実施例によれば、データ符号器は各リージョンごとに異なるように符号化を行う。データ符号器は、特定のリージョンは高品質に、他のリージョンは低品質に符号化する。送信側のフィードバック処理部は、360ビデオの受信装置から伝達されたフィードバック情報をデータ符号器に伝達して、データ符号器がリージョンごとに差等化した符号化方法を使用するようにする。例えば、送信側のフィードバック処理部は受信側から伝達されたビューポート情報をデータ符号器に伝達する。データ符号器はビューポート情報が指示する領域を含むリージョンに対して、他のリージョンよりも高い品質(UHDなど)に符号化することができる。
360°ビデオ送信装置のさらに他の実施例によれば、送信処理部は各リージョンごとに異なるように送信のための処理を行う。送信処理部はリージョンごとに異なる送信パラメータ(モジュレーションオーダ、符号レートなど)を適用して、各リージョンごとに伝達されるデータの剛健性(robustenss)を変更することができる。
この時、送信側のフィードバック処理部は、360°ビデオ受信装置から伝達されたフィードバック情報を送信処理部に伝達して、送信処理部がリージョンごとに差等化した送信処理を行うようにする。例えば、送信側のフィードバック処理部は、受信側から伝達されたビューポート情報を送信処理部に伝達する。送信処理部は該当ビューポート情報が指示する領域を含むリージョンに対して、他のリージョンよりも高い剛健性を有するように送信処理を行う。
上述した360°ビデオ送信装置の内/外部エレメントは、ハードウェアで具現されるハードウェアエレメントである。実施例によって、内/外部エレメントは変更、省略されるか、或いは他のエレメントに代替、統合される。実施例によって、付加エレメントが360ビデオ送信装置に追加されることができる。
図6は一実施例による360ビデオ受信装置の構成を概略的に説明する図である。
一実施例による360ビデオ受信装置は、上述したプロセシング過程及び/又はレンダリング過程に関連する動作を行う。360ビデオ受信装置は、受信部、受信処理部、カプセル除去(decapsulation)処理部、データ復号器、メタデータパーザ、(受信側)フィードバック処理部、リプロジェクション処理部及び/又はレンダラーを内/外部エレメントとして含む。なお、シグナリングパーザはメタデータパーザとも呼ばれる。
受信部は、一実施例による360ビデオ送信装置が送信した360ビデオデータを受信する。送信されるチャネルによって受信部は放送網により360ビデオデータを受信し、広帯域を介して360ビデオデータを受信することもできる。
受信処理部は、受信された360ビデオデータに対して送信プロトコルによる処理を行う。送信側で送信のための処理が行われたことに対応するように、受信処理部は上述した送信処理部の逆過程を行う。受信処理部は得られた360ビデオデータをカプセル除去処理部に伝達し、得られた360ビデオ関連メタデータはメタデータパーザに伝達する。受信処理部が得る360ビデオ関連メタデータはシグナリングテーブルの形態である。
カプセル除去処理部は受信処理部から伝達されたファイル形態の360ビデオデータをカプセル除去する。カプセル除去処理部はISOBMFFなどによるファイルをカプセル除去して、360ビデオデータ或いは360ビデオ関連メタデータを得ることができる。得られた360°ビデオデータはデータ復号器に、得られた360°ビデオ関連メタデータはメタデータパーザに伝達する。カプセル除去処理部が得る360°ビデオ関連メタデータはファイルフォーマット内のボックス或いはトラック形態である。必要な場合、カプセル除去処理部にはメタデータパーザからカプセル除去に必要なメタデータが伝達される。
データ復号器は360ビデオデータに対する復号を行う。データ復号器にはメタデータパーザから復号に必要なメタデータが伝達されることもできる。データ復号過程で得られた360°ビデオ関連メタデータはメタデータパーザに伝達されることもできる。
メタデータパーザは360ビデオ関連メタデータに対するパーシング/復号を行う。メタデータパーザは、得られたメタデータをデータカプセル除去処理部、データ復号器、リプロジェクション処理部及び/又はレンダラーに伝達することができる。
リプロジェクション処理部は復号された360ビデオデータに対してリプロジェクションを行う。リプロジェクション処理部は360ビデオデータを3D空間にリプロジェクションすることができる。3D空間は使用される3Dモデルによって異なる形態を有する。リプロジェクション処理部はメタデータパーザからリプロジェクションに必要なメタデータが伝達されることもできる。例えば、リプロジェクション処理部には使用される3Dモデルのタイプ及びその細部情報に関する情報がメタデータパーザから伝達される。実施例によってリプロジェクション処理部はリプロジェクションに必要なメタデータを用いて、3D空間上の特定の領域に該当する360°ビデオデータのみを3D空間にリプロジェクションすることもできる。
レンダラーはリプロジェクションされた360ビデオデータをレンダリングする。上述したように、360ビデオデータが3D空間上にレンダリングされると表現することもできるが、このように2つの過程が同時に起こる場合、リプロジェクション処理部とレンダラーが統合されて、レンダラーでこれらの全過程が進行されることができる。実施例によって、レンダラーはユーザの視点情報によってユーザが見ている部分のみをレンダリングすることもできる。
ユーザはVRディスプレイなどによりレンダリングされた360ビデオの一部領域を見ることができる。VRディスプレイは360ビデオを再生する装置であって、360ビデオ受信装置に含まれるか(tethered)、又は別途の装置として360ビデオ受信装置に連結される(un−tethered)。
360ビデオ受信装置の一実施例によれば、さらに360°ビデオ受信装置は、(受信側)フィードバック処理部及び/又はネットワークインターフェース(図示せず)を内外部エレメントとして含む。受信側のフィードバック処理部はレンダラー、リプロジェクション処理部、データ復号器、カプセル除去処理部及び/又はVRディスプレイからフィードバック情報を得て処理することができる。フィードバック情報はビューポート情報、ヘッド方向情報、ゲイズ(Gaze)情報などを含む。ネットワークインターフェースはフィードバック情報を受信側のフィードバック処理部から受けて、それを360ビデオ送信装置に送信する。
上述したように、フィードバック情報は送信側に伝達されるだけではなく、受信側で消費されることもできる。受信側のフィードバック処理部は得られたフィードバック情報を360ビデオ受信装置の内部エレメントに伝達して、レンダリングなどの過程に反映させることができる。受信側のフィードバック処理部はフィードバック情報をレンダラー、リプロジェクション処理部、データ復号器及び/又はカプセル除去処理部に伝達する。例えば、レンダラーはフィードバック情報を活用してユーザが見ている領域を優先してレンダリングする。また、カプセル除去処理部、データ復号器などは、ユーザが見ている領域或いは見る領域を優先してカプセル除去、復号することができる。
上述した本発明による360ビデオ受信装置の内/外部エレメントは、ハードウェアで具現されるハードウェアエレメントである。実施例によって、内/外部エレメントは変更、省略されるか、又は他のエレメントに代替、統合されることができる。実施例によって、付加エレメントが360ビデオ受信装置に追加されることもできる。
本発明のさらに他の観点は、上記一実施例による360ビデオ受信装置の動作方法は、360ビデオを送信する方法及び360ビデオを受信する方法に関連する。一実施例による360ビデオを送信/受信する方法は、各々上述した一実施例による360°ビデオ送信/受信装置又はその装置の実施例により行われる。
上述した一実施例による360ビデオ送信/受信装置、送信/受信方法の各々の実施例及びその内/外部エレメントの各々の実施例を互いに組み合わせることができる。例えば、プロジェクション処理部の実施例とデータ符号器の実施例とを組み合わせて、その場合の数だけの360°ビデオ送信装置の実施例を作ることができる。
図7は一実施例による3D空間を説明するための飛行機主軸(Aircraft Principal Axes)の概念を示す図である。
本発明では3D空間における特定の地点、位置、方向、間隔、領域などを表現するために、飛行機主軸の概念が使用されている。即ち、本発明ではプロジェクション前又はリプロジェクション後の3D空間について記載しており、それに対するシグナリングを行うために飛行機主軸の概念を使用することができる。実施例によっては、X、Y、Z軸を用いる直交座標系又は球座標系を用いた方法が使用されることもできる。
飛行機は3次元に自由に回転できる。3次元をなす軸を各々、ピッチ(pitch)軸、ヨー(yaw)軸及びロール(roll)軸と呼ぶ。本明細書では、これらを簡略にpitch、yaw、roll又はpitch方向、yaw方向、roll方向とも表現する。
一例として、roll軸は、直交座標系のX軸又はback−to−front軸に対応する。又はroll軸は、示された飛行機の主軸概念において、飛行機の先端から後端に続く軸であり、roll方向の回転とは、roll軸を基準とする回転を意味する。roll軸を基準として回転した角度を意味するroll値の範囲は−180°から180°までであり、この時、境界値−180°及び180°はroll値の範囲に含まれる。
他の例として、pitch軸は、直交座標系のY軸又はSide−to−side軸に対応する。又はPitch軸は、飛行機の先端が上/下に回転する方向の基準になる軸を意味する。示された飛行機の主軸概念において、pitch軸は飛行機の翼から翼に続く軸を意味する。pitch軸を基準として回転した角度を意味するpitch値の範囲は−90°から90°までであり、この時、境界値−90°及び90°はpitch値の範囲に含まれる。
さらに他の例として、yaw軸は、直交座標系のZ軸又は垂直軸(vertical axis)に対応する。又はyaw軸は、飛行機の先端が左/右に回転する方向の基準になる軸を意味する。示された飛行機の主軸概念において、yaw軸は飛行機の上から下に続く軸を意味する。yaw軸を基準として回転した角度を意味するyaw値の範囲は−180°から180°までであり、この時、境界値−180°及び180°はyaw値の範囲に含まれる。
一実施例による3D空間において、yaw軸、pitch軸及びroll軸を決定する基準となる中央点(center point)は固定していない。
上述したように、pitch、yaw及びrollの概念により、本発明での3D空間が記載される。
上述したように、2Dイメージ上にプロジェクションされたビデオデータは、ビデオのコーディング効率を高めるために、リージョンごとのパッキング過程(Region−wise Packing)が行われる。リージョンごとのパッキング過程は、2Dイメージ上にプロジェクションされたビデオデータをリージョンごとに分けて処理する過程を意味する。リージョンは360ビデオデータがプロジェクションされた2Dイメージが分けられた領域を示し、2Dイメージが分けられたリージョンはプロジェクションスキームによって区分されることができる。ここで、2Dイメージはビデオフレーム又はフレームとも呼ばれる。
これに関連して、本発明では、プロジェクションスキームによるリージョンごとのパッキング過程に対するメタデータ及びメタデータのシグナリング方法を提案する。メタデータに基づいて、リージョンごとのパッキング過程がより効率的に行われることができる。
図8は360ビデオの処理過程及びプロジェクションフォーマットによるリージョンごとのパッキング過程が適用された2Dイメージを例示する図である。
図8の(a)は入力された360ビデオデータの処理過程を示す。図8の(a)を参照すると、入力された視点の360ビデオデータは様々なプロジェクションスキームによって3Dプロジェクション構造にスティチング及びプロジェクションされ、3Dプロジェクション構造にプロジェクションされた360ビデオデータは2Dイメージで示すことができる。即ち、360ビデオデータがスティチングされて、2Dイメージにプロジェクションされることができる。360ビデオデータがプロジェクションされた2Dイメージは、プロジェクションされたフレーム(projected frame)とも表すことができる。プロジェクションされたフレームでは、上述したリージョンごとのパッキング過程が行われる。即ち、プロジェクションされたフレーム上のプロジェクションされた360ビデオデータを含む領域をリージョンに区分し、各リージョンを回転、再配列又は各リージョンの解像度を変更するなどの処理が行われる。即ち、リージョンごとのパッキング過程は、プロジェクションされたフレームを一つ以上のパッキングされたフレーム(packed frame)にマッピングする過程を示す。リージョンごとのパッキング過程は選択的(optional)なものであり、リージョンごとのパッキング過程が適用されない場合は、パッキングされたフレームとプロジェクションされたフレームが同一であることができる。リージョンごとのパッキング過程が適用される場合には、プロジェクションされたフレームの各リージョンが、パッキングされたフレームのリージョンにマッピングされることができ、プロジェクションされたフレームの各リージョンがマッピングされるパッキングされたフレームのリージョンの位置、模様及びサイズを示すメタデータが導き出されることができる。
図8の(b)及び(c)はプロジェクションされたフレームの各リージョンがパッキングされたフレームのリージョンにマッピングされる例を示す。図8の(b)を参照すると、360ビデオデータはパノラミック(panoramic)プロジェクションスキーム(projection scheme)によって2Dイメージ(又はフレーム)にプロジェクションされることができる。プロジェクションされたフレームの上端面(top)リージョン、中端面(middle)リージョン及び下端面(bottom)リージョンは、リージョンごとのパッキング過程が適用されて右側図のように再配列されることができる。ここで、上端面リージョンは2Dイメージ上でパノラマの上端面を示すリージョンであり、中端面リージョンは2Dイメージ上でパノラマの中端面を示すリージョンであり、下端面リージョンは2Dイメージ上でパノラマの下端面を示すリージョンである。また、図8の(c)を参照すると、360ビデオデータはキュービク(cubic)プロジェクションスキームによって2Dイメージ(又はフレーム)にプロジェクションされることができる。プロジェクションされたフレームの前面(front)リージョン、後面(back)リージョン、上面(top)リージョン、底面(bottom)リージョン、右側面(right)リージョン及び左側面(left)リージョンは、リージョンごとのパッキング過程が適用されて右側図のように再配列されることができる。ここで、前面リージョンは2Dイメージ上でキューブの前面を示すリージョンであり、後面リージョンは2Dイメージ上でキューブの後面を示すリージョンである。上面リージョンは2Dイメージ上でキューブの上面を示すリージョンであり、底面リージョンは2Dイメージ上でキューブの底面を示すリージョンである。また、右側面リージョンは2Dイメージ上でキューブの右側面を示すリージョンであり、左側面リージョンは2Dイメージ上でキューブの左側面を示すリージョンである。
図8の(d)は360ビデオデータがプロジェクションされる様々な3Dプロジェクションフォーマットを示す。図8の(d)を参照すると、3Dプロジェクションフォーマットは四面体(tetrahedron)、キューブ(cube)、八面体(octahedron)、十二面体(dodecahedron)、二十面体(icosahedron)を含む。図8の(d)に示された2Dプロジェクションは3Dプロジェクションフォーマットにプロジェクションされた360ビデオデータを2Dイメージで示したプロジェクションされたフレームを示す。
プロジェクションフォーマットの一例として、一実施例によれば、様々なプロジェクションフォーマット(又はプロジェクションスキーム)のうちの一部又は全部が使用される。360ビデオについてどのプロジェクションフォーマットが使用されたかは、例えば、メタデータのプロジェクションフォーマットフィールドにより指示されることができる。
図9a及び図9bは一部の実施例によるプロジェクションフォーマットを例示する図である。
図9aの(a)は等正方形プロジェクションフォーマットを示す。等正方形プロジェクションフォーマットが使用される場合、球面上の(r、θ0、0)、即ち、θ=θ0、φ=0である点と2Dイメージの中央ピクチャがマッピングされることができる。また、前面カメラの主点(principal point)を球面の(r、0、0)点と仮定することができる。また、φ0=0に固定することができる。従って、XY座標系に変換された値(x、y)は、以下の式によって2Dイメージ上に(X、Y)ピクチャに変換されることができる。
また、2Dイメージの左上端ピクチャをXY座標系の(0,0)に位置させる場合、x軸に対するオフセット値及びy軸に対するオフセット値は以下の式のように示すことができる。
これを用いてXY座標系への返還式を書き換えると、以下の通りである。
例えば、θ0=0である場合、即ち、2Dイメージの中央ピクチャが球面上のθ=0であるデータを指す場合、球面は(0,0)を基準として2Dイメージ上で幅(width)=2Kxπrであり、高さ(height)=Kxπrの領域にマッピングされることができる。球面上でφ=π/2であるデータは、2Dイメージ上の上側辺の全体にマッピングされることができる。また球面上で(r、π/2、0)であるデータは、2Dイメージ上の(3πKxr/2、πKxr/2)の点にマッピングされることができる。
受信側では、2Dイメージ上の360ビデオデータを球面上にリプロジェクション(re−projection)することができる。これを返還式で書くと、以下の通りである。
例えば、2Dイメージ上でXY座標値が(Kxπr,0)であるピクチャは、球面上のθ=θ0、φ=π/2である点にリプロジェクションされることができる。
図9aの(b)はキュービクプロジェクションフォーマットを示す。例えば、スティチングされた360ビデオデータは球面上に示されることができる。プロジェクション処理部はかかる360ビデオデータをキューブ(Cube、立方体)形態に分けて2Dイメージ上にプロジェクションすることができる。球面上の360ビデオデータはキューブの各面に対応して、2Dイメージ上に図9aの(b)左側又は(b)右側に示したようにプロジェクションされることができる。
図9aの(c)はシリンダー型のプロジェクションフォーマットを示す。スティチングされた360ビデオデータが球面上に示されると仮定する時、プロジェクション処理部はかかる360ビデオデータをシリンダー形態に分けて2Dイメージ上にプロジェクションすることができる。球面上の360ビデオデータはシリンダーの側面(side)、上面(top)、底面(bottom)に各々対応し、2Dイメージ上に図8Aの(c)左側又は(c)右側に示したようにプロジェクションされることができる。
図9aの(d)はタイル基盤のプロジェクションフォーマットを示す。タイル基盤(Tile−based)のプロジェクションスキームが使用される場合、上述したプロジェクション処理部は球面上の360ビデオデータを、図9aの(d)に示したように、一つ以上の細部領域に分けて2Dイメージ上にプロジェクションすることができる。この細部領域はタイルとも呼ばれる。
図9bの(e)はピラミッドプロジェクションフォーマットを示す。スティチングされた360ビデオデータが球面上に示されると仮定する時、プロジェクション処理部はかかる360ビデオデータをピラミッド形態であるとして、各面を分けて2Dイメージ上にプロジェクションすることができる。球面上の360ビデオデータは、ピラミッドの底面(front)、ピラミッドの4方向の側面(Left top、Left bottom、Right top、Right bottom)に各々対応し、2Dイメージ上に図8bの(e)左側又は(e)右側に示されたように、プロジェクションすることができる。ここで、底面は正面を見るカメラが得たデータを含む領域である。
図9bの(f)はパノラミックプロジェクションフォーマットを示す。パノラミックプロジェクションフォーマットが使用される場合、上述したプロジェクション処理部は、図9bの(f)に示したように、球面上の360ビデオデータのうち、側面のみを2Dイメージ上にプロジェクションすることができる。これはシリンダー型のプロジェクションスキームにおいて、上面(top)と底面(bottom)が存在しない場合と同様である。
一方、一実施例によれば、スティチング無しにプロジェクションが行われることができる。図9bの(g)はスティチング無しにプロジェクションが行われる場合を示す。スティチング無しにプロジェクションされる場合、上述したプロジェクション処理部は、図9bの(g)に示したように、360ビデオデータをそのまま2Dイメージ上にプロジェクションすることができる。この場合、スティチングは行われず、カメラで得た各々のイメージがそのまま2Dイメージ上にプロジェクションされることができる。
図9bの(g)を参照すると、2つのイメージが2Dイメージ上にスティチング無しにプロジェクションされることができる。各々のイメージは球形カメラ(Spherical camera)(又は魚眼(fish−eye)カメラ)で各センサにより得た魚眼イメージである。上述したように、受信側でカメラセンサから得るイメージデータをスティチングすることができ、スティチングされたイメージデータを球面(Spherical surface)上にマッピングして球形ビデオ(Spherical video)、即ち、360ビデオをレンダリングすることができる。
図10a及び10bは一実施例によるタイル(Tile)を示す図である。
2Dイメージにプロジェクションされた360ビデオデータ又はリージョンごとのパッキングまで行われた360ビデオデータは一つ以上のタイルに区分できる。示された図10aは一つの2Dイメージが16個のタイルに分かれた形態を示している。ここで、2Dイメージとは、上述したプロジェクトフレーム或いはパッキングされたフレーム(packed frame)である。本発明による360ビデオ送信装置のさらに他の実施例によれば、データ符号器は各々のタイルを独立して符号化することができる。
上述したリージョンごとのパッキングとタイリング(Tiling)は区分される。上述したリージョンごとのパッキングは、コーディング効率を高めるために、又は解像度を調整するために、2Dイメージ上にプロジェクションされた360ビデオデータをリージョンで区分して処理することを意味する。タイリングは、データ符号器がプロジェクトフレーム乃至パッキングされたフレームをタイルという区画に分け、該当タイルごとに独立して符号化を行うことを意味する。360ビデオが提供される時、ユーザは360ビデオの全部分を同時に消費しない。タイリングは制限された帯域幅上でユーザが現在見ているビューポートなどの重要部分或いは一定部分に該当するタイルのみを受信側に送信或いは消費することを可能にする。タイリングにより制限された帯域幅をさらに効率的に活用することができ、受信側でも全ての360ビデオデータを一回に全部処理することに比べて演算負荷を減らすことができる。
リージョンとタイルは区分されるので、2つの領域が等しい必要はない。しかし、実施例によっては、リージョンとタイルは同じ領域を称することができる。実施例によって、タイルに合わせてリージョンごとのパッキングが行われてリージョンとタイルが等しいことができる。実施例によっては、プロジェクションスキームによる各面とリージョンが同一である場合、プロジェクションスキームによる各面、リージョン、タイルが同じ領域を称することもできる。文脈によって、リージョンをVRリージョン、タイルをタイルリージョンと呼ぶこともできる。
ROI(Region of Interest)は、360コンテンツ提供者が提案する、ユーザの関心領域を意味する。360コンテンツ提供者は360ビデオを製作する時、ある特定領域にユーザが関心を持つと判断して、それを考慮して360ビデオを製作する。実施例によってROIは360ビデオのコンテンツ上、重要な内容が再生される領域に該当する。
360ビデオ送信/受信装置のさらに他の実施例によれば、受信側フィードバック処理部はビューポート情報を抽出、収集して、それを送信側フィードバック処理部に伝達する。この過程において、ビューポート情報は両側のネットワークインターフェースを用いて伝達される。示された図10aの2Dイメージにビューポート1000が表示されている。ここで、ビューポートは2Dイメージ上の9個のタイルにわたることができる。
この場合、さらに360ビデオ送信装置はタイリングシステムを含む。実施例によってタイリングシステムは、データ符号器の後に位置することもでき(図示した10b)、上述したデータ符号器或いは送信処理部内に含まれることもでき、別途の内/外部エレメントとして360ビデオ送信装置に含まれることもできる。
タイリングシステムでは送信側フィードバック処理部からビューポート情報が伝達される。タイリングシステムはビューポート領域が含まれるタイルのみを選別して送信することができる。図示した図10aの2Dイメージにおいて、総16個のタイルのうち、ビューポート領域(1000)を含む9個のタイルのみが送信されることができる。ここで、タイリングシステムは広帯域によるユニキャスト方式でタイルを送信する。ユーザによってビューポート領域が異なるためである。
この場合、送信側フィードバック処理部はビューポート情報をデータ符号器に伝達することができる。データ符号器はビューポート領域を含むタイルについて他のタイルより高い品質で符号化を行う。
またこの場合、送信側フィードバック処理部はビューポート情報をメタデータ処理部に伝達することができる。メタデータ処理部はビューポート領域に関連するメタデータを360ビデオ送信装置の各内部エレメントに伝達するか、又は360ビデオ関連メタデータに含むことができる。
かかるタイリング方式により、送信帯域幅を節約でき、タイルごとに差等化された処理を行って効率的なデータ処理/送信が可能になる。
上述したビューポート領域に関連する実施例は、ビューポート領域ではない他の特定の領域についても類似方式を適用することができる。例えば、上述したゲイズ分析によりユーザが主に関心を持つと判断された領域、ROI領域、ユーザがVRディスプレイにより360ビデオに接する時、最初に再生される領域(初期視点、Initial Viewpoint)などについても、上述したビューポート領域のような方式の処理が行われる。
360ビデオ送信装置のさらに他の実施例によれば、送信処理部は各タイルごとに異なるように送信のための処理を行うことができる。送信処理部はタイルごとに異なる送信パラメータ(モジュレーションオーダ、符号レートなど)を適用して、各タイルごとに伝達されるデータの剛健性(robustenss)を変更することができる。
この時、送信側のフィードバック処理部は360°ビデオ受信装置から伝達されたフィードバック情報を送信処理部に伝達して、送信処理部がタイルごとの差等化した送信処理を行うようにする。例えば、送信側フィードバック処理部は、受信側から伝達されたビューポート情報を送信処理部に伝達する。送信処理部は該当ビューポート領域を含むタイルに対して、他のタイルよりも高い剛健性を有するように送信処理を行う。
図11は一実施例による360°ビデオ関連のメタデータの一例を示す。
上述したように、360°ビデオ関連のメタデータは、360°ビデオに関する様々なメタデータを含む。文脈によって、360°ビデオ関連のメタデータは、360°ビデオ関連のシグナリング情報とも呼ばれる。360°ビデオ関連のメタデータは、別のシグナリングテーブルに含まれて送信され、DASH MPD内に含まれて送信されることもでき、ISOBMFFなどのファイルフォーマットにボックス形態で含まれて伝達されることもできる。360°ビデオ関連のメタデータがボックス形態で含まれる場合、ファイル、フラグメント、トラック、サンプルエントリー、サンプルなどの様々なレベルに含まれて該当するレベルのデータに関するメタデータを含むことができる。
実施例によって、後述するメタデータの一部は、シグナリングテーブルで構成されて伝達され、残りの一部はファイルフォーマット内にボックス或いはトラック形態で含まれることもできる。
360°ビデオ関連のメタデータの一実施例によれば、360°ビデオ関連のメタデータはプロジェクションスキームなどに関する基本メタデータ、立体(Stereoscopic)関連メタデータ、初期視点(Initial View/Initial Viewpoint)関連メタデータ、ROI関連メタデータ、FOV(Field Of View)関連メタデータ及び/又はクロップされた領域関連のメタデータを含む。実施例によっては360°ビデオ関連のメタデータは、上述したもの以外にも、更なるメタデータを含むことができる。
360°ビデオ関連のメタデータの実施例は、上述した基本メタデータ、立体関連メタデータ、初期視点関連メタデータ、ROI関連メタデータ、FOV関連メタデータ、クロップされた領域関連メタデータ及び/又は後に追加されるメタデータのうちのいずれか一つを含む形態である。本発明による360°ビデオ関連のメタデータの実施例は、各々含む細部メタデータの場合の数によって多様に構成されることができる。実施例によって、360°ビデオ関連のメタデータは、上述したもの以外にも、更なる情報を含むことができる。
stereo_modeフィールドは該当360°ビデオが支援する3Dレイアウトを指示する。このフィールドのみで該当360°ビデオが3Dを支援するか否かを指示することもできるが、この場合、上記is_stereoscopicフィールドは省略できる。このフィールド値が0である場合、該当360°ビデオはモノ(mono)モードである。即ち、プロジェクションされた2Dイメージは、一つのモノビュー(mono view)のみを含む。この場合、該当360°ビデオは3Dを支援しない。
このフィールド値が1、2である場合、該当360°ビデオは各々左右レイアウト、上下レイアウトに従う。左右レイアウト、上下レイアウトは各々、side−by−sideフォーマット、top−bottomフォーマットとも呼ばれる。左右レイアウトの場合、左映像/右映像がプロジェクションされた2Dイメージは、イメージフレーム上で各々左/右に位置することができる。上下レイアウトの場合、左映像/右映像がプロジェクションされた2Dイメージはイメージフレーム上で各々上/下に位置することができる。該当フィールドが残りの値を有する場合には、今後の使用のために残っておくことができる(Reserved for Future Use)。
初期視点関連のメタデータは、ユーザが360°ビデオを最初に再生した時に見る視点(初期視点)に関する情報を含む。初期視点関連のメタデータは、initial_view_yaw_degreeフィールド、initial_view_pitch_degreeフィールド及び/又はinitial_view_roll_degreeフィールドを含む。実施例によって初期視点関連のメタデータは更なる情報を含むこともできる。
initial_view_yaw_degreeフィールド、initial_view_pitch_degreeフィールド、initial_view_roll_degreeフィールドは、該当360°ビデオ再生時の初期視点を示す。即ち、再生時に最初に見られるビューポートの正中央点が、これらの3つのフィールドにより示される。より具体的には、initial_view_yaw_degreeフィールドは、初期視点に対するyaw値を示す。即ち、initial_view_yaw_degreeフィールドは、正中央点の位置をyaw軸を基準として回転した方向(符号)及びその程度(角度)で示すことができる。initial_view_pitch_degreeフィールドは、初期視点に対するpitch値を示す。即ち、initial_view_pitch_degreeフィールドは、正中央点の位置をpitch軸を基準として回転した方向(符号)及びその程度(角度)で示すことができる。また、initial_view_roll_degreeフィールドは、初期視点に対するroll値を示す。即ち、initial_view_roll_degreeフィールドは、正中央点の位置をroll軸を基準として回転した方向(符号)及びその程度(角度)で示すことができる。initial_view_yaw_degreeフィールド、initial_view_pitch_degreeフィールド、initial_view_roll_degreeフィールドに基づいて、該当360°ビデオ再生時の初期視点、即ち、再生時に最初に見られるビューポートの正中央点を示し、これにより360°ビデオの特定の領域がユーザに初期視点にディスプレイされて提供されることができる。また、FOV(Field Of View)により、指示された初期視点を基準とした初期ビューポートの幅及び高さが決定される。即ち、これらの3つのフィールド及びFOV情報を用いて、360°ビデオ受信装置はユーザに360°ビデオの一定領域を初期ビューポートとして提供することができる。
実施例によって、初期視点関連のメタデータが指示する初期視点は、シーン(Scene)ごとに変更可能である。即ち、360コンテンツの時間的流れによって360°ビデオの場面が変更されるが、該当360°ビデオの場面ごとにユーザが最初に見る初期視点或いは初期ビューポートが変更されることができる。この場合、初期視点関連のメタデータは、各場面ごとの初期視点を指示することができる。このために、さらに初期視点関連のメタデータは、該当初期視点が適用される場面を識別するシーン識別子を含むことができる。360°ビデオの場面ごとにFOV(Field Of View)が変更可能であるので、さらに初期視点関連のメタデータは、該当場面に該当するFOVを示す場面ごとのFOV情報を含むことができる。
ROI関連メタデータは上述したROIに関連する情報を含む。ROI関連メタデータは、2d_roi_range_flagフィールド及び/又は3d_roi_range_flagフィールドを含む。2d_roi_range_flagフィールドは、ROI関連メタデータが2Dイメージを基準としてROIを表現するフィールドを含むか否かを指示し、3d_roi_range_flagフィールドは、ROI関連メタデータが3D空間を基準としてROIを表現するフィールドを含むか否かを指示することができる。実施例によってROI関連メタデータは、ROIによる差等符号化情報、ROIによる差等送信処理情報などの更なる情報を含むこともできる。
ROI関連メタデータが2Dイメージを基準としてROIを表現するフィールドを含む場合、ROI関連メタデータは、min_top_left_xフィールド、max_top_left_xフィールド、min_top_left_yフィールド、max_top_left_yフィールド、min_widthフィールド、max_widthフィールド、min_heightフィールド、max_heightフィールド、min_xフィールド、max_xフィールド、min_yフィールド及び/又はmax_yフィールドを含む。
min_top_left_xフィールド、max_top_left_xフィールド、min_top_left_yフィールド、max_top_left_yフィールドは、ROIの左上端の座標の最小/最大値を示す。即ち、フィールドは順に左上端の最小x座標、最大x座標、最小y座標、最大y座標を示す。
min_widthフィールド、max_widthフィールド、min_heightフィールド、max_heightフィールドは、ROIの幅(width)、高さ(height)の最小/最大値を示す。即ち、フィールドは順に幅の最小値、幅の最大値、高さの最小値、高さの最大値を示す。
min_xフィールド、max_xフィールド、min_yフィールド、max_yフィールドは、ROI内の座標の最小/最大値を示す。即ち、フィールドは順にROI内座標の最小x座標、最大x座標、最小y座標、最大y座標を示す。これらのフィールドは省略可能である。
ROI関連メタデータが3Dレンダリング空間上の座標を基準としてROIを表現するフィールドを含む場合、ROI関連メタデータは、min_yawフィールド、max_yawフィールド、min_pitchフィールド、max_pitchフィールド、min_rollフィールド、max_rollフィールド、min_field_of_viewフィールド及び/又はmax_field_of_viewフィールドを含む。
min_yawフィールド、max_yawフィールド、min_pitchフィールド、max_pitchフィールド、min_rollフィールド、max_rollフィールドは、ROIが3D空間上で占める領域をyaw、pitch、rollの最小/最大値で示すことができる。即ち、フィールドは順にヨー軸基準の回転量の最小値、ヨー軸基準の回転量の最大値、ピッチ軸基準の回転量の最小値、ピッチ軸基準の回転量の最大値、ロール軸基準の回転量の最小値、ロール軸基準の回転量の最大値を示す。
min_field_of_viewフィールド、max_field_of_viewフィールドは、該当360°ビデオデータのFOV(Field Of View)の最小/最大値を示す。FOVは360°ビデオの再生時に一回にディスプレイされる視野範囲を意味する。min_field_of_viewフィールド、max_field_of_viewフィールドは各々、FOVの最小値、最大値を示す。これらのフィールドは省略可能である。これらのフィールドは後述するFOV関連メタデータに含まれることもできる。
FOV関連メタデータは、上述したFOVに関連する情報を含む。FOV関連メタデータはcontent_fov_flagフィールド及び/又はcontent_fovフィールドを含む。実施例によっては、FOV関連メタデータは、上述したFOVの最小/最大値関連情報などの更なる情報を含むこともできる。
content_fov_flagフィールドは、該当360°ビデオについて製作時に意図したFOVに関する情報が存在するか否かを指示する。このフィールド値が1である場合、content_fovフィールドが存在することができる。
content_fovフィールドは、該当360°ビデオについて製作時に意図したFOVに関する情報を示す。実施例によって、該当360°ビデオ受信装置の垂直(vertical)或いは水平(horizontal)FOVによって、360映像のうち、ユーザに一回にディスプレイされる領域が決定される。或いは、実施例によって、このフィールドのFOV情報を反映してユーザに一回にディスプレイされる360°ビデオ領域が決定されることもできる。
クロップされた領域関連メタデータは、イメージフレーム上で実際の360°ビデオデータを含む領域に関する情報を含む。イメージフレームは実際の360°ビデオデータのプロジェクションされたアクティブビデオ領域(Active Video Area)と、そうではない領域とを含む。この時、アクティブビデオ領域は、クロップされた領域又はデフォルトディスプレイ領域とも称される。このアクティブビデオ領域は、実際のVRディスプレイ上で360°ビデオとして見られる領域であり、360°ビデオ受信装置又はVRディスプレイは、アクティブビデオ領域のみを処理/ディスプレイすることができる。例えば、イメージフレームの縦横比(aspect ratio)が4:3である場合、イメージフレームの上側の一部と下側の一部を除いた領域のみが360°ビデオデータを含むことができるが、この部分をアクティブビデオ領域と言える。
クロップされた領域関連メタデータは、is_cropped_regionフィールド、cr_region_left_top_xフィールド、cr_region_left_top_yフィールド、cr_region_widthフィールド及び/又はcr_region_heightフィールドを含む。実施例によっては、クロップされた領域関連メタデータは更なる情報を含むこともできる。
is_cropped_regionフィールドは、イメージフレームの全体領域が360°ビデオ受信装置或いはVRディスプレイにより使用されるか否かを示すフラグである。ここで、360°ビデオデータがマッピングされた領域或いはVRディスプレイ上で見られる領域は、アクティブビデオ領域(Active Video Area)とも呼ばれる。is_cropped_regionフィールドは、イメージフレーム全体がアクティブビデオ領域であるか否かを指示する。イメージフレームの一部のみがアクティブビデオ領域である場合は、さらに以下の4つのフィールドが追加される。
cr_region_left_top_xフィールド、cr_region_left_top_yフィールド、cr_region_widthフィールド、cr_region_heightフィールドは、イメージフレーム上でアクティブビデオ領域を示す。これらのフィールドは各々、アクティブビデオ領域の左上端のx座標、アクティブビデオ領域の左上端のy座標、アクティブビデオ領域の幅(width)、アクティブビデオ領域の高さ(height)を示す。幅と高さはピクチャ単位で示される。
360ビデオ基盤のVRシステムは、上述した360ビデオ処理過程に基づいて360ビデオに対してユーザの位置を基準として互いに異なる視聴方向(viewing orientation)に対する視覚的/聴覚的経験を提供する。360ビデオについて、ユーザの固定位置での互いに異なる視聴方向に対する視覚的/聴覚的経験を提供するVRシステムは、3DoF(three degree of freedom)基盤のVRシステムとも呼ばれる。なお、互いに異なるビューポイント、互いに異なる視点での互いに異なる視聴方向に対する拡張した視覚的/聴覚的経験を提供できるVRシステムは、3DoF+又は3DoF plus基盤のVRシステムとも呼ばれる。
図12はビューポイント、視点、視聴方向の概念を概略的に示す図である。
図12を参照すると、(a)のような空間(ex.講演場)を仮定した時、表示された各サークルは互いに異なるビューポイントを示す。同じ空間内に位置する各ビューポイントで提供される映像/音声は、同じ時間帯で互いに連関することができる。この場合、特定のビューポイントでユーザの視線方向の変化又はヘッドの動き(ex.head motion)によって互いに異なる視覚的/聴覚的経験をユーザに提供することができる。即ち、特定のビューポイントについて、(b)に示されたように、様々な視点の球(Sphere)を仮定することができ、各視点の相対的な位置を反映して映像/音声/テキスト情報を提供することができる。
なお、図12の(c)に示したように、特定のビューポイントの特定の視点では、既存の3DoFのように様々な方向の視覚的/聴覚的情報を伝達することができる。この時、メインソース(ex.映像/音声/テキスト)だけではなく、更なる様々なソースを統合して提供することができ、この場合、ユーザの視聴方向に連携されるか、又は独立して情報を伝達することができる。
図13は一実施例による3DoF+ビデオ提供のためのアーキテクチャの一例を概略的に示す図である。
図13は3DoF+の映像獲得、前処理、送信、(後)処理、レンダリング及びフィードバック過程を含む3DoF+end to endシステムのフローチャートを示す。
図13を参照すると、獲得(acquisition)過程は、360ビデオのキャプチャー、合成又は生成過程などによる360ビデオを得る過程を意味する。この過程により、多数の位置に対して視線方向の変化(ex.head motion)による多数の映像/音声情報を得ることができる。この時、映像情報は視覚的情報(ex.texture)だけではなく、深さ情報(depth)を含む。この時、1310の映像情報の例示のように、互いに異なるビューポイントによる互いに異なる視点の複数の情報を各々得ることができる。
合成(composition)過程は、映像/音声入力装置により得た情報だけではなく、外部メディアによる映像(ビデオ/イメージなど)、音声(オーディオ/効果音響など)、テキスト(字幕など)をユーザ経験に含めるために合成するための手順及び方法を含む。
前処理(pre−procesing)過程は、得られた360ビデオの送信/伝達のための準備(前処理)過程であり、上述したスティチング、プロジェクション、リージョンごとのパッキング過程及び/又は符号化過程などを含む。即ち、この過程は、映像/音声/テキスト情報を製作者の意図によってデータを変更/補完するための前処理過程及び符号化過程を含む。例えば、映像の前処理過程では、得られた視覚情報を360球面(Sphere)上にマッピングする作業(Stitching)、領域の境界をなくすか、色相/明るさの差を減らすか、映像の視覚的効果を与える補正作業(editing)、視点による映像を分離する過程(view segmentation)、360球面上の映像を2D映像にマッピングするプロジェクション過程(projection)、領域によって映像を再配置する過程(region−wise packing)、映像情報を圧縮する符号化過程が含まれる。1320のビデオ側面の例示のように、互いに異なるビューポイントによる互いに異なる視点の複数のプロジェクション映像が生成されることができる。
送信過程は、順位過程(前処理過程)を経た映像/音声データ及びメタデータを処理して送信する過程を意味する。互いに異なるビューポイントによる互いに異なる視点の複数の映像/音声データ及び関連メタデータを伝達する方法であって、上述したように、放送網、通信網を用いるか、又は単方向伝達などの方法を使用することができる。
後処理及び合成過程は、受信/格納されたビデオ/オーディオ/テキストデータを復号し、最終再生するための後処理過程を意味する。例えば、後処理過程は、上述したように、パッキングされた映像を開けるアンパッキング及び2Dプロジェクションされた映像を3D球形映像に復元するリプロジェクション過程などを含む。
レンダリング過程は、3D空間上にリプロジェクションされたイメージ/ビデオデータをレンダリングして、ディスプレイする過程を意味する。この過程において、映像/音声信号を最終的に出力するための形態で再構成することができる。ユーザの関心領域が存在する方向(viewing orientation)、視点(viewing position/head position)、位置(viewpoint)を追跡することができ、これらの情報によって必要な映像/音声/テキスト情報のみを選択的に使用することができる。この時、映像信号の場合、ユーザの関心領域によって1330のように互いに異なる視点が選択されることができ、最終的に1340のように特定の位置での特定視点の特定方向の映像が出力されることができる。
図14a及び14bは3DoF+end to endシステムアーキテクチャの一例である。
図14a及び14bのアーキテクチャにより、上述したような3D0F+360コンテンツが提供される。
図14aを参照すると、360ビデオ送信装置(送信端)は、大きく360ビデオ(イメージ)/オーディオデータが得られる部分(acquisition unit)、得られたデータを処理する部分(video/audio pre−processor)、追加情報を合成するための部分(composition generation unit)、テキスト、オーディオ及びプロジェクションされた360°ビデオを符号化する部分(encoding unit)及び符号化されたデータをカプセル化する部分(encapsulation unit)で構成される。上述したように、符号化されたデータはビットストリームの形態で出力され、符号化されたデータはISOBMFF、CFFなどのファイルフォーマットにカプセル化されるか、又はその他のDASHセグメントなどの形態で処理できる。符号化されたデータはデジタル格納媒体により360ビデオ受信装置に伝達され、又はたとえ明示的に示されてはいないが、上述したように送信処理部により送信のための処理を経た後、放送網又は広帯域などにより送信されることができる。
データ獲得部分では、センサの方向(Sensor orientation、映像の場合は、viewing orientation)、センサの情報獲得視点(Sensor position、映像の場合は、viewing position)、センサの情報獲得位置(映像の場合は、viewpoint)によって、互いに異なる情報を同時に又は連続して得ることができ、この時、ビデオ、イメージ、オーディオ、位置情報などを得ることができる。
映像データの場合、テクスチャー(texture)及び深さ情報を各々得ることができ、各コンポーネントの特性によって互いに異なる前処理(video pre−processing)が可能である。例えば、テクスチャー情報の場合、イメージセンサ位置情報を用いて同じ位置(viewpoint)で得た同一視点(viewing position)の互いに異なる方向(viewing orientation)の映像を用いて360全方位映像を構成することができ、このために、映像スティチング過程を行うことができる。また、映像を符号化するためのフォーマットに変更するためのプロジェクション及び/又はリージョンごとのパッキングを行うことができる。深さ映像の場合、一般的に深度カメラにより映像を得ることができ、この場合、テクスチャーのような形態で深さ映像を作ることができる。或いは、別途に測定されたデータに基づいて深さデータを生成することもできる。コンポーネントごとの映像が生成された後、効率的な圧縮のためのビデオフォーマットへの追加変換(packing)を行うか、又は実際必要な部分に分けて再構成する過程(Sub−picture generation)が行われる。Video pre−processingで使用された映像構成に関する情報はビデオメタデータで伝達される。
得られたデータ(或いは主にサービスするためのデータ)以外に、さらに与えられる映像/音声/テキスト情報を共にサービスする場合、これらの情報を最終再生時に合成するための情報を提供する必要がある。合成生成部(Composition generation)では、製作者の意図に基づいて、外部で生成されたメディアデータ(映像の場合は、ビデオ/イメージ、音声の場合は、オーディオ/効果音響、テキストの場合は、字幕などに)を最終再生部で合成するための情報を生成し、この情報は合成メタデータ(composition metadata)で伝達される。
各々の処理が行われた映像/音声/テキスト情報は、各々の符号器を用いて圧縮され、アプリケーションによってファイル或いはセグメント単位でカプセル化される。この時、ビデオ、ファイル或いはセグメント構成方法によって必要な情報のみを抽出することができる。
各データを受信器で再構成するための情報がコーデック或いはファイルフォーマット/システムレベルで伝達されるが、ここではビデオ/オーディオ再構成のための情報(video/audio metadata)、オーバーレイのための合成情報(composition metadata)、ビデオ/オーディオ再生可能位置(viewpoint)及び各位置による視点(viewing position)情報(viewing position and viewpoint metadata)などが含まれる。このような情報の処理は、別途のメタデータ処理部による生成も可能である。
図14bを参照すると、360ビデオ受信装置(受信端)は大きく、受信されたファイル或いはセグメントをカプセル除去する部分(file/segment decapsulation unit)、ビットストリームから映像/音声/テキスト情報を生成する部分(decoding unit)、映像/音声/テキストを再生するための形態で再構成する部分(post−processor)、ユーザの関心領域を追跡する部分(tracking unit)及び再生装置であるディスプレイで構成される。
カプセル除去により生成されたビットストリームは、データ種類によって映像/音声/テキストなどに分けて再生可能な形態に個々に復号される。
トラッキング部分では、センサ及びユーザの入力情報などに基づいてユーザの関心領域(Region of interest)の位置(viewpoint)、該当位置での視点(viewing position)、該当視点での方向(viewing orientation)情報を生成し、これらの情報は360ビデオ受信装置の各モジュールで関心領域の選択或いは抽出などに使用されるか、関心領域の情報を強調するための後処理過程などに使用される。また、360ビデオ送信装置に伝達される場合、効率的な帯域幅使用のためのファイル選択(file extractor)或いはサブピクチャ選択、関心領域に基づく様々な映像再構成方法(viewport/viewing position/viewpoint dependent processing)などに使用されることができる。
復号された映像信号は映像構成方法によって様々な処理方法で処理される。360ビデオ送信装置で映像パッキングが行われた場合、メタデータで伝達された情報に基づいて映像を再構成する過程が必要である。この場合、360ビデオ送信装置で生成したビデオメタデータを用いることができる。また復号された映像内に複数の視聴位置(viewpoint)、複数の視点(viewing position)、或いは様々な方向(viewing orientation)の映像が含まれた場合は、トラッキングにより生成されたユーザの関心領域の位置、視点、方向情報とマッチングされる情報を選択して処理することができる。この時、送信端で生成した視点及びビューポイント関連のメタデータが使用される。また特定の位置、視点、方向について複数のコンポーネントが伝達されるか、オーバーレイのためのビデオ情報が別に伝達される場合、各々によるレンダリング過程が含まれる。別のレンダリング過程を経たビデオデータ(テクスチャー、深さ、オーバーレイ)は、合成過程(composition)を経るが、この時、送信端で生成した合成メタデータ(composition metadata)が使用される。最終的にユーザの関心領域によってビューポートに再生するための情報を生成することができる。
復号された音声信号はオーディオレンダラー及び/又は後処理過程により再生可能な音声信号を生成し、この時、ユーザの関心領域に関する情報及び360ビデオ受信装置に伝達されたメタデータに基づいてユーザの要求に合う情報を生成することができる。
復号されたテキスト信号はオーバーレイのレンダラーに伝達されてサブタイトルなどのテキスト基盤のオーバーレイ情報として処理される。必要な場合、別途のテキスト後処理過程が含まれる。
図15はFLUSアーキテクチャの例示を概略的に示す図である。
図15は無線通信システム(wireless communication system)において、端末(User Equipment、UE)と端末又はネットワークがFLUS(Framework for Live Uplink Streaming)に基づいて通信を行う一例を示す。FLUSソース(Source)とFLUSシンク(Sink)は、Fレファレンスポイント(reference point)を用いて互いにデータを送受信する。
この明細書において、“FLUSソース”はFLUSに基づいてFレファレンスポイントによりFLUSシンクにデータを送信する装置を意味する。但し、FLUSソースが常にFLUSシンクへのデータ送信のみを行うことではなく、場合によっては、FLUSソースはFLUSシンクからFレファレンスポイントによりデータを受信することもできる。FLUSソースは、この明細書の全般に記載されたイメージ送信装置又は360ビデオ送信装置と同一/類似する装置であるか、イメージ送信装置又は360ビデオ送信装置を含むか、又はイメージ送信装置又は360ビデオ送信装置に含まれるものと解釈できる。FLUSソースは、例えば、端末(UE)、ネットワーク、サーバー、クラウドサーバー、セットトップボックス(STB)、基地局、PC、デスクトップ、ノートブック、カメラ、カムコーダー、TVなどであり、これらの装置に含まれる構成又はモジュールであるか、或いは例示された装置と類似する装置もFLUSソースとして動作することができる。FLUSソースの例示はこれらに限られない。
この明細書において、“FLUSシンク”はFLUSに基づいてFレファレンスポイントによりFLUSソースからデータを受信する装置を意味する。但し、FLUSシンクが常にFLUSシンクからデータ受信のみを行うことではなく、場合によっては、FLUSシンクはFLUSソースにFレファレンスポイントによりデータを送信することもできる。FLUSシンクは、この明細書の全般に記載されたイメージ受信装置又は360ビデオ受信装置と同一/類似する装置であるか、イメージ受信装置又は360ビデオ受信装置を含むか、又はイメージ受信装置又は360ビデオ受信装置に含まれるものと解釈できる。FLUSシンクは、例えば、ネットワーク、サーバー、クラウドサーバー、セットトップボックス(STB)、基地局、PC、デスクトップ、ノートブック、カメラ、カムコーダー、TVなどであり、例示された装置に含まれる構成又はモジュールであり、さらに例示された装置と類似する装置もFLUSソースとして動作することができる。FLUSソースの例示はこれらに限られない。
図15を参照すると、FLUSソースとキャプチャー装置が一つの端末(UE)を構成することが示されているが、これに限られない。FLUSソースはキャプチャー装置を含むことができ、キャプチャー装置を含むFLUSソース自体が端末になることができる。又はキャプチャー装置は端末に含まれず、端末でメディア情報を送信することもできる。キャプチャー装置の数は少なくとも一つ以上である。
図15を参照すると、FLUSシンクとレンダリング(Rendering)モジュール(又は部)、処理(Processing)モジュール(又は部)及び分配(Distribution)モジュール(又は部)が一つの端末又はネットワークを構成することが示されているが、これに限られない。FLUSシンクは、レンダリングモジュール、処理モジュール及び分配モジュールのうちのいずれか一つを含み、レンダリングモジュール、処理モジュール及び分配モジュールのうちのいずれか一つを含むFLUSシンク自体が端末又はネットワークになることができる。又はレンダリングモジュール、処理モジュール及び分配モジュールのうちのいずれか一つが端末又はネットワークに含まれず、FLUSシンクがレンダリングモジュール、処理モジュール及び分配モジュールのうちのいずれか一つでメディア情報を送信することもできる。レンダリングモジュール、処理モジュール及び分配モジュールの数は各々少なくとも一つ以上であり、場合によっては一部のモジュールは存在しないこともできる。
一例として、FLUSシンクはMGW(Media Gateway Function)及び/又はAF(Application Function)として動作する。
図15において、FLUSソースとFLUSシンクを連結するFレファレンスポイントは、FLUSソースが単一のFLUSセッションを生成及び制御するようにする。またFレファレンスポイントはFLUSシンクがFLUSソースを認証(authenticate)及び権限付与(authorize)するようにする。またFレファレンスポイントはFLUS制御平面(control plane)F−C及びFLUSユーザ平面(user plane)F−Uの保安保護機能を支援する。
一実施例において、FLUSソースとFLUSシンクは各々FLUS ctrlモジュールを含み、FLUSソースとFLUSシンクのFLUS ctrlモジュールはF−Cにより連結されることができる。FLUS ctrlモジュールとF−CはFLUSシンクがアップロードされたメディアに対してダウンストリーム分配(downstream distribution)を行うための機能を提供し、メディアインスタンス(instantiation)の選択を提供することができ、セッションの静的メタデータの構成を支援することができる。一例として、FLUSシンクがレンダリングのみを行える場合は、F−Cが存在しないこともできる。
一実施例において、F−CはFLUSセッションの生成及び制御に用いられる。F−CはFLUSソースがMTSIのようなFLUSメディアインスタンスを選択するか、メディアセッション周辺の静的メタデータを提供するか、又は処理/分配機能を選択及び構成する時に利用される。
FLUSメディアインスタンスは、FLUSセッションの一部として定義できる。場合によって、F−Uはメディアストリームの生成手順を含み、一つのFLUSセッションについて複数のメディアストリームが生成されることができる。
メディアストリームは、オーディオ、ビデオ、テキストのような単一コンテンツタイプに対するメディアコンポーネントを含むか、オーディオ及びビデオのように複数の互いに異なるコンテンツタイプに対するメディアコンポーネントを含む。FLUSセッションは同じ複数のコンテンツタイプで構成されることができる。例えば、FLUSセッションはビデオに対する複数のメディアストリームで構成されることができる。
また一実施例において、FLUSソースとFLUSシンクは各々FLUSメディアモジュールを含み、FLUSソースとFLUSシンクのFLUSメディアモジュールはF−Uにより連結されることができる。FLUSメディアモジュールとF−Uは一つ以上のメディアセッションの生成とメディアストリームによるメディアデータ送信機能を提供する。場合によっては、メディアセッション生成プロトコル(例えば、MTSIに基づくFLUSインスタンスのためのIMSセッションセットアップ)が要求される。
図16は3DoF+送信端の構成の一例を概略的に示す図である。
図16を参照すると、送信端(360ビデオ送信装置)では、入力されたデータがカメラ出力映像である場合、球(Sphere)映像構成のためのスティチングを位置/視点/コンポーネントごとに進行する。位置/視点/コンポーネントごとの球映像が構成されると、コーディングのために2D映像にプロジェクションを行う。アプリケーションによって複数の映像を統合映像にするためのパッキング或いは細部領域の映像に分けるサブピクチャで生成することができる。上述したように、リージョンごとのパッキング過程は、選択的(optional)過程であり、行わないこともできる。この場合、パッキング処理部は省略できる。入力されたデータが映像/音声/テキスト追加情報である場合は、追加情報を中心映像に追加してディスプレイする方法を知らせることができ、追加データと共に送信することができる。生成された映像及び追加データを圧縮してビットストリームで生成する符号化過程を経て送信或いは格納のためのファイルフォーマットに変換するカプセル化過程を経ることができる。この時、アプリケーション或いはシステムの要求により、受信部で必要とするファイルを抽出する過程を処理することができる。生成されたビットストリームは、送信処理部により送信フォーマットに変換された後、送信される。この時、送信側のフィードバック処理部では、受信端で伝達された情報に基づいて位置/視点/方向情報と必要なメタデータを処理して、関連する送信部で処理するように伝達することができる。
図17は3DoF+受信端の構成の一例を概略的に示す図である。
図17を参照すると、受信端(360ビデオ受信装置)では、送信端で伝達したビットストリームを受信した後、必要なファイルを抽出する。生成されたファイルフォーマット内の映像ストリームをフィードバック処理部で伝達する位置/視点/方向情報及びビデオメタデータを用いて選別し、選別したビットストリームを復号器により映像情報に再構成することができる。パッキングされた映像の場合、メタデータにより伝達されたパッキング情報に基づいてアンパッキングを行うことができる。送信端でパッキング過程が省略された場合は、受信端のアンパッキングも省略される。また必要によって、フィードバック処理部で伝達された位置(viewpoint)/視点(viewing position)/方向(viewing orientation)に適合する映像及び必要なコンポーネントを選択する過程を行うことができる。映像のテクスチャー、深さ、オーバーレイ情報などの再生に適合するフォーマットに再構成するレンダリング過程を行うことができる。最終映像を生成する前に、互いに異なるレイヤの情報を統合する合成(composition)過程を経ることができ、ディスプレイビューポートに適合する映像を生成して再生することができる。
図18は複数の位置でVRコンテンツに関する情報をキャプチャーする一例を示す図である。
一実施例において、VRコンテンツ生成のための情報は、図18のように、一つのシーン(scene)内の複数の位置でキャプチャーされることができる。二つのVRカメラは固定位置AとBでVRコンテンツ生成のための情報をキャプチャーし、一つのVRカメラはレールで位置を変更しながらVRコンテンツ生成のための情報をキャプチャーする。
ユーザは複数の位置、即ち、複数のビューポイントの間でビューポイントスイッチングを行うことができる。ビューポイントが転換されると、転換されたビューポイントの位置に関する情報及び関連メディアトラックの情報が提供される。システムは、特定のビューポイントが他のビューポイントへの転換に関するヒントを含んでいる場合、ヒントに基づいて他のビューポイントに転換するように設計される。
図19は3つのビューポイントをグローバル座標系(global coordinate)を基準として示す図である。
図19に示すように、一実施例によるグローバル座標系(global coordinate)は、グローバル3次元直交座標系(global three−dimensional Cartesian coordinate axes)により表現できる。
図19において、ビューポイントAの中心位置はグローバル座標系の原点であることができ、(0、0、0)値で表示することができる。グローバル座標系において、ビューポイント位置の絶対値はミリメートル単位で表現できる。
後述する内容は、MPEGシステムのファイルフォーマットシンタックス要素及びセマンティクス(semantics)のフォーマットに焦点を当てている。しかし、SEIメッセージ、パラメータセット及び/又は未来或いは現在のビデオコーデック、システムレベル(例えば、ファイル形式、DASH、MMT及び3GPP)又はデジタルインターフェース(例えば、HDMI、DisplayPortなど)などの他の形式のビデオレベル及びVESAも、後述する内容を反映して動作することができる。
一実施例において、ViewpointInfoStruct()は、ビューポイントの位置及びX,Y,Z軸を基準とするヨー(yaw)、ピッチ(pitch)及びロール(roll)角度に関する情報を含むビューポイント情報を提供する。ここで、ヨー、ピッチ及びロール角度は、共通参照座標系に対するビューポイントのグローバル座標系の回転角度を示す。ViewpointInfoStruct()の例示は以下の表1の通りである。
表1において、viewpoint_pos_x、viewpoint_pos_y及びviewpoint_pos_zは、3次元空間において(0、0、0)を共通参照座標系(common reference coordinate system)の中心とする時、ビューポイントの位置をミリメートル単位で示す。viewpoint_gcs_yaw、viewpoint_gcs_pitch及びviewpoint_gcs_rollは各々、共通参照座標系に対するビューポイントのグローバル座標系のX軸、Y軸及びZ軸のヨー、ピッチ及びロール角度を意味し、単位は2−16°である。viewpoint_gcs_yawは−180*216°以上180*216−1°以下の範囲に含まれ、viewpoint_gcs_pitchは−90*216°以上180*216−1°以下の範囲に含まれ、viewpoint_gcs_rollは−180*216°以上180*216−1°以下の範囲に含まれる。次に、transition_effect_typeは、ビューポイントスイッチングが行われる時の転移効果(transition effect)のタイプを表す。transition_effect_typeの例示は以下の表2の通りである。
表2による一例において、transition_effect_typeの値が0である場合、特定のビューポイントにズームイン(zoom−in)される転移効果を示すズームイン効果が指示され、transition_effect_typeの値が1である場合は、特定のビューポイントに移動する転移効果を示すウォークスルー(walking−through)効果が指示される。
再度表1を参照すると、viewing_orientation_refresh_flagの値が1である場合、InitialViewingOrientationSample()は示されず、現在のビューポイントにスイッチングされる前のビューポイントの視聴方向(viewing orientation)を維持することが勧められる。viewing_orientation_refresh_flagの値が0である場合は、InitialViewingOrientationSample()が示され、現在のビューポイントにスイッチングされる時にシグナリングされたInitialViewingOrientationSample()に含まれた視聴方向に従うことが勧められる。
viewing_orientation_yaw、viewing_orientation_pitch及びviewing_orientation_rollは、現在のビューポイントに転換される時に勧められるグローバル座標系のX軸、Y軸及びZ軸のヨー、ピッチ及びロール回転角度を示し、単位は2−16°である。viewing_orientation_yawは−180*216°以上180*216−1°以下の範囲に含まれ、viewing_orientation_pitchは−90*216°以上180*216−1°以下の範囲に含まれ、viewing_orientation_rollは−180*216°以上180*216−1°以下の範囲に含まれる。
一実施例によるビューポイント情報ボックス(viewpoint information box)は以下の通りである。
表3に含まれた情報は、共通参照座標系に対するビューポイントのグローバル座標系の位置情報、X軸、Y軸及びZ軸のヨー、ピッチ及びロール回転角度を含むビューポイント情報を提供する。
一実施例によるビューポイント情報ボックスは、例えば、以下の表4のようなシンタックスにより表現できる。
表4において、viewpoint_idはビューポイントグループに含まれたビューポイントのIDを示し、num_viewpointsはサンプルフォーマット内のシグナリングされたビューポイントの数を示す。
一実施例において、動的ビューポイントの時限メタデータトラック(Dynamic viewpoint timed metadata track)は、時間によって動的に変化するビューポイントパラメータを指示する。一例において、OMAFプレーヤーはビューポイント転換が行われた後、ビューポイントに対する再生を開始する時、以下のようなシグナリングされた情報を用いる。もし明らかにシグナリングされた推薦視聴方向が存在する場合、OMAFプレーヤーは推薦視聴方向に関する情報をパーシングし、推薦視聴方向に従う。逆に、もし明らかにシグナリングされた推薦視聴方向が存在しない場合は、OMAFプレーヤーはビューポイントスイッチングが発生する前のビューポイントの視聴方向をビューポイントスイッチングの後にも維持することができる。
一実施例において、トラックサンプルエントリータイプ(track sample entry type)‘dyvp’が用いられる、サンプルエントリータイプのサンプルエントリーは、以下の表5のように具体化することができる。
一実施例において、サンプルエントリータイプ(‘dyvp’)のサンプルシンタックスは、以下の表6のように具体化することができる。
表6において、viewpoint_idはビューポイントグループに含まれたビューポイントのID情報を示し、num_viewpointsはサンプルフォーマットでシグナリングされたビューポイントの数を指示する。
一実施例において、track_group_typeが‘vpgr’であるTrackGroupTypeBoxに含まれたトラックは、360シーン内でスイッチングできることを示す。このグループにマッピングされたトラック、即ち、track_group_typeが‘vpgr’であるTrackGroupTypeBox内のtrack_group_idの値が等しい視覚トラックは、360シーン内でスイッチングされるビューポイントを形成することができる。
複数のビューポイントのビデオトラックグルーピングとしては、以下の2つの実施例が提案される。第1の実施例において、non_contiguous_flagはトラックグループの近接性(contiguity characteristic)を指示し、これによりtrack_group_idが同一であると、non_contiguous_flagの値が同一である。第2の実施例では、各々の近接ビューポイントのアンカービューポイント(anchor viewpoint)を定義することができる。複数のビューポイントのビデトラックグルーピングに関する実施例は、上述した第1、第2の実施例に限られない。以下、図20乃至図22bは第1の実施例に関し、図23乃至図24bは第2の実施例に関する。
本発明の一実施例によれば、ユーザは3DoF、3DoF+又は6DoFの環境で複数のビューポイントに基づいてビューポイント転換(viewpoint switching)を行うことにより、様々な観点で360°ビデオを経験することができる。この時、ビューポイントの転換が行われるビューポイントは“ホットスポット(hotspot)”とも称される。ホットスポットは、ビューポイントのうち、ビューポイント転換が行われるビューポイントを示すので、ビューポイントの下位概念であると解釈できるが、場合によっては、ホットスポットはビューポイントと同一/類似する概念であることもできる。従って、この明細書の全般に記載された任意の“ビューポイント”はホットスポットに代替し、この明細書の全般に記載された任意の“ホットスポット”はビューポイントに代替することができる。例えば、“ホットスポットメタデータ”のようにホットスポットに関連する情報も“ビューポイントメタデータ”などに代替して解釈することができる。
この明細書に記載された“共通参照座標系(common reference coordinate system)”は、ビューポイントグループの基準(又は中心)となる座標系を意味する。共通参照座標系は参照座標系(reference coordinate system)とも称することができる。
図20は複数のビューポイントのビューポイントグループIDと非近接フラグ情報を示す一例である。
複数のビューポイントビデオトラックグルーピングに関するシンタックスは、例えば、以下の表7のように表現できる。
表7において、non_contiguous_flagの値が0であると、グループ内の全てのビューポイントが360シーン内で近接することを意味し、non_contiguous_flagの値が1であると、ビューポイントビデオトラックグループが360シーン内で少なくとも一つの非近接ビューポイントを含むことを意味する。一例において、track_group_idの値が等しいトラックのnon_contiguous_flag値は同一であることができる。
一実施例において、non_contiguous_flagの値が異なりながら、track_group_idの値が異なるトラックが存在する場合は、non_contiguous_flagの値が0であるtrack_group_idがnon_contiguous_flagの値が1であるtrack_group_idより先行することができる。
他のタイプのビューポイントビデオトラックグループは、フラグを追加するか又はViewpointTrackGroupTypeを定義することで定義することができる。
一例において、表7のviewpointTrackGroupType()のセマンティクスは、transition_effect_type、viewing_orientation_refresh_flag、viewing_orientation_refresh_flagなどのフィールドを含む。transition_effect_typeはトラックグループ内でビューポイントスイッチングが行われる時の転移効果のタイプを指示することができる。viewing_orientation_refresh_flagの値が1である場合は、InitialViewingOrientationSample()は示されず、現在のビューポイントにスイッチングされる前のビューポイントの視聴方向(viewing orientation)を維持することが勧められる。viewing_orientation_refresh_flagの値が0である場合は、InitialViewingOrientationSample()が示され、現在のビューポイントにスイッチングされる時にシグナリングされたInitialViewingOrientationSample()に含まれた視聴方向に従うことが勧められる。
図20による例示を参照すると、ビューポイントがVP#1乃至VP#5により表されている。VP#1及びVP#2とVP#3、VP#4及びVP#5とを区分する線は、ビューポイント間の近接有無を示す。track_group_idが0であるグループ内のVP#1とVP#2は近接するので、track_group_idが0であるグループ内のビューポイントのnon_contiguous_flagの値は0である。track_group_idが1であるグループ内のVP#2はVP#4及びVP#5に近接していないので、track_group_idが1であるグループ内のビューポイントのnon_contiguous_flagの値は1である。track_group_idが2であるグループ内のVP#3、VP#4及びVP#5は近接するので、track_group_idが2であるグループ内のビューポイントのnon_contiguous_flagの値は0である。
図21a及び図21bは複数のビューポイントの間が近接しているか否かによるディスプレイの一例を示す図である。
図21aにおいて、VP#1乃至VP#4はスタジアムのシーンを示し、VP#5及びVP#6はロッカールームを示し、VP#7はスタジアム入口のシーンを示す。track_group_idが0であるグループ内に含まれるVP#1乃至VP#4は近接するので、track_group_idが0であるグループ内のビューポイントのnon_contiguous_flagの値は0である。track_group_idが1であるグループ内に含まれるVP#5及びVP#6は近接するので、track_group_idが1であるグループ内のビューポイントのnon_contiguous_flagの値は0である。track_group_idが2であるグループ内に含まれるVP#1乃至VP#7は、全てが相互近接することではないので、track_group_idが2であるグループ内のビューポイントのnon_contiguous_flagの値は1である。
一実施例において、近接するビューポイントの間でスイッチングが行われる時と、近接していないビューポイントの間でスイッチングが行われる時に適用される転移効果は互いに異なることができる。一例において、近接するビューポイントの間でスイッチングが行われる時に適用される転移効果はズームイン効果であり、近接していないビューポイントの間でスイッチングが行われる時に適用される転移効果はウォークスルー(walking through)効果又はwalk through a hall wayである。
図21bを参照すると、名前、静止画像、プレビュービデオ、実際のビデオ又は関連説明(description)がオーバーレイを用いて伝達(delivered)又はディスプレイされることができる。図21aにおいて、track_group_id=0のVP#1、VP#2、VP#3及びVP#4は互いに近接することを確認できるので、図21bのようにVP#1のシーン内でVP#2、VP#3及びVP#4の位置を指示するアイコンがオーバーレイされることができる。
VP#1に近接していないVP#5、VP#6及びVP#7は、図21bの左側図の右上端に示されたオーバーレイアイコンにより接続できる。即ち、track_group_idが1であるビューポイントと、track_group_idが2であり、かつtrack_group_idが0ではないビューポイントは、VP#1に近接していないので、VP#5、VP#6及びVP#7に対応するアイコンはVP#1のシーン内に直接ディスプレイされず、リンクアイコンに対する接続後にさらにディスプレイされることができる。但し、実施例はこれに限られず、VP#1に近接していないVP#5、VP#6及びVP#7に対応するアイコンは、例えば、更なるポップアップディスプレイによるか、ビューポート上のアドオンによるか、又は360シーンのカバレッジ限界によるブラック領域(black area)によって示されることができる。
図22a及び図22bは複数のビューポイントの間が近接しているか否かによるディスプレイの他の例を示す図である。
一実施例において、図22aはVP#1に近接していないVP#5、VP#6及びVP#7に対応するアイコンがポップアップ方式でディスプレイされることを示し、図22bはVP#1に近接していないVP#5、VP#6及びVP#7に対応するアイコンがビューポート上のアドオン方式でディスプレイされることを示す。
図22aを参照すると、VP#5、VP#6及びVP#7はVP#1に近接していないので、VP#1のシーン内に直接ディスプレイすることはできないが、VP#5、VP#6及びVP#7を示す最適の間接位置(例えば、VP#1シーン内で見たロッカールームの位置)にVP#5、VP#6及びVP#7に対応するアイコンをディスプレイすることができる。また、各ビューポイントに関連するイメージ情報、説明情報などを図22aのようにポップアップ方式でディスプレイすることができる。
図22bを参照すると、VP#1に近接していないVP#5、VP#6及びVP#7に対するアイコンをVP#1に対するシーンの左側にディスプレイすることができる。VP#5、VP#6及びVP#7に対するアイコンと共に、VP#5、VP#6及びVP#7と各々対応するイメージをディスプレイすることができる。
図23は複数のビューポイントのビューポイントグループID、非近接フラグ情報及びアンカービューポイントフラグ情報を示す一例である。
複数のビューポイントビデオトラックグルーピングに関するシンタックスは、例えば、以下の表8のように表現できる。
アンカービューポイントは近接ビューポイントの基礎ビューポイントと定義できる。表8において、anchor_viewpoint_flagの値が0である場合、(現在の)ビューポイントはトラックグループ(又はビューポイントグループ)内の近接するビューポイントのうち、アンカー(anchor)/マスター(master)/オリジン(origin)ではない。anchor_viewpoint_flagの値が1である場合は、(現在の)ビューポイントはトラックグループ(又はビューポイントグループ)内の近接するビューポイントのうち、アンカー/マスター/オリジンである。ビューポイントトラックグループ(又はビューポイントグループ、トラックグループ)内の複数の近接ビューポイントが定義された場合、少なくとも一つのビューポイントに対するanchor_viewpoint_flagの値は1である。
一実施例において、アンカービューポイントは、2つの分離されたグループの間の連結ポイント(connection point)として利用できる。例えば、一つのルームに複数のビューポイントが定義された場合、ルームのドアに位置するビューポイントがアンカービューポイントとして定義されることができる。この時、ルームのドアに位置するビューポイントは連結ポイントとして他のルームのドアに位置するビューポイントに連結されることができる。
表8において、non_contiguous_flagの値が0であると、現在のビューポイントはアンカービューポイントと空間的に(spatiallly)又は論理的に(logically)近接することができる。non_contiguous_flagの値が1であると、現在のビューポイントはアンカービューポイントと空間的又は論理的に近接しないことができる。即ち、ビューポイントトラックグループ内のビューポイントの近接性(contiguity)は、現在のビューポイントとアンカービューポイントとの間の空間的関係又は論理的関係により決定される。一例において、他のタイプのビューポイントビデオトラックグループはフラグを追加するか、又はViewpointTrackGroupTypeを定義することにより定義することができる。
一例において、ViewpointTrackGroupTypeは空間的近接性、論理的近接性などの互いに異なるタイプの近接性に関する指示情報を示す。
一実施例において、ViewpointTransitionEffectStruct()は、以下のようなtransition_effect_type及びviewing_orientation_refresh_flagを含む。transition_effect_typeは、トラックグループ(又はビューポイントグループ)内のビューポイント間のスイッチングを行う時に適用される転移効果のタイプを指示する。viewing_orientation_refresh_flagの値が0であると、InitialViewingOrientationSample()は示されず、同じトラックグループ(又はビューポイントグループ)内でスイッチングが行われる前の視聴方向を維持することが勧められる。viewing_orientation_refresh_flagの値が1であると、InitialViewingOrientationSample()値が示され、同じトラックグループ内でスイッチングが行われる時にシグナリングされたInitialViewingOrientationSample()に含まれた視聴方向に従うことが勧められる。
図23を参照すると、ビューポイントトラックグループのtrack_group_idが0であるビューポイント(点線内のビューポイント)はVP#1乃至VP#5であり、ビューポイントトラックグループのtrack_group_idが1であるビューポイント(実線内のビューポイント)もVP#1乃至VP#5であることを確認できる。図23における中心ラインを基準として近接しているか否かが判断される。即ち、VP#1とVP#2が近接し、VP#3、VP#4及びVP#5が近接する。図23において、track_group_idが0であるビューポイント(トラック)グループのアンカービューポイントはVP#2であり、track_group_idが1であるビューポイント(トラック)グループのアンカービューポイントはVP#4である。
図23を参照すると、track_group_idが0であるビューポイントグループにおいて、VP#1はアンカービューポイントであるVP#2に近接するので、VP#1のnon_contiguous_flagの値は0であり、VP#1はアンカービューポイントではないので、anchor_viewpoint_flagの値は0であることを確認できる。track_group_idが0であるビューポイントグループにおいて、VP#3はアンカービューポイントであるVP#2に近接していないので、VP#3のnon_contiguous_flagの値は1であり、VP#3はアンカービューポイントではないので、anchor_viewpoint_flagの値は0であることを確認できる。また、track_group_idが1であるビューポイントグループにおいて、VP#4はアンカービューポイントであるので、non_contiguous_flagの値は0であり、anchor_viewpoint_flagの値は1であることを確認できる。
図24a及び図24bは複数のビューポイントの間が近接しているか否かによるディスプレイのさらに他の例を示す図である。
図24aを参照すると、ビューポイントトラックグループのtrack_group_idが0であるビューポイントはVP#1乃至VP#7であり、アンカービューポイントはVP#1であり、アンカービューポイントであるVP#1に近接するビューポイントはVP#2乃至VP#4である。従って、VP#1のanchor_viewpoint_flagの値は1であり、VP#2乃至VP#7のanchor_viewpoint_flagの値は0であり、VP#1乃至VP#4のnon_contiguous_flagの値は0であり、VP#5乃至VP#7のanchor_viewpoint_flagの値は1であることを確認できる。track_group_idが1であるビューポイント(トラック)グループのアンカービューポイントはVP#5であり、track_group_idが2であるビューポイント(トラック)グループのアンカービューポイントはVP#7であり、track_group_idが1であるビューポイントグループ及び2であるビューポイントグループは、track_group_idが0であるビューポイントグループと同様に、アンカービューポイントを基準としてanchor_viewpoint_flagの値及びnon_contiguous_flagの値が決定されることを確認できる。
一実施例において、近接するビューポイントの間でスイッチングが行われる時と、近接していないビューポイントの間でスイッチングが行われる時に適用される転移効果は互いに異なることができる。一例において、近接するビューポイントの間でスイッチングが行われる時に適用される転移効果はズームイン効果であり、近接していないビューポイントの間でスイッチングが行われる時に適用される転移効果はウォークスルー(walking through)効果又はwalk through a hall wayである。
図24bを参照すると、名前、静止画像、プレビュービデオ、実際のビデオ又は関連説明がオーバーレイを用いて伝達又はディスプレイされることができる。図24aにおいて、track_group_idが0であるビューポイントグループにおいて、VP#1、VP#2、VP#3及びVP#4が互いに近接することが確認できるので、図24bのようにVP#1のシーン内でVP#2、VP#3及びVP#4の位置を指示するアイコンがオーバーレイされることができる。
VP#1に近接していないVP#5、VP#6及びVP#7は、図24bの左側図の右上端に示されたオーバーレイアイコンにより接続できる。即ち、VP#5乃至VP#7はVP#1に近接していないので、VP#5、VP#6及びVP#7に対応するアイコンはVP#1のシーン内に直接ディスプレイされず、リンクアイコンに対する接続後にさらにディスプレイされることができる。但し、実施例はこれに限られず、VP#1に近接していないVP#5、VP#6及びVP#7に対応するアイコンは、例えば、更なるポップアップディスプレイによるか、ビューポート上のアドオンによるか、実際の位置に関連するか又は関連しない360球面座標系によるか、又は360シーンのカバレッジ限界によるブラック領域によって示されることができる。
一実施例において、上記メタデータは以下の表9のDASHデータのように示すことができる。
表9のtransition_effect_typeは表1のtransition_effect_type[i]に対応し、表9のviewing_orientation_refresh_flagは表1のviewing_orientation_refresh_flagに対応し、表9のviewing_orientation_yaw、viewing_orientation_pitch及びviewing_orientation_rollは表1のviewing_orientation_yaw、viewing_orientation_pitch及びviewing_orientation_rollに対応し、表9のnum_viewpointsは表4のnum_viewpointsに対応し、表9のviewpoint_idは表4のviewpoint_idに対応し、表9のnon_contiguous_flagは表7のnon_contiguous_flagに対応し、表9のviewpointTrackGroupTypeは表7のviewpointTrackGroupTypeに対応することができる。
図25a及び図25bは複数のビューポイントの一例を示す図である。
複数のビューポイントは、ユーザが360シーンを探索する時に用いられる。ホットスポットは複数のビューポイント間のスイッチングを行う過程で用いられ、ユーザは360シーン内でスイッチング可能なビューポイントを示すホットスポットを選択してクリックすることにより、ビューポイントスイッチングを行うことができる。
複数のビューポイント機能を支援するために、以下の要求事項を考える必要がある。第一に、互いに異なるビューポイントに対応するコンテンツの間の空間的関係を記載する手段を定義する必要がある。第二に、互いに異なるビューポイントに対応するコンテンツを一時的に同期化する必要がある。第三に、互いに異なるビューポイントでコンテンツを転換することを支援する必要がある。第四に、コンテンツ提供者により互いに異なるビューポイント間の転換が行われる時、スムーズな移動(smooth transition)が提要されることができる。
ビューポイント間の転換を支援するために、更なるメタデータが考えられる必要がある。第一には、一つのビューポイントから他のビューポイントに転換される時に用いられることが勧められる転移効果に関するメタデータである。転移効果は、例えば、ウォークスルー効果又はズームイン効果を含む。転移効果に関するメタデータは、コンテンツ提供者により意図されたビーポイント間の転換が行われる時にスムーズな移動を提供することができる。
第二に、ユーザが加用ビューポイントのうちの一つを選択するようにするビューポイントのグルーピングに関するメタデータである。図25aはスポーツスタジアムの複数のビューポイントの例示を示し、スポーツスタジアムの複数のビューポイントと、ロッカールームの複数のビューポイント及びスタジアム入口のビューポイントのようなフィールド外部のビューポイントを示している。スポーツスタジアムの複数のビューポイントに関連するケースにおいて、ユーザがホットスポットを転換できるビューポイントは現在の360シーンに位置することができ、ビューポイントの位置は近接するビューポイントの間の実際の関係に基づいて決定される。ビューポイントの位置がシーンと整列されると、ユーザは直観的にビューポイントを選択することができる。
反面、フィールド外部のビューポイントに関連するケースにおいて、ビューポイント間の空間的関係がシーンと整列されないことができるので、受信器は非近接ビューポイントの可用性を他の方式で示す必要がある。図25bを参照すると、ロッカールームとスタジアム入口は、実際の時点に一致しないホットスポットに連結されていることを確認できる。
上記イッシュを解決するために、一実施例では、受信器が意図された転移効果に関する情報を受信できるシグナリング方法が提供される。さらに、ビューポイントスイッチングに対するビデオトラックグループを指示する複数のビューポイントのための新しいトラックグルーピングが提案される。複数のビューポイントのスイッチングを支援するために、OMAFでビューポイントメタデータを伝達する方法が提案される。OMAFでビューポイントメタデータを伝達する方法において、ViewpointInfoStruct()内に転移効果メタデータを含んで伝達することができ、近接又は非近接360シーン内でスイッチングされるビデオトラックグループを指示するために、ビューポイントに対する新しいトラックグルーピングが提案されることができる。
一実施例において、ViewpointInfoStruct()は共通参照座標系に備えたグローバル座標系のビューポイント位置及びX軸、Y軸及びZ軸のヨー、ピッチ及びロール回転角度を含むビューポイント情報を提供する。一例において、ビューポイントグループ内の全てのビューポイントに対して共通に適用される共通参照座標系が定義される必要がある。ViewpointInfoStruct()を含むシンタックスの一例は以下の表10の通りである。
viewpoint_pos_x、viewpoint_pos_y及びviewpoint_pos_zは、(0、0、0)を共通参照座標系の中心とする3D空間でビューポイントの位置をミリメートル単位で示すことができる。
viewpoint_gcs_yaw、viewpoint_gcs_pitch及びviewpoint_gcs_rollは各々、共通参照座標系に対するビューポイントのグローバル座標系のX軸、Y軸及びZ軸のヨー、ピッチ及びロール角度を意味し、単位は2−16°である。viewpoint_gcs_yawは−180*216°以上180*216−1°以下の範囲に含まれ、viewpoint_gcs_pitchは−90*216°以上180*216−1°以下の範囲に含まれ、viewpoint_gcs_rollは−180*216°以上180*216−1°以下の範囲に含まれる。次に、transition_effect_typeはビューポイントスイッチングが行われる時の転移効果のタイプを示す。transition_effect_typeの例示は以下の表11の通りである。
再度表10を参照すると、viewing_orientation_refresh_flagの値が1である場合、InitialViewingOrientationSample()は示されず、現在のビューポイントにスイッチングされる前のビューポイントの視聴方向(viewing orientation)を維持することが勧められる。viewing_orientation_refresh_flagの値が0である場合は、InitialViewingOrientationSample()が示され、現在のビューポイントにスイッチングされる時にシグナリングされたInitialViewingOrientationSample()に含まれた視聴方向に従うことが勧められる。他の例示では、viewing_orientation_refresh_flagの値が0でありながら、関連するInitialViewingOrientationSample()が存在しない場合、ビューポイント座標系の(0、0、0)をビューポイントスイッチング時の視聴方向として決定することができる。
一方、表10によるViewpointInfoStructは一例に過ぎず、ViewpointInfoStructを示すシンタックスが表10に限られないことは、当該技術分野における通常の技術者が容易に理解することができる。
一実施例において、track_group_typeが‘vpgr’であるTrackGroupTypeBoxは、該当トラックが360シーンでスイッチング可能なトラックであることを示す。該当グループにマッピングされたトラックは360シーン内でスイッチング可能なビューポイントを形成することができる。
一実施例において、anchor_viewpoint_flagとnon_contiguous_flagを含むシンタックスの一例は、以下の表12の通りである。
表12において、anchor_viewpoint_flagの値が1である場合、(現在の)ビューポイントは、同じビューポイントのトラックグループ内のビューポイント近接性の決定に基盤となるアンカービューポイントに該当する。track_group_idが同じ値を有する複数のトラックが存在する場合は、該当グループの少なくとも一つのトラック(又はビューポイント)のanchor_viewpoint_flagの値は1になる。
一例において、OMAFプレーヤーは360シーンの変更のように、該当ビューポイントトラックグループのうち、特定のビューポイントを明示的に選択せず、ユーザがビューポイントトラックグループに参与する時、アンカービューポイントトラックを再生することができる。
表12のnon_contiguous_flagの値が0であると、アンカービューポイントに近接することができ、non_contiguous_flagの値が1であると、アンカービューポイントに近接しないことができる。
図26は一実施例による360°ビデオ送信装置の動作方法を示すフローチャートであり、図27は一実施例による360°ビデオ送信装置の構成を示すブロック図である。
図26に示された各段階は、図5に示された360ビデオ送信装置、図14aに示された360ビデオ送信装置、図15に示されたFLUSソース、又は図27に示された360°ビデオ送信装置により行われる。一例として、図26のS2600は図5に示された360ビデオ送信装置のデータ入力部により行われ、図26のS2610は図5に示された360ビデオ送信装置のプロジェクション処理部により行われ、図26のS2620は図5に示されたメタデータ処理部により行われ、図26のS2630は図5に示された360ビデオ送信装置のデータ符号器により行われ、図26のS2640は図5に示された360ビデオ送信装置のカプセル化処理部により行われる。従って、図26の各段階を説明するにおいて、図5、図14a及び図15に示した内容と重複する具体的な内容は省略するか又は簡単に説明する。
図27に示したように、一実施例による360°ビデオ送信装置は、データ入力部、プロジェクション処理部、メタデータ処理部、データ符号器及びカプセル化処理部を含む。しかし、場合によっては、図27に示した全ての構成要素が360°ビデオ送信装置の必須構成要素ではないこともでき、360°ビデオ送信装置は図27に示した構成要素より多いか又は少なく構成要素により具現されることもできる。
一実施例による360°ビデオ送信装置において、データ入力部、プロジェクション処理部、メタデータ処理部、データ符号器及びカプセル化処理部は各々、別途のチップで具現されるか、又は少なくとも2つ以上の構成要素が一つのチップにより具現される。
この明細書において、“360ビデオ”と“360°ビデオ”は多少名称が異なるが、同じ対象を指すものである。従って、図5に示した“360ビデオ送信装置”と図27に示した“360°ビデオ送信装置”は名称が多少異なるだけであり、互いに同一/類似する動作を行うものであり、図6に示した“360ビデオ受信装置”と図29に示した“360°ビデオ受信装置”も名称が多少異なるだけであり、互いに同一/類似する動作を行う。
一実施例による360°ビデオ送信装置は、少なくとも一つのイメージ獲得装置によりキャプチャーされた360°ビデオデータを得る(S2600)。より具体的には、360°ビデオ送信装置のデータ入力部は、少なくとも一つのイメージ獲得装置によりキャプチャーされた360°ビデオデータを得ることができる。
一実施例において、イメージ獲得装置はカメラ、カムコーダー、スマートホン、PCなどを含み、これらに限られない。
一実施例による360°ビデオ送信装置は360°ビデオデータを処理して全方向イメージを含む2次元ピクチャを導き出す(S2610)。より具体的には、360°ビデオ送信装置のプロジェクション処理部は、360°ビデオデータを処理して全方向イメージを含む2次元ピクチャを導き出すことができる。
一実施例による360°ビデオ送信装置は360°ビデオデータに関するメタデータを生成する(S2620)。より具体的には、360°ビデオ送信装置のメタデータ処理部は360°ビデオデータに対するメタデータを生成することができる。
一実施例において、メタデータは360°ビデオデータ内のビューポイントグループに含まれた少なくとも一つのビューポイントが互いに近接しているか否かを示す非近接フラグ情報を含む。一例において、非近接フラグ情報はnon_contiguous_flagと称される。
一実施例において、ビューポイントグループに含まれた全てのビューポイントが互いに近接する場合、非近接フラグ情報の値は0であり、ビューポイントグループに含まれた少なくとも一つのビューポイントが互いに近接していない場合は、非近接フラグ情報の値は1である。
一実施例において、ビューポイントグループに含まれた少なくとも一つのビューポイントが互いに近接しているか否かについての判断は、空間的非近接性(spatial non−contiguity)及び論理的非近接性(logical non−contiguity)のうちのいずれかに基づく。一例において、ビューポイントグループに含まれた少なくとも一つのビューポイントが互いに近接しているか否かについての判断は、ViewpointTrackGroupTypeに基づいて行われる。
一実施例において、さらにメタデータは、ビューポイントグループに含まれた現在のビューポイントがアンカービューポイント(anchor viewpoint)であるか否かを示すアンカービューポイントフラグ情報を含む。一例において、アンカービューポイントフラグ情報はanchor_viewpoint_flagと称される。
一実施例において、現在のビューポイントがアンカービューポイントである場合、現在のビューポイントに対するアンカービューポイントフラグ情報の値は1であり、現在のビューポイントがアンカービューポイントではない場合は、現在のビューポイントに対するアンカービューポイントフラグ情報の値は0である。
一実施例において、ビューポイントグループに含まれた現在のビューポイントがアンカービューポイントに近接する場合、現在のビューポイントに対する非近接フラグ情報の値は0であり、ビューポイントグループに含まれた現在のビューポイントがアンカービューポイントに近接していない場合は、現在のビューポイントに対する非近接フラグ情報の値は1である。
一実施例において、アンカービューポイントフラグ情報の値が1である場合、非近接フラグ情報の値は0である。
一実施例において、さらにメタデータは、ビューポイントに対して初期の視聴方向(initial viewing orientation)を適用するか否かに関する情報を含む。一例において、ビューポイントに対して初期の視聴方向を適用するか否かに関する情報はviewing_orientation_refresh_flagと称される。
一実施例において、初期の視聴方向を適用するか否かに関する情報に基づいてビューポイントに対して初期の視聴方向を適用すると決定した場合、メタデータはビューポイントに対する初期の視聴方向のヨー(yaw)角度、ピッチ(pitch)角度及びロール(roll)角度に関する情報を含む。一例において、ビューポイントに対する初期の視聴方向のヨー角度、ピッチ角度及びロール角度に関する情報はInitialViewingOrientationSampleと称される。
一実施例において、さらにメタデータは、ビューポイントグループ内でビューポイントスイッチングが行われる時に適用される転移効果(transition effect)のタイプに関する情報を含む。一例において、転移効果のタイプに関する情報はtransition_effect_typeと称される。
一実施例において、転移効果のタイプに関する情報は、ズームイン(zoom−in)効果に関する情報及びウォークスルー(walking through)効果に関する情報を含む。
一実施例による360°ビデオ送信装置は、2次元ピクチャに関する情報を符号化する(S2630)。より具体的には、360°ビデオ送信装置のデータ符号器は2次元ピクチャに関する情報を符号化する。
一実施例による360°ビデオ送信装置は、2次元ピクチャに関する情報及びメタデータに基づいてカプセル化を行う(S2640)。より具体的には、360°ビデオ送信装置のカプセル化処理部は2次元ピクチャに関する情報及びメタデータに基づいてカプセル化を行う。
図26及び図27に示された360°ビデオ送信装置及び360°ビデオ送信装置の動作方法によれば、一実施例による360°ビデオ送信装置は、少なくとも一つのカメラによりキャプチャーされた360°ビデオデータを得(S2600)、360°ビデオデータを処理して全方向イメージを含む2次元ピクチャを導き出し(S2610)、360°ビデオデータに対するメタデータを生成し(S2620)、2次元ピクチャに関する情報を符号化し(S2630)、2次元ピクチャに関する情報及びメタデータに基づいてカプセル化を行い(S2640)、この時、メタデータは360°ビデオデータ内のビューポイントグループに含まれた少なくとも一つのビューポイントが互いに近接しているか否かを示す非近接フラグ情報を含むことを特徴とする。これにより、360°ビデオ内でビューポイントグループに含まれた少なくとも一つのビューポイントが互いに近接しているか否かを示す非近接フラグ情報を効果的にシグナリングすることができる。
図28は一実施例による360°ビデオ受信装置の動作方法を示すフローチャートであり、図29は一実施例による360°ビデオ受信装置の構成を示すブロック図である。
図28及び図29による360°ビデオ受信装置及びその動作方法は、上述した図26及び図27による360°ビデオ送信装置の動作方法と一部対応する。従って、互いに重複する動作については説明を簡単にするか又は省略する。
図28に示された各段階は図6に示された360ビデオ受信装置、図14bに示された360ビデオ受信装置、図15に示されたFLUSシンク、又は図29に示された360°ビデオ受信装置により行われる。一例として、図28のS2800及びS2810は図6に示された360ビデオ受信装置の受信処理部により行われ、図28のS2820は図6に示された360ビデオ受信装置のデータ復号器により行われ、図28のS2830は図6に示されたレンダラーにより行われる。従って、図28の各段階を説明するにおいて、図6、図14b及び図15に示した内容と重複する具体的な内容は説明を省略するか又は簡単に説明する。
図29に示したように、一実施例による360°ビデオ受信装置は、受信処理部、データ復号器及びレンダラーを含む。しかし、場合によっては、図29に示した全ての構成要素が360°ビデオ受信装置の必須構成要素ではないこともでき、360°ビデオ受信装置は図29に示した構成要素より多いか又は少ない構成要素により具現されることもできる。
一実施例による360°ビデオ受信装置において、受信処理部、データ復号器及びレンダラーは各々別のチップで具現されるか、又は少なくとも2つ以上の構成要素が一つのチップで具現されることもできる。
一実施例による360°ビデオ受信装置は、360°ビデオデータに関する情報を受信する(S2800)。より具体的には、360°ビデオ受信装置の受信処理部は360°ビデオデータに関する情報を受信することができる。
一実施例において、360°ビデオ受信装置は360°ビデオ送信装置から360°ビデオデータに関する情報を受信し、360°ビデオデータに関する情報は、例えば、360°送信装置で符号化されたピクチャに関する情報及び360°ビデオデータに関するメタデータに基づいてカプセル化(encapsulation)して導き出されたファイルを含む。但し、これに限られない。
一実施例による360°デオ受信装置は、360°ビデオデータに関する情報から符号化されたピクチャに関する情報及びメタデータを得る(S2810)。より具体的には、360°ビデオ受信装置の受信処理部、メタデータパーサー又はカプセル除去処理部は、360°ビデオデータに関する情報から符号化されたピクチャに関する情報及びメタデータを得ることができる。
一実施例による360°ビデオ受信装置は、符号化されたピクチャに関する情報に基づいてピクチャを復号する(S2820)。より具体的には、360°ビデオ受信装置のデータ復号器は符号化されたピクチャに関する情報に基づいてピクチャを復号する。
一実施例による360°ビデオ受信装置は、メタデータに基づいて復号されたピクチャをレンダリングする(S2830)。より具体的には、360°ビデオ受信装置のレンダラーはメタデータに基づいて復号されたピクチャをレンダリングする。
図28及び図29に示された360°ビデオ受信装置及び360°ビデオ受信装置の動作方法によれば、一実施例による360°ビデオ受信装置は、360°ビデオデータに関する情報を受信し(S2800)、360°ビデオデータに関する情報から符号化されたピクチャに関する情報及びメタデータを得(S2810)、符号化されたピクチャに関する情報に基づいてピクチャを復号し(S2820)、メタデータに基づいて復号されたピクチャをレンダリング(S2830)することができ、この時、メタデータは360°ビデオデータ内のビューポイントグループに含まれた少なくとも一つのビューポイントが互いに近接しているか否かを示す非近接フラグ情報を含むことを特徴とする。これにより、360°ビデオ内でビューポイントグループに含まれた少なくとも一つのビューポイントが互いに近接しているか否かを示す非近接フラグ情報を効果的にシグナリングすることができる。
上述した各々のパート、モジュール又はユニットは、メモリ(又は格納ユニット)に格納された連続する実行過程を行うプロセッサであるか、又はハードウェアパートである。上述した実施例に記載された各々の段階は、プロセッサ又はハードウェアパートにより行われることができる。上述した実施例に記載された各々のモジュール/ブロック/ユニットは、ハードウェア/プロセッサとして動作することができる。また本発明が提示する方法は、コードとして実行されることができる。このコードはプロセッサが読み取り可能な格納媒体に記録されることができ、よって装置が提供するプロセッサにより読み取られることができる。
上述した実施例において、上記方法は一連の段階又はブロックで順序図に基づいて説明されているが、本発明は段階の順序に限定されるものではなく、ある段階は前述と異なる段階と異なる順序に又は同時に発生することができる。また、当業者であれば、順序図に示す段階が排他的でなく、他の段階が含まれたり、或いは順序図の一つ又はその以上の段階が本発明の範囲に影響を及ぼさずに削除可能であること理解することができる。
本発明において、実施例がソフトウェアで具現される時、上述した技法は、上述した機能を遂行するモジュール(過程、機能など)で具現されることができる。モジュールはメモリに格納され、プロセッサにより実行されることができる。メモリはプロセッサの内部又は外部にあり、よく知られた多様な手段でプロセッサと連結されることができる。プロセッサはASIC(application−specific integrated circuit)、他のチップセット、論理回路及び/又はデータ処理装置を含む。メモリはROM(read−only memory)、RAM(random access memory)、フラッシュメモリ、メモリカード、格納媒体及び/又は他の格納装置を含む。