JP2024518007A - 非インターリーブ分離ツリー - Google Patents

非インターリーブ分離ツリー Download PDF

Info

Publication number
JP2024518007A
JP2024518007A JP2023525099A JP2023525099A JP2024518007A JP 2024518007 A JP2024518007 A JP 2024518007A JP 2023525099 A JP2023525099 A JP 2023525099A JP 2023525099 A JP2023525099 A JP 2023525099A JP 2024518007 A JP2024518007 A JP 2024518007A
Authority
JP
Japan
Prior art keywords
chroma
luma
ctb
picture
block
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2023525099A
Other languages
English (en)
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 JP2024518007A publication Critical patent/JP2024518007A/ja
Pending legal-status Critical Current

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/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/132Sampling, masking or truncation of coding units, e.g. adaptive resampling, frame skipping, frame interpolation or high-frequency transform coefficient masking
    • 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/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/124Quantisation
    • 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/13Adaptive entropy coding, e.g. adaptive variable length coding [AVLC] or context adaptive binary arithmetic coding [CABAC]
    • 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/136Incoming video signal characteristics or properties
    • H04N19/137Motion inside a coding unit, e.g. average field, frame or block difference
    • 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
    • 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/184Methods 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 bits, e.g. of the compressed video stream
    • 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/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/188Methods 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 video data packet, e.g. a network abstraction layer [NAL] unit
    • 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/1883Methods 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 relating to sub-band structure, e.g. hierarchical level, directional tree, e.g. low-high [LH], high-low [HL], high-high [HH]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/436Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation using parallelised computational arrangements
    • 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)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

本開示の態様は、ビデオエンコーディング/デコーディングのための方法および装置を提供する。いくつかの例において、ビデオデコーディングのための装置は、処理回路を含む。処理回路は、ビットストリームにおけるコーディングツリーユニット(CTU)の異なる色成分のコーディングに非インターリーブ分離ツリー構造が使用されていると決定する。処理回路は、ビットストリームの第1の部分から複数のCTUの第1の色成分を復号し、ビットストリームの第2の部分から複数のCTUの第2の色成分を復号し、第2の部分は、ビットストリームにおいて第1の部分の後に位置する。

Description

参照による援用
本出願は、2021年7月22日に出願された米国仮出願第63/224,767号「非インターリーブドセパレートツリー(Non-Interleaved Separate Tree)」および2021年7月22日に出願された米国仮出願第63/224,771号「非インターリーブドセパレートツリー(Non-Interleaved Separate Tree)」に対する優先権の利益を主張する2022年7月18日に出願された米国特許出願第17/867,349号「非インターリーブドセパレートツリー(NON-INTERLEAVED SEPARATE TREE)」に対する優先権の利益を主張する。先行の出願の開示は、それらの全体が参照により本明細書に組み込まれる。
本開示は、ビデオコーディングに一般的に関連する実施形態を説明する。
本明細書において提供される背景技術の説明は、本開示の背景を大まかに提示することを目的としている。この背景技術の箇所に記載される程度までの現時点の記名発明者の仕事、ならびに他の点で出願時点における先行技術として適格ではない可能性がある本明細書の態様は、明示的にも黙示的にも、本開示に対する先行技術として認められるものではない。
非圧縮デジタルビデオは、一連のピクチャを含むことができ、各ピクチャは、例えば、1920×1080の輝度サンプルおよび関連の色サンプルの空間次元を有する。一連のピクチャは、例えば、毎秒60ピクチャまたは60Hzの固定または可変のピクチャレート(非公式には、フレームレートとしても知られる)を有することができる。非圧縮ビデオは、特有のビットレート要件を有する。例えば、サンプルあたり8ビットでの1080p60 4:2:0ビデオ(60Hzのフレームレートで1920×1080の輝度サンプル解像度)は、1.5Gbit/sに近い帯域幅を必要とする。1時間のそのようなビデオは、600Gバイトを超えるストレージ空間を必要とする。
ビデオのコーディングおよびデコーディングの1つの目的は、圧縮による入力ビデオ信号の冗長性の低減であり得る。圧縮は、前述の帯域幅および/またはストレージ空間の要件を、場合によっては、2桁以上削減するのに役立つことができる。可逆圧縮および非可逆圧縮の両方、ならびにそれらの組み合わせを採用することができる。可逆圧縮は、圧縮された元の信号から元の信号の正確なコピーを復元することができる技法を指す。非可逆圧縮を使用すると、復元された信号が元の信号と同一でない可能性があるが、元の信号と復元された信号との間の歪みは、復元された信号を目的の用途にとって有用なものにするほどに充分に小さい。ビデオの場合、非可逆圧縮が広く採用されている。許容される歪みの量は、用途に依存し、例えば、特定の消費者ストリーミング用途のユーザは、テレビ配信用途のユーザよりも大きい歪みを許容し得る。達成可能な圧縮比は、より大きな歪みを容認/許容できるならば圧縮比がより大きくてよいという事実を反映できる。
ビデオエンコーダおよびデコーダは、例えば、動き補償、変換、量子化、およびエントロピーコーディングなどのいくつかの広範なカテゴリからの技術を利用し得る。
ビデオコーデック技術は、イントラコーディングとして知られる技術を含み得る。イントラコーディングにおいて、サンプル値は、以前に復元された参照ピクチャからのサンプルまたは他のデータを参照することなく表される。一部のビデオコーデックにおいて、ピクチャは、サンプルのブロックへと空間的に細分化される。サンプルのすべてのブロックがイントラモードでコーディングされるとき、そのピクチャはイントラピクチャであり得る。イントラピクチャ、および独立デコーダリフレッシュピクチャなどのそれらの派生物は、デコーダ状態をリセットするために使用することができるため、コーディングされたビデオビットストリームおよびビデオセッション内の最初のピクチャとして、または静止画像として使用され得る。イントラブロックのサンプルに変換を施すことができ、変換係数をエントロピーコーディングの前に量子化することができる。イントラ予測は、変換前ドメインにおけるサンプル値を最小化する技術であり得る。いくつかの場合、変換後のDC値がより小さく、AC係数がより小さいほど、エントロピーコーディング後のブロックを表すために所与の量子化ステップサイズにおいて必要とされるビットは少なくなる。
例えば、MPEG-2生成コーディング技術から知られているような従来のイントラコーディングは、イントラ予測を使用しない。しかしながら、いくつかのより新しいビデオ圧縮技術は、例えば、空間的に隣接し、デコーディング順序において先行するデータブロックのエンコーディングおよび/またはデコーディング中に取得された周囲のサンプルデータおよび/またはメタデータから試行する技法を含む。そのような技法は、以下で「イントラ予測」技法と呼ばれる。少なくともいくつかの場合において、イントラ予測は、復元中のカレントピクチャからの参照データのみを使用し、参照ピクチャからの参照データを使用しないことに留意されたい。
イントラ予測の多数の異なる形式が存在し得る。そのような技法のうちの2つ以上を所与のビデオコーディング技術において使用できるとき、使用中の技法は、イントラ予測モードでコーディングされ得る。特定の場合、モードは、サブモードおよび/またはパラメータを有することができ、それらを個別にコーディングするか、あるいはモードのコードワードに含めることができる。所与のモード、サブモード、および/またはパラメータの組み合わせにどのコードワードを使用するかは、イントラ予測によるコーディング効率向上に影響を与える可能性があり、したがってコードワードをビットストリームに変換するために使用されるエントロピーコーディング技術も影響を与える可能性がある。
イントラ予測の特定のモードは、H.264で導入され、H.265において改良され、共同探索モデル(JEM:joint exploration model)、多用途ビデオコーディング(VVC:versatile video coding)、およびベンチマークセット(BMS:benchmark set)などのより新しいコーディング技術においてさらに改良された。予測器ブロックを、既に利用可能なサンプルに属する隣接サンプル値を使用して形成することができる。隣接サンプルのサンプル値は、方向に従って予測器ブロックにコピーされる。使用中の方向への参照は、ビットストリーム中にコーディングされてよく、それ自体が予測されてもよい。
図1Aを参照すると、H.265の(35個のイントラモードのうちの33個の角度モードに対応する)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は、ブロック(104)内のY次元およびX次元の両方において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個のイントラ予測方向を描写する概略図(110)を示している。
方向を表すコーディングされたビデオビットストリーム内のイントラ予測方向ビットのマッピングは、ビデオコーディング技術ごとに異なってもよく、例えば、予測方向のイントラ予測モードへの単純な直接マッピングから、コードワード、最も可能性が高いモードを含む複雑な適応方式、および同様の技術まで及び得る。しかしながら、すべての場合において、ビデオコンテンツ内で特定の他の方向よりも統計的に発生する可能性が低い特定の方向が存在し得る。ビデオ圧縮の目的は冗長性の低減であるので、それらの可能性が低い方向は、うまく機能するビデオコーディング技術では、可能性が高い方向よりも多いビット数によって表される。
ビデオのコーディングおよびデコーディングを、動き補償を伴うインターピクチャ予測を使用して実行することができる。動き補償は、非可逆圧縮技術であってよく、以前に復元されたピクチャまたはその一部(参照ピクチャ)からのサンプルデータのブロックが、動きベクトル(以下では、MV)によって示される方向に空間的にシフトされた後に、新たに復元されるピクチャまたはピクチャ部分の予測に使用される技術に関係することができる。場合によっては、参照ピクチャは、現時点において復元中のピクチャと同じであり得る。MVは、2つの次元XおよびY、または3つの次元を有することができ、3番目の次元は、使用中の参照ピクチャの指示であってよい(後者は、間接的に、時間次元であり得る)。
いくつかのビデオ圧縮技術では、サンプルデータの特定の領域に適用可能な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」、2016年12月)に、さまざまなMV予測機構が記載されている。ここでは、H.265が提供する多数のMV予測機構のうち、以下で「空間マージ」と呼ぶ技術について説明する。
図2を参照すると、カレントブロック(201)は、動き検索プロセスにおいてエンコーダによって空間的にシフトされた同じサイズの以前のブロックから予測可能であることが発見されたサンプルを含む。そのMVを直接コーディングする代わりに、MVを、A0、A1、およびB0、B1、B2(それぞれ、202~206)と表記された5つの周囲サンプルのいずれか1つに関連付けられたMVを使用して、1つまたは複数の参照ピクチャに関連付けられたメタデータから、例えば(デコーディング順序における)最新の参照ピクチャから導出することができる。H.265では、MV予測は、隣接ブロックが使用している同じ参照ピクチャからの予測器を使用することができる。
本開示の態様は、ビデオエンコーディング/デコーディングのための方法および装置を提供する。いくつかの例において、ビデオデコーディングのための装置は、処理回路を含む。処理回路は、ビットストリームにおけるコーディングツリーユニット(CTU)の異なる色成分のコーディングに非インターリーブ分離ツリー構造が使用されていると決定する。処理回路は、ビットストリームの第1の部分から複数のCTUの第1の色成分を復号し、ビットストリームの第2の部分から複数のCTUの第2の色成分を復号し、第2の部分と第1の部分とは、ビットストリームにおいてインターリーブされていない。
いくつかの例において、ビットストリームの第1の部分からの複数のCTUの第1の色成分の復号は、ビットストリームの第2の部分からの複数のCTUの第2の色成分の復号と並行して実行される。いくつかの例において、複数のCTUは、イントラピクチャ、インターピクチャ、イントラブロックコピー(IBC)ピクチャ、ピクチャ内のイントラスライス、ピクチャ内のインタースライス、ピクチャ内のIBCスライス、ピクチャ内のイントラタイル、ピクチャ内のインタータイル、またはピクチャ内のIBCタイルのうちの1つを形成する。
いくつかの例において、処理回路は、ビットストリーム中のネットワーク抽象化レイヤユニット(NALU)の第1の部分から複数のCTUのルマコーディングツリーブロック(CTB)を復号し、NALUの第2の部分から複数のCTUのクロマCTBを復号する。一例においては、第1の部分と第2の部分との間に1つまたは複数のビットが存在し、NALUの第2の部分は、NALU内の第1の部分の後の整数バイトから始まる。いくつかの例において、処理回路は、シーケンスパラメータセット(SPS)同期フラグの値に基づいてルマCTBとクロマCTBとの間のコンテキスト適応型バイナリ算術符号化(CABAC)同期を実行する。
いくつかの例において、処理回路は、ビットストリーム中の第1のネットワーク抽象化レイヤユニット(NALU)から複数のCTUのルマコーディングツリーブロック(CTB)を解析および復号し、ビットストリーム中の第2のNALUから複数のCTUのクロマCTBを解析および復号する。一例において、第1のNALUからの解析および復号は、第2のNALUからの解析および復号と並行して実行される。
いくつかの実施形態において、複数のCTUの第1の色成分は、複数のCTUのルマコーディングツリーブロック(CTB)に対応し、複数のCTUの第2の色成分は、クロマCTBに対応し、処理回路は、ルマCTBからルマサンプル内の異なるサイズのクロマCTBを復号する。
いくつかの実施形態において、処理回路は、クロスコンポーネント線形モデル(CCLM)モードにおいて少なくとも第1のルマコーディングツリーブロック(CTB)および第2のルマCTB内のルマサンプルに基づいてクロマブロック内のクロマサンプルを予測する。
いくつかの例において、処理回路は、クロマブロックと同位置の複数のルマブロックを決定し、クロマブロックの量子化パラメータ(QP)値を、複数のルマブロックのうちの復号された第1の同位置のルマブロックのQP値、複数のルマブロックの平均QP値、複数のルマブロックの中央QP値、またはクロマブロックの中心位置と同位置の中心ルマブロックのQPのうちの少なくとも1つに基づいて導出する。
いくつかの例において、処理回路は、ルマ処理チャネルにおいてルマサンプル内のCTBサイズのルマコーディングツリーブロック(CTB)を復号し、クロマ処理チャネルにおいてルマサンプル内のCTBサイズのクロマCTBを復号する。一例において、処理回路は、CTUのクロマCTBの復号を、CTUのルマCTBの復号の完了後に開始する。
いくつかの例において、処理回路は、クロマコーディングツリーブロック(CTB)のためのCTUレベル制御パラメータを、クロマCTBに関するビットストリームにおけるシグナリング、および同位置のルマCTBに基づくクロマCTBのためのCTUレベル制御パラメータの導出、のうちの少なくとも一方に基づいて決定する。
いくつかの例において、ルマコーディングツリーブロック(CTB)は、第1の分割ツリー構造を使用して分割され、クロマCTBは、第1の分割ツリー構造とは異なる第2の分割ツリー構造を使用して分割される。
一例において、処理回路は、ビットストリームから最大ルマツリーサイズを決定する。別の例において、処理回路は、ビットストリームから最小ルマツリーサイズを決定する。別の例において、処理回路は、ビットストリームから最大クロマツリーサイズを決定する。別の例において、処理回路は、ビットストリームから最小クロマツリーサイズを決定する。
いくつかの例において、処理回路は、クロマコーディングユニット(CU)の予測モードを同位置のルマCUに基づいて導出する。いくつかの例において、処理回路は、クロマCUの予測モードを、クロマCUが最小クロマブロックサイズ要件を満たすことに応答して、ビットストリーム内の信号に基づいて決定する。
いくつかの例において、処理回路は、クロマコーディングユニット(CU)の動きベクトルを、クロマCUがクロマイントラCUであることに応答して、同位置のルマCUの動きベクトルに基づいて導出する。
いくつかの例において、処理回路、クロマコーディングユニット(CU)のブロックベクトルを、クロマCUがクロマイントラブロックコピー(IBC)CUであることに応答して、同位置のルマCUのブロックベクトルに基づいて導出する。
さらに、本開示の態様は、ビデオデコーディングのためのコンピュータによって実行されたときにコンピュータにビデオデコーディングのための方法を実行させる命令を格納した非一時的なコンピュータ可読媒体も提供する。
開示される主題のさらなる特徴、性質、および種々の利点が、以下の詳細な説明および添付の図面からさらに明らかになるであろう。
イントラ予測モードの例示的なサブセットの概略図である。 例示的なイントラ予測方向の図である。 一例におけるカレントブロックおよびその周囲の空間マージ候補の概略図である。 一実施形態による通信システム(300)の簡略化されたブロック図の概略図である。 一実施形態による通信システム(400)の簡略化されたブロック図の概略図である。 一実施形態によるデコーダの簡略化されたブロック図の概略図である。 一実施形態によるエンコーダの簡略化されたブロック図の概略図である。 別の実施形態によるエンコーダのブロック図を示している。 別の実施形態によるデコーダのブロック図を示している。 本開示の実施形態によるクロマサブサンプリング形式の例を示している。 本開示の実施形態による対応するルマおよびクロマサンプルの名目上の垂直および水平相対位置を示している。 本開示の実施形態による対応するルマおよびクロマサンプルの名目上の垂直および水平相対位置を示している。 本開示の実施形態による対応するルマおよびクロマサンプルの名目上の垂直および水平相対位置を示している。 本開示の一実施形態によるCTU(1101)に分割されたピクチャ(1100)の一例を示している。 本開示の一実施形態によるピクチャ(1200)のラスタ走査スライス分割の一例を示している。 本開示の一実施形態によるピクチャ(1300)の矩形スライス分割の一例を示している。 本開示の一実施形態によるタイル、ブリック(1401)~(1411)、および矩形スライス(1421)~(1424)に分割されたピクチャ(1400)の一例を示している。 いくつかの例におけるピクチャの分割の例を示している。 本開示の実施形態によるマルチタイプツリー(MTT)構造における例示的な分割タイプ(1621)~(1624)を示している。 本開示の一実施形態による入れ子状MTTコーディングツリー構造を有する四分木(QT)における分割フラグシグナリングの例を示している。 本開示の実施形態によるMTT分割モードの例を示している。 本開示の一実施形態による入れ子状MTTコーディングブロック構造を有するQTの例を示している。 本開示のいくつかの実施形態によるプロセスの概要を示すフローチャートを示している。 本開示のいくつかの実施形態による別のプロセスの概要を示すフローチャートを示している。 一実施形態によるコンピュータシステムの概略図である。
図3が、本開示の一実施形態による通信システム(300)の概略のブロック図を示している。通信システム(300)は、例えば、ネットワーク(350)を介して互いに通信することができる複数の端末デバイスを含む。例えば、通信システム(300)は、ネットワーク(350)を介して相互接続された端末デバイス(310)および(320)からなる第1のペアを含む。図3の例において、端末デバイス(310)および(320)の第1のペアは、データの単方向送信を実行する。例えば、端末デバイス(310)は、ネットワーク(350)を介して他の端末デバイス(320)に送信するためのビデオデータ(例えば、端末デバイス(310)によって取り込まれたビデオピクチャのストリーム)をコーディングすることができる。符号化ビデオデータを、1つまたは複数のコーディングされたビデオビットストリームの形式で送信することができる。端末デバイス(320)は、コーディングされたビデオデータをネットワーク(350)から受信し、コーディングされたビデオデータを復号してビデオピクチャを復元し、復元されたビデオデータに従ってビデオピクチャを表示することができる。単方向データ送信は、メディア提供用途などにおいて一般的であり得る。
別の例では、通信システム(300)は、例えばビデオ会議中に発生する可能性があるコーディングされたビデオデータの双方向送信を実行する端末デバイス(330)および(340)からなる第2のペアを含む。データの双方向送信の場合、一例では、端末デバイス(330)および(340)の各々の端末デバイスは、端末デバイス(330)および(340)のうちの他方の端末デバイスへとネットワーク(350)を介して送信するためにビデオデータ(例えば、端末デバイスによって取り込まれたビデオピクチャのストリーム)をコーディングすることができる。さらに、端末デバイス(330)および(340)の各々の端末デバイスは、端末デバイス(330)および(340)のうちの他方の端末デバイスによって送信されたコーディングされたビデオデータを受信することができ、コーディングされたビデオデータを復号してビデオピクチャを復元することができ、復元されたビデオデータに従ってアクセス可能な表示デバイスにおいてビデオピクチャを表示することができる。
図3の例では、端末デバイス(310)、(320)、(330)、および(340)は、サーバ、パーソナルコンピュータ、およびスマートフォンとして示される場合があるが、本開示の原理はそのように限定されなくてもよい。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、および/または専用ビデオ会議機器を用いる用途を見出す。ネットワーク(350)は、例えば、電線(有線)および/またはワイヤレスの通信ネットワークを含む端末デバイス(310)、(320)、(330)、および(340)の間でコーディングされたビデオデータを伝達する任意の数のネットワークを表す。通信ネットワーク(350)は、回線交換チャネルおよび/またはパケット交換チャネルでデータを交換することができる。代表的なネットワークには、電気通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、および/またはインターネットが含まれる。本説明の目的のために、ネットワーク(350)のアーキテクチャおよびトポロジーは、本明細書で以下に説明されない限り、本開示の動作にとって重要でない可能性がある。
図4が、開示される主題の用途の一例として、ストリーミング環境におけるビデオエンコーダおよびビデオデコーダの配置を示している。開示される主題は、例えば、ビデオ会議、デジタルTV、CD、DVD、メモリスティック、などを含むデジタル媒体への圧縮ビデオの格納、などを含む他のビデオ対応の用途に等しく適用可能であり得る。
ストリーミングシステムは、例えば、圧縮されていないビデオピクチャのストリーム(402)を作成するビデオソース(401)、例えばデジタルカメラを含むことができるキャプチャサブシステム(413)を含んでよい。一例では、ビデオピクチャのストリーム(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)(例えば、受信回路)を含むことができる。ビデオデコーダ(510)を、図4の例のビデオデコーダ(410)の代わりに使用することができる。
受信器(531)は、ビデオデコーダ(510)によって復号される1つまたは複数のコーディングされたビデオシーケンスを受信することができ、同じ実施形態または別の実施形態において、一度に1つのコーディングされたビデオシーケンスを受信することができ、各々のコーディングされたビデオシーケンスのデコーディングは、他のコーディングされたビデオシーケンスから独立である。コーディングされたビデオシーケンスは、符号化ビデオデータを格納するストレージデバイスへのハードウェア/ソフトウェアリンクであってよいチャネル(501)から受信されてよい。受信器(531)は、符号化ビデオデータを、それぞれの使用エンティティ(図示せず)へと転送されてよい他のデータ、例えばコーディングされたオーディオデータおよび/または補助データストリームと一緒に受信することができる。受信器(531)は、コーディングされたビデオシーケンスを他のデータから分離することができる。ネットワークジッタに対抗するために、バッファメモリ(515)を、受信器(531)とエントロピーデコーダ/パーサー(520)(以下では、「パーサー(520)」)との間に結合させることができる。特定の用途において、バッファメモリ(515)は、ビデオデコーダ(510)の一部である。他の用途においては、ビデオデコーダ(510)の外部にあってよい(図示せず)。さらに他の用途において、例えば、ネットワークジッタに対抗するために、ビデオデコーダ(510)の外部にバッファメモリ(図示せず)があってよく、加えて、例えば、プレイアウトタイミングを処理するために、ビデオデコーダ(510)の内部に別のバッファメモリ(515)があってよい。受信器(531)が、充分な帯域幅および制御可能性の格納/転送デバイス、あるいはアイソシンクロナス(isosynchronous)ネットワークからデータを受信しているとき、バッファメモリ(515)は不要かもしれず、あるいは小さくてよい。インターネットなどのベストエフォートパケットネットワークにおける使用の場合、バッファメモリ(515)は、必要であるかもしれず、比較的大きくてよく、好都合には適応的なサイズであってよく、オペレーティングシステムまたはビデオデコーダ(510)の外部の同様の要素(図示せず)に少なくとも部分的に実装されてよい。
ビデオデコーダ(510)は、コーディングされたビデオシーケンスからシンボル(521)を復元するためにパーサー(520)を含み得る。これらのシンボルのカテゴリとして、ビデオデコーダ(510)の動作を管理するために使用される情報が挙げられ、潜在的には、図5に示したように、電子デバイス(530)の一体の一部分ではないが電子デバイス(530)に結合することができるレンダーデバイス(512)(例えば、表示画面)などのレンダリングデバイスを制御するための情報が挙げられる。レンダリングデバイスのための制御情報は、補足拡張情報(SEIメッセージ)またはビデオユーザビリティ情報(VUI)のパラメータセットフラグメント(図示せず)の形式であってよい。パーサー(520)は、受け取ったコーディングされたビデオシーケンスを構文解析/エントロピーデコーディングすることができる。コーディングされたビデオシーケンスのコーディングは、ビデオコーディング技術または規格に従うことができ、文脈感度の有無にかかわらず、可変長コーディング、ハフマンコーディング、算術コーディング、などを含むさまざまな原理に従うことができる。パーサー(520)は、グループに対応する少なくとも1つのパラメータに基づいて、コーディングされたビデオシーケンスから、ビデオデコーダ内のピクセルのサブグループのうちの少なくとも1つのための一組のサブグループパラメータを抽出することができる。サブグループは、ピクチャグループ(GOP)、ピクチャ、タイル、スライス、マクロブロック、コーディングユニット(CU)、ブロック、変換ユニット(TU)、予測ユニット(PU)、などを含むことができる。さらに、パーサー(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)が予測サンプルをフェッチする参照ピクチャメモリ(557)内のアドレスを、例えば、X、Y、および参照ピクチャ成分を有することができるシンボル(521)の形式で動き補償予測ユニット(553)に利用可能な動きベクトルによって制御することができる。さらに、動き補償は、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリ(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)(例えば、送信回路)を含む。ビデオエンコーダ(603)を、図4の例のビデオエンコーダ(403)の代わりに使用することができる。
ビデオエンコーダ(603)は、ビデオエンコーダ(603)によってコーディングされるビデオ画像を取り込むことができる(図6の例では電子デバイス(620)の一部ではない)ビデオソース(601)からビデオサンプルを受信することができる。別の例では、ビデオソース(601)は、電子デバイス(620)の一部である。
ビデオソース(601)は、任意の適切なビット深度(例えば、8ビット、10ビット、12ビット、…)、任意の色空間(例えば、BT.601 Y CrCB、RGB、…)、および任意の適切なサンプリング構造(例えば、Y CrCb 4:2:0、Y CrCb 4:4:4)であり得るデジタルビデオサンプルストリームの形式で、ビデオエンコーダ(603)によってコーディングされるソースビデオシーケンスを提供することができる。メディア提供システムにおいて、ビデオソース(601)は、前もって準備されたビデオを格納するストレージデバイスであってよい。ビデオ会議システムでは、ビデオソース(601)は、ビデオシーケンスとしてローカル画像情報を取り込むカメラであってよい。ビデオデータは、順番に見られたときに動きを伝える複数の個々のピクチャとして提供され得る。ピクチャ自体は、ピクセルの空間配列として編成されてよく、各ピクセルは、使用中のサンプリング構造、色空間、などに応じて、1つまたは複数のサンプルを含むことができる。当業者であれば、ピクセルとサンプルとの間の関係を容易に理解することができる。以下の説明はサンプルに焦点を当てる。
一実施形態によれば、ビデオエンコーダ(603)は、リアルタイムで、または用途によって必要とされる任意の他の時間制約の下で、ソースビデオシーケンスのピクチャをコーディングされたビデオシーケンス(643)にコーディングおよび圧縮することができる。適切なコーディング速度を強制することが、コントローラ(650)の1つの機能である。いくつかの実施形態では、コントローラ(650)は、以下に記載される他の機能ユニットを制御し、他の機能ユニットに機能的に結合している。分かりやすくするために、結合は描写されていない。コントローラ(650)によって設定されるパラメータは、レート制御関連パラメータ(ピクチャスキップ、量子化器、レート歪み最適化技法のラムダ値、…)、ピクチャサイズ、ピクチャグループ(GOP)レイアウト、最大動きベクトル検索範囲、などを含むことができる。コントローラ(650)は、特定のシステム設計のために最適化されたビデオエンコーダ(603)に関連する他の適切な機能を有するように構成され得る。
いくつかの実施形態では、ビデオエンコーダ(603)は、コーディングループで動作するように構成される。過度に簡略化された説明として、一例では、コーディングループは、ソースコーダ(630)(例えば、コーディングされるべき入力ピクチャと、(1つまたは複数の)参照ピクチャとに基づいて、シンボルストリームなどのシンボルを作成する役割を担う)と、ビデオエンコーダ(603)に組み込まれた(ローカル)デコーダ(633)とを含むことができる。デコーダ(633)は、(シンボルとコーディングされたビデオビットストリームとの間のいかなる圧縮も、開示される主題で考慮されるビデオ圧縮技術において可逆であるため)(リモート)デコーダも作成するのと同様の方式で、シンボルを復元してサンプルデータを作成する。復元されたサンプルストリーム(サンプルデータ)は、参照ピクチャメモリ(634)に入力される。シンボルストリームのデコーディングは、デコーダの位置(ローカルまたはリモート)に関係なくビットパーフェクト(bit-exact)な結果をもたらすため、参照ピクチャメモリ(634)の内容も、ローカルエンコーダとリモートエンコーダとの間でビットパーフェクトである。言い換えれば、エンコーダの予測部分は、デコーディング中に予測を使用するときにデコーダが「見る」のと全く同じサンプル値を参照ピクチャサンプルとして「見る」。参照ピクチャの同期性(および、例えば、チャネル誤差のために同期性が維持できない場合に結果として生じるドリフト)のこの基本原理は、いくつかの関連技術でも使用される。
「ローカル」デコーダ(633)の動作は、図5と共に上記で詳細に既に説明されたビデオデコーダ(510)などの「リモート」デコーダの動作と同じであり得る。しかしながら、図5も簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ(645)およびパーサー(520)によるコーディングされたビデオシーケンスへのシンボルのエンコーディング/デコーディングが可逆であり得るため、バッファメモリ(515)を含むビデオデコーダ(510)のエントロピーデコーディング部分、およびパーサー(520)は、ローカルデコーダ(633)に完全には実装されない可能性がある。
この時点でなされ得る観測は、デコーダに存在する構文解析/エントロピーデコーディングを除く任意のデコーダ技術が、対応するエンコーダ内にも実質的に同一の機能形態で存在する必要があるということである。このため、開示される主題は、デコーダの動作に焦点を当てる。エンコーダ技術の説明は、包括的に記載されたデコーダ技術の逆であるため、省略することができる。特定の領域においてのみ、より詳細な説明が必要とされ、以下に提供される。
動作中、いくつかの例では、ソースコーダ(630)は、「参照ピクチャ」として指定されたビデオシーケンスからの1つまたは複数の以前にコーディングされたピクチャを参照して入力ピクチャを予測的にコーディングする動き補償予測コーディングを実行することができる。このようにして、コーディングエンジン(632)は、入力ピクチャのピクセルブロックと、入力ピクチャへの予測参照として選択され得る参照ピクチャのピクセルブロックとの間の差をコーディングする。
ローカルビデオデコーダ(633)は、ソースコーダ(630)によって作成されたシンボルに基づいて、参照ピクチャとして指定され得るピクチャのコーディングされたビデオデータを復号することができる。コーディングエンジン(632)の動作は、好都合には、非可逆プロセスであってよい。コーディングされたビデオデータが(図6には示されていない)ビデオデコーダで復号され得るとき、復元されたビデオシーケンスは、典型的には、いくつかの誤差を伴うソースビデオシーケンスの複製であり得る。ローカルビデオデコーダ(633)は、参照ピクチャについてビデオデコーダによって実行され得るデコーディングプロセスを複製し、復元された参照ピクチャの参照ピクチャキャッシュ(634)への格納を生じさせることができる。このようにして、ビデオエンコーダ(603)は、(送信エラーがない)遠端ビデオデコーダによって取得される復元された参照ピクチャとして共通のコンテンツを有する復元された参照ピクチャのコピーをローカルに格納することができる。
予測器(635)は、コーディングエンジン(632)の予測検索を実行することができる。すなわち、コーディングされる新しいピクチャに関し、予測器(635)は、新しいピクチャのための適切な予測参照として役立つことができる(候補参照ピクセルブロックとしての)サンプルデータあるいは参照ピクチャ動きベクトル、ブロック形状、などの特定のメタデータを求めて、参照ピクチャメモリ(634)を検索することができる。予測器(635)は、適切な予測参照を見つけるために、ピクセルブロックごとにサンプルブロックに対して動作することができる。場合によっては、予測器(635)によって取得された検索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ(634)に格納された複数の参照ピクチャから引き出された予測参照を有することができる。
コントローラ(650)は、例えば、ビデオデータを復号するために使用されるパラメータおよびサブグループパラメータの設定を含むソースコーダ(630)のコーディング動作を管理することができる。
すべての前述の機能ユニットの出力は、エントロピーコーダ(645)においてエントロピーコーディングの対象とされ得る。エントロピーコーダ(645)は、ハフマンコーディング、可変長コーディング、算術コーディング、などの技術に従ってシンボルを可逆圧縮することにより、さまざまな機能ユニットによって生成されたシンボルをコーディングされたビデオシーケンスに変換する。
送信器(640)は、エントロピーコーダ(645)によって作成されたコーディングされたビデオシーケンスをバッファして、符号化ビデオデータを格納するストレージデバイスへのハードウェア/ソフトウェアリンクであってよい通信チャネル(660)を介した送信の準備をすることができる。送信器(640)は、ビデオエンコーダ(603)からのコーディングされたビデオデータを、送信される他のデータ、例えばコーディングされたオーディオデータおよび/または補助データストリーム(ソースは図示されていない)とマージすることができる。
コントローラ(650)は、ビデオエンコーダ(603)の動作を管理することができる。コーディング中に、コントローラ(650)は、各々のコーディングされたピクチャに特定のコーディングされたピクチャタイプを割り当てることができ、それは、それぞれのピクチャに適用され得るコーディング技法に影響を及ぼし得る。例えば、ピクチャは、多くの場合、以下のピクチャタイプのうちの1つとして割り当てられ得る。
イントラピクチャ(Iピクチャ)は、予測のソースとしてシーケンス内のいかなる他のピクチャも使用せずにコーディングおよびデコーディングされ得るピクチャであり得る。いくつかのビデオコーデックは、例えば独立デコーダリフレッシュ(「IDR」)ピクチャなど、さまざまなタイプのイントラピクチャを可能にする。当業者は、Iピクチャのそれらの変形形態、ならびにそれらのそれぞれの用途および特徴を認識している。
予測ピクチャ(Pピクチャ)は、各ブロックのサンプル値を予測するために最大で1つの動きベクトルおよび基準インデックスを使用するイントラ予測またはインター予測を用いてコーディングおよびデコーディングされ得るピクチャであり得る。
双方向予測ピクチャ(Bピクチャ)は、各ブロックのサンプル値を予測するために最大で2つの動きベクトルおよび参照インデックスを使用するイントラ予測またはインター予測を用いてコーディングおよびデコーディングされ得るピクチャであり得る。同様に、複数の予測ピクチャは、単一のブロックの復元のために3つ以上の参照ピクチャおよび関連メタデータを使用し得る。
ソースピクチャは、一般に、複数のサンプルブロック(例えば、それぞれ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)に分割され、ピクチャ内のCTUは、64×64ピクセル、32×32ピクセル、または16×16ピクセルなどの同じサイズを有する。一般に、CTUは、3つのコーディングツリーブロック(CTB)を含み、それらは1つのルマCTBおよび2つのクロマCTBである。各々のCTUは、1つまたは複数のコーディングユニット(CU)に再帰的に四分木分割され得る。例えば、64×64ピクセルのCTUを、1つの64×64ピクセルのCU、または4つの32×32ピクセルのCU、または16個の16×16ピクセルのCUに分割することができる。一例では、各々の各CUが、インター予測タイプまたはイントラ予測タイプなどのCUの予測タイプを決定するために分析される。CUは、時間的および/または空間的な予測可能性に応じて、1つまたは複数の予測ユニット(PU)に分割される。一般に、各々のPUは、1つのルマ予測ブロック(PB)および2つのクロマPBを含む。一実施形態では、コーディング(エンコーディング/デコーディング)における予測動作は、予測ブロック単位で実行される。予測ブロックの例としてルマ予測ブロックを使用すると、予測ブロックは、8×8ピクセル、16×16ピクセル、8×16ピクセル、16×8ピクセル、などのピクセルの値(例えば、ルマ値)の行列を含む。
図7が、本開示の別の実施形態によるビデオエンコーダ(703)の図を示している。ビデオエンコーダ(703)は、ビデオピクチャのシーケンス内のカレントビデオピクチャ内のサンプル値の処理ブロック(例えば、予測ブロック)を受信し、処理ブロックをコーディングされたビデオシーケンスの一部であるコーディングされたピクチャに符号化するように構成される。一例では、ビデオエンコーダ(703)は、図4の例のビデオエンコーダ(403)の代わりに使用される。
HEVCの例では、ビデオエンコーダ(703)は、8×8サンプルの予測ブロックなどの処理ブロック用のサンプル値の行列を受信する。ビデオエンコーダ(703)は、例えばレート歪み最適化を使用して、イントラモード、インターモード、または双予測モードのいずれを使用して処理ブロックが最良にコーディングされるかを決定する。処理ブロックがイントラモードでコーディングされるとき、ビデオエンコーダ(703)は、イントラ予測技法を使用して、処理ブロックをコーディングされたピクチャに符号化することができ、処理ブロックがインターモードまたは双予測モードでコーディングされるとき、ビデオエンコーダ(703)は、インター予測技法または双予測技法をそれぞれ使用して、処理ブロックをコーディングされたピクチャに符号化することができる。特定のビデオコーディング技術では、マージモードは、予測器の外側のコーディングされた動きベクトルコンポーネントの恩恵を受けずに、動きベクトルが1つまたは複数の動きベクトル予測器から導出されるインターピクチャ予測サブモードであり得る。特定の他のビデオコーディング技術では、対象ブロックに適用可能な動きベクトルコンポーネントが存在し得る。一例では、ビデオエンコーダ(703)は、処理ブロックのモードを決定するためにモード決定モジュール(図示せず)などの他のコンポーネントを含む。
図7の例では、ビデオエンコーダ(703)は、図7に示されるように互いに結合したインターエンコーダ(730)、イントラエンコーダ(722)、残差計算器(723)、スイッチ(726)、残差エンコーダ(724)、汎用コントローラ(721)、およびエントロピーエンコーダ(725)を含む。
インターエンコーダ(730)は、カレントブロック(例えば、処理ブロック)のサンプルを受信し、ブロックを参照ピクチャ内の1つまたは複数の参照ブロック(例えば、前のピクチャおよび後のピクチャ内のブロック)と比較し、インター予測情報(例えば、インター符号化技法による冗長情報、動きベクトル、マージモード情報の記述)を生成し、任意の適切な技法を使用して、インター予測情報に基づいてインター予測結果(例えば、予測ブロック)を計算するように構成される。いくつかの例では、参照ピクチャは、符号化ビデオ情報に基づいて復号された復号参照ピクチャである。
イントラエンコーダ(722)は、カレントブロック(例えば、処理ブロック)のサンプルを受信し、場合によっては、ブロックを同じピクチャ内の既にコーディングされたブロックと比較し、変換後に量子化係数を生成し、場合によっては、イントラ予測情報(例えば、1つまたは複数のイントラ符号化技法によるイントラ予測方向情報)も生成するように構成される。一例では、イントラエンコーダ(722)は、同じピクチャ内のイントラ予測情報および参照ブロックに基づいて、イントラ予測結果(例えば、予測ブロック)も計算する。
汎用コントローラ(721)は、汎用制御データを決定し、汎用制御データに基づいてビデオエンコーダ(703)の他のコンポーネントを制御するように構成される。一例では、汎用コントローラ(721)は、ブロックのモードを決定し、モードに基づいてスイッチ(726)に制御信号を提供する。例えば、モードがイントラモードであるとき、汎用コントローラ(721)は、スイッチ(726)を制御して残差計算器(723)による使用のためにイントラモード結果を選択し、エントロピーエンコーダ(725)を制御してイントラ予測情報を選択し、ビットストリームにイントラ予測情報を含め、モードがインターモードであるとき、汎用コントローラ(721)は、スイッチ(726)を制御して残差計算器(723)による使用のためにインター予測結果を選択し、エントロピーエンコーダ(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)を含むために)特定の制御情報を必要とする場合があり、その情報はエントロピーデコーダ(871)によって提供され得る(これは少量の制御情報にすぎない可能性があるため、データ経路は図示されていない)。
復元モジュール(874)は、空間ドメインにおいて、残差デコーダ(873)によって出力された残差と、(状況に応じてインター予測モジュールまたはイントラ予測モジュールによって出力された)予測結果とを組み合わせて、復元されたピクチャの一部であり得る復元されたブロックを形成するように構成され、復元されたピクチャは復元されたビデオの一部であり得る。視覚的品質を改善するために、デブロッキング動作などの他の適切な動作を実行することができることに留意されたい。
ビデオエンコーダ(403)、(603)、および(703)、ならびにビデオデコーダ(410)、(510)、および(810)を、任意の適切な技法を使用して実装できることに留意されたい。一実施形態では、ビデオエンコーダ(403)、(603)、および(703)、ならびにビデオデコーダ(410)、(510)、および(810)を、1つまたは複数の集積回路を使用して実装することができる。別の実施形態では、ビデオエンコーダ(403)、(603)、および(603)、ならびにビデオデコーダ(410)、(510)、および(810)を、ソフトウェア命令を実行する1つまたは複数のプロセッサを使用して実装することができる。
ビットストリームを介して与えられるソースピクチャと復号ピクチャとの間の例示的な関係を、以下で説明する。ビットストリームによって表されるビデオソースは、デコーディング順序でのピクチャのシーケンスであり得る。ソースピクチャおよび復号ピクチャの各々は、(1)ルマ(Y)のみ(モノクロ)、(2)ルマおよび2つのクロマ(例えば、YCbCrまたはYCgCo)、(3)緑、青、および赤(GBR;RGBとしても知られる)、ならびに(4)他の不特定のモノクロまたは三刺激カラーサンプリングを表すアレイ(例えば、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ビットの範囲(8ビットおよび16ビットを含む)内であってよく、ルマ配列で使用されるビット数は、クロマ配列で使用されるビット数とは異なり得る。
図10A~図10Cが、本開示の実施形態によるそれぞれのピクチャ内の対応するルマおよびクロマサンプルの名目上の垂直および水平相対位置を示している。代替のクロマサンプル相対位置がビデオユーザビリティ情報において示されてもよい。
図10Aを参照すると、一例において、クロマフォーマットインデックス(例えば、chroma_format_idc)の値は1に等しく、したがって、クロマフォーマットは4:2:0である。図10Aは、ピクチャ内の対応するルマおよびクロマサンプルの名目上の垂直および水平位置の一例を示している。いくつかの例において、クロマサンプルは、垂直方向においては2つの隣接するルマサンプル位置の間に位置し、水平方向においてはルマサンプル位置に位置する。
図10Bを参照すると、クロマフォーマットインデックスの値は2に等しく、したがって、クロマフォーマットは4:2:2である。いくつかの例において、クロマサンプルは、ピクチャ内の対応するルマサンプルと同じ位置にある(または、同じ場所に配置される)。図10Bは、ピクチャ内の対応するルマおよびクロマサンプルの名目上の垂直および水平位置の一例を示している。
図10Cを参照すると、クロマフォーマットインデックスの値が3に等しいとき、すべての配列サンプル(例えば、ルマ配列サンプルおよび2つのクロマ配列サンプル)は、同じ位置にあってよい(または、同じ場所に配置され得る)。図10Cは、ピクチャ内の対応するルマおよびクロマサンプルの名目上の垂直および水平位置の一例を示している。
VVCなどにおける分割の例が、以下で説明される。一実施形態において、ピクチャをCTUに分割することができる。ピクチャを、CTUのシーケンスに分割することができる。3つのサンプル配列を有するピクチャの場合、CTUは、ルマサンプルのN×Nのブロック(例えば、ルマブロック)を、クロマサンプルの2つの対応するブロック(例えば、2つのクロマブロック)と一緒に含むことができる。図11が、本開示の一実施形態によるCTU(1101)に分割されたピクチャ(1100)の一例を示している。一例において、CTU内のルマブロックの最大許容サイズは、128×128に指定される。一例において、ルマ変換ブロックの最大サイズは、64×64である。
ピクチャを、スライス、タイル、および/またはブリックに分割することができる。ピクチャを、1つまたは複数のタイル行および1つまたは複数のタイル列に分割することができる。タイルは、ピクチャの矩形領域をカバーするCTUのシーケンスであり得る。タイルを、各々がタイル内のいくつかのCTU行を含むことができる1つまたは複数のブリックに分割することができる。複数のブリックに分割されていないタイルを、ブリックと呼ぶこともできる。しかしながら、タイルの真のサブセットであるブロックは、タイルとは呼ばれない。
スライスは、ピクチャ内のいくつかのタイルまたはタイル内のいくつかのブリックを含むことができる。例えばラスタ走査スライスモードおよび矩形スライスモードなど、スライスの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)、および矩形スライス(1421)~(1424)に分割されたピクチャ(1400)の一例を示している。ピクチャ(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)を含む。
図15が、タイルに分割されたピクチャ(1500)の例を示している。図15の例において、ピクチャ(1500)は、18個のタイル(1501)~(1518)に分割されている。左側の12個のタイル(1501)~(1512)の各々は、4×4のCTUからなるスライスをカバーし、右側の6個のタイル(1513)~(1518)の各々は、垂直に積み重ねられた2×2のCTUからなる2つのスライスをカバーし、全体として、ピクチャ(1500)は24個のスライスに分割され、各々のスライスはサブピクチャである。24個のサブピクチャは、さまざまな寸法である。
CTUを、ツリー構造を使用して分割することができる。HEVCなどにおける一実施形態において、CTUは、種々のローカル特性に適応するためにコーディングツリーと称される四分木またはQT構造を使用することによってCUに分割され得る。インターピクチャ(または、時間的)予測またはイントラピクチャ(空間的)予測のどちらを使用してピクチャ領域をコーディングするかの決定は、リーフCUレベルで行われ得る。各々のリーフCUを、PU分割タイプに応じて、1つ、2つ、または4つのPUにさらに分割できる。PUの内部で、同じ予測プロセスが適用可能であり、関連情報がPUベースでデコーダに送信され得る。PU分割タイプに基づく予測プロセスを適用することによって残差ブロックを取得した後に、リーフCUを、CUのコーディングツリーと同様のQT構造に従って変換ユニット(TU)に分割することができる。HEVC構造などにおける一例において、CU、PU、およびTUなどの複数の分割ユニットは異なり得る。
VVCなどにおける一実施形態において、2値および3値分割セグメント化構造を使用する入れ子状のマルチタイプツリーを有する四分木は、複数のパーティションユニットタイプの概念を置き換えることができ、したがって、CU、PU、およびTUの概念の分離を除去することができ、CU分割形状のより高い柔軟性をサポートすることができる。いくつかの例において、CUが最大変換長に対して大きすぎるサイズを有する場合、異なるサイズがCU、PU、および/またはTUに使用され得る。コーディングツリー構造において、CUは、正方形または矩形のいずれかの形状を有することができる。CTUを、最初にQT構造によって分割することができる。次いで、QTリーフノードを、マルチタイプツリー(MTT)構造によってさらに分割することができる。
図16が、本開示の実施形態によるMTT構造における例示的な分割タイプ(1621)~(1624)を示している。分割タイプ(1621)~(1624)は、垂直二分割(SPLIT_BT_VER)(1621)、水平二分割(SPLIT_BT_HOR)(1622)、垂直三分割(SPLIT_TT_VER)(1623)、および水平三分割(SPLIT_TT_HOR)(1624)を含むことができる。MTTリーフノードをCUと呼ぶことができ、CUが最大変換長に対して大きすぎない限り、セグメント化(または、CU)を、さらなる分割を必要とすることなく予測および変換処理に使用することができる。このように、ほとんどの場合、CU、PU、およびTUが、入れ子状のMTTコーディングブロック構造を有するQTにおいて同じブロックサイズを有することができる。1つの例外が、サポートされる最大変換長がCUの色成分の幅または高さよりも小さい場合に生じる。
図17が、本開示の一実施形態による入れ子状MTTコーディングツリー構造を有するQTのための分割フラグシグナリングの例を示している。図17は、入れ子状MTTコーディングツリー構造を有するQTにおけるパーティション分割情報の例示的なシグナリング機構を示している。CTUなどのノード(1711)を、QTのルートとして扱うことができ、QT分割フラグ(例えば、qt_split_flag)が真(例えば、値「1」)である場合、QTノード(1721)を生成するために、QT構造によってQTノードに最初に分割することができる。QT分割フラグ(例えば、qt_split_flag)が偽(例えば、値「0」)である場合、ノード(1711)は、QT分割を用いて分割されることがなく、したがってQTリーフノード(1711)と呼ばれ得る。各々のQTリーフノード(それを可能にするために充分に大きい場合)は、MTT構造によってさらに分割可能であり、MTTノードと呼ばれ得る。図17を参照すると、QTリーフノードまたはMTTノード(1711)は、MTT分割を使用してさらに分割され得る。
MTT構造において、ノード(1711)がさらに分割されるかどうかを示すために、第1のフラグ(例えば、mtt_split_cu_flag)をシグナリングすることができる。ノード(1711)が分割されない(例えば、mtt_split_cu_flagが「0」である)場合、ノード(1711)は、MTTリーフノード(1711)と呼ばれる。ノード(1711)がさらに分割される(例えば、mtt_split_cu_flagが「1」である)場合、分割方向(水平分割または垂直分割)を示すために第2のフラグ(例えば、mtt_split_cu_vertical_flag)をシグナリングすることができ、次いで、分割が二分割であるか、あるいは三分割であるかを示すために第3のフラグ(例えば、mtt_split_cu_binary_flag)をシグナリングすることができる。したがって、MTTノード(1751)は、ノード(1711)の垂直二分割(例えば、BT_VER_split)に基づいて生成され、MTTノード(1752)は、ノード(1711)の垂直三分割(例えば、TT_VER_split)に基づいて生成され、MTTノード(1753)は、ノード(1711)の水平二分割(例えば、BT_HOR_split)に基づいて生成され、MTTノード(1754)は、ノード(1711)の水平三分割(例えば、TT_HOR_split)に基づいて生成される。
図18を参照すると、第2のフラグ(例えば、mtt_split_cu_vertical_flag)および第3のフラグ(例えば、mtt_split_cu_binary_flag)の値に基づいて、表2に示されるようにCUのMTT分割モード(例えば、MttSplitMode)を導出することができる。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)を含むことができる。
図19が、本開示の一実施形態による入れ子状MTTコーディングブロック構造を有するQTの例を示している。CTU(1900)を、QTおよび入れ子状MTTコーディングブロック構造を有する複数のCUに分割することができ、ブロックの太線の辺はQT分割を表し、残りの辺はMTT分割を表す。入れ子状MTTパーティションを有するQTは、CUを含むコンテンツ適応型コーディングツリー構造を提供することができる。CUのサイズは、任意の適切なサイズであり得る。CUのサイズは、CTU(1900)と同じ大きさ、またはルマサンプルの単位で4×4と同じ小ささであり得る。一例において、4:2:0のクロマフォーマットの場合、最大クロマCBサイズは64×64であってよく、最小クロマCBサイズは2×2であってよい。
VVCなどの一例において、サポートされる最大ルマ変換サイズは64×64であり、サポートされる最大クロマ変換サイズは32×32である。CBの幅または高さが最大変換幅または高さよりも大きい場合、CBは、水平方向および/または垂直方向において、その方向の変換サイズの制限を満たすように自動的に分割され得る。
以下のパラメータが、入れ子状MTTコーディングツリー方式でQTのシーケンスパラメータセット(SPS)シンタックス要素によって定義および指定され得る。以下のパラメータは、(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)において、コーディングツリー方式(分離ツリー構造方式と呼ばれる)は、ルマ成分(例えば、ルマCTB)および対応するクロマ成分(複数可)(クロマCTB)が別個のブロックツリー構造(コーディングツリー構造、ツリー構造、コーディングツリー、またはツリーとも呼ばれる)を有する能力をサポートする。一例において、PおよびBスライスに関して、CTU内のルマおよびクロマCTBは、同じコーディングツリー構造(例えば、シングルコーディングツリー)を共有する。Iスライスに関して、CTU内のルマおよびクロマCTBは、別個のブロックツリー構造(例えば、デュアルツリー)を有することができ、別個のブロックツリー構造を使用するCTUの分割事例は、デュアルツリー分割と呼ばれる。分離ブロックツリーモード(または、デュアルツリー)が適用される場合、ルマCTBは、コーディングツリー構造(ルマコーディングツリー構造)によってCUに分割され、クロマCTBは、別のコーディングツリー構造(クロマコーディングツリー構造)によってクロマCUに分割される。このようにして、Iスライス内のCUは、ルマ成分のコーディングブロック(一例においてルマCUとも呼ばれる)または2つのクロマ成分のコーディングブロック(クロマCUとも呼ばれる)を含むことができ、PまたはBスライス内のCUは常に、ビデオがモノクロでない限り、3つの色成分すべてのコーディングブロックからなる。
本開示の一態様によれば、ハードウェアビデオエンコーダおよびデコーダの実装態様において、ピクチャが比較的小さいイントラブロックを有する場合、隣接するイントラブロック間のサンプル処理データ依存性ゆえに、処理スループットが低下する。イントラブロックの予測器生成は、隣接ブロックからの上部および左側の境界再現サンプルを必要とする。したがって、イントラ予測は、一般に、ブロック単位で順次処理される。
いくつかの例(例えば、HEVC)において、最小イントラCUは、8×8のルマサンプルに制限される。最小イントラCUのルマ成分を、4つの4×4のルマイントラ予測ユニット(PU)にさらに分割することができるが、最小イントラCUのクロマ成分は、さらに分割することができない。したがって、最悪の場合のハードウェア処理スループットは、4×4のクロマイントラブロックまたは4×4のルマイントラブロックが処理されるときに発生する。いくつかの他の例(例えば、VVC)において、最悪の場合のスループットを改善するために、16個のクロマサンプルよりも小さいクロマイントラCB(サイズ2x2、4x2、および2x4)および4個のクロマサンプルよりも幅が小さいクロマイントラCB(サイズ2xN)は、クロマイントラCBの分割を制約することによって許可されない。
いくつかの例において、シングルコーディングツリーに関して、最小クロマイントラ予測ユニット(SCIPU)は、クロマブロックサイズが16個のクロマサンプル以上であり、64個のルマサンプルより小さい少なくとも1つの子ルマブロックを有するコーディングツリーノード、あるいはクロマブロックサイズが2×Nではなく、少なくとも1つの子ルマブロック4×N個のルマサンプルを有するコーディングツリーノードとして定義される。いくつかの例において、各々のSCIPUにおいて、すべてのCBがインター予測に基づいてコーディングされ、あるいはすべてのCBが非インター予測、すなわちイントラ予測またはイントラブロックコピー(IBC)のいずれかに基づいてコーディングされることが要求される。すべてのCBがインター予測に基づいてコーディングされたSCIPUは、インターSCIPUと呼ばれ、すべてのCBが非インター予測に基づいてコーディングされたSCIPUは、非インターSCIPUと呼ばれる。非インターSCIPUの場合、非インターSCIPUのクロマはそれ以上分割されず、SCIPUのルマはさらに分割されることが可能であることがさらに必要である。このようにして、サイズがクロマサンプル16個未満またはサイズが2xNの小さいクロマイントラCBが除去される(禁止される)。加えて、非インターSCIPUの場合、クロマスケーリングは適用されない。いくつかの例において、追加のシンタックスはシグナリングされず、SCIPUが非インターであるかどうかは、SCIPU内の第1のルマCBの予測モードによって導出され得る。SCIPUのタイプは、カレントスライスがIスライスであり、あるいはカレントSCIPUが1回のさらなる分割後に4x4ルマ分割をその中に有する場合(VVCではインター4x4が許されないため)、非インターであると推論され、そうでない場合、SCIPUのタイプ(インターまたは非インター)は、SCIPU内のCUを解析する前に1つのフラグによって示される。
いくつかの例において、イントラ予測ピクチャ内の分離ツリー構造に関して、4xNおよび8xNのクロマパーティションの垂直二分割および垂直三分割をそれぞれ無効にすることによって、2xNのイントラクロマブロックが除去される。サイズが2x2、4x2、および2x4の小さいクロマブロックも、分割制限によって除去される(許可されない)。
いくつかの例においては、さらに、ピクチャの幅および高さがmax(8、MinCbSizeY)の倍数になることを考慮することによって、ピクチャの角における2x2/2x4/4x2/2xNのイントラクロマブロックを回避するために、ピクチャサイズの制限が考慮される。
いくつかの例(例えば、VVC)において、タイルベースの並列コーディング、波面ベースの並列コーディング、などの並列コーディング方法がサポートされる。タイルベースの並列コーディングにおいて、ピクチャをいくつかの矩形領域(タイル)に分割でき、したがって矩形領域を並列に符号化または復号することができる。波面ベースの並列コーディングは、CTU行ベースの並列コーディング方法である。
並列コーディング方法を可能にするために、いくつかの例においては、バイトアライメントとCABAC同期の両方が必要である。例えば(例えば、VVCにおいて)、シンタックス要素sps_entropy_coding_sync_enabled_flagが、バイトアライメントおよびCABAC同期が使用されるかどうかを示すために使用される。
一般に、ルマCTBおよびクロマCTBは、インターリーブ方式でビットストリームにコーディングされ、すなわちルマCTUがコーディングされ、続いてクロマCTUがコーディングされる。一例において、ルマCTBおよびクロマCTBは、第1のCTUのルマCTB、第1のCTUのクロマCTB、第2のCTUのルマCTB、第2のCTUのクロマCTB、などのシーケンスでビットストリームにコーディングされ得る。
いくつかの例において、VVCイントラフレーム内の分離ツリー構造のルマCTBおよびクロマCTBは、インターリーブ方式でコーディングされる。そのようなインターリーブ方式は、ルマCTBとクロマCTBとの間に依存性が存在しない場合でもルマCTBおよびクロマCTBを順次に処理しなければならないため、いくつかの例において並列エンコーディングおよびデコーディングに関して効率的でない。これは、インターリーブによるシグナリングゆえにルマおよびクロマを並列に解析することができず、8Kビデオのような高解像度に関してスループットの性能が低下するため、デコーダ側においてさらに問題である。
いくつかの例において、VVCにおける分離ツリー構造方式は、ルマおよびクロマCTBのサイズがルマピクセルの単位において同じサイズを共有することを必要とし、これは、クロマコーディングに関してあまり効率的でない。
いくつかの例において、VVCにおける分離ツリー構造方式は、イントラフレームでのみ利用可能であり、これは、きわめて複雑な方式のSCIPUをもたらす。
本開示の態様は、非インターリーブ方式でルマCTBおよびクロマCTBをコーディングするための技法を提供する。いくつかの実施形態において、分離ツリー構造に関して、ピクチャレベル、スライスレベル、またはタイルレベルなどの特定のレベルにおいて、すべてのルマCTBがクロマCTBの前にシグナリングされ、これは、VVCにおけるインターリーブ方式とは異なる。一例において、分離ツリー構造に関して、ピクチャ内のすべてのルマCTBは、ピクチャ内のクロマCTBの前に(ビットストリーム内で)シグナリングされる。別の例において、分離ツリー構造に関して、スライス内のすべてのルマCTBは、スライス内のクロマCTBの前に(ビットストリーム内で)シグナリングされる。別の例において、分離ツリー構造に関して、タイル内のすべてのルマCTBは、タイル内のクロマCTBの前に(ビットストリーム内で)シグナリングされる。非インターリーブ方式は、ルマCTBおよびクロマCTBの並列処理を容易にすることができる。いくつかの例においては、分離ツリー構造がイントラ予測に適用され、ルマCTBおよびクロマCTBのための非インターリーブ方式を使用することができる。いくつかの他の例において、分離ツリー命令は、非イントラピクチャ、非イントラスライス、非イントラタイル、などの非イントラ予測で使用され、ルマCTBおよびクロマCTBの非インターリーブ方式を使用することができる。
一実施形態において、同じスライス/タイルのルマCTBおよびクロマCTBは、同じネットワーク抽象化レイヤユニット(NALU)でシグナリングされる。バイトアライメントが、NALU内のすべてのルマCTBのシグナリングの後かつクロマCTBの前に挿入される。いくつかの例において、ルマCTBとクロマCTBとの間のコンテキスト適応型バイナリ算術符号化(CABAC)同期が使用されるかどうかを、sps_entropy_coding_sync_enabled_flagなどのフラグに基づいて判定することができる。例えば、フラグsps_entropy_coding_sync_enabled_flagが真である場合、いくつかの例では、スライス/タイルまたはフレームのCABACルマエンジンおよびクロマエンジンについて同期を実行することができる。
別の実施形態において、ルマCTBおよびクロマCTBは、デコーダにおける並列解析が可能であるように、異なるNALUに入れられてもよい。例えば、1つまたは複数のタイルのルマCTBが第1のNALUに含まれ、1つまたは複数のタイルのクロマCTBが第2のNALUに含まれる。デコーダは、第1のNALUおよび第2のNALUをそれぞれ解析することができる2つ以上の処理コアを含むことができる。
別の実施形態において、ルマCTBのサイズおよびクロマCTBのサイズは、ルマサンプルの単位において異なり得る。VVCなどのいくつかの関連の例において、ルマCTBが128×128のルマサンプルのサイズを有する場合、対応するクロマCTBは、色フォーマット4:4:4についてはルマサンプルにおける同じサイズ、すなわち128×128のクロマサンプル、および色フォーマット4:2:0については64×64のクロマサンプルでなければならない。本開示の一実施形態においては、たとえルマCTBが128×128のルマサンプルのサイズを有する場合でも、対応するクロマCTBは、色フォーマット4:2:0について128×128のクロマサンプルであり得る。一例においては、256×256のルマサンプルの領域について、非インターリーブ技法が使用される場合、ルマ部分を、4つの128×128のCTBを使用してコーディングすることができ、クロマ部分を、色フォーマット4:2:0について1つの128×128(クロマサンプル)のCTBを使用してコーディングすることができる。64x64のクロマサンプルの代わりにCTB 128x128のクロマサンプルを使用してクロマ部分をコーディングすることで、コーディング効率が向上する。
別の実施形態において、CCLMモードなどのクロスコンポーネント予測では、とりわけ追加のフィルタリングが予測と共に使用される場合、異なるルマCTBからのルマ予測を使用してクロマブロックを予測することができる。いくつかの関連の例において、CCLMモードにおけるクロマブロックの予測のために異なるルマCTBからのルマ予測を使用することは、許可されない。本開示によれば、非インターリーブ分離ツリーを使用して、CCLMモードにおけるクロマブロックの予測を、異なるルマCTBからのルマ予測を使用して実行することができる。
別の実施形態において、クロマCUまたはクロマTUのQPは、直接シグナリングされても、同位置のルマブロックのQPから導出されてもよい。いくつかの例において、クロマCUまたはクロマTUの領域は、複数のルマCUまたはルマTUに対応することができる。ルマCUからクロマQPを導出するとき、クロマCUまたはクロマTUが複数のルマCUまたはTUに対応する場合、平均QP、中央値QP、あるいは(コーディング順序における)第1の同位置のルマブロックのQPまたは同位置の中央に位置するルマブロックのQPなどの特別な順序または位置のルマQPを、クロマQPまたはクロマQPの予測として使用することができる。
別の実施形態(例えば、限定されたキャッシュハードウェア実装態様)においては、CTBレベルの復元/復号されたピクセルのキャッシュへの不必要に頻繁なロードを回避するために、ルマおよびクロマチャネルのルマサンプル内の同じCTBサイズが制約される。例えば、ルマ処理チャネルおよびクロマ処理チャネルが、ルマサンプル内の同じCTBサイズを処理するように制約される。いくつかの例において、クロマCTB nの符号化/復号は、ルマCTB nの処理が完了するまで開始されず、nは対応するCTBインデックスである。
別の実施形態において、サンプル適応オフセット(SAO)、適応ループフィルタ(ALF)、クロスコンポーネント適応ループフィルタ(CCALF)の制御パラメータなどのCTUレベル制御パラメータは、ルマCTBおよびクロマCTBについて別々にシグナリングされる。いくつかの例において、クロマCTBのいくつかのパラメータは、同位置のルマCTBから導出または予測され得る。一例において、ALFなどのいくつかのフィルタリングツールに関し、同位置のルマCTB/ブロックについてフィルタがオフにされる場合、フィルタは、クロマCTB/ブロックについてオフにされる。別の例において、ルマCTB/ブロックについてALFがオフにされるとき、対応するクロマCTB/ブロックについてCCALFがオフにされる。別の例においては、例えばクロマCTBについてのフラグがルマCTBに基づいてオフにされると条件付きで推論されるなど、色成分についてフラグがオフにされると条件付きで推論されてよい。
別の実施形態において、ルマおよびクロマツリーは、異なる分割ツリー構造を使用することができる。一例において、ルマツリーが、QT、BT、およびTTの組み合わせを使用することができる一方で、クロマツリーは、QTおよびBTの組み合わせを使用することができる。
別の実施形態において、同じサイズの最大変換が、ルマブロックおよびクロマブロックに適用され得る。例えば、関連の例(例えば、VVC)において、4:2:0のプロファイルについて、最大ルマ変換が128x128である一方で、最大クロマ変換は64x64である。非インターリーブ分離ツリー方式を使用すると、一実施形態において、128×128の変換ユニットサイズをルマブロックおよびクロマブロックの両方に適用することもでき、クロマブロックについてより大きな変換ユニットを使用することによってコーディング効率を改善することができる。
本開示のいくつかの態様によれば、分離ツリー構造方式は、例えば、インターピクチャ/スライス/タイル、IBCピクチャ/スライス/タイル、などの非イントラピクチャ/スライス/タイルについて使用され得る。いくつかの例においては、分離ツリー構造方式がすべての予測モードについて使用されるため、複雑なローカルデュアルツリー方式SCIPUは不要である。
一実施形態において、ルマツリーおよびクロマツリーの最小CUサイズを、個別に事前定義することができる。例えば、ルマツリーの最小CUサイズは、LxL個のルマサンプルであり、クロマツリーの最小CUサイズは、CxC個のクロマサンプルであり、LおよびCは正の整数である。一例では、Lは4である。別の例では、Cは4である。
別の実施形態において、最大および最小ルマツリーサイズは、SPS、PPS、ピクチャヘッダ、またはスライスヘッダなどのビットストリームでシグナリングされてよい。一例において、最小ルマツリーサイズは、4×4のルマサンプルに対してシグナリングされる。LxL個のルマサンプル(ルマツリーの最小CUサイズはLxL個のルマサンプルである)よりも小さいブロックサイズは、許容されない。
別の実施形態において、最大および最小クロマツリーサイズは、SPS、PPS、ピクチャヘッダ、またはスライスヘッダなどのビットストリームでシグナリングされてよい。CxC個のクロマサンプル(クロマツリーの最小CUサイズはCxC個のクロマサンプルである)よりも小さいブロックサイズは、許容されない。
いくつかの実施形態において、クロマCUについて、予測モード(例えば、イントラ、インター、IBC)はシグナリングされない。クロマCUの予測モードは、同位置のルマCU(複数可)から導出される。一実施形態において、クロマCUの予測モードは、コーディング順序における第1の同位置のルマCUの予測モードに基づいて導出される。一例において、クロマCUの予測モードは、クロマCUの左上角の同位置のルマCUなど、コーディング順序における第1の同位置のルマCUの予測モードと同じである。別の実施形態において、第1の同位置のルマCUの予測モードがIBCである場合、クロマCUの予測モードはイントラである。そうでない(第1の同位置のルマCUの予測モードがIBCではない)場合、予測モードは、第1の同位置のルマCUの予測モードと同じである。
いくつかの実施形態において、クロマCUのすべての同位置のルマCUが同じ予測モードを共有しなければならないという適合制約を適用することができる。
別の実施形態において、クロマCUが(クロマサンプル内の)最小クロマブロックサイズでない場合、第1の同位置のルマCUの予測モードに基づいて、クロマCUの予測モードが導出される。最小クロマブロックサイズのクロマCUの場合、予測モードがさらにシグナリングされる。
本開示の一態様によれば、クロマインターCUについて、動きベクトルを同位置のルマブロックから導出することができる。一実施形態において、クロマCUの動きベクトルは、4×4のクロマサンプルに基づいて導出される。一例において、(クロマサンプル内の)各々の4×4のクロマブロックについて、動きベクトルは、(ルマサンプル内の)第1の同位置の4×4のルマブロックの動きベクトル、または(ルマサンプル内の)すべての同位置の4×4のルマブロックの平均動きベクトルに設定される。
いくつかの例において、(クロマサンプル内の)4×4のクロマブロックが(ルマサンプル内の)2つ以上の同位置の4×4のルマブロックを有する場合、水平方向および垂直方向の両方におけるルマ動きベクトルの最大差がしきい値以下であるという適合制約を適用することができる。一例において、しきい値は、1つのルマサンプルである。別の例において、しきい値は、1つのクロマサンプルである。別の例において、クロマブロックが制約を満たさない場合、クロマブロックは分割されなければならない。別の例において、制約を満たさない最小のクロマブロックに関して、それはイントラとしてシグナリングされる。
本開示の一態様によれば、クロマIBC CUについて、ブロックベクトルを同位置のルマブロックから導出することができる。いくつかの実施形態において、クロマCUのブロックベクトルは、4×4のクロマサンプルに基づいて導出される。一例において、(クロマサンプル内の)各々の4×4のクロマブロックについて、ブロックベクトルは、(ルマサンプル内の)第1の同位置の4×4のルマブロックの動きベクトル、または(ルマサンプル内の)すべての同位置の4×4のルマブロックの平均ブロックベクトルに設定される。いくつかの例において、平均ブロックベクトルを整数精度に丸めることが必要となり得る。丸めは、0、無限大(正の無限大への正のブロックベクトル、負の無限大への負のブロックベクトル)、正の無限大、または負の無限大に向かってよい。
いくつかの実施形態において、(クロマサンプル内の)4×4のクロマブロックが(ルマサンプル内の)2つ以上の同位置の4×4のルマブロックを有する場合、水平方向および垂直方向の両方におけるルマブロックベクトルの最大差がしきい値以下であるという適合制約を適用することができる。一例において、しきい値は、1つのルマサンプルである。別の例において、しきい値は、1つのクロマサンプルである。別の例において、クロマブロックが制約を満たさない場合、クロマブロックは分割されなければならない。別の例において、制約を満たさない最小のクロマブロックに関して、イントラ予測モードが最小クロマブロックについてシグナリングされる。
図20が、本開示の一実施形態によるプロセス(2000)を概説するフローチャートを示している。プロセス(2000)を、ビデオエンコーダで使用することができる。種々の実施形態において、プロセス(2000)は、端末デバイス(310)、(320)、(330)、および(340)の処理回路、ビデオエンコーダ(403)の機能を実行する処理回路、ビデオエンコーダ(603)の機能を実行する処理回路、ビデオエンコーダ(703)の機能を実行する処理回路、などの処理回路によって実行される。いくつかの実施形態において、プロセス(2000)はソフトウェア命令によって実装され、したがって、処理回路がソフトウェア命令を実行するとき、処理回路はプロセス(2000)を実行する。処理は(S20301)において始まり、(S2010)に進む。
(S2010)において、ビットストリーム内のCTUの異なる色成分をコーディングするために使用される非インターリーブ分離ツリー構造が決定される。
(S2020)において、複数のCTUの第1の色成分が、ビットストリームの第1の部分に符号化される。
(S2030)において、複数のCTUの第2の色成分が、ビットストリームの第2の部分に符号化される。第1の部分および第2の部分は、ビットストリーム内で非インターリーブである。例えば、第2の部分は、ビットストリーム内で第1の部分の後に位置し、第1の部分とインターリーブされない。
いくつかの実施形態において、複数のCTUの第1の色成分の符号化は、複数のCTUの第2の色成分の符号化と並行して実行される。
一例において、複数のCTUは、イントラピクチャ(イントラ予測を使用してコーディングされたピクチャ)を形成する。別の例において、複数のCTUは、インターピクチャ(インター予測を使用してコーディングされたピクチャ)を形成する。別の例において、複数のCTUは、イントラブロックコピー(IBC)ピクチャ(イントラブロックコピーを使用してコーディングされたピクチャ)を形成する。別の例において、複数のCTUは、ピクチャ内のイントラスライス(イントラ予測を使用してコーディングされたスライス)を形成する。別の例において、複数のCTUは、ピクチャ内のインタースライス(インター予測を使用してコーディングされたスライス)を形成する。別の例において、複数のCTUは、ピクチャ内のIBCスライス(IBCを使用してコーディングされたスライス)を形成する。別の例において、複数のCTUは、ピクチャ内のイントラタイル(イントラ予測を使用してコーディングされたタイル)を形成する。別の例において、複数のCTUは、ピクチャ内のインタータイル(インター予測を使用してコーディングされたタイル)を形成する。別の例において、複数のCTUは、ピクチャ内のIBCタイル(IBCを使用してコーディングされたタイル)を形成する。
いくつかの例において、各々のCTUは、ルマ成分のルマCTBと、クロマ成分の2つのクロマCTBとを含む。一例において、複数のCTUのルマCTBは、ビットストリームのネットワーク抽象化レイヤユニット(NALU)の第1の部分に符号化され、複数のCTUのクロマCTBは、NALUの第2の部分に符号化される。一例において、NALUの第2の部分がNALU内の第1の部分の後の整数バイトから始まるように、バイトアライメント(1つまたは複数のビット)をルマCTBの後かつクロマCTBの前に挿入することができる。別の例において、ルマCTBとクロマCTBとの間のコンテキスト適応型バイナリ算術符号化(CABAC)同期は、シーケンスパラメータセット(SPS)同期フラグ、例えばsps_entropy_coding_sync_enabled_flagの値に基づいて実行されても、されなくてもよい。
いくつかの例において、複数のCTUのルマCTBは、ビットストリームの第1のネットワーク抽象化レイヤユニット(NALU)を形成するように符号化され、複数のCTUのクロマCTBは、ビットストリームの第2のNALUを形成するように符号化される。
一例において、ルマCTBおよびクロマCTBのサイズは、ルマサンプルの単位において異なり得る。一例において、ルマCTBが128×128のルマサンプルを含む場合、クロマCTBは、ルマサンプルの単位の256×256のルマサンプルに対応する色フォーマット4:2:0の128×128のクロマサンプルを含むことができる。
いくつかの例においては、クロスコンポーネント予測が使用され、クロマブロック内のクロマサンプルを、クロスコンポーネント線形モデル(CCLM)モードにおける少なくとも第1のルマCTBおよび第2のルマCTBのルマサンプルなど、異なるルマCTBからのルマ予測に基づいて予測することができる。
いくつかの実施形態において、クロマCU(例えば、クロマコーディングブロック)またはクロマTU(クロマ送信ユニット)のQP値は、直接シグナリングされ、あるいは同位置のルマブロックのQPから導出される。一例において、QP値は、複数のルマブロックのうちの復号可能な第1の同位置のルマブロックのQP値に基づいて導出される。別の例において、QP値は、複数のルマブロックの平均QP値として導出される。別の例において、QP値は、複数のルマブロックの中央QP値として導出される。別の例において、QP値は、クロマブロックの中心位置と同位置の中心ルマブロックのQP値として導出される。
いくつかの実施形態においては、CTBレベルの復元されたピクセルの不必要なロードを回避するために、ルマ処理チャネルおよびクロマ処理チャネルのCTBサイズは、ルマサンプルの単位で同じになるように制約される。したがって、ルマサンプル内のCTBサイズのルマCTBは、ルマ処理チャネルで符号化され、ルマサンプル内のCTBサイズのクロマCTBは、クロマ処理チャネルで符号化される。一例において、CTUのクロマCTBの符号化は、CTUのルマCTBの符号化が完了した後に開始することができる。
いくつかの例において、サンプル適応オフセット(SAO)、適応ループフィルタ(ALF)、クロスコンポーネント適応ループフィルタ(CCALF)、などのCTUレベル制御パラメータは、ルマCTBおよびクロマCTBについて別々にシグナリングされる。例えば、CTU内のルマCTBのCTUレベル制御パラメータは、ルマCTBのビットストリームでシグナリングされ、CTU内のクロマCTBのCTUレベル制御パラメータは、クロマCTBのビットストリーム内でシグナリングされる。いくつかの例において、クロマCTBのいくつかのパラメータは、同位置のルマCTBに基づいて導出され得る。例えば、クロマCTBのCTUレベル制御パラメータは、同位置のルマCTBに基づいて導出される。
いくつかの例において、ルマCTBおよびクロマCTBは、異なる分割ツリー構造を使用して分割され得る。一例において、CTUのルマCTBは、第1の分割ツリー構造(例えば、QT、BT、およびTTの組み合わせ)を使用して分割され、クロマCTBは、第1の分割ツリー構造とは異なる第2の分割ツリー構造(例えば、QTとBTとの組み合わせ)を使用して分割される。
一例において、最大ルマツリーサイズ(最大ルマCBサイズ)がビットストリームでシグナリングされる。別の例において、最小ルマツリーサイズ(最小ルマCBサイズ)がビットストリームでシグナリングされる。別の例において、最大クロマツリーサイズ(最大クロマCBサイズ)がビットストリームでシグナリングされる。別の例において、最小クロマツリーサイズ(最小クロマCBサイズ)がビットストリームでシグナリングされる。
いくつかの例において、クロマCUの予測モードはシグナリングされず、同位置のルマCUに基づいて導出される。いくつかの例において、クロマCUの予測モードは、クロマCUが最小クロマブロックサイズ要件を満たす(クロマCUが最小クロマブロックサイズを有する)ことに応答してビットストリーム内でシグナリングされる。
いくつかの例において、クロマCUは、(インター予測を使用してコーディングされた)クロマインターCUであり、クロマCUの動きベクトルは、同位置のルマCU(例えば、同位置のルマブロック、同位置のルマCB)の動きベクトルに基づいて導出される。
いくつかの例において、クロマCUは、(IBCを使用してコーディングされた)クロマIBC CUであり、クロマCUのブロックベクトルは、同位置のルマCU(例えば、同位置のルマブロック、同位置のルマCB)のブロックベクトルに基づいて導出される。
次いで、プロセスは(S2099)に進み、終了する。
プロセス(2000)を適切に適合させることができる。プロセス(2000)におけるステップは、変更および/または省略されてよい。追加のステップが追加されてよい。任意の適切な実施順序を使用することができる。
図21が、本開示の一実施形態によるプロセス(2100)を概説するフローチャートを示している。プロセス(2100)を、ビデオデコーダで使用することができる。種々の実施形態において、プロセス(2100)は、端末デバイス(310)、(320)、(330)、および(340)の処理回路、ビデオデコーダ(410)の機能を実行する処理回路、ビデオデコーダ(510)の機能を実行する処理回路、などの処理回路によって実行される。いくつかの実施形態において、プロセス(2100)はソフトウェア命令によって実装され、したがって、処理回路がソフトウェア命令を実行するとき、処理回路はプロセス(2100)を実行する。プロセスは(S2101)において始まり、(S2110)に進む。
(S2110)において、ビットストリームが受信され、ビットストリームが、ビットストリーム内のコーディングツリーユニット(CTU)の異なる色成分をコーディングするために非インターリーブ分離ツリー構造を使用していると決定される。
(S2120)において、複数のCTUの第1の色成分が、ビットストリームの第1の部分から復号される。
(S2130)において、複数のCTUの第2の色成分が、ビットストリームの第2の部分から復号される。第1の部分および第2の部分は、ビットストリーム内でインターリーブされておらず、例えば、第2の部分は、ビットストリーム内で第1の部分の後に位置する。
いくつかの例において、ビットストリームの第1の部分からの複数のCTUの第1の色成分の復号は、ビットストリームの第2の部分からの複数のCTUの第2の色成分の復号と並行して実行される。
一例において、複数のCTUは、イントラピクチャ(イントラ予測を使用してコーディングされたピクチャ)を形成する。別の例において、複数のCTUは、インターピクチャ(インター予測を使用してコーディングされたピクチャ)を形成する。別の例において、複数のCTUは、イントラブロックコピー(IBC)ピクチャ(イントラブロックコピーを使用してコーディングされたピクチャ)を形成する。別の例において、複数のCTUは、ピクチャ内のイントラスライス(イントラ予測を使用してコーディングされたスライス)を形成する。別の例において、複数のCTUは、ピクチャ内のインタースライス(インター予測を使用してコーディングされたスライス)を形成する。別の例において、複数のCTUは、ピクチャ内のIBCスライス(IBCを使用してコーディングされたスライス)を形成する。別の例において、複数のCTUは、ピクチャ内のイントラタイル(イントラ予測を使用してコーディングされたタイル)を形成する。別の例において、複数のCTUは、ピクチャ内のインタータイル(インター予測を使用してコーディングされたタイル)を形成する。別の例において、複数のCTUは、ピクチャ内のIBCタイル(IBCを使用してコーディングされたタイル)を形成する。
いくつかの例において、各々のCTUは、ルマ成分のルマCTBと、クロマ成分の2つのクロマCTBとを含む。いくつかの例において、複数のCTUのルマCTBは、ビットストリーム中のネットワーク抽象化レイヤユニット(NALU)の第1の部分から復号され、複数のCTUのクロマCTBは、NALUの第2の部分から復号される。いくつかの実施形態においては、バイトアライメントがルマCTBとクロマCTBとの間に挿入され、NALUの第2の部分は、NALU内の第1の部分の後の整数バイトから始まる。いくつかの例において、ルマCTBとクロマCTBとの間のコンテキスト適応型バイナリ算術符号化(CABAC)同期を実行するかどうかは、sps_entropy_coding_sync_enabled_flagなどのシーケンスパラメータセット(SPS)同期フラグの値に基づいて判定される。
いくつかの例においては、ビットストリームの第1のネットワーク抽象化レイヤユニット(NALU)が解析および復号されて、複数のCTUのルマCTBが得られ、ビットストリームの第2のNALUが解析および復号されて、複数のCTUのクロマCTBが得られる。一例において、第1のNALUからの解析および復号は、第2のNALUからの解析および復号と並列である。
いくつかの例において、ルマCTBおよびクロマCTBのサイズは、ルマサンプルの単位において異なり得る。一例において、ルマサンプル中のルマCTBとは異なるサイズのクロマCTBが復号される。一例において、ルマCTBが128×128のルマサンプルを含む場合、クロマCTBは、ルマサンプルの単位の256×256のルマサンプルに対応する色フォーマット4:2:0の128×128のクロマサンプルを含むことができる。例えば、少なくとも色フォーマット4:2:0の128×128のクロマサンプルのクロマCTBを復号することができる。
いくつかの例においては、クロスコンポーネント予測が使用され、クロマブロック内のクロマサンプルを、クロスコンポーネント線形モデル(CCLM)モードにおける少なくとも第1のルマCTBおよび第2のルマCTBのルマサンプルなど、異なるルマCTBからのルマ予測に基づいて予測することができる。
いくつかの実施形態において、クロマCU(例えば、クロマコーディングブロック)またはクロマTU(クロマ送信ユニット)のQP値は、直接シグナリングされ、あるいは同位置のルマブロックのQPから導出される。いくつかの例において、クロマブロックと同位置の複数のルマブロックが決定される。一例において、クロマCUのQP値は、複数のルマブロックのうちの復号可能な第1の同位置のルマブロックのQP値に基づいて導出される。別の例において、クロマCUのQP値は、複数のルマブロックの平均QP値として導出される。別の例において、クロマCUのQP値は、複数のルマブロックの中央QP値として導出される。別の例において、クロマCUのQP値は、クロマブロックの中心位置と同位置の中心ルマブロックのQP値として導出される。
いくつかの実施形態においては、CTBレベルの復元されたピクセルの不必要なロードを回避するために、ルマ処理チャネルおよびクロマ処理チャネルのCTBサイズは、ルマサンプルの単位で同じになるように制約される。したがって、ルマサンプル内のCTBサイズのルマCTBは、ルマ処理チャネルで復号され、ルマサンプル内のCTBサイズのクロマCTBは、クロマ処理チャネルで復号される。一例において、CTUのクロマCTBの復号は、CTUのルマCTBの復号が完了した後に開始することができる。
いくつかの例において、サンプル適応オフセット(SAO)、適応ループフィルタ(ALF)、クロスコンポーネント適応ループフィルタ(CCALF)、などのCTUレベル制御パラメータは、ルマCTBおよびクロマCTBについて別々にシグナリングされる。例えば、CTU内のルマCTBのCTUレベル制御パラメータは、ルマCTBのビットストリームでのシグナリングから決定され、CTU内のクロマCTBのCTUレベル制御パラメータは、クロマCTBのビットストリームでのシグナリングから決定される。いくつかの例において、クロマCTBのいくつかのパラメータは、同位置のルマCTBに基づいて導出され得る。例えば、クロマCTBのCTUレベル制御パラメータは、少なくとも同位置のルマCTBに基づいて導出される。
いくつかの例において、ルマCTBおよびクロマCTBは、異なる分割ツリー構造を使用して分割され得る。一例において、CTUのルマCTBは、第1の分割ツリー構造(例えば、QT、BT、およびTTの組み合わせ)を使用してルマツリーに分割され、クロマCTBは、第1の分割ツリー構造とは異なる第2の分割ツリー構造(例えば、QTとBTとの組み合わせ)を使用してクロマツリーに分割される。
一例において、最大ルマツリーサイズ(最大ルマCBサイズ)が、ビットストリームでのシグナリングに基づいて決定される。別の例において、最小ルマツリーサイズ(最小ルマCBサイズ)が、ビットストリームでのシグナリングに基づいて決定される。別の例において、最大クロマツリーサイズ(最大クロマCBサイズ)が、ビットストリームでのシグナリングに基づいて決定される。別の例において、最小クロマツリーサイズ(最小クロマCBサイズ)が、ビットストリームでのシグナリングに基づいて決定される。
いくつかの例において、クロマコーディングユニット(CU)(クロマコーディングブロックとも呼ばれるクロマツリーにおけるコーディングユニット)の予測モードはシグナリングされず、同位置のルマCU(ルマツリーにおけるコーディングユニット)に基づいて導出される。いくつかの例において、クロマCUの予測モードは、クロマCUが最小クロマブロックサイズ要件を満たす(クロマCUが最小クロマブロックサイズを有する)ことに応答したビットストリームでのシグナリングに基づいて決定される。
いくつかの例において、クロマCUは、(インター予測を使用してコーディングされた)クロマインターCUであり、クロマCUの動きベクトルは、同位置のルマCU(例えば、同位置のルマブロック、同位置のルマCB)の動きベクトルに基づいて導出される。
いくつかの例において、クロマCUは、(IBCを使用してコーディングされた)クロマIBC CUであり、クロマCUのブロックベクトルは、同位置のルマCU(例えば、同位置のルマブロック、同位置のルマCB)のブロックベクトルに基づいて導出される。
次いで、プロセスは(S2199)に進み、終了する。
プロセス(2100)を適切に適合させることができる。プロセス(2100)におけるステップは、変更および/または省略されてよい。さらなるステップを追加することができる。任意の適切な実施順序を使用することができる。
上記で説明した技法を、コンピュータ可読命令を使用してコンピュータソフトウェアとして実装でき、1つまたは複数のコンピュータ可読媒体に物理的に記憶することができる。例えば、図22が、開示された主題の特定の実施形態を実施するために適したコンピュータシステム(2200)を示している。
コンピュータソフトウェアを、1つまたは複数のコンピュータ中央処理装置(CPU:central processing unit)およびグラフィック処理装置(GPU:Graphics Processing Unit)などによって直接的に、または解釈およびマイクロコードの実行などを通して実行され得る命令を含むコードを生成するために、アセンブリ、コンパイル、リンキング、または同様の機構の対象とされ得る任意の適切なマシンコードまたはコンピュータ言語を使用してコーディングすることができる。
命令を、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム機、IoT(internet of things)機器、などを含むさまざまなタイプのコンピュータまたはその構成要素上で実行することができる。
コンピュータシステム(2200)に関して図22に示されている構成要素は、本質的に例示であり、本開示の実施形態を実施するコンピュータソフトウェアの使用または機能の範囲に関するいかなる限定も示唆することを意図していない。また、構成要素の構成を、コンピュータシステム(2200)の例示的な実施形態に示される構成要素のいずれか1つまたは組み合わせに関する何らかの依存性または要件を有すると解釈すべきではない。
コンピュータシステム(2200)は、特定のヒューマンインタフェース入力装置を含み得る。そのようなヒューマンインタフェース入力装置は、例えば、触覚入力(キーストローク、スワイプ、データグローブの動きなど)、音声入力(音声、拍手など)、視覚入力(ジェスチャなど)、嗅覚入力(図示せず)を介して、1人または複数の人間であるユーザによる入力に応答し得る。ヒューマンインタフェース装置を、音声(発話、音楽、周囲音など)、画像(走査画像、静止画カメラで取得される写真画像など)、映像(二次元映像、立体映像を含む三次元映像など)などの人による意識的な入力に必ずしも直接的には関係しない特定の媒体の捕捉に使用することもできる。
入力ヒューマンインタフェース装置は、キーボード(2201)、マウス(2202)、トラックパッド(2203)、タッチスクリーン(2210)、データグローブ(図示せず)、ジョイスティック(2205)、マイクロフォン(2206)、スキャナ(2207)、カメラ(2208)のうちの1つまたは複数を含み得る(各々が1つだけ図示されている)。
さらに、コンピュータシステム(2200)は、特定のヒューマンインタフェース出力装置を含み得る。そのようなヒューマンインタフェース出力装置は、例えば、触覚出力、音、光、および嗅覚/味覚を通して、1人または複数の人間であるユーザの感覚を刺激し得る。このようなヒューマンインタフェース出力装置は、触覚出力装置(例えば、タッチスクリーン(2210)、データグローブ(図示せず)、またはジョイスティック(2205)による触覚フィードバックであるが、入力装置として機能しない触覚フィードバック装置でもよい)、オーディオ出力装置(スピーカ(2209)、ヘッドホン(図示せず)など)、視覚出力装置(CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含むスクリーン(2210)など(それぞれがタッチスクリーン入力機能を有しても、有さなくてもよく、それぞれが触覚フィードバック機能を有しても、有さなくてもよく、一部は、立体グラフィック出力、仮想現実眼鏡(図示せず)、ホログラフィックディスプレイおよびスモークタンク(図示せず)などの手段を通じて二次元視覚出力または三次元以上の出力を出力することが可能であってよい))、およびプリンタ(図示せず)を含み得る。
さらに、コンピュータシステム(2200)は、CD/DVDまたは同様の媒体(2221)を有するCD/DVD ROM/RW(2220)を含む光学媒体、サムドライブ(2222)、リムーバブルハードドライブまたはソリッドステートドライブ(2223)、テープおよびフロッピーディスクなどのレガシー磁気媒体(描写せず)、セキュリティドングルなどの専用のROM/ASIC/PLDベースのデバイス(図示せず)など、人間がアクセス可能なストレージデバイスおよびそれらに関連する媒体を含むことができる。
当業者であれば、ここで開示されている主題に関して使用される「コンピュータ可読媒体」という用語が、伝送媒体、搬送波、またはその他の一時的な信号を含まないことも、理解できるであろう。
さらに、コンピュータシステム(2200)は、1つまたは複数の通信ネットワーク(2255)へのインタフェース(2254)を含むことができる。ネットワークは、例えば、ワイヤレス、有線、光であり得る。ネットワークはさらに、ローカル、広域、メトロポリタン、車両および産業用、リアルタイム、遅延耐性などであり得る。ネットワークの例は、イーサネット、ワイヤレスLANなどのローカルエリアネットワーク、GSM、3G、4G、5G、LTEなどを含むセルラネットワーク、ケーブルTV、衛星TV、および地上放送TVを含むTV有線または無線広域デジタルネットワーク、CANBusを含む車両および産業、などを含む。特定のネットワークは、一般に、特定の汎用データポートまたは周辺バス(2249)(例えば、コンピュータシステム(2200)のUSBポートなど)に取り付けられる外部ネットワークインタフェースアダプタを必要とし、他のネットワークは、後述のとおりのシステムバスへの取り付けによってコンピュータシステム(2200)のコアに統合される(例えば、PCコンピュータシステムへのイーサネットインタフェースまたはスマートフォンコンピュータシステムへのセルラーネットワークインタフェースなど)。これらのネットワークのいずれかを使用して、コンピュータシステム(2200)は他のエンティティと通信することができる。このような通信は、受信のみの一方向(例えば、テレビ放送)、送信のみの一方向(例えば、特定のCANbus装置へのCANbus)、あるいは例えばローカルまたはワイドエリアデジタルネットワークを用いた他のコンピュータシステムへの双方向であり得る。特定のプロトコルおよびプロトコルスタックが、上記で説明したように、それらのネットワークおよびネットワークインタフェースの各々において使用され得る。
前述のヒューマンインタフェース装置、人間がアクセス可能なストレージデバイス、およびネットワークインタフェースは、コンピュータシステム(2200)のコア(2240)に取り付け可能である。
コア(2240)は、1つまたは複数の中央処理装置(CPU)(2241)、グラフィック処理装置(GPU)(2242)、フィールドプログラマブルゲートエリア(FPGA:Field Programmable Gate Area)(2243)の形式の専用のプログラマブル処理ユニット、特定のタスク用のハードウェアアクセラレータ(2244)、およびグラフィックスアダプタ(2250)、などを含み得る。これらの装置は、読み取り専用メモリ(ROM)(2245)、ランダムアクセスメモリ(2246)、内蔵のユーザがアクセスできないハードドライブ、SSDなどの内部大容量記憶装置(2247)と共に、システムバス(2248)を介して接続され得る。一部のコンピュータシステムにおいては、追加のCPU、GPUなどによる拡張を可能にするために、1つまたは複数の物理プラグの形式でシステムバス(2248)にアクセス可能であり得る。周辺装置は、コアのシステムバス(2248)に直接接続されても、周辺バス(2249)を介して接続されてもよい。一例において、スクリーン(2210)はグラフィックスアダプタ(2250)に接続され得る。周辺バスのアーキテクチャは、PCI、USBなどを含む。
CPU(2241)、GPU(2242)、FPGA(2243)、およびアクセラレータ(2244)は、組み合わせて前述のコンピュータコードを構成できる特定の命令を実行できる。そのコンピュータコードは、ROM(2245)またはRAM(2246)に格納され得る。過渡的なデータをRAM(2246)に格納することもできる一方で、恒久的なデータを例えば内部大容量記憶装置(2247)に格納することができる。任意のメモリ装置への高速な格納および取り出しを、1つまたは複数のCPU(2241)、GPU(2242)、大容量記憶装置(2247)、ROM(2245)、RAM(2246)、などに密接に関連付けられ得るキャッシュメモリの使用を通じて可能にすることができる。
コンピュータ可読媒体は、さまざまなコンピュータ実施動作を実行するためのコンピュータコードを有することができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築されたものであってよく、あるいはコンピュータソフトウェアの分野の当業者とって周知かつ使用可能な種類のものであってよい。
一例として、限定するものではないが、アーキテクチャを有するコンピュータシステム(2200)、具体的にはコア(2240)が、1つまたは複数の有形のコンピュータ可読媒体に組み込まれたソフトウェアを実行するプロセッサ(CPU、GPU、FPGA、アクセラレータなどを含む)の結果として機能を提供することができる。このようなコンピュータ可読媒体は、上記で紹介したユーザアクセス可能な大容量記憶装置、ならびにコア内部大容量記憶装置(2247)またはROM(2245)などの非一時的な性質のコア(2240)の特定の記憶装置に関連付けられた媒体であり得る。本開示の種々の実施形態を実施するソフトウェアは、そのような装置に格納され、コア(2240)によって実行され得る。コンピュータ可読媒体は、特定の必要性に応じて、1つまたは複数のメモリ装置またはチップを含むことができる。ソフトウェアは、コア(2240)、とくにはその内部のプロセッサ(CPU、GPU、FPGAなどを含む)に、RAM(2246)に格納されるデータ構造の定義およびソフトウェアによって定義される処理によるそのようなデータ構造の偏向など、本明細書に記載の特定のプロセスまたは特定のプロセスの特定の部分を実行させることができる。これに加え、あるいは代えて、コンピュータシステムは、本明細書に記載の特定のプロセスまたは特定のプロセスの特定の部分を実行するために、ソフトウェアの代わりに動作またはソフトウェアと一緒に動作することができる回路(例えば、アクセラレータ(2244))に論理的に配線され、あるいは他のやり方で具体化された結果として、機能を提供することができる。ソフトウェアへの言及は、必要に応じて、ロジックを包含することができ、逆もまた同様である。必要に応じて、コンピュータ可読媒体への言及は、実行のためのソフトウェアを記憶する回路(集積回路(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,ビデオユーザビリティ情報
GOPs:Groups of Pictures,ピクチャグループ
TUs:Transform Units,変換ユニット
PUs:Prediction Units,予測ユニット
CTUs:Coding Tree Units,コーディングツリーユニット
CTBs:Coding Tree Blocks,コーディングツリーブロック
PBs:Prediction Blocks,予測ブロック
HRD:Hypothetical Reference Decoder,仮想参照デコーダ
SNR:Signal Noise Ratio,信号雑音比
CPUs:Central Processing Units,中央処理装置
GPUs:Graphics Processing Units,グラフィックス処理装置
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,コーディングユニット
本開示は、いくつかの例示的な実施形態を説明してきたが、本開示の範囲に含まれる変更、置換、およびさまざまな代替等価物が存在する。したがって、当業者であれば、本明細書に明示的には図示または記載されていないが、本開示の原理を具現化し、したがって本開示の趣旨および範囲内にある多数のシステムおよび方法を考案できることを、理解できるであろう。
101 サンプル
102,103 矢印
104 ブロック
201 カレントブロック
202,203,204,205,206 周囲のサンプル
300 通信システム
310,320,330,340 端末デバイス
350 ネットワーク
400 通信システム
401 ビデオソース
402 ビデオピクチャのストリーム
403 ビデオエンコーダ
404 符号化ビデオデータ
405 ストリーミングサーバ
406 クライアントサブシステム
407 符号化ビデオデータのコピー
408 クライアントサブシステム
409 符号化ビデオデータのコピー
410 ビデオデコーダ
411 ビデオピクチャの出力ストリーム
412 ディスプレイ
413 キャプチャサブシステム
420 電子デバイス
430 電子デバイス
501 チャネル
510 ビデオデコーダ
512 レンダーデバイス
515 バッファメモリ
520 パーサー
521 シンボル
530 電子デバイス
531 受信器
551 スケーラ/逆変換ユニット
552 イントラ予測ユニット
553 動き補償予測ユニット
555 アグリゲータ
556 ループフィルタユニット
557 参照ピクチャメモリ
558 カレントピクチャバッファ
601 ビデオソース
603 ビデオエンコーダ
620 電子デバイス
630 ソースコーダ
632 コーディングエンジン
633 デコーダ
634 参照ピクチャメモリ
635 予測器
640 送信器
643 コーディングされたビデオシーケンス
645 エントロピーコーダ
650 コントローラ
660 チャネル
703 ビデオエンコーダ
721 汎用コントローラ
722 イントラエンコーダ
723 残差計算器
724 残差エンコーダ
725 エントロピーエンコーダ
726 スイッチ
728 残差デコーダ
730 インターエンコーダ
810 ビデオデコーダ
871 エントロピーデコーダ
872 イントラデコーダ
873 残差デコーダ
874 復元モジュール
880 インターデコーダ
1100 ピクチャ
1101 コーディングツリーユニット(CTU)
1200 ピクチャ
1201,1202,1203,1204,1205,1206,1207,1208,1209,1210,1211,1212 タイル
1221,1222,1223 ラスタ走査スライス
1300 ピクチャ
1301,1302,1303,1304,1305,1306,1307,1308,1309,1310,1311,1312,1313,1314,1315,1316,1317,1318,1319,1320,1321,1322,1323,1324 タイル
1331,1332,1333,1334,1335,1336,1337,1338,1339 矩形スライス
1400 ピクチャ
1401,1402,1403,1404,1405,1406,1407,1408,1409,1410,1411 ブリック
1421,1422,1423,1424 矩形スライス
1500 ピクチャ
1501,1502,1503,1504,1505,1506,1507,1508,1509,1510,1511,1512,1513,1514,1515,1516,1517,1518 タイル
1621,1622,1623,1624 分割タイプ
1711,1721 ノード
1751,1752,1753,1754 マルチタイプツリー(MTT)ノード
1900 コーディングツリーユニット(CTU)
2200 コンピュータシステム
2201 キーボード
2202 マウス
2203 トラックパッド
2205 ジョイスティック
2206 マイクロフォン
2207 スキャナ
2208 カメラ
2209 スピーカ
2210 タッチスクリーン
2220 CD/DVD ROM/RW
2221 媒体
2222 サムドライブ
2223 リムーバブルハードドライブまたはソリッドステートドライブ
2240 コア
2241 中央処理装置(CPU)
2242 グラフィック処理装置(GPU)
2243 フィールドプログラマブルゲートエリア(FPGA)
2244 アクセラレータ
2245 読み取り専用メモリ(ROM)
2246 ランダムアクセスメモリ(RAM)
2247 内部大容量記憶装置
2248 システムバス
2249 周辺バス
2250 グラフィックスアダプタ
2254 ネットワークインタフェース
2255 通信ネットワーク

Claims (20)

  1. デコーダにおけるビデオ処理の方法であって、
    ビットストリームにおけるコーディングツリーユニット(CTU)の異なる色成分のコーディングに非インターリーブ分離ツリー構造が使用されていると決定するステップと、
    前記ビットストリームの第1の部分から複数のCTUの第1の色成分を復号するステップと、
    前記ビットストリームの第2の部分から前記複数のCTUの第2の色成分を復号するステップであって、前記第2の部分は、前記ビットストリームにおいて前記第1の部分の後に位置する、ステップと
    を含む、方法。
  2. 前記ビットストリームの第1の部分から複数のCTUの第1の色成分を復号する前記ステップは、前記ビットストリームの第2の部分から前記複数のCTUの第2の色成分を復号する前記ステップと並行している、請求項1に記載の方法。
  3. 前記複数のCTUは、イントラピクチャ、インターピクチャ、イントラブロックコピー(IBC)ピクチャ、ピクチャ内のイントラスライス、ピクチャ内のインタースライス、ピクチャ内のIBCスライス、ピクチャ内のイントラタイル、ピクチャ内のインタータイル、またはピクチャ内のIBCタイルのうちの1つを形成する、請求項1に記載の方法。
  4. 複数のCTUの第1の色成分を復号する前記ステップおよび前記複数のCTUの第2の色成分を復号する前記ステップは、
    前記ビットストリーム内のネットワーク抽象化レイヤユニット(NALU)の第1の部分から前記複数のCTUのルマコーディングツリーブロック(CTB)を復号するステップと、
    前記NALUの第2の部分から前記複数のCTUのクロマCTBを復号するステップと
    をさらに含む、請求項1に記載の方法。
  5. 前記NALUの前記第2の部分は、前記NALUの前記第1の部分の後の整数バイトから始まる、請求項4に記載の方法。
  6. シーケンスパラメータセット(SPS)同期フラグの値に基づいて前記ルマCTBと前記クロマCTBとの間のコンテキスト適応型バイナリ算術符号化(CABAC)同期を実行するステップ
    をさらに含む、請求項4に記載の方法。
  7. 複数のCTUの第1の色成分を復号する前記ステップおよび前記複数のCTUの第2の色成分を復号する前記ステップは、
    前記ビットストリーム内の第1のネットワーク抽象化レイヤユニット(NALU)から前記複数のCTUのルマコーディングツリーブロック(CTB)を解析および復号するステップと、
    前記ビットストリーム内の第2のNALUから前記複数のCTUのクロマCTBを解析および復号するステップと
    をさらに含む、請求項1に記載の方法。
  8. 第1のNALUから解析および復号する前記ステップは、第2のNALUから解析および復号する前記ステップと並行して実行される、請求項7に記載の方法。
  9. 前記複数のCTUの前記第1の色成分は、前記複数のCTUのルマコーディングツリーブロック(CTB)に対応し、前記複数のCTUの前記第2の色成分は、クロマCTBに対応し、前記方法は、
    ルマCTBからルマサンプル内の異なるサイズのクロマCTBを復号するステップ
    を含む、請求項1に記載の方法。
  10. クロスコンポーネント線形モデル(CCLM)モードにおいて少なくとも第1のルマコーディングツリーブロック(CTB)および第2のルマCTB内のルマサンプルに基づいてクロマブロック内のクロマサンプルを予測するステップ
    をさらに含む、請求項1に記載の方法。
  11. クロマブロックと同位置の複数のルマブロックを決定するステップと、
    前記クロマブロックの量子化パラメータ(QP)値を、
    前記複数のルマブロックのうちの復号された第1の同位置のルマブロックのQP値、
    前記複数のルマブロックの平均QP値、
    前記複数のルマブロックの中央QP値、または
    前記クロマブロックの中心位置と同位置の中心ルマブロックのQP値
    のうちの少なくとも1つに基づいて導出するステップと
    をさらに含む、請求項1に記載の方法。
  12. ルマ処理チャネルにおいてルマサンプル内のルマコーディングツリーブロック(CTB)サイズのCTBを復号するステップと、
    クロマ処理チャネルにおいてルマサンプル内の前記CTBサイズのクロマCTBを復号するステップと
    をさらに含む、請求項1に記載の方法。
  13. CTUのクロマCTBの復号を、前記CTUのルマCTBの復号の完了後に開始するステップ
    をさらに含む、請求項12に記載の方法。
  14. クロマコーディングツリーブロック(CTB)のためのCTUレベル制御パラメータを、
    前記クロマCTBに関する前記ビットストリームにおけるシグナリング、および
    同位置のルマCTBに基づく前記クロマCTBのための前記CTUレベル制御パラメータの導出
    のうちの少なくとも1つに基づいて決定するステップ
    をさらに含む、請求項1に記載の方法。
  15. ルマコーディングツリーブロック(CTB)は、第1の分割ツリー構造を使用して分割され、クロマCTBは、前記第1の分割ツリー構造とは異なる第2の分割ツリー構造を使用して分割される、請求項1に記載の方法。
  16. 前記ビットストリームから最大ルマツリーサイズを決定するステップ、
    前記ビットストリームから最小ルマツリーサイズを決定するステップ、
    前記ビットストリームから最大クロマツリーサイズを決定するステップ、または
    前記ビットストリームから最小クロマツリーサイズを決定するステップ
    のうちの少なくとも1つをさらに含む、請求項1に記載の方法。
  17. クロマコーディングユニット(CU)の予測モードを同位置のルマCUに基づいて導出するステップ
    をさらに含む、請求項1に記載の方法。
  18. クロマCUの予測モードを、前記クロマCUが最小クロマブロックサイズ要件を満たすことに応答して、前記ビットストリーム内の信号に基づいて決定するステップ
    をさらに含む、請求項17に記載の方法。
  19. クロマコーディングユニット(CU)の動きベクトルを、前記クロマCUがクロマイントラCUであることに応答して、同位置のルマCUの動きベクトルに基づいて導出するステップ
    をさらに含む、請求項1に記載の方法。
  20. クロマコーディングユニット(CU)のブロックベクトルを、前記クロマCUがクロマイントラブロックコピー(IBC)CUであることに応答して、同位置のルマCUのブロックベクトルに基づいて導出するステップ
    をさらに含む、請求項1に記載の方法。
JP2023525099A 2021-07-22 2022-07-19 非インターリーブ分離ツリー Pending JP2024518007A (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US202163224767P 2021-07-22 2021-07-22
US202163224771P 2021-07-22 2021-07-22
US63/224,767 2021-07-22
US63/224,771 2021-07-22
US17/867,349 US11876970B2 (en) 2021-07-22 2022-07-18 Non-interleaved separate tree
US17/867,349 2022-07-18
PCT/US2022/073907 WO2023004330A2 (en) 2021-07-22 2022-07-19 Non-interleaved separate tree

Publications (1)

Publication Number Publication Date
JP2024518007A true JP2024518007A (ja) 2024-04-24

Family

ID=84977028

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023525099A Pending JP2024518007A (ja) 2021-07-22 2022-07-19 非インターリーブ分離ツリー

Country Status (5)

Country Link
US (1) US11876970B2 (ja)
EP (1) EP4186233A2 (ja)
JP (1) JP2024518007A (ja)
KR (1) KR20230057420A (ja)
WO (1) WO2023004330A2 (ja)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9538172B2 (en) 2012-04-11 2017-01-03 Qualcomm Incorporated Grouping bypass coded syntax elements in video coding
US10448025B1 (en) 2018-05-11 2019-10-15 Tencent America LLC Method and apparatus for video coding
WO2020005758A1 (en) * 2018-06-29 2020-01-02 Interdigital Vc Holdings, Inc. Wavefront parallel processing of luma and chroma components
EP4344202A2 (en) 2019-08-23 2024-03-27 Huawei Technologies Co., Ltd. An encoder, a decoder and corresponding methods for performing chroma deblocking for blocks which use joint chroma coding

Also Published As

Publication number Publication date
WO2023004330A2 (en) 2023-01-26
US20230026013A1 (en) 2023-01-26
US11876970B2 (en) 2024-01-16
EP4186233A2 (en) 2023-05-31
KR20230057420A (ko) 2023-04-28
WO2023004330A3 (en) 2024-04-04

Similar Documents

Publication Publication Date Title
CN113170102B (zh) 视频编码方法、装置、计算机设备和存储介质
KR20200121904A (ko) 비디오 디코딩을 위한 방법 및 장치
JP2022517114A (ja) ビデオ復号用の方法、装置およびプログラム
JP7244670B2 (ja) デコーダが実行するビデオデコーディングのための方法、装置及び非一時的なコンピュータ可読媒体、並びにエンコーダが実行するビデオエンコーディングのための方法
CN113228649B (zh) 视频解码方法、装置以及存储介质
KR20230129623A (ko) 인트라 예측 모드와 블록 차분 펄스-코드 변조 모드 사이의 상호작용을 위한 방법 및 장치
KR20210138114A (ko) 비디오 코딩 방법 및 장치
JP7236558B2 (ja) ビデオコーディングのための方法および装置
JP2023165926A (ja) ビデオ符号化のための方法、装置、媒体およびコンピュータ・プログラム
JP7267404B2 (ja) ビデオを符号化及び復号する方法、並びにその装置及びコンピュータプログラム
KR20220059550A (ko) 비디오 코딩을 위한 방법 및 장치
JP7478253B2 (ja) デカップリング変換パーティション分割
CN113841390B (zh) 用于视频编解码的方法和设备
JP2023546962A (ja) 成分間のブロック終了フラグの符号化
JP2023525213A (ja) 多重参照ライン選択方式に対する少メモリ設計
KR20220122767A (ko) 비디오 코딩을 위한 방법 및 장치
KR20220091602A (ko) 비디오 디코딩 방법 및 장치, 및 컴퓨터 판독가능 저장 매체
CN113875256B (zh) 进行视频解码的方法、装置及存储介质
JP7490299B2 (ja) スキップ変換フラグ符号化
CN112019844B (zh) 视频解码的方法和装置、计算机设备和存储介质
JP7439344B2 (ja) ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム
JP7478841B2 (ja) デコーダ側イントラモード導出
US11876970B2 (en) Non-interleaved separate tree
AU2020329833B2 (en) Method and apparatus for video coding
JP2023533904A (ja) ゼロ残差フラグコーディング

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230425

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230425

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240513