当技術分野では、通常、3D映像(3DV)の基本原則は、1つのシーンまたはオブジェクトの異なるビューをユーザの左右の目それぞれに対して与えることにより、ユーザがそのシーンまたはオブジェクトの奥行きを感じることができるようにすることであると理解されている。さらに、ユーザ・エクスペリエンスを向上させるために、伝送されているビュー以外の仮想ビューを描画して、例えば、知覚される異なる奥行きの範囲に対して基線長を調整することもできる。これらの目的の1つまたは複数を達成するために、上記のように、3D映像(3DV)表現フォーマットは、例えば映像や奥行き、また場合によっては2D+Z(MVD)やLDV(DES)などのさらに補足的な情報など、様々なレイヤを含むことができる。3DVコンテンツの奥行きおよびその他の補足的情報の概念をよりよく例示するために、図1および図2を参照する。
図1は、従来の映像に対応する奥行きマップ100の一例を示す図である。さらに、図2は、LDVフォーマットの4つの構成要素の一例、すなわち2D映像202およびその奥行き(Z)204と、同じシーンの隠蔽映像206およびその隠蔽奥行き208とを含む図である。上述のデータ・フォーマットの符号化および伝送は、多くの点で困難である。例えば、符号化効率以外に、旧来のAdvanced Video Coding(AVC)/Multiview Coding(MVC)デコーダがビットストリームから可視映像を抽出することができるように、同期や(従来のモノスコープ2D映像との)後方互換性などの機能も提供することが好ましい。
これらの問題の少なくとも一部に対処できる1つの解決策は、各ビューおよび/またはレイヤの符号化および伝送を独立して行うサイマルキャスト(simulcast)である。この手法では、個々のビュー/レイヤをそれぞれ符号化および復号し、それらのビュー/レイヤを同期させてシステム・レベルまたはアプリケーション・レベルで可視画像にするために、複数のエンコーダおよびデコーダを使用することがある。例えば、Moving Picture Experts Group(MPEG)−C Part3(International Organization for Standardization(ISO)/International Electrotechnical Commission(IEC)23002−3)では、2D+Zのシステム・フレームワークを指定している。通常の実施態様では、映像と奥行きの間でシステム・レベルの同期を用いている。映像および奥行きは、任意の既存の映像符号化規格を用いて符号化することができる。しかし、通常の実施態様では、映像および奥行きの符号化が切り離されている。従って、サイマルキャストのコストは、伝送するビューおよび/またはレイヤの数だけ増大する。さらに、異なるビューおよび/またはレイヤを別々に符号化するので、ビューおよび/またはレイヤ間で冗長性があっても、通常は、それを利用して符号化効率を高めることは行われない。
それに対して、本明細書に記載する1つまたは複数の実施態様では、レイヤ間符号化を可能にして、レイヤ間の冗長性を活用することにより、AVC/MVCシステムの後方互換性に加えて、より高い符号化効率を実現することができる。特に、1つまたは複数の実施態様では、符号化レベルでのビューおよび/またはレイヤの同期を可能にして、これらの利点の少なくとも一部を達成する手段を提供する。例えば、本明細書に記載する少なくとも1つの実施態様では、ビュー/レイヤのレイヤ間符号化および同期を効率的に可能にするために、AVCのNALユニット設計に基づく新規の3DVプレフィックス・ネットワーク抽象化レイヤ(NAL)ユニットおよび新規の3DV NALユニット・ヘッダ拡張を提案する。このハイレベル・シンタックスは、AVCビットストリームやScalable Video Coding(SVC)/MVCビットストリームなどのビットストリームから3DV構成要素を抽出する方法を示している。従って、この手法は、3DV構成要素を符号化済みビットストリーム(SVCレイヤやMVCビューなど)中で結合することができるので、システム・レベルで異なる3DV構成要素間の同期を行う必要がないという利点がある。別の可能性のある利点として、このように符号化を行うときには、レイヤ間またはビュー間の冗長性を除去することができる。さらに、新規のNALユニット設計は、MVCとの互換性を維持することができ、また、任意の将来のカプセル化符号化技術との互換性も維持して、高度な圧縮効率を実現することもできる。
以下に述べるように、システム・レベルではなく符号化レベルにおいて異なるビュー/レイヤの同期を可能にするために、1つまたは複数の実施態様では、3DV NALユニット設計を、3DVビュー識別子(ID)および3DVレイヤIDと関連付ける。さらに、ビュー間/レイヤ間の冗長性をさらに活用するために、ビュー間/レイヤ間の予測を利用して、インタリーブ方式を用いたAVCと比較してより高い符号化効率を実現する。さらに、3DV補足レイヤのNALユニット設計は、MVC/AVCとの2Dビュー・レイヤ互換性に影響を及ぼすことなく、新たな符号化モード/ツールを開発することを可能にしながら、完全な後方互換性も実現することができる。
様々な実施形態は、複数の参照予測を利用することによって3DVコンテンツを含むビットストリームの符号化および復号を可能にする参照リストの構成に関する。例えば、3DV符号構造では、少なくとも3つのタイプの参照ピクチャがある可能性がある。例えば、時間的参照ピクチャ、ビュー間参照ピクチャ、および異なる3DVレイヤからの参照ピクチャなどである。異なる3DVレイヤからの参照ピクチャとしては、例えば、奥行きレイヤの参照として使用される2D映像レイヤなどが挙げられる。本出願に記載する少なくとも1つの実施形態では、これら3つのタイプの参照ピクチャを参照ピクチャ・リスト内にどのように配列するかに関する概念および実施態様を提供する。例えば、予測モードでマクロブロック(MB)を符号化するときには、エンコーダは、利用可能な複数の参照ピクチャの中で、どの1つまたは複数のピクチャが参照として使用されるかを示すことができる。ここで、リスト中の指標により、どの参照ピクチャが使用されるかを示すことができる。以下でさらに述べるように、1つまたは複数の実施形態では、レイヤ間予測を可能にするために、1つまたは複数のレイヤ間参照ピクチャをリスト内に設けることができる。
上記のように、1つまたは複数の実施形態には多くの利点があり、そのうちの1つは、MVCとの潜在的な互換性である。すなわち、これらの実施形態の1つによる3DVビットストリームが旧来のMVCデコーダに送られると、2D映像(例えば以下ではレイヤ0として示す)を、復号して出力することができる。様々なレイヤを用いた効率的な3DVコンテンツの符号化を同時に可能にしながら、MVCとの互換性をさらに支援するために、さらに様々な実施形態は、シーケンス・パラメータ・セット(SPS)の構築および信号通信を対象としている。当業者なら理解するであろうが、SPSは、1つのピクチャ・シーケンスの複数のピクチャ間で共有される共通の性質を指定することができる。このような共通の性質としては、例えば、ピクチャ・サイズ、利用している任意選択の符号化モード、マクロブロック/スライス・グループ・マップ(macroblock to slice group map)などがあり、これらはそれぞれ、1つのシーケンス中の複数のピクチャの間で必要に応じて共有することができる。少なくとも1つの実施形態では、SPSの拡張を利用して、3DVコンテンツの符号化および復号に使用される新規のシーケンス・パラメータを信号通信する。さらに、この拡張SPSに対して、別個の新規のNALユニット・タイプを利用することができる。以下でさらに述べるように、拡張SPSを、ルータなどのネットワーク・デバイスが使用して、3DVコンテンツ・ストリーミングのビットレートの適合を行うことができる。
実施形態について詳細に述べる前に、説明する概念の理解を容易にするために、使用する用語について簡単に述べておく。
[用語]
本明細書で使用する「2D映像」レイヤは、一般に、従来の映像信号を指す。
本明細書で使用する「奥行き」レイヤは、一般に、シーン中のオブジェクトについての距離情報を示すデータを指す。「奥行きマップ」は、奥行きレイヤの通常の例である。
本明細書で使用する「隠蔽映像」レイヤは、一般に、特定の視点からは遮られる映像情報を指す。隠蔽映像レイヤは、通常は、2D映像レイヤの背景情報を含む。
本明細書で使用する「隠蔽奥行き」レイヤは、一般に、ある特定の視点からは遮られる奥行き情報を指す。隠蔽奥行きレイヤは、通常は、奥行きレイヤの背景情報を含む。
本明細書で使用する「透明度」レイヤは、一般に、奥行きの不連続部または奥行きの境界を示すピクチャを指す。通常の透明度レイヤは2値情報を有し、その2つの値の一方は、奥行きが、近接する奥行き値に対して特定のしきい値を超える不連続性を有する位置を示す。
「3DVビュー」は、本明細書では、MVCで使用する「ビュー」とは異なる、1つのビュー位置からのデータ・セットとして定義する。例えば、3DVビューはMVCのビューよりも多くのデータを含むことができる。2D+Zフォーマットでは、3DVビューは2D映像およびその奥行きマップという、2つのレイヤを含むことができる。LDVフォーマットでは、3DVビューは、2D映像、奥行きマップ、隠蔽映像、および隠蔽奥行きマップという、4つのレイヤを含むことができる。さらに、特に透明度マップを、3DVビュー内のもう1つのレイヤ・データ・タイプとすることができる。
「3DVレイヤ」は、3DVビューのレイヤの1つとして定義する。3DVレイヤの例としては、例えば、2Dビューまたは2D映像、奥行き、隠蔽映像、隠蔽奥行き、および透明度マップなどがある。2Dビューまたは2D映像以外のレイヤは、「3DV補足レイヤ」とも定義される。1つまたは複数の実施形態では、3DVデコーダを、3dv_layer_idを用いて、1つのレイヤを特定して、このレイヤをその他のレイヤと区別するように構成することができる。1つの実施態様では、3dv_layer_idは、表1のように定義される。ただし、本明細書に与える教示に鑑みて当業者なら理解するであろうが、これらのレイヤは、その他の方法で定義し、識別することもできることに留意されたい。
図3は、ハイレベル汎用3DVエンコーダ300を示す図、図4は、ハイレベル汎用3DVデコーダ400を示す図である。エンコーダ300/デコーダ400は、複数のレイヤ・エンコーダ/デコーダと、1つの3DV参照バッファとで構成される。例えば、図3に示すように、2Dビュー・レイヤ、奥行きレイヤ、隠蔽・ビュー・レイヤ、隠蔽奥行きレイヤ、透明度マップ・レイヤなどを含むことができる3DVコンテンツ信号302が、様々なレイヤ・エンコーダに入力される。具体的には、エンコーダ・システム/装置300は、AVC互換性を有することもある、2Dレイヤを符号化するように構成された2Dレイヤ・エンコーダ304、エンハンスト2Dレイヤを符号化するように構成されたエンハンスト2Dレイヤ・エンコーダ306、奥行きレイヤを符号化するように構成された奥行きレイヤ・エンコーダ308、隠蔽ビュー・レイヤを符号化するように構成された隠蔽ビュー・レイヤ・エンコーダ310、隠蔽奥行きレイヤを符号化するように構成された隠蔽奥行きレイヤ・エンコーダ312、および透明度レイヤを符号化するように構成された透明度レイヤ・エンコーダ314を含む。従って、各レイヤを、異なるエンコーダおよび/または符号化技術を用いて符号化することができる。
本明細書では、エンハンスト2Dレイヤは、一般に、AVC、MVC、SVC、または他の基礎となる規格と互換性のあるレイヤからこのレイヤを区別するために使用される。例えば、エンハンスト2Dレイヤは、通常は、MVCとの互換性がない。エンハンスト2Dレイヤは、例えばレイヤ間参照を用いるなどの新たな符号化ツールを可能にするからである。従って、これらのレイヤは、一般にMVCとの後方互換性がない。
「エンハンスト2Dレイヤ」(または補足レイヤ)という用語は、MVCで符号化することができるレイヤを参照するために用いることができるが、表示が行われないと予想されたためにMVCで符号化されているとは通常記述されないレイヤを指してもよいことに留意されたい。例えば、一連の奥行きレイヤは、MVCで一連のピクチャとして処理され、MVCで符号化することができる。しかし、通常は奥行きレイヤを表示することはないので、これらのレイヤの識別および符号化には、MVCを用いる以外の別の方法を用いることが望ましいことが多い。
各レイヤで、異なる参照を使用することもできる。この参照は、符号化(復号)しているピクチャ/ブロックとは異なるレイヤのものであってもよい。異なるレイヤからの参照は、3DV参照バッファ316(3DV参照/出力バッファ414)から取得することができる。図3に示すように、各レイヤ・エンコーダは、3DV参照バッファ316と信号通信して様々なモードの入力信号302の符号化を可能にし、出力信号318を生成する。
3DV参照バッファ316を利用することにより、3DVフォーマットの各レイヤは、例えば動き補償およびまたはディスパリティ補償が施された同じレイヤ内の時間的参照および/またはビュー間参照など、そのレイヤ自体からの参照を用いて、且つ/または様々なレイヤ間のレイヤ間予測を用いて、符号化することができる。例えば、レイヤ間予測では、例えば動きベクトルや参照ピクチャ番号など、別のレイヤからの動き情報を再利用して、現在のレイヤを符号化することもでき、モーション・スキップ・モードと呼ばれる。このようにして、出力信号318は、1つまたは複数の3DVビューの様々なレイヤ情報を混合(interleave)することができる。レイヤ間予測は、他のレイヤの評価に基づく任意の種類の技術のものとすることができる。
図4に示すように、デコーダ・システム/装置400に関しては、システム400は、信号318を入力することができる様々なレイヤ・デコーダを含む。具体的には、デコーダ・システム/装置400は、AVC互換性を有することもある、2Dレイヤを復号するように構成された2Dレイヤ・デコーダ402、エンハンスト2Dレイヤを復号するように構成されたエンハンスト2Dレイヤ・デコーダ404、奥行きレイヤを復号するように構成された奥行きレイヤ・デコーダ406、隠蔽・ビュー・レイヤを復号するように構成された隠蔽・ビュー・レイヤ・デコーダ408、隠蔽奥行きレイヤを復号するように構成された隠蔽奥行きレイヤ・デコーダ410、および/または透明度レイヤを復号するように構成された透明度レイヤ・デコーダ412を含む。
図4に示すように、各レイヤ・デコーダは、レイヤ・デコーダから受信した復号済みレイヤ情報を構文解析して、入力信号に含まれるレイヤが、3D処理に対応する構造にどのように適応するかを判定するように構成することができる、3DV参照/出力バッファ414と信号通信している。このような3D処理としては、例えば、本明細書で述べるような3Dレイヤの符号化や、受信器または表示ユニットにおける追加ピクチャのレンダリング(合成処理)などがある。レンダリングでは、例えば、奥行きピクチャを使用して、2D映像および/または隠蔽ピクチャを歪ませて(warp)、描画されたピクチャの穴を背景情報で埋めることもできる。
さらに、3DV参照/出力バッファ414は、ユーザへの提示用に、3DV互換フォーマットで出力信号416を生成するように構成することができる。フォーマット化された3DVコンテンツ信号416は、もちろん、例えば2Dビュー・レイヤ、奥行きレイヤ、隠蔽ビュー・レイヤ、隠蔽奥行きレイヤ、および透明度マップ・レイヤを含むことができる。この出力バッファは、図4に示すように参照バッファと一体化して実装することもできるが、その代わりに他の実施形態では、参照バッファと出力バッファを別々のバッファとすることもできる。
エンコーダ300およびデコーダ400のその他の実施態様では、使用するレイヤの数がこれより多くても少なくてもよい。さらに、上記に示したレイヤ以外のレイヤを使用することもできる。
3DV参照バッファ316および3DV参照/出力バッファ414において用いている「バッファ」という用語は、インテリジェント・バッファであることは明らかであろう。このようなバッファは、例えば、ピクチャを記憶し、参照(または参照の一部分)を提供し、出力するためにピクチャを再配列するために使用することができる。さらに、このようなバッファは、他の様々な処理動作を実行するために使用することができ、例えば、仮想参照デコーダ・テスト、マーキング・コマンドの処理(例えばAVCにおけるメモリ管理制御動作)、および復号済みピクチャ・バッファ管理などの処理動作を実行するために使用することができる。
図5は、レイヤ・エンコーダ304〜314の何れか1つまたは複数を実施するために使用することができる一般的な3DVレイヤ・エンコーダ500を示すハイレベル・ブロック図/流れ図、図6は、レイヤ・デコーダ402〜412の何れか1つまたは複数を実施するために使用することができる一般的な3DVレイヤ・デコーダ600を示すハイレベル・ブロック図/流れ図である。各レイヤ・エンコーダ304〜314は、例えば図5に示すように、対応するレイヤに対して概ね同様に、特定の目的に適うように設計することができることに留意されたい。逆に、本明細書に与える教示に鑑みて理解されるであろうが、レイヤ・エンコーダは、それぞれ独自の特性をよりよく利用するように異なる構成にすることもできる。同様に、デコーダ402〜412は、例えば図6に示すように、対応するレイヤに対して概ね同様に設計することができる。また逆に、レイヤ・デコーダは、それぞれ独自の特性をよりよく利用するように異なる構成にすることもできる。
MVCエンコーダに関しては、入力が、複数のビューで構成されることに留意されたい。各ビューは、従来の2D映像である。従って、AVCエンコーダと比較して、通常のMVCエンコーダは、ディスパリティ推定ブロック、ディスパリティ補償ブロックおよびビュー間参照バッファなど、追加ブロックを含む。同様に、図5および図6は、3DV参照のブロックおよびレイヤ間予測のブロックを含んでいる。3DVエンコーダでは、入力は、複数の3Dビューで構成される。上記のように、各3Dビューは、いくつかのレイヤを含むことができる。従って、各レイヤの符号化方法は、それぞれ独自のフィーチャを利用するように異なる設計にすることができる。その結果、3DVエンコーダは、図3に示すように複数のレイヤ・エンコーダに分割することができる。しかし、レイヤ・エンコーダは、緊密に接続することもできる。レイヤ・エンコーダで用いられる技術は、所与のシステムに合わせて望み通りに調整することができる。各レイヤは映像信号として現れるので、これらのレイヤは、ハイレベルでは図5に示すように同様の構造を有することができる。なお、より低い、より具体的なレベルでは、これらのレイヤ・エンコーダの設計が異なる可能性もあることに留意されたい。もちろん、一実施形態では、全てのレイヤを符号化するように構成されたエンコーダを1つしか使用しないこともある。
図5に示すハイレベル図では、3DVレイヤ・エンコーダ500は、入力信号502中の3DVビューiの3DVビュー・レイヤを受信して、それらを互いに分割するように構成されたレイヤ分割器(レイヤ・パーティショナ)504を含むことができる。分割器504は、分割器504から1組の分割済みレイヤのセットをそれぞれ受信する、加算器または結合器506、変位(動き/ディスパリティ)補償モジュール508、および変位(動き/ディスパリティ)推定モジュール510と信号通信している。加算器506に対するもう1つの入力は、スイッチ512を介して受信される、様々な可能な参照ピクチャ情報のうちの1つである。
例えば、スイッチ512と信号通信しているモード決定モジュール536が、符号化モードが、現在符号化中の同じブロックまたはスライスを基準とするイントラ予測であると判定した場合には、加算器は、イントラ予測モジュール530からその入力を受信する。あるいは、モード決定モジュール536が、符号化モードが、現在符号化中のブロックまたはスライスとは異なる、現在処理中の同じフレームもしくは3DVビューもしくは3DVレイヤのブロックまたはスライス、または以前に処理した別のフレームもしくは3DVビューもしくは3DVレイヤのブロックまたはスライスを基準とする変位補償および推定であると判定した場合には、加算器は、図5に示すように変位補償モジュール508からその入力を受信する。さらに、モード決定モジュール536が、符号化モードが、現在処理中のレイヤとは異なる、現在処理中の同じフレームもしくは3DVビューの3DVレイヤ、または以前に処理した別のフレームもしくは3DVビューの3DVレイヤを基準とする3DVレイヤ間予測であると判定した場合には、加算器は、3DV参照バッファ532と信号通信している3DVレイヤ間予測モジュール534からその入力を受信する。
加算器506は、1つまたは複数の3DVレイヤと、予測情報、補償情報および/または推定情報を含む信号を、変換モジュール514に供給する。変換モジュール514は、その入力信号を変換して、変換済み信号を量子化モジュール516に提供するように構成されている。量子化モジュール516は、その受信信号に対して量子化を実行し、量子化済み情報をエントロピ・エンコーダ518に出力するように構成される。エントロピ・エンコーダ518は、その入力信号に対してエントロピ符号化を実行して、ビットストリーム520を生成するように構成される。逆量子化モジュール522は、量子化モジュール516から量子化済み信号を受信して、その量子化済み信号について逆量子化を実行するように構成される。逆変換モジュール524は、モジュール522から逆量子化済み信号を受信して、その受信信号に対して逆変換を実行するように構成される。モジュール522および524は、加算器506から出力された信号を再生成または再構成する。
加算器または結合器526は、逆変換モジュール524から受信した信号とスイッチ512から受信した信号を加算(結合)し、その結果得られた信号をイントラ予測モジュール530およびデブロッキング・フィルタ528に出力する。さらに、イントラ予測モジュール530は、その受信信号を用いて、上述のようにイントラ予測を実行する。同様に、デブロッキング・フィルタ528は、加算器526から受信した信号をフィルタリングし、フィルタリング済み信号を3DV参照バッファ532に提供する。
3DV参照バッファ532は、その受信信号を構文解析する。3DV参照バッファ532は、要素534、508および510による上述のレイヤ間の変位補償/推定符号化を支援する。3DV参照バッファ532は、例えば、様々な3DVレイヤの全てまたは一部を提供する。
再度図6を参照すると、3DVレイヤ・デコーダ600は、ビットストリーム受信器602を用いてビットストリーム318を受信するように構成することができ、ビットストリーム受信器602は、ビットストリーム解析器604と信号通信して、ビットストリームを解析器604に供給する。ビットストリーム・解析器604は、残留ビットストリーム605をエントロピ・デコーダ606に伝送し、制御シンタックス要素607をモード選択モジュール622に伝送し、変位(動き/ディスパリティ)ベクトル情報609を変位補償(動き/ディスパリティ)モジュール618に伝送し、現在復号中の3DVレイヤ以外の3DVレイヤからの符号化情報611を3DVレイヤ間予測モジュール620に伝送するように構成することができる。逆量子化モジュール608は、エントロピ・デコーダ606から受信したエントロピ復号済み信号に対して逆量子化を実行するように構成することができる。さらに、逆変換モジュール610は、逆量子化モジュール608から受信した逆量子化済み信号について逆変換を実行し、逆変換済み信号を加算器または結合器612に出力するように構成することができる。
加算器612は、利用している復号モードに応じて、その他にも様々な信号の1つを受信することができる。例えば、モード決定モジュール622は、制御シンタックス要素607を構文解析および解析することにより、3DVレイヤ間予測、変位補償またはイントラ予測符号化が、エンコーダ500が現在処理しているブロックに対して実行されたかどうかを判定することができる。判定したモードに応じて、モード選択制御モジュール622は、制御シンタックス要素607に基づいてスイッチ623にアクセスしてこれを制御し、加算器612が3DVレイヤ間予測モジュール620、変位補償モジュール618またはイントラ予測モジュール614から信号を受信できるようにすることができる。
ここで、イントラ予測モジュール614は、例えば、現在復号中の同じブロックまたはスライスへの参照を用いて、イントラ予測を実行してブロックまたはスライスを復号するように構成することができる。また、変位補償モジュール618は、例えば、現在復号中のブロックまたはスライスとは異なる、現在処理中の同じフレームもしくは3DVビューもしくは3DVレイヤのブロックまたはスライス、または以前に処理した別のフレームもしくは3DVビューもしくは3DVレイヤのブロックまたはスライスへの参照を用いて、変位補償を実行してブロックまたはスライスを復号するように構成することができる。さらに、3DVレイヤ間予測モジュール620は、例えば、現在処理している同じフレームもしくは3DVビューまたは以前に処理した別のフレームもしくは3DVビューの、現在処理しているレイヤとは異なる3DVレイヤへの参照を用いて、3DVレイヤ間予測を実行してブロックまたはスライスを復号するように構成することができる。
予測情報信号または補償情報信号を受信した後で、加算器612は、この予測情報信号または補償情報信号を逆変換済み信号と加算して、デブロッキング・フィルタ602に伝送することができる。デブロッキング・フィルタ602は、その入力信号をフィルタリングして、復号済みピクチャを出力するように構成することができる。また、加算器612は、加算済み信号を、イントラ予測に使用できるように、イントラ予測モジュール614にも出力することができる。さらに、デブロッキング・フィルタ602は、フィルタリング済み信号を3DV参照バッファ616に伝送することができる。3DV参照バッファ616は、その受信信号を構文解析して、要素618および620による上述のレイヤ間の変位補償復号を可能にし、これを支援するように構成することができる。3DV参照バッファ616は、要素618および620のそれぞれに対して構文解析済み信号を供給する。この構文解析済み信号は、例えば、様々な3DVレイヤの全てであってもよいし、その一部であってもよい。
本明細書に開示する教示に鑑みて当業者には理解されるであろうが、システム/装置300、400、500および600は、上記とは異なる構成であってもよく、上記と異なる要素を含んでいてもよいことを理解されたい。
次に、図7を参照すると、図7は、一実施態様による、本明細書に記載する態様を適用することができる映像伝送システム/装置700を示す図である。映像伝送システム700は、例えば、例えば衛星、ケーブル、電話回線、地上波放送など様々なメディアの何れかを用いて信号を伝送するヘッドエンド・システムまたは伝送システムとすることができる。この伝送は、インターネットなど何らかのネットワークを介して行うことができる。
映像伝送システム700は、例えば映像コンテンツおよび奥行きを、その他の3DV補足レイヤとともに生成し、配信することができる。これは、3DV補足レイヤ情報、または例えばデコーダなどの受信器側で3DV補足レイヤ情報を合成するために使用することができる情報を含む、1つまたは複数の符号化済み信号を生成することによって達成される。
映像伝送システム700は、エンコーダ710と、符号化済み信号を伝送することができる伝送器720とを含む。エンコーダ710は、映像情報を受信し、この映像情報および/または3DVレイヤ情報に基づいて1つまたは複数の符号化済み信号を生成する。エンコーダ710は、例えば、上記で詳細に述べたエンコーダ300とすることができる。エンコーダ710は、例えば様々な情報を受信して、記憶または伝送に適した構造のフォーマットにアセンブルするアセンブリ・ユニットなどの、サブモジュールを含むことができる。この様々な情報としては、例えば、符号化された映像または符号化されていない映像、符号化された奥行き情報または符号化されていない奥行き情報、ならびに例えば動きベクトル、符号化モード指標およびシンタックス要素などの、符号化された要素または符号化されていない要素などが挙げられる。
伝送器720は、例えば、符号化済みピクチャおよび/またはそれに関連する情報を表す1つまたは複数のビットストリームを有するプログラム信号750を伝送するようにすることができる。通常の伝送器は、例えば、誤り訂正符号化を実行する、信号にデータをインタリーブする、信号中のエネルギーをランダム化する、変調器722を用いて1つまたは複数の搬送波に信号を変調するといったうちの1つまたは複数などの機能を実行する。伝送器720は、アンテナ(図示せず)を含む、またはアンテナとインタフェースをとることができる。さらに、伝送器720の実施態様は、変調器を含むこともあれば、変調器に限定されることもある。
図8を参照すると、図8は、一実施態様による、本明細書に記載する態様を適用することができる映像受信システム/装置800を示す図である。映像受信システム800は、例えば、例えば衛星、ケーブル、電話回線、地上波放送など様々なメディアを介して信号を受信するように構成することができる。信号は、インターネットなど何らかのネットワークを介して受信することができる。
映像受信システム800は、例えば、符号化済み映像を受信して、ユーザに対して表示するため、または記憶するための復号済み映像などを供給する、携帯電話、コンピュータ、セット・トップ・ボックス、テレビジョン、またはその他のデバイスとすることができる。従って、映像受信システム800は、例えばテレビジョンの画面、コンピュータ・モニタ、コンピュータ(記憶、処理または表示を行う)、あるいはその他の何らかの記憶、処理または表示デバイスに対して、その出力を供給することができる。
映像受信システム800は、映像情報を含む映像コンテンツを受信し、処理することができる。映像受信システム800は、例えば本願の実施態様で述べる信号などの符号化済み信号を受信することができる受信器810と、受信信号を復号することができるデコーダ820とを含む。
受信器810は、例えば、符号化済みピクチャを表す複数のビットストリームを有するプログラム信号を受信するようにすることができる。典型的な受信器は、例えば、変調済み且つ符号化済みのデータ信号を受信する、復調器822を用いて1つまたは複数の搬送波からデータ信号を復調する、信号中のエネルギーを逆ランダム化する、信号中のデータをインタリーブ解除する、信号の誤り訂正復号を行うといったうちの1つまたは複数などの機能を実行する。受信器810は、アンテナ(図示せず)を含むか、またはアンテナと接続することができる。受信器810の実施態様は、復調器を含むこともあれば、復調器に限定されることもある。
デコーダ820は、映像情報および奥行き情報を含む映像信号を出力する。デコーダ820は、例えば、上記で詳細に述べたデコーダ400とすることができる。
システム700への入力は、図7では、「入力信号(1つまたは複数)」と記してあり、システム800からの出力は、図8では、「出力映像」として記してある。少なくともこれらの実施態様では、これらが複数のレイヤを含む3D映像を指していることは明らかであろう。
図9を参照すると、図9は、一実施態様による、本明細書に記載する特徴を適用することができる映像処理デバイス900を示す図である。映像処理デバイス900は、符号化済み映像を受信し、例えばユーザに対して表示するため、または記憶するための復号済み映像を供給する、セット・トップ・ボックスまたは他のデバイスとすることができる。従って、映像処理デバイス900は、テレビジョン、コンピュータ・モニタ、あるいはコンピュータまたはその他の処理デバイスに、その出力を供給することができる。
映像処理デバイス900は、フロントエンド(FE)デバイス905と、デコーダ910とを含む。フロントエンド・デバイス905は、例えば、符号化済みピクチャを表す複数のビットストリームを有するプログラム信号を受信し、該複数のビットストリームから復号するための1つまたは複数のビットストリームを選択するようになされた受信器とすることができる。通常の受信器は、変調済み且つ符号化済みのデータ信号を受信する、データ信号を復調する、データ信号の1つまたは複数の符号化(例えばチャネル符号化および/またはソース符号化)を復号する、および/またはデータ信号の誤り訂正を行うといったうちの1つまたは複数などの機能を実行する。フロントエンド・デバイス905は、例えばアンテナ(図示せず)からプログラム信号を受信することができる。フロントエンド・デバイス905は、受信したデータ信号をデコーダ910に供給する。
デコーダ910は、データ信号920を受信する。データ信号920は、例えば、1つまたは複数のAdvanced Video Coding(AVC)またはScalable Video Coding(SVC)またはMulti−view Video Coding(MVC)と互換性のあるストリームを含むことができる。
AVCは、より詳細には、既存のInternational Organization for Standardization/International Electrotechnical Commission(ISO/IEC) Moving Picture Experts Group−4(MPEG−4) Part 10 Advanced Video Coding(AVC)規格/International Telecommunication Union、Telecommunication Sector(ITU−T) H.264勧告(以下、「H.264/MPEG−4 AVC規格」として、または「AVC規格」や単なる「AVC」などの変形形式として表記する)のことである。
MVCは、より詳細には、AVC規格のマルチビュー映像符号化(「MVC」)拡張(Annex H)のことであり、「H.264/MPEG−4 AVC MVC拡張」(「MVC拡張」または単に「MVC」)と呼ぶ。
SVCは、より詳細には、AVC規格のスケーラブル映像符号化(「SVC」)拡張(Annex G)のことであり、「H.264/MPEG−4 AVC SVC拡張」(「SVC拡張」または単に「SVC」)と呼ぶ。
デコーダ910は、受信信号920の全てまたは一部を復号し、復号済み映像信号930を出力として提供する。復号済み映像930は、セレクタ950に提供される。デバイス900は、ユーザ入力970を受信するユーザ・インタフェース960も含む。ユーザ・インタフェース960は、ユーザ入力970に基づくピクチャ選択信号980を、セレクタ950に提供する。ピクチャ選択信号980およびユーザ入力970は、利用可能な復号済みデータの複数のピクチャ、シーケンス、スケーラブル・バージョン、ビューまたはその他の選択のうちのどれをユーザが表示したいと望んでいるかを示す。セレクタ950は、選択した1つまたは複数のピクチャを出力990として供給する。セレクタ950は、ピクチャ選択情報980を使用して、復号済み映像930中のどのピクチャを出力990として供給するかを選択する。
様々な実施態様では、セレクタ950は、ユーザ・インタフェース960を含むが、実施態様によっては、別個のインタフェース機能が実行されることなく、セレクタ950がユーザ入力970を直接受信するので、ユーザ・インタフェース960が不要である。セレクタ950は、例えば、ソフトウェアとして実施しても、集積回路として実施してもよい。一実施態様では、セレクタ950がデコーダ910に組み込まれるが、別の実施態様では、デコーダ910、セレクタ950およびユーザ・インタフェース960が、全て一体化される。
1つの応用分野では、フロントエンド905は、様々なテレビジョン・ショーの放送を受信して、そのうちの1つを選択して処理する。1つのショーの選択は、ユーザからの視聴したいチャネルの入力に基づいて行われる。図9には、フロントエンド・デバイス905へのユーザ入力が図示されていないが、フロントエンド・デバイス905は、ユーザ入力970を受信する。フロントエンド・デバイス905は、放送を受信し、放送スペクトルの関連部分を復調し、この復調済みのショーに外部符号化があればこれを復号することにより、所望のショーを処理する。フロントエンド・デバイス905は、復号済みのショーをデコーダ910に供給する。デコーダ910は、デバイス960および950を含む集積ユニットである。従って、デコーダ910は、当該ショー中で視聴することを望むビューを示すユーザから供給された指示であるユーザ入力を受信する。デコーダ910は、選択されたビュー、およびその他のビューに含まれる任意の所要の参照ピクチャを復号し、復号済みのビュー990をテレビジョン(図示せず)に表示するために提供する。
引き続き上記の応用分野で、ユーザは、表示されているビューを切り替えたいと望むことがあり、その場合には、新たな入力をデコーダ910に供給することができる。ユーザから「ビュー変更」を受信した後で、デコーダ910は、古いビューおよび新しいビューの両方と、古いビューと新しいビューの間にある任意のビューとを復号する。すなわち、デコーダ910は、古いビューを撮影したカメラと新しいビューを撮影したカメラの間に物理的に位置する複数のカメラから取得した任意のビューを復号する。フロントエンド・デバイス905は、古いビュー、新しいビュー、およびその間のビューを識別する情報も受信する。これらの情報は、例えば、ビューの位置に関する情報を有する制御装置(図9には図示せず)またはデコーダ910によって与えることができる。その他の実施態様では、制御装置が一体化されたフロントエンド・デバイスを使用することもできる。
デコーダ910は、これらの復号済みビューの全てを出力990として供給する。ポストプロセッサ(図9には図示せず)が、これらのビューを補間して、古いビューから新しいビューへ滑らかに遷移させ、この遷移をユーザに対して表示する。新しいビューに遷移した後で、ポストプロセッサは、(図示しない1つまたは複数の通信リンクを介して)デコーダ910およびフロントエンド・デバイス905に対して、新しいビューのみが必要であることを通知する。その後、デコーダ910は、出力990として新しいビューのみを供給する。
システム/装置900は、一続きの画像シーケンスの複数のビューを受信し、1つのビューを表示するために提示し、様々なビュー間で滑らかに切り替えるために使用することができる。この滑らかさは、ビュー間を補間して別のビューに滑らかに移行させることを必要とすることがある。さらに、システム900は、ユーザがオブジェクトまたはシーンを回転させる、またはその他の方法でオブジェクトまたはシーンの3次元表現を見ることができるようにすることができる。例えば、オブジェクトの回転は、ビューからビューに移行し、当該ビュー間を補間して当該ビュー間の滑らかな遷移を実現する、または単純に3次元表現を実現することに対応することがある。すなわち、ユーザは、補間済みのビューを、表示する「ビュー」として「選択」することができる。
映像伝送システム700、映像受信システム800および映像処理デバイス900は全て、本願に述べる様々な実施態様とともに使用するように適応化することができることは、明らかであろう。例えば、システム700、800および900は、上述の3DVフォーマットの1つのデータ、およびそれに関連する信号通信情報とともに動作するように適応化することもできる。
[実施形態1:3DVプレフィックスNALユニット]
この実施形態では、新たなNALユニット・タイプを紹介し、これを「3DVプレフィックスNALユニット」と呼び、参照番号16で示す。このユニットは、特定の3DVビューまたは3DVレイヤのVideo Coding Layer(VCL)NALユニットまたはMVCプレフィックスNALユニット(nal_unit_type、14で示す)より前に置くことができる。VCL NALユニットおよびMVCプレフィックス・ユニットについては、提案するAVC規格に関連がある、Gary Sullivan他による「Editors’ draft revision to ITU−T Rec. H.264|ISO/IEC 14496−10 Advanced Video Coding」、JVT−AD007、2009年1月2月号、Geneva CH(以下「AVC」ドラフト)に詳細に述べられている。本明細書で使用されているが明示的な定義がなされていない多くの用語および略語の意味は、このAVCドラフトに記載されており、当業者なら理解することができる。3DVプレフィックスNALユニットを指すのに使用している「16」は、任意に選んだものであり、AVCドラフトにおいて予約済みとされている任意のNALユニット・タイプになるように選ぶことができる。
以下に示す表2は、nal_unit_type符号に関するAVCドラフトの表7−1の修正版であり、3DVプレフィックスNALユニット16を定義するものである。AVCドラフトの表7−1は、以下に表3として再現しておく。なお、表2は、以下でさらに詳細に述べる実施形態3での修正も含むことに留意されたい。3DVプレフィックスNALユニット16は、MVC互換デコーダが、3DV補足レイヤも含めて伝送された全ての3DVレイヤを復号することを可能にし、また、符号化レベルでの3DVビューおよびレイヤの同期も可能にする。表2の行2〜5(NALユニット・タイプ16〜23)は、表3のシンタックス変更を反映している。
提案する3DVプレフィックスNALユニットに関するさらに詳細な説明を、以下の表4に示す。
表4に示すように、3DVプレフィックスNALユニットは、3dv_view_idおよび3dv_layer_idを含むことができる。3dv_view_idは、3DVビューに関連するフレームの3DVビューID番号を指定する。さらに、3dv_layer_idは、関連するフレームの3DVレイヤID番号を指定する。reserved_bitsは、NALユニットをバイト整列することができるようにする。なお、これらの各シンタックス要素に使用されるビットの数およびそれらの符号化方法は、単なる例に過ぎないことを理解されたい。また、NALユニット16のヘッダは、以下の表9の最初の3つの要素と同様に、標準的な第1のバイトを含むことができることに留意されたい。この実施形態では、NALユニット16は、ヘッダと拡張ヘッダとを含むことができ、ペイロードを含む必要はない。NALユニット16は、例えば、あらゆる3DVレイヤ・フレームよりも先に、または3DVレイヤ・フレームのあらゆるスライスより先に、伝送することができる。
3DVプレフィックスNALユニットの利用方法をより分かりやすく示すために、図10を参照する。図10は、3DVビュー1002、1004および1006の構造1000を含む3DVコンテンツの一例を示す図である。ここで、ビュー1002、1004および1006は、同じシーンまたはオブジェクトの異なるパースペクティブを与えるものである。この例では、各3DVビューは、2Dビュー1010およびその奥行き1008という、さらに2つのレイヤで構成される。図10の矢印は、異なるビュー間および異なるレイヤ間の符号化の依存関係を示している。例えば、双方向予測ビューであるBビュー1004は、符号化のために、ベース・ビュー1002と予測ビューであるPビュー1006とに依存し、これらを参照する。同様に、Pビュー1006は、ベース・ビュー1002に依存し、これを参照する。ここで、各3DVビューの奥行きレイヤ1008は、対応する3DVビューの2Dビュー・レイヤ1010を参照する。なお、当業者なら、本明細書に与える教示に鑑みて、これらの3DVビューおよび依存関係を、MVD、LDV、DESフォーマットに準拠したものなど追加の3DV補足レイヤを有する3DVコンテンツに拡張することができることに留意されたい。また、図10に示す依存関係は単なる例に過ぎないこと、および3DVプレフィックスNALユニットを使用することによってその他の様々な依存関係が可能になることにも留意されたい。
この実施形態による図10に示す3DVコンテンツのNALユニット・ストリームを、図11に示す。具体的には、図11では、異なる時点T0 1102およびT1 1110のNALユニット1100のストリームが、映像提示のために供給される。ここで、ビュー1104およびビュー1112(3DVビュー0)は、ベース・ビュー1002と同じパースペクティブまたは視点と関連付けられているので、それぞれ時点T0およびT1におけるベース・ビュー1002に対応する。同様に、ビュー1106およびビュー1114(3DVビュー2)は、それぞれ時点T0およびT1におけるPビュー1006に対応し、ビュー1108およびビュー1116(3DVビュー1)は、それぞれ時点T0およびT1におけるBビュー1004に対応する。
図11に示すように、各3DVビューは、2Dビュー・レイヤおよび奥行きレイヤで構成される。ただし、他の実施形態では、追加の補足レイヤを利用することもできることを理解されたい。ここで、ビュー1104は、2Dビュー・レイヤ1118および奥行きレイヤ1120で構成される。2Dビュー・レイヤ1118自体は、NALユニット16(1126)、14(1128)、および5(1130)で構成され、奥行きレイヤ1120は、NALユニット16およびNALユニット20(1132)で構成される。ビュー1106の2Dビュー・レイヤ1122および奥行きレイヤ1124自体は、図11に示すように、NALユニット16およびNALユニット20で構成される。ビュー1112は、NALユニット16および20を含む奥行きレイヤ、ならびにNALユニット16、14および1(1134)を含む2Dビュー・レイヤ1136の両方を含む。
図11の矢印は、NALユニットの伝送順序を示している。例えば、NALユニット16(1126)は、NALユニット14(1128)より前に伝送され、NALユニット14(1128)は、NALユニット5(1130)より前に伝送される、などである。NALユニット16は、表2および表4に定義されているが、図11に示すその他のNALユニットは、表3に定義されている。例えば、NALユニット5は、AVCドラフトに定義されるように、イントラ・スライスまたはSIスライスのみで構成される瞬時復号更新(IDR)ピクチャの符号化済みスライスの映像データを含む。一般に、IDRピクチャは、イントラ予測のみを用いて、またはイントラ予測および予測サンプルの量子化を用いて符号化される。さらに、NALユニット1は、その他のピクチャ、3DVレイヤまたは3DVビューを参照することができる双方向(B)符号化済みピクチャまたは予測(P)符号化済みピクチャなどの非IDRピクチャの符号化済みスライスの映像データを含む。NALユニット20は、例えば図10に示すように別のレイヤを参照する、または別の3DVビューを参照することができる符号化済みスライス拡張である。また、図11に示すNALユニット1、5および20は、このような多くのユニットを表しており、示しやすいように省略されていることにも留意されたい。例えば、2Dビュー1118のプレフィックス・ユニット16および14を伝送した後で、対応するフレームの全てのスライスが送信されるまで、いくつかのNALユニット5(1130)を伝送することができる。同様に、奥行きビューのプレフィックスNALユニット16を伝送した後で、奥行きレイヤ・フレームを構成する複数のNALユニット20を伝送することができる。図11に示すNALユニット1も、同様に、2Dビュー・レイヤ1136のフレームに対応するスライスの省略された表現である。
各NALユニット14は、上述のように、それが対応するレイヤのMVCビューIDを示すプレフィックスNALユニットである。例えば、NALユニット14は、それが対応する2Dビュー・レイヤ1118のMVCビューIDを含む。同様に、NALユニット20も、それが対応する3DVレイヤのMVCビューIDを含む。この実施形態では、あらゆる3DVレイヤは、別個のMVCビューとして符号化されるので、その符号化中に一意的なMVC view_idが割り当てられる。上述のエンコーダ300などのエンコーダは、以下の実施形態5〜7でさらに述べるように、MVC view_idを使用して、シーケンス・パラメータ・セット(SPS)中の複数のレイヤ間および/またはフレーム間の依存関係を示すことができ、デコーダ400などのデコーダが3DVプレフィックスNALユニットを用いて正しくフレームを解釈して復号することができるように、プレフィックスNALユニット16中の対応する3dv_view_idおよび3dv_layer_idを指定することができる。
例えば、各3DVレイヤのMVC view_idを、表5のように設定することができる。従って、実施形態1のアーキテクチャでは、4に等しいMVC view_idを有する任意のNALユニットより、2として設定される3dv_view_idおよび0として設定される3dv_layer_idを有するプレフィックスNALユニット16が先にならなければならない。ここで割り当てられた実際の値は、任意の値であり、異なるパースペクティブまたは視点にそれぞれ対応する異なる3DVビューが一意的に識別され、それらが対応する3DVレイヤが適切に識別され伝達される限り、変化させることができる。また、表5の値は、時間が異なっても一貫していることにも留意されたい。例えば、ビュー1104および1112は、同じMVCビュー、3DVビューおよび3DVレイヤIDを共有する。
実施形態1で定義されるビットストリームは、MVC互換性があり、全ての3DVビューおよびその全てのレイヤを従来のMVCデコーダで復号することができることを理解されたい。従って、3DVプレフィックスNALユニット16により、MVC互換デコーダは、3DV補足レイヤも含めて伝送された全ての3DVレイヤを復号することができる。しかし、従来のMVCデコーダでは復号したデータがどのようにして3DVフォーマットに構成されているかが分からないが、NALユニット16を使用することにより、実施形態による符号化レベルにおける3DVビューおよびレイヤの同期が可能になる。例えば、図3に示すエンコーダ300の3DV参照バッファ316は、上記に開示した教示によれば、ビットストリーム318中に適当な3DVプレフィックス・ユニットを含むことができ、図4のデコーダ400の3DV参照バッファ414は、ビットストリーム318中のNALユニットを解釈することができ、従って、それらのNALユニットを用いて、上記の図10および図11で説明した構造に一致するように3DVコンテンツを構築してフォーマット化することができる。
3DVビューのあらゆる2Dビュー・レイヤをMVCに従って従来のMVCデコーダによって復号し、フォーマット化することができるので、MVC後方互換性が実現されることに留意されたい。ただし、奥行きレイヤおよびその他の3DV補足レイヤはそれら自体の一意的なMVCビューIDを含むので、3DV補足レイヤは、別個のMVCビューとしてMVCデコーダによって解釈される。従って、3DV補足レイヤがMVCに従ってフォーマット化され、表示された場合には、表示画像は、通常は3次元効果を有していない。従って、ユーザは、可視の3D画像が提示されるまで、MVCビューを探索して、その表示を試みることができる。ここで、2つの2Dビュー・レイヤが選択/表示されて、ユーザの各目に対して提示されれば、可視の3Dビューが提示されることになる。
さらに、ユーザのディスプレイが例えば実施形態1を用いて伝送された3DV補足レイヤを受け入れて3D画像を生成するように構成されていれば、ユーザが3D画像を見ることができることもある。例えば、ユーザのディスプレイが、LDVフォーマット入力を受け入れ、その入力から3D画像を生成できることがある。このような場合には、ユーザは、例えばユーザのディスプレイにおいて、入力がLDVフォーマットであることを示すモードを選択することができる。
[実施形態2:3DVにおけるMVC view_idの再利用]
実施形態2では、実施形態1の代替の実施態様として、NALユニット・ヘッダにおける新規の符号化および復号プロセスが提案される。ここで、上記の実施形態1で述べた詳細は、3DVプレフィックスNALユニット16の使用を避けるようにMVC view_idを含む具体的なナンバリング方法を利用することを除けば、実施形態2にも当てはまる。例えば、MVC view_idは10ビットを有するように定義されるので、MVC view_idの最下位の3ビットで3dv_layer_idを示すことができ、MVC view_idの最上位の7ビットで3dv_view_idを示すことができる。その結果、表5のMVC view_idは、以下の表6に示すように設定することができる。従って、図11に示す3DVコンテンツは、実施形態2ではNALユニット16が存在せず、デコーダが表6を記憶し、これを使用して、ビットストリーム中の抽出したMVCビューIDを3DVビューIDおよび3DVレイヤIDに対して相互参照することにより、これらの抽出したMVCビューIDから3DVビューIDおよび3DVレイヤIDを決定することを除けば、実施形態2でも同じである。従って、NALプレフィックス・ユニット14および/またはNALユニット20は、MVCビューIDを含むナンバリング方法に従って構成することができる。ここで、上記のように、MVCビューIDを利用して、3DVビューIDおよび3DVレイヤIDを伝達して、符号化レベルでの3DVコンテンツの同期およびフォーマット化を可能にすることができる。
[実施形態3:3DV NALユニット拡張]
実施形態1および2では、特定のMVC符号化技術を使用して全ての3DVレイヤを符号化したので、全ての3DVレイヤを従来のMVCデコーダで復号することができた。しかし、現在のMVC規格を実施する従来のMVCデコーダは、上述したように、様々な3DVレイヤのそれぞれを3DVフォーマットに構成するわけではない。実施形態3では、現在のMVC規格に含まれない、特定の3DVビューおよび/または特定の3DVレイヤに適用することができる追加の符号化技術の導入を可能にする、符号化フレームワークを提案する。
この目的を達成するために、上記の表2に示すように、本明細書では「21」と呼ぶ、新規のNALユニット・タイプを利用することができる。NALユニット16と同様に、この実施形態3の新規のNALユニットに対して選択した参照番号は、表3のAVCドラフトで予約済みとされている任意の番号とすることができる。ここで、MVCデコーダによって復号する必要のない任意の3DVビューおよび/または3DVレイヤは、3DVコンテンツを復号するためにNALユニット・タイプ21を使用することができる。さらに、MVCデコーダによって復号し、適切に解釈することができる全ての2Dビュー・レイヤは、上記のように、1、5および20など、従来のNALユニット・タイプで符号化することができる。これらを、MVC互換2Dビューと呼ぶ。MVC互換2Dビューより先に、実施形態1で述べたNALユニット16などの3DVプレフィックスNALユニットがあってもよい。あるいは、実施形態2で述べたように、3DVプレフィックスNALユニットを避けるように、MVC view_idのナンバリング方法を指定してもよい。
以下の表7に示すAVCドラフトのMVC NALユニット・ヘッダ拡張と同様に、新規の3DV NALユニット・ヘッダ拡張を提案し、以下の表8に示す。
表7および表8に示すように、3DV NALユニット・ヘッダ拡張は、MVC NALユニット・ヘッダ拡張のview_idのシンタックス要素が、3DV NALユニット・ヘッダ拡張では2つのシンタックス要素3dv_view_idおよび3dv_layer_idで置き換えられていることを除けば、MVC NALユニット・ヘッダ拡張と同じシンタックス要素を含むことができる。ここで、実施形態3では、3dv_view_idは、関連するフレームの3DVビューID番号を指定する。同じビュー位置からの複数の3DVビュー・レイヤの間では、同じ3dv_view_idが共有される。また、3dv_layer_idは、関連するフレームの3DVレイヤID番号を指定する。nal_unit_header_3dv_extension()の呼出しを、以下の表9に示す。
ここでは、If(nal_unit_type==21){...}の記述が、AVCドラフトに記載されているNALユニット・シンタックスに追加されている。
実施形態3によるNALユニット・ストリーム1200の一例を、この新たなNALユニット・タイプ21を利用する図12に示す。ここで、view_idのナンバリングがNALユニット・ヘッダ構文解析プロセスで指定されるので、3DVプレフィックスNALユニット・タイプを使用することが回避される。NALユニット・ストリーム1200は、図10に示す3DVコンテンツの例に実施形態3を適用した例である。上述のように、3DVビュー間および3DVレイヤ間の依存関係、ならびに使用する3DVレイヤは、実施態様に応じて様々に変更することができる。
ストリーム1100と同様に、ストリーム1200は、異なる時間に対して異なるセットのビューを含むことができ、ビュー1204、1206および1208は、T0(1202)に対応し、ビュー1212、1214および1216は、時点T1(1210)に対応する。ビュー1204およびビュー1212(3DVビュー0)は、ベース・ビュー1002と同じパースペクティブまたは視点に関連付けられているので、それぞれ時点T0およびT1におけるベース・ビュー1002に対応する。同様に、ビュー1206およびビュー1214(3DVビュー2)は、それぞれ時点T0およびT1におけるPビュー1006に対応し、ビュー1208およびビュー1216(3DVビュー1)は、それぞれ時点T0およびT1におけるBビュー1004に対応する。各3DVビューは、2Dビュー・レイヤおよび奥行きレイヤで構成される。ストリーム1100の場合と同様に、その他の実施形態でも追加の補足レイヤを利用することができることを理解されたい。ビュー1204は、2Dビュー・レイヤ1218および奥行きレイヤ1220で構成される。2Dビュー・レイヤ1218は、NALユニット14(1226)およびNALユニット5(1230)で構成され、奥行きレイヤ1220は、NALユニット21(1230)で構成される。さらに、ビュー1206は、NALユニット20を含む2Dビュー1222、およびNALユニット21で構成される奥行きビュー1224で構成される。さらに、ビュー1212の2Dビュー1236は、NALユニット14およびNALユニット1で構成される。
NALユニット1、5、14および20については、図11を参照して上記で述べた。NALユニット14および20が、表7のMVC NALユニット・ヘッダ拡張を使用するのに対して、NALユニット21は、表8の3DV NALユニット・ヘッダ拡張を利用する。この新規の3DV NALユニット・ヘッダ拡張を使用することにより、新たな符号化方法の適用を可能にしながら、符号化レベルで3DVレイヤを3DVコンテンツ・フォーマットに同期させることが可能になる。NALユニット16とは異なり、NALユニット21は、対応する映像データのペイロードを含むことができる。より一般的には、このペイロードは、ピクチャ・データを含むことができる。このピクチャ・データは、一般に、対応する符号化済みピクチャのデータを指す。ピクチャ・データは、例えば2D映像レイヤ、奥行きレイヤ、隠蔽映像レイヤ、隠蔽奥行きレイヤまたは透明度レイヤなど、任意のレイヤからのものとすることができる。
また、図11と同様に、図12の矢印も、NALユニットの伝送順序を示していることに留意されたい。さらに、図12に示すNALユニット1、5、20および21は、図11に示すNALユニット1、5および20の省略と同じ方法で省略が施される。さらに、実施形態3は、従来のデコーダで2Dビュー・レイヤを復号し、MVCに従って結合して、3Dコンテンツの生成および表示を可能にするので、MVC互換性がある。
次に、図13および図14を参照すると、実施形態3による、3DVコンテンツ・ストリームを復号する方法1300および符号化する方法1400が、それぞれ示してある。方法1300は、図4のデコーダ400が実行し、その内部で実施することができ、方法1400は、図3のエンコーダ300が実行し、その内部で実施することができることを理解されたい。方法1300および1400は両方とも、上述の表9に示すシンタックスを利用する。
方法1300は、ステップ1302から開始することができ、ステップ1302では、デコーダ400が、上記の表9およびAVCドラフトに記載される、受信したNALユニットのnal_ref_idcを読み取ることができる。
ステップ1304で、デコーダ400は、NALユニット・タイプを読み取ることができる。
ステップ1306で、デコーダ400は、NALユニット・タイプが14であるかどうかを判定することができる。NALユニット・タイプが14である場合には、デコーダ400は、ステップ1308に進み、現在処理しているNALユニットの残りの部分を構文解析して、MVCビューIDを取得することができる。実施形態3のこの特定の実施態様では、3DVビューIDおよび3DVレイヤIDは、実施形態2で上述したように、例えば、MVCビューIDで示される。
従って、ステップ1310で、デコーダ400は、例えば実施形態2で上述したように、MVCビューIDから3DVビューIDおよび3DVレイヤIDを取得することができる。
ステップ1312で、デコーダ400は、受信した次のNALユニットを読み取り、これを構文解析することができる。この次のNALユニットは、タイプ1またはタイプ15の何れかでなければならない。従って、この次のNALユニットがタイプ1またはタイプ15ではないとデコーダが判定した場合には、エラーが生じている。
ステップ1314で、デコーダ400は、現在処理しているNALユニットの現在のスライス・データを復号することができる。
ステップ1316で、デコーダ400は、この処理済みのNALユニットが現在のフレームの末尾に対応するかどうかを判定することができる。この処理済みのNALユニットが現在のフレームの末尾に対応しない場合には、デコーダ400は、ステップ1312〜1316を繰り返すことができる。
現在のフレームの末尾に達した後で、この方法は、ステップ1318に進むことができ、このステップで、デコーダ400は、復号済みのフレームを、その3DVビューIDおよびその3DVレイヤIDとともに、例えば3DV参照/出力バッファ414などのその出力バッファに送信することができ、このバッファは、このフレームを、上述のように、表示するための3DVフォーマットに構成することができる。
ステップ1320で、デコーダ400は、ビットストリームまたはシーケンスの末尾に達したかどうかを判定することができる。ビットストリームまたはシーケンスの末尾に達していない場合には、この方法は、ステップ1302に進むことができ、デコーダ400は、方法1300を繰り返すことができる。ビットストリームまたはシーケンスの末尾に達している場合には、方法1300は終了することができる。
ステップ1306に戻って、デコーダ400が、現在処理しているNALユニットのNALユニット・タイプがタイプ14ではないと判定した場合には、この方法は、ステップ1322に進むことができ、このステップで、デコーダ400は、現在処理しているNALユニットのNALユニット・タイプが20であるかどうかを判定することができる。現在処理しているNALユニットがタイプ20である場合には、この方法は、ステップ1324に進むことができ、このステップで、デコーダ400は、現在処理しているNALユニットの残りの部分を構文解析して、MVCビューIDを取得することができる。実施形態3のこの特定の実施態様では、3DVビューIDおよびその3DVレイヤIDは、例えば実施形態2で上述したように、MVCビューIDで示される。
従って、ステップ1326で、デコーダ400は、例えば実施形態2で上述したように、MVCビューIDから3DVビューIDおよび3DVレイヤIDを取得することができる。
ステップ1328で、デコーダ400は、現在処理しているNALユニットの現在のスライス・データを復号することができる。
ステップ1330で、デコーダ400は、処理済みのNALユニットが現在のフレームの末尾に対応するかどうかを判定することができる。処理済みのNALユニットが現在のフレームの末尾に対応しない場合には、この方法はステップ1332に進むことができ、このステップで、デコーダ400は、受信した次のNALユニットを読み取り、これを構文解析することができる。次のNALユニットは、タイプ20でなければならない。従って、次のNALユニットがタイプ20ではないとデコーダが判定した場合には、エラーが生じている。その後、デコーダ400が、ステップ1326〜1330を繰り返すことができる。
ステップ1330で、デコーダ400が、現在のフレームの末尾に達していると判定した場合には、この方法は、ステップ1318に進むことができ、このステップで、デコーダ400は、上述のように、復号済みのフレームを、その3DVビューIDおよびその3DVレイヤIDとともに、その出力バッファに送信することができる。その後、この方法は、ステップ1320に進むことができ、上述のように繰り返す、または終了することができる。
ステップ1322に戻って、デコーダ400が、現在処理しているNALユニットがタイプ20ではないと判定した場合には、この方法は、ステップ1334に進むことができ、このステップで、デコーダは、現在処理しているNALユニットがタイプ21であるかどうかを判定する。現在処理しているNALユニットがタイプ21である場合には、この方法は、ステップ1336に進むことができ、このステップで、デコーダ400は、現在処理しているNALユニットの残りの部分を構文解析し、3DV NALユニット・ヘッダ拡張によって与えられる3DVビューIDおよび3DVレイヤIDを取得することができる。
ステップ1338で、デコーダ400は、現在処理しているNALユニットの現在のスライス・データを復号することができる。
ステップ1340で、デコーダ400は、処理済みのNALユニットが現在のフレームの末尾に対応するかどうかを判定することができる。処理済みのNALユニットが現在のフレームの末尾に対応しない場合には、この方法は、ステップ1342に進むことができ、このステップで、デコーダ400は、受信した次のNALユニットを読み取り、これを構文解析することができる。この次のNALユニットは、タイプ21でなければならない。従って、この次のNALユニットがタイプ21ではないとデコーダが判定した場合には、エラーが生じている。その後、デコーダ400が、ステップ1338〜1340を繰り返すことができる。
ステップ1340で、現在のフレームの末尾に達しているとデコーダ400が判定した場合には、この方法は、ステップ1318に進むことができ、このステップで、デコーダ400は、上述のように、復号済みのフレームを、その3DVビューIDおよびその3DVレイヤIDとともに、その出力バッファに送信することができる。その後、この方法は、ステップ1320に進むことができ、上述のように繰り返す、または終了することができる。
ステップ1334に戻って、デコーダ400がステップ1334で、現在処理しているNALユニットがタイプ21ではないと判定した場合には、この方法は、ステップ1344に進むことができ、このステップで、現在処理しているNALユニットの残りの部分が構文解析される。この構文解析は、シーケンス・パラメータ・セット(SPS)、ピクチャ・パラメータ・セット(PPS)またはその他の目的を対象とすることができる。その後、この方法は、ステップ1320に進むことができ、上述のように繰り返す、または終了することができる。
再度図14を参照すると、実施形態3によって3DVコンテンツ・ストリームを符号化する方法1400はステップ1402から開始することができ、ステップ1402ではエンコーダ300がその構成プロフィルを読み取ることができる。
ステップ1404で、エンコーダ300は、SPSおよび/またはPPS NALユニットを書き込むことができる。
ステップ1406で、エンコーダ300は、次に符号化するフレームを読み取ることができる。
ステップ1408で、エンコーダ300は、現在処理しているフレームがAVC互換ビューとなるかどうかを判定することができる。現在処理しているフレームがAVC互換ビューとなる場合には、この方法は、ステップ1410に進むことができ、このステップで、エンコーダ300は、現在のフレームの次のスライスを符号化することができる。
ステップ1412で、現在のフレームの現在処理しているスライスが現在のフレームの最初のスライスであるとエンコーダ300が判定した場合には、エンコーダ300は、例えばNALユニット・タイプ14のMVCプレフィックスNALユニットを書き込むことができる。
ステップ1414で、エンコーダ300は、現在のスライスを、タイプ1または5のNALユニットなどのNALユニットにカプセル化することができる。
ステップ1416で、エンコーダ300は、ステップ1414で現在のスライスがカプセル化されたNALユニットを書き込むことができる。
ステップ1418で、エンコーダ300は、現在のフレームの末尾に達したかどうかを判定することができる。エンコーダが現在のフレームの末尾に達していない場合には、この方法は、ステップ1410に進むことができ、エンコーダ300は、ステップ1410〜1418を繰り返すことができる。エンコーダが現在のフレームの末尾に達している場合には、この方法は、ステップ1420に進むことができ、このステップで、エンコーダ300は、1つのシーケンスまたはビットストリームの全てのフレームが処理されたかどうかを判定することができる。全てのフレームが処理されている場合には、この方法は、終了することができる。そうでない場合には、この方法は、ステップ1406に進むことができ、エンコーダは、ステップ1406〜1408を繰り返すことができる。
上記で述べたステップ1408に戻って、エンコーダ300が、現在処理しているフレームがAVC互換ビューである必要がないと判定した場合には、この方法は、ステップ1422に進むことができ、このステップで、エンコーダ300は、現在処理しているフレームがMVC互換ビューとなるかどうかを判定することができる。現在処理しているフレームがMVC互換ビューとなる場合には、この方法は、ステップ1424に進むことができ、このステップで、エンコーダ300は、現在処理しているフレームの次のスライスを符号化することができる。
ステップ1426で、エンコーダは、現在のスライスを、例えば20などのNALユニット・タイプのNALユニットにカプセル化することができる。
ステップ1428で、エンコーダ300は、ステップ1426で現在のスライスがカプセル化されたNALユニットを書き込むことができる。
ステップ1430で、エンコーダ300は、現在のフレームの末尾に達したかどうかを判定することができる。エンコーダが現在のフレームの末尾に達していない場合には、この方法は、ステップ1424に進むことができ、エンコーダ300は、ステップ1424〜1430を繰り返すことができる。エンコーダが現在のフレームの末尾に達している場合には、この方法は、ステップ1420に進むことができ、このステップで、エンコーダ300は、1つのシーケンスまたはビットストリームの全てのフレームが処理されたかどうかを判定することができる。全てのフレームが処理されている場合には、この方法は、終了することができる。そうでない場合には、この方法は、ステップ1406に進むことができ、エンコーダは、ステップ1406〜1408を繰り返すことができる。
ステップ1422に戻って、エンコーダ300が、現在処理しているフレームがMVC互換ビューである必要がないと判定した場合には、この方法は、ステップ1432に進むことができ、このステップで、エンコーダ300は、現在のフレームの次のスライスを符号化することができる。
ステップ1434で、エンコーダは、現在のスライスを、例えば21などのNALユニット・タイプのNALユニットにカプセル化することができる。
ステップ1436で、エンコーダ300は、ステップ1434で現在のスライスがカプセル化されたNALユニットを書き込むことができる。
ステップ1440で、エンコーダ300は、現在のフレームの末尾に達しているかどうかを判定することができる。エンコーダが現在のフレームの末尾に達していない場合には、この方法は、ステップ1432に進むことができ、エンコーダ300は、ステップ1432〜1440を繰り返すことができる。エンコーダが現在のフレームの末尾に達している場合には、この方法は、ステップ1420に進むことができ、このステップで、エンコーダ300は、1つのシーケンスまたはビットストリームの全てのフレームが処理されたかどうかを判定することができる。全てのフレームが処理されている場合には、この方法は、終了することができる。そうでない場合には、この方法は、ステップ1406に進むことができ、エンコーダは、ステップ1406〜1408を繰り返すことができる。
符号化ステップ1410、1424および1432、ならびに復号ステップ1314、1328および1338は、例えば図10および図12に関連して上述した実施形態の構造およびフィーチャへの準拠を可能にする様々な符号化方法および符号化規格に従って実行することができることを理解されたい。
さらに、3DVレイヤの新たなNALユニット・タイプ21を導入することで、異なる3DVレイヤに対して、それぞれの異なる特性を利用した特別な符号化技術を規定することができる。例えば、2Dビューの復号は、参照ピクチャ中で予測ブロックを発見するのに奥行きマップを用いている場合には、その奥行きマップの復号に依存することができる。さらに、その他のこのような依存性も、上述のように利用することができる。
また、新規のNALユニット・タイプ21を用いると、3DVビュー/レイヤを、表10に示すように、3dv_slice_layer_extension_rbsp()を用いて符号化することができることにも留意されたい。ここで、3dv_slice_header()および3dv_slice_data()は、修正したslice_header()およびslice_data()を含むことができる。
また、実施形態1〜3はそれぞれ別個に説明したが、本明細書に与える教示に鑑みて当業者には理解されるように、これらの実施形態のうちの1つまたは複数を様々な形態で組み合わせることもできることを理解されたい。例えば、同じフレームの様々なスライスを、様々な方法で符号化することができる。例えば、1つのフレームの特定のスライスを、実施形態1および/または2によるMVC互換性のある方法で符号化し、その他のスライスを、実施形態3による非MVC符号化モードを用いて符号化することもできる。さらに、例えば2Dビューなど、3DVビューの特定のレイヤを符号化するのに、実施形態1および/または2によるMVCを利用し、例えば隠蔽・ビューなど、3DVビューのその他のレイヤを符号化するのに、実施形態3による非MVCモードを適用することもできる。ここで、NALユニット16ならびにNALユニット1および/または5を、1つまたは複数の3DVビューの一部のレイヤに適用し、NALユニット21を、1つまたは複数の3DVビューのその他のレイヤに適用することもできる。
[実施形態4:参照ピクチャ・リストの構築]
上記に示したように、実施形態は、参照ピクチャ・リストの構築プロセスに関する場合もある。以下に述べる実施形態では、各ピクチャが、それ自体の参照ピクチャ・リストを有する。しかし、その他の実施態様では、複数のピクチャについて固有の(且つそれらのピクチャに対して使用される)参照ピクチャ・リストを提供することができる。例えば、1つの時間的なピクチャ・シーケンス全体に1つの参照ピクチャ・リストを割り当ててもよいし、所与の時点における複数のビューにまたがるピクチャ・セット全体に1つの参照ピクチャ・リストを割り当ててもよいし、あるいは1つのピクチャのサブセットに1つの参照ピクチャ・リストを割り当ててもよい。例えば、1つのピクチャのサブセットは、1つのスライス、あるいは1つのマクロブロックまたはサブマクロブロックで構成することができる。この参照ピクチャ・リスト構築プロセスの入力は、NALユニット・ヘッダからのinter_view_flag、およびシーケンス・パラメータ・セットから復号されたビュー依存関係情報である。図3のエンコーダ300および図4のデコーダ400はともに、以下に述べる教示を利用することにより、参照ピクチャ・リストを構築して、それぞれビットストリームを符号化/復号するように構成することができることを理解されたい。
このプロセスの第1のフェーズでは、例えばAVCシステムまたはMVCシステムで行うことがあるのと同様に、時間的参照ピクチャおよびビュー間参照ピクチャを、初期参照ピクチャ・リストRefPicListX(Xは0または1)に挿入することができる。AVCドラフトで定義されるRefPicListxは、初期参照ピクチャ・リストの一例として用いることができる。例えば、Xが0であるRefPicList0を、任意のタイプの予測符号化ピクチャの符号化または復号に使用し、Xが1であるRefPicList1を、双方向符号化ピクチャすなわちBピクチャの符号化または復号に使用することができる。従って、Bピクチャは、2つの参照ピクチャ・リストRefPicList0およびRefPicList1を有することができ、その他のタイプの予測符号化ピクチャは、1つのみの参照ピクチャ・リストRefPicList0を有することができる。さらに、ここでは、時間的参照は、参照リストが割り当てられた対応するピクチャと時間的に異なるピクチャを参照することに対応することにも留意されたい。例えば、図11を参照すると、時間的参照は、ビュー1112の符号化/復号のためにビュー1104を参照することに対応することができる。ビュー間参照は、ビュー1106の符号化/復号のために、ビュー1104を参照することに対応することができる。参照ピクチャ・リストに時間的参照ピクチャおよびビュー間参照ピクチャを挿入することにより、(例えばAVCおよび/またはMVCの)既存の時間的およびビュー間予測技術に対応することができる。既知の通り、AVCシステムが、時間的参照ピクチャを参照ピクチャ・リストに含み、MVCシステムが、さらにビュー間参照ピクチャを参照ピクチャ・リストに含むことになる。
このプロセスの第2のフェーズは、各レイヤごとに独立して定義することができるレイヤ間参照ピクチャを追加することを含むことができる。実施形態4の1つのレイヤ間予測構造1500を、図15に示す。構造1500中の矢印は、予測の方向を示している。例えば、ある特定のビューの2D映像(ビュー)レイヤ1502(そこから矢印が出る)は、当該ビューの奥行きレイヤ1504(そこに矢印が入る)の符号化の際の参照として使用される。従って、レイヤ間予測構造を使用して、どの1つまたは複数のピクチャを参照として使用することができるか、従って、どの1つまたは複数のピクチャが参照ピクチャ・リストに含まれていなければならないかを判定することができる。構造1500では、2D映像レイヤは、隠蔽映像レイヤ1506および透明度レイヤ1510の両方の参照としても使用される。さらに、奥行きレイヤ1504は、隠蔽奥行きレイヤ1508の参照として使用される。
図15に示すように、レイヤ間予測構造1500では、各3DVレイヤは、最大で1つしかレイヤ間参照を有していない。所与のレイヤを符号化するために、同様の特性を有するレイヤを、参照として使用する。例えば、再度図2を参照すると、隠蔽映像レイヤ206は、2D映像レイヤ202の背景を含み、隠蔽奥行きレイヤ208は、奥行きレイヤ204の背景を含む。従って、レイヤ間の冗長性をよりよく活用するために、いくつかの実施態様では、1つのビューの2D映像レイヤを、当該ビューの隠蔽・レイヤの参照として使用し、当該ビューの奥行きレイヤを、当該ビューの隠蔽奥行きレイヤの参照として使用することができる。その他の実施態様では、所与の3DVレイヤについて複数のレイヤ間参照を認めることができる。
2D映像レイヤ・ピクチャの実施態様では、レイヤ間参照を用いる必要がないので、2D映像レイヤ・ピクチャでは、第2のフェーズでは何もする必要がない。その他の実施形態では、実際には、2D映像レイヤのレイヤ間参照に備えることもできる。例えば、所与のビューの隠蔽レイヤは、当該ビューの2D映像レイヤの参照として使用することができる。2Dビュー・レイヤのレイヤ間参照を用いることを回避することの利点は、全ての2Dビュー・レイヤを従来のMVCデコーダで復号することができることである。なお、その他の実施態様では、例えば同期仮想参照ピクチャなどの歪み(warped)ピクチャを、参照リストに追加することもできることに留意されたい。参照リスト中の歪みピクチャ参照の位置に関しては、歪みピクチャ参照は、初期参照リストの先頭なら高い合成品質で挿入することができ、参照リストの末尾なら中程度の合成品質で挿入することができる。このように歪みピクチャを使用することにより、符号化効率を向上させることができる。
図15を参照すると、奥行きレイヤ・ピクチャ1504については、2D映像レイヤ・ピクチャ1502(図15では奥行きレイヤの参照として示す)を、第2のフェーズで、RefPicListXの末尾に追加することができる。様々な実施態様では、2D映像ピクチャ参照は、参照リストの先頭ではなく、参照リストの末尾に追加される。これは、冗長性が(第1のフェーズの時間的参照およびビュー間参照のうちの任意の参照と比較して)最小になると予想され、参照として使用される可能性が最も低くなると予想されるからである。従って、ここでは、参照ピクチャ・リスト中の任意の時間的参照およびビュー間参照の後に、レイヤ間参照を設ける。
隠蔽映像レイヤ・ピクチャ1506については、2D映像レイヤ・ピクチャ1502を、第2のフェーズで、RefPicListXの先頭に追加することができる。2D映像ピクチャは、参照ピクチャ・リストにおいて、いかなる時間的参照およびビュー間参照よりも前に、末尾や中間ではなく先頭に、追加する(先頭追加する)ことができる。これは、2D映像ピクチャが、利用可能な参照ピクチャとの冗長性が最大になり、参照として使用される可能性が最も高くなると予想されるからである。
隠蔽奥行きレイヤ・ピクチャ1508については、奥行きピクチャ1504を、第2のフェーズで、RefPicListXの先頭に、この参照ピクチャ・リスト中のいかなる時間的参照およびビュー間参照よりも前に、追加することができる。これは、隠蔽奥行きレイヤと奥行きレイヤとの間で(第1のフェーズの時間的参照およびビュー間参照のうちの任意の参照と比較して)高いレベルの冗長性が予想されるからである。
透明度レイヤ・ピクチャ1510については、2D映像レイヤ・ピクチャ1502を、第2のフェーズで、RefPicListXの末尾に、この参照ピクチャ・リスト中のいかなる時間的参照およびビュー間参照よりも後に、追加することができる。これは、透明度レイヤと2D映像レイヤとの間で(第1のフェーズの時間的参照およびビュー間参照のうちの任意の参照と比較して)低いレベルの冗長性が予想されるからである。
より一般的には、あるピクチャのレイヤ間参照は、当該参照がどの程度の頻度で使用されるかによって決まる位置で、当該ピクチャの参照ピクチャ・リストに挿入することができる。各参照に優先順位が割り付けられる実施態様では、優先順位は、参照がどの程度の頻度で使用されるかに基づいて割り付けることができる。例えば、1つの実施態様では、ピクチャをマクロブロック単位で符号化し、各マクロブロックは、参照ピクチャ・リストの所与の参照を使用することもあれば、使用しないこともある。この実施態様の各マクロブロックごとに、様々な符号化モードや様々な参照も含む様々な符号化オプションの間で、レート/歪み最適化を実行する。従って、ピクチャのマクロブロックのサブセットの符号化において、所与のレイヤ間参照のみが使用されることもある。所与のレイヤ間参照に割り付けられる優先順位は、何個のマクロブロックが参照ピクチャ・リスト中の利用可能なその他の参照を使用するかと比較して、何個のマクロブロックが当該レイヤ間参照を使用するかに基づいて決定することができる。
次に、図16および図17を参照すると、符号化プロセスのための参照ピクチャ・リストを構築する方法1600、および復号プロセスのための参照ピクチャ・リストを構築する方法1700が、それぞれ示してある。実施形態4の一実施態様による符号化プロセスのための参照ピクチャ・リストを構築する方法1600は、図3のエンコーダ300によって実行することができる。例えば、3DV参照バッファ316は、方法1600を実施するように構成することができる。
方法1600は、ステップ1602から開始することができ、このステップで、エンコーダ300は、参照ピクチャ・リストRefPicListXを初期化することができる。上述のように、RefPicListXは、Xが0であっても1であっても、AVCドラフトに従って初期化することができる。例えば、上記に示したように、時間的参照ピクチャおよび/またはビュー間参照ピクチャを、初期参照ピクチャ・リストに挿入することができる。
ステップ1604で、エンコーダ300は、参照ピクチャ・リストが2D映像レイヤ・ピクチャ用のものであるかどうかを判定することができる。参照ピクチャ・リストが2D映像レイヤ・ピクチャ用のものである場合には、この方法は、ステップ1622に進むことができ、このステップで、エンコーダ300は、現在処理しているスライスの符号化を継続することができる。その後、この方法は、終了する、または反復して別の3DVレイヤ・ピクチャ用の参照ピクチャ・リストを構築することができる。あるいは、3DVレイヤ・ピクチャがBピクチャである場合には、この方法は、同じ3DVレイヤ・ピクチャについて反復して、RefPicList1を構築することができる。
ステップ1604で、エンコーダ300が、参照ピクチャ・リストが2D映像レイヤ・ピクチャ用のものではないと判定した場合には、この方法は、ステップ1606に進むことができ、このステップで、エンコーダ300は、参照ピクチャ・リストが奥行きレイヤ・ピクチャ用のものであるかどうかを判定することができる。参照ピクチャ・リストが奥行きレイヤ・ピクチャ用のものである場合には、この方法は、ステップ1608に進むことができ、このステップで、奥行きレイヤ・ピクチャと同じ3Dビューからの2D映像レイヤ・ピクチャを、参照ピクチャ・リストの末尾に追加する。その後、この方法は、ステップ1622に進むことができ、このステップで、エンコーダ300は、現在処理しているスライスの符号化を継続することができる。その後、この方法は、終了する、または反復して別の3DVレイヤ・ピクチャ用の参照ピクチャ・リストを構築することができる。あるいは、3DVレイヤ・ピクチャがBピクチャである場合には、この方法は、同じ3DVレイヤ・ピクチャについて反復して、RefPicList1を構築することができる。
ステップ1606で、エンコーダ300が、参照ピクチャ・リストが奥行きレイヤ・ピクチャ用のものではないと判定した場合には、この方法は、ステップ1610に進むことができ、このステップで、エンコーダ300は、参照ピクチャ・リストが隠蔽映像レイヤ・ピクチャ用のものであるかどうかを判定することができる。参照ピクチャ・リストが隠蔽映像レイヤ・ピクチャ用のものである場合には、この方法は、ステップ1612に進むことができ、このステップで、隠蔽映像レイヤ・ピクチャと同じ3Dビューからの2D映像レイヤ・ピクチャを、参照ピクチャ・リストの先頭に追加する。その後、この方法は、ステップ1622に進むことができ、このステップで、エンコーダ300は、現在処理しているスライスの符号化を継続することができる。その後、この方法は、終了する、または反復して別の3DVレイヤ・ピクチャ用の参照ピクチャ・リストを構築することができる。あるいは、3DVレイヤ・ピクチャがBピクチャである場合には、この方法は、同じ3DVレイヤ・ピクチャについて反復して、RefPicList1を構築することができる。
ステップ1610で、エンコーダ300が、参照ピクチャ・リストが隠蔽映像レイヤ・ピクチャ用のものではないと判定した場合には、この方法は、ステップ1614に進むことができ、このステップで、エンコーダ300は、参照ピクチャ・リストが隠蔽奥行きレイヤ・ピクチャ用のものであるかどうかを判定することができる。参照ピクチャ・リストが隠蔽奥行きレイヤ・ピクチャ用のものである場合には、この方法は、ステップ1616に進むことができ、このステップで、隠蔽奥行きレイヤ・ピクチャと同じ3Dビューからの奥行きレイヤ・ピクチャを、参照ピクチャ・リストの先頭に追加する。その後、この方法は、ステップ1622に進むことができ、このステップで、エンコーダ300は、現在処理しているスライスの符号化を継続することができる。その後、この方法は、終了する、または反復して別の3DVレイヤ・ピクチャ用の参照ピクチャ・リストを構築することができる。あるいは、3DVレイヤ・ピクチャがBピクチャである場合には、この方法は、同じ3DVレイヤ・ピクチャについて反復して、RefPicList1を構築することができる。
ステップ1614で、エンコーダ300が、参照ピクチャ・リストが隠蔽奥行きレイヤ・ピクチャ用のものではないと判定した場合には、この方法は、ステップ1618に進むことができ、このステップで、エンコーダ300は、参照ピクチャ・リストが透明度レイヤ・ピクチャ用のものであるかどうかを判定することができる。参照ピクチャ・リストが透明度レイヤ・ピクチャ用のものである場合には、この方法は、ステップ1620に進むことができ、このステップで、透明度レイヤ・ピクチャと同じ3Dビューからの2D映像レイヤ・ピクチャを、参照ピクチャ・リストの末尾に追加する。その後、この方法は、ステップ1622に進むことができ、このステップで、エンコーダ300は、現在処理しているスライスの符号化を継続することができる。その後、この方法は、終了する、または反復して別の3DVレイヤ・ピクチャ用の参照ピクチャ・リストを構築することができる。あるいは、3DVレイヤ・ピクチャがBピクチャである場合には、この方法は、同じ3DVレイヤ・ピクチャについて反復して、RefPicList1を構築することができる。同様に、ステップ1618で、エンコーダ300が、レイヤが透明度レイヤ・ピクチャではないと判定した場合には、この方法は、ステップ1622に進むことができ、このステップで、エンコーダ300は、現在処理しているスライスの符号化を継続することができる。その後、この方法は、終了する、または反復して別の3DVレイヤ・ピクチャ用の参照ピクチャ・リストを構築することができる。あるいは、3DVレイヤ・ピクチャがBピクチャである場合には、この方法は、同じ3DVレイヤ・ピクチャについて反復して、RefPicList1を構築することができる。
次に、図17に示す方法1700を参照すると、実施形態4の一実施態様による復号プロセスのための参照ピクチャ・リストを構築する方法1700は、図4のデコーダ400によって実行することができる。例えば、3DV参照/出力バッファ414は、方法1700を実行するように構成することができる。
方法1700は、デコーダ400が受信したNALユニットおよびスライス・ヘッダを構文解析して3DVレイヤ・ヘッダを抽出することができるステップ1702から開始することができる。例えば、NALユニットは、上記の実施形態1で述べた3DVプレフィックス・ユニット16、実施形態2のNALプレフィックス・ユニット14および/またはNALユニット20、ならびに/あるいは実施形態3のNALユニット21とすることができる。さらに、上述のように、デコーダ400が受信した3DVコンテンツを含むビットストリームからデコーダ400が抽出することができるその他の情報としては、NALユニット・ヘッダのinter_view_flagおよびシーケンス・パラメータ・セットから復号したビュー依存関係情報などが挙げられる。その後、参照ピクチャ・リストRefPicListXを初期化することができる。上述のように、RefPicListXは、Xが0であっても1であっても、AVCドラフトに従って初期化することができる。例えば、上記に示したように、NALユニット・ヘッダのinter_view_flagおよびシーケンス・パラメータ・セットから復号したビュー依存関係情報を利用して、RefPicListXを初期化することができる。時間的参照ピクチャおよび/またはビュー間参照ピクチャは、初期参照ピクチャ・リストに挿入することができる。
方法1700の残りのステップは、ステップ1622をステップ1722で置き換えることを除けば、方法1600に関連して上述したのと同様に、デコーダ400によって実行することができる。例えば、ステップ1704〜1720は、エンコーダ300がステップ1604〜1620を実行したのと同様に、デコーダ400によって実行することができる。しかし、ステップ1722では、現在処理しているスライスを符号化するのではなく、デコーダは、現在処理しているスライスの復号を継続する。
図15を参照して上述した以外のレイヤ間依存関係を有するレイヤ間予測構造も、当業者なら、実施形態4に関連して上記に与えた教示を用いて容易に考えつくことができることを理解されたい。
従って、実施形態4は、様々なタイプのレイヤ間予測に対応することができる。さらに、実施形態4は、例えば15を参照して上述した構造などのレイヤ間予測構造に参照ピクチャ・リストを適合させる。その結果、実施形態4は、システムのレイヤ間予測構造に基づく参照ピクチャ・リストを提供すると同時に、従来のMVCデコーダが3DVコンテンツを抽出し、当該コンテンツを表示用にフォーマット化することができるようにする。
なお、参照ピクチャは、AVCシステムとの互換性を有するように構成することができることに留意されたい。例えば、レイヤ間参照ピクチャおよびビュー間参照ピクチャを、時間的に異なるピクチャとして多重化することができる。
[実施形態5:サブセットSPS 3DVの新規のNALユニット・タイプ]
上記に示したように、少なくとも1つの実施形態では、3DVフォーマットの新たなシーケンス・パラメータを信号通信することができるようにSPSを拡張することができる。この3DV用の拡張SPSを、以下では「サブセットSPS 3DV」と呼ぶ。実施形態5では、このサブセットSPS 3DV用の新規のNALユニット・タイプを利用することができる。以下に述べる実施形態6および7では、サブセットSPS 3DVを構成することができる方法について述べる。提案するパラメータは、SPS内に限定されるわけではなく、NALユニット・ヘッダ、ピクチャ・パラメータ・セット(PPS)、補足エンハンスメント情報(SEI)、スライス・ヘッダ、およびその他の任意の高レベル・シンタックス要素にも見ることができることを理解されたい。いくつかの実施形態では、低レベル・シンタックスおよび帯域外情報を使用することもできる。
ここで、実施形態5では、新規のNALユニット・タイプを使用して、サブセットSPS 3DVを示すことができる。この実施形態におけるNALユニット・タイプの番号は、上述のようにAVCドラフトから転記した上記の表3で割り当てられていない値の任意の1つとすることができる。さらに、3DVレイヤのVCL NALユニットに割り当てられた新規のNALユニット・タイプ番号も、実施形態1および3に関連して上述した新規のNALユニット・タイプとは異なる方法で選択しなければならない。その結果、サブセットSPS 3DV用のNALユニット・タイプ番号として、17が選択され、これは、以下の表11ではsubset_seq_parameter_set_3dv_rbsp()として表される。もちろん、その他のNALユニット・タイプ番号を選択してもよい。実施形態を組み合わせない場合には、17の代わりに、NALユニット・タイプ16または21を使用することもできる。nal_unit_type17の行およびnal_unit_type18…20の行は、上記の表2に新たに追加したものである。
新規のNALユニット・タイプにより、MVCデコーダまたは3DVデコーダが、サブセットSPS 3DV内のコンテンツを廃棄するか構文解析するかを判定できるようにすることができる。タイプ17はMVCでは予約済みであるので、MVCデコーダは、このNALユニットのデータを無視または廃棄することを選択することができる。しかし、3DVデコーダは、このユニットのデータを構文解析することができ、これにより、3DVデコーダは、3DV補足レイヤを復号することが可能になる。
例えばルータなど、新規のNALユニット・タイプを認識することができるスマート・ネットワーク・デバイスの場合、特定の状況下では3DV補足レイヤを伝送してはならないとネットワーク・プロバイダが決定している場合には、サブセットSPS 3DVを廃棄することを選択することもできる。あるいは、またはこれに加えて、サブセットSPS 3DVのコンテンツを構文解析し、これを利用して、ストリーミングを利用可能なネットワーク帯域幅に適合させることもできる。例えば、3DVレイヤ予測構造に関する知識があれば、ネットワーク・デバイス(例えばストリーミング・サーバまたはルータ)は、ネットワークにバースト・トラフィックが発生しているときに、参照として使用されていない3DVレイヤを廃棄することができる。
ストリーム・サーバとも呼ばれるビットストリーム抽出器を使用して、3DVストリームの様々な部分を抽出することもできる。上記のルータは、ビットストリームを構文解析し、様々な3DVレイヤを転送(伝送)するか否かについて判定を下した。ビットストリーム抽出器も、ビットストリームを構文解析し、優先順位に基づいて転送に関する判定を下すことができるが、抽出したビットストリーム(サブ・ビットストリームとも呼ぶ)を、下流側のデバイスに合わせて調整することもできる。例えば、ビットストリーム抽出器は、下流側の受信器が隠蔽レイヤまたは透明度レイヤを使用していないという理由で、2D映像レイヤおよび奥行きレイヤのみを抽出することもできる。さらに、ビットストリーム抽出器は、下流側の受信器が2つを超えるビューを使用していないという理由で、ビットストリーム中の最初の2つのビューに対応するレイヤのみを抽出することもできる。ただし、これに加えて、ビットストリーム抽出器は、3DV SPSならびに任意のMVC SPSまたはその他の依存関係情報を分析して、2D映像レイヤまたは奥行きレイヤが隠蔽レイヤまたは透明度レイヤの何れかをレイヤ間参照として使用しているかどうかを判定し、且つ最初の2つのビューがその他のビューの何れかをビュー間参照として使用しているかどうかを判定することができる場合もある。所望の3DVレイヤ、すなわち最初の2つのビューの2D映像レイヤおよび奥行きレイヤを適切に復号するためにその他のレイヤまたはビューが必要な場合には、ビットストリーム抽出器は、それらのレイヤおよび/またはビューも抽出することになる。
なお、3DVレイヤおよび3DVビューの優先順位情報は、ルータまたはビットストリーム抽出器が決定することができることに留意されたい。ただし、このような優先順位情報は、例えばNALユニット・ヘッダ中に配置することによって、ビットストリーム中に与えることもできる。このような優先順位情報としては、例えば、時間的レベルID、優先順位ID、ビューID、および3DV情報に関連する優先順位IDなどが挙げられる。
次に、図18および図19を参照すると、実施形態5の実施態様によってサブセットSPS 3DV情報のNALユニットを符号化する方法1800、およびそれを復号する方法1900が、それぞれ示してある。方法1800は、例えば、エンコーダ300の3DV参照バッファ316によって実行することができ、方法1900は、例えば、デコーダ400の3DV参照バッファ414によって実行することができる。
方法1800は、例えば、エンコーダ300がNALユニットのNALユニット・タイプを17に設定することができるステップ1802から開始することができる。ステップ1804で、エンコーダ300は、NALユニット・ヘッダを書き込むことができる。その後、ステップ1806で、エンコーダ300は、SPSを構成し、書き込むことができる。例えば、SPSは、subset_sequence_parameter_set_3dv_rbsp()に対応することができ、実施形態6および7で以下に述べるように構成して書き込むことができる。
方法1900は、例えば、デコーダ400がNALユニットを受信して、NALユニット・ヘッダを読み取ることができるステップ1902から開始することができる。NALユニットは、方法1800で符号化されたNALユニットに対応することができる。ステップ1904で、デコーダ400は、NALユニット・タイプを抽出することができる。NALユニット・タイプが17に設定されている場合には、デコーダは、SPSを読み取って構文解析することができる。SPSは、例えば、subset_sequence_parameter_set_3dv_rbsp()に対応することができ、実施形態6および7で以下に述べるように読み取って構文解析することができる。
[実施形態6:SPSの3DV適用分野用の信号パラメータへの拡張]
実施形態1〜4で上述したように、3DV補足レイヤを利用して、エンハンスト3Dレンダリング機能に対応することができるので、3DVレイヤ識別番号(3dv_layer_id)をSPSで信号通信することができる。さらに、上述のように、レイヤ間の冗長性を除去するために、レイヤ間符号化を利用することができ、レイヤ間ピクチャを参照ピクチャ・リストに追加して、レイヤ間符号化を容易にすることができる。従って、デコーダがレイヤ間参照を用いてピクチャを復号する方法を決定できるようにするために、エンコーダは、SPS中のレイヤ間予測構造を指定することができる。このようなレイヤ間予測構造は、例えば、図15を参照して上述した構造1500に対応することができる。
SPSの構築について詳細に述べる前に、様々な実施態様によれば、3DVコンテンツに対応するビットストリームについては新規のプロフィルを利用することができることに留意されたい。以下では「更新版AVCドラフト」と呼ぶ、ITU−T、「Advanced Video Coding for Generic audiovisial Services − Recommendation ITU−T H.264」、2009年3月では、複数のプロフィルについて述べられている。1つまたは複数の実施態様では、profile_idcを218に設定することができる。更新版AVCドラフトでは、AVC/MVCのその他の既存のプロフィルについても述べられている。
以下に示す表12は、実施形態5に関連して上述した関数subset_sequence_parameter_set_3dv_rbsp()について行われるプロセスを詳細に示すものである。特に、表12は、else if(profile_idc==218){...}の記述において、実施形態6によるサブセットSPS 3DVの1つの高レベルな実施態様を示している。詳細な信号通信は、例えば以下の表13に示すように、seq_parameter_set_3dv_extension()の関数において実施することができる。218であるprofile_idcは、MVC規格の新たなプロフィルを表し、3DVプロフィルである。
図20および図21は、それぞれ、実施形態6の様々な実施態様によるSPSを符号化する方法2000および復号する方法2100を示すハイレベル流れ図である。方法2000および2100は、例えば表12に与える形態のSPSを符号化/復号する方法である。表12は、例えば、NALユニット・タイプ17として使用することができる。なお、図3のエンコーダ300は、方法2000を実行するように構成することができ、図4のデコーダ400は、方法2100を実行するように構成することができることに留意されたい。
方法2000は、エンコーダ300がprofile_idcを設定することができるステップ2002から開始することができる。上記で示したように、profile_idcは、例えば、サブセットSPS 3DVでは218に設定することができる。
ステップ2004で、エンコーダ300は、シーケンス・パラメータ・セット・データを書き込むことができる。例えば、このデータは、seq_parameter_set_data()シンタックス構造に関連して更新版AVCドラフトに記載されている任意のSPSデータに対応することができる。
ステップ2006で、エンコーダ300は、profile_idcが83または86に設定されているかどうかを判定することができる。profile_idcが83または86に設定されている場合には、この方法は、ステップ2008に進むことができ、このステップで、エンコーダ300は、更新版AVCドラフトに記載されているように、seq_parameter_set_svc_extension()を書き込み、svc_vui_parameters_present_flagを設定して書き込むことができる。さらに、ステップ2008では、svc_vui_parameters_present_flagが1に設定されている場合には、エンコーダ300は、更新版AVCドラフトに記載されているように、svc_vui_parameter_extension()を書き込むことができる。その後、この方法は、以下でさらに詳細に述べるステップ2010に進むことができる。
ステップ2006に戻って、profile_idcが83または86に設定されていない場合には、この方法は、ステップ2014に進むことができ、このステップで、エンコーダ300は、profile_idcが118に設定されているかどうかを判定することができる。profile_idcが118に設定されている場合には、この方法は、ステップ2016に進むことができ、このステップで、エンコーダ300は、更新版AVCドラフトに記載されているように、bit_equal_to_oneを1に等しくなるように設定し、bit_equal_to_oneを書き込み、seq_parameter_set_mvc_extension()を書き込み、mvc_vui_parameters_present_flagを設定して書き込むことができる。mvc_vui_parameters_present_flagが1に等しい場合には、エンコーダ300は、更新版AVCドラフトに記載されているように、mvc_vui_parameters_extension()を書き込むことができる。その後、この方法は、以下でさらに詳細に述べるステップ2010に進むことができる。
ステップ2014で、エンコーダ300が、profile_idcが118に設定されていないと判定した場合には、この方法は、ステップ2018に進むことができ、このステップで、エンコーダ300は、profile_idcが218に設定されているかどうかを判定することができる。profile_idcが218に設定されていない場合には、この方法は、ステップ2022に進むことができ、このステップで、エンコーダ300は、profile_idcが未知であると判定することができ、エラー・メッセージを出力することができる。
しかし、profile_idcが218に設定されている場合には、エンコーダ300は、ステップ2020を実行することができ、このステップで、エンコーダ300は、bit_equal_to_oneを1に等しくなるように設定し、bit_equal_to_oneを書き込むことができる。上述のように、bit_equal_to_oneは、更新版AVCドラフトに記載されている。ステップ2020で、エンコーダ300は、以下で表13および14ならびに図22から図25に関連してさらに詳細に説明するseq_parameter_set_3dv_extension()を、さらに書き込むことができる。以下で述べるように、seq_parameter_set_3dv_extension()は、レイヤ間依存関係をデコーダに対して示す、または伝達して、デコーダが、ピクチャの復号中に当該ピクチャの適切な予測参照を決定できるようにすることができる。その後、この方法は、ステップ2010に進むことができる。
ステップ2010で、エンコーダ300は、additional_extension2_flagを設定することができ、additional_extension2_flagが1に設定されている場合には、エンコーダ300は、更新版AVCドラフトに記載されているように、全てのadditional_extension2_data_flagsを書き込むことができる。ステップ2012で、エンコーダ300は、更新版AVCドラフトに記載されているようにrbsp_trailing_bits()を書き込むことができ、その後、この方法は終了することができる。
次に、例えば方法2000に従って生成されている可能性もあるSPSを復号する方法2100を示す図21を参照すると、この方法2100は、デコーダ400が受信したビットストリームからシーケンス・パラメータ・セット・データseq_parameter_set_data()を復号し、更新版AVCドラフトに記載されているようにprofile_idcを設定することができる、ステップ2102から開始することができる。
ステップ2104で、デコーダ400は、profile_idcが83または86に設定されているかどうかを判定することができる。profile_idcが83または86に設定されている場合には、この方法は、ステップ2016に進むことができ、このステップで、デコーダ400は、更新版AVCドラフトに記載されているように、seq_parameter_set_svc_extension()を復号し、svc_vui_parameters_present_flagを復号することができる。さらに、ステップ2106で、svc_vui_parameters_present_flagが1に設定されている場合には、デコーダ400は、更新版AVCドラフトに記載されているように、svc_vui_parameter_extension()を復号することができる。その後、この方法は、以下でさらに詳細に述べるステップ2108に進むことができる。
ステップ2104に戻って、profile_idcが83または86に設定されていない場合には、この方法は、ステップ2112に進むことができ、このステップで、デコーダ400は、profile_idcが118に設定されているかどうかを判定することができる。profile_idcが118に設定されている場合には、この方法は、ステップ2114に進むことができ、このステップで、デコーダ400は、更新版AVCドラフトに記載されているように、bit_equal_to_oneを復号し、seq_parameter_set_mvc_extension()を復号し、mvc_vui_parameters_present_flagを復号することができる。さらに、mvc_vui_parameters_present_flagが1に設定されている場合には、デコーダ400は、更新版AVCドラフトに記載されているように、mvc_vui_parameters_extension()を復号することができる。その後、この方法は、以下でさらに詳細に述べるステップ2108に進むことができる。
ステップ2112で、デコーダ400が、profile_idcが118に設定されていないと判定した場合には、この方法は、ステップ2116に進むことができ、このステップで、デコーダ400は、profile_idcが218に設定されているかどうかを判定することができる。profile_idcが218に設定されていない場合には、この方法は、ステップ2120に進むことができ、このステップで、デコーダ400は、未知のprofile_idcが読み取られていると判定することができ、エラー・メッセージを出力することができる。
しかし、profile_idcが218に設定されている場合には、デコーダ400は、ステップ2118を実行することができ、このステップで、デコーダ400は、bit_equal_to_oneを復号することができ、さらに、以下で表13および14ならびに図22〜25に関連してさらに詳細に述べるseq_parameter_set_3dv_extension()を復号することができる。その後、この方法は、ステップ2108に進むことができる。
ステップ2108で、デコーダ400は、additional_extension2_flagを復号することができ、additional_extension2_flagが1に設定されている場合には、デコーダ400は、更新版AVCドラフトに記載されているように、全てのadditional_extension2_data_flagsを復号することができる。ステップ2110で、デコーダ400は、更新版AVCドラフトに記載されているようにrbsp_trailing_bits()を復号することができ、その後、この方法は終了することができる。
上述のように、表13は、seq_parameter_set_3dv_extension()の一実施態様を示しており、3dv_layer_idおよびレイヤ間予測構造は、明示的に信号通信される。このような実施態様は、3DVレイヤの様々な順序付けおよび様々なレイヤ間予測構造を指定することができるので、高い柔軟性を実現する。
表13のセマンティクスは、以下のように与えられる。
num_3dv_layer_minus1に1を加えた値は、3DVレイヤの数を示す。
3dv_layer_id[i]は、i番目の3DVレイヤの識別番号を指定する。
num_3dv_layer_refs_I0[i]は、3DVレイヤ識別番号が3dv_layer_id[i]である3DVレイヤの参照ピクチャ・リスト0中のレイヤ間参照の数を指定する。
3dv_layer_ref_I0[i][j]は、3DVレイヤ識別番号が3dv_layer_id[i]である3DVレイヤの参照ピクチャ・リスト0中のj番目のレイヤ間参照として使用される3DVレイヤ識別番号を指定する。
num_3dv_layer_refs_I1[i]は、3DVレイヤ識別番号が3dv_layer_id[i]である3DVレイヤの参照ピクチャ・リスト1中のレイヤ間参照の数を指定する。
3dv_layer_ref_I1[i][j]は、3DVレイヤ識別番号が3dv_layer_id[i]である3DVレイヤの参照ピクチャ・リスト1中のj番目のレイヤ間参照として使用される3DVレイヤ識別番号を指定する。
表13のseq_parameter_set_3dv_extension()をどのようにして実施形態6で利用することができるかをよりよく示すために、サブセットSPS 3DV拡張を符号化する方法2200を示す図22、およびサブセットSPS 3DV拡張を復号する方法2300を示す図23を参照する。方法2200は、エンコーダ300によって実施することができ、方法2300は、デコーダ400によって実施することができることを理解されたい。
方法2200は、エンコーダ300が、更新版AVCドラフトに記載されているseq_parameter_set_mvc_extension()を符号化することができるステップ2202から開始することができる。
ステップ2204で、エンコーダ300は、num_3dv_layer_minus1を設定し、符号化することができる。上記で示したように、num_3dv_layer_minus1は、符号化対象の3DVコンテンツの3DVビュー中で利用される3DVレイヤの総数を示している。符号化および復号に都合がよいように、num_3dv_layer_minus1の数値は、実際の3DVレイヤの数より1だけ小さい。
上述のように、「i」は、3DVレイヤのid番号を表す。例えば、3DVレイヤidは、上記の表1に定義する3DVレイヤidに対応することができる。ここで、ステップ2208で、エンコーダ300は、符号化対象の3DVコンテンツ中で利用される各タイプの3DVレイヤごとに、3DVレイヤIDを設定し、符号化することができる。従って、エンコーダ300は、3DVコンテンツの3DVビュー中で利用される3DVレイヤの総数に達するまで、ループ2206で各3DVレイヤidを繰り返し処理する。
ループ2210で、ループ2210の第1行目に記しているように、エンコーダ300は、ループ2210において各3DVレイヤidを連続的に処理して、各参照ピクチャ・リスト・タイプ0および場合によっては1の各3DVレイヤの3DVレイヤ間参照を設定し、符号化する。例えば、ステップ2212で、エンコーダ300は、参照ピクチャ・リストが割り当てられた3DVレイヤ(「i」で表される)の参照ピクチャ・リスト0のレイヤ間参照の総数(num_3dv_layer_refs_I0[i])を設定し、符号化することができる。なお、任意の参照ピクチャ・リスト中のレイヤ間参照の数は、利用するレイヤ間依存関係構造によって決まることに留意されたい。例えば、図15の構造1500では、各3DVレイヤは、当該3DVレイヤに割り当てられた参照ピクチャ・リストに、最大で1つしかレイヤ間参照を有していない。しかし、以下に実施形態7で述べる構造など、その他のレイヤ間依存関係または予測構造を利用することもできる。
参照ピクチャ・リスト「0」の3DVレイヤ「i」のレイヤ間参照の総数を設定した後で、エンコーダ300は、ステップ2216で、3DVレイヤ「i」の参照ピクチャ・リスト「0」レイヤ間参照を設定し、符号化することができる。具体的には、エンコーダ300は、3DVレイヤ「i」の参照ピクチャ・リスト「0」のレイヤ間参照の3DVレイヤid(3dv_layer_ref_I0[i][j])を指定することができる。図22および表13では、3DVレイヤ「i」の参照ピクチャ・リスト「0」のレイヤ間参照を「j」で表すことができ、参照ピクチャ・リスト「0」の3DVレイヤ「i」のレイヤ間参照の総数に達するまで、ループ2214でステップ2216を繰り返すことができるようになっている。
エンコーダ300は、さらに、3DVレイヤ「i」の任意の参照ピクチャ・リスト「1」のレイヤ間参照を提供するように構成することもできる。しかし、ある3DVレイヤ「i」が参照ピクチャ・リスト「1」を有していない場合には、方法2200の後続のステップをスキップすることもできることを理解されたい。3DVレイヤ「i」が参照ピクチャ・リスト「1」を有する場合には、この方法は、ステップ2218に進むことができ、このステップで、エンコーダ300は、参照ピクチャ・リスト「1」が割り当てられた3DVレイヤiの参照ピクチャ・リスト1中のレイヤ間参照の総数(num_3dv_layer_refs_I1[i])を設定し、符号化することができる。
参照ピクチャ・リスト「1」の3DVレイヤ「i」のレイヤ間参照の総数を設定した後で、エンコーダ300は、ステップ2222で、3DVレイヤ「i」の参照ピクチャ・リスト「1」のレイヤ間参照を設定し、符号化することができる。具体的には、エンコーダ300は、3DVレイヤ「i」の参照ピクチャ・リスト「1」のレイヤ間参照の3DVレイヤid(3dv_layer_ref_I1[i][j])を指定することができる。3DVレイヤ「i」の参照ピクチャ・リスト「0」に関する上記の説明と同様に、3DVレイヤ「i」の参照ピクチャ・リスト「1」のレイヤ間参照も「j」で表すことができ、参照ピクチャ・リスト「1」の3DVレイヤ「i」のレイヤ間参照の総数に達するまで、ループ2220でステップ2222を繰り返すことができるようになっている。
さらに、上記で示したように、ループ2210では、ステップ2212および2218ならびにループ2214および2220を、符号化対象の3DVコンテンツの3DVビューで利用される全ての3DVレイヤが処理されるまで、それらのレイヤのそれぞれについて繰り返すことができる。
次に、図23を参照すると、seq_parameter_set_3dv_extension()を用いてビットストリーム中の受信したSPS 3DV拡張を復号する方法2300が示してある。方法2300は、デコーダ400が、更新版AVCドラフトに記載されているseq_parameter_set_mvc_extension()を復号することができるステップ2302から開始することができる。
ステップ2304で、デコーダ400は、num_3dv_layer_minus1を復号し、取得する。上述のように、num_3dv_layer_minus1は、3DVコンテンツの3DVビュー中で利用される3DVレイヤの総数を示している。上述のように、num_3dv_layer_minus1の数値は、3DVレイヤの実際の数より1だけ小さい。
上述のように、「i」は、3DVレイヤのid番号を表す。例えば、3DVレイヤidは、上記の表1に定義する3DVレイヤidに対応することができる。ここで、ステップ2308で、デコーダ400は、3DVコンテンツ中で利用される各タイプの3DVレイヤごとに、3DVレイヤIDを復号し、取得することができる。従って、デコーダ400は、3DVコンテンツの3DVビュー中で利用される3DVレイヤの総数に達して、各3DVレイヤidが取得されるまで、ループ2306で各3DVレイヤidを繰り返し処理する。
ループ2310で、ループ2310の第1行目に記しているように、デコーダ400は、ループ2310において各3DVレイヤidを連続的に処理して、各参照ピクチャ・リスト・タイプ0および場合によっては1の各3DVレイヤの3DVレイヤ間参照を復号し、取得する。例えば、ステップ2312で、デコーダ400は、参照ピクチャ・リストが割り当てられた3DVレイヤ(「i」で表される)の参照ピクチャ・リスト0のレイヤ間参照の総数(num_3d_layer_refs_I0[i])を復号し、取得することができる。なお、任意の参照ピクチャ・リスト中のレイヤ間参照の数は、利用するレイヤ間依存関係構造によって決まることに留意されたい。例えば、図15の構造1500では、各3DVレイヤは、当該3DVレイヤに割り当てられた参照ピクチャ・リストに、最大で1つしかレイヤ間参照を有していない。しかし、以下に実施形態7で述べる構造など、その他のレイヤ間依存関係または予測構造を利用することもできる。
参照ピクチャ・リスト「0」の3DVレイヤ「i」のレイヤ間参照の総数を取得した後で、デコーダ400は、ステップ2316で、3DVレイヤ「i」の参照ピクチャ・リスト「0」レイヤ間参照を復号し、取得することができる。具体的には、デコーダ400は、3DVレイヤ「i」の参照ピクチャ・リスト「0」のレイヤ間参照の3DVレイヤid(3dv_layer_ref_I0[i][j])を取得することができる。図23および表13では、3DVレイヤ「i」の参照ピクチャ・リスト「0」のレイヤ間参照を「j」で表すことができ、参照ピクチャ・リスト「0」の3DVレイヤ「i」のレイヤ間参照の総数に達するまで、ループ2314でステップ2316を繰り返すことができるようになっている。
デコーダ400は、さらに、3DVレイヤ「i」の任意の参照ピクチャ・リスト「1」のレイヤ間参照を取得するように構成することもできる。しかし、ある3DVレイヤ「i」が参照ピクチャ・リスト「1」を有していない場合には、方法2300の後続のステップをスキップすることもできることを理解されたい。3DVレイヤ「i」が参照ピクチャ・リスト「1」を有する場合には、この方法は、ステップ2318に進むことができ、このステップで、デコーダ400は、参照ピクチャ・リスト「1」が割り当てられた3DVレイヤ「i」の参照ピクチャ・リスト1中のレイヤ間参照の総数(num_3dv_layer_refs_I1[i])を復号し、取得することができる。
参照ピクチャ・リスト「1」の3DVレイヤ「i」のレイヤ間参照の総数を取得した後で、デコーダ400は、ステップ2322で、3DVレイヤ「i」の参照ピクチャ・リスト「1」のレイヤ間参照を復号し、取得することができる。具体的には、デコーダ400は、3DVレイヤ「i」の参照ピクチャ・リスト「1」のレイヤ間参照の3DVレイヤid(3dv_layer_ref_I1[i][j])を取得することができる。3DVレイヤ「i」の参照ピクチャ・リスト「0」に関する上記の説明と同様に、3DVレイヤ「i」の参照ピクチャ・リスト「1」のレイヤ間参照も「j」で表すことができ、参照ピクチャ・リスト「1」の3DVレイヤ「i」のレイヤ間参照の総数に達するまで、ループ2320でステップ2322を繰り返すことができるようになっている。
さらに、上記で示したように、ループ2310では、ステップ2312および2318ならびにループ2314および2320を、3DVコンテンツの3DVビューで利用される全ての3DVレイヤが処理されるまで、それらのレイヤのそれぞれについて繰り返すことができる。このようにして、デコーダ400は、各3DVレイヤごとに1つまたは複数の参照ピクチャ・リストを再構築することができ、それにより、受信した3DVレイヤ・ピクチャの復号中に、それらのピクチャそれぞれのレイヤ間参照を決定することができる。
なお、ネットワーク・デバイスは、3DVレイヤに関する情報および予測構造を構文解析するときに、異なる3DVレイヤに属するNALユニットに対して、異なる伝送の優先順位を割り当てることができる。従って、輻輳が生じたときに、「上位の」3DV補足レイヤに属するいくつかのNALユニット(例えば表1の上位の3Dレイヤid)を廃棄して、トラフィックを緩和することができる。
[実施形態7:SPSの3DV適用分野の信号パラメータへの代替拡張]
いくつかの実施態様では、使用できる可能性のある3DVレイヤの数が制限されていることがあり、3DVレイヤのコンテンツが特定の、且つ一貫した特性を有することがあるので、3DVを符号化および復号するために使用される予測構造が事前に構成され、エンコーダおよびデコーダの双方がそれを知っていることがある。従って、発明者等は、例えば実施形態6の表13に示すように、明示的な方法で特定の予測またはレイヤ間依存関係構造を信号通信して伝達する必要がない。むしろ、実施形態7では、レイヤ間予測構造は、エンコーダおよびデコーダの双方にとって既知であるようにすることにより、3DVの拡張SPSのデコーダへの伝達を簡略化することができる。
簡単な例を挙げるために、上記に定義した以下の3DVレイヤを利用する。すなわち、2D映像レイヤ、奥行きレイヤ、隠蔽映像レイヤ、隠蔽奥行きレイヤ、および透明度レイヤを利用する。
以下、様々な実施態様で利用することができる事前に定義されたレイヤ間予測構造の一例について述べる。ただし、他の実施態様では、他の事前に定義されたレイヤ間予測構造を利用することができることを理解されたい。この構造では、2D映像レイヤに対して、3DV補足レイヤをレイヤ間予測参照として使用することはない。奥行きレイヤに対しては、2D映像レイヤを、レイヤ間予測参照として使用する。隠蔽映像レイヤに対しては、2D映像レイヤおよび奥行きレイヤが、レイヤ間参照として使用される。隠蔽奥行きレイヤに対しては、2D映像レイヤおよび奥行きレイヤが、レイヤ間参照として使用される。透明度レイヤに対しては、2D映像レイヤおよび奥行きレイヤが、レイヤ間参照として使用される。
ここで、実施形態7では、レイヤ間予測構造を事前に定義することができるので、3DVの拡張SPSは、表14に示すように、各3DVビューについてあるレイヤが存在するかどうかを簡単に伝達することができる。従って、seq_parameter_set_3dv_extension()は、単純に、可能性のある各3DVレイヤごとに複数のフラグを利用して、3DVコンテンツの各3DVビュー中でそれらが利用されているかどうかを示すことができる。従って、3DVの拡張SPSは、いかなる明示的な方法でも、レイヤ間予測構造を信号通信または伝達する必要がない。一実施態様では、レイヤ間予測構造は、一定であり、変更することができない。別の実施態様では、レイヤ間予測構造は、表13を用いて設定され(例えば表12の最初の出現時または定期的な出現時)、それ以外の場合には、表14を用いて拡張情報を通信する。表12〜14は、設計の選択に従って望ましい頻度でデコーダに再伝送することができ、一実施態様では、この情報に変更があったときだけ再伝送されることに留意されたい。
実施形態7で表14のseq_parameter_set_3dv_extension()をどのようにして利用することができるかをよりよく示すために、サブセットSPS 3DVを符号化する方法2400を示す図24、およびサブセットSPS 3DVを復号する方法2500を示す図25を参照する。方法2400は、エンコーダ300によって実施することができ、方法2500は、デコーダ400によって実施することができることを理解されたい。
方法2400は、エンコーダ300が、更新版AVCドラフトに記載されているseq_parameter_set_mvc_extension()を符号化することができるステップ2402から開始することができる。次いで、エンコーダ300は、ループ2404を実行することができ、このループにおいて、エンコーダ300は、3DVレイヤ・フラグを設定して、特定の3DVビュー「i」についてそれぞれの3DVレイヤが存在するかどうかを示すことができる。例えば、num_views_minus1は、3DVコンテンツで利用される3DVビューの総数を示す。例えば、図10〜図12に示す例では、3つの3DVビューが利用される(3DVビュー0〜3DVビュー2)。符号化および復号に都合がよいように、num_views_minus1の数値は、実際の3DVビューの数より1だけ小さい。エンコーダ300は、3DVコンテンツで利用される3DVビューの総数に達するまで、各3DVビュー「i」についてステップ2406〜2414を繰り返すことができる。
具体的には、ループ2404において、エンコーダ300は、ステップ2406で、2D映像レイヤ・フラグを設定し、符号化して、2D映像レイヤが3DVビュー「i」中に存在するかどうかを示すことができ、ステップ2408で、(2D)奥行きレイヤ・フラグを設定し、符号化して、奥行きレイヤが3DVビュー「i」中に存在するかどうかを示すことができ、ステップ2410で、隠蔽映像レイヤ・フラグを設定し、符号化して、隠蔽映像レイヤが3DVビュー「i」中に存在するかどうかを示すことができ、ステップ2412で、隠蔽奥行きレイヤ・フラグを設定し、符号化して、隠蔽奥行きレイヤが3DVビュー「i」中に存在するかどうかを示すことができ、ステップ2414で、透明度レイヤ・フラグを設定し、符号化して、透明度レイヤが3DVビュー「i」中に存在するかどうかを示すことができる。
次に、表14を用いてサブセットSPS 3DVを復号する方法2500について述べる。方法2500は、デコーダ400が、更新版AVCドラフトに記載されているseq_parameter_set_mvc_extension()を復号することができるステップ2502から開始することができる。方法2500におけるデコーダ400は、方法2400に従ってエンコーダ300によって符号化されたビットストリームを受信することができることに留意されたい。デコーダ400も、ループ2504を実行することができ、このループにおいて、デコーダ400は、3DVレイヤ・フラグを復号して、特定の3DVビュー「i」についてそれぞれの3DVレイヤが存在するかどうかを判定することができる。例えば、方法2400に関して上述したように、num_views_minus1は、受信した3DVコンテンツで利用される3DVビューの総数を示す。デコーダ400は、3DVコンテンツで利用される3DVビューの総数に達するまで、各3DVビュー「i」についてステップ2506〜2514を繰り返すことができる。
具体的には、ループ2504において、デコーダ400は、ステップ2506で、2D映像レイヤ・フラグを復号し、取得して、2D映像レイヤが3DVビュー「i」中に存在するかどうかを判定することができ、ステップ2508で、(2D)奥行きレイヤ・フラグを復号し、取得して、奥行きレイヤが3DVビュー「i」中に存在するかどうかを判定することができ、ステップ2510で、隠蔽映像レイヤ・フラグを復号し、取得して、隠蔽映像レイヤが3DVビュー「i」中に存在するかどうかを判定することができ、ステップ2512で、隠蔽奥行きレイヤ・フラグを復号し、取得して、隠蔽奥行きレイヤが3DVビュー「i」中に存在するかどうかを判定することができ、ステップ2514で、透明度レイヤ・フラグを復号し、取得して、透明度レイヤが3DVビュー「i」中に存在するかどうかを判定することができる。
上述のように、デコーダ400は、各3DVビュー中の各3DVレイヤの1つまたは複数の参照ピクチャ・リストを再構築することができ、それにより、受信した3DVレイヤ・ピクチャの復号中に、各3DVレイヤ・ピクチャのレイヤ間参照を決定することができる。
[追加の実施形態]
次に、図26および図27を参照すると、3DVコンテンツを符号化する方法2600および3DVコンテンツを復号する方法2700が示してある。実施形態に関連して本明細書で述べる何れか1つまたは複数の特徴、およびそれらの組合せは、方法2600および2700において、またはこれらの方法を用いて実施することができる。例えば、以下でさらに述べるように、実施形態1〜3は、単独で、または任意に組み合わせて、方法2600および2700において、またはこれらの方法によって実施することができる。さらに、図3のエンコーダ300を使用して方法2600を実施し、図4のデコーダ400を使用して方法2700を実施することができることにも留意されたい。
方法2600は、ステップ2602から開始し、エンコーダ300が複数のピクチャを符号化することができる。ここで、これら複数のピクチャは、所与の時点の所与のビューについての異なる3D情報を記述したものである。例えば、エンコーダ300について上述したレイヤ・エンコーダの何れか1つまたは複数を使用して、実施形態1、2および/または3の何れか1つまたは複数に従って複数のピクチャの符号化を実施することができる。複数のピクチャは、例えば、2D映像レイヤ・ピクチャおよび奥行きレイヤ・ピクチャとすることができる。2D映像レイヤ・ピクチャによって記述される3D情報は、例えば、2D映像とすることができる。同様に、奥行きレイヤ・ピクチャによって記述される3D情報は、例えば、奥行き情報とすることができる。2D映像情報および奥行き情報は、両方とも、所与の時点の所与のビューについての3D情報の例である。
追加の実施形態の方法を説明するために、「ピクチャ」は、様々な実施形態について上述した「フレーム」と等価であるとすることができる。さらに、ピクチャは、上述の何れか1つまたは複数の3DVレイヤに対応することができる。例えば、2Dビュー1010および奥行きビュー1008は、それぞれ別個のピクチャを構成することができる。さらに、図11および/または図12に関連して上述した任意の2Dビュー・レイヤ1118、1122、1136、1218、1222、1236、および/または任意の奥行きレイヤ1120、1124、1220、1224も、それぞれ別個のピクチャを構成することができる。さらに、図11および図12に明示的には図示していないが上述したその他の3DV補足レイヤも、それぞれ別個のピクチャを構成することができる。さらに、上述の3DVビューの何れか1つまたは複数は、図11および図12に関連して上述した、時点T0およびT1における3Dビュー0、1および2など、所与の時点の所与のビューを構成することができる。
ステップ2604で、エンコーダ300は、複数の符号化済みピクチャについて、これらの符号化済みピクチャが、上記複数のピクチャのコンテンツ・タイプを規定する3D処理に対応する構造にどのように適応するかを示すシンタックス要素を生成することができる。例えば、3DV参照バッファ316は、実施形態1、2および/または3の何れか1つまたは複数に従ってシンタックス要素を生成することができる。シンタックス要素は、例えば、実施形態1に関連して上述した3DVプレフィックス・ユニット16、実施形態2のNALプレフィックス・ユニット14および/またはNALユニット20、ならびに/あるいは実施形態3のNALユニット21とすることができる。上述のように、実施形態1、2および3による新規のNALユニットは、符号化済み3DVレイヤについて、図10の構造1000など3D処理に対応する構造に、各レイヤがどのように適応するかを示すことができる。さらに、NALユニット16および21など、新規のNALユニットを使用することで、ビットストリームにおいて図10に示す構造などの3DV構造が使用されていることを示すことができる。上述のように、構造1000は、3DVレイヤの様々なタイプなど、様々なコンテンツ・タイプを規定することができる。構造は、図10に示すように1組の3DVビューのセットに対応することができ、且つ/または3DVビュー内の1組のレイヤのセットに対応することができることを理解されたい。また、エンコーダ300は、あるピクチャを、別の符号化済みピクチャを参照として使用して符号化することによって、コンテンツ・タイプの異なるピクチャ間でレイヤ間符号化を実現することができることも理解されたい。例えば、図10を例として用いると、ビュー1004の奥行きビューは、ビュー1004の2Dビューなど異なるレイヤに依存して、これを参照することにより、レイヤ間符号化を実現することができる。さらに、図10の符号化構造は、ビュー1004の2Dビューが、ビュー1006の奥行きレイヤなど別のレイヤに依存して、これを参照するように構成することができる。上記に示すように、その他のタイプのレイヤ間符号化も可能であり、当業者なら、本明細書に与える教示に鑑みて実施することができる。
ステップ2606で、エンコーダ300は、複数の符号化済みピクチャおよびシンタックス要素を含むビットストリームを生成することができる。ここで、シンタックス要素を含むことにより、符号化済みビットストリームのレベルで、構造中の複数の符号化済みピクチャ間の関係を示す指示を与えることができる。例えば、3DV参照バッファ316は、ビットストリーム318を生成することができるが、このビットストリーム318は、上述のように実施形態1、2および/または3に従って生成された符号化済みビットストリームの何れかを含むことができる。従って、このビットストリームは、図10〜図12に関連した上述したレイヤ・フレームの何れか1つまたは複数など、複数の符号化済みピクチャを含むことができ、また、上述のように符号化済みビットストリーム・レベルで構造中の複数の符号化済みピクチャ間の関係を示す指示を提供することができる実施形態1の3DVプレフィックス・ユニット16、実施形態2のNALプレフィックス・ユニット14および/またはNALユニット20、ならびに/あるいは実施形態3のNALユニット21のうちの何れか1つまたは複数を含むことができる。例えば、シンタックス要素は、図10の構造中、あるいは3DVコンテンツに対応するその他の構造中の複数のピクチャまたはレイヤ間の依存関係および関係を示すことができる。例えば、シンタックス要素は、どのようにしてピクチャを結合して3DVコンテンツを生成すべきかを示す指示を与えることができる。
様々な実施形態において、エンコーダ300のレイヤ・エンコーダ304〜314のセットを、ステップ2602を実行するように構成することができることを理解されたい。さらに、3DV参照バッファ316および/またはレイヤ・エンコーダ304〜314は、ステップ2604〜2606の何れか1つまたは複数を実行するように構成することができる。あるいは、またはこれに加えて、エンコーダ300は、少なくとも方法2600を実行するように構成されたプロセッサを含むこともできる。さらに、実施形態は、ステップ2602で生成された複数の符号化済みピクチャ、ステップ2604で生成されたシンタックス要素、および/またはステップ2606で生成された、ビットストリームに含まれる何れか1つまたは複数の要素(ビットストリーム自体も含む)を含むようにフォーマット化された映像信号および/または映像信号構造を含むことができる。さらに、実施形態は、映像信号構造を記憶したプロセッサ可読媒体を含むこともできる。さらに、上記に示したように、図7の変調器722は、映像信号を変調するように構成することができる。さらに、実施形態は、プロセッサに少なくとも方法2600を実行させる命令を記憶したプロセッサ可読媒体を含むこともできる。
図27に示す3DVコンテンツを復号する方法2700を再度参照すると、方法2700は、デコーダ400がビットストリームに属する複数の符号化済みピクチャにアクセスすることができるステップ2702から開始することができる。これら複数のピクチャは、所与の時点の所与のビューについての異なる3D情報を記述している。例えば、ビットストリームは、方法2600によって生成されるビットストリームに対応することができる。方法2600に関連して上述したように、図11および/または図12に関連して上述した任意の2Dビュー・レイヤおよび/または任意の奥行きレイヤは、それぞれ別個のピクチャを構成することができる。さらに、叙述のように、図11および図12に明示的には図示していないが上述したその他の3DV補足レイヤも、それぞれ別個のピクチャを構成することができる。さらに、上述の3DVビューの何れか1つまたは複数は、図11および図12に関連して上述した、時点T0およびT1における3Dビュー0、1および2など、所与の時点の所与のビューを構成することができる。
ステップ2704で、デコーダ400は、ビットストリームに属するシンタックス要素にアクセスすることができる。シンタックス要素は、複数の符号化済みピクチャについて、符号化済みピクチャがどのように3D処理に対応する構造に適応するかを示す。この構造は、複数のピクチャ間の規定された関係を与える。例えば、3DV参照バッファ414は、実施形態1、2および/または3の何れか1つまたは複数に従ってシンタックス要素にアクセスすることができる。シンタックス要素は、例えば、実施形態1に関連して上述した3DVプレフィックス・ユニット16、実施形態2のNALプレフィックス・ユニット14および/またはNALユニット20、ならびに/あるいは実施形態3のNALユニット21とすることができる。上述のように、実施形態1、2および3による新規のNALユニットは、符号化済み3DVレイヤについて、図10の構造1000など3D処理に対応する構造に、各レイヤがどのように適応するかを示すことができる。さらに、NALユニット16および21など、新規のNALユニットを使用することで、ビットストリームにおいて図10に示す構造などの3DV構造が使用されていることを示すことができる。上述のように、構造1000は、3DVレイヤの様々なタイプなど、様々なコンテンツ・タイプを規定することができる。構造は、図10に示すように1組の3DVビューのセットに対応することができ、且つ/または3DVビュー内の1組のレイヤのセットに対応することができることを理解されたい。また、デコーダ400は、あるピクチャを、別の符号化済みピクチャを参照として使用して復号することによって、コンテンツ・タイプの異なるピクチャ間のレイヤ間復号を可能にすることができることも理解されたい。例えば、図10を例として用いると、ビュー1004の奥行きビューは、ビュー1004の2Dビューなど異なるレイヤに依存して、これを参照することにより、レイヤ間復号を可能にすることができる。さらに、図10の符号化構造は、ビュー1004の2Dビューが、ビュー1006の奥行きレイヤなど別のレイヤに依存して、これを参照するように構成することができる。上記に示すように、その他のタイプのレイヤ間復号も可能であり、当業者なら、本明細書に与える教示に鑑みて実施することができる。さらに、実施形態1〜3に関連して上述したように、実施形態1の3DVプレフィックス・ユニット16、実施形態2のNALプレフィックス・ユニット14および/またはNALユニット20、ならびに/あるいは実施形態3のNALユニット21の何れか1つまたは複数は、上述のように、3DVビューIDおよび3DレイヤIDを用いることによって、ビットストリームのピクチャ間の規定された関係を与えることができる。例えば、デコーダ400は、図10の構造1000などの3DV構造に従ってピクチャを結合するように事前に構成することができ、3DVビューIDおよび3DVレイヤIDを使用して、受信したどのピクチャが、既定の構造中の様々なレイヤに対応するかを特定することができる。
ステップ2706で、デコーダ400は、複数の符号化ピクチャを復号するように構成することができる。例えば、デコーダ400は、例えば図4および図6に関連して上述したように、レイヤ・デコーダ402〜412を用いて受信したピクチャを復号することができる。例えば、デコーダ400は、シンタックス要素によって示され、与えられる規定された関係を使用して、2次元(2D)映像レイヤ・ピクチャ、奥行きレイヤ・ピクチャ、隠蔽レイヤ・ピクチャまたは透明度ピクチャのうちの1つまたは複数を参照する追加のピクチャを描画することができる。例えば、上述のように、図10のビュー1004の奥行きビューは、ビュー1004の2Dビューなど異なるレイヤに依存して、これを参照することにより、レイヤ間符号化を実現することができる。従って、デコーダ400は、様々な異なるレイヤ・ピクチャの1つまたは複数から、ビュー1004の奥行きビューなど、追加のピクチャを描画することができる。
ステップ2708で、デコーダ400は、複数のピクチャ間の規定された関係を示す出力フォーマットで、復号済みピクチャを供給することができる。例えば、デコーダ400の3DV参照/出力バッファ414は、3DV構造に従ってフォーマット化された3DVコンテンツを出力することができる。従って、この出力は、この構造による複数のピクチャ間の関係をディスプレイ・デバイスに対して示して、3DVコンテンツをディスプレイ・デバイスに適切に表示することができるようにし、3DVコンテンツをユーザが見ることができるようにすることができる。具体的には、出力フォーマットは、復号済みピクチャがどのように構造に適応するかを指定するシンタックス要素を含むことができる。このようなシンタックス要素の例としては、実施形態1の3DVプレフィックス・ユニット16、実施形態2のNALプレフィックス・ユニット14および/またはNALユニット20、ならびに/あるいは実施形態3のNALユニット21の何れか1つまたは複数が挙げられる。
任意選択のステップ2710〜2714は、ステップ2708を実行した後で、デコーダにおいて実行することができる。いくつかの実施態様では、ステップ2710〜2714の1つまたは複数を、ステップ2708の一部および/またはステップ2706の復号の一部として実行することができる。様々な実施態様で、ステップ2710〜2714の1つまたは複数、特にステップ2714は、ディスプレイにおいて実行することができる。
必要に応じて、ステップ2710で、デコーダ400は、シンタックス要素を用いて複数のピクチャから2D映像ピクチャを識別することができる。例えば、デコーダ400は、3DVレイヤを符号化するために実施される実施形態1の3DVプレフィックス・ユニット16、実施形態2のNALプレフィックス・ユニット14および/またはNALユニット20、ならびに/あるいは実施形態3のNALユニット21の何れか1つまたは複数を構文解析することによって、2D映像ピクチャまたはレイヤを識別することができる。デコーダ400は、さらに、符号化済みピクチャのうちのどれが上記では「0」として表した2Dビュー・レイヤIDを有するかを決定し、3DVビューIDを用いて対応する3DVビューを決定することができる。
必要に応じて、ステップ2712で、デコーダ400は、シンタックス要素を用いて複数のピクチャから奥行きピクチャを識別することができる。例えば、デコーダ400は、3DVレイヤを符号化するために実施される実施形態1の3DVプレフィックス・ユニット16、実施形態2のNALプレフィックス・ユニット14および/またはNALユニット20、ならびに/あるいは実施形態3のNALユニット21の何れか1つまたは複数を構文解析することによって、奥行きピクチャまたはレイヤを識別することができる。さらに、デコーダ400は、符号化済みピクチャのうちのどれが上記では「1」として表した奥行きレイヤIDを有するかを決定し、3DVビューIDを用いて対応する3DVビューを決定することができる。なお、様々な実施形態では、シンタックス要素を用いてその他の3DV補足レイヤを識別することもできることに留意されたい。
必要に応じて、ステップ2714で、デコーダ400は、2D映像ピクチャおよび奥行きピクチャに基づいて追加ビューの新たなピクチャを描画することができる。例えば、識別されたピクチャまたはビューは、図10の2Dビュー1010および奥行きビュー1008に対応することができる。さらに、3DVビュー1004および1006は、例えば、図10に関連して上記に与えた説明に従って、3DVベース・ビュー1002の2Dビュー1010および奥行きビュー1008を参照として用いて描画することができる。同様に、3DVビュー1006の2D映像レイヤおよび奥行きレイヤを参照として使用して、図10に関連して上記に与えた説明に従って、3DVビュー1004を描画することができる。
様々な実施形態によれば、デコーダ400のレイヤ・デコーダ402〜412のセットは、ステップ2702および2706を実行するように構成することができることを理解されたい。さらに、3DV参照バッファ414および/またはレイヤ・デコーダ402〜412は、ステップ2704および2708の何れか1つまたは複数を実行するように構成することができる。あるいは、またはこれに加えて、デコーダ400は、少なくとも方法2700を実行するように構成されたプロセッサを含むことができる。さらに、上記に示したように、図8の復調器822は、ステップ2702でアクセスした複数の符号化ピクチャが属しているビットストリームを含む映像信号を復調するように構成することができる。さらに、いくつかの実施形態では、プロセッサに少なくとも方法2700を実行させる命令を記憶したプロセッサ可読媒体を含むこともできる。
次に、図28を参照すると、参照ピクチャ・リストを構築する方法2800が示してある。実施形態に関連して本明細書で述べる何れか1つまたは複数の特徴およびそれらの組合せは、方法2800において、またはこれを用いて実施することができることを理解されたい。例えば、以下でさらに述べるように、実施形態4は、方法2800において、またこの方法によって実施することができる。さらに、実施形態1〜3および5〜7の何れか1つまたは複数は、実施形態4と組み合わせて、方法2800において、またはこれを用いて実施することができる。さらに、図3のエンコーダ300および/または図4のデコーダ400を使用して、方法2800を実施することができることに留意されたい。さらに、方法2800は、ピクチャについての参照ピクチャ・リストの構築を記述したものであるが、実施形態4に関連して上述したように、このような参照リストは、ピクチャのシーケンスについて、複数のビューにまたがる1組のピクチャのセットについて、またはピクチャのサブセットについて構築することもできる。
方法2800は、エンコーダ300またはデコーダ400がピクチャの依存関係情報に基づいてピクチャのレイヤ間参照を決定することができる任意選択ステップ2802から開始することができる。例えば、デコーダ400は、上述のように、シーケンス・パラメータ・セット(SPS)を伝達する受信したシンタックス要素から依存関係情報を抽出して復号することができる。エンコーダ300の場合は、依存関係情報は、例えば実施形態5〜8に関連して上述したようにエンコーダ300がSPSに含めた依存関係情報と同じとすることができる。例えば、エンコーダ300は、エンコーダに記憶される構成ファイルから依存関係情報を取得することができる。依存関係情報は、異なるピクチャおよびピクチャ・タイプがどのように予測符号化されるかを示す時間的依存関係、ビュー間依存関係、およびレイヤ間依存関係の何れか1つまたは複数を含むことができることを理解されたい。従って、この依存関係情報に基づいて、エンコーダ300またはデコーダ400は、参照ピクチャ・リストを構築しているピクチャのレイヤ間参照を決定することができる。さらに、レイヤ間参照は、実施形態4に関連して上述したレイヤ間参照に準拠していてもよい。例えば、レイヤ間参照は、図15に関連して上述した構造の何れか1つまたは複数に対応することができる。
ステップ2804で、エンコーダ300またはデコーダ400は、ピクチャの1つまたは複数のその他の参照に対するレイヤ間参照の優先順位を決定することができる。例えば、エンコーダ300またはデコーダ400は、参照ピクチャ・リスト中のピクチャに優先順位をつける優先順位方式を適用するように構成することができる。例えば、実施形態4に関連して上述したように、参照リスト中のピクチャは、その参照ピクチャ・リストが構築されたピクチャと、当該参照ピクチャ・リスト中に列挙されたピクチャとの間の冗長性の程度に従って、順序付け/優先順位付けすることができる。例えば、奥行きピクチャに関連して上述したように、レイヤ間参照は、参照リスト中の時間的参照およびビュー間参照と比較して最小の冗長性を有するものと予想される。したがって、レイヤ間参照は時間的参照およびビュー間参照よりも低い優先順位を有する。なお、実施形態4の様々な3DVレイヤ・タイプに関連して上記に与えた任意の優先順位を、ここではステップ2804で適用することができることに留意されたい。ただし、異なる優先順位も、本明細書に記載する様々な特徴に従って利用することができることも理解されたい。例えば、優先順位は、3DVコンテンツのピクチャ参照と参照ピクチャ・リストに関連するピクチャとの間の実際の冗長性に従って変化してもよい。例えば、冗長性は、3DVコンテンツを構成するピクチャまたはレイヤの測定値に基づいて決定することができ、優先順位方式は、参照リスト関連するピクチャとの冗長性の高い参照ピクチャに冗長性の低い参照ピクチャよりも高い優先順位が与えられるように、測定した冗長性レベルを反映するように調整することができる。さらに、このような優先順位方式は、その他の特徴または実施形態では、各ピクチャまたは参照ピクチャ・リストごとに異なるものを工夫することもできる。
ステップ2806で、エンコーダ300またはデコーダ400は、優先順位に基づいて、ピクチャの参照の順序付けされたリストにレイヤ間参照を含めることができる。例えば、より低い、または最低の優先順位を有するレイヤ間参照ピクチャは、より高い優先順位を有するその他の参照ピクチャの後に、またはリストの末尾に、含めることができる。また、より高い、または最高の優先順位を有するレイヤ間参照ピクチャは、より低い優先順位を有する、またはリストの先頭の他の参照ピクチャの前に含めることができる。
このような参照としては、上述のように、時間的参照および/またはビュー間参照などが挙げられる。上記に示したように、レイヤ間参照は、エンコーダの実施態様の方法1600またはデコーダの実施態様の方法1700に従って、参照のリストに含めることができる。さらに、レイヤ間参照は、ステップ2804に関連して上述したように、その他の優先順位方式に従って参照のリストに含めることもできる。なお、共通性の高い参照により小さな指標を使用することができ、伝送においてビットを節約することができるように、予想される用途に基づいて、リストを順序付けおよび優先順位付けすることができることに留意されたい。
任意選択のステップ2808で、エンコーダ300またはデコーダ400は、ピクチャを含む符号化動作にレイヤ間参照を使用することができる。例えば、エンコーダ300は、予測符号化動作を実行して、レイヤ間参照を参照ピクチャとして使用して参照リストを構築したピクチャを符号化することができる。デコーダ400は、予測復号動作を実行して、レイヤ間参照を参照ピクチャとして使用して参照リストを構築したピクチャを復号することができる。従って、ピクチャの符号化または復号は、少なくとも部分的には、レイヤ間参照に基づくことができる。
必要に応じて、ステップ2810で、エンコーダ300またはデコーダ400は、符号化済みピクチャを含むビットストリームを生成することができる。例えば、エンコーダ300は、図3および図5に関連して上記に与えた説明に従って、ビットストリーム318に符号化済みピクチャを含めることができる。さらに、デコーダ400は、図4および図6に関連して上記に与えた説明に従って、ビットストリーム416に復号済みピクチャを含めることができる。
その後、この方法は、終了することもできるし、あるいはエンコーダ300またはデコーダ400が別のピクチャの参照ピクチャ・リストを生成することができるように、またはピクチャがBピクチャである場合には同じピクチャの第2の参照ピクチャ・リストを生成することができるように、反復することができる。
一実施態様では、ステップ2804および2806のみを実行する。例えば、レイヤ間参照を提供することができ、この実施態様では、このレイヤ間参照の優先順位を決定する。次いで、この実施態様は、決定した優先順位に基づいて順序付けしたリストにこのレイヤ間参照を含める。
ステップ2802に戻ると、必要に応じて、ステップ2802は、図29に示す2D映像レイヤ・ピクチャを処理する方法2900の実行を含むことができる。例えば、方法2900は、ステップ2902から開始することができ、このステップで、エンコーダ300またはデコーダ400は、参照ピクチャ・リストが構築されたピクチャが2D映像レイヤ・ピクチャであるかどうかを判定することができる。参照が2D映像レイヤ・ピクチャ出ない場合には、この方法は、方法2800のステップ2804に進むことができる。そうでない場合には、この方法は、ステップ2904に進むことができ、このステップで、エンコーダ300またはデコーダ400は、参照ピクチャ・リストから任意のレイヤ間参照を除外することができる。例えば、実施形態4に関連して上述したように、2D映像レイヤのレイヤ間参照を用いないことにより、従来のMVCで3DVコンテンツを抽出し、このコンテンツを表示のためにフォーマット化できるようにすることができる。その後、この方法は、方法2800のステップ2804に進むことができる。
ステップ2904は、奥行きレイヤのみを、2D映像レイヤの参照として使用されないようにするように修正することもできる。このような実施態様では、例えば、2D映像レイヤのレイヤ間参照として、隠蔽映像レイヤに依拠することができる。
様々な実施形態によれば、デコーダ400のレイヤ・デコーダ402〜412やエンコーダ300のレイヤ・エンコーダ304〜314など、1組のレイヤ・コーダのセットを、ステップ2808およびステップ2810を実行するように構成することができることを理解されたい。さらに、3D参照バッファ414、3DV参照バッファ316および/またはレイヤ・コーダは、ステップ2802〜2806および2810の何れか1つまたは複数を実行するように構成することができる。あるいは、またはこれに加えて、エンコーダ300またはデコーダ400は、少なくとも方法2800を実行するように構成されたプロセッサを含むこともできる。さらに、実施形態は、プロセッサに少なくとも方法2800を実行させる命令を記憶したプロセッサ可読媒体を含むこともできる。
次に、図30および図31を参照すると、3DVレイヤ間依存関係構造が伝達されるように3DVコンテンツを符号化する方法3000および復号する方法3100が示してある。様々な実施形態に関連して本明細書で述べる何れか1つまたは複数の特徴およびそれらの組合せは、方法3000および3100において、またはこれらを用いて実施することができることを理解されたい。例えば、以下でさらに述べるように、実施形態5〜7は、方法2600および2700において、またこれらの方法によって実施することができる。さらに、図3のエンコーダ300および図4のデコーダ400を使用して、方法3000および3100をそれぞれ実施することができることに留意されたい。
方法3000は、エンコーダ300が3DVレイヤ間のレイヤ間依存関係構造を示すシンタックス要素を生成することができるステップ3002から開始することができる。例えば、シンタックス要素は、実施形態5〜7の何れか1つまたは複数に関連して上述したように生成することができる。例えば、NALユニット17をシンタックス要素として利用して、実施形態5に関連して上述したように、相互依存関係構造を伝達することもできる。さらに、相互依存関係構造は、実施形態6および7に関連して、また表13および14に関連して上述したように伝達することもできる。例えば、方法2000、2200および2400の何れか1つまたは複数を利用して、相互依存関係構造を伝達することができる。例えば、シンタックス要素は、実施形態6に関連して上述したように、レイヤ間依存関係構造を明示的に伝達することもできるし、あるいは、実施形態7に関連して上述したように、3DVレイヤidを用いて各3DVビューごとに特定の3DVレイヤが存在するかどうかを伝達することによって、既定のレイヤ間依存関係の構造を示すこともできる。さらに、レイヤ間依存関係構造は、多数の異なるレイヤ間依存関係構造のうちの1つに対応することができる。例えば、レイヤ間依存関係構造は、図15に関連して上述した構造および実施形態7に関連して上述した構造に対応することができる。さらに、上述のように、レイヤ間依存関係構造は、NALユニット・ヘッダ、SPS、PPS、SEIまたはスライス・ヘッダの何れか1つまたは複数に設けることもできる。さらに、エンコーダ300は、例えば実施形態4に関連して上述したように、参照ピクチャ・リストを構築してこれを利用することによって、シンタックス要素を生成することができる。
ステップ3004で、エンコーダ300は、レイヤ間依存関係構造に基づいて、それらの3Dレイヤのうちの1つのレイヤのピクチャのレイヤ間参照を識別することができる。例えば、レイヤ間依存関係構造が図15に関連して上述した構造に対応する場合には、奥行きレイヤ・ピクチャを符号化するために、エンコーダ300は、ステップ3002で構築することができる参照ピクチャ・リストを利用して、奥行きレイヤ・ピクチャのレイヤ間参照が、奥行きレイヤ・ピクチャと同じビューまたは3DVビュー中の2D映像レイヤ・ピクチャであると判定することができる。上述のように、相互依存関係構造は変化することができ、例えば異なる3DVビュー間のレイヤ間依存関係など相互依存関係が変わるとともに、特に2D映像レイヤ、奥行きレイヤ、隠蔽映像レイヤ、隠蔽奥行きレイヤおよび透明度レイヤなど、多数の異なるタイプのレイヤを含むことができる。
ステップ3006で、エンコーダ300は、少なくとも部分的にはレイヤ間参照に基づいて、ピクチャを符号化することができる。例えば、エンコーダ300は、エンコーダ304〜314を用いて、図3および図5に関連して上述したようにピクチャを符号化することができる。ここで、再度構造1500および奥行きレイヤを一例として用いると、奥行きレイヤは、上述のように、少なくとも部分的には2D映像レイヤに基づいて符号化することができる。
任意選択のステップ3008で、エンコーダ300は、符号化済みピクチャを含むビットストリームを生成することができる。例えば、符号化済みビットストリームは、図3および図5に関連して上述したように生成することができ、例えばビットストリーム318に対応することができる。
任意選択のステップ3010で、エンコーダ300は、符号化済みピクチャと、符号化済みピクチャの復号に使用されるシンタックス要素とを提供することができる。例えば、シンタックス要素および符号化済みピクチャは、ビットストリーム318を介してデコーダ400に伝送することができる。あるいは、シンタックス要素は、3DVデータ・コンテンツを伝送するために使用するビットストリームとは別のビットストリームで伝送することもできる。従って、図3のビットストリーム318は、2つの別個の対応するビットストリームを表すことができる。あるいは、異なるビットストリームを、別々に伝送することもできる。例えば、一方のビットストリームはケーブル・ネットワークを介してデコーダ400に伝送し、他方のビットストリームは、無線でデコーダ400に伝送することもできる。さらに、シンタックス要素は、方法3100に関連して以下で述べるように、符号化済みピクチャを復号するために使用することもできる。
様々な実施形態で、エンコーダ300のレイヤ・エンコーダ304〜314のセットは、ステップ3006を実行するように構成することができることを理解されたい。さらに、3DV参照バッファ316および/またはレイヤ・エンコーダ304〜314は、ステップ3002、3004、3008および3010の1つまたは複数を実行するように構成することができる。あるいは、またはこれに加えて、エンコーダ300は、少なくとも方法3000を実行するように構成されたプロセッサを含むこともできる。さらに、実施形態は、方法3000に従って生成された符号化済みピクチャ、シンタックス要素および/またはビットストリームを含むようにフォーマット化された映像信号およびまたは映像信号構造を含むこともできる。さらに、実施形態は、映像信号構造を記憶したプロセッサ可読媒体を含むこともできる。さらに、上記に示したように、図7の変調器722は、映像信号を変調するように構成することができる。さらに、実施形態は、プロセッサに少なくとも方法3000を実行させる命令を記憶したプロセッサ可読媒体を含むこともできる。
一実施態様では、ステップ3002〜3006のみを実行する。この実施態様では、シンタックス要素を生成して、ピクチャのレイヤ間参照を識別し、次いで、少なくとも部分的にはこの識別したレイヤ間参照に基づいて、ピクチャを符号化する。この場合には、この実施態様では、符号化済みピクチャを含むビットストリームを生成する、または復号に使用する符号化済みピクチャおよびシンタックスを提供する必要はない。
図31の3DVコンテンツを復号する方法3100を再度参照すると、方法3100は、ステップ3102から開始することができる。デコーダ400は、ビットストリームに属する符号化済みピクチャにアクセスすることができ、このピクチャは、所与の時点の所与のビューに属する特定の3DVレイヤについての3DV情報を記述したものである。例えば、符号化済みピクチャは、上述の何れか1つまたは複数の3DVレイヤに対応することができる。例えば、2Dビュー1010および奥行きビュー1008は、それぞれ別個のピクチャを構成することができる。さらに、図11および/または図12に関連して上述した任意の2Dビュー・レイヤ1118、1122、1136、1218、1222、1236および/または任意の奥行きビュー1120、1124、1220、1224も、それぞれ別個のピクチャを構成することができる。さらに、図11および図12に明示的には示していないが上述したその他の3DV補足レイヤも、それぞれ別個のピクチャを構成することができる。さらに、上述した3DVビューの何れか1つまたは複数は、図11および図12に関連して上述した時点T0およびT1の3Dビュー0、1および2など、所与の時点の所与のビューを構成することができる。さらに、符号化済みピクチャは、方法3000によって生成された符号化済みピクチャとすることもできる。
ステップ3104で、デコーダ400は、特定の3DVレイヤを含む1組の3DVレイヤのセットのレイヤ間依存関係構造を示すシンタックス要素にアクセスすることができる。例えば、NALユニット17が、実施形態5に関連して上述したように、相互依存関係構造を示すシンタックス要素であってもよい。さらに、相互依存関係構造は、実施形態6および7ならびに表13および表14に関連して上述したように示す、または伝達することもできる。例えば、方法2000、2200および2400の何れか1つまたは複数を利用して、相互依存関係構造を伝達する、または示すこともできる。
例えば、シンタックス要素は、実施形態6に関連して上述したように、レイヤ間依存関係構造を明示的に伝達することができる。あるいは、シンタックス要素は、実施形態7に関連して上述したように、3DVレイヤidを用いて各3DVビューごとに特定の3DVレイヤが存在するかどうかを伝達することによって、既定のレイヤ間依存関係の構造を示すこともできる。さらに、相互依存関係構造は、多数の異なる相互依存関係構造のうちの1つに対応することができる。例えば、相互依存関係構造は、図15に関連して上述した構造および実施形態7に関連して上述した構造に対応することができる。さらに、上述のように、相互依存関係構造およびシンタックス要素は、NALユニット・ヘッダ、SPS、PPS、SEIまたはスライス・ヘッダの何れか1つまたは複数から取得することもできる。さらに、デコーダは、例えば方法2100、2300および2500の何れか1つまたは複数に関連して上述したようにシンタックス要素にアクセスすることもできる。
ステップ3106で、デコーダ400は、少なくとも部分的にはレイヤ間依存関係構造に基づいて、符号化済みピクチャを復号することができる。例えば、デコーダ400は、図4および図6に関連して上述したように、符号化済みピクチャを復号することができる。さらに、デコーダ400は、例えば実施形態4に関連して上述したようにシンタックス要素を用いて1つまたは複数の参照ピクチャ・リストを構築し、これを利用して、符号化済みピクチャを復号することもできる。従って、デコーダ400は、予測符号化のために符号化済みピクチャの参照を決定することができ、少なくとも部分的にはその参照に基づいて、ピクチャを復号することができる。
任意選択のステップ3108で、デコーダ400は、レイヤ間依存関係構造を示す出力フォーマットで、復号されたピクチャを提供することができる。例えば、デコーダ400の3DV参照/出力バッファ414は、レイヤ間依存関係構造に従ってフォーマット化された3DVコンテンツを出力することができる。従って、この出力は、この構造による複数のピクチャ間の関係をディスプレイ・デバイスに対して示して、3DVコンテンツをディスプレイ・デバイスに適切に表示することができるようにし、3DVコンテンツをユーザが見ることができるようにすることができる。具体的には、出力フォーマットは、復号済みピクチャがどのように構造に適応するかを指定するシンタックス要素を含むことができる。このようなシンタックス要素の例としては、上述したように、NALユニット17を挙げることができる。
様々な実施形態で、デコーダ400のレイヤ・デコーダ402〜412のセットは、ステップ3106を実行するように構成することができることを理解されたい。さらに、3DV参照バッファ414および/またはレイヤ・デコーダ402〜412は、ステップ3102、3104および3108の1つまたは複数を実行するように構成することができる。あるいは、またはこれに加えて、デコーダ400は、少なくとも方法3100を実行するように構成されたプロセッサを含むこともできる。さらに、上記に示したように、図8の復調器822は、ステップ3102でアクセスした複数の符号化ピクチャが属するビットストリームを含む映像信号を復調するように構成することができる。さらに、実施形態は、プロセッサに少なくとも方法3100を実行させる命令を記憶したプロセッサ可読媒体を含むこともできる。
当業者なら、本明細書に与えた教示に鑑みて、上記の実施形態を様々な形態で結合することができることを理解されたい。例えば、図32を参照すると、上述したいくつかの実施形態のフィーチャを組み込んだNALユニット・ストリーム3200が示してある。ここで、ストリーム3200は、上記の表3に示し、AVCドラフトに定義されるように、MVC用のサブセット・シーケンス・パラメータ・セットのNALユニット15(3202)を含むことができる。さらに、ストリーム3200は、実施形態5〜7に関連して上述したように、少なくとも1つのレイヤ間依存関係構造を示す3DVの拡張SPSのNALユニット17も含むことができる。ここで、分かりやすいように、図10に示すレイヤ間依存関係構造を、ストリーム3200では利用している。
図11および図12と同様に、図32は、時点T0および時点T1に対応する3DVビューのセットを示している。上述した図11および図12の省略は、図32にも適用され、図32の矢印は、図11および図12の矢印と同様に、NALユニットの伝送順序を示している。もちろん、図32は、ストリーム3200のごく一部である。ストリーム3200は、実際の適用分野では、多数の異なる瞬間に対して、さらに多くのNALユニットを含むことになる。さらに、MVCに精通した当業者なら理解できるように、3つの3DVビューを使用しているのも一例に過ぎず、さらに多くのビューを利用し、且つ/またはデコーダにおいて描画することができる。さらに、各ビューごとに2つの3DVレイヤを使用しているのも一例に過ぎず、上記で詳細に述べたように、いくつかの追加の3DVレイヤを利用することもできることを理解されたい。
このストリーム3200の部分では、3つの3DVビュー3206、3208および3210は、時点T0に対応し、3つの3DVビュー3212、3214および3216は、時点T1に対応する。図11および図12と同様に、3DVビュー0(3206、3212)は、図10のベース・ビュー1002に対応することができ、3DVビュー2(3208、3214)および3DVビュー1(3210、3216)は、それぞれ図10のPビュー1006およびBビュー1004に対応することができる。3DVビュー3206は、2D映像レイヤ3218を構成するNALユニット16(3220)、14(3222)および5(3224)を含むことができる。上述のように、NALユニット5は、瞬時復号更新(IDR)ピクチャの符号化済みスライスの映像データを含み、AVCドラフトに規定されるようにイントラ・スライスまたはSIスライスのみで構成される。さらに、NALユニット14は、MVCに従って、MVCプレフィックスとして、その他のビューのベース・レイヤとして2D映像レイヤ3218を示す参照を含むことができる。ステレオ・プロフィルを使用する別の実施態様では、NALユニット14および17を省略することができる。
NALユニット16は、例えば、実施形態1に関連して上述したように、3DVビューIDおよび3DVレイヤIDを含むことができる。ここで、3DVビューIDおよび3DVレイヤIDは、例えば、奥行きレイヤまたはその他の3DVレイヤのレイヤ間参照として2D映像レイヤ3218を識別するためにデコーダ400が使用することができる。図32に示すように、3DVビュー3206は、実施形態3に関連して上述したように、NALユニット21(3228)で構成される奥行きレイヤ3226をさらに含むことができる。実施形態3に関連して上述したように、NALユニット21は、MVC NALユニット・ヘッダ拡張に設けられたその他の情報に加えて、3DVビューIDおよび3DVレイヤIDを含むことができる。
実施形態4〜7に関連して上述したように、デコーダ400は、NALユニット17によって与えられるレイヤ間依存関係構造など、SPSに設けられた情報を用いて参照ピクチャ・リストを再構築し、この参照ピクチャ・リストを使用して適切に3DVコンテンツを復号することができる。例えば、3DVビューIDおよび3DVレイヤIDに基づいて、デコーダ400は、SPSに含めて伝達されるレイヤ間依存関係構造中の対応するレイヤ(この場合には奥行きレイヤ3226)の役割を決定することができる。ここで、3DVビューIDおよび3DVレイヤIDは、奥行きレイヤ3226の復号に2D映像レイヤ3218を参照として使用すべきであることを示すことができる。
図32に示すように、時点T0のその他の各3DVビューは、3DVビュー中の2D映像レイヤに対応するNALユニット20および奥行きレイヤに対応するNALユニット21で構成される。ビュー3208および3210内のNALユニットは、図12に関連して上述したように、ビュー1206および1208中のNALユニットと同じ機能を有することができる。同様に、時点T1の3DVビューのセットは、3DVビュー3206中のNALユニット5が3DVビュー3212中のNALユニット1 3230で置き換えられることを除けば、基本的に時点T0の3DVビューのセットと同様に構築される。実施形態3に関連して上述したように、NALユニット1は、非IDRピクチャの符号化済みスライスの映像データを含む。
次に、図33を参照すると、レイヤ間依存関係構造を利用することによってネットワーク・トラフィックを管理するシステム3300が示してある。システム3300は、図7および図8に関連して上述した伝送システム/装置700および受信システム/装置800を含むことができる。具体的には、伝送システム/装置700のエンコーダ710は、本明細書に記載の様々な実施態様に関連して上述したエンコーダ300によって実施することができる。同様に、受信システム/装置800のデコーダ820は、本明細書に記載の様々な実施態様に関連して上述したデコーダ400によって実施することができる。システム3300の入力および出力は、図33では、「入力映像(1つまたは複数)」および「出力映像」として示してある。少なくともこの実施態様では、これらが複数のレイヤを含む3D映像を指していることは、明らかであろう。
システム3300は、伝送システム/装置700と受信システム/装置800の間のネットワーク3350中に設けられたネットワーク・デバイス/システム3301をさらに含むことができる。ネットワーク3350は、例えば、インターネット、広域ネットワークやローカル・エリア・ネットワーク(LAN)などの有線ネットワーク、または無線携帯電話網や無線LANなどの無線ネットワークとすることができる。ネットワーク・デバイス3301は、有線ネットワーク中のルータとして実施することもできるし、無線ネットワーク中の基地局として実施することもできる。図33に示すように、ネットワーク・デバイス3301は、解析器3302、制御装置3304、ネットワーク・トラフィック・モニタ3306、および転送モジュール3308を含むことができる。さらに、ネットワーク・デバイス3301の各要素は、ハードウェア要素として実施することもできるし、ソフトウェアとハードウェアの組合せとして実施することもできる。ネットワーク・デバイス3301およびその要素の機能については、ネットワーク・デバイス3301が実施することができる図34に示す方法3400に関連して、以下でさらに詳細に述べる。
図34および引き続き図33を参照して、ネットワーク資源を管理する方法3400について述べる。方法3400は、ステップ3402から開始することができ、このステップで、解析器3302は、3DVレイヤのレイヤ間依存関係構造を示す受信したシンタックス要素を構文解析して、この構造に基づいて3DVレイヤの少なくともサブセットの転送優先順位を決定することができる。例えば、シンタックス要素は、伝送システム/装置700から、例えば実施形態5〜7に関連して上述したように表13または14に従って相互依存関係構造を示すことができるNALユニット17に含まれた状態で受信することができる。
ここで、解析器3302は、相互依存関係構造に示される3DVレイヤの重要性に従って転送優先順位を決定することができる。例えば、3DVレイヤidは、最小の数が最高の優先順位に対応し、最大の数が最低の優先順位に対応するように構成することができる。図15の相互依存関係構造および表1の3DVレイヤ識別子を利用する場合には、解析器3302は、3DVレイヤ識別子に基づいて、2D映像レイヤの優先順位が最も高く、奥行きレイヤの優先順位がその次に高い、といったことなどを決定することができる。具体的には、3DVレイヤ識別子は、3DVコンテンツの形成に関する寄与の重要性に従って順位付けすることができる。例えば、図2を参照すると、2D映像の奥行きレイヤ204は、ビュー中の主要オブジェクトに3次元効果を与えるが、隠蔽映像レイヤ206または隠蔽奥行きレイヤ208は3次元効果を与えないので、隠蔽映像レイヤ206または隠蔽奥行きレイヤ208より重要性が高いと考えることができる。異なる3DVレイヤ間の重要性の決定については、様々な変形形態を適用することができる。
例えば、1つの変形形態は、レイヤの優先順位を、レイヤ間依存関係構造中にレイヤが有している参照の数、または特定のレイヤを含む参照ピクチャ・リストの数に従って決めるものである。例えば、レイヤ間依存関係構造および/またはそれに対応するレイヤ間参照が決定されたのに応答して、解析器3302は、最も多数のレイヤから参照されたレイヤに最高の優先順位を割り当て、参照された数が最も少ないレイヤに最低の優先順位を割り当てることができる。例えば、図15のレイヤ間依存関係構造では、2D映像レイヤが、3つのレイヤから参照されるので最高の優先順位を有することになり、1つのレイヤから参照される奥行きレイヤが、その次に高い優先順位を有することになる、などである。
その他の変形形態は、適切にレイヤを符号化/復号するために、利用する参照の数に従って3DVレイヤを順序付けすることに関することがある。例えば、実施形態7に関連して上述した相互依存関係構造では、隠蔽映像レイヤ、隠蔽奥行きレイヤ、および透明度レイヤは、それぞれ2つの(レイヤ間)参照を利用するので、最低の優先順位を与えることができ、奥行きレイヤは、1つの(レイヤ間)参照を利用するので、その次に高い優先順位を与えることができ、2D映像レイヤは、いかなる(レイヤ間)参照も利用しないので、最高の優先順位を与えることができる。
さらに、様々な組合せを適用して、優先順位を決定することもできる。例えば、3Dビューを描画する際の所与のレイヤの重要性および当該所与のレイヤを参照するレイヤの数の両方を考慮した重み関数を使用して、転送優先順位を決定することができる。さらに、レイヤ間参照に加えて、その他のタイプの参照も考慮することができることを理解されたい。例えば、上述の優先順位の決定では、さらに、特定のレイヤが依存する時間的参照およびビュー間参照も考慮することができる。従って、上述の道理は、時間的参照およびビュー間参照ならびに/あるいはレイヤ間参照など、任意のタイプの参照および/または参照の組合せに適用することができる。
ステップ3404で、解析器3302は、3DVレイヤを構築するためのデータ・ユニットを受信することができる。例えば、図11を再度参照すると、解析器3302は、2D映像レイヤ1118を構築するために利用されるNALユニット16、14および5を受信することができる。解析器3302は、さらに、奥行きレイヤ1120を構築するために使用されるNALユニット16および20なども受信することができる。
ステップ3406で、ネットワーク・トラフィック・モニタ3306は、ネットワーク3350上のトラフィック/ネットワーク輻輳を測定することができる。当業者なら理解するであろうが、ここでは、様々な既知のネットワーク・トラフィック・モニタを利用することができる。
ステップ3408で、制御装置3304は、ネットワーク・トラフィック・モニタ3306から受信した輻輳測定値に基づいて、ステップ3406で測定したネットワーク・トラフィックが第1の輻輳しきい値を満たすかどうかを判定することができる。ここでは、必要に応じて、複数の異なる輻輳しきい値を利用して、上述のようにレイヤ間依存関係構造に基づくことができる決定した転送優先順位に従って3DVレイヤと関連付けることができることを理解されたい。例えば、3DVコンテンツを描画するために利用される各3DVレイヤごと、または削除可能な各3DVレイヤごとに、1つの輻輳しきい値を使用することもできる。例えば、表1を再度参照して、ステップ3402に関連して上述したように3DVレイヤID番号に従って転送優先順位を決定した場合には、例えば、第1のしきい値を、透明度レイヤと関連付け、第1のしきい値より高いレベルのネットワーク輻輳に対応する第2のしきい値を、隠蔽奥行きレイヤと関連付け、第1および第2のしきい値より高いレベルのネットワーク輻輳に対応する第3のしきい値を、隠蔽映像レイヤと関連付けることができる。
従って、第1の輻輳しきい値が満たされた場合には、ステップ3412で、制御装置3304は、優先順位が最低である3DVレイヤについてステップ3404で受信したユニットまたはNALユニットを削除することができ、転送モジュール3308に、(次のしきい値が満たされていない場合には)残りの3DVレイヤのユニットを受信システム/装置800に転送するように指示することができる。第1の輻輳しきい値が満たされていない場合には、転送モジュール3308は、ステップ3410で、制御装置3304の指示の下で、全ての3DVレイヤのユニットを転送することができる。N個の3DVレイヤのそれぞれについて、しきい値の決定を繰り返すことができることを理解されたい。例えば、N個のレイヤは、3DVコンテンツを描画するために1つまたは複数のビュー内で利用されるレイヤの数に対応することができる。従って、しきい値の決定は、各しきい値ごとに繰り返すことができ、その結果に応じて、ユニットの削除および転送の判断を行うことができる。
例えば、ステップ3412の後、第2のしきい値が満たされない場合には、ステップ3412で、転送モジュール3308が、N−1個の3DVレイヤのユニットを受信ユニット800に転送することができる。あるいは、ステップ3412の後、制御装置3304が、最初のN−2個のしきい値が満たされたと判定した場合には、この方法は、ステップ3414に進むことができ、このステップで、制御装置3304は、(N−1)番目の輻輳しきい値が満たされているかどうかを判定することができる。(N−1)番目の輻輳しきい値が満たされていない場合には、ステップ3416で、転送モジュール3308は、制御装置3304の指示の下で、優先順位が最高と2番目の3DVレイヤのユニットを転送することができる。さらに、ステップ3416で、制御装置3304は、N−2個の優先順位が最低の3DVレイヤを、それらN−2個の最低の優先順位の3DVレイヤのしきい値が満たされているという理由で、削除することができる。(N−1)番目の輻輳しきい値が満たされている場合には、ステップ3418で、転送モジュール3308は、制御装置3304の指示の下で、優先順位が最高である3DVレイヤのユニットを転送することができる。さらに、制御装置3304は、(N−1)個の優先順位が最低である3DVレイヤのユニットを削除することができる。従って、方法3400は、M番目のしきい値が満たされ、(M+1)番目のしきい値が満たされないときに、例えばM個の優先順位が最低の3DVレイヤの例えばNALユニットなどのユニットが削除され、残りの優先順位の高いレイヤが転送されるように、しきい値の決定を進めることができる。なお、この例では、受信装置/システム800が少なくとも一部のコンテンツを確実に復号することができるように、少なくとも優先順位が最高であるレイヤは削除されないことを保証するために、N−1個のしきい値しか考慮していないことに留意されたい。ただし、方法3400の変形形態を利用することもできる。また、ネットワーク輻輳の任意の変化に対応するために、方法3400の1つまたは複数のステップを定期的に繰り返すことができることにも留意されたい。
方法3400以外の実施態様も可能であることは明らかであろう。このような実施態様の1つは、さらに一般的であり、3次元映像(3DV)レイヤ間のレイヤ間依存関係構造を示すシンタックス要素にアクセスすることを含む。このアクセスは、例えば、ステップ3402に示すように受信したシンタックス要素を構文解析することによって実行することができる。
また、この実施態様では、この構造に基づいて、これらの3DVレイヤのうちの特定の3DVレイヤの伝送優先順位を決定する。伝送優先順位は、例えば、ストリーム中のピクチャ(またはピクチャの一部)の転送あるいはストリームからのピクチャ(またはピクチャの一部)の削除に関する優先順位とすることができる。伝送優先順位は、例えば、その特定の3DVレイヤをどれだけの数のレイヤが参照(レイヤ間参照、ビュー間参照および/または時間的参照)として使用しているかを判定することによって、決定することができる。
また、この実施態様では、この特定の3DVレイヤに属する符号化済みデータを伝送するかどうかを判定する。伝送するかどうかの判定は、この特定の3DVレイヤの決定した伝送優先順位、およびネットワーク輻輳を示す指標に基づいて行う。ネットワーク輻輳は、例えば、ステップ3406のように決定することができる。ネットワーク輻輳を示す指標としては、例えば、ステップ3408および3414のように、1つまたは複数の輻輳しきい値が満たされているかどうかを示すフラグ(またはフラグのセット)とすることができる。その他の指標としては、例えば、ネットワーク・アクティビティの測度(スループット率、エラー率、再伝送要求の数または率、確認の数または率など)などが挙げられる。
さらに別の実施態様では、このような伝送優先順位にアクセスして、この特定の3DVレイヤのアクセスした伝送優先順位、およびネットワーク輻輳を示す指標に基づいて、この特定の3DVレイヤに属する符号化済みデータを伝送するかどうかを判定する。ただし、この実施態様では、これらの3DVレイヤの間のレイヤ間依存関係構造を示すシンタックスにアクセスする必要はない。また、この実施態様では、レイヤ間依存関係構造に基づいて伝送優先順位を決定する必要もない。
また、伝送優先順位が、完全にまたは部分的に、その他の情報に基づくこともあることは、明らかであろう。このような情報としては、例えば、AVC、MVCまたはSVCシステムに関連する時間的レベルID、優先順位IDまたはビューIDなどが挙げられる。
従って、発明者等は、特定のフィーチャおよび特徴を有する1つまたは複数の実施態様を提供する。ただし、記載した実施態様のフィーチャおよび特徴は、その他の実施態様に適合させることもできる。
本願に記載した実施態様およびフィーチャのいくつかは、H.264/MPEG−4 AVC(AVC)規格、MVC拡張を有するAVC規格、またはSVC拡張を有するAVC規格の状況で使用することができる。さらに、いくつかの実施態様は、(a)MPEGおよびITU−TのJoint Collaborative Team for Video Coding (JCT−VC)、(b)MPEGのHigh−performance Video Coding group、(c)ITU−TのVideo Coding Experts Group(VCEG)のNext Generation Video Coding group、(d)MPEGの3D Video Coding group、(e)MPEGまたはITU−Tの1つまたは複数と関連するその他の任意のグループ、あるいは(f)任意の企業によって開発された任意の規格(独占または公開)からの符号化規格または符号化提案の状況で使用することもできる。ただし、これらの実施態様およびフィーチャは、別の(既存のまたは将来の)規格の状況でも、あるいは規格を伴わない状況でも使用することができる。
さらに、いくつかの実施態様では、例えばSEIメッセージ、スライス・ヘッダ、その他の高レベル・シンタックス、非高レベル・シンタックス、帯域外情報、データストリーム・データ、および暗示的信号通信など(ただしこれらに限定されない)、様々な技術を用いて、情報を信号通信することができる。従って、本明細書に記載の実施態様が特定の文脈で記述されていることがあっても、このような記述は、どのような意味においても、フィーチャおよび概念をこれらの実施態様または文脈に限定するものとして解釈するべきではない。
さらに、多くの実施態様は、エンコーダ、デコーダ、デコーダの出力を処理するポストプロセッサ、またはエンコーダへの入力を提供するプリプロセッサの1つまたは複数において実施することができる。さらに、他の実施態様も、本開示によって企図されている。
本明細書における「一実施形態」もしくは「実施形態」、または「一実施態様」もしくは「実施態様」、あるいはそれらの表現の変形表現は、当該実施形態に関連して述べられている特定のフィーチャ、構造、特性などが、少なくとも1つの実施形態に含まれる、ということを意味している。従って、本明細書を通じて様々な箇所に見られる「一実施形態において」もしくは「実施形態において」、または「一実施態様において」もしくは「実施態様において」、あるいはその他の任意の変形表現は、必ずしも同じ実施形態を指しているわけではない。
例えば「A/B」、「Aおよび/またはB」ならびに「AおよびBの少なくとも1つ」など、「/」、「および/または」ならびに「少なくとも1つ」の何れかを用いている場合、それは、1つ目に挙げた選択肢(A)のみを選択する場合、2つ目に挙げた選択肢(B)のみを選択する場合、または両方(AおよびB)の選択肢を選択する場合を包含することを意図したものであることを理解されたい。他にも例えば、「A、Bおよび/またはC」、「A、BおよびCの少なくとも1つ」、ならびに「A、BまたはCの少なくとも1つ」の場合も、これらの言い回しは、1つ目に挙げた選択肢(A)のみを選択する場合、2つ目に挙げた選択肢(B)のみを選択する場合、3つ目に挙げた選択肢(C)のみを選択する場合、1つ目と2つ目に挙げた選択肢(AおよびB)のみを選択する場合、1つ目と3つ目に挙げた選択肢(AおよびC)のみを選択する場合、2つ目と3つ目に挙げた選択肢(BおよびC)のみを選択する場合、または3つ全ての選択肢(AおよびBおよびC)を選択する場合を包含することを意図したものである。当技術分野および関連分野の当業者には容易に分かるであろうが、このことは、列挙される項目の数がいくつであっても、拡張して当てはめることができる。
また、本明細書で使用する「ピクチャ」および「画像」という用語は、入れ替え可能であり、例えば、静止画像の全体または一部(一部分)あるいは映像シーケンスに属するピクチャの全体または一部(一部分)を指している。さらに一般的には、ピクチャは、例えば、画像または映像データの任意のセットを指している。ピクチャは、例えば、ピクセル、マクロブロック、スライス、フレーム、フィールド、フル・ピクチャ、ピクチャ中のオブジェクトと接する領域、ピクチャの前景、ピクチャの背景、またはピクチャ中の特定の座標(x,y)とすることができる。同様に、ピクチャの「一部分」は、例えば、ピクセル、マクロブロック、スライス、フレーム、フィールド、ピクチャ中のオブジェクトと接する領域、ピクチャの前景、ピクチャの背景、またはピクチャ中の特定の座標(x,y)とすることができる。別の例として、奥行きピクチャ(奥行き画像)は、例えば、完全な奥行きマップ、または例えば対応する映像フレームの1つのマクロブロックについての奥行き情報しか含まない部分的な奥行きマップとすることができる。
さらに、当業者なら、レイヤ(あるいは「映像」または「画像」または「ピクチャ」)が、様々な映像構成要素の何れか、またはそれらの組合せを指すことができることを理解するであろう。こうした構成要素またはそれらの組合せとしては、例えば、輝度、クロミナンス、Y(YUVまたはYCbCrまたはYPbPrまたはYPcPrのY)、U(YUVのU)、V(YUVのV)、Cb(YCbCrのCb)、Cr(YCbCrのCr)、Pb(YPbPrのPb)、Pr(YPbPrまたはYPcprのPr)、Pc(YPcPrのPc)、赤(RGBの赤)、緑(RGBの緑)、青(RGBの青)、S−Video、およびこれらの構成要素の何れかのネガティブまたはポジティブなどが挙げられる。さらに、これらの様々なタイプの構成要素を、上述した実施態様とともに使用することができる。例えば、YUVの構成要素のセットを、上述の1つまたは複数の実施態様とともに使用することができ、通常の実施態様では、YUVは、マクロブロック・レベルで結合される。さらに、その他のピクチャ・タイプを、本明細書に記載した実施態様およびフィーチャとともに使用することができる。このようなその他のピクチャ・タイプとしては、例えば、2D映像、奥行き、隠蔽または背景、透明度またはエッジ不連続性以外の情報を含むピクチャなどが挙げられる。
さらに、本願またはその特許請求の範囲では、様々な情報を「決定する」ことに言及することがある。情報を決定すると言う場合には、例えば、情報を推定する、情報を計算する、情報を予測する、リストまたはその他のデータ・セットから情報を特定する、あるいはメモリから情報を取り出す、などのうちの1つまたは複数を含むことができる。
同様に、「アクセスする」も、意味の広い言葉として用いている。情報にアクセスすると言う場合には、例えば、情報を使用する、記憶する、送信する、伝送する、受信する、取り出す、修正する、構文解析する、または提供するなどの任意の動作を含むことができる。
多くの実施態様で、「参照」に言及している。「参照」は、例えば、参照からのピクセル・ベースの差を使用してソースを予測する、従来の参照とすることができる。あるいは、参照は、異なる方法で使用してソースを予測することもできる。例えば、一実施態様では、エッジ位置またはエッジの不連続性の測度を、ソースの予測に使用する。一般に、参照から任意の情報を流用して、ソースの予測に役立てることができる。ピクセル値、エッジ位置およびエッジ不連続性の測度など、情報の例を与えたが、その他のタイプの情報も可能である。
本明細書の記載した実施態様は、例えば、方法またはプロセス、装置、ソフトウェア・プログラム、データ・ストリーム、あるいは信号において実施することができる。1つの形態の実施態様の状況でしか述べていない場合でも(例えば方法としてしか述べていない場合でも)、記述しているフィーチャの実施態様は、その他の形態(例えば装置やプログラム)で実施することもできる。装置は、例えば適当なハードウェア、ソフトウェア、およびファームウェアにおいて実施することができる。方法は、例えば、コンピュータ、マイクロプロセッサ、集積回路またはプログラマブル論理デバイスなど処理デバイス一般を指す、プロセッサなどの装置において実施することができる。プロセッサとしては、例えばコンピュータ、携帯電話、携帯情報端末(PDA)、およびその他のエンド・ユーザ間での情報通信を容易にするデバイスなどが挙げられる。
本明細書に記載した様々なプロセスおよびフィーチャの実施態様は、様々に異なる機器またはアプリケーションで実施することができ、具体的には例えば、データの符号化および復号に関連する機器またはアプリケーションで実施することができる。このような機器の例としては、エンコーダ、デコーダ、デコーダの出力を処理するポストプロセッサ、エンコーダへの入力を提供するプリプロセッサ、ビデオ・コーダ、ビデオ・デコーダ、ビデオ・コーデック、ウェブ・サーバ、セット・トップ・ボックス、ラップトップ、パーソナル・コンピュータ、携帯電話、PDA、およびその他の通信デバイスが挙げられる。機器は、移動機器とすることも、移動可能な車両に設置することもできることは明らかであろう。
さらに、これらの方法は、プロセッサによって命令を実行することによって実施することができ、これらの命令(および/または実施態様により生成されるデータ値)は、例えば集積回路、ソフトウェア・キャリア、あるいは例えばハードディスク、コンパクト・ディスク、ランダム・アクセス・メモリ(RAM)、または読取り専用メモリ(ROM)などその他の記憶デバイスなどのプロセッサ可読媒体に記憶することができる。これらの命令は、プロセッサ可読媒体上に実装されるアプリケーション・プログラムを構成することができる。命令は、例えば、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せに含めることができる。命令は、例えば、オペレーティング・システム、別個のアプリケーション、またはその両者の組合せに見ることができる。従って、プロセッサは、例えば、プロセスを実行するように構成されたデバイスおよびプロセスを実行するための命令を有するプロセッサ可読媒体(記憶デバイスなど)を含むデバイスの両方の特徴を有することができる。さらに、プロセッサ可読媒体は、命令に加えて、または命令の代わりに、実施態様によって生成されるデータ値を記憶することもできる。
実施態様は、例えば記憶または伝送することができる情報を担持するようにフォーマット化された様々な信号を生成することができることは、当業者には明らかであろう。このような情報としては、例えば、方法を実行するための命令、または記載した実施態様の1つによって生成されるデータなどが挙げられる。例えば、信号は、記載した実施形態のシンタックスを書き込む、または読み取るための規則をデータとして担持するように、あるいは記載した実施形態によって書き込まれた実際のシンタックス値をデータとして担持するようにフォーマット化することができる。このような信号は、例えば、(例えばスペクトルの無線周波部分を用いて)電磁波として、またはベースバンド信号として、フォーマット化することができる。フォーマット化は、例えば、データ・ストリームの符号化、および符号化済みデータ・ストリームによる搬送波の変調などを含むことができる。信号が担持する情報は、例えば、アナログ情報またはディジタル情報とすることができる。信号は、既知の通り、様々な有線または無線リンクを介して伝送することができる。信号は、プロセッサ可読媒体に記憶することができる。
上記の実施態様の記述では、開示を合理化し、様々な特徴の1つまたは複数の理解を助ける目的で、様々な特徴を、1つの実施態様、図面または記述にまとめている箇所があることを理解されたい。しかし、この開示方法は、請求する発明が、各請求項に明示的に記載している以上の特徴を必要とするという意図を表していると解釈すべきではない。そうではなく、以下の特許請求の範囲が表すように、本発明の特徴は、上記に開示した1つの実施形態の全てのフィーチャを含まないこともある。従って、各請求項が別々の実施態様を提供することを理解されたい。
いくつかの実施態様について説明した。しかし、様々な修正を加えることができることを理解されたい。例えば、異なる実施態様の要素を組み合わせて、補足して、修正して、または除去して、その他の実施態様を生み出すこともできる。さらに、機能ブロック間で、動作を入れ替えることもできる。さらに、その他の構造およびプロセスを、開示した構造およびプロセスの代わりに用いることもでき、その結果得られる実施態様では、開示した実施態様と少なくとも実質的には同じ1つまたは複数の機能が、少なくとも実質的には同じ1つまたは複数の方法で実行されて、少なくとも実質的には同じ1つまた複数の結果が得られることは、当業者なら理解するであろう。従って、本願では、上記その他の実施態様を企図し、それらの実施態様は、以下の特許請求の範囲に含まれる。