JP7288071B2 - ビデオ処理方法、装置及び記憶媒体 - Google Patents
ビデオ処理方法、装置及び記憶媒体 Download PDFInfo
- Publication number
- JP7288071B2 JP7288071B2 JP2021551763A JP2021551763A JP7288071B2 JP 7288071 B2 JP7288071 B2 JP 7288071B2 JP 2021551763 A JP2021551763 A JP 2021551763A JP 2021551763 A JP2021551763 A JP 2021551763A JP 7288071 B2 JP7288071 B2 JP 7288071B2
- Authority
- JP
- Japan
- Prior art keywords
- transform
- video
- sub
- block
- samples
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/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/117—Filters, e.g. for pre-processing or post-processing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
- H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
- H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
- H04N19/159—Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
- H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
- H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
- H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/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/80—Details of filtering operations specially adapted for video compression, e.g. for pixel interpolation
- H04N19/82—Details of filtering operations specially adapted for video compression, e.g. for pixel interpolation involving filtering within a prediction loop
-
- 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/85—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
- H04N19/86—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression involving reduction of coding artifacts, e.g. of blockiness
-
- 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)
Description
関連出願の相互参照
本願は、2020年3月2日付で出願された国際特許出願PCT/CN2020/077429に基づいており、同出願は2019年3月2日付で出願された「パーティション構造に関する制限」と題するPCT/CN2019/076785の優先権を主張している。あらゆる目的に関し、上記出願の開示全体が本願の開示の一部として参照により援用される。
本願は、2020年3月2日付で出願された国際特許出願PCT/CN2020/077429に基づいており、同出願は2019年3月2日付で出願された「パーティション構造に関する制限」と題するPCT/CN2019/076785の優先権を主張している。あらゆる目的に関し、上記出願の開示全体が本願の開示の一部として参照により援用される。
技術分野
この特許文献は、ビデオ・コーディング技術、デバイス及びシステムに関連している。
この特許文献は、ビデオ・コーディング技術、デバイス及びシステムに関連している。
現在、より良い圧縮比を提供するため、又はより低い複雑性あるいは並列化された実装を可能にするビデオ符号化及び復号化方式を提供するために、現在のビデオ・コーデック技術のパフォーマンスの改善が進行しつつある。業界のエキスパートは、最近、幾つかの新しいビデオ・コーディング・ツールを提案しており、それらの有効性を判定するためのテストが現在進行中である。
デジタル・ビデオ・コーディング、具体的には動きベクトルを導出することに関連するデバイス、システム、及び方法が説明される。説明される方法は、既存のビデオ・コーディング規格（例えば、高効率ビデオ・コーディング（HEVC）又は汎用ビデオ・コーディング（VVC））及び将来のビデオ・コーディング規格又はビデオ・コーデックに適用することが可能である。
代表的な一態様では、開示される技術は、ビデオ処理のための方法を提供するために使用することが可能である。この方法は、少なくとも部分的に仮想パイプライン・データ・ユニット（VPDU）のサイズに基づいて、パーティション・ツリーに関連するパーティションのタイプがビデオ・ブロックに対して許容されるか又は許容されないかを決定することを含み、VPDUサイズはVPDU高さ及びVPDU幅を含み、パーティションのタイプを許容しないことに応じて、パーティション・タイプの指示はビットストリーム内に存在しない。
他の代表的な態様では、開示される技術は、ビデオ処理のための他の方法を提供するために使用されることが可能である。この方法は、少なくとも部分的に最大許容サブ・ブロック変換サイズに基づいて、パーティション・ツリーに関連するパーティションのタイプがビデオ・ブロックに対して許容されるか又は許容されないかを決定することを含み、最大許容サブ・ブロック変換サイズは、最大許容サブ・ブロック変換高さと最大許容サブ・ブロック変換幅とを含み、パーティションのタイプを許容しないことに応じて、パーティション・タイプの指示はビットストリーム内に存在しない。
更に別の代表的な態様では、開示される技術は、ビデオ処理のための更に別の方法を提供するために使用されることが可能である。この方法は、少なくとも部分的に最大許容変換サイズと仮想パイプライン・データ・ユニット（VPDU）のサイズに基づいて、又は少なくとも部分的に最大許容サブ・ブロック変換サイズと仮想パイプライン・データ・ユニット（VPDU）のサイズに基づいて、パーティション・ツリーに関連するパーティションのタイプがビデオ・ブロックに対して許容されるか又は許容されないかを決定することを含み、VPDUサイズはVPDU高さとVPDU幅とを含み、最大許容変換サイズは最大許容変換高さと最大許容変換幅とを含み、パーティションのタイプを許容しないことに応じて、パーティション・タイプの指示はビットストリーム内に存在しない。
更に別の代表的な態様では、開示される技術は、ビデオ処理のための更に別の方法を提供するために使用されることが可能である。本方法は：サブ・ブロック変換が適用される場合に、サンプルはサブ・ブロック変換境界に位置するかどうかを判定するステップと；サンプルはサブ・ブロック変換境界に位置すると判定された場合に、デブロッキング・フィルタ・プロセスを適用するステップと；ビデオ及びビデオのビットストリーム表現の間で変換を実行するステップとを含む。
更に別の代表的な態様では、開示される技術は、ビデオ処理のための更に別の方法を提供するために使用されることが可能である。本方法は：サブ・ブロック変換が適用されるかどうかに基づいて、フィルタリング・プロセスをビデオ・ブロックに適用する仕方を決定するステップと；当該決定に基づいてフィルタリング・プロセスを実行するステップと；ビデオ・ブロック及びビデオのビットストリーム表現の間で変換を実行するステップとを含む。
更に、代表的な態様では、ビデオ復号化装置が開示され、本装置は開示される方法のうちの任意の1つ以上を実行するように構成されたプロセッサを含む。
更に、代表的な態様では、ビデオ符号化装置が開示され、本装置は開示される方法のうちの任意の1つ以上を実行するように構成されたプロセッサを含む。
更に、代表的な態様では、プロセッサと命令を伴う非一時的なメモリとを含むビデオ・システムにおける装置が開示される。命令はプロセッサにより実行されると、開示される方法のうちの任意の1つ以上をプロセッサに実行させる。
また、非一時的なコンピュータ読み取り可能な媒体に記憶されたコンピュータ・プログラム製品が開示され、コンピュータ・プログラム製品は、開示される方法のうちの任意の1つ以上を実行するためのプログラム・コードを含む。
開示される技術の上記及び他の態様及び特徴は、図面、明細書及び特許請求の範囲に詳細に記載されている。
1．H.264/AVCのビデオ・コーディング
ビデオ・コーディング規格は、よく知られたITU-TやISO/IEC規格の開発を中心に発展してきた。ITU-TはH.261とH.263を作成し、ISO/IECはMPEG-1とMPEG-4 Visualを作成し、2つの組織はH.262/MPEG-2 VideoとH.264/MPEG-4 Advanced Video Coding（AVC）とH.265/HEVC規格とを共同で作成した。H.262以降、ビデオ・コーディング規格は、時間的予測プラス変換コーディングが利用されるハイブリッド・ビデオ・コーディング構造に基づいている。HEVCを越える将来的なビデオ・コーディング技術を探求するため、2015年に共同ビデオ探査チーム（JVET）がVCEGとMPEGにより共同で設立された。それ以来、JVETによって多くの新しい方法が採用され、共同探索モデル（Joint Exploration Model，JEM）と名付けられた参照ソフトウェアに組み込まれている。2018年4月には、VCEG（Q6/16）とISO/IEC JTC1 SC29/WG11（MPEG）の間で共同ビデオ・エキスパート・チーム（JVET）を発足させ、HEVCと比較して50%のビットレート縮小を目指すVVC規格に取り組んでいる。
ビデオ・コーディング規格は、よく知られたITU-TやISO/IEC規格の開発を中心に発展してきた。ITU-TはH.261とH.263を作成し、ISO/IECはMPEG-1とMPEG-4 Visualを作成し、2つの組織はH.262/MPEG-2 VideoとH.264/MPEG-4 Advanced Video Coding（AVC）とH.265/HEVC規格とを共同で作成した。H.262以降、ビデオ・コーディング規格は、時間的予測プラス変換コーディングが利用されるハイブリッド・ビデオ・コーディング構造に基づいている。HEVCを越える将来的なビデオ・コーディング技術を探求するため、2015年に共同ビデオ探査チーム（JVET）がVCEGとMPEGにより共同で設立された。それ以来、JVETによって多くの新しい方法が採用され、共同探索モデル（Joint Exploration Model，JEM）と名付けられた参照ソフトウェアに組み込まれている。2018年4月には、VCEG（Q6/16）とISO/IEC JTC1 SC29/WG11（MPEG）の間で共同ビデオ・エキスパート・チーム（JVET）を発足させ、HEVCと比較して50%のビットレート縮小を目指すVVC規格に取り組んでいる。
VVCドラフトの最新バージョン、即ち汎用ビデオ・コーディング（ドラフト4）は、http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=5755にある。VTMと名付けられるVVCの最新リファレンス・ソフトウェアは、https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/tags/VTM-3.1にある。
2．1 H.264/AVCにおけるパーティション・ツリー構造
H.264/AVSで使用される用語は、マクロブロックとMBモード/8x8モード（パーティション）である。マクロブロックは、各ピクチャ/スライスが分割され且つイントラ/インター・モード判定が適用されるユニットである。パーティションは、動き情報がシグナリングされるレベルを定める。
H.264/AVSで使用される用語は、マクロブロックとMBモード/8x8モード（パーティション）である。マクロブロックは、各ピクチャ/スライスが分割され且つイントラ/インター・モード判定が適用されるユニットである。パーティションは、動き情報がシグナリングされるレベルを定める。
H.264/AVCのコーディング・レイヤはマクロブロックを当てにしており、そのマクロブロックは、16x16ブロックのルマ・サンプルと、4:2:0のカラー・サンプリングの通常の場合は、2つの対応する8x8ブロックのクロマ・サンプルとを含む。
2．1．1．H.264/AVCメイン・プロファイル
このプロファイルでは、イントラ・コーディングされたブロックは、ピクセル間の空間相関を活用するために、空間予測を利用する。16x16と4x4の2つのパーティションが定義されている。
このプロファイルでは、イントラ・コーディングされたブロックは、ピクセル間の空間相関を活用するために、空間予測を利用する。16x16と4x4の2つのパーティションが定義されている。
インター・コーディングされたブロックは、ピクチャ間の動きを推定することにより、空間予測ではなく時間予測を利用する。16x16マクロブロック又はそのうちの任意のマクロブロック・パーティション（16x8，8x16，8x8）に対して独立に動きを推定することが可能である。16x16，16x8，8x16，又は8x8が選択されたかどうかを示すためにシンタックス要素（MBモード）がシグナリングされる。8x8が選択される場合、8x8，8x4，4x8，4x4（例えば、図1に示されている）が使用されるかどうかを示すために、別のシンタックス要素（8x8モード）が更に使用される。パーティションあたり唯1つの動きベクトル（MV）が許容される。
4x4変換のみが使用される。
2．1．2．H.264/AVCハイ・プロファイル
ハイ・プロファイルでは、8x8変換及びI_8x8（8x8イントラ予測）が導入される。イントラ・コーディング・マクロブロックの場合、変換サイズは固定される。I_16x16及びI_4x4は4x4変換を使用し；I_8x8は8x8変換を使用する。
ハイ・プロファイルでは、8x8変換及びI_8x8（8x8イントラ予測）が導入される。イントラ・コーディング・マクロブロックの場合、変換サイズは固定される。I_16x16及びI_4x4は4x4変換を使用し；I_8x8は8x8変換を使用する。
インター・コーディングされたマクロブロックの場合、4x4変換又は8x8変換の何れかを選択することが可能である。しかしながら、変換サイズはパーティション・サイズを超えることはできない。例えば、1つのマクロブロックが8x8パーティションを選択し、且つ8x4サブ・モードも選択する場合、4x4変換のみを適用することが可能である。1つのマクロブロックが16x16，16x8，8x16，8x8パーティションを8x8サブ・モードとともに選択する場合、4x4又は8x8変換の何れかを選択することが可能である。
2．1．3．要約
モード選択はマクロブロック・レベルで決定される。変換サイズはパーティション・サイズを越えないものとする。
モード選択はマクロブロック・レベルで決定される。変換サイズはパーティション・サイズを越えないものとする。
2．2．HEVCにおけるパーティション・ツリー構造
HEVCでは、コーディング・ツリー・ユニット（CTU）、最大コーディング・ユニット（LCU）としても知られているものは、様々なローカルな特徴に適合させるために、コーディング・ツリーとして示される四分木を使用することによって、コーディング・ユニット（CU）に分割される。インター・ピクチャ（時間的）又はイントラ・ピクチャ（空間的）予測を使用してピクチャ領域をコーディングするかどうかの判定は、CUレベルで行われる。各CUは、PU分割タイプに応じて、1つ、2つ、又は4つのPUに更に分割されることが可能である。1つのPU内では、同じ予測プロセスが適用され、関連情報がPUベースでデコーダに送信される。PU分割タイプに基づいて予測プロセスを適用することにより残差ブロックを取得した後、CUは、CUのコーディング・ツリーに類似する別の四分木構造に従って、変換ユニット（TU）にパーティション化されることが可能である。HEVC構造の重要な特徴の1つは、それがCU、PU、及びTUを含む複数のパーティション概念を有していることである。
HEVCでは、コーディング・ツリー・ユニット（CTU）、最大コーディング・ユニット（LCU）としても知られているものは、様々なローカルな特徴に適合させるために、コーディング・ツリーとして示される四分木を使用することによって、コーディング・ユニット（CU）に分割される。インター・ピクチャ（時間的）又はイントラ・ピクチャ（空間的）予測を使用してピクチャ領域をコーディングするかどうかの判定は、CUレベルで行われる。各CUは、PU分割タイプに応じて、1つ、2つ、又は4つのPUに更に分割されることが可能である。1つのPU内では、同じ予測プロセスが適用され、関連情報がPUベースでデコーダに送信される。PU分割タイプに基づいて予測プロセスを適用することにより残差ブロックを取得した後、CUは、CUのコーディング・ツリーに類似する別の四分木構造に従って、変換ユニット（TU）にパーティション化されることが可能である。HEVC構造の重要な特徴の1つは、それがCU、PU、及びTUを含む複数のパーティション概念を有していることである。
以下では、HEVCを使用するハイブリッド・ビデオ・コーディングに関わる様々な特徴が次の点で強調される。
1）コーディング・ツリー・ユニット及びコーディング・ツリー・ブロック（CTB）構造：HEVCにおける類似構造はコーディング・ツリー・ユニット（CTU）であり、エンコーダによって選択されたサイズを有し、従来のマクロブロックよりも大きい可能性がある。CTUはルマCTBと、対応するクロマCTBと、シンタックス要素とを含む。ルマCTBのサイズL×Lは、L = 16，32，又は64サンプルのように選択することが可能であり、一般的にはサイズが大きいほど、より優れた圧縮を可能にする。次いで、HEVCは、ツリー構造及び四分木的なシグナリングを使用して、CTBのより小さなブロックへのパーティショニングをサポートする。
2）コーディング・ユニット（CU）及びコーディング・ブロック（CB）：CTUの四分木シンタックスは、そのルマ及びクロマCBのサイズと位置を指定する。四分木のルートはCTUに関連付けられる。従って、ルマCTBのサイズは、ルマCBに対してサポートされる最大サイズである。CTUのルマ及びクロマCBへの分割は、一緒にシグナリングさえる。1つのルマCBと通常的には2つのクロマCBは、関連するシンタックスと共に、コーディング・ユニット（CU）を形成する。CTBは、唯1つのCUを含む場合があり、又は複数のCUを形成するために分割される場合があり、各CUは、予測ユニット（PU）への関連するパーティショニング、及び変換ユニット（TU）のツリーを有する。
3）予測ユニット（PU）及び予測ブロック（PB）：インター・ピクチャ又はイントラ・ピクチャ予測を用いてピクチャ領域をコーディングするかどうかの判定は、CUレベルで行われる。PUパーティショニング構造は、CUレベルでそのルートを有する。基本的な予測タイプ決定に依存して、ルマ及びクロマCBは更にサイズ分割され、ルマ及びクロマ予測ブロック（PB）から予測することが可能である。HEVCは、64×64から4×4サンプルまでの可変のPBサイズをサポートしている。図2は許容されるPBを描いている。
4）変換ユニット（TU）及び変換ブロック（TB）：予測残差はブロック変換を用いてコーディングされる。TUツリー構造は、CUレベルでそのルートを有する。ルマCB残差は、ルマ変換ブロック（TB）と同一であってもよいし、又はより小さなルマTBに更に分割されてもよい。クロマTBについても同様なことが適用される。4×4，8×8，16×16，及び32×32の正方形TBサイズに対して、離散コサイン変換（DCT）によるものと類似する整数基底関数が定義される。ルマ・イントラ・ピクチャ予測残差の4×4変換については、離散サイン変換（DST）の形式から導出される整数変換が代替的に指定される。
2．2．1．四分木の深度
サイズM×Mの所与のルマCBの場合、それがサイズM/2×M/2の4ブロックに分割されるかどうかを示すフラグがシグナリングされる。SPSに示されている残差四分木の最大深さによってシグナリングされるように、更なる分割が可能である場合、各々のクオーターには、それが4つのクオーターに分割されるかどうかを示すフラグが割り当てられる。残りの四分木から生じるリーフ・ノード・ブロックは、変換コーディングによって更に処理される変換ブロックである。エンコーダは、使用できる最大及び最小ルマTBサイズを指定する。CBサイズが最大TBサイズより大きい場合、分割は暗黙的である。分割が、指定された最小値より小さなルマTBサイズをもたらす場合、分割は暗黙的ではない。クロマTBサイズは、各次元のルマTBサイズの半分であるが、但し、ルマTBサイズが4×4である場合は除外され、その場合、4つの4×4ルマTBでカバーされた領域に対して1つの4×4クロマTBが使用される。イントラ・ピクチャ予測されるCUの場合、（CBの中又は外で）最も近い隣接TBの復号化されたサンプルが、イントラ・ピクチャ予測の参照データとして使用される。
サイズM×Mの所与のルマCBの場合、それがサイズM/2×M/2の4ブロックに分割されるかどうかを示すフラグがシグナリングされる。SPSに示されている残差四分木の最大深さによってシグナリングされるように、更なる分割が可能である場合、各々のクオーターには、それが4つのクオーターに分割されるかどうかを示すフラグが割り当てられる。残りの四分木から生じるリーフ・ノード・ブロックは、変換コーディングによって更に処理される変換ブロックである。エンコーダは、使用できる最大及び最小ルマTBサイズを指定する。CBサイズが最大TBサイズより大きい場合、分割は暗黙的である。分割が、指定された最小値より小さなルマTBサイズをもたらす場合、分割は暗黙的ではない。クロマTBサイズは、各次元のルマTBサイズの半分であるが、但し、ルマTBサイズが4×4である場合は除外され、その場合、4つの4×4ルマTBでカバーされた領域に対して1つの4×4クロマTBが使用される。イントラ・ピクチャ予測されるCUの場合、（CBの中又は外で）最も近い隣接TBの復号化されたサンプルが、イントラ・ピクチャ予測の参照データとして使用される。
2．2．2．要約
四分木の深度増加に基づいて、1つのCTUは複数のCUに再帰的に分割されることが可能である。図3A及び3Bに示されるように、正方形のCB及びTBパーティショニングのみが指定され、ブロックは再帰的にクオーターに分割されることが可能である。
四分木の深度増加に基づいて、1つのCTUは複数のCUに再帰的に分割されることが可能である。図3A及び3Bに示されるように、正方形のCB及びTBパーティショニングのみが指定され、ブロックは再帰的にクオーターに分割されることが可能である。
モード選択はCUレベルで決定される。動き情報、イントラ予測モードのような、選択されたモードに応じたサイド情報は、PUレベルでシグナリング化される。残差はTUレベルでシグナリングされる。
1つのPUは、インター・コーディングされるブロックの場合はCUより大きくなることはできず、1つのPUは、イントラ・コーディングされるブロックの場合はCUに等しい。
TUは、インター・コーディングされたブロックではPUを超える可能性があるが、イントラ・コーディングされたブロックではPUに等しい。
2．3．JEMにおける大きなCTUを伴う四分木プラス二分木ブロック構造
HEVCを越える将来的なビデオ・コーディング技術を探求するため、2015年に共同ビデオ探査チーム（JVET）がVCEGとMPEGにより共同で設立された。それ以来、JVETによって多くの新しい方法が採用され、共同探索モデル（JEM）と名付けられた参照ソフトウェアに組み込まれている。
HEVCを越える将来的なビデオ・コーディング技術を探求するため、2015年に共同ビデオ探査チーム（JVET）がVCEGとMPEGにより共同で設立された。それ以来、JVETによって多くの新しい方法が採用され、共同探索モデル（JEM）と名付けられた参照ソフトウェアに組み込まれている。
2．3．1．四分木プラス二分木（QTBT）ブロック・パーティショニング構造
HEVCとは異なり、QTBTブロック構造は、複数のパーティション・タイプの概念を取り除き、即ちCU、PU、TUの概念の区別を取り除き、CUパーティション形状の多くの柔軟性をサポートする。QTBTブロック構造では、CUは正方形又は長方形の何れかの形状を有することが可能である。図5A-5Eに示されるように、コーディング・ツリー・ユニット（CTU）は、先ず四分木構造によってパーティション化される。四分木リーフ・ノードは、二分木ツリー構造によって更にパーティション化される。二分木分割には、対称的な水平分割と対称的な垂直分割の2種類の分割が存在し得る。二分木リーフ・ノードは、コーディング・ユニット（CU）と呼ばれ、そのセグメンテーションは、それ以上のパーティショニングを行わずに、予測及び変換処理に使用される。これは、CU、PU、TUがQTBTコーディング・ブロック構造において同じブロック・サイズを有することを意味する。JEMでは、CUはしばしば、異なる色成分のコーディング・ブロック（CB）を含み、4:2:0クロマ・フォーマットのP及びBスライスの場合、1つのCUは、1つのルマCBと2つのクロマCBを含み、しばしば単一成分のCBを含み、例えば、1つのCUは、Iスライスの場合に、1つのルマCBのみ又は2つのクロマCBのみを含む。
HEVCとは異なり、QTBTブロック構造は、複数のパーティション・タイプの概念を取り除き、即ちCU、PU、TUの概念の区別を取り除き、CUパーティション形状の多くの柔軟性をサポートする。QTBTブロック構造では、CUは正方形又は長方形の何れかの形状を有することが可能である。図5A-5Eに示されるように、コーディング・ツリー・ユニット（CTU）は、先ず四分木構造によってパーティション化される。四分木リーフ・ノードは、二分木ツリー構造によって更にパーティション化される。二分木分割には、対称的な水平分割と対称的な垂直分割の2種類の分割が存在し得る。二分木リーフ・ノードは、コーディング・ユニット（CU）と呼ばれ、そのセグメンテーションは、それ以上のパーティショニングを行わずに、予測及び変換処理に使用される。これは、CU、PU、TUがQTBTコーディング・ブロック構造において同じブロック・サイズを有することを意味する。JEMでは、CUはしばしば、異なる色成分のコーディング・ブロック（CB）を含み、4:2:0クロマ・フォーマットのP及びBスライスの場合、1つのCUは、1つのルマCBと2つのクロマCBを含み、しばしば単一成分のCBを含み、例えば、1つのCUは、Iスライスの場合に、1つのルマCBのみ又は2つのクロマCBのみを含む。
QTBTパーティショニング方式に対して以下のパラメータが定義される。
－ CTU size：四分木のルート・ノード・サイズ（例えば、HEVCにおけるものと同じ概念）
－ MinQTSize：最小許容四分木リーフ・ノード・サイズ
－ MaxBTSize：最大許容二分木ルート・ノード・サイズ
－ MaxBTDepth：最大許容二分木深度
－ MinBTSize：最小許容二分木リーフ・ノード・サイズ
－ CTU size：四分木のルート・ノード・サイズ（例えば、HEVCにおけるものと同じ概念）
－ MinQTSize：最小許容四分木リーフ・ノード・サイズ
－ MaxBTSize：最大許容二分木ルート・ノード・サイズ
－ MaxBTDepth：最大許容二分木深度
－ MinBTSize：最小許容二分木リーフ・ノード・サイズ
QTBTパーティショニング構造の一例では、CTUサイズは128×128ルマ・サンプルとして、クロマ・サンプルの対応する2つの64×64ブロックとともに設定され、MinQTSizeは16×16に設定され、MaxBTSizeは64×64に設定され、MinBTSizeは（幅と高さの両方に対して）4×4に設定され、MaxBTDepthは4に設定される。四分木パーティショニングは、四分木リーフ・ノードを生成するために先ずCTUに適用される。四分木リーフ・ノードは、16×16（即ち、MinQTSize）から128×128（即ち、CTUサイズ）までのサイズを有する可能性がある。リーフ四分木ノードが128×128である場合、サイズがMaxBTSize （即ち、64×64）を超えているので、二分木によって更に分割することはできない。それ以外の場合、リーフ四分木ノードは、二分木によって更にパーティション化されることが可能である。従って、四分木リーフ・ノードは、二分木のルート・ノードでもあり、二分木の深さを0として有する。二分木の深さがMaxBTDepth（即ち、4）に到達している場合、それ以上の分割は考慮されない。二分木ノードがMinBTSize（即ち4）に等しい幅を有する場合、それ以上の水平分割は考慮されない。同様に、二分木ノードがMinBTSizeに等しい高さを有する場合、それ以上の垂直分割は考慮されない。二分木のリーフ・ノードは、それ以上のパーティショニングによらず、予測及び変換処理によって更に処理される。JEMでは、最大CTUサイズは256×256ルマ・サンプルである。
図4AはQTBTを使用するブロック・パーティショニングの例を示し、図4Bは対応するツリー表現を示す。実線は四分木分割を示し、点線は二分木分割を示す。二分木の各分割（即ち、非リーフ）ノードでは、どの分割タイプ（即ち、水平又は垂直）が使用されるかを示すために、1つのフラグがシグナリングされ、0は水平分割を示し、1は垂直分割を示す。四分木分割の場合、等しいサイズの4つのサブ・ブロックを生成するために、四分木分割は常に水平及び垂直双方にブロックを分割するので、分割タイプを指定する必要はない。
更に、QTBT方式はルマとクロマについて別々のQTBT構造を有する機能をサポートする。現在、P及びBスライスに関し、1つのCTUにおけるルマ及びクロマCTBは同じQTBT構造を共有する。しかしながら、Iスライスでは、ルマCTBはQTBT構造によってCU（複数）にパーティション化され、クロマCTBは別のQTB構造によってクロマCU（複数）にパーティション化される。これは、Iスライス内のCUがルマ成分のコーディング・ブロック、又は2つのクロマ成分のコーディング・ブロックを含み、P又はBスライス内のCUが3つの色成分すべてのコーディング・ブロックを含むことを意味する。
HEVCでは、小さなブロックに対するインター予測は、動き補償のメモリ・アクセスを減らすために制限され、その結果、双－予測は4×8及び8×4ブロックに関してサポートされておらず、インター予測は4×4ブロックに関してサポートされていない。JEMのQTBTでは、これらの制約が取り除かれる。
2．3．2．QTBTの要約
四分木又は二分木の深さの増加に基づいて、1つのCTUは複数のCUに再帰的に分割される可能性がある。正方形及び長方形のCB（幅/高さが1/2又は2に等しい）が指定される。
四分木又は二分木の深さの増加に基づいて、1つのCTUは複数のCUに再帰的に分割される可能性がある。正方形及び長方形のCB（幅/高さが1/2又は2に等しい）が指定される。
モード選択はCUレベルで決定される。PU及びTUは常にCUに等しい。
2．4 VCCに関する複数タイプ・ツリー（Multiple type trees，MTT）
2．4．1 提案
提案されるように、四分木と二分木以外のツリー・タイプがサポートされる。実装では、図5D及び5Eに示すように、更に2つの三分木（TT）パーティション、即ち、水平及び垂直センター・サイド・トリプル・ツリーが導入される。
2．4．1 提案
提案されるように、四分木と二分木以外のツリー・タイプがサポートされる。実装では、図5D及び5Eに示すように、更に2つの三分木（TT）パーティション、即ち、水平及び垂直センター・サイド・トリプル・ツリーが導入される。
2つのレベルのツリー、領域ツリー（四分木）と予測ツリー（二分木又は三分木）が存在する。CTUは先ず領域ツリー（RT）によってパーティション化される。RTリーフは、予測ツリー（PT）を用いて更に分割される可能性がある。PTリーフは、最大PT深度に達するまで、PTにより更に分割される可能性がある。PTリーフは基本コーディング・ユニットである。それは便宜的に依然としてCUと呼ばれる。CUを更に分割することはできない。予測と変換は、ともにJEMと同様にCUに適用される。パーティション構造全体は「複数タイプ・ツリー（multiple-type-tree）」と名付けられる。
2．4．2．VVCにおけるパーティション
異なるパーティション・ツリーの使用法を指定するために、VVCでは幾つかのシンタックス要素が定義され／シグナリングされる。
異なるパーティション・ツリーの使用法を指定するために、VVCでは幾つかのシンタックス要素が定義され／シグナリングされる。
例えば：
－ オフセットmaxMttDepthを伴う最大マルチ・タイプ・ツリー深度
－ 最大二分木サイズmaxBtSize
－ MinBtSizeY
－ 最小二分木サイズmaxBtSize
－ 最大三分木サイズmaxTtSize
－ オフセットmaxMttDepthを伴う最大マルチ・タイプ・ツリー深度
－ 最大二分木サイズmaxBtSize
－ MinBtSizeY
－ 最小二分木サイズmaxBtSize
－ 最大三分木サイズmaxTtSize
2．4．2．1．BT及びTTの使用制限
2．4．2．1．1．変数定義
log2_ctu_size_minus2，log2_min_luma_coding_block_size_minus2を、SPSでシグナリングすることが可能である。
2．4．2．1．1．変数定義
log2_ctu_size_minus2，log2_min_luma_coding_block_size_minus2を、SPSでシグナリングすることが可能である。
log2_ctu_size_minus2プラス2は、各CTUのルマ・コーディング・ツリー・ブロック・サイズを指定する。
log2_min_luma_coding_block_size_minus2プラス2は、最小ルマ・コーディング・ブロック・サイズを指定する。
変数CtbLog2SizeY，CtbSizeY，MinCbLog2SizeY，MinCbSizeY，MinTbLog2SizeY，MaxTbLog2SizeY，MinTbSizeY，MaxTbSizeY，PicWidthInCtbsY，PicHeightInCtbsY，PicSizeInCtbsY，PicWidthInMinCbsY，PicHeightInMinCbsY，PicSizeInMinCbsY，PicSizeInSamplesY，PicWidthInSamplesC及びPicHeightInSamplesCは、次のようにして導出される：
CtbLog2SizeY = log2_ctu_size_minus2 + 2
CtbSizeY = 1 << CtbLog2SizeY
MinCbLog2SizeY = log2_min_luma_coding_block_size_minus2 + 2
MinCbSizeY = 1 << MinCbLog2SizeY
MinTbLog2SizeY = 2
MaxTbLog2SizeY = 6
MinTbSizeY = 1 << MinTbLog2SizeY
MaxTbSizeY = 1 << MaxTbLog2SizeY
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
CtbLog2SizeY = log2_ctu_size_minus2 + 2
CtbSizeY = 1 << CtbLog2SizeY
MinCbLog2SizeY = log2_min_luma_coding_block_size_minus2 + 2
MinCbSizeY = 1 << MinCbLog2SizeY
MinTbLog2SizeY = 2
MaxTbLog2SizeY = 6
MinTbSizeY = 1 << MinTbLog2SizeY
MaxTbSizeY = 1 << MaxTbLog2SizeY
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
2．4．2．1．2．許容される二分割プロセス
このプロセスに対する入力は以下のとおりである：
－ 二分割モードbtSplit,
－ コーディング・ブロック幅cbWidth,
－ コーディング・ブロック高さcbHeight,
－ ピクチャの左上ルマ・サンプルに対する、対象のコーディング・ブロックの左上ルマ・サンプルの位置（x0，y0）,
－ マルチ・タイプ・ツリー深度mttDepth,
－ オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth,
－ 最大二分木サイズmaxBtSize,
－ パーティション・インデックスpartIdx。
このプロセスに対する入力は以下のとおりである：
－ 二分割モードbtSplit,
－ コーディング・ブロック幅cbWidth,
－ コーディング・ブロック高さcbHeight,
－ ピクチャの左上ルマ・サンプルに対する、対象のコーディング・ブロックの左上ルマ・サンプルの位置（x0，y0）,
－ マルチ・タイプ・ツリー深度mttDepth,
－ オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth,
－ 最大二分木サイズmaxBtSize,
－ パーティション・インデックスpartIdx。
このプロセスの出力は、変数allowBtSplitである。
表1 btSplitに基づくparallelTtSplit及びcbSizeの仕様
表1 btSplitに基づくparallelTtSplit及びcbSizeの仕様
変数parallelTtSplit及びcbSizeは、表1で指定されるように導出される。
異なる実施形態では、変数allowBtSplit（例えば、ブール代数の真又は偽の値をとる分割変数）は、様々な条件に従うか又はそれに基づくことが可能である。これらの条件を使用して、この変数の値は次のようにして導出することが可能である：
－ 以下の条件のうちの1つ以上が真である場合に、allowBtSplitはFALSEに等しく設定される：
//許容されるBTブロック・サイズ及び許容される最大MTT深さ条件に従って
－ cbSizeはMinBtSizeY以下であること
－ cbWidthはmaxBtSizeより大きいこと
－ cbHeightはmaxBtSizeより大きいこと
－ cbHeightはmaxBtSizeより大きいこと
－ mttDepthはmaxMttDepth以下であること
－ それ以外の場合に、以下の全ての条件が真である場合に、allowBtSplitはFALSEに等しく設定される
//ピクチャ境界（下ピクチャ境界、右下ピクチャ境界に関して垂直BTなし）条件に従って
－ btSplitはSPLIT_BT_VERに等しいこと
－ y0 + cbHeightはpic_height_in_luma_samplesより大きいこと
－ それ以外の場合に、以下の全ての条件が真である場合に、allowBtSplitはFALSEに等しく設定される
//ピクチャ境界に従って（右下ピクチャ境界に関して水平BTなし）
－ btSplitはSPLIT_BT_HORに等しいこと
－ x0 + cbWidthはpic_width_in_luma_samplesより大きいこと
－ y0 + cbHeightはpic_height_in_luma_samples以下であること
－ それ以外の場合、以下の全ての条件が真である場合に、allowBtSplitはFALSEに等しく設定される
//親TT分割方向（例えば、垂直TTに関し、ミドル・パーティションについて垂直BTなし；水平TTに関し、ミドル・パーティションについて水平BTなし）条件に従ってTT分割インデックス1（ミドル・パーティション）を決定する
－ mttDepthはより大きいこと
－ partIdxは1に等しいこと
－ MttSplitMode[x0][y0][mttDepth-1]はparallelTtSplitに等しいこと
－ それ以外の場合、以下の全ての条件が真である場合に、allowBtSplitはFALSEに等しく設定される
//最大許容変換サイズ（例えば、MaxTbSizeYが64に等しい場合、64×128に関し、垂直BTなしであり；128×64に関し、水平BTなしである）条件に従って
－ btSplitはSPLIT_BT_VERに等しいこと
－ cbWidthはMaxTbSizeY以下であること
－ cbHeightはMaxTbSizeYより大きいこと
－ それ以外の場合、以下の全ての条件が真である場合に、allowBtSplitはFALSEに等しく設定される
－ btSplitはSPLIT_BT_HORに等しいこと
－ cbWidthはMaxTbSizeYより大きいこと
－ cbHeightはMaxTbSizeY以下であること
－ それ以外の場合、allowBtSplitはTRUEに等しく設定される。
－ 以下の条件のうちの1つ以上が真である場合に、allowBtSplitはFALSEに等しく設定される：
//許容されるBTブロック・サイズ及び許容される最大MTT深さ条件に従って
－ cbSizeはMinBtSizeY以下であること
－ cbWidthはmaxBtSizeより大きいこと
－ cbHeightはmaxBtSizeより大きいこと
－ cbHeightはmaxBtSizeより大きいこと
－ mttDepthはmaxMttDepth以下であること
－ それ以外の場合に、以下の全ての条件が真である場合に、allowBtSplitはFALSEに等しく設定される
//ピクチャ境界（下ピクチャ境界、右下ピクチャ境界に関して垂直BTなし）条件に従って
－ btSplitはSPLIT_BT_VERに等しいこと
－ y0 + cbHeightはpic_height_in_luma_samplesより大きいこと
－ それ以外の場合に、以下の全ての条件が真である場合に、allowBtSplitはFALSEに等しく設定される
//ピクチャ境界に従って（右下ピクチャ境界に関して水平BTなし）
－ btSplitはSPLIT_BT_HORに等しいこと
－ x0 + cbWidthはpic_width_in_luma_samplesより大きいこと
－ y0 + cbHeightはpic_height_in_luma_samples以下であること
－ それ以外の場合、以下の全ての条件が真である場合に、allowBtSplitはFALSEに等しく設定される
//親TT分割方向（例えば、垂直TTに関し、ミドル・パーティションについて垂直BTなし；水平TTに関し、ミドル・パーティションについて水平BTなし）条件に従ってTT分割インデックス1（ミドル・パーティション）を決定する
－ mttDepthはより大きいこと
－ partIdxは1に等しいこと
－ MttSplitMode[x0][y0][mttDepth-1]はparallelTtSplitに等しいこと
－ それ以外の場合、以下の全ての条件が真である場合に、allowBtSplitはFALSEに等しく設定される
//最大許容変換サイズ（例えば、MaxTbSizeYが64に等しい場合、64×128に関し、垂直BTなしであり；128×64に関し、水平BTなしである）条件に従って
－ btSplitはSPLIT_BT_VERに等しいこと
－ cbWidthはMaxTbSizeY以下であること
－ cbHeightはMaxTbSizeYより大きいこと
－ それ以外の場合、以下の全ての条件が真である場合に、allowBtSplitはFALSEに等しく設定される
－ btSplitはSPLIT_BT_HORに等しいこと
－ cbWidthはMaxTbSizeYより大きいこと
－ cbHeightはMaxTbSizeY以下であること
－ それ以外の場合、allowBtSplitはTRUEに等しく設定される。
2．4．2．1．3 許容される三分割プロセス
このプロセスに対する入力は以下のとおりである：
－ 三分割モードttSplit
－ コーディング・ブロック幅cbWidth,
－ コーディング・ブロック高さcbHeight,
－ ピクチャの左上ルマ・サンプルに対する、対象のコーディング・ブロックの左上ルマ・サンプルの位置（x0，y0）,
－ マルチ・タイプ・ツリー深度mttDepth,
－ オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth,
－ 最大三分木サイズmaxTtSize。
このプロセスに対する入力は以下のとおりである：
－ 三分割モードttSplit
－ コーディング・ブロック幅cbWidth,
－ コーディング・ブロック高さcbHeight,
－ ピクチャの左上ルマ・サンプルに対する、対象のコーディング・ブロックの左上ルマ・サンプルの位置（x0，y0）,
－ マルチ・タイプ・ツリー深度mttDepth,
－ オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth,
－ 最大三分木サイズmaxTtSize。
このプロセスの出力は、分割変数allowTtSplitである（例えば、ブール代数の真又は偽の値をとる）。分割変数allowTtSplitの値は、様々な条件に従うか又はそれに基づくことが可能である。これらの条件を使用して、この変数の値は次のようにして導出することが可能である：
表2 ttSplitに基づくcbSizeの仕様
変数cbSizeは、表2で指定されるように導出される。
変数allowTtSplitは次のようにして導出される：
－ 以下の条件のうちの1つ以上が真である場合に、allowTtSplitはFALSEに等しく設定される：
//許容されるTTブロック・サイズ及び許容される最大変換サイズ条件に従って
－ cbSizeは2 * MinTtSizeY以下であること
－ cbSize は2 * MinTtSizeY以下であること
－ cbWidthはMin( MaxTbSizeY，maxTtSize )より大きいこと
－ cbHeightはMin( MaxTbSizeY，maxTtSize )より大きいこと
//最大許容MTT深度条件に従って
－ mttDepthはmaxMttDepth以上であること
//それがピクチャ境界条件に位置しているかどうかに従って
－ x0 + cbWidthはpic_width_in_luma_samplesより大きいこと
－ y0 + cbHeightはpic_height_in_luma_samplesより大きいこと
－ それ以外の場合、allowTtSplitはTRUE.に等しく設定される。
2．4．2．1．4．セマンティクス
VVC仕様 条項7．4．5．5．マルチ・タイプ・ツリー・セマンティクス
変数allowSplitBtVer，allowSplitBtHor，allowSplitTtVer，allowSplitTtHorは次のようにして導出される：
－ 変数maxBtSize，maxTtSize及びmaxMttDepthは次のようにして導出される：
－ treeTypeがDUAL_TREE_CHROMAに等しい場合、maxBtSize，maxTtSize及びmaxMttDepthはそれぞれ、MaxBtSizeC，MaxTtSizeC及びMaxMttDepthC + depthOffsetに等しく設定される。
－ それ以外の場合、Otherwise, maxBtSize, maxTtSize and maxMttDepthはそれぞれ、MaxBtSizeY，MaxTtSizeY及びMaxMttDepthY + depthOffsetに等しく設定される。
－ 2．4．2．1．1項で指定されるような許容される二分割プロセスは、二分割モードSPLIT_BT_VER、コーディング・ブロック幅cbWidth、コーディング・ブロック高cbHeight、位置（x0，y0）、現在のマルチ・タイプ・ツリー深度mttDepth、オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth、最大二分木サイズmaxBtSize、及び現在のパーティション・インデックスpartIdxを入力として呼び出され、出力はallowSplitBtVerに割り当てられる。
－ 2．4．2．1．1項で指定されるような許容される二分割プロセスは、二分割モードSPLIT_BT_HOR、コーディング・ブロック高さcbHeight、コーディング・ブロック幅cbWidth、位置（x0，y0）、現在のマルチ・タイプ・ツリー深度mttDepth、オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth、最大二分木サイズmaxBtSize、及び現在のパーティション・インデックスpartIdxを入力として呼び出され、出力はallowSplitBtHorに割り当てられる。
－ 2．4．2．1．3項で指定されるような許容される三分割プロセスは、三分割モードSPLIT_TT_VER、コーディング・ブロック幅cbWidth、コーディング・ブロック高さcbHeight、位置（x0，y0）、現在のマルチ・タイプ・ツリー深度mttDepth、オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth、及び最大三分木サイズmaxTtSizeを入力として呼び出され、出力はallowSplitTtVerに割り当てられる。
－ 2．4．2．1．3項で指定されるような許容される三分割プロセスは、三分割モードSPLIT_TT_HOR、コーディング・ブロック高さcbHeight、コーディング・ブロック幅cbWidth、位置（x0，y0）、現在のマルチ・タイプ・ツリー深度mttDepth、オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth、及び最大三分木サイズmaxTtSizeを入力として呼び出され、出力はallowSplitTtHorに割り当てられる。
－ 以下の条件のうちの1つ以上が真である場合に、allowTtSplitはFALSEに等しく設定される：
//許容されるTTブロック・サイズ及び許容される最大変換サイズ条件に従って
－ cbSizeは2 * MinTtSizeY以下であること
－ cbSize は2 * MinTtSizeY以下であること
－ cbWidthはMin( MaxTbSizeY，maxTtSize )より大きいこと
－ cbHeightはMin( MaxTbSizeY，maxTtSize )より大きいこと
//最大許容MTT深度条件に従って
－ mttDepthはmaxMttDepth以上であること
//それがピクチャ境界条件に位置しているかどうかに従って
－ x0 + cbWidthはpic_width_in_luma_samplesより大きいこと
－ y0 + cbHeightはpic_height_in_luma_samplesより大きいこと
－ それ以外の場合、allowTtSplitはTRUE.に等しく設定される。
2．4．2．1．4．セマンティクス
VVC仕様 条項7．4．5．5．マルチ・タイプ・ツリー・セマンティクス
変数allowSplitBtVer，allowSplitBtHor，allowSplitTtVer，allowSplitTtHorは次のようにして導出される：
－ 変数maxBtSize，maxTtSize及びmaxMttDepthは次のようにして導出される：
－ treeTypeがDUAL_TREE_CHROMAに等しい場合、maxBtSize，maxTtSize及びmaxMttDepthはそれぞれ、MaxBtSizeC，MaxTtSizeC及びMaxMttDepthC + depthOffsetに等しく設定される。
－ それ以外の場合、Otherwise, maxBtSize, maxTtSize and maxMttDepthはそれぞれ、MaxBtSizeY，MaxTtSizeY及びMaxMttDepthY + depthOffsetに等しく設定される。
－ 2．4．2．1．1項で指定されるような許容される二分割プロセスは、二分割モードSPLIT_BT_VER、コーディング・ブロック幅cbWidth、コーディング・ブロック高cbHeight、位置（x0，y0）、現在のマルチ・タイプ・ツリー深度mttDepth、オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth、最大二分木サイズmaxBtSize、及び現在のパーティション・インデックスpartIdxを入力として呼び出され、出力はallowSplitBtVerに割り当てられる。
－ 2．4．2．1．1項で指定されるような許容される二分割プロセスは、二分割モードSPLIT_BT_HOR、コーディング・ブロック高さcbHeight、コーディング・ブロック幅cbWidth、位置（x0，y0）、現在のマルチ・タイプ・ツリー深度mttDepth、オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth、最大二分木サイズmaxBtSize、及び現在のパーティション・インデックスpartIdxを入力として呼び出され、出力はallowSplitBtHorに割り当てられる。
－ 2．4．2．1．3項で指定されるような許容される三分割プロセスは、三分割モードSPLIT_TT_VER、コーディング・ブロック幅cbWidth、コーディング・ブロック高さcbHeight、位置（x0，y0）、現在のマルチ・タイプ・ツリー深度mttDepth、オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth、及び最大三分木サイズmaxTtSizeを入力として呼び出され、出力はallowSplitTtVerに割り当てられる。
－ 2．4．2．1．3項で指定されるような許容される三分割プロセスは、三分割モードSPLIT_TT_HOR、コーディング・ブロック高さcbHeight、コーディング・ブロック幅cbWidth、位置（x0，y0）、現在のマルチ・タイプ・ツリー深度mttDepth、オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth、及び最大三分木サイズmaxTtSizeを入力として呼び出され、出力はallowSplitTtHorに割り当てられる。
2．4．3．サブ・ブロック変換
1に等しいcu_cbf を有するインター予測されるCU の場合、残差ブロック全体又は残差ブロックのサブ・パートが復号されるかどうかを指定するために、cu_sbt_flag がシグナリングされる可能性がある。前者の場合、インター複数変換選択（MTS（EMTとしても知られている））情報が更に解析され、CUの変換タイプを決定する。後者の場合、残差ブロックの一部は、推定適応変換でコーディングされ、残差ブロックの他の部分はゼロ化されて出力される。
1に等しいcu_cbf を有するインター予測されるCU の場合、残差ブロック全体又は残差ブロックのサブ・パートが復号されるかどうかを指定するために、cu_sbt_flag がシグナリングされる可能性がある。前者の場合、インター複数変換選択（MTS（EMTとしても知られている））情報が更に解析され、CUの変換タイプを決定する。後者の場合、残差ブロックの一部は、推定適応変換でコーディングされ、残差ブロックの他の部分はゼロ化されて出力される。
2．4．3．1．サブ・ブロックTUタイリング
CU間でSBTが使用され場合、SBTタイプ、及びSBT位置情報はビットストリームから更に復号化される。図6に示すように、2つのSBTタイプ及び2つのSBT位置がある。SBT-V（又はSBT-H）の場合、TU幅（又は高さ）はCU幅（又は高さ）の半分、又はCU幅（又は高さ）の1/4に等しく、それは別のフラグでシグナリングされ、結果として2:2分割又は1:3/3:1分割となる。2:2分割は二分木（BT）分割のようなものであり、1:3/3:1分割は非対称二分木（ABT）分割のようなものである。CUの一辺がルマ・サンプルで8つである場合、この辺に沿って1:3/3:1の分割は許容されない。従って、CUに関して高々8つのSBTモードが存在する。
CU間でSBTが使用され場合、SBTタイプ、及びSBT位置情報はビットストリームから更に復号化される。図6に示すように、2つのSBTタイプ及び2つのSBT位置がある。SBT-V（又はSBT-H）の場合、TU幅（又は高さ）はCU幅（又は高さ）の半分、又はCU幅（又は高さ）の1/4に等しく、それは別のフラグでシグナリングされ、結果として2:2分割又は1:3/3:1分割となる。2:2分割は二分木（BT）分割のようなものであり、1:3/3:1分割は非対称二分木（ABT）分割のようなものである。CUの一辺がルマ・サンプルで8つである場合、この辺に沿って1:3/3:1の分割は許容されない。従って、CUに関して高々8つのSBTモードが存在する。
SBT-V、及びSBT-Hは、幅、高さ共にmaxSbtSize以下であるCUに対して許容される。maxSbtSizeはSPSでシグナリングされる。HD及び4Kシーケンスの場合、エンコーダによりmaxSbtSizeは64として設定され；それ以外の小さな解像度のシーケンスの場合、maxSbtSizeは32として設定される。
2．5 サブ・ブロックの変換タイプ
JVET-M0140では、SBT-V及びSBT-H（常にDCT-2を使用するクロマTB）のルマ変換ブロックに、位置依存性の変換が適用される。SBT‐HとSBT‐Vの2つの位置は、異なるコア変換に関連付けられる。より具体的には、各SBT位置に対する水平及び垂直変換は、図1で指定されている。例えば、SBT-V位置0の水平及び垂直変換はそれぞれDCT-8及びDST-7である。残差TUの一辺が32より大きい場合、対応する変換はDCT-2として設定される。従って、サブ・ブロック変換は、残差ブロックのTUタイリング、cbf、及び水平、垂直変換を共同で指定し、これは、ブロックの主な残差がブロックの片側にある場合のシンタックス・ショートカットと考えられてもよい。
JVET-M0140では、SBT-V及びSBT-H（常にDCT-2を使用するクロマTB）のルマ変換ブロックに、位置依存性の変換が適用される。SBT‐HとSBT‐Vの2つの位置は、異なるコア変換に関連付けられる。より具体的には、各SBT位置に対する水平及び垂直変換は、図1で指定されている。例えば、SBT-V位置0の水平及び垂直変換はそれぞれDCT-8及びDST-7である。残差TUの一辺が32より大きい場合、対応する変換はDCT-2として設定される。従って、サブ・ブロック変換は、残差ブロックのTUタイリング、cbf、及び水平、垂直変換を共同で指定し、これは、ブロックの主な残差がブロックの片側にある場合のシンタックス・ショートカットと考えられてもよい。
ブロック間のSBTにより採用されるパートの概要：
－ 1-d分割（対称又は1/4）
－ 対称である場合、どの半分かをシグナリングし；それ以外は1/4を使用する
－ 残差TUの変換タイプは推定される
3．課題
パーティション・ツリー制約の現在の設計は、全ブロック変換と共通テスト条件の仮定に基づいている。それは以下の課題を有する可能性がある：
i． 1つのパーティション構造に従って分割を有効又は無効にするかどうかは、最大許容変換サイズに依存する。1つのパーティション構造を有効／無効にしようとする動機付けは、主に、より大きなブロック（例えば、128x128）が実装されにくいというハードウェア実装の検討事項に起因する。汎用ビデオ・コーディング（VVC）では、VPDU（仮想パイプライン・データ・ユニット）の概念が採用されており、動き補償のための最大許容ブロックが定義される。現在の共通テスト条件では、VPDUサイズは最大許容変換サイズに等しい。しかしながら、最大許容変換サイズは、シーケンス・パラメータのようなハイ・レベル・シンタックス要素で適応的にシグナリングされる。
ii． 最大許容変換サイズが64x64であると仮定すると、1つのコーディング・ブロックが64x128である場合、垂直BTは許容されない。しかしながら、サブ・ブロック変換の採用に起因して、垂直BTはサブ・ブロック変換サイズ・セット32x64で依然として適用される可能性がある。
iii． サブ・ブロック変換でコーディングされたブロックの境界をどのように扱うかは、当技術分野では対処されていない。
－ 1-d分割（対称又は1/4）
－ 対称である場合、どの半分かをシグナリングし；それ以外は1/4を使用する
－ 残差TUの変換タイプは推定される
3．課題
パーティション・ツリー制約の現在の設計は、全ブロック変換と共通テスト条件の仮定に基づいている。それは以下の課題を有する可能性がある：
i． 1つのパーティション構造に従って分割を有効又は無効にするかどうかは、最大許容変換サイズに依存する。1つのパーティション構造を有効／無効にしようとする動機付けは、主に、より大きなブロック（例えば、128x128）が実装されにくいというハードウェア実装の検討事項に起因する。汎用ビデオ・コーディング（VVC）では、VPDU（仮想パイプライン・データ・ユニット）の概念が採用されており、動き補償のための最大許容ブロックが定義される。現在の共通テスト条件では、VPDUサイズは最大許容変換サイズに等しい。しかしながら、最大許容変換サイズは、シーケンス・パラメータのようなハイ・レベル・シンタックス要素で適応的にシグナリングされる。
ii． 最大許容変換サイズが64x64であると仮定すると、1つのコーディング・ブロックが64x128である場合、垂直BTは許容されない。しかしながら、サブ・ブロック変換の採用に起因して、垂直BTはサブ・ブロック変換サイズ・セット32x64で依然として適用される可能性がある。
iii． サブ・ブロック変換でコーディングされたブロックの境界をどのように扱うかは、当技術分野では対処されていない。
4．例示的な技術及び実施形態
以下に述べる詳細な実施形態は、一般的な概念を説明するための例示として考慮されるべきである。これらの実施形態は狭義に解釈されるべきではない。更に、これらの実施形態は、任意の方法で組み合わせることが可能である。
1．最大許容変換サイズを使用する代わりに、1つのパーティション・ツリーが許容されるかどうかは、VPDUサイズに依存してもよいことが提案される。
a．一例では、ブロック幅がVPDU幅より大きくはなく、ブロック高さがVPDU高さより大きい場合、垂直BTは許容されない。
b．一例では、ブロック幅がVPDU幅よりも大きく、ブロック高さがVPDU高さよりも大きくはない場合、水平BTは許容されない。
c．同様に、TT分割に関し、それは、以下の条件のうちの1つ（又は幾つか＼又は全て）が真である場合には許容されない可能性がある：
－ cbSizeは 2 * MinTtSizeY以下であること
－ cbWidthはMin(VPDUSizeX，maxTtSize )より大きいこと
－ cbHeightはMin(VPDUSizeY，maxTtSize )より大きいこと
ここで、MinTtSizeY及びmaxTtSizeはそれぞれ最小及び最大許容TTサイズを示し、cbWidth及びcbHeightはそれぞれコーディング・ブロックの幅及び高さを示し、VPDUSizeX及びVPDUSizeYはそれぞれVPDU幅及び高さを示す。
d．一例では、VPDU高さはVPDU幅に等しい。
i 一例では、VPDU高さ及び幅の一方のみがエンコーダからデコーダへシグナリングされる。他方はシグナリングされたものに等しく設定される。
ii 別の例では、VPDU高さはVPDU幅に等しくない可能性がある。
a) 一例では、VPDU高さと幅の両方が、エンコーダからデコーダへシグナリングされる。
2．最大許容変換サイズを使用する代わりに、1つのパーティション・ツリーが許容されるかどうかは、パーティション・ツリーに対する最大許容サブ・ブロック変換サイズに依存してもよいことが提案される。
a．一例では、ブロック幅が最大許容変換幅より大きくはなく、ブロック高さが最大許容変換高さより大きい場合、垂直BTは許容されない。
i．代替的に、更に、サブ・ブロック変換が上記の場合に適用されてもよく、即ち、変換は垂直BTに起因して子ブロックの部分に適用される。
ii．一例では、ブロック幅が最大許容変換幅より大きくなく、ブロック高さが最大許容変換高さより大きいが、垂直BT分割に起因するサブ・ブロックが少なくとも1つのサブ・ブロック変換サイズをサポートする場合、垂直BTは許容されてもよい。
iii．一例では、ブロック幅が最大許容変換幅より大きくなく、ブロック高さが最大許容変換高さより大きいが、ブロック高さは最大許容サブ・ブロック変換高さより大きくない場合、垂直BTは許容されてもよい。
iv．代替的に、更に、ブロック幅が最大許容サブ・ブロック変換幅より大きくなく、ブロック高さが最大許容サブ・ブロック変換高さより大きい場合には、垂直BTは許容されない可能性がある。
a) 一例では、特定の最大許容サブ・ブロック変換幅／高さは、垂直BT（V-BT）に関するものである。
v．一例では、V-BTに対する最大許容サブ・ブロック変換幅は、最大許容変換幅の半分又は4分の1、最大許容変換幅であるように定義されてもよい。
vi．一例では、V-BTに対する最大許容サブ・ブロック変換高さは、最大許容変換高さの半分又は4分の1、又は最大許容変換高さより大きいものであるように定義されてもよい。
b．一例では、ブロック幅が最大許容変換幅よりも大きく、ブロック高さが最大許容変換高さよりも大きくない場合でさえ、水平BTは許容される可能性がある。
i．代替的に、更に、サブ・ブロック変換は上記の場合に適用されてもよく、即ち、変換は垂直BTに起因する子ブロックの部分に適用される。
ii．代替的に、更に、ブロック幅が最大許容サブ・ブロック変換幅よりも大きく、ブロック高さが最大許容サブ・ブロック変換高さよりも大きくない場合、水平BTは許容されない。
a) 一例では、特定の最大許容サブ・ブロック変換幅／高さは、水平BT（H-BT）に対するものである。
iii．一例では、V-BTに対する最大許容サブ・ブロック変換幅は、最大許容変換幅の半分又は4分の1、最大許容変換幅であると定義されてもよい。
iv．一例では、V-BTに対する最大許容サブ・ブロック変換高さは、最大許容変換高さの半分又は4分の1、最大許容変換高さであると定義されてもよい。
c．一例では、セットがTx=maximum{最大許容変換幅，最大許容サブ・ブロック幅}，Ty=maximum{最大許容変換高さ，最大許容サブ・ブロック高さ}である場合に、分割が許容されるかどうかは、Tx及び／又はTyに依存してもよいことが提案される。
i．一例では、ブロック幅がTxより大きくなく、ブロック高さがTyより大きい場合、垂直BTは許容されない可能性がある。
ii．ブロック幅がTxよりも大きく、ブロック高さがTyより大きくない場合、水平BTは許容されない。
d．代替的に、更に、そのような方法は、サブ・ブロック変換技術が有効である場合、SPSフラグが真であるような場合に、適用されてもよい。
3．1つのパーティション・ツリーが許容されるかどうかは、VPDUサイズと最大許容変換サイズの両方に依存する可能性がある。
a．代替的に、1つのパーティション・ツリーが許容されるかどうかは、VPDUサイズと最大許容サブ・ブロック変換サイズの両方に依存してもよい。
b．一例では、ブロック幅がf（VPDU幅，最大許容変換幅）より大きくなく、ブロック高さがf（VPDU高さ，最大許容変換高さ）より大きい場合、垂直BTは許容されない。
c．一例では、ブロック幅がf（VPDU幅、最大許容変換幅）より大きく、ブロック高さがf（VPDU高さ，最大許容変換高さ）より大きくない場合、水平BTは許容されない。
d．一例では、関数f（x，y）はx及びyのうちより大きな値を返す。
e．一例では、関数f（x，y）はx及びyのうちより小さな値を返す。
f．一例では、VPDU高さは、VPDU幅に等しい。
g．一例では、最大許容変換幅は最大許容変換高さに等しい。
4．上述のVPDUサイズ（幅と高さを含む）は、例えば64×64のように予め定義されていてもよい。
a．代替的に、それは、SPS／VPS／PPS／PPS／シーケンス・ヘッダ／ピクチャ・ヘッダ／タイル・グループ・ヘッダ／スライス・ヘッダ／CTU行／領域／その他の種類のビデオ処理データ・ユニット内でシグナリングされてもよい。
5．デブロッキング・フィルタ、SAO及び／又はALFのようなフィルタリング・プロセスを適用する仕方は、サブ・ブロック変換サイズに依存してもよいことが、提案される。
a．一例では、サブ・ブロック変換の境界は、デブロッキング・フィルタ・プロセスにおいてフィルタリングされてもよい。
b．一例では、デブロッキング・フィルタの決定（フィルタリングの有無、強い又は弱いフィルタ、どのフィルタを使用するか、フィルタリングされたサンプルにクリッピングを適用する仕方など）は、サンプルがサブ・ブロック変換境界に配置されているかどうかに依存してもよい。
以下に述べる詳細な実施形態は、一般的な概念を説明するための例示として考慮されるべきである。これらの実施形態は狭義に解釈されるべきではない。更に、これらの実施形態は、任意の方法で組み合わせることが可能である。
1．最大許容変換サイズを使用する代わりに、1つのパーティション・ツリーが許容されるかどうかは、VPDUサイズに依存してもよいことが提案される。
a．一例では、ブロック幅がVPDU幅より大きくはなく、ブロック高さがVPDU高さより大きい場合、垂直BTは許容されない。
b．一例では、ブロック幅がVPDU幅よりも大きく、ブロック高さがVPDU高さよりも大きくはない場合、水平BTは許容されない。
c．同様に、TT分割に関し、それは、以下の条件のうちの1つ（又は幾つか＼又は全て）が真である場合には許容されない可能性がある：
－ cbSizeは 2 * MinTtSizeY以下であること
－ cbWidthはMin(VPDUSizeX，maxTtSize )より大きいこと
－ cbHeightはMin(VPDUSizeY，maxTtSize )より大きいこと
ここで、MinTtSizeY及びmaxTtSizeはそれぞれ最小及び最大許容TTサイズを示し、cbWidth及びcbHeightはそれぞれコーディング・ブロックの幅及び高さを示し、VPDUSizeX及びVPDUSizeYはそれぞれVPDU幅及び高さを示す。
d．一例では、VPDU高さはVPDU幅に等しい。
i 一例では、VPDU高さ及び幅の一方のみがエンコーダからデコーダへシグナリングされる。他方はシグナリングされたものに等しく設定される。
ii 別の例では、VPDU高さはVPDU幅に等しくない可能性がある。
a) 一例では、VPDU高さと幅の両方が、エンコーダからデコーダへシグナリングされる。
2．最大許容変換サイズを使用する代わりに、1つのパーティション・ツリーが許容されるかどうかは、パーティション・ツリーに対する最大許容サブ・ブロック変換サイズに依存してもよいことが提案される。
a．一例では、ブロック幅が最大許容変換幅より大きくはなく、ブロック高さが最大許容変換高さより大きい場合、垂直BTは許容されない。
i．代替的に、更に、サブ・ブロック変換が上記の場合に適用されてもよく、即ち、変換は垂直BTに起因して子ブロックの部分に適用される。
ii．一例では、ブロック幅が最大許容変換幅より大きくなく、ブロック高さが最大許容変換高さより大きいが、垂直BT分割に起因するサブ・ブロックが少なくとも1つのサブ・ブロック変換サイズをサポートする場合、垂直BTは許容されてもよい。
iii．一例では、ブロック幅が最大許容変換幅より大きくなく、ブロック高さが最大許容変換高さより大きいが、ブロック高さは最大許容サブ・ブロック変換高さより大きくない場合、垂直BTは許容されてもよい。
iv．代替的に、更に、ブロック幅が最大許容サブ・ブロック変換幅より大きくなく、ブロック高さが最大許容サブ・ブロック変換高さより大きい場合には、垂直BTは許容されない可能性がある。
a) 一例では、特定の最大許容サブ・ブロック変換幅／高さは、垂直BT（V-BT）に関するものである。
v．一例では、V-BTに対する最大許容サブ・ブロック変換幅は、最大許容変換幅の半分又は4分の1、最大許容変換幅であるように定義されてもよい。
vi．一例では、V-BTに対する最大許容サブ・ブロック変換高さは、最大許容変換高さの半分又は4分の1、又は最大許容変換高さより大きいものであるように定義されてもよい。
b．一例では、ブロック幅が最大許容変換幅よりも大きく、ブロック高さが最大許容変換高さよりも大きくない場合でさえ、水平BTは許容される可能性がある。
i．代替的に、更に、サブ・ブロック変換は上記の場合に適用されてもよく、即ち、変換は垂直BTに起因する子ブロックの部分に適用される。
ii．代替的に、更に、ブロック幅が最大許容サブ・ブロック変換幅よりも大きく、ブロック高さが最大許容サブ・ブロック変換高さよりも大きくない場合、水平BTは許容されない。
a) 一例では、特定の最大許容サブ・ブロック変換幅／高さは、水平BT（H-BT）に対するものである。
iii．一例では、V-BTに対する最大許容サブ・ブロック変換幅は、最大許容変換幅の半分又は4分の1、最大許容変換幅であると定義されてもよい。
iv．一例では、V-BTに対する最大許容サブ・ブロック変換高さは、最大許容変換高さの半分又は4分の1、最大許容変換高さであると定義されてもよい。
c．一例では、セットがTx=maximum{最大許容変換幅，最大許容サブ・ブロック幅}，Ty=maximum{最大許容変換高さ，最大許容サブ・ブロック高さ}である場合に、分割が許容されるかどうかは、Tx及び／又はTyに依存してもよいことが提案される。
i．一例では、ブロック幅がTxより大きくなく、ブロック高さがTyより大きい場合、垂直BTは許容されない可能性がある。
ii．ブロック幅がTxよりも大きく、ブロック高さがTyより大きくない場合、水平BTは許容されない。
d．代替的に、更に、そのような方法は、サブ・ブロック変換技術が有効である場合、SPSフラグが真であるような場合に、適用されてもよい。
3．1つのパーティション・ツリーが許容されるかどうかは、VPDUサイズと最大許容変換サイズの両方に依存する可能性がある。
a．代替的に、1つのパーティション・ツリーが許容されるかどうかは、VPDUサイズと最大許容サブ・ブロック変換サイズの両方に依存してもよい。
b．一例では、ブロック幅がf（VPDU幅，最大許容変換幅）より大きくなく、ブロック高さがf（VPDU高さ，最大許容変換高さ）より大きい場合、垂直BTは許容されない。
c．一例では、ブロック幅がf（VPDU幅、最大許容変換幅）より大きく、ブロック高さがf（VPDU高さ，最大許容変換高さ）より大きくない場合、水平BTは許容されない。
d．一例では、関数f（x，y）はx及びyのうちより大きな値を返す。
e．一例では、関数f（x，y）はx及びyのうちより小さな値を返す。
f．一例では、VPDU高さは、VPDU幅に等しい。
g．一例では、最大許容変換幅は最大許容変換高さに等しい。
4．上述のVPDUサイズ（幅と高さを含む）は、例えば64×64のように予め定義されていてもよい。
a．代替的に、それは、SPS／VPS／PPS／PPS／シーケンス・ヘッダ／ピクチャ・ヘッダ／タイル・グループ・ヘッダ／スライス・ヘッダ／CTU行／領域／その他の種類のビデオ処理データ・ユニット内でシグナリングされてもよい。
5．デブロッキング・フィルタ、SAO及び／又はALFのようなフィルタリング・プロセスを適用する仕方は、サブ・ブロック変換サイズに依存してもよいことが、提案される。
a．一例では、サブ・ブロック変換の境界は、デブロッキング・フィルタ・プロセスにおいてフィルタリングされてもよい。
b．一例では、デブロッキング・フィルタの決定（フィルタリングの有無、強い又は弱いフィルタ、どのフィルタを使用するか、フィルタリングされたサンプルにクリッピングを適用する仕方など）は、サンプルがサブ・ブロック変換境界に配置されているかどうかに依存してもよい。
5．追加例の実施形態
5．1．1．1．1．許容される二分割プロセス
このプロセスに対する入力は以下のとおりである：
－ 二分割モードbtSplit,
－ コーディング・ブロック幅cbWidth,
－ コーディング・ブロック高さcbHeight,
－ ピクチャの左上ルマ・サンプルに対する、対象のコーディング・ブロックの左上ルマ・サンプルの位置（x0，y0）,
－ マルチ・タイプ・ツリー深度mttDepth,
－ オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth,
－ 最大二分木サイズmaxBtSize,
－ パーティション・インデックスpartIdx。
5．1．1．1．1．許容される二分割プロセス
このプロセスに対する入力は以下のとおりである：
－ 二分割モードbtSplit,
－ コーディング・ブロック幅cbWidth,
－ コーディング・ブロック高さcbHeight,
－ ピクチャの左上ルマ・サンプルに対する、対象のコーディング・ブロックの左上ルマ・サンプルの位置（x0，y0）,
－ マルチ・タイプ・ツリー深度mttDepth,
－ オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth,
－ 最大二分木サイズmaxBtSize,
－ パーティション・インデックスpartIdx。
このプロセスの出力は、変数allowBtSplitである（例えば、真又は偽の値をとるブール変数）。
以下の全ての条件が真である場合、allowBtSplitはFALSEに等しく設定される：
－ btSplitはSPLIT_BT_VERに等しいこと
－ cbWidthはVPDUSizeY以下であること
－ cbHeightはVPDUSizeYより大きいこと
－ btSplitはSPLIT_BT_VERに等しいこと
－ cbWidthはVPDUSizeY以下であること
－ cbHeightはVPDUSizeYより大きいこと
それ以外の場合に、以下の全ての条件が真である場合、allowBtSplitはFALSEに等しく設定される。
－ btSplitはSPLIT_BT_HORに等しいこと
－ cbWidthはVPDUSizeYより大きいこと
－ cbHeightはVPDUSizeY以下であること
－ btSplitはSPLIT_BT_HORに等しいこと
－ cbWidthはVPDUSizeYより大きいこと
－ cbHeightはVPDUSizeY以下であること
5．1．1．1．2．許容される三分割プロセス
このプロセスに対する入力は以下のとおりである：
－ 三分割モードttSplit
－ コーディング・ブロック幅cbWidth,
－ コーディング・ブロック高さcbHeight,
－ ピクチャの左上ルマ・サンプルに対する、対象のコーディング・ブロックの左上ルマ・サンプルの位置（x0，y0）,
－ マルチ・タイプ・ツリー深度mttDepth,
－ オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth,
－ 最大三分木サイズmaxTtSize。
このプロセスに対する入力は以下のとおりである：
－ 三分割モードttSplit
－ コーディング・ブロック幅cbWidth,
－ コーディング・ブロック高さcbHeight,
－ ピクチャの左上ルマ・サンプルに対する、対象のコーディング・ブロックの左上ルマ・サンプルの位置（x0，y0）,
－ マルチ・タイプ・ツリー深度mttDepth,
－ オフセットを伴う最大マルチ・タイプ・ツリー深度maxMttDepth,
－ 最大三分木サイズmaxTtSize。
このプロセスの出力は、変数allowTtSplitである。
表3 ttSplitに基づくcbSizeの仕様
表3 ttSplitに基づくcbSizeの仕様
変数cbSizeは、表3で指定される情報に基づいて導出することが可能である。
変数allowTtSplitは、様々な条件に基づいて又はそれに従って次のように導出することが可能である：
－ 以下の条件のうちの1つ以上が真である場合に、allowTtSplitはFALSEに等しく設定される：
//許容されるTTブロック・サイズ及び許容される最大変換サイズ条件に従って
－ cbSizeは2 * MinTtSizeY以下であること
－ cbWidthはMin (VPDUSizeX，maxTtSize )より大きいこと
－ cbHeightはMin (VPDUSizeY，maxTtSize )より大きいこと
//最大許容MTT深度条件に従って
－ mttDepthはmaxMttDepth以上であること
//それがピクチャ境界条件に位置しているかどうかに従って
－ x0 + cbWidthはpic_width_in_luma_samplesより大きいこと
－ y0 + cbHeightはpic_height_in_luma_samplesより大きいこと
－ それ以外の場合、allowTtSplitはTRUEに等しく設定される。
－ 以下の条件のうちの1つ以上が真である場合に、allowTtSplitはFALSEに等しく設定される：
//許容されるTTブロック・サイズ及び許容される最大変換サイズ条件に従って
－ cbSizeは2 * MinTtSizeY以下であること
－ cbWidthはMin (VPDUSizeX，maxTtSize )より大きいこと
－ cbHeightはMin (VPDUSizeY，maxTtSize )より大きいこと
//最大許容MTT深度条件に従って
－ mttDepthはmaxMttDepth以上であること
//それがピクチャ境界条件に位置しているかどうかに従って
－ x0 + cbWidthはpic_width_in_luma_samplesより大きいこと
－ y0 + cbHeightはpic_height_in_luma_samplesより大きいこと
－ それ以外の場合、allowTtSplitはTRUEに等しく設定される。
6．開示される技術の実装例
図7はビデオ処理装置700のブロック図である。装置700は、本願で説明される1つ以上の方法を実施するために使用されることが可能である。装置700は、スマートフォン、タブレット、コンピュータ、モノのインターネット（IoT）受信機などで具現化される可能性がある。装置700は、1つ以上のプロセッサ702、1つ以上のメモリ704、及びビデオ処理ハードウェア706を含む可能性がある。プロセッサ702は、本明細書で説明される1つ以上の方法を実施するように構成されてもよい。メモリ（複数のメモリ）704は、本願で説明される方法及び技術を実施するために使用されるデータ及びコードを記憶するために使用されてもよい。ビデオ処理ハードウェア706は、ハードウェア回路において、本明細書で説明される幾つかの技術を実装するために使用することが可能であり、部分的に又は完全に、プロセッサ702（例えば、グラフィックス・プロセッサ・コアGPU又はその他の信号処理回路）の一部分であってもよい。
図7はビデオ処理装置700のブロック図である。装置700は、本願で説明される1つ以上の方法を実施するために使用されることが可能である。装置700は、スマートフォン、タブレット、コンピュータ、モノのインターネット（IoT）受信機などで具現化される可能性がある。装置700は、1つ以上のプロセッサ702、1つ以上のメモリ704、及びビデオ処理ハードウェア706を含む可能性がある。プロセッサ702は、本明細書で説明される1つ以上の方法を実施するように構成されてもよい。メモリ（複数のメモリ）704は、本願で説明される方法及び技術を実施するために使用されるデータ及びコードを記憶するために使用されてもよい。ビデオ処理ハードウェア706は、ハードウェア回路において、本明細書で説明される幾つかの技術を実装するために使用することが可能であり、部分的に又は完全に、プロセッサ702（例えば、グラフィックス・プロセッサ・コアGPU又はその他の信号処理回路）の一部分であってもよい。
本明細書において、「ビデオ処理」という用語は、ビデオ符号化、ビデオ復号化、ビデオ圧縮、又はビデオ解凍を指す可能性がある。例えば、ビデオ圧縮アルゴリズムは、ビデオのピクセル表現から、対応するビットストリーム表現へ、又はその逆への変換の間に適用されてもよい。現在のビデオ・ブロックのビットストリーム表現は、例えば、シンタックスによって定義されるように、ビットストリーム内の異なる場所に分散されるか又は共存するビットに対応する可能性がある。例えば、マクロブロックは、変換されコーディングされたエラーの残差値の観点から、また、ビットストリームのヘッダ及びその他のフィールド内のビットを使用して符号化されてもよい。
本開示の方法及び技術は、本明細書で開示される技術の使用を可能にすることによって、スマートフォン、ラップトップ、デスクトップ及び類似のデバイスのようなビデオ処理デバイス内に組み込まれるビデオ・エンコーダ及び／又はデコーダの実施形態に有益であることが理解されるであろう。
図8は、ビデオ処理の例示的な方法800のフローチャートである。方法800は、810において、ビジュアル・メディア・データのビデオ・ブロックとビデオ・ブロックの対応するビットストリームとの間の変換のためのビデオ・ブロックに関連する分割変数の値を（少なくとも部分的に、仮想パイプライン・データ・ユニット（VPDU）のサイズ及びパーティショニング・ツリーの1つ以上のパラメータに基づいて）計算することを含み、VPDUのサイズは、高さ及び幅を含む。また、方法800は、820において、分割変数の値がブーリアン真である旨の判定に応じて、パーティショニング・ツリーに従ってビデオ・ブロックの分割を許容することを含む。方法800は、更に、830において、分割変数の値がブーリアン偽であり、ビデオ・ブロックの分割を許可しない旨の判定に応じて、ビデオ・ブロックの分割を許可しないことを含む。本願で使用されているようにビデオ・ブロックという用語は、コーディング・ブロック、予測ブロック、マクロブロックなどを含む（但し、これらに限定されない）任意の形態のメディア・ブロックに適用することが可能である。更に、様々な実施形態において、これらのブロックは、イントラ又はインター・ブロックであるとすることが可能である。
図9は、ビデオ処理の例示的な方法900のフローチャートである。方法900は、910において、少なくとも部分的に仮想パイプライン・データ・ユニット（VPDU）のサイズに基づいて、パーティション・ツリーに関連するパーティションのタイプがビデオ・ブロックに対して許容されるか又は許容されないかを決定することを含み、VPDUサイズはVPDU高さ及びVPDU幅を含み、パーティションのタイプを許容しないことに応じて、パーティション・タイプの指示はビットストリーム内に存在しない。
図10は、ビデオ処理の例示的な方法1000のフローチャートである。方法1000は、1010において、少なくとも部分的に最大許容サブ・ブロック変換サイズに基づいて、パーティション・ツリーに関連するパーティションのタイプがビデオ・ブロックに対して許容されるか又は許容されないかを決定することを含み、最大許容サブ・ブロック変換サイズは、最大許容サブ・ブロック変換高さと最大許容サブ・ブロック変換幅とを含み、パーティションのタイプを許容しないことに応じて、パーティション・タイプの指示はビットストリーム内に存在しない。
図11は、ビデオ処理の例示的な方法1100のフローチャートである。方法1100は、1110において、少なくとも部分的に最大許容変換サイズと仮想パイプライン・データ・ユニット（VPDU）のサイズに基づいて、又は少なくとも部分的に最大許容サブ・ブロック変換サイズと仮想パイプライン・データ・ユニット（VPDU）のサイズに基づいて、パーティション・ツリーに関連するパーティションのタイプがビデオ・ブロックに対して許容されるか又は許容されないかを決定することを含み、VPDUサイズはVPDU高さとVPDU幅とを含み、最大許容変換サイズは最大許容変換高さと最大許容変換幅とを含み、パーティションのタイプを許容しないことに応じて、パーティション・タイプの指示はビットストリーム内に存在しない。
図12は、ビデオ処理の例示的な方法1200のフローチャートである。方法1200は、1210において、サブ・ブロック変換が適用される場合に、サンプルはサブ・ブロック変換境界に位置するかどうかを判定するステップと；1220において、サンプルはサブ・ブロック変換境界に位置すると判定された場合に、デブロッキング・フィルタ・プロセスを適用するステップと；1230において、ビデオ及びビデオのビットストリーム表現の間で変換を実行するステップとを含む。
図13は、ビデオ処理の例示的な方法1300のフローチャートである。方法1300は、1310において、サブ・ブロック変換が適用されるかどうかに基づいて、フィルタリング・プロセスをビデオ・ブロックに適用する仕方を決定するステップと；1320において、当該決定に基づいてフィルタリング・プロセスを実行するステップと；1330において、ビデオ・ブロック及びビデオのビットストリーム表現の間で変換を実行するステップとを含む。
幾つかの実施形態は以下の条項に基づくフォーマットを利用して説明することができる。
1．ビデオ処理方法であって、
サブ・ブロック変換が適用される場合に、サンプルはサブ・ブロック変換境界に位置するかどうかを判定するステップと；
サンプルはサブ・ブロック変換境界に位置すると判定された場合に、デブロッキング・フィルタ・プロセスを適用するステップと；
ビデオ及びビデオのビットストリーム表現の間で変換を実行するステップとを含む方法。
2．条項1の方法であって、サンプルはサブ・ブロック変換境界に位置することに基づいて、強デブロッキング・フィルタを適用することを決定するステップを更に含む方法。
3．条項1の方法であって、サンプルはサブ・ブロック変換境界に位置することに基づいて、弱デブロッキング・フィルタを適用することを決定するステップを更に含む方法。
4．条項1の方法であって、サンプルはサブ・ブロック変換境界に位置することに基づいて、適用されるべきフィルタ・タイプを決定するステップを更に含む方法。
5．条項1の方法であって、フィルタリングされたサンプルにクリッピングを適用する仕方を決定するステップを更に含む方法。
6．ビデオ処理方法であって、
サブ・ブロック変換が適用されるかどうかに基づいて、フィルタリング・プロセスをビデオ・ブロックに適用する仕方を決定するステップと；
当該決定に基づいてフィルタリング・プロセスを実行するステップと；
ビデオ・ブロック及びビデオのビットストリーム表現の間で変換を実行するステップとを含む方法。
7．条項6の方法であって、フィルタリング・プロセスは、デブロッキング・フィルタ・プロセス、サンプル適応オフセット（SAO）フィルタ・プロセス、又は適応ループ・フィルタ（ALF）プロセスのうちの少なくとも1つを含む、方法。
8．条項7の方法であって、サブ・ブロック変換の境界は、デブロッキング・フィルタ・プロセスにおける変換境界として処理される、方法。
9．条項8の方法であって、サブ・ブロック変換が適用される場合、少なくともサブ・ブロック変換の境界がデブロッキング・フィルタ・プロセスにおいてフィルタリングされる、方法。
10．条項1-9のうちの何れかの方法であって、サブ・ブロック変換がビデオ・ブロックに適用される場合、ビデオ・ブロックは1つより多いサブ・ブロックに分割され、サブ・ブロックのうち唯1つが非ゼロの変換係数を有し、その他は有しておらず、変換係数は唯1つのサブ・ブロックに対してシグナリングされるだけである、方法。
11．条項1-10のうちの1つ以上に記載された方法を実行するように構成されたプロセッサを含むビデオ復号化装置。
12．条項1-10のうちの1つ以上に記載された方法を実行するように構成されたプロセッサを含むビデオ復号化装置。
13．コンピュータ・コードを記憶したコンピュータ・プログラム製品であって、そのコードは、プロセッサにより実行されると、条項1-10のうちの何れかに記載された方法をプロセッサに実行させる、コンピュータ・プログラム製品。
14．プロセッサと命令を伴う非一時的なメモリとを含むビデオ・システムにおける装置であって、その命令はプロセッサにより実行されると、条項1-10のうちの何れかに記載された方法をプロセッサに実行させる、装置。
本明細書で説明されている開示された及びその他の解決策、具体例、実施形態、モジュール、及び機能的動作は、デジタル電子回路において、又は、本明細書で開示される構造及びそれらの構造的等価物を含むコンピュータ・ソフトウェア、ファームウェア、又はハードウェアにおいて、或いはそれらの1つ以上の組み合わせにおいて実施することが可能である。開示された及びその他の実施形態は、1つ以上のコンピュータ・プログラム製品として、即ち、データ処理装置による実行のため又はデータ処理装置の動作を制御するために、コンピュータ読み取り可能な媒体にエンコードされたコンピュータ・プログラム命令の1つ以上のモジュールとして、実施することが可能である。コンピュータ読み取り可能な媒体は、機械読み取り可能なストレージ装置、機械読み取り可能なストレージ基板、メモリ装置、機械読み取り可能な伝搬する信号に影響を与える物質の組成物、又はそれらの1つ以上の組み合わせである可能性がある。用語「データ処理装置」は、例えば、プログラマブル・プロセッサ、コンピュータ、又は複数のプロセッサ又はコンピュータを含む、データを処理するための装置、デバイス、及びマシンの全てを包含する。装置は、ハードウェアに加えて、対象となるコンピュータ・プログラムの実行環境を成すコード、例えば、プロセッサ・ファームウェア、プロトコル・スタック、データベース管理システム、オペレーティング・システム、又はそれらの1つ以上の組み合わせを構成するコードを含むことが可能である。伝搬する信号は、人為的に生成された信号であり、例えば、適切な受信装置への伝送に備えて情報を符号化するために生成された機械生成による電気的、光学的、又は電磁的な信号である。
コンピュータ・プログラム（プログラム、ソフトウェア、ソフトウェア・アプリケーション、スクリプト、又はコードとしても知られている）は、コンパイルされる又は解釈される言語を含む任意の形式のプログラミング言語で書かれることが可能であり、それは、スタンド・アロン・プログラムとして、又はモジュール、コンポーネント、サブルーチン、若しくはその他のユニット（コンピューティング環境での使用に適したもの）として、任意の形式で配備されることが可能である。コンピュータ・プログラムは、必ずしもファイル・システム内のファイルに対応するものではない。プログラムは、他のプログラム又はデータを保持するファイルの一部分（例えば、マークアップ言語文書に記憶される1つ以上のスクリプト）、問題としているプログラムに専用の単一ファイル、又は複数のコーディネートされたファイル（例えば、1つ以上のモジュール、サブ・プログラム、又はコードの一部分を記憶するファイル）に、記憶されることが可能である。コンピュータ・プログラムは、1つのコンピュータ又は複数のコンピュータ上で実行されるように配備されることが可能であり、複数のコンピュータは、1つのサイトに配置されるか、又は複数のサイトに分散され、通信ネットワークによって相互接続される。
本明細書で説明されるプロセス及び論理フローは、1つ以上のコンピュータ・プログラムを実行する1つ以上のプログラマブル・プロセッサによって実行され、入力データを処理して出力を生成することにより機能を実行することが可能である。プロセス及び論理フローはまた、例えばFPGA（field programmable gate array）又はASIC（application specific integrated circuit）のような特殊目的論理回路によって実行されることも可能であり、装置はそれらとして実施されることも可能である。
コンピュータ・プログラムの実行に適したプロセッサは、例えば、汎用及び専用マイクロプロセッサの両方、及び任意の種類のデジタル・コンピュータの任意の1つ以上のプロセッサを含む。一般に、プロセッサは、リード・オンリ・メモリ又はランダム・アクセス・メモリ又はその両方から命令及びデータを受け取るであろう。コンピュータの必須要素は、命令を実行するためのプロセッサと、命令及びデータを記憶するための1つ以上のメモリ・デバイスである。一般に、コンピュータはまた、データを記憶するための1つ以上の大容量ストレージ・デバイス、例えば、磁気的な、磁気光学的なディスク、又は光ディスクからデータを受信したり、そこにデータを転送したり、又は双方のためにそれらを包含し、又はそれらに動作可能に結合されるであろう。しかしながら、コンピュータは、そのようなデバイスを有することを必須としない。コンピュータ・プログラム命令及びデータを記憶するのに適したコンピュータ読み取り可能な媒体は、半導体メモリ・デバイス、例えば、EPROM、EEPROM、及びフラッシュ・メモリ・デバイス；磁気ディスク、例えば、内部ハード・ディスク又はリムーバブル・ディスク；磁気光学ディスク；及びCD ROM、DVD-ROMディスクを含む、あらゆる形式の不揮発性メモリ、媒体及びメモリ・デバイスを含む。プロセッサ及びメモリは、特殊目的論理回路によって補足されるか、又はそれらに組み込まれることが可能である。
この特許文献は、多くの詳細を含んでいるが、これらは、何らかの対象事項又はクレームされる可能性のあるものの範囲に関する限定として解釈されるべきではなく、特定の技術の特定の実施形態に特有である可能性のある特徴の説明として解釈されるべきである。別々の実施形態の文脈でこの特許文献で説明されている特定の特徴は、単一の実施形態で組み合わせて実施することも可能である。逆に、単一の実施形態の文脈で説明される種々の特徴は、複数の実施形態で別々に、又は任意の適切なサブコンビネーションで実施されることも可能である。更に、特徴は、特定の組み合わせにおいて作用するものとして上述され、当初にはそのようにクレームされさえもするかもしれないが、クレームされる組み合わせからの1つ以上の特徴は、場合によっては、組み合わせから切り出されることが可能であり、クレームされる組み合わせは、サブコンビネーション又はサブコンビネーションの変形に向けられることが可能である。
同様に、動作は特定の順序で図面に描かれているが、これは、所望の結果を達成するために、そのような動作が図示の特定の順序で又は連続的な順序で実行されなければならないこと、或いは図示の全ての動作が実行されなければならないこと、を要求するものとして理解されるべきではない。更に、この特許文献で説明される実施形態における種々のシステム構成要素の分け方は、全ての実施形態においてこのような分け方を要求するものとして理解されるべきではない。
少数の実装及び具体例のみが記述されており、他の実装、拡張、及び変形が、本特許文献で説明及び図示されているものに基づいて行われることが可能である。
Claims (14)
- ビデオ処理方法であって：
サンプルが所定の変換境界に位置するかどうかに基づいて、ビデオの現在のビデオ・ユニットのサンプルに対してフィルタリング・プロセスを適用するかどうか及び適用の仕方を決定するステップと；
前記決定に基づいて、前記ビデオ及び前記ビデオのビットストリームの間で変換を実行するステップと；
を含み、前記所定の変換境界は第１変換モードに基づいて決定され、前記第１変換モードでは、変換領域は複数のサブ変換領域に分割され、唯１つのサブ変換領域が非ゼロ変換係数を有し、
前記第１変換モードはインター予測モードの変換領域に許容されるだけである、方法。 - 前記フィルタリング・プロセスは、前記サンプルが前記所定の変換境界に位置することに基づいて適用される、請求項１に記載の方法。
- 前記サンプルのうちの少なくとも１つは非ゼロである、請求項１又は２に記載の方法。
- 前記非ゼロ変換係数を有するサブ変換領域のサイズは、前記複数のサブ変換領域の他のサブ変換領域以下である、請求項１－３のうちの何れか１項に記載の方法。
- 前記所定の変換境界のうちの少なくとも１つの境界は、前記サンプルが前記所定の変換境界に位置することに基づいて、フィルタリング・プロセスでフィルタリングされる、請求項２又は３に記載の方法。
- 前記フィルタリング・プロセスはデブロッキング・フィルタリング・プロセスである、請求項１－５のうちの何れか１項に記載の方法。
- 境界強度値は前記所定の変換境界に基づいて決定される、請求項１－６のうちの何れか１項に記載の方法。
- 前記変換は前記ビデオを前記ビットストリームに符号化することを含む、請求項１－７のうちの何れか１項に記載の方法。
- 前記変換は前記ビデオを前記ビットストリームから復号化することを含む、請求項１－７のうちの何れか１項に記載の方法。
- プロセッサと命令を有する非一時的なメモリとを含む、ビデオ・データを処理する装置であって、前記命令は前記プロセッサにより実行されると、前記プロセッサに：
サンプルが所定の変換境界に位置するかどうかに基づいて、ビデオの現在のビデオ・ユニットのサンプルに対してフィルタリング・プロセスを適用するかどうか及び適用の仕方を決定するステップと；
前記決定に基づいて、前記ビデオ及び前記ビデオのビットストリームの間で変換を実行するステップと；
を行わせ、前記所定の変換境界は第１変換モードに基づいて決定され、前記第１変換モードでは、変換領域は複数のサブ変換領域に分割され、唯１つのサブ変換領域が非ゼロ変換係数を有し、
前記第１変換モードはインター予測モードの変換領域に許容されるだけである、装置。 - 前記フィルタリング・プロセスは前記サンプルが前記所定の変換境界に位置することに基づいて適用される、請求項１０に記載の装置。
- 前記所定の変換境界のうちの少なくとも１つの境界は、前記サンプルが前記所定の変換境界に位置することに基づいて、フィルタリング・プロセスでフィルタリングされる、請求項１１に記載の装置。
- 命令を記憶する非一時的なコンピュータ読み取り可能な記憶媒体であって、前記命令は、プロセッサに：
サンプルが所定の変換境界に位置するかどうかに基づいて、ビデオの現在のビデオ・ユニットのサンプルに対してフィルタリング・プロセスを適用するかどうか及び適用の仕方を決定するステップと；
前記決定に基づいて、前記ビデオ及び前記ビデオのビットストリームの間で変換を実行するステップと；
を行わせ、前記所定の変換境界は第１変換モードに基づいて決定され、前記第１変換モードでは、変換領域は複数のサブ変換領域に分割され、唯１つのサブ変換領域が非ゼロ変換係数を有し、
前記第１変換モードはインター予測モードの変換領域に許容されるだけである、記憶媒体。 - ビデオのビットストリームを記憶する方法であって、前記方法は：
サンプルが所定の変換境界に位置するかどうかに基づいて、ビデオの現在のビデオ・ユニットのサンプルに対してフィルタリング・プロセスを適用するかどうか及び適用の仕方を決定するステップと；
前記決定に基づいて、前記ビデオのビットストリームを生成するステップと；
前記ビデオのビットストリームを、非一時的なコンピュータ読み取り可能な記憶媒体に記憶するステップと；
を含み、前記所定の変換境界は第１変換モードに基づいて決定され、前記第１変換モードでは、変換領域は複数のサブ変換領域に分割され、唯１つのサブ変換領域が非ゼロ変換係数を有し、
前記第１変換モードはインター予測モードの変換領域に許容されるだけである、方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2023085853A JP2023109946A (ja) | 2019-03-02 | 2023-05-25 | ビデオ処理方法、装置及び記憶媒体 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNPCT/CN2019/076785 | 2019-03-02 | ||
| CN2019076785 | 2019-03-02 | ||
| PCT/CN2020/077429 WO2020177664A1 (en) | 2019-03-02 | 2020-03-02 | Restrictions on in-loop filtering |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2023085853A Division JP2023109946A (ja) | 2019-03-02 | 2023-05-25 | ビデオ処理方法、装置及び記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2022522774A JP2022522774A (ja) | 2022-04-20 |
| JP7288071B2 true JP7288071B2 (ja) | 2023-06-06 |
Family
ID=72336991
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2021551763A Active JP7288071B2 (ja) | 2019-03-02 | 2020-03-02 | ビデオ処理方法、装置及び記憶媒体 |
| JP2023085853A Pending JP2023109946A (ja) | 2019-03-02 | 2023-05-25 | ビデオ処理方法、装置及び記憶媒体 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2023085853A Pending JP2023109946A (ja) | 2019-03-02 | 2023-05-25 | ビデオ処理方法、装置及び記憶媒体 |
Country Status (6)
| Country | Link |
|---|---|
| US (2) | US11558644B2 (ja) |
| EP (1) | EP3918788A4 (ja) |
| JP (2) | JP7288071B2 (ja) |
| KR (1) | KR20210130735A (ja) |
| CN (2) | CN113519164A (ja) |
| WO (2) | WO2020177664A1 (ja) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11677969B2 (en) * | 2019-03-22 | 2023-06-13 | Tencent America LLC | Method and apparatus for video coding |
| WO2020224581A1 (en) | 2019-05-05 | 2020-11-12 | Beijing Bytedance Network Technology Co., Ltd. | Chroma deblocking harmonization for video coding |
| WO2020249124A1 (en) | 2019-06-14 | 2020-12-17 | Beijing Bytedance Network Technology Co., Ltd. | Handling video unit boundaries and virtual boundaries based on color format |
| KR20220049520A (ko) | 2019-08-23 | 2022-04-21 | 베이징 바이트댄스 네트워크 테크놀로지 컴퍼니, 리미티드 | 코딩 블록 또는 서브블록 경계에서의 디블로킹 필터링 |
| KR20220058889A (ko) | 2019-09-14 | 2022-05-10 | 바이트댄스 아이엔씨 | 비디오 코딩의 크로마 양자화 파라미터 |
| CN114424529A (zh) | 2019-09-18 | 2022-04-29 | 北京字节跳动网络技术有限公司 | 视频编解码中自适应环路滤波器的两部分信令 |
| WO2021052492A1 (en) * | 2019-09-20 | 2021-03-25 | Beijing Bytedance Network Technology Co., Ltd. | Luma mapping with chroma scaling |
| EP4018652A4 (en) | 2019-09-22 | 2022-11-02 | Beijing Bytedance Network Technology Co., Ltd. | FILLING METHOD IN AN ADAPTIVE LOOP FILTER |
| KR20220063177A (ko) | 2019-09-27 | 2022-05-17 | 베이징 바이트댄스 네트워크 테크놀로지 컴퍼니, 리미티드 | 상이한 비디오 유닛들 간의 적응적 루프 필터링 |
| CN114651442A (zh) | 2019-10-09 | 2022-06-21 | 字节跳动有限公司 | 视频编解码中的跨分量适应性回路滤波 |
| JP7454042B2 (ja) | 2019-10-10 | 2024-03-21 | 北京字節跳動網絡技術有限公司 | 適応ループ・フィルタリングにおける利用可能でないサンプル位置でのパディング・プロセス |
| CN114556924B (zh) | 2019-10-14 | 2024-01-26 | 字节跳动有限公司 | 视频处理中色度残差的联合编解码与滤波的方法、装置及介质 |
| JP7389252B2 (ja) | 2019-10-29 | 2023-11-29 | 北京字節跳動網絡技術有限公司 | クロスコンポーネント適応ループフィルタ |
| KR20220106116A (ko) | 2019-12-09 | 2022-07-28 | 바이트댄스 아이엔씨 | 비디오 코딩에서 양자화 그룹 사용 |
| CN115104302A (zh) | 2019-12-11 | 2022-09-23 | 抖音视界有限公司 | 跨分量适应性回路滤波的样点填充 |
| CN114902657A (zh) | 2019-12-31 | 2022-08-12 | 字节跳动有限公司 | 视频编解码中的自适应颜色变换 |
| JP2023531223A (ja) | 2020-06-30 | 2023-07-21 | 北京字節跳動網絡技術有限公司 | 適応ループフィルタリングのための境界位置 |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020167228A1 (en) | 2019-02-15 | 2020-08-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Deblocking of transform sub-block boundaries |
Family Cites Families (43)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070058713A1 (en) | 2005-09-14 | 2007-03-15 | Microsoft Corporation | Arbitrary resolution change downsizing decoder |
| EP2080382B1 (en) | 2006-10-20 | 2016-07-20 | Nokia Technologies Oy | System and method for implementing low-complexity multi-view video coding |
| EP2215844A2 (en) | 2007-10-15 | 2010-08-11 | Nokia Corporation | Motion skip and single-loop encoding for multi-view video content |
| EP2324641A1 (en) * | 2008-08-12 | 2011-05-25 | Nokia Corporation | Video coding using spatially varying transform |
| US8995778B2 (en) * | 2009-12-01 | 2015-03-31 | Humax Holdings Co., Ltd. | Method and apparatus for encoding/decoding high resolution images |
| CN106231342B (zh) * | 2010-04-13 | 2019-05-31 | 三星电子株式会社 | 执行去块滤波的对视频进行解码的方法 |
| US9380314B2 (en) * | 2010-12-20 | 2016-06-28 | Texas Instruments Incorporated | Pixel retrieval for frame reconstruction |
| US9232237B2 (en) * | 2011-08-05 | 2016-01-05 | Texas Instruments Incorporated | Block-based parallel deblocking filter in video coding |
| US9167269B2 (en) * | 2011-10-25 | 2015-10-20 | Qualcomm Incorporated | Determining boundary strength values for deblocking filtering for video coding |
| US20130107973A1 (en) | 2011-10-28 | 2013-05-02 | Qualcomm Incorporated | Loop filtering control over tile boundaries |
| CN104137545B (zh) * | 2012-01-19 | 2018-06-05 | 寰发股份有限公司 | 编码块旗标的编码及视频比特流的解码方法与装置 |
| US9591331B2 (en) | 2012-03-28 | 2017-03-07 | Qualcomm Incorporated | Merge signaling and loop filter on/off signaling |
| US9088770B2 (en) | 2012-08-15 | 2015-07-21 | Intel Corporation | Size based transform unit context derivation |
| US20140079135A1 (en) * | 2012-09-14 | 2014-03-20 | Qualcomm Incoporated | Performing quantization to facilitate deblocking filtering |
| AU2013200051B2 (en) * | 2013-01-04 | 2016-02-11 | Canon Kabushiki Kaisha | Method, apparatus and system for de-blocking video data |
| US20140192862A1 (en) * | 2013-01-07 | 2014-07-10 | Research In Motion Limited | Methods and systems for prediction filtering in video coding |
| TW201507443A (zh) | 2013-05-15 | 2015-02-16 | Vid Scale Inc | 基於單迴路解碼之多層視訊編碼 |
| US20150049821A1 (en) | 2013-08-16 | 2015-02-19 | Qualcomm Incorporated | In-loop depth map filtering for 3d video coding |
| WO2015054811A1 (en) | 2013-10-14 | 2015-04-23 | Microsoft Corporation | Features of intra block copy prediction mode for video and image coding and decoding |
| US11070810B2 (en) | 2014-03-14 | 2021-07-20 | Qualcomm Incorporated | Modifying bit depths in color-space transform coding |
| AU2014202921B2 (en) * | 2014-05-29 | 2017-02-02 | Canon Kabushiki Kaisha | Method, apparatus and system for de-blocking a block of video samples |
| US9819948B2 (en) | 2014-06-18 | 2017-11-14 | Qualcomm Incorporated | Signaling HRD parameters for bitstream partitions |
| US10432951B2 (en) | 2014-06-24 | 2019-10-01 | Qualcomm Incorporated | Conformance and inoperability improvements in multi-layer video coding |
| WO2016090568A1 (en) * | 2014-12-10 | 2016-06-16 | Mediatek Singapore Pte. Ltd. | Binary tree block partitioning structure |
| US10057574B2 (en) | 2015-02-11 | 2018-08-21 | Qualcomm Incorporated | Coding tree unit (CTU) level adaptive loop filter (ALF) |
| WO2017045101A1 (en) * | 2015-09-14 | 2017-03-23 | Mediatek Singapore Pte. Ltd. | Advanced deblocking filter in video coding |
| US10491922B2 (en) * | 2015-09-29 | 2019-11-26 | Qualcomm Incorporated | Non-separable secondary transform for video coding |
| US11563938B2 (en) | 2016-02-15 | 2023-01-24 | Qualcomm Incorporated | Geometric transforms for filters for video coding |
| CN109076241B (zh) | 2016-05-04 | 2023-06-23 | 微软技术许可有限责任公司 | 利用样本值的非相邻参考线进行帧内图片预测 |
| CN109121465B (zh) | 2016-05-06 | 2023-06-06 | 交互数字麦迪逊专利控股公司 | 用于运动补偿残差预测的系统和方法 |
| US10382766B2 (en) | 2016-05-09 | 2019-08-13 | Qualcomm Incorporated | Signalling of filtering information |
| US20180041778A1 (en) | 2016-08-02 | 2018-02-08 | Qualcomm Incorporated | Geometry transformation-based adaptive loop filtering |
| US11095893B2 (en) * | 2016-10-12 | 2021-08-17 | Qualcomm Incorporated | Primary transform and secondary transform in video coding |
| US20180139444A1 (en) * | 2016-11-16 | 2018-05-17 | Mediatek Inc. | Method and Apparatus of Video Coding Using Flexible Quadtree and Binary Tree Block Partitions |
| US10694202B2 (en) | 2016-12-01 | 2020-06-23 | Qualcomm Incorporated | Indication of bilateral filter usage in video coding |
| US10506230B2 (en) | 2017-01-04 | 2019-12-10 | Qualcomm Incorporated | Modified adaptive loop filter temporal prediction for temporal scalability support |
| US10778974B2 (en) | 2017-07-05 | 2020-09-15 | Qualcomm Incorporated | Adaptive loop filter with enhanced classification methods |
| CN116866559A (zh) | 2017-11-01 | 2023-10-10 | Vid拓展公司 | 用于简化视频译码中的自适应环路滤波器的方法 |
| US10721469B2 (en) | 2017-11-28 | 2020-07-21 | Qualcomm Incorporated | Line buffer reduction for adaptive loop filtering in video coding |
| WO2019126170A1 (en) | 2017-12-19 | 2019-06-27 | Vid Scale, Inc. | Face discontinuity filtering for 360-degree video coding |
| US20190238845A1 (en) | 2018-01-26 | 2019-08-01 | Qualcomm Incorporated | Adaptive loop filtering on deblocking filter results in video coding |
| US20190306502A1 (en) | 2018-04-02 | 2019-10-03 | Qualcomm Incorporated | System and method for improved adaptive loop filtering |
| CN113383554B (zh) | 2019-01-13 | 2022-12-16 | 北京字节跳动网络技术有限公司 | LUT和共享Merge列表之间的交互 |
-
2020
- 2020-03-02 CN CN202080018315.2A patent/CN113519164A/zh active Pending
- 2020-03-02 WO PCT/CN2020/077429 patent/WO2020177664A1/en unknown
- 2020-03-02 EP EP20767163.7A patent/EP3918788A4/en active Pending
- 2020-03-02 WO PCT/CN2020/077428 patent/WO2020177663A1/en active Application Filing
- 2020-03-02 CN CN202080018326.0A patent/CN113545036B/zh active Active
- 2020-03-02 KR KR1020217028282A patent/KR20210130735A/ko not_active Application Discontinuation
- 2020-03-02 JP JP2021551763A patent/JP7288071B2/ja active Active
-
2021
- 2021-07-07 US US17/368,972 patent/US11558644B2/en active Active
-
2022
- 2022-11-25 US US17/994,092 patent/US20230091563A1/en active Pending
-
2023
- 2023-05-25 JP JP2023085853A patent/JP2023109946A/ja active Pending
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020167228A1 (en) | 2019-02-15 | 2020-08-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Deblocking of transform sub-block boundaries |
Non-Patent Citations (4)
| Title |
|---|
| Kenneth Andersson, et al.，CE11: Deblocking for 4 x N, N x 4 and 8 x N and N x 8 block boundaries that not are aligned with 8x8 grid (test 11.2.1)，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-M0299-v2，13th Meeting: Marrakech, MA，2019年01月，pp.1-7 |
| Yin Zhao, Haitao Yang, and Jianle Chen，CE6: Spatially Varying Transform (Test 6.1.12.1)，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-K0139-v3，11th Meeting: Ljubljana, SI，2018年07月，pp.1-7 |
| Yin Zhao, Haitao Yang, and Jianle Chen，CE6: Sub-block transform for inter blocks (CE6.1.2)，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-L0358-v2，12th Meeting: Macao, CN，2018年09月，pp.1-9 |
| Yin Zhao, Han Gao, Haitao Yang, and Jianle Chen，CE6: Sub-block transform for inter blocks (CE6.4.1)，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，JVET-M0140-v3，13th Meeting: Marrakech, MA，2019年01月，pp.1-18 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP3918788A4 (en) | 2022-04-06 |
| CN113545036A (zh) | 2021-10-22 |
| JP2022522774A (ja) | 2022-04-20 |
| WO2020177663A1 (en) | 2020-09-10 |
| US20210337239A1 (en) | 2021-10-28 |
| JP2023109946A (ja) | 2023-08-08 |
| KR20210130735A (ko) | 2021-11-01 |
| CN113545036B (zh) | 2023-11-28 |
| US11558644B2 (en) | 2023-01-17 |
| US20230091563A1 (en) | 2023-03-23 |
| EP3918788A1 (en) | 2021-12-08 |
| CN113519164A (zh) | 2021-10-19 |
| WO2020177664A1 (en) | 2020-09-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP7288071B2 (ja) | ビデオ処理方法、装置及び記憶媒体 | |
| TWI829721B (zh) | 跨分量幀內預測模式導出 | |
| TWI767126B (zh) | 擴展四叉樹子塊的形狀 | |
| WO2019244116A1 (en) | Border partition in video coding | |
| CN110839160B (zh) | 扩展四叉树分割的强制边界分割 | |
| TWI714153B (zh) | 零單元的定義 | |
| KR20190052097A (ko) | 영상 처리 방법 및 이를 위한 장치 | |
| TWI707576B (zh) | 用於微塊的約束 | |
| TWI707580B (zh) | 零單元的劃分 | |
| TWI719520B (zh) | 零單元的濾波 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20210831 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20210831 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20220816 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20221115 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20221220 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20230320 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20230425 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20230525 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 7288071 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |