JP2023111927A - 分割制約要素間の関係 - Google Patents

分割制約要素間の関係 Download PDF

Info

Publication number
JP2023111927A
JP2023111927A JP2023085663A JP2023085663A JP2023111927A JP 2023111927 A JP2023111927 A JP 2023111927A JP 2023085663 A JP2023085663 A JP 2023085663A JP 2023085663 A JP2023085663 A JP 2023085663A JP 2023111927 A JP2023111927 A JP 2023111927A
Authority
JP
Japan
Prior art keywords
block
picture
size
video
minqtsizey
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
Application number
JP2023085663A
Other languages
English (en)
Inventor
ハン・ガオ
Han Gao
セミフ・エセンリク
Esenlik Semih
ジエンレ・チェン
Chen Jianle
アナンド・メヘル・コトラ
Kotra Anand
ビャオ・ワン
Biao Wang
ジジエ・ジャオ
Zhijie Zhao
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2023111927A publication Critical patent/JP2023111927A/ja
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/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/146—Data rate or code amount at the encoder output
    • H04N19/147—Data rate or code amount at the encoder output according to rate distortion criteria
    • 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/167—Position within a video image, e.g. region of interest [ROI]
    • 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/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/96—Tree coding, e.g. quad-tree coding

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Lining And Supports For Tunnels (AREA)
  • Paper (AREA)

Abstract

【課題】本発明は、一般に、ビデオコーディングおよびピクチャ分割方法に関する。【解決手段】詳細には、本発明は、様々なピクチャ分割方法のための分割規則を設定することによる分割制約要素間の関係に関する。本発明は、符号化ピクチャを含むビットストリームを生成または処理するための、特に分割制約要素を設定し、ビットストリームに含めるためのデバイスおよび対応する方法を提供する。デバイスのうちの1つは、四分木分割から生じるリーフブロックの最小ルーマサイズ（MinQtSizeY）を決定し、MinQtSizeYに基づいて、二分木分割を使用して分割されるコーディングブロックの最大ルーマサイズ（MaxBtSizeY）を決定し、決定されたMinQtSizeYに関する情報をビットストリームに含めるように構成される。【選択図】図１３

Description

本開示は、一般に、ビデオの符号化、復号、およびピクチャ分割の方法に関する。
比較的短いビデオさえ描写するために必要なビデオデータはかなりの量であり、それにより、帯域幅容量が限られる通信ネットワークにわたってデータがストリーミングされるか、さもなければ通信されるときに困難が生じる可能性がある。このように、ビデオデータは、一般に、今日の通信ネットワーク全体にわたって通信される前に圧縮される。メモリリソースが限られる場合があるので、ビデオがストレージデバイスに格納されるときに、ビデオのサイズが問題になる可能性もある。ビデオ圧縮デバイスは、しばしば伝送または格納より前に供給元でソフトウェアおよび／またはハードウェアを使用してビデオデータを符号化し、それにより、デジタルビデオ画像を表すために必要なデータの量が減らされる。次いで、圧縮されたデータは、供給先でビデオデータを復号するビデオ解凍デバイスによって受信される。ネットワークリソースは限られ、さらにより高いビデオ品質の需要が増大しており、画質をほとんど犠牲にしないかまたはまったく犠牲にせずに圧縮率を高める改善された圧縮および解凍技法が望まれている。
従来、多数の分割制約要素が存在し、各要素は、様々なタイプの分割方法に対してピクチャの分割（ビデオの分割）を制約する。これらの様々なタイプの分割方法には、特に、二分木分割、四分木分割、および三分木分割が含まれる。分割制約要素は、通常、符号化ピクチャを含むビットストリームに含まれて通知される。以下では、いくつかの重要な分割制約要素が記載される。
最小コーディングブロックサイズ（MinCbSizeY）が定義されてよい。一例として、MinCbSizeYは8に等しくなる可能性があり、それは、結果として生じる子ブロックは（幅または高さのいずれかで）MinCbSizeYよりも小さいことが保証されるので、サイズが8×8の親ブロックは分割（partitioning）（分割（splitting））方法のいずれを使用しても分割することができないことを意味する。第2の例によれば、MinCbSizeYが8に等しい場合、サイズが8×16の親ブロックは、たとえば、結果として生じる4つの子ブロックのサイズは4×8（幅が4に等しく、高さが8に等しい）であり、結果として生じる子ブロックの幅はMinCbSizeYよりも小さいはずなので、四分木分割（splitting）（分割（partitioning））を使用して分割することができない。第2の例では、MinCbSizeYがブロックの幅と高さの両方に適用されることが想定されたが、幅と高さを個別に制限するために2つの異なる構文要素を使用することができる。
最大コーディングツリーブロックサイズ（CtbSizeY）は、ルーマサンプルの数を単位として最大コーディングブロックのサイズを示すことができる。
最大二分木サイズ（MaxBtSizeY）は、バイナリ分割方法を使用して分割することができるコーディングブロックの、サンプル数の単位の最大ルーマサイズ（幅または高さ）として定義されてよい。一例として、MaxBtSizeYが64に等しい場合、幅または高さのいずれかでサイズが大きいコーディングブロックは、バイナリ分割を使用して分割することができない。これは、サイズが128×128のブロックはバイナリ分割を使用して分割することができないが、サイズが64×64のブロックはバイナリ分割を使用して分割できることを意味する。
最小二分木サイズ（MinBtSizeY）は、バイナリ分割方法を使用して分割することができるコーディングブロックの、サンプル数の単位の最小ルーマサイズ（幅または高さ）として定義されてよい。一例として、MinBtSizeYが16に等しい場合、幅または高さのいずれかでサイズが小さいか等しいコーディングブロックは、バイナリ分割を使用して分割することができない。これは、サイズが8×8のブロックはバイナリ分割を使用して分割することができないが、サイズが32×32のブロックはバイナリ分割を使用して分割できることを意味する。
最小四分木サイズ（MinQtSizeY）は、コーディングツリーユニット（CTU）の四分木分割から生じるリーフブロックの最小ルーマサイズとして定義されてよい。サイズは、サンプル数でブロックの幅または高さのいずれかを示すことができる。それは、正方形ブロックの場合、幅と高さを一緒に示してもよい。一例として、MinQtSizeYが16に等しい場合、サイズが16以下のコーディングブロックは、四分木分割方法を使用して子ブロックに分割することができない。従来、MinQtSizeY（ならびに通知された構文要素「log2＿min＿qt＿size＿intra＿slices＿minus2」および「log2＿min＿qt＿size＿inter＿slices＿minus2」）は、最小四分木ブロックサイズを示すために使用される。特に、サイズの構文要素は間接構文要素であり得、log2＿min＿qt＿size＿intra＿slices＿minus2が、最小四分木ブロックのルーマサンプル数の2進対数（底2）であり得ることを意味する。
最小変換ブロックサイズ（MinTbSizeY）は、三値分割方法を使用して分割することができるコーディングブロックの、サンプル数の単位の最小変換ブロックサイズとして定義されてよい。一例として、MinTbSizeYが16に等しい場合、幅または高さのいずれかでサイズが小さいか等しいコーディングブロックは、三値分割を使用して分割することができない。これは、サイズが8×8のブロックは三値分割を使用して分割することができないが、サイズが32×32のブロックは三値分割を使用して分割できることを意味する。
最大マルチタイプツリー深度（MaxMttDepth）は、四分木リーフまたはCTUのマルチタイプツリー分割から生じるコーディングユニットのための最大階層深度として定義されてよい。CTUまたはコーディングツリーブロック（CTB）は、ピクチャフレームを分割するために使用される最大ブロックサイズを記述する。MaxMttDepthは、子ブロックを取得するために適用することができる連続するバイナリ分割または三値分割の数についての上限を記述する。一例として、CTUサイズが128×128（幅が128に等しく、高さが128に等しい）であり、MaxMttDepthが1であると仮定すると、各親ブロック（サイズが128×128）は、最初にバイナリ分割を使用して2つの128×64の子ブロックに分割することができる。しかしながら、許可されるバイナリ分割の最大数に達したので、子ブロックは（128×32または64×64のいずれかの子ブロックになるために）連続するバイナリ分割を適用することができない。MaxMttDepthは、最大バイナリ分割深度もしくは最大三値分割深度、または両方を同時に制御できることに留意されたい。それがバイナリ分割深度と三値分割深度の両方を同時に制御する場合、1つのバイナリ分割とそれに続く1つの三値分割は、2つの階層分割としてカウントすることができる。従来、MaxMttDepth（ならびにその構文要素「max＿mtt＿hierarchy＿depth＿inter＿slices」および「max＿mtt＿hierarchy＿depth＿intra＿slices」）は、マルチタイプツリーから生じるコーディングユニットのための最大階層深度を示すために使用される。
さらに、「pic＿width＿in＿luma＿samples」は、ピクチャサイズ要素、すなわち、復号された各ピクチャの幅をルーマサンプルの単位で指定する構文要素である。pic＿width＿in＿luma＿samplesは、通常、0に等しくなく、MinCbSizeYの整数倍でなければならない。
同様に、「pic＿height＿in＿luma＿samples」は、ピクチャサイズ要素、すなわち、復号された各ピクチャの高さをルーマサンプルの単位で指定する構文要素である。pic＿height＿in＿luma＿samplesは、通常、0に等しくなく、MinCbSizeYの整数倍でなければならない。
ビデオコーディングの目的の1つは、可能な限り低いレートで可能な限り高い品質を提供することである。この目的に寄与することができる要因の1つは、ビットストリーム構造の効率を高めることである。
上記の問題を考慮して、本発明の実施形態は、ピクチャ分割の現在の実装形態を改善することを目的とする。詳細には、目的は、様々なピクチャ分割方法、すなわち、二分木分割方法、四分木分割方法、および三分木分割方法の可用性および柔軟性を高めることである。目標は、より多くのピクチャサイズの符号化および復号を可能にすることである。
本発明の実施形態は、添付の独立請求項において提供される。本発明の有利な実装形態は、従属請求項でさらに定義される。
上記および他の目的は、独立請求項の主題によって達成される。さらなる実施形態は、従属請求項、説明、および図から明らかである。
特定の実施形態は添付の独立請求項に概説されており、他の実施形態は従属請求項に概説されている。
本発明の実施形態では、特に分割制約要素間の関係を設定し、符号化ピクチャとともにビットストリーム内でそれらを通知することによって、新しい分割規則が確立される。これらは、ビデオデータをビットストリームに符号化し、ビットストリームを復号ビデオデータに復号するために使用されてよい。
第1の態様によれば、本発明は、符号化ピクチャを含むビットストリームを復号または処理するためのデバイスに関する。デバイスは、ビットストリーム（101）から構文要素を取得し、四分木分割から生じるルーマリーフブロックのルーマサンプル内の最小サイズMinQtSizeY（105）に関する情報を取得し、MinQtSizeY（105）に関する情報および取得された構文要素に基づいて、二分木分割を使用して分割することができるルーマルートブロックのルーマサンプル内の最大サイズMaxBtSizeY（102）を決定するように構成された回路を含む。
これらの分割制約要素間の関係を設定することを介して新しい分割規則を定義することにより、復号デバイスは、様々なピクチャ分割方法、特に四分木分割および二分木分割の可用性および柔軟性の向上を促進する。
第1の態様による方法の可能な実装形態では、回路は、その下限がMinQtSizeYであることを考慮してMaxBtSizeYを決定するように構成される。
第1の態様または上記の実装による方法の可能な実装形態では、構文要素は、MinQtSizeY（105）の2を底とする対数とMaxBtSizeY（102）の2を底とする対数との間の差分の構文要素（301）である。
このように、関連する分割制約要素は、たとえば、デコーダ側で簡単に推測することができ、同時にビットストリーム内の情報オーバーヘッドが削減される。差分は関係の一例である。しかしながら、関係は、比例係数、計算方式などである可能性もあり、それにより、MinQtSizeYからMaxBtSizeYを推測することが可能になる。
第1の態様または上記の実装による方法の可能な実装形態では、構文要素は、MinQtSizeY（105）とMaxBtSizeY（102）との間の差分の構文要素（301）であり、差分の構文要素は、すなわち、2を底とする対数スケールで前記差分を通知する、log2＿diff＿max＿bt＿size＿min＿qt＿sizeであってよい。そのような差分の構文要素は、差分を通知するコンパクトな方法を提供する。
第1の態様または上記の実装による方法の可能な実装形態では、回路は、四分木リーフブロックのマルチタイプツリー分割から生じるコーディングユニットのための最大階層深度（MaxMttDepth）に依存するビットストリームから構文要素を取得するように構成される。このように、関連する分割制約要素は、たとえば、デコーダ側で簡単に推測することができ、同時にビットストリーム内の情報オーバーヘッドが削減される。
追加または代替として、MaxMttDepthがゼロに等しい場合、回路はビットストリームからMaxBtSizeYのいかなる構文要素も取得しないように構成されてよい。
追加または代替として、MaxMttDepth（103）がゼロに等しくない場合、回路はビットストリーム（101）から構文要素も取得しないように構成されてよい。
第2の態様によれば、本発明は、符号化ピクチャを含むビットストリームを生成または処理するためのデバイスに関し、デバイスは、四分木分割から生じるリーフブロックの最小ルーマサイズMinQtSizeYを決定し、MinQtSizeYに基づいて、二分木分割を使用して分割されるコーディングブロックの最大ルーマサイズMaxBtSizeYを決定し、決定されたMinQtSizeYに関する情報をビットストリームに含めるように構成される。
この方法により、生成されたストリームがコンパクトな構文を有する効率的なエンコーダの実装が可能になり、デコーダが制約パラメータを効率的に推測することが可能になる。デコーダ側の上記の利点は、ビットストリームが生成されるエンコーダ側にも当てはまる。
第2の態様または上記の実装による方法の可能な実装形態では、デバイス（その処理回路）は、その下限がMinQtSizeYであることを考慮してMaxBtSizeYを決定するように構成される。
第2の態様または上記の実装による方法の可能な実装形態では、ビットストリームを生成または処理するためのデバイスは、MinQtSizeY（105）の2を底とする対数とMaxBtSizeY（102）の2を底とする対数との間の差分の構文要素をビットストリーム（101）に含めるようにさらに構成されてよい。
第2の態様または上記の実装による方法の可能な実装形態では、構文要素は、MinQtSizeY（105）とMaxBtSizeY（102）との間の差分の構文要素（301）であり、差分の構文要素は、2を底とする対数スケールで前記差分を通知している。
第2の態様または上記の実装による方法の可能な実装形態では、デバイスは、マルチタイプツリー分割から生じるコーディングユニットのための最大階層深度MaxMttDepthに依存するMaxBtSizeYの構文要素をビットストリームに含めるように構成される。
追加または代替として、MaxMttDepthがゼロに等しい場合、デバイスはビットストリームにMaxBtSizeYのいかなる構文要素も含めないように構成される。
追加または代替として、MaxMttDepthがゼロに等しくない場合、デバイスはビットストリームにMaxBtSizeYの任意の構文要素を含めるように構成される。
第3の態様によれば、本発明は、四分木分割から生じるリーフブロックの最小ルーマサイズMinQtSizeYを決定するステップと、MinQtSizeYに基づいて、二分木分割を使用して分割されるコーディングブロックの最大ルーマサイズMaxBtSizeYを決定するステップと、決定されたMinQtSizeY（105）に関する情報をビットストリームに含めるステップとを含む、符号化ピクチャを含むビットストリームを生成または処理するために提供される方法に関する。
第4の態様によれば、本発明は、ビットストリーム（101）から構文要素を取得するステップと、四分木分割から生じるルーマリーフブロックのルーマサンプル内の最小サイズMinQtSizeY（105）に関する情報を取得するステップと、MinQtSizeY（105）に関する情報および取得された構文要素に基づいて、二分木分割を使用して分割することができるルーマルートブロックのルーマサンプル内の最大サイズMaxBtSizeY（102）を決定するステップとを含む、符号化ピクチャを含むビットストリームを復号または処理するために提供される方法に関する。
方法は、MaxBtSizeYに基づいて、バイナリ分割がピクチャブロックに適用されることが許可されるかどうかを判定するステップと、判定結果に基づいてピクチャブロックのコーディングブロックを取得するステップと、コーディングブロックの復元されたサンプル値を取得するステップとをさらに含んでよい。
ピクチャブロックは、符号化ピクチャのルーマブロックであってよい。
構文要素は、MaxBtSizeY（102）の2を底とする対数とMinQtSizeY（105）の2を底とする対数との間の差分を指定することができ、または構文要素は、MaxBtSizeYとMinQtSizeYとの間の差分を指定することができる。
構文要素は、ビットストリームのスライスヘッダからであってよい。
本発明の第3の態様による方法は、本発明の第1の態様による装置によって実行することができる。本発明の第1の態様による方法のさらなる特徴および実装形態は、本発明の第3の態様による装置の特徴および実装形態に対応する。
本発明の第4の態様による方法は、本発明の第2の態様による装置によって実行することができる。本発明の第2の態様による方法のさらなる特徴および実装形態は、本発明の第4の態様による装置の特徴および実装形態に対応する。
第2の態様による方法は、第1の態様による第1の装置の実装形態に対応する実装形態に拡張することができる。したがって、方法の実装形態は、第1の装置の対応する実装形態の特徴を含む。
第4の態様による方法の利点は、第3の態様による方法の対応する実装形態についての利点と同じである。
第5の態様によれば、本発明は、プロセッサおよびメモリを含む、ビデオストリームを復号するための装置に関する。メモリは、第3の態様による方法をプロセッサに実行させる命令を記憶している。
第6の態様によれば、本発明は、プロセッサおよびメモリを含む、ビデオストリームを符号化するための装置に関する。メモリは、第4の態様による方法をプロセッサに実行させる命令を記憶している。
第7の態様によれば、実行されると、1つまたは複数のプロセッサにビデオデータをコーディングさせる命令をその上に記憶したコンピュータ可読記憶媒体が提案される。命令は、第3もしくは第4の態様または第3もしくは第4の態様の任意の可能な実施形態による方法を1つまたは複数のプロセッサに実行させる。
第8の態様によれば、本発明は、コンピュータ上で実行されると、第3もしくは第4の態様または第3もしくは第4の態様の任意の可能な実施形態による方法を実行するためのプログラムコード含むコンピュータプログラムに関する。
1つまたは複数の実施形態の詳細は、添付の図面および下記の説明に記載される。他の特徴、目的、および利点は、説明、図面、および特許請求の範囲から明らかになる。
一実施形態によれば、デバイスの1つまたは複数のプロセッサによってプログラムコードが実行されると、上記の方法のいずれかを実行するようにデバイスを制御するためのプログラムコードを含むコンピュータプログラム製品が提供される。
明確にするために、本明細書で開示される実施形態のいずれか1つは、本開示の範囲内で新しい実施形態を作成するために他の実施形態のいずれか1つまたは複数と組み合わされてよい。
これらおよび他の特徴は、添付の図面および特許請求の範囲と併せて以下の詳細な説明からより明確に理解される。
本出願に記載されたすべてのデバイス、要素、ユニット、および手段は、ソフトウェア要素もしくはハードウェア要素、またはそれらの任意の種類の組合せに実装できることに留意されたい。本出願に記載された様々なエンティティによって実行されるすべてのステップ、ならびに様々なエンティティによって実行されるように記載された機能は、それぞれのエンティティがそれぞれのステップおよび機能を実行するように適合または構成されることを意味するものである。特定の実施形態の以下の説明において、外部エンティティによって実行される特定の機能またはステップが、その特定のステップまたは機能を実行するそのエンティティの特定の詳細な要素の説明に反映されない場合でも、これらの方法および機能は、それぞれのソフトウェア要素もしくはハードウェア要素、またはそれらの任意の種類の組合せに実装できることは、当業者には明らかなはずである。
上記の態様および実施形態は、添付の図面に関連して特定の実施形態の以下の記述において説明される。
本発明の一実施形態によるデバイスを示す図である。 本発明の第2の特定の実施形態による、デバイス用のSPS RBSP構文を示す図である。 本発明の第2の特定の実施形態による、デバイス用のスライスヘッダ構文を示す図である。 本発明の第3の特定の実施形態による、デバイス用のSPS RBSP構文を示す図である。 本発明の第4の特定の実施形態による、デバイス用のスライスヘッダ構文を示す図である。 本発明の第4の特定の実施形態による、デバイス用のスライスヘッダ構文を示す図である。 本発明の一実施形態による方法を示す図である。 従来のSPS RBSP構文を示す図である。 従来のスライスヘッダ構文を示す図である。 本発明の一実施形態によるデバイスを示す図である。 本開示の実施形態を実装することができる例示的なコーディングシステムを示すブロック図である。 本開示の実施形態を実装することができる別の例示的なコーディングシステムを示すブロック図である。 本開示の実施形態を実装することができる例示的なビデオエンコーダを示すブロック図である。 本開示の実施形態を実装することができるビデオデコーダの一例を示すブロック図である。 本開示の一実施形態によるネットワークデバイスの概略図である。 例示的な一実施形態による、図11Aからのソースデバイス12および宛先デバイス14のいずれかまたは両方として使用され得る装置の簡略化されたブロック図である。 VVCにおける様々なCU分割モードを示す図である。 VVCにおける様々なCU分割モードを示す図である。 VVCにおける様々なCU分割モードを示す図である。 VVCにおける様々なCU分割モードを示す図である。 VVCにおける様々なCU分割モードを示す図である。 VVCにおける様々なCU分割モードを示す図である。 HD（1920×1080）下部境界CTU（128×128）強制QT分割を示す図である。 本開示の一実施形態による、HD（1920×1080）下部境界CTU（128×128）強制BT分割を示す図である。 例示的な境界定義を示す図である。 本開示の一実施形態による、コーナーケース強制QTBT分割の一例を示す図である。 本開示の一実施形態による、コーナーに位置するブロックのための強制QTBT分割の一例を示す図である。 境界定義の一実施形態を示す図である。 四分木－二分木（QTBT）構造を使用するブロック分割の一例の例示的な図である。 図6のQTBT構造を使用するブロック分割に対応するツリー構造の一例の例示的な図である。 水平三分木分割タイプの一例の例示的な図である。 垂直三分木分割タイプの一例の例示的な図である。 本発明の実施形態を実装するように構成されたビデオエンコーダの例を示すブロック図である。 本発明の実施形態を実装するように構成されたビデオデコーダの例示的な構成を示すブロック図である。 コンテンツ配信サービスを実現するコンテンツ供給システム3100の例示的な構造を示すブロック図である。 端末デバイスの一例の構造を示すブロック図である。
1つまたは複数の実施形態の例示的な実装が下記に提供されるが、開示されるシステムおよび／または方法は、現在公知であるか、または実在するかどうかにかかわらず、任意の数の技法を使用して実装されてよいことを最初に理解されたい。本開示は、本明細書に図示および記載される例示的な設計および実装を含む、下記に示される例示的な実装、図面、および技法に決して限定されるべきではなく、それらの均等物の全範囲とともに添付の特許請求の範囲内で修正されてよい。
以下の説明では、添付の図面が参照されるが、それらは本開示の一部を形成し、実例として、本発明の実施形態の特定の態様または本発明の実施形態が使用され得る特定の態様を示す。本発明の実施形態は他の態様で使用されてよく、図に描写されていない構造的または論理的な変更を含んでよいことが理解される。したがって、以下の詳細な説明は限定的な意味で解釈されるべきでなく、本発明の範囲は添付の特許請求の範囲によって規定される。
たとえば、記載された方法に関連する開示は、方法を実行するように構成された対応するデバイスまたはシステムに当てはまる場合もあり、その逆も同様であることが理解される。たとえば、1つまたは複数の特定の方法ステップが記載される場合、対応するデバイスは、記載された1つまたは複数の方法ステップを実行するための1つまたは複数のユニット、たとえば機能ユニット（たとえば、1つもしくは複数のステップを実行する1つのユニット、または各々が複数のステップの1つもしくは複数を実行する複数のユニット）を、そのような1つまたは複数のユニットが図に明示的に記載または図示されていない場合でも含んでよい。一方、たとえば、1つまたは複数のユニット、たとえば機能ユニットに基づいて特定の装置が記載される場合、対応する方法は、1つまたは複数のユニットの機能を実行するための1つのステップ（たとえば、1つもしくは複数のユニットの機能を実行する1つのステップ、または各々が複数のユニットの1つもしくは複数の機能を実行する複数のステップ）を、そのような1つまたは複数のステップが図に明示的に記載または図示されていない場合でも含んでよい。さらに、特に断らない限り、本明細書に記載された様々な例示的な実施形態および／または態様の特徴は、互いに組み合わされてよいことが理解される。
ビデオコーディングは、通常、ビデオまたはビデオシーケンスを形成する一連のピクチャの処理を指す。「ピクチャ」という用語の代わりに、「フレーム」または「画像」という用語が、ビデオコーディングの分野での同義語として使用されてよい。本出願（または本開示）で使用されるビデオコーディングは、ビデオ符号化またはビデオ復号のいずれかを示す。ビデオ符号化はソース側で実行され、通常、（より効率的な格納および／または伝送のために）ビデオピクチャを表すために必要なデータの量を低減するための、元のビデオピクチャの（たとえば、圧縮による）処理を含む。ビデオ復号は宛先側で実行され、通常、ビデオピクチャを復元するための、エンコーダと比較して逆の処理を含む。ビデオピクチャ（または後で説明されるように、一般に、ピクチャ）の「コーディング」に言及する実施形態は、ビデオピクチャに対する「符号化」および「復号」のいずれかに関連すると理解されるはずである。符号化部分と復号部分の組合せは、CODEC（Coding and Decoding）とも呼ばれる。
可逆ビデオコーディングの場合、元のビデオピクチャを復元することができる、すなわち、（格納または伝送中の伝送損失または他のデータ損失がないと仮定すると）復元されたビデオピクチャは元のビデオピクチャと同じ品質を有する。非可逆ビデオコーディングの場合は、ビデオピクチャを表すデータの量を削減するために、たとえば量子化により、さらなる圧縮が実行されるが、ビデオピクチャはデコーダにおいて完全に復元することができない、すなわち、復元されたビデオピクチャの品質は、元のビデオピクチャの品質と比較して低いかまたは悪い。
H．261以降のいくつかのビデオコーディング規格は、「非可逆ハイブリッドビデオコーデック」のグループに属する（すなわち、サンプル領域内の空間予測および時間予測と、変換領域内で量子化を適用するための2D変換コーディングを組み合わせる）。ビデオシーケンスの各ピクチャは、通常、一組の重複しないブロックに分割され、コーディングは、通常、ブロックレベルで実行される。言い換えれば、エンコーダにおいて、ビデオは、通常、たとえば空間（ピクチャ内）予測および時間（ピクチャ間）予測を使用して予測ブロックを生成し、現在ブロック（現在処理されている／処理される予定のブロック）から予測ブロックを差し引いて残差ブロックを取得し、残差ブロックを変換し、変換領域内で残差ブロックを量子化して送信されるデータの量を削減すること（圧縮）により、ブロック（ビデオブロック）レベルで処理、すなわち符号化され、一方、デコーダにおいて、表示用に現在ブロックを復元するために、エンコーダと比べて逆の処理が符号化または圧縮されたブロックに部分的に適用される。さらに、エンコーダはデコーダ処理ループを複製し、その結果、両方は、後続のブロックを処理、すなわちコーディングするための同一の予測（たとえば、イントラ予測およびインター予測）ならびに／または復元を生み出す。
本明細書で使用される「ブロック」という用語は、ピクチャまたはフレームの一部分であってよい。説明の便宜上、本発明の実施形態は、ITU－Tビデオコーディングエキスパートグループ（VCEG）およびISO／IEC動画エキスパートグループ（MPEG）のビデオコーディングに関する共同研究チーム（JCT－VC）によって開発された、高効率ビデオコーディング（HEVC）または多用途ビデオコーディング（VVC）の基準ソフトウェアを参照して本明細書に記載される。当業者は、本発明の実施形態がHEVCまたはVVCに限定されないことを理解されよう。それは、CU（コーディングユニット）、PU（予測ユニット）、およびTU（変換ユニット）を指す場合がある。HEVCでは、CTU（コーディングツリーユニット）は、コーディングツリーと表記される四分木構造を使用してCUに分割される。ピクチャ間（時間）予測またはピクチャ内（空間）予測を使用してピクチャ領域をコーディングするかどうかの決定は、CUレベルで行われる。各CUは、PU分割タイプに応じて、1つ、2つ、または4つのPUにさらに分割することができる。1つのPU内で、同じ予測プロセスが適用され、関連情報がPUベースでデコーダに送信される。PU分割タイプに基づく予測プロセスを適用して残差ブロックを取得した後、CU用のコーディングツリーと同様の別の四分木構造に従って、CUは変換ユニット（TU）に分割することができる。ビデオ圧縮技術の最新の開発では、四分木および二分木（QTBT）の分割フレームがコーディングブロックを分割するために使用される。QTBTブロック構造では、CUは正方形または長方形のいずれかの形状をもつことができる。たとえば、コーディングツリーユニット（CTU）は、最初に四分木構造によって分割される。四分木リーフノードは、二分木構造によってさらに分割される。二分木リーフノードはコーディングユニット（CU）と呼ばれ、そのセグメント化は、それ以上分割することなく、予測処理および変換処理に使用される。これは、CU、PU、およびTUがQTBTコーディングブロック構造で同じブロックサイズを有することを意味する。並行して、複数の分割、たとえば、三分木（TT）分割もQTBTブロック構造と一緒に使用されることが提案された。「デバイス」という用語は、「装置」、「デコーダ」、または「エンコーダ」であってもよい。
以下の実施形態では、エンコーダ20、デコーダ30、およびコーディングシステム10が、図11～図13に基づいて記載される。
以下の説明では、添付の図面が参照されるが、それらは本開示の一部を形成し、実例として、本発明の実施形態の特定の態様または本発明の実施形態が使用され得る特定の態様を示す。本発明の実施形態は他の態様で使用されてよく、図に描写されていない構造的または論理的な変更を含んでよいことが理解される。したがって、以下の詳細な説明は限定的な意味で解釈されるべきでなく、本発明の範囲は添付の特許請求の範囲によって規定される。
たとえば、記載された方法に関連する開示は、方法を実行するように構成された対応するデバイスまたはシステムに当てはまる場合もあり、その逆も同様であることが理解される。たとえば、1つまたは複数の特定の方法ステップが記載される場合、対応するデバイスは、記載された1つまたは複数の方法ステップを実行するための1つまたは複数のユニット、たとえば機能ユニット（たとえば、1つもしくは複数のステップを実行する1つのユニット、または各々が複数のステップの1つもしくは複数を実行する複数のユニット）を、そのような1つまたは複数のユニットが図に明示的に記載または図示されていない場合でも含んでよい。一方、たとえば、1つまたは複数のユニット、たとえば機能ユニットに基づいて特定の装置が記載される場合、対応する方法は、1つまたは複数のユニットの機能を実行するための1つのステップ（たとえば、1つもしくは複数のユニットの機能を実行する1つのステップ、または各々が複数のユニットの1つもしくは複数の機能を実行する複数のステップ）を、そのような1つまたは複数のステップが図に明示的に記載または図示されていない場合でも含んでよい。さらに、特に断らない限り、本明細書に記載された様々な例示的な実施形態および／または態様の特徴は、互いに組み合わされてよいことが理解される。
ビデオコーディングは、通常、ビデオまたはビデオシーケンスを形成する一連のピクチャの処理を指す。「ピクチャ」という用語の代わりに、「フレーム」または「画像」という用語が、ビデオコーディングの分野での同義語として使用されてよい。本出願（または本開示）で使用されるビデオコーディングは、ビデオ符号化またはビデオ復号のいずれかを示す。ビデオ符号化はソース側で実行され、通常、（より効率的な格納および／または伝送のために）ビデオピクチャを表すために必要なデータの量を低減するための、元のビデオピクチャの（たとえば、圧縮による）処理を含む。ビデオ復号は宛先側で実行され、通常、ビデオピクチャを復元するための、エンコーダと比較して逆の処理を含む。ビデオピクチャ（または後で説明されるように、一般に、ピクチャ）の「コーディング」に言及する実施形態は、ビデオピクチャに対する「符号化」および「復号」のいずれかに関連すると理解されるはずである。符号化部分と復号部分の組合せは、CODEC（Coding and Decoding）とも呼ばれる。
可逆ビデオコーディングの場合、元のビデオピクチャを復元することができる、すなわち、（格納または伝送中の伝送損失または他のデータ損失がないと仮定すると）復元されたビデオピクチャは元のビデオピクチャと同じ品質を有する。非可逆ビデオコーディングの場合は、ビデオピクチャを表すデータの量を削減するために、たとえば量子化により、さらなる圧縮が実行されるが、ビデオピクチャはデコーダにおいて完全に復元することができない、すなわち、復元されたビデオピクチャの品質は、元のビデオピクチャの品質と比較して低いかまたは悪い。
H．261以降のいくつかのビデオコーディング規格は、「非可逆ハイブリッドビデオコーデック」のグループに属する（すなわち、サンプル領域内の空間予測および時間予測と、変換領域内で量子化を適用するための2D変換コーディングを組み合わせる）。ビデオシーケンスの各ピクチャは、通常、一組の重複しないブロックに分割され、コーディングは、通常、ブロックレベルで実行される。言い換えれば、エンコーダにおいて、ビデオは、通常、たとえば空間（ピクチャ内）予測および時間（ピクチャ間）予測を使用して予測ブロックを生成し、現在ブロック（現在処理されている／処理される予定のブロック）から予測ブロックを差し引いて残差ブロックを取得し、残差ブロックを変換し、変換領域内で残差ブロックを量子化して送信されるデータの量を削減すること（圧縮）により、ブロック（ビデオブロック）レベルで処理、すなわち符号化され、一方、デコーダにおいて、表示用に現在ブロックを復元するために、エンコーダと比べて逆の処理が符号化または圧縮されたブロックに部分的に適用される。さらに、エンコーダはデコーダ処理ループを複製し、その結果、両方は、後続のブロックを処理、すなわちコーディングするための同一の予測（たとえば、イントラ予測およびインター予測）ならびに／または復元を生み出す。
本明細書で使用される「ブロック」という用語は、ピクチャまたはフレームの一部分であってよい。説明の便宜上、本発明の実施形態は、ITU－Tビデオコーディングエキスパートグループ（VCEG）およびISO／IEC動画エキスパートグループ（MPEG）のビデオコーディングに関する共同研究チーム（JCT－VC）によって開発された、高効率ビデオコーディング（HEVC）または多用途ビデオコーディング（VVC）の基準ソフトウェアを参照して本明細書に記載される。当業者は、本発明の実施形態がHEVCまたはVVCに限定されないことを理解されよう。それは、CU（コーディングユニット）、PU（予測ユニット）、およびTU（変換ユニット）を指す場合がある。HEVCでは、CTU（コーディングツリーユニット）は、コーディングツリーと表記される四分木構造を使用してCUに分割される。ピクチャ間（時間）予測またはピクチャ内（空間）予測を使用してピクチャ領域をコーディングするかどうかの決定は、CUレベルで行われる。各CUは、PU分割タイプに応じて、1つ、2つ、または4つのPUにさらに分割することができる。1つのPU内で、同じ予測プロセスが適用され、関連情報がPUベースでデコーダに送信される。PU分割タイプに基づく予測プロセスを適用して残差ブロックを取得した後、CU用のコーディングツリーと同様の別の四分木構造に従って、CUは変換ユニット（TU）に分割することができる。ビデオ圧縮技術の最新の開発では、四分木および二分木（QTBT）の分割フレームがコーディングブロックを分割するために使用される。QTBTブロック構造では、CUは正方形または長方形のいずれかの形状をもつことができる。たとえば、コーディングツリーユニット（CTU）は、最初に四分木構造によって分割される。四分木リーフノードは、二分木構造によってさらに分割される。二分木リーフノードはコーディングユニット（CU）と呼ばれ、そのセグメント化は、それ以上分割することなく、予測処理および変換処理に使用される。これは、CU、PU、およびTUがQTBTコーディングブロック構造で同じブロックサイズを有することを意味する。並行して、複数の分割、たとえば、三分木（TT）分割もQTBTブロック構造と一緒に使用されることが提案された。「デバイス」という用語は、「装置」、「デコーダ」、または「エンコーダ」であってもよい。
以下の実施形態では、エンコーダ20、デコーダ30、およびコーディングシステム10が、図11～図13に基づいて記載される。
図11Aは、例示的なコーディングシステム10、たとえば、この本出願（本開示）の技法を利用することができるビデオコーディングシステム10を示す概念上または概略的なブロック図である。ビデオコーディングシステム10のエンコーダ20（たとえば、ビデオエンコーダ20）およびデコーダ30（たとえば、ビデオデコーダ30）は、本出願に記載された様々な例による技法を実行するように構成され得るデバイスの例を表す。図11Aに示されたように、コーディングシステム10は、符号化データ13、たとえば、符号化ピクチャ13を、たとえば、符号化データ13を復号するための宛先デバイス14に提供するように構成されたソースデバイス12を備える。
ソースデバイス12はエンコーダ20を備え、さらに、すなわち、場合によっては、ピクチャソース16、前処理ユニット18、たとえばピクチャ前処理ユニット18、および通信インターフェースまたは通信ユニット22を備えてよい。
ピクチャソース16は、たとえば、実世界のピクチャを取り込むための任意の種類のピクチャ取込みデバイス、および／または任意の種類のピクチャもしくはコメント（画面コンテンツコーディングの場合、画面上のいくつかのテキストは符号化されるピクチャもしくは画像の一部と見なされる）生成デバイス、たとえばコンピュータアニメーションピクチャを生成するためのコンピュータグラフィックプロセッサ、あるいは実世界のピクチャ、コンピュータアニメーションピクチャ（たとえば、画面コンテンツ、仮想現実（VR）ピクチャ）、および／またはそれらの任意の組合せ（たとえば、拡張現実（AR）ピクチャ）を取得および／または提供するための任意の種類のデバイスを備えてもよいか、またはそれらであってよい。ピクチャソースは、前述のピクチャのいずれかを記憶する任意の種類のメモリまたはストレージであってよい。
（デジタル）ピクチャは、強度値を有するサンプルの2次元の配列もしくは行列であるか、またはそのように見なすことができる。配列内のサンプルは、ピクセル（ピクチャ要素の短い形式）またはペルと呼ばれる場合もある。配列またはピクチャの水平および垂直の方向（または軸）のサンプル数は、ピクチャのサイズおよび／または解像度を規定する。色を表現するために、通常は3つの色成分が使用される、すなわち、ピクチャは3つのサンプル配列で表現されるか、または3つのサンプル配列を含んでよい。RBGフォーマットまたは色空間では、ピクチャは対応する赤、緑、および青のサンプル配列を含む。しかしながら、ビデオコーディングでは、各ピクセルは、通常、輝度／色度フォーマットまたは色空間、たとえばYCbCrで表され、それは、Yで示される輝度成分（場合によってはLも代わりに使用される）と、CbおよびCrで示される2つの色度成分とを含む。輝度（または短くルーマ）成分Yは、明るさまたは（たとえば、グレースケールピクチャのように）グレーレベル強度を表し、2つの色度（または短くクロマ）成分CbおよびCrは、色度または色情報成分を表す。したがって、YCbCrフォーマットのピクチャは、輝度サンプル値（Y）の輝度サンプル配列と、色度値（CbおよびCr）の2つの色度サンプル配列とを含む。RGBフォーマットのピクチャは、YCbCrフォーマットに転換または変換されてよく、その逆も同様であり、このプロセスは、色変換または色転換としても知られている。ピクチャがモノクロである場合、ピクチャは輝度サンプル配列のみを含んでよい。
ピクチャソース16（たとえば、ビデオソース16）は、たとえば、ピクチャを取り込むためのカメラ、以前に取り込まれたかもしくは生成されたピクチャ、および／またはピクチャを取得もしくは受信するための任意の種類のインターフェース（内部もしくは外部）を含むかまたは記憶するメモリ、たとえばピクチャメモリであってよい。カメラは、たとえば、ローカルカメラまたはソースデバイスに統合された統合カメラであってよく、メモリは、ローカルメモリまたはたとえば、ソースデバイスに統合された統合メモリであってよい。インターフェースは、たとえば、外部ビデオソース、たとえば、カメラのような外部ピクチャ取込みデバイス、外部メモリ、または外部ピクチャ生成デバイス、たとえば、外部コンピュータグラフィックスプロセッサ、コンピュータ、もしくはサーバからピクチャを受信するための外部インターフェースであってよい。インターフェースは、任意の専用または標準化されたインターフェースプロトコルに従う、任意の種類のインターフェース、たとえば有線またはワイヤレスのインターフェース、光インターフェースであり得る。ピクチャデータ17を取得するためのインターフェースは、通信インターフェース22と同じインターフェースまたは通信インターフェース22の一部であってよい。
前処理ユニット18および前処理ユニット18によって実行される処理とは異なり、ピクチャまたはピクチャデータ17（たとえば、ビデオデータ16）は、未加工ピクチャまたは未加工ピクチャデータ17と呼ばれる場合もある。
前処理ユニット18は、（未加工）ピクチャデータ17を受け取り、ピクチャデータ17に対して前処理を実行して、前処理されたピクチャ19または前処理されたピクチャデータ19を取得するように構成される。前処理ユニット18によって実行される前処理は、たとえば、トリミング、色フォーマット変換（たとえば、RGBからYCbCrへ）、色補正、またはノイズ除去を含んでよい。前処理ユニット18はオプションの構成要素であってよいことを理解することができる。
エンコーダ20（たとえば、ビデオエンコーダ20）は、前処理されたピクチャデータ19を受け取り、符号化ピクチャデータ21を提供するように構成される（さらなる詳細は、たとえば、図12または図14に基づいて下記に記載される）。
ソースデバイス12の通信インターフェース22は、符号化ピクチャデータ21を受け取り、符号化ピクチャデータ21（またはその任意のさらに処理されたバージョン）を、通信チャネル13を介して、格納または直接復元のための別のデバイス、たとえば、宛先デバイス14または任意の他のデバイスに送信するように構成されてよい。
ソースデバイス12の通信インターフェース22は、符号化ピクチャデータ21を受け取り、格納または直接復元のための別のデバイス、たとえば宛先デバイス14または任意の他のデバイスにそれを送信するように、あるいは、それぞれ、符号化データ13を格納する前、および／または符号化データ13を別のデバイス、たとえば復号もしくは格納するための宛先デバイス14もしくは他のデバイスに送信する前に、符号化ピクチャデータ21を処理するように構成されてよい。
宛先デバイス14は、デコーダ30（たとえば、ビデオデコーダ30）を備え、さらに、すなわち、場合によっては、通信インターフェースまたは通信ユニット28、後処理ユニット32、およびディスプレイデバイス34を備えてよい。
宛先デバイス14の通信インターフェース28は、符号化ピクチャデータ21（またはその任意のさらに処理されたバージョン）を、ソースデバイス12から直接、または任意の他のソース、たとえばストレージデバイス、たとえば符号化ピクチャデータストレージデバイスから受信し、符号化ピクチャデータ21をデコーダ30に提供するように構成される。
宛先デバイス14の通信インターフェース28は、たとえばソースデバイス12から直接、または任意の他のソース、たとえばストレージデバイス、たとえば符号化ピクチャデータストレージデバイスから、符号化ピクチャデータ21または符号化データ13を受信するように構成される。
通信インターフェース22および通信インターフェース28は、ソースデバイス12と宛先デバイス14との間の直接通信リンク、たとえば、有線またはワイヤレスの直接接続を介して、あるいは任意の種類のネットワーク、たとえば有線もしくはワイヤレスのネットワークまたはそれらの任意の組合せを介して、あるいは任意の種類のプライベートおよびパブリックのネットワーク、またはそれらの任意の種類の組合せを介して、符号化ピクチャデータ21または符号化データ13を送受信するように構成されてよい。
通信インターフェース22は、たとえば、符号化ピクチャデータ21を適切なフォーマット、たとえばパケットにパッケージ化し、かつ／または通信リンクもしくは通信ネットワークを介する送信のための任意の種類の送信の符号化または処理を使用して、符号化ピクチャデータを処理するように構成されてよい。
通信インターフェース22の相手方を形成する通信インターフェース28は、たとえば、符号化データ13をパッケージ解除して符号化ピクチャデータ21を取得するように構成されてよい。
通信インターフェース22の相手方を形成する通信インターフェース28は、たとえば、送信データを受信し、任意の種類の対応する送信の復号もしくは処理および／またはパッケージ解除を使用して送信データを処理して、符号化ピクチャデータ21を取得するように構成されてよい。
通信インターフェース22と通信インターフェース28の両方は、ソースデバイス12から宛先デバイス14を指す、図11Aの符号化ピクチャデータ13の矢印によって示されたような単方向通信インターフェース、または双方向通信インターフェースとして構成されてよく、たとえば、メッセージを送受信するように、たとえば、接続をセットアップするように、通信リンクおよび／またはデータ送信、たとえば、符号化ピクチャデータ送信に関連する任意の他の情報を確認および交換するように構成されてよい。
デコーダ30は、符号化ピクチャデータ21を受信し、復号ピクチャデータ31または復号ピクチャ31を提供するように構成される（さらなる詳細は、たとえば、図13または図15に基づいて下記に記載される）。
宛先デバイス14のポストプロセッサ32は、（復元ピクチャデータとも呼ばれる）復号ピクチャデータ31、たとえば復号ピクチャ31を後処理して、後処理されたピクチャデータ33、たとえば後処理されたピクチャ33を取得するように構成される。後処理ユニット32によって実行される後処理は、たとえば、たとえばディスプレイデバイス34による表示用の復号ピクチャデータ31を準備するための、たとえば、色フォーマット変換（たとえば、YCbCrからRGBへ）、色補正、トリミング、もしくは再サンプリング、または任意の他の処理を含んでよい。
宛先デバイス14のディスプレイデバイス34は、たとえばユーザまたはビューアにピクチャを表示するための後処理されたピクチャデータ33を受信するように構成される。ディスプレイデバイス34は、復元ピクチャを表すための任意の種類のディスプレイ、たとえば統合されるかまたは外部のディスプレイまたはモニタであるか、またはそれを備えてよい。ディスプレイは、たとえば、液晶ディスプレイ（LCD）、有機発光ダイオード（OLED）ディスプレイ、プラズマディスプレイ、プロジェクタ、マイクロLEDディスプレイ、液晶オンシリコン（LCoS）、デジタルライトプロセッサ（DLP）、または任意の種類の他のディスプレイを含んでよい。
図11Aは、ソースデバイス12および宛先デバイス14を別個のデバイスとして描写するが、デバイスの実施形態は、ソースデバイス12または対応する機能および宛先デバイス14または対応する機能の両方または両方の機能を含む場合もある。そのような実施形態では、ソースデバイス12または対応する機能および宛先デバイス14または対応する機能は、同じハードウェアおよび／またはソフトウェアを使用して、あるいは別個のハードウェアおよび／もしくはソフトウェアまたはそれらの任意の組合せによって実装されてよい。
説明に基づいて当業者には明らかなように、図11Aに示されたソースデバイス12および／または宛先デバイス14内の様々なユニットまたは機能の存在および（正確な）機能の分割は、実際のデバイスおよびアプリケーションに応じて変わる場合がある。
エンコーダ20（たとえば、ビデオエンコーダ20）およびデコーダ30（たとえば、ビデオデコーダ30）は、各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（DSP）、特定用途向け集積回路（ASIC）、フィールドプログラマブルゲートアレイ（FPGA）、個別論理、ハードウェア、またはそれらの任意の組合せなどの、様々な適切な回路のいずれかとして実装されてよい。技法がソフトウェア内で部分的に実装される場合、デバイスは、ソフトウェアの命令を適切な非一時的コンピュータ可読媒体に記憶することができ、1つまたは複数のプロセッサを使用してハードウェア内で命令を実行して、本開示の技法を実行することができる。（ハードウェア、ソフトウェア、ハードウェアとソフトウェアの組合せなどを含む）前述のいずれかは、1つまたは複数のプロセッサであるように見なされてよい。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、それらのいずれかは、それぞれのデバイス内の複合エンコーダ／デコーダ（コーデック）の一部として統合されてよい。
エンコーダ20は、図12のエンコーダ20および／または本明細書に記載される任意の他のエンコーダシステムもしくはサブシステムに関して説明される様々なモジュールを具現化するために、処理回路46を介して実装されてよい。デコーダ30は、図13のデコーダ30および／または本明細書に記載される任意の他のデコーダシステムもしくはサブシステムに関して説明される様々なモジュールを具現化するために、処理回路46を介して実装されてよい。処理回路は、後で説明される様々な動作を実行するように構成されてよい。図15に示されたように、技法がソフトウェア内で部分的に実装される場合、デバイスは、ソフトウェアの命令を適切な非一時的コンピュータ可読媒体に記憶することができ、1つまたは複数のプロセッサを使用してハードウェア内で命令を実行して、本開示の技法を実行することができる。ビデオエンコーダ20およびビデオデコーダ30のいずれかは、たとえば、図11Bに示されたように、単一のデバイス内の複合エンコーダ／デコーダ（コーデック）の一部として統合されてよい。
ソースデバイス12は、ビデオ符号化デバイスまたはビデオ符号化装置と呼ばれる場合がある。宛先デバイス14は、ビデオ復号デバイスまたはビデオ復号装置と呼ばれる場合がある。ソースデバイス12および宛先デバイス14は、ビデオコーディングデバイスまたはビデオコーディング装置の一例であり得る。
ソースデバイス12および宛先デバイス14は、任意の種類のハンドヘルドデバイスまたは固定デバイス、たとえば、ノートブックコンピュータもしくはラップトップコンピュータ、携帯電話、スマートフォン、タブレットもしくはタブレットコンピュータ、カメラ、デスクトップコンピュータ、セットトップボックス、テレビ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲーミングコンソール、（コンテンツサービスサーバもしくはコンテンツ配信サーバなどの）ビデオストリーミングデバイス、ブロードキャスト受信機デバイス、ブロードキャスト送信機デバイスなどを含む、広範囲のデバイスのいずれかを含んでよく、オペレーティングシステムをまったく使用しない場合があるか、または任意の種類のオペレーティングシステムを使用する場合がある。
場合によっては、ソースデバイス12および宛先デバイス14は、ワイヤレス通信に対応していてよい。このように、ソースデバイス12および宛先デバイス14は、ワイヤレス通信デバイスであってよい。
場合によっては、図11Aに示されたビデオコーディングシステム10は単なる例であり、本出願の技法は、符号化デバイスと復号デバイスとの間の任意のデータ通信を必ずしも含むとは限らないビデオコーディング設定（たとえば、ビデオ符号化またはビデオ復号）に適用されてよい。他の例では、データはローカルメモリから取り出される、ネットワークを介してストリーミングされる、などである。ビデオ符号化デバイスは、データを符号化しメモリに記憶することができ、かつ／またはビデオ復号デバイスは、メモリからデータを取り出し復号することができる。いくつかの例では、符号化および復号は、互いに通信しない、データをメモリに符号化し、かつ／またはメモリからデータを取り出し復号するだけのデバイスによって実行される。
説明の便宜上、本発明の実施形態は、たとえば、ITU－Tビデオコーディングエキスパートグループ（VCEG）およびISO／IEC動画エキスパートグループ（MPEG）のビデオコーディングに関する共同研究チーム（JCT－VC）によって開発された、高効率ビデオコーディング（HEVC）または多用途ビデオコーディング（VVC）の基準ソフトウェア、次世代ビデオコーディング規格を参照して本明細書に記載される。当業者は、本発明の実施形態がHEVCまたはVVCに限定されないことを理解されよう。ビデオエンコーダ20を参照して記載された上記の例の各々に対して、ビデオデコーダ30は逆のプロセスを実行するように構成されてよい。構文要素の通知に関して、ビデオデコーダ30は、そのような構文要素を受信および構文解析し、それに応じて関連するビデオデータを復号するように構成されてよい。いくつかの例では、ビデオエンコーダ20は、1つまたは複数の構文要素を符号化ビデオビットストリームにエントロピー符号化することができる。そのような例では、ビデオデコーダ30は、そのような構文要素を構文解析し、それに応じて関連するビデオデータを復号することができる。
図11Bは、例示的な一実施形態による、図12のエンコーダ20および／または図13のデコーダ30を含む別の例示的なビデオコーディングシステム40の例示的な図である。システム40は、本出願に記載された様々な例による技法を実装することができる。図示された実施形態では、ビデオコーディングシステム40は、撮像デバイス41、ビデオエンコーダ100、ビデオデコーダ30（および／もしくは処理ユニット46の論理回路47を介して実装されるビデオコーダ）、アンテナ42、1つもしくは複数のプロセッサ43、1つもしくは複数のメモリストア44、ならびに／またはディスプレイデバイス45を含んでよい。
図示されたように、撮像デバイス41、アンテナ42、処理ユニット46、論理回路47、ビデオエンコーダ20、ビデオデコーダ30、プロセッサ43、メモリストア44、および／またはディスプレイデバイス45は、互いに通信することが可能であってよい。説明されたように、ビデオエンコーダ20とビデオデコーダ30の両方で示されているが、ビデオコーディングシステム40は、様々な例では、ビデオエンコーダ20のみ、またはビデオデコーダ30のみを含んでよい。
図示されたように、いくつかの例では、ビデオコーディングシステム40はアンテナ42を含んでよい。アンテナ42は、たとえば、ビデオデータの符号化ビットストリームを送受信するように構成されてよい。さらに、いくつかの例では、ビデオコーディングシステム40はディスプレイデバイス45を含んでよい。ディスプレイデバイス45は、ビデオデータを提示するように構成されてよい。図示されたように、いくつかの例では、論理回路47は処理ユニット46を介して実装されてよい。処理ユニット46は、特定用途向け集積回路（ASIC）ロジック、グラフィックスプロセッサ、汎用プロセッサなどを含んでよい。ビデオコーディングシステム40はまた、特定用途向け集積回路（ASIC）ロジック、グラフィックスプロセッサ、汎用プロセッサなどを同様に含んでよい、オプションのプロセッサ43を含んでよい。いくつかの例では、論理回路47は、ハードウェア、ビデオコーディング専用ハードウェアなどを介して実装されてよく、プロセッサ43は、汎用ソフトウェア、オペレーティングシステムなどを実装することができる。加えて、メモリストア44は、揮発性メモリ（たとえば、スタティックランダムアクセスメモリ（SRAM）、ダイナミックランダムアクセスメモリ（DRAM）など）、または不揮発性メモリ（たとえば、フラッシュメモリなど）などの任意のタイプのメモリであってよい。非限定的な例では、メモリストア44はキャッシュメモリによって実装されてよい。いくつかの例では、論理回路47は、（たとえば、画像バッファの実装のために）メモリストア44にアクセスすることができる。他の例では、論理回路47および／または処理ユニット46は、画像バッファなどの実装のためのメモリストア（たとえば、キャッシュなど）を含んでよい。
いくつかの例では、論理回路を介して実装されるビデオエンコーダ100は、（たとえば、処理ユニット46またはメモリストア44のいずれかを介して）画像バッファを含んでよく、（たとえば、処理ユニット46を介して）グラフィックス処理ユニットを含んでよい。グラフィックス処理ユニットは、画像バッファに通信可能に結合されてよい。グラフィックス処理ユニットは、図12に関して説明される様々なモジュール、および／または本明細書に記載された任意の他のエンコーダシステムもしくはサブシステムを具現化するために論理回路47を介して実装されたビデオエンコーダ100を含んでよい。論理回路は、本明細書に説明された様々な動作を実行するように構成されてよい。
ビデオデコーダ30は、図13のデコーダ30および／または本明細書に記載される任意の他のデコーダシステムもしくはサブシステムに関して説明される様々なモジュールを具現化するために処理回路47を介して実装されたのと同様に実装されてよい。いくつかの例では、論理回路を介して実装され得るビデオデコーダ30は、（たとえば、処理ユニット420またはメモリストア44のいずれかを介して）画像バッファを含んでよく、（たとえば、処理ユニット46を介して）グラフィックス処理ユニットを含んでよい。グラフィックス処理ユニットは、画像バッファに通信可能に結合されてよい。グラフィックス処理ユニットは、図13に関して説明される様々なモジュール、および／または本明細書に記載された任意の他のデコーダシステムもしくはサブシステムを具現化するために論理回路47を介して実装されたビデオデコーダ30を含んでよい。
いくつかの例では、ビデオコーディングシステム40のアンテナ42は、ビデオデータの符号化ビットストリームを受信するように構成されてよい。説明されたように、符号化ビットストリームは、コーディング分割に関連付けられたデータ（たとえば、変換係数または量子化変換係数、（説明された）オプションのインジケータ、および／またはコーディング分割を定義するデータ）などの、本明細書に説明されたビデオフレームの符号化に関連付けられたデータ、インジケータ、インデックス値、モード選択データなどを含んでよい。ビデオコーディングシステム40はまた、アンテナ42に結合され、符号化ビットストリームを復号するように構成されたビデオデコーダ30を含んでよい。ビデオフレームを提示するように構成されたディスプレイデバイス45。
図12は、本出願の技法を実装するように構成された例示的なビデオエンコーダ20の概略／概念ブロック図を示す。図12の例では、ビデオエンコーダ20は、残差計算ユニット204、変換処理ユニット206、量子化ユニット208、逆量子化ユニット210、逆変換処理ユニット212、復元ユニット214、バッファ216、ループフィルタユニット220、復号ピクチャバッファ（DPB）230、予測処理ユニット260、およびエントロピー符号化ユニット270を備える。予測処理ユニット260は、インター予測ユニット244、イントラ予測ユニット254、およびモード選択ユニット262を含んでよい。インター予測ユニット244は、動き推定ユニットおよび動き補償ユニット（図示せず）を含んでよい。図12に示されたビデオエンコーダ20は、ハイブリッドビデオエンコーダまたはハイブリッドビデオコーデックによるビデオエンコーダと呼ばれる場合もある。
たとえば、残差計算ユニット204、変換処理ユニット206、量子化ユニット208、予測処理ユニット260、およびエントロピー符号化ユニット270は、エンコーダ20の順方向信号経路を形成し、一方、たとえば、逆量子化ユニット210、逆変換処理ユニット212、復元ユニット214、バッファ216、ループフィルタ220、復号ピクチャバッファ（DPB）230、予測処理ユニット260は、エンコーダの逆方向信号経路を形成し、エンコーダの逆方向信号経路はデコーダの信号経路（図13のデコーダ30を参照）に対応する。
逆量子化ユニット210、逆変換処理ユニット212、復元ユニット214、ループフィルタ220、復号ピクチャバッファ（DPB）230、インター予測ユニット244、およびイントラ予測ユニット254はまた、ビデオエンコーダ20の「内蔵デコーダ」を形成すると呼ばれる。エンコーダ20は、たとえば、入力202により、ピクチャ201またはピクチャ201のブロック203、たとえば、ビデオまたはビデオシーケンスを形成する一連のピクチャのうちのピクチャを受信するように構成される。ピクチャブロック203はまた、現在ピクチャブロックまたはコーディングされるピクチャブロックと呼ばれる場合もあり、ピクチャ201は、現在ピクチャまたは（特に、現在ピクチャを他のピクチャ、たとえば、同じビデオシーケンス、すなわち、現在ピクチャも含むビデオシーケンスの以前に符号化および／または復号されたピクチャと区別するためのビデオコーディングにおいて）コーディングされるピクチャと呼ばれる場合もある。
（デジタル）ピクチャは、強度値を有するサンプルの2次元の配列もしくは行列であるか、またはそのように見なすことができる。配列内のサンプルは、ピクセル（ピクチャ要素の短い形式）またはペルと呼ばれる場合もある。配列またはピクチャの水平および垂直の方向（または軸）のサンプル数は、ピクチャのサイズおよび／または解像度を規定する。色を表現するために、通常は3つの色成分が使用される、すなわち、ピクチャは3つのサンプル配列で表現されるか、または3つのサンプル配列を含んでよい。RBGフォーマットまたは色空間では、ピクチャは対応する赤、緑、および青のサンプル配列を含む。しかしながら、ビデオコーディングでは、各ピクセルは、通常、輝度および色度フォーマットまたは色空間、たとえばYCbCrで表され、それは、Yで示される輝度成分（場合によってはLも代わりに使用される）と、CbおよびCrで示される2つの色度成分とを含む。輝度（または短くルーマ）成分Yは、明るさまたは（たとえば、グレースケールピクチャのように）グレーレベル強度を表し、2つの色度（または短くクロマ）成分CbおよびCrは、色度または色情報成分を表す。したがって、YCbCrフォーマットのピクチャは、輝度サンプル値（Y）の輝度サンプル配列と、色度値（CbおよびCr）の2つの色度サンプル配列とを含む。RGBフォーマットのピクチャは、YCbCrフォーマットに転換または変換されてよく、その逆も同様であり、このプロセスは、色変換または色転換としても知られている。ピクチャがモノクロである場合、ピクチャは輝度サンプル配列のみを含んでよい。したがって、ピクチャは、たとえば、モノクロフォーマットのルーマサンプルの配列、または、ルーマサンプルの配列、ならびに4：2：0、4：2：2、および4：4：4の色フォーマットのクロマサンプルの2つの対応する配列であってよい。
分割
エンコーダ20の実施形態は、ピクチャ201を複数の（通常は重複しない）ピクチャブロック203に分割するように構成された分割ユニット（図12には描写されていない）を含んでよい。これらのブロックは、ルートブロック、マクロブロック（H．264／AVC）またはコーディングツリーブロック（CTB）またはコーディングツリーユニット（CTU）（H．265／HEVCおよびVVC）と呼ばれる場合もある。分割ユニットは、ビデオシーケンスのすべてのピクチャおよびブロックサイズを画定する対応するグリッドに同じブロックサイズを使用するか、またはピクチャもしくはサブセットもしくはピクチャグループの間でブロックサイズを変更し、各ピクチャを対応するブロックに分割するように構成されてよい。
さらなる実施形態では、ビデオエンコーダは、ピクチャ201のブロック203、たとえば、ピクチャ201を形成する1つ、いくつか、またはすべてのブロックを直接受信するように構成されてよい。ピクチャブロック203は、現在ピクチャブロックまたはコーディングされるピクチャブロックと呼ばれる場合もある。一例では、ビデオエンコーダ20の予測処理ユニット260は、上述された分割技法の任意の組合せを実行するように構成されてよい。
ピクチャ201と同様に、ブロック203も、ピクチャ201よりも小さい次元であるが、強度値（サンプル値）を有するサンプルの2次元の配列または行列であるか、またはそのように見なすことができる。言い換えれば、ブロック203は、たとえば、1つのサンプル配列（たとえば、モノクロピクチャ201の場合のルーマ配列）、または3つのサンプル配列（たとえば、カラーピクチャ201の場合のルーマ配列および2つのクロマ配列）、または適用されるカラーフォーマットに依存する任意の他の数および／もしくは種類の配列を含んでよい。ブロック203の水平および垂直の方向（または軸）のサンプル数は、ブロック203のサイズを規定する。したがって、ブロックは、たとえば、サンプルのM×N（M列×N行）配列、または変換係数のM×N配列であってよい。
図12に示されたエンコーダ20は、ピクチャ201をブロックごとに符号化するように構成され、たとえば、符号化および予測はブロック203ごとに実行される。
図12に示されたビデオエンコーダ20の実施形態は、（ビデオスライスとも呼ばれる）スライスを使用してピクチャを分割および／または符号化するようにさらに構成されてよく、ピクチャは、1つまたは複数のスライス（通常は重複しない）を使用して分割または符号化されてよく、各スライスは、1つもしくは複数のブロック（たとえば、CTU）またはブロックの1つもしくは複数のグループ（たとえば、タイル（H．265／HEVCおよびVVC）もしくはレンガ（VVC））を含んでよい。
図12に示されたビデオエンコーダ20の実施形態は、（ビデオタイルグループとも呼ばれる）スライス／タイルグループおよび／または（ビデオタイルとも呼ばれる）タイルを使用してピクチャを分割および／または符号化するようにさらに構成されてよく、ピクチャは、1つまたは複数のスライス／タイルグループ（通常は重複しない）を使用して分割または符号化されてよく、各スライス／タイルグループは、たとえば、1つもしくは複数のブロック（たとえば、CTU）または1つもしくは複数のタイルを含んでよく、各タイルは、たとえば、長方形の形状であってよく、1つまたは複数のブロック（たとえば、CTU）、たとえば、完全または部分的なブロックを含んでよい。
残差計算
残差計算ユニット204は、ピクチャブロック203および予測ブロック265（予測ブロック265に関するさらなる詳細は後で提供される）に基づいて、たとえば、ピクチャブロック203のサンプル値から予測ブロック265のサンプル値を減算することによって残差ブロック205を計算して、サンプルごと（ピクセルごと）にサンプル領域内の残差ブロック205を取得するように構成される。
変換
変換処理ユニット206は、残差ブロック205のサンプル値に対して、変換、たとえば、離散コサイン変換（DCT）または離散サイン変換（DST）を適用して、変換領域内の変換係数207を取得するように構成される。変換係数207は、変換残差係数と呼ばれる場合もあり、変換領域内の残差ブロック205を表すことができる。
変換処理ユニット206は、HEVC／H．265向けに指定された変換などのDCT／DSTの整数近似を適用するように構成されてよい。直交DCT変換と比較すると、そのような整数近似は、通常、特定の係数によってスケーリングされる。順変換および逆変換によって処理される残差ブロックのノルムを保存するために、変換プロセスの一部として追加のスケーリング係数が適用される。スケーリング係数は、通常、スケーリング係数がシフト演算のために2のべき乗であるような特定の制約、変換係数のビット深度、精度と実装コストとの間のトレードオフなどに基づいて選択される。特定のスケーリング係数は、たとえば、たとえばデコーダ30における逆変換処理ユニット212による逆変換（および、たとえばエンコーダ20における逆変換処理ユニット212による対応する逆変換）のために指定され、たとえば、エンコーダ20における変換処理ユニット206による順変換のための対応するスケーリング係数は、それに応じて指定されてよい。
ビデオエンコーダ20（それぞれ変換処理ユニット206）の実施形態は、変換パラメータ、たとえば、1つまたは複数の変換のタイプを直接出力するように構成されるか、またはエントロピー符号化ユニット270を介して符号化もしくは圧縮されてよく、その結果、たとえば、ビデオデコーダ30は、復号のために変換パラメータを受信し使用することができる。
量子化
量子化ユニット208は、たとえば、スカラー量子化またはベクトル量子化を適用することにより、変換係数207を量子化して量子化変換係数209を取得するように構成される。量子化変換係数209は、量子化残差係数209と呼ばれる場合もある。量子化プロセスは、変換係数207の一部または全部に関連付けられたビット深度を減らすことができる。たとえば、nビットの変換係数は、量子化中にmビットの変換係数に切り捨てられる場合があり、ここで、nはmよりも大きい。量子化の程度は、量子化パラメータ（QP）を調節することによって修正されてよい。たとえば、スカラー量子化の場合、より細かいまたはより粗い量子化を実現するために、異なるスケーリングが適用されてよい。より小さい量子化ステップサイズはより細かい量子化に対応し、より大きい量子化ステップサイズはより粗い量子化に対応する。適用可能な量子化ステップサイズは、量子化パラメータ（QP）によって示されてよい。量子化パラメータは、たとえば、適用可能な量子化ステップサイズのあらかじめ定義されたセットへのインデックスであってよい。たとえば、小さい量子化パラメータは細かい量子化（小さい量子化ステップサイズ）に対応してよく、大きい量子化パラメータは粗い量子化（大きい量子化ステップサイズ）に対応してよく、またはその逆である。量子化は、量子化ステップサイズ、および対応するまたは逆の逆量子化による、たとえば逆量子化210による除算を含んでよく、量子化ステップサイズによる乗算を含んでよい。いくつかの規格、たとえばHEVCによる実施形態は、量子化パラメータを使用して量子化ステップサイズを決定するように構成されてよい。一般に、量子化ステップサイズは、除算を含む方程式の固定小数点近似を使用して、量子化パラメータに基づいて計算されてよい。残差ブロックのノルムを修復するために、量子化および逆量子化に追加のスケーリング係数が導入されてよく、それは、量子化ステップサイズおよび量子化パラメータのための方程式の固定小数点近似で使用されるスケーリングのために修正される可能性がある。1つの例示的な実装形態では、逆変換と逆量子化のスケーリングが組み合わされてよい。あるいは、カスタマイズされた量子化テーブルが使用され、たとえばビットストリーム内で、エンコーダからデコーダに通知されてよい。量子化は非可逆演算であり、損失は量子化ステップサイズの増加に伴って増加する。
ビデオエンコーダ20（それぞれ量子化ユニット208）の実施形態は、量子化パラメータ（QP）を直接出力するように構成されるか、またはエントロピー符号化ユニット270を介して符号化されてよく、その結果、たとえば、ビデオデコーダ30は、復号のために量子化パラメータを受信し適用することができる。
逆量子化ユニット210は、たとえば量子化ユニット208と同じ量子化ステップサイズに基づいて、またはそれを使用して、量子化ユニット208によって適用された量子化方式の逆を適用することにより、量子化係数に対して量子化ユニット208の逆量子化を適用して逆量子化係数211を取得するように構成される。逆量子化係数211は、逆量子化残差係数211とも呼ばれ、通常、量子化による損失のために変換係数と同一ではないが、変換係数207に対応する。
逆変換処理ユニット212は、変換処理ユニット206によって適用された変換の逆変換、たとえば逆離散コサイン変換（DCT）または逆離散サイン変換（DST）を適用して、サンプル領域内の逆変換ブロック213を取得するように構成される。逆変換ブロック213は、逆変換逆量子化ブロック213または逆変換残差ブロック213と呼ばれる場合もある。
復元ユニット214（たとえば、加算器214）は、たとえば、復元残差ブロック213のサンプル値と予測ブロック265のサンプル値を加算することにより、逆変換ブロック213（すなわち、復元残差ブロック213）を予測ブロック265に加算してサンプル領域内の復元ブロック215を取得するように構成される。
オプションのバッファユニット216（または短く「バッファ」216）、たとえば、ラインバッファ216は、たとえばイントラ予測のために、復元ブロック215およびそれぞれのサンプル値をバッファリングまたは格納するように構成される。さらなる実施形態では、エンコーダは、任意の種類の推定および／または予測、たとえばイントラ予測のために、バッファユニット216に格納されたフィルタリングされていない復元ブロックおよび／またはそれぞれのサンプル値を使用するように構成されてよい。
エンコーダ20の実施形態は、たとえば、バッファユニット216が、イントラ予測254のためだけでなく（図12には示されていない）ループフィルタユニット220のためにも復元ブロック215を格納するために使用されるように、かつ／または、たとえば、バッファユニット216および復号ピクチャバッファユニット230が1つのバッファを形成するように構成されてよい。さらなる実施形態は、フィルタリングされたブロック221および／または復号ピクチャバッファ230からのブロックもしくはサンプル（両方とも図12には示されていない）を、イントラ予測254のための入力または基礎として使用するように構成されてよい。
ループフィルタユニット220（または短く「ループフィルタ」220）は、たとえば、ピクセル遷移をスムーズにするか、さもなければビデオ品質を改善するために、復元ブロック215をフィルタリングして、フィルタリングされたブロック221を取得するように構成される。ループフィルタユニット220は、デブロッキングフィルタ、サンプル適応オフセット（SAO）フィルタ、または他のフィルタ、たとえば、バイラテラルフィルタもしくは適応ループフィルタ（ALF）もしくは先鋭化フィルタもしくは平滑化フィルタもしくは協調フィルタなどの1つまたは複数のループフィルタを表すものである。ループフィルタユニット220は、インループフィルタであるように図12に示されているが、他の構成では、ループフィルタユニット220は、ポストループフィルタとして実装される場合がある。フィルタリングされたブロック221は、フィルタリングされた復元ブロック221と呼ばれる場合もある。復号ピクチャバッファ230は、ループフィルタユニット220が復元コーディングブロックに対してフィルタリング演算を実行した後に復元コーディングブロックを格納することができる。
ループフィルタユニット220（または短く「ループフィルタ」220）は、復元ブロック215をフィルタリングしてフィルタリングされたブロック221を取得するか、または一般に、復元サンプルをフィルタリングしてフィルタリングされたサンプル値を取得するように構成される。ループフィルタユニットは、たとえば、ピクセル遷移をスムーズにするか、さもなければビデオ品質を改善するように構成される。ループフィルタユニット220は、デブロッキングフィルタ、サンプル適応オフセット（SAO）フィルタ、または1つもしくは複数の他のフィルタ、たとえば、適応ループフィルタ（ALF）、ノイズ抑制フィルタ（NSF）、またはそれらの任意の組合せなどの1つまたは複数のループフィルタを含んでよい。一例では、ループフィルタユニット220は、デブロッキングフィルタ、SAOフィルタ、およびALFフィルタを含んでよい。フィルタリングプロセスの順序は、デブロッキングフィルタ、SAO、およびALFであってよい。別の例では、クロマスケーリングを伴うルーママッピング（LMCS）（すなわち、適応インループリシェーパ）と呼ばれるプロセスが追加される。このプロセスはデブロッキングの前に実行される。別の例では、デブロッキングフィルタプロセスはまた、内部サブブロックエッジ、たとえば、アフィンサブブロックエッジ、ATMVPサブブロックエッジ、サブブロック変換（SBT）エッジ、およびイントラサブパーティション（ISP）エッジに適用されてよい。ループフィルタユニット220は、インループフィルタであるように図12に示されているが、他の構成では、ループフィルタユニット220は、ポストループフィルタとして実装される場合がある。フィルタリングされたブロック221は、フィルタリングされた復元ブロック221と呼ばれる場合もある。
ビデオエンコーダ20の実施形態（それぞれループフィルタユニット220）は、（SAOフィルタパラメータまたはALFフィルタパラメータまたはLMCSパラメータなどの）ループフィルタパラメータを、たとえば、直接出力するか、またはエントロピー符号化ユニット270を介して符号化されて出力するように構成されてよく、その結果、たとえば、デコーダ30は、復号のために同じループフィルタパラメータまたはそれぞれのループフィルタを受信し適用することができる。
復号ピクチャバッファ（DPB）230は、ビデオエンコーダ20によるビデオデータの符号化に使用するための基準ピクチャデータを格納する基準ピクチャメモリであってよい。DPB230は、同期型DRAM（SDRAM）、磁気抵抗RAM（MRAM）、抵抗型RAM（RRAM（登録商標））、または他のタイプのメモリデバイスを含む、ダイナミックランダムアクセスメモリ（DRAM）などの様々なメモリデバイスのいずれかによって形成されてよい。DPB230およびバッファ216は、同じメモリデバイスまたは別個のメモリデバイスによって提供されてよい。いくつかの例では、復号ピクチャバッファ（DPB）230は、フィルタリングされたブロック221を格納するように構成される。復号ピクチャバッファ230は、他の以前にフィルタリングされたブロック、たとえば同じ現在ピクチャまたは異なるピクチャ、たとえば以前に復元されたピクチャの以前に復元されフィルタリングされたブロック221を格納するようにさらに構成されてよく、たとえばインター予測のために、完全に以前に復元された、すなわち復号されたピクチャ（および対応する基準ブロックとサンプル）ならびに／または部分的に復元された現在ピクチャ（および対応する基準ブロックとサンプル）を提供することができる。いくつかの例では、復元ブロック215が復元されたがインループフィルタリングなしの場合、復号ピクチャバッファ（DPB）230は、1つまたは複数のフィルタリングされていない復元ブロック215、あるいは、たとえば、復元ブロック215が、ループフィルタユニット220、または復元されたブロックもしくはサンプルの任意の他のさらに処理されたバージョンによってフィルタリングされない場合、一般にフィルタリングされていない復元サンプルを格納するように構成される。
ブロック予測処理ユニット260とも呼ばれる予測処理ユニット260は、ブロック203（現在ピクチャ201の現在ブロック203）および復元ピクチャデータ、たとえば、バッファ216からの同じ（現在）ピクチャの基準サンプルおよび／または復号ピクチャバッファ230からの1つもしくは複数の以前に復号されたピクチャからの基準ピクチャデータ231を受信または取得し、そのようなデータを予測のために処理する、すなわち、インター予測ブロック245またはイントラ予測ブロック255であり得る予測ブロック265を提供するように構成される。
モード選択ユニット262は、残差ブロック205の計算および復元ブロック215の復元のための予測ブロック265として使用される予測モード（たとえば、イントラ予測もしくはインター予測モード）および／または対応する予測ブロック245もしくは255を選択するように構成されてよい。
モード選択ユニット262の実施形態は、（たとえば、予測処理ユニット260によってサポートされるものから）予測モードを選択するように構成されてよく、それは、最良の一致、あるいは言い換えれば、最小残差（最小残差は、送信もしくは格納のためのより良い圧縮を意味する）、または最小の通知オーバーヘッド（最小の通知オーバーヘッドは、送信もしくは格納のためのより良い圧縮を意味する）を提供するか、または両方を考慮もしくはバランスする。モード選択ユニット262は、レート歪み最適化（RDO）に基づいて予測モードを決定する、すなわち、最小レート歪み最適化を提供するか、または関連するレート歪みが少なくとも予測モード選択基準を満たす予測モードを選択するように構成されてよい。
以下では、例示的なエンコーダ20によって実行される予測処理（たとえば、予測ユニット260）および（たとえば、モード選択ユニット262による）モード選択がより詳細に説明される。
上記の実施形態に加えて、またはその代替として、図25による別の実施形態では、モード選択ユニット260は、分割ユニット262、インター予測ユニット244、およびイントラ予測ユニット254を備え、元のピクチャデータ、たとえば、元のブロック203（現在ピクチャ17の現在ブロック203）、ならびに復元ピクチャデータ、たとえば、同じ（現在）ピクチャの、および／もしくは1つまたは複数の以前に復号されたピクチャからの、たとえば、復号ピクチャバッファ230もしくは他のバッファ（たとえば、ラインバッファ、図示せず）からの、フィルタリングされたかつ／またはフィルタリングされていない復元されたサンプルまたはブロックを受信または取得するように構成される。復元ピクチャデータは、予測ブロック265または予測子265を取得するために、予測、たとえばインター予測またはイントラ予測のための基準ピクチャデータとして使用される。
モード選択ユニット260は、（分割なしを含む）現在ブロック予測モードおよび予測モード（たとえば、イントラ予測モードまたはインター予測モード）のための分割を決定または選択し、対応する予測ブロック265を生成するように構成されてよく、予測ブロック265は、残差ブロック205の計算および復元ブロック215の復元に使用される。
モード選択ユニット260の実施形態は、（たとえば、モード選択ユニット260によってサポートされるか、またはそれに利用可能なものから）分割および予測モードを選択するように構成されてよく、それは、最良の一致、または言い換えれば、最小残差（最小残差は、送信もしくは格納のためのより良い圧縮を意味する）、または最小の通知オーバーヘッド（最小の通知オーバーヘッドは、送信もしくは格納のためのより良い圧縮を意味する）を提供するか、または両方を考慮もしくはバランスする。モード選択ユニット260は、レート歪み最適化（RDO）に基づいて分割および予測モードを決定する、すなわち、最小レート歪みを提供する予測モードを選択するように構成されてよい。この文脈における「最良」、「最小」、「最適」などの用語は、必ずしも全体的な「最良」、「最小」、「最適」などを指すとは限らず、しきい値を超えるかもしくは下回る値のような終了および選択基準、または潜在的に「次善の選択」につながるが複雑さおよび処理時間を削減する他の制約を指してもよい。
言い換えれば、分割ユニット262は、ビデオシーケンスからのピクチャを一連のコーディングツリーユニット（CTU）に分割するように構成されてよく、CTU203は、たとえば、四分木分割（QT）、二分木分割（BT）、もしくは三分木分割（TT）、またはそれらの任意の組合せを繰り返し使用して、たとえば、ブロックパーティションまたはサブブロックの各々の予測を実行することにより、より小さいブロックパーティションまたは（再びブロックを形成する）サブブロックにさらに分割されてよく、モード選択は分割ブロック203のツリー構造の選択を含み、予測モードはブロックパーティションまたはサブブロックの各々に適用される。
以下では、例示的なビデオエンコーダ20によって実行される（たとえば、分割ユニット260による）分割および（インター予測ユニット244およびイントラ予測ユニット254による）予測処理がより詳細に記載される。
分割
分割ユニット262は、ビデオシーケンスからのピクチャを一連のコーディングツリーユニット（CTU）に分割するように構成されてよく、分割ユニット262は、コーディングツリーユニット（CTU）203をより小さいパーティション、たとえば、正方形または長方形のサイズのより小さいブロックに分割（partition）（または分割（split））することができる。3つのサンプル配列をもつピクチャの場合、CTUは、クロマサンプルの2つの対応するブロックと一緒にルーマサンプルのN×Nブロックから構成される。CTU内のルーマブロックの最大許容サイズは、開発中の多用途ビデオコーディング（VVC）では128×128に指定されているが、それは、将来的には128×128以外の値、たとえば、256×256に指定することができる。ピクチャのCTUは、スライス／タイルグループ、タイル、またはレンガとしてクラスタ化／グループ化されてよい。タイルはピクチャの長方形領域をカバーし、タイルは1つまたは複数のレンガに分割することができる。レンガは、タイル内のいくつかのCTU行から構成される。複数のレンガに分割されていないタイルは、レンガと呼ぶことができる。しかしながら、レンガはタイルの真のサブセットであり、タイルとは呼ばれない。VVC内でサポートされるタイルグループの2つのモード、すなわち、ラスタースキャンスライス／タイルグループモードおよび長方形スライスモードが存在する。ラスタースキャンタイルグループモードでは、スライス／タイルグループは、ピクチャのタイルラスタースキャン内の一連のタイルを含む。長方形スライスモードでは、スライスは、ピクチャの長方形領域を集合的に形成するピクチャのいくつかのレンガを含む。長方形スライス内のレンガは、スライスのレンガラスタースキャンの順序になっている。（サブブロックと呼ばれる場合もある）これらの小さいブロックは、さらに小さいパーティションにさらに分割されてよい。これは、ツリー分割または階層ツリー分割とも呼ばれ、ルートブロック、たとえばルートツリーレベル0（階層レベル0、深度0）は再帰的に分割化される、たとえば、次に低いツリーレベルの2つ以上のブロック、たとえば、ツリーレベル1（階層レベル1、深度1）にあるノードに分割されてよく、これらのブロックは、たとえば、終了基準が満たされる、たとえば、最大ツリー深度または最小ブロックサイズに達したので、分割が終了するまで、次に低いレベル、たとえば、ツリーレベル2（階層レベル2、深度2）の2つ以上のブロックに再び分割されてよい。これ以上分割されないブロックは、ツリーのリーフブロックまたはリーフノードとも呼ばれる。2つのパーティションへの分割を使用するツリーは二分木（BT）と呼ばれ、3つのパーティションへの分割を使用するツリーは三分木（TT）と呼ばれ、4つのパーティションへの分割を使用するツリーは四分木（QT）と呼ばれる。
たとえば、コーディングツリーユニット（CTU）は、3つのサンプル配列を有するピクチャのルーマサンプルのCTB、クロマサンプルの2つの対応するCTB、または、3つの別個の色平面およびサンプルをコーディングするために使用される構文構造を使用してコーディングされるモノクロピクチャもしくはピクチャのサンプルのCTBであるか、またはそれらを含んでよい。それに対応して、コーディングツリーブロック（CTB）は、成分のCTBへの区分が分割であるように、Nのある値に対するサンプルのN×Nブロックであってよい。コーディングユニット（CU）は、3つのサンプル配列を有するピクチャのルーマサンプルのコーディングブロック、クロマサンプルの2つの対応するコーディングブロック、または、3つの別個の色平面およびサンプルをコーディングするために使用される構文構造を使用してコーディングされるモノクロピクチャもしくはピクチャのサンプルのコーディングブロックであるか、またはそれらを含んでよい。それに対応して、コーディングブロック（CB）は、CTBのコーディングブロックへの区分が分割であるように、MおよびNのある値に対するサンプルのM×Nブロックであってよい。
実施形態では、たとえば、HEVCによれば、コーディングツリーユニット（CTU）は、コーディングツリーとして表記された四分木構造を使用してCUに分割されてよい。ピクチャ内（時間）またはピクチャ間（空間）予測を使用してピクチャ領域をコーディングするかどうかの決定は、リーフCUレベルで行われる。各リーフCUは、PU分割タイプに応じて、1つ、2つ、または4つのPUにさらに分割することができる。1つのPU内で、同じ予測プロセスが適用され、関連情報がPUベースでデコーダに送信される。PU分割タイプに基づいて予測プロセスを適用することによって残差ブロックを取得した後、リーフCUは、CUのためのコーディングツリーと同様の別の四分木構造に従って変換ユニット（TU）に分割することができる。
実施形態では、たとえば、多用途ビデオコーディング（VVC）と呼ばれる、現在開発中の最新のビデオコーディング規格によれば、バイナリおよび三値の分割セグメンテーション構造を使用する複合四分木ネストマルチタイプツリーは、たとえば、コーディングツリーユニットを分割するために使用される。コーディングツリーユニット内のコーディングツリー構造では、CUは正方形または長方形のいずれかの形状をもつことができる。たとえば、コーディングツリーユニット（CTU）は、最初に四分木によって分割される。次いで、四分木リーフノードは、マルチタイプツリー構造によってさらに分割することができる。マルチタイプツリー構造には、4つの分割タイプ、垂直バイナリ分割（SPLIT＿BT＿VER）、水平バイナリ分割（SPLIT＿BT＿HOR）、垂直三値分割（SPLIT＿TT＿VER）、および水平三値分割（SPLIT＿TT＿HOR）が存在する。マルチタイプツリーリーフノードはコーディングユニット（CU）と呼ばれ、CUが最大変換長に対して大き過ぎない限り、このセグメンテーションは、それ以上の分割なしに予測および変換処理に使用される。これは、ほとんどの場合、CU、PU、およびTUが、ネストされたマルチタイプツリーコーディングブロック構造を有する四分木内で同じブロックサイズをもつことを意味する。例外は、サポートされる最大変換長がCUの色成分の幅または高さよりも小さいときに発生する。VVCは、ネストされたマルチタイプツリーコーディングツリー構造を有する四分木内で情報を分割するパーティションの独自の通知メカニズムを開発する。通知メカニズムでは、コーディングツリーユニット（CTU）は、四分木のルートとして扱われ、最初に四分木構造によって分割される。次いで、（それを許可するのに十分大きいときの）各四分木リーフノードは、マルチタイプツリー構造によってさらに分割される。マルチタイプツリー構造では、ノードがさらに分割されるかどうかを示すために第1のフラグ（mtt＿split＿cu＿flag）が通知され、ノードがさらに分割されるとき、分割方向を示すために第2のフラグ（mtt＿split＿cu＿vertical＿flag）が通知され、次いで、分割がバイナリ分割か三値分割かを示すために第3のフラグ（mtt＿split＿cu＿binary＿flag）が通知される。mtt＿split＿cu＿vertical＿flagおよびmtt＿split＿cu＿binary＿flagの値に基づいて、CUのマルチタイプツリー分割モード（MttSplitMode）は、事前定義された規則またはテーブルに基づいてデコーダによって導出することができる。特定の設計、たとえば、VVCハードウェアデコーダ内の64×64ルーマブロックおよび32×32クロマパイプラインの設計の場合、図6に示されたように、ルーマコーディングブロックの幅または高さのいずれかが64より大きいとき、TT分割は禁止されることに留意されたい。クロマコーディングブロックの幅または高さのいずれかが32より大きいときも、TT分割は禁止される。パイプライン設計は、ピクチャを仮想パイプラインデータユニット（VPDU）に分割し、それらはピクチャ内で重複しないユニットとして定義される。ハードウェアデコーダでは、連続するVPDUは複数のパイプラインステージによって同時に処理される。VPDUサイズは、ほとんどのパイプラインステージ内でバッファサイズにほぼ比例するので、VPDUサイズを小さく保つことが重要である。ほとんどのハードウェアデコーダでは、VPDUサイズは最大変換ブロック（TB）サイズに設定することができる。しかしながら、VVCでは、三分木（TT）および二分木（BT）の分割は、VPDUサイズの増大につながる可能性がある。
加えて、ツリーノードブロックの一部分がピクチャの下部または右側のピクチャ境界を超えるとき、あらゆるコーディングされたCUのすべてのサンプルがピクチャ境界内に位置するまで、ツリーノードブロックが強制的に分割されることに留意されたい。
一例として、イントラサブ分割（ISP）ツールは、ルーマイントラ予測ブロックを、ブロックサイズに応じて垂直方向または水平方向に2つまたは4つのサブパーティションに分割することができる。
一例では、ビデオエンコーダ20のモード選択ユニット260は、本明細書に記載された分割技法の任意の組合せを実行するように構成されてよい。上述されたように、エンコーダ20は、一組の（事前に決定された）予測モードから最良または最適な予測モードを決定または選択するように構成される。一組の予測モードは、たとえば、イントラ予測モードおよび／またはインター予測モードを含んでよい。
一組のイントラ予測モードは、35の異なるイントラ予測モード、たとえば、DC（もしくは平均）モードおよび平面モードなどの無指向性モード、またはたとえば、H．265で定義された指向性モードを含んでよく、あるいは67の異なるイントラ予測内モード、たとえば、DC（もしくは平均）モードおよび平面モードなどの無指向性モード、またはたとえば、VVC用に定義された指向性モードを含んでよい。一例として、いくつかの従来の角度イントラ予測モードは、たとえば、VVCで定義された非正方形ブロックのための広角イントラ予測モードと適応的に置き換えられる。別の例として、DC予測用の除算演算を回避するために、非正方形ブロックの平均を計算するために長い方の辺のみが使用される。また、平面モードのイントラ予測の結果は、位置依存イントラ予測連結（PDPC）方法によってさらに修正されてよい。
イントラ予測ユニット254は、一組のイントラ予測モードのうちのイントラ予測モードに従って、同じ現在ピクチャの隣接ブロックの復元サンプルを使用してイントラ予測ブロック265を生成するように構成される。
イントラ予測ユニット254（または一般にモード選択ユニット260）は、イントラ予測パラメータ（または一般に、ブロックに対して選択されたイントラ予測モードを示す情報）を、符号化ピクチャデータ21に含めるための構文要素266の形式でエントロピー符号化ユニット270に出力するようにさらに構成され、その結果、たとえば、ビデオデコーダ30は予測パラメータを受信し復号に使用することができる。
一組の（または可能な）インター予測モードは、利用可能な基準ピクチャ（すなわち、たとえばDBP230に格納された、以前に少なくとも部分的に復号されたピクチャ）および他のインター予測パラメータ、たとえば、基準ピクチャの全体もしくは一部のみ、たとえば基準ピクチャの現在ブロックの領域の周りの検索ウィンドウ領域が、最もよく一致する基準ブロックを検索するために使用されるかどうか、ならびに／または、たとえばピクセル補間、たとえばハーフ／セミペル、クウォータペル、および／もしくは1／16ペル補間が適用されるか否かに依存する。
上記の予測モードに加えて、スキップモード、直接モード、および／または他のインター予測モードが適用されてよい。
たとえば、拡張マージ予測では、そのようなモードのマージ候補リストは、以下の5つのタイプの候補を順番に含めることによって構築される：空間隣接CUからの空間MVP、併置CUからの時間MVP、FIFOテーブルからの履歴ベースのMVP、ペアワイズ平均MVP、およびゼロMV。また、マージモードのMVの精度を高めるために、バイラテラル－マッチングベースのデコーダ側動きベクトルリファインメント（DMVR）が適用されてよい。MVDによるマージモード（MMVD）、それは、動きベクトルの差分によるマージモードに由来する。MMVDフラグは、スキップフラグおよびマージフラグを送信した直後に通知されて、MMVDモードがCUに使用されるかどうかを指定する。また、CUレベル適応動きベクトル解像度（AMVR）方式が適用されてよい。AMVRにより、CUのMVDが様々な精度でコーディングされることが可能になる。現在CUのための予測モードに応じて、現在CUのMVDが適応的に選択されてよい。CUがマージモードでコーディングされるとき、複合インター／イントラ予測（CIIP）モードが現在CUに適用されてよい。CIIP予測を取得するために、インター予測信号とイントラ予測信号の加重平均が実行される。アフィン動き補償予測、ブロックのアフィン動きフィールドは、2つの制御点（4パラメータ）または3つの制御点動きベクトル（6パラメータ）の動き情報によって記述される。サブブロックベースの時間動きベクトル予測（SbTMVP）、それはHEVC内の時間動きベクトル予測（TMVP）と同様であるが、現在CU内のサブCUの動きベクトルを予測する。以前はBIOと呼ばれた双方向オプティカルフロー（BDOF）は、特に、乗算の数および乗数のサイズに関してはるかに少ない計算で済む、より単純なバージョンである。三角形分割モード、そのようなモードでは、CUは、対角分割または反対角分割のいずれかを使用して、2つの三角形の形状のパーティションに均等に分割される。さらに、バイ予測モードは単純な平均化を超えて拡張されて、2つの予測信号の加重平均を可能にする。
上記の予測モードに加えて、スキップモードおよび／または直接モードが適用されてよい。
予測処理ユニット260は、たとえば、四分木分割（QT）、二分木分割（BT）、もしくは三分木分割（TT）、またはそれらの任意の組合せを繰り返し使用して、たとえば、ブロックパーティションまたはサブブロックの各々の予測を実行することにより、ブロック203をより小さいブロックパーティションまたはサブブロックに分割するようにさらに構成されてよく、モード選択は、分割されたブロック203のツリー構造の選択、およびブロックパーティションまたはサブブロックの各々に適用される予測モードを含む。
インター予測ユニット244は、動き推定（ME）ユニット（図2には示されていない）および動き補償（MC）ユニット（図2には示されていない）を含んでよい。動き推定ユニットは、ピクチャブロック203（現在ピクチャ201の現在ピクチャブロック203）および復号ピクチャ231、または少なくとも1つもしくは複数の以前に復元されたブロック、たとえば、動き推定のための1つもしくは複数の他の／異なる以前に復号されたピクチャ231の復元ブロックを受信または取得するように構成される。たとえば、ビデオシーケンスは、現在ピクチャおよび以前に復号されたピクチャ231を含んでよいか、または言い換えれば、現在ピクチャおよび以前に復号されたピクチャ231は、ビデオシーケンスを形成する一連のピクチャの一部であってよいか、もしくは一連のピクチャを形成することができる。
エンコーダ20は、たとえば、複数の他のピクチャの同じかまたは異なるピクチャの複数の基準ブロックから基準ブロックを選択し、基準ピクチャ（または基準ピクチャインデックス、…）および／または基準ブロックの位置（x、y座標）と現在ブロックの位置との間のオフセット（空間オフセット）を、インター予測パラメータとして動き推定ユニット（図2には示されていない）に提供するように構成されてよい。このオフセットは、動きベクトル（MV）とも呼ばれる。
動き補償ユニットは、インター予測パラメータを取得、たとえば受け取り、インター予測パラメータに基づいて、またはそれを使用してインター予測を実行して、インター予測ブロック265を取得するように構成される。動き補償ユニットによって実行される動き補償は、動き推定によって決定された動き／ブロックベクトルに基づいて予測ブロックをフェッチまたは生成すること、場合によってはサブピクセル精度への補間を実行することを含んでよい。補間フィルタリングは、既知のピクセルサンプルから追加のピクセルサンプルを生成し、したがって、ピクチャブロックをコーディングするために使用され得る候補予測ブロックの数を潜在的に増加させることができる。現在ピクチャブロックのPUのための動きベクトルを受け取ると、動き補償ユニットは、基準ピクチャリストのうちの1つにある動きベクトルが指す予測ブロックの位置を特定することができる。
イントラ予測ユニット254は、ピクチャブロック203（現在ピクチャブロック）、およびイントラ推定のために同じピクチャの1つまたは複数の以前に復元されたブロック、たとえば復元された隣接ブロックを取得する、たとえば受け取るように構成される。エンコーダ20は、たとえば、複数の（事前に決定された）イントラ予測モードからイントラ予測モードを選択するように構成されてよい。
エンコーダ20の実施形態は、最適化基準、たとえば最小残差（たとえば、現在ピクチャブロック203に最も類似する予測ブロック255を提供するイントラ予測モード）または最小レート歪みに基づいて、イントラ予測モードを選択するように構成されてよい。
イントラ予測ユニット254は、イントラ予測パラメータ、たとえば選択されたイントラ予測モードに基づいてイントラ予測ブロック255を決定するようにさらに構成される。いずれの場合も、ブロックのためのイントラ予測モードを選択した後、イントラ予測ユニット254はまた、イントラ予測パラメータ、すなわち、ブロックのための選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット270に提供するように構成される。一例では、イントラ予測ユニット254は、後述されるイントラ予測技法の任意の組合せを実行するように構成されてよい。
エントロピー符号化ユニット270は、量子化残差係数209、インター予測パラメータ、イントラ予測パラメータ、および／またはループフィルタパラメータに対して、個別もしくは一緒に（またはまったくそうではないように）、エントロピー符号化アルゴリズムまたは方式（たとえば、可変長コーディング（VLC）方式、コンテキスト適応VLC方式（CALVC）、算術コーディング方式、コンテキスト適応バイナリ算術コーディング（CABAC）、構文ベースのコンテキスト適応バイナリ算術コーディング（SBAC）、確率間隔分割エントロピー（PIPE）コーディング、または別のエントロピー符号化方法もしくは技法）を適用して、たとえば、符号化ビットストリーム21の形式で、出力272によって出力することができる符号化ピクチャデータ21を取得するように構成される。符号化ビットストリーム21は、ビデオデコーダ30に送信されるか、またはビデオデコーダ30による後の送信もしくは検索のためにアーカイブされてよい。エントロピー符号化ユニット270は、コーディングされている現在ビデオスライスの他の構文要素をエントロピー符号化するようにさらに構成することができる。
ビデオストリームを符号化するために、ビデオエンコーダ20の他の構造的変形形態を使用することができる。たとえば、非変換ベースのエンコーダ20は、特定のブロックまたはフレームに対して、変換処理ユニット206なしで直接残差信号を量子化することができる。別の実装形態では、エンコーダ20は、量子化ユニット208および逆量子化ユニット210を単一のユニットに組み合わせることができる。
図13は、本出願の技法を実装するように構成された例示的なビデオデコーダ30を示す。ビデオデコーダ30は、たとえばエンコーダ100によって符号化された符号化ピクチャデータ（たとえば、符号化ビットストリーム）21を受信して、復号ピクチャ131を取得するように構成される。復号プロセスの間、ビデオデコーダ30は、ビデオエンコーダ100から、符号化ビデオスライスのピクチャブロックおよび関連する構文要素を表す符号化ビデオビットストリームを受信する。
図13の例では、デコーダ30は、エントロピー復号ユニット304、逆量子化ユニット310、逆変換処理ユニット312、復元ユニット314（たとえば、加算器314）、バッファ316、ループフィルタ320、復号ピクチャバッファ330、および予測処理ユニット360を備える。予測処理ユニット360は、インター予測ユニット344、イントラ予測ユニット354、およびモード選択ユニット362を含んでよい。ビデオデコーダ30は、いくつかの例では、図12からビデオエンコーダ100に関して記載された符号化パスと全体的に逆となる復号パスを実行することができる。
エンコーダ20に関して説明されたように、逆量子化ユニット210、逆変換処理ユニット212、復元ユニット214、ループフィルタ220、復号ピクチャバッファ（DPB）230、インター予測ユニット344、およびイントラ予測ユニット354はまた、ビデオエンコーダ20の「内蔵デコーダ」を形成すると呼ばれる。したがって、逆量子化ユニット310は逆量子化ユニット110と機能が同一であってよく、逆変換処理ユニット312は逆変換処理ユニット212と機能が同一であってよく、復元ユニット314は復元ユニット214と機能が同一であってよく、ループフィルタ320はループフィルタ220と機能が同一であってよく、復号ピクチャバッファ330は復号ピクチャバッファ230と機能が同一であってよい。したがって、ビデオエンコーダ20のそれぞれのユニットおよび機能について提供された説明は、ビデオデコーダ30のそれぞれのユニットおよび機能に対応して当てはまる。
エントロピー復号ユニット304は、符号化ピクチャデータ21に対してエントロピー復号を実行して、たとえば量子化係数309および／または復号コーディングパラメータ（図13には示されていない）、たとえばインター予測パラメータ、イントラ予測パラメータ、ループフィルタパラメータ、および／または他の構文要素の（復号された）いずれかまたはすべてを取得するように構成される。エントロピー復号ユニット304は、インター予測パラメータ、イントラ予測パラメータ、および／または他の構文要素を予測処理ユニット360に転送するようにさらに構成される。ビデオデコーダ30は、ビデオスライスレベルおよび／またはビデオブロックレベルで構文要素を受信することができる。
エントロピー復号ユニット304は、ビットストリーム21（または一般に符号化ピクチャデータ21）を構文解析し、たとえば、符号化ピクチャデータ21に対してエントロピー復号を実行して、たとえば、量子化係数309および／または復号コーディングパラメータ（図13には示されていない）、たとえば、インター予測パラメータ（たとえば、基準ピクチャインデックスおよび動きベクトル）、イントラ予測パラメータ（たとえば、イントラ予測モードもしくはインデックス）、変換パラメータ、量子化パラメータ、ループフィルタパラメータ、および／または他の構文要素のいずれかまたはすべてを取得するように構成される。エントロピー復号ユニット304は、エンコーダ20のエントロピー符号化ユニット270に関して記載された符号化方式に対応する復号アルゴリズムまたは方式を適用するように構成されてよい。エントロピー復号ユニット304は、モード適用ユニット360にインター予測パラメータ、イントラ予測パラメータ、および／または他の構文要素を提供し、デコーダ30の他のユニットに他のパラメータを提供するようにさらに構成されてよい。ビデオデコーダ30は、ビデオスライスレベルおよび／またはビデオブロックレベルで構文要素を受信することができる。スライスおよびそれぞれの構文要素に加えて、またはそれらの代替として、タイルグループおよび／またはタイルならびにそれぞれの構文要素が受信および／または使用されてよい。
逆量子化ユニット310は逆量子化ユニット110と機能が同一であってよく、逆変換処理ユニット312は逆変換処理ユニット112と機能が同一であってよく、復元ユニット314は復元ユニット114と機能が同一であってよく、バッファ316はバッファ116と機能が同一であってよく、ループフィルタ320はループフィルタ120と機能が同一であってよく、復号ピクチャバッファ330は復号ピクチャバッファ130と機能が同一であってよい。
デコーダ30の実施形態は、分割ユニット（図13には描写されていない）を含んでよい。一例では、ビデオデコーダ30の予測処理ユニット360は、上述された分割技法の任意の組合せを実行するように構成されてよい。
予測処理ユニット360は、インター予測ユニット344およびイントラ予測ユニット354を備えてよく、インター予測ユニット344は、機能がインター予測ユニット144と似ていてよく、イントラ予測ユニット354は、機能がイントラ予測ユニット154と似ていてよい。予測処理ユニット360は、通常、ブロック予測を実行し、かつ／または符号化データ21から予測ブロック365を取得し、予測関連パラメータおよび／または選択された予測モードに関する情報を、たとえばエントロピー復号ユニット304から（明示的または暗黙的に）受け取るかまたは取得するように構成される。
ビデオスライスがイントラ符号化（I）スライスとして符号化されるとき、予測処理ユニット360のイントラ予測ユニット354は、通知されたイントラ予測モードおよび現在のフレームまたはピクチャの以前に復号されたブロックからのデータに基づいて、現在ビデオスライスのピクチャブロックのための予測ブロック365を生成するように構成される。ビデオフレームがインター符号化（すなわち、BまたはP）スライスとして符号化されるとき、予測処理ユニット360のインター予測ユニット344（たとえば、動き補償ユニット）は、エントロピー復号ユニット304から受け取った動きベクトルおよび他の構文要素に基づいて、現在ビデオスライスのビデオブロックのための予測ブロック365を生成するように構成される。インター予測の場合、予測ブロックは、基準ピクチャリストのうちの1つにある基準ピクチャのうちの1つから生成されてよい。ビデオデコーダ30は、DPB330に格納された基準ピクチャに基づいて、デフォルトの構築技法を使用して基準フレームリスト、リスト0およびリスト1を構築することができる。
予測処理ユニット360は、動きベクトルおよび他の構文要素を構文解析することにより、現在ビデオスライスのビデオブロックについての予測情報を特定し、予測情報を使用して、復号されている現在ビデオブロックのための予測ブロックを生成する。たとえば、動き補償ユニット360は、受け取った構文要素のいくつかを使用して、ビデオスライスのビデオブロックをコーディングするために使用される予測モード（たとえば、イントラ予測またはインター予測）、インター予測スライスタイプ（たとえば、Bスライス、Pスライス、またはGPBスライス）、スライス用の基準ピクチャリストのうちの1つまたは複数についての構築情報、スライスのインター符号化ビデオブロックごとの動きベクトル、スライスのインター符号化ビデオブロックごとのインター予測状態、および現在ビデオスライス内のビデオブロックを復号するための他の情報を特定する。
逆量子化ユニット310は、ビットストリーム内で提供され、エントロピー復号ユニット304によって復号された量子化変換係数を逆量子化する、すなわち、量子化解除するように構成される。逆量子化処理は、ビデオスライス内のビデオブロックごとにビデオエンコーダ100によって計算された量子化パラメータを使用して、量子化の程度と、同様に適用されるべき逆量子化の程度を決定することを含んでよい、
逆量子化ユニット310は、（たとえば、エントロピー復号ユニット304による、たとえば、構文解析および／または復号により）符号化ピクチャデータ21から量子化パラメータ（QP）（または一般に逆量子化に関連する情報）および量子化係数を受け取り、量子化パラメータに基づいて、復号された量子化係数309に対して逆量子化を適用して、変換係数311と呼ばれる場合もある逆量子化係数311を取得するように構成されてよい。
逆変換処理ユニット312は、逆変換、たとえば、逆DCT、逆整数変換、または概念的に類似する逆変換プロセスを適用して、ピクセル領域内の残差ブロックを生成するために係数を変換するように構成される。
逆変換処理ユニット312は、変換係数311とも呼ばれる逆量子化係数311を受け取り、サンプル領域内で復元残差ブロック213を取得するために逆量子化係数311に変換を適用するように構成されてよい。復元残差ブロック213は、変換ブロック313と呼ばれる場合もある。変換は、逆変換、たとえば、逆DCT、逆DST、逆整数変換、または概念的に類似する逆変換プロセスであってよい。逆変換処理ユニット312は、（たとえば、エントロピー復号ユニット304による、たとえば、構文解析および／または復号により）符号化ピクチャデータ21から変換パラメータまたは対応する情報を受け取って、逆量子化係数311に適用される変換を決定するようにさらに構成されてよい。
復元ユニット314（たとえば、加算器314）は、たとえば、復元残差ブロック313のサンプル値と予測ブロック365のサンプル値を加算することにより、逆変換ブロック313（すなわち、復元残差ブロック313）を予測ブロック365に加算してサンプル領域内の復元ブロック315を取得するように構成される。
（コーディングループ内またはコーディングループ後のいずれかで）ループフィルタユニット320は、復元ブロック315をフィルタリングして、フィルタリングされたブロック321を取得する、たとえばピクセル遷移をスムーズにするか、さもなければビデオ品質を改善するように構成される。ループフィルタユニット320は、デブロッキングフィルタ、サンプル適応オフセット（SAO）フィルタ、または1つもしくは複数の他のフィルタ、たとえば、適応ループフィルタ（ALF）、ノイズ抑制フィルタ（NSF）、またはそれらの任意の組合せなどの1つまたは複数のループフィルタを含んでよい。一例では、ループフィルタユニット220は、デブロッキングフィルタ、SAOフィルタ、およびALFフィルタを含んでよい。フィルタリングプロセスの順序は、デブロッキングフィルタ、SAO、およびALFであってよい。別の例では、クロマスケーリングを伴うルーママッピング（LMCS）（すなわち、適応インループリシェーパ）と呼ばれるプロセスが追加される。このプロセスはデブロッキングの前に実行される。別の例では、デブロッキングフィルタプロセスはまた、内部サブブロックエッジ、たとえば、アフィンサブブロックエッジ、ATMVPサブブロックエッジ、サブブロック変換（SBT）エッジ、およびイントラサブパーティション（ISP）エッジに適用されてよい。ループフィルタユニット320は、インループフィルタであるように図13に示されているが、他の構成では、ループフィルタユニット320は、ポストループフィルタとして実装される場合がある。
次いで、所与のフレームまたはピクチャにある復号ビデオブロック321は、後続の動き補償に使用される基準ピクチャを格納する復号ピクチャバッファ330に格納される。
次いで、ピクチャの復号ビデオブロック321は復号ピクチャバッファ330に格納され、復号ピクチャバッファ330は、他のピクチャのための後続の動き補償および／またそれぞれの表示の出力のための基準ピクチャとして復号ピクチャ331を格納する。
デコーダ30は、ユーザへの提示または表示のために、たとえば出力332を介して復号ピクチャ331を出力するように構成される。
ビデオデコーダ30の他の変形形態は、圧縮されたビットストリームを復号するために使用することができる。たとえば、デコーダ30は、ループフィルタリングユニット320なしで出力ビデオストリームを生成することができる。たとえば、非変換ベースのデコーダ30は、特定のブロックまたはフレームに対して、逆変換処理ユニット312なしで直接残差信号を逆量子化することができる。別の実装形態では、ビデオデコーダ30は、逆量子化ユニット310および逆変換処理ユニット312を単一のユニットに組み合わせることができる。
上記の実施形態に加えて、またはその代替として、図26による別の実施形態では、機能において、インター予測ユニット344はインター予測ユニット244（特に動き補償ユニット）と同一であってよく、イントラ予測ユニット354はインター予測ユニット254と同一であってよく、分割パラメータおよび／もしくは予測パラメータ、または（たとえば、エントロピー復号ユニット304による、たとえば、構文解析および／もしくは復号により）符号化ピクチャデータ21から受け取ったそれぞれの情報に基づいて、分割（split）または分割（partitioning）の決定および予測を実行する。モード適用ユニット360は、復元されたピクチャ、ブロック、または（フィルタリングされたかもしくはフィルタリングされていない）それぞれのサンプルに基づいて、ブロックごとに予測（イントラ予測またはインター予測）を実行して、予測ブロック365を取得するように構成されてよい。
ビデオスライスがイントラ符号化（I）スライスとして符号化されるとき、モード適用ユニット360のイントラ予測ユニット354は、通知されたイントラ予測モードおよび現在ピクチャの以前に復号されたブロックからのデータに基づいて、現在ビデオスライスのピクチャブロックのための予測ブロック365を生成するように構成される。ビデオピクチャがインター符号化（すなわち、BまたはP）スライスとして符号化されるとき、モード適用ユニット360のインター予測ユニット344（たとえば、動き補償ユニット）は、エントロピー復号ユニット304から受け取った動きベクトルおよび他の構文要素に基づいて、現在ビデオスライスのビデオブロックのための予測ブロック365を生成するように構成される。インター予測の場合、予測ブロックは、基準ピクチャリストのうちの1つにある基準ピクチャのうちの1つから生成されてよい。ビデオデコーダ30は、DPB330に格納された基準ピクチャに基づいて、デフォルトの構築技法を使用して基準フレームリスト、リスト0およびリスト1を構築することができる。同じかまたは類似するものは、スライス（たとえば、ビデオスライス）に加えて、またはその代わりに、タイルグループ（たとえば、ビデオタイルグループ）および／またはタイル（たとえば、ビデオタイル）を使用する実施形態に、または実施形態によって適用されてよく、たとえば、ビデオは、I、P、またはBのタイルグループおよび／またはタイルを使用してコーディングされてよい。
モード適用ユニット360は、動きベクトルまたは関連情報および他の構文要素を構文解析することにより、現在ビデオスライスのビデオブロックについての予測情報を特定し、予測情報を使用して、復号されている現在ビデオブロックのための予測ブロックを生成するように構成される。たとえば、モード適用ユニット360は、受け取った構文要素のいくつかを使用して、ビデオスライスのビデオブロックをコーディングするために使用される予測モード（たとえば、イントラ予測またはインター予測）、インター予測スライスタイプ（たとえば、Bスライス、Pスライス、またはGPBスライス）、スライス用の基準ピクチャリストのうちの1つまたは複数についての構築情報、スライスのインター符号化ビデオブロックごとの動きベクトル、スライスのインター符号化ビデオブロックごとのインター予測状態、および現在ビデオスライス内のビデオブロックを復号するための他の情報を特定する。同じかまたは類似するものは、スライス（たとえば、ビデオスライス）に加えて、またはその代わりに、タイルグループ（たとえば、ビデオタイルグループ）および／またはタイル（たとえば、ビデオタイル）を使用する実施形態に、または実施形態によって適用されてよく、たとえば、ビデオは、I、P、またはBのタイルグループおよび／またはタイルを使用してコーディングされてよい。
図13に示されたビデオデコーダ30の実施形態は、（ビデオスライスとも呼ばれる）スライスを使用してピクチャを分割および／または復号するように構成されてよく、ピクチャは、1つまたは複数のスライス（通常は重複しない）を使用して分割または復号されてよく、各スライスは、1つもしくは複数のブロック（たとえば、CTU）またはブロックの1つもしくは複数のグループ（たとえば、タイル（H．265／HEVCおよびVVC）もしくはレンガ（VVC））を含んでよい。
図13に示されたビデオデコーダ30の実施形態は、（ビデオタイルグループとも呼ばれる）スライス／タイルグループおよび／または（ビデオタイルとも呼ばれる）タイルを使用してピクチャを分割および／または復号するように構成されてよく、ピクチャは、1つまたは複数のスライス／タイルグループ（通常は重複しない）を使用して分割または復号されてよく、各スライス／タイルグループは、たとえば、1つもしくは複数のブロック（たとえば、CTU）または1つもしくは複数のタイルを含んでよく、各タイルは、たとえば、長方形の形状であってよく、1つまたは複数のブロック（たとえば、CTU）、たとえば、完全または部分的なブロックを含んでよい。
ビデオデコーダ30の他の変形形態は、符号化ピクチャデータ21を復号するために使用することができる。たとえば、デコーダ30は、ループフィルタリングユニット320なしで出力ビデオストリームを生成することができる。たとえば、非変換ベースのデコーダ30は、特定のブロックまたはフレームに対して、逆変換処理ユニット312なしで直接残差信号を逆量子化することができる。別の実装形態では、ビデオデコーダ30は、逆量子化ユニット310および逆変換処理ユニット312を単一のユニットに組み合わせることができる。
エンコーダ20およびデコーダ30では、現在のステップの処理結果がさらに処理され、次いで次のステップに出力されてよいことを理解されたい。たとえば、補間フィルタリング、動きベクトル導出またはループフィルタリングの後、クリップまたはシフトなどのさらなる演算が、補間フィルタリング、動きベクトル導出またはループフィルタリングの処理結果に対して実行されてよい。
図14は、本開示の一実施形態による、ビデオコーディングデバイス400の概略図である。ビデオコーディングデバイス400は、本明細書に記載された開示された実施形態を実装するのに適している。一実施形態では、ビデオコーディングデバイス400は、図11Aのビデオデコーダ30などのデコーダ、または図11Aのビデオエンコーダ20などのエンコーダであってよい。一実施形態では、ビデオコーディングデバイス400は、上述された図11Aのビデオデコーダ30または図11Aのビデオエンコーダ20の1つまたは複数の構成要素であってよい。
ビデオコーディングデバイス400は、データを受信するための入口ポート410および受信機ユニット（Rx）420と、データを処理するためのプロセッサ、論理ユニット、または中央処理装置（CPU）430と、データを送信するための送信機ユニット（Tx）440および出口ポート450と、データを記憶するためのメモリ460とを備える。ビデオコーディングデバイス400はまた、光信号または電気信号の出口または入口のための、入口ポート410、受信機ユニット420、送信機ユニット440、および出口ポート450に結合された、光－電気（OE）構成要素および電気－光（EO）構成要素を備えてよい。
プロセッサ430は、ハードウェアおよびソフトウェアによって実装される。プロセッサ430は、1つまたは複数のCPUチップ、コア（たとえば、マルチコアプロセッサとして）、FPGA、ASIC、およびDSPとして実装されてよい。プロセッサ430は、入口ポート410、受信機ユニット420、送信機ユニット440、出口ポート450、およびメモリ460と通信する。プロセッサ430はコーディングモジュール470を備える。コーディングモジュール470は、上記の開示された実施形態を実装する。たとえば、コーディングモジュール470は、様々なコーディング動作を実装、処理、準備、または提供する。したがって、コーディングモジュール470を含めることにより、ビデオコーディングデバイス400の機能に実質的な改善がもたらされ、ビデオコーディングデバイス400の異なる状態への変換がもたらされる。あるいは、コーディングモジュール470は、メモリ460に記憶され、プロセッサ430によって実行される命令として実装される。
メモリ460は、1つまたは複数のディスク、テープドライブ、およびソリッドステートドライブを含み、プログラムが実行のために選択されたときにそのようなプログラムを記憶し、かつプログラムの実行中に読み取られる命令およびデータを記憶するために、オーバーフローデータストレージデバイスとして使用されてよい。メモリ460は、揮発性および／または不揮発性であってもよく、読取り専用メモリ（ROM）、ランダムアクセスメモリ（RAM）、三値連想メモリ（TCAM）、および／またはスタティックランダムアクセスメモリ（SRAM）であってもよい。
図15は、例示的な一実施形態による、図11からのソースデバイス310および宛先デバイス320のいずれかまたは両方として使用され得る装置500の簡略化されたブロック図である。装置500は、上述された本出願の技法を実装することができる。装置500は、複数のコンピューティングデバイスを含むコンピューティングシステムの形態、または単一のコンピューティングデバイス、たとえば、携帯電話、タブレットコンピュータ、ラップトップコンピュータ、ノートブックコンピュータ、デスクトップコンピュータなどの形態であり得る。
装置500内のプロセッサ502は中央処理装置であり得る。あるいは、プロセッサ502は、現在存在するかまたは今後開発される、情報を操作または処理することが可能な、任意の他のタイプのデバイス、または複数のデバイスであり得る。開示された実装形態は、図示されたように単一のプロセッサ、たとえば、プロセッサ502で実践することができるが、速度および効率の利点は、2つ以上のプロセッサを使用して実現することができる。
装置500内のメモリ504は、一実装形態では、読取り専用メモリ（ROM）デバイスまたはランダムアクセスメモリ（RAM）デバイスであり得る。任意の他の適切なタイプのストレージデバイスをメモリ504として使用することができる。メモリ504は、バス512を使用してプロセッサ502によってアクセスされるコードおよびデータ506を含むことができる。メモリ504は、オペレーティングシステム508およびアプリケーションプログラム510をさらに含むことができ、アプリケーションプログラム510は、プロセッサ502が本明細書に記載された方法を実行することを可能にする少なくとも1つのプログラムを含む。たとえば、アプリケーションプログラム510はアプリケーション1～Nを含むことができ、それらは本明細書に記載された方法を実行するビデオコーディングアプリケーションをさらに含む。装置500はまた、セカンダリストレージ514の形態で追加のメモリを含むことができ、それは、たとえば、モバイルコンピューティングデバイスとともに使用されるメモリカードであり得る。ビデオ通信セッションはかなりの量の情報を含む場合があるので、それらは、全体的または部分的にセカンダリストレージ514に記憶され、処理のために必要に応じてメモリ504にロードされ得る。装置500はまた、ディスプレイ518などの1つまたは複数の出力デバイスを含むことができる。ディスプレイ518は、一例では、タッチ入力を検知するように動作可能なタッチセンサ式要素とディスプレイを組み合わせたタッチセンサ式ディスプレイであってよい。ディスプレイ518は、バス512を介してプロセッサ502に結合することができる。
装置500はまた、ディスプレイ518などの1つまたは複数の出力デバイスを含むことができる。ディスプレイ518は、一例では、タッチ入力を検知するように動作可能なタッチセンサ式要素とディスプレイを組み合わせたタッチセンサ式ディスプレイであってよい。ディスプレイ518は、バス512を介してプロセッサ502に結合することができる。ユーザが装置500をプログラムするか、さもなければ使用することを可能にする他の出力デバイスは、ディスプレイ518に加えて、またはその代わりとして提供することができる。出力デバイスがディスプレイであるか、またはディスプレイを含むとき、ディスプレイは、液晶ディスプレイ（LCD）、ブラウン管（CRT）ディスプレイ、プラズマディスプレイ、または有機LED（OLED）ディスプレイなどの発光ダイオード（LED）ディスプレイを含む様々な方法で実装することができる。
装置500はまた、画像検知デバイス520、たとえばカメラ、または装置500を操作するユーザの画像などの画像を検知することができる、現在存在するかもしくは今後開発される、任意の他の画像検知デバイス520を含むか、またはそれと通信することができる。画像検知デバイス520は、装置500を操作するユーザに向けられるように配置することができる。一例では、画像検知デバイス520の位置および光軸は、ディスプレイ518に直接隣接し、そこからディスプレイ518が見える領域を視野が含むように構成することができる。
装置500はまた、音波検知デバイス522、たとえば、マイクロフォン、または装置500の近くの音波を検知することができる、現在存在するかもしくは今後開発される、任意の他の音波検知デバイスを含むか、またはそれと通信することができる。音波検知デバイス522は、装置500を操作するユーザに向けられるように配置することができ、ユーザが装置500を操作する間にユーザによって作られる音波、たとえば、音声または他の発話を受信するように構成することができる。
図15は、装置500のプロセッサ502およびメモリ504を単一のユニットに統合されているように描写するが、他の構成を利用することができる。プロセッサ502の動作は、直接またはローカルエリアネットワークもしくは他のネットワークを介して結合することができる複数のマシン（各マシンは1つまたは複数のプロセッサを有する）にわたって分散させることができる。メモリ504は、ネットワークベースのメモリまたは装置500の動作を実行する複数のマシン内のメモリなどの複数のマシンにわたって分散させることができる。ここでは単一のバスとして描写されているが、装置500のバス512は複数のバスから構成することができる。さらに、セカンダリストレージ514は、装置500の他の構成要素に直接結合することができるか、またはネットワークを介してアクセスすることができ、メモリカードなどの単一の統合ユニットまたは複数のメモリカードなどの複数のユニットを備えることができる。したがって、装置500は多種多様な構成で実装することができる。
分割制約要素間の関係に関する実施形態
本開示は、複数の符号化ピクチャを含むビットストリームを介して通知され得る、（異なるピクチャ分割方法のための分割規則を設定する）分割制約要素間の関係に関する。したがって、本発明は、そのようなビットストリームを生成、復号、または処理し、特に、分割制約要素をビットストリームに含め、新しい分割規則に従って分割制約を抽出するためのデバイスおよび方法を提供する。
上記の構文要素の名前は、それらが従来使用されているように（本明細書全体を通して）使用されることに留意されたい。しかしながら、これらの名前は、技術的なコンテキストを変更せずに変更される可能性があることは明らかなはずである。したがって、重要と見なされるべきことは構文要素の論理的な意味である。
現在、分割制約要素（たとえば、MaxBtSizeY、MaxMttDepth、およびMinQtSizeY）は、それらの定義範囲内で個別に通知される。詳細には、現在、CtbSizeYの構文要素（すなわち、log2＿ctu＿size＿minus2）、およびMinQtSizeYの構文要素（すなわち、log2＿min＿qt＿size＿intra＿slices＿minus2およびlog2＿min＿qt＿size＿inter＿slices＿minus2）、ならびにMaxMttDepthの構文要素（すなわち、max＿mtt＿hierarchy＿depth＿inter＿slicesおよびmax＿mtt＿hierarchy＿depth＿intra＿slices）は、シーケンスパラメータセット（SPS）内で通知される。さらに、ルーマCTBサイズとMaxBtSizeYとの間の差分の構文要素（すなわち、log2＿diff＿ctu＿max＿bt＿size）は、スライスヘッダ内で通知される。SPSおよびスライスヘッダは、ピクチャビットストリームに含まれてよい。
例示的なSPS構文、特に、SPS Raw Byte Sequence Payload（RBSP）構文が図8に示されている。この構文のSPS RBSPセマンティクスは以下の通りである。
「pic＿width＿in＿luma＿samples」は、各復号ピクチャの幅をルーマサンプルの単位で指定し、0に等しくなく、MinCbSizeYの整数倍でなければならない。
「pic＿height＿in＿luma＿samples」は、各復号ピクチャの高さをルーマサンプルの単位で指定し、0に等しくなく、MinCbSizeYの整数倍でなければならない。
「log2＿ctu＿size＿minus2」プラス2は、各CTUのルーマCTBサイズを指定する。
要素CtbLog2SizeY、CtbSizeY、MinCbLog2SizeY、MinCbSizeY、MinTbLog2SizeY、MaxTbLog2SizeY、PicWidthInCtbsY、PicHeightInCtbsY、PicSizeInCtbsY、PicWidthInMinCbsY、PicHeightInMinCbsY、PicSizeInMinCbsY、PicSizeInSamplesY、PicWidthInSamplesC、およびPicHeightInSamplesCは、通常、以下のように導出される。
・CtbLog2SizeY＝log2＿ctu＿size＿minus2＋2
・CtbSizeY＝1＜＜CtbLog2SizeY
・MinCbLog2SizeY＝2
・MinCbSizeY＝1＜＜MinCbLog2SizeY
・MinTbSizeY＝4
・MaxTbSizeY＝64
・PicWidthInCtbsY＝Ceil（pic＿width＿in＿luma＿samples÷CtbSizeY）
・PicHeightInCtbsY＝Ceil（pic＿height＿in＿luma＿samples÷CtbSizeY）
・PicSizeInCtbsY＝PicWidthInCtbsY＊PicHeightInCtbsY
・PicWidthInMinCbsY＝pic＿width＿in＿luma＿samples／MinCbSizeY
・PicHeightInMinCbsY＝pic＿height＿in＿luma＿samples／MinCbSizeY
・PicSizeInMinCbsY＝PicWidthInMinCbsY＊PicHeightInMinCbsY
・PicSizeInSamplesY＝pic＿width＿in＿luma＿samples＊pic＿height＿in＿luma＿samples
・PicWidthInSamplesC＝pic＿width＿in＿luma＿samples／SubWidthC
・PicHeightInSamplesC＝pic＿height＿in＿luma＿samples／SubHeightC
「log2＿min＿qt＿size＿intra＿slices＿minus2」プラス2は、slice＿typeが2（I）に等しいスライス内のCTUの四分木分割から生じるリーフブロックの最小ルーマサイズを指定する。log2＿min＿qt＿size＿intra＿slices＿minus2の値は、両端を含む0～CtbLog2SizeY－2の範囲でなければならない。
・MinQtLog2SizeIntraY＝log2＿min＿qt＿size＿intra＿slices＿minus2＋2
「log2＿min＿qt＿size＿inter＿slices＿minus2」プラス2は、slice＿typeが0（B）または1（P）に等しいスライス内のCTUの四分木分割から生じるリーフブロックの最小ルーマサイズを指定する。log2＿min＿qt＿size＿inter＿slices＿minus2の値は、両端を含む0～CtbLog2SizeY－2の範囲でなければならない。
・MinQtLog2SizeInterY＝log2＿min＿qt＿size＿inter＿slices＿minus2＋2
「max＿mtt＿hierarchy＿depth＿inter＿slices」は、slice＿typeが0（B）または1（P）に等しいスライス内の四分木リーフのマルチタイプツリー分割から生じるコーディングユニットの最大階層深度を指定する。max＿mtt＿hierarchy＿depth＿inter＿slicesの値は、両端を含む0～CtbLog2SizeY－MinTbLog2SizeYの範囲でなければならない。
「max＿mtt＿hierarchy＿depth＿intra＿slices」は、slice＿typeが2（I）に等しいスライス内の四分木リーフのマルチタイプツリー分割から生じるコーディングユニットの最大階層深度を指定する。max＿mtt＿hierarchy＿depth＿intra＿slicesの値は、両端を含む0～CtbLog2SizeY－MinTbLog2SizeYの範囲でなければならない。
さらに、図9は例示的なスライスヘッダ構文を示す。この構文のスライスヘッダセマンティクスは以下の通りである。
「log2＿diff＿ctu＿max＿bt＿size」は、バイナリ分割を使用して分割することができるコーディングブロックのルーマCTBサイズと最大ルーマサイズ（幅または高さ）との間の差分を指定する。log2＿diff＿ctu＿max＿bt＿sizeの値は、両端を含む0～CtbLog2SizeY－MinCbLog2SizeYの範囲でなければならない。
log2＿diff＿ctu＿max＿bt＿sizeが存在しない場合、log2＿diff＿ctu＿max＿bt＿sizeの値は2に等しいと推測される。
要素MinQtLog2SizeY、MaxBtLog2SizeY、MinBtLog2SizeY、MaxTtLog2SizeY、MinTtLog2SizeY、MaxBtSizeY、MinBtSizeY、MaxTtSizeY、MinTtSizeY、およびMaxMttDepthは、通常、以下のように導出される。
・MinQtLog2SizeY＝（slice＿type＝＝I）？MinQtLog2SizeIntraY：MinQtLog2SizeInterY
・MaxBtLog2SizeY＝CtbLog2SizeY－log2＿diff＿ctu＿max＿bt＿size
・MinBtLog2SizeY＝MinCbLog2SizeY
・MaxTtLog2SizeY＝（slice＿type＝＝I）？5：6
・MinTtLog2SizeY＝MinCbLog2SizeY
・MinQtSizeY＝1＜＜MinQtLog2SizeY
・MaxBtSizeY＝1＜＜MaxBtLog2SizeY
・MinBtSizeY＝1＜＜MinBtLog2SizeY
・MaxTtSizeY＝1＜＜MaxTtLog2SizeY
・MinTtSizeY＝1＜＜MinTtLog2SizeY
・MaxMttDepth＝（slice＿type＝＝I）？max＿mtt＿hierarchy＿depth＿intra＿slices：max＿mtt＿hierarchy＿depth＿inter＿slices
図8に示されたように、現在、ピクチャシーケンス（たとえば、ビデオシーケンスのピクチャ）の幅および高さは、構文要素「pic＿width＿in＿luma＿samples」および「pic＿height＿in＿luma＿samples」を使用して示されている。従来、これらの構文要素は、ピクチャを最小サイズのコーディングブロックに分割できることを確保するために、MinCbSizeYの倍数である必要がある。しかしながら、pic＿height＿in＿luma＿samplesおよびpic＿width＿in＿luma＿samplesはMinCbSizeYの倍数でなければならないが、利用可能な四分木、二分木、および三分木の分割方法をそれぞれ使用してピクチャをブロックに完全に分割できることはまだ保証されていない。この問題の一例は以下のように説明される。
例として、
・MinCbSizeYは4に等しい
・MinQtSizeYは32に等しい
・MaxBtSizeYは16に等しい
と仮定する。
この例では、pic＿width＿in＿luma＿samples＝132およびpic＿width＿in＿luma＿samples＝132である場合、ピクチャの幅および高さは4の倍数であるが、ピクチャを完全に分割することはまだ可能でない。その理由は、たとえば、32×32のサイズの親ブロックは、バイナリ分割または四分木分割を使用して分割できないことであり、四分木分割が適用された場合、MinQtSizeY制限に違反し、バイナリ分割が適用された場合、MaxBtSizeY制限に違反するからである。言い換えれば、幅または高さが4に等しいブロックを生成することは可能でないが、それは、ピクチャを完全に分割するために必要である。
このように、上記で例示されたように、現在、従来の分割規則を完全に尊重してピクチャを分割するという問題が存在する。これは、いくつかのピクチャサイズを符号化および復号できないことを意味するので、実際には大きい問題である。
図1は、本発明の一般的な実施形態によるデバイス100を示す。デバイス100は、符号化ピクチャ、たとえばビデオビットストリームを含むビットストリーム101を生成または処理する、すなわち操作するのに適している。デバイス100は、ピクチャを符号化し、ビットストリーム101を生成するように構成されたエンコーダに含まれてよいか、またはエンコーダを備えてよい。デバイス100は、分割制約要素間の関係を決定することができ、これらの分割制約要素および／またはそれらの関係をビットストリーム101に含めることができる。それにより、デバイス100は、分割制約要素および／または関係を、ビットストリーム101内のSPS構文および／またはスライスヘッダ構文に追加することができる。
同様の方式で、デコーダデバイスはビットストリームを構文解析し、かつ／またはビットストリームから、事前定義された規則を適用することにより、分割に関連する制約パラメータを推測する。次いで、制約パラメータは、パーティションを正確に復号および復元するのに役立つ。エンコーダおよびデコーダは同じ構文上で動作（同じ構文を処理）する。
詳細には、デバイス100は、MaxBtSizeY 102を決定するように、かつ／またはMaxMttDepth 103およびMinCbSizeY 104を決定するように構成される。次いで、デバイス100は、MaxBtSizeY 102に基づいて、かつ／またはMaxMttDepth 103およびMinCbSizeY 104に基づいて、MinQtSizeY 105を決定するように構成される。最後に、デバイス100は、決定されたMinQtSizeY 105を、間接的に（すなわち、MinQtSizeY 105を導出することができる情報を含めることにより）、または直接的にビットストリーム101に含めるように構成される。
図1に示されたデバイス100に基づく、本発明の第1の特定の実施形態によるデバイス100では、MinQtSizeY 105の値の範囲は、MaxBtSizeY 102の値に基づいて制限される場合がある。たとえば、MinQtSizeY 105の上限は、MaxBtSizeY 102に制限される場合がある。言い換えれば、第1の特定の実施形態によるデバイス100では、MinQtSizeY 105の最小値は、MaxBtSizeY 102よりも大きくなることができない。
あるいは、または上記に加えて、第1の特定の実施形態によるデバイス100では、MinQtSizeY 105の値の範囲は、MaxMttDepth 103に基づいて制限される場合がある。この場合、たとえば：
・MaxMttDepth 103が0に等しい場合、MinQtSizeY 105はMinCbSizeY 104に等しい（またはそのように推測される）場合がある。
・MaxMttDepth 103が0より大きい場合、MinQtSizeY 105の上限は（MinCbSizeY 104＜＜MaxMttDepth 103）に等しい可能性がある。言い換えれば、MinQtSizeY 105は（MinCbSizeY 104＜＜MaxMttDepth 103）より大きくてはならない。
特に、本明細書全体を通して、演算x＜＜yは数学的にxyとして記述することができ、ここで、xは2のn乗であり、nは非負の整数である。言い換えれば、x＜＜yは、xをyビット左にシフトすることを表す。
このように、第1の特定の実施形態によるデバイス100は、特に、四分木分割方法またはバイナリ分割方法の組合せを使用して親ブロックを再帰的に分割することによって最小のパーティションブロックを実現することができるように、MinQtSizeY 105と、MinCbSizeY 104、MaxBtSizeY 102、および／またはMaxMttDepth 103との間の関係を設定するように構成される。（そのサイズがMinCbSizeY 104によって示される）最小のブロックは、利用可能な分割方法で生成することができるので、MinCbSizeY 104の倍数のサイズをもつピクチャを完全に分割することが可能である。
図2および図3は、本発明の第2の特定の実施形態によるデバイスのためのSPS RPBS構文200およびスライスヘッダ構文300を示す。詳細には、図8に示された従来のSPS RBSP構文は、図2に示された構文200に変更される（新しい要素は太字でマークされ、削除された要素は線で消されている）。さらに、図9に示された従来のスライスヘッダ構文は、図3に示された構文300に変更される（新しい要素は太字でマークされ、削除された要素は線で消されている）。第2の特定の実施形態によるデバイスは、図1に示されたデバイス100に基づいてもよく、本発明の別個の実施形態であってもよい。第2の特定の実施形態によるデバイスでは、以下が実装される。
・MaxBtSizeY 102は、MinQtSizeY 105に関連するビットストリーム101内で通知される。言い換えれば、図3に示されたように、MaxBtSizeY 102とMinQtSizeY 105との間の差分の構文要素301は、（たとえば、log2＿diff＿max＿bt＿size＿min＿qt＿sizeなどの構文要素を使用して）ビットストリーム101内で通知されてよく、MinQtSizeY 105およびlog2＿diff＿max＿bt＿size＿min＿qt＿sizeに基づいて、（たとえば、ビットストリーム101のデコーダにおいて）MaxBtSizeY 102を導出することができる。この場合、一例では、
・MaxBtSizeY 102＝MinQtSizeY 105＜＜log2＿diff＿max＿bt＿size＿min＿qt＿size
であり、
・特に、この例では、MaxBtSizeY 102とMinQtSizeY 105との間の差分の構文要素301が対数スケールで（特に基数2で）通知される。この例では、log2＿diff＿max＿bt＿size＿min＿qt＿sizeは正の整数値またはゼロ値のみをもつことができる。
・MaxMttDepth 103は、MinQtSizeY 105およびMinCbSizeY 104に関連するビットストリーム101内で通知される。図2に示されたように、MaxMttDepth 103とMinQtSizeY 105のlog2値との間の差分の構文要素201は、（たとえば、構文要素：
diff＿max＿mtt＿hierarchy＿depth＿log2＿min＿qt＿sizeを使用して）ビットストリーム101内で通知されてよい。2つのそのような構文要素201が図2に示され、1つはinter＿slices用であり、1つはintra＿slices用である。この場合、その例では、
・MaxMttDepth 103＝diff＿max＿mtt＿hierarchy＿depth＿log2＿min＿qt＿size＋log2（MinQtSizeY）－log2（MinCbSizeY）である。
・特に、この例では、diff＿max＿mtt＿hierarchy＿depth＿log2＿min＿qt＿sizeが対数スケールで通知されることが再び想定されている。関数log2（x）は、基数2のxの対数に対応する。
図3では、「log2＿diff＿max＿bt＿size＿min＿qt＿size」は、バイナリ分割を使用して分割することができるコーディングブロックの最大ルーマサイズ（幅または高さ）と、四分木分割を使用して分割することができるコーディングブロックの最小ルーマサイズ（幅または高さ）との間の差分を指定する。log2＿diff＿ctu＿max＿bt＿sizeの値は、両端を含む0～CtbLog2SizeY－MinQtLog2SizeYの範囲でなければならない。
図4は、本発明の第3の特定の実施形態によるデバイスのためのSPS RPBS構文400を示す。第3の特定の実施形態によるデバイスは、図1に示されたデバイス100に基づいてもよく、本発明の別個の実施形態であってもよい。先述されたように、従来、通知されるピクチャサイズ要素405および406（pic＿width＿in＿luma＿samplesおよびpic＿height＿in＿luma＿samples）は、各々、MinCbSizeY 104の整数倍の値として指定される。
対照的に、第3の特定の実施形態によるデバイスの第1の実装形態では、ピクチャサイズ要素405および406は、MinQtSizeY 105の整数倍である値のみをもつように制約される場合がある。その利点は、境界ブロックが利用可能な分割方法として四分木分割を常にもつことができることである。
第3の特定の実施形態によるデバイスの第2の実装形態では、ピクチャの幅および高さは、MinQtSizeY 105に基づいてビットストリーム101内で通知されてよい。詳細には、図8に示された従来のSPS RBSP構文は、図4に示された構文400に従って変更される（新しい要素は太字でマークされ、削除された要素は線で消されている）。
この場合、図4に示されたSPS構文400では、4つの構文要素401～404、特に、intra＿slice当たり2つの構文要素（高さ／幅）、およびinter＿slice当たり2つの構文要素（高さ／幅）が通知されてよい（たとえば、log2＿diff＿pic＿height＿min＿Qtおよびlog2＿diff＿pic＿width＿min＿Qt）。好ましくは、これらの構文要素401～404は、実際のピクチャサイズ要素405および406の代わりに通知され、ピクチャの幅および高さは、以下の関係を使用して決定されてよい。
・ルーマサンプル内のピクチャの幅＝MinQtSizeY 105＜＜log2＿diff＿pic＿width＿min＿Qt
・ルーマサンプル内のピクチャの高さ＝MinQtSizeY 105＜＜log2＿diff＿pic＿height＿min＿Qt
構文要素401～404、特に差分は、対数スケールに基づいてSPS構文400内で示すことができる。
図5および図6は、本発明の第4の特定の実施形態によるデバイスのための、2つのスライスヘッダ構文5000および600をそれぞれ示す。第4の特定の実施形態によるデバイスは、図1に示されたデバイス100に基づいてもよく、本発明の別個の実施形態であってもよい。
本発明の第4の特定の実施形態によるデバイスは、MaxMttDepth 103が0に等しいと推測、通知、または指示された場合、MaxBtSizeY 102（またはMaxTtSizeY）が依然としてビットストリーム101内に存在することができ、MinCbSizeY 104より大きい値をもつことができ、MinBtSizeY（またはMinTtSizeY）が依然としてMinCbSizeY 104に等しい値をもつことができるという問題に関係する。この状態は、エンコーダおよび／またはデコーダの動作に曖昧さを生じさせる可能性があり、その結果、ピクチャフレームの完全な分割が依然として可能でない可能性がある。
第4の特定の実施形態によるデバイスの第1の実装形態では、MaxMttDepth 103の値に基づいて、MaxBtSizeY 102（またはMaxTtSizeY）がビットストリーム101内で通知または指示される。詳細には、図9に示された従来のスライスヘッダ構文は、図5に示された構文5000に変更される（新しい要素は太字でマークされている）。すなわち、デバイスは、MaxMttDepth 103に依存するMaxBtSizeY 102（またはMaxTtSizeY）の構文要素5001をビットストリーム101に含めるように構成される。
具体的には、MaxMttDepth 103が0に等しいとき、MaxBtSizeY 102（またはMaxTtSizeY）は、ビットストリーム101内で通知されない場合があるが、（たとえば、デコーダにおいて）MinCbSizeY 104に等しいと推測される場合がある。あるいは、MaxBtSizeY 102（またはMaxTtSizeY）は、MaxMttDepth 103が0に等しい場合、（たとえば、デコーダにおいて）たとえば、4または8などのデフォルトの事前定義された値に等しいと推測される。
「log2＿diff＿ctu＿max＿bt＿size」は、この場合も、バイナリ分割を使用して分割することができるコーディングブロックのルーマCTBサイズと最大ルーマサイズ（幅または高さ）との間の差分を指定する。log2＿diff＿ctu＿max＿bt＿sizeの値は、両端を含む0～CtbLog2SizeY－MinCbLog2SizeYの範囲でなければならない。
log2＿diff＿ctu＿max＿bt＿sizeが存在しないとき、以下が適用される場合がある：slice＿typeが2（I）に等しく、max＿mtt＿hierarchy＿depth＿intra＿slicesが1に等しい場合、log2＿diff＿ctu＿max＿bt＿sizeの値は2に等しいと推測されてよい。そうでない場合、log2＿diff＿ctu＿max＿bt＿sizeの値はCtbLog2SizeY－MinCbLog2SizeYに等しいと推測されてよい。
第4の特定の実施形態によるデバイスの第2の実装形態では、MaxMttDepth 103は、MaxBtSizeY 102（またはMaxTtSizeY）の値に基づいて、ビットストリーム101内で通知または指示される。詳細には、図9に示された従来のスライスヘッダ構文は、図6に示された構文600に変更される（新しい要素は太字でマークされている）。すなわち、デバイスは、MaxBtSizeY 102またはMaxTtSizeYに依存するMaxMttDepth 103の構文要素601をビットストリーム101に含めるように構成される。
具体的には、MaxBtSizeY 102（またはMaxTtSizeY）が0に等しいとき、MaxMttDepth 103は通知されない場合があるが、たとえば、デコーダにおいて、0に等しいと推測される場合がある。MaxMttDepth 103の値が0に等しい場合、それはバイナリ分割が適用されることが許可されないことを意味する。この解決策では、MaxBtSizeY 102およびMaxTtSizeYの構文要素は、MaxMttDepth 103の前に通知されるべきであるが、いかなるパラメータセットヘッダにおいても制限されない。
「MaxTtSizeY」は、三値分割を使用して分割することができるコーディングブロックの、サンプル数の単位の最大ルーマサイズ（幅または高さ）として定義される。「MinTtSizeY」は、三値分割を使用して分割することができるコーディングブロックの、サンプル数の単位の最小ルーマサイズ（幅または高さ）として定義される。
図6では、「max＿mtt＿hierarchy＿depth」は、スライス内の四分木リーフのマルチタイプツリー分割から生じるコーディングユニットの最大階層深度を指定する。max＿mtt＿hierarchy＿depth＿inter＿slicesの値は、両端を含む0～CtbLog2SizeY－MinTbLog2SizeYの範囲でなければならない。max＿mtt＿hierarchy＿depthが存在しないとき、max＿mtt＿hierachiy＿depthの値は0と推測される。
図7は、本発明の一実施形態による方法7000を示す。方法7000は、具体的に、ビットストリーム101を操作するためであり、図1に示されたデバイス100によって実行されてよい。方法7000はまた、ビットストリーム101のピクチャをビットストリーム101に符号化する、すなわちビットストリーム101を生成するエンコーダによって実行されてよい。
方法7000は、MaxBtSizeY 102を決定する、かつ／またはMaxMttDepth 103およびMinCbSizeY 104を決定するステップ7001を含む。さらに、方法7000は、MaxBtSizeY 102に基づいて、かつ／またはMaxMttDepth 103およびMinCbSizeY 104に基づいて、MinQtSizeY 105を決定するステップ7002を含む。最後に、方法7000は、決定されたMinQtSizeY 105をビットストリーム101に含めるステップ7003を含む。
図10は、本発明の一般的な実施形態によるデバイス1000を示す。デバイス1000は、符号化ピクチャ、たとえばビデオビットストリームを含むビットストリーム101を生成または処理する、すなわち操作するのに適している。デバイス1000は、ピクチャを符号化し、ビットストリーム101を生成するように構成されたエンコーダに含まれてよいか、またはエンコーダを備えてよい。デバイス1000は、分割制約要素間の関係を決定することができ、これらの分割制約要素および／またはそれらの関係をビットストリーム101に含めることができる。それにより、デバイス1000は、分割制約要素および／または関係を、ビットストリーム101内のSPS構文および／またはスライスヘッダ構文に追加することができる。デバイス1000は図1に示されたデバイス100の代替である。しかしながら、図10に関して下記で説明されるデバイス1000の特徴は、（それらが図1のデバイス100に基づかない場合）第1、第2、第3、または第4の特定の実施形態によるデバイスの上記の特徴と組み合わされてよい。
詳細には、デバイス1000は、MinQtSizeY（105）を決定するように構成される。さらに、デバイスは、MinQtSizeY 105に基づいて、MaxBtSizeY 102を決定し、かつ／またはMaxMttDepth 103を決定するように構成される。最後に、デバイスは、決定されたMaxBtSizeY 102および／または決定されたMaxMttDepth 103を、間接的に（すなわち、MaxBtSizeY 102および／もしくはMaxMttDepth 103を導出することができる情報を含めることにより）、または直接的にビットストリーム（101）に含めるように構成される。
たとえば、デバイス1000は、その下限がMinQtSizeY 105であることを考慮して、MaxBtSizeY 102を決定することができる。すなわち、MaxBtSizeY 102の値の範囲は、MinQtSizeY 105の値によって制限される場合がある。たとえば、MaxBtSizeY 102の下限は、MinQtSizeY 105に制限される場合がある。言い換えれば、デバイス1000では、MaxBtSizeY 102の最小値は、MinQtSizeY 105よりも小さくなるとはできない。
あるいは、または上記に加えて、デバイス1000では、その上限がMinQtSizeY 105のlog2値とMinCbSizeY 104のlog2値の差分であることを考慮して、MaxMttDepth 103が決定されてよい。すなわち、MaxMttDepth 103の最大値は、MinQtSizeY 105のlog2値とMinCbSizeY 104のlog2値の差分より大きくなることはできない。
要約すると、本発明の第1の態様は、符号化ピクチャを含むビットストリームを生成または処理するためのデバイスを提供し、デバイスは、MaxBtSizeYを決定し、かつ／またはMaxMttDepthおよびMinCbSizeYを決定し、MaxBtSizeYに基づいて、かつ／またはMaxMttDepthおよびMinCbSizeYに基づいてMinQtSizeYを決定し、決定されたMinQtSizeYをビットストリームに含めるように構成される。
MaxBtSizeYに基づいて、かつ／またはMaxMttDepthおよびMinCbSizeYに基づいてMinQtSizeYを決定することにより、すなわち、これらの分割制約要素間の関係を設定することを介して新しい分割規則を定義することにより、第1の態様のデバイスは、様々なピクチャ分割方法、特に四分木分割および二分木分割の可用性および柔軟性の向上を実現する。
第1の態様の実装形態では、デバイスは、その上限がMaxBtSizeYであることを考慮してMinQtSizeYを決定し、かつ／またはその上限がMinCbSizeYのMaxMttDepth乗であることを考慮してMinQtSizeYを決定するように構成される。
分割制約要素MinQtSizeY、MinCbSizeY、MaxBtSizeY、およびMaxMttDepthの間にそのような関係をそれぞれ設定することにより、四分木分割方法またはバイナリ分割方法の組合せを使用して親ブロックを再帰的に分割することにより、最小の分割ブロックを実現できることが保証される。（そのサイズがMinCbSizeYによって示される）最小のブロックは利用可能な分割方法で生成することができるので、サイズがMinCbSizeYの倍数であるピクチャを完全に分割することが可能である。
第1の態様のさらなる実装形態では、デバイスは、MaxMttDepthがゼロに等しい場合、MinQtSizeYがMinCbSizeYであると決定し、MaxMttDepthがゼロよりも大きい場合、MinQtSizeYがMinCbSizeYのMaxMttDepth乗であると決定するように構成される。
これにより、それぞれ、四分木分割および二分木分割を使用してピクチャの完全な分割を可能にするために、以前の実装形態の効率的な実装形態が提供される。
本発明の第2の態様は、符号化ピクチャを含むビットストリームを生成または処理するためのデバイスを提供し、デバイスは、MinQtSizeYを決定し、MaxBtSizeYを決定し、かつ／またはMinQtSizeYに基づいてMaxMttDepthを決定し、決定されたMaxBtSizeYおよび／または決定されたMaxMttDepthをビットストリームに含めるように構成される。
第2の態様の実装形態では、デバイスは、その下限がMinQtSizeYであることを考慮してMaxBtSizeYを決定し、かつ／またはその上限がMinQtSizeYのlog2値とMinCbSizeYのlog2値の差分であることを考慮してMaxMttDepthを決定するように構成される。
第1の態様と同様に、第2の態様は、分割制約要素間の関係を設定することを介して新しい分割規則を定義する。このように、第2の態様のデバイスは、様々なピクチャ分割方法、特に四分木分割および二分木分割の可用性および柔軟性の向上を実現する。
第1または第2の態様のさらなる実装形態では、デバイスは、MinQtSizeYとMaxBtSizeYとの間の関係、特に差分の指示をビットストリームに含めるように構成される。
このように、関連する分割制約要素は、たとえば、デコーダ側において簡単に推測することができ、同時にビットストリーム内の情報オーバーヘッドが削減される。差分は関係の一例である。しかしながら、関係は、比例係数、計算方式などである可能性もあり、それにより、MinQtSizeYからMaxBtSizeYを推測することが可能になる。
第1または第2の態様のさらなる実装形態では、デバイスは、MinQtSizeYのlog2値とMaxMttDepthとの間の関係、特に差分の指示をビットストリームに含めるように構成される。
このように、関連する分割制約要素は、たとえば、デコーダ側において推測することができ、同時にビットストリーム内の情報オーバーヘッドが削減される。
第1または第2の態様のさらなる実装形態では、デバイスは、ビットストリームのピクチャのサイズ、特に高さおよび幅を示す1つまたは複数のピクチャサイズ要素をMinQtSizeYの整数倍であると決定し、1つまたは複数のピクチャサイズ要素をビットストリームに含めるように構成される。
結果として、境界ブロックは利用可能な分割方法として四分木分割を常にもつことができる。
第1または第2の態様のさらなる実装形態では、デバイスは、ビットストリームのピクチャのサイズ、特に高さおよび幅を示す1つまたは複数のピクチャサイズ要素を決定し、ピクチャサイズ要素とMinQtSizeYとの間の関係の指示をビットストリームに含めるように構成される。
このように、関連する分割制約要素は、たとえば、デコーダ側において推測することができ、同時にビットストリーム内の情報オーバーヘッドが削減される。
第1または第2の態様のさらなる実装形態では、ピクチャサイズ要素とMinQtSizeYとの間の関係の指示は、対数スケールに基づく。
第1または第2の態様のさらなる実装形態では、デバイスは、MaxMttDepthに依存するMaxBtSizeYまたはMaxTtSizeYの指示をビットストリームに含めるように構成される。
このようにして、エンコーダおよび／またはデコーダの動作において従来引き起こされた曖昧さが排除され、ピクチャフレームの完全な分割が可能になる。
第1または第2の態様のさらなる実装形態では、デバイスは、MaxMttDepthがゼロに等しい場合、MaxBtSizeYまたはMaxTtSizeYのいかなる指示もビットストリームに含めないように構成される。
これにより、ビットストリーム内の情報オーバーヘッドの削減が可能になる。
第1または第2の態様のさらなる実装形態では、デバイスは、MaxBtSizeYまたはMaxTtSizeYに依存するMaxMttDepthの指示をビットストリームに含めるように構成される。
このようにして、エンコーダおよび／またはデコーダの動作において従来引き起こされた曖昧さが排除され、ピクチャフレームの完全な分割が可能になる。
第1または第2の態様のさらなる実装形態では、デバイスは、MaxBtSizeYまたはMaxTtSizeYがゼロに等しい場合、MaxMttDepthのいかなる指示もビットストリームに含めないように構成される。
これにより、ビットストリーム内の情報オーバーヘッドの削減が可能になる。
第1または第2の態様のさらなる実装形態では、デバイスは、ビットストリームのピクチャを符号化するように構成されたエンコーダを備えるか、またはエンコーダに含まれる。
本発明の第3の態様は、符号化ピクチャを含むビットストリームを生成または処理するための方法を提供し、方法は、MaxBtSizeYを決定し、かつ／またはMaxMttDepthおよびMinCbSizeYを決定するステップと、MaxBtSizeYに基づいて、かつ／またはMaxMttDepthおよびMinCbSizeYに基づいてMinQtSizeYを決定するステップと、決定されたMinQtSizeYをビットストリームに含めるステップとを含む。
第3の態様の実装形態では、方法は、その上限がMaxBtSizeYであることを考慮してMinQtSizeYを決定し、かつ／またはその上限がMinCbSizeYのMaxMttDepth乗であることを考慮してMinQtSizeYを決定するステップを含む。
第3の態様のさらなる実装形態では、方法は、MaxMttDepthがゼロに等しい場合、MinQtSizeYがMinCbSizeYであると決定するステップと、MaxMttDepthがゼロよりも大きい場合、MinQtSizeYがMinCbSizeYのMaxMttDepth乗であると決定するステップとを含む。
第3の態様のさらなる実装形態では、方法は、MinQtSizeYとMaxBtSizeYとの間の関係、特に差分の指示をビットストリームに含めるステップを含む。
第3の態様のさらなる実装形態では、方法は、MinQtSizeYとMaxMttDepthとの間の関係、特に差分の指示をビットストリームに含めるステップを含む。
第3の態様のさらなる実装形態では、方法は、ビットストリームのピクチャのサイズ、特に高さおよび幅を示す1つまたは複数のピクチャサイズ要素をMinQtSizeYの整数倍であると決定するステップと、1つまたは複数のピクチャサイズ要素をビットストリームに含めるステップとを含む。
第3の態様のさらなる実装形態では、方法は、ビットストリームのピクチャのサイズ、特に高さおよび幅を示す1つまたは複数のピクチャサイズ要素を決定するステップと、ピクチャサイズ要素とMinQtSizeYとの間の関係の指示をビットストリームに含めるステップとを含む。
第3の態様のさらなる実装形態では、ピクチャサイズ要素とMinQtSizeYとの間の関係の指示は、対数スケールに基づく。
第3の態様のさらなる実装形態では、方法は、MaxMttDepthに依存するMaxBtSizeYまたはMaxTtSizeYの指示をビットストリームに含めるステップを含む。
第3の態様のさらなる実装形態では、方法は、MaxMttDepthがゼロに等しい場合、MaxBtSizeYまたはMaxTtSizeYのいかなる指示もビットストリームに含めないステップを含む。
第3の態様のさらなる実装形態では、方法は、MaxBtSizeYまたはMaxTtSizeYに依存するMaxMttDepthの指示をビットストリームに含めるステップを含む。
第3の態様のさらなる実装形態では、方法は、MaxBtSizeYまたはMaxTtSizeYがゼロに等しい場合、MaxMttDepthのいかなる指示もビットストリームに含めないステップを含む。
第3の態様のさらなる実装形態では、方法は、ビットストリームのピクチャを符号化するエンコーダにおいて実行される。
第3の態様の方法およびその実装形態により、第1の態様の対応するデバイスおよびそのそれぞれの実装形態について上述されたすべての利点および効果を実現することができる。本発明のさらなる態様は、第2の態様のデバイスに対応する、ビットストリームを生成または処理するための方法である。
本発明の第4の態様は、符号化ピクチャを含むビットストリームを生成または処理するためのデバイスを提供し、デバイスは、MinQtSizeYとMaxBtSizeYとの間の関係、特に差分の指示をビットストリームに含め、かつ／またはMinQtSizeYとMaxMttDepthとの間の関係、特に差分の指示をビットストリームに含めるように構成される。
第4の態様のデバイスにより、関連する分割制約要素を通知することができ、同時にビットストリーム内の情報オーバーヘッドが削減される。分割制約要素は、たとえば、デコーダ側において推測することができる。第4の態様のデバイスは、様々なピクチャ分割方法、特に四分木分割および二分木分割の可用性および柔軟性の向上を実現する。
本発明の第5の態様は、符号化ピクチャを含むビットストリームを生成または処理するためのデバイスを提供し、デバイスは、ビットストリームのピクチャのサイズ、特に高さおよび幅を示す1つもしくは複数のピクチャサイズ要素をMinQtSizeYの整数倍であると決定し、1つもしくは複数のピクチャサイズ要素をビットストリームに含めるか、またはビットストリームのピクチャのサイズ、特に高さおよび幅を示す1つもしくは複数のピクチャサイズ要素を決定し、ピクチャサイズ要素とMinQtSizeYとの間の関係の指示をビットストリームに含めるように構成される。
第5の態様のデバイスにより、境界ブロックは、利用可能な分割方法として四分木分割を常にもつことができる。さらに、関連する分割制約要素は、たとえば、デコーダ側において推測することができ、同時にビットストリーム内の情報オーバーヘッドが削減される。第5の態様のデバイスは、様々なピクチャ分割方法、特に四分木分割および二分木分割の可用性および柔軟性の向上を実現する。
本発明の第6の態様は、符号化ピクチャを含むビットストリームを生成または処理するためのデバイスを提供し、デバイスは、MaxMttDepthに依存するMaxBtSizeYもしくはMaxTtSizeYの指示をビットストリームに含めるか、またはMaxBtSizeYもしくはMaxTtSizeYに依存するMaxMttDepthの指示をビットストリームに含めるように構成される。
第6の態様のデバイスは、エンコーダおよび／またはデコーダの動作において従来引き起こされた曖昧さを低減または排除し、したがって、ピクチャフレームの完全な分割をサポートする。第6の態様のデバイスは、様々なピクチャ分割方法、特に四分木分割および二分木分割の可用性および柔軟性の向上を実現する。
本発明の第7の態様は、プログラムコードがデバイスの1つまたは複数のプロセッサによって実行されるときに、第3の態様およびそのそれぞれの実装形態の方法を実行するようにデバイスを制御するためのプログラムコードを含むコンピュータプログラム製品を提供する。デバイスは、第1、第2、第4、第5、もしくは第6の態様、またはそれらの任意の実装形態のデバイスであってよい。
本発明の第8の態様は、第1、第2、第4、第5、もしくは第6の態様、またはそれらの任意の実装形態によるデバイスによって生成または処理されたビットストリームを復号するためのデバイスを提供する。
境界分割に関係する実施形態
多用途ビデオコーディング（VVC）の次世代規格は、共同ビデオ調査チーム（JVET）として知られるパートナーシップで協働している、国際電気通信連合電気通信標準化部門（ITU－T）ビデオコーディングエキスパートグループ（VCEG）と国際標準化機構／国際電気技術委員会（ISO／IEC）動画エキスパートグループ（MPEG）標準化組織の最新の共同ビデオプロジェクトである。VVCでは、マルチタイプ（バイナリ／三値／四値）ツリー（BT／TT／QTまたは二分木／三分木／四分木）セグメンテーション構造は、複数の分割ユニットタイプの概念を置き換えるか、または置き換える可能性があり、すなわち、それは、サイズが最大変換長に対して大き過ぎるCUに必要な場合を除いて、CU、PU、およびTUの概念の分離を取り除き、CU分割形状のための柔軟性をサポートする［JVET－J1002］。
図6A～図6Fは、一例として、VTM内で現在使用されている分割モードを示す。図16Aは分割されていないブロック（分割なし）を示し、図16Bは四値または四分木（QT）分割を示し、図16Cは水平バイナリまたは二分木（BT）分割を示し、図16Dは垂直バイナリまたは二分木（BT）分割を示し、図16Eは水平三値または三分木（TT）分割を示し、図16FはCUまたはCTUなどのブロックの垂直三値または三分木（TT）分割を示す。実施形態は、図16A～図16Fに示された分割モードを実施するように構成されてよい。
実施形態では、以下のパラメータは、BT／TT／QTコーディングツリー方式のためのシーケンスパラメータセット（SPS）構文要素によって定義および指定されてよい。
CTUサイズ：四分木のルートノードサイズ
MinQTSize：最小許容四分木リーフノードサイズ
MaxBTTSize：最大許容二分木および三分木ルートノードサイズ
MaxBTTDepth：最大許容二分木および三分木深度
MinBTTSize：最小許容二分木および三分木リーフノードサイズ
他の実施形態では、最小許容四分木リーフノードサイズMinQTSizeパラメータはまた、他のヘッダまたはセット、たとえば、スライスヘッダ（SH）またはピクチャパラメータセット（PPS）に含まれてよい。
HEVC規格では、スライス／ピクチャ境界に位置するコーディングツリーユニット（CTU）またはコーディングユニット（CU）は、リーフノードの右下のサンプルがスライス／ピクチャ境界内に位置するまで、四分木（QT）を使用して強制分割される。エンコーダとデコーダの両方、たとえば、ビデオエンコーダ20とビデオデコーダ30の両方は、強制QTをいつ適用するかを知っているので、強制的なQTパーティションまたは分割は、ビットストリーム内で通知される必要がない。強制分割の目的は、ビデオエンコーダ20／ビデオデコーダ30によって境界CTU／CUを可能にすることである。
国際特許公開番号WO2016／090568は、QTBT（四分木プラス二分木）構造を開示し、VTM1．0でも、境界CTU／CU強制分割プロセスがHEVCから継承されている。すなわち、フレーム境界に位置するCTU／CUは、現在CU全体がピクチャ境界内に収まるまで、レート歪み（RD）最適化を考慮せずに、四分木（QT）構造によって強制分割される。これらの強制分割は、ビットストリーム内で通知されない。
図7Aは、強制QTによって分割された高解像度（HD）（1920×1080ピクセル）の下部境界CTU（128×128）に対する強制分割の例を示す。図17では、HDピクチャは、1920×1080ピクセルを有するかそれであり、CTUは128×128ピクセルを有するかそれである。
サンディエゴ会議（2018年4月）でのCE1（分割）のSubCE2（ピクチャ境界処理）［JVET－J1021］では、BT、TT、またはABT（非対称BT）を使用するピクチャ境界処理について15のテストが提案された。たとえば、JVET－K0280およびJVET－K0376では、境界は図18に示されたように定義される。図18は、ドットハッシュ線によるピクチャの境界、および直線の境界ケースの領域、すなわち下部境界ケース、コーナー境界ケース、および右側境界ケースを示す。下部境界は水平強制BTまたは強制QTによって分割することができ、右側境界は垂直強制BTまたは強制QTによって分割することができ、コーナーケースは強制QTによってのみ分割することができ、強制BT分割または強制QT分割のいずれかを使用するかどうかの決定は、レート歪み最適化基準に基づき、ビットストリーム内で通知される。強制分割は、ブロックが分割されなければならないことを意味し、たとえば、強制分割は、図16Aに示された「分割なし」を使用してコーディングされない場合がある境界ブロックに適用される。
強制境界分割で強制QT分割が使用される場合、MinQTSizeの分割制約は無視される。たとえば、図19Aでは、SPS内でMinQTSizeが32として通知された場合、境界を強制QT方法と一致させるために、ブロックサイズ8×8に分割されたQTが必要になり、それにより、MinQTSizeが32であるという制約は無視される。
本開示の実施形態によれば、強制QTがピクチャ境界分割に使用された場合、強制QT分割は、たとえば、SPS内で通知された分割制約に従う、たとえば、それを無視しない。さらなる強制分割が必要な場合、強制BTのみが使用され、それは組み合わせて強制QTBTと呼ばれる場合もある。本開示の実施形態では、たとえば、分割制約MinQTSizeは、ピクチャ境界での強制QT分割のために考慮され、強制BT分割のためのさらなる通知は必要でない。実施形態はまた、通常の（非境界）ブロックおよび境界ブロックの分割を調和させることを可能にする。たとえば、従来の解決策では、2つの「MinQTSize」パラメータが必要であり、1つは通常のブロック分割用であり、もう1つは境界ブロック分割用である。実施形態は、通常のブロックと境界ブロックの両方の分割に対して1つの共通の「MinQTSize」パラメータのみを必要とし、それは、たとえば、1つの「MinQTSize」パラメータを通知することにより、エンコーダとデコーダとの間で柔軟に設定されてよい。さらに、実施形態は、たとえば、強制QTよりも少ない分割を必要とする。
下部境界ケースおよび右側境界ケースのための解決策
下部および右側の境界ケースでは、ブロックサイズがMinQTSizeより大きい場合、ピクチャ境界分割用の分割モードは、たとえば、RDO（レートデ歪み最適化）に基づいて、強制BT分割と強制QT分割との間で選択することができる。そうでない場合（すなわち、ブロックサイズがMinQTSize以下である場合）、強制BT分割のみがピクチャ境界分割に使用され、より具体的には、水平強制BTは、ピクチャの下部境界に位置する境界ブロックの下部境界にそれぞれ使用され、垂直強制BTは、ピクチャの右側境界に位置する境界ブロックの右側境界にそれぞれ使用される。
強制BT分割は、現在ブロックのサブパーティションがピクチャの下部境界に位置するまで水平強制境界分割によって現在ブロックを再帰的に分割することと、リーフノードがピクチャの右側境界に完全に位置するまで垂直強制境界分割によってサブパーティションを再帰的に分割することとを含んでよい。あるいは、強制BT分割は、現在ブロックのサブパーティションが下部境界に位置するまで垂直強制境界分割によって現在ブロックを再帰的に分割することと、リーフノードが右側境界に完全に位置するまで水平強制境界分割によってサブパーティションを再帰的に分割することとを含んでよい。MinQTSizeは、非境界ブロックの分割を制御するためにも適用されてよい。
たとえば、図17Aに示されたケースでは、MinQTSizeが32であるか、または32に制限され、8サンプルの高さまたは幅の長方形（非正方形）ブロックのサイズがピクチャ境界と一致する必要がある場合、強制BT分割は、32×32の境界に位置するブロックを分割するために使用される。BTパーティションは、同じタイプの強制BT分割を使用してさらに分割されてよく、たとえば、強制垂直BT分割が適用されている場合は、さらなる強制垂直BT分割のみが適用され、強制水平BT分割が適用されている場合は、さらなる強制水平BT分割のみが適用される。強制BT分割は、リーフノードが完全にピクチャ内に収まるまで継続される。
図17Bは、本発明の一実施形態による、128×128サンプルのサイズを有する下部境界CTUの例示的な分割を示す。分割ツリーのルートブロックまたはルートノードを形成する下部境界CTUは、より小さいパーティション、たとえば、正方形または長方形のサイズの小さいブロックに分割される。これらの小さいパーティションまたはブロックは、さらに小さいパーティションまたはブロックにさらに分割されてよい。図17Bでは、CTUは、最初に、各々が64×64サンプルのサイズを有する4つの正方形ブロック710、720、730、および740に分割された四分木である。これらのブロックのうち、ブロック710および720はこの場合も下部境界ブロックであるが、ブロック730および740はピクチャの外側にあり（それぞれピクチャの外側に位置し）、処理されない。
ブロック710は、四分木分割を使用して、各々が32×32サンプルのサイズを有する4つの正方形ブロック750、760、770、および780にさらに分割される。ブロック750および760はピクチャの内側に位置するが、ブロック770および780はこの場合も下部境界ブロックを形成する。ブロック770のサイズは、たとえば32であるMinQTSizeよりも大きくないので、再帰的な水平強制バイナリ分割は、リーフノードが完全にピクチャ内にあるか完全にピクチャ内に位置するまで、たとえば、（1つの水平バイナリ分割後）リーフノードブロック772、32×16サンプルを有する長方形非正方形ブロックがピクチャ内にあるか、または（2つの水平バイナリ分割後）リーフノードブロック774、ピクチャの下部境界に位置し、32×8サンプルを有する長方形非正方形ブロックがピクチャ内にあるまで、ブロック770に適用される。同じことがブロック780にも当てはまる。
本開示の実施形態は、ピクチャの完全に内側に位置する通常のブロックに対する分割と境界ブロックの分割を調和させることを可能にする。境界ブロックは、ピクチャの完全に内側にはなく、ピクチャの完全に外側にはないブロックである。言い換えれば、境界ブロックは、ピクチャ内に位置する部分およびピクチャ外に位置する部分を含むブロックである。さらに、本開示の実施形態は、MinQTSize以下での強制BT分割が通知される必要がないので、通知を削減することが可能になる。
コーナーケースのための解決策
コーナーケースでは、いくつかの手法は強制QT分割のみを可能にし、MinQTSizeの制約も無視される。本開示の実施形態は、コーナーケースのための2つの解決策を提供する。コーナーケースは、現在処理されているブロックがピクチャの隅にあるときに発生する。これは、現在ブロックが2つのピクチャ境界（垂直および水平）と交差または隣接しているケースである。
解決策1：
コーナーケースは、下部境界ケースまたは右側境界ケースと見なされる。図20は、境界定義の一実施形態を示す。図20は、ドットハッシュ線によるピクチャの境界および直線の境界ケースの領域を示す。図示されたように、コーナーケースは下部境界ケースとして定義される。このように、解決策は、上記の下部境界ケースおよび右側境界ケースについて記載されたものと同じである。言い換えれば、最初に、ブロックまたはパーティションが（垂直方向に）完全にピクチャ内に収まるまで（下部境界ケースについて記載されたように）水平分割が適用され、次いで、リーフノードが（水平方向に）完全にピクチャ内に収まるまで（右側境界ケースについて記載されたように）垂直分割が適用される。
解決策2：
境界ケースの定義はそのまま維持される。強制QTがMinQTSizeによって制約される場合（MinQTSize以下の現在ブロックサイズ）、水平強制BTを使用して下部境界と一致させ、下部境界が一致すると、垂直強制BTを使用して右側境界と一致させる。
たとえば、ピクチャのコーナーに位置するブロックの対する強制QTBTの一実施形態を示す図19Aでは、MinQTSizeがコーナーケースの強制QT分割に対して32であるか、または32に制限される場合、強制分割が終了するまで、32×32ブロックの分割後さらなるBT分割が使用される。
図9Bは、本発明の一実施形態による、ピクチャのコーナーにあるか、またはコーナーの中にある境界CTUの例示的な分割のさらなる詳細を示し、CTUは128×128サンプルのサイズを有する。CTUは、最初に、各々が64×64サンプルのサイズを有する4つの正方形ブロックに分割された四分木である。これらのブロックのうち、左上のブロック910のみが境界ブロックであり、他の3つはピクチャの外側（完全に外側）に位置し、それ以上処理されない。ブロック910は、四分木分割を使用して、各々が32×32サンプルのサイズを有する4つの正方形ブロック920、930、940、および950にさらに分割される。ブロック920はピクチャの内側に位置し、ブロック930、940、および950はこの場合も境界ブロックを形成する。これらのブロック930、940、および950のサイズは、32であるMinQTSizeよりも大きくないので、ブロック930、940、および950に強制バイナリ分割が適用される。
ブロック930は、右側境界上に位置し、リーフノードがピクチャ内に収まる、たとえば、（ここでは2つの垂直バイナリ分割の後）ブロック932がピクチャの右側境界に位置するまで、再帰的な垂直強制バイナリ分割を使用して分割される。
ブロック940は、下部境界上に位置し、リーフノードがピクチャ内に収まる、たとえば、（ここでは2つの水平バイナリ分割の後）ブロック942がピクチャの右側境界に位置するまで、再帰的な水平強制バイナリ分割を使用して分割される。
ブロック950は、コーナー境界に位置し、最初に、サブパーティションまたはブロック、ここではブロック952が（ここでは2つの水平バイナリ分割の後に）ピクチャの下部境界に位置するまで、再帰的な水平強制バイナリ分割を使用して分割され、次いで、リーフノードもしくはブロック、たとえばブロック954が（ここでは2つの垂直バイナリ分割の後に）ピクチャの右側境界に位置するまで、またはリーフノードがピクチャ内に位置するまで、垂直強制境界分割によってサブパーティションを再帰的に分割する。
上記の手法は復号と符号化の両方に適用されてよい。復号の場合、MinQTSizeはSPSを介して受信されてよい。符号化の場合、MinQTSizeはSPSを介して送信されてよい。実施形態は、図18または図20に示された境界定義、または他の境界定義を使用することができる。
本開示のさらなる実施形態が以下に提供される。以下のセクションで使用される番号付けは、必ずしも前のセクションで使用された番号付けに準拠しているとは限らないことに留意されたい。
実施形態1：
ピクチャの現在ブロックが境界ブロックであるかどうかを判定するステップと、
現在ブロックが境界ブロックである場合、現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きいかどうかを判定するステップと、
現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きくない場合、現在ブロックに強制二分木分割を適用するステップと
を含む、分割方法。
実施形態2：強制二分木分割が、現在ブロックがピクチャの下部境界に位置する場合の再帰的な水平強制バイナリ分割であるか、または現在ブロックがピクチャの右側境界に位置する場合の再帰的な垂直強制境界分割である、実施形態1の分割方法。
実施形態3：強制バイナリ分割が、現在ブロックのサブパーティションがピクチャの下部境界にそのまま位置するまで水平強制境界分割によって現在ブロックを再帰的に分割することと、リーフノードがピクチャの右側境界に完全にそのまま位置するまで垂直強制境界分割によってサブパーティションを再帰的に分割することとを含む、実施形態1または2の分割方法。
実施形態4：最小許容四分木リーフノードサイズが、非境界ブロックの分割を制御するためにも適用される最小許容四分木リーフノードサイズである、実施形態1から3のいずれかの分割方法。
実施形態5：実施形態1から4のいずれかの分割方法に従ってブロックを分割することによってブロックを復号するための復号方法。
実施形態6：最小許容四分木リーフノードサイズがSPSを介して受信される、実施形態5の復号方法。
実施形態7：実施形態1から4のいずれかの分割方法に従ってブロックを分割することによってブロックを符号化するための符号化方法。
実施形態8：最小許容四分木リーフノードサイズがSPSを介して送信される、実施形態7の符号化方法。
実施形態9：実施形態5または6の方法のいずれか1つを実行するように構成された論理回路を備える、復号デバイス。
実施形態10：実施形態7または8の方法のいずれか1つを実行するように構成された論理回路を備える、符号化デバイス。
実施形態11：プロセッサによって実行されると、実施形態1から8による方法のいずれかをプロセッサに実行させる命令を記憶するための非一時的記憶媒体。
1つまたは複数の例では、記載された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せに実装されてよい。ソフトウェアに実装される場合、機能は、コンピュータ可読媒体上に1つまたは複数の命令またはコードとして記憶または送信され、ハードウェアベースの処理ユニットによって実行されてよい。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含んでよい。このように、コンピュータ可読媒体は、一般に、（1）非一時的である有形コンピュータ可読記憶媒体、または（2）信号もしくは搬送波などの通信媒体に対応してよい。データ記憶媒体は、本開示に記載された技法の実装のための命令、コード、またはデータ構造を検索するために、1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスすることができる任意の利用可能な媒体であってよい。コンピュータプログラム製品はコンピュータ可読媒体を含んでもよい。
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、電気的消去可能プログラマブル読取り専用メモリ（EEPROM）、CD－ROMもしくは他の光ディスクストレージ、磁気ディスクストレージ、他の磁気ストレージデバイス、フラッシュメモリ、または命令もしくはデータ構造の形式で所望のプログラムコードを記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の媒体を含むことができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者線（DSL）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、Webサイト、サーバ、または他のリモートソースから命令が送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まず、代わりに、非一時的な有形記憶媒体を対象とすることを理解されたい。本明細書で使用されるディスク（disk）およびディスク（disc）には、コンパクトディスク（disc）（CD）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（DVD）、フロッピーディスク（disk）、およびブルーレイディスク（disc）が含まれ、ディスク（disk）は通常磁気的にデータを再生し、ディスク（disc）はレーザーで光学的にデータを再生する。上記の組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。
命令は、1つまたは複数のデジタルシグナルプロセッサ（DSP）、汎用マイクロプロセッサ、特定用途向け集積回路（ASIC）、フィールドプログラマブルロジックアレイ（FPGA）、または他の同等の統合されるかもしくは個別の論理回路などの、1つまたは複数のプロセッサによって実行されてよい。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造のいずれか、または本明細書に記載された技法の実装に適した任意の他の構造を指す場合がある。加えて、いくつかの態様では、本明細書に記載された機能は、符号化および復号のために構成されるか、または複合コーデックに組み込まれた専用のハードウェアモジュールおよび／またはソフトウェアモジュール内で提供されてよい。また、これらの技法は、1つまたは複数の回路または論理要素に完全に実装することができる。
本開示の技法は、ワイヤレスハンドセット、集積回路（IC）、またはICのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置に実装されてよい。開示された技法を実行するように構成されたデバイスの機能的態様を強調するために、様々な構成要素、モジュール、またはユニットが本開示に記載されるが、必ずしも異なるハードウェアユニットによる実現を必要としない。むしろ、上述されたように、様々なユニットは、コーデックハードウェアユニット内で組み合わされるか、または適切なソフトウェアおよび／もしくはファームウェアと連携して、上述された1つもしくは複数のプロセッサを含む、相互運用可能なハードウェアユニットの集合によって提供されてよい。
装置は、メモリ要素と、メモリ要素に結合され、ピクチャの現在ブロックが境界ブロックであるかどうかを判定し、現在ブロックが境界ブロックであるとき、現在ブロックのサイズが最小許容四分木（QT）リーフノードサイズ（MinQTSize）よりも大きいかどうかを判定し、現在ブロックのサイズがMinQTSizeよりも大きくないとき、現在ブロックに強制二分木（BT）分割を適用するように構成されたプロセッサ要素とを備える。
本開示においていくつかの実施形態が提供されているが、開示されたシステムおよび方法は、本開示の趣旨または範囲から逸脱することなく、多くの他の特定の形態で具現化されてよいことを理解されたい。本例は、限定ではなく例示と見なされるべきであり、その意図は、本明細書で与えられた詳細に限定されるものではない。たとえば、様々な要素または構成要素は別のシステム内で結合または統合されてよく、いくつかの機能は省略されてもよく、実装されなくてもよい。
加えて、様々な実施形態において別個または単独として記載および図示された技法、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技法、または方法と結合または統合されてよい。互いに結合されるかまたは直接結合されるかまたは通信するものとして図示または説明された他の項目は、電気的か、機械的か、またはそれ以外かにかかわらず、何らかのインターフェース、デバイス、または中間構成要素を介して間接的に結合されるかまたは通信してもよい。変更、置換、および改変の他の例は、当業者によって確認可能であり、本明細書に開示された趣旨および範囲から逸脱することなく行うことができる。
本出願（または本開示）の実施形態は、符号化および復号のための装置および方法を提供する。
第1の態様は、ピクチャの現在ブロックが境界ブロックであるかどうか、および現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きいかどうかを判定するステップと、現在ブロックが境界ブロックであり、現在ブロックのサイズが最小許容四分木リーフノードサイズ（MinQTSize）よりも大きくない場合、現在ブロックに強制二分木（BT）分割を適用するステップとを含む、分割方法に関する。
そのような第1の態様による方法の第1の実装形態では、強制二分木分割は、現在ブロックがピクチャの下部境界に位置するケースの再帰的な水平強制バイナリ分割であるか、または現在ブロックがピクチャの右側境界に位置するケースの再帰的な垂直強制境界分割である。
そのような第1の態様または第1の態様の任意の先行する実装形態による方法の第2の実装形態では、強制二分木分割は、リーフノードブロックがピクチャ内に収まるまで継続される。
そのような第1の態様または第1の態様の任意の先行する実装形態による方法の第3の実装形態では、強制バイナリ分割は、現在ブロックのサブパーティションがピクチャの下部境界に位置するまで水平強制境界分割によって現在ブロックを再帰的に分割することと、リーフノードがピクチャの右側境界に完全に位置するまで垂直強制境界分割によってサブパーティションを再帰的に分割することとを含む。
そのような第1の態様または第1の態様の任意の先行する実装形態による方法の第4の実装形態では、強制BT分割は、現在ブロックのサブパーティションが下部境界に位置するまで垂直強制境界分割によって現在ブロックを再帰的に分割することと、リーフノードが右側境界に完全に位置するまで水平強制境界分割によってサブパーティションを再帰的に分割することとを含む。
そのような第1の態様または第1の態様の任意の先行する実装形態による方法の第5の実装形態では、方法は、非境界ブロックの分割を制御するために最小許容四分木リーフノードサイズを適用するステップをさらに含む。
そのような第1の態様または第1の態様の任意の先行する実施形態による方法の第6の実施形態では、境界ブロックは、ピクチャの完全に内側にはなく、ピクチャの完全に外側にはないブロックである。
第2の態様は、そのような第1の態様または第1の態様の任意の先行する実装形態によりブロックを分割することによってブロックを復号するための復号方法に関する。
そのような第2の態様による方法の第1の実装形態では、方法は、シーケンスパラメータセット（SPS）を介して最小許容四分木リーフノードサイズを受信するステップをさらに含む。
第3の態様は、そのような第1の態様または第1の態様の任意の先行する実装形態によりブロックを分割することによってブロックを符号化するための符号化方法に関する。
そのような第3の態様による方法の第1の実装形態では、方法は、シーケンスパラメータセット（SPS）を介して最小許容四分木リーフノードサイズを送信するステップをさらに含む。
第4の態様は、そのような第1の態様または第1の態様の任意の先行する実装形態の分割方法によりブロックを分割することによってブロックを復号するように構成された論路回路を備える復号デバイスに関する。
そのような第4の態様による復号デバイスの第1の実装形態では、論理回路は、シーケンスパラメータセット（SPS）を介して最小許容四分木リーフノードサイズを受信するようにさらに構成される。
第5の態様は、そのような第1の態様または第1の態様の任意の先行する実装形態の分割方法によりブロックを分割することによってブロックを符号化するように構成された論路回路を備える符号化デバイスに関する。
そのような第5の態様による復号デバイスの第1の実装形態では、論理回路は、シーケンスパラメータセット（SPS）を介して最小許容四分木リーフノードサイズを送信するようにさらに構成される。
第6の態様は、プロセッサによって実行されると、そのような第1、第2、もしくは第3の態様のいずれか、または第1、第2、もしくは第3の態様の任意の先行する実装形態をプロセッサに実行させる命令を記憶するための非一時的記憶媒体に関する。
第7の態様は、ピクチャの現在ブロックが境界ブロックであり、現在ブロックのサイズが最小許容四分木（QT）リーフノードサイズ（MinQTSize）以下であることの判定を行うステップと、判定に応答して、現在ブロックに強制二分木（BT）分割を適用するステップとを含む方法に関する。
そのような第7の態様による方法の第1の実装形態では、現在ブロックはピクチャの下部境界に位置し、強制BT分割は再帰的な水平強制BT分割である。
そのような第7の態様または第7の態様の任意の先行する実装形態による方法の第2の実装形態では、現在ブロックはピクチャの右側境界に位置し、強制BT分割は再帰的な垂直強制BT分割である。
そのような第7の態様または第7の態様の任意の先行する実装形態による方法の第3の実装形態では、強制BT分割は、現在ブロックのサブパーティションが下部境界に位置するまで水平強制境界分割によって現在ブロックを再帰的に分割することと、リーフノードが右側境界に完全に位置するまで垂直強制境界分割によってサブパーティションを再帰的に分割することとを含む。
そのような第7の態様または第7の態様の任意の先行する実装形態による方法の第4の実装形態では、強制BT分割は、現在ブロックのサブパーティションが下部境界に位置するまで垂直強制境界分割によって現在ブロックを再帰的に分割することと、リーフノードが右側境界に完全に位置するまで水平強制境界分割によってサブパーティションを再帰的に分割することとを含む。
そのような第7の態様または第7の態様の任意の先行する実装形態による方法の第5の実装形態では、方法は、非境界ブロックの分割を制御するためにMinQTSizeを適用するステップをさらに含む。
そのような第7の態様または第7の態様の任意の先行する実装形態による方法の第6の実装形態では、方法は、シーケンスパラメータセット（SPS）を介してMinQTSizeを受信するステップをさらに含む。
そのような第7の態様または第7の態様の任意の先行する実装形態による方法の第7の実装形態では、方法は、シーケンスパラメータセット（SPS）を介してMinQTSizeを送信するステップをさらに含む。
第8の態様は、メモリと、メモリに結合され、ピクチャの現在ブロックが境界ブロックであるかどうかを判定し、現在ブロックが境界ブロックであるとき、現在ブロックのサイズが最小許容四分木（QT）リーフノードサイズ（MinQTSize）よりも大きいかどうかを判定し、現在ブロックのサイズがMinQTSizeよりも大きくないとき、現在ブロックに強制二分木（BT）分割を適用するように構成されたプロセッサとを備える、装置に関する。
そのような第8の態様による装置の第1の実装形態では、強制BT分割は、現在ブロックがピクチャの下部境界に位置するときの再帰的な水平強制BT分割であるか、または現在ブロックがピクチャの右側境界に位置するときの再帰的な垂直強制BT分割である。
そのような第8の態様または第8の態様の任意の先行する実装形態による装置の第2の実装形態では、強制BT分割は、現在ブロックのサブパーティションが下部境界に位置するまで水平強制境界分割によって現在ブロックを再帰的に分割することと、リーフノードが右側境界に完全に位置するまで垂直強制境界分割によってサブパーティションを再帰的に分割することとを含む。
そのような第8の態様または第8の態様の任意の先行する実装形態による装置の第3の実装形態では、強制BT分割は、現在ブロックのサブパーティションが下部境界に位置するまで垂直強制境界分割によって現在ブロックを再帰的に分割することと、リーフノードが右側境界に完全に位置するまで水平強制境界分割によってサブパーティションを再帰的に分割することとを含む。
そのような第8の態様または第8の態様の任意の先行する実装形態による装置の第4の実装形態では、プロセッサは、非境界ブロックの分割を制御するためにMinQTSizeを適用するようにさらに構成される。
そのような第8の態様または第8の態様の任意の先行する実装形態による装置の第5の実装形態では、装置は、プロセッサに結合され、シーケンスパラメータセット（SPS）を介してMinQTSizeを受信するように構成された受信機をさらに備える。
そのような第8の態様または第8の態様の任意の先行する実装形態による装置の第6の実装形態では、装置は、プロセッサに結合され、シーケンスパラメータセット（SPS）を介してMinQTSizeを受信するように構成された送信機をさらに備える。
第9の態様は、プロセッサによって実行されると、ピクチャの現在ブロックが境界ブロックであるかどうかを判定し、現在ブロックが境界ブロックであるとき、現在ブロックのサイズが最小許容四分木（QT）リーフノードサイズ（MinQTSize）よりも大きいかどうかを判定し、現在ブロック0のサイズがMinQTSizeよりも大きくないとき、現在ブロックに強制二分木（BT）分割を適用することを装置に行わせる、非一時的媒体に記憶されたコンピュータ実行可能命令を含む、コンピュータプログラム製品に関する。
そのような第8の態様による装置の第1の実装形態では、強制BT分割は、現在ブロックがピクチャの下部境界に位置するときの再帰的な水平強制BT分割であるか、または現在ブロックがピクチャの右側境界に位置するときの再帰的な垂直強制BT分割である。
そのような第9の態様または第9の態様の任意の先行する実装形態による装置の第2の実装形態では、強制BT分割は、現在ブロックのサブパーティションが下部境界に位置するまで水平強制境界分割によって現在ブロックを再帰的に分割することと、リーフノードが右側境界に完全に位置するまで垂直強制境界分割によってサブパーティションを再帰的に分割することとを含む。
そのような第9の態様または第9の態様の任意の先行する実装形態による装置の第3の実装形態では、強制BT分割は、現在ブロックのサブパーティションが下部境界に位置するまで垂直強制境界分割によって現在ブロックを再帰的に分割することと、リーフノードが右側境界に完全に位置するまで水平強制境界分割によってサブパーティションを再帰的に分割することとを含む。
そのような第9の態様または第9の態様の任意の先行する実装形態による装置の第4の実装形態では、命令は、装置に非境界ブロックの分割を制御するためにMinQTSizeをさらに適用させる。
そのような第9の態様または第9の態様の任意の先行する実装形態による装置の第5の実装形態では、命令は、装置にシーケンスパラメータセット（SPS）を介してMinQTSizeをさらに受信させる。
そのような第9の態様または第9の態様の任意の先行する実装形態による装置の第6の実装形態では、命令は、装置にシーケンスパラメータセット（SPS）を介してMinQTSizeをさらに送信させる。
非境界ブロックおよび境界ブロックに対する分割制約間の関係に関する実施形態
次世代ビデオコーディング（NGVC）は、CU、PU、およびTUの概念の分離を取り除き、CU分割形状の柔軟性をサポートする。CUのサイズは、コーディングノードのサイズに対応し、形状が正方形または非正方形（たとえば、長方形）であってよい。
J．Anらの、「Block partitioning structure for next generation video coding」、国際電気通信連合、COM16－C966、2015年9月（以下、「VCEG提案COM16－C966」）では、四分木－二分木（QTBT）分割技法が、HEVCを超える将来のビデオコーディング規格のために提案された。シミュレーションは、提案されたQTBT構造が使用されたHEVC内の四分木構造よりも効率的であることを示している。HEVCでは、動き補償のメモリアクセスを削減するために、小さいブロックのためのインター予測が制限され、4×4ブロックのためのインター予測はサポートされない。JEMのQTBTでは、これらの制限が削除されている。
QTBTでは、CUは正方形または長方形のいずれかの形状をもつことができる。図21に示されたように、コーディングツリーユニット（CTU）は、最初に四分木構造によって分割される。四分木リーフノードは、二分木構造によってさらに分割することができる。二分木分割には、対称水平分割および対称垂直分割の2つの分割タイプがある。いずれの場合も、ノードを水平方向または垂直方向のいずれかに中央で分割することにより、ノードが分割される。二分木リーフノードはコーディングユニット（CU）と呼ばれ、そのセグメント化は、それ以上分割することなく、予測処理および変換処理に使用される。これは、CU、PU、およびTUがQTBTコーディングブロック構造で同じブロックサイズを有することを意味する。CUは、時には異なる色成分のコーディングブロック（CB）から構成され、たとえば、4：2：0クロマフォーマットのPスライスおよびBスライスの場合、1つのCUは1つのルーマCBおよび2つのクロマCBを含み、時には単一の成分のCBから構成され、たとえば、Iスライスの場合、1つのCUは1つのルーマCBのみまたは2つのクロマCBだけを含む。
QTBT分割方式のために以下のパラメータが定義される。
－CTUサイズ：四分木のルートノードサイズ、HEVCと同じ概念
－MinQTSize：最小許容四分木リーフノードサイズ
－MaxBTSize：最大許容二分木ルートノードサイズ
－MaxBTDepth：最大許容二分木深度
－MinBTSize：最小許容二分木リーフノードサイズ
QTBT分割構造の一例では、四分木ノードがMinQTSize以下のサイズをもつ場合、それ以上の四分木は考慮されない。サイズ（MinQTSize）がMaxBTSizeを超えたときから、それは二分木によってそれ以上分割されない。そうでない場合、リーフ四分木ノードは二分木によってさらに分割される可能性がある。したがって、四分木リーフノードは二分木用のルートノードでもあり、それは0（ゼロ）としての二分木深度を有する。二分木深度がMaxBTDepth（すなわち、4）に達すると、それ以上の分割は考慮されない。二分木ノードがMinBTSize（すなわち、4）に等しい幅をもつとき、それ以上の水平分割は考慮されない。同様に、二分木ノードがMinBTSizeに等しい高さをもつとき、それ以上の垂直分割は考慮されない。二分木のリーフノードは、さらなる分割なしに、予測および変換処理によってさらに処理される。JEMでは、最大CTUサイズは256×256ルーマサンプルである。二分木のリーフノードは、さらなる分割なしに、（たとえば、予測プロセスおよび変換プロセスを実行することによって）さらに処理されてよい。
図21は、QTBT分割技法を使用して分割されたブロック30（たとえば、CTB）の一例を示す。図21に示されたように、QTBT分割技法を使用して、ブロックの各々は、各ブロックの中心を通って対称的に分割される。図22は、図21のブロック分割に対応するツリー構造を示す。図22の実線は四分木分割を示し、点線は二分木分割を示す。一例では、二分木の各分割（すなわち、非リーフ）ノードでは、実行された分割のタイプ（たとえば、水平または垂直）を示すために構文要素（たとえば、フラグ）が通知され、0は水平分割を示し、1は垂直分割を示す。四分木分割の場合、四分木分割は常にブロックを水平方向と垂直方向に同じサイズの4つのサブブロックに分割するので、分割タイプを示す必要がない。
図22に示されたように、ノード50において、（ルート50に対応する）ブロック30は、QT分割を使用して、図21に示された4つのブロック31、32、33、および34に分割される。ブロック34はそれ以上分割されず、したがってリーフノードである。ノード52において、ブロック31はBT分割を使用して2つのブロックにさらに分割される。図22に示されたように、ノード52は垂直分割を示す1でマークされている。したがって、ノード52における分割は、ブロック37、ならびにブロック35と36の両方を含むブロックをもたらす。ブロック35および36は、ノード54におけるさらなる垂直分割によって作成される。ノード56において、ブロック32はBT分割を使用して2つのブロック38および39にさらに分割される。
ノード58において、ブロック33はQT分割を使用して4つの等しいサイズのブロックに分割される。ブロック43および44はこのQT分割から作成され、それ以上分割されない。ノード60において、左上のブロックは最初に垂直二分木分割を使用して分割され、ブロック40および右側の垂直ブロックをもたらす。次いで、右側の垂直ブロックは水平二分木分割を使用してブロック41および42に分割される。ノード58における四分木分割から作成された右下のブロックは、ノード62において水平二分木分割を使用してブロック45および46に分割される。図22に示されたように、ノード62は水平分割を示す0でマークされている。
QTBTに加えて、QTBTベースのCU構造内のBTを置き換えるためにマルチタイプツリー（MTT）という名前のブロック分割構造が提案され、すなわち、CTUは最初にQT分割によって分割されてCTUのブロックを取得し、次いでブロックは2番目にMTT分割によって分割されてよい。
MTT分割構造は、やはり再帰的なツリー構造である。MTTでは、複数の異なる分割構造（たとえば、2つ以上）が使用される。たとえば、MTT技法によれば、ツリー構造の各深度で、2つ以上の異なるパーティション構造がツリー構造のそれぞれの非リーフノードごとに使用されてよい。ツリー構造内のノードの深度は、ノードからツリー構造のルートまでの経路の長さ（たとえば、分割の数）を指してよい。
MTTでは、BT分割および三分木（TT）分割の2つの分割タイプがある。分割タイプは、BT分割およびTT分割から選択することができる。TT分割構造がブロックを真っ二つに分割しないという点で、TT分割構造はQT構造またはBT構造とは異なる。ブロックの中央領域は、同じサブブロック内に一緒に残る。4つのブロックを生成するQT、または2つのブロックを生成する二分木とは異なり、TT分割構造による分割は3つのブロックを生成する。TT分割構造による例示的な分割タイプには、対称分割タイプ（水平と垂直の両方）、ならびに非対称分割タイプ（水平と垂直の両方）が含まれる。さらに、TT分割構造による対称分割タイプは、不均等／不均一または均等／均一であってよい。TT分割構造による非対称分割タイプは、不均等／不均一である。一例では、TT分割構造は、以下の分割タイプ：水平均等／均一対称三分木分割タイプ、垂直均等／均一対称三分木分割タイプ、水平不均等／不均一対称三分木分割タイプ、垂直不均等／不均一対称三分木分割タイプ、水平不均等／不均一非対称三分木分割タイプ、または垂直不均等／不均一非対称三分木分割タイプのうちの少なくとも1つを含んでよい。
一般に、不均等／不均一対称三分木分割タイプは、ブロックの中心線に対して対称であるが、結果として生じる3つのブロックのうちの少なくとも1つが他の2つと同じサイズではない分割タイプである。1つの好ましい例は、サイドブロックがブロックのサイズの1／4であり、中央ブロックがブロックのサイズの1／2である場合である。均等／均一対称三分木分割タイプは、ブロックの中心線に対して対称であり、結果として生じるブロックがすべて同じサイズである分割タイプである。そのような分割は、垂直分割または水平分割に応じて、ブロックの高さまたは幅が3の倍数である場合に可能である。不均等／不均一非対称三分木分割タイプは、ブロックの中心線に対して対称ではなく、結果として生じるブロックのうちの少なくとも1つが他の2つと同じサイズではない分割タイプである。
図23は、オプションの例示的な水平三分木分割タイプを示す概念図である。図24は、オプションの例示的な垂直三分木分割タイプを示す概念図である。図23と図24の両方では、hはルーマサンプルまたはクロマサンプル内のブロックの高さを表し、wはルーマサンプルまたはクロマサンプル内のブロックの幅を表す。ブロックのそれぞれの中心線はブロックの境界を表さない（すなわち、三分木分割は中心線を介してブロックを分割しない）ことに留意されたい。むしろ、中心線は、特定の分割タイプが元のブロックの中心線に対して対称であるか非対称であるかを描写するために使用される。中心線も分割の方向に沿っている。
図23に示されたように、ブロック71は水平均等／均一対称分割タイプで分割されている。水平均等／均一対称分割タイプは、ブロック71の中心線に対して対称の上半分および下半分を生成する。水平均等／均一対称分割タイプは、各々がh／3の高さおよびwの幅を有する、同じサイズの3つのサブブロックを生成する。水平均等／均一対称分割タイプは、ブロック71の高さが3で割り切れるときに可能である。
ブロック73は、水平不均等／不均一対称分割タイプで分割されている。水平不均等／不均一対称分割タイプは、ブロック73の中心線に対して対称の上半分および下半分を生成する。水平不均等／不均一対称分割タイプは、同じサイズの2つのブロック（たとえば、h／4の高さを有する上部ブロックおよび下部ブロック）、ならびに異なるサイズの中央ブロック（たとえば、h／2の高さを有する中央ブロック）を生成する。一例では、水平不均等／不均一対称分割タイプによれば、中央ブロックの面積は、上部ブロックと下部ブロックを合わせた面積に等しい。いくつかの例では、水平不均等／不均一対称分割タイプは、2の累乗（たとえば、2、4、8、16、32など）の高さを有するブロックに好ましい可能性がある。
ブロック75は、水平不均等／不均一非対称分割タイプで分割されている。水平不均等／不均一非対称分割タイプは、ブロック75の中心線に対して対称の上半分および下半分を生成しない（すなわち、上半分と下半分は非対称である）。図23の例では、水平不均等／不均一非対称分割タイプは、h／4の高さを有する上部ブロック、3h／8の高さを有する中央ブロック、および3h／8の高さを有する下部ブロックを生成する。当然、他の非対称配置が使用されてよい。
図24に示されたように、ブロック81は垂直均等／均一対称分割タイプで分割されている。垂直均等／均一対称分割タイプは、ブロック81の中心線に対して対称の左半分および右半分を生成する。垂直均等／均一対称分割タイプは、各々がw／3の幅およびhの高さを有する、同じサイズの3つのサブブロックを生成する。垂直均等／均一対称分割タイプは、ブロック81の幅が3で割り切れるときに可能である。
ブロック83は、垂直不均等／不均一対称分割タイプで分割されている。垂直不均等／不均一対称分割タイプは、ブロック83の中心線に対して対称の左半分および右半分を生成する。垂直不均等／不均一対称分割タイプは、83の中心線に対して対称の左半分および右半分を生成する。垂直不均等／不均一対称分割タイプは、同じサイズの2つのブロック（たとえば、w／4の幅を有する左側ブロックおよび右側ブロック）、ならびに異なるサイズの中央ブロック（たとえば、w／2の幅を有する中央ブロック）を生成する。一例では、垂直不均等／不均一対称分割タイプによれば、中央ブロックの面積は、左側ブロックと右側ブロックを合わせた面積に等しい。いくつかの例では、垂直不均等／不均一対称分割タイプは、2の累乗（たとえば、2、4、8、16、32など）の幅を有するブロックに好ましい可能性がある。
ブロック85は、垂直不均等／不均一非対称分割タイプで分割されている。垂直不均等／不均一非対称分割タイプは、ブロック85の中心線に対して対称の左半分および右半分を生成しない（すなわち、左半分と右半分は非対称である）。図24の例では、垂直不均等／不均一非対称分割タイプは、w／4の幅を有する左側ブロック、3w／8の幅を有する中央ブロック、および3w／8の幅を有する右側ブロックを生成する。当然、他の非対称配置が使用されてよい。
上記で定義されたQTBT用のパラメータに加えて（またはそれらの代わりに）、MTT分割方式のために以下のパラメータが定義される。
－MaxBTSize：最大許容二分木ルートノードサイズ
－MinBtSize：最小許容二分木ルートノードサイズ
－MaxMttDepth：最大マルチタイプツリー深度
－MaxMttDepthオフセット：最大マルチタイプツリー深度オフセット
－MaxTtSize：最大許容三分木ルートノードサイズ
－MinTtSize：最小許容三分木ルートノードサイズ
－MinCbSize：最小許容コーディングブロックサイズ
本開示の実施形態は、本出願の実施形態による、図12のビデオエンコーダ20または図13のビデオデコーダ30などのビデオエンコーダまたはビデオデコーダによって実装されてよい。分割ユニットを含む、ビデオエンコーダ20またはビデオデコーダ30の1つまたは複数の構造要素は、本開示の実施形態の技法を実行するように構成されてよい。
本開示の一実施形態では：
JVET－K1001－v4では、log2＿ctu＿size＿minus2、log2＿min＿qt＿size＿intra＿slices＿minus2、およびlog2＿min＿qt＿size＿inter＿slices＿minus2が、（構文要素として）SPS内で通知される。
パラメータlog2＿ctu＿size＿minus2プラス2は、各CTUのルーマコーディングツリーブロックサイズを指定する。詳細には、
CtbLog2SizeY＝log2＿ctu＿size＿minus2＋2 （7－5）
CtbSizeY＝1＜＜CtbLog2SizeY （7－6）
である。
言い換えれば、CtbLog2SizeYは、ルーマ（Y）のためのコーディングツリーブロック（CTB）サイズに対応するCTUサイズCtbSizeYのlog2値を指定する。
さらなる設定は以下のように提供される。
MinCbLog2SizeY＝2 （7－7）
MinCbSizeY＝1＜＜MinCbLog2SizeY （7－8）
MinTbSizeY＝4 （7－9）
MaxTbSizeY＝64 （7－10）
パラメータlog2＿min＿qt＿size＿intra＿slices＿minus2プラス2は、slice＿typeが2（I）に等しいスライス、すなわちイントラスライス内のCTUの四分木分割から生じるリーフブロックの最小ルーマサイズを指定する。log2＿min＿qt＿size＿intra＿slices＿minus2の値は、両端を含む0～CtbLog2SizeY－2の範囲でなければならない。
MinQtLog2SizeIntraY＝log2＿min＿qt＿size＿intra＿slices＿minus2＋2（7－22）
パラメータlog2＿min＿qt＿size＿inter＿slices＿minus2プラス2は、slice＿typeが0（B）または1（P）に等しいスライス、すなわちインタースライス内のCTUの四分木分割から生じるリーフブロックの最小ルーマサイズを指定する。log2＿min＿qt＿size＿inter＿slices＿minus2の値は、両端を含む0～CtbLog2SizeY－2の範囲でなければならない。
MinQtLog2SizeInterY＝log2＿min＿qt＿size＿inter＿slices＿minus2＋2（7－23）
MinQtSizeYは（7－30）で定義され、これはルーマサンプル内の最小許容四分木分割サイズを意味する。コーディングブロックサイズがMinQtSizeY以下である場合、四分木分割は許可されない。さらなる設定は以下のように提供される。
MinQtLog2SizeY＝（slice＿type＝＝I）？MinQtLog2SizeIntraY：MinQtLog2SizeInterY （7－25）
MaxBtLog2SizeY＝CtbLog2SizeY－log2＿diff＿ctu＿max＿bt＿size （7－26）
MinBtLog2SizeY＝MinCbLog2SizeY （7－27）
MaxTtLog2SizeY＝（slice＿type＝＝I）？5：6 （7－28）
MinTtLog2SizeY＝MinCbLog2SizeY （7－29）
MinQtSizeY＝1＜＜MinQtLog2SizeY （7－30）
MaxBtSizeY＝1＜＜MaxBtLog2SizeY （7－31）
MinBtSizeY＝1＜＜MinBtLog2SizeY （7－32）
MaxTtSizeY＝1＜＜MaxTtLog2SizeY （7－33）
MinTtSizeY＝1＜＜MinTtLog2SizeY （7－34）
MaxMttDepth＝（slice＿type＝＝I）？max＿mtt＿hierarchy＿depth＿intra＿slices：max＿mtt＿hierarchy＿depth＿inter＿slices （7－35）
パラメータmax＿mtt＿hierarchy＿depth＿intra＿slicesおよびmax＿mtt＿hierarchy＿depth＿inter＿slicesは、それぞれ、イントラスライスおよびインタースライス用のMTTタイプ分割の最大階層深度を表記する。
log2＿min＿qt＿size＿intra＿slices＿minus2およびlog2＿min＿qt＿size＿inter＿slices＿minus2のセマンティクスに基づいて、log2＿min＿qt＿size＿intra＿slices＿minus2およびlog2＿min＿qt＿size＿inter＿slices＿minus2の範囲は、0からCtbLog2SizeY－2までである。
ここで、CtbLog2SizeYはlog2＿ctu＿size＿minus2のセマンティクスで定義され、これは各CTUのルーマコーディングツリーブロックサイズのlog2値を意味し、VTM2．0のCtbLog2SizeYは7に等しい。
（7－22）および（7－23）に基づいて、MinQtLog2SizeIntraYおよびMinQtLog2SizeInterYの範囲は、2からCtbLog2SizeYまでである。
（7－25）に基づいて、MinQtLog2SizeYの範囲は2からCtbLog2SizeYまでである。
（7－30）に基づいて、JVET－K1001－v4では、MinQtSizeYの範囲は（1＜＜2）から（1＜＜CtbLog2SizeY）までであり、VTM2．0では、範囲は（1＜＜2）から（1＜＜7）までであり、これは4から128までに等しい。
JVET－K1001－v4では、log2＿diff＿ctu＿max＿bt＿sizeは、スライスヘッダ内で条件付きで通知される。
パラメータlog2＿diff＿ctu＿max＿bt＿sizeは、バイナリ分割を使用して分割することができるコーディングブロックのルーマCTBサイズと最大ルーマサイズ（幅または高さ）との間の差分を指定する。log2＿diff＿ctu＿max＿bt＿sizeの値は、両端を含む0～CtbLog2SizeY－MinCbLog2SizeYの範囲でなければならない。
log2＿diff＿ctu＿max＿bt＿sizeが存在しない場合、log2＿diff＿ctu＿max＿bt＿sizeの値は2に等しいと推測される。
MinCbLog2SizeYは（7－7）で定義され、これは最小許容コーディングブロックサイズを意味する。
log2＿diff＿ctu＿max＿bt＿sizeのセマンティクスに基づいて、log2＿diff＿ctu＿max＿bt＿sizeの範囲は0からCtbLog2SizeY－MinCbLog2SizeYまでである。
（7－26）に基づいて、MaxBtLog2SizeYの範囲はCtbLog2SizeYからMinCbLog2SizeYまでである。
（7－31）に基づいて、MaxBtSizeYの範囲は（1＜＜CtbLog2SizeY）から（1＜＜MinCbLog2SizeY）までである。
（7－7）に基づいて、JVET－K1001－v4では、MaxBtSizeYの範囲は（1＜＜CtbLog2SizeY）から（1＜＜2）までであり、VTM2．0では、CtbLog2SizeYは7に等しいので、VTM2．0のMaxBtSizeYの範囲は128から4までである。
したがって、MinQtSizeYは、4から（1＜＜CtbLog2SizeY）まで、VTM2．0では4から128までの範囲をもち、MaxBtSizeYは、（1＜＜CtbLog2SizeY）から4まで、VTM2．0では128から4までの範囲をもつ。
したがって、MinQtSizeYがMaxBtSizeYよりも大きい可能性がある。
その上、VVC2．0の現在の境界処理に基づいて、境界に位置するブロックに対してQT分割およびBT分割のみが許可される（TTは許可されず、分割なしは許可されない）。
現在コーディングブロックが境界上に位置し、現在コーディングブロックサイズcbSizeYが条件：
MinQtSizeY＞cbSizeY＞MaxBtSizeY
を満たす場合、現在コーディングブロックに対して可能なQT分割もBT分割も存在しない。したがって、現在ブロックに利用可能な分割モードは存在しない。
実施形態1
境界ケースの問題を含む、上記の問題の解決策（本発明の実施形態）は、より詳細に下記に記載される。
一実施形態によれば、記載された問題を解決するために、MaxBtSizeYの下限は、MaxBtSizeYがMinQtSizeYより小さくないことを確保するために、MinQtSizeYに制限されるべきである。詳細には、MaxBtSizeYの下限はMinQtSizeYに等しい場合があるので、MaxBtSizeYの範囲は（1＜＜CtbLog2SizeY）から（1＜＜MinQtLog2SizeY）までであるべきであり、そのため、MaxBtLog2SizeYの範囲はCtbLog2SizeYからMinQtLog2SizeYまでであるべきであり、そのため、log2＿diff＿ctu＿max＿bt＿sizeの範囲は0からCtbLog2SizeY－MinQtLog2SizeYまでであるべきである。
（ビデオ規格の）ドラフトテキストの対応する変更は、以下の通り、log2＿diff＿ctu＿max＿bt＿sizeのセマンティクス内にある。
log2＿diff＿ctu＿max＿bt＿sizeは、バイナリ分割を使用して分割することができるコーディングブロックのルーマCTBサイズと最大ルーマサイズ（幅または高さ）との間の差分を指定する。log2＿diff＿ctu＿max＿bt＿sizeの値は、両端を含む0～CtbLog2SizeY－MinQtLog2SizeYの範囲でなければならない。そのため、MinQtSizeYについての情報は、MaxBtSizeYの有効性を判断するために使用されてよい。言い換えれば、MaxBtSizeYは、MinQtSizeYについての情報に基づいて決定されてよい。
コーディングデバイス（デコーダまたはエンコーダ）によって実施されるコーディングの対応する方法は、以下の通りであってよい：
ピクチャの現在ブロックが境界ブロックであるかどうかを判定するステップと、
現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きいかどうかを判定するステップと、
現在ブロックが境界ブロックであり、現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きくない場合、現在ブロックにバイナリ分割を適用するステップであって、最小許容四分木リーフノードサイズは最大許容二分木ルートノードサイズよりも大きくない、ステップ。
現在ブロックにバイナリ分割を適用するステップは、現在ブロックに強制バイナリ分割を適用するステップを含んでよい。
現在ブロックは、画像またはコーディングツリーユニット（CTU）を分割することによって取得されてよい。
方法は2つのケースを含んでよい：1）treeTypeがSINGLE＿TREEまたはDUAL＿TREE＿LUMAと等しい。2）treeTypeがDUAL＿TREE＿CHROMAと等しい。ケース1）の場合、現在ブロックはルーマブロックであり、ケース2）の場合、現在ブロックはクロマブロックである。
最大許容二分木ルートノードサイズは、二分木分割を使用して分割することができる、ルーマコーディングルートブロックのルーマサンプル内の最大ルーマサイズであってよい。
最大許容三分木ルートノードサイズは、三分木分割を使用して分割することができる、ルーマコーディングルートブロックのルーマサンプル内の最大ルーマサイズであってよい。
最小許容四分木ルーフノードサイズは、四分木分割から生じるルーマリーフブロックのルーマサンプル内の最小ルーマサイズであってよい。
本明細書では、コーディングは、画像、ビデオ、または動画のコーディングに対応する。
境界ブロックであることは、画像／フレームの境界がブロックを切断するか、または言い換えれば、ブロックが画像／フレームの境界にあることを意味する。上記の実施形態では、現在ブロックが境界ブロックであり（条件1）、そのサイズが最小許容四分木リーフノードサイズよりも大きくない（条件2）場合、現在ブロックにバイナリ分割が適用される。いくつかの実施形態では、バイナリ分割の代わりに三値分割または他の分割が使用される場合があることに留意されたい。その上、いくつかの実施形態では、バイナリ分割は、条件1にかかわらず、条件2の下で適用されてよい。言い換えれば、条件1は判断される必要がない。現在ブロックのサイズが実際には最小許容四分木リーフノードサイズより大きい（すなわち、条件2が満たされない）場合、四分木分割が適用されてよい。
バイナリ分割が境界ブロックに対してのみ使用される（条件1）実施形態が存在することに留意されたい。非境界ブロックの場合、四分木分割が唯一の使用される分割であってよい。画像／フレームの境界でバイナリ（または三値）分割を適用すると、おそらくより効率的な分割、たとえば、水平方向の境界での水平バイナリ／三値分割および垂直方向の境界での垂直バイナリ／三値分割の利点が得られる。
コーディングデバイス（デコーダまたはエンコーダ）によって実施される別の対応するコーディング方法は、以下の通りであってよい：境界ブロックのサイズが最小許容四分木リーフノードサイズよりも大きいかどうかを判定するステップ。境界ブロックのサイズが最小許容四分木リーフノードサイズよりも大きくない場合、（たとえば、標準規格により）最小許容四分木リーフノードサイズは最大許容二分木ルートノードサイズよりも大きくなく、バイナリ分割が境界ブロックに適用される。
場合によっては、境界ブロックはコーナーブロックを含まない場合がある。言い換えれば、垂直方向と水平方向の両方の画像／フレーム境界によって切断されたコーナーブロックは、上記の条件1の目的のための境界ブロックとは見なされない。
実施形態2
（上記の実施形態と組み合わせることができる）本開示の他の実施形態が下記に記載される。
JVET－K1001－v4では、max＿mtt＿hierarchy＿depth＿inter＿slicesおよびmax＿mtt＿hierarchy＿depth＿intra＿slicesはSPS内で通知される。言い換えれば、max＿mtt＿hierarchy＿depth＿inter＿slicesおよびmax＿mtt＿hierarchy＿depth＿intra＿slicesは、それらの値が符号化された画像またはビデオも含むビットストリームに含まれることを意味する構文要素である。
詳細には、max＿mtt＿hierarchy＿depth＿inter＿slicesは、slice＿typeが0（B）または1（P）に等しいスライス内の四分木リーフのマルチタイプツリー分割から生じるコーディングユニットの最大階層深度を指定する。max＿mtt＿hierarchy＿depth＿inter＿slicesの値は、両端を含む0～CtbLog2SizeY－MinTbLog2SizeYの範囲でなければならない。
max＿mtt＿hierarchy＿depth＿intra＿slicesは、slice＿typeが2（I）に等しいスライス内の四分木リーフのマルチタイプツリー分割から生じるコーディングユニットの最大階層深度を指定する。max＿mtt＿hierarchy＿depth＿intra＿slicesの値は、両端を含む0～CtbLog2SizeY－MinTbLog2SizeYの範囲でなければならない。
MinTbSizeYは（7－9）で定義され、4に固定されているので、MinTbLog2SizeY＝log2 MinTbSizeYは2に固定されている。
マルチタイプツリー分割の最大許容深度を意味するMaxMttDepthが定義される。現在のマルチタイプツリー分割の深度がMaxMttDepth以上である場合、マルチタイプツリー分割は許可（適用）されない。
max＿mtt＿hierarchy＿depth＿inter＿slicesおよびmax＿mtt＿hierarchy＿depth＿intra＿slicesのセマンティクスに基づいて、max＿mtt＿hierarchy＿depth＿inter＿slicesおよびmax＿mtt＿hierarchy＿depth＿intra＿slicesの範囲は0からCtbLog2SizeY－MinTbLog2SizeYまでである。
（7－35）に基づいて、MaxMttDepthの範囲は0からCtbLog2SizeY－MinTbLog2SizeYまでである。VTM2．0ではCtbLog2SizeYは7に等しいので、MaxMttDepthの範囲は0から5までである。
したがって、MaxMttDepthの範囲は0からCtbLog2SizeY－MinTbLog2SizeYまでであり、VTM2．0では0から5までである。
VVC2．0の現在の境界処理に基づいて、境界に位置するブロックに対してQT分割およびBT分割のみが許可される（TTは許可されず、分割なしは許可されない）。
上記の最初の問題が解決された場合（MaxBtSizeY＞＝MinQtSizeY）、さらに以下の条件が満たされる。
cbSizeY＜＝MinQtSizeY
MaxMttDepth＝0
境界処理に十分なレベルのBT（一般に、TTを含む任意のMTT）分割は存在しない。
たとえば、MinQtSizeYは16に等しく、MinTbSizeYは4に等しく、MaxMttDepthは0である。
境界ブロックがcbSizeY＝16を有し、親分割がQTであり、このブロックがまだ境界上に位置する場合、現在ブロックのMttdepthがMaxMttDepthに達するので、それ以上の分割を実行することができない。
境界ケースのこの問題の解決策（本発明の一実施形態）：記載された問題を解決するために、MaxMttDepthの下限は、QT分割後、境界ケースの場合に十分なレベルのマルチタイプツリー分割が存在することを確保するために、1に制限されるべきである（言い換えれば、ゼロの値をとることができない）。または、さらに、MaxMttDepthの下限は、QT分割後に、境界ケースと非境界ケースの両方に十分なレベルのマルチタイプツリー分割が存在することを確保するために、（MinQtLog2SizeY－MinTbLog2SizeY）に制限されるべきである。
（規格の）ドラフトテキスト内の対応する変更は、max＿mtt＿hierarchy＿depth＿inter＿slicesおよびmax＿mtt＿hierarchy＿depth＿intra＿slicesのセマンティクス内で以下の通りである。
max＿mtt＿hierarchy＿depth＿inter＿slicesは、slice＿typeが0（B）または1（P）に等しいスライス内の四分木リーフのマルチタイプツリー分割から生じるコーディングユニットの最大階層深度を指定する。max＿mtt＿hierarchy＿depth＿inter＿slicesの値は、両端を含む1～CtbLog2SizeY－MinTbLog2SizeYの範囲でなければならない。
max＿mtt＿hierarchy＿depth＿intra＿slicesは、slice＿typeが2（I）に等しいスライス内の四分木リーフのマルチタイプツリー分割から生じるコーディングユニットの最大階層深度を指定する。max＿mtt＿hierarchy＿depth＿intra＿slicesの値は、両端を含む1～CtbLog2SizeY－MinTbLog2SizeYの範囲でなければならないか、
または
max＿mtt＿hierarchy＿depth＿inter＿slicesは、slice＿typeが0（B）または1（P）に等しいスライス内の四分木リーフのマルチタイプツリー分割から生じるコーディングユニットの最大階層深度を指定する。max＿mtt＿hierarchy＿depth＿inter＿slicesの値は、両端を含むMinQtLog2SizeY－MinTbLog2SizeY～CtbLog2SizeY－MinTbLog2SizeYの範囲でなければならない。
max＿mtt＿hierarchy＿depth＿intra＿slicesは、slice＿typeが2（I）に等しいスライス内の四分木リーフのマルチタイプツリー分割から生じるコーディングユニットの最大階層深度を指定する。max＿mtt＿hierarchy＿depth＿intra＿slicesの値は、両端を含むMinQtLog2SizeY－MinTbLog2SizeY～CtbLog2SizeY－MinTbLog2SizeYの範囲でなければならない。
コーディングデバイス（デコーダまたはエンコーダ）によって実施される対応するコーディング方法は、以下の通りであってよい。
画像をブロックに分割するステップであって、ブロックが境界ブロックを含む、ステップ。最大境界マルチタイプ分割深度を有する境界ブロックにバイナリ分割を適用するステップであって、最大境界マルチタイプ分割深度が少なくとも最大マルチタイプツリー深度と最大マルチタイプツリー深度オフセットの合計であり、最大マルチタイプツリー深度が0より大きい、ステップ。この実施形態は、実施形態1と組み合わされてもよく、実施形態1なしで適用されてもよい。
場合によっては、境界ブロックにバイナリ分割を適用するときに最大マルチタイプツリー深度は0より大きい。
場合によっては、境界ブロックはコーナーブロックを含まない場合がある。
実施形態3
本開示の別の実施形態では：
JVET－K1001－v4では、MinQtSizeY＞MaxBtSizeYおよびMinQtSizeY＞MaxTtSizeYである場合。
cbSize＝MinQtsizeYである場合、利用可能な考えられる分割モードが存在しないので、分割はMinCbSizeYに到達することができない（MinTbSizeYおよびMinCbsizeYは固定され、4に等しい）。
非境界ケースまたは境界ケースのこの問題の解決策：記載された問題を解決するために、MaxBtSizeYの下限は、MaxBtSizeYがMinQtSizeYより小さくないことを確保するために、MinQtSizeYに制限されるべきである。または、MaxTtSizeYの下限は、MaxTtSizeYがMinQtSizeYより小さくないことを確保するために、MinQtSizeYに制限されるべきである。
ドラフトテキスト内の対応する変更は、
log2＿diff＿ctu＿max＿bt＿sizeは、バイナリ分割を使用して分割することができるコーディングブロックのルーマCTBサイズと最大ルーマサイズ（幅または高さ）との間の差分を指定する
セマンティクス内にある。log2＿diff＿ctu＿max＿bt＿sizeの値は、両端を含む0～CtbLog2SizeY－MinQtLog2SizeYの範囲でなければならない。
かつ／または、
log2＿min＿qt＿size＿intra＿slices＿minus2プラス2は、slice＿typeが2（I）に等しいスライス内のCTUの四分木分割から生じるリーフブロックの最小ルーマサイズを指定する。log2＿min＿qt＿size＿intra＿slices＿minus2の値は、両端を含む0～MaxTtLog2SizeY－2の範囲でなければならない。
log2＿min＿qt＿size＿inter＿slices＿minus2プラス2は、slice＿typeが0（B）または1（P）に等しいスライス内のCTUの四分木分割から生じるリーフブロックの最小ルーマサイズを指定する。log2＿min＿qt＿size＿inter＿slices＿minus2の値は、両端を含む0～MaxTtLog2SizeY－2の範囲でなければならない。
コーディングデバイス（デコーダまたはエンコーダ）によって実施される対応するコーディング方法は、以下の通りであってよい。
現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きいかどうかを判定するステップと、現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きくない場合、現在ブロックにマルチタイプツリー分割を適用するステップであって、
最小許容四分木リーフノードサイズは最大許容二分木ルートノードサイズよりも大きくないか、または最小許容四分木リーフノードサイズは最大許容三分木ルートノードサイズよりも大きくない、
ステップ。
場合によっては、最小許容四分木リーフノードサイズは最大許容二分木ルートノードサイズよりも大きくなく、最小許容四分木リーフノードサイズは最大許容三分木ルートノードサイズよりも大きくない。
場合によっては、現在ブロックにマルチタイプツリー分割を適用するステップは、現在ブロックに三値分割を適用するステップ、または現在ブロックにバイナリ分割を適用するステップを含む。
場合によっては、境界ブロックはコーナーブロックを含まない場合がある。
実施形態4
本開示の別の実施形態では：
MaxBtSizeY＞＝MinQtSizeY、MinQtSizeY＞MinTbLog2SizeY、およびMaxMttDepth＜（MinQtLog2SizeY－MinTbLog2SizeY）である場合、
cbSize＝MinQtsizeYである場合、許可される十分なレベルのマルチタイプツリー分割が存在しないので、分割はMinCbSizeYに到達することができない。
非境界ケースまたは境界ケースのこの問題の解決策：記載された問題を解決するために、MaxMttDepthの下限は、QT分割後、境界ケースと非境界ケースの両方に十分なレベルのマルチタイプツリー分割が存在することを確保するために、（MinQtLog2SizeY－MinTbLog2SizeY）に制限されるべきである。
ドラフトテキスト内の対応する変更は、max＿mtt＿hierarchy＿depth＿inter＿slicesおよびmax＿mtt＿hierarchy＿depth＿intra＿slicesのセマンティクス内で以下の通りである。
max＿mtt＿hierarchy＿depth＿inter＿slicesは、slice＿typeが0（B）または1（P）に等しいスライス内の四分木リーフのマルチタイプツリー分割から生じるコーディングユニットの最大階層深度を指定する。max＿mtt＿hierarchy＿depth＿inter＿slicesの値は、両端を含むMinQtLog2SizeY－MinTbLog2SizeY～CtbLog2SizeY－MinTbLog2SizeYの範囲でなければならない。
max＿mtt＿hierarchy＿depth＿intra＿slicesは、slice＿typeが2（I）に等しいスライス内の四分木リーフのマルチタイプツリー分割から生じるコーディングユニットの最大階層深度を指定する。max＿mtt＿hierarchy＿depth＿intra＿slicesの値は、両端を含むMinQtLog2SizeY－MinTbLog2SizeY～CtbLog2SizeY－MinTbLog2SizeYの範囲でなければならない。
コーディングデバイス（デコーダまたはエンコーダ）によって実施される対応するコーディング方法は、以下の通りであってよい。
画像をブロックに分割するステップ。
最終的な最大マルチタイプツリー深度を有するブロックのうちのブロックにマルチタイプツリー分割を適用するステップであって、最終的な最大マルチタイプツリー深度が、少なくとも最大マルチタイプツリー深度と最大マルチタイプツリー深度オフセットの合計であり、最大マルチタイプツリー深度が、最小許容四分木リーフノードサイズのLog2値から最小許容変換ブロックサイズのLog2値の減算以上であるか、または最大のマルチタイプツリー深度が、最小許容四分木リーフノードサイズのLog2値から最小許容コーディングブロックサイズのLog2値の減算以上である、ステップ。
場合によっては、ブロックは非境界ブロックである。
場合によっては、最大マルチタイプツリー深度オフセットは0である。
場合によっては、ブロックは境界ブロックであり、マルチタイプツリー分割はバイナリ分割である。
場合によっては、マルチタイプツリー分割は三値分割である（または三値分割を含む）。
場合によっては、境界ブロックはコーナーブロックを含まない場合がある。
実施形態1～4は、画像／フレームをコーディングユニットに分割するため、かつコーディングユニットをコーディングするために、エンコーダ側で適用することができる。実施形態1～4は、画像／フレームのパーティション、すなわちコーディングユニットを提供するため、かつそれに応じてコーディングユニットを復号する（たとえば、ストリームからコーディングユニットを正確に構文解析し、それらを復号する）ために、デコーダ側で適用することができる。
いくつかの実施形態によれば、1つまたは複数のプロセッサと、プロセッサに結合され、プロセッサによる実行用のプログラミングを記憶する非一時的コンピュータ可読記憶媒体とを備えるデコーダが提供され、プログラミングは、プロセッサによって実行されると、実施形態1～4を参照して上述された方法のいずれかを実行するようにデコーダを構成する。
その上、1つまたは複数のプロセッサと、プロセッサに結合され、プロセッサによる実行用のプログラミングを記憶する非一時的コンピュータ可読記憶媒体とを備えるエンコーダが提供され、プログラミングは、プロセッサによって実行されると、実施形態1～4を参照して上述された方法のいずれかを実行するようにエンコーダを構成する。
要約すると、復号デバイスによって実施されるコーディングのための方法が提供され、方法は、現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きいかどうかを判定するステップと、現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きくない場合、現在ブロックにマルチタイプツリー分割を適用するステップとを含み、最小許容四分木リーフノードサイズは最大許容二分木ルートノードサイズよりも大きくないか、または最小許容四分木リーフノードサイズは最大許容三分木ルートノードサイズよりも大きくない。
この手法により、画像／ビデオブロックの効率的な分割および分割パラメータの通知が容易になる。
その上、いくつかの実装形態では、方法はまた、ピクチャの現在ブロックが境界ブロックであるかどうかを判定するステップを含む。現在ブロックが境界ブロックであり、現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きくない場合、方法はまた、現在ブロックにバイナリ分割を適用するステップを含む。この場合、最小許容四分木リーフノードサイズは、最大許容二分木ルートノードサイズよりも大きくないことに留意されたい。たとえば、現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きくない場合、上記の現在ブロックにマルチタイプツリー分割を適用するステップは、現在ブロックが境界ブロックであり、現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きくない場合、現在ブロックにバイナリ分割を適用するステップを含む。
バイナリ分割の提供は、画像／ビデオフレーム境界にあるブロックにとって、たとえば、境界によって切断されたブロックにとって特に有利であってよい。このように、いくつかの実装形態では、境界ブロックに手段を適用し、残りのブロックに手段を適用しないことが有益な場合がある。しかしながら、本開示はそれに限定されず、上述されたように、より大きい分割深度にバイナリ分割を適用する手法は、非境界ブロックにも適用され、効率的に通知されてよい。
上記の実施形態に加えて、またはそれらの代わりに、最小許容四分木リーフノードサイズは最大許容二分木ルートノードサイズよりも大きくなく、最小許容四分木リーフノードサイズは最大許容三分木ルートノードサイズよりも大きくない。
現在ブロックにマルチタイプツリー分割を適用するステップは、現在ブロックに三値分割を適用するステップ、または現在ブロックにバイナリ分割を適用するステップを含んでよい。しかしながら、本開示はそれによって限定されず、一般に、マルチタイプツリー分割はまた、さらなるまたは他の異なる種類の分割を含んでよい。
方法は、最小許容四分木リーフノードサイズに基づいて最大許容二分木ルートノードサイズを決定するステップをさらに含んでよい。これにより、パラメータの効率的な通知／格納が容易になる。たとえば、最大許容二分木ルートノードサイズは、最小許容四分木リーフノードサイズに等しいと見なされる場合がある。しかしながら、本開示はそれによって限定されず、最大許容二分木ルートノードサイズを導出するために別の関係が想定されてよい。
例示的な実施形態によれば、上記の実施形態に加えて、またはそれらの代わりに、方法は、画像をブロックに分割するステップを含んでよく、ブロックは現在ブロックを含む。現在ブロックにバイナリ分割を適用するステップは、最大境界マルチタイプ分割深度を有する境界ブロックにバイナリ分割を適用するステップを含み、最大境界マルチタイプ分割深度は少なくとも最大マルチタイプツリー深度と最大マルチタイプツリー深度オフセットの合計であり、最大マルチタイプツリー深度は0より大きい。その上、いくつかの実施形態では、境界ブロックにバイナリ分割を適用するときに最大マルチタイプツリー深度は0よりも大きい。
一実施形態によれば、方法は、画像をブロック（現在ブロックを含むブロック）に分割するステップを含む。現在ブロックにマルチタイプツリー分割を適用するステップは、最終的な最大マルチタイプツリー深度を有するブロックのうちの現在ブロックにマルチタイプツリー分割を適用するステップを含み、最終的な最大マルチタイプツリー深度は、少なくとも最大マルチタイプツリー深度と最大マルチタイプツリー深度オフセットの合計であり、最大マルチタイプツリー深度は、最小許容四分木リーフノードサイズのLog2値から最小許容変換ブロックサイズのLog2値の減算以上であるか、または最大のマルチタイプツリー深度は、最小許容四分木リーフノードサイズのLog2値から最小許容コーディングブロックサイズのLog2値の減算以上である。これにより、分割深度が大きい場合でも、さらなる分割が容易になる。
現在ブロックは非境界ブロックであってよい。最大マルチタイプツリー深度オフセットは0であってよい。現在ブロックは、代替または追加として、境界ブロックであってよく、マルチタイプツリー分割はバイナリ分割である。マルチタイプツリー分割は、三値分割であるか、または三値分割を含んでよい。
一実施形態によれば、現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きいかどうかを判定するステップと、現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きくない場合、現在ブロックにマルチタイプツリー分割を適用するステップとを含む符号化方法が提供され、最小許容四分木リーフノードサイズは最大許容二分木ルートノードサイズよりも大きくないか、または最小許容四分木リーフノードサイズは最大許容三分木ルートノードサイズよりも大きくない。
符号化方法は、復号方法に関して記載された上記の規則および制約のいずれかを適用することができる。エンコーダ側とデコーダ側はビットストリームを共有する必要があるからである。詳細には、符号化側は、上述された分割から生じるパーティションを符号化した後にビットストリームを生成し、復号側は、ビットストリームを構文解析し、それに応じて復号されたパーティションを復元する。以下に記載される符号化デバイス（エンコーダ）および復号デバイス（デコーダ）に関連する実施形態についても同様である。
一実施形態によれば、現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きいかどうかを判定し、現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きくない場合、現在ブロックにマルチタイプツリー分割を適用するように構成された回路を備える復号デバイスが提供され、最小許容四分木リーフノードサイズは最大許容二分木ルートノードサイズよりも大きくないか、または最小許容四分木リーフノードサイズは最大許容三分木ルートノードサイズよりも大きくない。現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きいかどうかを判定することは、復号側でビットストリーム内の通知に基づいて実行されてよいことに留意されたい。
また、現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きいかどうかを判定し、現在ブロックのサイズが最小許容四分木リーフノードサイズよりも大きくない場合、現在ブロックにマルチタイプツリー分割を適用するように構成された回路を備える符号化デバイスが提供され、最小許容四分木リーフノードサイズは最大許容二分木ルートノードサイズよりも大きくないか、または最小許容四分木リーフノードサイズは最大許容三分木ルートノードサイズよりも大きくない。
一実施形態によれば、処理回路による実行用のプログラミングを記憶する非一時的コンピュータ可読記憶媒体が提供され、プログラミングは、処理回路によって実行されると、上記の方法のいずれかを実行するように処理回路を構成する。
本開示に記載されたデバイスは、本明細書に記載された様々な動作および方法を実行するための処理回路を備えてよい。処理回路はハードウェアおよびソフトウェアを備えてよい。たとえば、処理回路は、1つまたは複数のプロセッサと、1つまたは複数のプロセッサに接続された不揮発性メモリとを備えてよい。メモリは、1つまたは複数のプロセッサによって実行されると、デバイスに前記動作または方法を実行させるプログラムコードを搬送することができる。
本発明は、例ならびに実装形態として様々な実施形態とともに記載されている。しかしながら、図面、本開示、および独立請求項の研究から、請求された発明を実践する当業者によって、他の変形形態が理解され実施されてよい。特許請求の範囲ならびに説明では、「含む」という単語は他の要素またはステップを排除せず、不定冠詞「a」または「an」は複数を排除しない。単一の要素または他のユニットは、特許請求の範囲に列挙されたいくつかのエンティティまたはアイテムの機能を満たすことができる。特定の手段が相互に異なる従属請求項に列挙されているという単なる事実は、これらの手段の組合せが有利な実装形態に使用できないことを示していない。
以下は、上記実施形態に示された符号化方法ならびに復号方法の用途、およびそれらを使用するシステムの説明である。
図27は、コンテンツ配信サービスを実現するためのコンテンツ供給システム3100を示すブロック図である。このコンテンツ供給システム3100は、キャプチャデバイス3102、端末デバイス3106を含み、場合によっては、ディスプレイ3126を含む。キャプチャデバイス3102は、通信リンク3104を介して端末デバイス3106と通信する。通信リンクは、上述された通信チャネル13を含んでよい。通信リンク3104には、WIFI、イーサネット、ケーブル、ワイヤレス（3G／4G／5G）、USB、またはそれらの任意の種類の組合せなどが含まれるが、それらに限定されない。
キャプチャデバイス3102は、データを生成し、上記の実施形態に示された符号化方法によってデータを符号化することができる。あるいは、キャプチャデバイス3102は、データをストリーミングサーバ（図には示されていない）に配信することができ、サーバは、データを符号化し、符号化データを端末デバイス3106に送信する。キャプチャデバイス3102には、カメラ、スマートフォンもしくはスマートパッド、コンピュータもしくはラップトップ、ビデオ会議システム、PDA、車載デバイス、またはそれらのいずれかの組合せなどが含まれるが、それらに限定されない。たとえば、キャプチャデバイス3102は、上述されたソースデバイス12を含んでよい。データがビデオを含むとき、キャプチャデバイス3102に含まれるビデオエンコーダ20は、実際にビデオ符号化処理を実行することができる。データがオーディオ（すなわち、音声）を含む場合、キャプチャデバイス3102に含まれるオーディオエンコーダは、実際にオーディオ符号化処理を実行することができる。いくつかの実践的なシナリオでは、キャプチャデバイス3102は、それらを一緒に多重化することによって、符号化されたビデオデータおよびオーディオデータを配信する。他の実践的なシナリオでは、たとえばビデオ会議システムでは、符号化されたオーディオデータおよび符号化されたビデオデータは多重化されない。キャプチャデバイス3102は、符号化されたオーディオデータおよび符号化されたビデオデータを別々に端末デバイス3106に配信する。
コンテンツ供給システム3100では、端末デバイス310は符号化データを受信し再生する。端末デバイス3106は、上記の符号化データを復号することが可能なスマートフォンもしくはスマートパッド3108、コンピュータもしくはラップトップ3110、ネットワークビデオレコーダ（NVR）／デジタルビデオレコーダ（DVR）3112、テレビ3114、セットトップボックス（STB）3116、ビデオ会議システム3118、ビデオ監視システム3120、携帯情報端末（PDA）3122、車載デバイス3124、またはそれらのいずれかの組合せなどのデータ受信および復元機能を有するデバイスであってよい。たとえば、端末デバイス3106は、上述された宛先デバイス14を含んでよい。符号化データがビデオを含むとき、ビデオ復号を実行するために、端末デバイスに含まれるビデオデコーダ30が優先される。符号化データがオーディオを含むとき、オーディオ復号処理を実行するために、端末デバイスに含まれるオーディオデコーダが優先される。
そのディスプレイを有する端末デバイス、たとえば、スマートフォンもしくはスマートパッド3108、コンピュータもしくはラップトップ3110、ネットワークビデオレコーダ（NVR）／デジタルビデオレコーダ（DVR）3112、テレビ3114、携帯情報端末（PDA）3122、または車載デバイス3124の場合、端末デバイスは、復号データをそのディスプレイに供給することができる。ディスプレイを備えていない端末デバイス、たとえば、STB3116、ビデオ会議システム3118、またはビデオ監視システム3120の場合、復号データを受信し表示するために、外部ディスプレイ3126がその中で接触される。
このシステム内の各デバイスが符号化または復号を実行するとき、上記の実施形態に示されたように、ピクチャ符号化デバイスまたはピクチャ復号デバイスを使用することができる。
図28は、端末デバイス3106の一例の構造を示す図である。端末デバイス3106がキャプチャデバイス3102からストリームを受信した後、プロトコル進行ユニット3202は、ストリームの送信プロトコルを分析する。プロトコルには、リアルタイムストリーミングプロトコル（RTSP）、ハイパーテキスト転送プロトコル（HTTP）、HTTPライブストリーミングプロトコル（HLS）、MPEG－DASH、リアルタイム転送プロトコル（RTP）、リアルタイムメッセージングプロトコル（RTMP）、またはそれらの任意の種類の組合せなどが含まれるが、それらに限定されない。
プロトコル進行ユニット3202がストリームを処理した後、ストリームファイルが生成される。ファイルは逆多重化ユニット3204に出力される。逆多重化ユニット3204は、多重化されたデータを符号化されたオーディオデータと符号化されたビデオデータに分離することができる。上述されたように、いくつかの実践的なシナリオでは、たとえばビデオ会議システムでは、符号化されたオーディオデータと符号化されたビデオデータは多重化されない。この状況では、符号化データは、逆多重化ユニット3204を介さずに、ビデオデコーダ3206およびオーディオデコーダ3208に送信される。
逆多重化処理を介して、ビデオエレメンタリストリーム（ES）、オーディオES、および場合によっては字幕が生成される。上記の実施形態で説明されたビデオデコーダ30を含むビデオデコーダ3206は、上記の実施形態に示された復号方法によりビデオESを復号してビデオフレームを生成し、このデータを同期ユニット3212に供給する。オーディオデコーダ3208は、オーディオESを復号してオーディオフレームを生成し、このデータを同期ユニット3212に供給する。あるいは、ビデオフレームは、同期ユニット3212にそれを供給する前に、バッファ（図28には示されていない）に格納することができる。同様に、オーディオフレームは、同期ユニット3212にそれを供給する前に、バッファ（図28には示されていない）に格納することができる。
同期ユニット3212は、ビデオフレームとオーディオフレームを同期させ、ビデオ／オーディオディスプレイ3214にビデオ／オーディオを供給する。たとえば、同期ユニット3212は、ビデオ情報およびオーディオ情報の提示を同期させる。情報は、コーディングされたオーディオデータおよびビジュアルデータの提示に関するタイムスタンプ、ならびにデータストリーム自体の配信に関するタイムスタンプを使用して、構文内でコーディングすることができる。
字幕がストリームに含まれている場合、字幕デコーダ3210が字幕を復号し、それをビデオフレームおよびオーディオフレームと同期させ、ビデオ／オーディオ／字幕ディスプレイ3216にビデオ／オーディオ／字幕を供給する。
本発明は上記のシステムに限定されず、上記の実施形態におけるピクチャ符号化デバイスまたはピクチャ復号デバイスのいずれかは、他のシステム、たとえば車載システムに組み込むことができる。
本発明の実施形態は、主にビデオコーディングに基づいて記載されているが、コーディングシステム10、エンコーダ20、およびデコーダ30（および対応するシステム10）の実施形態、ならびに本明細書に記載された他の実施形態は、静止画像処理またはコーディング、すなわち、ビデオコーディングの場合のように、先行するまたは連続する画像から独立した個々のピクチャの処理またはコーディングにも構成され得ることに留意されたい。一般に、画像処理コーディングが単一のピクチャ27に限定される場合、インター予測ユニット244（エンコーダ）および344（デコーダ）のみが利用可能でない場合がある。ビデオエンコーダ20およびビデオデコーダ30のすべての他の（ツールまたは技術とも呼ばれる）機能は、静止ピクチャ処理、たとえば、残差計算204／304、変換206、量子化208、逆量子化210／310、（逆）変換212／312、分割262／362、イントラ予測254／354、および／またはループフィルタリング220、320、ならびにエントロピーコーディング270およびエントロピー復号304に等しく使用されてよい。
たとえば、エンコーダ20およびデコーダ30の実施形態、ならびに、たとえば、エンコーダ20およびデコーダ30を参照して本明細書に記載された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せに実装されてよい。ソフトウェアに実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶されるか、または通信媒体を介して送信され、ハードウェアベースの処理ユニットによって実行されてよい。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含んでよい。このように、コンピュータ可読媒体は、一般に、（1）非一時的である有形コンピュータ可読記憶媒体、または（2）信号もしくは搬送波などの通信媒体に対応することができる。データ記憶媒体は、本開示に記載された技法の実装のための命令、コード、および／またはデータ構造を検索するために、1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスすることができる任意の利用可能な媒体であってよい。コンピュータプログラム製品はコンピュータ可読媒体を含んでもよい。
以下の論理演算子または数学演算子は、以下のように定義される。
本出願で使用される数学演算子は、Cプログラミング言語で使用されるものと同様である。しかしながら、整数除算および算術シフト演算の結果はより正確に定義され、べき乗および実数値除算などの追加の演算が定義される。ナンバリングおよびカウントの慣習は、一般に、0から始まり、たとえば、「最初の」は0番目に相当し、「2番目の」は1番目に相当する。
算術演算子
以下の算術演算子は以下のように定義される。
論理演算子
以下の論理演算子は以下のように定義される。
x＆＆y xとyのブール論理「and」
x｜｜y xとyのブール論理「or」
！ ブール論理「not」
x？y：z xが真であるか、または0に等しくない場合、yの値と判断され、そうでない場合、zの値と判断される。
関係演算子
以下の関係演算子は以下のように定義される。
＞ より大きい
＞＝ より大きいかまたは等しい
＜ より小さい
＜＝ より小さいかまたは等しい
＝＝ 等しい
！＝ 等しくない
値「na」（該当なし）が割り当てられた構文要素または変数に関係演算子が適用されると、値「na」は構文要素または変数用の個別の値として扱われる。値「na」はいかなる他の値とも等しくないと見なされる。
ビット単位の演算子
以下のビット単位の演算子は以下のように定義される。
＆ ビット単位の「and」整数引数に作用するとき、整数値の2の補数表現に作用する。別の引数よりも少ないビットを含むバイナリ引数に作用するとき、0に等しいより上位のビットを追加することにより、短い引数が拡張される。
｜ ビット単位の「or」整数引数に作用するとき、整数値の2の補数表現に作用する。別の引数よりも少ないビットを含むバイナリ引数に作用するとき、0に等しいより上位のビットを追加することにより、短い引数が拡張される。
＾ ビット単位の「排他的論理和」整数引数に作用するとき、整数値の2の補数表現に作用する。別の引数よりも少ないビットを含むバイナリ引数に作用するとき、0に等しいより上位のビットを追加することにより、短い引数が拡張される。
x＞＞y xの2の補数整数表現のyビットだけの算術右シフトこの関数は、yの負でない整数値に対してのみ定義される。右シフトの結果として最上位ビット（MSB）にシフトされたビットは、シフト演算前のxのMSBに等しい値を有する。
x＜＜y xの2の補数整数表現のyビットだけの算術左シフトこの関数は、yの負でない整数値に対してのみ定義される。左シフトの結果として最下位ビット（LSB）にシフトされたビットは、0に等しい値を有する。
代入演算子
以下の算術演算子は以下のように定義される。
＝ 代入演算子
＋＋ インクリメント、すなわちx＋＋はx＝x＋1に相当し、配列インデックスで使用されるとき、インクリメント演算の前に変数の値と判断される。
－－ デクリメント、すなわちx－－はx＝x－1に相当し、配列インデックスで使用されるとき、デクリメント演算の前に変数の値と判断される。
＋＝ 指定された量だけインクリメントする、すなわち、x＋＝3はx＝x＋3に相当し、x＋＝（－3）は、x＝x＋（－3）に相当する。
－＝ 指定された量だけデクリメントする、すなわち、x－＝3はx＝x－3に相当し、x－＝（－3）はx＝x－（－3）に相当する。
範囲表記
以下の表記は、値の範囲を指定するために使用される。
x＝y．．z xは、両端を含むyからzまでの整数値をとり、x、y、zは整数値であり、zはyよりも大きい。
数学関数
以下の数学関数が定義される。
Abs（x）＝
Asin（x）三角逆正弦関数、両端を含む－1．0から1．0までの範囲の引数xに作用し、出力値はラジアンの単位で両端を含む－π÷2からπ÷2までの範囲である。
Atan（x）三角逆正接関数、引数xに作用し、出力値はラジアンの単位で両端を含む－π÷2からπ÷2の範囲である。
Atan2（y、x）＝
Ceil（x）以上の最小の整数
Clip1Y（x）＝Clip3（0、（1＜＜BitDepthY）－1、x）
Clip1C（x）＝Clip3（0、（1＜＜BitDepthC）－1、x）
Clip3（x、y、z）＝
Cos（x）ラジアンの単位の引数xに作用する三角余弦関数
Floor（x）x以下の最大の整数
GetCurrMsb（a、b、c、d）＝
Ln（x）xの自然対数（底eの対数、eは自然対数の底定数2．718281828…）
Log2（x）底2のxの対数
Log10（x）底10のxの対数
Min（x、y）＝
Max（x、y）＝
Round（x）＝Sign（x）＊Floor（Abs（x）＋0．5）
Sign（x）＝
Sin（x）ラジアンの単位の引数xに作用する三角正弦関数
Sqrt（x）＝
Swap（x、y）＝（y、x）
Tan（x）ラジアンの単位の引数xに作用する三角正接関数
演算の優先順位
式の優先順位が括弧を使用して明示的に示されていないときは、以下の規則が適用される。
－優先度が高い演算は、優先度が低い演算の前に判断される。
－同じ優先度の演算は、左から右に順番に判断される。
下記の表は演算の優先度を最高から最低まで指定し、表の上位にあるほど、優先度が高いことを示す。
Cプログラミング言語でも使用される演算子の場合、本明細書で使用される優先順位は、Cプログラミング言語で使用されるものと同じである。
論理演算のテキスト記述
テキストでは、以下の形式で数学的に記述される論理演算のステートメント：
if（条件0）
ステートメント0
else if（条件1）
ステートメント1
…
else／＊残りの条件に関する有益なコメント＊／
ステートメントn
は、以下のように記述される場合がある：
…以下のように／…以下が適用される：
－If条件0，ステートメント0
－Otherwise，If条件1，ステートメント1
－…
－Otherwise（残りの条件に関する有益なコメント）、ステートメントn
テキスト内の各「If…Otherwise，if…Otherwise，…」ステートメントは、「…以下のように」または「…以下が適用される」の直後に「if…」が続く。「if…の最後の条件Otherwise，if…Otherwise，…」は常に「Otherwise，…」である。インターリーブされた「If…Otherwise，if…Otherwise，…」ステートメントは、「…以下のように」または「…以下が適用される」と整合することによって示すことができ、「Otherwise，…」で終わる。
テキストでは、以下の形式で数学的に記述される論理演算のステートメント：
if（条件0a＆＆条件0b）
ステートメント0
else if（条件1a｜｜条件1b）
ステートメント1
…
else
ステートメントn
は、以下のように記述される場合がある：
…以下のように／…以下が適用される：
－以下の条件のうちのすべてが真である場合、ステートメント0：
－条件0a
－条件0b
－そうでなく、以下の条件うちの1つまたは複数がすべて真である場合、ステートメント1：
－条件1a
－条件1b
－…
－そうでない場合、ステートメントn
テキストでは、以下の形式で数学的に記述される論理演算のステートメント：
if（条件0）
ステートメント0
if（条件1）
ステートメント1
は、以下のように記述される場合がある：
条件0のとき、ステートメント0
条件1のとき、ステートメント1
頭字語の定義および用語集
HEVC－高効率ビデオコーディング
VVC－多用途ビデオコーディング
VTM－VVCテストモデル
JEM－共同調査モデル
CTU－コーディングツリーユニット
CU－コーディングユニット
BT－二分木
TT－三分木
QT－四分木（Quad Tree）または四分木（Quaternary Tree）
ABT－非対称BT
MTT－マルチタイプツリー
AMP－非対称分割
SH－スライスヘッダ
SPS－シーケンスパラメータセット
PPS－ピクチャパラメータセット
CE－コア実験
SubCE－サブコア実験（コア実験の一部）
10 ビデオコーディングシステム
12 ソースデバイス
13 符号化データ
14 宛先デバイス
16 ピクチャソース
17 ピクチャデータ
18 前処理ユニット
19 前処理されたピクチャデータ
20 エンコーダ
21 符号化ピクチャデータ
22 通信インターフェース
28 通信インターフェース
30 デコーダ
30 ブロック
31 復号ピクチャ
31 ブロック
32 後処理ユニット
32 ブロック
33 後処理されたピクチャ
33 ブロック
34 ディスプレイデバイス
34 ブロック
35 ブロック
36 ブロック
37 ブロック
38 ブロック
39 ブロック
40 ビデオコーディングシステム
40 ブロック
41 撮像デバイス
41 ブロック
42 アンテナ
42 ブロック
43 プロセッサ
43 ブロック
44 メモリストア
44 ブロック
45 ディスプレイデバイス
45 ブロック
46 処理ユニット
46 ブロック
47 論理回路
50 ノード
52 ノード
54 ノード
56 ノード
58 ノード
60 ノード
62 ノード
100 デバイス
101 ビットストリーム
102 MaxBtSizeY
103 MaxMttDepth
104 MinCbSizeY
105 MinQtSizeY
200 SPS RBSP構文
201 構文要素
202 構文要素
202 入力
203 ピクチャブロック
204 残差計算ユニット
205 残差ブロック
206 変換処理ユニット
207 変換係数
208 量子化ユニット
209 量子化変換係数
210 逆量子化ユニット
211 逆量子化係数
212 逆変換処理ユニット
213 逆変換ブロック
214 復元ユニット
215 復元ブロック
216 バッファ
220 ループフィルタユニット
221 フィルタリングされたブロック
230 復号ピクチャバッファ（DPB）
231 復号ピクチャ
244 インター予測ユニット
245 インター予測ブロック
254 イントラ予測ユニット
255 イントラ予測ブロック
260 予測処理ユニット
262 モード選択ユニット
265 予測ブロック
266 構文要素
270 エントロピー符号化ユニット
271 符号化ピクチャデータ
272 出力
300 スライスヘッダ構文
301 構文要素
304 エントロピー復号ユニット
309 量子化係数
310 逆量子化ユニット
311 逆量子化係数
312 逆変換処理ユニット
313 逆変換ブロック
314 復元ユニット
315 復元ブロック
316 バッファ
317 基準サンプル
320 ループフィルタ
321 フィルタリングされたブロック
330 復号ピクチャバッファ
331 復号ピクチャ
332 出力
344 インター予測ユニット
354 イントラ予測ユニット
360 予測処理ユニット
362 モード選択ユニット
365 予測ブロック
366 構文要素
400 SPS RBSP構文
400 ビデオコーディングデバイス
401 構文要素
402 構文要素
403 構文要素
404 構文要素
405 ピクチャサイズ要素
406 ピクチャサイズ要素
410 入口ポート
420 受信機ユニット（Rx）
430 プロセッサ
440 送信機ユニット（Tx）
450 出口ポート
460 メモリ
470 コーディングモジュール
500 装置
502 プロセッサ
504 メモリ
506 コードおよびデータ
508 オペレーティングシステム
510 アプリケーションプログラム
512 バス
514 セカンダリストレージ
518 ディスプレイ
520 画像検知デバイス
522 音波検知デバイス
600 スライスヘッダ構文
601 構文要素
710 正方形ブロック
720 正方形ブロック
730 正方形ブロック
740 正方形ブロック
750 正方形ブロック
760 正方形ブロック
770 正方形ブロック
772 リーフノードブロック
774 リーフノードブロック
780 正方形ブロック
910 ブロック
920 正方形ブロック
930 正方形ブロック
932 ブロック
940 正方形ブロック
942 ブロック
950 正方形ブロック
952 ブロック
954 ブロック
1000 デバイス
3100 コンテンツ供給システム
3102 キャプチャデバイス
3104 通信リンク
3106 端末デバイス
3108 スマートフォンまたはスマートパッド
3110 コンピュータまたはラップトップ
3112 ネットワークビデオレコーダ（NVR）／デジタルビデオレコーダ（DVR）
3114 テレビ
3116 セットトップボックス（STB）
3118 ビデオ会議システム
3120 ビデオ監視システム
3122 携帯情報端末（PDA）
3124 車載デバイス
3126 ディスプレイ
3202 プロトコル進行ユニット
3204 逆多重化ユニット
3206 ビデオデコーダ
3208 オーディオデコーダ
3210 字幕デコーダ
3212 同期ユニット
3214 ビデオ／オーディオディスプレイ
3216 ビデオ／オーディオ／字幕ディスプレイ
5000 スライスヘッダ構文
5001 構文要素
7000 方法
7001 ステップ
7002 ステップ
7003 ステップ

Claims (20)

  1. ビデオビットストリーム（101）を復号または処理するためのデバイスであって、前記デバイスが、
    前記ビットストリーム（101）から構文要素を取得し、
    四分木分割から生じるルーマリーフブロックのルーマサンプル内の最小サイズMinQtSizeY（105）に関する情報を取得し、
    MinQtSizeY（105）に関する前記情報および前記取得された構文要素に基づいて、二分木分割を使用して分割することができるルーマルートブロックのルーマサンプル内の最大サイズMaxBtSizeY（102）を決定する
    ように構成された回路を含む、デバイス。
  2. 前記回路が、その下限が前記MinQtSizeY（105）であることを考慮して前記MaxBtSizeY（102）を決定するように構成される、請求項1に記載のデバイス。
  3. 前記構文要素が、前記MinQtSizeY（105）の2を底とする対数と前記MaxBtSizeY（102）の2を底とする対数との間の差分の構文要素（301）である、請求項1または2に記載のデバイス。
  4. 前記構文要素が、前記MinQtSizeY（105）と前記MaxBtSizeY（102）との間の差分の構文要素（301）であり、差分の前記構文要素が、2を底とする対数スケールで前記差分を通知している、請求項1または2に記載のデバイス。
  5. 前記回路が、四分木リーフブロックのマルチタイプツリー分割から生じるコーディングユニットの最大階層深度に依存する前記ビットストリームから前記構文要素を取得するように構成される、請求項1から4のいずれか一項に記載のデバイス。
  6. 前記MaxMttDepth（103）がゼロに等しくない場合、前記回路が前記ビットストリーム（101）から前記構文要素を取得するように構成される、請求項5に記載のデバイス。
  7. ビデオビットストリーム（101）を生成または処理するためのデバイス（1000）であって、前記デバイス（1000）が、
    四分木分割から生じるリーフブロックの最小ルーマサイズMinQtSizeY（105）を決定し、
    前記MinQtSizeY（105）に基づいて、二分木分割を使用して分割されるコーディングブロックの最大ルーマサイズMaxBtSizeY（102）を決定し、
    前記決定されたMinQtSizeY（105）に関する情報を前記ビットストリーム（101）に含める
    ように構成される、デバイス（1000）。
  8. その下限が前記MinQtSizeY（105）であることを考慮して前記MaxBtSizeY（102）を決定する
    ように構成される、請求項7に記載のデバイス（1000）。
  9. 請求項7または8に記載の、符号化ピクチャを含むビットストリーム（101）を生成または処理するためのデバイスであって、前記デバイスが、
    前記MinQtSizeY（105）の2を底とする対数と前記MaxBtSizeY（102）の2を底とする対数との間の差分の構文要素（301）を前記ビットストリーム（101）に含める
    ようにさらに構成される、デバイス。
  10. 前記構文要素が、前記MinQtSizeY（105）と前記MaxBtSizeY（102）との間の差分の構文要素（301）であり、差分の前記構文要素が、2を底とする対数スケールで前記差分を通知している、請求項8または9に記載のデバイス（1000）。
  11. 請求項9から10のいずれか一項に記載の、符号化ピクチャを含むビットストリーム（101）を生成または処理するためのデバイスであって、前記デバイスが、
    マルチタイプツリー分割から生じるコーディングユニットの最大階層深度MaxMttDepth（103）に依存する前記構文要素（5001）を前記ビットストリーム（101）に含める
    ように構成される、デバイス。
  12. 前記MaxMttDepth（103）がゼロに等しくない場合、前記構文要素を前記ビットストリーム（101）に含める
    ように構成される、請求項11に記載のデバイス（100）。
  13. ビデオビットストリーム（101）を生成または処理するための方法であって、
    四分木分割から生じるリーフブロックの最小ルーマサイズMinQtSizeY（105）を決定するステップと、
    前記MinQtSizeY（105）に基づいて、二分木分割を使用して分割されるコーディングブロックの最大ルーマサイズMaxBtSizeY（102）を決定するステップと、
    前記決定されたMinQtSizeY（105）に関する情報を前記ビットストリーム（101）に含めるステップと
    を含む、方法。
  14. ビデオビットストリーム（101）を復号または処理するための方法であって、
    前記ビットストリーム（101）から構文要素を取得するステップと、
    四分木分割から生じるルーマリーフブロックのルーマサンプル内の最小サイズMinQtSizeY（105）に関する情報を取得するステップと、
    MinQtSizeY（105）に関する前記情報および前記取得された構文要素に基づいて、二分木分割を使用して分割することができるルーマルートブロックのルーマサンプル内の最大サイズMaxBtSizeY（102）を決定するステップと
    を含む、方法。
  15. MinQtSizeY（105）に関する前記情報および前記取得された構文要素に基づいて前記MaxBtSizeY（102）を決定する前記ステップが、その下限が前記MinQtSizeY（105）であることを考慮して前記MaxBtSizeY（102）を決定するステップを含む、請求項14に記載の方法。
  16. 前記構文要素が、前記MaxBtSizeY（102）の2を底とする対数と前記MinQtSizeY（105）の2を底とする対数との間の差分を指定する構文要素（301）であるか、または前記構文要素が、前記MaxBtSizeYと前記MinQtSizeYとの間の前記差分を指定する、請求項14または15に記載の方法。
  17. 前記構文要素が、前記MinQtSizeY（105）と前記MaxBtSizeY（102）との間の差分の構文要素（301）であり、差分の前記構文要素が、2を底とする対数スケールで前記差分を通知している、請求項14または15に記載の方法。
  18. 前記ビットストリーム（101）から前記構文要素を取得する前記ステップが、四分木リーフブロックのマルチタイプツリー分割から生じるコーディングユニットの最大階層深度に依存する前記ビットストリームから前記構文要素を取得するステップを含む、請求項14から17のいずれか一項に記載の方法。
  19. 前記ビットストリーム（101）から前記構文要素を取得する前記ステップが、前記MaxMttDepth（103）がゼロに等しくない場合、前記ビットストリーム（101）から前記構文要素を取得するステップを含む、請求項18に記載の方法。
  20. デバイス（100、1000）の1つまたは複数のプロセッサによってプログラムコードが実行されると、請求項13または14の前記方法（7000）を実行するように前記デバイス（100、1000）を制御するための前記プログラムコードを含む、コンピュータプログラム製品。
JP2023085663A 2018-09-03 2023-05-24 分割制約要素間の関係 Pending JP2023111927A (ja)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US201862726423P 2018-09-03 2018-09-03
US62/726,423 2018-09-03
US201862733053P 2018-09-18 2018-09-18
US62/733,053 2018-09-18
US201962818996P 2019-03-15 2019-03-15
US62/818,996 2019-03-15
JP2021506475A JP7286757B2 (ja) 2018-09-03 2019-09-03 分割制約要素間の関係
PCT/CN2019/104260 WO2020048466A1 (en) 2018-09-03 2019-09-03 Relation between partition constraint elements

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2021506475A Division JP7286757B2 (ja) 2018-09-03 2019-09-03 分割制約要素間の関係

Publications (1)

Publication Number Publication Date
JP2023111927A true JP2023111927A (ja) 2023-08-10

Family

ID=69722985

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2021506475A Active JP7286757B2 (ja) 2018-09-03 2019-09-03 分割制約要素間の関係
JP2023085663A Pending JP2023111927A (ja) 2018-09-03 2023-05-24 分割制約要素間の関係

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2021506475A Active JP7286757B2 (ja) 2018-09-03 2019-09-03 分割制約要素間の関係

Country Status (11)

Country Link
US (2) US11477494B2 (ja)
EP (1) EP3808081A4 (ja)
JP (2) JP7286757B2 (ja)
KR (2) KR20230054917A (ja)
CN (2) CN112673626B (ja)
AU (1) AU2019334017B2 (ja)
BR (1) BR112021003999A2 (ja)
CA (1) CA3111043C (ja)
MX (1) MX2021002284A (ja)
WO (1) WO2020048466A1 (ja)
ZA (1) ZA202101704B (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113273197A (zh) * 2019-02-03 2021-08-17 北京字节跳动网络技术有限公司 视频块分割模式的信令通知
US11496774B2 (en) * 2019-08-27 2022-11-08 Tencent America LLC Header syntax for QT/BT/TT size
US11399195B2 (en) * 2019-10-30 2022-07-26 Tencent America LLC Range of minimum coding block size in video coding
FI4044599T3 (fi) * 2019-11-05 2024-03-25 Lg Electronics Inc Kuva/videokoodausmenetelmä ja -laite
WO2021207055A1 (en) 2020-04-05 2021-10-14 Bytedance Inc. High level control of filtering in video coding
WO2023236775A1 (en) * 2022-06-06 2023-12-14 Mediatek Inc. Adaptive coding image and video data

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8761245B2 (en) 2010-12-21 2014-06-24 Intel Corporation Content adaptive motion compensation filtering for high efficiency video coding
TWI638564B (zh) 2011-12-21 2018-10-11 Ｊｖｃ建伍股份有限公司 Dynamic image decoding device, dynamic image decoding method, and recording medium recorded with dynamic image decoding program
US20140254661A1 (en) * 2013-03-08 2014-09-11 Samsung Electronics Co., Ltd. Method and apparatus for applying secondary transforms on enhancement-layer residuals
WO2016074147A1 (en) * 2014-11-11 2016-05-19 Mediatek Singapore Pte. Ltd. Separated coding tree for luma and chroma
WO2016090568A1 (en) 2014-12-10 2016-06-16 Mediatek Singapore Pte. Ltd. Binary tree block partitioning structure
WO2017008263A1 (en) 2015-07-15 2017-01-19 Mediatek Singapore Pte. Ltd. Conditional binary tree block partitioning structure
US10212444B2 (en) * 2016-01-15 2019-02-19 Qualcomm Incorporated Multi-type-tree framework for video coding
MX2021012481A (es) 2016-03-16 2022-05-30 Hfi Innovation Inc Metodo y aparato de procesamiento de datos de video con tama?o restringido de bloque en codificacion de video.
CN107566848B (zh) 2016-06-30 2020-04-14 华为技术有限公司 编解码的方法及装置
JP7173961B2 (ja) 2016-08-21 2022-11-16 エルジー エレクトロニクス インコーポレイティド 映像符号化／復号化方法及びそのための装置
US10609423B2 (en) * 2016-09-07 2020-03-31 Qualcomm Incorporated Tree-type coding for video coding
EP4075798A1 (en) * 2016-10-04 2022-10-19 HFI Innovation Inc. Method and apparatus for intra chroma coding in image and video coding
JP2018085660A (ja) 2016-11-25 2018-05-31 キヤノン株式会社 画像符号化装置
US10560723B2 (en) * 2017-05-08 2020-02-11 Qualcomm Incorporated Context modeling for transform coefficient coding
US10911757B2 (en) * 2017-09-08 2021-02-02 Mediatek Inc. Methods and apparatuses of processing pictures in an image or video coding system
CN111819851A (zh) * 2018-01-30 2020-10-23 夏普株式会社 用于使用预测运动向量起点对视频编码执行运动向量预测的系统和方法
WO2019194147A1 (en) * 2018-04-02 2019-10-10 Sharp Kabushiki Kaisha Systems and methods for deriving quantization parameters for video blocks in video coding
CN112204967A (zh) * 2018-05-31 2021-01-08 夏普株式会社 用于划分视频数据的帧间预测片段中的视频块的系统和方法
WO2020004987A1 (ko) * 2018-06-27 2020-01-02 한국전자통신연구원 영상 부호화/복호화 방법, 장치 및 비트스트림을 저장한 기록 매체

Also Published As

Publication number Publication date
CA3111043C (en) 2023-08-15
EP3808081A1 (en) 2021-04-21
CN116208767B (zh) 2023-11-28
WO2020048466A1 (en) 2020-03-12
AU2023202264A1 (en) 2023-05-04
US11910027B2 (en) 2024-02-20
CN112673626B (zh) 2024-04-26
CN116208767A (zh) 2023-06-02
EP3808081A4 (en) 2021-07-21
JP7286757B2 (ja) 2023-06-05
MX2021002284A (es) 2021-05-27
AU2019334017B2 (en) 2023-01-12
BR112021003999A2 (pt) 2021-05-25
ZA202101704B (en) 2022-04-28
US11477494B2 (en) 2022-10-18
JP2021535645A (ja) 2021-12-16
AU2019334017A1 (en) 2021-04-08
CA3111043A1 (en) 2020-03-12
KR102525179B1 (ko) 2023-04-21
US20230171437A1 (en) 2023-06-01
CN112673626A (zh) 2021-04-16
KR20210024114A (ko) 2021-03-04
US20210258618A1 (en) 2021-08-19
KR20230054917A (ko) 2023-04-25

Similar Documents

Publication Publication Date Title
JP7286757B2 (ja) 分割制約要素間の関係
AU2023206208B2 (en) A video encoder, a video decoder and corresponding methods
JP2023041687A (ja) タイル構成のシグナリングのためのエンコーダ、デコーダ、および対応する方法
EP4085620A2 (en) Reference picture management methods for video coding
AU2023202264B2 (en) Relation between partition constraint elements
RU2786652C2 (ru) Связь между элементами ограничения разделения
RU2786427C2 (ru) Видеокодер, видеодекодер и соответствующие способы
JP2023508053A (ja) 符号化器、復号器、及びコーディング・ブロック・パーティショニング制限導出の方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230622

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230622