IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティドの特許一覧

(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
【FI】
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)【参考文献】
【文献】国際公開第2018/080122(WO,A1)
【文献】米国特許出願公開第2014/0192904(US,A1)
【文献】米国特許出願公開第2019/0075328(US,A1)
【文献】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.,DB名)
H04N 7/12
H04N 19/00-19/98
(57)【特許請求の範囲】
【請求項1】
ビデオ信号復号化装置であって、
プロセッサを含み、
前記プロセッサは、
在変換ブロックの分割方向が垂直方向又は水平方向であることを示す結果値を決定し、
前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割し、
前記複数個の変換ブロックに基づき、前記現在変換ブロックを復号化し、
前記結果値は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果、及び第1値と第2値とを比較した結果に基づいて決定され、
前記第1値は、前記現在変換ブロックに関連したクロマフォーマット(chroma format)、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの幅に基づいて取得され、
前記第2値は、前記現在変換ブロックに関連したクロマフォーマット、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの高さに基づいて取得されることを特徴とするビデオ信号復号化装置。
【請求項2】
記最大変換ブロック幅は、前記現在変換ブロックに関連したクロマフォーマット、前記現在変換ブロックのカラー成分及び最大変換サイズに基づいて決定されることを特徴とする、請求項1に記載のビデオ信号復号化装置。
【請求項3】
前記第1値は、前記現在変換ブロックの幅とSubWidthCとを掛けることによって取得され、
前記第2値は、前記現在変換ブロックの高さとSubHeightCとを掛けることによって取得され、
前記SubWidthC及び前記SubHeightCは、各々、前記現在変換ブロックに関連したクロマフォーマットに基づいて決定される変数であることを特徴とする、請求項2に記載のビデオ信号復号化装置。
【請求項4】
前記現在変換ブロックのカラー成分ルーマ成分である場合に、前記SubWidthCは1であり、かつ、前記SubHeightCは1であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが4:2:0である場合に、前記SubWidthCは2であり、かつ、前記SubHeightCは2であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが4:2:2である場合に、前記SubWidthCは2であり、かつ、前記SubHeightCは1であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが4:4:4である場合に、前記SubWidthCは1であり、かつ、前記SubHeightCは1であることを特徴とする、請求項3に記載のビデオ信号復号化装置。
【請求項5】
前記現在変換ブロックの幅が前記最大変換ブロック幅以下であるか、又は前記第1値が前記第値以下である場合に、前記結果値は、前記分割方向が前記水平方向であることを示す値である0と決定され、
前記現在変換ブロックの幅が前記最大変換ブロック幅より大きく、かつ、前記第1値が前記第2値より大きい場合に、前記結果値は、前記分割方向が前記垂直方向であることを示す値である1と決定されることを特徴とする、請求項に記載のビデオ信号復号化装置。
【請求項6】
前記最大変換サイズは、前記現在変換ブロックに関連したコーディングツリーユニット(coding tree unit,CTU)に含まれるルーマ成分を有するコーディングツリーブロック(coding tree block,CTB)のサイズに基づいて決定されることを特徴とする、請求項2に記載のビデオ信号復号化装置。
【請求項7】
前記コーディングツリーブロックのサイズが32である場合に、前記最大変換サイズは32であることを特徴とする、請求項6に記載のビデオ信号復号化装置。
【請求項8】
前記結果値が0と決定される場合に、
前記複数個の変換ブロックのそれぞれの幅は、前記現在変換ブロックの幅と同じ値であり、
前記複数個の変換ブロックのそれぞれの高さは、前記現在変換ブロックの高さを2で割った値であり、
前記結果値が1と決定される場合に、
前記複数個の変換ブロックのそれぞれの幅は、前記現在変換ブロックの幅を2で割った値であり、
前記複数個の変換ブロックのそれぞれの高さは、前記現在変換ブロックの高さと同じ値であることを特徴とする、請求項1に記載のビデオ信号復号化装置。
【請求項9】
ビデオ信号符号化装置であって、
プロセッサを含み、
前記プロセッサは、
符号化方法を用いてデコーダによって復号化されるビットストリーム(bitstream)を取得し、
前記符号化方法は、
在変換ブロックの分割方向が垂直方向又は水平方向であることを示す結果値を決定するステップと
前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割するステップと
前記複数個の変換ブロックに基づき、前記現在変換ブロックを復号化するステップと、を含み、
前記結果値は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果、及び第1値と第2値とを比較した結果に基づいて決定され、
前記第1値は、前記現在変換ブロックに関連したクロマフォーマット(chroma format)、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの幅に基づいて取得され、
前記第2値は、前記現在変換ブロックに関連したクロマフォーマット、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの高さに基づいて取得されることを特徴とするビデオ信号符号化装置。
【請求項10】
記最大変換ブロック幅は、前記現在変換ブロックに関連したクロマフォーマット、前記現在変換ブロックのカラー成分及び最大変換サイズに基づいて決定されることを特徴とする、請求項9に記載のビデオ信号符号化装置。
【請求項11】
前記第1値は、前記現在変換ブロックの幅とSubWidthCとを掛けることによって取得され、
前記第2値は、前記現在変換ブロックの高さとSubHeightCとを掛けることによって取得され、
前記SubWidthC及び前記SubHeightCは、各々、前記現在変換ブロックに関連したクロマフォーマットに基づいて決定される変数であることを特徴とする、請求項10に記載のビデオ信号符号化装置。
【請求項12】
前記現在変換ブロックのカラー成分ルーマ成分である場合に、前記SubWidthCは1であり、かつ、前記SubHeightCは1であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが4:2:0である場合に、前記SubWidthCは2であり、かつ、前記SubHeightCは2であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが4:2:2である場合に、前記SubWidthCは2であり、かつ、前記SubHeightCは1であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが4:4:4である場合に、前記SubWidthCは1であり、かつ、前記SubHeightCは1であることを特徴とする、請求項11に記載のビデオ信号符号化装置。
【請求項13】
前記現在変換ブロックの幅が前記最大変換ブロック幅以下であるか、又は前記第1値が前記第値以下である場合に、前記結果値は、前記分割方向が前記水平方向であることを示す値である0と決定され、
前記現在変換ブロックの幅が前記最大変換ブロック幅より大きく、かつ、前記第1値が前記第2値より大きい場合に、前記結果値は、前記分割方向が前記垂直方向であることを示す値である1と決定されることを特徴とする、請求項11に記載のビデオ信号符号化装置。
【請求項14】
前記最大変換サイズは、前記現在変換ブロックに関連したコーディングツリーユニット(coding tree unit,CTU)に含まれるルーマ成分を有するコーディングツリーブロック(coding tree block,CTB)のサイズに基づいて決定されることを特徴とする、請求項10に記載のビデオ信号符号化装置。
【請求項15】
前記コーディングツリーブロックのサイズが32である場合に、前記最大変換サイズは32であることを特徴とする、請求項14に記載のビデオ信号符号化装置。
【請求項16】
前記結果値が0と決定される場合に、
前記複数個の変換ブロックのそれぞれの幅は、前記現在変換ブロックの幅と同じ値であり、
前記複数個の変換ブロックのそれぞれの高さは、前記現在変換ブロックの高さを2で割った値であり、
前記結果値が1と決定される場合に、
前記複数個の変換ブロックのそれぞれの幅は、前記現在変換ブロックの幅を2で割った値であり、
前記複数個の変換ブロックのそれぞれの高さは、前記現在変換ブロックの高さと同じ値であることを特徴とする、請求項13に記載のビデオ信号符号化装置。
【請求項17】
ビットストリーム(bitstream)を取得する方法であって、
前記方法は、
在変換ブロックの分割方向が垂直方向又は水平方向であることを示す結果値を決定するステップと、
前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割するステップと、を含み、
前記結果値は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果、及び第1値と第2値とを比較した結果に基づいて決定され、
前記第1値は、前記現在変換ブロックに関連したクロマフォーマット(chroma format)、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの幅に基づいて取得され、
前記第2値は、前記現在変換ブロックに関連したクロマフォーマット、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの高さに基づいて取得されることを特徴とする方法
【請求項18】
記最大変換ブロック幅は、前記現在変換ブロックに関連したクロマフォーマット、前記現在変換ブロックのカラー成分及び最大変換サイズに基づいて決定されることを特徴とする、請求項17に記載の方法
【請求項19】
前記第1値は、前記現在変換ブロックの幅とSubWidthCとを掛けることによって取得され、
前記第2値は、前記現在変換ブロックの高さとSubHeightCとを掛けることによって取得され、
前記SubWidthC及び前記SubHeightCは、各々、前記現在変換ブロックに関連したクロマフォーマットに基づいて決定される変数であることを特徴とする、請求項18に記載の方法
【請求項20】
前記現在変換ブロックのカラー成分がルーマ成分である場合に、前記SubWidthCは1であり、かつ、前記SubHeightCは1であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが4:2:0である場合に、前記SubWidthCは2であり、かつ、前記SubHeightCは2であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが4:2:2である場合に、前記SubWidthCは2であり、かつ、前記SubHeightCは1であり、
前記現在変換ブロックのカラー成分がクロマ成分であり、かつ、前記現在変換ブロックに関連したクロマフォーマットが4:4:4である場合に、前記SubWidthCは1であり、かつ、前記SubHeightCは1であることを特徴とする、請求項19に記載の方法
【請求項21】
ビデオ信号を処理するための方法であって、前記方法は、
在変換ブロックの分割方向が垂直方向又は水平方向であることを示す結果値を決定するステップと、
前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割するステップと、
前記複数個の変換ブロックに基づき、前記現在変換ブロックを復号化するステップとを含み、
前記結果値は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果、及び第1値と第2値とを比較した結果に基づいて決定され、
前記第1値は、前記現在変換ブロックに関連したクロマフォーマット(chroma format)、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの幅に基づいて取得され、
前記第2値は、前記現在変換ブロックに関連したクロマフォーマット、前記現在変換ブロックのカラー成分、及び前記現在変換ブロックの高さに基づいて取得される、方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明はビデオ信号処理方法及び装置に関し、特にビデオ信号を符号化又は復号するビデオ信号処理方法及び装置に関する。
【背景技術】
【0002】
圧縮符号化とは、デジタル化した情報を通信回線を介して伝送するか、貯蔵媒体に適合した形態に貯蔵するための一連の信号処理技術を意味する。圧縮符号化の対象としては音声、映像、文字などの対象が存在するが、特に映像を対象とする圧縮符号化を行う技術をビデオ映像圧縮と称する。ビデオ信号に対する圧縮符号化は、空間的な相関関係、時間的な相関関係、確率的な相関関係などを考慮して剰余情報を除去することで行われる。しかし、最近の多様なメディア及びデータ伝送媒体の発展によって、より高効率のビデオ信号処理方法及び装置が求められている。
【発明の概要】
【発明が解決しようとする課題】
【0003】
本発明の目的は、ビデオ信号のコーディング効率を上げることにある。
【0004】
本発明の目的は、変換ユニット(ブロック)の分割を用いてビデオ信号のコーディング効率を上げることにある。
【0005】
本発明の目的は、画面内予測方法においてエンコーダが選択した予測モードを効率的に受信することにある。
【課題を解決するための手段】
【0006】
本明細書は、2次変換を用いるビデオ信号処理方法を提供する。
【0007】
具体的に、ビデオ信号復号化装置において、プロセッサを含み、前記プロセッサは、既に設定された条件に基づき、現在変換ブロック(transform block,TB)の分割方向を示す結果値を決定し、前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割し、前記複数個の変換ブロックを用いてビデオ信号を復号化するが、前記既に設定された条件は、前記現在変換ブロックのカラー成分(color component)に関連した条件を含むことを特徴とする。
【0008】
また、本明細書において、前記既に設定された条件は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果に関連した条件をさらに含み、前記最大変換ブロック幅は、前記現在変換ブロックに関連したクロマフォーマット(chroma format)、前記現在変換ブロックのカラー成分及び最大変換サイズに基づいて決定されることを特徴とする。
【0009】
また、本明細書において、前記既に設定された条件は、前記現在変換ブロックの幅に第1値を掛けた値である第1幅値と、前記現在変換ブロックの高さに第2値を掛けた値である第1高さ値とを比較した結果に関連した条件をさらに含み、前記第1値及び前記第2値はそれぞれ、現在変換ブロックの幅及び現在変換ブロックの高さに関連した値であり、前記現在変換ブロックのカラー成分が、ルーマであれば、それぞれ1に設定され、クロマてあれば、前記現在変換ブロックに関連したクロマフォーマットに基づいてそれぞれ決定されることを特徴とする。
【0010】
また、本明細書において、前記現在変換ブロックの幅が前記最大変換ブロック幅よりも大きく、前記第1幅値が前記第1高さ値よりも大きい場合に、前記結果値は、前記分割方向が垂直方向であることを示す値である1と決定され、前記複数個の変換ブロックのそれぞれの幅は、前記変換ブロックの幅を2で割った値であり、前記複数個の変換ブロックのそれぞれの高さは、前記変換ブロックの高さと同じ値であることを特徴とする。
【0011】
また、本明細書において、前記現在変換ブロックの幅が前記最大変換ブロック幅以下であるか、又は前記第1幅値が前記第1高さ値以下である場合に、前記結果値は、前記分割方向が水平方向であることを示す値である0と決定され、前記複数個の変換ブロックのそれぞれの幅は、前記変換ブロックの幅と同じ値であり、前記複数個の変換ブロックのそれぞれの高さは、前記変換ブロックの高さを2で割った値であることを特徴とする。
【0012】
また、本明細書において、前記最大変換サイズは、前記現在変換ブロックに関連したコーディングツリーユニット(coding tree unit,CTU)に含まれるルーマ成分を有するコーディングツリーブロック(coding tree block,CTB)のサイズに基づいて決定されることを特徴とする。
【0013】
また、本明細書において、前記コーディングツリーブロックのサイズが32である場合に、前記最大変換サイズは32であることを特徴とする。
【0014】
また、本明細書において、前記プロセッサは、前記現在変換ブロックのカラー成分がクロマてあれば、前記現在変換ブロックに関連したコーディングブロックの予測方法がBDPCM(Block-based Delta Pulse Code Modulation)であるか否かを示すシンタックス要素をパース(parsing)し、前記パーシングの結果、前記コーディングブロックの予測方法がBDPCMでない場合に、前記コーディングブロックの予測方法に関連したシンタックス要素をさらにパースし、前記パーシング結果に基づいて前記コーディングブロックの予測方法を決定し、前記コーディングブロックの予測方法に関連したシンタックス要素は、CCLM(cross component linear model)、平面(planar)モード、DCモード、垂直モード、水平モード、対角モード、及びDMモードの少なくともいずれか一つを示すシンタックス要素であることを特徴とする。
【0015】
また、本明細書において、ビデオ信号符号化装置において、プロセッサを含み、前記プロセッサは、既に設定された条件に基づき、現在変換ブロック(transform block,TB)の分割方向を示す結果値を決定し、前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割し、前記複数個の変換ブロックに関する情報を含むビットストリーム(bitstream)を生成するが、前記既に設定された条件は、前記現在変換ブロックのカラー成分(color component)に関連した条件を含むことを特徴とする。
【0016】
また、本明細書において、前記既に設定された条件は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果に関連した条件をさらに含み、前記最大変換ブロック幅は、前記現在変換ブロックに関連したクロマフォーマット(chroma format)、前記現在変換ブロックのカラー成分及び最大変換サイズに基づいて決定されることを特徴とする。
【0017】
また、本明細書において、前記既に設定された条件は、前記現在変換ブロックの幅に第1値を掛けた値である第1幅値と、前記現在変換ブロックの高さに第2値を掛けた値である第1高さ値とを比較した結果に関連した条件をさらに含み、前記第1値及び前記第2値はそれぞれ、現在変換ブロックの幅及び現在変換ブロックの高さに関連した値であり、前記現在変換ブロックのカラー成分が、ルーマであれば、それぞれ1に設定され、クロマてあれば、前記現在変換ブロックに関連したクロマフォーマットに基づいてそれぞれ決定されることを特徴とする。
【0018】
また、本明細書において、前記現在変換ブロックの幅が前記最大変換ブロック幅よりも大きく、前記第1幅値が前記第1高さ値よりも大きい場合に、前記結果値は、前記分割方向が垂直方向であることを示す値である1と決定され、前記複数個の変換ブロックのそれぞれの幅は、前記変換ブロックの幅を2で割った値であり、前記複数個の変換ブロックのそれぞれの高さは、前記変換ブロックの高さと同じ値であることを特徴とする。
【0019】
また、本明細書において、前記変換ブロックの幅が前記最大変換ブロック幅以下であるか、又は前記第1幅値が前記第1高さ値以下である場合に、前記結果値は、前記分割方向が水平方向であることを示す値である0と決定され、前記複数個の変換ブロックのそれぞれの幅は、前記変換ブロックの幅と同じ値であり、前記複数個の変換ブロックのそれぞれの高さは、前記変換ブロックの高さを2で割った値であることを特徴とする。
【0020】
また、本明細書において、前記最大変換サイズは、前記現在変換ブロックに関連したコーディングツリーユニット(coding tree unit,CTU)に含まれるルーマ成分を有するコーディングツリーブロック(coding tree block,CTB)のサイズに基づいて決定されることを特徴とする。
【0021】
また、本明細書において、前記コーディングツリーブロックのサイズが32である場合に、前記最大変換サイズは32であることを特徴とする。
【0022】
また、本明細書において、前記プロセッサは、前記現在変換ブロックのカラー成分がクロマてあれば、前記現在変換ブロックに関連したコーディングブロックの予測方法がBDPCM(Block-based Delta Pulse Code Modulation)であるか否かを示すシンタックス要素をパース(parsing)し、前記パーシングの結果、前記コーディングブロックの予測方法がBDPCMでない場合に、前記コーディングブロックの予測方法に関連したシンタックス要素をさらにパースし、前記パーシング結果に基づいて前記コーディングブロックの予測方法を決定し、前記コーディングブロックの予測方法に関連したシンタックス要素は、CCLM(cross component linear model)、平面(planar)モード、DCモード、垂直モード、水平モード、対角モード、及びDMモードの少なくともいずれか一つを示すシンタックス要素であることを特徴とする。
【0023】
また、本明細書において、ビットストリーム(bitstream)を保存する非時的な(non-transitory)コンピュータ可読媒体(computer-readable medium)において、前記ビットストリームは、既に設定された条件に基づき、現在変換ブロック(transform block,TB)の分割方向を示す結果値を決定する段階;前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割する段階;前記複数個の変換ブロックに関する情報を含むビットストリームを符号化する段階;を含む符号化方法によって符号化され、前記既に設定された条件は、前記現在変換ブロックのカラー成分(color component)に関連した条件を含むことを特徴とする。
【0024】
また、本明細書において、前記既に設定された条件は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果に関連した条件をさらに含み、前記最大変換ブロック幅は、前記現在変換ブロックに関連したクロマフォーマット(chroma format)、前記現在変換ブロックのカラー成分及び最大変換サイズに基づいて決定されることを特徴とする。
【0025】
また、本明細書において、前記既に設定された条件は、前記現在ブロックの幅に第1値を掛けた値である第1幅値と、前記現在変換ブロックの高さに第2値を掛けた値である第1高さ値とを比較した結果に関連した条件をさらに含み、前記第1値及び前記第2値はそれぞれ、現在変換ブロックの幅及び現在変換ブロックの高さに関連した値であり、前記現在変換ブロックのカラー成分が、ルーマであれば、それぞれ1に設定され、クロマてあれば、前記現在変換ブロックに関連したクロマフォーマットに基づいてそれぞれ決定されることを特徴とする。
【0026】
また、本明細書において、前記最大変換サイズは、前記現在変換ブロックに関連したコーディングツリーユニット(coding tree unit,CTU)に含まれるルーマ成分を有するコーディングツリーブロック(coding tree block,CTB)のサイズに基づいて決定されることを特徴とする。
【発明の効果】
【0027】
本発明の一実施例は、変換ユニットの分割を用いるビデオ信号処理方法及びそのための装置を提供する。
【0028】
本発明の一実施例は、画面内予測方法において、エンコーダが選択した予測モードを効率的に受信するビデオ信号処理方法及びそのための装置を提供する。
【図面の簡単な説明】
【0029】
図1】本発明の一実施例によるビデオ信号エンコーディング装置の概略的なブロック図である。
図2】本発明の一実施例によるビデオ信号デコーディング装置の概略的なブロック図である。
図3】ピクチャ内でコーディングツリーユニットがコーディングユニットに分割される実施例を示す図である。
図4】クォードツリー及びマルチ-タイプツリーの分割をシグナリングする方法の一実施例を示す図である。
図5】本発明の実施例によるイントラ予測方法をより詳しく示す図である。
図6】本発明の実施例によるイントラ予測方法をより詳しく示す図である。
図7】本発明の一実施例に係るインター予測方法を示す図である。
図8】本発明の一実施例に係る、現在ブロックのモーションベクトルがシグナルされる方法を示す図である。
図9】本発明の一実施例に係る、現在ブロックのモーションベクトル差分値がシグナルされる方法を示す図である。
図10】本発明の一実施例に係るコーディングユニット及び変換ユニットを示す図である。
図11】本発明の一実施例に係る変換ツリーシンタックスを示す図である。
【0030】
図12】本発明の一実施例に係るイントラブロックにおけるデコーディングプロセスを示す図である。
図13】本発明の一実施例に係るレジデュアル信号のデコーディングプロセスを示す図である。
図14】本発明の一実施例に係るカラー成分の関係を示す図である。
図15】本発明の一実施例に係るカラー成分の関係を示す図である。
図16】本発明の一実施例に係る最大変換サイズを示す図である。
【0031】
図17】本発明の一実施例に係る上位レベルにおけるシンタックスを示す図である。
図18】本発明の一実施例に係る変換ツリーシンタックスを示す図である。
図19】本発明の一実施例に係るTU分割を示す図である。
図20】本発明の一実施例に係るTU分割を示す図である。
図21】本発明の一実施例に係るデコーディングプロセスを示す図である。
図22】本発明の一実施例に係るデコーディングプロセスを示す図である。
図23】本発明の一実施例に係る上位レベルシンタックスを示す図である。
図24】本発明の一実施例に係る上位レベルシンタックスを示す図である。
図25】本発明の一実施例に係る変換ツリーシンタックスを示す図である。
図26】本発明の一実施例に係るデコーディングプロセスを示す図である。
図27】本発明の一実施例に係るBDPCM実行方法を示す図である。
図28】本発明の一実施例に係るBDPCMに関連したシンタックスを示す図である。
図29】本発明の一実施例に係るBDPCM使用可能条件を示す図である。
図30】本発明の一実施例に係るCIIPとイントラ予測を示す図である。
図31】本発明の一実施例に係るマージデータシンタックスを示す図である。
図32】本発明の一実施例に係るマージデータシンタックスを示す図である。
図33】本発明の一実施例に係るCIIPモードの実行方法を示す図である。
図34】本発明の一実施例に係るクロマBDPCMシンタックス構造を示す図である。
図35】本発明の一実施例に係るクロマBDPCMシンタックス構造を示す図である。
図36】本発明の一実施例に係るBDPCMに関連した上位レベルシンタックスを示す図である。
図37】本発明の一実施例に係るBDPCMに関する上位レベルでシグナルされるシンタックス要素を示す図である。
図38】本発明の一実施例に係るクロマBDPCMに関連したシンタックスを示す図である。
図39】本発明の実施例に係るイントラ予測に関連したシンタックスを示す図である。
図40】本発明の実施例に係るイントラ予測(intra prediction)に関連したシンタックスを示す図である。
図41】本発明の一実施例に係るシーケンスパラメータセットシンタックスを示す図である。
図42】本発明の一実施例に係るサブピクチャーに関連したシンタックス要素を示す図である。
図43】本発明の一実施例に係る演算子を示す図である。
図44】本発明の一実施例に係るピクチャーとサブピクチャーを示す図である。
図45】本発明の一実施例に係るサブピクチャーに関連したシンタックス要素を示す図である。
図46】本発明の一実施例に係る変換ブロックを分割する方法を示す図である。
【発明を実施するための形態】
【0032】
本明細書で使用される用語は本発明における機能を考慮しながらできるだけ現在広く使用されている一般的な用語を選択したが、これは当分野に携わる技術者の意図、慣例または新たな技術の出現などによって異なり得る。また、特定の場合は出願人が任意に選定した用語もあるが、この場合、該当の発明を実施する形態の部分においてその意味を記載する。よって、本明細書で使用される用語は、単なる用語の名称ではなく、その用語の有する実質的な意味と本明細書全般にわたる内容に基づいて解釈すべきであることを明らかにする。
【0033】
本明細書において、一部用語は以下のように解釈される。コーディングは、場合によってはエンコーディングまたはでコーディングに解釈される。本明細書において、ビデオ信号のエンコーディング(符号化)を行ってビデオ信号のビットストリームを生成する装置はエンコーディング装置またはエンコーダと称され、ビデオ信号ビットストリームのデコーディング(復号化)を行ってビデオ信号を復元する装置はデコーディング装置またはデコーダと称される。また、本明細書において、ビデオ信号処理装置はエンコーダ及びデコーダをいずれも含む概念の用語として使用される。情報(information)は値(values)、パラメータ(parameter)、係数(coefficients)、成分(elements)などをいずれも含む用語であって、場合によっては意味が異なるように解釈されることがあるため、本発明はこれに限らない。 ‘ユニット’は、映像処理の基本単位又はピクチャの特定位置を表す意味で使われ、ルーマ(luma)成分及びクロマ(chroma)成分のうち少なくとも一つを含むイメージ領域のことを指す。また、「ブロック」は輝度成分及び色差成分(つまり、Cb及びCr)のうち特定成分を含むイメージ領域を指す。但し、実施例によって「ユニット」、「ブロック」、「パーティション」、及び「領域」などの用語は互いに混合して使用されてもよい。また、本明細書において、ユニットはコーディングユニット、予測ユニット、変換ユニットをいずれも含む概念として使用される。ピクチャはフィールドまたはフレームを指し、実施例よっては前記用語は互いに混用して使用される。
【0034】
図1は、本発明の一実施例によるビデオ信号エンコーディング装置100の概略的なブロック図である。図1を参照すると、本明細書のエンコーディング装置100は、変換部110、量子化部115、逆量子化部120、逆変換部125、フィルタリング部130、予測部150、及びエントロピーコーディング部160を含む。
【0035】
変換部110は、入力されたビデオ信号と予測部150で生成された予測信号の差であるレジデュアル信号を変換して変換系数値を獲得する。例えば、離散コサイン変換(Discrete Cosine Transform、DCT)、離散サイン変換(Discrete Sine Transform、DST)、またはウェーブレット変換(Wavelet Transform)などが使用される。離散コサイン変換及び離散サイン変換は、入力されたピクチャ信号をブロックの形態に分けて変換を行うようになる。変換において、変換領域内の値の分布と特性によってコーディング効率が異なり得る。量子化部115は、変換部110内で出力された変換係数の値を量子化する。
【0036】
コーディング効率を上げるために、ピクチャ信号をそのままコーディングするのではなく、予測部150を介して予めコーディングされた領域を利用してピクチャを予測し、予測されたピクチャに原本ピクチャと予測ピクチャの間のレジデュアル値を足して復元ピクチャを獲得する方法が使用される。エンコーダとデコーダでミスマッチが発生しないように、エンコーダで予測を行う際にはデコーダでも使用可能な情報を使用すべきである。そのために、エンコーダでは符号化した現在ブロックを更に復元する過程を行う。逆量子化部120では変換係数値を逆量子化し、逆変換部125では逆量子化された変換系数値を利用してレジデュアル値を復元する。一方、フィルタリング部130は、復元されたピクチャの品質改善及び符号化効率の向上のためのフィルタリング演算を行う。例えば、デブロッキングフィルタ、サンプル適応的オフセット(Sample Adpative Offset、SAO)、及び適応的ループフィルタなどが含まれてもよい。フィルタリングを経たピクチャは、出力されるか参照ピクチャとして利用するために復号ピクチャバッファ(Decoded Picture Buffer、DPB)156に貯蔵される。
【0037】
コーディング効率を上げるために、ピクチャ信号をそのままコードせず、予測部150で既にコードされた領域を用いてピクチャを予測し、予測されたピクチャに原ピクチャと予測ピクチャ間のレジデュアル値を足して復元ピクチャを取得する方法が用いられる。イントラ予測部152では、現在ピクチャ内で画面内予測を行い、インター予測部154では、復号ピクチャバッファ156に保存された参照ピクチャを用いて現在ピクチャを予測する。イントラ予測部152は、現在ピクチャ内の復元された領域から画面内予測を行い、画面内符号化情報をエントロピーコーディング部160に伝達する。インター予測部154はさらに、モーション推定部154a及びモーション補償部154bを含んで構成されてよい。モーション推定部154aでは、復元された特定領域を参照して現在領域のモーションベクトル値を取得する。モーション推定部154aでは、参照領域の位置情報(参照フレーム、モーションベクトルなど)などをエントロピーコーディング部160に伝達してビットストリームに含まれ得るようにする。モーション推定部154aから伝達されたモーションベクトル値を用いて、モーション補償部154bでは画面間モーション補償を行う。
【0038】
予測部150は、イントラ予測部152とインター予測部154を含む。イントラ予測部152は現在ピクチャ内でイントラ(intra)予測を行い、インター予測部154は復号ピクチャバッファ156に貯蔵された参照バッファを利用して現在ピクチャを予測するインター(inter)予測を行う。イントラ予測部152は、現在ピクチャ内の復元されたサンプルからイントラ予測を行い、イントラ符号化情報をエントロピーコーディング部160に伝達する。イントラ符号化情報は、イントラ予測モード、MPM(Most Probable Mode)フラッグ、MPMインデックスのうち少なくとも一つを含む。 イントラ符号化情報は、参照サンプルに関する情報を含むことができる。 イントラ符号化情報は参照サンプルに関する情報を含む。インター予測部154は、モーション推定部154a及びモーション補償部154bを含んで構成される。モーション推定部154aは、復元された参照信号ピクチャの特定領域を参照して現在領域のモーションベクトル値を獲得する。モーション推定部154aは、参照領域に対するモーション情報セット(参照ピクチャインデックス、モーションベクトル情報)をエントロピーコーディング部160に伝達する。モーション補償部154bは、モーション補償部154aから伝達されたモーションベクトル値を利用してモーション補償を行う。インター予測部154は、参照領域に対するモーション情報を含むインター符号化情報をエントロピーコーディング部160に伝達する。
【0039】
更なる実施例によって、予測部150はイントラブロックコピー(block copy、BC)予測部(図示せず)を含む。イントラBC予測部は、現在ピクチャ内の復元されたサンプルからイントラBC予測を行い、イントラBC符号化情報をエントロピーコーディング部160に伝達する。イントラBC予測部は、現在ピクチャ内の特定領域を参照して現在領域の予測に利用される参照領域を示すブロックベクトル値を獲得する。イントラBC予測部は、獲得されたブロックベクトル値を利用してイントラBC予測を行う。イントラBC予測部は、イントラBC符号化情報をエントロピーコーディング部160に伝達する。イントラBC予測部はブロックベクトル情報を含む。
【0040】
上述したピクチャ予測が行われれば、変換部110は原本ピクチャと予測ピクチャの間のレジデュアル値を変換して変換係数値を獲得する。この際、変換はピクチャ内で特定ブロック単位で行われるが、特定ブロックのサイズは予め設定された範囲内で可変する。量子化部115は、変換部110で生成された変換係数の値を量子化してエントロピーコーディング部160に伝達する。
【0041】
エントロピーコーディング部160は、量子化された変換係数を示す情報、イントラ符号化情報、及びインター符号化情報などをエントロピーコーディングしてビデオ信号ビットストリームを生成する。 エントロピーコーディング部160では、可変長コーディング(Variable Length Codeing、VLC)方式と算術コーディング(arithmetic coding)方式などが使用される。可変長コーディング(VLC)方式は入力されるシンボルを連続したコードワードにへ難するが、コードワードの長さは可変的である。例えば、よく発生するシンボルは短いコードワードで、よく発生しないシンボルは長いコードワードで表現する。可変長コーディング方式として、コンテキスト基盤適応型可変長コーディング(Context-based Adaptive Variable Length Coding、CAVLC)方式が使用される。算術コーディングは連続したデータシンボルを一つの素数に変換するが、算術コーディングは各シンボルを表現するために必要な最適の素数ビットを得る。算術コーディングとして、コンテキスト基盤適合型算術符号化(Context-based Adaptive Binary Arithmetic Coding、CABAC)方式が使用される。 例えば、エントロピーコーディング部160は、量子化された変換係数を示す情報を二進化することができる。また、エントロピーコーディング部160は、二進化された情報を算術コーディングしてビットストリームを生成することができる。
【0042】
前記生成されたビットストリームは、NAL(Network Abstraction Layer)ユニットを基本単位にカプセル化される。NALユニットは、符号化された整数個のコーディングツリーユニット(coding tree unit)を含む。ビデオデコーダでビットストリームを復号化するためには、まずビットストリームをNALユニット単位に分離した後、分離されたそれぞれのNALユニットを復号化すべきである。 一方、ビデオ信号ビットストリームの復号化のために必要な情報は、ピクチャーパラメータセット(Picture Parameter Set,PPS)、シーケンスパラメータセット(Sequence Parameter Set,SPS)、ビデオパラメータセット(Video Parameter Set,VPS)、デコーディングケイパビリティ情報(Decoding Capability Information,DCI)などのような上位レベルセットのRBSP(Raw Byte Sequence Payload)で送信されてよい。
【0043】
一方、図1のブロック図は本発明の一実施例によるエンコーディング装置100を示し、分離して示したブロックはエンコーディング装置100のエレメントを論理的に区別して示している。よって、上述したエンコーディング装置100のエレメントは、ディバイスの設計に応じて一つのチップまたは複数のチップに取り付けられる。一実施例によると、上述したエンコーディング装置100のの各エレメントの動作はプロセッサ(図示せず)によって行われる。
【0044】
図2は、本発明の実施例によるビデオ信号デコーディング装置の200概略的なブロック図である。図2を参照すると、本明細書のデコーディング装置200は、エントロピーデコーディング部210、逆量子化部220、逆変換部225、フィルタリング部230、及び予測部250を含む。
【0045】
エントロピーデコーディング部210は、ビデオ信号ビットストリームをエントロピーデコードし、各領域に対する変換係数情報、イントラ符号化情報、インター符号化情報などを抽出する。例えば、エントロピーデコーディング部210は、ビデオ信号ビットストリームから特定領域の変換係数情報に対する二進化コードを取得することができる。また、エントロピーデコーディング部210は二進化コードを逆二進化し、量子化された変換係数を取得する。逆量子化部220は量子化された変換係数を逆量子化し、逆変換部225は、逆量子化された変換係数を用いてレジデュアル値を復元する。ビデオ信号処理装置200は、逆変換部225から取得したレジデュアル値を、予測部250から取得した予測値と合算して、元来の画素値を復元する。
【0046】
一方、フィルタリング部230は、ピクチャに対するフィルタリングを行って画質を向上させる。ここには、ブロック歪曲現象を減少させるためのデブロッキングフィルタ及び/またはピクチャ全体の歪曲を除去するための適応的ループフィルタなどが含まれる。フィルタリングを経たピクチャは出力されるか、次のピクチャに対する参照ピクチャとして利用するために復号ピクチャバッファ(DPB)256に貯蔵される。
【0047】
予測部250は、イントラ予測部252及びインター予測部254を含む。予測部250は、前述したエントロピーデコーディング部210を通じて復号化された符号化タイプ、各領域に対する変換係数、イントラ/インター符号化情報などを活用して予測ピクチャを生成する。復号化が遂行される現在ブロックを復元するために、現在ブロックが含まれた現在ピクチャまたは他のピクチャの復号化された領域が利用できる。 復元に現在ピクチャだけを用いる、すなわち、イントラ予測又はイントラBC予測を行うピクチャ(又は、タイル/スライス)をイントラピクチャ又はIピクチャ(又は、タイル/スライス)、イントラ予測、インター予測及びイントラBC予測を全て行うことができるピクチャ(又は、タイル/スライス)を、インターピクチャ(又は、タイル/スライス)という。インターピクチャ(又は、タイル/スライス)のうち、各ブロックのサンプル値を予測するために、最大で1つのモーションベクトル及び参照ピクチャインデックスを用いるピクチャ(又は、タイル/スライス)を、予測ピクチャ(predictive picture)又はPピクチャ(又は、タイル/スライス)といい、最大で2つのモーションベクトル及び参照ピクチャインデックスを用いるピクチャ(又は、タイル/スライス)を、双予測ピクチャ(Bi-predictive picture)又はBピクチャ(又は、タイル/スライス)という。 言い換えると、Pピクチャ(または、タイル/スライス)は各ブロックを予測するために最大1つの動き情報セットを用いて、Bピクチャ(または、タイル/スライス)は各ブロックを予測するために最大2つの動き情報セットを用いる。ここで、動き情報セットは1つ以上の動きベクトルと1つの参照ピクチャインデックスを含む。
【0048】
イントラ予測部252は、イントラ符号化情報及び現在ピクチャ内の復元されたサンプルを利用して予測ブロックを生成する。上述したように、イントラ符号化情報は、イントラ予測モード、MPM(MOST Probable Mode)フラッグ、MPMインデックスのうち少なくとも一つを含む。イントラ予測部252は、現在ブロックの左側及び/または上側に位置する復元されたサンプルを参照サンプルとして利用して、現在ブロックのサンプル値を予測する。本開示において、復元されたサンプル、参照サンプル、及び現在ブロックのサンプルはピクセルを示す。また、サンプル値(sample value)はピクセル値を示す。
【0049】
一実施例において、参照サンプルは現在ブロックの周辺ブロックに含まれたサンプルである。例えば、参照サンプルは現在ブロックの左側境界に隣接したサンプル及び/または上側境界に隣接したサンプルである。また、参照サンプルは現在ブロックの周辺ブロックのサンプルのうち、現在ブロックの左側境界から予め設定された距離以内のライン上に位置するサンプル及び/または現在ブロックの上側境界から予め設定された距離以内のライン上に位置するサンプルである。この際、現在ブロックの周辺ブロックは、現在ブロックに隣接した左側(L)ブロック、上側(A)ブロック、下左側(Below Left、BL)ブロック、右上側(Above Right、AR)ブロック、または左上側(Above Left、AL)ブロックのうち少なくとも一つを含む。
【0050】
インター予測部254は、復号ピクチャバッファ256に貯蔵された参照ピクチャ及びインター符号化情報を利用して予測ブロックを生成する。インター符号化情報は、参照ブロックに対する現在ブロックのモーション情報セット(参照ピクチャインデックス、モーションベクトルなど)を含む。インター予測には、L0予測、L1予測、及び双予測(Bi-prediction)がある。L0予測はL0ピクチャリストに含まれた一つの参照ピクチャを利用した予測であり、L1予測はL1ピクチャリストに含まれた一つの参照ピクチャを利用した予測を意味する。そのためには、1セットのモーション情報(例えば、モーションベクトル及び参照ピクチャインデックス)が必要である。双予測方式では最大2つの参照領域を利用するが、この2つの参照領域は同じ参照ピクチャに存在してもよく、互いに異なるピクチャにそれぞれ存在してもよい。つまり、双予測方式では最大2セットのモーション情報(例えば、モーションベクトル及び参照ピクチャインデックス)が利用されるが、2つのモーションベクトルが同じ参照ピクチャインデックスに対応してもよく、互いに異なる参照ピクチャインデックスに対応してもよい。この際、参照ピクチャは時間的に現在ピクチャの以前や以降のいずれにも表示(または出力)される。 一実施例によって、双予測方式では、使用される2個の参照領域は、L0ピクチャリスト及びL1ピクチャリストのそれぞれから選択された領域であってよい。
【0051】
インター予測部254は、モーションベクトル及び参照ピクチャインデックスを利用して現在の参照ブロックを獲得する。前記参照ブロックは、参照ピクチャインデックスに対応する参照ピクチャ内に存在する。また、モーションベクトルによって特定されたブロックのサンプル値またはこれの補間(interpolation)された値が現在ブロックの予測子(predictor)として利用される。サブペル(sub-pel)単位のピクセル正確度を有するモーション予測のために、例えば、輝度信号に対して8-タブ補間フィルタが、色差信号に対して4-タブ補間フィルタが使用される。但し、サブペル単位のモーション予測のための補間フィルタはこれに限らない。このように、インター予測部254は、以前復元されたピクチャから現在ユニットのテクスチャを予測するモーション補償(motion compensation)を行う。この際、インター予測部はモーション情報セットを利用する。
【0052】
更なる実施例によって、予測部250は、イントラBC予測部(図示せず)を含むことができる。イントラBC予測部は、現在ピクチャ内の復元されたサンプルを含む特定領域を参照して現在領域を復元することができる。イントラBC予測部は、エントロピーデコーディング部210から、現在領域に対するイントラBC符号化情報を取得する。イントラBC予測部は、現在ピクチャ内の特定領域を指示する現在領域のブロックベクトル値を取得する。イントラBC予測部は、取得されたブロックベクトル値を用いてイントラBC予測を行うことができる。イントラBC符号化情報は、ブロックベクトル情報を含むことができる。
【0053】
前記イントラ予測部252又はインター予測部254から出力された予測値、及び逆変換部225から出力されたレジデュアル値が合算されて復元されたビデオピクチャが生成される。すなわち、ビデオ信号デコーディング装置200は、予測部250で生成された予測ブロックと逆変換部225から取得されたレジデュアルを用いて現在ブロックを復元する。
【0054】
一方、図2のブロック図は本発明の一実施例によるデコーディング装置200を示し、分離して示したブロックはデコーディング装置200のエレメントを論理的に区別して示している。よって、上述したデコーディング装置200のエレメントは、ディバイスの設計に応じて一つのチップまたは複数のチップに取り付けられる。一実施り例によると、上述したデコーディング装置200のの各エレメントの動作はプロセッサ(図示せず)によって行われる。
【0055】
図3は、ピクチャ内でコーディングツリーユニット(Coding Tree Unit、CTU)がコーディングユニット(Coding Units、CUs)に分割される実施例を示している。ビデオ信号のコーディング過程において、ピクチャはコーディングツリーユニット(CTU)のシーケンスに分割される。コーディングツリーユニットは、輝度サンプルのNXNブロックと、それに対応する色差サンプルの2つのブロックからなる。コーディングツリーユニットは、複数のコーディングユニットに分割される。コーディングツリーユニットは分割されずにリーフノードになってもよい。この場合、コーディングツリーユニット自体がコーディングユニットになり得る。コーディングユニットは上述したビデオ信号の処理過程、つまり、イントラ/インター予測、変換、量子化及び/またはエントロピーコーディングなどの過程でピクチャを処理するための基本単位を指す。一つのピクチャ内において、コーディングユニットのサイズ及び模様は一定ではない。コーディングユニットは正方形または長方形の模様を有する。長方形コーディングユニット(または、長方形ブロック)は垂直コーディングユニット(または、垂直ブロック)と水平コーディングユニット(または、水平ブロック)を含む。本明細書において、垂直ブロックは高さが幅より大きいブロックであり、水平ブロックは幅が高さより大きいブロックである。また、本明細書において、正方形ではない(non-square)ブロックは長方形ブロックを指すが、本発明はこれに限らない。
【0056】
図3を参照すると、コーディングツリーユニットは、まずクォードツリー(Quad Tree、QT)構造に分割される。つまり、クォードツリー構造において、2N×2Nのサイズを有する一つのノードはN×Nのサイズを有する4つのノードに分割される。本明細書において、クォードツリーは4進(quaternary)ツリーとも称される。クォードツリー分割は再帰的に行われ、全てのノードが同じ深さに分割される必要はない。
【0057】
一方、上述したクォードツリーのリーフノード(leaf node)は、マルチ-タイプツリー(Multi-Type Tree、MTT)構造に更に分割される。本発明の実施例によると、マルチタイプツリー構造では一つのノードが水平または垂直分割の2進(binary、バイナリー)または3進(ternary、ターナリー)ツリー構造に分割される。つまり、マルチ-タイプツリー構造には、垂直バイナリー分割、水平バイナリー分割、垂直ターナリー分割、及び水平ターナリー分割の4つの分割構造が存在する。本発明の実施例によると、前記各ツリー構造において、ノードの幅及び高さはいずれも2の累乗値を有する。例えば、バイナリーツリー(binary Tree、BT)構造において、2N×2Nのサイズのノードは垂直バイナリー分割によって2つのN×2Nノードに分割され、水平バイナリー分割によって2つの2N×Nノードに分割される。また、ターナリーツリー(Ternary Tree、TT)構造において、2N×2Nのサイズのノードは垂直ターナリー分割によって(N/2)×2N、N×2N及び(N/2)×2Nのノードに分割され、水平ターナリー分割によって2N×(N/2)、2N×N及び2N×(N/2)のノードに分割される。このようなマルチ-タイプツリー分割は再帰的に行われる。
【0058】
マルチタイプツリーのリーフノードは、コーディングユニットになり得る。コーディングユニットが最大変換長に比べて大きくない場合、当該コーディングユニットはそれ以上の分割無しで予測及び/又は変換の単位として用いられてよい。一実施例として、現在コーディングユニットの幅又は高さが最大変換長よりも大きい場合に、現在コーディングユニットは、分割に関する明示的シグナリング無しで複数の変換ユニットに分割されてよい。 一方、上述したクォードツリー及びマルチ-タイプツリーにおいて、次のパラメータのうち少なくとも一つが事前に定義されるか、PPS、SPS、VPSなどのような上位レベルセットのRBSPを介して伝送される。1)CTUサイズ:クォードツリーのルートノード(root node)のサイズ、2)最小QTサイズ(MinQtSize):許容された最小QTリーフノードのサイズ、3)最大BTサイズ(MaxBtSize):許容された最大BTルートノードのサイズ、4)最大TTサイズ(MaxTtSize):許容された最大TTルートノードのサイズ、5)最大MTT深さ(MaxMttDepth):QTのリーフノードからのMTT分割の最大許容深さ、6)最小BTサイズ(MinBtSize):許容された最小BTリーフノードのサイズ、7)最小TTサイズ:許容された最小TTリーフノードのサイズ。
【0059】
図4は、クアッドツリー及びマルチタイプツリーの分割をシグナルする方法の一実施例を示す。前述したクアッドツリー及びマルチタイプツリーの分割をシグナルするために、既に設定されたフラグが用いられてよい。図4を参照すると、ノードの分割されるか否かを示すフラグ‘split_cu_flag’、クアッドツリーノードの分割されるか否かを示すフラグ‘split_qt_flag’、マルチタイプツリーノードの分割方向を示すフラグ‘mtt_split_cu_vertical_flag’、又はマルチタイプツリーノードの分割形態を示すフラグ‘mtt_split_cu_binary_flag’のうち少なくとも一つが用いられてよい。
【0060】
本発明の実施例によれば、現在ノードの分割されるか否かを示すフラグである‘split_cu_flag’がまずシグナルされてよい。‘split_cu_flag’の値が0である場合、現在ノードが分割されないことを示し、現在ノードはコーディングユニットになる。現在ノードがコーティングツリーユニットである場合、コーディングツリーユニットは、分割されていない一つのコーディングユニットを含む。現在ノードがクアッドツリーノード‘QT node’である場合、現在ノードはクアッドツリーのリーフノード‘QT leaf node’であり、コーディングユニットになる。現在ノードがマルチタイプツリーノード‘MTT node’である場合、現在ノードはマルチタイプツリーのリーフノード‘MTT leaf node’であり、コーディングユニットになる。
【0061】
‘split_cu_flag’の値が1である場合、現在ノードは‘split_qt_flag’の値によってクアッドツリー又はマルチタイプツリーのノードに分割されてよい。コーディングツリーユニットは、クアッドツリーのルートノードであり、クアッドツリー構造にまず分割されてよい。クアッドツリー構造では、それぞれのノード‘QT node’別に‘split_qt_flag’がシグナルされる。‘split_qt_flag’の値が1である場合、当該ノードは4個の正方形ノードに分割され、‘qt_split_flag’の値が0である場合、当該ノードはクアッドツリーのリーフノード‘QT leaf node’になり、当該ノードはマルチタイプノードに分割される。本発明の実施例によれば、現在ノードの種類によってクアッドツリー分割は制限されることがある。現在ノードがコーディングツリーユニット(クアッドツリーのルートノード)又はクアッドツリーノードである場合に、クアッドツリー分割が許容されてよく、現在ノードがマルチタイプツリーノードである場合に、クアッドツリー分割は許容されなくてよい。それぞれのクアッドツリーリーフノード‘QT leaf node’は、マルチタイプツリー構造にさらに分割されてよい。上述したように、‘split_qt_flag’が0である場合に、現在ノードはマルチタイプノードに分割されてよい。分割方向及び分割形態を示すために、‘mtt_split_cu_vertical_flag’及び‘mtt_split_cu_binary_flag’がシグナルされてよい。‘mtt_split_cu_vertical_flag’の値が1である場合、ノード‘MTT node’の垂直分割を示し、‘mtt_split_cu_vertical_flag’の値が0である場合、ノード‘MTT node’の水平分割を示す。また、‘mtt_split_cu_binary_flag’の値が1である場合、ノード‘MTT node’は2個の長方形ノードに分割され、‘mtt_split_cu_binary_flag’の値が0である場合、ノード‘MTT node’は3個の長方形ノードに分割される。
【0062】
コーティングのためのピクチャ予測(モーション補償)はそれ以上分けられないコーディングユニット(つまり、コーディングユニットツリーのリーフノード)を対象に行われる。このような予測を行う基本単位を、以下では予測ユニット(prediction unit)または予測ブロック(prediction block)という。
【0063】
以下、本明細書で使用されるユニットという用語は、予測を行う基本単位である前記予測ユニットを代替する用語として使用される。但し、本発明はこれに限らず、より広い意味では、前記コーディングユニットを含む概念として理解される。
【0064】
図5及び図6は、本発明の実施例によるイントラ予測方法をより詳しく示す図である。上述したように、イントラ予測部は、現在ブロックの左側及び/または上側に位置する復元されたサンプルを参照サンプルとして利用して、現在ブロックのサンプル値を予測する。
【0065】
まず、図5はイントラ予測モードで現在ブロックを予測するために使用される参照サンプルの一実施例を示す。一実施例によると、参照サンプルは現在ブロックの左側境界に隣接したサンプル及び/または上側境界に隣接したサンプルである。図5に示したように、現在ブロックのサイズがW×Hで現在ブロックに隣接した単一参照ライン(line)のサンプルがイントラ予測に使用されれば、現在ブロックの左側及び/または上側に位置した最大2W+2H+1個の周辺サンプルを使用して参照サンプルが設定される。
【0066】
また、参照サンプルとして使用される少なくとも一部のサンプルがまだ復元されていなければ、イントラ予測部は参照サンプルパッディング過程を行って参照サンプルを獲得する。また、イントラ予測部は、イントラ予測の誤差を減らすために参照サンプルフィルタリング過程を行う。つまり、周辺サンプル及び/または参照サンプルパッディング過程によって獲得された参照サンプルにフィルタリングを行って、フィルタリングされた参照サンプルを獲得する。 イントラ予測部は、このように取得された参照サンプルを用いて現在ブロックのサンプルを予測する。イントラ予測部は、フィルタリングされない参照サンプル又はフィルタリングされた参照サンプルを用いて現在ブロックのサンプルを予測する。本開示において、周辺サンプルは、少なくとも一つの参照ライン上のサンプルを含むことができる。例えば、周辺サンプルは、現在ブロックの境界に隣接したライン上の隣接サンプルを含むことができる。
【0067】
次に、図6はイントラ予測に使われる予測モードの一実施形態を図示する。イントラ予測のために、イントラ予測方向を指示するイントラ予測モード情報がシグナリングできる。イントラ予測モード情報は、イントラ予測モードセットを構成する複数のイントラ予測モードのうち、いずれか1つを指示する。現在ブロックがイントラ予測されたブロックである場合、デコーダーはビットストリームから現在ブロックのイントラ予測モード情報を受信する。デコーダのイントラ予測部は、抽出されたイントラ予測モード情報に基づいて現在ブロックに対するイントラ予測を遂行する。
【0068】
本発明の実施例によると、イントラ予測モードセットは、イントラ予測に使用される全てのイントラ予測モード(例えば、総67個のイントラ予測モード)を含む。より詳しくは、イントラ予測モードセットは、平面モード、DCモード、及び複数の(例えば、65個の)角度モード(つまり、方向モード)を含む。 それぞれのイントラ予測モードは、予め設定されたインデックス(つまり、イントラ予測モードインデックス)を介して指示される。例えば、図6に示したように、イントラ予測モードインデックス0は平面(planar)モードを指示し、イントラ予測モードインデックス1はDCモードを指示する。また、イントラ予測モードインデックス2乃至66は、互いに異なる角度モードをそれぞれ指示する。 角度モードは、既に設定された角度範囲以内の異なる角度をそれぞれ指示する。例えば、角度モードは時計回り方向に45°~-135°の角度範囲(すなわち、第1角度範囲)以内の角度を指示できる。前記角度モードは12時方向を基準に定義されてよい。この際、イントラ予測モードインデックス2は水平対角(Horizontal Diagonal、HDIA)モードを指示し、イントラ予測モードインデックス18は水平(Horizontal、HOR)モードを指示し、イントラ予測モードインデックス34は対角(Diagonal、DIA)モードを指示し、イントラ予測モードインデックス50は水直(Vertical、VER)モードを指示し、イントラ予測モードインデックス66は垂直対角(Vertical Diagonal、VDIA)モードを指示する。
【0069】
一方、既に設定された角度範囲は、現在ブロックの形態によって個別に設定されてよい。例えば、現在ブロックが長方形ブロックであれば、時計回り方向に45°を超える或いは-135°未満の角度を示す広角モードがさらに用いられてよい。現在ブロックが水平ブロックであれば、角度モードは、時計回り方向に(45+offset 1)°~(-135+offset 1)°の角度範囲(すなわち、第2角度範囲)以内の角度を示すことができる。このとき、第1角度範囲を外れる角度モード67~76がさらに用いられてよい。また、現在ブロックが垂直ブロックであれば、角度モードは、時計回り方向に(45-offset 2)°~(-135-offset 2)の角度範囲(すなわち、第3角度範囲)以内の角度を示すことができる。このとき、第1角度範囲を外れる角度モード-10~-1がさらに用いられてよい。本発明の実施例によれば、offset 1及びoffset 2の値は、長方形ブロックの幅と高さとの比率によって個別に決定されてよい。また、offset 1及びoffset 2は正数であってよい。
【0070】
本発明の更なる実施例によれば、イントラ予測モードセットを構成する複数の角度モードは、基本角度モードと拡張角度モードを含むことができる。このとき、拡張角度モードは基本角度モードに基づいて決定されてよい。
【0071】
一実施例によれば、基本角度モードは、既存HEVC(High Efficiency Video Coding)標準のイントラ予測で用いられる角度に対応するモードであり、拡張角度モードは、次世代ビデオコーデック標準のイントラ予測で新しく追加される角度に対応するモードであってよい。より具体的に、基本角度モードは、イントラ予測モード{2,4,6,…,66}のいずれか一つに対応する角度モードであり、拡張角度モードは、イントラ予測モード{3,5,7,…,65}のいずれか一つに対応する角度モードであってよい。すなわち、拡張角度モードは、第1角度範囲内で基本角度モード間の角度モードであってよい。したがって、拡張角度モードが示す角度は、基本角度モードが示す角度に基づいて決定されてよい。
【0072】
他の実施例によれば、基本角度モードは、既に設定された第1角度範囲以内の角度に対応するモードであり、拡張角度モードは、前記第1角度範囲を外れる広角モードであってよい。すなわち、基本角度モードは、イントラ予測モード{2,3,4,…,66}のいずれか一つに対応する角度モードであり、拡張角度モードは、イントラ予測モード{-10,-9,…,-1}及び{67,68,…,76}のいずれか一つに対応する角度モードであってよい。拡張角度モードが示す角度は、対応する基本角度モードが示す角度の反対側の角度と決定されてよい。したがって、拡張角度モードが示す角度は、基本角度モードが示す角度に基づいて決定されてよい。一方、拡張角度モードの個数はこれに限定されず、現在ブロックのサイズ及び/又は形態によって更なる張角度が定義されてよい。例えば、拡張角度モードは、イントラ予測モード{-14,-13,…,-1}及び{67,68,…,80}のいずれか一つに対応する角度モードと定義されてよい。一方、イントラ予測モードセットに含まれるイントラ予測モードの総個数は、前述した基本角度モードと拡張角度モードの構成によって可変してよい。
【0073】
上記の実施例において、拡張角度モード間の間隔は、対応する基本角度モード間の間隔に基づいて設定されてよい。例えば、拡張角度モード{3,5,7,…,65}間の間隔は、対応する基本角度モード{2,4,6,…,66}間の間隔に基づいて決定されてよい。また、拡張角度モード{-10,-9,…,-1}間の間隔は、対応する反対側の基本角度モード{56,57,…,65}間の間隔に基づいて決定され、拡張角度モード{67,68,…,76}間の間隔は、対応する反対側の基本角度モード{3,4,…,12}間の間隔に基づいて決定されてよい。拡張角度モード間の角度間隔は、対応する基本角度モード間の角度間隔と同一となるように設定されてよい。また、イントラ予測モードセットにおいて拡張角度モードの個数は、基本角度モードの個数以下に設定されてよい。
【0074】
本発明の実施例によれば、拡張角度モードは、基本角度モードに基づいてシグナルされてよい。例えば、広角モード(すなわち、拡張角度モード)は、第1角度範囲以内の少なくとも一つの角度モード(すなわち、基本角度モード)を代替することができる。代替される基本角度モードは、広角モードの反対側に対応する角度モードであってよい。すなわち、代替される基本角度モードは、広角モードが示す角度の反対方向の角度に対応するか或いは前記反対方向の角度から既に設定されたオフセットインデックスだけの差を有する角度に対応する角度モードである。本発明の実施例によれば、既に設定されたオフセットインデックスは、1である。代替される基本角度モードに対応するイントラ予測モードインデックスは、広角モードに再びマップされ、当該広角モードをシグナリングできる。例えば、広角モード{-10,-9,…,-1}は、イントラ予測モードインデックス{57,58,…,66}によってそれぞれシグナルされてよく、広角モード{67,68,…,76}は、イントラ予測モードインデックス{2,3,…,11}によってそれぞれシグナルされてよい。このように基本角度モードのためのイントラ予測モードインデックスで拡張角度モードをシグナルすることにより、各ブロックのイントラ予測に用いられる角度モードの構成が互いに異なっても、同じセットのイントラ予測モードインデックスがイントラ予測モードのシグナリングに用いられてよい。したがって、イントラ予測モード構成の変化によるシグナリングオーバーヘッドが最小化し得る。
【0075】
一方、拡張角度モードの使用されるか否かは、現在ブロックの形態及びサイズのうち少なくとも一つに基づいて決定されてよい。一実施例によれば、現在ブロックのサイズが既に設定されたサイズよりも大きい場合、拡張角度モードが現在ブロックのイントラ予測のために用いられ、そうでない場合、基本角度モードのみが現在ブロックのイントラ予測のために用いられてよい。他の実施例によれば、現在ブロックが正方形以外のブロックである場合、拡張角度モードが現在ブロックのイントラ予測のために用いられ、現在ブロックが正方形ブロックである場合、基本角度モードのみが現在ブロックのイントラ予測のために用いられてよい。
【0076】
以下、図7を参照して、本発明の一実施形態によるインター予測方法について説明する。本明細書で説明されるインター予測方法は、並進運動(translation motion)に最適化された一般的なインター予測方法およびアフィン(affine)モデルベースのインター予測方法を含むことができる。さらに、動きベクトルは、一般的なインター予測方法による動き補償のための一般的な動きベクトルと、アフィン動き補償のための制御点動きベクトルのうちの少なくとも1つとを含むことができる。
【0077】
図7は、本発明の一実施例に係るインター予測方法を示す図である。前述したように、デコーダは、復号化された他のピクチャーの復元されたサンプルを参照して現在ブロックを予測することができる。図7を参照すると、デコーダは、現在ブロック701のモーション情報セットに基づいて参照ピクチャー720内の参照ブロック702を取得する。このとき、モーション情報セットは、参照ピクチャーインデックス及びモーションベクトル703を含むことができる。参照ピクチャーインデックスは、参照ピクチャーリストにおいて現在ブロックのインター予測のための参照ブロックが含まれた参照ピクチャー720を示す。一実施例によって、参照ピクチャーリストは、前述したL0ピクチャーリスト又はL1ピクチャーリストのうち少なくとも一つを含むことができる。モーションベクトル703は、現在ピクチャー710内で現在ブロック701の座標値と参照ピクチャー720内で参照ブロック702の座標値とのオフセットを表す。デコーダは、参照ブロック702のサンプル値に基づいて現在ブロック701の予測子を取得し、該予測子を用いて現在ブロック701を復元する。
【0078】
具体的に、エンコーダは、復元順序が先であるピクチャーから現在ブロックと類似のブロックを探索し、前述した参照ブロックを取得できる。例えば、エンコーダは、既に設定された探索領域内で現在ブロックとサンプル値との差の和が最小となる参照ブロックを探索するこができる。このとき、現在ブロックと参照ブロックのサンプル間の類似度を測定するために、SAD(sum of absolute difference)又はSATD(sum of hadamard transformed difference)のうち少なくとも一つが用いられてよい。ここで、SADは、両ブロックに含まれたサンプル値の差のそれぞれの絶対値を全て合算した値であってよい。また、SATDは、両ブロックに含まれたサンプル値の各差をアダマール変換(hadamard transform)して取得されたアダマール変換係数の絶対値を全て合算した値であってよい。
【0079】
一方、現在ブロックは、一つ以上の参照領域を用いて予測されてよい。前述したように、現在ブロックは、2個以上の参照領域を利用する双予測方式によってインター予測されてよい。一実施例によって、デコーダは、現在ブロックの2個のモーション情報セットに基づいて2個の参照ブロックを取得することができる。また、デコーダは、取得された2個の参照ブロックのそれぞれのサンプル値に基づいて現在ブロックの第1予測子及び第2予測子を取得することができる。また、デコーダは、第1予測子及び第2予測子を用いて現在ブロックを復元することができる。例えば、デコーダは、第1予測子及び第2予測子のサンプル別平均に基づいて現在ブロックを復元することができる。
【0080】
前述したように、現在ブロックのモーション補償のために、一つ以上のモーション情報セットがシグナルされてよい。このとき、複数のブロックのそれぞれのモーション補償のためのモーション情報セット間の類似性が用いられてよい。例えば、現在ブロックの予測に用いられるモーション情報セットは、既に復元された他のサンプルのいずれか一つの予測に用いられたモーション情報セットから誘導されてよい。これにより、エンコーダ及びデコーダはシグナリングオーバーヘッドを減少させることができる。以下では、現在ブロックのモーション情報セットがシグナルされる様々な実施例について説明する。
【0081】
図8は、本発明の一実施例に係る、現在ブロックのモーションベクトルがシグナルされる方法を示す図である。本発明の一実施例によって、現在ブロックのモーションベクトルは、現在ブロックのモーションベクトル予測子(motion vector predictor,MVP)から誘導されてよい。一実施例によって、現在ブロックのモーションベクトルを誘導するために参照されるモーションベクトル予測子は、モーションベクトル予測子(motion vector predictor,MVP)候補リストを用いて取得できる。MVP候補リストは、既に設定された個数のMVP候補Candidate 1,Candidate 2,...,Candidate Nを含むことができる。
【0082】
一実施例によって、MVP候補リストは、空間的候補又は時間的候補のうち少なくとも一つを含むことができる。空間的候補は、現在ピクチャー内で現在ブロックから一定の範囲以内の周辺ブロックの予測に用いられたモーション情報セットであってよい。空間的候補は、現在ブロックの周辺ブロックのうち利用可能な周辺ブロックに基づいて構成されてよい。また、時間的候補は、現在ピクチャーと他のピクチャー内のブロックの予測に用いられたモーション情報セットであってよい。例えば、時間的候補は、特定参照ピクチャー内で現在ブロックの位置に対応する特定ブロックに基づいて構成されてよい。このとき、特定ブロックの位置は、前記参照ピクチャー内で特定ブロックの左上端(top-left)サンプルの位置を表す。更なる実施例によって、MVP候補リストは、ゼロモーションベクトルを含むことができる。更なる実施例によって、現在ブロックのMVP候補リストが含むMVP候補に対するラウンディング(rounding)プロセスが行われてよい。このとき、後述する現在ブロックのモーションベクトル差分値のレゾリューションが用いられてよい。例えば、現在ブロックのMVP候補はそれぞれ、現在ブロックのモーションベクトル差分値のレゾリューションに基づいてラウンドされてよい。
【0083】
本開示において、MVP候補リストは、改善された時間的モーションベクトル候補(advanced temporal motion vector prediction,ATMVP)リスト、マージインター予測のためのマージ候補リスト、アフィンモーション補償のためのコントロールポイントモーションベクトル候補リスト、サブブロックベースのモーション補償のための時間的モーションベクトル候補(subblock-based temporal motion vecto prediction,STMVP)リスト、及びこれらの組合せを含むことができる。
【0084】
一実施例によって、エンコーダ810及びデコーダ820は、現在ブロックのモーション補償のためのMVP候補リストを構成することができる。例えば、現在ブロックよりも先に復元されたサンプルのうち、現在ブロックのモーション情報セットと同一又は類似するモーション情報セットに基づいて予測されている可能性のあるサンプルに対応する候補が存在してよい。エンコーダ810及びデコーダ820は、当該複数の候補ブロックに基づいて現在ブロックのMVP候補リストを構成することができる。このとき、エンコーダ810及びデコーダ820は、エンコーダ810とデコーダ820との間にあらかじめ定義された規則にしたがって、MVP候補リストを構成することができる。すなわち、エンコーダ810とデコーダ820のそれぞれにおいて構成されたMVP候補リストは、互いに同一であってよい。
【0085】
また、あらかじめ定義された規則は、現在ブロックの予測モードによって変わってよい。例えば、現在ブロックの予測モードがアフィンモデルベースのアフィン予測モードである場合に、エンコーダ及びデコーダは、アフィンモデルに基づく第1方法を用いて現在ブロックのMVP候補リストを構成することができる。第1方法は、コントロールポイントモーションベクトル候補リストを取得する方法であってよい。これに対し、現在ブロックの予測モードがアフィンモデルに基づいていない一般インター予測モードである場合、エンコーダ及びデコーダは、アフィンモデルに基づいていない第2方法を用いて現在ブロックのMVP候補リストを構成することができる。このとき、第1方法と第2方法は、互いに異なる方法であってよい。
【0086】
デコーダ820は、現在ブロックのMVP候補リストが含む少なくとも一つのMVP候補のいずれか一つに基づいて現在ブロックのモーションベクトルを誘導することができる。例えば、エンコーダ810は、現在ブロックのモーションベクトルを誘導するために参照されるモーションベクトル予測子を指示するMVPインデックス(index)をシグナルすることができる。デコーダ820は、シグナルされたMVPインデックスに基づいて現在ブロックのモーションベクトル予測子を取得することができる。デコーダ820は、モーションベクトル予測子を用いて現在ブロックのモーションベクトルを誘導することができる。一実施例によって、デコーダ820は、MVP候補リストから取得されたモーションベクトル予測子を、別のモーションベクトル差分値無しで、現在ブロックのモーションベクトルとして使用することができる。デコーダ820は、現在ブロックのモーションベクトルに基づいて現在ブロックを復元することができる。MVP候補リストから取得されたモーションベクトル予測子が別のモーションベクトル差分値無しで現在ブロックのモーションベクトルとして使用されるインター予測モードは、マージモードと呼ぶことができる。
【0087】
他の実施例によって、デコーダ820は、現在ブロックのモーションベクトルのための別のモーションベクトル差分値(motion vector difference)を取得することができる。デコーダ820は、MVP候補リストから取得されたモーションベクトル予測子と現在ブロックのモーションベクトル差分値とを合算して現在ブロックのモーションベクトルを取得することができる。この場合、エンコーダ810は、現在ブロックのモーションベクトルとモーションベクトル予測子間の差を表すモーションベクトル(motion vector,MV)差分値(MV difference)をシグナルすることができる。モーションベクトル差分値がシグナルされる方法については、図9で具体的に説明する。デコーダ820は、モーションベクトル差分値(MV difference)に基づいて現在ブロックのモーションベクトルを取得することができる。デコーダ820は、現在ブロックのモーションベクトルに基づいて現在ブロックを復元することができる。
【0088】
さらに、現在ブロックのモーション補償のための参照ピクチャーインデックスがシグナルされてよい。エンコーダ810は、参照ブロックを含む参照ピクチャーを指示する参照ピクチャーインデックスをシグナルすることができる。デコーダ820は、シグナルされた参照ピクチャーインデックスに基づいて現在ブロックの復元に参照される参照ピクチャーのPOCを取得することができる。このとき、参照ピクチャーのPOCが現在ブロックのモーションベクトルを誘導するために参照されるMVPに対応する参照ピクチャーのPOCと互いに異なってよい。この場合、デコーダ820は、モーションベクトルスケーリングを行うことができる。すなわち、デコーダ820は、MVPをスケーリングしてMVP’を取得することができる。このとき、モーションベクトルスケーリングは、現在ピクチャーのPOC、現在ブロックのシグナルされた参照ピクチャーのPOC及びMVPに対応する参照ピクチャーのPOCに基づいて行われてよい。また、デコーダ820は、MVP’を現在ブロックのモーションベクトル予測子として使用することができる。
【0089】
前述したように、現在ブロックのモーションベクトルは、現在ブロックのモーションベクトル予測子とモーションベクトル差分値を合算して取得できる。このとき、モーションベクトル差分値は、エンコーダからシグナルされてよい。エンコーダは、モーションベクトル差分値をエンコードし、モーションベクトル差分値を示す情報を生成し、シグナルすることができる。以下では、本発明の一実施例によってモーションベクトル差分値がシグナルされる方法について説明する。
【0090】
図9は、本発明の一実施例に係る現在ブロックのモーションベクトル差分値がシグナルされる方法を示す図である。一実施例によって、モーションベクトル差分値を示す情報は、モーションベクトル差分値の絶対値情報又はモーションベクトル差分値の符号情報のうち少なくとも一つを含むことができる。モーションベクトル差分値の絶対値と符号は、別個にエンコードされてよい。
【0091】
一実施例によって、モーションベクトル差分値の絶対値は、値自体でシグナルされてもよい。エンコーダは、モーションベクトル差分値の絶対値の特性を示す少なくとも一つのフラグを用いて、シグナルされる値のサイズを減らすことができる。デコーダは、シグナルされた値から、少なくとも一つのフラグを用いてモーションベクトル差分値の絶対値を誘導することができる。
【0092】
例えば、少なくとも一つのフラグは、モーションベクトル差分値の絶対値がNよりも大きいか否かを示す第1フラグを含むことができる。このとき、Nは整数であってよい。モーションベクトル差分値の絶対値のサイズがNよりも大きい場合、活性化された第1フラグと共に(モーションベクトル差分値の絶対値-N)値がシグナルされてよい。このとき、活性化されたフラグは、モーションベクトル差分値の絶対値のサイズがNよりも大きい場合を示すことができる。デコーダは、活性化された第1フラグ及びシグナルされた値に基づいてモーションベクトル差分値の絶対値を取得することができる。
【0093】
図9を参照すると、モーションベクトル差分値の絶対値が‘0’よりも大きいかを示す第2フラグ(abs_mvd_greater0_flag)がシグナルされてよい。第2フラグ(abs_mvd_greater0_flag[])が、モーションベクトル差分値の絶対値が‘0’よりも大きくことを示す場合、モーションベクトル差分値の絶対値は‘0’であってよい。また、第2フラグ(abs_mvd_greater0_flag)がモーションベクトル差分値の絶対値が‘0’よりも大きいことを示す場合、デコーダは、モーションベクトル差分値に対する他の情報を用いてモーションベクトル差分値の絶対値を取得することができる。
【0094】
一実施例によって、モーションベクトル差分値の絶対値が‘1’よりも大きいかを示す第3フラグ(abs_mvd_greater1_flag)がシグナルされてよい。第3フラグ(abs_mvd_greater1_flag)が、モーションベクトル差分値の絶対値が‘1’よりも大きくないことを示す場合、デコーダは、モーションベクトル差分値の絶対値が‘1’であると判断できる。
【0095】
逆に、第3フラグ(abs_mvd_greater1_flag)が、モーションベクトル差分値の絶対値が‘1’よりも大きいことを示す場合、デコーダは、モーションベクトル差分値に関するさらに他の情報を用いてモーションベクトル差分値の絶対値を取得することができる。例えば、(モーションベクトル差分値の絶対値-2)値(abs_mvd_minus2)がシグナルされてよい。モーションベクトル差分値の絶対値が‘1’よりも大きい場合、モーションベクトル差分値の絶対値は2以上の値であり得るためである。
【0096】
前述したように、現在ブロックのモーションベクトル差分値の絶対値は、少なくとも一つのフラグに変形されてよい。例えば、モーションベクトル差分値の変形された絶対値は、モーションベクトル差分値のサイズによって(モーションベクトル差分値の絶対値-N)を示すことができる。一実施例によって、モーションベクトル差分値の変形された絶対値は、少なくとも一つのビットでシグナルされてよい。このとき、モーションベクトル差分値の変形された絶対値を示すためにシグナルされるビットの個数は、可変してよい。エンコーダは、モーションベクトル差分値の変形された絶対値を可変長二進化方法を用いてエンコードすることができる。例えば、エンコーダは、可変長二進化方法として、切断単項(truncated unary)二進化、単項(unary)二進化、切断ライス(truncated rice)又は指数ゴロム(exp-Golomb)二進化のうち少なくとも一つを用いることができる。
【0097】
また、モーションベクトル差分値の符号は、符号フラグ(mvd_sign_flag)でシグナルされてよい。一方、モーションベクトル差分値の符号は、符号ビット隠し(sign-bit-hiding)によって暗黙的にシグナルされてよい。
【0098】
一方、前述した現在ブロックのモーションベクトル差分値は、特定レゾリューション単位でシグナルされてよい。本開示において、モーションベクトル差分値のレゾリューションは、モーションベクトル差分値がシグナルされる単位を表すことができる。すなわち、本開示において、ピクチャーのレゾリューション以外のレゾリューションは、モーションベクトル差分値がシグナルされる精密度(precision)又は細密度(granularity)を表すことができる。モーションベクトル差分値のレゾリューションは、サンプル又はピクセルの単位で表現されてよい。例えば、モーションベクトル差分値のレゾリューションは、1/4(quarter)、1/2(half)、1(integer)、2、4サンプル単位のように、サンプルの単位を用いて表現されてよい。また、現在ブロックのモーションベクトル差分値のレゾリューションが小さいほど、現在ブロックのモーションベクトル差分値の精密度は増加し得る。
【0099】
本発明の一実施例によれば、モーションベクトル差分値は、様々なレゾリューションに基づいてシグナルされてよい。一実施例によって、モーションベクトル差分値の絶対値又は変形された絶対値は、整数サンプル単位の値でシグナルされてよい。または、モーションベクトル差分値の絶対値は、1/2-サブペル単位の値でシグナルされてよい。すなわち、モーションベクトル差分値のレゾリューションは、状況によって異なるように設定されてよい。本発明の一実施例に係るエンコーダ及びデコーダは、モーションベクトル差分値のための様々なレゾリューションを適切に用いて、現在ブロックのモーションベクトル差分値を効率的にシグナルすることができる。
【0100】
一実施例によって、モーションベクトル差分値のレゾリューションは、ブロック、コーディングユニット、スライス又はタイルのうち少なくとも一つの単位ごとに異なる値に設定されてよい。例えば、第1ブロックのモーションベクトル差分値の第1レゾリューションは、1/4サンプル単位であってよい。この場合、モーションベクトル差分値の絶対値‘16’を第1レゾリューションで割った値である‘64’がシグナルされてよい。また、第2ブロックのモーションベクトル差分値の第2レゾリューションは、整数サンプル単位であってよい。この場合、第2モーションベクトル差分値の絶対値‘16’を第2レゾリューションで割った値である‘16’がシグナルされてよい。このように、モーションベクトル差分値の絶対値が同一である場合にも、レゾリューションによって異なる値がシグナルされてよい。このとき、モーションベクトル差分値の絶対値をレゾリューションで割った値が少数点以下の桁数を含む場合、当該値にラウンディング関数が適用されてよい。
【0101】
エンコーダは、モーションベクトル差分値のレゾリューションに基づき、モーションベクトル差分値を示す情報をシグナルすることができる。デコーダは、シグナルされたモーションベクトル差分値から、修正されたモーションベクトル差分値を取得することができる。デコーダは、レゾリューション差分値のレゾリューションに基づいてモーションベクトル差分値を修正することができる。現在ブロックのシグナルされたモーションベクトル差分値(valuePerResolution)と修正されたモーションベクトル差分値(valueDetermined)間の関係は、下記の式1の通りである。以下、本開示において、特に言及がない限り、モーションベクトル差分値は、修正されたモーションベクトル差分値(valueDetermined)を表す。また、シグナルされたモーションベクトル差分値は、レゾリューションによって修正される前の値を表す。
【0102】
【数1】
【0103】
式1で、レゾリューション(resolution)は、現在ブロックのモーションベクトル差分値のレゾリューションを表す。すなわち、デコーダは、現在ブロックのシグナルされたモーションベクトル差分値とレゾリューションを掛けて、修正されたモーションベクトル差分値を取得することができる。次に、デコーダは、修正されたモーションベクトル差分値に基づいて現在ブロックのモーションベクトルを取得することができる。また、デコーダは、現在ブロックのモーションベクトルに基づいて現在ブロックを復元することができる。
【0104】
現在ブロックのモーションベクトル差分値のレゾリューションとして、相対的に小さい値が使用される場合(すなわち、精密度が高い場合)、現在ブロックのモーションベクトル差分値をより細密に示し易くなる。しかし、この場合、シグナルされる値自体が大きくなり、現在ブロックのモーションベクトル差分値のためのシグナリングオーバーヘッドが増加することがある。逆に、現在ブロックのモーションベクトル差分値のレゾリューションとして、相対的に大きい値が使用される場合(すなわち、精密度が低い場合)、シグナルされる値のサイズを減らし、モーションベクトル差分値のためのシグナリングオーバーヘッドを減少させることができる。すなわち、モーションベクトル差分値のレゾリューションが大きい場合、現在ブロックのモーションベクトル差分値は、現在ブロックのモーションベクトル差分値のレゾリューションが小さい場合に比べて、少ない個数のビットでシグナルされてよい。しかし、この場合、現在ブロックのモーションベクトル差分値を細密に示すことが困難であり得る。
【0105】
これにより、エンコーダ及びデコーダは、複数のレゾリューションから、状況に応じて、モーションベクトル差分値をシグナルするために有利なレゾリューションを選択することができる。例えば、エンコーダは、状況に基づいて選択されたレゾリューションをシグナルすることができる。また、デコーダは、シグナルされたレゾリューションに基づいて現在ブロックのモーションベクトル差分値を取得することができる。以下では、本発明の一実施例によって現在ブロックのモーションベクトル差分値のレゾリューションがシグナルされる方法について説明する。本発明の一実施例によって、現在ブロックのモーションベクトル差分値のレゾリューションは、レゾリューションセットが含む複数の可用レゾリューションのいずれか一つであってよい。ここで、複数の可用レゾリューションは、特定状況で使用可能なレゾリューションを表すことができる。また、レゾリューションセットが含む可用レゾリューションの種類及び個数は、状況によって変わってよい。
【0106】
図10は、本発明の一実施例に係るコーディングユニット及び変換ユニットを示す図である。
【0107】
図10(a)は、本発明の一実施例に係るコーディングユニットを示す図であり、図10(b)は、本発明の一実施例に係る変換ユニットを示す図である。
【0108】
本発明の一実施例をよれば、変換(transform)が行われるブロック(block)単位が存在してよい。例えば、変換が行われるブロック単位は、コーディングユニット(coding unit,CU)と同一であるか小さくてよく、又は予測(prediction)を行うブロック単位と同一であるか小さくてよい。また、変換が行われるブロック単位のサイズは、最大変換サイズ(maximum transform size)によって制限されてよい。例えば、変換が行われるブロック単位の幅(width)又は高さ(height)は、最大変換サイズによって制限されてよい。具体的に、変換が行われるブロック単位の幅又は高さは、最大変換サイズ以下であってよい。また、前記最大変換サイズは、変換ブロックの色差成分、すなわち、ルーマ成分、クロマ成分によって異なってよい。このとき、変換が行われるブロック単位は、変換ユニット(transform unit,TU)と表現されてよい。仮にコーディングユニット又は予測ユニット(prediction unit,PU)が最大変換サイズよりも大きい場合、コーディングユニット又は予測ユニットが分割され、複数の変換ユニットが生成されてよい。複数の変換ユニットのうち最大変換サイズよりも大きい変換ユニットは分割されてよく、複数の変換ユニットが生成されてよい。このような過程で生成された複数の変換ユニットのサイズはいずれも、最大変換サイズ以下であってよい。本発明において、ユニット(ブロック)のサイズが最大変換サイズよりも大きいということは、ユニット(ブロック)の幅又は高さが最大変換サイズよりも大きいことを意味できる。一方、ユニット(ブロック)のサイズが最大変換サイズ以下であるということは、ユニット(ブロック)の幅及び高さがいずれも最大変換サイズ以下であることを意味できる。本発明の一実施例をよれば、変換ユニットを最大変換サイズに基づいて分割する動作は、イントラ予測(intra prediction)が行われる時、残差信号(residual signal)をプロセシング(processing)する時などの状況で行われてよい。変換ユニットを最大変換サイズに基づいて分割する動作は、回帰的(recursive)に行われてよく、変換ユニットのサイズが最大変換サイズ以下になるまで行われてよい。
【0109】
図10(a)を参照すると、コーディングユニットの幅、高さはそれぞれ、cbWidth、cbHeightと表現されてよい。図10(b)を参照すると、変換ユニットの幅、高さはそれぞれ、tbWidth、tbHeightと表現されてよい。最大変換サイズは、MaxTbSizeYと表現されてよい。具体的に、MaxTbSizeYは、ルーマ(luma)成分に対する最大変換サイズであってよい。変換ユニットのサイズが最大変換サイズよりも大きいため変換ユニットが分割されなければならない場合、分割される前の変換ユニットのtbWidth、tbHeightはそれぞれ、cbWidth、cbHeightになり得る。すなわち、最大変換サイズよりも変換ユニットの幅又は高さが大きいか否かによって変換ユニットは分割されてよく、tbWidth又はtbHeightはアップデートされてよい。例えば、図10(a)を参照すると、cbWidthは、MaxTbSizeYよりも大きい。この場合、変換ユニットは分割されてよいが、変換ユニットが分割される前の変換ユニットのtbWidth、tbHeightはそれぞれ、cbWidth、cbHeightになり得る。図10(b)を参照すると、tbWidthがMaxTbSizeYよりも大きいため、TUはtransform unit 1、transform unit 2に分割されてよい。このとき、新しい変換ユニットの幅(分割後の変換ユニットの幅)であるnewTbWidthは、tbWidth/2になり得る。
【0110】
本明細書で説明する変換ユニット(transform unit,TU)分割は、TUに含まれる変換ブロック(transform block,TB)の分割を意味できる。
【0111】
本明細書ではユニットとブロックを同じ意味で使用する。また、ユニットは、色差成分による一つ以上のブロックを含む概念であってよい。例えば、ユニットは、ルーマに対するブロックとクロマに対する一つ以上のブロックを含む概念であってよい。
【0112】
図11は、本発明の一実施例に係る変換ツリーシンタックスを示す図である。
【0113】
図11のシンタックスは、図10を参照して説明したTUの分割を行うためのシンタックスであってよい。
【0114】
図11に示す変換ツリーシンタックス(transform tree syntax)は、コーディングユニットシンタックス(coding unit syntax)又は予測ユニットシンタックス(prediction unit syntax)から呼び出されてよい。このとき、変換ツリーシンタックスの入力(input)値であるtbWidth、tbHeightは、図10で説明したcbWidth、cbHeightであってよい。そして、デコーダは、tbWidthが最大変換サイズ(MaxTbSizeY)よりも大きいか否か、又はtbHeightがMaxTbSizeYよりも大きいか否かを確認することができる。確認の結果、tbwidth又はtbHeightがMaxTbSizeYよりも大きい場合、TU分割がなされてよく、変換ツリーシンタックスは再び呼び出されてよい。そうでない場合には、変換ユニットシンタックスが呼び出されてよい。このとき、変換ツリーシンタックスが再び呼び出される場合、入力値はアップデートされてよい。例えば、tbWidth又はtbHeightがMaxTbSizeYよりも大きい場合、入力値はtbWidth/2又はtbHeight/2にアップデートされてよい。図11で、アップデートされたtbWidth、tbHeightは、trafoWidth、trafoHeightと表現されてよい。また、シンタックス要素transform_tree(x0,y0,tbWidth,tbHeight,treeType)においてx0、y0は、変換ツリーシンタックスが適用されるブロックの位置を示す水平、垂直座標値であってよい。デコーダは、trafoWidth、trafoHeightの値を用いてシンタックス要素transform_tree(x0,y0,trafoWidth,trafoHeight,treeType)をパースすることができる。tbWidthがMaxTbSizeYよりも大きい場合、デコーダは、シンタックス要素transform_tree(x0+trafoWidth,y0,trafoWidth,trafoHeight,treeType)をパースすることができる。tbheightがMaxTbSizeYよりも大きい場合、デコーダは、シンタックス要素transform_tree(x0,y0+trafoHeight,trafoWidth,trafoHeight,treeType)をパースすることができる。tbWidthがMaxTbSizeYより大きく、tbHeightがMaxTbSizeYよりも大きい場合、デコーダは、シンタックス要素transform_tree(x0+trafoWidth,y0+trafoHeight,trafoWidth,trafoHeight,treeType)をパースすることができる。このとき、変換ツリーシンタックス‘tranform_tree()’が複数回呼び出される過程の順序は、エンコーダ、デコーダマッチ又は又はコーディング性能の側面で重要であり得る。このとき、順序は、既に設定された順序に従うことができ、既に設定された順序は、図11に開示されたシンタックスによる順序であってよい。
【0115】
また、図11の変換ツリーシンタックスがコーディングユニット又は予測ユニットで初めて呼び出される場合、tbWidth、tbHeight、x0、y0は、ルーマ成分を基準に設定された値であってよい。例えば、ルーマブロックのサイズが16×16であるとき、クロマフォーマット(chroma format)によるクロマブロックのサイズは、8×8であってよい。このとき、デコーダが前記クロマブロックに対する変換ツリーシンタックスをパースしても、tbWidth、tbHeight値はそれぞれ16、16であってよい。
【0116】
また、図11の変換ツリーシンタックスは、ツリー類型(treeType)値に関係なくパースされてよい。ツリー類型は、ルーマ成分のブロック構造とクロマ成分のブロック構造が同一か異なるかを示す。例えば、ツリー類型がSINGLE_TREEである場合、ルーマ成分のブロック構造とクロマ成分のブロック構造は同一であってよい。一方、ツリー類型がSINGLE_TREEでない場合、ルーマ成分のブロック構造とクロマ成分のブロック構造は互いに異なってよい。ツリー類型がDUAL_TREE_LUMAである場合、ルーマ成分のブロック構造とクロマ成分のブロック構造は互いに異なってよく、このとき、ツリー類型はルーマ成分に対するツリーであるか、ルーマ成分に対する変換ツリーシンタックスがパースされることを示すことができる。一方、ツリー類型がDUAL_TREE_CHROMAである場合、ルーマ成分のブロック構造とクロマ成分のブロック構造が互いに異なってよく、このとき、ツリー類型は、クロマ成分に対するツリーであるか、クロマ成分に対する変換ツリーシンタックスがパースされることを示すことができる。
【0117】
図12は、本発明の一実施例に係るイントラブロックにおけるデコーディングプロセスを示す図である。
【0118】
図12は、変換ユニット分割に対する説明及びイントラ予測過程を示す図である。
【0119】
本明細書の図面を参照して説明される実施例において、使われる用語を定義する。
【0120】
(xTb0,yTb0):現在変換ブロックの左上端サンプル位置の座標
【0121】
nTbW:現在変換ブロックの幅
【0122】
nTbH:現在変換ブロックの高さ
【0123】
図12に開示された8.4.1節では、コーディングユニットのルーマブロックのデコーディングプロセスとクロマブロックのデコーディングプロセスを示す。クロマブロックのデコーディングプロセスは、CbブロックのデコーディングプロセスとCrブロックのデコーディングプロセスを含むことができる。図12の8.4.1節を参照すると、ルーマブロックのデコーディングプロセスとクロマブロックのデコーディングプロセスには、互いに異なる入力(input)が利用されてよく、デコーダは、互いに異なる入力を用いて、図12の8.4.5.1節に開示された動作を行うことができる。
【0124】
図12の8.4.1節に開示されたcbWidth及びcbHeightは、現在コーディングブロックの幅及び高さを意味するものでよく、cbWidth及びcbHeight値は、ルーマサンプルを基準にした値であってよい。例えば、ルーマブロックサイズが16×16であれば、クロマフォーマットによってクロマブロックサイズは8×8であってよい。このとき、クロマコーディングブロックに対するcbWidth及びcbHeight値はそれぞれ、16、16であってよい。また、図12に開示された(xCb,yCb)は、現在コーディングブロックの座標を示すものでよく、現在コーディングブロックの左上端(top-left)サンプルの座標値であってよい。このとき、座標値は、現在ピクチャーの左上端サンプルの座標を基準にして設定されてよい。また、(xCb,yCb)は、ルーマサンプルを基準にして示した値であってよい。
【0125】
図12の8.4.1節を参照すると、ツリー類型(treeType)がSINGLE_TREEであるか、DUAL_TREE_LUMAである場合、デコーダは、ルーマブロックに対するデコーディングプロセスを行うことができる。このとき、図12に開示された8.4.5.1節がインボーク(invoke)されてよく、その時のサンプルロケーション入力(sample location input)は、(xCb,yCb)であり、ブロックの幅と高さはそれぞれ、cbWidthとcbHeightであってよい。また、カラー成分(color component)を示すcIdxの値は、0であってよい。
【0126】
ツリー類型(treeType)がSINGLE_TREEであるか、DUAL_TREE_CHROMAである場合、デコーダは、クロマブロックに対するデコーディングプロセスを行うことができる。このとき、図12に開示された8.4.5.1がインボーク(invoke)されてよく、Cbブロック、Crブロックのそれぞれに対してインボーク(invoke)されてよい。このとき、サンプルロケーション入力(sample location input)は、(xCb/SubWidthC,yCb/SubHeightC)であり、ブロックの幅と高さはそれぞれ、cbWidth/SubWidthCとcbHeight/SubHeightCであってよい。このとき、cIdxの値は0でなくてよく、cIdx値は、Cbブロックに対しては1、Crブロックに対しては2に設定されてよい。SubWidthCとSubHeightCは、クロマフォーマットに基づいて既に設定される値であってよい。SubWidthCとSubHeightC値は1又は2でよく、ルーマ成分とクロマ成分の関係に対する値であってよい。SubWidthCとSubHeightCについては、図14及び図15を参照して後述する。
【0127】
デコーダが、図12の8.4.5.1節に開示されたデコーディングプロセスを行うとき、入力(input)はルーマブロック、クロマブロックに対応するように変換された状態であってよい。例えば、図12の8.4.5.1節に開示されたブロックの幅(nTbW)、ブロックの高さ(nTbH)、サンプルロケーションの座標(xTb0,yTb0)は、クロマブロックに対するデコーディングプロセスが行われる際には、クロマサンプル数に基づいて決定されてよく、ルーマブロックに対するデコーディングプロセスが行われる際には、ルーマサンプル数に基づいて決定されてよい。
【0128】
図12の8.4.5.1節を用いて上述のTU分割が行われてよい。図12に開示されたmaxTbWidth、maxTbHeightは、カラー(color)成分に該当する最大変換サイズ(maximum transform size)を示す値であり、それぞれ幅、高さに該当する値であってよい。上述したように、MaxTbSizeYは、ルーマブロックに対する最大変換サイズであってよい。したがって、クロマブロック(すなわち、cIdxが0でない場合)に対してmaxTbWidthは、MaxTbSizeY/SubWidthCでよく、maxTbHeightは、MaxTbSizeY/SubHeightCでよい。ルーマブロック対してmaxTbWidth、maxTbHeightはいずれもMaxTbSizeYであってよい。
【0129】
また、図12の8-43を参照すると、座標((xTbY,yTbY))は、ルーマ基準で変換されてよく、このとき、前記座標は、cIdxとSubWidthC、SubHeightCに基づいて計算されてよい。
【0130】
図12で説明したデコーディングプロセスはシンタックス構造と一致しなければならない。すなわち、図12のデコーディングプロセスは、図11のシンタックス構造と一致しなければならない。
【0131】
図12の8.4.5.1節においてnTbWがmaxTbWidthよりも大きいか、nTbHがmaxTbHeightよりも大きい場合、図12の8.4.5.1に開示された過程1~5が行われてよい。図12の過程1を参照すると、ブロックの幅(nTbW)及び高さ(nTbH)は、newTbW、newTbHにアップデートされてよい。具体的に、nTbWがmaxTbWidthよりも大きいと、ブロックの幅はnTbW/2にアップデートされ、そうでないと、ブロックの幅は相変わらずnTbWである。nTbHがmaxTbHeightよりも大きいと、ブロックの高さはnTbH/2にアップデートされ、そうでないと、ブロックの高さは相変わらずnTbHである。図12の過程2を参照すると、座標(xTb0,yTb0)、newTbW、newTbHを入力として図12の8.4.5.1節が再びインボーク(invoke)されてよい。図12の過程3を参照すると、nTbWがmaxTbWidthよりも大きいと、座標(xTb0+newTbW,yTb0)、newTbW、newTbHを入力として図12の8.4.5.1節が再びインボーク(invoke)されてよい。図12の過程4を参照すると、nTbHがmaxTbHeightよりも大きいと、座標(xTb0,yTb0+newTbH)、newTbW、newTbHを入力として図12の8.4.5.1節が再びインボーク(invoke)されてよい。図12の過程5を参照すると、nTbWがmaxTbWidthより大きく、nTbHがmaxTbHeightよりも大きいと、座標(xTb0+newTbW,yTb0+newTbH)、newTbW、newTbHを入力として図12の8.4.5.1節が再びインボーク(invoke)されてよい。図12の過程2~5は、図11で変換ツリーシンタックスをまた呼び出す過程と同一であってよい。
【0132】
一方、nTbWがmaxTbWidth以下であり、nTbHがmaxTbHeight以下であれば、図12の過程1~5以外のプロセスが行われてよい。このとき、図12の過程1~5以外のプロセスは、実際イントラ予測とレジデュアル信号デコーディング(residual signal decoding)、変換(transform)、復元(reconstruction)などに関連したプロセスであってよい。
【0133】
図13は、本発明の一実施例に係るレジデュアル信号のデコーディングプロセスを示す図である。
【0134】
図13に開示された内容のうち、上述した内容と重複する内容は省略するものとする。
【0135】
図13に開示されたデコーディングプロセスは、インター予測、IBC(intra block copy)予測などが適用される場合に行われてよい。また、図13は、上述したTU分割について開示できる。
【0136】
図13のS1301を参照すると、図13の8.5.8節をインボーク(invoke)する過程は、カラー(color)成分別に行われてよい。このとき、図12を参照して説明した通り、各カラー成分に該当する入力(input)を用いて図13の8.5.8節のデコーディングプロセスが行われてよい。図13の8.5.8節のデコーディングプロセスの入力であるサンプルロケーションの座標(xTb0,yTb0)、ブロックの幅(nTbW)、ブロックの高さ(nTbH)は、ルーマブロックに対しては(xCb,yCb)、cbWidth、cbHeightであってよく、クロマブロックに対しては(xCb/SubWidthC,yCb/SubHeightC)、cbWidth/SubWidthC、cbHeight/SubHeightCであってよい。また、カラー(color)成分を示すcIdx値は、ブロックがルーマ成分である場合、0に設定され、ブロックがクロマ成分である場合、0以外の値に設定されてよい。例えば、ブロックがCb成分である場合にcIdx値は1、ブロックがCr成分である場合にcIdx値は2に設定されてよい。
【0137】
図13の8.5.8節のデコーディングプロセスが行われるとき、(xTb0,yTb0)、nTbW、nTbHは、各カラー(color)成分に該当する値であってよい。すなわち、各カラー(color)成分のサンプル数に該当する値であってよい。
【0138】
図13の8-849、8-850を参照すると、各カラー(color)成分に合わせて最大変換サイズ(maximum transform size)が計算されてよい。また、図13の8-852、8-853を参照すると、nTbW又はnTbHが最大変換サイズよりも大きいか否かに基づいてブロックの幅又はブロックの高さはアップデートされ、newTbW、newTbHと記述されてよい。図13の8.5.8節の過程2~5では、8.5.8節を再びインボークする過程を開示しているが、これは、図12を参照して上述した内容と同一であってよい。
【0139】
一方、nTbWがmaxTbWidth以下であり、nTbH maxTbHeight以下であれば、図13の過程1~5以外のプロセスが行われてよい。このとき、図13の過程1~5以外のプロセスは、実際のレジデュアル信号デコーディング(residual signal decoding)、変換(transform)などに関連したプロセスであってよい。
【0140】
図14は、本発明の一実施例に係るカラー成分の関係を示す図である。
【0141】
図14を参照すると、カラー成分に関係した要素として、chroma_format_idc、Chroma format、separate_colour_plane_flagなどがあり得る。
【0142】
例えば、クロマフォーマット(Chroma format)がMonochromeである場合、1個のサンプルアレイ(sample array)だけ存在してよく、SubWidthC、SubHeightCがいずれも1であってよい。クロマフォーマットが4:2:0サンプリングである場合、クロマアレイ(chroma array)は2個存在してよい。このとき、クロマアレイは、ルーマアレイ(luma array)の半分の幅(half width)、半分の高さ(half height)を有することができ、SubWidthC、SubHeightCはいずれも2であってよい。クロマフォーマットが4:2:2サンプリングである場合、クロマアレイは2個存在してよい。このとき、クロマアレイは、ルーマアレイの半分の幅、ルーマアレイと同じ高さを有してよく、SubWidthC、SubHeightCはそれぞれ、2、1であってよい。クロマフォーマットが4:4:4サンプリングである場合、クロマアレイは2個存在してよい。このとき、クロマアレイは、ルーマアレイと同じ幅、同じ高さを有してよく、SubWidthC、SubHeightCはいずれも1であってよい。
【0143】
一方、クロマフォーマットが4:4:4サンプリングである場合、separate_colour_plane_flagに基づいて行われるプロセスが互いに異なってよい。separate_colour_plane_flagが0である場合、クロマアレイは、ルーマアレイと同じ幅、同じ高さを有してよい。separate_colour_plane_flagが1である場合、3個のカラー平面(color plane)、すなわち、ルーマ、Cb、Crに対するプロセスはそれぞれ行われてよい。separate_colour_plane_flagが1である場合、一つのスライスには一つのカラー(color)成分だけ存在してよい。一方、separate_colour_plane_flagが0である場合、一つのスライスには複数のカラー成分が存在してよい。図14に示すように、クロマフォーマットが4:4:4サンプリングである場合、separate_colour_plane_flagに関係なくSubWidthC、SubHeightCはいずれも1であってよい。
【0144】
SubWidthCとSubHeightCは、クロマアレイがルーマアレイに対していかなるサイズを有するかを示すことができ、クロマアレイ幅又はクロマアレイ高さがルーマアレイの半分である場合、SubWidthC又はSubHeightCは2であり、クロマアレイ幅又は高さがルーマアレイと同じサイズである場合、SubWidthC又はSubHeightCは1であってよい。
【0145】
図14を参照すると、クロマフォーマットが4:2:2サンプリングである場合にのみ、SubWidthC、SubHeightCは互いに異なる値を有してよい。したがって、クロマフォーマットが4:2:2サンプリングである場合、ルーマ成分を基準にした幅対高さの関係は、クロマ成分を基準にした幅対高さの関係と異なってよい。
【0146】
図15は、本発明の一実施例に係るカラー成分の関係を示す図である。
【0147】
図15(a)は、クロマフォーマットが4:2:0サンプリングである場合、図15(b)は、クロマフォーマットが4:2:2サンプリングである場合、図15(c)は、クロマフォーマットが4:4:4サンプリングである場合、を示す。
【0148】
図15(a)を参照すると、クロマフォーマットが4:2:0サンプリングである場合、水平(horizontal)方向においてルーマサンプル2個当りにクロマサンプルは1個(Cb1個、Cr1個)ずつ位置してよい。また、垂直(vertical)方向においてルーマサンプル2個当りにクロマサンプルは1個(Cb1個、Cr1個)ずつ位置してよい。
【0149】
図15(b)を参照すると、クロマフォーマットが4:2:2サンプリングである場合、水平(horizontal)方向においてルーマサンプル2個当りにクロマサンプルは1個(Cb1個、Cr1個)ずつ位置してよい。また、垂直(vertical)方向においてルーマサンプル1個当りにクロマサンプルは1個(Cb1個、Cr1個)ずつ位置してよい。
【0150】
図15(c)を参照すると、クロマフォーマットが4:4:4サンプリングである場合、水平(horizontal)方向においてルーマサンプル1個当りにクロマサンプルは1個(Cb1個、Cr1個)ずつ位置してよい。また、垂直(vertical)方向においてルーマサンプル1個当りにクロマサンプルは1個(Cb1個、Cr1個)ずつ位置してよい。
【0151】
図15に示したルーマサンプルとクロマサンプルの関係によって、上述したSubWidthC、SubHeightCが決定されてよく、SubWidthC、SubHeightCに基づき、ルーマサンプルを基準にした変換、クロマサンプルを基準にした変換が行われてよい。
【0152】
図16は、本発明の一実施例に係る最大変換サイズを示す図である。
【0153】
最大変換サイズ(maximum transform size)は可変してよいが、エンコーダ又はデコーダの複雑度は、最大変換サイズを変更することによって調節されてよい。例えば、最大変換サイズが小さい場合、エンコーダ又はデコーダの複雑度は減り得る。
【0154】
本発明の一実施例として、最大変換サイズになり得る値は制限されてよい。例えば、最大変換サイズは、2個の値のいずれか一つに制限されてよい。このとき、2個の値は、32、64でよく、ルーマ基準のサイズであってよい。
【0155】
最大変換サイズは、上位レベルでシグナルされてよい。このとき、上位レベルとは、現在ブロックを含むレベルであってよい。例えば、シーケンス、シーケンスパラメータ、スライス、タイル、タイルグループ、ピクチャー、コーディングツリーユニット(coding tree unit,CTU)などの単位が上位レベルになり得る。
【0156】
図16を参照すると、sps_max_luma_transform_size_64_flagは、最大変換サイズを示すフラグであってよい。例えば、sps_max_luma_transform_size_64_flagの値が1であれば、最大変換サイズは64であり、sps_max_luma_transform_size_64_flagの値が0であれば、合最大変換サイズは32であってよい。このとき、最大変換サイズは、ルーマサンプルを基準にしたサイズであってよい。
【0157】
また、MaxTbLog2SizeYは、最大変換サイズにlog2を取った値であってよい。したがって、MaxTbLog2SizeYは、(sps_max_luma_transform_size_64_flag?6:5)であってよい。すなわち、sps_max_luma_transform_size_64_flagの値が1であれば、MaxTbLog2SizeY値は6であり、sps_max_luma_transform_size_64_flagの値が0であれば、MaxTbLog2SizeY値は5になる。
【0158】
また、最大変換サイズを示すMaxTbSizeYは、(1<<MaxTbLog2SizeY)であってよい。すなわち、MaxTbLog2SizeYの値が6であれば、左にビットを6桁移動させ、MaxTbSizeYの値は64になり、MaxTbLog2SizeYの値が5であれば、左にビットを5桁移動させ、MaxTbSizeYの値は32になる。
【0159】
図16に開示されたMinTbSizeYは、最小変換サイズ(minimum transform size)を示す値であってよい。
【0160】
ルーマコーディングツリーブロックのサイズ(CtbSizeY)又はコーディングツリーユニットのサイズ(CTU size)は可変してよい。例えば、CtbSizeYが64よりも小さい場合、最小変換サイズは64よりも小さくてよい。したがって、CtbSizeYが64よりも小さい場合、sps_max_luma_transform_size_64_flagの値は、0であってよい。
【0161】
以下、本発明で記述するCtbsizeYは、ルーマコーディングツリーブロックのサイズを意味するものであり、具体的に、ルーマコーディングツリーブロックの幅及び高さを示す。
【0162】
図17は、本発明の一実施例に係る上位レベルにおけるシンタックスを示す図である。
【0163】
図17を参照すると、図17に示したシンタックス構造は上位レベルのシンタックスでよく、sps_max_luma_transform_size_64_flagを含むことができる。
【0164】
また、図17のシンタックス構造は、log2_ctu_size_minus5を含むことができる。log2_ctu_size_minus5に基づいてCTUサイズ及びルーマコーディングツリーブロックのサイズCtbSizeYが決定されてよい。例えば、log2_ctu_size_minus5+5は、CtbLog2SizeYであり、CtbLog2SizeYは、log2(CtbSizeY)を表す。また、CtbSizeYは(1<<CtbLog2SizeY)と決定されてよい。
【0165】
また、図17のシンタックス構造は、sps_sbt_enabled_flag、sps_sbt_max_size_64_flagを含むことができる。sps_sbt_enabled_flagは、サブブロック変換(subblock transform,SBT)が使用され得るか否かを示すフラグであってよい。SBTは、CU又はPUの一部サンプルだけを変換するものであってよい。sps_sbt_max_size_64_flagは、SBTが用いられてよい最大サイズを示すフラグであってよい。図17を参照すると、sps_sbt_enabled_flagが、SBTが用いられてよいことを示す場合(例えば、sps_sbtenabled_flagの値が1である場合)、sps_sbt_max_size_64_flagはシグナルされてよい。一方、sps_sbt_enabled_flagが、SBTが用いられなくてよいことを示す場合(例えば、sps_sbt_enabled_flagの値が0である場合)、sps_sbt_max_size_64_flagは、シグナルされなくてもよい。また、ブロックの幅と高さがいずれも、SBTが用いられてよい最大サイズ以下である場合に、SBTは用いられてよい。
【0166】
sps_sbt_max_size_64_flagが示す、SBTが用いられてよい最大サイズは、32を含むことができる。また、sps_sbt_max_size_64_flagが示す、SBTが用いられてよい最大サイズは、32又は64であってよい。最大変換サイズが、sps_sbt_max_size_64_flagが示すSBTが用いられてよい最大サイズよりも小さい場合、SBTが用いられてよい最大サイズは、最大変換サイズに設定されてよい。図17の7-31を参照すると、最大変換サイズ(MaxTbSizeY)とsps_sbt_max_size_64_flagによって示されたSBTが用いられてよい最大サイズのうち小さい値が、SBTが用いられてよい最大サイズ(MaxSbtSize)に設定されてよい。
【0167】
図17のシンタックス構造は、sps_transform_skip_enabled_flagを含むことができる。sps_transform_skip_enabled_flagは、変換スキップ(transform skip)が使用可能か否かを示すフラグであってよい。このとき、変換スキップは、変換を行わないことを表してよい。
【0168】
図18は、本発明の一実施例に係る変換ツリーシンタックスを示す図である。
【0169】
図18の変換ツリーシンタックスは、図16図17で説明した可変的な最大変換サイズを支援するためのシンタックスであってよい。
【0170】
CU又はPUの最大サイズが最大変換サイズの2倍であり、固定された最大変換サイズを使用する場合、図11図13で説明したシンタックス及びデコーディングプロセッサが用いられてよい。具体的に、CU又はPUの最大サイズが128であり、最大変換サイズが64であるとき、図11図13の実施例が用いられてよい。このとき、CU又はPUが最大変換サイズよりも大きいためTUが分割される場合に、TUは2個又は4個に分割されてよい。分割は、水平(horizontal)方向、垂直(vertical)方向にそれぞれ2個まで分割されてよい。
【0171】
しかし、可変的な最大変換サイズが用いられる場合、又は従来の最大変換サイズよりも小さい最大変換サイズが支援される場合、又はCU又はPUの最大サイズが最大変換サイズの2倍よりも大きい場合には、TUが水平方向、垂直方向にそれぞれ2個以上に分割される必要がある。しかし、図11図13で説明したシンタックス、プロセスは、このような分割を支援しないという問題点がある。
【0172】
したがって、このような問題点を解決するために、図18を参照して、TUを水平又は垂直方向のいずれかにのみ2個に分割する動作を回帰的(recursive)に行うようにするシンタックスを説明する。図18を参照すると、tbWdithがMaxTbSizeYよりも大きい、又はtbHeightがMaxTbSizeYよりも大きい場合、図18の変換ツリーシンタックス‘transform_tree()’が再び呼び出されてよい。このとき、‘transform_tree()’は、2回(図18の(6)と(8)、又は図18の(6)と(10))呼び出されてよい。2回の呼び出しが図18の(6)と(8)であるか或いは図18の(6)と(10)であるかは、TUの最初の分割方向によって決定されてよい。verSplitFirstに基づいてTUの最初の分割方向が決定されてよい。verSplitFirstに基づき、呼び出される‘transform_tree()’における入力(input)が変わってよい。また、verSplitFirstに基づき、前記2回の呼び出しが図18の(6)と(8)であるか或いは図18の(6)と(10)であるかが決定されてよい。tbWidth、tbHeightは、ブロックの幅、高さであり、MaxTbSizeYは最大変換サイズである。
【0173】
図18の(3)を参照すると、tbWidth、tbHeight、MaxTbSizeYに基づいてverSplitFirst値が決定されてよい。
【0174】
本発明の一実施例において、tbWidthがMaxTbSizeYよりも大きく、tbWidthがtbHeightよりも大きい場合、verSplitFirst値は1に設定され、そうでない場合、verSplitFirst値は0に設定されてよい。
【0175】
図18の‘transform_tree()’の入力(input)であるブロックの幅、高さは、図18の(6)、(8)、(10)ではtrafoWidth、trafoHeightであってよい。trafoWidth、trafoHeightは、verSplitFirstに基づいて決定されてよい。例えば、verSplitFirstが1である場合、trafoWidthはtbWidth/2に設定され、verSplitFirstが0である場合、trafoWidthはtbWidthに設定されてよい。また、verSplitFirstが0である場合、trafoHeightはtbHeight/2に設定され、verSplitFirstが1である場合、trafoHeightはtbHeightに設定されてよい。すなわち、図18の(6)、(8)、(10)の入力(input)であるtrafoWidth、trafoHeightは、既存のブロック幅、高さのいずれか一つと同一であり、残り一つは、既存の値の半分であってよい。言い換えると、trafoWidth、trafoHeightはtbWidth/2、tbHeightであるか、tbWidth、tbHeight/2であってよい。
【0176】
本発明の一実施例として、tbWidthがMaxTbSizeY以上であり、tbWidthがtbHeight以上である場合、verSplitFirstは1に設定されてよく、そうでない場合、verSplitFirstは0に設定されてよい。
【0177】
図18の(4)、(5)によってブロックの幅、高さはアップデートされてよい。このとき、アップデートされたブロックの幅、高さは、trafoWidth、trafoHeightであってよい。図18の(6)、すなわち、再び呼び出される‘transform_tree()’の入力としてtrafoWidth、trafoHeightが用いられてよい。図18の(6)は、座標(x0,y0)、trafoWidth、trafoHeightを入力とする‘transform_tree()’を呼び出す過程であってよい。すなわち、既存の‘tranform_tree()’の入力である座標と同じ座標及びアップデートされたブロックの幅(すなわち、trafoWidth)又はアップデートされたブロックの高さ(すなわち、trafoHeight)を入力として‘transform_tree()’を呼び出すことあってよい。
【0178】
verSplitFirstに基づいて図18の(8)又は(10)が行われてよい。図18の(8)が行われる場合、座標(x0+trafoWidth,y0)、trafoWidth、trafoHeightを入力とする‘transform_tree()’が呼び出されてよい。図18の(10)が行われる場合、座標(x0,y0+trafoHeight)、trafoWidth、trafoHeightを入力とする‘transform_tree()’が呼び出されてよい。すなわち、既存の‘transform_tree()’において図18の(6)に該当するブロックを除外した残りブロック(座標が互いに異なるので)に該当する‘transform_tree()’を呼び出すことが、図18の(8)と(10)であってよい。
【0179】
‘transform_tree()’を呼び出す過程は回帰的(recursive)に行われてよい。
【0180】
tbWidthがMaxTbSizeY以下であり、tbHeightがMaxTbSizeY以下である場合、‘transform_unit()’は呼び出されてよい。
【0181】
図18におけるx0、y0、tbWidth、tbHeightは、ルーマサンプル基準の値であってよく、図11で説明したのと同一であってよい。したがって、verSplitFirstを決定するためのサイズ比較は、ルーマサンプルを基準にした値で行われてよい。クロマサンプルを基準にすれば、変換ブロック(ユニット)の幅と高さが同一である場合にも、クロマブロックのtbWidthがtbHeightよりも大きい場合が発生し得るわけである。例えば、クロマフォーマットが4:2:2サンプリングである場合、tbWidthがtbHeightよりも大きく、tbWidth/SubWidthCがtbHeight/SubHeightCと同一である状況が発生し得る。
【0182】
図19は、本発明の一実施例に係るTU分割を示す図である。
【0183】
図19に示すTUの分割は、図18のシンタックスによる分割を示すことができる。例えば、ブロックの幅(tbWidth)が最大変換サイズ(MaxTbSizeY)よりも大きく、ブロックの幅(tbWidth)がブロックの高さ(tbHeight)よりも大きい場合、図19のように、左側1、右側2のTUに分割される垂直スプリット(vertical split)が適用されてよい。図18で説明した通り、verSplitFirstの値が1であれば、図19に示すように、左側、右側2個のTUに分割されてよい。このとき、再び呼び出した‘transform_tree()’によってさらに分割されてよい。図19は、tbHeightも最大変換サイズ(MaxTbSizeY)よりも大きい場合を示している。図19の左側TU(1)の内部で分割がなされてよく、図19の右側TU(2)の内部で分割がなされてよいが、図18のシンタックスによれば、‘transform_tree()’は回帰的(recursive)に呼び出されるので、左側TU(1)でなされた分割に関連した動作が全てパースされる又は行われた後に、TU2でなされた分割に関連した動作がパースされる又は行われてよい。一方、ブロックの幅が最大変換サイズよりも小さいか、ブロックの幅がブロックの高さよりも小さい場合、verSplitの値は0と決定されてよい。このとき、TUは、水平スプリット(horizontal split)が適用され、上側TU、下側TUに分割されてよい。
【0184】
図20は、本発明の一実施例に係るTU分割を示す図である。
【0185】
図20のTU分割は、図11図13を参照して説明した実施例に係るTU分割であってよい。例えば、ブロックの幅(tbWidth)が最大変換サイズ(MaxTbSizeY)よりも大きく、ブロックの高さ(tbHeight)がMaxTbSizeYよりも大きい場合、図20のように、一つのTUは4個のTUに一度に分割されてよい。また図11図13の実施例を参照すると、分割されたTUに対するデコーディングプロセスを行う既に設定された順序が存在してよい。既に設定された順序の一例として、図20の(a)、(b)、(c)、(d)の順にデコーディングプロセスが行われてよい。
【0186】
ただし、図19の(1)に該当する領域は図20の(a)と(c)であり、図19の(2)に該当する領域は図20の(b)及び(d)であるので、図19図20の分割されたTUに対するデコーディングプロセス実行順序が互いに異なってくるという問題があり得る。また、シンタックス順序とデコーディングプロセス順序とが異なる場合に、シンタックスのブロック順序とデコーディングプロセスのブロック順序とが異なると、具現側面の複雑度が増加するという問題がある。あるブロックのデコーディングプロセスにおいて、それぞれのブロックに適用されるデコーディングプロセスに該当するシンタックスが適用される必要があるためである。
【0187】
図19図20の実施例のようにブロックのデコーディングプロセス順序が互いに変わる場合は、tbWidthがMaxTbSizeYよりも大きく、tbWidthがtbHeightよりも大きい場合であってよい。具体的に、tbWidthがMaxTbSizeYよりも大きく、tbWidthがtbHeightよりも大きく、tbHeightがMaxTbSizeYよりも大きい場合であってよい。例えば、MaxTbSizeが32、tbWidthが128、tbHeightが64である場合に、ブロックのデコーディングプロセス順序が互いに変わってよい。
【0188】
図21は、本発明の一実施例に係るデコーディングプロセスを示す図である。
【0189】
図21に開示された内容は、イントラブロックに関連したものであるが、これに限定されず、レジデュアル信号デコーディングプロセス(residual signal decoding process)など、TU分割に対する他の実施例においても適用可能である。
【0190】
図21に開示されたデコーディングプロセスは、図18のシンタックスに該当するデコーディングプロセスである。
【0191】
図20などの実施例で上述した問題を解決するために、TU分割に関連したデコーディングプロセスは変更される必要がある。上述と同様に、本明細書に記述されたTU分割は、TBを分割するのと同じ意味であってよい。図21に開示されたデコーディングプロセスは、TBが2つに分割され、回帰的に(recursive)動作する形態と定義されてよい。例えば、verSplitFirstに基づいてTBが2つに分割されてよい。図21の8-41、8-42を参照すると、maxTbWidthとmaxTbHeightは、図12の実施例と同一に決定されてよい。また、図21のnTbW,nTbHは各カラー(color)成分を基準に設定された値であってよい。maxTbWidthとmaxTbHeightは、最大変換ブロックの幅、高さを示し、nTbWとnTbHはブロックの幅、高さを示す。
【0192】
例えば、nTbWがmaxTbWidthよりも大きく、nTbWがnTbHよりも大きい場合、verSplitFirstは1に設定され、そうでない場合、verSplitFirstは0に設定されてよい。また、newTbWはverSplitFirstが1である場合、nTbW/2に設定され、そうでない場合、nTbWに設定されてよい(図21の8-44)。また、newTbHは、verSplitFirstが0である場合、nTbH/2に設定され、そうでない場合、nTbHに設定されてよい(図21の8-45)。
【0193】
一方、図18に開示されたシンタックスにおいてverSplitFirstが互いに異なるように定義されると、図21のverSplitFirstは異なるように定義されてよい。例えば、図18でtbWidthがMaxTbSizeYよりも大きく、tbWidthがtbHeight以上である場合、verSplitFirstが1に設定され、そうでない場合、verSplitFirstが0に設定されると、図21のverSplitFirstは、nTbWがmaxTbWidthよりも大きく、nTbWがnTbH以上である場合、1に設定され、そうでない場合、0に設定されてよい。
【0194】
図21の過程2で、図21に開示された8.4.5.1節を再びインボーク(invoke)することができる。このとき、入力(input)としてサンプルロケーションの座標(xTb0,yTb0)、newTbH、newTbHが用いられてよい。これは、図19の左側TU(1)のようにTUが分割されたとき、1番目(左側又は上側)のTUに対するものであってよい。
【0195】
また、verSplitFirstに基づき、図21の過程3又は4で図21の8.4.5.1節が再びインボーク(invoke)されてよい。これは、図19の右側TU(2)部分のようにTUが分割されたとき、2番目(右側又は下側)のTUに対するものであってよい。図21の過程3で図21の8.4.5.1節がインボーク(invoke)される場合、入力(input)は、座標(xTb0+newTbW,yTb0)、newTbH、newTbHが用いられてよい。図21の過程4で図21の8.4.5.1節がインボーク(invoke)される場合、入力(input)は、座標(xTb0,yTb0+newTbH)、newTbH、newTbHが用いられてよい。
【0196】
上述したように、図18でtbWidth、tbHeightは、ルーマ基準の値であってよく、図21でnTbW、nTbHは、各カラー(color)成分基準の値であってよい。したがって、図21に開示されたデコーディングプロセスがクロマ成分のブロックに対して行われるとき、図18のシンタックスと図21のデコーディングプロセス間に不一致が発生し得る。例えば、tbWdithとnTbW間の関係は、次の通りでよい。ルーマ成分のブロックでは、tbWidthはnTbWと同一であり、tbHeightはnTbHと同一であってよい。クロマ成分のブロックでは、tbWidth/SubWidthCはnTbWと同一であり、tbHeight/SubHeightCはnTbHと同一であってよい。したがって、図18に開示されたverSplitを決定するためにブロックの幅と高さを比較する部分と、図21の過程1に開示されたverSplitを決定するためにブロックの幅と高さを比較する部分の結果とが異なることがある。例えば、図18のtbWidth>tbHeightの結果と図21のnTbW>nTbHの結果とが異なることがあり、このため、図18図21のverSplitFirst値とが異なってくるという問題がある。
【0197】
図22は、本発明の一実施例に係るデコーディングプロセスを示す図である。
【0198】
図22に開示された内容はイントラブロックに関連するものであるが、これに限定されず、レジデュアル信号デコーディングプロセス(residual signal decoding process)など、TB分割に対する他の実施例においても適用可能である。図22に開示された内容のうち、前述した内容と同じ内容は省略するものとする。
【0199】
図22に開示された内容は、図18に開示されたシンタックスに該当するデコーディングプロセスであってよい。また、図22を参照して、図20図21などで説明した問題を解決するためのデコーディングプロセス、特にTB分割に関連したデコーディングプロセスについて説明する。
【0200】
図22を参照すると、イントラブロックデコーディングプロセス(intra block decoding process)又はレジデュアル信号デコーディングプロセス(residual signal decoding process)の入力(input)として、ブロックの位置を示す座標(xTb0,yTb0)、ブロックの幅を示すnTbW、ブロックの高さを示すnTbH、カラー成分(color component)を示すcIdx、ツリー構造を示すtreeTypeなどがあり得る。このとき、nTbW、nTbHは、変換ブロック(transform block)の幅、高さであってよい。すなわち、nTbW、nTbHは、現在ブロックのカラー成分を基準にした幅、高さであってよい。例えば、クロマサブサンプリングが4:2:0のとき、ルーマブロックの幅、高さがそれぞれ16、16であれば、図22に開示されたデコーディングプロセスのnTbW、nTbHは、クロマブロックに対して(cIdxが0でない時)それぞれ8、8であってよい。
【0201】
図22の8-41を参照すると、maxTbWidthは、cIdxとSubWidthCに基づいて決定されてよい。例えば、cIdxが0である場合、maxTbWidthはMaxTbSizeYであり、cIdxが0でない場合、maxTbWidthは、MaxTbSizeY及びSubWidthCに基づいて決定されてよい。cIdxが0でない場合、maxTbWidthは、MaxTbSizeY/SubWidthCに設定されてよい。
【0202】
図22の8-42を参照すると、maxTbHeightは、cIdxとSubHeightCに基づいて決定されてよい。例えば、cIdxが0である場合、maxTbHeightはMaxTbSizeYであり、cIdxが0でない場合、maxTbHeightは、MaxTbSizeY及びSubHeightCに基づいて決定されてよい。cIdxが0でない場合、maxTbHeightは、MaxTbSizeY/SubHeightCに設定されてよい。
【0203】
nTbWがmaxTbWidthよりも大きいか、nTbHがmaxTbHeightよりも大きい場合、図22に開示されたデコーディングプロセスが別の入力(input)を用いて再びインボーク(invoke)されてよい。例えば、インボーク(invoke)が2回行われてよい。また、回帰的に(recursive)インボーク(invoke)される場合が発生してもよい。図22に開示されたデコーディングプロセスが再びインボーク(invoke)されることは、TBが分割されることであってよい。
【0204】
本発明の一実施例によれば、TBが分割されるとき、nTbW、nTbH、MaxTbSizeY、cIdx、SubWidthC、SubHeightCに基づいて分割されてよい。または、TBが分割されるとき、nTbW、nTbH、maxTbWidth、cIdx、SubWidthC、SubHeightCに基づいて分割されてよい。または、verSplitFirst値に基づいてTBが分割されてよい。
【0205】
verSplitFirst値は、cIdxに基づいて決定されてよい。例えば、cIdxが0のとき、verSplitFirst値は、nTbW、nTbH、maxTbWidthに基づいて決定されてよい。cIdxが0のとき、verSplitFirst値は、SubWidthC、SubHeightCに関係なく決定されてよい。一方、cIdxが0でない場合、すなわち、cIdxが1又は2である場合、verSplitFirst値は、nTbW、nTbH、maxTbWidth、SubWidthC、SubHeightCに基づいて決定されてよい。
【0206】
また、verSplitFirst値は、一つ以上の条件に基づいて決定されてよい。例えば、verSplitFirstは、ブロックの幅(width)が最大変換サイズ(maximum transform size)よりも大きいか否かに基づいて決定されてよい。verSplitFirstは、ブロックの高さ(height)が最大変換サイズよりも大きいか否かに基づいて決定されてよい。このとき、ブロックの幅、ブロックの高さが最大変換サイズよりも大きいか否かに対する結果は、ルーマブロック基準にしても、クロマブロック基準にしても構わない。言い換えると、いかなるカラー(color)成分を基準にしても結果には影響を与えない。したがって、図22を参照すると、各カラー成分を基準にした入力(input)を用いて上述の条件を確認している。これは、ルーマ基準の値に変換する計算を省くためのものでよい。
【0207】
また、verSplitFirst値を決定するための上述した一つ以上の条件は、ブロックの幅と高さに基づく条件であってよい。例えば、ブロックの幅がブロックの高さよりも大きいか否かによってverSplitFirst値は決定されてよい。このとき、ブロックの幅、高さは、ルーマ成分を有するブロックの値であってよい。言い換えると、デコーダは、ルーマピクセル、ルーマ成分を基準にした値を基準にブロックの幅、ブロックの高さを比較し、verSplitFist値を決定することができる。すなわち、cIdxが0である場合(ルーマブロックである場合)には、上述した一つ以上の条件にはnTbWとnTbHが用いられ、cIdxが0でない場合(クロマブロックである場合)には、nTbW*SubWidthCとnTbH*SubHeightCが用いられてよい。図22を参照すると、cIdxが0である場合、nTbWがnTbHよりも大きいか否か確認し、cIdxが0でない場合、nTbW*SubWidthCがnTbH*SubHeightCよりも大きいか否かが確認できる。
【0208】
このとき、上述した一つ以上の条件を満たす場合、verSplitFirst値は1に設定され、そうでない場合(一つ以上の条件のうち少なくとも一つを満たさない場合)、verSplitFirst値は0に設定されてよい。
【0209】
言い換えると、デコーダは、ブロックの幅(width)と最大変換サイズとを比較する時は、カラー成分及びクロマフォーマットを考慮した値を用い、ブロックの幅とブロックの高さとを比較する時は、ルーマ成分を基準にした値を用いることができる。
【0210】
図22を参照して、上述したverSplitFirst値が決定される条件を、下記の式2のように示すことができる。
【0211】
【数2】
【0212】
式2を再び説明すると、cIdxが0である場合には、verSplitFirstは下記の式3のように決定されてよい。
【0213】
【数3】
【0214】
式2を再び説明すると、cIdxが0でない場合(例えばcIdxが1又は2である場合)、verSplitFirstは下記の式4のように決定されてよい。
【0215】
【数4】
【0216】
式2~4のサイズ比較時に、等号(=)が含まれてよい。言い換えると、nTbWがmaxTbWidth以上であるか否か確認でき、cIdxが0である場合、nTbWがnTbH以上であるか否かを確認し、cIdxが0でない場合、nTbW*SubWidthCがnTbH*SubHeightC以上であるか否かが確認できる。このとき、図18のシンタックスにおいても同様に、サイズ比較時に等号(=)が含まれてよい。
【0217】
図22の8-44、8-45を参照すると、verSplitFirst値に基づいてnewTbW、newTbHが決定されてよい。例えば、verSplitFirstが1である場合、newTbWはnTbW/2、newTbHはnTbHと決定されてよい。verSplitFirstが0である場合、newTbWはnTbW、newTbHはnTbH/2と決定されてよい。
【0218】
図22を参照すると、verSplitFirstに基づき、図22の過程2と3でデコーディングプロセスが再びインボーク(invoke)されるか、過程2と4でデコーディングプロセスが再びインボーク(invoke)されてよい。
【0219】
図22の過程2では、ブロックの位置(xTb0,yTb0)、newTbW、newTbHを用いてデコーディングプロセスが再びインボーク(invoke)されてよい。これは、図19の左側TU(1)部分のように分割されたものの1番目(左側或いは上側)のTUに対するものでよい。
【0220】
図22の過程3では、ブロックの位置(xTb0+newTbW,yTb0)、newTbW、newTbHを用いてデコーディングプロセスが再びインボーク(invoke)されてよい。これは、図19の右側TU(2)部分のように分割されたものの2番目(右側)のTUに対するものでよい。
【0221】
図22の過程4では、ブロックの位置(xTb0,yTb0+newTbH)、newTbW、newTbHを用いてデコーディングプロセスが再びインボーク(invoke)されてよい。これは、図19の右側TU(2)部分のように分割されたものの2番目(下側)のTUに対するものでよい。
【0222】
図23は、本発明の一実施例に係る上位レベルシンタックスを示す図である。
【0223】
最大変換サイズ(maximum transform size)を示すシンタックス要素は、CTUサイズ又はCtbSizeY又はCtbSizeYを示すシンタックス要素に基づいてよい。例えば、CTUサイズ又はCtbSizeY又はCtbSizeYを示すシンタックス要素が示すサイズ(size)よりも大きい最大変換サイズは、候補から除外されてよい。CTUサイズ又はCtbSizeY又はCtbSizeYを示すシンタックス要素が示すサイズが64よりも小さい場合、最大変換サイズ候補から64以上の値は除外されてよい。最大変換サイズとして可能な値が2つである場合、最大変換サイズを知らせるシグナリング無しで、CTUサイズ又はCtbSizeY又はCtbSizeYを示すシンタックス要素が示すサイズに基づいて最大変換サイズは決定され、その値が決定されてよい。CTUサイズは、コーディングツリーユニットの幅、高さを意味し、CtbSizeYは、ルーマコーディングツリーブロックのサイズを示し、クロマコーディングツリーブロックの幅、高さを意味する。
【0224】
図23を参照すると、最大変換サイズを示すシンタックス要素は、sps_max_luma_transform_size_64_flagであってよい。最大変換サイズを示すシンタックス要素は、最大変換サイズを64及び64よりも小さい値と示すことができる。仮にCtbSizeYが64よりも小さい場合、sps_max_luma_transform_size_64_flagはシグナルされず、推論(infer)されてよい。例えば、sps_max_luma_transform_size_64_flagの値が1のとき、最大変換サイズが64を示すと、CtbSizeYが64よりも小さい場合、sps_max_luma_transform_size_64_flagの値は0と推論(infer)されてよい。または、MaxTbLog2SizeYの値は5と決定されるか、MaxTbSizeYの値は32と決定されてよい。
【0225】
最小CtbSizeYが32であれば、上述したCtbSizeYが64よりも小さい場合は、CtbSizeYが32である場合と同一であってよい。例えば、CtbsizeYが32であれば、sps_max_luma_transform_size_64_flagの値は0と推論(infer)され、よって、最大変換サイズ(MaxTbSizeY)値は32と決定されてよい。
【0226】
図24は、本発明の一実施例に係る上位レベルシンタックスを示す図である。
【0227】
最大変換サイズ(maximum transform size)が制限的であれば、それに伴い、サブブロック変換(subblock transform,SBT)が用いられてよい最大サイズも制限的であってよい。例えば、SBTが用いられてよい最大サイズは、最大変換サイズ以下であってよい。したがって、SBTが用いられてよい最大サイズを示すシンタックス要素が変わってよい。例えば、最大変換サイズ又は最大変換サイズを示すシンタックス要素に基づき、SBTが用いられてよい最大サイズを示すシンタックス要素がシグナルされてよい。
【0228】
図24を参照すると、最大変換サイズが64よりも小さい場合、SBTが用いられてよい最大サイズが64であるか否かを示すシンタックス要素はシグナルされず、SBTが用いられてよい最大サイズは推論(infer)されてよい。SBTが用いられてよい最大サイズが64であることを示すシンタックス要素は、sps_sbt_max_size_64_flagであってよい。図24を参照すると、sps_sbt_enabled_flagの値が1であり、sps_max_luma_tranform_size_64_flagの値が1である場合(すなわち、sps_sbt_enabled_flag&&sps_max_luma_tranform_size_64_flag)、sps_sbt_max_size_64_flagはシグナルされ、そうでない場合、sps_sbt_max_size_64_flagはシグナルされない。また、sps_sbt_max_size_64_flagが存在しない場合、sps_sbt_max_size_64_flagの値は0と推論(infer)されてよい。または、sps_sbt_max_size_64_flagが存在しない場合、その値はsps_max_luma_tranform_size_64_flagの値と推論(infer)されてよい。このとき、MaxSbtSizeは、図24の7-31に開示されているように、sps_sbt_max_size_64_flagが1である場合に64、sps_sbt_max_size_64_flagが0である場合に32に設定されてよい。
【0229】
図25は、本発明の一実施例に係る変換ツリーシンタックスを示す図である。
【0230】
図25は、図18のシンタックスを参照して説明したverSplitFirst値を決定するための条件が変更されたものであり、その他同一の説明は省略するものとする。
【0231】
TU分割方法は、ツリー類型(treeType)に基づいて互いに異なってよい。例えば、ツリー類型がDUAL_TREE_CHROMAである場合、各カラー(color)成分、すなわち、クロマ成分を有するブロックを基準にした幅、高さに基づいてTU分割がなされてよい。図18の実施例では図18の(3)に開示された条件を用いてverSplitFirstが決定されたが、DUAL_TREE_CHROMAである場合、図25の(2)に開示された条件を用いてverSplitFirstが決定されてよい。
【0232】
ブロックの幅と最大変換サイズ(maximum transform size)を決定する時は、ルーマを基準にしても、各カラー成分を基準にしても構わず、変換ツリーシンタックス‘transform_tree()’の入力は、ルーマを基準にした値が用いられてよい。しかし、ブロックの幅と高さを比較する時は、クロマ成分を基準にした値が用いられてよい。すなわち、tbWidth/SubWidthCとtbHeight/SubHeightCとを比較することが可能である。具体的に、tbWidth/SubWidthCがtbHeight/SubHeightCよりも大きいかどうか確認することが可能である。
【0233】
これにより、ツリー類型がデュアルツリー(dual tree)である場合に、ルーマ成分のときにおけると同じ基準でクロマ成分に対するTU分割が行われてよい。
【0234】
図25を参照すると、ツリー類型がSINGLE_TREE又はDUAL_TREE_LUMAである場合に、デコーダは、図25の(1)の過程を行ってverSplitFirstを決定することができる。すなわち、ルーマ成分を基準にした値を用いて分割が決定されてよい。ツリー類型がDUAL_TREE_CHROMAである場合に、デコーダは、図25の(2)の過程を行ってverSplitFirstを決定することができる。すなわち、クロマ成分を基準にした値を用いて分割が決定されてよい。
【0235】
図26は、本発明の一実施例に係るデコーディングプロセスを示す図である。
【0236】
図26に開示されたデコーディングプロセッサの一実施例は、図25に開示されたシンタックスに該当するデコーディングプロセスであってよい。上述と同様に、本明細書に記述されたTU分割は、TBを分割するのと同じ意味であってよい。
【0237】
TB分割又はverSplitFirstが決定される方法は、cIdx、ツリー類型(treeType)などに基づいて決定されてよい。例えば、cIdxが0である場合、各カラー(color)成分を基準にしたブロックの幅(width)、ブロックの高さ(height)を用いてverSplitFirstは決定されてよい。ツリー類型がDUAL_TREE_CHROMAである場合、各カラー成分を基準にしたブロックの幅(width)、ブロックの高さ(height)を用いてverSplitFirstは決定されてよい。cIdxが0でなく、ツリー類型がDUAL_TREE_CHROMAでない場合(すなわち、cIdxが0でなく、ツリー類型がSINGLE_TREEである場合)、ルーマ成分を基準にしたブロックの幅、ブロックの高さを用いてverSplitFirstは決定されてよい。
【0238】
すなわち、cIdxが0であるか、ツリー類型がDUAL_TREE_CHROMAである場合(cIdx==0||treeType==DUAL_TREE_CHROMAである場合)、nTbWがnTbHよりも大きいかを比較し、verSplitFirstが決定されてよい。すなわち、SubWidthCとSubHeightCを用いることなくverSplitFirstは決定されてよい。cIdxが0でなく、ツリー類型がDUAL_TREE_CHROMAでない場合(cIdx!=0&&treeType!=DUAL_TREE_CHROMAである場合)、nTbW/SubWidthCがnTbH/SubHeightCよりも大きいか比較し、verSplitFirstが決定されてよい。
【0239】
最大変換サイズ(maximum transform size)よりも最大変換スキップサイズ(maximum transform skip size)が小さくてよい。例えば、最大変換サイズが可変的であれば、それにしたがって最大変換スキップサイズが変わってよい。したがって、最大変換サイズが可変的であれば、それにしたがって最大変換スキップサイズをシグナルする方法は変わってよい。
【0240】
最大変換サイズと最大変換スキップサイズは同一であってよい。このとき、CU又はPUのサイズが最大変換サイズよりも大きいとき、分割されたTUに変換スキップ(transformskip)が用いられるか否かは共有されてよい。言い換えると、CU又はPUのサイズが最大変換サイズよりも大きいとき、分割されたTUに変換スキップが用いられるか否かを示すシンタックス要素のシグナルリングは、一部省略されてもよい。CU又はPUのサイズが最大変換サイズよりも大きいとき、分割されたTUのレジデュアル信号(residual signal)形態が類似であり得るためである。分割されたTUに変換スキップが用いられるか否かが共有される、或いは関連したシンタックス要素のシグナルリングが省略されることは、可変的な最大変換サイズ、可変的な最大変換スキップサイズを使用するとき、最大変換サイズと最大変換スキップサイズとが同一である場合に限ることができる。さらに、分割されたTUに変換スキップが用いられるか否かが共有されることは、基準となるTU、例えば、1番目のTUに変換スキップが用いられる場合に限ることができる。すなわち、基準となるTUに変換スキップが用いられない場合、分割された他のTUに対して変換スキップが用いられるか否かがシグナルされてよい。また、既に設定された順序で分割されたTUに変換スキップが用いられるか否かがシグナルされ、特定TUに変換スキップが用いられることがシグナルされると、その後、TUに対して変換スキップが用いられるか否かを示すシンタックス要素はシグナルされず、変換スキップが用いられると決定されてよい。
【0241】
分割されたTUに対する変換スキップが用いられるか否かが共有される或いは関連したシンタックス要素のシグナリングが省略される場合、CU又はPUレベルで変換スキップが用いられるか否かに対するシンタックス要素のシグナリングが可能である。
【0242】
図27は、本発明の一実施例に係るBDPCM実行方法を示す図である。
【0243】
BDPCM(block-based delta pulse code modulation)は、(イントラ)予測方法又はコーディング方法であってよい。また、BDPCMは、予測方法及びレジデュアル信号(residual signal)生成方法において固有の特徴を有することが可能である。すなわち、特定値(例えば、レジデュアル信号又は予測信号(prediction signal)又はピクチャーサンプル(picture sample)又は復元されたサンプル(reconstructed sample))の差に基づく値をコードしシグナルする方法であってよい。例えばエンコーダは、特定値の差に基づく値をシグナルし、デコーダはシグナリングに基づいて特定値を復元することができる。このとき、デコーダの復元過程において、特定値の差を計算する過程を逆に行わなければならず、シグナルされた値に基づいて加算する過程を行って特定値を復元することができる。BDPCMは、RDPCM(Quantized residual differential pulse coded modulation)と記述されてよい。
【0244】
BDPCMが用いられるか否かを示すシンタックス要素が存在してよい。例えば、前記シンタックス要素は、BdpcmFlag又はintra_bdpcm_flagであってよい。BDPCMが用いられるか否かを示すシンタックス要素のシグナリングは、CUレベルで行われてよい。また、BDPCMの使用可否を示す上位レベルにおけるシンタックス要素が存在してよい。例えば、BDPCMが用いられるか否かを示す上位レベルにおけるシンタックス要素は、sps_bdpcm_enabled_flagであってよい。また、シンタックス要素がシグナルされる上位レベルは、SPSレベル、スライスレベル(slice level)、タイルレベル(tile level)、タイルグループレベル(tile group level)であってよい。BDPCMが用いられるか否かを示す上位レベルにおけるシンタックス要素のシグナリングが可能である場合、BDCPMが用いられるか否かを示すシンタックス要素のシグナリングは行われなくてもよい。また、BDPCMが用いられるか否かを示す上位レベルにおけるシンタックス要素のシグナリングが可能でない場合、BDCPMが用いられるか否かを示すシンタックス要素のシグナリングは行われなくてもよい。
【0245】
BDPCMの予測モード(prediction mode)は制限的であってよい。BDPCMの予測モードを示すシンタックス要素は、BdpcmDir又はintra_bdpcm_dir_flagであってよい。BDPCMが使用される場合、予測モードは角度モードであってよい。具体的に、BDPCMが使用される場合、予測モードは水平モード(horizontal mode)(mode18;INTRA_ANGULAR18)又は垂直モード(vertical mode)(mode50;INTRA_ANGULAR50)であってよい。したがって、BDPCMが使用されるとき、ある位置の予測サンプル値は、水平モードである場合、前記ある位置の左側に該当する参照サンプル(reference sample)と同じ値であってよい。また、BDPCMが使用され、水平モードである場合、同一列(row)に該当する予測サンプル(すなわち、y座標が同一である予測サンプル)は、同一の値を有してよい。また、BDPCMが使用される場合、ある位置の予測サンプル値は、垂直モードである場合、前記ある位置の上側に該当する参照サンプルと同じ値であってよい。また、BDPCMが使用され、垂直モードである場合、同一行(column)に該当する予測サンプル(すなわち、x座標が同一である予測サンプル)は同一の値を有してよい。
【0246】
図27(a)は、BDPCMの予測モード導出(prediction mode derivation)を示す図であり、図27(a)を参照すると、BDPCMの予測モード導出は、BdpcmDirに基づくことができる。図27(a)で、BdpcmFlagの値が1である場合は、BDPCMが使用される場合を意味できる。IntraPredModeYは、予測モードを示す値であってよい。具体的に、IntraPredModeYは、ルーマ成分に対する予測モードを示す値であってよい。例えば、BdpcmDirに基づき、IntraPredModeYはINTRA_ANGULAR50又はINTRA_ANGULAR18に設定されてよい。BdpcmDirの値が1である場合、IntraPredModeYはINTRA_ANGULAR50に設定され、垂直モードであってよい。また、BdpcmDirの値が0である場合IntraPredModeYはINTRA_ANGULAR18に設定され、水平モードであってよい。IntraPredModeYに基づいて予測動作が行われてよい。
【0247】
BDPCMに対するレジデュアル信号生成方法又はスケーリング及び変換(scaling and transformation(transform))方法が存在してよい。上述したように、BDPCMが使用される場合、特定値の差に基づく値はコード、シグナルされてよい。例えば、BDPCMが使用される場合、レジデュアル信号又はレジデュアル信号に基づく値の差に基づく値は、コード、シグナルされてよい。シグナルされる第1位置のサンプルに該当する値は、前記第1位置を基準にした第2位置の値と前記第1位置の値との差であってよい。具体的に、シグナルされる第1位置のサンプルに該当する値は、前記第1位置と隣接した位置である第2位置の値と前記第1位置の値との差であってよい。シグナルされる第1位置(x,y)のサンプルに該当する値は、水平モードである場合、第2位置(x-1,y)の値と前記第1位置の値との差であってよい。また、シグナルされる第1位置(x,y)のサンプルに該当する値は、垂直モードである場合、第2位置(x,y-1)の値と前記第1位置の値との差であってよい。このとき、第2位置の値と第1位置の値は、レジデュアル信号又はレジデュアル信号に基づく値であってよい。
【0248】
図27(b)は、BDPCMが使用される場合、デコーダでの動作を示す図である。図27(b)を参照すると、dzは、シンタックス要素(syntaxelement)でシグナルされた値に基づいて作ったアレイ(array)であってよい。また、水平モードである場合、dz[x][y]値は、dz[x][y]とdz[x-1][y]に基づいて設定されてよい。例えば、水平モードである場合、dz[x][y]値は、(dz[x-1][y]+dz[x][y])に基づいて設定されてよい(図27(b)の8-961)。このような設定は、xが0よりも大きい場合(ブロックの左側境界(left boundary)に接しない場合)に行われてよく、xが0である場合には、dz[x][y」はdz[x][y]そのままであってよい。垂直モードである場合、dz[x][y]値は、dz[x][y]とdz[x][y-1]に基づいて設定されてよい。垂直モードである場合、dz[x][y]値は、(dz[x][y-1]+dz[x][y])に基づいて設定されてよい(図27(b)の8-962)。このような設定は、yが0よりも大きい場合(ブロックの上側境界(top boundary)に接しない場合)に行われてよく、yが0である場合には、dz[x][y」はdz[x][y]そのままであってよい。和(+)演算に基づいてdzが計算されることは、シグナルされた信号が差(-)演算に基づくものであるためである。例えば、シグナルされた信号dz[x][y」は、水平モードである場合、(dz[x][y]-dz[x-1][y])に設定され、垂直モードである場合、(dz[x][y]-dz[x][y-1])に設定された値であってよい。したがって、これを復元するために、デコーダは和演算に基づく計算を行うことができる。また、前記dz[x][y]値に基づいてdnc[x][y]が導出(derivation)されてよく、d[x][y]が導出されてよい(図27(b)の8-963、8-964)。
【0249】
本発明の一実施例において、変換(transform)は、d[x][y]に基づいて行われてよい。このとき、変換を行うことは、変換スキップモード(transform skip mode)を行うことを含むことができる。すなわち、変換を行うことは、変換メトリックス(transformation matrix)に基づく演算を行わないことを含むことができる。BDPCMが使用される場合、常に変換スキップモードは用いられてよい。BDPCMが使用される場合、変換スキップモードの使用されるか否かを示すシンタックス要素であるtransform_skip_flagの値は、常に1であってよい。変換スキップモードが使用される場合、前記d[x][y]にベクトル(vector)又はメトリックス(matrix)を掛ける過程無しでレジデュアル信号は決定されてよい。変換スキップモードが使用される場合、前記d[x][y]にビットシフト(bit shift)又はラウンティング(rounding)以外の演算は行われずにレジデュアル信号が決定されてよい。例えば、変換スキップモードが使用される場合、(d[x][y]<<tsShift)値が、レジデュアルサンプルアレイ値(residual sample array value)であるr[x][y]になり得る。ここで、tsShiftは、変換ブロックの幅及び高さに基づいて決定される値であってよい。また、r[x][y]に基づいて中間レジデュアルサンプル(intermediate residual sample)及びレジデュアルサンプル(residual sample)が決定されてよい。また、変換スキップモードが適用される場合にのみ、BDPCMは使用可能であってよい。BDPCMが使用される場合に、変換スキップモードが使用可能なためである。例えば、上位レベルでシグナルされるシンタックス要素が、変換スキップモードが使用可能であることを示す場合にのみ、BDPCM使用可能であることを示す上位レベルにおけるシンタックス要素のシグナリングが行われてよい。
【0250】
図28は、本発明の一実施例に係るBDPCMに関連したシンタックスを示す図である。
【0251】
BDPCMの使用可否を示す上位レベルでシグナルされるシンタックス要素が、BDPCMが使用可能であることを示す場合、BDPCMは用いられてよい。図28を参照すると、sps_bdpcm_enabled_flagに基づき、intra_bdpcm_flagのパースされるか否かが決定されてよい。
【0252】
また、変換スキップ(transform skip)が使用されてよいブロックサイズは制限的であってよい。例えば、変換スキップが使用されてよいブロックの幅(width)又は高さ(height)の最大値は、MaxTsSizeであってよい。したがって、ブロックの幅がMaxTsSize以下であり、ブロックの高さがMaxTsSize以下である場合、変換スキップは用いられてよい。一方、ブロックの幅がMaxTsSizeよりも大きいか、ブロックの高さがMaxTsSizeよりも大きい場合には、変換スキップは用いられなくてよい。変換(transform)はTUレベルで行われるため、ブロックの幅と高さは変換ブロックの幅と高さであってよい。このとき、変換ブロックの幅はtbWidth、変換ブロックの高さはtbHeightと記述されてよい。BDPCMは変換スキップを使用するので、BDPCMの使用可否は、MaxTsSizeに基づいて決定されてよい。また、BDPCMの使用可否は、CUレベルでシグナルされてよい。したがって、BDPCMの使用可否は、コーディングブロック(coding block,CB)の幅及び高さ(cbWidth及びcbHeightと記述されてもよい。)とMaxTsSizeに基づいて決定されてよい。例えば、cbWidthがMaxTsSize以下であり、cbHeightがMaxTsSize以下である場合、BDPCMは使用可能であってよい。cbWidthがMaxTsSizeよりも大きいか、cbHeightがMaxTsSizeよりも大きい場合には、BDPCMは使用可能でなくてよい。図28を参照すると、cbWidth<=MaxTsSizeであり、cbHeight<=MaxTsSizeである場合、intra_bdpcm_flagはパースされてよく、cbWidth>MaxTsSizeであるか、cbHeight>MaxTsSizeである場合、intra_bdpcm_flagはパースされなくてよい。このとき、intra_bdpcm_flagが存在しない場合、その値は0と推論(infer)されてよい。
【0253】
本発明の一実施例によれば、MaxTsSizeは、複数の値のいずれか一つの値が選択されて用いられてよい。例えば、MaxTsSizeは32以下の値であってよい。または、MaxTsSizeは、MaxTbSizeY以下の値であってよい。または、MaxTsSizeは、32、16、8、4のいずれか一つであってよい。また、MaxTsSizeを決定するためのシンタックス要素が存在してよい。例えば、Log2(MaxTsSize)に基づく値がシグナルされてよい。log2_transform_skip_max_size_minusNがシグナルされてよく、MaxTsSizeは(1<<(log2_transform_skip_max_size_minusN+N))であってよい。具体的に、Nは2であってよく、この場合、log2_transform_skip_max_size_minus2がシグナルされ、MaxTsSizeは(1<<(log2_transform_skip_max_size_minus2+2))であってよい。このとき、log2_transform_skip_max_size_minus2は、0から3までの範囲の値であってよく、この場合、MaxTsSizeは、4、8、16、32のいずれか一つの値であってよい。MaxTsSizeを決定するためのシンタックス要素は、上位レベルでシグナルされてよい。例えば、ピクチャーパラメータセット(picture parameter set)又はスライスレベルでシンタックス要素はシグナルされてよい。
【0254】
図29は、本発明の一実施例に係るBDPCM使用可能条件を示す図である。
【0255】
図28を参照すると、コーディングブロックの幅(cbWidth)及び高さ(cbHeight)がMaxTsSize以下である場合、BDPCMは使用可能であった。MaxTbSizeYがMaxTsSizeよりも大きく、コーディングブロックの幅及び高さがMaxTsSize以下であれば、コーディングブロックの幅及び高さは、変換ブロックの幅及び高さと同一であってよい。このような場合にはTU分割が発生しないわけである。具体的に、MaxTbSizeYが64であり、MaxTsSizeが32以下である場合、cbWidthがMaxTsSize以下であり、cbHeightがMaxTsSize以下であれば、cbWidthはtbWidthと同一であり、cbHeightはtbHeightと同一であってよい。したがって、cbWidth及びcbHeightがMaxTsSize以下の時にBDPCMが使用可能であることは、tbWidth及びtbHeightがMaxTsSize以下の時にBDPCMが使用可能であることと同じ意味であってよい。
【0256】
しかし、本発明の一実施例によれば、MaxTbSizeYは、MaxTsSizeと同一であるか小さくてよい。このとき、cbWidthがMaxTsSizeよりも大きいか、cbHeightがMaxTsSizeよりも大きいと、BDPCMは使用可能である。このような場合にTU分割が発生することがあり、TU分割後の変換ブロックの幅及び高さはMaxTsSize以下であるためである。MaxTbSizeYがMaxTsSizeと同一である場合、cbWidthがMaxTsSizeよりも大きいか、cbHeightがMaxTsSizeよりも大きいと、TU分割が発生することがあり、TU分割後の変換ブロックが幅及び高さはMaxTbSizeYと同一であってよい。したがって、BDPCMである場合に使用されるモードである変換スキップモード(transform skip mode)を行うことが可能である。変換スキップモードはTUレベルで行われるためである。BDPCMが使用可能な場合に、intra_bdpcm_flagはパースされてよい。
【0257】
したがって、MaxTbSizeYとMaxTsSizeとが同一である場合にもBDPCMは使用可能である。または、BDPCMが使用可能か否かを示す上位レベルでシグナルされるシンタックス要素が、BDPCMが使用可能であることを示し、MaxTbSizeYとMaxTsSizeとが同一である場合、BDPCMは使用可能である。または、MaxTbSizeYとMaxTsSizeとが異なる場合にも、cbWidthがMaxTsSize以下であり、cbHeightがMaxTsSize以下である場合に、BDPCMは使用可能である。または、BDPCMが使用可能か否かを示す上位レベルでシグナルされるシンタックス要素が、BDPCMが使用可能であることを示し、MaxTbSizeYとMaxTsSizeとが異なる場合、cbWidthがMaxTsSize以下であり、cbHeightがMaxTsSize以下である場合に、BDPCMは使用可能である。一方、MaxTbSizeYとMaxTsSizeとが異なる場合、cbWidthがMaxTsSizeよりも大きいか、cbHeightがMaxTsSizeよりも大きい場合には、BDPCMが使用できない。
【0258】
BDPCMが使用可能なとき、BDPCMの使用可否を示すシンタックス要素であるintra_bdpcm_flagはパースされてよい。
【0259】
上述した通り、MaxTbSizeYは32以上の値を有してよい。具体的に、MaxTbSizeYは、32又は64の値を有してよい。また、MaxTsSizeは32以下の値を有してよい。具体的に、MaxTsSizeは4又は8又は16又は32の値を有してよい。したがって、MaxTbSizeYとMaxTsSizeとが同一である場合は、MaxTbSizeYが32であり、MaxTsSizeが32である場合であってよい。
【0260】
図29(a)及び(b)は、上述した実施例に関連したシンタックス構造を示す図である。
【0261】
図29(a)を参照すると、sps_bdpcm_enabled_flagの値が1であり、次の2つの条件のうち少なくとも一つを満たすとき、intra_bdpcm_flagはパースされてよい。
【0262】
条件a-1)cbWidth<=MaxTsSize&&cbHeight<=MaxTsSize
【0263】
条件a-2)MaxTbSizeY==32&&MaxTsSize==32
【0264】
一方、条件a-1、a-2の両方を満たさないと、intra_bdpcm_flagはパースされなくてよい。一方、intra_bdpcm_flagが存在しない場合、intra_bdpcm_flagの値は0と推論(infer)されてよい。
【0265】
図29(b)を参照すると、sps_bdpcm_enabled_flagの値が1であり、次の2つの条件のうち少なくとも一つを満たすとき、intra_bdpcm_flagはパースされてよい。
【0266】
条件b-1)cbWidth<=MaxTsSize&&cbHeight<=MaxTsSize
【0267】
条件b-2)MaxTbSizeY==MaxTsSize
【0268】
一方、条件b-1、b-2の両方を満たさないと、intra_bdpcm_flagはパースされなくてよい。一方、intra_bdpcm_flagが存在しない場合、intra_bdpcm_flagの値は0と推論(infer)されてよい。
【0269】
図30は、本発明の一実施例に係るCIIPとイントラ予測を示す図である。
【0270】
CIIPは、combined inter-and intra-prediction又はcombined inter-picture merge and intra-picture predictionの略称である。CIIPは、予測信号(prediction signal)が生成するとき、イントラ予測信号(intra prediction signal)とインター予測信号(inter prediction signal)とを結合する方法を意味する。CIIPが用いられるとき、イントラ予測(intra prediction)方法又はインター予測(inter prediction)方法は制限的であってよい。例えば、CIIPが用いられるとき、イントラ予測モード(intra prediction mode)は、平面モード(planar mode)(MODE_PLANAR)のみが用いられるか、マージモード(merge mode)のみが用いられてよい。コーディングブロック(coding block,CB)又はコーディングユニット(coding unit,CU)にCIIPが用いられる場合、コーディングブロック全体に対してイントラ予測が行われてよい。すなわち、CB又はCUにCIIPが用いられる場合、(cbWidth xcbHeight)サイズを有するブロックに対してイントラ予測が行われてよい。言い換えると、CB又はCUにCIIPが用いられる場合、TU分割無しでイントラ予測が行われてよい。CBが最大変換サイズ(maximum transform size)よりも大きくても、CIIPが用いられるとTU分割無しでイントラ予測が行われてよい。
【0271】
CIIPが使用されてよいブロックサイズは制限的であってよい。このとき、制限されるブロックサイズは、固定された値であってよい。CIIPが使用されてよいブロックサイズの最大値があらかじめ定められていてよい。例えば、ブロックの幅(cbWidth)又は高さ(cbHeight)が128であるか、128以上である場合、CIIPは用いられなくてよい。cbWidthが128よりも小さく、cbHeightが128よりも小さく、cbWidth*cbHeightが64以上である場合、CIIPは用いられてよい。
【0272】
図30は、CB又はCUが64×64である場合にCIIPモードとイントラ予測モードについて示している。CIIPモードが用いられる場合、64×64サイズのブロックに対するインター予測と、64×64サイズのブロックに対するイントラ予測が行われてよい。また、前記インター予測と前記イントラ予測に基づいて64×64サイズの予測ブロック(predicted block、図30の“Combined inter and intra predicted block”)を生成することができる。
【0273】
イントラ予測モードが使用されない場合(すなわち、現在ピクチャーのみ使用される場合、又は参照ピクチャー(reference picture)が使用されない場合、又はCuPredModeがMODE_INTRAである場合)、64×64サイズのCBから分割されるTBは、MaxTbSizeYに基づいて決定されてよい。例えば、MaxTbSizeYが64よりも小さい場合(例えば、32である場合)、64×64サイズのCBは、32×32サイズのTUに分割されてよく、分割されたTUに対してそれぞれイントラ予測が行われてよい。したがって、32×32サイズの予測されたブロック(predicted block)は、4個生成されてよい。
【0274】
このとき、CIIPモードでのイントラ予測とイントラ予測モードでのイントラ予測が互いに整列(align)されないという問題があり得る。言い換えると、CIIPモードが用いられる場合、イントラ予測は、32×32サイズよりも大きいブロックに対して行われてよく、イントラ予測モードでのイントラ予測は、32×32サイズ以下のブロックに対して行われてよい。したがって、イントラ予測モードの場合、32×32サイズ以下のブロックに対するイントラ予測を処理できる能力(capability)を有するハードウェア、ソフトウェアが必要であるが、CIIPモードの場合、32×32サイズよりも大きいイントラ予測を処理できる能力を有するハードウェア、ソフトウェアが必要である。これは、具現側面において大きな負担となり得る。例えば、あるエンコーダ(encoder)は、最大変換サイズを64ではなく32に制限し、小さいサイズのブロックに対してイントラ予測を行うことで、ハードウェア、ソフトウェアの負担を減らしたいものの、CIIPモードを使用するには32よりも大きいサイズのブロックに対するイントラ予測を準備しなければならないことがある。
【0275】
図31は、本発明の一実施例に係るマージデータシンタックスを示す図である。
【0276】
本発明の一実施例をよれば、マージモードシグナリング(merge mode signaling)方法としてグルーピング(grouping)方法が用いられてよい。例えば、group_1_flagがシグナルされてよく、デコーダはgroup_1_flagに基づき、選択されるモードがグループ1(group1)に属するか否かが決定できる。group_1_flagが、グループ1(group 1)でないことを示す場合、group_2_flagがシグナルされてよい。また、デコーダは、group_2_flagに基づき、選択されるモードがグループ2(group2)に属するか否かが決定できる。このような動作は、複数のグループ(group)が存在する場合にも行われてよい。また、グループ内のモードを示すシグナリングが存在してよい。グルーピング方法は、順次にシグナルする方法に比べて、シグナリングの深さ(depth)を減らすことができる。また、シグナリングの最大長(例えば、コードワード(codeword)の最大長)を減らすことができる。
【0277】
以下では、グルーピング方法について具体的に説明する。
【0278】
まず、3個のグループが存在すると仮定する。特定グループは一つ以上のモードを含むことができる。例えば、グループ1に含まれるモードは1個であってよい。また、グループ2とグループ3に含まれるモードはそれぞれ2個であってよい。グループ1にサブブロックマージモード(subblock merge mode)が含まれ、グループ2にレギュラーマージモード(regular merge mode)とMMVD(Merge with Motion Vector Difference)が含まれ、グループ3にはCIIPと三角マージモード(triangle merge mode)が含まれてよい。group_1_flagは、merge_subblock_flag、group_2_flagは、regular_merge_flagであってよい。また、group内のモードを示すシンタックス要素としてciip_flagとmmvd_merge_flagが存在してよい。一実施例において、merge_subblock_flagがシグナルされ、merge_subblock_flagに基づいて現在モードがサブブロックマージモードか否かが決定されてよい。このとき、サブブロックマージモードでない場合、regular_merge_flagがシグナルされてよい。デコーダは、regular_merge_flagに基づき、モードがグループ2(レギュラーマージモード又はMMVD)に含まれるか、グループ3(CIIP又は三角マージモード)に含まれるかが決定できる。このとき、regular_merge_flagがグループ2を示す場合、mmvd_merge_flagに基づいて現在モードがレギュラーマージモードか、MMVDかが決定されてよい。一方ねregular_merge_flagがグループ3を示す場合、ciip_flagに基づき、現在モードがCIIPか三角マージモードかが決定されてよい。
【0279】
図31を参照すると、マージモード(merge mode)が用いられる場合、merge_subblock_flagがシグナルされてよい。マージモードが用いられる場合の一実施例は、上述した通りであってよく、general_merge_flagが1である場合であってよい。また、本発明は、CuPredModeがMODE_IBCでない場合、又はCuPredModeがMODE_INTERである場合に適用されてよい。デコーダは、merge_subblock_flagをMaxNumSubblockMergeCand、ブロックサイズ(block size)に基づいてパースするかどうか決定できる。merge_subblock_flagの値が1である場合、デコーダは、サブブロックマージモード(subblock merge mode)を使用すると決定でき、さらに、merge_subblock_idxに基づいてcandidate indexを決定できる。merge_subblock_flagの値が0である場合、デコーダは、regular_merge_flagをパースすることができる。このとき、regular_merge_flagがパースされるための条件が存在してよい。例えば、ブロックサイズに基づく条件があり得る。また、モードの使用可否を示す上位レベルでシグナルされるシンタックス要素に基づく条件があり得る。このとき、モードの使用可否を示す上位レベルでシグナルされるシンタックス要素は、sps_ciip_enabled_flag、sps_triangle_enabled_flagがあり得る。このとき、sps_triangle_enabled_flagは、デコーダが三角モード(triangle mode)を使用できるか否かを示す上位レベルでシグナルされるシンタックス要素であってよく、シーケンスパラメータセット(sequence parameter set)でシグナルされてよい。また、スライス類型(slice type)に基づく条件があり得る。また、cu_skip_flagに基づく条件があり得る。このとき、cu_skip_flagは、スキップモード(skip mode)の使用可否を示すシンタックス要素であってよい。スキップモードが用いられる場合、レジデュアル信号(residual signal)はシグナルされなくてよい。したがって、スキップモードが用いられる場合、デコーダはレジデュアル信号(residual signal)(又は、変換係数(transform coefficient))無しで予測信号(prediction signal)からブロックを復元できる。
【0280】
CIIPが使用されてよいブロックサイズ(block size)に関連した条件は、ブロックの幅(width)*ブロックの高さ(height)が64以上であり、ブロックの幅が128よりも小さく、ブロックの高さが128よりも小さいということであってよい。また、三角マージモードが使用されてよいブロックサイズ条件は、ブロックの幅(width)*ブロックの高さ(height)が64以上であるということであってよい。図31を参照すると、ブロックの幅(width)*ブロックの高さ(height)が64以上である条件を満たさない場合、デコーダは、regular_merge_flagをパースしなくてよい。また、ブロックの幅(width)が128と同一である(又は、以上である)か、ブロックの高さ(height)が128と同一である(又は、以上である)場合、デコーダはregular_merge_flagをパースすることができる。
【0281】
具体的に、i)sps_ciip_enabled_flagの値が1であり、cu_skip_flagの値が0であり、ブロックの幅(width)が128よりも小さく、ブロックの高さ(height)が128よりも小さいとき、ブロックの幅(width)*ブロックの高さ(height)が64以上である場合を満たすと、デコーダはregular_merge_flagをパースすることができる。または、ii)sps_triangle_enabled_flagの値が1であり、MaxNumTriangleMergeCandの値が1よりも大きく、slice_typeがBであるとき、ブロックの幅(width)*ブロックの高さ(height)が64以上である場合を満たすと、デコーダはregular_merge_flagをパースすることができる。
【0282】
一方、上述したregular_merge_flagがパースされる条件を満たさない場合、すなわち、i)sps_ciip_enabled_flagの値が1であり、cu_skip_flagの値が0であり、ブロックの幅(width)が128よりも小さく、ブロックの高さ(height)が128よりも小さい場合を満たさなく、ii)sps_triangle_enabled_flagの値が1であり、MaxNumTriangleMergeCandの値が1よりも大きく、slice_typeがBである場合を満たさない場合に、デコーダはregular_merge_flagをパースしなくてよい。このとき、MaxNumTriangleMergeCandは、三角(マージ)モード(triangle(merge)mode)に使用可能な候補(candidate)の最大(maximum)個数であってよい。また、slice_typeは、スライス類型(slice type)を示すシグナリングであってよい。slice_typeがBであると、両方向予測(bi-prediction)が用いられてよいことを示す。slice_typeがPであると、両方向予測(bi-prediction)は用いられず、単方向予測(uni-prediction)が用いられてよいことを示す。slice_typeがP又はBであると、インター予測(inter prediction)が用いられてよいことを示す。slice_typeがIであると、インター予測が用いられなくてよいことを示す。
【0283】
また、図31を参照すると、デコーダがciip_flagをパースするか否か決定するとき、ブロックサイズに基づく条件が用いられてよい。例えば、ブロックの幅(width)が128よりも小さく、ブロックの高さ(height)が128よりも小さい場合、デコーダはciip_flagをパースすることができる。一方、ブロックの幅(width)が128である(又は、128以上である)か、ブロックの高さ(height)が128である(又は、128以上である)場合、デコーダはciip_flagをパースしなくてよい。ブロックの幅(width)又はブロックの高さ(height)が128である(又は、128以上である)場合、CIIPと三角マージモード(triangle merge mode)のいずれか一つしか使用できないためである。例えば、CIIPは使用できず、三角マージモードだけが用いられてよい。
【0284】
本発明において、ciip_flagがパースされてよいということは、CIIPが用いられてよいことを意味できる。または、ciip_flagがパースされてよいということは、CIIP又は三角マージモードが用いられてよいことを意味できる。
【0285】
CIIPが使用されてよい条件は、sps_ciip_enabled_flagの値が1であり、cu_skip_flagの値が0である場合を含むことができる。また、CIIPが使用されてよいブロックサイズに関連した条件は、ブロックの幅(width)*ブロックの高さ(height)が64以上であり、ブロックの幅(width)は128よりも小さく、ブロックの高さ(height)は128よりも小さい場合を含むことができる。
【0286】
三角マージモードが使用されてよい条件は、sps_triangle_enabled_flagの値が1であり、MaxNumTriangleMergeCandの値が1よりも大きく、slice_typeがBである場合を含むことができる。また、三角マージモードが使用されてよいブロックサイズに関連した条件は、ブロックの幅(width)*ブロックの高さ(height)が64以上である場合を含むことができる。
【0287】
上述したCIIPが使用されてよい条件又は上述した三角マージモードが使用されてよい条件を満たす場合、デコーダは、regular_merge_flagをパースすることができる。一方、CIIPが使用されてよい条件と三角マージモードが使用されてよい条件の両方を満たさない場合、デコーダはregular_merge_flagをパースしなくてよい。
【0288】
regular_merge_flagが存在しない場合、regular_merge_flagの値は、1と推論(infer)されてよい。本発明において、regular_merge_flagの値が1であれば、レギュラーマージモード(regular merge mode)又はMMVDが用いられてよい。したがって、上述したCIIPが使用されてよいブロックサイズに関連した条件と上述した三角マージモードが使用されてよいブロックサイズに関連した条件の両方を満たさない場合、使用可能なモードはレギュラーマージモードとMMVDであってよく、このとき、regular_merge_flagはパースされず、1と決定されてよい。
【0289】
また、上述したCIIPが使用されてよい条件と上述した三角マージモードが使用されてよい条件の両方を満たさない場合、使用可能なモードは、レギュラーマージモード又はMMVDであってよいので、regular_merge_flagはパースされず、1と推論(infer)されてよい。
【0290】
図31を参照すると、regular_merge_flagの値が1である場合、sps_mmvd_enabled_flag値に基づいてシンタックス要素がパースされてよい。sps_mmvd_enabled_flagは、MMVDが使用可能か否かを示す上位レベルでシグナルされるシンタックス要素であってよい。sps_mmvd_enabled_flagの値が0である場合、MMVDは使用されなくてよい。図31を参照すると、sps_mmvd_enabled_flagの値が0である場合、mmvd_merge_flag、mmvd_cand_flag、mmvd_distance_idx、mmvd_direction_idxはパースされなくてよい。mmvd_merge_flagが存在しない場合、mmvd_merge_flagの値は0と推論(infer)されてよい。
【0291】
また、図31を参照すると、regular_merge_flagの値が0であれば、上述したCIIPが使用されてよい条件と上述した三角マージモードが使用されてよい条件の両方を満たす場合、デコーダはciip_flagをパースすることができる。このとき、ciip_flagの値が1であれば、CIIPが使用され、ciip_flagの値が0であれば、三角マージモードが使用されてよい。ciip_flagの値が0である場合、CIIPが用いられないことを意味できる。一方、上述したCIIPが使用されてよい条件又は上述した三角マージモードが使用されてよい条件を満たさない場合、デコーダはciip_flagをパースしなくてよい。
【0292】
ciip_flagが存在しない場合、次の条件を全て満たすと、ciip_flagの値は1と推論(infer)されてよい。一方、次の条件のいずれか一つでも満たさないと、ciip_flagの値は0と推論(infer)されてよい。
【0293】
条件c-1)sps_ciip_enabled_flag==1
【0294】
条件c-2)general_merge_flag==1
【0295】
条件c-3)merge_subblock_flag==0
【0296】
条件c-4)regular_merge_flag==0
【0297】
条件c-5)cbWidth<128
【0298】
条件c-6)cbHeight<128
【0299】
条件c-7)cbWidth*cbHeight>=64
【0300】
条件c-8)cu_skip_flag==0
【0301】
sps_ciip_enabled_flagは、CIIPが用いられるか否かを示す上位レベルでシグナルされるシンタックス要素であってよい。sps_ciip_enabled_flagは、シーケンスパラメータセット(sequence parameter set)でシグナルされてよい。general_merge_flagは、マージモード(merge mode)の使用されるか否かを示すシンタックス要素であってよい。merge_subblock_flagは、サブブロックマージモード(subblock merge mode)の使用されるか否かを示すシンタックス要素であってよい。このとき、サブブロックマージモードは、アフィンマージモード(affine merge mode)、SbTMVP(subblock-based temporal motion vector prediction)であってよい。regular_merge_flagは、既存のマージモード(例えば、レギュラーマージモード)又はMMVD使用可否を示すシンタックス要素であってよい。
【0302】
図32は、本発明の一実施例に係るマージデータシンタックスを示す図である。
【0303】
上述したこと通り、CIIPが使用されてよいブロックサイズが制限的であり、このとき、ブロックサイズは固定した値であってよい。また、最大変換サイズ(maximum transform size)が可変的である場合、CIIPモードでのイントラ予測(intra prediction)とイントラ予測モード(intra prediction mode)でのイントラ予測が互いに整列(align)されないという問題がある。
【0304】
以下、このような問題を解決するための方法について、図32を参照して説明する。図32を参照すると、CIIPモードが使用されてよいブロックサイズは可変的であってよい。具体的に、CIIPモードが使用されてよいブロックサイズは、MaxTbSizeYに基づき得る。例えば、ブロックの幅(width)がMaxTbSizeY以下であり、ブロックの高さ(height)がMaxTbSizeY以下である場合、CIIPモードが用いられてよい。また、ブロックの幅(width)がMaxTbSizeYよりも大きいか、ブロックの高さ(height)がMaxTbSizeYよりも大きい場合、CIIPは使用されなくてよい。このとき、ブロックの幅(width)及びブロックの高さ(height)は、コーディングブロック(ユニット)の幅及び高さであってよい。ブロックの幅及び高さがMaxTbSizeYに基づいて決定されることにより、CIIPモードでのイントラ予測サイズはMaxTbSizeY以下に制限され、既存イントラ予測サイズもMaxTbSizeY以下に制限されるので、統一した方法、ハードウェア、ソフトウェアを用いてイントラ予測を行うことができる。これにより、ハードウェア、ソフトウェアに必要なリソースを低減できるという効果がある。MaxTbSizeYが32である場合にも、CIIPモードでのイントラ予測と既存のイントラ予測とも32×32以下サイズのブロックに対して行われてよい。
【0305】
図32を参照すると、CIIPモードが使用されるための条件は、sps_ciip_enabled_flagの値が1であり、cbWidthがMaxTbSizeY以下であり、cbHeightがMaxTbSizeY以下であり、cbWidth*cbHeightが64以上であり、cu_skip_flagの値が0である場合が含まれてよい。したがって、sps_ciip_enabled_flagの値が0であるか、cbWidthがMaxTbSizeYよりも大きいか、cbHeightがMaxTbSizeYよりも大きいか、cbWidth*cbHeightが64よりも小さいか、cu_skip_flagの値が0でない場合、CIIPモードは使用されない。デコーダは、CIIPモードを使用するための条件を満たす場合、ciip_flagをパースすることができる。また、CIIPモードを使用するための条件を満たす場合、デコーダはregular_merge_flagをパースすることができる。また、デコーダはciip_flag又はregular_merge_flagをパースするとき、追加の条件を考慮できる。また、デコーダは、CIIPモードが使用されなくてよい場合、ciip_flagをパースしなくてよい。
【0306】
三角(マージ)モード(triangle(merge)mode)が使用されるための条件は、sps_triangle_enabled_flagの値が1であり、MaxNumTriangleMergeCandの値が1よりも大きく、slice_typeがBであり、cbWidth*cbHeightが64以上である場合を含むことができる。
【0307】
このとき、前記CIIPモードが使用されるための条件と前記三角(マージ)モードが使用されるための条件の両方を満たす場合、デコーダはciip_flagをパースすることができる。前記CIIPモードが使用されるための条件又は前記三角(マージ)モードが使用されるための条件のいずれか一つでも満たさない場合、デコーダはciip_flagをパースしなくてよい。また、ciip_flagが存在しなく、前記CIIPモードが使用されるための条件を満たさない場合、ciip_flag値は0と推論(infer)されてよい。また、ciip_flagが存在しなく、前記CIIPモードが使用されるための条件を満たし、general_merge_flagの値が1であり、merge_subblock_flagの値が0であり、regular_merge_flagの値が0である場合、ciip_flagの値は1と推論(infer)されてよい。
【0308】
前記CIIPモードが使用されるための条件と前記三角(マージ)モードが使用されるための条件のいずれか一つでも満たす場合、デコーダはregular_merge_flagをパースすることができる。前記CIIPモードが使用されるための条件と前記三角(マージ)モードが使用されるための条件の両方を満たさない場合、デコーダはregular_merge_flagをパースしなくてよい。このとき、regular_merge_flagが存在しないと、regular_merge_flagの値は、(general_merge_flag&&!merge_subblock_flag)と推論(infer)されてよい。
【0309】
図32を参照すると、cbWidthがMaxTbSizeY以下であり、cbHeightがMaxTbSizeY以下である場合、デコーダはciip_flagをパースすることができる。一方、cbWidthがMaxTbSizeYよりも大きいか、cbHeightがMaxTbSizeYよりも大きい場合、デコーダはciip_flagをパースしなくてよい。cbWidthがMaxTbSizeYよりも大きいか、cbHeightがMaxTbSizeYよりも大きい場合、ciip_flagの値は0と推論(infer)されてよい。
【0310】
cbWidthがMaxTbSizeY以下であり、cbHeightがMaxTbSizeY以下である場合、デコーダは、regular_merge_flagをパースすることができる。一方、i)cbWidthがMaxTbSizeYよりも大きいか、cbHeightがMaxTbSizeYよりも大きく、ii)前記三角(マージ)モードが使用されるための条件を満たさない場合、regular_merge_flagはパースされなくてよい。
【0311】
下記の式5の条件を満たす場合、デコーダはciip_flagをパースすることができる。
【0312】
【数5】
【0313】
ciip_flagが存在しないと、次の条件を全て満たす場合、ciip_flagの値は1と推論(infer)されてよい。一方、次の条件のいずれか一つでも満たさない場合、ciip_flagの値は0と推論(infer)されてよい。
【0314】
条件d-1)sps_ciip_enabled_flag==1
【0315】
条件d-2)general_merge_flag==1
【0316】
条件d-3)merge_subblock_flag==0
【0317】
条件d-4)regular_merge_flag==0
【0318】
条件d-5)cbWidth<=MaxTbSizeY
【0319】
条件d-6)cbHeight<=MaxTbSizeY
【0320】
条件d-7)cbWidth*cbHeight>=64
【0321】
条件d-8)cu_skip_flag==0
【0322】
下記の式6の条件を満たす場合、デコーダはregular_merge_flagをパースすることができる。
【0323】
【数6】
【0324】
regular_merge_flagが存在しない場合、regular_merge_flagの値は(general_merge_flag&&!merge_subblock_flag)と推論(infer)されてよい。すなわち、general_merge_flagの値が1であり、merge_subblock_flagの値が0である場合、regular_merge_flagの値は1と推論(infer)されてよい。一方、general_merge_flagの値が0であるか、merge_subblock_flagの値が1である場合、regular_merge_flagは0と推論(infer)されてよい。
【0325】
図33は、本発明の一実施例に係るCIIPモードの実行方法を示す図である。
【0326】
図33は、図30で説明した問題を解決するための実施例を示す図であってよい。
【0327】
本発明の一実施例において、CIIPモードにおけるイントラ予測は、変換ブロック(ユニット)単位で行われてよい。すなわち、CIIPモードが使用されるとき、TU分割が行われてよい。例えば、cbWidthがMaxTbSizeYよりも大きいか、cbHeightがMaxTbSizeYよりも大きい場合、CIIPモードが使用されてよく、この時にTU分割がなされ、(tbWidth xtbHeight)のブロックには(MaxTbSizeY×MaxTbSizeY)ブロック単位でイントラ予測(intra prediction)が行われてよい。これにより、既存のイントラ予測と同じリソースを用いてCIIPモードにおけるイントラ予測の実行が可能である。
【0328】
図33は、64×64サイズのCUにCIIPモードが使用され、MaxTbSizeYが32であるときの予測方法を示す。CIIPモードが使用されるので、インター予測(inter prediction)が使用された予測信号(prediction signal)とイントラ予測が使用された予測信号に基づいて予測信号が生成されてよい。このとき、インター予測は64×64サイズのCUに対して行われてよい。また、64×64サイズのブロックはMaxTbSizeYを超えるため、イントラ予測が行われる前にTU分割がなされてよい。TU分割後のブロックは、MaxTbSizeY×MaxTbSizeYサイズのブロックであってよい。すなわち、TU分割以後、複数個の32×32サイズのブロックが生成されてよい。また、TU分割後に生成されたブロックに対してそれぞれイントラ予測が行われてよい。
【0329】
以下、CIIPモードが使用され、TU分割される場合、イントラ予測方法について説明する。
【0330】
TU分割後のイントラ予測は、分割後の各TUと隣接した位置の参照サンプル(reference sample)を使用することができる。ブロックと近接している参照サンプルが使用されるので、予測性能の側面で利点があり、コーディング効率(coding efficiency)側面でも利点がある。例えば、参照サンプルは、復元されたサンプルであってよい。ただし、このような場合、特定TUに対してイントラ予測を行うためには、隣接したTU(すなわち、参照サンプルの位置に該当するTU)が復元されるまで待たなければならず、余分の遅延(latency)が発生することがある。また、参照サンプルは、予測されたサンプル(predicted sample)であってよい。この場合、復元されたサンプル(reconstructed sample)を使用することに比べて、予測性能は低下し得るが、隣接したTUが完全に復元されなくても、予測が完了する場合には現在TUに対する予測が始まり得る。したがって、復元されたサンプルを参照サンプル(reference sample)として使用する場合に比べて遅延(latency)を減らすことができる。ただし、予測されたサンプルを参照サンプルとして使用しても、遅延(latency)に関する問題があり得る。
【0331】
TU分割後のイントラ予測は、TU分割前CUと隣接した位置の参照サンプルを使用することができる。この場合には、上述した遅延(latency)問題を解決することができる。ただし、隣接していないサンプルを使用するため、予測性能が低下し得る。また、分割されたTUのうち一部は、TUに隣接していない参照サンプルを使用してイントラ予測が行われるため、既存のイントラ予測とは異なる位置の参照サンプルが必要であり、既存のイントラ予測とは異なるプロセスが必要である。
【0332】
CIIPモードが使用される時にTU分割が行われる場合、CUのサイズが大きくてもCIIPモードにおける予測が行われてよい。CIIPモードに含まれるイントラ予測は、サイズの大きいCUに対して行われてよく、CIIPモードに含まれるイントラ予測はTU分割後に、分割されて小さくなったブロックに対して行われてよいためである。したがって、CIIPモードを使用できるブロックサイズに関連した条件は、上限がなくてもよい。すなわち、図31及び図32で記述されたcbWidthは128よりも小さく、cbHeightは128よりも小さいという条件は存在しなくてもよい。したがって、ブロックサイズに対して(cbWidth*cbHeight)が64以上である条件を満たすと、デコーダは、ciip_flag又はregular_merge_flagをパースすることができる。言い換えると、cbWidthが64よりも大きいか、cbHeightが64よりも大きいか(図31参照)、cbWidthがMaxTbSizeYよりも大きいか、cbHeightがMaxTbSizeYよりも大きくても(図32参照)、デコーダはciip_flag又はregular_merge_flagをパースすることができる。
【0333】
具体的に、次の条件を満たす場合、ciip_flagはパースされてよい。一方、次の条件のいずれか一つでも満たさない場合、ciip_flagはパースされなくてよい。
【0334】
条件e-1)sps_ciip_enabled_flag==1
【0335】
条件e-2)sps_triangle_enabled_flag==1
【0336】
条件e-3)MaxNumTriangleMergeCand>1
【0337】
条件e-4)slice_type==B
【0338】
条件e-5)cu_skip_flag==0
【0339】
条件e-6)cbWidth*cbHeight>=64
【0340】
ciip_flagが存在しないと、次の条件を全て満たす場合、ciip_flagは1と推論(infer)され、次の条件のいずれか一つでも満たさない場合、ciip_flagは0と推論(infer)されてよい。
【0341】
条件f-1)sps_ciip_enabled_flag==1
【0342】
条件f-2)general_merge_flag==1
【0343】
条件f-3)merge_subblock_flag==0
【0344】
条件f-4)regular_merge_flag==0
【0345】
条件f-5)cbWidth*cbHeight>=64
【0346】
条件f-6)cu_skip_flag==0
【0347】
次の条件を全て満たす場合、regular_merge_flagはパースされてよい。一方、次の条件のいずれか一つでも満たさない場合、regular_merge_flagはパースされなくてよい。
【0348】
条件g-1)cbWidth*cbHeight>=64
【0349】
条件g-2)
【0350】
(sps_ciip_enabled_flag&&cu_skip_flag==0)||(sps_triangle_enabled_flag&&MaxNumTriangleMergeCand>1&&slice_type==B)
【0351】
regular_merge_flagが存在しない場合、regular_merge_flagの値は推論(infer)されてよいが、これは、図31図32で説明したのと同一であり、省略するものとする。
【0352】
図34は、本発明の一実施例に係るクロマBDPCMシンタックス構造を示す図である。
【0353】
図27図29で説明したBDPCMは、クロマ成分(chroma component)に対して行われてよい。クロマ成分に対してBDPCMが行われることにより、特定ビデオコンテンツ(video contents)に対する圧縮性能が向上し得る。本発明において、クロマブロックにBDPCMが適用されることを、クロマBDPCMと記述するものとする。
【0354】
クロマ成分に対してBDPCMが行われるためには別個のシグナリング方法が必要であり、図34で説明する。また、図34に開示されたシンタックスは、コーディングユニットシンタックス(coding unit syntax)に含まれていてよい。
【0355】
ツリー類型(treeType)値がSINGLE_TREEであるか、DUAL_TREE_CHROMAである場合、図34に開示されたシンタックス要素はパースされてよい。また、ChromaArrayTypeが0でない場合に、図34に開示されたシンタックス要素はパースされてよい。ChromaArrayTypeは、separate_colour_plane_flagの値が0である場合、chroma_format_idcの値に設定されてよい。ChromaArrayTypeはseparate_colour_plane_flagの値が1である場合、0に設定されてよい。このとき、separate_colour_plane_flagは、4:4:4クロマフォーマットのカラー成分(color component)が個別に(separately)コードされるか否かを示すことができる。例えば、separate_colour_plane_flagの値が0である場合、カラー成分は個別に(separately)コードされないことを示すことができる。separate_colour_plane_flagの値が0であり、Monochromeでない場合、ChromaArrayTypeは0でなくてよい。
【0356】
pred_mode_plt_flagの値が1であり、ツリー類型(treeType)がDUAL_TREE_CHROMAである場合、‘palette_coding()’が行われてよい。pred_mode_plt_flagは、パレットモード(palette mode)の使用されるか否かを示すシンタックス要素であり、‘palette_coding()’は、パレットモードに関連したシンタックス要素をパースする部分であってよい。pred_mode_plt_flagの値が0であるか、ツリー類型値がDUAL_TREE_CHROMAでない場合、デコーダは、図34の(1)以下の段階を行うことができる。
【0357】
また、cu_act_enabled_flagに基づき、図34の(1)以下の段階が行われてよい。cu_act_enabled_flagは、適応的カラー変換(adaptive color transform)が適用されるか否かを示すシンタックス要素であってよい。cu_act_enabled_flagの値が1である場合、レジデュアル信号(residual signal)は、他のカラースペース(color space)にコードされてよく、cu_act_enabled_flagの値が0である場合、レジデュアル信号(residual signal)は元来の(original)カラースペースにコードされてよい。前記元来の(original)カラースペースは、YUVカラースペース又はYCbCrカラースペースであってよい。前記他のカラースペース(color space)は、YCgCoカラースペース又はRGBカラースペース(color space)であってよい。図34を参照すると、cu_act_enabled_flagの値が0である場合、図34の(1)以下の段階が行われてよい。一方、cu_act_enabled_flagの値が1である場合、図34の(1)以下の段階は行われなくてもよい。すなわち、cu_act_enabled_flagの値が0である場合、デコーダは、クロマイントラ予測(chroma intra prediction)に関連したシンタックス要素をパースでき、cu_act_enabled_flagの値が0でない場合、デコーダは、クロマイントラ予測に関連したシンタックス要素をパースしなくてよい。
【0358】
図34を参照すると、下記の式7の条件を満たす場合、デコーダはintra_bdpcm_chroma_flagをパースできる。
【0359】
【数7】
【0360】
intra_bdpcm_chroma_flagは、現在クロマコーディングブロック(chroma coding block)にBDPCMが適用されるか否かを示すシンタックス要素であってよい。例えば、intra_bdpcm_chroma_flagの値が1である場合、現在クロマコーディングブロック(chroma coding block)にBDPCMが適用されることを示し、intra_bdpcm_chroma_flagの値が0である場合、現在クロマコーディングブロックにBDPCMが適用されないことを示すことができる。図34を参照すると、intra_bdpcm_chroma_flagをパースするための条件が存在してよい。または、chroma BDPCMを使用できる条件が存在してよい。Chroma BDPCMを使用できる条件は、intra_bdpcm_chroma_flagをパースするための条件と同一であってよい。intra_bdpcm_chroma_flagがパースされるための条件は、上述した式7と同一であり、それを具体的に説明すると、次の通りである。
【0361】
条件h-1)cbWidth<=MaxTsSize
【0362】
条件h-2)cbHeight<=MaxTsSize
【0363】
条件h-3)sps_bdpcm_chroma_enable_flag==1
【0364】
前記条件のいずれか一つでも満たさない場合、デコーダは、intra_bdpcm_chroma_flagをパースしなくてよい。intra_bdpcm_chroma_flagが存在しない場合、intra_bdpcm_chroma_flagの値は0と推論(infer)されてよい。intra_bdpcm_chroma_flagの値が1であれば、デコーダは、クロマBDPCMに関連したシンタックスをパースすることができる。このとき、クロマBDPCMに関連したシンタックスはintra_bdpcm_chroma_dir_flagを含むことができる。intra_bdpcm_chroma_dir_flagは、クロマBDPCMの予測方向を示すフラグであってよい。例えば、intra_bdpcm_chroma_dir_flagは、クロマBDPCMの予測方向が水平(horizontal)か垂直(vertical)かを示すことができる。sps_bdpcm_chroma_enable_flagは、クロマBDPCMが使用可能か否かを示す上位レベルでシグナルされるシンタックス要素であってよい。例えば、sps_bdpcm_chroma_enable_flagは、現在コーディングユニットを含む範囲(例えば、シーケンス、ピクチャー、スライスなどのレベル)でシグナルされてよい。sps_bdpcm_chroma_enable_flagの値が1であれば、クローナBDPCMは使用されてよく、クロマBDPCMが使用されるか否かを示す追加のシンタックス要素が存在してよい。sps_bdpcm_chroma_enable_flagの値が0である場合、クロマBDPCMは使用されない。
【0365】
図34を参照すると、デコーダが、intra_bdpcm_chroma_flagをパースし、パーシングの結果、intra_bdpcm_chroma_flagの値が0である場合、デコーダは、クロマイントラ予測(chroma intra prediction)に関連したシンタックスをパースしない。このとき、クロマイントラ予測に関連したシンタックスは、cclm_mode_flag、cclm_mode_idx、intra_chroma_pred_modeなどがあり得る。このとき、cclm_mode_flagは、クロマイントラ予測モード(chroma intra prediction mode)としてCCLM(cross component linear model)が使用されるか否かを示すシンタックス要素であってよい。cclm_mode_flagは、クロマイントラ予測モード(chroma intra prediction mode)がINTRA_LT_CCLM、INTRA_L_CCLM、INTRA_T_CCLMののうち一つであるかを示すシンタックス要素であってよい。CclmEnabledは、CCLMが使用可能か否かを示す値であってよい。または、CclmEnabledは、CCLM使用可否を示すシンタックス要素のパースされるか否かを示す値であってよい。CCLMは、ルーマサンプルに基づくクロマ予測方法である。cclm_mode_idxは、CCLMが用いられる場合にパースされてよい。cclm_mode_idxは、複数個のCCLM方法のいずれの方法が用いられるか示すシンタックス要素であってよい。CCLMが使用されない場合、デコーダはintra_chroma_pred_modeをパースすることができる。このとき、intra_chroma_pred_modeは、クロマサンプルのイントラ予測モードを示すシンタックス要素であってよい。具体的に、intra_chroma_pred_modeはクロマ成分(chroma component)に対する予測モード(prediction mode)が平面モード(planar mode)(mode index 0)、DCモード(mode index 1)、垂直(vertical)モード(mode index 50)、水平(horizontal)モード(mode index 18)、対角モード(mode inde× 66)、DMモード(ルーマモードと同じモード)のいずれのモードが用いられるか示すシンタックス要素であってよい。
【0366】
図34を参照すると、intra_bdpcm_chroma_flagがパースされるための条件又はクロマBDPCMが使用されてよい条件を満たしても、クロマBDPCMが使用されないとシンタックス要素がシグナルされる場合、上述したクロマインター予測(chroma intra prediction)に関連したシンタックスがパースされないため、クロマ予測モードが決定されないという問題が発生し得る。
【0367】
図35は、本発明の一実施例に係るクロマBDPCMシンタックス構造を示す図である。
【0368】
図35の実施例は、図34で説明した問題を解決するための実施例であり、重複する内容は省略するものとする。
【0369】
図35を参照すると、intra_bdpcm_chroma_flagがパースされてよい条件又はクロマBDPCMが使用されてよい条件を満たす場合、デコーダは、intra_bdpcm_chroma_flagをパースすることができる。intra_bdpcm_chroma_flagがパースされてよい条件は、図35の(1)と同一であり、これは、上述した式7の通りである。すなわち、次の条件を全て満たす場合、クロマBDPCMは使用されてよく、次の条件のいずれか一つでも満たさない場合、クロマBDPCMは使用されなくてよい。また、次の条件のいずれか一つでも満たさない場合、intra_bdpcm_chroma_flagが存在しなくてよい。このとき、intra_bdpcm_chroma_flagが存在しないと、intra_bdpcm_chroma_flagの値は0と推論(infer)されてよい。
【0370】
条件i-1)cbWidth<=MaxTsSize
【0371】
条件i-2)cbHeight<=MaxTsSize
【0372】
条件i-3)sps_bdpcm_chroma_enable_flag==1
【0373】
図29で説明したBDPCM適用方法がクロマBDPCMにも適用されてよい。すなわち、コーディングブロックサイズ(cbWidth、cbHeight)がMaxTsSizeよりも大きくても、分割されたTU又はTBサイズがMaxTsSize以下であれば、クロマBDPCMは使用されてよい。したがって、次の条件を全て満たす場合、クロマBDPCMは使用されてよく、次の条件のいずれか一つでも満たさない場合、クロマBDPCMは使用されなくてよい。
【0374】
条件j-1)
【0375】
(cbWidth<=MaxTsSize&&cbHeight<=MaxTsSize)||(MaxTbSizeY==MaxTsSize)
【0376】
条件j-2)sps_bdpcm_chroma_enable_flag==1
【0377】
intra_bdpcm_chroma_flagの値が1であれば、デコーダは、クロマBDPCMに関連したシンタックスをパースすることができる。このとき、クロマBDPCMに関連したシンタックスは、intra_bdpcm_chroma_dir_flag、sps_bdpcm_chroma_enable_flagなどがあり得る。intra_bdpcm_chroma_dir_flag、sps_bdpcm_chroma_enable_flagなどは、図34で説明したのと同一であってよい。
【0378】
図35を参照すると、デコーダは、intra_bdpcm_chroma_flagをパースし、パーシングの結果、intra_bdpcm_chroma_flagの値が0である場合(クロマBDPCMが使用されない場合)、図35の(2)以下の段階を行うことができる。すなわち、デコーダは、他のクロマイントラ予測(chroma intra prediction)に関連したシンタックスをパースすることができる。他のクロマイントラ予測に関連したシンタックスは、図34で説明したのと同一であってよい。他のクロマイントラ予測に関連したシンタックスは、cclm_mode_flag、cclm_mode_idx、intra_chroma_pred_modeなどがあり得る。
【0379】
intra_bdpcm_chroma_flagの値が0であり、CclmEnabledの値が1である場合、デコーダは、cclm_mode_flagをパースすることができる。また、cclm_mode_flagの値が1であれば、デコーダはcclm_mode_idxをパースし、cclm_mode_flagの値が1でない場合、デコーダはintra_chroma_pred_modeをパースすることができる。
【0380】
図35を参照すると、intra_bdpcm_chroma_flagがパースされてよい条件を満たし、intra_bdpcm_chroma_flagのパーシングの結果、クロマBDPCMが使用されないとシンタックス要素がシグナルされた場合にも、図34とは違い、他のクロマ予測モードを決定するシンタックス要素がパースされてよいので、デコーダはクロマ予測モードを決定することができる。具体的に、ブロックの幅(width)及びブロックの高さ(height)が最大変換サイズ(maximum transform skip size)以下であり、クロマBDPCMの使用可否を示す上位レベルでシグナルされるシンタックス要素が使用される場合には、デコーダは、クロマBDPCMの使用可否を示すシンタックス要素をパースすることができる。このとき、パーシングの結果、クロマBDPCMが使用されないことを示す場合、デコーダは、いかなるクロマイントラ予測モードを使用しなければならないかを示すシンタックス要素(例えば、cclm_mode_flag、intra_chroma_pred_mode)に基づいてクロマイントラ予測モードを決定することができる。
【0381】
図36は、本発明の一実施例に係るBDPCMに関連した上位レベルシンタックスを示す図である。
【0382】
上述したように、BDPCMの使用可否を示すシンタックス要素を含む上位レベルシンタックスが存在してよい。例えば、BDPCMの使用可否を示す上位レベルでシグナルされるシンタックス要素は、前述したsps_bdpcm_enabled_flag、sps_bdpcm_chroma_enabled_flagなどがあり得る。具体的に、sps_bdpcm_enabled_flagは、ルーマ成分(luma component)に対するBDPCMの使用可否を示す上位レベルでシグナルされるシンタックス要素である。また、sps_bdpcm_chroma_enabled_flagは、クロマ成分(chroma component)に対するBDPCMの使用可否を示す上位レベルでシグナルされるシンタックス要素である。このとき、BDPCMの使用可否を示すシンタックス要素がシグナルされる上位レベルは、シーケンスレベル(sequence level)、シーケンスパラメータセットレベル(sequence parameter set,SPS level)、スライスレベル(slice level)、ピクチャーレベル(picture level)、ピクチャーパラメータセットレベル(picture parameter set,PPS level)であってよい。BDPCMの使用可否を示す上位レベルでシグナルされるシンタックス要素が、BDPCMが使用可能であること示す場合(例えば、値が1である場合)、BDPCMが使用されるか否かを示すシンタックス要素がさらに存在してよい。例えば、BDPCMが使用されるか否かを示すシンタックス要素は、ブロックレベル(block level)、コーディングユニット(ブロック)レベル(coding unit(block) level)に存在してよい。一方、BDPCMの使用可否を示す上位レベルでシグナルされるシンタックス要素が、BDPCMが使用できないことを示す場合(例えば、値が0である場合)、BDPCMが使用されるか否かを示すシンタックス要素はさらに存在しなくてよい。また、BDPCMの使用可否を示す上位レベルでシグナルされるシンタックス要素が存在しない場合、前記上位レベルでシグナルされるシンタックス要素の値は0と推論(infer)されてよい。また、sps_bdpcm_enabled_flagの使用可否に関連したシンタックス要素は、図28図29で説明したintra_bdpcm_flagであってよい。intra_bdpcm_flagは、intra_bdpcm_luma_flagと同一であってよい。また、sps_bdpcm_chroma_enabled_flagの使用可否に関連したシンタックス要素は、図34図35で説明したintra_bdpcm_chroma_flagであってよい。
【0383】
変換スキップ(transform skip)の使用可否を示す上位レベルでシグナルされるシンタックス要素が存在してよい。図36を参照すると、変換スキップの使用可否を示す上位レベルでシグナルされるシンタックス要素は、sps_transform_skip_enalbed_flagであってよい。このとき、変換スキップの使用可否を示すシンタックス要素がシグナルされる上位レベルは、シーケンスレベル(sequence level)、シーケンスパラメータセットレベル(sequence parameter set,SPS level)、スライスレベル(slice level)、ピクチャーレベル(picture level)、ピクチャーパラメータセットレベル(picture parameter set,PPS level)であってよい。変換スキップの使用可否を示す上位レベルでシグナルされるシンタックス要素が、変換スキップを使用できることを示す場合(例えば、値が1である場合)、変換スキップが使用されるか否かを示すシンタックス要素がさらに存在してよい。例えば、変換スキップが使用されるか否かを示すシンタックス要素は、ブロックレベル(block level)、コーディングユニット(ブロック)レベル(coding unit(block) level)レベルに存在してよい。一方、変換スキップの使用可否を示す上位レベルでシグナルされるシンタックス要素が、変換スキップを使用できないことを示す場合(例えば、値が0である場合)、変換スキップが使用されるか否かを示すシンタックス要素はさらに存在しない。変換スキップの使用可否を示す上位レベルでシグナルされるシンタックス要素が存在しない場合、前記上位レベルでシグナルされるシンタックス要素の値は0と推論(infer)されてよい。sps_transform_skip_enabled_flagの使用可否に関連したシンタックス要素は、図27図28で説明したtransform_skip_flagであってよい。
【0384】
上述した通り、BDPCMが使用されるためには、変換スキップが使用される必要がある。図36を参照すると、変換スキップの使用可否を示す上位レベルでシグナルされるシンタックス要素が、変換スキップを使用できることを示す場合、デコーダは、BDPCMの使用可否を示す上位レベルでシグナルされるシンタックス要素をパースすることができる。一方、変換スキップの使用可否を示す上位レベルでシグナルされるシンタックス要素が、変換スキップを使用できないことを示す場合、デコーダは、BDPCMの使用可否を示す上位レベルでシグナルされるシンタックス要素をパースしなくてよい。このとき、BDPCMの使用可否を示す上位レベルでシグナルされるシンタックス要素は、ルーマ成分(luma component)に関する情報とクロマ成分(chroma component)に関する情報の両方を含むことができる。
【0385】
sps_bdpcm_enabled_flagの値が1であれば、デコーダは、sps_bdpcm_chroma_enabled_flagをパースすることができる。一方、sps_bdpcm_enabled_flagの値が0である場合、デコーダは、sps_bdpcm_chroma_enabled_flagをパースしなくてよい。すなわち、ルーマ成分に対するBDPCMを使用できる場合にのみ、クロマ成分に対するBDPCMは使用可能である。
【0386】
図36を参照すると、デコーダは、sps_transform_skip_enabled_flagをパースし、パーシングの結果、sps_transform_skip_enabled_flagの値が1であれば、sps_bdpcm_enabled_flagをパースすることができる。デコーダは、sps_bdpcm_enabled_flagの値が1であれば、sps_bdpcm_chroma_enabled_flagをパースすることができる。
【0387】
図37は、本発明の一実施例に係るBDPCMに関する上位レベルでシグナルされるシンタックス要素を示す図である。
【0388】
図37の実施例において図36と重複する内容は省略するものとする。
【0389】
図37を参照すると、クロマBDPCMの使用可否は、クロマフォーマットに基づいて決定されてよい。カラーフォーマット(color format)に関連した情報は、chroma_format_idc、separate_colour_plance_flag、Chroma format、SubWidthC、SubHeightCなどがあり得る。具体的に、カラーフォーマットが4:4:4である場合、クロマBDPCMは使用可能であってよい。一方、カラーフォーマットが4:4:4でない場合、クロマBDPCMを使用可能でなくてよい。したがって、クロマBDPCMの使用可否は、chroma_format_idcに基づくことができる。例えば、chroma_format_idcの値が3である場合、デコーダは、クロマBDPCMの使用可否を示すシンタックス要素(sps_bdpcm_chroma_enabled_flag)をパースしてよく、そうでない場合、デコーダは、クロマBDPCMの使用可否を示すシンタックス要素(sps_bdpcm_chroma_enabled_flag)をパースしなくてよい。本発明において、カラーフォーマット(color format)は、クロマフォーマット(chroma format)と同じ意味で使われてもよい。
【0390】
図38は、本発明の一実施例に係るクロマBDPCMに関連したシンタックスを示す図である。
【0391】
ルーマ成分(luma component)に対するBDPCMの使用可否を示す上位レベルでシグナルされるシンタックス要素と、クロマ成分(chroma component)に対するBDPCMの使用可否を示す上位レベルでシグナルされるシンタックス要素は個別に存在しなくてよい。すなわち、一つのシンタックス要素でルーマ成分とクロマ成分の両方に対するBDPCMが使用可能か否かが指示されてよい。例えば、BDPCMの使用可否を示す上位レベルでシグナルされるシンタックス要素が、BDPCMを使用できるこを示す場合、ルーマ成分に対するBDPCM又はクロマ成分に対するBDPCMが使用可能であってよい。また、このとき、BDPCMが使用されるか否かを示す追加のシンタックス要素が存在してよい。例えば、前記追加のシンタックス要素は、上述したintra_bdpcm_flag、intra_bdpcm_chroma_flagであってよい。一方、BDPCMの使用可否を示す上位レベルでシグナルされるシンタックス要素が、BDPCMを使用できないことを示す場合、ルーマ成分及びクロマ成分の両方に対してBDPCMは使用されなくてよい。
【0392】
ルーマ成分に対するBDPCMが使用されるか否かを示すシンタックス要素とクロマ成分に対するBDPCMが使用されるか否かを示すシンタックス要素は、ルーマ成分及びクロマ成分の両方に同一BDPCMの使用が可能か否か示す上位レベルでシグナルされるシンタックス要素に基づいてパースされてよい。例えば、前記同一BDPCMの使用可否を示すシンタックス要素がsps_intra_bdpcm_flagである場合、図28及び図29で説明したように、デコーダは、ルーマ成分に対するBDPCMが使用されるか否かを示すシンタックス要素をパースすることができる。すなわち、sps_bdpcm_enabled_flagの値が1である場合、デコーダは、intra_bdpcm_flagをパーシングでき(このとき、追加の条件が考慮されてよい。)、sps_bdpcm_enabled_flagの値が1でない場合、デコーダはintra_bdpcm_flagをパースしなくてよい。
【0393】
図38を参照すると、クロマ成分(chroma component)に対するBDPCMが使用されるか否かを示すシンタックス要素は、sps_bdpcm_enabled_flagの値によって行われてよい。例えば、sps_bdpcm_enabled_flagの値が1である場合、デコーダは、intra_bdpcm_chroma_flagをパースしてよく(このとき、追加の条件が考慮されてよい。)、sps_bdpcm_enabled_flagの値が1でない場合、デコーダはintra_bdpcm_chroma_flagをパースしなくてよい。
【0394】
コーディングユニット(ブロック)レベル(coding unit(block) level)におけるBDPCMが使用されるか否かを示すシンタックス要素は、ルーマ成分(luma component)とクロマ成分に対して分離していなくてよい。すなわち、BDPCMが使用されるか否かを示すシンタックス要素が、BDPCMが使用されることを示す場合、ルーマ成分とクロマ成分の両方に対してBDPCMは使用されてよい。一方、BDPCMが使用されるか否かを示すシンタックス要素が、BDPCMが使用されないことを示す場合、ルーマ成分とクロマ成分の両方に対してBDPCMは使用されなくてよい。
【0395】
図39は、本発明の実施例に係るイントラ予測に関連したシンタックスを示す図である。
【0396】
図39を参照すると、既に設定された順序によって、複数個のイントラ予測(intra prediction)に関連したシンタックス要素がシグナルされてよい。
【0397】
カラー成分(color component)別にシンタックス要素はグルーピングされ、シグナルされてよい。例えば、ルーマ成分(luma component)に関連したシンタックス要素がグルーピングしてシグナルされてよい。クロマ成分(chroma component)に関連したシンタックス要素がグルーピングしてシグナルされてよい。また、ルーマ成分に関連したシンタックス要素グループ(syntaxelement group)、クロマ成分に関連したシンタックス要素グループは順にシグナルされてよい。逆に、クロマ成分に関連したシンタックス要素グループ、ルーマ成分に関連したシンタックス要素グループが順にシグナルされてよい。
【0398】
図39を参照して、ルーマ成分(luma component)に関連したシンタックス要素グループ(syntaxelement group)とクロマ成分(chroma component)に関連したシンタックス要素グループが順にシグナルされる構造について説明する。
【0399】
ルーマ成分に関連したシンタックス要素グループは、次のシンタックス要素を含むことができる。
【0400】
i)ルーマ成分(luma component)に対するBDPCMに関連したシンタックス要素:
【0401】
BDPCMの使用可否を示すシンタックス要素と予測方向を示すシンタックス要素であってよい。例えば、図39に開示されたintra_bdpcm_luma_flag、intra_bdpcm_luma_dir_flagがそれに該当し得る。
【0402】
ii)MIP(matrix-based intra prediction)関連シンタックス要素:
【0403】
MIP予測の使用可否を示すシンタックス要素、MIP入力ベクトル(input vector)がトランスポーズ(transpose)されるか否かを示すシンタックス要素、MIPモードを示すシンタックス要素を意味する。例えば、図39に開示されたintra_mip_flag、intra_mip_transposed、intra_mip_modeがそれに該当し得る。
【0404】
iii)予測に用いられる参照ライン(reference line)を示すシンタックス要素:
【0405】
イントラ予測(intra prediction)に用いられる参照ラインの位置を示すシンタックス要素であってよい。例えば、図39に開示されたintra_luma_ref_idxがそれに該当し得る。
【0406】
iv)ISP(intra sub-partition)関連シンタックス要素:
【0407】
ISPの使用されるか否かを示すシンタックス要素、ISPスプリット(split)方向を示すシンタックス要素であってよい。例えば、図39に開示されたintra_subpartitions_mode_flag、intra_subpartitions_split_flagがそれに該当し得る。このとき、ISPは、イントラサブパーティションモード又はブロックをサブパーティションに分けて予測する方法である。
【0408】
v)イントラ予測モード(intra prediction mode)を示すシンタックス要素:
【0409】
MPMリスト(候補リスト(candidate list))の使用されるか否かを示すシンタックス要素、平面モード(planar mode)の使用されるか否かを示すシンタックス要素、MPMインデックスを示すシンタックス要素、MPMリストに含まれていないモードを示すシンタックス要素であってよい。例えば、図39に開示されたintra_luma_mpm_flag、intra_luma_not_planar_flag、intra_luma_mpm_idx、intra_luma_mpm_remainderがそれに該当し得る。
【0410】
クロマ成分(chroma component)に関連したシンタックス要素グループ(syntaxelement group)は、次のシンタックス要素を含むことができる。
【0411】
i)クロマ成分(chroma component)BDPCMに関連したシンタックス要素:
【0412】
BDPCMの使用されるか否かを示すシンタックス要素、予測方向を示すシンタックス要素であってよい。例えば、図39に開示されたintra_bdpcm_chroma_flag、intra_bdpcm_chroma_dir_flagがそれに該当し得る。
【0413】
ii)CCLM(cross component linear model)関連シンタックス要素:
【0414】
CCLMの使用されるか否かを示すシンタックス要素、予測に用いられるCCLMモードを示すシンタックス要素であってよい。例えば、図39に開示されたcclm_mode_flag、cclm_mode_idxがそれに該当し得る。CCLMは、別のカラー成分(color component)値に基づいて予測する方法であり、具体的に、ルーマ成分(luma component)値に基づいてクロマ成分(chroma component)を予測する方法であってよい。
【0415】
iii)クロマイントラ予測モード(chroma intra prediction mode)に関連したシンタックス要素:
【0416】
クロマ成分(chroma component)に対するイントラ予測モードインデックスを決定するために用いられるシンタックス要素であってよい。例えば、図39に開示されたintra_chroma_pred_modeがそれに該当し得る。
【0417】
図39を参照すると、ツリー類型(treeType)がSINGLE_TREEであるか、DUAL_TREE_LUMAである場合、デコーダは、ルーマ成分(luma component)に関連したシンタックス要素をパースし、ツリー類型がSINGLE_TREEであるか、DUAL_TREE_CHROMAである場合、デコーダは、クロマ成分(chroma component)に関連したシンタックス要素をパースすることができる。したがって、デコーダは、ルーマ成分に関連したシンタックス要素グループ(syntaxelement group)を連続してパースし、クロマ成分に関連したシンタックスグループを連続してパースすることができる。
【0418】
図39を参照すると、クロマ成分に関連したシンタックス要素であるintra_bdpcm_chroma_flag及びintra_bdpcm_chroma_dir_flagは、ルーマ成分に関連したシンタックス要素グループよりも後に位置してよい。したがって、ツリー類型がSINGLE_TREEである場合、ルーマ成分に関連したシンタックス要素グループ後に位置しているintra_bdpcm_chroma_flag及びintra_bdpcm_chroma_dir_flagなどがパースされてよい。
【0419】
これにより、ルーマ成分に関連したシンタックス要素とクロマ成分に関連したシンタックス要素がそれぞれ連続して位置(パーシング)するので、メモリ管理の側面で利点がある。すなわち、具現側面で有効であり得る。
【0420】
図40は、本発明の実施例に係るイントラ予測(intra prediction)に関連したシンタックスを示す図である。
【0421】
図39を参照すると、ルーマ成分(luma component)に関連したシンタックス要素グループ(syntaxelement group)とクロマ成分(chroma component)に関連したシンタックス要素グループは順にパースされなくてよい。例えば、図39を参照して説明したルーマ成分に関連したシンタックス要素グループとクロマ成分に関連したシンタックス要素グループのうち一部の順序が変わってパースされてよい。具体的に、ルーマ成分に対するBDPCMに関連したシンタックス要素とクロマ成分に対するBDPCMに関連したシンタックス要素は連続してパースされてよい。また、ルーマ成分に関連したシンタックス要素グループに含まれたシンタックス要素のうち、ルーマ成分に対するBDPCMに関連したシンタックス要素を除くシンタックス要素グループと、クロマ成分に関連したシンタックス要素グループに含まれたシンタックス要素のうち、クロマ成分に対するBDPCMに関連したシンタックス要素を除くシンタックス要素グループは、連続してパースされてよい。また、BDPCMに関連したシンタックス要素は他のシンタックス要素グループよりも前にパースされてよい。
【0422】
シンタックス要素がパースされる順序の一実施例は、次のようである。
【0423】
まず、ルーマ成分に対するBDPCMに関連したシンタックス要素がパースされ、クロマ成分に対するBDPCMに関連したシンタックス要素がパースされてよい。そして、ルーマ成分に関連したシンタックス要素グループに含まれたシンタックス要素のうち、ルーマ成分に対するBDPCMに関連したシンタックス要素を除くシンタックス要素グループがパースされてよい。そして、クロマ成分に関連したシンタックス要素グループに含まれたシンタックス要素のうち、クロマ成分に対するBDPCMに関連したシンタックス要素を除くシンタックス要素グループがパースされてよい。
【0424】
図40を参照すると、intra_bdpcm_luma_flag、intra_bdpcm_luma_dir_flag、intra_bdpcm_chroma_flag、intra_bdpcm_chroma_dir_flagは、intra_mip_flag、intra_mip_transposed、intra_mip_mode、intra_luma_ref_idx、intra_subpartitions_mode_flag、intra_subpartitions_split_flag、intra_luma_mpm_flag、intra_luma_not_planar_flag、intra_luma_mpm_idx、intra_luma_mpm_remainder、cclm_mode_flag、cclm_mode_idx、intra_chroma_pred_modeよりも先に位置してよい。
【0425】
または、intra_bdpcm_luma_flag、intra_bdpcm_luma_dir_flag、intra_bdpcm_chroma_flag、intra_bdpcm_chroma_dir_flagは、intra_mip_flag、intra_mip_transposed、intra_mip_mode、intra_luma_ref_idx、intra_subpartitions_mode_flag、intra_subpartitions_split_flag、intra_luma_mpm_flag、intra_luma_not_planar_flag、intra_luma_mpm_idx、intra_luma_mpm_remainder、cclm_mode_flag、cclm_mode_idx、intra_chroma_pred_modeの少なくともいずれか一つよりも先に位置してよい。
【0426】
図40を参照すると、クロマ成分(chroma component)に対するBDPCMに関連したシンタックス要素が、ルーマ成分(luma component)に関連したシンタックス要素よりも先に位置してよい。これにより、クロマBDPCMが多く使用される場合に、シンタックス要素をパースするか否かを決定する動作/演算が減るという効果がある。
【0427】
ルーマBDPCMとクロマBDPCMは、予測方向を共有してよい。したがって、図40に開示された通り、intra_bdpcm_luma_dir_flagとintra_bdpcm_chroma_dir_flagは別個に存在せず、一つのシンタックス要素によってルーマBDPCMの予測方向とクロマBDPCMの予測方向が指示されてよい。このとき、ルーマBDPCMの使用されるか否かとクロマBDPCMの使用されるか否かは、独立的でなくてよい。例えば、クロマBDPCMが使用されるためには、ルーマBDPCMが使用される必要がある。したがって、ルーマBDPCMの使用されるか否かを示すシンタックス要素とクロマBDPCMの使用されるか否かを示すシンタックス要素は、従属的(dependent)であってよい。ルーマBDPCMの使用されるか否かを示すシンタックス要素が、ルーマBDPCMが使用されることを示す場合にのみ、クロマBDPCMの使用されるか否かを示すシンタックス要素がパースされてよい。
【0428】
図41は、本発明の一実施例に係るシーケンスパラメータセットシンタックスを示す図である。
【0429】
シーケンスパラメータセット(sequence parameter set,SPS)シンタックスは、CVS(coded video sequence)に適用されるシンタックスであってよい。SPSシンタックスがCVSに適用されるか否かは、スライスヘッダー(slice header)のシンタックス要素によって参照されるPPS(picture parameter set)のシンタックス要素値によって決定されてよい。
【0430】
図41に開示されたシンタックス要素は、SPSシンタックス要素の一部であってよい。図41を参照すると、SPSシンタックスは、pic_width_max_in_luma_samples、pic_height_max_in_luma_samples、sps_log2_ctu_size_minus5、subpics_present_flag、sps_num_subpics_minus1、subpic_ctu_top_left_x、subpic_ctu_top_left_y、subpic_width_minus1、subpic_height_minus1、subpic_treated_as_pic_flag、loop_filter_across_subpic_enabled_flag、sps_subpic_id_present_flag、sps_subpic_id_signalling_present_flag、sps_subpic_id_len_minus1、sps_subpic_idなどのシンタックス要素を含むことができる。また、SPSシンタックスに含まれるシンタックス要素のうち一部は、サブピクチャーの個数だけ存在してよい。例えば、シンタックス要素subpic_ctu_top_left_x、subpic_ctu_top_left_y、subpic_width_minus1、subpic_height_minus1、subpic_treated_as_pic_flag、loop_filter_across_subpic_enabled_flag、sps_subpic_idは、サブピクチャーの個数だけ存在してよい。具体的に、このようなシンタックス要素は、syntaxElement[I]であり、iは、0から(サブピクチャーの個数-1)までと表されてよい。このとき、syntaxElementは、サブピクチャーの個数だけ存在するシンタックス要素であってよい。
【0431】
サブピクチャーは、ピクチャー又はフレームよりも下位単位であってよい。例えば、ピクチャー又はフレームは、一つ以上のサブピクチャーを含むことができる。このとき、サブピクチャーは、長方形区域(rectangular region)であってよい。具体的に、サブピクチャーは、ピクチャー内の一つ以上のスライスで構成される長方形区域を意味できる。また、サブピクチャーは、独立してデコードされてよい。したがって、ピクチャー内のあるサブピクチャーに関する情報のみをデコーダが受信しても、デコーダは、受信したあるサブピクチャーをデコードして復元することができる。また、ピクチャー内の複数のサブピクチャーは互いに重ならなくてよい。
【0432】
図41を参照すると、subpics_present_flagの値が1である場合、デコーダは、sps_num_subpics_minus1、subpic_ctu_top_left_x、subpic_ctu_top_left_y、subpic_width_minus1、subpic_height_minus1、subpic_treated_as_pic_flag、loop_filter_across_subpic_enabled_flagをパースすることができる。また、subpic_ctu_top_left_x、subpic_ctu_top_left_y、subpic_width_minus1、subpic_height_minus1、subpic_treated_as_pic_flag、loop_filter_across_subpic_enabled_flagは、それぞれ(sps_num_subpics_minus1+1)個だけパースされてよい。
【0433】
上述したSPSシンタックスのシンタックス要素とサブピクチャーシグナリング方法について、図42を用いて説明する。
【0434】
図42は、本発明の一実施例に係るサブピクチャーに関連したシンタックス要素を示す図である。
【0435】
図42に開示されたpic_width_max_in_luma_samplesは、ピクチャーの最大幅を示すシンタックス要素であり、このとき、ピクチャーの最大幅は、ルーマサンプル単位で示すことができる。pic_width_max_in_luma_samplesの値は0でなくてよく、既に設定された値の整数倍(integer multiple)の値であってよい。前記既に設定された値は、8と最小コーディングブロックサイズ(minimum coding block size)のうち、大きい値であってよい。このとき、最小コーディングブロックサイズは、ルーマサンプル基準で決定されてよく、MinCbSizeYと記述されてよい。
【0436】
また、pic_height_max_in_luma_samplesは、ピクチャーの最大高さを示すシンタックス要素であり、このとき、ピクチャーの最大高さは、ルーマサンプル単位で示すことができる。また、pic_height_max_in_luma_samplesの値は0でなくてよく、既に設定された値の整数倍(integer multiple)であってよい。前記既に設定された値は、8と最小コーディングブロックサイズ(minimum coding block size)のうち、大きい値であってよい。このとき、最小コーディングブロックサイズは、ルーマサンプル基準で決定されてよく、MinCbSizeYと記述されてよい。
【0437】
ピクチャーがサブピクチャーを使用する場合、pic_width_max_in_luma_samples、pic_height_max_in_luma_samplesは、それぞれ、ピクチャーの幅、高さを示す。このとき、ピクチャーの最大幅、最大高さはそれぞれ、ピクチャーの幅、ピクチャーの高さと同一であってよい。
【0438】
sps_log_2_ctu_size_minus5は、コーディングツリーユニット(coding tree unit,CTU)のコーディングツリーブロック(coding tree block,CTB)のサイズを示すシンタックス要素であってよい。具体的に、sps_log_2_ctu_size_minus5は、ルーマコーディングツリーブロックのサイズを示すことができる。また、sps_log_2_ctu_size_minus5は、ルーマサンプル単位のCTBサイズにlog2を取り、既に設定された値を引いた値を有してよい。ルーマコーディングツリーブロックのサイズをCtbSizeYとすれば、CtbSizeYは、(1<<(sps_log2_ctu_size_minus5+既に設定された値))であってよい。前記既に設定された値は、5であってよい。すなわち、sps_log2_ctu_size_minus5が0、1、2のとき、CtbSizeY値はそれぞれ、32、64、128であってよい。また、sps_log2_ctu_size_minus5値は、2以下の値であってよい。
【0439】
subpics_present_flagは、サブピクチャーパラメータが存在するか否かを示すシンタックス要素である。subpics_present_flagは、サブピクチャーを使用できるか否か、サブピクチャー個数を1よりも大きい値とシグナルできるか否かを示す。このとき、サブピクチャーパラメータは、sps_num_subpics_minus1、subpic_ctu_top_left_x、subpic_ctu_top_left_y、subpic_width_minus1、subpic_height_minus1、subpic_treated_as_pic_flag、loop_filter_across_subpic_enabled_flagなどを含むことができる。
【0440】
sps_num_subpics_minus1は、サブピクチャー個数を示すシンタックス要素であってよい。例えば、sps_num_subpics_minus1の値に既に設定された値を足した値が、サブピクチャーの個数であってよい。このとき、既に設定された値は、1であってよい。この場合、サブピクチャーの個数は、1以上の値とシグナルされてよい。また、既に設定された値は、2であってよい。この場合、サブピクチャーの個数は2以上の値でシグナルされてよい。sps_num_subpics_minus1値は、0以上254以下であり、8-bitで表現されてよい。一方、sps_num_subpics_minus1値が存在しない場合、sps_num_subpics_minus1の値は0と推論(infer)されてよい。
【0441】
図42に開示された、subpic_ctu_top_left_x、subpic_ctu_top_left_y、subpic_width_minus1、subpic_height_minus1は、各サブピクチャーの位置及びサイズを示すシンタックス要素である。subpic_ctu_top_left_x[i]、subpic_ctu_top_left_y[i]、subpic_width_minus1[i]、subpic_height_minus1[I]は、i番目のサブピクチャーに該当する値を示す。このとき、i値は、0以上sps_num_subpics_minus1の値以下であってよい。
【0442】
subpic_ctu_top_left_xは、サブピクチャーの左上端の位置のx座標(horizontal position)を示すことができる。具体的に、subpic_ctu_top_left_xは、サブピクチャーの左上端のCTUのx座標を示すことができる。このとき、座標は、CTU単位又はCTB単位で表されてよい。例えば、座標は、CtbSizeY単位で表すことができる。また、subpic_ctu_top_left_xは、符号なし整数(unsigned integer)の値でシグナルされてよく、このとき、ビット数は、Ceil(Log2(pic_width_max_in_luma_samples/CtbSizeY))であってよい。一方、subpic_ctu_top_left_xの値が存在しない場合、subpic_ctu_top_left_xの値は0と推論(infer)されてよい。
【0443】
subpic_ctu_top_left_yは、サブピクチャーの左上端の位置のy座標(vertical position)を示すことができる。具体的に、subpic_ctu_top_left_yは、サブピクチャーの左上端のCTUのy座標を示すことができる。このとき、座標は、CTU単位又はCTB単位で表されてよい。例えば座標は、CtbSizeY単位で表すことができる。また、subpic_ctu_top_left_yは、符号なし整数(unsigned integer)の値でシグナルされてよく、このとき、ビット数は、Ceil(Log2(pic_height_max_in_luma_samples/CtbSizeY))であってよい。一方、subpic_ctu_top_left_yの値が存在しない場合、subpic_ctu_top_left_yの値は0と推論(infer)されてよい。
【0444】
subpic_width_minus1は、サブピクチャーの幅を示すことができる。例えば、subpic_width_minus1の値に既に設定された値を足した値が、サブピクチャーの幅であってよい。このとき、既に設定された値は1であってよい。また、サブピクチャーの幅はCTU単位又はCTB単位で表されてよい。例えば、サブピクチャーの幅は、CtbSizeY単位で表すことができる。また、subpic_width_minus1は、符号なし整数(unsigned integer)の値でシグナルされてよく、このとき、ビット数は、Ceil(Log2(pic_width_max_in_luma_samples/CtbSizeY))であってよい。一方、subpic_width_minus1の値が存在しない場合、subpic_width_minus1の値は、(Ceil(pic_width_max_in_luma_samples/CtbSizeY)-1)と推論(infer)されてよい。
【0445】
subpic_height_minus1は、サブピクチャーの高さを示すことができる。例えば、subpic_height_minus1の値に既に設定された値を足した値が、サブピクチャーの高さであってよい。このとき、既に設定された値は、1であってよい。また、サブピクチャーの高さは、CTU単位又はCTB単位で表されてよい。例えば、サブピクチャーの高さは、CtbSizeY単位で表すことができる。また、subpic_height_minus1は、符号なし整数(unsigned integer)の値でシグナルされてよく、このとき、ビット数は、Ceil(Log2(pic_height_max_in_luma_samples/CtbSizeY))であってよい。一方、subpic_height_minus1値が存在しない場合、subpic_height_minus1の値は、(Ceil(pic_height_max_in_luma_samples/CtbSizeY)-1)と推論(infer)されてよい。
【0446】
本発明で説明するCeil(x)値は、xより大きいか同一である最小の整数(the smallest integer greater than or equal to x)であってよい。上述したビット数計算においてCeil(Log2(x))のような演算をしたが、これは、0以上の整数であるx値を2進法で表す時に必要なビット数を計算するためのものである。
【0447】
また、サブピクチャーの位置及びサイズが決定されることにより、サブピクチャー境界(subpicture boundary)位置が計算されてよい。これにより、サブピクチャーの内部に存在する位置が判断できる。
【0448】
図43は、本発明の一実施例に係る演算子を示す図である。
【0449】
図43を参照すると、複数の分割(division)演算が定義されてよい。
【0450】
“/”は、整数分割(integer division)を表すことができる。すなわち、“/”の結果値は、整数(integer)であってよい。具体的に、“/”演算の結果値を整数(integer)にさせる時、ゼロ(zero)方向に切断(truncation)するものであってよい。例えば、7/4と(-7)/(-4)の値は1である。また、(-7)/4と7/(-4)の値は-1である。図42で説明したビット数に対する演算又はビット数を推論(infer)する演算において、整数分割(integer division)が用いられてよい。
【0451】
“÷”は、切断(truncation)又は四捨五入(rounding)をしない分割(division)演算である。したがって、“÷”演算の結果値は、整数(integer)であっても、整数でなくてもよい。例えば、7÷4と(-7)÷(-4)の値は、1よりも大きい値であってよい。また、(-7)÷4と7÷(-4)の値は-1よりも小さい値であってよい。
【0452】
図43における
【数8】
の“-”演算は、上述した“÷”と同じ演算である。
【0453】
図44は、本発明の一実施例に係るピクチャーとサブピクチャーを示す図である。
【0454】
上述したように、ピクチャーは、複数個のサブピクチャーに分けられてよい。このとき、サブピクチャーがどのように分けられるか又はどのように構成されるかは、図42に開示されたシグナリングによればいい。ただし、図42及び図43で説明した実施例によれば、シグナリングで表現できない範囲が存在することがある。例えば、ピクチャーの幅がCtbSizeYで割り切れないか、又はピクチャーの高さがCtbSizeYで割り切れない時には表すことのできないサブピクチャーの構造があり得る。具体的に、ピクチャーの幅がCtbSizeYで割り切れない場合、pic_width_max_in_luma_samples/CtbSizeY値は、0の方に切断される(truncation)ので、ピクチャーの最右側CTBの位置は表現できない。また、ピクチャーの高さがCtbSizeYで割り切れない場合、pic_height_max_in_luma_samples/CtbSizeY値は0の方に切断される(truncation)ので、ピクチャーの最下側CTBの位置は表現できない。したがって、ピクチャーの幅がCtbSizeYで割り切れず、サブピクチャーの幅がピクチャーの幅と同一である場合、上述したシグナリングは、サブピクチャーの幅を表現できない。また、ピクチャーの幅がCtbSizeYで割れきれず、サブピクチャーの水平位置が最右側CTBである場合、上述したシグナリングは、サブピクチャーの左上端のx座標を表現できない。
【0455】
具体的に、図44を参照すると、ピクチャーの幅は、1032ルーマサンプルであってよい。また、CtbSizeYは、128であってよい。図44のSubpicture0のように、サブピクチャーの幅はピクチャーの幅と同一であってよい。このとき、Subpicture0の幅は、CtbSizeY単位で9であるので、subpic_width_minus1値は、8を表さなければならない。ただし、pic_width_max_in_luma_samples/CtbSizeY(1032/128)値が8であるため、Ceil(Log2(pic_width_max_in_luma_samples/CtbSizeY))値は3である。したがって、subpic_width_minus1は3ビットであって、0~7の値のみ表現でき、8は表現できないという問題がある。また、subpic_width_minus1の値が存在せず、推論(infer)される場合があり得る。このとき、ピクチャーが1個のサブピクチャーで構成されるかのように、サブピクチャーの幅はピクチャー幅と推論(infer)されるべきであるが、上述したように、ピクチャーの幅がCtbSizeYで割り切れない場合、サブピクチャー幅は推論(infer)できない。
【0456】
図44を参照すると、Subpicrue 2のように、サブピクチャーの左上端のx座標は、最右側のCTBであってよい。このとき、サブピクチャーの左上端のx座標は、CtbSizeY単位で9番目の値、座標が0から始まる場合は8の値を示さなければならない。ただし、pic_width_max_in_luma_samples/CtbSizeY値が8であるので、Ceil(Log2(pic_width_max_in_luma_samples/CtbSizeY))値は、3である。したがって、subpic_ctu_top_left_xの値は3ビットであって、0~7の値のみを表現でき、8は表現できないという問題がある。
【0457】
図45は、本発明の一実施例に係るサブピクチャーに関連したシンタックス要素を示す図である。
【0458】
図44で説明したように、pic_width_max_in_luma_samplesがCtbSizeYで割り切れない場合、pic_width_max_in_luma_samples/CtbSizeYが切断(切り捨て)(truncation(flooring))されながら表現範囲が減るという問題がある。同様に、pic_height_max_in_luma_samplesがCtbSizeYで割り切れない場合、pic_height_max_in_luma_samples/CtbSizeYが切断(切り捨て)(truncation(flooring))されながら表現範囲が減った。したがつて、本発明で切断(truncation)されない演算方法を提案する。
【0459】
例えば、サブピクチャーの左上端ののx座標、y座標、サブピクチャーの幅、サブピクチャーの高さは、CtbSizeY単位で表現されるので、CtbSizeYで割り切れなければならないが、このとき、図43で説明した“÷”演算が用いられてよい。
【0460】
subpic_ctu_top_left_xは、サブピクチャーの左上端の位置のx座標(horizontal position)を示すことができる。具体的に、subpic_ctu_top_left_xは、サブピクチャーの左上端のCTUのx座標を示すことができる。このとき、座標は、CTU単位又はCTB単位で表されてよい。例えば、CtbSizeY単位で表すことができる。subpic_ctu_top_left_xは、符号なし整数(unsigned integer)の値でシグナルされてよく、subpic_ctu_top_left_xのビット数は、Ceil(Log2(pic_width_max_in_luma_samples÷CtbSizeY))であってよい。一方、subpic_ctu_top_left_xの値が存在しない場合、subpic_ctu_top_left_xの値は0と推論(infer)されてよい。このとき、subpic_ctu_top_left_xのビット数は、Ceil(Log2(Ceil(pic_width_max_in_luma_samples÷CtbSizeY)))と決定されてよい。
【0461】
subpic_ctu_top_left_yは、サブピクチャーの左上端の位置のy座標(vertical position)を示すことができる。具体的に、subpic_ctu_top_left_yは、サブピクチャーの左上端のCTUのy座標を示すことができる。このとき、座標は、CTU単位又はCTB単位で表されてよい。例えば座標は、CtbSizeY単位で表すことができる。subpic_ctu_top_left_yは、符号なし整数(unsigned integer)の値でシグナルされてよく、subpic_ctu_top_left_yのビット数は、Ceil(Log2(pic_height_max_in_luma_samples÷CtbSizeY))であってよい。一方、subpic_ctu_top_left_yの値が存在しない場合、subpic_ctu_top_left_yの値は0と推論(infer)されてよい。このとき、subpic_ctu_top_left_yのビット数は、Ceil(Log2(Ceil(pic_height_max_in_luma_samples÷CtbSizeY)))と決定されてよい。
【0462】
subpic_width_minus1は、サブピクチャーの幅を示すことができる。例えば、subpic_width_minus1の値に既に設定された値を足した値が、サブピクチャーの幅を示すことができる。このとき、既に設定された値は、1であってよい。また、サブピクチャーの幅は、CTU単位又はCTB単位で表すことができる。例えば、サブピクチャーの幅は、CtbSizeY単位で表されてよい。subpic_width_minus1は、符号なし整数(unsigned integer)の値でシグナルされてよく、subpic_width_minus1のビット数は、Ceil(Log2(pic_width_max_in_luma_samples÷CtbSizeY))であってよい。一方、subpic_width_minus1の値が存在しない場合、subpic_width_minus1の値は、(Ceil(pic_width_max_in_luma_samples÷CtbSizeY)-1)と推論(infer)されてよい。このとき、subpic_width_minus1のビット数は、Ceil(Log2(Ceil(pic_width_max_in_luma_samples÷CtbSizeY)))と決定されてよい。
【0463】
subpic_height_minus1は、サブピクチャーの高さを示すことができる。例えば、subpic_height_minus1の値に既に設定された値を足した値が、サブピクチャーの高さを示すことができる。このとき、既に設定された値は、1であってよい。また、サブピクチャーの高さは、CTU単位又はCTB単位で表すことができる。例えば、サブピクチャーの高さは、CtbSizeY単位で表されてよい。subpic_height_minus1は、符号なし整数(unsigned integer)の値でシグナルされてよく、subpic_height_minus1のビット数は、Ceil(Log2(pic_height_max_in_luma_samples÷CtbSizeY))であってよい。一方、subpic_height_minus1の値が存在しない場合、subpic_height_minus1の値は、(Ceil(pic_height_max_in_luma_samples÷CtbSizeY)-1)と推論(infer)されてよい。このとき、subpic_height_minus1のビット数は、Ceil(Log2(Ceil(pic_height_max_in_luma_samples÷CtbSizeY)))と決定されてよい。
【0464】
図45に開示されたシンタックス要素を用いてサブピクチャーの位置及びサイズに対する表現範囲を拡張することができる。上述したように、シンタックス要素が存在せず、シンタックス要素の値が推論されるとき、ビット数の計算は、Ceil(Log2(Ceil(x)))のようになるが、これは、Log2(y)のyを整数のみとして取り込み可能な装置(デコーダ/エンコーダ)を具現する側面において有利である。上述した(pic_width_max_in_luma_samples÷CtbSizeY)と(pic_height_max_in_luma_samples÷CtbSizeY)の値はそれぞれ、ピクチャーの幅、ピクチャーの高さがいくつのCtbSizeY単位で構成されるかを示す。図45に開示されたシンタックス要素を使用する場合、図44に開示されたSubpicture 0の幅及びSubpicture 2のx座標は表現されてよい。
【0465】
図46は、本発明の一実施例に係る変換ブロックを分割する方法を示すフローチャートである。
【0466】
以下では、図1図45を用いて説明した一実施例に基づく、変換ブロックを分割する方法及び装置について説明する。
【0467】
ビデオ信号復号化装置は、変換ブロックを分割する方法を行うプロセッサを含むことができる。まず、ビデオ信号復号化装置は、変換ブロックに関する情報(例えば、シンタックス要素)を含むビットストリームを受信することができる。前記プロセッサは、既に設定された条件に基づき、現在変換ブロック(transform block,TB)の分割方向を示す結果値を決定することができる(S4601)。前記プロセッサは、前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割することができる(S4602)。前記プロセッサは、前記複数個の変換ブロックを用いてビデオ信号を復号化することができる(S4603)。
【0468】
また、ビデオ信号符号化装置は、既に設定された条件に基づき、現在変換ブロック(transform block,TB)の分割方向を示す結果値を決定し、前記結果値に基づき、前記現在変換ブロックを複数個の変換ブロックに分割し、前記複数個の変換ブロックに関する情報を含むビットストリーム(bitstream)を生成するプロセッサを含むことができる。
【0469】
このとき、前記既に設定された条件は、前記現在変換ブロックのカラー成分(color component)に関連した条件を含むことができる。
【0470】
このとき、前記既に設定された条件は、前記現在変換ブロックの幅と最大変換ブロック幅とを比較した結果に関連した条件をさらに含み、前記最大変換ブロック幅は、前記現在変換ブロックに関連したクロマフォーマット(chroma format)、前記現在変換ブロックのカラー成分及び最大変換サイズに基づいて決定されてよい。
【0471】
このとき、前記既に設定された条件は、前記現在変換ブロックの幅に第1値を掛けた値である第1幅値と、前記現在変換ブロックの高さに第2値を掛けた値である第1高さ値とを比較した結果に関連した条件をさらに含み、前記第1値及び前記第2値はそれぞれ、現在変換ブロックの幅及び現在変換ブロックの高さに関連した値であり、前記現在変換ブロックのカラー成分がルーマであれば、それぞれ1に設定され、クロマてあれば、前記現在変換ブロックに関連したクロマフォーマットに基づいてそれぞれ決定されてよい。
【0472】
前記現在変換ブロックの幅が前記最大変換ブロック幅よりも大きく、前記第1幅値が前記第1高さ値よりも大きい場合、前記結果値は、前記分割方向が垂直方向であることを示す値である1と決定されてよい。このとき、前記複数個の変換ブロックのそれぞれの幅は、前記変換ブロックの幅を2で割った値であり、前記複数個の変換ブロックのそれぞれの高さは、前記変換ブロックの高さと同じ値であってよい。
【0473】
前記現在変換ブロックの幅が前記最大変換ブロック幅以下であるか、又は前記第1幅値が前記第1高さ値以下である場合、前記結果値は、前記分割方向が水平方向であることを示す値である0と決定されてよい。このとき、前記複数個の変換ブロックのそれぞれの幅は、前記変換ブロックの幅と同じ値であり、前記複数個の変換ブロックのそれぞれの高さは、前記変換ブロックの高さを2で割った値であってよい。
【0474】
このとき、既に設定された条件は、上述した式2~式4で説明した条件であってよい。
【0475】
前記最大変換サイズは、前記現在変換ブロックに関連したコーディングツリーユニット(coding tree unit,CTU)に含まれるルーマ成分を有するコーディングツリーブロック(coding tree block,CTB)のサイズに基づいて決定されてよい。前記コーディングツリーブロックのサイズが32である場合、前記最大変換サイズは32であってよい。
【0476】
前記プロセッサは、前記現在変換ブロックのカラー成分がクロマてあれば、前記現在変換ブロックに関連したコーディングブロックの予測方法がBDPCM(Block-based Delta Pulse Code Modulation)であるか否かを示すシンタックス要素をパース(parsing)できる。その後、前記プロセッサは、前記パーシングの結果、前記コーディングブロックの予測方法がBDPCMでない場合、前記コーディングブロックの予測方法に関連したシンタックス要素をさらにパースし、前記パーシング結果に基づいて前記コーディングブロックの予測方法を決定できる。このとき、前記コーディングブロックの予測方法に関連したシンタックス要素は、CCLM(cross component linear model)、平面(planar)モード、DCモード、垂直モード、水平モード、対角モード、及びDMモードの少なくともいずれか一つを示すシンタックス要素であってよい。
【0477】
上述した本発明の実施例は多様な手段を介して具現される。例えば、本発明の実施例は、ハードウェア、ファームウェア(firmware)、ソフトフェアまたはそれらの組み合わせによって具現される。
【0478】
ハードウェアによる具現の場合、本発明の実施例による方法は、一つまたはそれ以上のASICs(Application Specific Integrated Circuits)、DSPs(Digital Signal Processors)、DSDPs(Digital Signal Processing Devices)、PDLs(Programmable Logic Devices)、FPGAs(Field Programmable Gate Arrays)、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどによって具現される。
【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