JP2022525334A - ビデオ符号化及び復号における最小符号化ブロックサイズの範囲 - Google Patents

ビデオ符号化及び復号における最小符号化ブロックサイズの範囲 Download PDF

Info

Publication number
JP2022525334A
JP2022525334A JP2021555306A JP2021555306A JP2022525334A JP 2022525334 A JP2022525334 A JP 2022525334A JP 2021555306 A JP2021555306 A JP 2021555306A JP 2021555306 A JP2021555306 A JP 2021555306A JP 2022525334 A JP2022525334 A JP 2022525334A
Authority
JP
Japan
Prior art keywords
size
coded block
block size
video
ctu
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
JP2021555306A
Other languages
English (en)
Other versions
JP7322171B2 (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 JP2022525334A publication Critical patent/JP2022525334A/ja
Application granted granted Critical
Publication of JP7322171B2 publication Critical patent/JP7322171B2/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/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/12Selection from among a plurality of transforms or standards, e.g. selection between discrete cosine transform [DCT] and sub-band transform or selection between H.263 and H.264
    • H04N19/122Selection of transform size, e.g. 8x8 or 2x4x8 DCT; Selection of sub-band transforms of varying structure or type
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • 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/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/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
    • 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

Landscapes

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

Abstract

ビデオ復号の装置は、符号化ビデオのビットストリームから、パラメータセット又はピクチャヘッダに含まれ且つ最小輝度符号化ブロックサイズを指定する第1のシンタックスエレメントを受信し、最小輝度符号化ブロックサイズが最大許容符号化ツリーユニット(CTU)サイズよりも小さい上限を有する許容最小輝度符号化ブロックサイズの範囲内にあるか否かを検証し、最小輝度符号化ブロックサイズに基づいて、符号化ビデオにおけるパラメータセットを参照するか或いはピクチャヘッダを含む符号化ピクチャを復号するように構成された回路を含む。許容最小輝度符号化ブロックサイズの範囲の上限は、所定の最大許容最小輝度符号化ブロックサイズでもよい。

Description

[関連出願への相互参照]
本開示は、2020年10月23日に出願された米国特許出願第17/078,302号「RANGE OF MINIMUM CODING BLOCK SIZE IN VIDEO CODING」に対する優先権の利益を主張し、当該出願は、2019年10月30日に出願された米国仮出願第62/928,150号「METHODS ON RANGE OF MINIMUM CODING BLOCK 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)のようなより新しい符号化技術で更に改良されている。予測ブロックは、既に利用可能なサンプルに属する隣接するサンプル値を使用して形成できる。隣接サンプルのサンプル値は、方向に従って予測ブロックにコピーされる。使用中の方向への参照は、ビットストリームにおいて符号化でき、或いは、それ自体が予測されてもよい。
方向を表す符号化ビデオビットストリームにおけるイントラ予測方向ビットのマッピングは、ビデオ符号化技術によって異なる可能性があり、例えば、予測方向の簡単な直接マッピングから、イントラ予測モード、コードワード、最確モードを含む複雑な適応方式、及び同様の技術まで及ぶ可能性がある。しかし、全ての場合で、ビデオコンテンツにおいて、特定の他の方向よりも統計的に生じにくい特定の方向が存在し得る。ビデオ圧縮の目標は冗長性の低減であるので、良好に機能するビデオ符号化技術において、これらのより可能性の低い方向は、より可能性の高い方向よりもより多くのビット数によって表される。
動き補償は不可逆圧縮技術であり、前に復元されたピクチャ又はその一部(参照ピクチャ)からのサンプルデータのブロックが、動きベクトル(以下、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)」と呼ばれる技術が存在する。
図1を参照すると、カレントブロック(101)は、動き探索処理中に、空間的にシフトされた同じサイズの前のブロックから予測可能であることがエンコーダによって検出されたサンプルを含む。MVを直接符号化する代わりに、MVは、1つ以上の参照ピクチャに関連するメタデータから導出でき、例えば、A0、A1及びB0、B1、B2(それぞれ102~106)と示される5個の周囲のサンプルのうちいずれか1つに関連するMVを使用して、(復号順で)最近の参照ピクチャから導出できる。H.265では、MV予測は、隣接ブロックが使用しているものと同じ参照ピクチャからの予測子を使用できる。
本開示の態様は、ビデオ符号化/復号の方法及び装置を提供する。いくつかの例では、ビデオ復号の装置は回路を含む。回路は、符号化ビデオのビットストリームから第1のシンタックスエレメントを受信するように構成される。一例では、第1のシンタックスエレメントは、パラメータセット又はピクチャヘッダに含まれ、最小輝度符号化ブロックサイズを指定する。回路は、最小輝度符号化ブロックサイズが最大許容符号化ツリーユニット(CTU, coding tree unit)サイズよりも小さい上限を有する許容最小輝度符号化ブロックサイズの範囲内にあるか否かを検証し、最小輝度符号化ブロックサイズに基づいて、符号化ビデオにおける符号化ピクチャを復号するように更に構成される。一例では、符号化ピクチャは、パラメータセットを参照するか、或いは、ピクチャヘッダを含む。一実施形態では、許容最小輝度符号化ブロックサイズの範囲の上限は、所定の最大許容最小輝度符号化ブロックサイズでもよい。
一実施形態では、回路は、符号化ビデオのビットストリームから第2のシンタックスエレメントを受信するように更に構成される。第2のシンタックスエレメントはCTUサイズを指定し、パラメータセットに含まれてもよい。CTUサイズが所定の最大許容最小輝度符号化ブロックサイズよりも大きい場合、所定の最大許容最小輝度符号化ブロックサイズが、許容最小輝度符号化ブロックサイズの範囲の上限として使用される。CTUサイズが所定の最大許容最小輝度符号化ブロックサイズよりも小さい場合、CTUサイズが、許容最小輝度符号化ブロックサイズの範囲の上限として使用される。
一実施形態では、第1のシンタックスエレメントは、最小輝度符号化ブロックサイズから2を減算した値の2進対数値を示す。回路は、最小輝度符号化ブロックサイズから2を減算した値の2進対数値が0以上N以下の範囲内にあるか否かを検証するように更に構成される。Nは整数であり、N+2は所定の最大許容最小輝度符号化ブロックサイズの2進対数値を表す。
一実施形態では、第1のシンタックスエレメントは、最小輝度符号化ブロックサイズから2を減算した値の2進対数値を示し、回路は、最小輝度符号化ブロックサイズから2を減算した値の2進対数値が0以上Min(N,log2_ctu_size_minus5+3)以下の範囲内にあるか否かを検証するように更に構成される。Nは整数であり、N+2は所定の最大許容最小輝度符号化ブロックサイズの2進対数値を表し、log2_ctu_size_minus5+5は符号化ビデオのCTUサイズの2進対数値を表す。一実施形態では、Nは4に等しい。
一実施形態では、第1のシンタックスエレメントは、最小輝度符号化ブロックサイズから2を減算した値の2進対数値を示し、回路は、最小輝度符号化ブロックサイズの2進対数値がMin(N+2,log2_ctu_size)よりも大きいか否かを検証するように更に構成される。Nは整数であり、N+2は所定の最大許容最小輝度符号化ブロックサイズの2進対数値を表し、log2_ctu_sizeは符号化ビデオのCTUサイズの2進対数値を表す。一実施形態では、Nは4に等しい。
一実施形態では、第1のシンタックスエレメントは、最小輝度符号化ブロックサイズから2を減算した値の2進対数値を示し、回路は、最小輝度符号化ブロックサイズから2を減算した値の2進対数値が0以上log2_ctu_size_minus5+M以下の範囲にあるか否かを検証するように更に構成される。Mは整数であり、log2_ctu_size_minus5+5は符号化ビデオのCTUサイズの2進対数値を表し、log2_ctu_size_minus5+M+2は所定の最大許容最小輝度符号化ブロックサイズの2進対数値を表す。
また、本開示の態様は、ビデオ復号のためにコンピュータによって実行されると、コンピュータにビデオ復号の方法を実行させる非一時的なコンピュータ読み取り可能媒体記憶命令を提供する。
開示の対象物の更なる特徴、性質及び様々な利点は、以下の詳細な説明及び添付の図面からより明らかになる。
一例におけるカレントブロック及びその周囲の空間マージ候補の概略図である。 一実施形態による通信システム(200)の簡略化したブロック図の概略図である。 一実施形態による通信システム(300)の簡略化したブロック図の概略図である。 一実施形態によるデコーダの簡略化したブロック図の概略図である。 一実施形態によるエンコーダの簡略化したブロック図の概略図である。 他の実施形態によるエンコーダのブロック図を示す。 他の実施形態によるデコーダのブロック図を示す。 ピクチャ内の4:2:0輝度及び色差サンプルの垂直位置及び水平位置を示す。 ピクチャ内の4:2:2輝度及び色差サンプルの垂直位置及び水平位置を示す。 ピクチャ内の4:2:4輝度及び色差サンプルの垂直位置及び水平位置を示す。 符号化ツリーユニット(CTU, coding tree unit)に分割されたピクチャの例を示す。 タイル及びラスタスキャンスライスに分割されたピクチャの例を示す。 タイル及び矩形スライスに分割されたピクチャの例を示す。 タイル、ブリック及び矩形スライスに分割されたピクチャの例を示す。 マルチタイプツリー分割モードを示す。 ネスト構造マルチタイプツリーの符号化ツリー構造を有する四分木における分割フラグの伝達を示す。 ネスト構造マルチタイプツリーの符号化ブロック構造を有する四分木の例を示す。 128×128符号化ブロックについて三分木(TT, ternary tree)分割が実行されない例を示す。 二分木分割の場合及び三分木分割の場合の冗長な分割パターンを示す。 許容されないTT分割及び二分木(BT, binary tree)分割の例を示す。 本開示の一実施形態によるプロセス(2100)の概略を示すフローチャートを示す。 一実施形態によるコンピュータシステムの概略図である。
[I.ビデオエンコーダ及びデコーダシステム]
図2は、本開示の一実施形態による通信システム(200)の簡略化したブロック図を示す。通信システム(200)は、例えば、ネットワーク(250)を介して互いに通信できる複数の端末デバイスを含む。例えば、通信システム(200)は、ネットワーク(250)を介して相互接続された第1の対の端末デバイス(210)及び(220)を含む。図2の例では、第1の対の端末デバイス(210)及び(220)は、データの一方向伝送を実行する。例えば、端末デバイス(210)は、ネットワーク(250)を介して他の端末デバイス(220)に送信するために、ビデオデータ(例えば、端末デバイス(210)によってキャプチャされたビデオピクチャのストリーム)を符号化してもよい。符号化されたビデオデータは、1つ以上の符号化ビデオビットストリームの形式で送信されてもよい。端末デバイス(220)は、ネットワーク(250)から符号化ビデオデータを受信し、符号化ビデオデータを復号して、ビデオピクチャを復元して復元されたビデオデータに従ってビデオピクチャを表示してもよい。一方向データ伝送は、メディア提供アプリケーション等において一般的でもよい。
他の例では、通信システム(200)は、例えば、テレビ会議中に発生し得る符号化ビデオデータの双方向伝送を実行する第2の対の端末デバイス(230)及び(240)を含む。データの双方向伝送のために、一例では、端末デバイス(230)及び(240)の各端末デバイスは、ネットワーク(250)を介して端末デバイス(230)及び(240)の他方の端末デバイスに送信するために、ビデオデータ(例えば、端末デバイスによってキャプチャされたビデオピクチャのストリーム)を符号化してもよい。また、端末デバイス(230)及び(240)の各端末デバイスは、端末デバイス(230)及び(240)の他方の端末デバイスによって送信された符号化ビデオデータを受信してもよく、符号化ビデオデータを復号してビデオピクチャを復元してもよく、復元されたビデオデータに従って、アクセス可能な表示デバイスにビデオピクチャを表示してもよい。
図2の例では、端末デバイス(210)、(220)、(230)及び(240)は、サーバ、パーソナルコンピュータ及びスマートフォンとして示されることがあるが、本開示の原理はこれらに限定されない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレイヤ及び/又は専用のテレビ会議機器に適用がある。ネットワーク(250)は、例えば、有線(配線接続)及び/又は無線通信ネットワークを含む、端末デバイス(210)、(220)、(230)及び(240)の間で符号化ビデオデータを伝達するいずれかの数のネットワークを表す。通信ネットワーク(250)は、回線交換チャネル及び/又はパケット交換チャネルにおいてデータを交換してもよい。代表的なネットワークは、電気通信ネットワーク、ローカルエリアネットワーク、広域ネットワーク及び/又はインターネットを含む。本説明の目的では、ネットワーク(250)のアーキテクチャ及びトポロジは、本明細書において以下に説明しない限り、本開示の動作には重要ではない。
図3は、開示の対象物のアプリケーションの例として、ストリーミング環境におけるビデオエンコーダ及びビデオデコーダの配置を示す。開示の対象物は、例えば、テレビ会議、デジタルTV、デジタルメディア(CD、DVD、メモリスティック等を含む)上の圧縮ビデオの記憶等を含む、他のビデオ可能なアプリケーションにも同様に適用可能である。
ストリーミングシステムはキャプチャサブシステム(313)を含んでもよく、当該キャプチャサブシステム(313)は、例えば、非圧縮のビデオピクチャのストリーム(302)を生成するビデオソース(301)(例えば、デジタルカメラ)を含んでもよい。一例では、ビデオピクチャのストリーム(302)は、デジタルカメラによって撮影されたサンプルを含む。符号化ビデオデータ(304)(又は符号化ビデオビットストリーム)と比較したときに高いデータ量であることを強調する太線として描かれるビデオピクチャのストリーム(302)は、ビデオソース(301)に結合されたビデオエンコーダ(303)を含む電子デバイス(320)によって処理されてもよい。ビデオエンコーダ(303)は、以下により詳細に説明するように、開示の対象物の態様を可能にするため或いは実装するために、ハードウェア、ソフトウェア又はこれらの組み合わせを含んでもよい。ビデオピクチャのストリーム(302)と比較したときにより低いデータ量であることを強調するために細線として描かれる符号化ビデオデータ(304)(又は符号化ビデオビットストリーム(304))は、将来の使用のためにストリーミングサーバ(305)に記憶されてもよい。図3におけるクライアントサブシステム(306)及び(308)のような1つ以上のストリーミングクライアントサブシステムは、ストリーミングサーバ(305)にアクセスして符号化ビデオデータ(304)のコピー(307)及び(309)を取得してもよい。クライアントサブシステム(306)は、例えば、電子デバイス(330)内にビデオデコーダ(310)を含んでもよい。ビデオデコーダ(310)は、符号化ビデオデータの入力コピー(307)を復号し、ディスプレイ(312)(例えば、表示画面)又は他のレンダリングデバイス(図示せず)上にレンダリングできるビデオピクチャの出力ストリーム(311)を生成する。いくつかのストリーミングシステムでは、符号化ビデオデータ(304)、(307)及び(309)(例えば、ビデオビットストリーム)は、特定のビデオ符号化/圧縮標準に従って符号化されてもよい。これらの標準の例は、ITU―T勧告H.265を含む。一例では、開発中のビデオ符号化標準は、VVC(Versatile Video Coding)として非公式に知られている。開示の対象物は、VVCの背景において使用されてもよい。
電子デバイス(320)及び(330)は、他の構成要素(図示せず)を含んでもよい点に留意すべきである。例えば、電子デバイス(320)は、ビデオデコーダ(図示せず)を含んでもよく、また、電子デバイス(330)は、ビデオエンコーダ(図示せず)を含んでもよい。
図4は、本開示の一実施形態によるビデオデコーダ(410)のブロック図を示す。ビデオデコーダ(410)は、電子デバイス(430)に含まれてもよい。電子デバイス(430)は、受信機(431)(例えば、受信回路)を含んでもよい。図3の例におけるビデオデコーダ(310)の代わりにビデオデコーダ(410)が使用されてもよい。
受信機(431)は、ビデオデコーダ(410)によって復号されるべき1つ以上の符号化ビデオシーケンスを受信してもよく、同一又は他の実施形態では、一度に1つの符号化ビデオシーケンスを受信してもよく、各符号化ビデオシーケンスの復号は、他の符号化ビデオシーケンスとは独立している。符号化ビデオシーケンスは、チャネル(401)から受信されてもよく、当該チャネルは、符号化ビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクでもよい。受信機(431)は、符号化ビデオデータを、他のデータ(例えば、符号化オーディオデータ及び/又は補助データストリーム)と共に受信してもよく、これらは、それぞれの使用エンティティ(図示せず)に転送されてもよい。受信機(431)は、符号化ビデオシーケンスを他のデータから分離してもよい。ネットワークジッタを防止するために、バッファメモリ(415)は、受信機(431)とエントロピーデコーダ/パーサ(420)(以下、「パーサ(420)」という)との間に結合されてもよい。特定のアプリケーションでは、バッファメモリ(415)はビデオデコーダ(410)の一部である。他の場合には、ビデオデコーダ(410)の外側にあってもよい(図示せず)。更に他の場合には、例えば、ネットワークジッタを防止するために、ビデオデコーダ(410)の外側にバッファメモリ(図示せず)が存在してもよく、加えて、例えば、再生タイミングに対処するために、ビデオデコーダ(410)の内側に他のバッファメモリ(415)が存在してもよい。受信機(431)が、十分な帯域幅及び制御可能性を有する記憶/転送デバイスから、或いは、アイソクロナスネットワークからデータを受信している場合、バッファメモリ(415)は必要なくてもよく或いは小さくすることができる。インターネットのようなベストエフォート型パケットネットワークでの使用については、バッファメモリ(415)が必要とされてもよく、比較的大きくすることができ、有利には適応的なサイズとすることができ、ビデオデコーダ(410)の外側のオペレーティングシステム又は同様の要素(図示せず)に少なくとも部分的に実装されてもよい。
ビデオデコーダ(410)は、符号化ビデオシーケンスからシンボル(421)を復元するためのパーサ(420)を含んでもよい。これらのシンボルのカテゴリは、ビデオデコーダ(410)の動作を管理するために使用される情報を含み、レンダリングデバイス(412)(例えば、表示画面)のようなレンダリングデバイスを制御するための情報を潜在的に含む。当該レンダリングデバイス(412)は、図4に示されているように、電子デバイス(430)の一体的な部分ではないが、電子デバイス(430)に結合されてもよい。レンダリングデバイスの制御情報は、補足エンハンスメント情報(SEI, Supplemental Enhancement Information)(SEIメッセージ)又はビデオユーザビリティ情報(VUI, Video Usability Information)パラメータセットフラグメント(図示せず)の形式でもよい。パーサ(420)は、受信した符号化ビデオシーケンスを解析/エントロピー復号してもよい。符号化ビデオシーケンスの符号化は、ビデオ符号化技術又は標準に従ってもよく、可変長符号化、ハフマン符号化、コンテキスト感度を伴う或いは伴わない算術符号化等を含む様々な原理に従ってもよい。パーサ(420)は、グループに対応する少なくとも1つのパラメータに基づいて、符号化ビデオシーケンスから、ビデオデコーダ内の画素のサブグループのうち少なくとも1つについてのサブグループパラメータのセットを抽出してもよい。サブグループは、グループオブピクチャ(GOP, Group of Picture)、ピクチャ、タイル、スライス、マクロブロック、符号化ユニット(CU, Coding Unit)、ブロック、変換ユニット(TU, Transformation Unit)、予測ユニット(PU, Prediction Unit)等を含んでもよい。また、パーサ(420)は、符号化ビデオシーケンスから、変換係数、量子化パラメータ値、動きベクトル等のような情報を抽出してもよい。
パーサ(420)は、シンボル(421)を生成するために、バッファメモリ(415)から受信したビデオシーケンスに対してエントロピー復号/解析動作を実行してもよい。
シンボル(421)の復元には、符号化ビデオピクチャ又はその部分のタイプ(例えば、インターピクチャ及びイントラピクチャ、インターブロック及びイントラブロック)及び他の要因に依存して、複数の異なるユニットが関与してもよい。どのユニットがどのように関与するかは、パーサ(420)によって符号化ビデオシーケンスから解析されたサブグループ制御情報によって制御されてもよい。パーサ(420)と以下の複数ユニットとの間のこのようなサブグループ制御情報の流れは、明確にするために図示されていない。
上記の機能ブロックの他に、ビデオデコーダ(410)は、概念的に、以下に説明するような複数の機能ユニットに細分されてもよい。商用的な制約の下で動作する実用的な実装では、これらのユニットの多くは互いに密接に相互作用し、少なくとも部分的に互いに統合されてもよい。しかし、開示の対象物を説明する目的で、以下の機能ユニットに概念的に細分することが適切である。
第1のユニットは、スケーラ/逆変換ユニット(451)である。スケーラ/逆変換ユニット(451)は、パーサ(420)からシンボル(421)として、制御情報(どの変換を使用するべきか、ブロックサイズ、量子化係数、量子化スケーリング行列等を含む)と共に、量子化された変換係数を受信する。スケーラ/逆変換ユニット(451)は、アグリゲータ(455)に入力できるサンプル値を含むブロックを出力してもよい。
場合によっては、スケーラ/逆変換(451)の出力サンプルは、イントラ符号化ブロックに関連してもよく、すなわち、前に復元されたピクチャからの予測情報を使用していないが、カレントピクチャの前に復元された部分からの予測情報を使用できるブロックに関連してもよい。このような予測情報は、イントラピクチャ予測ユニット(452)によって提供されてもよい。場合によっては、イントラピクチャ予測ユニット(452)は、カレントピクチャバッファ(458)から取り出された周囲の既に復元された情報を使用して、復元中のブロックの同じサイズ及び形状のブロックを生成する。カレントピクチャバッファ(458)は、例えば、部分的に復元されたカレントピクチャ及び/又は完全に復元されたカレントピクチャをバッファする。場合によっては、アグリゲータ(455)は、サンプル毎に、イントラ予測ユニット(452)が生成した予測情報を、スケーラ/逆変換ユニット(451)によって提供された出力サンプル情報に追加する。
他の場合には、スケーラ/逆変換ユニット(451)の出力サンプルは、インター符号化されて潜在的に動き補償されたブロックに関連してもよい。このような場合、動き補償予測ユニット(453)は、参照ピクチャメモリ(457)にアクセスして、予測に使用されるサンプルを取り出してもよい。ブロックに関連するシンボル(421)に従って、取り出されたサンプルを動き補償した後に、これらのサンプルは、出力サンプル情報を生成するために、アグリゲータ(455)によってスケーラ/逆変換ユニット(451)の出力(この場合には、残差サンプル又は残差信号と呼ばれる)に追加されてもよい。動き補償予測ユニット(453)に利用可能な、動き補償予測ユニット(453)が予測サンプルを取り出す参照ピクチャメモリ(457)内のアドレスは、例えば、X、Y及び参照ピクチャ成分を有することができるシンボル(421)の形式で、動きベクトルによって制御されてもよい。また、動き補償は、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリ(457)から取り出されるサンプル値の補間、動きベクトル予測メカニズム等を含んでもよい。
アグリゲータ(455)の出力サンプルは、ループフィルタユニット(456)内の様々なループフィルタリング技術を受けてもよい。ビデオ圧縮技術はループ内フィルタ技術を含んでもよく、当該ループ内フィルタ技術は、符号化ビデオシーケンス(符号化ビデオビットストリームとも呼ばれる)に含まれるパラメータによって制御され、パーサ(420)からシンボル(421)としてループフィルタユニット(456)に利用可能にされるが、符号化ピクチャ又は符号化ビデオシーケンスの(復号順に)前の部分の復号の間に取得されたメタ情報に応答すると共に、前に復元されてループフィルタリングされたサンプル値にも応答してもよい。
ループフィルタユニット(456)の出力はサンプルストリームでもよく、当該サンプルストリームは、レンダリングデバイス(412)に出力されると共に、将来のインターピクチャ予測に使用するために参照ピクチャメモリ(457)に記憶されてもよい。
特定の符号化ピクチャは、完全に復元されると、将来の予測のための参照ピクチャとして使用されてもよい。例えば、カレントピクチャに対応する符号化ピクチャが完全に復元され、符号化ピクチャが(例えば、パーサ(420)によって)参照ピクチャとして識別されると、カレントピクチャバッファ(458)は参照ピクチャメモリ(457)の一部となってもよく、新たなカレントピクチャバッファが、後続の符号化ピクチャの復元を開始する前に再割り当てされてもよい。
ビデオデコーダ(410)は、ITU―T Rec. H.265のような標準における所定のビデオ圧縮技術に従って復号動作を実行してもよい。符号化ビデオシーケンスがビデオ圧縮技術又は標準のシンタックス及びビデオ圧縮技術又は標準に文書化されているプロファイルの双方に従うという意味で、符号化ビデオシーケンスは、使用されているビデオ圧縮技術又は標準によって指定されたシンタックスに適合してもよい。具体的には、プロファイルは、ビデオ圧縮技術又は標準で利用可能な全てのツールから特定のツールを、そのプロファイルで使用するのに利用可能な唯一のツールとして選択してもよい。また、コンプライアンスのために必要なことは、符号化ビデオシーケンスの複雑さが、ビデオ圧縮技術又は標準のレベルによって定義される範囲内にあることである。場合によっては、レベルは、最大ピクチャサイズ、最大フレームレート、最大復元サンプルレート(例えば、毎秒当たりのメガサンプル単位で測定される)、最大参照ピクチャサイズ等を制限する。場合によっては、レベルによって設定される制限は、仮想参照デコーダ(HRD, Hypothetical Reference Decoder)仕様及び符号化ビデオシーケンスで伝達されるHRDバッファ管理についてのメタデータを通じて更に制限されてもよい。
一実施形態では、受信機(431)は、符号化ビデオと共に更なる(冗長な)データを受信してもよい。更なるデータは、符号化ビデオシーケンスの一部として含まれてもよい。更なるデータは、データを適切に復号するために、及び/又は元のビデオデータをより正確に復元するために、ビデオデコーダ(410)によって使用されてもよい。更なるデータは、例えば、時間、空間又は信号雑音比(SNR, signal noise ratio)エンハンスメント層、冗長スライス、冗長ピクチャ、前方誤り訂正コード等の形式でもよい。
図5は、本開示の一実施形態によるビデオエンコーダ(503)のブロック図を示す。ビデオエンコーダ(503)は、電子デバイス(520)に含まれる。電子デバイス(520)は、送信機(540)(例えば、送信回路)を含む。図3の例におけるビデオエンコーダ(303)の代わりにビデオエンコーダ(503)が使用されてもよい。
ビデオエンコーダ(503)は、ビデオソース(501)(図5の例では電子デバイス(520)の一部ではない)からビデオサンプルを受信してもよく、当該ビデオソース(501)は、ビデオエンコーダ(503)によって符号化されるべきビデオ画像をキャプチャしてもよい。他の例では、ビデオソース(501)は電子デバイス(520)の一部である。
ビデオソース(501)は、デジタルビデオサンプルストリームの形式でビデオエンコーダ(503)によって符号化されるべきソースビデオシーケンスを提供してもよく、当該デジタルビデオサンプルストリームは、いずれかの適切なビット深度(例えば、8ビット、10ビット、12ビット等)、いずれかの色空間(例えば、BT.601 Y CrCB、RGB等)及びいずれかの適切なサンプリング構造(例えば、Y CrCb 4:2:0、Y CrCb 4:4:4)でもよい。メディア提供システムにおいて、ビデオソース(501)は、事前に準備されたビデオを記憶する記憶デバイスでもよい。テレビ会議システムでは、ビデオソース(501)は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラでもよい。ビデオデータは、順に見たときに動きを伝える複数の個々のピクチャとして提供されてもよい。ピクチャ自体は、画素の空間配列として構成されてもよく、各画素は、使用中のサンプリング構造、色空間等に依存して、1つ以上のサンプルを含んでもよい。当業者は、画素とサンプルとの関係を容易に理解することができる。以下の説明は、サンプルに焦点を当てる。
一実施形態によれば、ビデオエンコーダ(503)は、リアルタイムで或いはアプリケーションによって要求されるいずれかの他の時間制約下で、ソースビデオシーケンスのピクチャを、符号化ビデオシーケンス(543)に符号化及び圧縮してもよい。適切な符号化速度を実現することは、コントローラ(550)の1つの機能である。いくつかの実施形態では、コントローラ(550)は、以下に説明するように、他の機能ユニットを制御し、他の機能ユニットに機能的に結合される。結合は、明確にするために図示されていない。コントローラ(550)によって設定されるパラメータは、レート制御関連パラメータ(ピクチャスキップ、量子化、レート歪み最適化技術のラムダ値等)、ピクチャサイズ、グループオブピクチャ(GOP)のレイアウト、最大動きベクトル探索範囲等を含んでもよい。コントローラ(550)は、特定のシステム設計のために最適化されたビデオエンコーダ(503)に関連する他の適切な機能を有するように構成されてもよい。
いくつかの実施形態では、ビデオエンコーダ(503)は、符号化ループで動作するように構成される。非常に簡略化した説明として、一例では、符号化ループは、ソースコーダ(530)(例えば、符号化されるべき入力ピクチャ及び参照ピクチャに基づいて、シンボルストリームのようなシンボルを生成することを担う)と、ビデオエンコーダ(503)に埋め込まれた(ローカル)デコーダ(533)とを含んでもよい。デコーダ(533)は、(リモート)デコーダが生成するのと同様に(シンボルと符号化ビデオビットストリームとの間のいずれかの圧縮が、開示の対象物において検討されるビデオ圧縮技術において可逆であるように)、サンプルデータを生成するようにシンボルを復元する。復元されたサンプルストリーム(サンプルデータ)は、参照ピクチャメモリ(534)に入力される。シンボルストリームの復号は、デコーダの位置(ローカル又はリモート)と独立したビット単位の正確な結果をもたらすので、参照ピクチャメモリ(534)内の内容も、ローカルエンコーダとリモートエンコーダとの間でビット単位で正確である。言い換えると、エンコーダの予測部分は、デコーダが復号中に予測を使用するときに「見る」のと全く同じサンプル値を参照ピクチャサンプルとして「見る」。参照ピクチャの同期(例えば、チャネルエラーの理由で同期が維持できない場合の結果として生じるドリフトを含む)のこの基本原理は、いくつかの関連技術においても同様に使用される。
「ローカル」デコーダ(533)の動作は、ビデオデコーダ(410)のような「リモート」デコーダと同じでもよく、これは、図4に関連して上記において既に詳細に説明した。しかし、図4を簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ(545)及びパーサ(520)による符号化ビデオシーケンスへのシンボルの符号化/復号が可逆になり得るので、バッファメモリ(515)及びパーサ(520)を含むビデオデコーダ(410)のエントロピー復号部分は、ローカルデコーダ(533)に完全には実装されなくてもよい。
この時点で行うことができる考察は、デコーダ内に存在する解析/エントロピー復号を除く如何なるデコーダ技術も、必然的に対応するエンコーダ内に実質的に同一の機能形式で存在する必要があることである。このため、開示の対象物はデコーダ動作に焦点を当てる。エンコーダ技術の説明は、包括的に記載されるデコーダ技術の逆であるので、省略できる。特定の領域においてのみ、より詳細な説明が必要であり、以下に提供される。
いくつかの例では、動作中に、ソースコーダ(530)は、動き補償予測符号化を実行してもよく、当該動き補償予測符号化は、「参照ピクチャ」として指定されたビデオシーケンスからの1つ以上の前に符号化されたピクチャを参照して入力ピクチャを予測的に符号化する。このように、符号化エンジン(532)は、入力ピクチャの画素ブロックと、入力ピクチャに対する予測参照として選択され得る参照ピクチャの画素ブロックとの間の差を符号化する。
ローカルビデオデコーダ(533)は、ソースコーダ(530)によって生成されたシンボルに基づいて、参照ピクチャとして指定され得るピクチャの符号化ビデオデータを復号してもよい。符号化エンジン(532)の動作は、有利には、不可逆処理でもよい。符号化ビデオデータがビデオデコーダ(図5に図示せず)で復号され得る場合、復元されたビデオシーケンスは、典型的には、いくつかのエラーを伴うソースビデオシーケンスのレプリカになり得る。ローカルビデオデコーダ(533)は、参照ピクチャに対してビデオデコーダによって実行され得る復号処理を複製し、復元された参照ピクチャを参照ピクチャキャッシュ(534)に記憶させてもよい。このように、ビデオエンコーダ(503)は、遠端のビデオデコーダによって取得される(送信エラーのない)復元された参照ピクチャとして、共通の内容を有する復元された参照ピクチャのコピーをローカルに記憶してもよい。
予測器(535)は、符号化エンジン(532)のための予測探索を実行してもよい。すなわち、符号化されるべき新たなピクチャについて、予測器(535)は、(候補参照画素ブロックとしての)サンプルデータ又は特定のメタデータ(参照ピクチャ動きベクトル、ブロック形状等)を求めて参照ピクチャメモリ(534)を検索してもよい。これらは、新たなピクチャについての適切な予測参照として機能してもよい。予測器(535)は、適切な予測参照を検出するために、サンプルブロック毎画素ブロック毎(sample block―by―pixel block)に動作してもよい。場合によっては、予測器(535)によって取得された検索結果によって決定された入力ピクチャは、参照ピクチャメモリ(534)に記憶された複数の参照ピクチャから引き出された予測参照を有してもよい。
コントローラ(550)は、例えば、ビデオデータを符号化するために使用されるパラメータ及びサブグループパラメータの設定を含む、ソースコーダ(530)の符号化動作を管理してもよい。
全ての上記の機能ユニットの出力は、エントロピーコーダ(545)におけるエントロピー符号化を受けてもよい。エントロピーコーダ(545)は、ハフマン符号化、可変長符号化、算術符号化等のような技術に従って、シンボルを可逆圧縮することによって、様々な機能ユニットによって生成されたシンボルを符号化ビデオシーケンスに変換する。
送信機(540)は、エントロピーコーダ(545)によって生成された符号化ビデオシーケンスをバッファして、通信チャネル(560)を介した送信の準備をしてもよく、当該通信チャネル(560)は、符号化ビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクでもよい。送信機(540)は、ビデオコーダ(503)からの符号化ビデオデータを、送信されるべき他のデータ(例えば、符号化オーディオデータ及び/又は補助データストリーム(図示せず))とマージしてもよい。
コントローラ(550)は、ビデオエンコーダ(503)の動作を管理してもよい。符号化中に、コントローラ(550)は、各符号化ピクチャに、特定の符号化ピクチャタイプを割り当ててもよい。当該符号化ピクチャタイプは、各ピクチャに適用され得る符号化技術に影響を与えてもよい。例えば、ピクチャは、しばしば、以下のピクチャタイプのうち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つ前に符号化された参照ピクチャを参照して、空間予測又は時間予測を介して予測的に符号化されてもよい。
ビデオエンコーダ(503)は、ITU―T Rec. H.265のような所定のビデオ符号化技術又は標準に従って符号化動作を実行してもよい。その動作において、ビデオエンコーダ(503)は、入力ビデオシーケンスにおける時間的及び空間的冗長性を利用する予測符号化動作を含む様々な圧縮動作を実行してもよい。したがって、符号化ビデオデータは、使用されているビデオ符号化技術又は標準によって指定されたシンタックスに適合してもよい。
一実施形態では、送信機(540)は、符号化ビデオと共に更なるデータを送信してもよい。ソースコーダ(530)は、符号化ビデオシーケンスの一部としてこのようなデータを含んでもよい。更なるデータは、時間/空間/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の画素等のように、画素の値(例えば、輝度値)の行列を含む。
図6は、本開示の他の実施形態によるビデオエンコーダ(603)の図を示す。ビデオエンコーダ(603)は、ビデオピクチャのシーケンス内のカレントビデオピクチャ内のサンプル値の処理ブロック(例えば、予測ブロック)を受信し、処理ブロックを符号化ビデオシーケンスの一部である符号化ピクチャに符号化するように構成される。一例では、ビデオエンコーダ(603)は、図3の例のビデオエンコーダ(303)の代わりに使用される。
HEVCの例では、ビデオエンコーダ(603)は、8×8のサンプルの予測ブロック等のような処理ブロックのサンプル値の行列を受信する。ビデオエンコーダ(603)は、処理ブロックが、例えば、レート歪み最適化を使用して、イントラモードを使用して最も良く符号化されるか、インターモードを使用して最も良く符号化されるか、双方向予測モードを使用して最も良く符号化されるかを決定する。処理ブロックがイントラモードで符号化される場合、ビデオエンコーダ(603)は、処理ブロックを符号化ピクチャに符号化するためにイントラ予測技術を使用してもよい。処理ブロックがインターモード又は双方向予測モードで符号化される場合、ビデオエンコーダ(603)は、処理ブロックを符号化ピクチャに符号化するために、それぞれインター予測技術又は双方向予測技術を使用してもよい。特定のビデオ符号化技術では、マージモード(merge mode)は、動きベクトル予測子以外の符号化された動きベクトル成分の恩恵を受けずに、動きベクトルが1つ以上の動きベクトル予測子から導出されるインターピクチャ予測サブモードでもよい。特定の他のビデオ符号化技術では、対象のブロックに適用可能な動きベクトル成分が存在してもよい。一例では、ビデオエンコーダ(603)は、処理ブロックのモードを決定するためのモード決定モジュール(図示せず)のような他の構成要素を含む。
図6の例では、ビデオエンコーダ(603)は、図6に示されるように共に結合されたインターエンコーダ(630)と、イントラエンコーダ(622)と、残差計算器(623)と、スイッチ(626)と、残差エンコーダ(624)と、全体コントローラ(621)と、エントロピーエンコーダ(625)とを含む。
インターエンコーダ(630)は、カレントブロック(例えば、処理ブロック)のサンプルを受信し、当該ブロックを参照ピクチャ内の1つ以上の参照ブロック(例えば、前のピクチャ及び後のピクチャ内のブロック)と比較し、インター予測情報(例えば、インター符号化技術による冗長情報の記述、動きベクトル、マージモード情報)を生成し、いずれかの適切な技術を使用して、インター予測情報に基づいてインター予測結果(例えば、予測ブロック)を計算するように構成される。いくつかの例では、参照ピクチャは、符号化ビデオ情報に基づいて復号された復号参照ピクチャである。
イントラエンコーダ(622)は、カレントブロック(例えば、処理ブロック)のサンプルを受信し、場合によっては、当該ブロックを、同じピクチャ内で既に符号化されたブロックと比較し、変換後に量子化係数を生成し、場合によっては、イントラ予測情報(例えば、1つ以上のイントラ符号化技術によるイントラ予測方向情報)も生成するように構成される。また、一例では、イントラエンコーダ(622)は、同じピクチャ内のイントラ予測情報及び参照ブロックに基づいて、イントラ予測結果(例えば、予測ブロック)を計算する。
全体コントローラ(621)は、全体制御データを決定し、全体制御データに基づいてビデオエンコーダ(603)の他の構成要素を制御するように構成される。一例では、全体コントローラ(621)は、ブロックのモードを決定し、当該モードに基づいて制御信号をスイッチ(626)に提供する。例えば、モードがイントラモードである場合、全体コントローラ(621)は、残差計算器(623)によって使用されるイントラモード結果を選択するようにスイッチ(626)を制御し、イントラ予測情報を選択してイントラ予測情報をビットストリームに含めるようにエントロピーエンコーダ(625)を制御する。モードがインターモードである場合、全体コントローラ(621)は、残差計算器(623)によって使用されるインター予測結果を選択するようにスイッチ(626)を制御し、インター予測情報を選択してインター予測情報をビットストリームに含めるようにエントロピーエンコーダ(625)を制御する。
残差計算器(623)は、受信したブロックと、イントラエンコーダ(622)又はインターエンコーダ(630)から選択された予測結果との差(残差データ)を計算するように構成される。残差エンコーダ(624)は、残差データに基づいて動作し、残差データを符号化して変換係数を生成するように構成される。一例では、残差エンコーダ(624)は、残差データを空間ドメインから周波数ドメインに変換し、変換係数を生成するように構成される。次いで、変換係数は、量子化された変換係数を取得するための量子化処理を受ける。また、様々な実施形態では、ビデオエンコーダ(603)は、残差デコーダ(628)も含む。残差デコーダ(628)は、逆変換を実行し、復号された残差データを生成するように構成される。復号された残差データは、イントラエンコーダ(622)及びインターエンコーダ(630)によって適切に使用されてもよい。例えば、インターエンコーダ(630)は、復号された残差データ及びインター予測情報に基づいて復号ブロックを生成してもよく、イントラエンコーダ(622)は、復号された残差データ及びイントラ予測情報に基づいて復号ブロックを生成してもよい。復号ブロックは、復号ピクチャを生成するように適切に処理され、復号ピクチャは、メモリ回路(図示せず)にバッファされ、いくつかの例では参照ピクチャとして使用されてもよい。
エントロピーエンコーダ(625)は、符号化ブロックを含めるようにビットストリームをフォーマットするように構成される。エントロピーエンコーダ(625)は、HEVC標準のような適切な標準に従った様々な情報を含めるように構成される。一例では、エントロピーエンコーダ(625)は、全体制御データと、選択された予測情報(例えば、イントラ予測情報又はインター予測情報)と、残差情報と、他の適切な情報とをビットストリームに含めるように構成される。開示の対象物によれば、インターモード又は双方向予測モードのいずれかのマージサブモードでブロックを符号化する場合、残差情報は存在しない点に留意すべきである。
図7は、本開示の他の実施形態によるビデオデコーダ(710)の図を示す。ビデオデコーダ(710)は、符号化ビデオシーケンスの一部である符号化ピクチャを受信し、符号化ピクチャを復号して復元ピクチャを生成するように構成される。一例では、ビデオデコーダ(710)は、図3の例のビデオデコーダ(310)の代わりに使用される。
図7の例では、ビデオデコーダ(710)は、図7に示されるように共に結合されたエントロピーデコーダ(771)と、インターデコーダ(780)と、残差デコーダ(773)と、復元モジュール(774)と、イントラデコーダ(772)とを含む。
エントロピーデコーダ(771)は、符号化ピクチャから、当該符号化ピクチャが構成されるシンタックスエレメントを表す特定のシンボルを復元するように構成されてもよい。このようなシンボルは、例えば、ブロックが符号化されるモード(例えば、イントラモード、インターモード、双方向予測モード、マージサブモード又は他のサブモードにおける後者の2つ等)、それぞれイントラデコーダ(772)又はインターデコーダ(780)によって予測のために使用される特定のサンプル又はメタデータを識別できる予測情報(例えば、イントラ予測情報又はインター予測情報等)、例えば、量子化された変換係数の形式の残差情報等を含んでもよい。一例では、予測モードがインターモード又は双方向予測モードである場合、インター予測情報はインターデコーダ(780)に提供され、予測タイプがイントラ予測タイプである場合には、イントラ予測情報がイントラデコーダ(772)に提供される。残差情報は、逆量子化を受けてもよく、残差デコーダ(773)に提供される。
インターデコーダ(780)は、インター予測情報を受信し、インター予測情報に基づいてインター予測結果を生成するように構成される。
イントラデコーダ(772)は、イントラ予測情報を受信し、イントラ予測情報に基づいて予測結果を生成するように構成される。
残差デコーダ(773)は、逆量子化された変換係数を抽出するための逆量子化を実行し、逆量子化された変換係数を処理して残差を周波数ドメインから空間ドメインに変換するように構成される。また、残差デコーダ(773)は、特定の制御情報(量子化パラメータ(QP, Quantizer Parameter)を含む)を必要としてもよく、その情報は、エントロピーデコーダ(771)によって提供されてもよい(これは低ボリュームの制御情報のみである可能性があるので、データ経路は図示されていない)。
復元モジュール(774)は、空間ドメインにおいて、残差デコーダ(773)によって出力された残差と、予測結果(場合によっては、インター予測モジュール又はイントラ予測モジュールによって出力されたもの)とを結合して復元ブロックを形成するように構成され、当該復元ブロックは、復元ピクチャの一部でもよく、また、復元ビデオの一部でもよい。視覚品質を改善するために、デブッキング動作のような他の適切な動作が実行されてもよい点に留意すべきである。
ビデオエンコーダ(303)、(503)及び(603)並びにビデオデコーダ(310)、(410)及び(710)は、いずれかの適切な技術を使用して実装されてもよい点に留意すべきである。一実施形態では、ビデオエンコーダ(303)、(503)及び(603)並びにビデオデコーダ(310)、(410)及び(710)は、1つ以上の集積回路を使用して実装されてもよい。他の実施形態では、ビデオエンコーダ(303)、(503)及び(603)並びにビデオデコーダ(310)、(410)及び(710)は、ソフトウェア命令を実行する1つ以上のプロセッサを使用して実装されてもよい。
[II.ピクチャフォーマット及びピクチャ分割]
[II.1 ソース、復号及び出力ピクチャフォーマット]
くつかの実施形態では、ソースピクチャと復号ピクチャとの関係は、以下のようにビットストリームを介して与えられる。ビットストリームによって表されるビデオソースは、復号順のピクチャのシーケンスである。ソースピクチャ及び復号ピクチャは、以下の1つ以上のサンプル配列でそれぞれ構成される。
―輝度(Y)のみ(モノクロ)
―輝度及び2つの色差(YCbCr又はYCgCo)
―緑、青及び赤(GBR、RGBとしても知られている)
―他の不特定のモノクロ又は三刺激値のカラーサンプリング(例えば、YZX、XYZとしても知られている)を表す配列。
本開示における表記及び用語の便宜上、これらの配列に関連する変数及び用語は、輝度(又はL若しくはY)及び色差と呼ばれ、2つの色差配列は、使用されている実際の色表現方法にかかわらず、Cb及びCrと呼ばれる。使用される実際の色表現方法は、シンタックスにより示されてもよい。
変数SubWidthC及びSubHeightCは、色差成分サブサンプリング比を示し、色差フォーマットのサンプリング構造に依存して表1で指定される。色差フォーマットのサンプリング構造は、chroma_format_idc及びseparate_color_plane_flagによって指定される。
Figure 2022525334000002
モノクロサンプリングでは、1つのみのサンプル配列が存在し、これは公称上で輝度配列と考えられる。4:2:0サンプリングでは、2つの色差配列のそれぞれは輝度配列の半分の高さ及び半分の幅を有する。4:2:2サンプリングでは、2つの色差配列のそれぞれは輝度配列の同じ高さ及び半分の幅を有する。4:4:4サンプリングでは、separate_color_plane_flagの値に依存して以下が適用される。
―separate_color_plane_flagが0に等しい場合、2つの色差配列のそれぞれは輝度配列と同じ高さ及び幅を有する。
―そうでない場合(separate_color_plane_flagが1に等しい場合)、3つの色平面はモノクロサンプリングピクチャとして別々に処理される。
ビデオシーケンスにおける輝度配列及び色差配列内のサンプルのそれぞれの表現に必要なビット数は、例えば、8以上16以下の範囲でもよく、輝度配列において使用されるビット数は、色差配列において使用されるビット数と異なってもよい。chroma_format_idcの値が1に等しい場合、ピクチャ内の輝度サンプル及び色差サンプルの公称上の垂直及び水平相対位置が図8に示されている。別の色差サンプルの相対位置が、ビデオユーザビリティ情報において示されてもよい。
chroma_format_idcの値が2に等しい場合、色差サンプルは対応する輝度サンプルと同一場所にあり、ピクチャ内の公称上の位置は図9に示される通りである。chroma_format_idcの値が3に等しい場合、全ての配列サンプルは、ピクチャの全ての場合について同一場所にあり、ピクチャ内の公称上の位置は図10に示される通りである。
[II.2 ピクチャ分割]
[II.2.1 CTUへのピクチャの分割]
いくつかの実施形態では、ピクチャは、符号化ツリーユニット(CTU, coding tree unit)のシーケンスに分割される。CTUの概念はHEVCの概念と同様である。3つのサンプル配列を有するピクチャについて、CTUは輝度サンプルのN×Nブロックと色差サンプルの2つの対応するブロックで構成される。図11は、CTUに分割されたピクチャの例を示す。一例では、CTUにおける輝度ブロックの最大許容サイズは128×128である。一例では、輝度変換ブロックの最大サイズは64×64である。
[II.2.2 スライス、タイル及びブリックへのピクチャの分割]
いくつかの実施形態では、ピクチャは、1つ以上のタイル行及び1つ以上のタイル列に分割されてもよい。タイルは、ピクチャの矩形領域をカバーするCTUのシーケンスである。タイルは、1つ以上のブリック(brick)に分割され、ブリックのそれぞれは、タイル内の複数のCTU行で構成される。複数のブリックに分割されないタイルもブリックと呼ばれる。しかし、タイルの真のサブセットであるブリックはタイルと呼ばれない。スライスは、ピクチャの複数のタイル又はタイルの複数のブリックを含む。2つのモードのスライス、すなわち、ラスタスキャンスライスモード及び矩形スライスモードがサポートされている。ラスタスキャンスライスモードでは、スライスは、ピクチャのタイルラスタスキャンにおけるタイルのシーケンスを含む。矩形スライスモードでは、スライスは、ピクチャの矩形領域を併せて形成するピクチャの複数のブリックを含む。矩形スライス内のブリックは、スライスのブリックラスタスキャンの順序にある。
図12は、ピクチャのラスタスキャンスライス分割の例を示しており、ピクチャは12個のタイルと3つのラスタスキャンスライスとに分割される。図13は、ピクチャの矩形スライス分割の例を示しており、ピクチャは24個のタイル(6つのタイル列及び4つのタイル行)と9つの矩形スライスとに分割される。図14は、タイル、ブリック及び矩形スライスに分割されたピクチャの例を示しており、ピクチャは、4つのタイル(2つのタイル列及び2つのタイル行)と、11個のブリック(左上のタイルは1つのブリックを含み、右上のタイルは5つのブリックを含み、左下のタイルは2つのブリックを含み、右下のタイルは3つのブリックを含む)と、4つの矩形スライスとに分割される。
[II.2.3 ツリー構造を使用したCTUの分割]
いくつかの実施形態では、CTUは、様々な局所特性に適応するために、符号化ツリーとして示される四分木構造を使用することによってCUに分割される。ピクチャ領域をインターピクチャ(時間)予測を使用して符号化するか、イントラピクチャ(空間)予測を使用して符号化するかの決定は、リーフCUレベルにおいて行われる。各リーフCUは、PU分割タイプに従って1つのPU、2つのPU又は4つのPUに更に分割されてもよい。1つのPUの中では、同じ予測プロセスが適用され、関連情報がPUベースでデコーダに送信される。PU分割タイプに基づいて予測プロセスを適用することによって残差ブロックを取得した後に、リーフCUは、CUについての符号化ツリーと同様の他の四分木構造に従って変換ユニット(TU, transform unit)に分割されてもよい。HEVC構造の重要な特徴の1つは、CU、PU及びTUを含む複数の分割概念を有することである。
いくつかの実施形態では、二分木及び三分木分割のセグメンテーション構造を使用するネスト構造マルチタイプツリーを有する四分木は、複数の分割ユニットタイプの概念を置き換える。すなわち、最大変換長にとって大きすぎるサイズを有するCUに必要とされる場合を除いて、CU、PU及びTU概念の分離を除去し、CU分割形状についてより高い柔軟性をサポートする。符号化ツリー構造では、CUは正方形又は矩形のいずれかの形を有してもよい。符号化ツリーユニット(CTU, coding tree unit)は、まず、四分木(quadtreeとしても知られる)構造によって分割される。次いで、四分木リーフノードは、マルチタイプツリー構造によって更に分割されてもよい。
図15に示すように、マルチタイプツリー構造には、垂直二分割(SPLIT_BT_VER)、水平二分割(SPLIT_BT_HOR)、垂直三分割(SPLIT_TT_VER)及び水平三分割(SPLIT_TT_HOR)の4つの分割タイプが存在する。マルチタイプツリーのリーフノードは、符号化ユニット(CU, coding unit)と呼ばれ、CUが最大変換長にとって大きすぎない限り、このセグメンテーションは、更なる分割なしに予測及び変換処理に使用される。これは、ほとんどの場合、CU、PU及びTUが、ネスト構造マルチタイプツリーの符号化ブロック構造を有する四分木において同じブロックサイズを有することを意味する。例外は、最大でサポートされる変換長がCUの色成分の幅又は高さよりも小さい場合に生じる。
図16は、ネスト構造マルチタイプツリーの符号化ツリー構造を有する四分木における部分分割情報の伝達メカニズムを示す。符号化ツリーユニット(CTU)は四分木のルートとして扱われ、まず、四分木構造によって分割される。次いで、各四分木リーフノード(十分に大きい場合)は、マルチタイプツリー構造によって更に分割される。マルチタイプツリー構造では、第1のフラグ(mtt_split_cu_flag)は、ノードが更に分割されるか否かを示すために伝達される。ノードが更に分割される場合、第2のフラグ(mtt_split_cu_vertical_flag)は、分割方向を示すために伝達され、次いで、第3のフラグ(mtt_split_cu_binary_flag)は、分割が二分木分割であるか三分木分割であるかを示すために伝達される。mtt_split_cu_vertical_flag及びmtt_split_cu_binary_flagの値に基づいて、表2に示すようにCUのマルチタイプツリー分割モード(MttSplitMode)が導出される。
Figure 2022525334000003
図17は、四分木及びネスト構造マルチタイプツリーの符号化ブロック構造によって複数のCUに分割されたCTUを示す。太字のブロック境界線は四分木分割を表し、残りの境界線はマルチタイプツリー分割を表す。ネスト構造マルチタイプツリー分割を有する四分木は、CUで構成されるコンテンツ適応符号化ツリー構造を提供する。CUのサイズは、CTUと同じ大きさでもよく、或いは、輝度サンプルの単位の4×4ほど小さくてもよい。4:2:0色差フォーマットの場合、最大色差CBサイズは64×64であり、最小色差CBサイズは2×2である。
いくつかの実施形態では、最大でサポートされる輝度変換サイズは64×64であり、最大でサポートされる色差変換サイズは32×32である。CBの幅又は高さが最大変換幅又は高さよりも大きい場合、CBは、その方向の変換サイズの制限を満たすように、自動的に水平方向及び/又は垂直方向に分割される。
いくつかの実施形態では、以下のパラメータが定義され、ネスト構造マルチタイプツリーの符号化ツリー方式を有する四分木についてのシンタックスパラメータセット(SPS, syntax parameter set)シンタックスエレメントによって定義及び指定される。
―CTUサイズ:四分木ルートノードサイズ
―MinQTSize:最小許容四分木リーフノードサイズ
―MaxBtSize:最大許容二分木ルートノードサイズ
―MaxTtSize:最大許容三分木ルートノードサイズ
―MaxMttDepth:四分木リーフからのマルチタイプツリー分割の最大許容階層深さ
―MinBtSize:最小許容二分木リーフノードサイズ
―MinTtSize:最小許容三分木リーフノードサイズ
ネスト構造マルチタイプツリーの符号化ツリー構造を有する四分木の一例では、CTUサイズは4:2:0色差サンプルの2つの対応する64×64ブロックを有する128×128輝度サンプルとして設定され、MinQTSizeは16×16として設定され、MaxBtSizeは128×128として設定され、MaxTtSizeは64×64として設定され、MinBtSize及びMinTtSize(幅及び高さの双方)は4×4として設定され、MaxMttDepthは4として設定される。四分木分割が最初にCTUに適用され、四分木リーフノードを生成する。四分木リーフノードは、16×16(すなわち、MinQTSize)から128×128(すなわち、CTUサイズ)までのサイズを有する。リーフQTノードが128×128である場合、サイズがMaxBtSize及びMaxTtSize(すなわち64×64)を超えるので、二分木によって更に分割されない。そうでない場合、リーフ四分木ノードは、マルチタイプツリーによって更に分割されてもよい。
したがって、四分木リーフノードはマルチタイプツリーのルートノードでもあり、0としてのマルチタイプツリー深さ(mttDepth)を有する。マルチタイプツリー深さがMaxMttDepth(すなわち、4)に達した場合、更なる分割は考慮されない。マルチタイプツリーノードがMinBtSizeに等しく2×MinTtSize以下の幅を有する場合、更なる水平分割は考慮されない。同様に、マルチタイプツリーノードがMinBtSizeに等しく2×MinTtSize以下の高さを有する場合、更なる垂直分割は考慮されない。
いくつかの実施形態では、いくつかのハードウェアデコーダにおいて64×64輝度ブロック及び32×32色差パイプライン設計を可能にするために、図18に示すように、輝度符号化ブロックの幅又は高さのいずれかが64よりも大きい場合、TT分割は禁止される。色差符号化ブロックの幅又は高さのいずれかが32よりも大きい場合も、TT分割は禁止される。
いくつかの実施形態では、符号化ツリー方式は、輝度及び色差が別個のブロックツリー構造を有する能力をサポートする。例えば、Pスライス及びBスライスについて、1つのCTU内の輝度CTB及び色差CTBは同じ符号化ツリー構造を共有してもよい。しかし、Iスライスについては、輝度及び色差は別個のブロックツリー構造を有してもよい。別個のブロックツリーモードが適用される場合、輝度CTBは或る符号化ツリー構造によってCUに分割され、色差CTBは他の符号化ツリー構造によって色差CUに分割される。これは、Iスライス内のCUが輝度成分の符号化ブロック又は2つの色差成分の符号化ブロックで構成されてもよく、Pスライス又はBスライス内のCUが、ビデオがモノクロでない限り、常に全ての3つの色成分の符号化ブロックで構成されることを意味する。
[II.2.4 ピクチャ境界に対するCU分割]
いくつかの実施形態では、ツリーノードブロックの一部が下側又は右側ピクチャ境界を超える場合、ツリーノードブロックは、各符号化CUの全てのサンプルがピクチャ境界内に位置するまで、強制的に分割される。いくつかの実施形態では、以下の分割規則が適用される。
ツリーノードブロックの一部が下側及び右側ピクチャ境界の双方を超える場合、(i)ブロックがQTノードであり、ブロックのサイズが最小QTサイズよりも大きい場合、ブロックはQT分割モードで強制的に分割される。そうでない場合は、ブロックはSPLIT_BT_HORモードで強制的に分割される。
(ii)そうでなく、ツリーノードブロックの一部が下側ピクチャ境界を超える場合、
―ブロックがQTノードであり、ブロックのサイズが最小QTサイズよりも大きく、ブロックのサイズが最大BTサイズよりも大きい場合、ブロックはQT分割モードで強制的に分割される。
―そうでなく、ブロックがQTノードであり、ブロックのサイズが最小QTサイズよりも大きく、ブロックのサイズが最大BTサイズ以下である場合、ブロックはQT分割モード又はSPLIT_BT_HORモードで強制的に分割される。
―そうでない場合(ブロックがBTTノードである場合、又はブロックのサイズが最小QTサイズ以下である場合)、ブロックはSPLIT_BT_HORモードで強制的に分割される。
(iii)そうでなく、ツリーノードブロックの一部が右側ピクチャ境界を超える場合、
―ブロックがQTノードであり、ブロックのサイズが最小QTサイズよりも大きく、ブロックのサイズが最大BTサイズよりも大きい場合、ブロックはQT分割モードで強制的に分割される。
―そうでなく、ブロックがQTノードであり、ブロックのサイズが最小QTサイズよりも大きく、ブロックのサイズが最大BTサイズ以下である場合、ブロックはQT分割モード又はSPLIT_BT_VERモードで強制的に分割される。
―そうでない場合(ブロックがBTTノードである場合、又はブロックのサイズが最小QTサイズ以下である場合)、ブロックはSPLIT_BT_VERモードで強制的に分割される。
[II.2.5 冗長なCU分割に対する制限]
ネスト構造マルチタイプツリーの符号化ブロック構造を有する四分木は、非常に柔軟なブロック分割構造を提供する。マルチタイプツリーをサポートした分割のタイプのため、異なる分割パターンは、潜在的に同じ符号化ブロック構造を生じる可能性がある。いくつかの実施形態では、これらの冗長な分割パターンのうちいくつかは許容されない。
図19は、二分木分割及び三分木分割の冗長な分割パターンを示す。図示のように、一方向における2つのレベルの連続した二分木分割は、三分木分割に続く中央部分の二分木分割と同じ符号化ブロック構造を有し得る。この場合、三分木分割の中央部分についての二分木分割(所与の方向)は、シンタックスによって禁止される。この制限は、全てのピクチャのCUに適用される。
上記のように分割が禁止される場合、禁止された場合を考慮するために、対応するシンタックスエレメントの伝達が変更される。例えば、図19におけるいずれかの場合が識別された場合(すなわち、中央部分のCUについて二分木分割が禁止される場合)、分割が二分木分割であるか三分木分割であるかを指定するシンタックスエレメントmtt_split_cu_binary_flagは伝達されず、デコーダによって0に等しいと推定される。
[II.2.6 仮想パイプラインデータユニット(VPDU)]
いくつかの実施形態では、仮想パイプラインデータユニット(VPDU, virtual pipeline data unit)が使用される。VPDUは、ピクチャにおける重複しないユニットとして定義される。ハードウェアデコーダでは、連続するVPDUが複数のパイプライン段によって同時に処理される。VPDUサイズはほとんどのパイプライン段においてバッファサイズにほぼ比例するので、VPDUサイズを小さく保持することが重要である。いくつかのハードウェアデコーダでは、VPDUサイズは最大変換ブロック(TB, transport block)サイズに設定されてもよい。しかし、いくつかのシナリオでは、三分木(TT, ternary tree)分割及び二分木(BT, binary tree)分割はVPDUサイズの増加をもたらす可能性がある。
いくつかの例では、VPDUサイズを64×64輝度サンプルとして保持するために、図20に示すように、以下の標準的な分割制限(シンタックス伝達の変更を伴う)が適用される。幅若しくは高さ又は幅及び高さの双方が128に等しいCUについて、TT分割は許容されない。128×N(N≦64)のCU(すなわち、幅が128に等しく高さが128よりも小さい)について、水平BTは許容されない。N×128(N≦64)のCU(すなわち、高さが128に等しく幅が128よりも小さい)について、垂直BTは許容されない。
[II.2.7 イントラ色差分割及び予測の制限]
イントラピクチャにおけるデュアルツリー(dual tree)は、輝度符号化ツリーと比較して色差符号化ツリーで異なる分割を適用することが可能であるので、デュアルツリーでは、より長い符号化パイプライン及びQTBTのMinQTSizeC値の範囲を導入し、色差ツリーにおけるMinBtSizeY及びMinTTSizeYは、2×2、4×2及び2×4のような小さい色差ブロックを許容する。これは、デコーダ設計において困難を生じさせる。さらに、CCLM、プラナー及び角度モードのようないくつかの予測モードは乗算を必要とする。上記の問題を緩和するために、いくつかの実施形態では、小さい色差ブロックサイズ(2×2/2×4/4×2)は、分割制限としてデュアルツリーにおいて制限される。
典型的なハードウェアビデオエンコーダ及びデコーダでは、隣接するイントラブロックの間のサンプル処理データ依存性のため、ピクチャがより小さいイントラブロックを有する場合に処理スループットが低下する。イントラブロックの予測子生成は、隣接ブロックからの上側及び左側境界の復元サンプルを必要とする。したがって、イントラ予測はブロック毎に順次処理されなければならない。
いくつかの符号化技術では、最小イントラCUは8×8輝度サンプルである。最小イントラCUの輝度成分は、4つの4×4輝度イントラ予測ユニット(PU, prediction unit)に更に分割されてもよいが、最小イントラCUの色差成分は更に分割されなくてもよい。したがって、最悪の場合のハードウェア処理スループットは、4×4色差イントラブロック又は4×4輝度イントラブロックが処理されるときに発生する。
いくつかの実施形態では、最悪の場合のスループットを改善するために、色差イントラCBの分割を制限することによって、16個の色差サンプルよりも小さい色差イントラCBは許容されない。単一の符号化ツリーにおいて、最小色差イントラ予測ユニット(SCIPU, smallest chroma intra prediction unit)は、色差ブロックサイズが16個の色差サンプル以上であり、64個の輝度サンプルよりも小さい少なくとも1つの子輝度ブロックを有する符号化ツリーノードとして定義される。各SCIPUにおいて、全てのCBはインターであるか或いは全てのCBは非インターであり、すなわち、イントラ又はイントラブロックコピー(IBC, intra block copy)であることが必要とされる。非インターSCIPUの場合、非インターSCIPUの色差が更に分割されず、SCIPUの輝度が更に分割されることが許容されることが更に必要とされる。このように、最小色差イントラCBサイズは16個の色差サンプルであり、2×2、2×4及び4×2の色差CBが除去される。
さらに、色差スケーリングは、非インターSCIPUの場合に適用されない。ここでは、更なるシンタックスは伝達されず、SCIPUが非インターであるか否かは、SCIPUにおける最初の輝度CBの予測モードによって導出されてもよい。SCIPUのタイプは、カレントスライスがIスライスである場合、又はカレントSCIPUが1回の更なる分割の後に4×4輝度部分を有する場合(VVCではインター4×4が許容されないため)、非インターであると推定される。そうでない場合、SCIPUのタイプ(インター又は非インター)は、SCIPUにおけるCUを解析する前に、1つのフラグによって示される。さらに、ピクチャ幅及び高さをmax(8,MinCbSizeY)の倍数とみなすことで、ピクチャの角における2×2/2×4/4×2イントラ色差ブロックを回避するようにピクチャサイズの制限が考慮される。
[II.3 SPSにおける分割及びブロックサイズに関連するシンタックス]
表3はSPSシンタックステーブルの例である。
Figure 2022525334000004
[II.4 分割及びブロックサイズに関連する意味]
例として、分割及びブロックサイズに関連するいくつかのシンタックスエレメントの意味について以下に説明する。例えば、シンタックスエレメントはSPSに含まれ、SPSを参照してピクチャに適用されてもよい。
1に等しいqtbtt_dual_tree_intra_flagは、Iスライスについて各CTUが暗示的な四分木分割を使用して64×64輝度サンプルを有する符号化ユニットに分割され、これらの符号化ユニットが輝度及び色差について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の値の範囲は、0以上log2_ctu_size_minus5+3以下の範囲とする。
変数MinCbLog2SizeY、MinCbSizeY、IbcBufWidthY、IbcBufWidthC及びVsizeは、以下のように導出される。
MinCbLog2SizeY=log2_min_luma_coding_block_size_minus2+2 (式2―1)
MinCbSizeY=1<<MinCbLog2SizeY (式2―2)
IbcBufWidthY=256*128/CtbSizeY (式2―3)
IbcBufWidthC=IbcBufWidthY/SubWidthC (式2―4)
VSize=Min(64,CtbSizeY) (式2―5)
MinCbSizeYの値はVSize以下とする。
各色差CTBについての配列の幅及び高さを指定する変数CtbWidthC及びCtbHeightCは、以下のように導出される。
―chroma_format_idcが0に等しい場合(モノクロ)、又はseparate_color_plane_flagが1に等しい場合、CtbWidthC及びCtbHeightCは共に0に等しい。
―そうでない場合、CtbWidthC及びCtbHeightCは以下のように導出される。
CtbWidthC=CtbSizeY/SubWidthC (式2―6)
CtbHeightC=CtbSizeY/SubHeightC (式2―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内の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の四分木分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズの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の四分木分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数は、以下のように導出される。
MinQtLog2SizeIntraY=sps_log2_diff_min_qt_min_cb_intra_slice_luma+MinCbLog2SizeY (式2―8)
sps_log2_diff_min_qt_min_cb_inter_sliceは、CTUの四分木分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズの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の四分木分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数は、以下のように導出される。
MinQtLog2SizeInterY=sps_log2_diff_min_qt_min_cb_inter_slice+MinCbLog2SizeY (式2―9)
sps_max_mtt_hierarchy_depth_inter_sliceは、SPSを参照してslice_typeが0(B)又は1(P)に等しいスライス内の四分木リーフのマルチタイプツリー分割から生じる符号化ユニットについてのデフォルト最大階層深さを指定する。partition_constraints_override_enabled_flagが1に等しい場合、デフォルト最大階層深さは、SPSを参照するピクチャヘッダ(PH, picture header)に存在する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)に等しいスライス内の四分木リーフのマルチタイプツリー分割から生じる符号化ユニットについてのデフォルト最大階層深さを指定する。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の四分木分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズ(幅又は高さ)との間のデフォルト差を指定する。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の四分木分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズ(幅又は高さ)との間のデフォルト差を指定する。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の四分木分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズ(幅又は高さ)との間のデフォルト差を指定する。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の四分木分割から生じる輝度リーフブロックの輝度サンプルにおける最小サイズ(幅又は高さ)との間のデフォルト差を指定する。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の四分木分割から生じる色差リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数は以下のように導出される。
MinQtLog2SizeIntraC=sps_log2_diff_min_qt_min_cb_intra_slice_chroma+MinCbLog2SizeY (式2―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の四分木分割から生じる色差リーフブロックの輝度サンプルにおける最小サイズ(幅又は高さ)との間のデフォルト差を指定する。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 (式2―11)
MaxTbLog2SizeY=sps_max_luma_transform_size_64_flag?6:5 (式2―12)
MinTbSizeY=1<<MinTbLog2SizeY (式2―13)
MaxTbSizeY=1<<MaxTbLog2SizeY (式2―14)
pic_log2_diff_min_qt_min_cb_intra_slice_chromaは、treeTypeがDUAL_TREE_CHROMAに等しい色差CTUの四分木分割から生じる色差リーフブロックの輝度サンプルにおける最小サイズの2を底とする対数と、PHに関連してslice_typeが2(I)に等しいスライス内のtreeTypeがDUAL_TREE_CHROMAに等しい色差CUの輝度サンプルにおける最小符号化ブロックサイズの2の底とする対数との差を指定する。pic_log2_diff_min_qt_min_cb_intra_slice_chromaの値は、0以上CtbLog2SizeY―MinCbLog2SizeYの範囲とする。存在しない場合、pic_log2_diff_min_qt_min_cb_intra_slice_chromaの値は、sps_log2_diff_min_qt_min_cb_intra_slice_chromaと等しいと推定される。
slice_typeは、表4に従ってスライスの符号化タイプを指定する。
Figure 2022525334000005
nal_unit_typeがIDR_W_RADL以上CRA_NUT以下の範囲のnal_unit_typeの値であり、カレントピクチャがアクセスユニット内の最初のピクチャである場合、slice_typeは2に等しいとする。
変数MinQtLog2SizeY、MinQtLog2SizeC、MinQtSizeY、MinQtSizeC、MaxBtSizeY、MaxBtSizeC、MinBtSizeY、MaxTtSizeY、MaxTtSizeC、MinTtSizeY、MaxMttDepthY及びMaxMttDepthCは以下のように導出される。
MinQtSizeY=1<<MinQtLog2SizeY (式2―15)
MinQtSizeC=1<<MinQtLog2SizeC (式2―16)
MinBtSizeY=1<<MinCbLog2SizeY (式2―17)
MinTtSizeY=1<<MinCbLog2SizeY (式2―18)
(i)slice_typeが2(I)に等しい場合、以下の通りである。
MinQtLog2SizeY=MinCbLog2SizeY+pic_log2_diff_min_qt_min_cb_intra_slice_luma (式2―19)
MinQtLog2SizeC=MinCbLog2SizeC+pic_log2_diff_min_qt_min_cb_intra_slice_chroma (式2―20)
MaxBtSizeY=1<<(MinQtLog2SizeY+pic_log2_diff_max_bt_min_qt_intra_slice_luma) (式2―21)
MaxBtSizeC=1<<(MinQtLog2SizeC+pic_log2_diff_max_bt_min_qt_intra_slice_chroma) (式2―22)
MaxTtSizeY=1<<(MinQtLog2SizeY+pic_log2_diff_max_tt_min_qt_intra_slice_luma) (式2―23)
MaxTtSizeC=1<<(MinQtLog2SizeC+pic_log2_diff_max_tt_min_qt_intra_slice_chroma) (式2―24)
MaxMttDepthY=pic_max_mtt_hierarchy_depth_intra_slice_luma (式2―25)
MaxMttDepthC=pic_max_mtt_hierarchy_depth_intra_slice_chroma (式2―26)
CuQpDeltaSubdiv=pic_cu_qp_delta_subdiv_intra_slice (式2―93)
CuChromaQpOffsetSubdiv=pic_cu_chroma_qp_offset_subdiv_intra_slice (式2―27)
(ii)そうでない場合(slice_typeが0(B)又は1(P)に等しい場合)、以下の通りである。
MinQtLog2SizeY=MinCbLog2SizeY+pic_log2_diff_min_qt_min_cb_inter_slice (式2―29)
MinQtLog2SizeC=MinCbLog2SizeC+pic_log2_diff_min_qt_min_cb_inter_slice (式2―29)
MaxBtSizeY=1<<(MinQtLog2SizeY+pic_log2_diff_max_bt_min_qt_inter_slice) (式2―30)
MaxBtSizeC=1<<(MinQtLog2SizeC+pic_log2_diff_max_bt_min_qt_inter_slice) (式2―31)
MaxTtSizeY=1<<(MinQtLog2SizeY+pic_log2_diff_max_tt_min_qt_inter_slice) (式2―32)
MaxTtSizeC=1<<(MinQtLog2SizeC+pic_log2_diff_max_tt_min_qt_inter_slice) (式2―33)
MaxMttDepthY=pic_max_mtt_hierarchy_depth_inter_slice (式2―34)
MaxMttDepthC=pic_max_mtt_hierarchy_depth_inter_slice (式2―35)
CuQpDeltaSubdiv=pic_cu_qp_delta_subdiv_inter_slice (式2―36)
CuChromaQpOffsetSubdiv=pic_cu_chroma_qp_offset_subdiv_inter_slice (式2―37)
[II.5 2×Nのサイズでの色差イントラ予測の無効化]
いくつかの実施形態では、2×N色差イントラブロックは、デュアルツリー及びシングルツリーの双方において除去される。p方式は以下のように表される。
[II.5.1 デュアルツリーにおける2×Nの制限]
デュアルツリーにおいて、以前に提案されたように、いくつかの分割を無効にすることによって、2×Nイントラ色差が制限される。特に、それぞれ4及び8の幅を有するブロックについて二分木分割及び三分木分割が禁止される。
[II.5.2 シングルツリーにおける2×Nの制限]
シングルツリーにおいて2×Nを除去するために、ローカルデュアルツリーの拡張と色差2×NについてのCIIPの制限とを含む2つの制限が提案される。
第1の制限において、4の幅での分割であり分割が二分木垂直分割である場合、又は8の幅であり分割が三分木垂直分割である場合、これはSCIPUとして扱われる。SCIPUの原理の制限に従って、色差成分は、イントラSCIPUにおいて分割されない(全ての輝度ブロックは非インターモードを使用して符号化され、非分割色差ブロックはイントラモードを使用して符号化される)。インターSCIPU(全ての輝度ブロック及び色差ブロックはインターモードを使用して符号化される)について、色差成分の分割は輝度成分から継承される。
第2の制限において、4×NのCIIPブロックについて、組み合わせイントラ・インター予測は輝度成分にのみ使用され、インター予測は色差成分にのみ使用される。
提案の制限は、イントラ色差ブロックの幅が常に4以上であることを確保し、したがって、2×N画素のイントラプロセスが除去されることを強調する。この制限は、パイプライン管理及び待ち時間の点で、ハードウェア実装のためのビデオコーデックの実装をフレンドリにする。
[III.最小輝度符号化ブロックサイズの範囲]
いくつかの実施形態では、最小輝度符号化ブロックサイズは、4個以上128個以下の輝度サンプルの範囲でもよい。例えば、B. Bross, J. Chen, S. Liu, Y.―K. Wang, “Versatile Video Coding (Draft 7)”, ISO/IEC JTC1/SC29/WG11 JVET―P2001, Oct. 2019に記載のように、log2_min_luma_coding_block_size_minus2によって示されるSPSレベルのシンタックスエレメントは、最小輝度符号化ブロックサイズを指定するために伝達されてもよい。log2_min_luma_coding_block_size_minus2に2を加算した値は、最小輝度符号化ブロックサイズの2を底とする対数(log2)の値を指定する。log2_min_luma_coding_block_size_minus2の値の範囲は、0以上log2_ctu_size_minus5+3以下の範囲とする。
シンタックスエレメントlog2_ctu_size_minus5(又はSPSに含まれる場合は他の形式のsps_log2_ctu_size_minus5)は、各CTUの輝度符号化ツリーブロックサイズ(すなわち、CTUサイズ)を指定する他のSPSレベルのシンタックスエレメントでもよい。sps_log2_ctu_size_minus5に5を加算した値は、各CTUの輝度符号化ツリーブロックサイズのlog2値を指定する。sps_log2_ctu_size_minus5の値が2以下であることはビットストリーム適合要件である。言い換えると、各CTUの輝度符号化ツリーブロックサイズのlog2値は、5~7の範囲である。したがって、各CTUの輝度符号化ツリーブロックのサイズは32(25)個以上128(27)個以下の輝度サンプルの範囲にある。
log2_min_luma_coding_block_size_minus2の値の範囲は、0以上log2_ctu_size_minus5+3以下の範囲とするので、最小輝度符号化ブロックサイズは、4から32~128個の輝度サンプルである輝度符号化ツリーブロックサイズの範囲となり得る。
一例として、輝度符号化ツリーブロックのサイズが128であると伝達された場合、エンコーダは、最小輝度符号化ブロックサイズとして128を使用することを決定することが可能になる。このような大きいブロックサイズが使用される場合、ピクチャ内の局所領域の特性をキャプチャするために、より小さいCUに分割することは許容できず、これは高速の復号速度をもたらす可能性があるが、デコーダ側で復号されたビデオシーケンスのより低い品質というコストをもたらす可能性がある。
本開示は、過度に大きい最小輝度符号化ブロックサイズによって引き起こされる低品質の問題を解決するための解決策を提供する。
[III.1 最小輝度符号化ブロックサイズの上限の制限]
いくつかの実施形態では、最小輝度符号化ブロックサイズの範囲の上限は、最小輝度符号化ブロックサイズを制限する特定の値になるように定義される。例えば、許容最小輝度符号化ブロックサイズは、4個以上64個以下の輝度サンプル又は4個以上32個以下の輝度サンプルの範囲に制限されてもよい。
[実施形態A]
一実施形態では、ビデオ符号化標準(例えば、VVC、HEVC等)で指定されたビットストリーム適合要件として、ビットストリームで伝達される最小輝度符号化ブロックサイズは、4~(1<<(N+2))個の輝度サンプルの範囲(22~2N+2の範囲と等価である)であることが必要とされる。したがって、最小輝度符号化ブロックサイズのlog2値は2~N+2の範囲であり、最小輝度符号化ブロックサイズから2を減算した値のlog2値は0~Nの範囲である。Nは0、1、2、3、4等のような整数でもよい。数Nを指定することにより、最小輝度符号化ブロックサイズの範囲の上限が指定できる。
一例として、log2_min_luma_coding_block_size_minus2によって示されるシンタックスエレメントは、最小輝度符号化ブロックサイズを示すために、パラメータセット(例えば、SPS)で伝達されてもよい。意味は以下のように指定されてもよい。
―log2_min_luma_coding_block_size_minus2に2を加算した値は、最小輝度符号化ブロックサイズを指定する。log2_min_luma_coding_block_size_minus2の値の範囲は0以上N以下の範囲とする。
―変数MinCbLog2SizeY及びMinCbSizeYは以下のように導出されてもよい。
MinCbLog2SizeY=log2_min_luma_coding_block_size_minus2+2 (式3―1)
MinCbSizeY=1<<MinCbLog2SizeY (式3―2)
ここで、MinCbLog2SizeYは最小輝度符号化ブロックサイズのlog2値を表し、MinCbSizeYは輝度サンプルにおける最小輝度符号化ブロックサイズを表す。
Nは、0、1、2、3、4等のような整数でもよい。Nが0に等しい場合、最小輝度符号化ブロックサイズは4個の輝度サンプルのサイズに固定される。Nが4に等しい場合、最小輝度符号化ブロックサイズは4~64(1<<(4+2))個の輝度サンプルの範囲に制限される。Nが3に等しい場合、最小輝度符号化ブロックサイズは4~32(1<<(3+2))個の輝度サンプルの範囲に制限される。
一実施形態では、log2_min_luma_coding_block_size_minus2は、固定長符号化で伝達されてもよい。Nが1に等しい場合、1ビットの固定長符号化が使用されてもよい。Nが2又は3に等しい場合、2ビットの固定長符号化が使用されてもよい。他の実施形態では、他の符号化方式が使用されてもよい。
[実施形態B]
上記の実施形態Aでは、最小輝度ブロックサイズの範囲の上限を2N+2として定義するために、整数Nが使用される。Nが0、1、2、3又は4の値をとる場合、最大許容最小輝度ブロックサイズは、それぞれ4、8、16、32及び64とすることができる。2N+2よりも大きいCTUサイズ(例えば、128)がパラメータセット(例えば、SPS)で伝達された場合、最小輝度ブロックサイズの範囲を制限するために上限2N+2が使用される。2N+2よりも小さいCTUサイズが、パラメータセット(例えば、SPS)で伝達された場合(例えば、N=4であり、2N+2=64であるときに32個の輝度サンプルのCTUサイズが伝達された場合)、このCTUサイズは、最小輝度ブロックサイズの上限になる。したがって、実施形態Aの等価なものは、最小輝度ブロックサイズが0~min(2N+2,CTUサイズ)の範囲内になるように制限されることである。2N+2及びCTUサイズのうち小さい方の値が最小輝度ブロックサイズの上限として使用される。
したがって、他の実施形態では、ビデオ符号化標準で指定されたビットストリーム適合要件として、ビットストリームで伝達される最小輝度符号化ブロックサイズは、4~min((1<<(N+2)),CTUサイズ)個の輝度サンプルの範囲(22~min(2N+2,2CTUサイズのlog2値)の範囲と等価である)であることが必要とされる。したがって、最小輝度符号化ブロックサイズのlog2値は、2~min(N+2,CTUサイズのlog2値)の範囲である。Nは、0、1、2、3、4等のような整数でもよい。数Nを指定することにより、最小輝度符号化ブロックサイズの範囲の上限が指定できる。
一例として、log2_min_luma_coding_block_size_minus2によって示されるシンタックスエレメントは、最小輝度符号化ブロックサイズを示すために、パラメータセット(例えば、SPS)で伝達されてもよい。意味は以下のように指定されてもよい。
―log2_min_luma_coding_block_size_minus2に2を加算した値は、最小輝度符号化ブロックサイズを指定する。log2_min_luma_coding_block_size_minus2の値の範囲は0以上min(N,sps_log2_ctu_size_minus5+3)以下の範囲とする。シンタックスエレメントsps_log2_ctu_size_minus5は、同じパラメータセットで伝達され、CTUサイズから5を減算した値のlog2値を示してもよい。
Nは、0、1、2、3、4等のような整数でもよい。第1の場合では、Nが0に等しい場合、最小輝度符号化ブロックサイズは4個の輝度サンプルのサイズに固定される。第2の場合では、Nが4に等しい場合、最小輝度符号化ブロックサイズは4~min(64,CTUサイズ)個の輝度サンプルの範囲に制限される。CTUサイズが128個の輝度サンプルであることが伝達された場合、最小輝度符号化ブロックサイズは4~64個の輝度サンプルの範囲に制限される。CTUサイズが32個の輝度サンプルであることが伝達された場合、最小輝度符号化ブロックサイズは4~32個の輝度サンプルの範囲に制限される。
[実施形態C]
一実施形態では、デコーダは、ビットストリームで伝達された最小輝度符号化ブロックサイズが復号プロセス中にビットストリーム適合要件を満たすか否かを検証するように構成されてもよい。例えば、デコーダは、まず、ビットストリームから最小輝度符号化ブロックサイズを指定するシンタックスエレメントを受信してもよい。例えば、シンタックスエレメントは、最小輝度符号化ブロックサイズから2を減算した値のlog2値を提供する。log2値は、本開示において2進対数値又は2を底とする対数値とも呼ばれてもよい。
次いで、デコーダは、最小輝度符号化ブロックサイズから2を減算した値の2進対数値が、0以上N以下の範囲内にあるか否かを検証してもよい。Nは0、1、2、4等のような整数であり、N+2は所定の最大許容最小輝度符号化ブロックサイズの2進対数値を表す。一例では、最小輝度符号化ブロックサイズから2を減算した値の2進対数値がNよりも大きい場合、デコーダは、ビットストリーム適合要件が満たされないと決定してもよく、復号プロセスを終了し及び/又はエラーメッセージを出力してもよい。最小輝度符号化ブロックサイズから2を減算した値の2進対数値が0~Nの範囲内にあると決定された場合、デコーダは復号プロセスを続けてもよい。
[実施形態D]
一実施形態では、デコーダは、ビットストリームで伝達された最小輝度符号化ブロックサイズが復号プロセス中にビットストリーム適合要件を満たすか否かを検証するように構成されてもよい。例えば、デコーダは、ビットストリームから最小輝度符号化ブロックサイズを指定する第1のシンタックスエレメントを受信してもよい。デコーダは、第1のシンタックスエレメントの前又は後に、ビットストリームからCTUサイズを指定する第2のシンタックスエレメントを受信してもよい。
次いで、デコーダは、最小輝度符号化ブロックサイズが許容最小輝度符号化ブロックサイズの範囲内にあるか否かを検証してもよい。CTUサイズが所定の最大許容最小輝度符号化ブロックサイズよりも大きい場合、所定の最大許容最小輝度符号化ブロックサイズが、許容最小輝度符号化ブロックサイズの範囲の上限として使用される。CTUサイズが所定の最大許容最小輝度符号化ブロックサイズよりも小さい場合、CTUサイズが、許容最小輝度符号化ブロックサイズの範囲の上限として使用される。
最小輝度符号化ブロックサイズが許容最小輝度符号化ブロックサイズの範囲内にある場合、デコーダは復号プロセスを続けてもよい。そうでない場合、デコーダは復号プロセスを終了してもよい。
[実施形態E]
一実施形態では、デコーダは、ビットストリームで伝達された最小輝度符号化ブロックサイズが復号プロセス中にビットストリーム適合要件を満たすか否かを検証するように構成されてもよい。例えば、デコーダは、ビットストリームから最小輝度符号化ブロックサイズを指定する第1のシンタックスエレメントを受信してもよい。例えば、シンタックスエレメントは、最小輝度符号化ブロックサイズから2を減算した値のlog2値を提供する。デコーダは、第1のシンタックスエレメントの前又は後に、ビットストリームからCTUサイズを指定する第2のシンタックスエレメントを受信してもよい。第2のシンタックスエレメントは、CTUサイズから5を減算した値のlog2値を提供し、log2_ctu_size_minus5によって示されてもよい。
次いで、デコーダは、最小輝度符号化ブロックサイズから2を減算した値の2進対数値が0以上Min(N,log2_ctu_size_minus5+3)以下の範囲内にあるか否かを検証してもよい。Nは0、1、2、3、4等のような整数である。N+2は所定の最大許容最小輝度符号化ブロックサイズの2進対数値を表す。log2_ctu_size_minus5+5はCTUサイズの2進対数値を表す。
最小輝度符号化ブロックサイズが許容最小輝度符号化ブロックサイズの範囲内にある場合、デコーダは復号プロセスを続けてもよい。そうでない場合、デコーダは復号プロセスを終了してもよい。
[実施形態F]
一実施形態では、デコーダは、ビットストリームで伝達された最小輝度符号化ブロックサイズが復号プロセス中にビットストリーム適合要件を満たすか否かを検証するように構成されてもよい。実施形態Eと同様に、デコーダは、ビットストリームから最小輝度符号化ブロックサイズを指定する第1のシンタックスエレメントを受信してもよい。シンタックスエレメントは、最小輝度符号化ブロックサイズから2を減算した値のlog2値を提供し、log2_min_luma_coding_block_size_minus2によって示される。デコーダは、第1のシンタックスエレメントの前又は後に、ビットストリームからCTUサイズを指定する第2のシンタックスエレメントを受信してもよい。第2のシンタックスエレメントは、CTUサイズから5を減算した値のlog2値を提供し、log2_ctu_size_minus5によって示されてもよい。
実施形態Eとは異なり、デコーダは、まず、最小輝度符号化ブロックサイズの2進対数値をlog2_min_luma_coding_block_size_minus2+2と決定し、CTUサイズの2進対数値をlog2_ctu_size_minus5+5と決定してもよい。次いで、デコーダは、最小輝度符号化ブロックサイズの2進対数値がMin(N+2,log2_ctu_size)よりも大きいか否かを検証してもよい。Nは、0、1、2、3、4等のような整数である。N+2は所定の最大許容最小輝度符号化ブロックサイズの2進対数値を表す。log2_ctu_sizeはCTUサイズの2進対数値を表す。
最小輝度符号化ブロックサイズがMin(N+2,log2_ctu_size)よりも大きい場合、デコーダは復号プロセスを終了してもよく、及び/又はエラーメッセージを出力してもよい。そうでない場合、デコーダは復号プロセスを続けてもよい。
[III.2 CTUサイズに基づく最小輝度符号化ブロックサイズの制限]
いくつかの実施形態では、ビデオ符号化標準で指定されたビットストリーム適合要件として、最大許容最小輝度ブロックサイズと伝達されるCTUサイズとの差が最小輝度ブロックサイズの範囲を制限するために指定される。この差は、最大許容最小輝度ブロックサイズ及び伝達されるCTUサイズのlog2値に関して指定されてもよい。例えば、最小輝度符号化ブロックサイズは、4~(1<<log2_ctu_size_minus5+M+2))個の輝度サンプルの範囲にあることが必要とされてもよい。Mは、0、1、2、3等のような整数でもよい。log2値に関して、範囲の上限log2_ctu_size_minus5+M+2は、log2_ctu_size_minus5+5によって示されるCTUサイズよりも(3―M)だけ小さくてもよい。例えば、Mが3に等しい場合、上限とCTUサイズとの間に差は存在しない。Mが2に等しい場合、上限は輝度サンプルに関してCTUサイズの半分である。例えば、128個の輝度サンプルのCTUサイズについて、2に等しいMは、64個の輝度サンプルの上限を定義する。
一例として、log2_min_luma_coding_block_size_minus2によって示されるシンタックスエレメントは、最小輝度符号化ブロックサイズを示すために、パラメータセット(例えば、SPS)で伝達されてもよい。意味は以下のように指定されてもよい。
―log2_min_luma_coding_block_size_minus2に2を加算した値は、最小輝度符号化ブロックサイズを指定する。log2_min_luma_coding_block_size_minus2の値の範囲は、0以上log2_ctu_size_minus5+M以下の範囲とする。
一実施形態では、デコーダは、ビットストリームで伝達された最小輝度符号化ブロックサイズが復号プロセス中に上記のビットストリーム適合要件を満たすか否かを検証するように構成されてもよい。デコーダは、ビットストリームから最小輝度符号化ブロックサイズを指定する第1のシンタックスエレメントを受信してもよい。シンタックスエレメントは、最小輝度符号化ブロックサイズから2を減算した値のlog2値を提供する。デコーダは、第1のシンタックスエレメントの前又は後に、ビットストリームからCTUサイズを指定する第2のシンタックスエレメントを受信してもよい。第2のシンタックスエレメントは、CTUサイズから5を減算した値のlog2値を提供し、log2_ctu_size_minus5によって示されてもよい。
次いで、デコーダは、最小輝度符号化ブロックサイズから2を減算した値の2進対数値が0以上log2_ctu_size_minus5+M以下の範囲内にあるか否かを検証してもよい。同様に、最小輝度符号化ブロックサイズが許容最小輝度符号化ブロックサイズの範囲内にある場合、デコーダは復号プロセスを続けてもよい。そうでない場合、デコーダは復号プロセスを終了してもよい。
[III.3 固定の最小輝度符号化ブロックサイズ]
過度に大きい最小輝度符号化ブロックサイズによって符号化性能が低下することを回避するために、いくつかの実施形態では、最小輝度符号化ブロックサイズは所定の値(例えば、4つの輝度サンプル)に設定されてもよい。このように、ツリー構造に基づくブロック分割は、ピクチャ内の局所領域の統計特性に依存して様々なブロックサイズを使用するように適切に実行されてもよい。
例えば、所定の値は、ビットストリーム適合要件としてビデオ符号化標準で指定されてもよい。ビットストリームが最小輝度符号化ブロックサイズ要件に適合するか否かを検証するために、デコーダは、ビットストリームにおいて最小輝度符号化ブロックサイズを指定するシンタックスエレメントを受信し、所定の値に対してシンタックスエレメントの値を検査してもよい。
[IV. 最小輝度符号化ブロックサイズの制限された範囲での復号プロセス]
図21は、本開示の一実施形態によるプロセス(2100)の概略を示すフローチャートを示す。プロセス(2100)は、ビットストリームに符号化されたピクチャのシーケンスを復号する際に使用されてもよい。様々な実施形態では、プロセス(2100)は、端末デバイス(210)、(220)、(230)及び(240)内の処理回路、ビデオデコーダ(310)の機能を実行する処理回路、ビデオデコーダ(410)の機能を実行する処理回路等の処理回路によって実行される。いくつかの実施形態では、プロセス(2100)は、ソフトウェア命令で実装され、したがって、処理回路がソフトウェア命令を実行すると、処理回路はプロセス(2100)を実行する。プロセスは(S2101)から始まり、(S2110)に進む。
(S2110)において、第1のシンタックスエレメントが符号化ビデオのビットストリームから受信されてもよい。第1のシンタックスエレメントは、最小輝度符号化ブロックサイズを指定し、SPSのようなパラメータセットに含まれてもよい。或いは、いくつかの例では、最小輝度符号化ブロックサイズを指定する第1のシンタックスエレメントは、ビットストリーム内の1つ以上のピクチャのピクチャヘッダ、又は他のシンタックス構造に含まれてもよい。ピクチャヘッダ(PH, picture header)は、符号化ピクチャの全てのスライスに適用するシンタックスエレメントを含むシンタックス構造でもよい。
(S2120)において、最小輝度符号化ブロックサイズが許容最小輝度符号化ブロックサイズの範囲内にあるか否かが検証される。この範囲は、ビデオ符号化標準(例えば、HEVC、VVC等)におけるビットストリーム適合要件として指定されてもよい。この範囲は、4個、8個又は16個の輝度サンプルのような下限と、最大許容CTUサイズよりも小さい上限とを有してもよい。例えば、ビデオ符号化標準で指定されているように、最大許容CTUサイズは128個の輝度サンプルでもよい。許容最小輝度符号化ブロックサイズの範囲の上限は、128個の輝度サンプルよりも小さい値でもよい。
例えば、上限は、所定の最大許容最小輝度符号化ブロックサイズと、第2のシンタックスエレメントによって指定されたCTUサイズとのうち小さい方でもよい。所定の最大許容最小輝度符号化ブロックサイズは、1<<(N+2)(又は別の形式では2N+2)によって表されてもよく、Nは、0、1、2、3、4等でもよい。第2のシンタックスエレメントは、ビットストリームで伝達されてもよい。
一例では、Nは4に等しく、所定の最大許容最小輝度符号化ブロックサイズは64個の輝度サンプルである。伝達されたCTUサイズが128個の輝度サンプルである場合、検証動作は64個の輝度サンプルのサイズを上限として使用してもよい。伝達されたCTUサイズが32個の輝度サンプルである場合、検証動作は32個の輝度サンプルのサイズを上限として使用してもよい。伝達されたCTUサイズが64個の輝度サンプルであり、所定の最大許容最小輝度符号化ブロックサイズと同じである場合、検証動作は64個の輝度サンプルのサイズを上限として使用してもよい。
一例では、伝達された最小輝度符号化ブロックサイズが許容最小輝度符号化ブロックサイズの範囲内にあると決定された場合、プロセス(2100)は継続してもよい。そうでない場合、プロセス(2100)は終了してもよい。さらに、デコーダは、伝達された最小輝度符号化ブロックサイズが許容最小輝度符号化ブロックサイズの範囲内にないことを示すエラーメッセージを出力してもよい。
(S2130)において、符号化ビデオにおける符号化ピクチャは、最小輝度符号化ブロックサイズに基づいて復号されてもよい。符号化ピクチャは、第1のシンタックスエレメントを含むパラメータセットを参照する。或いは、符号化ピクチャは、第1のシンタックスエレメントを含むピクチャヘッダをそれぞれ含む。したがって、符号化ピクチャ内のCUは、第1のシンタックスエレメントによって示される最小輝度符号化ブロックサイズ以上の輝度符号化ブロックサイズを有してもよい。
様々な復号動作が、最小輝度符号化ブロックサイズに基づいて実行されてもよい。一例では、符号化ビデオのピクチャサイズは、以下の規則に従ってもよい。pps_pic_width_in_luma_samplesは、輝度サンプルの単位でPPSを参照する各復号済みピクチャの幅を指定する。pps_pic_width_in_luma_samplesは、0に等しくないものとし、Max(8,MinCbSizeY)の整数倍であるものとし、sps_pic_width_max_in_luma_samples以下であるものとする。MinCbSizeYは最小輝度符号化ブロックサイズを表す。したがって、デコーダは、PPSを参照する各復号済みピクチャの幅が最小輝度符号化ブロックサイズに基づいて規則に従うか否かを検証してもよい。
他の例として、最小輝度符号化ブロックサイズMinCbSizeYは、VVC(Versatile Video Coding)(Draft 7)で指定されているように、復号済みスライスNALユニットのコンテキストの復号から生じるビンの最大数を決定してもよい。具体的には、NumBytesInVclNalUnitsを、符号化ピクチャの全てのVCL NALユニットについてのNumBytesInNalUnitの値の合計とする。BinCountsInNalUnitsを、解析処理関数DecodeBin()が符号化ピクチャの全てのVCL NALユニットの内容を復号するために呼び出される回数とする。変数RawMinCuBitsは以下のように導出されてもよい。
RawMinCuBits=MinCbSizeY*MinCbSizeY*(BitDepth+2*BitDepth/(SubWidthC*SubHeightC)) (式3―3)
BinCountsInNalUnitsの値は(32÷3)*NumBytesInVclNalUnits+(RawMinCuBits*PicSizeInMinCbsY)÷32以下とする。
プロセス(2100)は(2130)の後に(S2199)に進んでもよく、(S2199)において終了する。
[V.コンピュータシステム]
上記の技術は、コンピュータ読み取り可能命令を使用してコンピュータソフトウェアとして実装され、1つ以上のコンピュータ読み取り可能媒体に物理的に記憶されてもよい。例えば、図22は、開示の対象物の特定の実施形態を実装するのに適したコンピュータシステム(2200)を示す。
コンピュータソフトウェアは、いずれかの適切な機械コード又はコンピュータ言語を使用して符号化されてもよく、当該機械コード又はコンピュータ言語は、命令を含むコードを生成するために、アセンブリ、コンパイル、リンク又は類似のメカニズムを受けてもよく、当該命令は、1つ以上のコンピュータ中央処理装置(CPU, central processing unit)、グラフィックス処理ユニット(GPU, Graphics Processing Unit)等によって、直接的に或いはインタープリタ、マイクロコード実行等を通じて実行されてもよい。
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットのデバイス等を含む様々なタイプのコンピュータ又はその構成要素上で実行されてもよい。
コンピュータシステム(2200)について図22に示される構成要素は、本質的に例示的なものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用範囲又は機能に関する如何なる限定も示唆することを意図するものではない。また、構成要素の構成も、コンピュータシステム(2200)の例示的な実施形態に示される構成要素のいずれか1つ又は組み合わせに関する如何なる依存性又は要件も有するものとして解釈されるべきではない。
コンピュータシステム(2200)は、特定のヒューマンインタフェース入力デバイスを含んでもよい。このようなヒューマンインタフェース入力デバイスは、例えば、触覚入力(キーストローク、スワイプ、データグローブの動き等)、オーディオ入力(音声、拍手等)、視覚入力(ジェスチャ等)、嗅覚入力(図示せず)を通じて、1人以上の人間のユーザによる入力に応答してもよい。また、ヒューマンインタフェースデバイスは、オーディオ(例えば、会話、音楽、周辺音)、画像(スキャンされた画像、静止画カメラから取得された写真画像等)、ビデオ(2次元ビデオ、立体ピクチャを含む3次元ビデオ等)のような、人間による意識的入力に必ずしも直接関連しない特定のメディアをキャプチャするために使用されてもよい。
入力ヒューマンインタフェースデバイスは、キーボード(2201)、マウス(2202)、トラックパッド(2203)、タッチ画面(2210)、データグローブ(図示せず)、ジョイスティック(2205)、マイクロフォン(2206)、スキャナ(2207)、カメラ(2208)のうち1つ以上を含んでもよい。
また、コンピュータシステム(2200)は、特定のヒューマンインタフェース出力デバイスを含んでもよい。このようなヒューマンインタフェース出力デバイスは、例えば、触覚出力、音、光及び嗅覚/味覚を通じて、1人以上の人間のユーザの感覚を刺激してもよい。このようなヒューマンインタフェース出力デバイスは、触覚出力デバイス(例えば、タッチ画面(2210)、データグローブ(図示せず)又はジョイスティック(2205)による触覚フィードバック、ただし、入力デバイスとして機能しない触覚フィードバックデバイスが存在してもよい)と、オーディオ出力デバイス(スピーカ(2209)、ヘッドフォン(図示せず)等)と、視覚出力デバイス(それぞれがタッチ画面入力機能を有しても有さなくてもよく、それぞれが触覚フィードバック機能を有しても有さなくてもよく、いくつかが2次元視覚出力又は立体出力のような手段を通じた3次元以上の出力を出力可能でもよい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ポート等)を必要とし、他のネットワークインタフェースアダプタは、一般的に、以下に説明するシステムバス(例えば、PCコンピュータシステムへのイーサネットインタフェース又はスマートフォンコンピュータシステムへのセルラネットワーク)に取り付けられることによって、コンピュータシステム(2200)のコアに統合される。これらのネットワークのいずれかを使用して、コンピュータシステム(2200)は、他のエンティティと通信することができる。このような通信は、一方向の受信のみ(例えば、放送TV)、一方向の送信のみ(例えば、特定のCANbusデバイスへのCANbus)でもよく、或いは、例えば、ローカル又は広域デジタルネットワークを使用する他のコンピュータシステムへの双方向でもよい。特定のプロトコル及びプロトコルスタックは、上記のようなネットワーク及びネットワークインタフェースのそれぞれにおいて使用されてもよい。
上記のヒューマンインタフェースデバイス、人間がアクセス可能な記憶デバイス及びネットワークインタフェースは、コンピュータシステム(2200)のコア(2240)に取り付けられてもよい。
コア(2240)は、1つ以上の中央処理装置(CPU)(2241)、グラフィックス処理ユニット(GPU)(2242)、フィールドプログラマブルゲートアレイ(FPGA, Field Programmable Gate Area)(2243)の形式の特殊なプログラム可能処理ユニット、特定のタスク用のハードウェアアクセラレータ(2244)、グラフィックスアダプタ(2250)等を含んでもよい。これらのデバイスは、読み取り専用メモリ(ROM)(2245)、ランダムアクセスメモリ(2246)、内部大容量記憶装置(内部のユーザアクセス不可能なハードドライブ、SSD等)(2247)と共に、システムバス(2248)を通じて接続されてもよい。いくつかのコンピュータシステムでは、システムバス(2248)は、更なるCPU、GPU等による拡張を可能にするために、1つ以上の物理プラグの形式でアクセス可能でもよい。周辺デバイスは、コアのシステムバス(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:略語]
AMVP: Advanced MVP
ASIC: Application―Specific Integrated Circuit
BDOF: Bi―directional optical flow
BMS: benchmark set
CANBus: Controller Area Network Bus
CBF: Coded Block Flag
CCLM: Cross―Component Linear Mode/Model
CD: Compact Disc
CIIP: Combined Inter/Intra prediction
CPU: Central Processing Unit
CRT: Cathode Ray Tube
CTB: Coding Tree Block
CTU: Coding Tree Unit
CU: Coding Unit
DVD: Digital Video Disc
FPGA: Field Programmable Gate Area
GOP: Group of Pictures
GPU: Graphics Processing Unit
GSM: Global System for Mobile communications
HEVC: High Efficiency Video Coding
HMVP: History―based MVP
HRD: Hypothetical Reference Decoder
IC: Integrated Circuit
JEM: joint exploration model
LAN: Local Area Network
LCD: Liquid―Crystal Display
LFNST: Low Frequency Non Separable Transform
LIC: Luma Illumination Compensation
LTE: Long―Term Evolution
MMVD: Merge with MVD
MV: Motion Vector
MVD: Motion vector difference
MVP: Motion vector predictor
OLED: Organic Light―Emitting Diode
PB: Prediction Block
PCI: Peripheral Component Interconnect
PDPC: Position Dependent Prediction Combination
PLD: Programmable Logic Device
PU: Prediction Unit
RAM: Random Access Memory
ROM: Read―Only Memory
RST: Reduced Secondary Transform
SbTMVP: Subblock―based TMVP
SCIPU: Smallest chroma intra prediction unit
SEI: Supplementary Enhancement Information
SNR: Signal Noise Ratio
SSD: solid―state drive
TMVP: Temporal MVP
TPM: Triangular partitioning mode
TU: Transform Unit
USB: Universal Serial Bus
VPDU: Visual Process Data Unit
VTM: Versatile test model
VUI: Video Usability Information
VVC: versatile video coding
本開示は、いくつかの例示的な実施形態を記載しているが、本開示の範囲内に入る変更、置換及び様々な代替の等価物が存在する。したがって、当業者は、本明細書に明示的に図示又は記載されていないが、本開示の原理を具現し、したがって、本開示の真意及び範囲内にある多数のシステム及び方法を考案することができることが認識される。

Claims (13)

  1. ビデオデコーダが実行するビデオ復号の方法であって、
    符号化ビデオのビットストリームから第1のシンタックスエレメントを受信するステップであって、前記第1のシンタックスエレメントは、最小輝度符号化ブロックサイズを指定する、ステップと、
    前記最小輝度符号化ブロックサイズが最大許容符号化ツリーユニット(CTU)サイズよりも小さい上限を有する許容最小輝度符号化ブロックサイズの範囲内にあるか否かを検証するステップと、
    前記最小輝度符号化ブロックサイズに基づいて、前記符号化ビデオにおける符号化ピクチャを復号するステップと
    を含む方法。
  2. 前記許容最小輝度符号化ブロックサイズの範囲の前記上限は、所定の最大許容最小輝度符号化ブロックサイズである、請求項1に記載の方法。
  3. 前記符号化ビデオの前記ビットストリームから第2のシンタックスエレメントを受信するステップであって、前記第2のシンタックスエレメントはCTUサイズを指定する、ステップを更に含み、
    前記CTUサイズが所定の最大許容最小輝度符号化ブロックサイズよりも大きい場合、前記所定の最大許容最小輝度符号化ブロックサイズが、前記許容最小輝度符号化ブロックサイズの範囲の前記上限として使用される、請求項1又は2に記載の方法。
  4. 前記CTUサイズが前記所定の最大許容最小輝度符号化ブロックサイズよりも小さい場合、前記CTUサイズが、前記許容最小輝度符号化ブロックサイズの範囲の前記上限として使用される、請求項3に記載の方法。
  5. 前記第1のシンタックスエレメントは、前記最小輝度符号化ブロックサイズから2を減算した値の2進対数値を示し、
    前記最小輝度符号化ブロックサイズが前記許容最小輝度符号化ブロックサイズの範囲内にあるか否かを検証する前記ステップは、
    前記最小輝度符号化ブロックサイズから2を減算した値の前記2進対数値が0以上N以下の範囲内にあるか否かを検証するステップであって、Nは整数であり、N+2は所定の最大許容最小輝度符号化ブロックサイズの2進対数値を表す、ステップを含む、請求項1乃至4のうちいずれか1項に記載の方法。
  6. 前記第1のシンタックスエレメントは、前記最小輝度符号化ブロックサイズから2を減算した値の2進対数値を示し、
    前記最小輝度符号化ブロックサイズが前記許容最小輝度符号化ブロックサイズの範囲内にあるか否かを検証する前記ステップは、
    前記最小輝度符号化ブロックサイズから2を減算した値の前記2進対数値が0以上Min(N,log2_ctu_size_minus5+3)以下の範囲内にあるか否かを検証するステップであって、Nは整数であり、N+2は所定の最大許容最小輝度符号化ブロックサイズの2進対数値を表し、log2_ctu_size_minus5+5は前記符号化ビデオのCTUサイズの2進対数値を表す、ステップを含む、請求項1乃至4のうちいずれか1項に記載の方法。
  7. Nは4に等しい、請求項6に記載の方法。
  8. 前記第1のシンタックスエレメントは、前記最小輝度符号化ブロックサイズから2を減算した値の2進対数値を示し、
    前記最小輝度符号化ブロックサイズが前記許容最小輝度符号化ブロックサイズの範囲内にあるか否かを検証する前記ステップは、
    前記最小輝度符号化ブロックサイズの前記2進対数値がMin(N+2,log2_ctu_size)よりも大きいか否かを検証するステップであって、Nは整数であり、N+2は所定の最大許容最小輝度符号化ブロックサイズの2進対数値を表し、log2_ctu_sizeは前記符号化ビデオのCTUサイズの2進対数値を表す、ステップを含む、請求項1乃至4のうちいずれか1項に記載の方法。
  9. Nは4に等しい、請求項8に記載の方法。
  10. 前記第1のシンタックスエレメントは、前記最小輝度符号化ブロックサイズから2を減算した値の2進対数値を示し、
    前記最小輝度符号化ブロックサイズが前記許容最小輝度符号化ブロックサイズの範囲内にあるか否かを検証する前記ステップは、
    前記最小輝度符号化ブロックサイズから2を減算した値の前記2進対数値が0以上log2_ctu_size_minus5+M以下の範囲にあるか否かを検証するステップであって、Mは整数であり、log2_ctu_size_minus5+5は前記符号化ビデオのCTUサイズの2進対数値を表し、log2_ctu_size_minus5+M+2は所定の最大許容最小輝度符号化ブロックサイズの2進対数値を表す、ステップを含む、請求項1乃至4のうちいずれか1項に記載の方法。
  11. 処理回路を含むビデオ復号の装置であって、
    前記処理回路は、
    請求項1乃至10のうちいずれか1項に記載の方法を実行するように構成される装置。
  12. プロセッサによって実行されると、前記プロセッサに、
    請求項1乃至10のうちいずれか1項に記載の方法を実行させるコンピュータプログラム。
  13. ビデオエンコーダが実行するビデオ符号化の方法であって、
    符号化ビデオのビットストリームにおいて第1のシンタックスエレメントを送信するステップであって、前記第1のシンタックスエレメントは、最小輝度符号化ブロックサイズを指定する、ステップを含み、
    前記最小輝度符号化ブロックサイズは、前記最小輝度符号化ブロックサイズが最大許容符号化ツリーユニット(CTU)サイズよりも小さい上限を有する許容最小輝度符号化ブロックサイズの範囲内にあるか否かを検証することによって、前記符号化ビデオにおける符号化ピクチャを復号するために使用される、方法。
JP2021555306A 2019-10-30 2020-10-27 ビデオ符号化及び復号における最小符号化ブロックサイズの範囲 Active JP7322171B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201962928150P 2019-10-30 2019-10-30
US62/928,150 2019-10-30
US17/078,302 2020-10-23
US17/078,302 US11399195B2 (en) 2019-10-30 2020-10-23 Range of minimum coding block size in video coding
PCT/US2020/057482 WO2021086828A1 (en) 2019-10-30 2020-10-27 Range of minimum coding block size in video coding

Publications (2)

Publication Number Publication Date
JP2022525334A true JP2022525334A (ja) 2022-05-12
JP7322171B2 JP7322171B2 (ja) 2023-08-07

Family

ID=75688130

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021555306A Active JP7322171B2 (ja) 2019-10-30 2020-10-27 ビデオ符号化及び復号における最小符号化ブロックサイズの範囲

Country Status (9)

Country Link
US (2) US11399195B2 (ja)
EP (1) EP4052468A4 (ja)
JP (1) JP7322171B2 (ja)
KR (1) KR20210130808A (ja)
CN (1) CN113826391A (ja)
AU (2) AU2020372880B2 (ja)
CA (1) CA3136208A1 (ja)
SG (1) SG11202110884SA (ja)
WO (1) WO2021086828A1 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2019201649A1 (en) * 2019-03-11 2020-10-01 Canon Kabushiki Kaisha Method, apparatus and system for encoding and decoding a tree of blocks of video samples
JP7273193B2 (ja) * 2019-05-12 2023-05-12 北京字節跳動網絡技術有限公司 参照ピクチャ再サンプリングのための信号通知
WO2021091253A1 (ko) * 2019-11-05 2021-05-14 엘지전자 주식회사 슬라이스 타입 기반 영상/비디오 코딩 방법 및 장치
KR20220082058A (ko) * 2019-11-18 2022-06-16 엘지전자 주식회사 루프 필터링을 제어하는 영상 코딩 장치 및 방법
JP2023508053A (ja) * 2019-12-23 2023-02-28 華為技術有限公司 符号化器、復号器、及びコーディング・ブロック・パーティショニング制限導出の方法
WO2023116704A1 (en) * 2021-12-21 2023-06-29 Mediatek Inc. Multi-model cross-component linear model prediction
EP4254950A1 (en) * 2022-03-31 2023-10-04 Beijing Xiaomi Mobile Software Co., Ltd. Encoding/decoding video picture partitionned in ctu grids
WO2023198110A1 (en) * 2022-04-13 2023-10-19 Mediatek Inc. Block partitioning image and video data

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101888515B1 (ko) * 2011-01-13 2018-08-14 캐논 가부시끼가이샤 화상 부호화장치, 화상 부호화방법, 화상복호장치, 화상복호방법 및 기억매체
WO2015102042A1 (en) * 2014-01-02 2015-07-09 Sharp Kabushiki Kaisha Parameter set signaling
WO2017083553A1 (en) * 2015-11-10 2017-05-18 Vid Scale, Inc. Systems and methods for coding in super-block based video coding framework
CN109196862B (zh) * 2016-05-28 2021-01-22 联发科技股份有限公司 视频数据处理方法、装置及相应可读存储介质
CN117221589A (zh) * 2016-06-22 2023-12-12 Lx 半导体科技有限公司 图像编码/解码设备以及传输图像数据的设备
CN109417636B (zh) * 2016-06-24 2022-04-01 韩国电子通信研究院 用于基于变换的图像编码/解码的方法和设备
CN116614639A (zh) * 2016-07-12 2023-08-18 韩国电子通信研究院 图像编码/解码方法和用于所述方法的记录介质
CN116708783A (zh) * 2016-07-12 2023-09-05 韩国电子通信研究院 图像编码/解码方法以及用于该方法的记录介质
JP2019525577A (ja) * 2016-07-18 2019-09-05 エレクトロニクス アンド テレコミュニケーションズ リサーチ インスチチュートElectronics And Telecommunications Research Institute 画像符号化/復号方法、装置、及び、ビットストリームを保存した記録媒体
CN116527887A (zh) * 2016-08-01 2023-08-01 韩国电子通信研究院 图像编码/解码方法和设备以及存储比特流的记录介质
CN116567212A (zh) * 2016-08-11 2023-08-08 Lx 半导体科技有限公司 编码/解码设备以及发送图像数据的设备
KR20180029905A (ko) * 2016-09-13 2018-03-21 한국전자통신연구원 영상 부호화/복호화 방법, 장치 및 비트스트림을 저장한 기록 매체
CN109804625A (zh) * 2016-10-04 2019-05-24 韩国电子通信研究院 对图像编码/解码的方法和装置及存储比特流的记录介质
CN117221575A (zh) * 2016-10-04 2023-12-12 英迪股份有限公司 图像解码方法、图像编码方法以及发送比特流的方法
WO2018080135A1 (ko) * 2016-10-28 2018-05-03 한국전자통신연구원 영상 부호화/복호화 방법, 장치 및 비트스트림을 저장한 기록 매체
US11503286B2 (en) * 2016-11-28 2022-11-15 Electronics And Telecommunications Research Institute Method and device for filtering
US10848788B2 (en) * 2017-01-06 2020-11-24 Qualcomm Incorporated Multi-type-tree framework for video coding
US11218697B2 (en) * 2017-05-26 2022-01-04 Sk Telecom Co., Ltd. Apparatus and method for video encoding or decoding supporting various block sizes
US20180367818A1 (en) * 2017-06-15 2018-12-20 Futurewei Technologies, Inc. Block Partition Structure in Video Compression
CN117440151A (zh) * 2017-07-06 2024-01-23 Lx 半导体科技有限公司 图像解码方法、图像编码方法、发送方法和数字存储介质
US10666943B2 (en) * 2017-09-15 2020-05-26 Futurewei Technologies, Inc. Block partition structure in video compression
WO2019059482A1 (ko) * 2017-09-19 2019-03-28 삼성전자 주식회사 영상 부호화 방법 및 장치, 영상 복호화 방법 및 장치
WO2019078629A1 (ko) * 2017-10-18 2019-04-25 한국전자통신연구원 영상 부호화/복호화 방법, 장치 및 비트스트림을 저장한 기록 매체
US10827173B2 (en) * 2017-11-13 2020-11-03 Electronics And Telecommunications Research Institute Method and apparatus for quantization
US11172229B2 (en) * 2018-01-12 2021-11-09 Qualcomm Incorporated Affine motion compensation with low bandwidth
US10841577B2 (en) * 2018-02-08 2020-11-17 Electronics And Telecommunications Research Institute Method and apparatus for video encoding and video decoding based on neural network
US20190306506A1 (en) * 2018-04-02 2019-10-03 Qualcomm Incorporated Limitation on the coding tree unit/block for next-generation video coding
US11019355B2 (en) * 2018-04-03 2021-05-25 Electronics And Telecommunications Research Institute Inter-prediction method and apparatus using reference frame generated based on deep learning
KR102525179B1 (ko) * 2018-09-03 2023-04-21 후아웨이 테크놀러지 컴퍼니 리미티드 파티션 제한 요소들 간의 관계
US11057636B2 (en) * 2018-09-17 2021-07-06 Qualcomm Incorporated Affine motion prediction
US11889118B2 (en) * 2019-02-24 2024-01-30 Sharp Kabushiki Kaisha Systems and methods for signaling types of pictures and associated information in video coding
WO2021037004A1 (en) * 2019-08-23 2021-03-04 Huawei Technologies Co., Ltd. An encoder, a decoder and corresponding methods for performing chroma deblocking for blocks which use joint chroma coding

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
YAO-JEN CHANG VADIM SEREGIN MUHAMMED COBAN ADARSH RAMASUBRAMONIAN MARTA KARCZEWICZ: "AHG17: On log2_min_luma_coding_block_size_minus2 [online]", JVET-P JVET-P0429R1, JPN6022043693, 7 October 2019 (2019-10-07), pages 1 - 5, ISSN: 0004899135 *

Also Published As

Publication number Publication date
SG11202110884SA (en) 2021-10-28
CA3136208A1 (en) 2021-05-06
US20210136399A1 (en) 2021-05-06
KR20210130808A (ko) 2021-11-01
AU2020372880B2 (en) 2023-01-12
CN113826391A (zh) 2021-12-21
WO2021086828A1 (en) 2021-05-06
AU2023202071A1 (en) 2023-05-04
US11399195B2 (en) 2022-07-26
EP4052468A1 (en) 2022-09-07
JP7322171B2 (ja) 2023-08-07
EP4052468A4 (en) 2023-11-08
US20220337864A1 (en) 2022-10-20
AU2020372880A1 (en) 2021-10-21

Similar Documents

Publication Publication Date Title
JP7046220B2 (ja) 小ブロックの予測と変換のための方法、装置、及びプログラム
KR102435382B1 (ko) 디코더 측 mv 도출 및 리파인먼트를 위한 개선
JP2022523795A (ja) ビデオ・コーディングのための方法及び装置
JP7322171B2 (ja) ビデオ符号化及び復号における最小符号化ブロックサイズの範囲
KR20200121904A (ko) 비디오 디코딩을 위한 방법 및 장치
JP7055485B2 (ja) 映像符号化のための方法並びに、その、装置及びコンピュータプログラム
JP2022511865A (ja) ビデオ符号化又は復号の方法及び装置並びにコンピュータプログラム
JP2022526161A (ja) ビデオ・コーディング方法及び装置
JP7016971B2 (ja) ビデオ符号化の方法及び装置
JP2022517114A (ja) ビデオ復号用の方法、装置およびプログラム
JP2022511851A (ja) 最大変換サイズの制御
JP7271675B2 (ja) ビデオ復号の方法および装置、並びにプログラム
JP2022525748A (ja) ビデオ符号化のための色変換
KR20210090270A (ko) 비디오 디코딩 또는 인코딩을 위한 방법 및 장치
JP2022524107A (ja) イントラピクチャブロック補償のための予測候補リストサイズシグナリングのための方法および装置
JP2022526380A (ja) スキップモードフラグを伝達するための方法、装置及びコンピュータプログラム
JP2022522683A (ja) ビデオコーディングのための方法並びにその、装置およびコンピュータプログラム
JP2022521699A (ja) 映像コーディングのための方法、装置、及びコンピュータプログラム
JP2022511843A (ja) ビデオ・コーディングのための方法、装置及びコンピュータ・プログラム
JP2022512109A (ja) ビデオ復号及び符号化の方法、装置並びにプログラム
KR20210138114A (ko) 비디오 코딩 방법 및 장치
JP2022502950A (ja) ビデオ符号化及び復号の方法及び装置並びにコンピュータプログラム
JP7377887B2 (ja) ビデオ符号化又はビデオ復号のための方法、装置及びコンピュータプログラム
JP7325622B2 (ja) 映像コーディングのための方法、装置、及びコンピュータプログラム
RU2796261C1 (ru) Диапазон минимального размера блока кодирования при кодировании видео

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210913

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20221018

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20230118

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230317

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230726

R150 Certificate of patent or registration of utility model

Ref document number: 7322171

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150