JP5614900B2 - ３ｄ映像符号化フォーマット - Google Patents

Description

関連出願の相互参照
本願は、２００９年５月１日に出願された「３Ｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｆｏｒｍａｔｓ」と題する米国仮出願第６１／２１５１５４号の出願日、２００９年５月１１日に出願された「Ｒｅｆｅｒｅｎｃｅ Ｐｉｃｔｕｒｅｓ ｆｏｒ ３Ｄ Ｖｉｄｅｏ」と題する米国仮出願第６１／２１５８７４号の出願日、および２０１０年３月４日に出願された「Ｅｘｔｅｎｄｅｄ ＳＰＳ ｆｏｒ ３ＤＶ ｓｅｑｕｅｎｃｅｓ」と題する米国仮出願第６１／３１０４９７号の出願日の利益を主張するものである。

符号化システムに関する実施態様について述べる。様々な具体的な実施態様は、３次元（３Ｄ）映像符号化方式に関する。

３次元テレビジョン（３ＤＴＶ）や自由視点映像（ＦＶＶ）など、新たな映像の応用を促進するために、従来の２Ｄ映像と奥行きマップの両方を含む３Ｄ映像（３ＤＶ）データ・フォーマットを利用して、ユーザ・エンドで追加ビューを描画することができるようにすることができる。このような３ＤＶフォーマットの例としては、２次元（２Ｄ）映像とそれに対応する奥行きマップとを含む、２Ｄプラス・デプス（２Ｄ＋Ｚ）や、２Ｄ＋Ｚと隠蔽（ｏｃｃｌｕｓｉｏｎ）映像に隠蔽奥行きを加えたものとを含む、レイヤ・デプス・ビデオ（Ｌａｙｅｒｅｄ Ｄｅｐｔｈ Ｖｉｄｅｏ）（ＬＤＶ）などがある。このような３ＤＶフォーマットのその他の例としては、マルチビュー・プラス・デプス（ＭＶＤ）やディスパリティ・エンハンスト・ステレオ（ＤＥＳ）などがある。ＭＶＤは、２Ｄ＋Ｚを拡張したものであり、視点の異なる複数の２Ｄ＋Ｚを含む。ＤＥＳは、異なる２つの視点からの２つのＬＤＶで構成される。３ＤＶフォーマットの別の例として、左ビューの１つのＬＤＶと、右ビューの２Ｄ映像とで構成される、レイヤ・デプス・ビデオ・プラス・ライト・ビュー（Ｌａｙｅｒ Ｄｅｐｔｈ Ｖｉｄｅｏ ｐｌｕｓ Ｒｉｇｈｔ Ｖｉｅｗ）がある。ユーザ・エンドでは、３ＤＶコンテンツを復号するのに様々な構成要素を組み合わせて使用しているので、こうした全てのフォーマットで如何にしてデータを伝達（符号化および伝送）するかは、難しい問題である。

一般的な特徴によれば、所与の時点の所与のビューについての異なる３次元（３Ｄ）情報を記述する複数のピクチャが、符号化される。上記符号化された複数のピクチャについて、３Ｄ処理に対応した構造に符号化されたピクチャがどのように適応するかを示すシンタックス要素が生成される。上記構造は、これら複数のピクチャのコンテンツ・タイプを規定する。上記符号化された複数のピクチャおよびシンタックス要素を含むビットストリームが生成される。上記シンタックス要素を含むことにより、符号化されたビットストリームのレベルで、上記構造における符号化された複数のピクチャの間の関係を示す指示が与えられる。

別の一般的な特徴によれば、映像信号または映像構造は、複数の符号化されたピクチャのための１つまたは複数のピクチャ部分を含む。上記複数の符号化されたピクチャは、所与の時点の所与のビューについての異なる３次元（３Ｄ）情報を記述する。上記映像信号または映像構造は、上記符号化された複数のピクチャについて、３Ｄ処理に対応した構造に符号化されたピクチャがどのように適応するかを示すシンタックス要素のための１つまたは複数のシンタックス部分も含む。上記構造は、これら複数のピクチャのコンテンツ・タイプを規定する。上記映像信号にシンタックス要素を含むことにより、符号化されたビットストリームのレベルで、構造における符号化された複数のピクチャの間の関係を示す指示が与えられる。

別の一般的な特徴によれば、符号化された複数のピクチャは、ビットストリームからアクセスされる。上記複数のピクチャは、所与の時点の所与のビューについての異なる３次元（３Ｄ）情報を記述する。シンタックス要素は、上記ビットストリームからアクセスされる。上記シンタックス要素は、これらの符号化された複数のピクチャについて、３Ｄ処理に対応した構造に符号化されたピクチャがどのように適応するかを示す。上記構造は、複数のピクチャ間の規定された関係を与える。上記符号化された複数のピクチャは、復号される。復号されたピクチャは、複数のピクチャ間の規定された関係を示す出力フォーマットで供給される。

別の一般的な特徴によれば、シンタックス要素は、１組のデータからアクセスされる。上記シンタックス要素は、３Ｄ処理に対応した構造に符号化されたピクチャがどのように適応するかを示す。上記構造は、符号化されたピクチャのコンテンツ・タイプを規定する。上記１組のデータ・セットから、符号化されたピクチャのうちの特定のピクチャが抽出される。上記符号化されたピクチャのうちのこれら特定のピクチャは、所与の関心のあるビューに属し、且つ所与の関心のあるコンテンツ・タイプを有するピクチャ、またはこの所与の関心のあるビューおよびこの所与の関心のあるコンテンツ・タイプの参照に対応する。上記所与の関心のあるビューおよび所与の関心のあるコンテンツ・タイプに対応するピクチャの抽出は、シンタックス要素および示される構造に基づく。

１つまたは複数の実施態様の詳細を、添付の図面および以下の説明に記述する。実施態様は、１つの特定の方法で記述されている場合でも、様々な方法で構成する、または実施することができることは明らかであろう。例えば、ある実施態様は、方法として実行することも、例えば１組の動作セットを実行するように構成された装置や１組の動作セットを実行する命令を記憶した装置などの装置として実施することも、あるいは信号中に実装することもできる。その他の特徴およびフィーチャも、以下の詳細な説明を添付の図面および特許請求の範囲と関連付けて考慮すれば、明らかになるであろう。

奥行きマップの一例を示す図である。 ＬＤＶフォーマットの４つの構成要素の一例を示す図である。 ３ＤＶエンコーダの実施態様を示すブロック図／流れ図である。 ３ＤＶデコーダの実施態様を示すブロック図／流れ図である。 ３ＤＶレイヤ・エンコーダの実施態様を示すブロック図／流れ図である。 ３ＤＶレイヤ・デコーダの実施態様を示すブロック図／流れ図である。 映像伝送システムの実施態様を示すブロック図／流れ図である。 映像受信システムの実施態様を示すブロック図／流れ図である。 映像処理デバイスの実施態様を示すブロック図／流れ図である。 ３ＤＶ符号化構造の一例を示す図である。 ネットワーク抽象化レイヤ（ＮＡＬ）ユニット・ストリームの第１の例を示すブロック図／流れ図である。 ＮＡＬユニット・ストリームの第２の例を示すブロック図／流れ図である。 ３ＤＶコンテンツを復号する方法の一例を示す流れ図である。 ３ＤＶコンテンツを復号する方法の一例を示す流れ図である（図１３Ａの続き）。 ３ＤＶコンテンツを符号化する方法の一例を示す流れ図である。 ３ＤＶコンテンツを符号化する方法の一例を示す流れ図である（図１４Ａの続き）。 レイヤ間依存関係構造の一例を示すブロック図である。 符号化プロセスの参照ピクチャ・リストを構築する方法の一例を示す流れ図である。 復号プロセスの参照ピクチャ・リストを構築する方法の一例を示す流れ図である。 ３ＤＶコンテンツの拡張シーケンス・パラメータ・セットのＮＡＬユニットを符号化する方法の一例を示す流れ図である。 ３ＤＶコンテンツの拡張シーケンス・パラメータ・セットのＮＡＬユニットを復号する方法の一例を示す流れ図である。 拡張を有するシーケンス・パラメータ・セットを符号化する方法の一例を示す流れ図である。 拡張を有するシーケンス・パラメータ・セットを復号する方法の一例を示す流れ図である。 ３ＤＶコンテンツのレイヤ間依存関係構造のシーケンス・パラメータ・サブセットを符号化する第１の方法の一例を示すブロック図／流れ図である。 ３ＤＶコンテンツのレイヤ間依存関係構造のシーケンス・パラメータ・サブセットを復号する第１の方法の一例を示すブロック図／流れ図である。 ３ＤＶコンテンツのレイヤ間依存関係構造のシーケンス・パラメータ・サブセットを符号化する第２の方法の一例を示すブロック図／流れ図である。 ３ＤＶコンテンツのレイヤ間依存関係構造のシーケンス・パラメータ・サブセットを復号する第２の方法の一例を示すブロック図／流れ図である。 ３ＤＶコンテンツを符号化する方法の一例を示す流れ図である。 ３ＤＶコンテンツを復号する方法の一例を示す流れ図である。 符号化動作用の参照ピクチャ・リストを構築する方法の一例を示す流れ図である。 図２８の方法で実施することができる２Ｄ映像レイヤ・ピクチャを処理する方法の一例を示す流れ図である。 ３ＤＶコンテンツを符号化し、レイヤ間依存関係構造を伝達する方法の一例を示す流れ図である。 ３ＤＶコンテンツを復号し、レイヤ間依存関係構造を伝達する方法の一例を示す流れ図である。 ＮＡＬユニット・ストリームの一例を示すブロック図／流れ図である。 レイヤ間依存関係構造を利用することによってネットワーク・トラフィックを管理するシステムの一例を示すブロック図／流れ図である。 レイヤ間依存関係構造を利用することによってネットワーク・トラフィックを管理する方法の一例を示す流れ図である。

当技術分野では、通常、３Ｄ映像（３ＤＶ）の基本原則は、１つのシーンまたはオブジェクトの異なるビューをユーザの左右の目それぞれに対して与えることにより、ユーザがそのシーンまたはオブジェクトの奥行きを感じることができるようにすることであると理解されている。さらに、ユーザ・エクスペリエンスを向上させるために、伝送されているビュー以外の仮想ビューを描画して、例えば、知覚される異なる奥行きの範囲に対して基線長を調整することもできる。これらの目的の１つまたは複数を達成するために、上記のように、３Ｄ映像（３ＤＶ）表現フォーマットは、例えば映像や奥行き、また場合によっては２Ｄ＋Ｚ（ＭＶＤ）やＬＤＶ（ＤＥＳ）などのさらに補足的な情報など、様々なレイヤを含むことができる。３ＤＶコンテンツの奥行きおよびその他の補足的情報の概念をよりよく例示するために、図１および図２を参照する。

図１は、従来の映像に対応する奥行きマップ１００の一例を示す図である。さらに、図２は、ＬＤＶフォーマットの４つの構成要素の一例、すなわち２Ｄ映像２０２およびその奥行き（Ｚ）２０４と、同じシーンの隠蔽映像２０６およびその隠蔽奥行き２０８とを含む図である。上述のデータ・フォーマットの符号化および伝送は、多くの点で困難である。例えば、符号化効率以外に、旧来のＡｄｖａｎｃｅｄ Ｖｉｄｅｏ ｃｏｄｉｎｇ（ＡＶＣ）／Ｍｕｌｔｉｖｉｅｗ Ｃｏｄｉｎｇ（ＭＶＣ）デコーダがビットストリームから可視映像を抽出することができるように、同期や（従来のモノスコープ２Ｄ映像との）後方互換性などの機能も提供することが好ましい。

これらの問題の少なくとも一部に対処できる１つの解決策は、各ビューおよび／またはレイヤの符号化および伝送を独立して行うサイマルキャスト（ｓｉｍｕｌｃａｓｔ）である。この手法では、個々のビュー／レイヤをそれぞれ符号化および復号し、それらのビュー／レイヤを同期させてシステム・レベルまたはアプリケーション・レベルで可視画像にするために、複数のエンコーダおよびデコーダを使用することがある。例えば、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）−Ｃ Ｐａｒｔ３（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ（ＩＳＯ）／Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｅｌｅｃｔｒｏｔｅｃｈｎｉｃａｌ Ｃｏｍｍｉｓｓｉｏｎ（ＩＥＣ）２３００２−３）では、２Ｄ＋Ｚのシステム・フレームワークを指定している。通常の実施態様では、映像と奥行きの間でシステム・レベルの同期を用いている。映像および奥行きは、任意の既存の映像符号化規格を用いて符号化することができる。しかし、通常の実施態様では、映像および奥行きの符号化が切り離されている。従って、サイマルキャストのコストは、伝送するビューおよび／またはレイヤの数だけ増大する。さらに、異なるビューおよび／またはレイヤを別々に符号化するので、ビューおよび／またはレイヤ間で冗長性があっても、通常は、それを利用して符号化効率を高めることは行われない。

それに対して、本明細書に記載する１つまたは複数の実施態様では、レイヤ間符号化を可能にして、レイヤ間の冗長性を活用することにより、ＡＶＣ／ＭＶＣシステムの後方互換性に加えて、より高い符号化効率を実現することができる。特に、１つまたは複数の実施態様では、符号化レベルでのビューおよび／またはレイヤの同期を可能にして、これらの利点の少なくとも一部を達成する手段を提供する。例えば、本明細書に記載する少なくとも１つの実施態様では、ビュー／レイヤのレイヤ間符号化および同期を効率的に可能にするために、ＡＶＣのＮＡＬユニット設計に基づく新規の３ＤＶプレフィックス・ネットワーク抽象化レイヤ（ＮＡＬ）ユニットおよび新規の３ＤＶ ＮＡＬユニット・ヘッダ拡張を提案する。このハイレベル・シンタックスは、ＡＶＣビットストリームやＳｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＳＶＣ）／ＭＶＣビットストリームなどのビットストリームから３ＤＶ構成要素を抽出する方法を示している。従って、この手法は、３ＤＶ構成要素を符号化済みビットストリーム（ＳＶＣレイヤやＭＶＣビューなど）中で結合することができるので、システム・レベルで異なる３ＤＶ構成要素間の同期を行う必要がないという利点がある。別の可能性のある利点として、このように符号化を行うときには、レイヤ間またはビュー間の冗長性を除去することができる。さらに、新規のＮＡＬユニット設計は、ＭＶＣとの互換性を維持することができ、また、任意の将来のカプセル化符号化技術との互換性も維持して、高度な圧縮効率を実現することもできる。

以下に述べるように、システム・レベルではなく符号化レベルにおいて異なるビュー／レイヤの同期を可能にするために、１つまたは複数の実施態様では、３ＤＶ ＮＡＬユニット設計を、３ＤＶビュー識別子（ＩＤ）および３ＤＶレイヤＩＤと関連付ける。さらに、ビュー間／レイヤ間の冗長性をさらに活用するために、ビュー間／レイヤ間の予測を利用して、インタリーブ方式を用いたＡＶＣと比較してより高い符号化効率を実現する。さらに、３ＤＶ補足レイヤのＮＡＬユニット設計は、ＭＶＣ／ＡＶＣとの２Ｄビュー・レイヤ互換性に影響を及ぼすことなく、新たな符号化モード／ツールを開発することを可能にしながら、完全な後方互換性も実現することができる。

様々な実施形態は、複数の参照予測を利用することによって３ＤＶコンテンツを含むビットストリームの符号化および復号を可能にする参照リストの構成に関する。例えば、３ＤＶ符号構造では、少なくとも３つのタイプの参照ピクチャがある可能性がある。例えば、時間的参照ピクチャ、ビュー間参照ピクチャ、および異なる３ＤＶレイヤからの参照ピクチャなどである。異なる３ＤＶレイヤからの参照ピクチャとしては、例えば、奥行きレイヤの参照として使用される２Ｄ映像レイヤなどが挙げられる。本出願に記載する少なくとも１つの実施形態では、これら３つのタイプの参照ピクチャを参照ピクチャ・リスト内にどのように配列するかに関する概念および実施態様を提供する。例えば、予測モードでマクロブロック（ＭＢ）を符号化するときには、エンコーダは、利用可能な複数の参照ピクチャの中で、どの１つまたは複数のピクチャが参照として使用されるかを示すことができる。ここで、リスト中の指標により、どの参照ピクチャが使用されるかを示すことができる。以下でさらに述べるように、１つまたは複数の実施形態では、レイヤ間予測を可能にするために、１つまたは複数のレイヤ間参照ピクチャをリスト内に設けることができる。

上記のように、１つまたは複数の実施形態には多くの利点があり、そのうちの１つは、ＭＶＣとの潜在的な互換性である。すなわち、これらの実施形態の１つによる３ＤＶビットストリームが旧来のＭＶＣデコーダに送られると、２Ｄ映像（例えば以下ではレイヤ０として示す）を、復号して出力することができる。様々なレイヤを用いた効率的な３ＤＶコンテンツの符号化を同時に可能にしながら、ＭＶＣとの互換性をさらに支援するために、さらに様々な実施形態は、シーケンス・パラメータ・セット（ＳＰＳ）の構築および信号通信を対象としている。当業者なら理解するであろうが、ＳＰＳは、１つのピクチャ・シーケンスの複数のピクチャ間で共有される共通の性質を指定することができる。このような共通の性質としては、例えば、ピクチャ・サイズ、利用している任意選択の符号化モード、マクロブロック／スライス・グループ・マップ（ｍａｃｒｏｂｌｏｃｋ ｔｏ ｓｌｉｃｅ ｇｒｏｕｐ ｍａｐ）などがあり、これらはそれぞれ、１つのシーケンス中の複数のピクチャの間で必要に応じて共有することができる。少なくとも１つの実施形態では、ＳＰＳの拡張を利用して、３ＤＶコンテンツの符号化および復号に使用される新規のシーケンス・パラメータを信号通信する。さらに、この拡張ＳＰＳに対して、別個の新規のＮＡＬユニット・タイプを利用することができる。以下でさらに述べるように、拡張ＳＰＳを、ルータなどのネットワーク・デバイスが使用して、３ＤＶコンテンツ・ストリーミングのビットレートの適合を行うことができる。

実施形態について詳細に述べる前に、説明する概念の理解を容易にするために、使用する用語について簡単に述べておく。

［用語］
本明細書で使用する「２Ｄ映像」レイヤは、一般に、従来の映像信号を指す。

本明細書で使用する「奥行き」レイヤは、一般に、シーン中のオブジェクトについての距離情報を示すデータを指す。「奥行きマップ」は、奥行きレイヤの通常の例である。

本明細書で使用する「隠蔽映像」レイヤは、一般に、特定の視点からは遮られる映像情報を指す。隠蔽映像レイヤは、通常は、２Ｄ映像レイヤの背景情報を含む。

本明細書で使用する「隠蔽奥行き」レイヤは、一般に、ある特定の視点からは遮られる奥行き情報を指す。隠蔽奥行きレイヤは、通常は、奥行きレイヤの背景情報を含む。

本明細書で使用する「透明度」レイヤは、一般に、奥行きの不連続部または奥行きの境界を示すピクチャを指す。通常の透明度レイヤは２値情報を有し、その２つの値の一方は、奥行きが、近接する奥行き値に対して特定のしきい値を超える不連続性を有する位置を示す。

「３ＤＶビュー」は、本明細書では、ＭＶＣで使用する「ビュー」とは異なる、１つのビュー位置からのデータ・セットとして定義する。例えば、３ＤＶビューはＭＶＣのビューよりも多くのデータを含むことができる。
２Ｄ＋Ｚフォーマットでは、３ＤＶビューは２Ｄ映像およびその奥行きマップという、２つのレイヤを含むことができる。ＬＤＶフォーマットでは、３ＤＶビューは、２Ｄ映像、奥行きマップ、隠蔽映像、および隠蔽奥行きマップという、４つのレイヤを含むことができる。さらに、特に透明度マップを、３ＤＶビュー内のもう１つのレイヤ・データ・タイプとすることができる。

「３ＤＶレイヤ」は、３ＤＶビューのレイヤの１つとして定義する。３ＤＶレイヤの例としては、例えば、２Ｄビューまたは２Ｄ映像、奥行き、隠蔽映像、隠蔽奥行き、および透明度マップなどがある。２Ｄビューまたは２Ｄ映像以外のレイヤは、「３ＤＶ補足レイヤ」とも定義される。１つまたは複数の実施形態では、３ＤＶデコーダを、３ｄｖ＿ｌａｙｅｒ＿ｉｄを用いて、１つのレイヤを特定して、このレイヤをその他のレイヤと区別するように構成することができる。１つの実施態様では、３ｄｖ＿ｌａｙｅｒ＿ｉｄは、表１のように定義される。ただし、本明細書に与える教示に鑑みて当業者なら理解するであろうが、これらのレイヤは、その他の方法で定義し、識別することもできることに留意されたい。

図３は、ハイレベル汎用３ＤＶエンコーダを示す図、図４は、ハイレベル汎用３ＤＶデコーダ４００を示す図である。エンコーダ３００／デコーダ４００は、複数のレイヤ・エンコーダ／デコーダと、１つの３ＤＶ参照バッファとで構成される。例えば、図３に示すように、２Ｄビュー・レイヤ、奥行きレイヤ、隠蔽・ビュー・レイヤ、隠蔽奥行きレイヤ、透明度マップ・レイヤなどを含むことができる３ＤＶコンテンツ信号３０２が、様々なレイヤ・エンコーダに入力される。具体的には、エンコーダ・システム／装置３００は、ＡＶＣ互換性を有することもある、２Ｄレイヤを符号化するように構成された２Ｄレイヤ・エンコーダ３０４、エンハンスト２Ｄレイヤを符号化するように構成されたエンハンスト２Ｄレイヤ・エンコーダ３０６、奥行きレイヤを符号化するように構成された奥行きレイヤ・エンコーダ３０８、隠蔽ビュー・レイヤを符号化するように構成された隠蔽ビュー・レイヤ・エンコーダ３１０、隠蔽奥行きレイヤを符号化するように構成された隠蔽奥行きレイヤ・エンコーダ３１２、および透明度レイヤを符号化するように構成された透明度レイヤ・エンコーダ３１４を含む。従って、各レイヤを、異なるエンコーダおよび／または符号化技術を用いて符号化することができる。

本明細書では、エンハンスト２Ｄレイヤは、一般に、ＡＶＣ、ＭＶＣ、ＳＶＣ、または他の基礎となる規格と互換性のあるレイヤからこのレイヤを区別するために使用される。例えば、エンハンスト２Ｄレイヤは、通常は、ＭＶＣとの互換性がない。エンハンスト２Ｄレイヤは、例えばレイヤ間参照を用いるなどの新たな符号化ツールを可能にするからである。従って、これらのレイヤは、一般にＭＶＣとの後方互換性がない。

「エンハンスト２Ｄレイヤ」（または補足レイヤ）という用語は、ＭＶＣで符号化することができるレイヤを参照するために用いることができるが、表示が行われないと予想されたためにＭＶＣで符号化されているとは通常記述されないレイヤを指してもよいことに留意されたい。例えば、一連の奥行きレイヤは、ＭＶＣで一連のピクチャとして処理され、ＭＶＣで符号化することができる。しかし、通常は奥行きレイヤを表示することはないので、これらのレイヤの識別および符号化には、ＭＶＣを用いる以外の別の方法を用いることが望ましいことが多い。

各レイヤで、異なる参照を使用することもできる。この参照は、符号化（復号）しているピクチャ／ブロックとは異なるレイヤのものであってもよい。異なるレイヤからの参照は、３ＤＶ参照バッファ３１６（３ＤＶ参照／出力バッファ４１４）から取得することができる。図３に示すように、各レイヤ・エンコーダは、３ＤＶ参照バッファ３１６と信号通信して様々なモードの入力信号３０２の符号化を可能にし、出力信号３１８を生成する。

３ＤＶ参照バッファ３１６を利用することにより、３ＤＶフォーマットの各レイヤは、例えば動き補償およびまたはディスパリティ補償が施された同じレイヤ内の時間的参照および／またはビュー間参照など、そのレイヤ自体からの参照を用いて、且つ／または様々なレイヤ間のレイヤ間予測を用いて、符号化することができる。例えば、レイヤ間予測では、例えば動きベクトルや参照ピクチャ番号など、別のレイヤからの動き情報を再利用して、現在のレイヤを符号化することもでき、モーション・スキップ・モードと呼ばれる。このようにして、出力信号３１８は、１つまたは複数の３ＤＶビューの様々なレイヤ情報を混合（ｉｎｔｅｒｌｅａｖｅ）することができる。レイヤ間予測は、他のレイヤの評価に基づく任意の種類の技術のものとすることができる。

図４に示すように、デコーダ・システム／装置４００に関しては、システム４００は、信号３１８を入力することができる様々なレイヤ・デコーダを含む。具体的には、デコーダ・システム／装置４００は、ＡＶＣ互換性を有することもある、２Ｄレイヤを復号するように構成された２Ｄレイヤ・デコーダ４０２、エンハンスト２Ｄレイヤを復号するように構成されたエンハンスト２Ｄレイヤ・デコーダ４０４、奥行きレイヤを復号するように構成された奥行きレイヤ・デコーダ４０６、隠蔽・ビュー・レイヤを復号するように構成された隠蔽・ビュー・レイヤ・デコーダ４０８、隠蔽奥行きレイヤを復号するように構成された隠蔽奥行きレイヤ・デコーダ４１０、および／または透明度レイヤを復号するように構成された透明度レイヤ・デコーダ４１２を含む。

図４に示すように、各レイヤ・デコーダは、レイヤ・デコーダから受信した復号済みレイヤ情報を構文解析して、入力信号に含まれるレイヤが、３Ｄ処理に対応する構造にどのように適応するかを判定するように構成することができる、３ＤＶ参照／出力バッファ４１４と信号通信している。このような３Ｄ処理としては、例えば、本明細書で述べるような３Ｄレイヤの符号化や、受信器または表示ユニットにおける追加ピクチャのレンダリング（合成処理）などがある。レンダリングでは、例えば、奥行きピクチャを使用して、２Ｄ映像および／または隠蔽ピクチャを歪ませて（ｗａｒｐ）、描画されたピクチャの穴を背景情報で埋めることもできる。

さらに、３ＤＶ参照／出力バッファ４１４は、ユーザへの提示用に、３ＤＶ互換フォーマットで出力信号４１６を生成するように構成することができる。フォーマット化された３ＤＶコンテンツ信号４１６は、もちろん、例えば２Ｄビュー・レイヤ、奥行きレイヤ、隠蔽ビュー・レイヤ、隠蔽奥行きレイヤ、および透明度マップ・レイヤを含むことができる。この出力バッファは、図４に示すように参照バッファと一体化して実装することもできるが、その代わりに他の実施形態では、参照バッファと出力バッファを別々のバッファとすることもできる。

エンコーダ３００およびデコーダ４００のその他の実施態様では、使用するレイヤの数がこれより多くても少なくてもよい。さらに、上記に示したレイヤ以外のレイヤを使用することもできる。

３ＤＶ参照バッファ３１６および３ＤＶ参照／出力バッファ４１４において用いている「バッファ」という用語は、インテリジェント・バッファであることは明らかであろう。このようなバッファは、例えば、ピクチャを記憶し、参照（または参照の一部分）を提供し、出力するためにピクチャを再配列するために使用することができる。さらに、このようなバッファは、他の様々な処理動作を実行するために使用することができ、例えば、仮想参照デコーダ・テスト、マーキング・コマンドの処理（例えばＡＶＣにおけるメモリ管理制御動作）、および復号済みピクチャ・バッファ管理などの処理動作を実行するために使用することができる。

図５は、レイヤ・エンコーダ３０４〜３１４の何れか１つまたは複数を実施するために使用することができる一般的な３ＤＶレイヤ・エンコーダ５００を示すハイレベル・ブロック図／流れ図、図６は、レイヤ・デコーダ４０２〜４１２の何れか１つまたは複数を実施するために使用することができる一般的な３ＤＶレイヤ・デコーダ６００を示すハイレベル・ブロック図／流れ図である。各レイヤ・エンコーダ３０４〜３１４は、例えば図５に示すように、対応するレイヤに対して概ね同様に、特定の目的に適うように設計することができることに留意されたい。逆に、本明細書に与える教示に鑑みて理解されるであろうが、レイヤ・エンコーダは、それぞれ独自の特性をよりよく利用するように異なる構成にすることもできる。同様に、デコーダ４０２〜４１２は、例えば図６に示すように、対応するレイヤに対して概ね同様に設計することができる。また逆に、レイヤ・デコーダは、それぞれ独自の特性をよりよく利用するように異なる構成にすることもできる。

ＭＶＣエンコーダに関しては、入力が、複数のビューで構成されることに留意されたい。各ビューは、従来の２Ｄ映像である。従って、ＡＶＣエンコーダと比較して、通常のＭＶＣエンコーダは、ディスパリティ推定ブロック、ディスパリティ補償ブロックおよびビュー間参照バッファなど、追加ブロックを含む。同様に、図５および図６は、３ＤＶ参照のブロックおよびレイヤ間予測のブロックを含んでいる。３ＤＶエンコーダでは、入力は、複数の３Ｄビューで構成される。上記のように、各３Ｄビューは、いくつかのレイヤを含むことができる。従って、各レイヤの符号化方法は、それぞれ独自のフィーチャを利用するように異なる設計にすることができる。その結果、３ＤＶエンコーダは、図３に示すように複数のレイヤ・エンコーダに分割することができる。しかし、レイヤ・エンコーダは、緊密に接続することもできる。レイヤ・エンコーダで用いられる技術は、所与のシステムに合わせて望み通りに調整することができる。各レイヤは映像信号として現れるので、これらのレイヤは、ハイレベルでは図５に示すように同様の構造を有することができる。なお、より低い、より具体的なレベルでは、これらのレイヤ・エンコーダの設計が異なる可能性もあることに留意されたい。もちろん、一実施形態では、全てのレイヤを符号化するように構成されたエンコーダを１つしか使用しないこともある。

図５に示すハイレベル図では、３ＤＶレイヤ・エンコーダ５００は、入力信号５０２中の３ＤＶビューｉの３ＤＶビュー・レイヤを受信して、それらを互いに分割するように構成されたレイヤ分割器（レイヤ・パーティショナ）５０４を含むことができる。分割器５０４は、分割器５０４から１組の分割済みレイヤのセットをそれぞれ受信する、加算器または結合器５０６、変位（動き／ディスパリティ）補償モジュール５０８、および変位（動き／ディスパリティ）推定モジュール５１０と信号通信している。加算器５０６に対するもう１つの入力は、スイッチ５１２を介して受信される、様々な可能な参照ピクチャ情報のうちの１つである。

例えば、スイッチ５１２と信号通信しているモード決定モジュール５３６が、符号化モードが、現在符号化中の同じブロックまたはスライスを基準とするイントラ予測であると判定した場合には、加算器は、イントラ予測モジュール５３０からその入力を受信する。あるいは、モード決定モジュール５３６が、符号化モードが、現在符号化中のブロックまたはスライスとは異なる、現在処理中の同じフレームもしくは３ＤＶビューもしくは３ＤＶレイヤのブロックまたはスライス、または以前に処理した別のフレームもしくは３Ｄビューもしくは３ＤＶレイヤのブロックまたはスライスを基準とする変位補償および推定であると判定した場合には、加算器は、図５に示すように変位補償モジュール５０８からその入力を受信する。さらに、モード決定モジュール５３６が、符号化モードが、現在処理中のレイヤとは異なる、現在処理中の同じフレームもしくは３ＤＶビューの３ＤＶレイヤ、または以前に処理した別のフレームもしくは３ＤＶビューの３ＤＶレイヤを基準とする３ＤＶレイヤ間予測であると判定した場合には、加算器は、３ＤＶ参照バッファ５３２と信号通信している３ＤＶレイヤ間予測モジュール５３４からその入力を受信する。

加算器５０６は、１つまたは複数の３ＤＶレイヤと、予測情報、補償情報および／または推定情報を含む信号を、変換モジュール５１４に供給する。変換モジュール５１４は、その入力信号を変換して、変換済み信号を量子化モジュール５１６に提供するように構成されている。量子化モジュール５１６は、その受信信号に対して量子化を実行し、量子化済み情報をエントロピ・エンコーダ５１８に出力するように構成される。エントロピ・エンコーダ５１８は、その入力信号に対してエントロピ符号化を実行して、ビットストリーム５２０を生成するように構成される。逆量子化モジュール５２２は、量子化モジュール５１６から量子化済み信号を受信して、その量子化済み信号について逆量子化を実行するように構成される。逆変換モジュール５２４は、モジュール５２２から逆量子化済み信号を受信して、その受信信号に対して逆変換を実行するように構成される。モジュール５２２および５２４は、加算器５０６から出力された信号を再生成または再構成する。

加算器または結合器５２６は、逆変換モジュール５２４から受信した信号とスイッチ５１２から受信した信号を加算（結合）し、その結果得られた信号をイントラ予測モジュール５３０およびデブロッキング・フィルタ５２８に出力する。さらに、イントラ予測モジュール５３０は、その受信信号を用いて、上述のようにイントラ予測を実行する。同様に、デブロッキング・フィルタ５２８は、加算器５２６から受信した信号をフィルタリングし、フィルタリング済み信号を３ＤＶ参照バッファ５３２に提供する。

３ＤＶ参照バッファ５３２は、その受信信号を構文解析する。３ＤＶ参照バッファ５３２は、要素５３４、５０８および５１０による上述のレイヤ間の変位補償／推定符号化を支援する。３ＤＶ参照バッファ５３２は、例えば、様々な３ＤＶレイヤの全てまたは一部を提供する。

再度図６を参照すると、３ＤＶレイヤ・デコーダ６００は、ビットストリーム受信器６０２を用いてビットストリーム３１８を受信するように構成することができ、ビットストリーム受信器６０２は、ビットストリーム解析器６０４と信号通信して、ビットストリームを解析器６０４に供給する。ビットストリーム・解析器６０４は、残留ビットストリーム６０５をエントロピ・デコーダ６０６に伝送し、制御シンタックス要素６０７をモード選択モジュール６２２に伝送し、変位（動き／ディスパリティ）ベクトル情報６０９を変位補償（動き／ディスパリティ）モジュール６１８に伝送し、現在復号中の３ＤＶレイヤ以外の３ＤＶレイヤからの符号化情報６１１を３ＤＶレイヤ間予測モジュール６２０に伝送するように構成することができる。逆量子化モジュール６０８は、エントロピ・デコーダ６０６から受信したエントロピ復号済み信号に対して逆量子化を実行するように構成することができる。さらに、逆変換モジュール６１０は、逆量子化モジュール６０８から受信した逆量子化済み信号について逆変換を実行し、逆変換済み信号を加算器または結合器６１２に出力するように構成することができる。

加算器６１２は、利用している復号モードに応じて、その他にも様々な信号の１つを受信することができる。例えば、モード決定モジュール６２２は、制御シンタックス要素６０７を構文解析および解析することにより、３ＤＶレイヤ間予測、変位補償またはイントラ予測符号化が、エンコーダ５００が現在処理しているブロックに対して実行されたかどうかを判定することができる。判定したモードに応じて、モード選択制御モジュール６２２は、制御シンタックス要素６０７に基づいてスイッチ６２３にアクセスしてこれを制御し、加算器６１２が３ＤＶレイヤ間予測モジュール６２０、変位補償モジュール６１８またはイントラ予測モジュール６１４から信号を受信できるようにすることができる。

ここで、イントラ予測モジュール６１４は、例えば、現在復号中の同じブロックまたはスライスへの参照を用いて、イントラ予測を実行してブロックまたはスライスを復号するように構成することができる。また、変位補償モジュール６１８は、例えば、現在復号中のブロックまたはスライスとは異なる、現在処理中の同じフレームもしくは３ＤＶビューもしくは３ＤＶレイヤのブロックまたはスライス、または以前に処理した別のフレームもしくは３Ｄビューもしくは３ＤＶレイヤのブロックまたはスライスへの参照を用いて、変位補償を実行してブロックまたはスライスを復号するように構成することができる。さらに、３ＤＶレイヤ間予測モジュール６２０は、例えば、現在処理している同じフレームもしくは３ＤＶビューまたは以前に処理した別のフレームもしくは３ＤＶビューの、現在処理しているレイヤとは異なる３ＤＶレイヤへの参照を用いて、３ＤＶレイヤ間予測を実行してブロックまたはスライスを復号するように構成することができる。

予測情報信号または補償情報信号を受信した後で、加算器６１２は、この予測情報信号または補償情報信号を逆変換済み信号と加算して、デブロッキング・フィルタ６０２に伝送することができる。デブロッキング・フィルタ６０２は、その入力信号をフィルタリングして、復号済みピクチャを出力するように構成することができる。また、加算器６１２は、加算済み信号を、イントラ予測に使用できるように、イントラ予測モジュール６１４にも出力することができる。さらに、デブロッキング・フィルタ６０２は、フィルタリング済み信号を３ＤＶ参照バッファ６１６に伝送することができる。３ＤＶ参照バッファ６１６は、その受信信号を構文解析して、要素６１８および６２０による上述のレイヤ間の変位補償復号を可能にし、これを支援するように構成することができる。３ＤＶ参照バッファ６１６は、要素６１８および６２０のそれぞれに対して構文解析済み信号を供給する。この構文解析済み信号は、例えば、様々な３ＤＶレイヤの全てであってもよいし、その一部であってもよい。

本明細書に開示する教示に鑑みて当業者には理解されるであろうが、システム／装置３００、４００、５００および６００は、上記とは異なる構成であってもよく、上記と異なる要素を含んでいてもよいことを理解されたい。

次に、図７を参照すると、図７は、一実施態様による、本明細書に記載する態様を適用することができる映像伝送システム／装置７００を示す図である。映像伝送システム７００は、例えば、例えば衛星、ケーブル、電話回線、地上波放送など様々なメディアの何れかを用いて信号を伝送するヘッドエンド・システムまたは伝送システムとすることができる。この伝送は、インターネットなど何らかのネットワークを介して行うことができる。

映像伝送システム７００は、例えば映像コンテンツおよび奥行きを、その他の３Ｄ補足レイヤとともに生成し、配信することができる。これは、３Ｄ補足レイヤ情報、または例えばデコーダなどの受信器側で３ＤＶ補足レイヤ情報を合成するために使用することができる情報を含む、１つまたは複数の符号化済み信号を生成することによって達成される。

映像伝送システム７００は、エンコーダ７１０と、符号化済み信号を伝送することができる伝送器７２０とを含む。エンコーダ７１０は、映像情報を受信し、この映像情報および／または３ＤＶレイヤ情報に基づいて１つまたは複数の符号化済み信号を生成する。エンコーダ７１０は、例えば、上記で詳細に述べたエンコーダ３００とすることができる。エンコーダ７１０は、例えば様々な情報を受信して、記憶または伝送に適した構造のフォーマットにアセンブルするアセンブリ・ユニットなどの、サブモジュールを含むことができる。この様々な情報としては、例えば、符号化された映像または符号化されていない映像、符号化された奥行き情報または符号化されていない奥行き情報、ならびに例えば動きベクトル、符号化モード指標およびシンタックス要素などの、符号化された要素または符号化されていない要素などが挙げられる。

伝送器７２０は、例えば、符号化済みピクチャおよび／またはそれに関連する情報を表す１つまたは複数のビットストリームを有するプログラム信号７５０を伝送するようにすることができる。通常の伝送器は、例えば、誤り訂正符号化を実行する、信号にデータをインタリーブする、信号中のエネルギーをランダム化する、変調器７２２を用いて１つまたは複数の搬送波に信号を変調するといったうちの１つまたは複数などの機能を実行する。伝送器７２０は、アンテナ（図示せず）を含む、またはアンテナとインタフェースをとることができる。さらに、伝送器７２０の実施態様は、変調器を含むこともあれば、変調器に限定されることもある。

図８を参照すると、図８は、一実施態様による、本明細書に記載する態様を適用することができる映像受信システム／装置８００を示す図である。映像受信システム８００は、例えば、例えば衛星、ケーブル、電話回線、地上波放送など様々なメディアを介して信号を受信するように構成することができる。信号は、インターネットなど何らかのネットワークを介して受信することができる。

映像受信システム８００は、例えば、符号化済み映像を受信して、ユーザに対して表示するため、または記憶するための復号済み映像などを供給する、携帯電話、コンピュータ、セット・トップ・ボックス、テレビジョン、またはその他のデバイスとすることができる。従って、映像受信システム８００は、例えばテレビジョンの画面、コンピュータ・モニタ、コンピュータ（記憶、処理または表示を行う）、あるいはその他の何らかの記憶、処理または表示デバイスに対して、その出力を供給することができる。

映像受信システム８００は、映像情報を含む映像コンテンツを受信し、処理することができる。映像受信システム８００は、例えば本願の実施態様で述べる信号などの符号化済み信号を受信することができる受信器８１０と、受信信号を復号することができるデコーダ８２０とを含む。

受信器８１０は、例えば、符号化済みピクチャを表す複数のビットストリームを有するプログラム信号を受信するようにすることができる。典型的な受信器は、例えば、変調済み且つ符号化済みのデータ信号を受信する、復調器８２２を用いて１つまたは複数の搬送波からデータ信号を復調する、信号中のエネルギーを逆ランダム化する、信号中のデータをインタリーブ解除する、信号の誤り訂正復号を行うといったうちの１つまたは複数などの機能を実行する。受信器８１０は、アンテナ（図示せず）を含むか、またはアンテナと接続することができる。受信器８１０の実施態様は、復調器を含むこともあれば、復調器に限定されることもある。

デコーダ８２０は、映像情報および奥行き情報を含む映像信号を出力する。デコーダ８２０は、例えば、上記で詳細に述べたデコーダ４００とすることができる。

システム７００への入力は、図７では、「入力信号（１つまたは複数）」と記してあり、システム８００からの出力は、図８では、「出力映像」として記してある。少なくともこれらの実施態様では、これらが複数のレイヤを含む３Ｄ映像を指していることは明らかであろう。

図９を参照すると、図９は、一実施態様による、本明細書に記載する特徴を適用することができる映像処理デバイス９００を示す図である。映像処理デバイス９００は、符号化済み映像を受信し、例えばユーザに対して表示するため、または記憶するための復号済み映像を供給する、セット・トップ・ボックスまたは他のデバイスとすることができる。従って、映像処理デバイス９００は、テレビジョン、コンピュータ・モニタ、あるいはコンピュータまたはその他の処理デバイスに、その出力を供給することができる。

映像処理デバイス９００は、フロントエンド（ＦＥ）デバイス９０５と、デコーダ９１０とを含む。フロントエンド・デバイス９０５は、例えば、符号化済みピクチャを表す複数のビットストリームを有するプログラム信号を受信し、該複数のビットストリームから復号するための１つまたは複数のビットストリームを選択するようになされた受信器とすることができる。通常の受信器は、変調済み且つ符号化済みのデータ信号を受信する、データ信号を復調する、データ信号の１つまたは複数の符号化（例えばチャネル符号化および／またはソース符号化）を復号する、および／またはデータ信号の誤り訂正を行うといったうちの１つまたは複数などの機能を実行する。フロントエンド・デバイス９０５は、例えばアンテナ（図示せず）からプログラム信号を受信することができる。フロントエンド・デバイス９０５は、受信したデータ信号をデコーダ９１０に供給する。

デコーダ９１０は、データ信号９２０を受信する。データ信号９２０は、例えば、１つまたは複数のＡｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）またはＳｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＳＶＣ）またはＭｕｌｔｉ−ｖｉｅｗ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＭＶＣ）と互換性のあるストリームを含むことができる。

ＡＶＣは、より詳細には、既存のＩｎｔｅｒｎａｔｉｏｎａｌ Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ／Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｅｌｅｃｔｒｏｔｅｃｈｎｉｃａｌ Ｃｏｍｍｉｓｓｉｏｎ（ＩＳＯ／ＩＥＣ） Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ−４（ＭＰＥＧ−４） Ｐａｒｔ １０ Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）規格／Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃｄａｔｉｏｎ Ｕｎｉｏｎ、Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｅｃｔｏｒ（ＩＴＵ−Ｔ） Ｈ．２６４勧告（以下、「Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣ規格」として、または「ＡＶＣ規格」や単なる「ＡＶＣ」などの変形形式として表記する）のことである。

ＭＶＣは、より詳細には、ＡＶＣ規格のマルチビュー映像符号化（「ＭＶＣ」）拡張（Ａｎｎｅｘ Ｈ）のことであり、「Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣ ＭＶＣ拡張」（「ＭＶＣ拡張」または単に「ＭＶＣ」）と呼ぶ。

ＳＶＣは、より詳細には、ＡＶＣ規格のスケーラブル映像符号化（「ＳＶＣ」）拡張（Ａｎｎｅｘ Ｇ）のことであり、「Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣ ＳＶＣ拡張」（「ＳＶＣ拡張」または単に「ＳＶＣ」）と呼ぶ。

デコーダ９１０は、受信信号９２０の全てまたは一部を復号し、復号済み映像信号９３０を出力として提供する。復号済み映像９３０は、セレクタ９５０に提供される。デバイス９００は、ユーザ入力９７０を受信するユーザ・インタフェース９６０も含む。ユーザ・インタフェース９６０は、ユーザ入力９７０に基づくピクチャ選択信号９８０を、セレクタ９５０に提供する。ピクチャ選択信号９８０およびユーザ入力９７０は、利用可能な復号済みデータの複数のピクチャ、シーケンス、スケーラブル・バージョン、ビューまたはその他の選択のうちのどれをユーザが表示したいと望んでいるかを示す。セレクタ９５０は、選択した１つまたは複数のピクチャを出力９９０として供給する。セレクタ９５０は、ピクチャ選択情報９８０を使用して、復号済み映像９３０中のどのピクチャを出力９９０として供給するかを選択する。

様々な実施態様では、セレクタ９５０は、ユーザ・インタフェース９６０を含むが、実施態様によっては、別個のインタフェース機能が実行されることなく、セレクタ９５０がユーザ入力９７０を直接受信するので、ユーザ・インタフェース９６０が不要である。セレクタ９５０は、例えば、ソフトウェアとして実施しても、集積回路として実施してもよい。一実施態様では、セレクタ９５０がデコーダ９１０に組み込まれるが、別の実施態様では、デコーダ９１０、セレクタ９５０およびユーザ・インタフェース９６０が、全て一体化される。

１つの応用分野では、フロントエンド９０５は、様々なテレビジョン・ショーの放送を受信して、そのうちの１つを選択して処理する。１つのショーの選択は、ユーザからの視聴したいチャネルの入力に基づいて行われる。図９には、フロントエンド・デバイス９０５へのユーザ入力が図示されていないが、フロントエンド・デバイス９０５は、ユーザ入力９７０を受信する。フロントエンド・デバイス９０５は、放送を受信し、放送スペクトルの関連部分を復調し、この復調済みのショーに外部符号化があればこれを復号することにより、所望のショーを処理する。フロントエンド・デバイス９０５は、復号済みのショーをデコーダ９１０に供給する。デコーダ９１０は、デバイス９６０および９５０を含む集積ユニットである。従って、デコーダ９１０は、当該ショー中で視聴することを望むビューを示すユーザから供給された指示であるユーザ入力を受信する。デコーダ９１０は、選択されたビュー、およびその他のビューに含まれる任意の所要の参照ピクチャを復号し、復号済みのビュー９９０をテレビジョン（図示せず）に表示するために提供する。

引き続き上記の応用分野で、ユーザは、表示されているビューを切り替えたいと望むことがあり、その場合には、新たな入力をデコーダ９１０に供給することができる。ユーザから「ビュー変更」を受信した後で、デコーダ９１０は、古いビューおよび新しいビューの両方と、古いビューと新しいビューの間にある任意のビューとを復号する。すなわち、デコーダ９１０は、古いビューを撮影したカメラと新しいビューを撮影したカメラの間に物理的に位置する複数のカメラから取得した任意のビューを復号する。フロントエンド・デバイス９０５は、古いビュー、新しいビュー、およびその間のビューを識別する情報も受信する。これらの情報は、例えば、ビューの位置に関する情報を有する制御装置（図９には図示せず）またはデコーダ９１０によって与えることができる。その他の実施態様では、制御装置が一体化されたフロントエンド・デバイスを使用することもできる。

デコーダ９１０は、これらの復号済みビューの全てを出力９９０として供給する。ポストプロセッサ（図９には図示せず）が、これらのビューを補間して、古いビューから新しいビューへ滑らかに遷移させ、この遷移をユーザに対して表示する。新しいビューに遷移した後で、ポストプロセッサは、（図示しない１つまたは複数の通信リンクを介して）デコーダ９１０およびフロントエンド・デバイス９０５に対して、新しいビューのみが必要であることを通知する。その後、デコーダ９１０は、出力９９０として新しいビューのみを供給する。

システム／装置９００は、一続きの画像シーケンスの複数のビューを受信し、１つのビューを表示するために提示し、様々なビュー間で滑らかに切り替えるために使用することができる。この滑らかさは、ビュー間を補間して別のビューに滑らかに移行させることを必要とすることがある。さらに、システム９００は、ユーザがオブジェクトまたはシーンを回転させる、またはその他の方法でオブジェクトまたはシーンの３次元表現を見ることができるようにすることができる。例えば、オブジェクトの回転は、ビューからビューに移行し、当該ビュー間を補間して当該ビュー間の滑らかな遷移を実現する、または単純に３次元表現を実現することに対応することがある。すなわち、ユーザは、補間済みのビューを、表示する「ビュー」として「選択」することができる。

映像伝送システム７００、映像受信システム８００および映像処理デバイス９００は全て、本願に述べる様々な実施態様とともに使用するように適応化することができることは、明らかであろう。例えば、システム７００、８００および９００は、上述の３ＤＶフォーマットの１つのデータ、およびそれに関連する信号通信情報とともに動作するように適応化することもできる。

［実施形態１：３ＤＶプレフィックスＮＡＬユニット］
この実施形態では、新たなＮＡＬユニット・タイプを紹介し、これを「３ＤＶプレフィックスＮＡＬユニット」と呼び、参照番号１６で示す。このユニットは、特定の３ＤＶビューまたは３ＤＶレイヤのＶｉｄｅｏ Ｃｏｄｉｎｇ Ｌａｙｅｒ（ＶＣＬ）ＮＡＬユニットまたはＭＶＣプレフィックスＮＡＬユニット（ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ、１４で示す）より前に置くことができる。ＶＣＬ ＮＡＬユニットおよびＭＶＣプレフィックス・ユニットについては、提案するＡＶＣ規格に関連がある、Ｇａｒｙ Ｓｕｌｌｉｖａｎ他による「Ｅｄｉｔｏｒｓ’ ｄｒａｆｔ ｒｅｖｉｓｉｏｎ ｔｏ ＩＴＵ−Ｔ Ｒｅｃ． Ｈ．２６４｜ＩＳＯ／ＩＥＣ １４４９６−１０ Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ」、ＪＶＴ−ＡＤ００７、２００９年１月２月号、Ｇｅｎｅｖａ ＣＨ（以下「ＡＶＣ」ドラフト）に詳細に述べられている。本明細書で使用されているが明示的な定義がなされていない多くの用語および略語の意味は、このＡＶＣドラフトに記載されており、当業者なら理解することができる。３ＤＶプレフィックスＮＡＬユニットを指すのに使用している「１６」は、任意に選んだものであり、ＡＶＣドラフトにおいて予約済みとされている任意のＮＡＬユニット・タイプになるように選ぶことができる。

以下に示す表２は、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ符号に関するＡＶＣドラフトの表７−１の修正版であり、３ＤＶプレフィックスＮＡＬユニット１６を定義するものである。ＡＶＣドラフトの表７−１は、以下に表３として再現しておく。なお、表２は、以下でさらに詳細に述べる実施形態３での修正も含むことに留意されたい。３ＤＶプレフィックスＮＡＬユニット１６は、ＭＶＣ互換デコーダが、３ＤＶ補足レイヤも含めて伝送された全ての３ＤＶレイヤを復号することを可能にし、また、符号化レベルでの３ＤＶビューおよびレイヤの同期も可能にする。表２の行２〜５（ＮＡＬユニット・タイプ１６〜２３）は、表３のシンタックス変更を反映している。

提案する３ＤＶプレフィックスＮＡＬユニットに関するさらに詳細な説明を、以下の表４に示す。

表４に示すように、３ＤＶプレフィックスＮＡＬユニットは、３ｄｖ＿ｖｉｅｗ＿ｉｄおよび３ｄｖ＿ｌａｙｅｒ＿ｉｄを含むことができる。３ｄｖ＿ｖｉｅｗ＿ｉｄは、３ＤＶビューに関連するフレームの３ＤＶビューＩＤ番号を指定する。さらに、３ｄｖ＿ｌａｙｅｒ＿ｉｄは、関連するフレームの３ＤＶレイヤＩＤ番号を指定する。ｒｅｓｅｒｖｅｄ＿ｂｉｔｓは、ＮＡＬユニットをバイト整列することができるようにする。なお、これらの各シンタックス要素に使用されるビットの数およびそれらの符号化方法は、単なる例に過ぎないことを理解されたい。また、ＮＡＬユニット１６のヘッダは、以下の表９の最初の３つの要素と同様に、標準的な第１のバイトを含むことができることに留意されたい。この実施形態では、ＮＡＬユニット１６は、ヘッダと拡張ヘッダとを含むことができ、ペイロードを含む必要はない。ＮＡＬユニット１６は、例えば、あらゆる３ＤＶレイヤ・フレームよりも先に、または３ＤＶレイヤ・フレームのあらゆるスライスより先に、伝送することができる。

３ＤＶプレフィックスＮＡＬユニットの利用方法をより分かりやすく示すために、図１０を参照する。図１０は、３ＤＶビュー１００２、１００４および１００６の構造１０００を含む３ＤＶコンテンツの一例を示す図である。ここで、ビュー１００２、１００４および１００６は、同じシーンまたはオブジェクトの異なるパースペクティブを与えるものである。この例では、各３ＤＶビューは、２Ｄビュー１０１０およびその奥行き１００８という、さらに２つのレイヤで構成される。図１０の矢印は、異なるビュー間および異なるレイヤ間の符号化の依存関係を示している。例えば、双方向予測ビューであるＢビュー１００４は、符号化のために、ベース・ビュー１００２と予測ビューであるＰビュー１００６とに依存し、これらを参照する。同様に、Ｐビュー１００６は、ベース・ビュー１００２に依存し、これを参照する。ここで、各３ＤＶビューの奥行きレイヤ１００８は、対応する３ＤＶビューの２Ｄビュー・レイヤ１０１０を参照する。なお、当業者なら、本明細書に与える教示に鑑みて、これらの３ＤＶビューおよび依存関係を、ＭＶＤ、ＬＤＶ、ＤＥＳフォーマットに準拠したものなど追加の３ＤＶ補足レイヤを有する３ＤＶコンテンツに拡張することができることに留意されたい。また、図１０に示す依存関係は単なる例に過ぎないこと、および３ＤＶプレフィックスＮＡＬユニットを使用することによってその他の様々な依存関係が可能になることにも留意されたい。

この実施形態による図１０に示す３ＤＶコンテンツのＮＡＬユニット・ストリームを、図１１に示す。具体的には、図１１では、異なる時点Ｔ０ １１０２およびＴ１ １１１０のＮＡＬユニット１１００のストリームが、映像提示のために供給される。ここで、ビュー１１０４およびビュー１１１２（３ＤＶビュー０）は、ベース・ビュー１００２と同じパースペクティブまたは視点と関連付けられているので、それぞれ時点Ｔ０およびＴ１におけるベース・ビュー１００２に対応する。同様に、ビュー１１０６およびビュー１１１４（３ＤＶビュー２）は、それぞれ時点Ｔ０およびＴ１におけるＰビュー１００６に対応し、ビュー１１０８およびビュー１１１６（３Ｄビュー１）は、それぞれ時点Ｔ０およびＴ１におけるＢビュー１００４に対応する。

図１１に示すように、各３ＤＶビューは、２Ｄビュー・レイヤおよび奥行きレイヤで構成される。ただし、他の実施形態では、追加の補足レイヤを利用することもできることを理解されたい。ここで、ビュー１１０４は、２Ｄビュー・レイヤ１１１８および奥行きレイヤ１１２０で構成される。２Ｄビュー・レイヤ１１１８自体は、ＮＡＬユニット１６（１１２６）、１４（１１２８）、および５（１１３０）で構成され、奥行きレイヤ１１２０は、ＮＡＬユニット１６およびＮＡＬユニット２０（１１３２）で構成される。ビュー１１０６の２Ｄビュー・レイヤ１１２２および奥行きレイヤ１１２４自体は、図１１に示すように、ＮＡＬユニット１６およびＮＡＬユニット２０で構成される。ビュー１１１２は、ＮＡＬユニット１６および２０を含む奥行きレイヤ、ならびにＮＡＬユニット１６、１４および１（１１３４）を含む２Ｄビュー・レイヤ１１３６の両方を含む。

図１１の矢印は、ＮＡＬユニットの伝送順序を示している。例えば、ＮＡＬユニット１６（１１２６）は、ＮＡＬユニット１４（１１２８）より前に伝送され、ＮＡＬユニット１４（１１２８）は、ＮＡＬユニット５（１１３０）より前に伝送される、などである。ＮＡＬユニット１６は、表２および表４に定義されているが、図１１に示すその他のＮＡＬユニットは、表３に定義されている。例えば、ＮＡＬユニット５は、ＡＶＣドラフトに定義されるように、イントラ・スライスまたはＳＩスライスのみで構成される瞬時復号更新（ＩＤＲ）ピクチャの符号化済みスライスの映像データを含む。一般に、ＩＤＲピクチャは、イントラ予測のみを用いて、またはイントラ予測および予測サンプルの量子化を用いて符号化される。さらに、ＮＡＬユニット１は、その他のピクチャ、３ＤＶレイヤまたは３ＤＶビューを参照することができる双方向（Ｂ）符号化済みピクチャまたは予測（Ｐ）符号化済みピクチャなどの非ＩＤＲピクチャの符号化済みスライスの映像データを含む。ＮＡＬユニット２０は、例えば図１０に示すように別のレイヤを参照する、または別の３ＤＶビューを参照することができる符号化済みスライス拡張である。また、図１１に示すＮＡＬユニット１、５および２０は、このような多くのユニットを表しており、示しやすいように省略されていることにも留意されたい。例えば、２Ｄビュー１１１８のプレフィックス・ユニット１６および１４を伝送した後で、対応するフレームの全てのスライスが送信されるまで、いくつかのＮＡＬユニット５（１１３０）を伝送することができる。同様に、奥行きビューのプレフィックスＮＡＬユニット１６を伝送した後で、奥行きレイヤ・フレームを構成する複数のＮＡＬユニット２０を伝送することができる。図１１に示すＮＡＬユニット１も、同様に、２Ｄビュー・レイヤ１１３６のフレームに対応するスライスの省略された表現である。

各ＮＡＬユニット１４は、上述のように、それが対応するレイヤのＭＶＣビューＩＤを示すプレフィックスＮＡＬユニットである。例えば、ＮＡＬユニット１４は、それが対応する２Ｄビュー・レイヤ１１１８のＭＶＣビューＩＤを含む。同様に、ＮＡＬユニット２０も、それが対応する３ＤＶレイヤのＭＶＣビューＩＤを含む。この実施形態では、あらゆる３ＤＶレイヤは、別個のＭＶＣビューとして符号化されるので、その符号化中に一意的なＭＶＣ ｖｉｅｗ＿ｉｄが割り当てられる。上述のエンコーダ３００などのエンコーダは、以下の実施形態５〜７でさらに述べるように、ＭＶＣ ｖｉｅｗ＿ｉｄを使用して、シーケンス・パラメータ・セット（ＳＰＳ）中の複数のレイヤ間および／またはフレーム間の依存関係を示すことができ、デコーダ４００などのデコーダが３ＤＶプレフィックスＮＡＬユニットを用いて正しくフレームを解釈して復号することができるように、プレフィックスＮＡＬユニット１６中の対応する３ｄｖ＿ｖｉｅｗ＿ｉｄおよび３ｄｖ＿ｌａｙｅｒ＿ｉｄを指定することができる。

例えば、各３ＤＶレイヤのＭＶＣ ｖｉｅｗ＿ｉｄを、表５のように設定することができる。従って、実施形態１のアーキテクチャでは、４に等しいＭＶＣ ｖｉｅｗ＿ｉｄを有する任意のＮＡＬユニットより、２として設定される３ｄｖ＿ｖｉｅｗ＿ｉｄおよび０として設定される３ｄｖ＿ｌａｙｅｒ＿ｉｄを有するプレフィックスＮＡＬユニット１６が先にならなければならない。ここで割り当てられた実際の値は、任意の値であり、異なるパースペクティブまたは視点にそれぞれ対応する異なる３ＤＶビューが一意的に識別され、それらが対応する３ＤＶレイヤが適切に識別され伝達される限り、変化させることができる。また、表５の値は、時間が異なっても一貫していることにも留意されたい。例えば、ビュー１１０４および１１１２は、同じＭＶＣビュー、３ＤＶビューおよび３ＤＶレイヤＩＤを共有する。

実施形態１で定義されるビットストリームは、ＭＶＣ互換性があり、全ての３ＤＶビューおよびその全てのレイヤを従来のＭＶＣデコーダで復号することができることを理解されたい。従って、３ＤＶプレフィックスＮＡＬユニット１６により、ＭＶＣ互換デコーダは、３ＤＶ補足レイヤも含めて伝送された全ての３ＤＶレイヤを復号することができる。しかし、従来のＭＶＣデコーダでは復号したデータがどのようにして３ＤＶフォーマットに構成されているかが分からないが、ＮＡＬユニット１６を使用することにより、実施形態による符号化レベルにおける３ＤＶビューおよびレイヤの同期が可能になる。例えば、図３に示すエンコーダ３００の３ＤＶ参照バッファ３１６は、上記に開示した教示によれば、ビットストリーム３１８中に適当な３ＤＶプレフィックス・ユニットを含むことができ、図４のデコーダ４００の３ＤＶ参照バッファ４１４は、ビットストリーム３１８中のＮＡＬユニットを解釈することができ、従って、それらのＮＡＬユニットを用いて、上記の図１０および図１１で説明した構造に一致するように３ＤＶコンテンツを構築してフォーマット化することができる。

３ＤＶビューのあらゆる２Ｄビュー・レイヤをＭＶＣに従って従来のＭＶＣデコーダによって復号し、フォーマット化することができるので、ＭＶＣ後方互換性が実現されることに留意されたい。ただし、奥行きレイヤおよびその他の３ＤＶ補足レイヤはそれら自体の一意的なＭＶＣビューＩＤを含むので、３ＤＶ補足レイヤは、別個のＭＶＣビューとしてＭＶＣデコーダによって解釈される。従って、３ＤＶ補足レイヤがＭＶＣに従ってフォーマット化され、表示された場合には、表示画像は、通常は３次元効果を有していない。従って、ユーザは、可視の３Ｄ画像が提示されるまで、ＭＶＣビューを探索して、その表示を試みることができる。ここで、２つの２Ｄビュー・レイヤが選択／表示されて、ユーザの各目に対して提示されれば、可視の３ＤＶビューが提示されることになる。

さらに、ユーザのディスプレイが例えば実施形態１を用いて伝送された３Ｄ補足レイヤを受け入れて３Ｄ画像を生成するように構成されていれば、ユーザが３Ｄ画像を見ることができることもある。例えば、ユーザのディスプレイが、ＬＤＶフォーマット入力を受け入れ、その入力から３Ｄ画像を生成できることがある。このような場合には、ユーザは、例えばユーザのディスプレイにおいて、入力がＬＤＶフォーマットであることを示すモードを選択することができる。

［実施形態２：３ＤＶにおけるＭＶＣ ｖｉｅｗ＿ｉｄの再利用］
実施形態２では、実施形態１の代替の実施態様として、ＮＡＬユニット・ヘッダにおける新規の符号化および復号プロセスが提案される。ここで、上記の実施形態１で述べた詳細は、３ＤＶプレフィックスＮＡＬユニット１６の使用を避けるようにＭＶＣ ｖｉｅｗ＿ｉｄを含む具体的なナンバリング方法を利用することを除けば、実施形態２にも当てはまる。例えば、ＭＶＣ ｖｉｅｗ＿ｉｄは１０ビットを有するように定義されるので、ＭＶＣ ｖｉｅｗ＿ｉｄの最下位の３ビットで３ｄｖ＿ｌａｙｅｒ＿ｉｄを示すことができ、ＭＶＣ ｖｉｅｗ＿ｉｄの最上位の７ビットで３ｄｖ＿ｖｉｅｗ＿ｉｄを示すことができる。その結果、表５のＭＶＣ ｖｉｅｗ＿ｉｄは、以下の表６に示すように設定することができる。従って、図１１に示す３ＤＶコンテンツは、実施形態２ではＮＡＬユニット１６が存在せず、デコーダが表６を記憶し、これを使用して、ビットストリーム中の抽出したＭＶＣビューＩＤを３ＤＶビューＩＤおよび３ＤＶレイヤＩＤに対して相互参照することにより、これらの抽出したＭＶＣビューＩＤから３ＤＶビューＩＤおよび３ＤＶレイヤＩＤを決定することを除けば、実施形態２でも同じである。従って、ＮＡＬプレフィックス・ユニット１４および／またはＮＡＬユニット２０は、ＭＶＣビューＩＤを含むナンバリング方法に従って構成することができる。ここで、上記のように、ＭＶＣビューＩＤを利用して、３ＤＶビューＩＤおよび３ＤＶレイヤＩＤを伝達して、符号化レベルでの３ＤＶコンテンツの同期およびフォーマット化を可能にすることができる。

［実施形態３：３ＤＶ ＮＡＬユニット拡張］
実施形態１および２では、特定のＭＶＣ符号化技術を使用して全ての３ＤＶレイヤを符号化したので、全ての３ＤＶレイヤを従来のＭＶＣデコーダで復号することができた。しかし、現在のＭＶＣ規格を実施する従来のＭＶＣデコーダは、上述したように、様々な３ＤＶレイヤのそれぞれを３ＤＶフォーマットに構成するわけではない。実施形態３では、現在のＭＶＣ規格に含まれない、特定の３ＤＶビューおよび／または特定の３ＤＶレイヤに適用することができる追加の符号化技術の導入を可能にする、符号化フレームワークを提案する。

この目的を達成するために、上記の表２に示すように、本明細書では「２１」と呼ぶ、新規のＮＡＬユニット・タイプを利用することができる。ＮＡＬユニット１６と同様に、この実施形態３の新規のＮＡＬユニットに対して選択した参照番号は、表３のＡＶＣドラフトで予約済みとされている任意の番号とすることができる。ここで、ＭＶＣデコーダによって復号する必要のない任意の３ＤＶビューおよび／または３ＤＶレイヤは、３ＤＶコンテンツを復号するためにＮＡＬユニット・タイプ２１を使用することができる。さらに、ＭＶＣデコーダによって復号し、適切に解釈することができる全ての２Ｄビュー・レイヤは、上記のように、１、５および２０など、従来のＮＡＬユニット・タイプで符号化することができる。これらを、ＭＶＣ互換２Ｄビューと呼ぶ。ＭＶＣ互換２３ビューより先に、実施形態１で述べたＮＡＬユニット１６などの３ＤＶプレフィックスＮＡＬユニットがあってもよい。あるいは、実施形態２で述べたように、３ＤＶプレフィックスＮＡＬユニットを避けるように、ＭＶＣ ｖｉｅｗ＿ｉｄのナンバリング方法を指定してもよい。

以下の表７に示すＡＶＣドラフトのＭＶＣ ＮＡＬユニット・ヘッダ拡張と同様に、新規の３ＤＶ ＮＡＬユニット・ヘッダ拡張を提案し、以下の表８に示す。

表７および表８に示すように、３ＤＶ ＮＡＬユニット・ヘッダ拡張は、ＭＶＣ ＮＡＬユニット・ヘッダ拡張のｖｉｅｗ＿ｉｄのシンタックス要素が、３ＤＶ ＮＡＬユニット・ヘッダ拡張では２つのシンタックス要素３ｄｖ＿ｖｉｅｗ＿ｉｄおよび３ｄｖ＿ｌａｙｅｒ＿ｉｄで置き換えられていることを除けば、ＭＶＣ ＮＡＬユニット・ヘッダ拡張と同じシンタックス要素を含むことができる。ここで、実施形態３では、３ｄｖ＿ｖｉｅｗ＿ｉｄは、関連するフレームの３ＤＶビューＩＤ番号を指定する。同じビュー位置からの複数の３ＤＶビュー・レイヤの間では、同じ３ｄｖ＿ｖｉｅｗ＿ｉｄが共有される。また、３ｄｖ＿ｌａｙｅｒ＿ｉｄは、関連するフレームの３ＤＶレイヤＩＤ番号を指定する。ｎａｌ＿ｕｎｉｔ＿ｈｅａｄｅｒ＿３ｄｖ＿ｅｘｔｅｎｓｉｏｎ（）の呼出しを、以下の表９に示す。

ここでは、Ｉｆ（ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ＝＝２１）｛．．．｝の記述が、ＡＶＣドラフトに記載されているＮＡＬユニット・シンタックスに追加されている。

実施形態３によるＮＡＬユニット・ストリーム１２００の一例を、この新たなＮＡＬユニット・タイプ２１を利用する図１２に示す。ここで、ｖｉｅｗ＿ｉｄのナンバリングがＮＡＬユニット・ヘッダ構文解析プロセスで指定されるので、３ＤＶプレフィックスＮＡＬユニット・タイプを使用することが回避される。ＮＡＬユニット・ストリーム１２００は、図１０に示す３ＤＶコンテンツの例に実施形態３を適用した例である。上述のように、３ＤＶビュー間および３ＤＶレイヤ間の依存関係、ならびに使用する３ＤＶレイヤは、実施態様に応じて様々に変更することができる。

ストリーム１１００と同様に、ストリーム１２００は、異なる時間に対して異なるセットのビューを含むことができ、ビュー１２０４、１２０６および１２０８は、Ｔ０（１２０２）に対応し、ビュー１２１２、１２１４および１２１６は、時点Ｔ１（１２１０）に対応する。ビュー１２０４およびビュー１２１２（３ＤＶビュー０）は、ベース・ビュー１００２と同じパースペクティブまたは視点に関連付けられているので、それぞれ時点Ｔ０およびＴ１におけるベース・ビュー１００２に対応する。同様に、ビュー１２０６およびビュー１２１４（３ＤＶビュー２）は、それぞれ時点Ｔ０およびＴ１におけるＰビュー１００６に対応し、ビュー１２０８およびビュー１２１６（３ＤＶビュー１）は、それぞれ時点Ｔ０およびＴ１におけるＢビュー１００４に対応する。各３ＤＶビューは、２Ｄビュー・レイヤおよび奥行きレイヤで構成される。ストリーム１１００の場合と同様に、その他の実施形態でも追加の補足レイヤを利用することができることを理解されたい。ビュー１２０４は、２Ｄビュー・レイヤ１２１８および奥行きレイヤ１２２０で構成される。２Ｄビュー・レイヤ１２１８は、ＮＡＬユニット１４（１２２６）およびＮＡＬユニット５（１２３０）で構成され、奥行きレイヤ１２２０は、ＮＡＬユニット２１（１２３０）で構成される。さらに、ビュー１２０６は、ＮＡＬユニット２０を含む２Ｄビュー１２２２、およびＮＡＬユニット２１で構成される奥行きビュー１２２４で構成される。さらに、ビュー１２１２の２Ｄビュー１２３６は、ＮＡＬユニット１４およびＮＡＬユニット１で構成される。

ＮＡＬユニット１、５、１４および２０については、図１１を参照して上記で述べた。ＮＡＬユニット１４および２０が、表７のＭＶＣ ＮＡＬユニット・ヘッダ拡張を使用するのに対して、ＮＡＬユニット２１は、表８の３ＤＶ ＮＡＬユニット・ヘッダ拡張を利用する。この新規の３ＤＶ ＮＡＬユニット・ヘッダ拡張を使用することにより、新たな符号化方法の適用を可能にしながら、符号化レベルで３ＤＶレイヤを３ＤＶコンテンツ・フォーマットに同期させることが可能になる。ＮＡＬユニット１６とは異なり、ＮＡＬユニット２１は、対応する映像データのペイロードを含むことができる。より一般的には、このペイロードは、ピクチャ・データを含むことができる。このピクチャ・データは、一般に、対応する符号化済みピクチャのデータを指す。ピクチャ・データは、例えば２Ｄ映像レイヤ、奥行きレイヤ、隠蔽映像レイヤ、隠蔽奥行きレイヤまたは透明度レイヤなど、任意のレイヤからのものとすることができる。

また、図１１と同様に、図１２の矢印も、ＮＡＬユニットの伝送順序を示していることに留意されたい。さらに、図１２に示すＮＡＬユニット１、５、２０および２１は、図１１に示すＮＡＬユニット１、５および２０の省略と同じ方法で省略が施される。さらに、実施形態３は、従来のデコーダで２Ｄビュー・レイヤを復号し、ＭＶＣに従って結合して、３Ｄコンテンツの生成および表示を可能にするので、ＭＶＣ互換性がある。

次に、図１３および図１４を参照すると、実施形態３による、３ＤＶコンテンツ・ストリームを復号する方法１３００および符号化する方法１４００が、それぞれ示してある。方法１３００は、図４のデコーダ４００が実行し、その内部で実施することができ、方法１４００は、図３のエンコーダ３００が実行し、その内部で実施することができることを理解されたい。方法１３００および１４００は両方とも、上述の表９に示すシンタックスを利用する。

方法１３００は、ステップ１３０２から開始することができ、ステップ１３０２では、デコーダ４００が、上記の表９およびＡＶＣドラフトに記載される、受信したＮＡＬユニットのｎａｌ＿ｒｅｆ＿ｉｄｃを読み取ることができる。

ステップ１３０４で、デコーダ４００は、ＮＡＬユニット・タイプを読み取ることができる。

ステップ１３０６で、デコーダ４００は、ＮＡＬユニット・タイプが１４であるかどうかを判定することができる。ＮＡＬユニット・タイプが１４である場合には、デコーダ４００は、ステップ１３０８に進み、現在処理しているＮＡＬユニットの残りの部分を構文解析して、ＭＶＣビューＩＤを取得することができる。実施形態３のこの特定の実施態様では、３ＤＶビューＩＤおよび３ＤＶレイヤＩＤは、実施形態２で上述したように、例えば、ＭＶＣビューＩＤで示される。

従って、ステップ１３１０で、デコーダ４００は、例えば実施形態２で上述したように、ＭＶＣビューＩＤから３ＤＶビューＩＤおよび３ＤＶレイヤＩＤを取得することができる。

ステップ１３１２で、デコーダ４００は、受信した次のＮＡＬユニットを読み取り、これを構文解析することができる。この次のＮＡＬユニットは、タイプ１またはタイプ１５の何れかでなければならない。従って、この次のＮＡＬユニットがタイプ１またはタイプ１５ではないとデコーダが判定した場合には、エラーが生じている。

ステップ１３１４で、デコーダ４００は、現在処理しているＮＡＬユニットの現在のスライス・データを復号することができる。

ステップ１３１６で、デコーダ４００は、この処理済みのＮＡＬユニットが現在のフレームの末尾に対応するかどうかを判定することができる。この処理済みのＮＡＬユニットが現在のフレームの末尾に対応しない場合には、デコーダ４００は、ステップ１３１２〜１３１６を繰り返すことができる。

現在のフレームの末尾に達した後で、この方法は、ステップ１３１８に進むことができ、このステップで、デコーダ４００は、復号済みのフレームを、その３ＤＶビューＩＤおよびその３ＤＶレイヤＩＤとともに、例えば３ＤＶ参照／出力バッファ４１４などのその出力バッファに送信することができ、このバッファは、このフレームを、上述のように、表示するための３ＤＶフォーマットに構成することができる。

ステップ１３２０で、デコーダ４００は、ビットストリームまたはシーケンスの末尾に達したかどうかを判定することができる。ビットストリームまたはシーケンスの末尾に達していない場合には、この方法は、ステップ１３０２に進むことができ、デコーダ４００は、方法１３００を繰り返すことができる。ビットストリームまたはシーケンスの末尾に達している場合には、方法１３００は終了することができる。

ステップ１３０６に戻って、デコーダ４００が、現在処理しているＮＡＬユニットのＮＡＬユニット・タイプがタイプ１４ではないと判定した場合には、この方法は、ステップ１３２２に進むことができ、このステップで、デコーダ４００は、現在処理しているＮＡＬユニットのＮＡＬユニット・タイプが２０であるかどうかを判定することができる。現在処理しているＮＡＬユニットがタイプ２０である場合には、この方法は、ステップ１３２４に進むことができ、このステップで、デコーダ４００は、現在処理しているＮＡＬユニットの残りの部分を構文解析して、ＭＶＣビューＩＤを取得することができる。実施形態３のこの特定の実施態様では、３ＤＶビューＩＤおよびその３ＤＶレイヤＩＤは、例えば実施形態２で上述したように、ＭＶＣビューＩＤで示される。

従って、ステップ１３２６で、デコーダ４００は、例えば実施形態２で上述したように、ＭＶＣビューＩＤから３ＤＶビューＩＤおよび３ＤＶレイヤＩＤを取得することができる。

ステップ１３２８で、デコーダ４００は、現在処理しているＮＡＬユニットの現在のスライス・データを復号することができる。

ステップ１３３０で、デコーダ４００は、処理済みのＮＡＬユニットが現在のフレームの末尾に対応するかどうかを判定することができる。処理済みのＮＡＬユニットが現在のフレームの末尾に対応しない場合には、この方法はステップ１３３２に進むことができ、このステップで、デコーダ４００は、受信した次のＮＡＬユニットを読み取り、これを構文解析することができる。次のＮＡＬユニットは、タイプ２０でなければならない。従って、次のＮＡＬユニットがタイプ２０ではないとデコーダが判定した場合には、エラーが生じている。その後、デコーダ４００が、ステップ１３２６〜１３３０を繰り返すことができる。

ステップ１３３０で、デコーダ４００が、現在のフレームの末尾に達していると判定した場合には、この方法は、ステップ１３１８に進むことができ、このステップで、デコーダ４００は、上述のように、復号済みのフレームを、その３ＤＶビューＩＤおよびその３ＤＶレイヤＩＤとともに、その出力バッファに送信することができる。その後、この方法は、ステップ１３２０に進むことができ、上述のように繰り返す、または終了することができる。

ステップ１３２２に戻って、デコーダ４００が、現在処理しているＮＡＬユニットがタイプ２０ではないと判定した場合には、この方法は、ステップ１３３４に進むことができ、このステップで、デコーダは、現在処理しているＮＡＬユニットがタイプ２１であるかどうかを判定する。現在処理しているＮＡＬユニットがタイプ２１である場合には、この方法は、ステップ１３３６に進むことができ、このステップで、デコーダ４００は、現在処理しているＮＡＬユニットの残りの部分を構文解析し、３ＤＶ ＮＡＬユニット・ヘッダ拡張によって与えられる３ＤＶビューＩＤおよび３ＤＶレイヤＩＤを取得することができる。

ステップ１３３８で、デコーダ４００は、現在処理しているＮＡＬユニットの現在のスライス・データを復号することができる。

ステップ１３４０で、デコーダ４００は、処理済みのＮＡＬユニットが現在のフレームの末尾に対応するかどうかを判定することができる。処理済みのＮＡＬユニットが現在のフレームの末尾に対応しない場合には、この方法は、ステップ１３４２に進むことができ、このステップで、デコーダ４００は、受信した次のＮＡＬユニットを読み取り、これを構文解析することができる。この次のＮＡＬユニットは、タイプ２１でなければならない。従って、この次のＮＡＬユニットがタイプ２１ではないとデコーダが判定した場合には、エラーが生じている。その後、デコーダ４００が、ステップ１３３８〜１３４０を繰り返すことができる。

ステップ１３４０で、現在のフレームの末尾に達しているとデコーダ４００が判定した場合には、この方法は、ステップ１３１８に進むことができ、このステップで、デコーダ４００は、上述のように、復号済みのフレームを、その３ＤＶビューＩＤおよびその３ＤＶレイヤＩＤとともに、その出力バッファに送信することができる。その後、この方法は、ステップ１３２０に進むことができ、上述のように繰り返す、または終了することができる。

ステップ１３３４に戻って、デコーダ４００がステップ１３３４で、現在処理しているＮＡＬユニットがタイプ２１ではないと判定した場合には、この方法は、ステップ１３４４に進むことができ、このステップで、現在処理しているＮＡＬユニットの残りの部分が構文解析される。この構文解析は、シーケンス・パラメータ・セット（ＳＰＳ）、ピクチャ・パラメータ・セット（ＰＰＳ）またはその他の目的を対象とすることができる。その後、この方法は、ステップ１３２０に進むことができ、上述のように繰り返す、または終了することができる。

再度図１４を参照すると、実施形態３によって３ＤＶコンテンツ・ストリームを符号化する方法１４００はステップ１４０２から開始することができ、ステップ１４０２ではエンコーダ３００がその構成プロフィルを読み取ることができる。

ステップ１４０４で、エンコーダ３００は、ＳＰＳおよび／またはＰＰＳ ＮＡＬユニットを書き込むことができる。

ステップ１４０６で、エンコーダ３００は、次に符号化するフレームを読み取ることができる。

ステップ１４０８で、エンコーダ３００は、現在処理しているフレームがＡＶＣ互換ビューとなるかどうかを判定することができる。現在処理しているフレームがＡＶＣ互換ビューとなる場合には、この方法は、ステップ１４１０に進むことができ、このステップで、エンコーダ３００は、現在のフレームの次のスライスを符号化することができる。

ステップ１４１２で、現在のフレームの現在処理しているスライスが現在のフレームの最初のスライスであるとエンコーダ３００が判定した場合には、エンコーダ３００は、例えばＮＡＬユニット・タイプ１４のＭＶＣプレフィックスＮＡＬユニットを書き込むことができる。

ステップ１４１４で、エンコーダ３００は、現在のスライスを、タイプ１または５のＮＡＬユニットなどのＮＡＬユニットにカプセル化することができる。

ステップ１４１６で、エンコーダ３００は、ステップ１４１４で現在のスライスがカプセル化されたＮＡＬユニットを書き込むことができる。

ステップ１４１８で、エンコーダ３００は、現在のフレームの末尾に達したかどうかを判定することができる。エンコーダが現在のフレームの末尾に達していない場合には、この方法は、ステップ１４１０に進むことができ、エンコーダ３００は、ステップ１４１０〜１４１８を繰り返すことができる。エンコーダが現在のフレームの末尾に達している場合には、この方法は、ステップ１４２０に進むことができ、このステップで、エンコーダ３００は、１つのシーケンスまたはビットストリームの全てのフレームが処理されたかどうかを判定することができる。全てのフレームが処理されている場合には、この方法は、終了することができる。そうでない場合には、この方法は、ステップ１４０６に進むことができ、エンコーダは、ステップ１４０６〜１４０８を繰り返すことができる。

上記で述べたステップ１４０８に戻って、エンコーダ３００が、現在処理しているフレームがＡＶＣ互換ビューである必要がないと判定した場合には、この方法は、ステップ１４２２に進むことができ、このステップで、エンコーダ３００は、現在処理しているフレームがＭＶＣ互換ビューとなるかどうかを判定することができる。現在処理しているフレームがＭＶＣ互換ビューとなる場合には、この方法は、ステップ１４２４に進むことができ、このステップで、エンコーダ３００は、現在処理しているフレームの次のスライスを符号化することができる。

ステップ１４２６で、エンコーダは、現在のスライスを、例えば２０などのＮＡＬユニット・タイプのＮＡＬユニットにカプセル化することができる。

ステップ１４２８で、エンコーダ３００は、ステップ１４２６で現在のスライスがカプセル化されたＮＡＬユニットを書き込むことができる。

ステップ１４３０で、エンコーダ３００は、現在のフレームの末尾に達したかどうかを判定することができる。エンコーダが現在のフレームの末尾に達していない場合には、この方法は、ステップ１４２４に進むことができ、エンコーダ３００は、ステップ１４２４〜１４３０を繰り返すことができる。エンコーダが現在のフレームの末尾に達している場合には、この方法は、ステップ１４２０に進むことができ、このステップで、エンコーダ３００は、１つのシーケンスまたはビットストリームの全てのフレームが処理されたかどうかを判定することができる。全てのフレームが処理されている場合には、この方法は、終了することができる。そうでない場合には、この方法は、ステップ１４０６に進むことができ、エンコーダは、ステップ１４０６〜１４０８を繰り返すことができる。

ステップ１４２２に戻って、エンコーダ３００が、現在処理しているフレームがＭＶＣ互換ビューである必要がないと判定した場合には、この方法は、ステップ１４３２に進むことができ、このステップで、エンコーダ３００は、現在のフレームの次のスライスを符号化することができる。

ステップ１４３４で、エンコーダは、現在のスライスを、例えば２１などのＮＡＬユニット・タイプのＮＡＬユニットにカプセル化することができる。

ステップ１４３６で、エンコーダ３００は、ステップ１４３４で現在のスライスがカプセル化されたＮＡＬユニットを書き込むことができる。

ステップ１４４０で、エンコーダ３００は、現在のフレームの末尾に達しているかどうかを判定することができる。エンコーダが現在のフレームの末尾に達していない場合には、この方法は、ステップ１４３２に進むことができ、エンコーダ３００は、ステップ１４３２〜１４４０を繰り返すことができる。エンコーダが現在のフレームの末尾に達している場合には、この方法は、ステップ１４２０に進むことができ、このステップで、エンコーダ３００は、１つのシーケンスまたはビットストリームの全てのフレームが処理されたかどうかを判定することができる。全てのフレームが処理されている場合には、この方法は、終了することができる。そうでない場合には、この方法は、ステップ１４０６に進むことができ、エンコーダは、ステップ１４０６〜１４０８を繰り返すことができる。

符号化ステップ１４１０、１４２４および１４３２、ならびに復号ステップ１３１４、１３２８および１３３８は、例えば図１０および図１２に関連して上述した実施形態の構造およびフィーチャへの準拠を可能にする様々な符号化方法および符号化規格に従って実行することができることを理解されたい。

さらに、３ＤＶレイヤの新たなＮＡＬユニット・タイプ２１を導入することで、異なる３ＤＶレイヤに対して、それぞれの異なる特性を利用した特別な符号化技術を規定することができる。例えば、２Ｄビューの復号は、参照ピクチャ中で予測ブロックを発見するのに奥行きマップを用いている場合には、その奥行きマップの復号に依存することができる。さらに、その他のこのような依存性も、上述のように利用することができる。

また、新規のＮＡＬユニット・タイプ２１を用いると、３ＤＶビュー／レイヤを、表１０に示すように、３ｄｖ＿ｓｌｉｃｅ＿ｌａｙｅｒ＿ｅｘｔｅｎｓｉｏｎ＿ｒｂｓｐ（）を用いて符号化することができることにも留意されたい。ここで、３ｄｖ＿ｓｌｉｃｅ＿ｈｅａｄｅｒ（）および３ｄｖ＿ｓｌｉｃｅ＿ｄａｔａ（）は、修正したｓｌｉｃｅ＿ｈｅａｄｅｒ（）およびｓｌｉｃｅ＿ｄａｔａ（）を含むことができる。

また、実施形態１〜３はそれぞれ別個に説明したが、本明細書に与える教示に鑑みて当業者には理解されるように、これらの実施形態のうちの１つまたは複数を様々な形態で組み合わせることもできることを理解されたい。例えば、同じフレームの様々なスライスを、様々な方法で符号化することができる。例えば、１つのフレームの特定のスライスを、実施形態１および／または２によるＭＶＣ互換性のある方法で符号化し、その他のスライスを、実施形態３による非ＭＶＣ符号化モードを用いて符号化することもできる。さらに、例えば２Ｄビューなど、３ＤＶビューの特定のレイヤを符号化するのに、実施形態１および／または２によるＭＶＣを利用し、例えば隠蔽・ビューなど、３ＤＶビューのその他のレイヤを符号化するのに、実施形態３による非ＭＶＣモードを適用することもできる。ここで、ＮＡＬユニット１６ならびにＮＡＬユニット１および／または５を、１つまたは複数の３ＤＶビューの一部のレイヤに適用し、ＮＡＬユニット２１を、１つまたは複数の３ＤＶビューのその他のレイヤに適用することもできる。

［実施形態４：参照ピクチャ・リストの構築］
上記に示したように、実施形態は、参照ピクチャ・リストの構築プロセスに関する場合もある。以下に述べる実施形態では、各ピクチャが、それ自体の参照ピクチャ・リストを有する。しかし、その他の実施態様では、複数のピクチャについて固有の（且つそれらのピクチャに対して使用される）参照ピクチャ・リストを提供することができる。例えば、１つの時間的なピクチャ・シーケンス全体に１つの参照ピクチャ・リストを割り当ててもよいし、所与の時点における複数のビューにまたがるピクチャ・セット全体に１つの参照ピクチャ・リストを割り当ててもよいし、あるいは１つのピクチャのサブセットに１つの参照ピクチャ・リストを割り当ててもよい。例えば、１つのピクチャのサブセットは、１つのスライス、あるいは１つのマクロブロックまたはサブマクロブロックで構成することができる。この参照ピクチャ・リスト構築プロセスの入力は、ＮＡＬユニット・ヘッダからのｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇ、およびシーケンス・パラメータ・セットから復号されたビュー依存関係情報である。図３のエンコーダ３００および図４のデコーダ４００はともに、以下に述べる教示を利用することにより、参照ピクチャ・リストを構築して、それぞれビットストリームを符号化／復号するように構成することができることを理解されたい。

このプロセスの第１のフェーズでは、例えばＡＶＣシステムまたはＭＶＣシステムで行うことがあるのと同様に、時間的参照ピクチャおよびビュー間参照ピクチャを、初期参照ピクチャ・リストＲｅｆＰｉｃＬｉｓｔＸ（Ｘは０または１）に挿入することができる。ＡＶＣドラフトで定義されるＲｅｆＰｉｃＬｉｓｔｘは、初期参照ピクチャ・リストの一例として用いることができる。例えば、Ｘが０であるＲｅｆＰｉｃＬｉｓｔ０を、任意のタイプの予測符号化ピクチャの符号化または復号に使用し、Ｘが１であるＲｅｆＰｉｃＬｉｓｔ１を、双方向符号化ピクチャすなわちＢピクチャの符号化または復号に使用することができる。従って、Ｂピクチャは、２つの参照ピクチャ・リストＲｅｆＰｉｃＬｉｓｔ０およびＲｅｆＰｉｃＬｉｓｔ１を有することができ、その他のタイプの予測符号化ピクチャは、１つのみの参照ピクチャ・リストＲｅｆＰｉｃＬｉｓｔ０を有することができる。さらに、ここでは、時間的参照は、参照リストが割り当てられた対応するピクチャと時間的に異なるピクチャを参照することに対応することにも留意されたい。例えば、図１１を参照すると、時間的参照は、ビュー１１１２の符号化／復号のためにビュー１１０４を参照することに対応することができる。ビュー間参照は、ビュー１１０６の符号化／復号のために、ビュー１１０４を参照することに対応することができる。参照ピクチャ・リストに時間的参照ピクチャおよびビュー間参照ピクチャを挿入することにより、（例えばＡＶＣおよび／またはＭＶＣの）既存の時間的およびビュー間予測技術に対応することができる。既知の通り、ＡＶＣシステムが、時間的参照ピクチャを参照ピクチャ・リストに含み、ＭＶＣシステムが、さらにビュー間参照ピクチャを参照ピクチャ・リストに含むことになる。

このプロセスの第２のフェーズは、各レイヤごとに独立して定義することができるレイヤ間参照ピクチャを追加することを含むことができる。実施形態４の１つのレイヤ間予測構造１５００を、図１５に示す。構造１５００中の矢印は、予測の方向を示している。例えば、ある特定のビューの２Ｄ映像（ビュー）レイヤ１５０２（そこから矢印が出る）は、当該ビューの奥行きレイヤ１５０４（そこに矢印が入る）の符号化の際の参照として使用される。従って、レイヤ間予測構造を使用して、どの１つまたは複数のピクチャを参照として使用することができるか、従って、どの１つまたは複数のピクチャが参照ピクチャ・リストに含まれていなければならないかを判定することができる。構造１５００では、２Ｄ映像レイヤは、隠蔽映像レイヤ１５０６および透明度レイヤ１５１０の両方の参照としても使用される。さらに、奥行きレイヤ１５０４は、隠蔽奥行きレイヤ１５０８の参照として使用される。

図１５に示すように、レイヤ間予測構造１５００では、各３ＤＶレイヤは、最大で１つしかレイヤ間参照を有していない。所与のレイヤを符号化するために、同様の特性を有するレイヤを、参照として使用する。例えば、再度図２を参照すると、隠蔽映像レイヤ２０６は、２Ｄ映像レイヤ２０２の背景を含み、隠蔽奥行きレイヤ２０８は、奥行きレイヤ２０４の背景を含む。従って、レイヤ間の冗長性をよりよく活用するために、いくつかの実施態様では、１つのビューの２Ｄ映像レイヤを、当該ビューの隠蔽・レイヤの参照として使用し、当該ビューの奥行きレイヤを、当該ビューの隠蔽奥行きレイヤの参照として使用することができる。その他の実施態様では、所与の３ＤＶレイヤについて複数のレイヤ間参照を認めることができる。

２Ｄ映像レイヤ・ピクチャの実施態様では、レイヤ間参照を用いる必要がないので、２Ｄ映像レイヤ・ピクチャでは、第２のフェーズでは何もする必要がない。その他の実施形態では、実際には、２Ｄ映像レイヤのレイヤ間参照に備えることもできる。例えば、所与のビューの隠蔽レイヤは、当該ビューの２Ｄ映像レイヤの参照として使用することができる。２Ｄ映像レイヤのレイヤ間参照を用いることを回避することの利点は、全ての２Ｄビュー・レイヤを従来のＭＶＣデコーダで復号することができることである。なお、その他の実施態様では、例えば同期仮想参照ピクチャなどの歪み（ｗａｒｐｅｄ）ピクチャを、参照リストに追加することもできることに留意されたい。参照リスト中の歪みピクチャ参照の位置に関しては、歪みピクチャ参照は、初期参照リストの先頭なら高い合成品質で挿入することができ、参照リストの末尾なら中程度の合成品質で挿入することができる。このように歪みピクチャを使用することにより、符号化効率を向上させることができる。

図１５を参照すると、奥行きレイヤ・ピクチャ１５０４については、２Ｄ映像レイヤ・ピクチャ１５０２（図１５では奥行きレイヤの参照として示す）を、第２のフェーズで、ＲｅｆＰｉｃＬｉｓｔＸの末尾に追加することができる。様々な実施態様では、２Ｄ映像ピクチャ参照は、参照リストの先頭ではなく、参照リストの末尾に追加される。これは、冗長性が（第１のフェーズの時間的参照およびビュー間参照のうちの任意の参照と比較して）最小になると予想され、参照として使用される可能性が最も低くなると予想されるからである。従って、ここでは、参照ピクチャ・リスト中の任意の時間的参照およびビュー間参照の後に、レイヤ間参照を設ける。

隠蔽映像レイヤ・ピクチャ１５０６については、２Ｄ映像レイヤ・ピクチャ１５０２を、第２のフェーズで、ＲｅｆＰｉｃＬｉｓｔＸの先頭に追加することができる。２Ｄ映像ピクチャは、参照ピクチャ・リストにおいて、いかなる時間的参照およびビュー間参照よりも前に、末尾や中間ではなく先頭に、追加する（先頭追加する）ことができる。これは、２Ｄ映像ピクチャが、利用可能な参照ピクチャとの冗長性が最大になり、参照として使用される可能性が最も高くなると予想されるからである。

隠蔽奥行きレイヤ・ピクチャ１５０８については、奥行きピクチャ１５０４を、第２のフェーズで、ＲｅｆＰｉｃＬｉｓｔＸの先頭に、この参照ピクチャ・リスト中のいかなる時間的参照およびビュー間参照よりも前に、追加することができる。これは、隠蔽奥行きレイヤと奥行きレイヤとの間で（第１のフェーズの時間的参照およびビュー間参照のうちの任意の参照と比較して）高いレベルの冗長性が予想されるからである。

透明度レイヤ・ピクチャ１５１０については、２Ｄ映像レイヤ・ピクチャ１５０２を、第２のフェーズで、ＲｅｆＰｉｃＬｉｓｔＸの末尾に、この参照ピクチャ・リスト中のいかなる時間的参照およびビュー間参照よりも後に、追加することができる。これは、透明度レイヤと２Ｄ映像レイヤとの間で（第１のフェーズの時間的参照およびビュー間参照のうちの任意の参照と比較して）低いレベルの冗長性が予想されるからである。

より一般的には、あるピクチャのレイヤ間参照は、当該参照がどの程度の頻度で使用されるかによって決まる位置で、当該ピクチャの参照ピクチャ・リストに挿入することができる。各参照に優先順位が割り付けられる実施態様では、優先順位は、参照がどの程度の頻度で使用されるかに基づいて割り付けることができる。例えば、１つの実施態様では、ピクチャをマクロブロック単位で符号化し、各マクロブロックは、参照ピクチャ・リストの所与の参照を使用することもあれば、使用しないこともある。この実施態様の各マクロブロックごとに、様々な符号化モードや様々な参照も含む様々な符号化オプションの間で、レート／歪み最適化を実行する。従って、ピクチャのマクロブロックのサブセットの符号化において、所与のレイヤ間参照のみが使用されることもある。所与のレイヤ間参照に割り付けられる優先順位は、何個のマクロブロックが参照ピクチャ・リスト中の利用可能なその他の参照を使用するかと比較して、何個のマクロブロックが当該レイヤ間参照を使用するかに基づいて決定することができる。

次に、図１６および図１７を参照すると、符号化プロセスのための参照ピクチャ・リストを構築する方法１６００、および復号プロセスのための参照ピクチャ・リストを構築する方法１７００が、それぞれ示してある。実施形態４の一実施態様による符号化プロセスのための参照ピクチャ・リストを構築する方法１６００は、図３のエンコーダ３００によって実行することができる。例えば、３ＤＶ参照バッファ３１６は、方法１６００を実施するように構成することができる。

方法１６００は、ステップ１６０２から開始することができ、このステップで、エンコーダ３００は、参照ピクチャ・リストＲｅｆＰｉｃＬｉｓｔＸを初期化することができる。上述のように、ＲｅｆＰｉｃＬｉｓｔＸは、Ｘが０であっても１であっても、ＡＶＣドラフトに従って初期化することができる。例えば、上記に示したように、時間的参照ピクチャおよび／またはビュー間参照ピクチャを、初期参照ピクチャ・リストに挿入することができる。

ステップ１６０４で、エンコーダ３００は、参照ピクチャ・リストが２Ｄ映像レイヤ・ピクチャ用のものであるかどうかを判定することができる。参照ピクチャ・リストが２Ｄ映像レイヤ・ピクチャ用のものである場合には、この方法は、ステップ１６２２に進むことができ、このステップで、エンコーダ３００は、現在処理しているスライスの符号化を継続することができる。その後、この方法は、終了する、または反復して別の３ＤＶレイヤ・ピクチャ用の参照ピクチャ・リストを構築することができる。あるいは、３ＤＶレイヤ・ピクチャがＢピクチャである場合には、この方法は、同じ３ＤＶレイヤ・ピクチャについて反復して、ＲｅｆＰｉｃＬｉｓｔ１を構築することができる。

ステップ１６０４で、エンコーダ３００が、参照ピクチャ・リストが２Ｄ映像レイヤ・ピクチャ用のものではないと判定した場合には、この方法は、ステップ１６０６に進むことができ、このステップで、エンコーダ３００は、参照ピクチャ・リストが奥行きレイヤ・ピクチャ用のものであるかどうかを判定することができる。参照ピクチャ・リストが奥行きレイヤ・ピクチャ用のものである場合には、この方法は、ステップ１６０８に進むことができ、このステップで、奥行きレイヤ・ピクチャと同じ３Ｄビューからの２Ｄ映像レイヤ・ピクチャを、参照ピクチャ・リストの末尾に追加する。その後、この方法は、ステップ１６２２に進むことができ、このステップで、エンコーダ３００は、現在処理しているスライスの符号化を継続することができる。その後、この方法は、終了する、または反復して別の３ＤＶレイヤ・ピクチャ用の参照ピクチャ・リストを構築することができる。あるいは、３ＤＶレイヤ・ピクチャがＢピクチャである場合には、この方法は、同じ３ＤＶレイヤ・ピクチャについて反復して、ＲｅｆＰｉｃＬｉｓｔ１を構築することができる。

ステップ１６０６で、エンコーダ３００が、参照ピクチャ・リストが奥行きレイヤ・ピクチャ用のものではないと判定した場合には、この方法は、ステップ１６１０に進むことができ、このステップで、エンコーダ３００は、参照ピクチャ・リストが隠蔽映像レイヤ・ピクチャ用のものであるかどうかを判定することができる。参照ピクチャ・リストが隠蔽映像レイヤ・ピクチャ用のものである場合には、この方法は、ステップ１６１２に進むことができ、このステップで、隠蔽映像レイヤ・ピクチャと同じ３Ｄビューからの２Ｄ映像レイヤ・ピクチャを、参照ピクチャ・リストの先頭に追加する。その後、この方法は、ステップ１６２２に進むことができ、このステップで、エンコーダ３００は、現在処理しているスライスの符号化を継続することができる。その後、この方法は、終了する、または反復して別の３ＤＶレイヤ・ピクチャ用の参照ピクチャ・リストを構築することができる。あるいは、３ＤＶレイヤ・ピクチャがＢピクチャである場合には、この方法は、同じ３ＤＶレイヤ・ピクチャについて反復して、ＲｅｆＰｉｃＬｉｓｔ１を構築することができる。

ステップ１６１０で、エンコーダ３００が、参照ピクチャ・リストが隠蔽映像レイヤ・ピクチャ用のものではないと判定した場合には、この方法は、ステップ１６１４に進むことができ、このステップで、エンコーダ３００は、参照ピクチャ・リストが隠蔽奥行きレイヤ・ピクチャ用のものであるかどうかを判定することができる。参照ピクチャ・リストが隠蔽奥行きレイヤ・ピクチャ用のものである場合には、この方法は、ステップ１６１６に進むことができ、このステップで、隠蔽奥行きレイヤ・ピクチャと同じ３Ｄビューからの奥行きレイヤ・ピクチャを、参照ピクチャ・リストの先頭に追加する。その後、この方法は、ステップ１６２２に進むことができ、このステップで、エンコーダ３００は、現在処理しているスライスの符号化を継続することができる。その後、この方法は、終了する、または反復して別の３ＤＶレイヤ・ピクチャ用の参照ピクチャ・リストを構築することができる。あるいは、３ＤＶレイヤ・ピクチャがＢピクチャである場合には、この方法は、同じ３ＤＶレイヤ・ピクチャについて反復して、ＲｅｆＰｉｃＬｉｓｔ１を構築することができる。

ステップ１６１４で、エンコーダ３００が、参照ピクチャ・リストが隠蔽奥行きレイヤ・ピクチャ用のものではないと判定した場合には、この方法は、ステップ１６１８に進むことができ、このステップで、エンコーダ３００は、参照ピクチャ・リストが透明度レイヤ・ピクチャ用のものであるかどうかを判定することができる。参照ピクチャ・リストが透明度レイヤ・ピクチャ用のものである場合には、この方法は、ステップ１６２０に進むことができ、このステップで、透明度レイヤ・ピクチャと同じ３Ｄビューからの２Ｄ映像レイヤ・ピクチャを、参照ピクチャ・リストの末尾に追加する。その後、この方法は、ステップ１６２２に進むことができ、このステップで、エンコーダ３００は、現在処理しているスライスの符号化を継続することができる。その後、この方法は、終了する、または反復して別の３ＤＶレイヤ・ピクチャ用の参照ピクチャ・リストを構築することができる。あるいは、３ＤＶレイヤ・ピクチャがＢピクチャである場合には、この方法は、同じ３ＤＶレイヤ・ピクチャについて反復して、ＲｅｆＰｉｃＬｉｓｔ１を構築することができる。同様に、ステップ１６１８で、エンコーダ３００が、レイヤが透明度レイヤ・ピクチャではないと判定した場合には、この方法は、ステップ１６２２に進むことができ、このステップで、エンコーダ３００は、現在処理しているスライスの符号化を継続することができる。その後、この方法は、終了する、または反復して別の３ＤＶレイヤ・ピクチャ用の参照ピクチャ・リストを構築することができる。あるいは、３ＤＶレイヤ・ピクチャがＢピクチャである場合には、この方法は、同じ３ＤＶレイヤ・ピクチャについて反復して、ＲｅｆＰｉｃＬｉｓｔ１を構築することができる。

次に、図１７に示す方法１７００を参照すると、実施形態４の一実施態様による復号プロセスのための参照ピクチャ・リストを構築する方法１７００は、図４のデコーダ４００によって実行することができる。例えば、３ＤＶ参照／出力バッファ４１４は、方法１７００を実行するように構成することができる。

方法１７００は、デコーダ４００が受信したＮＡＬユニットおよびスライス・ヘッダを構文解析して３ＤＶレイヤ・ヘッダを抽出することができるステップ１７０２から開始することができる。例えば、ＮＡＬユニットは、上記の実施形態１で述べた３ＤＶプレフィックス・ユニット１６、実施形態２のＮＡＬプレフィックス・ユニット１４および／またはＮＡＬユニット２０、ならびに／あるいは実施形態３のＮＡＬユニット２１とすることができる。さらに、上述のように、デコーダ４００が受信した３ＤＶコンテンツを含むビットストリームからデコーダ４００が抽出することができるその他の情報としては、ＮＡＬユニット・ヘッダのｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇおよびシーケンス・パラメータ・セットから復号したビュー依存関係情報などが挙げられる。その後、参照ピクチャ・リストＲｅｆＰｉｃＬｉｓｔＸを初期化することができる。上述のように、ＲｅｆＰｉｃＬｉｓｔＸは、Ｘが０であっても１であっても、ＡＶＣドラフトに従って初期化することができる。例えば、上記に示したように、ＮＡＬユニット・ヘッダのｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇおよびシーケンス・パラメータ・セットから復号したビュー依存関係情報を利用して、ＲｅｆＰｉｃＬｉｓｔＸを初期化することができる。時間的参照ピクチャおよび／またはビュー間参照ピクチャは、初期参照ピクチャ・リストに挿入することができる。

方法１７００の残りのステップは、ステップ１６２２をステップ１７２２で置き換えることを除けば、方法１６００に関連して上述したのと同様に、デコーダ４００によって実行することができる。例えば、ステップ１７０４〜１７２０は、エンコーダ３００がステップ１６０４〜１６２０を実行したのと同様に、デコーダ４００によって実行することができる。しかし、ステップ１７２２では、現在処理しているスライスを符号化するのではなく、デコーダは、現在処理しているスライスの復号を継続する。

図１５を参照して上述した以外のレイヤ間依存関係を有するレイヤ間予測構造も、当業者なら、実施形態４に関連して上記に与えた教示を用いて容易に考えつくことができることを理解されたい。

従って、実施形態４は、様々なタイプのレイヤ間予測に対応することができる。さらに、実施形態４は、例えば１５を参照して上述した構造などのレイヤ間予測構造に参照ピクチャ・リストを適合させる。その結果、実施形態４は、システムのレイヤ間予測構造に基づく参照ピクチャ・リストを提供すると同時に、従来のＭＶＣデコーダが３ＤＶコンテンツを抽出し、当該コンテンツを表示用にフォーマット化することができるようにする。

なお、参照ピクチャは、ＡＶＣシステムとの互換性を有するように構成することができることに留意されたい。例えば、レイヤ間参照ピクチャおよびビュー間参照ピクチャを、時間的に異なるピクチャとして多重化することができる。

［実施形態５：サブセットＳＰＳ ３ＤＶの新規のＮＡＬユニット・タイプ］
上記に示したように、少なくとも１つの実施形態では、３ＤＶフォーマットの新たなシーケンス・パラメータを信号通信することができるようにＳＰＳを拡張することができる。この３ＤＶ用の拡張ＳＰＳを、以下では「サブセットＳＰＳ ３ＤＶ」と呼ぶ。実施形態５では、このサブセットＳＰＳ ３ＤＶ用の新規のＮＡＬユニット・タイプを利用することができる。以下に述べる実施形態６および７では、サブセットＳＰＳ ３ＤＶを構成することができる方法について述べる。提案するパラメータは、ＳＰＳ内に限定されるわけではなく、ＮＡＬユニット・ヘッダ、ピクチャ・パラメータ・セット（ＰＰＳ）、補足エンハンスメント情報（ＳＥＩ）、スライス・ヘッダ、およびその他の任意の高レベル・シンタックス要素にも見ることができることを理解されたい。いくつかの実施形態では、低レベル・シンタックスおよび帯域外情報を使用することもできる。

ここで、実施形態５では、新規のＮＡＬユニット・タイプを使用して、サブセットＳＰＳ ３ＤＶを示すことができる。この実施形態におけるＮＡＬユニット・タイプの番号は、上述のようにＡＶＣドラフトから転記した上記の表３で割り当てられていない値の任意の１つとすることができる。さらに、３ＤＶレイヤのＶＣＬ ＮＡＬユニットに割り当てられた新規のＮＡＬユニット・タイプ番号も、実施形態１および３に関連して上述した新規のＮＡＬユニット・タイプとは異なる方法で選択しなければならない。その結果、サブセットＳＰＳ ３ＤＶ用のＮＡＬユニット・タイプ番号として、１７が選択され、これは、以下の表１１ではｓｕｂｓｅｔ＿ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿３ｄｖ＿ｒｂｓｐ（）として表される。もちろん、その他のＮＡＬユニット・タイプ番号を選択してもよい。実施形態を組み合わせない場合には、１７の代わりに、ＮＡＬユニット・タイプ１６または２１を使用することもできる。ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ１７の行およびｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ１８…２０の行は、上記の表２に新たに追加したものである。

新規のＮＡＬユニット・タイプにより、ＭＶＣデコーダまたは３ＤＶデコーダが、サブセットＳＰＳ ３ＤＶ内のコンテンツを廃棄するか構文解析するかを判定できるようにすることができる。タイプ１７はＭＶＣでは予約済みであるので、ＭＶＣデコーダは、このＮＡＬユニットのデータを無視または廃棄することを選択することができる。しかし、３ＤＶデコーダは、このユニットのデータを構文解析することができ、これにより、３ＤＶデコーダは、３ＤＶ補足レイヤを復号することが可能になる。

例えばルータなど、新規のＮＡＬユニット・タイプを認識することができるスマート・ネットワーク・デバイスの場合、特定の状況下では３ＤＶ補足レイヤを伝送してはならないとネットワーク・プロバイダが決定している場合には、サブセットＳＰＳ ３ＤＶを廃棄することを選択することもできる。あるいは、またはこれに加えて、サブセットＳＰＳ ３ＤＶのコンテンツを構文解析し、これを利用して、ストリーミングを利用可能なネットワーク帯域幅に適合させることもできる。例えば、３ＤＶレイヤ予測構造に関する知識があれば、ネットワーク・デバイス（例えばストリーミング・サーバまたはルータ）は、ネットワークにバースト・トラフィックが発生しているときに、参照として使用されていない３ＤＶレイヤを廃棄することができる。

ストリーム・サーバとも呼ばれるビットストリーム抽出器を使用して、３ＤＶストリームの様々な部分を抽出することもできる。上記のルータは、ビットストリームを構文解析し、様々な３ＤＶレイヤを転送（伝送）するか否かについて判定を下した。ビットストリーム抽出器も、ビットストリームを構文解析し、優先順位に基づいて転送に関する判定を下すことができるが、抽出したビットストリーム（サブ・ビットストリームとも呼ぶ）を、下流側のデバイスに合わせて調整することもできる。例えば、ビットストリーム抽出器は、下流側の受信器が隠蔽レイヤまたは透明度レイヤを使用していないという理由で、２Ｄ映像レイヤおよび奥行きレイヤのみを抽出することもできる。さらに、ビットストリーム抽出器は、下流側の受信器が２つを超えるビューを使用していないという理由で、ビットストリーム中の最初の２つのビューに対応するレイヤのみを抽出することもできる。ただし、これに加えて、ビットストリーム抽出器は、３ＤＶ ＳＰＳならびに任意のＭＶＣ ＳＰＳまたはその他の依存関係情報を分析して、２Ｄ映像レイヤまたは奥行きレイヤが隠蔽レイヤまたは透明度レイヤの何れかをレイヤ間参照として使用しているかどうかを判定し、且つ最初の２つのビューがその他のビューの何れかをビュー間参照として使用しているかどうかを判定することができる場合もある。所望の３ＤＶレイヤ、すなわち最初の２つのビューの２Ｄ映像レイヤおよび奥行きレイヤを適切に復号するためにその他のレイヤまたはビューが必要な場合には、ビットストリーム抽出器は、それらのレイヤおよび／またはビューも抽出することになる。

なお、３ＤＶレイヤおよび３ＤＶビューの優先順位情報は、ルータまたはビットストリーム抽出器が決定することができることに留意されたい。ただし、このような優先順位情報は、例えばＮＡＬユニット・ヘッダ中に配置することによって、ビットストリーム中に与えることもできる。このような優先順位情報としては、例えば、時間的レベルＩＤ、優先順位ＩＤ、ビューＩＤ、および３ＤＶ情報に関連する優先順位ＩＤなどが挙げられる。

次に、図１８および図１９を参照すると、実施形態５の実施態様によってサブセットＳＰＳ ３ＤＶ情報のＮＡＬユニットを符号化する方法１８００、およびそれを復号する方法１９００が、それぞれ示してある。方法１８００は、例えば、エンコーダ３００の３ＤＶ参照バッファ３１６によって実行することができ、方法１９００は、例えば、デコーダ４００の３ＤＶ参照バッファ４１４によって実行することができる。

方法１８００は、例えば、エンコーダ３００がＮＡＬユニットのＮＡＬユニット・タイプを１７に設定することができるステップ１８０２から開始することができる。ステップ１８０４で、エンコーダ３００は、ＮＡＬユニット・ヘッダを書き込むことができる。その後、ステップ１８０６で、エンコーダ３００は、ＳＰＳを構成し、書き込むことができる。例えば、ＳＰＳは、ｓｕｂｓｅｔ＿ｓｅｑｕｅｎｃｅ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿３ｄｖ＿ｒｂｓｐ（）に対応することができ、実施形態６および７で以下に述べるように構成して書き込むことができる。

方法１９００は、例えば、デコーダ４００がＮＡＬユニットを受信して、ＮＡＬユニット・ヘッダを読み取ることができるステップ１９０２から開始することができる。ＮＡＬユニットは、方法１８００で符号化されたＮＡＬユニットに対応することができる。ステップ１９０４で、デコーダ４００は、ＮＡＬユニット・タイプを抽出することができる。ＮＡＬユニット・タイプが１７に設定されている場合には、デコーダは、ＳＰＳを読み取って構文解析することができる。ＳＰＳは、例えば、ｓｕｂｓｅｔ＿ｓｅｑｕｅｎｃｅ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿３ｄｖ＿ｒｂｓｐ（）に対応することができ、実施形態６および７で以下に述べるように読み取って構文解析することができる。

［実施形態６：ＳＰＳの３ＤＶ適用分野用の信号パラメータへの拡張］
実施形態１〜４で上述したように、３ＤＶ補足レイヤを利用して、エンハンスト３Ｄレンダリング機能に対応することができるので、３ＤＶレイヤ識別番号（３ｄｖ＿ｌａｙｅｒ＿ｉｄ）をＳＰＳで信号通信することができる。さらに、上述のように、レイヤ間の冗長性を除去するために、レイヤ間符号化を利用することができ、レイヤ間ピクチャを参照ピクチャ・リストに追加して、レイヤ間符号化を容易にすることができる。従って、デコーダがレイヤ間参照を用いてピクチャを復号する方法を決定できるようにするために、エンコーダは、ＳＰＳ中のレイヤ間予測構造を指定することができる。このようなレイヤ間予測構造は、例えば、図１５を参照して上述した構造１５００に対応することができる。

ＳＰＳの構築について詳細に述べる前に、様々な実施態様によれば、３ＤＶコンテンツに対応するビットストリームについては新規のプロフィルを利用することができることに留意されたい。以下では「更新版ＡＶＣドラフト」と呼ぶ、ＩＴＵ−Ｔ、「Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ ｆｏｒ Ｇｅｎｅｒｉｃ ａｕｄｉｏｖｉｓｉａｌ Ｓｅｒｖｉｃｅｓ − Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ ＩＴＵ−Ｔ Ｈ．２６４」、２００９年３月では、複数のプロフィルについて述べられている。１つまたは複数の実施態様では、ｐｒｏｆｉｌｅ＿ｉｄｃを２１８に設定することができる。更新版ＡＶＣドラフトでは、ＡＶＣ／ＭＶＣのその他の既存のプロフィルについても述べられている。

以下に示す表１２は、実施形態５に関連して上述した関数ｓｕｂｓｅｔ＿ｓｅｑｕｅｎｃｅ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿３ｄｖ＿ｒｂｓｐ（）について行われるプロセスを詳細に示すものである。特に、表１２は、ｅｌｓｅ ｉｆ（ｐｒｏｆｉｌｅ＿ｉｄｃ＝＝２１８）｛．．．｝の記述において、実施形態６によるサブセットＳＰＳ ３ＤＶの１つの高レベルな実施態様を示している。詳細な信号通信は、例えば以下の表１３に示すように、ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿３ｄｖ＿ｅｘｔｅｎｓｉｏｎ（）の関数において実施することができる。２１８であるｐｒｏｆｉｌｅ＿ｉｄｃは、ＭＶＣ規格の新たなプロフィルを表し、３ＤＶプロフィルである。

図２０および図２１は、それぞれ、実施形態６の様々な実施態様によるＳＰＳを符号化する方法２０００および復号する方法２１００を示すハイレベル流れ図である。方法２０００および２１００は、例えば表１２に与える形態のＳＰＳを符号化／復号する方法である。表１２は、例えば、ＮＡＬユニット・タイプ１７として使用することができる。なお、図３のエンコーダ３００は、方法２０００を実行するように構成することができ、図４のデコーダ４００は、方法２１００を実行するように構成することができることに留意されたい。

方法２０００は、エンコーダ３００がｐｒｏｆｉｌｅ＿ｉｄｃを設定することができるステップ２００２から開始することができる。上記で示したように、ｐｒｏｆｉｌｅ＿ｉｄｃは、例えば、サブセットＳＰＳ ３ＤＶでは２１８に設定することができる。

ステップ２００４で、エンコーダ３００は、シーケンス・パラメータ・セット・データを書き込むことができる。例えば、このデータは、ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｄａｔａ（）シンタックス構造に関連して更新版ＡＶＣドラフトに記載されている任意のＳＰＳデータに対応することができる。

ステップ２００６で、エンコーダ３００は、ｐｒｏｆｉｌｅ＿ｉｄｃが８３または８６に設定されているかどうかを判定することができる。ｐｒｏｆｉｌｅ＿ｉｄｃが８３または８６に設定されている場合には、この方法は、ステップ２００８に進むことができ、このステップで、エンコーダ３００は、更新版ＡＶＣドラフトに記載されているように、ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｓｖｃ＿ｅｘｔｅｎｓｉｏｎ（）を書き込み、ｓｖｃ＿ｖｕｉ＿ｐａｒａｍｅｔｅｒｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを設定して書き込むことができる。さらに、ステップ２００８では、ｓｖｃ＿ｖｕｉ＿ｐａｒａｍｅｔｅｒｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが１に設定されている場合には、エンコーダ３００は、更新版ＡＶＣドラフトに記載されているように、ｓｖｃ＿ｖｕｉ＿ｐａｒａｍｅｔｅｒ＿ｅｘｔｅｎｓｉｏｎ（）を書き込むことができる。その後、この方法は、以下でさらに詳細に述べるステップ２０１０に進むことができる。

ステップ２００６に戻って、ｐｒｏｆｉｌｅ＿ｉｄｃが８３または８６に設定されていない場合には、この方法は、ステップ２０１４に進むことができ、このステップで、エンコーダ３００は、ｐｒｏｆｉｌｅ＿ｉｄｃが１１８に設定されているかどうかを判定することができる。ｐｒｏｆｉｌｅ＿ｉｄｃが１１８に設定されている場合には、この方法は、ステップ２０１６に進むことができ、このステップで、エンコーダ３００は、更新版ＡＶＣドラフトに記載されているように、ｂｉｔ＿ｅｑｕａｌ＿ｔｏ＿ｏｎｅを１に等しくなるように設定し、ｂｉｔ＿ｅｑｕａｌ＿ｔｏ＿ｏｎｅを書き込み、ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｍｖｃ＿ｅｘｔｅｎｓｉｏｎ（）を書き込み、ｍｖｃ＿ｖｕｉ＿ｐａｒａｍｅｔｅｒｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを設定して書き込むことができる。ｍｖｃ＿ｖｕｉ＿ｐａｒａｍｅｔｅｒｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが１に等しい場合には、エンコーダ３００は、更新版ＡＶＣドラフトに記載されているように、ｍｖｃ＿ｖｕｉ＿ｐａｒａｍｅｔｅｒｓ＿ｅｘｔｅｎｓｉｏｎ（）を書き込むことができる。その後、この方法は、以下でさらに詳細に述べるステップ２０１０に進むことができる。

ステップ２０１４で、エンコーダ３００が、ｐｒｏｆｉｌｅ＿ｉｄｃが１１８に設定されていないと判定した場合には、この方法は、ステップ２０１８に進むことができ、このステップで、エンコーダ３００は、ｐｒｏｆｉｌｅ＿ｉｄｃが２１８に設定されているかどうかを判定することができる。ｐｒｏｆｉｌｅ＿ｉｄｃが２１８に設定されていない場合には、この方法は、ステップ２０２２に進むことができ、このステップで、エンコーダ３００は、ｐｒｏｆｉｌｅ＿ｉｄｃが未知であると判定することができ、エラー・メッセージを出力することができる。

しかし、ｐｒｏｆｉｌｅ＿ｉｄｃが２１８に設定されている場合には、エンコーダ３００は、ステップ２０２０を実行することができ、このステップで、エンコーダ３００は、ｂｉｔ＿ｅｑｕａｌ＿ｔｏ＿ｏｎｅを１に等しくなるように設定し、ｂｉｔ＿ｅｑｕａｌ＿ｔｏ＿ｏｎｅを書き込むことができる。上述のように、ｂｉｔ＿ｅｑｕａｌ＿ｔｏ＿ｏｎｅは、更新版ＡＶＣドラフトに記載されている。ステップ２０２０で、エンコーダ３００は、以下で表１３および１４ならびに図２２から図２５に関連してさらに詳細に説明するｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿３ｄｖ＿ｅｘｔｅｎｓｉｏｎ（）を、さらに書き込むことができる。以下で述べるように、ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿３ｄｖ＿ｅｘｔｅｎｓｉｏｎ（）は、レイヤ間依存関係をデコーダに対して示す、または伝達して、デコーダが、ピクチャの復号中に当該ピクチャの適切な予測参照を決定できるようにすることができる。その後、この方法は、ステップ２０１０に進むことができる。

ステップ２０１０で、エンコーダ３００は、ａｄｄｉｔｉｏｎａｌ＿ｅｘｔｅｎｓｉｏｎ２＿ｆｌａｇを設定することができ、ａｄｄｉｔｉｏｎａｌ＿ｅｘｔｅｎｓｉｏｎ２＿ｆｌａｇが１に設定されている場合には、エンコーダ３００は、更新版ＡＶＣドラフトに記載されているように、全てのａｄｄｉｔｉｏｎａｌ＿ｅｘｔｅｎｓｉｏｎ２＿ｄａｔａ＿ｆｌａｇｓを書き込むことができる。ステップ２０１２で、エンコーダ３００は、更新版ＡＶＣドラフトに記載されているようにｒｂｓｐ＿ｔｒａｉｌｉｎｇ＿ｂｉｔｓ（）を書き込むことができ、その後、この方法は終了することができる。

次に、例えば方法２０００に従って生成されている可能性もあるＳＰＳを復号する方法２１００を示す図２１を参照すると、この方法２１００は、デコーダ４００が受信したビットストリームからシーケンス・パラメータ・セット・データｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｄａｔａ（）を復号し、更新版ＡＶＣドラフトに記載されているようにｐｒｏｆｉｌｅ＿ｉｄｃを設定することができる、ステップ２１０２から開始することができる。

ステップ２１０４で、デコーダ４００は、ｐｒｏｆｉｌｅ＿ｉｄｃが８３または８６に設定されているかどうかを判定することができる。ｐｒｏｆｉｌｅ＿ｉｄｃが８３または８６に設定されている場合には、この方法は、ステップ２０１６に進むことができ、このステップで、デコーダ４００は、更新版ＡＶＣドラフトに記載されているように、ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｓｖｃ＿ｅｘｔｅｎｓｉｏｎ（）を復号し、ｓｖｃ＿ｖｕｉ＿ｐａｒａｍｅｔｅｒｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを復号することができる。さらに、ステップ２１０６で、ｓｖｃ＿ｖｕｉ＿ｐａｒａｍｅｔｅｒｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが１に設定されている場合には、デコーダ４００は、更新版ＡＶＣドラフトに記載されているように、ｓｖｃ＿ｖｕｉ＿ｐａｒａｍｅｔｅｒ＿ｅｘｔｅｎｓｉｏｎ（）を復号することができる。その後、この方法は、以下でさらに詳細に述べるステップ２１０８に進むことができる。

ステップ２１０４に戻って、ｐｒｏｆｉｌｅ＿ｉｄｃが８３または８６に設定されていない場合には、この方法は、ステップ２１１２に進むことができ、このステップで、デコーダ４００は、ｐｒｏｆｉｌｅ＿ｉｄｃが１１８に設定されているかどうかを判定することができる。ｐｒｏｆｉｌｅ＿ｉｄｃが１１８に設定されている場合には、この方法は、ステップ２１１４に進むことができ、このステップで、デコーダ４００は、更新版ＡＶＣドラフトに記載されているように、ｂｉｔ＿ｅｑｕａｌ＿ｔｏ＿ｏｎｅを復号し、ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｍｖｃ＿ｅｘｔｅｎｓｉｏｎ（）を復号し、ｍｖｃ＿ｖｕｉ＿ｐａｒａｍｅｔｅｒｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを復号することができる。さらに、ｍｖｃ＿ｖｕｉ＿ｐａｒａｍｅｔｅｒｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが１に設定されている場合には、デコーダ４００は、更新版ＡＶＣドラフトに記載されているように、ｍｖｃ＿ｖｕｉ＿ｐａｒａｍｅｔｅｒｓ＿ｅｘｔｅｎｓｉｏｎ（）を復号することができる。その後、この方法は、以下でさらに詳細に述べるステップ２１０８に進むことができる。

ステップ２１１２で、デコーダ４００が、ｐｒｏｆｉｌｅ＿ｉｄｃが１１８に設定されていないと判定した場合には、この方法は、ステップ２１１６に進むことができ、このステップで、デコーダ４００は、ｐｒｏｆｉｌｅ＿ｉｄｃが２１８に設定されているかどうかを判定することができる。ｐｒｏｆｉｌｅ＿ｉｄｃが２１８に設定されていない場合には、この方法は、ステップ２１２０に進むことができ、このステップで、デコーダ４００は、未知のｐｒｏｆｉｌｅ＿ｉｄｃが読み取られていると判定することができ、エラー・メッセージを出力することができる。

しかし、ｐｒｏｆｉｌｅ＿ｉｄｃが２１８に設定されている場合には、デコーダ４００は、ステップ２１１８を実行することができ、このステップで、デコーダ４００は、ｂｉｔ＿ｅｑｕａｌ＿ｔｏ＿ｏｎｅを復号することができ、さらに、以下で表１３および１４ならびに図２２〜２５に関連してさらに詳細に述べるｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿３ｄｖ＿ｅｘｔｅｎｓｉｏｎ（）を復号することができる。その後、この方法は、ステップ２１０８に進むことができる。

ステップ２１０８で、デコーダ４００は、ａｄｄｉｔｉｏｎａｌ＿ｅｘｔｅｎｓｉｏｎ２＿ｆｌａｇを復号することができ、ａｄｄｉｔｉｏｎａｌ＿ｅｘｔｅｎｓｉｏｎ２＿ｆｌａｇが１に設定されている場合には、デコーダ４００は、更新版ＡＶＣドラフトに記載されているように、全てのａｄｄｉｔｉｏｎａｌ＿ｅｘｔｅｎｓｉｏｎ２＿ｄａｔａ＿ｆｌａｇｓを復号することができる。ステップ２１１０で、デコーダ４００は、更新版ＡＶＣドラフトに記載されているようにｒｂｓｐ＿ｔｒａｉｌｉｎｇ＿ｂｉｔｓ（）を復号することができ、その後、この方法は終了することができる。

上述のように、表１３は、ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿３ｄｖ＿ｅｘｔｅｎｓｉｏｎ（）の一実施態様を示しており、３ｄｖ＿ｌａｙｅｒ＿ｉｄおよびレイヤ間予測構造は、明示的に信号通信される。このような実施態様は、３ＤＶレイヤの様々な順序付けおよび様々なレイヤ間予測構造を指定することができるので、高い柔軟性を実現する。

表１３のセマンティクスは、以下のように与えられる。
ｎｕｍ＿３ｄｖ＿ｌａｙｅｒ＿ｍｉｎｕｓ１に１を加えた値は、３ＤＶレイヤの数を示す。
３ｄｖ＿ｌａｙｅｒ＿ｉｄ［ｉ］は、ｉ番目の３ＤＶレイヤの識別番号を指定する。
ｎｕｍ＿３ｄｖ＿ｌａｙｅｒ＿ｒｅｆｓ＿Ｉ０［ｉ］は、３ＤＶレイヤ識別番号が３ｄｖ＿ｌａｙｅｒ＿ｉｄ［ｉ］である３ＤＶレイヤの参照ピクチャ・リスト０中のレイヤ間参照の数を指定する。
３ｄｖ＿ｌａｙｅｒ＿ｒｅｆ＿Ｉ０［ｉ］［ｊ］は、３ＤＶレイヤ識別番号が３ｄｖ＿ｌａｙｅｒ＿ｉｄ［ｉ］である３ＤＶレイヤの参照ピクチャ・リスト０中のｊ番目のレイヤ間参照として使用される３ＤＶレイヤ識別番号を指定する。
ｎｕｍ＿３ｄｖ＿ｌａｙｅｒ＿ｒｅｆｓ＿Ｉ１［ｉ］は、３ＤＶレイヤ識別番号が３ｄｖ＿ｌａｙｅｒ＿ｉｄ［ｉ］である３ＤＶレイヤの参照ピクチャ・リスト１中のレイヤ間参照の数を指定する。
３ｄｖ＿ｌａｙｅｒ＿ｒｅｆ＿Ｉ１［ｉ］［ｊ］は、３ＤＶレイヤ識別番号が３ｄｖ＿ｌａｙｅｒ＿ｉｄ［ｉ］である３ＤＶレイヤの参照ピクチャ・リスト１中のｊ番目のレイヤ間参照として使用される３ＤＶレイヤ識別番号を指定する。

表１３のｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿３ｄｖ＿ｅｘｔｅｎｓｉｏｎ（）をどのようにして実施形態６で利用することができるかをよりよく示すために、サブセットＳＰＳ ３ＤＶ拡張を符号化する方法２２００を示す図２２、およびサブセットＳＰＳ ３ＤＶ拡張を復号する方法２３００を示す図２３を参照する。方法２２００は、エンコーダ３００によって実施することができ、方法２３００は、デコーダ４００によって実施することができることを理解されたい。

方法２２００は、エンコーダ３００が、更新版ＡＶＣドラフトに記載されているｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｍｖｃ＿ｅｘｔｅｎｓｉｏｎ（）を符号化することができるステップ２２０２から開始することができる。

ステップ２２０４で、エンコーダ３００は、ｎｕｍ＿３ｄｖ＿ｌａｙｅｒ＿ｍｉｎｕｓ１を設定し、符号化することができる。上記で示したように、ｎｕｍ＿３ｄｖ＿ｌａｙｅｒ＿ｍｉｎｕｓ１は、符号化対象の３ＤＶコンテンツの３ＤＶビュー中で利用される３ＤＶレイヤの総数を示している。符号化および復号に都合がよいように、ｎｕｍ＿３ｄｖ＿ｌａｙｅｒ＿ｍｉｎｕｓ１の数値は、実際の３ＤＶレイヤの数より１だけ小さい。

上述のように、「ｉ」は、３ＤＶレイヤのｉｄ番号を表す。例えば、３ＤＶレイヤｉｄは、上記の表１に定義する３ＤＶレイヤｉｄに対応することができる。ここで、ステップ２２０８で、エンコーダ３００は、符号化対象の３ＤＶコンテンツ中で利用される各タイプの３ＤＶレイヤごとに、３ＤＶレイヤＩＤを設定し、符号化することができる。従って、エンコーダ３００は、３ＤＶコンテンツの３ＤＶビュー中で利用される３ＤＶレイヤの総数に達するまで、ループ２２０６で各３ＤＶレイヤｉｄを繰り返し処理する。

ループ２２１０で、ループ２２１０の第１行目に記しているように、エンコーダ３００は、ループ２２１０において各３ＤＶレイヤｉｄを連続的に処理して、各参照ピクチャ・リスト・タイプ０および場合によっては１の各３ＤＶレイヤの３ＤＶレイヤ間参照を設定し、符号化する。例えば、ステップ２２１２で、エンコーダ３００は、参照ピクチャ・リストが割り当てられた３ＤＶレイヤ（「ｉ」で表される）の参照ピクチャ・リスト０のレイヤ間参照の総数（ｎｕｍ＿３ｄｖ＿ｌａｙｅｒ＿ｒｅｆｓ＿Ｉ０［ｉ］）を設定し、符号化することができる。なお、任意の参照ピクチャ・リスト中のレイヤ間参照の数は、利用するレイヤ間依存関係構造によって決まることに留意されたい。例えば、図１５の構造１５００では、各３ＤＶレイヤは、当該３ＤＶレイヤに割り当てられた参照ピクチャ・リストに、最大で１つしかレイヤ間参照を有していない。しかし、以下に実施形態７で述べる構造など、その他のレイヤ間依存関係または予測構造を利用することもできる。

参照ピクチャ・リスト「０」の３ＤＶレイヤ「ｉ」のレイヤ間参照の総数を設定した後で、エンコーダ３００は、ステップ２２１６で、３ＤＶレイヤ「ｉ」の参照ピクチャ・リスト「０」レイヤ間参照を設定し、符号化することができる。具体的には、エンコーダ３００は、３ＤＶレイヤ「ｉ」の参照ピクチャ・リスト「０」のレイヤ間参照の３ＤＶレイヤｉｄ（３ｄｖ＿ｌａｙｅｒ＿ｒｅｆ＿Ｉ０［ｉ］［ｊ］）を指定することができる。図２２および表１３では、３ＤＶレイヤ「ｉ」の参照ピクチャ・リスト「０」のレイヤ間参照を「ｊ」で表すことができ、参照ピクチャ・リスト「０」の３ＤＶレイヤ「ｉ」のレイヤ間参照の総数に達するまで、ループ２２１４でステップ２２１６を繰り返すことができるようになっている。

エンコーダ３００は、さらに、３ＤＶレイヤ「ｉ」の任意の参照ピクチャ・リスト「１」のレイヤ間参照を提供するように構成することもできる。しかし、ある３ＤＶレイヤ「ｉ」が参照ピクチャ・リスト「１」を有していない場合には、方法２２００の後続のステップをスキップすることもできることを理解されたい。３ＤＶレイヤ「ｉ」が参照ピクチャ・リスト「１」を有する場合には、この方法は、ステップ２２１８に進むことができ、このステップで、エンコーダ３００は、参照ピクチャ・リスト「１」が割り当てられた３ＤＶレイヤｉの参照ピクチャ・リスト１中のレイヤ間参照の総数（ｎｕｍ＿３ｄｖ＿ｌａｙｅｒ＿ｒｅｆｓ＿Ｉ１［ｉ］）を設定し、符号化することができる。

参照ピクチャ・リスト「１」の３ＤＶレイヤ「ｉ」のレイヤ間参照の総数を設定した後で、エンコーダ３００は、ステップ２２２２で、３ＤＶレイヤ「ｉ」の参照ピクチャ・リスト「１」のレイヤ間参照を設定し、符号化することができる。具体的には、エンコーダ３００は、３ＤＶレイヤ「ｉ」の参照ピクチャ・リスト「１」のレイヤ間参照の３ＤＶレイヤｉｄ（３ｄｖ＿ｌａｙｅｒ＿ｒｅｆ＿Ｉ１［ｉ］［ｊ］）を指定することができる。３ＤＶレイヤ「ｉ」の参照ピクチャ・リスト「０」に関する上記の説明と同様に、３ＤＶレイヤ「ｉ」の参照ピクチャ・リスト「１」のレイヤ間参照も「ｊ」で表すことができ、参照ピクチャ・リスト「１」の３ＤＶレイヤ「ｉ」のレイヤ間参照の総数に達するまで、ループ２２２０でステップ２２２２を繰り返すことができるようになっている。

さらに、上記で示したように、ループ２２１０では、ステップ２２１２および２２１８ならびにループ２２１４および２２２０を、符号化対象の３ＤＶコンテンツの３ＤＶビューで利用される全ての３ＤＶレイヤが処理されるまで、それらのレイヤのそれぞれについて繰り返すことができる。

次に、図２３を参照すると、ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿３ｄｖ＿ｅｘｔｅｎｓｉｏｎ（）を用いてビットストリーム中の受信したＳＰＳ ３ＤＶ拡張を復号する方法２３００が示してある。方法２３００は、デコーダ４００が、更新版ＡＶＣドラフトに記載されているｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｍｖｃ＿ｅｘｔｅｎｓｉｏｎ（）を復号することができるステップ２３０２から開始することができる。

ステップ２３０４で、デコーダ４００は、ｎｕｍ＿３ｄｖ＿ｌａｙｅｒ＿ｍｉｎｕｓ１を復号し、取得する。上述のように、ｎｕｍ＿３ｄｖ＿ｌａｙｅｒ＿ｍｉｎｕｓ１は、３ＤＶコンテンツの３ＤＶビュー中で利用される３ＤＶレイヤの総数を示している。上述のように、ｎｕｍ＿３ｄｖ＿ｌａｙｅｒ＿ｍｉｎｕｓ１の数値は、３ＤＶレイヤの実際の数より１だけ小さい。

上述のように、「ｉ」は、３ＤＶレイヤのｉｄ番号を表す。例えば、３ＤＶレイヤｉｄは、上記の表１に定義する３ＤＶレイヤｉｄに対応することができる。ここで、ステップ２３０８で、デコーダ４００は、３ＤＶコンテンツ中で利用される各タイプの３ＤＶレイヤごとに、３ＤＶレイヤＩＤを復号し、取得することができる。従って、デコーダ４００は、３ＤＶコンテンツの３ＤＶビュー中で利用される３ＤＶレイヤの総数に達して、各３ＤＶレイヤｉｄが取得されるまで、ループ２３０６で各３ＤＶレイヤｉｄを繰り返し処理する。

ループ２３１０で、ループ２３１０の第１行目に記しているように、デコーダ４００は、ループ２３１０において各３ＤＶレイヤｉｄを連続的に処理して、各参照ピクチャ・リスト・タイプ０および場合によっては１の各３ＤＶレイヤの３ＤＶレイヤ間参照を復号し、取得する。例えば、ステップ２３１２で、デコーダ４００は、参照ピクチャ・リストが割り当てられた３ＤＶレイヤ（「ｉ」で表される）の参照ピクチャ・リスト０のレイヤ間参照の総数（ｎｕｍ＿３ｄ＿ｌａｙｅｒ＿ｒｅｆｓ＿Ｉ０［ｉ］）を復号し、取得することができる。なお、任意の参照ピクチャ・リスト中のレイヤ間参照の数は、利用するレイヤ間依存関係構造によって決まることに留意されたい。例えば、図１５の構造１５００では、各３ＤＶレイヤは、当該３ＤＶレイヤに割り当てられた参照ピクチャ・リストに、最大で１つしかレイヤ間参照を有していない。しかし、以下に実施形態７で述べる構造など、その他のレイヤ間依存関係または予測構造を利用することもできる。

参照ピクチャ・リスト「０」の３ＤＶレイヤ「ｉ」のレイヤ間参照の総数を取得した後で、デコーダ４００は、ステップ２３１６で、３ＤＶレイヤ「ｉ」の参照ピクチャ・リスト「０」レイヤ間参照を復号し、取得することができる。具体的には、デコーダ４００は、３ＤＶレイヤ「ｉ」の参照ピクチャ・リスト「０」のレイヤ間参照の３ＤＶレイヤｉｄ（３ｄｖ＿ｌａｙｅｒ＿ｒｅｆ＿Ｉ０［ｉ］［ｊ］）を取得することができる。図２３および表１３では、３ＤＶレイヤ「ｉ」の参照ピクチャ・リスト「０」のレイヤ間参照を「ｊ」で表すことができ、参照ピクチャ・リスト「０」の３ＤＶレイヤ「ｉ」のレイヤ間参照の総数に達するまで、ループ２３１４でステップ２３１６を繰り返すことができるようになっている。

デコーダ４００は、さらに、３ＤＶレイヤ「ｉ」の任意の参照ピクチャ・リスト「１」のレイヤ間参照を取得するように構成することもできる。しかし、ある３ＤＶレイヤ「ｉ」が参照ピクチャ・リスト「１」を有していない場合には、方法２３００の後続のステップをスキップすることもできることを理解されたい。３ＤＶレイヤ「ｉ」が参照ピクチャ・リスト「１」を有する場合には、この方法は、ステップ２３１８に進むことができ、このステップで、デコーダ４００は、参照ピクチャ・リスト「１」が割り当てられた３ＤＶレイヤ「ｉ」の参照ピクチャ・リスト１中のレイヤ間参照の総数（ｎｕｍ＿３ｄｖ＿ｌａｙｅｒ＿ｒｅｆｓ＿Ｉ１［ｉ］）を復号し、取得することができる。

参照ピクチャ・リスト「１」の３ＤＶレイヤ「ｉ」のレイヤ間参照の総数を取得した後で、デコーダ４００は、ステップ２３２２で、３ＤＶレイヤ「ｉ」の参照ピクチャ・リスト「１」のレイヤ間参照を復号し、取得することができる。具体的には、デコーダ４００は、３ＤＶレイヤ「ｉ」の参照ピクチャ・リスト「１」のレイヤ間参照の３ＤＶレイヤｉｄ（３ｄｖ＿ｌａｙｅｒ＿ｒｅｆ＿Ｉ１［ｉ］［ｊ］）を取得することができる。３ＤＶレイヤ「ｉ」の参照ピクチャ・リスト「０」に関する上記の説明と同様に、３ＤＶレイヤ「ｉ」の参照ピクチャ・リスト「１」のレイヤ間参照も「ｊ」で表すことができ、参照ピクチャ・リスト「１」の３ＤＶレイヤ「ｉ」のレイヤ間参照の総数に達するまで、ループ２３２０でステップ２３２２を繰り返すことができるようになっている。

さらに、上記で示したように、ループ２３１０では、ステップ２３１２および２３１８ならびにループ２３１４および２３２０を、３ＤＶコンテンツの３ＤＶビューで利用される全ての３ＤＶレイヤが処理されるまで、それらのレイヤのそれぞれについて繰り返すことができる。このようにして、デコーダ４００は、各３ＤＶレイヤごとに１つまたは複数の参照ピクチャ・リストを構築することができ、それにより、受信した３ＤＶレイヤ・ピクチャの復号中に、それらのピクチャそれぞれのレイヤ間参照を決定することができる。

なお、ネットワーク・デバイスは、３ＤＶレイヤに関する情報および予測構造を構文解析するときに、異なる３ＤＶレイヤに属するＮＡＬユニットに対して、異なる伝送の優先順位を割り当てることができる。従って、輻輳が生じたときに、「上位の」３ＤＶ補足レイヤに属するいくつかのＮＡＬユニット（例えば表１の上位の３Ｄレイヤｉｄ）を廃棄して、トラフィックを緩和することができる。

［実施形態７：ＳＰＳの３ＤＶ適用分野の信号パラメータへの代替拡張］
いくつかの実施態様では、使用できる可能性のある３ＤＶレイヤの数が制限されていることがあり、３ＤＶレイヤのコンテンツが特定の、且つ一貫した特性を有することがあるので、３ＤＶを符号化および復号するために使用される予測構造が事前に構成され、エンコーダおよびデコーダの双方がそれを知っていることがある。従って、発明者等は、例えば実施形態６の表１３に示すように、明示的な方法で特定の予測またはレイヤ間依存関係構造を信号通信して伝達する必要がない。むしろ、実施形態７では、レイヤ間予測構造は、エンコーダおよびデコーダの双方にとって既知であるようにすることにより、３ＤＶの拡張ＳＰＳのデコーダへの伝達を簡略化することができる。

簡単な例を挙げるために、上記に定義した以下の３ＤＶレイヤを利用する。すなわち、２Ｄ映像レイヤ、奥行きレイヤ、隠蔽映像レイヤ、隠蔽奥行きレイヤ、および透明度レイヤを利用する。

以下、様々な実施態様で利用することができる事前に定義されたレイヤ間予測構造の一例について述べる。ただし、他の実施態様では、他の事前に定義されたレイヤ間予測構造を利用することができることを理解されたい。この構造では、２Ｄ映像レイヤに対して、３ＤＶ補足レイヤをレイヤ間予測参照として使用することはない。奥行きレイヤに対しては、２Ｄ映像レイヤを、レイヤ間予測参照として使用する。隠蔽映像レイヤに対しては、２Ｄ映像レイヤおよび奥行きレイヤが、レイヤ間参照として使用される。隠蔽奥行きレイヤに対しては、２Ｄ映像レイヤおよび奥行きレイヤが、レイヤ間参照として使用される。透明度レイヤに対しては、２Ｄ映像レイヤおよび奥行きレイヤが、レイヤ間参照として使用される。

ここで、実施形態７では、レイヤ間予測構造を事前に定義することができるので、３ＤＶの拡張ＳＰＳは、表１４に示すように、各３ＤＶビューについてあるレイヤが存在するかどうかを簡単に伝達することができる。従って、ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿３ｄｖ＿ｅｘｔｅｎｓｉｏｎ（）は、単純に、可能性のある各３ＤＶレイヤごとに複数のフラグを利用して、３ＤＶコンテンツの各３ＤＶビュー中でそれらが利用されているかどうかを示すことができる。従って、３ＤＶの拡張ＳＰＳは、いかなる明示的な方法でも、レイヤ間予測構造を信号通信または伝達する必要がない。一実施態様では、レイヤ間予測構造は、一定であり、変更することができない。別の実施態様では、レイヤ間予測構造は、表１３を用いて設定され（例えば表１２の最初の出現時または定期的な出現時）、それ以外の場合には、表１４を用いて拡張情報を通信する。表１２〜１４は、設計の選択に従って望ましい頻度でデコーダに再伝送することができ、一実施態様では、この情報に変更があったときだけ再伝送されることに留意されたい。

実施形態７で表１４のｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿３ｄｖ＿ｅｘｔｅｎｓｉｏｎ（）をどのようにして利用することができるかをよりよく示すために、サブセットＳＰＳ ３ＤＶを符号化する方法２４００を示す図２４、およびサブセットＳＰＳ ３ＤＶを復号する方法２５００を示す図２５を参照する。方法２４００は、エンコーダ３００によって実施することができ、方法２５００は、デコーダ４００によって実施することができることを理解されたい。

方法２４００は、エンコーダ３００が、更新版ＡＶＣドラフトに記載されているｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｍｖｃ＿ｅｘｔｅｎｓｉｏｎ（）を符号化することができるステップ２４０２から開始することができる。次いで、エンコーダ３００は、ループ２４０４を実行することができ、このループにおいて、エンコーダ３００は、３ＤＶレイヤ・フラグを設定して、特定の３ＤＶビュー「ｉ」についてそれぞれの３ＤＶレイヤが存在するかどうかを示すことができる。例えば、ｎｕｍ＿ｖｉｅｗｓ＿ｍｉｎｕｓ１は、３ＤＶコンテンツで利用される３ＤＶビューの総数を示す。例えば、図１０〜図１２に示す例では、３つの３ＤＶビューが利用される（３ＤＶビュー０〜３ＤＶビュー２）。符号化および復号に都合がよいように、ｎｕｍ＿ｖｉｅｗｓ＿ｍｉｎｕｓ１の数値は、実際の３ＤＶビューの数より１だけ小さい。エンコーダ３００は、３ＤＶコンテンツで利用される３ＤＶビューの総数に達するまで、各３ＤＶビュー「ｉ」についてステップ２４０６〜２４１４を繰り返すことができる。

具体的には、ループ２４０４において、エンコーダ３００は、ステップ２４０６で、２Ｄ映像レイヤ・フラグを設定し、符号化して、２Ｄ映像レイヤが３ＤＶビュー「ｉ」中に存在するかどうかを示すことができ、ステップ２４０８で、（２Ｄ）奥行きレイヤ・フラグを設定し、符号化して、奥行きレイヤが３ＤＶビュー「ｉ」中に存在するかどうかを示すことができ、ステップ２４１０で、隠蔽映像レイヤ・フラグを設定し、符号化して、隠蔽映像レイヤが３ＤＶビュー「ｉ」中に存在するかどうかを示すことができ、ステップ２４１２で、隠蔽奥行きレイヤ・フラグを設定し、符号化して、隠蔽奥行きレイヤが３ＤＶビュー「ｉ」中に存在するかどうかを示すことができ、ステップ２４１４で、透明度レイヤ・フラグを設定し、符号化して、透明度レイヤが３ＤＶビュー「ｉ」中に存在するかどうかを示すことができる。

次に、表１４を用いてサブセットＳＰＳ ３ＤＶを復号する方法２５００について述べる。方法２５００は、デコーダ４００が、更新版ＡＶＣドラフトに記載されているｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｍｖｃ＿ｅｘｔｅｎｓｉｏｎ（）を復号することができるステップ２５０２から開始することができる。方法２５００におけるデコーダ４００は、方法２４００に従ってエンコーダ３００によって符号化されたビットストリームを受信することができることに留意されたい。デコーダ４００も、ループ２５０４を実行することができ、このループにおいて、デコーダ４００は、３ＤＶレイヤ・フラグを復号して、特定の３ＤＶビュー「ｉ」についてそれぞれの３ＤＶレイヤが存在するかどうかを判定することができる。例えば、方法２４００に関して上述したように、ｎｕｍ＿ｖｉｅｗｓ＿ｍｉｎｕｓ１は、受信した３ＤＶコンテンツで利用される３ＤＶビューの総数を示す。デコーダ４００は、３ＤＶコンテンツで利用される３ＤＶビューの総数に達するまで、各３ＤＶビュー「ｉ」についてステップ２５０６〜２５１４を繰り返すことができる。

具体的には、ループ２５０４において、デコーダ４００は、ステップ２５０６で、２Ｄ映像レイヤ・フラグを復号し、取得して、２Ｄ映像レイヤが３ＤＶビュー「ｉ」中に存在するかどうかを判定することができ、ステップ２５０８で、（２Ｄ）奥行きレイヤ・フラグを復号し、取得して、奥行きレイヤが３ＤＶビュー「ｉ」中に存在するかどうかを判定することができ、ステップ２５１０で、隠蔽映像レイヤ・フラグを復号し、取得して、隠蔽映像レイヤが３ＤＶビュー「ｉ」中に存在するかどうかを判定することができ、ステップ２５１２で、隠蔽奥行きレイヤ・フラグを復号し、取得して、隠蔽奥行きレイヤが３ＤＶビュー「ｉ」中に存在するかどうかを判定することができ、ステップ２５１４で、透明度レイヤ・フラグを復号し、取得して、透明度レイヤが３ＤＶビュー「ｉ」中に存在するかどうかを判定することができる。

上述のように、デコーダ４００は、各３ＤＶビュー中の各３ＤＶレイヤの１つまたは複数の参照ピクチャ・リストを再構築することができ、それにより、受信した３ＤＶレイヤ・ピクチャの復号中に、各３ＤＶレイヤ・ピクチャのレイヤ間参照を決定することができる。

［追加の実施形態］
次に、図２６および図２７を参照すると、３ＤＶコンテンツを符号化する方法２６００および３ＤＶコンテンツを復号する方法２７００が示してある。実施形態に関連して本明細書で述べる何れか１つまたは複数の特徴、およびそれらの組合せは、方法２６００および２７００において、またはこれらの方法を用いて実施することができる。例えば、以下でさらに述べるように、実施形態１〜３は、単独で、または任意に組み合わせて、方法２６００および２７００において、またはこれらの方法によって実施することができる。さらに、図３のエンコーダ３００を使用して方法２６００を実施し、図４のデコーダ４００を使用して方法２７００を実施することができることにも留意されたい。

方法２６００は、ステップ２６０２から開始し、エンコーダ３００が複数のピクチャを符号化することができる。ここで、これら複数のピクチャは、所与の時点の所与のビューについての異なる３Ｄ情報を記述したものである。例えば、エンコーダ３００について上述したレイヤ・エンコーダの何れか１つまたは複数を使用して、実施形態１、２および／または３の何れか１つまたは複数に従って複数のピクチャの符号化を実施することができる。複数のピクチャは、例えば、２Ｄ映像レイヤ・ピクチャおよび奥行きレイヤ・ピクチャとすることができる。２Ｄ映像レイヤ・ピクチャによって記述される３Ｄ情報は、例えば、２Ｄ映像とすることができる。同様に、奥行きレイヤ・ピクチャによって記述される３Ｄ情報は、例えば、奥行き情報とすることができる。２Ｄ映像情報および奥行き情報は、両方とも、所与の時点の所与のビューについての３Ｄ情報の例である。

追加の実施形態の方法を説明するために、「ピクチャ」は、様々な実施形態について上述した「フレーム」と等価であるとすることができる。さらに、ピクチャは、上述の何れか１つまたは複数の３ＤＶレイヤに対応することができる。例えば、２Ｄビュー１０１０および奥行きビュー１００８は、それぞれ別個のピクチャを構成することができる。さらに、図１１および／または図１２に関連して上述した任意の２Ｄビュー・レイヤ１１１８、１１２２、１１３６、１２１８、１２２２、１２３６、および／または任意の奥行きレイヤ１１２０、１１２４、１２２０、１２２４も、それぞれ別個のピクチャを構成することができる。さらに、図１１および図１２に明示的には図示していないが上述したその他の３ＤＶ補足レイヤも、それぞれ別個のピクチャを構成することができる。さらに、上述の３ＤＶビューの何れか１つまたは複数は、図１１および図１２に関連して上述した、時点Ｔ０およびＴ１における３Ｄビュー０、１および２など、所与の時点の所与のビューを構成することができる。

ステップ２６０４で、エンコーダ３００は、複数の符号化済みピクチャについて、これらの符号化済みピクチャが、上記複数のピクチャのコンテンツ・タイプを規定する３Ｄ処理に対応する構造にどのように適応するかを示すシンタックス要素を生成することができる。例えば、３ＤＶ参照バッファ３１６は、実施形態１、２および／または３の何れか１つまたは複数に従ってシンタックス要素を生成することができる。シンタックス要素は、例えば、実施形態１に関連して上述した３ＤＶプレフィックス・ユニット１６、実施形態２のＮＡＬプレフィックス・ユニット１４および／またはＮＡＬユニット２０、ならびに／あるいは実施形態３のＮＡＬユニット２１とすることができる。上述のように、実施形態１、２および３による新規のＮＡＬユニットは、符号化済み３ＤＶレイヤについて、図１０の構造１０００など３Ｄ処理に対応する構造に、各レイヤがどのように適応するかを示すことができる。さらに、ＮＡＬユニット１６および２１など、新規のＮＡＬユニットを使用することで、ビットストリームにおいて図１０に示す構造などの３ＤＶ構造が使用されていることを示すことができる。上述のように、構造１０００は、３ＤＶレイヤの様々なタイプなど、様々なコンテンツ・タイプを規定することができる。構造は、図１０に示すように１組の３ＤＶビューのセットに対応することができ、且つ／または３ＤＶビュー内の１組のレイヤのセットに対応することができることを理解されたい。また、エンコーダ３００は、あるピクチャを、別の符号化済みピクチャを参照として使用して符号化することによって、コンテンツ・タイプの異なるピクチャ間でレイヤ間符号化を実現することができることも理解されたい。例えば、図１０を例として用いると、ビュー１００４の奥行きビューは、ビュー１００４の２Ｄビューなど異なるレイヤに依存して、これを参照することにより、レイヤ間符号化を実現することができる。さらに、図１０の符号化構造は、ビュー１００４の２Ｄビューが、ビュー１００６の奥行きレイヤなど別のレイヤに依存して、これを参照するように構成することができる。上記に示すように、その他のタイプのレイヤ間符号化も可能であり、当業者なら、本明細書に与える教示に鑑みて実施することができる。

ステップ２６０６で、エンコーダ３００は、複数の符号化済みピクチャおよびシンタックス要素を含むビットストリームを生成することができる。ここで、シンタックス要素を含むことにより、符号化済みビットストリームのレベルで、構造中の複数の符号化済みピクチャ間の関係を示す指示を与えることができる。例えば、３ＤＶ参照バッファ３１６は、ビットストリーム３１８を生成することができるが、このビットストリーム３１８は、上述のように実施形態１、２および／または３に従って生成された符号化済みビットストリームの何れかを含むことができる。従って、このビットストリームは、図１０〜図１２に関連した上述したレイヤ・フレームの何れか１つまたは複数など、複数の符号化済みピクチャを含むことができ、また、上述のように符号化済みビットストリーム・レベルで構造中の複数の符号化済みピクチャ間の関係を示す指示を提供することができる実施形態１の３ＤＶプレフィックス・ユニット１６、実施形態２のＮＡＬプレフィックス・ユニット１４および／またはＮＡＬユニット２０、ならびに／あるいは実施形態３のＮＡＬユニット２１のうちの何れか１つまたは複数を含むことができる。例えば、シンタックス要素は、図１０の構造中、あるいは３ＤＶコンテンツに対応するその他の構造中の複数のピクチャまたはレイヤ間の依存関係および関係を示すことができる。例えば、シンタックス要素は、どのようにしてピクチャを結合して３ＤＶコンテンツを生成すべきかを示す指示を与えることができる。

様々な実施形態において、エンコーダ３００のレイヤ・エンコーダ３０４〜３１４のセットを、ステップ２６０２を実行するように構成することができることを理解されたい。さらに、３ＤＶ参照バッファ３１６および／またはレイヤ・エンコーダ３０４〜３１４は、ステップ２６０４〜２６０６の何れか１つまたは複数を実行するように構成することができる。あるいは、またはこれに加えて、エンコーダ３００は、少なくとも方法２６００を実行するように構成されたプロセッサを含むこともできる。さらに、実施形態は、ステップ２６０２で生成された複数の符号化済みピクチャ、ステップ２６０４で生成されたシンタックス要素、および／またはステップ２６０６で生成された、ビットストリームに含まれる何れか１つまたは複数の要素（ビットストリーム自体も含む）を含むようにフォーマット化された映像信号および／または映像信号構造を含むことができる。さらに、実施形態は、映像信号構造を記憶したプロセッサ可読媒体を含むこともできる。さらに、上記に示したように、図７の変調器７２２は、映像信号を変調するように構成することができる。さらに、実施形態は、プロセッサに少なくとも方法２６００を実行させる命令を記憶したプロセッサ可読媒体を含むこともできる。

図２７に示す３ＤＶコンテンツを復号する方法２７００を再度参照すると、方法２７００は、デコーダ４００がビットストリームに属する複数の符号化済みピクチャにアクセスすることができるステップ２７０２から開始することができる。これら複数のピクチャは、所与の時点の所与のビューについての異なる３Ｄ情報を記述している。例えば、ビットストリームは、方法２６００によって生成されるビットストリームに対応することができる。方法２６００に関連して上述したように、図１１および／または図１２に関連して上述した任意の２Ｄビュー・レイヤおよび／または任意の奥行きレイヤは、それぞれ別個のピクチャを構成することができる。さらに、叙述のように、図１１および図１２に明示的には図示していないが上述したその他の３ＤＶ補足レイヤも、それぞれ別個のピクチャを構成することができる。さらに、上述の３ＤＶビューの何れか１つまたは複数は、図１１および図１２に関連して上述した、時点Ｔ０およびＴ１における３Ｄビュー０、１および２など、所与の時点の所与のビューを構成することができる。

ステップ２７０４で、デコーダ４００は、ビットストリームに属するシンタックス要素にアクセスすることができる。シンタックス要素は、複数の符号化済みピクチャについて、符号化済みピクチャがどのように３Ｄ処理に対応する構造に適応するかを示す。この構造は、複数のピクチャ間の規定された関係を与える。例えば、３ＤＶ参照バッファ４１４は、実施形態１、２および／または３の何れか１つまたは複数に従ってシンタックス要素にアクセスすることができる。シンタックス要素は、例えば、実施形態１に関連して上述した３ＤＶプレフィックス・ユニット１６、実施形態２のＮＡＬプレフィックス・ユニット１４および／またはＮＡＬユニット２０、ならびに／あるいは実施形態３のＮＡＬユニット２１とすることができる。上述のように、実施形態１、２および３による新規のＮＡＬユニットは、符号化済み３ＤＶレイヤについて、図１０の構造１０００など３Ｄ処理に対応する構造に、各レイヤがどのように適応するかを示すことができる。さらに、ＮＡＬユニット１６および２１など、新規のＮＡＬユニットを使用することで、ビットストリームにおいて図１０に示す構造などの３ＤＶ構造が使用されていることを示すことができる。上述のように、構造１０００は、３ＤＶレイヤの様々なタイプなど、様々なコンテンツ・タイプを規定することができる。構造は、図１０に示すように１組の３ＤＶビューのセットに対応することができ、且つ／または３ＤＶビュー内の１組のレイヤのセットに対応することができることを理解されたい。また、デコーダ４００は、あるピクチャを、別の符号化済みピクチャを参照として使用して復号することによって、コンテンツ・タイプの異なるピクチャ間のレイヤ間復号を可能にすることができることも理解されたい。例えば、図１０を例として用いると、ビュー１００４の奥行きビューは、ビュー１００４の２Ｄビューなど異なるレイヤに依存して、これを参照することにより、レイヤ間復号を可能にすることができる。さらに、図１０の符号化構造は、ビュー１００４の２Ｄビューが、ビュー１００６の奥行きレイヤなど別のレイヤに依存して、これを参照するように構成することができる。上記に示すように、その他のタイプのレイヤ間復号も可能であり、当業者なら、本明細書に与える教示に鑑みて実施することができる。さらに、実施形態１〜３に関連して上述したように、実施形態１の３ＤＶプレフィックス・ユニット１６、実施形態２のＮＡＬプレフィックス・ユニット１４および／またはＮＡＬユニット２０、ならびに／あるいは実施形態３のＮＡＬユニット２１の何れか１つまたは複数は、上述のように、３ＤＶビューＩＤおよび３ＤレイヤＩＤを用いることによって、ビットストリームのピクチャ間の規定された関係を与えることができる。例えば、デコーダ４００は、図１０の構造１０００などの３ＤＶ構造に従ってピクチャを結合するように事前に構成することができ、３ＤＶビューＩＤおよび３ＤＶレイヤｉｄを使用して、受信したどのピクチャが、既定の構造中の様々なレイヤに対応するかを特定することができる。

ステップ２７０６で、デコーダ４００は、複数の符号化ピクチャを復号するように構成することができる。例えば、デコーダ４００は、例えば図４および図６に関連して上述したように、レイヤ・デコーダ４０２〜４１２を用いて受信したピクチャを復号することができる。例えば、デコーダ４００は、シンタックス要素によって示され、与えられる規定された関係を使用して、２次元（２Ｄ）映像レイヤ・ピクチャ、奥行きレイヤ・ピクチャ、隠蔽レイヤ・ピクチャまたは透明度ピクチャのうちの１つまたは複数を参照する追加のピクチャを描画することができる。例えば、上述のように、図１０のビュー１００４の奥行きビューは、ビュー１００４の２Ｄビューなど異なるレイヤに依存して、これを参照することにより、レイヤ間符号化を実現することができる。従って、デコーダ４００は、様々な異なるレイヤ・ピクチャの１つまたは複数から、ビュー１００４の奥行きビューなど、追加のピクチャを描画することができる。

ステップ２７０８で、デコーダ４００は、複数のピクチャ間の規定された関係を示す出力フォーマットで、復号済みピクチャを供給することができる。例えば、デコーダ４００の３ＤＶ参照／出力バッファ４１４は、３ＤＶ構造に従ってフォーマット化された３ＤＶコンテンツを出力することができる。従って、この出力は、この構造による複数のピクチャ間の関係をディスプレイ・デバイスに対して示して、３ＤＶコンテンツをディスプレイ・デバイスに適切に表示することができるようにし、３ＤＶコンテンツをユーザが見ることができるようにすることができる。具体的には、出力フォーマットは、復号済みピクチャがどのように構造に適応するかを指定するシンタックス要素を含むことができる。このようなシンタックス要素の例としては、実施形態１の３ＤＶプレフィックス・ユニット１６、実施形態２のＮＡＬプレフィックス・ユニット１４および／またはＮＡＬユニット２０、ならびに／あるいは実施形態３のＮＡＬユニット２１の何れか１つまたは複数が挙げられる。

任意選択のステップ２７１０〜２７１４は、ステップ２７０８を実行した後で、デコーダにおいて実行することができる。いくつかの実施態様では、ステップ２７１０〜２７１４の１つまたは複数を、ステップ２７０８の一部および／またはステップ２７０６の復号の一部として実行することができる。様々な実施態様で、ステップ２７１０〜２７１４の１つまたは複数、特にステップ２７１４は、ディスプレイにおいて実行することができる。

必要に応じて、ステップ２７１０で、デコーダ４００は、シンタックス要素を用いて複数のピクチャから２Ｄ映像ピクチャを識別することができる。例えば、デコーダ４００は、３ＤＶレイヤを符号化するために実施される実施形態１の３ＤＶプレフィックス・ユニット１６、実施形態２のＮＡＬプレフィックス・ユニット１４および／またはＮＡＬユニット２０、ならびに／あるいは実施形態３のＮＡＬユニット２１の何れか１つまたは複数を構文解析することによって、２Ｄ映像ピクチャまたはレイヤを識別することができる。デコーダ４００は、さらに、符号化済みピクチャのうちのどれが上記では「０」として表した２Ｄビュー・レイヤＩＤを有するかを決定し、３ＤＶビューＩＤを用いて対応する３ＤＶビューを決定することができる。

必要に応じて、ステップ２７１２で、デコーダ４００は、シンタックス要素を用いて複数のピクチャから奥行きピクチャを識別することができる。例えば、デコーダ４００は、３ＤＶレイヤを符号化するために実施される実施形態１の３ＤＶプレフィックス・ユニット１６、実施形態２のＮＡＬプレフィックス・ユニット１４および／またはＮＡＬユニット２０、ならびに／あるいは実施形態３のＮＡＬユニット２１の何れか１つまたは複数を構文解析することによって、奥行きピクチャまたはレイヤを識別することができる。さらに、デコーダ４００は、符号化済みピクチャのうちのどれが上記では「１」として表した奥行きレイヤＩＤを有するかを決定し、３ＤＶビューＩＤを用いて対応する３ＤＶビューを決定することができる。なお、様々な実施形態では、シンタックス要素を用いてその他の３ＤＶ補足レイヤを識別することもできることに留意されたい。

必要に応じて、ステップ２７１４で、デコーダ４００は、２Ｄ映像ピクチャおよび奥行きピクチャに基づいて追加ビューの新たなピクチャを描画することができる。例えば、識別されたピクチャまたはビューは、図１０の２Ｄビュー１０１０および奥行きビュー１００８に対応することができる。さらに、３ＤＶビュー１００４および１００６は、例えば、図１０に関連して上記に与えた説明に従って、３ＤＶベース・ビュー１００２の２Ｄビュー１０１０および奥行きビュー１００８を参照として用いて描画することができる。同様に、３ＤＶビュー１００６の２Ｄ映像レイヤおよび奥行きレイヤを参照として使用して、図１０に関連して上記に与えた説明に従って、３ＤＶビュー１００４を描画することができる。

様々な実施形態によれば、デコーダ４００のレイヤ・デコーダ４０２〜４１２のセットは、ステップ２７０２および２７０６を実行するように構成することができることを理解されたい。さらに、３ＤＶ参照バッファ４１４および／またはレイヤ・デコーダ４０２〜４１２は、ステップ２７０４および２７０８の何れか１つまたは複数を実行するように構成することができる。あるいは、またはこれに加えて、デコーダ４００は、少なくとも方法２７００を実行するように構成されたプロセッサを含むことができる。さらに、上記に示したように、図８の復調器８２２は、ステップ２７０２でアクセスした複数の符号化ピクチャが属しているビットストリームを含む映像信号を復調するように構成することができる。さらに、いくつかの実施形態では、プロセッサに少なくとも方法２７００を実行させる命令を記憶したプロセッサ可読媒体を含むこともできる。

次に、図２８を参照すると、参照ピクチャ・リストを構築する方法２８００が示してある。実施形態に関連して本明細書で述べる何れか１つまたは複数の特徴およびそれらの組合せは、方法２８００において、またはこれを用いて実施することができることを理解されたい。例えば、以下でさらに述べるように、実施形態４は、方法２８００において、またこの方法によって実施することができる。さらに、実施形態１〜３および５〜７の何れか１つまたは複数は、実施形態４と組み合わせて、方法２８００において、またはこれを用いて実施することができる。さらに、図３のエンコーダ３００および／または図４のデコーダ４００を使用して、方法２８００を実施することができることに留意されたい。さらに、方法２８００は、ピクチャについての参照ピクチャ・リストの構築を記述したものであるが、実施形態４に関連して上述したように、このような参照リストは、ピクチャのシーケンスについて、複数のビューにまたがる１組のピクチャのセットについて、またはピクチャのサブセットについて構築することもできる。

方法２８００は、エンコーダ３００またはデコーダ４００がピクチャの依存関係情報に基づいてピクチャのレイヤ間参照を決定することができる任意選択ステップ２８０２から開始することができる。例えば、デコーダ４００は、上述のように、シーケンス・パラメータ・セット（ＳＰＳ）を伝達する受信したシンタックス要素から依存関係情報を抽出して復号することができる。エンコーダ３００の場合は、依存関係情報は、例えば実施形態５〜８に関連して上述したようにエンコーダ３００がＳＰＳに含めた依存関係情報と同じとすることができる。例えば、エンコーダ３００は、エンコーダに記憶される構成ファイルから依存関係情報を取得することができる。依存関係情報は、異なるピクチャおよびピクチャ・タイプがどのように予測符号化されるかを示す時間的依存関係、ビュー間依存関係、およびレイヤ間依存関係の何れか１つまたは複数を含むことができることを理解されたい。従って、この依存関係情報に基づいて、エンコーダ３００またはデコーダ４００は、参照ピクチャ・リストを構築しているピクチャのレイヤ間参照を決定することができる。さらに、レイヤ間参照は、実施形態４に関連して上述したレイヤ間参照に準拠していてもよい。例えば、レイヤ間参照は、図１５に関連して上述した構造の何れか１つまたは複数に対応することができる。

ステップ２８０４で、エンコーダ３００またはデコーダ４００は、ピクチャの１つまたは複数のその他の参照に対するレイヤ間参照の優先順位を決定することができる。例えば、エンコーダ３００またはデコーダ４００は、参照ピクチャ・リスト中のピクチャに優先順位をつける優先順位方式を適用するように構成することができる。例えば、実施形態４に関連して上述したように、参照リスト中のピクチャは、その参照ピクチャ・リストが構築されたピクチャと、当該参照ピクチャ・リスト中に列挙されたピクチャとの間の冗長性の程度に従って、順序付け／優先順位付けすることができる。例えば、奥行きピクチャに関連して上述したように、レイヤ間参照は、参照リスト中の時間的参照およびビュー間参照と比較して最小の冗長性を有するものと予想される。したがって、レイヤ間参照は時間的参照およびビュー間参照よりも低い優先順位を有する。
なお、実施形態４の様々な３ＤＶレイヤ・タイプに関連して上記に与えた任意の優先順位を、ここではステップ２８０４で適用することができることに留意されたい。ただし、異なる優先順位も、本明細書に記載する様々な特徴に従って利用することができることも理解されたい。例えば、優先順位は、３ＤＶコンテンツのピクチャ参照と参照ピクチャ・リストに関連するピクチャとの間の実際の冗長性に従って変化してもよい。例えば、冗長性は、３ＤＶコンテンツを構成するピクチャまたはレイヤの測定値に基づいて決定することができ、優先順位方式は、参照リスト関連するピクチャとの冗長性の高い参照ピクチャに冗長性の低い参照ピクチャよりも高い優先順位が与えられるように、測定した冗長性レベルを反映するように調整することができる。さらに、このような優先順位方式は、その他の特徴または実施形態では、各ピクチャまたは参照ピクチャ・リストごとに異なるものを工夫することもできる。

ステップ２８０６で、エンコーダ３００またはデコーダ４００は、優先順位に基づいて、ピクチャの参照の順序付けされたリストにレイヤ間参照を含めることができる。例えば、より低い、または最低の優先順位を有するレイヤ間参照ピクチャは、より高い優先順位を有するその他の参照ピクチャの後に、またはリストの末尾に、含めることができる。また、より高い、または最高の優先順位を有するレイヤ間参照ピクチャは、より低い優先順位を有する、またはリストの先頭の他の参照ピクチャの前に含めることができる。
このような参照としては、上述のように、時間的参照および／またはビュー間参照などが挙げられる。上記に示したように、レイヤ間参照は、エンコーダの実施態様の方法１６００またはデコーダの実施態様の方法１７００に従って、参照のリストに含めることができる。さらに、レイヤ間参照は、ステップ２８０４に関連して上述したように、その他の優先順位方式に従って参照のリストに含めることもできる。なお、共通性の高い参照により小さな指標を使用することができ、伝送においてビットを節約することができるように、予想される用途に基づいて、リストを順序付けおよび優先順位付けすることができることに留意されたい。

任意選択のステップ２８０８で、エンコーダ３００またはデコーダ４００は、ピクチャを含む符号化動作にレイヤ間参照を使用することができる。例えば、エンコーダ３００は、予測符号化動作を実行して、レイヤ間参照を参照ピクチャとして使用して参照リストを構築したピクチャを符号化することができる。デコーダ４００は、予測復号動作を実行して、レイヤ間参照を参照ピクチャとして使用して参照リストを構築したピクチャを復号することができる。従って、ピクチャの符号化または復号は、少なくとも部分的には、レイヤ間参照に基づくことができる。

必要に応じて、ステップ２８１０で、エンコーダ３００またはデコーダ４００は、符号化済みピクチャを含むビットストリームを生成することができる。例えば、エンコーダ３００は、図３および図５に関連して上記に与えた説明に従って、ビットストリーム３１８に符号化済みピクチャを含めることができる。さらに、デコーダ４００は、図４および図６に関連して上記に与えた説明に従って、ビットストリーム４１６に復号済みピクチャを含めることができる。

その後、この方法は、終了することもできるし、あるいはエンコーダ３００またはデコーダ４００が別のピクチャの参照ピクチャ・リストを生成することができるように、またはピクチャがＢピクチャである場合には同じピクチャの第２の参照ピクチャ・リストを生成することができるように、反復することができる。

一実施態様では、ステップ２８０４および２８０６のみを実行する。例えば、レイヤ間参照を提供することができ、この実施態様では、このレイヤ間参照の優先順位を決定する。次いで、この実施態様は、決定した優先順位に基づいて順序付けしたリストにこのレイヤ間参照を含める。

ステップ２８０２に戻ると、必要に応じて、ステップ２８０２は、図２９に示す２Ｄ映像レイヤ・ピクチャを処理する方法２９００の実行を含むことができる。例えば、方法２９００は、ステップ２９０２から開始することができ、このステップで、エンコーダ３００またはデコーダ４００は、参照ピクチャ・リストが構築されたピクチャが２Ｄ映像レイヤ・ピクチャであるかどうかを判定することができる。参照が２Ｄ映像レイヤ・ピクチャ出ない場合には、この方法は、方法２８００のステップ２８０４に進むことができる。そうでない場合には、この方法は、ステップ２９０４に進むことができ、このステップで、エンコーダ３００またはデコーダ４００は、参照ピクチャ・リストから任意のレイヤ間参照を除外することができる。例えば、実施形態４に関連して上述したように、２Ｄ映像レイヤのレイヤ間参照を用いないことにより、従来のＭＶＣで３ＤＶコンテンツを抽出し、このコンテンツを表示のためにフォーマット化できるようにすることができる。その後、この方法は、方法２８００のステップ２８０４に進むことができる。

ステップ２９０４は、奥行きレイヤのみを、２Ｄ映像レイヤの参照として使用されないようにするように修正することもできる。このような実施態様では、例えば、２Ｄ映像レイヤのレイヤ間参照として、隠蔽映像レイヤに依拠することができる。

様々な実施形態によれば、デコーダ４００のレイヤ・デコーダ４０２〜４１２やエンコーダ３００のレイヤ・エンコーダ３０４〜３１４など、１組のレイヤ・コーダのセットを、ステップ２８０８およびステップ２８１０を実行するように構成することができることを理解されたい。さらに、３Ｄ参照バッファ４１４、３ＤＶ参照バッファ３１６および／またはレイヤ・コーダは、ステップ２８０２〜２８０６および２８１０の何れか１つまたは複数を実行するように構成することができる。あるいは、またはこれに加えて、エンコーダ３００またはデコーダ４００は、少なくとも方法２８００を実行するように構成されたプロセッサを含むこともできる。さらに、実施形態は、プロセッサに少なくとも方法２８００を実行させる命令を記憶したプロセッサ可読媒体を含むこともできる。

次に、図３０および図３１を参照すると、３ＤＶレイヤ間依存関係構造が伝達されるように３ＤＶコンテンツを符号化する方法３０００および復号する方法３１００が示してある。様々な実施形態に関連して本明細書で述べる何れか１つまたは複数の特徴およびそれらの組合せは、方法３０００および３１００において、またはこれらを用いて実施することができることを理解されたい。例えば、以下でさらに述べるように、実施形態５〜７は、方法２６００および２７００において、またこれらの方法によって実施することができる。さらに、図３のエンコーダ３００および図４のデコーダ４００を使用して、方法３０００および３１００をそれぞれ実施することができることに留意されたい。

方法３０００は、エンコーダ３００が３ＤＶレイヤ間のレイヤ間依存関係構造を示すシンタックス要素を生成することができるステップ３００２から開始することができる。例えば、シンタックス要素は、実施形態５〜７の何れか１つまたは複数に関連して上述したように生成することができる。例えば、ＮＡＬユニット１７をシンタックス要素として利用して、実施形態５に関連して上述したように、相互依存関係構造を伝達することもできる。さらに、相互依存関係構造は、実施形態６および７に関連して、また表１３および１４に関連して上述したように伝達することもできる。例えば、方法２０００、２２００および２４００の何れか１つまたは複数を利用して、相互依存関係構造を伝達することができる。例えば、シンタックス要素は、実施形態６に関連して上述したように、レイヤ間依存関係構造を明示的に伝達することもできるし、あるいは、実施形態７に関連して上述したように、３ＤＶレイヤｉｄを用いて各３ＤＶビューごとに特定の３ＤＶレイヤが存在するかどうかを伝達することによって、既定のレイヤ間依存関係の構造を示すこともできる。さらに、レイヤ間依存関係構造は、多数の異なるレイヤ間依存関係構造のうちの１つに対応することができる。例えば、レイヤ間依存関係構造は、図１５に関連して上述した構造および実施形態７に関連して上述した構造に対応することができる。さらに、上述のように、レイヤ間依存関係構造は、ＮＡＬユニット・ヘッダ、ＳＰＳ、ＰＰＳ、ＳＥＩまたはスライス・ヘッダの何れか１つまたは複数に設けることもできる。さらに、エンコーダ３００は、例えば実施形態４に関連して上述したように、参照ピクチャ・リストを構築してこれを利用することによって、シンタックス要素を生成することができる。

ステップ３００４で、エンコーダ３００は、レイヤ間依存関係構造に基づいて、それらの３Ｄレイヤのうちの１つのレイヤのピクチャのレイヤ間参照を識別することができる。例えば、レイヤ間依存関係構造が図１５に関連して上述した構造に対応する場合には、奥行きレイヤ・ピクチャを符号化するために、エンコーダ３００は、ステップ３００２で構築することができる参照ピクチャ・リストを利用して、奥行きレイヤ・ピクチャのレイヤ間参照が、奥行きレイヤ・ピクチャと同じビューまたは３ＤＶビュー中の２Ｄ映像レイヤ・ピクチャであると判定することができる。上述のように、相互依存関係構造は変化することができ、例えば異なる３ＤＶビュー間のレイヤ間依存関係など相互依存関係が変わるとともに、特に２Ｄ映像レイヤ、奥行きレイヤ、隠蔽映像レイヤ、隠蔽奥行きレイヤおよび透明度レイヤなど、多数の異なるタイプのレイヤを含むことができる。

ステップ３００６で、エンコーダ３００は、少なくとも部分的にはレイヤ間参照に基づいて、ピクチャを符号化することができる。例えば、エンコーダ３００は、エンコーダ３０４〜３１４を用いて、図３および図５に関連して上述したようにピクチャを符号化することができる。ここで、再度構造１５００および奥行きレイヤを一例として用いると、奥行きレイヤは、上述のように、少なくとも部分的には２Ｄ映像レイヤに基づいて符号化することができる。

任意選択のステップ３００８で、エンコーダ３００は、符号化済みピクチャを含むビットストリームを生成することができる。例えば、符号化済みビットストリームは、図３および図５に関連して上述したように生成することができ、例えばビットストリーム３１８に対応することができる。

任意選択のステップ３０１０で、エンコーダ３００は、符号化済みピクチャと、符号化済みピクチャの復号に使用されるシンタックス要素とを提供することができる。例えば、シンタックス要素および符号化済みピクチャは、ビットストリーム３１８を介してデコーダ４００に伝送することができる。あるいは、シンタックス要素は、３ＤＶデータ・コンテンツを伝送するために使用するビットストリームとは別のビットストリームで伝送することもできる。従って、図３のビットストリーム３１８は、２つの別個の対応するビットストリームを表すことができる。あるいは、異なるビットストリームを、別々に伝送することもできる。例えば、一方のビットストリームはケーブル・ネットワークを介してデコーダ４００に伝送し、他方のビットストリームは、無線でデコーダ４００に伝送することもできる。さらに、シンタックス要素は、方法３１００に関連して以下で述べるように、符号化済みピクチャを復号するために使用することもできる。

様々な実施形態で、エンコーダ３００のレイヤ・エンコーダ３０４〜３１４のセットは、ステップ３００６を実行するように構成することができることを理解されたい。さらに、３ＤＶ参照バッファ３１６および／またはレイヤ・エンコーダ３０４〜３１４は、ステップ３００２、３００４、３００８および３０１０の１つまたは複数を実行するように構成することができる。あるいは、またはこれに加えて、エンコーダ３００は、少なくとも方法３０００を実行するように構成されたプロセッサを含むこともできる。さらに、実施形態は、方法３０００に従って生成された符号化済みピクチャ、シンタックス要素および／またはビットストリームを含むようにフォーマット化された映像信号およびまたは映像信号構造を含むこともできる。さらに、実施形態は、映像信号構造を記憶したプロセッサ可読媒体を含むこともできる。さらに、上記に示したように、図７の変調器７２２は、映像信号を変調するように構成することができる。さらに、実施形態は、プロセッサに少なくとも方法３０００を実行させる命令を記憶したプロセッサ可読媒体を含むこともできる。

一実施態様では、ステップ３００２〜３００６のみを実行する。この実施態様では、シンタックス要素を生成して、ピクチャのレイヤ間参照を識別し、次いで、少なくとも部分的にはこの識別したレイヤ間参照に基づいて、ピクチャを符号化する。この場合には、この実施態様では、符号化済みピクチャを含むビットストリームを生成する、または復号に使用する符号化済みピクチャおよびシンタックスを提供する必要はない。

図３１の３ＤＶコンテンツを復号する方法３１００を再度参照すると、方法３１００は、ステップ３１０２から開始することができる。デコーダ４００は、ビットストリームに属する符号化済みピクチャにアクセスすることができ、このピクチャは、所与の時点の所与のビューに属する特定の３ＤＶレイヤについての３ＤＶ情報を記述したものである。例えば、符号化済みピクチャは、上述の何れか１つまたは複数の３ＤＶレイヤに対応することができる。例えば、２Ｄビュー１０１０および奥行きビュー１００８は、それぞれ別個のピクチャを構成することができる。さらに、図１１および／または図１２に関連して上述した任意の２Ｄビュー・レイヤ１１１８、１１２２、１１３６、１２１８、１２２２、１２３６および／または任意の奥行きビュー１１２０、１１２４、１２２０、１２２４も、それぞれ別個のピクチャを構成することができる。さらに、図１１および図１２に明示的には示していないが上述したその他の３ＤＶ補足レイヤも、それぞれ別個のピクチャを構成することができる。さらに、上述した３ＤＶビューの何れか１つまたは複数は、図１１および図１２に関連して上述した時点Ｔ０およびＴ１の３Ｄビュー０、１および２など、所与の時点の所与のビューを構成することができる。さらに、符号化済みピクチャは、方法３０００によって生成された符号化済みピクチャとすることもできる。

ステップ３１０４で、デコーダ４００は、特定の３ＤＶレイヤを含む１組の３ＤＶレイヤのセットのレイヤ間依存関係構造を示すシンタックス要素にアクセスすることができる。例えば、ＮＡＬユニット１７が、実施形態５に関連して上述したように、相互依存関係構造を示すシンタックス要素であってもよい。さらに、相互依存関係構造は、実施形態６および７ならびに表１３および表１４に関連して上述したように示す、または伝達することもできる。例えば、方法２０００、２２００および２４００の何れか１つまたは複数を利用して、相互依存関係構造を伝達する、または示すこともできる。

例えば、シンタックス要素は、実施形態６に関連して上述したように、レイヤ間依存関係構造を明示的に伝達することができる。あるいは、シンタックス要素は、実施形態７に関連して上述したように、３ＤＶレイヤｉｄを用いて各３ＤＶビューごとに特定の３ＤＶレイヤが存在するかどうかを伝達することによって、既定のレイヤ間依存関係の構造を示すこともできる。さらに、相互依存関係構造は、多数の異なる相互依存関係構造のうちの１つに対応することができる。例えば、相互依存関係構造は、図１５に関連して上述した構造および実施形態７に関連して上述した構造に対応することができる。さらに、上述のように、相互依存関係構造およびシンタックス要素は、ＮＡＬユニット・ヘッダ、ＳＰＳ、ＰＰＳ、ＳＥＩまたはスライス・ヘッダの何れか１つまたは複数から取得することもできる。さらに、デコーダは、例えば方法２１００、２３００および２５００の何れか１つまたは複数に関連して上述したようにシンタックス要素にアクセスすることもできる。

ステップ３１０６で、デコーダ４００は、少なくとも部分的にはレイヤ間依存関係構造に基づいて、符号化済みピクチャを復号することができる。例えば、デコーダ４００は、図４および図６に関連して上述したように、符号化済みピクチャを復号することができる。さらに、デコーダ４００は、例えば実施形態４に関連して上述したようにシンタックス要素を用いて１つまたは複数の参照ピクチャ・リストを構築し、これを利用して、符号化済みピクチャを復号することもできる。従って、デコーダ４００は、予測符号化のために符号化済みピクチャの参照を決定することができ、少なくとも部分的にはその参照に基づいて、ピクチャを復号することができる。

任意選択のステップ３１０８で、デコーダ４００は、レイヤ間依存関係構造を示す出力フォーマットで、復号されたピクチャを提供することができる。例えば、デコーダ４００の３ＤＶ参照／出力バッファ４１４は、レイヤ間依存関係構造に従ってフォーマット化された３ＤＶコンテンツを出力することができる。従って、この出力は、この構造による複数のピクチャ間の関係をディスプレイ・デバイスに対して示して、３ＤＶコンテンツをディスプレイ・デバイスに適切に表示することができるようにし、３ＤＶコンテンツをユーザが見ることができるようにすることができる。具体的には、出力フォーマットは、復号済みピクチャがどのように構造に適応するかを指定するシンタックス要素を含むことができる。このようなシンタックス要素の例としては、上述したように、ＮＡＬユニット１７を挙げることができる。

様々な実施形態で、デコーダ４００のレイヤ・デコーダ４０２〜４１２のセットは、ステップ３１０６を実行するように構成することができることを理解されたい。さらに、３ＤＶ参照バッファ４１４および／またはレイヤ・デコーダ４０２〜４１２は、ステップ３１０２、３１０４および３１０８の１つまたは複数を実行するように構成することができる。あるいは、またはこれに加えて、デコーダ４００は、少なくとも方法３１００を実行するように構成されたプロセッサを含むこともできる。さらに、上記に示したように、図８の復調器８２２は、ステップ３１０２でアクセスした複数の符号化ピクチャが属するビットストリームを含む映像信号を復調するように構成することができる。さらに、さらに、実施形態は、プロセッサに少なくとも方法３１００を実行させる命令を記憶したプロセッサ可読媒体を含むこともできる。

当業者なら、本明細書に与えた教示に鑑みて、上記の実施形態を様々な形態で結合することができることを理解されたい。例えば、図３２を参照すると、上述したいくつかの実施形態のフィーチャを組み込んだＮＡＬユニット・ストリーム３２００が示してある。ここで、ストリーム３２００は、上記の表３に示し、ＡＶＣドラフトに定義されるように、ＭＶＣ用のサブセット・シーケンス・パラメータ・セットのＮＡＬユニット１５（３２０２）を含むことができる。さらに、ストリーム３２００は、実施形態５〜７に関連して上述したように、少なくとも１つのレイヤ間依存関係構造を示す３ＤＶの拡張ＳＰＳのＮＡＬユニット１７も含むことができる。ここで、分かりやすいように、図１０に示すレイヤ間依存関係構造を、ストリーム３２００では利用している。

図１１および図１２と同様に、図３２は、時点Ｔ０および時点Ｔ１に対応する３ＤＶビューのセットを示している。上述した図１１および図１２の省略は、図３２にも適用され、図３２の矢印は、図１１および図１２の矢印と同様に、ＮＡＬユニットの伝送順序を示している。もちろん、図３２は、ストリーム３２００のごく一部である。ストリーム３２００は、実際の適用分野では、多数の異なる瞬間に対して、さらに多くのＮＡＬユニットを含むことになる。さらに、ＭＶＣに精通した当業者なら理解できるように、３つの３ＤＶビューを使用しているのも一例に過ぎず、さらに多くのビューを利用し、且つ／またはデコーダにおいて描画することができる。さらに、各ビューごとに２つの３ＤＶレイヤを使用しているのも一例に過ぎず、上記で詳細に述べたように、いくつかの追加の３ＤＶレイヤを利用することもできることを理解されたい。

このストリーム３２００の部分では、３つの３ＤＶビュー３２０６、３２０８および３２１０は、時点Ｔ０に対応し、３つの３ＤＶビュー３２１２、３２１４および３２１６は、時点Ｔ１に対応する。図１１および図１２と同様に、３ＤＶビュー０（３２０６、３２１２）は、図１０のベース・ビュー１００２に対応することができ、３ＤＶビュー２（３２０８、３２１４）および３ＤＶビュー１（３２１０、３２１６）は、それぞれ図１０のＰビュー１００６およびＢビュー１００４に対応することができる。３ＤＶビュー３２０６は、２Ｄ映像レイヤ３２１８を構成するＮＡＬユニット１６（３２２０）、１４（３２２２）および５（３２２４）を含むことができる。上述のように、ＮＡＬユニット５は、瞬時復号更新（ＩＤＲ）ピクチャの符号化済みスライスの映像データを含み、ＡＶＣドラフトに規定されるようにイントラ・スライスまたはＳＩスライスのみで構成される。さらに、ＮＡＬユニット１４は、ＭＶＣに従って、ＭＶＣプレフィックスとして、その他のビューのベース・レイヤとして２Ｄ映像レイヤ３２１８を示す参照を含むことができる。ステレオ・プロフィルを使用する別の実施態様では、ＮＡＬユニット１４および１７を省略することができる。

ＮＡＬユニット１６は、例えば、実施形態１に関連して上述したように、３ＤＶビューＩＤおよび３ＤＶレイヤＩＤを含むことができる。ここで、３ＤＶビューＩＤおよび３ＤＶレイヤＩＤは、例えば、奥行きレイヤまたはその他の３ＤＶレイヤのレイヤ間参照として２Ｄ映像レイヤ３２１８を識別するためにデコーダ４００が使用することができる。図３２に示すように、３ＤＶビュー３２０６は、実施形態３に関連して上述したように、ＮＡＬユニット２１（３２２８）で構成される奥行きレイヤ３２２６をさらに含むことができる。実施形態３に関連して上述したように、ＮＡＬユニット２１は、ＭＶＣ ＮＡＬユニット・ヘッダ拡張に設けられたその他の情報に加えて、３ＤＶビューＩＤおよび３ＤＶレイヤＩＤを含むことができる。

実施形態４〜７に関連して上述したように、デコーダ４００は、ＮＡＬユニット１７によって与えられるレイヤ間依存関係構造など、ＳＰＳにも受けられた情報を用いて参照ピクチャ・リストを再構築し、この参照ピクチャ・リストを使用して適切に３ＤＶコンテンツを復号することができる。例えば、３ＤＶビューＩＤおよび３ＤＶレイヤＩＤに基づいて、デコーダ４００は、ＳＰＳに含めて伝達されるレイヤ間依存関係構造中の対応するレイヤ（この場合には奥行きレイヤ３２２６）の役割を決定することができる。ここで、３ＤＶビューＩＤおよび３ＤＶレイヤＩＤは、奥行きレイヤ３２２６の復号に２Ｄ映像レイヤ３２１８を参照として使用すべきであることを示すことができる。

図３２に示すように、時点Ｔ０のその他の各３ＤＶビューは、３ＤＶビュー中の２Ｄ映像レイヤに対応するＮＡＬユニット２０および奥行きレイヤに対応するＮＡＬユニット２１で構成される。ビュー３２０８および３２１０内のＮＡＬユニットは、図１２に関連して上述したように、ビュー１２０６および１２０８中のＮＡＬユニットと同じ機能を有することができる。同様に、時点Ｔ１の３ＤＶビューのセットは、３ＤＶビュー３２０６中のＮＡＬユニット５が３ＤＶビュー３２１２中のＮＡＬユニット１ ３２３０で置き換えられることを除けば、基本的に時点Ｔ０の３ＤＶビューのセットと同様に構築される。実施形態３に関連して上述したように、ＮＡＬユニット１は、非ＩＤＲピクチャの符号化済みスライスの映像データを含む。

次に、図３３を参照すると、レイヤ間依存関係構造を利用することによってネットワーク・トラフィックを管理するシステム３３００が示してある。システム３３００は、図７および図８に関連して上述した伝送システム／装置７００および受信システム／装置８００を含むことができる。具体的には、伝送システム／装置７００のエンコーダ７１０は、本明細書に記載の様々な実施態様に関連して上述したエンコーダ３００によって実施することができる。同様に、受信システム／装置８００のデコーダ８２０は、本明細書に記載の様々な実施態様に関連して上述したデコーダ４００によって実施することができる。システム３３００の入力および出力は、図３３では、「入力映像（１つまたは複数）」および「出力映像」として示してある。少なくともこの実施態様では、これらが複数のレイヤを含む３Ｄ映像を指していることは、明らかであろう。

システム３３００は、伝送システム／装置７００と受信システム／装置８００の間のネットワーク３３５０中に設けられたネットワーク・デバイス／システム３３０１をさらに含むことができる。ネットワーク３３５０は、例えば、インターネット、広域ネットワークやローカル・エリア・ネットワーク（ＬＡＮ）などの有線ネットワーク、または無線携帯電話網や無線ＬＡＮなどの無線ネットワークとすることができる。ネットワーク・デバイス３３０１は、有線ネットワーク中のルータとして実施することもできるし、無線ネットワーク中の基地局として実施することもできる。図３３に示すように、ネットワーク・デバイス３３０１は、解析器３３０２、制御装置３３０４、ネットワーク・トラフィック・モニタ３３０６、および転送モジュール３３０８を含むことができる。さらに、ネットワーク・デバイス３３０１の各要素は、ハードウェア要素として実施することもできるし、ソフトウェアとハードウェアの組合せとして実施することもできる。ネットワーク・デバイス３３０１およびその要素の機能については、ネットワーク・デバイス３３０１が実施することができる図３４に示す方法３４００に関連して、以下でさらに詳細に述べる。

図３４および引き続き図３３を参照して、ネットワーク資源を管理する方法３４００について述べる。方法３４００は、ステップ３４０２から開始することができ、このステップで、解析器３３０２は、３ＤＶレイヤのレイヤ間依存関係構造を示す受信したシンタックス要素を構文解析して、この構造に基づいて３ＤＶレイヤの少なくともサブセットの転送優先順位を決定することができる。例えば、シンタックス要素は、伝送システム／装置７００から、例えば実施形態５〜７に関連して上述したように表１３または１４に従って相互依存関係構造を示すことができるＮＡＬユニット１７に含まれた状態で受信することができる。

ここで、解析器３３０２は、相互依存関係構造に示される３ＤＶレイヤの重要性に従って転送優先順位を決定することができる。例えば、３ＤＶレイヤｉｄは、最小の数が最高の優先順位に対応し、最大の数が最低の優先順位に対応するように構成することができる。図１５の相互依存関係構造および表１の３ＤＶレイヤ識別子を利用意する場合には、解析器３３０２は、３ＤＶレイヤ識別子に基づいて、２Ｄ映像レイヤの優先順位が最も高く、奥行きレイヤの優先順位がその次に高い、といったことなどを決定することができる。具体的には、３ＤＶレイヤ識別子は、３ＤＶコンテンツの形成に関する寄与の重要性に従って順位付けすることができる。例えば、図２を参照すると、２Ｄ映像の奥行きレイヤ２０４は、ビュー中の主要オブジェクトに３次元効果を与えるが、隠蔽映像レイヤ２０６または隠蔽奥行きレイヤ２０８は３次元効果を与えないので、隠蔽映像レイヤ２０６または隠蔽奥行きレイヤ２０８より重要性が高いと考えることができる。異なる３ＤＶレイヤ間の重要性の決定については、様々な変形形態を適用することができる。

例えば、１つの変形形態は、レイヤの優先順位を、レイヤ間依存関係構造中にレイヤが有している参照の数、または特定のレイヤを含む参照ピクチャ・リストの数に従って決めるものである。例えば、レイヤ間依存関係構造および／またはそれに対応するレイヤ間参照が決定されたのに応答して、解析器３３０２は、最も多数のレイヤから参照されたレイヤに最高の優先順位を割り当て、参照された数が最も少ないレイヤに最低の優先順位を割り当てることができる。例えば、図１５のレイヤ間依存関係構造では、２Ｄ映像レイヤが、３つのレイヤから参照されるので最高の優先順位を有することになり、１つのレイヤから参照される奥行きレイヤが、その次に高い優先順位を有することになる、などである。

その他の変形形態は、適切にレイヤを符号化／復号するために、利用する参照の数に従って３ＤＶレイヤを順序付けすることに関することがある。例えば、実施形態７に関連して上述した相互依存関係構造では、隠蔽映像レイヤ、隠蔽奥行きレイヤ、および透明度レイヤは、それぞれ２つの（レイヤ間）参照を利用するので、最低の優先順位を与えることができ、奥行きレイヤは、１つの（レイヤ間）参照を利用するので、その次に高い優先順位を与えることができ、２Ｄ映像レイヤは、いかなる（レイヤ間）参照も利用しないので、最高の優先順位を与えることができる。

さらに、様々な組合せを適用して、優先順位を決定することもできる。例えば、３Ｄビューを描画する際の所与のレイヤの重要性および当該所与のレイヤを参照するレイヤの数の両方を考慮した重み関数を使用して、転送優先順位を決定することができる。さらに、レイヤ間参照に加えて、その他のタイプの参照も考慮することができることを理解されたい。例えば、上述の優先順位の決定では、さらに、特定のレイヤが依存する時間的参照およびビュー間参照も考慮することができる。従って、上述の道理は、時間的参照およびビュー間参照ならびに／あるいはレイヤ間参照など、任意のタイプの参照および／または参照の組合せに適用することができる。

ステップ３４０４で、解析器３３０２は、３ＤＶレイヤを構築するためのデータ・ユニットを受信することができる。例えば、図１１を再度参照すると、解析器３３０２は、２Ｄ映像レイヤ１１１８を構築するために利用されるＮＡＬユニット１６、１４および５を受信することができる。解析器３３０２は、さらに、奥行きレイヤ１１２０を構築するために使用されるＮＡＬユニット１６および２０なども受信することができる。

ステップ３４０６で、ネットワーク・トラフィック・モニタ３３０６は、ネットワーク３３５０上のトラフィック／ネットワーク輻輳を測定することができる。当業者なら理解するであろうが、ここでは、様々な既知のネットワーク・トラフィック・モニタを利用することができる。

ステップ３４０８で、制御装置３３０４は、ネットワーク・トラフィック・モニタ３３０６から受信した輻輳測定値に基づいて、ステップ３４０６で測定したネットワーク・トラフィックが第１の輻輳しきい値を満たすかどうかを判定することができる。ここでは、必要に応じて、複数の異なる輻輳しきい値を利用して、上述のようにレイヤ間依存関係構造に基づくことができる決定した転送優先順位に従って３ＤＶレイヤと関連付けることができることを理解されたい。例えば、３ＤＶコンテンツを描画するために利用される各３ＤＶレイヤごと、または削除可能な各３ＤＶレイヤごとに、１つの輻輳しきい値を使用することもできる。例えば、表１を再度参照して、ステップ３４０２に関連して上述したように３ＤＶレイヤＩＤ番号に従って転送優先順位を決定した場合には、例えば、第１のしきい値を、透明度レイヤと関連付け、第１のしきい値より高いレベルのネットワーク輻輳に対応する第２のしきい値を、隠蔽奥行きレイヤと関連付け、第１および第２のしきい値より高いレベルのネットワーク輻輳に対応する第３のしきい値を、隠蔽映像レイヤと関連付けることができる。

従って、第１の輻輳しきい値が満たされた場合には、ステップ３４１２で、制御装置３３０４は、優先順位が最低である３ＤＶレイヤについてステップ３４０４で受信したユニットまたはＮＡＬユニットを削除することができ、転送モジュール３３０８に、（次のしきい値が満たされていない場合には）残りの３ＤＶレイヤのユニットを受信システム／装置８００に転送するように指示することができる。第１の輻輳しきい値が満たされていない場合には、転送モジュール３３０８は、ステップ３４１０で、制御装置３３０４の指示の下で、全ての３ＤＶレイヤのユニットを転送することができる。Ｎ個の３ＤＶレイヤのそれぞれについて、しきい値の決定を繰り返すことができることを理解されたい。例えば、Ｎ個のレイヤは、３ＤＶコンテンツを描画するために１つまたは複数のビュー内で利用されるレイヤの数に対応することができる。従って、しきい値の決定は、各しきい値ごとに繰り返すことができ、その結果に応じて、ユニットの削除および転送の判断を行うことができる。

例えば、ステップ３４１２の後、第２のしきい値が満たされない場合には、ステップ３４１２で、転送モジュール３３０８が、Ｎ−１個の３ＤＶレイヤのユニットを受信ユニット８００に転送することができる。あるいは、ステップ３４１２の後、制御装置３３０４が、最初のＮ−２個のしきい値が満たされたと判定した場合には、この方法は、ステップ３４１４に進むことができ、このステップで、制御装置３３０４は、（Ｎ−１）番目の輻輳しきい値が満たされているかどうかを判定することができる。（Ｎ−１）番目の輻輳しきい値が満たされていない場合には、ステップ３４１６で、転送モジュール３３０８は、制御装置３３０４の指示の下で、優先順位が最高と２番目の３ＤＶレイヤのユニットを転送することができる。さらに、ステップ３４１６で、制御装置３３０４は、Ｎ−２個の優先順位が最低の３ＤＶレイヤを、それらＮ−２個の最低の優先順位の３ＤＶレイヤのしきい値が満たされているという理由で、削除することができる。（Ｎ−１）番目の輻輳しきい値が満たされている場合には、ステップ３４１８で、転送モジュール３３０８は、制御装置３３０４の指示の下で、優先順位が最高である３ＤＶレイヤのユニットを転送することができる。さらに、制御装置３３０４は、（Ｎ−１）個の優先順位が最低である３ＤＶレイヤのユニットを削除することができる。従って、方法３４００は、Ｍ番目のしきい値が満たされ、（Ｍ＋１）番目のしきい値が満たされないときに、例えばＭ個の優先順位が最低の３ＤＶレイヤの例えばＮＡＬユニットなどのユニットが削除され、残りの優先順位の高いレイヤが転送されるように、しきい値の決定を進めることができる。なお、この例では、受信装置／システム８００が少なくとも一部のコンテンツを確実に復号することができるように、少なくとも優先順位が最高であるレイヤは削除されないことを保証するために、Ｎ−１個のしきい値しか考慮していないことに留意されたい。ただし、方法３４００の変形形態を利用することもできる。また、ネットワーク輻輳の任意の変化に対応するために、方法３４００の１つまたは複数のステップを定期的に繰り返すことができることにも留意されたい。

方法３４００以外の実施態様も可能であることは明らかであろう。このような実施態様の１つは、さらに一般的であり、３次元映像（３ＤＶ）レイヤ間のレイヤ間依存関係構造を示すシンタックス要素にアクセスすることを含む。このアクセスは、例えば、ステップ３４０２に示すように受信したシンタックス要素を構文解析することによって実行することができる。

また、この実施態様では、この構造に基づいて、これらの３ＤＶレイヤのうちの特定の３ＤＶレイヤの伝送優先順位を決定する。伝送優先順位は、例えば、ストリーム中のピクチャ（またはピクチャの一部）の転送あるいはストリームからのピクチャ（またはピクチャの一部）の削除に関する優先順位とすることができる。伝送優先順位は、例えば、その特定の３ＤＶレイヤをどれだけの数のレイヤが参照（レイヤ間参照、ビュー間参照および／または時間的参照）として使用しているかを判定することによって、決定することができる。

また、この実施態様では、この特定の３ＤＶレイヤに属する符号化済みデータを伝送するかどうかを判定する。伝送するかどうかの判定は、この特定の３ＤＶレイヤの決定した伝送優先順位、およびネットワーク輻輳を示す指標に基づいて行う。ネットワーク輻輳は、例えば、ステップ３４０６のように決定することができる。ネットワーク輻輳を示す指標としては、例えば、ステップ３４０８および３４１４のように、１つまたは複数の輻輳しきい値が満たされているかどうかを示すフラグ（またはフラグのセット）とすることができる。その他の指標としては、例えば、ネットワーク・アクティビティの測度（スループット率、エラー率、再伝送要求の数または率、確認の数または率など）などが上げられる。

さらに別の実施態様では、このような伝送優先順位にアクセスして、この特定の３ＤＶレイヤのアクセスした伝送優先順位、およびネットワーク輻輳を示す指標に基づいて、この特定の３ＤＶレイヤに属する符号化済みデータを伝送するかどうかを判定する。ただし、この実施態様では、これらの３ＤＶレイヤの間のレイヤ間依存関係構造を示すシンタックスにアクセスする必要はない。また、この実施態様では、レイヤ間依存関係構造に基づいて伝送優先順位を決定する必要もない。

また、伝送優先順位が、完全にまたは部分的に、その他の情報に基づくこともあることは、明らかであろう。このような情報としては、例えば、ＡＶＣ、ＭＶＣまたはＳＶＣシステムに関連する時間的レベルＩＤ、優先順位ＩＤまたはビューＩＤなどが挙げられる。

従って、発明者等は、特定のフィーチャおよび特徴を有する１つまたは複数の実施態様を提供する。ただし、記載した実施態様のフィーチャおよび特徴は、その他の実施態様に適合させることもできる。

本願に記載した実施態様およびフィーチャのいくつかは、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣ（ＡＶＣ）規格、ＭＶＣ拡張を有するＡＶＣ規格、またはＳＶＣ拡張を有するＡＶＣ規格の状況で使用することができる。さらに、いくつかの実施態様は、（ａ）ＭＰＥＧおよびＩＴＵ−ＴのＪｏｉｎｔ Ｃｏｌｌａｂｏｒａｔｉｖｅ Ｔｅａｍ ｆｏｒ Ｖｉｄｅｏ Ｃｏｄｉｎｇ （ＪＣＴ−ＶＣ）、（ｂ）ＭＰＥＧのＨｉｇｈ−ｐｅｒｆｏｒｍａｎｃｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ ｇｒｏｕｐ、（ｃ）ＩＴＵ−ＴのＶｉｄｅｏ Ｃｏｄｉｎｇ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＶＣＥＧ）のＮｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｖｉｄｅｏ Ｃｏｄｉｎｇ ｇｒｏｕｐ、（ｄ）ＭＰＥＧの３Ｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ ｇｒｏｕｐ、（ｅ）ＭＰＥＧまたはＩＴＵ−Ｔの１つまたは複数と関連するその他の任意のグループ、あるいは（ｆ）任意の企業によって開発された任意の規格（独占または公開）からの符号化規格または符号化提案の状況で使用することもできる。ただし、これらの実施態様およびフィーチャは、別の（既存のまたは将来の）規格の状況でも、あるいは規格を伴わない状況でも使用することができる。

さらに、いくつかの実施態様では、例えばＳＥＩメッセージ、スライス・ヘッダ、その他の高レベル・シンタックス、非高レベル・シンタックス、帯域外情報、データストリーム・データ、および暗示的信号通信など（ただしこれらに限定されない）、様々な技術を用いて、情報を信号通信することができる。従って、本明細書に記載の実施態様が特定の文脈で記述されていることがあっても、このような記述は、どのような意味においても、フィーチャおよび概念をこれらの実施態様または文脈に限定するものとして解釈するべきではない。

さらに、多くの実施態様は、エンコーダ、デコーダ、デコーダの出力を処理するポストプロセッサ、またはエンコーダへの入力を提供するプリプロセッサの１つまたは複数において実施することができる。さらに、他の実施態様も、本開示によって企図されている。

本明細書における「一実施形態」もしくは「実施形態」、または「一実施態様」もしくは「実施態様」、あるいはそれらの表現の変形表現は、当該実施形態に関連して述べられている特定のフィーチャ、構造、特性などが、少なくとも１つの実施形態に含まれる、ということを意味している。従って、本明細書を通じて様々な箇所に見られる「一実施形態において」もしくは「実施形態において」、または「一実施態様において」もしくは「実施態様において」、あるいはその他の任意の変形表現は、必ずしも同じ実施形態を指しているわけではない。

例えば「Ａ／Ｂ」、「Ａおよび／またはＢ」ならびに「ＡおよびＢの少なくとも１つ」など、「／」、「および／または」ならびに「少なくとも１つ」の何れかを用いている場合、それは、１つ目に挙げた選択肢（Ａ）のみを選択する場合、２つ目に挙げた選択肢（Ｂ）のみを選択する場合、または両方（ＡおよびＢ）の選択肢を選択する場合を包含することを意図したものであることを理解されたい。他にも例えば、「Ａ、Ｂおよび／またはＣ」、「Ａ、ＢおよびＣの少なくとも１つ」、ならびに「Ａ、ＢまたはＣの少なくとも１つ」の場合も、これらの言い回しは、１つ目に挙げた選択肢（Ａ）のみを選択する場合、２つ目に挙げた選択肢（Ｂ）のみを選択する場合、３つ目に挙げた選択肢（Ｃ）のみを選択する場合、１つ目と２つ目に挙げた選択肢（ＡおよびＢ）のみを選択する場合、１つ目と３つ目に挙げた選択肢（ＡおよびＣ）のみを選択する場合、２つ目と３つ目に挙げた選択肢（ＢおよびＣ）のみを選択する場合、または３つ全ての選択肢（ＡおよびＢおよびＣ）を選択する場合を包含することを意図したものである。当技術分野および関連分野の当業者には容易に分かるであろうが、このことは、列挙される項目の数がいくつであっても、拡張して当てはめることができる。

また、本明細書で使用する「ピクチャ」および「画像」という用語は、入れ替え可能であり、例えば、静止画像の全体または一部（一部分）あるいは映像シーケンスに属するピクチャの全体または一部（一部分）を指している。さらに一般的には、ピクチャは、例えば、画像または映像データの任意のセットを指している。ピクチャは、例えば、ピクセル、マクロブロック、スライス、フレーム、フィールド、フル・ピクチャ、ピクチャ中のオブジェクトと接する領域、ピクチャの前景、ピクチャの背景、またはピクチャ中の特定の座標（ｘ，ｙ）とすることができる。同様に、ピクチャの「一部分」は、例えば、ピクセル、マクロブロック、スライス、フレーム、フィールド、ピクチャ中のオブジェクトと接する領域、ピクチャの前景、ピクチャの背景、またはピクチャ中の特定の座標（ｘ，ｙ）とすることができる。別の例として、奥行きピクチャ（奥行き画像）は、例えば、完全な奥行きマップ、または例えば対応する映像フレームの１つのマクロブロックについての奥行き情報しか含まない部分的な奥行きマップとすることができる。

さらに、当業者なら、レイヤ（あるいは「映像」または「画像」または「ピクチャ」）が、様々な映像構成要素の何れか、またはそれらの組合せを指すことができることを理解するであろう。こうした構成要素またはそれらの組合せとしては、例えば、輝度、クロミナンス、Ｙ（ＹＵＶまたはＹＣｂＣｒまたはＹＰｂＰｒまたはＹＰｃＰｒのＹ）、Ｕ（ＹＵＶのＵ）、Ｖ（ＹＵＶのＶ）、Ｃｂ（ＹＣｂＣｒのＣｂ）、Ｃｒ（ＹＣｂＣｒのＣｒ）、Ｐｂ（ＹＰｂＰｒのＰｂ）、Ｐｒ（ＹＰｂＰｒまたはＹＰｃｐｒのＰｒ）、Ｐｃ（ＹＰｃｐｒのＰｃ）、赤（ＲＧＢの赤）、緑（ＲＧＢの緑）、青（ＲＧＢの青）、Ｓ−Ｖｉｄｅｏ、およびこれらの構成要素の何れかのネガティブまたはポジティブなどが挙げられる。さらに、これらの様々なタイプの構成要素を、上述した実施態様とともに使用することができる。例えば、ＹＵＶの構成要素のセットを、上述の１つまたは複数の実施態様とともに使用することができ、通常の実施態様では、ＹＵＶは、マクロブロック・レベルで結合される。さらに、その他のピクチャ・タイプを、本明細書に記載した実施態様およびフィーチャとともに使用することができる。このようなその他のピクチャ・タイプとしては、例えば、２Ｄ映像、奥行き、隠蔽または背景、透明度またはエッジ不連続性以外の情報を含むピクチャなどが挙げられる。

さらに、本願またはその特許請求の範囲では、様々な情報を「決定する」ことに言及することがある。情報を決定すると言う場合には、例えば、情報を推定する、情報を計算する、情報を予測する、リストまたはその他のデータ・セットから情報を特定する、あるいはメモリから情報を取り出す、などのうちの１つまたは複数を含むことができる。

同様に、「アクセスする」も、意味の広い言葉として用いている。情報にアクセスすると言う場合には、例えば、情報を使用する、記憶する、送信する、伝送する、受信する、取り出す、修正する、構文解析する、または提供するなどの任意の動作を含むことができる。

多くの実施態様で、「参照」に言及している。「参照」は、例えば、参照からのピクセル・ベースの差を使用してソースを予測する、従来の参照とすることができる。あるいは、参照は、異なる方法で使用してソースを予測することもできる。例えば、一実施態様では、エッジ位置またはエッジの不連続性の測度を、ソースの予測に使用する。一般に、参照から任意の情報を流用して、ソースの予測に役立てることができる。ピクセル値、エッジ位置およびエッジ不連続性の測度など、情報の例を与えたが、その他のタイプの情報も可能である。

本明細書の記載した実施態様は、例えば、方法またはプロセス、装置、ソフトウェア・プログラム、データ・ストリーム、あるいは信号において実施することができる。１つの形態の実施態様の状況でしか述べていない場合でも（例えば方法としてしか述べていない場合でも）、記述しているフィーチャの実施態様は、その他の形態（例えば装置やプログラム）で実施することもできる。装置は、例えば適当なハードウェア、ソフトウェア、およびファームウェアにおいて実施することができる。方法は、例えば、コンピュータ、マイクロプロセッサ、集積回路またはプログラマブル論理デバイスなど処理デバイス一般を指す、プロセッサなどの装置において実施することができる。プロセッサとしては、例えばコンピュータ、携帯電話、携帯情報端末（ＰＤＡ）、およびその他のエンド・ユーザ間での情報通信を容易にするデバイスなどが挙げられる。

本明細書に記載した様々なプロセスおよびフィーチャの実施態様は、様々に異なる機器またはアプリケーションで実施することができ、具体的には例えば、データの符号化および復号に関連する機器またはアプリケーションで実施することができる。このような機器の例としては、エンコーダ、デコーダ、デコーダの出力を処理するポストプロセッサ、エンコーダへの入力を提供するプリプロセッサ、ビデオ・コーダ、ビデオ・デコーダ、ビデオ・コーデック、ウェブ・サーバ、セット・トップ・ボックス、ラップトップ、パーソナル・コンピュータ、携帯電話、ＰＤＡ、およびその他の通信デバイスが挙げられる。機器は、移動機器とすることも、移動可能な車両に設置することもできることは明らかであろう。

さらに、これらの方法は、プロセッサによって命令を実行することによって実施することができ、これらの命令（および／または実施態様により生成されるデータ値）は、例えば集積回路、ソフトウェア・キャリア、あるいは例えばハードディスク、コンパクト・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、または読取り専用メモリ（ＲＯＭ）などその他の記憶デバイスなどのプロセッサ可読媒体に記憶することができる。これらの命令は、プロセッサ可読媒体上に実装されるアプリケーション・プログラムを構成することができる。命令は、例えば、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せに含めることができる。命令は、例えば、オペレーティング・システム、別個のアプリケーション、またはその両者の組合せに見ることができる。従って、プロセッサは、例えば、プロセスを実行するように構成されたデバイスおよびプロセスを実行するための命令を有するプロセッサ可読媒体（記憶デバイスなど）を含むデバイスの両方の特徴を有することができる。さらに、プロセッサ可読媒体は、命令に加えて、または命令の代わりに、実施態様によって生成されるデータ値を記憶することもできる。

実施態様は、例えば記憶または伝送することができる情報を担持するようにフォーマット化された様々な信号を生成することができることは、当業者には明らかであろう。このような情報としては、例えば、方法を実行するための命令、または記載した実施態様の１つによって生成されるデータなどが挙げられる。例えば、信号は、記載した実施形態のシンタックスを書き込む、または読み取るための規則をデータとして担持するように、あるいは記載した実施形態によって書き込まれた実際のシンタックス値をデータとして担持するようにフォーマット化することができる。このような信号は、例えば、（例えばスペクトルの無線周波部分を用いて）電磁波として、またはベースバンド信号として、フォーマット化することができる。フォーマット化は、例えば、データ・ストリームの符号化、および符号化済みデータ・ストリームによる搬送波の変調などを含むことができる。信号が担持する情報は、例えば、アナログ情報またはディジタル情報とすることができる。信号は、既知の通り、様々な有線または無線リンクを介して伝送することができる。信号は、プロセッサ可読媒体に記憶することができる。

上記の実施態様の記述では、開示を合理化し、様々な特徴の１つまたは複数の理解を助ける目的で、様々な特徴を、１つの実施態様、図面または記述にまとめている箇所があることを理解されたい。しかし、この開示方法は、請求する発明が、各請求項に明示的に記載している以上の特徴を必要とするという意図を表していると解釈すべきではない。そうではなく、以下の特許請求の範囲が表すように、本発明の特徴は、上記に開示した１つの実施形態の全てのフィーチャを含まないこともある。従って、各請求項が別々の実施態様を提供することを理解されたい。

いくつかの実施態様について説明した。しかし、様々な修正を加えることができることを理解されたい。例えば、異なる実施態様の要素を組み合わせて、補足して、修正して、または除去して、その他の実施態様を生み出すこともできる。さらに、機能ブロック間で、動作を入れ替えることもできる。さらに、その他の構造およびプロセスを、開示した構造およびプロセスの代わりに用いることもでき、その結果得られる実施態様では、開示した実施態様と少なくとも実質的には同じ１つまたは複数の機能が、少なくとも実質的には同じ１つまた複数の方法で実行されて、少なくとも実質的には同じ１つまた複数の結果が得られることは、当業者なら理解するであろう。従って、本願では、上記その他の実施態様を企図し、それらの実施態様は、以下の特許請求の範囲に含まれる。

Claims (21)

1. 方法であって、
   所与の時点の所与のビューに対して異なる３次元（３Ｄ）情報を記述する複数のピクチャを符号化するステップと、
   前記符号化された複数のピクチャに対して３Ｄ処理に対応した構造に前記符号化されたピクチャがどのように適応するかを示すシンタックス要素を生成するステップであって、該構造が前記複数のピクチャのコンテンツ・タイプを規定し、該コンテンツ・タイプが、２次元映像、奥行き、隠蔽映像、隠蔽奥行き、および透明度のうちの１つまたは複数を含む、該ステップと、
   前記符号化された複数のピクチャおよび前記シンタックス要素を含むビットストリームを生成するステップであって、前記シンタックス要素を含むことにより符号化されたビットストリームのレベルで前記構造における前記符号化された複数のピクチャの間の関係を示す指示が与えられる、該ステップと、
   を含む、前記方法。
2. 複数の追加ピクチャを符号化するステップであって、該複数の追加ピクチャが、前記所与の時点の第２のビューについての異なる３Ｄ情報を記述しており、該第２のビューが、前記所与のビューとは異なるビューである、該ステップと、
   前記符号化された複数の追加ピクチャについて、前記符号化されたピクチャが３Ｄ処理に対応する前記構造にどのように適応するかを示す追加のシンタックス要素を生成するステップであって、前記構造が前記複数の追加ピクチャのコンテンツ・タイプを含む、該ステップと、
   をさらに含み、
   前記生成されたビットストリームが、前記符号化された複数の追加ピクチャおよび前記追加のシンタックス要素をさらに含み、該追加のシンタックス要素を含むことにより符号化されたビットストリームのレベルで前記構造における前記符号化された複数の追加ピクチャの間の関係を示す指示が与えられる、請求項１に記載の方法。
3. 前記シンタックス要素および構造が、Ｍｕｌｔｉｖｉｅｗ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＭＶＣ）と互換性がある、請求項１に記載の方法。
4. 前記シンタックス要素が前記複数のピクチャのそれぞれのＭＶＣビュー識別子を含み、前記複数のピクチャ間の依存関係がＭＶＣシーケンス・パラメータ・セット・データによって示される、請求項３に記載の方法。
5. 前記シンタックス要素が、前記構造が前記ビットストリームで使用されたことを示すネットワーク抽象化レイヤ（ＮＡＬ）ユニット・タイプを含む、請求項１に記載の方法。
6. 前記符号化されたピクチャのそれぞれのシンタックス要素が３Ｄビュー識別子およびコンテンツ・タイプ識別子を含み、該３Ｄビュー識別子が１組の前記符号化されたピクチャで構成される３Ｄビューを識別し、該１組の前記符号化されたピクチャのそれぞれが、異なるコンテンツ・タイプに対応する、請求項１に記載の方法。
7. 前記符号化されたピクチャのそれぞれのシンタックス要素が、対応する符号化されたピクチャのデータを含む１つまたは複数のＮＡＬユニットとは別のネットワーク抽象化レイヤ（ＮＡＬ）ユニットに含めて伝送される、請求項６に記載の方法。
8. 前記符号化されたピクチャのそれぞれのシンタックス要素が、異なるＭｕｌｔｉｖｉｅｗ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＭＶＣ）ビュー識別子を含むことにより、符号化された各ピクチャを別個のＭＶＣビューとして規定する、請求項６に記載の方法。
9. 前記符号化されたピクチャのそれぞれのシンタックス要素が３Ｄビューおよびコンテンツ・タイプの両方を示すＭｕｌｔｉｖｉｅｗ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＭＶＣ）ビュー識別子を含み、該ＭＶＣビュー識別子が１組の前記符号化されたピクチャで構成される３Ｄビューを識別し、該１組の前記符号化されたピクチャのそれぞれが異なるコンテンツ・タイプに対応する、請求項１に記載の方法。
10. 前記複数のピクチャが２次元（２Ｄ）映像ピクチャおよび１つまたは複数の３Ｄ映像補足レイヤ・ピクチャを含み、
    前記符号化された２Ｄ映像ピクチャのシンタックス要素が前記符号化された２Ｄ映像ピクチャのＭｕｌｔｉｖｉｅｗ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＭＶＣ）ビュー識別子を含み、
    前記符号化された２Ｄ映像ピクチャおよび前記符号化された１つまたは複数の３Ｄ映像補足レイヤ・ピクチャのシンタックス要素が前記符号化された２Ｄ映像ピクチャおよび対応する符号化された３Ｄ映像補足レイヤ・ピクチャの３Ｄビュー識別子およびコンテンツ・タイプ識別子を含み、前記３Ｄビュー識別子が前記符号化されたピクチャのセットで構成される３Ｄビューを識別し、前記セットの前記符号化されたピクチャのそれぞれが異なるコンテンツ・タイプに対応する、請求項１に記載の方法。
11. 前記１つまたは複数の３Ｄ映像補足レイヤ・ピクチャのシンタックス要素が、対応する符号化されたピクチャのデータを含むネットワーク抽象化レイヤ（ＮＡＬ）ユニットに含めて伝送される、請求項１０に記載の方法。
12. 前記符号化された２Ｄ映像ピクチャのシンタックス要素がＭＶＣと互換性があり、前記３Ｄ映像補足レイヤのシンタックス要素がＭＶＣとは異なる符号化規格と互換性がある、請求項１０に記載の方法。
13. 前記複数のピクチャを符号化するステップが、前記複数のピクチャのうちの１つのピクチャを前記複数のピクチャのうちの別のピクチャを参照として使用して符号化することによりコンテンツ・タイプの異なるピクチャ間のレイヤ間符号化を実現することを含む、請求項１に記載の方法。
14. 前記シンタックス要素が、（１）Ｍｕｌｔｉｖｉｅｗ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＭＶＣ）ビュー識別子、（２）３Ｄ映像（３ＤＶ）ビュー識別子、および（３）３ＤＶレイヤ識別子のうちの１つまたは複数を含む、請求項１に記載の方法。
15. 前記符号化するステップ、前記シンタックス要素を生成するステップ、および前記ビットストリームを生成するステップがエンコーダで実行される、請求項１に記載の方法。
16. 装置であって、
    所与の時点の所与のビューに対して異なる３次元（３Ｄ）情報を記述する複数のピクチャを符号化する手段と、
    前記符号化された複数のピクチャに対して３Ｄ処理に対応した構造に前記符号化されたピクチャがどのように適応するかを示すシンタックス要素を生成する手段であって、該構造が前記複数のピクチャのコンテンツ・タイプを規定し、該コンテンツ・タイプが、２次元映像、奥行き、隠蔽映像、隠蔽奥行き、および透明度のうちの１つまたは複数を含む、該手段と、
    前記符号化された複数のピクチャおよび前記シンタックス要素を含むビットストリームを生成する手段であって、前記シンタックス要素を含むことにより符号化されたビットストリームのレベルで前記構造における前記符号化された複数のピクチャの間の関係を示す指示が与えられる、該手段と、
    を備える、前記装置。
17. 方法であって、
    所与の時点の所与のビューに対して異なる３次元（３Ｄ）情報を記述する、ビットストリームに属する符号化された複数のピクチャにアクセスするステップと、
    前記符号化された複数のピクチャに対して前記複数のピクチャ間の規定された関係を与える３Ｄ処理に対応した構造に、前記符号化されたピクチャがどのように適応するかを示す、前記ビットストリームに属するシンタックス要素にアクセスするステップと、
    前記符号化された複数のピクチャを復号するステップであって、前記規定された関係を使用して、２次元（２Ｄ）レイヤ・ピクチャ、奥行きレイヤ・ピクチャ、隠蔽映像レイヤ・ピクチャ、隠蔽奥行きレイヤ・ピクチャ、および透明度ピクチャのうちの１つまたは複数を参照する追加ピクチャを描画することを含む、該ステップと、
    前記復号されたピクチャを前記複数のピクチャ間の前記規定された関係を示す出力フォーマットで供給するステップと、
    を含む、前記方法。
18. 前記出力フォーマットが、所与の復号されたピクチャがどのように前記構造に適応するかを指定するシンタックス要素を含む、請求項１７に記載の方法。
19. 前記符号化された複数のピクチャのアクセスするステップ、前記シンタックス要素のアクセスするステップ、前記復号するステップ、および前記供給するステップが、エンコーダおよびデコーダの１つまたは複数で実行される、請求項１７に記載の方法。
20. 前記シンタックス要素を使用して、前記複数のピクチャから２次元（２Ｄ）映像ピクチャを識別するステップと、
    前記シンタックス要素を使用して、前記複数のピクチャから、奥行きピクチャ、隠蔽映像ピクチャ、隠蔽奥行きピクチャまたは透明度ピクチャのうちの１つまたは複数を識別するステップと、
    前記２Ｄ映像ピクチャと、前記奥行きピクチャ、前記隠蔽映像ピクチャ、前記隠蔽奥行きピクチャ、または前記透明度ピクチャから識別された１つまたは複数のピクチャとに基づいて追加ビューの新たなピクチャを描画することによって３Ｄ処理を実行するステップと、
    をさらに含む、請求項１７に記載の方法。
21. 装置であって、
    ビットストリームに属する符号化された複数のピクチャにアクセスする手段であって、該複数のピクチャが所与の時点の所与のビューに対して異なる３次元（３Ｄ）情報を記述する、該手段と、
    前記ビットストリームに属するシンタックス要素にアクセスする手段であって、該シンタックス要素が前記符号化された複数のピクチャに対して前記複数のピクチャ間の規定された関係を与える３Ｄ処理に対応した構造に前記符号化されたピクチャがどのように適応するかを示す、該手段と、
    前記符号化された複数のピクチャを復号する手段であって、前記規定された関係を使用して、２次元（２Ｄ）レイヤ・ピクチャ、奥行きレイヤ・ピクチャ、隠蔽映像レイヤ・ピクチャ、隠蔽奥行きレイヤ・ピクチャ、および透明度ピクチャのうちの１つまたは複数を参照する追加ピクチャを描画する、該手段と、
    前記復号されたピクチャを前記複数のピクチャ間の前記規定された関係を示す出力フォーマットで供給する手段と、
    を備える、前記装置。

Images