JP7191211B2 - 復号する方法、コンピュータプログラム、ビデオ復号装置 - Google Patents

復号する方法、コンピュータプログラム、ビデオ復号装置 Download PDF

Info

Publication number
JP7191211B2
JP7191211B2 JP2021514320A JP2021514320A JP7191211B2 JP 7191211 B2 JP7191211 B2 JP 7191211B2 JP 2021514320 A JP2021514320 A JP 2021514320A JP 2021514320 A JP2021514320 A JP 2021514320A JP 7191211 B2 JP7191211 B2 JP 7191211B2
Authority
JP
Japan
Prior art keywords
chroma
luma
coding tree
samples
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.)
Active
Application number
JP2021514320A
Other languages
English (en)
Other versions
JP2022500926A (ja
Inventor
クリストファー ジェームズ ロゼワーン,
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
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 Canon Inc filed Critical Canon Inc
Publication of JP2022500926A publication Critical patent/JP2022500926A/ja
Priority to JP2022193604A priority Critical patent/JP7391175B2/ja
Application granted granted Critical
Publication of JP7191211B2 publication Critical patent/JP7191211B2/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/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/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/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/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/593Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • 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/117Filters, e.g. for pre-processing or post-processing
    • 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/146Data rate or code amount at the encoder output
    • H04N19/147Data rate or code amount at the encoder output according to rate distortion criteria
    • 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/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
    • H04N19/523Motion estimation or motion compensation with sub-pixel accuracy

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)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)
  • Color Television Systems (AREA)

Description

関連出願の参照
本出願は、2018年9月21日に出願されたオーストラリア国特許出願第2018233042号の米国特許法セクション119に基づく出願日の利益を主張するものであり、本明細書に完全に記載されているかのように、その全体が参照により組み込まれる。
本発明は、一般に、デジタルビデオ信号処理に関し、特に、ビデオサンプルのブロックのツリーを符号化および復号化するための方法、装置およびシステムに関するものである。また、本発明は、ビデオサンプルのブロックのツリーを符号化および復号化するためのコンピュータプログラムを記録したコンピュータ可読媒体を含むコンピュータプログラム製品にも関する。
ビデオデータの送信および保存のためのアプリケーションを含む、ビデオ符号化のための多くのアプリケーションが現在存在する。また、多くのビデオ符号化標準が開発されており、他のものも現在開発中である。ビデオ符号化の標準化の最近の進展により、「ジョイントビデオエキスパートチーム」(JVET)と呼ばれるグループが形成されている。ジョイントビデオエキスパートチーム(JVET)は、「ビデオ符号化エキスパートグループ」(VCEG)とも呼ばれる国際電気通信連合(ITU)の電気通信標準化部門(ITU-T)のスタディグループ16,研究課題6(SG16/Q6)のメンバーと「動画エキスパートグループ」(MPEG)とも呼ばれる国際標準化機構/国際電気標準会議のジョイント技術委員会1/サブ委員会29/作業グループ11(ISO/IEC JTC1/SC29/WG11)のメンバーとを含んでいる。
ジョイントビデオエキスパートチーム(JVET)は、提案募集(CfP)を発行し、米国のサンディエゴで開催された第10回会議で回答を分析した。提出された提案は、現在の最新ビデオ圧縮規格である「高効率ビデオ符号化」(HEVC)を大幅に上回るビデオ圧縮能力を示していた。この結果を受けて、新たなビデオ圧縮規格である「多用途ビデオ符号化(VVC)」の開発プロジェクトを開始することが決定された。VVCは、ビデオフォーマットの高機能化(高解像度化、高フレームレート化)や、帯域コストが相対的に高いWAN上でのサービス提供に対する市場の要求の高まりを受けて、これまで以上に高い圧縮性能が求められている。同時に、VVCは現代のシリコンプロセスで実装可能でなければならず、達成された性能と実装コストの間に許容できるトレードオフを提供しなければならない(例えば、シリコン面積、CPUプロセッサの負荷、メモリ利用率、帯域幅の観点から)。
ビデオデータは、それぞれが1つ以上のカラーチャネルを含む画像データの複数のフレームのシーケンスを含む。一般的には、1つのプライマリカラーチャネルと2つのセカンダリカラーチャネルが必要である。プライマリカラーチャネルは一般に「ルマ」チャネルと呼ばれ、セカンダリカラーチャネル(複数可)は一般に「クロマ」チャネルと呼ばれる。ビデオデータは通常、RGB(赤-緑-青)色空間で表示されるが、この色空間は3つの成分の間に高度な相関関係がある。符号化器や復号化器が見るビデオデータの表現は、多くの場合、YCbCrなどの色空間を用いている。YCbCrは、伝達関数によって「ルマ」にマッピングされた輝度をY(プライマリ)チャネルに、クロマをCbとCr(セカンダリ)チャネルに集約している。さらに、CbおよびCrチャネルは、例えば水平方向に半分、垂直方向に半分というように、ルマチャネルに比べて低いレートで空間的にサンプリングされることがあり、これは「4:2:0クロマフォーマット」として知られている。4:2:0クロマフォーマットは、インターネットビデオストリーミング、テレビ放送、ブルーレイディスクへの保存など、一般消費者向けのアプリケーションで使用されている。CbチャネルとCrチャネルを水平方向にハーフレートでサブサンプリングし、垂直方向にはサブサンプリングしない方式は「4:2:2クロマフォーマット」として知られている。4:2:2クロマフォーマットは、映画製作用のビデオを撮影するなど、プロ向けの用途で使用されることが多い。4:2:2クロマフォーマットは、サンプリングレートが高いため、カラーグレーディングなどの編集作業に強いビデオが得られる。4:2:2クロマフォーマットの素材は、消費者に配信される前に、4:2:0クロマフォーマットに変換された後、符号化されることが多い。クロマフォーマットに加えて、ビデオは解像度とフレームレートによっても特徴づけられる。解像度は3840x2160の超高精細(UHD)や7680x4320の「8K」などがあり、フレームレートは60Hzや120Hzなどがある。ルマのサンプルレートは、約500メガサンプル/秒から数ギガサンプル/秒の範囲になる。4:2:0クロマフォーマットの場合、各クロマチャネルのサンプルレートは、ルマサンプルレートの1/4であり、4:2:2クロマフォーマットの場合、各クロマチャネルのサンプルレートは、ルマサンプルレートの1/2である。
VVC規格は「ブロックベース」のコーデックであり、フレームはまず「符号化ツリーユニット」(CTU)として知られる正方形の領域配列に分割される。CTUは一般的に、128×128のルマサンプルのような比較的大きな領域を占める。ただし、フレームの右端や下端にあるCTUは面積が小さい場合がある。各CTUには、ルマチャネル用の「符号化ツリー」と、クロマチャネル用の追加の符号化ツリーが関連付けられている。符号化ツリーは、CTUの領域を「符号化ブロック」(CB)と呼ばれるブロックの集合に分解して定義する。この場合、ブロックは「符号化ユニット」(CU)と呼ばれ、各CUは各カラーチャネルの符号化ブロックを持つ。CBは特定の順序で符号化または復号化のために処理される。4:2:0クロマフォーマットを採用しているため、128×128のルマサンプルエリアに対応するルマ符号化ツリーを持つCTUは、128×128のルマサンプルエリアに隣接する64×64のクロマサンプルエリアに対応するクロマ符号化ツリーを持っている。ルマチャネルとクロマチャネルに単一の符号化ツリーが使用されている場合、所定のエリアに配置されたブロックの集合体は、一般に「ユニット」と呼ばれ、例えば、上記のCUのほか、「予測ユニット」(PU)や「変換ユニット」(TU)などがある。所与のエリアに対して別々の符号化ツリーが使用される場合、上述のCBのほか、「予測ブロック」(PB)および「変換ブロック」(TB)が使用される。
上記の「ユニット」と「ブロック」の区別にかかわらず、「ブロック」という用語は、すべてのカラーチャネルに演算が適用されるフレームのエリアまたは領域の一般的な用語として使用することができる。
各CUについて、フレームデータの対応するエリアのコンテンツ(サンプル値)の予測(PU)が生成される(「予測ユニット」)。さらに、予測値と、符号化器への入力時に見られる領域のコンテンツとの間の差(または空間領域における「残差」)の表現が形成される。各カラーチャネルの差は、残差係数のシーケンスとして変換符号化され、所定のCUに対する1つまたは複数のTUを形成することができる。適用される変換は、残差値の各ブロックに適用される離散コサイン変換(DCT)または他の変換であってもよい。このプライマリ変換は分離して適用され、すなわち、二次元変換は2つのパスで実行される。まず、ブロック内のサンプルの各行に1次元変換を適用してブロックを変換しり。次に、部分結果の各列に一次元変換を適用して部分結果を変換し、残留サンプルを実質的に相関させる変換係数の最終ブロックを生成する。VVC規格では、様々なサイズの変換がサポートされており、各辺が2の累乗になっている長方形のブロックの変換も含まれる。変換係数は、ビットストリームへのエントロピー符号化のために量子化される。
空間予測(「イントラ予測」)がPBを生成するために使用される場合、参照サンプルのセットが、現在のPBに対する予測サンプルを生成するために使用される。基準サンプルは、既に「再構成」(イントラ予測サンプルへの残留サンプルの追加)されたPBに隣接するサンプルを含む。これらの隣接するサンプルは、PBの上に行を、PBの左に列を形成する。この行と列は、PBの境界を越えて、さらに近隣のサンプルを含んでいる。Zオーダスキャンでブロックをスキャンするため、参照サンプルの一部は直前のブロックで再構成されたものになる。直前のブロックのサンプルを使用すると、フィードバック依存性が発生し、ビデオ符号化器や復号化器でのブロックのスループットが制限される場合がある。
本発明の目的は、既存の装置の1つまたは複数の欠点を実質的に克服し、または少なくとも改善することである。
本開示の一態様は、ビットストリームから画像フレーム内の符号化ツリーユニットの符号化ブロックを復号化する方法を提供し、該方法は、前記画像フレームを受信することであって、前記画像フレームはクロマフォーマットを有し、前記画像フレームの複数のクロマチャネルは前記画像フレームの1つのルマチャネルに対してサブサンプリングされている、前記受信することと、前記符号化ツリーユニットの領域の寸法に応じて、前記符号化ツリーユニットの前記1つのルマチャネルに対する複数のルマ分割オプションを決定することと、前記領域の前記寸法に応じて、前記符号化ツリーユニットの前記複数のクロマチャネルに対する複数のクロマ分割オプションを決定することであって、前記複数のクロマ分割オプションは前記複数のルマ分割オプションとは異なり、許容される複数のクロマ分割オプションは最小サイズが16サンプルの複数のクロマイントラ予測ブロックをもたらす、前記決定することと、前記ビットストリームから複数のフラグを決定し、前記決定された複数のルマ分割オプションの1つと前記決定された複数のクロマ分割オプションの1つを選択し、前記符号化ツリーユニットの前記符号化ブロックを復号化することと、を含む。
別の態様によれば、クロマブロックサイズは、前記画像フレームの複数のクロマチャネルに対して16サンプルの倍数である。
別の態様によれば、前記決定された複数のルマ分割オプションは、前記画像フレームの1つのルマチャネルに対して16サンプルの倍数である1つのルマブロックサイズをもたらす。
別の態様によれば、2サンプルの幅を有する複数のクロマブロックはブロックの複数のサブブロックへの分割を用いて符号化され、各サブブロックのサイズは2×8サンプルである。
別の態様によれば、2サンプルの高さを有する複数のクロマブロックはブロックの複数のサブブロックへの分割を用いて符号化され、各サブブロックのサイズは8×2サンプルである。
本開示の別の態様は、ビットストリームから画像フレーム内の符号化ツリーユニットの符号化ブロックを復号化する方法を実施するためのコンピュータプログラムを格納する非一時的コンピュータ可読媒体を提供し、前記コンピュータプログラムは、前記画像フレームを受信するためのコードであって、前記画像フレームはクロマフォーマットを有し、前記画像フレームの複数のクロマチャネルは前記画像フレームの1つのルマチャネルに対してサブサンプリングされている、前記受信するためのコードと、前記符号化ツリーユニットの領域の寸法に応じて、前記符号化ツリーユニットの前記1つのルマチャネルに対する複数のルマ分割オプションを決定するためのコードと、前記領域の前記寸法に応じて、前記符号化ツリーユニットの前記複数のクロマチャネルに対する複数のクロマ分割オプションを決定するためのコードであって、前記複数のクロマ分割オプションは前記複数のルマ分割オプションとは異なり、許容される複数のクロマ分割オプションは最小サイズが16サンプルの複数のクロマイントラ予測ブロックをもたらす、前記決定するためのコードと、前記ビットストリームから複数のフラグを決定し、前記決定された複数のルマ分割オプションの1つと前記決定された複数のクロマ分割オプションの1つを選択し、前記符号化ツリーユニットの前記符号化ブロックを復号化するためのコードと、を含む。
本開示の別の態様は、ビデオ復号化器を提供し、該ビデオ復号化器は、ビットストリームから画像フレームの符号化ツリーユニットを受信し、前記画像フレームはクロマフォーマットを有し、前記画像フレームの複数のクロマチャネルは前記画像フレームの1つのルマチャネルに対してサブサンプリングされており、前記符号化ツリーユニットの領域の寸法に応じて、前記符号化ツリーユニットの前記1つのルマチャネルに対する複数のルマ分割オプションを決定し、前記領域の前記寸法に応じて、前記符号化ツリーユニットの前記複数のクロマチャネルに対する複数のクロマ分割オプションを決定し、前記複数のクロマ分割オプションは前記複数のルマ分割オプションとは異なり、許容される複数のクロマ分割オプションは最小サイズが16サンプルの複数のクロマイントラ予測ブロックをもたらし、前記ビットストリームから複数のフラグを決定し、前記決定された複数のルマ分割オプションの1つと前記決定された複数のクロマ分割オプションの1つを選択し、前記符号化ツリーユニットの前記符号化ブロックを復号化する、ように構成される。
本開示の別の態様は、システムを提供し、該システムは、メモリと、ビットストリームから画像フレーム内の符号化ツリーユニットの符号化ブロックを復号化する方法を実施するために、前記メモリに格納されたコードを実行するように構成された、プロセッサと、を備え、前記方法は、前記画像フレームを受信することであって、前記画像フレームはクロマフォーマットを有し、前記画像フレームの複数のクロマチャネルは前記画像フレームの1つのルマチャネルに対してサブサンプリングされている、前記受信することと、前記符号化ツリーユニットの領域の寸法に応じて、前記符号化ツリーユニットの前記1つのルマチャネルに対する複数のルマ分割オプションを決定することと、前記領域の前記寸法に応じて、前記符号化ツリーユニットの前記複数のクロマチャネルに対する複数のクロマ分割オプションを決定することであって、前記複数のクロマ分割オプションは前記複数のルマ分割オプションとは異なり、許容される複数のクロマ分割オプションは最小サイズが16サンプルの複数のクロマイントラ予測ブロックをもたらす、前記決定することと、前記ビットストリームから複数のフラグを決定し、前記決定された複数のルマ分割オプションの1つと前記決定された複数のクロマ分割オプションの1つを選択し、前記符号化ツリーユニットの前記符号化ブロックを復号化することと、を含む。
他の態様も開示されている。
以下、本発明の少なくとも一実施形態を、以下の図面および付録を参照して説明する。
図1は、ビデオ符号化および復号化システムを示す概略ブロック図である。
図2Aは、図1のビデオ符号化および復号化システムの一方または両方が実施され得る汎用コンピュータシステムの概略ブロック図である。 図2Bは、図1のビデオ符号化および復号化システムの一方または両方が実施され得る汎用コンピュータシステムの概略ブロック図である。
図3は、ビデオ符号化器の機能モジュールを示す概略ブロック図である。
図4は、ビデオ復号化器の機能モジュールを示す概略ブロック図である。
図5は、多用途ビデオ符号化のツリー構造において、1つのブロックの1つ以上のブロックへの利用可能な分割を示す概略ブロック図である。
図6は、多用途ビデオ符号化のツリー構造において、1つのブロックの1つ以上のブロックへの許可された分割を実現するためのデータフローを示す概略図である。
図7Aは、符号化ツリーユニット(CTU)を多数の符号化ユニットに分割する例を示す図である。 図7Bは、符号化ツリーユニット(CTU)を多数の符号化ユニットに分割する例を示す図である。
図8は、変換ブロックサイズと関連するスキャンパターンの集合を示す図である。
図9は、ルマ符号化ツリーおよびクロマ符号化ツリーにおいて許容される分割のリストを生成するための規則を示す図である。
図10は、画像フレームの符号化ツリーをビデオビットストリームに符号化するための方法のフロー図である。
図11は、ビデオビットストリームから画像フレームの符号化ツリーを復号化するための方法のフロー図である。
図12は、画像フレームのルマおよびクロマ符号化ツリーをビデオビットストリームに符号化するための方法のフロー図である。
図13は、ビデオビットストリームから画像フレームのルマおよびクロマ符号化ツリーを復号化するための方法のフロー図である。
添付図面のいずれか1つ以上において、同じ参照数字を有するステップおよび/または特徴が参照される場合、それらのステップおよび/または特徴は、反対の意図が現れない限り、本明細書の目的のために、同じ機能(複数可)または動作(複数可)を有する。
上述したように、直前のブロックからのサンプルの使用は、ビデオ符号化器または復号化器を介したブロックのスループットを制限する可能性のあるフィードバック依存性をもたらす。結果として生じるフィードバック依存性ループの深刻さを緩和する方法が、典型的なリアルタイム符号化および復号化アプリケーションに必要とされるように、ブロック処理が高いレートで維持されることを保証するために望まれる。フィードバック依存ループは、ASIC(特定用途向け集積回路)のクロック周波数が一般的に数百MHzであるのに対し、現代のビデオフォーマットの高いサンプルレート(例えば500~4000サンプル/秒)の場合に特に問題となる。
図1は、ビデオ符号化および復号化システム100の機能モジュールを示す概略ブロック図である。システム100は、遭遇する最悪のケースのブロック処理速度を低減するために、ルマおよびクロマの符号化ツリーにおける領域の許容される細分化のために異なる規則を利用してもよい。例えば、システム100は、ブロックのアスペクト比に関わらず、ブロックが常に16サンプルの倍数のサイズであるように動作してもよい。また、残差係数符号化は、2サンプルの幅または高さを有するブロックの場合を含めて、16の倍数のブロックサイズを利用してもよい。
システム100は、ソースデバイス110と、デスティネーションデバイス130とを含む。通信チャネル120は、ソースデバイス110からデスティネーションデバイス130に符号化されたビデオ情報を通信するために使用される。いくつかの取り決めでは、ソースデバイス110およびデスティネーションデバイス130のいずれかまたは両方が、それぞれの携帯電話ハンドセットまたは「スマートフォン」を構成してもよく、その場合、通信チャネル120は、無線チャネルである。他の構成では、ソースデバイス110およびデスティネーションデバイス130は、ビデオ会議装置で構成されてもよく、その場合、通信チャネル120は、典型的には、インターネット接続などの有線チャネルである。さらに、ソースデバイス110およびデスティネーションデバイス130は、オーバーザエアのテレビジョン放送、ケーブルテレビアプリケーション、インターネットビデオアプリケーション(ストリーミングを含む)、およびエンコードされたビデオデータがファイルサーバ内のハードディスクドライブのような何らかのコンピュータ読み取り可能な記憶媒体に取り込まれるアプリケーションをサポートするデバイスを含む、広範囲のデバイスのいずれかを構成してもよい。
図1に示すように、ソースデバイス110は、ビデオソース112、ビデオ符号化器114および送信機116を含む。ビデオソース112は、典型的には、画像キャプチャセンサ、非一時的記憶媒体に格納された以前にキャプチャされたビデオシーケンス、またはリモート画像キャプチャセンサからのビデオフィードなど、キャプチャされたビデオフレームデータのソース(113として示される)を構成する。また、ビデオソース112は、コンピュータグラフィックスカードの出力であってもよく、例えば、タブレットコンピュータなどのコンピューティングデバイス上で実行されるオペレーティングシステムや様々なアプリケーションのビデオ出力を表示するものである。ビデオソース112としてイメージキャプチャセンサを含むことができるソースデバイス110の例には、スマートフォン、ビデオカムコーダ、プロ用ビデオカメラ、およびネットワークビデオカメラが含まれる。
ビデオ符号化器114は、図3を参照してさらに説明したように、ビデオソース112からのキャプチャされたフレームデータ(矢印113で示す)を、ビットストリーム(矢印115で示す)に変換(または「符号化」)する。ビットストリーム115は、送信機116によって、符号化されたビデオデータ(または「符号化されたビデオ情報」)として、通信チャネル120を介して送信される。また、ビットストリーム115が、後で通信チャネル120を介して送信されるまで、または通信チャネル120を介した送信に代えて、「フラッシュ」メモリやハードディスクドライブなどの非一時的記憶装置122に記憶されることも可能である。
デスティネーションデバイス130は、受信機132、ビデオ復号化器134、および表示装置136を含む。受信機132は、通信路120から符号化されたビデオデータを受信し、受信したビデオデータをビットストリーム(矢印133で示す)としてビデオ復号化器134に渡す。そして、ビデオ復号化器134は、復号化されたフレームデータ(矢印135で示す)を表示装置136に出力する。復号化されたフレームデータ135は、フレームデータ113と同じクロマフォーマットを有する。表示装置136の例としては、陰極線管、スマートフォンやタブレットコンピュータ、コンピュータモニタ、あるいは単体のテレビに搭載されているような液晶ディスプレイなどが挙げられる。また、ソースデバイス110およびデスティネーションデバイス130のそれぞれの機能が単一のデバイスで具現化されることも可能であり、その例としては、携帯電話端末やタブレットコンピュータなどが挙げられる。
上述した例示的な装置にかかわらず、ソースデバイス110およびデスティネーションデバイス130のそれぞれは、典型的にはハードウェアおよびソフトウェアコンポーネントの組み合わせによって、汎用のコンピューティングシステム内に構成されてもよい。図2Aは、そのようなコンピュータシステム200を示しており、このコンピュータシステム200は、コンピュータモジュール201と、キーボード202、マウスポインタデバイス203、スキャナ226、ビデオソース112として構成されてもよいカメラ227、およびマイクロフォン280などの入力デバイスと、プリンタ215、表示装置136として構成されてもよい表示デバイス214、およびラウドスピーカ217などの出力デバイスと、を含む。外部の変調器-復調器(モデム)送受信機デバイス216は、接続221を介して通信ネットワーク220との間で通信するために、コンピュータモジュール201によって使用されてもよい。通信チャネル120を表し得る通信ネットワーク220は、インターネット、セルラー通信ネットワーク、またはプライベートWANなどの広域ネットワーク(WAN)であってもよい。接続221が電話回線である場合、モデム216は、従来の「ダイアルアップ」モデムであってもよい。あるいは、接続221が大容量(例えば、ケーブルまたは光)接続である場合、モデム216は、ブロードバンドモデムであってもよい。また、通信ネットワーク220への無線接続には、無線モデムを用いてもよい。送受信機デバイス216は、送信機116および受信機132の機能を提供してもよく、また、通信チャネル120は、接続221に具現化されてもよい。
コンピュータモジュール201は、典型的には、少なくとも1つのプロセッサユニット205と、メモリユニット206とを含む。例えば、メモリユニット206は、半導体ランダムアクセスメモリ(RAM)および半導体リードオンリーメモリ(ROM)を有していてもよい。また、コンピュータモジュール201は、ビデオディスプレイ214、ラウドスピーカ217およびマイクロフォン280に結合するオーディオ-ビデオインタフェース207、キーボード202、マウス203、スキャナ226、カメラ227および任意にジョイスティックまたは他のヒューマンインタフェースデバイス(図示せず)に結合するI/Oインタフェース213、および外部モデム216およびプリンタ215用のインタフェース208を含む多数の入出力(I/O)インタフェースを含む。オーディオビデオインタフェース207からコンピュータモニタ214への信号は、一般に、コンピュータグラフィックスカードの出力である。いくつかの実装では、モデム216は、例えばインタフェース208内で、コンピュータモジュール201内に組み込まれてもよい。コンピュータモジュール201はまた、ローカルネットワークインタフェース211を有し、これは、ローカルエリアネットワーク(LAN)として知られるローカルエリア通信ネットワーク222への接続223を介したコンピュータシステム200の結合を可能にする。図2Aに示されているように、ローカル通信ネットワーク222は、接続224を介して広域ネットワーク220に結合することもでき、これは、いわゆる「ファイアウォール」装置または同様の機能を有する装置を典型的に含むであろう。ローカルネットワークインタフェース211は、イーサネット(商標)回路カード、ブルートゥース(商標)無線装置、またはIEEE802.11無線装置で構成されてもよいが、インタフェース211については、他の多数のタイプのインタフェースが実施されてもよい。また、ローカルネットワークインタフェース211は、送信機116と受信機132の機能を提供してもよく、通信チャネル120もローカル通信ネットワーク222で具現化してもよい。
I/Oインタフェース208および213は、シリアルおよびパラレル接続のいずれかまたは両方を与えてもよく、前者は、典型的には、ユニバーサルシリアルバス(USB)規格に従って実装され、対応するUSBコネクタ(図示せず)を有する。ストレージデバイス209は、典型的にはハードディスクドライブ(HDD)210を含む。また、フロッピーディスクドライブや磁気テープドライブ(図示せず)などの他のストレージデバイスも使用することができる。光ディスクドライブ212は、典型的には、データの不揮発性ソースとして機能するために提供される。コンピュータシステム200への適切なデータソースとして、例えば、光ディスク(例えば、CD-ROM、DVD、ブルーレイディスク(商標))、USB-RAM、ポータブル、外付けハードドライブ、およびフロッピーディスクなどのポータブルメモリデバイスが使用されてもよい。典型的には、HDD210、光学ドライブ212、ネットワーク220および222のいずれもが、ビデオソース112として、またはディスプレイ214を介した再生のために保存される復号化されたビデオデータの宛先として動作するようにも構成され得る。システム100のソースデバイス110およびデスティネーションデバイス130は、コンピュータシステム200に具現化されてもよい。
コンピュータモジュール201のコンポーネント205~213は、典型的には、相互接続されたバス204を介して、関連技術者に知られているコンピュータシステム200の従来の動作モードをもたらす方法で通信する。例えば、プロセッサ205は、接続218を用いてシステムバス204に結合される。同様に、メモリ206および光ディスクドライブ212は、接続219によってシステムバス204に結合されている。記載された装置を実施することができるコンピュータの例には、IBM-PCおよび互換機、サンSPARCステーション、アップルMac(商標)または同様のコンピュータシステムが含まれる。
適切または所望の場合、ビデオ符号化器114およびビデオ復号化器134、ならびに以下に説明する方法は、コンピュータシステム200を使用して実施することができる。特に、ビデオ符号化器114、ビデオ復号化器134、および説明する方法は、コンピュータシステム200内で実行可能な1つまたは複数のソフトウェアアプリケーションプログラム233として実装されてもよい。特に、ビデオ符号化器114、ビデオ復号化器134、および説明する方法のステップは、コンピュータシステム200内で実行されるソフトウェア233内の命令231(図2B参照)によって効力を発揮する。ソフトウェアの命令231は、それぞれが1つまたは複数の特定のタスクを実行するための1つまたは複数のコードモジュールとして形成されてもよい。また、ソフトウェアは、2つの別々の部分に分割されてもよく、その場合、第1の部分および対応するコードモジュールは、説明した方法を実行し、第2の部分および対応するコードモジュールは、第1の部分とユーザとの間のユーザインタフェースを管理する。
ソフトウェアは、例えば、以下に説明する記憶装置を含むコンピュータ可読媒体に格納されてもよい。ソフトウェアは、コンピュータ可読媒体からコンピュータシステム200にロードされ、その後、コンピュータシステム200によって実行される。このようなソフトウェアまたはコンピュータプログラムが記録されたコンピュータ可読媒体は、コンピュータプログラム製品である。コンピュータシステム200におけるコンピュータプログラム製品の使用は、好ましくは、ビデオ符号化器114、ビデオ復号化器134および説明した方法を実施するための有利な装置をもたらす。
ソフトウェア233は、典型的には、HDD210またはメモリ206に格納される。ソフトウェアは、コンピュータ可読媒体からコンピュータシステム200にロードされ、コンピュータシステム200によって実行される。したがって、例えば、ソフトウェア233は、光ディスクドライブ212によって読み取られる光読取可能なディスク記憶媒体(例えば、CD-ROM)225に格納されていてもよい。
いくつかの例では、アプリケーションプログラム233は、1つまたは複数のCD-ROM225に符号化されてユーザに供給され、対応するドライブ212を介して読み取られてもよく、または代替的に、ネットワーク220または222からユーザによって読み取られてもよい。さらに、ソフトウェアは、他のコンピュータ可読媒体からコンピュータシステム200にロードすることもできる。コンピュータ可読記憶媒体とは、実行および/または処理のために、記録された命令および/またはデータをコンピュータシステム200に提供する任意の非一時的の有形記憶媒体を指す。このような記憶媒体の例には、フロッピーディスク、磁気テープ、CD-ROM、DVD、ブルーレイディスク(商標)、ハードディスクドライブ、ROMまたは集積回路、USBメモリ、光磁気ディスク、またはPCMCIAカード等のコンピュータ可読カードが含まれ、このようなデバイスがコンピュータモジュール201の内部にあるか外部にあるかは問わない。コンピュータモジュール401へのソフトウェア、アプリケーションプログラム、命令および/またはビデオデータもしくは符号化されたビデオデータの提供にも参加し得る一時的または非有形のコンピュータ可読伝送媒体の例としては、無線または赤外線の伝送路のほか、他のコンピュータまたはネットワークデバイスとのネットワーク接続、および電子メールの送信やWebサイトなどに記録された情報を含むインターネットまたはイントラネットなどが挙げられる。
上述したアプリケーションプログラム233の第2の部分および対応するコードモジュールは、ディスプレイ214上にレンダリングされるかまたは他の方法で表現される1つまたは複数のグラフィカルユーザインタフェース(GUI)を実装するために実行されてもよい。典型的にはキーボード202およびマウス203の操作を通じて、コンピュータシステム200およびアプリケーションのユーザは、GUI(複数可)に関連するアプリケーションに制御コマンドおよび/または入力を提供するために、機能的に適応可能な方法でインタフェースを操作することができる。また、ラウドスピーカ217を介して出力される音声プロンプトや、マイクロフォン280を介して入力されるユーザの音声コマンドを利用したオーディオインタフェースなど、機能的に適応可能なユーザインタフェースの他の形態も実装することができる。
図2Bは、プロセッサ205と「メモリ」234の詳細な概略ブロック図である。メモリ234は、図2Aのコンピュータモジュール201によってアクセス可能なすべてのメモリモジュール(HDD209および半導体メモリ206を含む)の論理的集約を表す。
コンピュータモジュール201の初期電源投入時には、電源オン自己テスト(POST)プログラム250が実行される。POSTプログラム250は、典型的には、図2Aの半導体メモリ206のROM249に格納されている。なお、ROM249のようにソフトウェアを格納するハードウェアデバイスをファームウェアと呼ぶことがある。POSTプログラム250は、コンピュータモジュール201内のハードウェアを検査して正しい機能を確保し、典型的には、プロセッサ205、メモリ234(209、206)、および同じく典型的にROM249に格納されている基本入出力システムソフトウェア(BIOS)モジュール251をチェックする。POSTプログラム250が正常に実行されると、BIOS251は、図2Aのハードディスクドライブ210を起動する。ハードディスクドライブ210の起動により、ハードディスクドライブ210に常駐しているブートストラップローダプログラム252がプロセッサ205を介して実行される。これにより、RAMメモリ206にオペレーティングシステム253がロードされ、これによりオペレーティングシステム253の動作が開始される。オペレーティングシステム253は、プロセッサ205によって実行可能なシステムレベルのアプリケーションであり、プロセッサ管理、メモリ管理、デバイス管理、ストレージ管理、ソフトウェアアプリケーションインタフェース、および汎用ユーザインタフェースを含む様々な高レベルの機能を果たすものである。
オペレーティングシステム253は、コンピュータモジュール201上で実行されている各プロセスまたはアプリケーションが、別のプロセスに割り当てられたメモリと衝突することなく実行するのに十分なメモリを有するように、メモリ234(209、206)を管理する。さらに、各プロセスが効果的に実行できるように、図2Aのコンピュータシステム200で利用可能な異なる種類のメモリを適切に使用しなければならない。したがって、集約されたメモリ234は、メモリの特定のセグメントがどのように割り当てられるかを説明することを意図したものではなく(特に断らない限り)、むしろ、コンピュータシステム200によってアクセス可能なメモリの一般的な見解と、そのようなものがどのように使用されるかを提供することを意図したものである。
図2Bに示すように、プロセッサ205は、制御部239、算術論理ユニット(ALU)240、およびキャッシュメモリと呼ばれることもあるローカルまたは内部メモリ248を含む多数の機能モジュールを含む。キャッシュメモリ248は、典型的には、レジスタ部に多数の記憶レジスタ244~246を含む。1つまたは複数の内部バス241は、これらの機能モジュールを機能的に相互接続する。また、プロセッサ205は、典型的には、接続218を用いて、システムバス204を介して外部装置と通信するための1つ以上のインタフェース242を有する。メモリ234は、接続219を用いてバス204に結合されている。
アプリケーションプログラム233は、条件付きの分岐命令およびループ命令を含むことができる一連の命令231を含む。また、プログラム233は、プログラム233の実行で使用されるデータ232を含んでもよい。命令231およびデータ232は、それぞれメモリ位置228、229、230および235、236、237に格納される。命令231およびメモリ位置228~230の相対的なサイズに応じて、メモリ位置230に示された命令によって描かれるように、特定の命令が単一のメモリ位置に格納されてもよい。代わりに、命令は、メモリ位置228および229に示される命令セグメントによって描かれるように、それぞれが別のメモリ位置に格納されるいくつかの部分にセグメント化されてもよい。
一般に、プロセッサ205は、その中で実行される命令のセットを与えられる。プロセッサ205は、後続の入力を待ち、これに対してプロセッサ205は、別の命令セットを実行することによって反応する。各入力は、入力装置202、203のうちの1つ以上によって生成されたデータ、ネットワーク220、202のうちの1つを介して外部ソースから受信されたデータ、ストレージデバイス206、209のうちの1つから取得されたデータ、または対応するリーダ212に挿入された記憶媒体225から取得されたデータを含む、多数のソースのうちの1つ以上から提供されてもよく、これらはすべて図2Aに描かれている。一連の命令の実行は、場合によっては、データの出力を伴うことがある。また、実行は、データまたは変数をメモリ234に格納することを含んでもよい。
ビデオ符号化器114、ビデオ復号化器134、および説明した方法は、対応するメモリ位置255、256、257においてメモリ234に格納される入力変数254を使用してもよい。ビデオ符号化器114、ビデオ復号化器134、および説明した方法は、出力変数261を生成し、これらは、対応するメモリ位置262、263、264でメモリ234に格納される。中間変数258は、メモリ位置259、260、266、267に格納されてもよい。
図2Bのプロセッサ205を参照すると、レジスタ244、245、246、算術論理ユニット(ALU)240、および制御部239は、プログラム233を構成する命令セット内のすべての命令について「フェッチ、デコード、および実行」サイクルを実行するために必要なマイクロオペレーションのシーケンスを実行するために協働する。各フェッチ、デコード、実行サイクルは以下を含む:
メモリ位置228、229、230から命令231をフェッチまたはリードするフェッチ動作、
制御部239が、どの命令がフェッチされたかを判断するデコード動作、および
制御部239および/またはALU240が命令を実行する実行動作。
その後、次の命令のさらなるフェッチ、デコード、および実行サイクルが実行されてもよい。同様に、制御部239がメモリ位置232に値を格納または書き込むストアサイクルが実行されてもよい。
これから説明する図10~図13の方法における各ステップまたはサブプロセスは、プログラム233の1つまたは複数のセグメントに関連付けられており、典型的には、プロセッサ205内のレジスタ部244、245、247、ALU240、および制御部239が協働して、プログラム233の指摘されたセグメントに対する命令セット内のすべての命令に対するフェッチサイクル、デコードサイクル、および実行サイクルを実行することによって実行される。
図3は、ビデオ符号化器114の機能モジュールを示す概略ブロック図である。図4は、ビデオ復号化器134の機能モジュールを示す概略ブロック図である。一般に、データは、ビデオ符号化器114内の機能モジュールとビデオ復号化器134内の機能モジュールとの間を、ブロックを固定サイズのサブブロックに分割したようなサンプルまたは係数のグループで、あるいはアレイとして通過する。ビデオ符号化器114およびビデオ復号化器134は、図2Aおよび図2Bに示すように、汎用コンピュータシステム200を用いて実装されてもよく、ここで、様々な機能モジュールは、コンピュータシステム200内の専用ハードウェアによって、ハードディスクドライブ205上に常駐するソフトウェアアプリケーションプログラム233の1つまたは複数のソフトウェアコードモジュールのようなコンピュータシステム200内で実行可能なソフトウェアによって実装され、プロセッサ205によってその実行が制御されてもよい。あるいは、ビデオ符号化器114およびビデオ復号化器134は、専用のハードウェアと、コンピュータシステム200内で実行可能なソフトウェアとの組み合わせによって実装されてもよい。ビデオ符号化器114、ビデオ復号化器134、および説明した方法は、代替的に、説明した方法の機能またはサブ機能を実行する1つまたは複数の集積回路などの専用ハードウェアで実装されてもよい。そのような専用ハードウェアは、グラフィックプロセッシングユニット(GPU)、デジタルシグナルプロセッサ(DSP)、特定用途向け標準製品(ASSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、または1つまたは複数のマイクロプロセッサおよび関連するメモリを含んでもよい。特に、ビデオ符号化器114はモジュール310~386を含み、ビデオ復号化器134はモジュール420~496を含み、それぞれがソフトウェアアプリケーションプログラム233の1つ以上のソフトウェアコードモジュールとして実装されてもよい。
図3のビデオ符号化器114は、多用途ビデオ符号化(VVC)のビデオ符号化パイプラインの一例であるが、本明細書で説明する処理ステージを実行するために、他のビデオコーデックを使用することもできる。ビデオ符号化器114は、一連のフレームのようなキャプチャされたフレームデータ113を受信し、各フレームは1つ以上のカラーチャネルを含む。フレームデータ113は、4:2:0クロマフォーマットであってもよいし、4:2:2クロマフォーマットであってもよい。ブロックパーティショナ310は、まず、フレームデータ113を、一般的に正方形の形状であり、CTUのための特定のサイズが使用されるように構成されたCTUに分割する。CTUのサイズは、例えば、64×64、128×128、または256×256のルマサンプルであってもよい。ブロックパーティショナ310は、さらに、各CTUを、ルマ符号化ツリーおよびクロマ符号化ツリーに従って、1つまたは複数のCBに分割する。CBは、様々なサイズを有し、正方形と非正方形の両方のアスペクト比を含んでもよい。ブロックパーティショナ310の動作については、図10を参照してさらに説明する。しかし、VVC規格では、CB、CU、PU、およびTUは、常に2の累乗である辺の長さを有する。したがって、312として表される現在のCBは、CTUのルマ符号化ツリーおよびクロマ符号化ツリーに従って、CTUの1つまたは複数のブロックに対する反復に従って進行し、ブロックパーティショナ310から出力される。CTUをCBにパーティショニングするためのオプションは、図5および図6を参照して以下にさらに説明される。
フレームデータ113の第1の分割から得られるCTUは、ラスタースキャン順にスキャンされてもよく、1つまたは複数の「スライス」にグループ化されてもよい。スライスは、「イントラ」(または「I」)スライスであってもよい。イントラスライス(Iスライス)は、スライス内のすべてのCUがイントラ予測されることを示す。あるいは、スライスは、一方向予測または双方向予測(それぞれ、「P」または「B」スライス)であってもよく、それぞれ、スライスにおける一方向予測および双方向予測の追加的な利用可能性を示す。
各CTUについて、ビデオ符号化器114は、2つのステージで動作する。第1ステージ(「検索」ステージと呼ばれる)では、ブロックパーティショナ310は、符号化ツリーの様々な潜在的な構成をテストする。符号化ツリーの各潜在的な構成は、関連する「候補」CBを有する。第1ステージでは、低歪みで高い圧縮効率を提供するCBを選択するために、様々な候補CBをテストする。このテストには一般的にラグランジュ最適化が含まれており、それによって候補CBはレート(符号化コスト)と歪み(入力フレームデータ113に対する誤差)の重み付けされた組み合わせに基づいて評価される。「最良」の候補CB(評価されたレート/歪みが最も小さいCB)は、その後のビットストリーム115への符号化のために選択される。候補CBの評価に含まれるのは、与えられた領域に対してCBを使用するか、または様々な分割オプションに従って領域をさらに分割し、小さくなった結果の領域のそれぞれをさらにCBで符号化するか、または領域をさらに分割するかというオプションである。結果として、CBと符号化ツリー自体の両方が検索ステージで選択される。
ビデオ符号化器114は、各CB、例えばCB312に対して、矢印320で示される予測ブロック(PB)を生成する。PB320は、関連するCB312の内容を予測したものである。減算器モジュール322は、PB320とCB312との間に、324(または、差が空間領域にあることを指して「残差」)として示される差を生成する。差分324は、PB320とCB312の対応するサンプル間のブロックサイズの差分である。差分324は、変換され、量子化され、矢印336で示される変換ブロック(TB)として表される。PB320および関連するTB336は、典型的には、例えば、評価されたコストまたは歪みに基づいて、多くの可能な候補CBの1つから選択される。
候補符号化ブロック(CB)は、関連するPBおよび結果としての残差に対してビデオ符号化器114が利用可能な予測モードの1つから生じるCBである。各候補CBは、図8を参照して以下に説明するように、1つまたは複数の対応するTBをもたらす。TB336は、差分324の量子化および変換された表現である。ビデオ復号化器114において予測されたPBと組み合わせると、TB336は、ビットストリームにおける追加のシグナリングを犠牲にして、復号されたCBと元のCB312との間の差を低減する。
各候補符号化ブロック(CB)、すなわち、変換ブロック(TB)と組み合わせた予測ブロック(PB)は、したがって、関連する符号化コスト(または「レート」)および関連する差分(または「歪み」)を有する。レートは通常、ビット単位で測定される。CBの歪みは、サンプル値の差、例えば、絶対差の和(SAD)や二乗差の和(SSD)として推定される。各候補PBから得られる推定値は、モードセレクタ386が差分324を用いてイントラ予測モードを決定する(矢印388で表す)。各候補予測モードおよび対応する残差符号化に関連する符号化コストの推定は、残差のエントロピー符号化よりも著しく低いコストで実行することができる。したがって、多数の候補モードを評価して、レート-歪みの意味で最適なモードを決定することができる。
レート歪みの意味での最適なモードの決定は、典型的にはラグランジュ最適化のバリエーションを用いて達成される。イントラ予測モード388の選択は、典型的には、特定のイントラ予測モードを適用した結果の残留データに対する符号化コストを決定することを含む。符号化コストは、ハダマード変換などの比較的単純な変換を用いて推定変換残差コストを求める「絶対変換差の和」(SATD)を用いて近似することができる。比較的単純な変換を使用するいくつかの実装では、簡略化された推定方法から得られるコストは、そうでなければ完全な評価から決定されるであろう実際のコストと単調に関連している。単調に関連する推定コストを有する実装では、簡略化された推定方法は、ビデオ符号化器114における複雑さを軽減して同じ決定(すなわちイントラ予測モード)を行うために使用され得る。推定コストと実際のコストとの間の関係において考えられる非単調性を許容するために、簡略化された推定方法は、最良の候補のリストを生成するために使用されてもよい。非単調性は、例えば、残留データの符号化に利用可能な更なるモード決定に起因する可能性がある。最良の候補のリストは、任意の数であってもよい。最良の候補を用いてより完全な探索を行い、候補のそれぞれについて残余データの符号化のための最適なモード選択を確立し、他のモード決定とともにイントラ予測モードの最終的な選択を可能にしてもよい。
他のモード決定には、「変換スキップ」として知られる前方変換をスキップする機能が含まれる。変換をスキップすることは、変換基底関数としての表現を介して符号化コストを低減するための十分な相関性を欠く残留データに適している。比較的単純なコンピュータで生成されたグラフィックスなどのある種のコンテンツも、同様の動作を示す。「スキップされた変換」では、変換自体が実行されていないにもかかわらず、残留係数は依然として符号化される。
ラグランジュまたは類似の最適化処理は、(ブロックパーティショナ310による)CTUのCBへの最適なパーティショニングの選択と、複数の可能性からの最良の予測モードの選択との両方に採用することができる。モードセレクタモジュール386における候補モードのラグランジュ最適化プロセスの適用により、最小のコスト測定を行うイントラ予測モードが「最良」モードとして選択される。「最良」モードは、選択されたイントラ予測モード388であり、また、エントロピー符号化器338によってビットストリーム115内に符号化される。モードセレクタモジュール386の動作によるイントラ予測モード388の選択は、ブロックパーティショナ310の動作にも及ぶ。例えば、イントラ予測モード388の選択の候補には、所定のブロックに適用されるモードと、集合的に所定のブロックとコロケーションされる複数のより小さなブロックに適用される追加的なモードとが含まれ得る。所与のブロックおよびより小さなコロケーションされたブロックに適用されるモードを含む場合、候補の選択プロセスは、暗黙的に、CBへのCTUの最適な階層的分解を決定するプロセスでもある。
ビデオ符号化器114の動作の第2ステージ(「符号化」ステージと呼ばれる)では、選択されたルマ符号化ツリーおよび選択されたクロマ符号化ツリー、したがって選択された各CBに対する反復が、ビデオ符号化器114において実行される。反復では、本明細書でさらに説明するように、CBがビットストリーム115に符号化される。
エントロピー符号化器338は、シンタックス要素の可変長符号化と、シンタックス要素の算術符号化の両方をサポートする。算術符号化は、コンテキスト適応型のバイナリ算術符号化プロセスを使用してサポートされる。算術符号化されたシンタックス要素は、1つまたは複数の「ビン」のシーケンスで構成される。ビンは、ビットと同様に、「0」または「1」の値を持つ。しかし、ビンは、ビットストリーム115内で個別のビットとしてエンコードされない。ビンは、「コンテキスト」と呼ばれる、関連する予測値(または「可能性が高い」または「最も可能性が高い」)および関連する確率を有する。符号化される実際のビンが予測値と一致した場合、「最も可能性の高いシンボル」(MPS)が符号化される。最も可能性の高いシンボルの符号化は、消費されるビット数が少なくて済む。符号化されるべき実際のビンが可能性の高い値と不一致である場合、「最小確率シンボル」(LPS)が符号化される。最小確率シンボルの符号化は、消費するビット数の点で比較的高いコストがかかる。ビン符号化技術は、「0」と「1」の確率が偏っているビンを効率的にコード化することができる。2つの可能な値を持つシンタックス要素(つまり「フラグ」)の場合、1つのビンで十分である。多くの可能な値を持つシンタックス要素の場合、一連のビンが必要である。
シーケンス内の後のビンの存在は、シーケンス内の以前のビンの値に基づいて決定されてもよい。さらに、各ビンは2つ以上のコンテキストと関連していてもよい。特定のコンテキストの選択は、シンタックス要素の以前のビン、隣接するシンタックス要素(すなわち、隣接するブロックからのもの)のビンの値などに依存することができる。コンテキスト符号化されたビンが符号化されるたびに、そのビンに対して選択されたコンテキスト(もしあれば)は、新しいビンの値を反映した方法で更新される。このように、二値算術符号化スキームは、適応的であると言われる。
また、ビデオ符号化器114によってサポートされるのは、コンテキストを持たないビン(「バイパスビン」)である。バイパスビンは、「0」と「1」との間の等身大の分布を仮定して符号化される。したがって、各ビンは、ビットストリーム115の1ビットを占める。コンテキストがないことで、メモリを節約し、複雑さを軽減することができ、したがって、バイパスビンは、特定のビンの値の分布が歪んでいないところで使用される。コンテキストおよび適応を採用するエントロピー符号化器の一例は、CABAC(Context Adaptive Binary Arithmetic Coder)として当技術分野で知られており、この符号化器の多くの変形がビデオ符号化に採用されている。
エントロピー符号化器338は、コンテキスト符号化されたビンとバイパス符号化されたビンの組み合わせを使用して、イントラ予測モード388を符号化する。典型的には、ビデオ符号化器114において、「最も確率の高いモード」のリストが生成される。最も確率の高いモードのリストは、典型的には、3つまたは6つのモードのような固定長であり、以前のブロックで遭遇したモードを含むことができる。コンテキスト符号化されたビンは、イントラ予測モードが最も確率の高いモードの1つであるかどうかを示すフラグを符号化する。イントラ予測モード388が最も確率の高いモードの1つである場合、バイパス符号化されたビンを使用して、さらなるシグナリングが符号化される。符号化された更なるシグナリングは、例えば、切り捨てられた1項ビン文字列を用いて、どの最も確率の高いモードがイントラ予測モード388に対応するかを示している。そうでなければ、イントラ予測モード388は、「残りのモード」として符号化される。残りのモードとしての符号化は、固定長コードのような代替シンタックスを使用し、同じくバイパスコード化されたビンを使用して符号化され、最確モードリストに存在するモード以外のイントラ予測モードを表現する。
マルチプレクサモジュール384は、決定された最良のイントラ予測モード388に従って、各候補CBのテストされた予測モードから選択してPB320を出力する。候補予測モードは、ビデオ符号化器114によってサポートされるすべての考えられる予測モードを含む必要はない。
予測モードは、大まかに2つのカテゴリに分類される。第1のカテゴリは、「フレーム内予測」(「イントラ予測」とも呼ばれる)である。フレーム内予測では、ブロックに対する予測が生成され、生成方法は、現在のフレームから得られた他のサンプルを使用してもよい。イントラ予測されたPBについては、ルマとクロマに対して異なるイントラ予測モードを使用することが可能であり、したがって、イントラ予測は主にPBに対する動作の観点から説明される。
予測モードの第2のカテゴリは、「フレーム間予測」(「インター予測」とも呼ばれる)である。フレーム間予測では、ビットストリーム内の符号化フレームの順序で、現在のフレームに先行する1つまたは2つのフレームからのサンプルを使用して、ブロックの予測が生成される。さらに、フレーム間予測では、通常、単一の符号化ツリーがルマチャネルとクロマチャネルの両方に使用される。ビットストリーム内の符号化フレームの順序は、撮影時や表示時のフレームの順序とは異なる場合がある。予測に1つのフレームが使用される場合、そのブロックは「一方向予測」と呼ばれ、1つの動きベクトルが関連付けられる。予測に2つのフレームが使用された場合、ブロックは「双方向予測」と呼ばれ、2つの関連する動きベクトルを持つ。Pスライスの場合、各CUは、イントラ予測または一方向予測される。Bスライスの場合、各CUは、イントラ予測、一方向予測、または双方向予測のいずれかである。フレームは、通常、「ピクチャグループ」構造を用いて符号化され、フレームの時間的な階層化を可能にする。フレームの時間的な階層化により、フレームは、フレームを表示する順序で、先行する画像と後続する画像を参照することができる。画像は、各フレームを復号化するための依存関係を確実に満たすために必要な順序で符号化される。
インター予測のサブカテゴリは、「スキップモード」と呼ばれる。インター予測モードとスキップモードは、2つの異なるモードとして説明されている。しかし、インター予測モードおよびスキップモードの両方は、先行するフレームからのサンプルのブロックを参照する動きベクトルを含む。インター予測では、動きベクトル予測器に対する動きベクトルを指定する、符号化された動きベクトルデルタが必要である。動きベクトル予測器は、「マージインデックス」で選択された1つまたは複数の候補動きベクトルのリストから取得される。符号化された動きベクトルデルタは、選択された動きベクトル予測に対する空間オフセットを提供する。また、インター予測は、ビットストリーム133の符号化された残差を使用する。スキップモードは、インデックス(「マージインデックス」とも呼ばれる)のみを使用して、複数の動きベクトル候補のうちの1つを選択する。選択された候補は、さらなるシグナリングなしに使用される。また、スキップモードは、いかなる残留係数の符号化もサポートしない。スキップモードが使用されるときに符号化された残余係数がないということは、スキップモードのための変換を実行する必要がないことを意味する。したがって、スキップモードは通常、パイプライン処理の問題を引き起こすことはない。パイプライン処理の問題は、イントラ予測されたCUとインター予測されたCUの場合に生じる可能性がある。スキップモードのシグナリングが制限されているため、スキップモードは、比較的高品質の参照フレームが利用可能な場合に、非常に高い圧縮性能を実現するのに有効である。ランダムアクセスピクチャグループ構造のより高い時間的層における双方向予測CUは、典型的には、高品質の参照ピクチャおよび基礎的な動きを正確に反映する動きベクトル候補を有する。
サンプルは、動きベクトルおよび参照ピクチャインデックスに応じて選択される。動きベクトルおよび参照ピクチャインデックスは、すべてのカラーチャネルに適用され、したがって、インター予測は、主にPBではなくPUに対する動作の観点から説明される。各カテゴリ(つまり、フレーム内予測とフレーム間予測)において、PUを生成するために異なる技術を適用することができる。例えば、イントラ予測は、以前に再構成されたサンプルの隣接する行および列からの値を、所定のフィルタリングおよび生成プロセスに従ってPUを生成するための指示と組み合わせて使用してもよい。あるいは、PUは、少数のパラメータを用いて記述されてもよい。インター予測は、動きパラメータの数およびその精度が異なる場合がある。動きパラメータは、典型的には、参照フレームのリストからどの参照フレームを使用するかを示す参照フレームインデックスと、参照フレームのそれぞれに対する空間変換とからなるが、より多くのフレーム、特殊なフレーム、またはスケーリングやローテーションなどの複雑なアフィンパラメータを含んでいてもよい。さらに、参照されたサンプルブロックに基づいて密な動き推定値を生成するために、所定の動きリファインメント処理を適用してもよい。
「最良の」PB320を決定して選択し、減算器322で元のサンプルブロックからPB320を減算したところで、324と表される符号化コストが最も低い残差が得られ、非可逆圧縮にかけられる。非可逆圧縮処理は、変換、量子化、エントロピー符号化の各ステップからなる。変換モジュール326は、差分324に前方変換を適用し、差分324を周波数領域に変換し、矢印332で表される変換係数を生成する。順方向変換は、典型的には分離可能であり、各ブロックの行のセットを変換し、次に列のセットを変換する。行および列の各セットの変換は、まずブロックの各行に一次元変換を適用して部分的な結果を生成し、次に部分的な結果の各列に適用して最終的な結果を生成することによって行われる。
変換係数332は、量子化モジュール334に渡される。モジュール334では、矢印336で表される残差係数を生成するために、「量子化パラメータ」に従った量子化が実行される。量子化パラメータは、所与のTBに対して一定であり、したがって、TBに対する残差係数の生成のための一様なスケーリングをもたらす。非一様なスケーリングは、「量子化マトリクス」の適用によっても可能であり、それによって、各残差係数に適用されるスケーリング係数は、量子化パラメータと、典型的にはTBのサイズと等しいサイズを有するスケーリングマトリクスの対応するエントリとの組み合わせから得られる。残留係数336は、ビットストリーム115内で符号化するために、エントロピー符号化器338に供給される。典型的には、TUの少なくとも1つの有意な残差係数を有する各TBの残差係数は、スキャンパターンに従って、値の順序付けられたリストを生成するためにスキャンされる。スキャンパターンは、一般的に、4×4の「サブブロック」のシーケンスとしてTBをスキャンし、残差係数の4×4セットの粒度で規則的なスキャン動作を提供し、サブブロックの配置はTBのサイズに依存している。さらに、予測モード388および対応するブロック分割も、ビットストリーム115に符号化される。
上述したように、ビデオ符号化器114は、ビデオ復号化器134で見られるフレーム表現に対応するフレーム表現へのアクセスを必要とする。したがって、残差係数336はまた、逆量子化モジュール340によって逆量子化され、矢印342で表される逆変換係数を生成する。逆変換係数342は、逆変換モジュール348に通されて、矢印350で表されるTUの残留サンプルを生成する。和算モジュール352は、残差サンプル350とPU320とを加算して、CUの再構成サンプル(矢印354で示される)を生成する。
再構成されたサンプル354は、基準サンプルキャッシュ356およびインループフィルタモジュール368に渡される。参照サンプルキャッシュ356は、典型的にはASIC上のスタティックRAMを使用して実装され(したがって、コストのかかるオフチップメモリアクセスを回避する)、フレーム内の後続のCUに対するフレーム内PBを生成するための依存関係を満たすために必要な最小限のサンプルストレージを提供する。最小限の依存性には、次の行のCTUで使用するための、CTUの行の底部に沿ったサンプルの「ラインバッファ」や、CTUの高さによって設定されるカラムバッファが含まれる。参照サンプルキャッシュ356は、参照サンプル(矢印358で表される)を参照サンプルフィルタ360に供給する。サンプルフィルタ360は、平滑化操作を適用して、フィルタリングされた参照サンプル(矢印362で示される)を生成する。フィルタリングされた参照サンプル362は、フレーム内予測モジュール364によって使用され、矢印366で表されるサンプルのイントラ予測ブロックを生成する。各候補のイントラ予測モードについて、フレーム内予測モジュール364は、366であるサンプルのブロックを生成する。
インループフィルタモジュール368は、再構成されたサンプル354にいくつかのフィルタリングステージを適用する。フィルタリングステージは、不連続性から生じるアーティファクトを低減するためにCU境界に整列した平滑化を適用する「デブロッキングフィルタ」(DBF)を含む。インループフィルタモジュール368に存在する別のフィルタリングステージは、「適応ループフィルタ」(ALF)であり、これは、ウィーナーベースの適応フィルタを適用して歪みをさらに低減する。インループフィルタモジュール368に存在する別のフィルタリングステージは、「サンプル適応オフセット」(SAO)フィルタである。SAOフィルタは、まず、再構成されたサンプルを1つまたは複数のカテゴリに分類し、割り当てられたカテゴリに応じて、サンプルレベルでオフセットを適用することによって動作する。
矢印370で表されるフィルタリングされたサンプルは、インループフィルタモジュール368から出力される。フィルタリングされたサンプル370は、フレームバッファ372に格納される。フレームバッファ372は、典型的には、複数(例えば16枚まで)のピクチャを格納する容量を有し、したがって、メモリ206に格納される。フレームバッファ372は、必要なメモリ消費量が大きいため、典型的にはオンチップメモリを使用して格納されない。そのため、フレームバッファ372へのアクセスは、メモリの帯域幅の点でコストがかかる。フレームバッファ372は、基準フレーム(矢印374で表される)を動き推定モジュール376および動き補償モジュール380に提供する。
動き推定モジュール376は、フレームバッファ372内の参照フレームの1つのブロックを参照して、それぞれが本CBの位置からのデカルト空間オフセットである多数の「動きベクトル」(378として示される)を推定する。参照サンプルのフィルタリングされたブロック(382として示される)は、各動きベクトルに対して生成される。フィルタリングされた参照サンプル382は、モードセレクタ386による潜在的な選択に利用可能な更なる候補モードを形成する。さらに、所定のCUについて、PU320は、1つの参照ブロックを用いて形成されてもよいし(「一方向予測」)、2つの参照ブロックを用いて形成されてもよい(「双方向予測」)。選択された動きベクトルに対して、動き補償モジュール380は、動きベクトルのサブピクセル精度を支持するフィルタリング処理に従って、PB320を生成する。このように、動き推定モジュール376(多くの候補の動きベクトルで動作する)は、動き補償モジュール380(選択された候補のみで動作する)のフィルタリング処理と比較して、簡略化されたフィルタリング処理を実行して、計算複雑性の低減を達成することができる。
図3のビデオ符号化器114は、多用途ビデオ符号化(VVC)を参照して説明されているが、他のビデオ符号化規格または実装も、モジュール310~386の処理ステージを採用してもよい。また、フレームデータ113(およびビットストリーム115)は、メモリ206、ハードディスクドライブ210、CD-ROM、Blu-rayディスク(商標)、またはその他のコンピュータ可読記憶媒体から読み出されて(または書き込まれて)もよい。さらに、フレームデータ113(およびビットストリーム115)は、通信ネットワーク220に接続されたサーバや無線周波数受信機などの外部から受信されて(または送信されて)もよい。
ビデオ復号化器134を図4に示す。図4のビデオ復号化器134は、多用途ビデオ符号化(VVC)ビデオ復号化パイプラインの一例であるが、本明細書で説明する処理ステージを実行するために、他のビデオコーデックを使用することもできる。図4に示すように、ビデオ復号化器134には、ビットストリーム133が入力される。ビットストリーム133は、メモリ206、ハードディスクドライブ210、CD-ROM、Blu-rayディスク(商標)、またはその他の非一時的なコンピュータ可読記憶媒体から読み取られてもよい。あるいは、ビットストリーム133は、通信ネットワーク220に接続されたサーバや無線周波数受信機などの外部ソースから受信されてもよい。ビットストリーム133は、復号化されるべきキャプチャされたフレームデータを表す符号化されたシンタックス要素を含む。
ビットストリーム133は、エントロピー復号化器モジュール420に入力される。エントロピー復号化器モジュール420は、ビットストリーム133からシンタックス要素を抽出し、シンタックス要素の値をビデオ復号化器134の他のモジュールに渡す。エントロピー復号化器モジュール420は、CABACアルゴリズムを適用して、ビットストリーム133からシンタックス要素を復号する。復号化されたシンタックス要素は、ビデオ復号化器134内のパラメータを再構築するために使用される。パラメータには、残差係数(矢印424で表される)およびイントラ予測モードなどのモード選択情報(矢印458で表される)が含まれる。また、モード選択情報には、動きベクトルなどの情報や、各CTUを1つ以上のCBに分割することも含まれる。パラメータは、典型的には、以前に復号化されたCBからのサンプルデータと組み合わせて、PBを生成するために使用される。
残差係数424は、逆量子化モジュール428に入力される。逆量子化モジュール428は、残差係数424に対して逆量子化(または「スケーリング」)を実行して、量子化パラメータに従って、矢印440で表される再構成された変換係数を作成する。不均一な逆量子化マトリクスの使用がビットストリーム133で示される場合、ビデオ復号化器134は、スケーリング係数のシーケンスとしてビットストリーム133から量子化マトリクスを読み取り、スケーリング係数をマトリクスに配列する。逆スケーリングは、量子化マトリクスを量子化パラメータと組み合わせて使用し、再構成された変換係数440を作成する。
再構成された変換係数440は、逆変換モジュール444に渡される。モジュール444は、係数を周波数領域から空間領域に戻して変換する。TBは、有意な残差係数および有意でない残差係数値に基づいて効果的に行われる。モジュール444の動作の結果は、矢印448で表される残差サンプルのブロックである。残差サンプル448は、対応するCUと等しいサイズである。残差サンプル448は、和算モジュール450に供給される。和算モジュール450において、残留サンプル448は、復号化されたPB(452として表される)に追加され、矢印456で表される再構成されたサンプルのブロックを生成する。再構成されたサンプル456は、再構成されたサンプルキャッシュ460およびインループフィルタリングモジュール488に供給される。インループフィルタリングモジュール488は、492で表されるフレームサンプルの再構成されたブロックを生成する。フレームサンプル492は、フレームバッファ496に書き込まれる。
再構成されたサンプルキャッシュ460は、ビデオ符号化器114の再構成されたサンプルキャッシュ356と同様に動作する。再構成サンプルキャッシュ460は、メモリ206を使用せずに(例えば、典型的なオンチップメモリであるデータ232を代わりに使用することによって)、後続のCBをイントラ予測するために必要な再構成サンプルのストレージを提供する。矢印464で表される参照サンプルは、再構成サンプルキャッシュ460から得られ、参照サンプルフィルタ468に供給されて、矢印472で示されるフィルタリングされた参照サンプルを生成する。フィルタリングされた参照サンプル472は、フレーム内予測モジュール476に供給される。モジュール476は、ビットストリーム133にシグナリングされたイントラ予測モードパラメータ458に従って、矢印480で示されるイントラ予測サンプルのブロックを生成し、エントロピー復号化器420によって復号化される。
イントラ予測が現在のCBについてビットストリーム133に示されている場合、イントラ予測されたサンプル480は、マルチプレクサモジュール484を介して、復号されたPB452を形成する。
インター予測が現在のCBのためのビットストリーム133において指示される場合、動き補償モジュール434は、フレームバッファ496からのサンプルのブロックを選択してフィルタリングするために、動きベクトルおよび参照フレームインデックスを使用して、438として表されるインター予測されたサンプルのブロックを生成する。サンプルのブロック498は、フレームバッファ496に格納された前に復号化されたフレームから得られる。双方向予測のために、サンプルの2つのブロックが生成され、一緒にブレンドされて、復号化されたPB452のためのサンプルを生成する。フレームバッファ496には、インループフィルタリングモジュール488からのフィルタリングされたブロックデータ492が入力される。ビデオ符号化器114のインループフィルタリングモジュール368と同様に、インループフィルタリングモジュール488は、DBF、ALFおよびSAOのフィルタリング動作のいずれか、少なくとも、またはすべてを適用する。インループフィルタリングモジュール368は、再構成されたサンプル456から、フィルタリングされたブロックデータ492を生成する。
図5は、多用途ビデオ符号化のツリー構造において、1つの領域を1つ以上のサブ領域に分割する利用可能な分割または分割のコレクション500を示す概略ブロック図である。コレクション500に示される分割は、図3を参照して説明したように、ラグランジュ最適化によって決定されるように、符号化ツリーに従って各CTUを1つまたは複数のCUまたはCBに分割するために、符号化器114のブロックパーティショナ310が利用可能である。
コレクション500は、正方形の領域が他の、おそらく非正方形のサブ領域に分割されることのみを示しているが、図500は、潜在的な分割を示しているが、含有領域が正方形であることを要求していないことを理解すべきである。含まれる領域が非正方形である場合、分割の結果得られるブロックの寸法は、含まれるブロックのアスペクト比に応じてスケーリングされる。ある領域がさらに分割されない場合、つまり符号化ツリーのリーフノードでは、CUがその領域を占有する。ブロックパーティショナ310によるCTUの1つまたは複数のCUへの特定の細分化は、CTUの「符号化ツリー」と呼ばれる。領域をサブ領域に細分化するプロセスは、結果として生じるサブ領域が最小のCUサイズに達したときに終了しなければならない。CUは、例えば4×4より小さいサイズを禁止するだけでなく、幅または高さの最小値が4であるように制約されている。これ以外にも、幅と高さの両方、または幅と高さの両方の最小値を設定することも可能である。細分化のプロセスは、最も深いレベルの分解の前に終了することもあり、その結果、最小のCUサイズよりも大きいCUができる。分割が行われず、1つのCUがCTUの全体を占めることも可能である。CTUの全体を占める単一のCUは、利用可能な最大の符号化ユニットサイズとなる。さらに、分割が行われないCUは、処理領域のサイズよりも大きくなる。符号化ツリーの最上位レベルで2値または3値の分割が行われた結果、64x128、128x64、32x128、128x32などのCUサイズが可能となり、それぞれが処理領域サイズよりも大きくなる。処理領域サイズよりも大きいCUSの例については、図10を参照してさらに説明する。
符号化ツリーのリーフノードには、それ以上細分化されていないCUが存在する。例えば、リーフノード510は、1つのCUを含む。符号化ツリーの非リーフノードには、2つ以上のさらなるノードへの分割のいずれかが存在し、その各々は、こうして1つのCUを含むリーフノードを含むか、またはより小さい領域へのさらなる分割を含むことができる。
クワッドツリー分割512は、図5に示すように、包含領域を4つの等しいサイズの領域に分割する。HEVCと比較して、多用途ビデオ符号化(VVC)は、水平2分割514および垂直2分割516の追加により、さらなる柔軟性を達成する。分割514と516のそれぞれは、含まれる領域を2つの同じサイズの領域に分割する。分割は、包含ブロック内の水平境界(514)または垂直境界(516)に沿って行われる。
多用途ビデオ符号化では、3分割の水平分割518と3分割の垂直分割520を追加することで、さらなる柔軟性が得られる。3分割518および520は、ブロックを、含有領域の幅または高さの1/4および3/4に沿って水平(518)または垂直(520)のいずれかに境界づけられた3つの領域に分割する。四分木、二分木、三分木の組み合わせは、「QTBTTT」と呼ばれる。ツリーのルートには、ゼロまたはそれ以上のクワッドツリーの分割(ツリーの「QT」セクション)が含まれる。QTセクションが終了すると、ゼロまたはそれ以上の2分割または3分割が発生し(ツリーの「マルチツリー」または「MT」セクション)、最終的にツリーのリーフノードでCBまたはCUで終了する。ツリーがすべてのカラーチャネルを記述している場合、ツリーのリーフノードはCUとなります。ツリーがルマチャネルまたはクロマチャネルを記述する場合、ツリーのリーフノードはCBである。
四分木のみをサポートし、したがって四角いブロックのみをサポートするHEVCと比較して、QTBTTTは、特に二分木および/または三分木の分割を再帰的に適用する可能性を考慮すると、より多くの可能なCUサイズをもたらす。ブロックの幅または高さが4サンプル未満または4サンプルの倍数にならない分割を排除するように分割オプションを制限することで、通常とは異なる(正方形ではない)ブロックサイズの可能性を減らすことができる。一般的に、この制約はルマサンプルを考慮して適用される。しかし、ここで説明する方法では、クロマチャネルのブロックに個別に制約を適用することができる。例えば、フレームデータが4:2:0クロマフォーマットまたは4:2:2クロマフォーマットの場合、クロマチャネルの分割オプションに制約を適用すると、ルマとクロマの最小ブロックサイズが異なることになる。各分割では、包含する領域に対して横方向の寸法が変わらないか、半分になるか、4分の1になるかのサブ領域が生成される。そして、CTUのサイズは2の累乗であるため、すべてのCUの側面寸法も2の累乗となる。
図6は、多用途ビデオ符号化で使用されるQTBTTT(または「符号化ツリー」)構造のデータフロー600を示す概略フロー図である。QTBTTT構造は、CTUの1つまたは複数のECUへの分割を定義するために、各CTUに対して使用される。各CTUのQTBTTT構造は、ビデオ符号化器114内のブロックパーティショナ310によって決定され、ビデオ復号化器134内のエントロピー復号化器420によって、ビットストリーム115に符号化されるか、またはビットストリーム133から復号化される。データフロー600はさらに、図5に示す分割に従って、CTUを1つまたは複数のCUに分割するためにブロックパーティショナ310が利用できる許容可能な組み合わせを特徴とする。
階層の最上位レベル、すなわちCTUから出発して、まずゼロまたは複数のクアッドツリー分割が実行される。具体的には、クアッドツリー(QT)分割の決定610が、ブロックパーティショナ310によって行われる。「1」シンボルを返す610での決定は、クアッドツリー分割512に従って、現在のノードを4つのサブノードに分割する決定を示す。その結果、620でのように、4つの新しいノードが生成され、各新しいノードについて、QT分割決定610に再帰する。各新しいノードは、ラスタ(またはZスキャン)の順序で考慮される。あるいは、QT分割決定610が、さらなる分割を行わないことを示す(「0」シンボルを返す)場合、クアッドツリー分割は停止し、続いてマルチツリー(MT)分割が検討される。
まず、ブロックパーティショナ310によって、MT分割決定612が行われる。612では、MT分割を行うかどうかの決定が示される。決定612で「0」シンボルを返すことは、ノードのサブノードへのさらなる分割を実行しないことを示す。ノードのさらなる分割が実行されない場合、そのノードは、符号化ツリーのリーフノードであり、CUに対応する。リーフノードは622で出力される。あるいは、MT分割612がMT分割を実行する決定を示す(「1」シンボルを返す)場合、ブロックパーティショナ310は、方向決定614に進む。
方向決定614は、MT分割の方向を、水平(「H」または「0」)または垂直(「V」または「1」)のいずれかとして示す。ブロックパーティショナ310は、決定614が水平方向を示す「0」を返した場合、決定616に進む。ブロックパーティショナ310は、決定614が垂直方向を示す「1」を返した場合、決定618に進む。
決定616、618のそれぞれにおいて、MT分割の分割数は、BT/TT分割では、2つ(2分割または「BT」ノード)または3つ(3分割または「TT」)のいずれかが示される。すなわち、614からの指示方向が水平の場合には、ブロックパーティショナ310によってBT/TT分割決定616が行われ、614からの指示方向が垂直の場合には、ブロックパーティショナ310によってBT/TT分割決定618が行われる。
BT/TT分割決定616は、水平分割が、「0」を返すことで示される2分割514であるか、「1」を返すことで示される3分割518であるかを示す。BT/TT分割決定616が2分割を示す場合、HBT CTUノード生成ステップ625において、水平2分割514に応じて、ブロックパーティショナ310により2つのノードが生成される。BT/TT分割616が3分割を示すとき、生成HTT_CTUノードステップ626において、水平3分割518に従って、3つのノードがブロックパーティショナ310によって生成される。
BT/TT分割決定618は、垂直分割が、「0」を返すことで示される2分割516であるか、「1」を返すことで示される3分割520であるかを示す。BT/TT分割618が2分割を示す場合、VBT_CTUノード生成ステップ627において、ブロックパーティショナ310により、垂直2分割516に応じて2つのノードが生成される。BT/TT分割618が3分割を示す場合、生成VTT_CTUノードステップ628において、垂直3分割520に従って、ブロックパーティショナ310によって3つのノードが生成される。ステップ625~628から得られる各ノードに対して、方向614に応じて、左から右または上から下の順序で、MT分割決定612に戻るデータフロー600の再帰が適用される。結果として、二分木および三分木の分割は、様々なサイズを有するCUを生成するために適用され得る。
符号化木の各ノードで許可される分割と許可されない分割のセットについて、図9を参照してさらに説明する。
図7Aおよび7Bは、CTU710を多数のCUまたはCBに分割する例示的な分割700を提供する。例示的なCU712が、図7Aに示されている。図7Aは、CTU710におけるCUの空間的配置を示す。また、例示的な分割700は、図7Bに符号化ツリー720として示されている。
図7AのCTU710の各非リーフノード、例えばノード714、716および718において、含まれるノード(さらに分割されてもよいし、CUであってもよい)が「Zオーダ」にスキャンまたはトラバースされて、符号化ツリー720の列として表されるノードのリストが作成される。四分木の分割の場合、Zオーダスキャンは、左上から右へ、続いて左下から右への順に行われる。水平分割および垂直分割の場合、Zオーダスキャン(トラバーサル)は、それぞれ上から下へのスキャンおよび左から右へのスキャンに単純化される。図7Bの符号化ツリー720は、適用されたスキャン順序に従って、すべてのノードおよびCUをリストアップする。各分割は、リーフノード(CU)に到達するまで、ツリーの次のレベルで2つ、3つ、または4つの新しいノードのリストを生成する。
ブロックパーティショナ310によって画像をCTUに分解し、さらにCUに分解し、図3を参照して説明したようにCUを使用して各残留ブロック(324)を生成した後、残留ブロックはビデオ符号化器114によって前方変換および量子化の対象となる。結果として得られるTB336は、その後、エントロピー符号化モジュール338の動作の一部として、残差係数のシーケンシャルリストを形成するためにスキャンされる。ビットストリーム133からTBを得るために、ビデオ復号化器134において同等の処理が行われる。
図7Aおよび図7Bの例では、ルマチャネルおよびクロマチャネルの両方に適用される符号化ツリーを説明している。しかし、図7Aおよび図7Bの例は、ルマチャネルだけに適用される符号化ツリーまたはクロマチャネルだけに適用される符号化ツリーのトラバーサルの観点からの動作も示している。多くの入れ子になった分割を持つ符号化ツリーの場合、より深いレベルで利用可能な分割オプションは、対応する小領域の利用可能なブロックサイズの制限によって制約を受ける。小領域で利用可能なブロックサイズの制限は、ブロックの処理速度が高すぎて実装に負担がかかるという最悪のケースを防ぐために設けられている。具体的には、ブロックサイズをクロマの16の倍数にすることで、16サンプルの粒度で処理することが可能になる。ブロックサイズを16サンプルの倍数に制約することは、「イントラ再構成」フィードバックループ、すなわち、モジュール450、460、468、476、484を含む図4のビデオ復号化器134内のパス、およびビデオ符号化器114内の同等のパスに特に関連する。特に、ブロックサイズを16サンプルの倍数に制約することは、イントラ予測モードでのスループットを維持することを支援する。例えば、「SIMD(Simultaneous Data Multiple Instruction)」マイクロプロセッサアーキテクチャは、一般的に、16サンプルを含む可能性のあるワイドワードで動作する。また、ハードウェアアーキテクチャでは、イントラ再構成フィードバックループに沿ってサンプルを転送するために、16サンプルの幅を持つバスなど、広いバスを使用することができる。例えば4サンプルのような小さなブロックサイズを使用した場合、バスは十分に活用されず、例えばバス幅の1/4にしかサンプルデータが含まれないことになる。活用されていないバスは、より小さなブロック(つまり、16サンプル以下)を扱うことができるが、多くのブロックまたはすべてのブロックが比較的小さなサイズであるなどの最悪のケースでは、活用されていないために、符号化器(114)または復号化器(134)のリアルタイム動作が妨げられる可能性がある。インター予測では、各ブロックは、フレームバッファ(バッファ372または496など)から得られる参照サンプルに依存する。フレームバッファには、先行するフレームを処理する際に参照サンプルが入力されるため、インター予測のブロックを生成するためのブロック単位の動作に影響を与えるフィードバック依存ループは存在しない。フレーム内再構成に関連するフィードバック依存ループに加えて、イントラ予測モード458の決定に関連する追加の同時のフィードバックループが存在する。イントラ予測モード458は、最も確率の高いモードリストからモードを選択すること、または、残存するモードリストからモードを選択することによって決定される。最確モードリストと残りのモードリストの決定には、隣接するブロックのイントラ予測モードが必要である。比較的小さいブロックサイズが使用される場合、最確モードリストおよび残りのモードリストは、より頻繁に、すなわち、サンプル単位のブロックサイズおよびチャネルのサンプリングレートによって支配される頻度で決定される必要がある。
図8は、4:2:0クロマフォーマットの使用に起因する、クロマチャネルの変換ブロックサイズおよび関連するスキャンパターンのコレクション800を示す図である。コレクション800は、4:2:2のクロマフォーマットにも使用することができる。記載された配置は、特に4:2:0および4:2:2フォーマットのために、画像フレームのクロマチャネルが画像フレームのルマチャネルに対してサブサンプリングされるクロマフォーマットを有する画像フレームで使用するのに適している。コレクション800は、すべての可能なクロマ変換ブロックサイズを含まない。16以下の幅または8以下の高さを有するクロマ変換ブロックのみが図8に示されている。より大きな幅と高さを持つクロマ変換ブロックが存在する可能性があるが、参照を容易にするために図8には示されていない。追加のクロマ変換サイズは、ルマチャネルとクロマチャネルで符号化ツリーを共有する場合、2×16、4×16、8×16、16×16、32×32である。また、クロマチャネルの符号化ツリーがルマチャネルの符号化ツリーとは別個のものである場合(「デュアル符号化ツリー」)には、以下の追加のクロマ変換サイズも利用可能である:2×32、4×32、8×32、16×32、32×2、32×4、32×8、32×16。しかしながら、コレクション800は、より大きなTBをスキャンするために同様に適用することができるTBをスキャンするためのアプローチを示している。
禁止された変換サイズのセット810は、変換ブロックサイズ2×2、2×4、および4×2を含み、これらはすべて、16サンプル未満の領域を有する。言い換えれば、16クロマサンプルの最小変換サイズは、特にイントラ予測CBについて、記載された装置の動作から生じる。禁止された変換サイズ810の事例は、図9を参照して説明したように分割オプションを決定することによって回避される。変換中の残留係数は、変換が「サブブロック」(または「係数グループ」)に分割される2層アプローチでスキャンされる。スキャンは、最後の有意な(ゼロでない)係数からDC(左上)の係数に戻るスキャンパスに沿って行われる。スキャンパスは、各サブブロック内の進行(「下層」)と、あるサブブロックから次のサブブロックへの進行(「上層」)として定義される。コレクション800において、8×2のTB820は、8×2サブブロック、すなわち16個の残差係数を含むサブブロックを使用する。2×8のTB822は、2×8サブブロック、すなわち、同じく16個の残差係数を含むサブブロックを使用する。
幅または高さが2であり、他の次元が8の倍数であるTBは、複数の2×8または8×2サブブロックを使用する。したがって、2サンプルの幅を有するいくつかの例のクロマブロックは、サイズ2x8サンプルのそれぞれのサブブロックへのブロックの分割を用いて符号化され、2サンプルの高さを有するクロマブロックは、サイズ8x2サンプルのそれぞれのサブブロックへのブロックの分割を用いて符号化される例がある。例えば、16×2のTB816は、2つの8×2のサブブロックを有し、各サブブロックは、TB820に対して示されるようにスキャンされる。1つのサブブロックから次のサブブロックへのスキャンの進行はサブブロック進行817に示される。
2×32のTB(図8には示されていない)は、1×4のアレイとして配置された4つの2×8のサブブロックを使用する。各サブブロック内の残留係数は、2×8のTB822に示すようにスキャンされ、サブブロックは1×4のアレイの最下位のサブブロックから最上位のサブブロックに向かって進行する。
より大きなTBは、同様のスキャン進行に従う。幅と高さがそれぞれ4以上であるすべてのTBについて、4×4のサブブロックスキャンが使用される。例えば、4×8のTB823は、4×4のサブブロックスキャン824を使用し、下のサブブロックから上のサブブロックへと進行する。4×4のTB825も同様の方法でスキャンすることができる。8×8TB829は、4つの4×4のサブブロックの進行830を使用する。すべての場合において、サブブロック内のスキャンおよびサブブロックからサブブロックへの進行は、後方の対角線スキャンに従っている。すなわち、スキャンは、「最後の」有意な残留係数からTBの左上の残留係数に向かって戻るように進行する。また、図8は、例えば、8x4のTB832、16x4のTB834、16x8のTB836にわたるスキャン順序を示している。さらに、スキャン経路に沿った最後の有意な係数の位置に応じて、最後の有意な係数の位置からサブブロックの左上の残差係数に戻るまでの、最後の有意な残差係数を含むサブブロックの部分のみをスキャンする必要がある。スキャン経路に沿って順方向にさらに進んだサブブロック(すなわち、ブロックの右下に近い部分)は、スキャンする必要がない。コレクション800および特に禁止された変換サイズ810は、図9を参照して説明したように、符号化ツリーの領域(またはノード)をサブ領域(またはサブノード)に分割する能力に制限を課すものである。
2×2、2×4および4×2のTB(TBのセット810)を使用するVVCシステムでは、2×2のサブブロックが、2サンプルの幅および/または高さのTBに採用されてもよい。上述したように、TB810の使用は、イントラ再構成フィードバック依存ループにおけるスループット制約を増加させる。さらに、4つの係数のみを有するサブブロックの使用は、より高いスループットで残留係数を解析することの困難性を増加させる。特に、各サブブロックに対して、「有意性マップ」が、そこに含まれる各残差係数の有意性を示す。1値の有意性フラグの符号化は、残差係数の大きさが少なくとも1であることを確定し、0値のフラグの符号化は、残差係数の大きさが0であることを確定する。残留係数の大きさ(1以降)および符号は、「有意な」残留係数に対してのみ符号化される。DC係数については、有意性ビットは符号化されず、(0からの)大きさが常に符号化される。高スループットの符号化器および復号化器では、リアルタイム動作を維持するために、クロックサイクルごとに複数の有意性マップビンを符号化または復号化する必要がある。1サイクルあたりのマルチビンの符号化および復号化の難易度は、サブブロックサイズが小さい場合など、ビン間の依存関係がより多い場合に高くなる。本システム100では、サブブロックサイズは、ブロックサイズに関わらず、16(最後の有意な係数を含むサブブロックの例外は除く)である。
図9は、イントラ予測が使用されているときに、ルマ符号化ツリーおよびクロマ符号化ツリーにおいて許容される分割のリストを生成するための規則900のセットを示す図である。一連のフレームの最初のフレームを含む特定のフレームについては、すべてのブロックがイントラ予測を使用する。その他のフレームでは、インター予測ブロックとイントラ予測ブロックの混在が可能である。図6を参照して符号化ツリーの利用可能な分割の全セットを説明したが、利用可能な変換サイズの制限により、所定の領域サイズに対する特定の分割オプションに制約がある。以下に説明するように、ルマおよびクロマチャネルのそれぞれに対する分割オプションは、対応する符号化ツリーユニットの領域の寸法に応じて決定される。
VVCでは、ルマサンプルとクロマサンプルに対して異なる符号化ツリーの使用が可能であるため、クロマサンプルに対して許容される分割オプションは、ルマサンプルに対する分割オプションとは異なる。それに応じて、規則900のセットは、クロマ領域のための規則920のセットと、ルマ領域のための規則910のセットに分割される。ルマ符号化ツリーとクロマ符号化ツリーに別々の規則が示されており、ルマチャネルとクロマチャネルに異なる変換ブロックのコレクションを使用することができる。特に、ルマチャネルとクロマチャネルで使用可能なブロックのコレクションがクロマフォーマットで関連しているという要件はない。符号化ツリーのノードをトラバースする際に、領域サイズで分割オプションのセットの利用可能性をチェックすることにより、許可された分割のリストが得られる。CBを使用して符号化される可能性のある領域をもたらす分割オプションは、許可される分割のリストに追加される。領域がCBを使用して符号化されるためには、領域サイズは、コレクション800からの特定のサイズの整数個の変換による符号化を可能にしなければならない。特定のサイズは、(幅と高さの両方を考慮して)領域サイズを超えない最大のサイズとして選択される。このように、小さい領域では単一の変換が使用され、領域のサイズが利用可能な最大の変換のサイズを超える場合には、利用可能な最大の変換が領域の全体を占めるようにタイル状に配置される。
セット920を用いてクロマ領域を処理するとき、分割オプションの初期分割リストが生成される。各分割オプションは、領域サイズに対してテストされ、その分割オプションが、コレクション800の変換サイズよりも小さい、禁止されたサイズのサブ領域をもたらすかどうかを決定する。許可されたサイズのサブ領域をもたらす分割オプション、すなわち、コレクション800の最小変換サイズの整数に一致する分割オプションは、許可されたクロマ分割リスト970に追加される。
例えば、QTモードの場合(図6の決定610に対応)、領域が4:2:0フォーマットの8x8または4:2:2フォーマットの8x16のサイズである場合、分割するとクロマチャネルの変換サイズがそれぞれ2x2または2x4になるため、クアッドツリー分割は許可されない。許容される領域サイズは、矢印921で示されている。同様に、クロマ規則セット920に対する他の許容可能な分割は、矢印922、923、924、925および926によって示され、以下の図10および図11に関連して説明される。
クロマチャネルのための領域サイズは、ルマサンプルグリッドの観点から説明される。例えば、8x4の領域は、4:2:0のクロマフォーマットが使用されている場合、クロマチャネルの4x2の変換に対応する。4:2:2クロマフォーマットが使用されている場合、8x4の領域はクロマの4x4変換に対応する。4:4:4クロマフォーマットが使用されている場合、クロマはルマに対してサブサンプリングされないので、クロマの変換サイズは領域サイズに対応する。
許容されるルマ変換分割は、異なる最小サイズ制約に関連しており、4x4は認められない。4x4のルマPBは、16サンプルの倍数であるという要件を満たしているが、ルマのサンプルレートは、4:2:0クロマフォーマットのビデオの各クロマチャネルのサンプルレートの4倍である。4x4のルマ予測ブロックがバスの利用不足にならないとしても(例えば、SIMDアーキテクチャや16サンプル幅のバスアーキテクチャの場合)、イントラ再構成フィードバックループやイントラ予測モード決定フィードバックループが比較的高いサンプルレートでの動作に対応するのは困難である。ルマチャネルにおける4x4ブロックの禁止は、フィードバックループの深刻さを、高いサンプルレートでの実装が可能なレベルまで低減する。規則セット920と同様に、セット910における許容分割は、矢印901~906で示され、許容分割のリスト972を生成するために使用される。許容される分割オプションは、以下の図10および11に関連してさらに説明される。
図10は、画像フレームの符号化ツリーをビデオビットストリームに符号化する方法1000を示す。方法1000は、図12を参照して説明したように、ルマ符号化ツリーおよびクロマ符号化ツリーのそれぞれについて実行され、その結果、CTUについて各符号化ツリーを決定し、その結果得られた符号化ツリーをビットストリーム115に符号化することになる。方法1000は、構成されたFPGA、ASIC、またはASSPのような装置によって具現化されてもよい。さらに、方法1000は、プロセッサ205の実行下でビデオ符号化器114によって実行されてもよい。このように、方法1000は、コンピュータ可読記憶媒体および/またはメモリ206に格納されてもよい。各CTUのルマ符号化ツリーおよびクロマ符号化ツリーに対して起動される方法1000は、生成初期分割オプションステップ1010で開始され、「現在のノード」(または現在の領域)は、ルマまたは符号化ツリーのルート、すなわちCTU全体を占める領域である。方法1000は、フレームデータ113がブロックパーティショナ310によって受信されたときに、ルマおよびクロマの符号化ツリーのそれぞれについて符号化器114によって実施される。
初期分割オプション生成ステップ1010において、プロセッサ205は、符号化ツリーの現在のノードに対する分割オプションを生成する。分割オプションは、方法1000の反復に応じて、ルマチャネルまたはクロマチャネルに対して生成される。当初、符号化ツリーは、唯一許可される分割がクワッドツリーの分割(図5の分割512)、または分割の停止(図5の510参照)であるクワッドツリー(QT)ステージである。さらに、イントラ予測ブロックのみを使用するように符号化されたフレームまたはスライスでは、ルマおよびクロマの符号化ツリーは、そのルートノードにクワッドツリー分割を含む。その結果、128x128のCTUの場合、4:2:0のクロマフォーマットが使用される場合、最大のルマのイントラ予測CBは64x64であり、最大のクロマのイントラ予測CBは32x32である。イントラ予測ブロックとインター予測ブロックのいずれかまたは両方を使用するように符号化されたスライスのフレームでは、ルマとクロマの符号化ツリーは、そのルートノードにクワッドツリーの分割を含む必要はない。ただし、イントラ予測されたCBは、64x64のルマサンプルグリッドの境界をまたぐことはできない。クワッドツリーの分割が終了すると、符号化ツリーはマルチツリー(MT)ステージにあると言われ、図6の決定312に対応する。マルチツリーステージでは、分割オプションは、(i)分割を中止する(すなわち510)、この場合、現在のノードに対応する領域がCBを使用して符号化される、または(ii)分割を継続する、である。初期の分割オプションとして、水平方向および垂直方向の両方における2分割および3分割(図5の514~520参照)を使用することができる。ステップ1010の結果として、符号化ツリーステージ(すなわち、QTまたはMT)に対して可能なすべての分割のリストが作成される。プロセッサ205における制御は、ステップ1010から、クロマフォーマットを決定するステップ1020へと進行する。
クロマフォーマットを決定するステップ1020において、プロセッサ205は、フレームデータ113のクロマフォーマットを、4:2:0クロマフォーマットまたは4:2:2クロマフォーマットのいずれかとして決定する。クロマフォーマットは、フレームデータの特性であり、動作中には変化しない。したがって、クロマフォーマットは、設定ファイルやレジスタなどの手段でビデオ符号化器113に与えられる。決定されたクロマフォーマットは、例えば「chroma_format_idc」シンタックス要素を用いて、ビデオに対して一度だけ符号化されて、ビットストリーム113に符号化される。プロセッサ205における制御は、ステップ1020から、許可された分割を生成するステップ1030へと進行する。
許可された分割を生成するステップ1030では、プロセッサ205は、許可された分割タイプを制約する規則をステップ1010の各分割オプションに適用して、許可された分割リストを生成する。ルマ符号化ツリーを処理するとき、ステップ1030の実行により、許容ルマ分割リスト972が生成される。クロマ符号化ツリーを処理するとき、ステップ1030の実行により、許容クロマ分割リスト970が作成される。許可された分割タイプを制約する規則は、ルマチャネルおよびクロマチャネルのそれぞれにおける利用可能な変換サイズを考慮する。
一般に、ルマチャネルにおけるN×Mの変換に対して、4:2:0クロマフォーマットが使用される場合には、クロマチャネルに対して利用可能なN/2×M/2の変換があり、4:2:2クロマフォーマットが使用される場合には、クロマチャネルに対して利用可能なN/2×Mの変換がある。このように、分割規則は、一般的には、ルマチャネルとクロマチャネルで同等である。ただし、ブロックサイズが小さい場合は例外がある。特に、4×8および8×4のルマ変換は、クロマにおいて対応する2×4および4×2の変換を持たない。また、4×4のルマ変換や2×2のクロマ変換になる分割も認められない。2×2クロマ変換の領域サイズは、4:2:0クロマフォーマットの場合、4×4のルマサンプルであるため、規則はルマチャネルとクロマチャネルで同等である。
ルマの変換セットがクロマの変換セットと異なる程度に、ルマとクロマの間で許容される分割オプションに違いがある。符号化ツリー内のルマノードを処理する際、各分割オプション(図9に示す510~520)について、ルマノードの領域サイズが評価される。分割なしの場合(510)は、常に許可され、従って、矢印912で示すように、許可されたルマ分割リスト972に常に追加される。クワッドツリー分割(512)は、領域サイズが8×8の場合には不許可となり、不許可となった4×4のルマ変換サイズの使用を回避する。より大きな領域サイズの場合、クワッドツリー分割は許可され、矢印911で示されるように、許可されたルマ分割リスト972に追加される。ルマ符号化ツリーのMTステージでは、ルマでの4×4変換の使用を防ぐために、以下の分割が不許可となる:
-4×8の領域の水平方向の2分割(4×4ブロックのペアを避ける)。矢印913で示されるように、残りの分割は許可される。
-8×4の領域の垂直方向の2分割(4×4ブロックのペアを避ける)。矢印914で示されるように、残りの分割は許される。
-4×16以下の領域の水平3分割(分割の1ブロック目と3ブロック目が4×4ブロックになることを避ける)。矢印915で示されるように、残りの分割は許可される。
-16×4以下の領域の垂直3分割(分割の1ブロック目と3ブロック目が4×4ブロックになることを避ける)。矢印916で示されるように、残りの分割は許可される。
さらに、4未満の高さの幅を有するブロックになるようなルマの分割は禁止される。幅または高さが4未満であることの回避およびブロックサイズが4×4であることによる分割の制限が遭遇しないことを条件に、分割は許可されたルマの分割リスト972に追加される。
クロマ符号化ツリーのクロマノードを処理するとき、各分割オプションについて、ノードの領域サイズに関する対応する規則を参照して、分割オプションを許可されたクロマ分割リスト970に追加するかどうかを決定する。ルマ符号化ツリーと同様に、クロマ符号化ツリーは、クワッドツリー分割512または分割なし510のいずれかが許容される「QT」ステージ(図6の決定610に対応)で始まる。分割なし510が発生すると、符号化ツリーは「MT」ステージに入る(図6の決定612に対応)。MTステージでは、(i)分割なしは、ノードに関連する領域を占有するCBの存在を示すか、または(ii)分割514~520のうちの1つが発生する。分岐514~520のいずれかが発生すると、領域がサブ領域に分割される。結果として生じるサブ領域の各々は、許容される分割オプションを決定するためにも評価される。
符号化ツリーのQTステージにおいて、4:2:0クロマフォーマットを使用して、ノードが、領域サイズが8×8(すなわち、4×4クロマ変換)に達している場合、それ以上のクアッドツリー分割は可能ではない。また、他の分割オプションも利用できない。ノードで許可されているクロマの分割に「分割なし」を追加するオプションがある。結果として、単一の4×4のCBがそのノードに存在する。
符号化ツリーのQTステージで、4:2:2クロマフォーマットを使用して、ノードが8×16の領域サイズ(すなわち、4×8のクロマ変換)を有する場合、それ以上のクアッドツリー分割は可能ではなく、ステップ1030は、符号化ツリーのMTステージに入る。MTステージにおける8×16の領域は、単一の4×8のクロマ変換を有していてもよいし、2つの8×8の領域、したがって一対の4×4のクロマ変換をもたらす水平方向の分割を有していてもよいし、2つの4×16の領域、したがって一対の2×8のクロマ変換をもたらす垂直方向の分割を有していてもよい。MTステージのクロマ符号化ツリーでは、サイズが4×4、4×8、8×4の領域となり、その結果、サイズが2×2、2×4、4×2の変換が導入されるような分割は禁止されており、以下のようにリストされる:
-8×8の領域の水平2分割(4×2のクロマ変換のペアを避ける)または4×16の領域の水平2分割(2×4のクロマ変換のペアを避ける)。矢印923で示されるように、残りの分割は許可される。
-8×8の領域の垂直2分割(2×4のクロマ変換のペアを避ける)または16×4の領域の垂直2分割(4×2のクロマ変換のペアを避ける)。矢印924で示されるように、残りの分割は許可される。
-4×16の領域の水平3分割(2×2のクロマ変換を用いた第1および第3のサブ領域を避け、クロマ変換を用いた中央の2×4のサブ領域を避ける)または8×16領域の水平3分割(第1および第3のサブ領域の2×4のクロマ変換を避ける)。矢印925で示されるように、残りの分割は許可される。
16×4の領域の垂直3分割(2×2クロマ変換を用いた第1および第3のサブ領域を避け、クロマ変換を用いた中央の4×2のサブ領域を避ける)または16×8領域の垂直3分割(第1および第3のサブ領域の4×2のクロマ変換を避ける)。矢印926で示されるように、残りの分割は許可される。
上記の制約に加えて、2未満の幅または高さを有するサブ領域になるような分割は禁止される。ステップ1010の各分割オプションを考慮して、上記の規則が参照され、禁止されていない分割オプションが、ステップ1030の実行において、クロマ分割オプションリスト970に追加される。初期の分割オプションが許可された分割のリスト(クロマ用リスト970およびルマ用リスト972)に改良されると、ブロックパーティショナ310は、ラグランジュ最適化に従って予測モードおよび符号化コストを評価することにより、許可された分割の1つを選択する。プロセッサ205における制御は、ステップ1030からゼロ許容分割テスト1040へと進行する。
ゼロ許容分割テスト1040では、プロセッサ205は、分割オプションリスト(970または972)が「分割なし」エントリのみを含むかどうかをテストする(分割510)。そうであれば(ステップ1040で「YES」)、それ以上の分割は可能ではない。現在のノードにCBが存在し、プロセッサ205内の制御は、符号化ブロック符号化ステップ1070に進む。分割が可能であれば(ステップ1040で「NO」)、プロセッサ205内の制御は、符号化ツリーステージテストステップ1050に進む。
符号化ツリーステージテストステップ1050において、プロセッサ205は、符号化ツリーにおける現在のノードのステージをチェックし、すなわち、ステージがQTであるかMTであるかをチェックする。ノードがQTステージにある場合、ブロックパーティショナ310の決定は、QTステージに留まることであり、プロセッサ205における制御は、符号化QT分割ステップ1055に進行する。ノードがMTステージにある場合、またはブロックパーティショナ310の決定が、符号化ツリーの現在のノードについてQTステージからMTステージに移行することである場合、プロセッサ205における制御は、MT分割符号化ステップ1060に進行する。
QT分割符号化ステップ1055において、エントロピー符号化器338は、プロセッサ205の実行下で、「1」の値を有するQT分割フラグ(図6の決定610に関連して説明した)をビットストリーム115に符号化する。値が「1」のQT分割フラグは、現在のノードを4つのサブモードに分割すること、すなわち、クアッドツリー分割512を示す。プロセッサ205における制御は、ステップ1055からサブ領域再帰ステップ10100へと進行する。
MT分割符号化ステップ1060において、プロセッサ205の実行下にあるエントロピー符号化器338は、MT分割のタイプを示すために、ビットストリーム115にさらなるフラグを符号化する。現在のノードが符号化ツリーのQTステージからMTステージへの移行時である場合、「0」の値を有するQT分割フラグ(図6の決定610に関連して説明した)がビットストリーム115に符号化される。ステップ1030で決定されたように、「分割なし」の場合以外の少なくとも1つの分割が許容される場合、MT分割フラグは、分割なし510の選択を示す(MT分割フラグに対して「0」を符号化する、図6の決定612に関連して説明する)。ステップ1060では「NO」が返され、プロセッサ205内の制御は、符号化ブロック符号化ステップ1070に進む。
そうでなければ、ブロックパーティショナ310による分割514~520のうちの1つの選択は、MT分割フラグ、すなわち612に対して「1」を符号化することによって示される。ステップ1060は「YES」を返し、プロセッサ205における制御は、B/T_H/V分割符号化ステップ1090に進行する。
符号化ブロック符号化ステップ1070では、プロセッサ205の実行下にあるエントロピー符号化器338が、符号化ブロックの予測モードおよび残差係数をビットストリーム115に符号化する。イントラ予測されたCBについては、イントラ予測モードが符号化され、インター予測されたCBについては、動きベクトルが符号化される。残留係数は、スキャンパス内の最後の有意な残留係数からブロックのDC係数に向かって戻るスキャンに従って符号化される。
さらに、係数は「サブブロック」にグループ化され、そのサブブロックに少なくとも1つの有意な残留係数が存在することを示す符号化されたサブブロックフラグが必要に応じて符号化される。サブブロックに有意な残差係数が存在しない場合は、サブブロックの各残差係数に対して個々の有意フラグを符号化する必要はない。最後の有意な残差係数を含むサブブロックは、符号化されたサブブロックフラグを必要としない。DC(ブロックの左上)残留係数を含むサブブロックには、符号化されたサブブロックフラグはコード化されない。サブブロックサイズは、図8に示すように、ルマでは常に4×4であり、クロマでは所定のブロックに対して2×8または4×4または8×2のいずれかである。したがって、サブブロックサイズは常に16であり、これはコレクション800の場合のように、常に16の倍数であるブロックサイズと一致する。プロセッサ205における制御は、ステップ1070から最後の符号化ブロックテストステップ1080へと進行する。
最後の符号化ブロックテスト1080では、プロセッサ205は、現在の符号化ブロックが符号化ツリーの最後のCBであるかどうかを判断する。階層的なZオーダスキャンにより、最後のCBは、CTUの右下隅を占めるCBである。現在のCBが符号化ツリーの最後のものである場合(ステップ1080で「YES」)、方法1000は終了する。方法1000がルマ符号化ツリーを処理すると、方法1000はクロマ符号化ツリーを処理するために起動される。プロセッサ205は、ルマ符号化ツリーおよびクロマ符号化ツリーを処理するために、方法1000の2つのインスタンスを並行して実行してもよい。方法1000の2つのインスタンスが並行して実行される場合、エントロピー符号化器338は、決定論的なビットストリームを生成するために、直列化された方法でルマおよびクロマに対する動作を実行する。すなわち、並列符号化器によって生成されたビットストリームは、シリアル復号化器によって復号化可能でなければならない。そうでない場合は、ステップ1080が”NO”であれば、図7Aおよび図7Bに例示されているように、現在のノードは、階層的なZオーダスキャンに従って次のノードに進行する。プロセッサ205における制御は、初期分割オプション生成ステップ1010に進む。
B/T_H/V分割符号化ステップ1090において、プロセッサ205の実行下にあるエントロピー符号化器338は、許容分割リストのどの分割がブロックパーティショナ310によって選択されたかを示す追加フラグをビットストリーム115に符号化する。許可された分割リストが、「分割なし」の場合以外の1つの分割のみを含む場合、その1つの分割は、ブロックパーティショナ310によって選択されたものでなければならず、分割を識別するための追加フラグを符号化する必要はない。許可された分割のリストが、水平方向と垂直方向の両方の分割を含む場合、エントロピー符号化器338は、ブロックパーティショナ310によって選択された分割の方向を示すフラグを符号化する。許可された分割のリストが2分割と3分割の両方を含む場合、エントロピー符号化器338は、ブロックパーティショナ310によって選択された分割のタイプ(すなわち、2分割または3分割)を示すフラグを符号化する。プロセッサ205における制御は、ステップ1090からサブ領域再帰ステップ10100へと進行する。
サブ領域再帰ステップ10100において、プロセッサ205は、ステップ1030の決定された分割に従って、サブ領域を生成する。方法1000は、生成されたサブ領域またはノードの各々に対して再帰的に呼び出され、その結果、符号化ツリー全体で再帰が行われる。方法1000の再帰的な呼び出しは、図7Aおよび図7Bに示すように、符号化ツリーの階層的なZオーダスキャンに従って、1つのサブ領域またはノードから次のサブ領域またはノードへと進行する。分割によって生じた子ノードが、サブ領域を生成するために方法1000によって処理された場合、再帰は符号化ツリーの次の兄弟ノードに進行する。それ以上の兄弟ノードがない場合、再帰は親ノードに進行し、その時点で、次のノード(例えば、親の兄弟)が、サブ領域を生成する次のノードとして選択される。親ノードが符号化ツリーのQTステージにある場合、親ノードに戻ることは、符号化ツリーのQTステージに戻ることになる。
したがって、ステップ1055、1060、1090、および1070のそれぞれは、決定された許容可能な分割オプションのフラグをビットストリームに符号化するように動作する。各分割オプションは、クロマチャネルまたはルマチャネルの一方について決定される。分割オプションは、符号化ツリーの領域の寸法に基づいて決定することができる。
図11は、ビデオビットストリームから画像フレーム内の符号化ツリーを復号するための方法1100を示す。方法1100は、図13を参照して説明したように、ルマ符号化ツリーおよびクロマ符号化ツリーのそれぞれについて実行され、その結果、CTUについて、ビットストリーム133から各符号化ツリーを復号する。方法1100は、構成されたFPGA、ASIC、またはASSPのような装置によって具現化されてもよい。さらに、方法1100は、プロセッサ205の実行下でビデオ復号化器134によって実行されてもよい。このように、方法1100は、コンピュータ可読記憶媒体および/またはメモリ206に格納されてもよい。各CTUのルマ符号化ツリーおよびクロマ符号化ツリーに対して呼び出される方法1100は、初期分割オプション生成ステップ1110で開始し、「現在のノード」(または現在の領域)は、ルマまたは符号化ツリーのルート、すなわちCTU全体を占める領域である。
初期分割オプション生成ステップ1110では、プロセッサ205は、符号化ツリーの現在のノードに対する分割オプションを生成する。初期状態では、符号化ツリーはクアッドツリー(QT)ステージであり、唯一許可される分割は、クアッドツリー分割(分割512)、または分割の停止(分割510)である。さらに、イントラ予測ブロックのみを使用するように符号化されたフレームまたはスライスについては、ルマおよびクロマ符号化ツリーは、そのルートノードにクワッドツリー分割を含む。クワッドツリーの分割が停止したとき、符号化ツリーはマルチツリー(MT)ステージにあると言われる。マルチツリーステージでは、分割オプションは、現在のノードに対応する領域がCBを使用して符号化される場合に、分割を中止する(510を使用)か、または分割を継続するかである。初期の分割オプションとしては、水平方向と垂直方向の2分割と3分割(分割514~520)が利用可能である。ステップ1110の結果として、符号化ツリーステージ(すなわちQTまたはMT)のためのすべての可能な分割のリストが作成される。プロセッサ205における制御は、クロマフォーマット決定ステップ1120に進む。
クロマフォーマット決定ステップ1120において、プロセッサ205は、フレームデータ135のクロマフォーマットを、4:2:0クロマフォーマットまたは4:2:2クロマフォーマットのいずれかとして決定する。例えば、プロセッサ205の実行下にあるエントロピー復号化器420によって、ビットストリーム113から「chroma_format_idc」シンタックス要素が読み込まれ、クロマフォーマットを決定してもよい。プロセッサ205における制御は、ステップ1120から、許可された分割を生成するステップ1130へと進行する。
許可された分割を生成するステップ1130では、プロセッサ205は、許可された分割タイプを制約する規則をステップ1110の各分割オプションに適用して、許可された分割リストを生成する。ルマ符号化ツリーを処理する際に、許可されたルマ分割リスト972が作成される。ステップ1130は、方法100のステップ1030と同じ方法に従って動作し、したがって、ビデオ復号化器134におけるルマおよびクロマ符号化ツリーのノードの許容分割リストは、ビデオ符号化器114におけるルマおよびクロマ符号化ツリーのノードの許容分割リストと同じである。ステップ1030は、ルマ符号化ツリーとクロマ符号化ツリーのどちらが処理されているかに依存して、許容分割リスト970および972のうちの1つを生成するように動作する。ステップ1030および図9に関連して説明したように、クロマ分割オプションは、ルマ分割オプションとは異なり、クロマ分割オプションは、16サンプルの最小サイズを有するブロックをもたらす。プロセッサ205における制御は、QT/MTテストステップ1140に進行する。
QT/MTテストステップ1140において、プロセッサ205は、現在のノード(領域)が符号化ツリーのQTステージにあるか、または符号化ツリーのMTステージにあるかをテストする。現在のノードが符号化ツリーのQTステージにあり、許容される分割のリストに「4分割」オプション(分割512)が含まれている場合、プロセッサの制御はデコードQT分割ステップ1155に進む。現在のノードが符号化ツリーのQTステージにあり、許可された分割のリストに「4分割」オプションが含まれていない場合、すなわち「分割なし」オプションのみが許可されている場合、符号化ツリーのステージは「MT」ステージに移行し、プロセッサ205内の制御はゼロ許可分割テスト1150に進行する。符号化ツリーが既にMTステージにある場合、プロセッサ205内の制御は、ゼロ許容分割テスト1150に進行する。
ゼロ許容分割テスト1150において、プロセッサ205は、分割オプションリスト、すなわち、クロマおよびルマ符号化ツリーのそれぞれに対する970または972が、「分割なし」エントリのみを含むかどうかをテストする(510)。分割オプションリストに分割なしのエントリしか含まれていない場合、それ以上の分割はできず、現在のノードにCBが存在することになる。ステップ1150は「YES」を返し、プロセッサ内の制御は、符号化ブロック復号化ステップ1170に進む。さらなる分割が可能な場合(ステップ1150で「NO」)、プロセッサ内の制御はMT分割復号化ステップ1160に進む。
QT分割復号化ステップ1055において、プロセッサ205の実行下にあるエントロピー復号化器420は、現在のノードの4つのサブモードへの分割、すなわちクワッドツリー分割512が発生するかどうかを示すQT分割フラグ(すなわち610)をビットストリーム133から復号化する。クワッドツリー分割が発生しない場合(ステップ1155で「NO」)、プロセッサ205内の制御は、ゼロ許可分割テスト1150に進行する。クワッドツリー分割が発生する場合(ステップ1155で「YES」)、プロセッサ205内の制御は、サブ領域再検索ステップ11100に進行する。
MT分割復号化ステップ1060では、プロセッサ205の実行下にあるエントロピー復号化器420が、MT分割のタイプを示すフラグをビットストリーム133からさらに復号化する。ステップ1130で決定されたように、「分割なし」の場合以外の少なくとも1つの分割が許可されている場合、MT分割フラグは、分割なし510の選択を示す(MT分割フラグに対して「0」を復号化する、すなわち612を復号化する)。ステップ1060では「NO」が返され、プロセッサ205における制御は、符号化ブロック復号化ステップ1170に進む。そうでなければ、許可された分割(970または972)のうちの分割514~520のうちの1つを選択する必要性は、MT分割フラグ、すなわち612に対して「1」を復号化することによって示される。ステップ1060は「YES」を返し、プロセッサ205における制御は、B/T_H/V分割復号化ステップ1190に進行する。
符号化ブロック復号化ステップ1170では、プロセッサ205の実行下にあるエントロピー復号化器420が、ビットストリーム133から符号化ブロックの予測モードおよび残差係数を復号化する。イントラ予測されたCBについては、イントラ予測モードが復号化され、インター予測されたCBについては、動きベクトルが復号化される。残留係数は、スキャンパス内の最後の有意な残留係数からブロックのDC係数に向かって戻るスキャンに従って復号化される。さらに、係数は「サブブロック」にグループ化され、サブブロック内に少なくとも1つの有意な残差係数が存在することを示す符号化されたサブブロックフラグが復号化される。サブブロックに有意な残差係数が存在しない場合、サブブロックの各残差係数に対する個々の有意性フラグを復号化する必要はない。最後の有意な残差係数を含むサブブロックは、サブブロックフラグの復号化を必要とせず、DC(ブロックの左上)の残差係数を含むサブブロックに対しては、符号化されたサブブロックフラグは復号化されない。サブブロックサイズは、図8に示すように、ルマでは常に4×4であり、クロマでは所定のブロックに対して2×8または4×4または8×2のいずれかである。したがって、サブブロックサイズは常に16であり、これはコレクション800の場合のように、常に16の倍数であるブロックサイズと一致する。プロセッサ205における制御は、最終符号化ブロックテストステップ1180に進行する。
最終符号化ブロックテスト1180では、プロセッサ205は、現在の符号化ブロックが符号化ツリーの最後のCBであるかどうかを決定する。階層的なZオーダスキャンにより、最後のCBは、CTUの右下隅を占めるものである。現在のCBが符号化ツリーの最後のものである場合、ステップ1180は「YES」を返し、方法1100は終了する。方法1100がルマ符号化ツリーを復号化すると、クロマ符号化ツリーを復号化するために方法1100が起動される。そうでなければ、図7Aおよび図7Bに例示されているように、階層的なZオーダスキャンに従って、現在のノードが次のノードに進行する。ステップ1180は「NO」を返し、プロセッサ205内の制御は、初期分割オプション生成ステップ1110に進む。ビットストリーム133を正しく解析するために、ビデオ復号化器134は、通常、フラグおよび他のシンタックス要素を、ビデオ符号化器113によって書き込まれたのと同じ順序で読み取る。しかし、他の操作は、それらの依存関係が満たされることを条件に、異なる順序でおよび/または同時に実行されるかもしれない。例えば、ルマおよびクロマのイントラ再構成のためのものなどの操作のセットは、並行して実行されるかもしれない。
B/T_H/V分割復号化ステップ1190において、プロセッサ205の実行下にあるエントロピー復号化器420は、許可された分割リストのどの分割をビデオ復号化器134が実行するかを示す追加フラグをビットストリーム133から復号化する。許可された分割リストが、「分割なし」の場合以外の1つの分割のみを含む場合には、他の選択肢がないため、1つの分割を実行する必要がある。したがって、分割を識別するために追加のフラグを復号化する必要はない。その後、プロセッサ205における制御は、サブ領域再帰ステップ11100に進む。許可された分割のリストが、水平方向および垂直方向の両方の分割を含む場合、ビットストリーム133から分割の方向を示すフラグを復号化する。また、許可された分割のリストに2分割と3分割の両方が含まれている場合には、ビットストリーム133から分割の種類(2分割か3分割か)を示すフラグを決定する。プロセッサ205における制御は、サブ領域再帰ステップ11100に進行する。
サブ領域再帰ステップ11100では、ステップ1190または1155の決定された分割に従ったプロセッサ205のサブ領域が生成され、これらのサブ領域またはノードのそれぞれに対して方法1100が呼び出され、符号化ツリー全体の再帰が行われる。方法1100の再帰的な呼び出しは、図7Aおよび図7Bに示すように、符号化ツリーの階層的なZオーダスキャンに従って、1つのサブ領域またはノードから次のサブ領域またはノードへと進行する。分割によって生じた子ノードがブロックまたはサブ領域を生成するために処理された場合、再帰は符号化ツリーの次の兄弟ノードに進行する。それ以上の兄弟ノードが存在しない場合、再帰は親ノードまたは領域に進む。次のノード(例えば、親の兄弟)が、処理する次のノードとして選択される。親ノードが符号化ツリーのQTステージにある場合、親ノードに戻ることは、符号化ツリーのQTステージに戻ることになる。
したがって、ステップ1155、1160、1190および1170は、ステップ1130で決定されたルマ分割オプションおよびクロマ分割オプションのうちの1つを選択するために、ビットストリーム133からフラグを決定して、符号化ツリーユニットの符号化ユニットを復号化するように動作する。
方法1000および1100、特にステップ1030および1130の結果として、イントラ再構成ループにおいて高レートで処理することが困難な、クロマチャネルの比較的小さなイントラ予測ブロックが回避される。小さなブロックの回避は、品質の許容できない劣化なしに「ピクセルレート」(処理する必要のある1秒あたりのピクセル)が高い、高解像度および/またはフレームレートでの実装を容易にする。
図12は、画像フレームのルマおよびクロマ符号化ツリーをビデオビットストリームに符号化するための方法1200を示す。この方法1200は、構成されたFPGA、ASIC、またはASSPなどの装置によって具現化されてもよい。さらに、方法1200は、プロセッサ205の実行下でビデオ復号化器114によって実行されてもよい。このように、方法1200は、コンピュータ可読記憶媒体および/またはメモリ206に格納されてもよい。方法1200は、CTUへのフレーム分割ステップ1210で開始する。
CTUへのフレーム分割ステップ1210において、プロセッサ205の実行下にあるブロックパーティショナ310は、フレームデータ113の現在のフレームをCTUのアレイに分割する。分割された結果のCTUに対する符号化の進行が開始される。プロセッサにおける制御は、ステップ1210からルマ符号化ツリー符号化ステップ1220へと進行する。
ルマ符号化ツリー符号化ステップ1220において、ビデオ符号化器114は、プロセッサ205の実行下で、方法1000を実行して、現在のCTUのルマ符号化ツリーを決定し、ビットストリーム115に符号化する。現在のCTUは、ステップ1210の実行の結果得られたCTUのうちの選択された1つである。プロセッサ205における制御は、ステップ1220からクロマ符号化ツリー符号化ステップ1230へと進行する。
クロマ符号化ツリー符号化ステップ1230において、プロセッサ205の実行下にあるビデオ符号化器114は、方法1000を実行して、現在のCTUの彩度符号化ツリーを決定し、ビットストリーム115に符号化する。プロセッサ205における制御は、ステップ1230から最終CTUテストステップ1240まで進行する。
最終CTUテストステップ1240において、プロセッサ205は、現在のCTUがスライスまたはフレーム内の最後のものであるかどうかをテストする。そうでない場合(ステップ1240で「NO」)、ビデオ符号化器114は、フレーム内の次のCTUに進み、プロセッサ205内の制御は、ステップ1240からステップ1220に戻って、フレーム内の残りのCTUの処理を継続するように進行する。CTUがフレームまたはスライスの最後のものである場合、ステップ1240は「YES」を返し、方法1200は終了する。
図13は、ビデオビットストリームから画像フレームのルマおよびクロマ符号化ツリーを復号するための方法1300のフロー図である。方法1300は、構成されたFPGA、ASIC、またはASSPのような装置によって具現化されてもよい。さらに、方法1300は、プロセッサ205の実行下でビデオ復号化器134によって実行されてもよい。このように、方法1300は、コンピュータ可読記憶媒体および/またはメモリ206に格納されてもよい。方法1300は、CTUへのフレーム分割ステップ1310で開始する。
CTUへのフレーム分割ステップ1310において、ビデオ復号化器134は、プロセッサ205の実行下で、復号化されるべきフレームデータ133の現在のフレームの分割をCTUのアレイに決定する。決定された分割に起因するCTUに対する復号化の進行が開始される。プロセッサにおける制御は、ステップ1310からルマ符号化ツリー復号化ステップ1320へと進行する。
ルマ符号化ツリー復号化ステップ1320において、プロセッサ205の実行下にあるビデオ復号化器134は、方法1100を現在のCTUに対して初めて実行し、ビットストリーム133から現在のCTUのルマ符号化ツリーを復号化する。現在のCTUは、ステップ1310の実行の結果得られたCTUのうちの選択された1つである。プロセッサ205における制御は、ステップ1320からクロマ符号化ツリー復号化ステップ1330へと進行する。
クロマ符号化ツリー復号化ステップ1330において、プロセッサ205の実行下にあるビデオ復号化器134は、方法1100を現在のCTUに対して2回目に実行して、ビットストリーム133から現在のCTUのクロマ符号化ツリーを復号化する。プロセッサ205における制御は、ステップ1330から最終CTUテストステップ1340まで進行する。
最終CTUテストステップ1340において、プロセッサ205は、現在のCTUがスライスまたはフレームにおける最後のものであるかどうかをテストする。そうでない場合(ステップ1340で「NO」)、ビデオ復号化器134は、フレーム内の次のCTUに進み、プロセッサ205内の制御は、ステップ1340からステップ1320に戻って進行し、ビットストリームからのCTUの復号化を継続する。CTUがフレームまたはスライスの最後のものである場合、ステップ1340は「YES」を返し、方法1300は終了する。
残留係数をサイズ16のサブブロックにグループ化することは、例えば、図8のTB816および823に関連して説明したように使用して、エントロピー符号化器338およびエントロピー復号化器420の実装を容易にする。特に、残差係数をサイズ16のサブブロックにグループ化することは、各サブブロック内のコンテキストの固定パターンの使用を可能にするために、有意マップのためなどのコンテキスト符号化されたビンの算術符号化の実装を容易にする。
記載された装置は、コンピュータおよびデータ処理産業に適用され、特に、ビデオおよび画像信号などの信号の符号化および復号化のためのデジタル信号処理に適用され、高い圧縮効率を達成する。
HEVCと比較して、VVCシステムでは、柔軟性を高めるために、ルマチャネルとクロマチャネルに別々の符号化ツリーを使用することができる。しかし、上述したように、より小さいクロマブロックの使用がスループットに影響を与えるという結果的な問題が発生する可能性がある。ここでは、各符号化ツリーユニットが処理される際に適切な規則を決定し、スループットの問題を回避することができる。さらに、上述したように、説明された装置は、スループットの問題を回避するための規則が与えられた場合、各符号化ツリーを記述するために使用されるコンテキスト符号化されたビンの算術符号化の改善された効率および精度を提供するのを支援することができる。
上述は、本発明のいくつかの実施形態のみを説明しており、本発明の範囲および精神から逸脱することなく、それらに修正および/または変更を加えることができ、実施形態は例示的なものであり、制限的なものではない。
(オーストラリアのみ)本明細書の文脈において、「comprising」という語は、「主に含むが、必ずしも単独ではない」または「有する」もしくは「含む」を意味し、「のみにより構成される」ではない。また、「comprise」や「comprises」などの「comprising」という単語の変化は、それに応じて様々な意味を持つ。

Claims (7)

  1. ビットストリームから画像内の符号化ツリーユニットにおける複数のブロックを復号する方法であって、
    複数のクロマフォーマットから前記画像のクロマフォーマットを決定し、
    前記符号化ツリーユニットの領域のサイズに応じて、前記符号化ツリーユニットのルマチャネルに対する複数のルマ分割オプションを決定
    前記符号化ツリーユニット内の領域のサイズに応じて、前記符号化ツリーユニットの複数のクロマチャネルに対する複数のクロマ分割オプションを決定前記複数のクロマ分割オプションは垂直三分割を含むことが可能であり、前記符号化ツリーユニットの前記複数のクロマチャネルに対するツリー構造は前記符号化ツリーユニットの前記ルマチャネルに対するツリー構造と独立しており、前記符号化ツリーユニット内の或る領域に対する垂直三分割は、(a)前記或る領域の横幅がルマサンプルにおいて16サンプルであり、且つ、(b)前記決定されたクロマフォーマットが4:2:2クロマフォーマット又は4:2:0クロマフォーマットである場合、前記複数のクロマ分割オプションとして許容されず、
    前記複数のルマ分割オプションの1つを選択し、前記複数のクロマ分割オプションの1つを選択するために、前記ビットストリームから複数のフラグを復号する
    ことを特徴とする方法。
  2. 前記複数のクロマ分割オプションにより得られる、イントラ予測のためのクロマブロックの最小サイズは、16サンプルである
    ことを特徴とする請求項1に記載の方法。
  3. 前記決定された複数のルマ分割オプションは、前記画像ルマチャネルに対して16サンプルの倍数である1つのルマブロックサイズをもたらす
    ことを特徴とする請求項1に記載の方法。
  4. 前記決定された複数のルマ分割オプションは、前記画像ルマチャネルに対して16サンプルの倍数である1つのルマブロックサイズをもたらし、2サンプルの幅を有する複数のクロマブロックは複数のサブブロックへの分割を用いて符号化され、各サブブロックのサイズは2×8サンプルである
    ことを特徴とする請求項1に記載の方法。
  5. 前記決定された複数のルマ分割オプションは、前記画像ルマチャネルに対して16サンプルの倍数である1つのルマブロックサイズをもたらし、2サンプルの高さを有する複数のクロマブロックは複数のサブブロックへの分割を用いて符号化され、各サブブロックのサイズは8×2サンプルである
    ことを特徴とする請求項1に記載の方法。
  6. ビットストリームから画像内の符号化ツリーユニットにおける複数のブロックを復号する方法を実施するためのコンピュータプログラムであって、前記方法は、
    複数のクロマフォーマットから前記画像のクロマフォーマットを決定し、
    前記符号化ツリーユニットの領域のサイズに応じて、前記符号化ツリーユニットのルマチャネルに対する複数のルマ分割オプションを決定
    前記符号化ツリーユニット内の領域のサイズに応じて、前記符号化ツリーユニットの複数のクロマチャネルに対する複数のクロマ分割オプションを決定前記複数のクロマ分割オプションは垂直三分割を含むことが可能であり、前記符号化ツリーユニットの前記複数のクロマチャネルに対するツリー構造は前記符号化ツリーユニットの前記ルマチャネルに対するツリー構造と独立しており、前記符号化ツリーユニット内の或る領域に対する垂直三分割は、(a)前記或る領域の横幅がルマサンプルにおいて16サンプルであり、且つ、(b)前記決定されたクロマフォーマットが4:2:2クロマフォーマット又は4:2:0クロマフォーマットである場合、前記複数のクロマ分割オプションとして許容されず、
    前記複数のルマ分割オプションの1つを選択し、前記複数のクロマ分割オプションの1つを選択するために、前記ビットストリームから複数のフラグを復号する
    ことを特徴とする、コンピュータプログラム
  7. ビットストリームから画像内の符号化ツリーユニットにおける複数のブロックを復号するビデオ復号装置であって、
    複数のクロマフォーマットから前記画像のクロマフォーマットを決定し、
    前記符号化ツリーユニットの領域のサイズに応じて、前記符号化ツリーユニットのルマチャネルに対する複数のルマ分割オプションを決定し、
    前記符号化ツリーユニット内の領域のサイズに応じて、前記符号化ツリーユニットの複数のクロマチャネルに対する複数のクロマ分割オプションを決定前記複数のクロマ分割オプションは垂直三分割を含むことが可能であり、前記符号化ツリーユニットの前記複数のクロマチャネルに対するツリー構造は前記符号化ツリーユニットの前記ルマチャネルに対するツリー構造と独立しており、前記符号化ツリーユニット内の或る領域に対する垂直三分割は、(a)前記或る領域の横幅がルマサンプルにおいて16サンプルであり、且つ、(b)前記決定されたクロマフォーマットが4:2:2クロマフォーマット又は4:2:0クロマフォーマットである場合、前記複数のクロマ分割オプションとして許容されず、
    前記複数のルマ分割オプションの1つを選択し、前記複数のクロマ分割オプションの1つを選択するために、前記ビットストリームから複数のフラグを復号する
    ことを特徴とする、ビデオ復号装置
JP2021514320A 2018-09-21 2019-06-25 復号する方法、コンピュータプログラム、ビデオ復号装置 Active JP7191211B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2022193604A JP7391175B2 (ja) 2018-09-21 2022-12-02 復号する方法、ビデオ復号装置、符号化する方法、ビデオ符号化装置

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
AU2018233042 2018-09-21
AU2018233042A AU2018233042A1 (en) 2018-09-21 2018-09-21 Method, apparatus and system for encoding and decoding a tree of blocks of video samples
PCT/AU2019/050658 WO2020056452A1 (en) 2018-09-21 2019-06-25 Method, apparatus and system for encodng and decoding a tree of blocks of video samples

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2022193604A Division JP7391175B2 (ja) 2018-09-21 2022-12-02 復号する方法、ビデオ復号装置、符号化する方法、ビデオ符号化装置

Publications (2)

Publication Number Publication Date
JP2022500926A JP2022500926A (ja) 2022-01-04
JP7191211B2 true JP7191211B2 (ja) 2022-12-16

Family

ID=69886764

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2021514320A Active JP7191211B2 (ja) 2018-09-21 2019-06-25 復号する方法、コンピュータプログラム、ビデオ復号装置
JP2022193604A Active JP7391175B2 (ja) 2018-09-21 2022-12-02 復号する方法、ビデオ復号装置、符号化する方法、ビデオ符号化装置

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2022193604A Active JP7391175B2 (ja) 2018-09-21 2022-12-02 復号する方法、ビデオ復号装置、符号化する方法、ビデオ符号化装置

Country Status (10)

Country Link
US (6) US11595699B2 (ja)
EP (1) EP3854091A4 (ja)
JP (2) JP7191211B2 (ja)
KR (1) KR20210050572A (ja)
CN (1) CN112771866A (ja)
AU (1) AU2018233042A1 (ja)
BR (1) BR112021003783A2 (ja)
MX (1) MX2021003054A (ja)
TW (2) TWI820714B (ja)
WO (1) WO2020056452A1 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
HUE064218T2 (hu) 2018-08-28 2024-02-28 Huawei Tech Co Ltd Képfelosztási eljárás és eszköz
CN112075077B (zh) * 2019-01-08 2022-01-11 华为技术有限公司 图像预测方法、装置、设备、系统及存储介质
CN113366855A (zh) * 2019-02-03 2021-09-07 北京字节跳动网络技术有限公司 基于条件的非对称四叉树分割
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
WO2021023261A1 (en) 2019-08-06 2021-02-11 Beijing Bytedance Network Technology Co., Ltd. Size restriction based on color format
BR112022003732A2 (pt) 2019-09-02 2022-10-11 Beijing Bytedance Network Tech Co Ltd Método e aparelho para processamento de dados de vídeo, e, meios de armazenamento e de gravação legíveis por computador não transitórios
CN114424565A (zh) 2019-09-21 2022-04-29 北京字节跳动网络技术有限公司 基于色度帧内模式的尺寸限制
US11432018B2 (en) * 2020-05-11 2022-08-30 Tencent America LLC Semi-decoupled partitioning for video coding
CN111598186B (zh) * 2020-06-05 2021-07-16 腾讯科技(深圳)有限公司 基于纵向联邦学习的决策模型训练方法、预测方法及装置
DE102021116357A1 (de) 2020-06-29 2021-12-30 Tyco Electronics Amp Korea Co., Ltd. Steckeranordnung
WO2023277486A1 (ko) * 2021-06-29 2023-01-05 주식회사 케이티 화면내 예측 기반의 비디오 신호 부호화/복호화 방법 및 장치, 그리고 비트스트림을 저장한 기록 매체

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014143716A (ja) 2014-03-12 2014-08-07 Sony Corp 画像処理装置および方法、プログラム、並びに記録媒体
JP2015534373A (ja) 2012-09-28 2015-11-26 キヤノン株式会社 符号化単位の変換単位を符号化および復号化する方法、装置、およびシステム
JP2016106482A (ja) 2009-08-12 2016-06-16 トムソン ライセンシングThomson Licensing 改善されたイントラ・クロマ符号化および復号のための方法および装置
JP2021536689A (ja) 2018-08-28 2021-12-27 華為技術有限公司Huawei Technologies Co., Ltd. ピクチャパーティショニング方法及び機器

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2390072C (en) * 2002-06-28 2018-02-27 Adrian Gh Podoleanu Optical mapping apparatus with adjustable depth resolution and multiple functionality
US20100220215A1 (en) * 2009-01-12 2010-09-02 Jorge Rubinstein Video acquisition and processing systems
JP5905884B2 (ja) 2011-06-30 2016-04-20 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 復号方法及び復号装置
US9807401B2 (en) * 2011-11-01 2017-10-31 Qualcomm Incorporated Transform unit partitioning for chroma components in video coding
US8964849B2 (en) 2011-11-01 2015-02-24 Blackberry Limited Multi-level significance maps for encoding and decoding
US9743098B2 (en) 2011-11-19 2017-08-22 Blackberry Limited Multi-level significance map scanning
WO2013102293A1 (en) * 2012-01-04 2013-07-11 Mediatek Singapore Pte. Ltd. Improvements of luma-based chroma intra prediction
AU2012200319B2 (en) * 2012-01-19 2015-11-26 Canon Kabushiki Kaisha Method, apparatus and system for encoding and decoding the significance map for residual coefficients of a transform unit
CN110602509A (zh) 2012-02-04 2019-12-20 谷歌技术控股有限责任公司 用于最末重要系数位置编码中的上下文减少的设备和方法
WO2013152736A1 (en) 2012-04-12 2013-10-17 Mediatek Singapore Pte. Ltd. Method and apparatus for block partition of chroma subsampling formats
JP6190361B2 (ja) * 2012-06-01 2017-08-30 シャープ株式会社 算術復号装置、画像復号装置、算術符号化装置、および画像符号化装置
US9538175B2 (en) 2012-09-26 2017-01-03 Qualcomm Incorporated Context derivation for context-adaptive, multi-level significance coding
RU2641223C2 (ru) 2012-11-08 2018-01-16 Кэнон Кабусики Кайся Способ, устройство и система для кодирования и декодирования единиц преобразования единицы кодирования
US11284103B2 (en) * 2014-01-17 2022-03-22 Microsoft Technology Licensing, Llc Intra block copy prediction with asymmetric partitions and encoder-side search patterns, search ranges and approaches to partitioning
EP2908524A1 (en) * 2014-02-14 2015-08-19 France Brevets An apparatus for encoding an ultra-high definition video sequence
WO2016074147A1 (en) * 2014-11-11 2016-05-19 Mediatek Singapore Pte. Ltd. Separated coding tree for luma and chroma
US10362310B2 (en) 2015-10-21 2019-07-23 Qualcomm Incorporated Entropy coding techniques for display stream compression (DSC) of non-4:4:4 chroma sub-sampling
CN105472389B (zh) * 2015-12-01 2018-11-16 上海交通大学 一种用于超高清视频处理系统的片外缓存压缩方法
JP7100582B2 (ja) 2016-02-11 2022-07-13 インターデジタル ヴイシー ホールディングス, インコーポレイテッド 輝度チャネル及び少なくとも1つのクロミナンスチャネルによって表される画像データを含む画像ユニットを符号化/復号する方法及び装置
WO2018056703A1 (ko) * 2016-09-20 2018-03-29 주식회사 케이티 비디오 신호 처리 방법 및 장치
US10368080B2 (en) * 2016-10-21 2019-07-30 Microsoft Technology Licensing, Llc Selective upsampling or refresh of chroma sample values
WO2018236028A1 (ko) * 2017-06-21 2018-12-27 엘지전자(주) 인트라 예측 모드 기반 영상 처리 방법 및 이를 위한 장치

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016106482A (ja) 2009-08-12 2016-06-16 トムソン ライセンシングThomson Licensing 改善されたイントラ・クロマ符号化および復号のための方法および装置
JP2015534373A (ja) 2012-09-28 2015-11-26 キヤノン株式会社 符号化単位の変換単位を符号化および復号化する方法、装置、およびシステム
JP2014143716A (ja) 2014-03-12 2014-08-07 Sony Corp 画像処理装置および方法、プログラム、並びに記録媒体
JP2021536689A (ja) 2018-08-28 2021-12-27 華為技術有限公司Huawei Technologies Co., Ltd. ピクチャパーティショニング方法及び機器

Also Published As

Publication number Publication date
JP2022500926A (ja) 2022-01-04
KR20210050572A (ko) 2021-05-07
US20220046288A1 (en) 2022-02-10
US20230164363A1 (en) 2023-05-25
BR112021003783A2 (pt) 2021-05-18
JP7391175B2 (ja) 2023-12-04
US20230156243A1 (en) 2023-05-18
US20230156242A1 (en) 2023-05-18
CN112771866A (zh) 2021-05-07
JP2023025180A (ja) 2023-02-21
US11910028B2 (en) 2024-02-20
AU2018233042A1 (en) 2020-04-09
TWI820165B (zh) 2023-11-01
TWI820714B (zh) 2023-11-01
WO2020056452A1 (en) 2020-03-26
US20230164364A1 (en) 2023-05-25
US11930224B2 (en) 2024-03-12
TW202234885A (zh) 2022-09-01
MX2021003054A (es) 2021-05-27
US11595699B2 (en) 2023-02-28
TW202013961A (zh) 2020-04-01
EP3854091A4 (en) 2022-08-31
EP3854091A1 (en) 2021-07-28
US20230164365A1 (en) 2023-05-25

Similar Documents

Publication Publication Date Title
JP7191211B2 (ja) 復号する方法、コンピュータプログラム、ビデオ復号装置
TWI776071B (zh) 用以編碼及解碼視訊取樣之轉換區塊的方法、設備和系統
JP2021530124A (ja) ビデオサンプルの変換されたブロックを符号化および復号するための方法、装置、およびシステム
JP7391167B2 (ja) 符号化ブロックを復号する方法、符号化ブロックを符号化する方法、復号装置、符号化装置
TW202135530A (zh) 用於編碼和解碼視訊樣本區塊的方法、設備及系統
TWI786392B (zh) 用於編碼及解碼視訊樣本的區塊的方法、設備和系統
TWI788262B (zh) 用以編碼和解碼視頻樣本之區塊樹的方法、設備及系統
TWI776072B (zh) 用以編碼及解碼視訊取樣之轉換區塊的方法、設備和系統
AU2019284053A1 (en) Method, apparatus and system for encoding and decoding a block of video samples
TWI836542B (zh) 用以編碼及解碼視訊取樣之轉換區塊的方法、設備和非暫態電腦可讀取儲存媒體
AU2020202285A1 (en) Method, apparatus and system for encoding and decoding a block of video samples

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210517

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20220427

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220606

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220804

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20221206

R151 Written notification of patent or utility model registration

Ref document number: 7191211

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151