JP2023155275A - クロマ・イントラモードのベースとなるサイズ制約 - Google Patents
クロマ・イントラモードのベースとなるサイズ制約 Download PDFInfo
- Publication number
- JP2023155275A JP2023155275A JP2023130792A JP2023130792A JP2023155275A JP 2023155275 A JP2023155275 A JP 2023155275A JP 2023130792 A JP2023130792 A JP 2023130792A JP 2023130792 A JP2023130792 A JP 2023130792A JP 2023155275 A JP2023155275 A JP 2023155275A
- Authority
- JP
- Japan
- Prior art keywords
- chroma
- block
- video
- mode
- equal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000006243 chemical reaction Methods 0.000 claims abstract description 26
- 238000003672 processing method Methods 0.000 claims abstract description 7
- 238000000034 method Methods 0.000 claims description 228
- OSWPMRLSEDHDFF-UHFFFAOYSA-N methyl salicylate Chemical compound COC(=O)C1=CC=CC=C1O OSWPMRLSEDHDFF-UHFFFAOYSA-N 0.000 claims description 142
- 241000023320 Luma <angiosperm> Species 0.000 claims description 134
- 238000012545 processing Methods 0.000 claims description 47
- 230000009466 transformation Effects 0.000 claims description 43
- 230000015654 memory Effects 0.000 claims description 6
- 238000000638 solvent extraction Methods 0.000 description 47
- 230000008569 process Effects 0.000 description 37
- 230000011664 signaling Effects 0.000 description 25
- 239000013598 vector Substances 0.000 description 17
- 238000013139 quantization Methods 0.000 description 16
- 238000005192 partition Methods 0.000 description 14
- 230000009977 dual effect Effects 0.000 description 12
- 238000010586 diagram Methods 0.000 description 11
- 238000004590 computer program Methods 0.000 description 10
- 238000001914 filtration Methods 0.000 description 9
- 208000037170 Delayed Emergence from Anesthesia Diseases 0.000 description 8
- 229910003460 diamond Inorganic materials 0.000 description 7
- 239000010432 diamond Substances 0.000 description 7
- 230000003044 adaptive effect Effects 0.000 description 6
- 239000011449 brick Substances 0.000 description 6
- 238000009795 derivation Methods 0.000 description 6
- 238000013507 mapping Methods 0.000 description 6
- 238000000844 transformation Methods 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 5
- 238000004364 calculation method Methods 0.000 description 4
- 230000006835 compression Effects 0.000 description 4
- 238000007906 compression Methods 0.000 description 4
- 230000001419 dependent effect Effects 0.000 description 4
- 238000013461 design Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000011218 segmentation Effects 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 238000003780 insertion Methods 0.000 description 3
- 230000037431 insertion Effects 0.000 description 3
- 238000002156 mixing Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 230000009467 reduction Effects 0.000 description 3
- 238000012360 testing method Methods 0.000 description 3
- 101100129500 Caenorhabditis elegans max-2 gene Proteins 0.000 description 2
- 101100155952 Escherichia coli (strain K12) uvrD gene Proteins 0.000 description 2
- 230000004913 activation Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 238000000354 decomposition reaction Methods 0.000 description 2
- 230000006837 decompression Effects 0.000 description 2
- 238000006073 displacement reaction Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 230000002441 reversible effect Effects 0.000 description 2
- 238000013515 script Methods 0.000 description 2
- 238000000926 separation method Methods 0.000 description 2
- FZEIVUHEODGHML-UHFFFAOYSA-N 2-phenyl-3,6-dimethylmorpholine Chemical compound O1C(C)CNC(C)C1C1=CC=CC=C1 FZEIVUHEODGHML-UHFFFAOYSA-N 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 239000003086 colorant Substances 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000002401 inhibitory effect Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000013138 pruning Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 239000000758 substrate Substances 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
- H04N19/103—Selection of coding mode or of prediction mode
- H04N19/11—Selection of coding mode or of prediction mode among a plurality of spatial predictive coding modes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
- H04N19/119—Adaptive subdivision aspects, e.g. subdivision of a picture into rectangular or non-rectangular coding blocks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
- H04N19/132—Sampling, masking or truncation of coding units, e.g. adaptive resampling, frame skipping, frame interpolation or high-frequency transform coefficient masking
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
- H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
- H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
- H04N19/159—Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
- H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
- H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
- H04N19/186—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a colour or a chrominance component
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
- H04N19/593—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
- H04N19/96—Tree coding, e.g. quad-tree coding
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
Abstract
【課題】クロマ・イントラモードのベースとなるサイズ制約を提供する。【解決手段】ビデオ処理の方法が記載される。本方法は、ビデオのビデオ・ピクチャーのビデオ領域のクロマ・ブロックと、ビデオの符号化表現との間の変換を規則に従って実行することを含み、前記規則は、クロマ・ブロックがサイズM×Nを有するため、前記クロマ・ブロックは、イントラ符号化モードを用いて前記符号化表現において表現されることが許容されないことを規定し、MおよびNは、それぞれ、前記クロマ・ブロックの幅および高さを示す整数であり、前記イントラ符号化モードは、前記ビデオ・ピクチャーの前に符号化されたビデオ領域に基づいて前記クロマ・ブロックを符号化することを含む。【選択図】図１８
Description
関連出願への相互参照
本願は2020年9月21日に出願された国際特許出願第PCT/CN2020/116472号の国内移行である特願2022-517728の分割出願であり、同国際出願は、2019年9月21日に出願された国際特許出願第PCT/CN2019/107139号および2019年9月27日に出願された国際特許出願第PCT/CN2019/108760号の優先権および利益を適時に主張するために行われる。前述の諸出願の開示全体は、本出願の開示の一部として引用により援用される。
本願は2020年9月21日に出願された国際特許出願第PCT/CN2020/116472号の国内移行である特願2022-517728の分割出願であり、同国際出願は、2019年9月21日に出願された国際特許出願第PCT/CN2019/107139号および2019年9月27日に出願された国際特許出願第PCT/CN2019/108760号の優先権および利益を適時に主張するために行われる。前述の諸出願の開示全体は、本出願の開示の一部として引用により援用される。
技術分野
本文書は、ビデオおよび画像の符号化・復号化技術に関するものである。
本文書は、ビデオおよび画像の符号化・復号化技術に関するものである。
デジタル・ビデオは、インターネットおよびその他のデジタル通信ネットワークにおける最大の帯域幅使用を占める。ビデオを受信および表示できる接続されたユーザー装置の数が増加するにつれて、デジタル・ビデオの利用のための帯域幅需要は増加し続けることが予想される。
開示された技法は、ビデオ符号化または復号において参照画像が使用されるビデオまたは画像デコーダまたはエンコーダの実施形態によって使用されてもよい。
ある例示的側面では、ビデオ処理の方法が開示される。本方法は、ビデオのビデオ・ピクチャーのビデオ領域のクロマ・ブロックと、該ビデオの符号化表現との間の変換を規則に従って実行することを含む。前記規則は、前記クロマ・ブロックがサイズM×Nを有するため、前記クロマ・ブロックがイントラ符号化モードを用いて前記符号化表現において表現されることが許されないことを規定し、MおよびNはそれぞれ前記クロマ・ブロックの幅および高さを示す整数であり、前記イントラ符号化モードは、前記ビデオ・ピクチャーの前に符号化されたビデオ領域に基づいて前記クロマ・ブロックを符号化することを含む。
別の例示的側面では、ビデオ処理の別の方法が開示される。本方法は、ビデオのビデオ・ピクチャーのビデオ領域のクロマ・ブロックと、該ビデオの符号化表現との間の変換を規則に従って実行することを含む。前記規則は、サイズM×Nを有する前記クロマ・ブロックが、デュアルツリー分割が使用される場合に、イントラ符号化モードを使用して前記符号化表現において表現されることが許されないことを規定し、MおよびNはそれぞれ前記クロマ・ブロックの幅および高さを示す整数であり、前記イントラ符号化モードは、前記ビデオ・ピクチャーの前に符号化されたビデオ領域に基づいて前記クロマ・ブロックを符号化することを含む。
さらに別の例示的側面では、ビデオ処理の別の方法が開示される。本方法は、ビデオのビデオ・ピクチャーのビデオ領域のクロマ・ブロックと、該ビデオの符号化表現との間の変換を規則に従って実行することを含む。前記規則は、サイズM×Nを有する前記クロマ・ブロックが、シングルツリー分割が使用される場合に、イントラ符号化モードを使用して前記符号化表現において表現されることが許されないことを規定し、MおよびNはそれぞれ前記クロマ・ブロックの幅および高さを示す整数であり、前記イントラ符号化モードは、前記ビデオ・ピクチャーの前に符号化されたビデオ領域に基づいて前記クロマ・ブロックを符号化することを含む。
さらに別の例示的側面では、ビデオ処理の別の方法が開示される。本方法は、ビデオのビデオ領域のクロマ・ブロックと、該ビデオの符号化表現との間の変換を規則に従って実行することを含む。前記規則は、サイズM×Nを有する前記クロマ・ブロックが、インター予測とイントラ予測を組み合わせる複合インターおよびイントラ予測（CIIP）モードを使用して前記符号化表現において表現されることが許されないことを規定し、MおよびNはそれぞれ前記クロマ・ブロックの幅および高さを示す整数である。
さらに別の例示的側面では、ビデオ処理の別の方法が開示される。本方法は、ビデオのビデオ領域と該ビデオの符号化表現との間の変換を実行することを含み、前記規則は、前記ビデオ領域に適用可能な最大変換サイズが信号伝達されるかどうか、およびどのように信号伝達されるかが、前記符号化表現において前記ビデオ領域を表現するために使用される符号化モード・タイプに依存することを規定し、前記符号化モード・タイプは、（i）前記ビデオ領域に適用される量子化パラメータ（QP）が閾値よりも小さいほぼ無損失の符号化モード、（ii）前記ビデオ領域についての残差データの変換がバイパスされる無損失の符号化モード、または（iii）前記ビデオ領域についての残差データの変換がスキップされる、損失のある符号化モードである。
さらに別の例示的側面では、上述の方法は、プロセッサを備えるビデオ・エンコーダ装置によって実装されうる。
さらに別の例示的側面では、上述の方法は、プロセッサを備えるビデオ・デコーダ装置によって実装されうる。
さらに別の例示的側面では、これらの方法は、プロセッサ実行可能命令の形で具現され、コンピュータ読み取り可能プログラム媒体に記憶されてもよい。
これらおよびその他の側面は、本文書でさらに説明される。
本稿は、圧縮解除または復号されたデジタル・ビデオまたは画像の品質を改善するために、画像またはビデオ・ビットストリームのデコーダによって使用されうるさまざまな技法を提供する。簡潔のため、本明細書では、用語「ビデオ」は、ピクチャーのシーケンス（伝統的にビデオと呼ばれる）および個々の画像の両方を含むために使用される。さらに、ビデオ・エンコーダも、さらなるエンコードのために使用されるデコードされたフレームを再構成するために、エンコードのプロセス中にこれらの技法を実装しうる。
セクション見出しは、理解の容易のために本稿で使用されており、実施形態および技法を対応するセクションに限定するものではない。よって、あるセクションからの実施形態は、他のセクションからの実施形態と組み合わせることができる。
1. 概要
本稿は、ビデオ符号化技術に関するものである。具体的には、ビデオ符号化における基本色ベースの（base colors based）表現を用いたパレット符号化に関する。これは、HEVCのような既存のビデオ符号化標準、またはこれから最終化される標準（多用途ビデオ符号化）に適用されうる。これは、将来のビデオ符号化規格またはビデオ・コーデックにも適用可能でありうる。
2. 初期の議論
ビデオ符号化規格は、主に、周知のITU-TおよびISO/IEC規格の開発を通じて発展してきた。ITU-TはH.261とH.263を生み出し、ISO/IECはMPEG-1とMPEG-4 Visualを生み出し、両組織は合同して、H.262/MPEG-2 VideoとH.264/MPEG-4 Advanced Video Coding（AVC）とH.265/HEVC規格とを生み出した。H.262以来、ビデオ符号化規格は、時間的予測と変換符号化が利用されるハイブリッドビデオ符号化構造に基づいている。HEVCを越えた将来のビデオ符号化技術を探求するため、2015年にVCEGとMPEGが合同で合同ビデオ探査チーム（JVET）を設立した。それ以来、JVETによって多くの新しい方法が採用され、合同探査モデル（Joint Exploration Model、JEM）と名付けられた参照ソフトウェアに入れられた。2018年4月には、VCEG（Q6/16）とISO/IEC JTC1 SC29/WG11（MPEG）の間の合同ビデオエキスパートチーム（JVET）が発足し、HEVCに比べ50%のビットレート削減を目指すVVC規格に取り組んでいる。
2.1 イントラブロックコピー
HEVCスクリーンコンテンツ符号化拡張（HEVC Screen Content Coding extensions、HEVC‐SCC）および現在のVVCテストモデル（VTM-4.0）では、現在ピクチャー参照としても知られるイントラブロックコピー（IBC）が採用されている。IBCは、動き補償の概念をフレーム間符号化からフレーム内符号化に拡張した。図1に示されるように、IBCが適用されるとき、現在のブロックは、同じピクチャー内の参照ブロックによって予測される。参照ブロック内のサンプルは、現在のブロックが符号化または復号される前に、すでに再構成されていなければならない。IBCは、ほとんどのカメラ捕捉シーケンスについてそれほど効率的ではないが、スクリーンコンテンツについては顕著な符号化利得を示す。その理由は、スクリーンコンテンツピクチャーにはアイコンやテキスト文字などの反復パターンが多数存在することである。IBCは、これらの反復パターン間の冗長性を効果的に除去することができる。HEVC-SCCでは、インター符号化される符号化単位（CU）は、現在のピクチャーをその参照ピクチャーとして選択する場合、IBCを適用することができる。この場合、MVはブロックベクトル（BV）に名称変更され、BVは常に整数ピクセル精度をもつ。メインプロファイルHEVCとの互換性を保つために、現在のピクチャーは、デコードピクチャーバッファ（DPB）において「長期」参照ピクチャーとしてマークされる。同様に、マルチビュー／3Dビデオ符号化標準においては、ビュー間参照ピクチャーも「長期」参照ピクチャーとしてマークされることに注意すべきである。
BVをたどって参照ブロックを見つけた後、参照ブロックをコピーすることにより予測が生成できる。残差は、もとの信号から参照ピクセルを減算することによって得られる。その後、変換および量子化は、他の符号化モードと同様に適用できる。
図1は、イントラブロックコピーの図解である。
しかしながら、参照ブロックがピクチャーの外側にある、または現在のブロックと重複する、または再構成された領域の外側にある、またはいくつかの制約条件によって制約されている有効領域の外側にある場合、一部または全部のピクセル値が定義されない。そのような問題に対処するためには、基本的に2つの解決策がある。1つは、たとえばビットストリーム適合性において、そのような状況を許容しないことである。もう1つは、それら未定義のピクセル値についてパディングを適用することである。以下のサブセッションは、これらの解決策を詳細に説明する。
2.2 HEVCスクリーンコンテンツ符号化拡張におけるIBC
HEVCのスクリーンコンテンツ符号化拡張において、ブロックが現在のピクチャーを参照として使用する場合、次の仕様テキストに示されるように、参照ブロック全体が利用可能な再構成領域内にあることを保証すべきである。
HEVCのスクリーンコンテンツ符号化拡張において、ブロックが現在のピクチャーを参照として使用する場合、次の仕様テキストに示されるように、参照ブロック全体が利用可能な再構成領域内にあることを保証すべきである。
このように、参照ブロックが現在のブロックと重複する、または参照ブロックがピクチャーの外側にある場合は発生しない。参照ブロックや予測ブロックをパディングする必要はない。
2.3 VVCテストモデルにおけるIBC
現在のVVCテストモデル、すなわち、VTM-4.0設計では、参照ブロック全体が現在の符号化ツリー単位（CTU）と一緒であるべきであり、現在ブロックと重複しない。よって、参照ブロックまたは予測ブロックをパディングする必要はない。IBCフラグは、現在のCUの予測モードとして符号化される。よって、各CUについて、全部で3つの予測モード、MODE_INTRA、MODE_INTER、MODE_IBCがある。
現在のVVCテストモデル、すなわち、VTM-4.0設計では、参照ブロック全体が現在の符号化ツリー単位（CTU）と一緒であるべきであり、現在ブロックと重複しない。よって、参照ブロックまたは予測ブロックをパディングする必要はない。IBCフラグは、現在のCUの予測モードとして符号化される。よって、各CUについて、全部で3つの予測モード、MODE_INTRA、MODE_INTER、MODE_IBCがある。
2.3.1 IBCマージ・モード
IBCマージ・モードでは、IBCマージ候補リスト内のエントリーを指すインデックスがビットストリームからパースされる。IBCマージ・リストの構築は、以下の一連のステップに従って要約できる：
・ステップ1；空間的候補の導出
・ステップ2：HMVP候補の挿入
・ステップ3：ペアワイズ平均候補の挿入。
IBCマージ・モードでは、IBCマージ候補リスト内のエントリーを指すインデックスがビットストリームからパースされる。IBCマージ・リストの構築は、以下の一連のステップに従って要約できる：
・ステップ1；空間的候補の導出
・ステップ2：HMVP候補の挿入
・ステップ3：ペアワイズ平均候補の挿入。
空間的マージ候補の導出では、図19に示される位置に位置する候補の中から最大4つのマージ候補が選択される。導出の順序はA1、B1、B0、A0、B2である。位置B2は、位置A1、B1、B0、A0のいずれかのPUが利用可能でない（たとえば、別のスライスまたはタイルに属するため）、またはIBCモードで符号化されていない場合にのみ考慮される。位置A1の候補が追加された後、残りの候補の挿入は、同じ動き情報をもつ候補がリストから除外されることを確実にする冗長性チェックにかけられ、符号化効率が改善される。計算複雑性を低減するために、前述の冗長性チェックでは、可能な候補ペアのすべてが考慮されるわけではない。その代わりに、図20の矢印でリンクされたペアのみが考慮され、冗長性チェックに使用される対応する候補が同じ動き情報をもたない場合にのみ、候補がリストに追加される。
空間的候補の挿入後、IBCマージ・リストのサイズが最大IBCマージ・リスト・サイズよりもまだ小さい場合、HMVPテーブルからのIBC候補が挿入されてもよい。HMVP候補を挿入する際に、冗長性チェックが実行される。
最後に、ペアワイズ平均候補がIBCマージ・リストに挿入される。
マージ候補によって同定される参照ブロックが、ピクチャーの外側にある、または現在ブロックと重複している、または再構成された領域の外側にある、または何らかの制約条件によって制約されている有効な領域の外側にある場合、マージ候補は、無効なマージ候補と呼ばれる。
無効なマージ候補がIBCマージ・リストに挿入される可能性があることに注意されたい。
2.3.2 IBC AMVPモード
IBC AMVPモードでは、IBC AMVPリスト内のエントリーを指すAMVPインデックスがビットストリームからパースされる。IBC AMVPリストの構築は、以下の一連のステップに従って要約できる：
・ステップ1：空間的候補の導出
○利用可能な候補が見つかるまで、A0、A1をチェックする。
○利用可能な候補が見つかるまで、B0、B1、B2をチェックする。
・ステップ2：HMVP候補の挿入
・ステップ3：ゼロ候補の挿入。
IBC AMVPモードでは、IBC AMVPリスト内のエントリーを指すAMVPインデックスがビットストリームからパースされる。IBC AMVPリストの構築は、以下の一連のステップに従って要約できる：
・ステップ1：空間的候補の導出
○利用可能な候補が見つかるまで、A0、A1をチェックする。
○利用可能な候補が見つかるまで、B0、B1、B2をチェックする。
・ステップ2：HMVP候補の挿入
・ステップ3：ゼロ候補の挿入。
空間的候補の挿入後、IBC AMVPリスト・サイズが最大IBC AMVPリスト・サイズよりもまだ小さい場合、HMVPテーブルからのIBC候補が挿入されてもよい。
最後に、ゼロ候補がIBC AMVPリストに挿入される。
2.4 パレット・モード
パレット・モードの背後にある基本的な発想は、CU内のピクセルが代表的な色値の小さな集合によって表現されるということである。この集合はパレットと呼ばれる。エスケープ・シンボルおよびそれに続く（可能性としては量子化された）成分値を信号伝達することによって、パレットの外側にあるサンプルを示すことも可能である。この種のサンプルはエスケープ・サンプルと呼ばれる。パレット・モードは図2に示されている。
パレット・モードの背後にある基本的な発想は、CU内のピクセルが代表的な色値の小さな集合によって表現されるということである。この集合はパレットと呼ばれる。エスケープ・シンボルおよびそれに続く（可能性としては量子化された）成分値を信号伝達することによって、パレットの外側にあるサンプルを示すことも可能である。この種のサンプルはエスケープ・サンプルと呼ばれる。パレット・モードは図2に示されている。
図2は、パレット・モードで符号化されたブロックの例を示す。
2.5 HEVCスクリーンコンテンツ符号化拡張（HEVC-SCC）におけるパレット・モード
HEVC-SCCにおけるパレット・モードでは、パレットとインデックス・マップを符号化するために予測的な方法が使用される。
HEVC-SCCにおけるパレット・モードでは、パレットとインデックス・マップを符号化するために予測的な方法が使用される。
2.5.1 パレット項目の符号化
パレット項目の符号化のために、パレット予測子が維持される。パレットの最大サイズとパレット予測子は、SPSにおいて信号伝達される。HEVC-SCCでは、palette_predictor_initializer_present_flagがPPSにおいて導入される。このフラグが1である場合、パレット予測子を初期化するための項目が、ビットストリームにおいて信号伝達される。パレット予測子は、各CTU行、各スライスおよび各タイルの先頭において初期化される。palette_predictor_initializer_present_flagの値に依存して、パレット予測子は0にリセットされるか、PPSにおいて信号伝達されたパレット予測子初期化子項目（palette predictor initializer entries）を使用して初期化される。HEVC-SCCでは、サイズ0のパレット予測子初期化子により、PPSレベルでパレット予測子初期化の明示的な無効化を許容することができるようにされた。
パレット項目の符号化のために、パレット予測子が維持される。パレットの最大サイズとパレット予測子は、SPSにおいて信号伝達される。HEVC-SCCでは、palette_predictor_initializer_present_flagがPPSにおいて導入される。このフラグが1である場合、パレット予測子を初期化するための項目が、ビットストリームにおいて信号伝達される。パレット予測子は、各CTU行、各スライスおよび各タイルの先頭において初期化される。palette_predictor_initializer_present_flagの値に依存して、パレット予測子は0にリセットされるか、PPSにおいて信号伝達されたパレット予測子初期化子項目（palette predictor initializer entries）を使用して初期化される。HEVC-SCCでは、サイズ0のパレット予測子初期化子により、PPSレベルでパレット予測子初期化の明示的な無効化を許容することができるようにされた。
パレット予測子における各項目について、再利用フラグは、それが現在のパレットの一部であるかどうかを示すために信号伝達される。これは図3に示される。再利用フラグは、ゼロのランレングス符号化を使用して送信される。その後、新しいパレット項目の数が、次数0の指数ゴロム（exponential Golomb）符号を使用して信号伝達される。最後に、新しいパレット項目のための成分値が信号伝達される。
図3は、パレット項目を信号伝達するためのパレット予測器の使用の例を示す。
2.5.2 パレット・インデックスの符号化
パレット・インデックスは、図4に示されるように水平および垂直横断走査を用いて符号化される。走査順序は、palette_transpose_flagを使用してビットストリームにおいて明示的に信号伝達される。サブセクションの残りについては、走査は水平であると想定される。
パレット・インデックスは、図4に示されるように水平および垂直横断走査を用いて符号化される。走査順序は、palette_transpose_flagを使用してビットストリームにおいて明示的に信号伝達される。サブセクションの残りについては、走査は水平であると想定される。
図4は、水平および垂直横断走査の例を示す。
パレット・インデックスは、'INDEX'〔インデックス〕と'COPY_ABOVE'〔上をコピー〕という2つの主なパレット・サンプル・モードを使用して符号化される。先に説明したように、エスケープ・シンボルも'INDEX'モードとして信号伝達され、最大パレット・サイズに等しいインデックスを割り当てられる。該モードは、一番上の行または前のモードが'COPY_ABOVE'であったときを除いて、フラグを使用して信号伝達される。'COPY_ABOVE'モードでは、上の行のサンプルのパレット・インデックスがコピーされる。'INDEX'モードでは、パレット・インデックスは明示的に信号伝達される。'INDEX'モードと'COPY_ABOVE'モードの両方について、やはり同じモードで符号化される後続のサンプルの数を指定するラン値が信号伝達される。エスケープ・シンボルが'INDEX'または'COPY_ABOVE'モードのランの一部である場合、エスケープ成分値は各エスケープ・シンボルについて信号伝達される。パレット・インデックスの符号化は図5に示される。
この構文順序（syntax order）は、次のように達成される。まず、CUについてのインデックス値の数が信号伝達される。これに続いて、打ち切りされたバイナリ符号化を使用して、CU全体についての実際のインデックス値が信号伝達される。インデックスの数とインデックス値の両方がバイパス・モードで符号化される。これは、インデックスに関連したバイパス・ビンをグループ化する。次いで、パレット・サンプル・モード（必要な場合）およびランが、インターリーブされた仕方で信号伝達される。最後に、CU全体についての諸エスケープ・サンプルに対応する成分エスケープ値が一緒にグループ化され、バイパス・モードで符号化される。
追加的な構文要素last_run_type_flagが、インデックス値を信号伝達した後に信号伝達される。この構文要素は、インデックスの数とともに、ブロックにおける最後のランに対応するラン値を信号伝達する必要をなくす。
HEVC-SCCでは、パレット・モードは4:2:2、4:2:0、およびモノクロ・クロマ・フォーマットについても有効にされる。パレット項目とパレット・インデックスの信号伝達は、すべてのクロマ・フォーマットについてほぼ同一である。非モノクロ・フォーマットの場合、各パレット項目は3つの成分で構成される。モノクロ・フォーマットの場合、各パレット項目は単一の成分で構成される。サブサンプリングされたクロマ方向については、クロマ・サンプルは2で割れるルーマ・サンプル・インデックスと関連付けられる。CUのためのパレット・インデックスを再構成した後、サンプルが、それに関連する単一の成分をもつだけである場合、パレット項目の最初の成分のみが使用される。信号伝達における唯一の違いは、エスケープ成分値についてである。各エスケープ・サンプルについて、信号伝達されるエスケープ成分値の数は、そのサンプルに関連する成分の数に依存して異なる可能性がある。各エスケープ・サンプルについて、信号伝達されるエスケープ成分値の数は、そのサンプルに関連する成分の数に依存して異なることがある。
VVCでは、デュアルツリー符号化構造がイントラスライスの符号化に使用されるため、ルーマ成分と2つのクロマ成分は、異なるパレットおよびパレット・インデックスをもつことがある。さらに、2つのクロマ成分は、同じパレットおよびパレット・インデックスを共有する。
図5は、パレット・インデックスの符号化の例を示す。
2.6 VVCにおけるイントラモード符号化
自然なビデオで提示された任意のエッジ方向を捕捉するために、VTM5における方向性イントラモードの数は、HEVCで使用される33から65に拡張される。HEVCにない新しい方向性モードは、図6において赤い点線の矢印として示されており、平面モードとDCモードは同じままである。これらのより高密度の方向性イントラ予測モードは、すべてのブロック・サイズならびにルーマおよびクロマ・イントラ予測の両方に適用される。
自然なビデオで提示された任意のエッジ方向を捕捉するために、VTM5における方向性イントラモードの数は、HEVCで使用される33から65に拡張される。HEVCにない新しい方向性モードは、図6において赤い点線の矢印として示されており、平面モードとDCモードは同じままである。これらのより高密度の方向性イントラ予測モードは、すべてのブロック・サイズならびにルーマおよびクロマ・イントラ予測の両方に適用される。
VTM5では、いくつかの従来の角度性イントラ予測モードは、非正方形ブロックについての広角イントラ予測モードで適応的に置き換えられる。
HEVCでは、各イントラ符号化ブロックは正方形の形状を有し、その各辺の長さは2の冪乗である。よって、DCモードを使用してイントラ予測子を生成するために除算演算は必要とされない。VTM5では、ブロックは、一般的な場合、ブロックごとの除算演算の使用を必要とする長方形形状を有することができる。DC予測のための除算演算を回避するために、長辺のみが非正方形ブロックについての平均を計算するために使用される。
図6は、67個のイントラ予測モードの例を示す。
最確モード（most probable mode、MPM）リスト生成の複雑さを低く保つために、6つのMPMをもつイントラモード符号化方法が、2つの利用可能な近傍イントラモードを考慮することによって使用される。MPMリストを構築するには、以下の3つの側面が考えられる：
・デフォルト・イントラモード
・近傍イントラモード
・派生イントラモード。
・デフォルト・イントラモード
・近傍イントラモード
・派生イントラモード。
統合された6-MPMリストは、MRLおよびISP符号化ツールが適用されるか否かにかかわらず、イントラブロックについて使用される。MPMリストは、左および上の近傍ブロックのイントラモードに基づいて構築される。左ブロックのモードがLeftと記され、上のブロックのモードがAboveと記されるとすると、統合されたMPMリストは以下のようになる（左および上のブロックは図7に示されている）。
図7は、現在のブロックの左および上の近傍の例である。
・近傍ブロックが利用可能でない場合は、そのイントラモードは、デフォルトで平面に設定される。
・モードLeftとAboveの両方が非角度性モードである場合：
○MPMリスト→{平面,DC,V,H,V-4,V+4}
・モードLeftとAboveの一方が角度性モードで、他方が非角度性である場合：
○モードMaxを、LeftおよびAboveにおける大きなほうのモードに設定
○MPMリスト→{平面,Max,DC,Max－1,Max＋1,Max－2}
・LeftとAboveが両方とも角度性であり、異なる場合：
○モードMaxをLeftおよびAboveにおける大きなほうのモードに設定
○モードLeftとAboveの差が2ないし62の範囲内（両端含む）である場合：
・MPMリスト→{平面,Left,Above,DC,Max－1,Max＋1}
○それ以外の場合：
・MPMリスト→{平面,Left,Above,DC,Max－2,Max＋2}
・LeftとAboveが両方とも角度性であり、同じである場合：
○MPMリスト→{平面,Left,Left－1,Left＋1,DC,Left－2}
・近傍ブロックが利用可能でない場合は、そのイントラモードは、デフォルトで平面に設定される。
・モードLeftとAboveの両方が非角度性モードである場合：
○MPMリスト→{平面,DC,V,H,V-4,V+4}
・モードLeftとAboveの一方が角度性モードで、他方が非角度性である場合：
○モードMaxを、LeftおよびAboveにおける大きなほうのモードに設定
○MPMリスト→{平面,Max,DC,Max－1,Max＋1,Max－2}
・LeftとAboveが両方とも角度性であり、異なる場合：
○モードMaxをLeftおよびAboveにおける大きなほうのモードに設定
○モードLeftとAboveの差が2ないし62の範囲内（両端含む）である場合：
・MPMリスト→{平面,Left,Above,DC,Max－1,Max＋1}
○それ以外の場合：
・MPMリスト→{平面,Left,Above,DC,Max－2,Max＋2}
・LeftとAboveが両方とも角度性であり、同じである場合：
○MPMリスト→{平面,Left,Left－1,Left＋1,DC,Left－2}
さらに、mpmインデックス符号語の最初のビンは、CABACコンテキスト符号化される。現在のイントラブロックがMRL有効か、ISP有効か、通常のイントラブロックかに対応する、合計3つのコンテキストが使用される。
6MPMリスト生成プロセスの間、重複したモードを除去するために、プルーニング〔剪定〕が使用される。それにより、MPMリストには一意的なモードのみが含まれることができる。61個の非MPMモードのエントロピー符号化のためには、打ち切りされたバイナリ符号（Truncated Binary Code、TBC）が使用される。
クロマ・イントラモード符号化については、クロマ・イントラモード符号化のために合計8つのイントラモードが許される。それらのモードは、5つの伝統的なイントラモードと、3つの交差成分線形モデル・モード（cross-component linear model modes）（CCLM, LM_A, LM_L）を含む。クロマ・モード信号伝達および導出プロセスがテーブル2-に示される。クロマ・モード符号化は対応する、ルーマ・ブロックのイントラ予測モードに直接依存する。Iスライスではルーマ成分とクロマ成分についての別個のブロック分割構造が別々に有効にされているため、1つのクロマ・ブロックが複数のルーマ・ブロックに対応することがある。よって、クロマDMモードについては、現在のクロマ・ブロックの中心位置をカバーする対応するルーマ・ブロックのイントラ予測モードが直接継承される。
2.7 量子化残差ブロック差分パルス符号変調（QR-BDPCM）
JVET-N0413では、量子化残差ブロック差分パルス符号変調（quantized residual block differential pulse-code modulation、QR-BDPCM）が、スクリーンコンテンツを効率的に符号化するために提案されている。
JVET-N0413では、量子化残差ブロック差分パルス符号変調（quantized residual block differential pulse-code modulation、QR-BDPCM）が、スクリーンコンテンツを効率的に符号化するために提案されている。
QR-BDPCMにおいて使用される予測方向は、垂直および水平予測モードでありうる。イントラ予測は、ブロック全体に対して、イントラ予測と同様に予測方向（水平または垂直予測）におけるサンプル・コピーにより行われる。残差は量子化され、量子化された残差とその予測子（水平または垂直）量子化値との間のデルタが符号化される。これは、下記によって導出される：サイズM（行）×N（列）のブロックについて、サイズM（行）×N（列）のブロックについて、0≦i≦M－1、0≦j≦N－1としてri,jが、上または左のブロック境界サンプルからのフィルタリングされていないサンプルを用いて、イントラ予測を水平方向（予測されるブロックを通じてラインごとに左近傍ピクセル値をコピー）または垂直方向（予測されるブロックにおいて各ラインに上の近傍ラインをコピー）で実行した後の予測残差であるとする。0≦i≦M－1、0≦j≦N－1としてQ(ri,j)が、残差ri,jの量子化されたバージョンを表すとする。残差は、もとのブロックと予測されたブロックの値の差である。すると、ブロックDPCMは、量子化された残差サンプルに適用され、結果として、要素
をもつ修正されたM×N配列
を与える。垂直BDPCMが信号伝達される場合：
水平方向の予測については、同様の規則が適用され、残差量子化サンプルは次式によって得られる。
残差量子化サンプル
がデコーダに送られる。
デコーダ側では、上記の計算が逆にされて、Q(ri,j)、0≦i≦M－1、0≦j≦N－1を生成する。垂直予測の場合は、
水平の場合は、
逆量子化された残差Q-1(Q(ri,j))がイントラブロック予測値に加算されて、再構成されたサンプル値を生成する。
この方式の主な利点は、逆DPCMが、単に係数がパースされるにつれて予測子を加えることで係数パースの間にオンザフライで実行でき、またはパース後に実行できるということである。
2.8 適応ループ・フィルタ
VTM5では、ブロックベースのフィルタ適応のある適応ループ・フィルタ（Adaptive Loop Filter、ALF）が適用される。ルーマ成分については、ローカル勾配の方向と活性〔アクティビティ〕に基づいて、4×4ブロックごとに25のフィルタのうちの1つが選択される。
VTM5では、ブロックベースのフィルタ適応のある適応ループ・フィルタ（Adaptive Loop Filter、ALF）が適用される。ルーマ成分については、ローカル勾配の方向と活性〔アクティビティ〕に基づいて、4×4ブロックごとに25のフィルタのうちの1つが選択される。
2.8.1.1 フィルタ形状
VTM5では、（図8に示されるように）2つのダイヤモンドフィルタ形状が使用される。ルーマ成分について7×7のダイヤモンド形状が適用され、クロマ成分については5×5のダイヤモンド形状が適用される。
VTM5では、（図8に示されるように）2つのダイヤモンドフィルタ形状が使用される。ルーマ成分について7×7のダイヤモンド形状が適用され、クロマ成分については5×5のダイヤモンド形状が適用される。
図8は、ALFフィルタ形状の例（クロマ：5×5ダイヤモンド、ルーマ7×7ダイヤモンド）を示す。
2.8.1.2 ブロック分類
ルーマ成分については、各ブロックは25のクラスのうちの1つに分類される。分類インデックスCは、その方向性Dと、活性（activity）の量子化値
〔＾Aとも記す〕とに基づいて、次のように導出される：
ルーマ成分については、各ブロックは25のクラスのうちの1つに分類される。分類インデックスCは、その方向性Dと、活性（activity）の量子化値
Dおよび＾Aを計算するために、まず、1-Dラプラシアンを用いて、水平方向、垂直方向、および2つの対角方向の勾配が計算される：
インデックスiおよびjは、4×4ブロック内の左上のサンプルの座標を指し、R(i,j)は座標(i,j)における再構成されたサンプルを示す。
ブロック分類の複雑さを低減するために、サブサンプリングされた1-Dラプラシアン計算が適用される。図9に示されるように、全方向の勾配計算のために、同じサブサンプリングされる位置が使用される。
図9は、サブサンプリングされたラプラシアン計算の例を示す。（a）垂直勾配についてのサブサンプリングされる位置（b）水平勾配についてのサブサンプリングされる位置（c）斜め勾配についてのサブサンプリングされる位置（d）斜め勾配についてのサブサンプリングされる位置。
次いで、水平方向と垂直方向の勾配のD最大および最小値が
として設定される。
2つの対角方向の勾配の最大および最小値は
として設定される。
方向性の値Dを導出するために、これらの値は互いと、また2つの閾値t1およびt2と比較される：
活性値Aは次のように計算される：
Aはさらに0から4の範囲（両端含む）に量子化され、量子化された値は
と表される。
ピクチャー内のクロマ成分については、分類方法は適用されない。すなわち、ALF係数の単一の集合が各クロマ成分に適用される。
2.8.1.3 フィルタ係数の幾何学的変換およびクリッピング値
それぞれの4×4ブロックをフィルタリングする前に、回転または対角方向および垂直方向の反転のような幾何学的変換が、そのブロックについて計算された勾配値に依存して、フィルタ係数f(k,l)および対応するフィルタクリッピング値c(k,l)に適用される。これは、フィルタ・サポート領域内のサンプルにこれらの変換を適用することと等価である。発想は、ALFが適用される異なるブロックを、それらの方向性を整列させることによって、より類似させることである。
それぞれの4×4ブロックをフィルタリングする前に、回転または対角方向および垂直方向の反転のような幾何学的変換が、そのブロックについて計算された勾配値に依存して、フィルタ係数f(k,l)および対応するフィルタクリッピング値c(k,l)に適用される。これは、フィルタ・サポート領域内のサンプルにこれらの変換を適用することと等価である。発想は、ALFが適用される異なるブロックを、それらの方向性を整列させることによって、より類似させることである。
対角方向、垂直方向反転、回転を含む3つの幾何学的変換が導入される：
ここで、Kはフィルタのサイズであり、0≦k,l≦K－1は、位置(0,0)が左上隅に、位置(K－1,K－1)が右下隅になるような係数座標である。変換は、そのブロックについて計算された勾配値に依存してフィルタ係数f(k,l)およびクリッピング値c(k,l)に適用される。変換と4方向の4つの勾配との関係が次のテーブルにまとめられている。
2.8.1.4 フィルタ・パラメータ信号伝達
VTM5では、ALFフィルタ・パラメータは適応パラメータセット（APS）において信号伝達される。1つのAPSでは、ルーマ・フィルタ係数およびクリッピング値インデックスの25個までの集合と、クロマ・フィルタ係数およびクリッピング値インデックスの1つまでの集合とが信号伝達されることができる。ビット・オーバーヘッドを減らすために、異なる分類のフィルタ係数がマージされることができる。スライスヘッダでは、現在のスライスに使用されているAPSのインデックスが信号伝達される。
VTM5では、ALFフィルタ・パラメータは適応パラメータセット（APS）において信号伝達される。1つのAPSでは、ルーマ・フィルタ係数およびクリッピング値インデックスの25個までの集合と、クロマ・フィルタ係数およびクリッピング値インデックスの1つまでの集合とが信号伝達されることができる。ビット・オーバーヘッドを減らすために、異なる分類のフィルタ係数がマージされることができる。スライスヘッダでは、現在のスライスに使用されているAPSのインデックスが信号伝達される。
APSからデコードされるクリッピング値インデックスは、クリッピング値のルーマ・テーブルとクリッピング値のクロマ・テーブルを使用してクリッピング値を決定することを許容する。これらのクリッピング値は、内部ビット深さに依存する。より正確には、クリッピング値のルーマ・テーブルとクリッピング値のクロマ・テーブルは、以下の公式によって得られる：
ここで、Bは、内部ビット深さに等しく、Nは4に等しく、これはVTM5.0における許容されるクリッピング値の数である。
フィルタリング・プロセスはCTBレベルで制御できる。ALFがルーマCTBに適用されるかどうかを示すためにフラグが常に信号伝達される。ルーマCTBは、16の固定したフィルタ集合およびAPSからのフィルタ集合の間でフィルタ集合を選択できる。フィルタ集合インデックスは、どのフィルタ集合が適用されるかを示すために、ルーマCTBについて信号伝達される。16個の固定したフィルタ集合は、あらかじめ定義されており、エンコーダとデコーダの両方でハードコーディングされる。
フィルタ係数は、128に等しいノルムで量子化される。乗算複雑さを制限するために、非中央位置の係数値が－27から27－1の範囲（両端含む）にあるようにビットストリーム適合性が適用される。中央位置係数は、ビットストリームにおいて信号伝達されず、128に等しいとみなされる。
2.8.1.5 フィルタリング・プロセス
デコーダ側では、CTBについてALFが有効にされているとき、CU内の各サンプルがフィルタリングされ、次のようなサンプル値を与える。
デコーダ側では、CTBについてALFが有効にされているとき、CU内の各サンプルがフィルタリングされ、次のようなサンプル値を与える。
ここで、f(k,l)はデコードされたフィルタ係数を表し、K(x,y)はクリッピング関数であり、c(k,l)はデコードされたクリッピング・パラメータを表す。変数kとlは、－L/2からL/2までの間で変化し、Lはフィルタ長を表す。クリッピング関数K(x,y)＝min(y,max(－y,x))であり、これは関数Clip3(－y,y,x)に等しい。
2.8.1.6 ラインバッファ削減のための仮想境界フィルタリング・プロセス
VTM5では、ALFのラインバッファ要求を低減するために、水平CTU境界付近のサンプルについて、修正されたブロック分類およびフィルタリングが採用される。この目的のために、仮想境界は、図10に示すように、「N」サンプルで水平CTU境界をシフトすることによって線として定義され、Nは、ルーマ成分については4、クロマ成分については2に等しい。
VTM5では、ALFのラインバッファ要求を低減するために、水平CTU境界付近のサンプルについて、修正されたブロック分類およびフィルタリングが採用される。この目的のために、仮想境界は、図10に示すように、「N」サンプルで水平CTU境界をシフトすることによって線として定義され、Nは、ルーマ成分については4、クロマ成分については2に等しい。
図10は、仮想境界における修正されたブロック分類の例を示す。
図11に示されるように、修正されたブロック分類がルーマ成分に適用され、よって、活性値Aは、1Dラプラシアン勾配計算で使用されるサンプル数の減少を考慮することによって、スケールされる。
フィルタ処理のために、仮想境界での対称的なパディング操作がルーマとクロマ成分の両方に使用される。図11に示されるように、フィルタリングされるサンプルが仮想境界の下に位置する場合、仮想境界の上方に位置する近傍サンプルは、パディングされる。一方、他の側面における対応するサンプルも、対称的にパディングされる。
図11は、仮想境界におけるルーマ成分についての修正されたALFフィルタリングの例を示す。
2.9 サンプル適応オフセット（SAO）
サンプル適応オフセット（SAO）は、エンコーダによって各CTBについて指定されたオフセットを使用することによって、ブロッキング解除フィルタ後に、再構成された信号に適用される。HMエンコーダは、まず、SAOプロセスが現在のスライスに適用されるか否かの判断をする。スライスにSAOが適用される場合、テーブル2-に示されるように、各CTBは5つのSAOタイプの1つに分類される。SAOの概念は、ピクセルをカテゴリーに分類し、各カテゴリーのピクセルにオフセットを加えることによって歪みを低減することである。SAO動作には、SAOタイプ1～4のピクセル分類についてエッジ属性を使用するエッジオフセット（EO）と、SAOタイプ5のピクセル分類についてピクセル強度を使用する帯域オフセット（BO）とを含む。適用可能な各CTBは、SAOパラメータ（sao_merge_left_flag、sao_merge_up_flag、SAOタイプ、および4つのオフセットを含む）を有する。sao_merge_left_flagが1に等しい場合、現在のCTBは、左のCTBのSAOタイプおよびオフセットを再利用する。sao_merge_up_flagが1に等しい場合、現在のCTBは、上のCTBのSAOタイプおよびオフセットを再利用する。
サンプル適応オフセット（SAO）は、エンコーダによって各CTBについて指定されたオフセットを使用することによって、ブロッキング解除フィルタ後に、再構成された信号に適用される。HMエンコーダは、まず、SAOプロセスが現在のスライスに適用されるか否かの判断をする。スライスにSAOが適用される場合、テーブル2-に示されるように、各CTBは5つのSAOタイプの1つに分類される。SAOの概念は、ピクセルをカテゴリーに分類し、各カテゴリーのピクセルにオフセットを加えることによって歪みを低減することである。SAO動作には、SAOタイプ1～4のピクセル分類についてエッジ属性を使用するエッジオフセット（EO）と、SAOタイプ5のピクセル分類についてピクセル強度を使用する帯域オフセット（BO）とを含む。適用可能な各CTBは、SAOパラメータ（sao_merge_left_flag、sao_merge_up_flag、SAOタイプ、および4つのオフセットを含む）を有する。sao_merge_left_flagが1に等しい場合、現在のCTBは、左のCTBのSAOタイプおよびオフセットを再利用する。sao_merge_up_flagが1に等しい場合、現在のCTBは、上のCTBのSAOタイプおよびオフセットを再利用する。
2.9.1 各SAOタイプの動作
エッジ・オフセットは、図12に示されるように、エッジ方向性情報を考慮することによって現在のピクセルpを分類するために、4つの1-D 3ピクセル・パターンを使用する。左から右に、これらは0度、90度、135度、45度である。
エッジ・オフセットは、図12に示されるように、エッジ方向性情報を考慮することによって現在のピクセルpを分類するために、4つの1-D 3ピクセル・パターンを使用する。左から右に、これらは0度、90度、135度、45度である。
図12は、EOにおけるピクセル分類のための4つの1-D 3ピクセル・パターンの例を示す。
各CTBは、テーブル2-7に従って5つのカテゴリーの1つに分類される。
帯域オフセット（BO）は、帯域インデックスとしてピクセル値の上位5ビットを使用することにより、1つのCTB領域内のすべてのピクセルを32個の均一帯域に分類する。言い換えると、ピクセル強度範囲は、ゼロから最大強度値（たとえば、8ビット・ピクセルについては255）までの32個の等しいセグメントに分割される。図13に示されるように、4つの隣接する帯域がグループ化され、それぞれのグループはその左端の位置で示される。エンコーダは、各帯域のオフセットを補償することにより、最大歪み低減を有するグループを得るために、すべての位置を探索する。
図13は、4つの帯域がグループ化され、その開始帯域位置によって表される例である。
2.10 複合インターおよびイントラ予測（CIIP）
VTM5では、CUがマージ・モードで符号化されている場合、CUが少なくとも64個のルーマ・サンプルを含み（すなわち、CU幅×CU高さが64以上）、CU幅とCU高さの両方が128ルーマ・サンプル未満の場合、現在のCUに複合インター／イントラ予測（CIIP）モードが適用されるかどうかを示すために追加フラグが信号伝達される。その名前が示すように、CIIP予測は、インター予測信号をイントラ予測信号と組み合わせる。CIIPモードでのインター予測信号Pinterは、通常のマージ・モードに適用されるのと同じインター予測プロセスを用いて導出され、イントラ予測信号Pintraは、平面モードでの通常のイントラ予測プロセスに従って導出される。次いで、重み付け平均を用いて、イントラおよびインター予測信号が組み合わされ、ここで、重み値は、上および左の近傍ブロック（図14に示される）の符号化モードに依存して、以下のように計算される：
・上の近傍が利用可能でイントラ符号化されている場合、isIntraTopを1に設定し、そうでない場合、isIntraTopを0に設定する；
・左近傍が利用可能でイントラ符号化されている場合、isIntraLeftを1に設定し、そうでない場合、isIntraLeftを0に設定する；
・（isIntraLeft＋isIntraLeft）が2に等しい場合、wtは3に設定される；
・それ以外で、（isIntraLeft＋isIntraLeft）が1に等しい場合、wtは2に設定される；
・それ以外の場合は、wtを1に設定する。
VTM5では、CUがマージ・モードで符号化されている場合、CUが少なくとも64個のルーマ・サンプルを含み（すなわち、CU幅×CU高さが64以上）、CU幅とCU高さの両方が128ルーマ・サンプル未満の場合、現在のCUに複合インター／イントラ予測（CIIP）モードが適用されるかどうかを示すために追加フラグが信号伝達される。その名前が示すように、CIIP予測は、インター予測信号をイントラ予測信号と組み合わせる。CIIPモードでのインター予測信号Pinterは、通常のマージ・モードに適用されるのと同じインター予測プロセスを用いて導出され、イントラ予測信号Pintraは、平面モードでの通常のイントラ予測プロセスに従って導出される。次いで、重み付け平均を用いて、イントラおよびインター予測信号が組み合わされ、ここで、重み値は、上および左の近傍ブロック（図14に示される）の符号化モードに依存して、以下のように計算される：
・上の近傍が利用可能でイントラ符号化されている場合、isIntraTopを1に設定し、そうでない場合、isIntraTopを0に設定する；
・左近傍が利用可能でイントラ符号化されている場合、isIntraLeftを1に設定し、そうでない場合、isIntraLeftを0に設定する；
・（isIntraLeft＋isIntraLeft）が2に等しい場合、wtは3に設定される；
・それ以外で、（isIntraLeft＋isIntraLeft）が1に等しい場合、wtは2に設定される；
・それ以外の場合は、wtを1に設定する。
CIIP予測は以下のように形成される:
PCIIP＝（(4－wt)*Pinter＋wt*Pintra＋2）>>2 (3-2)
PCIIP＝（(4－wt)*Pinter＋wt*Pintra＋2）>>2 (3-2)
図14は、CIIP重み導出に用いられる上および左の近傍ブロックの例を示す。
2.11 クロマ・スケーリングのあるルーマ・マッピング（LMCS）
VTM5では、クロマ・スケーリングのあるルーマ・マッピング（luma mapping with chroma scaling、LMCS）と呼ばれる符号化ツールが、ループ・フィルタの前に新しい処理ブロックとして追加される。LMCSは、1）適応区分線形モデルに基づくルーマ成分のループ内マッピング、2）クロマ成分について、ルーマ依存クロマ残差スケーリングが適用される、という2つの主要な構成要素を有する。図15は、デコーダの観点からのLMCSアーキテクチャーを示す。図15の点線のブロックは、マップされたドメインで処理が適用されるところを示しており、これらには、逆量子化、逆変換、ルーマ・イントラ予測およびルーマ残差とルーマ予測の加算を含む。図15のパターニングされていないブロックは、処理がもとの（すなわち、マップされていない）ドメインで適用されるところを示し、これらは、ブロッキング解除、ALF、およびSAOのようなループ・フィルタ、動き補償された予測、クロマ・イントラ予測、クロマ予測とクロマ残差の加算、およびデコードされたピクチャーの参照ピクチャーとしての記憶を含む。図15のチェッカー状のブロックは、ルーマ信号の順方向および逆マッピング、およびルーマ依存クロマ・スケーリング・プロセスを含む、新しいLMCS機能ブロックである。VVCのたいていの他のツールと同様に、LMCSはSPSフラグを使用して、シーケンス・レベルで有効／無効にできる。
VTM5では、クロマ・スケーリングのあるルーマ・マッピング（luma mapping with chroma scaling、LMCS）と呼ばれる符号化ツールが、ループ・フィルタの前に新しい処理ブロックとして追加される。LMCSは、1）適応区分線形モデルに基づくルーマ成分のループ内マッピング、2）クロマ成分について、ルーマ依存クロマ残差スケーリングが適用される、という2つの主要な構成要素を有する。図15は、デコーダの観点からのLMCSアーキテクチャーを示す。図15の点線のブロックは、マップされたドメインで処理が適用されるところを示しており、これらには、逆量子化、逆変換、ルーマ・イントラ予測およびルーマ残差とルーマ予測の加算を含む。図15のパターニングされていないブロックは、処理がもとの（すなわち、マップされていない）ドメインで適用されるところを示し、これらは、ブロッキング解除、ALF、およびSAOのようなループ・フィルタ、動き補償された予測、クロマ・イントラ予測、クロマ予測とクロマ残差の加算、およびデコードされたピクチャーの参照ピクチャーとしての記憶を含む。図15のチェッカー状のブロックは、ルーマ信号の順方向および逆マッピング、およびルーマ依存クロマ・スケーリング・プロセスを含む、新しいLMCS機能ブロックである。VVCのたいていの他のツールと同様に、LMCSはSPSフラグを使用して、シーケンス・レベルで有効／無効にできる。
図15は、クロマ・スケーリング・アーキテクチャーのあるルーマ・マッピングの例を示す。
2.12 デュアルツリー分割
現在のVVC設計では、Iスライスについて、暗黙的な四分木分割を使用して、各CTUは64×64ルーマ・サンプルをもつ符号化単位に分割でき、これらの符号化単位はルーマとクロマについての2つの別々の符号化ツリー構文構造のルート（root）である。
現在のVVC設計では、Iスライスについて、暗黙的な四分木分割を使用して、各CTUは64×64ルーマ・サンプルをもつ符号化単位に分割でき、これらの符号化単位はルーマとクロマについての2つの別々の符号化ツリー構文構造のルート（root）である。
イントラ・ピクチャーにおけるデュアルツリーでは、ルーマ符号化ツリーと比較してクロマ符号化ツリーにおいて異なるパーティション分割を適用することができるため、デュアルツリーは、より長い符号化パイプラインを導入し、QTBT MinQTSizeC値範囲ならびにクロマツリーにおけるMinBtSizeYおよびMinTTSizeYでは、2×2、4×2、2×4などの小さなクロマ・ブロックが許可される。それは、実際的なデコーダ設計に困難をもたらす。さらに、CCLM、平面および角度性モードのようないくつかの予測モードは乗算を必要とする。上記の問題を緩和するために、小さなクロマ・ブロック・サイズ（2x2/2x4/4x2）は分割制限としてデュアルツリーにおいて制約される。
2.13 JVET-O0050における最小クロマ・イントラ予測ユニット（SCIPU）
小さなクロマサイズはハードウェア実装には不向きである。デュアルツリーの場合、サイズが小さすぎるクロマ・ブロックは許容されない。しかしながら、シングルツリーの場合、VVCドラフト5は、依然として2×2、2×4、4×2クロマ・ブロックを許容する。クロマ・ブロックのサイズを制限するために、単一符号化ツリーにおいて、SCIPUは、JVET-O0050において、クロマ・ブロック・サイズがTHクロマ・サンプル以上であり、4THルーマ・サンプルより小さい少なくとも1つの子ルーマ・ブロックを有する符号化ツリー・ノードとして定義される。ここで、THは、この寄稿では16に設定される。各SCIPUでは、すべてのCBがインターであるか、またはすべてのCBが非インターである、すなわちイントラまたはIBCのいずれかであることが要求される。非インターSCIPUの場合、さらに、非インターSCIPUのクロマがそれ以上分割されず、SCIPUのルーマがさらに分割されることが許されることが要求される。このようにして、最小のクロマ・イントラCBサイズは16クロマ・サンプルであり、2×2、2×4、および4×2クロマCBが除去される。さらに、クロマ・スケーリングは、非インターSCIPUの場合には適用されない。
小さなクロマサイズはハードウェア実装には不向きである。デュアルツリーの場合、サイズが小さすぎるクロマ・ブロックは許容されない。しかしながら、シングルツリーの場合、VVCドラフト5は、依然として2×2、2×4、4×2クロマ・ブロックを許容する。クロマ・ブロックのサイズを制限するために、単一符号化ツリーにおいて、SCIPUは、JVET-O0050において、クロマ・ブロック・サイズがTHクロマ・サンプル以上であり、4THルーマ・サンプルより小さい少なくとも1つの子ルーマ・ブロックを有する符号化ツリー・ノードとして定義される。ここで、THは、この寄稿では16に設定される。各SCIPUでは、すべてのCBがインターであるか、またはすべてのCBが非インターである、すなわちイントラまたはIBCのいずれかであることが要求される。非インターSCIPUの場合、さらに、非インターSCIPUのクロマがそれ以上分割されず、SCIPUのルーマがさらに分割されることが許されることが要求される。このようにして、最小のクロマ・イントラCBサイズは16クロマ・サンプルであり、2×2、2×4、および4×2クロマCBが除去される。さらに、クロマ・スケーリングは、非インターSCIPUの場合には適用されない。
2つのSCIPUの例が図16に示される。図6の(a)においては、8×4クロマ・サンプルの1つのクロマCBと3つのルーマCB（4×8、8×8、4×8のルーマCB）が1つのSCIPUを形成するが、これは、8×4クロマ・サンプルからの三分木（TT）分割は、16クロマ・サンプルより小さなクロマCBを生じるためである。図16の(b)では、4×4クロマ・サンプルの一方のクロマCB（8×4クロマ・サンプルの左側）と3つのルーマCB（8×4、4×4、4×4のルーマCB）が1つのSCIPUを形成し、4×4サンプルの他方のクロマCB（8×4クロマ・サンプルの右側）と2つのルーマCB（8×4、8×4のルーマCB）が1つのSCIPUを形成する。これは、4×4クロマ・サンプルからの二分木（BT）分割は、16のクロマ・サンプルよりも小さなクロマCBを生じるためである。
図16は、SCIPUの例を示す。
現在のスライスがIスライスであるか、または現在のSCIPUがさらに1回分割した後に4×4ルーマ・パーティションをその中に有する場合、SCIPUのタイプは非インターであると推定される（VVCではインター4×4は許可されないため）；それ以外の場合、SCIPUのタイプ（インターまたは非インター）は、SCIPUにおいてCUをパースする前に、1つの信号伝達されるフラグによって示される。
2.14 VVCドラフト6における小クロマ・ブロック制約条件
VVCドラフト6（JVET-O2001-vE.docx）では、小さなクロマ・ブロックに対する制約条件は以下のように実装されている（関連する部分は太字の斜体でマークされている）。
VVCドラフト6（JVET-O2001-vE.docx）では、小さなクロマ・ブロックに対する制約条件は以下のように実装されている（関連する部分は太字の斜体でマークされている）。
2.14.1.1 符号化単位構文
許容される四分分割プロセス
このプロセスへの入力は以下の通りである：
・ルーマ・サンプル中の符号化ブロック・サイズcbSize、
・マルチタイプ・ツリー深さmttDepth、
・CTUを分割するためにシングルツリー（SINGLE_TREE）が使われるかまたはデュアルツリーが使われるかと、デュアルツリーが使用される場合は、現在処理されているのがルーマ成分か（DUAL_TREE_LUMA）またはクロマ成分か（DUAL_TREE_CHROMA）とを指定する変数treeType。
〔ビットマップの内容をテキストでも記載しておく：符号化ツリー・ノード内の符号化単位のために、イントラ（MODE_INTRA）、IBC（MODE_IBC）、パレット（MODE_PLT）、およびインター符号化モードを使用できるかどうか（MODE_TYPE_ALL）、またはイントラ、IBC、およびパレット符号化モードのみが使用できるかどうか（MODE_TYPE_INTRA）、またはインター符号化モードのみが使用できるかどうか（MODE_TYPE_INTER）を指定する変数modeType。〕
このプロセスへの入力は以下の通りである：
・ルーマ・サンプル中の符号化ブロック・サイズcbSize、
・マルチタイプ・ツリー深さmttDepth、
・CTUを分割するためにシングルツリー（SINGLE_TREE）が使われるかまたはデュアルツリーが使われるかと、デュアルツリーが使用される場合は、現在処理されているのがルーマ成分か（DUAL_TREE_LUMA）またはクロマ成分か（DUAL_TREE_CHROMA）とを指定する変数treeType。
このプロセスの出力は、変数allowSplitQtである。
変数allowSplitQtは次のように導出される：
・次の条件の一つまたは複数が真である場合、allowSplitQtはFALSEに等しく設定される：
・treeTypeがSINGLE_TREEまたはDUAL_TREE_LUMAに等しく、cbSizeがMinQtSizeY以下
・treeTypeがDUAL_TREE_CHROMAに等しく、cbSize/SubWidthCがMinQtSizeC以下
・mttDepthが0に等しくない
・treeTypeがDUAL_TREE_CHROMAに等しく、（cbSize/SubWidthC）が4以下
・そうでない場合、allowSplitQtはTRUEに等しく設定される。
・次の条件の一つまたは複数が真である場合、allowSplitQtはFALSEに等しく設定される：
・treeTypeがSINGLE_TREEまたはDUAL_TREE_LUMAに等しく、cbSizeがMinQtSizeY以下
・treeTypeがDUAL_TREE_CHROMAに等しく、cbSize/SubWidthCがMinQtSizeC以下
・mttDepthが0に等しくない
・treeTypeがDUAL_TREE_CHROMAに等しく、（cbSize/SubWidthC）が4以下
許容される二分分割プロセス
このプロセスへの入力は以下の通りである：
・二分分割モードbtSplit、
・ルーマ・サンプル単位での符号化ブロック幅cbWidth、
・ルーマ・サンプル単位での符号化ブロック高さcbHeight、
・ピクチャーの左上のルーマ・サンプルに対する、考えられている符号化ブロックの左上のルーマ・サンプルの位置（x0,y0）
・マルチタイプ・ツリー深さmttDepth、
・オフセットmaxMttDepthをもつ最大マルチタイプ・ツリー深さ、
・最大二分木サイズmaxBtSize、
・最小四分木サイズminQtSize、
・パーティションインデックスpartIdx、
・CTUを分割するためにシングルツリー（SINGLE_TREE）が使われるかまたはデュアルツリーが使われるかと、デュアルツリーが使用される場合は、現在処理されているのがルーマ成分か（DUAL_TREE_LUMA）またはクロマ成分か（DUAL_TREE_CHROMA）とを指定する変数treeType。
〔ビットマップの内容をテキストでも記載しておく：符号化ツリー・ノード内の符号化単位のために、イントラ（MODE_INTRA）、IBC（MODE_IBC）、パレット（MODE_PLT）、およびインター符号化モードを使用できるかどうか（MODE_TYPE_ALL）、またはイントラ、IBC、およびパレット符号化モードのみが使用できるかどうか（MODE_TYPE_INTRA）、またはインター符号化モードのみが使用できるかどうか（MODE_TYPE_INTER）を指定する変数modeType。〕
このプロセスへの入力は以下の通りである：
・二分分割モードbtSplit、
・ルーマ・サンプル単位での符号化ブロック幅cbWidth、
・ルーマ・サンプル単位での符号化ブロック高さcbHeight、
・ピクチャーの左上のルーマ・サンプルに対する、考えられている符号化ブロックの左上のルーマ・サンプルの位置（x0,y0）
・マルチタイプ・ツリー深さmttDepth、
・オフセットmaxMttDepthをもつ最大マルチタイプ・ツリー深さ、
・最大二分木サイズmaxBtSize、
・最小四分木サイズminQtSize、
・パーティションインデックスpartIdx、
・CTUを分割するためにシングルツリー（SINGLE_TREE）が使われるかまたはデュアルツリーが使われるかと、デュアルツリーが使用される場合は、現在処理されているのがルーマ成分か（DUAL_TREE_LUMA）またはクロマ成分か（DUAL_TREE_CHROMA）とを指定する変数treeType。
このプロセスの出力は、変数allowBtSplitである。
変数parallelTtSplitとcbSizeは、テーブル6-2に指定されるように導出される。
変数allowBtSplitは次のように導出される：
・次の条件の一つまたは複数が真である場合、allowBtSplitはFALSEに等しく設定される：
・cbSizeがMinBtSizeY以下
・cbWidthがmaxBtSizeより大きい
・cbHeightがmaxBtSizeより大きい
・mttDepthがmaxMttDepth以上
・treeTypeがDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は16以下
・それ以外の場合で、次の条件がすべて真であれば、allowBtSplitはFALSEに等しく設定される
・btSplitがSPLIT_BT_VERと等しい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・それ以外の場合で、次の条件がすべて真であれば、allowBtSplitはFALSEに等しく設定される
・btSplitがSPLIT_BT_VERと等しい
・cbHeightがMaxTbSizeYより大きい
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・それ以外の場合で、次の条件がすべて真である場合、allowBtSplitがFALSEに等しく設定される
・btSplitがSPLIT_BT_HORと等しい
・cbWidthがMaxTbSizeYより大きい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・それ以外の場合で、次の条件がすべて真である場合、allowBtSplitはFALSEに等しく設定される。
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・cbWidthがminQtSizeより大きい
・それ以外の場合で、次の条件がすべて真である場合、allowBtSplitはFALSEに等しく設定される。
・btSplitがSPLIT_BT_HORと等しい
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・y0＋cbHeightがpic_height_in_luma_samples以下
・それ以外の場合で、次の条件がすべて真である場合、allowBtSplitはFALSEに等しく設定される。
・mttDepthが0より大きい
・partIdxが1に等しい
・MttSplitMode[x0][y0][mttDepth－1]がparallelTtSplitと等しい
・それ以外の場合で、次の条件がすべて真である場合、parallelBtSplitはFALSEに等しく設定される。
・btSplitがSPLIT_BT_VERと等しい
・cbWidthがMaxTbSizeY以下
・cbHeightがMaxTbSizeYより大きい
・それ以外の場合で、次の条件がすべて真である場合、allowBtSplitはFALSEに等しく設定される。
・btSplitがSPLIT_BT_HORと等しい
・cbWidthがMaxTbSizeYより大きい
・cbHeightがMaxTbSizeY以下
・それ以外の場合、allowBtSplitはTRUEに等しく設定される。
・次の条件の一つまたは複数が真である場合、allowBtSplitはFALSEに等しく設定される：
・cbSizeがMinBtSizeY以下
・cbWidthがmaxBtSizeより大きい
・cbHeightがmaxBtSizeより大きい
・mttDepthがmaxMttDepth以上
・treeTypeがDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は16以下
・btSplitがSPLIT_BT_VERと等しい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・それ以外の場合で、次の条件がすべて真であれば、allowBtSplitはFALSEに等しく設定される
・btSplitがSPLIT_BT_VERと等しい
・cbHeightがMaxTbSizeYより大きい
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・それ以外の場合で、次の条件がすべて真である場合、allowBtSplitがFALSEに等しく設定される
・btSplitがSPLIT_BT_HORと等しい
・cbWidthがMaxTbSizeYより大きい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・それ以外の場合で、次の条件がすべて真である場合、allowBtSplitはFALSEに等しく設定される。
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・cbWidthがminQtSizeより大きい
・それ以外の場合で、次の条件がすべて真である場合、allowBtSplitはFALSEに等しく設定される。
・btSplitがSPLIT_BT_HORと等しい
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・y0＋cbHeightがpic_height_in_luma_samples以下
・それ以外の場合で、次の条件がすべて真である場合、allowBtSplitはFALSEに等しく設定される。
・mttDepthが0より大きい
・partIdxが1に等しい
・MttSplitMode[x0][y0][mttDepth－1]がparallelTtSplitと等しい
・それ以外の場合で、次の条件がすべて真である場合、parallelBtSplitはFALSEに等しく設定される。
・btSplitがSPLIT_BT_VERと等しい
・cbWidthがMaxTbSizeY以下
・cbHeightがMaxTbSizeYより大きい
・それ以外の場合で、次の条件がすべて真である場合、allowBtSplitはFALSEに等しく設定される。
・btSplitがSPLIT_BT_HORと等しい
・cbWidthがMaxTbSizeYより大きい
・cbHeightがMaxTbSizeY以下
・それ以外の場合、allowBtSplitはTRUEに等しく設定される。
許容される三分分割プロセス
このプロセスへの入力は以下の通りである：
・三分分割モードttSplit、
・ルーマ・サンプル単位での符号化ブロック幅cbWidth、
・ルーマ・サンプル単位での符号化ブロックの高さcbHeight、
・ピクチャーの左上のルーマ・サンプルに対する、考えられている符号化ブロックの左上のルーマ・サンプルの位置（x0,y0）
・マルチタイプ・ツリー深さmttDepth
・オフセットmaxMttDepthをもつ最大マルチタイプ・ツリー深さ、
・最大三分木サイズmaxTtSize、
・CTUを分割するためにシングルツリー（SINGLE_TREE）が使われるかまたはデュアルツリーが使われるかと、デュアルツリーが使用される場合は、現在処理されているのがルーマ成分か（DUAL_TREE_LUMA）またはクロマ成分か（DUAL_TREE_CHROMA）とを指定する変数treeType。
〔ビットマップの内容をテキストでも記載しておく：符号化ツリー・ノード内の符号化単位のために、イントラ（MODE_INTRA）、IBC（MODE_IBC）、パレット（MODE_PLT）、およびインター符号化モードを使用できるかどうか（MODE_TYPE_ALL）、またはイントラ、IBC、およびパレット符号化モードのみが使用できるかどうか（MODE_TYPE_INTRA）、またはインター符号化モードのみが使用できるかどうか（MODE_TYPE_INTER）を指定する変数modeType。〕
このプロセスへの入力は以下の通りである：
・三分分割モードttSplit、
・ルーマ・サンプル単位での符号化ブロック幅cbWidth、
・ルーマ・サンプル単位での符号化ブロックの高さcbHeight、
・ピクチャーの左上のルーマ・サンプルに対する、考えられている符号化ブロックの左上のルーマ・サンプルの位置（x0,y0）
・マルチタイプ・ツリー深さmttDepth
・オフセットmaxMttDepthをもつ最大マルチタイプ・ツリー深さ、
・最大三分木サイズmaxTtSize、
・CTUを分割するためにシングルツリー（SINGLE_TREE）が使われるかまたはデュアルツリーが使われるかと、デュアルツリーが使用される場合は、現在処理されているのがルーマ成分か（DUAL_TREE_LUMA）またはクロマ成分か（DUAL_TREE_CHROMA）とを指定する変数treeType。
このプロセスの出力は、変数allowTtSplitである。
変数cbSizeは、テーブル6-3に指定されているように導出される。
変数allowTtSplitは次のように導出される：
・次の条件の一つまたは複数が真の場合は、allowTtSplitはFALSEに等しく設定される：
・cbSizeが2×MinTtSizeY以下
・cbWidthがMin（MaxTbSizeY,maxTtSize）より大きい
・cbHeightがMin（MaxTbSizeY,maxTtSize）より大きい
・mttDepthがmaxMttDepth以上
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・treeTypeがDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は32以下
・それ以外の場合は、allowTtSplitがTRUEに等しく設定される。
・次の条件の一つまたは複数が真の場合は、allowTtSplitはFALSEに等しく設定される：
・cbSizeが2×MinTtSizeY以下
・cbWidthがMin（MaxTbSizeY,maxTtSize）より大きい
・cbHeightがMin（MaxTbSizeY,maxTtSize）より大きい
・mttDepthがmaxMttDepth以上
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・treeTypeがDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は32以下
pred_mode_flagが0に等しいことは、現在の符号化単位がインター予測モードで符号化されることを指定する。pred_mode_flagが1に等しいことは、現在の符号化単位がイントラ予測モードで符号化されることを指定する。
pred_mode_flagが存在しない場合、次のように推定される：
pred_mode_flagが存在しない場合、次のように推定される：
変数CuPredMode[chType][x][y]は、x＝x0..x0＋cbWidth－1およびy＝y0..y0＋cbHeight－1について、次のように導出される：
・pred_mode_flagが0に等しい場合、CuPredMode[chType][x][y]はMODE_INTERに等しく設定される。
・それ以外の場合（pred_mode_flagが1に等しい）、CuPredMode[chType][x][y]はMODE_INTRAに等しく設定される。
・pred_mode_flagが0に等しい場合、CuPredMode[chType][x][y]はMODE_INTERに等しく設定される。
・それ以外の場合（pred_mode_flagが1に等しい）、CuPredMode[chType][x][y]はMODE_INTRAに等しく設定される。
pred_mode_ibc_flagが1に等しいことは、現在の符号化単位がIBC予測モードで符号化されることを指定する。pred_mode_ibc_flagが0に等しいことは、現在の符号化単位がIBC予測モードで符号化されないことを指定する。
pred_mode_ibc_flagが存在しない場合、次のように推定される：
pred_mode_ibc_flagが1に等しい場合、変数CuPredMode[chType][x][y]は、x＝x0..x0＋cbWidth－1およびy＝y0..y0＋cbHeight－1についてMODE_IBCに等しいと設定される。
pred_mode_ibc_flagが存在しない場合、次のように推定される：
3. 課題
１．現在、IBCはMODE_TYPE_INTRAと考えられているため、小さなクロマ・ブロックは許容されず、不必要な符号化効率の低下につながる。
２．現在、パレットはMODE_TYPE_INTRAと考えられているため、小さなクロマ・ブロックは許容されず、不必要な符号化効率の低下につながる。
３．現在、小さなクロマ・ブロック制約条件は、色サブサンプリング・フォーマットを考慮していない。
４．現在、小ブロック上の同じパーティションおよび予測モード制約条件がすべてのクロマ・フォーマットに適用される。しかしながら、4:2:0および4:2:2クロマ・フォーマットにおいて、小さなブロックに対する異なる制約条件メカニズムを設計することが望ましい場合がある。
５．現在、パレット・モード・フラグ信号伝達はmodeTypeに依存しており、これはパレットが小ブロック制約条件を適用しない可能性があるため望ましくない。
６．現在、IBCモード・フラグは、cu_skip_flagが1に等しいが、MODE_TYPEがMODE_TYPE_INTRAに等しいP/Bスライスについて0であると推定される。これは構文解析では不正（illegal）である。
７．現在、非4×4ルーマIBCモードはSCIPUルーマ・ブロックについて許容されておらず、これは望ましくないかもしれず、符号化効率の損失を引き起こしうる。
８．2×Hクロマ・ブロックは相変わらず許容されるが、ハードウェア実装には不向きである。
９．CIIPはMODE_INTERとみなされるが、イントラ予測を使用し、そのことは、場合によっては制約条件を破る。
１０．SCIPUが適用される場合、ルーマ分割に依存してクロマについてのデルタQPが信号伝達されることがある。たとえば、現在のブロック寸法がルーマ・サンプル単位で16×8であり、垂直TTで分割される場合、ローカルのデュアルツリーが適用されてもよい。qgOnC＝qgOnC && （cbSubdiv＋2<=cu_chroma_qp_offset_subdiv）と規定されている。よって、cbSubdiv＋2<=cu_chroma_qp_offset_subdivであれば、qgOnCはゼロに設定される。この条件付き設定は、クロマ成分もTTによって分割されると想定している。ローカルデュアルツリーでは、クロマ成分は分割されない可能性があるため、cbSubdivはcu_chroma_qp_offset_subdivよりも大きい可能性がある。クロマについてのデルタQPの信号伝達を許容するためには、IsCuChromaQpOffsetCodedは0に設定されるべきである。ただし、qgOnCが0に設定されているため、IsCuChromaQpOffsetCodedは0に設定されない。
１１．可逆符号化の場合の最大変換サイズが、不可逆符号化の場合の最大変換サイズとは異なるように設定されることがある。
１．現在、IBCはMODE_TYPE_INTRAと考えられているため、小さなクロマ・ブロックは許容されず、不必要な符号化効率の低下につながる。
２．現在、パレットはMODE_TYPE_INTRAと考えられているため、小さなクロマ・ブロックは許容されず、不必要な符号化効率の低下につながる。
３．現在、小さなクロマ・ブロック制約条件は、色サブサンプリング・フォーマットを考慮していない。
４．現在、小ブロック上の同じパーティションおよび予測モード制約条件がすべてのクロマ・フォーマットに適用される。しかしながら、4:2:0および4:2:2クロマ・フォーマットにおいて、小さなブロックに対する異なる制約条件メカニズムを設計することが望ましい場合がある。
５．現在、パレット・モード・フラグ信号伝達はmodeTypeに依存しており、これはパレットが小ブロック制約条件を適用しない可能性があるため望ましくない。
６．現在、IBCモード・フラグは、cu_skip_flagが1に等しいが、MODE_TYPEがMODE_TYPE_INTRAに等しいP/Bスライスについて0であると推定される。これは構文解析では不正（illegal）である。
７．現在、非4×4ルーマIBCモードはSCIPUルーマ・ブロックについて許容されておらず、これは望ましくないかもしれず、符号化効率の損失を引き起こしうる。
８．2×Hクロマ・ブロックは相変わらず許容されるが、ハードウェア実装には不向きである。
９．CIIPはMODE_INTERとみなされるが、イントラ予測を使用し、そのことは、場合によっては制約条件を破る。
１０．SCIPUが適用される場合、ルーマ分割に依存してクロマについてのデルタQPが信号伝達されることがある。たとえば、現在のブロック寸法がルーマ・サンプル単位で16×8であり、垂直TTで分割される場合、ローカルのデュアルツリーが適用されてもよい。qgOnC＝qgOnC && （cbSubdiv＋2<=cu_chroma_qp_offset_subdiv）と規定されている。よって、cbSubdiv＋2<=cu_chroma_qp_offset_subdivであれば、qgOnCはゼロに設定される。この条件付き設定は、クロマ成分もTTによって分割されると想定している。ローカルデュアルツリーでは、クロマ成分は分割されない可能性があるため、cbSubdivはcu_chroma_qp_offset_subdivよりも大きい可能性がある。クロマについてのデルタQPの信号伝達を許容するためには、IsCuChromaQpOffsetCodedは0に設定されるべきである。ただし、qgOnCが0に設定されているため、IsCuChromaQpOffsetCodedは0に設定されない。
１１．可逆符号化の場合の最大変換サイズが、不可逆符号化の場合の最大変換サイズとは異なるように設定されることがある。
4. 技術的解決策および実施形態の例
以下のリストは、例として考慮されるべきである。これらの技法は狭義に解釈されるべきではない。さらに、これらの技法は、任意の仕方で組み合わされることができる。
以下のリストは、例として考慮されるべきである。これらの技法は狭義に解釈されるべきではない。さらに、これらの技法は、任意の仕方で組み合わされることができる。
本稿では、「M×N符号化ツリー・ノード」とは、M×Nブロックを示し、ルーマ・サンプル単位でMがブロック幅、Nがブロック高さであり、これはさらに、QT/BT/TTなどで分割されてもよい。たとえば、ブロックは、QTノード、BTノード、またはTTノードでありうる。符号化ツリー・ノードは、符号化単位（たとえば、シングルツリーの場合は3つの色成分、デュアルツリー・クロマ符号化の場合は2つのクロマ色成分、デュアルツリー・ルーマ符号化の場合はルーマ色成分のみを含む）、またはルーマ符号化ブロック、またはクロマ符号化ブロックでありうる。「小符号化ツリー・ノードユニット」は、ルーマ・サンプル単位で32/64/128に等しいブロック・サイズM×Nをもつ符号化ツリー・ノードを示しうる。
特に記載がなければ、符号化ブロックについての幅Wと高さHはルーマ・サンプル単位で測られる。たとえば、M×N符号化ブロックとは、M×Nルーマ・ブロックおよび／または2つの（M/SubWidthC）×（N/SubHeightC）クロマ・ブロックを意味し、ここでSubWidthCおよびSubHeightCは、下記のようにクロマ・フォーマットによって導出される。
１．小ブロックに分割するかどうか、および／または、どのように分割するかは、色フォーマットに依存してもよい。
ａ．一例では、4:4:4色フォーマットについて、クロマ・ブロックのサイズに関する制約条件は、ルーマ・ブロックに関する制約条件に従ってもよい。
ｂ．一例では、4:2:2色フォーマットについて、クロマ・ブロックのサイズに関する制約条件は、4:2:0色フォーマットについての制約条件に従ってもよい。
ｃ．一例では、4:0:0および／または4:4:4クロマ・フォーマットについて、小ブロック・パーティションおよび／または予測モードに関する制約条件が適用されなくてもよい。
ｄ．一例では、小ブロック・パーティションおよび／または予測モードに対する制約条件は、異なるクロマ・フォーマットについて異なるように適用されてもよい。
ｉ．一例では、水平BT分割を伴うM×N（たとえば8×8）符号化ツリー・ノードについて、4:2:2クロマ・フォーマットでは、水平BT分割は、クロマ・ブロックとルーマ・ブロックの両方について許容されてもよいが、4:2:0クロマ・フォーマットでは、水平BT分割は、ルーマ・ブロックについて許可されるが、クロマ・ブロックについては無効にされるのでもよい。
ｉｉ．一例では、垂直BT分割を伴うM×N（たとえば16×4）符号化ツリー・ノードについて、4:2:2クロマ・フォーマットでは、垂直BT分割は、クロマ・ブロックとルーマ・ブロックの両方について許容されてもよいが、4:2:0クロマ・フォーマットでは、垂直BT分割は、ルーマ・ブロックについて許容されるが、クロマ・ブロックについては無効にされるのでもよい。
ｉｉｉ．一例では、水平TT分割を伴うM×N（たとえば8×16）符号化ツリー・ノードについて、4:2:2クロマ・フォーマットでは、クロマ・ブロックとルーマ・ブロックの両方について水平TT分割が許容されてもよいが、4:2:0クロマ・フォーマットでは、水平TT分割は、ルーマ・ブロックについて許容されるがクロマ・ブロックについては無効にされるのでもよい。
ｉｖ．一例では、垂直TT分割を伴うM×N（32×4など）符号化ツリー・ノードについては、4:2:2クロマ・フォーマットでは、クロマ・ブロックとルーマ・ブロックの両方について垂直TT分割が許容されてもよいが、4:2:0クロマ・フォーマットでは、垂直TT分割は、ルーマ・ブロックについては許容されるがクロマ・ブロックについては無効にされるのでもよい。
ｖ．一例では、4:0:0および／または4:4:4色フォーマットについて、小ブロック制約条件が適用されなくてもよい。
ｅ．一例では、SCIPUを有効にするかどうかは、色フォーマットに依存する。
ｉ．一例では、SCIPUは、4:2:0および4:2:2色フォーマットについて有効にされる。
ｉｉ．一例では、SCIPUは、4:0:0および／または4:4:4色フォーマットについては無効にされる。
１．一例では、modeTypeは、4:0:0および／または4:4:4色フォーマットについては、常にMODE_TYPE_ALLに等しくてもよい。
２．一例では、modeTypeConditionは、4:0:0および／または4:4:4の色フォーマットについては、常に0に等しくてもよい。
ａ．一例では、4:4:4色フォーマットについて、クロマ・ブロックのサイズに関する制約条件は、ルーマ・ブロックに関する制約条件に従ってもよい。
ｂ．一例では、4:2:2色フォーマットについて、クロマ・ブロックのサイズに関する制約条件は、4:2:0色フォーマットについての制約条件に従ってもよい。
ｃ．一例では、4:0:0および／または4:4:4クロマ・フォーマットについて、小ブロック・パーティションおよび／または予測モードに関する制約条件が適用されなくてもよい。
ｄ．一例では、小ブロック・パーティションおよび／または予測モードに対する制約条件は、異なるクロマ・フォーマットについて異なるように適用されてもよい。
ｉ．一例では、水平BT分割を伴うM×N（たとえば8×8）符号化ツリー・ノードについて、4:2:2クロマ・フォーマットでは、水平BT分割は、クロマ・ブロックとルーマ・ブロックの両方について許容されてもよいが、4:2:0クロマ・フォーマットでは、水平BT分割は、ルーマ・ブロックについて許可されるが、クロマ・ブロックについては無効にされるのでもよい。
ｉｉ．一例では、垂直BT分割を伴うM×N（たとえば16×4）符号化ツリー・ノードについて、4:2:2クロマ・フォーマットでは、垂直BT分割は、クロマ・ブロックとルーマ・ブロックの両方について許容されてもよいが、4:2:0クロマ・フォーマットでは、垂直BT分割は、ルーマ・ブロックについて許容されるが、クロマ・ブロックについては無効にされるのでもよい。
ｉｉｉ．一例では、水平TT分割を伴うM×N（たとえば8×16）符号化ツリー・ノードについて、4:2:2クロマ・フォーマットでは、クロマ・ブロックとルーマ・ブロックの両方について水平TT分割が許容されてもよいが、4:2:0クロマ・フォーマットでは、水平TT分割は、ルーマ・ブロックについて許容されるがクロマ・ブロックについては無効にされるのでもよい。
ｉｖ．一例では、垂直TT分割を伴うM×N（32×4など）符号化ツリー・ノードについては、4:2:2クロマ・フォーマットでは、クロマ・ブロックとルーマ・ブロックの両方について垂直TT分割が許容されてもよいが、4:2:0クロマ・フォーマットでは、垂直TT分割は、ルーマ・ブロックについては許容されるがクロマ・ブロックについては無効にされるのでもよい。
ｖ．一例では、4:0:0および／または4:4:4色フォーマットについて、小ブロック制約条件が適用されなくてもよい。
ｅ．一例では、SCIPUを有効にするかどうかは、色フォーマットに依存する。
ｉ．一例では、SCIPUは、4:2:0および4:2:2色フォーマットについて有効にされる。
ｉｉ．一例では、SCIPUは、4:0:0および／または4:4:4色フォーマットについては無効にされる。
１．一例では、modeTypeは、4:0:0および／または4:4:4色フォーマットについては、常にMODE_TYPE_ALLに等しくてもよい。
２．一例では、modeTypeConditionは、4:0:0および／または4:4:4の色フォーマットについては、常に0に等しくてもよい。
２．符号化ツリー・ノードの（サブ）ブロックについての予測モード（および／またはmodeType）をどのように決定するかは、クロマ・フォーマットに依存してもよい。
ａ．一例では、以下の条件の1つが真の場合、この符号化ツリー・ノードによって分割された（サブ）ブロックのmodeTypeは、4:2:2クロマ・フォーマットについてはMODE_TYPE_ALLに等しくてもよく、4:2:0クロマ・フォーマットについては、modeTypeは、MODE_TYPE_INTRAまたはMODE_TYPE_INTERのいずれかに等しくてもよい。
ｉ．水平BT分割を伴うM×N（たとえば8×8）符号化ツリー・ノード
ｉｉ．垂直BT分割を伴うM×N（たとえば16×4）符号化ツリー・ノード
ｉｉｉ．水平TT分割を伴うM×N（たとえば8×16）符号化ツリー・ノード
ｉｖ．垂直TT分割を伴うM×N（たとえば32×4）符号化ツリー・ノード。
ａ．一例では、以下の条件の1つが真の場合、この符号化ツリー・ノードによって分割された（サブ）ブロックのmodeTypeは、4:2:2クロマ・フォーマットについてはMODE_TYPE_ALLに等しくてもよく、4:2:0クロマ・フォーマットについては、modeTypeは、MODE_TYPE_INTRAまたはMODE_TYPE_INTERのいずれかに等しくてもよい。
ｉ．水平BT分割を伴うM×N（たとえば8×8）符号化ツリー・ノード
ｉｉ．垂直BT分割を伴うM×N（たとえば16×4）符号化ツリー・ノード
ｉｉｉ．水平TT分割を伴うM×N（たとえば8×16）符号化ツリー・ノード
ｉｖ．垂直TT分割を伴うM×N（たとえば32×4）符号化ツリー・ノード。
３．MODE_TYPE_INTRAの名前をMODE_TYPE_NO_INTERに変更し、MODE_INTERの使用を制限することが提案される。
ａ．一例では、符号化単位のmodeTypeがMODE_TYPE_NO_INTERに等しい場合、MODE_INTERは許容されない。
ａ．一例では、符号化単位のmodeTypeがMODE_TYPE_NO_INTERに等しい場合、MODE_INTERは許容されない。
４．MODE_TYPE_INTERの名前をMODE_TYPE_NO_INTRAに変更し、MODE_INTRAの使用を制限することが提案される。
ａ．一例では、符号化単位のmodeTypeがMODE_TYPE_NO_INTRAに等しい場合、MODE_INTRAは許容されない。
ａ．一例では、符号化単位のmodeTypeがMODE_TYPE_NO_INTRAに等しい場合、MODE_INTRAは許容されない。
５．モード制約条件フラグは、4:2:2および／または4:0:0および／または4:4:4クロマ・フォーマットにおいて信号伝達されることは決してなくてもよい。
ａ．一例では、モード制約条件フラグが存在しない場合、それは1に等しいと推定されてもよい。
ｉ．あるいはまた、モード制約条件フラグが存在しない場合、それは0に等しいと推定されてもよい。
ａ．一例では、モード制約条件フラグが存在しない場合、それは1に等しいと推定されてもよい。
ｉ．あるいはまた、モード制約条件フラグが存在しない場合、それは0に等しいと推定されてもよい。
６．Mをブロック幅、Nをブロック高さとしてM×N符号化ブロックにSCIPUを適用するかどうか、および／またはどのように適用するかは、色フォーマットが4:2:0であるか4:2:2であるかに依存してもよい。
ａ．一例では、4:2:2の色フォーマットでは、Mをブロック幅、Nをブロック高さとして、M×N符号化ブロックについて、MかけるN（M×Nで示される）が64または32に等しい場合にのみSCIPUが有効にされてもよい。
ｂ．一例では、M*N＝128の符号化ツリー・ノードは、4:2:2色フォーマットでは、決してSCIPUブロックとして扱われなくてもよい。
ｃ．一例では、BT分割およびM*N＝64をもつ符号化ツリー・ノードは、4:2:2色フォーマットでは、決してSCIPUブロックとして扱われなくてもよい。
ｄ．一例では、split_qt_flagが1に等しく、M*N＝64である符号化ツリー・ノードは、4:2:2色フォーマットでは、SCIPUブロックであってもよい。
ｅ．一例では、TT分割およびM*N＝64を有する符号化ツリー・ノードは、4:2:2色フォーマットではSCIPUブロックとして扱われてもよい。
ｆ．一例では、BT分割およびM*N＝32を有する符号化ツリー・ノードは、4:2:2色フォーマットでは、SCIPUブロックとして扱われてもよい。
ｇ．上記の記述において、4:2:2色フォーマットのSCIPUブロックについては、modeTypeConditionは常に1に等しくてもよい。
ｈ．上記の説明において、4:2:2色フォーマットのSCIPUブロックについては、親ノードの現在のブロックと子リーフノードの下のすべてのサブブロックの両方について、MODE_TYPE_INTRAのみが許容されてもよい。
ａ．一例では、4:2:2の色フォーマットでは、Mをブロック幅、Nをブロック高さとして、M×N符号化ブロックについて、MかけるN（M×Nで示される）が64または32に等しい場合にのみSCIPUが有効にされてもよい。
ｂ．一例では、M*N＝128の符号化ツリー・ノードは、4:2:2色フォーマットでは、決してSCIPUブロックとして扱われなくてもよい。
ｃ．一例では、BT分割およびM*N＝64をもつ符号化ツリー・ノードは、4:2:2色フォーマットでは、決してSCIPUブロックとして扱われなくてもよい。
ｄ．一例では、split_qt_flagが1に等しく、M*N＝64である符号化ツリー・ノードは、4:2:2色フォーマットでは、SCIPUブロックであってもよい。
ｅ．一例では、TT分割およびM*N＝64を有する符号化ツリー・ノードは、4:2:2色フォーマットではSCIPUブロックとして扱われてもよい。
ｆ．一例では、BT分割およびM*N＝32を有する符号化ツリー・ノードは、4:2:2色フォーマットでは、SCIPUブロックとして扱われてもよい。
ｇ．上記の記述において、4:2:2色フォーマットのSCIPUブロックについては、modeTypeConditionは常に1に等しくてもよい。
ｈ．上記の説明において、4:2:2色フォーマットのSCIPUブロックについては、親ノードの現在のブロックと子リーフノードの下のすべてのサブブロックの両方について、MODE_TYPE_INTRAのみが許容されてもよい。
７．4:2:2色フォーマットでは、SCIPUブロックのmodeTypeConditionは常に1に等しくてもよい。
ａ．一例では、modeTypeConditionは、4:2:2色フォーマットにちうて0または1に等しくてもよい。
ｂ．一例では、4:2:2色フォーマットのSCIPUブロックについて、modeTypeConditionは、決して2に等しくなくてもよい。
ａ．一例では、modeTypeConditionは、4:2:2色フォーマットにちうて0または1に等しくてもよい。
ｂ．一例では、4:2:2色フォーマットのSCIPUブロックについて、modeTypeConditionは、決して2に等しくなくてもよい。
８．4:2:2色フォーマットでは、SCIPUブロックのmodeTypeは常にMODE_TYPE_INTRAに等しくてもよい。
ａ．一例では、modeTypeは、4:2:2色フォーマットのMODE_TYPE_ALLまたはMODE_TYPE_INTRAと等しくてもよい。
ｂ．一例では、4:2:2色フォーマットのSCIPUブロックについては、MODE_TYPE_INTERは無効にされてもよい。
ａ．一例では、modeTypeは、4:2:2色フォーマットのMODE_TYPE_ALLまたはMODE_TYPE_INTRAと等しくてもよい。
ｂ．一例では、4:2:2色フォーマットのSCIPUブロックについては、MODE_TYPE_INTERは無効にされてもよい。
９．ブロック・パーティションが許可されるか否かは、modeTypeおよび／またはブロック・サイズに依存してもよい。
ａ．一例では、ブロックについてBTおよび／またはTT分割が許容されるかどうかは、modeTypeに依存してもよい。
ｉ．一例では、modeTypeがMODE_TYPE_INTERに等しい場合、現在の符号化ブロックについてBT分割は許容されなくてもよい（たとえば、allowBtSplitがfalseに等しく設定される）。
ｉｉ．一例では、modeTypeがMODE_TYPE_INTERに等しい場合、現在の符号化ブロックについてTT分割は許容されなくてもよい（たとえば、allowTtSplitがfalseに等しく設定される）。
ｂ．一例では、ブロックについてBTおよび／またはTT分割が許容されるかどうかは、modeTypeおよびブロック・サイズに依存してもよい。
ｉ．一例では、M×N符号化ブロックについては、Mをブロック幅、Nをブロック高さとして、M*Nが32以下であり、modeTypeがMODE_TYPE_INTERに等しい場合、BT分割は許容されなくてもよい（たとえば、allowBtSplitがfalseに設定される）。
ｉｉ．一例では、M×N符号化ブロックについては、Mをブロック幅、Nをブロック高さとし、M*Nが64以下であり、modeTypeがMODE_TYPE_INTERに等しい場合、TT分割は許容されなくてもよい（たとえば、allowTtSplitがfalseに設定される）。
ａ．一例では、ブロックについてBTおよび／またはTT分割が許容されるかどうかは、modeTypeに依存してもよい。
ｉ．一例では、modeTypeがMODE_TYPE_INTERに等しい場合、現在の符号化ブロックについてBT分割は許容されなくてもよい（たとえば、allowBtSplitがfalseに等しく設定される）。
ｉｉ．一例では、modeTypeがMODE_TYPE_INTERに等しい場合、現在の符号化ブロックについてTT分割は許容されなくてもよい（たとえば、allowTtSplitがfalseに等しく設定される）。
ｂ．一例では、ブロックについてBTおよび／またはTT分割が許容されるかどうかは、modeTypeおよびブロック・サイズに依存してもよい。
ｉ．一例では、M×N符号化ブロックについては、Mをブロック幅、Nをブロック高さとして、M*Nが32以下であり、modeTypeがMODE_TYPE_INTERに等しい場合、BT分割は許容されなくてもよい（たとえば、allowBtSplitがfalseに設定される）。
ｉｉ．一例では、M×N符号化ブロックについては、Mをブロック幅、Nをブロック高さとし、M*Nが64以下であり、modeTypeがMODE_TYPE_INTERに等しい場合、TT分割は許容されなくてもよい（たとえば、allowTtSplitがfalseに設定される）。
１０．符号化ツリーのmodeTypeCurrがMODE_TYPE_INTERに等しい場合、符号化ツリーの分割は制約されてもよい。
ａ．一例では、符号化ツリーのmodeTypeCurrがMODE_TYPE_INTERに等しい場合、BT分割は許容されなくてもよい。
ｂ．一例では、符号化ツリーのmodeTypeCurrがMODE_TYPE_INTERに等しい場合、TT分割は許容されなくてもよい。
ｃ．一例では、符号化ツリーのmodeTypeCurrがMODE_TYPE_INTERに等しい場合、QT分割は許容されなくてもよい。
ｄ．一例では、符号化ツリーのmodeTypeCurrがMODE_TYPE_INTERに等しく、ルーマ・ブロック・サイズが32以下の場合、BT分割は許容されなくてもよい。
ｅ．一例では、符号化ツリーのmodeTypeCurrがMODE_TYPE_INTERに等しく、ルーマ・ブロック・サイズが64以下の場合、TT分割は許容されなくてもよい。
ａ．一例では、符号化ツリーのmodeTypeCurrがMODE_TYPE_INTERに等しい場合、BT分割は許容されなくてもよい。
ｂ．一例では、符号化ツリーのmodeTypeCurrがMODE_TYPE_INTERに等しい場合、TT分割は許容されなくてもよい。
ｃ．一例では、符号化ツリーのmodeTypeCurrがMODE_TYPE_INTERに等しい場合、QT分割は許容されなくてもよい。
ｄ．一例では、符号化ツリーのmodeTypeCurrがMODE_TYPE_INTERに等しく、ルーマ・ブロック・サイズが32以下の場合、BT分割は許容されなくてもよい。
ｅ．一例では、符号化ツリーのmodeTypeCurrがMODE_TYPE_INTERに等しく、ルーマ・ブロック・サイズが64以下の場合、TT分割は許容されなくてもよい。
１１．treeTypeがDUAL_TREE_LUMAである符号化単位は、インター・モードで符号化されてもよい。
ａ．一例では、インター符号化モード、すなわちMODE_INTERで符号化された符号化単位は、複数の色成分をもつ色フォーマットの場合でも、ルーマ成分のみを含んでいてもよい。
ｂ．一例では、pred_mode_flagはDUAL_TREE_LUMAブロックについてパースされる必要があってもよい。
ｃ．一例では、インター・モードで符号化されたDUAL_TREE_LUMAブロックについて、SINGLE_TREEについてのインター・モードの同じ制約条件が適用されてもよい。
ｉ．一例では、4×4 DUAL_TREE_LUMAインターブロックは、許容されなくてもよい。
ａ．一例では、インター符号化モード、すなわちMODE_INTERで符号化された符号化単位は、複数の色成分をもつ色フォーマットの場合でも、ルーマ成分のみを含んでいてもよい。
ｂ．一例では、pred_mode_flagはDUAL_TREE_LUMAブロックについてパースされる必要があってもよい。
ｃ．一例では、インター・モードで符号化されたDUAL_TREE_LUMAブロックについて、SINGLE_TREEについてのインター・モードの同じ制約条件が適用されてもよい。
ｉ．一例では、4×4 DUAL_TREE_LUMAインターブロックは、許容されなくてもよい。
１２．ブロック幅がM（M＝2など）クロマ・サンプルに等しいクロマ・イントラ・ブロック（および／またはIBCブロック）は許容されなくてもよい。
ａ．一例では、2×N（N≦64など）クロマ・イントラ・ブロックは、デュアルツリーでは許容されなくてもよい。
ｉ．一例では、treeTypeがDUAL_TREE_CHROMAに等しく、ブロック幅が4クロマ・サンプルに等しい場合、垂直BT分割は無効にされてもよい。
ｉｉ．一例では、treeTypeがDUAL_TREE_CHROMAに等しく、ブロック幅が8クロマ・サンプルに等しい場合、垂直TT分割は無効にされてもよい。
ｂ．一例では、2×N（N≦64など）クロマ・イントラ（および／またはIBC）ブロックは、シングルツリーでは許容されなくてもよい。
ｉ．一例では、垂直BT分割を伴うM×N（たとえば、M=8およびN≦64）符号化ツリー・ノードについて、以下のプロセスの1つが適用されてもよい。
１．4×Nまたは4×（N/2）のクロマ・ブロックについては垂直BT分割は許容されないが、8×Nのルーマ・ブロックについては許容されるのでもよい。
２．4×Nまたは4×（N/2）クロマ・ブロックは、垂直BT分割ではなく、MODE_INTRAまたはMODE_IBCによって符号化されてもよい。
３．垂直BT分割は、8×Nルーマ・ブロックと4×Nまたは4×（N/2）クロマ・ブロックの両方について許容されるが、ルーマ・ブロックとクロマ・ブロックの両方はMODE_INTRAで符号化されないのでもよい（たとえば、MODE_INTERまたはMODE_IBCで符号化されてもよい）。
ｉｉ．一例では、垂直TT分割を伴うM×N（たとえば、M＝16およびN≦64）符号化ツリー・ノードについて、以下のプロセスの1つが適用されてもよい。
１．8×Nまたは8×（N/2）のクロマ・ブロックについては垂直TT分割は許容されないが、16×Nのルーマ・ブロックについては許容されるのでもよい。
２．8×Nまたは8×（N/2）クロマ・ブロックは、垂直TT分割ではなく、MODE_INTRAまたはMODE_IBCによって符号化されてもよい。
３．垂直TT分割は、16×Nルーマ・ブロックと8×Nまたは8×（N/2）クロマ・ブロックの両方について許容されるが、ルーマ・ブロックとクロマ・ブロックの両方はMODE_INTRAで符号化されないのでもよい（たとえば、MODE_INTERまたはMODE_IBCで符号化されてもよい）。
ａ．一例では、2×N（N≦64など）クロマ・イントラ・ブロックは、デュアルツリーでは許容されなくてもよい。
ｉ．一例では、treeTypeがDUAL_TREE_CHROMAに等しく、ブロック幅が4クロマ・サンプルに等しい場合、垂直BT分割は無効にされてもよい。
ｉｉ．一例では、treeTypeがDUAL_TREE_CHROMAに等しく、ブロック幅が8クロマ・サンプルに等しい場合、垂直TT分割は無効にされてもよい。
ｂ．一例では、2×N（N≦64など）クロマ・イントラ（および／またはIBC）ブロックは、シングルツリーでは許容されなくてもよい。
ｉ．一例では、垂直BT分割を伴うM×N（たとえば、M=8およびN≦64）符号化ツリー・ノードについて、以下のプロセスの1つが適用されてもよい。
１．4×Nまたは4×（N/2）のクロマ・ブロックについては垂直BT分割は許容されないが、8×Nのルーマ・ブロックについては許容されるのでもよい。
２．4×Nまたは4×（N/2）クロマ・ブロックは、垂直BT分割ではなく、MODE_INTRAまたはMODE_IBCによって符号化されてもよい。
３．垂直BT分割は、8×Nルーマ・ブロックと4×Nまたは4×（N/2）クロマ・ブロックの両方について許容されるが、ルーマ・ブロックとクロマ・ブロックの両方はMODE_INTRAで符号化されないのでもよい（たとえば、MODE_INTERまたはMODE_IBCで符号化されてもよい）。
ｉｉ．一例では、垂直TT分割を伴うM×N（たとえば、M＝16およびN≦64）符号化ツリー・ノードについて、以下のプロセスの1つが適用されてもよい。
１．8×Nまたは8×（N/2）のクロマ・ブロックについては垂直TT分割は許容されないが、16×Nのルーマ・ブロックについては許容されるのでもよい。
２．8×Nまたは8×（N/2）クロマ・ブロックは、垂直TT分割ではなく、MODE_INTRAまたはMODE_IBCによって符号化されてもよい。
３．垂直TT分割は、16×Nルーマ・ブロックと8×Nまたは8×（N/2）クロマ・ブロックの両方について許容されるが、ルーマ・ブロックとクロマ・ブロックの両方はMODE_INTRAで符号化されないのでもよい（たとえば、MODE_INTERまたはMODE_IBCで符号化されてもよい）。
１３．IBCモードは、小ブロック・サイズであるかどうかにかかわらず、ルーマおよび／またはクロマ・ブロックについて許容されてもよい。
ａ．一例では、modeTypeがMODE_TYPE_INTRAに等しい場合でも、8x4/8x8/16x4および4xN（N<=64など）のルーマ・ブロックを含むルーマ・ブロックについて、IBCモードが許容されてもよい。
ｂ．一例では、modeTypeがMODE_TYPE_INTRAに等しい場合でも、IBCモードはクロマ・ブロックについて許容されてもよい。
ａ．一例では、modeTypeがMODE_TYPE_INTRAに等しい場合でも、8x4/8x8/16x4および4xN（N<=64など）のルーマ・ブロックを含むルーマ・ブロックについて、IBCモードが許容されてもよい。
ｂ．一例では、modeTypeがMODE_TYPE_INTRAに等しい場合でも、IBCモードはクロマ・ブロックについて許容されてもよい。
１４．IBC予測モード・フラグの信号伝達は、予測モード・タイプ（たとえば、MODE_TYPE_INTRA）に依存してもよい。
ａ．一例では、非SKIPブロック（たとえば、スキップ・モードで符号化されない符号化ブロック）についてのIBC予測モード・フラグは、treeTypeがDUAL_TREE_CHROMAに等しくなく、かつmodeTypeがMODE_TYPE_INTRAに等しい場合に、明示的にビットストリームにおいて信号伝達されうる。
ａ．一例では、非SKIPブロック（たとえば、スキップ・モードで符号化されない符号化ブロック）についてのIBC予測モード・フラグは、treeTypeがDUAL_TREE_CHROMAに等しくなく、かつmodeTypeがMODE_TYPE_INTRAに等しい場合に、明示的にビットストリームにおいて信号伝達されうる。
１５．IBC予測モード・フラグは、CU SKIPフラグとモード・タイプ（たとえばmodeType）に依存して推定されうる。
ａ．一例では、現在のブロックがSKIPモードで符号化され（たとえば、cu_skip_flagが1に等しい）、modeTypeがMODE_TYPE_INTRAに等しい場合、IBC予測モード・フラグ（たとえば、pred_mode_ibc_flag）が1に等しいと推定されてもよい。
ａ．一例では、現在のブロックがSKIPモードで符号化され（たとえば、cu_skip_flagが1に等しい）、modeTypeがMODE_TYPE_INTRAに等しい場合、IBC予測モード・フラグ（たとえば、pred_mode_ibc_flag）が1に等しいと推定されてもよい。
１６．パレット・モード・フラグの明示的な信号伝達はmodeTypeに依存しなくてもよい。
ａ．一例では、パレット・モード・フラグ（たとえばpred_mode_plt_flag）信号伝達は、スライスタイプ、ブロック・サイズ、予測モードなどに依存しうるが、modeTypeは何であってもよい。
ｂ．一例では、modeTypeがMODE_TYPE_INTERまたはMODE_TYPE_INTRAに等しい場合、パレット・モード・フラグ（pred_mode_plt_flagなど）は0と推定される。
ａ．一例では、パレット・モード・フラグ（たとえばpred_mode_plt_flag）信号伝達は、スライスタイプ、ブロック・サイズ、予測モードなどに依存しうるが、modeTypeは何であってもよい。
ｂ．一例では、modeTypeがMODE_TYPE_INTERまたはMODE_TYPE_INTRAに等しい場合、パレット・モード・フラグ（pred_mode_plt_flagなど）は0と推定される。
１７．modeTypeがMODE_TYPE_INTERに等しい場合、IBCモードは使用することが許容されてもよい。
ａ．一例では、modeTypeがMODE_TYPE_INTRAに等しいとき、クロマIBCは許容されなくてもよい。
ｂ．一例では、modeTypeがMODE_TYPE_INTRAまたはMODE_TYPE_INTERに等しいとき、IBCモードは使用することが許容されうる。
ｃ．一例では、IBCモードは、modeTypeが何であるかに関係なく、使用することを許容されうる。
ｄ．一例では、1つのSCIPU内で、IBCおよびインター・モードが両方とも許容されてもよい。
ｅ．一例では、IBCクロマ・ブロックのサイズは、常に、対応するルーマ・ブロックのサイズに対応してもよい。
ｆ．一例では、modeTypeがMODE_TYPE_INTERに等しく、符号化単位サイズがルーマで4x4の場合、pred_mode_ibc_flagの信号伝達はスキップされ、pred_mode_ibc_flagは1に等しいと推定されうる。
ａ．一例では、modeTypeがMODE_TYPE_INTRAに等しいとき、クロマIBCは許容されなくてもよい。
ｂ．一例では、modeTypeがMODE_TYPE_INTRAまたはMODE_TYPE_INTERに等しいとき、IBCモードは使用することが許容されうる。
ｃ．一例では、IBCモードは、modeTypeが何であるかに関係なく、使用することを許容されうる。
ｄ．一例では、1つのSCIPU内で、IBCおよびインター・モードが両方とも許容されてもよい。
ｅ．一例では、IBCクロマ・ブロックのサイズは、常に、対応するルーマ・ブロックのサイズに対応してもよい。
ｆ．一例では、modeTypeがMODE_TYPE_INTERに等しく、符号化単位サイズがルーマで4x4の場合、pred_mode_ibc_flagの信号伝達はスキップされ、pred_mode_ibc_flagは1に等しいと推定されうる。
１８．modeTypeがMODE_TYPE_INTERの場合、パレット・モードは使用することを許容されうる。
ａ．一例では、modeTypeがMODE_TYPE_INTRAの場合、クロマパレットは許容されなくてもよい。
ｂ．一例では、modeTypeがMODE_TYPE_INTRAまたはMODE_TYPE_INTERに等しいとき、IBCモードは使用することを許容されなくてもよい。
ｃ．一例では、IBCモードは、modeTypeが何であるかに関係なく、使用を許容されてもよい。
ｄ．一例では、modeTypeがMODE_TYPE_INTRAまたはMODE_TYPE_INTERに等しいとき、パレット・モードは、使用を許容されてもよい。
ｅ．一例では、パレット・モードは、modeTypeが何であるかに関係なく、使用を許容されてもよい。
ｆ．一例では、1つのSCIPU内で、パレットおよびインター・モードの両方が許容されてもよい。
ｇ．一例では、1つのSCIPU内で、パレット、IBCおよびインター・モードがすべて許容されてもよい。
ｈ．一例では、パレットクロマ・ブロックのサイズは、対応するルーマ・ブロックのサイズに常に対応してもよい。
ｉ．一例では、modeTypeがMODE_TYPE_INTERに等しく、符号化単位サイズがルーマで4x4の場合、pred_mode_plt_flagの信号伝達はスキップされ、pred_mode_plt_flagは1に等しいと推定される。
ｊ．一例では、modeTypeがMODE_TYPE_INTERに等しく、符号化単位サイズがルーマで4×4の場合、現在の予測モードがIBCまたはパレットであるかどうかを示すために、1つのメッセージが送られてもよい。
ｋ．一例では、パレット・モードを有効／無効にするかどうかは、スライスタイプとmodeTypeに依存してもよい。
ｉ．一例では、MODE_TYPE_INTRAをもつIスライスについては、パレット・モードが有効にされてもよい。
ｉｉ．一例では、MODE_TYPE_INTERをもつP/Bスライスについては、パレット・モードが有効にされてもよい。
ａ．一例では、modeTypeがMODE_TYPE_INTRAの場合、クロマパレットは許容されなくてもよい。
ｂ．一例では、modeTypeがMODE_TYPE_INTRAまたはMODE_TYPE_INTERに等しいとき、IBCモードは使用することを許容されなくてもよい。
ｃ．一例では、IBCモードは、modeTypeが何であるかに関係なく、使用を許容されてもよい。
ｄ．一例では、modeTypeがMODE_TYPE_INTRAまたはMODE_TYPE_INTERに等しいとき、パレット・モードは、使用を許容されてもよい。
ｅ．一例では、パレット・モードは、modeTypeが何であるかに関係なく、使用を許容されてもよい。
ｆ．一例では、1つのSCIPU内で、パレットおよびインター・モードの両方が許容されてもよい。
ｇ．一例では、1つのSCIPU内で、パレット、IBCおよびインター・モードがすべて許容されてもよい。
ｈ．一例では、パレットクロマ・ブロックのサイズは、対応するルーマ・ブロックのサイズに常に対応してもよい。
ｉ．一例では、modeTypeがMODE_TYPE_INTERに等しく、符号化単位サイズがルーマで4x4の場合、pred_mode_plt_flagの信号伝達はスキップされ、pred_mode_plt_flagは1に等しいと推定される。
ｊ．一例では、modeTypeがMODE_TYPE_INTERに等しく、符号化単位サイズがルーマで4×4の場合、現在の予測モードがIBCまたはパレットであるかどうかを示すために、1つのメッセージが送られてもよい。
ｋ．一例では、パレット・モードを有効／無効にするかどうかは、スライスタイプとmodeTypeに依存してもよい。
ｉ．一例では、MODE_TYPE_INTRAをもつIスライスについては、パレット・モードが有効にされてもよい。
ｉｉ．一例では、MODE_TYPE_INTERをもつP/Bスライスについては、パレット・モードが有効にされてもよい。
１９．パレット・モードを有効にされている場合、ローカルデュアルツリーは許容されなくてもよい。
ａ．一例では、パレット・モードが有効にされている場合、modeTypeConditionは常に0に設定されてもよい。
ａ．一例では、パレット・モードが有効にされている場合、modeTypeConditionは常に0に設定されてもよい。
２０．幅がMに等しい（たとえば、M＝2）または高さがNに等しい（たとえば、N＝2）小クロマ・ブロックについて、許容されるイントラ予測モードは、大きなクロマ・ブロックについて許容されるものとは異なるよう、制約されてもよい。
ａ．一例では、利用可能なクロマ・イントラ予測モードのイントラ予測モードのサブセットのみが使用されてもよい。
ｂ．一例では、INTRA_DCモードのみが使用されてもよい。
ｃ．一例では、INTRA_PLANARモードのみが使用されてもよい。
ｄ．一例では、INTRA_ANGULAR18モードのみが使用されてもよい。
ｅ．一例では、INTRA_ANGULAR50モードのみが使用されてもよい。
ｆ．一例では、CCLMモードが許容されなくてもよい。
ａ．一例では、利用可能なクロマ・イントラ予測モードのイントラ予測モードのサブセットのみが使用されてもよい。
ｂ．一例では、INTRA_DCモードのみが使用されてもよい。
ｃ．一例では、INTRA_PLANARモードのみが使用されてもよい。
ｄ．一例では、INTRA_ANGULAR18モードのみが使用されてもよい。
ｅ．一例では、INTRA_ANGULAR50モードのみが使用されてもよい。
ｆ．一例では、CCLMモードが許容されなくてもよい。
２１．幅がMに等しい（たとえば、M＝2）小さなクロマ・ブロックまたは高さがNに等しい（たとえば、N＝2）小さなクロマ・ブロックについては、変換タイプは大きなクロマ・ブロックについて許容されるものとは異なるように、制約されてもよい。
ａ．一例では、変換スキップのみが使用されてもよい。
ｂ．一例では、一次元変換のみが使用されてもよい。
ｃ．一例では、複数のタイプの変換をサポートする符号化ツールは許容されない。
ｉ．あるいはまた、複数のタイプの変換をサポートする符号化ツールの信号伝達は省略される。
ａ．一例では、変換スキップのみが使用されてもよい。
ｂ．一例では、一次元変換のみが使用されてもよい。
ｃ．一例では、複数のタイプの変換をサポートする符号化ツールは許容されない。
ｉ．あるいはまた、複数のタイプの変換をサポートする符号化ツールの信号伝達は省略される。
２２．CIIPはMODE_TYPE_INTRAとみなされてもよい。
ａ．一例では、CIIPモードは、デュアルツリー分割が使用される場合に許容されてもよい。
ｉ．一例では、CIIPモードは、CUタイプがDUAL_TREEE_CHROMAの場合、許容されてもよい。
ｂ．あるいはまた、CIIPは、MODE_TYPE_INTERとみなされてもよい。
ｉ．一例では、クロマ・ブロック幅がMに等しい場合（たとえば、M＝2）、CIIPモードは許容されなくてもよい。
ｉｉ．一例では、クロマ・ブロック幅がMに等しい場合（たとえば、M=2）、CIIPにおけるクロマについてのイントラ予測モードは、単純なイントラ予測モードに制限されてもよい。
１．一例では、クロマ・ブロック幅がMに等しい場合（たとえば、M＝2）、INTRA_DCがクロマ・イントラ予測のために使用されてもよい。
２．一例では、クロマ・ブロック幅がMに等しい場合（たとえば、M＝2）、INTRA_ANGULAR18がクロマ・イントラ予測のために使用されてもよい。
３．一例では、クロマ・ブロック幅がMに等しい場合（たとえば、M＝2）、INTRA_ANGULAR50がクロマ・イントラ予測のために使用されてもよい。
ｉｉｉ．一例では、CIIPにおけるクロマのためのイントラ予測モードは、単純なイントラ予測モードに制限されてもよい。
１．一例では、INTRA_DCは、クロマ・イントラ予測のために使用されてもよい。
２．一例では、INTRA_ANGULAR18モードは、クロマ・イントラ予測のために使用されてもよい。
３．一例では、INTRA_ANGULAR50モードは、クロマ・イントラ予測のために使用されてもよい。
ａ．一例では、CIIPモードは、デュアルツリー分割が使用される場合に許容されてもよい。
ｉ．一例では、CIIPモードは、CUタイプがDUAL_TREEE_CHROMAの場合、許容されてもよい。
ｂ．あるいはまた、CIIPは、MODE_TYPE_INTERとみなされてもよい。
ｉ．一例では、クロマ・ブロック幅がMに等しい場合（たとえば、M＝2）、CIIPモードは許容されなくてもよい。
ｉｉ．一例では、クロマ・ブロック幅がMに等しい場合（たとえば、M=2）、CIIPにおけるクロマについてのイントラ予測モードは、単純なイントラ予測モードに制限されてもよい。
１．一例では、クロマ・ブロック幅がMに等しい場合（たとえば、M＝2）、INTRA_DCがクロマ・イントラ予測のために使用されてもよい。
２．一例では、クロマ・ブロック幅がMに等しい場合（たとえば、M＝2）、INTRA_ANGULAR18がクロマ・イントラ予測のために使用されてもよい。
３．一例では、クロマ・ブロック幅がMに等しい場合（たとえば、M＝2）、INTRA_ANGULAR50がクロマ・イントラ予測のために使用されてもよい。
ｉｉｉ．一例では、CIIPにおけるクロマのためのイントラ予測モードは、単純なイントラ予測モードに制限されてもよい。
１．一例では、INTRA_DCは、クロマ・イントラ予測のために使用されてもよい。
２．一例では、INTRA_ANGULAR18モードは、クロマ・イントラ予測のために使用されてもよい。
３．一例では、INTRA_ANGULAR50モードは、クロマ・イントラ予測のために使用されてもよい。
２３．上記の諸項目について、変数Mおよび／またはNは事前に定義されてもよいし、信号伝達されてもよい。
ａ．一例では、Mおよび／またはNは、色フォーマット（たとえば、4:2:0、4:2:2、4:4:4）にさらに依存してもよい。
ａ．一例では、Mおよび／またはNは、色フォーマット（たとえば、4:2:0、4:2:2、4:4:4）にさらに依存してもよい。
２４．modeTypeはより多くのタイプをカバーするように拡張されてもよい。
ａ．一例では、modeTypeはMODE_TYPE_IBCであってもよい。modeTypeがMODE_TYPE_IBCに等しい場合、予測モードはIBCと推定される。
ｉ．一例では、pred_mode_flagは、この場合、信号伝達されない。
ｉｉ．一例では、pred_mode_ibc_flagは、この場合、信号伝達されない。
ｉｉｉ．一例では、pred_mode_plt_flagは、この場合、信号伝達されない。
ｂ．一例では、modeTypeはMODE_TYPE_PALETTEであってもよい。modeTypeがMODE_TYPE_PALETTEに等しい場合、予測モードはパレット・モードであると推定される。
ｉ．一例では、pred_mode_flagは、この場合、信号伝達されない。
ｉｉ．一例では、pred_mode_ibc_flagは、この場合に、信号伝達されない。
ｉｉｉ．一例では、pred_mode_plt_flagは、この場合、信号伝達されない。
ｃ．一例では、mode_constraint_flagは、許容されるmodeTypeのどれが使われるかを示すために、インデックスで置き換えられてもよい。
ａ．一例では、modeTypeはMODE_TYPE_IBCであってもよい。modeTypeがMODE_TYPE_IBCに等しい場合、予測モードはIBCと推定される。
ｉ．一例では、pred_mode_flagは、この場合、信号伝達されない。
ｉｉ．一例では、pred_mode_ibc_flagは、この場合、信号伝達されない。
ｉｉｉ．一例では、pred_mode_plt_flagは、この場合、信号伝達されない。
ｂ．一例では、modeTypeはMODE_TYPE_PALETTEであってもよい。modeTypeがMODE_TYPE_PALETTEに等しい場合、予測モードはパレット・モードであると推定される。
ｉ．一例では、pred_mode_flagは、この場合、信号伝達されない。
ｉｉ．一例では、pred_mode_ibc_flagは、この場合に、信号伝達されない。
ｉｉｉ．一例では、pred_mode_plt_flagは、この場合、信号伝達されない。
ｃ．一例では、mode_constraint_flagは、許容されるmodeTypeのどれが使われるかを示すために、インデックスで置き換えられてもよい。
２５．一例では、寸法W×HのブロックについてQT分割が許容されるかどうかは、寸法と組み合わされたmodeTypeに依存しうる。
ａ．たとえば、modeTypeがMODE_TYPE_INTERに等しく、Wが8に等しく、Hが8に等しい場合、QTスピットは許容されない。
ａ．たとえば、modeTypeがMODE_TYPE_INTERに等しく、Wが8に等しく、Hが8に等しい場合、QTスピットは許容されない。
２６．一例では、寸法W×Hのブロックについて垂直TT分割が許容されるかどうかは、寸法と組み合わされたmodeTypeに依存しうる。
ａ．たとえば、modeTypeがMODE_TYPE_INTERに等しく、Wが16に等しく、Hが4に等しい場合、垂直TTスピットは許容されない。
ａ．たとえば、modeTypeがMODE_TYPE_INTERに等しく、Wが16に等しく、Hが4に等しい場合、垂直TTスピットは許容されない。
２７．一例では、寸法W×Hのブロックについて水平方向のTT分割が許容されるかどうかは、寸法と組み合わされたmodeTypeに依存しうる。
ａ．たとえば、modeTypeがMODE_TYPE_INTERに等しく、Wが4に等しく、Hが16に等しい場合、水平TT分割は許容されない。
ａ．たとえば、modeTypeがMODE_TYPE_INTERに等しく、Wが4に等しく、Hが16に等しい場合、水平TT分割は許容されない。
２８．一例では、寸法W×Hのブロックについて垂直BT分割が許容されるかどうかは、寸法と組み合わされたmodeTypeに依存しうる。
ａ．たとえば、modeTypeがMODE_TYPE_INTERに等しく、Wが8に等しく、Hが4に等しい場合、垂直BT分割は許容されない。
ａ．たとえば、modeTypeがMODE_TYPE_INTERに等しく、Wが8に等しく、Hが4に等しい場合、垂直BT分割は許容されない。
２９．一例では、寸法W×Hのブロックについて水平方向のTT分割が許容されるかどうかは、寸法と組み合わされたmodeTypeに依存しうる。
ａ．たとえば、modeTypeがMODE_TYPE_INTERに等しく、Wが4に等しく、Hが8に等しい場合、水平BT分割は許容されない。
ａ．たとえば、modeTypeがMODE_TYPE_INTERに等しく、Wが4に等しく、Hが8に等しい場合、水平BT分割は許容されない。
３０．一例では、CUの予測モードがmodeTypeによって推定されるかどうかは、色成分および／またはブロック寸法W×Hに依存しうる。
ａ．たとえば、クロマCUの予測モードはmodeTypeによって推定されるが、ルーマCUの予測モードはmodeTypeによって推定されるのではなく、信号伝達される。
ｉ．たとえば、ルーマCUの予測モードは、もしW>4かH>4なら、modeTypeによって推定されるのではなく、信号伝達される。
ａ．たとえば、クロマCUの予測モードはmodeTypeによって推定されるが、ルーマCUの予測モードはmodeTypeによって推定されるのではなく、信号伝達される。
ｉ．たとえば、ルーマCUの予測モードは、もしW>4かH>4なら、modeTypeによって推定されるのではなく、信号伝達される。
３１．SCIPUが適用される場合、第1の成分のデルタQPに関連する情報を信号伝達するかどうか、および／または、どのように信号伝達するかは、第1の成分の分割の仕方に依存しうる。
ａ．一例では、SCIPUが適用される場合、第1の成分のデルタQPに関連する情報を信号伝達するかどうか、および／またはどのように信号伝達するかは、第1の成分の分割の仕方に依存してもよいく、第2の成分の分割の仕方からは分離しうる。
ｂ．一例では、第一の成分はルーマであり、第二の成分はクロマである。
ｃ．一例では、第一の成分はクロマであり、第二の成分はルーマである。
ａ．一例では、SCIPUが適用される場合、第1の成分のデルタQPに関連する情報を信号伝達するかどうか、および／またはどのように信号伝達するかは、第1の成分の分割の仕方に依存してもよいく、第2の成分の分割の仕方からは分離しうる。
ｂ．一例では、第一の成分はルーマであり、第二の成分はクロマである。
ｃ．一例では、第一の成分はクロマであり、第二の成分はルーマである。
３２．デュアルツリーおよび／またはローカルデュアルツリー符号化構造が適用されるとき、第1の成分のデルタQPに関連するいかなる変数も、第2の成分のデコードまたはパース・プロセス中に修正されることができない。
ａ．一例では、ローカルデュアルツリー符号化構造は、SCIPUに従って使用されうる。
ｂ．一例では、第1の成分はルーマであり、第2の成分はクロマである。
ｉ．前記変数はIsCuQpDeltaCodedであってもよい。
ｃ．一例では、第1の成分はクロマであり、第2の成分はルーマである。
ｉ．前記変数はIsCuChromaQpOffsetCodedであってもよい。
ａ．一例では、ローカルデュアルツリー符号化構造は、SCIPUに従って使用されうる。
ｂ．一例では、第1の成分はルーマであり、第2の成分はクロマである。
ｉ．前記変数はIsCuQpDeltaCodedであってもよい。
ｃ．一例では、第1の成分はクロマであり、第2の成分はルーマである。
ｉ．前記変数はIsCuChromaQpOffsetCodedであってもよい。
３３．SCIPUが適用される場合、ある成分（ルーマまたはクロマなど）のデルタQPに関連する情報は、
ルーマ成分とクロマ成分が同じモード・タイプ（MODE_TYPE_INTERまたはMODE_TYPE_INTRAなど）を共有することが必要とされる特定の領域において、高々一度、信号伝達されてもよい。
ａ．一例では、特定の領域は、量子化グループと見なされる。
ルーマ成分とクロマ成分が同じモード・タイプ（MODE_TYPE_INTERまたはMODE_TYPE_INTRAなど）を共有することが必要とされる特定の領域において、高々一度、信号伝達されてもよい。
ａ．一例では、特定の領域は、量子化グループと見なされる。
３４．ブロック幅がM、ブロック高さがNのM×Nクロマ・イントラ・ブロックは許容されなくてもよい。
ａ．一例では、DC予測は、M×Nクロマ・イントラ予測について使用されうる。たとえば、M＝2個のクロマ・サンプル、N＝8および／または16および／または32個のクロマ・サンプルである。
ｉ．一例では、再構成された近傍ピクセルは、DC予測のために使用されなくてもよい。
ｉｉ．一例では、近傍参照ピクセルは、DC予測のために1<<（bitDepth－1）に等しく設定されてもよい。
ｉｉｉ．一例では、PDPCは、DC予測のために適用されなくてもよい。
ｉｖ．一例では、DCモード情報は、M×Nクロマ・イントラ・ブロックについて符号化されず、導出されてもよい。
ｂ．一例では、CCLM予測は、M×Nクロマ・イントラ予測のために使用されてもよい。たとえば、M＝2クロマ・サンプルであり、N＝8および／または16および／または32クロマ・サンプルである。
ｉ．一例では、再構成された近傍ピクセルはCCLM予測について使用されなくてもよい。
ｉｉ．一例では、CCLM予測predC＝a*recL＋bであり、クロマ予測値predCがルーマ再構成値recLから導出される場合、パラメータaおよびbは、SPS/VPS/PPS/PPS/ピクチャー/サブピクチャー/スライス/タイル/ブリック/CTU行/CTU/VPDU/CU/PU/TUなどのビデオ単位の先頭のデフォルトの固定値（a＝0、b＝512など）に初期化されてもよい。
１．一例では、CCLMパラメータaおよびbを更新するために、先入れ先出しテーブルがオンザフライで維持されてもよい。
ｉｉｉ．一例では、PDPCがCCLM予測に適用されなくてもよい。
ｉｖ．一例では、CCLMモード情報は、M×Nクロマ・イントラ・ブロックについて符号化されず、導出されてもよい。
ｖ．あるいはまた、提案される方法は、幅がMに等しくない、または高さがNに等しくない他の種類のCCLM符号化クロマ・ブロックに適用されてもよい。
１．一例では、前に符号化されたブロックのCCLMパラメータは、現在のブロックの近傍ブロックの再構成情報に基づいて導出される代わりに、現在のブロックのために利用されてもよい。
２．一例では、CCLMパラメータは、テーブルに格納され、FIFOを使用するなどしてオンザフライで更新されてもよい。
ｃ．一例では、M×Nクロマ・イントラ・ブロックは、デュアルツリーでは許容されなくてもよく、たとえば、M＝2クロマ・サンプル、N＝8および／または16および／または32クロマ・サンプルである。
ｉ．一例では、treeTypeがDUAL_TREE_CHROMAに等しい場合、X分割は、（M*a）×（N*b）に等しい寸法をもつ符号化ツリー・ノードについて無効にされてもよい。ここで、M*aは、クロマ・サンプル単位での符号化ツリー・ノードの幅であり、N*bは、クロマ・サンプル単位での符号化ツリー・ノードの高さである。
１．一例では、Xは垂直BT分割であり、a＝2、b＝1である。
２．一例では、Xは水平BT分割であり、a＝1、b＝2である。
３．一例では、Xは垂直TT分割であり、a＝4、b＝1である。
４．一例では、Xは水平方向のTT分割であり、a＝1、b＝4である。
ｄ．一例では、M×Nクロマ・イントラ・ブロックは、シングルツリーでは許容されなくてもよく、たとえば、M＝2クロマ・サンプル、N＝8および／または16および／または32クロマ・サンプルである。
ｉ．一例では、シングルツリーにおいて、X分割は、（M*a*subWidthC）×（N*b*subHeightC）に等しい寸法をもつ符号化ツリー・ノードのクロマ成分について無効化されてもよい。ここで、M*aは、ルーマ・サンプル単位での符号化ツリー・ノードの幅であり、N*bは、ルーマ・サンプル単位での符号化ツリー・ノードの高さであり、subWidthCおよびsubHeightCは、幅および高さの寸法におけるクロマ・サブサンプリング比であり、たとえば、subWidthCおよびsubHeightCは、4:2:0クロマ・フォーマットについては2に等しい。
１．一例では、X＝垂直BT分割であり、a＝2、b＝1
２．一例では、X＝垂直TT分割であり、a＝4、b＝1
３．一例では、X＝水平BT分割であり、a＝1、b＝2
４．一例では、X＝水平TT分割であり、a＝1、b＝2
５．一例では、X＝水平TT分割であり、a＝1、b＝4
６．一例では、非分割クロマ・ブロックは、（M*a）×（N*d）に等しい寸法を有することができる。
７．一例では、非分割クロマ・ブロックは、MODE_TYPE_INTRAとして決定されてもよく、このクロマ・ブロックについては、イントラ予測（および／またはIBCおよび／またはPLTモード）のみが許容されてもよい。
８．一例では、X分割は、この符号化ツリー・ノードのルーマ成分について許容されてもよく、たとえば、ルーマ符号化ツリー・ノードは、さらに複数のルーマ子ノードに分割されてもよく、各ルーマ子ノードは、MODE_TYPE_INTERに決定されてもよい。この間、インター予測（および／またはIBCモード）のみが許容されてもよい。
９．あるいはまた、クロマ成分は、共位置のルーマ成分とともにさらに分割されてもよいが、モード・タイプは、MODE_TYPE_INTERと等しくてもよく、インター予測（および／またはIBCモード）のみが許容されてもよい。
ｉｉ．一例では、M×Nクロマ・イントラ・ブロックは、CIIPでは許容されない。
１．一例では、ルーマ・サンプル単位での（M*subWidthC）×（N*subHeightC）に等しい寸法をもつ符号化ブロックについてCIIPが許容されなくてもよい。
ａ）CIIPが許容されない場合、CIIPフラグなどの関連する構文要素は、ビットストリームにおいて符号化されなくてもよい。
２．一例では、CIIPにおけるクロマ混合プロセスは、インター部からの予測で満たされるだけでもよい。
ａ）一例では、ルーマ・イントラ予測のみがCIIP符号化ブロックに適用されることができ、一方、クロマ・イントラ予測は、ルーマ・サンプル単位での（M*subWidthC）×（N*subHeightC）に等しい寸法をもつCIIP符号化ブロックには適用されなくてもよい。
３．一例では、DC予測は、項目34（a）に記載されているように、CIIPブロックについてのM×Nクロマ・イントラ予測に使用されてもよい。
４．一例では、CCLM予測は、項目34（b）に記載されているように、CIIPブロックについてのM×Nクロマ・イントラ予測に使用されてもよい。
ａ．一例では、DC予測は、M×Nクロマ・イントラ予測について使用されうる。たとえば、M＝2個のクロマ・サンプル、N＝8および／または16および／または32個のクロマ・サンプルである。
ｉ．一例では、再構成された近傍ピクセルは、DC予測のために使用されなくてもよい。
ｉｉ．一例では、近傍参照ピクセルは、DC予測のために1<<（bitDepth－1）に等しく設定されてもよい。
ｉｉｉ．一例では、PDPCは、DC予測のために適用されなくてもよい。
ｉｖ．一例では、DCモード情報は、M×Nクロマ・イントラ・ブロックについて符号化されず、導出されてもよい。
ｂ．一例では、CCLM予測は、M×Nクロマ・イントラ予測のために使用されてもよい。たとえば、M＝2クロマ・サンプルであり、N＝8および／または16および／または32クロマ・サンプルである。
ｉ．一例では、再構成された近傍ピクセルはCCLM予測について使用されなくてもよい。
ｉｉ．一例では、CCLM予測predC＝a*recL＋bであり、クロマ予測値predCがルーマ再構成値recLから導出される場合、パラメータaおよびbは、SPS/VPS/PPS/PPS/ピクチャー/サブピクチャー/スライス/タイル/ブリック/CTU行/CTU/VPDU/CU/PU/TUなどのビデオ単位の先頭のデフォルトの固定値（a＝0、b＝512など）に初期化されてもよい。
１．一例では、CCLMパラメータaおよびbを更新するために、先入れ先出しテーブルがオンザフライで維持されてもよい。
ｉｉｉ．一例では、PDPCがCCLM予測に適用されなくてもよい。
ｉｖ．一例では、CCLMモード情報は、M×Nクロマ・イントラ・ブロックについて符号化されず、導出されてもよい。
ｖ．あるいはまた、提案される方法は、幅がMに等しくない、または高さがNに等しくない他の種類のCCLM符号化クロマ・ブロックに適用されてもよい。
１．一例では、前に符号化されたブロックのCCLMパラメータは、現在のブロックの近傍ブロックの再構成情報に基づいて導出される代わりに、現在のブロックのために利用されてもよい。
２．一例では、CCLMパラメータは、テーブルに格納され、FIFOを使用するなどしてオンザフライで更新されてもよい。
ｃ．一例では、M×Nクロマ・イントラ・ブロックは、デュアルツリーでは許容されなくてもよく、たとえば、M＝2クロマ・サンプル、N＝8および／または16および／または32クロマ・サンプルである。
ｉ．一例では、treeTypeがDUAL_TREE_CHROMAに等しい場合、X分割は、（M*a）×（N*b）に等しい寸法をもつ符号化ツリー・ノードについて無効にされてもよい。ここで、M*aは、クロマ・サンプル単位での符号化ツリー・ノードの幅であり、N*bは、クロマ・サンプル単位での符号化ツリー・ノードの高さである。
１．一例では、Xは垂直BT分割であり、a＝2、b＝1である。
２．一例では、Xは水平BT分割であり、a＝1、b＝2である。
３．一例では、Xは垂直TT分割であり、a＝4、b＝1である。
４．一例では、Xは水平方向のTT分割であり、a＝1、b＝4である。
ｄ．一例では、M×Nクロマ・イントラ・ブロックは、シングルツリーでは許容されなくてもよく、たとえば、M＝2クロマ・サンプル、N＝8および／または16および／または32クロマ・サンプルである。
ｉ．一例では、シングルツリーにおいて、X分割は、（M*a*subWidthC）×（N*b*subHeightC）に等しい寸法をもつ符号化ツリー・ノードのクロマ成分について無効化されてもよい。ここで、M*aは、ルーマ・サンプル単位での符号化ツリー・ノードの幅であり、N*bは、ルーマ・サンプル単位での符号化ツリー・ノードの高さであり、subWidthCおよびsubHeightCは、幅および高さの寸法におけるクロマ・サブサンプリング比であり、たとえば、subWidthCおよびsubHeightCは、4:2:0クロマ・フォーマットについては2に等しい。
１．一例では、X＝垂直BT分割であり、a＝2、b＝1
２．一例では、X＝垂直TT分割であり、a＝4、b＝1
３．一例では、X＝水平BT分割であり、a＝1、b＝2
４．一例では、X＝水平TT分割であり、a＝1、b＝2
５．一例では、X＝水平TT分割であり、a＝1、b＝4
６．一例では、非分割クロマ・ブロックは、（M*a）×（N*d）に等しい寸法を有することができる。
７．一例では、非分割クロマ・ブロックは、MODE_TYPE_INTRAとして決定されてもよく、このクロマ・ブロックについては、イントラ予測（および／またはIBCおよび／またはPLTモード）のみが許容されてもよい。
８．一例では、X分割は、この符号化ツリー・ノードのルーマ成分について許容されてもよく、たとえば、ルーマ符号化ツリー・ノードは、さらに複数のルーマ子ノードに分割されてもよく、各ルーマ子ノードは、MODE_TYPE_INTERに決定されてもよい。この間、インター予測（および／またはIBCモード）のみが許容されてもよい。
９．あるいはまた、クロマ成分は、共位置のルーマ成分とともにさらに分割されてもよいが、モード・タイプは、MODE_TYPE_INTERと等しくてもよく、インター予測（および／またはIBCモード）のみが許容されてもよい。
ｉｉ．一例では、M×Nクロマ・イントラ・ブロックは、CIIPでは許容されない。
１．一例では、ルーマ・サンプル単位での（M*subWidthC）×（N*subHeightC）に等しい寸法をもつ符号化ブロックについてCIIPが許容されなくてもよい。
ａ）CIIPが許容されない場合、CIIPフラグなどの関連する構文要素は、ビットストリームにおいて符号化されなくてもよい。
２．一例では、CIIPにおけるクロマ混合プロセスは、インター部からの予測で満たされるだけでもよい。
ａ）一例では、ルーマ・イントラ予測のみがCIIP符号化ブロックに適用されることができ、一方、クロマ・イントラ予測は、ルーマ・サンプル単位での（M*subWidthC）×（N*subHeightC）に等しい寸法をもつCIIP符号化ブロックには適用されなくてもよい。
３．一例では、DC予測は、項目34（a）に記載されているように、CIIPブロックについてのM×Nクロマ・イントラ予測に使用されてもよい。
４．一例では、CCLM予測は、項目34（b）に記載されているように、CIIPブロックについてのM×Nクロマ・イントラ予測に使用されてもよい。
losslessSizeYとmaxCTB/maxTBsize/maxTSサイズとの間の関係
３５．最大変換サイズは、可逆（および／または可逆符号化に近い）および不可逆符号化について、異なる仕方で信号伝達および／または推定されうる。
ａ．一例では、可逆符号化および／またはほぼ可逆符号化のための最大変換サイズは、変換には関わらないので、「最大残差サイズ」または「最大表現サイズ」のような他の用語で称されてもよい。本開示においては、それは「maxLosslessTbSizeY」と称されることがある。
ｂ．一例では、ブロックについての可逆符号化は、そのブロックについてのcu_transquant_bypass_flagが1に等しいということができる。
ｃ．一例では、ブロックについてのほぼ可逆的な符号化は、所与の閾値よりも小さいQPをもつ符号化ということができる。
ｉ．一例では、閾値は、DPS/VPS/SPS/PPS/タイル/スライス/ブリックヘッダにおいて示されてもよい。
ｄ．一例では、ブロックについてのほぼ可逆的な符号化は、所与の閾値より小さいQPをもつ符号化ということができ、transform_skip_flagは、そのブロックについて1に等しい。
ｉ．一例では、閾値は、DPS/VPS/SPS/PPS/タイル/スライス/ブリックヘッダで示されてもよい。
ｅ．可逆符号化および／またはほぼ可逆符号化のための第1の最大変換サイズ（たとえば、maxLosslessTbSizeY）は、不可逆符号化のために使用されうる第2の最大変換サイズ、および／または最大符号化ツリー単位サイズ、および／または、最大変換スキップサイズを条件として設定されてもよい。
ｆ．可逆および／またはほぼ可逆符号化のための最大変換サイズは、SPS/VPS/PPS/サブピクチャー/スライス/タイル/ブリック/CTU/VPDUにおける構文要素（SE）のようなビデオ単位レベルで信号伝達されてもよい。
ｉ．一例では、SEは、最大CTBサイズ（たとえば、log2_ctu_size_minus5、CtbSizeYなど）に依存して信号伝達されうる。
１．たとえば、フラグは、log2_ctu_size_minus5がN（たとえばN＝0）より大きい場合に信号伝達されうる。
ｉｉ．一例では、SEは、最大変換サイズ（たとえば、sps_max_luma_transform_size_64_flag、MaxTbSizeなど）に依存して信号伝達されてもよい。
１．たとえば、SEは、sps_max_luma_transform_size_64_flagがMに等しい場合（たとえばM＝1）に信号伝達されうる。
ｉｉｉ．一例では、SEは、最大変換スキップサイズ（たとえば、log2_transform_skip_max_size_minus2、MaxTsSizeなど）に依存して、信号伝達されうる。
１．たとえば、SEは、log2_transform_skip_max_size_minus2がKより大きい場合（たとえばK＝3）、信号伝達されうる。
ｉｖ．一例では、log（maxLosslessTbSizeY）とXとの間のデルタ値は、信号伝達されてもよい。
１．たとえば、Xはlog2_ctu_size_minus5に等しくてもよい。
２．たとえば、Xはsps_max_luma_transform_size_64_flagと等しくてもよい。
３．たとえば、Xはlog2_transform_skip_max_size_minus2と等しくてもよい。
４．たとえば、Xは固定した整数に等しくてもよい。
５．一例では、デルタ－Kが信号伝達されてもよい。ここで、Kは、1のような整数である。
ｖ．一例では、maxLosslessTbSizeYとXとの間のデルタ値が信号伝達されてもよい。
１．たとえば、XはCtbSizeYと等しくてもよい
２．たとえば、XはMaxTbSizeと等しくてもよい
３．たとえば、XはMaxTsSizeと等しくてもよい
４．たとえば、Xは固定した整数に等しくてもよい
５．一例では、デルタ－Kが信号伝達されてもよい。ここで、Kは、1のような整数である。
ｖｉ．一例では、ビデオ単位のmaxLosslessTbSizeY（シーケンス/ピクチャー/サブピクチャー/スライス/タイル/CTU/VPDU/CU/PU/TUなど）は、SEから導出されてもよい。
ｖｉｉ．SEはフラグであってもよい。
ｖｉｉｉ．フラグが存在しない場合、それは、正の整数Nに等しいと推定されうる。
ｇ．一例では、可逆および／またはほぼ可逆符号化がビデオ単位に適用される（たとえばcu_transquant_bypass_flagが1に等しい）場合、ビデオ単位についての最大変換サイズはmaxTbSizeY以外のmaxLosslessTbSizeYに等しく設定されてもよい。
ｈ．あるいはまた、ビデオ単位についての可逆符号化および／またはほぼ可逆符号化のための最大変換サイズ（たとえば、シーケンス/ピクチャー/サブピクチャー/スライス/タイル/CTU/VPDU/CU/PU/TU）は、信号伝達される代わりに導出されてもよい。
ｉ．たとえば、それは、固定した整数値M（ルーマ・サンプル単位でM＝32など）に等しく設定されてもよい。
ｉｉ．たとえば、それは、不可逆符号化のために使用されうる第2の最大変換サイズに等しく設定されてもよい。
ｉｉｉ．たとえば、それは、最大符号化ツリー単位サイズに等しく設定されてもよい。
ｉｖ．たとえば、それは、VPDUサイズと等しく設定されてもよい。
ｖ．たとえば、それは、最大変換スキップ・ブロック・サイズに等しく設定されてもよい。
ｖｉ．たとえば、それは、最大残差符号化ブロック・サイズに等しく設定されてもよい。
３５．最大変換サイズは、可逆（および／または可逆符号化に近い）および不可逆符号化について、異なる仕方で信号伝達および／または推定されうる。
ａ．一例では、可逆符号化および／またはほぼ可逆符号化のための最大変換サイズは、変換には関わらないので、「最大残差サイズ」または「最大表現サイズ」のような他の用語で称されてもよい。本開示においては、それは「maxLosslessTbSizeY」と称されることがある。
ｂ．一例では、ブロックについての可逆符号化は、そのブロックについてのcu_transquant_bypass_flagが1に等しいということができる。
ｃ．一例では、ブロックについてのほぼ可逆的な符号化は、所与の閾値よりも小さいQPをもつ符号化ということができる。
ｉ．一例では、閾値は、DPS/VPS/SPS/PPS/タイル/スライス/ブリックヘッダにおいて示されてもよい。
ｄ．一例では、ブロックについてのほぼ可逆的な符号化は、所与の閾値より小さいQPをもつ符号化ということができ、transform_skip_flagは、そのブロックについて1に等しい。
ｉ．一例では、閾値は、DPS/VPS/SPS/PPS/タイル/スライス/ブリックヘッダで示されてもよい。
ｅ．可逆符号化および／またはほぼ可逆符号化のための第1の最大変換サイズ（たとえば、maxLosslessTbSizeY）は、不可逆符号化のために使用されうる第2の最大変換サイズ、および／または最大符号化ツリー単位サイズ、および／または、最大変換スキップサイズを条件として設定されてもよい。
ｆ．可逆および／またはほぼ可逆符号化のための最大変換サイズは、SPS/VPS/PPS/サブピクチャー/スライス/タイル/ブリック/CTU/VPDUにおける構文要素（SE）のようなビデオ単位レベルで信号伝達されてもよい。
ｉ．一例では、SEは、最大CTBサイズ（たとえば、log2_ctu_size_minus5、CtbSizeYなど）に依存して信号伝達されうる。
１．たとえば、フラグは、log2_ctu_size_minus5がN（たとえばN＝0）より大きい場合に信号伝達されうる。
ｉｉ．一例では、SEは、最大変換サイズ（たとえば、sps_max_luma_transform_size_64_flag、MaxTbSizeなど）に依存して信号伝達されてもよい。
１．たとえば、SEは、sps_max_luma_transform_size_64_flagがMに等しい場合（たとえばM＝1）に信号伝達されうる。
ｉｉｉ．一例では、SEは、最大変換スキップサイズ（たとえば、log2_transform_skip_max_size_minus2、MaxTsSizeなど）に依存して、信号伝達されうる。
１．たとえば、SEは、log2_transform_skip_max_size_minus2がKより大きい場合（たとえばK＝3）、信号伝達されうる。
ｉｖ．一例では、log（maxLosslessTbSizeY）とXとの間のデルタ値は、信号伝達されてもよい。
１．たとえば、Xはlog2_ctu_size_minus5に等しくてもよい。
２．たとえば、Xはsps_max_luma_transform_size_64_flagと等しくてもよい。
３．たとえば、Xはlog2_transform_skip_max_size_minus2と等しくてもよい。
４．たとえば、Xは固定した整数に等しくてもよい。
５．一例では、デルタ－Kが信号伝達されてもよい。ここで、Kは、1のような整数である。
ｖ．一例では、maxLosslessTbSizeYとXとの間のデルタ値が信号伝達されてもよい。
１．たとえば、XはCtbSizeYと等しくてもよい
２．たとえば、XはMaxTbSizeと等しくてもよい
３．たとえば、XはMaxTsSizeと等しくてもよい
４．たとえば、Xは固定した整数に等しくてもよい
５．一例では、デルタ－Kが信号伝達されてもよい。ここで、Kは、1のような整数である。
ｖｉ．一例では、ビデオ単位のmaxLosslessTbSizeY（シーケンス/ピクチャー/サブピクチャー/スライス/タイル/CTU/VPDU/CU/PU/TUなど）は、SEから導出されてもよい。
ｖｉｉ．SEはフラグであってもよい。
ｖｉｉｉ．フラグが存在しない場合、それは、正の整数Nに等しいと推定されうる。
ｇ．一例では、可逆および／またはほぼ可逆符号化がビデオ単位に適用される（たとえばcu_transquant_bypass_flagが1に等しい）場合、ビデオ単位についての最大変換サイズはmaxTbSizeY以外のmaxLosslessTbSizeYに等しく設定されてもよい。
ｈ．あるいはまた、ビデオ単位についての可逆符号化および／またはほぼ可逆符号化のための最大変換サイズ（たとえば、シーケンス/ピクチャー/サブピクチャー/スライス/タイル/CTU/VPDU/CU/PU/TU）は、信号伝達される代わりに導出されてもよい。
ｉ．たとえば、それは、固定した整数値M（ルーマ・サンプル単位でM＝32など）に等しく設定されてもよい。
ｉｉ．たとえば、それは、不可逆符号化のために使用されうる第2の最大変換サイズに等しく設定されてもよい。
ｉｉｉ．たとえば、それは、最大符号化ツリー単位サイズに等しく設定されてもよい。
ｉｖ．たとえば、それは、VPDUサイズと等しく設定されてもよい。
ｖ．たとえば、それは、最大変換スキップ・ブロック・サイズに等しく設定されてもよい。
ｖｉ．たとえば、それは、最大残差符号化ブロック・サイズに等しく設定されてもよい。
３６．可逆符号化（および／またはほぼ可逆符号化）によるM×N残差ブロックについては、maxLosslessTbSizeYに依存して複数の、より小さな残差サブブロックに分割されてもよい。
ａ．分割後、すべてのサブブロックの幅と高さはmaxLosslessTbSizeYより大きくない。
ｂ．一例では、すべてのサブブロックの幅と高さがmaxLosslessTbSizeY以下になるまで、再帰的な方法でサブブロックに分割されてもよい。
5. 実施形態
新たに追加された部分は太字と斜体〔下線で代替することもある〕で強調表示され、VVCの作業原案から削除される部分は二重括弧で囲まれる（[[a]]は文字「a]の削除を表す）。修正は最新のVVC作業原案（JVET-O2001-v11）に基づいている。
ａ．分割後、すべてのサブブロックの幅と高さはmaxLosslessTbSizeYより大きくない。
ｂ．一例では、すべてのサブブロックの幅と高さがmaxLosslessTbSizeY以下になるまで、再帰的な方法でサブブロックに分割されてもよい。
5. 実施形態
新たに追加された部分は太字と斜体〔下線で代替することもある〕で強調表示され、VVCの作業原案から削除される部分は二重括弧で囲まれる（[[a]]は文字「a]の削除を表す）。修正は最新のVVC作業原案（JVET-O2001-v11）に基づいている。
5.1 例示的実施形態#1
以下の実施形態は、小ブロック・パーティションに関する制約条件についてのものであり、予測モードは、4:2:0および4:4:4クロマ・フォーマットのみに適用される（4:0:0および4:4:4クロマ・フォーマットには適用されない）。
以下の実施形態は、小ブロック・パーティションに関する制約条件についてのものであり、予測モードは、4:2:0および4:4:4クロマ・フォーマットのみに適用される（4:0:0および4:4:4クロマ・フォーマットには適用されない）。
7.4.9.4 符号化ツリーのセマンティクス
変数modeTypeConditionは次のように導出される：
・次の条件のいずれかが真である場合、modeTypeConditionは0に設定される。
・slice_type==Iかつqtbtt_dual_tree_intra_flagが1に等しい
・modeTypeCurrがMODE_TYPE_ALLと等しくない
・chroma_format_idcが0に等しい
・chroma_format_idcが3に等しい
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1に設定される。
・cbWidth*cbHeightが64に等しく、split_qt_flagが1に等しい
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidth*cbHeightが32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1＋（slice_type!=I? 1 : 0）に設定される。
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・cbWidth*cbHeightが128に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・それ以外の場合は、modeTypeConditionは0に設定される。
変数modeTypeConditionは次のように導出される：
・次の条件のいずれかが真である場合、modeTypeConditionは0に設定される。
・slice_type==Iかつqtbtt_dual_tree_intra_flagが1に等しい
・modeTypeCurrがMODE_TYPE_ALLと等しくない
・chroma_format_idcが0に等しい
・chroma_format_idcが3に等しい
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1に設定される。
・cbWidth*cbHeightが64に等しく、split_qt_flagが1に等しい
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidth*cbHeightが32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1＋（slice_type!=I? 1 : 0）に設定される。
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・cbWidth*cbHeightが128に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・それ以外の場合は、modeTypeConditionは0に設定される。
5.2 例示的実施形態#2
以下の実施形態は、modeTypeに依存しないパレット・モード・フラグの信号伝達に関するものである。
7.3.8. 符号化単位構文
以下の実施形態は、modeTypeに依存しないパレット・モード・フラグの信号伝達に関するものである。
7.3.8. 符号化単位構文
5.3 例示的実施形態#3
以下の実施形態は、IBC予測モード・フラグがCU SKIPフラグおよびmodeTypeに依存して推定されることについてのものである。
以下の実施形態は、IBC予測モード・フラグがCU SKIPフラグおよびmodeTypeに依存して推定されることについてのものである。
pred_mode_ibc_flagが1に等しいことは、現在の符号化単位がIBC予測モードで符号化されることを指定する。pred_mode_ibc_flagが0に等しいことは、現在の符号化単位がIBC予測モードで符号化されないことを指定する。
pred_mode_ibc_flagが存在しない場合、それは次のように推定される：
・cu_skip_flag[x0][y0]が1に等しく、cbWidthが4に等しく、cbHeightが4に等しい場合、pred_mode_ibc_flagは1に等しいと推定される。
・それ以外の場合で、cbWidthとcbHeightの両方が128に等しい場合、pred_mode_ibc_flagは0に等しいと推定される。
・それ以外の場合で、cu_skip_flag[x0][y0]が1に等しく、modeTypeがMODE_TYPE_INTRAに等しい場合、pred_mode_ibc_flagは1に等しいと推定される。
・それ以外の場合で、modeTypeがMODE_TYPE_INTERに等しい場合、pred_mode_ibc_flagは0に等しいと推定される。
・それ以外の場合で、treeTypeがDUAL_TREE_CHROMAに等しい場合、pred_mode_ibc_flagは0に等しいと推定される。
・それ以外の場合で、pred_mode_ibc_flagは、Iスライスをデコードするときはsps_ibc_enabled_flagの値に、PまたはBスライスをデコードするときは0に等しいと推定される。
・cu_skip_flag[x0][y0]が1に等しく、cbWidthが4に等しく、cbHeightが4に等しい場合、pred_mode_ibc_flagは1に等しいと推定される。
・それ以外の場合で、cbWidthとcbHeightの両方が128に等しい場合、pred_mode_ibc_flagは0に等しいと推定される。
・それ以外の場合で、cu_skip_flag[x0][y0]が1に等しく、modeTypeがMODE_TYPE_INTRAに等しい場合、pred_mode_ibc_flagは1に等しいと推定される。
・それ以外の場合で、modeTypeがMODE_TYPE_INTERに等しい場合、pred_mode_ibc_flagは0に等しいと推定される。
・それ以外の場合で、treeTypeがDUAL_TREE_CHROMAに等しい場合、pred_mode_ibc_flagは0に等しいと推定される。
・それ以外の場合で、pred_mode_ibc_flagは、Iスライスをデコードするときはsps_ibc_enabled_flagの値に、PまたはBスライスをデコードするときは0に等しいと推定される。
pred_mode_ibc_flagが1の場合、変数CuPredMode[chType][x][y]は、x＝x0..x0＋cbWidth－1およびy＝y0..y0＋cbHeight－1について、MODE_IBCに等しいと設定される。
5.4 例示的実施形態#4
以下の実施形態は、IBC予測モード・フラグの信号伝達がMODE_TYPE_INTRAに依存する、および／またはIBCモードは、それが小さいブロック・サイズであるかどうかにかかわらず、ルーマ・ブロックについて許容されることに関する。
以下の実施形態は、IBC予測モード・フラグの信号伝達がMODE_TYPE_INTRAに依存する、および／またはIBCモードは、それが小さいブロック・サイズであるかどうかにかかわらず、ルーマ・ブロックについて許容されることに関する。
7.3.8. 符号化単位構文
5.5 例示的実施形態#5
以下の実施形態は、4:2:0および4:2:2色フォーマットについて異なるイントラブロック制約条件を適用することに関する。
以下の実施形態は、4:2:0および4:2:2色フォーマットについて異なるイントラブロック制約条件を適用することに関する。
7.4.9.4 符号化ツリーのセマンティクス
変数modeTypeConditionは次のように導出される：
・次の条件のいずれかが真である場合、modeTypeConditionは0に設定される。
・slice_type==Iかつqtbtt_dual_tree_intra_flagが1に等しい
・modeTypeCurrがMODE_TYPE_ALLと等しくない
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1に等しく設定される。
・cbWidth*cbHeightが64に等しく、split_qt_flagが1に等しい
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidth*cbHeightが32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1＋（slice_type!=I?1:0）に等しく設定される。
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しく、chroma_format_idcが1に等しい
・cbWidth*cbHeightが128に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しく、chroma_format_idcが1に等しい
・cbWidthが8に等しく、cbHeightが8に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_VERに等しく、chroma_format_idcが2に等しい
・cbWidthが4に等しく、cbHeightが16に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORに等しく、chroma_format_idcが2に等しい
・cbWidthが16に等しく、cbHeightが8に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_VERに等しく、chroma_format_idcが2に等しい
・cbWidthが4に等しく、cbHeightが32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORに等しく、chroma_format_idcが2に等しい
・それ以外の場合は、modeTypeConditionは0に設定される。
変数modeTypeConditionは次のように導出される：
・次の条件のいずれかが真である場合、modeTypeConditionは0に設定される。
・slice_type==Iかつqtbtt_dual_tree_intra_flagが1に等しい
・modeTypeCurrがMODE_TYPE_ALLと等しくない
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1に等しく設定される。
・cbWidth*cbHeightが64に等しく、split_qt_flagが1に等しい
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidth*cbHeightが32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1＋（slice_type!=I?1:0）に等しく設定される。
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しく、chroma_format_idcが1に等しい
・cbWidth*cbHeightが128に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しく、chroma_format_idcが1に等しい
・cbWidthが8に等しく、cbHeightが8に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_VERに等しく、chroma_format_idcが2に等しい
・cbWidthが4に等しく、cbHeightが16に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORに等しく、chroma_format_idcが2に等しい
・cbWidthが16に等しく、cbHeightが8に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_VERに等しく、chroma_format_idcが2に等しい
・cbWidthが4に等しく、cbHeightが32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORに等しく、chroma_format_idcが2に等しい
・それ以外の場合は、modeTypeConditionは0に設定される。
5.6 例示的実施形態#6
以下の実施形態は、シングルツリーにおける2×Nクロマ・イントラ・ブロックを禁止することに関する。
以下の実施形態は、シングルツリーにおける2×Nクロマ・イントラ・ブロックを禁止することに関する。
7.4.9.4 符号化ツリーの意味
変数modeTypeConditionは次のように導出される：
・次の条件のいずれかが真である場合、modeTypeConditionは0に設定される。
・slice_type==Iかつqtbtt_dual_tree_intra_flagが1に等しい
・modeTypeCurrがMODE_TYPE_ALLと等しくない
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1に設定される。
・cbWidth*cbHeightが64に等しく、split_qt_flagが1に等しい
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidth*cbHeightが32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1＋（slice_type!=I?1:0）に設定される。
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・cbWidth*cbHeightが128に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidthが8に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_VERに等しい
・cbWidthが16に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_VERに等しい
・それ以外の場合は、modeTypeConditionは0に設定される。
変数modeTypeConditionは次のように導出される：
・次の条件のいずれかが真である場合、modeTypeConditionは0に設定される。
・slice_type==Iかつqtbtt_dual_tree_intra_flagが1に等しい
・modeTypeCurrがMODE_TYPE_ALLと等しくない
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1に設定される。
・cbWidth*cbHeightが64に等しく、split_qt_flagが1に等しい
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidth*cbHeightが32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1＋（slice_type!=I?1:0）に設定される。
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・cbWidth*cbHeightが128に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidthが8に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_VERに等しい
・cbWidthが16に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_VERに等しい
・それ以外の場合は、modeTypeConditionは0に設定される。
5.7 例示的実施形態#7
以下の実施形態は、デュアルツリーにおける2×Nクロマ・イントラ・ブロックを禁止することに関する。
以下の実施形態は、デュアルツリーにおける2×Nクロマ・イントラ・ブロックを禁止することに関する。
6.4.2 許容される二分分割プロセス
変数allowBtSplitは次のように導出される：
・次の条件の一つまたは複数が真である場合、allowBtSplitがFALSEに等しく設定される：
・cbSizeがMinBtSizeY以下
・cbWidthがmaxBtSizeより大きい
・cbHeightがmaxBtSizeより大きい
・mttDepthがmaxMttDepth以上
・treeTypeがDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は16以下
・btSplitがSPLIT_BT_VERに等しく、treeTypeがDUAL_TREE_CHROMAに等しく、（cbWidth/SubWidthC）が4以下
・treeTypeがDUAL_TREE_CHROMAに等しく、modeTypeはMODE_TYPE_INTRAに等しい
……
変数allowBtSplitは次のように導出される：
・次の条件の一つまたは複数が真である場合、allowBtSplitがFALSEに等しく設定される：
・cbSizeがMinBtSizeY以下
・cbWidthがmaxBtSizeより大きい
・cbHeightがmaxBtSizeより大きい
・mttDepthがmaxMttDepth以上
・treeTypeがDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は16以下
・btSplitがSPLIT_BT_VERに等しく、treeTypeがDUAL_TREE_CHROMAに等しく、（cbWidth/SubWidthC）が4以下
・treeTypeがDUAL_TREE_CHROMAに等しく、modeTypeはMODE_TYPE_INTRAに等しい
……
6.4.3 許容される三分分割プロセス
変数allowTtSplitは次のように導出される：
・次の条件の一つまたは複数が真の場合は、allowTtSplitがFALSEに等しく設定される：
・cbSizeが2×MinTtSizeY以下
・cbWidthがMin（MaxTbSizeY,maxTtSize）より大きい
・cbHeightがMin（MaxTbSizeY,maxTtSize）より大きい
・mttDepthがmaxMttDepth以上
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・treeTypeがDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は32以下
・btSplitがSPLIT_TT_VERに等しく、treeTypeがDUAL_TREE_CHROMAに等しく、（cbWidth/SubWidthC）が8以下
・treeTypeがDUAL_TREE_CHROMAに等しく、modeTypeがMODE_TYPE_INTRAに等しい
・それ以外の場合は、allowTtSplitはTRUEに等しく設定される。
変数allowTtSplitは次のように導出される：
・次の条件の一つまたは複数が真の場合は、allowTtSplitがFALSEに等しく設定される：
・cbSizeが2×MinTtSizeY以下
・cbWidthがMin（MaxTbSizeY,maxTtSize）より大きい
・cbHeightがMin（MaxTbSizeY,maxTtSize）より大きい
・mttDepthがmaxMttDepth以上
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・treeTypeがDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は32以下
・btSplitがSPLIT_TT_VERに等しく、treeTypeがDUAL_TREE_CHROMAに等しく、（cbWidth/SubWidthC）が8以下
・treeTypeがDUAL_TREE_CHROMAに等しく、modeTypeがMODE_TYPE_INTRAに等しい
・それ以外の場合は、allowTtSplitはTRUEに等しく設定される。
5.8 例示的実施形態#8
以下の実施形態は、SCIPUクロマ・ブロックに対してMODE_IBCを有効にすることに関するものである。
以下の実施形態は、SCIPUクロマ・ブロックに対してMODE_IBCを有効にすることに関するものである。
7.3.8.5 符号化単位構文
5.9 modeTypeがMODE_TYPE_INTERである場合のブロック分割の禁止に関する例示的実施形態#9（解決策1）
6.4.2 許容される二分分割プロセス
変数allowBtSplitは次のように導出される：
次の条件の一つまたは複数が真である場合、allowBtSplitはFALSEに等しく設定される：
・cbSizeがMinBtSizeY以下
・cbWidthがmaxBtSizeより大きい
・cbHeightがmaxBtSizeより大きい
・mttDepthがmaxMttDepth以上
・treeTypeはDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は16以下
・modeTypeはMODE_TYPE_INTERに等しく、cbWidth*cbHeightは32以下
・treeTypeはDUAL_TREE_CHROMAに等しく、modeTypeはMODE_TYPE_INTRAに等しい
……
変数allowBtSplitは次のように導出される：
次の条件の一つまたは複数が真である場合、allowBtSplitはFALSEに等しく設定される：
・cbSizeがMinBtSizeY以下
・cbWidthがmaxBtSizeより大きい
・cbHeightがmaxBtSizeより大きい
・mttDepthがmaxMttDepth以上
・treeTypeはDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は16以下
・modeTypeはMODE_TYPE_INTERに等しく、cbWidth*cbHeightは32以下
・treeTypeはDUAL_TREE_CHROMAに等しく、modeTypeはMODE_TYPE_INTRAに等しい
……
6.4.3 許容される三分分割プロセス
変数allowTtSplitは次のように導出される：
・次の条件の一つまたは複数が真の場合は、allowTtSplitはFALSEに等しく設定される：
・cbSizeが2×MinTtSizeY以下
・cbWidthがMin（MaxTbSizeY,maxTtSize）より大きい
・cbHeightがMin（MaxTbSizeY,maxTtSize）より大きい
・mttDepthがmaxMttDepth以上
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・treeTypeがDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は32以下
・modeTypeがMODE_TYPE_INTERに等しく、cbWidth*cbHeightは64以下
・treeTypeがDUAL_TREE_CHROMAに等しく、modeTypeはMODE_TYPE_INTRAに等しい
・それ以外の場合は、allowTtSplitはTRUEに等しく設定される。
変数allowTtSplitは次のように導出される：
・次の条件の一つまたは複数が真の場合は、allowTtSplitはFALSEに等しく設定される：
・cbSizeが2×MinTtSizeY以下
・cbWidthがMin（MaxTbSizeY,maxTtSize）より大きい
・cbHeightがMin（MaxTbSizeY,maxTtSize）より大きい
・mttDepthがmaxMttDepth以上
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・treeTypeがDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は32以下
・modeTypeがMODE_TYPE_INTERに等しく、cbWidth*cbHeightは64以下
・treeTypeがDUAL_TREE_CHROMAに等しく、modeTypeはMODE_TYPE_INTRAに等しい
・それ以外の場合は、allowTtSplitはTRUEに等しく設定される。
5.10 modeTypeがMODE_TYPE_INTERである場合のブロック分割の禁止に関する例示的実施形態#10（解決策2）
6.4.2 許容される二分分割プロセス
変数allowBtSplitは次のように導出される：
・次の条件の一つまたは複数が真である場合、allowBtSplitはFALSEに等しく設定される：
・cbSizeがMinBtSizeY以下
・cbWidthがmaxBtSizeより大きい
・cbHeightがmaxBtSizeより大きい
・mttDepthがmaxMttDepth以上
・treeTypeはDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は16以下
・modeTypeはMODE_TYPE_INTERと等しい
・treeTypeはDUAL_TREE_CHROMAに等しく、modeTypeはMODE_TYPE_INTRAに等しい
……
変数allowBtSplitは次のように導出される：
・次の条件の一つまたは複数が真である場合、allowBtSplitはFALSEに等しく設定される：
・cbSizeがMinBtSizeY以下
・cbWidthがmaxBtSizeより大きい
・cbHeightがmaxBtSizeより大きい
・mttDepthがmaxMttDepth以上
・treeTypeはDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は16以下
・modeTypeはMODE_TYPE_INTERと等しい
・treeTypeはDUAL_TREE_CHROMAに等しく、modeTypeはMODE_TYPE_INTRAに等しい
……
6.4.3 許容される三分分割プロセス
変数allowTtSplitは次のように導出される：
・次の条件の一つまたは複数が真の場合は、allowTtSplitはFALSEに等しく設定される：
・cbSizeが2×MinTtSizeY以下
・cbWidthがMin（MaxTbSizeY,maxTtSize）より大きい
・cbHeightがMin（MaxTbSizeY,maxTtSize）より大きい
・mttDepthがmaxMttDepth以上
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・treeTypeはDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は32以下
・modeTypeがMODE_TYPE_INTERと等しい
・treeTypeがDUAL_TREE_CHROMAに等しく、modeTypeはMODE_TYPE_INTRAに等しい
・それ以外の場合は、allowTtSplitがTRUEに等しく設定される。
変数allowTtSplitは次のように導出される：
・次の条件の一つまたは複数が真の場合は、allowTtSplitはFALSEに等しく設定される：
・cbSizeが2×MinTtSizeY以下
・cbWidthがMin（MaxTbSizeY,maxTtSize）より大きい
・cbHeightがMin（MaxTbSizeY,maxTtSize）より大きい
・mttDepthがmaxMttDepth以上
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・treeTypeはDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は32以下
・modeTypeがMODE_TYPE_INTERと等しい
・treeTypeがDUAL_TREE_CHROMAに等しく、modeTypeはMODE_TYPE_INTRAに等しい
・それ以外の場合は、allowTtSplitがTRUEに等しく設定される。
5.11 例示的実施形態#11
以下の実施形態は、MODE_TYPE_INTERが導出される場合の符号化ツリーのさらなる分割に関する制約条件に関する。
以下の実施形態は、MODE_TYPE_INTERが導出される場合の符号化ツリーのさらなる分割に関する制約条件に関する。
7.3.8.4 符号化ツリー構文
5.12 例示的実施形態#12
以下の実施形態は、小ブロック・パーティションに関する制約条件についてであり、予測モードは、パレット・モードが有効にされているときは適用されない。
以下の実施形態は、小ブロック・パーティションに関する制約条件についてであり、予測モードは、パレット・モードが有効にされているときは適用されない。
7.4.9.4 符号化ツリーのセマンティクス
変数modeTypeConditionは次のように導出される：
・次の条件のいずれかが真である場合、modeTypeConditionは0に設定される。
・slice_type==Iであり、かつ、qtbtt_dual_tree_intr_flagが1に等しい
・modeTypeCurrがMODE_TYPE_ALLと等しくない
・sps_palette_enabled_flagが1に等しい
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1に設定される。
・cbWidth*cbHeightが64に等しく、split_qt_flagが1に等しい
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidth*cbHeightが32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1＋（slice_type!=I?1:0）に設定される。
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・cbWidth*cbHeightが128に等しく、MttSplitMode[x0][y0][mttDepth]はSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・それ以外の場合は、modeTypeConditionが0に設定される。
変数modeTypeConditionは次のように導出される：
・次の条件のいずれかが真である場合、modeTypeConditionは0に設定される。
・slice_type==Iであり、かつ、qtbtt_dual_tree_intr_flagが1に等しい
・modeTypeCurrがMODE_TYPE_ALLと等しくない
・sps_palette_enabled_flagが1に等しい
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1に設定される。
・cbWidth*cbHeightが64に等しく、split_qt_flagが1に等しい
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidth*cbHeightが32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1＋（slice_type!=I?1:0）に設定される。
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・cbWidth*cbHeightが128に等しく、MttSplitMode[x0][y0][mttDepth]はSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・それ以外の場合は、modeTypeConditionが0に設定される。
5.13 例示的実施形態#13
以下の実施形態は、4:2:2色フォーマットについての小さなクロマ・イントラ・ブロック制約条件についてである。
以下の実施形態は、4:2:2色フォーマットについての小さなクロマ・イントラ・ブロック制約条件についてである。
7.4.9.4 符号化ツリーのセマンティクス
変数modeTypeConditionは次のように導出される：
・次の条件のいずれかが真である場合、modeTypeConditionは0に等しく設定される。
・slice_type==Iであり、qtbtt_dual_tree_intr_flagが1に等しい
・modeTypeCurrがMODE_TYPE_ALLと等しくない
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1に設定される。
・cbWidth*cbHeightが64に等しく、split_qt_flagが1に等しい
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidth*cbHeightが32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・それ以外の場合で、chroma_format_idcが1に等しく、次の条件のいずれかが真の場合、modeTypeConditionは1＋（slice_type!=I?1:0）に設定される。
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・cbWidth*cbHeightが28に等しく、MttSplitMode[x0][y0][mttDepth]はSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・それ以外の場合は、modeTypeConditionが0に設定される。
変数modeTypeConditionは次のように導出される：
・次の条件のいずれかが真である場合、modeTypeConditionは0に等しく設定される。
・slice_type==Iであり、qtbtt_dual_tree_intr_flagが1に等しい
・modeTypeCurrがMODE_TYPE_ALLと等しくない
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1に設定される。
・cbWidth*cbHeightが64に等しく、split_qt_flagが1に等しい
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidth*cbHeightが32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・それ以外の場合で、chroma_format_idcが1に等しく、次の条件のいずれかが真の場合、modeTypeConditionは1＋（slice_type!=I?1:0）に設定される。
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・cbWidth*cbHeightが28に等しく、MttSplitMode[x0][y0][mttDepth]はSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・それ以外の場合は、modeTypeConditionが0に設定される。
5.14 SCIPUにおけるデルタQP信号伝達の例#1
5.15 SCIPUにおけるデルタQP信号伝達の例#2
5.16 SCIPUにおけるデルタQP信号伝達の例#3
5.17 SCIPUにおけるデルタQP信号伝達の例#4
5.18 2×8クロマ・イントラ・ブロックを無効にする例#14
6.4.2. 許容される二分分割プロセス
変数allowBtSplitは次のように導出される：
・次の条件の一つまたは複数が真である場合、allowBtSplitがFALSEに等しく設定される：
・cbSizeがMinBtSizeY以下
・cbWidthがmaxBtSizeより大きい
・cbHeightがmaxBtSizeより大きい
・mttDepthがmaxMttDepth以上
・treeTypeがDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は16以下
・treeTypeがDUAL_TREE_CHROMAに等しく、btSplitはSPLIT_BT_VERに等しく、（cbWidth/SubWidthC）は4に等しく、（cbHeight/SubHeightC）は8に等しい
・treeTypeがDUAL_TREE_CHROMAに等しく、btSplitはSPLIT_BT_HORに等しく、（cbWidth/SubWidthC）が2に等しく、（cbHeight/SubHeightC）が16に等しい
・treeTypeがDUAL_TREE_CHROMAに等しく、modeTypeはMODE_TYPE_INTRAに等しい
……
6.4.2. 許容される二分分割プロセス
変数allowBtSplitは次のように導出される：
・次の条件の一つまたは複数が真である場合、allowBtSplitがFALSEに等しく設定される：
・cbSizeがMinBtSizeY以下
・cbWidthがmaxBtSizeより大きい
・cbHeightがmaxBtSizeより大きい
・mttDepthがmaxMttDepth以上
・treeTypeがDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は16以下
・treeTypeがDUAL_TREE_CHROMAに等しく、btSplitはSPLIT_BT_VERに等しく、（cbWidth/SubWidthC）は4に等しく、（cbHeight/SubHeightC）は8に等しい
・treeTypeがDUAL_TREE_CHROMAに等しく、btSplitはSPLIT_BT_HORに等しく、（cbWidth/SubWidthC）が2に等しく、（cbHeight/SubHeightC）が16に等しい
・treeTypeがDUAL_TREE_CHROMAに等しく、modeTypeはMODE_TYPE_INTRAに等しい
……
6.4.3. 許容される三分分割プロセス
変数allowTtSplitは次のように導出される：
・次の条件の一つまたは複数が真の場合は、allowTtSplitがFALSEに等しく設定される；
・cbSizeが2×MinTtSizeY以下
・cbWidthがMin（MaxTbSizeY,maxTtSize）より大きい
・cbHeightがMin（MaxTbSizeY,maxTtSize）より大きい
・mttDepthがmaxMttDepth以上
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・treeTypeはDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は32以下
・treeTypeがDUAL_TREE_CHROMAに等しく、btSplitがSPLIT_TT_VERに等しく、（cbWidth/SubWidthC）が8に等しく、（cbHeight/SubHeightC）が8に等しい
・treeTypeがDUAL_TREE_CHROMAに等しく、btSplitがSPLIT_TT_HORに等しく、（cbWidth/SubWidthC）が2に等しく、（cbHeight/SubHeightC）が32に等しい
・treeTypeがDUAL_TREE_CHROMAに等しく、modeTypeはMODE_TYPE_INTRAに等しい
・それ以外の場合は、allowTtSplitがTRUEに等しく設定される。
変数allowTtSplitは次のように導出される：
・次の条件の一つまたは複数が真の場合は、allowTtSplitがFALSEに等しく設定される；
・cbSizeが2×MinTtSizeY以下
・cbWidthがMin（MaxTbSizeY,maxTtSize）より大きい
・cbHeightがMin（MaxTbSizeY,maxTtSize）より大きい
・mttDepthがmaxMttDepth以上
・x0＋cbWidthがpic_width_in_luma_samplesより大きい
・y0＋cbHeightがpic_height_in_luma_samplesより大きい
・treeTypeはDUAL_TREE_CHROMAと等しく、（cbWidth/SubWidthC）*（cbHeight/SubHeightC）は32以下
・treeTypeがDUAL_TREE_CHROMAに等しく、btSplitがSPLIT_TT_VERに等しく、（cbWidth/SubWidthC）が8に等しく、（cbHeight/SubHeightC）が8に等しい
・treeTypeがDUAL_TREE_CHROMAに等しく、btSplitがSPLIT_TT_HORに等しく、（cbWidth/SubWidthC）が2に等しく、（cbHeight/SubHeightC）が32に等しい
・treeTypeがDUAL_TREE_CHROMAに等しく、modeTypeはMODE_TYPE_INTRAに等しい
・それ以外の場合は、allowTtSplitがTRUEに等しく設定される。
7.4.9.4. 符号化ツリーのセマンティクス
変数modeTypeConditionは次のように導出される：
・次の条件のいずれかが真である場合、modeTypeConditionは0に設定される。
・slice_type==Iであり、qtbtt_dual_tree_intr_flagが1に等しい
・modeTypeCurrがMODE_TYPE_ALLと等しくない
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1に設定される。
・cbWidth*cbHeightが64に等しく、split_qt_flagが1に等しい
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidth*cbHeightが32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1＋（slice_type!=I?1:0）に設定される。
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・cbWidth*cbHeightが128に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidthが8に等しく、（cbHeight/SubHeightC）が8に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_VERに等しい
・cbWidthが16に等しく、（cbHeight/SubHeightC）が8に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_VERに等しい
・cbWidthが4に等しく、（cbHeight/SubHeightC）が16に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_TT_HORに等しい
・cbWidthが4に等しく、（cbHeight/SubHeightC）が32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORに等しい
・それ以外の場合は、modeTypeConditionが0に設定される。
変数modeTypeConditionは次のように導出される：
・次の条件のいずれかが真である場合、modeTypeConditionは0に設定される。
・slice_type==Iであり、qtbtt_dual_tree_intr_flagが1に等しい
・modeTypeCurrがMODE_TYPE_ALLと等しくない
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1に設定される。
・cbWidth*cbHeightが64に等しく、split_qt_flagが1に等しい
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidth*cbHeightが32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・それ以外の場合で、次の条件のいずれかが真である場合、modeTypeConditionは1＋（slice_type!=I?1:0）に設定される。
・cbWidth*cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_BT_VERに等しい
・cbWidth*cbHeightが128に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORまたはSPLIT_TT_VERに等しい
・cbWidthが8に等しく、（cbHeight/SubHeightC）が8に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_VERに等しい
・cbWidthが16に等しく、（cbHeight/SubHeightC）が8に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_VERに等しい
・cbWidthが4に等しく、（cbHeight/SubHeightC）が16に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HORまたはSPLIT_TT_HORに等しい
・cbWidthが4に等しく、（cbHeight/SubHeightC）が32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HORに等しい
・それ以外の場合は、modeTypeConditionが0に設定される。
7.4.9.7. マージ・データのセマンティクス
ciip_flag[x0][y0]は、ピクチャー間マージとピクチャー内予測の組み合わせが現在の符号化単位に適用されるかどうかを指定する。配列インデックスx0,y0は、ピクチャーの左上のルーマ・サンプルに対する、考慮される符号化ブロックの左上のルーマ・サンプルの位置（x0,y0）を指定する。
ciip_flag[x0][y0]が存在しない場合、次のように推定される：
・以下の条件がすべて真である場合、ciip_flag[x0][y0]は1に等しいと推定される：
・sps_ciip_enabled_flagが1に等しい
・general_merge_flag[x0][y0]が1に等しい
・merge_subblock_flag[x0][y0]が0に等しい
・regular_merge_flag[x0][y0]が0に等しい
・cbWidthが128未満
・cbHeightが128未満
・cbWidthが4より大きく、cbHeightが16に等しくない
・cbWidth*cbHeightが64以上
・それ以外の場合は、ciip_flag[x0][y0]は0に等しいと推定される。
ciip_flag[x0][y0]は、ピクチャー間マージとピクチャー内予測の組み合わせが現在の符号化単位に適用されるかどうかを指定する。配列インデックスx0,y0は、ピクチャーの左上のルーマ・サンプルに対する、考慮される符号化ブロックの左上のルーマ・サンプルの位置（x0,y0）を指定する。
ciip_flag[x0][y0]が存在しない場合、次のように推定される：
・以下の条件がすべて真である場合、ciip_flag[x0][y0]は1に等しいと推定される：
・sps_ciip_enabled_flagが1に等しい
・general_merge_flag[x0][y0]が1に等しい
・merge_subblock_flag[x0][y0]が0に等しい
・regular_merge_flag[x0][y0]が0に等しい
・cbWidthが128未満
・cbHeightが128未満
・cbWidthが4より大きく、cbHeightが16に等しくない
・cbWidth*cbHeightが64以上
・それ以外の場合は、ciip_flag[x0][y0]は0に等しいと推定される。
7.3.8.7. マージ・データの構文
図17Aは、ビデオ処理装置1700のブロック図である。装置1700は、本明細書に記載される方法のうちの一つまたは複数を実装するために使用されてもよい。装置1700は、スマートフォン、タブレット、コンピュータ、モノのインターネット（IoT）受信機などにおいて具現されてもよい。装置1700は、一つまたは複数のプロセッサ1702、一つまたは複数のメモリ1704、およびビデオ処理ハードウェア1706を含んでいてもよい。プロセッサ1702は、本稿に記載される一つまたは複数の方法を実装するように構成されてもよい。メモリ（単数または複数）1704は、本明細書に記載される方法および技法を実装するために使用されるデータおよびコードを記憶するために使用されてもよい。ビデオ処理ハードウェア1706は、ハードウェア回路において、本稿に記載されるいくつかの技法を実装するために使用されてもよい。
図17Bは、開示された技法が実装されうるビデオ処理システムのブロック図の別の例である。図17Bは、本明細書に開示されるさまざまな技法が実装されうる例示的なビデオ処理システム1710を示すブロック図である。さまざまな実装は、システム1710の構成要素の一部または全部を含んでいてもよい。システム1710は、ビデオ・コンテンツを受信するための入力1712を含んでいてもよい。ビデオ・コンテンツは、生または非圧縮フォーマット、たとえば、8または10ビットの多成分ピクセル値の形で受領されてもよく、または圧縮またはエンコードされたフォーマットで受領されてもよい。入力1712は、ネットワークインターフェース、周辺バスインターフェース、または記憶インターフェースを表すことができる。ネットワークインターフェースの例は、イーサネット、受動光ネットワーク（PON）などの有線インターフェース、およびWi-Fiまたはセルラーインターフェースなどの無線インターフェースを含む。
システム1710は、本稿に記載されるさまざまな符号化またはエンコード方法を実装しうる符号化コンポーネント1714を含んでいてもよい。符号化コンポーネント1714は、入力1712から符号化コンポーネント1714の出力へ、ビデオの平均ビットレートを低減して、ビデオの符号化表現を生成してもよい。よって、符号化技法は、時に、ビデオ圧縮またはビデオトランスコード技法と呼ばれる。符号化コンポーネント1714の出力は、コンポーネント1716によって表されるように接続された通信を介して、記憶されるか、または送信されてもよい。入力1712で受信されたビデオの記憶されたまたは通信されたビットストリーム（または符号化された）表現は、ディスプレイインターフェース1720に送られるピクセル値または表示可能なビデオを生成するために、コンポーネント1718によって使用されうる。ビットストリーム表現からユーザーが見ることができるビデオを生成するプロセスは、時に、ビデオ圧縮解除と呼ばれる。さらに、ある種のビデオ処理動作は、「符号化」操作またはツールと称されるが、符号化ツールまたは操作は、エンコーダにおいて使用され、符号化の結果を反転させる対応する復号ツールまたは操作がデコーダにおいて実行されることが理解されるであろう。
周辺バスインターフェースまたはディスプレイインターフェースの例は、ユニバーサルシリアルバス（USB）または高精細度マルチメディアインターフェース（MDMI）またはディスプレイポートなどを含む。記憶インターフェースの例は、SATA（シリアルアドバンストテクノロジーアタッチメント）、PCI、IDEインターフェースなどを含む。本稿に記載される技法は、携帯電話、ラップトップ、スマートフォン、またはデジタルデータ処理および／またはビデオ表示を実行することができる他の装置のようなさまざまな電子装置において具現されうる。
図22は、本開示の技表を利用することができる例示的なビデオ符号化システム100を示すブロック図である。
図22に示されるように、ビデオ符号化システム100は、源装置110および宛先装置120を含んでいてもよい。源装置110は、ビデオ・エンコード装置と称されてもよく、エンコードされたビデオ・データを生成する。宛先装置120は、ビデオ・デコード装置と称されてもよく、源装置110によって生成されたエンコードされたビデオ・データをデコードしてもよい。
源装置110は、ビデオ源112、ビデオ・エンコーダ114、および入出力（I/O）インターフェース116を含むことができる。
ビデオ源112は、ビデオ捕捉装置のような源、ビデオ・コンテンツ・プロバイダーからビデオ・データを受信するためのインターフェース、および／またはビデオ・データを生成するためのコンピュータ・グラフィックス・システム、またはそのような源の組み合わせを含んでいてもよい。ビデオ・データは、一つまたは複数のピクチャーを含んでいてもよい。ビデオ・エンコーダ114は、ビデオ源112からのビデオ・データをエンコードしてビットストリームを生成する。ビットストリームは、ビデオ・データの符号化表現を形成するビットのシーケンスを含んでいてもよい。ビットストリームは、符号化されたピクチャーおよび関連するデータを含んでいてもよい。符号化ピクチャーは、ピクチャーの符号化表現である。関連するデータは、シーケンスパラメータセット、ピクチャーパラメータセット、および他の構文構造を含んでいてもよい。I/Oインターフェース116は、変調器／復調器（モデム）および／または送信器を含んでいてもよい。エンコードされたビデオ・データは、ネットワーク130aを通じてI/Oインターフェース116を介して宛先装置120に直接送信されてもよい。エンコードされたビデオ・データはまた、宛先装置120によるアクセスのために記憶媒体／サーバー130b上に記憶されてもよい。
宛先装置120は、I/Oインターフェース126、ビデオ・デコーダ124、および表示装置122を含んでいてもよい。
I/Oインターフェース126は、受信機および／またはモデムを含んでいてもよい。I/Oインターフェース126は、源装置110または記憶媒体／サーバー130bから、エンコードされたビデオ・データを取得してもよい。ビデオ・デコーダ124は、エンコードされたビデオ・データをデコードしてもよい。表示装置122は、デコードされたビデオ・データをユーザーに対して表示してもよい。表示装置122は、宛先装置120と一体化されてもよく、または外部表示装置とインターフェースするように構成された宛先装置120の外部にあってもよい。
ビデオ・エンコーダ114およびビデオ・デコーダ124は、高効率ビデオ符号化（HEVC）標準、多用途ビデオ符号化（VVC）標準、およびその他の現行のおよび／またはさらなる標準のようなビデオ圧縮標準に従って動作してもよい。
図23は、図22に示されるシステム100内のビデオ・エンコーダ114であってもよいビデオ・エンコーダ200の一例を示すブロック図である。
ビデオ・エンコーダ200は、本開示の技法のいずれかまたはすべてを実行するように構成されてもよい。図9の例では、ビデオ・エンコーダ200は、複数の機能コンポーネントを含む。本開示に記載される技法は、ビデオ・エンコーダ200のさまざまなコンポーネント間で共有されてもよい。いくつかの例では、プロセッサが、本開示に記載される技法のいずれかまたはすべてを実行するように構成されてもよい。
ビデオ・エンコーダ200の機能コンポーネントは、分割部201と、モード選択部203、動き推定部204、動き補償部205、およびイントラ予測部206を含みうる予測部202と、残差生成部207と、変換部208と、量子化部209と、逆量子化部210と、逆変換部211と、再構成部212と、バッファ213と、エントロピー符号化部214とを含んでいてもよい。
他の例では、ビデオ・エンコーダ200は、より多くの、より少ない、または異なる機能コンポーネントを含んでいてもよい。一例では、予測部202は、イントラブロックコピー（IBC）部を含んでいてもよい。IBC部は、少なくとも1つの参照ピクチャーが現在のビデオ・ブロックが位置するピクチャーであるIBCモードで予測を実行することができる。
さらに、動き推定部204や動き補償部205のようないくつかのコンポーネントは、高度に統合されてもよいが、説明のために図11の例では別個に表現されている。
分割部201は、ピクチャーを一つまたは複数のビデオ・ブロックにパーティション分割することができる。ビデオ・エンコーダ200およびビデオ・デコーダ300は、さまざまなビデオ・ブロック・サイズをサポートすることができる。
モード選択部203は、たとえば誤差結果に基づいて、符号化モードのうちの1つ、イントラまたはインターを選択し、結果として得られるイントラまたはインター符号化されたブロックを、残差ブロック・データを生成する残差生成部207に、また、参照ピクチャーとして使用するためにエンコードされたブロックを再構成する再構成部212に提供することができる。いくつかの例では、モード選択部203は、予測がインター予測信号およびイントラ予測信号に基づく、イントラおよびインター予測の組み合わせ（CIIP）モードを選択してもよい。モード選択部203は、また、インター予測の場合、ブロックについての動きベクトルの分解能（たとえば、サブピクセルまたは整数ピクセル精度）を選択してもよい。
現在のビデオ・ブロックに対してインター予測を実行するために、動き推定部204は、バッファ213からの一つまたは複数の参照フレームを現在のビデオ・ブロックと比較することによって、現在のビデオ・ブロックについての動き情報を生成してもよい。動き補償部205は、現在のビデオ・ブロックに関連するピクチャー以外のバッファ213からのピクチャーのデコードされたサンプルと前記動き情報とに基づいて、現在のビデオ・ブロックについて予測されるビデオ・ブロックを決定することができる。
動き推定部204と動き補償部205は、たとえば、現在のビデオ・ブロックがIスライス内にあるか、Pスライス内にあるか、Bスライス内にあるかによって、現在のビデオ・ブロックについて異なる動作を実行してもよい。
いくつかの例では、動き推定部204は、現在のビデオ・ブロックについて一方向の予測を実行してもよく、動き推定部204は、現在のビデオ・ブロックについての参照ビデオ・ブロックを求めて、リスト0またはリスト1の参照ピクチャーを探索してもよい。次いで、動き推定部204は、参照ビデオ・ブロックを含むリスト0またはリスト1内の参照ピクチャーを示す参照インデックスと、現在のビデオ・ブロックと参照ビデオ・ブロックとの間の空間的変位を示す動きベクトルとを生成することができる。動き推定部204は、参照インデックス、予測方向指示子、および動きベクトルを現在のビデオ・ブロックの動き情報として出力することができる。動き補償部205は、現在のビデオ・ブロックの動き情報によって示される参照ビデオ・ブロックに基づいて、現在のブロックの予測されたビデオ・ブロックを生成することができる。
他の例では、動き推定部204は、現在のビデオ・ブロックについて双方向予測を実行してもよく、動き推定部204は、現在のビデオ・ブロックについての参照ビデオ・ブロックを求めてリスト0内の参照ピクチャーを探索してもよく、現在のビデオ・ブロックについての別の参照ビデオ・ブロックを求めてリスト1内の参照ピクチャーをも探索してもよい。次いで、動き推定部204は、参照ビデオ・ブロックを含むリスト0およびリスト1における参照ピクチャーを示す参照インデックスと、参照ビデオ・ブロックと現在のビデオ・ブロックとの間の空間的変位を示す動きベクトルとを生成してもよい。動き推定部204は、現在のビデオ・ブロックの参照インデックスおよび動きベクトルを、現在のビデオ・ブロックの動き情報として、出力することができる。動き補償部205は、現在のビデオ・ブロックの動き情報によって示される参照ビデオ・ブロックに基づいて、現在のビデオ・ブロックの予測ビデオ・ブロックを生成することができる。
いくつかの例では、動き推定部204は、デコーダのデコード処理のための動き情報のフルセットを出力してもよい。
いくつかの例では、動き推定部204は、現在のビデオについての動き情報のフルセットは出力しなくてもよい。むしろ、動き推定部204は、別のビデオ・ブロックの動き情報を参照して現在のビデオ・ブロックの動き情報を信号伝達してもよい。たとえば、動き推定部204は、現在のビデオ・ブロックの動き情報が近傍のビデオ・ブロックの動き情報と十分に類似していると判断することができる。
一例では、動き推定部204は、現在のビデオ・ブロックに関連する構文構造において、現在のビデオ・ブロックが別のビデオ・ブロックと同じ動き情報を有することをビデオ・デコーダ300に対して示す値を示してもよい。
別の例では、動き推定部204は、現在のビデオ・ブロックに関連する構文構造において、別のビデオ・ブロックおよび動きベクトル差（MVD）を同定してもよい。動きベクトル差は、現在のビデオ・ブロックの動きベクトルと示されたビデオ・ブロックの動きベクトルとの間の差を示す。ビデオ・デコーダ300は、示されたビデオ・ブロックの動きベクトルと動きベクトル差とを使用して、現在のビデオ・ブロックの動きベクトルを決定することができる。
上述のように、ビデオ・エンコーダ200は、動きベクトルを予測的に信号伝達してもよい。ビデオ・エンコーダ200によって実装されうる予測的な信号伝達技法の2つの例は、先進動きベクトル予測（AMVP）およびマージ・モード信号伝達を含む。
イントラ予測部206は、現在のビデオ・ブロックに対してイントラ予測を実行することができる。イントラ予測部206が現在のビデオ・ブロックに対してイントラ予測を実行するとき、イントラ予測部206は、同じピクチャー内の他のビデオ・ブロックのデコードされたサンプルに基づいて、現在のビデオ・ブロックのための予測データを生成することができる。現在のビデオ・ブロックのための予測データは、予測されるビデオ・ブロックおよびさまざまな構文要素を含んでいてもよい。
残差生成部207は、現在のビデオ・ブロックから現在のビデオ・ブロックの予測ビデオ・ブロックを差し引くことによって（たとえば、マイナス記号によって示される）、現在のビデオ・ブロックのための残差データを生成することができる。現在のビデオ・ブロックの残差データは、現在のビデオ・ブロック内のサンプルの異なるサンプル成分に対応する残差ビデオ・ブロックを含んでいてもよい。
他の例では、たとえばスキップ・モードにおいて、現在のビデオ・ブロックのための現在のビデオ・ブロックのための残差データが存在しないことがあり、残差生成部207は減算演算を実行しないことがある。
変換処理部208は、現在のビデオ・ブロックに関連する残差ビデオ・ブロックに一つまたは複数の変換を適用することによって、現在のビデオ・ブロックのための一つまたは複数の変換係数ビデオ・ブロックを生成することができる。
変換処理部208が現在のビデオ・ブロックに関連する変換係数ビデオ・ブロックを生成した後、量子化部209は、現在のビデオ・ブロックに関連する一つまたは複数の量子化パラメータ（QP）値に基づいて、現在のビデオ・ブロックに関連する変換係数ビデオ・ブロックを量子化することができる。
逆量子化部210および逆変換部211は、変換係数ビデオ・ブロックから残差ビデオ・ブロックを再構成するために、変換係数ビデオ・ブロックに対してそれぞれ逆量子化および逆変換を適用することができる。再構成部212は、再構成された残差ビデオ・ブロックを、予測部202によって生成された一つまたは複数の予測ビデオ・ブロックからの対応するサンプルに加算して、バッファ213に記憶するために現在のブロックに関連する再構成されたビデオ・ブロックを生成する。
再構成部212がビデオ・ブロックを再構成した後、ビデオ・ブロック内のビデオ・ブロッキング・アーチファクトを低減するためにループ・フィルタリング動作が実行されてもよい。
エントロピー符号化部214は、ビデオ・エンコーダ200の他の機能コンポーネントからデータを受領することができる。エントロピー符号化部214がデータを受領すると、エントロピー符号化部214は、一つまたは複数のエントロピー符号化動作を実行してエントロピー符号化データを生成し、エントロピー符号化データを含むビットストリームを出力することができる。
図24は、図22に示されるシステム100内のビデオ・デコーダ114であってもよいビデオ・デコーダ300の例を示すブロック図である。
ビデオ・デコーダ300は、本開示の技法のいずれかまたはすべてを実行するように構成されうる。図24の例では、ビデオ・デコーダ300は、複数の機能的コンポーネントを含む。本開示に記載される技法は、ビデオ・デコーダ300のさまざまなコンポーネント間で共有されてもよい。いくつかの例では、プロセッサが、本開示に記載される技法のいずれかまたはすべてを実行するように構成されてもよい。
図24の例では、ビデオ・デコーダ300は、エントロピー復号部301、動き補償部302、イントラ予測部303、逆量子化部304、逆変換部305、再構成部306、バッファ307を含む。ビデオ・デコーダ300は、いくつかの例では、ビデオ・エンコーダ200（たとえば図23）に関して説明したエンコード・パス（pass）とおおむね逆のデコード・パスを実行することができる。
エントロピー復号部301は、エンコードされたビットストリームを取り出すことができる。エンコードされたビットストリームはエントロピー符号化されたビデオ・データ（たとえば、ビデオ・データのエンコードされたブロック）を含むことができる。エントロピー復号部301はエントロピー符号化されたビデオ・データを復号することができ、エントロピー復号されたビデオ・データから、動き補償部302は、動きベクトル、動きベクトル精度、参照ピクチャー・リスト・インデックス、および他の動き情報を含む動き情報を決定することができる。動き補償部302は、たとえば、AMVPおよびマージ・モードを実行することによって、そのような情報を決定することができる。
動き補償部302は、可能性としては補間フィルタに基づく補間を実行して、動き補償されたブロックを生成することができる。サブピクセル精度で使用される補間フィルタのための識別子が、構文要素に含まれてもよい。
動き補償部302は、ビデオ・ブロックのエンコード中にビデオ・エンコーダ20によって使用される補間フィルタを使用して、参照ブロックの整数未満ピクセルについての補間された値を計算することができる。動き補償部302は、受領された構文情報に従ってビデオ・エンコーダ200によって使用される補間フィルタを決定し、該補間フィルタを使用して予測ブロックを生成することができる。
動き補償部302は、構文情報の一部を使用して、エンコードされたビデオ・シーケンスのフレームおよび／またはスライスをエンコードするために使用されるブロックのサイズ、エンコードされたビデオ・シーケンスのピクチャーの各マクロブロックがどのようにパーティション分割されるかを記述する分割情報、各パーティションがどのようにエンコードされるかを示すモード、各インター符号化されたブロックについての一つまたは複数の参照フレーム（および参照フレーム・リスト）、およびエンコードされたビデオ・シーケンスをデコードするための他の情報を決定することができる。
イントラ予測部303は、たとえばビットストリームにおいて受領されたイントラ予測モードを使用して、空間的に隣接するブロックから予測ブロックを形成してもよい。逆量子化部303は、ビットストリーム内で提供され、エントロピー復号部301によって復号された量子化ビデオ・ブロック係数を逆量子化する、すなわち、脱量子化する。逆変換部303は、逆変換を適用する。
再構成部306は、残差ブロックを、動き補償部202またはイントラ予測部303によって生成された対応する予測ブロックと加算して、デコードされたブロックを形成することができる。所望であれば、ブロック性アーチファクトを除去するために、デコードされたブロックをフィルタリングするようブロッキング解除フィルタも適用されてもよい。次いで、デコードされたビデオ・ブロックはバッファ307に格納され、バッファ307は、その後の動き補償／イントラ予測のための参照ブロックを提供する。
図18は、ビデオを処理する方法1800のためのフローチャートである。方法1800は、ビデオのビデオ領域と該ビデオ領域の符号化表現との間の変換のために、クロマ・ブロック・サイズとビデオ領域の色フォーマットとの間の関係を定義する構文規則に従って符号化表現をパースし（1802）；構文規則に従ってパースを実行することによって変換を実行する（1804）ことを含む。
開示された技術のいくつかの実施形態は、ビデオ処理ツールまたはモードを可能にする判断または決定を行うことを含む。一例では、ビデオ処理ツールまたはモードが有効にされる場合、エンコーダは、ビデオのブロックの処理において該ツールまたはモードを使用または実装するが、必ずしも該ツールまたはモードの使用に基づいて、結果として生じるビットストリームを修正しないことがある。すなわち、ビデオのブロックからビデオのビットストリーム表現への変換は、前記判断または決定に基づいて有効にされるとき、前記ビデオ処理ツールまたはモードを使用する。別の例では、前記ビデオ処理ツールまたはモードが有効である場合、デコーダは、ビットストリームが前記ビデオ処理ツールまたはモードに基づいて修正されているという知識を用いてビットストリームを処理する。すなわち、ビデオのビットストリーム表現からビデオのブロックへの変換は、前記判断または判定に基づいて有効にされたビデオ処理ツールまたはモードを使用して実行される。
開示された技術のいくつかの実施形態は、ビデオ処理ツールまたはモードを無効にする判断または決定を行うことを含む。一例では、ビデオ処理ツールまたはモードが無効にされる場合、エンコーダは、ビデオのブロックをビデオのビットストリーム表現に変換する際に、前記ツールまたはモードを使用しない。別の例では、ビデオ処理ツールまたはモードが無効にされる場合、デコーダは、ビットストリームが、前記判断または決定に基づいて無効にされた前記ビデオ処理ツールまたはモードを使用して修正されていないという知識を用いて、ビットストリームを処理する。
本稿において、「ビデオ処理」という用語は、ビデオ・エンコード、ビデオ・デコード、ビデオ圧縮またはビデオ圧縮解除を指すことができる。たとえば、ビデオ圧縮アルゴリズムが、ビデオのピクセル表現から対応するビットストリーム表現へ、またはその逆への変換の間に適用されてもよい。現在のビデオ・ブロックのビットストリーム表現は、たとえば、構文によって定義されるように、ビットストリーム内で共位置の、または異なる場所に拡散された諸ビットに対応しうる。たとえば、マクロブロックは、変換され符号化された誤差残差値を用いて、また、ビットストリーム内のヘッダおよび他のフィールド内のビットを使用してエンコードされてもよい。
以下の条項は、開示された技術の例示的実装として実装されうる。
第1の組の条項は、前のセクションの項目1に記述された技法に関する以下の条項を含むことができる。
１．ビデオのビデオ領域と前記ビデオ領域の符号化表現との間の変換のために、前記ビデオ領域のクロマ・ブロック・サイズと色フォーマットとの間の関係を定義する構文規則に従って前記符号化表現をパース〔構文解析〕するステップと；前記構文規則に従って前記パースを実行することによって前記変換を実行するステップとを含む、ビデオ処理方法。
２．条項１に記載の方法であって、前記色フォーマットは4:4:4であり、前記構文規則は、前記クロマ・ブロックがルーマ・ブロックと同じサイズ制約条件に従うことを規定する、方法。
３．前記色フォーマットは4:2:2であり、前記構文規則は、前記クロマ・ブロックが4:2:0色フォーマットの場合と同じサイズ制約条件に従うことを規定する、条項１に記載の方法。
４．前記構文は、予測モードおよび小ブロック・パーティションがクロマ・フォーマット依存の仕方で使用されることを規定する、条項１ないし３のうちいずれか一項に方法。
５．前記構文規則は、前記ビデオ領域の色フォーマットに基づいて、前記ビデオ領域の変換のために、最小の許容されるサイズのフィーチャーが有効にされることを定義する、条項１に記載の方法。
１．ビデオのビデオ領域と前記ビデオ領域の符号化表現との間の変換のために、前記ビデオ領域のクロマ・ブロック・サイズと色フォーマットとの間の関係を定義する構文規則に従って前記符号化表現をパース〔構文解析〕するステップと；前記構文規則に従って前記パースを実行することによって前記変換を実行するステップとを含む、ビデオ処理方法。
２．条項１に記載の方法であって、前記色フォーマットは4:4:4であり、前記構文規則は、前記クロマ・ブロックがルーマ・ブロックと同じサイズ制約条件に従うことを規定する、方法。
３．前記色フォーマットは4:2:2であり、前記構文規則は、前記クロマ・ブロックが4:2:0色フォーマットの場合と同じサイズ制約条件に従うことを規定する、条項１に記載の方法。
４．前記構文は、予測モードおよび小ブロック・パーティションがクロマ・フォーマット依存の仕方で使用されることを規定する、条項１ないし３のうちいずれか一項に方法。
５．前記構文規則は、前記ビデオ領域の色フォーマットに基づいて、前記ビデオ領域の変換のために、最小の許容されるサイズのフィーチャーが有効にされることを定義する、条項１に記載の方法。
以下の条項は、前のセクションの項目2に記載されている追加の技法と一緒に実装されうる。
６．ビデオの属性および前記ビデオのクロマ・フォーマットに基づいて、前記ビデオの符号化ツリー・ノードの符号化モードを決定するステップと；前記決定された符号化モードを使用して、前記ビデオの符号化表現と前記符号化ツリー・ノードのビデオ・ブロックとの間の変換を実行するステップとを含む、ビデオ処理の方法。
７．前記属性が：
i. 符号化ノードが水平二分木分割をもつM×N符号化ツリー・ノードである；
ii. 符号化ノードが垂直二分木分割をもつM×N符号化ツリー・ノードである；
iii. 符号化ノードが水平三分木分割をもつM×N符号化ツリー・ノードである；または
iv. 符号化ノードが垂直三分木分割をもつM×N符号化ツリー・ノードである場合、
前記符号化モードが、4:2:2である前記クロマ・フォーマットについてはMODE_TYPE_ALLであり、4:2:0である前記クロマ・フォーマットについてはMODE_TYPE_INTRAまたはMODE_TYPE_INTERであると決定される、条項６に記載の方法。
８．M＝8または16または32であり、およびN＝4または8または16である、条項７に記載の方法。
６．ビデオの属性および前記ビデオのクロマ・フォーマットに基づいて、前記ビデオの符号化ツリー・ノードの符号化モードを決定するステップと；前記決定された符号化モードを使用して、前記ビデオの符号化表現と前記符号化ツリー・ノードのビデオ・ブロックとの間の変換を実行するステップとを含む、ビデオ処理の方法。
７．前記属性が：
i. 符号化ノードが水平二分木分割をもつM×N符号化ツリー・ノードである；
ii. 符号化ノードが垂直二分木分割をもつM×N符号化ツリー・ノードである；
iii. 符号化ノードが水平三分木分割をもつM×N符号化ツリー・ノードである；または
iv. 符号化ノードが垂直三分木分割をもつM×N符号化ツリー・ノードである場合、
前記符号化モードが、4:2:2である前記クロマ・フォーマットについてはMODE_TYPE_ALLであり、4:2:0である前記クロマ・フォーマットについてはMODE_TYPE_INTRAまたはMODE_TYPE_INTERであると決定される、条項６に記載の方法。
８．M＝8または16または32であり、およびN＝4または8または16である、条項７に記載の方法。
以下の条項は、前のセクションの項目12に記載されている追加の技法と一緒に実装されうる。
９．ビデオ処理方法であって、規則に基づいて、クロマ・ブロックのあるサイズがビデオのビデオ領域において許容されるかどうかを決定するステップと；前記決定に基づいて、前記ビデオ領域と前記ビデオ領域の符号化表現との間の変換を実行するステップとを含む、ビデオ処理方法。
１０．前記規則が、2xNクロマ・ブロックが、前記ビデオ領域がデュアルツリー・パーティションを含むために、禁止されることを規定する、条項９に記載の方法。
１１．前記規則は、前記ビデオ領域がシングルツリー・パーティションを含むため2Nクロマ・ブロックが許容されないことを規定する、条項９に記載の方法。
１２．N≦64である、条項１０または１１に記載の方法。
９．ビデオ処理方法であって、規則に基づいて、クロマ・ブロックのあるサイズがビデオのビデオ領域において許容されるかどうかを決定するステップと；前記決定に基づいて、前記ビデオ領域と前記ビデオ領域の符号化表現との間の変換を実行するステップとを含む、ビデオ処理方法。
１０．前記規則が、2xNクロマ・ブロックが、前記ビデオ領域がデュアルツリー・パーティションを含むために、禁止されることを規定する、条項９に記載の方法。
１１．前記規則は、前記ビデオ領域がシングルツリー・パーティションを含むため2Nクロマ・ブロックが許容されないことを規定する、条項９に記載の方法。
１２．N≦64である、条項１０または１１に記載の方法。
以下の条項は、前のセクションの項目13、14、および15に記載されている追加の技法と一緒に実装されうる。
１３．あるビデオ条件について符号化モードの使用を許容する規則に基づいて、ある符号化モードがビデオ領域について許可されることを決定するステップと；前記決定に基づいて、前記ビデオ領域内のピクセルの符号化表現と前記ビデオ領域のピクセルとの間の変換を実行するステップとを含む、ビデオ処理方法。
１４．条項１３に記載の方法であって、前記ビデオ条件はブロック・サイズであり、前記規則は、ルーマ・ブロックの小さなブロック・サイズについてイントラブロックコピー・モードの使用を許容する、方法。
１５．前記小さなブロック・サイズは、8×4、8×8、16×4または4×Nのルーマ・ブロック・サイズを含む、条項１４に記載の方法。
１６．前記規則は、MODE_TYPE_INTERモードの符号化を使用して、ビデオ領域の変換のためのイントラブロックコピー・モードの使用を許容する、条項１３に記載の方法。
１７．前記規則は、MODE_TYPE_INTERモードの符号化を使用して、ビデオ領域の変換のためのパレット符号化モードの使用を許容する、条項１３に記載の方法。
１３．あるビデオ条件について符号化モードの使用を許容する規則に基づいて、ある符号化モードがビデオ領域について許可されることを決定するステップと；前記決定に基づいて、前記ビデオ領域内のピクセルの符号化表現と前記ビデオ領域のピクセルとの間の変換を実行するステップとを含む、ビデオ処理方法。
１４．条項１３に記載の方法であって、前記ビデオ条件はブロック・サイズであり、前記規則は、ルーマ・ブロックの小さなブロック・サイズについてイントラブロックコピー・モードの使用を許容する、方法。
１５．前記小さなブロック・サイズは、8×4、8×8、16×4または4×Nのルーマ・ブロック・サイズを含む、条項１４に記載の方法。
１６．前記規則は、MODE_TYPE_INTERモードの符号化を使用して、ビデオ領域の変換のためのイントラブロックコピー・モードの使用を許容する、条項１３に記載の方法。
１７．前記規則は、MODE_TYPE_INTERモードの符号化を使用して、ビデオ領域の変換のためのパレット符号化モードの使用を許容する、条項１３に記載の方法。
以下の条項は、前のセクションの項目16、17、18に記載されている追加の技法と一緒に実装されうる。
１８．ビデオのビデオ・ブロックと前記ビデオ・ブロックの符号化表現との間の変換を、あるビデオ符号化モードを用いて実行するステップを含み、前記符号化モードを信号伝達する構文要素は、規則に基づいて前記符号化表現に選択的に含められる、ビデオ処理方法。
１９．前記ビデオ符号化モードは、ブロック内符号化モード〔イントラブロック符号化モード〕であり、前記規則は、前記符号化表現における前記構文要素の包含を制御するために、前記ビデオ符号化モードのタイプを使用することを規定する、条項１８に記載の方法。
２０．条項１９に記載の方法であって、前記規則は、非SKIPブロックを明示的に信号伝達することを規定する、方法。
２１．前記規則が、スキップフラグおよび前記ビデオ・ブロックのモード・タイプに基づいて、暗黙的にイントラブロックコピー・フラグを信号伝達することを規定する、条項１８に記載の方法。
２２．前記符号化モードはパレット符号化モードであり、前記規則は、前記ビデオ・ブロックのモード・タイプに基づいてパレット符号化インジケータを選択的に含めることを規定する、条項１８に記載の方法。
１８．ビデオのビデオ・ブロックと前記ビデオ・ブロックの符号化表現との間の変換を、あるビデオ符号化モードを用いて実行するステップを含み、前記符号化モードを信号伝達する構文要素は、規則に基づいて前記符号化表現に選択的に含められる、ビデオ処理方法。
１９．前記ビデオ符号化モードは、ブロック内符号化モード〔イントラブロック符号化モード〕であり、前記規則は、前記符号化表現における前記構文要素の包含を制御するために、前記ビデオ符号化モードのタイプを使用することを規定する、条項１８に記載の方法。
２０．条項１９に記載の方法であって、前記規則は、非SKIPブロックを明示的に信号伝達することを規定する、方法。
２１．前記規則が、スキップフラグおよび前記ビデオ・ブロックのモード・タイプに基づいて、暗黙的にイントラブロックコピー・フラグを信号伝達することを規定する、条項１８に記載の方法。
２２．前記符号化モードはパレット符号化モードであり、前記規則は、前記ビデオ・ブロックのモード・タイプに基づいてパレット符号化インジケータを選択的に含めることを規定する、条項１８に記載の方法。
以下の条項は、前のセクションの項目21に記載されている追加の技法と一緒に実装されうる。
２３．閾値サイズより小さいサイズを有するクロマ・ブロックのため、前記クロマ・ブロックと前記クロマ・ブロックの符号化表現との間の変換中に使用される変換タイプが、対応するルーマ・ブロック変換のために使用される変換タイプと異なることを決定するステップと；前記決定に基づいて前記変換を実行するステップとを含む、ビデオ処理の方法。
２４．前記閾値サイズがM×Nであり、Mが2である、条項２３に記載の方法。
２３．閾値サイズより小さいサイズを有するクロマ・ブロックのため、前記クロマ・ブロックと前記クロマ・ブロックの符号化表現との間の変換中に使用される変換タイプが、対応するルーマ・ブロック変換のために使用される変換タイプと異なることを決定するステップと；前記決定に基づいて前記変換を実行するステップとを含む、ビデオ処理の方法。
２４．前記閾値サイズがM×Nであり、Mが2である、条項２３に記載の方法。
以下の条項は、前のセクションの項目22に記載されている追加の技法と一緒に実装されうる。
２５．前記変換が、MODE_TYPE_INTRAモードとして、複合インターおよびイントラ予測モードを使用する、条項１ないし２４のうちいずれか一項に記載の方法。
２６．前記変換は、MODE_TYPE_INTERモードとして、複合インターおよびイントラ予測モードを使用する、条項１８ないし２２のうちいずれか一項に記載の方法。たとえば、CIIPをMODE_TYPE_INTERと考える場合、前のセクションの項目14～17に記述された方法が適用されうる。または、条項14～16に記述された方法が適用される場合、CIIPはMODE_TYPE_INTERと考えることができる。
２５．前記変換が、MODE_TYPE_INTRAモードとして、複合インターおよびイントラ予測モードを使用する、条項１ないし２４のうちいずれか一項に記載の方法。
２６．前記変換は、MODE_TYPE_INTERモードとして、複合インターおよびイントラ予測モードを使用する、条項１８ないし２２のうちいずれか一項に記載の方法。たとえば、CIIPをMODE_TYPE_INTERと考える場合、前のセクションの項目14～17に記述された方法が適用されうる。または、条項14～16に記述された方法が適用される場合、CIIPはMODE_TYPE_INTERと考えることができる。
以下の条項は、前のセクションの項目3～6に記載されている追加の技法と一緒に実装されうる。
２７．ビデオ領域のある符号化条件に基づいて、ビデオ領域の符号化表現と前記ビデオ領域のピクセル値との間の変換中に最小クロマ・ブロック規則が実施されるかどうかを判定するステップと；前記判定に基づいて前記変換を実行するステップとを含む、ビデオ処理の方法。
２８．前記符号化条件は、前記ビデオ領域の色フォーマットを含む、条項１７に記載の方法。
２９．前記ビデオ領域は、Mピクセルの幅およびNピクセルの高さを有し、前記符号化条件は、Mおよび／またはNの値にさらに依存する、条項１８に記載の方法。
３０．4:2:2色フォーマットおよびM*N＝32またはM*N=64を有するビデオ領域のため、前記最小クロマ・ブロック規則が有効にされる、条項２９に記載の方法。
２７．ビデオ領域のある符号化条件に基づいて、ビデオ領域の符号化表現と前記ビデオ領域のピクセル値との間の変換中に最小クロマ・ブロック規則が実施されるかどうかを判定するステップと；前記判定に基づいて前記変換を実行するステップとを含む、ビデオ処理の方法。
２８．前記符号化条件は、前記ビデオ領域の色フォーマットを含む、条項１７に記載の方法。
２９．前記ビデオ領域は、Mピクセルの幅およびNピクセルの高さを有し、前記符号化条件は、Mおよび／またはNの値にさらに依存する、条項１８に記載の方法。
３０．4:2:2色フォーマットおよびM*N＝32またはM*N=64を有するビデオ領域のため、前記最小クロマ・ブロック規則が有効にされる、条項２９に記載の方法。
以下の条項は、前のセクションの項目7～11に記載されている追加の技法と一緒に実装されうる。
３１．4:2:2フォーマットでのビデオ領域の符号化表現と前記ビデオ領域のピクセル値との間の変換のために、前記ビデオ領域について最小クロマ・ブロック規則が有効にされるかどうかに基づいて、前記変換に使用されるモード・タイプを決定するステップと；前記決定に基づいて前記変換を実行するステップとを含む、ビデオ処理方法。
３２．前記ビデオ領域が4:2:2フォーマットを有し、前記最小クロマ・ブロック規則が有効にされるため、前記ビデオ領域のモード・タイプが1に設定される、条項３１に記載の方法。
３３．前記モード・タイプを決定することが、前記最小のクロマ・ブロック規則が前記ビデオ領域について有効にされているため、前記モード・タイプをINTRAタイプであるように決定することを含む、条項３１に記載の方法。
３４．前記モード・タイプを決定することが、前記最小クロマ・ブロック規則が前記ビデオ領域について有効にされているのため、前記モード・タイプINTERが無効にされることを決定することを含む、条項３１に記載の方法。
３１．4:2:2フォーマットでのビデオ領域の符号化表現と前記ビデオ領域のピクセル値との間の変換のために、前記ビデオ領域について最小クロマ・ブロック規則が有効にされるかどうかに基づいて、前記変換に使用されるモード・タイプを決定するステップと；前記決定に基づいて前記変換を実行するステップとを含む、ビデオ処理方法。
３２．前記ビデオ領域が4:2:2フォーマットを有し、前記最小クロマ・ブロック規則が有効にされるため、前記ビデオ領域のモード・タイプが1に設定される、条項３１に記載の方法。
３３．前記モード・タイプを決定することが、前記最小のクロマ・ブロック規則が前記ビデオ領域について有効にされているため、前記モード・タイプをINTRAタイプであるように決定することを含む、条項３１に記載の方法。
３４．前記モード・タイプを決定することが、前記最小クロマ・ブロック規則が前記ビデオ領域について有効にされているのため、前記モード・タイプINTERが無効にされることを決定することを含む、条項３１に記載の方法。
以下の条項は、前のセクションの項目7～11に記載されている追加の技法と一緒に実装されうる。
３５．ビデオ・ブロックの符号化表現とビデオのビデオ・ブロックとの間の変換について、前記変換中に使用されるモード・タイプまたは前記ビデオ・ブロックの寸法に基づいて、ブロック分割が前記変換中に許容されるかどうかを決定するステップと；前記決定を使用して前記変換を実行するステップとを含む、ビデオ処理の方法。
３６．前記ブロック部分化は、二分木分割または三分木分割を含む、条項３５に記載の方法。
３７．モード・タイプがINTERモードである場合、ブロック分割は、パーティションタイプを許容または禁止する制約規則に基づく、条項３５～３６のうちいずれか一項に記載の方法。
３５．ビデオ・ブロックの符号化表現とビデオのビデオ・ブロックとの間の変換について、前記変換中に使用されるモード・タイプまたは前記ビデオ・ブロックの寸法に基づいて、ブロック分割が前記変換中に許容されるかどうかを決定するステップと；前記決定を使用して前記変換を実行するステップとを含む、ビデオ処理の方法。
３６．前記ブロック部分化は、二分木分割または三分木分割を含む、条項３５に記載の方法。
３７．モード・タイプがINTERモードである場合、ブロック分割は、パーティションタイプを許容または禁止する制約規則に基づく、条項３５～３６のうちいずれか一項に記載の方法。
以下の条項は、前のセクションの項目34に記載されている追加の技法と一緒に実装されうる。
３８．ビデオのビデオ・セグメントの符号化表現と前記ビデオ・セグメントとの間の変換のために、サイズM×Nのクロマ・ブロックについて特別な処理モードを適用するように決定するステップであって、M×Nは整数である、ステップと；前記決定に基づいて前記変換を実行するステップとを含む、ビデオ処理方法。
３９．前記特別な処理モードは、前記変換中のクロマ・ブロックの使用を無効にする、条項３８に記載の方法。
４０．前記特別な処理モードは、前記クロマ・ブロックのイントラ予測のためにDC予測を使用する、条項３８に記載の方法。
４１．前記特別な処理モードは、対応するダウンサンプリングされたルーマ係数からクロマ・ブロックのイントラ係数を予測するために、成分横断線形モデルを使用することを含む、条項３８に記載の方法。
４２．前記特別な処理モードは、前記ビデオ・セグメントがデュアルツリー分割を使用するため、前記クロマ・ブロックの使用を無効にする、条項３８～４１のいずれかの方法。
４３．前記特別な処理モードは、前記ビデオ・セグメントがシングルツリー分割を使用するため、前記クロマ・ブロックの使用を無効にする、条項３８～４１のいずれかの方法。
４４．前記変換が、前記ビデオを前記符号化表現にエンコードすることを含む、条項１ないし４３のうちいずれかに記載の方法。
４５．前記変換が、前記ビデオのピクセル値を生成するために、前記符号化表現をデコードすることを含む、条項１ないし４３のうちいずれかに記載の方法。
４６．条項１ないし４５のうち一つまたは複数に記載の方法を実装するように構成されたプロセッサを含む、ビデオ・デコード装置。
４７．条項１ないし４５のうち一つまたは複数に記載の方法を実装するように構成されたプロセッサを含む、ビデオ・エンコード装置。
４８．コンピュータ・コードが記憶されているコンピュータ・プログラム・プロダクトであって、前記コードは、プロセッサによって実行されると、プロセッサに、条項１ないし４５のうちいずれかに記載の方法を実行させる、コンピュータ・プログラム・プロダクト。
４９．本稿に記載された方法、装置またはシステム。
３８．ビデオのビデオ・セグメントの符号化表現と前記ビデオ・セグメントとの間の変換のために、サイズM×Nのクロマ・ブロックについて特別な処理モードを適用するように決定するステップであって、M×Nは整数である、ステップと；前記決定に基づいて前記変換を実行するステップとを含む、ビデオ処理方法。
３９．前記特別な処理モードは、前記変換中のクロマ・ブロックの使用を無効にする、条項３８に記載の方法。
４０．前記特別な処理モードは、前記クロマ・ブロックのイントラ予測のためにDC予測を使用する、条項３８に記載の方法。
４１．前記特別な処理モードは、対応するダウンサンプリングされたルーマ係数からクロマ・ブロックのイントラ係数を予測するために、成分横断線形モデルを使用することを含む、条項３８に記載の方法。
４２．前記特別な処理モードは、前記ビデオ・セグメントがデュアルツリー分割を使用するため、前記クロマ・ブロックの使用を無効にする、条項３８～４１のいずれかの方法。
４３．前記特別な処理モードは、前記ビデオ・セグメントがシングルツリー分割を使用するため、前記クロマ・ブロックの使用を無効にする、条項３８～４１のいずれかの方法。
４４．前記変換が、前記ビデオを前記符号化表現にエンコードすることを含む、条項１ないし４３のうちいずれかに記載の方法。
４５．前記変換が、前記ビデオのピクセル値を生成するために、前記符号化表現をデコードすることを含む、条項１ないし４３のうちいずれかに記載の方法。
４６．条項１ないし４５のうち一つまたは複数に記載の方法を実装するように構成されたプロセッサを含む、ビデオ・デコード装置。
４７．条項１ないし４５のうち一つまたは複数に記載の方法を実装するように構成されたプロセッサを含む、ビデオ・エンコード装置。
４８．コンピュータ・コードが記憶されているコンピュータ・プログラム・プロダクトであって、前記コードは、プロセッサによって実行されると、プロセッサに、条項１ないし４５のうちいずれかに記載の方法を実行させる、コンピュータ・プログラム・プロダクト。
４９．本稿に記載された方法、装置またはシステム。
第2の組の条項は、前のセクションの項目34～36に記載されている追加の技法と一緒に実装されうる。
１．ビデオ処理方法（たとえば、図21に示す方法2100）であって、ビデオのビデオ・ピクチャーのビデオ領域のクロマ・ブロックと、前記ビデオの符号化表現との間の変換を規則に従って実行2102することを含み、前記規則は、前記クロマ・ブロックがサイズM×Nを有するため、前記クロマ・ブロックがイントラ符号化モードを用いて前記符号化表現において表現されることが禁止されることを規定し、MおよびNは、それぞれ前記クロマ・ブロックの幅および高さを示す整数であり、前記イントラ符号化モードは、前記ビデオ・ピクチャーの前に符号化されたビデオ領域に基づいて前記クロマ・ブロックを符号化することを含む、ビデオ処理方法。
２．前記規則は、DC予測モードが前記クロマ・ブロックに使用されることをさらに規定し、前記DC予測モードは、クロマ成分の予測値を前記クロマ・ブロックの近傍ブロックの平均に基づいて導出する、条項１に記載の方法。
３．前記規則が、前記クロマ・ブロックについて成分横断線形モデル（CCLM）予測モードが使用されることをさらに規定し、前記CCLM予測モードは、クロマ成分の予測値を他の成分から導出するために線形モードを使用する、条項１に記載の方法。
４．M＝2クロマ・サンプルであり、N＝8、16、または32クロマ・サンプルである、条項２または３に記載の方法。
５．前記規則が、さらに、DC予測モードまたはCCLM予測モードのために、再構成された近傍ピクセルが使用されないことを規定する、条項２または３に記載の方法。
６．前記規則は、近傍参照ピクセルが、DC予測モードについて1<<（bitDepth－1）に設定されることをさらに規定する、条項２に記載の方法。
７．前記規則は、位置依存イントラ予測結合（PDPC）法が前記DC予測モードまたは前記CCLM予測モードについて適用されないことをさらに規定し、前記PDPC法は、近傍サンプルを前記ビデオ領域の予測信号と組み合わせて、前記ビデオ領域の洗練された予測信号を生成する、条項２または３に記載の方法。
８．前記規則が、さらに、前記DC予測モードまたは前記CCLM予測モードに関する情報が、前記クロマ・ブロックについて符号化されることなく、導出されることを規定する、条項２または３に記載の方法。
９．前記規則は、さらに、predC＝a*recL＋bを満たすCCLM予測モードについて、クロマ予測値predCがルーマ再構成値recLおよびパラメータaおよびbから導出され、それはビデオ領域の開始時にデフォルトの固定値に初期化されることを規定する、条項８に記載の方法。
１０．パラメータaおよびbを更新するために先入れ先出しテーブルが維持される、条項９に記載の方法。
１１．条項１ないし１０のうちのいずれかに記載の方法であって、前記規則が、前記CCLM予測を用いて符号化され、Mに等しくない幅またはNに等しくない高さを有する別のクロマ・ブロックに適用される、方法。
１２．前記ビデオ領域の近傍ブロックの再構成情報に基づいて導出される代わりに、前記ビデオ領域のために、前に符号化されたビデオ領域のCCLMパラメータが利用される、条項１１に記載の方法。
１３．前記CCLMパラメータがテーブルに記憶され、先入れ先出しテーブルを使用して更新される、条項１１に記載の方法。
１４．ビデオのビデオ・ピクチャーのビデオ領域のクロマ・ブロックと、前記ビデオの符号化表現との間の変換を規則に従って実行するステップを含み、前記規則は、サイズM×Nを有する前記クロマ・ブロックが、デュアルツリー分割が使用される場合にイントラ符号化モードを使用して前記符号化表現において表現されることを禁止されることを規定し、MおよびNは、それぞれ、前記クロマ・ブロックの幅および高さを示す整数であり、前記イントラ符号化モードは、前記ビデオ・ピクチャーの、前に符号化されたビデオ領域に基づいて前記クロマ・ブロックを符号化することを含む、ビデオ処理の方法。
１５．M＝2クロマ・サンプルであり、N＝8、16、または32クロマ・サンプルである、条項１４に記載の方法。
１６．前記規則は、さらに、デュアルツリー分割のため、（M*a）×（N*b）に等しい寸法を有する符号化ツリー・ノードであるビデオ領域について、ある分割方式が無効にされることを規定する、条項１４に記載の方法であって、M*aは、符号化ツリー・ノードの幅におけるクロマ・サンプルの数であり、N*bは、符号化ツリー・ノードの高さにおけるクロマ・サンプルの数である、方法。
１７．前記ある分割方式は、ビデオ領域が垂直方向に沿って2つの部分に分割される垂直二分木（BT）分割であり、a＝2およびb＝1である、条項１６に記載の方法。
１８．前記ある分割方式は、ビデオ領域が水平方向に沿って2つの部分に分割される水平二分木（BT）分割であり、a＝1およびb＝2である、条項１６に記載の方法。
１９．前記ある分割方式は、ビデオ領域が垂直方向に沿って3つの部分に分割される垂直三分木（TT）分割であり、a＝4およびb＝1である、条項１６に記載の方法。
２０．前記ある分割方式は、ビデオ領域が水平方向に沿って3つの部分に分割される水平三分木（TT）分割であり、a＝1およびb＝4である、条項１６に記載の方法。
２１．ビデオのビデオ・ピクチャーのビデオ領域のクロマ・ブロックと、前記ビデオの符号化表現との間の変換を規則に従って実行するステップを含み、前記規則は、サイズM×Nを有する前記クロマ・ブロックが、シングルツリー分割が用いられる場合にイントラ符号化モードを用いて、前記符号化表現において表現されることを禁止されることを規定し、MおよびNは、それぞれ、前記クロマ・ブロックの幅および高さを示す整数であり、前記イントラ符号化モードは、前記ビデオ・ピクチャーの、前に符号化されたビデオ領域に基づいて前記クロマ・ブロックを符号化することを含む、ビデオ処理方法。
２２．M＝2クロマ・サンプルであり、N＝8、16、または32クロマ・サンプルである、条項２１に記載の方法。
２３．前記規則は、さらに、シングルツリー分割のため、（M*a*subWidthC）x（N*b*subHeightC）に等しい寸法を有する符号化ツリー・ノードである前記ビデオ領域のクロマ成分について、ある分割方式が無効にされることを規定する、条項２１または２２に記載の方法であって、M*aは、前記符号化ツリー・ノードの幅におけるルーマ・サンプルの数であり、N*bは、前記符号化ツリー・ノードの高さにおけるルーマ・サンプルの数であり、subWidthCおよびsubHeightCは、それぞれ、幅および高さにおけるクロマ・サブサンプリング比を示す、方法。
２４．前記ある分割方式は、ビデオ領域が垂直方向に沿って2つの部分に分割される垂直二分木（BT）分割であり、a＝2およびb＝1である、条項２３に記載の方法。
２５．前記ある分割方式は、ビデオ領域が垂直方向に沿って3つの部分に分割される垂直三分木（TT）分割であり、a＝4およびb＝1である、条項２３に記載の方法。
２６．前記ある分割方式は、ビデオ領域が水平方向に沿って2つの部分に分割される水平二分木（BT）分割であり、a＝1およびb＝2である、条項２３に記載の方法。
２７．前記ある分割方式は、ビデオ領域が水平方向に沿って3つの部分に分割される水平三分木（TT）分割であり、a＝1およびb＝2である、条項２３に記載の方法。
２８．前記ある分割方式は、ビデオ領域が水平方向に沿って3つの部分に分割される水平三分木（TT）分割であり、a＝1およびb＝4である、条項２３に記載の方法。
２９．前記クロマ・ブロックが（M*a）×（N*d）に等しい寸法を有する、条項２３に記載の方法。
３０．前記クロマ・ブロックの符号化タイプが、前記変換のためのイントラモード、パレット・モード、およびイントラブロックコピー・モードの使用を許容するMODE_TYPE_INTRAである、条項２３に記載の方法。
３１．前記規則が、前記ある分割方式が、前記符号化ツリー・ノードのルーマ成分について許容されることをさらに規定する、条項２３に記載の方法。
３２．前記符号化ツリー・ノードは、子ノードに分割され、子ノードについてインター・モードおよび／またはイントラブロックコピー・モードが許容される、条項３１に記載の方法。
３３．前記規則は、クロマ成分が共位置のルーマ成分に沿って分割され、前記クロマ成分についてインター・モードおよび／またはイントラブロックコピー・モードが許容されることをさらに規定する、条項２２に記載の方法。
３４．ビデオのビデオ領域のクロマ・ブロックと、前記ビデオの符号化表現との間の変換を規則に従って実行するステップを含み、前記規則は、サイズM×Nを有する前記クロマ・ブロックが、インター予測をイントラ予測とを組み合わせる複合インターおよびイントラ予測（CIIP）モードを用いて前記符号化表現において表現されることを禁止されることを規定し、MおよびNは、それぞれ、前記クロマ・ブロックの幅および高さを示す整数である、ビデオ処理方法。
３５．前記規則は、さらに、（M*subWidthC）×（N*subHeightC）に等しい寸法を有する符号化ツリー・ノードである前記ビデオ領域のクロマ成分についてCIIPモードが許容されないことを規定し、それにより、subWidthCおよびsubHeightCは、それぞれ、幅および高さ次元におけるクロマ・サブサンプリング比を示す、条項３４に記載の方法。
３６．前記変換を実行することが、前記ビデオ領域が前記CIIPモードを使用して符号化される場合に、前記インター予測を使用して前記クロマ・ブロックの諸予測を混合することによって、前記クロマ・ブロックのクロマ予測ブロックを決定するクロマ混合プロセスを含む、条項３４に記載の方法。
３７．前記規則が、さらに、ルーマ・イントラ予測が前記ビデオ領域に適用され、クロマ・イントラ予測が（M*subWidthC）×（N*subHeightC）に等しい寸法を有する前記ビデオ領域に適用されないことを規定し、それにより、subWidthCおよびsubHeightCは、それぞれ、幅および高さの次元におけるクロマ・サブサンプリング比を示す、条項３６に記載の方法。
３８．前記規則は、前記ビデオ領域が前記CIIPモードを使用して符号化される場合に、前記サイズM×Nを有する前記クロマ・ブロックについてDC予測が使用されることをさらに規定する、条項３４に記載の方法。
３９．前記規則は、さらに、前記ビデオ領域が前記CIIPモードを使用して符号化される場合、サイズM×Nを有するクロマ・ブロックについて、クロマ成分の予測値を別の成分から導出するために線形モードを使用するCCLM予測が使用されることを規定する、条項３４に記載の方法。
４０．ビデオのビデオ領域と前記ビデオの符号化表現との間の変換を規則に従って実行するステップを含み、前記規則は、前記ビデオ領域に適用可能な最大変換サイズが信号伝達されるかどうか、およびどのようにして信号伝達されるかが、前記符号化表現において前記ビデオ領域を表現するために使用される符号化モード・タイプに依存することを規定し、前記符号化モード・タイプは、（i）前記ビデオ領域に適用される量子化パラメータ（QP）が閾値よりも小さい、ほぼ無損失〔可逆〕の符号化モード、（ii）前記ビデオ領域についての残差データの変換がバイパスされる無損失の符号化モード、または（iii）前記ビデオ領域についての残差データの変換がスキップされる損失のある符号化モードである、ビデオ処理方法。
４１．前記規則は、さらに、前記無損失の符号化モードおよび／または前記ほぼ無損失の符号化モードについての最大変換サイズがmaxLosslessTbSizeYに等しいことを規定する、条項４０に記載の方法。
４２．前記無損失の符号化モードは、構文要素cu_transquant_bypass_flagを使用して、符号化単位レベルで信号伝達される、条項４０に記載の方法。
４３．前記閾値は、デコーダパラメータセット（DPS）、ビデオパラメータセット（VPS）、シーケンスパラメータセット（SPS）、ピクチャーパラメータセット（PPS）、タイル、スライス、またはブリックヘッダ内で信号伝達される、条項４０に記載の方法。
４４．前記ビデオ領域のほぼ無損失の符号化モードについてtransform_skip_flagが1に等しい、条項４０に記載の方法。
４５．前記規則は、さらに、前記ビデオ領域の前記無損失の符号化モードおよび／または前記ほぼ無損失の符号化モードについての第1の最大変換サイズが、i）前記損失のある符号化モードに使用される別の最大変換サイズ、ii）最大符号化ツリー単位サイズ、および／または、iii）最大変換スキップサイズに基づいて設定されることを規定する、条項４０に記載の方法。
４６．前記ビデオ領域の前記無損失の符号化モードまたは前記ほぼ無損失の符号化モードについての最大変換サイズは、シーケンスパラメータセット（SPS）、ビデオパラメータセット（VPS）、ピクチャーパラメータセット（PPS）、サブピクチャー、スライス、タイル、ブリック、符号化ツリー単位（CTU）、または仮想パイプラインデータ単位（VPDU）における構文要素（SE）に対応するビデオ単位レベルで信号伝達される、条項４０に記載の方法。
４７．SEが、最大符号化ツリーブロック・サイズ（CTB）、最大変換サイズ、および／または最大変換スキップサイズに依存して信号伝達される、条項４６に記載の方法。
４８．log2_ctu_size_minus5がNより大きく、Nが整数である場合に、SEが信号伝達される、条項４７に記載の方法。
４９．sps_max_luma_transform_size_64_flagがMに等しく、Mが整数である場合に、SEが信号伝達される、条項４７に記載の方法。
５０．log2_transform_skip_max_size_minus2がKより大きい場合に、SEが信号伝達される、条項４７に記載の方法。
５１．log（maxLosslessTbSizeY）とXとの間の差分が信号伝達され、maxLosslessTbSizeYは、前記ビデオ領域の、前記ほぼ無損失の符号化モードまたは前記無損失の符号化モードについて最大変換サイズを示す、条項４７に記載の方法。
５２．Xが、log2_ctu_size_minus5、sps_max_luma_transform_size_64_flag、log2_transform_sk_max_size_minus2、または固定した整数に等しい、条項５１に記載の方法。
５３．maxLosslessTbSizeYとXとの間の差分が信号伝達され、maxLosslessTbSizeYは前記ビデオ領域の前記ほぼ無損失の符号化モードまたは前記無損失の符号化モードについての最大変換サイズを示す、条項４７に記載の方法。
５４．maxLosslessTbSizeYとX－Kとの間の差に対応する値が信号伝達され、maxLosslessTbSizeYは、前記ビデオ領域の前記ほぼ無損失の符号化モードまたは前記無損失の符号化モードについての最大変換サイズを示し、Kは整数である、条項４７に記載の方法。
５５．XがCtbSizeY、MaxTbSize、MaxTsSize、または固定整数に等しい、条項５３または５４に記載の方法。
５６．前記ビデオ領域のmaxLosslessTbSizeYは、前記SEから導出され、maxLosslessTbSizeYは、前記ビデオ領域の前記ほぼ無損失の符号化モードまたは前記無損失の符号化モードについての前記最大変換サイズを示す、条項４６に記載の方法。
５７．前記構文要素はフラグに対応する、条項４６に記載の方法。
５８．前記フラグが存在しない場合、正の整数値である値が推定される、条項５７に記載の方法。
５９．前記規則は、前記ビデオ領域の前記無損失の符号化モードおよび／または前記ほぼ無損失の符号化モードについて、前記最大変換サイズが導出されることをさらに規定する、条項４０に記載の方法。
６０．前記最大変換サイズは、i）固定整数値、ii）前記損失のある符号化モードに使用される別の最大変換サイズ、iii）最大符号化ツリー単位サイズ、iv）VPDUサイズ、v）最大変換スキップ・ブロック・サイズ、またはvi）最大残差符号化ブロック・サイズに等しいように設定される、条項５９に記載の方法。
６１．ビデオ処理方法であって、ビデオのビデオ領域と、前記ビデオの符号化表現との間の変換を規則に従って実行するステップを含み、
前記規則は、ビデオ領域の残差ブロックが、無損失の符号化および／またはほぼ無損失の符号化が適用される前記ビデオ領域の最大変換サイズに基づいて、無損失の符号化および／またはほぼ無損失の符号化のための一つまたは複数の残差サブブロックに分割されることを規定し、前記無損失の符号化は、前記ビデオ領域について残差ブロックの変換をバイパスすることを含み、前記ほぼ無損失の符号化は、閾値より小さい量子化パラメータ（QP）を使用する、方法。
６２．前記規則は、さらに、前記分割後に得られる前記一つまたは複数の残差サブブロックの幅および高さが、前記最大変換サイズより大きくないことを規定する、条項６１に記載の方法。
６３．前記規則は、前記一つまたは複数の残差サブブロックの幅および高さが前記最大変換サイズ以下になるまで、前記残差ブロックの分割を繰り返すことをさらに規定する、条項６２に記載の方法。
６４．前記変換は、前記ビデオを前記符号化表現にエンコードすることを含む、条項１ないし６３のうちいずれかに記載の方法。
６５．前記変換は、前記符号化表現をデコードして前記ビデオを生成することを含む、条項１ないし６３のうちいずれかに記載の方法。
６６．条項１ないし６５のうち一つまたは複数に記載の方法を実装するように構成されたプロセッサを備える、ビデオ処理装置。
６７．プログラムコードが記憶されているコンピュータ可読媒体であって、前記プログラムコードは、実行されると、プロセッサに、条項１ないし６５のうちいずれか一つまたは複数に記載された方法を実装させる、媒体。
６８．上述の方法のいずれかに従って生成された符号化表現またはビットストリーム表現を格納するコンピュータ可読媒体。
１．ビデオ処理方法（たとえば、図21に示す方法2100）であって、ビデオのビデオ・ピクチャーのビデオ領域のクロマ・ブロックと、前記ビデオの符号化表現との間の変換を規則に従って実行2102することを含み、前記規則は、前記クロマ・ブロックがサイズM×Nを有するため、前記クロマ・ブロックがイントラ符号化モードを用いて前記符号化表現において表現されることが禁止されることを規定し、MおよびNは、それぞれ前記クロマ・ブロックの幅および高さを示す整数であり、前記イントラ符号化モードは、前記ビデオ・ピクチャーの前に符号化されたビデオ領域に基づいて前記クロマ・ブロックを符号化することを含む、ビデオ処理方法。
２．前記規則は、DC予測モードが前記クロマ・ブロックに使用されることをさらに規定し、前記DC予測モードは、クロマ成分の予測値を前記クロマ・ブロックの近傍ブロックの平均に基づいて導出する、条項１に記載の方法。
３．前記規則が、前記クロマ・ブロックについて成分横断線形モデル（CCLM）予測モードが使用されることをさらに規定し、前記CCLM予測モードは、クロマ成分の予測値を他の成分から導出するために線形モードを使用する、条項１に記載の方法。
４．M＝2クロマ・サンプルであり、N＝8、16、または32クロマ・サンプルである、条項２または３に記載の方法。
５．前記規則が、さらに、DC予測モードまたはCCLM予測モードのために、再構成された近傍ピクセルが使用されないことを規定する、条項２または３に記載の方法。
６．前記規則は、近傍参照ピクセルが、DC予測モードについて1<<（bitDepth－1）に設定されることをさらに規定する、条項２に記載の方法。
７．前記規則は、位置依存イントラ予測結合（PDPC）法が前記DC予測モードまたは前記CCLM予測モードについて適用されないことをさらに規定し、前記PDPC法は、近傍サンプルを前記ビデオ領域の予測信号と組み合わせて、前記ビデオ領域の洗練された予測信号を生成する、条項２または３に記載の方法。
８．前記規則が、さらに、前記DC予測モードまたは前記CCLM予測モードに関する情報が、前記クロマ・ブロックについて符号化されることなく、導出されることを規定する、条項２または３に記載の方法。
９．前記規則は、さらに、predC＝a*recL＋bを満たすCCLM予測モードについて、クロマ予測値predCがルーマ再構成値recLおよびパラメータaおよびbから導出され、それはビデオ領域の開始時にデフォルトの固定値に初期化されることを規定する、条項８に記載の方法。
１０．パラメータaおよびbを更新するために先入れ先出しテーブルが維持される、条項９に記載の方法。
１１．条項１ないし１０のうちのいずれかに記載の方法であって、前記規則が、前記CCLM予測を用いて符号化され、Mに等しくない幅またはNに等しくない高さを有する別のクロマ・ブロックに適用される、方法。
１２．前記ビデオ領域の近傍ブロックの再構成情報に基づいて導出される代わりに、前記ビデオ領域のために、前に符号化されたビデオ領域のCCLMパラメータが利用される、条項１１に記載の方法。
１３．前記CCLMパラメータがテーブルに記憶され、先入れ先出しテーブルを使用して更新される、条項１１に記載の方法。
１４．ビデオのビデオ・ピクチャーのビデオ領域のクロマ・ブロックと、前記ビデオの符号化表現との間の変換を規則に従って実行するステップを含み、前記規則は、サイズM×Nを有する前記クロマ・ブロックが、デュアルツリー分割が使用される場合にイントラ符号化モードを使用して前記符号化表現において表現されることを禁止されることを規定し、MおよびNは、それぞれ、前記クロマ・ブロックの幅および高さを示す整数であり、前記イントラ符号化モードは、前記ビデオ・ピクチャーの、前に符号化されたビデオ領域に基づいて前記クロマ・ブロックを符号化することを含む、ビデオ処理の方法。
１５．M＝2クロマ・サンプルであり、N＝8、16、または32クロマ・サンプルである、条項１４に記載の方法。
１６．前記規則は、さらに、デュアルツリー分割のため、（M*a）×（N*b）に等しい寸法を有する符号化ツリー・ノードであるビデオ領域について、ある分割方式が無効にされることを規定する、条項１４に記載の方法であって、M*aは、符号化ツリー・ノードの幅におけるクロマ・サンプルの数であり、N*bは、符号化ツリー・ノードの高さにおけるクロマ・サンプルの数である、方法。
１７．前記ある分割方式は、ビデオ領域が垂直方向に沿って2つの部分に分割される垂直二分木（BT）分割であり、a＝2およびb＝1である、条項１６に記載の方法。
１８．前記ある分割方式は、ビデオ領域が水平方向に沿って2つの部分に分割される水平二分木（BT）分割であり、a＝1およびb＝2である、条項１６に記載の方法。
１９．前記ある分割方式は、ビデオ領域が垂直方向に沿って3つの部分に分割される垂直三分木（TT）分割であり、a＝4およびb＝1である、条項１６に記載の方法。
２０．前記ある分割方式は、ビデオ領域が水平方向に沿って3つの部分に分割される水平三分木（TT）分割であり、a＝1およびb＝4である、条項１６に記載の方法。
２１．ビデオのビデオ・ピクチャーのビデオ領域のクロマ・ブロックと、前記ビデオの符号化表現との間の変換を規則に従って実行するステップを含み、前記規則は、サイズM×Nを有する前記クロマ・ブロックが、シングルツリー分割が用いられる場合にイントラ符号化モードを用いて、前記符号化表現において表現されることを禁止されることを規定し、MおよびNは、それぞれ、前記クロマ・ブロックの幅および高さを示す整数であり、前記イントラ符号化モードは、前記ビデオ・ピクチャーの、前に符号化されたビデオ領域に基づいて前記クロマ・ブロックを符号化することを含む、ビデオ処理方法。
２２．M＝2クロマ・サンプルであり、N＝8、16、または32クロマ・サンプルである、条項２１に記載の方法。
２３．前記規則は、さらに、シングルツリー分割のため、（M*a*subWidthC）x（N*b*subHeightC）に等しい寸法を有する符号化ツリー・ノードである前記ビデオ領域のクロマ成分について、ある分割方式が無効にされることを規定する、条項２１または２２に記載の方法であって、M*aは、前記符号化ツリー・ノードの幅におけるルーマ・サンプルの数であり、N*bは、前記符号化ツリー・ノードの高さにおけるルーマ・サンプルの数であり、subWidthCおよびsubHeightCは、それぞれ、幅および高さにおけるクロマ・サブサンプリング比を示す、方法。
２４．前記ある分割方式は、ビデオ領域が垂直方向に沿って2つの部分に分割される垂直二分木（BT）分割であり、a＝2およびb＝1である、条項２３に記載の方法。
２５．前記ある分割方式は、ビデオ領域が垂直方向に沿って3つの部分に分割される垂直三分木（TT）分割であり、a＝4およびb＝1である、条項２３に記載の方法。
２６．前記ある分割方式は、ビデオ領域が水平方向に沿って2つの部分に分割される水平二分木（BT）分割であり、a＝1およびb＝2である、条項２３に記載の方法。
２７．前記ある分割方式は、ビデオ領域が水平方向に沿って3つの部分に分割される水平三分木（TT）分割であり、a＝1およびb＝2である、条項２３に記載の方法。
２８．前記ある分割方式は、ビデオ領域が水平方向に沿って3つの部分に分割される水平三分木（TT）分割であり、a＝1およびb＝4である、条項２３に記載の方法。
２９．前記クロマ・ブロックが（M*a）×（N*d）に等しい寸法を有する、条項２３に記載の方法。
３０．前記クロマ・ブロックの符号化タイプが、前記変換のためのイントラモード、パレット・モード、およびイントラブロックコピー・モードの使用を許容するMODE_TYPE_INTRAである、条項２３に記載の方法。
３１．前記規則が、前記ある分割方式が、前記符号化ツリー・ノードのルーマ成分について許容されることをさらに規定する、条項２３に記載の方法。
３２．前記符号化ツリー・ノードは、子ノードに分割され、子ノードについてインター・モードおよび／またはイントラブロックコピー・モードが許容される、条項３１に記載の方法。
３３．前記規則は、クロマ成分が共位置のルーマ成分に沿って分割され、前記クロマ成分についてインター・モードおよび／またはイントラブロックコピー・モードが許容されることをさらに規定する、条項２２に記載の方法。
３４．ビデオのビデオ領域のクロマ・ブロックと、前記ビデオの符号化表現との間の変換を規則に従って実行するステップを含み、前記規則は、サイズM×Nを有する前記クロマ・ブロックが、インター予測をイントラ予測とを組み合わせる複合インターおよびイントラ予測（CIIP）モードを用いて前記符号化表現において表現されることを禁止されることを規定し、MおよびNは、それぞれ、前記クロマ・ブロックの幅および高さを示す整数である、ビデオ処理方法。
３５．前記規則は、さらに、（M*subWidthC）×（N*subHeightC）に等しい寸法を有する符号化ツリー・ノードである前記ビデオ領域のクロマ成分についてCIIPモードが許容されないことを規定し、それにより、subWidthCおよびsubHeightCは、それぞれ、幅および高さ次元におけるクロマ・サブサンプリング比を示す、条項３４に記載の方法。
３６．前記変換を実行することが、前記ビデオ領域が前記CIIPモードを使用して符号化される場合に、前記インター予測を使用して前記クロマ・ブロックの諸予測を混合することによって、前記クロマ・ブロックのクロマ予測ブロックを決定するクロマ混合プロセスを含む、条項３４に記載の方法。
３７．前記規則が、さらに、ルーマ・イントラ予測が前記ビデオ領域に適用され、クロマ・イントラ予測が（M*subWidthC）×（N*subHeightC）に等しい寸法を有する前記ビデオ領域に適用されないことを規定し、それにより、subWidthCおよびsubHeightCは、それぞれ、幅および高さの次元におけるクロマ・サブサンプリング比を示す、条項３６に記載の方法。
３８．前記規則は、前記ビデオ領域が前記CIIPモードを使用して符号化される場合に、前記サイズM×Nを有する前記クロマ・ブロックについてDC予測が使用されることをさらに規定する、条項３４に記載の方法。
３９．前記規則は、さらに、前記ビデオ領域が前記CIIPモードを使用して符号化される場合、サイズM×Nを有するクロマ・ブロックについて、クロマ成分の予測値を別の成分から導出するために線形モードを使用するCCLM予測が使用されることを規定する、条項３４に記載の方法。
４０．ビデオのビデオ領域と前記ビデオの符号化表現との間の変換を規則に従って実行するステップを含み、前記規則は、前記ビデオ領域に適用可能な最大変換サイズが信号伝達されるかどうか、およびどのようにして信号伝達されるかが、前記符号化表現において前記ビデオ領域を表現するために使用される符号化モード・タイプに依存することを規定し、前記符号化モード・タイプは、（i）前記ビデオ領域に適用される量子化パラメータ（QP）が閾値よりも小さい、ほぼ無損失〔可逆〕の符号化モード、（ii）前記ビデオ領域についての残差データの変換がバイパスされる無損失の符号化モード、または（iii）前記ビデオ領域についての残差データの変換がスキップされる損失のある符号化モードである、ビデオ処理方法。
４１．前記規則は、さらに、前記無損失の符号化モードおよび／または前記ほぼ無損失の符号化モードについての最大変換サイズがmaxLosslessTbSizeYに等しいことを規定する、条項４０に記載の方法。
４２．前記無損失の符号化モードは、構文要素cu_transquant_bypass_flagを使用して、符号化単位レベルで信号伝達される、条項４０に記載の方法。
４３．前記閾値は、デコーダパラメータセット（DPS）、ビデオパラメータセット（VPS）、シーケンスパラメータセット（SPS）、ピクチャーパラメータセット（PPS）、タイル、スライス、またはブリックヘッダ内で信号伝達される、条項４０に記載の方法。
４４．前記ビデオ領域のほぼ無損失の符号化モードについてtransform_skip_flagが1に等しい、条項４０に記載の方法。
４５．前記規則は、さらに、前記ビデオ領域の前記無損失の符号化モードおよび／または前記ほぼ無損失の符号化モードについての第1の最大変換サイズが、i）前記損失のある符号化モードに使用される別の最大変換サイズ、ii）最大符号化ツリー単位サイズ、および／または、iii）最大変換スキップサイズに基づいて設定されることを規定する、条項４０に記載の方法。
４６．前記ビデオ領域の前記無損失の符号化モードまたは前記ほぼ無損失の符号化モードについての最大変換サイズは、シーケンスパラメータセット（SPS）、ビデオパラメータセット（VPS）、ピクチャーパラメータセット（PPS）、サブピクチャー、スライス、タイル、ブリック、符号化ツリー単位（CTU）、または仮想パイプラインデータ単位（VPDU）における構文要素（SE）に対応するビデオ単位レベルで信号伝達される、条項４０に記載の方法。
４７．SEが、最大符号化ツリーブロック・サイズ（CTB）、最大変換サイズ、および／または最大変換スキップサイズに依存して信号伝達される、条項４６に記載の方法。
４８．log2_ctu_size_minus5がNより大きく、Nが整数である場合に、SEが信号伝達される、条項４７に記載の方法。
４９．sps_max_luma_transform_size_64_flagがMに等しく、Mが整数である場合に、SEが信号伝達される、条項４７に記載の方法。
５０．log2_transform_skip_max_size_minus2がKより大きい場合に、SEが信号伝達される、条項４７に記載の方法。
５１．log（maxLosslessTbSizeY）とXとの間の差分が信号伝達され、maxLosslessTbSizeYは、前記ビデオ領域の、前記ほぼ無損失の符号化モードまたは前記無損失の符号化モードについて最大変換サイズを示す、条項４７に記載の方法。
５２．Xが、log2_ctu_size_minus5、sps_max_luma_transform_size_64_flag、log2_transform_sk_max_size_minus2、または固定した整数に等しい、条項５１に記載の方法。
５３．maxLosslessTbSizeYとXとの間の差分が信号伝達され、maxLosslessTbSizeYは前記ビデオ領域の前記ほぼ無損失の符号化モードまたは前記無損失の符号化モードについての最大変換サイズを示す、条項４７に記載の方法。
５４．maxLosslessTbSizeYとX－Kとの間の差に対応する値が信号伝達され、maxLosslessTbSizeYは、前記ビデオ領域の前記ほぼ無損失の符号化モードまたは前記無損失の符号化モードについての最大変換サイズを示し、Kは整数である、条項４７に記載の方法。
５５．XがCtbSizeY、MaxTbSize、MaxTsSize、または固定整数に等しい、条項５３または５４に記載の方法。
５６．前記ビデオ領域のmaxLosslessTbSizeYは、前記SEから導出され、maxLosslessTbSizeYは、前記ビデオ領域の前記ほぼ無損失の符号化モードまたは前記無損失の符号化モードについての前記最大変換サイズを示す、条項４６に記載の方法。
５７．前記構文要素はフラグに対応する、条項４６に記載の方法。
５８．前記フラグが存在しない場合、正の整数値である値が推定される、条項５７に記載の方法。
５９．前記規則は、前記ビデオ領域の前記無損失の符号化モードおよび／または前記ほぼ無損失の符号化モードについて、前記最大変換サイズが導出されることをさらに規定する、条項４０に記載の方法。
６０．前記最大変換サイズは、i）固定整数値、ii）前記損失のある符号化モードに使用される別の最大変換サイズ、iii）最大符号化ツリー単位サイズ、iv）VPDUサイズ、v）最大変換スキップ・ブロック・サイズ、またはvi）最大残差符号化ブロック・サイズに等しいように設定される、条項５９に記載の方法。
６１．ビデオ処理方法であって、ビデオのビデオ領域と、前記ビデオの符号化表現との間の変換を規則に従って実行するステップを含み、
前記規則は、ビデオ領域の残差ブロックが、無損失の符号化および／またはほぼ無損失の符号化が適用される前記ビデオ領域の最大変換サイズに基づいて、無損失の符号化および／またはほぼ無損失の符号化のための一つまたは複数の残差サブブロックに分割されることを規定し、前記無損失の符号化は、前記ビデオ領域について残差ブロックの変換をバイパスすることを含み、前記ほぼ無損失の符号化は、閾値より小さい量子化パラメータ（QP）を使用する、方法。
６２．前記規則は、さらに、前記分割後に得られる前記一つまたは複数の残差サブブロックの幅および高さが、前記最大変換サイズより大きくないことを規定する、条項６１に記載の方法。
６３．前記規則は、前記一つまたは複数の残差サブブロックの幅および高さが前記最大変換サイズ以下になるまで、前記残差ブロックの分割を繰り返すことをさらに規定する、条項６２に記載の方法。
６４．前記変換は、前記ビデオを前記符号化表現にエンコードすることを含む、条項１ないし６３のうちいずれかに記載の方法。
６５．前記変換は、前記符号化表現をデコードして前記ビデオを生成することを含む、条項１ないし６３のうちいずれかに記載の方法。
６６．条項１ないし６５のうち一つまたは複数に記載の方法を実装するように構成されたプロセッサを備える、ビデオ処理装置。
６７．プログラムコードが記憶されているコンピュータ可読媒体であって、前記プログラムコードは、実行されると、プロセッサに、条項１ないし６５のうちいずれか一つまたは複数に記載された方法を実装させる、媒体。
６８．上述の方法のいずれかに従って生成された符号化表現またはビットストリーム表現を格納するコンピュータ可読媒体。
本明細書に記載された、開示されたおよびその他の解決策、例、実施形態、モジュール、および機能的な動作は、デジタル電子回路において、または本明細書に開示された構造およびそれらの構造的等価物を含むコンピュータ・ソフトウェア、ファームウェア、またはハードウェアにおいて、またはそれらの一つまたは複数の組み合わせにおいて実装されることができる。開示されたおよびその他の実施形態は、一つまたは複数のコンピュータ・プログラム・プロダクト、すなわち、データ処理装置による実行のため、またはデータ処理装置の動作を制御するために、コンピュータ読み取り可能媒体上にエンコードされたコンピュータ・プログラム命令の一つまたは複数のモジュールとして実装されることができる。コンピュータ読み取り可能媒体は、機械読み取り可能な記憶デバイス、機械読み取り可能な記憶基板、メモリ装置、機械読み取り可能な伝搬信号を実現する物質の組成、またはそれらの一つまたは複数の組み合わせでありうる。用語「データ処理装置」は、たとえば、プログラム可能なプロセッサ、コンピュータ、または複数のプロセッサまたはコンピュータを含む、データを処理するためのすべての装置、デバイス、および機械を包含する。装置は、ハードウェアに加えて、問題のコンピュータ・プログラムのための実行環境を生成するコード、たとえば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、またはそれらの一つまたは複数の組み合わせを構成するコードを含むことができる。伝搬信号は、人工的に生成された信号、たとえば、好適な受信器装置に送信するための情報をエンコードするために生成される機械生成された電気信号、光信号、または電磁信号である。
コンピュータ・プログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとしても知られる）は、コンパイルされるまたはインタープリットされる言語を含む、任意の形のプログラミング言語で書くことができ、それは、スタンドアローン・プログラムとして、またはコンピューティング環境での使用に好適なモジュール、コンポーネント、サブルーチン、または他のユニットとして展開することを含め、任意の形で展開できる。コンピュータ・プログラムは、必ずしもファイルシステム内のファイルに対応するものではない。プログラムは、他のプログラムまたはデータを保持するファイルの一部分に（たとえば、マークアップ言語文書に格納される一つまたは複数のスクリプト）、問題のプログラム専用の単一のファイルに、または複数の協調させられるファイル（たとえば、一つまたは複数のモジュール、サブプログラム、またはコード部分を格納するファイル）に格納されることができる。コンピュータ・プログラムは、1つのコンピュータ上で、または1つのサイトに位置するか、または複数のサイトに分散され、通信ネットワークによって相互接続される複数のコンピュータ上で実行されるように展開されることができる。
本稿に記載されるプロセスおよび論理フローは、一つまたは複数のコンピュータ・プログラムを実行する一つまたは複数のプログラム可能なプロセッサによって実行されて、入力データに対して作用し、出力を生成することによって機能を実行することができる。プロセスおよび論理フローは、特殊目的の論理回路、たとえばFPGA（フィールドプログラマブルゲートアレイ）またはASIC（特定用途向け集積回路）によって実行されることもでき、装置もそのようなものとして実装されることができる。
コンピュータ・プログラムの実行に好適なプロセッサは、たとえば、汎用および専用マイクロプロセッサの両方、および任意の種類のデジタル・コンピュータの任意の一つまたは複数のプロセッサを含む。一般に、プロセッサは、読み出し専用メモリまたはランダムアクセスメモリまたはその両方から命令およびデータを受領する。コンピュータの必須の要素は、命令を実行するためのプロセッサと、命令およびデータを記憶するための一つまたは複数のメモリデバイスである。一般に、コンピュータはまた、データを記憶するための一つまたは複数の大容量記憶装置、たとえば、磁気ディスク、磁気光ディスク、または光ディスクをも含む、またはそれらからデータを受領したり、またはそれにデータを転送したり、またはその両方をしたりするよう、動作上結合される。しかしながら、コンピュータは、そのような装置を有する必要はない。コンピュータ・プログラム命令およびデータを記憶するのに好適なコンピュータ読み取り可能媒体は、あらゆる形の不揮発性メモリ、媒体およびメモリデバイスを含み、たとえば、半導体メモリデバイス、たとえばEPROM、EEPROM、およびフラッシュメモリデバイス；磁気ディスク、たとえば、内蔵ハードディスクまたはリムーバブルディスク；光磁気ディスク；ならびにCD-ROMおよびDVD-ROMディスクを含む。プロセッサおよびメモリは、特殊目的論理回路によって補足されるか、またはそれに組み込まれることができる。
この特許文献は多くの個別的事項を含んでいるが、これらは、いずれかの主題の範囲または特許請求されうるものの範囲に対する限定として解釈されるべきではなく、むしろ特定の技法の特定の実施形態に特有でありうる特徴の記述と解釈されるべきである。この特許文献において別個の実施形態の文脈で記載されているある種の特徴は、単一の実施形態において組み合わせて実施されることもできる。逆に、単一の実施形態の文脈において記載されるさまざまな特徴が、複数の実施形態において別個に、または任意の好適なサブコンビネーションにおいて実施されることもできる。さらに、特徴は、ある種の組み合わせにおいて作用するものとして上述され、さらには当初はそのようなものとして請求項に記載されることがあるが、請求項に記載された組み合わせからの一つまたは複数の特徴が、場合によっては、組み合わせから削除されてもよく、請求項に記載された組み合わせは、サブコンビネーションまたはサブコンビネーションの変形に向けられてもよい。
同様に、図面には特定の順序で動作が示されているが、これは、所望の結果を達成するために、そのような動作が示されている特定の順序で、あるいは逐次順に実行されること、あるいはすべての示されている動作が実行されることを要求すると解釈されるべきではない。さらに、この特許文献に記載されている実施形態におけるさまざまなシステムコンポーネントの分離は、すべての実施形態においてそのような分離を必要とするものとして理解されるべきではない。
少数の実装および例のみが記述されており、この特許文献に記載され、説明されている内容に基づいて、他の実装、向上および変形がなされてもよい。
Claims (14)
- ビデオ処理方法であって：
ビデオのクロマ・ブロックと、前記ビデオのビットストリームとの間の変換について、前記クロマ・ブロックのツリー・タイプおよび前記クロマ・ブロックの寸法に関係する規則に従って前記クロマ・ブロックを分割するかどうかを決定する段階と；
前記決定に基づいて前記変換を実行する段階とを含み、
前記規則は、DUAL_TREE_CHROMAのツリー・タイプを有する前記クロマ・ブロックを分割して幅2をもつクロマ・サブブロックを生成することが許容されないことを指定する、
方法。 - 前記規則は、前記クロマ・ブロックの前記ツリー・タイプがDUAL_TREE_CHROMAに等しく、前記クロマ・ブロックの幅が4に等しい場合に、前記クロマ・ブロックが垂直二分分割を許容されないことを指定する、請求項１に記載の方法。
- 前記規則は、前記クロマ・ブロックの前記ツリー・タイプがDUAL_TREE_CHROMAに等しく、前記クロマ・ブロックの幅が8に等しい場合に、前記クロマ・ブロックが垂直三分分割を許容されないことを指定する、請求項１または２に記載の方法。
- 前記クロマ・ブロックのモード・タイプがMODE_TYPE_INTRAである場合、前記規則はさらに、前記クロマ・ブロックを分割して幅4および高さ2をもつクロマ・サブブロックを生成することも許容されないことを指定する、
請求項１ないし３のうちいずれか一項に記載の方法。 - 前記規則がさらに、前記クロマ・ブロックに対応するルーマ・ブロックを分割してルーマ・サブブロックを生成することが許容されることを指定する、請求項４に記載の方法。
- 前記規則がさらに、前記クロマ・ブロックに対応する前記ルーマ・ブロックが64個のルーマ・サンプルを有し、前記クロマ・ブロックのスライスタイプがIスライスであり、前記クロマ・ブロックのクロマ・フォーマットが4:2:0である場合、DUAL_TREE_CHROMAの前記ツリー・タイプを有する前記クロマ・ブロックを二分分割を使って分割することは許容されず、前記クロマ・ブロックに対応する前記ルーマ・ブロックは二分分割を許容されることを指定する、請求項５に記載の方法。
- 前記規則がさらに、前記クロマ・ブロックに対応する前記ルーマ・ブロックが128個のルーマ・サンプルを有し、前記クロマ・ブロックのスライスタイプがIスライスであり、前記クロマ・ブロックのクロマ・フォーマットが4:2:0である場合、DUAL_TREE_CHROMAの前記ツリー・タイプを有する前記クロマ・ブロックを三分分割を使って分割することは許容されず、前記ルーマ・ブロックは三分分割を許容されることを指定する、請求項５または６に記載の方法。
- 幅が4未満のクロマ・ブロックには、複合インター・イントラ予測モードが適用されることは許容されない、請求項１ないし７のうちいずれか一項に記載の方法。
- 幅が4に等しく、高さが16に等しいルーマ・ブロックには、複合インター・イントラ予測モードが適用されることは許容されない、請求項８に記載の方法。
- 前記変換は、前記クロマ・ブロックを前記ビットストリームにエンコードすることを含む、請求項１ないし９のうちいずれかに記載の方法。
- 前記変換は、前記ビットストリームから前記クロマ・ブロックをデコードすることを含む、請求項１ないし９のうちいずれかに記載の方法。
- プロセッサと、命令をもつ非一時的メモリとを有するビデオ処理装置であって、前記命令は、前記プロセッサによって実行されると、前記プロセッサに：
ビデオのクロマ・ブロックと、前記ビデオのビットストリームとの間の変換について、前記クロマ・ブロックのツリー・タイプおよび前記クロマ・ブロックの寸法に関係する規則に従って前記クロマ・ブロックを分割するかどうかを決定する段階と；
前記決定に基づいて前記変換を実行する段階とを実行させるものであり、
前記規則は、DUAL_TREE_CHROMAのツリー・タイプを有する前記クロマ・ブロックを分割して幅2をもつクロマ・サブブロックを生成することが許容されないことを指定する、
装置。 - 命令を記憶している非一時的なコンピュータ読み取り可能な記憶媒体であって、前記命令は、プロセッサに：
ビデオのクロマ・ブロックと、前記ビデオのビットストリームとの間の変換について、前記クロマ・ブロックのツリー・タイプおよび前記クロマ・ブロックの寸法に関係する規則に従って前記クロマ・ブロックを分割するかどうかを決定する段階と；
前記決定に基づいて前記変換を実行する段階とを実行させるものであり、
前記規則は、DUAL_TREE_CHROMAのツリー・タイプを有する前記クロマ・ブロックを分割して幅2をもつクロマ・サブブロックを生成することが許容されないことを指定する、
記憶媒体。 - ビデオ処理装置によって実行される方法によって生成されたビデオのビットストリームを記憶している非一時的なコンピュータ読み取り可能な記録媒体であって、前記方法は：
前記ビデオのクロマ・ブロックについて、前記クロマ・ブロックのツリー・タイプおよび前記クロマ・ブロックの寸法に関係する規則に従って前記クロマ・ブロックを分割するかどうかを決定する段階と；
前記決定に基づいて前記ビットストリームを生成する段階とを含み、
前記規則は、DUAL_TREE_CHROMAのツリー・タイプを有する前記クロマ・ブロックを分割して幅2をもつクロマ・サブブロックを生成することが許容されないことを指定する、
記録媒体。
Applications Claiming Priority (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNPCT/CN2019/107139 | 2019-09-21 | ||
| CN2019107139 | 2019-09-21 | ||
| CNPCT/CN2019/108760 | 2019-09-27 | ||
| CN2019108760 | 2019-09-27 | ||
| PCT/CN2020/116472 WO2021052494A1 (en) | 2019-09-21 | 2020-09-21 | Size restriction based for chroma intra mode |
| JP2022517728A JP7332795B2 (ja) | 2019-09-21 | 2020-09-21 | クロマ・イントラモードのベースとなるサイズ制約 |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2022517728A Division JP7332795B2 (ja) | 2019-09-21 | 2020-09-21 | クロマ・イントラモードのベースとなるサイズ制約 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2023155275A true JP2023155275A (ja) | 2023-10-20 |
Family
ID=74883922
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2022517728A Active JP7332795B2 (ja) | 2019-09-21 | 2020-09-21 | クロマ・イントラモードのベースとなるサイズ制約 |
| JP2023130792A Pending JP2023155275A (ja) | 2019-09-21 | 2023-08-10 | クロマ・イントラモードのベースとなるサイズ制約 |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2022517728A Active JP7332795B2 (ja) | 2019-09-21 | 2020-09-21 | クロマ・イントラモードのベースとなるサイズ制約 |
Country Status (8)
| Country | Link |
|---|---|
| US (2) | US11575893B2 (ja) |
| EP (1) | EP4018662A4 (ja) |
| JP (2) | JP7332795B2 (ja) |
| KR (1) | KR102649584B1 (ja) |
| CN (2) | CN118055248A (ja) |
| BR (1) | BR112022005109A2 (ja) |
| MX (1) | MX2022003122A (ja) |
| WO (1) | WO2021052494A1 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116248873A (zh) * | 2016-10-10 | 2023-06-09 | 三星电子株式会社 | 通过块映射来对图像进行编码或解码的方法和装置 |
| US11570428B2 (en) * | 2018-09-19 | 2023-01-31 | Electronics And Telecommunications Research Institute | Intra prediction mode encoding/decoding method and device, and recording medium in which bitstream is stored |
| JP7381722B2 (ja) | 2019-09-02 | 2023-11-15 | 北京字節跳動網絡技術有限公司 | カラーフォーマットに基づいたコーディングモード決定 |
| JP7444998B2 (ja) * | 2019-12-31 | 2024-03-06 | エルジー エレクトロニクス インコーポレイティド | リーフノードの再設定された予測モードタイプに基づいて予測を行う画像符号化／復号化方法、装置、及びビットストリームを伝送する方法 |
| US20230217030A1 (en) * | 2022-01-04 | 2023-07-06 | Alibaba (China) Co., Ltd. | Decoder-side chroma intra prediction mode gradient-based derivation |
| WO2023249901A1 (en) * | 2022-06-21 | 2023-12-28 | Beijing Dajia Internet Information Technology Co., Ltd. | Improved cross-component prediction for video coding |
Family Cites Families (67)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8139875B2 (en) | 2007-06-28 | 2012-03-20 | Mitsubishi Electric Corporation | Image encoding device, image decoding device, image encoding method and image decoding method |
| US8526495B2 (en) | 2010-11-22 | 2013-09-03 | Mediatek Singapore Pte. Ltd. | Apparatus and method of constrained partition size for high efficiency video coding |
| US9049444B2 (en) * | 2010-12-22 | 2015-06-02 | Qualcomm Incorporated | Mode dependent scanning of coefficients of a block of video data |
| WO2013109123A1 (ko) * | 2012-01-19 | 2013-07-25 | 삼성전자 주식회사 | 인트라 예측 처리 속도 향상을 위한 비디오의 부호화 방법 및 장치, 비디오의 복호화 방법 및 장치 |
| CN104205843A (zh) | 2012-04-20 | 2014-12-10 | 华为技术有限公司 | Hevc中无损编码中的改进帧内预测 |
| GB2501535A (en) | 2012-04-26 | 2013-10-30 | Sony Corp | Chrominance Processing in High Efficiency Video Codecs |
| US20130294524A1 (en) * | 2012-05-04 | 2013-11-07 | Qualcomm Incorporated | Transform skipping and lossless coding unification |
| US9549182B2 (en) * | 2012-07-11 | 2017-01-17 | Qualcomm Incorporated | Repositioning of prediction residual blocks in video coding |
| US20140029670A1 (en) * | 2012-07-27 | 2014-01-30 | Motorola Mobility Llc | Devices and methods for processing of partition mode in high efficiency video coding |
| WO2014071439A1 (en) | 2012-11-08 | 2014-05-15 | Canon Kabushiki Kaisha | Method, apparatus and system for encoding and decoding the transform units of a coding unit |
| US9332257B2 (en) | 2012-10-01 | 2016-05-03 | Qualcomm Incorporated | Coded black flag coding for 4:2:2 sample format in video coding |
| US20140192862A1 (en) * | 2013-01-07 | 2014-07-10 | Research In Motion Limited | Methods and systems for prediction filtering in video coding |
| WO2015005132A1 (ja) | 2013-07-08 | 2015-01-15 | ソニー株式会社 | 画像符号化装置および方法、並びに画像復号装置および方法 |
| WO2015011752A1 (ja) | 2013-07-22 | 2015-01-29 | ルネサスエレクトロニクス株式会社 | 動画像符号化装置およびその動作方法 |
| WO2015103496A2 (en) | 2014-01-02 | 2015-07-09 | Vid Scale, Inc. | Two-demensional palette coding for screen content coding |
| EP3078194B1 (en) | 2014-01-02 | 2019-09-11 | HFI Innovation Inc. | Method and apparatus for intra prediction coding with boundary filtering control |
| US9883197B2 (en) | 2014-01-09 | 2018-01-30 | Qualcomm Incorporated | Intra prediction of chroma blocks using the same vector |
| WO2015134360A1 (en) | 2014-03-03 | 2015-09-11 | Sony Corporation | Strong intra smoothing for in rext |
| US10404988B2 (en) * | 2014-03-16 | 2019-09-03 | Vid Scale, Inc. | Method and apparatus for the signaling of lossless video coding |
| EP3120556B1 (en) | 2014-03-17 | 2021-01-13 | Microsoft Technology Licensing, LLC | Encoder-side decisions for screen content encoding |
| US9860559B2 (en) | 2014-03-17 | 2018-01-02 | Mediatek Singapore Pte. Ltd. | Method of video coding using symmetric intra block copy |
| US10327001B2 (en) | 2014-06-19 | 2019-06-18 | Qualcomm Incorporated | Systems and methods for intra-block copy |
| CN106716999B (zh) | 2014-06-20 | 2019-08-09 | 寰发股份有限公司 | 用于视频编码的调色板预测器信令的方法 |
| CN105491379A (zh) | 2014-10-01 | 2016-04-13 | 财团法人工业技术研究院 | 解码器、编码器、解码方法、编码方法与编解码系统 |
| JP2017535169A (ja) | 2014-10-06 | 2017-11-24 | ヴィド スケール インコーポレイテッド | スクリーンコンテンツコード化のための改善されたパレットコード化 |
| US9883184B2 (en) | 2014-10-07 | 2018-01-30 | Qualcomm Incorporated | QP derivation and offset for adaptive color transform in video coding |
| US10382795B2 (en) | 2014-12-10 | 2019-08-13 | Mediatek Singapore Pte. Ltd. | Method of video coding using binary tree block partitioning |
| CN107211121B (zh) | 2015-01-22 | 2020-10-23 | 联发科技（新加坡）私人有限公司 | 视频编码方法与视频解码方法 |
| US20160234494A1 (en) | 2015-02-10 | 2016-08-11 | Qualcomm Incorporated | Restriction on palette block size in video coding |
| TWI816224B (zh) | 2015-06-08 | 2023-09-21 | 美商Ｖｉｄ衡器股份有限公司 | 視訊解碼或編碼方法及裝置 |
| US10148977B2 (en) | 2015-06-16 | 2018-12-04 | Futurewei Technologies, Inc. | Advanced coding techniques for high efficiency video coding (HEVC) screen content coding (SCC) extensions |
| EP3357245A4 (en) | 2015-11-05 | 2019-03-13 | MediaTek Inc. | METHOD AND DEVICE OF INTERPRESSATION USING AN AVERAGE MOTION VECTOR FOR VIDEO CODING |
| US11032550B2 (en) | 2016-02-25 | 2021-06-08 | Mediatek Inc. | Method and apparatus of video coding |
| US11223852B2 (en) | 2016-03-21 | 2022-01-11 | Qualcomm Incorporated | Coding video data using a two-level multi-type-tree framework |
| CA3025490A1 (en) * | 2016-05-28 | 2017-12-07 | Mediatek Inc. | Method and apparatus of current picture referencing for video coding using affine motion compensation |
| US10326986B2 (en) * | 2016-08-15 | 2019-06-18 | Qualcomm Incorporated | Intra video coding using a decoupled tree structure |
| US10609423B2 (en) | 2016-09-07 | 2020-03-31 | Qualcomm Incorporated | Tree-type coding for video coding |
| CN117176948A (zh) | 2016-10-04 | 2023-12-05 | 有限公司B1影像技术研究所 | 图像编码/解码方法、记录介质和传输比特流的方法 |
| KR20180039323A (ko) | 2016-10-10 | 2018-04-18 | 디지털인사이트 주식회사 | 다양한 블록 분할 구조를 결합하여 사용하는 비디오 코딩 방법 및 장치 |
| US10848788B2 (en) | 2017-01-06 | 2020-11-24 | Qualcomm Incorporated | Multi-type-tree framework for video coding |
| US11025903B2 (en) | 2017-01-13 | 2021-06-01 | Qualcomm Incorporated | Coding video data using derived chroma mode |
| EP3383045A1 (en) | 2017-03-27 | 2018-10-03 | Thomson Licensing | Multiple splits prioritizing for fast encoding |
| CN107071494B (zh) | 2017-05-09 | 2019-10-11 | 珠海市杰理科技股份有限公司 | 视频图像帧的二进制语法元素的生成方法和系统 |
| JP2021010046A (ja) | 2017-10-06 | 2021-01-28 | シャープ株式会社 | 画像符号化装置及び画像復号装置 |
| KR20190067732A (ko) * | 2017-12-07 | 2019-06-17 | 한국전자통신연구원 | 채널들 간의 선택적인 정보 공유를 사용하는 부호화 및 복호화를 위한 방법 및 장치 |
| CN111919446B (zh) | 2018-04-02 | 2022-10-28 | 夏普株式会社 | 解码视频图片中的当前视频块的方法 |
| US10834396B2 (en) | 2018-04-12 | 2020-11-10 | Qualcomm Incorporated | Bilateral filter for predicted video data |
| EP3738315B1 (en) | 2018-04-19 | 2022-01-26 | Huawei Technologies Co., Ltd. | Luma and chroma block partitioning |
| CN113115046A (zh) | 2018-06-21 | 2021-07-13 | 北京字节跳动网络技术有限公司 | 分量相关的子块分割 |
| KR20200001554A (ko) | 2018-06-27 | 2020-01-06 | 한국전자통신연구원 | 영상 부호화/복호화 방법, 장치 및 비트스트림을 저장한 기록 매체 |
| US20210329233A1 (en) | 2018-07-14 | 2021-10-21 | Mediatek Inc. | Methods and Apparatuses of Processing Video Pictures with Partition Constraints in a Video Coding System |
| AU2018233042B2 (en) | 2018-09-21 | 2024-06-13 | Canon Kabushiki Kaisha | Method, apparatus and system for encoding and decoding a tree of blocks of video samples |
| US10939118B2 (en) | 2018-10-26 | 2021-03-02 | Mediatek Inc. | Luma-based chroma intra-prediction method that utilizes down-sampled luma samples derived from weighting and associated luma-based chroma intra-prediction apparatus |
| CN109743576B (zh) | 2018-12-28 | 2020-05-12 | 杭州海康威视数字技术股份有限公司 | 编码方法、解码方法及装置 |
| JP2021513755A (ja) | 2019-01-15 | 2021-05-27 | エルジー エレクトロニクス インコーポレイティド | 変換スキップフラグを利用した映像コーディング方法及び装置 |
| CN113557527B (zh) | 2019-03-12 | 2024-07-23 | 腾讯美国有限责任公司 | 视频解码方法、视频解码器及介质 |
| CN113906753B (zh) | 2019-04-24 | 2023-12-01 | 字节跳动有限公司 | 编解码视频的量化残差差分脉冲编解码调制表示的约束 |
| CN113785306B (zh) | 2019-05-02 | 2024-06-14 | 字节跳动有限公司 | 基于编解码树结构类型的编解码模式 |
| US11330298B2 (en) | 2019-06-25 | 2022-05-10 | Qualcomm Incorporated | Simplified intra chroma mode coding in video coding |
| CN110381311B (zh) | 2019-07-01 | 2023-06-30 | 腾讯科技（深圳）有限公司 | 视频帧的编码方法、装置、计算机可读介质及电子设备 |
| JP7379655B2 (ja) | 2019-07-19 | 2023-11-14 | ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド | ビデオ信号処理方法及び装置 |
| US11399199B2 (en) | 2019-08-05 | 2022-07-26 | Qualcomm Incorporated | Chroma intra prediction units for video coding |
| WO2021023261A1 (en) | 2019-08-06 | 2021-02-11 | Beijing Bytedance Network Technology Co., Ltd. | Size restriction based on color format |
| EP4005215A4 (en) | 2019-08-15 | 2022-10-26 | Beijing Dajia Internet Information Technology Co., Ltd. | LOW CHROMINANCE BLOCK SIZE RESTRICTION IN VIDEO CODING |
| WO2021036939A1 (en) | 2019-08-23 | 2021-03-04 | Mediatek Inc. | Method and apparatus of partitioning small size coding units with partition constraints |
| JP7381722B2 (ja) | 2019-09-02 | 2023-11-15 | 北京字節跳動網絡技術有限公司 | カラーフォーマットに基づいたコーディングモード決定 |
| KR20220054360A (ko) | 2019-09-25 | 2022-05-02 | 엘지전자 주식회사 | 컬러 포맷에 기반하여 분할 모드를 결정하는 영상 부호화/복호화 방법, 장치 및 비트스트림을 전송하는 방법 |
-
2020
- 2020-09-21 CN CN202311623364.0A patent/CN118055248A/zh active Pending
- 2020-09-21 JP JP2022517728A patent/JP7332795B2/ja active Active
- 2020-09-21 MX MX2022003122A patent/MX2022003122A/es unknown
- 2020-09-21 EP EP20865514.2A patent/EP4018662A4/en active Pending
- 2020-09-21 KR KR1020227008360A patent/KR102649584B1/ko active IP Right Grant
- 2020-09-21 WO PCT/CN2020/116472 patent/WO2021052494A1/en unknown
- 2020-09-21 CN CN202080066291.8A patent/CN114424565B/zh active Active
- 2020-09-21 BR BR112022005109A patent/BR112022005109A2/pt unknown
-
2022
- 2022-03-21 US US17/700,155 patent/US11575893B2/en active Active
-
2023
- 2023-01-09 US US18/151,842 patent/US20230217024A1/en active Pending
- 2023-08-10 JP JP2023130792A patent/JP2023155275A/ja active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| EP4018662A4 (en) | 2023-05-03 |
| US20220248009A1 (en) | 2022-08-04 |
| MX2022003122A (es) | 2022-04-06 |
| KR20220064961A (ko) | 2022-05-19 |
| JP2022549185A (ja) | 2022-11-24 |
| EP4018662A1 (en) | 2022-06-29 |
| BR112022005109A2 (pt) | 2023-03-14 |
| US11575893B2 (en) | 2023-02-07 |
| CN118055248A (zh) | 2024-05-17 |
| US20230217024A1 (en) | 2023-07-06 |
| KR102649584B1 (ko) | 2024-03-21 |
| WO2021052494A1 (en) | 2021-03-25 |
| CN114424565B (zh) | 2024-09-10 |
| CN114424565A (zh) | 2022-04-29 |
| JP7332795B2 (ja) | 2023-08-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN114208189B (zh) | 使用屏幕内容编码工具进行视频编码和解码 | |
| JP7332795B2 (ja) | クロマ・イントラモードのベースとなるサイズ制約 | |
| JP7381722B2 (ja) | カラーフォーマットに基づいたコーディングモード決定 | |
| KR102624456B1 (ko) | 팔레트 모드의 양자화 프로세스 | |
| JP7442673B2 (ja) | ビデオコーディングにおけるスキップブロックの変換のための最小許容量子化 | |
| RU2827859C2 (ru) | Ограничение размера на основе цветового формата | |
| RU2807441C2 (ru) | Ограничение размера на основе внутрикадрового режима цветности |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20230831 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20240507 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20240806 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20241001 |