[0021]一般に、本開示の技法は3次元(3D)ビデオコーディングに関する。すなわち、これらの技法を使用してコーディングされたビデオデータは、3次元効果を生成するためにレンダリングされ、表示され得る。たとえば、異なるビューの2つの画像(すなわち、わずかに異なる水平位置を有する2つのカメラパースペクティブに対応する)は、一方の画像が閲覧者の左眼によって見られ、他方の画像が閲覧者の右眼によって見られるように、実質的に同時に表示され得る。
[0022]3D効果は、たとえば、立体視(stereoscopic)ディスプレイまたは自動立体視(autostereoscopic)ディスプレイを使用して達成され得る。立体視ディスプレイは、2つの画像を相応にフィルタ処理するアイウェア(eyewear)とともに使用され得る。たとえば、パッシブ眼鏡は、正しい眼が正しい画像を閲覧することを保証するために偏光レンズまたは異なるカラーレンズを使用して画像をフィルタ処理し得る。アクティブ眼鏡は、別の例として、立体視ディスプレイと協調して交互のレンズを迅速に閉じ得、それにより、左眼画像を表示することと右眼画像を表示することとを交互に行い得る。自動立体視ディスプレイは、眼鏡が必要とされないような方法で2つの画像を表示する。たとえば、自動立体視ディスプレイは、各画像が閲覧者の適切な眼に投影されるように構成されたミラーまたはプリズムを含み得る。
[0023]本開示の技法は、テクスチャデータと深度データとをコーディングすることによって3Dビデオデータをコーディングすることに関する。概して、「テクスチャ」という用語は、画像のルミナンス(すなわち、輝度または「ルーマ」)値と画像のクロミナンス(すなわち、色または「クロマ」)値とを説明するために使用される。いくつかの例では、テクスチャ画像は、1セットのルミナンスデータと、青色相(Cb)および赤色相(Cr)のための2セットのクロミナンスデータとを含み得る。4:2:2または4:2:0などの特定のクロマフォーマットでは、クロマデータは、ルーマデータに関してダウンサンプリングされる。すなわち、クロミナンスピクセルの空間解像度は、対応するルミナンスピクセルの空間解像度よりも低く、たとえば、ルミナンス解像度の1/2または1/4であり得る。
[0024]深度データは、概して、対応するテクスチャデータの深度値を表す。たとえば、深度画像は、各々が対応するテクスチャデータの深度を表す深度ピクセルのセットを含み得る。深度データは、対応するテクスチャデータの水平ディスパリティを決定するために使用され得る。したがって、テクスチャデータと深度データとを受信するデバイスは、一方のビュー(たとえば、左眼ビュー)のための第1のテクスチャ画像を表示し、深度値に基づいて決定された水平ディスパリティ値だけ第1の画像のピクセル値をオフセットすることによって、他方のビュー(たとえば、右眼ビュー)のための第2のテクスチャ画像を生成するように第1のテクスチャ画像を変更するために深度データを使用し得る。概して、水平視差(または単に「視差」)は、右ビュー中の対応するピクセルに対する第1のビュー中のピクセルの水平空間オフセットを表し、2つのピクセルは、2つのビュー中で表される同じオブジェクトの同じ部分に対応する。
[0025]さらに他の例では、画像について定義されたゼロディスパリティ平面に対して所与のピクセルに関連する深度が定義されるように、画像平面に直交するz次元におけるピクセルについて深度データが定義され得る。そのような深度は、ピクセルを表示するための水平視差を作成するために使用され得、その結果として、ピクセルは、0視差平面に対するピクセルのz次元深度値に応じて、左眼と右眼とで異なるように表示される。
[0026]ゼロディスパリティ平面は、ビデオシーケンスの異なる部分に対して変化し得、ゼロディスパリティ平面に対する深度の量も変化し得る。ゼロディスパリティ平面上に位置するピクセルは、左眼と右眼とに対して同様に定義され得る。ゼロディスパリティ平面の前に位置するピクセルは、ピクセルが画像平面に直交するz方向の画像から出てくるように見える知覚を作成するように、(たとえば、水平ディスパリティを用いて)左眼と右眼とに対して異なるロケーションで表示され得る。0視差平面の後に位置するピクセルは、深度のわずかな知覚まで、わずかなぼかしとともに表示され得るか、または(たとえば、0視差平面の前に位置するピクセルの水平視差とは反対の水平視差を用いて)左眼と右眼とに対して異なるロケーションで表示され得る。他の多くの技法も、画像の深度データを伝達または定義するために使用され得る。
[0027]2次元ビデオデータは、概して、その各々が特定の時間インスタンスに対応する、個別ピクチャのシーケンスとしてコーディングされる。すなわち、各ピクチャは、シーケンス中の他の画像の再生時間に対する関連する再生時間を有する。これらのピクチャはテクスチャピクチャまたはテクスチャ画像と考えられ得る。深度ベースの3Dビデオコーディングでは、シーケンス中の各テクスチャピクチャは深度マップにも対応し得る。すなわち、テクスチャピクチャに対応する深度マップは、対応するテクスチャピクチャのための深度データを表す。マルチビュービデオデータは、様々な異なるビューのためのデータを含み得、各ビューは、テクスチャピクチャと、対応する深度ピクチャとのそれぞれのシーケンスを含み得る。
[0028]上述したように、画像は特定の時間インスタンスに対応し得る。ビデオデータは、アクセスユニットのシーケンスを使用して表され得、各アクセスユニットは、特定の時間インスタンスに対応するすべてのデータを含む。したがって、たとえば、マルチビュービデオデータ+深度の場合、共通時間インスタンスについての各ビューからのテクスチャ画像+テクスチャ画像の各々についての深度マップはすべて、特定のアクセスユニット内に含まれ得る。アクセスユニットは、テクスチャ画像に対応するテクスチャコンポーネントのためのデータと、深度マップに対応する深度コンポーネントのためのデータとを含み得る。
[0029]このようにして、3Dビデオデータは、キャプチャまたは生成されたビュー(テクスチャ)が対応する深度マップに関連する、マルチビュービデオ+深度フォーマットを使用して表され得る。その上、3Dビデオコーディングでは、テクスチャと深度マップとはコーディングされ、3Dビデオビットストリーム中に多重化され得る。深度マップはグレースケール画像としてコーディングされ得、深度マップの「ルーマ」サンプル(すなわち、ピクセル)は深度値を表す。従来のイントラコーディング方法およびインターコーディング方法は深度マップコーディングのために適用され得る。
[0030]深度マップは、通常、シャープエッジと一定のエリアとを含み、深度マップ中のエッジは、一般に、対応するテクスチャデータとの強い相関を提示する。テクスチャと対応する深度との間の異なる統計値および相関により、異なるコーディング方式が、2Dビデオコーデックに基づく深度マップのために設計されており、設計され続ける。
[0031]深度マップコーディングに特有であるいくつかのコーディング方式は、以下でより詳細に説明するように、深度マップのブロックを様々な予測領域に区分することに関する。たとえば、深度マップのブロックは、以下でより詳細に説明するように、ウェッジレット(Wedgelet)パターンまたは輪郭(Contour)パターンを使用して区分され得る。概して、ウェッジレットパターンは、深度マップデータのブロックを通して描画される任意のラインによって画定されるが、輪郭区分では、深度ブロックが2つの不規則形状領域に区分され得る。
[0032]本開示の技法は、一般に深度情報をコーディングすることに関し、高効率ビデオコーディング(HEVC)規格とともに適用可能であり得る。たとえば、ジョイントビデオチーム(JVT:Joint Video Team)は、最近、前に開発されたビデオコーディング規格よりも高い効率を与えるHEVCのベースバージョン(2D)を開発した。3Dビデオコーディング共同研究部会(JCT−3V:Joint Collaboration Team on 3D Video Coding)は、現在、HEVCへの拡張として2つの3次元ビデオ(3DV)ソリューションの研究を進めている。一例は、MV−HEVCと呼ばれるHEVCのマルチビュー拡張を含む。別の例は深度向上3Dビデオ拡張(3D−HEVC)を含む。3D−HEVCのための基準ソフトウェア3D−HTMバージョン5.1の一例がhttps://hevc.hhi.fraunhofer.de/svn/svn_3DVCSoftware/tags/HTM-5.1/において公的に入手可能である。ソフトウェア説明書がhttp://phenix.it-sudparis.eu/jct2/doc_end_user/documents/2_Shanghai/wg11/JCT3V-B1005-v1.zip(文書番号B1005)から入手可能である。
[0033]3D−HEVCでは、各アクセスユニットが複数のビューコンポーネントを含み、各々が、一意のビューid、またはビュー順序インデックス、またはレイヤidを含んでいる。ビューコンポーネントはテクスチャビューコンポーネントならびに深度ビューコンポーネントを含んでいる。テクスチャビューコンポーネントは1つまたは複数のテクスチャスライスとしてコーディングされ得、深度ビューコンポーネントは1つまたは複数の深度スライスとしてコーディングされ得る。
[0034]いくつかの事例では、深度情報がイントラコーディングされ得、それは、所与のピクチャ内の空間的冗長性を低減または除去するために空間予測に依拠する。たとえば、3D−HEVCでは、ビデオコーダ(たとえば、ビデオエンコーダまたはビデオデコーダ)は、深度スライスのイントラ予測ユニットをコーディングするためにベース(2D)HEVC規格からのイントラ予測モードを使用し得る。HEVC規格のイントラモードについて、図4に関して以下でより詳細に説明する。別の例では、ビデオコーダは、深度スライスのイントラ予測ユニットをコーディングするために深度モデリングモード(DMM)を使用し得る。3D−HEVCのDMMについて、図5Aおよび図5Bに関して以下でより詳細に説明する。別の例では、ビデオコーダは、深度スライスのイントラ予測ユニットをコーディングするために領域境界チェーンコーディングを使用し得る。領域境界チェーンコーディングについて、図6に関して以下でより詳細に説明する。ビデオコーダは、残差深度値を生成するために上記のイントラモード(たとえば、HEVCイントラモード、DMM、および/または領域境界チェーンコーディング)を使用し得る。ビデオコーダは、次いで、以下でより詳細に説明するように、残差深度値を変換し、量子化し得る。
[0035]いくつかの事例では、ビデオコーダは、深度スライスのイントラ予測ユニットをコーディングするために簡略深度コーディング(SDC)モードを使用し得る。上記で説明したイントラモードコーディング方式とは対照的に、SDCモードを使用するとき、ビデオコーダは残差深度値を変換または量子化しない。むしろ、いくつかの例では、ビデオコーダは、各パーティションの残差深度値を直接コーディングし得る。そのような例では、ビデオコーダは、現在パーティションの平均値から(たとえば、隣接サンプルに基づいて生成された)予測子を減算することによって、残差深度値を計算し得る。
[0036]他の例では、残差値をコーディングする代わりに、ビデオコーダは、深度ルックアップテーブル(DLT)からのマッピングされたインデックス差分をコーディングし得る。たとえば、ビデオエンコーダは、現在パーティションの平均値のインデックスから予測子のインデックスを減算することによって、インデックス差分を計算し得る。ビデオデコーダは、復号されたインデックス差分と予測子のインデックスとの和を計算し得、DLTに基づいて和を深度値にマッピングし得る。
[0037]このようにして、DLTは元の深度マップの深度値をマッピングし得る。DLTは、ピクチャのフルシーケンスを符号化する前に最初のイントラ期間のフレームを分析することによって構成され得る。いくつかの事例では、ビデオコーダは、増加するインデックスをもつDLTに値を挿入する前に、すべての有効深度値を昇順で分類し得る。いくつかの事例では、予測子の値または平均値はDLT中に含まれず、値はインデックスiにマッピングされ得、平均値−DLT中のi番目のエントリの値によって除算された予測子値の絶対値は最小値である。
[0038]ビデオコーダは、随意のコーディングツールとしてDLTを使用し得る。たとえば、ビデオエンコーダは、分析段において元の深度マップ中に0から最大深度値(たとえば、MAX_DEPTH_VALUE、8ビット深度サンプルの場合は255)までの値の1/2よりも多くが現れる場合、DLTを使用しないことがある。他の場合、ビデオエンコーダは、シーケンスまたはビデオパラメータセットなど、パラメータセット中にDLTをコーディングし得る。いくつかの事例では、有効深度値の数が、最初に指数ゴロム(Expゴロム)コードを使用してコーディングされ得る。各有効深度値は、次いで、Expゴロムコードを用いてコーディングされ得る。
[0039]上記のバージョン5.1など、1つの例示的な3D−HEVC設計によれば、予測DC値を導出するとき、ビデオコーダ(たとえば、ビデオエンコーダまたはビデオデコーダ)は、深度値の上昇特性を考慮することなしに深度値を直接コーディングし得、それは効率的でないことがある。さらに、異なるビューの深度値間の関係式はバージョン5.1では利用されない。したがって、冗長な深度値をシグナリングすることに対して多くのビットが浪費され得る。その上、シーケンスパラメータセット(SPS:sequence parameter set)またはビデオパラメータセット(VPS:video parameter set)のいずれか中にDLTをシグナリングすることは、1つのシーケンス/ビュー内にシーン変化があるときに効率的でないことがある。さらに、より短いコードをもつ深度値がより高い出現確率を有するという仮定がないので、指数ゴロムコードは、深度値をコーディングするときに非効率的であることがある。
[0040]本開示の態様は、一般にDLTシグナリングに関し、特定のコーディング規格に限定されることなしに、上記で3D−HEVCに関して説明した問題のうちの1つまたは複数に対処するために実装され得る。たとえば、本開示のいくつかの態様によれば、DLTの深度値がDLTの別の深度値に対して予測され、コーディングされ得る。一例では、説明の目的で、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリである深度値がdlt_D[i][j]によって示されると仮定する。この例では、第1の有効深度値(たとえば、dlt_D[i][0])がビットストリーム中に直接シグナリングされ得る。DLTの残りの深度値は、DLT中の前の深度値に基づいて差分的にコーディングされ得る(たとえば、dlt_D[i][j]−dlt_D[i][j−1])。このようにして、DLTの第2の深度値(dlt_D[i][j−1])はDLTの第1の値(dlt_D[i][j])に対してコーディングされ得る。
[0041]別の例では、本開示の態様によれば、DLTの深度値がビュー間で予測され得る、すなわち、ビュー間DLT予測。この例では、ビデオコーダは、あるビューのDLT値を第2の異なるビュー中のDLT値に対してコーディングし得る。たとえば、ベースビューは、深度値のセットを有する関連するDLTを含み得る。第2の非ベースビューは、この例では第2のDLTと呼ばれる、深度値のセットを有するそれ自体の関連するDLTを含み得る。本開示の態様によれば、第2のDLTの値は、ベースビューのためのDLTに対してコーディングされ得る。たとえば、第2のDLTの実際の値がシグナリングされる必要がないように、1つまたは複数のシンタックス要素は、第2のDLTの値がベースビューDLT中に現れることを示し得る。
[0042]このようにして、本技法は、深度コーディングのためのビットストリーム中に含まれるデータの量を低減し得る。たとえば、本開示の技法は、DLTに関連する冗長性を低減し得、それによって、符号化ビットストリーム中に深度値をシグナリングするために必要とされるビット数を低減する。
[0043]図1は、深度コーディングのための本開示の技法を利用し得る例示的なビデオ符号化および復号システム10を示すブロック図である。図1に示されているように、システム10は、宛先デバイス14によって後で復号されるべき符号化ビデオデータを生成するソースデバイス12を含む。特に、ソースデバイス12は、符号化ビデオが宛先デバイス14によってアクセスされ得るように、符号化ビデオデータをコンピュータ可読媒体16に記憶し得る。ソースデバイス12および宛先デバイス14は、デスクトップコンピュータ、ノートブック(すなわち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを含み得る。場合によっては、ソースデバイス12および宛先デバイス14は、ワイヤレス通信のために装備され得る。
[0044]上述のように、宛先デバイス14は、コンピュータ可読媒体16に記憶された復号されるべき符号化ビデオデータにアクセスし得る。コンピュータ可読媒体16は、符号化ビデオデータをソースデバイス12から宛先デバイス14に移動することが可能な任意のタイプの非一時的媒体またはデバイスを含み得る。一例では、コンピュータ可読媒体16は、ソースデバイス12が、符号化ビデオデータをリアルタイムで宛先デバイス14に直接送信することを可能にするための通信媒体を備え得る。
[0045]符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス14に送信され得る。通信媒体は、無線周波数(RF)スペクトルまたは1つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成し得る。通信媒体は、ソースデバイス12から宛先デバイス14への通信を可能にするために有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。
[0046]いくつかの例では、コンピュータ可読媒体16がストレージデバイスを含むように、符号化データは出力インターフェース22からストレージデバイスに出力され得る。同様に、符号化データは入力インターフェース28によってストレージデバイスからアクセスされ得る。ストレージデバイスは、ハードドライブ、Blu−ray(登録商標)ディスク、DVD、CD−ROM、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体など、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる一例では、ストレージデバイスは、ソースデバイス12によって生成された符号化ビデオを記憶し得るファイルサーバまたは別の中間ストレージデバイスに対応し得る。
[0047] 宛先デバイス14は、ストリーミングまたはダウンロードを介して、ストレージデバイスから記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶し、その符号化ビデオデータを宛先デバイス14に送信することが可能な任意のタイプのサーバであり得る。例示的なファイルサーバとしては、(たとえば、ウェブサイト用の)ウェブサーバ、FTPサーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブがある。宛先デバイス14は、インターネット接続を含む、任意の標準のデータ接続を介して符号化ビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適であるワイヤレスチャネル(たとえば、Wi−Fi(登録商標)接続)、ワイヤード接続(たとえば、DSL、ケーブルモデムなど)、または両方の組合せを含み得る。ストレージデバイスからの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。
[0048]本開示の技法は、必ずしもワイヤレス適用例または設定に限定されるとは限らない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、動的適応ストリーミングオーバーHTTP(DASH)などのインターネットストリーミングビデオ送信、データ記憶媒体に符号化されたデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオテレフォニーなどの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
[0049]図1の例では、ソースデバイス12は、ビデオソース18と、ビデオエンコーダ20と、出力インターフェース22とを含む。宛先デバイス14は、入力インターフェース28と、ビデオデコーダ30と、ディスプレイデバイス32とを含む。本開示によれば、ソースデバイス12のビデオエンコーダ20は、マルチビューコーディングにおける動きベクトル予測のための技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他のコンポーネントまたは構成を含み得る。たとえば、ソースデバイス12は、外部カメラなどの外部ビデオソース18からビデオデータを受信し得る。同様に、宛先デバイス14は、集積ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。
[0050]図1の図示のシステム10は一例にすぎない。深度コーディングのための技法は、任意のデジタルビデオ符号化および/または復号デバイスによって実行され得る。概して、本開示の技法はビデオ符号化デバイスによって実行されるが、本技法は、一般に「コーデック」と呼ばれるビデオエンコーダ/デコーダによっても実行され得る。その上、本開示の技法は、ビデオプリプロセッサによっても実行され得る。ソースデバイス12および宛先デバイス14は、ソースデバイス12が宛先デバイス14に送信するためのコード化ビデオデータを生成するような、コーディングデバイスの例にすぎない。いくつかの例では、デバイス12、14は、デバイス12、14の各々がビデオ符号化構成要素とビデオ復号構成要素とを含むように、実質的に対称的に動作し得る。したがって、システム10は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスト、またはビデオテレフォニーのためのビデオデバイス12とビデオデバイス14の間の一方向または双方向のビデオ送信をサポートし得る。
[0051]ソースデバイス12のビデオソース18は、ビデオカメラなどのビデオキャプチャデバイス、前にキャプチャされたビデオを含んでいるビデオアーカイブ、および/またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース18は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオとアーカイブビデオとコンピュータ生成ビデオとの組合せを生成し得る。場合によっては、ビデオソース18がビデオカメラである場合、ソースデバイス12および宛先デバイス14は、いわゆるカメラフォンまたはビデオフォンを形成し得る。ただし、上述のように、本開示で説明する技法は、概してビデオコーディングに適用可能であり得、ワイヤレスおよび/またはワイヤード適用例に適用され得る。各場合において、キャプチャされたビデオ、プリキャプチャされたビデオ、またはコンピュータ生成ビデオは、ビデオエンコーダ20によって符号化され得る。符号化ビデオ情報は、次いで、出力インターフェース22によってコンピュータ可読媒体16上に出力され得る。
[0052]コンピュータ可読媒体16は、ワイヤレスブロードキャストまたはワイヤードネットワーク送信などの一時媒体、あるいはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Blu−rayディスク、または他のコンピュータ可読媒体などの記憶媒体(すなわち、非一時的記憶媒体)を含み得る。いくつかの例では、ネットワークサーバ(図示せず)は、たとえば、ネットワーク送信を介して、ソースデバイス12から符号化されたビデオデータを受信し、宛先デバイス14に符号化されたビデオデータを与え得る。同様に、ディスクスタンピング設備など、媒体製造設備のコンピューティングデバイスは、ソースデバイス12から符号化されたビデオデータを受信し、その符号化ビデオデータを含んでいるディスクを生成し得る。したがって、コンピュータ可読媒体16は、様々な例において、様々な形態の1つまたは複数のコンピュータ可読媒体を含むことが理解されよう。
[0053]本開示では、概して、ビデオエンコーダ20が、ある情報をビデオデコーダ30などの別のデバイスに「シグナリング」することに言及することがある。ただし、ビデオエンコーダ20は、いくつかのシンタックス要素をビデオデータの様々な符号化部分に関連付けることによって情報をシグナリングし得ることを理解されたい。すなわち、ビデオエンコーダ20は、いくつかのシンタックス要素をビデオデータの様々な符号化部分のヘッダに記憶することによってデータを「シグナリング」し得る。場合によっては、そのようなシンタックス要素は、ビデオデコーダ30によって受信されおよび復号されるより前に、符号化されおよび記憶され(たとえば、コンピュータ可読媒体16に記憶され)得る。したがって、「シグナリング」という用語は、通信がリアルタイムまたはほぼリアルタイムで行われるか、あるいは、符号化時にシンタックス要素を媒体に記憶し、次いで、この媒体に記憶された後の任意の時間にそのシンタックス要素が復号デバイスによって取り出され得るときなどに行われ得る、ある時間期間にわたって行われるかどうかにかかわらず、概して、圧縮ビデオデータを復号するためのシンタックスまたは他のデータの通信を指し得る。
[0054]宛先デバイス14の入力インターフェース28は、コンピュータ可読媒体16から情報を受信する。コンピュータ可読媒体16の情報は、ビデオエンコーダ20によって定義され、またビデオデコーダ30によって使用される、ブロックおよび他のコーディングされたユニット、たとえば、GOPの特性および/または処理を記述するシンタックス要素を含む、シンタックス情報を含み得る。ディスプレイデバイス32は、復号されたビデオデータをユーザに対して表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。
[0055]図1には示されていないが、いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は、それぞれオーディオエンコーダおよびデコーダと統合され得、適切なMUX−DEMUXユニット、または他のハードウェアおよびソフトウェアを含んで、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理し得る。適用可能な場合、MUX−DEMUXユニットはITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠し得る。
[0056]ビデオエンコーダ20およびビデオデコーダ30はそれぞれ、適用可能なとき、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダまたはデコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。ビデオエンコーダ20およびビデオデコーダ30の各々は1つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合ビデオエンコーダ/デコーダ(コーデック)の一部として統合され得る。ビデオエンコーダ20および/またはビデオデコーダ30を含むデバイスは、集積回路、マイクロプロセッサ、および/またはセルラー電話などのワイヤレス通信デバイスを備え得る。
[0057]ビデオエンコーダ20およびビデオデコーダ30は、ジョイントビデオチーム(JVT)として知られる共同パートナーシップの成果としてISO/IECムービングピクチャエキスパートグループ(MPEG:Moving Picture Experts Group)とともにITU−Tビデオコーディングエキスパートグループ(VCEG:Video Coding Experts Group)によって策定された、ITU−T H.264/MPEG−4(AVC)規格など、ビデオコーディング規格に従って動作し得る。別のビデオコーディング規格は、それのスケーラブルビデオコーディング(SVC)およびマルチビュービデオコーディング(MVC)拡張を含む、H.264規格を含む。H.264規格は、ITU−T研究グループによる、ITU−T勧告H.264、Advanced Video Coding for generic audiovisual servicesに記載されている。ジョイントビデオチーム(JVT)は、H.264/MPEG−4 AVCへの拡張に取り組み続けている。MVCの最新のジョイントドラフトは、「Advanced video coding for generic audiovisual services」、ITU−T勧告H.264、2010年3月に記載されている。
[0058]代替的に、ビデオエンコーダ20およびビデオデコーダ30は、高効率ビデオコーディング(HEVC)規格に従って動作し得、HEVCテストモデル(HM)に準拠し得る。HEVCは、ITU−T VCEGとISO/IEC MPEGとのJCT−VCによって開発された。HEVCの最新ドラフトは、http://phenix.int-evry.fr/jct/doc_end_user/documents/12_Geneva/wg11/JCTVC-L1003-v14.zipから入手可能である。HEVC規格化の取り組みは、HEVCテストモデル(HM)と呼ばれるビデオコーディングデバイスの発展的モデルに基づいていた。HMは、たとえば、ITU−T H.264/AVCに従う既存のデバイスに対してビデオコーディングデバイスのいくつかの追加の能力を仮定する。たとえば、H.264は9個のイントラ予測符号化モードを与えるが、HMは35個ものイントラ予測符号化モードを与え得る。
[0059]概して、HMの作業モデルは、ビデオピクチャ(または「フレーム」)が、ルーマサンプルとクロマサンプルの両方を含む一連のツリーブロックまたは最大コーディングユニット(LCU:largest coding unit)に分割され得ることを記載している。ビットストリーム内のシンタックスデータが、ピクセルの数に関して最大コーディングユニットであるLCUのサイズを定義し得る。スライスは、コーディング順序でいくつかの連続するツリーブロックを含む。ピクチャは、1つまたは複数のスライスに区分され得る。各ツリーブロックは、4分木(quadtree)に従ってコーディングユニット(CU)に分割され得る。概して、4分木データ構造はCUごとに1つのノードを含み、ルートノードはツリーブロックに対応する。CUが4つのサブCUに分割された場合、CUに対応するノードは4つのリーフノードを含み、リーフノードの各々はサブCUのうちの1つに対応する。
[0060]4分木データ構造の各ノードは、対応するCUのシンタックスデータを与え得る。たとえば、4分木のノードは、そのノードに対応するCUがサブCUに分割されるかどうかを示す分割フラグを含み得る。CUのシンタックス要素は、再帰的に定義され得、CUがサブCUに分割されるかどうかに依存し得る。CUがさらに分割されない場合、そのCUはリーフCUと呼ばれる。本開示では、元のリーフCUの明示的分割が存在しない場合でも、リーフCUの4つのサブCUをリーフCUとも呼ぶ。たとえば、16×16サイズのCUがさらに分割されない場合、この16×16CUが決して分割されなくても、4つの8×8サブCUをリーフCUとも呼ぶ。
[0061]CUは、CUがサイズ差異を有しないことを除いて、H.264規格のマクロブロックと同様の目的を有する。たとえば、ツリーブロックは、4つの子ノード(サブCUとも呼ばれる)に分割され得、各子ノードは、今度は親ノードとなり、別の4つの子ノードに分割され得る。4分木のリーフノードと呼ばれる、最後の分割されていない子ノードは、リーフCUとも呼ばれるコーディングノードを備える。コード化ビットストリームに関連するシンタックスデータは、最大CU深さと呼ばれる、ツリーブロックが分割され得る最大回数を定義し得、また、コーディングノードの最小サイズを定義し得る。それに応じて、ビットストリームは最小コーディングユニット(SCU:smallest coding unit)をも定義し得る。本開示では、HEVCのコンテキストにおけるCU、PU、またはTU、あるいは他の規格のコンテキストにおける同様のデータ構造(たとえば、H.264/AVCにおけるマクロブロックおよびそれのサブブロック)のいずれかを指すために「ブロック」という用語を使用する。
[0062]CUは、コーディングノードと、コーディングノードに関連する予測ユニット(PU:prediction unit)および変換ユニット(TU:transform unit)とを含む。CUのサイズは、コーディングノードのサイズに対応し、形状が正方形でなければならない。CUのサイズは、8×8ピクセルから最大64×64以上のピクセルを有するツリーブロックのサイズまで及び得る。各CUは、1つまたは複数のPUと、1つまたは複数のTUとを含み得る。CUに関連するシンタックスデータは、たとえば、CUを1つまたは複数のPUに区分することを記述し得る。区分モードは、CUが、スキップモード符号化またはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、あるいはインター予測モード符号化されるかの間で異なり得る。PUは、形状が非方形になるように区分され得る。CUに関連するシンタックスデータは、たとえば、4分木に従って、CUを1つまたは複数のTUに区分することも記述し得る。TUは、形状が正方形または非正方形(たとえば、矩形)であり得る。
[0063]HEVC規格は、CUごとに異なり得るTUに従う変換を可能にする。TUは、一般に、区分されたLCUについて定義された所与のCU内のPUのサイズに基づいてサイズ決定されるが、常にそうであるとは限らない。TUは、一般に、PUと同じサイズであるかまたはPUよりも小さい。いくつかの例では、CUに対応する残差サンプルは、「残差4分木」(RQT:residual quad tree)として知られる4分木構造を使用してより小さいユニットに再分割され得る。RQTのリーフノードは変換ユニット(TU)と呼ばれることがある。TUに関連するピクセル差分値は、変換されて変換係数が生成され得、その変換係数は量子化され得る。
[0064]リーフCUは、1つまたは複数の予測ユニット(PU)を含み得る。概して、PUは、対応するCUの全部または一部分に対応する空間エリアを表し、そのPUの参照サンプルを取り出すためのデータを含み得る。その上、PUは、予測に関係するデータを含む。たとえば、PUがイントラモード符号化されるとき、PUについてのデータは、PUに対応するTUについてのイントラ予測モードを記述するデータを含み得る残差4分木(RQT)中に含まれ得る。別の例として、PUがインターモード符号化されるとき、PUは、PUのための1つまたは複数の動きベクトルを定義するデータを含み得る。PUのための動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルについての解像度(たとえば、1/4ピクセル精度または1/8ピクセル精度)、動きベクトルが指す参照ピクチャ、および/または動きベクトルの参照ピクチャリスト(たとえば、リスト0、リスト1、またはリストC)を記述し得る。
[0065]1つまたは複数のPUを有するリーフCUはまた、1つまたは複数の変換ユニット(TU)を含み得る。変換ユニットは、上記で説明したように、(TU4分木構造とも呼ばれる)RQTを使用して指定され得る。たとえば、分割フラグは、リーフCUが4つの変換ユニットに分割されるかどうかを示し得る。次いで、各変換ユニットは、さらなるサブTUにさらに分割され得る。TUがさらに分割されないとき、そのTUはリーフTUと呼ばれることがある。概して、イントラコーディングの場合、リーフCUに属するすべてのリーフTUは同じイントラ予測モードを共有する。すなわち、概して、リーフCUのすべてのTUの予測値を計算するために同じイントラ予測モードが適用される。イントラコーディングの場合、ビデオエンコーダ20は、イントラ予測モードを使用して各リーフTUの残差値をTUに対応するCUの一部と元のブロックとの間の差分として計算し得る。TUは、必ずしもPUのサイズに制限されるとは限らない。したがって、TUはPUよりも大きくまたは小さくなり得る。イントラコーディングの場合、PUは、同じCUの対応するリーフTUとコロケートされ得る。いくつかの例では、リーフTUの最大サイズは、対応するリーフCUのサイズに対応し得る。
[0066]その上、リーフCUのTUはまた、残差4分木(RQT)と呼ばれる、それぞれの4分木データ構造に関連付けられ得る。すなわち、リーフCUは、リーフCUがどのようにTUに区分されるかを示す4分木を含み得る。TU4分木のルートノードは概してリーフCUに対応し、CU4分木のルートノードは概してツリーブロック(またはLCU)に対応する。分割されないRQTのTUはリーフTUと呼ばれる。概して、本開示では、特に明記しない限り、リーフCUおよびリーフTUに言及するためにそれぞれCUおよびTUという用語を使用する。
[0067]ビデオシーケンスは、一般に一連のピクチャを含む。本明細書で説明する「ピクチャ」および「フレーム」という用語は互換的に使用され得る。すなわち、ビデオデータを含んでいるピクチャは、ビデオフレームまたは単に「フレーム」と呼ばれることがある。ピクチャグループ(GOP:group of picture)は、概して、ビデオピクチャのうちの一連の1つまたは複数を備える。GOPは、GOP中に含まれるいくつかのピクチャを記述するシンタックスデータを、GOPのヘッダ中、ピクチャのうちの1つまたは複数のヘッダ中、または他の場所に含み得る。ピクチャの各スライスは、それぞれのスライスのための符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ20は、一般に、ビデオデータを符号化するために個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、CU内のコーディングノードに対応し得る。ビデオブロックは、固定サイズまたは可変サイズを有し得、指定のコーディング規格に応じてサイズが異なり得る。
[0068]一例として、HMは、様々なPUサイズでの予測をサポートする。特定のCUのサイズが2N×2Nであると仮定すると、HMは、2N×2NまたはN×NのPUサイズでのイントラ予測をサポートし、2N×2N、2N×N、N×2N、またはN×Nの対称的なPUサイズでのインター予測をサポートする。HMはまた、2N×nU、2N×nD、nL×2N、およびnR×2NのPUサイズでのインター予測のための非対称区分をサポートする。非対称区分では、CUの一方向は区分されないが、他の方向は25%と75%とに区分される。25%の区分に対応するCUの部分は、「n」とその後ろに付く「Up」、「Down」、「Left」、または「Right」という表示によって示される。したがって、たとえば、「2N×nU」は、上部の2N×0.5N PUと下部の2N×1.5N PUとで水平方向に区分された2N×2N CUを指す。
[0069]本開示では、「N×N(NxN)」および「N×N(N by N)」は、垂直寸法および水平寸法に関するビデオブロックのピクセル寸法、たとえば、16×16(16x16)ピクセルまたは16×16(16 by 16)ピクセルを指すために互換的に使用され得る。概して、16×16ブロックは、垂直方向に16ピクセルを有し(y=16)、水平方向に16ピクセルを有する(x=16)。同様に、N×Nブロックは、概して、垂直方向にNピクセルを有し、水平方向にNピクセルを有し、ただし、Nは非負整数値を表す。ブロック中のピクセルは行と列に構成され得る。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要があるとは限らない。たとえば、ブロックはN×Mピクセルを備え得、ただし、Mは必ずしもNに等しいとは限らない。
[0070]CUのPUを使用したイントラ予測コーディングまたはインター予測コーディングの後に、ビデオエンコーダ20は、CUのTUのための残差データを計算し得る。PUは、(ピクセル領域とも呼ばれる)空間領域において予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備え得、TUは、変換、たとえば、残差ビデオデータへの離散コサイン変換(DCT)、整数変換、ウェーブレット変換、または概念的に同様の変換の適用後に、変換領域において係数を備え得る。残差データは、符号化されていないピクチャのピクセルと、PUに対応する予測値との間のピクセル差分に対応し得る。ビデオエンコーダ20は、CUのための残差データを含むTUを形成し、次いで、TUを変換して、CUのための変換係数を生成し得る。
[0071]変換係数を生成するための任意の変換に続いて、ビデオエンコーダ20は、変換係数の量子化を実行し得る。量子化は、概して、係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化され、さらなる圧縮を行うプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。たとえば、量子化中にnビット値がmビット値に切り捨てられ得、ここで、nはmよりも大きい。
[0072]量子化の後に、ビデオエンコーダ20は、変換係数を走査して、量子化変換係数を含む2次元行列から1次元ベクトルを生成し得る。走査は、アレイの前部により高いエネルギー(したがって、より低い周波数)係数を配置し、アレイの後部により低いエネルギー(したがって、より高い周波数)係数を配置するように設計され得る。
[0073]いくつかの例では、ビデオエンコーダ20は、エントロピー符号化され得るシリアル化ベクトルを生成するために、量子化変換係数を走査するためにあらかじめ定義された走査順序を利用し得る。他の例では、ビデオエンコーダ20は適応走査を実施し得る。量子化変換係数を走査して1次元ベクトルを形成した後に、ビデオエンコーダ20は、たとえば、コンテキスト適応型可変長コーディング(CAVLC:context-adaptive variable length coding)、コンテキスト適応型バイナリ算術コーディング(CABAC:context-adaptive binary arithmetic coding)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC:syntax-based context-adaptive binary arithmetic coding)、確率間隔区分エントロピー(PIPE:Probability Interval Partitioning Entropy)コーディング、または別のエントロピー符号化方法に従って1次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ20はまた、ビデオデータを復号する際にビデオデコーダ30が使用するための符号化ビデオデータに関連するシンタックス要素をエントロピー符号化し得る。
[0074]ビデオエンコーダ20はさらに、ブロックベースのシンタックスデータ、ピクチャベースのシンタックスデータ、およびGOPベースのシンタックスデータなどのシンタックスデータを、たとえば、ピクチャヘッダ、ブロックヘッダ、スライスヘッダ、またはGOPヘッダ中でビデオデコーダ30に送り得る。GOPシンタックスデータは、それぞれのGOP中のピクチャの数を表し得、ピクチャシンタックスデータは、対応するピクチャを符号化するために使用される符号化/予測モードを示し得る。
[0075]いくつかの事例では、ビデオエンコーダ20および/またはビデオデコーダ30は深度情報をイントラコーディングし得る。たとえば、3D−HEVCでは、ビデオエンコーダ20および/またはビデオデコーダ30は、深度スライスのイントラ予測ユニットをコーディングするためにベース(2D)HEVC規格からのイントラ予測モードを使用し得る。別の例では、ビデオエンコーダ20および/またはビデオデコーダ30は、深度スライスのイントラ予測ユニットをコーディングするために深度モデリングモード(DMM)を使用し得る。別の例では、ビデオエンコーダ20および/またはビデオデコーダ30は、深度スライスのイントラ予測ユニットをコーディングするために領域境界チェーンコーディングを使用し得る。さらに別の例では、ビデオエンコーダ20および/またはビデオデコーダ30は、深度スライスのイントラ予測ユニットをコーディングするために簡略深度コーディング(SDC)モードを使用し得る。
[0076]SDCコーディングモードに関して、残差深度値をコーディングする代わりに、ビデオエンコーダ20および/またはビデオデコーダ30は、DLTからのマッピングされたインデックス差分をコーディングし得る。たとえば、ビデオエンコーダ20は、現在パーティションの平均値のインデックスから予測子のインデックスを減算することによってインデックス差分を計算し得る。ビデオデコーダ30は、復号されたインデックス差分と予測子のインデックスとの和を計算し得、DLTに基づいて和を深度値にマッピングし得る。このようにして、DLTは元の深度マップの深度値をマッピングし得る。
[0077]本開示の態様はDLTに関する。一例では、本開示の態様によれば、ビデオエンコーダ20および/またはビデオデコーダ30は、深度ルックアップテーブル(DLT)の第1の深度値を決定することと、ここにおいて、第1の深度値がビデオデータの第1のピクセルに関連する、DLTの第2の深度値を決定することと、ここにおいて、第2の深度値がビデオデータの第2のピクセルに関連する、第1の深度値に対して第2の深度値をコーディングすることを含むDLTをコーディングすることとを行い得る。
[0078]一例では、説明の目的で、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリに関する深度値が、dlt_D[i][j]によって示されると仮定する。本開示の態様によれば、以下でより詳細に説明するように、ビデオエンコーダ20および/またはビデオデコーダ30は、DLTの1つまたは複数の他の深度値を使用してDLT内の深度値を予測し得る。たとえば、ビデオエンコーダ20は、符号化ビットストリーム中で第1の有効深度値(たとえば、dlt_D[i][0])をシグナリングし得る。ビデオエンコーダ20は、次いで、DLT中の前の深度値に基づいて、DLTの残りの連続する深度値を差分的に符号化し得る(たとえば、dlt_D[i][j]−dlt_D[i][j−1])。すなわち、ビデオエンコーダ20は、ある深度値と次の連続する深度値との間の差分の指示をビットストリーム中に符号化し得る。
[0079]上記の例では、ビデオデコーダ30は、DLTのための初期深度値をパースし、復号し得る。ビデオデコーダ30は、次いで、ビデオエンコーダ20において適用された逆プロセスを適用することによってDLTの残りを再構成し得る。すなわち、ビデオデコーダ30は、受信され、復号された差分値をDLT中の前の連続する深度値に加算し得る。以下で図7に関してより詳細に説明するように、他の例も可能である。
[0080]追加または代替として、本開示の態様によれば、ビデオエンコーダ20および/またはビデオデコーダ30は、ビュー間でDLTの値を予測し、すなわち、DLTをビュー間予測し得る。この例では、ビデオエンコーダ20および/またはビデオデコーダ30は、あるビューに関連するDLTを使用して、第2の異なるビューに関連するDLTの少なくとも一部を予測し、コーディングし得る。
[0081]一例では、説明の目的で、第1のDLTが深度値の第1のセットを含むと仮定する。さらに、第2のDLTは深度値の第2のセットを含む。第1のセット中の深度値の数は第2のセット中の深度値の数に等しい。この例では、ビデオエンコーダおよび/またはビデオデコーダ30は、第2のDLT中の深度値と同じである第1のDLT中の深度値のロケーションの指示を、第2のDLTのためにコーディングするように構成され得る。いくつかの例では、指示は、第1のDLT中の開始ロケーションおよび/または終了ロケーションであり得る。第1のDLTと第2のDLTとの間で重複する深度値のロケーションの指示を受信すると、ビデオデコーダ30は、第1のDLTを使用して第2のDLTを再構成し得る。
[0082]いくつかの例では、第2のDLTに関連する第2のセット中の深度値の数が、第1のDLTに関連する第1のセット中の深度値の数よりも大きいことがある。この例では、ビデオエンコーダ20は、第2のDLTが第1のDLTの深度値のすべてを含むことをシグナリングし得る。さらに、ビデオエンコーダ20は、第1のDLT中に含まれない第2のDLTの深度値をシグナリングし得る。したがって、ビデオデコーダ30は、上記の情報を受信すると、第1のDLTをコピーし、追加のシグナリングされた深度値を第2のDLTに追加することによって、第2のDLTを再構成し得る。以下で図7に関して説明するように、他の例も可能である。
[0083]図2は、深度コーディングのための技法を実装し得るビデオエンコーダ20の一例を示すブロック図である。ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実行し得る。イントラコーディングは、所与のビデオフレームまたはピクチャ内のビデオの空間的冗長性を低減または除去するために空間的予測に依拠する。インターコーディングは、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオの時間的冗長性を低減または除去するために時間的予測に依拠する。イントラモード(Iモード)は、いくつかの空間ベースのコーディングモードのいずれかを指し得る。単方向予測(Pモード)または双予測(Bモード)などのインターモードは、いくつかの時間ベースのコーディングモードのいずれかを指し得る。
[0084]上記のように、ビデオエンコーダ20は、マルチビュービデオコーディングを実行するように適合され得る。いくつかの事例では、ビデオエンコーダ20は、時間インスタンス中の各ビューがビデオデコーダ30のなどのデコーダによって処理され得るように、マルチビューHEVCをコーディングするように構成され得る。HEVC−3Dの場合、各ビューに対するテクスチャマップ(すなわち、ルーマ値およびクロマ値)を符号化することに加えて、ビデオエンコーダ20はさらに、各ビューに対する深度マップを符号化し得る。
[0085]いずれの場合も、図2に示されているように、ビデオエンコーダ20は、符号化されるべきビデオフレーム内の現在ビデオブロックを受信する。図2の例では、ビデオエンコーダ20は、モード選択ユニット40と、参照ピクチャメモリ64と、加算器50と、変換処理ユニット52と、量子化ユニット54と、エントロピーエンコーディングユニット56とを含む。モード選択ユニット40は、今度は、動き補償ユニット44と、動き推定ユニット42と、イントラ予測ユニット46と、パーティションユニット48とを含む。ビデオブロック再構成のために、ビデオエンコーダ20はまた、逆量子化ユニット58と、逆変換ユニット60と、加算器62とを含む。再構成されたビデオからブロッキネスアーティファクトを除去するためにブロック境界をフィルタ処理するデブロッキングフィルタ(図2に図示せず)も含まれ得る。所望される場合、デブロッキングフィルタは、一般に、加算器62の出力をフィルタ処理することになる。追加のフィルタ(ループ内またはループ後)もデブロッキングフィルタに加えて使用され得る。そのようなフィルタは、簡潔のために示されていないが、所望される場合、(ループ内フィルタとして)加算器50の出力をフィルタ処理し得る。
[0086]符号化プロセス中に、ビデオエンコーダ20はコーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは複数のビデオブロックに分割され得る。動き推定ユニット42および動き補償ユニット44は、時間予測を行うために、1つまたは複数の参照フレーム中の1つまたは複数のブロックに対して、受信されたビデオブロックのインター予測コーディングを実行する。イントラ予測ユニット46は、代替的に、空間予測を行うために、コーディングされるべきブロックと同じフレームまたはスライス中の1つまたは複数の隣接ブロックに対して受信されたビデオブロックのイントラ予測コーディングを実行し得る。ビデオエンコーダ20は、たとえば、ビデオデータのブロックごとに適切なコーディングモードを選択するために、複数のコーディングパスを実行し得る。
[0087]その上、パーティションユニット48は、前のコーディングパスにおける前の区分方式の評価に基づいて、ビデオデータのブロックをサブブロックに区分し得る。たとえば、パーティションユニット48は、初めにフレームまたはスライスをLCUに区分し、レートひずみ(rate-distortion)分析(たとえば、レートひずみ最適化)に基づいてLCUの各々をサブCUに区分し得る。モード選択ユニット40は、LCUをサブCUに区分することを示す4分木データ構造をさらに生成し得る。4分木のリーフノードCUは、1つまたは複数のPUと、1つまたは複数のTUとを含み得る。
[0088]モード選択ユニット40は、たとえば、誤差結果に基づいてコーディングモード、すなわち、イントラまたはインターのうちの1つを選択し、残差ブロックデータを生成するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器50に与え、参照フレームとして使用するための符号化ブロックを再構成するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器62に与え得る。モード選択ユニット40はまた、動きベクトル、イントラモードインジケータ、パーティション情報、および他のそのようなシンタックス情報など、シンタックス要素をエントロピー符号化ユニット56に与える。
[0089]動き推定ユニット42と動き補償ユニット44とは、高度に統合され得るが、概念的な目的のために別々に示してある。動き推定ユニット42によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在フレーム(または他のコード化ユニット)内でコーディングされている現在ブロックに対する参照フレーム(または他のコード化ユニット)内の予測ブロックに対する現在ビデオフレームまたはピクチャ内のビデオブロックのPUの変位を示し得る。予測ブロックは、絶対値差分和(SAD:sum of absolute difference)、2乗差分和(SSD:sum of square difference)、または他の差分メトリックによって判断され得るピクセル差分に関して、コーディングされるべきブロックにぴったり一致することがわかるブロックである。
[0090]いくつかの例では、ビデオエンコーダ20は、参照ピクチャメモリ64に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ20は、参照ピクチャの1/4ピクセル位置、1/8ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット42は、フルピクセル位置と分数ピクセル位置とに関して動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。
[0091]動き推定ユニット42は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライスにおけるビデオブロックのPUのための動きベクトルを計算する。参照ピクチャは、第1の参照ピクチャリスト(リスト0)または第2の参照ピクチャリスト(リスト1)から選択され得、それらの参照ピクチャリストの各々は、参照ピクチャメモリ64に記憶された1つまたは複数の参照ピクチャを識別する。動き推定ユニット42は、計算された動きベクトルをエントロピー符号化ユニット56と動き補償ユニット44とに送る。
[0092]動き補償ユニット44によって実行される動き補償は、動き推定ユニット42によって判断された動きベクトルに基づいて予測ブロックをフェッチまたは生成することに関与し得る。この場合も、いくつかの例では、動き推定ユニット42と動き補償ユニット44とは機能的に統合され得る。現在ビデオブロックのPUのための動きベクトルを受信すると、動き補償ユニット44は、動きベクトルが参照ピクチャリストのうちの1つにおいて指す予測ブロックの位置を特定し得る。
[0093]加算器50は、以下で説明するように、コーディングされている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算することによって残差ビデオブロックを形成し、それによって、ピクセル差分値を形成する。概して、動き推定ユニット42はルーマ成分に対して動き推定を実行し、動き補償ユニット44は、クロマ成分とルーマ成分の両方のためにルーマ成分に基づいて計算された動きベクトルを使用する。モード選択ユニット40はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ30が使用するためのビデオブロックとビデオスライスとに関連するシンタックス要素を生成し得る。
[0094] イントラ予測ユニット46は、上記で説明したように、動き推定ユニット42と動き補償ユニット44とによって実施されるインター予測の代替として、現在ブロックをイントラ予測し得る。特に、イントラ予測ユニット46は、現在ブロックを符号化するために使用すべきイントラ予測モードを判断し得る。いくつかの例では、イントラ予測ユニット46は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在ブロックを符号化し得、イントラ予測ユニット46(または、いくつかの例では、モード選択ユニット40)は、テストされたモードから使用するのに適切なイントラ予測モードを選択し得る。
[0095]たとえば、イントラ予測ユニット46は、様々なテストされたイントラ予測モードのためのレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、概して、符号化ブロックと、符号化ブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ(または誤差)の量、ならびに符号化ブロックを生成するために使用されるビットレート(すなわち、ビット数)を判断する。イントラ予測ユニット46は、どのイントラ予測モードがブロックについて最良のレートひずみ値を呈するかを判断するために、様々な符号化ブロックのひずみおよびレートから比率を計算し得る。
[0096]さらに、イントラ予測ユニット46は、深度情報、たとえば、深度マップの深度ブロックをコーディングするように構成され得る。たとえば、イントラ予測ユニット46は、深度情報をイントラ予測し、残差値を決定し得る。イントラ予測ユニット46は、各パーティションの残差値を直接コーディングし得るか、または、残差値をコーディングする代わりに、DLTへのインデックスに基づいて深度値をコーディングし得る。たとえば、DLTは、各深度値が対応するインデックスを有する、深度値のセットを含み得る。イントラ予測ユニット46は、1つまたは複数の他のブロックのためのインデックスを使用して現在ブロック(たとえば、パーティション)のためのインデックスを予測し得る。たとえば、イントラ予測ユニット46は、現在ブロック(たとえば、区分)の平均深度値に関連するインデックスからインデックス予測子のインデックスを減算することによって、インデックス差分を計算し得る。
[0097]本開示の態様によれば、DLTをコーディングすることを担当するビデオエンコーダ20のユニット、たとえば、エントロピー符号化ユニット56などは、あるDLTの値をDLTの1つまたは複数の他の値に対して予測し得る。たとえば、DLTにおいて実際の深度値を符号化するのではなく、エントロピー符号化ユニット56は、DLTの1つまたは複数の連続深度値間の差分を決定し得、図7に関してより詳細に説明するように、差分値を符号化し得る。そうすることにより、ビットストリーム中でDLTをシグナリングすることに関連するビット数を低減し得る。いくつかの例では、エントロピー符号化ユニット56は、連続するエントリ間の差分値が同じであることを示す1つまたは複数のシンタックス要素を生成し得る。一例では、説明の目的で、すべての深度値差分が2である場合(たとえば、0、2、4、6、以下同様のDLT中の深度値の場合)、エントロピー符号化ユニット56は、差分値の類似度を示すフラグならびに差分値をシグナリングし得る。
[0098]追加または代替として、本開示の態様によれば、エントロピー符号化ユニット56は、あるビューのDLTに関連する深度値を第2の異なるビューのDLTに関連する深度値に対してシグナリングし得る、すなわち、ビュー間DLT予測。たとえば、エントロピー符号化ユニット56は、第1のビューのDLTの1つまたは複数の深度値が第2の異なるビューのDLTの1つまたは複数の深度値に等しいことを示す1つまたは複数のシンタックス要素をビットストリーム中に含め得る。エントロピー符号化ユニット56はまた、ビュー間DLT予測が有効であることを示すもう1つのシンタックス要素を生成し得る。
[0099]エントロピー符号化ユニット56は、パラメータセット中に(上記で説明した差分値を含む)1つまたは複数のDLTを表すデータを符号化し得る。たとえば、エントロピー符号化ユニット56は、ピクチャパラメータセット(PPS)中に1つまたは複数のDLTを含め得る。いくつかの例では、DLTは、ベースビューのビューコンポーネント中のスライスによって参照されるPPS中にのみ存在し得る。
[0100]ビデオエンコーダ20は、コーディングされている元のビデオブロックから、モード選択ユニット40からの予測データを減算することによって残差ビデオブロックを形成する。加算器50は、この減算演算を実行する1つまたは複数の構成要素を表す。変換処理ユニット52は、離散コサイン変換(DCT)または概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット52は、DCTと概念的に同様である他の変換を実行し得る。ウェーブレット変換、整数変換、サブバンド変換または他のタイプの変換も使用され得る。
[0101]いずれの場合も、変換処理ユニット52は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。変換処理ユニット52は、得られた変換係数を量子化ユニット54に送り得る。量子化ユニット54は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、量子化ユニット54は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット56が走査を実行し得る。
[0102]量子化に続いて、エントロピー符号化ユニット56は、量子化変換係数をエントロピーコーディングする。たとえば、エントロピー符号化ユニット56は、コンテキスト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)、確率間隔区分エントロピー(PIPE)コーディングまたは別のエントロピーコーディング技法を実行し得る。コンテキストベースエントロピーコーディングの場合、コンテキストは隣接ブロックに基づき得る。エントロピー符号化ユニット56によるエントロピーコーディングに続いて、符号化ビットストリームは、別のデバイス(たとえば、ビデオデコーダ30)に送信されるか、あるいは後で送信するかまたは取り出すためにアーカイブされ得る。
[0103]逆量子化ユニット58および逆変換ユニット60は、それぞれ逆量子化および逆変換を適用して、たとえば参照ブロックとして後で使用するために、ピクセル領域中で残差ブロックを再構成する。動き補償ユニット44は、残差ブロックを参照ピクチャメモリ64のフレームのうちの1つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット44はまた、再構成された残差ブロックに1つまたは複数の補間フィルタを適用して、動き推定において使用するためのサブ整数ピクセル値を計算し得る。加算器62は、再構成された残差ブロックを、動き補償ユニット44によって生成された動き補償予測ブロックに加算して、参照ピクチャメモリ64に記憶するための再構成されたビデオブロックを生成する。再構成されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするために動き推定ユニット42および動き補償ユニット44によって参照ブロックとして使用され得る。
[0104]ビデオエンコーダ20のユニットは説明のために与えられたことと、(エントロピー符号化ユニット56などの)特定のユニットに帰される技法はビデオエンコーダ20の1つまたは複数の他または追加のユニットによって実行され得ることとを理解されたい。
[0105]図3は、深度コーディングのための技法を実装し得るビデオデコーダ30の一例を示すブロック図である。図3の例では、ビデオデコーダ30は、エントロピー復号ユニット70と、動き補償ユニット72と、イントラ予測ユニット74と、逆量子化ユニット76と、逆変換ユニット78と、参照ピクチャメモリ82と、加算器80とを含む。ビデオデコーダ30は、いくつかの例では、ビデオエンコーダ20(図2)に関して説明した符号化パスとは概して逆の復号パスを実行し得る。動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルに基づいて予測データを生成し得、イントラ予測ユニット74は、エントロピー復号ユニット70から受信されたイントラ予測モードインジケータに基づいて予測データを生成し得る。
[0106]復号プロセス中に、ビデオデコーダ30は、ビデオエンコーダ20から、符号化ビデオスライスのビデオブロックと、関連するシンタックス要素とを表す符号化ビデオビットストリームを受信する。ビデオデコーダ30のエントロピー復号ユニット70は、量子化係数、動きベクトルまたはイントラ予測モードインジケータ、および他のシンタックス要素を生成するためにビットストリームをエントロピー復号する。エントロピー復号ユニット70は、動きベクトルと他の予測シンタックス要素とを動き補償ユニット72に転送する。ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルでシンタックス要素を受信し得る。
[0107]背景として、ビデオデコーダ30は、ネットワークを介した送信のために、いわゆる「ネットワークアブストラクションレイヤユニット(network abstraction layer unit)」またはNALユニットに圧縮された圧縮ビデオデータを受信し得る。各NALユニットは、NALユニットに記憶されるデータのタイプを識別するヘッダを含み得る。一般にNALユニットに記憶されるデータの2つのタイプがある。NALユニットに記憶される第1のタイプのデータはビデオコーディングレイヤ(VCL)データであり、これは圧縮ビデオデータを含む。NALユニットに記憶される第2のタイプのデータは非VCLデータと呼ばれ、これは、多数のNALユニットに共通のヘッダデータを定義するパラメータセットなどの追加の情報と、補足エンハンスメント情報(SEI)とを含む。
[0108]たとえば、パラメータセットは、(たとえば、SPSまたはVPS中の)シーケンスレベルヘッダ情報と、(たとえば、PPS中の)まれに変化するピクチャレベルヘッダ情報とを含んでいることがある。パラメータセット中に含まれている、まれに変化する情報は、シーケンスまたはピクチャごとに繰り返される必要がなく、それによりコーディング効率が改善される。さらに、パラメータセットの使用はヘッダ情報の帯域外送信を可能にし、それにより誤り耐性のための冗長送信の必要が回避される。
[0109]上述のように、ビデオデコーダ30は、マルチビュービデオコーディングを実行するように適合され得る。いくつかの例では、ビデオデコーダ30は、マルチビューHEVCを復号するように構成され得る。HEVC−3Dの場合、各ビューに対するテクスチャマップ(すなわち、ルーマ値およびクロマ値)を復号することに加えて、ビデオデコーダ30はさらに、各ビューに対する深度マップを復号し得る。
[0110]いずれの場合も、ビデオスライスがイントラコード化(I)スライスとしてコーディングされるとき、イントラ予測ユニット74は、シグナリングされたイントラ予測モードと、現在フレームまたはピクチャの、前に復号されたブロックからのデータとに基づいて、現在ビデオスライスのビデオブロックのための予測データを生成し得る。さらに、イントラ予測ユニット74は、深度情報、たとえば、深度マップの深度ブロックをコーディングするように構成され得る。たとえば、イントラ予測ユニット74は、深度情報をイントラ予測し、残差値を受信し得る。
[0111]イントラ予測ユニット74は、各パーティションの残差値を直接受信し、復号し得るか、またはDLTへのインデックスに基づいて深度値を復号し得る。たとえば、上述のように、DLTは、各深度値が対応するインデックスを有する、深度値のセットを含み得る。イントラ予測ユニット74は、インデックス予測子のインデックスと現在ブロックの平均深度値に関連するインデックスとの間の差分に基づく、インデックス差分を受信し得る。イントラ予測ユニット74は、復号されたインデックス差分とインデックス予測子のインデックスとの和によって決定されたインデックスに基づいて、現在ブロックの深度値を決定し得る。
[0112]本開示の態様によれば、ビデオデコーダ30(たとえば、ビデオデコーダ30のエントロピー復号ユニット70)は、DLTの1つまたは複数の他の値に対してDLTの値を予測し得る。たとえば、DLTにおいて実際の深度値を復号するのではなく、エントロピー復号ユニット70は、図7に関してより詳細に説明するように、DLTの1つまたは複数の連続深度値間の差分をパースし、復号し得る。エントロピー復号ユニット70は、受信された差分値をDLT中の前の深度値に加算することによって実際の深度値を再構成し得る。
[0113]いくつかの例では、エントロピー復号ユニット70は、連続するエントリ間の差分値が同じであることを示す1つまたは複数のシンタックス要素を受信し得る。一例では、説明の目的で、すべての深度値差分が2である場合(たとえば、0、2、4、6、以下同様のDLT中の深度値の場合)、ビデオデコーダ30は、差分値の類似性を示すフラグならびに差分値を受信し得る。
[0114]追加または代替として、本開示の態様によれば、エントロピー復号ユニット70は、あるビューのDLTに関連する深度値を第2の異なるビューのDLTに関連する深度値に対して決定し得る、すなわち、ビュー間DLT予測。たとえば、エントロピー復号ユニット70は、第1のビューのDLTの1つまたは複数の深度値が第2の異なるビューのDLTの1つまたは複数の深度値に等しいことを示すビットストリーム中の1つまたは複数のシンタックス要素をパースし、複合し得る。エントロピー復号ユニット70は、次いで、他のビューからのDLT値をコピーすることによってあるビューのためのDLTを生成し得る。エントロピー復号ユニット70はまた、ビュー内DLT予測が有効であることを示すもう1つのシンタックス要素を受信し得る。
[0115]エントロピー復号ユニット70は、パラメータセット中の(上記で説明した差分値を含む)1つまたは複数のDLTを表すデータを復号し得る。たとえば、エントロピー復号ユニット70は、PPS中の1つまたは複数のDLTを受信し得る。いくつかの例では、DLTは、ベースビューのビューコンポーネント中のスライスによって参照されるPPS中にのみ存在し得る。
[0116]ビデオフレームがインターコード化(すなわち、B、PまたはGPB)スライスとしてコーディングされるとき、動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルと他のシンタックス要素とに基づいて、現在ビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの1つ内の参照ピクチャのうちの1つから生成され得る。ビデオデコーダ30は、参照ピクチャメモリ92に記憶された参照ピクチャに基づいて、デフォルトの構成技法を使用して、参照フレームリスト、すなわち、リスト0およびリスト1を構成し得る。
[0117]動き補償ユニット72は、動きベクトルと他のシンタックス要素とをパースすることによって現在ビデオスライスのビデオブロックのための予測情報を判断し、その予測情報を使用して、復号されている現在ビデオブロックのための予測ブロックを生成する。たとえば、動き補償ユニット72は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード(たとえば、イントラ予測またはインター予測)と、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)と、スライスの参照ピクチャリストのうちの1つまたは複数のための構成情報と、スライスの各インター符号化ビデオブロックのための動きベクトルと、スライスの各インターコーディングビデオブロックのためのインター予測ステータスと、現在ビデオスライス中のビデオブロックを復号するための他の情報とを決定するために、受信されたシンタックス要素のいくつかを使用する。
[0118]動き補償ユニット72はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット72は、ビデオブロックの符号化中にビデオエンコーダ20によって使用された補間フィルタを使用して、参照ブロックのサブ整数ピクセルの補間値を計算し得る。この場合、動き補償ユニット72は、受信されたシンタックス要素からビデオエンコーダ20によって使用された補間フィルタを判断し、その補間フィルタを使用して予測ブロックを生成し得る。
[0119]逆量子化ユニット76は、ビットストリーム中で与えられ、エントロピー復号ユニット70によって復号された量子化変換係数を逆量子化(inverse quantize)、すなわち、逆量子化(de-quantize)する。逆量子化プロセスは、量子化の程度を判断し、同様に、適用されるべき逆量子化の程度を判断するための、ビデオスライス中のビデオブロックごとにビデオエンコーダ30によって計算される量子化パラメータQPYの使用を含み得る。
[0120]逆変換ユニット78は、ピクセル領域において残差ブロックを生成するために、逆変換、たとえば逆DCT、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。
[0121]動き補償ユニット72またはイントラ予測ユニット74が、動きベクトルまたは他のシンタックス要素に基づいて現在ビデオブロック(たとえば、テクスチャブロックまたは深度ブロック)のための予測ブロックを生成した後、ビデオデコーダ30は、逆変換ユニット78からの残差ブロックを、動き補償ユニット72またはイントラ予測ユニット74によって生成された対応する予測ブロックと加算することによって復号ビデオブロックを形成する。加算器80は、この加算演算を実行する1つまたは複数の構成要素を表す。
[0122]所望される場合、ブロッキネスアーティファクトを除去するために、復号ブロックをフィルタ処理するためにデブロッキングフィルタも適用され得る。ピクセル遷移を平滑化するために、または場合によってはビデオ品質を改善するために、他のループフィルタも(コーディングループ中またはコーディングループ後のいずれかで)使用され得る。所与のフレームまたはピクチャ中の復号されたビデオブロックは、次いで、その後の動き補償のために使用される参照ピクチャを記憶する参照ピクチャメモリ82に記憶される。参照ピクチャメモリ82はまた、図1のディスプレイデバイス32などのディスプレイデバイス上での後の提示のために、復号されたビデオを記憶する。
[0123]説明のためにビデオデコーダ30のユニットが与えられたことと、(エントロピー復号ユニット70などの)特定のユニットに起因する技法が、ビデオデコーダ30の1つまたは複数の他または追加のユニットによって実行され得ることとを理解されたい。
[0124]図4に、方向性イントラ予測モードに関連する予測方向を概して示す。たとえば、上述のように、HEVC規格は、平面モード(モード0)、DCモード(モード1)、および33個の方向性予測モード(モード2〜34)を含む、35個のイントラ予測モードを含み得る。平面モードの場合、いわゆる「プレーン」機能を使用して予測が実行される。DCモードの場合、ブロック内のピクセル値の平均化に基づいて予測が実行される。方向性予測モードの場合、(そのモードによって示される)特定の方向に沿った隣接ブロックの再構成されたピクセルに基づいて予測が実行される。概して、図4に示されている矢印の末端は、値がそこから取り出される隣接ピクセルのうちの相対的な1つを表すが、矢印のヘッドは、予測ブロックを形成するために取り出された値が伝搬される方向を表す。
[0125]図4に示されているイントラモードは、深度値を予測するための使用され得る。たとえば、図4に示されている角度イントラ予測モードの各々は、図5Aおよび図5Bに関して以下でより詳細に説明するように、ウェッジレットパターンのセットに関連し得る。
[0126]図5Aおよび図5Bは、深度モデリングモード(DMM)の例を示す概念図である。図5Aは、たとえば、ウェッジレット区分を使用して区分された深度ブロック110を示し、図5Bは、別の例として、輪郭区分を使用して区分された深度ブロック130を示す。3D−HEVCは、深度スライスのイントラ予測ユニットをコーディングするために、イントラ予測モードとともに、ブロックを区分するための深度モデリングモード(DMM)のための技法を含む。HTMバージョン3.1は、場合によっては深度マップ中のより鋭いエッジをより良く表し得る、深度マップのイントラコーディングのためのDMM方法を適用する。
[0127]たとえば、3D−HEVCは、4つのDMM、すなわち、モード1(明示的ウェッジレットシグナリング)と、モード2(イントラ予測ウェッジレット区分)と、モード3(コンポーネント間ウェッジレット区分)と、モード4(コンポーネント間輪郭区分)とを与える。すべての4つのモードでは、ビデオエンコーダ20またはビデオデコーダ30などのビデオコーダは、深度ブロックをDMMパターンによって指定された2つの領域に区分し得、各領域は一定値によって表される。DMMパターンは、明示的にシグナリングされる(モード1)か、空間的に隣接するブロックによって予測される(モード2)か、またはコロケートテクスチャブロックを使用して予測される(モード3およびモード4)かのいずれかであり得る。
[0128]ウェッジレット区分と輪郭区分とを含む、DMMにおいて定義されている2つの区分モデルがある。この場合も、図5Aにウェッジレット区分の一例を示し、図5Bに輪郭区分の一例を示す。深度ブロック110および130内の各個々の正方形は、それぞれ、深度ブロック110および130のそれぞれの個々のピクセルを表す。正方形内の数値は、対応するピクセルが領域112(図5Aの例における値「0」)に属するのか、領域114(図5Aの例における値「1」)に属するのかを表す。また、図5Aにおいて、ピクセルが領域112(白い正方形)に属するのか、領域114(灰色の影つき正方形)に属するのかを示すために陰影が使用される。
[0129]各パターン(すなわち、ウェッジレットと輪郭の両方)は、対応するサンプル(すなわち、ピクセル)が領域P1に属するのかP2に属するのか(ただし、P1は図5A中の領域112と図5B中の領域132とに対応し、P2は図5A中の領域114と図5B中の領域134A、134Bとに対応する)のサイズuB×vB2進数字ラベリングのアレイによって画定され得、uBおよびvBは、それぞれ、現在PUの水平サイズおよび垂直サイズを表す。図5Aおよび図5Bの例では、PUは、それぞれブロック110および130に対応する。ビデオエンコーダ20およびビデオデコーダ30などのビデオコーダは、コーディングの開始、たとえば、符号化の開始または復号の開始時に、ウェッジレットパターンを初期化し得る。
[0130]図5Aの例に示されているように、ウェッジレット区分の場合、深度ブロック110は、(Xs,Ys)に位置する開始点118と(Xe,Ye)に位置する終了点120とをもつ直線116によって2つの領域、すなわち、領域112と領域114とに区分される。図5Aの例では、開始点118は点(8,0)として定義され得、終了点120は点(0,8)として定義され得る。
[0131]図5Bの例に示されているように、輪郭区分の場合、深度ブロック130などの深度ブロックは2つの不規則形状領域に区分され得る。図5Bの例では、深度ブロック130は領域132と領域134A、134Bとに区分される。領域134A中のピクセルは領域134B中のピクセルに直接隣接しないが、領域134Aおよび134Bは、深度ブロック130のPUを予測する目的で1つの単一の領域を形成するように画定される。輪郭区分は、ウェッジレット区分よりもフレキシブルであるが、シグナリングすることが相対的により困難であり得る。DMMモード4では、3D−HEVCの場合、輪郭区分パターンは、コロケートテクスチャブロックの再構成されたルーマサンプルを使用して暗黙的に導出される。
[0132]このようにして、ビデオエンコーダ20およびビデオデコーダ30などのビデオコーダは、深度ブロック110のピクセルが(領域「P1」と呼ばれることもある)領域112に属するのか、(領域「P2」と呼ばれることもある)領域114に属するのかを判断するために、開始点118と終了点120とによって画定された線116を使用し得る。同様に、ビデオコーダは、深度ブロック130のピクセルが(領域「P1」と呼ばれることもある)領域132に属するのか、(領域「P2」と呼ばれることもある)領域134に属するのかを判断するために、図5Bの線136、138を使用し得る。領域「P1」および「P2」は、DMMに従って区分された異なる領域のためのデフォルト命名規則であり、したがって、深度ブロック110の領域P1は、深度ブロック130の領域P1と同じ領域と考えられるべきでない。
[0133]上記のように、DMMの各々は、DMMがウェッジレット区分を使用するのか輪郭区分を使用するのかと、パターンが明示的にシグナリングされるのかまたは暗黙的に判断されるのかとによって定義され得る。DMMプロセスは、(図4に示された)HEVCにおいて指定されたイントラ予測モードの代替として組み込まれ得る。DMMが適用されるのか従来のイントラ予測が適用されるのかを指定するために、1ビットフラグが各PUについてシグナリングされ得る。
[0134]図6は、領域境界チェーンコーディングモードを示す概念図である。たとえば、3D−HEVCは、(たとえば、DMMに関して上記で説明した、コロケートされたテクスチャに基づく区分ではなく)パーティション境界の明示的シグナリングを可能にする領域境界チェーンコーディングモードを含む。本開示では、「領域境界チェーンコーディングモード」を「チェーンコーディング」と呼ぶことがある。
[0135]概して、チェーンは、サンプルとそれの8連結性サンプルのうちの1つとの間の連結である。図6の上部に示されているように、8つの異なるチェーン方向タイプがあり、それぞれに0から7にわたる方向インデックスが割り当てられる。(ビデオエンコーダ20などの)ビデオエンコーダは、チェーンの開始位置と、チェーン中のリンクの数の指示(たとえば、チェーンコードの数)と、チェーンコードごとに、方向インデックスとを用いて、PUのためのチェーンをシグナリングし得る。
[0136]チェーンコーディングプロセスの一例が図6に示されている。図6に示されている任意のパーティションパターンをシグナリングするために、ビデオエンコーダ20は、パーティションパターンを識別し、符号化ビットストリーム中の以下の情報を符号化し得る。すなわち、チェーンが上部境界から開始することをシグナリングするために1ビット「0」が符号化され、上部境界における開始位置「3」をシグナリングするために3ビット「011」が符号化され、チェーンの総数を7としてシグナリングするために4ビット「0110」が符号化され、一連の連結チェーンインデックス「3、3、3、7、1、1、1」が符号化され、ここで、各チェーンインデックスは、図6の相対的な上部において示されている表を使用してコードワードに変換される。
[0137]ビデオデコーダ30など、ビデオデコーダは、ブロックの区分パターンを決定するために、上記で説明したシグナリングをパースし得る。ビデオデコーダ30は、次いで、各パーティションの深度値を復号し得る。
[0138]図7は、簡略深度コーディング(SDC)を使用したイントラコーディング深度情報を示すブロック図である。図7に関して以下で説明する例は、ビデオエンコーダ20、ビデオデコーダ30、または様々な他のコーデックおよび/またはプロセッサによって実行され得る。
[0139]図7の例では、上述のように、(ビデオエンコーダ20またはビデオデコーダ30などの)ビデオコーダは、深度情報をイントラ予測するために、上記で説明したイントラ予測モード(HEVCモード、DMM、チェーンコーディング)のいずれかを使用し得る。そのような例では、ビデオコーダは、図7の左ブランチ(たとえば、区分と、予測モードと、残差コーディングと)を実装し得る。
[0140]代替的に、ビデオコーダは、深度情報がSDCを使用してコーディングされることを示すために、シンタックス要素(たとえば、sdc_enable_flag)をシグナリングし得る。SDCを実装するとき、ビデオコーダはまた、図7の右ブランチに示されているように、深度値のための予測モードとDCオフセットとを示し得る。現在の3D−HEVC(上述のバージョン5.1)では、SDCは、2N×2N PUパーティションサイズのためにのみ適用される。上述のように、量子化された変換係数をコーディングする代わりに、SDCモードは、以下の4つのタイプの情報を用いて深度ブロックを表す。
1.a.DC(1つのパーティション)
b.DMMモード1(2つのパーティション)
c.DMMモード2(2つのパーティション)
d.平面(1つのパーティション)
を含む、現在深度ブロックのパーティションのタイプ
2.パーティションごとに、(ピクセル領域中の)残差値がビットストリーム中でシグナリングされる。
[0141]したがって、SDCにおいて定義された4つのサブモードは、それぞれ、DC、DMMモード1、DMMモード2、および平面のパーティションタイプに対応する、SDCモード1、SDCモード2、SDCモード3、およびSDCモード4を含む。SDCでは、変換または量子化は適用されない。各パーティションの残差値をシグナリングするために、ビデオエンコーダ20は2つの代替プロセスを適用し得る。第1のプロセスでは、ビデオエンコーダ20は、現在PU中の現在パーティションの平均値(Aver)から隣接サンプルの生成された予測子(Pred)を減算することによって計算され得る、各パーティションの残差値を直接コーディングし得る。
[0142]第2のプロセスでは、残差値を直接コーディングする代わりに、ビデオエンコーダ20は、DLTからのマッピングされたインデックス差分を符号化し得る。たとえば、上述のように、DLTは元の深度マップの深度値をマッピングする。DLTは、フルシーケンスを符号化する前にイントラ期間内のフレームを分析することによって構成され得る。いくつかの例では、ビデオエンコーダ20は、すべての有効深度値を昇順で分類し、深度値がDLTにおいて増加するインデックスを有するように深度値をDLTに挿入する。
[0143]ビデオエンコーダ20は、現在ブロックの深度値(Aver)の平均値のインデックスから予測子、たとえば、予測深度値(Pred)のインデックスを減算することによって、上述のインデックス差分を計算する。PredまたはAverの値がDLT中に含まれないとき、ビデオエンコーダ20は、値を実際のPred値またはAver値に相対的に最も近い値を有するDLTのインデックスi(たとえば、Pred/Averの絶対値−DLT中のi番目のエントリの値が最小値にある深度値に対応するインデックス)にマッピングし得る。
[0144]ビデオデコーダ30は、インデックス値を受信し、ビデオエンコーダ20と同じ様式で予測子のインデックスを決定し得る。ビデオデコーダ30は、次いで、現在復号されている深度値のためのインデックスを決定するために、予測子のインデックスとインデックス差分とを組み合わせ得る。ビデオデコーダ30は、決定されたインデックスと受信されたDLTとを使用して深度値を決定し得る。
[0145]いくつかの事例では、DLTを使用することは、随意であり得、分析段において元の深度マップ中に0からMAX_DEPTH_VALUE(たとえば、8ビット深度サンプルの場合は255)までの値の1/2よりも多くが現れる場合、使用されないことがある。DLTを使用するとき、概して、DLTはシーケンスおよび/またはビデオパラメータセット中にコーディングされ得る。DLTをコーディングするために、(ビデオエンコーダ20またはビデオデコーダ30などの)ビデオコーダは、最初にExpゴロムコードを用いてDLT中の有効深度値の数をコーディングし得る。ビデオコーダは、次いで、Expゴロムコードを用いて各有効深度値をコーディングし得る。DLTをシグナリングするための関係するシンタックス要素とセマンティクスとの一例を以下の表1に示す。
[0146]上記の表1の例において、1に等しいdlt_flag[i]は、DLTが使用されることと、簡略深度コード化コーディングユニットのための残差値が、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLTのインデックスとして解釈されるべきであることとを指定する。さらに、0に等しいdlt_flag[i]は、DLTが使用されないことと、簡略深度コード化コーディングユニットのための残差値が、iに等しいlayer_idをもつ深度ビューコンポーネントのためのインデックスとして解釈されるべきでないこととを指定する。dlt_flat[i]が存在しないとき、0に等しいと推論され得る。
[0147]さらに、上記の表1の例において、num_depth_values_in_dlt[i]は、iに等しいlayer_idをもつ現在レイヤの深度ビューコンポーネントのためのDLT中の異なる深度値の数と要素の数とを指定する。さらに、dlt_depth_value[i][j]は、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリを指定する。現在3DHTM(上述のバージョン5.1)では、DLTは、上記で定義したVPSの代わりにSPS中にシグナリングされ得る。
[0148]上記で説明したDLT方式は、コーディング効率に影響を及ぼし得る、様々な冗長性を含むことがある。潜在的冗長性を示すために、例示的なテストシーケンスを以下に与える。
[0149]上記のテストシーケンスに示されているように、2つ以上のビュー中に現れる多くの冗長な(同じ)深度値(上記の太字およびイタリック体の数字)がある。さらに、DLTの深度値の範囲が比較的大きい(たとえば、58〜255の最小範囲をもつ)。別の例示的なテストシーケンスを以下に与える。
[0150]この場合も、上記のテストシーケンスに示されているように、2つ以上のビュー中に現れる多くの冗長な(同じ)深度値(上記の太字およびイタリック体の数字)がある。さらに、DLTの深度値の範囲が比較的大きい(たとえば、3〜88の最小範囲をもつ)。
[0151]上述のように、深度値の上昇特性を考慮することなしに直接深度値を直接コーディングすることは、非効率的であることがある。さらに、異なるビュー間の関係式が現在の設計(上述のバージョン5.1)では利用されない。したがって、冗長な深度値をシグナリングすることに対して比較的大きいビット数が浪費され得る。その上、SPSまたはVPSのいずれか中にDLTをシグナリングすることは、1つのシーケンス/ビュー内にシーン変化があるときに効率的でないことがある。さらに、より短いコードをもつ深度値がより高い出現確率を有するという仮定がないので、指数ゴロムコードは、深度値をコーディングするときに非効率的であることがある。
[0152]本開示の態様は、一般にDLTシグナリングに関し、特定の規格に限定されることなしに、3D−HEVCにおいて使用され得る。本開示の態様によれば、DLTの1つまたは複数の深度値がDLTの1つまたは複数の他の深度値に対してコーディングされ得る。たとえば、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリに関する深度値が、dlt_D[i][j]によって示されると仮定する。一例では、ビデオエンコーダ20は、第1の有効深度値(たとえば、dlt_D[i][0])を直接シグナリングし得、コーディングされている深度値をDLT中の前の深度値と比較することによって差分コーディングを後続の深度値に適用し得る(たとえば、dlt_D[i][j]−dlt_D[i][j−1])。ビデオデコーダ30は、第1の深度値を受信し得、たとえば、復号されている深度値の差分値をDLTの前の深度値に加算することによって、受信された差分値を使用してDLTを再構成し得る。
[0153]一例では、ビデオエンコーダ20は、同様の方法で異なるビューのためのDLTシグナリングを実行し得る。すなわち、この例では、ビデオエンコーダ20およびビデオデコーダ30は、DLTに対してビュー間予測を適用しない。また、ビデオエンコーダ20およびビデオデコーダ30はDLT間でスライス/フレームレベル予測を実行しない。この例のための例示的なVPSシンタックスを以下の表2に示す。
[0154]上記の表2の例において、イタリック体の要素は、表1に関して上記で説明した現在シンタックスからの逸脱を示す(および[removed: “…”]は材料の除去を示す)。表2の例において、num_depth_values_in_dlt[i]は、iに等しいlayer_idをもつ現在レイヤの深度ビューコンポーネントのためのDLT中の異なる深度値の数と要素の数とを指定する。さらに、dlt_depth_start_value[i]は、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中の0番目のエントリを指定する。
[0155]表2の例は、u(v)を用いてコーディングされているdlt_depth_start_value[i]を示すが、いくつかの例では、シンタックス要素は、固定長としてシグナリングされる得、たとえば、u(7)または0から255までの範囲をもつu(v)としてシグナリングされるか、または0から(255−num_depth_values_in_dlt[i])までの範囲をもつu(v)としてシグナリングされ得る。別の例では、dlt_depth_start_value[i]の代わりにdlt_depth_start_value_minus1[i]がシグナリングされ得、ここで、dlt_depth_start_value_minus1[i]+1は、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中の0番目のエントリを指定する。
[0156]さらに、本開示の態様によれば、dlt_depth_value_diff[i][j]は、iに等しいlayer_idと0よりも大きいjとをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリと(j−1)番目のエントリとの間の深度値の差分を指定する。dltDepthValue[i][j]は、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリを示し、次のように導出される。jが0に等しい場合、dltDepthValue[i][j]はdlt_depth_start_value[i]に等しく設定され、他の場合、dltDepthValue[i][j]は、dltDepthValue[i][j−1]+dlt_depth_value_diff[i][j]に等しく設定される。
[0157]別の例では、dlt_depth_value_diff[i][j]の代わりにdlt_depth_value_diff_minus1[i][j]が、シグナリングされ得、ここで、dlt_depth_value_diff_minus1[i][j]+1は、iに等しいlayer_idと0よりも大きいjとをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリと(j−1)番目のエントリとの間の深度値の差分を指定する。
[0158]いくつかの例では、本開示の態様によれば、DLTの2つの連続するエントリ間の差分値の範囲がシグナリングされ得、差分値は、範囲に応じて固定長でシグナリングされる。すなわち、DLT差分は、最大差分値または最小差分値に基づいてシグナリングされ得る。
[0159]いくつかの例では、dlt_depth_value_diff[i][j]またはdlt_depth_value_diff_minus1[i][j]は、ue(v)の代わりにu(v)を用いてシグナリングされ得、このシンタックス要素の範囲がシグナリングされ得る。この例のための例示的なVPSシンタックスを以下の表3に示す。
[0160]上記の表3の例において、イタリック体の要素は、表1に関して上記で説明した現在シンタックスからの逸脱を示す(および[removed: “…”]は材料の除去を示す)。表3の例において、max_diff_minus1[i]は、dlt_depth_value_diff_minus1[i][j]の範囲を指定する。すなわち、max_diff_minus1[i]は、DLT中の2つの連続する深度値間の最大数値差分の指示を与える。さらに、dlt_depth_value_diff_minus1[i][j]+1は、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリと(j−1)番目のエントリとの間の深度値の差分を指定する。dlt_depth_value_diff_minus1は、両端値を含む、0〜max_diff_minus1[i]の範囲内にある。他の例では、num_depth_values_in_dlt[i]およびdlt_depth_start_value[i]は、ue(v)としてコーディングされ得、または、両方とも、u(8)または異なる所与の範囲をもつu(v)としてコーディングされ得る。
[0161]いくつかの例では、差分コーディングが2つの連続する深度値の差分に適用され、すなわち、2次差分がシグナリングされる。すなわち、jが1よりも大きいとき、(dlt_D[i][j]−dlt_D[i][j−1])−(dlt_D[i][j−1]−dlt_D[i][j−2])がシグナリングされる。jが1に等しいとき、(dlt_D[i][j]−dlt_D[i][j−1])がシグナリングされる。この例のための例示的なVPSシンタックスを以下の表4に示す。
[0162]上記の表4の例において、イタリック体の要素は、表1に関して上記で説明した現在シンタックスからの逸脱を示す(および[removed: “…”]は材料の除去を示す)。表4の例において、dlt_depth_value_consecutive_diff[i][j]は、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中の深度値の差分からのj番目のエントリと、(j−1)番目のエントリとの2次差分を指定する。ltDepthValueDiff[i][j]は、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリと(j−1)番目のエントリとの間の深度値の差分を示し、次のように導出される。jが1に等しいとき、dltDepthValueDiff[i][j]は、dlt_depth_value_consecutive_diff[i][1]に設定され、他の場合(jが、1よりも大きく、num_depth_values_in_dlt[i]よりも小さいとき)、dltDepthValueDiff[i][j]は、dltDepthValueDiff[i][j−1]+dlt_depth_value_consecutive_diff[i][j]に設定される。
[0163]さらに、dltDepthValue[i][j]は、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリを示し、次のように導出される。jが0に等しい場合、dltDepthValue[i][j]はdlt_depth_start_value[i]に等しく設定され、他の場合、dltDepthValue[i][j]は、dltDepthValue[i][j−1]+dltDepthValueDiff[i][j]に等しく設定される。
[0164]いくつかの例では、jが1よりも大きいとき、dlt_depth_value_consecutive_diff[i][j]の範囲は明示的にシグナリングされ得る。この例のための例示的なVPSシンタックスを以下の表5に示す。
[0165]上記の表5の例において、イタリック体の要素は、表1に関して上記で説明した現在シンタックスからの逸脱を示す(および[removed: “…”]は材料の除去を示す)。表5の例において、dlt_depth_value_diff[i][j]は、iに等しいlayer_idと1に等しいjとをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリと(j−1)番目のエントリとの間の深度値の差分を指定する。さらに、dlt_depth_start_value_diff[i]は、両端値を含む、0〜(256−num_depth_values_in_dlt[i]−dlt_depth_start_value[i])の範囲内にある。
[0166]さらに、max_consecutive_diff_minus1[i]+1は、dlt_depth_value_consecutive_diff_abs[i][j]の範囲を指定する。max_consecutive_diff_minus1[i]は、両端値を含む、0〜(256−num_depth_values_in_dlt[i]−dlt_depth_start_value[i])の範囲内にある。
[0167]さらに、dlt_depth_value_consecutive_diff_abs[i][j]は、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中の深度値の差分からのj番目のエントリと、(j−1)番目のエントリとの2次差分の絶対値を指定する。さらに、dlt_depth_value_consecutive_diff_absは、両端値を含む、0〜(max_consecutive_diff_minus1[i]+1)の範囲内にある。
[0168]いくつかの例では、max_consecutive_diff_minus1[i]+1のシンタックス要素の代わりにmax_consecutive_diff[i]シンタックス要素が使用され得る。そのような例において、max_consecutive_diff[i]は、dlt_depth_value_consecutive_diff_abs[i][j]の範囲を指定する。いくつかの事例では、max_consecutive_diff[i]は、両端値を含む、0〜(256−num_depth_values_in_dlt[i]−dlt_depth_start_value[i])の範囲内にあり得る。さらに、dlt_depth_value_consecutive_diff_absは、両端値を含む、0〜max_consecutive_diff[i]の範囲内にあり得る。さらに、dlt_depth_value_consecutive_diff_sign[i][j]は、dlt_depth_value_consecutive_diff_abs[i][j]が0に等しくないとき、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中の深度値の差分からのj番目のエントリと、(j−1)番目のエントリとの2次差分の絶対値を指定する。
[0169]さらに、ltDepthValueDiff[i][j]は、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリと(j−1)番目のエントリとの間の深度値の差分を示し、次のように導出され得る。jが1に等しいとき、dltDepthValueDiff[i][j]はdlt_depth_start_value_diff[i]に設定され、他の場合(jが1よりも大きく、num_depth_values_in_dlt[i]よりも小さいとき)、dltDepthValueDiff[i][j]は、dltDepthValueDiff[i][j−1]+(1−2*dlt_depth_value_consecutive_diff_sign[i][j])*dlt_depth_value_consecutive_diff_abs[i][j]に設定される。
[0170]さらに、dltDepthValue[i][j]は、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリを示し、次のように導出され得る。jが0に等しい場合、dltDepthValue[i][j]はdlt_depth_start_value[i]に等しく設定され、他の場合、dltDepthValue[i][j]は、dltDepthValue[i][j−1]+dltDepthValueDiff[i][j]に等しく設定される。
[0171]本開示の態様によれば、個々の深度値差分をシグナリングするのではなく、上述のように、DLTの連続するエントリ間のすべての差分が同じであるかどうかを示すために、1つまたは複数のシンタックス要素(たとえば、フラグ)が導入され得る。たとえば、DLTの連続する深度値間の差分のすべてが同じ(たとえば、1、2、3などの差分)である場合、差分が一定であることを示すためにフラグが使用され得、深度値間で適用されるべき差分値がシグナリングされる。このようにして、すべて同じである深度差分値のセットをシグナリングするのではなく、シグナリングコストを低減するためにこの技法が実装され得る。
[0172]j番目のエントリと(j−1)番目のエントリとの間のすべての差分が同じであるかどうかを示すフラグの一例、ならびに差分の値を以下の表6に示す。
[0173]上記の表6の例において、イタリック体の要素は、表1に関して上記で説明した現在シンタックスからの逸脱を示す(および[removed: “…”]は材料の除去を示す)。イタリック体の要素は、上記で説明した現在シンタックスからの逸脱を示す。表6の例において、1に等しいdlt_depth_delta_equal_flag[i]は、(j+1)番目のエントリにおける深度値とj番目のエントリにおける深度値との間のすべての差分が同じであることを示す。さらに、0に等しいdlt_depth_delta_equal_flag[i]は、(j+1)番目のエントリにおける深度値とj番目のエントリにおける深度値との間のすべての差分が同じであるとは限らないことを示す。
[0174]さらに、dlt_depth_detla_value[i]は、連続するエントリ、すなわち、(j+1)番目のエントリとj番目のエントリとに関する2つの深度値間の差分を示す。dlt_depth_detla_value[i]は、両端値を含む、0〜(256−dlt_depth_start_value[i])/num_depth_values_in_dlt[i])の範囲内にある。dlt_depth_delta_equal_flag[i]が1に等しいとき、dlt_depth_detla_value[i]が存在する。他の例では、dlt_depth_detla_value[i]は、u(7)またはu(8)としてシグナリングされる。
[0175]さらに、dltDepthValue[i][j]は、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリを示し、次のように導出される。jが0に等しい場合、dltDepthValue[i][j]はdlt_depth_start_value[i]に等しく設定され、他の場合、dltDepthValue[i][j]は、dlt_depth_delta_equal_flag[i]が0に等しいとき、dltDepthValue[i][j−1]+dlt_depth_value_diff[i][j]に等しく設定され、dlt_depth_delta_equal_flag[i]が1に等しいとき、dltDepthValue[i][0]+dlt_depth_detla_value[i]*jに等しく設定される。
[0176]上記の表2〜表6に関して図示および説明する例は、概して、同じDLT内の深度値の予測に関する。DLTの1つまたは複数の値を予測することによって、DLTに関連する値の範囲(および、そのような値をシグナリングするために必要とされるビット)が低減され得る。すなわち、たとえば、0〜255の深度値の範囲をシグナリングするのではなく、比較的小さい深度差分値がシグナリングされ得る。
[0177]本開示の他の態様によれば、あるビューのDLTは他のビューを予測するために使用され得、本明細書ではビュー間DLT予測と呼ぶ。一例では、ビデオエンコーダ20は、参照ビューのDLTのどの連続するエントリが、DLT別のビューの連続するエントリと同じであるか(シフトが可能性であるか)の指示を符号化し得(ビデオデコーダ30は復号し得る)。すなわち、等しい深度値のロケーションが、1つまたは複数のシンタックス要素を使用して示され得る。
[0178]一例では、別のDLTと同じであるDLTの最初のエントリの開始位置を示すために、フラグがシグナリングされ得る。いくつかの例では、デフォルト開始位置は、0に等しいか、またはベースビューのDLTの最大エントリに等しくなり得る。たとえば、ベースビューがDLT中の深度値の第1のセットを有することと、非ベースビューがベースビューの深度値のすべて、ならびにベースビューの深度値よりも小さい追加の値を有することとを仮定する。すべての新たに追加された深度値がベースビュー中のDLTの最初のエントリよりも小さい場合、0に等しいフラグを設定することによって開始位置がシグナリングされ得る。
[0179]別の例では、ベースビューがDLT中の深度値の第1のセットを有することと、非ベースビューがベースビューの深度値のすべて、ならびにベースビューの深度値よりも大きい追加の値を有することとを仮定する。すべての新たに追加された深度値がベースビューのDLTの最後のエントリよりも大きい場合、1に等しいフラグが開始位置としてシグナリングされる。
[0180]他の例では、ビュー間で重複する深度値を示すために1つまたは複数のシンタックス要素ペアが使用され得る。たとえば、そのようなシンタックス要素は、重複する深度値の開始位置と、挿入されるべき深度値の数(重複する深度値の数)とを示し得る。DLTのための深度値のすべてがシグナリングされた(たとえば、すべてのペア中でシグナリングされた深度値の数の和が、非ベースとベースビューとの間の深度値の差分に等しくなった)後に、シグナリングプロセスは終了され得る。
[0181]さらに他の例では、新たに追加された深度値のすべてが最小(または最大)深度値よりも小さいか(またはより大きい)かどうかを示すために、1つまたは複数のシンタックス要素(たとえば、フラグ)が最初にシグナリングされ得る。追加の深度値がすべて、予測のために使用されているDLTからの深度値よりも小さいかまたはそれよりも大きいとは限らない場合、(重複する深度値の開始/終了を示す)シンタックス要素のペアの数の指示が最初にシグナリングされ得る。いくつかの例では、シンタックス要素のペアの数がシグナリングされるとき、最後のペア中の深度値の数はシグナリングされない。
[0182]上記の例のいずれにおいても、重複しない深度値(すなわち、2つ以上のDLT中に現れない深度値)は、上記の差分DLTシグナリングを使用してシグナリングされ得る。
[0183]上述のように、ベースビューおよび非ベースビューは、それらのそれぞれのDLT中に異なる数の深度値を有し得る。たとえば、深度値ベースビューの数が非ベースビュー中の深度値の数よりも小さいことがある。非ベースビュー中の異なる深度値の数がベースビュー中のそれよりも小さいとき、非ベースビュー中の第1の有効深度値の位置を示すためにベースビューのDLTのデフォルト開始位置がシグナリングされる。いくつかの例では、上述のように、(たとえば、現在の開始位置に関連するコピーされるべき深度値の開始位置と数とを示す)1つまたは複数のシンタックス要素ペアがシグナリングされ得る。すべてのペア中でシグナリングされた深度値の数の和が非ベースおよびベースビュー中の深度値に等しくなった後に、シグナリングプロセスは終了され得る。
[0184]いくつかの例では、すべての深度値がベースビューのDLTの連続するエントリからコピーされることが可能であるどうかを示すために、1つまたは複数のシンタックス要素(たとえば、フラグ)が最初にシグナリングされ得る。ベースビューDLTの深度値のすべてが非ベースビューにコピーされ得るとは限らない場合、シンタックス要素ペアの数が最初にシグナリングされ得る。いくつかの例では、シンタックス要素のペアの数がシグナリングされるとき、最後のペアにコピーされるべき深度値の数はシグナリングされない。いくつかの例では、非ベースビューとベースビューとの間の異なる深度値の数(たとえば、DLT中の要素の数)の差分がシグナリングされる。
[0185]したがって、本開示の態様によれば、1つのビューのDLTをシグナリングするために必要とされるデータの量を低減するために、イントラDLT予測が使用され得、他のビューのDLTをシグナリングするために必要とされるデータの量を低減するために、追加または代替として、ビュー間DLT予測が使用され得る。
[0186]いくつかの例では、ビュー間DLT予測の場合、非ベースビューの有効深度値の数がベースビューのそれよりも大きいとき、すべての新たに追加された深度値が、ベースビュー中のDLTの最初のエントリの前または最後のエントリの後に挿入される。他の例では、非ベースビューの有効深度値の数がベースビューの有効深度値の数よりも小さいとき、ベースビュー中のDLTからコピーされるすべての深度値は、ベースビュー中のDLTの連続するエントリを有する。
[0187]例示的なビュー間DLT予測のための例示的なVPSシンタックスを以下の表7に示す。
[0188]上記の表7の例において、イタリック体の要素は、表1に関して上記で説明した現在シンタックスからの逸脱を示す。表7の例において、1に等しいinter_view_dlt_pred_enable_flag[i]は、iに等しいlayer_idをもつ深度ビューが、現在ビュー中のDLTをシグナリングするためにビュー間DLT予測方法を使用することを示す。さらに、0に等しいinter_view_DLT_pred_enable_flag[i]は、iに等しいlayer_idをもつ深度ビューが、現在ビュー中のDLTをシグナリングするためにビュー間DLT予測方法を使用せず、代わりに、ベースビューと同様にDLTがシグナリングされること示す。
[0189]さらに、1に等しいleft_side_crop_or_extend_flag[i]は、num_depth_values_in_dlt[i]がnum_depth_values_in_dlt[1]よりも大きいとき、すべての新たに追加された深度値がベースビュー中のDLTの最初のエントリの前に挿入され、num_depth_values_in_dlt[i]がnum_depth_values_in_dlt[1]よりも小さいかそれに等しいとき、ベースビュー中のDLTの第1のnum_depth_values_in_dlt[i]エントリが、iに等しいlayer_idをもつビュー中のDLTに直接コピーされることを示す。
[0190]さらに、0に等しいleft_side_crop_or_extend_flag[i]は、num_depth_values_in_dlt[i]がnum_depth_values_in_dlt[1]よりも大きいとき、すべての新たに追加された深度値がベースビュー中のDLTの最後のエントリの後に挿入され、num_depth_values_in_dlt[i]がnum_depth_values_in_dlt[1]よりも小さいかそれに等しいとき、ベースビュー中のDLTの最後のnum_depth_values_in_dlt[i]エントリが、iに等しいlayer_idをもつビュー中のDLTに直接コピーされることを示す。
[0191]さらに、dlt_depth_value_diff_minus1[i][j]+1は、left_side_crop_or_extend_flag[i]が1に等しく、dlt_depth_value_diff_minus1[i][−1]が0であると推論されるとき、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中の((num_depth_values_in_dlt[i]−num_depth_values_in_dlt[1])−j−1)番目のエントリにおける差分値と比較される((num_depth_values_in_dlt[i]−num_depth_values_in_dlt[1])−j)番目のエントリにおける2つの深度値の差分を指定する。left_side_crop_or_extend_flag[i]が0に等しいとき、dlt_depth_value_diff_minus1[i][j]+1は、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中の(j−1+num_depth_values_in_dlt[1])番目のエントリにおける深度値と比較される(j+num_depth_values_in_dlt[1])番目のエントリにおける2つの深度値の差分を指定する。
[0192]さらに、dltDepthValue[i][j]は、iに等しい(iは1に等しくない)layer_idをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリと、inter_view_dlt_pred_enable_flag[i]が1に等しいこととを示し、次のように導出される。
num_depth_values_in_dlt_view_diff[i]が0よりも大きく、left_side_crop_or_extend_flag[i]が0に等しいとき、以下が適用される。
num_depth_values_in_dlt_view_diff[i]が0よりも大きく、left_side_crop_or_extend_flag[i]が1に等しいとき、以下が適用される。
[0193]別の例では、ビュー間DLT予測のためのプロセスは、上記で説明した例と同様であり得るが、非ベースビュー中の有効深度値の数がベースビューのそれよりも大きいとき、1つまたは複数のシンタックス要素および関連するセマンティクスが、ビュー間DLT予測をサポートするように変更され得る。新たに追加された深度値の一部がベースビュー中の最初のエントリの前に挿入され、新たに追加された深度値の一部がベースビュー中のDLTの最後のエントリの後に挿入される。この例のための例示的なVPSシンタックスを以下の表8に示す。
[0194]上記の表8の例において、イタリック体の要素は、表1に関して上記で説明した現在シンタックスからの逸脱を示す。表8の例において、max_diff_minus1[i]は、dlt_depth_value_diff_minus1[i][j]の範囲を指定する。シンタックス要素max_diff_minus1[i]は、Ceil(Log2(2BitDepthY−num_depth_values_in_dlt[i]))ビットによって表される。さらに、dlt_depth_value_diff_minus1[i][j]+1は、iに等しいlayer_idをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリと(j−1)番目のエントリとの間の深度値の差分を指定する。シンタックス要素dlt_depth_value_diff_minus1[i][j]は、Ceil(Log2(max_diff_minus1[i]+1))ビットによって表される。
[0195]さらに、depth_overlap_idc[i]は、iに等しいlayer_idをもつビューの深度値とベースビューの深度値との重複ステータスを指定する。存在しないとき、depth_overlap_idc[i]は0に等しいと推測され得る。0に等しいdepth_overlap_idc[i]は、両方のビューの深度値が重複しないことがあることを示し、この値は、1回depth_overlap_idc[i]が存在するために現在予約済みである。0よりも大きいdepth_overlap_idc[i]は、iに等しいlayer_idをもつビューの深度値と、ベースビューの深度値とが重複することを示し、dlt_depth_value[i][j+k]がdlt_depth_value[1][j]に等しく設定されるか、または、kが0に等しいかまたはそれよりも大きい場合、dlt_depth_value[i][j]がdlt_depth_value[1][j+k]に等しく設定され、連続する等しい深度値の数は、mim(num_depth_values_in_dlt[i],num_depth_values_in_dlt[1])に等しいnumOverlapValuesに等しい。
[0196]0よりも大きいdepth_overlap_idc[i]の値は、次の場合に対応する。1に等しいdepth_overlap_idc[i]は、dlt_depth_value[i][j+k]がdlt_depth_value[1][j]に等しく設定されることを示し、ここにおいて、jは、両端値を含む、0からnumOverlapValues−1までであり、kはmax(num_depth_values_in_dlt[i]−num_depth_values_in_dlt[1],0)に等しい。2に等しいdepth_overlap_idc[i]は、dlt_depth_value[i][j]がdlt_depth_value[1][[j+k]に等しく設定されることを示し、ここにおいて、jは、両端値を含む、0からnumOverlapValues−1までであり、kはmax(num_depth_values_in_dlt[1]−num_depth_values_in_dlt[i],0)に等しい。3に等しいdepth_overlap_idc[i]は、num_depth_values_in_dlt[i]がnum_depth_values_in_dlt[1]よりも大きいとき、dlt_depth_value[i][j+k]がdlt_depth_value[1][j]に等しく設定され、または、num_depth_values_in_dlt[i]がnum_depth_values_in_dlt[1]よりも小さいとき、dlt_depth_value[i][j]がdlt_depth_value[1][j+k]に等しく設定されることを示し、ここにおいて、jは、両端値を含む、0からnumOverlapValues−1までであり、kはnumber_left_nonoverlap_depth_values[i]に等しい。
[0197]加えて、さらに表8に示された例を参照すると、number_left_nonoverlap_depth_values[i]は、重複深度値領域の左側に、iまたは1に等しいlayer_idをもつビューの非重複深度値の数を指定する。いくつかの例では、number_left_nonoverlap_depth_values[i]は、両端値を含む、0〜Abs(num_depth_values_in_dlt[1]―num_depth_values_in_dlt[i])の範囲内にある。存在しないとき、number_left_nonoverlap_depth_values[i]は0に等しいと推論され得る。depth_overlap_idc[i]が0よりも大きく、num_depth_values_in_dlt[i]がnum_depth_values_in_dlt[1]よりも大きいとき、iに等しいlayer_idをもつビューの非重複深度値は、次のように導出される。
[0198]さらに別の例では、ビュー間DLT予測の場合、非ベースビューの有効深度値の数がベースビューのそれよりも大きいときでも、新たに追加された深度値の一部分が最初のエントリの前に挿入され得、新たに追加された深度値の一部分がベースビュー中のDLTの最後のエントリの後に挿入され得る。この例では、ビュー間DLT予測方法が依然として使用され得、すなわち、inter_view_dlt_pred_enable_flagは1に等しい。この例のための例示的なVPSシンタックスを以下の表9に示す。
[0199]上記の表9の例において、イタリック体の要素は、表1に関して上記で説明した現在シンタックスからの逸脱を示す。この例において、1に等しいcrop_extend_both_side_flag[i]は、非重複深度値の一部分がベースビュー中のDLTの最初のエントリの前に挿入され、残りの深度値がベースビュー中のDLTの最後のエントリの後に挿入されること、または、ベースビューのDLTの中間のnum_depth_values_in_dlt[i]深度値が、iに等しいlayer_idをもつビューによって重複されることを示し得る。さらに、0に等しいcrop_extend_both_side_flag[i]は、非重複深度値のすべてがベースビュー中のDLTの最初のエントリの前または最後のエントリの後に挿入されること、または、ベースビュー中のDLTの最初または最後のnum_depth_values_in_dlt[i]深度値が、iに等しいlayer_idをもつビューによって重複されることを示し得る。
[0200]さらに、1に等しいcrop_extend_both_side_flag[i]は、num_depth_values_in_dlt[i]がnum_depth_values_in_dlt[1]よりも大きいとき、dlt_depth_value[i][j+k]=dlt_depth_value[1][j]であり、または、num_depth_values_in_dlt[i]がnum_depth_values_in_dlt[1]よりも小さいとき、dlt_depth_value[i][j]=dlt_depth_value[0][j+k]であることを示し、ここで、jは、両端値を含む、0〜numOverlapValues−1であり、kはnumber_left_nonoverlap_depth_values[i]に等しい。さらに、0に等しいcrop_extend_both_side_flag[i]および1に等しいleft_side_crop_or_extend_flag[i]は、dlt_depth_value[i][j+k]=dlt_depth_value[1][j]であることを示し、ここにおいて、jは、両端値を含む、0からnumOverlapValues−1までであり、kはmax(num_depth_values_in_dlt[i]−num_depth_values_in_dlt[1],0)に等しい。さらに、0に等しいcrop_extend_both_side_flag[i]および0に等しいleft_side_crop_or_extend_flag[i]は、dlt_depth_value[i][j]=dlt_depth_value[1][j+k]であることを示し、ここにおいて、jは、両端値を含む、0からnumOverlapValues−1までであり、kはmax(num_depth_values_in_dlt[1]−num_depth_values_in_dlt[i],0)に等しい。
[0201]上記の例において、number_left_nonoverlap_depth_values[i]は、重複深度値領域の左側に、iまたは1に等しいlayer_idをもつビューの非重複深度値の数を指定する。number_left_nonoverlap_depth_values[i]は、両端値を含む、0〜abs(num_depth_values_in_dlt[1]−num_depth_values_in_dlt[i])の範囲を有し得る。存在しないとき、number_left_nonoverlap_depth_values[i]は0に等しいと推論され得る。
[0202]さらに、dltDepthValue[i][j]は、iに等しい(iは1に等しくない)layer_idをもつ深度ビューコンポーネントのためのDLT中のj番目のエントリを指示し、inter_view_dlt_pred_enable_flag[i]は1に等しく、次のように導出され得る。inter_view_dlt_pred_enable_flag[i]が1に等しいとき、num_depth_values_in_dlt[i]はnum_depth_values_in_dlt[1]よりも大きく、iに等しいlayer_idをもつビューの非重複深度値は次のように導出される。
crop_extend_both_side_flag[i]が1に等しいか、またはleft_side_crop_or_extend_flag[i]が0に等しいとき、以下が適用される。
crop_extend_both_side_flag[i]が1に等しいか、またはleft_side_crop_or_extend_flag[i]が1に等しいとき、以下が適用される。
[0203]本開示の態様はまた、DLT予測のシグナリングに関する。たとえば、表2〜表9の例についてVPSに関して説明するが、いくつかの例では、そのようなシグナリングは、PPSなど、別のパラメータセット中で実行され得る。
[0204]一例では、DLTは、DLTがシーケンスレベルで必要とされる場合にのみ、VPSまたはSPS中でシグナリングされ得る。ただし、ピクチャレベルで必要なときは、たとえば、ベースビューのスライスヘッダ拡張の一部として複数のビューのDLTがシグナリングされ得る。追加または代替として、DLTは、フラグがDLTの存在を示すとき、現在スライスがランダムアクセススライスであるとき、現在スライスがイントラのスライスタイプを有するときという状況のうちの1つでのみシグナリングされ得る。
[0205]いくつかの例では、複数のビューのDLTのビュー間予測が有効でないことがあり、DLTの存在を示すフラグがある場合、または、スライスがランダムなアクセスピクチャに属することを示すNALユニットタイプをスライスが有するとき、各DLTがスライスヘッダ中でシグナリングされ得る。他の例では、HEVCに記載されているように、DLTが適応パラメータセット中でシグナリングされ得る。
[0206]スライスレベルDLT予測の場合、一例では、DLTがスライスヘッダ中でシグナリングされ得、1つのピクチャ内の2つのスライス間の深度値の数(たとえば、DLT中の要素の数)間の差分がシグナリングされ得る。この例では、スライス間DLT予測が、ビュー間DLT予測に関して本明細書で説明する技法の任意の組合せを使用して達成され得る。
[0207]さらに他の例では、DLTがPPS中でシグナリングされ得、1つのビュー中の2つの異なるピクチャ間の深度値の数(すなわち、DLT中の要素の数)間の差分がシグナリングされ得る。再び、この例では、ピクチャ間DLT予測が、ビュー間DLT予測に関して本明細書で説明する技法の任意の組合せを使用して達成され得る。
[0208]一例では、PPS中のslice_segment_header_extension_present_flagを1になるように設定することと、slice_segment_header_extension_lengthのシンタックス要素の後のバイトを用いて情報を搬送することとによってピクチャレベルDLTシグナリングをサポートするために、DLTはスライスヘッダ中に存在する。この場合、DLTは、ベースビュー構成要素に関連するスライスヘッダ中にのみ存在し得る。
[0209]別の例では、DLTは1つのスライスヘッダ(たとえば、スライスヘッダ「A」)中でシグナリングされ得、スライスヘッダ予測を通して別のDLTのビュー間予測が有効になり得る。たとえば、(たとえば、同じアクセスユニット内のビューコンポーネントのための)1つまたは複数のスライスヘッダが、DLTを含んでいるスライスヘッダ「A」によって予測され得る。
[0210]別の例では、DLTは、たとえば、pps_extension_flagを1に設定することによってPPS中に存在し得る。さらに、DLTは、ベースビューのビューコンポーネント中のスライスによって参照されるPPS中にのみ存在することがある。この場合、PPSは、非ベースビューのビューコンポーネントによって依然として参照され得る。1つのPPSが、複数のビューのためのすべてのDLTを含んでいることがある。他の例では、ビューコンポーネントのDLTが、PPS中に存在し、同じビューに属するビューコンポーネントによってのみ参照され得る。
[0211]図8は、ビュー合成予測に関係する情報をコーディングするための例示的な方法を示すフローチャートである。図8の方法について、ビデオエンコーダ20(図1および図2)に関して説明する。ただし、他のビデオコーディングデバイスが、同様の方法を実行するように構成され得ることを理解されたい。その上、本方法におけるいくつかのステップは、異なる順序で、または並行して実行され得る。同様に、様々な例では、いくつかのステップが省略され得、他のステップが追加され得る。
[0212]図8の例において、ビデオエンコーダ20は、いくつかのピクチャおよび/またはスライスのための1つまたは複数の深度マップを決定する(160)。いくつかの事例では、ビデオエンコーダ20は、複数のビューを符号化し得、ビューのうちの1つまたは複数の深度マップを符号化し得る。ビデオエンコーダ20は、深度マップのためのDLTを生成し、たとえば、昇順で深度マップの深度値を分類する(162)。ビデオエンコーダ20が複数のビューを符号化する事例では、ビデオエンコーダ20は、ビューのうちの1つまたは複数のためのDLTを生成し得る。
[0213]本開示のいくつかの態様によれば、ビデオエンコーダ20は、第1のDLTのための第1の深度値を決定する(164)。さらに、ビデオエンコーダ20は、第1のDLTの残りの深度値のための差分値を決定する(166)。たとえば、ビデオエンコーダは、第1のDLTの1つまたは複数の他の値に対して第1のDLTの1つまたは複数の深度値を符号化し得る。いくつかの例では、ビデオエンコーダ20は、第1のDLTの連続する値間の差分を決定し、差分値を符号化し得る。他の例では、上述のように、ビデオエンコーダ20は、たとえば、3つ以上の連続する値間の2次差分を決定し得る。いくつかの例では、ビデオエンコーダ20は、差分値をコーディングするとき、深度値差分の範囲(たとえば、最大差分または最小差分)を考慮し得る。
[0214]ビデオエンコーダ20は、関連するDLTをもつ2つ以上のビューがあるかどうかを決定し得る(168)。いくつかの例では、関連するDLTをもつ2つ以上のビューがある場合、ビデオエンコーダ20は、他のビューのDLTのための差分深度値を決定する(170)。たとえば、ビデオエンコーダ20は、あるDLTの1つまたは複数の深度値が別のビューの別のDLTの1つまたは複数の深度値と同様であることを示す、1つまたは複数のシンタックス要素を符号化し得る。いくつかの例では、上述のように、シンタックス要素は重複する深度値(たとえば、2つ以上のDLT中に現れる深度値)のロケーションを示し得る。
[0215]ビデオエンコーダ20は、次いで、ビットストリーム中のDLTを符号化する(172)。たとえば、ビデオエンコーダ20は、本明細書で説明したシンタックス要素を表すデータを符号化し得、いくつかの例では、PPSなど、パラメータセット中にそのようなデータを含め得る。
[0216]図9は、ビュー合成予測に関係する情報をコーディングするための例示的な方法を示すフローチャートである。図9の方法について、ビデオデコーダ30(図1および図3)に関して説明する。ただし、他のビデオコーディングデバイスが、同様の方法を実行するように構成され得ることを理解されたい。その上、本方法におけるいくつかのステップは、異なる順序で、または並行して実行され得る。同様に、様々な例では、いくつかのステップが省略され得、他のステップが追加され得る。
[0217]図9の例において、ビデオデコーダ30は、符号化ビットストリームからの圧縮されたDLTを復号する(180)。たとえば、ビデオデコーダ30は、1つまたは複数の他の深度値の値に対して1つまたは複数の深度値の値を示し得る、深度差分値のセットを復号し得る。さらに、ビデオデコーダ30は、DLTを再構成する際にビデオデコーダ30を支援するための様々な他の情報(たとえば、表2〜表9に関して上記で説明した他のシンタックスなど)を復号し得る。
[0218]本開示のいくつかの態様によれば、ビデオデコーダ30は、第1のDLTのための第1の深度値を決定する(182)。たとえば、ビデオデコーダ30は、第1のDLTの相対的な第1の深度値の値を示す1つまたは複数のシンタックス要素を受信し、シンタックスに基づいて第1の深度値を決定し得る。
[0219]さらに、ビデオデコーダ30は、第1のDLTの残りの深度値のために受信された差分値を使用して残りの深度値を再構成する(184)。たとえば、ビデオデコーダ30は、第1のDLTの1つまたは複数の他の深度値に対して1つまたは複数の深度値の値を示す1つまたは複数のシンタックス要素を受信し得る。いくつかの例では、ビデオデコーダ30は、第1のDLTの連続する値間の差分を示す1つまたは複数のシンタックス要素を復号し得る。他の例では、上述のように、ビデオデコーダ30は、たとえば、3つ以上の連続する値間の2次差分を示すシンタックス要素を受信し得る。いくつかの例では、ビデオデコーダ30は、差分値を復号するときに深度値差分の範囲(たとえば、最大差分または最小差分)を考慮し得る。いずれの場合も、ビデオデコーダ30は、たとえば、差分値を適切な前に再構成された深度値に加算することによって、受信された値に基づいて第1のDLTを再構成し得る。
[0220]いくつかの事例では、ビデオデコーダ30は、複数のビューを復号し得、ビューのうちの1つまたは複数のDLTおよび深度マップを復号し得る。したがって、ビデオデコーダ30は、関連するDLTをもつ2つ以上のビューがあるかどうかを決定し得る(186)。いくつかの例では、関連するDLTをもつ2つ以上のビューがある場合、ビデオデコーダ30は、他のビューのDLTのための受信された差分値を使用して他のビューのDLTを再構成する(188)。たとえば、ビデオデコーダ30は、あるDLTの1つまたは複数の深度値が別のビューの別のDLTの1つまたは複数の深度値と同じであることを示す、1つまたは複数のシンタックス要素を復号し得る。いくつかの例では、上述のように、シンタックス要素は重複する深度値(たとえば、2つ以上のDLT中に現れる深度値)のロケーションを示し得る。
[0221]ビデオデコーダ30は、次いで、復号されたDLTを使用してピクチャのための深度マップを決定する(190)。たとえば、上述のように、ビデオデコーダ30は、(たとえば、インデックス差分値と予測子との組合せに基づいて)ピクチャの深度値のためのDLTへのインデックスを決定し得る。
[0222]上記で説明した技法は、その両方が一般にビデオコーダと呼ばれることがある、ビデオエンコーダ20(図1および図2)および/またはビデオデコーダ30(図1および図3)によって実行され得る。さらに、ビデオコーディングは、概して、適用可能な場合、ビデオ符号化またはビデオ復号を指し得る。
[0223]本開示の技法について概して3D−HEVCに関して説明するが、本技法はこのように限定されない。上記で説明した技法はまた、他の現在の規格またはまだ開発されていない将来の規格に適用可能であり得る。たとえば、深度コーディングのための技法はまた、HEVCのマルチビュー拡張(たとえば、いわゆるMV−HEVC)、HEVCに対するスケーラブル拡張、または深度コンポーネントを有する他の現在または将来の規格に適用可能であり得る。
[0224]例に応じて、本明細書で説明した方法のうちのいずれかのいくつかの行為またはイベントは、異なるシーケンスで実行され得、互いに付加、マージ、または除外され得る(たとえば、すべての説明した行為またはイベントが、方法の実施のために必要であるとは限らない)ことを理解されたい。その上、いくつかの例では、行為またはイベントは、連続的にではなく、同時に、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通じて実行され得る。さらに、本開示のいくつかの態様について、明快のために単一のモジュールまたはユニットによって実行されるものとして説明したが、本開示の技法は、ビデオコーダに関連するユニットまたはモジュールの組合せによって実行され得ることを理解されたい。
[0225]技法の様々な態様の特定の組合せについて上記で説明したが、これらの組合せは、本開示で説明する技法の例を単に示すために与えられる。したがって、本開示の技法は、これらの例示的な組合せに限定されるべきではなく、本開示で説明される技法の様々な態様の任意の想起可能な組合せを包含し得る。
[0226]1つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含み得る。
[0227]このようにして、コンピュータ可読媒体は、概して、(1)非一時的である有形コンピュータ可読記憶媒体、あるいは(2)信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明する技法の実装のための命令、コードおよび/またはデータ構造を取り出すために、1つまたは複数のコンピュータあるいは1つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読記憶媒体とパッケージング材料とを含み得る。
[0228]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM(登録商標)、CD−ROMまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。
[0229]ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用されるディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)およびblu−ray(登録商標)ディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。
[0230]命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、あるいは他の等価な集積回路またはディスクリート論理回路など、1つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書で説明する技法の実装に好適な他の構造のいずれかを指すことがある。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび/またはソフトウェアモジュール内に与えられるか、あるいは複合コーデックに組み込まれ得る。また、本技法は、1つまたは複数の回路または論理要素中に十分に実装され得る。
[0231]本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示する技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットについて説明したが、それらの構成要素、モジュール、またはユニットを、必ずしも異なるハードウェアユニットによって実現する必要があるとは限らない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび/またはファームウェアとともに、上記で説明した1つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作ハードウェアユニットの集合によって与えられ得る。
[0232]本開示の様々な態様について説明した。これらおよび他の態様は以下の特許請求の範囲内に入る。