JP2022529636A - ビデオ符号化又はビデオ復号のための方法、装置及びコンピュータプログラム - Google Patents

ビデオ符号化又はビデオ復号のための方法、装置及びコンピュータプログラム Download PDF

Info

Publication number
JP2022529636A
JP2022529636A JP2021560898A JP2021560898A JP2022529636A JP 2022529636 A JP2022529636 A JP 2022529636A JP 2021560898 A JP2021560898 A JP 2021560898A JP 2021560898 A JP2021560898 A JP 2021560898A JP 2022529636 A JP2022529636 A JP 2022529636A
Authority
JP
Japan
Prior art keywords
slice
coded
split
video
size
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.)
Granted
Application number
JP2021560898A
Other languages
English (en)
Other versions
JP7377887B2 (ja
Inventor
リ,グォイチュン
リ,シアン
リィウ,シャン
Original Assignee
テンセント・アメリカ・エルエルシー
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 テンセント・アメリカ・エルエルシー filed Critical テンセント・アメリカ・エルエルシー
Publication of JP2022529636A publication Critical patent/JP2022529636A/ja
Application granted granted Critical
Publication of JP7377887B2 publication Critical patent/JP7377887B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90Methods 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/96Tree coding, e.g. quad-tree coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods 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/119Adaptive subdivision aspects, e.g. subdivision of a picture into rectangular or non-rectangular coding blocks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods 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/157Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
    • H04N19/159Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods 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/17Methods 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/176Methods 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods 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/186Methods 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/189Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70Methods 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

本開示の態様は、ビデオ符号化/復号のための方法及び装置を提供する。いくつかの例では、ビデオ復号のための装置は、受信回路及び処理回路を含む。例えば、処理回路は、符号化ビデオビットストリームから分割情報を復号する。分割情報は、イントラ符号化(I)スライスについての最小許容四分木(QT, quaternary tree)リーフノードサイズを示す。Iスライスについての最小許容QTリーフノードサイズは、符号化ツリーユニット(CTU, coding tree unit)サイズよりも小さい閾値によって制限される。さらに、処理回路は、最小許容QTリーフノードサイズに基づいて、Iスライス内の符号化ツリーブロックを符号化ブロックに分割し、符号化ビデオビットストリームからそれぞれ符号化ブロックを復元する。

Description

[関連出願への相互参照]
本願は、2020年10月22日に出願された米国特許出願第17/077,748号「METHOD AND APPARATUS FOR VIDEO CODING」の優先権の利益を主張する。当該米国特許出願は、2020年2月21日に出願された米国仮出願第62/979,911号「METHODS ON CONSTRAINT OF MINIMUM QT SIZE」の優先権の利益を主張する。これらの先の出願の全開示の全ての内容が参照によって本明細書に組み込まれる。
[技術分野]
本開示は、概してビデオ符号化に関連する実施形態を記載する。
本明細書において提供される背景技術の説明は、本開示の背景を一般的に提示するためのものである。本願の発明者の研究は、当該研究がこの背景技術の段落に記載されている範囲において、また、出願時に従来技術として特に適することのない説明の側面も、本開示に対する従来技術として明示的にも暗示的にも認められるものではない。
ビデオ符号化及び復号は、動き補償によるインターピクチャ予測を使用して実行できる。非圧縮ディジタルビデオは、一連のピクチャを含むことができ、各ピクチャは、例えば、1920×1080の輝度サンプル及び関連する色差サンプルの空間次元を有する。一連のピクチャは、例えば、毎秒60ピクチャ又は60Hzの固定又は可変のピクチャレート(フレームレートとしても非公式に知られている)を有することができる。非圧縮ビデオは、特定のビットレート要件を有する。例えば、サンプル当たり8ビットの1080p60 4:2:0ビデオ(60Hzのフレームレートの1920×1080の輝度サンプル解像度)は、1.5Gbit/sに近い帯域幅を必要とする。1時間のこのようなビデオは、600Gバイトを超える記憶空間を必要とする。
ビデオ符号化及び復号の1つの目的は、圧縮を通じて入力ビデオ信号の冗長性を低減できることである。圧縮は、場合によっては2桁以上も上記の帯域幅及び/又は記憶空間の要件を低減するのに役立つことができる。可逆圧縮及び不可逆圧縮の双方並びにこれらの組み合わせを使用することができる。可逆圧縮とは、元の信号の正確なコピーが圧縮された元の信号から復元できる技術を示す。不可逆圧縮を使用する場合、復元された信号は、元の信号と同一ではない可能性があるが、元の信号と復元された信号との間の歪みは、復元された信号を目的のアプリケーションにとって有用にするほど十分に小さい。ビデオの場合、不可逆圧縮が広く使用されている。許容される歪みの量はアプリケーションに依存する。例えば、特定の消費者のストリーミングアプリケーションのユーザは、テレビ配信アプリケーションのユーザよりも高い歪みを許容する可能性がある。達成可能な圧縮比は、より高い許容可能な歪み/許容される歪みがより高い圧縮比をもたらすことができるということを反映できる。
ビデオエンコーダ及びデコーダは、例えば、動き補償、変換、量子化及びエントロピー符号化を含むいくつかの広いカテゴリからの技術を利用することができる。
ビデオコーデック技術は、イントラ符号化として知られる技術を含むことができる。イントラ符号化では、サンプル値は、前に復元された参照ピクチャからのサンプル又は他のデータを参照せずに表される。いくつかのビデオコーデックでは、ピクチャは空間的にサンプルのブロックに細分される。サンプルの全てのブロックがイントラモードで符号化される場合、そのピクチャはイントラピクチャとすることができる。イントラピクチャと、独立デコーダリフレッシュピクチャのようなそれらの派生物は、デコーダ状態をリセットするために使用でき、したがって、符号化ビデオビットストリーム及びビデオセッションにおける最初のピクチャとして或いは静止画像として使用できる。イントラブロックのサンプルは変換を受けさせることができ、変換係数はエントロピー符号化の前に量子化できる。イントラ予測は、変換前ドメインにおけるサンプル値を最小化する技術とすることができる。場合によっては、変換後のDC値が小さく、AC係数が小さいほど、エントロピー符号化後のブロックを表すために所与の量子化ステップサイズにおいて必要とされるビットが少なくなる。
例えば、MPEG―2世代の符号化技術から知られているような従来のイントラ符号化は、イントラ予測を使用しない。しかし、いくつかのより新しいビデオ圧縮技術は、例えば、空間的に隣接しており復号順で前のデータのブロックを符号化/復号する間に取得された周囲のサンプルデータ及び/又はメタデータから試みる技術を含む。このような技術は、以下では「イントラ予測(intra prediction)」技術と呼ばれる。少なくともいくつかの場合、イントラ予測は復元中のカレントピクチャのみからの参照データを使用し、参照ピクチャからの参照データを使用しない点に留意すべきである。
多くの形式のイントラ予測が存在し得る。所与のビデオ符号化技術においてこのような技術のうち1つ以上が使用できる場合、使用される技術は、イントラ予測モードで符号化できる。或る場合、モードは、サブモード及び/又はパラメータを有することができ、これらは個別に符号化されてもよく、或いは、モードコードワードに含まれてもよい。所与のモード/サブモード/パラメータの組み合わせに使用するコードワードは、イントラ予測を通じた符号化効率利得に影響を与える可能性があり、同様に、コードワードをビットストリームに変換するために使用されるエントロピー符号化技術にも影響を与える可能性がある。
特定のイントラ予測モードがH.264で導入され、H.265で改良されて、JEM(joint exploration model)、VVC(versatile video coding)及びBMS(benchmark set)のようなより新しい符号化技術で更に改良されている。予測ブロックは、既に利用可能なサンプルに属する隣接するサンプル値を使用して形成できる。隣接サンプルのサンプル値は、方向に従って予測ブロックにコピーされる。使用中の方向への参照は、ビットストリームにおいて符号化でき、或いは、それ自体予測されてもよい。
図1Aを参照すると、右下に示されているのは、H.265の33個の可能な予測子方向(35個のイントラモードのうち33個の角度モードに対応する)から知られている9個の予測子方向のサブセットである。矢印が収束する点(101)は、予測されるサンプルを表す。矢印は、サンプルが予測される方向を表す。例えば、矢印(102)は、サンプル(101)が、水平から45度の角度の右上に対する1つ又は複数のサンプルから予測されることを示す。同様に、矢印(103)は、サンプル(101)が、水平から22.5度の角度でサンプル(101)の左下に対する1つ又は複数のサンプルから予測されることを示す。
依然として図1Aを参照すると、左上には、4×4のサンプルの正方形ブロック(104)が示されている(破線の太線で示されている)。正方形ブロック(104)は、16個のサンプルを含み、各サンプルは「S」と、Y次元におけるその位置(例えば、行インデックス)と、X次元におけるその位置(例えば、列インデックス)とでそれぞれラベル付けされる。例えば、サンプルS21は、Y次元における第2のサンプル(上から)及びX次元における第1のサンプル(左から)である。同様に、サンプルS44は、Y次元及びX次元の双方においてブロック(104)内の第4のサンプルである。ブロックのサイズが4×4のサンプルであるので、S44は右下にある。さらに、同様の番号付け方式に従った参照サンプルが示されている。参照サンプルは、Rと、ブロック(104)に対するそのY位置(例えば、行インデックス)及びX位置(列インデックス)とでラベル付けされる。H.264及びH.265の双方において、予測サンプルは復元中のブロックに隣接しており、したがって、負の値が使用される必要はない。
イントラピクチャ予測は、伝達された予測方向に応じて、隣接サンプルから参照サンプル値をコピーすることによって機能できる。例えば、符号化ビデオビットストリームが、このブロックについて、矢印(102)と一致する予測方向を示す信号伝達を含むと仮定する。すなわち、サンプルは、水平から45度の角度で右上に対する1つ又は複数の予測サンプルから予測されると仮定する。この場合、サンプルS41、S32、S23及びS14は、同じ参照サンプルR05から予測される。次いで、サンプルS44は、参照サンプルR08から予測される。
或る場合、特に方向が45度で均一に割り切れない場合、参照サンプルを計算するために、複数の参照サンプルの値が、例えば補間によって組み合わされてもよい。
ビデオ符号化技術の発達に伴い、可能な方向の数が増加している。H.264(2003年)では、9個の異なる方向が表現可能であった。これは、H.265(2013年)で33個に増加し、開示の時点でのJEM/VVC/BMSでは、最大で65個の方向をサポートできる。最も可能性の高い方向を特定するために実験が行われており、エントロピー符号化における或る技術は、より可能性の低い方向に対して特定のペナルティを受け入れて、少数のビットでこれらの可能性の高い方向を表すために使用されている。さらに、場合によっては、方向自体が、隣接する既に復号されたブロックで使用される隣接方向から予測できる。
図1Bは、時間と共に増加する予測方向の数を示す、JEMに従った65個のイントラ予測方向を示す概略図(180)を示す。
方向を表す符号化ビデオビットストリームにおけるイントラ予測方向ビットのマッピングは、ビデオ符号化技術によって異なる可能性があり、例えば、予測方向の簡単な直接マッピングから、イントラ予測モード、コードワード、最確モードを含む複雑な適応方式、及び同様の技術まで及ぶ可能性がある。しかし、全ての場合で、ビデオコンテンツにおいて、特定の他の方向よりも統計的に生じにくい特定の方向が存在し得る。ビデオ圧縮の目標は冗長性の低減であるので、良好に機能するビデオ符号化技術において、これらのより可能性の低い方向は、より可能性の高い方向よりもより多くのビット数によって表される。
動き補償は不可逆圧縮技術であり、前に復元されたピクチャ又はその一部(参照ピクチャ)からのサンプルデータのブロックが、動きベクトル(以下、MVという)によって示される方向に空間的にシフトされた後に、新たに復元されるピクチャ又はその一部の予測に使用されるという技術に関連付けることができる。場合によっては、参照ピクチャは現在復元中のピクチャと同じものにすることができる。MVは、X及びYの2次元を有してもよく、或いは、3次元を有してもよく、第3の次元は、使用中の参照ピクチャを示す(後者は、間接的に、時間次元とすることができる)。
いくつかのビデオ圧縮技術では、サンプルデータの特定の領域に適用可能なMVは、他のMVから予測でき、例えば、復元中の領域に空間的に隣接しており、復号順でそのMVに先行するサンプルデータの他の領域に関連するMVから予測できる。これにより、MVを符号化するために必要なデータ量をかなり低減でき、それによって冗長性を除去し、圧縮を増加させることができる。例えば、カメラから導出された入力ビデオ信号(ナチュラルビデオとして知られている)を符号化する場合、単一のMVが適用可能な領域よりも大きい領域が同様の方向に移動し、したがって、場合によっては隣接領域のMVから導出された同様の動きベクトルを使用して予測できるという統計的な可能性が存在するので、MV予測は効果的に機能し得る。その結果、所与の領域に対して検出されたMVは、周囲のMVから予測されるMVと同様又は同一であることになり、そのMVは、エントロピー符号化の後に、MVを直接符号化する場合に使用されるものよりも少ない数のビットで表現できる。場合によって、MV予測は、元の信号(すなわち、サンプルストリーム)から導出された信号(すなわち、MV)の可逆圧縮の一例になり得る。他の場合には、MV予測自体が、例えば、いくつかの周囲のMVから予測子を計算するときの丸め誤差の理由で、不可逆になり得る。
H.265/HEVC(ITU―T Rec. H.265, 「High Efficiency Video Coding」, December 2016)には、様々なMV予測メカニズムが記載されている。H.265が提供する多くのMV予測メカニズムの中で、本明細書において「空間マージ(spatial merge)」と呼ばれる技術について説明する。
図2を参照すると、カレントブロック(201)は、空間的にシフトされた同じサイズの前のブロックから予測可能であることが動き探索処理中にエンコーダによって見出されたサンプルを含む。そのMVを直接符号化する代わりに、MVは、1つ以上の参照ピクチャに関連するメタデータから、例えば、A0、A1及びB0、B1、B2(それぞれ202~206)と示される5つの周囲のサンプルのいずれか1つに関連するMVを使用して(復号順に)最新の参照ピクチャから導出できる。H.265では、MV予測は、隣接ブロックが使用しているのと同じ参照ピクチャからの予測子を使用できる。
本開示の態様は、ビデオ符号化/復号のための方法及び装置を提供する。いくつかの例では、ビデオ復号のための装置は、受信回路及び処理回路を含む。例えば、処理回路は、符号化ビデオビットストリームから分割情報を復号する。分割情報は、イントラ符号化(I)スライスについての最小許容四分木(QT, quaternary tree)リーフノードサイズを示す。Iスライスについての最小許容QTリーフノードサイズは、符号化ツリーユニット(CTU, coding tree unit)サイズよりも小さい閾値によって制限される。さらに、処理回路は、最小許容QTリーフノードサイズに基づいて、Iスライス内の符号化ツリーブロックを符号化ブロックに分割し、符号化ビデオビットストリームからそれぞれ符号化ブロックを復元する。
いくつかの実施形態では、分割情報は、輝度成分についての最小許容QTリーフノードサイズを示す。いくつかの例では、Iスライスについての最小許容QTリーフノードサイズは、Iスライスに使用されるデュアルツリー分割に応じて閾値によって制限される。一例では、閾値は、暗示的なQT分割要件に基づいて決定される。
いくつかの実施形態では、分割情報は、色差成分についての最小許容QTリーフノードサイズを示す。
一例では、分割情報は、シーケンスパラメータセット(SPS, sequence parameter set)から復号される。他の例では、分割情報は、ピクチャヘッダ(PH, picture header)から復号される。
いくつかの例では、処理回路は、二分木分割又は三分木分割を適用する前に、QT分割を適用し、符号化ツリーブロックを、最小許容QTリーフノードサイズの要件を満たすQTリーフノードに分割する。
いくつかの実施形態では、Iスライスについての最小許容QTリーフノードサイズの2を底とする対数は、CTUサイズの2を底とする対数よりも小さくなるように制限される。いくつかの例では、Iスライスについての最小許容QTリーフノードサイズの2を底とする対数は、CTUサイズの2を底とする対数よりも1だけ小さい。
また、本開示の態様は、ビデオ復号のためにコンピュータによって実行されると、コンピュータにビデオ復号のための方法を実行させる命令を記憶した非一時的なコンピュータ読み取り可能媒体を提供する。
開示の対象物の更なる特徴、性質及び様々な利点は、以下の詳細な説明及び添付の図面からより明らかになる。
イントラ予測モードの例示的なサブセットの概略図である。 例示的なイントラ予測方向の図である。 一例におけるカレントブロック及びその周囲の空間マージ候補の概略図である。 一実施形態による通信システム(300)の簡略化したブロック図の概略図である。 一実施形態による通信システム(400)の簡略化したブロック図の概略図である。 一実施形態によるデコーダの簡略化したブロック図の概略図である。 一実施形態によるエンコーダの簡略化したブロック図の概略図である。 他の実施形態によるエンコーダのブロック図を示す。 他の実施形態によるデコーダのブロック図を示す。 本開示の一実施形態による色差サブサンプリングフォーマットの例を示す。 本開示の実施形態による、対応する輝度サンプル及び色差サンプルの公称上の垂直及び水平相対位置を示す。 本開示の実施形態による、対応する輝度サンプル及び色差サンプルの公称上の垂直及び水平相対位置を示す。 本開示の実施形態による、対応する輝度サンプル及び色差サンプルの公称上の垂直及び水平相対位置を示す。 本開示の一実施形態に従ってCTU(1101)に分割されたピクチャ(1100)の一例を示す。 本開示の一実施形態によるピクチャ(1200)のラスタスキャンスライス分割の一例を示す。 本開示の一実施形態によるピクチャ(1300)の矩形スライス分割の一例を示す。 本開示の一実施形態に従ってタイル、ブリック(1401)~(1411)及び矩形スライス(1421)~(1424)に分割されたピクチャ(1400)の一例を示す。 本開示の実施形態によるマルチタイプツリー(MTT, multi―type tree)構造における例示的な分割タイプ(1521)~(1524)を示す。 本開示の一実施形態によるネスト構造MTT符号化ツリー構造を有する四分木(QT, quaternary tree)における分割フラグの伝達の例を示す。 本開示の実施形態によるMTT分割モードの例を示す。 本開示の一実施形態によるネスト構造MTT符号化ブロック構造を有するQTの一例を示す。 本開示の実施形態による三分木(TT, ternary tree)分割に対する制限の例を示す。 本開示の実施形態による二分木(BT, binary tree)分割及びTT分割の冗長な分割パターンの例を示す。 本開示の実施形態による許容不可能なTT分割及びBT分割の例を示す。 本開示の一実施形態によるシーケンスパラメータセット(SPS)における分割及びブロックサイズに関する例示的なシンタックス(2200)を示す。 本開示の一実施形態によるピクチャヘッダ構造の例示的なシンタックス(2300)を示す。 本開示の一実施形態による符号化ツリーユニットについての例示的なシンタックス(2400)を示す。 本開示の一実施形態による符号化ツリーユニットについての例示的なシンタックス(2400)を示す。 本開示の一実施形態による符号化ツリーについての例示的なシンタックス(2500)を示す。 本開示の一実施形態による符号化ツリーについての例示的なシンタックス(2500)を示す。 本開示の一実施形態による符号化ツリーについての例示的なシンタックス(2500)を示す。 本開示の一実施形態による符号化ツリーについての例示的なシンタックス(2500)を示す。 本開示の一実施形態によるスライスタイプの例を示す。 本開示の一実施形態による、並列TT分割及び符号化ブロックサイズについての変数の例示的な導出を示す。 本開示の一実施形態による符号化ブロックサイズについての変数の例示的な導出を示す。 本開示の一実施形態によるプロセスを概略的に示すフローチャートを示す。 一実施形態によるコンピュータシステムの概略図である。
図3は、本開示の一実施形態による通信システム(300)の簡略化したブロック図を示す。通信システム(300)は、例えば、ネットワーク(350)を介して互いに通信できる複数の端末デバイスを含む。例えば、通信システム(300)は、ネットワーク(350)を介して相互接続された第1の対の端末デバイス(310)及び(320)を含む。図3の例では、第1の対の端末デバイス(310)及び(320)は、データの一方向伝送を実行する。例えば、端末デバイス(310)は、ネットワーク(350)を介して他の端末デバイス(320)に送信するために、ビデオデータ(例えば、端末デバイス(310)によってキャプチャされたビデオピクチャのストリーム)を符号化してもよい。符号化されたビデオデータは、1つ以上の符号化ビデオビットストリームの形式で送信されてもよい。端末デバイス(320)は、ネットワーク(350)から符号化ビデオデータを受信し、符号化ビデオデータを復号して、ビデオピクチャを復元して復元されたビデオデータに従ってビデオピクチャを表示してもよい。一方向データ伝送は、メディア提供アプリケーション等において一般的でもよい。
他の例では、通信システム(300)は、例えば、テレビ会議中に発生し得る符号化ビデオデータの双方向伝送を実行する第2の対の端末デバイス(330)及び(340)を含む。データの双方向伝送のために、一例では、端末デバイス(330)及び(340)の各端末デバイスは、ネットワーク(350)を介して端末デバイス(330)及び(340)の他方の端末デバイスに送信するために、ビデオデータ(例えば、端末デバイスによってキャプチャされたビデオピクチャのストリーム)を符号化してもよい。また、端末デバイス(330)及び(340)の各端末デバイスは、端末デバイス(330)及び(340)の他方の端末デバイスによって送信された符号化ビデオデータを受信してもよく、符号化ビデオデータを復号してビデオピクチャを復元してもよく、復元されたビデオデータに従って、アクセス可能な表示デバイスにビデオピクチャを表示してもよい。
図3の例では、端末デバイス(410)、(420)、(430)及び(440)は、サーバ、パーソナルコンピュータ及びスマートフォンとして示されることがあるが、本開示の原理はこれらに限定されない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレイヤ及び/又は専用のテレビ会議機器に適用がある。ネットワーク(450)は、例えば、有線(配線接続)及び/又は無線通信ネットワークを含む、端末デバイス(410)、(420)、(430)及び(440)の間で符号化ビデオデータを伝達するいずれかの数のネットワークを表す。通信ネットワーク(450)は、回線交換チャネル及び/又はパケット交換チャネルにおいてデータを交換してもよい。代表的なネットワークは、電気通信ネットワーク、ローカルエリアネットワーク、広域ネットワーク及び/又はインターネットを含む。本説明の目的では、ネットワーク(450)のアーキテクチャ及びトポロジは、本明細書において以下に説明しない限り、本開示の動作には重要ではない。
図4は、開示の対象物のアプリケーションの例として、ストリーミング環境におけるビデオエンコーダ及びビデオデコーダの配置を示す。開示の対象物は、例えば、テレビ会議、デジタルTV、デジタルメディア(CD、DVD、メモリスティック等を含む)上の圧縮ビデオの記憶等を含む、他のビデオ可能なアプリケーションにも同様に適用可能である。
ストリーミングシステムはキャプチャサブシステム(413)を含んでもよく、当該キャプチャサブシステム(413)は、例えば、非圧縮のビデオピクチャのストリーム(402)を生成するビデオソース(401)(例えば、デジタルカメラ)を含んでもよい。一例では、ビデオピクチャのストリーム(402)は、デジタルカメラによって撮影されたサンプルを含む。符号化ビデオデータ(404)(又は符号化ビデオビットストリーム)と比較したときに高いデータ量であることを強調する太線として描かれるビデオピクチャのストリーム(402)は、ビデオソース(401)に結合されたビデオエンコーダ(403)を含む電子デバイス(420)によって処理されてもよい。ビデオエンコーダ(403)は、以下により詳細に説明するように、開示の対象物の態様を可能にするため或いは実装するために、ハードウェア、ソフトウェア又はこれらの組み合わせを含んでもよい。ビデオピクチャのストリーム(402)と比較したときにより低いデータ量であることを強調するために細線として描かれる符号化ビデオデータ(404)(又は符号化ビデオビットストリーム(404))は、将来の使用のためにストリーミングサーバ(405)に記憶されてもよい。図4におけるクライアントサブシステム(406)及び(408)のような1つ以上のストリーミングクライアントサブシステムは、ストリーミングサーバ(405)にアクセスして符号化ビデオデータ(404)のコピー(407)及び(409)を取得してもよい。クライアントサブシステム(406)は、例えば、電子デバイス(430)内にビデオデコーダ(410)を含んでもよい。ビデオデコーダ(410)は、符号化ビデオデータの入力コピー(407)を復号し、ディスプレイ(412)(例えば、表示画面)又は他のレンダリングデバイス(図示せず)上にレンダリングできるビデオピクチャの出力ストリーム(411)を生成する。いくつかのストリーミングシステムでは、符号化ビデオデータ(404)、(407)及び(409)(例えば、ビデオビットストリーム)は、特定のビデオ符号化/圧縮標準に従って符号化されてもよい。これらの標準の例は、ITU―T勧告H.265を含む。一例では、開発中のビデオ符号化標準は、VVC(Versatile Video Coding)として非公式に知られている。開示の対象物は、VVCの背景において使用されてもよい。
電子デバイス(420)及び(430)は、他の構成要素(図示せず)を含んでもよい点に留意すべきである。例えば、電子デバイス(420)は、ビデオデコーダ(図示せず)を含んでもよく、また、電子デバイス(430)は、ビデオエンコーダ(図示せず)を含んでもよい。
図5は、本開示の一実施形態によるビデオデコーダ(510)のブロック図を示す。ビデオデコーダ(510)は、電子デバイス(530)に含まれてもよい。電子デバイス(530)は、受信機(531)(例えば、受信回路)を含んでもよい。図4の例におけるビデオデコーダ(410)の代わりにビデオデコーダ(510)が使用されてもよい。
受信機(531)は、ビデオデコーダ(510)によって復号されるべき1つ以上の符号化ビデオシーケンスを受信してもよく、同一又は他の実施形態では、一度に1つの符号化ビデオシーケンスを受信してもよく、各符号化ビデオシーケンスの復号は、他の符号化ビデオシーケンスとは独立している。符号化ビデオシーケンスは、チャネル(501)から受信されてもよく、当該チャネルは、符号化ビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクでもよい。受信機(531)は、符号化ビデオデータを、他のデータ(例えば、符号化オーディオデータ及び/又は補助データストリーム)と共に受信してもよく、これらは、それぞれの使用エンティティ(図示せず)に転送されてもよい。受信機(531)は、符号化ビデオシーケンスを他のデータから分離してもよい。ネットワークジッタを防止するために、バッファメモリ(515)は、受信機(531)とエントロピーデコーダ/パーサ(520)(以下、「パーサ(520)」という)との間に結合されてもよい。特定のアプリケーションでは、バッファメモリ(515)はビデオデコーダ(510)の一部である。他の場合には、ビデオデコーダ(510)の外側にあってもよい(図示せず)。更に他の場合には、例えば、ネットワークジッタを防止するために、ビデオデコーダ(510)の外側にバッファメモリ(図示せず)が存在してもよく、加えて、例えば、再生タイミングに対処するために、ビデオデコーダ(510)の内側に他のバッファメモリ(515)が存在してもよい。受信機(531)が、十分な帯域幅及び制御可能性を有する記憶/転送デバイスから、或いは、アイソクロナスネットワークからデータを受信している場合、バッファメモリ(515)は必要なくてもよく或いは小さくすることができる。インターネットのようなベストエフォート型パケットネットワークでの使用については、バッファメモリ(515)が必要とされてもよく、比較的大きくすることができ、有利には適応的なサイズとすることができ、ビデオデコーダ(510)の外側のオペレーティングシステム又は同様の要素(図示せず)に少なくとも部分的に実装されてもよい。
ビデオデコーダ(510)は、符号化ビデオシーケンスからシンボル(521)を復元するためのパーサ(520)を含んでもよい。これらのシンボルのカテゴリは、ビデオデコーダ(510)の動作を管理するために使用される情報を含み、レンダリングデバイス(512)(例えば、表示画面)のようなレンダリングデバイスを制御するための情報を潜在的に含む。当該レンダリングデバイス(512)は、図5に示されているように、電子デバイス(530)の一体的な部分ではないが、電子デバイス(530)に結合されてもよい。レンダリングデバイスの制御情報は、補足エンハンスメント情報(SEI, Supplemental Enhancement Information)(SEIメッセージ)又はビデオユーザビリティ情報(VUI, Video Usability Information)パラメータセットフラグメント(図示せず)の形式でもよい。パーサ(520)は、受信した符号化ビデオシーケンスを解析/エントロピー復号してもよい。符号化ビデオシーケンスの符号化は、ビデオ符号化技術又は標準に従ってもよく、可変長符号化、ハフマン符号化、コンテキスト感度を伴う或いは伴わない算術符号化等を含む様々な原理に従ってもよい。パーサ(520)は、グループに対応する少なくとも1つのパラメータに基づいて、符号化ビデオシーケンスから、ビデオデコーダ内の画素のサブグループのうち少なくとも1つについてのサブグループパラメータのセットを抽出してもよい。サブグループは、グループオブピクチャ(GOP, Group of Picture)、ピクチャ、タイル、スライス、マクロブロック、符号化ユニット(CU, Coding Unit)、ブロック、変換ユニット(TU, Transformation Unit)、予測ユニット(PU, Prediction Unit)等を含んでもよい。また、パーサ(520)は、符号化ビデオシーケンスから、変換係数、量子化パラメータ値、動きベクトル等のような情報を抽出してもよい。
パーサ(520)は、シンボル(521)を生成するために、バッファメモリ(515)から受信したビデオシーケンスに対してエントロピー復号/解析動作を実行してもよい。
シンボル(521)の復元には、符号化ビデオピクチャ又はその部分のタイプ(例えば、インターピクチャ及びイントラピクチャ、インターブロック及びイントラブロック)及び他の要因に依存して、複数の異なるユニットが関与してもよい。どのユニットがどのように関与するかは、パーサ(520)によって符号化ビデオシーケンスから解析されたサブグループ制御情報によって制御されてもよい。パーサ(520)と以下の複数ユニットとの間のこのようなサブグループ制御情報の流れは、明確にするために図示されていない。
上記の機能ブロックの他に、ビデオデコーダ(510)は、概念的に、以下に説明するような複数の機能ユニットに細分されてもよい。商用的な制約の下で動作する実用的な実装では、これらのユニットの多くは互いに密接に相互作用し、少なくとも部分的に互いに統合されてもよい。しかし、開示の対象物を説明する目的で、以下の機能ユニットに概念的に細分することが適切である。
第1のユニットは、スケーラ/逆変換ユニット(551)である。スケーラ/逆変換ユニット(551)は、パーサ(520)からシンボル(521)として、制御情報(どの変換を使用するべきか、ブロックサイズ、量子化係数、量子化スケーリング行列等を含む)と共に、量子化された変換係数を受信する。スケーラ/逆変換ユニット(551)は、アグリゲータ(555)に入力できるサンプル値を含むブロックを出力してもよい。
場合によっては、スケーラ/逆変換(551)の出力サンプルは、イントラ符号化ブロックに関連してもよく、すなわち、前に復元されたピクチャからの予測情報を使用していないが、カレントピクチャの前に復元された部分からの予測情報を使用できるブロックに関連してもよい。このような予測情報は、イントラピクチャ予測ユニット(552)によって提供されてもよい。場合によっては、イントラピクチャ予測ユニット(552)は、カレントピクチャバッファ(558)から取り出された周囲の既に復元された情報を使用して、復元中のブロックの同じサイズ及び形状のブロックを生成する。カレントピクチャバッファ(558)は、例えば、部分的に復元されたカレントピクチャ及び/又は完全に復元されたカレントピクチャをバッファする。場合によっては、アグリゲータ(555)は、サンプル毎に、イントラ予測ユニット(552)が生成した予測情報を、スケーラ/逆変換ユニット(551)によって提供された出力サンプル情報に追加する。
他の場合には、スケーラ/逆変換ユニット(551)の出力サンプルは、インター符号化されて潜在的に動き補償されたブロックに関連してもよい。このような場合、動き補償予測ユニット(553)は、参照ピクチャメモリ(557)にアクセスして、予測に使用されるサンプルを取り出してもよい。ブロックに関連するシンボル(521)に従って、取り出されたサンプルを動き補償した後に、これらのサンプルは、出力サンプル情報を生成するために、アグリゲータ(555)によってスケーラ/逆変換ユニット(551)の出力(この場合には、残差サンプル又は残差信号と呼ばれる)に追加されてもよい。動き補償予測ユニット(553)に利用可能な、動き補償予測ユニット(553)が予測サンプルを取り出す参照ピクチャメモリ(557)内のアドレスは、例えば、X、Y及び参照ピクチャ成分を有することができるシンボル(521)の形式で、動きベクトルによって制御されてもよい。また、動き補償は、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリ(557)から取り出されるサンプル値の補間、動きベクトル予測メカニズム等を含んでもよい。
アグリゲータ(555)の出力サンプルは、ループフィルタユニット(556)内の様々なループフィルタリング技術を受けてもよい。ビデオ圧縮技術はループ内フィルタ技術を含んでもよく、当該ループ内フィルタ技術は、符号化ビデオシーケンス(符号化ビデオビットストリームとも呼ばれる)に含まれるパラメータによって制御され、パーサ(520)からシンボル(521)としてループフィルタユニット(556)に利用可能にされるが、符号化ピクチャ又は符号化ビデオシーケンスの(復号順に)前の部分の復号の間に取得されたメタ情報に応答すると共に、前に復元されてループフィルタリングされたサンプル値にも応答してもよい。
ループフィルタユニット(556)の出力はサンプルストリームでもよく、当該サンプルストリームは、レンダリングデバイス(512)に出力されると共に、将来のインターピクチャ予測に使用するために参照ピクチャメモリ(557)に記憶されてもよい。
特定の符号化ピクチャは、完全に復元されると、将来の予測のための参照ピクチャとして使用されてもよい。例えば、カレントピクチャに対応する符号化ピクチャが完全に復元され、符号化ピクチャが(例えば、パーサ(520)によって)参照ピクチャとして識別されると、カレントピクチャバッファ(558)は参照ピクチャメモリ(557)の一部となってもよく、新たなカレントピクチャバッファが、後続の符号化ピクチャの復元を開始する前に再割り当てされてもよい。
ビデオデコーダ(510)は、ITU―T Rec. H.265のような標準における所定のビデオ圧縮技術に従って復号動作を実行してもよい。符号化ビデオシーケンスがビデオ圧縮技術又は標準のシンタックス及びビデオ圧縮技術又は標準に文書化されているプロファイルの双方に従うという意味で、符号化ビデオシーケンスは、使用されているビデオ圧縮技術又は標準によって指定されたシンタックスに適合してもよい。具体的には、プロファイルは、ビデオ圧縮技術又は標準で利用可能な全てのツールから特定のツールを、そのプロファイルで使用するのに利用可能な唯一のツールとして選択してもよい。また、コンプライアンスのために必要なことは、符号化ビデオシーケンスの複雑さが、ビデオ圧縮技術又は標準のレベルによって定義される範囲内にあることである。場合によっては、レベルは、最大ピクチャサイズ、最大フレームレート、最大復元サンプルレート(例えば、毎秒当たりのメガサンプル単位で測定される)、最大参照ピクチャサイズ等を制限する。場合によっては、レベルによって設定される制限は、仮想参照デコーダ(HRD, Hypothetical Reference Decoder)仕様及び符号化ビデオシーケンスで伝達されるHRDバッファ管理についてのメタデータを通じて更に制限されてもよい。
一実施形態では、受信機(531)は、符号化ビデオと共に更なる(冗長な)データを受信してもよい。更なるデータは、符号化ビデオシーケンスの一部として含まれてもよい。更なるデータは、データを適切に復号するために、及び/又は元のビデオデータをより正確に復元するために、ビデオデコーダ(510)によって使用されてもよい。更なるデータは、例えば、時間、空間又は信号雑音比(SNR, signal noise ratio)エンハンスメント層、冗長スライス、冗長ピクチャ、前方誤り訂正コード等の形式でもよい。
図6は、本開示の一実施形態によるビデオエンコーダ(603)のブロック図を示す。ビデオエンコーダ(603)は、電子デバイス(620)に含まれる。電子デバイス(620)は、送信機(640)(例えば、送信回路)を含む。図4の例におけるビデオエンコーダ(403)の代わりにビデオエンコーダ(603)が使用されてもよい。
ビデオエンコーダ(603)は、ビデオソース(601)(図6の例では電子デバイス(620)の一部ではない)からビデオサンプルを受信してもよく、当該ビデオソース(601)は、ビデオエンコーダ(603)によって符号化されるべきビデオ画像をキャプチャしてもよい。他の例では、ビデオソース(601)は電子デバイス(620)の一部である。
ビデオソース(601)は、デジタルビデオサンプルストリームの形式でビデオエンコーダ(603)によって符号化されるべきソースビデオシーケンスを提供してもよく、当該デジタルビデオサンプルストリームは、いずれかの適切なビット深度(例えば、8ビット、10ビット、12ビット等)、いずれかの色空間(例えば、BT.601 Y CrCB、RGB等)及びいずれかの適切なサンプリング構造(例えば、Y CrCb 4:2:0、Y CrCb 4:4:4)でもよい。メディア提供システムにおいて、ビデオソース(601)は、事前に準備されたビデオを記憶する記憶デバイスでもよい。テレビ会議システムでは、ビデオソース(601)は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラでもよい。ビデオデータは、順に見たときに動きを伝える複数の個々のピクチャとして提供されてもよい。ピクチャ自体は、画素の空間配列として構成されてもよく、各画素は、使用中のサンプリング構造、色空間等に依存して、1つ以上のサンプルを含んでもよい。当業者は、画素とサンプルとの関係を容易に理解することができる。以下の説明は、サンプルに焦点を当てる。
一実施形態によれば、ビデオエンコーダ(603)は、リアルタイムで或いはアプリケーションによって要求されるいずれかの他の時間制約下で、ソースビデオシーケンスのピクチャを、符号化ビデオシーケンス(643)に符号化及び圧縮してもよい。適切な符号化速度を実現することは、コントローラ(650)の1つの機能である。いくつかの実施形態では、コントローラ(650)は、以下に説明するように、他の機能ユニットを制御し、他の機能ユニットに機能的に結合される。結合は、明確にするために図示されていない。コントローラ(650)によって設定されるパラメータは、レート制御関連パラメータ(ピクチャスキップ、量子化、レート歪み最適化技術のラムダ値等)、ピクチャサイズ、グループオブピクチャ(GOP)のレイアウト、最大動きベクトル探索範囲等を含んでもよい。コントローラ(650)は、特定のシステム設計のために最適化されたビデオエンコーダ(603)に関連する他の適切な機能を有するように構成されてもよい。
いくつかの実施形態では、ビデオエンコーダ(603)は、符号化ループで動作するように構成される。非常に簡略化した説明として、一例では、符号化ループは、ソースコーダ(630)(例えば、符号化されるべき入力ピクチャ及び参照ピクチャに基づいて、シンボルストリームのようなシンボルを生成することを担う)と、ビデオエンコーダ(603)に埋め込まれた(ローカル)デコーダ(633)とを含んでもよい。デコーダ(633)は、(リモート)デコーダが生成するのと同様に(シンボルと符号化ビデオビットストリームとの間のいずれかの圧縮が、開示の対象物において検討されるビデオ圧縮技術において可逆であるように)、サンプルデータを生成するようにシンボルを復元する。復元されたサンプルストリーム(サンプルデータ)は、参照ピクチャメモリ(634)に入力される。シンボルストリームの復号は、デコーダの位置(ローカル又はリモート)と独立したビット単位の正確な結果をもたらすので、参照ピクチャメモリ(634)内の内容も、ローカルエンコーダとリモートエンコーダとの間でビット単位で正確である。言い換えると、エンコーダの予測部分は、デコーダが復号中に予測を使用するときに「見る」のと全く同じサンプル値を参照ピクチャサンプルとして「見る」。参照ピクチャの同期(例えば、チャネルエラーの理由で同期が維持できない場合の結果として生じるドリフトを含む)のこの基本原理は、いくつかの関連技術においても同様に使用される。
「ローカル」デコーダ(633)の動作は、ビデオデコーダ(510)のような「リモート」デコーダと同じでもよく、これは、図5に関連して上記において既に詳細に説明した。しかし、図5を簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ(645)及びパーサ(520)による符号化ビデオシーケンスへのシンボルの符号化/復号が可逆になり得るので、バッファメモリ(515)及びパーサ(520)を含むビデオデコーダ(510)のエントロピー復号部分は、ローカルデコーダ(633)に完全には実装されなくてもよい。
この時点で行うことができる考察は、デコーダ内に存在する解析/エントロピー復号を除く如何なるデコーダ技術も、必然的に対応するエンコーダ内に実質的に同一の機能形式で存在する必要があることである。このため、開示の対象物はデコーダ動作に焦点を当てる。エンコーダ技術の説明は、包括的に記載されるデコーダ技術の逆であるので、省略できる。特定の領域においてのみ、より詳細な説明が必要であり、以下に提供される。
いくつかの例では、動作中に、ソースコーダ(630)は、動き補償予測符号化を実行してもよく、当該動き補償予測符号化は、「参照ピクチャ」として指定されたビデオシーケンスからの1つ以上の前に符号化されたピクチャを参照して入力ピクチャを予測的に符号化する。このように、符号化エンジン(632)は、入力ピクチャの画素ブロックと、入力ピクチャに対する予測参照として選択され得る参照ピクチャの画素ブロックとの間の差を符号化する。
ローカルビデオデコーダ(633)は、ソースコーダ(630)によって生成されたシンボルに基づいて、参照ピクチャとして指定され得るピクチャの符号化ビデオデータを復号してもよい。符号化エンジン(632)の動作は、有利には、不可逆処理でもよい。符号化ビデオデータがビデオデコーダ(図6に図示せず)で復号され得る場合、復元されたビデオシーケンスは、典型的には、いくつかのエラーを伴うソースビデオシーケンスのレプリカになり得る。ローカルビデオデコーダ(633)は、参照ピクチャに対してビデオデコーダによって実行され得る復号処理を複製し、復元された参照ピクチャを参照ピクチャキャッシュ(634)に記憶させてもよい。このように、ビデオエンコーダ(603)は、遠端のビデオデコーダによって取得される(送信エラーのない)復元された参照ピクチャとして、共通の内容を有する復元された参照ピクチャのコピーをローカルに記憶してもよい。
予測器(635)は、符号化エンジン(632)のための予測探索を実行してもよい。すなわち、符号化されるべき新たなピクチャについて、予測器(635)は、(候補参照画素ブロックとしての)サンプルデータ又は特定のメタデータ(参照ピクチャ動きベクトル、ブロック形状等)を求めて参照ピクチャメモリ(634)を検索してもよい。これらは、新たなピクチャについての適切な予測参照として機能してもよい。予測器(635)は、適切な予測参照を検出するために、サンプルブロック毎画素ブロック毎(sample block―by―pixel block)に動作してもよい。場合によっては、予測器(635)によって取得された検索結果によって決定された入力ピクチャは、参照ピクチャメモリ(634)に記憶された複数の参照ピクチャから引き出された予測参照を有してもよい。
コントローラ(650)は、例えば、ビデオデータを符号化するために使用されるパラメータ及びサブグループパラメータの設定を含む、ソースコーダ(630)の符号化動作を管理してもよい。
全ての上記の機能ユニットの出力は、エントロピーコーダ(645)におけるエントロピー符号化を受けてもよい。エントロピーコーダ(645)は、ハフマン符号化、可変長符号化、算術符号化等のような技術に従って、シンボルを可逆圧縮することによって、様々な機能ユニットによって生成されたシンボルを符号化ビデオシーケンスに変換する。
送信機(640)は、エントロピーコーダ(645)によって生成された符号化ビデオシーケンスをバッファして、通信チャネル(660)を介した送信の準備をしてもよく、当該通信チャネル(660)は、符号化ビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクでもよい。送信機(640)は、ビデオコーダ(603)からの符号化ビデオデータを、送信されるべき他のデータ(例えば、符号化オーディオデータ及び/又は補助データストリーム(図示せず))とマージしてもよい。
コントローラ(650)は、ビデオエンコーダ(603)の動作を管理してもよい。符号化中に、コントローラ(650)は、各符号化ピクチャに、特定の符号化ピクチャタイプを割り当ててもよい。当該符号化ピクチャタイプは、各ピクチャに適用され得る符号化技術に影響を与えてもよい。例えば、ピクチャは、しばしば、以下のピクチャタイプのうち1つとして割り当てられてもよい。
イントラピクチャ(Iピクチャ)は、予測のソースとしてシーケンス内の他のピクチャを使用せずに、符号化及び復号され得るものでもよい。いくつかのビデオコーデックは、例えば、独立デコーダリフレッシュ(IDR, Independent Decoder Refresh)ピクチャを含む、異なるタイプのイントラピクチャを許容する。当業者は、Iピクチャのこれらの変形例と、それぞれの用途及び特徴を認識する。
予測ピクチャ(Pピクチャ)は、各ブロックのサンプル値を予測するために、最大で1つの動きベクトル及び参照インデックスを使用して、イントラ予測又はインター予測を使用して符号化及び復号され得るものでもよい。
双方向予測ピクチャ(Bピクチャ)は、各ブロックのサンプル値を予測するために、最大で2つの動きベクトル及び参照インデックスを使用して、イントラ予測又はインター予測を使用して符号化及び復号され得るものでもよい。同様に、複数の予測ピクチャは、単一のブロックの復元のために、2つより多くの参照ピクチャ及び関連するメタデータを使用してもよい。
一般的に、ソースピクチャは、空間的に複数のサンプルブロック(例えば、それぞれ4×4、8×8、4×8又は16×16のサンプルのブロック)に細分され、ブロック毎に符号化されてもよい。ブロックは、ブロックのそれぞれのピクチャに適用される符号化割り当てによって決定される通り、他の(既に符号化された)ブロックを参照して予測的に符号化されてもよい。例えば、Iピクチャのブロックは、非予測的に符号化されてもよく、或いは、同じピクチャの既に符号化されたブロックを参照して予測的に符号化されてもよい(空間予測又はイントラ予測)。Pピクチャの画素ブロックは、1つ前に符号化された参照ピクチャを参照して、空間予測又は時間予測を介して予測的に符号化されてもよい。Bピクチャのブロックは、1つ又は2つ前に符号化された参照ピクチャを参照して、空間予測又は時間予測を介して予測的に符号化されてもよい。
ビデオエンコーダ(603)は、ITU―T Rec. H.265のような所定のビデオ符号化技術又は標準に従って符号化動作を実行してもよい。その動作において、ビデオエンコーダ(603)は、入力ビデオシーケンスにおける時間的及び空間的冗長性を利用する予測符号化動作を含む様々な圧縮動作を実行してもよい。したがって、符号化ビデオデータは、使用されているビデオ符号化技術又は標準によって指定されたシンタックスに適合してもよい。
一実施形態では、送信機(640)は、符号化ビデオと共に更なるデータを送信してもよい。ソースコーダ(630)は、符号化ビデオシーケンスの一部としてこのようなデータを含んでもよい。更なるデータは、時間/空間/SNRエンハンスメント層、冗長ピクチャ及びスライス、SEIメッセージ、VUIパラメータセットフラグメント等のような他の形式の冗長データを含んでもよい。
ビデオは、時系列において複数のソースピクチャ(ビデオピクチャ)としてキャプチャされてもよい。イントラピクチャ予測(しばしばイントラ予測と略される)は、所与のピクチャ内の空間的相関を利用し、インターピクチャ予測は、ピクチャ間の(時間的又は他の)相関を利用する。一例では、カレントピクチャと呼ばれる符号化/復号中の特定のピクチャは、ブロックに分割される。カレントピクチャ内のブロックがビデオにおける前に符号化されて依然としてバッファされている参照ピクチャ内の参照ブロックに類似する場合、カレントピクチャ内のブロックは、動きベクトルと呼ばれるベクトルによって符号化されてもよい。動きベクトルは、参照ピクチャ内の参照ブロックを指し、複数の参照ピクチャが使用されている場合には、参照ピクチャを識別する第3の次元を有してもよい。
いくつかの実施形態では、双方向予測技術は、インターピクチャ予測において使用されてもよい。双方向予測技術によれば、ビデオにおけるカレントピクチャへの復号順で双方とも先行する(しかし、表示順ではそれぞれ過去及び将来のものでもよい)第1の参照ピクチャ及び第2の参照ピクチャのような2つの参照ピクチャが使用される。カレントピクチャ内のブロックは、第1の参照ピクチャ内の第1の参照ブロックを指す第1の動きベクトルと、第2の参照ピクチャ内の第2の参照ブロックを指す第2の動きベクトルとによって符号化されてもよい。ブロックは、第1の参照ブロックと第2の参照ブロックとの組み合わせによって予測されてもよい。
さらに、符号化効率を改善するために、インターピクチャ予測においてマージモード技術が使用できる。
本開示のいくつかの実施形態によれば、インターピクチャ予測及びイントラピクチャ予測のような予測は、ブロックの単位で実行される。例えば、HEVC標準によれば、ビデオピクチャのシーケンス内のピクチャは、圧縮のために符号化ツリーユニット(CTU, coding tree unit)に分割され、ピクチャ内のCTUは、64×64の画素、32×32の画素又は16×16の画素のように、同じサイズを有する。一般的に、CTUは、1つの輝度CTBと2つの色差CTBである3つの符号化ツリーブロック(CTB, coding tree block)を含む。各CTUは、1つ又は複数の符号化ユニット(CU, coding unit)に再帰的に四分木分割されてもよい。例えば、64×64の画素のCTUは、64×64の画素の1つのCU、32×32の画素の4つのCU又は16×16の画素の16個のCUに分割できる。一例では、各CUは、インター予測タイプ又はイントラ予測タイプのようなCUの予測タイプを決定するために分析される。CUは、時間的及び/又は空間的予測可能性に依存して1つ以上の予測ユニット(PU, prediction unit)に分割される。一般的に、各PUは、輝度予測ブロック(PB, prediction block)と2つの色差PBとを含む。一実施形態では、符号化(符号化/復号)における予測動作は、予測ブロックの単位で実行される。予測ブロックの一例として輝度予測ブロックを使用すると、予測ブロックは、8×8の画素、16×16の画素、8×16の画素、16×8の画素等のように、画素の値(例えば、輝度値)の行列を含む。
図7は、本開示の他の実施形態によるビデオエンコーダ(703)の図を示す。ビデオエンコーダ(703)は、ビデオピクチャのシーケンス内のカレントビデオピクチャ内のサンプル値の処理ブロック(例えば、予測ブロック)を受信し、処理ブロックを符号化ビデオシーケンスの一部である符号化ピクチャに符号化するように構成される。一例では、ビデオエンコーダ(703)は、図4の例のビデオエンコーダ(403)の代わりに使用される。
HEVCの例では、ビデオエンコーダ(703)は、8×8のサンプルの予測ブロック等のような処理ブロックのサンプル値の行列を受信する。ビデオエンコーダ(703)は、処理ブロックが、例えば、レート歪み最適化を使用して、イントラモードを使用して最も良く符号化されるか、インターモードを使用して最も良く符号化されるか、双方向予測モードを使用して最も良く符号化されるかを決定する。処理ブロックがイントラモードで符号化される場合、ビデオエンコーダ(703)は、処理ブロックを符号化ピクチャに符号化するためにイントラ予測技術を使用してもよい。処理ブロックがインターモード又は双方向予測モードで符号化される場合、ビデオエンコーダ(703)は、処理ブロックを符号化ピクチャに符号化するために、それぞれインター予測技術又は双方向予測技術を使用してもよい。特定のビデオ符号化技術では、マージモード(merge mode)は、動きベクトル予測子以外の符号化された動きベクトル成分の恩恵を受けずに、動きベクトルが1つ以上の動きベクトル予測子から導出されるインターピクチャ予測サブモードでもよい。特定の他のビデオ符号化技術では、対象のブロックに適用可能な動きベクトル成分が存在してもよい。一例では、ビデオエンコーダ(703)は、処理ブロックのモードを決定するためのモード決定モジュール(図示せず)のような他の構成要素を含む。
図7の例では、ビデオエンコーダ(703)は、図7に示されるように共に結合されたインターエンコーダ(730)と、イントラエンコーダ(722)と、残差計算器(723)と、スイッチ(726)と、残差エンコーダ(724)と、全体コントローラ(721)と、エントロピーエンコーダ(725)とを含む。
インターエンコーダ(730)は、カレントブロック(例えば、処理ブロック)のサンプルを受信し、当該ブロックを参照ピクチャ内の1つ以上の参照ブロック(例えば、前のピクチャ及び後のピクチャ内のブロック)と比較し、インター予測情報(例えば、インター符号化技術による冗長情報の記述、動きベクトル、マージモード情報)を生成し、いずれかの適切な技術を使用して、インター予測情報に基づいてインター予測結果(例えば、予測ブロック)を計算するように構成される。いくつかの例では、参照ピクチャは、符号化ビデオ情報に基づいて復号された復号参照ピクチャである。
イントラエンコーダ(722)は、カレントブロック(例えば、処理ブロック)のサンプルを受信し、場合によっては、当該ブロックを、同じピクチャ内で既に符号化されたブロックと比較し、変換後に量子化係数を生成し、場合によっては、イントラ予測情報(例えば、1つ以上のイントラ符号化技術によるイントラ予測方向情報)も生成するように構成される。また、一例では、イントラエンコーダ(722)は、同じピクチャ内のイントラ予測情報及び参照ブロックに基づいて、イントラ予測結果(例えば、予測ブロック)を計算する。
全体コントローラ(721)は、全体制御データを決定し、全体制御データに基づいてビデオエンコーダ(703)の他の構成要素を制御するように構成される。一例では、全体コントローラ(721)は、ブロックのモードを決定し、当該モードに基づいて制御信号をスイッチ(726)に提供する。例えば、モードがイントラモードである場合、全体コントローラ(721)は、残差計算器(723)によって使用されるイントラモード結果を選択するようにスイッチ(726)を制御し、イントラ予測情報を選択してイントラ予測情報をビットストリームに含めるようにエントロピーエンコーダ(725)を制御する。モードがインターモードである場合、全体コントローラ(721)は、残差計算器(723)によって使用されるインター予測結果を選択するようにスイッチ(726)を制御し、インター予測情報を選択してインター予測情報をビットストリームに含めるようにエントロピーエンコーダ(725)を制御する。
残差計算器(723)は、受信したブロックと、イントラエンコーダ(722)又はインターエンコーダ(730)から選択された予測結果との差(残差データ)を計算するように構成される。残差エンコーダ(724)は、残差データに基づいて動作し、残差データを符号化して変換係数を生成するように構成される。一例では、残差エンコーダ(724)は、残差データを空間ドメインから周波数ドメインに変換し、変換係数を生成するように構成される。次いで、変換係数は、量子化された変換係数を取得するための量子化処理を受ける。また、様々な実施形態では、ビデオエンコーダ(703)は、残差デコーダ(728)も含む。残差デコーダ(728)は、逆変換を実行し、復号された残差データを生成するように構成される。復号された残差データは、イントラエンコーダ(722)及びインターエンコーダ(730)によって適切に使用されてもよい。例えば、インターエンコーダ(730)は、復号された残差データ及びインター予測情報に基づいて復号ブロックを生成してもよく、イントラエンコーダ(722)は、復号された残差データ及びイントラ予測情報に基づいて復号ブロックを生成してもよい。復号ブロックは、復号ピクチャを生成するように適切に処理され、復号ピクチャは、メモリ回路(図示せず)にバッファされ、いくつかの例では参照ピクチャとして使用されてもよい。
エントロピーエンコーダ(725)は、符号化ブロックを含めるようにビットストリームをフォーマットするように構成される。エントロピーエンコーダ(725)は、HEVC標準のような適切な標準に従った様々な情報を含めるように構成される。一例では、エントロピーエンコーダ(725)は、全体制御データと、選択された予測情報(例えば、イントラ予測情報又はインター予測情報)と、残差情報と、他の適切な情報とをビットストリームに含めるように構成される。開示の対象物によれば、インターモード又は双方向予測モードのいずれかのマージサブモードでブロックを符号化する場合、残差情報は存在しない点に留意すべきである。
図8は、本開示の他の実施形態によるビデオデコーダ(810)の図を示す。ビデオデコーダ(810)は、符号化ビデオシーケンスの一部である符号化ピクチャを受信し、符号化ピクチャを復号して復元ピクチャを生成するように構成される。一例では、ビデオデコーダ(810)は、図4の例のビデオデコーダ(410)の代わりに使用される。
図8の例では、ビデオデコーダ(810)は、図8に示されるように共に結合されたエントロピーデコーダ(871)と、インターデコーダ(880)と、残差デコーダ(873)と、復元モジュール(874)と、イントラデコーダ(872)とを含む。
エントロピーデコーダ(871)は、符号化ピクチャから、当該符号化ピクチャが構成されるシンタックスエレメントを表す特定のシンボルを復元するように構成されてもよい。このようなシンボルは、例えば、ブロックが符号化されるモード(例えば、イントラモード、インターモード、双方向予測モード、マージサブモード又は他のサブモードにおける後者の2つ等)、それぞれイントラデコーダ(872)又はインターデコーダ(880)によって予測のために使用される特定のサンプル又はメタデータを識別できる予測情報(例えば、イントラ予測情報又はインター予測情報等)、例えば、量子化された変換係数の形式の残差情報等を含んでもよい。一例では、予測モードがインターモード又は双方向予測モードである場合、インター予測情報はインターデコーダ(880)に提供され、予測タイプがイントラ予測タイプである場合には、イントラ予測情報がイントラデコーダ(872)に提供される。残差情報は、逆量子化を受けてもよく、残差デコーダ(873)に提供される。
インターデコーダ(880)は、インター予測情報を受信し、インター予測情報に基づいてインター予測結果を生成するように構成される。
イントラデコーダ(872)は、イントラ予測情報を受信し、イントラ予測情報に基づいて予測結果を生成するように構成される。
残差デコーダ(873)は、逆量子化された変換係数を抽出するための逆量子化を実行し、逆量子化された変換係数を処理して残差を周波数ドメインから空間ドメインに変換するように構成される。また、残差デコーダ(873)は、特定の制御情報(量子化パラメータ(QP, Quantizer Parameter)を含む)を必要としてもよく、その情報は、エントロピーデコーダ(871)によって提供されてもよい(これは低ボリュームの制御情報のみである可能性があるので、データ経路は図示されていない)。
復元モジュール(874)は、空間ドメインにおいて、残差デコーダ(873)によって出力された残差と、予測結果(場合によっては、インター予測モジュール又はイントラ予測モジュールによって出力されたもの)とを結合して復元ブロックを形成するように構成され、当該復元ブロックは、復元ピクチャの一部でもよく、また、復元ビデオの一部でもよい。視覚品質を改善するために、デブッキング動作のような他の適切な動作が実行されてもよい点に留意すべきである。
ビデオエンコーダ(403)、(603)及び(703)並びにビデオデコーダ(410)、(510)及び(810)は、いずれかの適切な技術を使用して実装されてもよい点に留意すべきである。一実施形態では、ビデオエンコーダ(403)、(603)及び(703)並びにビデオデコーダ(510)、(610)及び(810)は、1つ以上の集積回路を使用して実装されてもよい。他の実施形態では、ビデオエンコーダ(403)、(603)及び(703)並びにビデオデコーダ(410)、(510)及び(810)は、ソフトウェア命令を実行する1つ以上のプロセッサを使用して実装されてもよい。
本開示の態様は、四分木分割のための最小サイズを制限する技術を提供する。
ビットストリームを介して与えられるソースピクチャと復号ピクチャとの間の例示的な関係について、以下に説明する。ビットストリームによって表されるビデオソースは、復号順のピクチャのシーケンスでもよい。ソースピクチャ及び復号ピクチャは、(1)輝度(Y)のみ(モノクロ)、(2)輝度及び2つの色差(例えば、YCbCr又はYCgCo)、(3)緑、青及び赤(GBR、RGBとしても知られる)、並びに(4)他の不特定のモノクロ又は3刺激カラーサンプリング(例えば、YZX、XYZとしても知られる)を表す配列のような1つ以上のサンプル配列をそれぞれ含んでもよい。
開示における表記及び用語の便宜上、上述の配列に関連する変数及び用語は、輝度(又はL若しくはY)及び色差と呼ばれてもよく、2つの色差配列は、使用されている実際の色表現方法にかかわらず、Cb及びCrと呼ばれてもよい。使用されている実際の色表現方法は、シンタックスによって更に示されてもよい。
いくつかの実施形態では、複数のサンプル配列が使用される場合、サンプル配列のうち1つが参照サンプル空間として使用されてもよく、他のサンプル配列は、サンプリング比に基づいて参照サンプル空間から導出されてもよい。一例では、輝度及び色差配列(又はブロック)が使用される場合、輝度サンプル配列は参照サンプル空間として使用されてもよく、色差配列は、サブサンプリング係数に基づいて参照サンプル空間から導出されてもよい。一例では、輝度配列及び色差配列がソース及び復号ピクチャに含まれ、次いで、色差ブロックと対応する輝度ブロックとの間の色差水平サブサンプリング係数(例えば、SubWidthC)及び色差垂直サブサンプリング係数(例えば、SubHeightC)のようなサブサンプリング係数が指定されてもよい。
図9は、変数SubWidthC及びSubHeightC(色差サブサンプリング比とも呼ばれる)を指定するための表(表1)を示す。一例では、色差フォーマットを指定するために、chroma_format_idc及びseparate_colour_plane_flagのようなインデックス及びフラグが使用されてもよく、次いで、変数SubWidthC及びSubHeightCが色差フォーマットに基づいて決定されてもよい。他の例では、色差フォーマットを指定するために、chroma_format_idcのようなインデックスが使用されてもよく、次いで、変数SubWidthC及びSubHeightCが色差フォーマットに基づいて決定されてもよい。いくつかの例では、chroma_format_idc及び対応するSubWidthC及びSubHeightCの他の適切な値も指定されてもよい点に留意すべきである。
図9を参照すると、色差フォーマットインデックス(例えば、chroma_format_idc)が0である場合、色差サブサンプリングフォーマットは、名目上で輝度配列と考えられる1つのサンプル配列のみを有するモノクロサンプリングに対応する「モノクロ」でもよい。
色差フォーマットインデックスが1である場合、色差サブサンプリングフォーマットは4:2:0又は4:2:0サンプリングでもよく、2つの色差配列のそれぞれは、対応する輝度配列の半分の高さ及び半分の幅を有する。
色差フォーマットインデックスが2である場合、色差サブサンプリングフォーマットは4:2:2又は4:2:2サンプリングでもよく、2つの色差配列のそれぞれは、輝度配列の同じ高さ及び半分の幅を有する。
色差フォーマットインデックスが3である場合、色差サブサンプリングフォーマットは、セパレート色平面フラグ(例えば、separate_colour_plane_flag)の値に依存して、4:4:4又は4:4:4サンプリングでもよく、以下の条件が当てはまる。(i)セパレート色平面フラグが0に等しい場合、2つの色差配列のそれぞれは、輝度配列と同じ高さ及び幅を有する。(ii)そうでなく、セパレート色平面フラグが1に等しい場合、3つの色平面はモノクロサンプルピクチャとして別々に処理されてもよい。
ビデオシーケンスにおける輝度配列及び色差配列内のサンプルのそれぞれの表現に使用されるビットの数は、8ビット以上16ビット以下の範囲でもよく、輝度配列に使用されるビットの数は、色差配列に使用されるビットの数と異なってもよい。
図10A~10Cは、本開示の実施形態による、それぞれのピクチャにおける対応する輝度サンプル及び色差サンプルの公称上の垂直及び水平相対位置を示す。別の色差サンプルの相対位置が、ビデオユーザビリティ情報において示されてもよい。
図10Aを参照すると、一例では、色差フォーマットインデックスの値(例えば、chroma_format_idc)は1に等しく、したがって、色差フォーマットは4:2:0である。図10Aは、ピクチャ内の対応する輝度サンプル及び色差サンプルの公称上の垂直位置及び水平位置の一例を示す。いくつかの例では、色差サンプルは2つの隣接輝度サンプル位置の間で垂直に配置され、輝度サンプル位置において水平に配置される。
図10Bを参照すると、色差フォーマットインデックスの値は2に等しく、したがって、色差フォーマットは4:2:2である。いくつかの例では、色差サンプルは、ピクチャ内の対応する輝度サンプルと共配置される(又は同一場所に配置される)。図10Bは、ピクチャ内の対応する輝度サンプル及び色差サンプルの公称上の垂直位置及び水平位置の一例を示す。
図10Cを参照すると、色差フォーマットインデックスの値が3に等しい場合、全ての配列のサンプル(例えば、輝度配列のサンプル及び色差配列のサンプル)は共配置されてもよい(或いは同一位置に配置されてもよい)。図10Cは、ピクチャ内の対応する輝度サンプル及び色差サンプルの公称上の垂直位置及び水平位置の一例を示す。
VVCのような分割の例について以下に説明する。一実施形態では、ピクチャはCTUに分割されてもよい。ピクチャはCTUのシーケンスに分割されてもよい。3つのサンプル配列を有するピクチャについて、CTUは輝度サンプルのN×Nブロック(例えば、輝度ブロック)及び色差サンプルの2つの対応するブロック(例えば2つの色差ブロック)で構成される。図11は、本開示の一実施形態に従ってCTU(1101)に分割されたピクチャ(1100)の一例を示す。一例では、CTUにおける輝度ブロックの最大許容サイズは128×128として指定される。一例では、輝度変換ブロックの最大サイズは64×64である。
ピクチャはスライス、タイル又はブリック(brick)に分割されてもよい。ピクチャは、1つ以上のタイル行及び1つ以上のタイル列に分割されてもよい。タイルは、ピクチャの矩形領域をカバーするCTUのシーケンスでもよい。タイルは、1つ以上のブリックに分割されてもよく、ブリックのそれぞれは、タイル内の複数のCTU行を含んでもよい。複数のブリックに分割されないタイルもブリックと呼ばれる。しかし、タイルの真のサブセットであるブリックはタイルと呼ばれない。
スライスは、ピクチャ内の複数のタイル又はタイル内の複数のブリックを含んでもよい。2つのモードのスライス、例えば、ラスタスキャンスライスモード及び矩形スライスモードがサポートされてもよい。ラスタスキャンスライスモードでは、スライスは、ピクチャのタイルラスタスキャンにおけるタイルのシーケンスを含んでもよい。矩形スライスモードでは、スライスは、ピクチャの矩形領域を併せて形成し得るピクチャの複数のブリックを含んでもよい。矩形スライス内のブリックは、スライスのブリックラスタスキャンの順序にある。
ピクチャは、タイル又はラスタスキャンスライスに分割されてもよい。図12は、本開示の実施形態によるピクチャ(1200)のラスタスキャンスライス分割の例を示す。ピクチャ(1200)は12個のタイル(1201)~(1212)(例えば、3つの列(又はタイル列)及び4つの行(又はタイル行)における12個のタイル)と、3つのラスタスキャンスライス(1221)~(1223)とに分割されてもよい。例えば、ラスタスキャンスライス(1221)はタイル(1201)~(1202)を含み、ラスタスキャンスライス(1222)はタイル(1203)~(1207)を含み、ラスタスキャンスライス(1223)はタイル(1208)~(1212)を含む。
ピクチャは、タイル及び矩形スライスに分割されてもよい。図13は、本開示の実施形態によるピクチャ(1300)の矩形スライス分割の例を示す。ピクチャ(1300)は24個のタイル(1301)~(1324)(例えば、6つの列(又はタイル列)及び4つの行(又はタイル行)における24個のタイル)と、9つの矩形スライス(1331)~(1339)とに分割される。例えば、矩形スライス(1331)はタイル(1301)~(1302)を含み、矩形スライス(1332)はタイル(1303)~(1304)を含み、矩形スライス(1333)はタイル(1305)~(1306)を含み、矩形スライス(1334)はタイル(1307)、(1308)、(1313)及び(1314)を含み、矩形スライス(1335)はタイル(1309)、(1310)、(1315)及び(1316)を含み、矩形スライス(1336)はタイル(1311)、(1312)、(1317)及び(1318)を含み、矩形スライス(1337)はタイル(1319)~(1320)を含み、矩形スライス(1338)はタイル(1321)~(1322)を含み、矩形スライス(1339)はタイル(1323)~(1324)を含む。
ピクチャは、タイル、ブリック及び矩形スライスに分割されてもよい。図14は、本開示の実施形態に従ってタイル、ブリック(1401)~(1411)及び矩形スライスに分割されたピクチャ(1400)の例を示しており、ピクチャは、4つのタイル(2つのタイル列及び2つのタイル行)と、11個のブリック(1401)~(1411)と、4つの矩形スライス(1421)~(1424)とに分割されてもよい。左上のタイルは1つのブリック(1401)を含み、右上のタイルは5つのブリック(1402)~(1406)を含み、左下のタイルは2つのブリック(1407)~(1408)を含み、右下のタイルは3つのブリック(1409)~(1411)を含む。矩形スライス(1421)はブリック(1401)、(1407)及び(1408)を含み、矩形スライス(1422)はブリック(1402)及び(1403)を含み、矩形スライス(1423)はブリック(1404)~(1406)を含み、矩形スライス(1424)はブリック(1409)~(1411)を含む。
CTUはツリー構造を使用して分割されてもよい。一実施形態では、例えばHEVCにおいて、CTUは、様々な局所特性に適応するために、符号化ツリーとして示される四分木又はQT構造を使用することによってCUに分割されてもよい。ピクチャ領域をインターピクチャ(時間)を使用して符号化するか、イントラピクチャ(空間)予測を使用して符号化するかの決定は、リーフCUレベルにおいて行われてもよい。各リーフCUは、PU分割タイプに従って1つのPU、2つのPU又は4つのPUに更に分割されてもよい。1つのPUの中では、同じ予測プロセスが適用されてもよく、関連情報がPUベースでデコーダに送信されてもよい。PU分割タイプに基づいて予測プロセスを適用することによって残差ブロックを取得した後に、リーフCUは、CUについての符号化ツリーと同様のQT構造に従って変換ユニット(TU, transform unit)に分割されてもよい。HEVC構造のような例では、CU、PU及びTUのような複数の分割単位は異なってもよい。
VVCのような一実施形態では、二分木及び三分木分割のセグメンテーション構造を使用するネスト構造マルチタイプツリーを有する四分木は、複数の分割ユニットタイプの概念を置き換えてもよく、したがって、CU、PU及びTU概念の分離を除去してもよく、CU分割形状についてより高い柔軟性をサポートしてもよい。いくつかの例では、CUが最大変換長にとって大きすぎるサイズを有する場合、異なるサイズがCU、PU及び/又はTUに使用されてもよい。符号化ツリー構造では、CUは正方形又は矩形のいずれかの形状を有してもよい。CTUは、まず、QT構造によって分割される。次いで、QTリーフノードは、マルチタイプツリー(MTT, multi―type tree)構造によって更に分割されてもよい。
図15は、本開示の実施形態によるMTT構造における例示的な分割タイプ(1521)~(1524)を示す。分割タイプ(1521)~(1524)は、垂直二分割(SPLIT_BT_VER)(1521)、水平二分割(SPLIT_BT_HOR)(1522)、垂直三分割(SPLIT_TT_VER)(1523)及び水平三分割(SPLIT_TT_HOR)(1524)を含んでもよい。MTTリーフノードはCUと呼ばれてもよく、CUが最大変換長にとって大きすぎない限り、このセグメンテーション(又はCU)は、更なる分割なしに予測及び変換処理に使用されてもよい。これは、ほとんどの場合、CU、PU及びTUが、ネスト構造MTT符号化ブロック構造を有するQTにおいて同じブロックサイズを有してもよいことを意味する。例外は、最大でサポートされる変換長がCUの色成分の幅又は高さよりも小さい場合に生じる。
図16は、本開示の一実施形態によるネスト構造MTT符号化ツリー構造を有するQTについての分割フラグの伝達の例を示す。図16は、ネスト構造MTT符号化ツリー構造を有するQTにおける部分分割情報の例示的な伝達メカニズムを示す。CTUのようなノード(1611)はQTのルートとして扱われてもよく、まず、QTノード(1621)を生成するためのQT分割フラグ(例えば、qt_split_flag)が真(例えば、値「1」)である場合、QT構造によってQTノードに分割されてもよい。QT分割フラグ(例えば、qt_split_flag)が偽(例えば、値「0」)である場合、ノード(1611)はQT分割を使用して分割されず、したがって、QTリーフノード(1611)と呼ばれてもよい。各QTリーフノード(許容するのに十分に大きい場合)は、MTT構造によって更に分割されてもよく、MTTノードと呼ばれてもよい。図16を参照すると、QTリーフノード又はMTTノード(1611)は、MTT分割を使用して更に分割されてもよい。
MTT構造では、第1のフラグ(例えば、mtt_split_cu_flag)は、ノード(1611)が更に分割されるか否かを示すために伝達されてもよい。ノード(1611)が分割されない場合(例えば、mtt_split_cu_flagが「0」である場合)、ノード(1611)はMTTリーフノード(1611)と呼ばれる。ノード(1611)が更に分割される場合(例えば、mtt_split_cu_flagが「1」である場合)、第2のフラグ(例えば、mtt_split_cu_vertical_flag flag)は、分割方向(水平分割又は垂直分割)を示すために伝達されてもよく、次いで、第3のフラグ(例えば、mtt_split_cu_binary_flag)は、分割が二分木分割であるか三分木分割であるかを示すために伝達されてもよい。したがって、MTTノード(1651)は、ノード(1611)の垂直二分割(例えば、BT_VER_split)に基づいて生成され、MTTノード(1652)は、ノード(1611)の垂直三分割(例えば、TT_VER_split)に基づいて生成され、MTTノード(1653)は、ノード(1611)の水平二分割(例えば、BT_HOR_split)に基づいて生成され、MTTノード(1654)は、ノード(1611)の水平三分割(例えば、TT_ HOR_split)に基づいて生成される。
図17を参照すると、第2のフラグ(例えば、mtt_split_cu_vertical_flag)及び第3のフラグ(例えば、mtt_split_cu_binary_flag)の値に基づいて、CUのMTT分割モード(例えば、MttSplitMode)は表2に示すように導出されてもよい。MTT分割モードは、垂直二分割(例えば、BT_VER_split又はSPLIT_BT_VER)、垂直三分割(例えば、TT_VER_split又はSPLIT_TT_VER)、水平二分割(例えば、BT_HOR_split又はSPLIT_BT_HOR)及び水平三分割(例えば、TT_ HOR_split又はSPLIT_TT_HOR)を含んでもよい。
図18は、本発明の一実施形態によるネスト構造MTT符号化ブロック構造を有するQTの一例を示す。CTU(1800)は、QT及びネスト構造MTT符号化ブロック構造によって複数のCUに分割されてもよく、太字のブロック境界線はQT分割を表し、残りの境界線はMTT分割を表す。ネスト構造MTT分割を有するQTは、CUを含むコンテンツ適応符号化ツリー構造を提供してもよい。CUのサイズは、CTU(1800)と同じ大きさでもよく、或いは、輝度サンプルの単位の4×4ほど小さくてもよい。一例では、4:2:0色差フォーマットの場合、最大色差CBサイズは64×64でもよく、最小色差CBサイズは2×2でもよい。
VVCのような一例では、最大でサポートされる輝度変換サイズは64×64であり、最大でサポートされる色差変換サイズは32×32である。CBの幅又は高さが最大変換幅又は高さよりも大きい場合、CBは、それぞれの方向の変換サイズの制限を満たすように、自動的に水平方向及び/又は垂直方向に分割されてもよい。
以下のパラメータが定義され、ネスト構造MTT符号化ツリー方式を有するQTについてのシーケンスパラメータセット(SPS, sequence parameter set)シンタックスエレメントによって指定されてもよい。以下のパラメータは、(1)QTツリーのルートノードサイズであるCTUサイズ、(2)最小許容QTリーフノードサイズであるMinQTSize、(3)最大許容BTルートノードサイズであるMaxBtSize、(4)最大許容TTルートノードサイズであるMaxTtSize、(5)QTリーフからのMTT分割の最大許容階層深さであるMaxMttDepth、(6)最小許容BTリーフノードサイズであるMinBtSize、(7):最小許容TTリーフノードサイズであるMinTtSize等を含んでもよい。
ネスト構造MTT符号化ツリー構造を有するQTの一例では、CTUサイズは4:2:0色差サンプルの2つの対応する64×64ブロックを有する128×128輝度サンプルとして設定され、MinQTSizeは16×16として設定され、MaxBtSizeは128×128として設定され、MaxTtSizeは64×64として設定され、MinBtSize及びMinTtSize(幅及び高さの双方)は4×4として設定され、MaxMttDepthは4として設定される。QT分割が最初にCTUに適用され、QTリーフノードを生成する。QTリーフノードは、16×16(例えば、MinQTSize)から128×128(例えば、CTUサイズ)までのサイズを有してもよい。一例では、QTリーフノードが128×128である場合、サイズがMaxBtSize及びMaxTtSize(例えば、64×64)を超えるので、QTリーフノードはBTによって更に分割されない。そうでない場合、QTリーフノードは、MTTによって更に分割されてもよい。したがって、QTリーフノードはMTTのルートノードでもよく、0のMTT深さ(例えば、MttDepth)を有してもよい。MTT深さがMaxMttDepth (例えば、4)に達した場合、更なる分割は考慮されない。MTTノードがMinBtSizeに等しく2×MinTtSize以下の幅を有する場合、更なる水平分割は考慮されない。同様に、MTTノードがMinBtSizeに等しく2×MinTtSize以下の高さを有する場合、更なる垂直分割は考慮されない。
一実施形態では、VVCハードウェアデコーダ等において64×64輝度ブロック及び32×32色差パイプライン設計を可能にするために、図19に示すように、輝度符号化ブロックの幅又は高さのいずれかが第1の閾値(例えば、64)よりも大きい場合、TT分割は禁止されてもよい。したがって、128×128輝度符号化ブロックのように、64よりも大きい輝度符号化ブロックにTT分割は適用されない。色差符号化ブロックの幅又は高さのいずれかが第2の閾値(例えば、32)よりも大きい場合にも、TT分割が禁止されてもよい。図19を参照すると、第1の閾値は64であり、輝度符号化ブロック(1911)~(1915)は128×128のサイズを有するので、輝度符号化ブロック(1911)~(1915)においてTT分割は禁止される。例えば、輝度符号化ブロック(1911)は分割されず、輝度符号化ブロック(1912)~(1913)はBTを使用して分割される。輝度符号化ブロック(1914)~(1915)は、まず、64×64ブロックにQT分割される。続いて、TT分割が、64×64のサイズを有する輝度符号化ブロック(1921)~(1922)に適用されてもよい。
一実施形態では、符号化ツリー方式は、輝度成分及び対応する色差成分が別個のブロックツリー構造を有する能力をサポートする。例えば、Pスライス及びBスライスについて、CTU内の輝度CTB及び色差CTBは同じ符号化ツリー構造(例えば、シングルツリー)を共有する。Iスライスについては、CTU内の輝度CTB及び色差CTBは別個のブロックツリー構造(例えば、デュアルツリー)を有してもよく、別個のブロックツリー構造を使用したCTUの分割の場合は、デュアルツリー分割と呼ばれる。デュアルツリー分割が適用される場合、輝度CTBは輝度符号化ツリー構造(例えば、DUAL_TREE_LUMA)によって輝度CUに分割されてもよく、色差CTBは色差符号化ツリー構造(例えば、DUAL_TREE_CHROMA)によって色差CUに分割されてもよい。したがって、Iスライス内のCUは、輝度成分の符号化ブロックを含んでもよく或いは2つの色差成分の符号化ブロックを含んでもよく、Pスライス又はBスライス内のCUは、ビデオがモノクロでない限り、常に全ての3つの色成分の符号化ブロックを含む。
以下に説明するように、CUは、ピクチャ境界(境界とも呼ばれる)で分割されてもよい。HEVCのような一例では、ツリーノードブロックの一部が下側ピクチャ境界又は右側ピクチャ境界を超える場合、ツリーノードブロックは、各符号化CUの全てのサンプルがピクチャ境界内に位置するまで、強制的に分割される。
いくつかの実施形態では、以下の分割規則が適用されてもよい。
―ツリーノードブロックの一部が下側ピクチャ境界及び右側ピクチャ境界の双方を超える場合、
・ツリーノードブロックがQTノードであり、ツリーノードブロックのサイズが最小QTサイズよりも大きい場合、ツリーノードブロックはQT分割モードで強制的に分割される。
・そうでない場合は、ツリーノードブロックはSPLIT_BT_HORモードで強制的に分割される。
―そうでなく、ツリーノードブロックの一部が下側ピクチャ境界を超える場合、
・ツリーノードブロックがQTノードであり、ツリーノードブロックのサイズが最小QTサイズよりも大きく、ツリーノードブロックのサイズが最大BTサイズよりも大きい場合、ツリーノードブロックはQT分割モードで強制的に分割される。
・そうでなく、ツリーノードブロックがQTノードであり、ツリーノードブロックのサイズが最小QTサイズよりも大きく、ツリーノードブロックのサイズが最大BTサイズ以下である場合、ツリーノードブロックはQT分割モード又はSPLIT_BT_HORモードで強制的に分割される。
・そうでない場合(ツリーノードブロックがBTTノードである場合、又はツリーノードブロックのサイズが最小QTサイズ以下である場合)、ツリーノードブロックはSPLIT_BT_HORモードで強制的に分割される。
―そうでなく、ツリーノードブロックの一部が右側ピクチャ境界を超える場合、
・ツリーノードブロックがQTノードであり、ツリーノードブロックのサイズが最小QTサイズよりも大きく、ツリーノードブロックのサイズが最大BTサイズよりも大きい場合、ツリーノードブロックはQT分割モードで強制的に分割される。
・そうでなく、ツリーノードブロックがQTノードであり、ツリーノードブロックのサイズが最小QTサイズよりも大きく、ツリーノードブロックのサイズが最大BTサイズ以下である場合、ツリーノードブロックはQT分割モード又はSPLIT_BT_VERモードで強制的に分割される。
・そうでない場合(ツリーノードブロックがBTTノードである場合、又はツリーノードブロックのサイズが最小QTサイズ以下である場合)、ツリーノードブロックはSPLIT_BT_VERモードで強制的に分割される。
冗長なCU分割に対する制限が使用されてもよい。ネスト構造MTT符号化ブロック構造を有するQTは、柔軟なブロック分割構造を提供してもよい。MTTにおいてサポートされる分割のタイプのため、異なる分割パターンは、潜在的に同じ符号化ブロック構造を生じる可能性がある。VVCのような一例では、特定の冗長な分割パターンは許容されない。
図20は、本開示の実施形態によるBT分割及びTT分割の冗長な分割パターンの例を示す。或る方向における2つのレベルの連続したBT分割は、TT分割に続く中央部分のBT分割と同じ符号化ブロック構造を有し得る。上記の場合、TT分割の中央部分についてのBT分割(所与の方向)は、例えば、シンタックスによって禁止されてもよい(例えば、許容されない)。一例では、上記の制限は、各ピクチャのCUに適用される。
一例では、符号化ブロック構造(2001)は、垂直方向の2つのレベルの連続したBT分割(例えば、第1のレベルのBT分割(2011)に続いて第2のレベルのBT分割(2021)―(2022))によって生成される。符号化ブロック構造(2002)は、垂直TT分割(2012)に続いて垂直TT分割(2012)の中央部分の垂直BT分割(2023)によって生成されてもよい。符号化ブロック構造(2001)は、符号化ブロック構造(2002)と同じであり、したがって、TT分割(2012)の中央部分についてのBT分割(2023)(垂直方向)は、例えば、シンタックスにより禁止される。
一例では、符号化ブロック構造(2003)は、水平方向の2つのレベルの連続したBT分割(例えば、第1のレベルのBT分割(2013)に続いて第2のレベルのBT分割(2024)―(2025))によって生成される。符号化ブロック構造(2004)は、垂直TT分割(2014)に続いて水平TT分割(2014)の中央部分の水平BT分割(2026)によって生成されてもよい。符号化ブロック構造(2003)は、符号化ブロック構造(2004)と同じでもよく、したがって、TT分割(2014)の中央部分についてのBT分割(2026)(水平方向)は、例えば、シンタックスにより禁止される。
上記のように分割が禁止される場合、禁止された場合を考慮するために、対応するシンタックスエレメントの伝達が変更されてもよい。例えば、図20を参照すると、或る場合が識別された場合(例えば、中央部分のCUについてBT分割(2023)又は(2026)が禁止される場合)、分割がBT分割であるかTT分割であるかを指定するシンタックスエレメント(例えば、mtt_split_cu_binary_flag)は伝達されず、デコーダによって0に等しいと推定される。したがって、当該CUについてBT分割は禁止される。
仮想パイプラインデータユニット(VPDU, virtual pipeline data unit)は、ピクチャ内の重複しないユニットとして定義されてもよい。ハードウェアデコーダでは、連続するVPDUが複数のパイプライン段によって同時に処理されてもよい。VPDUサイズはほとんどのパイプライン段においてバッファサイズにほぼ比例し得るので、比較的小さいVPDUサイズを保持することが重要である。ほとんどのハードウェアデコーダのような様々な例では、VPDUサイズは最大変換ブロック(TB, transport block)サイズに設定されてもよい。VVCのようないくつかの例では、TT分割及びBT分割はVPDUサイズの増加をもたらす可能性がある。VPDUサイズを64×64輝度サンプルのような特定のサイズに保持するために、図21に示すように、以下の標準的な分割制限(シンタックス伝達の変更を伴う)が適用されてもよい。図21は、本開示の実施形態による許容不可能なTT分割及びBT分割の例を示す。
―幅、高さ又は幅及び高さの双方が128に等しいCUについて、TT分割は許容されない。例えば、TT分割(2001)、(2002)及び(2005)~(2008)は許容されない。
―128×N(N≦64)のCU(すなわち、幅が128に等しく高さが128よりも小さい)について、水平BTは許容されない。例えば、128×64のCUについて、水平BT分割(2004)は許容されない。
―N×128(N≦64)のCU(すなわち、高さが128に等しく幅が128よりも小さい)について、垂直BTは許容されない。例えば、64×128のCUについて、垂直BT分割(2003)は許容されない。
イントラ色差分割及び予測の制限について以下に説明する。イントラピクチャにおけるデュアルツリー(dual tree)は、輝度符号化ツリーと比較して色差符号化ツリーで異なる分割を適用することが可能であるので、デュアルツリーは、より長い符号化パイプラインを導入する可能性がある。QTBTのMinQTSizeC値の範囲、色差符号化ツリーにおけるMinBtSizeY及びMinTTSizeYは、2×2、4×2及び2×4のような小さい色差ブロックを許容し得る。一例として、MinQTSizeCは、最小許容色差QTリーフノードサイズを示す。したがって、実際のデコーダ設計が問題になり得る。さらに、クロスコンポーネント線形モデル(CCLM, cross―component linear model)、プラナーモード及び角度モードのような特定の予測モードは乗算を使用し得る。上記の問題を軽減するために、小さい色差ブロックサイズ(例えば、2×2、2×4及び/又は4×2)は、分割制限としてデュアルツリーにおいて制限されてもよい。
様々なハードウェアビデオエンコーダ及びデコーダでは、例えば、隣接するイントラブロックの間のサンプル処理データ依存性のため、ピクチャがより小さいイントラブロックを有する場合に処理スループットが減少し得る。イントラブロックの予測子生成は、隣接ブロックからの上側及び左側境界の復元サンプルを使用してもよい。したがって、一例では、イントラ予測はブロック毎に順次処理されるべきである。
HEVCのようないくつかの例では、最小イントラCUは8×8輝度サンプルである。最小イントラCUの輝度成分は、4つの4×4輝度イントラPUに更に分割されてもよく、最小イントラCUの色差成分は更に分割されなくてもよい。したがって、一例では、最悪の場合のハードウェア処理スループットは、4×4色差イントラブロック又は4×4輝度イントラブロックが処理されるときに発生し得る。いくつかの例では、最悪の場合のスループットを改善するために、色差イントラCBの分割を制限することによって、16個の色差サンプルよりも小さい色差イントラCBは許容されない。単一の符号化ツリーにおいて、最小色差イントラ予測ユニット(SCIPU, smallest chroma intra prediction unit)は、色差ブロックサイズが16個の色差サンプル以上であり、64個の輝度サンプルよりも小さい少なくとも1つの子輝度ブロックを有する符号化ツリーノードとして定義されてもよい。各SCIPUにおいて、全てのCBはインター予測されるか或いはインター予測されない(例えば、イントラ予測又はイントラブロックコピー(IBC, intra block copy))。非インターSCIPUについて、一例では、非インターSCIPUの色差CBが更に分割されず、SCIPUの輝度CBが更に分割されることが許容される。したがって、最小色差イントラCBサイズは16個の色差サンプルでもよく、したがって、2×2、2×4及び4×2の色差CBが除去されてもよい。さらに、一例では、色差スケーリングは、非インターSCIPUについて適用されない。ここでは、更なるシンタックスは伝達されず、SCIPUが非インター予測されるか否かは、SCIPUにおける最初の輝度CBの予測モードによって導出されてもよい。SCIPUのタイプ(インターSCIPU又は非インターSCIPU)は、カレントスライスがIスライスである場合、又はSCIPUが1回の更なる分割の後に4×4輝度部分を有する場合(例えば、VVCではインター4×4が許容されないため)、非インターであると推定されてもよい。そうでない場合、SCIPUのタイプは、SCIPUにおけるCUを解析する前に、フラグによって示されてもよい。さらに、ピクチャ幅及び高さをmax(8,MinCbSizeY)の倍数とみなすことで、ピクチャの角における2×2、2×4又は4×2イントラ色差ブロックを回避するようにピクチャサイズの制限が考慮されてもよい。
本開示のいくつかの態様によれば、シーケンスレベル(SPS)、ピクチャレベル(ピクチャヘッダ内)、符号化ツリーユニットレベル等のような様々なレベルの情報は、分割及びブロックサイズ関連のシンタックスを含んでもよい。
図22は、本開示の一実施形態による、シーケンスパラメータセット(SPS, sequence parameter set)についての例示的なシンタックス(2200)を示す。シンタックス(2200)は、生バイトシーケンスペイロード(RBSP, raw byte sequence payload)を含んでもよい。RBSPは、ネットワーク抽象化レイヤ(NAL, network abstraction layer)ユニットにカプセル化された整数のバイトを含むシンタックス構造を示してもよく、空であるか、或いは、RBSPストップビット及び0に等しいゼロ個以上の後続のビットが続くシンタックスエレメントを含むデータビット列の形式を有する。一例では、RBSPストップビットは、RBSPにおける最後の非ゼロビットである。
図23は、本開示の一実施形態によるピクチャヘッダ構造の例示的なシンタックス(2300)を示す。
図24A~24Bは、本開示の一実施形態による符号化ツリーユニットについての例示的なシンタックス(2400)を示す。
図25A~25Dは、本開示の一実施形態による符号化ツリーについての例示的なシンタックス(2500)を示す。
シンタックス(2200)、(2300)、(2400)及び(2500)は、以下に説明し得る分割及びブロックサイズ関連の意味を含む。
一例として、シーケンスパラメータセットRBSPの意味について以下に説明する。
1に等しいqtbtt_dual_tree_intra_flagは、Iスライスについて各CTUが暗示的なQT分割を使用して64×64輝度サンプルを有するCUに分割され、CUが輝度及び色差について2つの別個のcoding_treeシンタックス構造のルートになり得ることを指定してもよい。0に等しいqtbtt_dual_tree_intra_flagは、別個のcoding_treeシンタックス構造がIスライスに使用されないことを指定してもよい。qtbtt_dual_tree_intra_flagが存在しない場合、これは0に等しいと推定されてもよい。
変数log2_min_luma_coding_block_size_minus2に2を加算した値(すなわち、log2_min_luma_coding_block_size_minus2+2)は、最小輝度符号化ブロックサイズを指定する。log2_min_luma_coding_block_size_minus2の値の範囲は、0以上log2_ctu_size_minus5+3以下の範囲でもよい。
変数MinCbLog2SizeY、MinCbSizeY、IbcBufWidthY、IbcBufWidthC及びVsizeは、以下のように導出されてもよい。
MinCbLog2SizeY=log2_min_luma_coding_block_size_minus2+2 (1)
MinCbSizeY=1<<MinCbLog2SizeY (2)
IbcBufWidthY=256×128/CtbSizeY (3)
IbcBufWidthC=IbcBufWidthY/SubWidthC (4)
VSize=Min(64,CtbSizeY) (5)
MinCbSizeYの値はVSize以下でもよい。
各色差CTBについての配列の幅及び高さを指定する変数CtbWidthC及びCtbHeightCは、以下のように導出されてもよい。
―chroma_format_idcが0に等しい場合(モノクロ)、又はseparate_colour_plane_flagが1に等しい場合、CtbWidthC及びCtbHeightCは共に0に等しい。
―そうでない場合、CtbWidthC及びCtbHeightCは以下のように導出される。
CtbWidthC=CtbSizeY/SubWidthC (6)
CtbHeightC=CtbSizeY/SubHeightC (7)
0から4の範囲のlog2BlockWidth及び0から4の範囲のlog2BlockHeightについて、右上対角線及びラスタスキャン順配列初期化プロセスは、入力として1<<log2BlockWidth及び1<<log2BlockHeightによって呼び出されてもよく、出力はDiagScanOrder[log2BlockWidth][log2BlockHeight]及びRaster2DiagScanPos[log2BlockWidth][log2BlockHeight]に割り当てられてもよい。
0から6の範囲のlog2BlockWidth及び0から6の範囲のlog2BlockHeightについて、水平及び垂直トラバーススキャン順配列初期化プロセスは、入力として1<<log2BlockWidth及び1<<log2BlockHeightによって呼び出されてもよく、出力はHorTravScanOrder[log2BlockWidth][log2BlockHeight]及びVerTravScanOrder[log2BlockWidth][log2BlockHeight]に割り当てられてもよい。
1に等しいpartition_constraints_override_enabled_flagは、SPSを参照するピクチャヘッダ(PH, picture header)内のpartition_constraints_override_flagの存在を指定してもよい。0に等しいpartition_constraints_override_enabled_flagは、SPSを参照するPH内のpartition_constraints_override_flagの欠如を指定してもよい。
sps_log2_diff_min_qt_min_cb_intra_slice_lumaは、CTUのQT分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数と、SPSを参照してslice_typeが2(Iスライスを示す)に等しいスライス内の輝度CUの輝度サンプルにおける最小符号化ブロックサイズの2を底とする対数との間のデフォルト差を指定してもよい。partition_constraints_override_enabled_flagが1に等しい場合、デフォルト差は、SPSを参照するPH内に存在するpic_log2_diff_min_qt_min_cb_lumaによって上書きされてもよい。sps_log2_diff_min_qt_min_cb_intra_slice_lumaの値は、0以上CtbLog2SizeY―MinCbLog2SizeY以下の範囲でもよい。CTUのQT分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数は、以下のように導出されてもよい。
MinQtLog2SizeIntraY=sps_log2_diff_min_qt_min_cb_intra_slice_luma+MinCbLog2SizeY (8)
sps_log2_diff_min_qt_min_cb_inter_sliceは、CTUのQT分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数と、SPSを参照してslice_typeが0(Bスライスを示す)又は1(Pスライスを示す)に等しいスライス内の輝度CUの輝度サンプルにおける最小輝度符号化ブロックサイズの2を底とする対数との間のデフォルト差を指定してもよい。partition_constraints_override_enabled_flagが1に等しい場合、デフォルト差は、SPSを参照するPH内に存在するpic_log2_diff_min_qt_min_cb_lumaによって上書きされてもよい。sps_log2_diff_min_qt_min_cb_inter_sliceの値は、0以上CtbLog2SizeY―MinCbLog2SizeY以下の範囲でもよい。CTUのQT分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数は、以下のように導出されてもよい。
MinQtLog2SizeInterY=sps_log2_diff_min_qt_min_cb_inter_slice+MinCbLog2SizeY (9)
sps_max_mtt_hierarchy_depth_inter_sliceは、SPSを参照してslice_typeが0(Bスライスを示す)又は1(Pスライスを示す)に等しいスライス内のQTリーフのMTT分割から生じる符号化ユニットについてのデフォルト最大階層深さを指定してもよい。partition_constraints_override_enabled_flagが1に等しい場合、デフォルト最大階層深さは、SPSを参照するPHに存在するpic_max_mtt_hierarchy_depth_inter_sliceによって上書きされてもよい。sps_max_mtt_hierarchy_depth_inter_sliceの値は、0以上2×(CtbLog2SizeY―MinCbLog2SizeY)以下の範囲でもよい。
sps_max_mtt_hierarchy_depth_intra_slice_lumaは、SPSを参照してslice_typeが2(Iスライスを示す)に等しいスライス内のQTリーフのMTT分割から生じる符号化ユニットについてのデフォルト最大階層深さを指定してもよい。partition_constraints_override_enabled_flagが1に等しい場合、デフォルト最大階層深さは、SPSを参照するPHに存在するpic_max_mtt_hierarchy_depth_intra_slice_lumaによって上書きされてもよい。sps_max_mtt_hierarchy_depth_intra_slice_lumaの値は、0以上2×(CtbLog2SizeY―MinCbLog2SizeY)以下の範囲でもよい。
sps_log2_diff_max_bt_min_qt_intra_slice_lumaは、二分木分割を使用して分割可能な輝度符号化ブロックの輝度サンプルにおける最大サイズ(幅又は高さ)の2を底とする対数と、SPSを参照してslice_typeが2(Iスライスを示す)に等しいスライス内のCTUのQT分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズ(幅又は高さ)との間のデフォルト差を指定してもよい。partition_constraints_override_enabled_flagが1に等しい場合、デフォルト差は、SPSを参照するPHに存在するpic_log2_diff_max_bt_min_qt_lumaによって上書きされてもよい。sps_log2_diff_max_bt_min_qt_intra_slice_lumaの値は、0以上CtbLog2SizeY―MinQtLog2SizeIntraY以下の範囲でもよい。sps_log2_diff_max_bt_min_qt_intra_slice_lumaが存在しない場合、sps_log2_diff_max_bt_min_qt_intra_slice_lumaの値は0に等しいと推定されてもよい。
sps_log2_diff_max_tt_min_qt_intra_slice_lumaは、三分木分割を使用して分割可能な輝度符号化ブロックの輝度サンプルにおける最大サイズ(幅又は高さ)の2を底とする対数と、SPSを参照してslice_typeが2(Iスライスを示す)に等しいスライス内のCTUのQT分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズ(幅又は高さ)との間のデフォルト差を指定してもよい。partition_constraints_override_enabled_flagが1に等しい場合、デフォルト差は、SPSを参照するPHに存在するpic_log2_diff_max_tt_min_qt_lumaによって上書きされてもよい。sps_log2_diff_max_tt_min_qt_intra_slice_lumaの値は、0以上CtbLog2SizeY―MinQtLog2SizeIntraY以下の範囲でもよい。sps_log2_diff_max_tt_min_qt_intra_slice_lumaが存在しない場合、sps_log2_diff_max_tt_min_qt_intra_slice_lumaの値は0に等しいと推定されてもよい。
sps_log2_diff_max_bt_min_qt_inter_sliceは、二分木分割を使用して分割可能な輝度符号化ブロックの輝度サンプルにおける最大サイズ(幅又は高さ)の2を底とする対数と、SPSを参照してslice_typeが0(Bスライスを示す)又は1(Pスライスを示す)に等しいスライス内のCTUのQT分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズ(幅又は高さ)との間のデフォルト差を指定してもよい。partition_constraints_override_enabled_flagが1に等しい場合、デフォルト差は、SPSを参照するPHに存在するpic_log2_diff_max_bt_min_qt_lumaによって上書きされてもよい。sps_log2_diff_max_bt_min_qt_inter_sliceの値は、0以上CtbLog2SizeY―MinQtLog2SizeInterY以下の範囲でもよい。sps_log2_diff_max_bt_min_qt_inter_sliceが存在しない場合、sps_log2_diff_max_bt_min_qt_inter_sliceの値は0に等しいと推定されてもよい。
sps_log2_diff_max_tt_min_qt_inter_sliceは、三分木分割を使用して分割可能な輝度符号化ブロックの輝度サンプルにおける最大サイズ(幅又は高さ)の2を底とする対数と、SPSを参照してslice_typeが0(Bスライスを示す)又は1(Pスライスを示す)に等しいスライス内のCTUのQT分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズ(幅又は高さ)との間のデフォルト差を指定してもよい。partition_constraints_override_enabled_flagが1に等しい場合、デフォルト差は、SPSを参照するPHに存在するpic_log2_diff_max_tt_min_qt_lumaによって上書きされてもよい。sps_log2_diff_max_tt_min_qt_inter_sliceの値は、0以上CtbLog2SizeY―MinQtLog2SizeInterY以下の範囲でもよい。sps_log2_diff_max_tt_min_qt_inter_sliceが存在しない場合、sps_log2_diff_max_tt_min_qt_inter_sliceの値は0に等しいと推定されてもよい。
sps_log2_diff_min_qt_min_cb_intra_slice_chromaは、treeTypeがDUAL_TREE_CHROMAに等しい色差CTUの四分木分割から生じる色差リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数と、SPSを参照してslice_typeが2(Iスライスを示す)に等しいスライス内のtreeTypeがDUAL_TREE_CHROMAに等しい色差CUの輝度サンプルにおける最小符号化ブロックサイズの2を底とする対数との間のデフォルト差を指定してもよい。partition_constraints_override_enabled_flagが1に等しい場合、デフォルト差は、SPSを参照するPHに存在するpic_log2_diff_min_qt_min_cb_chromaによって上書きされてもよい。sps_log2_diff_min_qt_min_cb_intra_slice_chromaの値は、0以上CtbLog2SizeY―MinCbLog2SizeY以下の範囲でもよい。存在しない場合、sps_log2_diff_min_qt_min_cb_intra_slice_chromaの値は0に等しいと推定されてもよい。treeTypeがDUAL_TREE_CHROMAに等しいCTUのQT分割から生じる色差リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数は以下のように導出されてもよい。
MinQtLog2SizeIntraC=sps_log2_diff_min_qt_min_cb_intra_slice_chroma+MinCbLog2SizeY (10)
sps_max_mtt_hierarchy_depth_intra_slice_chromaは、SPSを参照してslice_typeが2(Iスライスを示す)に等しいスライス内でtreeTypeがDUAL_TREE_CHROMAに等しい色差四分木リーフのマルチタイプツリー分割から生じる色差符号化ユニットについてのデフォルト最大階層深さを指定してもよい。partition_constraints_override_enabled_flagが1に等しい場合、デフォルト最大階層深さは、SPSを参照するPHに存在するpic_max_mtt_hierarchy_depth_chromaによって上書きされてもよい。sps_max_mtt_hierarchy_depth_intra_slice_chromaの値は、0以上2×(CtbLog2SizeY―MinCbLog2SizeY以下の範囲でもよい。存在しない場合、sps_max_mtt_hierarchy_depth_intra_slice_chromaの値は0に等しいと推定されてもよい。
sps_log2_diff_max_bt_min_qt_intra_slice_chromaは、二分木分割を使用して分割可能な色差符号化ブロックの輝度サンプルにおける最大サイズ(幅又は高さ)の2を底とする対数と、SPSを参照してslice_typeが2(Iスライスを示す)に等しいスライス内のtypeTreeがDUAL_TREE_CHROMAに等しい色差CTUのQT分割から生じる色差リーフブロックの輝度サンプルにおける最小サイズ(幅又は高さ)との間のデフォルト差を指定してもよい。partition_constraints_override_enabled_flagが1に等しい場合、デフォルト差は、SPSを参照するPHに存在するpic_log2_diff_max_bt_min_qt_chromaによって上書きされてもよい。sps_log2_diff_max_bt_min_qt_intra_slice_chromaの値は、0以上CtbLog2SizeY― MinQtLog2SizeIntraC以下の範囲でもよい。sps_log2_diff_max_bt_min_qt_intra_slice_chromaが存在しない場合、sps_log2_diff_max_bt_min_qt_intra_slice_chromaの値は0に等しいと推定されてもよい。
sps_log2_diff_max_tt_min_qt_intra_slice_chromaは、三分木分割を使用して分割可能な色差符号化ブロックの輝度サンプルにおける最大サイズ(幅又は高さ)の2を底とする対数と、SPSを参照してslice_typeが2(Iスライスを示す)に等しいスライス内のtypeTreeがDUAL_TREE_CHROMAに等しい色差CTUの四分木分割から生じる色差リーフブロックの輝度サンプルにおける最小サイズ(幅又は高さ)との間のデフォルト差を指定してもよい。partition_constraints_override_enabled_flagが1に等しい場合、デフォルト差は、SPSを参照するPHに存在するpic_log2_diff_max_tt_min_qt_chromaによって上書きされてもよい。sps_log2_diff_max_tt_min_qt_intra_slice_chromaの値は、0以上CtbLog2SizeY― MinQtLog2SizeIntraC以下の範囲でもよい。sps_log2_diff_max_bt_min_tt_intra_slice_chromaが存在しない場合、sps_log2_diff_max_bt_min_tt_intra_slice_chromaの値は0に等しいと推定されてもよい。
1に等しいsps_max_luma_transform_size_64_flagは輝度サンプルにおける最大変換サイズが64に等しいことを指定してもよい。0に等しいsps_max_luma_transform_size_64_flagは輝度サンプルにおける最大変換サイズが32に等しいことを指定してもよい。CtbSizeYが64未満である場合、sps_max_luma_transform_size_64_flagの値は0に等しくてもよい。
変数MinTbLog2SizeY、MaxTbLog2SizeY、MinTbSizeY及びMaxTbSizeYは以下のように導出されてもよい。
MinTbLog2SizeY=2 (11)
MaxTbLog2SizeY=sps_max_luma_transform_size_64_flag?6:5 (12)
MinTbSizeY=1<<MinTbLog2SizeY (13)
MaxTbSizeY=1<<MaxTbLog2SizeY (14)
さらに、一例として、ピクチャヘッダ構造の意味について以下に説明する。
具体的には、ph_log2_diff_min_qt_min_cb_intra_slice_lumaは、CTUの四分木分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数と、ピクチャヘッダに関連してslice_typeが2(Iスライスを示す)に等しいスライス内の輝度CUの輝度サンプルにおける最小符号化ブロックサイズの2を底とする対数との間の差を指定するために使用される。一例では、ph_log2_diff_min_qt_min_cb_intra_slice_lumaの値は、0以上CtbLog2SizeY―MinCbLog2SizeY以下の範囲である。存在しない場合、ph_log2_diff_min_qt_min_cb_lumaの値はsps_log2_diff_min_qt_min_cb_intra_slice_lumaに等しいと推定されてもよい。
さらに、ph_max_mtt_hierarchy_depth_intra_slice_lumaは、ピクチャヘッダに関連してslice_typeが2(Iスライスを示す)に等しいスライス内の四分木リーフのマルチタイプツリー分割から生じる符号化ユニットについての最大階層深さを指定するために使用される。一例では、ph_max_mtt_hierarchy_depth_intra_slice_lumaの値は、0以上2×(CtbLog2SizeY―MinCbLog2SizeY)以下の範囲である。存在しない場合、ph_max_mtt_hierarchy_depth_intra_slice_lumaの値はsps_max_mtt_hierarchy_depth_intra_slice_lumaに等しいと推定されてもよい。
さらに、ph_log2_diff_max_bt_min_qt_intra_slice_lumaは、二分木分割を使用して分割可能な輝度符号化ブロックの輝度サンプルにおける最大サイズ(幅又は高さ)の2を底とする対数と、ピクチャヘッダに関連してslice_typeが2(Iスライスを示す)に等しいスライス内のCTUの四分木分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズ(幅又は高さ)との間の差を指定するために使用される。一例では、ph_log2_diff_max_bt_min_qt_intra_slice_lumaの値は、0以上CtbLog2SizeY―MinQtLog2SizeIntraY以下の範囲である。存在しない場合、ph_log2_diff_max_bt_min_qt_intra_slice_lumaの値はsps_log2_diff_max_bt_min_qt_intra_slice_lumaに等しいと推定されてもよい。
さらに、ph_log2_diff_max_tt_min_qt_intra_slice_lumaは、三分木分割を使用して分割可能な輝度符号化ブロックの輝度サンプルにおける最大サイズ(幅又は高さ)の2を底とする対数と、ピクチャヘッダに関連してslice_typeが2(Iスライスを示す)に等しいスライス内のCTUの四分木分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズ(幅又は高さ)との間の差を指定するために使用される。一例では、ph_log2_diff_max_tt_min_qt_intra_slice_lumaの値は、0以上CtbLog2SizeY―MinQtLog2SizeIntraY以下の範囲とする。存在しない場合、ph_log2_diff_max_tt_min_qt_intra_slice_lumaの値はsps_log2_diff_max_tt_min_qt_intra_slice_lumaに等しいと推定されてもよい。
さらに、ph_log2_diff_min_qt_min_cb_intra_slice_chromaは、treeTypeがDUAL_TREE_CHROMAに等しい色差CTUの四分木分割から生じる色差リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数と、ピクチャヘッダに関連してslice_typeが2(Iスライスを示す)に等しいスライス内のtreeTypeがDUAL_TREE_CHROMAに等しい色差CUの輝度サンプルにおける最小符号化ブロックサイズの2を底とする対数との間の差を指定するために使用される。一例では、ph_log2_diff_min_qt_min_cb_intra_slice_chromaの値は、0以上CtbLog2SizeY―MinCbLog2SizeY以下の範囲である。存在しない場合、ph_log2_diff_min_qt_min_cb_intra_slice_chromaの値はsps_log2_diff_min_qt_min_cb_intra_slice_chromaに等しいと推定されてもよい。
さらに、ph_max_mtt_hierarchy_depth_intra_slice_chromaは、ピクチャヘッダに関連してslice_typeが2(Iスライスを示す)に等しいスライス内でtreeTypeがDUAL_TREE_CHROMAに等しい色差四分木リーフのマルチタイプツリー分割から生じる色差符号化ユニットについての最大階層深さを指定するために使用される。一例では、ph_max_mtt_hierarchy_depth_intra_slice_chromaの値は、0以上2×(CtbLog2SizeY―MinCbLog2SizeY)以下の範囲である。存在しない場合、ph_max_mtt_hierarchy_depth_intra_slice_chromaの値はsps_max_mtt_hierarchy_depth_intra_slice_chromaに等しいと推定されてもよい。
さらに、ph_log2_diff_max_bt_min_qt_intra_slice_chromaは、二分木分割を使用して分割可能な色差符号化ブロックの輝度サンプルにおける最大サイズ(幅又は高さ)の2を底とする対数と、ピクチャヘッダに関連してslice_typeが2(Iスライスを示す)に等しいスライス内のtypeTreeがDUAL_TREE_CHROMAに等しい色差CTUの四分木分割から生じる色差リーフブロックの輝度サンプルにおける最小サイズ(幅又は高さ)との間の差を指定するために使用される。一例では、ph_log2_diff_max_bt_min_qt_intra_slice_chromaの値は、0以上CtbLog2SizeY―MinQtLog2SizeIntraC以下の範囲とする。存在しない場合、ph_log2_diff_max_bt_min_qt_intra_slice_chromaの値はsps_log2_diff_max_bt_min_qt_intra_slice_chromaに等しいと推定されてもよい。
さらに、ph_log2_diff_max_tt_min_qt_intra_slice_chromaは、三分木分割を使用して分割可能な色差符号化ブロックの輝度サンプルにおける最大サイズ(幅又は高さ)の2を底とする対数と、ピクチャヘッダに関連してslice_typeが2(Iスライスを示す)に等しいスライス内のtypeTreeがDUAL_TREE_CHROMAに等しい色差CTUの四分木分割から生じる色差リーフブロックの輝度サンプルにおける最小サイズ(幅又は高さ)との間の差を指定するために使用される。一例では、ph_log2_diff_max_tt_min_qt_intra_slice_chromaの値は、0以上CtbLog2SizeY―MinQtLog2SizeIntraC以下の範囲とする。存在しない場合、ph_log2_diff_max_tt_min_qt_intra_slice_chromaの値はsps_log2_diff_max_tt_min_qt_intra_slice_chromaに等しいと推定されてもよい。
さらに、いくつかのスライスヘッダの意味について以下に説明する。
例えば、slice_typeは、図26における表3等に従って、スライスの符号化タイプを指定するために使用される。一例では、スライスのslice_typeが0の値を有する場合、スライスはBスライスであり、スライスのslice_typeが1の値を有する場合、スライスはPスライスであり、スライスのslice_typeが2の値を有する場合、スライスはIスライスである。存在しない場合、slice_typeの値は、一例では2に等しいと推定される。
他の例では、ph_intra_slice_allowed_flagが0に等しい場合、slice_typeの値は0又は1でもよい。nal_unit_typeがIDR_W_RADL以上CRA_NUT以下の範囲にあり、vps_independent_layer_flag[GeneralLayerIdx[nuh_layer_id]]が1に等しい場合、slice_typeは2でもよい。
いくつかの例では、変数MinQtLog2SizeY、MinQtLog2SizeC、MinQtSizeY、MinQtSizeC、MaxBtSizeY、MaxBtSizeC、MinBtSizeY、MaxTtSizeY、MaxTtSizeC、MinTtSizeY、MaxMttDepthY及びMaxMttDepthCは、次のように導出される。
例えば、slice_typeが2(Iスライスを示す)に等しい場合、以下が適用されてもよい。
MinQtLog2SizeY=MinCbLog2SizeY+ph_log2_diff_min_qt_min_cb_intra_slice_luma (15)
MinQtLog2SizeC=MinCbLog2SizeY+ph_log2_diff_min_qt_min_cb_intra_slice_chroma (16)
MaxBtSizeY=1<<(MinQtLog2SizeY+ph_log2_diff_max_bt_min_qt_intra_slice_luma) (17)
MaxBtSizeC=1<<(MinQtLog2SizeC+ph_log2_diff_max_bt_min_qt_intra_slice_chroma) (18)
MaxTtSizeY=1<<(MinQtLog2SizeY+ph_log2_diff_max_tt_min_qt_intra_slice_luma) (19)
MaxTtSizeC=1<<(MinQtLog2SizeC+ph_log2_diff_max_tt_min_qt_intra_slice_chroma) (20)
MaxMttDepthY=ph_max_mtt_hierarchy_depth_intra_slice_luma (21)
MaxMttDepthC=ph_max_mtt_hierarchy_depth_intra_slice_chroma (22)
CuQpDeltaSubdiv=ph_cu_qp_delta_subdiv_intra_slice (23)
CuChromaQpOffsetSubdiv=ph_cu_chroma_qp_offset_subdiv_intra_slice (24)
そうでなく、slice_typeが0(B)又は1(P)に等しい場合、以下が適用されてもよい。
MinQtLog2SizeY=MinCbLog2SizeY+ph_log2_diff_min_qt_min_cb_inter_slice (25)
MinQtLog2SizeC=MinCbLog2SizeY+ph_log2_diff_min_qt_min_cb_inter_slice (26)
MaxBtSizeY=1<<(MinQtLog2SizeY+ph_log2_diff_max_bt_min_qt_inter_slice) (27)
MaxBtSizeC=1<<(MinQtLog2SizeC+ph_log2_diff_max_bt_min_qt_inter_slice) (28)
MaxTtSizeY=1<<(MinQtLog2SizeY+ph_log2_diff_max_tt_min_qt_inter_slice) (29)
MaxTtSizeC=1<<(MinQtLog2SizeC+ph_log2_diff_max_tt_min_qt_inter_slice) (30)
MaxMttDepthY=ph_max_mtt_hierarchy_depth_inter_slice (31)
MaxMttDepthC=ph_max_mtt_hierarchy_depth_inter_slice (32)
CuQpDeltaSubdiv=ph_cu_qp_delta_subdiv_inter_slice (33)
CuChromaQpOffsetSubdiv=ph_cu_chroma_qp_offset_subdiv_inter_slice (34)
以下も当てはまる。
MinQtSizeY=1<<MinQtLog2SizeY (35)
MinQtSizeC=1<<MinQtLog2SizeC (36)
MinBtSizeY=1<<MinCbLog2SizeY (37)
MinTtSizeY=1<<MinCbLog2SizeY (38)
一例として、符号化ツリーの意味について以下に説明する。いくつかの例では、変数allowSplitQt、allowSplitBtVer、allowSplitBtHor、allowSplitTtVer及びallowSplitTtHorは以下のように導出されてもよい。
一例では、許容される四分木分割のプロセスは、入力としてcbWidthに等しい符号化ブロックサイズcbSize、現在のマルチタイプツリー深さmttDepth、treeTypeCurr及びmodeTypeCurrによって呼び出されてもよく、出力はallowSplitQtに割り当てられる。
変数minQtSize、maxBtSize、maxTtSize及びmaxMttDepthが導出されてもよい。treeTypeがDUAL_TREE_CHROMAに等しい場合、minQtSize、maxBtSize、maxTtSize及びmaxMttDepthは、それぞれMinQtSizeC、MaxBtSizeC、MaxTtSizeC及びMaxMttDepthC+depthOffsetに等しく設定され、そうでない場合、minQtSize、maxBtSize、maxTtSize及びmaxMttDepthは、それぞれMinQtSizeY、MaxBtSizeY、MaxTtSizeY及びMaxMttDepthY+depthOffsetに等しく設定される。
許容される二分木分割のプロセスは、入力として二分木分割モードSPLIT_BT_VER、符号化ブロック幅cbWidth、符号化ブロック高さcbHeight、位置(x0,y0)、現在のマルチタイプツリー深さmttDepth、オフセットを有する最大マルチタイプツリー深さmaxMttDepth、最大二分木サイズmaxBtSize、最小四分木サイズminQtSize、現在のパーティションインデックスpartIdx、treeTypeCurr及びmodeTypeCurrによって呼び出されてもよく、出力はallowSplitBtVerに割り当てられる。
許容される二分木分割のプロセスは、入力として二分木分割モードSPLIT_BT_HOR、符号化ブロック高さcbHeight、符号化ブロック幅cbWidth、位置(x0,y0)、現在のマルチタイプツリー深さmttDepth、オフセットを有する最大マルチタイプツリー深さmaxMttDepth、最大二分木サイズmaxBtSize、最小四分木サイズminQtSize、現在のパーティションインデックスpartIdx、treeTypeCurr及びmodeTypeCurrによって呼び出されてもよく、出力はallowSplitBtHorに割り当てられる。
許容される三分木分割のプロセスは、入力として三分木分割モードSPLIT_TT_VER、符号化ブロック幅cbWidth、符号化ブロック高さcbHeight、位置(x0,y0)、現在のマルチタイプツリー深さmttDepth、オフセットを有する最大マルチタイプツリー深さmaxMttDepth、最大三分木サイズmaxTtSize、treeTypeCurr及びmodeTypeCurrによって呼び出されてもよく、出力はallowSplitTtVerに割り当てられる。
許容される三分木分割のプロセスは、入力として三分木分割モードSPLIT_TT_HOR、符号化ブロック高さcbHeight、符号化ブロック幅cbWidth、位置(x0,y0)、現在のマルチタイプツリー深さmttDepth、オフセットを有する最大マルチタイプツリー深さmaxMttDepth、最大三分木サイズmaxTtSize、treeTypeCurr及びmodeTypeCurrによって呼び出されてもよく、出力はallowSplitTtHorに割り当てられる。
一例では、split_cu_flagは、符号化ユニットが分割されているか否かを指定するフラグである。例えば、0に等しいsplit_cu_flagは、符号化ユニットが分割されないことを指定し、1に等しいsplit_cu_flagは、符号化ユニットがシンタックスエレメントsplit_qt_flagで示されるように四分木分割を使用して4つの符号化ユニットに分割されること、又はシンタックスエレメントmtt_split_cu_binary_flagで示されるように二分木分割を使用して2つの符号化ユニットに或いは三分木分割を使用して3つの符号化ユニットに分割されることを指定する。二分木分割又は三分木分割は、シンタックスエレメントmtt_split_cu_vertical_flagで示されるように、垂直又は水平のいずれかでもよい。
split_cu_flagが存在しない場合、split_cu_flagの値は以下のように推定される。以下の条件のうち1つ以上が真である場合、split_cu_flagの値は1に等しいと推定される。条件は、(1)x0+cbWidthがpic_width_in_luma_samplesよりも大きいこと、及び(2)y0+cbHeightがpic_height_in_luma_samplesよりも大きいことを含む。そうでない場合(条件のいずれも真ではない場合)、split_cu_flagの値は0に等しいと推定される。
さらに、split_qt_flagは、符号化ユニットが半分の水平及び垂直サイズを有する符号化ユニットに分割されるか否かを指定する。いくつかの例では、split_qt_flagが存在しない場合、以下が当てはまる。以下の条件のうち全てが真である場合、split_qt_flagは1に等しいと推定される。条件は、(1)split_cu_flagが1に等しいこと、及び(2)allowSplitQt、allowSplitBtHor、allowSplitBtVer、allowSplitTtHor及びallowSplitTtVerが偽に等しいことを含む。そうでなく(全ての条件が真とは限らない)、allowSplitQtが真に等しい場合、split_qt_flagの値は1に等しいと推定され、そうでない場合(allowSplitQtが真ではない場合)、split_qt_flagの値は0に等しいと推定される。
さらに、0に等しいmtt_split_cu_vertical_flagは、符号化ユニットが水平に分割されることを指定する。1に等しいmtt_split_cu_vertical_flagは、符号化ユニットが垂直に分割されることを指定する。mtt_split_cu_vertical_flagが存在しない場合、mtt_split_cu_vertical_flagが推定される。例えば、allowSplitBtHorが真に等しい場合、又はallowSplitTtHorが真に等しい場合、mtt_split_cu_vertical_flagの値は0に等しいと推定される。そうでない場合、mtt_split_cu_vertical_flagの値は1に等しいと推定される。
さらに、0に等しいmtt_split_cu_binary_flagは、符号化ユニットが三分木分割を使用して3つの符号化ユニットに分割されることを指定する。1に等しいmtt_split_cu_binary_flagは、符号化ユニットが二分木分割を使用して2つの符号化ユニットに分割されることを指定する。mtt_split_cu_binary_flagが存在しない場合、mtt_split_cu_binary_flagは以下のように推定されてもよい。
―allowSplitBtVerが偽に等しく、allowSplitBtHorが偽に等しい場合、mtt_split_cu_binary_flagの値は0に等しいと推定される。
―そうでなく、allowSplitTtVerが偽に等しく、allowSplitTtHorが偽に等しい場合、mtt_split_cu_binary_flagの値は1に等しいと推定される。
―そうでなく、allowSplitBtHorが真に等しく、allowSplitTtVerが真に等しい場合、mtt_split_cu_binary_flagの値は1―mtt_split_cu_vertical_flagに等しいと推定される。
―そうでない場合(allowSplitBtVerが真に等しく、allowSplitTtHorが真に等しい場合)、mtt_split_cu_binary_flagの値はmtt_split_cu_vertical_flagに等しいと推定される。
いくつかの例では、変数MttSplitMode[x][y][mttDepth]は、x=x0..x0+cbWidth―1及びy=y0..y0+cbHeight―1について、図17の表2で定義されるようにmtt_split_cu_vertical_flagの値及びmtt_split_cu_binary_flagの値から導出される。
いくつかの例では、変数MttSplitMode[x0][y0][mttDepth]は、図15に示すように、マルチタイプツリー内の符号化ユニットの水平及び垂直の二分木分割及び三分木分割を表す。配列インデックスx0,y0は、ピクチャの左上の輝度サンプルに対する、考慮される符号化ブロックの左上の輝度サンプルの位置(x0,y0)を指定する。
いくつかの例では、変数modeTypeConditionは以下のように導出される。
―以下の条件のうち1つ以上が真である場合、modeTypeConditionは0に等しく設定される。
―slice_typeがIに等しく、qtbtt_dual_tree_intra_flagが1に等しい。
―modeTypeCurrがMODE_TYPE_ALLに等しくない。
―chroma_format_idcが0に等しい。
―chroma_format_idcが3に等しい。
―そうでなく、以下の条件のうち1つが真である場合、modeTypeConditionは1に等しく設定される。
―cbWidth×cbHeightが64に等しく、split_qt_flagが1に等しい。
―cbWidth×cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HOR又はSPLIT_TT_VERに等しい。
―cbWidth×cbHeightが32に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HOR又はSPLIT_BT_VERに等しい。
―そうでなく、以下の条件のうち1つが真である場合、modeTypeConditionは1+(slice_type!=I?1:0)に等しく設定される。
―cbWidth×cbHeightが64に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_HOR又はSPLIT_BT_VERに等しく、chroma_format_idcが1に等しい。
―cbWidth×cbHeightが128に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_HOR又はSPLIT_TT_VERに等しく、chroma_format_idcが1に等しい。
―cbWidthが8に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_BT_VERに等しい。
―cbWidthが16に等しく、MttSplitMode[x0][y0][mttDepth]がSPLIT_TT_VERに等しい。
―そうでない場合、modeTypeConditionは0に等しく設定される。
いくつかの例では、0に等しいmode_constraint_flagは、カレント符号化ツリーノード内の符号化ユニットがインター予測符号化モードのみを使用できることを指定し、1に等しいmode_constraint_flagは、カレント符号化ツリーノード内の符号化ユニットがインター予測符号化モードを使用できないことを指定する。
VVCのような分割可能性関連のプロセスの例について以下に説明する。
一実施形態において、許容される四分木分割のプロセスについて以下に説明する。許容される四分木分割のプロセスへの入力は、以下を含んでもよい。
a)輝度サンプルの符号化ブロックサイズ(又はcbSize)、
b)MTT深さ(又はmttDepth)、
c)符号化ツリーノードを分割するためにシングルツリー(又はSINGLE_TREE)が使用されるかデュアルツリーが使用されるか、及びデュアルツリーが使用される場合には輝度成分(DUAL_TREE_LUMA)が現在処理されているか色差成分(DUAL_TREE_CHROMA)が現在処理されているかを指定する変数のツリータイプ(又はtreeType)、
d)符号化ツリーノード内の符号化ユニットについて、イントラモード(又はイントラ予測モード、MODE_INTRA)、IBCモード(又はMODE_IBC)及びインター符号化モードが使用できるか否か(MODE_TYPE_ALL)、又はイントラモード及びIBC符号化モードのみが使用できるか否か(MODE_TYPE_INTRA)、又はインター符号化モードのみが使用できるか否か(MODE_TYPE_INTER)を指定する変数のモードタイプ(予測モードタイプ、例えば、modeTypeとも呼ばれる)。一例では、MODE_TYPE_ALLは、イントラモード、IBCモード及びインター符号化モードが使用できることを示す。
輝度サンプルの符号化ブロックサイズ(又はcbSize)は、輝度サンプルを有する色差符号化ブロック(又は色差ブロック)のブロックサイズを表してもよい。したがって、色差サンプル内の色差符号化ブロックのブロックサイズは、輝度サンプルの符号化ブロックサイズ(又はcbSize)と、水平方向の色差水平サブサンプリング比又は色差サブサンプリング比(例えば、SubWidthC)のような対応する色差サブサンプリング比とに基づいて決定されてもよい。例えば、色差フォーマット4:2:0について、輝度サンプルの符号化ブロックサイズ(又はcbSize)は16であり、したがって、色差符号化ブロックのブロックサイズは、輝度サンプルを単位として表される場合には16であり、或いは、色差サンプルを単位として表される場合には8である。
一例では、符号化ブロックサイズcbSizeは輝度サンプルの符号化ブロックサイズの幅(cbWidth)に等しく設定される。例えば、色差フォーマット4:2:2について、輝度サンプルの符号化ブロックサイズの幅は16個の輝度サンプルであり、色差水平サブサンプリング比(SubWidthC)は2であり、したがって、色差符号化ブロックのブロックサイズは輝度サンプルで16でもよく、或いは、色差サンプルで16/2(又は8)でもよい。さらに、色差フォーマット4:2:2について、輝度サンプルの符号化ブロックサイズの高さは16個の輝度サンプルであり、色差垂直サブサンプリング比(SubHeightC)は1であり、したがって、色差符号化ブロックの高さは輝度サンプルで16でもよく、或いは、色差サンプルで16でもよい。
許容される四分木分割のプロセスの出力は、QT分割が許容される(例えば、allowSplitQtが真である)か許容されないか(例えば、allowSplitQtが偽である)を示す変数allowSplitQtを含んでもよい。変数allowSplitQtは以下のように導出されてもよい。
―以下の条件(QT分割のための条件とも呼ばれる)のうち1つ以上が真である場合、変数allowSplitQtは偽に等しく設定されてもよく、QT分割(又はQTスプリット)は許容されない。
(a)treeTypeがSINGLE_TREE又はDUAL_TREE_LUMAに等しく、cbSizeがMinQtSizeY以下である。
(b)treeTypeがDUAL_TREE_CHROMAに等しく、cbSize/SubWidthCがMinQtSizeC以下である。
(c)mttDepthが0に等しくない。
(d)treeTypeがDUAL_TREE_CHROMAに等しく、(cbSize/SubWidthC)が4以下である。
(e)treeTypeがDUAL_TREE_CHROMAに等しく、modeTypeがMODE_TYPE_INTRAに等しい。
―そうでない場合、allowSplitQtは真に等しく設定されてもよい。したがって、QT分割(又はQTスプリット)は許容されてもよい。
様々な例では、上記の条件(b)、(d)及び(e)のような特定の条件は、treeTypeがDUAL_TREE_CHROMAに等しいことを含み、したがって、条件(b)、(d)及び(e)は、QT分割が色差ブロックに適用される場合には真でもよく、QT分割が輝度ブロックに適用される場合には真でなくてもよい。したがって、QT分割のための条件(b)、(d)及び(e)は、色差QT分割(又は色差QTスプリット)のための条件と呼ばれてもよい。
条件(a)~(e)のうち1つ以上が修正及び/又は省略されてもよい。更なる条件が条件(a)~(e)に追加されてもよい。
一例では、符号化ツリーの意味は、以下のように導出され得る変数allowSplitQtを含む。許容される四分木分割のプロセスは、入力としてcbWidthに等しく設定された符号化ブロックサイズcbSize(例えば、輝度サンプルのもの)、現在のマルチタイプツリー深さmttDepth、treeTypeCurr及びmodeTypeCurrによって呼び出されてもよく、出力はallowSplitQtに割り当てられてもよい。
一実施形態において、許容される二分木分割のプロセスについて以下に説明する。許容される二分木分割のプロセスへの入力は、以下を含んでもよい。
a)二分木分割モード(又はbtSplit)、
b)輝度サンプルの符号化ブロック幅(又はcbWidth)、
c)輝度サンプルの符号化ブロック高さ(又はcbHeight)、
d)ピクチャの左上の輝度サンプルに対する、考慮される符号化ブロックの左上の輝度サンプルの位置(x0,y0)、
e)マルチタイプツリー深さ(又はmttDepth)、
f)オフセットを有する最大のマルチタイプツリー深さ(又はmaxMttDepth)
g)最大二分木サイズ(又はmaxBtSize)、
h)最小QTサイズ(又はminQtSize)、
i)分割インデックス(又はpartIdx)、
j)符号化ツリーノードを分割するためにシングルツリー(SINGLE_TREE)が使用されるかデュアルツリーが使用されるか、及びデュアルツリーが使用される場合には輝度成分(DUAL_TREE_LUMA)が現在処理されているか色差成分(DUAL_TREE_CHROMA)が現在処理されているかを指定する変数のツリータイプ(又はtreeType)。
k)符号化ツリーノード内の符号化ユニットについて、イントラモード(MODE_INTRA)、IBCモード(MODE_IBC)及びインター符号化モードが使用できるか否か(MODE_TYPE_ALL)、又はイントラモード及びIBC符号化モードのみが使用できるか否か(MODE_TYPE_INTRA)、又はインター符号化モードのみが使用できるか否か(MODE_TYPE_INTER)を指定する変数のモードタイプ(又はmodeType)。
許容される二分木分割のプロセスの出力は、変数allowBtSplitを含んでもよい。
一例では、変数parallelTtSplit及びcbSizeは、表4(図27)に示すように、変数btSplitに基づいて導出される。
変数allowBtSplitは以下のように導出されてもよい。
―以下の条件のうち1つ以上が真である場合、変数allowBtSplitは偽に等しく設定されてもよい。
・cbSizeがMinBtSizeY以下である。
・cbWidthがmaxBtSizeよりも大きい。
・cbHeightがmaxBtSizeよりも大きい。
・mttDepthがmaxMttDepth以上である。
・treeTypeがDUAL_TREE_CHROMAに等しく、(cbWidth/SubWidthC)×(cbHeight/SubHeightC)が16以下である。
・treeTypeがDUAL_TREE_CHROMAに等しく、(cbWidth/SubWidthC)が4に等しく、btSplitがSPLIT_BT_VERに等しい。
・treeTypeがDUAL_TREE_CHROMAに等しく、modeTypeがMODE_TYPE_INTRAに等しい。
・cbWidth×cbHeightが32に等しく、modeTypeがMODE_TYPE_INTERに等しい。
―そうでなく、以下の条件の全てが真である場合、変数eallowBtSplitは偽に等しく設定されてもよい。
・btSplitがSPLIT_BT_VERに等しい。
・y0+cbHeightがpic_height_in_luma_samplesよりも大きい。
―そうでなく、以下の条件の全てが真である場合、変数allowBtSplitは偽に等しく設定されてもよい。
・btSplitがSPLIT_BT_VERに等しい。
・cbHeightが64よりも大きい。
・x0+cbWidthがpic_width_in_luma_samplesよりも大きい。
―そうでなく、以下の条件の全てが真である場合、変数allowBtSplitは偽に等しく設定されてもよい。
・btSplitがSPLIT_BT_HORに等しい。
・cbWidthが64よりも大きい。
・y0+cbHeightがpic_height_in_luma_samplesよりも大きい。
―そうでなく、以下の条件の全てが真である場合、変数allowBtSplitは偽に等しく設定されてもよい。
・x0+cbWidthがpic_width_in_luma_samplesよりも大きい。
・y0+cbHeightがpic_height_in_luma_samplesよりも大きい。
・cbWidthがminQtSizeよりも大きい。
―そうでなく、以下の条件の全てが真である場合、変数allowBtSplitは偽に等しく設定されてもよい。
・btSplitがSPLIT_BT_HORに等しい。
・x0+cbWidthがpic_width_in_luma_samplesよりも大きい。
・y0+cbHeightがpic_height_in_luma_samples以下である。
―そうでなく、以下の条件の全てが真である場合、変数allowBtSplitは偽に等しく設定されてもよい。
・mttDepthが0よりも大きい。
・partIdxが1に等しい。
・MttSplitMode[x0][y0][mttDepth―1]がparallelTtSplitに等しい。
―そうでなく、以下の条件の全てが真である場合、変数allowBtSplitは偽に等しく設定されてもよい。
・btSplitがSPLIT_BT_VERに等しい。
・cbWidthが64以下である。
・cbHeightが64よりも大きい。
―そうでなく、以下の条件の全てが真である場合、変数allowBtSplitは偽に等しく設定されてもよい。
・btSplitがSPLIT_BT_HORに等しい。
・cbWidthが64よりも大きい。
・cbHeightが64以下である。
―そうでない場合、変数allowBtSplitは真に等しく設定されてもよい。
一実施形態において、許容される三分木分割のプロセスについて以下に説明する。許容される三分木分割のプロセスへの入力は、以下を含んでもよい。
a)三分木分割モード(又はttSplit)、
b)輝度サンプルの符号化ブロック幅(又はcbWidth)、
c)輝度サンプルの符号化ブロック高さ(又はcbHeight)、
d)ピクチャの左上の輝度サンプルに対する、考慮される符号化ブロックの左上の輝度サンプルの位置(x0,y0)、
e)マルチタイプツリー深さ(又はmttDepth)、
f)オフセットを有する最大のマルチタイプツリー深さ(又はmaxMttDepth)
g)最大三分木サイズ(又はmaxTtSize)、
h)符号化ツリーノードを分割するためにシングルツリー(SINGLE_TREE)が使用されるかデュアルツリーが使用されるか、及びデュアルツリーが使用される場合には輝度成分(DUAL_TREE_LUMA)が現在処理されているか色差成分(DUAL_TREE_CHROMA)が現在処理されているかを指定する変数のツリータイプ(又はtreeType)。
i)符号化ツリーノード内の符号化ユニットについて、イントラモード(MODE_INTRA)、IBCモード(MODE_IBC)及びインター符号化モードが使用できるか否か(MODE_TYPE_ALL)、又はイントラモード及びIBC符号化モードのみが使用できるか否か(MODE_TYPE_INTRA)、又はインター符号化モードのみが使用できるか否か(MODE_TYPE_INTER)を指定する変数のモードタイプ(又はmodeType)。
許容される三分木分割のプロセスの出力は、変数allowTtSplitを含んでもよい。
一例では、変数cbSizeは、表5(図28)に示すように、変数ttSplitに基づいて導出される。
変数allowTtSplitは以下のように導出されてもよい。
―以下の条件のうち1つ以上が真である場合、変数allowTtSplitは偽に等しく設定されてもよい。
・cbSizeが2×MinTtSizeY以下である。
・cbWidthがMin(64,maxTtSize)よりも大きい。
・cbHeightがMin(64,maxTtSize)よりも大きい。
・mttDepthがmaxMttDepth以上である。
・x0+cbWidthがpic_width_in_luma_samplesよりも大きい。
・y0+cbHeightがpic_height_in_luma_samplesよりも大きい。
・treeTypeがDUAL_TREE_CHROMAに等しく、(cbWidth/SubWidthC)×(cbHeight/SubHeightC)が32以下である。
・treeTypeがDUAL_TREE_CHROMAに等しく、(cbWidth/SubWidthC)が8に等しく、ttSplitがSPLIT_TT_VERに等しい。
・treeTypeがDUAL_TREE_CHROMAに等しく、modeTypeがMODE_TYPE_INTRAに等しい。
・cbWidth×cbHeightが64に等しく、modeTypeがMODE_TYPE_INTERに等しい。
―そうでない場合、変数allowTtSplitは真に等しく設定されてもよい。
隣接ブロックの可用性についての導出プロセスについて以下に説明する。
隣接ブロックの可用性についての導出プロセスへの入力は、以下を含んでもよい。
a)カレントピクチャの左上の輝度サンプルに対するカレントブロックの左上のサンプルの輝度位置(xCurrr,yCurrr)、
b)カレントピクチャの左上の輝度サンプルに対する隣接ブロックでカバーされる輝度位置(xNbY,yNbY)
c)可用性が予測モードに依存するか否かを指定する変数checkPredModeY、
d)カレントブロックの色成分を指定する変数cIdx
導出プロセスの出力は、availableNとして記される、位置(xNbY,yNbY)をカバーする隣接ブロックの可用性を含んでもよい。隣接ブロックの可用性(又はavailableN)は、以下のように導出されてもよい。
―以下の条件のうち1つ以上が真である場合、availableNは偽に等しく設定される。
・xNbYが0よりも小さい。
・yNbYが0よりも小さい。
・xNbYがpic_width_in_luma_samples以上である。
・yNbYがpic_height_in_luma_samples以上である。
・IsAvailable[cIdx][xNbY][yNbY]が偽に等しい。
・隣接ブロックがカレントブロックと異なるスライスに含まれる。
・隣接ブロックがカレントブロックと異なるタイルに含まれる。
・entropy_coding_sync_enabled_flagが1に等しく、(xNbY>>CtbLog2SizeY)が(xCurr>>CtbLog2SizeY)+1以上である。
―そうでない場合、変数availableNは真に等しく設定されてもよい。
以下の条件の全てが真である場合、変数availableNは偽に設定されてもよい。
―checkPredModeYが真に等しい。
―CuPredMode[0][xNbY][yNbY]がCuPredMode[0][xCurr][yCurr]に等しくない。
本開示のいくつかの態様によれば、最低QTサイズに関する矛盾が存在する可能性がある。現在のVVCドラフトのデュアルツリーの輝度の場合を例にとると、最小輝度QTサイズ(MinQTSizeY)は128が設定され、最大輝度マルチタイプツリー深さ(maxMTTDepthY)がゼロよりも大きい場合、最大輝度二分木ノードサイズ(MaxBTSizeY)又は最大輝度三分木ノードサイズ(MaxTTSizeY)は、64に設定されることが許容されない。この理由は、これらが最小輝度QTサイズ(MinQTSizeY)以上でなければならないからである。しかし、デュアルツリーが使用される場合、デュアルツリーの暗示的な分割が128のサイズを有する輝度符号化ブロックに適用されるという事実のため、これは、実際の最小輝度QTサイズが64個の輝度サンプルになることを事実上生じ、したがって、64の最大輝度BTサイズ及び/又は64の最大輝度TTサイズが適用される可能性がある。
本開示の態様は、CTUサイズと、デュアルツリーが使用されるか否か(又はdual_tree_implicit_qt_splitが使用されるか否か)とを考慮して、最小QTサイズに関するシンタックスエレメントの範囲を制限するための技術を提供する。
いくつかの実施形態では、デュアルツリー分割が使用され、暗示的なQT分割が特定の閾値のブロックサイズ以上で適用される場合、最小QTサイズの範囲は、暗示的により小さいサイズに分割されるQTサイズを含まないように定義されてもよい。
一例では、128個の輝度サンプルのサイズを有するデュアルツリー輝度ブロックは、64のサイズを有するQTノードに暗示的に分割される。このような場合、シンタックスエレメントsps_log2_diff_min_qt_min_cb_intra_slice_lumaの意味は変更されてもよい。具体的には、sps_log2_diff_min_qt_min_cb_intra_slice_lumaは、CTUの四分木分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数と、SPSを参照してslice_typeが2(Iスライスを示す)に等しいスライス内の輝度CUの輝度サンプルにおける最小符号化ブロックサイズの2を底とする対数との間のデフォルト差を指定するために使用される。partition_constraints_override_enabled_flagが1に等しい場合、デフォルト差は、ピクチャヘッダ(PH)内で示されるph_log2_diff_min_qt_min_cb_lumaによって上書きされてもよい。いくつかの実施形態では、sps_log2_diff_min_qt_min_cb_intra_slice_lumaの値は、0以上CtbLog2SizeY―MinCbLog2SizeY―(CtbLog2SizeY>6&&qtbtt_dual_tree_intra_flag)以下の範囲である。CTUの四分木分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数は、式(39)のように導出されてもよい。
MinQtLog2SizeIntraY=sps_log2_diff_min_qt_min_cb_intra_slice_luma+MinCbLog2SizeY (39)
同様に、ピクチャヘッダ内のph_log2_diff_min_qt_min_cb_intra_slice_lumaの意味も変更されてもよい。具体的には、ph_log2_diff_min_qt_min_cb_intra_slice_lumaは、CTUの四分木分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数と、ピクチャヘッダに関連してslice_typeが2(Iスライスを示す)に等しいスライス内の輝度CUの輝度サンプルにおける最小符号化ブロックサイズの2を底とする対数との間の差を指定するために使用される。ph_log2_diff_min_qt_min_cb_intra_slice_lumaの値は、0以上CtbLog2SizeY―MinCbLog2SizeY―(CtbLog2SizeY>6&&qtbtt_dual_tree_intra_flag)以下の範囲でもよい。存在しない場合、ph_log2_diff_min_qt_min_cb_lumaの値はsps_log2_diff_min_qt_min_cb_intra_slice_lumaに等しいと推定される。partition_constraints_override_enabled_flagが1に等しい場合、式(39)のsps_log2_diff_min_qt_min_cb_intra_slice_lumaの代わりにph_log2_diff_min_qt_min_cb_lumaが使用される。
いくつかの実施形態では、128個の輝度サンプルのサイズを有するデュアルツリー色差ブロックは、輝度サンプルにおいて64のサイズを有するQTノードに暗示的に分割されてもよい。このような場合、シンタックスエレメントsps_log2_diff_min_qt_min_cb_intra_slice_chromaの意味は変更されてもよい。具体的には、sps_log2_diff_min_qt_min_cb_intra_slice_chromaは、treeTypeがDUAL_TREE_CHROMAに等しい色差CTUの四分木分割から生じる色差リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数と、SPSを参照してslice_typeが2(Iスライスを示す)に等しいスライス内のtreeTypeがDUAL_TREE_CHROMAに等しい色差CUの輝度サンプルにおける最小符号化ブロックサイズの2を底とする対数との間のデフォルト差を指定するために使用される。partition_constraints_override_enabled_flagが1に等しい場合、デフォルト差は、PH内で示されるph_log2_diff_min_qt_min_cb_chromaによって上書きされてもよい。sps_log2_diff_min_qt_min_cb_intra_slice_chromaの値は、0以上CtbLog2SizeY―MinCbLog2SizeY―(CtbLog2SizeY>6&&qtbtt_dual_tree_intra_flag)以下の範囲である。存在しない場合、sps_log2_diff_min_qt_min_cb_intra_slice_chromaの値は0に等しいと推定されてもよい。treeTypeがDUAL_TREE_CHROMAに等しいCTUの四分木分割から生じる色差リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数は、式(40)として導出される。
MinQtLog2SizeIntraC=sps_log2_diff_min_qt_min_cb_intra_slice_chroma+MinCbLog2SizeY (40)
同様に、ピクチャヘッダ内のph_log2_diff_min_qt_min_cb_intra_slice_chromaの意味も変更されてもよい。具体的には、ph_log2_diff_min_qt_min_cb_intra_slice_chromaは、teeTypeがDUAL_TREE_CHROMA に等しい色差CTUの四分木分割から生じる色差リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数と、ピクチャヘッダに関連してslice_typeが2(Iスライスを示す)に等しいスライス内のtreeTypeがDUAL_TREE_CHROMAに等しい色差CUの輝度サンプルにおける最小符号化ブロックサイズの2を底とする対数との間の差を指定するために使用される。ph_log2_diff_min_qt_min_cb_intra_slice_chromaの値は、0以上CtbLog2SizeY―MinCbLog2SizeY―(CtbLog2SizeY>6&&qtbtt_dual_tree_intra_flag)以下の範囲でもよい。存在しない場合、ph_log2_diff_min_qt_min_cb_intra_slice_chromaの値はsps_log2_diff_min_qt_min_cb_intra_slice_chromaに等しいと推定される。partition_constraints_override_enabled_flagが1に等しい場合、式(40)のsps_log2_diff_min_qt_min_cb_intra_slice_chromaの代わりにph_log2_diff_min_qt_min_cb_chromaが使用される。
図29は、本開示の一実施形態によるプロセス(2900)を概略的に示すフローチャートを示す。プロセス(2900)は、符号化ビデオシーケンスのピクチャ内のブロック(例えば、CB)を復元するために使用されてもよい。ブロックという用語は、予測ブロック、CB、CU等として解釈されてもよい。様々な実施形態では、プロセス(2900)は、端末デバイス(310)、(320)、(330)及び(340)内の処理回路、ビデオエンコーダ(403)の機能を実行する処理回路、ビデオデコーダ(410)の機能を実行する処理回路、ビデオデコーダ(510)の機能を実行する処理回路、ビデオエンコーダ(603)の機能を実行する処理回路等のような処理回路によって実行される。いくつかの実施形態では、プロセス(2900)は、ソフトウェア命令で実装され、したがって、処理回路がソフトウェア命令を実行すると、処理回路はプロセス(2900)を実行する。プロセスは(S2901)で始まり、(S2910)に進む。
(S2910)において、分割情報が符号化ビデオビットストリームから復号される。分割情報は、イントラ符号化(I)スライスについての最小許容四分木(QT)リーフノードサイズを示す。Iスライスについての最小許容QTリーフノードサイズは、符号化ツリーユニット(CTU)サイズよりも小さい閾値によって制限される。
いくつかの実施形態では、Iスライスについての最小許容QTリーフノードサイズの2を底とする対数(例えば、MinQtLog2SizeIntraY、MinQtLog2SizeIntraC)は、CTUサイズの2を底とする対数(例えば、CtbLog2SizeY)よりも小さくなるように制限される。いくつかの例では、Iスライスについての最小許容QTリーフノードサイズの2を底とする対数は、CTUサイズの2を底とする対数より1だけ小さい(例えば、CtbLog2SizeY>6&&qtbtt_dual_tree_intra_flagは1に等しい)。一例では、CTUサイズは128であり、CTUサイズの2を底とする対数は7であり、Iスライスについての最小許容QTリーフノードサイズの2を底とする対数(例えば、MinQtLog2SizeIntraY、MinQtLog2SizeIntraC)は、6によって制限される(例えば、6以下である)。
いくつかの実施形態では、分割情報は、輝度成分についての最小許容QTリーフノードサイズ(例えば、MinQtLog2SizeIntraY)を示す。一実施形態では、Iスライスについての最小許容QTリーフノードサイズは、Iスライスに使用されるデュアルツリー分割(例えば、qtbtt_dual_tree_intra_flagが1に等しい)に応じて閾値によって制限される。いくつかの例では、閾値は、暗示的なQT分割要件に基づいて決定される(例えば、暗示的なQT分割が128のブロックサイズ以上に適用される)。
いくつかの実施形態では、分割情報は、色差成分についての最小許容QTリーフノードサイズ(例えば、MinQtLog2SizeIntraC)を示す。
一例では、分割情報は、sps_log2_diff_min_qt_min_cb_intra_slice_luma、sps_log2_diff_min_qt_min_cb_intra_slice_chroma等のような形式でシーケンスパラメータセット(SPS)内にある。他の例では、分割情報は、ph_log2_diff_min_qt_min_cb_intra_slice_luma、ph_log2_diff_min_qt_min_cb_intra_slice_chroma等のような形式でピクチャヘッダ(PH)内にある。
一例では、sps_log2_diff_min_qt_min_cb_intra_slice_lumaは、0からCtbLog2SizeY―MinCbLog2SizeY―(CtbLog2SizeY>6&&qtbtt_dual_tree_intra_flag)の範囲に制限される。CTUサイズが128である場合、CtbLog2SizeYは7である。さらに、qtbtt_dual_tree_intra_flagが1に等しい場合、sps_log2_diff_min_qt_min_cb_intra_slice_lumaの最大値は(6―MinCbLog2SizeY)である。次いで、MinQtLog2IntraYの最大値は、式(39)に従って6であり、最小許容四分木(QT)リーフノードサイズは、64の閾値によって制限される。
上記の例では、partition_constrains_override_enabled_flagが1に等しい場合、sps_log2_diff_min_qt_min_cb_intra_slice_lumaの代わりにph_log2_diff_min_qt_min_cb_intra_slice_lumaが使用されてもよい点に留意すべきである。
一例では、sps_log2_diff_min_qt_min_cb_intra_slice_chromaは、0からCtbLog2SizeY―MinCbLog2SizeY―(CtbLog2SizeY>6&&qtbtt_dual_tree_intra_flag)の範囲に制限される。CTUサイズが128の場合、CtbLog2SizeYは7である。さらに、qtbtt_dual_tree_intra_flagが1である場合、sps_log2_diff_min_qt_min_cb_intra_slice_chromaの最大値は(6―MinCbLog2SizeY)である。次いで、MinQtLog2IntraCの最大値は式(40)に従って6であり、最小許容四分木(QT)リーフノードサイズは、64個の輝度サンプル(例えば、64個の輝度サンプル×64個の輝度サンプルのブロック)の閾値によって制限される。色差フォーマットに基づいて、最小許容四分木(QT)リーフノードサイズの対応する色差ブロックサイズが決定されてもよい。
上記の例では、partition_constrains_override_enabled_flagが1に等しい場合、sps_log2_diff_min_qt_min_cb_intra_slice_chromaの代わりに、ph_log2_diff_min_qt_min_cb_intra_slice_chromaが使用されてもよい点に留意すべきである。
(S2920)において、Iスライス内の符号化ツリーブロックは、最小許容QTリーフノードサイズに基づいて符号化ブロックに分割される。いくつかの実施形態では、BT分割又はTT分割を適用する前に、符号化ツリーブロックを、最小許容QTリーフノードサイズの要件を満たすQTリーフノードに分割するために、QT分割が適用されてもよい。
(S2930)において、符号化ブロックは、符号化ビデオビットストリームからそれぞれ復元される。次いで、プロセスは(S2999)に進み、終了する。
本開示の実施形態は、別々に使用されてもよく或いはいずれかの順序で組み合わされてもよい。さらに、方法(又は実施形態)、エンコーダ及びデコーダのそれぞれは、処理回路(例えば、1つ以上のプロセッサ又は1つ以上の集積回路)によって実装されてもよい。一例では、1つ以上のプロセッサは、非一時的なコンピュータ読み取り可能媒体に記憶されたプログラムを実行する。
上記の技術は、コンピュータ読み取り可能命令を使用してコンピュータソフトウェアとして実装され、1つ以上のコンピュータ読み取り可能媒体に物理的に記憶されてもよい。例えば、図30は、開示の対象物の特定の実施形態を実装するのに適したコンピュータシステム(3000)を示す。
コンピュータソフトウェアは、いずれかの適切な機械コード又はコンピュータ言語を使用して符号化されてもよく、当該機械コード又はコンピュータ言語は、命令を含むコードを生成するために、アセンブリ、コンパイル、リンク又は類似のメカニズムを受けてもよく、当該命令は、1つ以上のコンピュータ中央処理装置(CPU, central processing unit)、グラフィックス処理ユニット(GPU, Graphics Processing Unit)等によって、直接的に或いはインタープリタ、マイクロコード実行等を通じて実行されてもよい。
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットのデバイス等を含む様々なタイプのコンピュータ又はその構成要素上で実行されてもよい。
コンピュータシステム(3000)について図30に示される構成要素は、本質的に例示的なものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用範囲又は機能に関する如何なる限定も示唆することを意図するものではない。また、構成要素の構成も、コンピュータシステム(3000)の例示的な実施形態に示される構成要素のいずれか1つ又は組み合わせに関する如何なる依存性又は要件も有するものとして解釈されるべきではない。
コンピュータシステム(3000)は、特定のヒューマンインタフェース入力デバイスを含んでもよい。このようなヒューマンインタフェース入力デバイスは、例えば、触覚入力(キーストローク、スワイプ、データグローブの動き等)、オーディオ入力(音声、拍手等)、視覚入力(ジェスチャ等)、嗅覚入力(図示せず)を通じて、1人以上の人間のユーザによる入力に応答してもよい。また、ヒューマンインタフェースデバイスは、オーディオ(例えば、会話、音楽、周辺音)、画像(スキャンされた画像、静止画カメラから取得された写真画像等)、ビデオ(2次元ビデオ、立体ピクチャを含む3次元ビデオ等)のような、人間による意識的入力に必ずしも直接関連しない特定のメディアをキャプチャするために使用されてもよい。
入力ヒューマンインタフェースデバイスは、キーボード(3001)、マウス(3002)、トラックパッド(3003)、タッチ画面(3010)、データグローブ(図示せず)、ジョイスティック(3005)、マイクロフォン(3006)、スキャナ(3007)、カメラ(3008)のうち1つ以上を含んでもよい。
また、コンピュータシステム(3000)は、特定のヒューマンインタフェース出力デバイスを含んでもよい。このようなヒューマンインタフェース出力デバイスは、例えば、触覚出力、音、光及び嗅覚/味覚を通じて、1人以上の人間のユーザの感覚を刺激してもよい。このようなヒューマンインタフェース出力デバイスは、触覚出力デバイス(例えば、タッチ画面(3010)、データグローブ(図示せず)又はジョイスティック(3005)による触覚フィードバック、ただし、入力デバイスとして機能しない触覚フィードバックデバイスが存在してもよい)と、オーディオ出力デバイス(スピーカ(3009)、ヘッドフォン(図示せず)等)と、視覚出力デバイス(それぞれがタッチ画面入力機能を有しても有さなくてもよく、それぞれが触覚フィードバック機能を有しても有さなくてもよく、いくつかが2次元視覚出力又は立体出力のような手段を通じた3次元以上の出力を出力可能でもよいCRT画面、LCD画面、プラズマ画面、OLED画面を含む画面(3010)、仮想現実メガネ(図示せず)、ホログラフィックディスプレイ及びスモークタンク(図示せず))と、プリンタ(図示せず)とを含んでもよい。
また、コンピュータシステム(3000)は、CD/DVD又は同様の媒体(3021)を有するCD/DVD ROM/RW(3020)を含む光媒体のような人間がアクセス可能な記憶デバイス及び関連する媒体、サムドライブ(3022)、取り外し可能ハードドライブ又はソリッドステートドライブ(3023)、テープ及びフロッピーディスク(図示せず)のようなレガシー磁気媒体、セキュリティドングル(図示せず)のような特殊なROM/ASIC/PLDに基づくデバイス等を含んでもよい。
また、当業者は、ここに開示の対象物に関連して使用される用語「コンピュータ読み取り可能媒体」が伝送媒体、搬送波又は他の非一時的な信号を含まないことを理解すべきである。
また、コンピュータシステム(3000)は、1つ以上の通信ネットワーク(3055)へのインタフェース(3054)を含んでもよい。ネットワークは、例えば、無線、有線、光でもよい。ネットワークは、ローカル、広域、メトロポリタン、車両及び産業、リアルタイム、遅延耐性等でもよい。ネットワークの例は、イーサネット、無線LAN、セルラネットワーク(GSM、3G、4G、5G、LTE等を含む)、TV有線又は無線広域デジタルネットワーク(ケーブルTV、衛星TV、及び地上放送TVを含む)、車両及び産業(CANBusを含む)等を含む。特定のネットワークは、一般的に、特定の汎用データポート又は周辺バス(3049)に取り付けられる外部ネットワークインタフェースアダプタ(例えば、コンピュータシステム(3000)のUSBポート等)を必要とし、他のネットワークインタフェースアダプタは、一般的に、以下に説明するシステムバス(例えば、PCコンピュータシステムへのイーサネットインタフェース又はスマートフォンコンピュータシステムへのセルラネットワーク)に取り付けられることによって、コンピュータシステム(3000)のコアに統合される。これらのネットワークのいずれかを使用して、コンピュータシステム(3000)は、他のエンティティと通信することができる。このような通信は、一方向の受信のみ(例えば、放送TV)、一方向の送信のみ(例えば、特定のCANbusデバイスへのCANbus)でもよく、或いは、例えば、ローカル又は広域デジタルネットワークを使用する他のコンピュータシステムへの双方向でもよい。特定のプロトコル及びプロトコルスタックは、上記のようなネットワーク及びネットワークインタフェースのそれぞれにおいて使用されてもよい。
上記のヒューマンインタフェースデバイス、人間がアクセス可能な記憶デバイス及びネットワークインタフェースは、コンピュータシステム(3000)のコア(3040)に取り付けられてもよい。
コア(3040)は、1つ以上の中央処理装置(CPU)(3041)、グラフィックス処理ユニット(GPU)(3042)、フィールドプログラマブルゲートアレイ(FPGA, Field Programmable Gate Area)(3043)の形式の特殊なプログラム可能処理ユニット、特定のタスク用のハードウェアアクセラレータ(3044)、グラフィックスアダプタ(3050)等を含んでもよい。これらのデバイスは、読み取り専用メモリ(ROM)(3045)、ランダムアクセスメモリ(3046)、内部大容量記憶装置(内部のユーザアクセス不可能なハードドライブ、SSD等)(3047)と共に、システムバス(3048)を通じて接続されてもよい。いくつかのコンピュータシステムでは、システムバス(3048)は、更なるCPU、GPU等による拡張を可能にするために、1つ以上の物理プラグの形式でアクセス可能でもよい。周辺デバイスは、コアのシステムバス(3048)に直接取り付けられてもよく、或いは、周辺バス(3049)を通じて取り付けられてもよい。一例では、ディスプレイ(3010)はグラフィックスアダプタ(3050)に取り付けられてもよい。周辺バスのアーキテクチャは、PCI、USB等を含む。
CPU(3041)、GPU(3042)、FPGA(3043)及びアクセラレータ(3044)は特定の命令を実行してもよく、当該特定の命令は、組み合わせによって上記のコンピュータコードを構成してもよい。当該コンピュータコードは、ROM(3045)又はRAM(3046)に記憶されてもよい。また、一時的なデータは、RAM(3046)に記憶されてもよいが、永続的なデータは、例えば、内部大容量記憶装置(3047)に記憶されてもよい。1つ以上のCPU(3041)、GPU(3042)、大容量記憶装置(3047)、ROM(3045)、RAM(3046)等と密接に関連してもよいキャッシュメモリを使用することによって、メモリデバイスのいずれかへの高速記憶及び検索が可能になってもよい。
コンピュータ読み取り可能媒体は、様々なコンピュータに実装された動作を実行するためのコンピュータコードを有してもよい。媒体及びコンピュータコードは、本開示の目的のために特に設計及び構築されたものでよく、或いは、コンピュータソフトウェア分野における当業者に周知で入手可能なようなものでもよい。
限定ではなく一例として、アーキテクチャ(3000)、具体的には、コア(3040)を有するコンピュータシステムは、1つ以上の有形のコンピュータ読み取り可能媒体に具現されたソフトウェアを実行するプロセッサ(CPU、GPU、FPGA、アクセラレータ等を含む)の結果として機能を提供できる。このようなコンピュータ読み取り可能媒体は、コア内部の大容量記憶装置(3047)又はROM(3045)のような非一時的な性質のコア(3040)の特定の記憶装置と同様に、上記のようなユーザがアクセス可能な大容量記憶装置に関連する媒体でもよい。本開示の様々な実施形態を実装するソフトウェアは、このようなデバイスに記憶されてコア(3040)によって実行されてもよい。コンピュータ読み取り可能媒体は、特定のニーズに従って、1つ以上のメモリデバイス又はチップを含んでもよい。ソフトウェアは、コア(3040)、具体的には、その中のプロセッサ(CPU、GPU、FPGA等を含む)に、RAM(3046)に記憶されたデータ構造を定義し、ソフトウェアによって定義された処理に従ってこのようなデータ構造を修正することを含む、本明細書に記載の特定の処理又は特定の処理の特定の部分を実行させてもよい。さらに或いは代替として、コンピュータシステムは、回路(例えば、アクセラレータ(3044))内に配線されたロジック又は他の方法で具現されたロジックの結果として、機能を提供してもよく、当該回路は、本明細書に記載の特定の処理又は特定の処理の特定の部分を実行するために、ソフトウェアの代わりに或いはソフトウェアと共に動作してもよい。ソフトウェアへの言及は、ロジックを含み、必要に応じて、その逆も可能である。コンピュータ読み取り可能媒体への言及は、必要に応じて、実行するためのソフトウェアを記憶する回路(集積回路(IC)等)、実行するためのロジックを具現する回路又はこれらの双方を含んでもよい。本開示は、ハードウェア及びソフトウェアのいずれかの適切な組み合わせを含む。
[付録A:略語]
JEM: joint exploration model
VVC: versatile video coding
BMS: benchmark set
MV: Motion Vector
HEVC: High Efficiency Video Coding
SEI: Supplementary Enhancement Information
VUI: Video Usability Information
GOP: Group of Pictures
TU: Transform Unit
PU: Prediction Unit
CTU: Coding Tree Unit
CTB: Coding Tree Block
PB: Prediction Block
HRD: Hypothetical Reference Decoder
SNR: Signal Noise Ratio
CPU: Central Processing Unit
GPU: Graphics Processing Unit
CRT: Cathode Ray Tube
LCD: Liquid―Crystal Display
OLED: Organic Light―Emitting Diode
CD: Compact Disc
DVD: Digital Video Disc
ROM: Read―Only Memory
RAM: Random Access Memory
ASIC: Application―Specific Integrated Circuit
PLD: Programmable Logic Device
LAN: Local Area Network
GSM: Global System for Mobile communications
LTE: Long―Term Evolution
CANBus: Controller Area Network Bus
USB: Universal Serial Bus
PCI: Peripheral Component Interconnect
FPGA: Field Programmable Gate Areas
SSD: solid―state drive
IC: Integrated Circuit
CU: Coding Unit
本開示は、いくつかの例示的な実施形態を記載しているが、本開示の範囲内に入る変更、置換及び様々な代替の等価物が存在する。したがって、当業者は、本明細書に明示的に図示又は記載されていないが、本開示の原理を具現し、したがって、本開示の真意及び範囲内にある多数のシステム及び方法を考案することができることが認識される。

Claims (13)

  1. デコーダが実行するビデオ復号のための方法であって、
    符号化ビデオビットストリームから分割情報を復号するステップであって、前記分割情報は、イントラ符号化(I)スライスについての最小許容四分木(QT)リーフノードサイズを示し、前記Iスライスについての前記最小許容QTリーフノードサイズは、符号化ツリーユニット(CTU)サイズよりも小さい閾値によって制限される、ステップと、
    前記最小許容QTリーフノードサイズに基づいて、前記Iスライス内の符号化ツリーブロックを符号化ブロックに分割するステップと、
    前記符号化ビデオビットストリームからそれぞれ前記符号化ブロックを復元するステップと
    を含む方法。
  2. 前記分割情報は、輝度成分についての最小許容QTリーフノードサイズを示す、請求項1に記載の方法。
  3. 前記Iスライスについての前記最小許容QTリーフノードサイズは、前記Iスライスに使用されるデュアルツリー分割に応じて前記閾値によって制限される、請求項2に記載の方法。
  4. 暗示的なQT分割要件に基づいて前記閾値を決定するステップを更に含む、請求項2又は3に記載の方法。
  5. 前記分割情報は、色差成分についての最小許容QTリーフノードサイズを示す、請求項1に記載の方法。
  6. シーケンスパラメータセット(SPS)から前記分割情報を復号するステップを更に含む、請求項1乃至5のうちいずれか1項に記載の方法。
  7. ピクチャヘッダ(PH)から前記分割情報を復号するステップを更に含む、請求項1乃至5のうちいずれか1項に記載の方法。
  8. 二分木(BT)分割又は三分木(TT)分割を適用する前に、QT分割を適用し、前記符号化ツリーブロックを、前記最小許容QTリーフノードサイズの要件を満たすQTリーフノードに分割するステップを更に含む、請求項1乃至7のうちいずれか1項に記載の方法。
  9. 前記Iスライスについての前記最小許容QTリーフノードサイズの2を底とする対数は、前記CTUサイズの2を底とする対数よりも小さくなるように制限される、請求項1乃至8のうちいずれか1項に記載の方法。
  10. 前記Iスライスについての前記最小許容QTリーフノードサイズの前記2を底とする対数は、前記CTUサイズの前記2を底とする対数よりも1だけ小さい、請求項9に記載の方法。
  11. ビデオ復号のための装置であって、
    請求項1乃至10のうちいずれか1項に記載の方法を実行するように構成された処理回路を含む装置。
  12. プロセッサに請求項1乃至10のうちいずれか1項に記載の方法を実行させるコンピュータプログラム。
  13. エンコーダが実行するビデオ符号化のための方法であって、
    最小許容四分木(QT)リーフノードサイズに基づいて、イントラ符号化(I)スライス内の符号化ツリーブロックを符号化ブロックに分割するステップと、
    分割情報を符号化ビデオビットストリームに符号化するステップであって、前記分割情報は、前記Iスライスについての前記最小許容QTリーフノードサイズを示し、前記Iスライスについての前記最小許容QTリーフノードサイズは、符号化ツリーユニット(CTU)サイズよりも小さい閾値によって制限される、ステップと、
    を含む方法。
JP2021560898A 2020-02-21 2021-01-13 ビデオ符号化又はビデオ復号のための方法、装置及びコンピュータプログラム Active JP7377887B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US202062979911P 2020-02-21 2020-02-21
US62/979,911 2020-02-21
US17/077,748 US11206416B2 (en) 2020-02-21 2020-10-22 Method and apparatus for video coding
US17/077,748 2020-10-22
PCT/US2021/013245 WO2021167720A1 (en) 2020-02-21 2021-01-13 Method and apparatus for video coding

Publications (2)

Publication Number Publication Date
JP2022529636A true JP2022529636A (ja) 2022-06-23
JP7377887B2 JP7377887B2 (ja) 2023-11-10

Family

ID=77366622

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021560898A Active JP7377887B2 (ja) 2020-02-21 2021-01-13 ビデオ符号化又はビデオ復号のための方法、装置及びコンピュータプログラム

Country Status (6)

Country Link
US (3) US11206416B2 (ja)
EP (1) EP4107938A4 (ja)
JP (1) JP7377887B2 (ja)
KR (1) KR20210134406A (ja)
CN (3) CN118474399A (ja)
WO (1) WO2021167720A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021202178A1 (en) * 2020-03-31 2021-10-07 Beijing Dajia Internet Information Technology Co., Ltd. Methods and devices for high-level syntax in video coding
WO2023198110A1 (en) * 2022-04-13 2023-10-19 Mediatek Inc. Block partitioning image and video data

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2870067C (en) * 2012-04-16 2017-01-17 Nokia Corporation Video coding and decoding using multiple parameter sets which are identified in video unit headers
US10911757B2 (en) * 2017-09-08 2021-02-02 Mediatek Inc. Methods and apparatuses of processing pictures in an image or video coding system
US10771781B2 (en) * 2018-03-12 2020-09-08 Electronics And Telecommunications Research Institute Method and apparatus for deriving intra prediction mode
WO2019189279A1 (en) 2018-03-30 2019-10-03 Sharp Kabushiki Kaisha Systems and methods for partitioning video blocks at a boundary of a picture for video coding
EP3785433A4 (en) 2018-04-30 2022-02-23 MediaTek Inc. SYNTAX INTERLACE METHOD AND APPARATUS FOR A SEPARATE CODING TREE IN A VIDEO CODING SYSTEM
EP3804315A4 (en) * 2018-05-31 2022-03-09 Sharp Kabushiki Kaisha SYSTEMS AND METHODS FOR PARTITIONING VIDEO BLOCKS INTO A SLOT FOR INTERPRETING VIDEO DATA
TWI720584B (zh) * 2018-08-16 2021-03-01 聯發科技股份有限公司 視訊處理系統中色度量化參數導出的方法以及裝置
US11245922B2 (en) * 2018-08-17 2022-02-08 Mediatek Inc. Shared candidate list
US11589044B2 (en) * 2019-10-14 2023-02-21 Hfi Innovation Inc. Video encoding and decoding with ternary-tree block partitioning
US11240524B2 (en) * 2019-11-27 2022-02-01 Mediatek Inc. Selective switch for parallel processing
US11716490B2 (en) * 2020-02-06 2023-08-01 Qualcomm Incorporated Binary split at picture boundary for image and video coding

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SHIH-TA HSIANG ET AL., AHG9: FIX ON HIGH-LEVEL SYNTAX RELATED TO CODING TREE CONSTRAINTS, JPN6022045889, 10 January 2020 (2020-01-10), ISSN: 0004911146 *

Also Published As

Publication number Publication date
US20210266579A1 (en) 2021-08-26
JP7377887B2 (ja) 2023-11-10
CN113841390B (zh) 2024-04-19
CN113841390A (zh) 2021-12-24
CN118301372A (zh) 2024-07-05
US11206416B2 (en) 2021-12-21
KR20210134406A (ko) 2021-11-09
US20220030262A1 (en) 2022-01-27
CN118474399A (zh) 2024-08-09
EP4107938A4 (en) 2024-03-13
US20230283794A1 (en) 2023-09-07
US11711531B2 (en) 2023-07-25
WO2021167720A1 (en) 2021-08-26
EP4107938A1 (en) 2022-12-28

Similar Documents

Publication Publication Date Title
JP7046220B2 (ja) 小ブロックの予測と変換のための方法、装置、及びプログラム
CN113170102B (zh) 视频编码方法、装置、计算机设备和存储介质
JP7322171B2 (ja) ビデオ符号化及び復号における最小符号化ブロックサイズの範囲
JP2022511865A (ja) ビデオ符号化又は復号の方法及び装置並びにコンピュータプログラム
JP2022517114A (ja) ビデオ復号用の方法、装置およびプログラム
KR102574427B1 (ko) 인트라 예측 모드와 블록 차분 펄스-코드 변조 모드 사이의 상호작용을 위한 방법 및 장치
US11722701B2 (en) Signaling of coding tools for encoding a video component as monochrome video
CN113366847B (zh) 用于视频编解码的方法、装置及可读介质
JP2022511851A (ja) 最大変換サイズの制御
JP7544331B2 (ja) ビデオ符号化/復号のための方法および装置
JP2022525748A (ja) ビデオ符号化のための色変換
JP2022522683A (ja) ビデオコーディングのための方法並びにその、装置およびコンピュータプログラム
JP2022526380A (ja) スキップモードフラグを伝達するための方法、装置及びコンピュータプログラム
KR102663502B1 (ko) 비디오 코딩 방법 및 장치
JP2022512109A (ja) ビデオ復号及び符号化の方法、装置並びにプログラム
US20220030262A1 (en) Method and apparatus for video coding
CN112135151B (zh) 视频解码方法、系统、计算机设备和存储介质
JP2022520855A (ja) Qt/bt/ttサイズの改善されたヘッダシンタックス
JP7439344B2 (ja) ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム
CN113286152B (zh) 视频解码方法、装置、计算机设备及存储介质
RU2796261C1 (ru) Диапазон минимального размера блока кодирования при кодировании видео
JP2023543586A (ja) スキップ変換フラグ符号化
JP2024514116A (ja) パレット予測子生成およびシグナリング
JP2022523616A (ja) ビデオ復号の方法、装置、及びコンピュータプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20211013

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20221101

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230131

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230516

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230804

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: 20231003

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20231030

R150 Certificate of patent or registration of utility model

Ref document number: 7377887

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150