JP2019525659A - 分離ツリー構造を使用したイントラビデオコーディング - Google Patents

分離ツリー構造を使用したイントラビデオコーディング Download PDF

Info

Publication number
JP2019525659A
JP2019525659A JP2019507944A JP2019507944A JP2019525659A JP 2019525659 A JP2019525659 A JP 2019525659A JP 2019507944 A JP2019507944 A JP 2019507944A JP 2019507944 A JP2019507944 A JP 2019507944A JP 2019525659 A JP2019525659 A JP 2019525659A
Authority
JP
Japan
Prior art keywords
mode
candidate list
video
chroma
modes
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
JP2019507944A
Other languages
English (en)
Other versions
JP6995839B2 (ja
JP2019525659A5 (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 JP2019525659A publication Critical patent/JP2019525659A/ja
Publication of JP2019525659A5 publication Critical patent/JP2019525659A5/ja
Application granted granted Critical
Publication of JP6995839B2 publication Critical patent/JP6995839B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/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
    • 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/186—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 a colour or a chrominance component
    • 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/46—Embedding additional information in the video signal during the compression process
    • 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/46—Embedding additional information in the video signal during the compression process
    • H04N19/463—Embedding additional information in the video signal during the compression process by compressing encoding parameters before transmission
    • 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/124—Quantisation
    • 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/91—Entropy coding, e.g. variable length coding [VLC] or arithmetic coding

Abstract

例となるデバイスは、メモリと、このメモリと通信する処理回路とを含む。デバイスの処理回路は、メモリに記憶されたビデオデータのクロマブロックについての最確モード（ＭＰＭ）候補リストを、ＭＰＭ候補リストが、クロマブロックに関連するビデオデータのルーマブロックに関連する１つまたは複数の導出モード（ＤＭ）と、ビデオデータの輝度成分をコード化するために使用可能な複数のルーマ予測モードとを含むように作成するように構成される。処理回路は、ＭＰＭ候補リストからモードを選択することと、ＭＰＭ候補リストから選択されたモードにしたがってクロマブロックをコード化することとを行うようにさらに構成される。【選択図】図１６

Description

関連出願
[0001]本願は、２０１６年８月１５日に出願された米国仮特許出願第６２／３７５，３８３号および２０１６年１０月５日に出願された米国仮特許出願第６２／４０４，５７２号の利益を主張し、これら各々の内容全体が参照によってここに組み込まれている。
[0002]本開示は、ビデオコーディングに関する。
[0003]デジタルビデオ能力は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲーム機、セルラ式または衛星無線電話、いわゆる「スマートフォン」、ビデオテレビ会議デバイス、ビデオストリーミングデバイス、および同様のものを含む、広範囲のデバイスに組み込まれることができる。デジタルビデオデバイスは、様々なビデオコーディング規格によって定義されている規格において説明されるもののようなビデオコーディング技法をインプリメントする。ビデオコーディング規格には、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ビジュアル、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ビジュアル、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ビジュアル、および（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても知られている）ＩＴＵ−Ｔ Ｈ．２６４に加え、そのＳＶＣ（Scalable Video Coding）およびＭＶＣ（Multiview Video Coding）拡張が含まれる。
[0004]加えて、新たなビデオコーディング規格、すなわち高効率ビデオコーディング（ＨＥＶＣ）、が、ＩＴＵ−Ｔ ＶＣＥＧ（Video Coding Experts Group）とＩＳＯ／ＩＥＣ ＭＰＥＧ（Motion Picture Experts Group）とからなるＪＣＴ−ＶＣ（Joint Collaboration Team on Video Coding）によって最近開発された。以降「ＨＥＶＣ ＷＤ」と呼ばれる最新のＨＥＶＣドラフト仕様は、http://phenix.int-evry.fr/jct/doc_end_user/documents/14_Vienna/wg11/JCTVC-N1003-v1.zipから入手可能である。ＨＥＶＣと、ＲＥｘｔ（Format Range）、ＳＨＶＣ（Scalability）、並びにＭＶ（Multi-View）（ＭＶ−ＨＥＶＣ）拡張およびスクリーンコンテンツ拡張を含むその拡張との仕様は、http://phenix.int-evry.fr/jct/doc_end_user/current_document.php?id=10481から入手可能である。ＩＴＵ−Ｔ ＶＣＥＧ（Ｑ６／１６）およびＩＳＯ／ＩＥＣ ＭＰＥＧ（ＪＴＣ １／ＳＣ ２９／ＷＧ １１）は、現在、（スクリーンコンテンツコーディングおよび高ダイナミックレンジコーディングのための現在の拡張および近々の拡張を含む）現在のＨＥＶＣ規格のものを大幅に上回る圧縮能力を有した将来のビデオコーディング技術の標準化に対する潜在的な必要性を研究している。
[0005]グループは、この分野の専門家が提案する圧縮技術設計を評価するために、ＪＶＥＴ（Joint Video Exploration Team）として知られている共同研究の取組みにおいてこの探査活動に一緒に取り組んでいる。ＪＶＥＴは、２０１５年１０月１９−２１日の間に初めて開かれた。最新バージョンの参照ソフトウェア、すなわちＪＥＭ３（Joint Exploration Model 3）は、https://jvet.hhi.fraunhofer.de/svn/svn_HMJEMSoftware/tags/HM-16.6-JEM-3.0/.からダウンロード可能である。ＪＥＭ３についてのアルゴリズム記述は、Ｊ．Ｃｈｅｎ，Ｅ．Ａｌｓｈｉｎａ，Ｇ．Ｊ．Ｓｕｌｌｉｖａｎ，Ｊ．−Ｒ．Ｏｈｍ，およびＪ．Ｂｏｙｃｅによる「Algorithm description of Joint Exploration Test Model 3」，ＪＶＥＴ−Ｃ１００１，ジュネーブ、２０１６年６月、においてさらに説明されている。
[0006]ビデオデバイスは、そのようなビデオコーディング技法をインプリメントすることでより効率的にデジタルビデオ情報を送信、受信、符号化、復号、および／または記憶し得る。ビデオコーディング技法は、ビデオシーケンスに内在する冗長性を低減または取り除くために、空間（イントラピクチャ）予測および／または時間（インターピクチャ）予測を含む。ブロックベースのビデオコード化の場合、ビデオスライス（例えば、ビデオフレームまたはビデオフレームの一部）は、いくつかの技法では、ツリーブロック、コード化単位（ＣＵ）、および／またはコード化ノードとも呼ばれ得るビデオブロックへと区分化され得る。ピクチャのイントラコード化された（Ｉ）スライス中のビデオブロックは、同じピクチャにおける隣接ブロック中の基準サンプルに対して空間予測を使用して符号化される。ピクチャのインターコード化された（ＰまたはＢ）スライス中のビデオブロックは、同じピクチャにおける隣接ブロック中の基準サンプルに対して空間予測を使用するかまたは他の参照ピクチャ中の基準サンプルに対して時間予測を使用し得る。ピクチャは、フレームと呼ばれ得、参照ピクチャは、参照フレームと呼ばれ得る。
[0007]空間または時間予測は、コード化されることとなるブロックについての予測ブロックをもたらす。残差データは、コード化されることとなる元のブロックと予測ブロックとの間の画素差を表す。インターコード化されたブロックは、予測ブロックを形成する基準サンプルのブロックを指し示す動きベクトルと、コード化されたブロックと予測ブロックとの間の差分を示す残差データとにしたがって符号化される。イントラコード化されたブロックは、イントラコード化モードと残差データとにしたがって符号化される。さらなる圧縮のために、残差データは、画素ドメインから変換ドメインに変換され得、これは、残差変換係数をもたらし、これはその後量子化され得る。最初は二次元アレイで配置されている、量子化変換係数（quantized transform coefficient）が、一次元ベクトルの変換係数を作り出すために走査され得、エントロピーコード化が、さらなる圧縮を達成するために適用され得る。
[0008]一般に、本開示は、いくつかのケースでは、ルーマ成分およびクロマ成分に対して異なる分割情報を提供するツリー構造にしたがったイントラ予測を使用したビデオデータのコード化（例えば、復号または符号化）に関する技法を説明する。すなわち、説明される技法が互換性を有する様々な区分化スキームによれば、ルーマ区分化ツリー構造は、対応するクロマ区分化ツリー構造から分離され得る。説明される技法は、ＨＥＶＣの拡張または次世代のビデオコーディング規格のような、アドバンスドビデオコーデックのコンテキストにおいて使用され得る。
[0009]一例では、ビデオデータをコード化するためのデバイスは、メモリと、このメモリと通信する処理回路とを含む。デバイスのメモリは、ビデオデータを記憶するように構成される。処理回路は、メモリに記憶されたビデオデータのルーマブロックを予測するのに利用可能な複数の導出モード（ＤＭ）が、メモリに記憶されたビデオデータのクロマブロックを予測するのにも利用可能であると決定するように構成され、クロマブロックはルーマブロックに対応する。処理回路は、クロマブロックに関して予測モードの候補リストを作成するようにさらに構成され、候補リストは、クロマブロックを予測するのに利用可能な複数のＤＭのうちの１つまたは複数のＤＭを含む。処理回路は、候補リストの１つまたは複数のＤＭのうちの任意のＤＭを使用してクロマブロックをコード化すると決定することと、候補リストの１つまたは複数のＤＭのうちの任意のＤＭを使用してクロマブロックをコード化するとの決定に基づいて、クロマブロックをコード化するために使用されるべき、候補リストの選択されたＤＭを識別するインジケーションをコード化することとを行うようにさらに構成される。処理回路は、候補リストの選択されたＤＭにしたがってクロマブロックをコード化するようにさらに構成される。
[0010]別の例では、ビデオデータをコード化する方法は、ビデオデータのルーマブロックを予測するのに利用可能な複数の導出モード（ＤＭ）がルーマブロックに対応するビデオデータのクロマブロックを予測するのにも利用可能であると決定することを含む。方法は、クロマブロックに関して予測モードの候補リストを作成すること、ここで、候補リストは、クロマブロックを予測するのに利用可能な複数のＤＭのうちの１つまたは複数のＤＭを含む、と、候補リストの１つまたは複数のＤＭのうちの任意のＤＭを使用してクロマブロックをコード化すると決定することとをさらに含む。方法は、候補リストの１つまたは複数のＤＭのうちの任意のＤＭを使用してクロマブロックをコード化するとの決定に基づいて、クロマブロックをコード化するために使用されるべき、候補リストの選択されたＤＭを識別するインジケーションをコード化することと、候補リストの選択されたＤＭにしたがってクロマブロックをコード化することとをさらに含む。
[0011]別の例では、装置は、ビデオデータのルーマブロックを予測するのに利用可能な複数の導出モード（ＤＭ）がルーマブロックに対応するビデオデータのクロマブロックを予測するのにも利用可能であると決定するための手段を含む。方法は、クロマブロックに関して予測モードの候補リストを作成すること、ここで、候補リストは、クロマブロックを予測するのに利用可能な複数のＤＭのうちの１つまたは複数のＤＭを含む、と、候補リストの１つまたは複数のＤＭのうちの任意のＤＭを使用してクロマブロックをコード化すると決定することとをさらに含む。装置は、クロマブロックに関して予測モードの候補リストを作成するための手段、ここで、候補リストは、クロマブロックを予測するのに利用可能な複数のＤＭのうちの１つまたは複数のＤＭを含む、と、候補リストの１つまたは複数のＤＭのうちの任意のＤＭを使用してクロマブロックをコード化すると決定するための手段とをさらに含む。装置は、候補リストの１つまたは複数のＤＭのうちの任意のＤＭを使用してクロマブロックをコード化するとの決定に基づいて、クロマブロックをコード化するために使用されるべき、候補リストの選択されたＤＭを識別するインジケーションをコード化するための手段と、候補リストの選択されたＤＭにしたがってクロマブロックをコード化するための手段とをさらに含む。
[0012]別の例では、非一時的なコンピュータ読取可能な記憶媒体は、命令で符号化され、これら命令は、実行されると、コンピューティングデバイスのプロセッサに、ビデオデータのルーマブロックを予測するのに利用可能な複数の導出モード（ＤＭ）がルーマブロックに対応するビデオデータのクロマブロックを予測するのにも利用可能であると決定させる。命令は、実行されると、プロセッサに、クロマブロックに関して予測モードの候補リストを作成すること、ここで、候補リストは、クロマブロックを予測するのに利用可能な複数のＤＭのうちの１つまたは複数のＤＭを含む、と、候補リストの１つまたは複数のＤＭのうちの任意のＤＭを使用してクロマブロックをコード化すると決定することとをさらに行わせる。命令は、実行されると、プロセッサに、クロマブロックに関して予測モードの候補リストを作成すること、ここで、候補リストは、クロマブロックを予測するのに利用可能な複数のＤＭのうちの１つまたは複数のＤＭを含む、と、候補リストの１つまたは複数のＤＭのうちの任意のＤＭを使用してクロマブロックをコード化すると決定することとをさらに行わせる。命令は、実行されると、プロセッサに、候補リストの１つまたは複数のＤＭのうちの任意のＤＭを使用してクロマブロックをコード化するとの決定に基づいて、クロマブロックをコード化するために使用されるべき、候補リストの選択されたＤＭを識別するインジケーションをコード化することと、候補リストの選択されたＤＭにしたがってクロマブロックをコード化することとをさらに行わせる。
[0013]別の例では、ビデオデータをコード化するためのデバイスは、メモリと、このメモリと通信する処理回路とを含む。デバイスのメモリは、ビデオデータを記憶するように構成される。処理回路は、メモリに記憶されたビデオデータのクロマブロックについての最確モード（ＭＰＭ）候補リストを、このＭＰＭ候補リストが、クロマブロックに関連するビデオデータのルーマブロックに関連する１つまたは複数の導出モード（ＤＭ）と、ビデオデータの輝度成分をコード化するために使用可能な複数のルーマ予測モードとを含むように作成するように構成される。処理回路は、ＭＰＭ候補リストからモードを選択することと、ＭＰＭ候補リストから選択されたモードにしたがってクロマブロックをコード化することとを行うようにさらに構成される。
[0014]別の例では、ビデオデータのクロマブロックについての最確モード（ＭＰＭ）候補リストを、このＭＰＭ候補リストが、クロマブロックに関連するビデオデータのルーマブロックに関連する１つまたは複数の導出モード（ＤＭ）と、ビデオデータの輝度成分をコード化するために使用可能な複数のルーマ予測モードとを含むように作成することを含む。方法は、ＭＰＭ候補リストからモードを選択することと、ＭＰＭ候補リストから選択されたモードにしたがってクロマブロックをコード化することとをさらに含む。
[0015]別の例では、装置は、ビデオデータのクロマブロックについての最確モード（ＭＰＭ）候補リストを、このＭＰＭ候補リストが、クロマブロックに関連するビデオデータのルーマブロックに関連する１つまたは複数の導出モード（ＤＭ）と、ビデオデータの輝度成分をコード化するために使用可能な複数のルーマ予測モードとを含むように作成するための手段を含む。装置は、ＭＰＭ候補リストからモードを選択するための手段と、ＭＰＭ候補リストから選択されたモードにしたがってクロマブロックをコード化するための手段とをさらに含む。
[0016]別の例では、非一時的なコンピュータ読取可能な記憶媒体は、命令で符号化され、これら命令は、実行されると、コンピューティングデバイスのプロセッサに、ビデオデータのクロマブロックについての最確モード（ＭＰＭ）候補リストを、このＭＰＭ候補リストが、クロマブロックに関連するビデオデータのルーマブロックに関連する１つまたは複数の導出モード（ＤＭ）と、ビデオデータの輝度成分をコード化するために使用可能な複数のルーマ予測モードとを含むように作成させる。命令は、実行されると、コンピューティングデバイスのプロセッサに、ＭＰＭ候補リストからモードを選択することと、ＭＰＭ候補リストから選択されたモードにしたがってクロマブロックをコード化することとをさらに行わせる。
[0017]１つまたは複数の例の詳細は、添付の図面および以下の説明で明記される。他の特徴、目的、および利点は、本説明および図面からおよび特許請求の範囲から明らかになるであろう。
図１は、本開示の技法を実行するように構成され得る例となるビデオ符号化および復号システムを例示するブロック図である。 図２は、本開示の技法を実行するように構成され得るビデオエンコーダの例を例示するブロック図である。 図３は、本開示の技法を実行するように構成され得るビデオデコーダの例を例示するブロック図である。 図４は、イントラ予測の態様を例示する概念図である。 図５は、ルーマブロックについてのイントラ予測モードを例示する概念図である。 図６は、平面モードの態様を例示する概念図である。 図７は、ＨＥＶＣに係る角度モードの態様を例示する概念図である。 図８は、ピクチャにおけるルーマおよびクロマサンプルの公称の垂直および水平ロケーションの例を例示する概念図である。 図９は、線形モデル（ＬＭ）モードに係る予測において使用されるパラメータの導出に使用されるサンプルのロケーションを例示する概念図である。 図１０は、四分木二分木（ＱＴＢＴ）構造を例示する概念図である。 図１１Ａは、ＱＴＢＴ区分化スキームに係る、対応するルーマおよびクロマブロックについての別個の区分化構造の例を例示する。 図１１Ｂは、ＱＴＢＴ区分化スキームに係る、対応するルーマおよびクロマブロックについての別個の区分化構造の例を例示する。 図１２Ａは、本開示の１つまたは複数の態様に係る、クロマ予測モードの適応順序付けのための隣接ブロックセクションを例示する。 図１２Ｂは、本開示の１つまたは複数の態様に係る、クロマ予測モードの適応順序付けのための隣接ブロックセクションを例示する。 図１３Ａは、上述した複数のＤＭモード選択ベース技法にしたがってクロマイントラ予測モードを選択するためにビデオ符号化および復号デバイスが使用し得るブロック位置の例を例示する概念図である。 図１３Ｂは、上述した複数のＤＭモード選択ベース技法にしたがってクロマイントラ予測モードを選択するためにビデオ符号化および復号デバイスが使用し得るブロック位置の例を例示する概念図である。 図１４は、本開示の態様に係る、ビデオ復号デバイスの処理回路が実行し得る例となるプロセスを例示するフローチャートである。 図１５は、本開示の態様に係る、ビデオ符号化デバイスの処理回路が実行し得る例となるプロセスを例示するフローチャートである。 図１６は、本開示の態様に係る、ビデオ復号デバイスの処理回路が実行し得る例となるプロセスを例示するフローチャートである。 図１７は、本開示の態様に係る、ビデオ符号化デバイスの処理回路が実行し得る例となるプロセスを例示するフローチャートである。
詳細な説明
[0035]図１は、動きベクトル予測のための本開示の技法を実行するように構成され得る例となるビデオ符号化および復号システム１０を例示するブロック図である。図１に示されるように、システム１０は、宛先デバイス１４によって後の時間に復号されることとなる符号化済みビデオデータを供給するソースデバイス１２を含む。特に、ソースデバイス１２は、コンピュータ読取可能な媒体１６を介して宛先デバイス１４にビデオデータを供給する。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンのような電話ハンドセット、いわゆる「スマート」パッド、テレビ、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲーム機、ビデオストリーミングデバイス、または同様のものを含む、広範囲のデバイスのうちの任意のものを備え得る。いくつかのケースでは、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信のために装備され得る。
[0036]宛先デバイス１４は、コンピュータ読取可能な媒体１６を介して、復号されることとなる符号化済みビデオデータを受信し得る。コンピュータ読取可能な媒体１６は、符号化済みビデオデータをソースデバイス１２から宛先デバイス１４に移動させる能力がある任意のタイプの媒体またはデバイスを備え得る。一例では、コンピュータ読取可能な媒体１６は、ソースデバイス１２が符号化済みビデオデータをリアルタイムに直接宛先デバイス１４に送信することを可能にするための通信媒体を備え得る。符号化済みビデオデータは、ワイヤレス通信プロトコルのような通信規格にしたがって変調され、宛先デバイス１４に送信され得る。通信媒体は、無線周波数（ＲＦ）スペクトルまたは１つまたは複数の物理伝送線のような任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、広域ネットワーク、またはインターネットのようなグローバルネットワークといった、パケットベースのネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス１２から宛先デバイス１４への通信を容易にするのに有用であり得る任意の他の機器を含み得る。
[0037]いくつかの例では、符号化済みデータは、出力インターフェース２２から記憶デバイスに出力され得る。同様に、符号化済みデータは、入力インターフェースによって記憶デバイスからアクセスされ得る。記憶デバイスは、ハードドライブ、ブルーレイディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性または非揮発性メモリ、または符号化済みビデオデータを記憶するための任意の他の適切なデジタル記憶媒体のような様々な分散型または局所的にアクセスされるデータ記憶媒体のうちの任意のものを含み得る。さらなる例では、記憶デバイスは、ファイルサーバ、またはソースデバイス１２によって生成される符号化済みビデオを記憶し得る別の中間記憶デバイスに対応し得る。宛先デバイス１４は、ストリーミングまたはダウンロードを介して、記憶デバイスからの記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化済みビデオデータを記憶するおよび符号化済みビデオデータを宛先デバイス１４に送信する能力がある任意のタイプのサーバであり得る。例となるファイルサーバには、（例えば、ウェブサイトのための）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続記憶（ＮＡＳ）デバイス、またはローカルディスクドライブが含まれる。宛先デバイス１４は、インターネット接続を含む、任意の標準データ接続を通して符号化済みビデオデータにアクセスし得る。これは、ファイルサーバに記憶されている符号化済みビデオデータにアクセスするのに適したワイヤレスチャネル（例えば、Ｗｉ−Ｆｉ接続）、ワイヤード接続（例えば、ＤＳＬ、ケーブルモデム、等）または両方の組合せを含み得る。記憶デバイスからの符号化済みビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。
[0038]本開示の技法は、必ずしも、ワイヤレスアプリケーションまたはセッティングに制限されるわけではない。本技法は、無線テレビ放送、ケーブルテレビ送信、衛星テレビ送信、ＤＡＳＨ（dynamic adaptive streaming over HTTP）のようなインターネットストリーミングビデオ送信、データ記憶媒体上で符号化されるデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオの復号、または他のアプリケーションのような、様々なマルチメディアアプリケーションのうちの任意のものをサポートして、ビデオコード化に適用され得る。いくつかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスト、および／またはビデオ電話のようなアプリケーションをサポートするために、単方向または双方向のビデオ送信をサポートするように構成され得る。
[0039]図１の例では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、出力インターフェース２２とを含む。宛先デバイス１４は、入力インターフェース２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。本開示にしたがって、ソースデバイス１２のビデオエンコーダ２０は、本開示の技法を動きベクトル予測に適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または配置を含み得る。例えば、ソースデバイス１２は、外部カメラのような外部ビデオソース１８からビデオデータを受信し得る。同様に、宛先デバイス１４は、統合されたディスプレイデバイスを含むよりむしろ外部ディスプレイデバイスとインターフェース接続し得る。
[0040]図１の例示されるシステム１０は一例に過ぎない。動きベクトル予測のための本開示の技法は、任意のデジタルビデオ符号化および／または復号デバイスによって実行され得る。一般に、本開示の技法は、ビデオ符号化デバイスによって実行されるが、本技法は、典型的に「ＣＯＤＥＣ」と呼ばれるビデオエンコーダ／デコーダによっても実行され得る。さらに、本開示の技法は、ビデオプレプロセッサによっても実行され得る。ソースデバイス１２および宛先デバイス１４は、ソースデバイス１２が宛先デバイス１４への送信のためのコード化済みビデオデータを生成するそのようなコード化デバイスの例に過ぎない。いくつかの例では、デバイス１２、１４は、デバイス１２、１４の各々がビデオ符号化および復号構成要素を含むような略対称的に動作し得る。そのため、システム１０は、例えば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、またはビデオ電話のために、ビデオデバイス１２、１４の間の単方向または双方向のビデオ送信をサポートし得る。
[0041]ソースデバイス１２のビデオソース１８は、ビデオカメラのようなビデオキャプチャデバイス、前にキャプチャされたビデオを含むビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース１８は、ライブビデオ、アーカイブされたビデオ、およびコンピュータ生成されたビデオの組合せ、またはソースビデオとしてコンピュータグラフィックベースのデータを生成し得る。いくつかのケースでは、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、いわゆるカメラ電話またはビデオ電話を形成し得る。しかしながら、上述したように、本開示で説明される技法は、一般にビデオコード化に適用可能であり得、ワイヤレスおよび／またはワイヤードアプリケーションに適用され得る。いずれのケースでも、キャプチャされた、前にキャプチャされた、またはコンピュータ生成されたビデオは、ビデオエンコーダ２０によって符号化され得る。その後、符号化済みビデオ情報は、コンピュータ読取可能な媒体１６上に出力インターフェース２２によって出力され得る。
[0042]コンピュータ読取可能な媒体１６は、ワイヤレスブロードキャストまたはワイヤードネットワーク送信のような一時的な媒体、またはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、ブルーレイディスク、または他のコンピュータ読取可能な媒体のような記憶媒体（すなわち、非一時的な記憶媒体）を含み得る。いくつかの例では、ネットワークサーバ（図示されない）は、符号化済みビデオデータをソースデバイス１２から受信し、例えば、ネットワーク送信を介して、符号化済みビデオデータを宛先デバイス１４に供給し得る。同様に、ディスクスタンピング設備のような媒体製造設備（medium production facility）のコンピューティングデバイスは、符号化済みビデオデータをソースデバイス１２から受信し、符号化済みビデオデータを含むディスクを作り出し得る。したがって、コンピュータ読取可能な媒体１６は、様々な例では、様々な形式の１つまたは複数のコンピュータ読取可能な媒体を含むと理解され得る。
[0043]宛先デバイス１４の入力インターフェース２８は、コンピュータ読取可能な媒体１６から情報を受信する。コンピュータ読取可能な媒体１６の情報は、ブロックおよび他のコード化された単位、例えばＧＯＰ、の処理および／または特性を説明するシンタックス要素を含む、ビデオエンコーダ２０によって定義され、そしてまたビデオデコーダ３０によっても使用されるシンタックス情報を含み得る。ディスプレイデバイス３２は、復号済みビデオデータをユーザに表示し、ブラウン管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスのような様々なディスプレイデバイスのうちの任意のものを備え得る。
[0044]ビデオエンコーダ２０およびビデオデコーダ３０は、高効率ビデオコーディング（ＨＥＶＣ）規格、ＨＥＶＣ規格への拡張、またはＩＴＵ−Ｔ Ｈ．２６６といった後続の規格のようなビデオコーディング規格にしたがって動作し得る。代替的に、ビデオエンコーダ２０およびビデオデコーダ３０は、別名、ＭＰＥＧ−４，パート１０，アドバンスドビデオコーディング（ＡＶＣ）と呼ばれるＩＴＵ−Ｔ Ｈ．２６４規格またはそのような規格の拡張のような他の専有規格または業界規格にしたがって動作し得る。しかしながら、本開示の技法は、いずれの特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例は、ＭＰＥＧ−２およびＩＴＵ−Ｔ Ｈ．２６３を含む。図１には示されていないが、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は、各々、オーディオエンコーダおよびデコーダと統合され得、共通データストリームまたは別個のデータストリームにおけるオーディオおよびビデオの両方の符号化に対処するために、好適なＭＵＸ−ＤＥＭＵＸユニットまたは他のハードウェアおよびソフトウェアを含み得る。適用可能な場合、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ Ｈ．２２３マルチプレクサプロトコルに、またはユーザデータグラムプロトコル（ＵＤＰ）のような他のプロトコルに準拠し得る。
[0045]ビデオエンコーダ２０およびビデオデコーダ３０は各々、１つまたは複数のマイクロプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せのような、様々な適切なエンコーダ回路のうちの任意のものとしてインプリメントされ得る。本技法が部分的にソフトウェアでインプリメントされる場合、デバイスは、本開示の技法を実行するために、このソフトウェアのための命令を、適切で非一時的なコンピュータ読取可能な媒体に記憶し、１つまたは複数のプロセッサを使用してハードウェアで命令を実行し得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は、１つまたは複数のエンコーダまたはデコーダに含まれ得、それらのうちのどちらも、それぞれのデバイスにおいて複合エンコーダ／デコーダ（ＣＯＤＥＣ）の一部として統合され得る。
[0046]ビデオコーディング規格には、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ビジュアル、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ビジュアル、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ビジュアル、および（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても知られている）ＩＴＵ−Ｔ Ｈ．２６４に加え、そのＳＶＣ（Scalable Video Coding）およびＭＶＣ（Multiview Video Coding）拡張が含まれる。ＭＶＣの１つの共同ドラフトは、「Advanced video coding for generic audiovisual services」，ＩＴＵ−Ｔ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．２６４，２０１０年３月、に記載されている。
[0047]加えて、ＩＴＵ−Ｔ ＶＣＥＧ（Video Coding Experts Group）とＩＳＯ／ＩＥＣ ＭＰＥＧ（Motion Picture Experts Group）とからなるＪＣＴ−ＶＣ（Joint Collaboration Team on Video Coding）によって開発された、新たに開発されたビデオコーディング規格、すなわち高効率ビデオコーディング（ＨＥＶＣ）が存在する。ＨＥＶＣの最新のドラフトは、http://phenix.int-evry.fr/jct/doc_end_user/documents/12_Geneva/wg11/JCTVC-L1003-v34.zipから入手可能である。ＨＥＶＣ規格はまた、いずれも「High efficiency video coding」と題し、いずれも２０１４年１０月に発行されたＲｅｃｏｍｍｅｎｄａｔｉｏｎ ＩＴＵ−Ｔ Ｈ．２６５および国際規格ＩＳＯ／ＩＥＣ２３００８−２において共同で提示されている。
[0048]ＪＣＴ−ＶＣは、ＨＥＶＣ規格を開発した。ＨＥＶＣ規格化の取組みは、ＨＥＶＣテストモデル（ＨＭ）と呼ばれる、ビデオコード化デバイスの発展型モデルに基づいている。ＨＭは、例えば、ＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣにしたがって、既存のデバイスに対してビデオコード化デバイスのいくつかの追加の能力を仮定する。例えば、Ｈ．２６４が、９つのイントラ予測符号化モードを提供するのに対し、ＨＥＶＣ ＨＭは、３３個ものイントラ予測符号化モードを提供し得る。
[0049]一般に、ＨＭのワーキングモデルは、ビデオフレームまたはピクチャがルーマおよびクロマサンプルの両方を含む最大コード化単位（ＬＣＵ）またはツリーブロックのシーケンスに分割され得ることを説明する。ビットストリーム内のシンタックスデータは、画素数の観点から最大コード化単位であるＬＣＵについてのサイズを定義し得る。スライスは、コード化順序で連続した多数のツリーブロックを含む。ビデオフレームまたはピクチャは、１つまたは複数のスライスへと区分化され得る。各ツリーブロックは四分木にしたがってコード化単位（ＣＵ）に分割され得る。一般に、四分木データ構造は、ルートノードがツリーブロックに対応する状態で１つのＣＵにつき１つのノードを含む。ＣＵが４つのサブＣＵへと分割される場合、ＣＵに対応するノードは、４つのリーフノードを含み、それらの各々がサブＣＵのうちの１つに対応する。
[0050]四分木データ構造の各ノードは、対応するＣＵにシンタックスデータを供給し得る。例えば、四分木におけるノードは、このノードに対応するＣＵがサブＣＵへと分割されるかどうかを示す分割フラグを含み得る。ＣＵに関するシンタックス要素は再帰的に定義され得、ＣＵがサブＣＵへと分割されるかどうかに依存し得る。ＣＵがこれ以上分割されない場合、それはリーフＣＵと呼ばれる。本開示では、たとえ元のリーフＣＵの明示的分割が存在しないとしても、リーフＣＵの４つのサブＣＵもまたリーフＣＵと呼ばれるであろう。例えば、１６×１６のサイズのＣＵがこれ以上分割されない場合、１６×１６のＣＵは分割されたことがないが、４つの８×８のサブＣＵもまたリーフＣＵと呼ばれるであろう。
[0051]ＣＵは、ＣＵがサイズ区別（size distinction）を有さないことを除いて、Ｈ．２６４規格のマクロブロックと同様の目的を有する。例えば、ツリーブロックは、（サブＣＵとも呼ばれる）４つの子ノードへと分割され得、各子ノードが次に親ノードになり、別の４つの子ノードへと分割され得る。四分木のリーフノードと呼ばれる、最終の分割されない子ノードは、リーフＣＵとも呼ばれるコード化ノードを備える。コード化されたビットストリームに関連するシンタックスデータは、最大ＣＵ深度と呼ばれる、ツリーブロックが分割され得る最大回数を定義し得、コード化ノードの最小サイズも定義し得る。したがって、ビットストリームもまた、最小コード化単位（ＳＣＵ）を定義し得る。本開示は、ＨＥＶＣのコンテキストにおけるＣＵ、ＰＵ、またはＴＵのうちの任意のもの、または、他の規格のコンテキストにおける同様のデータ構造（例えば、Ｈ．２６４／ＡＶＣにおけるそれのマクロブロックおよびサブブロック）を指すために「ブロック」という用語を使用する。
[0052]ＣＵは、コード化ノードと、このコード化ノードに関連する変換単位（ＴＵ）および予測単位（ＰＵ）とを含む。ＣＵのサイズはコード化ノードのサイズに対応し、形状が正方形でなければならない。ＣＵのサイズは、８×８画素から、最大６４×６４画素またはそれ以上のツリーブロックのサイズに及び得る。各ＣＵは、１つまたは複数のＰＵおよび１つまたは複数のＴＵを含み得る。ＣＵに関連するシンタックスデータは、例えば、１つまたは複数のＰＵへのＣＵの区分化を説明し得る。区分化モードは、ＣＵが、スキップまたはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、インター予測モード符号化されるかで異なり得る。ＰＵは、形状が非正方形になるように区分化され得る。ＣＵに関連するシンタックスデータはまた、例えば、四分木にしたがった１つまたは複数のＴＵへのＣＵの区分化を説明し得る。ＴＵは、形状が正方形または非正方形（例えば、長方形）であることができる。
[0053]ＨＥＶＣ規格は、ＣＵごとに異なり得るＴＵにしたがった変換を許容する。ＴＵは典型的に、区分化されたＬＣＵについて定義された所与のＣＵ中のＰＵのサイズに基づいてサイズ変更されるが、これは、常に当てはまるわけではないであろう。ＴＵは典型的に、ＰＵと同じサイズであるかそれより小さい。いくつかの例では、ＣＵに対応する残差サンプルは、「残差四分木」（ＲＱＴ）として知られている四分木構造を使用して、より小さい単位へと細分され得る。ＲＱＴのリーフノードは、変換単位（ＴＵ）と呼ばれ得る。ＴＵに関連する画素差値は、量子化され得る変換係数を作り出すために変換され得る。
[0054]リーフＣＵは、１つまたは複数の予測単位（ＰＵ）を含み得る。一般に、ＰＵは、対応するＣＵの全体または一部に対応する空間エリアを表し、このＰＵについての基準サンプルを取り出すためのデータを含み得る。さらに、ＰＵは、予測に関連するデータを含む。例えば、ＰＵがイントラモード符号化されるとき、このＰＵについてのデータが残差四分木（ＲＱＴ）に含まれ得、これは、このＰＵに対応するＴＵについてのイントラ予測モードを説明するデータを含み得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、このＰＵについての１つまたは複数の動きベクトルを定義するデータを含み得る。ＰＵについての動きベクトルを定義するデータは、例えば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルについての解像度（例えば、４分の１画素精度または８分の１画素精度）、動きベクトルが指し示す参照ピクチャ、および／または動きベクトルについての参照ピクチャリスト（例えば、リスト０、リスト１、またはリストＣ）を説明し得る。
[0055]１つまたは複数のＰＵを有するリーフＣＵもまた、１つまたは複数の変換単位（ＴＵ）を含み得る。変換単位は、上述したように、（ＴＵ四分木構造とも呼ばれる）ＲＱＴを使用して指定され得る。例えば、分割フラグは、リーフＣＵが４つの変換単位へと分割されるかを示し得る。次いで、各変換単位は、さらなるサブＴＵへとさらに分割され得る。ＴＵがこれ以上分割されないとき、それはリーフＴＵと呼ばれ得る。一般に、イントラコード化の場合、リーフＣＵに属するすべてのリーフＴＵが、同じイントラ予測モードを共有する。すなわち、リーフＣＵのすべてのＴＵの予測値を算出するために、同じイントラ予測モードが一般に適用される。イントラコード化の場合、ビデオエンコーダは、ＴＵに対応するＣＵの部分と元のブロックとの間の差分として、イントラ予測モードを使用して各リーフＴＵの残差値を算出し得る。ＴＵは、必ずしもＰＵのサイズに制限されるわけではない。ゆえに、ＴＵは、ＰＵより大きい場合も小さい場合もある。イントラコード化の場合、ＰＵは、同じＣＵについて対応するリーフＴＵとコロケートされ得る。いくつかの例では、リーフＴＵの最大サイズは、対応するリーフＣＵのサイズに対応し得る。
[0056]さらに、リーフＣＵのＴＵはまた、残差四分木（ＲＱＴ）と呼ばれるそれぞれの四分木データ構造に関連付けられ得る。すなわち、リーフＣＵは、リーフＣＵがどのようにＴＵへと区分化されるかを示す四分木を含み得る。ＴＵ四分木のルートノードは一般に、リーフＣＵに対応し、ＣＵ四分木のルートノードは一般に、ツリーブロック（または、ＬＣＵ）に対応する。分割されないＲＱＴのＴＵは、リーフＴＵと呼ばれる。一般に、本開示は、別途明記されていない限り、それぞれリーフＣＵおよびリーフＴＵを指すためにＣＵおよびＴＵという用語を使用する。
[0057]ビデオシーケンスは典型的に、一連のビデオフレームまたはピクチャを含む。ＧＯＰ（group of pictures）は一般に、ビデオピクチャのうちの一連の１つまたは複数を備える。ＧＯＰは、ＧＯＰのヘッダ、ピクチャのうちの１つまたは複数のピクチャのヘッダ、またはその他の場所に、ＧＯＰに含まれるピクチャの数を説明するシンタックスデータを含み得る。ピクチャの各スライスは、それぞれのスライスについての符号化モードを説明するスライスシンタックスデータを含み得る。ビデオエンコーダ２０は典型的に、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、ＣＵ内のコード化ノードに対応し得る。ビデオブロックは、一定のサイズまたは可変のサイズを有し得、指定のコーディング規格によってサイズが異なり得る。
[0058]例として、ＨＭは、様々なＰＵサイズにおける予測をサポートする。特定のＣＵのサイズが２Ｎ×２Ｎであると想定すると、ＨＭは、（８×８ＣＵのケースでは）２Ｎ×２ＮまたはＮ×ＮというＰＵサイズでのイントラ予測と、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、またはＮ×Ｎという対称的なＰＵサイズでのインター予測とをサポートする。ＨＭはまた、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮというＰＵサイズでのインター予測について非対称的な区分化をサポートする。非対称な区分化では、ＣＵの一方の方向は区分化されないが、もう一方の方向は２５％および７５％へと区分化される。２５％区分に対応するＣＵの部分は、「ｎ」と、それに続く「上（Ｕ：Up）」、「下（Ｄ：Down）」、「左（Ｌ：Left）」又は「右（Ｒ：Right）」というインジケーションとによって示される。ゆえに、例えば、「２Ｎ×ｎＵ」は、上には２Ｎ×０．５Ｎ ＰＵが、下には２Ｎ×１．５Ｎ ＰＵがくるように水平に区分化された２Ｎ×２Ｎ ＣＵを指す。
[0059]本開示では、「Ｎ×Ｎ（NxN）」および「Ｎ×Ｎ（N by N）」は、垂直次元および水平次元の観点からビデオブロックの画素次元、例えば、１６×１６（16x16）画素または１６×１６（16 by 16）画素、を指すために、交換可能に使用され得る。一般に、１６×１６ブロックは、垂直方向に１６画素（ｙ＝１６）を、水平方向に１６画素（ｘ＝１６）を有するであろう。同様に、Ｎ×Ｎブロックは一般に、垂直方向にＮ画素を、水平方向にＮ画素を有し、ここで、Ｎは、自然数を表す。ブロック中の画素は、行と列に配置され得る。さらに、ブロックは、水平方向において、必ずしも、垂直方向と同じ数の画素を有する必要はない。例えば、ブロックは、Ｎ×Ｍ画素を備え得、ここで、Ｍは必ずしもＮと等しいとは限らない。
[0060]ＣＵのＰＵを使用するイントラ予測またはインター予測コード化に続いて、ビデオエンコーダ２０は、ＣＵのＴＵについて残差データを算出し得る。ＰＵは、（画素ドメインとも呼ばれる）空間ドメインにおける予測画素データを生成する方法またはモードを説明するシンタックスデータを備え得、ＴＵは、例えば、残差ビデオデータへの離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に類似した変換のような変換の適用の後の変換ドメインにおける係数を備え得る。残差データは、ＰＵに対応する予測値および符号化されていないピクチャの画素間の画素差に対応し得る。ビデオエンコーダ２０は、ＣＵについての残差データを含むＴＵを形成し、次いでＴＵを変換して、ＣＵについての変換係数を作り出し得る。
[0061]変換係数を作り出すための任意の変換に続いて、ビデオエンコーダ２０は、変換係数の量子化を実行し得る。量子化は一般に、変換係数を表すために使用されるデータ量をできる限り低減させためにそれら係数が量子化されるプロセスを指し、これは、さらなる圧縮を提供する。量子化プロセスは、これら係数のうちのいくつかまたはすべてに関連するビット深度を低減し得る。例えば、ｎビット値は、量子化中、ｍビット値へと端数が切り捨てられ得、ここで、ｎはｍより大きい。
[0062]量子化に続いて、ビデオエンコーダは、変換係数を走査し得、量子化変換係数を含む二次元マトリックスから一次元ベクトルを作り出す。走査は、より高いエネルギー（そのため、より低い周波数）の係数をアレイの前方に置き、より低いエネルギー（そのため、より高い周波数）の係数をアレイの後方に置くように設計され得る。いくつかの例では、ビデオエンコーダ２０は、予め定義された走査順序を利用して、量子化変換係数を走査し、エントロピー符号化されることができる直列ベクトルを作り出し得る。別の例では、ビデオエンコーダ２０は、適応走査を実行し得る。一次元ベクトルを形成するために量子化変換係数を走査した後、ビデオエンコーダ２０は、例えば、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、確率区間区分化エントロピー（ＰＩＰＥ）コーディング、または別のエントロピー符号化方法にしたがって、一次元のベクトルをエントロピー符号化し得る。ビデオエンコーダ２０はまた、ビデオデータを復号する際に、ビデオデコーダ３０による使用のために符号化済みビデオデータに関連するシンタックス要素をエントロピー符号化し得る。
[0063]ＣＡＢＡＣを実行するために、ビデオエンコーダ２０は、送信されることとなるシンボルに、コンテキストモデル内のコンテキストを割り当て得る。コンテキストは、例えば、シンボルの隣接値が非ゼロであるか否かに関連し得る。ＣＡＶＬＣを実行するために、ビデオエンコーダ２０は、送信されることとなるシンボルのための可変長コードを選択し得る。
[0064]ＶＬＣにおけるコードワードは、比較的短いコードがより可能性の高いシンボルに対応する一方で、より長いコードがより可能性の低いシンボルに対応するように構築され得る。このように、ＶＬＣの使用は、例えば、送信されることとなる各シンボルに対して等しい長さのコードワードを使用するよりもビット節約を達成し得る。確率の決定は、シンボルに割り当てられたコンテキストに基づき得る。
[0065]本開示の１つまたは複数の技法にしたがって、ビデオエンコーダ２０および／またはビデオデコーダ３０は、本開示の技法のうちの１つまたは複数をインプリメントし得る。例えば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、動き推定および補償においてアフィンモデルを使用し得る。
[0066]図２は、動きベクトル予測のために本開示の技法を実行するように構成され得るビデオエンコーダ２０の例を例示するブロック図である。ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラおよびインターコード化を実行し得る。イントラコード化は、所与のビデオフレームまたはピクチャ内のビデオにおける空間冗長性を低減または取り除くために空間予測に依拠する。インターコード化は、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオにおける時間冗長性を低減または取り除くために時間予測に依拠する。イントラモード（Ｉモード）は、いくつかの空間ベースのコード化モードのうちの任意のものを指し得る。単方向予測（Ｐモード）または双方向予測（Ｂモード）のようなインターモードは、いくつかの時間ベースのコード化モードのうちの任意のものを指し得る。
[0067]図２に示されるように、ビデオエンコーダ２０は、符号化されることとなるビデオフレーム内の現在のビデオブロックを受け取る。図２の例では、ビデオエンコーダ２０は、モード選択ユニット４０と、参照ピクチャメモリ６４と、加算器５０と、変換処理ユニット５２と、量子化ユニット５４と、エントロピー符号化ユニット５６とを含む。次に、モード選択ユニット４０は、動き補償ユニット４４と、動き推定ユニット４２と、イントラ予測ユニット４６と、区分ユニット４８とを含む。ビデオブロックの再構築のために、ビデオエンコーダ２０はまた、逆量子化ユニット５８と、逆変換ユニット６０と、加算器６２とを含む。ブロック境界をフィルタ処理して、再構築されたビデオからブロッキネスアーティファクト（blockiness artifact）を取り除くためのデブロッキングフィルタ（図２には示されない）も含まれ得る。望まれる場合、デブロッキングフィルタは典型的に、加算器６２の出力をフィルタ処理するであろう。（ループ中またはループ後の）追加のフィルタもまた、デブロッキングフィルタに加えて使用され得る。そのようなフィルタは、簡潔さのために示されないが、望まれる場合、（ループフ内フィルタとして）加算器５０の出力をフィルタ処理し得る。
[0068]符号化プロセス中、ビデオエンコーダ２０は、コード化されることとなるビデオフレームまたはスライスを受け取る。フレームまたはスライスは、複数のビデオブロックへと分割され得る。動き推定ユニット４２および動き補償ユニット４４は、時間予測を提供するために、１つまたは複数の参照フレーム中の１つまたは複数のブロックに対して、受け取ったビデオブロックのインター予測コード化を実行する。代替的に、イントラ予測ユニット４６は、空間的予測を提供するために、コード化されることとなるブロックと同じフレームまたはスライス中の１つまたは複数の隣接ブロックに対して、受け取ったビデオブロックのイントラ予測コード化を実行し得る。ビデオエンコーダ２０は、例えば、ビデオデータの各ブロックについて、好適なコード化モードを選択するために、複数のコード化パスを実行し得る。
[0069]さらに、区分ユニット４８は、前のコード化パスにおける前の区分化スキームの評価に基づいて、ビデオデータのブロックをサブブロックへと区分化し得る。例えば、区分ユニット４８は、レート−歪み分析（例えば、レート−歪み最適化）に基づいて、最初にフレームまたはスライスをＬＣＵへと区分化し、ＬＣＵの各々をサブＣＵへと区分化し得る。モード選択ユニット４０はさらに、サブＣＵへのＬＣＵの区分化を示す四分木データ構造を作り出し得る。四分木のリーフノードＣＵは、１つまたは複数のＰＵおよび１つまたは複数のＴＵを含み得る。
[0070]モード選択ユニット４０は、例えば、誤差結果に基づいて、コード化モード、イントラまたはインター、のうちの１つを選択し得、結果として得られたイントラまたはインターコード化されたブロックを、残差ブロックデータを生成するために加算器５０におよび参照フレームとして使用される符号化済みブロックを再構築するために加算器６２に提供する。モード選択ユニット４０はまた、動きベクトル、イントラモードインジケータ、区分化情報、および他のそのようなシンタックス情報のようなシンタックス要素をエントロピー符号化ユニット５６に提供する。
[0071]動き推定ユニット４２および動き補償ユニット４４は、高度に統合され得るが、概念的な目的のために別個に例示されている。動き推定ユニット４２によって実行される動き推定は、ビデオブロックについての動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、例えば、現在のビデオフレームまたはピクチャ内のビデオブロックのＰＵの、現在のフレーム（または他のコード化された単位）内のコード化されている現在のブロックに関連した参照フレーム（または他のコード化された単位）内の予測ブロックに対する変位を示し得る。予測ブロックは、画素差の観点から、コード化されることとなるブロックに厳密に一致すると認められるブロックであり、これは、差分絶対値和（ＳＡＤ）、差分二乗和（ＳＳＤ）、または他の差分メトリックによって決定され得る。いくつかの例では、ビデオエンコーダ２０は、参照ピクチャメモリ６４に記憶された参照ピクチャのサブ整数画素位置の値を算出し得る。例えば、ビデオエンコーダ２０は、参照ピクチャの４分の１画素位置、８分の１画素位置、または他の分数画素位置の値を補間し得る。したがって、動き推定ユニット４２は、全画素位置および分数画素位置に対して動き探索を実行し、分数画素精度で動きベクトルを出力し得る。
[0072]動き推定ユニット４２は、ＰＵの位置を参照ピクチャの予測ブロックの位置と比較することで、インターコード化されたスライス中のビデオブロックのＰＵについての動きベクトルを算出する。参照ピクチャは、第１の参照ピクチャリスト（リスト０）または第２の参照ピクチャリスト（リスト１）から選択され得、それらは各々、参照ピクチャメモリ６４に記憶された１つまたは複数の参照ピクチャを識別する。動き推定ユニット４２は、算出された動きベクトルを、エントロピー符号化ユニット５６および動き補償ユニット４４に送る。
[0073]動き補償ユニット４４によって実行される動き補償は、動き推定ユニット４２によって決定された動きベクトルに基づいて、予測ブロックをフェッチすることまたは生成することを伴い得る。この場合も同様に、動き推定ユニット４２および動き補償ユニット４４は、いくつかの例では、機能的に統合され得る。現在のビデオブロックのＰＵについての動きベクトルを受け取ると、動き補償ユニット４４は、動きベクトルが指し示す予測ブロックを参照ピクチャリストのうちの１つに位置付け得る。加算器５０は、後述されるように、コード化されている現在のビデオブロックの画素値から予測ブロックの画素値を差し引き、画素差値を形成することで、残差ビデオブロックを形成する。一般に、動き推定ユニット４２は、ルーマ成分に対して動き推定を実行し、動き補償ユニット４４は、ルーマ成分とクロマ成分の両方に関して、ルーマ成分に基づいて算出された動きベクトルを使用する。モード選択ユニット４０はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ３０が使用するためのビデオブロックおよびビデオスライスに関連するシンタックス要素を生成し得る。
[0074]ビデオエンコーダ２０は、図１に関して上述され、以下により詳細に説明されるような本開示の様々な技法のうちの任意のものを実行するように構成され得る。例えば、動き補償ユニット４４は、本開示の技法にしたがってＡＭＶＰまたはマージモードを使用してビデオデータのブロックについての動き情報をコード化するように構成され得る。
[0075]動き補償ユニット４４がマージモードを実行することを選択すると想定すると、動き補償ユニット４４は、マージ候補のセットを含む候補リストを作成し得る。動き補償ユニット４４は、特定の所定の順序に基づいて候補リストに候補を加え得る。動き補償ユニット４４はまた、上述したように、追加候補を加え、候補リストのプルーニングを実行し得る。最終的に、モード選択ユニット４０は、現在のブロックの動き情報を符号化するために候補のうちのどれが使用されるべきかを決定し、選択された候補を表すマージインデックスを符号化し得る。
[0076]イントラ予測ユニット４６は、上で説明されたように、動き推定ユニット４２および動き補償ユニット４４によって実行されるインター予測の代わりとして、現在のブロックをイントラ予測し得る。特に、イントラ予測ユニット４６は、現在のブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測ユニット４６は、例えば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在のブロックを符号化し得、イントラ予測ユニット４６（または、いくつかの例では、モード選択ユニット４０）は、テストされたモードから、使用すべき好適なイントラ予測モードを選択し得る。
[0077]例えば、イントラ予測ユニット４６は、様々なテストされたイントラ予測モードに対してレート−歪み分析を使用してレート−歪み値を算出し、テストされたモードのうち、最良のレート−歪み特性を有するイントラ予測モードを選択し得る。レート−歪み分析は一般に、符号化済みブロックと、この符号化済みブロックを作り出すために符号化された元の符号化されていないブロックとの間の歪み（または誤差）の量、および、この符号化済みブロックを作り出すために使用されるビットレート（すなわち、ビットの数）を決定する。イントラ予測ユニット４６は、様々な符号化済みブロックについてレートおよび歪みから比を算出して、どのイントラ予測モードがブロックに対して最良のレート−歪み値を示すかを決定し得る。
[0078]ブロックについてイントラ予測モードを選択した後、イントラ予測ユニット４６は、このブロックについての選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット５６に提供し得る。エントロピー符号化ユニット５６は、選択されたイントラ予測モードを示す情報を符号化し得る。ビデオエンコーダ２０は、複数のイントラ予測モードインデックス表および（コードワードマッピング表とも呼ばれる）複数の修正されたイントラ予測モードインデックス表、様々なブロックについての符号化コンテキストの定義、ならびに、これらコンテキストの各々に使用すべき最も可能性の高い１つのイントラ予測モード、１つのイントラ予測モードインデックス表、および１つの修正されたイントラ予測モードインデックス表を示すインジケーション、を含み得る構成データを、送信されるビットストリーム中に含め得る。
[0079]ビデオエンコーダ２０は、コード化されている元のビデオブロックから、モード選択ユニット４０からの予測データを差し引くことで残差ビデオブロックを形成する。加算器５０は、この減算演算を実行する１つまたは複数の構成要素を表す。変換処理ユニット５２は、離散コサイン変換（ＤＣＴ）または概念的に類似した変換のような変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを作り出す。変換処理ユニット５２は、ＤＣＴと概念的に類似した他の変換を実行し得る。ウェーブレット変換、整数変換、サブバンド変換、または他のタイプの変換もまた使用され得る。
[0080]いずれのケースでも、変換処理ユニット５２は、変換を残差ブロックに適用し、残差変換係数のブロックを作り出す。変換は、残差情報を画素値ドメインから周波数ドメインのような変換ドメインに変換し得る。変換処理ユニット５２は、結果として得られた変換係数を量子化ユニット５４に送り得る。量子化ユニット５４は、ビットレートをさらに低減するために、変換係数を量子化する。量子化プロセスは、これら係数のうちのいくつかまたはすべてに関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することで修正され得る。次いで、いくつかの例では、量子化ユニット５４は、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット５６が走査を実行し得る。
[0081]量子化に続いて、エントロピー符号化ユニット５６は、量子化変換係数をエントロピーコード化する。例えば、エントロピー符号化ユニット５６は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、確率区間区分化エントロピー（ＰＩＰＥ）コーディング、または別のエントロピーコーディング技法を実行し得る。コンテキストベースのエントロピーコード化のケースでは、コンテキストは隣接ブロックに基づき得る。エントロピー符号化ユニット５６によるエントロピーコード化に続いて、符号化されたビットストリームは、別のデバイス（例えば、ビデオデコーダ３０）に送信されるか、または後の送信または取出しのためにアーカイブされ得る。
[0082]逆量子化ユニット５８および逆変換ユニット６０は、それぞれ、逆量子化および逆変換を適用して、例えば、参照ブロックとしての後の使用のために、画素ドメインにおける残差ブロックを再構築する。動き補償ユニット４４は、参照ピクチャメモリ６４のフレームのうちの１つのフレームの予測ブロックに残差ブロックを加えることによって、参照ブロックを算出し得る。動き補償ユニット４４はまた、再構築された残差ブロックに１つまたは複数の補間フィルタを適用して、動き推定で用いるサブ整数画素値を算出し得る。加算器６２は、動き補償ユニット４４によって作り出された動き補償された予測ブロックに、再構築された残差ブロックを加えて、参照ピクチャメモリ６４への記憶のための再構築されたビデオブロックを作り出す。再構築されたビデオブロックは、後続のビデオフレーム中のブロックをインターコード化するために、参照ブロックとして動き推定ユニット４２および動き補償ユニット４４によって使用され得る。
[0083]図３は、本開示の動きベクトル予測技法を実行するように構成され得るビデオデコーダ３０の例を例示するブロック図である。図３の例では、ビデオデコーダ３０は、エントロピー復号ユニット７０と、動き補償ユニット７２と、イントラ予測ユニット７４と、逆量子化ユニット７６と、逆変換ユニット７８と、参照ピクチャメモリ８２と、加算器８０とを含む。ビデオデコーダ３０は、いくつかの例では、ビデオエンコーダ２０（図２）に関して説明された符号化パスのほぼ反転である復号パスを実行し得る。動き補償ユニット７２は、エントロピー復号ユニット７０から受け取った動きベクトルに基づいて予測データを生成し得、イントラ予測ユニット７４は、エントロピー復号ユニット７０から受け取ったイントラ予測モードインジケータに基づいて予測データを生成し得る。
[0084]復号プロセス中、ビデオデコーダ３０は、ビデオエンコーダ２０から、符号化されたビデオスライスのビデオブロックおよび関連するシンタックス要素を表す符号化済みビデオビットストリームを受け取る。ビデオデコーダ３０のエントロピー復号ユニット７０は、量子化された係数、動きベクトルまたはイントラ予測モードインジケータ、および他のシンタックス要素を生成するために、ビットストリームをエントロピー復号する。エントロピー復号ユニット７０は、動きベクトルおよび他のシンタックス要素を動き補償ユニット７２に転送する。ビデオデコーダ３０は、ビデオスライスレベルおよび／またはビデオブロックレベルでシンタックス要素を受け取り得る。
[0085]ビデオスライスがイントラコード化された（Ｉ）スライスとしてコード化されるとき、イントラ予測ユニット７４は、シグナリングされたイントラ予測モードと、現在のフレームまたはピクチャの前に復号されたブロックからのデータとに基づいて、現在のビデオスライスのビデオブロックについての予測データを生成し得る。ビデオフレームがインターコード化された（すなわち、Ｂ、Ｐ、またはＧＰＢ）スライスとしてコード化されるとき、動き補償ユニット７２は、動きベクトルと、エントロピー復号ユニット７０から受け取った他のシンタックス要素とに基づいて、現在のビデオスライスのビデオブロックについての予測ブロックを作り出す。予測ブロックは、参照ピクチャリストのうちの１つ内の参照ピクチャのうちの１つから作り出され得る。ビデオデコーダ３０は、参照ピクチャメモリ８２に記憶された参照ピクチャに基づいてデフォルト構築技法を使用して参照フレームリスト、リスト０およびリスト１を、構築し得る。
[0086]動き補償ユニット７２は、動きベクトルおよび他のシンタックス要素を解析することで現在のビデオスライスのビデオブロックについての予測情報を決定し、この予測情報を使用して、復号されている現在のビデオブロックについての予測ブロックを作り出す。例えば、動き補償ユニット７２は、受け取ったシンタックス要素のうちのいくつかを使用して、ビデオスライスのビデオブロックをコード化するために使用される予測モード（例えば、イントラまたはインター予測）、インター予測スライスタイプ（例えば、Ｂスライス、Ｐスライス）、スライスのための参照ピクチャリストのうちの１つまたは複数についての構築情報、スライスの各インター符号化されたビデオブロックについての動きベクトル、スライスの各インターコード化されたビデオブロックについてのインター予測ステータス、および現在のビデオスライス中のビデオブロックを復号するための他の情報を決定する。
[0087]動き補償ユニット７２はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット７２は、参照ブロックのサブ整数画素の補間値を算出するために、ビデオブロックの符号化中、ビデオエンコーダ２０によって使用されるように補間フィルタを使用し得る。このケースでは、動き補償ユニット７２は、受け取ったシンタックス要素からビデオエンコーダ２０によって使用される補間フィルタを決定し、この補間フィルタを使用して予測ブロックを作り出し得る。
[0088]ビデオデコーダ３０は、図１に関して上述され、以下により詳細に説明されるような本開示の様々な技法のうちの任意のものを実行するように構成され得る。例えば、動き補償ユニット７２は、本開示の技法にしたがってＡＭＶＰまたはマージモードを使用して動きベクトル予測を実行すると決定するように構成され得る。エントロピー復号ユニット７０は、どのように動き情報が現在のブロックについてコード化されるかを表す１つまたは複数のシンタックス要素を復号し得る。
[0089]マージモードが実行されることをシンタックス要素が示すと想定すると、動き補償ユニット７２は、マージ候補のセットを含む候補リストを作成し得る。動き補償ユニット７２は、特定の所定の順序に基づいて候補リストに候補を加え得る。動き補償ユニット７２はまた、上述したように、追加候補を加え、候補リストのプルーニングを実行し得る。最終的に、動き補償ユニット７２は、現在のブロックについての動き情報をコード化するために候補のうちのどれが使用されるかを表すマージインデックスを復号し得る。
[0090]逆量子化ユニット７６は、ビットストリームにおいて提供され、かつ、エントロピー復号ユニット７０によってエントロピー復号された量子化変換係数を逆量子化（inverse quantize）、すなわち、逆量子化（de-quantize）する。逆量子化プロセスは、適用されるべき量子化の程度および同じく逆量子化の程度を決定するために、ビデオスライス中の各ビデオブロックについて、ビデオデコーダ３０によって算出される量子化パラメータＱＰＹの使用を含み得る。
[0091]逆変換ユニット７８は、画素ドメインにおいて残差ブロックを作り出すために、逆変換、例えば、逆ＤＣＴ、逆整数変換、または概念的に類似した逆変換プロセスを変換係数に適用する。
[0092]動き補償ユニット７２が動きベクトルと他のシンタックス要素とに基づいて現在のビデオブロックについての予測ブロックを生成した後、ビデオデコーダ３０は、逆変換ユニット７８からの残差ブロックを動き補償ユニット７２によって生成された対応する予測ブロックと合計することで、復号されたビデオブロックを形成する。加算器８０は、この加算演算を実行する１つまたは複数の構成要素を表す。望まれる場合、ブロッキネスアーティファクトを取り除くために、復号されたブロックをフィルタ処理するため、デブロッキングフィルタが適用され得る。（コード化ループ中またはコード化ループ後のどちらかの）他のループフィルタもまた、画素遷移を滑らかにするためにまたは別の方法でビデオ品質を改善するために使用され得る。次いで、所与のフレームまたはピクチャ内の復号されたビデオブロックは、後の動き補償のために使用される参照ピクチャを記憶する参照ピクチャメモリ８２に記憶される。参照ピクチャメモリ８２はまた、図１のディスプレイデバイス３２のようなディスプレイデバイス上での後の提示のために、復号されたビデオを記憶する。
[0093]図４は、イントラ予測の態様を例示する概念図である。ビデオエンコーダ２０および／またはビデオデコーダ３０は、ブロックの空間的に隣接する再構築画像サンプルを使用することで、画像ブロック予測を実行するためにイントラ予測をインプリメントし得る。１６×１６画像ブロックに対するイントラ予測の典型的な例が図４に示される。図４に例示されるように、イントラ予測を用いて、（実線の正方形の）１６×１６画像ブロックは、（矢印で示される）選択された予測方向に沿って左の列およびすぐ上の行に位置する左上の隣接する再構築サンプル（基準サンプル）によって予測される。ＨＥＶＣでは、ルーマブロックのイントラ予測について、３５個のモードが含まれる。
[0094]図５は、ルーマブロックについてのイントラ予測モードを例示する概念図である。モードは、図５に示されるように、１つの平面モードと、１つのＤＣモードと、３３個の角度モードとを含む。ＨＥＶＣにおいて定義されるイントラ予測の３５個のモードは、以下の表１において示されるようにインデックス化される：
[0095]図６は、平面モードの態様を例示する概念図である。平面モード、これは典型的に最も最近使用されるイントラ予測モードである、の場合、予測サンプルは、図６に示されるように生成される。Ｎ×Ｎブロックについて平面予測を実行するために、（ｘ、ｙ）に位置するサンプルｐｘｙごとに、ビデオエンコーダ２０および／またはビデオデコーダ３０は、バイリニアフィルタを用いて、４つの特定の隣接する再構築サンプル、すなわち基準サンプル、を使用して予測値を算出し得る。４つの基準サンプルは、右上の再構築サンプルＴＲと、左下の再構築サンプルＢＬと、Ｔで表される現在のサンプルの同じ列（ｒｘ，−１）およびＬで表される現在のサンプルの同じ行（ｒ−１，ｙ）に位置する２つの再構築サンプルとを含む。平面モードは、以下の式で示されるように公式化されることができる：ｐｘｙ＝（Ｎ−ｘ−１）・Ｌ＋（Ｎ−ｙ−１）・Ｔ＋ｘ・ＴＲ＋ｙ・ＢＬ
[0096]ＤＣモードの場合、予測ブロックは、単に、隣接する再構築サンプルの平均値で満たされる。一般に、平面モードおよびＤＣモードの両方が、滑らかに変化する画像領域および一定の画像領域をモデリングするために適用される。
[0097]図７は、ＨＥＶＣに係る角度モードの態様を例示する概念図である。合計３３個の異なる予測方向を含む、ＨＥＶＣにおける角度イントラ予測モードの場合、イントラ予測プロセスは、以下のように説明される。所与の角度イントラ予測ごとに、イントラ予測方向は、相応して識別されることができる。例えば、図５によれば、イントラモード１８は、純水平予測方向に対応し、イントラモード２６は、純垂直予測方向に対応する。所与のイントラ予測方向を前提として、予測ブロックのサンプルごとに、サンプルの座標（ｘ，ｙ）は最初に、図７の例に示されるように、予測方向に沿って、隣接する再構築サンプルの行／列に投影される。（ｘ，ｙ）のペアが、２つの隣接する再構築サンプルＬとＲとの間の分数位置αに投影されると仮定して、（ｘ，ｙ）の予測値は、２タップのバイリニア補間フィルタを使用して算出され、以下の式で示されるように公式化される：ｐｘｙ＝（１−α）・Ｌ＋α・Ｒ。浮動小数点演算を回避するために、ＨＥＶＣでは、上の算出は実際、ｐｘｙ＝（（３２−ａ）・Ｌ＋ａ・Ｒ＋１６）＞＞５のような整数演算を使用して近似され、ここで、ａは、３２×αに等しい整数である。
[0098]クロマ符号化および復号の態様が一般に以下に説明される。かなり頻繁に、クロマ信号の構造は、対応するルーマ信号のものに追従する。説明したように、各ルーマブロックは、１つのクロマブロックに対応し、各クロマ予測ブロックは、ＨＥＶＣにしたがって、２Ｎ×２ＮまたはＮ×Ｎに等しいルーマ予測ブロックの区分サイズに基づいて、１つまたは４つのルーマ予測ブロックに対応し得る。クロマ信号構造のこれらの特性および一般的傾向を利用して、ＨＥＶＣは、クロマＰＵが、対応する選択されたルーマＰＵと同じ予測モードを使用して予測されるケースまたは事例をビデオエンコーダ２０がビデオデコーダ３０に示し得るメカニズムを提供する。以下の表２は、クロマＰＵについてのクロマモードをシグナリングするためにビデオエンコーダ２０が使用し得るモード配列を指定する。例えば、１つのイントラコード化されたクロマＰＵは、平面モード（ＩＮＴＲＡ＿ＰＬＡＮＡＲ）、垂直モード（ＩＮＴＲＡ＿ＡＮＧＵＬＡＲ２６）、水平モード（ＩＮＴＲＡ＿ＡＮＧＵＬＡＲ１０）、ＤＣモード（ＩＮＴＲＡ＿ＤＣ）、および導出モード（ＤＭ）を含む５つのモードのうちの１つから選択されたモードを使用して予測されることができる。ＤＭは、対応する選択されたルーマＰＵを予測するために使用されるイントラ予測モードになるように設定される。例えば、対応する選択されたルーマＰＵが、１１に等しいインデックスを有するイントラモードでコード化される場合、ＤＭは、１１に等しいインデックスを有するイントラモードに設定される。
[0099]導出モードが、符号化済みビデオビットストリームにおけるＰＵについて示される場合、ビデオデコーダ３０は、対応するルーマＰＵに使用された予測モードを使用してクロマＰＵに対して予測を実行し得る。導出モードが、常に存在する予測モードのうちの１つを参照するときに生じる可能性のある．問題を緩和するために、ビデオエンコーダ２０およびビデオデコーダ３０は、重複モードの代わりとして、指定された代替モードを使用し得る。上の表２に示されるように、ビデオエンコーダ２０およびビデオデコーダ３０は、冗長性を取り除くために、「角度（３４）モード」とも呼ばれる「ＩＮＴＲＡ＿ＡＮＧＵＬＡＲ３４」クロマ代替モードを代わりとして使用し得る。例えば、クロマＰＵとルーマＰＵとの間の関係性は、１対１または多数対１であり、ビデオエンコーダ２０およびビデオデコーダ３０は、単一の対応するルーマＰＵに適用可能な予測モードを選択することで、クロマＰＵについての予測モードを決定し得る。
[0100]しかしながら、いくつかの事例では、１つのクロマＰＵは、複数のルーマＰＵに対応し得る。単一のクロマＰＵが複数のルーマＰＵに対応するシナリオは、クロマ符号化および復号に関して、例外または「特別なケース」と考えられる。例えば、これらの特別なケースのうちのいくつかでは、１つのクロマＰＵが、４つのルーマＰＵに対応し得る。クロマとルーマの関係性が１対多数である特別なケースでは、ビデオエンコーダ２０およびビデオデコーダ３０は、対応する左上ルーマＰＵに使用される予測モードを選択することで、クロマＰＵについての予測モードを決定し得る。
[0101]ビデオエンコーダ２０およびビデオデコーダ３０は、ビデオデータのブロックについてクロマ予測モードを示すデータをエントロピーコード化（それぞれ、エントロピー符号化およびエントロピー復号）し得る。クロマモードコード化にしたがって、ビデオエンコーダ２０は、１−ｂシンタックス要素（０）を単一の最も頻繁に生じる導出モードに割り当て、３−ｂシンタックス要素（それぞれ１００、１０１、１１０、および１１１）を残りの４つのモードの各々に割り当て得る。ビデオエンコーダ２０およびビデオデコーダ３は、１つのコンテキストモデルを有する最初のビンだけをコード化し得、（必要であれば）残りの２つのビンをバイパスコード化し得る。
[0102]ビデオエンコーダ２０およびビデオデコーダ３０は、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）にしたがってビデオデータをエントロピーコード化（それぞれエントロピー符号化およびエントロピー復号）し得る。ＣＡＢＡＣは、Ｈ．２６４／ＡＶＣにおいて最初に導入されたエントロピーコード化の方法であり、Ｄ．Ｍａｒｐｅ，Ｈ．Ｓｃｈｗａｒｚ、およびＴ．Ｗｉｅｇａｎｄによる「Context-based adaptive binary arithmetic coding in the H.264/AVC video compression standard」，IEEE Trans. Circuits Syst Video Technol.，vol. 13，no. 7，pp. 620-636，２００３年７月、に記載されている。ＣＡＢＡＣは現在、高効率ビデオコーディング（ＨＥＶＣ）ビデオコーディング規格において使用されている。ビデオエンコーダ２０メイビデオデコーダ３０は、ＨＥＶＣに対して実行されようなＣＡＢＡＣと類似した方法でエントロピーコード化のためにＣＡＢＡＣを使用し得る。
[0103]ＣＡＢＡＣは、二値化、コンテキストモデリング、および算術コーディングという３つの主要の機能を含む。二値化機能は、ビンストリングと呼ばれるバイナリシンボル（ビン）にシンタックス要素をマッピングする。コンテキストモデリング機能は、ビンの確率を推定する。（バイナリ算術コーディングとも呼ばれる）算術コーディング機能は、推定された確率に基づいてビンをビットに圧縮する。
[0104]ビデオエンコーダ２０およびビデオデコーダ３０は、ＨＥＶＣにおいて提供されるいくつかの異なる二値化プロセスのうちの１つまたは複数を使用してＣＡＢＡＣのために二値化を実行し得る。ＨＥＶＣにおいて提供される二値化プロセスは、単項（Ｕ）、短縮単項（ＴＵ）、ＥＧｋ（kth-order Exp-Golomb）、および固定長（ＦＬ）技法を含む。これらの二値化プロセスの詳細は、Ｖ．ＳｚｅおよびＭ．Ｂｕｄａｇａｖｉによる「High throughput CABAC entropy coding in HEVC」，IEEE Transactions on Circuits and Systems for Video Technology（ＴＣＳＶＴ），vol. 22，no. 12，pp. 1778-1791，２０１２年１２月、に記載されている。
[0105]単項ベースの符号化にしたがって、ビデオエンコーダ２０は、長さＮ＋１のビンストリングをシグナリングし得、ここで、「Ｎ」は、整数値を表し、最初のＮ個のビンは（値が）１であり、最後のビンは（値が）０である。単項ベース復号にしたがって、ビデオデコーダ３０は、ビンの０値をサーチし得る。０値のビンを検出すると、ビデオデコーダ３０は、シンタックス要素が完結したと決定し得る。
[0106]短縮単項コード化によれば、ビデオエンコーダ２０は、単項コード化のケースより１つ少ないビンを符号化有し得る。例えば、ビデオエンコーダ２０は、シンタックス要素の最大の可能な値に最大値を設定し得る。最大値は、ここでは、「ｃＭａｘ」と表される。（Ｎ＋１）＜ｃＭａｘであるとき、ビデオエンコーダ２０は、単項コード化と同じシグナリングをインプリメントし得る。しかしながら、（Ｎ＋１）＝ｃＭａｘであるとき、ビデオエンコーダ２０は、すべてのビンをそれぞれの値１に設定し得る。ビデオデコーダ３０は、いつシンタックス要素が完結するかを決定するために、ｃＭａｘ数のビンが検査されるまで、０値のビンをサーチし得る。単項および短縮単項コード化において使用されるビンストリングの態様と、それらの対比が以下の表３に例示されている。表３に例示されている対照的なビン値は、太字の斜体を使用して表される（called out）。
[0107]ビデオエンコーダ２０およびビデオエンコーダ３０はまた、ＣＡＢＡＣのコンテキストモデリング態様を実行し得る。コンテキストモデリングは、比較的正確な確率推定を提供し、これは、高効率コード化を達成する態様である。したがって、コンテキストモデリングは、適応プロセスであり、「高度に適応する」と説明されることがある。異なるコンテキストモデルが、異なるビンに対して使用されることができ、ここで、コンテキストモデルの確率は、前にコード化されたビンの値に基づいて更新される。同様の分配を有するビンは、同じコンテキストモデルを共有することが多い。ビデオエンコーダ２０および／またはビデオデコーダ３０は、シンタックス要素のタイプ、シンタックス要素におけるビン位置（binIdx）、ルーマ／クロマ、隣接情報、等を含む１つまたは複数の要因に基づいて、ビンごとにコンテキストモデルを選択し得る。
[0108]ビデオエンコーダ２０およびビデオデコーダ３０は、ビンコーデイング（場合によっては、ビン符号化またはビン復号）の各インスタンス後にコンテキストスイッチを実行し得る。ビデオエンコーダ２０およびビデオデコーダ３０は、コンテキストメモリに７ビットのエントリ（確率状態についての６ビットとＭＰＳ（most probable symbol）についての１ビット）として確率モデルを記憶し得、コンテキスト選択論理によって計算されるコンテキストインデックスを使用して確率モデルをアドレス指定し得る。ＨＥＶＣは、Ｈ．２６４／ＡＶＣと同じ確率更新方法を提供する。しかしながら、ＨＥＶＣベースのコンテキスト選択論理は、スループットを改善するために、Ｈ．２６４／ＡＶＣコンテキスト選択論理に対して修正される。ビデオエンコーダ２０およびビデオデコーダ３０はまた、それぞれ、ＣＡＢＡＣエントロピー符号化および復号に対して確率表現を使用し得る。ＣＡＢＡＣの場合、６４個の代表的な確率値ｐσ∈［０．０１８７５，０．５］が、以下の再帰方程式によって、ＬＰＳ（least probable symbol）に対して導出された：
すべてのσ＝１，．．．，６３について、ｐσ＝α＊ｐσ−１
ここで、α＝（０．０１８７５／０．５）１／６３
[0109]上の式では、確率のセットの選択されたスケーリング係数α≒０．９４９２および濃度Ｎ＝６４の両方が、確率表現の精度と適応速度との間の妥協を表す。上の式において使用されるパラメータは、確率表現の精度とより高速な適用に対する要望との間の比較的良好な妥協を示している。ＭＰＳの確率は、１からＬＰＳを差し引いた確率（すなわち、（１−ＬＰＳ））に等しい。したがって、ＣＡＢＡＣによって表されることができる確率範囲は、［０．０１８７５，０．９８１２５］である。この範囲の上界（ＭＰＳ確率）は、１から下限を差し引いたもの（すなわち、１−ＬＰＳ確率）に等しい。すなわち、１−０．０１８７５＝０．９８１２５である。
[0110]特定のスライスを符号化また復号する前に、ビデオエンコーダ２０およびビデオデコーダ３０は、いくつかの予め定義された値に基づいて確率モデルを初期化し得る。例えば、「ｑｐ」で表される入力量子化パラメータと「initVal」で表される予め定義された値とを前提として、ビデオエンコーダ２０および／またはビデオデコーダ３０は、次のように（「状態」および「ＭＰＳ」で表される）確率モデルの７ビットのエントリを導出し得る：
qp = Clip3(0, 51, qp);
slope = ( initVal >>4)*5 - 45;
offset = ((initVal &15)<<3)-16;
initState= min( max( 1, ( ( ( slope * qp ) >> 4 ) + offset ) ), 126 );
MPS = (initState >= 64 );
state index = ( (mpState? (initState - 64) : (63 - initState)) <<1) + MPS;
[0111]導出された状態インデックスは、ＭＰＳ情報を暗黙的に含む。すなわち、状態インデックスが偶数の値であるとき、ＭＰＳ値は０に等しい。逆に、状態インデックスが奇数の値であるとき、ＭＰＳ値は１に等しい。initValの値は、８ビット精度で［０，２５５］の範囲内である。
[0112]予め定義されたinitValは、スライス依存型である。すなわち、ビデオエンコーダ２０は、特に、それぞれ、Ｉスライス、Ｐスライス、およびＢスライスのコード化のために使用される確率モデルのためにコンテキスト初期化パラメータの３つのセットを使用し得る。このように、ビデオエンコーダ２０は、異なるコード化シナリオおよび／または異なるタイプのビデオコンテンツへのより良好な適合が潜在的に達成されることができるように、これら３つのスライスタイプについて３つの初期化テーブルから選ぶことが可能にされる。
[0113]最近のＪＥＭ３．０の進歩は、イントラモードコード化に関する開発を含む。ＪＥＭ３．０のこれらの最近の開発にしたがって、ビデオエンコーダ２０およびビデオデコーダ３０は、６つの最確モード（ＭＰＭ）でイントラモードコード化を実行し得る。Ｖ．Ｓｅｒｅｇｉｎ，Ｘ．Ｚｈａｏ，Ａ．Ｓａｉｄ，およびＭ．Ｋａｒｃｚｅｗｉｃｚによる「Neighbor based intra most probable modes list derivation」，ＪＶＥＴ−Ｃ００５５，ジュネーブ，２０１６年５月、記載されているように、ＨＥＶＣにおける３３個の角度モードは、６５個の角度モードに加え、６つの最確モード（ＭＰＭ）を有するＤＣモードよび平面モードに拡張される。ビデオエンコーダ２０は、イントラルーマモードが、（上で挙げたＪＶＥＴ−Ｃ００５５に記載されているように）６つのモードを含むＭＰＭ候補リストに含まれているかどうかを示すために１ビットフラグ（例えば、「ＭＰＭフラグ」）を符号化し得る。イントラルーマモードがＭＰＭ候補リストに含まれている（それによって、ビデオエンコーダ２０に、ＭＰＭフラグを正の値に設定させる）場合、ビデオエンコーダ２０は、リスト中のＭＰＭ候補のうちのどれがイントラルーマモードであるかを示すために、ＭＰＭ候補のインデックスをさらに符号化し、シグナリングし得る。そうでない場合（すなわち、ビデオエンコーダ２０がＭＰＭフラグを負の値に設定する場合）、ビデオエンコーダ２０は、残りのイントラルーマモードのインデックスをさらにシグナリグし得る。
[0114]ＪＥＭ３．０アドバンスメントのこれらの態様によれば、ビデオデコーダ３０は、イントラルーマモードがＭＰＭ候補リストに含まれているかどうかを決定するために、シグナリングされた符号化済みビデオビットストリームを受信すると、ＭＰＭフラグを復号し得る。ＭＰＭフラグが正の値に設定されるとビデオデコーダ３０が決定する場合、ビデオデコーダ３０は、ＭＰＭ候補リストからイントラルーマモードを識別するために、受信したインデックスを復号し得る。逆に、ＭＰＭフラグが負の値に設定されるとビデオデコーダ３０が決定すると、ビデオデコーダ３０は、残りのイントラルーマモードのインデックスを受信および復号し得る。
[0115]最近のＪＥＭ３．０の進歩また、適応型マルチコア変換に関してもなされている。ＨＥＶＣで用いられるＤＣＴ−ＩＩおよび４×４ＤＳＴ−ＶＩＩに加えて、ＡＭＴ（Adaptive Multiple Transform）スキームが、インターコード化されたブロックおよびイントラコード化されたブロックの両方についての残差コード化のために使用される。ＡＭＴは、ＨＥＶＣにおいて現在定義されている変換以外のＤＣＴ／ＤＳＴファミリからの複数の選択された変換を利用する。ＪＥＭ３．０の新たに導入された変換マトリックは、ＤＳＴ−ＶＩＩ、ＤＣＴ−ＶＩＩＩ、ＤＳＴ−Ｉ、およびＤＣＴ−Ｖである。
[0116]イントラ残差コード化の場合、異なるイントラ予測モードの異なる残差統計値により、ビデオエンコーダ２０およびビデオデコーダ３０は、モード依存型変換候補選択プロセスを使用し得る。３つの変換サブセットは、以下の表４に示されるように定義されており、ビデオエンコーダ２０および／またはビデオデコーダ３０は、以下の表５において指定されているように、イントラ予測モードに基づいて、変換サブセットを選択し得る。
[0117]サブセットの概念では、ビデオデコーダ３０は、最初に、以下の表６に基づいて、変換サブセットを識別し得る。例えば、変換サブセットを識別するために、ビデオデコーダ３０は、１の値に設定されたＣＵレベルのＡＭＴフラグでシグナリングされるＣＵのイントラ予測モードを使用し得る。その後、水平変換および垂直変換の各々について、ビデオデコーダ３０は、以下の表７にしたがって、識別された変換サブセット中の２つの変換候補のうちの１つを選択し得る。水平変換および垂直変換の各々についての選択される変換候補は、フラグで明示的にシグナリングされるデータに基づいて選択される。しかしながら、インター予測残差について、ビデオデコーダ３０は、すべてのインターモードに対してならびに水平変換および垂直変換の両方に対して、ＤＳＴ−ＶＩＩおよびＤＣＴ−ＶＩＩＩから構成される１つの変換セットだけを使用し得る。
[0118]最近のＪＥＭ３．０の進歩は、ビデオコード化のためのＬＭ（線形モデル）予測モードに関してなされている。ビデオエンコーダ２０およびビデオデコーダ３０のような本開示のビデオコード化デバイスは、ビデオ符号化およびビデオ復号の際に色フォーマットおよび色空間の態様を処理し得る。カラービデオは、マルチメディアシステムにおいて本来の役割を果たし、ここで、様々な色空間が、色を効率的に表すために使用される。色空間は、複数の成分を使用して数値で色を指定する。一般的な色空間は「ＲＧＢ」色空間であり、ここでは、色が、３つの原色成分値（すなわち、赤、緑、青）の組合せとして表される。カラービデオ圧縮の場合、Ａ．ＦｏｒｄおよびＡ．Ｒｏｂｅｒｔｓによる「Colour space conversions」，ウェストミンスタ大学，ロンドン，Tech. Rep.，１９９８年８月、に記載されているように、ＹＣｂＣｒ色空間が広く用されている。ＹＣｂＣｒは、線形変換を介して、ＲＧＢ色空間から比較的容易に変換されることができる。ＲＧＢからＹＣｂＣｒへの変換では、異なる成分間の冗長性、すなわち、成分間冗長性、は、結果として得られるＹＣｂＣｒ色変換において大幅に低減される。
[0119]ＹＣｂＣｒの１つの利点は、Ｙ信号が輝度情報を伝達するため、白黒ＴＶとの後位互換性である。加えて、クロミナンス帯域幅は、ＲＧＢでのサブサンプリングより大幅に少ない主観的インパクトにより、４：２：０クロマサンプルフィーマットでＣｂおよびＣｒ成分をサブサンプリングすることで低減されることができる。これらの利点により、ＹＣｂＣｒは、ビデオ圧縮における主要の色空間である。ビデオ圧縮において使用されるＹＣｏＣｇのような他の色空間も存在する。例示を目的として、使用される実際の色空間に関わらず、Ｙ、Ｃｂ、Ｃｒ信号は、本開示全体にわたって、ビデオ圧縮スキームにおける３つの色成分を表すために使用される。４：２：０サンプリングでは、２つのクロマアレイ（ＣｂおよびＣｒ）の各々は、ルーマアレイ（Ｙ）の半分の高さおよび半分の幅を有する。
[0120]図８は、ピクチャにおけるルーマおよびクロマサンプルの公称の垂直および水平ロケーションの例を例示する概念図である。図８に示される、ピクチャにおけるルーマおよびクロマサンプルの公称の垂直および水平相対ロケーションは、一般に、４：２：０サンプリングフォーマットによって提供されるようなロケーションに対応する。
[0121]ビデオコード化のためのＬＭ予測モードの態様が以下の段落で述べられる。ＹＣｂＣｒ色空間において成分間冗長性は大幅に低減されるが、３つの色成分間の相関は、依然としてＹＣｂＣｒ色空間に存在する。色成分間の相関をさらに低減することでビデオコーディング性能を改善するために、様々な技法が研究されている。４：２：０クロマビデオコード化に関して、ＨＥＶＣ規格の開発中に、線形モデル（ＬＭ）予測モードが研究された。ＬＭ予測モードの態様は、Ｊ．Ｃｈｅｎ，Ｖ．Ｓｅｒｅｇｉｎ，Ｗ．−Ｊ．Ｈａｎ，Ｊ．−Ｓ．Ｋｉｍ、およびＢ．−Ｍ．Ｊｏｅｎによる「CE6.a.4: Chroma intra prediction by reconstructed luma samples」、ＩＴＵ−Ｔ ＳＧ１６ ＷＰ３とＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１とからなるＪＣＴ−ＶＣ（Joint Collaborative Team on Video Coding），ＪＣＴＶＣ−Ｅ２６６，第５回会合：ジュネーブ，２０１１年３月１６−２３日、に記載されている。
[0122]ＬＭ予測モードにしたがって予測を実行するとき、ビデオエンコーダ２０およびビデオデコーダ３０は、以下の式（１）に示される線形モデルを使用することで、同じブロックのダウンサンプリングされた再構築ルーマサンプルに基づいてクロマサンプルを予測し得る。
ここで、ｐｒｅｄＣ（ｉ，ｊ）は、ブロック中のクロマサンプルの予測を表し、ｒｅｃＬ（ｉ，ｊ）は、同じブロックのダウンサンプリングされた再構築ルーマサンプルを表す。パラメータαおよびβは、現在のブロックの周りの因果的再構築サンプルから導出される。
[0123]図９は、線形モデル（ＬＭ）モードにしたがった予測において使用されるパラメータの導出のために使用されるサンプルのロケーションを例示する概念図である。図９に描写される選択された基準サンプルの例は、上の式（１）において使用されるようなαおよびβの導出に関する。クロマブロックのサイズがＮ×Ｎと表され、ここでＮが整数である場合、ｉおよびｊは両方とも、［０，Ｎ］の範囲内にある。
[0124]ビデオエンコーダ２０およびビデオデコーダ３０は、以下の式（２）にしたがって、現在のブロックの周りの隣接する再構築ルーマおよびクロマサンプル間の回帰誤差を低減するかまたは潜在的に最小化することで、式（１）中のパラメータαおよびβを導出し得る。
パラメータαおよびβは、以下のように解かれる：
ここで、ｘiは、ダウンサンプリングされた再構築ルーマ基準サンプルを表し、ｙiは、再構築されたクロマ基準サンプルを表し、Ｉは、基準サンプルの量（例えば、カウント）を表す。ターゲットのＮ×Ｎクロマブロックの場合、左および上の両方の因果的サンプルが利用可能なとき、合計の関連サンプルの数（Ｉ）は２Ｎに等しい。左または上の因果的サンプルのみが利用可能なとき、合計の関連サンプルの数（Ｉ）はＮに等しい。
[0125]要約すれば、ＬＭ予測モードが適用されるとき、ビデオエンコーダ２０および／またはビデオデコーダ３０は、以下にリストされた順序で以下のステップを呼び出し得る：
ａ）隣接するルーマサンプルをダウンサンプリングする；
ｂ）線形パラメータ（すなわち、αおよびβ）を導出する；
ｃ）現在のルーマブロックをダウンサンプリングし、ダウンサンプリングされたルーマブロックと線形パラメータとから予測を導出する。
[0126]コード化効率をさらに改善するために、ビデオエンコーダ２０および／またはビデオデコーダ３０は、隣接するサンプルｘiおよび対応するルーマブロック内のダウンサンプリングされたルーアサンプルｒｅｃＬ（Ｉ，ｊ）を導出するために、（１，２，１）および（１，１）というダウンサンプリングフィルタを利用し得る。
[0127]最近のＪＥＭ３．０の進歩はまた、クロマ成分間の予測に関してもなされている。ＪＥＭでは、ＬＭ予測モードは、２つのクロマ成分間の予測に拡張される。例えば、Ｃｒ成分は、Ｃｂ成分から予測される得る。再構築サンプル信号を使用する代わりに、ビデオエンコーダ２０および／またはビデオデコーダ３０は、残差ドメインにおいて成分間予測を適用し得る。例えば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、最終のＣｒ予測を形成するために、加重された再構築Ｃｂ残差を元のＣｒイントラ予測に加えることで、成分間予測の残差ドメイン適用をインプリメントし得る。この動作の例は、以下の式（３）に示される：
[0128]ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＬＭモードで導出されるように、スケーリング係数αを導出し得る。しかしながら、１つの相違点は、導出されたスケーリング係数がデフォルト値（−０．５）に向かってバイアスがかけられるような、誤差関数におけるデフォルトのα値に対する回帰コストの加算である。ＬＭ予測モードは、１つの追加のクロマイントラ予測モードとして加えられる。この点において、ビデオエンコーダ２０は、クロマイントラ予測モードを選択するためにクロマ成分についてのもう１つのＲＤコストチェックを加え得る。
[0129]四分木二分木（ＱＴＢＴ）構造の態様が以下の段落に説明されている。ＶＣＥＧ proposal ＣＯＭ１６−Ｃ９６６（Ｊ．Ａｎ，Ｙ．−Ｗ．Ｃｈｅｎ，Ｋ．Ｚｈａｎｇ，Ｈ．Ｈｕａｎｇ，Ｙ．−Ｗ．Ｈｕａｎｇ，およびＳ．Ｌｅｉによる「Block partitioning structure for next generation video coding」，国際電気通信連合，ＣＯＭ１６−Ｃ９６６，２０１５年９月）において、ＱＴＢＴ区分化スキームが、ＨＥＶＣを超える将来的なビデオコーディング規格のために提案された。シミュレーションは、ＣＯＭ１６−Ｃ９６６で提案されたＱＴＢＴ構造が、ＨＥＶＣにおいて使用される四分木構造より効率的であることを示した。ＣＯＭ１６−Ｃ９６６の提案されたＱＴＢＴ構造では、コード化ツリーブロック（ＣＴＢ）は、最初に、四分木構造にしたがって区分化され、ここでは、１つのノードの四分木分割は、このノードが最小許容四分木リーフノードサイズ（MinQTSize）に達するまで反復されることができる。
[0130]ＱＴＢＴ構造によれば、四分木リーフノードサイズが、最大許容二分木ルートノードサイズ（MaxBTSize）より大きくない場合、四分木リーフノードは、二分木構造にしたがってさらに区分化されることができる。所与のノードの二分木分割は、このノードが最小許容二分木リーフノードサイズ（MinBTSize）に達するまでまたは反復分割が最大許容二分木深度（MaxBTDepth）に達するまで反復されることができる。二分木リーフノードは、すなわち、これ以上の区分化なしに予測（例えば、イントラピクチャまたはインターピクチャ予測）および変換に使用されることができるＣＵである。
[0131]二分木分割にしたがって、ビデオエンコーダ２０および／またはビデオデコーダ３０は、対称水平分割および対称垂直分割という２つの分割タイプをインプリメントし得る。ＱＴＢＴ区分化構造の一例では、ＣＴＵサイズは、１２８×１２８（すなわち、１２８×１２８のルーマサンプルと２つの対応する６４×６４のクロマサンプル）に設定され、MinQTSizeは、１６×１６に設定され、MaxBTSizeは、６４×６４に設定され、（幅と高さの両方についての）MinBTSizeは、４に設定され、MaxBTDepthは、４に設定される。ビデオエンコーダ２０および／またはビデオデコーダ３０は、四分木リーフノードを生成するために、最初にＱＴＢＴスキームの四分木区分化部分をＣＴＵに適用し得る。四分木リーフノードは、１６×１６（すなわち、MinQTSize）から１２８×１２８（すなわち、ＣＴＵサイズ）までのサイズを有し得る。
[0132]四分木リーフノードが１２８×１２８である場合、ビデオエンコーダ２０および／またはビデオデコーダ３０は、このノードがMaxBTSize（このケースでは、６４×６４）を超えるため、ＱＴＢＴスキームの二分木部分を使用して四分木リーフノードをこれ以上分割しないであろう。そうでない場合（すなわち、ノードサイズが６４×６４のMaxBTSizeを超えない場合）、ビデオエンコーダ２０および／またはビデオデコーダ３０、ＱＴＢＴ構造の二分木区分化部分を使用して四分木リーフノードをさらに区分化し得る。したがって、四分木リーフノードはまた、ＱＴＢＴスキームの二分木部分のためのルートノードでもあり、ゆえに、０の二分木深度を有する。反復二分木区分化により、二分木深度がMaxBTDepth（すなわち、４）に達すると、ビデオエンコーダ２０および／またはビデオデコーダ３０は、このリーフノードに対してあらゆる種類のこれ以上の分割を実行しない。ＱＴＢＴスキームの二分木部分が、MinBTSize（すなわち、４）に等しい幅を有する二分木ノードに帰着するとき、ビデオエンコーダ２０および／またはビデオデコーダ３０は、このノードのこれ以上の水平分割を実行しないであろう。同様に、ＱＴＢＴスキームの二分木部分が、MinBTSize（すなわち４）に等しい高さを有する二分木ノードに帰着するとき、ビデオエンコーダ２０および／またはビデオデコーダ３０は、このノードのこれ以上の垂直分割を実行しないであろう。（仮にも区分化が二分木区分化に達すると）ＱＴＢＴスキームの二分木部分のリーフノードは、すなわち、これ以上の区分化なしに予測および変換によってさらに処理されるＣＵである。
[0133]図１０は、ＱＴＢＴ区分化スキームの態様を例示する概念図である。図１０の左側にあるブロック図は、ＱＴＢＴ区分化構造にしたがったブロック１６２の区分化の例を例示する。ＱＴＢＴ区分化スキームの四分木区分化態様は、ブロック１６２において実線を使用して例示され、ＱＴＢＴ区分化スキームの二分木区分化態様は、ブロック１６２において破線を使用して例示される。ブロック１６２は、ＱＴＢＴスキームの四分木部分のみ呼び出されるケースでは正方形のリーフノードへと区分化され、（四分木区分化部分と組み合わせて呼び出されても呼び出されなくても）ＱＴＢＴスキームの二分木部分が呼び出されるケースでは非正方形の長方形のリーフノードへと区分化される。複数の変換が可能であるＨＥＶＣの区分化技法とは対照的に、ＱＴＢＴ区分化スキームは、ＰＵサイズが常にＣＵサイズに等しくなるシステムを提供する。
[0134]図１０の右側にある概略図は、ツリー構造１６４を例示する。ツリー構造１６４は、図１０のブロック１６２に関して例示される区分化に関する対応するツリー構造である。ツリー構造１６４のケースでもまた、図１０のＱＴＢＴ区分化スキームの後援（auspices）内で、実線は四分木分割を示し、破線は二分木分割を示す。ツリー構造１６４において破線を使用して例示される二分木部分の分割（すなわち、非リーフ）ノードごとに、ビデオエンコーダ２０は、どの分割タイプ（すなわち、水平または垂直）が使用されるかを示すためにそれぞれの１ビットフラグをシグナリングし得る。ＱＴＢＴ区分化のいくつかのインプリメンテーションによれば、ビデオエンコーダ２０は、フラグを、水平分割を示すためにゼロ（０）の値におよび垂直分割を示すために１の値に設定し得る。ＱＴＢＴ区分化構造の四分木分割部分については、四分木分割が常にブロックを同じサイズの４つのサブブロックへと水平および垂直に分割するため、分割タイプを示す必要はないことは認識されるであろう。
[0135]図１１Ａおよび１１Ｂは、ＱＴＢＴ区分化スキームにしたがった、対応するルーマおよびクロマブロックについての別個の区分化構造の例を例示する。ＱＴＢＴブロック区分化技術は、対応するルーマおよびクロマブロックが別個のＱＴＢＴベースの区分化構造を有するという特徴を可能にするおよびサポートする。ＱＴＢＴ区分化スキームに基づいて、ＰスライスおよびＢスライスの場合は、１つのＣＴＵ中の対応するルーマおよびクロマＣＴＵは、同じＱＴＢＴベースの区分化構造を共有する。しかしながら、Ｉスライスの場合は、ルーマＣＴＵは、第１のＱＴＢＴベースの区分化構造によってＣＵへと区分化されることができ、クロマＣＴＵは、第１のＱＴＢＴベースの区分化構造とは異なる場合も異ならない場合もある第２のＱＴＢＴベースの区分化構造によってクロマＣＵへと区分化される。ゆえに、Ｉスライス中のＣＵは、１つのルーマ成分のコード化ブロックまたは２つのクロマ成分のコード化ブロックから構成され得、ＰおよびＢスライス中のＣＵの場合、このＣＵは、すべての３つの色成分のコード化ブロックから構成され得る。
[0136]ＩスライスのためにＱＴＢＴによってサポートされる別個のツリー構造は、クロマコード化に関する態様を含む。例えば、ＪＥＭは、１つのＰＵにつき６つのクロマモードを可能にする。ＤＭモードの使用は、ビデオエンコーダ２０および／またはビデオデコーダ３０が、クロマＰＵについて、対応するルーマＰＵについての予測モードと同じ予測モードを利用することを示す。上述したように、Ｉスライスの場合、ルーマブロックおよび対応するクロマのためのＱＴＢＴベースの区分化構造は異なり得る。そのため、ＤＭモードがＩスライスにおいて使用されるとき、ビデオエンコーダ２０および／またはビデオデコーダ３０は、クロマＰＵについての予測を実行するために、左上位置をカバーするＰＵのルーマ予測モードを継承し得る。ルーマブロックおよびその対応するクロマブロックが常に同じツリー構造を共有するＨＥＶＣの区分化技法とは対照的に、ＪＥＭ３．０のＱＴＢＴベースの区分化は、図１１Ａおよび１１Ｂに示されるようなルーマツリー構造とクロマツリー構造との間の起こり得る差分を可能にする。
[0137]図１１Ａおよび１１Ｂは、Ｉスライス中の１つのＣＴＵのＱＴＢＴ区分化構造の例を例示する。図１１Ａは、ルーマブロック１７２を例示し、ここで、左区分１７４は、上下で挟み込む中括弧（upper and lower bookending braces）を使用して表されている。図１１Ｂは、対応するクロマブロック１７６を例示し、ここで、左区分１７８が、上下で挟み込む中括弧を使用して表されている。それぞれの左区分１７４および１７８は、図１１Ａおよび１１Ｂに示されるように、より微細な区分を含む。Ｌ（ｉ）、ここで、「ｉ」は、それぞれの区分内で例示されるそれぞれの整数値を表す、は、それぞれの区分のためのルーマイントラ予測モードがｉに等しいインデックスを有することを示す。図１１Ａおよび１１Ｂに例示される例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＤＭモードでクロマブロック１７６の左区分を符号化／復号し得る。ゆえに、ビデオエンコーダ２０および／またはビデオデコーダ３０は、クロマブロック１７６の左区分１７８を予測するために、左上の対応するルーマブロック区分からＬＭモードを選び得る。図１１Ａおよび１１Ｂに例示される使用事例シナリオでは、ビデオエンコーダ２０および／またはビデオデコーダ３０は、「ｉ」がルーマブロック１７２の左上区分において１の値を有するため、クロマブロック１７６の左区分１７８を符号化／復号するために、１に等しいインデックスを有するイントラ予測モードを選択し得る。
[0138]上の表７は、ビデオエンコーダ２０がクロマモードをシグナリングするために使用し得るモード配列を指定する。導出モード（ＤＭ）が常に存在するモードのうちの１つを指すときに生じ得るクロマモードシグナリングにおける起こり得る冗長性を取り除くために、ビデオエンコーダ２０は、以下の表７．１に示されるように、重複モードの代わりになるために、角度（合計で６７個のイントラモードが存在する場合６６個の）モードを使用し得る。以下の表７．１に例示される使用事例シナリオでは、（ＩＮＴＲＡ＿ＡＮＧＵＬＡＲ６６と表される）角度モードは、「代替モード」と呼ばれる。
[0139]上述したように、ビデオエンコーダ２０およびビデオデコーダ３０は、クロマ予測モードのエントロピーコード化を実行し得る。クロマモードコード化では、１−ｂシンタックス要素（０）が、最も頻繁に生じる導出モードに割り当てられ、２つのビン（１０）が、ＬＭモードに割り当てられ、４−ｂシンタックス要素（１１００、１１０１，１１１０，１１１１）が残りの４つのモードに割り当てられる。最初の２つのビンは、１つのコンテキストモデルでコード化され、（必要であれば）残りの２つのビンは、バイパスコード化される。
[0140]本開示の技法は、上述した様々な技法の性能を改善することを対象としている。上述したように、ＪＥＭ３．０は、同じＣＴＵのためのクロマブロック区分化およびルーマブロック区分化に対して別個のツリー構造をサポートする。しかしながら、１つのクロマＰＵは、複数のルーマＰＵに対応し得る。ＪＥＭ３．０のＱＴＢＴ区分化態様にしたがって、クロマコード化のために複数のルーマＰＵからルーマイントラ予測モードのうちの１つだけを継承することは、準最適結果を提供し得、これは、本開示の様々な技法によって改善されることまたはできる限り最適化されることができる。追加的に、ＪＥＭにおける所与のＰＵにつての可能なクロマモードの総数は６である。しかしながら、ルーマコード化の場合、可能なモードの総数は、６７である。本開示の様々な技法は、クロマモードの総数を増加させることでコード化効率を改善し得る。
[0141]本開示の様々な技法は、以下に個条書きでリストされる。ビデオエンコーダ２０および／またはビデオデコーダ３０が、後述される様々な技法を、単独でまたは説明される技法の２つ以上の様々な組合せで適用し得ることは認識されるであろう。ビデオエンコーダ２０および／またはビデオデコーダ３０によって実行されるとして説明されているが、図２に例示されたビデオエンコーダ２０の１つまたは複数の構成要素および／または図３に例示されたビデオデコーダ３０の１つまたは複数の構成要素が本開示の様々な技法を実行し得ることは認識されるであろう。
[0142]以下の説明は、１つのクロマブロックのサイズをＷ×Ｈとして表す（ここで、「Ｗ」は、クロマブロックの幅であり、「Ｈ」は高さである）。スライス全体に対するクロマブロック中の左上画素の位置は、タプル（ｘ，ｙ）で表され、ここで、「ｘ」および「ｙ」は、それぞれ水平オフセットおよび垂直オフセットである。所与のクロマブロックに対応するルーマブロックは、（４：２：０色フォーマットのための）２Ｗ×２Ｈまたは（４：４：４色フォーマットのための）Ｗ×Ｈに等しいサイズを有する。スライス全体に対する対応するルーマブロック中の左上画素の位置は、（４：２：０のための）タプル（２ｘ，２ｙ）または（４：４：４のための）（ｘ，ｙ）で表される。以下に与えられる例は、４：２：０色フォーマットに関して説明される。本明細書で説明される技法が他の色フォーマットにも拡張可能であることは認識されるであろう。
[0143]本開示の特定の態様によれば、複数のＤＭモードが、クロマコード化に関して加えられ得、それによって、ビデオエンコーダ２０およびビデオデコーダ３０に利用可能な（ルーマブロックからの）利用可能なクロマ符号化および復号モードの数を増加させる。すなわち、本開示のこれらの態様によれば、ビデオエンコーダ２０およびビデオデコーダ３０は、対応するルーマブロックのために使用されるコード化モードを継承するために、単一のオプションより多くの数のＤＭオプションを有し得る。例えば、本開示の技法によれば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、対応するルーマブロックにおいて使用されるイントラ予測モードに基づいて、クロマブロックについてのＤＭイントラ予測モードを含む候補リストを生成し得る。ＤＭ候補リストにおける可能なクロマモードの総数を同じに維持することでコード化および帯域幅効率を保ちつつ、複数のＤＭを適用することを対象とした本開示の技法は、ＤＭが、既存の技法において使用されるデフォルトモードより良好な精度を提供するため、潜在的な精度の向上を提供する。
[0144]この例では、ビデオエンコーダ２０は、ＪＥＭ３．０において現在明記されているクロマモードをシグナリングし得る。しかしながら、ビデオエンコーダ２０が、クロマブロックのクロマコード化のためにＤＭモードを選択する場合、ビデオエンコーダ２０は、追加のシグナリングをインプリメントし得る。より具体的には、この例によれば、ビデオエンコーダ２０は、ＤＭモードがクロマブロックの符号化のために選択されたことを示すフラグを符号化し、シグナリングし得る。クロマブロックがＤＭモードで符号化されていることに基づいて、ビデオエンコーダ２０は、候補リストのどのモードがＤＭモードとして使用されたかを示すために、インデックス値を符号化し、シグナリングし得る。ビデオエンコーダ２０は、候補リストのサイズに基づいて、０と５との間のインデックス値を符号化し、シグナリングし得る。すなわち、ビデオエンコーダ２０は、合計で６つの候補を含むクロマ予測モードの候補リストを生成し得、すなわち、６という候補リストサイズに帰着する。
[0145]符号化されたクロマブロックがＤＭモードを使用して符号化されたことを示す値に設定されたフラグを受信することに基づいて、ビデオデコーダ３０は、クロマブロックについての復号モードが候補リストに含まれていると決定し得る。次に、ビデオデコーダ３０は、クロマモード候補リスト中のエントリを識別するインデックスを受信し、復号し得る。符号化されたクロマブロックがＤＭモードを使用しておよび符号化されたクロマブロックのために受信されたインデックス値を使用して符号化されたことを示すフラグに基づいて、ビデオデコーダ３０は、クロマモード候補リストから、クロマブロックの復号に使用するために特有のモードを選択し得る。このように、ビデオエンコーダ２０およびビデオデコーダ３０は、ＤＭモードがクロマブロックのコード化に選択される事例において、クロマブロックの符号化および復号に使用されることができる候補モードの数を増加させ得る。ビデオデコーダ３０は、候補リストのサイズに基づいて、０と５との間のインデックス値を復号し得る。すなわち、ビデオデコーダ３０は、合計で６つの候補を含むクロマ予測モードの候補リストを生成し得、すなわち、６という候補リストサイズに帰着する。
[0146]いくつかの例では、ビデオエンコーダ２０は、クロマブロックが線形モデル（ＬＭ）モードで符号化されるかどうかを示すために、最初に、フラグを符号化し、シグナリングし得る。これらの例では、ビデオエンコーダ２０は、候補リスト中のＤＭ候補のすべてを示すデータを用いて、（クロマブロックがＬＭ符号化されるか否かを示すための）シグナリングされたフラグに従い得る。このインプリメンテーションによれば、ビデオデコーダ３０は、符号化済みビデオビットストリームにおいて、クロマブロックがＬＭモードで符号化されるか否かを示す符号化されたフラグを受信し得る。ビデオデコーダ３０は、候補リスト中のＤＭ候補のすべてを示すデータを、符号化済みビデオビットストリーム中のＬＭフラグに続いて開始する位置から、解釈し得る。ゆえに、本開示の様々な例にしたがって、ビデオデコーダ３０が、ＤＭ候補リストを構築し得るか、または代替的に、符号化済みビデオビットストリーム中の全ＤＭ候補リストを受信し得るかのいずれかを行うことは認識されるであろう。ビデオデコーダ３０は、いずれのシナリオにおいても、候補リストから好適なＤＭモードを選択するために、シグナリングされたインデックスを使用し得る。
[0147]ビデオエンコーダ２０はまた、ＤＭ候補リストのＤＭに関してプルーニングをインプリメントし得る。すなわち、ビデオエンコーダ２０は、リストに含まれているＤＭのうちの２つが同一であるか否かを決定し得る。ビデオエンコーダ２０が、単一のＤＭの複数のインスタンス（すなわち、複数の同一のＤＭ）が候補リストに含まれていると決定する場合、ビデオエンコーダ２０は、同じＤＭの１つのインスタンスを除きすべてを取り除くことで冗長性を取り除き得る。すなわち、ビデオエンコーダ２０は、そのような同一のＤＭの厳密に１つのインスタンスが候補リストに残るようにリストをプルーニングし得る。
[0148]本開示のＤＭ候補リストベースの技法のいくつかの例では、ビデオエンコーダ２０は、デフォルトモードのうちの１つまたは複数に対して候補リスト中のＤＭ候補をプルーニングし得る。本開示のプルーニング技法にしたがって、デフォルトモードのうちの１つ（例えば、デフォルトモードリスト中の第Ｋのモード）がＤＭ候補リスト中のＤＭモードのうちの１つと同一であるとビデオエンコーダ２０が決定する場合、ビデオエンコーダ２０は、候補リスト中のそのようなＤＭモードを代替モードと置き換え得る。候補リスト中のプルーニングされたＤＭモードを置き換えることに加えて、ビデオエンコーダ２０は、（（max Intra Mode Index）−１−Ｋ）の値に等しいインデックスを有するモードに代替モードを設定し得る。ビデオエンコーダ２０が、候補リストに含まれるＤＭモードのすべてを示すデータをシグナリングするいくつかのインプリメンテーションでは、ビデオエンコーダ２０は、プルーニングされたＤＭ候補リストを反映するデータをシグナリングし得る。
[0149]ビデオデコーダ３０もまたＤＭ候補リスト構築を実行するいくつかの例では、ビデオデコーダ３０もまた、ＤＭ候補リストを確定するためにプルーニングを実行する。例えば、デフォルトモードのうちの１つ（例えば、デフォルトモードリスト中の第Ｋのモード）がＤＭ候補リスト中のＤＭモードのうちの１つと同一であるとビデオデコーダ３０が決定する場合、ビデオデコーダ３０は、候補リスト中のそのようなＤＭモードを代替モードと置き換え得る。候補リスト中のプルーニングされたＤＭモードを置き換えることに加えて、ビデオデコーダ３０は、（（max Intra Mode Index）−１−Ｋ）の値に等しいインデックスを有するモードに代替モードを設定し得る。
[0150]上で説明したＤＭ候補リストベースの技法のうちの１つまたは複数をインプリメントすることで、ビデオエンコーダ２０およびビデオデコーダ３０は、可能なクロマ予測モードの数を増加させ得る。上で説明したＤＭ候補リストベースの技法を介して利用可能なクロマモードの数の増加は、精確さを維持しつつコード化効率を向上させ得る。上で説明したように、様々な例では、ビデオデコーダ３０は、符号化済みビデオビットストリームを介してＤＭ候補リスト全体を受信し得る。また代替的に、ＤＭ候補リストを構築し、クロマブロックに関してＤＭ候補リストから予測モードを選択するためにシグナリングされたインデックスを使用し得る。ビデオデコーダ３０は、明示的にシグナリングされたＤＭ候補リストを受信するか、または代替的に、ＤＭ候補リストを構築するかのいずれかを行い得るため、様々なＤＭ候補リストベースの技法は、本明細書では、ビデオエンコーダ２０によって、そしてオプションでビデオデコーダ３０によって実行されていると説明される。
[0151]いくつかの例では、ビデオエンコーダ２０は、特定の領域（universe）内に、例えば、タイル内、スライス内、ピクチャ内、またはシーケンス内に、ＤＭ候補リストのサイズ（すなわち、ＤＭ候補リストに含まれる候補の総数）を固定し得る。いくつかのそのような例では、ビデオデコーダ３０が、ＤＭ候補リストを構築し、候補を選択するためにシグナリングされたインデックスを使用するように構成される場合、ビデオデコーダ３０はまた、特定の領域内に、例えば、タイル内、スライス内、ピクチャ内、またはシーケンス内に、ＤＭ候補リストのサイズ（すなわち、ＤＭ候補リストに含まれる候補の総数）を固定し得る。
[0152]いくつかの例では、ビデオエンコーダ２０は、対応する符号化されたビデオデータに関して帯域外でシグナリングされることができるメタデータ包含データ構造（metadata-containing data structure）において候補リストのサイズをシグナリングし得る。いくつかの非限定的な例として、ビデオエンコーダ２０は、スライスヘッダ、ピクチャパラメータセット（ＰＰＳ）、またはシーケンスパラメータセット（ＳＰＳ）のうちの任意のものにおいて候補リストのサイズをシグナリングし得る。いくつかの例によれば、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、候補リストのサイズがすべてのブロックサイズに対して同じになるように候補リストのサイズを予め定義するように構成され得る。代替的に、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、候補リストのサイズがブロックのサイズに依存して異なるように候補リストのサイズを予め定義するように構成され得る。
[0153]いくつかの例によれば、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、最大で３つの部分を含む（例えば、包含する）ようにＤＭ候補リストを構築し得る。これらの例では、ＤＭ候補リストの３つの部分は、以下を含む：（ｉ）対応するルーマブロックに対する特定の位置に関連するルーマイントラ予測モードの候補を含む第１の部分、（ｉｉ）対応するルーマブロック内のすべてのルーマブロックの関数から導出される候補を含む第２の部分、例えば、上の１つの例で説明するような、最も頻繁に使用されるルーマイントラ予測モード、および（ｉｉｉ）モードインデックスの特定のオフセットを有する、選択されたルーマイントラ予測モードから導出される候補を含む第３の部分。
[0154]一例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、候補の総数が、予め定義されたリストサイズ（すなわち、ＤＭモードの予め定義された総数）と等しくなるまで、最初の２つの部分からの候補をＤＭ候補リストに順番に挿入し得る。ＤＭ候補リストに含まれるモードに関してプルーニングプロセスを実行した後、候補リストのサイズが、依然として、ＤＭモードの予め定義された総数より小さい場合、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、リストの第３の部分から候補を挿入し得る。１つのそのような例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、第１の部分、それに続く第２の部分、そしてそれに続く第３の部分という順番に、３つの部分（または、プルーニングの結果に依存して２つの部分）からの候補を候補リストに挿入し得る。別の代替的な例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、第１の部分からの候補の前に第２の部分からの候補を挿入し得る。さらに別の代替的な例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、（例えば、第１の部分および第２の部分の候補をインターリーブまたは混ぜ合わさることで）第１の部分からの候補中に第２の部分からの候補を挿入し得る。
[0155]いくつかの例によれば、ＤＭ候補リストの第１の部分の候補は、対応するルーマブロックのコード化のために特定の位置から継承されたモードである。例えば、候補リストの第１の部分は、対応するルーマブロック中の次の位置から継承されたモードを含み得る：中央位置、左上位置、右上位置、左下位置、および右下位置。すなわち、この例では、候補リストの第１の部分は、対応するルーマブロックの４つのコーナーから継承されたモードを含み得る。１つのそのような例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、次の順序で、対応するルーマブロックの４つのコーナー位置から継承されたモードをＤＭ候補リストに挿入し得る：中央、左上、右上、左下、右下。別のそのような例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、次の順序で、対応するルーマブロックの４つのコーナー位置から継承されたモードをＤＭ候補リストに挿入し得る：中央、左上、右下、左下、右上。他の例では、順序は異なり得、上で説明した順序が非限定的な例であることは認識されるであろう。
[0156]一例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、対応するルーマブロックのすべての位置のイントラ予測モードを含むようにＤＭ候補リストの第１の部分を作成し得る。この例では、第１の部分が、対応するルーマブロックのイントラ予測モードのすべてを含むため、第２の部分は必要なくなり得る。追加的に、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、特定の順序で、対応するルーマブロック内のすべての単位をトラバースし得る。代替的に、または加えて、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、対応するルーマブロック内の出現の降順に基づく順序で追加モードをＤＭ候補リストに加え得る。
[0157]一例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、第３の部分を作成するために、リストに挿入される最初の１つまたは複数の候補にオフセットを適用し得る。加えて、第３の部分を作成する際、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、挿入された候補のプルーニングをさらに適用または実行し得る。１つの代替的な例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、隣接ブロックからの１つまたは複数のイントラクロマモードを含むように第３の部分を作成し得る。
[0158]本明細書で説明される技法のいくつかのインプリメンテーションによれば、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、ＣＵからＣＵに、ＰＵからＰＵに、またはＴＵからＴＵに、候補リストのサイズを適応的に変更し得る。一例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、３部分からなるＤＭ候補リスト作成インプリメンテーションに関して説明したように、第１の部分からの候補だけを加え得る。代替的に、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、第１および第２の部分からの候補だけをＤＭ候補リストに加え得る。いくつかの例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、同一のイントラ予測モードを取り除くために、プルーニングを実行し得る。ＩＩＩ．
[0159]ビデオエンコーダ２０がＤＭ候補リストをプルーニングする例では、最終のプルーニング後のＤＭ候補リスト中の候補の数が１に等しい場合、ビデオエンコーダ２０は、ＤＭインデックスをシグナリングしなであろう。いくつかの例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、短縮単項二値化を使用してＤＭ候補リスト内のＤＭインデックス値を二値化し得る。代替的に、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、単項二値化を使用してＤＭ候補リスト内のＤＭインデックス値を二値化し得る。
[0160]いくつかの例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、コンテキストモデルインデックスをビンインデックスに等しく設定し得る。代替的に、ＤＭインデックス値をコード化するためのコンテキストモデルの総数は、最大候補の数より小さいであろう。このケースでは、ビデオエンコーダ２０は、コンテキストモデルインデックスをｍｉｎ（Ｋ，ビンインデックス）に等しく設定し得、ここで、Ｋは、正の整数を表す。代替的に、ビデオエンコーダ２０は、コンテキストモデルで最初の数ビンだけを符号化し得、残りのビンをバイパスモードで符号化し得る。この例では、ビデオデコーダ３０は、コンテキストモデルで最初の数ビンだけを復号し得、残りのビンをバイパスモードで復号し得る。
[0161]代替的に、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、ＤＭ候補の総数、またはＣＵ、ＰＵ、またはＴＵサイズのうちの１つまたは複数に依存して、コンテキストコード化されるビンの数を決め得る。代替的に、最初のＭ個のビン（例えば、Ｍは１に等しい）の場合、コンテキストモデリングは、最終の（例えば、プルーニング後の）ＤＭ候補リスト中のＤＭ候補の総数、またはＣＵ／ＰＵ／ＴＵサイズ、または対応するルーマブロックの分割情報にさらに依存し得る。
[0162]いくつかの例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、二値化の前に候補リスト中の候補をさらに再順序付けし得る。一例では、ＣＵ／ＰＵ／ＴＵの幅がＣＵ／ＰＵ／ＴＵの高さより大きいとき、再順序付けは、候補のためのリアルイントラモードと水平イントラ予測モードとの間のイントラ予測モードインデックス差分に基づき得る。差分が小さいほど、ＤＭ候補リスト中の候補に割り当てられることとなるインデックスは小さくなり、割り当てられることとなる。別の例では、ＣＵ／ＰＵ／ＴＵの高さがＣＵ／ＰＵ／ＴＵの幅より大きいとき、再順序付けは、候補のためのリアルイントラモードと垂直イントラ予測モードとの間のイントラ予測モードインデックス差分に基づき得る。この例ではまた、差分が小さいほど、ＤＭ候補リスト中の候補に割り当てられることとなるインデックスは小さくなる。
[0163]代替的に、さらに、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、デフォルトモードに対してリスト中のすべてのＤＭ候補のプルーニングを実行し得る。デフォルトモードのうちの１つ（例えば、デフォルトモードリスト中の第Ｋのモード）がＤＭ候補リスト中のＤＭモードのうちの１つと同一である場合、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、ＤＭ候補リスト中のそのようなＤＭモードを、代替モードと置き換え得る。候補リスト中のプルーニングされたＤＭモードを置き換えることに加えて、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、（（max Intra Mode Index）−１−Ｋ）の値に等しいインデックスを有するモードに代替モードを設定し得る。
[0164]本開示のいくつかの技法によれば、ビデオエンコーダ２０およびビデオデコーダ３０は、ルーマイントラ予測モードとクロマイントラ予測モードとを単一化し得る。すなわち、各クロマブロックについて、ビデオエンコーダ２０および／またはビデオデコーダ３０は、線形モデル（ＬＭ）モードおよびクロマ成分のコード化に特有の他のモードに加え、利用可能なルーマ予測モードのプール（pool）から予測モードを選択し得る。利用可能なルーマ予測モードのプールは、本明細書では、合計「Ｎ」個の予測モードを含むと説明されており、ここで、「Ｎ」は、正の整数値を表す。いくつかの例では、「Ｎ」の値は、６７個の異なる利用可能なルーマ予測モードに対応する６７に等しい。
[0165]追加的に、ビデオエンコーダ２０はまた、最確モード（ＭＰＭ）フラグを、そしてこのＭＰＭフラグの値に依存して、クロマイントラ予測モードの符号化およびシグナリングに関する（ＭＰＭ候補リスト中のＭＰＭ候補のインデックスに対応する）ＭＰＭインデックスをシグナリングし得る。例えば、ビデオエンコーダ２０は、クロマブロックについての１つまたは複数のＤＭモードをＭＰＭ候補リストに最初に加えることで、ＭＰＭ候補リストを構築し得る。上述したように、ビデオエンコーダ２０は、クロマブロックについての複数のＤＭモードを識別し得る。しかしながら、いくつかのシナリオでは、ビデオエンコーダ２０が、クロマブロックについて単一のＤＭモードを識別し得ることは認識されるであろう。ＤＭモードをＭＰＭ候補リストに加えた後、ビデオエンコーダ２０は、隣接ブロックからの他のクロマモードをＭＰＭ候補リストに加え得る。代替的に、または加えて、ビデオエンコーダ２０は、例えば、Ｖ．Ｓｅｒｅｇｉｎ，Ｘ．Ｚｈａｏ，Ａ．Ｓａｉｄ，Ｍ．Ｋａｒｃｚｅｗｉｃｚによる「Neighbor based intra most probable modes list derivation」，ＪＶＥＴ−Ｃ００５５，ジュネーブ，２０１６年５月（以降「Ｓｅｒｅｇｉｎ」）に記載されているルーマＭＰＭ候補リスト構築プロセスを使用することで、デフォルトモードを加え得る。
[0166]代替的に、ビデオエンコーダ２０は、ルーマモードＭＰＭ候補リストの場合と同様にクロマＭＰＭ候補リストを構築し得る。例えば、ビデオエンコーダ２０は、Ｓｅｒｅｇｉｎに記載されている順序でいくつかの隣接ブロックをチェックし得る。これらのインプリメンテーションでは、ビデオエンコーダ２０は、 ＬＭモードおよび／または他のクロマ固有のイントラ予測モードを、ビデオエンコーダ２０が他のイントラ予測モードを処理するのと同様に処理し得る。さらに、ビデオエンコーダ２０は、同一のイントラ予測モードが複数のソースから加えられることから生じる冗長性を取り除くためにＭＰＭ候補リストをプルーニングし得る。
[0167]一例では、ビデオエンコーダ２０は、ＬＭモードおよび／またはクロマ成分のコード化にのみ使用される他の予測モードのような、クロマ成分にのみ適用される１つまたは複数のクロマ固有のモードの使用量（usage）を示すためにフラグを最初にシグナリングし得る。選択された予測モードがクロマ固有のモードでない（すなわち、ビデオエンコーダ２０が、上述したフラグを無効状態に設定する）場合、ビデオエンコーダ２０は、ＭＰＭフラグをさらにシグナリグし得る。この例となるインプリメンテーションでは、隣接ブロックから継承されたクロマ予測モードをＭＰＭリストに加えるとき、ビデオエンコーダ２０は、クロマ固有のモード（例えば、ＬＭモード）が隣接ブロックから得られる場合、そのようなクロマ固有のモードを考慮しないであろう。
[0168]このインプリメンテーションの例となる使用事例が以下に説明される。ビデオエンコーダ２０は、ＬＭモードを使用してクロマブロックをイントラ予測し得、そのため、有効状態に設定されたＬＭフラグをシグナリングし得る。クロマブロックがＬＭ予測モードを使用して符号化されていることに基づいて、ビデオエンコーダ２０は、クロマブロックについてのＭＰＭ候補リスト内の位置を示すＭＰＭインデックスをシグナリングし得る。この例となる使用事例は、クロマブロックについての予測モードがＭＰＭ候補リスト中の候補であるか全く候補でないかを示すインジケーションをビデオデコーダ３０に最初に提供するためにビデオエンコーダ２０が１ビットフラグを使用し得ることを例示する。クロマブロックに対して使用される予測モードがＭＰＭ候補リストからの候補である場合かつその場合に限り、ビデオエンコーダ２０は、クロマブロックを予測するためにＭＰＭ候補リストのどのモードが使用されるかをビデオデコーダ３０に示すためにインデックスをシグナリングし得る。このように、ビデオエンコーダ２０は、最初に１ビットフラグを使用し、その後このフラグの値に基づいて、インデックス値をシグナリングするか全くしないかを決定することで帯域幅を節約し得る。
[0169]上述した技法のデコーダ側の態様が後述される。ビデオデコーダ３０は、符号化済みビデオビットストリームにおいてＭＰＭフラグを受信し得る。ＭＰＭフラグの値が有効状態に設定されている場合、ビデオデコーダ３０もまた、適切なクロマブロックに関して、ＭＰＭ候補リスト中の特定のＭＰＭ候補のインデックスに対応するＭＰＭインデックスを受信し得る。例えば、ビデオデコーダ３０は、クロマブロックについての１つまたは複数のＤＭモードをＭＰＭ候補リストに最初に加えることで、ＭＰＭ候補リストを構築し得る。上述したように、ビデオデコーダ３０は、クロマブロックの再構築について複数のＤＭモードを識別し得る。しかしながら、いくつかのシナリオでは、ビデオデコーダ３０が、クロマブロックについて単一のＤＭモードを識別し得ることは認識されるであろう。ＤＭモードをＭＰＭ候補リストに加えた後、ビデオデコーダ３０は、隣接ブロックからの他のクロマモードをＭＰＭ候補リストに加え得る。代替的に、または加えて、ビデオデコーダ３０は、例えば、Ｓｅｒｅｇｉｎに記載されているルーマＭＰＭ候補リスト構築プロセスを使用することで、デフォルトモードを加え得る。
[0170]代替的に、ビデオデコーダ３０は、ルーマモードＭＰＭ候補リストに関する方法と同じ方法でクロマＭＰＭ候補リストを構築し得る。例えば、ビデオデコーダ３０は、Ｓｅｒｅｇｉｎに記載されている順序でいくつかの隣接ブロックをチェックし得る。これらのインプリメンテーションでは、ビデオデコーダ３０は、ＬＭモードおよび／または他のクロマ固有のイントラ予測モードを、ビデオデコーダ３０が他のイントラ予測モードを処理するのと同様に処理し得る。さらに、ビデオデコーダ３０は、同一のイントラ予測モードが複数のソースから加えられることから生じる冗長性を取り除くためにＭＰＭ候補リストをプルーニングし得る。
[0171]一例では、ビデオエンコーダ２０は、ＬＭモードおよび／またはクロマ成分のコード化にのみ使用される他の予測モードのような、クロマ成分にのみ適用される１つまたは複数のクロマ固有のモードの使用量を示すためにフラグを最初にシグナリングし得る。選択された予測モードがクロマ固有のモードでない（すなわち、上述したフラグが無効状態に設定されているとビデオデコーダ３０が決定する）場合、ビデオデコーダ３０は、ＭＰＭフラグをさらに受信し得る。この例となるインプリメンテーションでは、隣接ブロックから継承されるクロマ予測モードをＭＰＭリストに加えるとき、ビデオデコーダ３０は、クロマ固有のモード（例えば、ＬＭモード）が隣接ブロックから得られる場合、そのようなクロマ固有のモードを考慮しないであろう。
[0172]このインプリメンテーションの例となる使用事例が以下に説明される。ビデオデコーダ３０は、有効状態に設定されているＬＭフラグを受信し得、したがって、ＬＭモードイントラ予測を使用してクロマブロックを再構築し得る。クロマブロックがＬＭ予測モードを使用して符号化されていることに基づいて、ビデオデコーダ３０は、クロマブロックについてＭＰＭ候補リスト内の位置を示すＭＰＭインデックスを受信し得る。この例となる使用事例は、クロマブロックについての予測モードがＭＰＭ候補リスト中の候補であるか全く候補でないかを最初に決定するためにビデオデコーダ３０が１ビットフラグを使用し得ることを例示する。予測モードが、ＭＰＭ候補リストからの候補でない場合、ビデオデコーダ３０は、クロマブロックを予測するためにＭＰＭ候補リストのどのモードが使用されるかを示すインデックスをビデオエンコーダ２０がシグナリングする必要性を除去する。このように、ビデオデコーダ３０は、ビデオエンコーダ２０がインデックス値をシグナリングすることを必要とされるインスタンスの数を低減することで帯域幅を節約し得、これは、１ビットフラグをシグナリングするより帯域幅集約型であり得る。
[0173]いくつかの例では、ＬＭモードに加えて、ビデオエンコーダ２０および／またはビデオデコーダ３０は、他のクロマ特有のまたはクロマ固有のイントラ予測モードをＭＰＭリストに加え得、残りのイントラ予測モードをリストのデフォルトモードとして加え得る。代替的に、ビデオエンコーダ２０は、ＭＰＭフラグを最初にシグナリングし得、ＭＰＭリストを構築する際に、ビデオエンコーダ２０および／またはビデオデコーダ３０は、隣接ブロックがＬＭモードを使用して予測されるか否かにかかわらず、隣接ブロックのクロマ予測モードを常に考慮し得る。別の例では、ＬＭモードがＭＰＭリストに加えられないる場合、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＬＭモードを第１のデフォルトモードとして加え得る。別の例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＭＰＭ候補リストからのＬＭおよびモードだけを使用し得、デフォルトモードを完全に取り除き得る。いくつかの例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、加えられるデフォルトモードの総数が「Ｋ」で表される所定の整数値より少ない場合にのみ、既存のデフォルトモードを加え得る。１つのそのような例では、Ｋは、４の値に設定される。
[0174]いくつかの例では、１つのＤＭのみ許容されるとき、対応するルーマブロックを有する左上コーナーからルーマイントラ予測モードを得る代わりに、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ルーマイントラ予測モードをＤＭモードとして選択するために、以下のルールのうちの１つまたは複数を使用し得る。そのようなルールの一例では、ルーマイントラ予測モードは、対応するルーマブロック内で最も頻繁に使用されるモードである。一例では、特定の走査順序に基づいて、ビデオエンコーダ２０および／またはビデオデコーダ３０は、対応するルーマブロック内の各単位のイントラ予測モードをトラバースし、既存のルーマ予測モードの出現数を記録し得る。ビデオエンコーダ２０および／またはビデオデコーダ３０は、最大の出現数を有するモードを選択し得る。すなわち、ビデオエンコーダ２０および／またはビデオデコーダ３０は、対応するルーマブロックのサイズ（すなわち、エリア）の大部分をカバーするルーマイントラ予測モードを選択し得る。２つの予測モードが、対応するルーマブロックにおいて同じ量の使用量を有するとき、ビデオエンコーダ２０および／またはビデオデコーダ３０は、走査順序に基づいて、最初に検出される予測モードを選択し得る。ここで、単位は、ルーマ／クロマイントラ予測についての最小ＰＵ／ＴＵサイズとして定義される。いくつかの例では、走査順序は、ラスタ／ジグザグ／対角／ジグザグ走査順序またはコード化順序であり得る。
[0175]代替的に、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ルーマブロックの中央位置から走査を開始し、特定の順序で境界へとトラバースし得る。代替的に、または加えて、走査／単位は、ＰＵ／ＴＵサイズに依存し得る。代替的に、特定の走査順序に基づいて、ビデオエンコーダ２０および／またはビデオデコーダ３０は、対応するルーマブロック内の各ＰＵ／ＴＵ／ＣＵのイントラ予測モードをトラバースし、既存のルーマ予測モードの出現数を記録し得る。ビデオエンコーダ２０および／またはビデオデコーダ３０は、最大の出現数を有するモードを選択し得る。２つのモードが、ルーマブロックにおいて同じ量の使用量を有するとき、ビデオエンコーダ２０および／またはビデオデコーダ３０は、走査順序に基づいて最初に現れる（すなわち、最初に検出される）予測モードを選択し得る。いくつかの例では、走査順序は、ラスタ／ジグザグ／対角／ジグザグ走査順序またはコード化順序であり得る。代替的に、走査は、ＰＵ／ＴＵサイズに依存し得る。
[0176]別の代替例では、単一の許容されるＤＭモードに関して上で説明した例について、２つ以上のモードが、対応するルーマブロックにおいて等しい数の出現数を有するとビデオエンコーダ２０および／またはビデオデコーダ３０が決定する場合、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ルーマブロックにおいて等しい数の出現を有するモードのうちの１つを選択し得る。選択は、ＰＵ／ＴＵサイズのおよび／またはこれらの複数のルーマモードのモードインデックスに依存し得る。代替的に、３２×３２より大きいブロックサイズのような特定のブロックサイズについて、ビデオエンコーダ２０および／またはビデオデコーダ３０は、この単一ＤＭベースのルールにしたがって、対応するルーマブロックのルーマイントラ予測モードの部分（例えば、部分的なサブセット）だけを評価し得る。
[0177]単一ＤＭモードシナリオに関するそのようなルールの別の例として、ビデオエンコーダ２０および／またはビデオデコーダ３０は、対応するルーマブロックの中央位置に関連するルーマイントラ予測モードを選択し得る。一例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、４：２：０色フォーマットのための座標タプル（２ｘ＋Ｗ−１，２ｙ＋Ｈ−１）にしたがって中央位置を定義し得る。代替的に、ビデオエンコーダ２０および／またはビデオデコーダ３０は、中央位置が次のように定義されることを定義し得る：
−ＷおよびＨの両方が２に等しい場合、ビデオエンコーダ２０および／またはビデオデコーダ３０は、位置（２ｘ，２ｙ）を中央位置として使用し得る。
−上記以外の場合で、Ｈが２に等しい場合、ビデオエンコーダ２０および／またはビデオデコーダ３０は、位置（２ｘ＋（２＊Ｗ／４／２−１）＊４，２ｙ）を中央位置として使用し得る。
−上記以外の場合で、Ｗが２に等しい場合、ビデオエンコーダ２０および／またはビデオデコーダ３０は、位置（２ｘ，２ｙ＋（２＊Ｈ／４／２−１）＊４）を中央位置として使用し得る。
−上記以外の場合（例えば、ＨおよびＷの両方が４に等しくない場合）、（２ｘ＋（２＊Ｗ／４／２−１）＊４，２ｙ＋（２＊Ｈ／４／２−１）＊４）が中央位置として使用される。
[0178]本開示の技法のいくつかの例によれば、すべてのブロックに対して同じデフォルトモードを使用する代わりに、ビデオエンコーダ２０および／またはビデオデコーダ３０は、対応するルーマブロックから導出されたモードをデフォルトモードとみなし得る。一例では、デフォルトモードの総数は、対応するルーマブロックから導出されるモードをより多く含むために増やされる。別の例では、既存のデフォルトモードは、加えられたデフォルトモードの総数がＫ（１つ非限定的な例では、Ｋは４に設定される）より少ないときにのみ加えられる。
[0179]図１２Ａおよび１２Ｂは、本開示の１つまたは複数の態様に係る、クロマ予測モードの適応型順序付けのための隣接ブロックセクションを例示する。本開示の技法のいくつかの例によれば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、順序が隣接ブロックのクロマモードに依存し得るように、クロマモードの適応型順序付けを適用し得る。一例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＤＭおよび／またはＬＭモードのような特有のモードにのみ適応型順序付けを適用し得る。別の例では、隣接ブロックは、図１２Ａに描写されるように、５つの隣接ブロックである。代替的に、ビデオエンコーダ２０および／またはビデオデコーダ３０は、２つの隣接ブロック、例えば、図１２Ａに示されるようなＡ１およびＢ１または図１２Ｂに示される上（Ａ）および左（Ｌ）のブロック、だけを使用し得る。一例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、すべての利用可能な隣接するイントラコード化されたブロックがＬＭモードでコード化されるとき、ＬＭモードをＤＭモードの前に置き得る。代替的に、ビデオエンコーダ２０および／またはビデオデコーダ３０は、利用可能な隣接するイントラコード化されたブロックのうちの少なくとも１つがＬＭモードでコード化されるとき、ＬＭモードをＤＭモードの前に置き得る。
[0180]本開示のいくつかの例によれば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、エントロピーコード化の前にクロマシンタックス値を再順序付けするためにルーマ情報を使用し得る。一例では、ルーマブロックのＮＳＳＴインデックスは、クロマＮＳＳＴインデックスのコード化順序を更新するために使用され得る。このケースでは、ビデオエンコーダ２０および／またはビデオデコーダ３０は、クロマブロックのインデックスが、対応するルーマブロックのＮＳＳＴインデックスと同じであるかどうかを示すビンを最初に符号化／復号し得る。別の例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、クロマＡＭＴ（adaptive multiple transform）インデックスのコード化順序を更新するために、ルーマブロックのＡＭＴインデックスを使用し得る。このケースでは、ビデオエンコーダ２０および／またはビデオデコーダ３０は、クロマブロックのインデックスが、対応するルーマブロックのＡＭＴインデックスと同じであるかどうかを示すために、ビンを最初に符号化／復号し得る。ビデオエンコーダ２０および／またはビデオデコーダ３０は、インデックス／モードがルーマ成分とクロマ成分とで異なり得るが、方法がルーマ成分およびクロマ成分の両方に適用可能である任意の他のシンタックスに対して別の（例えば、類似した）やり方を使用し得る。
[0181]本開示のいくつかの例によれば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、導出が、対応するルーマブロックのルーマイントラ予測モードに基づくように、１つのクロマブロックに対してＬＭパラメータの複数のセットを導出し得る。一例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、最大でＫ個のセットのパラメータを導出し得、ここで、「Ｋ」は整数値を表す。一例では、「Ｋ」は、２の値に設定される。別の例では、ビデオエンコーダ２０および／またはビデオデコーダ３０は、対応するルーマブロックに位置するサンプルのイントラ予測モードに基づいて、隣接ルーマ／クロマサンプルをＫ個のセットに分類し得る。ビデオエンコーダ２０および／またはビデオデコーダ３０は、対応するルーマブロックに位置するサンプルのイントラ予測モードに基づいて、対応するルーマブロック内のルーマサンプルをＫ個のセットに分類し得る。別の例では、２つのイントラ予測モードが「離れている」と考えられるとき、例えば、モードインデクスの絶対値が閾値より大きい場合、ビデオエンコーダ２０および／またはビデオデコーダ３０は、異なるパラメータを使用するものとして、対応するサブブロックおよび隣接サンプルとをみなし得る。
[0182]本開示のいくつかの例によれば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、現在のクロマブロックを符号化／復号するために複合ＤＭモードを使用し得る。本開示の複合ＤＭモードによれば、ビデオエンコーダ２０は、２つ以上の識別されたイントラ予測モードから生成された予測ブロックの加重和を使用して予測ブロックを生成し得る。ビデオエンコーダ２０は、２つ以上のイントラ予測モードを識別し得、これらは、コロケートされているルーマブロックを符号化するために使用されるか、隣接クロマブロックを符号化するために使用されるか、対応するルーマブロックの隣接を符号化するために使用される。次いで、ビデオエンコーダは、識別されたイントラ予測モードの各々の予測ブロックを生成し得、２つ以上の生成された予測ブロックの加重和をこの複合ＤＭモードの予測ブロックとして導出し得る。
[0183]一例では、この複合ＤＭモードの予測ブロックを生成するための重みは、対応するルーマブロックに適用される各識別されたイントラ予測モードのエリアサイズに依存する。代替的に、識別された各イントラ予測モードについての予測ブロックの重みは、現在の画素の位置と、現在の識別されたイントラ予測モードが現在の画素をカバーしているかどうかとに依存し得る。別の代替例では、重みは、識別された各イントラ予測モードについて同一である。別の代替例では依然として、ビデオエンコーダ２０および／またはビデオデコーダ３０は、予め定義された重みのセットを利用し得る。さらに別の代替例では、または加えて、ビデオエンコーダ２０は、各ＣＴＵ／ＣＵ／ＰＵ／ＴＵについての重みのインデックスをシグナリングし得る。デフォルトモード（表７．１に示されるような非ＤＭおよび非ＬＭモード）をシグナリングするとき、デフォルトモードが、複合ＤＭモードを生成するために識別されている場合、ビデオエンコーダ２０は、デフォルトモードを、複合ＤＭモードを生成するために識別されない他のイントラ予測モードと置き換え得る。
[0184]図１３Ａおよび１３Ｂは、上述した複数のＤＭモード選択ベースの技法にしたがってクロマイントラ予測モードを選択するためにビデオエンコーダ２０およびビデオデコーダ３０が使用し得るブロック位置の例を例示する概念図である。クロマコード化のための複数のＤＭモードベースの選択に関する１つの例となるインプリメンテーションが以下に説明される。上で説明したように、本開示の態様にしたがって、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、ＤＭモードの選択を実行し得る。すなわち、いくつかの例では、ビデオエンコーダ２０は、ＤＭ候補リストを明示的にシグナリングし得、ビデオデコーダ３０が同じくＤＭ候補リストを作成する必要性がなくす。他の例では、ビデオエンコーダ２０は、ＤＭ候補リストから、選択された候補のインデックスだけをシグナリングし得、ビデオデコーダ３０が、ビデオデコーダ３０が同じく作成するＤＭ候補リストから候補を選択することを可能にする。
[0185]図１３Ａは、ルーマ成分（ルーマブロック２０２）のサブブロックにおいて使用される予測モードを例示する。図１３Ｂは、ＨＥＶＣ技法にしたがった、クロマブロック２０４に関するルーマモード継承を例示する。示されるように、ルーマブロック２０２の左上サブブロックからの予測モード（すなわち、モードＬ（１））は、ＨＥＶＣ技法にしたがって、クロマブロック２０４の左領域に関して継承される。図１３Ａに示されるように、中央（Ｃ０）、左上（ＴＬ）、右上（ＴＲ）、左下（ＢＬ）、および右下（ＢＲ）に位置しているサブブロックに使用されるルーマモードが、（例えば、ビデオエンコーダ２０およびオプションでビデオデコーダ３０によって）取得される。これらのモードは、頭文字語ＤＭＣ、ＤＭＴＬ、ＤＭＴＲ、ＤＭＢＬ、ＤＭＢＲで表される。いくつかの代替例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、Ｃ０選択を、位置Ｃ１および／またはＣ２および／またはＣ３において使用されたモードの選択と置き換え得る。加えて、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、ルーマブロック２０２の大部分のエリアをカバーするルーマモードを候補ＤＭモードとしてＤＭ候補リストに加え得る。ルーマブロック２０２の最大のエリアをカバーするルーマモードは、頭文字「ＤＭＭ」で表される。
[0186]ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、後述される１つまたは複数の技法を使用してＤＭ候補リストを構築し得る。ＤＭＣ、ＤＭＴＬ、ＤＭＴＲ、ＤＭＢＬ、およびＤＭＢＬを含む候補のグループからの候補の数（「Ｎ」で表される）は、所定の順序にしたがって、ＤＭ候補リストに加えられ得る。一例では、「Ｎ」は、６に設定され、順序は、次の通りであり得る：ＤＭＣ，ＤＭＭ，ＤＭＴＬ，ＤＭＴＲ，ＤＭＢＬ，ＤＭＢＲ。１つの代替例では、「Ｎ」は、５に設定され、順序は、次の通りであり得る：ＤＭＣ，ＤＭＴＬ，ＤＭＴＲ，ＤＭＢＬ，ＤＭＢＲ。候補リストを作成する際、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、各そのような候補をＤＭ候補リストに加える前に、前に加えられた候補の部分的なサブセット（例えば、真のサブセット）またはすべての候補に対して各候補をプルーニングし得る。２つの例となる順序が上述されているが、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）が、本開示の態様に係る、様々な他の順序も使用し得ることは認識されるべきである。候補リスト中のＤＭモードの総数が「Ｍ」であると仮定すると（ここで、「Ｍ」は正の整数である）、デフォルトモードの総数は、「Ｆ」で表され、ＤＭ候補リストの特定の候補は、ＤＭｉで表される。この表記法では、下付き文字「ｉ」は、０〜Ｍ−１の範囲の整数値を表す。
[0187]ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、ＤＭ候補およびデフォルトモードの間でプルーニングを使用適用し得る。すなわち、ＤＭ候補リストを作成する際、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、デフォルトモードに対してＤＭ候補をプルーニングし得る。１つの代替例では、ＤＭｉごとに、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、ＤＭｉをデフォルトモードの各々と比較し得る。任意のデフォルトモードがＤＭｉと同一であることが分かると、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、（ＤＭｉと同一であることが分かった）第１のそのようなデフォルトモードを代替モードと置き換え得る。例えば、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、プルーニングされたデフォルトモードを、（Ｋ−１−ｉ）に等しいインデックス値を有するモードと置き換え得、ここで、「Ｋ」は、対応するルーマブロックについてのルーマ予測モードの総数である。これらの動作のための例となる疑似コードは次の通りである：
for ( i = 0; i < M; i++)
{
DMIdx = DMi;
for ( j = 0; j < F; j ++) //suppose 4 default modes
{
if( DMIdx == j-th default mode )
{
j-th default mode = Mode (K-1-i)
}
}
}
[0188]例えば、デフォルトモードは、モード０（平面）モード５０（垂直方向）、モード１８（水平方向）、およびモード１（ＤＣ）であり得、ＤＭ候補リストは、｛モード０，モード６３，モード５０，モード１｝でありる。プルーニングプロセスの後、デフォルトモードは、次のセットと置き換えられる：｛モード６６，モード６４，モード１８，モード６３｝。別の代替例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、フルプルーニングを適用し得、ここで、各デフォルトモードは、すべてのＤＭモードに対してプルーニングされる。すなわち、デフォルトモードごとに、デフォルトモードは、すべてのＤＭモードと比較される。ＤＭモードのうちの１つが、現在調査されているデフォルトモードと同一であることをステップバイステップ比較が示す場合、デフォルトモードは、最後の非ＤＭモードと置き換えられる。この例についての例となる疑似コードは以下の通りである：
Bool ModeAdded [K];
memset ( ModeAdded, false, K*sizeof(Bool)); //initialized to be false
for ( i = 0; i < M; i++)
{
ModeAdded [DMi] = true; //set the flag to be true when the corresponding intra mode is added as DM
}
Set variable LastAvailModeIdx = K-1;
for ( i = 0; i < F; i ++) //loop each default mode
{
if( ModeAdded [i-th default mode] == true) //has been added to the chroma mode
//list
{
for( j= LastAvailModeIdx; j >=0; j--)
{
if( ModeAdded [j] == true) //hasn’t been added to the chroma mode list {
i-th default mode = mode j; //default mode is replaced by the last
// available mode
LastAvailModeIdx = j - 1; //update the variable to record the last
// index that may be not added
break;
}
}
}
}
[0189]ビデオエンコーダ２０は、クロマモードのシグナリングをインプリメントするために、本開示の複数のＤＭモードベースの技法の様々な態様をインプリメントし得る。ビデオエンコーダ２０は、以下の部分を含むプロセスにしたがってクロマモードを符号化し得る。１つの部分として、ビデオエンコーダ２０は、クロマ成分にのみ適用可能な予測モード（例えば、ＬＭ、これはクロマ符号化に特有である）のうちの任意のものの使用量を示すために、１ビットフラグを符号化し、シグナリングし得る。クロマブロックが、そのようなクロマ固有のモードにしたがって符号化される場合（それによって、ビデオエンコーダ２０に、フラグを有効状態に設定させる）、ビデオエンコーダ２０は、追加的に、その特有のモードについてのインデックスを符号化し、シグナリングし得る。
[0190]追加的に、ビデオエンコーダ２０は、対応するルーマブロックから導出されるモードの使用量を示すためにフラグを符号化し、シグナリングし得る。すなわち、ビデオエンコーダ２０が、対応するルーマブロックに使用される予測モードに基づいてクロマブロックを符号化するための予測モードを選択した場合、ビデオエンコーダ２０は、フラグを有効状態に設定し得る。次に、クロマブロックが、対応するルーマブロックから継承された予測モードを使用して符号化される場合、ビデオエンコーダ２０は、追加的に、対応するルーマブロックから選択されたモードについてのインデックスを符号化し、シグナリングし得る。
[0191]クロマブロックがクロマ固有の予測モードにしたがってもルーマブロック導出された予測モードにしたがっても符号化されないとビデオエンコーダ２０が決定する場合、ビデオエンコーダ２０は、残りのモードを識別する情報を符号化し、シグナリングし得る。ビデオエンコーダ２０は、異なる順序にしたがって、クロマ符号化の上にリストされた部分／オプションをインプリメントし得る。異なる順序の例は、以下の表７．３および表７．４または表８の通りである。
[0192]上で説明したように、本開示の態様は、ルーマモードとクロマモードの単一化を対象としている。ルーマモードとクロマモードの単一化の例となるインプリメンテーションが以下に説明される。最確モード（ＭＰＭ）候補の許容される総数は、以下にＮｍｐｍで表される。ビデオエンコーダ２０および／またはビデオデコーダ３０は、以下の部分を含むようにクロマイントラモードのモードリストを構築し得る：
−ＬＭモード、および
−ＭＰＭモード。
[0193]ＭＰＭモード部分は、ＤＭ候補リストとクロマモード部分とを含み得る。ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、ＤＭｃａ複数のＤＭモードを用いて上で説明したものと同じ技法を使用して、単一化された候補リストのＤＭ候補リスト部分を作成し得る。ＭＰＭモードのクロマモード部分に関して、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、現在コード化されているクロマブロックの隣接ブロックからクロマモードを導出し得る。例えば、隣接ブロックからクロマモードを導出するために、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、ルーマモードのために使用されるＭＰＭ構築プロセスを再使用し得る。上で説明したリスト構築プロセスを実行した後に、ＭＰＭ候補の総数が依然としてＮｍｐｍより小さい場合、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、上で挙げたＪＶＥＴ−Ｃ００５５のように、様々なステップをインプリメントし得る。
[0194]例えば、上に明記されたリスト構築プロセスを実行した後に、ＭＰＭ候補の総数がＮｍｐｍの値より少ない場合、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、次のモードを加え得る：左（Ｌ）、上（Ａ）、平面、ＤＣ、左下（ＢＬ）、右上（ＡＲ）、および左上（ＡＬ）モード。ＭＰＭ候補リストが依然として完結していない場合（すなわち、ＭＰＭ候補の総数がＮｍｐｍの値より少ない場合）、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、すでに含まれている角度モードに−１および＋１を加え得る。ＭＰＭリストが依然として完結しておらず、ＭＰＭ候補リストが依然として完結していない場合（すなわち、ＭＰＭ候補の総数がＮｍｐｍの値より少ない場合）、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、デフォルトモード、すなわち、垂直、水平、２、および対対角モード、を加え得る。
[0195]ビデオエンコーダ２０および／またはビデオデコーダ３０が識別し得る非ＭＰＭモードは、上で説明したＭＰＭ候補リスト構築プロセスに含まれない任意の残りのイントラ予測モードを含む。上で（例えば、ＪＶＥＴ−Ｃ００５５を参照する部分で）説明したルーマベースのＭＰＭリスト構築プロセスとの違いは、１つの候補が加えられるとき、加えられる候補がＬＭモードでないことである。代替的または加えて、平面モードおよびＤＣモードは、すべての空間隣接（spatial neighbor）の後に加えられ得る。代替的に、ビデオエンコーダ２０および／またはビデオデコーダ３０は、ＪＶＥＴ−Ｃ００５５の技法に置き換わるために１つまたは複数の他のＭＰＭリスト構築技法をインプリメントし得る。
[0196]ルーマモードとクロマモードの単一化に関して、ビデオエンコーダ２０は、本開示の様々なクロマモードシグナリング技法をインプリメントし得る。ビデオエンコーダ２０は、以下の部分を含むプロセスにしたがってクロマモードを符号化し得る。１つの部分として、ビデオエンコーダ２０は、クロマ成分にのみ適用可能な予測モード（例えば、ＬＭモード、これはクロマ符号化に特有である）のうちの任意のものの使用量を示すために、１ビットフラグを符号化し、シグナリングし得る。クロマブロックが、そのようなクロマ固有のモードにしたがって符号化される場合（それによって、ビデオエンコーダ２０に、フラグを有効状態に設定させる）、ビデオエンコーダ２０は、追加的に、その特有のモードについてのインデックスを符号化し、シグナリングし得る。
[0197]追加的に、ビデオエンコーダ２０は、ＭＰＭ候補リストに含まれるモードの使用量を示すために、フラグを符号化し、シグナリングし得る。すなわち、ビデオエンコーダ２０が、クロマブロックを符号化するための予測モードを選択し、かつ、選択された予測モードがＭＰＭ候補リストに含まれる場合、ビデオエンコーダ２０は、フラグを有効状態に設定し得る。次に、クロマブロックが、ＭＰＭ候補リストに含まれる予測モードを使用して符号化される場合、ビデオエンコーダ２０は、追加的に、ＭＰＭ候補リストにおけるこのモードの位置を示す、このモードについてのインデックスを符号化し、シグナリングし得る。
[0198]クロマブロックがクロマ固有の予測モードにしたがってもＭＰＭ候補リストに含まれる予測モードにしたがっても符号化されないとビデオエンコーダ２０が決定する場合、ビデオエンコーダ２０は、残りのモードを識別する情報を符号化し、シグナリングし得る。ビデオエンコーダ２０は、異なる順序にしたがって、クロマ符号化の上にリストされた部分／オプションをインプリメントし得る。異なる順序の例は、以下の表８．１または表9の通りである。
[0199]クロマイントラモードのモードリストが、（ルーマＭＰＭと同じように複数のＤＭモードおよび空間隣接からのモードを含む）ＬＭおよびＭＰＭ部分だけを含む場合、ビデオエンコーダ２０は、以下の表９に示されるように、さらに修正された方法でクロマモードのシグナリングをインプリメントし得る：
[0200]別の代替例では、ビデオエンコーダ２０（およびオプションで、ビデオデコーダ３０）は、常に、（平面、ＤＣ、水平、垂直モードのような）デフォルトモードをＭＰＭ候補リストに加え得る。一例では、ＭＰＭ候補リストのＮｍｐｍ個の候補が、上で説明した技法のうちの１つまたは複数を用いて最初に構築され得る。次いで、デフォルトモードのうちの不足しているモードが、最後の１つまたは複数のＭＰＭ候補に置き換わり得る。
[0201]図１４は、本開示の態様に係る、ビデオデコーダ３０の処理回路が実行し得る例となるプロセス２２０を例示するフローチャートである。プロセス２２０は、ビデオデータのルーマブロックを予測するのに利用可能な複数の導出モード（ＤＭ）がビデオデータのクロマブロックを予測するのにも利用可能であるとビデオデコーダ３０の処理回路が決定するときに開始し得、クロマブロックは、ルーマブロックに対応し得る（２２２）。ビデオデコーダ３０は、クロマブロックに関して予測モードの候補リストを作成し得、候補リストは、クロマブロックを予測するのに利用可能な複数のＤＭのうちの１つまたは複数のＤＭを含む（２２４）。いくつかの非限定的な例では、ビデオデコーダ３０の処理回路は、候補リストの１つまたは複数のＤＭの各それぞれのＤＭを示すデータを、符号化済みビデオビットストリームにおいて、受信し、候補リストを作成するために１つまたは複数のＤＭの各それぞれのＤＭを示す受信したデータを再構築し得る。他の例では、ビデオデコーダ３０の処理回路は、候補リストを構築し得る。
[0202]ビデオデコーダ３０の処理回路は、候補リストの１つまたは複数のＤＭのうちの任意のＤＭを使用してクロマブロックを復号すると決定し得る（２２６）。いくつかの非限定的な例では、ビデオデコーダ３０の処理回路は、クロマブロックがＤＭのうちの１つを使用して符号化されることを示す１ビットフラグを、符号化済みビデオビットストリームにおいて、受信し得る。候補リストの１つまたは複数のＤＭのうちの任意のＤＭを使用してクロマブロックを復号するとの決定に基づいて、ビデオデコーダ３０の処理回路は、クロマブロックを復号するために使用されるべき、候補リストの選択されたＤＭを識別するインジケーションを復号し得る（２２８）。例えば、ビデオデコーダ３０の処理回路は、候補リストにおける選択されたＤＭの位置を識別するインデックス値を示す（符号化済みビデオビットストリームにおいて受信された）データを再構築し得る。次に、ビデオデコーダ３０の処理回路は、選択されたＤＭにしたがってクロマブロックを復号し得る（２３０）。様々な例では、ルーマおよびクロマブロックを含むビデオデータは、ビデオデコーダ３０のメモリに記憶され得る。
[0203]いくつかの例では、候補リストに含まれる１つまたは複数のＤＭは、対応するルーマブロックの中央位置に関連する第１の予測モード、対応するルーマブロックの左上位置に関連する第２の予測モード、対応するルーマブロックの右上位置に関連する第３の予測モード、対応するルーマブロックの左下位置に関連する第４の予測モード、または対応するルーマブロックの右下位置に関連する第５の予測モードのうちの１つまたは複数を含み得る。いくつかの例では、候補リストは、１つまたは複数のＤＭの各々とは異なる１つまたは複数のクロマイントラ予測モードをさらに含み得る。いくつかのそのような例では、クロマイントラ予測モードの各々は、クロマブロックの隣接クロマブロックを予測するために使用されるモードに対応する。いくつかの例では、候補リストの少なくとも１つのそれぞれのクロマイントラ予測モードは、クロミナンスデータを予測するためにのみ使用されるクロマ固有の予測モードである。
[0204]図１５は、本開示の態様に係る、ビデオエンコーダ２０の処理回路が実行し得る例となるプロセス２４０を例示するフローチャートである。プロセス２４０は、ビデオデータのルーマブロックを予測するのに利用可能な複数の導出モード（ＤＭ）がビデオデータのクロマブロックの予測するのにも利用可能であるとビデオエンコーダ２０の処理回路が決定するときに開始し得、クロマブロックは、ルーマブロックに対応する（２４２）。様々な例では、ルーマおよびクロマブロックを含むビデオデータは、ビデオエンコーダ２０のメモリに記憶され得る。ビデオエンコーダ２０は、クロマブロックに関して予測モードの候補リストを作成し得、候補リストは、クロマブロックを予測するのに利用可能な複数のＤＭのうちの１つまたは複数のＤＭを含む（２４４）。
[0205]ビデオエンコーダ２０の処理回路は、候補リストの１つまたは複数のＤＭのうちの任意のＤＭを使用してクロマブロックを符号化すると決定し得る（２４６）。候補リストの１つまたは複数のＤＭのうちの任意のＤＭを使用してクロマブロックを符号化するとの決定に基づいて、ビデオエンコーダ２０の処理回路は、クロマブロックを復号するために使用されるべき、候補リストの選択されたＤＭを識別するインジケーションを符号化し得る（２４８）。例えば、ビデオエンコーダ２０の処理回路は、候補リストにおける選択されたＤＭの位置を識別するインデックス値を示すデータを符号化し、符号化済みビデオビットストリームにおいて符号化済みデータをシグナリングし得る。次に、ビデオエンコーダ２０の処理回路は、選択されたＤＭにしたがってクロマブロックを符号化し得る（２５０）。いくつかの例では、ビデオエンコーダ２０の処理回路は、クロマブロックが線形モデル（ＬＭ）モードを使用して符号化されるかどうかを示す１ビットフラグを、符号化済みビデオビットストリームにおいて、シグナリングし得る。これらの例では、ビデオエンコーダ２０の処理回路は、候補リストの１つまたは複数のＤＭの各それぞれのＤＭを示すデータを、符号化済みビデオビットストリームにおいて、シグナリングし得る。
[0206]いくつかの例では、候補リストに含まれる１つまたは複数のＤＭは、対応するルーマブロックの中央位置に関連する第１の予測モード、対応するルーマブロックの左上位置に関連する第２の予測モード、対応するルーマブロックの右上位置に関連する第３の予測モード、対応するルーマブロックの左下位置に関連する第４の予測モード、または対応するルーマブロックの右下位置に関連する第５の予測モードのうちの１つまたは複数を含み得る。いくつかの例では、候補リストは、１つまたは複数のＤＭの各々とは異なる１つまたは複数のクロマイントラ予測モードをさらに含み得る。いくつかのそのような例では、クロマイントラ予測モードの各々は、クロマブロックの隣接クロマブロックを予測するために使用されるモードに対応する。いくつかの例では、候補リストの少なくとも１つのそれぞれのクロマイントラ予測モードは、クロミナンスデータを予測するためにのみ使用されるクロマ固有の予測モードである。いくつかの例では、ビデオエンコーダ２０の処理回路は、１つまたは複数のＤＭのうちの少なくとも２つのＤＭが同一であると決定し得、少なくとも２つの同一のＤＭのうちの厳密に１つのＤＭを候補リストに含め得る。
[0207]図１６は、本開示の態様に係る、ビデオデコーダ３０の処理回路が実行し得る例となるプロセス２６０を例示するフローチャートである。プロセス２６０は、ビデオデコーダ３０の処理回路が、ビデオデコーダ３０のメモリに記憶されたビデオデータのクロマブロックについての最確モード（ＭＰＭ）候補リストを、このＭＰＭ候補リストが、クロマブロックに関連するビデオデータのルーマブロックに関連する１つまたは複数の導出モード（ＤＭ）と、ビデオデータの輝度成分を復号するために使用可能な複数のルーマ予測モードとを含むように作成するときに開始し得る（２６２）。いくつかの例では、ビデオデコーダ３０の処理回路は、１つまたは複数のＤＭをＭＰＭ候補リストに加え得、ＭＰＭ候補リスト中の１つまたは複数のＤＭのすべての位置の後に生じるＭＰＭ候補リストの位置に、クロマブロックの隣接クロマブロックから継承される１つまたは複数のクロマモードを加え得る。
[0208]いくつかの例では、ビデオデコーダ３０の処理回路は、クロマブロックの１つまたは複数の隣接クロマブロックを予測するためにＬＭモードが使用されたとの決定に応答して、ＭＰＭ候補リストからＬＭモードの任意の追加のインスタンスを省略し得る。いくつかの例では、ビデオデコーダ３０の処理回路は、クロマブロックがＬＭモードを使用して符号化されるかどうかを示す１ビットフラグを、符号化済みビデオビットストリームにおいて、受信し得る。１つのシナリオでは、ビデオデコーダ３０の処理回路は、受信した１ビットフラグが無効状態に設定されると決定し得、ＭＰＭ候補リストの特有のモードに対応するＭＰＭインデックスを受信し得、受信した１ビットフラグが無効状態に設定されていることに基づいて、受信したＭＰＭインデックスに対応する特有のモードを選択し得る。別のシナリオでは、ビデオデコーダ３０の処理回路は、受信した１ビットフラグが有効状態に設定されていると決定し得、受信した１ビットフラグが有効状態に設定されていることに基づいて、ＭＰＭ候補リストからＬＭモードを選択し得る。
[0209]いくつかの例では、ビデオデコーダ３０の処理回路は、クロマブロックに関連するデフォルトモードの数が所定の閾値を満たすかどうかを決定し得る。デフォルトモードの数が所定の閾値を満たすとの決定に基づいて、ビデオデコーダ３０の処理回路は、デフォルトモードの各デフォルトモードをＭＰＭ候補リストに加え得、ＭＰＭ候補リストからデフォルトモードのすべてを省略し得る。ビデオデコーダ３０の処理回路は、ＭＰＭ候補リストからモードを選択し得る（２６４）。次に、ビデオデコーダ３０の処理回路は、ＭＰＭ候補リストから選択されたモードにしたがってクロマブロックを復号し得る（２６６）。
[0210]いくつかの例では、ＭＰＭ候補リストを作成するために、ビデオデコーダ３０の処理回路は、１つまたは複数のＤＭをＭＰＭ候補リストに加え得、ＭＰＭ候補リスト中の１つまたは複数のＤＭのすべての位置の後に生じるＭＰＭ候補リストの位置に、クロマブロックの隣接クロマブロックから継承される１つまたは複数のクロマモードを加え得る。いくつかの例では、ＭＰＭ候補リストを作成するために、ビデオデコーダ３０の処理回路は、１つまたは複数の線形モデル（ＬＭ）モードをＭＰＭ候補リストに加え得る。１つのそのような例では、ビデオデコーダ３０の処理回路は、１つまたは複数のＬＭモードが、第１のＬＭモードの第１のインスタンスおよび第１のＬＭモードの１つまたは複数の追加のインスタンスを備えると決定し得、第１のＬＭモードがクロマブロックの１つまたは複数の隣接クロマブロックを予測するために使用されたとの決定に応答して、ＭＰＭ候補リストからＬＭモードの１つまたは複数の追加のインスタンスを省略し得る。
[0211]いくつかの例では、ビデオデコーダ３０の処理回路は、クロマブロックがＬＭモードを使用して符号化されるかどうかを示す１ビットフラグを、符号化済みビデオビットストリームにおいて、受信し得、ここにおいて、ＭＰＭ候補リストからモードを選択することは、１ビットフラグの値に基づく。いくつかのそのような例では、ビデオデコーダ３０の処理回路は、１つまたは複数のＬＭモードが複数のＬＭモードを含むと決定し得、受信した１ビットフラグが有効状態に設定されていると決定し得る。いくつかのそのような例では、ビデオデコーダ３０の処理回路は、ＭＰＭ候補リスト中の複数のＬＭモードのうちの特定のＬＭモードの位置に対応するＬＭインデックスを受信し得、受信した１ビットフラグが有効状態に設定されていることに基づいて、クロマブロックをコード化するために、受信したＬＭインデックスに対応する特定のＬＭモードを選択し得る。いくつかの例では、ＭＰＭ候補リストからモードを選択するために、ビデオデコーダ３０の処理回路は、受信した１ビットフラグが無効状態に設定されていると決定し得、ＭＰＭ候補リストの特有のモードに対応するＭＰＭインデックスを受信し得、受信した１ビットフラグが無効状態に設定されていることに基づいて、受信したＭＰＭインデックスに対応する特有のモードを選択し得る。
[0212]いくつかの例では、ビデオデコーダ３０の処理回路は、クロマブロックに関連するデフォルトモードの数が所定の閾値を満たすかどうかを決定し得る。これらの例では、ビデオデコーダ３０の処理回路は、（ｉ）デフォルトモードの数が所定の閾値を満たさないとの決定に基づいて、デフォルトモードの各デフォルトモードをＭＰＭ候補リストに加えること、または（ｉｉ）デフォルトモードの数が所定の閾値を満たすとの決定に基づいて、ＭＰＭ候補リストからのデフォルトモードのすべてを省略すること、のうちの１つを実行し得る。
[0213]図１７は、本開示の態様に係る、ビデオエンコーダ２０の処理回路が実行し得る例となるプロセス２８０を例示するフローチャートである。プロセス２８０は、ビデオエンコーダ２０の処理回路が、ビデオエンコーダ２０のメモリに記憶されたビデオデータのクロマブロックについての最確モード（ＭＰＭ）候補リストを、このＭＰＭ候補リストが、線形モデル（ＬＭ）モードと、クロマブロックに関連するビデオデータのルーマブロックに関連する１つまたは複数の導出モード（ＤＭ）と、ルーマブロックを復号するために使用可能な複数のルーマ予測モードとを含むように作成するときに開始し得る（２８２）。いくつかの例では、ビデオエンコーダ２０の処理回路は、１つまたは複数のＤＭをＭＰＭ候補リストに加え得、ＭＰＭ候補リスト中の１つまたは複数のＤＭのすべての位置の後に生じるＭＰＭ候補リストの位置に、クロマブロックの隣接クロマブロックから継承される１つまたは複数のクロマモードを加え得る。
[0214]いくつかの例では、ビデオエンコーダ２０の処理回路は、クロマブロックの１つまたは複数の隣接クロマブロックを予測するためにＬＭモードが使用されたとの決定に応答して、ＭＰＭ候補リストからＬＭモードの任意の追加のインスタンスを省略し得る。いくつかの例では、ビデオエンコーダ２０の処理回路は、クロマブロックがＬＭモードを使用して符号化されるかどうかを示す１ビットフラグを、符号化済みビデオビットストリームにおいて、シグナリングし得る。１つのシナリオでは、ビデオエンコーダ２０の処理回路は、クロマブロックがＬＭモードを使用して符号化されないとの決定に基づいて、１ビットフラグを無効状態に設定し得る。このシナリオでは、クロマブロックがＬＭモードを使用して符号化されないとの決定、および、クロマブロックがＭＰＭ候補リストの特有のモードを使用して符号化されるとの決定に基づいて、ビデオエンコーダ２０の処理回路は、ＭＰＭ候補リストの特有のモードに対応するＭＰＭインデックスを、符号化済みビデオビットストリームにおいて、シグナリングし得る。別のシナリオでは、ビデオエンコーダ２０の処理回路は、クロマブロックがＬＭモードを使用して符号化されるとの決定に基づいて、１ビットフラグを有効状態に設定し得る。
[0215]いくつかの例では、ビデオエンコーダ２０の処理回路は、クロマブロックに関連するデフォルトモードの数が所定の閾値を満たすと決定し得る。デフォルトモードの数が所定の閾値を満たすとの決定に基づいて、ビデオエンコーダ２０の処理回路は、デフォルトモードの各デフォルトモードをＭＰＭ候補リストに加え得、ＭＰＭ候補リストからデフォルトモードのすべてを省略し得る。ビデオエンコーダ２０の処理回路は、ＭＰＭ候補リストからモードを選択し得る（２８４）。次に、ビデオエンコーダ２０の処理回路は、ＭＰＭ候補リストから選択されたモードにしたがってクロマブロックを符号化し得る。
[0216]いくつかの例では、ＭＰＭ候補リストを作成するために、ビデオエンコーダ２０の処理回路は、１つまたは複数の線形モデル（ＬＭ）モードをＭＰＭ候補リストに加え得る。いくつかの例では、ビデオエンコーダ２０の処理回路は、クロマブロックがＭＰＭ候補リストの１つまたは複数のＬＭモードのうちの任意のものを使用して符号化されるかどうかを示す１ビットフラグを、符号化済みビデオビットストリームにおいて、シグナリングし得る。いくつかの例では、ビデオエンコーダ２０の処理回路は、クロマブロックが候補リストのどのＬＭモードを使用しても符号化されないとの決定に基づいて、１ビットフラグを無効状態に設定し得、クロマブロックがＭＰＭ候補リストのどのＬＭモードを使用しても符号化されないとの決定に基づいて、かつ、クロマブロックがＭＰＭ候補リストの特有のモードを使用して符号化されるとの決定に基づいて、ＭＰＭ候補リストの特有のモードに対応するＭＰＭインデックスを、符号化済みビデオビットストリームにおいて、シグナリングし得る。いくつかの例では、ビデオエンコーダ２０の処理回路は、クロマブロックがＭＰＭ候補リストの１つまたは複数のＬＭモードのうちの特定のＬＭモードを使用して符号化されるとの決定に基づいて、１ビットフラグを有効状態に設定し得る。
[0217]いくつかの例では、ビデオエンコーダ２０の処理回路は、クロマブロックに関連するデフォルトモードの数が所定の閾値を満たすかどうかを決定し得る。次に、ビデオエンコーダ２０の処理回路は、次のうちの１つを実行し得る：（ｉ）デフォルトモードの数が所定の閾値を満たさないとの決定に基づいて、デフォルトモードの各デフォルトモードをＭＰＭ候補リストに加えること、または（ｉｉ）デフォルトモードの数が所定の閾値を満たすとの決定に基づいて、ＭＰＭ候補リストからデフォルトモードのすべてを省略すること。
[0218]例によっては、本明細書で説明した技法のうちの任意のものの特定の動作（act）またはイベントが、異なる順序で実行されることができ、追加、混合、または完全に省略され得る（例えば、説明したすべての動作またはイベントが本技法の実施に必要なわけではない）ことは認識されるべきである。さらに、特定の例では、動作またはイベントは、連続というよりはむしろ、例えば、マルチスレッド処理、割込み処理、または複数のプロセッサを通して、同時に実行され得る。
[0219]１つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組合せでインプリメントされ得る。ソフトウェアでインプリメントされる場合、これらの機能は、１つまたは複数の命令またはコードとして、コンピュータ読取可能な媒体に記憶されるか、またはコンピュータ読取可能な媒体を通して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ読取可能な媒体は、例えば、通信プロトコルにしたがって、ある場所から別の場所へのコンピュータプログラムの移送を容易にする任意の媒体を含む通信媒体、またはデータ記憶媒体のような有体の媒体に対応するコンピュータ読取可能な記憶媒体を含み得る。このように、コンピュータ読取可能な媒体は一般に、（１）非一時的である有形のコンピュータ読取可能な記憶媒体または（２）信号または搬送波のような通信媒体に対応し得る。データ記憶媒体は、本開示で説明した技法のインプリメンテーションのための命令、コード、および／またはデータ構造を取り出すために、１つまたは複数のコンピュータまたは１つまたは複数のプロセッサによってアクセス可能な任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ読取可能な媒体を含み得る。
[0220]限定ではなく例として、このようなコンピュータ読取可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭもしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、フラッシュメモリ、またはデータ構造もしくは命令の形式で所望のプログラムコードを記憶もしくは搬送するために使用可能でありかつコンピュータによってアクセス可能な任意の他の媒体を備えることができる。また、任意の接続は、厳密にはコンピュータ読取可能な媒体と称される。例えば、命令が、ウェブサイト、サーバ、または他のリモートソースから、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、電波、およびマイクロ波のようなワイヤレス技術を使用して送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、電波、およびマイクロ波のようなワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ読取可能な記憶媒体およびデータ記憶媒体が、接続、搬送波、信号、または他の一時的な媒体を含むのではなく、代わりに、非一時的な有形の記憶媒体を対象としていることは理解されるべきである。本明細書で使用される場合、ディスク（disk）およびディスク（disc）は、コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピー（登録商標）ディスク、およびブルーレイディスクを含み、ここで、ディスク（disk）は、通常磁気的にデータを再生し、ディスク（disc）は、レーザーを用いて光学的にデータを再生する。上の組合せもまた、コンピュータ読取可能な媒体の範囲内に含まれるべきである。
[0221]命令は、１つまたは複数のデジタルシグナルプロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または他の同等の集積またはディスクリート論理回路のような１つまたは複数のプロセッサによって実行され得る。したがって、「プロセッサ」という用語は、本明細書で使用される場合、前述の構造または本明細書で説明された技法のインプリメンテーションに適した任意の他の構造のうちの任意のものを指し得る。加えて、いくつかの態様では、本明細書で説明した機能性は、符号化および復号のために構成された専用ハードウェアおよび／またはソフトウェアモジュール内に提供され得るか、複合コーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理要素において完全にインプリメントされることができる。
[0222]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（例えば、チップセット）を含む、幅広い種類のデバイスまたは装置においてインプリメントされ得る。様々な構成要素、モジュール、またはユニットは、本開示では、開示された技法を実行するように構成されたデバイスの機能的な態様を強調するために説明されているが、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上で説明したように、様々なユニットは、コーデックハードウェアユニットへと組み合わせられるか、適切なソフトウェアおよび／またはファームウェアと併せて、上で説明した１つまたは複数のプロセッサを含む、相互動作するハードウェアユニットの集合によって提供され得る。
[0223]様々な例が説明されている。これらの例および他の例は、以下の特許請求の範囲の範囲内である。
[0223]様々な例が説明されている。これらの例および他の例は、以下の特許請求の範囲の範囲内である。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
ビデオデータをコード化する方法であって、
前記ビデオデータのクロマブロックについての最確モード（ＭＰＭ）候補リストを、前記ＭＰＭ候補リストが、前記クロマブロックに関連する前記ビデオデータのルーマブロックに関連する１つまたは複数の導出モード（ＤＭ）と、前記ビデオデータの輝度成分をコード化するために使用可能な複数のルーマ予測モードとを含むように作成することと、
前記ＭＰＭ候補リストからモードを選択することと、
前記ＭＰＭ候補リストから選択された前記モードにしたがって前記クロマブロックをコード化することと
を備える方法。
［Ｃ２］
前記ＭＰＭ候補リストを作成することは、
前記１つまたは複数のＤＭを前記ＭＰＭ候補リストに加えることと、
前記ＭＰＭ候補リスト中の前記１つまたは複数のＤＭのすべて、の位置の後に生じる前記ＭＰＭ候補リストの位置に、前記クロマブロックの隣接クロマブロックから継承される１つまたは複数のクロマモードを加えることと
を備える、［Ｃ１］に記載の方法。
［Ｃ３］
前記ＭＰＭ候補リストを作成することは、
１つまたは複数の線形モデル（ＬＭ）モードを前記ＭＰＭ候補リストに加えることを備える、
［Ｃ１］に記載の方法。
［Ｃ４］
前記ＭＰＭ候補リストを作成することは、
前記１つまたは複数のＬＭモードが第１のＬＭモードの第１のインスタンスおよび前記第１のＬＭモードの１つまたは複数の追加のインスタンスを備えると決定することと、
前記クロマブロックの１つまたは複数の隣接クロマブロックを予測するために前記第１のＬＭモードが使用されたとの決定に応答して、前記ＭＰＭ候補リストから前記ＬＭモードの前記１つまたは複数の追加のインスタンスを省略することと
を備える、［Ｃ３］に記載の方法。
［Ｃ５］
前記クロマブロックをコード化することは、前記クロマブロックを復号することを備え、前記方法は、前記クロマブロックが前記ＬＭモードを使用して符号化されるかどうかを示す１ビットフラグを、符号化済みビデオビットストリームにおいて、受信することをさらに備え、ここにおいて、前記ＭＰＭ候補リストから前記モードを選択することは、前記１ビットフラグの値に基づく、
［Ｃ１］に記載の方法。
［Ｃ６］
前記１つまたは複数のＬＭモードが複数のＬＭモード含むと決定することと、
前記受信した１ビットフラグが有効状態に設定されていると決定することと、
前記ＭＰＭ候補リスト中の前記複数のＬＭモードのうちの特定のＬＭモードの位置に対応するＬＭインデックスを受信することと、
前記受信した１ビットフラグが前記有効状態に設定されていることに基づいて、前記クロマブロックをコード化するために、前記受信したＬＭインデックスに対応する前記特定のＬＭモードを選択することと
をさらに備える、［Ｃ５］に記載の方法。
［Ｃ７］
前記ＭＰＭ候補リストから前記モードを選択することは、
前記受信した１ビットフラグが無効状態に設定されていると決定することと、
前記ＭＰＭ候補リストの特有のモードに対応するＭＰＭインデックスを受信することと、
前記受信した１ビットフラグが前記無効状態に設定されていることに基づいて、前記受信したＭＰＭインデックスに対応する前記特有のモードを選択することと
を備える、［Ｃ５］に記載の方法。
［Ｃ８］
前記クロマブロックをコード化することは、前記クロマブロックを符号化することを備え、前記方法は、
１つまたは複数の線形モデル（ＬＭ）モードを前記ＭＰＭ候補リストに加えることと、
前記クロマブロックが前記ＭＰＭ候補リストの前記１つまたは複数のＬＭモードのうちの任意のものを使用して符号化されるかどうかを示す１ビットフラグを、符号化済みビデオビットストリームにおいて、シグナリングすることと
をさらに備える、［Ｃ１］に記載の方法。
［Ｃ９］
前記クロマブロックが前記候補リストのどのＬＭモードを使用しても符号化されないとの決定に基づいて、前記１ビットフラグを無効状態に設定することと、
前記クロマブロックが前記ＭＰＭ候補リストのどのＬＭモードを使用しても符号化されないとの前記決定に基づいて、かつ、前記クロマブロックが前記ＭＰＭ候補リストの特有のモードを使用して符号化されるとの決定に基づいて、前記ＭＰＭ候補リストの前記特有のモードに対応するＭＰＭインデックスを、前記符号化済みビデオビットストリームにおいて、シグナリングすることと
をさらに備える、［Ｃ８］に記載の方法。
［Ｃ１０］
前記クロマブロックが前記ＭＰＭ候補リストの前記１つまたは複数のＬＭモードのうちの特定のＬＭモードを使用して符号化されるとの決定に基づいて、前記１ビットフラグを有効状態に設定することをさらに備える、
［Ｃ８］に記載の方法。
［Ｃ１１］
前記クロマブロックに関連するデフォルトモードの数が所定の閾値を満たすかどうかを決定することと、
前記デフォルトモードの数が前記所定の閾値を満たさないとの決定に基づいて、前記デフォルトモードの各デフォルトモードを前記ＭＰＭ候補リストに加えること、または
前記デフォルトモードの数が前記所定の閾値を満たすとの決定に基づいて、前記ＭＰＭ候補リストから前記デフォルトモードのすべてを省略すること
のうちの１つを実行することと
をさらに備える、［Ｃ１］に記載の方法。
［Ｃ１２］
デバイスであって、
ビデオデータを記憶するように構成されたメモリと、
前記メモリと通信する処理回路と
を備え、前記処理回路は、
前記メモリデバイスに記憶された前記ビデオデータのクロマブロックについての最確モード（ＭＰＭ）候補リストを、前記ＭＰＭ候補リストが、前記クロマブロックに関連する前記ビデオデータのルーマブロックに関連する１つまたは複数の導出モード（ＤＭ）と、前記ビデオデータの輝度成分をコード化するために使用可能な複数のルーマ予測モードとを含むように作成することと、
前記ＭＰＭ候補リストからモードを選択することと、
前記ＭＰＭ候補リストから選択された前記モードにしたがって前記クロマブロックをコード化することと
を行うように構成される、デバイス。
［Ｃ１３］
前記ＭＰＭ候補リストを作成するために、前記処理回路は、
前記１つまたは複数のＤＭを前記ＭＰＭ候補リストに加えることと、
前記ＭＰＭ候補リスト中の前記１つまたは複数のＤＭのすべて、の位置の後に生じる前記ＭＰＭ候補リストの位置に、前記クロマブロックの隣接クロマブロックから継承される１つまたは複数のクロマモードを加えることと
を行うように構成される、［Ｃ１２］に記載のデバイス。
［Ｃ１４］
前記ＭＰＭ候補リストを作成するために、前記処理回路は、
１つまたは複数の線形モデル（ＬＭ）モードを前記ＭＰＭ候補リストに加える
ように構成される、［Ｃ１２］に記載のデバイス。
［Ｃ１５］
前記１つまたは複数のＬＭモードを加えるために、前記処理回路は、
前記１つまたは複数のＬＭモードが第１のＬＭモードの第１のインスタンスおよび前記第１のＬＭモードの１つまたは複数の追加のインスタンスを備えると決定することと、
前記クロマブロックの１つまたは複数の隣接クロマブロックを予測するために前記第１のＬＭモードが使用されたとの決定に応答して、前記ＭＰＭ候補リストから前記ＬＭモードの前記１つまたは複数の追加のインスタンスを省略することと
を行うように構成される、［Ｃ１４］に記載のデバイス。
［Ｃ１６］
前記クロマブロックをコード化するために、前記処理回路は、前記クロマブロックを復号するように構成され、前記処理回路は、前記クロマブロックが前記ＬＭモードを使用して符号化されるかどうかを示す１ビットフラグを、符号化済みビデオビットストリームにおいて、受信するようにさらに構成され、前記ＭＰＭ候補リストから前記モードを選択するために、前記処理回路は、前記１ビットフラグの値に基づいて前記モードを選択するように構成される、
［Ｃ１２］に記載のデバイス。
［Ｃ１７］
前記処理回路は、
前記１つまたは複数のＬＭモードが複数のＬＭモード含むと決定することと、
前記受信した１ビットフラグが有効状態に設定されていると決定することと、
前記ＭＰＭ候補リスト中の前記複数のＬＭモードのうちの特定のＬＭモードの位置に対応するＬＭインデックスを受信することと、
前記受信した１ビットフラグが前記有効状態に設定されていることに基づいて、前記クロマブロックをコード化するために、前記受信したＬＭインデックスに対応する前記特定のＬＭモードを選択することと
を行うようにさらに構成される、［Ｃ１６］に記載のデバイス。
［Ｃ１８］
前記ＭＰＭ候補リストから前記モードを選択するために、前記処理回路は、
前記受信した１ビットフラグが無効状態に設定されていると決定することと、
前記ＭＰＭ候補リストの特有のモードに対応するＭＰＭインデックスを受信することと、
前記受信した１ビットフラグが前記無効状態に設定されていることに基づいて、前記受信したＭＰＭインデックスに対応する前記特有のモードを選択することと
を行うように構成される、［Ｃ１６］に記載のデバイス。
［Ｃ１９］
前記クロマブロックをコード化するために、前記処理回路は、前記クロマブロックを符号化するように構成され、前記処理回路は、前記クロマブロックが前記ＬＭモードを使用して符号化されるかどうかを示す１ビットフラグを、符号化済みビデオビットストリームにおいて、シグナリングするようにさらに構成される、
［Ｃ１２］に記載のデバイス。
［Ｃ２０］
前記処理回路は、
前記クロマブロックが前記ＬＭモードを使用して符号化されないとの決定に基づいて、前記１ビットフラグを無効状態に設定することと、
前記クロマブロックが前記ＬＭモードを使用して符号化されないとの前記決定に基づいて、かつ、前記クロマブロックが前記ＭＰＭ候補リストの特有のモードを使用して符号化されるとの決定に基づいて、前記ＭＰＭ候補リストの前記特有のモードに対応するＭＰＭインデックスを、前記符号化済みビデオビットストリームにおいて、シグナリングすることと
を行うようにさらに構成される、［Ｃ１９］に記載のデバイス。
［Ｃ２１］
前記処理回路は、
前記クロマブロックが前記ＬＭモードを使用して符号化されるとの決定に基づいて、前記１ビットフラグを有効状態に設定する
ようにさらに構成される、［Ｃ１９］に記載のデバイス。
［Ｃ２２］
前記処理回路は、
前記クロマブロックに関連するデフォルトモードの数が所定の閾値を満たすかどうかを決定することと、
前記デフォルトモードの数が前記所定の閾値を満たさないとの決定に基づいて、前記デフォルトモードの各デフォルトモードを前記ＭＰＭ候補リストに加えることと、
前記デフォルトモードの数が前記所定の閾値を満たすとの決定に基づいて、前記ＭＰＭ候補リストから前記デフォルトモードのすべてを省略することと
を行うようにさらに構成される、［Ｃ１２］に記載のデバイス。

Claims (22)

  1. ビデオデータをコード化する方法であって、
    前記ビデオデータのクロマブロックについての最確モード（ＭＰＭ）候補リストを、前記ＭＰＭ候補リストが、前記クロマブロックに関連する前記ビデオデータのルーマブロックに関連する１つまたは複数の導出モード（ＤＭ）と、前記ビデオデータの輝度成分をコード化するために使用可能な複数のルーマ予測モードとを含むように作成することと、
    前記ＭＰＭ候補リストからモードを選択することと、
    前記ＭＰＭ候補リストから選択された前記モードにしたがって前記クロマブロックをコード化することと
    を備える方法。
  2. 前記ＭＰＭ候補リストを作成することは、
    前記１つまたは複数のＤＭを前記ＭＰＭ候補リストに加えることと、
    前記ＭＰＭ候補リスト中の前記１つまたは複数のＤＭのすべて、の位置の後に生じる前記ＭＰＭ候補リストの位置に、前記クロマブロックの隣接クロマブロックから継承される１つまたは複数のクロマモードを加えることと
    を備える、請求項１に記載の方法。
  3. 前記ＭＰＭ候補リストを作成することは、
    １つまたは複数の線形モデル（ＬＭ）モードを前記ＭＰＭ候補リストに加えることを備える、
    請求項１に記載の方法。
  4. 前記ＭＰＭ候補リストを作成することは、
    前記１つまたは複数のＬＭモードが第１のＬＭモードの第１のインスタンスおよび前記第１のＬＭモードの１つまたは複数の追加のインスタンスを備えると決定することと、
    前記クロマブロックの１つまたは複数の隣接クロマブロックを予測するために前記第１のＬＭモードが使用されたとの決定に応答して、前記ＭＰＭ候補リストから前記ＬＭモードの前記１つまたは複数の追加のインスタンスを省略することと
    を備える、請求項３に記載の方法。
  5. 前記クロマブロックをコード化することは、前記クロマブロックを復号することを備え、前記方法は、前記クロマブロックが前記ＬＭモードを使用して符号化されるかどうかを示す１ビットフラグを、符号化済みビデオビットストリームにおいて、受信することをさらに備え、ここにおいて、前記ＭＰＭ候補リストから前記モードを選択することは、前記１ビットフラグの値に基づく、
    請求項１に記載の方法。
  6. 前記１つまたは複数のＬＭモードが複数のＬＭモード含むと決定することと、
    前記受信した１ビットフラグが有効状態に設定されていると決定することと、
    前記ＭＰＭ候補リスト中の前記複数のＬＭモードのうちの特定のＬＭモードの位置に対応するＬＭインデックスを受信することと、
    前記受信した１ビットフラグが前記有効状態に設定されていることに基づいて、前記クロマブロックをコード化するために、前記受信したＬＭインデックスに対応する前記特定のＬＭモードを選択することと
    をさらに備える、請求項５に記載の方法。
  7. 前記ＭＰＭ候補リストから前記モードを選択することは、
    前記受信した１ビットフラグが無効状態に設定されていると決定することと、
    前記ＭＰＭ候補リストの特有のモードに対応するＭＰＭインデックスを受信することと、
    前記受信した１ビットフラグが前記無効状態に設定されていることに基づいて、前記受信したＭＰＭインデックスに対応する前記特有のモードを選択することと
    を備える、請求項５に記載の方法。
  8. 前記クロマブロックをコード化することは、前記クロマブロックを符号化することを備え、前記方法は、
    １つまたは複数の線形モデル（ＬＭ）モードを前記ＭＰＭ候補リストに加えることと、
    前記クロマブロックが前記ＭＰＭ候補リストの前記１つまたは複数のＬＭモードのうちの任意のものを使用して符号化されるかどうかを示す１ビットフラグを、符号化済みビデオビットストリームにおいて、シグナリングすることと
    をさらに備える、請求項１に記載の方法。
  9. 前記クロマブロックが前記候補リストのどのＬＭモードを使用しても符号化されないとの決定に基づいて、前記１ビットフラグを無効状態に設定することと、
    前記クロマブロックが前記ＭＰＭ候補リストのどのＬＭモードを使用しても符号化されないとの前記決定に基づいて、かつ、前記クロマブロックが前記ＭＰＭ候補リストの特有のモードを使用して符号化されるとの決定に基づいて、前記ＭＰＭ候補リストの前記特有のモードに対応するＭＰＭインデックスを、前記符号化済みビデオビットストリームにおいて、シグナリングすることと
    をさらに備える、請求項８に記載の方法。
  10. 前記クロマブロックが前記ＭＰＭ候補リストの前記１つまたは複数のＬＭモードのうちの特定のＬＭモードを使用して符号化されるとの決定に基づいて、前記１ビットフラグを有効状態に設定することをさらに備える、
    請求項８に記載の方法。
  11. 前記クロマブロックに関連するデフォルトモードの数が所定の閾値を満たすかどうかを決定することと、
    前記デフォルトモードの数が前記所定の閾値を満たさないとの決定に基づいて、前記デフォルトモードの各デフォルトモードを前記ＭＰＭ候補リストに加えること、または
    前記デフォルトモードの数が前記所定の閾値を満たすとの決定に基づいて、前記ＭＰＭ候補リストから前記デフォルトモードのすべてを省略すること
    のうちの１つを実行することと
    をさらに備える、請求項１に記載の方法。
  12. デバイスであって、
    ビデオデータを記憶するように構成されたメモリと、
    前記メモリと通信する処理回路と
    を備え、前記処理回路は、
    前記メモリデバイスに記憶された前記ビデオデータのクロマブロックについての最確モード（ＭＰＭ）候補リストを、前記ＭＰＭ候補リストが、前記クロマブロックに関連する前記ビデオデータのルーマブロックに関連する１つまたは複数の導出モード（ＤＭ）と、前記ビデオデータの輝度成分をコード化するために使用可能な複数のルーマ予測モードとを含むように作成することと、
    前記ＭＰＭ候補リストからモードを選択することと、
    前記ＭＰＭ候補リストから選択された前記モードにしたがって前記クロマブロックをコード化することと
    を行うように構成される、デバイス。
  13. 前記ＭＰＭ候補リストを作成するために、前記処理回路は、
    前記１つまたは複数のＤＭを前記ＭＰＭ候補リストに加えることと、
    前記ＭＰＭ候補リスト中の前記１つまたは複数のＤＭのすべて、の位置の後に生じる前記ＭＰＭ候補リストの位置に、前記クロマブロックの隣接クロマブロックから継承される１つまたは複数のクロマモードを加えることと
    を行うように構成される、請求項１２に記載のデバイス。
  14. 前記ＭＰＭ候補リストを作成するために、前記処理回路は、
    １つまたは複数の線形モデル（ＬＭ）モードを前記ＭＰＭ候補リストに加える
    ように構成される、請求項１２に記載のデバイス。
  15. 前記１つまたは複数のＬＭモードを加えるために、前記処理回路は、
    前記１つまたは複数のＬＭモードが第１のＬＭモードの第１のインスタンスおよび前記第１のＬＭモードの１つまたは複数の追加のインスタンスを備えると決定することと、
    前記クロマブロックの１つまたは複数の隣接クロマブロックを予測するために前記第１のＬＭモードが使用されたとの決定に応答して、前記ＭＰＭ候補リストから前記ＬＭモードの前記１つまたは複数の追加のインスタンスを省略することと
    を行うように構成される、請求項１４に記載のデバイス。
  16. 前記クロマブロックをコード化するために、前記処理回路は、前記クロマブロックを復号するように構成され、前記処理回路は、前記クロマブロックが前記ＬＭモードを使用して符号化されるかどうかを示す１ビットフラグを、符号化済みビデオビットストリームにおいて、受信するようにさらに構成され、前記ＭＰＭ候補リストから前記モードを選択するために、前記処理回路は、前記１ビットフラグの値に基づいて前記モードを選択するように構成される、
    請求項１２に記載のデバイス。
  17. 前記処理回路は、
    前記１つまたは複数のＬＭモードが複数のＬＭモード含むと決定することと、
    前記受信した１ビットフラグが有効状態に設定されていると決定することと、
    前記ＭＰＭ候補リスト中の前記複数のＬＭモードのうちの特定のＬＭモードの位置に対応するＬＭインデックスを受信することと、
    前記受信した１ビットフラグが前記有効状態に設定されていることに基づいて、前記クロマブロックをコード化するために、前記受信したＬＭインデックスに対応する前記特定のＬＭモードを選択することと
    を行うようにさらに構成される、請求項１６に記載のデバイス。
  18. 前記ＭＰＭ候補リストから前記モードを選択するために、前記処理回路は、
    前記受信した１ビットフラグが無効状態に設定されていると決定することと、
    前記ＭＰＭ候補リストの特有のモードに対応するＭＰＭインデックスを受信することと、
    前記受信した１ビットフラグが前記無効状態に設定されていることに基づいて、前記受信したＭＰＭインデックスに対応する前記特有のモードを選択することと
    を行うように構成される、請求項１６に記載のデバイス。
  19. 前記クロマブロックをコード化するために、前記処理回路は、前記クロマブロックを符号化するように構成され、前記処理回路は、前記クロマブロックが前記ＬＭモードを使用して符号化されるかどうかを示す１ビットフラグを、符号化済みビデオビットストリームにおいて、シグナリングするようにさらに構成される、
    請求項１２に記載のデバイス。
  20. 前記処理回路は、
    前記クロマブロックが前記ＬＭモードを使用して符号化されないとの決定に基づいて、前記１ビットフラグを無効状態に設定することと、
    前記クロマブロックが前記ＬＭモードを使用して符号化されないとの前記決定に基づいて、かつ、前記クロマブロックが前記ＭＰＭ候補リストの特有のモードを使用して符号化されるとの決定に基づいて、前記ＭＰＭ候補リストの前記特有のモードに対応するＭＰＭインデックスを、前記符号化済みビデオビットストリームにおいて、シグナリングすることと
    を行うようにさらに構成される、請求項１９に記載のデバイス。
  21. 前記処理回路は、
    前記クロマブロックが前記ＬＭモードを使用して符号化されるとの決定に基づいて、前記１ビットフラグを有効状態に設定する
    ようにさらに構成される、請求項１９に記載のデバイス。
  22. 前記処理回路は、
    前記クロマブロックに関連するデフォルトモードの数が所定の閾値を満たすかどうかを決定することと、
    前記デフォルトモードの数が前記所定の閾値を満たさないとの決定に基づいて、前記デフォルトモードの各デフォルトモードを前記ＭＰＭ候補リストに加えることと、
    前記デフォルトモードの数が前記所定の閾値を満たすとの決定に基づいて、前記ＭＰＭ候補リストから前記デフォルトモードのすべてを省略することと
    を行うようにさらに構成される、請求項１２に記載のデバイス。
JP2019507944A 2016-08-15 2017-08-15 分離ツリー構造を使用したイントラビデオコーディング Active JP6995839B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201662375383P 2016-08-15 2016-08-15
US62/375,383 2016-08-15
US201662404572P 2016-10-05 2016-10-05
US62/404,572 2016-10-05
US15/676,345 2017-08-14
US15/676,345 US10368107B2 (en) 2016-08-15 2017-08-14 Intra video coding using a decoupled tree structure
PCT/US2017/046962 WO2018035130A1 (en) 2016-08-15 2017-08-15 Intra video coding using a decoupled tree structure

Publications (3)

Publication Number Publication Date
JP2019525659A true JP2019525659A (ja) 2019-09-05
JP2019525659A5 JP2019525659A5 (ja) 2020-08-27
JP6995839B2 JP6995839B2 (ja) 2022-01-17

Family

ID=59714130

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019507944A Active JP6995839B2 (ja) 2016-08-15 2017-08-15 分離ツリー構造を使用したイントラビデオコーディング

Country Status (9)

Country Link
US (3) US10368107B2 (ja)
EP (1) EP3497933A1 (ja)
JP (1) JP6995839B2 (ja)
KR (1) KR102495160B1 (ja)
CN (2) CN117319647A (ja)
BR (1) BR112019002896A2 (ja)
SG (1) SG11201900111YA (ja)
TW (1) TWI761362B (ja)
WO (1) WO2018035130A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021535679A (ja) * 2018-08-27 2021-12-16 華為技術有限公司Huawei Technologies Co., Ltd. イントラ予測のための方法及び装置
JP2022520922A (ja) * 2019-01-02 2022-04-04 オッポ広東移動通信有限公司 クロマイントラ予測方法および装置、並びにコンピュータ記憶媒体
JP7410149B2 (ja) 2018-08-24 2024-01-09 中興通訊股▲ふん▼有限公司 視覚メディアエンコードおよびデコードのための平面予測モード

Families Citing this family (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10432963B2 (en) 2013-11-05 2019-10-01 Arris Enterprises Llc Bit depth variable for high precision data in weighted prediction syntax and semantics
US10715818B2 (en) 2016-08-04 2020-07-14 Intel Corporation Techniques for hardware video encoding
US10326986B2 (en) 2016-08-15 2019-06-18 Qualcomm Incorporated Intra video coding using a decoupled tree structure
US10368107B2 (en) 2016-08-15 2019-07-30 Qualcomm Incorporated Intra video coding using a decoupled tree structure
US20200045322A1 (en) * 2016-10-04 2020-02-06 Mediatek Inc. Method and apparatus for intra chroma coding in image and video coding
US10554974B2 (en) * 2017-01-13 2020-02-04 Mediatek Inc. Method and apparatus enabling adaptive multiple transform for chroma transport blocks using control flags
US10567772B2 (en) * 2017-07-11 2020-02-18 Google Llc Sub8×8 block processing
CN110999291B (zh) * 2017-08-03 2023-09-26 夏普株式会社 用于划分视频数据的帧间预测片段中的视频块的系统和方法
WO2019074985A1 (en) * 2017-10-09 2019-04-18 Arris Enterprises Llc PLANAR PLANAR WEATHER ADAPTIVE PREDICTION
EP3732883A4 (en) * 2017-12-29 2021-06-16 FG Innovation Company Limited DEVICE AND METHOD FOR CODING VIDEO DATA BASED ON A LIST OF MODES CONTAINING DIFFERENT GROUPS OF MODES
CN110113600B (zh) * 2018-02-01 2022-08-26 腾讯科技（深圳）有限公司 视频编码方法、装置、计算机可读存储介质和计算机设备
US11012715B2 (en) 2018-02-08 2021-05-18 Qualcomm Incorporated Intra block copy for video coding
US10771781B2 (en) * 2018-03-12 2020-09-08 Electronics And Telecommunications Research Institute Method and apparatus for deriving intra prediction mode
EP3799429A4 (en) * 2018-04-01 2021-07-28 Guangdong Oppo Mobile Telecommunications Corp., Ltd. METHOD AND APPARATUS FOR IMAGE CODING / DECODING USING INTRA PREDICTION
WO2019201203A1 (en) * 2018-04-16 2019-10-24 Mediatek Inc. Methods and apparatuses of video processing with overlapped block motion compensation in video coding systems
US10609402B2 (en) * 2018-05-02 2020-03-31 Tencent America LLC Method and apparatus for prediction and transform for small blocks
US10462486B1 (en) * 2018-05-07 2019-10-29 Tencent America, Llc Fast method for implementing discrete sine transform type VII (DST 7)
US10986340B2 (en) 2018-06-01 2021-04-20 Qualcomm Incorporated Coding adaptive multiple transform information for video coding
GB2588004B (en) 2018-06-05 2023-03-01 Beijing Bytedance Network Tech Co Ltd Interaction between IBC and affine
CN110636298B (zh) 2018-06-21 2022-09-13 北京字节跳动网络技术有限公司 对于Merge仿射模式和非Merge仿射模式的统一约束
CN113115046A (zh) 2018-06-21 2021-07-13 北京字节跳动网络技术有限公司 分量相关的子块分割
PT3799690T (pt) 2018-07-11 2023-12-22 Huawei Tech Co Ltd Sinalização intramodo de luma
US11509890B2 (en) * 2018-07-24 2022-11-22 Hfi Innovation Inc. Methods and apparatus for entropy coding and decoding aspects of video data
CN116347109A (zh) * 2018-08-17 2023-06-27 北京字节跳动网络技术有限公司 一种处理视频数据的方法和装置
TWI827675B (zh) 2018-09-12 2024-01-01 大陸商北京字節跳動網絡技術有限公司 交叉分量線性模型中的尺寸相關的下採樣
WO2020058893A1 (en) 2018-09-19 2020-03-26 Beijing Bytedance Network Technology Co., Ltd. History based motion vector predictor for intra block copy
CA3113370A1 (en) * 2018-09-21 2020-03-26 Huawei Technologies Co., Ltd. Intra prediction mode derivation based on neighboring blocks
WO2020065518A1 (en) 2018-09-24 2020-04-02 Beijing Bytedance Network Technology Co., Ltd. Bi-prediction with weights in video coding and decoding
JP7422757B2 (ja) * 2018-11-06 2024-01-26 北京字節跳動網絡技術有限公司 位置ベースのイントラ予測
EP3861723A4 (en) 2018-11-10 2022-04-20 Beijing Bytedance Network Technology Co., Ltd. ROUNDS IN PAIRS OF MEDIUM CANDIDATE BILLS
WO2020098803A1 (en) * 2018-11-15 2020-05-22 Beijing Bytedance Network Technology Co., Ltd. Harmonization between affine mode and other inter coding tools
WO2020108591A1 (en) 2018-12-01 2020-06-04 Beijing Bytedance Network Technology Co., Ltd. Parameter derivation for intra prediction
US11582482B2 (en) * 2018-12-05 2023-02-14 Lg Electronics Inc. Image prediction method and device for deriving chroma intra prediction mode
CN117336503A (zh) 2018-12-07 2024-01-02 北京字节跳动网络技术有限公司 基于上下文的帧内预测
US11323748B2 (en) * 2018-12-19 2022-05-03 Qualcomm Incorporated Tree-based transform unit (TU) partition for video coding
CN113287311B (zh) * 2018-12-22 2024-03-12 北京字节跳动网络技术有限公司 两步交叉分量预测模式的指示
AU2018454766A1 (en) * 2018-12-25 2021-04-08 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Decoding prediction method and apparatus, and computer storage medium
EP3881535A4 (en) * 2018-12-29 2022-03-16 Zhejiang Dahua Technology Co., Ltd. INTRA-PREDICTION SYSTEMS AND METHODS
WO2020140876A1 (en) * 2018-12-30 2020-07-09 Mediatek Inc. Method and apparatus of luma-chroma separated coding tree coding with constraints
CN113411588B (zh) * 2019-01-02 2022-11-01 Oppo广东移动通信有限公司 预测方向的确定方法、解码器以及计算机存储介质
WO2020141856A1 (ko) * 2019-01-02 2020-07-09 엘지전자 주식회사 영상 코딩 시스템에서 레지듀얼 정보를 사용하는 영상 디코딩 방법 및 그 장치
US11190568B2 (en) * 2019-01-09 2021-11-30 Bose Corporation Multimedia communication encoding system
US11095915B2 (en) * 2019-01-31 2021-08-17 Qualcomm Incorporated Shared motion vector predictor list for intra block copy mode in video coding
JP2022521698A (ja) * 2019-02-22 2022-04-12 北京字節跳動網絡技術有限公司 イントラ予測のための隣接サンプル選択
SG11202108289PA (en) 2019-02-24 2021-08-30 Beijing Bytedance Network Technology Co Ltd Parameter derivation for intra prediction
US11025913B2 (en) 2019-03-01 2021-06-01 Intel Corporation Encoding video using palette prediction and intra-block copy
CN114040205A (zh) * 2019-03-12 2022-02-11 浙江大华技术股份有限公司 帧内色度预测模式的选择方法、图像处理设备及存储设备
US11956427B2 (en) * 2019-03-21 2024-04-09 Sk Telecom Co., Ltd. Method of restoration in subblock units, and video decoding apparatus
CN117880494A (zh) 2019-03-24 2024-04-12 北京字节跳动网络技术有限公司 用于帧内预测的参数推导的条件
WO2020207493A1 (en) 2019-04-12 2020-10-15 Beijing Bytedance Network Technology Co., Ltd. Transform coding based on matrix-based intra prediction
CN113748676A (zh) 2019-04-16 2021-12-03 北京字节跳动网络技术有限公司 帧内编解码模式下的矩阵推导
CN113812150B (zh) 2019-05-01 2023-11-28 北京字节跳动网络技术有限公司 使用滤波的基于矩阵的帧内预测
CN113728647B (zh) 2019-05-01 2023-09-05 北京字节跳动网络技术有限公司 基于矩阵的帧内预测的上下文编码
US11284093B2 (en) * 2019-05-09 2022-03-22 Qualcomm Incorporated Affine linear weighted intra prediction in video coding
EP3954115A4 (en) 2019-05-22 2023-04-19 Beijing Bytedance Network Technology Co., Ltd. MATRIX-BASED INTRAPREDICTION USING UPSAMPLING
WO2020239017A1 (en) 2019-05-31 2020-12-03 Beijing Bytedance Network Technology Co., Ltd. One-step downsampling process in matrix-based intra prediction
KR20220016833A (ko) 2019-06-05 2022-02-10 베이징 바이트댄스 네트워크 테크놀로지 컴퍼니, 리미티드 행렬 기반의 인트라 예측을 위한 컨텍스트 결정
US10855983B2 (en) 2019-06-13 2020-12-01 Intel Corporation Encoding video using two-stage intra search
US11070825B2 (en) * 2019-06-13 2021-07-20 Mediatek Inc. Method and apparatus of encoding or decoding video data with adaptive colour transform
CN111699681B (zh) * 2019-06-25 2023-11-14 北京大学 一种视频图像处理方法、设备及存储介质
CN111602396B (zh) * 2019-06-25 2022-04-29 北京大学 一种视频图像处理方法、设备及存储介质
CN117579823A (zh) 2019-10-28 2024-02-20 北京字节跳动网络技术有限公司 基于颜色分量的语法信令通知和解析
CA3159796A1 (en) 2019-10-29 2021-05-06 Lg Electronics Inc. Image coding method based on transform and apparatus therefor
WO2021086050A1 (ko) * 2019-10-29 2021-05-06 엘지전자 주식회사 변환에 기반한 영상 코딩 방법 및 그 장치
US11265558B2 (en) * 2019-11-22 2022-03-01 Qualcomm Incorporated Cross-component adaptive loop filter
US11330266B2 (en) * 2020-05-18 2022-05-10 Tencent America LLC Signaling method for chroma intra prediction mode
BR112023023909A2 (pt) * 2021-06-03 2024-01-30 Qualcomm Inc Modos de intrapredição derivados e modos mais prováveis na codificação de vídeo
US20230113104A1 (en) * 2021-10-11 2023-04-13 Tencent America LLC On intra mode propagation
WO2023200155A1 (ko) * 2022-04-12 2023-10-19 엘지전자 주식회사 영상 부호화/복호화 방법, 비트스트림을 전송하는 방법 및 비트스트림을 저장한 기록 매체
WO2023234579A1 (ko) * 2022-05-30 2023-12-07 현대자동차주식회사 영상 부호화/복호화 방법, 장치 및 비트스트림을 저장한 기록 매체

Family Cites Families (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US1032698A (en) 1904-02-09 1912-07-16 Brown & Sharpe Mfg Gearing for metal-working machines.
US20060233253A1 (en) * 2005-03-10 2006-10-19 Qualcomm Incorporated Interpolated frame deblocking operation for frame rate up conversion applications
US8050331B2 (en) * 2005-05-20 2011-11-01 Ntt Docomo, Inc. Method and apparatus for noise filtering in video coding
US20070206117A1 (en) * 2005-10-17 2007-09-06 Qualcomm Incorporated Motion and apparatus for spatio-temporal deinterlacing aided by motion compensation for field-based video
US20070171987A1 (en) * 2006-01-20 2007-07-26 Nokia Corporation Method for optical flow field estimation using adaptive Filting
US8831111B2 (en) * 2006-05-19 2014-09-09 The Hong Kong University Of Science And Technology Decoding with embedded denoising
MY180607A (en) 2010-12-23 2020-12-03 Samsung Electronics Co Ltd Method and device for encoding intra prediction mode for image prediction unit, and method and device for decoding intra prediction mode for image prediction unit
BR112013014371B8 (pt) 2011-01-07 2022-05-24 Hfi Innovation Inc Método e aparelho de codificação aperfeiçoada de modo de predição intra crominância
EP3624451A1 (en) * 2011-06-17 2020-03-18 HFI Innovation Inc. Method and apparatus for coding of intra prediction mode
CN103636220B (zh) 2011-06-28 2017-10-13 寰发股份有限公司 编码/解码帧内预测模式的方法及装置
CN102857768B (zh) 2011-07-01 2014-12-10 华为技术有限公司 色度预测模式候选集的确定方法及设备
JP2013058939A (ja) 2011-09-08 2013-03-28 Sharp Corp 画像復号装置、および画像符号化装置
WO2013042884A1 (ko) * 2011-09-19 2013-03-28 엘지전자 주식회사 영상 부호화/복호화 방법 및 그 장치
FR2982446A1 (fr) * 2011-11-07 2013-05-10 France Telecom Procede de codage et decodage d'images, dispositif de codage et decodage et programmes d'ordinateur correspondants
WO2013102293A1 (en) * 2012-01-04 2013-07-11 Mediatek Singapore Pte. Ltd. Improvements of luma-based chroma intra prediction
US20130177083A1 (en) * 2012-01-05 2013-07-11 Qualcomm Incorporated Motion vector candidate index signaling in video coding
KR20130085603A (ko) 2012-01-20 2013-07-30 주식회사 팬택 색차 블록의 화면 내 예측 모드 방법 및 이러한 방법을 사용하는 장치
CN104093024B (zh) 2012-01-20 2017-08-04 华为技术有限公司 编解码方法和装置
WO2013115568A1 (ko) 2012-01-30 2013-08-08 한국전자통신연구원 인트라 예측 모드 부호화/복호화 방법 및 장치
US9131073B1 (en) * 2012-03-02 2015-09-08 Google Inc. Motion estimation aided noise reduction
AU2013250143B2 (en) 2012-04-16 2015-11-12 Electronics And Telecommunications Research Institute Encoding method and decoding method, and device using same
GB2501535A (en) * 2012-04-26 2013-10-30 Sony Corp Chrominance Processing in High Efficiency Video Codecs
EP4216547A1 (en) * 2012-06-29 2023-07-26 Electronics And Telecommunications Research Institute Method for encoding/decoding images
US20140064359A1 (en) 2012-08-31 2014-03-06 Qualcomm Incorporated Intra prediction most probable mode order improvement for scalable video coding
US9906786B2 (en) 2012-09-07 2018-02-27 Qualcomm Incorporated Weighted prediction mode for scalable video coding
US10003792B2 (en) 2013-05-27 2018-06-19 Microsoft Technology Licensing, Llc Video encoder for images
US10003805B2 (en) * 2013-07-01 2018-06-19 Samsung Electronics Co., Ltd. Video encoding and decoding method accompanied with filtering, and device thereof
US20150016516A1 (en) 2013-07-15 2015-01-15 Samsung Electronics Co., Ltd. Method for intra prediction improvements for oblique modes in video coding
JP6376130B2 (ja) * 2013-07-19 2018-08-22 日本電気株式会社 映像符号化装置、映像復号装置、映像符号化方法、映像復号方法及びプログラム
US9270999B2 (en) 2013-09-25 2016-02-23 Apple Inc. Delayed chroma processing in block processing pipelines
CN106464890A (zh) * 2014-03-14 2017-02-22 三星电子株式会社 可伸缩视频编码/解码方法和设备
US20150365703A1 (en) * 2014-06-13 2015-12-17 Atul Puri System and method for highly content adaptive quality restoration filtering for video coding
EP3158742A1 (en) * 2014-06-19 2017-04-26 VID SCALE, Inc. Systems and methods for model parameter optimization in three dimensional based color mapping
US9838662B2 (en) 2014-10-10 2017-12-05 Qualcomm Incorporated Harmonization of cross-component prediction and adaptive color transform in video coding
WO2016074147A1 (en) 2014-11-11 2016-05-19 Mediatek Singapore Pte. Ltd. Separated coding tree for luma and chroma
WO2016115736A1 (en) * 2015-01-23 2016-07-28 Mediatek Singapore Pte. Ltd. Additional intra prediction modes using cross-chroma-component prediction
KR102291835B1 (ko) * 2015-07-08 2021-08-23 인터디지털 매디슨 페턴트 홀딩스 에스에이에스 교차 평면 필터링을 이용한 향상된 크로마 코딩
US10390038B2 (en) * 2016-02-17 2019-08-20 Telefonaktiebolaget Lm Ericsson (Publ) Methods and devices for encoding and decoding video pictures using a denoised reference picture
US10390021B2 (en) * 2016-03-18 2019-08-20 Mediatek Inc. Method and apparatus of video coding
US10455228B2 (en) 2016-03-21 2019-10-22 Qualcomm Incorporated Determining prediction parameters for non-square blocks in video coding
JP2019519972A (ja) * 2016-05-05 2019-07-11 ヴィド スケール インコーポレイテッド イントラコーディングのための制御点ベースのイントラ方向表現
EP3453174A1 (en) * 2016-05-06 2019-03-13 VID SCALE, Inc. Method and system for decoder-side intra mode derivation for block-based video coding
US10368107B2 (en) 2016-08-15 2019-07-30 Qualcomm Incorporated Intra video coding using a decoupled tree structure
US10326986B2 (en) 2016-08-15 2019-06-18 Qualcomm Incorporated Intra video coding using a decoupled tree structure
US20180359486A1 (en) * 2017-06-07 2018-12-13 Mediatek Inc. Non-local adaptive loop filter processing
WO2019177331A1 (ko) * 2018-03-12 2019-09-19 삼성전자주식회사 부호화 방법 및 그 장치, 복호화 방법 및 그 장치
US20210058620A1 (en) * 2019-08-23 2021-02-25 Qualcomm Incorporated Chroma quantization parameter (qp) derivation for video coding

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"High efficiency video coding", RECOMMENDATION ITU-T H.265, vol. (04/2015), JPN6021030173, 9 July 2015 (2015-07-09), pages 119 - 120, ISSN: 0004564820 *
JIN SONG, ET AL.: "CE6.c Report on SDIP chroma extension scheme", JOINT COLLABORATIVE TEAM ON VIDEO CODING (JCT-VC) OF ITU-T SG16 WP3 AND ISO/IEC JTC1/SC29/WG11, vol. JCTVC-G267, JPN6021030175, 21 November 2011 (2011-11-21), ISSN: 0004564819 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7410149B2 (ja) 2018-08-24 2024-01-09 中興通訊股▲ふん▼有限公司 視覚メディアエンコードおよびデコードのための平面予測モード
JP2021535679A (ja) * 2018-08-27 2021-12-16 華為技術有限公司Huawei Technologies Co., Ltd. イントラ予測のための方法及び装置
JP2022520922A (ja) * 2019-01-02 2022-04-04 オッポ広東移動通信有限公司 クロマイントラ予測方法および装置、並びにコンピュータ記憶媒体
JP7309884B2 (ja) 2019-01-02 2023-07-18 オッポ広東移動通信有限公司 クロマイントラ予測方法および装置、並びにコンピュータ記憶媒体
US11924439B2 (en) 2019-01-02 2024-03-05 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Chroma intra prediction method and device

Also Published As

Publication number Publication date
US11310536B2 (en) 2022-04-19
US10368107B2 (en) 2019-07-30
WO2018035130A1 (en) 2018-02-22
SG11201900111YA (en) 2019-02-27
JP6995839B2 (ja) 2022-01-17
KR20190035739A (ko) 2019-04-03
BR112019002896A2 (pt) 2019-05-14
US20220256203A1 (en) 2022-08-11
CN109565603B (zh) 2023-10-10
KR102495160B1 (ko) 2023-02-01
CN109565603A (zh) 2019-04-02
CN117319647A (zh) 2023-12-29
TW201811055A (zh) 2018-03-16
US11743509B2 (en) 2023-08-29
EP3497933A1 (en) 2019-06-19
US20190313130A1 (en) 2019-10-10
US20180063553A1 (en) 2018-03-01
TWI761362B (zh) 2022-04-21

Similar Documents

Publication Publication Date Title
US11743509B2 (en) Intra video coding using a decoupled tree structure
US10326986B2 (en) Intra video coding using a decoupled tree structure
CN112369031B (zh) 对于视频编译码的波前处理的基于多个历史的非毗邻mvp
TWI805627B (zh) 視訊寫碼中之仿射預測
TWI776818B (zh) 用於視頻寫碼之線性模型色度內預測
JP6767508B2 (ja) ビデオコーディングのためのアフィンモーション予測
JP6543716B2 (ja) 適応型成分間残差予測
CN113196749B (zh) 用于译码视频数据的方法和设备
US20180205946A1 (en) Coding video data using derived chroma mode
CN113170180A (zh) 基于历史的运动矢量预测的简化
CN112806012A (zh) 用于帧间预测译码的基于历史的运动向量预测
KR20190044629A (ko) 비디오 코딩을 위한 트리-타입 코딩
KR20210142642A (ko) 비디오 코딩을 위한 확장된 다중 변환 선택
CN113748679A (zh) 用于视频编解码的帧内块复制合并数据语法
CN114128261A (zh) 用于视频译码的组合的帧间和帧内预测模式
KR101747058B1 (ko) 서브 pu 레벨 진보된 레지듀얼 예측
CN113383552A (zh) 用于视频译码中的帧内块复制模式的运动向量预测值列表生成
JP2021527999A (ja) シグナリングサブ予測ユニット動きベクトル予測子
JP7474774B2 (ja) ビデオコーディングにおけるイントラブロックコピーモードのための動きベクトル予測子リスト生成

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190508

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200717

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200717

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210803

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211020

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: 20211116

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20211215

R150 Certificate of patent or registration of utility model

Ref document number: 6995839

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150