JP7337163B2 - ビデオサンプルのツリー若しくはブロックを符号化および復号する方法、装置、およびシステム - Google Patents

ビデオサンプルのツリー若しくはブロックを符号化および復号する方法、装置、およびシステム Download PDF

Info

Publication number
JP7337163B2
JP7337163B2 JP2021531285A JP2021531285A JP7337163B2 JP 7337163 B2 JP7337163 B2 JP 7337163B2 JP 2021531285 A JP2021531285 A JP 2021531285A JP 2021531285 A JP2021531285 A JP 2021531285A JP 7337163 B2 JP7337163 B2 JP 7337163B2
Authority
JP
Japan
Prior art keywords
chroma
luma
block
transform
intra
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
JP2021531285A
Other languages
English (en)
Other versions
JP2022522576A (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 JP2022522576A publication Critical patent/JP2022522576A/ja
Priority to JP2023132042A priority Critical patent/JP7549715B2/ja
Application granted granted Critical
Publication of JP7337163B2 publication Critical patent/JP7337163B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/96—Tree coding, e.g. quad-tree coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/119—Adaptive subdivision aspects, e.g. subdivision of a picture into rectangular or non-rectangular coding blocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/12—Selection 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/122—Selection of transform size, e.g. 8x8 or 2x4x8 DCT; Selection of sub-band transforms of varying structure or type
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/132—Sampling, masking or truncation of coding units, e.g. adaptive resampling, frame skipping, frame interpolation or high-frequency transform coefficient masking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/186—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a colour or a chrominance component
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/124—Quantisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
    • H04N19/159—Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/18—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a set of transform coefficients
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/625—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding using discrete cosine transform [DCT]

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

Description

関連出願への参照
本出願は２０１９年３月１１日に出願されたオーストラリア特許出願第2019201653号の出願日の３５Ｕ．Ｓ．Ｃ§１１９に基づく利益を主張し、その全体が本明細書に完全に記載されているかのように参照により本明細書に組み込まれる。
本発明は一般に、デジタルビデオ信号処理に関し、特に、ビデオサンプルのツリー若しくはブロックを符号化及び復号するための方法、装置及びシステムに関する。本発明はまた、ビデオサンプルのツリー若しくはブロックを符号化および復号するためのコンピュータプログラムが記録されたコンピュータ可読媒体を含むコンピュータプログラム製品に関する。
ビデオデータの送信及び記憶のためのアプリケーションを含む、ビデオ符号化のための多くのアプリケーションが現在存在する。多くのビデオ符号化規格も開発されており、他の規格も現在開発中である。ビデオ符号化標準化における最近の開発は、「Joint Video Experts Team」（JVET）と呼ばれるグループの形成をもたらした。Joint Video Experts Team（JVET）は、「Video Coding Experts Group」(VCEG)としても知られる国際電気通信連合（ＩＴＵ）の電気通信標準化セクタ（ＩＴＵ－Ｔ）のStudy Group 16、Question6(SG16／Q6)のメンバー、および「Moving Picture Experts group」（MPEG）としても知られる国際標準化機構／国際電気技術委員会合同技術委員会１／小委員会２９／作業グループ１１(ISO／IEC JTC１／ＳＣ２９／ＷＧ１１）のメンバーを含む。
Joint Video Experts Team（JVET）は、米国サンディエゴで開催された１０回目の会議でレスポンスを分析し、Call for Proposals（CfP）を発行した。提出されたレスポンスは、現在の最新技術のビデオ圧縮規格、すなわち「高効率ビデオ符号化」（ＨＥＶＣ）のものを著しく上回るビデオ圧縮能力を実証した。このアウトパフォーマンスに基づいて、「versatile video coding」（ＶＶＣ）と命名される新しいビデオ圧縮規格を開発するプロジェクトを開始することが決定された。ＶＶＣは特に、ビデオフォーマットが（例えば、より高い解像度およびより高いフレームレートで）能力を増加させ、帯域幅コストが比較的高いＷＡＮ上のサービス配信に対する市場需要の増加に対処することにつれて、絶えずより高い圧縮性能に対する継続的な需要に対処することが予想される。同時に、ＶＶＣは、現代のシリコンプロセスで実施可能でなければならず、達成された性能対実施コスト（例えば、シリコン面積、ＣＰＵプロセッサ負荷、メモリ使用量、および帯域幅に関して）の間の許容可能なトレードオフを提供しなければならない。
ビデオデータは、画像データのフレームのシーケンスを含み、各フレームは、１つまたは複数のカラーチャネルを含む。一般に、１つの一次色チャネル（primary colour channel）と２つの二次色チャネル（secondary colour channel）が必要である。一次色チャネルは一般に「ルマ（luma）」チャネルと呼ばれ、二次色チャネルは一般に「クロマ（chroma）」チャネルと呼ばれる。ビデオデータは典型的にはＲＧＢ(赤－緑－青）色空間で表示されるが、この色空間は３つのそれぞれの要素間に高度の相関を有する。エンコーダまたはデコーダによって見られるビデオデータ表現はしばしば、ＹＣｂＣｒなどの色空間を使用する。ＹＣｂＣｒは、伝達関数に従って「ルマ」にマッピングされた輝度をＹ（一次）チャネルに集中させ、ＣｂおよびＣｒ（二次）チャネルにクロマを集中させる。さらに、ＣｂおよびＣｒチャネルは、「４：２：０クロマフォーマット」として知られる、ルマチャネルと比較してより低いレート、例えば、水平方向に半分および垂直方向に半分で空間的にサンプリング（サブサンプリング）されてもよい。４：２：０クロマフォーマットは、インターネットビデオストリーミング、ブロードキャストテレビジョン、Blu-RayTMディスクへの保存など、「コンシューマ」アプリケーションで一般的に使用される。水平方向に半分のレートでＣｂおよびＣｒチャネルをサブサンプリングし、垂直方向にサブサンプリングしないことは、「４：２：２クロマフォーマット」として知られている。４：２：２クロマフォーマットは、典型的には映画制作などのための映像のキャプチャを含むプロフェッショナルアプリケーションにおいて使用される。４：２：２クロマフォーマットのより高いサンプリングレートは、結果として得られるビデオを、カラーグレーディングのような編集動作に対してより弾力的にする。コンシューマに配布する前に、４：２：２クロマフォーマットマテリアルはしばしば、４：２：０クロマフォーマットに変換され、次いで、コンシューマに配布するために符号化される。クロマフォーマットに加えて、ビデオは、解像度およびフレームレートによっても特徴付けられる。例の解像度は３８４０ｘ２１６０の解像度の超高精細度（ＵＨＤ）、または７６８０ｘ４３２０の解像度の「８Ｋ」で、例のフレームレートは６０または１２０Ｈｚである。ルマサンプルレートは、約５００メガサンプル／秒から数ギガサンプル／秒の範囲であってもよい。４：２：０クロマフォーマットの場合、各クロマチャネルのサンプルレートは、ルマサンプルレートの４分の１であり、４：２：２クロマフォーマットの場合、各クロマチャネルのサンプルレートは、ルマサンプルレートの半分である。
ＶＶＣ規格は、「ブロックベース」コーデックであり、フレームは最初に、「符号化ツリーユニット」（ＣＴＵ）として知られる領域の正方形アレイに分割される。ＣＴＵは一般に、１２８×１２８ルマサンプルなどの比較的大きな面積を占有する。しかしながら、各フレームの右端および下端のＣＴＵは、面積がより小さくてもよい。各ＣＴＵには、ルマチャネルのための「符号化ツリー」と、クロマチャネルのための追加の符号化ツリーとが関連付けられている。符号化ツリーは、ＣＴＵの領域を「符号化ブロック」（ＣＢ）とも呼ばれる一連のブロックに分解することを定義する。単一の符号化ツリーがルマチャネルおよびクロマチャネルの両方のためのブロックを指定することも可能であり、その場合、並置された符号化ブロックの集合は「符号化ユニット」（ＣＵ）と呼ばれ、すなわち、各ＣＵは、各色チャネルについて符号化ブロックを有する。ＣＢは、特定の順序で符号化または復号するために処理される。４：２：０クロマフォーマットの使用の結果として、１２８×１２８ルマサンプル領域のためのルマ符号化ツリーを有するＣＴＵは、１２８×１２８ルマサンプル領域と一緒に配置された６４×６４クロマサンプル領域のための対応するクロマ符号化ツリーを有する。単一の符号化ツリーがルマチャネルおよびクロマチャネルのために使用されているとき、所与のエリアのためのコロケートされたブロックの集合は一般に、「ユニット」、例えば、上述のＣＵ、ならびに「予測ユニット」（ＰＵ）、および「変換ユニット」（ＴＵ）と呼ばれる。所与のエリアに対して別個の符号化ツリーが使用される場合、上述のＣＢ、ならびに「予測ブロック」（ＰＢ）、および「変換ブロック」（ＴＢ）が使用される。
「ユニット」と「ブロック」との間の上記の区別にもかかわらず、用語「ブロック」は、すべてのカラーチャネルに動作が適用されるフレームのエリアまたは領域に対する一般的な用語として使用されてもよい。
各ＣＵに対して、フレームデータの対応する領域のコンテンツ（サンプル値）の予測ユニット（ＰＵ）が生成される（「予測ユニット」）。さらに、予測とエンコーダへの入力で見られる領域のコンテンツとの間の差（または空間領域における「残差」）の表現が形成される。各色チャネルの差は、残差係数のシーケンスとして変換および符号化され、所与のＣＵのための１つまたは複数のＴＵを形成することができる。適用される変換は、残差値の各ブロックに適用される離散コサイン変換（ＤＣＴ）または他の変換とすることができる。この変換は分離可能に適用され、すなわち、２次元変換は、２つのパスで実行される。ブロックは最初に、ブロック内のサンプルの各行に１次元変換を適用することによって変換される。次に、部分結果は、部分結果の各列に１次元変換を適用することによって変換され、残差サンプルを実質的に非相関化する変換係数の最終ブロックを生成する。さまざまなサイズの変換は、長方形形状のブロックの変換を含めて、ＶＶＣ規格によってサポートされ、各側面寸法は２のべき乗である。変換係数は、ビットストリームへのエントロピー符号化のために量子化される。
空間予測（「イントラ予測」）がＰＢを生成するために使用される場合、参照サンプルのセットが、現在のＰＢのための予測サンプルを生成するために使用される。参照サンプルは、既に「再構成」されているＰＢに隣接するサンプルを含む（イントラ予測サンプルへの残差サンプルの追加）。これらの隣接するサンプルは、ＰＢの上に行を形成し、ＰＢの左に列を形成する。行および列はまた、ＰＢ境界を越えて延在し、追加の近傍サンプルを含む。Ｚ順走査におけるブロックの走査により、参照サンプルの幾つかは直前のブロックにおいて再構成されている。直前のブロックからのサンプルの使用は、ビデオエンコーダまたはデコーダを通るブロックのスループットを制限するフィードバック依存性をもたらす。さらに、比較的小さいブロックが他のフレームから予測される場合（「インター予測」）、特にサブピクセル補間フィルタリングに適応するために必要とされる追加のサンプルを考慮すると、基準サンプルをフェッチするためのメモリ帯域幅が過剰になる可能性がある。
本発明の目的は、既存の構成の１つまたは複数の欠点を実質的に克服するか、または少なくとも改善することである。
本開示の一態様は、ビデオビットストリームから画像フレームのカラーチャネルの変換ブロックを復号する方法であって、画像フレームのクロマフォーマットを決定することと、クロマフォーマットは、画像フレームのルマチャネルに対してサブサンプリングされる画像フレームのクロマチャネルを有し、変換ブロックの係数グループサイズを決定することと、係数グループサイズは１６サンプルまでの変換ブロックの最大領域であり、係数グループサイズは、変換ブロックサイズのみに基づいて決定され、（ｉ）変換ブロックのカラープレーンと、（ｉｉ）決定されたクロマフォーマットによるカラープレーンサブサンプリングとの両方に独立しており、ビデオビットストリームから、決定されたサイズの係数グループを使用して変換ブロックを復号することとを有することを特徴とする方法を提供する。
他の様態によれば、ビットストリームの画像フレームのルマ及びクロマカラープレーンに属する変換ブロックに単一のテーブルが使用される。
他の様態によれば、係数グループサイズは、前記変換ブロック幅及び高さの制約内で１：１に最も近いアスペクト比を有するように選択される。
本開示の他の様態は、ビデオビットストリームから画像フレームのカラーチャネルの変換ブロックを復号する方法を実施するコンピュータプログラムが記憶された非一時的コンピュータ可読媒体であって、前記プログラムが、画像フレームのクロマフォーマットを決定するためのコードと、クロマフォーマットは、画像フレームのルマチャネルに対してサブサンプリングされる画像フレームのクロマチャネルを有し、変換ブロックの係数グループサイズを決定するためのコードと、係数グループサイズは１６サンプルまでの変換ブロックの最大領域であり、係数グループサイズは、変換ブロックサイズのみに基づいて決定され、（ｉ）変換ブロックのカラープレーンと、（ｉｉ）決定されたクロマフォーマットによるカラープレーンサブサンプリングとの両方に独立しており、ビデオビットストリームから、決定されたサイズの係数グループを使用して変換ブロックを復号するためのコードとを有することを特徴とする非一時的コンピュータ可読媒体を提供する。
本開示の他の様態は、ビデオデコーダであって、ビデオビットストリームから画像フレームのカラーチャネルの変換ブロックを受信し、画像フレームのクロマフォーマットを決定し、クロマフォーマットは、画像フレームのルマチャネルに対してサブサンプリングされる画像フレームのクロマチャネルを有し、変換ブロックの係数グループサイズを決定し、係数グループサイズは１６サンプルまでの変換ブロックの最大領域であり、係数グループサイズは、変換ブロックサイズのみに基づいて決定され、（ｉ）変換ブロックのカラープレーンと、（ｉｉ）決定されたクロマフォーマットによるカラープレーンサブサンプリングとの両方に独立しており、ビデオビットストリームから、決定されたサイズの係数グループを使用して変換ブロックを復号するように構成されていることを特徴とするビデオデコーダを提供する。
本開示の他の様態は、システムであって、メモリと、プロセッサと、を有し、ここで、前記プロセッサは、ビデオビットストリームから画像フレームのカラーチャネルの変換ブロックを復号する方法を実施するための、前記メモリに記憶されたコードを実行するように構成され、前記方法は、画像フレームのクロマフォーマットを決定することと、クロマフォーマットは、画像フレームのルマチャネルに対してサブサンプリングされる画像フレームのクロマチャネルを有し、変換ブロックの係数グループサイズを決定することと、係数グループサイズは１６サンプルまでの変換ブロックの最大領域であり、係数グループサイズは、変換ブロックサイズのみに基づいて決定され、（ｉ）変換ブロックのカラープレーンと、（ｉｉ）決定されたクロマフォーマットによるカラープレーンサブサンプリングとの両方に独立しており、ビデオビットストリームから、決定されたサイズの係数グループを使用して変換ブロックを復号することとを有することを特徴とするシステムを提供する。
他の態様も開示される。
本発明の少なくとも１つの例示的な実施形態を、以下の図面および付録を参照して説明する。
図１は、ビデオ符号化及び復号システムを示す概略ブロック図である。 図２Ａは、図１のビデオ符号化および復号システムの一方または両方を実施することができる汎用コンピュータシステムの概略ブロック図を形成する。 図２Ｂは、図１のビデオ符号化および復号システムの一方または両方を実施することができる汎用コンピュータシステムの概略ブロック図を形成する。 図３は、ビデオエンコーダの機能モジュールを示す概略ブロック図である。 図４は、ビデオデコーダの機能モジュールを示す概略ブロック図である。 図５は、汎用ビデオ符号化のツリー構造における１つ以上のブロックへのブロックの利用可能な分割を示す概略ブロック図である。 図６は、汎用ビデオ符号化のツリー構造における１つ以上のブロックへのブロックの許可された分割を達成するためのデータフローの概略図である。 図７Ａは、符号化ツリーユニット（ＣＴＵ）をいくつかの符号化ユニット（ＣＵ）に分割する例を示す。 図７Ｂは、符号化ツリーユニット（ＣＴＵ）をいくつかの符号化ユニット（ＣＵ）に分割する例を示す。 図８Ａは、符号化ツリーユニット（ＣＴＵ）を、ルマチャネルおよびクロマチャネルにおけるいくつかの符号化ブロック（ＣＢ）に分割する例を示す。 図８Ｂは、符号化ツリーユニット（ＣＴＵ）を、ルマチャネルおよびクロマチャネルにおけるいくつかの符号化ブロック（ＣＢ）に分割する例を示す。 図８Ｃは、符号化ツリーユニット（ＣＴＵ）を、ルマチャネルおよびクロマチャネルにおけるいくつかの符号化ブロック（ＣＢ）に分割する例を示す。 図９は、変換ブロックサイズおよび関連するスキャンパターンの集合を示す。 図１０は、ルマ符号化ツリーおよびクロマ符号化ツリーにおいて許可された分割のリストを生成するための規則のセットを示す。 図１１は、画像フレームの符号化ツリーをビデオビットストリームに符号化するための方法を示す。 図１２は、ビデオビットストリームから画像フレームの符号化ツリーを復号する方法を示す。 図１３は、画像フレームの符号化ツリーをビデオビットストリームに符号化する方法を示す。 図１４は、ビデオビットストリームから画像フレームの符号化ツリーを復号する方法を示す。 図１５は、イントラ予測符号化ユニットの変換ブロック分割の集合を示す。 図１６は、画像フレームの符号化ユニットをビデオビットストリームに符号化する方法を示す。 図１７は、ビデオビットストリームから画像フレームの符号化ユニットを復号する方法を示す。
添付の図面のいずれか１以上において、同一の参照符号を有するステップ及び／又は特徴を参照する場合、それらのステップ及び／又は特徴は本明細書の目的のために、反対の意図が現れない限り、同一の機能又は動作を有する。
上述のように、直前のブロックからのサンプルの使用は、ビデオエンコーダまたはデコーダにおけるブロックのスループットを制限し得るフィードバック依存性をもたらす。典型的なリアルタイム符号化および復号アプリケーションに必要とされるように、高レートの処理ブロックを維持できることを保証するために、結果として生じるフィードバック依存性ループの重大性を軽減する方法が望ましい。フィードバック依存ループは例えば、毎秒５００－４０００サンプルからの現代のビデオフォーマットの高いサンプルレートに対して特に問題であるが、ＡＳＩＣ（特定用途向け集積回路）クロック周波数は典型的には数百ＭＨｚである。
図１は、ビデオ符号化及び復号システム１００の機能モジュールを示す概略ブロック図である。システム１００は、遭遇する最悪の場合のブロック処理レートを低減するために、ルマ符号化ツリーおよびクロマ符号化ツリーにおける領域の許容される再分割のための異なる規則を利用することができる。例えば、システム１００は、ブロックのアスペクト比にかかわらず、ブロックが常に１６（１６）サンプルの倍数としてサイズ設定されるように動作することができる。さらに、符号化ツリーが小さなルマ符号化ブロックの存在を示す分割を含む場合、分割は、クロマチャネルにおいて禁止されてもよく、その結果、単一のクロマＣＢが複数のルマＣＢと並置される。クロマＣＢは、（１つまたは複数のルマＣＢがインター予測を使用する場合を含む）各コロケートされたルマＣＢの予測モードとは独立して、１つのイントラ予測モードなどの単一の予測モードを使用することができる。残留係数符号化は、２つのサンプルの幅または高さを有するブロックの場合を含めて、１６ブロックサイズの倍数を利用することもできる。
システム１００は、ソース装置１１０と宛先装置１３０とを含む。通信チャネル１２０は、符号化されたビデオ情報をソース装置１１０から宛先装置１３０に通信するために使用される。いくつかの構成では、ソース装置１１０および宛先装置１３０がそれぞれの携帯電話ハンドセットまたは「スマートフォン」のいずれかまたは両方を備えることができ、その場合、通信チャネル１２０はワイヤレスチャネルである。他の構成では、ソース装置１１０および宛先装置１３０がビデオ会議機器を備えることができ、その場合、通信チャネル１２０は通常、インターネット接続などの有線チャネルである。さらに、ソース装置１１０および宛先装置１３０は、無線テレビ放送、ケーブルテレビアプリケーション、インターネットビデオアプリケーション（ストリーミングを含む）、およびファイルサーバ内のハードディスクドライブなどの何らかのコンピュータ可読記憶媒体上に符号化ビデオデータが取り込まれるアプリケーションをサポートする装置を含む、広範囲の装置のうちの任意のものを備えることができる。
図１に示すように、ソース装置１１０は、ビデオソース１１２と、ビデオエンコーダ１１４と、送信機１１６と、を含む。ビデオソース１１２は、典型的には撮像センサ等の、撮像されたビデオフレームデータ（１１３として示されている）のソース、非一時的記録媒体上に格納された前に撮像されたビデオシーケンス、又はリモート撮像センサからのビデオ、を有する。ビデオソース１１２はまた、コンピュータグラフィックスカードの出力であってもよく、例えば、タブレットコンピュータなどのコンピューティングデバイスで実行されているオペレーティングシステムとさまざまなアプリケーションのビデオ出力を表示する。ビデオソース１１２として撮像センサを含み得るソース装置１１０の例は、スマートフォン、ビデオカメラ、業務用ビデオカメラ、およびネットワークビデオカメラを含む。
ビデオエンコーダ１１４は、図３を参照してさらに説明されるように、ビデオソース１１２からの撮像されたフレームデータ（矢印１１３によって示される）をビットストリーム（矢印１１５によって示される）に変換（または「符号化」）する。ビットストリーム１１５は、符号化されたビデオデータ（または「符号化されたビデオ情報」）として通信チャネル１２０を介して送信機１１６によって送信される。ビットストリーム１１５は後に通信チャネル１２０を介して送信されるまで、または通信チャネル１２０を介した送信の代わりに、「フラッシュ」メモリまたはハードディスクドライブなどの非一時的記憶装置１２２に記憶されることも可能である。
宛先装置１３０は、受信機１３２と、ビデオデコーダ１３４と、表示装置１３６と、を含む。受信機１３２は、通信チャネル１２０から符号化されたビデオデータを受信し、受信されたビデオデータをビットストリームとしてビデオデコーダ１３４に渡す（矢印１３３によって示される）。そして、ビデオデコーダ１３４は、（矢印１３５で示す）復号フレームデータを表示装置１３６に出力する。復号フレームデータ１３５は、フレームデータ１１３と同じクロマフォーマットを有する。表示装置１３６の例には、陰極線管、スマートフォン、タブレットコンピュータ、コンピュータモニタ、またはスタンドアロンテレビセットなどの液晶ディスプレイが含まれる。また、ソース装置１１０および宛先装置１３０の各々の機能性が単一の装置で実現されることも可能であり、その例は、携帯電話ハンドセットおよびタブレットコンピュータを含む。
上記の例示的なデバイスにもかかわらず、ソース装置１１０および宛先装置１３０のそれぞれは、一般にハードウェアおよびソフトウェア構成要素の組合せを介して、汎用コンピューティングシステム内で構成され得る。図２Ａは、コンピュータモジュール２０１と、キーボード２０２、マウスポインタデバイス２０３、スキャナ２２６、ビデオソース１１２として構成することができるカメラ２２７、およびマイクロフォン２８０などの入力デバイスと、プリンタ２１５、表示装置１３６として構成することができるディスプレイデバイス２１４、およびスピーカ２１７を含む出力デバイスと、を含む、そのようなコンピュータシステム２００を示す。外部変復調器（モデム）トランシーバ装置２１６は、接続２２１を介して通信ネットワーク２２０との間で通信するためにコンピュータモジュール２０１によって使用され得る。通信チャネル１２０を表すことができる通信ネットワーク２２０は、インターネット、セルラ電気通信ネットワーク、またはプライベートＷＡＮなどの広域ネットワーク（ＷＡＮ）であってもよい。接続２２１が電話回線である場合、モデム２１６は従来の「ダイヤルアップ」モデムであってもよい。あるいは接続２２１が大容量（例えば、ケーブルまたは光）接続である場合、モデム２１６はブロードバンドモデムであってもよい。無線モデムはまた、通信ネットワーク２２０への無線接続のために使用されてもよい。トランシーバ装置２１６は、送信機１１６及び受信機１３２の機能性を提供することができ、通信チャネル１２０は、接続２２１内に具現化することができる。
コンピュータモジュール２０１は、典型的には少なくとも１つのプロセッサユニット２０５と、メモリユニット２０６とを含む。例えば、メモリユニット２０６は、半導体ランダムアクセスメモリ（ＲＡＭ）及び半導体リードオンリーメモリ（ROM）を有することができる。コンピュータモジュール２０１はまた、ビデオディスプレイ２１４、スピーカ２１７、およびマイクロフォン２８０に結合するオーディオビデオインターフェース２０７、キーボード２０２、マウス２０３、スキャナ２２６、カメラ２２７、およびオプションとしてジョイスティックまたは他のヒューマンインターフェースデバイス（図示せず）に結合するＩ／Ｏインターフェース２１３、ならびに外部モデム２１６およびプリンタ２１５のためのインターフェース２０８を含む、いくつかの入出力（Ｉ／Ｏ）インターフェースを含む。オーディオビデオインターフェース２０７からコンピュータモニタ２１４への信号は一般に、コンピュータグラフィックスカードの出力である。いくつかの実装では、モデム２１６が、例えばインターフェース２０８内のコンピュータモジュール２０１内に組み込まれてもよい。コンピュータモジュール２０１はまた、ローカルネットワークインターフェース２１１を有し、これは、接続２２３を介して、ローカルエリアネットワーク（ＬＡＮ）として知られるローカルエリア通信ネットワーク２２２への、コンピュータシステム２００の結合を可能にする。図２Ａに示すように、ローカル通信ネットワーク２２２は、通常、いわゆる「ファイアウォール」デバイスまたは同様の機能のデバイスを含む接続２２４を介してワイドネットワーク２２０に結合することもできる。ローカルネットワークインターフェース２１１は、イーサネットTM回路カード、ブルートゥースTMワイヤレス構成又はＩＥＥＥ８０２．１１ワイヤレス構成を含むことができるが、インターフェース２１１のために多くの他のタイプのインターフェースが実施されてもよい。ローカルネットワークインターフェース２１１は、また、送信機１１６の機能を提供することができ、受信機１３２および通信チャネル１２０はまた、ローカル通信ネットワーク２２２において具現化することができる。
Ｉ／Ｏインターフェース２０８および２１３は、シリアルコネクティビティおよびパラレルコネクティビティのいずれかまたは両方を提供することができ、前者は、典型的にはユニバーサルシリアルバス（ＵＳＢ）規格に従って実施され、対応するＵＳＢコネクタ（図示せず）を有する。記憶装置２０９が提供され、典型的にはハードディスクドライブ（ＨＤＤ）２１０を含む。フロッピーディスクドライブおよび磁気テープドライブ（図示せず）などの他の記憶装置も使用することができる。光ディスクドライブ２１２は、典型的にはデータの不揮発性ソースとして機能するために設けられる。例えば、光ディスク（例えば、ＣＤ－ＲＯＭ、ＤＶＤ、Blu ray DiscTM)、ＵＳＢ－ＲＡＭ、ポータブル、外部ハードドライブ、およびフロッピーディスクなどのポータブルメモリデバイスは、コンピュータシステム２００に対するデータの適切なソースとして使用することができる。典型的にはＨＤＤ２１０、光ドライブ２１２、ネットワーク２２０及び２２２のいずれかはビデオソース１１２として、又はディスプレイ２１４を介して再生するために記憶されるべき復号されたビデオデータのための宛先として動作するように構成されてもよい。システム１００のソース装置１１０および宛先装置１３０は、コンピュータシステム２００において具現化されてもよい。
コンピュータモジュール２０１の構成要素２０５～２１３は、典型的には相互接続バス２０４を介して、当業者に知られているコンピュータシステム２００の従来の動作モードをもたらす方法で通信する。例えば、プロセッサ２０５は、接続２１８を用いてシステムバス２０４に結合される。同様に、メモリ２０６および光ディスクドライブ２１２は、接続２１９によってシステムバス２０４に結合される。上記の構成が実行可能なコンピュータの例には、ＩＢＭ－ＰＣおよび互換機、Sun SPARCステーション、Apple MacTMまたは同様のコンピュータシステムが含まれる。
適切または必要な場合、ビデオエンコーダ１１４およびビデオデコーダ１３４、ならびに以下で説明する方法は、コンピュータシステム２００を使用して実施することができる。具体的には、ビデオエンコーダ１１４、ビデオデコーダ１３４、および説明される方法は、コンピュータシステム２００内で実行可能な１つまたは複数のソフトウェアアプリケーションプログラム２３３として実施することができる。具体的には、ビデオエンコーダ１１４、ビデオデコーダ１３４、および説明する方法のステップは、コンピュータシステム２００内で実行されるソフトウェア２３３内の命令２３１（図２Ｂ参照）によって実行される。ソフトウェア命令２３１は、それぞれが１つ以上の特定のタスクを実行するための１つ以上のコードモジュールとして形成されてもよい。ソフトウェアはまた、２つの別個の部分に分割されてもよく、その場合、第１の部分と対応するコードモジュールは説明される方法を実行し、第２の部分と対応するコードモジュールは、第１の部分とユーザとの間のユーザインターフェースを管理する。
ソフトウェアは例えば、以下に説明する記憶装置を含むコンピュータ可読媒体に記憶することができる。ソフトウェアは、コンピュータ可読媒体からコンピュータシステム２００にロードされ、その後、コンピュータシステム２００によって実行される。このようなソフトウェア又はコンピュータ可読媒体に記録されたコンピュータプログラムを有するコンピュータ可読媒体は、コンピュータプログラム製品である。コンピュータシステム２００におけるコンピュータプログラム製品の使用は、ビデオエンコーダ１１４、ビデオデコーダ１３４、および説明される方法を実施するための有利な装置をもたらすことが好ましい。
ソフトウェア２３３は、典型的にはＨＤＤ２１０またはメモリ２０６に記憶される。ソフトウェアは、コンピュータ可読媒体からコンピュータシステム２００にロードされ、コンピュータシステム２００によって実行される。したがって、例えば、ソフトウェア２３３は、光ディスクドライブ２１２によって読み取られる光学的に読み取り可能なディスク記憶媒体（例えば、ＣＤ－ＲＯＭ）２２５に記憶することができる。
場合によっては、アプリケーションプログラム２３３が１つ以上のＣＤ－ＲＯＭ２２５上で符号化されてユーザに供給され、対応するドライブ２１２を介して読み出されてもよく、あるいはネットワーク２２０または２２２からユーザによって読み出されてもよい。さらに、ソフトウェアは、他のコンピュータ可読媒体からコンピュータシステム２００にロードすることもできる。コンピュータ可読記憶媒体は、実行および／または処理のために記録された命令および／またはデータをコンピュータシステム２００に提供する任意の非一時的な有形の記憶媒体を指す。このような記憶媒体の例としては、フロッピーディスク、磁気テープ、ＣＤ－ＲＯＭ、ＤＶＤ、Blu-ray DiscTM、ハードディスクドライブ、ＲＯＭまたは集積回路、ＵＳＢメモリ、光磁気ディスク、またはＰＣＭＣＩＡカードなどのコンピュータ可読カードを含み、そのような装置がコンピュータモジュール２０１の内部または外部であるか否かは問わない。コンピュータモジュール４０１へのソフトウェア、アプリケーションプログラム、命令および／またはビデオデータまたは符号化されたビデオデータの提供にも参加し得る一時的なまたは非有形のコンピュータ可読伝送媒体の例には、無線または赤外線伝送チャネル、ならびに別のコンピュータまたはネットワーク接続された装置へのネットワーク接続、ならびにウェブサイトなどに記録された電子メール伝送および情報を含むインターネットまたはイントラネットが含まれる。
アプリケーションプログラム２３３の第２の部分および上記の対応するコードモジュールは、ディスプレイ２１４上でレンダリングされるかまたは他の方法で表される１つ以上のグラフィカルユーザインタフェース（ＧＵＩ）を実装するために実行されてもよい。典型的にはキーボード２０２およびマウス２０３の操作を通して、アプリケーションおよびコンピュータシステム２００のユーザは機能的に適応可能な方法でインターフェースを操作し、ＧＵＩに関連するアプリケーションに制御コマンドおよび／または入力を提供することができる。スピーカ２１７を介して出力されるスピーチプロンプトおよびマイクロフォン２８０を介して入力されるユーザ音声コマンドを利用するオーディオインターフェースなど、他の形態の機能的に適応可能なユーザインターフェースを実装することもできる。
図２Ｂは、プロセッサ２０５および「メモリ」２３４の詳細な概略ブロック図である。メモリ２３４は、図２Ａのコンピュータモジュール２０１がアクセス可能な全てのメモリモジュール（ＨＤＤ２０９及び半導体メモリ２０６を含む）の論理集合体を表す。
最初にコンピュータモジュール２０１の電源が入ると、パワーオン自己テスト（ＰＯＳＴ）プログラム２５０が実行される。ＰＯＳＴプログラム２５０は、典型的には図２Ａの半導体メモリ２０６のＲＯＭ２４９に記憶される。ソフトウェアを記憶するＲＯＭ２４９などのハードウェアデバイスは、ファームウェアと呼ばれることもある。ＰＯＳＴプログラム２５０は、コンピュータモジュール２０１内のハードウェアを検査して、適切に機能することを確認し、通常、正しい動作のために、プロセッサ２０５、メモリ２３４（２０９、２０６）、および基本入出力システムソフトウェア（ＢＩＯＳ）モジュール２５１（通常はＲＯＭ２４９にも格納される）をチェックする。ＰＯＳＴプログラム２５０が正常に実行されると、ＢＩＯＳ２５１は、図２Ａのハードディスクドライブ２１０を起動する。ハードディスクドライブ２１０を起動すると、ハードディスクドライブ２１０上に常駐するブートストラップローダプログラム２５２がプロセッサ２０５を介して実行される。これにより、オペレーティングシステム２５３がＲＡＭメモリ２０６にロードされ、その上でオペレーティングシステム２５３が動作を開始する。オペレーティングシステム２５３は、プロセッサ２０５によって実行可能なシステムレベルアプリケーションであり、プロセッサ管理、メモリ管理、デバイス管理、ストレージ管理、ソフトウェアアプリケーションインタフェース、および汎用ユーザインタフェースを含む様々な高レベルの機能を満たす。
オペレーティングシステム２５３は、メモリ２３４（２０９、２０６）を管理して、コンピュータモジュール２０１上で実行される各プロセスまたはアプリケーションが別のプロセスに割り当てられたメモリと衝突することなく実行するのに十分なメモリを有することを保証する。さらに、図２Ａのコンピュータシステム２００で利用可能な異なるタイプのメモリは、各プロセスが効果的に実行できるように、適切に使用されなければならない。したがって、集約メモリ２３４は、メモリの特定のセグメントが（特に明記されていない限り）どのように割り当てられるかを示すことを意図するものではなく、むしろ、コンピュータシステム２００によってアクセス可能なメモリの一般的なビューと、そのようなセグメントがどのように使用されるかを提供することを意図するものである。
図２Ｂに示すように、プロセッサ２０５は、制御部２３９、演算論理ユニット（ＡＬＵ）２４０、時にはキャッシュメモリと呼ばれるローカルまたは内部メモリ２４８、を含む多数の機能モジュールを含む。キャッシュメモリ２４８は、典型的にはレジスタセクション内に多数の記憶レジスタ２４４～２４６を含む。１つ以上の内部バス２４１は、これらの機能モジュールを機能的に相互接続する。プロセッサ２０５はまた、典型的には、接続２１８を使用して、システムバス２０４を介して外部装置と通信するための１つ以上のインターフェース２４２を有する。メモリ２３４は、接続２１９を使用してバス２０４に結合される。
アプリケーションプログラム２３３は、条件分岐およびループ命令を含み得る命令のシーケンス２３１を含む。プログラム２３３はまた、プログラム２３３の実行に使用されるデータ２３２を含んでもよい。命令２３１およびデータ２３２は、それぞれメモリ位置２２８、２２９、２３０および２３５、２３６、２３７に格納される。命令２３１とメモリ位置２２８～２３０の相対的なサイズに応じて、メモリ位置２３０に示される命令によって示されるように、特定の命令を単一のメモリ位置に記憶することができる。あるいは、命令がメモリ位置２２８および２２９に示される命令セグメントによって示されるように、各々が別個のメモリ位置に記憶されるいくつかの部分にセグメント化されてもよい。
一般に、プロセッサ２０５には、その中で実行される命令のセットが与えられる。プロセッサ２０５は後続の入力を待ち、この入力に対してプロセッサ２０５は、別の命令セットを実行することによって反応する。各入力は入力装置２０２、２０３のうちの１つまたは複数によって生成されたデータ、ネットワーク２２０、２０２のうちの１つを介して外部ソースから受信されたデータ、記憶装置２０６、２０９のうちの１つから取り出されたデータ、または対応するリーダ２１２に挿入された記憶媒体２２５から取り出されたデータを含む、いくつかのソースのうちの１つまたは複数から提供することができ、すべて図２Ａに示されている。命令のセットを実行すると、データが出力される場合がある。実行には、データまたは変数をメモリ２３４に記憶することも含まれ得る。
ビデオエンコーダ１１４、ビデオデコーダ１３４、および説明される方法は、メモリ２３４内の対応するメモリ位置２５５、２５６、２５７に格納されている入力変数２５４を使用することができる。ビデオエンコーダ１１４、ビデオデコーダ１３４、および説明される方法は、出力変数２６１を生成し、これらは、メモリ２３４内の対応するメモリ位置２６２、２６３、２６４に格納される。中間変数２５８は、メモリ位置２５９、２６０、２６６および２６７に格納され得る。
図２Ｂのプロセッサ２０５を参照すると、レジスタ２４４、２４５、２４６、演算論理ユニット（ＡＬＵ）２４０、および制御部２３９は、プログラム２３３を構成する命令セット内のすべての命令に対して「フェッチ、デコード、および実行」サイクルを実行するのに必要なマイクロオペレーションのシーケンスを実行するために協働する。各フェッチ、デコード、および実行サイクルは
メモリ位置２２８、２２９、２３０から命令２３１をフェッチまたは読出すフェッチ動作
制御部２３９が、どの命令がフェッチされたかを判定するデコード動作
制御部２３９及び／又はＡＬＵ２４０が命令を実行する動作を実行する
を有する。
その後、次の命令のフェッチ、デコード、および実行サイクルをさらに実行することができる。同様に、制御部２３９がメモリ位置２３２に値を格納または書き込む格納サイクルを実行することができる。
後述する図１０および図１１の方法における各ステップまたはサブプロセスは、プログラム２３３の１つまたは複数のセグメントに関連付けられ、典型的にはプロセッサ２０５内のレジスタセクション２４４、２４５、２４７、ＡＬＵ２４０、および制御部２３９が協働して、プログラム２３３の注記されたセグメントに対する命令セット内のすべての命令に対してフェッチ、デコード、および実行サイクルを実行することによって実行される。
図３は、ビデオエンコーダ１１４の機能モジュールを示す概略ブロック図である。図４は、ビデオデコーダ１３４の機能モジュールを示す概略ブロック図である。一般に、データは、固定サイズのサブブロックへのブロックの分割などのサンプルまたは係数のグループで、または配列として、ビデオデコーダ１３４とビデオエンコーダ１１４の機能モジュールの間を通過する。ビデオエンコーダ１１４およびビデオデコーダ１３４は、図２Ａおよび図２Ｂに示すように、汎用コンピュータシステム２００を使用して実施することができ、様々な機能モジュールは、ハードディスクドライブ２０５上に常駐し、プロセッサ２０５によってその実行中に制御されるソフトウェアアプリケーションプログラム２３３の１つ以上のソフトウェアコードモジュールなど、コンピュータシステム２００内で実行可能なソフトウェアによって、コンピュータシステム２００内の専用ハードウェアによって実現することができる。あるいは、ビデオエンコーダ１１４およびビデオデコーダ１３４は、コンピュータシステム２００内で実行可能なソフトウェアおよび専用ハードウェアの組合せによって実装されてもよい。ビデオエンコーダ１１４、ビデオデコーダ１３４、および説明される方法は、代替として、説明される方法の機能またはサブ機能を実行する１つまたは複数の集積回路などの専用ハードウェアで実装され得る。そのような専用ハードウェアは、グラフィック処理ユニット（ＧＰＵ）、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け標準製品（ＡＳＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または１つまたは複数のマイクロプロセッサおよび関連するメモリを含むことができる。特に、ビデオエンコーダ１１４は、モジュール３１０～３８６を含み、ビデオデコーダ１３４は、ソフトウェアアプリケーションプログラム２３３の１つ以上のソフトウェアコードモジュールとしてそれぞれ実装され得るモジュール４２０～４９６を含む。
図３のビデオエンコーダ１１４は、汎用ビデオ符号化（ＶＶＣ）ビデオ符号化パイプラインの一例であるが、本明細書で説明する処理ステージを実行するために他のビデオコーデックを使用することもできる。ビデオエンコーダ１１４は、一連のフレームのような撮像されたフレームデータ１１３を受信し、各フレームは１つ以上のカラーチャネルを含む。フレームデータ１１３は、４：２：０クロマフォーマットまたは４：２：２クロマフォーマットであってもよい。ブロックパーティショナ３１０は最初に、フレームデータ１１３をＣＴＵに分割し、ＣＴＵのための特定のサイズが使用されるように構成される、一般に正方形の形状である。ＣＴＵのサイズは例えば、６４×６４、１２８×１２８、または２５６×２５６ルマサンプルとすることができる。ブロックパーティショナ３１０は、ルマ符号化ツリー及びクロマ符号化ツリーに従って、各ＣＴＵを１つ以上のＣＢにさらに分割する。ＣＢは様々なサイズを有し、正方形および非正方形のアスペクト比の両方を含んでもよい。図１０を参照して、ブロックパーティショナ３１０の動作をさらに説明する。しかし、ＶＶＣ規格ではＣＢ、ＣＵ、ＰＵ、およびＴＵは常に２の累乗である辺長を有する。したがって、３１２として表される現在のＣＢは、ブロックパーティショナ３１０から出力され、ＣＴＵのクロマ符号化ツリーおよびルマ符号化ツリーに従って、ＣＴＵの１つまたは複数のブロックにわたる反復に従って進行する。ＣＴＵをＣＢに分割するためのオプションは、図５および図６を参照して以下でさらに説明される。
フレームデータ１１３の第１の分割から得られるＣＴＵは、ラスタスキャン順序でスキャンされ、１つまたは複数の「スライス」にグループ化され得る。スライスは「イントラ」（または「Ｉ」）スライスであってもよく、イントラスライス（Ｉスライス）はスライス内のすべてのＣＵがイントラ予測されることを示す。代替的に、スライスは、単一または双予測（それぞれ、「Ｐ」または「Ｂ」スライス）であってもよく、それぞれ、スライスにおける単一および双予測のさらなる利用可能性を示す。
各ＣＴＵに対して、ビデオエンコーダ１１４は２段階で動作する。第１段階（「サーチ」ステージと呼ばれる）では、ブロックパーティショナ３１０が符号化ツリーの様々な潜在的構成をテストする。符号化ツリーの各潜在的構成は、関連する「候補」ＣＢを有する。第１段階は、低歪で高い圧縮効率を提供するＣＢを選択するために様々な候補ＣＢをテストすることを含む。このテストは一般にラグランジュ最適化を含み、それによって候補ＣＢがレート（符号化コスト）と歪（入力フレームデータ１１３に関する誤差）の重み付けされた組合せに基づいて評価される。「最良の」候補ＣＢ（評価されたレート／歪みが最も低いＣＢ）は、ビットストリーム１１５への後続の符号化のために選択される。候補ＣＢの評価には、所与のエリアに対してＣＢを使用するか、または様々な分割オプションに従ってエリアをさらに分割し、結果として生じるより小さいエリアのそれぞれをさらなるＣＢで符号化するか、またはエリアをさらにさらに分割するオプションが含まれる。その結果、ＣＢと符号化ツリー自体の両方がサーチステージで選択される。
ビデオエンコーダ１１４は、各ＣＢ、例えばＣＢ３１２に対して、矢印３２０によって示される予測ブロック（ＰＢ）を生成する。ＰＢ３２０は、関連するＣＢ３１２のコンテンツの予測である。減算器モジュール３２２は、ＰＢ３２０とＣＢ３１２との間に、３２４（または「残差」、空間領域内にある差分を参照する）として示される差分を生成する。差分３２４は、ＰＢ３２０およびＣＢ３１２における対応するサンプル間のブロックサイズの差分である。差分３２４は、変換され、量子化され、矢印３３６によって示される変換ブロック（ＴＢ）として表される。ＰＢ３２０および関連するＴＢ３３６は典型的には例えば、評価されたコストまたは歪みに基づいて、多くの可能な候補ＣＢのうちの１つから選択される。
候補符号化ブロック（ＣＢ）は、関連するＰＢおよび結果として生じる残差についてビデオエンコーダ１１４に利用可能な予測モードの１つから生じるＣＢである。各候補ＣＢは図８を参照して後述するように、１つまたは複数の対応するＴＢをもたらす。ＴＢ３３６は、差分３２４の定量化され変換された表現である。ビデオデコーダ１１４において予測されたＰＢと組み合わされると、ＴＢ３３６は、ビットストリームにおける追加の信号を犠牲にして、復号されたＣＢとオリジナルのＣＢ３１２との間の差分を低減する。
したがって、各候補符号化ブロック（ＣＢ）、すなわち、変換ブロック（ＴＢ）と組み合わせた予測ブロック（ＰＢ）は、関連する符号化コスト（または「レート」）および関連する差分（または「歪み」）を有する。レートは、典型的にはビット単位で測定される。ＣＢの歪みは、典型的には絶対差の和（ＳＡＤ）または二乗差の和（ＳＳＤ）などのサンプル値の差分として推定される。各候補ＰＢから得られる推定は、差分３２４を使用してモード選択器３８６によって決定され、イントラ予測モード（矢印３８８によって表される）を決定する。各候補予測モードと対応する残差符号化に関連する符号化コストの推定は、残差のエントロピー符号化よりもかなり低いコストで実行できる。従って、レート歪み検知における最適モードを決定するために、多数の候補モードを評価することができる。
レート歪みの観点から最適モードの決定は、典型的にはラグランジュ最適化の変形を用いて達成される。イントラ予測モード３８８の選択は、典型的には特定のイントラ予測モードの適用から生じる残差データのための符号化コストを決定することを含む。符号化コストは「絶対変換差の和」（ＳＡＴＤ）を使用することによって近似することができ、それによって、アダマール変換などの比較的単純な変換を使用して、推定された変換残差コストを得る。比較的単純な変換を使用するいくつかの実施形態では、単純化された推定方法から得られるコストがさもなければ完全な評価から決定されるのであろう実際のコストに単調に関係する。単調に関連する推定コストを有する実施形態では、単純化された推定方法を使用して、ビデオエンコーダ１１４の複雑さを低減しながら、同じ決定（すなわち、イントラ予測モード）を行うことができる。推定されたコストと実際のコストとの間の関係における可能な非単調性を可能にするために、簡略化された推定方法を使用して、最良の候補のリストを生成することができる。非単調性は例えば、残差データの符号化に利用可能なさらなるモード決定から生じ得る。最良の候補のリストは、任意の数であってもよい。最良の候補を使用して、より完全な探索を実行して、候補のそれぞれについて残差データを符号化するための最適モード選択を確立することができ、他のモード決定と共にイントラ予測モードの最終選択を可能にする。
他のモード決定は、「変換スキップ」として知られる順方向変換をスキップする能力を含む。変換をスキップすることは、変換基底関数としての表現を介して符号化コストを低減するための適切な相関を欠く残差データに適している。比較的単純なコンピュータ生成グラフィックスのような特定のタイプのコンテンツは、同様の挙動を示すことがある。「スキップされた変換」の場合、変換自体が実行されなくても、残差係数は依然として符号化される。
ラグランジュ処理または類似の最適化処理を採用して、ＣＴＵのＣＢへの最適分割（ブロックパーティショナ３１０による）と、複数の可能性からの最良の予測モードの選択の両方を選択することができる。モード選択モジュール３８６における候補モードのラグランジュ最適化プロセスの適用を通して、最低コスト測定を有するイントラ予測モードが「最良」のモードとして選択される。最低コストのモードは、選択されたイントラ予測モード３８８であり、エントロピーエンコーダ３３８によってビットストリーム１１５に符号化される。モード選択モジュール３８６の動作によるイントラ予測モード３８８の選択は、ブロックパーティショナ３１０の動作に拡張する。例えば、イントラ予測モード３８８の選択のための候補は、所与のブロックに適用可能なモードと、さらに、所与のブロックと一緒に集合的に配置される複数のより小さいブロックに適用可能なモードとを含むことができる。所与のブロックおよびより小さいコロケートされたブロックに適用可能なモードを含む場合、候補を暗黙的に選択するプロセスは、ＣＴＵのＣＢへの最良の階層分解を決定するプロセスでもある。
ビデオエンコーダ１１４の動作の第２段階（「符号化」ステージと呼ばれる）では、選択されたルマ符号化ツリーおよび選択されたクロマ符号化ツリー、したがって選択された各ＣＢに対する反復がビデオエンコーダ１１４内で実行される。反復では、ＣＢが本明細書でさらに説明するように、ビットストリーム１１５に符号化される。
エントロピーエンコーダ３３８は、構文要素の可変長符号化と構文要素の算術符号化の両方をサポートする。算術符号化は、コンテキスト適応２進算術符号化処理を使用してサポートされる。算術的に符号化された構文要素は１つ以上の’ｂｉｎｓ’のシーケンスからなる。ビンはビットと同様に、「０」または「１」の値を持つ。しかし、ビンはビットストリーム１１５内で離散ビットとして符号化されていない。ビンは、「コンテキスト」として知られる、関連する予測（または「可能性」または「最も可能性のある」）値および関連する確率を有する。符号化される実際のビンが予測値と一致するとき、「最確シンボル」（ＭＰＳ）が符号化される。最も確率の高いシンボルを符号化することは、消費されるビットに関して比較的安価である。符号化されるべき実際のビンがありそうな値と一致しない場合、「最低確率シンボル」（ＬＰＳ）が符号化される。最低確率シンボルを符号化することは、消費されるビットに関して比較的高いコストを有する。ビン符号化技術は、「０」対「１」の確率がスキューされるビンの効率的な符号化を可能にする。２つの可能な値（すなわちｆｌａｇ）を持つ構文要素に対しては、単一のビンで十分である。可能な値が多い構文要素の場合は、一連のビンが必要である。
シーケンス中の後のビンの存在は、シーケンス中の前のビンの値に基づいて決定されてもよい。さらに、各ビンは、２つ以上のコンテキストに関連付けることができる。特定のコンテキストの選択は構文要素の以前のビン、隣接する構文要素のビン値（すなわち、隣接するブロックからのもの）などに依存することができる。コンテキスト符号化ビンが符号化されるたびに、そのビンに対して選択されたコンテキスト（もしあれば）は、新しいビン値を反映する方法で更新される。このように、２進算術符号化方式は適応型であると言われている。
また、ビデオエンコーダ１１４によってサポートされるのは、コンテキストを欠くビン（「バイパスビン」）である。バイパスビンは、「０」と「１」との間の等確率分布を仮定して符号化される。したがって、各ビンは、ビットストリーム１１５内の１ビットを占有する。コンテキストがないと、メモリが節約され、複雑さが軽減される。したがって、特定のビンの値の分布が偏っていない場合は、バイパスビンが使用される。コンテキストおよび適応を使用するエントロピーコーダの一例はＣＡＢＡＣ（コンテキスト適応バイナリ算術コーダ）として当技術分野で知られており、このコーダの多くの変形がビデオ符号化に使用されている。
エントロピーエンコーダ３３８は、コンテキスト符号化ビンとバイパス符号化ビンとの組合せを使用してイントラ予測モード３８８を符号化する。典型的には、「最確モード」のリストがビデオエンコーダ１１４において生成される。最も確率の高いモードのリストは典型的には３つまたは６つのモードのような固定長であり、以前のブロックで遭遇したモードを含むことができる。コンテキスト符号化ビンは、イントラ予測モードが最も確率の高いモードの１つかどうかを示すフラグを符号化する。イントラ予測モード３８８が最も確率の高いモードのうちの１つである場合、バイパス符号化されたビンを使用するさらなるシグナリングが符号化される。符号化されたさらなるシグナリングは例えば、切り捨てられた単項ビンストリングを使用して、どの最も確率の高いモードがイントラ予測モード３８８に対応するかを示す。そうでない場合、イントラ予測モード３８８は、「残りのモード」として符号化される。残りのモードとしての符号化は、バイパス符号化されたビンを使用しても符号化される固定長符号などの代替構文を使用して、最も確率の高いモードリストに存在するもの以外のイントラ予測モードを表現する。
マルチプレクサモジュール３８４は、決定された最良のイントラ予測モード３８８に従ってＰＢ３２０を出力し、各候補ＣＢのテストされた予測モードから選択する。候補予測モードは、ビデオエンコーダ１１４によってサポートされるすべての考えられる予測モードを含む必要はない。
予測モードは大きく二つのカテゴリーに分類される。第１のカテゴリは、「イントラフレーム予測」（「イントラ予測」とも呼ばれる）である。イントラフレーム予測では、ブロックに対する予測が生成され、生成方法は現在のフレームから得られた他のサンプルを使用してもよい。イントラ予測されたＰＢの場合、異なるイントラ予測モードがルマおよびクロマのために使用されることが可能であり、したがって、イントラ予測は主に、ＰＢ上での動作に関して説明される。
予測モードの第２のカテゴリは、「インターフレーム予測」（「インター予測」とも呼ばれる）である。インターフレーム予測では、ブロックの予測がビットストリーム内のフレームを符号化する順序で現在のフレームに先行する１つまたは２つのフレームからのサンプルを使用して生成される。さらに、インターフレーム予測のために、単一の符号化ツリーが典型的には、ルマチャネルおよびクロマチャネルの両方について使用される。ビットストリーム内のフレームの符号化順は、キャプチャまたは表示時のフレームの順序とは異なる場合がある。１つのフレームが予測に使用される場合、ブロックは「単一予測」であると言われ、１つの関連する動きベクトルを有する。２つのフレームが予測に使用される場合、ブロックは「双予測」されると言われ、２つの関連する動きベクトルを有する。Ｐスライスの場合、各ＣＵは、イントラ予測または単一予測され得る。Ｂスライスの場合、各ＣＵは、イントラ予測、単一予測、または双予測され得る。フレームは、典型的にはフレームの時間的階層を可能にする「ピクチャのグループ」構造を使用して符号化される。フレームの時間的階層は、フレームがフレームを表示する順序で、先行するピクチャおよび後続するピクチャを参照することを可能にする。画像は、各フレームを復号するための依存関係が満たされていることを確認するために必要な順序で符号化される。
インター予測のサブカテゴリは、「スキップモード」と呼ばれる。インター予測およびスキップモードは、２つの別個のモードとして説明される。しかしながら、インター予測モード及びスキップモードの両方は、先行するフレームからのサンプルのブロックを参照する動きベクトルを含む。インター予測は符号化された動きベクトルデルタを含み、動きベクトル予測子に対する動きベクトルを指定する。動きベクトル予測子は、「マージインデックス」で選択された１つ以上の候補動きベクトルのリストから得られる。符号化された動きベクトルデルタは、選択された動きベクトル予測に空間オフセットを提供する。また、インター予測は、ビットストリーム１３３内の符号化された残差を使用する。スキップモードは、インデックス（「マージインデックス」とも呼ばれる）のみを使用して、いくつかの動きベクトル候補のうちの１つを選択する。選択された候補は、さらなるシグナリングなしに使用される。また、スキップモードは、残差係数の符号化をサポートしない。スキップモードが使用されるとき、符号化された残差係数がないことは、スキップモードのための変換を実行する必要がないことを意味する。したがって、スキップモードは、典型的にはパイプライン処理問題を生じない。パイプライン処理問題は、イントラ予測ＣＵおよびインター予測ＣＵの場合であり得る。スキップモードの限定されたシグナリングのために、スキップモードは比較的高品質の参照フレームが利用可能であるときに、非常に高い圧縮性能を達成するために有用である。ランダムアクセスピクチャグループ構造のより高い時間レイヤにおける双予測ＣＵは、典型的には基礎となる動きを正確に反映する高品質の参照ピクチャおよび動きベクトル候補を有する。
サンプルは、動きベクトルおよび参照ピクチャインデックスに従って選択される。動きベクトルおよび参照ピクチャインデックスは、すべてのカラーチャネルに適用され、したがって、インター予測は主に、ＰＢではなくＰＵ上での動作に関して説明される。各カテゴリー内（すなわち、イントラおよびインターフレーム予測）では、ＰＵを生成するために異なる技法を適用することができる。例えば、イントラ予測は、所定のフィルタリング及び生成処理に従ってＰＵを生成する方向と組み合わせて、以前に再構成されたサンプルの隣接する行及び列からの値を使用することができる。あるいは、ＰＵが少数のパラメータを使用して記述されてもよい。インター予測法は、動きパラメータの数とその精度で変わる可能性がある。動きパラメータは通常、参照フレームのリストからのどの参照フレームが使用されるべきかを示す参照フレームインデックスと、参照フレームの各々のための空間変換とを含むが、より多くのフレーム、特別なフレーム、またはスケーリングおよび回転などの複雑なアフィンパラメータを含むことができる。さらに、参照サンプルブロックに基づいて高密度動き推定を生成するために、所定の動き精緻化処理を適用することができる。
ＰＢ３２０を決定し、選択し、減算器３２２で元のサンプルブロックからＰＢ３２０を減算すると、符号化コストが最も低い、３２４で表される残差が得られ、非可逆圧縮を受ける。非可逆圧縮プロセスは、変換、量子化、およびエントロピー符号化のステップを含む。順方向一次変換モジュール３２６は、差分３２４に順方向変換を適用し、差分３２４を空間領域から周波数領域に変換し、矢印３２８によって表される一次変換係数を生成する。一次変換係数３２８は、順方向二次変換モジュール３３０に渡され、非分離二次変換（ＮＳＳＴ）動作を実行することによって、矢印３３２によって表される変換係数を生成する。順方向一次変換は典型的には分離可能であり、典型的にはＤＣＴ－２を使用して、行のセット、次いで各ブロックの列のセットを変換するが、ＤＳＴ－７およびＤＣＴ－８も、例えば、１６サンプルを超えないブロック幅については水平方向に、１６サンプルを超えないブロック高さについては垂直方向に利用可能であり得る。行および列の各セットの変換は、最初にブロックの各行に１次元変換を適用して部分結果を生成し、次に部分結果の各列に１次元変換を適用して最終結果を生成することによって実行される。順方向二次変換は一般に、分離不可能な変換であり、これは、イントラ予測されたＣＵの残差に対してのみ適用され、それにもかかわらず、バイパスされてもよい。順方向二次変換は、１６個のサンプル（１次変換係数３２８の左上４×４サブブロックとして配置される）または６４個のサンプル（１次変換係数３２８の４つの４×４サブブロックとして配置される、左上８×８係数として配置される）のいずれかで動作する。更に、順方向二次変換の行列係数は、使用のために２組の係数が利用できるように、ＣＵのイントラ予測モードに従って複数のセットから選択される。行列係数のセットの１つ、または順方向二次変換のバイパスを使用することは、「ｎｓｓｔ＿ｉｎｄｅｘ」のシンタックス要素でシグナリングされ、切り捨てられた単項二値化（a truncated unary binarisation）を使って、値ゼロ（二次変換は適用されない）、１つ（選択された行列係数の第１セット）、または２つ（選択された行列係数の第２セット）を表すように符号化されている。
変換係数３３２は、量子化器モジュール３３４に渡される。モジュール３３４では、「量子化パラメータ」による量子化が実行され、矢印３３６によって表される残差係数が生成される。量子化パラメータは所与のＴＢについて一定であり、したがって、ＴＢについての残差係数の生成のための均一なスケーリングをもたらす。「量子化行列」を適用することによって、不均一なスケーリングも可能であり、それによって、各残差係数に適用されるスケーリング係数は、量子化パラメータと、典型的にはＴＢのサイズに等しいサイズを有するスケーリング行列内の対応するエントリとの組合せから導出される。残差係数３３６は、ビットストリーム１１５における符号化のためにエントロピーエンコーダ３３８に供給される。典型的には、ＴＵの少なくとも１つの有意な残差係数を有する各ＴＢの残差係数がスキャンパターンに従って、値の順序付けられたリストを生成するためにスキャンされる。スキャンパターンは一般に、４×４「サブブロック」のシーケンスとしてＴＢをスキャンし、残差係数の４×４セットの粒度で規則的なスキャン動作を提供し、サブブロックの配置は、ＴＢのサイズに依存する。さらに、予測モード３８８および対応するブロック分割もビットストリーム１１５に符号化される。
上述したように、ビデオエンコーダ１１４は、ビデオデコーダ１３４に見られるフレーム表現に対応するフレーム表現にアクセスする必要がある。従って、残差係数３３６も逆量子化器モジュール３４０によって逆量子化され、矢印３４２によって表される逆変換係数を生成する。逆変換係数３４２は、逆二次変換モジュール３４４を通過して、矢印３４６で表される中間逆変換係数を生成する。中間逆変換係数３４６は、ＴＵの矢印３５０によって表される残差サンプルを生成するために、逆一次変換モジュール３４８に渡される。逆二次変換モジュール３４４によって実行される逆変換のタイプは、順方向二次変換モジュール３３０によって実行される順変換のタイプに対応する。逆一次変換モジュール３４８によって実行される逆変換のタイプは、一次変換モジュール３２６によって実行される一次変換のタイプに対応する。加算モジュール３５２は、残差サンプル３５０とＰＵ３２０とを加算して、ＣＵの再構成サンプル（矢印３５４によって示される）を生成する。
再構成されたサンプル３５４は、参照サンプルキャッシュ３５６およびループ内フィルタモジュール３６８に渡される。参照サンプルキャッシュ３５６は、通常ＡＳＩＣ上のスタティックＲＡＭを使用して実現され（したがって、コストのかかるオフチップメモリアクセスを回避する）、フレーム内の後続のＣＵのためのフレーム内ＰＢを生成するための依存関係を満たすために必要な最小限のサンプル記憶装置を提供する。最小依存関係は、典型的にはＣＴＵの行の最下部に沿ったサンプルの「ラインバッファ」を含み、ＣＴＵの次の行および列バッファリングによって使用され、その範囲はＣＴＵの高さによって設定される。参照サンプルキャッシュ３５６は、参照サンプルフィルタ３６０に参照サンプル（矢印３５８で示す）を供給する。サンプルフィルタ３６０は、平滑化演算を適用して、フィルタリングされた参照サンプル（矢印３６２によって示される）を生成する。フィルタリングされた参照サンプル３６２は、イントラフレーム予測モジュール３６４によって使用され、矢印３６６によって表されるサンプルのイントラ予測ブロックを生成する。各候補イントラ予測モードについて、イントラフレーム予測モジュール３６４は、サンプルのブロック、すなわち３６６を生成する。
ループ内フィルタモジュール３６８は、再構成されたサンプル３５４にいくつかのフィルタリング段階を適用する。フィルタリング段階は、不連続性から生じるアーチファクトを低減するために、ＣＵ境界に整列された平滑化を適用する「デブロッキングフィルタ」（ＤＢＦ）を含む。インループフィルタモジュール３６８に存在する別のフィルタリング段階は、「適応ループフィルタ」（ＡＬＦ）であり、これは、歪みをさらに低減するためにウィナーベースの適応フィルタを適用する。ループ内フィルタモジュール３６８における更なる利用可能なフィルタリング段階は、「サンプル適応オフセット」（ＳＡＯ）フィルタである。ＳＡＯフィルタは最初に、再構成されたサンプルを１つまたは複数のカテゴリに分類し、割り当てられたカテゴリに従って、サンプルレベルでオフセットを適用することによって動作する。
矢印３７０で表されるフィルタリングされたサンプルは、ループ内フィルタモジュール３６８から出力される。フィルタリングされたサンプル３７０は、フレームバッファ３７２に記憶される。フレームバッファ３７２は、典型的には、いくつかの（例えば、１６までの）ピクチャを格納するための容量を有し、従って、メモリ２０６に格納される。フレームバッファ３７２は、大きなメモリ消費が要求されるため、通常、オンチップメモリを使用して記憶されない。したがって、フレームバッファ３７２へのアクセスは、メモリ帯域幅に関してコストがかかる。フレームバッファ３７２は、参照フレーム（矢印３７４によって表される）を動き推定モジュール３７６および動き補償モジュール３８０に提供する。
動き推定モジュール３７６は、いくつかの「動きベクトル」（３７８として示される）を推定し、各々は現在のＣＢの位置からのデカルト空間オフセットであり、フレームバッファ３７２内の参照フレームのうちの１つ内のブロックを参照する。参照サンプルのフィルタリングされたブロック（３８２として表される）は、各動きベクトルに対して生成される。フィルタリングされた参照サンプル３８２は、モードセレクタ３８６による潜在的な選択に利用可能なさらなる候補モードを形成する。さらに、所与のＣＵについて、ＰＵ３２０は、１つの参照ブロック（「単一予測」）を使用して形成されてもよく、または２つの参照ブロック（「双予測」）を使用して形成されてもよい。選択された動きベクトルに対して、動き補償モジュール３８０は、動きベクトル内のサブピクセル精度をサポートするフィルタリング処理に従って、ＰＢ３２０を生成する。したがって、動き推定モジュール３７６（多くの候補動きベクトルに対して動作する）は、計算の複雑さを低減するために、動き補償モジュール３８０（選択された候補のみに対して動作する）のそれと比較して、単純化されたフィルタリング処理を実行することができる。
図３のビデオエンコーダ１１４は汎用ビデオ符号化（ＶＶＣ）を参照して説明されるが、他のビデオ符号化規格または実装はモジュール３１０～３８６の処理段階を使用することもできる。フレームデータ１１３（およびビットストリーム１１５）は、メモリ２０６、ハードディスクドライブ２１０、ＣＤ－ＲＯＭ、Ｂｌｕ－ｒａｙディスクＴＭ、または他のコンピュータ可読記憶媒体から読み取る（または書き込む）こともできる。さらに、フレームデータ１１３（およびビットストリーム１１５）は、通信ネットワーク２２０または無線周波数受信機に接続されたサーバなどの外部ソースから受信（または送信）されてもよい。
ビデオデコーダ１３４を図４に示す。図４のビデオデコーダ１３４は、汎用ビデオコーディング（ＶＶＣ）ビデオデコーディングパイプラインの一例であるが、他のビデオコーデックを使用して、本明細書で説明する処理段階を実行することもできる。図４に示すように、ビットストリーム１３３はビデオデコーダ１３４に入力される。ビットストリーム１３３は、メモリ２０６、ハードディスクドライブ２１０、ＣＤ－ＲＯＭ、Ｂｌｕ－ｒａｙディスクＴＭ、または他の一時的でないコンピュータ可読記憶媒体から読み取ることができる。あるいは、ビットストリーム１３３が通信ネットワーク２２０または無線周波数受信機に接続されたサーバなどの外部ソースから受信されてもよい。ビットストリーム１３３は、復号される撮像フレームデータを表す符号化されたシンタックス要素を含む。
ビットストリーム１３３は、エントロピーデコーダモジュール４２０に入力される。エントロピーデコーダモジュール４２０は、「ｂｉｎｓ」のシーケンスを復号することによってビットストリーム１３３からシンタックス要素を抽出し、そのシンタックス要素の値をビデオデコーダ１３４内の他のモジュールに渡す。エントロピーデコーダモジュール４２０は、演算デコーディングエンジンを使用して、各シンタックス要素を１つ以上のビンのシーケンスとして復号する。各ビンは、ビンの「１」と「０」の値を符号化するために使用される確率レベルを記述するコンテキストと共に、一つ以上の「コンテキスト」を使用することができる。所与のビンに対して複数のコンテキストが利用可能な場合、「コンテキストモデリング」または「コンテキスト選択」ステップが、ビンを復号するために利用可能なコンテキストの１つを選択するために実行される。ビンを復号するプロセスは、順次フィードバックループを形成する。フィードバックループにおける動作の数は、エントロピーデコーダ４２０がビン／秒で高いスループットを達成することを可能にするために最小化されることが好ましい。コンテキストモデリングはコンテキスト、すなわち、現在のビンの前のプロパティを選択するときに、ビデオデコーダ１３４に知られているビットストリームの他のプロパティに依存する。例えば、コンテキストは、符号化ツリー内の現在のＣＵの四分木深さに基づいて選択され得る。依存性は、ビンを復号する前によく知られている特性に基づくか、または長い順次処理を必要とせずに決定されることが好ましい。符号化ツリーの四分木深さは、容易に知られているコンテキストモデリングに対する依存性の一例である。イントラ予測モードは、決定するのが比較的困難または計算集約的であるコンテキストモデリングのための依存性の一例である。イントラ予測モードは、「最も確率の高いモード（most probable modes）」（ＭＰＭ）のリストへのインデックスまたは「残りのモード」のリストへのインデックスのいずれかとして符号化され、ＭＰＭと残りのモードの間の選択は復号された「ｉｎｔｒａ＿ｌｕｍａ＿ｍｐｍ＿ｆｌａｇ」に従っている。ＭＰＭが使用されている場合、「ｉｎｔｒａ＿ｌｕｍａ＿ｍｐｍ＿ｉｄｘ」シンタックス要素が復号され、最も確率の高いモードのうちどれを使用するのかを選択する。一般に、６つのＭＰＭがある。残りのモードが使用されている場合、「ｉｎｔｒａ＿ｌｕｍａ＿ｒｅｍａｉｎｄｅｒ」シンタックス要素が復号され、残りの（非ＭＰＭ）モードのどれを使用するかを選択する。最も確率の高いモードと残りのモードの両方を決定することは、かなりの数の動作を必要とし、隣接ブロックのイントラ予測モードへの依存性を含む。例えば、隣接ブロックは、現在のブロックの左上のブロックであってもよい。望ましくは、各ＣＵのビンのコンテキストが、シグナリングされているイントラ予測モードを知ることなく、算術符号化エンジンによる構文解析を可能にして、決定することができる。したがって、逐次ビン復号のための算術符号化エンジンに存在するフィードバックループは、イントラ予測モードへの依存性を回避する。イントラ予測モード決定は、隣接ブロックのイントラ予測モードに対するＭＰＭリスト構成の依存性のために、別個のフィードバックループを用いて、後続の処理ステージに延期され得る。したがって、エントロピーデコーダモジュール４２０の演算デコードエンジンは、以前の（例えば、隣接する）ブロックのイントラ予測モードを知る必要なく、ｉｎｔｒａ＿ｌｕｍａ＿ｍｐｍ＿ｆｌａｇ、ｉｎｔｒａ＿ｌｕｍａ＿ｍｐｍ＿ｉｄｘ、ｉｎｔｒａ＿ｌｕｍａ＿ｒｅｍａｉｎｄｅｒを構文解析することができる。エントロピーデコーダモジュール４２０は、ビットストリーム１３３からシンタックス要素を復号するために、算術符号化アルゴリズム、例えば「コンテキスト適応２進算術符号化」（ＣＡＢＡＣ）を適用する。復号されたシンタックス要素は、ビデオデコーダ１３４内のパラメータを再構成するために使用される。パラメータは、残差係数（矢印４２４によって表される）と、イントラ予測モード（矢印４５８によって表される）などのモード選択情報とを含む。モード選択情報は、動きベクトル、および各ＣＴＵの１つまたは複数のＣＢへの分割などの情報も含む。パラメータは、典型的には以前に復号されたＣＢからのサンプルデータと組み合わせて、ＰＢを生成するために使用される。
残差係数４２４は、逆量子化モジュール４２８に入力される。逆量子化モジュール４２８は、残差係数４２４に対して逆量子化（または「スケーリング」）を実行して、量子化パラメータに従って、矢印４３２によって表される再構成された中間変換係数を生成する。再構成された中間変換係数４３２は、復号された「ｎｓｓｔ＿ｉｎｄｅｘ」シンタックス要素に従って、二次変換が適用されるか、または演算（バイパス）されない逆二次変換モジュール４３６に渡される。「ｎｓｓｔ＿ｉｎｄｅｘ」は、プロセッサ２０５の実行の下で、エントロピーデコーダ４２０によってビットストリーム１３３から復号される。図３を参照して説明されるように、「ｎｓｓｔ＿ｉｎｄｅｘ」は、ビットストリーム１３３から、ゼロから２の値を有する切り捨てられた単項シンタックス要素として復号される。逆二次変換モジュール４３６は、再構成された変換係数４４０を生成する。不均一な逆量子化行列の使用がビットストリーム１３３に示される場合、ビデオデコーダ１３４は、スケーリングファクタのシーケンスとしてビットストリーム１３３から量子化行列を読み出し、スケーリングファクタを行列に配置する。逆スケーリングは、量子化パラメータと組み合わせて量子化行列を使用して、再構成された中間変換係数４３２を生成する。
再構成された変換係数４４０は、逆一次変換モジュール４４４に渡される。モジュール４４４は、係数を周波数領域から空間領域に戻すように変換する。ＴＢは、有効残差係数値および非有効残差係数値に事実上基づいている。モジュール４４４の動作の結果は、矢印４４８によって表される残差サンプルのブロックである。残差サンプル４４８は、対応するＣＵとサイズが等しい。残差サンプル４４８は、加算モジュール４５０に供給される。加算モジュール４５０において、残差サンプル４４８は、復号されたＰＢ（４５２として表される）に加算されて、矢印４５６によって表される再構成されたサンプルのブロックを生成する。再構成サンプル４５６は、再構成サンプルキャッシュ４６０およびループ内フィルタリングモジュール４８８に供給される。ループ内フィルタリングモジュール４８８は、４９２として表されるフレームサンプルの再構成されたブロックを生成する。フレームサンプル４９２は、フレームバッファ４９６に書き込まれる。
再構成サンプルキャッシュ４６０は、ビデオエンコーダ１１４の再構成サンプルキャッシュ３５６と同様に動作する。再構成されたサンプルキャッシュ４６０は（例えば、典型的には、オンチップメモリであるデータ２３２を代わりに使用することによって）メモリ２０６を介さずに後続のＣＢをイントラ予測するために必要とされる再構成されたサンプルのための記憶装置を提供する。矢印４６４によって表される参照サンプルは、再構成サンプルキャッシュ４６０から得られ、参照サンプルフィルタ４６８に供給されて、矢印４７２によって示されるフィルタリングされた参照サンプルを生成する。フィルタリングされた参照サンプル４７２は、イントラフレーム予測モジュール４７６に供給される。モジュール４７６は、ビットストリーム１３３でシグナリングされ、エントロピーデコーダ４２０によって復号されたイントラ予測モードパラメータ４５８に従って、矢印４８０によって表されるイントラ予測サンプルのブロックを生成する。
ＣＢの予測モードがビットストリーム１３３におけるイントラ予測であることが示されていると、イントラ予測サンプル４８０は、マルチプレクサモジュール４８４を介して復号ＰＢ４５２を形成する。イントラ予測は、サンプルの予測ブロック（ＰＢ）、すなわち、同じ色成分内の「隣接サンプル」を使用して導出された１つの色成分内のブロックを生成する。隣接するサンプルは、現在のブロックに隣接するサンプルであり、ブロック復号順序において先行することにより、既に再構成されている。ルマおよびクロマブロックが並置される場合、ルマおよびクロマブロックは、異なるイントラ予測モードを使用することができる。しかしながら、２つのクロマチャネルはそれぞれ、同じイントラ予測モードを共有する。イントラ予測は、３つのタイプに分類される。「ＤＣイントラ予測」は、隣接するサンプルの平均を表す単一の値でＰＢをポピュレートすることを含む。「プレーンイントラ予測（Planar intra prediction）」は、隣接するサンプルから導出されるＤＣオフセットおよび垂直および水平勾配で、プレーンに従うサンプルでＰＢをポピュレートすることを含む。「角度イントラ予測（Angular intra prediction）」は、フィルタリングされ、ＰＢを横切って特定の方向（または「角度」）に伝播される隣接するサンプルでＰＢをポピュレートすることを含む。ＶＶＣ６５では、正方形ブロックでは使用できない追加の角度を使用できる矩形ブロックで角度がサポートされ、合計８７の角度が生成される。第４のタイプのイントラ予測は、クロマＰＢに利用可能であり、それによって、ＰＢは、「クロス構成要素線形モデル」（ＣＣＬＭ）モードに従って、並置されたルマ再構成サンプルから生成される。３つの異なるＣＣＬＭモードが利用可能であり、その各々は、隣接するルマ及びクロマサンプルから導出された異なるモデルを使用する。次いで、導出されたモデルを使用して、コロケートされたルマサンプルからクロマＰＢのサンプルのブロックを生成する。
ＣＢの予測モードがビットストリーム１３３におけるインター予測であることが示されていると、動き補償モジュール４３４は、フレームバッファ４９６からサンプルのブロックを選択し、フィルタリングするために、動きベクトルおよび参照フレームインデックスを使用して、４３８として表されるインター予測サンプルのブロックを生成する。サンプル４９８のブロックは、フレームバッファ４９６に記憶された以前に復号されたフレームから得られる。双方向予測の場合、２つのサンプルのブロックが生成され、一緒にブレンドされて、復号されたＰＢ４５２のためのサンプルが生成される。フレームバッファ４９６には、ループ内フィルタリングモジュール４８８からのフィルタリングされたブロックデータ４９２でポピュレートされる。ビデオエンコーダ１１４のループ内フィルタリングモジュール３６８と同様に、ループ内フィルタリングモジュール４８８は、ＤＢＦ、ＡＬＦ、およびＳＡＯフィルタリング動作のいずれか、少なくとも、またはすべてを適用する。一般に、動きベクトルは、ルマチャネルとクロマチャネルの両方に適用されるが、サブサンプル補間ルマチャネルおよびクロマチャネルのフィルタリング処理は異なる。符号化ツリーにおける分割が比較的小さなルマブロックの集合をもたらし、対応するクロマ領域が対応する小さなクロマブロックに分割されない場合、ブロックは図１３および図１４をそれぞれ参照して説明されるように、符号化され、復号される。特に、いずれかの小さなルマブロックがインター予測を使用して予測される場合、インター予測動作は、ルマＣＢに対してのみ実行され、対応するクロマＣＢのいずれの部分に対しても実行されない。ループ内フィルタリングモジュール３６８は、再構成されたサンプル４５６からフィルタリングされたブロックデータ４９２を生成する。
図５は、汎用ビデオ符号化のツリー構造内の１つまたは複数のサブ領域への領域の利用可能な分割（divisions）または分割（splits）の集合５００を示す概略ブロック図である。集合５００に示される分割（divisions）は、図３を参照して説明されるように、ラグランジュ最適化によって決定されるように、符号化ツリーに従って各ＣＴＵを１つまたは複数のＣＵまたはＣＢに分割するために、エンコーダ１１４のブロックパーティショナ３１０に利用可能である。
集合５００は、正方形領域のみが他の、おそらくは正方形でないサブ領域に分割されていることを示すが、図５００は潜在的な分割を示しているが、包含領域が正方形であることを必要としないことを理解されたい。含有領域が非正方形の場合、分割から生じるブロックの寸法は含有ブロックの縦横比に従ってスケールされる。領域がそれ以上分割されなくなると、すなわち、符号化ツリーのリーフノードにおいて、ＣＵがその領域を占有する。ブロックパーティショナ３１０によるＣＴＵの１つまたは複数のＣＵへの特定のサブ分割は、ＣＴＵの「符号化ツリー」と呼ばれる。
領域をサブ領域にサブ分割するプロセスは、結果として生じるサブ領域が最小ＣＵサイズに達したときに終了しなければならない。所定の最小サイズ、例えば、１６サンプルより小さいブロック領域を禁止するようにＣＵを制約することに加えて、ＣＵは、４の最小幅または高さを有するように制約される。幅および高さの両方に関して、または幅または高さに関して、他の最小値も可能である。サブ分割のプロセスは、最も深いレベルの分解の前に終了することもでき、その結果、ＣＵが最小ＣＵサイズよりも大きくなる。分割が起こらず、その結果、単一のＣＵがＣＴＵの全体を占有することが可能である。ＣＴＵの全体を占有する単一のＣＵは、最大の利用可能な符号化ユニットサイズである。また、分割が発生しないＣＵは、処理領域サイズよりも大きい。符号化ツリーの最高レベルでの２分割または３分割の結果として、６４×１２８、１２８×６４、３２×１２８、および１２８×３２などのＣＵサイズが可能であり、それぞれも処理領域サイズより大きい。図１０Ａ～１０Ｆを参照してさらに説明される処理領域サイズよりも大きいＣＵＳの例。４：２：０などのサブサンプリングされたクロマフォーマットの使用により、ビデオエンコーダ１１４およびビデオデコーダ１３４の構成は、ルマチャネルにおけるよりも早くクロマチャネルにおける領域の分割を終了させることができる。
符号化ツリーのリーフノードには、それ以上のサブ分割のないＣＵが存在する。例えば、リーフノード５１０は、１つのＣＵを含む。符号化ツリーの非リーフノードには、２つ以上のさらなるノードへの分割が存在し、各ノードはリーフノード従って１つのＣＵを含むか、またはより小さな領域へのさらなる分割を含むことができる。符号化ツリーの各リーフノードにおいて、各カラーチャネルに対して１つの符号化ブロックが存在する。ルマおよびクロマの両方について同じ深さで終端する分割は、３つの並置されたＣＢをもたらす。クロマよりも深いルマの深さで終端する分割は、複数のルマＣＢがクロマチャネルのＣＢと並置されることになる。
四分木分割５１２は図５に示すように、包含領域を４つの等しいサイズの領域に分割する。ＨＥＶＣと比較して、汎用ビデオ符号化（ＶＶＣ）は、水平２分割５１４および垂直２分割５１６を追加することにより、さらなる柔軟性を達成する。分割５１４および５１６の各々は、包含領域を２つの等しいサイズの領域に分割する。分割は、含有ブロック内の水平境界（５１４）または垂直境界（５１６）に沿っている。
水平３分割５１８および垂直３分割５２０を追加することにより、汎用ビデオ符号化においてさらなる柔軟性が達成される。３分割５１８および５２０は、ブロックを、包含領域の幅または高さの１／４および３／４に沿って水平方向（５１８）または垂直方向（５２０）のいずれかで境界をつけられた３つの領域に分割する。４分木、２分木、および３分木の組合せは、「ＱＴＢＴＴＴ」と呼ばれる。ツリーのルートには、ゼロ個以上の四分木分割（ツリーの「ＱＴ」セクション）が含まれる。ＱＴセクションが終了すると、ゼロまたはそれ以上の２分割または３分割（ツリーの「マルチツリー」または「ＭＴ」セクション）が発生し、最終的にツリーのリーフノードのＣＢまたはＣＵで終了する。ツリーがすべてのカラーチャネルを記述する場合、ツリーリーフノードはＣＵである。ツリーがルマチャネルまたはクロマチャネルを記述する場合、ツリーリーフノードはＣＢである。
４分木のみをサポートし、したがって正方形ブロックのみをサポートするＨＥＶＣと比較して、ＱＴＢＴＴＴは、特に２分木および／または３分木分割の可能な再帰的適用を考慮すると、より多くの可能なＣＵサイズをもたらす。異常な（正方形でない）ブロックサイズの可能性は、ブロック幅または高さが４サンプル未満であるか、または４サンプルの倍数ではないかのいずれかになる分割を排除するように分割オプションを制約することによって低減することができる。一般に、この制約は、ルマサンプルを考慮する際に適用される。しかしながら、説明した構成では、制約がクロマチャネル用のブロックに別々に適用することができる。クロマチャネルに対する分割オプションへの制約の適用は、フレームデータが４：２：０クロマフォーマットまたは４：２：２クロマフォーマットの場合など、ルマとクロマで最小ブロックサイズが異なり得る。各分割では、この包含領域に関して辺寸法が変わらない、半分になっている、または１／４になっているサブ領域が生成される。そして、ＣＴＵサイズは２のべき乗であるため、全てのＣＵの辺寸法も２のべき乗である。
図６は、汎用ビデオ符号化で使用されるＱＴＢＴＴＴ(または「符号化ツリー」）構造のデータフロー６００を示す概略フロー図である。ＱＴＢＴＴＴ構造は、ＣＴＵを１つまたは複数のＣＵに分割することを定義するために、各ＣＴＵに対して使用される。各ＣＴＵのＱＴＢＴＴＴ構造は、ビデオエンコーダ１１４内のブロックパーティショナ３１０によって決定され、ビットストリーム１１５に符号化されるか、またはビデオデコーダ１３４内のエントロピーデコーダ４２０によってビットストリーム１３３から復号される。データフロー６００はさらに、図５に示される分割に従って、ＣＴＵを１つまたは複数のＣＵに分割するためにブロックパーティショナ３１０に利用可能な許容可能な組合せを特徴付ける。
階層の最上位レベル、すなわちＣＴＵから始めて、ゼロまたはそれ以上の四分木分割が最初に実行される。具体的には、四分木（ＱＴ）分割決定６１０がブロックパーティショナ３１０によって行われる。「１」シンボルを返す６１０での決定は、四分木分割５１２に従って現在のノードを４つのサブノードに分割する決定を示す。その結果、６２０などの、４つの新しいノードが生成され、各新しいノードについて、ＱＴ分割決定６１０に戻る。各新しいノードは、ラスタ（またはＺスキャン）順序で考慮される。あるいは、ＱＴ分割決定６１０がさらなる分割が実行されるべきでないことを示す（「０」シンボルを返す）場合、四分木分割は停止し、マルチツリー（ＭＴ）分割がその後考慮される。
まず、ＭＴ分割決定６１２がブロックパーティショナ３１０によって行われる。６１２において、ＭＴ分割を実行する決定が示される。決定６１２で「０」のシンボルを返すことは、ノードのサブノードへのそれ以上の分割が実行されないことを示す。ノードのそれ以上の分割が実行されない場合、ノードは符号化ツリーのリーフノードであり、ＣＵに対応する。リーフノードは６２２で出力される。あるいは、ＭＴ分割６１２がＭＴ分割を実行する決定を示す（「１」シンボルを返す）場合、ブロックパーティショナ３１０は方向決定６１４に進む。
方向決定６１４は、水平（「Ｈ」または「０」）または垂直（「Ｖ」または「１」）のいずれかとしてＭＴ分割の方向を示す。ブロックパーティショナ３１０は、決定６１４が水平方向を示す「０」を返す場合、決定６１６に進む。ブロックパーティショナ３１０は、決定６１４が垂直方向を示す「１」を返す場合、決定６１８に進む。
決定６１６および６１８のそれぞれにおいて、ＭＴ分割のパーティション数は、ＢＴ／ＴＴ分割で２つ（２分割または「ＢＴ」ノード）または３つ（３分割または「ＴＴ」）のいずれかとして示される。すなわち、ＢＴ／ＴＴ分割決定６１６は、６１４からの指示された方向が水平であるときにブロックパーティショナ３１０によって行われ、ＢＴ／ＴＴ分割決定６１８は、６１４からの指示された方向が垂直であるときにブロックパーティショナ３１０によって行われる。
ＢＴ／ＴＴ分割決定６１６は、水平分割が「０」を返すことによって示される２分割５１４であるか、「１」を返すことによって示される３分割５１８であるかを示す。ＢＴ／ＴＴ分割決定６１６が２分割を示す場合、ＨＢＴ ＣＴＵノード生成ステップ６２５において、水平２分割５１４に従って、２つのノードがブロックパーティショナ３１０によって生成される。ＢＴ／ＴＴ分割６１６が３分割を示す場合、ＨＴＴ ＣＴＵノード生成ステップ６２６において、水平３分割５１８に従って、ブロックパーティショナ３１０によって３つのノードが生成される。
ＢＴ／ＴＴ分割決定６１８は、垂直分割が「０」を返すことによって示される２分割５１６であるか、「１」を返すことによって示される３分割５２０であるかを示す。ＢＴ／ＴＴ分割６１８が２分割を示す場合、ＶＢＴ ＣＴＵノード生成ステップ６２７では、垂直２分割５１６に従って、ブロックパーティショナ３１０によって２つのノードが生成される。ＢＴ／ＴＴ分割６１８が３分割を示す場合、ＶＴＴ ＣＴＵノード生成ステップ６２８において、垂直３分割５２０に従って、ブロックパーティショナ３１０によって３つのノードが生成される。ステップ６２５～６２８から生じる各ノードについて、ＭＴ分割決定６１２に戻るデータフロー６００の再帰が、方向６１４に応じて、左から右へ、または上から下への順序で適用される。その結果、２分木および３分木分割を適用して、様々なサイズを有するＣＵを生成することができる。
符号化ツリーの各ノードにおける許可された分割および許可されない分割のセットは、図９を参照してさらに説明される。
図７Ａおよび７Ｂは、ＣＴＵ７１０のいくつかのＣＵまたはＣＢへの分割例７００を提供する。ＣＵ７１２の一例を図７Ａに示す。図７Ａは、ＣＴＵ７１０におけるＣＵの空間配置を示す。分割例７００は、図７Ｂに符号化ツリー７２０としても示されている。
図７ＡのＣＴＵ７１０内の各非リーフノード、例えばノード７１４、７１６および７１８において、収容されたノード（さらに分割されていてもよいし、ＣＵであってもよい）は、ノードのリストを作成するために「Ｚオーダー」でスキャンまたはトラバースされ、符号化ツリー７２０内のカラムとして表される。４分木分割の場合、Ｚオーダースキャンは、左上から右に続いて左下から右の順序になる。水平分割および垂直分割の場合、Ｚオーダースキャン（トラバーサル）は、それぞれ、上から下へ、および左から右へのスキャンに単純化する。図７Ｂの符号化ツリー７２０は、適用されたスキャンオーダーに従って、すべてのノードおよびＣＵをリストする。各分割は、リーフノード（ＣＵ）に到達するまで、ツリーの次のレベルで２、３、または４個の新しいノードのリストを生成する。
ブロックパーティショナ３１０によって画像をＣＴＵに分解し、さらにＣＵに分解し、図３を参照して説明されるように、各残差ブロック（３２４）を生成するためにＣＵを用いて、残差ブロックは、ビデオエンコーダ１１４によって順変換および量子化される。結果として得られるＴＢ３３６は、その後、エントロピー符号化モジュール３３８の動作の一部として、残差係数の順次リストを形成するためにスキャンされる。同等のプロセスがビットストリーム１３３からＴＢを得るために、ビデオデコーダ１３４内で実行される。
図７Ａおよび７Ｂの例は、ルマチャネルおよびクロマチャネルの両方に適用可能な符号化ツリーを説明する。しかしながら、図７Ａおよび図７Ｂの例は、ルマチャネルのみに適用可能な符号化ツリーまたはクロマチャネルのみに適用可能な符号化ツリーのトラバースに関する挙動も示す。多くのネストされた分割を持つ符号化ツリーの場合、より深いレベルで利用可能な分割オプションは、対応する小さな領域の利用可能なブロックサイズの制限によって制約される。小さな領域のための利用可能なブロックサイズに対する制限は、実装に不合理な負担を課すほど高いブロック処理レートの最悪の場合を防止するために課される。特に、ブロックサイズがクロマにおける１６（１６）個のサンプルの倍数であるという制約は、実装が１６（１６）個のサンプルの粒度でサンプルを処理することを可能にする。ブロックサイズを１６サンプルの倍数に制限することは、「イントラ再構成」フィードバックループ、すなわち、モジュール４５０、４６０、４６８、４７６、および４８４を含む図４のビデオデコーダ１３４内の経路、ならびにビデオエンコーダ１１４内の同等の経路に特に関連する。特に、ブロックサイズを１６（１６）サンプルの倍数に制限することは、イントラ予測モードにおけるスループットを維持するのに役立つ。例えば、「同時データ複数命令」(ＳＩＭＤ)マイクロプロセッサアーキテクチャは一般に、１６個のサンプルを含むことができるワイドワード上で動作する。また、ハードウェアアーキテクチャは、イントラ再構成フィードバックループに沿ってサンプルを転送するために、１６サンプルの幅を有するバスのような広いバスを使用することができる。より小さなブロックサイズ、例えば４つのサンプルが使用されるならば、バスは、例えばサンプルデータを含むバス幅の４分の１だけ、十分に利用されないであろう。利用不足のバスはより小さなブロック（すなわち、１６サンプル未満）を処理することができるが、比較的小さなサイズの多くのブロック又は全てのブロックのような最悪の場合のシナリオでは、利用不足がエンコーダ（１１４）又はデコーダ（１３４）のリアルタイム動作を妨げる結果となり得る。インター予測の場合、各ブロックは、フレームバッファ（バッファ３７２または４９６など）から取得された参照サンプルに依存する。フレームバッファは、先行するフレームを処理するときに参照サンプルで占められるので、インター予測ブロックを生成するためのブロックバイブロック動作に影響を及ぼすフィードバック依存ループはない。イントラフレーム再構成に関連するフィードバック依存ループに加えて、イントラ予測モード４５８の決定に関連する追加の同時フィードバックループが存在する。イントラ予測モード４５８は、最も確率の高いモードリストからモードを選択することによって、または残りのモードリストからモードを選択することによって決定される。最も確率の高いモードリストおよび残りのモードリストの決定は、隣接ブロックのイントラ予測モードを必要とする。比較的小さいブロックサイズが使用される場合、最も確率の高いモードリストおよび残りのモードリストはより頻繁に、すなわち、サンプルのブロックサイズおよびチャネルのサンプリングレートによって支配される周波数で決定される必要がある。
図８Ａ、８Ｂ、および８Ｃは、ルマ分割の前に終端され、４：２：０クロマフォーマットを使用するクロマ分割を有する符号化ツリー８２０（図８Ｂ）によるＣＴＵ８００（８Ａ）の例示的な分割を提供する。クロマ分割が終了する場合、各クロマチャネルに１つずつ、１対のＣＢが使用される。説明の便宜上、サイズ６４×６４ルマサンプルのＣＴＵ８００。ＣＴＵ８００は、１２８×１２８のＣＴＵサイズと、１つの追加の四分木分割を含む符号化ツリーとに等しい。四分木分割が８×８ルマ領域８１４に適用される。８×８ルマ領域８１４は、４つの４×４ルマＣＢに分割されるが、クロマチャネルでは分割は起こらない。その代わりに、所定の最小サイズ（記載された例では１６）のクロマＣＢペアが使用され、１つは各クロマチャネルに対応する。クロマＣＢのペアは、典型的には同時に処理されることが望ましいサンプルの数に対する最小粒度に対応する最小サイズである。例えば、ビデオエンコーダ１１４およびビデオエンコーダ１３４の多くの実装は例えば、ハードウェア実装における対応する幅の広い内部バスの使用により、１６サンプルのセットに対して動作する。さらに、分割から生じる各ルマＣＢは、少なくとも部分的に、クロマＣＢのペアと重なり、集合ルマＣＢは、クロマＣＢのペアと完全に重なる。領域８１４の例では、４×４のクロマＣＢのペアが生成される。図８Ｃは、結果として得られるルマＣＢとクロマＣＢとがどのように関連するかの例を示す。
再び８Ａを参照すると、垂直２分割が１６×４ルマ領域８１０に適用される。１６×４ルマ領域８１０は、２つの８×４ルマＣＢに分割されるが、クロマチャネルには分割は起こらず、８×２クロマＣＢのペアをもたらす。１６×４ルマ領域８１２には、垂直３分割が適用される。１６×４ルマ領域８１２は、４×４、４×８、および４×４ルマＣＢに分割されるが、クロマチャネルには分割は起こらず、８×２クロマＣＢのペアをもたらす。水平２分割は、８×１６ルマ領域８１６に適用される。８×１６ルマ領域８１６は、８×４、８×８、および８×４ルマＣＢに分割されるが、クロマチャネルでは分割は起こらず、４×８クロマＣＢのペアをもたらす。したがって、クロマＣＢは、面積が少なくとも１６サンプルである。
図８Ｃは、異なる平面内の異なるブロック構造を例示するために、「爆発的（exploded）」（または分離）方式で示される３つの色平面を有するＣＴＵ８００の一部を示す。ルマサンプル平面８５０、第１のクロマサンプル平面８５２、および第２のクロマサンプル平面８５４が示されている。「ＹＣｂＣｒ」色空間が使用中であるとき、ルマサンプル平面８５０は画像フレームのＹサンプルを含み、第１のクロマサンプル平面８５２は画像フレームのＣｂサンプルを含み、第２のクロマサンプル平面８５４は画像フレームのＣｒサンプルを含む。４：２：０クロマフォーマットを使用すると、第１のクロマサンプル平面８５２および第２のクロマサンプル平面８５４は、ルマサンプル平面８５０に対して水平および垂直にサンプル密度の半分を有することになる。結果として、サンプル中のクロマブロックのＣＢ寸法は、典型的には対応するルマＣＢの寸法の半分である。すなわち、４：２：０クロマフォーマットの場合、クロマＣＢの幅および高さは、それぞれ、コロケートされたルマＣＢの幅および高さの半分である。４：２：２クロマフォーマットの場合、クロマＣＢの高さはコロケートされたルマＣＢの高さの半分であり、幅はコロケートされたルマＣＢの幅と同じである。明確にするために、８×１６ルマ領域８１６の符号化ツリーにおける親分割のみが示され、分割はルマサンプル平面８５０においてのみ示される。クロマ分割が終了すると、複数のルマＣＢがクロマＣＢのペアと並置される。例えば、ＣＴＵ８００の符号化ツリーは、８×１６ルマ領域８１６に適用される水平３分割を含む。水平３分割は、ルマサンプル平面８５０に存在する、８×４ルマＣＢ８６０、８×８ルマＣＢ８６２、および８×４ルマＣＢ８６４をもたらす。８×１６ルマ領域８１６は、クロマサンプル平面（８５２および８５４）内の４×８クロマサンプルのエリアに対応するので、符号化ツリーの３分割はクロマサンプル平面（８５２および８５４）には適用されない。したがって、４×８クロマサンプルの領域は、クロマについてのリーフノードを形成し、その結果、クロマＣＢのペア、すなわち、第１のクロマサンプル平面８５２についてのクロマＣＢ８６６と、第２のクロマサンプル平面８５４についてのクロマＣＢ８６８とが得られる。ルマ平面のみに適用される水平３分割の例では、３２サンプルの最小クロマＣＢサイズが達成される。他の例示的なルマ領域（８１０、８１２、および８１４）は、最小ルマブロックサイズおよびサンプル処理の所望の粒度に対応する、１６の最小クロマＣＢサイズをもたらす。
図９は、４：２：０クロマフォーマットの使用から生じるクロマチャネルのための変換ブロックサイズおよび関連するスキャンパターンの集合９００を示す。集合９００は、４：２：２クロマフォーマットにも使用することができる。記載された構成は、特に４：２：０及び４：２：２フォーマットに対して、画像フレームのクロマチャネルが画像フレームのルマチャネルに対してサブサンプリングされるクロマフォーマットを有する画像フレームと共に使用するのに適している。集合９００は、全ての可能なクロマ変換ブロックサイズを含まない。図９には、１６以下の幅または８以下の高さを有するクロマ変換ブロックのみが示されている。より大きな幅および高さを有するクロマブロックが生じ得るが、参照を容易にするために図９には示されていない。
禁止された変換サイズ９１０のセットは、変換ブロックサイズ２×２、２×４、および４×２を含み、これらはすべて、１６サンプル未満の領域を有する。言い換えれば、図９の例では、特にイントラ予測ＣＢについて、１６（１６）個のクロマサンプルの最小変換サイズが説明された構成の動作から生じる。禁止された変換サイズ９１０のインスタンスは、図１０を参照して説明したように、分割オプションを決定することによって回避される。変換における残差係数は、変換が「サブブロック」（または「係数グループ」）に分割される２層アプローチでスキャンされる。スキャンは、最後の有効（非ゼロ）係数からＤＣ（左上）係数に向かってスキャン経路に沿って行われる。スキャン経路は、各サブブロック（「下位層」）内の進行、および１つのサブブロックから次（「上位層」）への進行として定義される。集合９００では、８×２ＴＢ９２０が８×２サブブロック、すなわち、１６個の残差係数を含むサブブロックを使用する。２×８ＴＢ９２２は、２×８サブブロックを使用し、すなわち、１６個の残差係数も含む。
幅または高さが２であり、他の寸法が８の倍数であるＴＢは、複数の２×８または８×２サブブロックを使用する。したがって、いくつかの例では２つのサンプルの幅を有するクロマブロックが、ブロックをサブブロックに分割することを使用して符号化され、サイズ２×８サンプルのそれぞれと、２つのサンプルの高さを有するクロマブロックとはいくつかの例ではブロックをサブブロックに分割することを使用して符号化され、サイズ８×２サンプルのそれぞれである。例えば、１６×２ＴＢ９１６は、２つの８×２サブブロックを有し、各サブブロックは、ＴＢ９２０に対して示されるようにスキャンされる。サブブロック進行９１７に示すように、１つのサブブロックから次へのスキャンの進行。
２×３２ＴＢ（図９には図示せず）は、１×４アレイとして配置された４つの２×８サブブロックを使用する。各サブブロック内の残差係数は、２×８ＴＢ９２２について示されるようにスキャンされ、サブブロックは１×４アレイの最下位サブブロックから最上位サブブロックまで進む。
ＴＢが大きければ大きいほど、同様のスキャンの進行に続く。幅および高さがそれぞれ４以上であるすべてのＴＢについて、４×４サブブロックスキャンが使用される。例えば、４×８ＴＢ９２３は、下位サブブロックから上部サブブロックへの進行と共に、４×４サブブロックスキャン９２４を使用する。４×４ＴＢ９２５は、同様の方法でスキャンすることができる。８×８ＴＢ９２９は、４つの４×４サブブロックに対して進行９３０を使用する。すべての場合において、サブブロック内のスキャンおよびサブブロックからサブブロックへの進行は、後方対角スキャン（a backward diagonal scan）に続き、すなわち、スキャンは、「最後の」有意残差係数からＴＢの左上残差係数に向かって後方に進行する。図９はまた、例えば、８×４ＴＢ９３２、１６×４ＴＢ９３４、および１６×８ＴＢ９３６にわたるスキャン順序を示す。さらに、スキャン経路に沿った最後の有意係数の位置に応じて、サブブロックの最後の有意係数位置から左上の残差係数に戻るまでの最後の有意残差係数を含むサブブロックの部分のみをスキャンする必要がある。順方向（すなわち、ブロックの右下により近い）にスキャン経路に沿ったさらなるサブブロックは、スキャンされる必要はない。集合９００、特に禁止された変換サイズ９１０は、図１０を参照して説明されるように、クロマにおける符号化ツリーの領域（またはノード）をサブ領域（またはサブノード）に分割する能力に制限を課す。
２×２、２×４、および４×２のＴＢ（ＴＢ９１０のセット）を使用するＶＶＣシステムでは、２×２のサブブロックが２つのサンプルの幅および／または高さのＴＢのために使用され得る。上述したように、ＴＢ９１０の使用は、イントラ再構成フィードバック依存性ループにおけるスループット制約を増加させる。さらに、４つの係数のみを有するサブブロックの使用は、より高いスループットで残差係数を構文解析することの困難性を増加させる。特に、各サブブロックについて、「有意性マップ」は、その中に含まれる各残差係数の有意性を示す。１値の有意性フラグの符号化は、残差係数の大きさを少なくとも１であるとして確立し、ゼロ値フラグの符号化は、残差係数の大きさをゼロとして確立する。（１つ前方からの）残差係数の大きさおよび符号は、「有意である」残差係数についてのみ符号化される。有意ビットは符号化されず、大きさ（ゼロから）がＤＣ係数に対して常に符号化される。高スループットエンコーダおよびデコーダは、リアルタイム動作を維持するために、クロックサイクル当たり複数の有意性マップビンを符号化または復号する必要があり得る。サイクル当たりのマルチビン符号化および復号の難しさは、ビン間依存性がより多いとき、例えば、より小さいサブブロックサイズが使用されるとき、増加する。システム１００において、サブブロックサイズは、ブロックサイズにかかわらず、（最後の有意係数を含むサブブロックの例外にもかかわらず）１６である。
図１０は、クロマ符号化ツリーにおいて許可された分割のリストを生成するための規則１０００のセットを示す。他のフレームは、インター予測されたブロックとイントラ予測されたブロックとの混合を可能にすることができる。符号化ツリーの利用可能な分割の全セットを図６を参照して説明したが、利用可能な変換サイズに対する制限は所与の領域サイズに対する特定の分割オプションに制約を課す。以下に説明するように、各クロマチャネルに対する分割オプションは、対応する符号化ツリーユニットの領域の寸法に従って決定される。
クロマ領域のための規則１０２０は、異なる領域の許可された分割を示す。規則１０２０の許可された分割は、異なるクロマフォーマットが使用されている場合があるので、クロマチャネルが考慮中であっても、ルマサンプルの単位で表現される。
符号化ツリーのノードを横断する際に、符号化ツリーの領域サイズをもつ分割オプションのセットの利用可能性をチェックすることにより、クロマに対する許可された分割のリストを得る。ＣＢを使用して符号化される可能性のある領域をもたらす分割オプションは、許可される分割のリストに追加される。ＣＢを使用して符号化される領域のためには、領域サイズが集合９００からの特定のサイズの整数個の変換で符号化を可能にしなければならない。特定のサイズは、（幅および高さの両方を考慮して）領域サイズを超えない最大サイズであるように選択される。したがって、より小さい領域に対しては、単一の変換が使用される。領域サイズが最大の利用可能な変換のサイズを超える場合、最大の利用可能な変換は、領域の全体を占有するようにタイル化される。
所与の領域（ルマサンプルで表される）を有する符号化ツリー内のノードを考慮する場合、所与のタイプの分割を実行する能力は、分割タイプおよびクロマ領域エリアに従って決定される。図１０に示すように、分割オプションは分割オプションが禁止サイズのサブ領域をもたらすかどうかを決定するために、領域サイズに対してテストされる。許可されたサイズのサブ領域をもたらす分割オプションは、許可されたクロマ分割１０７０と見なされる。
例えば、ＱＴモードである場合（図６の決定６１０に対応する）、クロマ領域のための規則１０２１ａとして示されるように、領域が４：２：０フォーマットのサイズ８×８または４：２：２フォーマットの８×８である場合、分割がクロマチャネルに対してそれぞれ２×２または２×４の変換サイズをもたらすので、四分木分割は許可されない。許容可能な領域サイズを矢印１０２１で示す。同様に、クロマ規則セット１０２０に対する他の許容可能な分割は、矢印１０２２、１０２３、１０２４、１０２５、および１０２６によって示され、図１３および図１４に関連して以下に説明される。矢印１０２１、１０２２、１０２３、１０２４、１０２５および１０２６は、それぞれ許可されたクロマ分割リスト１０７０を参照する。
クロマチャネルの領域サイズは、ルマサンプルグリッドに関して記述される。たとえば、８ｘ４領域は、４：２：０クロマフォーマットが使用されている場合、クロマチャネルの４ｘ２変換に対応する。４：２：２クロマフォーマットが使用されている場合、８ｘ４領域はクロマの４ｘ４変換に対応する。４：４：４クロマフォーマットが使用されているとき、クロマはルマに関してサブサンプリングされず、したがって、クロマにおける変換サイズは領域サイズに対応する。
許容可能な分割オプションは、以下の図１３および図１４に関連してさらに説明される。
図１１は、画像フレームの符号化ツリーをビデオビットストリームに符号化する方法１１００を示す。方法１１００は、構成されたＦＰＧＡ、ＡＳＩＣ、またはＡＳＳＰなどの装置によって実施され得る。さらに、方法１１００は、プロセッサ２０５の実行下でビデオデコーダ１１４によって実行されてもよい。したがって、方法１１００は、コンピュータ可読記憶媒体および／またはメモリ２０６に記憶されてもよい。方法１１００は、クロマフォーマットを判定するステップ１１０５で開始する。
クロマフォーマットを判定するステップ１１０５において、プロセッサ２０５は、フレームデータ１１３のクロマフォーマットを、４：２：０クロマフォーマットまたは４：２：２クロマフォーマットのうちの１つとして判定する。クロマフォーマットはフレームデータのプロパティであり、方法１１００の動作中に変化しない。方法１１００は、プロセッサ２０５の制御下で、ステップ１１０５からフレームをＣＴＵに分割するステップ１１１０に続く。
フレームをＣＴＵに分割するステップ１１１０において、ブロックパーティショナ３１０は、プロセッサ２０５の実行下で、フレームデータ１１３の現在のフレームをＣＴＵのアレイに分割する。分割から生じるＣＴＵにわたる符号化の進行が開始する。プロセッサ内の制御は、ステップ１１１０から符号化ツリーを決定するステップ１１２０に進む。
符号化ツリーを決定するステップ１１２０において、ビデオエンコーダ１１４は、プロセッサ２０５の実行下で、様々な予測モードおよび分割オプションを組み合わせてテストして、ＣＴＵの符号化ツリーに到達する。また、ＣＴＵに対する符号化ツリーの各ＣＵに対する予測モードと残差係数を導出する。一般に、ラグランジュ最適化は、ＣＴＵのための最適な符号化ツリーおよびＣＵを選択するために実行される。インター予測の使用を評価する場合、候補動きベクトルのセットから動きベクトルが選択される。候補動きベクトルは、サーチパターンに従って生成される。候補動きベクトルに対するフェッチされた参照ブロックの歪みのテストを評価する場合、符号化ツリーにおける禁止されたクロマ分割の適用が考慮される。分割がクロマにおいて禁止され、ルマにおいて許可される場合、結果として生じるルマＣＢは、インター予測を使用することができる。動き補償はルマチャンネルのみに適用されるため、歪み演算ではルマ歪みが考慮され、クロマ歪みは考慮されない。クロマ分割が禁止されていた場合、クロマチャンネルで動き補償が行われないため、クロマ歪みは考慮されない。クロマについては、考慮されるイントラ予測モードおよび符号化されたクロマＴＢ（もしあれば）から生じる歪みが考慮される。ルマとクロマの両方を考慮する場合、インター予測検索では、まずルマ歪みに基づいて動きベクトルを選択し、次にクロマ歪みも考慮して動きベクトルを「リファイン」することがある。リファインメントは一般に、サブピクセル変位量のような動きベクトル値上の小さな変動を考慮する。クロマ分割が禁止され、小さいルマブロックに対するインター予測の評価が実行される場合、クロマリファインメントは必要とされない。プロセッサ２０５内の制御は、ステップ１１２０から符号化ツリーを符号化するステップ１１３０に進む。
符号化ツリーを符号化するステップ１１３０において、ビデオエンコーダ１１４は、プロセッサ２０５の実行下で、図１３に関連して説明する方法１３００を実行して、現在のＣＴＵの符号化ツリーをビットストリーム１１５に符号化する。ステップ１１３０は、現在のＣＴＵをビットストリームに符号化するために実行される。プロセッサ２０５における制御は、ステップ１１３０から最後のＣＴＵテストステップ１１４０に進む。
最後のＣＴＵテストステップ１１４０において、プロセッサ２０５は、現在のＣＴＵがスライス又はフレーム内の最後のＣＴＵであるかどうかをテストする。そわない場合（ステップ１１４０で「ＮＯ」）、ビデオエンコーダ１１４は、フレーム内の次のＣＴＵに進み、プロセッサ２０５内の制御はステップ１１４０からステップ１１２０に戻り、フレーム内の残りのＣＴＵの処理を継続する。ＣＴＵがフレームまたはスライス内の最後のＣＴＵである場合、ステップ１１４０は「ＹＥＳ」に戻り、方法１１００は終了する。方法１１００の結果として、画像フレーム全体がＣＴＵのシーケンスとしてビットストリームに符号化される。
図１２は、ビデオビットストリームから画像フレームの符号化ツリーを復号する方法１２００を示す。方法１２００は、構成されたＦＰＧＡ、ＡＳＩＣ、またはＡＳＳＰなどの装置によって実施され得る。さらに、方法１２００は、プロセッサ２０５の実行下でビデオデコーダ１３４によって実行されてもよい。したがって、方法１２００は、コンピュータ可読記憶媒体および／またはメモリ２０６に記憶されてもよい。方法１２００は、クロマフォーマットを判定するステップ１２０５で開始する。
クロマフォーマットを判定するステップ１２０５において、プロセッサ２０５は、フレームデータ１１３のクロマフォーマットを、４：２：０クロマフォーマットまたは４：２：２クロマフォーマットのうちの１つとして判定する。クロマフォーマットはフレームデータのプロパティであり、方法１２００の動作中に変化しない。ビデオデコーダ１３４は、ビットストリーム１３３のプロファイルによってクロマフォーマットを判定してもよい。プロファイルは特定のビットストリーム１３３によって使用され得る符号化ツールのセットを定義し、クロマフォーマットを４：２：０のような特定の値に制約し得る。プロファイルは例えば、ビットストリーム１３３からの「ｐｒｏｆｉｌｅ＿ｉｄｃ」シンタックス要素を復号することによって、またはビットストリーム１３３からの１つ以上の制約フラグを復号することによって判定され、各制約フラグはビットストリーム１３３における特定のツールの使用を制約する。クロマフォーマットがプロファイルによって完全に特定されていない場合、「ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃ」のようなさらなるシンタックスを復号して、クロマフォーマットを判定してもよい。方法１２００は、ステップ１２０５からフレームをＣＴＵに分割するステップ１２１０まで、プロセッサ２０５の実行下で継続する。
フレームをＣＴＵに分割するステップ１２１０において、ビデオデコーダ１３４は、プロセッサ２０５の実行下で、ＣＴＵのアレイに復号されるフレームデータ１３３の現在のフレームの分割を決定する。決定された分割から生じるＣＴＵにわたる復号の進行が開始する。プロセッサ内の制御は、ステップ１２１０から符号化ツリーを復号するステップ１２２０に進む。
符号化ツリーを復号するステップ１２２０において、ビデオデコーダ１３４はプロセッサ２０５の実行下で、ビットストリーム１３３から現在のＣＴＵの符号化ツリーを復号するために、現在のＣＴＵに対して方法１４００を実行する。現在のＣＴＵは、ステップ１２１０の実行から生じるＣＴＵのうちの選択された１つである。プロセッサ２０５における制御は、ステップ１２２０から最後のＣＴＵテストステップ１２４０に進む。
最後のＣＴＵテストステップ１２４０において、プロセッサ２０５は、現在のＣＴＵがスライス又はフレーム内の最後のＣＴＵであるかどうかをテストする。そわない場合（ステップ１２４０で「ＮＯ」）、ビデオデコーダ１３４はフレーム内の次のＣＴＵに進み、プロセッサ２０５内の制御はステップ１２４０からステップ１２２０に戻り、ビットストリームからＣＴＵを復号し続ける。ＣＴＵがフレームまたはスライス内の最後のＣＴＵである場合、ステップ１２４０は「ＹＥＳ」に戻り、方法１３００は終了する。
図１３は、画像フレームの符号化ツリーをビデオビットストリームに符号化する方法１３００を示す。方法１３００は、構成されたＦＰＧＡ、ＡＳＩＣ、またはＡＳＳＰなどの装置によって実施され得る。さらに、方法１３００は、プロセッサ２０５の実行下でビデオエンコーダ１１４によって実行され得る。したがって、方法１３００は、コンピュータ可読記憶媒体および／またはメモリ２０６に記憶されてもよい。方法１３００は各ブロックが最小領域にあるように、ブロックをビットストリーム１１５に符号化する。記載された構成は、所定の最小サイズのサンプルを使用する。説明される例で使用される最小サイズは１６サンプルであり、これは、いくつかのハードウェアおよびソフトウェア実装の観点から好ましい。しかしながら、それにもかかわらず、異なる最小サイズを使用することができる。例えば、３２または６４の処理粒度と、それぞれ３２または６４サンプルの対応する最小ブロック領域とが可能である。最小面積を有する符号化ブロックは、ハードウェアおよびソフトウェア実装の両方において、実装の実現可能性にとって有利である。ソフトウェア実装の場合、１６サンプルの最小領域は、ＡＶＸ－２およびＳＳＥ４などの典型的な単一命令多重データ（ＳＩＭＤ）命令セットと整列する。現在のＣＴＵの符号化ツリーのルートノードで最初に呼び出される方法１３００は、分割モードを符号化するステップ１３１０で開始する。
分割モードを符号化するステップ１３１０において、エントロピーエンコーダ３３８は、プロセッサ２０５の実行下で、符号化ツリーの現在のノードにおける分割モードをビットストリーム１１５に符号化する。分割モードは図５を参照して説明したように分割の１つであり、分割モードを符号化するステップは、可能な分割の符号化のみを可能にする。例えば、四分木分割５１２は、符号化ツリーのルートノードにおいて、または符号化ツリー内の他の四分木分割の下においてのみ可能である。セット９１０に関連して示されるように、４サンプル未満の幅または高さを有するルマＣＢをもたらす分割は禁止される。例えば、規則セット１０１０に基づいて、２分割および／または３分割の最大深さに関する他の制約も有効であり得る。プロセッサ２０５における制御は、ステップ１３１０から分割無しテストステップ１３２０に進む。
分割無しテストステップ１３２０で、プロセッサ２０５は、現在の分割が「分割無し」（すなわち、５１０）であるかどうかをテストする。現在の分割が分割無し５１０である場合（ステップ１３２０で「ＹＥＳ」）、プロセッサ２０５の制御はステップ１３２０からＣＵを符号化するステップ１３３０に進む。そうでなく、現在の分割が５１０でない場合（ステップ１３２０で「ＮＯ」）、プロセッサ２０５の制御はクロマ分割禁止テストステップ１３４０に進む。
ＣＵを符号化するステップ１３３０において、エントロピーエンコーダ３３８は、プロセッサ２０５の実行下で、ＣＵの予測モードおよびＣＵの残差をビットストリーム１１５に符号化する。ステップ１３３０が符号化ツリーの各リーフノードで到達すると、方法１３００は完了ステップ１３３０で終了し、符号化ツリートラバースにおける親呼び出しに戻る。符号化ツリーのすべてのノードがトラバースされると、ＣＴＵ全体がビットストリーム１１５に符号化され、制御は方法１１００に戻り、画像フレーム内の次のＣＴＵに進む。
クロマ分割禁止テストステップ１３４０において、プロセッサ２０５は図１０のクロマ領域１０２０分割規則セットに従って、ステップ１３１０のように、符号化ツリー内の現在のノードに対する分割がクロマチャネルに適用されることを許可されているかどうかを判定する。符号化ツリー内の現在のノードが１２８個のルマサンプル（３２×４または４×３２または１６×８または８×１６）のルマ領域をカバーする場合、対応するクロマ領域（それぞれ１６×２、２×１６、８×４、４×８のクロマサンプル）内の３分割は、規則セット１０２０に示されるように禁止される。３分割が許可された場合、結果として得られるブロックサイズは禁止されたブロックサイズ（例えば、２×４または４×２）を含むことになる。符号化ツリー内の現在のノードが６４個のルマサンプルのルマ領域をカバーする場合、規則セット１０２０に示されるように、２分割、３分割、四分木分割は禁止される。６４個のルマサンプルのルマ領域に対して２分割、３分割、四分木分割を実施すると、禁止されたクロマブロックサイズ（２×２、２×４、４×２）になる。分割が禁止されていない場合（すなわち、分割がリスト１０７０の許可されたクロマ分割である場合）、ステップ１３４０は「ＮＯ」を返し、プロセッサ２０５の制御はステップ１３４０からルマおよびクロマ分割を実行するステップ１３５０に進む。そわない場合、分割が禁止されている場合（１３４０で「ＹＥＳ」）、プロセッサ２０５の制御はルマ分割を実行するステップ１３１００に進む。
ルマおよびクロマ分割を実行するステップ１３５０において、プロセッサ２０５は、分割を適用して、符号化ツリーの現在のノードに関連する現在の領域を、符号化ツリーのサブノードに関連するサブ領域に分割する。分割は、図５および図６の説明に従って適用される。プロセッサ２０５内の制御は、ステップ１３５０から領域を選択するステップ１３６０に進む。
領域を選択するステップ１３６０において、プロセッサは、ステップ１３５０から生じるサブ領域のうちの１つを選択する。サブ領域は、領域のＺ順スキャンに従って選択される。選択は、ステップ１３６０の後続の反復でサブ領域を通って進行する。プロセッサ２０５内の制御は、ステップ１３６０から符号化ツリーを符号化するステップ１３７０に進む。
符号化ツリーを符号化するステップ１３７０において、プロセッサ２０５は、ステップ１３６０の結果として生じる選択された領域に対して、方法１３００を再帰的に起動する。ステップ１３７０はさらに、ビットストリームの各領域について、ルマおよびクロマブロック、ならびに関連する予測モードおよび残差係数を符号化するように動作する。プロセッサ２０５における制御は、ステップ１３７０から最後の領域テストステップ１３８０に進む。
最後の領域テストステップ１３８０において、プロセッサ２０５は、ステップ１３６０で選択された選択領域がステップ１３５０で実行されるように、分割モード分割から得られた領域の最後の１つかどうかをテストする。領域が最後の領域でない場合（ステップ１３８０で「ＮＯ」）、プロセッサ２０５における制御はステップ１３８０からステップ１３６０に進み、分割の領域を進み続け、そわない場合、ステップ１３８０は「ＹＥＳ」を返し、方法１３００は終了し、プロセッサ２０５における制御は、方法１３００の親呼び出しに進む。
ルマ分割を実行するステップ１３１００では、ステップ１３１０で符号化されたような分割モードがプロセッサ２０５のみによってルマチャネルで実行される。その結果、符号化ツリーの現在のノードは、分割モードに従って複数のルマＣＢに分割される。クロマＣＢのペア、すなわち、クロマチャネル当たり１つのクロマＣＢのみが生成される。結果として得られる各ルマＣＢは、クロマＣＢのペアと集合的に結果として得られるルマＣＢとに部分的に重なる（並置される）。集合ルマＣＢは、クロマＣＢのペアの領域を正確にカバーする。クロマＣＢのペアの領域と。また、各ルマＣＢ及びクロマＣＢの最小面積は、最小サイズ、例えば１６サンプルである。
ステップ１３１００および１３５０はそれぞれ、クロマチャネルＣｂおよびＣｒのためのクロマ符号化ブロックのサイズを決定するように動作する。ステップ１３５０では、ステップ１３１０で決定された分割モードに基づいて、クロマチャネルのクロマ符号化ブロックサイズが決定される。ステップ１３１００において、クロマチャネルのクロマ符号化ブロックサイズは、所定の最小クロマブロックサイズに基づいて決定される。上述したように、ステップ１３５０は、符号化ツリーユニットに対して禁止されているクロマ分割に基づいて実施される。図１０の規則セット１０２０に示されるように、許容可能な分割、したがってクロマ符号化ブロックのサイズは、ステップ１１０５で判定されたクロマフォーマットに基づいて決定される。
プロセッサ２０５内の制御は、ステップ１３１００からルマＣＢを選択するステップ１３１１０に進む。
ルマＣＢを選択するステップ１３１１０において、プロセッサ２０５は、ステップ１３１００から得られたＣＢの次のルマＣＢを選択する。方法１３１００は最初に、第１のＣＢ、すなわち、ルマ分割から生じるＣＢの左上ルマＣＢを選択する。ステップ１３１１０の後続の起動時に、各「次の」ルマＣＢは、ステップ１３１００から得られるルマＣＢに渡るＺオーダスキャンに従って選択される。プロセッサ２０５における制御は、ステップ１３１１０からルマＣＢを符号化するステップ１３１２０に進む。
ルマＣＢを符号化するステップ１３１２０において、エントロピーエンコーダ３３８は、プロセッサ２０５の実行下で、選択されたルマＣＢをビットストリーム１１５に符号化する。一般的に、予測モードと残差係数は、選択されたルマＣＢに対して符号化される。ルマＣＢのために符号化された予測モードは、インター予測またはイントラ予測を使用することができる。例えば、「ｃｕ＿ｓｋｉｐ＿ｆｌａｇ」は残差なしでのインター予測の使用を示すために符号化され、さもなければ、「ｐｒｅｄ＿ｍｏｄｅ＿ｆｌａｇ」および任意選択で「ｐｒｅｄ＿ｍｏｄｅ＿ｉｂｃ＿ｆｌａｇ」は、それぞれ任意選択の残差係数をもつイントラ予測、インター予測、またはブロック内コピーの使用を示すために符号化される。残差が存在してもよい場合、「ｃｕ＿ｃｂｆ」フラグはＣＢの任意のＴＢにおける少なくとも１つの有意な（非ゼロの）残差係数の存在を示す。ＣＢがインター予測を使用するように指示される場合、関連する動きベクトルは、ルマＣＢのみに適用可能である。すなわち、動きベクトルは、部分的に並置されたクロマＣＢに関連するＰＢを生成するためにも適用されない。ＣＢがブロック内コピーを使用するように指示されると、関連するブロックベクトルは、ルマＣＢのみに関連付けられ、部分的に並置されたクロマＣＢには関連付けられない。プロセッサ２０５における制御は、ステップ１３１２０から最後のルマＣＢテストステップ１３１３０に進む。
最後のルマＣＢテストステップ１３１３０で、プロセッサ２０５は、ステップ１３１１０で選択されたルマＣＢがステップ１３１００で実行された分割のルマＣＢのＺ順反復に従って最後のルマＣＢであるかどうかをテストする。選択されたルマＣＢが最後のものでない場合（ステップ１３１３０で「ＮＯ」）、プロセッサ２０５の制御はステップ１３１３０からステップ１３１２０に進む。そわない場合、ステップ１３１３０は「ＹＥＳ」に戻り、プロセッサ２０５の制御は、クロマイントラ予測モードを決定するステップ１３１４０に進む。
クロマイントラ予測モードを決定する１３１４０では、ビデオエンコーダ１１４がプロセッサ２０５の実行下で、ステップ１３１００のルマＣＢと一緒に配置されたクロマＣＢのペアに対するイントラ予測モードを決定する。ステップ１３１４０は、イントラ予測を使用してクロマブロックが符号化されることを効果的に決定する。クロマＣＢによって占有される領域が、ルマチャネルにおいて複数のルマＣＢにさらに分割されるかどうかの判定が行われる。チャネルに対するクロマブロックのサイズは、ステップ１３５０の動作によって決定される所定の最小値（例えば１６サンプル）である。ステップ１３１２０において、対応するルマＣＢがインター予測を使用して符号化された場合であっても、クロマＣＢのペアに対するイントラ予測モードが決定される。１つの構成では、ＤＣイントラ予測のような単一の予測モードが各クロマＣＢに適用される。単一予測モードの使用は、クロマ分割の禁止によってモードが決定されることを可能にし（ステップ１３４０における「ＹＥＳ」の結果）、複数の可能なモードのうちのどの１つのモードが使用されるべきかを決定するための追加の探索を必要としない。さらに、ビットストリーム１１５はこの場合、追加のシグナリングを必要としない、すなわち、追加の「ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅ」シンタックス要素を符号化する必要がない。しかし、構成はクロマ分割が禁止されているとき（ステップ１３４０で「ＹＥＳ」）、ビットストリーム１１５に「ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅ」シンタックス要素を含めることによって、いくつかの可能なイントラ予測モードのうちの１つのイントラ予測モードをシグナリングすることによって、より高い圧縮性能を達成することができる。ビデオエンコーダ１１４は、どのイントラ予測モードを使用するかを決定する。イントラ予測モードは、一般に歪みと比較して符号化コストの考慮に従って決定される。しかしながら、一般に、このようなクロマＣＢに対して単一のイントラ予測モードを使用する場合と比較して、より高い圧縮性能が得られる。プロセッサ２０５における制御は、ステップ１３１４０からクロマＣＢを符号化するステップ１３１５０に進む。
クロマＣＢを符号化するステップ１３１５０において、エントロピーエンコーダ３３８はプロセッサ２０５の実行下で、複数のイントラ予測モードが使用可能であるときに、「ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅ」シンタックス要素を使用して、クロマＣＢのイントラ予測モードをビットストリーム１１５に符号化する。１つのイントラ予測モード、例えばＤＣイントラ予測が可能であるとき、「ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅ」は、ビットストリーム１１５に符号化されない。クロマイントラ予測のための利用可能なイントラ予測モードがＤＣ、平面、および以下の角度予測モードを含むことができる：水平、垂直、上右対角。利用可能なイントラ予測モードは「ダイレクトモード」（ＤＭ＿ＣＨＲＯＭＡ）も含むことができ、それによって、クロマイントラ予測モードは、共配置されたルマＣＢから、一般的にステップ１３１００から結果として生じるルマＣＢの最下位および最右から、取得される。「クロス構成要素線形モデル」イントラ予測が利用可能である場合、クロマＣＢは、ルマＣＢからのサンプルから予測され得る。図１４のステップ１４１５０を参照して説明したように、クロマＣＢに関連付けられたクロマＴＢの残差係数も、ビットストリーム１１５に符号化され得る。ステップ１３１５０がプロセッサ２０５によって実行されると、方法１３００が終了し、プロセッサ２０５内の制御が方法１３００の親呼び出しに戻る。
図１４は、方法１２００のステップ１２２０で実施される、ビデオビットストリームから画像フレームの符号化ツリーを復号する方法１４００を示す。方法１４００は、構成されたＦＰＧＡ、ＡＳＩＣ、またはＡＳＳＰなどの装置によって実施され得る。さらに、方法１４００は、プロセッサ２０５の実行下でビデオデコーダ１３４によって実行されてもよい。そのようなものとして、方法１４００は、コンピュータ可読記憶媒体および／またはメモリ２０６に記憶することができる。方法１４００は、各ブロックがハードウェアの場合とソフトウェアの場合の両方で、実装の実現可能性にとって有利である１６サンプルなどの最小面積よりも小さくないように、ビットストリーム１３３からブロックを復号することになる。ソフトウェアの場合、１６サンプルの最小領域は、ＡＶＸ－２及びＳＳＥ４のような典型的な単一命令多重データ（ＳＩＭＤ）命令セットと整列する。現在のＣＴＵの符号化ツリーのルートノードで最初に起動される方法１４００は、分割モードを復号するステップ１４１０で開始する。
分割モードを復号するステップ１４１０において、エントロピーデコーダ４２０は、プロセッサ２０５の実行下で、符号化ツリーの現在のノードにおける分割モードをビットストリーム１３３に復号する。分割モードは、図５を参照して説明したように分割のうちの１つであり、分割モードを符号化する方法は、クロマチャネルにおいて分割が禁止されている場合であっても許可される、すなわち、ルマチャネルにおいて許可される分割の符号化のみを許可する。例えば、四分木分割５１２は、符号化ツリーのルートノードにおいて、または符号化ツリー内の他の四分木分割の下においてのみ可能である。４サンプル未満の幅または高さを有するルマＣＢをもたらす分割は禁止される。したがって、最小ルマＣＢサイズは１６サンプルである。２分割および／または３分割の最大深さに関する他の制約もまた、有効であり得る。プロセッサ２０５における制御は、ステップ１４１０から分割無しテストステップ１４２０に進む。
分割無しテストステップ１４２０において、プロセッサ２０５は現在の分割が「分割無し」（すなわち、５１０）であるかどうかをテストする。現在の分割が分割無し５１０である場合（１４２０で「ＹＥＳ」）、プロセッサ２０５の制御はステップ１４２０からＣＵを復号するステップ１４３０に進む。そわない場合、ステップ１４２０は「ＮＯ」を返し、プロセッサ２０５の制御はクロマ分割禁止テストステップ１４４０に進む。
ＣＵを復号するステップ１４３０において、エントロピーデコーダ４２０は、プロセッサ２０５の実行下で、ＣＵの予測モード及びビットストリーム１１５のＣＵの残差係数を復号する。ステップ１４３０は、エントロピーデコーダ４２０によってビットストリームから決定された残差係数および予測モードを使用して、符号化ユニットを復号するように動作する。ステップ１４３０が符号化ツリーの各リーフノードで到達すると、方法１４００はステップ１４３０が完了すると終了し、符号化ツリー探索における親呼び出しに戻る。符号化ツリーのすべてのノードがトラバースされると、ＣＴＵ全体がビットストリーム１３３から復号され、制御は方法１２００に戻り、画像フレーム内の次のＣＴＵに進む。
クロマ分割禁止テストステップ１４４０において、プロセッサ２０５は図１０のクロマ領域１０２０分割規則セットに従って、ステップ１４１０のように、符号化ツリー内の現在のノードに対する分割がクロマチャネルに適用されることを許可されているかどうかを判定する。ステップ１４４０は、方法１３００のステップ１３４０と同様に、分割テストが禁止されているかどうかを判定する。ステップ１４４０の動作は、禁止ブロックサイズの発生を防止する。クロマ領域が既に最小サイズ、例えば１６のクロマサンプルにある場合、結果として得られる領域が許容最小値よりも小さいので、任意のタイプのさらなる分割は許容されない。クロマ領域サイズが３２サンプルであり、対応する分割が（水平または垂直３分割であるかにかかわらず）３分割である場合、領域８クロマサンプルのクロマブロックを回避するために、さらなる分割も許可されない。分割が禁止されていない場合（すなわち、分割が許可されている場合）、ステップ１４５０は「ＮＯ」を返し、プロセッサ２０５の制御はステップ１４４０からルマおよびクロマ分割を実行するステップ１４５０に進む。そわない場合、分割が禁止されている場合（ステップ１４５０で「ＹＥＳ」）、プロセッサ２０５の制御はクロマイントラ予測モードを決定するステップ１４１００に進む。
ルマおよびクロマ分割を実行するステップ１４５０において、プロセッサ２０５は、分割を適用して、符号化ツリーの現在のノードに関連する現在の領域を、符号化ツリーのサブノードに関連するサブ領域に分割する。分割は、図５および図６に関連して説明したように適用される。
ステップ１４１００および１４５０はそれぞれ、クロマチャネルＣｂおよびＣｒのためのクロマ符号化ブロックのサイズを決定するように動作する。ステップ１４５０では、ステップ１４１０で復号された分割モードに基づいて、クロマチャネルのクロマ符号化ブロックサイズが決定される。ステップ１４１００において、クロマチャネルのクロマ符号化ブロックサイズは、所定の最小クロマブロックサイズに基づいて決定される。上述のように、ステップ１４５０は、１６の最小クロマＣＢサイズ（およびルマ領域１２８サンプルの３分割の場合には３２）に対応する、符号化ツリーユニットに対して禁止されているクロマ分割に基づいて実施される。図１０の規則セット１０２０に示されるように、許容可能な分割、したがってクロマ符号化ブロックのサイズは、ステップ１２０５で判定されたクロマフォーマットに基づいて決定される。
プロセッサ２０５内の制御は、ステップ１４５０から領域選択ステップ１４６０に進む。
領域選択ステップ１４６０において、プロセッサ２０５は、領域のＺオーダスキャンに従って、ステップ１４５０から生じるサブ領域の１つを選択する。ステップ１４６０は、後続の反復でサブ領域を通る進行選択を操作する。プロセッサ２０５内の制御は、ステップ１４６０から符号化ツリーを復号するステップ１４７０に進む。
符号化ツリーを復号するステップ１４７０において、プロセッサ２０５は、ステップ１４６０の動作の結果として生じる選択された領域に対して、方法１４００を再帰的に起動する。ステップ１４７０はさらに、ビットストリームから決定された残差係数および予測モードを使用して、符号化ツリーの各領域を復号するように動作する。プロセッサ２０５における制御は、ステップ１４７０から最後の領域テストステップ１４８０に進む。
最後の領域テストステップ１４８０で、プロセッサ２０５は、ステップ１４６０の最後の反復で事前選択されたように、選択された領域が、ステップ１４５０で実施された分割モード分割から生じる領域の最後の１つかどうかをテストする。領域が最後の領域でない場合（ステップ１４８０で「ＮＯ」）、プロセッサ２０５の制御は、ステップ１４８０からステップ１４６０に進み、分割の領域を進み続ける。そわない場合、ステップ１４８０は「ＹＥＳ」を返し、方法１４００は終了し、プロセッサ２０５の制御は方法１４００の親呼出しに進む。
ルマ分割を実行するステップ１４１００では、ステップ１４１０で符号化されたような分割モードがプロセッサ２０５のみによってルマチャネルで実行される。その結果、符号化ツリーの現在のノードは、分割モードに従って複数のルマＣＢに分割される。ステップ１４１００は、クロマＣＢのペア、すなわち、クロマチャネル当たり１つのクロマＣＢのみを生成するように動作する。結果として得られる各ルマＣＢは、クロマＣＢのペアと部分的に重なり（少なくとも部分的に一緒に配置され）、集合的に、ルマＣＢは、クロマＣＢのペアと完全に重なる。また、各ルマＣＢおよびクロマＣＢの最小面積は１６サンプルである。プロセッサ２０５内の制御は、ステップ１４１００からルマＣＢを選択するステップ１４１１０に進む。
ルマＣＢを選択するステップ１４１１０において、プロセッサ２０５は、ステップ１４１００から得られたＣＢの次のルマＣＢを選択する。次のルマＣＢの選択は、第１のＣＢ、すなわちルマ分割から生じるＣＢの左上のルマＣＢから開始する。ステップ１４１１０の後続の呼び出し時に、各「次の」ルマＣＢが、ステップ１４１００から得られるルマＣＢにわたるＺオーダースキャンに従って選択される。プロセッサ２０５内の制御は、ステップ１４１１０からルマＣＢを復号するステップ１４１２０に進む。
ルマＣＢを復号するステップ１４１２０において、エントロピーデコーダ４２０は、プロセッサ２０５の実行下で、選択されたルマＣＢをビットストリーム１１５に復号する。一般に、予測モードおよび残差は、選択されたルマＣＢについて復号される。例えば、「ｃｕ＿ｓｋｉｐ＿ｆｌａｇ」は残差なしでのインター予測の使用を示すために復号され、さもなければ「ｐｒｅｄ＿ｍｏｄｅ＿ｆｌａｇ」および任意選択で「ｐｒｅｄ＿ｍｏｄｅ＿ｉｂｃ＿ｆｌａｇ」はそれぞれ任意選択の残差係数をもつイントラ予測、インター予測、またはブロック内コピーの使用を示すために復号される。残差が存在する可能性がある場合、「ｃｕ＿ｃｂｆ」フラグはＣＢの任意のＴＢにおける少なくとも１つの有意な（非ゼロの）残差係数の存在を示す。ＣＢがインター予測を使用するように指示される場合、関連する動きベクトルはルマＣＢのみに適用可能であり、すなわち、動きベクトルは、部分的に並置されたクロマＣＢに関連するＰＢを生成するためにも適用されない。ＣＢがブロック内コピーを使用するように指示されると、関連するブロックベクトルは、ルマＣＢのみに関連付けられ、部分的に並置されたクロマＣＢには関連付けられない。プロセッサ２０５における制御は、ステップ１４１２０から最後のルマＣＢをテストするステップ１４１３０に進む。
最後のルマＣＢをテストするステップ１４１３０で、プロセッサ２０５は、ステップ１４１１０で選択されたルマＣＢがステップ１４１００で実行された分割のルマＣＢのＺオーダー反復に従って最後のルマＣＢであるかどうかをテストする。選択されたルマＣＢが最後のものでない場合、プロセッサ２０５内の制御は、ステップ１４１３０からステップ１４１１０に進む。そわない場合には、プロセッサ２０５における制御は、クロマイントラ予測モードを決定するステップ１４１４０に進む。
クロマイントラ予測モードを決定する１４１４０では、ビデオデコーダ１３４が、プロセッサ２０５の実行下で、ステップ１４１００のルマＣＢと一緒に配置されたクロマＣＢのペアに対するイントラ予測モードを決定する。ステップ１４１４０は、ステップ１４４０の動作によって決定されるように、クロマブロックがルマのための符号化ツリーを分割することが行われている間にクロマのための符号化ツリーを分割することの停止の結果である場合、イントラ予測を使用してクロマブロックが符号化されており、したがって、イントラ予測を使用して復号されるべきであることを効果的に決定する。ステップ１４１２０において、対応するルマＣＢがインター予測を使用して復号された場合であっても、クロマＣＢのペアに対するイントラ予測モードが決定される。１つの構成では、ＤＣイントラ予測のような単一の予測モードが各クロマＣＢに適用される。単一予測モードの使用は、クロマ分割の禁止によってモードが決定されることを可能にし（ステップ１４４０における「ＹＥＳ」の結果）、複数の可能なモードのうちのどの１つのモードが使用されるべきかを決定するための追加の探索を必要としない。さらに、ビットストリーム１３４はこの場合、追加のシグナリングを必要とせず、すなわち、追加の「ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅ」シンタックス要素を符号化する必要がない。しかし、構成は、クロマ分割が禁止されているとき（ステップ１４４０で「ＹＥＳ」）、「ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅ」シンタックス要素をビットストリーム１３４に含めることによって、いくつかの可能なイントラ予測モードのうち１つのイントラ予測モードをシグナリングすることによって、より高い圧縮性能を達成することができる。ビデオデコーダ１３４は、エントロピーデコーダ４２０を使用して、ビットストリーム１３４から「ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅ」シンタックス要素を復号するために、使用されるイントラ予測モードを決定する必要がある。プロセッサ２０５における制御は、ステップ１４１４０からクロマＣＢを復号するステップ１４１５０に進む。
クロマＣＢを復号するステップ１４１５０において、エントロピーデコーダ４２０は、プロセッサ２０５の実行下で、一般に、復号された「ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅ」シンタックス要素に従って、ビットストリーム４２０からのクロマＣＢのイントラ予測モードを決定する。「ｉｎｔｒａ＿ｃｈｒｏｍａ＿ｐｒｅｄ＿ｍｏｄｅ」の復号は、複数のイントラ予測モードが利用可能な場合に実行される。１つのイントラ予測モード、例えばＤＣイントラ予測のみが利用可能である場合、モードは、ビットストリーム１３３から追加のシンタックス要素を復号することなく推論される。クロマイントラ予測のために利用可能なイントラ予測モードは、ＤＣ、平面、以下の角度予測モードを含み得る：水平、垂直、上右対角。利用可能なイントラ予測モードはまた、「直接モード」（ＤＭ＿ＣＨＲＯＭＡ）を含むことができ、それによって、クロマイントラ予測モードは、ステップ１４１００から結果として生じるルマＣＢの一般的に最下位および最右位で並置されたルマＣＢから取得される。「クロス構成要素線形モデル」イントラ予測が利用可能である場合、クロマＣＢは、ルマＣＢからのサンプルから予測され得る。クロマＣＢのペアについて、「ｃｕ＿ｃｂｆ」フラグは、クロマＣＢのペアのいずれか１つにおける少なくとも１つの有意な残差係数の存在をシグナリングする。少なくとも１つの有意な残差係数がクロマＣＢのペアのいずれか１つに存在する場合、「ｔｕ＿ｃｂｆ＿ｃｂ」および「ｔｕ＿ｃｂｆ＿ｃｒ」はそれぞれ、ＣｂおよびＣｒチャネルのクロマＣＢにおける少なくとも１つの有意な係数の存在をシグナリングする。少なくとも１つの有意な残差係数を有するクロマＣＢについて、シンタックス要素の「ｒｅｓｉｄｕａｌ＿ｃｏｄｉｎｇ」シーケンスがそれぞれのクロマＣＢの残差係数を決定するために復号される。残差符号化シンタックスは、後方対角スキャンに従って、最後の有意な係数位置から左上（「ＤＣ」）係数位置に変換ブロックをポピュレートする値のシーケンスとして残差係数を符号化する。後方対角スキャンは、一般にサイズ４×４であるが、サイズ２×２、２×４、２×８、８×２、４×２も可能な「サブブロック」（または「係数グループ」）のシーケンスとして変換ブロックのスキャンを実行する。各係数グループ内のスキャンは、後方対角方向にあり、１つのサブブロックから次のサブブロックへのスキャンも後方対角方向にある。ステップ１４１５０がプロセッサ２０５によって実行されると、方法１４００が終了し、プロセッサ２０５内の制御が方法１４００の親呼び出しに戻る。
方法１３００および１４００の符号化ツリーアプローチは、１６サンプルの最小ブロック領域が４：２：０クロマフォーマットビデオデータに対して維持され、ソフトウェアおよびハードウェアの両方における高スループット実装を容易にする。さらに、小さいＣＢサイズに対するルマＣＢに対するインター予測の制限は、動き補償されたクロマＣＢを生成するためにサンプルをフェッチをもする必要性を回避することによって、動き補償メモリ帯域幅に対するこの最悪の場合のメモリ帯域幅を低減する。特に、最小クロマＣＢサイズが２×２であり、クロマＣＢのサブサンプル補間のためのフィルタサポートを提供するために追加のサンプルが必要とされる場合、小さいブロックサイズのためにルマチャネルにおいてインター予測を実行するだけと比較して、メモリ帯域幅の実質的な増加が見られる。動き補償の符号化利得は、実質的にルマチャネル内に現れ、したがって、小さなブロックも動き補償されることから省略することは比較的わずかな符号化性能の影響のためにメモリ帯域幅の低減を達成する。さらに、メモリ帯域幅の低減は、４×４ルマＣＢに対して動き補償を実行し、結果として得られる符号化利得を達成する実現可能性に寄与する。
ビデオエンコーダ１１４およびビデオデコーダ１３４の１つの構成では、２つ以上のルマ分割が、符号化ツリーのクロマ分割が終了する点から符号化ツリー内で発生することができる。例えば、８×１６ルマ領域は、クロマチャネルにおいて分割されず、４×８クロマＣＢのペアをもたらす。ルマチャネルにおいて、８×１６ルマ領域は最初に、水平３分割で分割され、次に、結果として生じるルマＣＢのうちの１つがさらに分割される。例えば、結果として得られる８×４ルマＣＢは、２つの４×４ルマＣＢに垂直に２分割される。符号化ツリーのクロマ分割が終了する点から符号化ツリーにおいて２つ以上のルマ分割を有する構成は、クロマ分割禁止領域内のビデオエンコーダ１１４およびビデオデコーダ１３４のそれぞれにおける方法１３００および１４００を再起動し、後続の呼出しではそれ以上のクロマＣＢは必要とされないという修正を伴う。クロマＣＢのペアが作成される方法１３００および１４００の呼び出しでは、クロマ領域全体が作成されたクロマＣＢによってカバーされるので、方法１３００および１４００の再帰的呼び出しは追加のクロマＣＢを作成する必要がない。
図１５は、イントラ予測符号化ユニットの変換ブロック分割の集合１５００を示す。ルマＣＢは、同じサイズの１つのルマＴＢ（「ＩＳＰ＿ＮＯ＿ＳＰＬＩＴ」）に分割されてもよい。サイズ４×４のルマＣＢが１６サンプルの領域を有し、さらに分割されず、サイズ４×４の１つのルマＴＢにもなる。３２サンプルの領域を有するルマＣＢは、２つの区分に分割されてもよい。例えば、８×４ルマＣＢ１５１０は、水平に（「ＩＳＰ＿ＨＯＲ＿ＳＰＬＩＴ」）２つの８×２ルマＴＢ１５２０に分割されてもよいし、垂直に（「ＩＳＰ＿ＶＥＲ＿ＳＰＬＩＴ」）２つの４×４ルマＴＢ１５３０に分割されてもよい。ルマＣＢ１５１０が４×８ルマＣＢである場合、ブロックは１５２０において２つの４×４ルマＴＢに水平に、または１５３０において２つの２×８ルマＴＢに垂直に分割され得る。
６４サンプル以上の領域のルマＣＢは、４つの区分への１つの区分に分割される。幅Ｗおよび高さＨの、より大きい６４サンプルの領域を有するルマＣＢ１５５０は、サイズＷｘ（Ｈ／４）の４つのルマＴＢ１５６０に水平に分割されてもよく、または４つの（Ｗ／４）ｘＨルマＴＢに垂直に分割されてもよい。集合１５００に示すように、ルマＣＢを複数の区分に分割すると、ルマＴＢがますます小さくなる。イントラ予測は、各ルマＴＢについてＰＢを生成するために実行され、イントラ再構成プロセスは、１つの区分から次の区分へのルマＣＢ内で実行される。
図１６は、画像フレームの符号化ユニットをビデオビットストリーム１１５に符号化するための方法１６００を示す。方法１６００は、構成されたＦＰＧＡ、ＡＳＩＣ、またはＡＳＳＰなどの装置によって実施され得る。さらに、方法１６００は、プロセッサ２０５の実行下でビデオエンコーダ１１４によって実行され得る。そのようなものとして、方法１６００は、コンピュータ可読記憶媒体および／またはメモリ２０６に記憶することができる。方法１６００は、係数グループサイズが変換ブロックサイズのみに基づいて決定され、ルマチャネルとクロマチャネルとの間でさらに区別されないように、ブロックをビットストリーム１１５に符号化することになる。エントロピー符号化は、ビデオエンコーダ１１４におけるクリティカルフィードバックループであるので、係数グループサイズ決定に必要なメモリアクセスまたは演算を低減することが有利である。符号化ツリー内の各符号化ユニットに対して呼び出される、すなわち図１３のステップ１３３０で呼び出される方法１６００は、ｐｒｅｄ＿ｍｏｄｅを符号化するステップ１６１０で開始する。上述したように、ステップ１３３０は、ステップ１３２０が現在の分割が分割無し５１０であると判定した場合に実行される。
ｐｒｅｄ ｍｏｄｅを符号化するステップ１６１０において、エントロピーエンコーダ３３８は、プロセッサ２０５の実行下で、ＣＵの予測モードをビットストリーム１１５に符号化する。プロセッサ２０５における制御は、ステップ１６１０からイントラ予測テストステップ１６２０に進む。
イントラ予測テストステップ１６２０において、プロセッサ２０５は、ＣＵの予測モードをテストする。予測モードがイントラ予測である場合（ステップ１６２０で「ＹＥＳ」）、プロセッサ２０５の制御は、ステップ１６２０からイントラサブ分割モードを符号化するステップ１６５０に進む。さもなければ、予測モードがイントラ予測でない場合（ステップ１６２０で「Ｎｏ」）、プロセッサ２０５の制御は、ステップ１６２０からマージフラグおよびインデックスを符号化するステップ１６３０に進む。
マージフラグおよびインデックスを符号化するステップ１６３０において、エントロピーエンコーダ３３８は、プロセッサ２０５の実行下で、インター予測のための「マージモード」の使用（または使用しない）をシグナリングするマージフラグをビットストリーム１１５に符号化する。マージモードはＣＵの動きベクトルを、空間的に（または時間的に）隣接するブロックの候補のセットのうち、空間的に（または時間的に）隣接するブロックから取得させる。マージモードが使用されている場合、対応する「マージインデックス」で１つの候補が選択される。マージインデックスは、マージフラグと共にビットストリーム１１５内に符号化される。「動きベクトル予測」が使用される場合、同様の符号化が実行され、それによって、いくつかの可能な候補動きベクトルのうちの１つが、フラグを使用して予測子としてシグナリングされる。プロセッサ２０５における制御は、ステップ１６３０から動きベクトルデルタを符号化するステップ１６４０に進む。
動きベクトルデルタを符号化するステップ１６４０において、エントロピーエンコーダ３３８は、プロセッサ２０５の実行下で、動きベクトルデルタをビットストリーム１１５に符号化する。ステップ１６４０は、動きベクトル予測がＣＵのために使用される場合に実行される。動きベクトルデルタは、ステップ１６３０で符号化された動きベクトル予測子と、動き補償に使用される動きベクトルと、の間のデルタを指定する。プロセッサ２０５における制御は、ステップ１６４０から符号化残差テストステップ１６６０に進む。動きベクトル予測がＣＵのために使用されない場合、ステップ１６４０は実施されず、方法１６００は直接ステップ１６６０に進む。
イントラサブ分割モードを符号化するステップ１６５０では、エントロピーエンコーダ３３８がプロセッサ２０５の実行下で、コンテキスト符号化「Ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｍｏｄｅ＿ｆｌａｇ」シンタックス要素を用いてイントラサブ分割をビットストリーム１１５に使用するかどうかの決定を符号化する。イントラサブ分割は、ルマＣＢサイズが最小ルマ変換ブロックサイズよりも大きい、すなわち１６ルマサンプルよりも大きいときに、ルマチャネルに利用可能である。イントラサブ分割は、集合１５００に示されるように、符号化ユニットを複数のルマ変換ブロックに分割する。ルマＣＢが複数のＴＢに分割される場合、「ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇ」は、ルマＣＢの複数のルマＴＢへの分割が水平方向または垂直方向に生じるかどうかをシグナリングする。集合的に、「ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｍｏｄｅ＿ｆｌａｇ」および「ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇ」は、「ＩＳＰ＿ＮＯ＿ＳＰＬＩＴ」、「ＩＳＰ＿ＨＯＲ＿ＳＰＬＩＴ」および「ＩＳＰ＿ＶＥＲ＿ＳＰＬＩＴ」として列挙される３つの可能な分割を符号化する。プロセッサ２０５における制御は、ステップ１６５０から符号化残差テストステップ１６６０に進む。
符号化残差テストステップ１６６０において、プロセッサ２０５は、符号化ブロックの任意の変換ブロック内の少なくとも１つの残差係数が有意であるかどうかを判定する。この判定は、イントラサブ分割の適用から生じるすべてのルマＴＢと、２つのクロマチャネルに関連するクロマＴＢのペアとを含む。ルマＴＢおよびクロマＴＢのいずれかにおける少なくとも１つの残差係数が有意である場合、エントロピーエンコーダ３３８は、プロセッサ２０５の実行下で、「ｃｕ＿ｃｂｆ」シンタックス要素について「１」を算術的に符号化し、ステップ１６６０は「ＹＥＳ」を返し、プロセッサ２０５はルマ係数グループサイズを決定するステップ１６７０に進む。有意な残差係数がＣＵのいずれのＴＢにも存在しない場合、ステップ１６６０は「ＮＯ」を返し、「０」がｃｕ＿ｃｂｆについて算術的に符号化され、方法１６００は終了し、プロセッサ２０５は、ＣＴＵ内の次のＣＵに進む。
ルマ係数グループサイズを決定するステップ１６７０において、プロセッサは、ＣＵに関連する１つまたは複数のルマＴＢ（変換ブロック）の係数グループサイズを決定する。イントラサブ分割が使用されていない場合、１つのルマＴＢが存在する。イントラサブ分割が使用されている場合は、２つまたは４つのルマＴＢがある。ルマＴＢのサイズは水平または垂直に実行されているイントラサブ分割、およびルマＴＢの数に依存し、したがって、集合１５００に示すように、ルマＣＵサイズに依存する。
係数グループサイズは以下のテーブル１に示すように、ルマＴＢ幅および高さを使用して決定される。テーブル１は、ＴＢがルマチャネルまたはクロマチャネルに対するものであるかにかかわらず、ＴＢに対して同じサイズの係数グループを有するルマチャネルおよびクロマチャネルに対する係数グループマッピングテーブルに対する変換ブロック（ＴＢ）サイズを示す。ＴＢ幅および高さは２の累乗であり、したがって、テーブル１は、ＴＢ幅および高さのｌｏｇ２、すなわち「ｌｏｇ２ＴＢｗｉｄｔｈ」および「ｌｏｇ２ＴＢｈｅｉｇｈｔ」がテーブル１の３次元への最初の２つのインデックスを形成することを考慮する。テーブルの最終寸法は、係数グループの幅と高さを区別する。係数グループの寸法は、ｌｏｇ２幅およびｌｏｇ２高さとして記憶される。例えば、サイズ１６×１６のＴＢはテーブル１のインデックス（４，４）をもたらし、これは、４×４の係数グループサイズを示す（２，２）を返す。サイズ（２×３２）のＴＢはテーブル１のインデックス（１，５）をもたらし、これは、２×８の係数グループサイズを示す（１，３）を返す。ルマＴＢの最小面積は１６サンプルであるので、テーブル１においてｌｏｇ２ｗｉｄｔｈ＋ｌｏｇ２ｈｅｉｇｈｔが４未満の場合はアクセスされない。イントラサブ分割がＣＵのために使用される場合、各ルマＴＢは同じサイズを有し、したがって、ルマＴＢのための係数グループサイズ決定は、ＣＵのために１回実行される。
以下のテーブル２は、クロマと比較して、ルマが同じサイズＴＢについて異なる係数グループサイズを有するルマチャネルおよびクロマチャネルについて、変換ブロック（ＴＢ）サイズを係数グループサイズにマッピングすることを示す。テーブル２が使用される場合、追加の次元、すなわちルマとクロマとを区別することが必要とされ、表サイズはテーブル１と比較して２倍である。テーブル１に定義される係数グループサイズはＴＢ幅および高さ内に適合するが、面積が１６サンプルを超えない可能な最大サイズであるサイズをもたらす。テーブル１は係数グループサイズのセットを提供し、そこから係数グループサイズが選択される。幅対高さの選択された係数グループアスペクト比は、ＴＢ幅および高さの制約内で可能な限り１：１に近く保たれる。プロセッサ２０５内の制御は、ステップ１６７０からルマＴＢを符号化するステップ１６８０に進む。
ルマＴＢを符号化するステップ１６８０において、エントロピーエンコーダ３３８は、プロセッサ２０５の実行下で、ＣＵの１つまたは複数のルマＴＢの残差係数をビットストリーム１１５に符号化する。ステップ１６７０の決定された係数グループサイズは、各ルマＴＢに対して使用される。各ルマＴＢについて、ルマＴＢ内の少なくとも１つの有意係数の存在を示す符号化ブロックフラグがビットストリーム１１５に符号化される。ルマＴＢに少なくとも１つの有意係数が存在する場合、最後の有意位置がビットストリームに符号化される。最後の有意位置は、ＴＢのＤＣ（左上）係数から右下の係数に進むスキャン経路に沿った最後の有意係数として定義される。スキャン経路は、ＴＢを、それぞれ係数グループサイズとしてサイズ設定され、ＴＢの全体を占有する、オーバーラップしないサブブロックのアレイに分割する際の対角スキャンとして定義される。スキャン順序における１つのサブブロックから次のサブブロックへの進行もまた、対角スキャンに従う。エントロピーエンコーダ３３８は、左上の係数グループおよび最後の有意係数を含む係数グループ以外の各係数グループについて、「符号化サブブロックフラグ」を符号化する。符号化サブブロックフラグは、サブブロック内の少なくとも１つの有意残差係数の存在を示す。サブブロック内に有意残差係数がない場合、ＴＢ内の残差係数の対角スキャンは、そのサブブロックをスキップする。サブブロック内に少なくとも１つの有意残差係数がある場合、そのサブブロック内のすべての位置がスキャンされ、各残差係数の大きさが符号化され、各有意残差係数の符号が符号化される。プロセッサ２０５における制御は、ステップ１６８０からクロマ係数グループサイズを決定するステップ１６９０に進む。
クロマ係数グループサイズを決定するステップ１６９０において、プロセッサ２０５は、ＣＵに関連付けられたクロマ変換ブロックのペアについての係数グループサイズを決定する。ルマＣＢが複数のルマＴＢに分割されるか否かとは無関係に、各クロマチャネルに対する１つのクロマＣＢがＣＵに関連付けられる。係数グループサイズはテーブル１に示すように、クロマＴＢ幅及び高さを用いて決定される。ＴＢ幅および高さは２の累乗であり、したがって、テーブル１は、ＴＢ幅および高さのｌｏｇ２、すなわち「ｌｏｇ２ＴＢｗｉｄｔｈ」および「ｌｏｇ２ＴＢｈｅｉｇｈｔ」がテーブル１の３次元への最初の２つのインデックスを形成することを考慮する。テーブルの最終寸法は、係数グループの幅と高さを区別する。係数グループの寸法は、ｌｏｇ２幅およびｌｏｇ２高さとして記憶される。例えば、サイズ１６×１６のＴＢはテーブル１のインデックス（４，４）をもたらし、これは、４×４の係数グループサイズを示す（２，２）を返す。サイズ（２×３２）のＴＢはテーブル１のインデックス（１，５）をもたらし、これは、２×８の係数グループサイズを示す（１，３）を返す。各クロマＴＢは同じサイズを有するので、クロマＴＢのペアに対する係数グループサイズ決定はＣＵに対して１回実行される。テーブル２が使用される場合、追加の寸法、すなわちルマとクロマとを区別する次元が必要とされ、テーブルサイズはテーブル１のそれと比較して２倍である。
ステップ１６７０および１６９０に関連して説明したように、係数グループサイズは、変換ブロックサイズのみに基づいて決定され、ルマチャネルとクロマチャネルとの間でさらに区別されることはない。したがって、係数グループサイズは、クロマフォーマットが４：２：２であるか４：２：０であるかに関係なく決定される。テーブル１に関連して説明したように、係数グループサイズは、１６サンプルまでの係数グループの最大領域に基づく。ステップ１６９０はクロマフォーマットに起因して、色プレーン（ＣｂおよびＣｒチャネルに適用可能）における変換ブロックまたはサブサンプリングの色プレーン（ＹまたはＣｂまたはＣｒ）とは無関係に、ＴＢに対する係数グループサイズを決定するために動作する。テーブル１は、ステップ１６７０およびステップ１６９０の両方で使用される。従って、ルマ面に属する変換ブロックと、クロマカラー面の各々に対して、単一のテーブルが使用される。プロセッサ２０５における制御は、ステップ１６９０からクロマＴＢを符号化するステップ１６１００に進む。
クロマＴＢを符号化するステップ１６１００において、エントロピーエンコーダ３３８は、プロセッサ２０５の実行下で、ＣＵのクロマＴＢのペアの残差係数をビットストリーム１１５に符号化する。ステップ１６９０の決定された係数グループサイズは、クロマＴＢのペアに対して使用される。各クロマＴＢについて、クロマＴＢにおける少なくとも１つの有意係数の存在を示す符号化ブロックフラグはビットストリーム１１５に符号化される。各クロマＴＢに対する符号化ステップの残りは、ステップ１６８０を参照して説明したように、ルマＴＢに対する符号化プロセスに一致する。方法１６００はステップ１６１００の実行時に終了し、プロセッサ２０５における制御は、ＣＴＵの次のＣＵに進む。
図１７は、ビデオビットストリーム１３３から画像フレームの符号化ユニットを復号する方法１７００を示す。方法１７００は、構成されたＦＰＧＡ、ＡＳＩＣ、またはＡＳＳＰなどの装置によって実施されてもよい。さらに、方法１７００は、プロセッサ２０５の実行下でビデオデコーダ１３４によって実行されてもよい。そのようなものとして、方法１７００は、コンピュータ可読記憶媒体および／またはメモリ２０６に記憶することができる。方法１７００は、係数グループサイズが変換ブロックサイズのみに基づいて決定され、ルマチャネルとクロマチャネルとの間でさらに区別されないように、ビットストリーム１３３からブロックを復号することになる。エントロピー復号は、ビデオエンコーダ１３４におけるクリティカルフィードバックループであるので、係数グループサイズ決定に必要なメモリアクセスまたは演算を低減することが有利である。方法１７００は、符号化ツリー内の各符号化ユニットについて呼び出され、すなわち、図１４のステップ１４３０で呼び出される。上述したように、ステップ１４３０は、現在の分割が分割無し５１０である場合に実行される。方法１７００は、ｐｒｅｄ＿ｍｏｄｅを復号するステップ１７１０で開始する。
ｐｒｅｄ＿ｍｏｄｅを復号するステップ１７１０において、エントロピーデコーダ４２０は、プロセッサ２０５の実行下で、ビットストリーム１３３からＣＵの予測モードを復号する。プロセッサ２０５における制御は、ステップ１７１０からイントラ予測テストステップ１７２０に進む。
イントラ予測テストステップ１７２０では、プロセッサ２０５がステップ１７１０で復号されたＣＵの予測モードをテストする。予測モードがイントラ予測である場合、ステップ１７２０は「ＹＥＳ」を返し、プロセッサ２０５における制御はステップ１７２０からイントラサブ分割モードを復号するステップ１７５０に進む。そわない場合、イントラ予測ではない場合、ステップ１７２０は「ＮＯ」を返し、プロセッサ２０５における制御は、ステップ１７２０からマージフラグおよびインデックスを復号するステップ１７３０に進む。
マージフラグおよびインデックスを復号するステップ１７３０において、エントロピーデコーダ４２０は、プロセッサ２０５の実行下で、ビットストリーム１３３から、「マージモード」がビットストリーム内でインター予測のために使用されているか否かをシグナリングするマージフラグを復号する。マージモードはＣＵの動きベクトルを、空間的または時間的に隣接する候補ブロックのセットのうち、空間的に（または時間的に）隣接するブロックから取得させる。マージモードが使用される場合、１つの候補が「マージインデックス」によって選択され、ビットストリーム１３３からも復号される。「動きベクトル予測」が使用される場合、同様の復号が実行され、それによって、いくつかの可能な候補動きベクトルのうちの１つが、ビットストリーム内のフラグによって予測子としてシグナリングされる。プロセッサ２０５における制御は、ステップ１７３０から動きベクトルデルタを復号するステップ１７４０に進む。
動きベクトルデルタを復号するステップ１７４０において、エントロピーデコーダ４２０は、プロセッサ２０５の実行下で、ビットストリーム１３３から動きベクトルデルタを復号する。ステップ１７４０は、動きベクトル予測がＣＵのために使用される場合に実行される。動きベクトルデルタは、ステップ１７３０で符号化された動きベクトル予測子と、動き補償に使用される動きベクトルとの間のデルタを指定する。プロセッサ２０５における制御は、ステップ１７４０から符号化残差テストステップ１７６０に進む。動きベクトル予測がＣＵのために使用されない場合、ステップ１７４０は実施されず、プロセッサ２０５における制御は直接ステップ１７６０に進む。
イントラサブ分割モードを復号するステップ１７５０では、エントロピーデコーダ４２０が、プロセッサ２０５の実行下で、コンテキスト符号化された「ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｍｏｄｅ＿ｆｌａｇ」シンタックス要素を使用して、ビットストリーム１３３からイントラサブ分割を使用するかどうかの決定を復号する。ルマＣＢサイズが最小ルマ変換ブロックサイズ、すなわち１６ルマサンプルよりも大きいとき、イントラサブ分割はルマチャネルに対して利用可能である。集合１５００に示されるように、イントラサブ分割は、符号化ユニットを複数のルマ変換ブロックに分割する。ルマＣＢが複数のＴＢに分割される場合、「ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇ」は、ルマＣＢの複数のルマＴＢへの分割が水平にもしくは垂直に発生するか否かをシグナリングする。集合的に、「ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｍｏｄｅ＿ｆｌａｇ」と「ｉｎｔｒａ＿ｓｕｂｐａｒｔｉｔｉｏｎｓ＿ｓｐｌｉｔ＿ｆｌａｇ」は、「ＩＳＰ＿ＮＯ＿ＳＰＬＩＴ」、「ＩＳＰ＿ＨＯＲ＿ＳＰＬＩＴ」、および「ＩＳＰ＿ＶＥＲ＿ＳＰＬＩＴ」として列挙された３つの可能な分割を符号化する。プロセッサ２０５における制御は、ステップ１７５０から符号化残差テストステップ１７６０に進む。
符号化残差テストステップ１７６０において、プロセッサ２０５は、符号化ブロックの任意の変換ブロック内の少なくとも１つの残差係数が有意であるかどうかを判定する。この判定は、イントラサブ分割の適用から生じるすべてのルマＴＢと、２つのクロマチャネルに関連するクロマＴＢのペアとを含む。エントロピーエンコーダ４２０はプロセッサ２０５の実行下で、「ｃｕ＿ｃｂｆ」シンタックス要素を算術的に復号し、プロセッサ２０５は、ＣＵのいずれかのＴＢにおける少なくとも１つの残差係数が有意であるか否かを判定する。ルマＴＢおよびクロマＴＢのいずれかにおける少なくとも１つの残差係数が有意である場合、ステップ１７６０は「ＹＥＳ」を返し、プロセッサ２０５における制御は、ルマ係数グループサイズを決定するステップ１７７０に進む。ｃｕ＿ｃｂｆについて算術的に復号される「ゼロ」によって示されるように、ＣＵのいずれのＴＢにも有意な残差係数が存在しない場合、ステップ１７６０は「ｎｏ」を返し、方法１７００は終了し、プロセッサ２０５は、ＣＴＵ内の次のＣＵに進む。
ルマ係数グループサイズを決定するステップ１７７０において、プロセッサ２０５は、ＣＵに関連する１つまたは複数のルマ変換ブロックの係数グループサイズを判定する。ステップ１７７０の判定は、ステップ１６７０の判定と同様に動作する。プロセッサ２０５内の制御は、ステップ１７７０からルマＴＢを復号するステップ１７８０に進む。
ルマＴＢを復号するステップ１７８０において、エントロピーデコーダ４２０は、プロセッサ２０５の実行下で、ビットストリーム１３３からのＣＵの１つまたは複数のルマＴＢの残差係数を復号する。ステップ１７７０の判定された係数グループサイズは、各ルマＴＢに対して使用される。各ルマＴＢについて、ルマＴＢ内に少なくとも１つの有意係数が存在することを示す符号化ブロックフラグがビットストリーム１３３から復号される。ルマＴＢ内に少なくとも１つの有意係数が存在する場合、最後の有意位置がビットストリームから復号される。最後の有意位置は、ＴＢのＤＣ（左上）係数から右下の係数に進むスキャン経路に沿った最後の有意係数として定義される。スキャン経路は、ＴＢを、それぞれ係数グループサイズとしてサイズ設定され、ＴＢの全体を占有する、オーバーラップしないサブブロックのアレイに分割する際の対角スキャンとして定義される。スキャン順序における１つのサブブロックから次のサブブロックへの進行もまた、対角スキャンに従う。エントロピーエンコーダ３３８は、左上の係数グループおよび最後の有意係数を含む係数グループ以外の各係数グループについて、「符号化サブブロックフラグ」を符号化する。符号化されたサブブロックフラグは、サブブロック内の少なくとも１つの有意残差係数の存在を示す。サブブロック内に有意残差係数がない場合、ＴＢ内の残差係数の対角スキャンは、そのサブブロックをスキップする。サブブロック内に少なくとも１つの有意残差係数がある場合、そのサブブロック内のすべての位置がスキャンされ、各残差係数の大きさが符号化され、各有意残差係数の符号が符号化される。プロセッサ２０５における制御は、ステップ１７８０から、クロマ係数グループサイズを決定するステップ１７９０に進む。
クロマ係数グループサイズを決定するステップ１７９０において、プロセッサ２０５は、ＣＵに関連付けられたクロマ変換ブロックのペアに対する係数グループサイズを判定する。ステップ１７９０で行われる判定は、ステップ１６９０で行われる判定と同じように動作する。
ステップ１６９０と同様に、係数グループサイズは、ステップ１７９０において、変換ブロックサイズに基づいて決定され、ルマチャネルとクロマチャネルとの間でさらに区別されない。したがって、係数グループサイズは、クロマフォーマットが４：２：２または４：２：０であるか、または各色プレーンにおける対応するサブサンプリングであるかに関係なく決定される。テーブル１に関連して説明したように、係数グループサイズは、１６サンプルまでであるＴＢの最大領域に基づく。ステップ１６９０は、変換ブロックの色平面（ＣｂまたはＣｒ）に関係なく、ＴＢの係数グループサイズを決定するように動作する。プロセッサ２０５内の制御は、ステップ１７９０からクロマＴＢを復号するステップ１７１００に進む。
クロマＴＢを復号するステップ１７１００において、エントロピーデコーダ４２０は、プロセッサ２０５の実行下で、ビットストリーム１３３からのＣＵのクロマＴＢのペアの残差係数を復号する。ステップ１７９０の決定された係数グループサイズは、クロマＴＢのペアに対して使用される。各クロマＴＢについて、クロマＴＢ内に少なくとも１つの有意係数が存在することを示す符号化ブロックフラグがビットストリーム１３３から復号される。各クロマＴＢに対する復号処理の残りの部分は、ステップ１７８０を参照して説明したように、ルマＴＢに対するのと同じ方法で動作する。方法１７００は、ステップ１７１００の実行時に終了し、プロセッサ２０５における制御は、ＣＴＵの次のＣＵに進む。
テーブル３はテーブル１を用いた場合に、JVET 「共通試験条件」(ＣＴＣ)－「All Intra Main １０」構成の下で得られた符号化性能結果を示す。テーブル３の結果は、方法１６００および１７００を実施しないベースラインＶＴＭ－４．０と比較して、方法１６００および１７００を実施する「ＶＶＣ試験モデル」（ＶＴＭ）ソフトウェアを用いて得られた。全体として、変化からの符号化の影響はなく、クロマチャネルに少しの利得さえ見られ、変換ブロックサイズから係数グループサイズへのマッピングテーブルを単純化することは、符号化性能に有害ではないことを実証する。
ビデオエンコーダ１１５およびビデオデコーダ１３４は、それぞれ方法１６００および１７００を使用して、ルマＴＢおよびクロマＴＢの係数グループサイズを調和させることによって、残差符号化／復号処理におけるメモリ削減を達成する。その結果、クロマＴＢは、２×８のような係数グループサイズにアクセスすることができる。２ｘ２と４ｘ４のみではなく、４ｘ２、２ｘ４、８ｘ２。ルマＴＢの場合、イントラサブ分割を使用すると、１６ｘ１と１ｘ１６のサイズが可能である。サイズ１６ｘ１および１ｘ１６はテーブル１におけるそれらの存在によってクロマに利用可能であるが、クロマブロックの最小幅および高さは２つのサンプルであり、したがって、サイズ１６ｘ１および１ｘ１６はクロマＴＢにおいて使用されない。残差符号化及び復号は、設計におけるフィードバックループの一部であるので、メモリ低減は例えば、ソフトウェア実装におけるキャッシュ性能又はハードウェア実装におけるクリティカルパス低減の改善に対応する。
uint32_t g_log2SbbSize[MAX_CU_DEPTH + 1][MAX_CU_DEPTH + 1][2] =
//===== ルマ／クロマ =====
{
{ { 0,0 },{ 0,1 },{ 0,2 },{ 0,3 },{ 0,4 },{ 0,4 },{ 0,4 },{ 0,4 } },
{ { 1,0 },{ 1,1 },{ 1,2 },{ 1,3 },{ 1,3 },{ 1,3 },{ 1,3 },{ 1,3 } },
{ { 2,0 },{ 2,1 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 } },
{ { 3,0 },{ 3,1 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 } },
{ { 4,0 },{ 3,1 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 } },
{ { 4,0 },{ 3,1 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 } },
{ { 4,0 },{ 3,1 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 } },
{ { 4,0 },{ 3,1 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 },{ 2,2 } }
};
テーブル１：（ＴＢがルマチャネルまたはクロマチャネルのためのものであるかにかかわらず、ＴＢのための同じサイズの係数グループを有する）ルマチャネルおよびクロマチャネルのための係数グループマッピングテーブルへのブロックサイズの変換
uint32_t g_log2SbbSize[2][MAX_CU_DEPTH+1][MAX_CU_DEPTH+1][2] =
{
//===== ルマ =====
{
{ {0,0}, {0,1}, {0,2}, {0,3}, {0,4}, {0,4}, {0,4}, {0,4} },
{ {1,0}, {1,1}, {1,2}, {1,3}, {1,3}, {1,3}, {1,3}, {1,3} },
{ {2,0}, {2,1}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2} },
{ {3,0}, {3,1}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2} },
{ {4,0}, {3,1}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2} },
{ {4,0}, {3,1}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2} },
{ {4,0}, {3,1}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2} },
{ {4,0}, {3,1}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2} }
},
//===== クロマ =====
{
{ {0,0}, {0,0}, {0,0}, {0,0}, {0,0}, {0,0}, {0,0}, {0,0} },
{ {0,0}, {1,1}, {1,1}, {1,1}, {1,1}, {1,1}, {1,1}, {1,1} },
{ {0,0}, {1,1}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2} },
{ {0,0}, {1,1}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2} },
{ {0,0}, {1,1}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2} },
{ {0,0}, {1,1}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2} },
{ {0,0}, {1,1}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2} },
{ {0,0}, {1,1}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2}, {2,2} }
},
};
テーブル２：変換ブロックサイズの、ルマチャネルおよびクロマチャネルの係数グループサイズへの従来のマッピング（ルマ対クロマの同じサイズのＴＢに対して異なる係数グループサイズを有する）
Figure 0007337163000001
テーブル３：ＴＢがルマチャネルまたはクロマチャネルに対するものであるかにかかわらず、ＴＢに対して同じサイズの係数グループを有することから生じる符号化性能。
産業上の利用可能性
記載される構成は、コンピュータ及びデータ処理産業に、特にビデオ及び画像信号のような信号の符号化、復号のためのディジタル信号処理に適用可能であり、高い圧縮効率を達成する。
ＨＥＶＣとは対照的に、ＶＶＣシステムは柔軟性を高めるために、ルマチャネルおよびクロマチャネルのための別個の符号化ツリーの使用を可能にする。しかしながら、上述したように、結果として生じる問題は、スループットに影響を及ぼすより小さなクロマブロックの使用により生じる可能性がある。本明細書で説明される構成は、各符号化ツリーユニットが処理されてスループット問題を回避するのを助けるときに、適切な規則を決定する。さらに、上述のように、上述の構成は、スループット問題を回避するための規則が与えられると、各符号化ツリーを記述するために使用されるコンテキスト符号化ビンの算術符号化の改善された効率および精度を提供することを支援することができる。
上記は本発明のいくつかの実施形態のみを記載し、本発明の範囲および精神から逸脱することなく、本発明に修正および／または変更を加えることができ、実施形態は例示的であり、限定的ではない。

Claims (2)

  1. ビットストリームから画像フレームの変換ブロックを復号する方法であって、
    ４：２：０クロマフォーマットと４：２：２クロマフォーマットを含む複数のクロマフォーマットから前記画像フレームのクロマフォーマットを決定することと、
    符号化ツリーユニットを、各々がルマ符号化ブロックとクロマ符号化ブロックとを有する一又は複数の符号化ユニットに分割することと、
    ルマ符号化ブロックについてのルマ変換ブロック、又は、クロマ符号化ブロックについてのクロマ変換ブロックである変換ブロックのサブブロックを決定することと、
    前記サブブロックを用いて前記変換ブロックを前記ビットストリームから復号することと、を有し、
    ４：２：０クロマフォーマットの前記符号化ツリーユニットにおけるルマ符号化ブロックとクロマ符号化ブロックとを有する或る符号化ユニットの前記クロマ符号化ブロックのブロックサイズが８ｘ２である場合、前記或る符号化ユニットの前記ルマ符号化ブロックに対する垂直ターナリ分割が行われた場合であっても、前記或る符号化ユニットの前記クロマ符号化ブロックに対する更なる垂直ターナリ分割は許可されず、
    前記或る符号化ユニットの前記ルマ符号化ブロックが垂直ターナリ分割され且つ前記或る符号化ユニットの前記クロマ符号化ブロックが垂直ターナリ分割されなかった場合、前記或る符号化ユニットの前記クロマ符号化ブロックは、前記或る符号化ユニットの前記ルマ符号化ブロックに対する垂直ターナリ分割により得られた３つのルマ符号化ブロックと対応する位置に配置され、
    前記変換ブロックは、（ｉ）前記変換ブロックのサイズと、（ｉｉ）前記変換ブロックがルマ変換ブロック又はクロマ変換ブロックのいずれであるかと、に基づき復号され、
    前記変換ブロックの前記サブブロックのサイズは、（ｉ）前記変換ブロックがルマ変換ブロック又はクロマ変換ブロックのいずれであるかと、（ｉｉ）前記画像フレームの前記クロマフォーマットと、の両方を用いず、前記変換ブロックのサイズから決定される
    ことを特徴とする方法。
  2. ビットストリームから画像フレームの変換ブロックを復号するビデオデコーダであって、
    ４：２：０クロマフォーマットと４：２：２クロマフォーマットを含む複数のクロマフォーマットから前記画像フレームのクロマフォーマットを決定する手段と、
    符号化ツリーユニットを、各々がルマ符号化ブロックとクロマ符号化ブロックとを有する一又は複数の符号化ユニットに分割する手段と、
    ルマ符号化ブロックについてのルマ変換ブロック、又は、クロマ符号化ブロックについてのクロマ変換ブロックである変換ブロックのサブブロックを決定する手段と、
    前記サブブロックを用いて前記変換ブロックを前記ビットストリームから復号する手段と、を有し、
    ４：２：０クロマフォーマットの前記符号化ツリーユニットにおけるルマ符号化ブロックとクロマ符号化ブロックとを有する或る符号化ユニットの前記クロマ符号化ブロックのブロックサイズが８ｘ２である場合、前記或る符号化ユニットの前記ルマ符号化ブロックに対する垂直ターナリ分割が行われた場合であっても、前記或る符号化ユニットの前記クロマ符号化ブロックに対する更なる垂直ターナリ分割は許可されず、
    前記或る符号化ユニットの前記ルマ符号化ブロックが垂直ターナリ分割され且つ前記或る符号化ユニットの前記クロマ符号化ブロックが垂直ターナリ分割されなかった場合、前記或る符号化ユニットの前記クロマ符号化ブロックは、前記或る符号化ユニットの前記ルマ符号化ブロックに対する垂直ターナリ分割により得られた３つのルマ符号化ブロックと対応する位置に配置され、
    前記変換ブロックは、（ｉ）前記変換ブロックのサイズと、（ｉｉ）前記変換ブロックがルマ変換ブロック又はクロマ変換ブロックのいずれであるかと、に基づき復号され、
    前記変換ブロックの前記サブブロックのサイズは、（ｉ）前記変換ブロックがルマ変換ブロック又はクロマ変換ブロックのいずれであるかと、（ｉｉ）前記画像フレームの前記クロマフォーマットと、の両方を用いず、前記変換ブロックのサイズから決定される
    ことを特徴とするビデオデコーダ。
JP2021531285A 2019-03-11 2020-01-20 ビデオサンプルのツリー若しくはブロックを符号化および復号する方法、装置、およびシステム Active JP7337163B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023132042A JP7549715B2 (ja) 2019-03-11 2023-08-14 ビデオサンプルのツリー若しくはブロックを符号化および復号する方法、装置、およびシステム

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
AU2019201653A AU2019201653A1 (en) 2019-03-11 2019-03-11 Method, apparatus and system for encoding and decoding a tree of blocks of video samples
AU2019201653 2019-03-11
PCT/AU2020/050028 WO2020181317A1 (en) 2019-03-11 2020-01-20 Method, apparatus and system for encoding and decoding a tree of blocks of video samples

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2023132042A Division JP7549715B2 (ja) 2019-03-11 2023-08-14 ビデオサンプルのツリー若しくはブロックを符号化および復号する方法、装置、およびシステム

Publications (2)

Publication Number Publication Date
JP2022522576A JP2022522576A (ja) 2022-04-20
JP7337163B2 true JP7337163B2 (ja) 2023-09-01

Family

ID=72425960

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2021531285A Active JP7337163B2 (ja) 2019-03-11 2020-01-20 ビデオサンプルのツリー若しくはブロックを符号化および復号する方法、装置、およびシステム
JP2023132042A Active JP7549715B2 (ja) 2019-03-11 2023-08-14 ビデオサンプルのツリー若しくはブロックを符号化および復号する方法、装置、およびシステム

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2023132042A Active JP7549715B2 (ja) 2019-03-11 2023-08-14 ビデオサンプルのツリー若しくはブロックを符号化および復号する方法、装置、およびシステム

Country Status (10)

Country Link
US (6) US12088822B2 (ja)
EP (1) EP3939277A4 (ja)
JP (2) JP7337163B2 (ja)
KR (1) KR20210100727A (ja)
CN (1) CN113574874B (ja)
AU (2) AU2019201653A1 (ja)
BR (1) BR112021013495A2 (ja)
RU (2) RU2022102866A (ja)
TW (2) TWI769432B (ja)
WO (1) WO2020181317A1 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7535068B2 (ja) * 2019-06-25 2024-08-15 フラウンホファー ゲセルシャフト ツール フェールデルンク ダー アンゲヴァンテン フォルシュンク エー．ファオ． イントラ下位区分のためのコーディングを含むデコーダ、エンコーダ、および方法
US20230262223A1 (en) * 2020-06-03 2023-08-17 Nokia Technologies Oy A Method, An Apparatus and a Computer Program Product for Video Encoding and Video Decoding
US11259055B2 (en) * 2020-07-10 2022-02-22 Tencent America LLC Extended maximum coding unit size
US20240137522A1 (en) * 2022-10-12 2024-04-25 City University Of Hong Kong Processing and encoding screen content video
WO2024137862A1 (en) * 2022-12-22 2024-06-27 Bytedance Inc. Method, apparatus, and medium for video processing

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013098988A (ja) 2011-11-01 2013-05-20 Research In Motion Ltd 符号化および復号のためのマルチレベル有効性写像
JP2018521552A (ja) 2015-05-29 2018-08-02 クアルコム，インコーポレイテッド 改善されたコンテキスト適応バイナリ算術コーティング（ｃａｂａｃ）設計を使用したデータのコーディング

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7630440B2 (en) 2003-05-28 2009-12-08 Broadcom Corporation Context adaptive binary arithmetic code decoding engine
CN103141103B (zh) 2010-04-09 2016-02-03 Lg电子株式会社 处理视频数据的方法和装置
JP5636507B2 (ja) 2011-01-07 2014-12-03 メディア テック シンガポール ピーティーイー．リミテッド 改良されたイントラ予測モード符号化の方法及び装置
WO2012176405A1 (ja) 2011-06-20 2012-12-27 株式会社Ｊｖｃケンウッド 画像符号化装置、画像符号化方法及び画像符号化プログラム、並びに画像復号装置、画像復号方法及び画像復号プログラム
US8964849B2 (en) 2011-11-01 2015-02-24 Blackberry Limited Multi-level significance maps for encoding and decoding
CA2773990C (en) 2011-11-19 2015-06-30 Research In Motion Limited Multi-level significance map scanning
US9363516B2 (en) 2012-01-19 2016-06-07 Qualcomm Incorporated Deblocking chroma data for video coding
US9185405B2 (en) 2012-03-23 2015-11-10 Qualcomm Incorporated Coded block flag inference in video coding
KR101749297B1 (ko) 2012-04-12 2017-06-21 미디어텍 싱가폴 피티이. 엘티디. 크로마 서브샘플링 포맷들의 블록 파티션을 위한 방법 및 장치
GB2501535A (en) 2012-04-26 2013-10-30 Sony Corp Chrominance Processing in High Efficiency Video Codecs
EP2866443A4 (en) 2012-06-22 2016-06-15 Sharp Kk ARITHMETIC DECODING DEVICE, ARITHMETIC CODING DEVICE, IMAGE DECODING DEVICE AND IMAGE DEVICES
US9426466B2 (en) 2012-06-22 2016-08-23 Qualcomm Incorporated Transform skip mode
JP6341426B2 (ja) * 2012-09-10 2018-06-13 サン パテント トラスト 画像復号化方法および画像復号化装置
US9538175B2 (en) 2012-09-26 2017-01-03 Qualcomm Incorporated Context derivation for context-adaptive, multi-level significance coding
AU2012232992A1 (en) * 2012-09-28 2014-04-17 Canon Kabushiki Kaisha Method, apparatus and system for encoding and decoding the transform units of a coding unit
AU2013200051B2 (en) 2013-01-04 2016-02-11 Canon Kabushiki Kaisha Method, apparatus and system for de-blocking video data
US10291934B2 (en) * 2013-10-02 2019-05-14 Arris Enterprises Llc Modified HEVC transform tree syntax
WO2016090568A1 (en) * 2014-12-10 2016-06-16 Mediatek Singapore Pte. Ltd. Binary tree block partitioning structure
WO2016205999A1 (en) * 2015-06-23 2016-12-29 Mediatek Singapore Pte. Ltd. Adaptive coding group for image/video coding
AU2015275320A1 (en) 2015-12-23 2017-07-13 Canon Kabushiki Kaisha Method, apparatus and system for determining a luma value
US10455228B2 (en) * 2016-03-21 2019-10-22 Qualcomm Incorporated Determining prediction parameters for non-square blocks in video coding
EP3453174A1 (en) 2016-05-06 2019-03-13 VID SCALE, Inc. Method and system for decoder-side intra mode derivation for block-based video coding
AU2016203181B2 (en) 2016-05-16 2018-09-06 Canon Kabushiki Kaisha Method, apparatus and system for determining a luma value
AU2018233042B2 (en) 2018-09-21 2024-06-13 Canon Kabushiki Kaisha Method, apparatus and system for encoding and decoding a tree of blocks of video samples

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013098988A (ja) 2011-11-01 2013-05-20 Research In Motion Ltd 符号化および復号のためのマルチレベル有効性写像
JP2018521552A (ja) 2015-05-29 2018-08-02 クアルコム，インコーポレイテッド 改善されたコンテキスト適応バイナリ算術コーティング（ｃａｂａｃ）設計を使用したデータのコーディング

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ROSEWARNE, C. et al.，AHG16-related: Chroma block coding and size restriction，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 13th Meeting: Marrakech, MA, 9-18 Jan. 2019, [JVET-M0245-v3]，JVET-M0245 (version 3)，ITU-T，2019年01月09日，＜URL:https://jvet-experts.org/doc_end_user/documents/13_Marrakech/wg11/JVET-M0245-v3.zip＞: JVET-M0245_r2.docx: pp.1-3
ROSEWARNE, C. et al.，CE7-related: Coefficient group size harmonisation，Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 14th Meeting: Geneva, CH, 19-27 March 2019, [JVET-N0103-v1]，JVET-N0103 (version 1)，ITU-T，2019年03月12日，＜URL:https://jvet-experts.org/doc_end_user/documents/14_Geneva/wg11/JVET-N0103-v1.zip＞: JVET-N0103.docx: pp.1-3
SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS Infrastructure of audiovisual services - Coding of moving video，Recommendation ITU-T H.265 (04/2013) High efficiency video coding，ITU-T，2013年06月07日，pp.19,50,66，＜URL:https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.265-201304-S!!PDF-E&type=items＞
ZHOU, Tianyang and IKAI, Tomohiro，Non-CE3: Intra chroma partitioning and prediction restriction，Joint Video Exploration Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 13th Meeting: Marrakesh, MA, 9-18 January 2019, [JVET-M0065]，JVET-M0065 (version 2)，ITU-T，2019年01月16日，＜URL:https://jvet-experts.org/doc_end_user/documents/13_Marrakech/wg11/JVET-M0065-v2.zip＞: JVET-M0065.doc: pp.1-4

Also Published As

Publication number Publication date
US12088822B2 (en) 2024-09-10
JP7549715B2 (ja) 2024-09-11
KR20210100727A (ko) 2021-08-17
CN113574874B (zh) 2024-08-30
US20240323393A1 (en) 2024-09-26
US20240323395A1 (en) 2024-09-26
TW202101981A (zh) 2021-01-01
AU2019201653A1 (en) 2020-10-01
US20240323392A1 (en) 2024-09-26
US20220150509A1 (en) 2022-05-12
WO2020181317A1 (en) 2020-09-17
EP3939277A4 (en) 2022-12-28
JP2022522576A (ja) 2022-04-20
BR112021013495A2 (pt) 2021-09-21
RU2022102866A (ru) 2022-03-03
CN113574874A (zh) 2021-10-29
AU2021254642B2 (en) 2023-09-28
TWI769432B (zh) 2022-07-01
US20240323394A1 (en) 2024-09-26
JP2023154047A (ja) 2023-10-18
TW202239204A (zh) 2022-10-01
AU2021254642A1 (en) 2021-11-18
RU2766881C1 (ru) 2022-03-16
EP3939277A1 (en) 2022-01-19
TWI788262B (zh) 2022-12-21
US20240323396A1 (en) 2024-09-26

Similar Documents

Publication Publication Date Title
JP7161619B2 (ja) ビデオサンプルのツリー若しくはブロックを符号化および復号する方法、装置、およびシステム
JP7337163B2 (ja) ビデオサンプルのツリー若しくはブロックを符号化および復号する方法、装置、およびシステム
JP7495923B2 (ja) ビデオサンプルの変換されたブロックを符号化および復号する方法、装置、およびシステム
JP7441314B2 (ja) ビデオサンプルのブロックを符号化および復号するための方法、装置、およびシステム
JP7391171B2 (ja) ビデオサンプルの変換されたブロックを符号化および復号する方法、装置、およびシステム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210730

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20220816

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220822

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221021

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230217

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230417

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230822

R151 Written notification of patent or utility model registration

Ref document number: 7337163

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151