特許 7379656 ビデオ信号処理方法及び装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-11-06

(45)【発行日】2023-11-14

(54)【発明の名称】ビデオ信号処理方法及び装置

(51)【国際特許分類】

   H04N 19/70 20140101AFI20231107BHJP

   H04N 19/176 20140101ALI20231107BHJP

   H04N 19/119 20140101ALI20231107BHJP

   H04N 19/136 20140101ALI20231107BHJP

【ＦＩ】

H04N19/70

H04N19/176

H04N19/119

H04N19/136

【請求項の数】 21

(21)【出願番号】P 2022503871

(86)(22)【出願日】2020-07-20

(65)【公表番号】

(43)【公表日】2022-09-27

(86)【国際出願番号】 KR2020009563

(87)【国際公開番号】W WO2021015524

(87)【国際公開日】2021-01-28

【審査請求日】2022-01-19

(31)【優先権主張番号】10-2019-0087951

(32)【優先日】2019-07-19

(33)【優先権主張国・地域又は機関】KR

(31)【優先権主張番号】10-2019-0102908

(32)【優先日】2019-08-22

(33)【優先権主張国・地域又は機関】KR

(31)【優先権主張番号】10-2019-0128764

(32)【優先日】2019-10-16

(33)【優先権主張国・地域又は機関】KR

(31)【優先権主張番号】10-2019-0171122

(32)【優先日】2019-12-19

(33)【優先権主張国・地域又は機関】KR

(73)【特許権者】

【識別番号】516079109

【氏名又は名称】ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】ゴンジュン・コ

(72)【発明者】

【氏名】ドンチョル・キム

(72)【発明者】

【氏名】ジェホン・ジュン

(72)【発明者】

【氏名】ジュヒョン・ソン

(72)【発明者】

【氏名】ジンサム・カク

【審査官】間宮 嘉誉

(56)【参考文献】

【文献】国際公開第２０１８／０８０１２２（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０１４／０１９２９０４（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１９／００７５３２８（ＵＳ，Ａ１）

【文献】BROSS, Benjamin et al.，Versatile Video Coding (Draft 6)，JVET-O2001 (version 9)，ITU，2019年07月16日，pp.1, 17-19, 21, 22, 60-63, 70, 89, 261，[online]，[retrieved on 2023-02-28]，Retrieved from the Internet: <URL: https://jvet-experts.org/doc_end_user/documents/15_Gothenburg/wg11/JVET-O2001-v9.zip>

【文献】ZHAO, Xin et al.，Non-CE6: Configurable Max Transform Size in VVC，JVET-O0545 (version 2)，ITU，2019年07月04日，pp.1-6，[online]，[retrieved on 2023-02-28]，Retrieved from the Internet: <URL: https://jvet-experts.org/doc_end_user/documents/15_Gothenburg/wg11/JVET-O0545-v2.zip>

【文献】KO, Geonjung et al.，Non-CE6: Decoding Process of Implicit TU Partitioning，JVET-P0301 (version 1)，ITU，2019年09月25日，pp.1-4，[online]，[retrieved on 2023-09-26]，Retrieved from the Internet: <URL: https://jvet-experts.org/doc_end_user/documents/16_Geneva/wg11/JVET-P0301-v1.zip>，JVET-P0301.docx

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ７／１２

Ｈ０４Ｎ １９／００－１９／９８

(57)【特許請求の範囲】

【請求項1】

ビデオ信号復号化装置であって、
プロセッサを含み、
前記プロセッサは、
現在変換ブロックの分割方向が垂直方向又は水平方向であることを示す結果値を決定し、
前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割し、
前記複数個の変換ブロックに基づき、前記現在変換ブロックを復号化し、
前記結果値は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果、及び第１値と第２値とを比較した結果に基づいて決定され、
前記第１値は、前記現在変換ブロックに関連したクロマフォーマット（ｃｈｒｏｍａ ｆｏｒｍａｔ）、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの幅に基づいて取得され、
前記第２値は、前記現在変換ブロックに関連したクロマフォーマット、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの高さに基づいて取得されることを特徴とするビデオ信号復号化装置。

【請求項2】

前記最大変換ブロック幅は、前記現在変換ブロックに関連したクロマフォーマット、前記現在変換ブロックのカラー成分及び最大変換サイズに基づいて決定されることを特徴とする、請求項１に記載のビデオ信号復号化装置。

【請求項3】

前記第１値は、前記現在変換ブロックの幅とＳｕｂＷｉｄｔｈＣとを掛けることによって取得され、
前記第２値は、前記現在変換ブロックの高さとＳｕｂＨｅｉｇｈｔＣとを掛けることによって取得され、
前記ＳｕｂＷｉｄｔｈＣ及び前記ＳｕｂＨｅｉｇｈｔＣは、各々、前記現在変換ブロックに関連したクロマフォーマットに基づいて決定される変数であることを特徴とする、請求項２に記載のビデオ信号復号化装置。

【請求項4】

前記現在変換ブロックのカラー成分がルーマ成分である場合に、前記ＳｕｂＷｉｄｔｈＣは１であり、かつ、前記ＳｕｂＨｅｉｇｈｔＣは１であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが４：２：０である場合に、前記ＳｕｂＷｉｄｔｈＣは２であり、かつ、前記ＳｕｂＨｅｉｇｈｔＣは２であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが４：２：２である場合に、前記ＳｕｂＷｉｄｔｈＣは２であり、かつ、前記ＳｕｂＨｅｉｇｈｔＣは１であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが４：４：４である場合に、前記ＳｕｂＷｉｄｔｈＣは１であり、かつ、前記ＳｕｂＨｅｉｇｈｔＣは１であることを特徴とする、請求項３に記載のビデオ信号復号化装置。

【請求項5】

前記現在変換ブロックの幅が前記最大変換ブロック幅以下であるか、又は前記第１値が前記第２値以下である場合に、前記結果値は、前記分割方向が前記水平方向であることを示す値である０と決定され、
前記現在変換ブロックの幅が前記最大変換ブロック幅より大きく、かつ、前記第１値が前記第２値より大きい場合に、前記結果値は、前記分割方向が前記垂直方向であることを示す値である１と決定されることを特徴とする、請求項４に記載のビデオ信号復号化装置。

【請求項6】

前記最大変換サイズは、前記現在変換ブロックに関連したコーディングツリーユニット（ｃｏｄｉｎｇ ｔｒｅｅ ｕｎｉｔ，ＣＴＵ）に含まれるルーマ成分を有するコーディングツリーブロック（ｃｏｄｉｎｇ ｔｒｅｅ ｂｌｏｃｋ，ＣＴＢ）のサイズに基づいて決定されることを特徴とする、請求項２に記載のビデオ信号復号化装置。

【請求項7】

前記コーディングツリーブロックのサイズが３２である場合に、前記最大変換サイズは３２であることを特徴とする、請求項６に記載のビデオ信号復号化装置。

【請求項8】

前記結果値が０と決定される場合に、
前記複数個の変換ブロックのそれぞれの幅は、前記現在変換ブロックの幅と同じ値であり、
前記複数個の変換ブロックのそれぞれの高さは、前記現在変換ブロックの高さを２で割った値であり、
前記結果値が１と決定される場合に、
前記複数個の変換ブロックのそれぞれの幅は、前記現在変換ブロックの幅を２で割った値であり、
前記複数個の変換ブロックのそれぞれの高さは、前記現在変換ブロックの高さと同じ値であることを特徴とする、請求項１に記載のビデオ信号復号化装置。

【請求項9】

ビデオ信号符号化装置であって、
プロセッサを含み、
前記プロセッサは、
符号化方法を用いてデコーダによって復号化されるビットストリーム（ｂｉｔｓｔｒｅａｍ）を取得し、
前記符号化方法は、
現在変換ブロックの分割方向が垂直方向又は水平方向であることを示す結果値を決定するステップと、
前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割するステップと、
前記複数個の変換ブロックに基づき、前記現在変換ブロックを復号化するステップと、を含み、
前記結果値は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果、及び第１値と第２値とを比較した結果に基づいて決定され、
前記第１値は、前記現在変換ブロックに関連したクロマフォーマット（ｃｈｒｏｍａ ｆｏｒｍａｔ）、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの幅に基づいて取得され、
前記第２値は、前記現在変換ブロックに関連したクロマフォーマット、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの高さに基づいて取得されることを特徴とするビデオ信号符号化装置。

【請求項10】

前記最大変換ブロック幅は、前記現在変換ブロックに関連したクロマフォーマット、前記現在変換ブロックのカラー成分及び最大変換サイズに基づいて決定されることを特徴とする、請求項９に記載のビデオ信号符号化装置。

【請求項11】

前記第１値は、前記現在変換ブロックの幅とＳｕｂＷｉｄｔｈＣとを掛けることによって取得され、
前記第２値は、前記現在変換ブロックの高さとＳｕｂＨｅｉｇｈｔＣとを掛けることによって取得され、
前記ＳｕｂＷｉｄｔｈＣ及び前記ＳｕｂＨｅｉｇｈｔＣは、各々、前記現在変換ブロックに関連したクロマフォーマットに基づいて決定される変数であることを特徴とする、請求項１０に記載のビデオ信号符号化装置。

【請求項12】

前記現在変換ブロックのカラー成分がルーマ成分である場合に、前記ＳｕｂＷｉｄｔｈＣは１であり、かつ、前記ＳｕｂＨｅｉｇｈｔＣは１であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが４：２：０である場合に、前記ＳｕｂＷｉｄｔｈＣは２であり、かつ、前記ＳｕｂＨｅｉｇｈｔＣは２であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが４：２：２である場合に、前記ＳｕｂＷｉｄｔｈＣは２であり、かつ、前記ＳｕｂＨｅｉｇｈｔＣは１であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが４：４：４である場合に、前記ＳｕｂＷｉｄｔｈＣは１であり、かつ、前記ＳｕｂＨｅｉｇｈｔＣは１であることを特徴とする、請求項１１に記載のビデオ信号符号化装置。

【請求項13】

前記現在変換ブロックの幅が前記最大変換ブロック幅以下であるか、又は前記第１値が前記第２値以下である場合に、前記結果値は、前記分割方向が前記水平方向であることを示す値である０と決定され、
前記現在変換ブロックの幅が前記最大変換ブロック幅より大きく、かつ、前記第１値が前記第２値より大きい場合に、前記結果値は、前記分割方向が前記垂直方向であることを示す値である１と決定されることを特徴とする、請求項１１に記載のビデオ信号符号化装置。

【請求項14】

前記最大変換サイズは、前記現在変換ブロックに関連したコーディングツリーユニット（ｃｏｄｉｎｇ ｔｒｅｅ ｕｎｉｔ，ＣＴＵ）に含まれるルーマ成分を有するコーディングツリーブロック（ｃｏｄｉｎｇ ｔｒｅｅ ｂｌｏｃｋ，ＣＴＢ）のサイズに基づいて決定されることを特徴とする、請求項１０に記載のビデオ信号符号化装置。

【請求項15】

前記コーディングツリーブロックのサイズが３２である場合に、前記最大変換サイズは３２であることを特徴とする、請求項１４に記載のビデオ信号符号化装置。

【請求項16】

前記結果値が０と決定される場合に、
前記複数個の変換ブロックのそれぞれの幅は、前記現在変換ブロックの幅と同じ値であり、
前記複数個の変換ブロックのそれぞれの高さは、前記現在変換ブロックの高さを２で割った値であり、
前記結果値が１と決定される場合に、
前記複数個の変換ブロックのそれぞれの幅は、前記現在変換ブロックの幅を２で割った値であり、
前記複数個の変換ブロックのそれぞれの高さは、前記現在変換ブロックの高さと同じ値であることを特徴とする、請求項１３に記載のビデオ信号符号化装置。

【請求項17】

ビットストリーム（ｂｉｔｓｔｒｅａｍ）を取得する方法であって、
前記方法は、
現在変換ブロックの分割方向が垂直方向又は水平方向であることを示す結果値を決定するステップと、
前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割するステップと、を含み、
前記結果値は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果、及び第１値と第２値とを比較した結果に基づいて決定され、
前記第１値は、前記現在変換ブロックに関連したクロマフォーマット（ｃｈｒｏｍａ ｆｏｒｍａｔ）、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの幅に基づいて取得され、
前記第２値は、前記現在変換ブロックに関連したクロマフォーマット、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの高さに基づいて取得されることを特徴とする方法。

【請求項18】

前記最大変換ブロック幅は、前記現在変換ブロックに関連したクロマフォーマット、前記現在変換ブロックのカラー成分及び最大変換サイズに基づいて決定されることを特徴とする、請求項１７に記載の方法。

【請求項19】

前記第１値は、前記現在変換ブロックの幅とＳｕｂＷｉｄｔｈＣとを掛けることによって取得され、
前記第２値は、前記現在変換ブロックの高さとＳｕｂＨｅｉｇｈｔＣとを掛けることによって取得され、
前記ＳｕｂＷｉｄｔｈＣ及び前記ＳｕｂＨｅｉｇｈｔＣは、各々、前記現在変換ブロックに関連したクロマフォーマットに基づいて決定される変数であることを特徴とする、請求項１８に記載の方法。

【請求項20】

前記現在変換ブロックのカラー成分がルーマ成分である場合に、前記ＳｕｂＷｉｄｔｈＣは１であり、かつ、前記ＳｕｂＨｅｉｇｈｔＣは１であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが４：２：０である場合に、前記ＳｕｂＷｉｄｔｈＣは２であり、かつ、前記ＳｕｂＨｅｉｇｈｔＣは２であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが４：２：２である場合に、前記ＳｕｂＷｉｄｔｈＣは２であり、かつ、前記ＳｕｂＨｅｉｇｈｔＣは１であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが４：４：４である場合に、前記ＳｕｂＷｉｄｔｈＣは１であり、かつ、前記ＳｕｂＨｅｉｇｈｔＣは１であることを特徴とする、請求項１９に記載の方法。

【請求項21】

ビデオ信号を処理するための方法であって、前記方法は、
現在変換ブロックの分割方向が垂直方向又は水平方向であることを示す結果値を決定するステップと、
前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割するステップと、
前記複数個の変換ブロックに基づき、前記現在変換ブロックを復号化するステップとを含み、
前記結果値は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果、及び第１値と第２値とを比較した結果に基づいて決定され、
前記第１値は、前記現在変換ブロックに関連したクロマフォーマット（ｃｈｒｏｍａ ｆｏｒｍａｔ）、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの幅に基づいて取得され、
前記第２値は、前記現在変換ブロックに関連したクロマフォーマット、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの高さに基づいて取得される、方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明はビデオ信号処理方法及び装置に関し、特にビデオ信号を符号化又は復号するビデオ信号処理方法及び装置に関する。

【背景技術】

【0002】

圧縮符号化とは、デジタル化した情報を通信回線を介して伝送するか、貯蔵媒体に適合した形態に貯蔵するための一連の信号処理技術を意味する。圧縮符号化の対象としては音声、映像、文字などの対象が存在するが、特に映像を対象とする圧縮符号化を行う技術をビデオ映像圧縮と称する。ビデオ信号に対する圧縮符号化は、空間的な相関関係、時間的な相関関係、確率的な相関関係などを考慮して剰余情報を除去することで行われる。しかし、最近の多様なメディア及びデータ伝送媒体の発展によって、より高効率のビデオ信号処理方法及び装置が求められている。

【発明の概要】

【発明が解決しようとする課題】

【0003】

本発明の目的は、ビデオ信号のコーディング効率を上げることにある。

【0004】

本発明の目的は、変換ユニット（ブロック）の分割を用いてビデオ信号のコーディング効率を上げることにある。

【0005】

本発明の目的は、画面内予測方法においてエンコーダが選択した予測モードを効率的に受信することにある。

【課題を解決するための手段】

【0006】

本明細書は、２次変換を用いるビデオ信号処理方法を提供する。

【0007】

具体的に、ビデオ信号復号化装置において、プロセッサを含み、前記プロセッサは、既に設定された条件に基づき、現在変換ブロック（ｔｒａｎｓｆｏｒｍ ｂｌｏｃｋ，ＴＢ）の分割方向を示す結果値を決定し、前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割し、前記複数個の変換ブロックを用いてビデオ信号を復号化するが、前記既に設定された条件は、前記現在変換ブロックのカラー成分（ｃｏｌｏｒ ｃｏｍｐｏｎｅｎｔ）に関連した条件を含むことを特徴とする。

【0008】

また、本明細書において、前記既に設定された条件は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果に関連した条件をさらに含み、前記最大変換ブロック幅は、前記現在変換ブロックに関連したクロマフォーマット（ｃｈｒｏｍａ ｆｏｒｍａｔ）、前記現在変換ブロックのカラー成分及び最大変換サイズに基づいて決定されることを特徴とする。

【0009】

また、本明細書において、前記既に設定された条件は、前記現在変換ブロックの幅に第１値を掛けた値である第１幅値と、前記現在変換ブロックの高さに第２値を掛けた値である第１高さ値とを比較した結果に関連した条件をさらに含み、前記第１値及び前記第２値はそれぞれ、現在変換ブロックの幅及び現在変換ブロックの高さに関連した値であり、前記現在変換ブロックのカラー成分が、ルーマであれば、それぞれ１に設定され、クロマてあれば、前記現在変換ブロックに関連したクロマフォーマットに基づいてそれぞれ決定されることを特徴とする。

【0010】

また、本明細書において、前記現在変換ブロックの幅が前記最大変換ブロック幅よりも大きく、前記第１幅値が前記第１高さ値よりも大きい場合に、前記結果値は、前記分割方向が垂直方向であることを示す値である１と決定され、前記複数個の変換ブロックのそれぞれの幅は、前記変換ブロックの幅を２で割った値であり、前記複数個の変換ブロックのそれぞれの高さは、前記変換ブロックの高さと同じ値であることを特徴とする。

【0011】

また、本明細書において、前記現在変換ブロックの幅が前記最大変換ブロック幅以下であるか、又は前記第１幅値が前記第１高さ値以下である場合に、前記結果値は、前記分割方向が水平方向であることを示す値である０と決定され、前記複数個の変換ブロックのそれぞれの幅は、前記変換ブロックの幅と同じ値であり、前記複数個の変換ブロックのそれぞれの高さは、前記変換ブロックの高さを２で割った値であることを特徴とする。

【0012】

また、本明細書において、前記最大変換サイズは、前記現在変換ブロックに関連したコーディングツリーユニット（ｃｏｄｉｎｇ ｔｒｅｅ ｕｎｉｔ，ＣＴＵ）に含まれるルーマ成分を有するコーディングツリーブロック（ｃｏｄｉｎｇ ｔｒｅｅ ｂｌｏｃｋ，ＣＴＢ）のサイズに基づいて決定されることを特徴とする。

【0013】

また、本明細書において、前記コーディングツリーブロックのサイズが３２である場合に、前記最大変換サイズは３２であることを特徴とする。

【0014】

また、本明細書において、前記プロセッサは、前記現在変換ブロックのカラー成分がクロマてあれば、前記現在変換ブロックに関連したコーディングブロックの予測方法がＢＤＰＣＭ（Ｂｌｏｃｋ－ｂａｓｅｄ Ｄｅｌｔａ Ｐｕｌｓｅ Ｃｏｄｅ Ｍｏｄｕｌａｔｉｏｎ）であるか否かを示すシンタックス要素をパース（ｐａｒｓｉｎｇ）し、前記パーシングの結果、前記コーディングブロックの予測方法がＢＤＰＣＭでない場合に、前記コーディングブロックの予測方法に関連したシンタックス要素をさらにパースし、前記パーシング結果に基づいて前記コーディングブロックの予測方法を決定し、前記コーディングブロックの予測方法に関連したシンタックス要素は、ＣＣＬＭ（ｃｒｏｓｓ ｃｏｍｐｏｎｅｎｔ ｌｉｎｅａｒ ｍｏｄｅｌ）、平面（ｐｌａｎａｒ）モード、ＤＣモード、垂直モード、水平モード、対角モード、及びＤＭモードの少なくともいずれか一つを示すシンタックス要素であることを特徴とする。

【0015】

また、本明細書において、ビデオ信号符号化装置において、プロセッサを含み、前記プロセッサは、既に設定された条件に基づき、現在変換ブロック（ｔｒａｎｓｆｏｒｍ ｂｌｏｃｋ，ＴＢ）の分割方向を示す結果値を決定し、前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割し、前記複数個の変換ブロックに関する情報を含むビットストリーム（ｂｉｔｓｔｒｅａｍ）を生成するが、前記既に設定された条件は、前記現在変換ブロックのカラー成分（ｃｏｌｏｒ ｃｏｍｐｏｎｅｎｔ）に関連した条件を含むことを特徴とする。

【0016】

また、本明細書において、前記既に設定された条件は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果に関連した条件をさらに含み、前記最大変換ブロック幅は、前記現在変換ブロックに関連したクロマフォーマット（ｃｈｒｏｍａ ｆｏｒｍａｔ）、前記現在変換ブロックのカラー成分及び最大変換サイズに基づいて決定されることを特徴とする。

【0017】

また、本明細書において、前記既に設定された条件は、前記現在変換ブロックの幅に第１値を掛けた値である第１幅値と、前記現在変換ブロックの高さに第２値を掛けた値である第１高さ値とを比較した結果に関連した条件をさらに含み、前記第１値及び前記第２値はそれぞれ、現在変換ブロックの幅及び現在変換ブロックの高さに関連した値であり、前記現在変換ブロックのカラー成分が、ルーマであれば、それぞれ１に設定され、クロマてあれば、前記現在変換ブロックに関連したクロマフォーマットに基づいてそれぞれ決定されることを特徴とする。

【0018】

また、本明細書において、前記現在変換ブロックの幅が前記最大変換ブロック幅よりも大きく、前記第１幅値が前記第１高さ値よりも大きい場合に、前記結果値は、前記分割方向が垂直方向であることを示す値である１と決定され、前記複数個の変換ブロックのそれぞれの幅は、前記変換ブロックの幅を２で割った値であり、前記複数個の変換ブロックのそれぞれの高さは、前記変換ブロックの高さと同じ値であることを特徴とする。

【0019】

また、本明細書において、前記変換ブロックの幅が前記最大変換ブロック幅以下であるか、又は前記第１幅値が前記第１高さ値以下である場合に、前記結果値は、前記分割方向が水平方向であることを示す値である０と決定され、前記複数個の変換ブロックのそれぞれの幅は、前記変換ブロックの幅と同じ値であり、前記複数個の変換ブロックのそれぞれの高さは、前記変換ブロックの高さを２で割った値であることを特徴とする。

【0020】

また、本明細書において、前記最大変換サイズは、前記現在変換ブロックに関連したコーディングツリーユニット（ｃｏｄｉｎｇ ｔｒｅｅ ｕｎｉｔ，ＣＴＵ）に含まれるルーマ成分を有するコーディングツリーブロック（ｃｏｄｉｎｇ ｔｒｅｅ ｂｌｏｃｋ，ＣＴＢ）のサイズに基づいて決定されることを特徴とする。

【0021】

また、本明細書において、前記コーディングツリーブロックのサイズが３２である場合に、前記最大変換サイズは３２であることを特徴とする。

【0022】

また、本明細書において、前記プロセッサは、前記現在変換ブロックのカラー成分がクロマてあれば、前記現在変換ブロックに関連したコーディングブロックの予測方法がＢＤＰＣＭ（Ｂｌｏｃｋ－ｂａｓｅｄ Ｄｅｌｔａ Ｐｕｌｓｅ Ｃｏｄｅ Ｍｏｄｕｌａｔｉｏｎ）であるか否かを示すシンタックス要素をパース（ｐａｒｓｉｎｇ）し、前記パーシングの結果、前記コーディングブロックの予測方法がＢＤＰＣＭでない場合に、前記コーディングブロックの予測方法に関連したシンタックス要素をさらにパースし、前記パーシング結果に基づいて前記コーディングブロックの予測方法を決定し、前記コーディングブロックの予測方法に関連したシンタックス要素は、ＣＣＬＭ（ｃｒｏｓｓ ｃｏｍｐｏｎｅｎｔ ｌｉｎｅａｒ ｍｏｄｅｌ）、平面（ｐｌａｎａｒ）モード、ＤＣモード、垂直モード、水平モード、対角モード、及びＤＭモードの少なくともいずれか一つを示すシンタックス要素であることを特徴とする。

【0023】

また、本明細書において、ビットストリーム（ｂｉｔｓｔｒｅａｍ）を保存する非時的な（ｎｏｎ－ｔｒａｎｓｉｔｏｒｙ）コンピュータ可読媒体（ｃｏｍｐｕｔｅｒ－ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）において、前記ビットストリームは、既に設定された条件に基づき、現在変換ブロック（ｔｒａｎｓｆｏｒｍ ｂｌｏｃｋ，ＴＢ）の分割方向を示す結果値を決定する段階；前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割する段階；前記複数個の変換ブロックに関する情報を含むビットストリームを符号化する段階；を含む符号化方法によって符号化され、前記既に設定された条件は、前記現在変換ブロックのカラー成分（ｃｏｌｏｒ ｃｏｍｐｏｎｅｎｔ）に関連した条件を含むことを特徴とする。

【0024】

また、本明細書において、前記既に設定された条件は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果に関連した条件をさらに含み、前記最大変換ブロック幅は、前記現在変換ブロックに関連したクロマフォーマット（ｃｈｒｏｍａ ｆｏｒｍａｔ）、前記現在変換ブロックのカラー成分及び最大変換サイズに基づいて決定されることを特徴とする。

【0025】

また、本明細書において、前記既に設定された条件は、前記現在ブロックの幅に第１値を掛けた値である第１幅値と、前記現在変換ブロックの高さに第２値を掛けた値である第１高さ値とを比較した結果に関連した条件をさらに含み、前記第１値及び前記第２値はそれぞれ、現在変換ブロックの幅及び現在変換ブロックの高さに関連した値であり、前記現在変換ブロックのカラー成分が、ルーマであれば、それぞれ１に設定され、クロマてあれば、前記現在変換ブロックに関連したクロマフォーマットに基づいてそれぞれ決定されることを特徴とする。

【0026】

また、本明細書において、前記最大変換サイズは、前記現在変換ブロックに関連したコーディングツリーユニット（ｃｏｄｉｎｇ ｔｒｅｅ ｕｎｉｔ，ＣＴＵ）に含まれるルーマ成分を有するコーディングツリーブロック（ｃｏｄｉｎｇ ｔｒｅｅ ｂｌｏｃｋ，ＣＴＢ）のサイズに基づいて決定されることを特徴とする。

【発明の効果】

【0027】

本発明の一実施例は、変換ユニットの分割を用いるビデオ信号処理方法及びそのための装置を提供する。

【0028】

本発明の一実施例は、画面内予測方法において、エンコーダが選択した予測モードを効率的に受信するビデオ信号処理方法及びそのための装置を提供する。

【図面の簡単な説明】

【0029】

【図1】本発明の一実施例によるビデオ信号エンコーディング装置の概略的なブロック図である。

【図2】本発明の一実施例によるビデオ信号デコーディング装置の概略的なブロック図である。

【図3】ピクチャ内でコーディングツリーユニットがコーディングユニットに分割される実施例を示す図である。

【図4】クォードツリー及びマルチ－タイプツリーの分割をシグナリングする方法の一実施例を示す図である。

【図5】本発明の実施例によるイントラ予測方法をより詳しく示す図である。

【図6】本発明の実施例によるイントラ予測方法をより詳しく示す図である。

【図7】本発明の一実施例に係るインター予測方法を示す図である。

【図8】本発明の一実施例に係る、現在ブロックのモーションベクトルがシグナルされる方法を示す図である。

【図9】本発明の一実施例に係る、現在ブロックのモーションベクトル差分値がシグナルされる方法を示す図である。

【図10】本発明の一実施例に係るコーディングユニット及び変換ユニットを示す図である。

【図11】本発明の一実施例に係る変換ツリーシンタックスを示す図である。

【0030】

【図12】本発明の一実施例に係るイントラブロックにおけるデコーディングプロセスを示す図である。

【図13】本発明の一実施例に係るレジデュアル信号のデコーディングプロセスを示す図である。

【図14】本発明の一実施例に係るカラー成分の関係を示す図である。

【図15】本発明の一実施例に係るカラー成分の関係を示す図である。

【図16】本発明の一実施例に係る最大変換サイズを示す図である。

【0031】

【図17】本発明の一実施例に係る上位レベルにおけるシンタックスを示す図である。

【図18】本発明の一実施例に係る変換ツリーシンタックスを示す図である。

【図19】本発明の一実施例に係るＴＵ分割を示す図である。

【図20】本発明の一実施例に係るＴＵ分割を示す図である。

【図21】本発明の一実施例に係るデコーディングプロセスを示す図である。

【図22】本発明の一実施例に係るデコーディングプロセスを示す図である。

【図23】本発明の一実施例に係る上位レベルシンタックスを示す図である。

【図24】本発明の一実施例に係る上位レベルシンタックスを示す図である。

【図25】本発明の一実施例に係る変換ツリーシンタックスを示す図である。

【図26】本発明の一実施例に係るデコーディングプロセスを示す図である。

【図27】本発明の一実施例に係るＢＤＰＣＭ実行方法を示す図である。

【図28】本発明の一実施例に係るＢＤＰＣＭに関連したシンタックスを示す図である。

【図29】本発明の一実施例に係るＢＤＰＣＭ使用可能条件を示す図である。

【図30】本発明の一実施例に係るＣＩＩＰとイントラ予測を示す図である。

【図31】本発明の一実施例に係るマージデータシンタックスを示す図である。

【図32】本発明の一実施例に係るマージデータシンタックスを示す図である。

【図33】本発明の一実施例に係るＣＩＩＰモードの実行方法を示す図である。

【図34】本発明の一実施例に係るクロマＢＤＰＣＭシンタックス構造を示す図である。

【図35】本発明の一実施例に係るクロマＢＤＰＣＭシンタックス構造を示す図である。

【図36】本発明の一実施例に係るＢＤＰＣＭに関連した上位レベルシンタックスを示す図である。

【図37】本発明の一実施例に係るＢＤＰＣＭに関する上位レベルでシグナルされるシンタックス要素を示す図である。

【図38】本発明の一実施例に係るクロマＢＤＰＣＭに関連したシンタックスを示す図である。

【図39】本発明の実施例に係るイントラ予測に関連したシンタックスを示す図である。

【図40】本発明の実施例に係るイントラ予測（ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）に関連したシンタックスを示す図である。

【図41】本発明の一実施例に係るシーケンスパラメータセットシンタックスを示す図である。

【図42】本発明の一実施例に係るサブピクチャーに関連したシンタックス要素を示す図である。

【図43】本発明の一実施例に係る演算子を示す図である。

【図44】本発明の一実施例に係るピクチャーとサブピクチャーを示す図である。

【図45】本発明の一実施例に係るサブピクチャーに関連したシンタックス要素を示す図である。

【図46】本発明の一実施例に係る変換ブロックを分割する方法を示す図である。

【発明を実施するための形態】

【0032】

本明細書で使用される用語は本発明における機能を考慮しながらできるだけ現在広く使用されている一般的な用語を選択したが、これは当分野に携わる技術者の意図、慣例または新たな技術の出現などによって異なり得る。また、特定の場合は出願人が任意に選定した用語もあるが、この場合、該当の発明を実施する形態の部分においてその意味を記載する。よって、本明細書で使用される用語は、単なる用語の名称ではなく、その用語の有する実質的な意味と本明細書全般にわたる内容に基づいて解釈すべきであることを明らかにする。

【0033】

本明細書において、一部用語は以下のように解釈される。コーディングは、場合によってはエンコーディングまたはでコーディングに解釈される。本明細書において、ビデオ信号のエンコーディング（符号化）を行ってビデオ信号のビットストリームを生成する装置はエンコーディング装置またはエンコーダと称され、ビデオ信号ビットストリームのデコーディング（復号化）を行ってビデオ信号を復元する装置はデコーディング装置またはデコーダと称される。また、本明細書において、ビデオ信号処理装置はエンコーダ及びデコーダをいずれも含む概念の用語として使用される。情報（ｉｎｆｏｒｍａｔｉｏｎ）は値（ｖａｌｕｅｓ）、パラメータ（ｐａｒａｍｅｔｅｒ）、係数（ｃｏｅｆｆｉｃｉｅｎｔｓ）、成分（ｅｌｅｍｅｎｔｓ）などをいずれも含む用語であって、場合によっては意味が異なるように解釈されることがあるため、本発明はこれに限らない。 ‘ユニット’は、映像処理の基本単位又はピクチャの特定位置を表す意味で使われ、ルーマ（ｌｕｍａ）成分及びクロマ（ｃｈｒｏｍａ）成分のうち少なくとも一つを含むイメージ領域のことを指す。また、「ブロック」は輝度成分及び色差成分（つまり、Ｃｂ及びＣｒ）のうち特定成分を含むイメージ領域を指す。但し、実施例によって「ユニット」、「ブロック」、「パーティション」、及び「領域」などの用語は互いに混合して使用されてもよい。また、本明細書において、ユニットはコーディングユニット、予測ユニット、変換ユニットをいずれも含む概念として使用される。ピクチャはフィールドまたはフレームを指し、実施例よっては前記用語は互いに混用して使用される。

【0034】

図１は、本発明の一実施例によるビデオ信号エンコーディング装置１００の概略的なブロック図である。図１を参照すると、本明細書のエンコーディング装置１００は、変換部１１０、量子化部１１５、逆量子化部１２０、逆変換部１２５、フィルタリング部１３０、予測部１５０、及びエントロピーコーディング部１６０を含む。

【0035】

変換部１１０は、入力されたビデオ信号と予測部１５０で生成された予測信号の差であるレジデュアル信号を変換して変換系数値を獲得する。例えば、離散コサイン変換（Ｄｉｓｃｒｅｔｅ Ｃｏｓｉｎｅ Ｔｒａｎｓｆｏｒｍ、ＤＣＴ）、離散サイン変換（Ｄｉｓｃｒｅｔｅ Ｓｉｎｅ Ｔｒａｎｓｆｏｒｍ、ＤＳＴ）、またはウェーブレット変換（Ｗａｖｅｌｅｔ Ｔｒａｎｓｆｏｒｍ）などが使用される。離散コサイン変換及び離散サイン変換は、入力されたピクチャ信号をブロックの形態に分けて変換を行うようになる。変換において、変換領域内の値の分布と特性によってコーディング効率が異なり得る。量子化部１１５は、変換部１１０内で出力された変換係数の値を量子化する。

【0036】

コーディング効率を上げるために、ピクチャ信号をそのままコーディングするのではなく、予測部１５０を介して予めコーディングされた領域を利用してピクチャを予測し、予測されたピクチャに原本ピクチャと予測ピクチャの間のレジデュアル値を足して復元ピクチャを獲得する方法が使用される。エンコーダとデコーダでミスマッチが発生しないように、エンコーダで予測を行う際にはデコーダでも使用可能な情報を使用すべきである。そのために、エンコーダでは符号化した現在ブロックを更に復元する過程を行う。逆量子化部１２０では変換係数値を逆量子化し、逆変換部１２５では逆量子化された変換系数値を利用してレジデュアル値を復元する。一方、フィルタリング部１３０は、復元されたピクチャの品質改善及び符号化効率の向上のためのフィルタリング演算を行う。例えば、デブロッキングフィルタ、サンプル適応的オフセット（Ｓａｍｐｌｅ Ａｄｐａｔｉｖｅ Ｏｆｆｓｅｔ、ＳＡＯ）、及び適応的ループフィルタなどが含まれてもよい。フィルタリングを経たピクチャは、出力されるか参照ピクチャとして利用するために復号ピクチャバッファ（Ｄｅｃｏｄｅｄ Ｐｉｃｔｕｒｅ Ｂｕｆｆｅｒ、ＤＰＢ）１５６に貯蔵される。

【0037】

コーディング効率を上げるために、ピクチャ信号をそのままコードせず、予測部１５０で既にコードされた領域を用いてピクチャを予測し、予測されたピクチャに原ピクチャと予測ピクチャ間のレジデュアル値を足して復元ピクチャを取得する方法が用いられる。イントラ予測部１５２では、現在ピクチャ内で画面内予測を行い、インター予測部１５４では、復号ピクチャバッファ１５６に保存された参照ピクチャを用いて現在ピクチャを予測する。イントラ予測部１５２は、現在ピクチャ内の復元された領域から画面内予測を行い、画面内符号化情報をエントロピーコーディング部１６０に伝達する。インター予測部１５４はさらに、モーション推定部１５４ａ及びモーション補償部１５４ｂを含んで構成されてよい。モーション推定部１５４ａでは、復元された特定領域を参照して現在領域のモーションベクトル値を取得する。モーション推定部１５４ａでは、参照領域の位置情報（参照フレーム、モーションベクトルなど）などをエントロピーコーディング部１６０に伝達してビットストリームに含まれ得るようにする。モーション推定部１５４ａから伝達されたモーションベクトル値を用いて、モーション補償部１５４ｂでは画面間モーション補償を行う。

【0038】

予測部１５０は、イントラ予測部１５２とインター予測部１５４を含む。イントラ予測部１５２は現在ピクチャ内でイントラ（ｉｎｔｒａ）予測を行い、インター予測部１５４は復号ピクチャバッファ１５６に貯蔵された参照バッファを利用して現在ピクチャを予測するインター（ｉｎｔｅｒ）予測を行う。イントラ予測部１５２は、現在ピクチャ内の復元されたサンプルからイントラ予測を行い、イントラ符号化情報をエントロピーコーディング部１６０に伝達する。イントラ符号化情報は、イントラ予測モード、ＭＰＭ（Ｍｏｓｔ Ｐｒｏｂａｂｌｅ Ｍｏｄｅ）フラッグ、ＭＰＭインデックスのうち少なくとも一つを含む。 イントラ符号化情報は、参照サンプルに関する情報を含むことができる。 イントラ符号化情報は参照サンプルに関する情報を含む。インター予測部１５４は、モーション推定部１５４ａ及びモーション補償部１５４ｂを含んで構成される。モーション推定部１５４ａは、復元された参照信号ピクチャの特定領域を参照して現在領域のモーションベクトル値を獲得する。モーション推定部１５４ａは、参照領域に対するモーション情報セット（参照ピクチャインデックス、モーションベクトル情報）をエントロピーコーディング部１６０に伝達する。モーション補償部１５４ｂは、モーション補償部１５４ａから伝達されたモーションベクトル値を利用してモーション補償を行う。インター予測部１５４は、参照領域に対するモーション情報を含むインター符号化情報をエントロピーコーディング部１６０に伝達する。

【0039】

更なる実施例によって、予測部１５０はイントラブロックコピー（ｂｌｏｃｋ ｃｏｐｙ、ＢＣ）予測部（図示せず）を含む。イントラＢＣ予測部は、現在ピクチャ内の復元されたサンプルからイントラＢＣ予測を行い、イントラＢＣ符号化情報をエントロピーコーディング部１６０に伝達する。イントラＢＣ予測部は、現在ピクチャ内の特定領域を参照して現在領域の予測に利用される参照領域を示すブロックベクトル値を獲得する。イントラＢＣ予測部は、獲得されたブロックベクトル値を利用してイントラＢＣ予測を行う。イントラＢＣ予測部は、イントラＢＣ符号化情報をエントロピーコーディング部１６０に伝達する。イントラＢＣ予測部はブロックベクトル情報を含む。

【0040】

上述したピクチャ予測が行われれば、変換部１１０は原本ピクチャと予測ピクチャの間のレジデュアル値を変換して変換係数値を獲得する。この際、変換はピクチャ内で特定ブロック単位で行われるが、特定ブロックのサイズは予め設定された範囲内で可変する。量子化部１１５は、変換部１１０で生成された変換係数の値を量子化してエントロピーコーディング部１６０に伝達する。

【0041】

エントロピーコーディング部１６０は、量子化された変換係数を示す情報、イントラ符号化情報、及びインター符号化情報などをエントロピーコーディングしてビデオ信号ビットストリームを生成する。 エントロピーコーディング部１６０では、可変長コーディング（Ｖａｒｉａｂｌｅ Ｌｅｎｇｔｈ Ｃｏｄｅｉｎｇ、ＶＬＣ）方式と算術コーディング（ａｒｉｔｈｍｅｔｉｃ ｃｏｄｉｎｇ）方式などが使用される。可変長コーディング（ＶＬＣ）方式は入力されるシンボルを連続したコードワードにへ難するが、コードワードの長さは可変的である。例えば、よく発生するシンボルは短いコードワードで、よく発生しないシンボルは長いコードワードで表現する。可変長コーディング方式として、コンテキスト基盤適応型可変長コーディング（Ｃｏｎｔｅｘｔ－ｂａｓｅｄ Ａｄａｐｔｉｖｅ Ｖａｒｉａｂｌｅ Ｌｅｎｇｔｈ Ｃｏｄｉｎｇ、ＣＡＶＬＣ）方式が使用される。算術コーディングは連続したデータシンボルを一つの素数に変換するが、算術コーディングは各シンボルを表現するために必要な最適の素数ビットを得る。算術コーディングとして、コンテキスト基盤適合型算術符号化（Ｃｏｎｔｅｘｔ－ｂａｓｅｄ Ａｄａｐｔｉｖｅ Ｂｉｎａｒｙ Ａｒｉｔｈｍｅｔｉｃ Ｃｏｄｉｎｇ、ＣＡＢＡＣ）方式が使用される。 例えば、エントロピーコーディング部１６０は、量子化された変換係数を示す情報を二進化することができる。また、エントロピーコーディング部１６０は、二進化された情報を算術コーディングしてビットストリームを生成することができる。

【0042】

前記生成されたビットストリームは、ＮＡＬ（Ｎｅｔｗｏｒｋ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ）ユニットを基本単位にカプセル化される。ＮＡＬユニットは、符号化された整数個のコーディングツリーユニット（ｃｏｄｉｎｇ ｔｒｅｅ ｕｎｉｔ）を含む。ビデオデコーダでビットストリームを復号化するためには、まずビットストリームをＮＡＬユニット単位に分離した後、分離されたそれぞれのＮＡＬユニットを復号化すべきである。 一方、ビデオ信号ビットストリームの復号化のために必要な情報は、ピクチャーパラメータセット（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ，ＰＰＳ）、シーケンスパラメータセット（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ，ＳＰＳ）、ビデオパラメータセット（Ｖｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ，ＶＰＳ）、デコーディングケイパビリティ情報（Ｄｅｃｏｄｉｎｇ Ｃａｐａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ，ＤＣＩ）などのような上位レベルセットのＲＢＳＰ（Ｒａｗ Ｂｙｔｅ Ｓｅｑｕｅｎｃｅ Ｐａｙｌｏａｄ）で送信されてよい。

【0043】

一方、図１のブロック図は本発明の一実施例によるエンコーディング装置１００を示し、分離して示したブロックはエンコーディング装置１００のエレメントを論理的に区別して示している。よって、上述したエンコーディング装置１００のエレメントは、ディバイスの設計に応じて一つのチップまたは複数のチップに取り付けられる。一実施例によると、上述したエンコーディング装置１００のの各エレメントの動作はプロセッサ（図示せず）によって行われる。

【0044】

図２は、本発明の実施例によるビデオ信号デコーディング装置の２００概略的なブロック図である。図２を参照すると、本明細書のデコーディング装置２００は、エントロピーデコーディング部２１０、逆量子化部２２０、逆変換部２２５、フィルタリング部２３０、及び予測部２５０を含む。

【0045】

エントロピーデコーディング部２１０は、ビデオ信号ビットストリームをエントロピーデコードし、各領域に対する変換係数情報、イントラ符号化情報、インター符号化情報などを抽出する。例えば、エントロピーデコーディング部２１０は、ビデオ信号ビットストリームから特定領域の変換係数情報に対する二進化コードを取得することができる。また、エントロピーデコーディング部２１０は二進化コードを逆二進化し、量子化された変換係数を取得する。逆量子化部２２０は量子化された変換係数を逆量子化し、逆変換部２２５は、逆量子化された変換係数を用いてレジデュアル値を復元する。ビデオ信号処理装置２００は、逆変換部２２５から取得したレジデュアル値を、予測部２５０から取得した予測値と合算して、元来の画素値を復元する。

【0046】

一方、フィルタリング部２３０は、ピクチャに対するフィルタリングを行って画質を向上させる。ここには、ブロック歪曲現象を減少させるためのデブロッキングフィルタ及び／またはピクチャ全体の歪曲を除去するための適応的ループフィルタなどが含まれる。フィルタリングを経たピクチャは出力されるか、次のピクチャに対する参照ピクチャとして利用するために復号ピクチャバッファ（ＤＰＢ）２５６に貯蔵される。

【0047】

予測部２５０は、イントラ予測部２５２及びインター予測部２５４を含む。予測部２５０は、前述したエントロピーデコーディング部２１０を通じて復号化された符号化タイプ、各領域に対する変換係数、イントラ／インター符号化情報などを活用して予測ピクチャを生成する。復号化が遂行される現在ブロックを復元するために、現在ブロックが含まれた現在ピクチャまたは他のピクチャの復号化された領域が利用できる。 復元に現在ピクチャだけを用いる、すなわち、イントラ予測又はイントラＢＣ予測を行うピクチャ（又は、タイル／スライス）をイントラピクチャ又はＩピクチャ（又は、タイル／スライス）、イントラ予測、インター予測及びイントラＢＣ予測を全て行うことができるピクチャ（又は、タイル／スライス）を、インターピクチャ（又は、タイル／スライス）という。インターピクチャ（又は、タイル／スライス）のうち、各ブロックのサンプル値を予測するために、最大で１つのモーションベクトル及び参照ピクチャインデックスを用いるピクチャ（又は、タイル／スライス）を、予測ピクチャ（ｐｒｅｄｉｃｔｉｖｅ ｐｉｃｔｕｒｅ）又はＰピクチャ（又は、タイル／スライス）といい、最大で２つのモーションベクトル及び参照ピクチャインデックスを用いるピクチャ（又は、タイル／スライス）を、双予測ピクチャ（Ｂｉ－ｐｒｅｄｉｃｔｉｖｅ ｐｉｃｔｕｒｅ）又はＢピクチャ（又は、タイル／スライス）という。 言い換えると、Ｐピクチャ（または、タイル／スライス）は各ブロックを予測するために最大１つの動き情報セットを用いて、Ｂピクチャ（または、タイル／スライス）は各ブロックを予測するために最大２つの動き情報セットを用いる。ここで、動き情報セットは１つ以上の動きベクトルと１つの参照ピクチャインデックスを含む。

【0048】

イントラ予測部２５２は、イントラ符号化情報及び現在ピクチャ内の復元されたサンプルを利用して予測ブロックを生成する。上述したように、イントラ符号化情報は、イントラ予測モード、ＭＰＭ（ＭＯＳＴ Ｐｒｏｂａｂｌｅ Ｍｏｄｅ）フラッグ、ＭＰＭインデックスのうち少なくとも一つを含む。イントラ予測部２５２は、現在ブロックの左側及び／または上側に位置する復元されたサンプルを参照サンプルとして利用して、現在ブロックのサンプル値を予測する。本開示において、復元されたサンプル、参照サンプル、及び現在ブロックのサンプルはピクセルを示す。また、サンプル値（ｓａｍｐｌｅ ｖａｌｕｅ）はピクセル値を示す。

【0049】

一実施例において、参照サンプルは現在ブロックの周辺ブロックに含まれたサンプルである。例えば、参照サンプルは現在ブロックの左側境界に隣接したサンプル及び／または上側境界に隣接したサンプルである。また、参照サンプルは現在ブロックの周辺ブロックのサンプルのうち、現在ブロックの左側境界から予め設定された距離以内のライン上に位置するサンプル及び／または現在ブロックの上側境界から予め設定された距離以内のライン上に位置するサンプルである。この際、現在ブロックの周辺ブロックは、現在ブロックに隣接した左側（Ｌ）ブロック、上側（Ａ）ブロック、下左側（Ｂｅｌｏｗ Ｌｅｆｔ、ＢＬ）ブロック、右上側（Ａｂｏｖｅ Ｒｉｇｈｔ、ＡＲ）ブロック、または左上側（Ａｂｏｖｅ Ｌｅｆｔ、ＡＬ）ブロックのうち少なくとも一つを含む。

【0050】

インター予測部２５４は、復号ピクチャバッファ２５６に貯蔵された参照ピクチャ及びインター符号化情報を利用して予測ブロックを生成する。インター符号化情報は、参照ブロックに対する現在ブロックのモーション情報セット（参照ピクチャインデックス、モーションベクトルなど）を含む。インター予測には、Ｌ０予測、Ｌ１予測、及び双予測（Ｂｉ－ｐｒｅｄｉｃｔｉｏｎ）がある。Ｌ０予測はＬ０ピクチャリストに含まれた一つの参照ピクチャを利用した予測であり、Ｌ１予測はＬ１ピクチャリストに含まれた一つの参照ピクチャを利用した予測を意味する。そのためには、１セットのモーション情報（例えば、モーションベクトル及び参照ピクチャインデックス）が必要である。双予測方式では最大２つの参照領域を利用するが、この２つの参照領域は同じ参照ピクチャに存在してもよく、互いに異なるピクチャにそれぞれ存在してもよい。つまり、双予測方式では最大２セットのモーション情報（例えば、モーションベクトル及び参照ピクチャインデックス）が利用されるが、２つのモーションベクトルが同じ参照ピクチャインデックスに対応してもよく、互いに異なる参照ピクチャインデックスに対応してもよい。この際、参照ピクチャは時間的に現在ピクチャの以前や以降のいずれにも表示（または出力）される。 一実施例によって、双予測方式では、使用される２個の参照領域は、Ｌ０ピクチャリスト及びＬ１ピクチャリストのそれぞれから選択された領域であってよい。

【0051】

インター予測部２５４は、モーションベクトル及び参照ピクチャインデックスを利用して現在の参照ブロックを獲得する。前記参照ブロックは、参照ピクチャインデックスに対応する参照ピクチャ内に存在する。また、モーションベクトルによって特定されたブロックのサンプル値またはこれの補間（ｉｎｔｅｒｐｏｌａｔｉｏｎ）された値が現在ブロックの予測子（ｐｒｅｄｉｃｔｏｒ）として利用される。サブペル（ｓｕｂ－ｐｅｌ）単位のピクセル正確度を有するモーション予測のために、例えば、輝度信号に対して８－タブ補間フィルタが、色差信号に対して４－タブ補間フィルタが使用される。但し、サブペル単位のモーション予測のための補間フィルタはこれに限らない。このように、インター予測部２５４は、以前復元されたピクチャから現在ユニットのテクスチャを予測するモーション補償（ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｉｏｎ）を行う。この際、インター予測部はモーション情報セットを利用する。

【0052】

更なる実施例によって、予測部２５０は、イントラＢＣ予測部（図示せず）を含むことができる。イントラＢＣ予測部は、現在ピクチャ内の復元されたサンプルを含む特定領域を参照して現在領域を復元することができる。イントラＢＣ予測部は、エントロピーデコーディング部２１０から、現在領域に対するイントラＢＣ符号化情報を取得する。イントラＢＣ予測部は、現在ピクチャ内の特定領域を指示する現在領域のブロックベクトル値を取得する。イントラＢＣ予測部は、取得されたブロックベクトル値を用いてイントラＢＣ予測を行うことができる。イントラＢＣ符号化情報は、ブロックベクトル情報を含むことができる。

【0053】

前記イントラ予測部２５２又はインター予測部２５４から出力された予測値、及び逆変換部２２５から出力されたレジデュアル値が合算されて復元されたビデオピクチャが生成される。すなわち、ビデオ信号デコーディング装置２００は、予測部２５０で生成された予測ブロックと逆変換部２２５から取得されたレジデュアルを用いて現在ブロックを復元する。

【0054】

一方、図２のブロック図は本発明の一実施例によるデコーディング装置２００を示し、分離して示したブロックはデコーディング装置２００のエレメントを論理的に区別して示している。よって、上述したデコーディング装置２００のエレメントは、ディバイスの設計に応じて一つのチップまたは複数のチップに取り付けられる。一実施り例によると、上述したデコーディング装置２００のの各エレメントの動作はプロセッサ（図示せず）によって行われる。

【0055】

図３は、ピクチャ内でコーディングツリーユニット（Ｃｏｄｉｎｇ Ｔｒｅｅ Ｕｎｉｔ、ＣＴＵ）がコーディングユニット（Ｃｏｄｉｎｇ Ｕｎｉｔｓ、ＣＵｓ）に分割される実施例を示している。ビデオ信号のコーディング過程において、ピクチャはコーディングツリーユニット（ＣＴＵ）のシーケンスに分割される。コーディングツリーユニットは、輝度サンプルのＮＸＮブロックと、それに対応する色差サンプルの２つのブロックからなる。コーディングツリーユニットは、複数のコーディングユニットに分割される。コーディングツリーユニットは分割されずにリーフノードになってもよい。この場合、コーディングツリーユニット自体がコーディングユニットになり得る。コーディングユニットは上述したビデオ信号の処理過程、つまり、イントラ／インター予測、変換、量子化及び／またはエントロピーコーディングなどの過程でピクチャを処理するための基本単位を指す。一つのピクチャ内において、コーディングユニットのサイズ及び模様は一定ではない。コーディングユニットは正方形または長方形の模様を有する。長方形コーディングユニット（または、長方形ブロック）は垂直コーディングユニット（または、垂直ブロック）と水平コーディングユニット（または、水平ブロック）を含む。本明細書において、垂直ブロックは高さが幅より大きいブロックであり、水平ブロックは幅が高さより大きいブロックである。また、本明細書において、正方形ではない（ｎｏｎ－ｓｑｕａｒｅ）ブロックは長方形ブロックを指すが、本発明はこれに限らない。

【0056】

図３を参照すると、コーディングツリーユニットは、まずクォードツリー（Ｑｕａｄ Ｔｒｅｅ、ＱＴ）構造に分割される。つまり、クォードツリー構造において、２Ｎ×２Ｎのサイズを有する一つのノードはＮ×Ｎのサイズを有する４つのノードに分割される。本明細書において、クォードツリーは４進（ｑｕａｔｅｒｎａｒｙ）ツリーとも称される。クォードツリー分割は再帰的に行われ、全てのノードが同じ深さに分割される必要はない。

【0057】

一方、上述したクォードツリーのリーフノード（ｌｅａｆ ｎｏｄｅ）は、マルチ－タイプツリー（Ｍｕｌｔｉ－Ｔｙｐｅ Ｔｒｅｅ、ＭＴＴ）構造に更に分割される。本発明の実施例によると、マルチタイプツリー構造では一つのノードが水平または垂直分割の２進（ｂｉｎａｒｙ、バイナリー）または３進（ｔｅｒｎａｒｙ、ターナリー）ツリー構造に分割される。つまり、マルチ－タイプツリー構造には、垂直バイナリー分割、水平バイナリー分割、垂直ターナリー分割、及び水平ターナリー分割の４つの分割構造が存在する。本発明の実施例によると、前記各ツリー構造において、ノードの幅及び高さはいずれも２の累乗値を有する。例えば、バイナリーツリー（ｂｉｎａｒｙ Ｔｒｅｅ、ＢＴ）構造において、２Ｎ×２Ｎのサイズのノードは垂直バイナリー分割によって２つのＮ×２Ｎノードに分割され、水平バイナリー分割によって２つの２Ｎ×Ｎノードに分割される。また、ターナリーツリー（Ｔｅｒｎａｒｙ Ｔｒｅｅ、ＴＴ）構造において、２Ｎ×２Ｎのサイズのノードは垂直ターナリー分割によって（Ｎ／２）×２Ｎ、Ｎ×２Ｎ及び（Ｎ／２）×２Ｎのノードに分割され、水平ターナリー分割によって２Ｎ×（Ｎ／２）、２Ｎ×Ｎ及び２Ｎ×（Ｎ／２）のノードに分割される。このようなマルチ－タイプツリー分割は再帰的に行われる。

【0058】

マルチタイプツリーのリーフノードは、コーディングユニットになり得る。コーディングユニットが最大変換長に比べて大きくない場合、当該コーディングユニットはそれ以上の分割無しで予測及び／又は変換の単位として用いられてよい。一実施例として、現在コーディングユニットの幅又は高さが最大変換長よりも大きい場合に、現在コーディングユニットは、分割に関する明示的シグナリング無しで複数の変換ユニットに分割されてよい。 一方、上述したクォードツリー及びマルチ－タイプツリーにおいて、次のパラメータのうち少なくとも一つが事前に定義されるか、ＰＰＳ、ＳＰＳ、ＶＰＳなどのような上位レベルセットのＲＢＳＰを介して伝送される。１）ＣＴＵサイズ：クォードツリーのルートノード（ｒｏｏｔ ｎｏｄｅ）のサイズ、２）最小ＱＴサイズ（ＭｉｎＱｔＳｉｚｅ）：許容された最小ＱＴリーフノードのサイズ、３）最大ＢＴサイズ（ＭａｘＢｔＳｉｚｅ）：許容された最大ＢＴルートノードのサイズ、４）最大ＴＴサイズ（ＭａｘＴｔＳｉｚｅ）：許容された最大ＴＴルートノードのサイズ、５）最大ＭＴＴ深さ（ＭａｘＭｔｔＤｅｐｔｈ）：ＱＴのリーフノードからのＭＴＴ分割の最大許容深さ、６）最小ＢＴサイズ（ＭｉｎＢｔＳｉｚｅ）：許容された最小ＢＴリーフノードのサイズ、７）最小ＴＴサイズ：許容された最小ＴＴリーフノードのサイズ。

【0059】

図４は、クアッドツリー及びマルチタイプツリーの分割をシグナルする方法の一実施例を示す。前述したクアッドツリー及びマルチタイプツリーの分割をシグナルするために、既に設定されたフラグが用いられてよい。図４を参照すると、ノードの分割されるか否かを示すフラグ‘ｓｐｌｉｔ＿ｃｕ＿ｆｌａｇ’、クアッドツリーノードの分割されるか否かを示すフラグ‘ｓｐｌｉｔ＿ｑｔ＿ｆｌａｇ’、マルチタイプツリーノードの分割方向を示すフラグ‘ｍｔｔ＿ｓｐｌｉｔ＿ｃｕ＿ｖｅｒｔｉｃａｌ＿ｆｌａｇ’、又はマルチタイプツリーノードの分割形態を示すフラグ‘ｍｔｔ＿ｓｐｌｉｔ＿ｃｕ＿ｂｉｎａｒｙ＿ｆｌａｇ’のうち少なくとも一つが用いられてよい。

【0060】

本発明の実施例によれば、現在ノードの分割されるか否かを示すフラグである‘ｓｐｌｉｔ＿ｃｕ＿ｆｌａｇ’がまずシグナルされてよい。‘ｓｐｌｉｔ＿ｃｕ＿ｆｌａｇ’の値が０である場合、現在ノードが分割されないことを示し、現在ノードはコーディングユニットになる。現在ノードがコーティングツリーユニットである場合、コーディングツリーユニットは、分割されていない一つのコーディングユニットを含む。現在ノードがクアッドツリーノード‘ＱＴ ｎｏｄｅ’である場合、現在ノードはクアッドツリーのリーフノード‘ＱＴ ｌｅａｆ ｎｏｄｅ’であり、コーディングユニットになる。現在ノードがマルチタイプツリーノード‘ＭＴＴ ｎｏｄｅ’である場合、現在ノードはマルチタイプツリーのリーフノード‘ＭＴＴ ｌｅａｆ ｎｏｄｅ’であり、コーディングユニットになる。

【0061】

‘ｓｐｌｉｔ＿ｃｕ＿ｆｌａｇ’の値が１である場合、現在ノードは‘ｓｐｌｉｔ＿ｑｔ＿ｆｌａｇ’の値によってクアッドツリー又はマルチタイプツリーのノードに分割されてよい。コーディングツリーユニットは、クアッドツリーのルートノードであり、クアッドツリー構造にまず分割されてよい。クアッドツリー構造では、それぞれのノード‘ＱＴ ｎｏｄｅ’別に‘ｓｐｌｉｔ＿ｑｔ＿ｆｌａｇ’がシグナルされる。‘ｓｐｌｉｔ＿ｑｔ＿ｆｌａｇ’の値が１である場合、当該ノードは４個の正方形ノードに分割され、‘ｑｔ＿ｓｐｌｉｔ＿ｆｌａｇ’の値が０である場合、当該ノードはクアッドツリーのリーフノード‘ＱＴ ｌｅａｆ ｎｏｄｅ’になり、当該ノードはマルチタイプノードに分割される。本発明の実施例によれば、現在ノードの種類によってクアッドツリー分割は制限されることがある。現在ノードがコーディングツリーユニット（クアッドツリーのルートノード）又はクアッドツリーノードである場合に、クアッドツリー分割が許容されてよく、現在ノードがマルチタイプツリーノードである場合に、クアッドツリー分割は許容されなくてよい。それぞれのクアッドツリーリーフノード‘ＱＴ ｌｅａｆ ｎｏｄｅ’は、マルチタイプツリー構造にさらに分割されてよい。上述したように、‘ｓｐｌｉｔ＿ｑｔ＿ｆｌａｇ’が０である場合に、現在ノードはマルチタイプノードに分割されてよい。分割方向及び分割形態を示すために、‘ｍｔｔ＿ｓｐｌｉｔ＿ｃｕ＿ｖｅｒｔｉｃａｌ＿ｆｌａｇ’及び‘ｍｔｔ＿ｓｐｌｉｔ＿ｃｕ＿ｂｉｎａｒｙ＿ｆｌａｇ’がシグナルされてよい。‘ｍｔｔ＿ｓｐｌｉｔ＿ｃｕ＿ｖｅｒｔｉｃａｌ＿ｆｌａｇ’の値が１である場合、ノード‘ＭＴＴ ｎｏｄｅ’の垂直分割を示し、‘ｍｔｔ＿ｓｐｌｉｔ＿ｃｕ＿ｖｅｒｔｉｃａｌ＿ｆｌａｇ’の値が０である場合、ノード‘ＭＴＴ ｎｏｄｅ’の水平分割を示す。また、‘ｍｔｔ＿ｓｐｌｉｔ＿ｃｕ＿ｂｉｎａｒｙ＿ｆｌａｇ’の値が１である場合、ノード‘ＭＴＴ ｎｏｄｅ’は２個の長方形ノードに分割され、‘ｍｔｔ＿ｓｐｌｉｔ＿ｃｕ＿ｂｉｎａｒｙ＿ｆｌａｇ’の値が０である場合、ノード‘ＭＴＴ ｎｏｄｅ’は３個の長方形ノードに分割される。

【0062】

コーティングのためのピクチャ予測（モーション補償）はそれ以上分けられないコーディングユニット（つまり、コーディングユニットツリーのリーフノード）を対象に行われる。このような予測を行う基本単位を、以下では予測ユニット（ｐｒｅｄｉｃｔｉｏｎ ｕｎｉｔ）または予測ブロック（ｐｒｅｄｉｃｔｉｏｎ ｂｌｏｃｋ）という。

【0063】

以下、本明細書で使用されるユニットという用語は、予測を行う基本単位である前記予測ユニットを代替する用語として使用される。但し、本発明はこれに限らず、より広い意味では、前記コーディングユニットを含む概念として理解される。

【0064】

図５及び図６は、本発明の実施例によるイントラ予測方法をより詳しく示す図である。上述したように、イントラ予測部は、現在ブロックの左側及び／または上側に位置する復元されたサンプルを参照サンプルとして利用して、現在ブロックのサンプル値を予測する。

【0065】

まず、図５はイントラ予測モードで現在ブロックを予測するために使用される参照サンプルの一実施例を示す。一実施例によると、参照サンプルは現在ブロックの左側境界に隣接したサンプル及び／または上側境界に隣接したサンプルである。図５に示したように、現在ブロックのサイズがＷ×Ｈで現在ブロックに隣接した単一参照ライン（ｌｉｎｅ）のサンプルがイントラ予測に使用されれば、現在ブロックの左側及び／または上側に位置した最大２Ｗ＋２Ｈ＋１個の周辺サンプルを使用して参照サンプルが設定される。

【0066】

また、参照サンプルとして使用される少なくとも一部のサンプルがまだ復元されていなければ、イントラ予測部は参照サンプルパッディング過程を行って参照サンプルを獲得する。また、イントラ予測部は、イントラ予測の誤差を減らすために参照サンプルフィルタリング過程を行う。つまり、周辺サンプル及び／または参照サンプルパッディング過程によって獲得された参照サンプルにフィルタリングを行って、フィルタリングされた参照サンプルを獲得する。 イントラ予測部は、このように取得された参照サンプルを用いて現在ブロックのサンプルを予測する。イントラ予測部は、フィルタリングされない参照サンプル又はフィルタリングされた参照サンプルを用いて現在ブロックのサンプルを予測する。本開示において、周辺サンプルは、少なくとも一つの参照ライン上のサンプルを含むことができる。例えば、周辺サンプルは、現在ブロックの境界に隣接したライン上の隣接サンプルを含むことができる。

【0067】

次に、図６はイントラ予測に使われる予測モードの一実施形態を図示する。イントラ予測のために、イントラ予測方向を指示するイントラ予測モード情報がシグナリングできる。イントラ予測モード情報は、イントラ予測モードセットを構成する複数のイントラ予測モードのうち、いずれか１つを指示する。現在ブロックがイントラ予測されたブロックである場合、デコーダーはビットストリームから現在ブロックのイントラ予測モード情報を受信する。デコーダのイントラ予測部は、抽出されたイントラ予測モード情報に基づいて現在ブロックに対するイントラ予測を遂行する。

【0068】

本発明の実施例によると、イントラ予測モードセットは、イントラ予測に使用される全てのイントラ予測モード（例えば、総６７個のイントラ予測モード）を含む。より詳しくは、イントラ予測モードセットは、平面モード、ＤＣモード、及び複数の（例えば、６５個の）角度モード（つまり、方向モード）を含む。 それぞれのイントラ予測モードは、予め設定されたインデックス（つまり、イントラ予測モードインデックス）を介して指示される。例えば、図６に示したように、イントラ予測モードインデックス０は平面（ｐｌａｎａｒ）モードを指示し、イントラ予測モードインデックス１はＤＣモードを指示する。また、イントラ予測モードインデックス２乃至６６は、互いに異なる角度モードをそれぞれ指示する。 角度モードは、既に設定された角度範囲以内の異なる角度をそれぞれ指示する。例えば、角度モードは時計回り方向に４５°～－１３５°の角度範囲（すなわち、第１角度範囲）以内の角度を指示できる。前記角度モードは１２時方向を基準に定義されてよい。この際、イントラ予測モードインデックス２は水平対角（Ｈｏｒｉｚｏｎｔａｌ Ｄｉａｇｏｎａｌ、ＨＤＩＡ）モードを指示し、イントラ予測モードインデックス１８は水平（Ｈｏｒｉｚｏｎｔａｌ、ＨＯＲ）モードを指示し、イントラ予測モードインデックス３４は対角（Ｄｉａｇｏｎａｌ、ＤＩＡ）モードを指示し、イントラ予測モードインデックス５０は水直（Ｖｅｒｔｉｃａｌ、ＶＥＲ）モードを指示し、イントラ予測モードインデックス６６は垂直対角（Ｖｅｒｔｉｃａｌ Ｄｉａｇｏｎａｌ、ＶＤＩＡ）モードを指示する。

【0069】

一方、既に設定された角度範囲は、現在ブロックの形態によって個別に設定されてよい。例えば、現在ブロックが長方形ブロックであれば、時計回り方向に４５°を超える或いは－１３５°未満の角度を示す広角モードがさらに用いられてよい。現在ブロックが水平ブロックであれば、角度モードは、時計回り方向に（４５＋ｏｆｆｓｅｔ １）°～（－１３５＋ｏｆｆｓｅｔ １）°の角度範囲（すなわち、第２角度範囲）以内の角度を示すことができる。このとき、第１角度範囲を外れる角度モード６７～７６がさらに用いられてよい。また、現在ブロックが垂直ブロックであれば、角度モードは、時計回り方向に（４５－ｏｆｆｓｅｔ ２）°～（－１３５－ｏｆｆｓｅｔ ２）の角度範囲（すなわち、第３角度範囲）以内の角度を示すことができる。このとき、第１角度範囲を外れる角度モード－１０～－１がさらに用いられてよい。本発明の実施例によれば、ｏｆｆｓｅｔ １及びｏｆｆｓｅｔ ２の値は、長方形ブロックの幅と高さとの比率によって個別に決定されてよい。また、ｏｆｆｓｅｔ １及びｏｆｆｓｅｔ ２は正数であってよい。

【0070】

本発明の更なる実施例によれば、イントラ予測モードセットを構成する複数の角度モードは、基本角度モードと拡張角度モードを含むことができる。このとき、拡張角度モードは基本角度モードに基づいて決定されてよい。

【0071】

一実施例によれば、基本角度モードは、既存ＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）標準のイントラ予測で用いられる角度に対応するモードであり、拡張角度モードは、次世代ビデオコーデック標準のイントラ予測で新しく追加される角度に対応するモードであってよい。より具体的に、基本角度モードは、イントラ予測モード｛２，４，６，…，６６｝のいずれか一つに対応する角度モードであり、拡張角度モードは、イントラ予測モード｛３，５，７，…，６５｝のいずれか一つに対応する角度モードであってよい。すなわち、拡張角度モードは、第１角度範囲内で基本角度モード間の角度モードであってよい。したがって、拡張角度モードが示す角度は、基本角度モードが示す角度に基づいて決定されてよい。

【0072】

他の実施例によれば、基本角度モードは、既に設定された第１角度範囲以内の角度に対応するモードであり、拡張角度モードは、前記第１角度範囲を外れる広角モードであってよい。すなわち、基本角度モードは、イントラ予測モード｛２，３，４，…，６６｝のいずれか一つに対応する角度モードであり、拡張角度モードは、イントラ予測モード｛－１０，－９，…，－１｝及び｛６７，６８，…，７６｝のいずれか一つに対応する角度モードであってよい。拡張角度モードが示す角度は、対応する基本角度モードが示す角度の反対側の角度と決定されてよい。したがって、拡張角度モードが示す角度は、基本角度モードが示す角度に基づいて決定されてよい。一方、拡張角度モードの個数はこれに限定されず、現在ブロックのサイズ及び／又は形態によって更なる張角度が定義されてよい。例えば、拡張角度モードは、イントラ予測モード｛－１４，－１３，…，－１｝及び｛６７，６８，…，８０｝のいずれか一つに対応する角度モードと定義されてよい。一方、イントラ予測モードセットに含まれるイントラ予測モードの総個数は、前述した基本角度モードと拡張角度モードの構成によって可変してよい。

【0073】

上記の実施例において、拡張角度モード間の間隔は、対応する基本角度モード間の間隔に基づいて設定されてよい。例えば、拡張角度モード｛３，５，７，…，６５｝間の間隔は、対応する基本角度モード｛２，４，６，…，６６｝間の間隔に基づいて決定されてよい。また、拡張角度モード｛－１０，－９，…，－１｝間の間隔は、対応する反対側の基本角度モード｛５６，５７，…，６５｝間の間隔に基づいて決定され、拡張角度モード｛６７，６８，…，７６｝間の間隔は、対応する反対側の基本角度モード｛３，４，…，１２｝間の間隔に基づいて決定されてよい。拡張角度モード間の角度間隔は、対応する基本角度モード間の角度間隔と同一となるように設定されてよい。また、イントラ予測モードセットにおいて拡張角度モードの個数は、基本角度モードの個数以下に設定されてよい。

【0074】

本発明の実施例によれば、拡張角度モードは、基本角度モードに基づいてシグナルされてよい。例えば、広角モード（すなわち、拡張角度モード）は、第１角度範囲以内の少なくとも一つの角度モード（すなわち、基本角度モード）を代替することができる。代替される基本角度モードは、広角モードの反対側に対応する角度モードであってよい。すなわち、代替される基本角度モードは、広角モードが示す角度の反対方向の角度に対応するか或いは前記反対方向の角度から既に設定されたオフセットインデックスだけの差を有する角度に対応する角度モードである。本発明の実施例によれば、既に設定されたオフセットインデックスは、１である。代替される基本角度モードに対応するイントラ予測モードインデックスは、広角モードに再びマップされ、当該広角モードをシグナリングできる。例えば、広角モード｛－１０，－９，…，－１｝は、イントラ予測モードインデックス｛５７，５８，…，６６｝によってそれぞれシグナルされてよく、広角モード｛６７，６８，…，７６｝は、イントラ予測モードインデックス｛２，３，…，１１｝によってそれぞれシグナルされてよい。このように基本角度モードのためのイントラ予測モードインデックスで拡張角度モードをシグナルすることにより、各ブロックのイントラ予測に用いられる角度モードの構成が互いに異なっても、同じセットのイントラ予測モードインデックスがイントラ予測モードのシグナリングに用いられてよい。したがって、イントラ予測モード構成の変化によるシグナリングオーバーヘッドが最小化し得る。

【0075】

一方、拡張角度モードの使用されるか否かは、現在ブロックの形態及びサイズのうち少なくとも一つに基づいて決定されてよい。一実施例によれば、現在ブロックのサイズが既に設定されたサイズよりも大きい場合、拡張角度モードが現在ブロックのイントラ予測のために用いられ、そうでない場合、基本角度モードのみが現在ブロックのイントラ予測のために用いられてよい。他の実施例によれば、現在ブロックが正方形以外のブロックである場合、拡張角度モードが現在ブロックのイントラ予測のために用いられ、現在ブロックが正方形ブロックである場合、基本角度モードのみが現在ブロックのイントラ予測のために用いられてよい。

【0076】

以下、図７を参照して、本発明の一実施形態によるインター予測方法について説明する。本明細書で説明されるインター予測方法は、並進運動(translation motion)に最適化された一般的なインター予測方法およびアフィン(affine)モデルベースのインター予測方法を含むことができる。さらに、動きベクトルは、一般的なインター予測方法による動き補償のための一般的な動きベクトルと、アフィン動き補償のための制御点動きベクトルのうちの少なくとも１つとを含むことができる。

【0077】

図７は、本発明の一実施例に係るインター予測方法を示す図である。前述したように、デコーダは、復号化された他のピクチャーの復元されたサンプルを参照して現在ブロックを予測することができる。図７を参照すると、デコーダは、現在ブロック７０１のモーション情報セットに基づいて参照ピクチャー７２０内の参照ブロック７０２を取得する。このとき、モーション情報セットは、参照ピクチャーインデックス及びモーションベクトル７０３を含むことができる。参照ピクチャーインデックスは、参照ピクチャーリストにおいて現在ブロックのインター予測のための参照ブロックが含まれた参照ピクチャー７２０を示す。一実施例によって、参照ピクチャーリストは、前述したＬ０ピクチャーリスト又はＬ１ピクチャーリストのうち少なくとも一つを含むことができる。モーションベクトル７０３は、現在ピクチャー７１０内で現在ブロック７０１の座標値と参照ピクチャー７２０内で参照ブロック７０２の座標値とのオフセットを表す。デコーダは、参照ブロック７０２のサンプル値に基づいて現在ブロック７０１の予測子を取得し、該予測子を用いて現在ブロック７０１を復元する。

【0078】

具体的に、エンコーダは、復元順序が先であるピクチャーから現在ブロックと類似のブロックを探索し、前述した参照ブロックを取得できる。例えば、エンコーダは、既に設定された探索領域内で現在ブロックとサンプル値との差の和が最小となる参照ブロックを探索するこができる。このとき、現在ブロックと参照ブロックのサンプル間の類似度を測定するために、ＳＡＤ（ｓｕｍ ｏｆ ａｂｓｏｌｕｔｅ ｄｉｆｆｅｒｅｎｃｅ）又はＳＡＴＤ（ｓｕｍ ｏｆ ｈａｄａｍａｒｄ ｔｒａｎｓｆｏｒｍｅｄ ｄｉｆｆｅｒｅｎｃｅ）のうち少なくとも一つが用いられてよい。ここで、ＳＡＤは、両ブロックに含まれたサンプル値の差のそれぞれの絶対値を全て合算した値であってよい。また、ＳＡＴＤは、両ブロックに含まれたサンプル値の各差をアダマール変換（ｈａｄａｍａｒｄ ｔｒａｎｓｆｏｒｍ）して取得されたアダマール変換係数の絶対値を全て合算した値であってよい。

【0079】

一方、現在ブロックは、一つ以上の参照領域を用いて予測されてよい。前述したように、現在ブロックは、２個以上の参照領域を利用する双予測方式によってインター予測されてよい。一実施例によって、デコーダは、現在ブロックの２個のモーション情報セットに基づいて２個の参照ブロックを取得することができる。また、デコーダは、取得された２個の参照ブロックのそれぞれのサンプル値に基づいて現在ブロックの第１予測子及び第２予測子を取得することができる。また、デコーダは、第１予測子及び第２予測子を用いて現在ブロックを復元することができる。例えば、デコーダは、第１予測子及び第２予測子のサンプル別平均に基づいて現在ブロックを復元することができる。

【0080】

前述したように、現在ブロックのモーション補償のために、一つ以上のモーション情報セットがシグナルされてよい。このとき、複数のブロックのそれぞれのモーション補償のためのモーション情報セット間の類似性が用いられてよい。例えば、現在ブロックの予測に用いられるモーション情報セットは、既に復元された他のサンプルのいずれか一つの予測に用いられたモーション情報セットから誘導されてよい。これにより、エンコーダ及びデコーダはシグナリングオーバーヘッドを減少させることができる。以下では、現在ブロックのモーション情報セットがシグナルされる様々な実施例について説明する。

【0081】

図８は、本発明の一実施例に係る、現在ブロックのモーションベクトルがシグナルされる方法を示す図である。本発明の一実施例によって、現在ブロックのモーションベクトルは、現在ブロックのモーションベクトル予測子（ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ，ＭＶＰ）から誘導されてよい。一実施例によって、現在ブロックのモーションベクトルを誘導するために参照されるモーションベクトル予測子は、モーションベクトル予測子（ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ，ＭＶＰ）候補リストを用いて取得できる。ＭＶＰ候補リストは、既に設定された個数のＭＶＰ候補Ｃａｎｄｉｄａｔｅ １，Ｃａｎｄｉｄａｔｅ ２，．．．，Ｃａｎｄｉｄａｔｅ Ｎを含むことができる。

【0082】

一実施例によって、ＭＶＰ候補リストは、空間的候補又は時間的候補のうち少なくとも一つを含むことができる。空間的候補は、現在ピクチャー内で現在ブロックから一定の範囲以内の周辺ブロックの予測に用いられたモーション情報セットであってよい。空間的候補は、現在ブロックの周辺ブロックのうち利用可能な周辺ブロックに基づいて構成されてよい。また、時間的候補は、現在ピクチャーと他のピクチャー内のブロックの予測に用いられたモーション情報セットであってよい。例えば、時間的候補は、特定参照ピクチャー内で現在ブロックの位置に対応する特定ブロックに基づいて構成されてよい。このとき、特定ブロックの位置は、前記参照ピクチャー内で特定ブロックの左上端（ｔｏｐ－ｌｅｆｔ）サンプルの位置を表す。更なる実施例によって、ＭＶＰ候補リストは、ゼロモーションベクトルを含むことができる。更なる実施例によって、現在ブロックのＭＶＰ候補リストが含むＭＶＰ候補に対するラウンディング（ｒｏｕｎｄｉｎｇ）プロセスが行われてよい。このとき、後述する現在ブロックのモーションベクトル差分値のレゾリューションが用いられてよい。例えば、現在ブロックのＭＶＰ候補はそれぞれ、現在ブロックのモーションベクトル差分値のレゾリューションに基づいてラウンドされてよい。

【0083】

本開示において、ＭＶＰ候補リストは、改善された時間的モーションベクトル候補（ａｄｖａｎｃｅｄ ｔｅｍｐｏｒａｌ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｉｏｎ，ＡＴＭＶＰ）リスト、マージインター予測のためのマージ候補リスト、アフィンモーション補償のためのコントロールポイントモーションベクトル候補リスト、サブブロックベースのモーション補償のための時間的モーションベクトル候補（ｓｕｂｂｌｏｃｋ－ｂａｓｅｄ ｔｅｍｐｏｒａｌ ｍｏｔｉｏｎ ｖｅｃｔｏ ｐｒｅｄｉｃｔｉｏｎ，ＳＴＭＶＰ）リスト、及びこれらの組合せを含むことができる。

【0084】

一実施例によって、エンコーダ８１０及びデコーダ８２０は、現在ブロックのモーション補償のためのＭＶＰ候補リストを構成することができる。例えば、現在ブロックよりも先に復元されたサンプルのうち、現在ブロックのモーション情報セットと同一又は類似するモーション情報セットに基づいて予測されている可能性のあるサンプルに対応する候補が存在してよい。エンコーダ８１０及びデコーダ８２０は、当該複数の候補ブロックに基づいて現在ブロックのＭＶＰ候補リストを構成することができる。このとき、エンコーダ８１０及びデコーダ８２０は、エンコーダ８１０とデコーダ８２０との間にあらかじめ定義された規則にしたがって、ＭＶＰ候補リストを構成することができる。すなわち、エンコーダ８１０とデコーダ８２０のそれぞれにおいて構成されたＭＶＰ候補リストは、互いに同一であってよい。

【0085】

また、あらかじめ定義された規則は、現在ブロックの予測モードによって変わってよい。例えば、現在ブロックの予測モードがアフィンモデルベースのアフィン予測モードである場合に、エンコーダ及びデコーダは、アフィンモデルに基づく第１方法を用いて現在ブロックのＭＶＰ候補リストを構成することができる。第１方法は、コントロールポイントモーションベクトル候補リストを取得する方法であってよい。これに対し、現在ブロックの予測モードがアフィンモデルに基づいていない一般インター予測モードである場合、エンコーダ及びデコーダは、アフィンモデルに基づいていない第２方法を用いて現在ブロックのＭＶＰ候補リストを構成することができる。このとき、第１方法と第２方法は、互いに異なる方法であってよい。

【0086】

デコーダ８２０は、現在ブロックのＭＶＰ候補リストが含む少なくとも一つのＭＶＰ候補のいずれか一つに基づいて現在ブロックのモーションベクトルを誘導することができる。例えば、エンコーダ８１０は、現在ブロックのモーションベクトルを誘導するために参照されるモーションベクトル予測子を指示するＭＶＰインデックス（ｉｎｄｅｘ）をシグナルすることができる。デコーダ８２０は、シグナルされたＭＶＰインデックスに基づいて現在ブロックのモーションベクトル予測子を取得することができる。デコーダ８２０は、モーションベクトル予測子を用いて現在ブロックのモーションベクトルを誘導することができる。一実施例によって、デコーダ８２０は、ＭＶＰ候補リストから取得されたモーションベクトル予測子を、別のモーションベクトル差分値無しで、現在ブロックのモーションベクトルとして使用することができる。デコーダ８２０は、現在ブロックのモーションベクトルに基づいて現在ブロックを復元することができる。ＭＶＰ候補リストから取得されたモーションベクトル予測子が別のモーションベクトル差分値無しで現在ブロックのモーションベクトルとして使用されるインター予測モードは、マージモードと呼ぶことができる。

【0087】

他の実施例によって、デコーダ８２０は、現在ブロックのモーションベクトルのための別のモーションベクトル差分値（ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ）を取得することができる。デコーダ８２０は、ＭＶＰ候補リストから取得されたモーションベクトル予測子と現在ブロックのモーションベクトル差分値とを合算して現在ブロックのモーションベクトルを取得することができる。この場合、エンコーダ８１０は、現在ブロックのモーションベクトルとモーションベクトル予測子間の差を表すモーションベクトル（ｍｏｔｉｏｎ ｖｅｃｔｏｒ，ＭＶ）差分値（ＭＶ ｄｉｆｆｅｒｅｎｃｅ）をシグナルすることができる。モーションベクトル差分値がシグナルされる方法については、図９で具体的に説明する。デコーダ８２０は、モーションベクトル差分値（ＭＶ ｄｉｆｆｅｒｅｎｃｅ）に基づいて現在ブロックのモーションベクトルを取得することができる。デコーダ８２０は、現在ブロックのモーションベクトルに基づいて現在ブロックを復元することができる。

【0088】

さらに、現在ブロックのモーション補償のための参照ピクチャーインデックスがシグナルされてよい。エンコーダ８１０は、参照ブロックを含む参照ピクチャーを指示する参照ピクチャーインデックスをシグナルすることができる。デコーダ８２０は、シグナルされた参照ピクチャーインデックスに基づいて現在ブロックの復元に参照される参照ピクチャーのＰＯＣを取得することができる。このとき、参照ピクチャーのＰＯＣが現在ブロックのモーションベクトルを誘導するために参照されるＭＶＰに対応する参照ピクチャーのＰＯＣと互いに異なってよい。この場合、デコーダ８２０は、モーションベクトルスケーリングを行うことができる。すなわち、デコーダ８２０は、ＭＶＰをスケーリングしてＭＶＰ’を取得することができる。このとき、モーションベクトルスケーリングは、現在ピクチャーのＰＯＣ、現在ブロックのシグナルされた参照ピクチャーのＰＯＣ及びＭＶＰに対応する参照ピクチャーのＰＯＣに基づいて行われてよい。また、デコーダ８２０は、ＭＶＰ’を現在ブロックのモーションベクトル予測子として使用することができる。

【0089】

前述したように、現在ブロックのモーションベクトルは、現在ブロックのモーションベクトル予測子とモーションベクトル差分値を合算して取得できる。このとき、モーションベクトル差分値は、エンコーダからシグナルされてよい。エンコーダは、モーションベクトル差分値をエンコードし、モーションベクトル差分値を示す情報を生成し、シグナルすることができる。以下では、本発明の一実施例によってモーションベクトル差分値がシグナルされる方法について説明する。

【0090】

図９は、本発明の一実施例に係る現在ブロックのモーションベクトル差分値がシグナルされる方法を示す図である。一実施例によって、モーションベクトル差分値を示す情報は、モーションベクトル差分値の絶対値情報又はモーションベクトル差分値の符号情報のうち少なくとも一つを含むことができる。モーションベクトル差分値の絶対値と符号は、別個にエンコードされてよい。

【0091】

一実施例によって、モーションベクトル差分値の絶対値は、値自体でシグナルされてもよい。エンコーダは、モーションベクトル差分値の絶対値の特性を示す少なくとも一つのフラグを用いて、シグナルされる値のサイズを減らすことができる。デコーダは、シグナルされた値から、少なくとも一つのフラグを用いてモーションベクトル差分値の絶対値を誘導することができる。

【0092】

例えば、少なくとも一つのフラグは、モーションベクトル差分値の絶対値がＮよりも大きいか否かを示す第１フラグを含むことができる。このとき、Ｎは整数であってよい。モーションベクトル差分値の絶対値のサイズがＮよりも大きい場合、活性化された第１フラグと共に（モーションベクトル差分値の絶対値－Ｎ）値がシグナルされてよい。このとき、活性化されたフラグは、モーションベクトル差分値の絶対値のサイズがＮよりも大きい場合を示すことができる。デコーダは、活性化された第１フラグ及びシグナルされた値に基づいてモーションベクトル差分値の絶対値を取得することができる。

【0093】

図９を参照すると、モーションベクトル差分値の絶対値が‘０’よりも大きいかを示す第２フラグ（ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ０＿ｆｌａｇ）がシグナルされてよい。第２フラグ（ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ０＿ｆｌａｇ［］）が、モーションベクトル差分値の絶対値が‘０’よりも大きくことを示す場合、モーションベクトル差分値の絶対値は‘０’であってよい。また、第２フラグ（ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ０＿ｆｌａｇ）がモーションベクトル差分値の絶対値が‘０’よりも大きいことを示す場合、デコーダは、モーションベクトル差分値に対する他の情報を用いてモーションベクトル差分値の絶対値を取得することができる。

【0094】

一実施例によって、モーションベクトル差分値の絶対値が‘１’よりも大きいかを示す第３フラグ（ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ１＿ｆｌａｇ）がシグナルされてよい。第３フラグ（ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ１＿ｆｌａｇ）が、モーションベクトル差分値の絶対値が‘１’よりも大きくないことを示す場合、デコーダは、モーションベクトル差分値の絶対値が‘１’であると判断できる。

【0095】

逆に、第３フラグ（ａｂｓ＿ｍｖｄ＿ｇｒｅａｔｅｒ１＿ｆｌａｇ）が、モーションベクトル差分値の絶対値が‘１’よりも大きいことを示す場合、デコーダは、モーションベクトル差分値に関するさらに他の情報を用いてモーションベクトル差分値の絶対値を取得することができる。例えば、（モーションベクトル差分値の絶対値－２）値（ａｂｓ＿ｍｖｄ＿ｍｉｎｕｓ２）がシグナルされてよい。モーションベクトル差分値の絶対値が‘１’よりも大きい場合、モーションベクトル差分値の絶対値は２以上の値であり得るためである。

【0096】

前述したように、現在ブロックのモーションベクトル差分値の絶対値は、少なくとも一つのフラグに変形されてよい。例えば、モーションベクトル差分値の変形された絶対値は、モーションベクトル差分値のサイズによって（モーションベクトル差分値の絶対値－Ｎ）を示すことができる。一実施例によって、モーションベクトル差分値の変形された絶対値は、少なくとも一つのビットでシグナルされてよい。このとき、モーションベクトル差分値の変形された絶対値を示すためにシグナルされるビットの個数は、可変してよい。エンコーダは、モーションベクトル差分値の変形された絶対値を可変長二進化方法を用いてエンコードすることができる。例えば、エンコーダは、可変長二進化方法として、切断単項（ｔｒｕｎｃａｔｅｄ ｕｎａｒｙ）二進化、単項（ｕｎａｒｙ）二進化、切断ライス（ｔｒｕｎｃａｔｅｄ ｒｉｃｅ）又は指数ゴロム（ｅｘｐ－Ｇｏｌｏｍｂ）二進化のうち少なくとも一つを用いることができる。

【0097】

また、モーションベクトル差分値の符号は、符号フラグ（ｍｖｄ＿ｓｉｇｎ＿ｆｌａｇ）でシグナルされてよい。一方、モーションベクトル差分値の符号は、符号ビット隠し（ｓｉｇｎ－ｂｉｔ－ｈｉｄｉｎｇ）によって暗黙的にシグナルされてよい。

【0098】

一方、前述した現在ブロックのモーションベクトル差分値は、特定レゾリューション単位でシグナルされてよい。本開示において、モーションベクトル差分値のレゾリューションは、モーションベクトル差分値がシグナルされる単位を表すことができる。すなわち、本開示において、ピクチャーのレゾリューション以外のレゾリューションは、モーションベクトル差分値がシグナルされる精密度（ｐｒｅｃｉｓｉｏｎ）又は細密度（ｇｒａｎｕｌａｒｉｔｙ）を表すことができる。モーションベクトル差分値のレゾリューションは、サンプル又はピクセルの単位で表現されてよい。例えば、モーションベクトル差分値のレゾリューションは、１／４（ｑｕａｒｔｅｒ）、１／２（ｈａｌｆ）、１（ｉｎｔｅｇｅｒ）、２、４サンプル単位のように、サンプルの単位を用いて表現されてよい。また、現在ブロックのモーションベクトル差分値のレゾリューションが小さいほど、現在ブロックのモーションベクトル差分値の精密度は増加し得る。

【0099】

本発明の一実施例によれば、モーションベクトル差分値は、様々なレゾリューションに基づいてシグナルされてよい。一実施例によって、モーションベクトル差分値の絶対値又は変形された絶対値は、整数サンプル単位の値でシグナルされてよい。または、モーションベクトル差分値の絶対値は、１／２－サブペル単位の値でシグナルされてよい。すなわち、モーションベクトル差分値のレゾリューションは、状況によって異なるように設定されてよい。本発明の一実施例に係るエンコーダ及びデコーダは、モーションベクトル差分値のための様々なレゾリューションを適切に用いて、現在ブロックのモーションベクトル差分値を効率的にシグナルすることができる。

【0100】

一実施例によって、モーションベクトル差分値のレゾリューションは、ブロック、コーディングユニット、スライス又はタイルのうち少なくとも一つの単位ごとに異なる値に設定されてよい。例えば、第１ブロックのモーションベクトル差分値の第１レゾリューションは、１／４サンプル単位であってよい。この場合、モーションベクトル差分値の絶対値‘１６’を第１レゾリューションで割った値である‘６４’がシグナルされてよい。また、第２ブロックのモーションベクトル差分値の第２レゾリューションは、整数サンプル単位であってよい。この場合、第２モーションベクトル差分値の絶対値‘１６’を第２レゾリューションで割った値である‘１６’がシグナルされてよい。このように、モーションベクトル差分値の絶対値が同一である場合にも、レゾリューションによって異なる値がシグナルされてよい。このとき、モーションベクトル差分値の絶対値をレゾリューションで割った値が少数点以下の桁数を含む場合、当該値にラウンディング関数が適用されてよい。

【0101】

エンコーダは、モーションベクトル差分値のレゾリューションに基づき、モーションベクトル差分値を示す情報をシグナルすることができる。デコーダは、シグナルされたモーションベクトル差分値から、修正されたモーションベクトル差分値を取得することができる。デコーダは、レゾリューション差分値のレゾリューションに基づいてモーションベクトル差分値を修正することができる。現在ブロックのシグナルされたモーションベクトル差分値（ｖａｌｕｅＰｅｒＲｅｓｏｌｕｔｉｏｎ）と修正されたモーションベクトル差分値（ｖａｌｕｅＤｅｔｅｒｍｉｎｅｄ）間の関係は、下記の式１の通りである。以下、本開示において、特に言及がない限り、モーションベクトル差分値は、修正されたモーションベクトル差分値（ｖａｌｕｅＤｅｔｅｒｍｉｎｅｄ）を表す。また、シグナルされたモーションベクトル差分値は、レゾリューションによって修正される前の値を表す。

【0102】

【数1】

【0103】

式１で、レゾリューション（ｒｅｓｏｌｕｔｉｏｎ）は、現在ブロックのモーションベクトル差分値のレゾリューションを表す。すなわち、デコーダは、現在ブロックのシグナルされたモーションベクトル差分値とレゾリューションを掛けて、修正されたモーションベクトル差分値を取得することができる。次に、デコーダは、修正されたモーションベクトル差分値に基づいて現在ブロックのモーションベクトルを取得することができる。また、デコーダは、現在ブロックのモーションベクトルに基づいて現在ブロックを復元することができる。

【0104】

現在ブロックのモーションベクトル差分値のレゾリューションとして、相対的に小さい値が使用される場合（すなわち、精密度が高い場合）、現在ブロックのモーションベクトル差分値をより細密に示し易くなる。しかし、この場合、シグナルされる値自体が大きくなり、現在ブロックのモーションベクトル差分値のためのシグナリングオーバーヘッドが増加することがある。逆に、現在ブロックのモーションベクトル差分値のレゾリューションとして、相対的に大きい値が使用される場合（すなわち、精密度が低い場合）、シグナルされる値のサイズを減らし、モーションベクトル差分値のためのシグナリングオーバーヘッドを減少させることができる。すなわち、モーションベクトル差分値のレゾリューションが大きい場合、現在ブロックのモーションベクトル差分値は、現在ブロックのモーションベクトル差分値のレゾリューションが小さい場合に比べて、少ない個数のビットでシグナルされてよい。しかし、この場合、現在ブロックのモーションベクトル差分値を細密に示すことが困難であり得る。

【0105】

これにより、エンコーダ及びデコーダは、複数のレゾリューションから、状況に応じて、モーションベクトル差分値をシグナルするために有利なレゾリューションを選択することができる。例えば、エンコーダは、状況に基づいて選択されたレゾリューションをシグナルすることができる。また、デコーダは、シグナルされたレゾリューションに基づいて現在ブロックのモーションベクトル差分値を取得することができる。以下では、本発明の一実施例によって現在ブロックのモーションベクトル差分値のレゾリューションがシグナルされる方法について説明する。本発明の一実施例によって、現在ブロックのモーションベクトル差分値のレゾリューションは、レゾリューションセットが含む複数の可用レゾリューションのいずれか一つであってよい。ここで、複数の可用レゾリューションは、特定状況で使用可能なレゾリューションを表すことができる。また、レゾリューションセットが含む可用レゾリューションの種類及び個数は、状況によって変わってよい。

【0106】

図１０は、本発明の一実施例に係るコーディングユニット及び変換ユニットを示す図である。

【0107】

図１０（ａ）は、本発明の一実施例に係るコーディングユニットを示す図であり、図１０（ｂ）は、本発明の一実施例に係る変換ユニットを示す図である。

【0108】

本発明の一実施例をよれば、変換（ｔｒａｎｓｆｏｒｍ）が行われるブロック（ｂｌｏｃｋ）単位が存在してよい。例えば、変換が行われるブロック単位は、コーディングユニット（ｃｏｄｉｎｇ ｕｎｉｔ，ＣＵ）と同一であるか小さくてよく、又は予測（ｐｒｅｄｉｃｔｉｏｎ）を行うブロック単位と同一であるか小さくてよい。また、変換が行われるブロック単位のサイズは、最大変換サイズ（ｍａｘｉｍｕｍ ｔｒａｎｓｆｏｒｍ ｓｉｚｅ）によって制限されてよい。例えば、変換が行われるブロック単位の幅（ｗｉｄｔｈ）又は高さ（ｈｅｉｇｈｔ）は、最大変換サイズによって制限されてよい。具体的に、変換が行われるブロック単位の幅又は高さは、最大変換サイズ以下であってよい。また、前記最大変換サイズは、変換ブロックの色差成分、すなわち、ルーマ成分、クロマ成分によって異なってよい。このとき、変換が行われるブロック単位は、変換ユニット（ｔｒａｎｓｆｏｒｍ ｕｎｉｔ，ＴＵ）と表現されてよい。仮にコーディングユニット又は予測ユニット（ｐｒｅｄｉｃｔｉｏｎ ｕｎｉｔ，ＰＵ）が最大変換サイズよりも大きい場合、コーディングユニット又は予測ユニットが分割され、複数の変換ユニットが生成されてよい。複数の変換ユニットのうち最大変換サイズよりも大きい変換ユニットは分割されてよく、複数の変換ユニットが生成されてよい。このような過程で生成された複数の変換ユニットのサイズはいずれも、最大変換サイズ以下であってよい。本発明において、ユニット（ブロック）のサイズが最大変換サイズよりも大きいということは、ユニット（ブロック）の幅又は高さが最大変換サイズよりも大きいことを意味できる。一方、ユニット（ブロック）のサイズが最大変換サイズ以下であるということは、ユニット（ブロック）の幅及び高さがいずれも最大変換サイズ以下であることを意味できる。本発明の一実施例をよれば、変換ユニットを最大変換サイズに基づいて分割する動作は、イントラ予測（ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）が行われる時、残差信号（ｒｅｓｉｄｕａｌ ｓｉｇｎａｌ）をプロセシング（ｐｒｏｃｅｓｓｉｎｇ）する時などの状況で行われてよい。変換ユニットを最大変換サイズに基づいて分割する動作は、回帰的（ｒｅｃｕｒｓｉｖｅ）に行われてよく、変換ユニットのサイズが最大変換サイズ以下になるまで行われてよい。

【0109】

図１０（ａ）を参照すると、コーディングユニットの幅、高さはそれぞれ、ｃｂＷｉｄｔｈ、ｃｂＨｅｉｇｈｔと表現されてよい。図１０（ｂ）を参照すると、変換ユニットの幅、高さはそれぞれ、ｔｂＷｉｄｔｈ、ｔｂＨｅｉｇｈｔと表現されてよい。最大変換サイズは、ＭａｘＴｂＳｉｚｅＹと表現されてよい。具体的に、ＭａｘＴｂＳｉｚｅＹは、ルーマ（ｌｕｍａ）成分に対する最大変換サイズであってよい。変換ユニットのサイズが最大変換サイズよりも大きいため変換ユニットが分割されなければならない場合、分割される前の変換ユニットのｔｂＷｉｄｔｈ、ｔｂＨｅｉｇｈｔはそれぞれ、ｃｂＷｉｄｔｈ、ｃｂＨｅｉｇｈｔになり得る。すなわち、最大変換サイズよりも変換ユニットの幅又は高さが大きいか否かによって変換ユニットは分割されてよく、ｔｂＷｉｄｔｈ又はｔｂＨｅｉｇｈｔはアップデートされてよい。例えば、図１０（ａ）を参照すると、ｃｂＷｉｄｔｈは、ＭａｘＴｂＳｉｚｅＹよりも大きい。この場合、変換ユニットは分割されてよいが、変換ユニットが分割される前の変換ユニットのｔｂＷｉｄｔｈ、ｔｂＨｅｉｇｈｔはそれぞれ、ｃｂＷｉｄｔｈ、ｃｂＨｅｉｇｈｔになり得る。図１０（ｂ）を参照すると、ｔｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹよりも大きいため、ＴＵはｔｒａｎｓｆｏｒｍ ｕｎｉｔ １、ｔｒａｎｓｆｏｒｍ ｕｎｉｔ ２に分割されてよい。このとき、新しい変換ユニットの幅（分割後の変換ユニットの幅）であるｎｅｗＴｂＷｉｄｔｈは、ｔｂＷｉｄｔｈ／２になり得る。

【0110】

本明細書で説明する変換ユニット（ｔｒａｎｓｆｏｒｍ ｕｎｉｔ，ＴＵ）分割は、ＴＵに含まれる変換ブロック（ｔｒａｎｓｆｏｒｍ ｂｌｏｃｋ，ＴＢ）の分割を意味できる。

【0111】

本明細書ではユニットとブロックを同じ意味で使用する。また、ユニットは、色差成分による一つ以上のブロックを含む概念であってよい。例えば、ユニットは、ルーマに対するブロックとクロマに対する一つ以上のブロックを含む概念であってよい。

【0112】

図１１は、本発明の一実施例に係る変換ツリーシンタックスを示す図である。

【0113】

図１１のシンタックスは、図１０を参照して説明したＴＵの分割を行うためのシンタックスであってよい。

【0114】

図１１に示す変換ツリーシンタックス（ｔｒａｎｓｆｏｒｍ ｔｒｅｅ ｓｙｎｔａｘ）は、コーディングユニットシンタックス（ｃｏｄｉｎｇ ｕｎｉｔ ｓｙｎｔａｘ）又は予測ユニットシンタックス（ｐｒｅｄｉｃｔｉｏｎ ｕｎｉｔ ｓｙｎｔａｘ）から呼び出されてよい。このとき、変換ツリーシンタックスの入力（ｉｎｐｕｔ）値であるｔｂＷｉｄｔｈ、ｔｂＨｅｉｇｈｔは、図１０で説明したｃｂＷｉｄｔｈ、ｃｂＨｅｉｇｈｔであってよい。そして、デコーダは、ｔｂＷｉｄｔｈが最大変換サイズ（ＭａｘＴｂＳｉｚｅＹ）よりも大きいか否か、又はｔｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹよりも大きいか否かを確認することができる。確認の結果、ｔｂｗｉｄｔｈ又はｔｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹよりも大きい場合、ＴＵ分割がなされてよく、変換ツリーシンタックスは再び呼び出されてよい。そうでない場合には、変換ユニットシンタックスが呼び出されてよい。このとき、変換ツリーシンタックスが再び呼び出される場合、入力値はアップデートされてよい。例えば、ｔｂＷｉｄｔｈ又はｔｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹよりも大きい場合、入力値はｔｂＷｉｄｔｈ／２又はｔｂＨｅｉｇｈｔ／２にアップデートされてよい。図１１で、アップデートされたｔｂＷｉｄｔｈ、ｔｂＨｅｉｇｈｔは、ｔｒａｆｏＷｉｄｔｈ、ｔｒａｆｏＨｅｉｇｈｔと表現されてよい。また、シンタックス要素ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（ｘ０，ｙ０，ｔｂＷｉｄｔｈ，ｔｂＨｅｉｇｈｔ，ｔｒｅｅＴｙｐｅ）においてｘ０、ｙ０は、変換ツリーシンタックスが適用されるブロックの位置を示す水平、垂直座標値であってよい。デコーダは、ｔｒａｆｏＷｉｄｔｈ、ｔｒａｆｏＨｅｉｇｈｔの値を用いてシンタックス要素ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（ｘ０，ｙ０，ｔｒａｆｏＷｉｄｔｈ，ｔｒａｆｏＨｅｉｇｈｔ，ｔｒｅｅＴｙｐｅ）をパースすることができる。ｔｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹよりも大きい場合、デコーダは、シンタックス要素ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（ｘ０＋ｔｒａｆｏＷｉｄｔｈ，ｙ０，ｔｒａｆｏＷｉｄｔｈ，ｔｒａｆｏＨｅｉｇｈｔ，ｔｒｅｅＴｙｐｅ）をパースすることができる。ｔｂｈｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹよりも大きい場合、デコーダは、シンタックス要素ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（ｘ０，ｙ０＋ｔｒａｆｏＨｅｉｇｈｔ，ｔｒａｆｏＷｉｄｔｈ，ｔｒａｆｏＨｅｉｇｈｔ，ｔｒｅｅＴｙｐｅ）をパースすることができる。ｔｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹより大きく、ｔｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹよりも大きい場合、デコーダは、シンタックス要素ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（ｘ０＋ｔｒａｆｏＷｉｄｔｈ，ｙ０＋ｔｒａｆｏＨｅｉｇｈｔ，ｔｒａｆｏＷｉｄｔｈ，ｔｒａｆｏＨｅｉｇｈｔ，ｔｒｅｅＴｙｐｅ）をパースすることができる。このとき、変換ツリーシンタックス‘ｔｒａｎｆｏｒｍ＿ｔｒｅｅ（）’が複数回呼び出される過程の順序は、エンコーダ、デコーダマッチ又は又はコーディング性能の側面で重要であり得る。このとき、順序は、既に設定された順序に従うことができ、既に設定された順序は、図１１に開示されたシンタックスによる順序であってよい。

【0115】

また、図１１の変換ツリーシンタックスがコーディングユニット又は予測ユニットで初めて呼び出される場合、ｔｂＷｉｄｔｈ、ｔｂＨｅｉｇｈｔ、ｘ０、ｙ０は、ルーマ成分を基準に設定された値であってよい。例えば、ルーマブロックのサイズが１６×１６であるとき、クロマフォーマット（ｃｈｒｏｍａ ｆｏｒｍａｔ）によるクロマブロックのサイズは、８×８であってよい。このとき、デコーダが前記クロマブロックに対する変換ツリーシンタックスをパースしても、ｔｂＷｉｄｔｈ、ｔｂＨｅｉｇｈｔ値はそれぞれ１６、１６であってよい。

【0116】

また、図１１の変換ツリーシンタックスは、ツリー類型（ｔｒｅｅＴｙｐｅ）値に関係なくパースされてよい。ツリー類型は、ルーマ成分のブロック構造とクロマ成分のブロック構造が同一か異なるかを示す。例えば、ツリー類型がＳＩＮＧＬＥ＿ＴＲＥＥである場合、ルーマ成分のブロック構造とクロマ成分のブロック構造は同一であってよい。一方、ツリー類型がＳＩＮＧＬＥ＿ＴＲＥＥでない場合、ルーマ成分のブロック構造とクロマ成分のブロック構造は互いに異なってよい。ツリー類型がＤＵＡＬ＿ＴＲＥＥ＿ＬＵＭＡである場合、ルーマ成分のブロック構造とクロマ成分のブロック構造は互いに異なってよく、このとき、ツリー類型はルーマ成分に対するツリーであるか、ルーマ成分に対する変換ツリーシンタックスがパースされることを示すことができる。一方、ツリー類型がＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡである場合、ルーマ成分のブロック構造とクロマ成分のブロック構造が互いに異なってよく、このとき、ツリー類型は、クロマ成分に対するツリーであるか、クロマ成分に対する変換ツリーシンタックスがパースされることを示すことができる。

【0117】

図１２は、本発明の一実施例に係るイントラブロックにおけるデコーディングプロセスを示す図である。

【0118】

図１２は、変換ユニット分割に対する説明及びイントラ予測過程を示す図である。

【0119】

本明細書の図面を参照して説明される実施例において、使われる用語を定義する。

【0120】

（ｘＴｂ０，ｙＴｂ０）：現在変換ブロックの左上端サンプル位置の座標

【0121】

ｎＴｂＷ：現在変換ブロックの幅

【0122】

ｎＴｂＨ：現在変換ブロックの高さ

【0123】

図１２に開示された８．４．１節では、コーディングユニットのルーマブロックのデコーディングプロセスとクロマブロックのデコーディングプロセスを示す。クロマブロックのデコーディングプロセスは、ＣｂブロックのデコーディングプロセスとＣｒブロックのデコーディングプロセスを含むことができる。図１２の８．４．１節を参照すると、ルーマブロックのデコーディングプロセスとクロマブロックのデコーディングプロセスには、互いに異なる入力（ｉｎｐｕｔ）が利用されてよく、デコーダは、互いに異なる入力を用いて、図１２の８．４．５．１節に開示された動作を行うことができる。

【0124】

図１２の８．４．１節に開示されたｃｂＷｉｄｔｈ及びｃｂＨｅｉｇｈｔは、現在コーディングブロックの幅及び高さを意味するものでよく、ｃｂＷｉｄｔｈ及びｃｂＨｅｉｇｈｔ値は、ルーマサンプルを基準にした値であってよい。例えば、ルーマブロックサイズが１６×１６であれば、クロマフォーマットによってクロマブロックサイズは８×８であってよい。このとき、クロマコーディングブロックに対するｃｂＷｉｄｔｈ及びｃｂＨｅｉｇｈｔ値はそれぞれ、１６、１６であってよい。また、図１２に開示された（ｘＣｂ，ｙＣｂ）は、現在コーディングブロックの座標を示すものでよく、現在コーディングブロックの左上端（ｔｏｐ－ｌｅｆｔ）サンプルの座標値であってよい。このとき、座標値は、現在ピクチャーの左上端サンプルの座標を基準にして設定されてよい。また、（ｘＣｂ，ｙＣｂ）は、ルーマサンプルを基準にして示した値であってよい。

【0125】

図１２の８．４．１節を参照すると、ツリー類型（ｔｒｅｅＴｙｐｅ）がＳＩＮＧＬＥ＿ＴＲＥＥであるか、ＤＵＡＬ＿ＴＲＥＥ＿ＬＵＭＡである場合、デコーダは、ルーマブロックに対するデコーディングプロセスを行うことができる。このとき、図１２に開示された８．４．５．１節がインボーク（ｉｎｖｏｋｅ）されてよく、その時のサンプルロケーション入力（ｓａｍｐｌｅ ｌｏｃａｔｉｏｎ ｉｎｐｕｔ）は、（ｘＣｂ，ｙＣｂ）であり、ブロックの幅と高さはそれぞれ、ｃｂＷｉｄｔｈとｃｂＨｅｉｇｈｔであってよい。また、カラー成分（ｃｏｌｏｒ ｃｏｍｐｏｎｅｎｔ）を示すｃＩｄｘの値は、０であってよい。

【0126】

ツリー類型（ｔｒｅｅＴｙｐｅ）がＳＩＮＧＬＥ＿ＴＲＥＥであるか、ＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡである場合、デコーダは、クロマブロックに対するデコーディングプロセスを行うことができる。このとき、図１２に開示された８．４．５．１がインボーク（ｉｎｖｏｋｅ）されてよく、Ｃｂブロック、Ｃｒブロックのそれぞれに対してインボーク（ｉｎｖｏｋｅ）されてよい。このとき、サンプルロケーション入力（ｓａｍｐｌｅ ｌｏｃａｔｉｏｎ ｉｎｐｕｔ）は、（ｘＣｂ／ＳｕｂＷｉｄｔｈＣ，ｙＣｂ／ＳｕｂＨｅｉｇｈｔＣ）であり、ブロックの幅と高さはそれぞれ、ｃｂＷｉｄｔｈ／ＳｕｂＷｉｄｔｈＣとｃｂＨｅｉｇｈｔ／ＳｕｂＨｅｉｇｈｔＣであってよい。このとき、ｃＩｄｘの値は０でなくてよく、ｃＩｄｘ値は、Ｃｂブロックに対しては１、Ｃｒブロックに対しては２に設定されてよい。ＳｕｂＷｉｄｔｈＣとＳｕｂＨｅｉｇｈｔＣは、クロマフォーマットに基づいて既に設定される値であってよい。ＳｕｂＷｉｄｔｈＣとＳｕｂＨｅｉｇｈｔＣ値は１又は２でよく、ルーマ成分とクロマ成分の関係に対する値であってよい。ＳｕｂＷｉｄｔｈＣとＳｕｂＨｅｉｇｈｔＣについては、図１４及び図１５を参照して後述する。

【0127】

デコーダが、図１２の８．４．５．１節に開示されたデコーディングプロセスを行うとき、入力（ｉｎｐｕｔ）はルーマブロック、クロマブロックに対応するように変換された状態であってよい。例えば、図１２の８．４．５．１節に開示されたブロックの幅（ｎＴｂＷ）、ブロックの高さ（ｎＴｂＨ）、サンプルロケーションの座標（ｘＴｂ０，ｙＴｂ０）は、クロマブロックに対するデコーディングプロセスが行われる際には、クロマサンプル数に基づいて決定されてよく、ルーマブロックに対するデコーディングプロセスが行われる際には、ルーマサンプル数に基づいて決定されてよい。

【0128】

図１２の８．４．５．１節を用いて上述のＴＵ分割が行われてよい。図１２に開示されたｍａｘＴｂＷｉｄｔｈ、ｍａｘＴｂＨｅｉｇｈｔは、カラー（ｃｏｌｏｒ）成分に該当する最大変換サイズ（ｍａｘｉｍｕｍ ｔｒａｎｓｆｏｒｍ ｓｉｚｅ）を示す値であり、それぞれ幅、高さに該当する値であってよい。上述したように、ＭａｘＴｂＳｉｚｅＹは、ルーマブロックに対する最大変換サイズであってよい。したがって、クロマブロック（すなわち、ｃＩｄｘが０でない場合）に対してｍａｘＴｂＷｉｄｔｈは、ＭａｘＴｂＳｉｚｅＹ／ＳｕｂＷｉｄｔｈＣでよく、ｍａｘＴｂＨｅｉｇｈｔは、ＭａｘＴｂＳｉｚｅＹ／ＳｕｂＨｅｉｇｈｔＣでよい。ルーマブロック対してｍａｘＴｂＷｉｄｔｈ、ｍａｘＴｂＨｅｉｇｈｔはいずれもＭａｘＴｂＳｉｚｅＹであってよい。

【0129】

また、図１２の８－４３を参照すると、座標（（ｘＴｂＹ，ｙＴｂＹ））は、ルーマ基準で変換されてよく、このとき、前記座標は、ｃＩｄｘとＳｕｂＷｉｄｔｈＣ、ＳｕｂＨｅｉｇｈｔＣに基づいて計算されてよい。

【0130】

図１２で説明したデコーディングプロセスはシンタックス構造と一致しなければならない。すなわち、図１２のデコーディングプロセスは、図１１のシンタックス構造と一致しなければならない。

【0131】

図１２の８．４．５．１節においてｎＴｂＷがｍａｘＴｂＷｉｄｔｈよりも大きいか、ｎＴｂＨがｍａｘＴｂＨｅｉｇｈｔよりも大きい場合、図１２の８．４．５．１に開示された過程１～５が行われてよい。図１２の過程１を参照すると、ブロックの幅（ｎＴｂＷ）及び高さ（ｎＴｂＨ）は、ｎｅｗＴｂＷ、ｎｅｗＴｂＨにアップデートされてよい。具体的に、ｎＴｂＷがｍａｘＴｂＷｉｄｔｈよりも大きいと、ブロックの幅はｎＴｂＷ／２にアップデートされ、そうでないと、ブロックの幅は相変わらずｎＴｂＷである。ｎＴｂＨがｍａｘＴｂＨｅｉｇｈｔよりも大きいと、ブロックの高さはｎＴｂＨ／２にアップデートされ、そうでないと、ブロックの高さは相変わらずｎＴｂＨである。図１２の過程２を参照すると、座標（ｘＴｂ０，ｙＴｂ０）、ｎｅｗＴｂＷ、ｎｅｗＴｂＨを入力として図１２の８．４．５．１節が再びインボーク（ｉｎｖｏｋｅ）されてよい。図１２の過程３を参照すると、ｎＴｂＷがｍａｘＴｂＷｉｄｔｈよりも大きいと、座標（ｘＴｂ０＋ｎｅｗＴｂＷ，ｙＴｂ０）、ｎｅｗＴｂＷ、ｎｅｗＴｂＨを入力として図１２の８．４．５．１節が再びインボーク（ｉｎｖｏｋｅ）されてよい。図１２の過程４を参照すると、ｎＴｂＨがｍａｘＴｂＨｅｉｇｈｔよりも大きいと、座標（ｘＴｂ０，ｙＴｂ０＋ｎｅｗＴｂＨ）、ｎｅｗＴｂＷ、ｎｅｗＴｂＨを入力として図１２の８．４．５．１節が再びインボーク（ｉｎｖｏｋｅ）されてよい。図１２の過程５を参照すると、ｎＴｂＷがｍａｘＴｂＷｉｄｔｈより大きく、ｎＴｂＨがｍａｘＴｂＨｅｉｇｈｔよりも大きいと、座標（ｘＴｂ０＋ｎｅｗＴｂＷ，ｙＴｂ０＋ｎｅｗＴｂＨ）、ｎｅｗＴｂＷ、ｎｅｗＴｂＨを入力として図１２の８．４．５．１節が再びインボーク（ｉｎｖｏｋｅ）されてよい。図１２の過程２～５は、図１１で変換ツリーシンタックスをまた呼び出す過程と同一であってよい。

【0132】

一方、ｎＴｂＷがｍａｘＴｂＷｉｄｔｈ以下であり、ｎＴｂＨがｍａｘＴｂＨｅｉｇｈｔ以下であれば、図１２の過程１～５以外のプロセスが行われてよい。このとき、図１２の過程１～５以外のプロセスは、実際イントラ予測とレジデュアル信号デコーディング（ｒｅｓｉｄｕａｌ ｓｉｇｎａｌ ｄｅｃｏｄｉｎｇ）、変換（ｔｒａｎｓｆｏｒｍ）、復元（ｒｅｃｏｎｓｔｒｕｃｔｉｏｎ）などに関連したプロセスであってよい。

【0133】

図１３は、本発明の一実施例に係るレジデュアル信号のデコーディングプロセスを示す図である。

【0134】

図１３に開示された内容のうち、上述した内容と重複する内容は省略するものとする。

【0135】

図１３に開示されたデコーディングプロセスは、インター予測、ＩＢＣ（ｉｎｔｒａ ｂｌｏｃｋ ｃｏｐｙ）予測などが適用される場合に行われてよい。また、図１３は、上述したＴＵ分割について開示できる。

【0136】

図１３のＳ１３０１を参照すると、図１３の８．５．８節をインボーク（ｉｎｖｏｋｅ）する過程は、カラー（ｃｏｌｏｒ）成分別に行われてよい。このとき、図１２を参照して説明した通り、各カラー成分に該当する入力（ｉｎｐｕｔ）を用いて図１３の８．５．８節のデコーディングプロセスが行われてよい。図１３の８．５．８節のデコーディングプロセスの入力であるサンプルロケーションの座標（ｘＴｂ０，ｙＴｂ０）、ブロックの幅（ｎＴｂＷ）、ブロックの高さ（ｎＴｂＨ）は、ルーマブロックに対しては（ｘＣｂ，ｙＣｂ）、ｃｂＷｉｄｔｈ、ｃｂＨｅｉｇｈｔであってよく、クロマブロックに対しては（ｘＣｂ／ＳｕｂＷｉｄｔｈＣ，ｙＣｂ／ＳｕｂＨｅｉｇｈｔＣ）、ｃｂＷｉｄｔｈ／ＳｕｂＷｉｄｔｈＣ、ｃｂＨｅｉｇｈｔ／ＳｕｂＨｅｉｇｈｔＣであってよい。また、カラー（ｃｏｌｏｒ）成分を示すｃＩｄｘ値は、ブロックがルーマ成分である場合、０に設定され、ブロックがクロマ成分である場合、０以外の値に設定されてよい。例えば、ブロックがＣｂ成分である場合にｃＩｄｘ値は１、ブロックがＣｒ成分である場合にｃＩｄｘ値は２に設定されてよい。

【0137】

図１３の８．５．８節のデコーディングプロセスが行われるとき、（ｘＴｂ０，ｙＴｂ０）、ｎＴｂＷ、ｎＴｂＨは、各カラー（ｃｏｌｏｒ）成分に該当する値であってよい。すなわち、各カラー（ｃｏｌｏｒ）成分のサンプル数に該当する値であってよい。

【0138】

図１３の８－８４９、８－８５０を参照すると、各カラー（ｃｏｌｏｒ）成分に合わせて最大変換サイズ（ｍａｘｉｍｕｍ ｔｒａｎｓｆｏｒｍ ｓｉｚｅ）が計算されてよい。また、図１３の８－８５２、８－８５３を参照すると、ｎＴｂＷ又はｎＴｂＨが最大変換サイズよりも大きいか否かに基づいてブロックの幅又はブロックの高さはアップデートされ、ｎｅｗＴｂＷ、ｎｅｗＴｂＨと記述されてよい。図１３の８．５．８節の過程２～５では、８．５．８節を再びインボークする過程を開示しているが、これは、図１２を参照して上述した内容と同一であってよい。

【0139】

一方、ｎＴｂＷがｍａｘＴｂＷｉｄｔｈ以下であり、ｎＴｂＨ ｍａｘＴｂＨｅｉｇｈｔ以下であれば、図１３の過程１～５以外のプロセスが行われてよい。このとき、図１３の過程１～５以外のプロセスは、実際のレジデュアル信号デコーディング（ｒｅｓｉｄｕａｌ ｓｉｇｎａｌ ｄｅｃｏｄｉｎｇ）、変換（ｔｒａｎｓｆｏｒｍ）などに関連したプロセスであってよい。

【0140】

図１４は、本発明の一実施例に係るカラー成分の関係を示す図である。

【0141】

図１４を参照すると、カラー成分に関係した要素として、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃ、Ｃｈｒｏｍａ ｆｏｒｍａｔ、ｓｅｐａｒａｔｅ＿ｃｏｌｏｕｒ＿ｐｌａｎｅ＿ｆｌａｇなどがあり得る。

【0142】

例えば、クロマフォーマット（Ｃｈｒｏｍａ ｆｏｒｍａｔ）がＭｏｎｏｃｈｒｏｍｅである場合、１個のサンプルアレイ（ｓａｍｐｌｅ ａｒｒａｙ）だけ存在してよく、ＳｕｂＷｉｄｔｈＣ、ＳｕｂＨｅｉｇｈｔＣがいずれも１であってよい。クロマフォーマットが４：２：０サンプリングである場合、クロマアレイ（ｃｈｒｏｍａ ａｒｒａｙ）は２個存在してよい。このとき、クロマアレイは、ルーマアレイ（ｌｕｍａ ａｒｒａｙ）の半分の幅（ｈａｌｆ ｗｉｄｔｈ）、半分の高さ（ｈａｌｆ ｈｅｉｇｈｔ）を有することができ、ＳｕｂＷｉｄｔｈＣ、ＳｕｂＨｅｉｇｈｔＣはいずれも２であってよい。クロマフォーマットが４：２：２サンプリングである場合、クロマアレイは２個存在してよい。このとき、クロマアレイは、ルーマアレイの半分の幅、ルーマアレイと同じ高さを有してよく、ＳｕｂＷｉｄｔｈＣ、ＳｕｂＨｅｉｇｈｔＣはそれぞれ、２、１であってよい。クロマフォーマットが４：４：４サンプリングである場合、クロマアレイは２個存在してよい。このとき、クロマアレイは、ルーマアレイと同じ幅、同じ高さを有してよく、ＳｕｂＷｉｄｔｈＣ、ＳｕｂＨｅｉｇｈｔＣはいずれも１であってよい。

【0143】

一方、クロマフォーマットが４：４：４サンプリングである場合、ｓｅｐａｒａｔｅ＿ｃｏｌｏｕｒ＿ｐｌａｎｅ＿ｆｌａｇに基づいて行われるプロセスが互いに異なってよい。ｓｅｐａｒａｔｅ＿ｃｏｌｏｕｒ＿ｐｌａｎｅ＿ｆｌａｇが０である場合、クロマアレイは、ルーマアレイと同じ幅、同じ高さを有してよい。ｓｅｐａｒａｔｅ＿ｃｏｌｏｕｒ＿ｐｌａｎｅ＿ｆｌａｇが１である場合、３個のカラー平面（ｃｏｌｏｒ ｐｌａｎｅ）、すなわち、ルーマ、Ｃｂ、Ｃｒに対するプロセスはそれぞれ行われてよい。ｓｅｐａｒａｔｅ＿ｃｏｌｏｕｒ＿ｐｌａｎｅ＿ｆｌａｇが１である場合、一つのスライスには一つのカラー（ｃｏｌｏｒ）成分だけ存在してよい。一方、ｓｅｐａｒａｔｅ＿ｃｏｌｏｕｒ＿ｐｌａｎｅ＿ｆｌａｇが０である場合、一つのスライスには複数のカラー成分が存在してよい。図１４に示すように、クロマフォーマットが４：４：４サンプリングである場合、ｓｅｐａｒａｔｅ＿ｃｏｌｏｕｒ＿ｐｌａｎｅ＿ｆｌａｇに関係なくＳｕｂＷｉｄｔｈＣ、ＳｕｂＨｅｉｇｈｔＣはいずれも１であってよい。

【0144】

ＳｕｂＷｉｄｔｈＣとＳｕｂＨｅｉｇｈｔＣは、クロマアレイがルーマアレイに対していかなるサイズを有するかを示すことができ、クロマアレイ幅又はクロマアレイ高さがルーマアレイの半分である場合、ＳｕｂＷｉｄｔｈＣ又はＳｕｂＨｅｉｇｈｔＣは２であり、クロマアレイ幅又は高さがルーマアレイと同じサイズである場合、ＳｕｂＷｉｄｔｈＣ又はＳｕｂＨｅｉｇｈｔＣは１であってよい。

【0145】

図１４を参照すると、クロマフォーマットが４：２：２サンプリングである場合にのみ、ＳｕｂＷｉｄｔｈＣ、ＳｕｂＨｅｉｇｈｔＣは互いに異なる値を有してよい。したがって、クロマフォーマットが４：２：２サンプリングである場合、ルーマ成分を基準にした幅対高さの関係は、クロマ成分を基準にした幅対高さの関係と異なってよい。

【0146】

図１５は、本発明の一実施例に係るカラー成分の関係を示す図である。

【0147】

図１５（ａ）は、クロマフォーマットが４：２：０サンプリングである場合、図１５（ｂ）は、クロマフォーマットが４：２：２サンプリングである場合、図１５（ｃ）は、クロマフォーマットが４：４：４サンプリングである場合、を示す。

【0148】

図１５（ａ）を参照すると、クロマフォーマットが４：２：０サンプリングである場合、水平（ｈｏｒｉｚｏｎｔａｌ）方向においてルーマサンプル２個当りにクロマサンプルは１個（Ｃｂ１個、Ｃｒ１個）ずつ位置してよい。また、垂直（ｖｅｒｔｉｃａｌ）方向においてルーマサンプル２個当りにクロマサンプルは１個（Ｃｂ１個、Ｃｒ１個）ずつ位置してよい。

【0149】

図１５（ｂ）を参照すると、クロマフォーマットが４：２：２サンプリングである場合、水平（ｈｏｒｉｚｏｎｔａｌ）方向においてルーマサンプル２個当りにクロマサンプルは１個（Ｃｂ１個、Ｃｒ１個）ずつ位置してよい。また、垂直（ｖｅｒｔｉｃａｌ）方向においてルーマサンプル１個当りにクロマサンプルは１個（Ｃｂ１個、Ｃｒ１個）ずつ位置してよい。

【0150】

図１５（ｃ）を参照すると、クロマフォーマットが４：４：４サンプリングである場合、水平（ｈｏｒｉｚｏｎｔａｌ）方向においてルーマサンプル１個当りにクロマサンプルは１個（Ｃｂ１個、Ｃｒ１個）ずつ位置してよい。また、垂直（ｖｅｒｔｉｃａｌ）方向においてルーマサンプル１個当りにクロマサンプルは１個（Ｃｂ１個、Ｃｒ１個）ずつ位置してよい。

【0151】

図１５に示したルーマサンプルとクロマサンプルの関係によって、上述したＳｕｂＷｉｄｔｈＣ、ＳｕｂＨｅｉｇｈｔＣが決定されてよく、ＳｕｂＷｉｄｔｈＣ、ＳｕｂＨｅｉｇｈｔＣに基づき、ルーマサンプルを基準にした変換、クロマサンプルを基準にした変換が行われてよい。

【0152】

図１６は、本発明の一実施例に係る最大変換サイズを示す図である。

【0153】

最大変換サイズ（ｍａｘｉｍｕｍ ｔｒａｎｓｆｏｒｍ ｓｉｚｅ）は可変してよいが、エンコーダ又はデコーダの複雑度は、最大変換サイズを変更することによって調節されてよい。例えば、最大変換サイズが小さい場合、エンコーダ又はデコーダの複雑度は減り得る。

【0154】

本発明の一実施例として、最大変換サイズになり得る値は制限されてよい。例えば、最大変換サイズは、２個の値のいずれか一つに制限されてよい。このとき、２個の値は、３２、６４でよく、ルーマ基準のサイズであってよい。

【0155】

最大変換サイズは、上位レベルでシグナルされてよい。このとき、上位レベルとは、現在ブロックを含むレベルであってよい。例えば、シーケンス、シーケンスパラメータ、スライス、タイル、タイルグループ、ピクチャー、コーディングツリーユニット（ｃｏｄｉｎｇ ｔｒｅｅ ｕｎｉｔ，ＣＴＵ）などの単位が上位レベルになり得る。

【0156】

図１６を参照すると、ｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｓｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇは、最大変換サイズを示すフラグであってよい。例えば、ｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｓｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇの値が１であれば、最大変換サイズは６４であり、ｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｓｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇの値が０であれば、合最大変換サイズは３２であってよい。このとき、最大変換サイズは、ルーマサンプルを基準にしたサイズであってよい。

【0157】

また、ＭａｘＴｂＬｏｇ２ＳｉｚｅＹは、最大変換サイズにｌｏｇ２を取った値であってよい。したがって、ＭａｘＴｂＬｏｇ２ＳｉｚｅＹは、（ｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｓｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇ？６：５）であってよい。すなわち、ｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｓｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇの値が１であれば、ＭａｘＴｂＬｏｇ２ＳｉｚｅＹ値は６であり、ｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｓｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇの値が０であれば、ＭａｘＴｂＬｏｇ２ＳｉｚｅＹ値は５になる。

【0158】

また、最大変換サイズを示すＭａｘＴｂＳｉｚｅＹは、（１＜＜ＭａｘＴｂＬｏｇ２ＳｉｚｅＹ）であってよい。すなわち、ＭａｘＴｂＬｏｇ２ＳｉｚｅＹの値が６であれば、左にビットを６桁移動させ、ＭａｘＴｂＳｉｚｅＹの値は６４になり、ＭａｘＴｂＬｏｇ２ＳｉｚｅＹの値が５であれば、左にビットを５桁移動させ、ＭａｘＴｂＳｉｚｅＹの値は３２になる。

【0159】

図１６に開示されたＭｉｎＴｂＳｉｚｅＹは、最小変換サイズ（ｍｉｎｉｍｕｍ ｔｒａｎｓｆｏｒｍ ｓｉｚｅ）を示す値であってよい。

【0160】

ルーマコーディングツリーブロックのサイズ（ＣｔｂＳｉｚｅＹ）又はコーディングツリーユニットのサイズ（ＣＴＵ ｓｉｚｅ）は可変してよい。例えば、ＣｔｂＳｉｚｅＹが６４よりも小さい場合、最小変換サイズは６４よりも小さくてよい。したがって、ＣｔｂＳｉｚｅＹが６４よりも小さい場合、ｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｓｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇの値は、０であってよい。

【0161】

以下、本発明で記述するＣｔｂｓｉｚｅＹは、ルーマコーディングツリーブロックのサイズを意味するものであり、具体的に、ルーマコーディングツリーブロックの幅及び高さを示す。

【0162】

図１７は、本発明の一実施例に係る上位レベルにおけるシンタックスを示す図である。

【0163】

図１７を参照すると、図１７に示したシンタックス構造は上位レベルのシンタックスでよく、ｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｓｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇを含むことができる。

【0164】

また、図１７のシンタックス構造は、ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５を含むことができる。ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５に基づいてＣＴＵサイズ及びルーマコーディングツリーブロックのサイズＣｔｂＳｉｚｅＹが決定されてよい。例えば、ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５＋５は、ＣｔｂＬｏｇ２ＳｉｚｅＹであり、ＣｔｂＬｏｇ２ＳｉｚｅＹは、ｌｏｇ２（ＣｔｂＳｉｚｅＹ）を表す。また、ＣｔｂＳｉｚｅＹは（１＜＜ＣｔｂＬｏｇ２ＳｉｚｅＹ）と決定されてよい。

【0165】

また、図１７のシンタックス構造は、ｓｐｓ＿ｓｂｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇ、ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇを含むことができる。ｓｐｓ＿ｓｂｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、サブブロック変換（ｓｕｂｂｌｏｃｋ ｔｒａｎｓｆｏｒｍ，ＳＢＴ）が使用され得るか否かを示すフラグであってよい。ＳＢＴは、ＣＵ又はＰＵの一部サンプルだけを変換するものであってよい。ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇは、ＳＢＴが用いられてよい最大サイズを示すフラグであってよい。図１７を参照すると、ｓｐｓ＿ｓｂｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇが、ＳＢＴが用いられてよいことを示す場合（例えば、ｓｐｓ＿ｓｂｔｅｎａｂｌｅｄ＿ｆｌａｇの値が１である場合）、ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇはシグナルされてよい。一方、ｓｐｓ＿ｓｂｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇが、ＳＢＴが用いられなくてよいことを示す場合（例えば、ｓｐｓ＿ｓｂｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が０である場合）、ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇは、シグナルされなくてもよい。また、ブロックの幅と高さがいずれも、ＳＢＴが用いられてよい最大サイズ以下である場合に、ＳＢＴは用いられてよい。

【0166】

ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇが示す、ＳＢＴが用いられてよい最大サイズは、３２を含むことができる。また、ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇが示す、ＳＢＴが用いられてよい最大サイズは、３２又は６４であってよい。最大変換サイズが、ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇが示すＳＢＴが用いられてよい最大サイズよりも小さい場合、ＳＢＴが用いられてよい最大サイズは、最大変換サイズに設定されてよい。図１７の７－３１を参照すると、最大変換サイズ（ＭａｘＴｂＳｉｚｅＹ）とｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇによって示されたＳＢＴが用いられてよい最大サイズのうち小さい値が、ＳＢＴが用いられてよい最大サイズ（ＭａｘＳｂｔＳｉｚｅ）に設定されてよい。

【0167】

図１７のシンタックス構造は、ｓｐｓ＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇを含むことができる。ｓｐｓ＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、変換スキップ（ｔｒａｎｓｆｏｒｍ ｓｋｉｐ）が使用可能か否かを示すフラグであってよい。このとき、変換スキップは、変換を行わないことを表してよい。

【0168】

図１８は、本発明の一実施例に係る変換ツリーシンタックスを示す図である。

【0169】

図１８の変換ツリーシンタックスは、図１６～図１７で説明した可変的な最大変換サイズを支援するためのシンタックスであってよい。

【0170】

ＣＵ又はＰＵの最大サイズが最大変換サイズの２倍であり、固定された最大変換サイズを使用する場合、図１１～図１３で説明したシンタックス及びデコーディングプロセッサが用いられてよい。具体的に、ＣＵ又はＰＵの最大サイズが１２８であり、最大変換サイズが６４であるとき、図１１～図１３の実施例が用いられてよい。このとき、ＣＵ又はＰＵが最大変換サイズよりも大きいためＴＵが分割される場合に、ＴＵは２個又は４個に分割されてよい。分割は、水平（ｈｏｒｉｚｏｎｔａｌ）方向、垂直（ｖｅｒｔｉｃａｌ）方向にそれぞれ２個まで分割されてよい。

【0171】

しかし、可変的な最大変換サイズが用いられる場合、又は従来の最大変換サイズよりも小さい最大変換サイズが支援される場合、又はＣＵ又はＰＵの最大サイズが最大変換サイズの２倍よりも大きい場合には、ＴＵが水平方向、垂直方向にそれぞれ２個以上に分割される必要がある。しかし、図１１～図１３で説明したシンタックス、プロセスは、このような分割を支援しないという問題点がある。

【0172】

したがって、このような問題点を解決するために、図１８を参照して、ＴＵを水平又は垂直方向のいずれかにのみ２個に分割する動作を回帰的（ｒｅｃｕｒｓｉｖｅ）に行うようにするシンタックスを説明する。図１８を参照すると、ｔｂＷｄｉｔｈがＭａｘＴｂＳｉｚｅＹよりも大きい、又はｔｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹよりも大きい場合、図１８の変換ツリーシンタックス‘ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（）’が再び呼び出されてよい。このとき、‘ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（）’は、２回（図１８の（６）と（８）、又は図１８の（６）と（１０））呼び出されてよい。２回の呼び出しが図１８の（６）と（８）であるか或いは図１８の（６）と（１０）であるかは、ＴＵの最初の分割方向によって決定されてよい。ｖｅｒＳｐｌｉｔＦｉｒｓｔに基づいてＴＵの最初の分割方向が決定されてよい。ｖｅｒＳｐｌｉｔＦｉｒｓｔに基づき、呼び出される‘ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（）’における入力（ｉｎｐｕｔ）が変わってよい。また、ｖｅｒＳｐｌｉｔＦｉｒｓｔに基づき、前記２回の呼び出しが図１８の（６）と（８）であるか或いは図１８の（６）と（１０）であるかが決定されてよい。ｔｂＷｉｄｔｈ、ｔｂＨｅｉｇｈｔは、ブロックの幅、高さであり、ＭａｘＴｂＳｉｚｅＹは最大変換サイズである。

【0173】

図１８の（３）を参照すると、ｔｂＷｉｄｔｈ、ｔｂＨｅｉｇｈｔ、ＭａｘＴｂＳｉｚｅＹに基づいてｖｅｒＳｐｌｉｔＦｉｒｓｔ値が決定されてよい。

【0174】

本発明の一実施例において、ｔｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹよりも大きく、ｔｂＷｉｄｔｈがｔｂＨｅｉｇｈｔよりも大きい場合、ｖｅｒＳｐｌｉｔＦｉｒｓｔ値は１に設定され、そうでない場合、ｖｅｒＳｐｌｉｔＦｉｒｓｔ値は０に設定されてよい。

【0175】

図１８の‘ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（）’の入力（ｉｎｐｕｔ）であるブロックの幅、高さは、図１８の（６）、（８）、（１０）ではｔｒａｆｏＷｉｄｔｈ、ｔｒａｆｏＨｅｉｇｈｔであってよい。ｔｒａｆｏＷｉｄｔｈ、ｔｒａｆｏＨｅｉｇｈｔは、ｖｅｒＳｐｌｉｔＦｉｒｓｔに基づいて決定されてよい。例えば、ｖｅｒＳｐｌｉｔＦｉｒｓｔが１である場合、ｔｒａｆｏＷｉｄｔｈはｔｂＷｉｄｔｈ／２に設定され、ｖｅｒＳｐｌｉｔＦｉｒｓｔが０である場合、ｔｒａｆｏＷｉｄｔｈはｔｂＷｉｄｔｈに設定されてよい。また、ｖｅｒＳｐｌｉｔＦｉｒｓｔが０である場合、ｔｒａｆｏＨｅｉｇｈｔはｔｂＨｅｉｇｈｔ／２に設定され、ｖｅｒＳｐｌｉｔＦｉｒｓｔが１である場合、ｔｒａｆｏＨｅｉｇｈｔはｔｂＨｅｉｇｈｔに設定されてよい。すなわち、図１８の（６）、（８）、（１０）の入力（ｉｎｐｕｔ）であるｔｒａｆｏＷｉｄｔｈ、ｔｒａｆｏＨｅｉｇｈｔは、既存のブロック幅、高さのいずれか一つと同一であり、残り一つは、既存の値の半分であってよい。言い換えると、ｔｒａｆｏＷｉｄｔｈ、ｔｒａｆｏＨｅｉｇｈｔはｔｂＷｉｄｔｈ／２、ｔｂＨｅｉｇｈｔであるか、ｔｂＷｉｄｔｈ、ｔｂＨｅｉｇｈｔ／２であってよい。

【0176】

本発明の一実施例として、ｔｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹ以上であり、ｔｂＷｉｄｔｈがｔｂＨｅｉｇｈｔ以上である場合、ｖｅｒＳｐｌｉｔＦｉｒｓｔは１に設定されてよく、そうでない場合、ｖｅｒＳｐｌｉｔＦｉｒｓｔは０に設定されてよい。

【0177】

図１８の（４）、（５）によってブロックの幅、高さはアップデートされてよい。このとき、アップデートされたブロックの幅、高さは、ｔｒａｆｏＷｉｄｔｈ、ｔｒａｆｏＨｅｉｇｈｔであってよい。図１８の（６）、すなわち、再び呼び出される‘ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（）’の入力としてｔｒａｆｏＷｉｄｔｈ、ｔｒａｆｏＨｅｉｇｈｔが用いられてよい。図１８の（６）は、座標（ｘ０，ｙ０）、ｔｒａｆｏＷｉｄｔｈ、ｔｒａｆｏＨｅｉｇｈｔを入力とする‘ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（）’を呼び出す過程であってよい。すなわち、既存の‘ｔｒａｎｆｏｒｍ＿ｔｒｅｅ（）’の入力である座標と同じ座標及びアップデートされたブロックの幅（すなわち、ｔｒａｆｏＷｉｄｔｈ）又はアップデートされたブロックの高さ（すなわち、ｔｒａｆｏＨｅｉｇｈｔ）を入力として‘ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（）’を呼び出すことあってよい。

【0178】

ｖｅｒＳｐｌｉｔＦｉｒｓｔに基づいて図１８の（８）又は（１０）が行われてよい。図１８の（８）が行われる場合、座標（ｘ０＋ｔｒａｆｏＷｉｄｔｈ，ｙ０）、ｔｒａｆｏＷｉｄｔｈ、ｔｒａｆｏＨｅｉｇｈｔを入力とする‘ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（）’が呼び出されてよい。図１８の（１０）が行われる場合、座標（ｘ０，ｙ０＋ｔｒａｆｏＨｅｉｇｈｔ）、ｔｒａｆｏＷｉｄｔｈ、ｔｒａｆｏＨｅｉｇｈｔを入力とする‘ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（）’が呼び出されてよい。すなわち、既存の‘ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（）’において図１８の（６）に該当するブロックを除外した残りブロック（座標が互いに異なるので）に該当する‘ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（）’を呼び出すことが、図１８の（８）と（１０）であってよい。

【0179】

‘ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（）’を呼び出す過程は回帰的（ｒｅｃｕｒｓｉｖｅ）に行われてよい。

【0180】

ｔｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹ以下であり、ｔｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹ以下である場合、‘ｔｒａｎｓｆｏｒｍ＿ｕｎｉｔ（）’は呼び出されてよい。

【0181】

図１８におけるｘ０、ｙ０、ｔｂＷｉｄｔｈ、ｔｂＨｅｉｇｈｔは、ルーマサンプル基準の値であってよく、図１１で説明したのと同一であってよい。したがって、ｖｅｒＳｐｌｉｔＦｉｒｓｔを決定するためのサイズ比較は、ルーマサンプルを基準にした値で行われてよい。クロマサンプルを基準にすれば、変換ブロック（ユニット）の幅と高さが同一である場合にも、クロマブロックのｔｂＷｉｄｔｈがｔｂＨｅｉｇｈｔよりも大きい場合が発生し得るわけである。例えば、クロマフォーマットが４：２：２サンプリングである場合、ｔｂＷｉｄｔｈがｔｂＨｅｉｇｈｔよりも大きく、ｔｂＷｉｄｔｈ／ＳｕｂＷｉｄｔｈＣがｔｂＨｅｉｇｈｔ／ＳｕｂＨｅｉｇｈｔＣと同一である状況が発生し得る。

【0182】

図１９は、本発明の一実施例に係るＴＵ分割を示す図である。

【0183】

図１９に示すＴＵの分割は、図１８のシンタックスによる分割を示すことができる。例えば、ブロックの幅（ｔｂＷｉｄｔｈ）が最大変換サイズ（ＭａｘＴｂＳｉｚｅＹ）よりも大きく、ブロックの幅（ｔｂＷｉｄｔｈ）がブロックの高さ（ｔｂＨｅｉｇｈｔ）よりも大きい場合、図１９のように、左側１、右側２のＴＵに分割される垂直スプリット（ｖｅｒｔｉｃａｌ ｓｐｌｉｔ）が適用されてよい。図１８で説明した通り、ｖｅｒＳｐｌｉｔＦｉｒｓｔの値が１であれば、図１９に示すように、左側、右側２個のＴＵに分割されてよい。このとき、再び呼び出した‘ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（）’によってさらに分割されてよい。図１９は、ｔｂＨｅｉｇｈｔも最大変換サイズ（ＭａｘＴｂＳｉｚｅＹ）よりも大きい場合を示している。図１９の左側ＴＵ（１）の内部で分割がなされてよく、図１９の右側ＴＵ（２）の内部で分割がなされてよいが、図１８のシンタックスによれば、‘ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（）’は回帰的（ｒｅｃｕｒｓｉｖｅ）に呼び出されるので、左側ＴＵ（１）でなされた分割に関連した動作が全てパースされる又は行われた後に、ＴＵ２でなされた分割に関連した動作がパースされる又は行われてよい。一方、ブロックの幅が最大変換サイズよりも小さいか、ブロックの幅がブロックの高さよりも小さい場合、ｖｅｒＳｐｌｉｔの値は０と決定されてよい。このとき、ＴＵは、水平スプリット（ｈｏｒｉｚｏｎｔａｌ ｓｐｌｉｔ）が適用され、上側ＴＵ、下側ＴＵに分割されてよい。

【0184】

図２０は、本発明の一実施例に係るＴＵ分割を示す図である。

【0185】

図２０のＴＵ分割は、図１１～図１３を参照して説明した実施例に係るＴＵ分割であってよい。例えば、ブロックの幅（ｔｂＷｉｄｔｈ）が最大変換サイズ（ＭａｘＴｂＳｉｚｅＹ）よりも大きく、ブロックの高さ（ｔｂＨｅｉｇｈｔ）がＭａｘＴｂＳｉｚｅＹよりも大きい場合、図２０のように、一つのＴＵは４個のＴＵに一度に分割されてよい。また図１１～図１３の実施例を参照すると、分割されたＴＵに対するデコーディングプロセスを行う既に設定された順序が存在してよい。既に設定された順序の一例として、図２０の（ａ）、（ｂ）、（ｃ）、（ｄ）の順にデコーディングプロセスが行われてよい。

【0186】

ただし、図１９の（１）に該当する領域は図２０の（ａ）と（ｃ）であり、図１９の（２）に該当する領域は図２０の（ｂ）及び（ｄ）であるので、図１９と図２０の分割されたＴＵに対するデコーディングプロセス実行順序が互いに異なってくるという問題があり得る。また、シンタックス順序とデコーディングプロセス順序とが異なる場合に、シンタックスのブロック順序とデコーディングプロセスのブロック順序とが異なると、具現側面の複雑度が増加するという問題がある。あるブロックのデコーディングプロセスにおいて、それぞれのブロックに適用されるデコーディングプロセスに該当するシンタックスが適用される必要があるためである。

【0187】

図１９と図２０の実施例のようにブロックのデコーディングプロセス順序が互いに変わる場合は、ｔｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹよりも大きく、ｔｂＷｉｄｔｈがｔｂＨｅｉｇｈｔよりも大きい場合であってよい。具体的に、ｔｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹよりも大きく、ｔｂＷｉｄｔｈがｔｂＨｅｉｇｈｔよりも大きく、ｔｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹよりも大きい場合であってよい。例えば、ＭａｘＴｂＳｉｚｅが３２、ｔｂＷｉｄｔｈが１２８、ｔｂＨｅｉｇｈｔが６４である場合に、ブロックのデコーディングプロセス順序が互いに変わってよい。

【0188】

図２１は、本発明の一実施例に係るデコーディングプロセスを示す図である。

【0189】

図２１に開示された内容は、イントラブロックに関連したものであるが、これに限定されず、レジデュアル信号デコーディングプロセス（ｒｅｓｉｄｕａｌ ｓｉｇｎａｌ ｄｅｃｏｄｉｎｇ ｐｒｏｃｅｓｓ）など、ＴＵ分割に対する他の実施例においても適用可能である。

【0190】

図２１に開示されたデコーディングプロセスは、図１８のシンタックスに該当するデコーディングプロセスである。

【0191】

図２０などの実施例で上述した問題を解決するために、ＴＵ分割に関連したデコーディングプロセスは変更される必要がある。上述と同様に、本明細書に記述されたＴＵ分割は、ＴＢを分割するのと同じ意味であってよい。図２１に開示されたデコーディングプロセスは、ＴＢが２つに分割され、回帰的に（ｒｅｃｕｒｓｉｖｅ）動作する形態と定義されてよい。例えば、ｖｅｒＳｐｌｉｔＦｉｒｓｔに基づいてＴＢが２つに分割されてよい。図２１の８－４１、８－４２を参照すると、ｍａｘＴｂＷｉｄｔｈとｍａｘＴｂＨｅｉｇｈｔは、図１２の実施例と同一に決定されてよい。また、図２１のｎＴｂＷ，ｎＴｂＨは各カラー（ｃｏｌｏｒ）成分を基準に設定された値であってよい。ｍａｘＴｂＷｉｄｔｈとｍａｘＴｂＨｅｉｇｈｔは、最大変換ブロックの幅、高さを示し、ｎＴｂＷとｎＴｂＨはブロックの幅、高さを示す。

【0192】

例えば、ｎＴｂＷがｍａｘＴｂＷｉｄｔｈよりも大きく、ｎＴｂＷがｎＴｂＨよりも大きい場合、ｖｅｒＳｐｌｉｔＦｉｒｓｔは１に設定され、そうでない場合、ｖｅｒＳｐｌｉｔＦｉｒｓｔは０に設定されてよい。また、ｎｅｗＴｂＷはｖｅｒＳｐｌｉｔＦｉｒｓｔが１である場合、ｎＴｂＷ／２に設定され、そうでない場合、ｎＴｂＷに設定されてよい（図２１の８－４４）。また、ｎｅｗＴｂＨは、ｖｅｒＳｐｌｉｔＦｉｒｓｔが０である場合、ｎＴｂＨ／２に設定され、そうでない場合、ｎＴｂＨに設定されてよい（図２１の８－４５）。

【0193】

一方、図１８に開示されたシンタックスにおいてｖｅｒＳｐｌｉｔＦｉｒｓｔが互いに異なるように定義されると、図２１のｖｅｒＳｐｌｉｔＦｉｒｓｔは異なるように定義されてよい。例えば、図１８でｔｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹよりも大きく、ｔｂＷｉｄｔｈがｔｂＨｅｉｇｈｔ以上である場合、ｖｅｒＳｐｌｉｔＦｉｒｓｔが１に設定され、そうでない場合、ｖｅｒＳｐｌｉｔＦｉｒｓｔが０に設定されると、図２１のｖｅｒＳｐｌｉｔＦｉｒｓｔは、ｎＴｂＷがｍａｘＴｂＷｉｄｔｈよりも大きく、ｎＴｂＷがｎＴｂＨ以上である場合、１に設定され、そうでない場合、０に設定されてよい。

【0194】

図２１の過程２で、図２１に開示された８．４．５．１節を再びインボーク（ｉｎｖｏｋｅ）することができる。このとき、入力（ｉｎｐｕｔ）としてサンプルロケーションの座標（ｘＴｂ０，ｙＴｂ０）、ｎｅｗＴｂＨ、ｎｅｗＴｂＨが用いられてよい。これは、図１９の左側ＴＵ（１）のようにＴＵが分割されたとき、１番目（左側又は上側）のＴＵに対するものであってよい。

【0195】

また、ｖｅｒＳｐｌｉｔＦｉｒｓｔに基づき、図２１の過程３又は４で図２１の８．４．５．１節が再びインボーク（ｉｎｖｏｋｅ）されてよい。これは、図１９の右側ＴＵ（２）部分のようにＴＵが分割されたとき、２番目（右側又は下側）のＴＵに対するものであってよい。図２１の過程３で図２１の８．４．５．１節がインボーク（ｉｎｖｏｋｅ）される場合、入力（ｉｎｐｕｔ）は、座標（ｘＴｂ０＋ｎｅｗＴｂＷ，ｙＴｂ０）、ｎｅｗＴｂＨ、ｎｅｗＴｂＨが用いられてよい。図２１の過程４で図２１の８．４．５．１節がインボーク（ｉｎｖｏｋｅ）される場合、入力（ｉｎｐｕｔ）は、座標（ｘＴｂ０，ｙＴｂ０＋ｎｅｗＴｂＨ）、ｎｅｗＴｂＨ、ｎｅｗＴｂＨが用いられてよい。

【0196】

上述したように、図１８でｔｂＷｉｄｔｈ、ｔｂＨｅｉｇｈｔは、ルーマ基準の値であってよく、図２１でｎＴｂＷ、ｎＴｂＨは、各カラー（ｃｏｌｏｒ）成分基準の値であってよい。したがって、図２１に開示されたデコーディングプロセスがクロマ成分のブロックに対して行われるとき、図１８のシンタックスと図２１のデコーディングプロセス間に不一致が発生し得る。例えば、ｔｂＷｄｉｔｈとｎＴｂＷ間の関係は、次の通りでよい。ルーマ成分のブロックでは、ｔｂＷｉｄｔｈはｎＴｂＷと同一であり、ｔｂＨｅｉｇｈｔはｎＴｂＨと同一であってよい。クロマ成分のブロックでは、ｔｂＷｉｄｔｈ／ＳｕｂＷｉｄｔｈＣはｎＴｂＷと同一であり、ｔｂＨｅｉｇｈｔ／ＳｕｂＨｅｉｇｈｔＣはｎＴｂＨと同一であってよい。したがって、図１８に開示されたｖｅｒＳｐｌｉｔを決定するためにブロックの幅と高さを比較する部分と、図２１の過程１に開示されたｖｅｒＳｐｌｉｔを決定するためにブロックの幅と高さを比較する部分の結果とが異なることがある。例えば、図１８のｔｂＷｉｄｔｈ＞ｔｂＨｅｉｇｈｔの結果と図２１のｎＴｂＷ＞ｎＴｂＨの結果とが異なることがあり、このため、図１８と図２１のｖｅｒＳｐｌｉｔＦｉｒｓｔ値とが異なってくるという問題がある。

【0197】

図２２は、本発明の一実施例に係るデコーディングプロセスを示す図である。

【0198】

図２２に開示された内容はイントラブロックに関連するものであるが、これに限定されず、レジデュアル信号デコーディングプロセス（ｒｅｓｉｄｕａｌ ｓｉｇｎａｌ ｄｅｃｏｄｉｎｇ ｐｒｏｃｅｓｓ）など、ＴＢ分割に対する他の実施例においても適用可能である。図２２に開示された内容のうち、前述した内容と同じ内容は省略するものとする。

【0199】

図２２に開示された内容は、図１８に開示されたシンタックスに該当するデコーディングプロセスであってよい。また、図２２を参照して、図２０～図２１などで説明した問題を解決するためのデコーディングプロセス、特にＴＢ分割に関連したデコーディングプロセスについて説明する。

【0200】

図２２を参照すると、イントラブロックデコーディングプロセス（ｉｎｔｒａ ｂｌｏｃｋ ｄｅｃｏｄｉｎｇ ｐｒｏｃｅｓｓ）又はレジデュアル信号デコーディングプロセス（ｒｅｓｉｄｕａｌ ｓｉｇｎａｌ ｄｅｃｏｄｉｎｇ ｐｒｏｃｅｓｓ）の入力（ｉｎｐｕｔ）として、ブロックの位置を示す座標（ｘＴｂ０，ｙＴｂ０）、ブロックの幅を示すｎＴｂＷ、ブロックの高さを示すｎＴｂＨ、カラー成分（ｃｏｌｏｒ ｃｏｍｐｏｎｅｎｔ）を示すｃＩｄｘ、ツリー構造を示すｔｒｅｅＴｙｐｅなどがあり得る。このとき、ｎＴｂＷ、ｎＴｂＨは、変換ブロック（ｔｒａｎｓｆｏｒｍ ｂｌｏｃｋ）の幅、高さであってよい。すなわち、ｎＴｂＷ、ｎＴｂＨは、現在ブロックのカラー成分を基準にした幅、高さであってよい。例えば、クロマサブサンプリングが４：２：０のとき、ルーマブロックの幅、高さがそれぞれ１６、１６であれば、図２２に開示されたデコーディングプロセスのｎＴｂＷ、ｎＴｂＨは、クロマブロックに対して（ｃＩｄｘが０でない時）それぞれ８、８であってよい。

【0201】

図２２の８－４１を参照すると、ｍａｘＴｂＷｉｄｔｈは、ｃＩｄｘとＳｕｂＷｉｄｔｈＣに基づいて決定されてよい。例えば、ｃＩｄｘが０である場合、ｍａｘＴｂＷｉｄｔｈはＭａｘＴｂＳｉｚｅＹであり、ｃＩｄｘが０でない場合、ｍａｘＴｂＷｉｄｔｈは、ＭａｘＴｂＳｉｚｅＹ及びＳｕｂＷｉｄｔｈＣに基づいて決定されてよい。ｃＩｄｘが０でない場合、ｍａｘＴｂＷｉｄｔｈは、ＭａｘＴｂＳｉｚｅＹ／ＳｕｂＷｉｄｔｈＣに設定されてよい。

【0202】

図２２の８－４２を参照すると、ｍａｘＴｂＨｅｉｇｈｔは、ｃＩｄｘとＳｕｂＨｅｉｇｈｔＣに基づいて決定されてよい。例えば、ｃＩｄｘが０である場合、ｍａｘＴｂＨｅｉｇｈｔはＭａｘＴｂＳｉｚｅＹであり、ｃＩｄｘが０でない場合、ｍａｘＴｂＨｅｉｇｈｔは、ＭａｘＴｂＳｉｚｅＹ及びＳｕｂＨｅｉｇｈｔＣに基づいて決定されてよい。ｃＩｄｘが０でない場合、ｍａｘＴｂＨｅｉｇｈｔは、ＭａｘＴｂＳｉｚｅＹ／ＳｕｂＨｅｉｇｈｔＣに設定されてよい。

【0203】

ｎＴｂＷがｍａｘＴｂＷｉｄｔｈよりも大きいか、ｎＴｂＨがｍａｘＴｂＨｅｉｇｈｔよりも大きい場合、図２２に開示されたデコーディングプロセスが別の入力（ｉｎｐｕｔ）を用いて再びインボーク（ｉｎｖｏｋｅ）されてよい。例えば、インボーク（ｉｎｖｏｋｅ）が２回行われてよい。また、回帰的に（ｒｅｃｕｒｓｉｖｅ）インボーク（ｉｎｖｏｋｅ）される場合が発生してもよい。図２２に開示されたデコーディングプロセスが再びインボーク（ｉｎｖｏｋｅ）されることは、ＴＢが分割されることであってよい。

【0204】

本発明の一実施例によれば、ＴＢが分割されるとき、ｎＴｂＷ、ｎＴｂＨ、ＭａｘＴｂＳｉｚｅＹ、ｃＩｄｘ、ＳｕｂＷｉｄｔｈＣ、ＳｕｂＨｅｉｇｈｔＣに基づいて分割されてよい。または、ＴＢが分割されるとき、ｎＴｂＷ、ｎＴｂＨ、ｍａｘＴｂＷｉｄｔｈ、ｃＩｄｘ、ＳｕｂＷｉｄｔｈＣ、ＳｕｂＨｅｉｇｈｔＣに基づいて分割されてよい。または、ｖｅｒＳｐｌｉｔＦｉｒｓｔ値に基づいてＴＢが分割されてよい。

【0205】

ｖｅｒＳｐｌｉｔＦｉｒｓｔ値は、ｃＩｄｘに基づいて決定されてよい。例えば、ｃＩｄｘが０のとき、ｖｅｒＳｐｌｉｔＦｉｒｓｔ値は、ｎＴｂＷ、ｎＴｂＨ、ｍａｘＴｂＷｉｄｔｈに基づいて決定されてよい。ｃＩｄｘが０のとき、ｖｅｒＳｐｌｉｔＦｉｒｓｔ値は、ＳｕｂＷｉｄｔｈＣ、ＳｕｂＨｅｉｇｈｔＣに関係なく決定されてよい。一方、ｃＩｄｘが０でない場合、すなわち、ｃＩｄｘが１又は２である場合、ｖｅｒＳｐｌｉｔＦｉｒｓｔ値は、ｎＴｂＷ、ｎＴｂＨ、ｍａｘＴｂＷｉｄｔｈ、ＳｕｂＷｉｄｔｈＣ、ＳｕｂＨｅｉｇｈｔＣに基づいて決定されてよい。

【0206】

また、ｖｅｒＳｐｌｉｔＦｉｒｓｔ値は、一つ以上の条件に基づいて決定されてよい。例えば、ｖｅｒＳｐｌｉｔＦｉｒｓｔは、ブロックの幅（ｗｉｄｔｈ）が最大変換サイズ（ｍａｘｉｍｕｍ ｔｒａｎｓｆｏｒｍ ｓｉｚｅ）よりも大きいか否かに基づいて決定されてよい。ｖｅｒＳｐｌｉｔＦｉｒｓｔは、ブロックの高さ（ｈｅｉｇｈｔ）が最大変換サイズよりも大きいか否かに基づいて決定されてよい。このとき、ブロックの幅、ブロックの高さが最大変換サイズよりも大きいか否かに対する結果は、ルーマブロック基準にしても、クロマブロック基準にしても構わない。言い換えると、いかなるカラー（ｃｏｌｏｒ）成分を基準にしても結果には影響を与えない。したがって、図２２を参照すると、各カラー成分を基準にした入力（ｉｎｐｕｔ）を用いて上述の条件を確認している。これは、ルーマ基準の値に変換する計算を省くためのものでよい。

【0207】

また、ｖｅｒＳｐｌｉｔＦｉｒｓｔ値を決定するための上述した一つ以上の条件は、ブロックの幅と高さに基づく条件であってよい。例えば、ブロックの幅がブロックの高さよりも大きいか否かによってｖｅｒＳｐｌｉｔＦｉｒｓｔ値は決定されてよい。このとき、ブロックの幅、高さは、ルーマ成分を有するブロックの値であってよい。言い換えると、デコーダは、ルーマピクセル、ルーマ成分を基準にした値を基準にブロックの幅、ブロックの高さを比較し、ｖｅｒＳｐｌｉｔＦｉｓｔ値を決定することができる。すなわち、ｃＩｄｘが０である場合（ルーマブロックである場合）には、上述した一つ以上の条件にはｎＴｂＷとｎＴｂＨが用いられ、ｃＩｄｘが０でない場合（クロマブロックである場合）には、ｎＴｂＷ＊ＳｕｂＷｉｄｔｈＣとｎＴｂＨ＊ＳｕｂＨｅｉｇｈｔＣが用いられてよい。図２２を参照すると、ｃＩｄｘが０である場合、ｎＴｂＷがｎＴｂＨよりも大きいか否か確認し、ｃＩｄｘが０でない場合、ｎＴｂＷ＊ＳｕｂＷｉｄｔｈＣがｎＴｂＨ＊ＳｕｂＨｅｉｇｈｔＣよりも大きいか否かが確認できる。

【0208】

このとき、上述した一つ以上の条件を満たす場合、ｖｅｒＳｐｌｉｔＦｉｒｓｔ値は１に設定され、そうでない場合（一つ以上の条件のうち少なくとも一つを満たさない場合）、ｖｅｒＳｐｌｉｔＦｉｒｓｔ値は０に設定されてよい。

【0209】

言い換えると、デコーダは、ブロックの幅（ｗｉｄｔｈ）と最大変換サイズとを比較する時は、カラー成分及びクロマフォーマットを考慮した値を用い、ブロックの幅とブロックの高さとを比較する時は、ルーマ成分を基準にした値を用いることができる。

【0210】

図２２を参照して、上述したｖｅｒＳｐｌｉｔＦｉｒｓｔ値が決定される条件を、下記の式２のように示すことができる。

【0211】

【数2】

【0212】

式２を再び説明すると、ｃＩｄｘが０である場合には、ｖｅｒＳｐｌｉｔＦｉｒｓｔは下記の式３のように決定されてよい。

【0213】

【数3】

【0214】

式２を再び説明すると、ｃＩｄｘが０でない場合（例えばｃＩｄｘが１又は２である場合）、ｖｅｒＳｐｌｉｔＦｉｒｓｔは下記の式４のように決定されてよい。

【0215】

【数4】

【0216】

式２～４のサイズ比較時に、等号（＝）が含まれてよい。言い換えると、ｎＴｂＷがｍａｘＴｂＷｉｄｔｈ以上であるか否か確認でき、ｃＩｄｘが０である場合、ｎＴｂＷがｎＴｂＨ以上であるか否かを確認し、ｃＩｄｘが０でない場合、ｎＴｂＷ＊ＳｕｂＷｉｄｔｈＣがｎＴｂＨ＊ＳｕｂＨｅｉｇｈｔＣ以上であるか否かが確認できる。このとき、図１８のシンタックスにおいても同様に、サイズ比較時に等号（＝）が含まれてよい。

【0217】

図２２の８－４４、８－４５を参照すると、ｖｅｒＳｐｌｉｔＦｉｒｓｔ値に基づいてｎｅｗＴｂＷ、ｎｅｗＴｂＨが決定されてよい。例えば、ｖｅｒＳｐｌｉｔＦｉｒｓｔが１である場合、ｎｅｗＴｂＷはｎＴｂＷ／２、ｎｅｗＴｂＨはｎＴｂＨと決定されてよい。ｖｅｒＳｐｌｉｔＦｉｒｓｔが０である場合、ｎｅｗＴｂＷはｎＴｂＷ、ｎｅｗＴｂＨはｎＴｂＨ／２と決定されてよい。

【0218】

図２２を参照すると、ｖｅｒＳｐｌｉｔＦｉｒｓｔに基づき、図２２の過程２と３でデコーディングプロセスが再びインボーク（ｉｎｖｏｋｅ）されるか、過程２と４でデコーディングプロセスが再びインボーク（ｉｎｖｏｋｅ）されてよい。

【0219】

図２２の過程２では、ブロックの位置（ｘＴｂ０，ｙＴｂ０）、ｎｅｗＴｂＷ、ｎｅｗＴｂＨを用いてデコーディングプロセスが再びインボーク（ｉｎｖｏｋｅ）されてよい。これは、図１９の左側ＴＵ（１）部分のように分割されたものの１番目（左側或いは上側）のＴＵに対するものでよい。

【0220】

図２２の過程３では、ブロックの位置（ｘＴｂ０＋ｎｅｗＴｂＷ，ｙＴｂ０）、ｎｅｗＴｂＷ、ｎｅｗＴｂＨを用いてデコーディングプロセスが再びインボーク（ｉｎｖｏｋｅ）されてよい。これは、図１９の右側ＴＵ（２）部分のように分割されたものの２番目（右側）のＴＵに対するものでよい。

【0221】

図２２の過程４では、ブロックの位置（ｘＴｂ０，ｙＴｂ０＋ｎｅｗＴｂＨ）、ｎｅｗＴｂＷ、ｎｅｗＴｂＨを用いてデコーディングプロセスが再びインボーク（ｉｎｖｏｋｅ）されてよい。これは、図１９の右側ＴＵ（２）部分のように分割されたものの２番目（下側）のＴＵに対するものでよい。

【0222】

図２３は、本発明の一実施例に係る上位レベルシンタックスを示す図である。

【0223】

最大変換サイズ（ｍａｘｉｍｕｍ ｔｒａｎｓｆｏｒｍ ｓｉｚｅ）を示すシンタックス要素は、ＣＴＵサイズ又はＣｔｂＳｉｚｅＹ又はＣｔｂＳｉｚｅＹを示すシンタックス要素に基づいてよい。例えば、ＣＴＵサイズ又はＣｔｂＳｉｚｅＹ又はＣｔｂＳｉｚｅＹを示すシンタックス要素が示すサイズ（ｓｉｚｅ）よりも大きい最大変換サイズは、候補から除外されてよい。ＣＴＵサイズ又はＣｔｂＳｉｚｅＹ又はＣｔｂＳｉｚｅＹを示すシンタックス要素が示すサイズが６４よりも小さい場合、最大変換サイズ候補から６４以上の値は除外されてよい。最大変換サイズとして可能な値が２つである場合、最大変換サイズを知らせるシグナリング無しで、ＣＴＵサイズ又はＣｔｂＳｉｚｅＹ又はＣｔｂＳｉｚｅＹを示すシンタックス要素が示すサイズに基づいて最大変換サイズは決定され、その値が決定されてよい。ＣＴＵサイズは、コーディングツリーユニットの幅、高さを意味し、ＣｔｂＳｉｚｅＹは、ルーマコーディングツリーブロックのサイズを示し、クロマコーディングツリーブロックの幅、高さを意味する。

【0224】

図２３を参照すると、最大変換サイズを示すシンタックス要素は、ｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｓｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇであってよい。最大変換サイズを示すシンタックス要素は、最大変換サイズを６４及び６４よりも小さい値と示すことができる。仮にＣｔｂＳｉｚｅＹが６４よりも小さい場合、ｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｓｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇはシグナルされず、推論（ｉｎｆｅｒ）されてよい。例えば、ｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｓｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇの値が１のとき、最大変換サイズが６４を示すと、ＣｔｂＳｉｚｅＹが６４よりも小さい場合、ｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｓｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇの値は０と推論（ｉｎｆｅｒ）されてよい。または、ＭａｘＴｂＬｏｇ２ＳｉｚｅＹの値は５と決定されるか、ＭａｘＴｂＳｉｚｅＹの値は３２と決定されてよい。

【0225】

最小ＣｔｂＳｉｚｅＹが３２であれば、上述したＣｔｂＳｉｚｅＹが６４よりも小さい場合は、ＣｔｂＳｉｚｅＹが３２である場合と同一であってよい。例えば、ＣｔｂｓｉｚｅＹが３２であれば、ｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｓｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇの値は０と推論（ｉｎｆｅｒ）され、よって、最大変換サイズ（ＭａｘＴｂＳｉｚｅＹ）値は３２と決定されてよい。

【0226】

図２４は、本発明の一実施例に係る上位レベルシンタックスを示す図である。

【0227】

最大変換サイズ（ｍａｘｉｍｕｍ ｔｒａｎｓｆｏｒｍ ｓｉｚｅ）が制限的であれば、それに伴い、サブブロック変換（ｓｕｂｂｌｏｃｋ ｔｒａｎｓｆｏｒｍ，ＳＢＴ）が用いられてよい最大サイズも制限的であってよい。例えば、ＳＢＴが用いられてよい最大サイズは、最大変換サイズ以下であってよい。したがって、ＳＢＴが用いられてよい最大サイズを示すシンタックス要素が変わってよい。例えば、最大変換サイズ又は最大変換サイズを示すシンタックス要素に基づき、ＳＢＴが用いられてよい最大サイズを示すシンタックス要素がシグナルされてよい。

【0228】

図２４を参照すると、最大変換サイズが６４よりも小さい場合、ＳＢＴが用いられてよい最大サイズが６４であるか否かを示すシンタックス要素はシグナルされず、ＳＢＴが用いられてよい最大サイズは推論（ｉｎｆｅｒ）されてよい。ＳＢＴが用いられてよい最大サイズが６４であることを示すシンタックス要素は、ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇであってよい。図２４を参照すると、ｓｐｓ＿ｓｂｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１であり、ｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇの値が１である場合（すなわち、ｓｐｓ＿ｓｂｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇ＆＆ｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇ）、ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇはシグナルされ、そうでない場合、ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇはシグナルされない。また、ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇが存在しない場合、ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇの値は０と推論（ｉｎｆｅｒ）されてよい。または、ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇが存在しない場合、その値はｓｐｓ＿ｍａｘ＿ｌｕｍａ＿ｔｒａｎｆｏｒｍ＿ｓｉｚｅ＿６４＿ｆｌａｇの値と推論（ｉｎｆｅｒ）されてよい。このとき、ＭａｘＳｂｔＳｉｚｅは、図２４の７－３１に開示されているように、ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇが１である場合に６４、ｓｐｓ＿ｓｂｔ＿ｍａｘ＿ｓｉｚｅ＿６４＿ｆｌａｇが０である場合に３２に設定されてよい。

【0229】

図２５は、本発明の一実施例に係る変換ツリーシンタックスを示す図である。

【0230】

図２５は、図１８のシンタックスを参照して説明したｖｅｒＳｐｌｉｔＦｉｒｓｔ値を決定するための条件が変更されたものであり、その他同一の説明は省略するものとする。

【0231】

ＴＵ分割方法は、ツリー類型（ｔｒｅｅＴｙｐｅ）に基づいて互いに異なってよい。例えば、ツリー類型がＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡである場合、各カラー（ｃｏｌｏｒ）成分、すなわち、クロマ成分を有するブロックを基準にした幅、高さに基づいてＴＵ分割がなされてよい。図１８の実施例では図１８の（３）に開示された条件を用いてｖｅｒＳｐｌｉｔＦｉｒｓｔが決定されたが、ＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡである場合、図２５の（２）に開示された条件を用いてｖｅｒＳｐｌｉｔＦｉｒｓｔが決定されてよい。

【0232】

ブロックの幅と最大変換サイズ（ｍａｘｉｍｕｍ ｔｒａｎｓｆｏｒｍ ｓｉｚｅ）を決定する時は、ルーマを基準にしても、各カラー成分を基準にしても構わず、変換ツリーシンタックス‘ｔｒａｎｓｆｏｒｍ＿ｔｒｅｅ（）’の入力は、ルーマを基準にした値が用いられてよい。しかし、ブロックの幅と高さを比較する時は、クロマ成分を基準にした値が用いられてよい。すなわち、ｔｂＷｉｄｔｈ／ＳｕｂＷｉｄｔｈＣとｔｂＨｅｉｇｈｔ／ＳｕｂＨｅｉｇｈｔＣとを比較することが可能である。具体的に、ｔｂＷｉｄｔｈ／ＳｕｂＷｉｄｔｈＣがｔｂＨｅｉｇｈｔ／ＳｕｂＨｅｉｇｈｔＣよりも大きいかどうか確認することが可能である。

【0233】

これにより、ツリー類型がデュアルツリー（ｄｕａｌ ｔｒｅｅ）である場合に、ルーマ成分のときにおけると同じ基準でクロマ成分に対するＴＵ分割が行われてよい。

【0234】

図２５を参照すると、ツリー類型がＳＩＮＧＬＥ＿ＴＲＥＥ又はＤＵＡＬ＿ＴＲＥＥ＿ＬＵＭＡである場合に、デコーダは、図２５の（１）の過程を行ってｖｅｒＳｐｌｉｔＦｉｒｓｔを決定することができる。すなわち、ルーマ成分を基準にした値を用いて分割が決定されてよい。ツリー類型がＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡである場合に、デコーダは、図２５の（２）の過程を行ってｖｅｒＳｐｌｉｔＦｉｒｓｔを決定することができる。すなわち、クロマ成分を基準にした値を用いて分割が決定されてよい。

【0235】

図２６は、本発明の一実施例に係るデコーディングプロセスを示す図である。

【0236】

図２６に開示されたデコーディングプロセッサの一実施例は、図２５に開示されたシンタックスに該当するデコーディングプロセスであってよい。上述と同様に、本明細書に記述されたＴＵ分割は、ＴＢを分割するのと同じ意味であってよい。

【0237】

ＴＢ分割又はｖｅｒＳｐｌｉｔＦｉｒｓｔが決定される方法は、ｃＩｄｘ、ツリー類型（ｔｒｅｅＴｙｐｅ）などに基づいて決定されてよい。例えば、ｃＩｄｘが０である場合、各カラー（ｃｏｌｏｒ）成分を基準にしたブロックの幅（ｗｉｄｔｈ）、ブロックの高さ（ｈｅｉｇｈｔ）を用いてｖｅｒＳｐｌｉｔＦｉｒｓｔは決定されてよい。ツリー類型がＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡである場合、各カラー成分を基準にしたブロックの幅（ｗｉｄｔｈ）、ブロックの高さ（ｈｅｉｇｈｔ）を用いてｖｅｒＳｐｌｉｔＦｉｒｓｔは決定されてよい。ｃＩｄｘが０でなく、ツリー類型がＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡでない場合（すなわち、ｃＩｄｘが０でなく、ツリー類型がＳＩＮＧＬＥ＿ＴＲＥＥである場合）、ルーマ成分を基準にしたブロックの幅、ブロックの高さを用いてｖｅｒＳｐｌｉｔＦｉｒｓｔは決定されてよい。

【0238】

すなわち、ｃＩｄｘが０であるか、ツリー類型がＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡである場合（ｃＩｄｘ＝＝０｜｜ｔｒｅｅＴｙｐｅ＝＝ＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡである場合）、ｎＴｂＷがｎＴｂＨよりも大きいかを比較し、ｖｅｒＳｐｌｉｔＦｉｒｓｔが決定されてよい。すなわち、ＳｕｂＷｉｄｔｈＣとＳｕｂＨｅｉｇｈｔＣを用いることなくｖｅｒＳｐｌｉｔＦｉｒｓｔは決定されてよい。ｃＩｄｘが０でなく、ツリー類型がＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡでない場合（ｃＩｄｘ！＝０＆＆ｔｒｅｅＴｙｐｅ！＝ＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡである場合）、ｎＴｂＷ／ＳｕｂＷｉｄｔｈＣがｎＴｂＨ／ＳｕｂＨｅｉｇｈｔＣよりも大きいか比較し、ｖｅｒＳｐｌｉｔＦｉｒｓｔが決定されてよい。

【0239】

最大変換サイズ（ｍａｘｉｍｕｍ ｔｒａｎｓｆｏｒｍ ｓｉｚｅ）よりも最大変換スキップサイズ（ｍａｘｉｍｕｍ ｔｒａｎｓｆｏｒｍ ｓｋｉｐ ｓｉｚｅ）が小さくてよい。例えば、最大変換サイズが可変的であれば、それにしたがって最大変換スキップサイズが変わってよい。したがって、最大変換サイズが可変的であれば、それにしたがって最大変換スキップサイズをシグナルする方法は変わってよい。

【0240】

最大変換サイズと最大変換スキップサイズは同一であってよい。このとき、ＣＵ又はＰＵのサイズが最大変換サイズよりも大きいとき、分割されたＴＵに変換スキップ（ｔｒａｎｓｆｏｒｍｓｋｉｐ）が用いられるか否かは共有されてよい。言い換えると、ＣＵ又はＰＵのサイズが最大変換サイズよりも大きいとき、分割されたＴＵに変換スキップが用いられるか否かを示すシンタックス要素のシグナルリングは、一部省略されてもよい。ＣＵ又はＰＵのサイズが最大変換サイズよりも大きいとき、分割されたＴＵのレジデュアル信号（ｒｅｓｉｄｕａｌ ｓｉｇｎａｌ）形態が類似であり得るためである。分割されたＴＵに変換スキップが用いられるか否かが共有される、或いは関連したシンタックス要素のシグナルリングが省略されることは、可変的な最大変換サイズ、可変的な最大変換スキップサイズを使用するとき、最大変換サイズと最大変換スキップサイズとが同一である場合に限ることができる。さらに、分割されたＴＵに変換スキップが用いられるか否かが共有されることは、基準となるＴＵ、例えば、１番目のＴＵに変換スキップが用いられる場合に限ることができる。すなわち、基準となるＴＵに変換スキップが用いられない場合、分割された他のＴＵに対して変換スキップが用いられるか否かがシグナルされてよい。また、既に設定された順序で分割されたＴＵに変換スキップが用いられるか否かがシグナルされ、特定ＴＵに変換スキップが用いられることがシグナルされると、その後、ＴＵに対して変換スキップが用いられるか否かを示すシンタックス要素はシグナルされず、変換スキップが用いられると決定されてよい。

【0241】

分割されたＴＵに対する変換スキップが用いられるか否かが共有される或いは関連したシンタックス要素のシグナリングが省略される場合、ＣＵ又はＰＵレベルで変換スキップが用いられるか否かに対するシンタックス要素のシグナリングが可能である。

【0242】

図２７は、本発明の一実施例に係るＢＤＰＣＭ実行方法を示す図である。

【0243】

ＢＤＰＣＭ（ｂｌｏｃｋ－ｂａｓｅｄ ｄｅｌｔａ ｐｕｌｓｅ ｃｏｄｅ ｍｏｄｕｌａｔｉｏｎ）は、（イントラ）予測方法又はコーディング方法であってよい。また、ＢＤＰＣＭは、予測方法及びレジデュアル信号（ｒｅｓｉｄｕａｌ ｓｉｇｎａｌ）生成方法において固有の特徴を有することが可能である。すなわち、特定値（例えば、レジデュアル信号又は予測信号（ｐｒｅｄｉｃｔｉｏｎ ｓｉｇｎａｌ）又はピクチャーサンプル（ｐｉｃｔｕｒｅ ｓａｍｐｌｅ）又は復元されたサンプル（ｒｅｃｏｎｓｔｒｕｃｔｅｄ ｓａｍｐｌｅ））の差に基づく値をコードしシグナルする方法であってよい。例えばエンコーダは、特定値の差に基づく値をシグナルし、デコーダはシグナリングに基づいて特定値を復元することができる。このとき、デコーダの復元過程において、特定値の差を計算する過程を逆に行わなければならず、シグナルされた値に基づいて加算する過程を行って特定値を復元することができる。ＢＤＰＣＭは、ＲＤＰＣＭ（Ｑｕａｎｔｉｚｅｄ ｒｅｓｉｄｕａｌ ｄｉｆｆｅｒｅｎｔｉａｌ ｐｕｌｓｅ ｃｏｄｅｄ ｍｏｄｕｌａｔｉｏｎ）と記述されてよい。

【0244】

ＢＤＰＣＭが用いられるか否かを示すシンタックス要素が存在してよい。例えば、前記シンタックス要素は、ＢｄｐｃｍＦｌａｇ又はｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇであってよい。ＢＤＰＣＭが用いられるか否かを示すシンタックス要素のシグナリングは、ＣＵレベルで行われてよい。また、ＢＤＰＣＭの使用可否を示す上位レベルにおけるシンタックス要素が存在してよい。例えば、ＢＤＰＣＭが用いられるか否かを示す上位レベルにおけるシンタックス要素は、ｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇであってよい。また、シンタックス要素がシグナルされる上位レベルは、ＳＰＳレベル、スライスレベル（ｓｌｉｃｅ ｌｅｖｅｌ）、タイルレベル（ｔｉｌｅ ｌｅｖｅｌ）、タイルグループレベル（ｔｉｌｅ ｇｒｏｕｐ ｌｅｖｅｌ）であってよい。ＢＤＰＣＭが用いられるか否かを示す上位レベルにおけるシンタックス要素のシグナリングが可能である場合、ＢＤＣＰＭが用いられるか否かを示すシンタックス要素のシグナリングは行われなくてもよい。また、ＢＤＰＣＭが用いられるか否かを示す上位レベルにおけるシンタックス要素のシグナリングが可能でない場合、ＢＤＣＰＭが用いられるか否かを示すシンタックス要素のシグナリングは行われなくてもよい。

【0245】

ＢＤＰＣＭの予測モード（ｐｒｅｄｉｃｔｉｏｎ ｍｏｄｅ）は制限的であってよい。ＢＤＰＣＭの予測モードを示すシンタックス要素は、ＢｄｐｃｍＤｉｒ又はｉｎｔｒａ＿ｂｄｐｃｍ＿ｄｉｒ＿ｆｌａｇであってよい。ＢＤＰＣＭが使用される場合、予測モードは角度モードであってよい。具体的に、ＢＤＰＣＭが使用される場合、予測モードは水平モード（ｈｏｒｉｚｏｎｔａｌ ｍｏｄｅ）（ｍｏｄｅ１８；ＩＮＴＲＡ＿ＡＮＧＵＬＡＲ１８）又は垂直モード（ｖｅｒｔｉｃａｌ ｍｏｄｅ）（ｍｏｄｅ５０；ＩＮＴＲＡ＿ＡＮＧＵＬＡＲ５０）であってよい。したがって、ＢＤＰＣＭが使用されるとき、ある位置の予測サンプル値は、水平モードである場合、前記ある位置の左側に該当する参照サンプル（ｒｅｆｅｒｅｎｃｅ ｓａｍｐｌｅ）と同じ値であってよい。また、ＢＤＰＣＭが使用され、水平モードである場合、同一列（ｒｏｗ）に該当する予測サンプル（すなわち、ｙ座標が同一である予測サンプル）は、同一の値を有してよい。また、ＢＤＰＣＭが使用される場合、ある位置の予測サンプル値は、垂直モードである場合、前記ある位置の上側に該当する参照サンプルと同じ値であってよい。また、ＢＤＰＣＭが使用され、垂直モードである場合、同一行（ｃｏｌｕｍｎ）に該当する予測サンプル（すなわち、ｘ座標が同一である予測サンプル）は同一の値を有してよい。

【0246】

図２７（ａ）は、ＢＤＰＣＭの予測モード導出（ｐｒｅｄｉｃｔｉｏｎ ｍｏｄｅ ｄｅｒｉｖａｔｉｏｎ）を示す図であり、図２７（ａ）を参照すると、ＢＤＰＣＭの予測モード導出は、ＢｄｐｃｍＤｉｒに基づくことができる。図２７（ａ）で、ＢｄｐｃｍＦｌａｇの値が１である場合は、ＢＤＰＣＭが使用される場合を意味できる。ＩｎｔｒａＰｒｅｄＭｏｄｅＹは、予測モードを示す値であってよい。具体的に、ＩｎｔｒａＰｒｅｄＭｏｄｅＹは、ルーマ成分に対する予測モードを示す値であってよい。例えば、ＢｄｐｃｍＤｉｒに基づき、ＩｎｔｒａＰｒｅｄＭｏｄｅＹはＩＮＴＲＡ＿ＡＮＧＵＬＡＲ５０又はＩＮＴＲＡ＿ＡＮＧＵＬＡＲ１８に設定されてよい。ＢｄｐｃｍＤｉｒの値が１である場合、ＩｎｔｒａＰｒｅｄＭｏｄｅＹはＩＮＴＲＡ＿ＡＮＧＵＬＡＲ５０に設定され、垂直モードであってよい。また、ＢｄｐｃｍＤｉｒの値が０である場合ＩｎｔｒａＰｒｅｄＭｏｄｅＹはＩＮＴＲＡ＿ＡＮＧＵＬＡＲ１８に設定され、水平モードであってよい。ＩｎｔｒａＰｒｅｄＭｏｄｅＹに基づいて予測動作が行われてよい。

【0247】

ＢＤＰＣＭに対するレジデュアル信号生成方法又はスケーリング及び変換（ｓｃａｌｉｎｇ ａｎｄ ｔｒａｎｓｆｏｒｍａｔｉｏｎ（ｔｒａｎｓｆｏｒｍ））方法が存在してよい。上述したように、ＢＤＰＣＭが使用される場合、特定値の差に基づく値はコード、シグナルされてよい。例えば、ＢＤＰＣＭが使用される場合、レジデュアル信号又はレジデュアル信号に基づく値の差に基づく値は、コード、シグナルされてよい。シグナルされる第１位置のサンプルに該当する値は、前記第１位置を基準にした第２位置の値と前記第１位置の値との差であってよい。具体的に、シグナルされる第１位置のサンプルに該当する値は、前記第１位置と隣接した位置である第２位置の値と前記第１位置の値との差であってよい。シグナルされる第１位置（ｘ，ｙ）のサンプルに該当する値は、水平モードである場合、第２位置（ｘ－１，ｙ）の値と前記第１位置の値との差であってよい。また、シグナルされる第１位置（ｘ，ｙ）のサンプルに該当する値は、垂直モードである場合、第２位置（ｘ，ｙ－１）の値と前記第１位置の値との差であってよい。このとき、第２位置の値と第１位置の値は、レジデュアル信号又はレジデュアル信号に基づく値であってよい。

【0248】

図２７（ｂ）は、ＢＤＰＣＭが使用される場合、デコーダでの動作を示す図である。図２７（ｂ）を参照すると、ｄｚは、シンタックス要素（ｓｙｎｔａｘｅｌｅｍｅｎｔ）でシグナルされた値に基づいて作ったアレイ（ａｒｒａｙ）であってよい。また、水平モードである場合、ｄｚ［ｘ］［ｙ］値は、ｄｚ［ｘ］［ｙ］とｄｚ［ｘ－１］［ｙ］に基づいて設定されてよい。例えば、水平モードである場合、ｄｚ［ｘ］［ｙ］値は、（ｄｚ［ｘ－１］［ｙ］＋ｄｚ［ｘ］［ｙ］）に基づいて設定されてよい（図２７（ｂ）の８－９６１）。このような設定は、ｘが０よりも大きい場合（ブロックの左側境界（ｌｅｆｔ ｂｏｕｎｄａｒｙ）に接しない場合）に行われてよく、ｘが０である場合には、ｄｚ［ｘ］［ｙ」はｄｚ［ｘ］［ｙ］そのままであってよい。垂直モードである場合、ｄｚ［ｘ］［ｙ］値は、ｄｚ［ｘ］［ｙ］とｄｚ［ｘ］［ｙ－１］に基づいて設定されてよい。垂直モードである場合、ｄｚ［ｘ］［ｙ］値は、（ｄｚ［ｘ］［ｙ－１］＋ｄｚ［ｘ］［ｙ］）に基づいて設定されてよい（図２７（ｂ）の８－９６２）。このような設定は、ｙが０よりも大きい場合（ブロックの上側境界（ｔｏｐ ｂｏｕｎｄａｒｙ）に接しない場合）に行われてよく、ｙが０である場合には、ｄｚ［ｘ］［ｙ」はｄｚ［ｘ］［ｙ］そのままであってよい。和（＋）演算に基づいてｄｚが計算されることは、シグナルされた信号が差（－）演算に基づくものであるためである。例えば、シグナルされた信号ｄｚ［ｘ］［ｙ」は、水平モードである場合、（ｄｚ［ｘ］［ｙ］－ｄｚ［ｘ－１］［ｙ］）に設定され、垂直モードである場合、（ｄｚ［ｘ］［ｙ］－ｄｚ［ｘ］［ｙ－１］）に設定された値であってよい。したがって、これを復元するために、デコーダは和演算に基づく計算を行うことができる。また、前記ｄｚ［ｘ］［ｙ］値に基づいてｄｎｃ［ｘ］［ｙ］が導出（ｄｅｒｉｖａｔｉｏｎ）されてよく、ｄ［ｘ］［ｙ］が導出されてよい（図２７（ｂ）の８－９６３、８－９６４）。

【0249】

本発明の一実施例において、変換（ｔｒａｎｓｆｏｒｍ）は、ｄ［ｘ］［ｙ］に基づいて行われてよい。このとき、変換を行うことは、変換スキップモード（ｔｒａｎｓｆｏｒｍ ｓｋｉｐ ｍｏｄｅ）を行うことを含むことができる。すなわち、変換を行うことは、変換メトリックス（ｔｒａｎｓｆｏｒｍａｔｉｏｎ ｍａｔｒｉｘ）に基づく演算を行わないことを含むことができる。ＢＤＰＣＭが使用される場合、常に変換スキップモードは用いられてよい。ＢＤＰＣＭが使用される場合、変換スキップモードの使用されるか否かを示すシンタックス要素であるｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｆｌａｇの値は、常に１であってよい。変換スキップモードが使用される場合、前記ｄ［ｘ］［ｙ］にベクトル（ｖｅｃｔｏｒ）又はメトリックス（ｍａｔｒｉｘ）を掛ける過程無しでレジデュアル信号は決定されてよい。変換スキップモードが使用される場合、前記ｄ［ｘ］［ｙ］にビットシフト（ｂｉｔ ｓｈｉｆｔ）又はラウンティング（ｒｏｕｎｄｉｎｇ）以外の演算は行われずにレジデュアル信号が決定されてよい。例えば、変換スキップモードが使用される場合、（ｄ［ｘ］［ｙ］＜＜ｔｓＳｈｉｆｔ）値が、レジデュアルサンプルアレイ値（ｒｅｓｉｄｕａｌ ｓａｍｐｌｅ ａｒｒａｙ ｖａｌｕｅ）であるｒ［ｘ］［ｙ］になり得る。ここで、ｔｓＳｈｉｆｔは、変換ブロックの幅及び高さに基づいて決定される値であってよい。また、ｒ［ｘ］［ｙ］に基づいて中間レジデュアルサンプル（ｉｎｔｅｒｍｅｄｉａｔｅ ｒｅｓｉｄｕａｌ ｓａｍｐｌｅ）及びレジデュアルサンプル（ｒｅｓｉｄｕａｌ ｓａｍｐｌｅ）が決定されてよい。また、変換スキップモードが適用される場合にのみ、ＢＤＰＣＭは使用可能であってよい。ＢＤＰＣＭが使用される場合に、変換スキップモードが使用可能なためである。例えば、上位レベルでシグナルされるシンタックス要素が、変換スキップモードが使用可能であることを示す場合にのみ、ＢＤＰＣＭ使用可能であることを示す上位レベルにおけるシンタックス要素のシグナリングが行われてよい。

【0250】

図２８は、本発明の一実施例に係るＢＤＰＣＭに関連したシンタックスを示す図である。

【0251】

ＢＤＰＣＭの使用可否を示す上位レベルでシグナルされるシンタックス要素が、ＢＤＰＣＭが使用可能であることを示す場合、ＢＤＰＣＭは用いられてよい。図２８を参照すると、ｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇに基づき、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇのパースされるか否かが決定されてよい。

【0252】

また、変換スキップ（ｔｒａｎｓｆｏｒｍ ｓｋｉｐ）が使用されてよいブロックサイズは制限的であってよい。例えば、変換スキップが使用されてよいブロックの幅（ｗｉｄｔｈ）又は高さ（ｈｅｉｇｈｔ）の最大値は、ＭａｘＴｓＳｉｚｅであってよい。したがって、ブロックの幅がＭａｘＴｓＳｉｚｅ以下であり、ブロックの高さがＭａｘＴｓＳｉｚｅ以下である場合、変換スキップは用いられてよい。一方、ブロックの幅がＭａｘＴｓＳｉｚｅよりも大きいか、ブロックの高さがＭａｘＴｓＳｉｚｅよりも大きい場合には、変換スキップは用いられなくてよい。変換（ｔｒａｎｓｆｏｒｍ）はＴＵレベルで行われるため、ブロックの幅と高さは変換ブロックの幅と高さであってよい。このとき、変換ブロックの幅はｔｂＷｉｄｔｈ、変換ブロックの高さはｔｂＨｅｉｇｈｔと記述されてよい。ＢＤＰＣＭは変換スキップを使用するので、ＢＤＰＣＭの使用可否は、ＭａｘＴｓＳｉｚｅに基づいて決定されてよい。また、ＢＤＰＣＭの使用可否は、ＣＵレベルでシグナルされてよい。したがって、ＢＤＰＣＭの使用可否は、コーディングブロック（ｃｏｄｉｎｇ ｂｌｏｃｋ，ＣＢ）の幅及び高さ（ｃｂＷｉｄｔｈ及びｃｂＨｅｉｇｈｔと記述されてもよい。）とＭａｘＴｓＳｉｚｅに基づいて決定されてよい。例えば、ｃｂＷｉｄｔｈがＭａｘＴｓＳｉｚｅ以下であり、ｃｂＨｅｉｇｈｔがＭａｘＴｓＳｉｚｅ以下である場合、ＢＤＰＣＭは使用可能であってよい。ｃｂＷｉｄｔｈがＭａｘＴｓＳｉｚｅよりも大きいか、ｃｂＨｅｉｇｈｔがＭａｘＴｓＳｉｚｅよりも大きい場合には、ＢＤＰＣＭは使用可能でなくてよい。図２８を参照すると、ｃｂＷｉｄｔｈ＜＝ＭａｘＴｓＳｉｚｅであり、ｃｂＨｅｉｇｈｔ＜＝ＭａｘＴｓＳｉｚｅである場合、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇはパースされてよく、ｃｂＷｉｄｔｈ＞ＭａｘＴｓＳｉｚｅであるか、ｃｂＨｅｉｇｈｔ＞ＭａｘＴｓＳｉｚｅである場合、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇはパースされなくてよい。このとき、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇが存在しない場合、その値は０と推論（ｉｎｆｅｒ）されてよい。

【0253】

本発明の一実施例によれば、ＭａｘＴｓＳｉｚｅは、複数の値のいずれか一つの値が選択されて用いられてよい。例えば、ＭａｘＴｓＳｉｚｅは３２以下の値であってよい。または、ＭａｘＴｓＳｉｚｅは、ＭａｘＴｂＳｉｚｅＹ以下の値であってよい。または、ＭａｘＴｓＳｉｚｅは、３２、１６、８、４のいずれか一つであってよい。また、ＭａｘＴｓＳｉｚｅを決定するためのシンタックス要素が存在してよい。例えば、Ｌｏｇ２（ＭａｘＴｓＳｉｚｅ）に基づく値がシグナルされてよい。ｌｏｇ２＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｍａｘ＿ｓｉｚｅ＿ｍｉｎｕｓＮがシグナルされてよく、ＭａｘＴｓＳｉｚｅは（１＜＜（ｌｏｇ２＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｍａｘ＿ｓｉｚｅ＿ｍｉｎｕｓＮ＋Ｎ））であってよい。具体的に、Ｎは２であってよく、この場合、ｌｏｇ２＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｍａｘ＿ｓｉｚｅ＿ｍｉｎｕｓ２がシグナルされ、ＭａｘＴｓＳｉｚｅは（１＜＜（ｌｏｇ２＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｍａｘ＿ｓｉｚｅ＿ｍｉｎｕｓ２＋２））であってよい。このとき、ｌｏｇ２＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｍａｘ＿ｓｉｚｅ＿ｍｉｎｕｓ２は、０から３までの範囲の値であってよく、この場合、ＭａｘＴｓＳｉｚｅは、４、８、１６、３２のいずれか一つの値であってよい。ＭａｘＴｓＳｉｚｅを決定するためのシンタックス要素は、上位レベルでシグナルされてよい。例えば、ピクチャーパラメータセット（ｐｉｃｔｕｒｅ ｐａｒａｍｅｔｅｒ ｓｅｔ）又はスライスレベルでシンタックス要素はシグナルされてよい。

【0254】

図２９は、本発明の一実施例に係るＢＤＰＣＭ使用可能条件を示す図である。

【0255】

図２８を参照すると、コーディングブロックの幅（ｃｂＷｉｄｔｈ）及び高さ（ｃｂＨｅｉｇｈｔ）がＭａｘＴｓＳｉｚｅ以下である場合、ＢＤＰＣＭは使用可能であった。ＭａｘＴｂＳｉｚｅＹがＭａｘＴｓＳｉｚｅよりも大きく、コーディングブロックの幅及び高さがＭａｘＴｓＳｉｚｅ以下であれば、コーディングブロックの幅及び高さは、変換ブロックの幅及び高さと同一であってよい。このような場合にはＴＵ分割が発生しないわけである。具体的に、ＭａｘＴｂＳｉｚｅＹが６４であり、ＭａｘＴｓＳｉｚｅが３２以下である場合、ｃｂＷｉｄｔｈがＭａｘＴｓＳｉｚｅ以下であり、ｃｂＨｅｉｇｈｔがＭａｘＴｓＳｉｚｅ以下であれば、ｃｂＷｉｄｔｈはｔｂＷｉｄｔｈと同一であり、ｃｂＨｅｉｇｈｔはｔｂＨｅｉｇｈｔと同一であってよい。したがって、ｃｂＷｉｄｔｈ及びｃｂＨｅｉｇｈｔがＭａｘＴｓＳｉｚｅ以下の時にＢＤＰＣＭが使用可能であることは、ｔｂＷｉｄｔｈ及びｔｂＨｅｉｇｈｔがＭａｘＴｓＳｉｚｅ以下の時にＢＤＰＣＭが使用可能であることと同じ意味であってよい。

【0256】

しかし、本発明の一実施例によれば、ＭａｘＴｂＳｉｚｅＹは、ＭａｘＴｓＳｉｚｅと同一であるか小さくてよい。このとき、ｃｂＷｉｄｔｈがＭａｘＴｓＳｉｚｅよりも大きいか、ｃｂＨｅｉｇｈｔがＭａｘＴｓＳｉｚｅよりも大きいと、ＢＤＰＣＭは使用可能である。このような場合にＴＵ分割が発生することがあり、ＴＵ分割後の変換ブロックの幅及び高さはＭａｘＴｓＳｉｚｅ以下であるためである。ＭａｘＴｂＳｉｚｅＹがＭａｘＴｓＳｉｚｅと同一である場合、ｃｂＷｉｄｔｈがＭａｘＴｓＳｉｚｅよりも大きいか、ｃｂＨｅｉｇｈｔがＭａｘＴｓＳｉｚｅよりも大きいと、ＴＵ分割が発生することがあり、ＴＵ分割後の変換ブロックが幅及び高さはＭａｘＴｂＳｉｚｅＹと同一であってよい。したがって、ＢＤＰＣＭである場合に使用されるモードである変換スキップモード（ｔｒａｎｓｆｏｒｍ ｓｋｉｐ ｍｏｄｅ）を行うことが可能である。変換スキップモードはＴＵレベルで行われるためである。ＢＤＰＣＭが使用可能な場合に、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇはパースされてよい。

【0257】

したがって、ＭａｘＴｂＳｉｚｅＹとＭａｘＴｓＳｉｚｅとが同一である場合にもＢＤＰＣＭは使用可能である。または、ＢＤＰＣＭが使用可能か否かを示す上位レベルでシグナルされるシンタックス要素が、ＢＤＰＣＭが使用可能であることを示し、ＭａｘＴｂＳｉｚｅＹとＭａｘＴｓＳｉｚｅとが同一である場合、ＢＤＰＣＭは使用可能である。または、ＭａｘＴｂＳｉｚｅＹとＭａｘＴｓＳｉｚｅとが異なる場合にも、ｃｂＷｉｄｔｈがＭａｘＴｓＳｉｚｅ以下であり、ｃｂＨｅｉｇｈｔがＭａｘＴｓＳｉｚｅ以下である場合に、ＢＤＰＣＭは使用可能である。または、ＢＤＰＣＭが使用可能か否かを示す上位レベルでシグナルされるシンタックス要素が、ＢＤＰＣＭが使用可能であることを示し、ＭａｘＴｂＳｉｚｅＹとＭａｘＴｓＳｉｚｅとが異なる場合、ｃｂＷｉｄｔｈがＭａｘＴｓＳｉｚｅ以下であり、ｃｂＨｅｉｇｈｔがＭａｘＴｓＳｉｚｅ以下である場合に、ＢＤＰＣＭは使用可能である。一方、ＭａｘＴｂＳｉｚｅＹとＭａｘＴｓＳｉｚｅとが異なる場合、ｃｂＷｉｄｔｈがＭａｘＴｓＳｉｚｅよりも大きいか、ｃｂＨｅｉｇｈｔがＭａｘＴｓＳｉｚｅよりも大きい場合には、ＢＤＰＣＭが使用できない。

【0258】

ＢＤＰＣＭが使用可能なとき、ＢＤＰＣＭの使用可否を示すシンタックス要素であるｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇはパースされてよい。

【0259】

上述した通り、ＭａｘＴｂＳｉｚｅＹは３２以上の値を有してよい。具体的に、ＭａｘＴｂＳｉｚｅＹは、３２又は６４の値を有してよい。また、ＭａｘＴｓＳｉｚｅは３２以下の値を有してよい。具体的に、ＭａｘＴｓＳｉｚｅは４又は８又は１６又は３２の値を有してよい。したがって、ＭａｘＴｂＳｉｚｅＹとＭａｘＴｓＳｉｚｅとが同一である場合は、ＭａｘＴｂＳｉｚｅＹが３２であり、ＭａｘＴｓＳｉｚｅが３２である場合であってよい。

【0260】

図２９（ａ）及び（ｂ）は、上述した実施例に関連したシンタックス構造を示す図である。

【0261】

図２９（ａ）を参照すると、ｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１であり、次の２つの条件のうち少なくとも一つを満たすとき、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇはパースされてよい。

【0262】

条件ａ－１）ｃｂＷｉｄｔｈ＜＝ＭａｘＴｓＳｉｚｅ＆＆ｃｂＨｅｉｇｈｔ＜＝ＭａｘＴｓＳｉｚｅ

【0263】

条件ａ－２）ＭａｘＴｂＳｉｚｅＹ＝＝３２＆＆ＭａｘＴｓＳｉｚｅ＝＝３２

【0264】

一方、条件ａ－１、ａ－２の両方を満たさないと、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇはパースされなくてよい。一方、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇが存在しない場合、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇの値は０と推論（ｉｎｆｅｒ）されてよい。

【0265】

図２９（ｂ）を参照すると、ｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１であり、次の２つの条件のうち少なくとも一つを満たすとき、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇはパースされてよい。

【0266】

条件ｂ－１）ｃｂＷｉｄｔｈ＜＝ＭａｘＴｓＳｉｚｅ＆＆ｃｂＨｅｉｇｈｔ＜＝ＭａｘＴｓＳｉｚｅ

【0267】

条件ｂ－２）ＭａｘＴｂＳｉｚｅＹ＝＝ＭａｘＴｓＳｉｚｅ

【0268】

一方、条件ｂ－１、ｂ－２の両方を満たさないと、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇはパースされなくてよい。一方、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇが存在しない場合、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇの値は０と推論（ｉｎｆｅｒ）されてよい。

【0269】

図３０は、本発明の一実施例に係るＣＩＩＰとイントラ予測を示す図である。

【0270】

ＣＩＩＰは、ｃｏｍｂｉｎｅｄ ｉｎｔｅｒ－ａｎｄ ｉｎｔｒａ－ｐｒｅｄｉｃｔｉｏｎ又はｃｏｍｂｉｎｅｄ ｉｎｔｅｒ－ｐｉｃｔｕｒｅ ｍｅｒｇｅ ａｎｄ ｉｎｔｒａ－ｐｉｃｔｕｒｅ ｐｒｅｄｉｃｔｉｏｎの略称である。ＣＩＩＰは、予測信号（ｐｒｅｄｉｃｔｉｏｎ ｓｉｇｎａｌ）が生成するとき、イントラ予測信号（ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ ｓｉｇｎａｌ）とインター予測信号（ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎ ｓｉｇｎａｌ）とを結合する方法を意味する。ＣＩＩＰが用いられるとき、イントラ予測（ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）方法又はインター予測（ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎ）方法は制限的であってよい。例えば、ＣＩＩＰが用いられるとき、イントラ予測モード（ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ ｍｏｄｅ）は、平面モード（ｐｌａｎａｒ ｍｏｄｅ）（ＭＯＤＥ＿ＰＬＡＮＡＲ）のみが用いられるか、マージモード（ｍｅｒｇｅ ｍｏｄｅ）のみが用いられてよい。コーディングブロック（ｃｏｄｉｎｇ ｂｌｏｃｋ，ＣＢ）又はコーディングユニット（ｃｏｄｉｎｇ ｕｎｉｔ，ＣＵ）にＣＩＩＰが用いられる場合、コーディングブロック全体に対してイントラ予測が行われてよい。すなわち、ＣＢ又はＣＵにＣＩＩＰが用いられる場合、（ｃｂＷｉｄｔｈ ｘｃｂＨｅｉｇｈｔ）サイズを有するブロックに対してイントラ予測が行われてよい。言い換えると、ＣＢ又はＣＵにＣＩＩＰが用いられる場合、ＴＵ分割無しでイントラ予測が行われてよい。ＣＢが最大変換サイズ（ｍａｘｉｍｕｍ ｔｒａｎｓｆｏｒｍ ｓｉｚｅ）よりも大きくても、ＣＩＩＰが用いられるとＴＵ分割無しでイントラ予測が行われてよい。

【0271】

ＣＩＩＰが使用されてよいブロックサイズは制限的であってよい。このとき、制限されるブロックサイズは、固定された値であってよい。ＣＩＩＰが使用されてよいブロックサイズの最大値があらかじめ定められていてよい。例えば、ブロックの幅（ｃｂＷｉｄｔｈ）又は高さ（ｃｂＨｅｉｇｈｔ）が１２８であるか、１２８以上である場合、ＣＩＩＰは用いられなくてよい。ｃｂＷｉｄｔｈが１２８よりも小さく、ｃｂＨｅｉｇｈｔが１２８よりも小さく、ｃｂＷｉｄｔｈ＊ｃｂＨｅｉｇｈｔが６４以上である場合、ＣＩＩＰは用いられてよい。

【0272】

図３０は、ＣＢ又はＣＵが６４×６４である場合にＣＩＩＰモードとイントラ予測モードについて示している。ＣＩＩＰモードが用いられる場合、６４×６４サイズのブロックに対するインター予測と、６４×６４サイズのブロックに対するイントラ予測が行われてよい。また、前記インター予測と前記イントラ予測に基づいて６４×６４サイズの予測ブロック（ｐｒｅｄｉｃｔｅｄ ｂｌｏｃｋ、図３０の“Ｃｏｍｂｉｎｅｄ ｉｎｔｅｒ ａｎｄ ｉｎｔｒａ ｐｒｅｄｉｃｔｅｄ ｂｌｏｃｋ”）を生成することができる。

【0273】

イントラ予測モードが使用されない場合（すなわち、現在ピクチャーのみ使用される場合、又は参照ピクチャー（ｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ）が使用されない場合、又はＣｕＰｒｅｄＭｏｄｅがＭＯＤＥ＿ＩＮＴＲＡである場合）、６４×６４サイズのＣＢから分割されるＴＢは、ＭａｘＴｂＳｉｚｅＹに基づいて決定されてよい。例えば、ＭａｘＴｂＳｉｚｅＹが６４よりも小さい場合（例えば、３２である場合）、６４×６４サイズのＣＢは、３２×３２サイズのＴＵに分割されてよく、分割されたＴＵに対してそれぞれイントラ予測が行われてよい。したがって、３２×３２サイズの予測されたブロック（ｐｒｅｄｉｃｔｅｄ ｂｌｏｃｋ）は、４個生成されてよい。

【0274】

このとき、ＣＩＩＰモードでのイントラ予測とイントラ予測モードでのイントラ予測が互いに整列（ａｌｉｇｎ）されないという問題があり得る。言い換えると、ＣＩＩＰモードが用いられる場合、イントラ予測は、３２×３２サイズよりも大きいブロックに対して行われてよく、イントラ予測モードでのイントラ予測は、３２×３２サイズ以下のブロックに対して行われてよい。したがって、イントラ予測モードの場合、３２×３２サイズ以下のブロックに対するイントラ予測を処理できる能力（ｃａｐａｂｉｌｉｔｙ）を有するハードウェア、ソフトウェアが必要であるが、ＣＩＩＰモードの場合、３２×３２サイズよりも大きいイントラ予測を処理できる能力を有するハードウェア、ソフトウェアが必要である。これは、具現側面において大きな負担となり得る。例えば、あるエンコーダ（ｅｎｃｏｄｅｒ）は、最大変換サイズを６４ではなく３２に制限し、小さいサイズのブロックに対してイントラ予測を行うことで、ハードウェア、ソフトウェアの負担を減らしたいものの、ＣＩＩＰモードを使用するには３２よりも大きいサイズのブロックに対するイントラ予測を準備しなければならないことがある。

【0275】

図３１は、本発明の一実施例に係るマージデータシンタックスを示す図である。

【0276】

本発明の一実施例をよれば、マージモードシグナリング（ｍｅｒｇｅ ｍｏｄｅ ｓｉｇｎａｌｉｎｇ）方法としてグルーピング（ｇｒｏｕｐｉｎｇ）方法が用いられてよい。例えば、ｇｒｏｕｐ＿１＿ｆｌａｇがシグナルされてよく、デコーダはｇｒｏｕｐ＿１＿ｆｌａｇに基づき、選択されるモードがグループ１（ｇｒｏｕｐ１）に属するか否かが決定できる。ｇｒｏｕｐ＿１＿ｆｌａｇが、グループ１（ｇｒｏｕｐ １）でないことを示す場合、ｇｒｏｕｐ＿２＿ｆｌａｇがシグナルされてよい。また、デコーダは、ｇｒｏｕｐ＿２＿ｆｌａｇに基づき、選択されるモードがグループ２（ｇｒｏｕｐ２）に属するか否かが決定できる。このような動作は、複数のグループ（ｇｒｏｕｐ）が存在する場合にも行われてよい。また、グループ内のモードを示すシグナリングが存在してよい。グルーピング方法は、順次にシグナルする方法に比べて、シグナリングの深さ（ｄｅｐｔｈ）を減らすことができる。また、シグナリングの最大長（例えば、コードワード（ｃｏｄｅｗｏｒｄ）の最大長）を減らすことができる。

【0277】

以下では、グルーピング方法について具体的に説明する。

【0278】

まず、３個のグループが存在すると仮定する。特定グループは一つ以上のモードを含むことができる。例えば、グループ１に含まれるモードは１個であってよい。また、グループ２とグループ３に含まれるモードはそれぞれ２個であってよい。グループ１にサブブロックマージモード（ｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｍｏｄｅ）が含まれ、グループ２にレギュラーマージモード（ｒｅｇｕｌａｒ ｍｅｒｇｅ ｍｏｄｅ）とＭＭＶＤ（Ｍｅｒｇｅ ｗｉｔｈ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｄｉｆｆｅｒｅｎｃｅ）が含まれ、グループ３にはＣＩＩＰと三角マージモード（ｔｒｉａｎｇｌｅ ｍｅｒｇｅ ｍｏｄｅ）が含まれてよい。ｇｒｏｕｐ＿１＿ｆｌａｇは、ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇ、ｇｒｏｕｐ＿２＿ｆｌａｇは、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇであってよい。また、ｇｒｏｕｐ内のモードを示すシンタックス要素としてｃｉｉｐ＿ｆｌａｇとｍｍｖｄ＿ｍｅｒｇｅ＿ｆｌａｇが存在してよい。一実施例において、ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇがシグナルされ、ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇに基づいて現在モードがサブブロックマージモードか否かが決定されてよい。このとき、サブブロックマージモードでない場合、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇがシグナルされてよい。デコーダは、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇに基づき、モードがグループ２（レギュラーマージモード又はＭＭＶＤ）に含まれるか、グループ３（ＣＩＩＰ又は三角マージモード）に含まれるかが決定できる。このとき、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇがグループ２を示す場合、ｍｍｖｄ＿ｍｅｒｇｅ＿ｆｌａｇに基づいて現在モードがレギュラーマージモードか、ＭＭＶＤかが決定されてよい。一方ねｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇがグループ３を示す場合、ｃｉｉｐ＿ｆｌａｇに基づき、現在モードがＣＩＩＰか三角マージモードかが決定されてよい。

【0279】

図３１を参照すると、マージモード（ｍｅｒｇｅ ｍｏｄｅ）が用いられる場合、ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇがシグナルされてよい。マージモードが用いられる場合の一実施例は、上述した通りであってよく、ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇが１である場合であってよい。また、本発明は、ＣｕＰｒｅｄＭｏｄｅがＭＯＤＥ＿ＩＢＣでない場合、又はＣｕＰｒｅｄＭｏｄｅがＭＯＤＥ＿ＩＮＴＥＲである場合に適用されてよい。デコーダは、ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇをＭａｘＮｕｍＳｕｂｂｌｏｃｋＭｅｒｇｅＣａｎｄ、ブロックサイズ（ｂｌｏｃｋ ｓｉｚｅ）に基づいてパースするかどうか決定できる。ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇの値が１である場合、デコーダは、サブブロックマージモード（ｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｍｏｄｅ）を使用すると決定でき、さらに、ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｉｄｘに基づいてｃａｎｄｉｄａｔｅ ｉｎｄｅｘを決定できる。ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇの値が０である場合、デコーダは、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースすることができる。このとき、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇがパースされるための条件が存在してよい。例えば、ブロックサイズに基づく条件があり得る。また、モードの使用可否を示す上位レベルでシグナルされるシンタックス要素に基づく条件があり得る。このとき、モードの使用可否を示す上位レベルでシグナルされるシンタックス要素は、ｓｐｓ＿ｃｉｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇ、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇがあり得る。このとき、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、デコーダが三角モード（ｔｒｉａｎｇｌｅ ｍｏｄｅ）を使用できるか否かを示す上位レベルでシグナルされるシンタックス要素であってよく、シーケンスパラメータセット（ｓｅｑｕｅｎｃｅ ｐａｒａｍｅｔｅｒ ｓｅｔ）でシグナルされてよい。また、スライス類型（ｓｌｉｃｅ ｔｙｐｅ）に基づく条件があり得る。また、ｃｕ＿ｓｋｉｐ＿ｆｌａｇに基づく条件があり得る。このとき、ｃｕ＿ｓｋｉｐ＿ｆｌａｇは、スキップモード（ｓｋｉｐ ｍｏｄｅ）の使用可否を示すシンタックス要素であってよい。スキップモードが用いられる場合、レジデュアル信号（ｒｅｓｉｄｕａｌ ｓｉｇｎａｌ）はシグナルされなくてよい。したがって、スキップモードが用いられる場合、デコーダはレジデュアル信号（ｒｅｓｉｄｕａｌ ｓｉｇｎａｌ）（又は、変換係数（ｔｒａｎｓｆｏｒｍ ｃｏｅｆｆｉｃｉｅｎｔ））無しで予測信号（ｐｒｅｄｉｃｔｉｏｎ ｓｉｇｎａｌ）からブロックを復元できる。

【0280】

ＣＩＩＰが使用されてよいブロックサイズ（ｂｌｏｃｋ ｓｉｚｅ）に関連した条件は、ブロックの幅（ｗｉｄｔｈ）＊ブロックの高さ（ｈｅｉｇｈｔ）が６４以上であり、ブロックの幅が１２８よりも小さく、ブロックの高さが１２８よりも小さいということであってよい。また、三角マージモードが使用されてよいブロックサイズ条件は、ブロックの幅（ｗｉｄｔｈ）＊ブロックの高さ（ｈｅｉｇｈｔ）が６４以上であるということであってよい。図３１を参照すると、ブロックの幅（ｗｉｄｔｈ）＊ブロックの高さ（ｈｅｉｇｈｔ）が６４以上である条件を満たさない場合、デコーダは、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースしなくてよい。また、ブロックの幅（ｗｉｄｔｈ）が１２８と同一である（又は、以上である）か、ブロックの高さ（ｈｅｉｇｈｔ）が１２８と同一である（又は、以上である）場合、デコーダはｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースすることができる。

【0281】

具体的に、ｉ）ｓｐｓ＿ｃｉｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１であり、ｃｕ＿ｓｋｉｐ＿ｆｌａｇの値が０であり、ブロックの幅（ｗｉｄｔｈ）が１２８よりも小さく、ブロックの高さ（ｈｅｉｇｈｔ）が１２８よりも小さいとき、ブロックの幅（ｗｉｄｔｈ）＊ブロックの高さ（ｈｅｉｇｈｔ）が６４以上である場合を満たすと、デコーダはｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースすることができる。または、ｉｉ）ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１であり、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄの値が１よりも大きく、ｓｌｉｃｅ＿ｔｙｐｅがＢであるとき、ブロックの幅（ｗｉｄｔｈ）＊ブロックの高さ（ｈｅｉｇｈｔ）が６４以上である場合を満たすと、デコーダはｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースすることができる。

【0282】

一方、上述したｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇがパースされる条件を満たさない場合、すなわち、ｉ）ｓｐｓ＿ｃｉｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１であり、ｃｕ＿ｓｋｉｐ＿ｆｌａｇの値が０であり、ブロックの幅（ｗｉｄｔｈ）が１２８よりも小さく、ブロックの高さ（ｈｅｉｇｈｔ）が１２８よりも小さい場合を満たさなく、ｉｉ）ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１であり、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄの値が１よりも大きく、ｓｌｉｃｅ＿ｔｙｐｅがＢである場合を満たさない場合に、デコーダはｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースしなくてよい。このとき、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄは、三角（マージ）モード（ｔｒｉａｎｇｌｅ（ｍｅｒｇｅ）ｍｏｄｅ）に使用可能な候補（ｃａｎｄｉｄａｔｅ）の最大（ｍａｘｉｍｕｍ）個数であってよい。また、ｓｌｉｃｅ＿ｔｙｐｅは、スライス類型（ｓｌｉｃｅ ｔｙｐｅ）を示すシグナリングであってよい。ｓｌｉｃｅ＿ｔｙｐｅがＢであると、両方向予測（ｂｉ－ｐｒｅｄｉｃｔｉｏｎ）が用いられてよいことを示す。ｓｌｉｃｅ＿ｔｙｐｅがＰであると、両方向予測（ｂｉ－ｐｒｅｄｉｃｔｉｏｎ）は用いられず、単方向予測（ｕｎｉ－ｐｒｅｄｉｃｔｉｏｎ）が用いられてよいことを示す。ｓｌｉｃｅ＿ｔｙｐｅがＰ又はＢであると、インター予測（ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎ）が用いられてよいことを示す。ｓｌｉｃｅ＿ｔｙｐｅがＩであると、インター予測が用いられなくてよいことを示す。

【0283】

また、図３１を参照すると、デコーダがｃｉｉｐ＿ｆｌａｇをパースするか否か決定するとき、ブロックサイズに基づく条件が用いられてよい。例えば、ブロックの幅（ｗｉｄｔｈ）が１２８よりも小さく、ブロックの高さ（ｈｅｉｇｈｔ）が１２８よりも小さい場合、デコーダはｃｉｉｐ＿ｆｌａｇをパースすることができる。一方、ブロックの幅（ｗｉｄｔｈ）が１２８である（又は、１２８以上である）か、ブロックの高さ（ｈｅｉｇｈｔ）が１２８である（又は、１２８以上である）場合、デコーダはｃｉｉｐ＿ｆｌａｇをパースしなくてよい。ブロックの幅（ｗｉｄｔｈ）又はブロックの高さ（ｈｅｉｇｈｔ）が１２８である（又は、１２８以上である）場合、ＣＩＩＰと三角マージモード（ｔｒｉａｎｇｌｅ ｍｅｒｇｅ ｍｏｄｅ）のいずれか一つしか使用できないためである。例えば、ＣＩＩＰは使用できず、三角マージモードだけが用いられてよい。

【0284】

本発明において、ｃｉｉｐ＿ｆｌａｇがパースされてよいということは、ＣＩＩＰが用いられてよいことを意味できる。または、ｃｉｉｐ＿ｆｌａｇがパースされてよいということは、ＣＩＩＰ又は三角マージモードが用いられてよいことを意味できる。

【0285】

ＣＩＩＰが使用されてよい条件は、ｓｐｓ＿ｃｉｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１であり、ｃｕ＿ｓｋｉｐ＿ｆｌａｇの値が０である場合を含むことができる。また、ＣＩＩＰが使用されてよいブロックサイズに関連した条件は、ブロックの幅（ｗｉｄｔｈ）＊ブロックの高さ（ｈｅｉｇｈｔ）が６４以上であり、ブロックの幅（ｗｉｄｔｈ）は１２８よりも小さく、ブロックの高さ（ｈｅｉｇｈｔ）は１２８よりも小さい場合を含むことができる。

【0286】

三角マージモードが使用されてよい条件は、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１であり、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄの値が１よりも大きく、ｓｌｉｃｅ＿ｔｙｐｅがＢである場合を含むことができる。また、三角マージモードが使用されてよいブロックサイズに関連した条件は、ブロックの幅（ｗｉｄｔｈ）＊ブロックの高さ（ｈｅｉｇｈｔ）が６４以上である場合を含むことができる。

【0287】

上述したＣＩＩＰが使用されてよい条件又は上述した三角マージモードが使用されてよい条件を満たす場合、デコーダは、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースすることができる。一方、ＣＩＩＰが使用されてよい条件と三角マージモードが使用されてよい条件の両方を満たさない場合、デコーダはｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースしなくてよい。

【0288】

ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇが存在しない場合、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇの値は、１と推論（ｉｎｆｅｒ）されてよい。本発明において、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇの値が１であれば、レギュラーマージモード（ｒｅｇｕｌａｒ ｍｅｒｇｅ ｍｏｄｅ）又はＭＭＶＤが用いられてよい。したがって、上述したＣＩＩＰが使用されてよいブロックサイズに関連した条件と上述した三角マージモードが使用されてよいブロックサイズに関連した条件の両方を満たさない場合、使用可能なモードはレギュラーマージモードとＭＭＶＤであってよく、このとき、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇはパースされず、１と決定されてよい。

【0289】

また、上述したＣＩＩＰが使用されてよい条件と上述した三角マージモードが使用されてよい条件の両方を満たさない場合、使用可能なモードは、レギュラーマージモード又はＭＭＶＤであってよいので、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇはパースされず、１と推論（ｉｎｆｅｒ）されてよい。

【0290】

図３１を参照すると、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇの値が１である場合、ｓｐｓ＿ｍｍｖｄ＿ｅｎａｂｌｅｄ＿ｆｌａｇ値に基づいてシンタックス要素がパースされてよい。ｓｐｓ＿ｍｍｖｄ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、ＭＭＶＤが使用可能か否かを示す上位レベルでシグナルされるシンタックス要素であってよい。ｓｐｓ＿ｍｍｖｄ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が０である場合、ＭＭＶＤは使用されなくてよい。図３１を参照すると、ｓｐｓ＿ｍｍｖｄ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が０である場合、ｍｍｖｄ＿ｍｅｒｇｅ＿ｆｌａｇ、ｍｍｖｄ＿ｃａｎｄ＿ｆｌａｇ、ｍｍｖｄ＿ｄｉｓｔａｎｃｅ＿ｉｄｘ、ｍｍｖｄ＿ｄｉｒｅｃｔｉｏｎ＿ｉｄｘはパースされなくてよい。ｍｍｖｄ＿ｍｅｒｇｅ＿ｆｌａｇが存在しない場合、ｍｍｖｄ＿ｍｅｒｇｅ＿ｆｌａｇの値は０と推論（ｉｎｆｅｒ）されてよい。

【0291】

また、図３１を参照すると、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇの値が０であれば、上述したＣＩＩＰが使用されてよい条件と上述した三角マージモードが使用されてよい条件の両方を満たす場合、デコーダはｃｉｉｐ＿ｆｌａｇをパースすることができる。このとき、ｃｉｉｐ＿ｆｌａｇの値が１であれば、ＣＩＩＰが使用され、ｃｉｉｐ＿ｆｌａｇの値が０であれば、三角マージモードが使用されてよい。ｃｉｉｐ＿ｆｌａｇの値が０である場合、ＣＩＩＰが用いられないことを意味できる。一方、上述したＣＩＩＰが使用されてよい条件又は上述した三角マージモードが使用されてよい条件を満たさない場合、デコーダはｃｉｉｐ＿ｆｌａｇをパースしなくてよい。

【0292】

ｃｉｉｐ＿ｆｌａｇが存在しない場合、次の条件を全て満たすと、ｃｉｉｐ＿ｆｌａｇの値は１と推論（ｉｎｆｅｒ）されてよい。一方、次の条件のいずれか一つでも満たさないと、ｃｉｉｐ＿ｆｌａｇの値は０と推論（ｉｎｆｅｒ）されてよい。

【0293】

条件ｃ－１）ｓｐｓ＿ｃｉｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇ＝＝１

【0294】

条件ｃ－２）ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇ＝＝１

【0295】

条件ｃ－３）ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇ＝＝０

【0296】

条件ｃ－４）ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇ＝＝０

【0297】

条件ｃ－５）ｃｂＷｉｄｔｈ＜１２８

【0298】

条件ｃ－６）ｃｂＨｅｉｇｈｔ＜１２８

【0299】

条件ｃ－７）ｃｂＷｉｄｔｈ＊ｃｂＨｅｉｇｈｔ＞＝６４

【0300】

条件ｃ－８）ｃｕ＿ｓｋｉｐ＿ｆｌａｇ＝＝０

【0301】

ｓｐｓ＿ｃｉｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、ＣＩＩＰが用いられるか否かを示す上位レベルでシグナルされるシンタックス要素であってよい。ｓｐｓ＿ｃｉｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、シーケンスパラメータセット（ｓｅｑｕｅｎｃｅ ｐａｒａｍｅｔｅｒ ｓｅｔ）でシグナルされてよい。ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇは、マージモード（ｍｅｒｇｅ ｍｏｄｅ）の使用されるか否かを示すシンタックス要素であってよい。ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇは、サブブロックマージモード（ｓｕｂｂｌｏｃｋ ｍｅｒｇｅ ｍｏｄｅ）の使用されるか否かを示すシンタックス要素であってよい。このとき、サブブロックマージモードは、アフィンマージモード（ａｆｆｉｎｅ ｍｅｒｇｅ ｍｏｄｅ）、ＳｂＴＭＶＰ（ｓｕｂｂｌｏｃｋ－ｂａｓｅｄ ｔｅｍｐｏｒａｌ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｉｏｎ）であってよい。ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇは、既存のマージモード（例えば、レギュラーマージモード）又はＭＭＶＤ使用可否を示すシンタックス要素であってよい。

【0302】

図３２は、本発明の一実施例に係るマージデータシンタックスを示す図である。

【0303】

上述したこと通り、ＣＩＩＰが使用されてよいブロックサイズが制限的であり、このとき、ブロックサイズは固定した値であってよい。また、最大変換サイズ（ｍａｘｉｍｕｍ ｔｒａｎｓｆｏｒｍ ｓｉｚｅ）が可変的である場合、ＣＩＩＰモードでのイントラ予測（ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）とイントラ予測モード（ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ ｍｏｄｅ）でのイントラ予測が互いに整列（ａｌｉｇｎ）されないという問題がある。

【0304】

以下、このような問題を解決するための方法について、図３２を参照して説明する。図３２を参照すると、ＣＩＩＰモードが使用されてよいブロックサイズは可変的であってよい。具体的に、ＣＩＩＰモードが使用されてよいブロックサイズは、ＭａｘＴｂＳｉｚｅＹに基づき得る。例えば、ブロックの幅（ｗｉｄｔｈ）がＭａｘＴｂＳｉｚｅＹ以下であり、ブロックの高さ（ｈｅｉｇｈｔ）がＭａｘＴｂＳｉｚｅＹ以下である場合、ＣＩＩＰモードが用いられてよい。また、ブロックの幅（ｗｉｄｔｈ）がＭａｘＴｂＳｉｚｅＹよりも大きいか、ブロックの高さ（ｈｅｉｇｈｔ）がＭａｘＴｂＳｉｚｅＹよりも大きい場合、ＣＩＩＰは使用されなくてよい。このとき、ブロックの幅（ｗｉｄｔｈ）及びブロックの高さ（ｈｅｉｇｈｔ）は、コーディングブロック（ユニット）の幅及び高さであってよい。ブロックの幅及び高さがＭａｘＴｂＳｉｚｅＹに基づいて決定されることにより、ＣＩＩＰモードでのイントラ予測サイズはＭａｘＴｂＳｉｚｅＹ以下に制限され、既存イントラ予測サイズもＭａｘＴｂＳｉｚｅＹ以下に制限されるので、統一した方法、ハードウェア、ソフトウェアを用いてイントラ予測を行うことができる。これにより、ハードウェア、ソフトウェアに必要なリソースを低減できるという効果がある。ＭａｘＴｂＳｉｚｅＹが３２である場合にも、ＣＩＩＰモードでのイントラ予測と既存のイントラ予測とも３２×３２以下サイズのブロックに対して行われてよい。

【0305】

図３２を参照すると、ＣＩＩＰモードが使用されるための条件は、ｓｐｓ＿ｃｉｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１であり、ｃｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹ以下であり、ｃｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹ以下であり、ｃｂＷｉｄｔｈ＊ｃｂＨｅｉｇｈｔが６４以上であり、ｃｕ＿ｓｋｉｐ＿ｆｌａｇの値が０である場合が含まれてよい。したがって、ｓｐｓ＿ｃｉｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が０であるか、ｃｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹよりも大きいか、ｃｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹよりも大きいか、ｃｂＷｉｄｔｈ＊ｃｂＨｅｉｇｈｔが６４よりも小さいか、ｃｕ＿ｓｋｉｐ＿ｆｌａｇの値が０でない場合、ＣＩＩＰモードは使用されない。デコーダは、ＣＩＩＰモードを使用するための条件を満たす場合、ｃｉｉｐ＿ｆｌａｇをパースすることができる。また、ＣＩＩＰモードを使用するための条件を満たす場合、デコーダはｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースすることができる。また、デコーダはｃｉｉｐ＿ｆｌａｇ又はｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースするとき、追加の条件を考慮できる。また、デコーダは、ＣＩＩＰモードが使用されなくてよい場合、ｃｉｉｐ＿ｆｌａｇをパースしなくてよい。

【0306】

三角（マージ）モード（ｔｒｉａｎｇｌｅ（ｍｅｒｇｅ）ｍｏｄｅ）が使用されるための条件は、ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１であり、ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄの値が１よりも大きく、ｓｌｉｃｅ＿ｔｙｐｅがＢであり、ｃｂＷｉｄｔｈ＊ｃｂＨｅｉｇｈｔが６４以上である場合を含むことができる。

【0307】

このとき、前記ＣＩＩＰモードが使用されるための条件と前記三角（マージ）モードが使用されるための条件の両方を満たす場合、デコーダはｃｉｉｐ＿ｆｌａｇをパースすることができる。前記ＣＩＩＰモードが使用されるための条件又は前記三角（マージ）モードが使用されるための条件のいずれか一つでも満たさない場合、デコーダはｃｉｉｐ＿ｆｌａｇをパースしなくてよい。また、ｃｉｉｐ＿ｆｌａｇが存在しなく、前記ＣＩＩＰモードが使用されるための条件を満たさない場合、ｃｉｉｐ＿ｆｌａｇ値は０と推論（ｉｎｆｅｒ）されてよい。また、ｃｉｉｐ＿ｆｌａｇが存在しなく、前記ＣＩＩＰモードが使用されるための条件を満たし、ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇの値が１であり、ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇの値が０であり、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇの値が０である場合、ｃｉｉｐ＿ｆｌａｇの値は１と推論（ｉｎｆｅｒ）されてよい。

【0308】

前記ＣＩＩＰモードが使用されるための条件と前記三角（マージ）モードが使用されるための条件のいずれか一つでも満たす場合、デコーダはｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースすることができる。前記ＣＩＩＰモードが使用されるための条件と前記三角（マージ）モードが使用されるための条件の両方を満たさない場合、デコーダはｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースしなくてよい。このとき、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇが存在しないと、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇの値は、（ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇ＆＆！ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇ）と推論（ｉｎｆｅｒ）されてよい。

【0309】

図３２を参照すると、ｃｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹ以下であり、ｃｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹ以下である場合、デコーダはｃｉｉｐ＿ｆｌａｇをパースすることができる。一方、ｃｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹよりも大きいか、ｃｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹよりも大きい場合、デコーダはｃｉｉｐ＿ｆｌａｇをパースしなくてよい。ｃｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹよりも大きいか、ｃｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹよりも大きい場合、ｃｉｉｐ＿ｆｌａｇの値は０と推論（ｉｎｆｅｒ）されてよい。

【0310】

ｃｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹ以下であり、ｃｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹ以下である場合、デコーダは、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースすることができる。一方、ｉ）ｃｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹよりも大きいか、ｃｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹよりも大きく、ｉｉ）前記三角（マージ）モードが使用されるための条件を満たさない場合、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇはパースされなくてよい。

【0311】

下記の式５の条件を満たす場合、デコーダはｃｉｉｐ＿ｆｌａｇをパースすることができる。

【0312】

【数5】

【0313】

ｃｉｉｐ＿ｆｌａｇが存在しないと、次の条件を全て満たす場合、ｃｉｉｐ＿ｆｌａｇの値は１と推論（ｉｎｆｅｒ）されてよい。一方、次の条件のいずれか一つでも満たさない場合、ｃｉｉｐ＿ｆｌａｇの値は０と推論（ｉｎｆｅｒ）されてよい。

【0314】

条件ｄ－１）ｓｐｓ＿ｃｉｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇ＝＝１

【0315】

条件ｄ－２）ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇ＝＝１

【0316】

条件ｄ－３）ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇ＝＝０

【0317】

条件ｄ－４）ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇ＝＝０

【0318】

条件ｄ－５）ｃｂＷｉｄｔｈ＜＝ＭａｘＴｂＳｉｚｅＹ

【0319】

条件ｄ－６）ｃｂＨｅｉｇｈｔ＜＝ＭａｘＴｂＳｉｚｅＹ

【0320】

条件ｄ－７）ｃｂＷｉｄｔｈ＊ｃｂＨｅｉｇｈｔ＞＝６４

【0321】

条件ｄ－８）ｃｕ＿ｓｋｉｐ＿ｆｌａｇ＝＝０

【0322】

下記の式６の条件を満たす場合、デコーダはｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースすることができる。

【0323】

【数6】

【0324】

ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇが存在しない場合、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇの値は（ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇ＆＆！ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇ）と推論（ｉｎｆｅｒ）されてよい。すなわち、ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇの値が１であり、ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇの値が０である場合、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇの値は１と推論（ｉｎｆｅｒ）されてよい。一方、ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇの値が０であるか、ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇの値が１である場合、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇは０と推論（ｉｎｆｅｒ）されてよい。

【0325】

図３３は、本発明の一実施例に係るＣＩＩＰモードの実行方法を示す図である。

【0326】

図３３は、図３０で説明した問題を解決するための実施例を示す図であってよい。

【0327】

本発明の一実施例において、ＣＩＩＰモードにおけるイントラ予測は、変換ブロック（ユニット）単位で行われてよい。すなわち、ＣＩＩＰモードが使用されるとき、ＴＵ分割が行われてよい。例えば、ｃｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹよりも大きいか、ｃｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹよりも大きい場合、ＣＩＩＰモードが使用されてよく、この時にＴＵ分割がなされ、（ｔｂＷｉｄｔｈ ｘｔｂＨｅｉｇｈｔ）のブロックには（ＭａｘＴｂＳｉｚｅＹ×ＭａｘＴｂＳｉｚｅＹ）ブロック単位でイントラ予測（ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）が行われてよい。これにより、既存のイントラ予測と同じリソースを用いてＣＩＩＰモードにおけるイントラ予測の実行が可能である。

【0328】

図３３は、６４×６４サイズのＣＵにＣＩＩＰモードが使用され、ＭａｘＴｂＳｉｚｅＹが３２であるときの予測方法を示す。ＣＩＩＰモードが使用されるので、インター予測（ｉｎｔｅｒ ｐｒｅｄｉｃｔｉｏｎ）が使用された予測信号（ｐｒｅｄｉｃｔｉｏｎ ｓｉｇｎａｌ）とイントラ予測が使用された予測信号に基づいて予測信号が生成されてよい。このとき、インター予測は６４×６４サイズのＣＵに対して行われてよい。また、６４×６４サイズのブロックはＭａｘＴｂＳｉｚｅＹを超えるため、イントラ予測が行われる前にＴＵ分割がなされてよい。ＴＵ分割後のブロックは、ＭａｘＴｂＳｉｚｅＹ×ＭａｘＴｂＳｉｚｅＹサイズのブロックであってよい。すなわち、ＴＵ分割以後、複数個の３２×３２サイズのブロックが生成されてよい。また、ＴＵ分割後に生成されたブロックに対してそれぞれイントラ予測が行われてよい。

【0329】

以下、ＣＩＩＰモードが使用され、ＴＵ分割される場合、イントラ予測方法について説明する。

【0330】

ＴＵ分割後のイントラ予測は、分割後の各ＴＵと隣接した位置の参照サンプル（ｒｅｆｅｒｅｎｃｅ ｓａｍｐｌｅ）を使用することができる。ブロックと近接している参照サンプルが使用されるので、予測性能の側面で利点があり、コーディング効率（ｃｏｄｉｎｇ ｅｆｆｉｃｉｅｎｃｙ）側面でも利点がある。例えば、参照サンプルは、復元されたサンプルであってよい。ただし、このような場合、特定ＴＵに対してイントラ予測を行うためには、隣接したＴＵ（すなわち、参照サンプルの位置に該当するＴＵ）が復元されるまで待たなければならず、余分の遅延（ｌａｔｅｎｃｙ）が発生することがある。また、参照サンプルは、予測されたサンプル（ｐｒｅｄｉｃｔｅｄ ｓａｍｐｌｅ）であってよい。この場合、復元されたサンプル（ｒｅｃｏｎｓｔｒｕｃｔｅｄ ｓａｍｐｌｅ）を使用することに比べて、予測性能は低下し得るが、隣接したＴＵが完全に復元されなくても、予測が完了する場合には現在ＴＵに対する予測が始まり得る。したがって、復元されたサンプルを参照サンプル（ｒｅｆｅｒｅｎｃｅ ｓａｍｐｌｅ）として使用する場合に比べて遅延（ｌａｔｅｎｃｙ）を減らすことができる。ただし、予測されたサンプルを参照サンプルとして使用しても、遅延（ｌａｔｅｎｃｙ）に関する問題があり得る。

【0331】

ＴＵ分割後のイントラ予測は、ＴＵ分割前ＣＵと隣接した位置の参照サンプルを使用することができる。この場合には、上述した遅延（ｌａｔｅｎｃｙ）問題を解決することができる。ただし、隣接していないサンプルを使用するため、予測性能が低下し得る。また、分割されたＴＵのうち一部は、ＴＵに隣接していない参照サンプルを使用してイントラ予測が行われるため、既存のイントラ予測とは異なる位置の参照サンプルが必要であり、既存のイントラ予測とは異なるプロセスが必要である。

【0332】

ＣＩＩＰモードが使用される時にＴＵ分割が行われる場合、ＣＵのサイズが大きくてもＣＩＩＰモードにおける予測が行われてよい。ＣＩＩＰモードに含まれるイントラ予測は、サイズの大きいＣＵに対して行われてよく、ＣＩＩＰモードに含まれるイントラ予測はＴＵ分割後に、分割されて小さくなったブロックに対して行われてよいためである。したがって、ＣＩＩＰモードを使用できるブロックサイズに関連した条件は、上限がなくてもよい。すなわち、図３１及び図３２で記述されたｃｂＷｉｄｔｈは１２８よりも小さく、ｃｂＨｅｉｇｈｔは１２８よりも小さいという条件は存在しなくてもよい。したがって、ブロックサイズに対して（ｃｂＷｉｄｔｈ＊ｃｂＨｅｉｇｈｔ）が６４以上である条件を満たすと、デコーダは、ｃｉｉｐ＿ｆｌａｇ又はｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースすることができる。言い換えると、ｃｂＷｉｄｔｈが６４よりも大きいか、ｃｂＨｅｉｇｈｔが６４よりも大きいか（図３１参照）、ｃｂＷｉｄｔｈがＭａｘＴｂＳｉｚｅＹよりも大きいか、ｃｂＨｅｉｇｈｔがＭａｘＴｂＳｉｚｅＹよりも大きくても（図３２参照）、デコーダはｃｉｉｐ＿ｆｌａｇ又はｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇをパースすることができる。

【0333】

具体的に、次の条件を満たす場合、ｃｉｉｐ＿ｆｌａｇはパースされてよい。一方、次の条件のいずれか一つでも満たさない場合、ｃｉｉｐ＿ｆｌａｇはパースされなくてよい。

【0334】

条件ｅ－１）ｓｐｓ＿ｃｉｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇ＝＝１

【0335】

条件ｅ－２）ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ＝＝１

【0336】

条件ｅ－３）ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄ＞１

【0337】

条件ｅ－４）ｓｌｉｃｅ＿ｔｙｐｅ＝＝Ｂ

【0338】

条件ｅ－５）ｃｕ＿ｓｋｉｐ＿ｆｌａｇ＝＝０

【0339】

条件ｅ－６）ｃｂＷｉｄｔｈ＊ｃｂＨｅｉｇｈｔ＞＝６４

【0340】

ｃｉｉｐ＿ｆｌａｇが存在しないと、次の条件を全て満たす場合、ｃｉｉｐ＿ｆｌａｇは１と推論（ｉｎｆｅｒ）され、次の条件のいずれか一つでも満たさない場合、ｃｉｉｐ＿ｆｌａｇは０と推論（ｉｎｆｅｒ）されてよい。

【0341】

条件ｆ－１）ｓｐｓ＿ｃｉｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇ＝＝１

【0342】

条件ｆ－２）ｇｅｎｅｒａｌ＿ｍｅｒｇｅ＿ｆｌａｇ＝＝１

【0343】

条件ｆ－３）ｍｅｒｇｅ＿ｓｕｂｂｌｏｃｋ＿ｆｌａｇ＝＝０

【0344】

条件ｆ－４）ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇ＝＝０

【0345】

条件ｆ－５）ｃｂＷｉｄｔｈ＊ｃｂＨｅｉｇｈｔ＞＝６４

【0346】

条件ｆ－６）ｃｕ＿ｓｋｉｐ＿ｆｌａｇ＝＝０

【0347】

次の条件を全て満たす場合、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇはパースされてよい。一方、次の条件のいずれか一つでも満たさない場合、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇはパースされなくてよい。

【0348】

条件ｇ－１）ｃｂＷｉｄｔｈ＊ｃｂＨｅｉｇｈｔ＞＝６４

【0349】

条件ｇ－２）

【0350】

（ｓｐｓ＿ｃｉｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇ＆＆ｃｕ＿ｓｋｉｐ＿ｆｌａｇ＝＝０）｜｜（ｓｐｓ＿ｔｒｉａｎｇｌｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ＆＆ＭａｘＮｕｍＴｒｉａｎｇｌｅＭｅｒｇｅＣａｎｄ＞１＆＆ｓｌｉｃｅ＿ｔｙｐｅ＝＝Ｂ）

【0351】

ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇが存在しない場合、ｒｅｇｕｌａｒ＿ｍｅｒｇｅ＿ｆｌａｇの値は推論（ｉｎｆｅｒ）されてよいが、これは、図３１、図３２で説明したのと同一であり、省略するものとする。

【0352】

図３４は、本発明の一実施例に係るクロマＢＤＰＣＭシンタックス構造を示す図である。

【0353】

図２７～図２９で説明したＢＤＰＣＭは、クロマ成分（ｃｈｒｏｍａ ｃｏｍｐｏｎｅｎｔ）に対して行われてよい。クロマ成分に対してＢＤＰＣＭが行われることにより、特定ビデオコンテンツ（ｖｉｄｅｏ ｃｏｎｔｅｎｔｓ）に対する圧縮性能が向上し得る。本発明において、クロマブロックにＢＤＰＣＭが適用されることを、クロマＢＤＰＣＭと記述するものとする。

【0354】

クロマ成分に対してＢＤＰＣＭが行われるためには別個のシグナリング方法が必要であり、図３４で説明する。また、図３４に開示されたシンタックスは、コーディングユニットシンタックス（ｃｏｄｉｎｇ ｕｎｉｔ ｓｙｎｔａｘ）に含まれていてよい。

【0355】

ツリー類型（ｔｒｅｅＴｙｐｅ）値がＳＩＮＧＬＥ＿ＴＲＥＥであるか、ＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡである場合、図３４に開示されたシンタックス要素はパースされてよい。また、ＣｈｒｏｍａＡｒｒａｙＴｙｐｅが０でない場合に、図３４に開示されたシンタックス要素はパースされてよい。ＣｈｒｏｍａＡｒｒａｙＴｙｐｅは、ｓｅｐａｒａｔｅ＿ｃｏｌｏｕｒ＿ｐｌａｎｅ＿ｆｌａｇの値が０である場合、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃの値に設定されてよい。ＣｈｒｏｍａＡｒｒａｙＴｙｐｅはｓｅｐａｒａｔｅ＿ｃｏｌｏｕｒ＿ｐｌａｎｅ＿ｆｌａｇの値が１である場合、０に設定されてよい。このとき、ｓｅｐａｒａｔｅ＿ｃｏｌｏｕｒ＿ｐｌａｎｅ＿ｆｌａｇは、４：４：４クロマフォーマットのカラー成分（ｃｏｌｏｒ ｃｏｍｐｏｎｅｎｔ）が個別に（ｓｅｐａｒａｔｅｌｙ）コードされるか否かを示すことができる。例えば、ｓｅｐａｒａｔｅ＿ｃｏｌｏｕｒ＿ｐｌａｎｅ＿ｆｌａｇの値が０である場合、カラー成分は個別に（ｓｅｐａｒａｔｅｌｙ）コードされないことを示すことができる。ｓｅｐａｒａｔｅ＿ｃｏｌｏｕｒ＿ｐｌａｎｅ＿ｆｌａｇの値が０であり、Ｍｏｎｏｃｈｒｏｍｅでない場合、ＣｈｒｏｍａＡｒｒａｙＴｙｐｅは０でなくてよい。

【0356】

ｐｒｅｄ＿ｍｏｄｅ＿ｐｌｔ＿ｆｌａｇの値が１であり、ツリー類型（ｔｒｅｅＴｙｐｅ）がＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡである場合、‘ｐａｌｅｔｔｅ＿ｃｏｄｉｎｇ（）’が行われてよい。ｐｒｅｄ＿ｍｏｄｅ＿ｐｌｔ＿ｆｌａｇは、パレットモード（ｐａｌｅｔｔｅ ｍｏｄｅ）の使用されるか否かを示すシンタックス要素であり、‘ｐａｌｅｔｔｅ＿ｃｏｄｉｎｇ（）’は、パレットモードに関連したシンタックス要素をパースする部分であってよい。ｐｒｅｄ＿ｍｏｄｅ＿ｐｌｔ＿ｆｌａｇの値が０であるか、ツリー類型値がＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡでない場合、デコーダは、図３４の（１）以下の段階を行うことができる。

【0357】

また、ｃｕ＿ａｃｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇに基づき、図３４の（１）以下の段階が行われてよい。ｃｕ＿ａｃｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、適応的カラー変換（ａｄａｐｔｉｖｅ ｃｏｌｏｒ ｔｒａｎｓｆｏｒｍ）が適用されるか否かを示すシンタックス要素であってよい。ｃｕ＿ａｃｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１である場合、レジデュアル信号（ｒｅｓｉｄｕａｌ ｓｉｇｎａｌ）は、他のカラースペース（ｃｏｌｏｒ ｓｐａｃｅ）にコードされてよく、ｃｕ＿ａｃｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が０である場合、レジデュアル信号（ｒｅｓｉｄｕａｌ ｓｉｇｎａｌ）は元来の（ｏｒｉｇｉｎａｌ）カラースペースにコードされてよい。前記元来の（ｏｒｉｇｉｎａｌ）カラースペースは、ＹＵＶカラースペース又はＹＣｂＣｒカラースペースであってよい。前記他のカラースペース（ｃｏｌｏｒ ｓｐａｃｅ）は、ＹＣｇＣｏカラースペース又はＲＧＢカラースペース（ｃｏｌｏｒ ｓｐａｃｅ）であってよい。図３４を参照すると、ｃｕ＿ａｃｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が０である場合、図３４の（１）以下の段階が行われてよい。一方、ｃｕ＿ａｃｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１である場合、図３４の（１）以下の段階は行われなくてもよい。すなわち、ｃｕ＿ａｃｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が０である場合、デコーダは、クロマイントラ予測（ｃｈｒｏｍａ ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）に関連したシンタックス要素をパースでき、ｃｕ＿ａｃｔ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が０でない場合、デコーダは、クロマイントラ予測に関連したシンタックス要素をパースしなくてよい。

【0358】

図３４を参照すると、下記の式７の条件を満たす場合、デコーダはｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇをパースできる。

【0359】

【数7】

【0360】

ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇは、現在クロマコーディングブロック（ｃｈｒｏｍａ ｃｏｄｉｎｇ ｂｌｏｃｋ）にＢＤＰＣＭが適用されるか否かを示すシンタックス要素であってよい。例えば、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇの値が１である場合、現在クロマコーディングブロック（ｃｈｒｏｍａ ｃｏｄｉｎｇ ｂｌｏｃｋ）にＢＤＰＣＭが適用されることを示し、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇの値が０である場合、現在クロマコーディングブロックにＢＤＰＣＭが適用されないことを示すことができる。図３４を参照すると、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇをパースするための条件が存在してよい。または、ｃｈｒｏｍａ ＢＤＰＣＭを使用できる条件が存在してよい。Ｃｈｒｏｍａ ＢＤＰＣＭを使用できる条件は、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇをパースするための条件と同一であってよい。ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇがパースされるための条件は、上述した式７と同一であり、それを具体的に説明すると、次の通りである。

【0361】

条件ｈ－１）ｃｂＷｉｄｔｈ＜＝ＭａｘＴｓＳｉｚｅ

【0362】

条件ｈ－２）ｃｂＨｅｉｇｈｔ＜＝ＭａｘＴｓＳｉｚｅ

【0363】

条件ｈ－３）ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅ＿ｆｌａｇ＝＝１

【0364】

前記条件のいずれか一つでも満たさない場合、デコーダは、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇをパースしなくてよい。ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇが存在しない場合、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇの値は０と推論（ｉｎｆｅｒ）されてよい。ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇの値が１であれば、デコーダは、クロマＢＤＰＣＭに関連したシンタックスをパースすることができる。このとき、クロマＢＤＰＣＭに関連したシンタックスはｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｄｉｒ＿ｆｌａｇを含むことができる。ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｄｉｒ＿ｆｌａｇは、クロマＢＤＰＣＭの予測方向を示すフラグであってよい。例えば、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｄｉｒ＿ｆｌａｇは、クロマＢＤＰＣＭの予測方向が水平（ｈｏｒｉｚｏｎｔａｌ）か垂直（ｖｅｒｔｉｃａｌ）かを示すことができる。ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅ＿ｆｌａｇは、クロマＢＤＰＣＭが使用可能か否かを示す上位レベルでシグナルされるシンタックス要素であってよい。例えば、ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅ＿ｆｌａｇは、現在コーディングユニットを含む範囲（例えば、シーケンス、ピクチャー、スライスなどのレベル）でシグナルされてよい。ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅ＿ｆｌａｇの値が１であれば、クローナＢＤＰＣＭは使用されてよく、クロマＢＤＰＣＭが使用されるか否かを示す追加のシンタックス要素が存在してよい。ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅ＿ｆｌａｇの値が０である場合、クロマＢＤＰＣＭは使用されない。

【0365】

図３４を参照すると、デコーダが、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇをパースし、パーシングの結果、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇの値が０である場合、デコーダは、クロマイントラ予測（ｃｈｒｏｍａ ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）に関連したシンタックスをパースしない。このとき、クロマイントラ予測に関連したシンタックスは、ｃｃｌｍ＿ｍｏｄｅ＿ｆｌａｇ、ｃｃｌｍ＿ｍｏｄｅ＿ｉｄｘ、ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅなどがあり得る。このとき、ｃｃｌｍ＿ｍｏｄｅ＿ｆｌａｇは、クロマイントラ予測モード（ｃｈｒｏｍａ ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ ｍｏｄｅ）としてＣＣＬＭ（ｃｒｏｓｓ ｃｏｍｐｏｎｅｎｔ ｌｉｎｅａｒ ｍｏｄｅｌ）が使用されるか否かを示すシンタックス要素であってよい。ｃｃｌｍ＿ｍｏｄｅ＿ｆｌａｇは、クロマイントラ予測モード（ｃｈｒｏｍａ ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ ｍｏｄｅ）がＩＮＴＲＡ＿ＬＴ＿ＣＣＬＭ、ＩＮＴＲＡ＿Ｌ＿ＣＣＬＭ、ＩＮＴＲＡ＿Ｔ＿ＣＣＬＭののうち一つであるかを示すシンタックス要素であってよい。ＣｃｌｍＥｎａｂｌｅｄは、ＣＣＬＭが使用可能か否かを示す値であってよい。または、ＣｃｌｍＥｎａｂｌｅｄは、ＣＣＬＭ使用可否を示すシンタックス要素のパースされるか否かを示す値であってよい。ＣＣＬＭは、ルーマサンプルに基づくクロマ予測方法である。ｃｃｌｍ＿ｍｏｄｅ＿ｉｄｘは、ＣＣＬＭが用いられる場合にパースされてよい。ｃｃｌｍ＿ｍｏｄｅ＿ｉｄｘは、複数個のＣＣＬＭ方法のいずれの方法が用いられるか示すシンタックス要素であってよい。ＣＣＬＭが使用されない場合、デコーダはｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅをパースすることができる。このとき、ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅは、クロマサンプルのイントラ予測モードを示すシンタックス要素であってよい。具体的に、ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅはクロマ成分（ｃｈｒｏｍａ ｃｏｍｐｏｎｅｎｔ）に対する予測モード（ｐｒｅｄｉｃｔｉｏｎ ｍｏｄｅ）が平面モード（ｐｌａｎａｒ ｍｏｄｅ）（ｍｏｄｅ ｉｎｄｅｘ ０）、ＤＣモード（ｍｏｄｅ ｉｎｄｅｘ １）、垂直（ｖｅｒｔｉｃａｌ）モード（ｍｏｄｅ ｉｎｄｅｘ ５０）、水平（ｈｏｒｉｚｏｎｔａｌ）モード（ｍｏｄｅ ｉｎｄｅｘ １８）、対角モード（ｍｏｄｅ ｉｎｄｅ× ６６）、ＤＭモード（ルーマモードと同じモード）のいずれのモードが用いられるか示すシンタックス要素であってよい。

【0366】

図３４を参照すると、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇがパースされるための条件又はクロマＢＤＰＣＭが使用されてよい条件を満たしても、クロマＢＤＰＣＭが使用されないとシンタックス要素がシグナルされる場合、上述したクロマインター予測（ｃｈｒｏｍａ ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）に関連したシンタックスがパースされないため、クロマ予測モードが決定されないという問題が発生し得る。

【0367】

図３５は、本発明の一実施例に係るクロマＢＤＰＣＭシンタックス構造を示す図である。

【0368】

図３５の実施例は、図３４で説明した問題を解決するための実施例であり、重複する内容は省略するものとする。

【0369】

図３５を参照すると、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇがパースされてよい条件又はクロマＢＤＰＣＭが使用されてよい条件を満たす場合、デコーダは、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇをパースすることができる。ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇがパースされてよい条件は、図３５の（１）と同一であり、これは、上述した式７の通りである。すなわち、次の条件を全て満たす場合、クロマＢＤＰＣＭは使用されてよく、次の条件のいずれか一つでも満たさない場合、クロマＢＤＰＣＭは使用されなくてよい。また、次の条件のいずれか一つでも満たさない場合、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇが存在しなくてよい。このとき、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇが存在しないと、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇの値は０と推論（ｉｎｆｅｒ）されてよい。

【0370】

条件ｉ－１）ｃｂＷｉｄｔｈ＜＝ＭａｘＴｓＳｉｚｅ

【0371】

条件ｉ－２）ｃｂＨｅｉｇｈｔ＜＝ＭａｘＴｓＳｉｚｅ

【0372】

条件ｉ－３）ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅ＿ｆｌａｇ＝＝１

【0373】

図２９で説明したＢＤＰＣＭ適用方法がクロマＢＤＰＣＭにも適用されてよい。すなわち、コーディングブロックサイズ（ｃｂＷｉｄｔｈ、ｃｂＨｅｉｇｈｔ）がＭａｘＴｓＳｉｚｅよりも大きくても、分割されたＴＵ又はＴＢサイズがＭａｘＴｓＳｉｚｅ以下であれば、クロマＢＤＰＣＭは使用されてよい。したがって、次の条件を全て満たす場合、クロマＢＤＰＣＭは使用されてよく、次の条件のいずれか一つでも満たさない場合、クロマＢＤＰＣＭは使用されなくてよい。

【0374】

条件ｊ－１）

【0375】

（ｃｂＷｉｄｔｈ＜＝ＭａｘＴｓＳｉｚｅ＆＆ｃｂＨｅｉｇｈｔ＜＝ＭａｘＴｓＳｉｚｅ）｜｜（ＭａｘＴｂＳｉｚｅＹ＝＝ＭａｘＴｓＳｉｚｅ）

【0376】

条件ｊ－２）ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅ＿ｆｌａｇ＝＝１

【0377】

ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇの値が１であれば、デコーダは、クロマＢＤＰＣＭに関連したシンタックスをパースすることができる。このとき、クロマＢＤＰＣＭに関連したシンタックスは、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｄｉｒ＿ｆｌａｇ、ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅ＿ｆｌａｇなどがあり得る。ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｄｉｒ＿ｆｌａｇ、ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅ＿ｆｌａｇなどは、図３４で説明したのと同一であってよい。

【0378】

図３５を参照すると、デコーダは、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇをパースし、パーシングの結果、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇの値が０である場合（クロマＢＤＰＣＭが使用されない場合）、図３５の（２）以下の段階を行うことができる。すなわち、デコーダは、他のクロマイントラ予測（ｃｈｒｏｍａ ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）に関連したシンタックスをパースすることができる。他のクロマイントラ予測に関連したシンタックスは、図３４で説明したのと同一であってよい。他のクロマイントラ予測に関連したシンタックスは、ｃｃｌｍ＿ｍｏｄｅ＿ｆｌａｇ、ｃｃｌｍ＿ｍｏｄｅ＿ｉｄｘ、ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅなどがあり得る。

【0379】

ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇの値が０であり、ＣｃｌｍＥｎａｂｌｅｄの値が１である場合、デコーダは、ｃｃｌｍ＿ｍｏｄｅ＿ｆｌａｇをパースすることができる。また、ｃｃｌｍ＿ｍｏｄｅ＿ｆｌａｇの値が１であれば、デコーダはｃｃｌｍ＿ｍｏｄｅ＿ｉｄｘをパースし、ｃｃｌｍ＿ｍｏｄｅ＿ｆｌａｇの値が１でない場合、デコーダはｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅをパースすることができる。

【0380】

図３５を参照すると、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇがパースされてよい条件を満たし、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇのパーシングの結果、クロマＢＤＰＣＭが使用されないとシンタックス要素がシグナルされた場合にも、図３４とは違い、他のクロマ予測モードを決定するシンタックス要素がパースされてよいので、デコーダはクロマ予測モードを決定することができる。具体的に、ブロックの幅（ｗｉｄｔｈ）及びブロックの高さ（ｈｅｉｇｈｔ）が最大変換サイズ（ｍａｘｉｍｕｍ ｔｒａｎｓｆｏｒｍ ｓｋｉｐ ｓｉｚｅ）以下であり、クロマＢＤＰＣＭの使用可否を示す上位レベルでシグナルされるシンタックス要素が使用される場合には、デコーダは、クロマＢＤＰＣＭの使用可否を示すシンタックス要素をパースすることができる。このとき、パーシングの結果、クロマＢＤＰＣＭが使用されないことを示す場合、デコーダは、いかなるクロマイントラ予測モードを使用しなければならないかを示すシンタックス要素（例えば、ｃｃｌｍ＿ｍｏｄｅ＿ｆｌａｇ、ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅ）に基づいてクロマイントラ予測モードを決定することができる。

【0381】

図３６は、本発明の一実施例に係るＢＤＰＣＭに関連した上位レベルシンタックスを示す図である。

【0382】

上述したように、ＢＤＰＣＭの使用可否を示すシンタックス要素を含む上位レベルシンタックスが存在してよい。例えば、ＢＤＰＣＭの使用可否を示す上位レベルでシグナルされるシンタックス要素は、前述したｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇ、ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅｄ＿ｆｌａｇなどがあり得る。具体的に、ｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、ルーマ成分（ｌｕｍａ ｃｏｍｐｏｎｅｎｔ）に対するＢＤＰＣＭの使用可否を示す上位レベルでシグナルされるシンタックス要素である。また、ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、クロマ成分（ｃｈｒｏｍａ ｃｏｍｐｏｎｅｎｔ）に対するＢＤＰＣＭの使用可否を示す上位レベルでシグナルされるシンタックス要素である。このとき、ＢＤＰＣＭの使用可否を示すシンタックス要素がシグナルされる上位レベルは、シーケンスレベル（ｓｅｑｕｅｎｃｅ ｌｅｖｅｌ）、シーケンスパラメータセットレベル（ｓｅｑｕｅｎｃｅ ｐａｒａｍｅｔｅｒ ｓｅｔ，ＳＰＳ ｌｅｖｅｌ）、スライスレベル（ｓｌｉｃｅ ｌｅｖｅｌ）、ピクチャーレベル（ｐｉｃｔｕｒｅ ｌｅｖｅｌ）、ピクチャーパラメータセットレベル（ｐｉｃｔｕｒｅ ｐａｒａｍｅｔｅｒ ｓｅｔ，ＰＰＳ ｌｅｖｅｌ）であってよい。ＢＤＰＣＭの使用可否を示す上位レベルでシグナルされるシンタックス要素が、ＢＤＰＣＭが使用可能であること示す場合（例えば、値が１である場合）、ＢＤＰＣＭが使用されるか否かを示すシンタックス要素がさらに存在してよい。例えば、ＢＤＰＣＭが使用されるか否かを示すシンタックス要素は、ブロックレベル（ｂｌｏｃｋ ｌｅｖｅｌ）、コーディングユニット（ブロック）レベル（ｃｏｄｉｎｇ ｕｎｉｔ（ｂｌｏｃｋ） ｌｅｖｅｌ）に存在してよい。一方、ＢＤＰＣＭの使用可否を示す上位レベルでシグナルされるシンタックス要素が、ＢＤＰＣＭが使用できないことを示す場合（例えば、値が０である場合）、ＢＤＰＣＭが使用されるか否かを示すシンタックス要素はさらに存在しなくてよい。また、ＢＤＰＣＭの使用可否を示す上位レベルでシグナルされるシンタックス要素が存在しない場合、前記上位レベルでシグナルされるシンタックス要素の値は０と推論（ｉｎｆｅｒ）されてよい。また、ｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇの使用可否に関連したシンタックス要素は、図２８、図２９で説明したｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇであってよい。ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇは、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｌｕｍａ＿ｆｌａｇと同一であってよい。また、ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅｄ＿ｆｌａｇの使用可否に関連したシンタックス要素は、図３４、図３５で説明したｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇであってよい。

【0383】

変換スキップ（ｔｒａｎｓｆｏｒｍ ｓｋｉｐ）の使用可否を示す上位レベルでシグナルされるシンタックス要素が存在してよい。図３６を参照すると、変換スキップの使用可否を示す上位レベルでシグナルされるシンタックス要素は、ｓｐｓ＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｅｎａｌｂｅｄ＿ｆｌａｇであってよい。このとき、変換スキップの使用可否を示すシンタックス要素がシグナルされる上位レベルは、シーケンスレベル（ｓｅｑｕｅｎｃｅ ｌｅｖｅｌ）、シーケンスパラメータセットレベル（ｓｅｑｕｅｎｃｅ ｐａｒａｍｅｔｅｒ ｓｅｔ，ＳＰＳ ｌｅｖｅｌ）、スライスレベル（ｓｌｉｃｅ ｌｅｖｅｌ）、ピクチャーレベル（ｐｉｃｔｕｒｅ ｌｅｖｅｌ）、ピクチャーパラメータセットレベル（ｐｉｃｔｕｒｅ ｐａｒａｍｅｔｅｒ ｓｅｔ，ＰＰＳ ｌｅｖｅｌ）であってよい。変換スキップの使用可否を示す上位レベルでシグナルされるシンタックス要素が、変換スキップを使用できることを示す場合（例えば、値が１である場合）、変換スキップが使用されるか否かを示すシンタックス要素がさらに存在してよい。例えば、変換スキップが使用されるか否かを示すシンタックス要素は、ブロックレベル（ｂｌｏｃｋ ｌｅｖｅｌ）、コーディングユニット（ブロック）レベル（ｃｏｄｉｎｇ ｕｎｉｔ（ｂｌｏｃｋ） ｌｅｖｅｌ）レベルに存在してよい。一方、変換スキップの使用可否を示す上位レベルでシグナルされるシンタックス要素が、変換スキップを使用できないことを示す場合（例えば、値が０である場合）、変換スキップが使用されるか否かを示すシンタックス要素はさらに存在しない。変換スキップの使用可否を示す上位レベルでシグナルされるシンタックス要素が存在しない場合、前記上位レベルでシグナルされるシンタックス要素の値は０と推論（ｉｎｆｅｒ）されてよい。ｓｐｓ＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇの使用可否に関連したシンタックス要素は、図２７、図２８で説明したｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｆｌａｇであってよい。

【0384】

上述した通り、ＢＤＰＣＭが使用されるためには、変換スキップが使用される必要がある。図３６を参照すると、変換スキップの使用可否を示す上位レベルでシグナルされるシンタックス要素が、変換スキップを使用できることを示す場合、デコーダは、ＢＤＰＣＭの使用可否を示す上位レベルでシグナルされるシンタックス要素をパースすることができる。一方、変換スキップの使用可否を示す上位レベルでシグナルされるシンタックス要素が、変換スキップを使用できないことを示す場合、デコーダは、ＢＤＰＣＭの使用可否を示す上位レベルでシグナルされるシンタックス要素をパースしなくてよい。このとき、ＢＤＰＣＭの使用可否を示す上位レベルでシグナルされるシンタックス要素は、ルーマ成分（ｌｕｍａ ｃｏｍｐｏｎｅｎｔ）に関する情報とクロマ成分（ｃｈｒｏｍａ ｃｏｍｐｏｎｅｎｔ）に関する情報の両方を含むことができる。

【0385】

ｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１であれば、デコーダは、ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅｄ＿ｆｌａｇをパースすることができる。一方、ｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が０である場合、デコーダは、ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅｄ＿ｆｌａｇをパースしなくてよい。すなわち、ルーマ成分に対するＢＤＰＣＭを使用できる場合にのみ、クロマ成分に対するＢＤＰＣＭは使用可能である。

【0386】

図３６を参照すると、デコーダは、ｓｐｓ＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇをパースし、パーシングの結果、ｓｐｓ＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１であれば、ｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇをパースすることができる。デコーダは、ｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１であれば、ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅｄ＿ｆｌａｇをパースすることができる。

【0387】

図３７は、本発明の一実施例に係るＢＤＰＣＭに関する上位レベルでシグナルされるシンタックス要素を示す図である。

【0388】

図３７の実施例において図３６と重複する内容は省略するものとする。

【0389】

図３７を参照すると、クロマＢＤＰＣＭの使用可否は、クロマフォーマットに基づいて決定されてよい。カラーフォーマット（ｃｏｌｏｒ ｆｏｒｍａｔ）に関連した情報は、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃ、ｓｅｐａｒａｔｅ＿ｃｏｌｏｕｒ＿ｐｌａｎｃｅ＿ｆｌａｇ、Ｃｈｒｏｍａ ｆｏｒｍａｔ、ＳｕｂＷｉｄｔｈＣ、ＳｕｂＨｅｉｇｈｔＣなどがあり得る。具体的に、カラーフォーマットが４：４：４である場合、クロマＢＤＰＣＭは使用可能であってよい。一方、カラーフォーマットが４：４：４でない場合、クロマＢＤＰＣＭを使用可能でなくてよい。したがって、クロマＢＤＰＣＭの使用可否は、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃに基づくことができる。例えば、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃの値が３である場合、デコーダは、クロマＢＤＰＣＭの使用可否を示すシンタックス要素（ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）をパースしてよく、そうでない場合、デコーダは、クロマＢＤＰＣＭの使用可否を示すシンタックス要素（ｓｐｓ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）をパースしなくてよい。本発明において、カラーフォーマット（ｃｏｌｏｒ ｆｏｒｍａｔ）は、クロマフォーマット（ｃｈｒｏｍａ ｆｏｒｍａｔ）と同じ意味で使われてもよい。

【0390】

図３８は、本発明の一実施例に係るクロマＢＤＰＣＭに関連したシンタックスを示す図である。

【0391】

ルーマ成分（ｌｕｍａ ｃｏｍｐｏｎｅｎｔ）に対するＢＤＰＣＭの使用可否を示す上位レベルでシグナルされるシンタックス要素と、クロマ成分（ｃｈｒｏｍａ ｃｏｍｐｏｎｅｎｔ）に対するＢＤＰＣＭの使用可否を示す上位レベルでシグナルされるシンタックス要素は個別に存在しなくてよい。すなわち、一つのシンタックス要素でルーマ成分とクロマ成分の両方に対するＢＤＰＣＭが使用可能か否かが指示されてよい。例えば、ＢＤＰＣＭの使用可否を示す上位レベルでシグナルされるシンタックス要素が、ＢＤＰＣＭを使用できるこを示す場合、ルーマ成分に対するＢＤＰＣＭ又はクロマ成分に対するＢＤＰＣＭが使用可能であってよい。また、このとき、ＢＤＰＣＭが使用されるか否かを示す追加のシンタックス要素が存在してよい。例えば、前記追加のシンタックス要素は、上述したｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇ、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇであってよい。一方、ＢＤＰＣＭの使用可否を示す上位レベルでシグナルされるシンタックス要素が、ＢＤＰＣＭを使用できないことを示す場合、ルーマ成分及びクロマ成分の両方に対してＢＤＰＣＭは使用されなくてよい。

【0392】

ルーマ成分に対するＢＤＰＣＭが使用されるか否かを示すシンタックス要素とクロマ成分に対するＢＤＰＣＭが使用されるか否かを示すシンタックス要素は、ルーマ成分及びクロマ成分の両方に同一ＢＤＰＣＭの使用が可能か否か示す上位レベルでシグナルされるシンタックス要素に基づいてパースされてよい。例えば、前記同一ＢＤＰＣＭの使用可否を示すシンタックス要素がｓｐｓ＿ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇである場合、図２８及び図２９で説明したように、デコーダは、ルーマ成分に対するＢＤＰＣＭが使用されるか否かを示すシンタックス要素をパースすることができる。すなわち、ｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１である場合、デコーダは、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇをパーシングでき（このとき、追加の条件が考慮されてよい。）、ｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１でない場合、デコーダはｉｎｔｒａ＿ｂｄｐｃｍ＿ｆｌａｇをパースしなくてよい。

【0393】

図３８を参照すると、クロマ成分（ｃｈｒｏｍａ ｃｏｍｐｏｎｅｎｔ）に対するＢＤＰＣＭが使用されるか否かを示すシンタックス要素は、ｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値によって行われてよい。例えば、ｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１である場合、デコーダは、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇをパースしてよく（このとき、追加の条件が考慮されてよい。）、ｓｐｓ＿ｂｄｐｃｍ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値が１でない場合、デコーダはｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇをパースしなくてよい。

【0394】

コーディングユニット（ブロック）レベル（ｃｏｄｉｎｇ ｕｎｉｔ（ｂｌｏｃｋ） ｌｅｖｅｌ）におけるＢＤＰＣＭが使用されるか否かを示すシンタックス要素は、ルーマ成分（ｌｕｍａ ｃｏｍｐｏｎｅｎｔ）とクロマ成分に対して分離していなくてよい。すなわち、ＢＤＰＣＭが使用されるか否かを示すシンタックス要素が、ＢＤＰＣＭが使用されることを示す場合、ルーマ成分とクロマ成分の両方に対してＢＤＰＣＭは使用されてよい。一方、ＢＤＰＣＭが使用されるか否かを示すシンタックス要素が、ＢＤＰＣＭが使用されないことを示す場合、ルーマ成分とクロマ成分の両方に対してＢＤＰＣＭは使用されなくてよい。

【0395】

図３９は、本発明の実施例に係るイントラ予測に関連したシンタックスを示す図である。

【0396】

図３９を参照すると、既に設定された順序によって、複数個のイントラ予測（ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）に関連したシンタックス要素がシグナルされてよい。

【0397】

カラー成分（ｃｏｌｏｒ ｃｏｍｐｏｎｅｎｔ）別にシンタックス要素はグルーピングされ、シグナルされてよい。例えば、ルーマ成分（ｌｕｍａ ｃｏｍｐｏｎｅｎｔ）に関連したシンタックス要素がグルーピングしてシグナルされてよい。クロマ成分（ｃｈｒｏｍａ ｃｏｍｐｏｎｅｎｔ）に関連したシンタックス要素がグルーピングしてシグナルされてよい。また、ルーマ成分に関連したシンタックス要素グループ（ｓｙｎｔａｘｅｌｅｍｅｎｔ ｇｒｏｕｐ）、クロマ成分に関連したシンタックス要素グループは順にシグナルされてよい。逆に、クロマ成分に関連したシンタックス要素グループ、ルーマ成分に関連したシンタックス要素グループが順にシグナルされてよい。

【0398】

図３９を参照して、ルーマ成分（ｌｕｍａ ｃｏｍｐｏｎｅｎｔ）に関連したシンタックス要素グループ（ｓｙｎｔａｘｅｌｅｍｅｎｔ ｇｒｏｕｐ）とクロマ成分（ｃｈｒｏｍａ ｃｏｍｐｏｎｅｎｔ）に関連したシンタックス要素グループが順にシグナルされる構造について説明する。

【0399】

ルーマ成分に関連したシンタックス要素グループは、次のシンタックス要素を含むことができる。

【0400】

ｉ）ルーマ成分（ｌｕｍａ ｃｏｍｐｏｎｅｎｔ）に対するＢＤＰＣＭに関連したシンタックス要素：

【0401】

ＢＤＰＣＭの使用可否を示すシンタックス要素と予測方向を示すシンタックス要素であってよい。例えば、図３９に開示されたｉｎｔｒａ＿ｂｄｐｃｍ＿ｌｕｍａ＿ｆｌａｇ、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｌｕｍａ＿ｄｉｒ＿ｆｌａｇがそれに該当し得る。

【0402】

ｉｉ）ＭＩＰ（ｍａｔｒｉｘ－ｂａｓｅｄ ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）関連シンタックス要素：

【0403】

ＭＩＰ予測の使用可否を示すシンタックス要素、ＭＩＰ入力ベクトル（ｉｎｐｕｔ ｖｅｃｔｏｒ）がトランスポーズ（ｔｒａｎｓｐｏｓｅ）されるか否かを示すシンタックス要素、ＭＩＰモードを示すシンタックス要素を意味する。例えば、図３９に開示されたｉｎｔｒａ＿ｍｉｐ＿ｆｌａｇ、ｉｎｔｒａ＿ｍｉｐ＿ｔｒａｎｓｐｏｓｅｄ、ｉｎｔｒａ＿ｍｉｐ＿ｍｏｄｅがそれに該当し得る。

【0404】

ｉｉｉ）予測に用いられる参照ライン（ｒｅｆｅｒｅｎｃｅ ｌｉｎｅ）を示すシンタックス要素：

【0405】

イントラ予測（ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）に用いられる参照ラインの位置を示すシンタックス要素であってよい。例えば、図３９に開示されたｉｎｔｒａ＿ｌｕｍａ＿ｒｅｆ＿ｉｄｘがそれに該当し得る。

【0406】

ｉｖ）ＩＳＰ（ｉｎｔｒａ ｓｕｂ－ｐａｒｔｉｔｉｏｎ）関連シンタックス要素：

【0407】

ＩＳＰの使用されるか否かを示すシンタックス要素、ＩＳＰスプリット（ｓｐｌｉｔ）方向を示すシンタックス要素であってよい。例えば、図３９に開示されたｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｍｏｄｅ＿ｆｌａｇ、ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇがそれに該当し得る。このとき、ＩＳＰは、イントラサブパーティションモード又はブロックをサブパーティションに分けて予測する方法である。

【0408】

ｖ）イントラ予測モード（ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ ｍｏｄｅ）を示すシンタックス要素：

【0409】

ＭＰＭリスト（候補リスト（ｃａｎｄｉｄａｔｅ ｌｉｓｔ））の使用されるか否かを示すシンタックス要素、平面モード（ｐｌａｎａｒ ｍｏｄｅ）の使用されるか否かを示すシンタックス要素、ＭＰＭインデックスを示すシンタックス要素、ＭＰＭリストに含まれていないモードを示すシンタックス要素であってよい。例えば、図３９に開示されたｉｎｔｒａ＿ｌｕｍａ＿ｍｐｍ＿ｆｌａｇ、ｉｎｔｒａ＿ｌｕｍａ＿ｎｏｔ＿ｐｌａｎａｒ＿ｆｌａｇ、ｉｎｔｒａ＿ｌｕｍａ＿ｍｐｍ＿ｉｄｘ、ｉｎｔｒａ＿ｌｕｍａ＿ｍｐｍ＿ｒｅｍａｉｎｄｅｒがそれに該当し得る。

【0410】

クロマ成分（ｃｈｒｏｍａ ｃｏｍｐｏｎｅｎｔ）に関連したシンタックス要素グループ（ｓｙｎｔａｘｅｌｅｍｅｎｔ ｇｒｏｕｐ）は、次のシンタックス要素を含むことができる。

【0411】

ｉ）クロマ成分（ｃｈｒｏｍａ ｃｏｍｐｏｎｅｎｔ）ＢＤＰＣＭに関連したシンタックス要素：

【0412】

ＢＤＰＣＭの使用されるか否かを示すシンタックス要素、予測方向を示すシンタックス要素であってよい。例えば、図３９に開示されたｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇ、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｄｉｒ＿ｆｌａｇがそれに該当し得る。

【0413】

ｉｉ）ＣＣＬＭ（ｃｒｏｓｓ ｃｏｍｐｏｎｅｎｔ ｌｉｎｅａｒ ｍｏｄｅｌ）関連シンタックス要素：

【0414】

ＣＣＬＭの使用されるか否かを示すシンタックス要素、予測に用いられるＣＣＬＭモードを示すシンタックス要素であってよい。例えば、図３９に開示されたｃｃｌｍ＿ｍｏｄｅ＿ｆｌａｇ、ｃｃｌｍ＿ｍｏｄｅ＿ｉｄｘがそれに該当し得る。ＣＣＬＭは、別のカラー成分（ｃｏｌｏｒ ｃｏｍｐｏｎｅｎｔ）値に基づいて予測する方法であり、具体的に、ルーマ成分（ｌｕｍａ ｃｏｍｐｏｎｅｎｔ）値に基づいてクロマ成分（ｃｈｒｏｍａ ｃｏｍｐｏｎｅｎｔ）を予測する方法であってよい。

【0415】

ｉｉｉ）クロマイントラ予測モード（ｃｈｒｏｍａ ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ ｍｏｄｅ）に関連したシンタックス要素：

【0416】

クロマ成分（ｃｈｒｏｍａ ｃｏｍｐｏｎｅｎｔ）に対するイントラ予測モードインデックスを決定するために用いられるシンタックス要素であってよい。例えば、図３９に開示されたｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅがそれに該当し得る。

【0417】

図３９を参照すると、ツリー類型（ｔｒｅｅＴｙｐｅ）がＳＩＮＧＬＥ＿ＴＲＥＥであるか、ＤＵＡＬ＿ＴＲＥＥ＿ＬＵＭＡである場合、デコーダは、ルーマ成分（ｌｕｍａ ｃｏｍｐｏｎｅｎｔ）に関連したシンタックス要素をパースし、ツリー類型がＳＩＮＧＬＥ＿ＴＲＥＥであるか、ＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡである場合、デコーダは、クロマ成分（ｃｈｒｏｍａ ｃｏｍｐｏｎｅｎｔ）に関連したシンタックス要素をパースすることができる。したがって、デコーダは、ルーマ成分に関連したシンタックス要素グループ（ｓｙｎｔａｘｅｌｅｍｅｎｔ ｇｒｏｕｐ）を連続してパースし、クロマ成分に関連したシンタックスグループを連続してパースすることができる。

【0418】

図３９を参照すると、クロマ成分に関連したシンタックス要素であるｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇ及びｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｄｉｒ＿ｆｌａｇは、ルーマ成分に関連したシンタックス要素グループよりも後に位置してよい。したがって、ツリー類型がＳＩＮＧＬＥ＿ＴＲＥＥである場合、ルーマ成分に関連したシンタックス要素グループ後に位置しているｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇ及びｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｄｉｒ＿ｆｌａｇなどがパースされてよい。

【0419】

これにより、ルーマ成分に関連したシンタックス要素とクロマ成分に関連したシンタックス要素がそれぞれ連続して位置（パーシング）するので、メモリ管理の側面で利点がある。すなわち、具現側面で有効であり得る。

【0420】

図４０は、本発明の実施例に係るイントラ予測（ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）に関連したシンタックスを示す図である。

【0421】

図３９を参照すると、ルーマ成分（ｌｕｍａ ｃｏｍｐｏｎｅｎｔ）に関連したシンタックス要素グループ（ｓｙｎｔａｘｅｌｅｍｅｎｔ ｇｒｏｕｐ）とクロマ成分（ｃｈｒｏｍａ ｃｏｍｐｏｎｅｎｔ）に関連したシンタックス要素グループは順にパースされなくてよい。例えば、図３９を参照して説明したルーマ成分に関連したシンタックス要素グループとクロマ成分に関連したシンタックス要素グループのうち一部の順序が変わってパースされてよい。具体的に、ルーマ成分に対するＢＤＰＣＭに関連したシンタックス要素とクロマ成分に対するＢＤＰＣＭに関連したシンタックス要素は連続してパースされてよい。また、ルーマ成分に関連したシンタックス要素グループに含まれたシンタックス要素のうち、ルーマ成分に対するＢＤＰＣＭに関連したシンタックス要素を除くシンタックス要素グループと、クロマ成分に関連したシンタックス要素グループに含まれたシンタックス要素のうち、クロマ成分に対するＢＤＰＣＭに関連したシンタックス要素を除くシンタックス要素グループは、連続してパースされてよい。また、ＢＤＰＣＭに関連したシンタックス要素は他のシンタックス要素グループよりも前にパースされてよい。

【0422】

シンタックス要素がパースされる順序の一実施例は、次のようである。

【0423】

まず、ルーマ成分に対するＢＤＰＣＭに関連したシンタックス要素がパースされ、クロマ成分に対するＢＤＰＣＭに関連したシンタックス要素がパースされてよい。そして、ルーマ成分に関連したシンタックス要素グループに含まれたシンタックス要素のうち、ルーマ成分に対するＢＤＰＣＭに関連したシンタックス要素を除くシンタックス要素グループがパースされてよい。そして、クロマ成分に関連したシンタックス要素グループに含まれたシンタックス要素のうち、クロマ成分に対するＢＤＰＣＭに関連したシンタックス要素を除くシンタックス要素グループがパースされてよい。

【0424】

図４０を参照すると、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｌｕｍａ＿ｆｌａｇ、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｌｕｍａ＿ｄｉｒ＿ｆｌａｇ、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇ、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｄｉｒ＿ｆｌａｇは、ｉｎｔｒａ＿ｍｉｐ＿ｆｌａｇ、ｉｎｔｒａ＿ｍｉｐ＿ｔｒａｎｓｐｏｓｅｄ、ｉｎｔｒａ＿ｍｉｐ＿ｍｏｄｅ、ｉｎｔｒａ＿ｌｕｍａ＿ｒｅｆ＿ｉｄｘ、ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｍｏｄｅ＿ｆｌａｇ、ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇ、ｉｎｔｒａ＿ｌｕｍａ＿ｍｐｍ＿ｆｌａｇ、ｉｎｔｒａ＿ｌｕｍａ＿ｎｏｔ＿ｐｌａｎａｒ＿ｆｌａｇ、ｉｎｔｒａ＿ｌｕｍａ＿ｍｐｍ＿ｉｄｘ、ｉｎｔｒａ＿ｌｕｍａ＿ｍｐｍ＿ｒｅｍａｉｎｄｅｒ、ｃｃｌｍ＿ｍｏｄｅ＿ｆｌａｇ、ｃｃｌｍ＿ｍｏｄｅ＿ｉｄｘ、ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅよりも先に位置してよい。

【0425】

または、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｌｕｍａ＿ｆｌａｇ、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｌｕｍａ＿ｄｉｒ＿ｆｌａｇ、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｆｌａｇ、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｄｉｒ＿ｆｌａｇは、ｉｎｔｒａ＿ｍｉｐ＿ｆｌａｇ、ｉｎｔｒａ＿ｍｉｐ＿ｔｒａｎｓｐｏｓｅｄ、ｉｎｔｒａ＿ｍｉｐ＿ｍｏｄｅ、ｉｎｔｒａ＿ｌｕｍａ＿ｒｅｆ＿ｉｄｘ、ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｍｏｄｅ＿ｆｌａｇ、ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇ、ｉｎｔｒａ＿ｌｕｍａ＿ｍｐｍ＿ｆｌａｇ、ｉｎｔｒａ＿ｌｕｍａ＿ｎｏｔ＿ｐｌａｎａｒ＿ｆｌａｇ、ｉｎｔｒａ＿ｌｕｍａ＿ｍｐｍ＿ｉｄｘ、ｉｎｔｒａ＿ｌｕｍａ＿ｍｐｍ＿ｒｅｍａｉｎｄｅｒ、ｃｃｌｍ＿ｍｏｄｅ＿ｆｌａｇ、ｃｃｌｍ＿ｍｏｄｅ＿ｉｄｘ、ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅの少なくともいずれか一つよりも先に位置してよい。

【0426】

図４０を参照すると、クロマ成分（ｃｈｒｏｍａ ｃｏｍｐｏｎｅｎｔ）に対するＢＤＰＣＭに関連したシンタックス要素が、ルーマ成分（ｌｕｍａ ｃｏｍｐｏｎｅｎｔ）に関連したシンタックス要素よりも先に位置してよい。これにより、クロマＢＤＰＣＭが多く使用される場合に、シンタックス要素をパースするか否かを決定する動作／演算が減るという効果がある。

【0427】

ルーマＢＤＰＣＭとクロマＢＤＰＣＭは、予測方向を共有してよい。したがって、図４０に開示された通り、ｉｎｔｒａ＿ｂｄｐｃｍ＿ｌｕｍａ＿ｄｉｒ＿ｆｌａｇとｉｎｔｒａ＿ｂｄｐｃｍ＿ｃｈｒｏｍａ＿ｄｉｒ＿ｆｌａｇは別個に存在せず、一つのシンタックス要素によってルーマＢＤＰＣＭの予測方向とクロマＢＤＰＣＭの予測方向が指示されてよい。このとき、ルーマＢＤＰＣＭの使用されるか否かとクロマＢＤＰＣＭの使用されるか否かは、独立的でなくてよい。例えば、クロマＢＤＰＣＭが使用されるためには、ルーマＢＤＰＣＭが使用される必要がある。したがって、ルーマＢＤＰＣＭの使用されるか否かを示すシンタックス要素とクロマＢＤＰＣＭの使用されるか否かを示すシンタックス要素は、従属的（ｄｅｐｅｎｄｅｎｔ）であってよい。ルーマＢＤＰＣＭの使用されるか否かを示すシンタックス要素が、ルーマＢＤＰＣＭが使用されることを示す場合にのみ、クロマＢＤＰＣＭの使用されるか否かを示すシンタックス要素がパースされてよい。

【0428】

図４１は、本発明の一実施例に係るシーケンスパラメータセットシンタックスを示す図である。

【0429】

シーケンスパラメータセット（ｓｅｑｕｅｎｃｅ ｐａｒａｍｅｔｅｒ ｓｅｔ，ＳＰＳ）シンタックスは、ＣＶＳ（ｃｏｄｅｄ ｖｉｄｅｏ ｓｅｑｕｅｎｃｅ）に適用されるシンタックスであってよい。ＳＰＳシンタックスがＣＶＳに適用されるか否かは、スライスヘッダー（ｓｌｉｃｅ ｈｅａｄｅｒ）のシンタックス要素によって参照されるＰＰＳ（ｐｉｃｔｕｒｅ ｐａｒａｍｅｔｅｒ ｓｅｔ）のシンタックス要素値によって決定されてよい。

【0430】

図４１に開示されたシンタックス要素は、ＳＰＳシンタックス要素の一部であってよい。図４１を参照すると、ＳＰＳシンタックスは、ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ、ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ、ｓｐｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５、ｓｕｂｐｉｃｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘ、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙ、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１、ｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ、ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｕｂｐｉｃ＿ｅｎａｂｌｅｄ＿ｆｌａｇ、ｓｐｓ＿ｓｕｂｐｉｃ＿ｉｄ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｓｐｓ＿ｓｕｂｐｉｃ＿ｉｄ＿ｓｉｇｎａｌｌｉｎｇ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｓｐｓ＿ｓｕｂｐｉｃ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１、ｓｐｓ＿ｓｕｂｐｉｃ＿ｉｄなどのシンタックス要素を含むことができる。また、ＳＰＳシンタックスに含まれるシンタックス要素のうち一部は、サブピクチャーの個数だけ存在してよい。例えば、シンタックス要素ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘ、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙ、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１、ｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ、ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｕｂｐｉｃ＿ｅｎａｂｌｅｄ＿ｆｌａｇ、ｓｐｓ＿ｓｕｂｐｉｃ＿ｉｄは、サブピクチャーの個数だけ存在してよい。具体的に、このようなシンタックス要素は、ｓｙｎｔａｘＥｌｅｍｅｎｔ［Ｉ］であり、ｉは、０から（サブピクチャーの個数－１）までと表されてよい。このとき、ｓｙｎｔａｘＥｌｅｍｅｎｔは、サブピクチャーの個数だけ存在するシンタックス要素であってよい。

【0431】

サブピクチャーは、ピクチャー又はフレームよりも下位単位であってよい。例えば、ピクチャー又はフレームは、一つ以上のサブピクチャーを含むことができる。このとき、サブピクチャーは、長方形区域（ｒｅｃｔａｎｇｕｌａｒ ｒｅｇｉｏｎ）であってよい。具体的に、サブピクチャーは、ピクチャー内の一つ以上のスライスで構成される長方形区域を意味できる。また、サブピクチャーは、独立してデコードされてよい。したがって、ピクチャー内のあるサブピクチャーに関する情報のみをデコーダが受信しても、デコーダは、受信したあるサブピクチャーをデコードして復元することができる。また、ピクチャー内の複数のサブピクチャーは互いに重ならなくてよい。

【0432】

図４１を参照すると、ｓｕｂｐｉｃｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値が１である場合、デコーダは、ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘ、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙ、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１、ｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ、ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｕｂｐｉｃ＿ｅｎａｂｌｅｄ＿ｆｌａｇをパースすることができる。また、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘ、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙ、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１、ｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ、ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｕｂｐｉｃ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、それぞれ（ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１＋１）個だけパースされてよい。

【0433】

上述したＳＰＳシンタックスのシンタックス要素とサブピクチャーシグナリング方法について、図４２を用いて説明する。

【0434】

図４２は、本発明の一実施例に係るサブピクチャーに関連したシンタックス要素を示す図である。

【0435】

図４２に開示されたｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、ピクチャーの最大幅を示すシンタックス要素であり、このとき、ピクチャーの最大幅は、ルーマサンプル単位で示すことができる。ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓの値は０でなくてよく、既に設定された値の整数倍（ｉｎｔｅｇｅｒ ｍｕｌｔｉｐｌｅ）の値であってよい。前記既に設定された値は、８と最小コーディングブロックサイズ（ｍｉｎｉｍｕｍ ｃｏｄｉｎｇ ｂｌｏｃｋ ｓｉｚｅ）のうち、大きい値であってよい。このとき、最小コーディングブロックサイズは、ルーマサンプル基準で決定されてよく、ＭｉｎＣｂＳｉｚｅＹと記述されてよい。

【0436】

また、ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、ピクチャーの最大高さを示すシンタックス要素であり、このとき、ピクチャーの最大高さは、ルーマサンプル単位で示すことができる。また、ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓの値は０でなくてよく、既に設定された値の整数倍（ｉｎｔｅｇｅｒ ｍｕｌｔｉｐｌｅ）であってよい。前記既に設定された値は、８と最小コーディングブロックサイズ（ｍｉｎｉｍｕｍ ｃｏｄｉｎｇ ｂｌｏｃｋ ｓｉｚｅ）のうち、大きい値であってよい。このとき、最小コーディングブロックサイズは、ルーマサンプル基準で決定されてよく、ＭｉｎＣｂＳｉｚｅＹと記述されてよい。

【0437】

ピクチャーがサブピクチャーを使用する場合、ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ、ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、それぞれ、ピクチャーの幅、高さを示す。このとき、ピクチャーの最大幅、最大高さはそれぞれ、ピクチャーの幅、ピクチャーの高さと同一であってよい。

【0438】

ｓｐｓ＿ｌｏｇ＿２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５は、コーディングツリーユニット（ｃｏｄｉｎｇ ｔｒｅｅ ｕｎｉｔ，ＣＴＵ）のコーディングツリーブロック（ｃｏｄｉｎｇ ｔｒｅｅ ｂｌｏｃｋ，ＣＴＢ）のサイズを示すシンタックス要素であってよい。具体的に、ｓｐｓ＿ｌｏｇ＿２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５は、ルーマコーディングツリーブロックのサイズを示すことができる。また、ｓｐｓ＿ｌｏｇ＿２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５は、ルーマサンプル単位のＣＴＢサイズにｌｏｇ２を取り、既に設定された値を引いた値を有してよい。ルーマコーディングツリーブロックのサイズをＣｔｂＳｉｚｅＹとすれば、ＣｔｂＳｉｚｅＹは、（１＜＜（ｓｐｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５＋既に設定された値））であってよい。前記既に設定された値は、５であってよい。すなわち、ｓｐｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５が０、１、２のとき、ＣｔｂＳｉｚｅＹ値はそれぞれ、３２、６４、１２８であってよい。また、ｓｐｓ＿ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５値は、２以下の値であってよい。

【0439】

ｓｕｂｐｉｃｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、サブピクチャーパラメータが存在するか否かを示すシンタックス要素である。ｓｕｂｐｉｃｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、サブピクチャーを使用できるか否か、サブピクチャー個数を１よりも大きい値とシグナルできるか否かを示す。このとき、サブピクチャーパラメータは、ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘ、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙ、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１、ｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ、ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｕｂｐｉｃ＿ｅｎａｂｌｅｄ＿ｆｌａｇなどを含むことができる。

【0440】

ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１は、サブピクチャー個数を示すシンタックス要素であってよい。例えば、ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１の値に既に設定された値を足した値が、サブピクチャーの個数であってよい。このとき、既に設定された値は、１であってよい。この場合、サブピクチャーの個数は、１以上の値とシグナルされてよい。また、既に設定された値は、２であってよい。この場合、サブピクチャーの個数は２以上の値でシグナルされてよい。ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１値は、０以上２５４以下であり、８－ｂｉｔで表現されてよい。一方、ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１値が存在しない場合、ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１の値は０と推論（ｉｎｆｅｒ）されてよい。

【0441】

図４２に開示された、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘ、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙ、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１は、各サブピクチャーの位置及びサイズを示すシンタックス要素である。ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘ［ｉ］、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙ［ｉ］、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１［ｉ］、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１［Ｉ］は、ｉ番目のサブピクチャーに該当する値を示す。このとき、ｉ値は、０以上ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１の値以下であってよい。

【0442】

ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘは、サブピクチャーの左上端の位置のｘ座標（ｈｏｒｉｚｏｎｔａｌ ｐｏｓｉｔｉｏｎ）を示すことができる。具体的に、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘは、サブピクチャーの左上端のＣＴＵのｘ座標を示すことができる。このとき、座標は、ＣＴＵ単位又はＣＴＢ単位で表されてよい。例えば、座標は、ＣｔｂＳｉｚｅＹ単位で表すことができる。また、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘは、符号なし整数（ｕｎｓｉｇｎｅｄ ｉｎｔｅｇｅｒ）の値でシグナルされてよく、このとき、ビット数は、Ｃｅｉｌ（Ｌｏｇ２（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／ＣｔｂＳｉｚｅＹ））であってよい。一方、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘの値が存在しない場合、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘの値は０と推論（ｉｎｆｅｒ）されてよい。

【0443】

ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙは、サブピクチャーの左上端の位置のｙ座標（ｖｅｒｔｉｃａｌ ｐｏｓｉｔｉｏｎ）を示すことができる。具体的に、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙは、サブピクチャーの左上端のＣＴＵのｙ座標を示すことができる。このとき、座標は、ＣＴＵ単位又はＣＴＢ単位で表されてよい。例えば座標は、ＣｔｂＳｉｚｅＹ単位で表すことができる。また、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙは、符号なし整数（ｕｎｓｉｇｎｅｄ ｉｎｔｅｇｅｒ）の値でシグナルされてよく、このとき、ビット数は、Ｃｅｉｌ（Ｌｏｇ２（ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／ＣｔｂＳｉｚｅＹ））であってよい。一方、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙの値が存在しない場合、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙの値は０と推論（ｉｎｆｅｒ）されてよい。

【0444】

ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１は、サブピクチャーの幅を示すことができる。例えば、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１の値に既に設定された値を足した値が、サブピクチャーの幅であってよい。このとき、既に設定された値は１であってよい。また、サブピクチャーの幅はＣＴＵ単位又はＣＴＢ単位で表されてよい。例えば、サブピクチャーの幅は、ＣｔｂＳｉｚｅＹ単位で表すことができる。また、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１は、符号なし整数（ｕｎｓｉｇｎｅｄ ｉｎｔｅｇｅｒ）の値でシグナルされてよく、このとき、ビット数は、Ｃｅｉｌ（Ｌｏｇ２（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／ＣｔｂＳｉｚｅＹ））であってよい。一方、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１の値が存在しない場合、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１の値は、（Ｃｅｉｌ（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／ＣｔｂＳｉｚｅＹ）－１）と推論（ｉｎｆｅｒ）されてよい。

【0445】

ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１は、サブピクチャーの高さを示すことができる。例えば、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１の値に既に設定された値を足した値が、サブピクチャーの高さであってよい。このとき、既に設定された値は、１であってよい。また、サブピクチャーの高さは、ＣＴＵ単位又はＣＴＢ単位で表されてよい。例えば、サブピクチャーの高さは、ＣｔｂＳｉｚｅＹ単位で表すことができる。また、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１は、符号なし整数（ｕｎｓｉｇｎｅｄ ｉｎｔｅｇｅｒ）の値でシグナルされてよく、このとき、ビット数は、Ｃｅｉｌ（Ｌｏｇ２（ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／ＣｔｂＳｉｚｅＹ））であってよい。一方、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１値が存在しない場合、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１の値は、（Ｃｅｉｌ（ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／ＣｔｂＳｉｚｅＹ）－１）と推論（ｉｎｆｅｒ）されてよい。

【0446】

本発明で説明するＣｅｉｌ（ｘ）値は、ｘより大きいか同一である最小の整数（ｔｈｅ ｓｍａｌｌｅｓｔ ｉｎｔｅｇｅｒ ｇｒｅａｔｅｒ ｔｈａｎ ｏｒ ｅｑｕａｌ ｔｏ ｘ）であってよい。上述したビット数計算においてＣｅｉｌ（Ｌｏｇ２（ｘ））のような演算をしたが、これは、０以上の整数であるｘ値を２進法で表す時に必要なビット数を計算するためのものである。

【0447】

また、サブピクチャーの位置及びサイズが決定されることにより、サブピクチャー境界（ｓｕｂｐｉｃｔｕｒｅ ｂｏｕｎｄａｒｙ）位置が計算されてよい。これにより、サブピクチャーの内部に存在する位置が判断できる。

【0448】

図４３は、本発明の一実施例に係る演算子を示す図である。

【0449】

図４３を参照すると、複数の分割（ｄｉｖｉｓｉｏｎ）演算が定義されてよい。

【0450】

“／”は、整数分割（ｉｎｔｅｇｅｒ ｄｉｖｉｓｉｏｎ）を表すことができる。すなわち、“／”の結果値は、整数（ｉｎｔｅｇｅｒ）であってよい。具体的に、“／”演算の結果値を整数（ｉｎｔｅｇｅｒ）にさせる時、ゼロ（ｚｅｒｏ）方向に切断（ｔｒｕｎｃａｔｉｏｎ）するものであってよい。例えば、７／４と（－７）／（－４）の値は１である。また、（－７）／４と７／（－４）の値は－１である。図４２で説明したビット数に対する演算又はビット数を推論（ｉｎｆｅｒ）する演算において、整数分割（ｉｎｔｅｇｅｒ ｄｉｖｉｓｉｏｎ）が用いられてよい。

【0451】

“÷”は、切断（ｔｒｕｎｃａｔｉｏｎ）又は四捨五入（ｒｏｕｎｄｉｎｇ）をしない分割（ｄｉｖｉｓｉｏｎ）演算である。したがって、“÷”演算の結果値は、整数（ｉｎｔｅｇｅｒ）であっても、整数でなくてもよい。例えば、７÷４と（－７）÷（－４）の値は、１よりも大きい値であってよい。また、（－７）÷４と７÷（－４）の値は－１よりも小さい値であってよい。

【0452】

図４３における

【数8】

の“－”演算は、上述した“÷”と同じ演算である。

【0453】

図４４は、本発明の一実施例に係るピクチャーとサブピクチャーを示す図である。

【0454】

上述したように、ピクチャーは、複数個のサブピクチャーに分けられてよい。このとき、サブピクチャーがどのように分けられるか又はどのように構成されるかは、図４２に開示されたシグナリングによればいい。ただし、図４２及び図４３で説明した実施例によれば、シグナリングで表現できない範囲が存在することがある。例えば、ピクチャーの幅がＣｔｂＳｉｚｅＹで割り切れないか、又はピクチャーの高さがＣｔｂＳｉｚｅＹで割り切れない時には表すことのできないサブピクチャーの構造があり得る。具体的に、ピクチャーの幅がＣｔｂＳｉｚｅＹで割り切れない場合、ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／ＣｔｂＳｉｚｅＹ値は、０の方に切断される（ｔｒｕｎｃａｔｉｏｎ）ので、ピクチャーの最右側ＣＴＢの位置は表現できない。また、ピクチャーの高さがＣｔｂＳｉｚｅＹで割り切れない場合、ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／ＣｔｂＳｉｚｅＹ値は０の方に切断される（ｔｒｕｎｃａｔｉｏｎ）ので、ピクチャーの最下側ＣＴＢの位置は表現できない。したがって、ピクチャーの幅がＣｔｂＳｉｚｅＹで割り切れず、サブピクチャーの幅がピクチャーの幅と同一である場合、上述したシグナリングは、サブピクチャーの幅を表現できない。また、ピクチャーの幅がＣｔｂＳｉｚｅＹで割れきれず、サブピクチャーの水平位置が最右側ＣＴＢである場合、上述したシグナリングは、サブピクチャーの左上端のｘ座標を表現できない。

【0455】

具体的に、図４４を参照すると、ピクチャーの幅は、１０３２ルーマサンプルであってよい。また、ＣｔｂＳｉｚｅＹは、１２８であってよい。図４４のＳｕｂｐｉｃｔｕｒｅ０のように、サブピクチャーの幅はピクチャーの幅と同一であってよい。このとき、Ｓｕｂｐｉｃｔｕｒｅ０の幅は、ＣｔｂＳｉｚｅＹ単位で９であるので、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１値は、８を表さなければならない。ただし、ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／ＣｔｂＳｉｚｅＹ（１０３２／１２８）値が８であるため、Ｃｅｉｌ（Ｌｏｇ２（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／ＣｔｂＳｉｚｅＹ））値は３である。したがって、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１は３ビットであって、０～７の値のみ表現でき、８は表現できないという問題がある。また、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１の値が存在せず、推論（ｉｎｆｅｒ）される場合があり得る。このとき、ピクチャーが１個のサブピクチャーで構成されるかのように、サブピクチャーの幅はピクチャー幅と推論（ｉｎｆｅｒ）されるべきであるが、上述したように、ピクチャーの幅がＣｔｂＳｉｚｅＹで割り切れない場合、サブピクチャー幅は推論（ｉｎｆｅｒ）できない。

【0456】

図４４を参照すると、Ｓｕｂｐｉｃｒｕｅ ２のように、サブピクチャーの左上端のｘ座標は、最右側のＣＴＢであってよい。このとき、サブピクチャーの左上端のｘ座標は、ＣｔｂＳｉｚｅＹ単位で９番目の値、座標が０から始まる場合は８の値を示さなければならない。ただし、ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／ＣｔｂＳｉｚｅＹ値が８であるので、Ｃｅｉｌ（Ｌｏｇ２（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／ＣｔｂＳｉｚｅＹ））値は、３である。したがって、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘの値は３ビットであって、０～７の値のみを表現でき、８は表現できないという問題がある。

【0457】

図４５は、本発明の一実施例に係るサブピクチャーに関連したシンタックス要素を示す図である。

【0458】

図４４で説明したように、ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓがＣｔｂＳｉｚｅＹで割り切れない場合、ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／ＣｔｂＳｉｚｅＹが切断（切り捨て）（ｔｒｕｎｃａｔｉｏｎ（ｆｌｏｏｒｉｎｇ））されながら表現範囲が減るという問題がある。同様に、ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓがＣｔｂＳｉｚｅＹで割り切れない場合、ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／ＣｔｂＳｉｚｅＹが切断（切り捨て）（ｔｒｕｎｃａｔｉｏｎ（ｆｌｏｏｒｉｎｇ））されながら表現範囲が減った。したがつて、本発明で切断（ｔｒｕｎｃａｔｉｏｎ）されない演算方法を提案する。

【0459】

例えば、サブピクチャーの左上端ののｘ座標、ｙ座標、サブピクチャーの幅、サブピクチャーの高さは、ＣｔｂＳｉｚｅＹ単位で表現されるので、ＣｔｂＳｉｚｅＹで割り切れなければならないが、このとき、図４３で説明した“÷”演算が用いられてよい。

【0460】

ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘは、サブピクチャーの左上端の位置のｘ座標（ｈｏｒｉｚｏｎｔａｌ ｐｏｓｉｔｉｏｎ）を示すことができる。具体的に、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘは、サブピクチャーの左上端のＣＴＵのｘ座標を示すことができる。このとき、座標は、ＣＴＵ単位又はＣＴＢ単位で表されてよい。例えば、ＣｔｂＳｉｚｅＹ単位で表すことができる。ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘは、符号なし整数（ｕｎｓｉｇｎｅｄ ｉｎｔｅｇｅｒ）の値でシグナルされてよく、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘのビット数は、Ｃｅｉｌ（Ｌｏｇ２（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ÷ＣｔｂＳｉｚｅＹ））であってよい。一方、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘの値が存在しない場合、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘの値は０と推論（ｉｎｆｅｒ）されてよい。このとき、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘのビット数は、Ｃｅｉｌ（Ｌｏｇ２（Ｃｅｉｌ（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ÷ＣｔｂＳｉｚｅＹ）））と決定されてよい。

【0461】

ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙは、サブピクチャーの左上端の位置のｙ座標（ｖｅｒｔｉｃａｌ ｐｏｓｉｔｉｏｎ）を示すことができる。具体的に、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙは、サブピクチャーの左上端のＣＴＵのｙ座標を示すことができる。このとき、座標は、ＣＴＵ単位又はＣＴＢ単位で表されてよい。例えば座標は、ＣｔｂＳｉｚｅＹ単位で表すことができる。ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙは、符号なし整数（ｕｎｓｉｇｎｅｄ ｉｎｔｅｇｅｒ）の値でシグナルされてよく、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙのビット数は、Ｃｅｉｌ（Ｌｏｇ２（ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ÷ＣｔｂＳｉｚｅＹ））であってよい。一方、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙの値が存在しない場合、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙの値は０と推論（ｉｎｆｅｒ）されてよい。このとき、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙのビット数は、Ｃｅｉｌ（Ｌｏｇ２（Ｃｅｉｌ（ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ÷ＣｔｂＳｉｚｅＹ）））と決定されてよい。

【0462】

ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１は、サブピクチャーの幅を示すことができる。例えば、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１の値に既に設定された値を足した値が、サブピクチャーの幅を示すことができる。このとき、既に設定された値は、１であってよい。また、サブピクチャーの幅は、ＣＴＵ単位又はＣＴＢ単位で表すことができる。例えば、サブピクチャーの幅は、ＣｔｂＳｉｚｅＹ単位で表されてよい。ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１は、符号なし整数（ｕｎｓｉｇｎｅｄ ｉｎｔｅｇｅｒ）の値でシグナルされてよく、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１のビット数は、Ｃｅｉｌ（Ｌｏｇ２（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ÷ＣｔｂＳｉｚｅＹ））であってよい。一方、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１の値が存在しない場合、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１の値は、（Ｃｅｉｌ（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ÷ＣｔｂＳｉｚｅＹ）－１）と推論（ｉｎｆｅｒ）されてよい。このとき、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１のビット数は、Ｃｅｉｌ（Ｌｏｇ２（Ｃｅｉｌ（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ÷ＣｔｂＳｉｚｅＹ）））と決定されてよい。

【0463】

ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１は、サブピクチャーの高さを示すことができる。例えば、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１の値に既に設定された値を足した値が、サブピクチャーの高さを示すことができる。このとき、既に設定された値は、１であってよい。また、サブピクチャーの高さは、ＣＴＵ単位又はＣＴＢ単位で表すことができる。例えば、サブピクチャーの高さは、ＣｔｂＳｉｚｅＹ単位で表されてよい。ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１は、符号なし整数（ｕｎｓｉｇｎｅｄ ｉｎｔｅｇｅｒ）の値でシグナルされてよく、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１のビット数は、Ｃｅｉｌ（Ｌｏｇ２（ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ÷ＣｔｂＳｉｚｅＹ））であってよい。一方、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１の値が存在しない場合、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１の値は、（Ｃｅｉｌ（ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ÷ＣｔｂＳｉｚｅＹ）－１）と推論（ｉｎｆｅｒ）されてよい。このとき、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１のビット数は、Ｃｅｉｌ（Ｌｏｇ２（Ｃｅｉｌ（ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ÷ＣｔｂＳｉｚｅＹ）））と決定されてよい。

【0464】

図４５に開示されたシンタックス要素を用いてサブピクチャーの位置及びサイズに対する表現範囲を拡張することができる。上述したように、シンタックス要素が存在せず、シンタックス要素の値が推論されるとき、ビット数の計算は、Ｃｅｉｌ（Ｌｏｇ２（Ｃｅｉｌ（ｘ）））のようになるが、これは、Ｌｏｇ２（ｙ）のｙを整数のみとして取り込み可能な装置（デコーダ／エンコーダ）を具現する側面において有利である。上述した（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ÷ＣｔｂＳｉｚｅＹ）と（ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ÷ＣｔｂＳｉｚｅＹ）の値はそれぞれ、ピクチャーの幅、ピクチャーの高さがいくつのＣｔｂＳｉｚｅＹ単位で構成されるかを示す。図４５に開示されたシンタックス要素を使用する場合、図４４に開示されたＳｕｂｐｉｃｔｕｒｅ ０の幅及びＳｕｂｐｉｃｔｕｒｅ ２のｘ座標は表現されてよい。

【0465】

図４６は、本発明の一実施例に係る変換ブロックを分割する方法を示すフローチャートである。

【0466】

以下では、図１～図４５を用いて説明した一実施例に基づく、変換ブロックを分割する方法及び装置について説明する。

【0467】

ビデオ信号復号化装置は、変換ブロックを分割する方法を行うプロセッサを含むことができる。まず、ビデオ信号復号化装置は、変換ブロックに関する情報（例えば、シンタックス要素）を含むビットストリームを受信することができる。前記プロセッサは、既に設定された条件に基づき、現在変換ブロック（ｔｒａｎｓｆｏｒｍ ｂｌｏｃｋ，ＴＢ）の分割方向を示す結果値を決定することができる（Ｓ４６０１）。前記プロセッサは、前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割することができる（Ｓ４６０２）。前記プロセッサは、前記複数個の変換ブロックを用いてビデオ信号を復号化することができる（Ｓ４６０３）。

【0468】

また、ビデオ信号符号化装置は、既に設定された条件に基づき、現在変換ブロック（ｔｒａｎｓｆｏｒｍ ｂｌｏｃｋ，ＴＢ）の分割方向を示す結果値を決定し、前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割し、前記複数個の変換ブロックに関する情報を含むビットストリーム（ｂｉｔｓｔｒｅａｍ）を生成するプロセッサを含むことができる。

【0469】

このとき、前記既に設定された条件は、前記現在変換ブロックのカラー成分（ｃｏｌｏｒ ｃｏｍｐｏｎｅｎｔ）に関連した条件を含むことができる。

【0470】

このとき、前記既に設定された条件は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果に関連した条件をさらに含み、前記最大変換ブロック幅は、前記現在変換ブロックに関連したクロマフォーマット（ｃｈｒｏｍａ ｆｏｒｍａｔ）、前記現在変換ブロックのカラー成分及び最大変換サイズに基づいて決定されてよい。

【0471】

このとき、前記既に設定された条件は、前記現在変換ブロックの幅に第１値を掛けた値である第１幅値と、前記現在変換ブロックの高さに第２値を掛けた値である第１高さ値とを比較した結果に関連した条件をさらに含み、前記第１値及び前記第２値はそれぞれ、現在変換ブロックの幅及び現在変換ブロックの高さに関連した値であり、前記現在変換ブロックのカラー成分がルーマであれば、それぞれ１に設定され、クロマてあれば、前記現在変換ブロックに関連したクロマフォーマットに基づいてそれぞれ決定されてよい。

【0472】

前記現在変換ブロックの幅が前記最大変換ブロック幅よりも大きく、前記第１幅値が前記第１高さ値よりも大きい場合、前記結果値は、前記分割方向が垂直方向であることを示す値である１と決定されてよい。このとき、前記複数個の変換ブロックのそれぞれの幅は、前記変換ブロックの幅を２で割った値であり、前記複数個の変換ブロックのそれぞれの高さは、前記変換ブロックの高さと同じ値であってよい。

【0473】

前記現在変換ブロックの幅が前記最大変換ブロック幅以下であるか、又は前記第１幅値が前記第１高さ値以下である場合、前記結果値は、前記分割方向が水平方向であることを示す値である０と決定されてよい。このとき、前記複数個の変換ブロックのそれぞれの幅は、前記変換ブロックの幅と同じ値であり、前記複数個の変換ブロックのそれぞれの高さは、前記変換ブロックの高さを２で割った値であってよい。

【0474】

このとき、既に設定された条件は、上述した式２～式４で説明した条件であってよい。

【0475】

前記最大変換サイズは、前記現在変換ブロックに関連したコーディングツリーユニット（ｃｏｄｉｎｇ ｔｒｅｅ ｕｎｉｔ，ＣＴＵ）に含まれるルーマ成分を有するコーディングツリーブロック（ｃｏｄｉｎｇ ｔｒｅｅ ｂｌｏｃｋ，ＣＴＢ）のサイズに基づいて決定されてよい。前記コーディングツリーブロックのサイズが３２である場合、前記最大変換サイズは３２であってよい。

【0476】

前記プロセッサは、前記現在変換ブロックのカラー成分がクロマてあれば、前記現在変換ブロックに関連したコーディングブロックの予測方法がＢＤＰＣＭ（Ｂｌｏｃｋ－ｂａｓｅｄ Ｄｅｌｔａ Ｐｕｌｓｅ Ｃｏｄｅ Ｍｏｄｕｌａｔｉｏｎ）であるか否かを示すシンタックス要素をパース（ｐａｒｓｉｎｇ）できる。その後、前記プロセッサは、前記パーシングの結果、前記コーディングブロックの予測方法がＢＤＰＣＭでない場合、前記コーディングブロックの予測方法に関連したシンタックス要素をさらにパースし、前記パーシング結果に基づいて前記コーディングブロックの予測方法を決定できる。このとき、前記コーディングブロックの予測方法に関連したシンタックス要素は、ＣＣＬＭ（ｃｒｏｓｓ ｃｏｍｐｏｎｅｎｔ ｌｉｎｅａｒ ｍｏｄｅｌ）、平面（ｐｌａｎａｒ）モード、ＤＣモード、垂直モード、水平モード、対角モード、及びＤＭモードの少なくともいずれか一つを示すシンタックス要素であってよい。

【0477】

上述した本発明の実施例は多様な手段を介して具現される。例えば、本発明の実施例は、ハードウェア、ファームウェア（ｆｉｒｍｗａｒｅ）、ソフトフェアまたはそれらの組み合わせによって具現される。

【0478】

ハードウェアによる具現の場合、本発明の実施例による方法は、一つまたはそれ以上のＡＳＩＣｓ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔｓ）、ＤＳＰｓ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒｓ）、ＤＳＤＰｓ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｄｅｖｉｃｅｓ）、ＰＤＬｓ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅｓ）、ＦＰＧＡｓ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙｓ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどによって具現される。

【0479】

ファームフェアやソフトウェアによる具現の場合、本発明の実施例による方法は、上述した機能または動作を行うモジュール、手順または関数などの形態で具現される。ソフトウェアコードは、メモリに貯蔵されてプロセッサによって具現される。前記メモリはプロセッサの内部または外部に位置し、既に公知の多様な手段によってプロセッサとデータを交換する。

【0480】

一部の実施例はコンピュータによって実行されるプログラムモジュールのようなコンピュータで実行可能な命令語を含む記録媒体の形態にも具現される。コンピュータで判読可能な媒体は、コンピュータでアクセスされ得る任意の利用可能な媒体であり、揮発性及び非揮発性媒体、分離型及び非分離型媒体をいずれも含む。また、コンピュータ読取可能媒体は貯蔵媒体及び通信媒体をいずれも含む。コンピュータ貯蔵媒体は、コンピュータ判読可能な命令語、データ構造、プログラムモジュール、またはその他のデータのような情報の貯蔵のための任意の方法または技術で具現された揮発性及び非揮発性媒体、分離型及び非分離型媒体をいずれも含む。通信媒体は、典型的にコンピュータ読取可能な命令語、データ構造、またはプログラムモジュールのような変調されたデータ信号のその他のデータ、またはその他の伝送メカニズムを含み、任意の情報伝達媒体を含む。

【0481】

上述した本発明の説明は例示のためのものであって、本発明が属する技術分野における通常の知識を有する者は、本発明の技術的思想や必須的特徴を変更せずも他の具体的な形態に容易に変更可能であることを理解できるはずである。よって、上述した実施例は全ての面で例示的なものであり、限定的なものではないと理解すべきである。例えば、単一型として説明されている各構成要素は分散されて実施されてもよく、同じく分散されていると説明されている構成要素も結合された形態で実施されてもよい。

【0482】

本発明の範囲は、上述した詳細な説明よりは後述する特許請求の範囲によって示され、特許請求の範囲の意味及び範囲、そしてその均等概念から導き出される全ての変更または変形された形態が本発明の範囲に含まれると解釈すべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15(a)】

【図15(b)】

【図15(c)】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27(a)】

【図27(b)】

【図28】

【図29(a)】

【図29(b)】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】

【図41】

【図42】

【図43】

【図44】

【図45】

【図46】