JP2017512032A - ３ｄビデオコーディングのための制限付き深度イントラモードコーディング - Google Patents

３ｄビデオコーディングのための制限付き深度イントラモードコーディング Download PDF

Info

Publication number
JP2017512032A
JP2017512032A JP2016556742A JP2016556742A JP2017512032A JP 2017512032 A JP2017512032 A JP 2017512032A JP 2016556742 A JP2016556742 A JP 2016556742A JP 2016556742 A JP2016556742 A JP 2016556742A JP 2017512032 A JP2017512032 A JP 2017512032A
Authority
JP
Japan
Prior art keywords
prediction unit
depth prediction
depth
syntax element
dmm
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2016556742A
Other languages
English (en)
Other versions
JP6445039B2 (ja
Inventor
リウ、ホンビン
チェン、イン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2017512032A publication Critical patent/JP2017512032A/ja
Application granted granted Critical
Publication of JP6445039B2 publication Critical patent/JP6445039B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/119—Adaptive subdivision aspects, e.g. subdivision of a picture into rectangular or non-rectangular coding blocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
    • H04N19/159—Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/423—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/593—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/96—Tree coding, e.g. quad-tree coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/11—Selection of coding mode or of prediction mode among a plurality of spatial predictive coding modes

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

本開示は、３次元（３Ｄ）−高効率ビデオコーディング（３Ｄ−ＨＥＶＣ）のような３Ｄビデオコーディング処理における深度イントラモードコーディングを制限するための技法について説明する。いくつかの例では、深度イントラモードコーディングを制限するための技法は、変換木ノードに対応する深度予測ユニットが深度モデリングモード（ＤＭＭ）に従って予測されるときに、変換木ノードがサブ変換木ノードに分割されるのを防ぎ得る。さらなる例では、深度イントラモードコーディングを制限するための技法は、深度予測ユニットに対応する最大変換ユニットサイズが深度予測ユニットのサイズよりも大きいときに、ＤＭＭモードが使用されるのを防ぎ得る。深度イントラモードコーディングを制限するための技法は、３Ｄ−ＨＥＶＣにおいて使用されるＤＭＭ予測モードの特性と３Ｄ−ＨＥＶＣにおいて使用される変換木細分の特性とが互いに干渉するのを防ぎ得る。

Description

[0001]本開示は、ビデオコーディングに関し、より具体的には、３次元（３Ｄ）ビデオコーディング処理における深度イントラモードコーディング（depth Intra mode coding）に関する。
[0002]デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、タブレットコンピュータ、スマートフォン、携帯情報端末（ＰＤＡ）、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、携帯電話または衛星無線電話、ビデオ遠隔会議デバイス、セットトップデバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３、ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４、Ｐａｒｔ１０、アドバンストビデオコーディング（ＡＶＣ：Advanced Video Coding）、高効率ビデオコーディング（ＨＥＶＣ：High Efficiency Video Coding）によって定義された規格、およびそのような規格の拡張に記述されているビデオ圧縮技法などのビデオ圧縮技法を実装する。
[0003]エンコーダ−デコーダ（コーデック）は、ビデオシーケンスの冗長性を低減または除去するように空間（イントラピクチャ）予測および／または時間（インターピクチャ）予測を実行するために、ビデオ圧縮技法を適用する。ブロックベースのビデオコーディングの場合、ビデオスライスが、コード化ツリーブロック（ＣＴＢ：coded treeblocks）、コーディングユニット（ＣＵ）および／またはコーディングノードと呼ばれることもあるビデオブロックに区分（partitioned）され得る。ピクチャのイントラコード化（Ｉ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロックにおける参照サンプルに対する空間予測を使用して符号化される。ピクチャのインターコード化（ＰまたはＢ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロックにおける参照サンプルに対する空間予測、または他の参照ピクチャ中の参照サンプルに対する時間予測を使用し得る。
[0004]空間予測または時間予測は、コーディングされるべきブロックのための予測ブロックをもたらす。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコード化ブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトルに従って符号化され、残差データは、コード化ブロックと予測ブロックとの間の差分を示す。イントラコード化ブロックは、イントラコーディングモードおよび残差データに従って符号化される。さらなる圧縮のために、残差データは空間領域から変換領域に変換され、残差変換係数が得られ得、その残差変換係数は、次いで量子化され得る。
[0005]マルチビューコーディングビットストリームは、たとえば、複数の視点からのビューを符号化することによって生成され得る。マルチビューコーディングは、デコーダが、異なるビューを選択すること、または場合によっては複数のビューをレンダリングすることを可能にし得る。加えて、開発されている、または開発中のいくつかの３次元（３Ｄ）ビデオ技法および規格は、マルチビューコーディングの態様を利用する。たとえば、いくつかの３Ｄビデオコーディング処理では、３Ｄビデオをサポートするために、異なるビューが左眼のビューと右眼のビューとを送信するために使用され得る。他の３Ｄビデオコーディング処理は、マルチビュープラス深度コーディングを使用し得る。ＨＥＶＣに対する３Ｄ−ＨＥＶＣ拡張によって定義される処理のようなマルチビュープラス深度コーディング処理では、３Ｄビデオビットストリームは、複数のビューを含み得る。ビューの各々は、テクスチャビュー成分と深度ビュー成分とを含み得る。たとえば、所与のビューは、テクスチャビュー成分と深度ビュー成分とを備え得る。テクスチャビュー成分および深度ビュー成分は、３Ｄビデオデータを構築するために使用され得る。
[0006]本開示は、３次元（３Ｄ）−高効率ビデオコーディング（３Ｄ−ＨＥＶＣ）のような３Ｄビデオコーディング処理における深度イントラモードコーディングを制限するための技法について説明する。いくつかの例では、深度イントラモードコーディングを制限するための技法は、変換木ノードに対応する深度予測ユニットが深度モデリングモード（ＤＭＭ）に従って予測されるときに、変換木ノードがサブ変換木ノードに分割されるのを防ぎ得る。さらなる例では、深度イントラモードコーディングを制限するための技法は、深度予測ユニットに対応する最大変換ユニットサイズが深度予測ユニットのサイズよりも大きいときに、ＤＭＭモードが使用されるのを防ぎ得る。深度イントラモードコーディングを制限するための技法は、３Ｄ−ＨＥＶＣにおいて使用されるＤＭＭ予測モードの特性と３Ｄ−ＨＥＶＣにおいて使用される変換木細分（transform tree subdivision）の特性とが互いに干渉するのを防ぎ得る。
[0007]一例では、本開示は、符号化ビデオビットストリームの変換木ノードを、変換木ノードに対応する深度予測ユニットがＤＭＭに従って予測されるかどうかに少なくとも部分的に基づいて、複数のサブ変換木ノードに選択的に分割するか、または分割しないことを含むビデオ復号の方法について説明する。本方法は、変換木ノードが複数のサブ変換木ノードに分割されるかどうかに少なくとも部分的に基づいて、変換木ノードを復号することをさらに含む。
[0008]別の例では、本開示は、変換木ノードに対応する深度予測ユニットがＤＭＭに従って予測されるかどうかに少なくとも部分的に基づいて、変換木ノードを複数のサブ変換木ノードに選択的に分割するか、または分割しないことを含むビデオ符号化の方法について説明する。本方法は、変換木ノードが複数のサブ変換木ノードに分割されるかどうかに少なくとも部分的に基づいて、変換木ノードを符号化することをさらに含む。本方法は、符号化ビデオビットストリームがコード化変換木ノードを含むように符号化ビデオビットストリームを生成することをさらに含む。
[0009]別の例では、本開示は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうかに少なくとも部分的に基づいて、ＤＭＭ予測モードまたは非ＤＭＭ予測モードに従って深度予測ユニットを選択的に予測することを含むビデオ復号の方法について説明する。本方法は、深度予測ユニットを、予測される深度予測ユニットに少なくとも部分的に基づいて復号することをさらに含む。
[0010]別の例では、本開示は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうかに少なくとも部分的に基づいて、ＤＭＭ予測モードまたは非ＤＭＭ予測モードに従って深度予測ユニットを選択的に予測することを含むビデオ符号化の方法について説明する。本方法は、深度予測ユニットを、予測される深度予測ユニットに少なくとも部分的に基づいて符号化することをさらに含む。本方法は、符号化ビデオビットストリームがコード化深度予測ユニットを含むように符号化ビデオビットストリームを生成することをさらに含む。
[0011]別の例では、本開示は、ＤＭＭに従って深度予測ユニットを予測するかどうかを決定することを含むビデオ復号の方法について説明する。深度予測ユニットは、１つまたは複数の変換ユニットを含む。本方法は、深度予測ユニットがＤＭＭに従って予測されるべきではないときに、ある変換ユニットレベルおよびあるコーディング順序で、深度予測ユニットの変換ユニットの各々を予測し再構築することをさらに含む。本方法は、深度予測ユニットがＤＭＭに従って予測されるべきであるときに、ある予測ユニットレベルで、深度予測ユニットのすべてのサンプルを予測することをさらに含む。
[0012]別の例では、本開示は、ＤＭＭに従って深度予測ユニットを予測するかどうかを決定することを含むビデオ符号化の方法について説明する。深度予測ユニットは、１つまたは複数の変換ユニットを含む。本方法は、深度予測ユニットがＤＭＭに従って予測されるべきではないときに、ある変換ユニットレベルおよびあるコーディング順序で、深度予測ユニットの変換ユニットの各々を予測し再構築することをさらに含む。本方法は、深度予測ユニットがＤＭＭに従って予測されるべきであるときに、ある予測ユニットレベルで、深度予測ユニットのすべてのサンプルを予測することをさらに含む。
[0013]他の例では、本開示は、上述の方法のうちの１つまたは複数を実行するように構成された１つまたは複数のプロセッサを含むビデオコーダを含むビデオコーディング装置について説明する。追加の例では、本開示は、実行時に、１つまたは複数のプロセッサに上述の方法のうちの１つまたは複数を実行させる命令を記憶したコンピュータ可読媒体について説明する。さらなる例では、本開示は、上述の方法のうちの１つまたは複数を実行するための手段を備えるビデオコーディング装置について説明する。
[0014]本開示の１つまたは複数の態様の詳細が、添付の図面および以下の説明において記載される。本開示で説明される技法の他の特徴、目的、および利点は、これらの説明および図面から、ならびに特許請求の範囲から明らかになろう。
[0015]高効率ビデオコーディング（ＨＥＶＣ）において使用されるイントラ予測モードを示す概念図。 [0016]本開示の技法を利用することができる例示的なビデオコーディングシステムを示すブロック図。 [0017]コーディングユニットを区分する際に使用するための例示的な区分モードを示す概念図。 [0018]コーディングユニット内の例示的な変換木構造を示す概念図。 [0019]ＰＡＲＴ＿Ｎ×Ｎ区分モードにより区分されるイントラコード化コーディングユニット内の変換木構造の例を示す概念図。 [0020]例示的な変換木構造の例示的な変換ユニット処理順序を示す図。 [0021]ピクセルサンプルの８×８のブロックをコーディングする際に使用するための１つのｗｅｄｇｅｌｅｔ区分パターンの例を示す概念図。 [0022]ピクセルサンプルの８×８のブロックをコーディングする際に使用するための１つの輪郭区分パターンの例を示す概念図。 [0023]本開示の技法を実装することができる例示的なビデオエンコーダを示すブロック図。 [0024]本開示の技法を実装することができる例示的なビデオデコーダを示すブロック図。 [0025]本開示による、制限付きビデオ符号化を実行するための例示的な技法を示す流れ図。 [0026]本開示による、制限付きビデオ復号を実行するための例示的な技法を示す流れ図。 [0027]本開示による、制限付きビデオ符号化を実行するための例示的な技法を示す流れ図。 [0028]本開示による、制限付きビデオ符号化を実行するための例示的な技法を示す流れ図。 [0029]本開示による、制限付きビデオ復号を実行するための例示的な技法を示す流れ図。 [0030]本開示による、制限付きビデオ復号を実行するための別の例示的な技法を示す流れ図。 [0031]本開示による、制限付きビデオ符号化を実行するための例示的な技法を示す流れ図。 [0032]本開示による、制限付きビデオ復号を実行するための例示的な技法を示す流れ図。 [0033]本開示による、制限付きビデオ符号化を実行するための例示的な技法を示す流れ図。 [0034]本開示による、制限付きビデオ符号化を実行するための例示的な技法を示す流れ図。 [0035]本開示による、制限付きビデオ復号を実行するための例示的な技法を示す流れ図。 [0036]本開示による、制限付きビデオ復号を実行するための別の例示的な技法を示す流れ図。 [0037]本開示による、ビデオをコーディングするための例示的な技法を示す流れ図。
[0038]本開示は、３次元（３Ｄ）−高効率ビデオコーディング（３Ｄ−ＨＥＶＣ）のような３Ｄビデオコーディング処理における深度イントラモードコーディングを制限するための技法について説明する。いくつかの例では、深度イントラモードコーディングを制限するための技法は、変換木ノードに対応する深度予測ユニットが深度モデリングモード（ＤＭＭ）に従って予測されるときに、変換木ノードがサブ変換木ノードに分割されるのを防ぎ得る。さらなる例では、深度イントラモードコーディングを制限するための技法は、深度予測ユニットに対応する最大変換ユニットサイズが深度予測ユニットのサイズよりも大きいときに、ＤＭＭモードが使用されるのを防ぎ得る。深度イントラモードコーディングを制限するための技法は、３Ｄ−ＨＥＶＣにおいて使用されるＤＭＭ予測モードの特性と３Ｄ−ＨＥＶＣにおいて使用される変換木細分の特性とが互いに干渉するのを防ぎ得る。
[0039]概して、本開示は、３Ｄ−ＨＥＶＣコーデックを用いた２つ以上のビューのコーディングを含む、アドバンストコーデックに基づくマルチビュービデオコーディング（たとえば、符号化または復号）に関する。より具体的には、本技法は、３Ｄ−ＨＥＶＣにおける深度イントラモードコーディングに関する。
[0040]本開示は、３Ｄ−ＨＥＶＣのような３Ｄビデオコーディング処理における深度イントラモードコーディングを制限するための技法について説明する。いくつかの例では、深度イントラモードコーディングを制限するための技法は、変換ユニットおよび／または変換木が細分されるのを、そのような細分が深度モデリングモード（ＤＭＭ）に従った深度予測ユニットのイントラコーディングに干渉することになる場合に防ぎ得る。
[0041]さらなる例では、深度イントラモードコーディングを制限するための技法は、ＤＭＭに従って深度成分をイントラコーディングするときに、予測ユニット全体が同じｗｅｄｇｅｌｅｔパターンに従ってコーディングされるように使用され得る。追加の例では、深度イントラモードコーディングを制限するための技法は、ＤＭＭに従って深度成分をイントラコーディングするときに、予測ユニットが３つ以上の領域ではなく２つの領域に分割されるようにし得る。
[0042]３Ｄ−ＨＥＶＣの現行バージョンによるＤＭＭコーディングに関係する問題がここで説明される。イントラ予測モードによりコーディングされるコーディングユニット（ＣＵ）に関して、セグメントごとのＤＣコーディング（ＳＤＣ：segment-wise DC coding）（たとえば、セグメントごとの直流電流（segment-wise direct current）（ＤＣ））が適用されない場合、１つの変換木（利用可能な場合）が、ＣＵの残差を表すようにコーディングされ、各ＰＵが変換木ノードに対応する。ＤＭＭコード化ＰＵの関連変換木ノードに対する深度制限はない。言い換えれば、そのような変換木ノード内の変換ユニット（ＴＵ）は、ＰＵサイズから最小許容可能ＴＵサイズ（たとえば、４×４）までのサイズをとり得る。しかしながら、そのような変換木ノードの深度が０よりも大きく、ＴＵサイズがＰＵサイズよりも小さいとき、２つの問題が生じ得る。
[0043]３Ｄ−ＨＥＶＣでは現在、予測ユニットは、予測ユニット全体に同じ予測処理が使用されるように定義されている。予測ユニットに関連付けられる変換ユニットは、複数のより小さい変換ユニットに区分され得る。ＤＭＭコーディングモードは、変換ユニットの各々をコーディングするためにｗｅｄｇｅｌｅｔパターンを使用することができる。変換ユニットの各々をコーディングするために使用されるｗｅｄｇｅｌｅｔパターンは、デコーダによって、ｗｅｄｇｅｌｅｔパターンインデックスおよびコーディングされるべき変換ユニットのサイズに基づいて決定され得る。場合によっては、単一の予測ユニットを形成する変換ユニットは、異なるサイズであり得る。そのような場合に、ＤＭＭコーディングが使用される場合、異なる変換ユニットは異なるｗｅｄｇｅｌｅｔパターンに従ってコーディングされ得る。これにより、予測ユニットを予測するために使用される予測処理が予測ユニットの部分ごとに異なることがあり、その結果、予測ユニットに関する現在の３Ｄ−ＨＥＶＣ定義に準拠しない予測ユニットが生じることがある。
[0044]いくつかの例では、本開示の技法は、ＤＭＭコーディングモードを使用してコーディングされる予測ユニットに対応する変換木ノード（たとえば、変換ユニット）がより小さい変換ユニットに区分されないように、変換ユニットの細分を制限することができる。たとえば、変換木ノードに関連付けられる予測ユニット（ＰＵ）がＤＭＭモードのうちの１つ（たとえば、ＤＭＭモード１またはＤＭＭモード４）によりコーディングされるとき、変換木ノードのｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇが０に設定され得る。
[0045]いくつかの例では、エンコーダは、変換木ノードに対応する予測ユニットがＤＭＭコーディングモードを使用してコーディングされるかどうかに基づいて、変換木ノードに対応するｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値を選択することができる。変換木ノードに対応する予測ユニットがＤＭＭコーディングモードを使用してコーディングされる場合、エンコーダは、対応する変換木ノードがさらに区分されるべきではないことを示すｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値を選択することができる。変換木ノードに対応する予測ユニットがＤＭＭコーディングモードを使用してコーディングされない場合、エンコーダは、対応する変換木ノードがさらに区分されることを可能にする１つまたは複数の他のｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇ選択技法に基づくｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値を選択することができる。ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇは、変換木ノード（たとえば、変換木、変換ユニット、変換ブロック）が複数のより小さい変換木ノードに分割、細分、および／または区分されるべきかどうかを示すことができる。さらなる例では、デコーダは、前述の例に従って符号化されたビットストリームを復号することができる。
[0046]追加の例では、エンコーダは、変換木ノードに対応する予測ユニットがＤＭＭコーディングモードを使用してコーディングされるかどうかに基づいて、変換木ノードのために符号化ビットストリームに、変換木ノードに対応するｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを選択的に含めることができる。変換木ノードに対応する予測ユニットがＤＭＭコーディングモードを使用してコーディングされる場合、エンコーダは、ビットストリームにｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを含めなくてよく、それによりデコーダは、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値が０であると推測することができる。変換木ノードに対応する予測ユニットがＤＭＭコーディングモードを使用してコーディングされない場合、エンコーダは、ビットストリームにｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを含めること、および／または他の基準に基づいてビットストリームにｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを含めるかどうかを決定することができる。さらなる例では、デコーダは、前述の例に従って符号化されたビットストリームを復号することができる。
[0047]いくつかの例では、デコーダは、変換木ノードに対応する予測ユニットがＤＭＭコーディングモードを使用してコーディングされるかどうかに基づいて、変換木ノードのために符号化ビットストリームからｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを解析、抽出，および／または復号するかどうかを決定することができる。たとえば、変換木ノードに対応する予測ユニットがＤＭＭコーディングモードを使用してコーディングされる場合、デコーダは、符号化ビットストリームからｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを解析しなくてよい。この例では、変換木ノードに対応する予測ユニットがＤＭＭコーディングモードを使用してコーディングされない場合、デコーダは、符号化ビットストリームからｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを解析する（たとえば、抽出する）すること、および／または状況によってはビットストリームからｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを解析することを可能にする他の基準に基づいて、符号化ビットストリームからｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを解析するかどうかを決定することができる。いくつかの例では、デコーダが符号化ビットストリームからｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを解析しないとき、デコーダは、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値が所定の推測値（たとえば、０）に等しいと推測することができる。
[0048]３Ｄ−ＨＥＶＣでは現在、ＤＭＭモード１または４は、ＰＵが２つの領域に区分されるべきであることを指定している。ＰＵがＤＭＭモード１またはＤＭＭモード４によりコーディングされるとき、ＰＵ内のＴＵの各々が２つの領域に区分される。したがって、ＰＵは、複数のＴＵを含んでいるときに、３つ以上の領域を含み得る。
[0049]いくつかの例では、本開示の技法は、ＤＭＭに従って深度成分をイントラコーディングするときに、予測ユニットが３つ以上の領域ではなくせいぜい２つの領域に分割されるようにし得る。たとえば、本開示の技法は、ＰＵサイズが最大変換ブロックサイズよりも大きいときに、ＤＭＭコーディングモードが使用されることを不可能にし得る。
[0050]いくつかの例では、エンコーダは、予測ユニット（ＰＵ）のサイズがＰＵに対応する最大変換ブロックサイズよりも大きいかどうかに基づいて、ＰＵに対応するｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値を選択することができる。ＰＵのサイズがＰＵに対応する最大変換ブロックサイズよりも大きい場合、エンコーダは、ＰＵをコーディングするためにＤＭＭモードが使用されないことを示すｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値を選択することができる。ＰＵのサイズがＰＵに対応する最大変換ブロックサイズよりも大きくない場合、エンコーダは、ＰＵをコーディングするためにＤＭＭモードが使用されることを可能にする１つまたは複数の他のｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ選択技法に基づくｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値を選択することができる。ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、対応する予測ユニットをコーディングするためにＤＭＭモードのうちの１つが使用されるべきかどうかを示すことができる。さらなる例では、デコーダは、前述の例に従って符号化されたビットストリームを復号することができる。
[0051]追加の例では、エンコーダは、ＰＵのサイズがＰＵに対応する最大変換ブロックサイズよりも大きいかどうかに基づいて、予測ユニットに対応するｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを選択的に含めることができる。ＰＵのサイズがＰＵに対応する最大変換ブロックサイズよりも大きい場合、エンコーダは、ビットストリームにｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを含めなくてよく、それによりデコーダは、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値が１であると推測することができる。ＰＵのサイズがＰＵに対応する最大変換ブロックサイズよりも大きくない場合、エンコーダは、ビットストリームにｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを含めること、および／または他の基準に基づいて、ビットストリームにｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを含めるかどうかを決定することができる。さらなる例では、デコーダは、前述の例に従って符号化されたビットストリームを復号することができる。
[0052]いくつかの例では、デコーダは、予測ユニット（ＰＵ）のサイズがＰＵに対応する最大変換ブロックサイズよりも大きいかどうかに基づいて、ＰＵのために符号化ビットストリームからｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを解析、抽出、および／または復号するかどうかを決定することができる。たとえば、ＰＵのサイズがＰＵに対応する最大変換ブロックサイズよりも大きい場合、デコーダは、符号化ビットストリームからｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを解析しなくてよい。この例では、ＰＵのサイズがＰＵに対応する最大変換ブロックサイズよりも大きくない場合、デコーダは、符号化ビットストリームからｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを解析する（たとえば、抽出する）すること、および／または状況によってはビットストリームからｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを解析することを可能にする他の基準に基づいて、符号化ビットストリームからｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを解析するかどうかを決定することができる。いくつかの例では、デコーダが符号化ビットストリームからｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを解析しないとき、デコーダは、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値が所定の推測値（たとえば、１）に等しいと推測することができる。
[0053]さらなる例では、ＰＵがＤＭＭモードのうちの１つによりコーディングされるとき、復号順序で１つずつＰＵ内のＴＵを予測し再構築する代わりに、ＰＵ全体が、その中のＴＵを再構築する前に３Ｄ−ＨＥＶＣがするのと同じ方法を使用して予測され得る。その後、ＰＵの再構築サンプルが、ＰＵの予測サンプルにＰＵの関連変換木ノードによって表される残差を加算することによって導出され得る。
[0054]いくつかの例では、ビデオエンコーダは、本開示で説明される制限付き深度イントラコーディングおよび／または制限付きＤＭＭコーディングのための技法のうちのいずれかを実行するように構成され得る。たとえば、ビデオエンコーダは、対応する深度予測ユニットが深度モデリングモード（ＤＭＭ）に従ってコーディングされるときに、（たとえば、変換木ノードが複数のより小さい変換木ノードに分割されるべきではないことを示すために）０に等しくなるようにｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを制限する技法を使用することができる。別の例として、ビデオエンコーダは、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいときに、（たとえば、ＤＭＭコーディングモードが深度予測ユニットに使用されないことを示すために）１に等しくなるようにｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを制限する技法を使用することができる。
[0055]さらなる例として、ビデオエンコーダは、対応する深度予測ユニットがＤＭＭに従ってコーディングされるかどうかに基づいて、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを選択的にシグナリングする技法を使用することができる。追加の例として、ビデオエンコーダは、対応する深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいかどうかに基づいて、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを選択的にシグナリングする技法を使用することができる。いくつかの例では、上述の技法のうちの１つまたは複数は、変換ユニットおよび／または変換木が細分されるのを、そのような細分が深度モデリングモード（ＤＭＭ）に従った深度予測ユニットのイントラコーディングに干渉することになる場合に防ぎ得る。
[0056]さらなる例では、ビデオデコーダは、本開示で説明される制限付き深度イントラコーディングおよび／または制限付きＤＭＭコーディングのための技法のうちのいずれかを実行するように構成され得る。たとえば、ビデオデコーダは、対応する深度予測ユニットが深度モデリングモード（ＤＭＭ）に従ってコーディングされるときに、（たとえば、変換木ノードが複数のより小さい変換木ノードに分割されるべきではないことを示すために）ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇが０に等しくなることを指定する制限を満たす符号化ビットストリームを復号する技法を使用することができる。別の例として、ビデオデコーダは、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいときに、（たとえば、ＤＭＭコーディングモードが深度予測ユニットに使用されないことを示すために）ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが１に等しくなることを指定する制限を満たす符号化ビットストリームを復号する技法を使用することができる。
[0057]さらなる例として、ビデオデコーダは、対応する深度予測ユニットがＤＭＭに従ってコーディングされるかどうかに基づいて、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを選択的に復号する技法を使用することができる。追加の例として、ビデオデコーダは、対応する深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいかどうかに基づいて、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを選択的に復号する技法を使用することができる。いくつかの例では、上述の技法のうちの１つまたは複数は、変換ユニットおよび／または変換木が細分されるのを、そのような細分が深度モデリングモード（ＤＭＭ）に従った深度予測ユニットのイントラコーディングに干渉することになる場合に防ぎ得る。
[0058]本開示に関するビデオコーディング規格およびＨＥＶＣ技法がここで概観される。ビデオコーディング規格の例としては、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌ、および、スケーラブルビデオコーディング（ＳＶＣ）拡張とマルチビュービデオコーディング（ＭＶＣ）拡張とを含む（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても知られる）ＩＴＵ−Ｔ Ｈ．２６４がある。ＭＶＣの最新のジョイントドラフトは、「Advanced video coding for generic audiovisual services」、ＩＴＵ−Ｔ勧告Ｈ．２６４、２０１０年３月に記載されている。
[0059]さらに、ＩＴＵ−Ｔ Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＶＣＥＧ）とＩＳＯ／ＩＥＣ Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）とのＪｏｉｎｔ Ｃｏｌｌａｂｏｒａｔｉｏｎ Ｔｅａｍ ｏｎ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＪＣＴ−ＶＣ）によって開発された新しいビデオコーディング規格、すなわち、高効率ビデオコーディング（ＨＥＶＣ）がある。ＨＥＶＣ規格の最近のドラフト、ＪＣＴＶＣ−Ｌ１００３、Benjamin Bross, Woo-Jin Han, Jens-Ranier Ohm, Gary Sullivan, Ye-Kui Wang, Thomas Wiegand、「High Efficiency Video Coding (HEVC) text specification draft 10 (for FDIS & Last Call)」、ＩＴＵ−Ｔ ＳＧ １６ ＷＰ ３とＩＳＯ／ＩＥＣ ＪＴＣ １／ＳＣ ２９／ＷＧ １１とのＪｏｉｎｔ Ｃｏｌｌａｂｏｒａｔｉｖｅ Ｔｅａｍ ｏｎ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＪＣＴ−ＶＣ）、第１２回会合：ジュネーブ、スイス、２０１３年１月１４〜２３日（「ＨＥＶＣ ＷＤ１０」または代替的に「ＨＥＶＣ」）が、参照によって全体が本明細書に組み込まれ、以下のリンクから入手可能である。
http://phenix.it-sudparis.eu/jct/doc_end_user/documents/12_Geneva/wg11/JCTVC-L1003-v34.zip
[0060]図１は、ＨＥＶＣにおいて使用されるイントラ予測モードを示す図である。ＨＥＶＣによって定義され、図１に示されるイントラ予測モードは、特に、３Ｄ−ＨＥＶＣのようなＨＥＶＣ拡張におけるそのようなイントラ予測モードの使用に関係して、正規ＨＥＶＣイントラ予測モードと呼ばれることがあり、そのようなＨＥＶＣ拡張では、そのような正規ＨＥＶＣイントラ予測モードならびにＤＭＭモードおよびＳＤＣモードのような他のイントラ予測モードが使用され得る。
[0061]図１は一般に、ＨＥＶＣにおけるイントラコーディングに利用可能な様々な方向性イントラ予測モードに関連付けられる予測方向を示す。現在のＨＥＶＣでは、たとえば、ＨＥＶＣ ＷＤ１０において説明されているように、各予測ユニット（ＰＵ）のルーマ成分のために、図１に示されるように、（２から３４までインデックス付けされた）３３個の方向性（directional）（角度（angular））予測モードと、（１とインデックス付けされた）ＤＣモードと、（０とインデックス付けされた）平面（Planar）モードとを有するイントラ予測方法が利用される。
[0062]（０とインデックス付けされた）平面モードでは、ビデオデータのブロック、たとえばＰＵ内のピクセルの各々に対する予測子値を決定するために、いわゆる「平面（plane）」関数を使用して予測が実行される。（１とインデックス付けされた）ＤＣモードによれば、ブロック内のピクセルの各々に対する予測子値を決定するために、ブロック内のピクセル値の平均を使用して予測が実行される。方向性予測モードによれば、（そのモードによって示される）特定の方向に沿った隣接ブロックの再構築されたピクセルに基づいて予測が実行される。概して、図１に示されている矢印の各々の末端は、１つまたは複数の値がそこから取り出される１つまたは複数の隣接ピクセルの相対的なセットを表し、矢印の各々のヘッドは、予測ブロックを形成するために取り出された値（または取り出された値の組合せ）が伝搬される方向を表す。
[0063]ＨＥＶＣイントラ予測モードでは、ビデオエンコーダおよび／またはビデオデコーダは、たとえば、モード２から３４に対するＰＵの隣接サンプルを使用することによって、上で論じられた様々なモードを使用してＰＵ中の各ピクセルのためのピクセル固有の予測子値を生成する。ビデオエンコーダは、ブロックのピクセルのための実際の深度値と予測子値との間の差分に基づいてビデオブロックのための残差値を決定し、残差値をビデオデコーダに提供する。
[0064]ＨＥＶＣ ＷＤ１０によれば、ビデオエンコーダは、残差値を変換して変換係数を生成し、変換係数を量子化する。ビデオエンコーダはまた、量子化変換係数をエントロピー符号化し得る。ビデオデコーダは、（たとえば、エントロピー復号、逆量子化、および逆変換の後で）残差値を予測子値に加算することによって、ブロックのピクセルに関して再構成された値を決定する。ＨＥＶＣイントラ予測モードに関するさらなる詳細が、ＨＥＶＣ ＷＤ１０において指定されている。
[0065]ＨＥＶＣにおいて使用されるコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）解析処理を含む、ＨＥＶＣにおいて使用され得るエントロピーコーディング処理がここで説明される。ＣＡＢＡＣコーディング処理のための主要ステップは、以下を含む。
１．バイナリ化
２．コンテキストモデリング
３．バイナリ算術コーディング
[0066]バイナリ化のために、ＣＡＢＡＣエントロピーコーダは、非バイナリ値のシンタックス要素を、ビン列と呼ばれるバイナリシーケンスにマッピングする。シンタックス要素がすでにバイナリ値である場合、バイナリ化は必要ではなく、回避され得る。ビン列における各ビンは二者択一を表す。次いでＣＡＢＡＣエントロピーコーダは、コンテキストモデルが選択されるＣＡＢＡＣコーダの正規コーディングエンジン、またはコンテキストモデル選択が必要とされないＣＡＢＡＣコーダのバイパスコーディングエンジンのいずれかを使用して、ビン列における各ビンをコーディングする。
[0067]正規（すなわち、コンテキスト適応型）コーディングモードでは、ＣＡＢＡＣエントロピーコーダは、各ビンに対する算術コーディング処理の前にコンテキストモデリングを実行するコンテキストモデラを含む。ＣＡＢＡＣエントロピーコーダの正規コーディングエンジンは、コンテキストモデリングを実行し、それによって、各ビンに対して確率モデルが選択される。以前コーディングされたバイナリシンタックス要素またはシンタックス要素のビンにコンテキスト選択が依拠するように、ＣＡＢＡＣエントロピーコーダにおいて確率モデルが選択され得る。
[0068]コンテキストモデル選択の後、ＣＡＢＡＣエントロピーコーダの正規コーディングエンジンは、ビンと、ビンに対して選択された確率モデルとを受信する。次いでＣＡＢＡＣ正規コーディングエンジンは、コンテキストモデルを使用して関連ビンにバイナリ算術コーディングを適用し、その後、コンテキストモデルを更新する。特に、コンテキストモデルを更新するために、コンテキストモデラにビン値が返され得る。ＣＡＢＡＣ符号化／復号（一般にコーディングと呼ばれ、コーディングは符号化または復号を備え得る）を開始する前に、エントロピーコーディング（たとえば、エントロピー符号化または復号）ユニットは、各コンテキストに初期化確率状態を割り当てる。
[0069]コンテキスト適応型コーディングの代替として、エントロピーコーダは、選択されたビンをエントロピーコーディングするためにバイパスコーディングモードを選択する。ＣＡＢＡＣエントロピーコーダのバイパスコーディングエンジンは、ビンをコーディングするために、明示的に割り当てられたコンテキストモデルを使用せずに、簡易算術コーダを使用する。バイパスコーディングエンジンは、コンテキスト適応型ではない。すなわち、バイパスコーディングエンジンでは、コンテキストモデルから取得された推定確率を使用してビンがコンテキストコーディングされることはない。代わりに、バイパスコード化ビンが固定確率モデルによりコーディングされ得る。
[0070]たとえば、バイパスコーディングエンジンは、０．５の等しい確率を仮定することができ、コーディングのためのコンテキストの選択を必要としない。したがって、コンテキストモデルを使用する正規バイナリ算術コーディングエンジンを使用してコーディングされる（すなわち、正規コーディングエンジンにおいてコンテキストコーディングされる）ビンもあれば、コンテキストモデルを使用せずにバイパスコーディングを使用してコーディングされる（すなわち、バイパスコーディングエンジンにおいてバイパスコーディングされる）ビンもある。
[0071]適用可能な場合、ＣＡＢＡＣエントロピーエンコーダの正規コーディングエンジンまたはバイパスコーディングエンジンは、ビットストリームを形成するコード化ビットを生成するために、シンタックス要素に関するビンを算術コーディングする。適用可能な場合、ＣＡＢＡＣエントロピーデコーダの正規コーディングエンジンまたはバイパスコーディングエンジンは、ビンを生成するためにビットストリーム中のビットを復号し、シンタックス要素を生成するために１つまたは複数のビンを復号する。いくつかの例では、バイパスコーディングは、スループットの増大をもたらすことができ、同じサイクルにおいて複数のビンがコーディングされることを可能にし得る。したがって、ＣＡＢＡＣバイパスコーディングエンジンの使用は、計算スループットの増大のために望ましいものであり得、ＣＡＢＡＣ正規コーディングエンジンの使用は、高いコーディング効率のために望ましいものであり得る。
[0072]ＪＣＴ−３Ｖでは、マルチビュー拡張（ＭＶ−ＨＥＶＣ）および３Ｄビデオ拡張（３Ｄ−ＨＥＶＣ）という２つのＨＥＶＣ拡張が開発されている。参照ソフトウェアの最近のバージョン、３Ｄ−ＨＥＶＣのための「３Ｄ−ＨＴＭ ｖｅｒｓｉｏｎ １０．０ｒｃ１」が、参照によって全体が本明細書に組み込まれ、以下のリンクからダウンロード可能である。
[3D-HTM version 10.0rc1]:
https://hevc.hhi.fraunhofer.de/svn/svn_3DVCSoftware/tags/HTM-10.0rc1/
[0073]３Ｄ−ＨＥＶＣの最近のワーキングドラフトは、ＪＣＴＶＣ−Ｇ１００１、Gerhard Tech, Krzysztof Wegner, Ying ChenおよびSehoon Yea、「3D-HEVC Draft Text 3」、ITU-T SG 16 WP 3とISO/IEC JTC 1/SC 29/WG 11とのJoint Collaborative Team on 3D Video Coding Extension Development、第６回会合：ジュネーブ、スイス、２０１３年１０月２５日〜１１月１日（以下では「Ｇ１００１」または「３Ｄ−ＨＥＶＣ ＷＤ」と呼ばれる）において提示され、参照によって全体が本明細書に組み込まれ、以下のリンクから入手可能である。
http://phenix.it-sudparis.eu/jct2/doc_end_user/documents/7_San%20Jose/wg11/JCT3V-G1001-v1.zip
[0074]３Ｄ−ＨＥＶＣでは、上で参照された３Ｄ−ＨＥＶＣ ＷＤにおいて定義されるように、各アクセスユニットは複数のピクチャを含み、各ビュー中のピクチャの各々は、固有のビュー識別情報（ｉｄ）またはビュー順序インデックスを有する。しかしながら、同じビューの深度ピクチャおよびテクスチャピクチャは、異なるレイヤｉｄを有することがある。
[0075]３Ｄビデオコーディングにおける深度コーディングがここで説明される。３Ｄビデオデータは、キャプチャされたビュー（テクスチャ）が対応する深度マップに関連付けられる、マルチビュービデオプラス深度フォーマットを使用して表される。３Ｄビデオコーディングでは、テクスチャおよび深度マップはコーディングされ、３Ｄビデオビットストリーム中に多重化される。深度マップはグレースケールビデオとしてコーディングされ、ここで、ルーマサンプルは深度値を表し、従来のイントラコーディングおよびインターコーディング方法が深度マップコーディングのために適用され得る。
[0076]深度マップは、鋭いエッジおよび一定のエリアによって特徴付けられ得る。深度マップのサンプルの異なる統計値により、様々なコーディング方式が、２Ｄビデオコーデックに基づく深度マップのために設計されている。マルチビュープラス深度コーディング処理では、ビューはテクスチャ成分と深度成分とを含み得る。深度成分における深度コーディングユニット（ＣＵ）がインターコーティングまたはイントラコーディングされ得る。深度ＣＵは、１つまたは複数のＰＵに分割され得、ＰＵは、１つまたは複数の区分に分割され得る。３Ｄ−ＨＥＶＣでは、イントラ予測モードの、ＨＥＶＣの場合と同じ定義が利用される。深度モデリングモード（ＤＭＭ）が、３Ｄ−ＨＥＶＣにおいて、深度スライスのイントラ予測ユニットをコーディングするためにＨＥＶＣイントラ予測モードとともに導入される。
[0077]図２は、本開示で説明される制限付き深度イントラコーディング技法および／または制限付きＤＭＭコーディング技法のような、本開示の様々な技法を利用するように構成され得る例示的なビデオ符号化および復号システム１０を示すブロック図である。図２に示されるように、システム１０は、宛先デバイス１４によって後で復号されるべき符号化ビデオデータを提供するソースデバイス１２を含む。具体的には、ソースデバイス１２は、コンピュータ可読媒体１６を介して宛先デバイス１４にビデオデータを提供する。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信に関する機能を備え得る。
[0078]宛先デバイス１４は、コンピュータ可読媒体１６を介して復号されるべき符号化ビデオデータを受信することができる。コンピュータ可読媒体１６は、ソースデバイス１２から宛先デバイス１４に符号化ビデオデータを移動することが可能な、任意のタイプの媒体またはデバイスを備え得る。一例では、コンピュータ可読媒体１６は、ソースデバイス１２が符号化ビデオデータを宛先デバイス１４にリアルタイムに直接送信することを可能にするために、送信チャネルなどの通信媒体を備え得る。
[0079]符号化ビデオデータは、ワイヤレス通信プロトコルのような通信規格に従って変調され、宛先デバイス１４に送信され得る。通信媒体は、無線周波（ＲＦ）スペクトルまたは１つもしくは複数の物理伝送線路などの、任意のワイヤレスまたはワイヤード通信媒体を備える場合がある。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどの、パケットベースのネットワークの一部を形成することができる。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス１２から宛先デバイス１４への通信を容易にするために有用であり得る任意の他の機器を含み得る。
[0080]いくつかの例では、符号化データは、出力インターフェース２２から、非一時的コンピュータ可読記憶媒体などのコンピュータ可読記憶媒体、すなわちデータストレージデバイスに出力され得る。同様に、符号化データは、ストレージデバイスから入力インターフェースによってアクセスされ得る。ストレージデバイスは、ハードドライブ、ブルーレイ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性もしくは不揮発性メモリ、または符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体のような、種々の分散されたまたはローカルにアクセスされる非一時的データ記憶媒体のいずれかを含み得る。さらなる例では、ストレージデバイスは、ソースデバイス１２によって生成された符号化ビデオを記憶することができる、ファイルサーバまたは別の中間ストレージデバイスに対応する場合がある。
[0081]宛先デバイス１４は、ストリーミングまたはダウンロードを介して、ストレージデバイスから記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶することができ、その符号化ビデオデータを宛先デバイス１４に送信することができる、任意のタイプのサーバであり得る。例示的なファイルサーバには、（たとえば、ウェブサイト用の）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続ストレージ（ＮＡＳ）デバイス、またはローカルディスクドライブがある。宛先デバイス１４は、インターネット接続を含む、任意の標準のデータ接続を通して、符号化ビデオデータにアクセスすることができる。これは、ワイヤレスチャネル（たとえば、Ｗｉ−Ｆｉ（登録商標）接続）、ワイヤード接続（たとえば、ＤＳＬ、ケーブルモデムなど）、またはファイルサーバに記憶された符号化ビデオデータにアクセスするために好適である両方の組合せを含み得る。ストレージデバイスからの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。
[0082]本開示の技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されたデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例などの、様々なワイヤードまたはワイヤレスマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオ放送、および／またはビデオ電話などの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
[0083]図２の例では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、出力インターフェース２２とを含む。宛先デバイス１４は、入力インターフェース２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。本開示によれば、ソースデバイス１２のビデオエンコーダ２０は、３Ｄ−ＨＥＶＣのような３Ｄビデオコーディング処理における深度イントラコーディングおよび／またはＤＭＭコーディングを制限するための技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または配置を含み得る。たとえば、ソースデバイス１２は、外部カメラなどの外部のビデオソース１８からビデオデータを受信し得る。同様に、宛先デバイス１４は、集積ディスプレイデバイスを含むのではなく、外部のディスプレイデバイスとインターフェースし得る。
[0084]図２の示されるシステム１０は一例にすぎない。本開示で説明される技法は、デジタルビデオ符号化および／または復号デバイスによって実行される場合がある。一般に、本開示の技法は、ビデオエンコーダ２０／ビデオデコーダ３０によって実行されるが、技法は、通常「コーデック」と呼ばれるビデオエンコーダ／デコーダによって実行されてもよい。その上、本開示の技法は、ビデオプリプロセッサによって実行されてもよい。ソースデバイス１２および宛先デバイス１４は、宛先デバイス１４に送信するためのコード化ビデオデータをソースデバイス１２が生成するコーディングデバイスの例にすぎない。いくつかの例では、デバイス１２、１４は、デバイス１２、１４の各々がビデオ符号化構成要素とビデオ復号構成要素とを含むように、実質的に対称の形で動作することができる。したがって、システム１０は、たとえば、ビデオストリーミング、ビデオ再生、ビデオ放送、またはビデオ電話のための、ビデオデバイス１２、１４の間の一方向または双方向のビデオ送信をサポートすることができる。
[0085]ソースデバイス１２のビデオソース１８は、ビデオカメラ、以前キャプチャされたビデオを含むビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオを受信するビデオフィードインターフェースなどの、ビデオキャプチャデバイスを含む場合がある。さらなる代替として、ビデオソース１８は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオ、アーカイブビデオ、およびコンピュータ生成ビデオの組合せを生成することができる。場合によっては、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、いわゆるスマートフォン、タブレットコンピュータ、またはビデオ電話を形成し得る。しかしながら、上で言及されたように、本開示で説明される技法は、ビデオコーディング全般に適用可能であってよく、ワイヤレス適用例および／またはワイヤード適用例に適用され得る。各々の場合において、キャプチャされたビデオ、事前にキャプチャされたビデオ、またはコンピュータ生成ビデオは、ビデオエンコーダ２０によって符号化され得る。符号化されたビデオ情報は次いで、出力インターフェース２２によってコンピュータ可読媒体１６上に出力され得る。
[0086]コンピュータ可読媒体１６は、ワイヤレスブロードキャストもしくはワイヤードネットワーク送信のような一時的媒体、またはデータ記憶媒体（すなわち、非一時的記憶媒体）を含み得る。いくつかの例では、ネットワークサーバ（図示されず）は、ソースデバイス１２から符号化ビデオデータを受信し、たとえば、ネットワーク送信を介して、その符号化ビデオデータを宛先デバイス１４に提供することができる。同様に、ディスクスタンピング設備のような、媒体製造設備のコンピューティングデバイスは、ソースデバイス１２から符号化ビデオデータを受信し、その符号化ビデオデータを含むディスクを生成することができる。したがって、様々な例では、コンピュータ可読媒体１６は、様々な形態の１つまたは複数のコンピュータ可読媒体を含むと理解され得る。
[0087]本開示は、一般に、ビデオエンコーダ２０が、ビデオデコーダ３０などの別のデバイスにある情報を「シグナリング」することに言及する場合がある。しかしながら、ビデオエンコーダ２０は、いくつかのシンタックス要素をビデオデータの様々な符号化部分に関連付けることによって情報をシグナリングできることを理解されたい。すなわち、ビデオエンコーダ２０は、ビデオデータの様々な符号化部分のヘッダまたはペイロードにいくつかのシンタックス要素を格納することによって、データを「シグナリング」することができる。場合によっては、そのようなシンタックス要素は、ビデオデコーダ３０によって受信および復号されるより前に、符号化および記憶（たとえば、コンピュータ可読媒体１６に記憶）される場合がある。したがって、「シグナリング」という用語は全般に、圧縮されたビデオデータを復号するためのシンタックスまたは他のデータの通信を、そのような通信がリアルタイムで発生するか、もしくはほぼリアルタイムで発生するか、またはある期間にわたって発生するかにかかわらず指すことがあり、ある期間にわたる通信は、シンタックス要素を符号化の時点で媒体に記憶し、次いで、シンタックス要素がこの媒体に記憶された後の任意の時点で復号デバイスによって取り出され得るときに、発生し得る。
[0088]いくつかの例では、シンタックス要素が、ビットストリームにそのシンタックス要素を含めることによってシグナリングされ得る。さらなる例では、シンタックス要素が、ビットストリームにそのシンタックス要素を含めることによってではなく、ビットストリームに他のシンタックス要素を含める（元のシンタックス要素の値がビットストリームから推測され得る）ことによってシグナリングされ得る。
[0089]宛先デバイス１４の入力インターフェース２８は、コンピュータ可読媒体１６から情報を受信する。コンピュータ可読媒体１６の情報は、ブロックおよび他のコード化ユニット、たとえば、ＧＯＰの特性および／または処理を記述するシンタックス要素を含む、ビデオエンコーダ２０によって定義されビデオデコーダ３０によっても使用される、シンタックス情報を含み得る。ディスプレイデバイス３２は、ユーザに復号ビデオデータを表示し、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、投影デバイス、または別のタイプのディスプレイデバイスなどの、様々なディスプレイデバイスのいずれかを備える場合がある。
[0090]図２には示されていないが、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は、それぞれ、オーディオエンコーダおよびオーディオデコーダと統合される場合があり、共通のデータストリームまたは別々のデータストリーム内のオーディオとビデオの両方の符号化を処理するために、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアおよびソフトウェアを含む場合がある。適用可能な場合、ＭＵＸ−ＤＥＭＵＸユニットは、一例として、ＩＴＵ Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠することができる。
[0091]ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、適用可能な場合、１つまたは複数のプロセッサのような、種々の好適なエンコーダまたはデコーダ回路のいずれかとして実装され得る。様々なプロセッサの例としては、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せを伴い得る、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理回路がある。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれもが複合ビデオエンコーダ／デコーダ（コーデック）の一部として組み込まれ得る。ビデオエンコーダ２０および／またはビデオデコーダ３０を含むデバイスは、集積回路、マイクロプロセッサ、および／または携帯電話のようなワイヤレス通信デバイスを備え得る。
[0092]ビデオエンコーダ２０およびビデオデコーダ３０は、ＨＥＶＣ規格のようなビデオコーディング規格、およびより具体的には、たとえば、３Ｄ−ＨＥＶＣ ＷＤによる、本開示で参照されるようなＨＥＶＣ規格の３Ｄ−ＨＥＶＣ拡張に従って動作することができる。ＨＥＶＣは、たとえば、ＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣなどの他の処理に従ってコーディングを実行するように構成されるデバイスと比較して、ビデオコーディングデバイスのいくつかの追加能力を仮定する。たとえば、Ｈ．２６４は９個のイントラ予測符号化モードを提供するが、図１に示され、図１を参照しながら上記で説明したように、ＨＭは３５個ものイントラ予測符号化モードを提供することができる。
[0093]ＨＥＶＣのいくつかの基本的態様がここで論じられる。一般に、ＨＥＶＣは、ビデオピクチャ（または「フレーム」）が、コーディングツリーユニット（ＣＴＵ）と呼ばれる一連の最大コーディングユニット（ＬＣＵ）に分割され得ることを指定する。ＣＴＵは、対応するルーマ成分およびクロマ成分を含み、これらはコード化ツリーブロック（ＣＴＢ）、たとえば、それぞれ、ルーマＣＴＢおよびクロマＣＴＢと呼ばれ、ルーマサンプルおよびクロマサンプルを含む。ビットストリーム内のシンタックスデータは、ＣＴＵにとってのサイズを定義し得、ＣＴＵは、ピクセルの個数に関して最大のコーディングユニットである。スライスは、ピクチャのコード化部分であってよく、コーディング順序で、いくつかの連続するＣＴＢを含み得る。ピクチャは、１つまたは複数のスライスに区分され得る。各ＣＴＵは、４分木区分構造に従ってコーディングユニット（ＣＵ）に分割され得る。一般に、４分木データ構造は、ＣＵあたり１つのノードを含み、ルートノードがＣＴＢに対応する。ＣＵが４つのサブＣＵに分割される場合、ＣＵに対応するノードは４つのリーフノードを含み、リーフノードの各々はサブＣＵのうちの１つに対応する。
[0094]４分木データ構造の各ノードは、対応するＣＵに関するシンタックスデータを提供し得る。たとえば、４分木中のノードは、そのノードに対応するＣＵがサブＣＵに分割されるのかどうかを示す分割フラグを含むことができる。ＣＵに関するシンタックス要素は、再帰的に定義される場合があり、ＣＵがサブＣＵに分割されるかどうかに依存する場合がある。ＣＵがさらに分割されない場合、そのＣＵはリーフＣＵと呼ばれる。リーフＣＵの４つのサブＣＵは、元のリーフＣＵの明示的な分割がない場合でも、リーフＣＵと呼ばれる場合もある。たとえば、１６×１６サイズのＣＵがさらに分割されない場合、この１６×１６ＣＵが決して分割されなくても、４つの８×８サブＣＵはリーフＣＵとも呼ばれる。
[0095]ＨＥＶＣにおけるＣＵは、ＣＵがサイズの差異を有しないことを除いて、Ｈ．２６４規格のマクロブロックと同様の目的を有する。たとえば、ＣＴＢは、（サブＣＵとも呼ばれる）４つの子ノードに分割され得、各子ノードは、今度は親ノードとなり、別の４つの子ノードに分割され得る。４分木のリーフノードと呼ばれる、最後の分割されない子ノードは、リーフＣＵとも呼ばれるコーディングノードを備える。コード化ビットストリームに関連付けられるシンタックスデータは、最大ＣＵ深度と呼ばれる、ＣＴＢが分割され得る最大回数を定義することができ、コーディングノードの最小サイズも定義することができる。したがって、いくつかの例では、ビットストリームは、最小コーディングユニットを定義することもできる。
[0096]ＣＵは、コーディングノードと、コーディングノードに関連付けられる予測ユニット（ＰＵ）および変換ユニット（ＴＵ）とを含む。本開示は、ＨＥＶＣのコンテキストでは、ＣＵ、予測ユニット（ＰＵ）、変換ユニット（ＴＵ）、コーディングブロック、予測ブロック、変換ブロック、もしくはそれらの区分のいずれか、または他の規格のコンテキストでは、同様のデータ構造を指すために、「ブロック」という用語を使用する場合がある。ＣＵのサイズはコーディングノードのサイズに対応する。ＣＵのサイズは、８×８ピクセルから最大６４×６４ピクセル以上のＣＴＢのサイズまで及ぶ場合がある。各ＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含み得る。ＣＵに関連付けられるシンタックスデータは、たとえば、ＣＵの１つまたは複数のＰＵへの区分を記述し得る。区分モードは、ＣＵが、スキップモード符号化もしくはダイレクトモード符号化されるのか、イントラ予測モード符号化されるのか、またはインター予測モード符号化されるのかによって異なり得る。本開示で説明される深度コーディングの場合、ＰＵは、形状が非正方形となるように区分され、または、形状が非長方形である区分を含み得る。ＣＵに関連付けられるシンタックスデータは、たとえば、４分木に従う１つまたは複数のＴＵへのＣＵの区分を記述することもできる。ＴＵは、形状が正方形または非正方形（たとえば、長方形）であってよい。
[0097]ＨＥＶＣ規格は、ＣＵごとに異なり得る、ＴＵに従った変換を可能にする。ＴＵは通常、区分されたＣＴＢについて定義される所与のＣＵ内のＰＵのサイズに基づいてサイズ決定されるが、必ずそうなっているとは限らない。ＴＵは、一般に、ＰＵ以下のサイズである。いくつかの例では、ＣＵに対応する残差サンプルは、「残差４分木」（ＲＱＴ）として知られている４分木構造を使用して、より小さいユニットに細分され得る。ＲＱＴのリーフノードは、変換ユニット（ＴＵ）と呼ばれ得る。ＴＵに関連付けられるピクセル差分値は、変換係数を生成するために変換されてよく、変換係数は量子化され得る。
[0098]リーフＣＵは、１つまたは複数の予測ユニット（ＰＵ）を含むことができる。一般に、ＰＵは、対応するＣＵのすべてまたは一部分に対応する空間エリアを表し、そのＰＵの参照サンプルを取り出すためのデータを含み得る。参照サンプルは、参照ブロックからのピクセルであり得る。いくつかの例では、参照サンプルは、たとえば、補間または他の技法によって、参照ブロックから取得されるか、または生成される場合がある。ＰＵはまた、予測に関するデータを含む。たとえば、ＰＵがイントラモード符号化されるとき、ＰＵ用のデータは、残差４分木（ＲＱＴ）に含まれる場合があり、ＲＱＴは、ＰＵに対応するＴＵ用のイントラ予測モードを記述するデータを含む場合がある。
[0099]別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵ用の１つまたは複数の動きベクトルを定義するデータを含む場合がある。ＰＵ用の動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（たとえば、１／４ピクセル精度もしくは１／８ピクセル精度）、動きベクトルが指す参照ピクチャ、および／または動きベクトル用の参照ピクチャリスト（たとえば、ＲｅｆＰｉｃＬｉｓｔ０、ＲｅｆＰｉｃＬｉｓｔ１）を記述することができる。
[0100]１つまたは複数のＰＵを有するリーフＣＵは、１つまたは複数の変換ユニット（ＴＵ）をも含み得る。変換ユニットは、上で論じられたように、ＲＱＴ（ＴＵ４分木構造とも呼ばれる）を使用して指定され得る。たとえば、分割フラグは、リーフＣＵが４つの変換ユニットに分割されるかどうかを示し得る。その場合に、各変換ユニットは、さらなるサブＴＵにさらに分割され得る。ＴＵがさらに分割されないとき、それはリーフＴＵと呼ばれることがある。いくつかの例では、イントラコーディングの場合、リーフＣＵに属するすべてのリーフＴＵは、同じイントラ予測モードを共有する。そのような例では、一般に、リーフＣＵのすべてのＴＵの予測値を計算するために、同じイントラ予測モードが適用される。イントラコーディングの場合、ビデオエンコーダ２０は、イントラ予測モードを使用して、リーフＴＵごとの残差値を、ＴＵに対応するＣＵの部分と元のブロックとの間の差分として計算することができる。ＴＵは、必ずしもＰＵのサイズに限定されるとは限らない。したがって、ＴＵは、ＰＵよりも大きい場合もあり、小さい場合もある。イントラコーディングの場合、ＰＵは、同じＣＵ用の対応するリーフＴＵと併置される場合がある。いくつかの例では、リーフＴＵの最大サイズは、対応するリーフＣＵのサイズに対応する場合がある。
[0101]その上、リーフＣＵのＴＵは、残差４分木（ＲＱＴ）と呼ばれる、それぞれの４分木データ構造にも関連付けられ得る。すなわち、リーフＣＵは、そのリーフＣＵがＴＵにどのように区分されるのかを示す４分木を含むことができる。ＴＵ４分木のルートノードは概してリーフＣＵに対応し、ＣＵ４分木のルートノードは概してＣＴＢに対応する。分割されないＲＱＴのＴＵは、リーフＴＵと呼ばれる。一般に、本開示は、別段に記載されていない限り、それぞれ、リーフＣＵおよびリーフＴＵを指すために、ＣＵおよびＴＵという用語を使用する。
[0102]ビデオシーケンスは通常、一連のピクチャを含む。本明細書で説明されるように、「ピクチャ」と「フレーム」は互換的に使用され得る。すなわち、ビデオデータを含んでいるピクチャは、ビデオフレームまたは単に「フレーム」と呼ばれ得る。ピクチャグループ（ＧＯＰ）は一般に、一連の１つまたは複数のビデオピクチャを備える。ＧＯＰは、ＧＯＰのヘッダ中、ピクチャの１つもしくは複数のヘッダ中、または他のところに、そのＧＯＰに含まれるピクチャの数を記述するシンタックスデータを含み得る。ピクチャの各スライスは、それぞれのスライスに関する符号化モードを記述するスライスシンタックスデータを含む場合がある。ビデオエンコーダ２０は、一般に、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに作用する。ビデオブロックはＣＵ内のコーディングノードに対応する場合がある。ビデオブロックは、固定サイズまたは可変サイズを有することができ、指定されたコーディング規格に従ってサイズが異なり得る。
[0103]一例として、ＨＥＶＣは、様々なＰＵサイズにおける予測をサポートする。特定のＣＵのサイズが２Ｎｘ２Ｎであると仮定すると、ＨＥＶＣは、２Ｎｘ２ＮまたはＮｘＮのＰＵサイズにおけるイントラ予測と、２Ｎｘ２Ｎ、２ＮｘＮ、Ｎｘ２Ｎ、またはＮｘＮという対称なＰＵサイズにおけるインター予測とをサポートする。２Ｎｘ２Ｎのサイズを有するＰＵは、それが存在するＣＵと同じサイズであるので、分割されないＣＵを表す。言い換えれば、２Ｎｘ２ＮのＰＵは、そのＣＵと同じサイズである。ＨＥＶＣは、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズにおけるインター予測のための非対称区分をサポートする。非対称区分では、ＣＵの一方の方向は区分されず、他方の方向は、２５％と７５％に区分される。２５％区分に対応するＣＵの部分は、「ｎ」とそれに続く「Ｕｐ」、「Ｄｏｗｎ」、「Ｌｅｆｔ」、または「Ｒｉｇｈｔ」の指示によって示される。したがって、たとえば、「２Ｎ×ｎＵ」は、上部の２Ｎ×０．５ＮのＰＵおよび下部の２Ｎ×１．５ＮのＰＵを用いて水平に区分される２Ｎ×２ＮのＣＵを指す。深度コーディングの場合、３Ｄ−ＨＥＶＣ ＷＤはさらに、説明されるように、非長方形区分を含む、深度モデリングモード（ＤＭＭ）に従ったＰＵの区分をサポートする。
[0104]本開示では、「Ｎ×Ｎ（NxN）」および「Ｎ×Ｎ（N by N）」は、垂直寸法および水平寸法の観点からビデオブロックのピクセル寸法、たとえば、１６×１６（16x16）ピクセルまたは１６×１６（16 by 16）ピクセルを指すために互換的に使用される場合がある。一般に、１６ｘ１６ブロックは、垂直方向に１６ピクセル（ｙ＝１６）、水平方向に１６ピクセル（ｘ＝１６）を有する。同様に、Ｎ×Ｎブロックは、一般に、垂直方向にＮピクセル、水平方向にＮピクセルを有し、Ｎは非負整数値を表す。ブロック内のピクセルは、行および列に配置される場合がある。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要があるとは限らない。たとえば、ブロックはＮ×Ｍピクセルを備え得、ここで、Ｍは必ずしもＮに等しいとは限らない。
[0105]ＨＥＶＣにおけるＣＵ構造に関するさらなる詳細がここで説明される。ＨＥＶＣでは、スライス中の最大コーディングユニットはコーディングツリーブロック（ＣＴＢ）と呼ばれる。ＣＴＢは４分木を含んでおり、そのノードはコーディングユニットである。
[0106]（８×８ＣＴＢサイズがサポートされ得るが）ＣＴＢのサイズは、ＨＥＶＣメインプロファイルにおいて１６×１６から６４×６４に及び得る。コーディングユニット（ＣＵ）は、ＣＴＢのサイズと同じサイズであることがあり、わずか８×８であることもある。各コーディングユニットは、いくつかの例では、１つのモードによりコーディングされ得る。ＣＵがインターコーディングされるときには、ＣＵはさらに、２個または４個の予測ユニット（ＰＵ）に区分され得、または区分が適用されない場合、ＣＵは１つのＰＵに対応し得る。１つのＣＵに２つのＰＵが存在するときには、それらは半分のサイズの長方形またはＣＵの１／４もしくは３／４のサイズを有する２つの長方形サイズであり得る。
[0107]ＣＵがインターコーディングされるとき、ＰＵごとに１つの動き情報セットが存在する。加えて、動き情報セットを導出するために、各ＰＵは一意のインター予測モードでコーディングされる。
[0108]予測ユニット（ＰＵ）構造に関するさらなる詳細がここで説明される。予測ユニット（ＰＵ）は、同じ予測が適用されるＣＵを区分することによって定義された領域である。一般に、ピクチャ中の実際のオブジェクトの境界に一致する区分を円滑にするために、ＰＵは形の点で正方形になることに限定されない。
[0109]図３は、コーディングユニットを区分する際に使用するための例示的な区分モードを示す概念図である。区分モードに応じて、各ＣＵは、１つ、２つ、または４つのＰＵを含む。図３では、インターコード化ＣＵのＰＵを定義するために使用され得る８つの区分モードが示されている。イントラコード化ＣＵを区分するために、ＰＡＲＴ＿２Ｎ×２Ｎ区分モードおよびＰＡＲＴ＿Ｎ×Ｎ区分モードが使用される。区分モードＰＡＲＴ＿Ｎ×Ｎは、対応するＣＵサイズが最小ＣＵサイズに等しいときだけ可能にされる。
[0110]イントラコード化ＣＵの場合、区分モードは、いくつかの例では、ＰＡＲＴ＿２Ｎ×２Ｎ区分モードおよびＰＡＲＴ＿Ｎ×Ｎに限定され得る。イントラコード化ＣＵを区分することから生じる区分は、予測ユニット（ＰＵ）と呼ばれ得る。たとえば、イントラコード化ＣＵがＰＡＲＴ＿２Ｎ×２Ｎ区分モードに従って区分される場合、イントラコード化ＣＵは、イントラコード化ＣＵと同じサイズを有する１つのＰＵに区分され得る。別の例として、イントラコード化ＣＵがＰＡＲＴ＿Ｎ×Ｎ区分モードに従って区分される場合、イントラコード化ＣＵは、各々がイントラコード化ＣＵのサイズの４分の１である４つのＰＵに区分され得る。
[0111]変換ユニット（ＴＵ）および変換木構造に関するさらなる詳細がここで説明される。各ＣＵは、４分木である１つの変換木に対応し、そのリーフは変換ユニットである。変換ユニット（ＴＵ）は、同じ変換および量子化処理を共有する、ＣＵの４分木区分によって定義された正方形領域である。
[0112]図４は、ＣＵ内の例示的な変換木構造を示す概念図である。図４に示されるように、ＣＵは、変換木構造のルートノード（Ｎ０）に対応する。ルートノード（Ｎ０）変換木構造は、変換木構造の親ノードに対応し、４つの子ノード（Ｎ１、Ｎ２、Ｎ３、Ｎ４）に分割される（たとえば、区分または細分される）。ノードＮ１は４つの子ノード（Ｎ５、Ｎ６、Ｎ７、Ｎ８）に分割され、ノードＮ２は４つの子ノード（Ｎ９、Ｎ１０、Ｎ１１、Ｎ１２）に分割され、ノードＮ４は４つの子ノード（Ｎ１３、Ｎ１４、Ｎ１５、Ｎ１６）に分割され、ノードＮ１１は４つの子ノード（Ｎ１７、Ｎ１８、Ｎ１９、Ｎ２０）に分割される。
[0113]図４の変換木構造におけるノードの各々は、変換木ノードと呼ばれ得る。より小さい変換木ノードにさらに分割されない変換木ノードは、リーフノードと呼ばれ得る。より小さい変換木ノードにさらに分割される変換木ノードは、非リーフノードと呼ばれ得る。変換木構造のリーフノードの各々は、それぞれの変換ユニットに対応し得る。変換ユニットの各々は、ピクチャの１つまたは複数の成分のためのそれぞれの変換ブロック（たとえば、ピクチャの深度ビュー成分のための変換ブロック）に対応し得る。各変換ユニットおよび／または変換ブロックは、ブロックベースの変換が適用され、および／またはブロックベースの量子化が適用される、基本的ブロックユニットに対応し得る。
[0114]図４の例では、ノードＮ３、Ｎ５、Ｎ６、Ｎ７、Ｎ８、Ｎ９、Ｎ１０、Ｎ１２、Ｎ１３、Ｎ１４、Ｎ１５、Ｎ１６、Ｎ１７、Ｎ１８、Ｎ１９、およびＮ２０はリーフノードであり、ノードＮ０、Ｎ１、Ｎ２、Ｎ４、およびＮ１１は非リーフノードである。リーフノードＮ３、Ｎ５、Ｎ６、Ｎ７、Ｎ８、Ｎ９、Ｎ１０、Ｎ１２、Ｎ１３、Ｎ１４、Ｎ１５、Ｎ１６、Ｎ１７、Ｎ１８、Ｎ１９、およびＮ２０の各々は、それぞれの変換ユニットに対応し得る。変換ユニットの各々は、ピクチャの１つまたは複数の成分のためのそれぞれの変換ブロック（たとえば、ピクチャの深度ビュー成分のための変換ブロック）に対応し得る。
[0115]変換木構造のノードが複数のサブノードに分割される場合に、分割されたノードがサブノードに対して親ノードと呼ばれることがあり、サブノードが親ノードに対して子ノードと呼ばれることがある。変換木構造におけるノードの各々は、細分レベル（subdivision level）に対応し得る。親ノードが複数の子ノードに分割される場合、子ノードは、親ノードよりも１レベル大きい細分レベルを有することになる。
[0116]図４の例では、ルートノード（Ｎ０）は０の細分レベル（たとえば、ｔｒａｆｏＤｅｐｔｈ）を有することができ、ノードＮ１、Ｎ２、Ｎ３、およびＮ４は１の細分レベルを有することができる。さらに、ノードＮ５、Ｎ６、Ｎ７、Ｎ８、Ｎ９、Ｎ１０、Ｎ１１、Ｎ１２、Ｎ１３、Ｎ１４、Ｎ１５、およびＮ１６は、２の細分レベルを有することができ、ノードＮ１７、Ｎ１８、Ｎ１９、およびＮ２０は３の細分レベルを有することができる。
[0117]いくつかの例では、変換木ノードの各々に関してシンタックス要素がコーディングされ得る。それぞれの変換木ノードに関するシンタックス要素は、それぞれの変換木ノードが複数のサブ変換木ノード（すなわち、子ノード）に分割されるべきかどうかを示し得る。非リーフノードの各々に関して、対応するシンタックス要素は、非リーフノードが複数のサブ変換木ノードに分割されるべきであることを示し得る。リーフノードの各々に関して、対応するシンタックス要素は、リーフノードが複数のサブ変換木ノードに分割されるべきではないことを示し得る。いくつかの例では、シンタックス要素は、コード化ビットストリームに含まれること、および／またはコード化ビットストリームから推測されることがある。
[0118]ＨＥＶＣおよび３Ｄ−ＨＥＶＣでは、変換木ノードが複数のサブ変換木ノードに分割されるべきかどうかを示すシンタックス要素は、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇシンタックス要素であり得る。１の値を有するｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇは、変換木ノードが複数のサブ変換木ノードに分割されるべきであることを指定する。０の値を有するｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇは、変換木ノードが複数のサブ変換木ノードに分割されるべきではないことを指定する。
[0119]図４の例では、ノードリーフノードＮ３、Ｎ５、Ｎ６、Ｎ７、Ｎ８、Ｎ９、Ｎ１０、Ｎ１２、Ｎ１３、Ｎ１４、Ｎ１５、Ｎ１６、Ｎ１７、Ｎ１８、Ｎ１９、およびＮ２０は、０に等しいｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを有し得る。同様に、非リーフＮ０、Ｎ１、Ｎ２、Ｎ４およびＮ１１は、１に等しいｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを有し得る。
[0120]上記で説明したように、イントラコード化ＣＵは、ＰＡＲＴ＿２Ｎ×２Ｎ区分モードまたはＰＡＲＴ＿Ｎ×Ｎ区分モードに従って１つまたは複数のＰＵに区分され得る。ＣＵがＰＡＲＴ＿２Ｎ×２Ｎ区分モードに従って区分される場合、ＣＵは、ルートノードＮ０と同じサイズを有し、ルートノードＮ０におけるサンプル（たとえば、ピクセル）に対応するサンプルを有する単一のＰＵに区分され得る。
[0121]ＣＵがＰＡＲＴ＿Ｎ×Ｎ区分モードに従って区分される場合、ＣＵは、ノードＮ１、Ｎ２、Ｎ３およびＮ４と同じサイズを有する４つのＰＵに区分され得る。第１のＰＵは、ノードＮ１におけるサンプルに対応するサンプルを有することができ、第２のＰＵは、ノードＮ２におけるサンプルに対応するサンプルを有することができ、第３のＰＵは、ノードＮ３におけるサンプルに対応するサンプルを有することができ、第４のＰＵは、ノードＮ４におけるサンプルに対応するサンプルを有することができる。
[0122]ＣＵ内の複数のＴＵの４分木構造が図４に示されている。図４の例では、ＴＵの形状は、常に正方形であり、３２×３２のサンプルから４×４のサンプルまでのサイズをとり得る。最大変換ブロックサイズおよび４分木の深度は、調整可能であり、シーケンスパラメータセットにおいて指定される。インターＣＵの場合、ＴＵは、ＰＵよりも大きい場合があり、すなわち、ＴＵはＰＵ境界を包含し得る。ただし、ＴＵは、イントラＣＵのＰＵ境界を越えることはない。たとえば、イントラ予測モードでは、ＣＵの区分モードがＰＡＲＴ＿Ｎ×Ｎであるとき、ＣＵの変換木深度（利用可能な場合）は０よりも大きくなるべきである。
[0123]図５は、ＰＡＲＴ＿Ｎ×Ｎ区分モードにより区分されるイントラコード化コーディングユニット内の変換木構造の例を示す概念図である。図５に示されるように、ＣＵは、予測木構造（左側）および変換木構造（右側）に対応することができ、ＣＵは、予測木構造と変換木構造の両方のルートノードに対応する。
[0124]図５の左側に示されるように、ＣＵ（すなわち、予測木構造のルートノード）は４つのノード（すなわち、予測木ノード）に分割され、各ＰＵはノードのうちの１つに対応する。図５の右側に示されるように、ＣＵ（すなわち、変換木構造のルートノード）は、変換ユニットＴＵ０、ＴＵ１、ＴＵ２、ＴＵ３、ＴＵ４、ＴＵ５、ＴＵ６、ＴＵ７、ＴＵ８、ＴＵ９、ＴＵ１０、ＴＵ１１、およびＴＵ１２に分割される。
[0125]いくつかの例では、シンタックス要素ｒｑｔ＿ｒｏｏｔ＿ｃｂｆは、特定のコーディングユニットに関してｔｒａｎｓｆｏｒｍ＿ｔｒｅｅシンタックス構造が存在するかどうかをシグナリングすることができる。たとえば、ｒｑｔ＿ｒｏｏｔ＿ｃｂｆを１に等しく設定することは、現在のコーディングユニットに関してｔｒａｎｓｆｏｒｍ＿ｔｒｅｅシンタックス構造が存在することを指定し、ｒｑｔ＿ｒｏｏｔ＿ｃｂｆを０に等しく設定することは、現在のコーディングユニットに関してｔｒａｎｓｆｏｒｍ＿ｔｒｅｅシンタックス構造が存在しないことを指定する。ｒｑｔ＿ｒｏｏｔ＿ｃｂｆが存在しないとき、その値は１に等しいと推測される。
[0126]ｒｑｔ＿ｒｏｏｔ＿ｃｂｆが０に等しいとき、変換木は、いくつかの例では、１つのノードのみを包含し、つまり、その変換木はさらに分割されず、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇは０に等しい。そのような例では、コーディングユニットに対応する変換ユニットのサイズは、コーディングユニットのサイズに等しくなり得る。さらに、ＣＵに対応するいくつかのノードは変換されないことがある。変換木の中のノードに関して、それが１に等しいｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを有する場合、ノードは、４つのノードにさらに分割される。変換木のリーフは、０に等しいｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを有する。
[0127]簡単にするために、変換ユニットまたは変換木が、変換を有しないブロックに対応する場合、そのような変換ユニットまたは変換木は、変換自体の階層が依然として存在するので、依然として変換木または変換ユニットと考えられ得る。変換スキップされたブロックは、変換ユニットに対応すること、および／または変換ユニットの中にあることがある。
[0128]変換ユニットのｃｂｆがここでさらに詳細に説明される。１に等しい変換ユニットのｃｂｆは、０に等しくない１つまたは複数の変換係数レベルを変換ユニットが含むことを指定する。０に等しい変換ユニットのｃｂｆは、変換ユニットのすべての変換係数レベルが０であることを指定する。ｃｂｆは、変換ユニットの各成分のために設定されることがあり、たとえば、ｃｂｆは、それぞれルーマ成分、ｃｂ成分およびｃｒ成分のために設定される。
[0129]ＴＵレベルにおけるイントラ予測がここでさらに詳細に説明される。図６は、例示的な変換木構造の例示的な変換ユニット処理順序を示す。ＨＥＶＣでは、イントラコード化ＣＵのサンプル予測および再構築は、ＴＵレベルで実行され、ＴＵは、図６に示されるように、復号順序で予測され再構築される。１つのＴＵを再構築した後、それの再構築サンプルが、後続のＴＵを予測するために使用される。ＰＵが複数のＴＵを含んでいるとき、第１のＴＵに関しては、ＰＵの隣接サンプルを使用して予測され、他のＴＵに関しては、ＰＵの隣接サンプルおよび／または先行ＴＵ中の隣接サンプルを使用して予測される。
[0130]正規イントラ予測モードの場合、（３３個の角度イントラ予測モードと、ＤＣモードおよび平面モードとを含む）同じイントラ予測モードが、異なるブロックサイズ、すなわち、４×４、８×８、１６×１６、３２×３２および６４×６４に適用されることに留意されたい。異なるブロックサイズを有する複数のＴＵをＰＵが含んでいるときでも、これらのＴＵは、同じイントラ予測モードを使用して予測され得る。
[0131]ＣＵのＰＵを使用したイントラ予測コーディングまたはインター予測コーディングに続いて、ビデオエンコーダ２０は、ＣＵのＴＵに関する残差データを計算することができる。ＰＵは、（ピクセル領域とも呼ばれる）空間領域において予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備え得、ＴＵは、残差ビデオデータへの変換、たとえば、離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に同様の変換の適用に続く変換領域における係数を備え得る。残差データは、符号化されていないピクチャのピクセルとＰＵに対応する予測値との間のピクセル差分に対応することができる。ビデオエンコーダ２０は、ＣＵに関する残差データを含むＴＵを形成し、次いで、ＣＵに関する変換係数を生成するためにＴＵを変換することができる。
[0132]変換係数を生成するための任意の変換に続いて、ビデオエンコーダ２０は、変換係数の量子化を実行することができる。量子化は一般に、係数を表すために使用されるデータの量をできるだけ低減するために、変換係数が量子化され、さらなる圧縮を実現する処理を指す。量子化処理は、係数の一部またはすべてに関連付けられたビット深度を低減することができる。たとえば、量子化の間にｎビット値がｍビット値へと切り捨てられてよく、この場合、ｎはｍよりも大きい。深度コーディングの場合、３Ｄ−ＨＥＶＣ ＷＤはさらに、残差データのセグメントごとのＤＣコーディングとＤＭＭコーディングとをサポートし、デルタＤＣ値がＰＵ区分に対する残差値を表す。通常のＨＥＶＣ残差値とは異なり、デルタＤＣ残差値は、変換または量子化されないことがある。
[0133]量子化に続いて、ビデオエンコーダ２０は、量子化変換係数を走査して、量子化変換係数を含む２次元行列から１次元ベクトルを生成することができる。走査は、より高いエネルギー（したがって、より低い頻度）の係数を配列の前方に配置し、より低いエネルギー（したがって、より高い頻度）の係数を配列の後方に配置するように設計され得る。
[0134]いくつかの例では、ビデオエンコーダ２０は、エントロピー符号化され得るシリアル化ベクトルを生成するために、量子化変換係数を走査するためにあらかじめ定義された走査順序を利用し得る。他の例では、ビデオエンコーダ２０は適応型走査を実行することができる。量子化変換係数を走査して１次元ベクトルを形成した後、ビデオエンコーダ２０は、たとえば、ＨＥＶＣにおいて使用されるコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）に従って、１次元ベクトルをエントロピー符号化することができる。他のエントロピーコーディング処理の例としては、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、および確率間隔区分エントロピー（ＰＩＰＥ）コーディングがある。やはり、ＨＥＶＣおよび３Ｄ−ＨＥＶＣでは、ＣＡＢＡＣが使用され得る。ビデオエンコーダ２０はまた、ビデオデータを復号する際にビデオデコーダ３０が使用するための、符号化ビデオデータに関連付けられたシンタックス要素をエントロピー符号化することができる。
[0135]ビデオエンコーダ２０はさらに、ブロックベースのシンタックスデータ、ピクチャベースのシンタックスデータ、およびＧＯＰベースのシンタックスデータのようなシンタックスデータを、たとえば、ピクチャヘッダ、ブロックヘッダ、スライスヘッダ、またはＧＯＰヘッダ中でビデオデコーダ３０に送ることができる。ＧＯＰシンタックスデータは、それぞれのＧＯＰ中のピクチャの数を記述することができ、ピクチャシンタックスデータは、対応するピクチャを符号化するために使用される符号化／予測モードを示すことができる。
[0136]ビデオエンコーダ２０および／またはビデオデコーダ３０は、深度データのイントラピクチャ予測コーディングと深度データのインター予測コーディングとを実行することができる。いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ビデオデータの深度イントラ予測コーディングおよび／またはビデオデータの深度インター予測コーディングから生じる残差データをコーディングするために、ＳＤＣを使用することができる。さらなる例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、深度イントラ予測から生じる残差データを生成するために、ＳＤＣを伴って、または伴わずにＤＭＭを使用することができる。ＤＭＭは、区分におけるピクセルに関する区分固有の予測子をもたらすことができる。残差データは、区分におけるピクセルの各々に関して生成され得る。代替的に、ＳＤＣがＤＭＭとともに使用される場合、区分におけるピクセルに適用される単一のＤＣ残差値が生成され得る。
[0137]ＨＥＶＣでは、コーディングユニット（ＣＵ）のサイズが２Ｎｘ２Ｎであると仮定すると、ビデオエンコーダ２０およびビデオデコーダ３０は、イントラ予測の場合は２Ｎｘ２ＮまたはＮｘＮという様々な予測ユニット（ＰＵ）サイズをサポートすることができ、インター予測の場合は２Ｎｘ２Ｎ、２ＮｘＮ、Ｎｘ２Ｎ、ＮｘＮ、または同様のサイズの対称のＰＵサイズをサポートすることができる。ビデオエンコーダおよびビデオデコーダはまた、インター予測の場合は２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズに対する非対称区分をサポートすることができる。３Ｄ−ＨＥＶＣにおいて提供されるような深度コーディングでは、ビデオエンコーダおよびビデオデコーダは、本開示で説明されるように、様々な深度モデリングモード（ＤＭＭ）を含む、イントラ予測および／またはインター予測のための種々の異なる深度コーディングモードをサポートするように構成され得る。
[0138]３Ｄビデオコーディング技法を使用してコーディングされたビデオデータは、３次元効果を生成するためにレンダリングされ、表示され得る。一例として、異なるビューの２つの画像（すなわち、わずかに異なる水平位置を有する２つのカメラの視点に対応する）は、一方の画像が閲覧者の左眼によって見られ、他方の画像が閲覧者の右眼によって見られるように、実質的に同時に表示され得る。
[0139]３Ｄ効果は、たとえば、立体視ディスプレイまたは自動立体視ディスプレイを使用して達成され得る。立体視ディスプレイは、２つの画像を相応にフィルタリングするアイウェアとともに使用され得る。たとえば、パッシブ眼鏡は、適切な眼が適切な画像を見ることを保証するために、偏光レンズ、または異なるカラーレンズ、または他の光学的フィルタリング技法を使用して、画像をフィルタリングすることができる。アクティブ眼鏡は、別の例として、立体視ディスプレイと協調して交互にレンズを高速に閉じることができ、それにより、左眼画像を表示することと右眼画像を表示することとを交互に行い得る。自動立体視ディスプレイは、眼鏡が必要とされないような方法で２つの画像を表示する。たとえば、自動立体視ディスプレイは、各画像が閲覧者の適切な眼に投影されるように構成された鏡またはプリズムを含み得る。
[0140]本開示の技法は、３Ｄビデオをサポートするために深度データをコーディングすることによって、３Ｄビデオデータをコーディングするための技法に関する。一般に、「テクスチャ」という用語は、画像のルミナンス（すなわち、輝度または「ルーマ」）値と画像のクロミナンス（すなわち、色または「クロマ」）値とを表すために使用される。いくつかの例では、テクスチャ画像は、１セットのルミナンスデータ（Ｙ）と、青色相（Ｃｂ）および赤色相（Ｃｒ）のための２セットのクロミナンスデータとを含み得る。たとえば、ＣＴＵは、ルーマＣＴＢとクロマＣＴＢとを含み得る。４：２：２または４：２：０などの特定のクロマフォーマットでは、クロマデータは、ルーマデータに対してダウンサンプリングされる。すなわち、クロミナンスピクセルの空間解像度は、対応するルミナンスピクセルの空間解像度よりも低く、たとえば、ルミナンス解像度の１／２または１／４であり得る。
[0141]深度データは一般に、対応するテクスチャデータの深度値を表す。たとえば、深度画像は、たとえばビューのテクスチャ成分中の対応するテクスチャデータに対する、たとえばビューの深度成分中の深度を各々表す、深度ピクセルのセット（または深度値）を含み得る。各ピクセルは、１つまたは複数のテクスチャ値（たとえば、ルミナンスおよびクロミナンス）を有してよく、１つまたは複数の深度値も有してよい。テクスチャピクチャおよび深度マップは、同じ空間解像度を有することがあるが、そうである必要はない。たとえば、深度マップは、対応するテクスチャピクチャよりも多数または少数のピクセルを含み得る。深度データは、対応するテクスチャデータの水平視差を決定するために使用されてよく、場合によっては垂直視差も使用されてよい。
[0142]したがって、テクスチャデータと深度データとを受信するデバイスは、一方のビュー（たとえば、左眼ビュー）のための第１のテクスチャ画像を表示し、深度値に基づいて決定された水平視差値だけ第１の画像のピクセル値をオフセットすることによって、他方のビュー（たとえば、右眼ビュー）のための第２のテクスチャ画像を生成するように第１のテクスチャ画像を修正するために深度データを使用することができる。一般に、水平視差（または単に「視差」）は、右ビュー中の対応するピクセルに対する第１のビュー中のピクセルの水平空間オフセットを表し、２つのピクセルは、２つのビュー中で表される同じオブジェクトの同じ部分に対応する。
[0143]さらに他の例では、画像について定義されたゼロ視差平面に対して所与のピクセルに関連付けられる深度が定義されるように、画像平面に直交するｚ次元におけるピクセルに対して深度データが定義され得る。そのような深度は、ピクセルを表示するための水平視差を作成するために使用されてよく、その結果、ピクセルは、ゼロ視差平面に対するピクセルのｚ次元深度値に応じて、左眼と右眼とで異なるように表示される。ゼロ視差平面は、ビデオシーケンスの異なる部分に対して変化してよく、ゼロ視差平面に対する深度の量も変化してよい。
[0144]ゼロ視差平面上に位置するピクセルは、左眼と右眼とに対して同様に定義され得る。ゼロ視差平面の前に位置するピクセルは、ピクセルが画像平面に直交するｚ方向の画像から出てくるように見える知覚を生み出すために、（たとえば、水平視差とともに）左眼と右眼とに対して異なる位置に表示され得る。ゼロ視差平面の後ろに位置するピクセルは、深度のわずかな知覚まで、わずかなぼかしとともに表示されてよく、または（たとえば、ゼロ視差平面の前に位置するピクセルの水平視差とは反対の水平視差とともに）左眼と右眼とに対して異なる位置に表示され得る。他の多くの技法も、画像の深度データを伝達または定義するために使用され得る。
[0145]２次元ビデオデータは一般に、その各々が特定の時間インスタンスに対応する、個別ピクチャのシーケンスとしてコーディングされる。すなわち、各ピクチャは、シーケンス中の他の画像の再生時間に対して、関連付けられる再生時間を有する。これらのピクチャはテクスチャピクチャまたはテクスチャ画像と考えられ得る。深度ベースの３Ｄビデオコーディングでは、シーケンス中の各テクスチャピクチャは深度マップにも対応し得る。すなわち、テクスチャピクチャに対応する深度マップは、対応するテクスチャピクチャのための深度データを表す。マルチビュービデオデータは、様々な異なるビューのためのデータを含んでよく、各ビューは、テクスチャ成分および対応する深度成分のそれぞれのシーケンスを含み得る。
[0146]ピクチャは一般に、特定の時間インスタンスに対応する。ビデオデータは、アクセスユニットのシーケンスを使用して表されてよく、各アクセスユニットは、特定の時間インスタンスに対応するすべてのデータを含む。したがって、たとえば、マルチビュービデオデータプラス深度コーディングの場合、共通時間インスタンスに対する各ビューからのテクスチャ画像＋テクスチャ画像の各々に対する深度マップがすべて、特定のアクセスユニット内に含まれ得る。したがって、アクセスユニットは複数のビューを含んでよく、各ビューは、テクスチャ画像に対応するテクスチャ成分のためのデータと、深度マップに対応する深度成分のためのデータとを含み得る。
[0147]各アクセスユニットは、複数のビュー成分またはピクチャを含み得る。特定のビューのビュー成分は、固有のビューｉｄまたはビュー順序インデックスに関連付けられ、その結果、異なるビューのビュー成分は異なるビューｉｄまたはビュー順序インデックスに関連付けられる。ビュー成分はテクスチャビュー成分ならびに深度ビュー成分を含み得る。同じビューの中のテクスチャビュー成分および深度ビュー成分は、異なるレイヤｉｄを有し得る。テクスチャビュー成分は１つまたは複数のテクスチャスライスとしてコーディングされ得る一方、深度ビュー成分は１つまたは複数の深度スライスとしてコーディングされ得る。マルチビュープラス深度は、イントラピクチャ予測、インターピクチャ予測、ビュー内予測、ビュー間予測、動き予測などのような、種々のコーディングの可能性を生み出す。
[0148]このようにして、３Ｄビデオコーディングにおける深度マップコーディングにより、３Ｄビデオデータは、キャプチャまたは生成されたビューが対応する深度マップに関連付けられるテクスチャ成分を含む、マルチビュービデオプラス深度フォーマットを使用して表され得る。その上、３Ｄビデオコーディングでは、テクスチャと深度マップがコーディングされ、３Ｄビデオビットストリームの中に多重化され得る。深度マップはグレースケール画像としてコーディングされてよく、深度マップの「ルーマ」サンプル（すなわち、ピクセル）は深度値を表す。
[0149]一般に、深度データのブロック（たとえばピクセルに対応する、深度マップのサンプルのブロック）は深度ブロックと呼ばれ得る。深度値は、深度サンプルに関連付けられるルーマ値と呼ばれ得る。すなわち、深度マップは一般に、モノクロームテクスチャピクチャ、すなわち、ルミナンス値を含みクロミナンス値を含まないテクスチャピクチャとして扱われ得る。いずれの場合も、従来のイントラコーディングおよびインターコーディング方法が深度マップコーディングのために適用され得る。
[0150]３Ｄ−ＨＥＶＣでは、上述のように、イントラ予測モードの、ＨＥＶＣと同じ定義が利用される。すなわち、３Ｄ−ＨＥＶＣにおいて使用されるイントラモードは、ＨＥＶＣの正規イントラモードを含む。また、３Ｄ−ＨＥＶＣでは、深度モデリングモード（ＤＭＭ）が、深度スライスのイントラ予測ユニットをコーディングするためにＨＥＶＣイントラ予測モードとともに導入される。
[0151]深度マップにおける鋭いエッジのより良好な表現のために、現在のＨＴＭ（３Ｄ−ＨＴＭバージョン１０．０ｒｃ１）は、深度マップのイントラコーディングのためにＤＭＭ方法を適用する。深度ブロックは、ＤＭＭパターンによって指定された２つの領域に区分され、各領域は一定の値によって表される。ＤＭＭパターンは、明示的にシグナリングされる（ＤＭＭモード１）か、または併置（co-located）されるテクスチャブロックによって予測される（ＤＭＭモード４）かのいずれかであり得る。
[0152]Ｗｅｄｇｅｌｅｔ区分（Wedgelet partitioning）と輪郭区分（Contour partitioning）とを含む、ＤＭＭにおいて定義されている２つのタイプの区分モデルがある。図７は、ピクセルサンプルのブロックをコーディングする際に使用するためのＷｅｄｇｅｌｅｔ区分パターンの例を示す図である。図８は、ピクセルサンプルのブロックをコーディングする際に使用するための輪郭区分パターンの例を示す図である。
[0153]Ｗｅｄｇｅｌｅｔ区分では、図７に示されるように、深度ブロックが、直線によって２つの領域に区分され、２つの領域は、Ｐ０およびＰ１と標識される。どのｗｅｄｇｅｌｅｔパターンが使用されるかを示すために、ｗｅｄｇｅｌｅｔパターンインデックス（ｗｅｄｇｅ＿ｆｕｌｌ＿ｔａｂ＿ｉｄｘ）が、ＰＵレベルおよび／またはＣＵレベルで、一般的な予測ユニットパラメータにおいてシグナリングされる。ＤＭＭモード１の場合、ブロックサイズごとに異なるｗｅｄｇｅｌｅｔパターンが適用されることに留意されたい。
[0154]輪郭区分では、図８に示されるように、深度ブロックが、２つの不規則な領域に区分され得る。輪郭区分は、Ｗｅｄｇｅｌｅｔ区分よりも柔軟であるが、明示的にシグナリングするのが難しい。ＤＭＭモード４では、３Ｄ−ＨＥＶＣの場合、輪郭区分パターンは、併置（co-located）されたテクスチャブロックの再構築されたルーマサンプルを使用して暗黙的に導出される。
[0155]ＤＭＭモードがＰＵに適用されるかどうかを示すために、フラグ、すなわちｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇがコーディングユニットパラメータにおいてシグナリングされる。より具体的には、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、ＰＵレベルでイントラモード拡張シンタックステーブルにおいてシグナリングされ得る。ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが１に等しいとき、ＨＥＶＣイントラ予測モードが現在のＰＵに使用される。一方、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが０に等しいとき、ＤＭＭモード（ＤＭＭモード１またはＤＭＭモード４）が現在のＰＵに使用される。
[0156]一例として、図７は、８×８のブロック４０に対するＷｅｄｇｅｌｅｔパターンの例示を与える。Ｗｅｄｇｅｌｅｔ区分では、深度ブロック、たとえばＰＵは、直線４６によって２つの領域４２、４４に区分され、図７に示されるように始点４８は（Ｘｓ，Ｙｓ）に位置し、終点５０は（Ｘｅ，Ｙｅ）に位置し、２つの領域４２、４４はそれぞれＰ０およびＰ１とも標識される。ブロック４０中の各パターンは、対応するサンプルが領域Ｐ０またはＰ１に属するかどうかを標識する、サイズｕＢ×ｖＢの２進数の配列からなり、ｕＢおよびｖＢはそれぞれ、現在のＰＵの水平方向のサイズと垂直方向のサイズを表す。領域Ｐ０およびＰ１は、図７において、それぞれ白いサンプルおよび影付きサンプルによって表されている。Ｗｅｄｇｅｌｅｔパターンは、符号化と復号の両方の最初に初期化される。
[0157]図８の例に示されるように、深度ブロック６０のような深度ブロックは、輪郭区分を使用して、２つの不規則な形状の領域６２、６４へと区分されることができ、ここで領域６２はＰ０と標識され、２つの領域６４Ａおよび６４ＢはそれぞれＰ１と一緒に標識される。領域６４は、２つのサブ領域６４Ａおよび６４Ｂから形成される。サブ領域６４Ａおよび６４Ｂは、それぞれ輪郭線（contour lines）６６および６８によって表される。
[0158]領域６４Ａ中のピクセルは領域６４Ｂ中のピクセルに直接隣接しないが、領域６４Ａおよび６４Ｂは、深度ブロック６０のＰＵを予測する目的で１つの単一の領域（領域「６４」）を形成するように定義され得る。したがって、深度ブロック６０は、２つの不規則な形状の領域６２および６４へと区分されると言われることがあり、領域６４は、２つの不連続のサブ領域６４Ａおよび６４Ｂを含む。
[0159]図７および図８を参照すると、Ｎ×Ｎの深度ブロック４０および６０内の各々の個々の正方形は、それぞれ、深度ブロック４０および６０のそれぞれの個々のピクセルを表す。正方形内の数値は、対応するピクセルが領域４２（図７の例における値「０」）に属するか、領域４４（図７の例における値「１」）に属するかを表す。また、図７において、ピクセルが領域４２（白い正方形）に属するか、領域４４（灰色の影付き正方形）に属するかを示すために陰影が使用される。
[0160]上で論じられたように、各パターン（すなわち、Ｗｅｄｇｅｌｅｔと輪郭の両方）は、対応するサンプル（すなわち、ピクセル）が領域Ｐ０に属するかＰ１に属するか（Ｐ０は図７中の領域４２と図８中の領域６２とに対応し、Ｐ１は図７中の領域４４と図８中の領域６４Ａ、６４Ｂとに対応する）を標識する、サイズｕＢ×ｖＢの２進数の配列によって定義されてよく、ｕＢおよびｖＢはそれぞれ、現在のＰＵの水平方向のサイズおよび垂直方向のサイズを表す。図７および図８の例では、ＰＵは、それぞれブロック４０および６０に対応する。
[0161]ＨＥＶＣイントラ予測モードでは、ＨＥＶＣ ＷＤ１０の８．４．２項において指定されるように、ＰＵの隣接サンプルを使用することによって、ピクセル固有のイントラ予測子値が、ＰＵ中の各ピクセルに対して生成される。
[0162]ＤＭＭのような他の深度イントラモードでは、区分固有のＤＣ予測子が、ＰＵの最大２つの隣接サンプルを使用することによって、ＰＵ内の各区分に対して計算される。ｂＰａｔｔｅｒｎ［ｘ］［ｙ］をＰＵの区分パターンとし、ここでｘ＝０．．Ｎ−１，ｙ＝０．．Ｎ−１であり、ＮはＰＵの幅である。ｂＰａｔｔｅｒｎ［ｘ］［ｙ］はピクセル（ｘ，ｙ）がどの区分に属するかを示し、ｂＰａｔｔｅｒｎ［ｘ］［ｙ］は０または１に等しくてよい。ＢｉｔＤｅｐｔｈを深度サンプルのビット深度とし、ＲｅｃＳａｍｐｌｅ［ｘ］［ｙ］をＰＵの再構築された隣接サンプルとし、ｘ＝−１およびｙ＝０．．Ｎ−１（ＰＵの左の隣接ピクセルに対応する）であり、またはｙ＝−１，ｘ＝０．．Ｎ−１（ＰＵの上の隣接ピクセルに対応する）である。次いで、区分ＸのＤＣ予測子、すなわちｘ＝０または１であるＤＣＰｒｅｄ［Ｘ］は、次のように導出される。
・bT = ( bPattern[0][0] ! = bPattern[N-1][0] ) ? 1 : 0 に設定する
・bL = ( bPattern[0][0] ! = bPattern[0][N-1] ) ? 1 : 0 に設定する
・ｂＴがｂＬに等しい場合、
- DCPred[X] = ( RecSample[-1][0] + RecSample[0][-1] ) >> 1
- DCPred[1-X] = bL ? ( RecSample[-1][N-1] + RecSample[N-1][-1] ) >>
1 : 2BitDepth-1
・それ以外の場合、
- DCPred[X] = bL ? RecSample[(N-1)>>1][-1] : RecSample[-1][(N-1)>>1]
- DCPred[1-X] = bL ? RecSample[-1][N-1] : RecSample[N-1][-1]
[0163]深度参照テーブル（ＤＬＴ：Depth Lookup Table）は、深度インデックスを深度値にマッピングする。ＤＬＴは、ビデオシーケンス全体を符号化する前に第１のイントラ期間内のフレームを分析することによって構築され得る。３Ｄ−ＨＥＶＣの現在の設計では、有効な深度値のすべてが、昇順で並べ替えられ、インデックスの増大とともにＤＬＴに挿入される。
[0164]ＤＬＴは任意選択のコーディングツールである。現在のＨＴＭ（３Ｄ−ＨＴＭバージョン９．０）では、ビデオエンコーダ２０は、分析段階において元の深度マップ中に０からＭＡＸ＿ＤＥＰＴＨ＿ＶＡＬＵＥ（たとえば、８ビット深度サンプルの場合は２５５）までの値の１／２よりも多くが現れる場合、ＤＬＴを使用しない。それ以外の場合、ＤＬＴは、シーケンスパラメータセット（ＳＰＳ）および／またはビデオパラメータセット（ＶＰＳ）においてコーディングされる。エンコーダ２０がＤＬＴをコーディングするために、最初に、有効な深度値の数が指数ゴロムコードによってコーディングされる。次いで、各々の有効な深度値も、指数ゴロムコードによってコーディングされ得る。
[0165]ビデオエンコーダ２０は、コーディングされるべき入力ビデオシーケンスから事前に定義された数のフレームを読み取り、利用可能な深度マップ値のためにすべてのサンプルを走査する。この処理の間、エンコーダ２０は、元の圧縮されていない深度マップに基づいて深度値を有効な深度値にマッピングするマッピングテーブルを生成する。
[0166]ビデオエンコーダ２０および／またはビデオデコーダ３０は、深度参照テーブルＩｄｘ２Ｄｅｐｔｈ（・）と、インデックス参照テーブルＤｅｐｔｈ２Ｉｄｘ（・）と、深度マッピングテーブルＭ（・）と、有効な深度値の数ｄvalidとを、深度マップＤtを分析する以下のアルゴリズムを使用して導出する。
１．初期化
・ブーリアンベクトルＢ（ｄ）＝すべての深度値ｄについてＦＡＬＳＥ
・インデックスカウンタｉ＝０
２．複数の時間インスタンスｔについてＤtの中の各ピクセル位置ｐを処理する：
・有効な深度値に印を付けるために、Ｂ（Ｄt（ｐ））＝ＴＲＵＥに設定する
３．Ｂ（ｄ）→ｄvalidまでのＴＲＵＥ値の数をカウントする
４．Ｂ（ｄ）＝＝ＴＲＵＥである各ｄについて、
・Ｉｄｘ２Ｄｅｐｔｈ（ｉ）＝ｄに設定する
・Ｍ（ｄ）＝ｄに設定する
・Ｄｅｐｔｈ２Ｉｄｘ（ｄ）＝ｉに設定する
・ｉ＝ｉ＋１
５．Ｂ（ｄ）＝＝ＦＡＬＳＥである各ｄについて、
・ｄ’＝ａｒｇ ｍｉｎ｜ｄ−ｄ’｜およびＢ（ｄ’）＝＝ＴＲＵＥであるｄ’を見つける
・Ｍ（ｄ）＝ｄ’に設定する
・Ｄｅｐｔｈ２Ｉｄｘ（ｄ）＝Ｄｅｐｔｈ２Ｉｄｘ（ｄ’）に設定する。
[0167]インデックスＩｄｘを深度値ｄにマッピングし返すことは、次のようなもの、すなわちｄ＝Ｉｄｘ２Ｄｅｐｔｈ［Ｉｄｘ］である。深度値ｄからインデックスＩｄｘへのマッピングは、次のようなもの、すなわちＩｄｘ＝Ｄｅｐｔｈ２Ｉｄｘ［ｄ］である。
[0168]３Ｄ−ＨＥＶＣにおいて、セグメントごとのＤＣコーディング（ＳＤＣ）が導入されている。ＳＤＣでは、ＰＵの区分ごとに１つのＤＣ残差値がシグナリングされ、変換または量子化は適用されない。ＨＥＶＣイントラ予測モードでは、ＰＵ全体が１つの区分と考えられる。ＳＤＣは、深度スライスのイントラＰＵをコーディングするために、正規ＨＥＶＣイントラ予測モードとＤＭＭモードとを含む、すべての深度イントラ予測モードに適用され得る。現在の３Ｄ−ＨＥＶＣでは、ＳＤＣは、２Ｎｘ２ＮのＰＵ区分サイズにのみ適用される。
[0169]各区分の残差値をシグナリングするために、２つの方法が適用され得る。
１．現在のＰＵ中の現在の区分のＤＣ値（すなわち、Ａｖｅｒによって示される平均値）から、隣接サンプルによって生成された、Ｐｒｅｄによって示される予測子を差し引くことによって計算される、各区分のＤＣ残差値を直接コーディングする。
２．ＤＬＴが送信されるとき、ＤＣ残差値をコーディングする代わりに、インデックス参照テーブルからマッピングされるＡｖｅｒおよびＰｒｅｄのインデックス差分がコーディングされる。インデックス差分は、ＡｖｅｒのインデックスからＰｒｅｄのインデックスを差し引くことによって計算される。デコーダ側において、復号されたインデックス差分とＰｒｅｄのインデックスとの合計が、ＤＬＴに基づいて深度値にマッピングし返される。
[0170]図９は、本開示の技法を実装するように構成され得る例示的なビデオエンコーダ２０を示すブロック図である。本開示は、ＨＥＶＣコーディング、より具体的には、たとえば、３Ｄ−ＨＥＶＣ ＷＤにおいて説明され、本開示において説明されるようにさらに修正される、３Ｄ−ＨＥＶＣコーディングの文脈においてビデオエンコーダ２０について説明する。しかしながら、本開示の技法は他のコーディング規格または方法に適用可能であり得る。したがって、図９は、説明のために提供され、本開示で広く例示され記載される技法を限定するものと見なされるべきではない。
[0171]ビデオデコーダ２０は、本開示で説明される制限付き深度イントラコーディングおよび／または制限付きＤＭＭコーディングのための技法のうちのいずれかを実行するように構成され得る。たとえば、ビデオエンコーダ２０は、対応する深度予測ユニットが深度モデリングモード（ＤＭＭ）に従ってコーディングされるときに、（たとえば、変換木ノードが複数のより小さい変換木ノードに分割されるべきではないことを示すために）０に等しくなるようにｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを制限する技法を使用することができる。別の例として、ビデオエンコーダ２０は、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいときに、（たとえば、ＤＭＭコーディングモードが深度予測ユニットに使用されないことを示すために）１に等しくなるようにｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを制限する技法を使用することができる。
[0172]さらなる例として、ビデオエンコーダ２０は、対応する深度予測ユニットがＤＭＭに従ってコーディングされるかどうかに基づいて、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを選択的にシグナリングする技法を使用することができる。追加の例として、ビデオエンコーダ２０は、対応する深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいかどうかに基づいて、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを選択的にシグナリングする技法を使用することができる。いくつかの例では、上述の技法のうちの１つまたは複数は、変換ユニットおよび／または変換木が細分されるのを、そのような細分が深度モデリングモード（ＤＭＭ）に従った深度予測ユニットのイントラコーディングに干渉することになる場合に防ぎ得る。
[0173]図９の例では、ビデオエンコーダ２０は、予測処理ユニット１００と、ビデオデータメモリ１０１と、残差生成ユニット１０２と、変換処理ユニット１０４と、量子化ユニット１０６と、逆量子化ユニット１０８と、逆変換処理ユニット１１０と、再構築ユニット１１２と、フィルタユニット１１４と、復号ピクチャバッファ１１６と、エントロピー符号化ユニット１１８とを含む。予測処理ユニット１００は、インター予測処理ユニット１２０と、イントラ予測処理ユニット１２６とを含む。インター予測処理ユニット１２０は、動き推定（ＭＥ）ユニット１２２と、動き補償（ＭＣ）ユニット１２４とを含む。
[0174]ビデオデータメモリ１０１は、ビデオエンコーダ２０の構成要素によって符号化されるべきビデオデータを記憶することができる。ビデオデータメモリ１０１内に記憶されるビデオデータは、たとえば、ビデオソース１８から取得される場合がある。復号ピクチャバッファ１１６は、たとえば、イントラコーディングモードまたはインターコーディングモードでビデオエンコーダ２０によってビデオデータを符号化する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ１０１および復号ピクチャバッファ１１６は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）（同期ＤＲＡＭ（ＳＤＲＡＭ）を含む）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗ＲＡＭ（ＲＲＡＭ（登録商標））、または他のタイプのメモリデバイスなどの、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ１０１および復号ピクチャバッファ１１６は、同じメモリデバイスまたは別々のメモリデバイスによって提供される場合がある。
[0175]予測処理ユニット１００の構成要素は、テクスチャ符号化と深度符号化の両方を実行するものとして記載される。いくつかの例では、テクスチャ符号化および深度符号化は、予測処理ユニット１００の同じ構成要素、または予測処理ユニット１００内の異なる構成要素によって実行される場合がある。たとえば、いくつかの実装形態では、別々のテクスチャエンコーダおよび深度エンコーダが提供される場合がある。また、複数のビューを符号化するために、たとえば、マルチビュープラス深度コーディングのために、複数のテクスチャエンコーダおよび深度エンコーダが提供される場合がある。
[0176]いずれの場合も、予測処理ユニット１００は、３Ｄ−ＨＥＶＣ処理のような３Ｄコーディング処理の一部として、テクスチャデータと深度データとをイントラ符号化またはインター符号化するように構成され得る。特に、いくつかのモードでは、予測処理ユニット１００は、深度スライスのイントラ予測ユニットをコーディングするために、正規ＨＥＶＣイントラコーディングモードまたはＤＭＭモードを使用することができる。さらに、予測処理ユニット１００は、非ＳＤＣ残差コーディングまたはＳＤＣコーディングを使用することができる。ＳＤＣコーディングまたはＤＭＭコーディングの場合、予測処理ユニット１００は、イントラコード化深度ＰＵまたはインターコード化深度ＰＵに対するデルタＤＣ残差値を生成することができ、デルタＤＣ残差値は、ＰＵまたはコード化ＰＵの区分におけるピクセルの平均値と、イントラ予測またはインター予測されるＰＵ区分における予測されるサンプルの平均値との間の差分を表す。ＰＵは、コーディングモードに応じて、単一の区分または複数の区分を有し得る。ＨＥＶＣイントラモード、ＨＥＶＣインターモード、ＤＭＭのモードまたは他のモードが、深度ＰＵをコーディングするために使用され得る。
[0177]いくつかの例では、予測処理ユニット１００は、制限付き深度イントラモードコーディングおよび／または制限付きＤＭＭコーディングに関するもののような、本開示で説明される修正および／または追加を受けて、実質的に、たとえば３Ｄ−ＨＥＶＣ ＷＤにおいて説明されているような３Ｄ−ＨＥＶＣに従って動作することができる。いくつかの例では、ビデオエンコーダ２０は、図９に示されるものよりも多数の、少数の、または図９に示されるものとは異なる機能構成要素を含み得る。予測処理ユニット１００は、エントロピー符号化ユニット１１８にシンタックス情報を提供することができる。シンタックス情報は、たとえば、どの予測モードが使用されたかと、インター予測の場合の動きベクトル、予測方向、および参照ピクチャインデックスなど、そのようなモードに関係する情報とを示し得る。
[0178]ビデオエンコーダ２０は、符号化されるべきビデオデータを受信する。ビデオエンコーダ２０は、ビデオデータのピクチャのスライスの中の複数のコーディングツリーユニット（ＣＴＵ）の各々を符号化することができる。３Ｄ−ＨＥＶＣでは、ビデオエンコーダ２０は、テクスチャビューおよび深度ビューのＣＴＵを符号化することができる。テクスチャＣＴＵの各々は、ルーマ成分とクロマ成分とを有することができ、ピクチャの等しいサイズのルーマコーディングツリーブロック（ＣＴＢ）および対応するクロマＣＴＢに関連付けられ得る。深度ＣＴＵは、単一の深度成分を含むことができる。ＣＴＵを符号化することの一部として、予測処理ユニット１００は、ＣＴＵのＣＴＢを徐々により小さいブロックに分割するために、４分木区分を実行することができる。より小さいブロックはＣＵのコーディングブロックであり得る。たとえば、予測処理ユニット１００は、ＣＴＵに関連付けられたＣＴＢを４つの等しいサイズのサブブロックに区分することができ、サブブロックのうちの１つまたは複数を４つの等しいサイズのサブサブブロックに区分することができ、以下同様である。
[0179]ビデオエンコーダ２０は、ＣＵの符号化表現（すなわちコード化ＣＵ）を生成するために、ＣＴＢのＣＵを符号化することができる。ＣＵを符号化することの一部として、予測処理ユニット１００は、ＣＵの１つまたは複数のＰＵの間でＣＵに関連付けられたコーディングブロックを区分することができる。したがって、テクスチャスライス中の各ＰＵは、ルーマ成分予測ブロックおよび対応するクロマ成分予測ブロックに関連付けられ得る。深度スライス中の各ＰＵは、単一の成分を有することができる。
[0180]ビデオエンコーダ２０およびビデオデコーダ３０は、様々なサイズを有するＰＵをサポートすることができる。上記で示されたように、ＣＵのサイズは、ＣＵのルーマコーディングブロックのサイズを指す場合があり、ＰＵのサイズは、ＰＵのルーマ予測ブロックのサイズを指す場合がある。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ビデオエンコーダ２０およびビデオデコーダ３０は、イントラ予測の場合は２Ｎ×２ＮまたはＮ×ＮのＰＵサイズをサポートすることができ、インター予測の場合は２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、Ｎ×Ｎ、または同様の対称のＰＵサイズをサポートすることができる。ビデオエンコーダ２０およびビデオデコーダ３０はまた、インター予測の場合は２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズ向けの非対称区分をサポートすることができる。本開示の態様によれば、ビデオエンコーダ２０およびビデオデコーダ３０はまた、深度インターコーディングのためのＰＵの非長方形区分をサポートする。
[0181]インター予測処理ユニット１２０は、ＣＵの各ＰＵに対してインター予測を実行することによって、ＰＵのための予測データを生成することができる。ＰＵの予測データは、ＰＵの予測サンプルブロックと、ＰＵの動き情報とを含み得る。インター予測処理ユニット１２０は、ＣＵのＰＵに対して、ＰＵがＩスライス中にあるか、Ｐスライス中にあるか、それともＢスライス中にあるかに応じて、様々な演算を実行することができる。Ｉスライスでは、すべてのＰＵはイントラ予測される。したがって、ＰＵがＩスライス中にある場合、インター予測処理ユニット１２０は、ＰＵに対してインター予測を実行しない。したがって、Ｉモードで符号化されるブロックに対して、予測ブロックは、同じフレーム内の以前符号化された隣接ブロックからの空間予測を使用して形成される。
[0182]ＰＵがＰスライス中にある場合、動き推定（ＭＥ）ユニット１２２は、ＰＵの参照領域について参照ピクチャのリスト（たとえば、「ＲｅｆＰｉｃＬｉｓｔ０」）中の参照ピクチャを探索することができる。参照ピクチャは、復号ピクチャバッファ１１６に記憶され得る。ＰＵの参照領域は、ＰＵのサンプルブロックに最も密接に対応するサンプルブロックを含む参照ピクチャ内の領域であり得る。動き推定（ＭＥ）ユニット１２２は、ＰＵの参照領域を含む参照ピクチャのＲｅｆＰｉｃＬｉｓｔ０中の位置を示す参照インデックスを生成することができる。
[0183]加えて、インターコーディングの場合、動き推定（ＭＥ）ユニット１２２は、ＰＵのコーディングブロックと参照領域に関連付けられた参照位置との間の空間変位を示す動きベクトル（ＭＶ）を生成することができる。たとえば、ＭＶは、現在の復号ピクチャ中の座標から参照ピクチャ中の座標までのオフセットを提供する２次元ベクトルであり得る。動き推定（ＭＥ）ユニット１２２は、ＰＵの動き情報として参照インデックスとＭＶとを出力することができる。動き補償（ＭＣ）ユニット１２４は、ＰＵの動きベクトルによって示される参照位置における実際のサンプルまたは補間されたサンプルに基づいて、ＰＵの予測サンプルブロックを生成することができる。
[0184]ＰＵがＢスライス中にある場合、動き推定ユニット１２２は、ＰＵについての単予測または双予測を実行することができる。ＰＵについての単予測を実行するために、動き推定ユニット１２２は、ＰＵの参照領域について、ＲｅｆＰｉｃＬｉｓｔ０または第２の参照ピクチャリスト（「ＲｅｆＰｉｃＬｉｓｔ１」）の参照ピクチャを探索することができる。動き推定（ＭＥ）ユニット１２２は、ＰＵの動き情報として、参照領域を含む参照ピクチャのＲｅｆＰｉｃＬｉｓｔ０またはＲｅｆＰｉｃＬｉｓｔ１内の位置を示す参照インデックスと、ＰＵのサンプルブロックと参照領域に関連付けられた参照位置との間の空間変位を示すＭＶと、参照ピクチャがＲｅｆＰｉｃＬｉｓｔ０中にあるかＲｅｆＰｉｃＬｉｓｔ１中にあるかを示す１つまたは複数の予測方向インジケータとを出力することができる。動き補償（ＭＣ）ユニット１２４は、ＰＵの動きベクトルによって示される参照領域における実際のサンプルまたは補間されたサンプルに少なくとも部分的に基づいて、ＰＵの予測サンプルブロックを生成することができる。
[0185]ＰＵのための双方向インター予測を実行するために、動き推定ユニット１２２は、ＰＵの参照領域についてＲｅｆＰｉｃＬｉｓｔ０中の参照ピクチャを探索することができ、また、ＰＵの別の参照領域についてＲｅｆＰｉｃＬｉｓｔ１中の参照ピクチャを探索することができる。動き推定（ＭＥ）ユニット１２２は、参照領域を含む参照ピクチャのＲｅｆＰｉｃＬｉｓｔ０およびＲｅｆＰｉｃＬｉｓｔ１中の位置を示す参照ピクチャインデックスを生成することができる。加えて、動き推定（ＭＥ）ユニット１２２は、参照領域に関連付けられた参照位置とＰＵのサンプルブロックとの間の空間変位を示すＭＶを生成することができる。ＰＵの動き情報は、ＰＵの参照インデックスとＭＶとを含む場合がある。動き補償（ＭＣ）ユニット１２４は、ＰＵの動きベクトルによって示される参照領域における実際のサンプルまたは補間されたサンプルに少なくとも部分的に基づいて、ＰＵの予測サンプルブロックを生成することができる。
[0186]イントラ予測処理ユニット１２６は、ＰＵに対してイントラ予測を実行することによって、ＰＵ用の予測データを生成することができる。ＰＵ用の予測データは、ＰＵ用の予測サンプルブロックと様々なシンタックス要素とを含む場合がある。イントラ予測処理ユニット１２６は、Ｉスライス、Ｐスライス、およびＢスライスの中のＰＵに対してイントラ予測を実行し得る。ＰＵに対してイントラ予測を実行するために、イントラ予測処理ユニット１２６は、複数のイントラ予測モードを使用してＰＵ用の予測データの複数のセットを生成し、次いで、たとえばレートひずみ最適化技法を使用して、受け入れ可能または最適なコーディング性能を生み出すイントラ予測モードのうちの１つを選択することができる。
[0187]イントラ予測モードを使用してＰＵ用の予測データのセットを生成するために、イントラ予測処理ユニット１２６は、そのイントラ予測モードに関連付けられた方向にあるＰＵのサンプルブロック全体にわたって、空間的に隣接するＰＵのサンプルブロックからのサンプルを拡張することができる。隣接ＰＵは、ＰＵ、ＣＵ、およびＣＴＵについて左から右、上から下の符号化順序を仮定すると、ＰＵの上、右上、左上、または左にあり得る。イントラ予測処理ユニット１２６は、様々な数のイントラ予測モード、たとえば、図１に示されるように、３３個の方向性イントラ予測モードを使用し得る。いくつかの例では、イントラ予測モードの数は、ＰＵに関連付けられた領域のサイズに依存する場合がある。
[0188]予測処理ユニット１００は、ＰＵ用にインター予測処理ユニット１２０によって生成された予測データ、またはＰＵ用にイントラ予測処理ユニット１２６によって生成された予測データの中から、ＣＵのＰＵ用の予測データを選択することができる。いくつかの例では、予測処理ユニット１００は、予測データのセットのレート／ひずみメトリックに基づいて、ＣＵのＰＵ用の予測データを選択する。選択された予測データの予測サンプルブロックは、本明細書では、選択された予測サンプルブロックと呼ばれ得る。
[0189]残差生成ユニット１０２は、ＣＵのルーマコーディングブロック、ＣｂコーディングブロックおよびＣｒコーディングブロック、ならびにＣＵのＰＵの選択されたインターまたはイントラ予測ルーマブロック、インターまたはイントラ予測Ｃｂブロック、およびインターまたはイントラ予測Ｃｒブロックに基づいて、ＣＵのルーマ残差ブロック、Ｃｂ残差ブロック、およびＣｒ残差ブロックを生成し得る。たとえば、残差生成ユニット１０２は、残差ブロック中の各サンプルがＣＵのコーディングブロック中のサンプルとＣＵのＰＵの対応する選択された予測サンプルブロック中の対応するサンプル（すなわち、適用可能な場合、ルーマピクセル値またはクロマピクセル値のサンプル）との間の差に等しい値を有するように、ＣＵの残差ブロックを生成することができる。
[0190]変換処理ユニット１０４は、ＣＵに関連付けられた残差ブロックを、ＣＵのＴＵに関連付けられた変換ブロックに区分するために、４分木区分を実行することができる。したがって、ＴＵは、テクスチャビューの場合に、ルーマ変換ブロックおよび２つのクロマ変換ブロックに関連付けられ得る。ＣＵのＴＵのルーマ変換ブロックおよびクロマ変換ブロックのサイズおよび位置は、ＣＵのＰＵの予測ブロックのサイズおよび位置に、基づく場合も基づかない場合もある。「残差４分木」（ＲＱＴ）として知られる４分木構造は、領域の各々に関連付けられたノードを含む場合がある。ＣＵのＴＵは、ＲＱＴのリーフノードに対応することができる。
[0191]変換処理ユニット１０４は、ＣＵの各ＴＵに関する変換係数ブロックを、ＴＵの変換ブロックに１つまたは複数の変換を適用することによって生成することができる。変換処理ユニット１０４は、ＴＵに関連付けられた変換ブロックに様々な変換を適用することができる。たとえば、変換処理ユニット１０４は、離散コサイン変換（ＤＣＴ）、方向変換、または概念的に同様の変換を、変換ブロックに適用し得る。いくつかの例では、変換処理ユニット１０４は、変換ブロックに変換を適用しない。そのような例では、変換ブロックは、変換係数ブロックとして扱われ得る。
[0192]量子化ユニット１０６は、係数ブロック内の変換係数を量子化することができる。量子化処理は、変換係数の一部またはすべてに関連付けられるビット深度を低減することができる。たとえば、量子化の間にｎビット変換係数がｍビット変換係数へと切り捨てられてよく、この場合、ｎはｍよりも大きい。量子化ユニット１０６は、ＣＵに関連付けられた量子化パラメータ（ＱＰ）値に基づいて、ＣＵのＴＵに関連付けられた係数ブロックを量子化することができる。ビデオエンコーダ２０は、ＣＵに関連付けられたＱＰ値を調整することによって、ＣＵに関連付けられた係数ブロックに適用される量子化の程度を調整することができる。量子化は、情報の損失をもたらす場合があり、したがって、量子化変換係数は、元の係数よりも低い精度を有する場合がある。
[0193]逆量子化ユニット１０８および逆変換処理ユニット１１０は、係数ブロックから残差ブロックを再構築するために、それぞれ、係数ブロックに逆量子化と逆変換とを適用することができる。再構築ユニット１１２は、ＴＵに関連付けられた再構築された変換ブロックを生成するために、予測処理ユニット１００によって生成された１つまたは複数の予測サンプルブロックからの対応するサンプルに、再構築された残差ブロックを加算することができる。ビデオエンコーダ２０は、このようにＣＵの各ＴＵのための変換ブロックを再構築することによって、ＣＵのコーディングブロックを再構築することができる。
[0194]ＨＥＶＣイントラモード、ＨＥＶＣインターモードおよび他のモード、たとえばＤＭＭモードの場合、予測されるＰＵまたはＰＵ区分に対して、ＤＣ残差値とも呼ばれるデルタＤＣ残差値を生成するために、デルタＤＣコーディングが使用され得る。ＳＤＣの場合、またはＳＤＣを伴うＤＭＭの場合、残差生成ユニット１０２は、各深度ＰＵまたはＰＵ区分に対する単一のデルタＤＣ値を生成することができ、単一のデルタＤＣ値は、ＰＵまたはＰＵ区分におけるピクセルの平均値と、イントラ予測またはインター予測されるＰＵまたはＰＵ区分における予測されるサンプルの平均値との間の差分を表す。ＳＤＣを伴わないＤＭＭの場合、残差生成ユニット１０２は、デルタＤＣ値と通常の残差木とを生成することができる。デルタＤＣ残差値は、変換または量子化されず、線１１５によって示されるように、残差生成ユニット１０２によってエントロピーコーディングユニット１１８に提供され得る。
[0195]再構築ユニット１１２は、深度ＣＵを、ＣＵのＰＵの区分およびＣＵのＰＵの対応する予測される区分に対するＤＣ残差値に基づいて再構築することができる。たとえば、各深度ＰＵ区分に対するデルタＤＣ残差値が、深度ＰＵ区分を再構築するために、対応する予測される区分のピクセル値に加算されてよく、ＤＣ残差値は、深度ＰＵ区分のピクセルの平均値と予測される区分の予測されるサンプルの平均値との間の差分を表し得る。ＳＤＣの場合、ＳＤＣを伴うＤＭＭを含め、ＤＣ残差値だけが使用される。ＳＤＣを伴わないＤＭＭの場合、ＤＣ残差値および残差木が使用され得る。いくつかの例では、デルタＤＣ値を表す１つまたは複数のシンタックス要素のような、ＤＣ残差値を表す情報が、予測処理ユニット１００によって生成され、エントロピー符号化ユニット１１８によって受信され、たとえば線１１５によって示されるように、逆量子化または逆変換処理を伴わずに再構築ユニット１１２によって使用され得る。
[0196]フィルタユニット１１４は、再構築されたＣＵに関連付けられたコーディングブロックの中のブロッキングアーティファクトを低減するために、１つまたは複数のデブロッキング動作を実行し得る。復号ピクチャバッファ１１６は、フィルタユニット１１４が、再構築されたコーディングブロックに対して１つまたは複数のデブロッキング動作を実行した後、再構築されたコーディングブロックを記憶することができる。インター予測ユニット１２０は、他のピクチャのＰＵに対してインター予測を実行するために、再構築されたコーディングブロックを含む参照ピクチャを使用し得る。加えて、イントラ予測処理ユニット１２６は、ＣＵと同じピクチャの中の他のＰＵに対してイントラ予測を実行するために、復号ピクチャバッファ１１６の中の再構築されたコーディングブロックを使用し得る。
[0197]エントロピー符号化ユニット１１８は、ビデオエンコーダ２０の様々な機能構成要素からデータを受信することができる。たとえば、エントロピー符号化ユニット１１８は、量子化ユニット１０６から係数ブロックを受信することができ、予測処理ユニット１００からシンタックス要素を受信することができる。加えて、エントロピー符号化ユニット１１８は、残差生成ユニット１０２からデルタＤＣ残差値を受信することができる。エントロピー符号化ユニット１１８は、エントロピー符号化データを生成するために、データに対して１つまたは複数のエントロピー符号化演算を実行し得る。たとえば、エントロピー符号化ユニット１１８は、ＣＡＢＡＣ演算を実行することができる。ビデオエンコーダ２０は、エントロピー符号化ユニット１１８によって生成されたＣＡＢＡＣエントロピー符号化データを含む符号化ビデオビットストリームを出力し得る。たとえば、ビットストリームは、バイナリシンタックス要素またはバイナリ化シンタックス要素のビンを表すビットを含む場合がある。
[0198]ビデオエンコーダ２０は、本開示で説明される技法のいずれかを実行するように構成されたビデオエンコーダの例である。追加の３Ｄ処理構成要素もビデオエンコーダ２０内に含まれ得る。本開示の１つまたは複数の技法によれば、ビデオエンコーダ２０内の１つまたは複数のユニットは、ビデオ符号化処理の一部として、本明細書で説明される技法を実行し得る。同様に、ビデオエンコーダ２０は、後でコーディングされるビデオデータの予測のために参照データとして使用されるビデオデータを再構築するために、ビデオ復号処理を実行することができる。
[0199]たとえば、ビデオエンコーダ２０は、本開示で説明されるように、深度イントラコーディングおよび／またはＤＭＭコーディングのために、１つもしくは複数のシンタックス要素を制限するか、または１つもしくは複数のシンタックス要素を選択的にシグナリングする技法を使用するように構成され得る。本技法は、変換ユニットおよび／または変換木が細分されるのを、そのような細分が深度モデリングモード（ＤＭＭ）に従った深度予測ユニットのイントラコーディングに干渉することになる場合に防ぎ得る。
[0200]図１０は、本開示の技法を実行するように構成された例示的なビデオデコーダ３０を示すブロック図である。図１０は、例示のために提供され、本開示で広く例示され記載される技法を限定するものと見なされるべきではない。本開示は、ＨＥＶＣコーディング、特に３Ｄ−ＨＥＶＣの文脈においてビデオデコーダ３０について説明する。しかしながら、本開示の技法は他の３Ｄビデオコーディング規格または方法に適用可能であり得る。
[0201]ビデオデコーダ３０は、本開示で説明される制限付き深度イントラコーディングおよび／または制限付きＤＭＭコーディングのための技法のうちのいずれかを実行するように構成され得る。たとえば、ビデオデコーダ３０は、対応する深度予測ユニットが深度モデリングモード（ＤＭＭ）に従ってコーディングされるときに、（たとえば、変換木ノードが複数のより小さい変換木ノードに分割されるべきではないことを示すために）ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇが０に等しくなることを指定する制限を満たす符号化ビットストリームを復号する技法を使用することができる。別の例として、ビデオデコーダ３０は、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいときに、（たとえば、ＤＭＭコーディングモードが深度予測ユニットに使用されないことを示すために）ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが１に等しくなることを指定する制限を満たす符号化ビットストリームを復号する技法を使用することができる。
[0202]さらなる例として、ビデオデコーダ３０は、対応する深度予測ユニットがＤＭＭに従ってコーディングされるかどうかに基づいて、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを選択的に復号する技法を使用することができる。追加の例として、ビデオデコーダ３０は、対応する深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいかどうかに基づいて、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを選択的に復号する技法を使用することができる。いくつかの例では、上述の技法のうちの１つまたは複数は、変換ユニットおよび／または変換木が細分されるのを、そのような細分が深度モデリングモード（ＤＭＭ）に従った深度予測ユニットのイントラコーディングに干渉することになる場合に防ぎ得る。
[0203]図１０の例では、ビデオデコーダ３０は、エントロピー復号ユニット１５０と、ビデオデータメモリ１５１と、予測処理ユニット１５２と、逆量子化ユニット１５４と、逆変換処理ユニット１５６と、再構築ユニット１５８と、フィルタユニット１６０と、復号ピクチャバッファ１６２とを含む。予測処理ユニット１５２は、インター予測用の動き補償（ＭＣ）ユニット１６４と、イントラ予測処理ユニット１６６とを含むことができる。
[0204]ビデオデータメモリ１５１は、ビデオデコーダ３０の構成要素によって復号されるべき、符号化ビデオビットストリームなどのビデオデータを記憶することができる。ビデオデータメモリ１５１内に記憶されたビデオデータは、たとえば、コンピュータ可読媒体１６から、たとえば、カメラなどのローカルビデオソースから、ビデオデータのワイヤードもしくはワイヤレスのネットワーク通信を介して、または物理データ記憶媒体にアクセスすることによって取得され得る。ビデオデータメモリ１５１は、符号化ビデオビットストリームからの符号化ビデオデータを記憶するコード化ピクチャバッファ（ＣＰＢ）を形成することができる。復号ピクチャバッファ１６２は、たとえば、イントラコーディングモードまたはインターコーディングモードでビデオデコーダ３０によってビデオデータを復号する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ１５１および復号ピクチャバッファ１６２は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）（同期ＤＲＡＭ（ＳＤＲＡＭ）を含む）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗性ＲＡＭ（ＲＲＡＭ）、または他のタイプのメモリデバイスなどの、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ１５１および復号ピクチャバッファ１６２は、同じメモリデバイスまたは別々のメモリデバイスによって提供される場合がある。
[0205]説明を容易にするために、予測処理ユニット１５２の構成要素は、テクスチャ復号と深度復号の両方を実行するものとして記載される。いくつかの例では、テクスチャ復号および深度復号は、予測処理ユニット１５２の同じ構成要素、または予測処理ユニット１５２内の異なる構成要素によって実行される場合がある。たとえば、いくつかの実装形態では、別々のテクスチャデコーダおよび深度デコーダが提供される場合がある。また、複数のビューを復号するために、たとえば、マルチビュープラス深度コーディングのために、複数のテクスチャデコーダおよび深度デコーダが提供される場合がある。いずれの場合も、予測処理ユニット１５２は、３Ｄ−ＨＥＶＣ処理のような３Ｄコーディング処理の一部として、テクスチャデータと深度データとをイントラ復号またはインター復号するように構成され得る。
[0206]したがって、予測処理ユニット１５２は、制限付き深度イントラモードコーディングおよび／または制限付きＤＭＭコーディングに関するもののような、本開示で説明される修正および／または追加を受けて、実質的に３Ｄ−ＨＥＶＣに従って動作することができる。予測処理ユニット１５２は、エントロピー復号ユニット１５０を介して、ＳＤＣまたは非ＳＤＣ残差コーディング技法を使用して、イントラ復号またはインター復号された深度データのために、符号化ビデオビットストリームから残差データを取得し、イントラ予測またはインター予測された深度データと残差データとを使用してＣＵを再構築することができる。いくつかの例では、残差データは、たとえば、ＳＤＣコーディングまたはＤＭＭコーディングによって生成され得る、デルタＤＣ残差値であり得る。ビデオデコーダ３０は、図１０に示されるものよりも多数の、少数の、または図１０に示されるものとは異なる機能構成要素を含み得る。
[0207]ビデオデコーダ３０は、符号化ビデオビットストリームを受信する。エントロピー復号ユニット１５０は、ビットストリームからエントロピー符号化シンタックス要素を復号するために、ビットストリームを解析する。予測処理ユニット１５２、逆量子化ユニット１５４、逆変換処理ユニット１５６、再構築ユニット１５８、およびフィルタユニット１６０は、ビットストリームから抽出されたシンタックス要素に基づいて、復号ビデオデータを生成することができる。ビットストリームは、一連のＮＡＬユニットを備える場合がある。ビットストリームのＮＡＬユニットは、コード化スライスＮＡＬユニットを含む場合がある。ビットストリームを復号することの一部として、エントロピー復号ユニット１５０は、コード化スライスＮＡＬユニットからシンタックス要素を抽出し、エントロピー復号し得る。
[0208]コード化スライスの各々は、スライスヘッダと、スライスデータとを含む場合がある。スライスヘッダは、スライスに関係するシンタックス要素を含む場合がある。スライスヘッダ内のシンタックス要素は、スライスを含むピクチャに関連付けられたＰＰＳを識別するシンタックス要素を含む場合がある。ＰＰＳはＳＰＳを参照することができ、ＳＰＳは次にＶＰＳを参照することができる。エントロピー復号ユニット１５０はまた、ＳＥＩメッセージのようなシンタックス情報を含み得る他の要素をエントロピー復号することができる。スライスヘッダ、パラメータセット、またはＳＥＩメッセージのいずれかの中の復号されたシンタックス要素は、本開示で説明される例示的な技法に従ってシグナリングされるものとして、本明細書に記載された情報を含む場合がある。そのようなシンタックス情報は、テクスチャブロックまたは深度ブロックの復号および再構築のために、予測処理ユニット１５２に提供され得る。
[0209]ビデオデコーダ３０は、区分されていないＣＵおよびＰＵに対して再構築動作を実行することができる。非ＳＤＣコーディングのために再構築動作を実行するために、ビデオデコーダ３０は、ＣＵの各ＴＵに対して再構築動作を実行することができる。ＣＵの各ＴＵに対して再構築動作を実行することによって、ビデオデコーダ３０は、ＣＵのブロックを再構築することができる。ＣＵのＴＵに対して再構築動作を実行することの一部として、逆量子化ユニット１５４は、ＴＵに関連付けられた係数ブロックを逆量子化（ｉｎｖｅｒｓｅ ｑｕａｎｔｉｚｅ）、すなわち逆量子化（ｄｅ−ｑｕａｎｔｉｚｅ）することができる。逆量子化ユニット１５４は、量子化の程度を決定するために、同様に、逆量子化ユニット１５４が適用すべき逆量子化の程度を決定するために、ＴＵのＣＵに関連付けられたＱＰ値を使用することができる。すなわち、圧縮比、すなわち、元のシーケンスと圧縮されたシーケンスとを表すために使用されるビット数の比は、変換係数を量子化するときに使用されるＱＰの値を調整することによって制御され得る。圧縮比はまた、利用されるエントロピーコーディングの方法に依存する場合がある。
[0210]逆量子化ユニット１５４が係数ブロックを逆量子化した後、逆変換処理ユニット１５６は、ＴＵに関連付けられた残差ブロックを生成するために、係数ブロックに１つまたは複数の逆変換を適用することができる。たとえば、逆変換処理ユニット１５６は、逆ＤＣＴ、逆整数変換、逆カルーネンレーベ変換（ＫＬＴ）、逆回転変換、逆方向変換、または別の逆変換を、係数ブロックに適用し得る。
[0211]ＰＵがイントラ予測を使用して符号化される場合、イントラ予測処理ユニット１６６は、ＰＵ用の予測ブロックを生成するために、イントラ予測を実行することができる。イントラ予測処理ユニット１６６は、空間的に隣接するＰＵの予測ブロックに基づいて、テクスチャスライスのＰＵのための予測ルーマブロックと、予測Ｃｂブロックと、予測Ｃｒブロックとを生成するために、イントラ予測モードを使用し得る。イントラ予測処理ユニット１６６は、深度スライスの深度ブロックを生成するために、イントラ予測モードを使用することができる。イントラ予測処理ユニット１６６は、ビットストリームから復号された１つまたは複数のシンタックス要素に基づいて、ＰＵのためのイントラ予測モードを決定し得る。
[0212]インター予測を使用してＰＵが符号化される場合、ＭＣユニット１６４は、ＰＵのインター予測ブロックを生成するためにイントラ予測を実行することができる。ＭＣユニット１６４は、他のピクチャまたはビューにおけるＰＵの予測ブロックに基づいて、テクスチャＰＵのための予測ルーマブロック、予測Ｃｂブロック、および予測Ｃｒブロックならびに／または予測深度ブロックを生成するために、インター予測モードを使用することができる。ＭＣユニット１６４は、ビットストリームから復号された１つまたは複数のシンタックス要素に基づいて、ＰＵのためのインター予測モードを決定することができ、動きベクトル、予測方向、および参照ピクチャインデックスなどの動き情報を受信することができる。
[0213]インター予測の場合、ＭＣユニット１６４は、ビットストリームから抽出されたシンタックス要素に基づいて、第１の参照ピクチャリスト（ＲｅｆＰｉｃＬｉｓｔ０）と第２の参照ピクチャリスト（ＲｅｆＰｉｃＬｉｓｔ１）とを構築することができる。ＰＵがインター予測を使用して符号化された場合、エントロピー復号ユニット１５０は、ＰＵの動き情報を抽出し得る。ＭＣユニット１６４は、ＰＵの動き情報に基づいて、ＰＵ用の１つまたは複数の参照ブロックを決定することができる。動き補償（ＭＣ）ユニット１６４は、ＰＵ用の１つまたは複数の参照ブロックにおけるブロック中のサンプルに基づいて、テクスチャＰＵの予測ルーマブロック、予測Ｃｂブロックおよび予測Ｃｒブロックならびに深度ＰＵの予測深度ブロックを生成することができる。
[0214]適用可能な場合、再構築ユニット１５８は、ＣＵのルーマコーディングブロックと、Ｃｂコーディングブロックと、Ｃｒコーディングブロックとを再構築するために、ＣＵのＴＵに関連付けられたルーマ変換ブロック、Ｃｂ変換ブロック、およびＣｒ変換ブロック、ならびにＣＵのＰＵの予測ルーマブロック、予測Ｃｂブロック、および予測Ｃｒブロック、すなわち、イントラ予測データまたはインター予測データのいずれかを使用することができる。たとえば、再構築ユニット１５８は、ＣＵのルーマコーディングブロックと、Ｃｂコーディングブロックと、Ｃｒコーディングブロックとを再構築するために、ルーマ変換ブロック、Ｃｂ変換ブロック、およびＣｒ変換ブロックの残差サンプルを、予測ルーマブロック、予測Ｃｂブロック、および予測Ｃｒブロックの対応するサンプルに加算することができる。同様に、再構築ユニット１５８は、ＣＵの深度ブロックを再構築するために、イントラ予測データまたはインター予測データを使用することができる。
[0215]フィルタユニット１６０は、ＣＵのルーマコーディングブロック、Ｃｂコーディングブロック、およびＣｒコーディングブロックに関連付けられたブロッキングアーティファクトを低減するために、デブロッキング動作を実行し得る。ビデオデコーダ３０は、ＣＵのルーマコーディングブロックと、Ｃｂコーディングブロックと、Ｃｒコーディングブロックとを、復号ピクチャバッファ１６２に記憶し得る。復号ピクチャバッファ１６２は、次の動き補償、イントラ予測、および図２のディスプレイデバイス３２などのディスプレイデバイス上での提示のために、参照ピクチャを提供することができる。たとえば、ビデオデコーダ３０は、復号ピクチャバッファ１６２中のルーマブロック、Ｃｂブロック、およびＣｒブロックに基づいて、他のＣＵのＰＵに対してイントラ予測演算またはインター予測演算を実行することができる。
[0216]いくつかの例では、ビデオデコーダ３０は、本明細書で説明されるように、デルタＤＣ残差値を表すために使用される１つまたは複数のシンタックス要素のエントロピーコーディングの複雑性を低減するために、修正されたバイナリ化および／またはコンテキストモデリング処理を使用し得る。さらなる例では、ビデオデコーダ３０内の１つまたは複数のユニットは、ビデオ復号処理の一部として、本明細書で説明される１つまたは複数の技法を実行することができる。追加の３Ｄコーディング構成要素もビデオエンコーダ３０内に含まれ得る。
[0217]予測処理ユニット１５２、より具体的にはイントラ予測処理ユニット１６６および動き補償（ＭＣ）ユニット１６４は適用可能な場合、３Ｄ−ＨＥＶＣのような３Ｄビデオコーディング処理の深度イントラ予測モードおよび深度インター予測モードにおいてＳＤＣまたはＤＭＭを実行するかどうかを、受信されたシンタックス情報に基づいて決定することができる。たとえば、ＳＤＣまたはＤＭＭが使用されるとき、エントロピー復号ユニット１５０は、深度ＣＵのＰＵまたはＰＵ区分に対する１つまたは複数のデルタＤＣ残差値、さらには関連付けられるシンタックス情報をエントロピー復号することができる。
[0218]ＳＤＣの場合、エントロピー復号ユニット１５０は、図１０に示されるように、ブロックのためのＳＤＣシンタックス情報を予測処理ユニット１５２に提供することができる。エントロピー復号ユニット１５０は、デルタＤＣ残差値を再構築ユニット１５８に提供することができる。ビデオデコーダ３０によって受信されたデルタＤＣ残差値は、変換および量子化されない。特に、デルタＤＣ残差値は、逆量子化および逆変換のために逆量子化ユニット１５４および逆変換処理ユニット１５６へ最初に提供されなくてよい。代わりに、エントロピー復号ユニット１５０は、デルタＤＣ残差値を表すシンタックス要素に関するビンを、ビットストリーム中のビットから復号し、デルタＤＣ残差値を表す情報を、コード化ＰＵまたは区分を再構築する際に使用するために再構築ユニット１５８に提供することができる。再構築ユニット１５８は、深度ＣＵのイントラ予測またはインター予測されるＰＵまたはＰＵ区分を予測処理ユニット１５２から受信し、コード化ＰＵまたはＰＵ区分を再構築するために、予測されるＰＵまたはＰＵ区分のサンプルの各々にデルタＤＣ残差値を加算することができる。
[0219]このようにして、たとえば、ＳＤＣまたはＤＭＭが使用されるとき、再構築ユニット１５８は、深度ＣＵを、ＣＵのＰＵの区分およびＣＵの対応する予測されるＰＵまたはＰＵ区分に対するデルタＤＣ残差値に基づいて再構築することができる。やはり、デルタＤＣ残差値は、深度ＰＵまたはＰＵ区分のピクセルの平均値と、予測されるＰＵまたはＰＵ区分の予測されるサンプルの平均値との間の差分を表し得る。ＳＤＣを伴わずにＤＭＭが使用されるとき、デルタＤＣ値に加えて、通常の残差コーディングツリーが使用され得る。同様に、ＨＥＶＣイントラモードが使用されるとき、通常の残差コーディングツリーが使用され得る。
[0220]本開示の様々な例によれば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＤＭＭコーディングのための技法を含む、本開示で説明される深度イントラコーディングのための技法を実行するように構成され得る。いくつかの例では、深度イントラモードコーディングのための技法は、変換ユニットおよび／または変換木が細分されるのを、そのような細分がＤＭＭ予測モード、たとえばＤＭＭモード１またはＤＭＭモード４に従った深度予測ユニットのイントラコーディングに干渉することになる場合に防ぎ得る。
[0221]さらなる例では、深度イントラモードコーディングのための技法は、深度モデリングモード（ＤＭＭ）に従って深度成分をイントラコーディングするときに、予測ユニット全体が同じｗｅｄｇｅｌｅｔパターンに従って符号化されるように使用され得る。追加の例では、深度イントラモードコーディングのための技法は、ＤＭＭに従って深度成分をイントラコーディングするときに、予測ユニットが３つ以上の領域ではなく２つの領域に分割されるようにし得る。
[0222]本開示の技法は、いくつかの例では、３Ｄ−ＨＥＶＣの現在のＤＭＭコーディングに関係する以下の問題のうちの１つまたは複数を克服することができる。イントラ予測モードによりコーディングされるコーディングユニット（ＣＵ）に関して、セグメントごとのＤＣコーディング（ＳＤＣ：segment-wise DC coding）が適用されない場合、１つの変換木（利用可能な場合）が、ＣＵの残差を表すようにコーディングされ、各ＰＵが変換木ノードに対応する。ＤＭＭコード化ＰＵの関連変換木ノードに対する深度制限はない。言い換えれば、そのような変換木ノード内の変換ユニット（ＴＵ）は、ＰＵサイズから最小許容可能ＴＵサイズ（たとえば、４×４）までのサイズをとり得る。しかしながら、そのような変換木ノードの深度が０よりも大きく、ＴＵサイズがＰＵサイズよりも小さいとき、２つの問題が生じ得る。
[0223]第１の問題は、ＤＭＭモード１を使用するときに生じることがあり、ここで説明される。図６に示されるものと同じＰＵ構造およびＴＵ構造が、イントラ予測モードによりコーディングされるＣＵに使用され、図６におけるＰＵ０がＤＭＭモード１により予測されると仮定する。ＰＵ０内のすべてのＴＵは、ＰＵレベルでシグナリングされた同じｗｅｄｇｅｌｅｔパターンインデックスを使用すべきである。ただし、異なるブロックサイズについて異なるｗｅｄｇｅｌｅｔパターンが適用されるので、同じｗｅｄｇｅｌｅｔパターンインデックスは、異なるＴＵサイズについての異なるｗｅｄｇｅｌｅｔパターンに対応し得る。したがって、ＰＵ内のＴＵは、異なるイントラ予測モードを使用することがあり、これはＰＵの概念を壊す可能性がある。さらに、シグナリングされたｗｅｄｇｅｌｅｔパターンインデックスは、ＴＵサイズによっては無効であることもあり、その結果、そのようなＴＵサイズに関して未知のｗｅｄｇｅｌｅｔパターンが生じることがある。
[0224]第２の問題は、ＤＭＭモード１および／またはＤＭＭモード４を使用するときに生じることがあり、ここで説明される。ＰＵがＤＭＭモード１またはＤＭＭモード４によりコーディングされるとき、ＰＵ内の各ＴＵが２つの領域に区分される。したがって、ＰＵは、複数のＴＵを含んでいるときに、３つ以上の領域を含み得る。これは、ＰＵを２つの領域に分割することを予想するＤＭＭモード（ＤＭＭモード１とＤＭＭモード４の両方）の概念を壊す可能性がある。
[0225]本開示の技法は、いくつかの例では、深度モデリングモード（ＤＭＭ）コーディングにおける上述の問題の一方または両方に対する解決策を提供することができる。いくつかの例では、深度モデリングモード（ＤＭＭ）コーディングを実行するときに、以下の技法のうちの１つまたは複数が使用され得る。
[0226]第１の技法によれば、変換木ノードに関連付けられる予測ユニット（ＰＵ）がＤＭＭモードのうちの１つ（たとえば、ＤＭＭモード１またはＤＭＭモード４）によりコーディングされるとき、変換木ノードのｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇは０になるものとする。第１の技法を使用するとき、３Ｄ−ＨＥＶＣにおいて使用される変換木構造はそのままであってよく、したがって、ＨＥＶＣにおけるものと同じであり得る。しかしながら、いくつかの例では、関連ＰＵがＤＭＭモードによりコーディングされる変換木ノードの場合、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇは０になるように制限され得る。さらなる例では、関連ＰＵがＤＭＭモードによりコーディングされる変換木ノードの場合、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇはシグナリングされないか、または０になると推測される。
[0227]第２の技法によれば、ＰＵサイズが最大変換ブロックサイズよりも大きいとき、ＤＭＭモードは適用されない。言い換えれば、エンコーダは、ＰＵサイズが最大変換ブロックサイズよりも大きいときに、ＤＭＭモードを使用することを可能にされないことがある。第２の技法を使用するとき、イントラモード拡張シンタックステーブルは、いくつかの例では、変更されないことがあるが、（ＤＭＭモードが使用されるかどうかを示す）フラグｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、サイズが最大変換ブロックサイズよりも大きいＰＵに関して１に制限され得る。他の例では、第２の技法を使用するとき、（ＤＭＭモードが使用されるかどうかを示す）ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、サイズが最大変換ブロックサイズよりも大きいＰＵに関してシグナリングされず、デコーダによって１であると推測される。
[0228]第３の技法によれば、ＰＵのＰＵサイズが最大変換ブロックサイズよりも大きく、ＰＵの残差がＳＤＣによりコーディングされない（すなわち、そのＰＵに関して変換木がコーディングされるものとする）とき、ＤＭＭモードは適用されない。言い換えれば、エンコーダは、ＰＵの残差をコーディングするために変換木が使用され、ＰＵのサイズが最大変換ブロックサイズよりも大きいときに、ＤＭＭモードを使用することを可能にされないことがある。第３の技法を使用するとき、イントラモード拡張シンタックステーブルは、いくつかの例では、変更されないことがあるが、（ＤＭＭモードが使用されるかどうかを示す）フラグｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、ＰＵに関して、ＰＵの残差がＳＤＣによりコーディングされず、ＰＵのサイズが最大変換ブロックサイズよりも大きい場合に、１になるように制限され得る。他の例では、第２の技法を使用するとき、（ＤＭＭモードが使用されるかどうかを示す）ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、ＰＵに関して、ＰＵの残差がＳＤＣによりコーディングされず、ＰＵのサイズが最大変換ブロックサイズよりも大きい場合に、シグナリングされない。そのような例では、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、デコーダによって１であると推測され得る。
[0229]第４の技法によれば、ＰＵがＤＭＭモードのうちの１つによりコーディングされるとき、復号順序で１つずつＰＵ内のＴＵを予測し再構築する代わりに、ＰＵ全体が、その中のＴＵを再構築する前に３Ｄ−ＨＥＶＣがするのと同じ方法を使用して予測される。その後、ＰＵの再構築サンプルが、ＰＵの予測サンプルにＰＵの関連変換木ノードによって表される残差を加算することによって導出される。
[0230]第１の技法および第２の技法の例示的な実装形態がここで説明される。例示的な実装形態は、３Ｄ−ＨＥＶＣのワーキングドラフトに加えて実施され得る。
[0231]ワーキングドラフトのシンタックスまたはセマンティクスの変更は、次のように示される。新たに追加された部分はイタリック体で表される。
[0232]第１の実施形態では、３Ｄ−ＨＥＶＣのシンタックスは変更されない。関連ＰＵがＤＭＭモードによりコーディングされる変換木ノードの場合、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇは０になるように制限され、最大変換ブロックサイズよりも大きいサイズを有するＰＵの場合、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは０になるように制限される。第１の実施形態についての例示的なセマンティクスを以下に与える。
７．４．９．８ 変換木セマンティクス
ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇ［ｘ０］［ｙ０］［ｔｒａｆｏＤｅｐｔｈ］は、ブロックが変換コーディングのために、半分の水平方向のサイズと半分の垂直方向のサイズとを有する４つのブロックに分割されるかどうかを指定する。アレイインデックスｘ０、ｙ０は、ピクチャの左上ルーマサンプルに対する当該ブロックの左上ルーマサンプルのロケーション（ｘ０，ｙ０）を指定する。アレイインデックスｔｒａｆｏＤｅｐｔｈは、変換コーディングのために、ブロックへのコーディングブロックの現在の細分レベルを指定する。ｔｒａｆｏＤｅｐｔｈは、コーディングブロックに対応するブロックの場合、０に等しい。
Figure 2017512032
 変数ｉｎｔｅｒＳｐｌｉｔＦｌａｇは、次のように導出される。
− ｍａｘ＿ｔｒａｎｓｆｏｒｍ＿ｈｉｅｒａｒｃｈｙ＿ｄｅｐｔｈ＿ｉｎｔｅｒが０に等しく、ＣｕＰｒｅｄＭｏｄｅ［ｘ０］［ｙ０］がＭＯＤＥ＿ＩＮＴＥＲに等しく、ＰａｒｔＭｏｄｅがＰＡＲＴ＿２Ｎ×２Ｎに等しくなく、ｔｒａｆｏＤｅｐｔｈが０に等しい場合、ｉｎｔｅｒＳｐｌｉｔＦｌａｇは１に等しく設定される。
− 他の場合、ｉｎｔｅｒＳｐｌｉｔＦｌａｇは０に等しく設定される。
ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇ［ｘ０］［ｙ０］［ｔｒａｆｏＤｅｐｔｈ］が存在しないとき、次のように推測される。
− 次の条件のうちの１つまたは複数が真である場合、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇ［ｘ０］［ｙ０］［ｔｒａｆｏＤｅｐｔｈ］の値は１に等しいと推測される。
− ｌｏｇ２ＴｒａｆｏＳｉｚｅがＬｏｇ２ＭａｘＴｒａｆｏＳｉｚｅよりも大きい
− ＩｎｔｒａＳｐｌｉｔＦｌａｇが１に等しく、ｔｒａｆｏＤｅｐｔｈが０に等しい
− ｉｎｔｅｒＳｐｌｉｔＦｌａｇが１に等しい
− 他の場合、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇ［ｘ０］［ｙ０］［ｔｒａｆｏＤｅｐｔｈ］の値は０に等しいと推測される。
．．．
Ｉ．７．４．９．５．１ イントラモード拡張セマンティクス
変数Ｌｏｇ２ＭａｘＤｍｍＣｂＳｉｚｅは、５に等しく設定される。
１に等しいｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ［ｘ０］［ｙ０］は、ｄｅｐｔｈ＿ｉｎｔｒａ＿ｍｏｄｅ＿ｆｌａｇシンタックス要素が存在しないことと、０から３４までの範囲のｉｎｔｒａＰｒｅｄＭｏｄｅを伴うイントラモードが現在の予測ユニットのために使用されることとを指定する。０に等しいｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ［ｘ０］［ｙ０］は、ｄｅｐｔｈ＿ｉｎｔｒａ＿ｍｏｄｅ＿ｆｌａｇシンタックス要素が存在する可能性があることを指定する。存在しないとき、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ［ｘ０］［ｙ０］の値は１に等しいと推測される。
Figure 2017512032
 変数ＤｍｍＦｌａｇ［ｘ０］［ｙ０］は、下で指定されているように導出される。
DmmFlag[ x0 ][ y0 ] = !dim_not_present_flag[ x0 ][ y0 ] I-29)
．．．
[0233]上記で説明した実施形態では、エンコーダおよび／またはデコーダによって、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇ制限とｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ制限の両方が実施され得る。しかしながら、他の例では、エンコーダおよび／またはデコーダによって、制限のうちの一方は実施されるが、他方の制限は実施されないことがある。たとえば、エンコーダおよび／またはデコーダによって、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇ制限は実施されるが、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ制限は実施されないことがある。別の例として、エンコーダおよび／またはデコーダによって、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ制限は実施されるが、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇ制限は実施されないことがある。
[0234]第２の実施形態では、ＰＵのサイズが最大変換ブロックサイズよりも大きいことと、ＰＵに対応するＳＤＣフラグが０に等しいことの両方に該当する場合に、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは０になるように制限される。いくつかの例では、この実施形態のｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ制限は、第１の実施形態のｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇ制限とともに使用され得る。第２の実施形態についての例示的なセマンティクスを以下に与える。
Ｉ．７．４．９．５．１ イントラモード拡張セマンティクス
変数Ｌｏｇ２ＭａｘＤｍｍＣｂＳｉｚｅは、５に等しく設定される。
１に等しいｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ［ｘ０］［ｙ０］は、ｄｅｐｔｈ＿ｉｎｔｒａ＿ｍｏｄｅ＿ｆｌａｇシンタックス要素が存在しないことと、０から３４までの範囲のｉｎｔｒａＰｒｅｄＭｏｄｅを伴うイントラモードが現在の予測ユニットのために使用されることとを指定する。０に等しいｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ［ｘ０］［ｙ０］は、ｄｅｐｔｈ＿ｉｎｔｒａ＿ｍｏｄｅ＿ｆｌａｇシンタックス要素が存在する可能性があることを指定する。存在しないとき、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ［ｘ０］［ｙ０］の値は１に等しいと推測される。
Figure 2017512032
 変数ＤｍｍＦｌａｇ［ｘ０］［ｙ０］は、下で指定されているように導出される。
DmmFlag[ x0 ][ y0 ] = !dim_not_present_flag[ x0 ][ y0 ] (I-29)
．．．
[0235]第３の実施形態では、関連ＰＵがＤＭＭモードによりコーディングされる変換木ノードの場合、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇはシグナリングされない。ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇがシグナリングされないとき、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇは０であると推測される。また、第３の実施形態では、最大変換ブロックサイズよりも大きいサイズを有するＰＵの場合、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ［ｘ０］［ｙ０］はシグナリングされない。ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇがシグナリングされないとき、フラグは１であると推測される。第３の実施形態についての例示的なシンタックスを以下に与える。
７．３．８．８ 変換木シンタックス
Figure 2017512032
Figure 2017512032
 Ｉ．７．３．８．５．１ イントラモード拡張シンタックス
Figure 2017512032
[0236]上記で説明した実施形態では、エンコーダおよび／またはデコーダによって、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇシグナリング条件とｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇシグナリング条件の両方が実施され得る。しかしながら、他の例では、エンコーダおよび／またはデコーダによって、シグナリング条件のうちの一方は実施されるが、他方のシグナリング条件は実施されないことがある。たとえば、エンコーダおよび／またはデコーダによって、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇシグナリング条件は実施されるが、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇシグナリング条件は実施されないことがある。別の例として、エンコーダおよび／またはデコーダによって、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇシグナリング条件は実施されるが、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇシグナリング条件は実施されないことがある。
[0237]第４の実施形態では、ＰＵのサイズが最大変換ブロックサイズよりも大きいことと、ＰＵに対応するＳＤＣフラグが０に等しいことの両方に該当する場合に、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ［ｘ０］［ｙ０］はシグナリングされない。ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇがシグナリングされないとき、フラグは１であると推測される。いくつかの例では、この実施形態のｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇシグナリング条件は、第３の実施形態のｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇシグナリング条件とともに使用され得る。第４の実施形態についての例示的なシンタックスを以下に与える。
Ｉ．７．３．８．５．１ イントラモード拡張シンタックス
Figure 2017512032
[0238]図１１は、本開示による、制限付きビデオ符号化を実行するための例示的な技法を示す流れ図である。図１１に示されるように、ビデオエンコーダ２０は、変換木ノードに対応する深度予測ユニット（ＤＰＵ）が深度モデリングモード（ＤＭＭ）に従って予測されるかどうかに少なくとも部分的に基づいて、変換木ノードを複数のサブ変換木ノードに選択的に分割するか、または分割しない（２００）。コーディングユニット（ＣＵ）は、変換木ノードに対応するＤＰＵと変換木ノードの両方を備えることができる。すなわち、変換木ノードは一般に、ＤＰＵと同じＣＵに含まれ、（たとえば、テクスチャＣＵなどの）異なるＣＵには含まれないことを理解されたい。したがって、ＤＰＵおよび変換木ノードが同じＣＵ（たとえば、深度ＣＵ）に含まれるとき、および／または同じＣＵから導出されるときに、ＤＰＵは変換木ノードに対応すると言われることがある。
[0239]ビデオエンコーダ２０は、変換木ノードが複数のサブ変換木ノードに分割されるかどうかに基づいて、変換木ノードを符号化する（２０２）。いくつかの例では、変換木ノードを符号化するために、ビデオエンコーダ２０は、変換木ノードが複数のサブ変換木ノードに分割されない場合に、変換木ノードに対応する変換ユニットを符号化することがある。そのような例では、ビデオエンコーダ２０は、変換木ノードが複数のサブ変換木ノードに分割される場合に、変換木ノードに対応する変換ユニットを符号化せず、変換木ノードが複数のサブ変換木ノードに分割される場合に、変換木ノードを含む変換木構造のそれぞれのリーフノードに対応する変換ユニットを符号化することがある。ビデオエンコーダ２０は、符号化ビデオビットストリームがコード化変換木ノードを含むように符号化ビデオビットストリームを生成する（２０４）。
[0240]ＤＭＭモードは、深度予測ユニットが２つのサブ領域に区分される予測モードを指すことがあり、サブ領域の各々に関して、それぞれのサブ領域におけるサンプル（たとえば、ピクセル）のすべてが、同じ予測子値により予測される。言い換えれば、ＤＭＭモードに従って予測されるとき、深度予測ユニットの同じＤＭＭ区分されたサブ領域内のすべてのサンプル（たとえば、ピクセル）の予測値が、互いに等しくなり得る。一方、異なるサブ領域におけるサンプルの予測値は、互いに異なり得る。いくつかの例では、ＤＭＭモードは、ｗｅｄｇｅｌｅｔ区分ＤＭＭモードおよび輪郭区分ＤＭＭモードの一方または両方に対応し得る。
[0241]深度予測ユニットは、同じイントラ予測モードに従って予測されるビデオブロックを指し得る。深度予測ユニットのサンプルは、深度マップの深度値および／または深度マップの深度値を示す値に対応し得る。
[0242]いくつかの例では、変換木ノードを選択的に分割するか、または分割しないために、ビデオエンコーダ２０は、変換木ノードに対応する深度予測ユニットがＤＭＭに従って予測されるかどうかを決定し、深度予測ユニットがＤＭＭに従って予測されると決定したことに応答して、変換木ノードを複数のサブ変換木ノードに分割しないことがある。そのような例では、深度予測ユニットがＤＭＭに従って予測されないと決定したことに応答して、ビデオエンコーダ２０は、いくつかの例では、変換木ノードを複数のサブ変換木ノードに分割すること、または変換木ノードを複数のサブ変換木ノードに分割するかどうかを決定するための他の技法を使用することがある。
[0243]いくつかの例では、符号化ビデオビットストリームを生成することは、ビデオエンコーダ２０が、変換木ノードに対応する深度予測ユニットがＤＭＭに従って予測されるかどうかに基づいて、変換木ノードに関するシンタックス要素の値を選択し、符号化ビデオビットストリームがシンタックス要素の値をシグナリングするように符号化ビデオビットストリームを生成することができることを備える。シンタックス要素の値は、変換木ノードが複数のサブ変換木ノードに分割されるべきかどうかを示すことができる。いくつかの例では、符号化ビデオビットストリームは、３Ｄ−ＨＥＶＣ符号化ビデオビットストリームであり得、シンタックス要素は、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇシンタックス要素であり得る。
[0244]いくつかの例では、シンタックス要素の値を選択するために、ビデオエンコーダ２０は、変換木ノードに対応する深度予測ユニットがＤＭＭに従って予測されるときに、変換木ノードが複数のサブ変換木ノードに分割されるべきではないことを示す値を選択することができる。そのような例では、変換木ノードに対応する深度予測ユニットがＤＭＭに従って予測されないとき、ビデオエンコーダ２０は、いくつかの例では、変換木ノードが複数のサブ変換木ノードに分割されるべきであることを示す値を選択すること、および／または別の技法に基づく値を選択することができる。
[0245]いくつかの例では、符号化ビデオビットストリームを生成することは、ビデオエンコーダ２０が、符号化ビデオビットストリームがシンタックス要素を含むように符号化ビデオビットストリームを生成することを備える。さらなる例では、符号化ビデオビットストリームを生成するために、ビデオエンコーダ２０は、変換木ノードに対応する深度予測ユニットがＤＭＭに従って予測されるときに、符号化ビデオビットストリームがシンタックス要素を含まないように符号化ビデオビットストリームを生成することができる。そのような例では、ビデオエンコーダ２０は、いくつかの例では、変換木ノードに対応する深度予測ユニットがＤＭＭに従って予測されないときに、符号化ビデオビットストリームがシンタックス要素を含むように符号化ビデオビットストリームを生成することができる。
[0246]いくつかの例では、符号化ビデオビットストリームは、変換木ノードに対応する深度予測ユニットがＤＭＭに従って予測されるときに、変換木ノードが複数のサブ変換木ノードに分割されるべきではないことをシンタックス要素が示さなければならないことを指定する制限を満たすことができる。このようにして、単一の深度予測ユニットに関連付けられる変換ユニットの異なるサイズを有することは、ＤＭＭ予測モードに従って深度予測ユニットを予測するときに回避され得る。
[0247]図１２は、本開示による、制限付きビデオ復号を実行するための例示的な技法を示す流れ図である。図１２に示されるように、ビデオデコーダ３０は符号化ビデオビットストリームを受信する（２０６）。ビデオデコーダ３０は、符号化ビデオビットストリームによって表される変換木ノードを、変換木ノードに対応する深度予測ユニット（ＤＰＵ）が深度モデリングモード（ＤＭＭ）に従って予測されるかどうかに少なくとも部分的に基づいて、複数のサブ変換木ノードに選択的に分割するか、または分割しない（２０８）。ビデオデコーダ３０は、変換木ノードが複数のサブ変換木ノードに分割されるかどうかに少なくとも部分的に基づいて、変換木ノードを復号する（２１０）。
[0248]いくつかの例では、変換木ノードを選択的に分割するか、または分割しないために、ビデオデコーダ３０は、符号化ビデオビットストリームに基づいて、変換木ノードに関するシンタックス要素の値を決定し、シンタックス要素の値に基づいて、変換木ノードを複数のサブ変換木ノードに選択的に分割するか、または分割しないことがある。シンタックス要素の値は、変換木ノードが複数のサブ変換木ノードに分割されるべきかどうかを示すことができる。シンタックス要素の値は、変換木ノードに対応する深度予測ユニットがＤＭＭに従って予測されるかどうかに基づいて設定され得る。いくつかの例では、シンタックス要素の値は、エンコーダによって、変換木ノードに対応する深度予測ユニットがＤＭＭに従って予測されるかどうかに基づいて決定され得る。
[0249]そのような例では、ビデオデコーダ３０は、いくつかの例では、シンタックス要素の値が第１の値に等しい場合に、変換木ノードを複数のサブ変換木に分割することがあり、シンタックス要素の値が第１の値とは異なる第２の値に等しい場合に、変換木ノードを複数のサブ変換木に選択的に分割しないことがある。いくつかの例では、符号化ビデオビットストリームは、３Ｄ−ＨＥＶＣ符号化ビデオビットストリームであり得、シンタックス要素は、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇシンタックス要素である。
[0250]さらなる例では、シンタックス要素の値を決定するために、ビデオデコーダ３０は、符号化ビデオビットストリームからシンタックス要素のコード化バージョンを取得することができる。そのような例では、ビデオデコーダ３０は、シンタックス要素の値を取得するために、シンタックス要素のコード化バージョンを復号することができる。
[0251]追加の例では、シンタックス要素は、第２のシンタックス要素であり得る。そのような例では、シンタックス要素の値を決定するために、ビデオデコーダ３０は、第１のシンタックス要素の値を取得するために、符号化ビデオビットストリームから第１のシンタックス要素を復号することができる。第１のシンタックス要素の値は、深度予測ユニットがＤＭＭに従って予測されるかどうかを示すことができる。そのような例では、ビデオデコーダ３０は、第１のシンタックス要素の値に基づいて、符号化ビデオビットストリームから第２のシンタックス要素を取得および復号することなく、第２のシンタックス要素の値を推測値に等しく設定するかどうかを決定し、第１のシンタックス要素の値が、深度予測ユニットがＤＭＭに従って予測されることを示すと決定したことに応答して、第２のシンタックス要素の値を推測値に等しく設定することができる。推測値は、変換木ノードが複数のサブ変換木ノードに分割されるべきではないことを示し得る。いくつかの例では、符号化ビデオビットストリームは、３Ｄ−ＨＥＶＣ符号化ビデオビットストリームであり得、第１のシンタックス要素はｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇシンタックス要素であり、第２のシンタックス要素はｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇシンタックス要素である。
[0252]いくつかの例では、符号化ビデオビットストリームは、変換木ノードに対応する深度予測ユニットがＤＭＭに従って予測されるときに、変換木ノードが複数のサブ変換木ノードに分割されるべきではないことをシンタックス要素が示さなければならないことを指定する制限を満たすことができる。このようにして、単一の深度予測ユニットに関連付けられる変換ユニットの異なるサイズを有することは、ＤＭＭ予測モードに従って深度予測ユニットを予測するときに回避され得る。
[0253]いくつかの例では、変換木ノードを選択的に分割するか、または分割しないために、ビデオデコーダ３０は、深度予測ユニットがＤＭＭに従って予測されるときに、変換木ノードを複数のサブ変換木ノードに分割しないことがある。そのような例では、ビデオデコーダ３０は、いくつかの例では、深度予測ユニットがＤＭＭに従って予測されないときに、変換木ノードを複数のサブ変換木ノードに分割すること、または変換木ノードを分割するかどうかを決定するための何らかの他の技法を使用することがある。
[0254]いくつかの例では、変換木ノードを復号するために、ビデオデコーダ３０は、変換木ノードが複数のサブ変換木ノードに分割されない場合に、変換木ノードに対応する変換ユニットを復号することがある。そのような例では、ビデオデコーダ３０は、変換木ノードが複数のサブ変換木ノードに分割される場合に、変換木ノードに対応する変換ユニットを復号せず、変換木ノードが複数のサブ変換木ノードに分割される場合に、変換木ノードを含む変換木構造のそれぞれのリーフノードに対応する変換ユニットを復号することがある。
[0255]図１３は、本開示による、制限付きビデオ符号化を実行するための例示的な技法を示す流れ図である。いくつかの例では、図１３に示される技法は、図１１に示される処理ボックス２０２および／または２０４を実施するために使用され得る。
[0256]図１３に示されるように、ビデオエンコーダ２０は、変換木ノードに対応する深度予測ユニット（ＰＵ）の予測モードを決定する（２１２）。ビデオエンコーダ２０は、深度ＰＵがＤＭＭに従って予測されるかどうかを決定する（２１４）。深度ＰＵがＤＭＭに従って予測されると決定したことに応答して、ビデオエンコーダ２０は、変換木ノードを複数のサブ変換木ノードに分割しない（２１６）。深度ＰＵがＤＭＭに従って予測されないと決定したことに応答して、ビデオエンコーダ２０は、深度ＰＵがＤＭＭに従って予測されるかどうかに加えて他の基準に基づいて、変換木ノードを複数のサブ変換木ノードに分割するかどうかを決定する（２１８）。
[0257]いくつかの例では、他の基準は、少なくともいくつかの状況では変換木ノードが複数のサブ変換木ノードに分割されることを可能にし得る。さらなる例では、深度ＰＵがＤＭＭに従って予測されないと決定したことに応答して、ビデオエンコーダ２０は、変換木ノードを複数のサブ変換木ノードに分割することを決定し得る。
[0258]図１４は、本開示による、制限付きビデオ符号化を実行するための例示的な技法を示す流れ図である。いくつかの例では、図１４に示される技法は、図１１に示される処理ボックス２０２および／または２０４を実施するために使用され得る。
[0259]図１３に示されるように、ビデオエンコーダ２０は、変換木ノードに対応する深度予測ユニット（ＰＵ）の予測モードを決定する（２２０）。ビデオエンコーダ２０は、深度ＰＵがＤＭＭに従って予測されるかどうかを決定する（２２２）。深度ＰＵがＤＭＭに従って予測されると決定したことに応答して、ビデオエンコーダ２０は、変換木ノードが複数のサブ変換木ノードに分割されるべきではないことを示すために、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを０に設定する（２２４）。深度ＰＵがＤＭＭに従って予測されないと決定したことに応答して、ビデオエンコーダ２０は、深度ＰＵがＤＭＭに従って予測されるかどうかに加えて他の基準に基づいて、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値を決定する（２２６）。
[0260]いくつかの例では、他の基準は、少なくともいくつかの状況ではｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値が１に等しくなることを可能にし得る。さらなる例では、深度ＰＵがＤＭＭに従って予測されないと決定したことに応答して、ビデオエンコーダ２０は、変換木ノードが複数のサブ変換木ノードに分割されるべきであることを示すために、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値を１に設定することができる。
[0261]図１５は、本開示による、制限付きビデオ復号を実行するための例示的な技法を示す流れ図である。いくつかの例では、図１５に示される技法は、図１２に示される処理ボックス２０８および／または２１０を実施するために使用され得る。
[0262]図１５に示されるように、ビデオデコーダ３０は、符号化ビデオビットストリームからｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを取得する（２２８）。ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇは、変換木ノードに対応し得る。ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値は、ビデオエンコーダによって、変換木ノードに対応する深度ＰＵがＤＭＭに従って予測されるかどうかに基づいて選択され得る。
[0263]ビデオデコーダ３０は、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇが１に等しいかどうかを決定する（２３０）。言い換えれば、ビデオデコーダ３０は、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値が、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇに対応する変換木ノードが複数のサブ変換木ノードに分割されるべきであることを示すかどうかを決定する。
[0264]ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇが１に等しいと決定したことに応答して、ビデオデコーダ３０は、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇに対応する変換木ノードを複数のサブ変換木ノードに分割する（２３２）。ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇが１に等しくないと決定したことに応答して、ビデオデコーダ３０は、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇに対応する変換木ノードを複数のサブ変換木ノードに分割しない（２３４）。
[0265]やはり、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値は、ビデオエンコーダによって、変換木ノードに対応する深度ＰＵがＤＭＭに従って予測されるかどうかに基づいて選択され得る。したがって、一例として図１５に示される技法を使用することによって、ビデオデコーダ３０は、符号化ビデオビットストリームによって表される変換木ノードを、変換木ノードに対応する深度予測ユニットがＤＭＭに従って予測されるかどうかに基づいて、複数のサブ変換木ノードに選択的に分割するか、または分割しないことがある。
[0266]図１６は、本開示による、制限付きビデオ復号を実行するための別の例示的な技法を示す流れ図である。いくつかの例では、図１６に示される技法は、図１２に示される処理ボックス２０８および／または２１０を実施するために使用され得る。
[0267]図１６に示されるように、ビデオデコーダ３０は、変換木ノードに対応する深度予測ユニット（ＰＵ）の予測モードを決定する（２３６）。たとえば、ビデオデコーダ３０は、シンタックス要素の値を取得するために、符号化ビットストリームからシンタックス要素を復号することができ、この場合、第１のシンタックス要素の値は、深度予測ユニットがＤＭＭに従って予測されるかどうかを示す。いくつかの例では、シンタックス要素は、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇシンタックス要素であり得る。
[0268]ビデオデコーダ３０は、深度ＰＵがＤＭＭに従って予測されるかどうかを決定する（２３８）。深度ＰＵがＤＭＭに従って予測されると決定したことに応答して、ビデオデコーダ３０は、符号化ビデオビットストリームからｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを取得および復号することなく、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇが０に等しいと推測する（２４０）。代替的に、ビデオデコーダ３０は、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値を実際に推測することなく、深度ＰＵに対応する変換ユニットが分割されないと推測し得る。０のｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇは、変換木ノードが複数のサブ変換木ノードに分割されるべきではないことを示す。深度ＰＵがＤＭＭに従って予測されないと決定したことに応答して、ビデオデコーダ３０は、深度ＰＵがＤＭＭに従って予測されるかどうかに加えて他の基準に基づいて、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値を決定する（２４２）。いくつかの例では、深度ＰＵがＤＭＭに従って予測されないとき、ビデオデコーダ３０は、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値を決定するために、符号化ビデオビットストリームからｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇを解析し復号することができる。
[0269]やはり、ｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値は、ビデオエンコーダによって、変換木ノードに対応する深度ＰＵがＤＭＭに従って予測されるかどうかに基づいて選択され得る。したがって、一例としてｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇの値を推測／取得するために図１６に示される技法を使用することによって、ビデオデコーダ３０は、符号化ビデオビットストリームによって表される変換木ノードを、変換木ノードに対応する深度予測ユニットがＤＭＭに従って予測されるかどうかに基づいて、複数のサブ変換木ノードに選択的に分割するか、または分割しないことがある。
[0270]図１７は、本開示による、制限付きビデオ符号化を実行するための例示的な技法を示す流れ図である。図１７に示されるように、ビデオエンコーダ２０は、深度予測ユニットのサイズ（ＤＰＵ＿ＳＩＺＥ）が深度予測ユニットのために指定された最大変換ブロックサイズ（ＭＡＸ＿ＴＢ＿ＳＩＺＥ）よりも大きいかどうかに少なくとも部分的に基づいて、深度モデリングモード（ＤＭＭ）予測モードまたは非ＤＭＭ予測モードに従って深度予測ユニット（ＤＰＵ）を選択的に予測する（２４４）。ビデオエンコーダ２０は、深度予測ユニットを、予測される深度予測ユニットに少なくとも部分的に基づいて符号化する（２４６）。ビデオエンコーダ２０は、符号化ビデオビットストリームがコード化深度予測ユニットを含むように符号化ビデオビットストリームを生成する（２４８）。
[0271]いくつかの例では、深度予測ユニットを選択的に予測するために、ビデオエンコーダ２０は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうかを決定し、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいと決定したことに応答して、非ＤＭＭ予測モードに従って深度予測ユニットを予測することができる。そのような例では、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きくないと決定したことに応答して、ビデオエンコーダ２０は、ＤＭＭ予測モードに従って深度予測ユニットを予測すること、および／またはＤＭＭ予測モードを使用するかどうかを決定するための別の技法を使用することができる。
[0272]さらなる例では、深度予測ユニットを選択的に予測するために、ビデオエンコーダ２０は、深度予測ユニットの残差がＳＤＣモードに従ってコーディングされるかどうかを決定することもできる。言い換えれば、ビデオエンコーダ２０は、深度予測ユニットの残差をコーディングするために変換木構造が使用されるかどうかを決定することができる。そのような例では、ビデオエンコーダ２０は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうか、および深度予測ユニットの残差がＳＤＣモードに従ってコーディングされるかどうかに少なくとも部分的に基づいて、ＤＭＭ予測モードまたは非ＤＭＭ予測モードに従って深度予測ユニットを選択的に予測することができる。
[0273]たとえば、ビデオエンコーダ２０は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいと決定し、深度予測ユニットの残差がＳＤＣモードに従ってコーディングされないと決定したことに応答して、非ＤＭＭ予測モードに従って深度予測ユニットを予測することができる。そのような例では、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きくないと決定したか、または深度予測ユニットの残差がＳＤＣモードに従ってコーディングされると決定したことに応答して、ビデオエンコーダ２０は、ＤＭＭ予測モードに従って深度予測ユニットを予測すること、および／またはＤＭＭ予測モードを使用するかどうかを決定するための別の技法を使用することができる。
[0274]いくつかの例では、符号化ビデオビットストリームを生成するために、ビデオエンコーダ２０は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうかに基づいて、深度予測ユニットに関するシンタックス要素の値を選択し、符号化ビデオビットストリームがシンタックス要素の値をシグナリングするように符号化ビデオビットストリームを生成することができる。シンタックス要素の値は、深度予測ユニットがＤＭＭ予測モードに従って予測されるべきかどうかを示すことができる。いくつかの例では、符号化ビデオビットストリームは、３次元高効率ビデオコーディング（３２Ｄ−ＨＥＶＣ）符号化ビデオビットストリームであり、シンタックス要素は、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇシンタックス要素である。
[0275]いくつかの例では、シンタックス要素の値を選択するために、ビデオエンコーダ２０は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいときに、深度予測ユニットがＤＭＭ予測モードに従って予測されるべきではないことを示す値を選択することができる。そのような例では、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きくないときに、ビデオエンコーダ２０は、深度予測ユニットがＤＭＭ予測モードに従って予測されるべきであることを示す値を選択すること、および／または少なくともいくつかの状況では深度予測ユニットがＤＭＭ予測モードに従って予測されるべきであることを可能にするシンタックス要素の値を選択するための別の技法を使用することができる。
[0276]さらなる例では、ビデオエンコーダ２０は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうか、および深度予測ユニットの残差がＳＤＣモードに従ってコーディングされるかどうかに少なくとも部分的に基づいて、深度予測ユニットに関するシンタックス要素の値を選択することができる。そのような例では、ビデオエンコーダ２０は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きく、深度予測ユニットの残差がＳＤＣモードに従ってコーディングされないときに、深度予測ユニットがＤＭＭ予測モードに従って予測されるべきではないことを示す値を選択することができる。そのような例では、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きくないか、または深度予測ユニットの残差がＳＤＣモードに従ってコーディングされるときに、ビデオエンコーダ２０は、深度予測ユニットがＤＭＭ予測モードに従って予測されるべきであることを示す値を選択すること、および／または少なくともいくつかの状況では深度予測ユニットがＤＭＭ予測モードに従って予測されるべきであることを可能にするシンタックス要素の値を選択するための別の技法を使用することができる。
[0277]いくつかの例では、符号化ビデオビットストリームを生成するために、ビデオエンコーダ２０は、符号化ビデオビットストリームがシンタックス要素を含むように符号化ビデオビットストリームを生成することができる。さらなる例では、符号化ビデオビットストリームを生成するために、ビデオエンコーダ２０は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいときに、符号化ビデオビットストリームがシンタックス要素を含まないように符号化ビデオビットストリームを生成することができる。そのような例では、ビデオエンコーダ２０は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きくないときに、符号化ビデオビットストリームがシンタックス要素を含むように符号化ビデオビットストリームを生成することができる。
[0278]追加の例では、符号化ビデオビットストリームを生成するために、ビデオエンコーダ２０は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きく、深度予測ユニットの残差がＳＤＣモードに従ってコーディングされないときに、符号化ビデオビットストリームがシンタックス要素を含まないように符号化ビデオビットストリームを生成することができる。そのような例では、ビデオエンコーダ２０は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きくないか、または深度予測ユニットの残差がＳＤＣモードに従ってコーディングされるときに、符号化ビデオビットストリームがシンタックス要素を含むように符号化ビデオビットストリームを生成することができる。
[0279]いくつかの例では、符号化ビデオビットストリームは、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいときに、深度予測ユニットがＤＭＭモードに従って予測されるべきではないことをシンタックス要素が示さなければならないことを指定する制限を満たすことができる。このようにして、ＤＭＭに従って深度予測ユニットを予測することは、変換ユニットが深度予測ユニットよりも小さいときに回避され得る。
[0280]さらなる例では、符号化ビデオビットストリームは、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいことと、深度予測ユニットの残差がＳＤＣモードに従ってコーディングされないことの両方に該当するときに、深度予測ユニットがＤＭＭモードに従って予測されるべきではないことをシンタックス要素が示さなければならないことを指定する制限を満たすことができる。
[0281]いくつかの例では、深度予測ユニットを符号化するために、ビデオエンコーダ２０は、深度予測ユニットに対応する１つまたは複数の残差変換ユニットを、予測される深度予測ユニットに基づいて生成することができる。
[0282]図１８は、本開示による、制限付きビデオ復号を実行するための例示的な技法を示す流れ図である。図１８に示されるように、ビデオデコーダ３０は符号化ビデオビットストリームを受信する（２５０）。ビデオデコーダ３０は、深度予測ユニットのサイズ（ＤＰＵ＿ＳＩＺＥ）が深度予測ユニットのために指定された最大変換ブロックサイズ（ＭＡＸ＿ＴＢ＿ＳＩＺＥ）よりも大きいかどうかに基づいて、深度モデリングモード（ＤＭＭ）予測モードまたは非ＤＭＭ予測モードに従って深度予測ユニット（ＤＰＵ）を選択的に予測する（２５２）。ビデオデコーダ３０は、深度予測ユニットを、予測される深度予測ユニットに基づいて復号する（２５４）。
[0283]いくつかの例では、深度予測ユニットを選択的に予測するために、ビデオデコーダ３０は、符号化ビデオビットストリームに基づいて、深度予測ユニットに関するシンタックス要素の値を決定し、シンタックス要素の値に基づいて、ＤＭＭ予測モードまたは非ＤＭＭ予測モードに従って深度予測ユニットを選択的に予測することができる。シンタックス要素の値は、深度予測ユニットがＤＭＭ予測モードに従って予測されるべきかどうかを示すことができる。
[0284]シンタックス要素の値は、いくつかの例では、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうかに基づいて設定され得る。さらなる例では、シンタックス要素の値は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうか、および深度予測ユニットの残差がＳＤＣモードに従ってコーディングされるかどうかに基づいて設定され得る。いくつかの例では、シンタックス要素の値は、エンコーダによって、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうか、および／または深度予測ユニットの残差がＳＤＣモードに従ってコーディングされるかどうかに基づいて決定され得る。
[0285]いくつかの例では、ビデオデコーダ３０は、いくつかの例では、シンタックス要素の値が第１の値に等しい場合に、ＤＭＭ予測モードに従って深度予測ユニットを予測し、非ＤＭＭ予測モードに従って深度予測ユニットを予測することができる。いくつかの例では、符号化ビデオビットストリームは、３Ｄ−ＨＥＶＣ符号化ビデオビットストリームであり得、シンタックス要素は、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇシンタックス要素である。
[0286]さらなる例では、深度予測ユニットを選択的に予測するために、ビデオデコーダ３０は、深度予測ユニットの残差がＳＤＣモードに従ってコーディングされるかどうかを決定することもできる。言い換えれば、ビデオデコーダ３０は、深度予測ユニットの残差をコーディングするために変換木構造が使用されるかどうかを決定することができる。そのような例では、ビデオデコーダ３０は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうか、および深度予測ユニットの残差がＳＤＣコーディングモードに従ってコーディングされるかどうかに少なくとも部分的に基づいて、ＤＭＭ予測モードまたは非ＤＭＭ予測モードに従って深度予測ユニットを選択的に予測することができる。
[0287]たとえば、ビデオデコーダ３０は、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きく、深度予測ユニットの残差がＳＤＣモードに従ってコーディングされないときに、非ＤＭＭ予測モードに従って深度予測ユニットを予測することができる。そのような例では、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きくないと決定したか、または深度予測ユニットの残差がＳＤＣモードに従ってコーディングされると決定したことに応答して、ビデオデコーダ３０は、ＤＭＭ予測モードに従って深度予測ユニットを予測すること、および／またはＤＭＭ予測モードを使用するかどうかを決定するための別の技法を使用することができる。
[0288]いくつかの例では、符号化ビデオビットストリームは、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいときに、深度予測ユニットがＤＭＭモードに従って予測されるべきではないことをシンタックス要素が示さなければならないことを指定する制限を満たすことができる。このようにして、ＤＭＭに従って深度予測ユニットを予測することは、変換ユニットが深度予測ユニットよりも小さいときに回避され得る。
[0289]さらなる例では、符号化ビデオビットストリームは、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいとき、および深度予測ユニットの残差がＳＤＣモードに従ってコーディングされないときに、深度予測ユニットがＤＭＭモードに従って予測されるべきではないことをシンタックス要素が示さなければならないことを指定する制限を満たすことができる。
[0290]いくつかの例では、シンタックス要素の値を決定するために、ビデオデコーダ３０は、符号化ビデオビットストリームからシンタックス要素のコード化バージョンを取得することができる。そのような例では、ビデオデコーダ３０は、シンタックス要素の値を取得するために、シンタックス要素のコード化バージョンを復号することができる。
[0291]さらなる例では、シンタックス要素の値を決定するために、ビデオデコーダ３０は、符号化ビデオビットストリームに基づいて、深度予測ユニットのサイズと深度予測ユニットに対応する最大変換ブロックサイズとを決定し、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいかどうかに基づいて、符号化ビデオビットストリームからシンタックス要素を取得および復号することなく、シンタックス要素の値を推測値に等しく設定するかどうかを決定し、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいと決定したことに応答して、シンタックス要素の値を推測値に等しく設定することができる。推測値は、深度予測ユニットがＤＭＭ予測モードに従って予測されるべきではないことを示すことができる。いくつかの例では、ビデオデコーダ３０は、符号化ビデオビットストリームにおける１つまたは複数のシンタックス要素に基づいて、深度予測ユニットのサイズと最大変換ブロックサイズとを決定することができる。
[0292]いくつかの例では、ビデオデコーダ３０は、また、深度予測ユニットの残差がＳＤＣモードに従ってコーディングされるかどうかし得る。そのような例では、ビデオデコーダ３０は、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいかどうか、および深度予測ユニットの残差がＳＤＣモードに従ってコーディングされるかどうかに少なくとも部分的に基づいて、符号化ビデオビットストリームからシンタックス要素を取得および復号することなく、シンタックス要素の値を推測値に等しく設定するかどうかを決定し、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいと決定し、深度予測ユニットの残差がＳＤＣモードに従ってコーディングされないと決定したことに応答して、シンタックス要素の値を推測値に等しく設定することができる。そのような例では、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きくないか、または深度予測ユニットの残差がＳＤＣモードに従ってコーディングされるときに、ビデオデコーダ３０は、シンタックス要素の値を推測せず、ビットストリームからシンタックス要素の値を取得すること、および／または他の基準に基づいてシンタックス要素の値を推測するかどうかを決定することができる。
[0293]いくつかの例では、深度予測ユニットを選択的に予測することは、ビデオデコーダ３０が、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きいときに、非ＤＭＭ予測モードに従って深度予測ユニットを予測することができることを備える。そのような例では、深度予測ユニットのサイズが深度予測ユニットに対応する最大変換ブロックサイズよりも大きくないときに、ビデオデコーダ３０は、ＤＭＭ予測モードに従って深度予測ユニットを予測すること、またはＤＭＭ予測モードに従って深度予測ユニットを予測するかどうかを決定するための別の予測モード選択技法を使用することができる。
[0294]いくつかの例では、深度予測ユニットを復号するために、ビデオデコーダ３０は、深度予測ユニットに対応する１つまたは複数の再構築された変換ユニットを、予測される深度予測ユニットおよび１つまたは複数の残差変換ユニットに基づいて生成することができる。
[0295]図１９は、本開示による、制限付きビデオ符号化を実行するための例示的な技法を示す流れ図である。いくつかの例では、図１９に示される技法は、図１７に示される処理ボックス２４６および／または２４８を実施するために使用され得る。
[0296]図１９に示されるように、ビデオエンコーダ２０は、深度予測ユニットのサイズ（ＤＰＵ＿ＳＩＺＥ）と深度予測ユニットのために指定された最大変換ブロックサイズ（ＭＡＸ＿ＴＢ＿ＳＩＺＥ）とを決定する（２５６）。ビデオエンコーダ２０は、深度予測ユニットのサイズ（ＤＰＵ＿ＳＩＺＥ）が深度予測ユニットのために指定された最大変換ブロックサイズ（ＭＡＸ＿ＴＢ＿ＳＩＺＥ）よりも大きいかどうかを決定する（２５８）。ＤＰＵ＿ＳＩＺＥがＭＡＸ＿ＴＢ＿ＳＩＺＥよりも大きい、ビデオエンコーダ２０は、非ＤＭＭ予測モードに従って深度ＰＵを予測する（２６０）。ＤＰＵ＿ＳＩＺＥがＭＡＸ＿ＴＢ＿ＳＩＺＥよりも大きくないと決定したことに応答して、ビデオエンコーダ２０は、ＤＰＵ＿ＳＩＺＥがＭＡＸ＿ＴＢ＿ＳＩＺＥよりも大きいかどうかに加えて他の基準に基づいて、深度ＰＵのための予測モード（たとえば、予測モードがＤＭＭ予測モードか、それとも非ＤＭＭ予測モードか）を選択する（２６２）。
[0297]いくつかの例では、他の基準は、深度ＰＵのための予測モードがＤＭＭ予測モードであることを可能にし得る。さらなる例では、ＤＰＵ＿ＳＩＺＥがＭＡＸ＿ＴＢ＿ＳＩＺＥよりも大きくないと決定したことに応答して、ビデオエンコーダ２０は、深度ＰＵを予測するためのＤＭＭ予測モードを選択することができる。
[0298]図２０は、本開示による、制限付きビデオ符号化を実行するための例示的な技法を示す流れ図である。いくつかの例では、図２０に示される技法は、図１７に示される処理ボックス２４６および／または２４８を実施するために使用され得る。
[0299]図２０に示されるように、ビデオエンコーダ２０は、深度予測ユニットのサイズ（ＤＰＵ＿ＳＩＺＥ）と深度予測ユニットのために指定された最大変換ブロックサイズ（ＭＡＸ＿ＴＢ＿ＳＩＺＥ）とを決定する（２６４）。ビデオエンコーダ２０は、深度予測ユニットのサイズ（ＤＰＵ＿ＳＩＺＥ）が深度予測ユニットのために指定された最大変換ブロックサイズ（ＭＡＸ＿ＴＢ＿ＳＩＺＥ）よりも大きいかどうかを決定する（２６６）。ＤＰＵ＿ＳＩＺＥがＭＡＸ＿ＴＢ＿ＳＩＺＥよりも大きいと決定したことに応答して、ビデオエンコーダ２０は、ＤＭＭ予測モードが対応する深度ＰＵにスースしない（not sues for）ことを示すために、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを１に等しく設定する（２６８）。ＤＰＵ＿ＳＩＺＥがＭＡＸ＿ＴＢ＿ＳＩＺＥよりも大きくないと決定したことに応答して、ビデオエンコーダ２０は、ＤＰＵ＿ＳＩＺＥがＭＡＸ＿ＴＢ＿ＳＩＺＥよりも大きいかどうかに加えて他の基準に基づいて、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値を決定する（２７０）。
[0300]いくつかの例では、他の基準は、少なくともいくつかの状況ではｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値が０に等しくなることを可能にし得る。さらなる例では、深度ＰＵがＤＭＭに従って予測されないと決定したことに応答して、ビデオエンコーダ２０は、深度ＰＵを予測するためにＤＭＭ予測モードが使用されるべきではないことを示すために、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値を０に等しく設定することができる。
[0301]図２１は、本開示による、制限付きビデオ復号を実行するための例示的な技法を示す流れ図である。いくつかの例では、図２１に示される技法は、図１８に示される処理ボックス２５２および／または２５４を実施するために使用され得る。
[0302]図２１に示されるように、ビデオデコーダ３０は、符号化ビデオビットストリームからｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを取得する（２７２）。ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、深度予測ユニットに対応し得る。ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値は、ビデオエンコーダによって、深度予測ユニットのサイズ（ＤＰＵ＿ＳＩＺＥ）が深度予測ユニットのために指定された最大変換ブロックサイズ（ＭＡＸ＿ＴＢ＿ＳＩＺＥ）よりも大きいかどうかに基づいて選択され得る。
[0303]ビデオデコーダ３０は、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが１に等しいかどうかを決定する（２７４）。言い換えれば、ビデオデコーダ３０は、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値が、深度ＰＵを予測するために非ＤＭＭモードが使用されるべきであることを示すかどうかを決定する。ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが１に等しいと決定したことに応答して、ビデオデコーダ３０は、非ＤＭＭ予測モード（たとえば、正規ＨＥＶＣ予測モードのうちの１つ）に従って深度ＰＵを予測する（２７６）。ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが１に等しくないと決定したことに応答して、ビデオデコーダ３０は、ＤＭＭ予測モードに従って深度ＰＵを予測する（２７８）。
[0304]やはり、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値は、ビデオエンコーダによって、深度予測ユニットのサイズ（ＤＰＵ＿ＳＩＺＥ）が深度予測ユニットのために指定された最大変換ブロックサイズ（ＭＡＸ＿ＴＢ＿ＳＩＺＥ）よりも大きいかどうかに基づいて選択され得る。したがって、一例として図２１に示される技法を使用することによって、ビデオデコーダ３０は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうかに基づいて、深度モデリングモード（ＤＭＭ）予測モードまたは非ＤＭＭ予測モードに従って深度予測ユニットを選択的に予測することができる。
[0305]図２２は、本開示による、制限付きビデオ復号を実行するための別の例示的な技法を示す流れ図である。いくつかの例では、図２２に示される技法は、図１８に示される処理ボックス２５２および／または２５４を実施するために使用され得る。
[0306]図２２に示されるように、ビデオデコーダ３０は、深度予測ユニットのサイズ（ＤＰＵ＿ＳＩＺＥ）と深度予測ユニットのために指定された最大変換ブロックサイズ（ＭＡＸ＿ＴＢ＿ＳＩＺＥ）とを決定する（２８０）。ビデオデコーダ３０は、深度予測ユニットのサイズ（ＤＰＵ＿ＳＩＺＥ）が深度予測ユニットのために指定された最大変換ブロックサイズ（ＭＡＸ＿ＴＢ＿ＳＩＺＥ）よりも大きいかどうかを決定する（２８２）。ＤＰＵ＿ＳＩＺＥがＭＡＸ＿ＴＢ＿ＳＩＺＥよりも大きいと決定したことに応答して、ビデオデコーダ３０は、符号化ビデオビットストリームからｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを取得および復号することなく、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが１に等しいと推測する（２８４）。１のｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ値は、深度予測ユニットが非ＤＭＭ予測モードに従って予測されるべきであることを示す。ＤＰＵ＿ＳＩＺＥがＭＡＸ＿ＴＢ＿ＳＩＺＥよりも大きくないと決定したことに応答して、ビデオデコーダ３０は、ＤＰＵ＿ＳＩＺＥがＭＡＸ＿ＴＢ＿ＳＩＺＥよりも大きいかどうかに加えて他の基準に基づいて、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値を決定する（２８６）。いくつかの例では、ＤＰＵ＿ＳＩＺＥがＭＡＸ＿ＴＢ＿ＳＩＺＥよりも大きくなく、ビデオデコーダ３０は、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値を決定するために、符号化ビデオビットストリームからｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇを解析し復号することができる。
[0307]やはり、ｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値は、ビデオエンコーダによって、深度予測ユニットのサイズ（ＤＰＵ＿ＳＩＺＥ）が深度予測ユニットのために指定された最大変換ブロックサイズ（ＭＡＸ＿ＴＢ＿ＳＩＺＥ）よりも大きいかどうかに基づいて選択され得る。したがって、一例としてｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値を推測／取得するために図２２に示される技法を使用することによって、ビデオデコーダ３０は、深度予測ユニットのサイズが深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうかに基づいて、深度モデリングモード（ＤＭＭ）予測モードまたは非ＤＭＭ予測モードに従って深度予測ユニットを選択的に予測することができる。
[0308]図２３は、本開示による、ビデオをコーディングするための例示的な技法を示す流れ図である。ビデオエンコーダ２０および／またはビデオデコーダ３０は、深度予測ユニットのための予測モードを取得／決定する（２８８）。ビデオエンコーダ２０および／またはビデオデコーダ３０はさらに、予測モードがＤＭＭ予測モード（たとえば、ＤＭＭモード１、ＤＭＭモード４、ｗｄｇｅｌｅｔ ＤＭＭモード、または輪郭ＤＭＭモード）であるかどうかを決定する（２９０）。
[0309]予測モードがＤＭＭ予測モードであると決定したことに応答して、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＰＵレベルで深度予測ユニット全体を予測し（２９２）、ＰＵを形成するＴＵの残差サンプル値に基づいて、ＰＵのサンプルを再構築する（２９４）。ＰＵレベルでＰＵを予測することは、ＰＵに含まれ得る複数のＴＵに別個に予測演算を適用するのではなく、ＰＵを予測するために単一の予測演算が実行されるように、ＰＵ全体に予測演算を適用することを指し得る。いくつかの例では、ＰＵ全体がＰＵレベルで予測されるとき、ＰＵに関する予測されるサンプルは、ＰＵのＴＵのうちのいずれかの再構築されたサンプル値に依存しないことがある。
[0310]予測モードがＤＭＭモードではないと決定したことに応答して、ビデオエンコーダ２０および／またはビデオデコーダ３０は、コーディング順序（たとえば、復号順序）でＰＵのＴＵの各々を予測し再構築することができる。言い換えれば、ＰＵはＴＵレベルで予測され得る。いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＴＵの各々を別個に予測し再構築することができる。ＴＵレベルでＰＵを予測することは、ＰＵのＴＵの各々に、ＴＵごとに１つの予測演算が実行されるように、予測演算を適用することを指し得る。言い換えれば、予測演算の異なるインスタンスがＰＵのＴＵごとに実行される。いくつかの例では、ＰＵがＴＵレベルで予測されるとき、ＰＵに関する予測されるサンプルは、ＰＵの１つまたは複数のＴＵの再構築されたサンプル値に依存し得る。言い換えれば、ＰＵがＴＵレベルで予測されるとき、ＰＵのＴＵに関する予測されるサンプルは、ＰＵに関する１つまたは複数の以前再構築されたＴＵの再構築されたサンプル値に依存し得る。ＴＵレベルでＰＵを再構築することは、ＰＵのＴＵの各々に、ＴＵごとに１つの再構築動作が実行されるように、再構築動作を適用することを指し得る。
[0311]いくつかの例では、ＰＵ全体がＰＵレベルで予測されるとき、ビデオエンコーダ２０および／またはビデオデコーダ３０は、深度予測ユニットの任意の再構築されたサンプル値を決定するより前に、深度予測ユニットのすべてのサンプルを予測することができる。いくつかの例では、ＰＵがＴＵレベルで予測されるとき、ビデオエンコーダ２０および／またはビデオデコーダ３０は、深度予測ユニットのサンプルのうちの１つまたは複数を予測するより前に、深度予測ユニットの１つまたは複数の再構築されたサンプル値を決定することができる。
[0312]いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、深度モデリングモード（ＤＭＭ）に従って（１つまたは複数の変換ユニットを含む（あるいは１つまたは複数の変換ユニットに対応する）ことがある）深度予測ユニットを予測するかどうかを決定し（２９０）、深度予測ユニットがＤＭＭに従って予測されるべきではないときに、ある変換ユニットレベルおよびあるコーディング順序で深度予測ユニットの変換ユニットの各々を予測し再構築し（２９６）、深度予測ユニットがＤＭＭに従って予測されるべきであるときに、ある予測ユニットレベルで深度予測ユニットのすべてのサンプルを予測する（２９２）ことができる。
[0313]いくつかの例では、変換ユニットの各々を予測し再構築することは、深度予測ユニットのサンプルのうちの１つまたは複数を予測するより前に、深度予測ユニットの１つまたは複数の再構築されたサンプル値を決定することを含み得る。いくつかの例では、深度予測ユニットのすべてのサンプルを予測することは、深度予測ユニットの任意の再構築されたサンプル値を決定するより前に、深度予測ユニットのすべてのサンプルを予測することを含み得る。
[0314]いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、深度予測ユニットがＤＭＭに従って予測されるべきではないときに、深度予測ユニットの再構築されたサンプルを生成するために、深度予測ユニットの予測サンプルに深度予測ユニットの変換ユニットの残差サンプルを加算することができる。さらなる例では、ビデオエンコーダ２０は、深度予測ユニットがＤＭＭに従って予測されるべきではないときに、深度予測ユニットの残差サンプルを生成するために、深度予測ユニットの予測サンプルに深度予測ユニットの変換ユニットのサンプルを加算することができる。
[0315]いくつかの例では、ＤＭＭ予測モードが使用されるとき、ＰＵ（たとえば、深度ＰＵ）がＰＵレベルで予測され再構築され得る。たとえば、ＰＵは隣接サンプルを使用して予測され得、次いで、変換木から復号された残差が、ＰＵを再構築するために予測サンプルに加算され得る。いくつかの例では、ＰＵ（たとえば、深度ＰＵ）に関連付けられる変換木は、複数のサブ変換木ノードに分割され得る（すなわち、ＰＵは複数のＴｕに対応する）。そのような例では、ＤＭＭ予測モードが使用されないとき、ＴＵは、いくつかの例では、コーディング順序（たとえば、Ｚオーダー）で予測され再構築され得る。すなわち、ＰＵは、ＴＵレベルで予測され再構築される。ＰＵは、コーディングブロックの領域を指し得る。領域は、コーディングブロックの１つもしくは複数のサンプル（たとえば、ピクセル）を含むこと、および／またはこれらのサンプルに対応することがある。
[0316]いくつかの例では、本開示の技法は、ＴＵに関して知られたＤＭＭ予測パターンを作り、それによってＤＭＭコード化ＰＵを復号可能にすることができる。さらなる例では、本開示の技法は、３Ｄ−ＨＥＶＣにおける変換木構造設計をＨＥＶＣにおける変換木構造設計と同じままにすることができる。
[0317]本開示で説明された様々なコーディング技法は、ビデオエンコーダ２０（図２および図９）ならびに／またはビデオデコーダ３０（図２および図１０）によって実施されてよく、ビデオエンコーダ２０とビデオデコーダ３０の両方が全般にビデオコーダと呼ばれ得る。加えて、ビデオコーディングは、一般に、適用可能な場合、ビデオ符号化および／またはビデオ復号を指す場合がある。
[0318]本開示の技法は全般に３Ｄ−ＨＥＶＣに関して説明されたが、本技法はこのように限定されない。上記で説明された技法は、３Ｄビデオコーディングのための他の現在の規格または将来の規格にも適用可能であり得る。たとえば、エントロピーコーディングのための本開示で説明された技法は、たとえば３Ｄビデオコーディングまたは他の用途のために、深度区分のための深度イントラモードのコーディングを伴う他の現在のまたは将来の規格にも適用可能であり得る。
[0319]１つまたは複数の例では、本明細書で説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せに実装される場合がある。ソフトウェアに実装される場合、機能は、１つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶されるか、またはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行される場合がある。コンピュータ可読媒体は、データ記憶媒体のような有形媒体に対応するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含み得る。このようにして、コンピュータ可読媒体は、一般に、（１）非一時的である有形のコンピュータ可読記憶媒体、または（２）信号もしくは搬送波などの通信媒体に相当する場合がある。データ記憶媒体は、本開示で説明された技法の実装のために命令、コードおよび／またはデータ構造を取り出すために、１つもしくは複数のコンピュータまたは１つもしくは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
[0320]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭもしくは他の光ディスクストレージ、磁気ディスクストレージ、もしくは他の磁気ストレージデバイス、フラッシュメモリ、または、命令もしくはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を備え得る。また、任意の接続は、コンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、ウェブサイト、サーバ、または他のリモートソースから、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに、非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用されるディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）およびＢｌｕ−ｒａｙ（登録商標）ディスク（disc）を含み、ディスク（disk）は通常、データを磁気的に再生し、一方、ディスク（disc）はデータをレーザーで光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲の中に含まれるべきである。
[0321]命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、または他の等価な集積回路もしくはディスクリート論理回路のような、１つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または、本明細書で説明された技法の実装に好適な任意の他の構造のいずれかを指し得る。加えて、いくつかの態様では、本明細書で説明された機能は、符号化および復号のために構成されるか、または複合コーデックに組み込まれる、専用のハードウェアモジュールおよび／またはソフトウェアモジュール内で提供される場合がある。また、本技法は、１つまたは複数の回路または論理素子において完全に実装され得る。
[0322]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）、またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置において実施される場合がある。様々な構成要素、モジュール、またはユニットは、開示された技法を実行するように構成されたデバイスの機能的態様を強調するように本開示において説明されているが、様々なハードウェアユニットによる実現を必ずしも必要としない。むしろ、上記で説明されたように、様々なユニットは、コーデックハードウェアユニット内で組み合わされるか、または適切なソフトウェアおよび／もしくはファームウェアとともに、上記で説明された１つもしくは複数のプロセッサを含む、相互動作可能なハードウェアユニットの集合体によって提供される場合がある。
[0323]様々な実施例について説明した。これらおよび他の実施例は、特許請求の範囲内にある。

Claims (74)

  1. ビデオ復号の方法であって、
    符号化ビデオビットストリームの変換木ノードを、前記変換木ノードに対応する深度予測ユニットが深度モデリングモード（ＤＭＭ）に従って予測されるかどうかに少なくとも部分的に基づいて、複数のサブ変換木ノードに選択的に分割するか、または分割しないことと、
    前記変換木ノードが前記複数のサブ変換木ノードに分割されるかどうかに少なくとも部分的に基づいて、前記変換木ノードを復号することと
    を備える方法。
  2. 前記変換木ノードを選択的に分割するか、または分割しないことは、
    前記符号化ビデオビットストリームに少なくとも部分的に基づいて、前記変換木ノードに関するシンタックス要素の値を決定することと、ここにおいて、前記シンタックス要素の前記値は、前記変換木ノードが前記複数のサブ変換木ノードに分割されるべきかどうかを示し、前記シンタックス要素の前記値は、前記変換木ノードに対応する前記深度予測ユニットが前記ＤＭＭに従って予測されるかどうかに少なくとも部分的に基づいて設定される、
    前記シンタックス要素の前記値に少なくとも部分的に基づいて、前記変換木ノードを前記複数のサブ変換木ノードに選択的に分割するか、または分割しないことと
    を備える、請求項１に記載の方法。
  3. 前記符号化ビデオビットストリームは３次元高効率ビデオコーディング（３Ｄ−ＨＥＶＣ）符号化ビデオビットストリームを備え、前記シンタックス要素はｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇシンタックス要素を備える、請求項２に記載の方法。
  4. 前記符号化ビデオビットストリームは、前記変換木ノードに対応する前記深度予測ユニットが前記ＤＭＭに従って予測されるときに、前記変換木ノードが前記複数のサブ変換木ノードに分割されるべきではないことを前記シンタックス要素が示さなければならないことを指定する制限を満たす、請求項２および３のいずれかに記載の方法。
  5. 前記シンタックス要素の前記値を決定することは、
    前記符号化ビデオビットストリームから前記シンタックス要素のコード化バージョンを取得することと、
    前記シンタックス要素の前記値を取得するために、前記シンタックス要素の前記コード化バージョンを復号することと
    を備える、請求項２から４のいずれかに記載の方法。
  6. 前記シンタックス要素は第２のシンタックス要素であり、前記シンタックス要素の前記値を決定することは、
    第１のシンタックス要素の値を取得するために、前記符号化ビットストリームから前記第１のシンタックス要素を復号することと、ここにおいて、前記第１のシンタックス要素の前記値は、前記深度予測ユニットが前記ＤＭＭに従って予測されるかどうかを示す、
    前記第１のシンタックス要素の前記値に少なくとも部分的に基づいて、前記符号化ビデオビットストリームから前記第２のシンタックス要素を取得および復号することなく、前記第２のシンタックス要素の前記値を推測値に等しく設定するかどうかを決定することと、ここにおいて、前記推測値は、前記変換木ノードが前記複数のサブ変換木ノードに分割されるべきではないことを示す、
    前記深度予測ユニットが前記ＤＭＭに従って予測されることを前記第１のシンタックス要素の前記値が示すと決定したことに応答して、前記第２のシンタックス要素の前記値を前記推測値に等しく設定することと
    を備える、請求項２から４のいずれかに記載の方法。
  7. 前記第１のシンタックス要素はｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇシンタックス要素である、請求項６に記載の方法。
  8. 前記変換木ノードを選択的に分割するか、または分割しないことは、
    前記深度予測ユニットが前記ＤＭＭに従って予測されるときに、前記変換木ノードを前記複数のサブ変換木ノードに分割しないこと
    を備える、請求項１から７のいずれかに記載の方法。
  9. 前記変換木ノードを復号することは、
    前記変換木ノードが前記複数のサブ変換木ノードに分割されない場合に、前記変換木ノードに対応する変換ユニットを復号することと、
    前記変換木ノードが前記複数のサブ変換木ノードに分割される場合に、前記変換木ノードを含む変換木構造のそれぞれのリーフノードに対応する変換ユニットを復号することと
    を備える、請求項１から８のいずれかに記載の方法。
  10. ビデオ符号化の方法であって、
    変換木ノードに対応する深度予測ユニットが深度モデリングモード（ＤＭＭ）に従って予測されるかどうかに少なくとも部分的に基づいて、前記変換木ノードを複数のサブ変換木ノードに選択的に分割するか、または分割しないことと、
    前記変換木ノードが前記複数のサブ変換木ノードに分割されるかどうかに少なくとも部分的に基づいて、前記変換木ノードを符号化することと、
    前記符号化ビデオビットストリームが前記コード化変換木ノードを含むように前記符号化ビデオビットストリームを生成することと
    を備える方法。
  11. 前記変換木ノードを選択的に分割するか、または分割しないことは、
    前記変換木ノードに対応する前記深度予測ユニットが前記ＤＭＭに従って予測されるかどうかを決定することと、
    前記深度予測ユニットが前記ＤＭＭに従って予測されると決定したことに応答して、前記変換木ノードを複数のサブ変換木ノードに分割しないことと
    を備える、請求項１０に記載の方法。
  12. 前記符号化ビデオビットストリームを生成することは、
    前記変換木ノードに対応する前記深度予測ユニットが前記ＤＭＭに従って予測されるかどうかに少なくとも部分的に基づいて、前記変換木ノードに関するシンタックス要素の値を選択することと、ここにおいて、前記シンタックス要素の前記値は、前記変換木ノードが前記複数のサブ変換木ノードに分割されるべきかどうかを示す、
    前記符号化ビデオビットストリームが前記シンタックス要素の前記値をシグナリングするように前記符号化ビデオビットストリームを生成することと
    を備える、請求項１０および１１のいずれかに記載の方法。
  13. 前記シンタックス要素の前記値を選択することは、
    前記変換木ノードに対応する前記深度予測ユニットが前記ＤＭＭに従って予測されるときに、前記変換木ノードが前記複数のサブ変換木ノードに分割されるべきではないことを示す値を選択すること
    を備える、請求項１２に記載の方法。
  14. 前記符号化ビデオビットストリームを生成することは、
    前記符号化ビデオビットストリームが前記シンタックス要素を含むように前記符号化ビデオビットストリームを生成すること
    を備える、請求項１２および１３のいずれかに記載の方法。
  15. 前記符号化ビデオビットストリームを生成することは、
    前記変換木ノードに対応する前記深度予測ユニットが前記ＤＭＭに従って予測されるときに、前記符号化ビデオビットストリームが前記シンタックス要素を含まないように前記符号化ビデオビットストリームを生成すること
    を備える、請求項１２および１３のいずれかに記載の方法。
  16. 前記符号化ビデオビットストリームは３次元高効率ビデオコーディング（３Ｄ−ＨＥＶＣ）符号化ビデオビットストリームを備え、前記シンタックス要素はｓｐｌｉｔ＿ｔｒａｎｓｆｏｒｍ＿ｆｌａｇシンタックス要素を備える、請求項１２から１５のいずれかに記載の方法。
  17. 前記符号化ビデオビットストリームは、前記変換木ノードに対応する前記深度予測ユニットが前記ＤＭＭに従って予測されるときに、前記変換木ノードが複数のサブ変換木ノードに分割されるべきではないことを前記シンタックス要素が示さなければならないことを指定する制限を満たす、請求項１２から１６のいずれかに記載の方法。
  18. 前記変換木ノードを符号化することは、
    前記変換木ノードが前記複数のサブ変換木ノードに分割されない場合に、前記変換木ノードに対応する変換ユニットを符号化することと、
    前記変換木ノードが前記複数のサブ変換木ノードに分割される場合に、前記変換木ノードを含む変換木構造のそれぞれのリーフノードに対応する変換ユニットを符号化することと
    を備える、請求項１０から１７のいずれかに記載の方法。
  19. ビデオコーディング装置であって、
    ビデオデータを記憶するメモリと、
    請求項１から１８のいずれかに記載の方法を実行するように構成された１つまたは複数のプロセッサを備えるビデオコーダと
    を備えるビデオコーディング装置。
  20. 実行時に、１つまたは複数のプロセッサに請求項１から１８のいずれかに記載の方法を実行させる命令を記憶したコンピュータ可読媒体。
  21. 請求項１から１８のいずれかに記載の方法を実行するための手段を備えるビデオコーディング装置。
  22. ビデオ復号の方法であって、
    深度予測ユニットのサイズが前記深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうかに少なくとも部分的に基づいて、深度モデリングモード（ＤＭＭ）予測モードまたは非ＤＭＭ予測モードに従って前記深度予測ユニットを選択的に予測することと、
    前記深度予測ユニットを、前記予測された深度予測ユニットに少なくとも部分的に基づいて復号することと
    を備える方法。
  23. 前記深度予測ユニットを選択的に予測することは、
    前記符号化ビデオビットストリームに少なくとも部分的に基づいて、前記深度予測ユニットに関するシンタックス要素の値を決定することと、ここにおいて、前記シンタックス要素の前記値は、前記深度予測ユニットが前記ＤＭＭ予測モードに従って予測されるべきかどうかを示し、前記シンタックス要素の前記値は、前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいかどうかに少なくとも部分的に基づいて設定される、
    前記シンタックス要素の前記値に少なくとも部分的に基づいて、前記ＤＭＭ予測モードまたは前記非ＤＭＭ予測モードに従って前記深度予測ユニットを選択的に予測することと
    を備える、請求項２２に記載の方法。
  24. 前記符号化ビデオビットストリームは３次元高効率ビデオコーディング（３Ｄ−ＨＥＶＣ）符号化ビデオビットストリームを備え、前記シンタックス要素はｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇシンタックス要素を備える、請求項２３に記載の方法。
  25. 前記符号化ビデオビットストリームは、前記深度予測ユニットの前記サイズが前記深度予測ユニットに対応する前記最大変換ブロックサイズよりも大きいときに、前記深度予測ユニットが前記ＤＭＭモードに従って予測されるべきではないことを前記シンタックス要素が示さなければならないことを指定する制限を満たす、請求項２３および２４のいずれかに記載の方法。
  26. 前記シンタックス要素の前記値を決定することは、
    前記符号化ビデオビットストリームから前記シンタックス要素のコード化バージョンを取得すること、
    前記シンタックス要素の前記値を取得するために、前記シンタックス要素の前記コード化バージョンを復号することと
    を備える、請求項２３から２５のいずれかに記載の方法。
  27. 前記シンタックス要素の前記値を決定することは、
    前記符号化ビデオビットストリームに少なくとも部分的に基づいて、深度予測ユニットのサイズと前記深度予測ユニットに対応する最大変換ブロックサイズとを決定することと、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットに対応する前記最大変換ブロックサイズよりも大きいかどうかに少なくとも部分的に基づいて、前記符号化ビデオビットストリームから前記シンタックス要素を取得および復号することなく、前記シンタックス要素の前記値を推測値に等しく設定するかどうかを決定することと、ここにおいて、前記推測値は、前記深度予測ユニットが前記ＤＭＭ予測モードに従って予測されるべきではないことを示す、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットに対応する前記最大変換ブロックサイズよりも大きいと決定したことに応答して、前記シンタックス要素の前記値を前記推測値に等しく設定することと
    を備える、請求項２３から２５のいずれかに記載の方法。
  28. 前記深度予測ユニットを選択的に予測することは、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットに対応する前記最大変換ブロックサイズよりも大きいときに、非ＤＭＭ予測モードに従って前記深度予測ユニットを予測すること
    を備える、請求項２２から２７のいずれかに記載の方法。
  29. 前記深度予測ユニットを選択的に予測することは、
    前記深度予測ユニットのサイズが前記深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうか、および前記深度予測ユニットの残差がセグメントごとのＤＣ（ＳＤＣ）コーディングモードに従ってコーディングされるかどうかに少なくとも部分的に基づいて、前記ＤＭＭ予測モードまたは前記非ＤＭＭ予測モードに従って前記深度予測ユニットを選択的に予測すること
    を備える、請求項２２に記載の方法。
  30. 前記深度予測ユニットを選択的に予測することは、
    前記符号化ビデオビットストリームに少なくとも部分的に基づいて、前記深度予測ユニットに関するシンタックス要素の値を決定することと、ここにおいて、前記シンタックス要素の前記値は、前記深度予測ユニットが前記ＤＭＭ予測モードに従って予測されるべきかどうかを示し、前記シンタックス要素の前記値は、前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいかどうか、および前記深度予測ユニットの前記残差が前記ＳＤＣモードに従ってコーディングされるかどうかに少なくとも部分的に基づいて設定される、
    前記シンタックス要素の前記値に少なくとも部分的に基づいて、前記ＤＭＭ予測モードまたは前記非ＤＭＭ予測モードに従って前記深度予測ユニットを選択的に予測することと
    を備える、請求項２９に記載の方法。
  31. 前記符号化ビデオビットストリームは３次元高効率ビデオコーディング（３Ｄ−ＨＥＶＣ）符号化ビデオビットストリームを備え、前記シンタックス要素はｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇシンタックス要素を備える、請求項３０に記載の方法。
  32. 前記符号化ビデオビットストリームは、前記深度予測ユニットの前記サイズが前記深度予測ユニットに対応する前記最大変換ブロックサイズよりも大きいとき、および前記深度予測ユニットの前記残差が前記ＳＤＣモードに従ってコーディングされないときに、前記深度予測ユニットが前記ＤＭＭモードに従って予測されるべきではないことを前記シンタックス要素が示さなければならないことを指定する制限を満たす、請求項３０および３１のいずれかに記載の方法。
  33. 前記シンタックス要素の前記値を決定することは、
    前記符号化ビデオビットストリームから前記シンタックス要素のコード化バージョンを取得すること、
    前記シンタックス要素の前記値を取得するために、前記シンタックス要素の前記コード化バージョンを復号することと
    を備える、請求項３０から３２のいずれかに記載の方法。
  34. 前記シンタックス要素の前記値を決定することは、
    前記符号化ビデオビットストリームに少なくとも部分的に基づいて、深度予測ユニットのサイズ、前記深度予測ユニットに対応する最大変換ブロックサイズを決定し、前記深度予測ユニットの前記残差が前記ＳＤＣモードに従ってコーディングされるかどうかを決定することと、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットに対応する前記最大変換ブロックサイズよりも大きいかどうか、および前記深度予測ユニットの前記残差が前記ＳＤＣモードに従ってコーディングされるかどうかに少なくとも部分的に基づいて、前記符号化ビデオビットストリームから前記シンタックス要素を取得および復号することなく、前記シンタックス要素の前記値を推測値に等しく設定するかどうかを決定することと、ここにおいて、前記推測値は、前記深度予測ユニットが前記ＤＭＭ予測モードに従って予測されるべきではないことを示す、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットに対応する前記最大変換ブロックサイズよりも大きいと決定し、前記深度予測ユニットの前記残差が前記ＳＤＣモードに従ってコーディングされないと決定したことに応答して、前記シンタックス要素の前記値を前記推測値に等しく設定することと
    を備える、請求項３０から３２のいずれかに記載の方法。
  35. 前記深度予測ユニットを選択的に予測することは、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットに対応する前記最大変換ブロックサイズよりも大きく、前記深度予測ユニットの前記残差が前記ＳＤＣモードに従ってコーディングされないときに、非ＤＭＭ予測モードに従って前記深度予測ユニットを予測すること
    を備える、請求項２９から３４のいずれかに記載の方法。
  36. 前記深度予測ユニットを復号することは、
    前記深度予測ユニットに対応する１つまたは複数の再構築された変換ユニットを、前記予測された深度予測ユニットおよび１つまたは複数の残差変換ユニットに少なくとも部分的に基づいて生成すること
    を備える、請求項２２から３５のいずれかに記載の方法。
  37. ビデオ符号化の方法であって、
    深度予測ユニットのサイズが前記深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうかに少なくとも部分的に基づいて、深度モデリングモード（ＤＭＭ）予測モードまたは非ＤＭＭ予測モードに従って前記深度予測ユニットを選択的に予測することと、
    前記深度予測ユニットを、前記予測された深度予測ユニットに少なくとも部分的に基づいて符号化することと、
    前記符号化ビデオビットストリームが前記コード化深度予測ユニットを含むように前記符号化ビデオビットストリームを生成することと
    を備える方法。
  38. 前記深度予測ユニットを選択的に予測することは、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいかどうかを決定することと、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいと決定したことに応答して、非ＤＭＭ予測モードに従って前記深度予測ユニットを予測することと
    を備える、請求項３７に記載の方法。
  39. 前記符号化ビデオビットストリームを生成することは、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいかどうかに少なくとも部分的に基づいて、前記深度予測ユニットに関するシンタックス要素の値を選択することと、ここにおいて、前記シンタックス要素の前記値は、前記深度予測ユニットが前記ＤＭＭ予測モードに従って予測されるべきかどうかを示す、
    前記符号化ビデオビットストリームが前記シンタックス要素の前記値をシグナリングするように前記符号化ビデオビットストリームを生成することと
    を備える、請求項３７および３８のいずれかに記載の方法。
  40. 前記シンタックス要素の前記値を選択することは、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいときに、前記深度予測ユニットが前記ＤＭＭ予測モードに従って予測されるべきではないことを示す値を選択すること
    を備える、請求項３９に記載の方法。
  41. 前記符号化ビデオビットストリームを生成することは、
    前記符号化ビデオビットストリームが前記シンタックス要素を含むように前記符号化ビデオビットストリームを生成すること
    を備える、請求項３９および４０のいずれかに記載の方法。
  42. 前記符号化ビデオビットストリームを生成することは、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいときに、前記符号化ビデオビットストリームが前記シンタックス要素を含まないように前記符号化ビデオビットストリームを生成すること
    を備える、請求項３９および４０のいずれかに記載の方法。
  43. 前記符号化ビデオビットストリームは３次元高効率ビデオコーディング（３Ｄ−ＨＥＶＣ）符号化ビデオビットストリームを備え、前記シンタックス要素はｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇシンタックス要素を備える、請求項３９から４２のいずれかに記載の方法。
  44. 前記符号化ビデオビットストリームは、前記深度予測ユニットの前記サイズが前記深度予測ユニットに対応する前記最大変換ブロックサイズよりも大きいときに、前記深度予測ユニットが前記ＤＭＭモードに従って予測されるべきではないことを前記シンタックス要素が示さなければならないことを指定する制限を満たす、請求項３９から４３のいずれかに記載の方法。
  45. 前記深度予測ユニットを選択的に予測することは、
    深度予測ユニットのサイズが前記深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうか、および前記深度予測ユニットの残差がＳＤＣモードに従ってコーディングされるかどうかに少なくとも部分的に基づいて、前記ＤＭＭ予測モードまたは前記非ＤＭＭ予測モードに従って前記深度予測ユニットを選択的に予測すること
    を備える、請求項３７に記載の方法。
  46. 前記深度予測ユニットを選択的に予測することは、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいかどうかを決定することと、
    前記深度予測ユニットの前記残差が前記ＳＤＣモードに従ってコーディングされるかどうかを決定することと、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいと決定し、前記深度予測ユニットの前記残差が前記ＳＤＣモードに従ってコーディングされないと決定したことに応答して、非ＤＭＭ予測モードに従って前記深度予測ユニットを予測することと
    を備える、請求項４５に記載の方法。
  47. 前記符号化ビデオビットストリームを生成することは、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいかどうか、および前記深度予測ユニットの前記残差が前記ＳＤＣモードに従ってコーディングされるかどうかに少なくとも部分的に基づいて、前記深度予測ユニットに関するシンタックス要素の値を選択することと、ここにおいて、前記シンタックス要素の前記値は、前記深度予測ユニットが前記ＤＭＭ予測モードに従って予測されるべきかどうかを示す、
    前記符号化ビデオビットストリームが前記シンタックス要素の前記値をシグナリングするように前記符号化ビデオビットストリームを生成することと
    を備える、請求項４５および４６のいずれかに記載の方法。
  48. 前記シンタックス要素の前記値を選択することは、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きく、前記深度予測ユニットの前記残差が前記ＳＤＣモードに従ってコーディングされないときに、前記深度予測ユニットが前記ＤＭＭ予測モードに従って予測されるべきではないことを示す値を選択すること
    を備える、請求項４７に記載の方法。
  49. 前記符号化ビデオビットストリームを生成することは、
    前記符号化ビデオビットストリームが前記シンタックス要素を含むように前記符号化ビデオビットストリームを生成すること
    を備える、請求項４７および４８のいずれかに記載の方法。
  50. 前記符号化ビデオビットストリームを生成することは、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいことと、前記深度予測ユニットの前記残差が前記ＳＤＣモードに従ってコーディングされないこととの両方に該当するときに、前記符号化ビデオビットストリームが前記シンタックス要素を含まないように前記符号化ビデオビットストリームを生成すること
    を備える、請求項４７および４８のいずれかに記載の方法。
  51. 前記符号化ビデオビットストリームは３次元高効率ビデオコーディング（３Ｄ−ＨＥＶＣ）符号化ビデオビットストリームを備え、前記シンタックス要素はｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇシンタックス要素を備える、請求項４７から５０のいずれかに記載の方法。
  52. 前記符号化ビデオビットストリームは、前記深度予測ユニットの前記サイズが前記深度予測ユニットに対応する前記最大変換ブロックサイズよりも大きいことと、前記深度予測ユニットの前記残差が前記ＳＤＣモードに従ってコーディングされないこととの両方に該当するときに、前記深度予測ユニットが前記ＤＭＭモードに従って予測されるべきではないことを前記シンタックス要素が示さなければならないことを指定する制限を満たす、請求項４７から５１のいずれかに記載の方法。
  53. 前記深度予測ユニットを符号化することは、
    前記深度予測ユニットに対応する１つまたは複数の残差変換ユニットを、前記予測された深度予測ユニットに少なくとも部分的に基づいて生成すること
    を備える、請求項３７から５２のいずれかに記載の方法。
  54. ビデオ符号化の方法であって、
    深度予測ユニットのサイズが前記深度予測ユニットのために指定された最大変換ブロックサイズよりも大きいかどうかに少なくとも部分的に基づいて、深度モデリングモード（ＤＭＭ）予測モードまたは非ＤＭＭ予測モードに従って前記深度予測ユニットを選択的に予測することと、
    前記深度予測ユニットを、前記予測された深度予測ユニットに少なくとも部分的に基づいて符号化することと、
    前記符号化ビデオビットストリームが前記コード化深度予測ユニットを含むように前記符号化ビデオビットストリームを生成することと
    を備える方法。
  55. 前記深度予測ユニットを選択的に予測することは、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいかどうかを決定することと、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいと決定したことに応答して、非ＤＭＭ予測モードに従って前記深度予測ユニットを予測することと
    を備える、請求項５４に記載の方法。
  56. 前記符号化ビデオビットストリームを生成することは、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいかどうかに少なくとも部分的に基づいて、前記深度予測ユニットに関するシンタックス要素の値を選択することと、ここにおいて、前記シンタックス要素の前記値は、前記深度予測ユニットが前記ＤＭＭ予測モードに従って予測されるべきかどうかを示す、
    前記符号化ビデオビットストリームが前記シンタックス要素の前記値をシグナリングするように前記符号化ビデオビットストリームを生成することと
    を備える、請求項５４および５５のいずれかに記載の方法。
  57. 前記シンタックス要素の前記値を選択することは、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいときに、前記深度予測ユニットが前記ＤＭＭ予測モードに従って予測されるべきではないことを示す値を選択すること
    を備える、請求項５６に記載の方法。
  58. 前記符号化ビデオビットストリームを生成することは、
    前記符号化ビデオビットストリームが前記シンタックス要素を含むように前記符号化ビデオビットストリームを生成すること
    を備える、請求項５６および５７のいずれかに記載の方法。
  59. 前記符号化ビデオビットストリームを生成することは、
    前記深度予測ユニットの前記サイズが前記深度予測ユニットのために指定された前記最大変換ブロックサイズよりも大きいときに、前記符号化ビデオビットストリームが前記シンタックス要素を含まないように前記符号化ビデオビットストリームを生成すること
    を備える、請求項５６および５７のいずれかに記載の方法。
  60. 前記符号化ビデオビットストリームは３次元高効率ビデオコーディング（３Ｄ−ＨＥＶＣ）符号化ビデオビットストリームを備え、前記シンタックス要素はｄｉｍ＿ｎｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇシンタックス要素を備える、請求項５６から５９のいずれかに記載の方法。
  61. 前記符号化ビデオビットストリームは、前記深度予測ユニットの前記サイズが前記深度予測ユニットに対応する前記最大変換ブロックサイズよりも大きいときに、前記深度予測ユニットが前記ＤＭＭモードに従って予測されるべきではないことを前記シンタックス要素が示さなければならないことを指定する制限を満たす、請求項５６から６０のいずれかに記載の方法。
  62. ビデオコーディング装置であって、
    ビデオデータを記憶するメモリと、
    請求項２２から６１のいずれかに記載の方法を実行するように構成された１つまたは複数のプロセッサを備えるビデオコーダと
    を備えるビデオコーディング装置。
  63. 実行時に、１つまたは複数のプロセッサに請求項２２から６１のいずれかに記載の方法を実行させる命令を記憶したコンピュータ可読媒体。
  64. 請求項２２から６１のいずれかに記載の方法を実行するための手段を備えるビデオコーディング装置。
  65. ビデオ復号の方法であって、
    深度モデリングモード（ＤＭＭ）に従って深度予測ユニットを予測するかどうかを決定することであって、前記深度予測ユニットが１つまたは複数の変換ユニットを含む、決定することと、
    前記深度予測ユニットが前記ＤＭＭに従って予測されるべきではないときに、変換ユニットレベルおよびコーディング順序で、前記深度予測ユニットの前記変換ユニットの各々を予測し再構築することと、
    前記深度予測ユニットが前記ＤＭＭに従って予測されるべきであるときに、予測ユニットレベルで、前記深度予測ユニットのすべてのサンプルを予測することと
    を備える方法。
  66. 前記変換ユニットの各々を予測し再構築することは、前記深度予測ユニットの前記サンプルのうちの１つまたは複数を予測するより前に、前記深度予測ユニットの１つまたは複数の再構築されたサンプル値を決定することを備え、
    前記深度予測ユニットのすべてのサンプルを予測することは、前記深度予測ユニットの任意の再構築されたサンプル値を決定するより前に、前記深度予測ユニットのすべてのサンプルを予測することを備える、請求項６５に記載の方法。
  67. 前記深度予測ユニットが前記ＤＭＭに従って予測されるべきではないときに、前記深度予測ユニットの再構築されたサンプルを生成するために、前記深度予測ユニットの予測サンプルに前記変換ユニットの残差サンプルを加算すること
    をさらに備える、請求項６５および６６のいずれかに記載の方法。
  68. ビデオ符号化の方法であって、
    深度モデリングモード（ＤＭＭ）に従って深度予測ユニットを予測するかどうかを決定することであって、前記深度予測ユニットが１つまたは複数の変換ユニットを含む、決定することと、
    前記深度予測ユニットが前記ＤＭＭに従って予測されるべきではないときに、変換ユニットレベルおよびコーディング順序で、前記深度予測ユニットの前記変換ユニットの各々を予測し再構築することと、
    前記深度予測ユニットが前記ＤＭＭに従って予測されるべきであるときに、予測ユニットレベルで、前記深度予測ユニットのすべてのサンプルを予測することと
    を備える方法。
  69. 前記変換ユニットの各々を予測し再構築することは、前記深度予測ユニットの前記サンプルのうちの１つまたは複数を予測するより前に、前記深度予測ユニットの１つまたは複数の再構築されたサンプル値を決定することを備え、
    前記深度予測ユニットのすべてのサンプルを予測することは、前記深度予測ユニットが前記ＤＭＭに従って予測されるときに、前記深度予測ユニットの任意の再構築されたサンプル値を決定するより前に、前記深度予測ユニットのすべてのサンプルを予測することを備える、請求項６８に記載の方法。
  70. 前記深度予測ユニットが前記ＤＭＭに従って予測されるべきであるときに、前記深度予測ユニットの再構築されたサンプルを生成するために、前記深度予測ユニットの予測サンプルに前記変換ユニットの残差サンプルを加算すること
    をさらに備える、請求項６８および６９のいずれかに記載の方法。
  71. 前記深度予測ユニットが前記ＤＭＭに従って予測されるべきではないときに、前記深度予測ユニットの残差サンプルを生成するために、前記深度予測ユニットの予測サンプルに前記変換ユニットのサンプルを加算すること
    をさらに備える、請求項６８から７０のいずれかに記載の方法。
  72. ビデオコーディング装置であって、
    ビデオデータを記憶するメモリと、
    請求項６９から７１のいずれかに記載の方法を実行するように構成された１つまたは複数のプロセッサを備えるビデオコーダと
    を備えるビデオコーディング装置。
  73. 実行時に、１つまたは複数のプロセッサに請求項６９から７１のいずれかに記載の方法を実行させる命令を記憶したコンピュータ可読媒体。
  74. 請求項６９から７１のいずれかに記載の方法を実行するための手段を備えるビデオコーディング装置。
JP2016556742A 2014-03-13 2014-03-13 ３ｄビデオコーディングのための制限付き深度イントラモードコーディング Expired - Fee Related JP6445039B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2014/073346 WO2015135169A1 (en) 2014-03-13 2014-03-13 Constrained depth intra mode coding for 3d video coding

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2018222236A Division JP2019050621A (ja) 2018-11-28 2018-11-28 ３ｄビデオコーディングのための制限付き深度イントラモードコーディング

Publications (2)

Publication Number Publication Date
JP2017512032A true JP2017512032A (ja) 2017-04-27
JP6445039B2 JP6445039B2 (ja) 2018-12-26

Family

ID=54070801

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016556742A Expired - Fee Related JP6445039B2 (ja) 2014-03-13 2014-03-13 ３ｄビデオコーディングのための制限付き深度イントラモードコーディング

Country Status (7)

Country Link
US (1) US10687079B2 (ja)
EP (1) EP3117616A4 (ja)
JP (1) JP6445039B2 (ja)
KR (1) KR20160132891A (ja)
CN (1) CN106105216A (ja)
CA (1) CA2939170A1 (ja)
WO (1) WO2015135169A1 (ja)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015139203A1 (en) 2014-03-18 2015-09-24 Mediatek Singapore Pte. Ltd. Dlt signaling in 3d video coding
US9955187B2 (en) * 2014-03-28 2018-04-24 University-Industry Cooperation Group Of Kyung Hee University Method and apparatus for encoding of video using depth information
JP6308449B2 (ja) * 2014-06-26 2018-04-11 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 高効率ビデオ符号化における演算負荷を低減するための方法および装置
US10244256B2 (en) * 2014-10-08 2019-03-26 Sharp Kabushiki Kaisha Image decoding device
US11223852B2 (en) 2016-03-21 2022-01-11 Qualcomm Incorporated Coding video data using a two-level multi-type-tree framework
US20180176582A1 (en) * 2016-12-21 2018-06-21 Qualcomm Incorporated Low-complexity sign prediction for video coding
US10848788B2 (en) * 2017-01-06 2020-11-24 Qualcomm Incorporated Multi-type-tree framework for video coding
CN118042129A (zh) * 2017-11-16 2024-05-14 松下电器（美国）知识产权公司 图像编码装置、编码方法、图像解码装置、解码方法和非暂时性存储介质
WO2019131807A1 (en) * 2017-12-29 2019-07-04 Sharp Kabushiki Kaisha Systems and methods for partitioning video blocks for video coding
CN111771377A (zh) 2018-01-30 2020-10-13 松下电器（美国）知识产权公司 编码装置、解码装置、编码方法和解码方法
WO2019189279A1 (en) * 2018-03-30 2019-10-03 Sharp Kabushiki Kaisha Systems and methods for partitioning video blocks at a boundary of a picture for video coding
MX2020012071A (es) * 2018-05-17 2021-02-09 Ericsson Telefon Ab L M Desbloqueo de limites implicitos de la unidad de transformacion.
WO2019234612A1 (en) * 2018-06-05 2019-12-12 Beijing Bytedance Network Technology Co., Ltd. Partition tree with four sub-blocks symmetric or asymmetric
AU2018217333A1 (en) * 2018-08-17 2020-03-05 Canon Kabushiki Kaisha Method, apparatus and system for encoding and decoding a transformed block of video samples
CN112840655B (zh) * 2018-10-08 2023-12-01 寰发股份有限公司 图像与视频编解码中最后有效系数的编解码方法及装置
WO2020167097A1 (ko) * 2019-02-15 2020-08-20 엘지전자 주식회사 영상 코딩 시스템에서 인터 예측을 위한 인터 예측 타입 도출
US11159795B2 (en) * 2019-03-04 2021-10-26 Tencent America LLC Max transform size control
BR112021017428A2 (pt) * 2019-03-08 2021-11-16 Beijing Bytedance Network Tech Co Ltd Método de processamento de dados de vídeo, aparelho para processamento de dados de vídeo e meios de armazenamento e de gravação não transitórios legíveis por computador
WO2020198061A1 (en) * 2019-03-22 2020-10-01 Futurewei Technologies, Inc. Transform unit partition method for video coding
US11109041B2 (en) * 2019-05-16 2021-08-31 Tencent America LLC Method and apparatus for video coding
CN114097228B (zh) 2019-06-04 2023-12-15 北京字节跳动网络技术有限公司 具有几何分割模式编解码的运动候选列表
CN117395397A (zh) 2019-06-04 2024-01-12 北京字节跳动网络技术有限公司 使用临近块信息的运动候选列表构建
US11190777B2 (en) * 2019-06-30 2021-11-30 Tencent America LLC Method and apparatus for video coding
CN114175636B (zh) 2019-07-14 2024-01-12 北京字节跳动网络技术有限公司 自适应参数集中的自适应环路滤波的指示
US11317090B2 (en) * 2019-08-12 2022-04-26 Tencent America LLC Method and apparatus for video coding
WO2021027925A1 (en) 2019-08-14 2021-02-18 Beijing Bytedance Network Technology Co., Ltd. Position-dependent intra prediction sample filtering
CN114287133A (zh) 2019-08-14 2022-04-05 北京字节跳动网络技术有限公司 帧内模式中的预测样点滤波的加权因子
WO2021057996A1 (en) 2019-09-28 2021-04-01 Beijing Bytedance Network Technology Co., Ltd. Geometric partitioning mode in video coding
BR112022019657A2 (pt) 2020-03-31 2024-03-12 Ericsson Telefon Ab L M Processamento de vídeo

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012140839A1 (ja) * 2011-04-11 2012-10-18 パナソニック株式会社 ストリーム生成装置およびストリーム生成方法

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4759291B2 (ja) * 2004-03-08 2011-08-31 三星電子株式会社 適応的２ｎ進ツリーの生成方法、ならびにそれを利用して３次元体積データを符号化／復号化する方法および装置
KR100695142B1 (ko) 2004-03-08 2007-03-14 삼성전자주식회사 적응적 ２의 ｎ 제곱 진트리 생성방법 및 이를 이용한 3차원 체적 데이터 부호화/복호화 방법 및 장치
KR101510108B1 (ko) * 2009-08-17 2015-04-10 삼성전자주식회사 영상의 부호화 방법 및 장치, 그 복호화 방법 및 장치
CN106101717B (zh) * 2010-01-12 2019-07-26 Lg电子株式会社 视频信号的处理方法和设备
KR101487687B1 (ko) * 2010-01-14 2015-01-29 삼성전자주식회사 큰 크기의 변환 단위를 이용한 영상 부호화, 복호화 방법 및 장치
CN108366270B (zh) * 2010-09-27 2022-05-27 Lg 电子株式会社 一种内预测方法、视频编码方法以及数据传输方法
KR20120035096A (ko) * 2010-10-04 2012-04-13 한국전자통신연구원 쿼드 트리 변환 구조에서 부가 정보의 시그널링 방법 및 장치
AU2012205077B2 (en) * 2011-01-06 2016-04-07 Samsung Electronics Co., Ltd. Encoding method and device of video using data unit of hierarchical structure, and decoding method and device thereof
US9788019B2 (en) * 2011-03-09 2017-10-10 Hfi Innovation Inc. Method and apparatus of transform unit partition with reduced complexity
US8494290B2 (en) * 2011-05-05 2013-07-23 Mitsubishi Electric Research Laboratories, Inc. Method for coding pictures using hierarchical transform units
BR112014007494B1 (pt) * 2011-09-29 2022-05-31 Sharp Kabushiki Kaisha Dispositivo de decodificação de imagem, método de decodificação de imagem, e dispositivo de codificação de imagem
LT3166317T (lt) * 2011-10-31 2018-09-10 Samsung Electronics Co., Ltd. Transformacijos koeficiento lygmens entropinio kodavimo ir dekodavimo konteksto modelio nustatymo būdas ir aparatas
KR101904457B1 (ko) 2011-11-11 2018-10-04 지이 비디오 컴프레션, 엘엘씨 분할 코딩을 이용한 효과적인 예측
US20130176390A1 (en) * 2012-01-06 2013-07-11 Qualcomm Incorporated Multi-hypothesis disparity vector construction in 3d video coding with depth
US9111376B2 (en) 2012-01-26 2015-08-18 Samsung Electronics Co., Ltd. Image processing method and apparatus for 3D video
KR20130086911A (ko) * 2012-01-26 2013-08-05 삼성전자주식회사 3차원 비디오를 위한 영상 처리 방법 및 장치
US9912944B2 (en) * 2012-04-16 2018-03-06 Qualcomm Incorporated Simplified non-square quadtree transforms for video coding
US9900619B2 (en) 2012-07-02 2018-02-20 Qualcomm Incorporated Intra-coding of depth maps for 3D video coding
EP2873240A1 (en) 2012-07-13 2015-05-20 Huawei Technologies Co., Ltd. Apparatus for coding a bit stream representing a three-dimensional video
MX340434B (es) * 2012-09-10 2016-07-08 Panasonic Ip Corp America Metodo de codificacion de imagenes, metodo de decodificacion de imagenes, aparato de codificacion de imagenes, aparato de decodificacion de imagenes y aparato de codificacion y decodificacion de imagenes.
CN103716607B (zh) 2012-09-28 2017-02-08 中兴通讯股份有限公司 一种应用于HEVC‑based 3DVC的编码方法和装置
WO2014172387A1 (en) * 2013-04-15 2014-10-23 Huawei Technologies Co., Ltd. Method and apparatus of depth prediction mode selection
US9571858B2 (en) * 2013-07-19 2017-02-14 Futurewei Technologies, Inc. Method and apparatus of derivation for a binary partition pattern
WO2015057947A1 (en) * 2013-10-17 2015-04-23 Huawei Technologies Co., Ltd. Improved reference pixel selection and filtering for intra coding of depth map
US20160255371A1 (en) * 2013-10-18 2016-09-01 Lg Electronics Inc. Method and apparatus for coding/decoding 3d video
KR20150106380A (ko) * 2014-03-11 2015-09-21 삼성전자주식회사 인터 레이어 비디오 부복호화를 위한 깊이 영상의 예측 모드 전송 방법 및 장치

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012140839A1 (ja) * 2011-04-11 2012-10-18 パナソニック株式会社 ストリーム生成装置およびストリーム生成方法

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
BENJAMIN BROSS ET AL.: "High Efficiency Video Coding (HEVC) text specification draft 10 (for FDIS & Last Call)", JOINT COLLABORATIVE TEAM ON VIDEO CODING (JCT-VC) JOINT COLLABORATIVE TEAM ON VIDEO CODING (JCT-VC), vol. JCTVC-L1003_v34, JPN6017050821, 19 March 2013 (2013-03-19), ISSN: 0003794677 *
GERHARD TECH ET AL.: "3D-HEVC Draft Text 3", JOINT COLLABORATIVE TEAM ON 3D VIDEO CODING EXTENSION DEVELOPMENT OF ITU-T SG 16 WP 3 AND ISO/IEC JT, vol. JCT3V-G1001-v2, JPN6017050819, 10 March 2014 (2014-03-10), ISSN: 0003794676 *
HONGBIN LIU ET AL.: "Constraints for depth modeling modes", JOINT COLLABORATIVE TEAM ON 3D VIDEO CODING EXTENSIONS OF ITU-T SG 16 WP 3 AND ISO/IEC JTC 1/SC 29/W, vol. JCT3V-H0136, JPN6017050815, 10 March 2014 (2014-03-10), ISSN: 0003794673 *
L.ZHANG ET AL: "Test Model 7 of 3D-HEVC and MV-HEVC", JOINT COLLABORATIVE TEAM ON 3D VIDEO CODING EXTENSIONS DEVELOPMENT OF ITU-T SG 16 WP 3 AND ISO/IEC J, vol. JCT3V-G1005, JPN6017050813, 14 February 2014 (2014-02-14), ISSN: 0003794674 *
W.LI ET AL: "CE5-related: Implicit split process for intra SDC", JOINT COLLABORATIVE TEAM ON 3D VIDEO CODING EXTENSIONS OF ITU-T SG 16 WP 3 AND ISO/IEC JTC 1/SC 29/W, vol. JCT3V-G0111, JPN6017050817, 16 January 2014 (2014-01-16), ISSN: 0003794675 *

Also Published As

Publication number Publication date
WO2015135169A1 (en) 2015-09-17
CA2939170A1 (en) 2015-09-17
US20170006309A1 (en) 2017-01-05
CN106105216A (zh) 2016-11-09
EP3117616A1 (en) 2017-01-18
KR20160132891A (ko) 2016-11-21
EP3117616A4 (en) 2017-11-08
US10687079B2 (en) 2020-06-16
JP6445039B2 (ja) 2018-12-26

Similar Documents

Publication Publication Date Title
JP6445039B2 (ja) ３ｄビデオコーディングのための制限付き深度イントラモードコーディング
KR102574560B1 (ko) 비디오 코딩을 위해 액세스하는 샘플을 갖는 선형 모델 예측 모드
JP6312854B2 (ja) ３ｄビデオコーディングにおけるデルタｄｃ残差コーディングの簡易化
JP6462693B2 (ja) ３ｄビデオコーディングにおける深度イントラ予測モードおよび深度インター予測モードのための簡易深度コーディング（ｓｄｃ）のシグナリング
JP6370898B2 (ja) レイヤを横切るピクチャパーティションに対するビットストリームの制限
US10404999B2 (en) Residual coding for depth intra prediction modes
JP6580562B2 (ja) イントラ予測フィルタリングの無効化
JP6096217B2 (ja) ３ｄビデオコーディングにおけるビュー合成予測サポートのシグナリング
JP6246919B2 (ja) 深度イントラコーディングのためのウェッジレットパターン拡張
JP6396493B2 (ja) ３ｄビデオコーディングにおける大型予測ブロックのセグメントごとのｄｃコーディングの簡易化
JP6698351B2 (ja) ビュー内でのおよびビューにわたる深度ルックアップテーブルの予測コーディング
JP2017508345A (ja) 予測ブロックからのイントラ予測
JP2016524408A (ja) 隣接ベースの視差ベクトル導出を用いた３ｄビデオコーディングのための、並列に導出された視差ベクトル
EP3085094A1 (en) Large blocks and depth modeling modes (dmm's) in 3d video coding
JP2015525988A (ja) ３ｄビデオコーディングのための深度マップのイントラコーディング
JP2015507883A (ja) 深度を用いた３ｄビデオコーディングにおける多仮説視差ベクトル構成
JP2015514340A (ja) ビデオコード化における視差ベクトル予測
JP2016514431A (ja) 深度マップイントラコード化のための予測子
WO2015131388A1 (en) Simplification of depth intra mode coding in 3d video coding
US20150063464A1 (en) Lookup table coding
JP2019050621A (ja) ３ｄビデオコーディングのための制限付き深度イントラモードコーディング

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170215

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20171225

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180109

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180404

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180515

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180814

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20181030

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181128

R150 Certificate of patent or registration of utility model

Ref document number: 6445039

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees