JP7191195B2 - ビデオサンプルの変換されたブロックを符号化および復号する方法、装置、およびシステム - Google Patents

ビデオサンプルの変換されたブロックを符号化および復号する方法、装置、およびシステム Download PDF

Info

Publication number
JP7191195B2
JP7191195B2 JP2021501306A JP2021501306A JP7191195B2 JP 7191195 B2 JP7191195 B2 JP 7191195B2 JP 2021501306 A JP2021501306 A JP 2021501306A JP 2021501306 A JP2021501306 A JP 2021501306A JP 7191195 B2 JP7191195 B2 JP 7191195B2
Authority
JP
Japan
Prior art keywords
transform
unit
size
coding unit
coding
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
JP2021501306A
Other languages
English (en)
Other versions
JP2021536156A (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 JP2021536156A publication Critical patent/JP2021536156A/ja
Priority to JP2022188696A priority Critical patent/JP7391171B2/ja
Application granted granted Critical
Publication of JP7191195B2 publication Critical patent/JP7191195B2/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/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/436—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation using parallelised computational arrangements
    • 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/103—Selection of coding mode or of prediction mode
    • H04N19/109—Selection of coding mode or of prediction mode among a plurality of temporal predictive coding modes
    • 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/117—Filters, e.g. for pre-processing or post-processing
    • 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/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
    • 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/136—Incoming video signal characteristics or properties
    • H04N19/137—Motion inside a coding unit, e.g. average field, frame or block difference
    • H04N19/139—Analysis of motion vectors, e.g. their magnitude, direction, variance or reliability
    • 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
    • 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/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/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform 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/80—Details of filtering operations specially adapted for video compression, e.g. for pixel interpolation
    • H04N19/82—Details of filtering operations specially adapted for video compression, e.g. for pixel interpolation involving filtering within a prediction loop
    • 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/48—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using compressed domain processing techniques other than decoding, e.g. modification of transform coefficients, variable length coding [VLC] data or run-length data
    • 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/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/513—Processing of motion vectors
    • H04N19/521—Processing of motion vectors for estimating the reliability of the determined motion vectors or motion vector field, e.g. for smoothing the motion vector field or for correcting motion vectors
    • 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/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/56—Motion estimation with initialisation of the vector search, e.g. estimating a good candidate to initiate a search

Description

関連出願への参照
本出願は２０１８年８月１７日に出願されたオーストラリア特許出願第２０１８２１７３３６号の出願日の３５Ｕ．Ｓ．Ｃ§１１９に基づく利益を主張し、その全体が本明細書に完全に記載されているかのように参照により本明細書に組み込まれる。
本発明は一般に、デジタルビデオ信号処理に関し、特に、ビデオサンプルの変換されたブロックを符号化及び復号するための方法、装置及びシステムに関する。
本発明はまた、ビデオサンプルの変換されたブロックを符号化および復号するためのコンピュータプログラムが記録されたコンピュータ可読媒体を含むコンピュータプログラム製品に関する。
ビデオデータの送信及び記憶のためのアプリケーションを含む、ビデオ符号化のための多くのアプリケーションが現在存在する。多くのビデオ符号化規格も開発されており、他の規格も現在開発中である。ビデオ符号化標準化における最近の開発は、「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）が必要である。一次色チャネルは一般に「輝度」チャネルと呼ばれ、二次色チャネルは一般に「彩度」チャネルと呼ばれる。ビデオデータは典型的にはＲＧＢ(赤－緑－青）色空間で表示されるが、この色空間は３つのそれぞれの要素間に高度の相関を有する。エンコーダまたはデコーダによって見られるビデオデータ表現はしばしば、ＹＣｂＣｒなどの色空間を使用する。ＹＣｂＣｒは、伝達関数に従って「輝度」にマッピングされた輝度をＹ(一次）チャネルに集中させ、ＣｂおよびＣｒ(二次）チャネルに彩度を集中させる。さらに、ＣｂおよびＣｒチャネルは、「４：２：０彩度フォーマット」として知られる、輝度チャネルと比較してより低いレート、例えば、水平方向に半分および垂直方向に半分で空間的にサンプリングされてもよい。
ＶＶＣ規格は「ブロックベース」コーデックであり、フレームは最初に、「コーディングツリーユニット」（ＣＴＵ）として知られる領域の正方配列に分割される。ＣＴＵは一般に、１２８×１２８輝度サンプルなどの比較的大きな領域を占有する。しかしながら、各フレームの右端および下端のＣＴＵは、面積がより小さくてもよい。各ＣＴＵには、「コーディングユニット」（ＣＵ）とも呼ばれる、ＣＴＵの領域を１組の領域に分解することを定義する「コーディングツリー」が関連付けられる。ＣＵは、特定の順序で符号化または復号するために処理される。コーディングツリーおよび４：２：０彩度フォーマットの使用の結果として、フレーム内の所与の領域は、カラーチャネルにわたるコロケートされたブロックの集合に関連付けられる。輝度ブロックは幅×高さの寸法を有し、彩度ブロックは各彩度ブロックに対して幅／２×高さ／２の寸法を有する。所与の領域に対するコロケートされたブロックのコレクションは一般に、「ユニット」、例えば、上述のＣＵ、ならびに「予測ユニット」（ＰＵ）、および「変換ユニット」（ＴＵ）と呼ばれる。
同じ領域に対する彩度ブロック対輝度ブロックの異なる寸法にもかかわらず、所与の「ユニット」のサイズは一般に、ユニットに対する輝度ブロックの寸法に関して記述される。個々のブロックは、典型的にはブロックが関連付けられるユニットのタイプによって識別される。たとえば、「コーティングブロック(CB)」、「変換ブロック(TB)」、および予測ブロック（ＰＢ）は、１つのカラーチャネルのブロックであり、それぞれＣＵ、ＴＵ、およびＰＵに関連付けられている。「ユニット」と「ブロック」との間の上記の区別にもかかわらず、用語「ブロック」は、すべてのカラーチャネルに動作が適用されるフレームのエリアまたは領域に対する一般的な用語として使用されてもよい。
各ＣＵに対して、フレームデータの対応する領域の内容（サンプル値）の予測（ＰＵ）が生成される（「予測ユニット」）。さらに、予測とエンコーダへの入力で見られる領域の内容との間の差（または空間領域における「残差」）の表現が形成される。各色チャネルの差は、残差係数のシーケンスとして変換符号化され、所与のＣＵのための１つまたは複数のＴＵを形成することができる。適用される変換は、残差値の各ブロックに適用される離散コサイン変換（ＤＣＴ）または他の変換とすることができる。この一次変換は分離可能に適用され、すなわち、二次元変換は、２つのパスで実行される。ブロックは最初に、ブロック内のサンプルの各行に１次元変換を適用することによって変換される。次に、部分結果は、部分結果の各列に１次元変換を適用することによって変換され、残差サンプルを実質的に非相関化する変換係数の最終ブロックを生成する。さまざまなサイズの変換は、矩形形状のブロックの変換を含めて、ＶＶＣ基準によってサポートされ、各側面寸法は２のべき乗である。変換係数は、ビットストリームへのエントロピー符号化のために量子化される。
ＶＶＣ規格の実装は、典型的には処理を一連のステージに分割するためにパイプライン化を使用する。各ステージは同時に動作し、部分的に処理されたブロックは完全に処理された（すなわち、符号化または復号された）ブロックが出力される前に、１つのステージから次のステージに渡される。ＶＶＣ規格のための過剰な実装コストを回避するために、パイプライン化アーキテクチャの内容における変換されたブロックの効率的な処理が必要とされる。パイプラインステージが完了する必要がある速度および各ステージで処理されるデータのサイズの両方に関して、メモリ消費に関して、および「最悪の場合」を処理するために必要とされる機能モジュールに関して、過剰な実装コストが必要とされる。
本発明の目的は、既存の構成の１つまたは複数の欠点を実質的に克服するか、または少なくとも改善することである。
本開示の一態様によれば、所定の方式に従って、ビットストリームからコーディングユニットを復号する方法であって、
コーディングツリーユニットにおけるコーディングユニットを決定するための情報を前記ビットストリームから復号する第１の復号工程と、
前記情報に基づいて、前記コーディングユニットを決定する第１の決定工程と、
前記コーディングユニットにおける変換ユニットを決定する第２の決定工程と、
前記コーディングユニットを、前記変換ユニットを用いて復号する第２の復号工程と
を有し、
前記所定の方式において、前記コーディングユニットの辺の長さは、１２８サンプルとすることが可能であり、
前記変換ユニットを決定する際に第１の制約が用いられる場合における前記第２の決定工程において、前記コーディングユニットの少なくとも１つの辺の長さが１２８サンプルであったとしても、当該コーディングユニットにおける変換ユニットの輝度成分のサイズとして選択可能な最大サイズを３２サンプルとして前記変換ユニットを決定し、
前記変換ユニットを決定する際に第２の制約が用いられる場合における前記第２の決定工程において、前記コーディングユニットの少なくとも１つの辺の長さが１２８サンプルであったとしても、前記最大サイズを６４サンプルとして前記変換ユニットを決定する。
また、本開示の一態様によれば、所定の方式に従ってコーディングユニットを符号化する方法であって、
コーディングツリーユニットにおけるコーディングユニットを決定する第１の決定工程と、
前記コーディングユニットにおける変換ユニットを決定する第２の決定工程と、
前記コーディングユニットを、前記変換ユニットを用いて符号化する符号化工程と
を有し、
前記所定の方式において、前記コーディングユニットの辺の長さは、１２８サンプルとすることが可能であり、
前記変換ユニットを決定する際に第１の制約が用いられる場合における前記第２の決定工程において、前記コーディングユニットの少なくとも１つの辺の長さが１２８サンプルであったとしても、当該コーディングユニットにおける変換ユニットの輝度成分のサイズとして選択可能な最大サイズを３２サンプルとして前記変換ユニットを決定し、
前記変換ユニットを決定する際に第２の制約が用いられる場合における前記第２の決定工程において、前記コーディングユニットの少なくとも１つの辺の長さが１２８サンプルであったとしても、前記最大サイズを６４サンプルとして前記変換ユニットを決定する。
本開示のさらに別の態様によれば、
メモリと、
プロセッサであって、該プロセッサはビットストリームから画像フレーム内のコーディングユニットを復号する方法を実現するために、メモリに記憶されたコードを実行するように構成される
を有するシステムが提供され、方法は、
ビットストリームからコーディングユニットのサイズを決定することと、
画像フレームを複数の等しいサイズの処理領域に分割することであって、該複数の等しいサイズの処理領域の各々は、ビットストリームを復号するパイプラインの単一段階の間に処理されるブロックであり、
コーディングユニットが、決定された処理領域間の境界に重なる場合、複数の変換サイズからコーディングユニットのための変換サイズを選択し、変換サイズは、コーディングユニット内に適合するように選択され、処理領域とはサイズが異なり、
コーディングユニットにおける各変換ユニットの残差係数に逆変換を適用することによってコーディングユニットを復号することであって、各変換ユニットは、選択された変換サイズのものである、
を有する。
本開示のさらに別の態様によれば、
ビットストリームから画像フレームを受信し、
ビットストリーム内のコーディングユニットのサイズを決定し、
画像フレームを複数の等しいサイズの処理領域に分割し、該複数の等しいサイズの処理領域の各々は、ビットストリームを復号するパイプラインの単一段階の間に処理されるブロックであり、
コーディングユニットが、決定された処理領域間の境界に重なる場合、複数の変換サイズからコーディングユニットのための変換サイズを選択し、変換サイズは、コーディングユニット内に適合するように選択され、処理領域とはサイズが異なり、
コーディングユニットにおける各変換ユニットの残差係数に逆変換を適用することにより、コーディングユニットを復号し、各変換ユニットは、選択された変換サイズのものである
ビデオデコーダが提供される。
本開示のさらに別の態様によれば、ビットストリームから画像フレーム内のコーディングユニットを復号する方法が提供され、方法は、
ビットストリームからコーディングユニットのサイズを決定することと、
画像フレームを複数の等しいサイズの処理領域に分割することであって、該複数の等しいサイズの処理領域の各々は、最大の利用可能なコーディングユニットサイズよりも小さく、
候補動きベクトルのリストからコーディングユニットに対応する動きベクトルを選択することであって、動きベクトルを選択することは、（ｉ）コーディングユニットが決定された処理領域のうちの１つ以上のサイズである場合にはマージインデックスを復号すること、または（ｉｉ）コーディングユニットが決定された処理領域のうちの１つ以上のサイズでない場合にマージインデックスを復号するためにスキップフラグを復号デコードすること、を含み、
コーディングユニットのために選択された動きベクトルに従ってコーディングユニットを復号することと、
を有する。
本開示のさらに別の態様によれば、ビットストリームから画像フレーム内のコーディングユニットを復号する方法を実施するためのコンピュータプログラムが格納された非一時的なコンピュータ可読媒体が提供され、コンピュータプログラムは、
ビットストリームからコーディングユニットのサイズを決定するためのコードと、
画像フレームを複数の等しいサイズの処理領域に分割するためのコードであって、該複数の等しいサイズの処理領域の各々は、最大の利用可能なコーディングユニットサイズよりも小さく、
候補動きベクトルのリストからコーディングユニットに対応する動きベクトルを選択するためのコードであって、動きベクトルを選択することは、（ｉ）コーディングユニットが決定された処理領域のうちの１つ以上のサイズである場合にマージインデックスを復号すること、または（ｉｉ）コーディングユニットが決定された処理領域のうちの１つ以上のサイズでない場合にマージインデックスを復号するためにスキップフラグを復号すること、を有し、
コーディングユニットのために選択された動きベクトルに従って、コーディングユニットを復号するためのコードと
を有する。
本開示のさらに別の態様によれば、
メモリと、
プロセッサであって、プロセッサはビットストリームから画像フレーム内のコーディングユニットを復号する方法を実現するために、メモリに記憶されたコードを実行するように構成されるシステムが提供され、方法は、
ビットストリームからコーディングユニットのサイズを決定することと、
画像フレームを複数の等しいサイズの処理領域に分割することであって、該複数の等しいサイズの処理領域の各々は、最大の利用可能なコーディングユニットサイズよりも小さく、
候補動きベクトルのリストからコーディングユニットに対応する動きベクトルを選択することであって、動きベクトルを選択することは、（ｉ）コーディングユニットが決定された処理領域のうちの１つ以上のサイズである場合にマージインデックスを復号すること、または（ｉｉ）コーディングユニットが決定された処理領域のうちの１つ以上のサイズでない場合にマージインデックスを復号するためにスキップフラグを復号することを含み、
コーディングユニットのために選択された動きベクトルに従ってコーディングユニットを復号すること
を有する。
本開示のさらに別の態様によれば、
ビットストリームから画像フレームを受信し、
ビットストリームからコーディングユニットのサイズを決定し、
画像フレームを複数の等しいサイズの処理領域に分割し、該複数の等しいサイズの処理領域の各々は、最大の利用可能なコーディングユニットサイズよりも小さく、
候補動きベクトルのリストからコーディングユニットに対応する動きベクトルを選択し、動きベクトルを選択することは、（ｉ）コーディングユニットが決定された処理領域の１つ以上のサイズである場合にマージインデックスを復号すること、または（ｉｉ）コーディングユニットが決定された処理領域の１つ以上のサイズでない場合にマージインデックスを復号するためにスキップフラグを復号すること、を有し、
コーディングユニットのために選択された動きベクトルに従ってコーディングユニットを復号する
ビデオデコーダが提供される。
他の態様も開示される。
次に、本発明の少なくとも１つの実施形態を、以下の図面および付録を参照して説明する。
図１は、ビデオ符号化及び復号システムを示す概略ブロック図である。 図２Ａは、図１のビデオ符号化および復号システムの一方または両方を実施することができる汎用コンピュータシステムの概略ブロック図を形成する。 図２Ｂは、図１のビデオ符号化および復号システムの一方または両方を実施することができる汎用コンピュータシステムの概略ブロック図を形成する。 図３はビデオエンコーダの機能モジュールを示す概略ブロック図である。 図４は、ビデオデコーダの機能モジュールを示す概略ブロック図である。 図５は、汎用ビデオ符号化のツリー構造における１つ以上のブロックへのブロックの利用可能な分割を示す概略ブロック図である。 図６は、汎用ビデオ符号化のツリー構造における１つ以上のブロックへのブロックの許可された分割を達成するためのデータフローの概略図である。 図７Ａは、コーディングツリーユニット（ＣＴＵ）をいくつかのコーディングユニットに分割する例を示す。 図７Ｂは、コーディングツリーユニット（ＣＴＵ）をいくつかのコーディングユニットに分割する例を示す。 図８Ａは、パイプライン化されたアーキテクチャに従って処理されるコーディングツリーユニット（ＣＴＵ）のシーケンス例を示す。 図８Ｂはビデオにおけるフレームの「ランダムアクセス」ピクチャグループ構造の例を示す。 図９は、ＶＶＣ規格のための変換サイズを示す図である。 図１０Ａは、コーディングツリーの最上位レベルにおける３分割のコーディングツリーユニット（ＣＴＵ）のコーディングユニットを示す図である。 図１０Ｂは、図１０Ａのコーディングツリーに関連付けられた代替の変換ユニットを示す図である。 図１０Ｃは、反対方向の２つの３分割のコーディングツリーに関連付けられた変換ユニットを示す図である。 図１０Ｄは、垂直３分割、水平２分割、および垂直３分割のコーディングツリーに関連付けられた変換ユニットを示す図である。 図１０Ｅは、２つの垂直３分割のコーディングツリーに関連付けられた変換ユニットを示す図である。 図１０Ｆは、図１０Ｅに対する２つの垂直３分割のコーディングツリーに関連付けられた代替の変換ユニットを示す図である。 図１１は、コーディングツリーユニットのコーディングツリーにおけるコーディングユニットの予測モードを決定するための方法のフローチャートである。 図１２は、変換を使用してコーディングユニットを符号化するための方法のフローチャート図であり、この方法は、ビデオエンコーダのパイプライン化された実装を実現することを可能にする。 図１３は、変換を用いてコーディングユニットを復号する方法のフローチャート図であり、図１２の方法に従って選択された変換サイズ。
添付の図面の１又は２以上において、同一の参照符号を有するステップ及び／又は特徴を参照する場合、それらのステップ及び／又は特徴は本明細書の目的のために、反対の意図が現れない限り、同一の機能又は動作を有する。
図１は、ビデオ符号化及び復号システム１００の機能モジュールを示す概略ブロック図である。システム１００は、ＣＴＵサイズよりも小さい領域（または「パイプライン処理領域」）においてコーディングツリーユニット（ＣＴＵ）を処理することを可能にするために、大きなブロックまたはコーディングユニット（ＣＵ）を複数のより小さなブロックまたは変換ユニット（ＴＵ）に暗黙的に分割することを利用することができる。例えば、システム１００は、４つの象限（four quadrants）としてＣＴＵを処理することができ、その各々は多くのＣＵを含むことができ、かつ／または複数の領域にまたがるＣＵの部分を含むことができる。
システム１００は、ソース装置１１０と宛先装置１３０とを含む。通信チャネル１２０は、符号化されたビデオ情報をソース装置１１０から宛先装置１３０に通信するために使用される。いくつかの構成では、ソース装置１１０および宛先装置１３０がそれぞれの携帯電話ハンドセットまたは「スマートフォン」のいずれかまたは両方を備えることができ、その場合、通信チャネル１２０はワイヤレスチャネルである。他の構成では、ソース装置１１０および宛先装置１３０がビデオ会議機器を備えることができ、その場合、通信チャネル１２０は通常、インターネット接続などの有線チャネルである。さらに、ソース装置１１０および宛先装置１３０は、無線テレビ放送、ケーブルテレビアプリケーション、インターネットビデオアプリケーション（ストリーミングを含む）、およびファイルサーバ内のハードディスクドライブなどの何らかのコンピュータ可読記憶媒体上に符号化ビデオデータが取り込まれるアプリケーションをサポートする装置を含む、広範囲の装置のうちの任意のものを備えることができる。
図１に示すように、ソース装置１１０は、ビデオソース１１２と、ビデオエンコーダ１１４と、送信機１１６と、を含む。ビデオソース１１２は、典型的には撮像センサ等の、撮像されたビデオフレームデータ（１１３として示されている）のソース、非一時的記録媒体上に格納された前に撮像されたビデオシーケンス、又はリモート撮像センサからのビデオ、を有する。ビデオソース１１２はまた、コンピュータグラフィックスカードの出力であってもよく、例えば、タブレットコンピュータなどのコンピューティングデバイスで実行されているオペレーティングシステムとさまざまなアプリケーションのビデオ出力を表示する。ビデオソース１１２として撮像センサを含み得るソース装置１１０の例は、スマートフォン、ビデオカメラ、業務用ビデオカメラ、およびネットワークビデオカメラを含む。
ビデオエンコーダ１１４は、図３を参照してさらに説明されるように、ビデオソース１１２からの撮像されたフレームデータ（矢印１１３によって示される）をビットストリーム（矢印１１５によって示される）に変換（または「符号化」）する。ビットストリーム１１５は、符号化されたビデオデータ（または「符号化されたビデオ情報」）として通信チャネル１２０を介して送信機１１６によって送信される。ビットストリーム１１５は後に通信チャネル１２０を介して送信されるまで、または通信チャネル１２０を介した送信の代わりに、「フラッシュ」メモリまたはハードディスクドライブなどの非一時的記憶装置１２２に記憶されることも可能である。
宛先装置１３０は、受信機１３２と、ビデオデコーダ１３４と、表示装置１３６と、を含む。受信機１３２は、通信チャネル１２０から符号化されたビデオデータを受信し、受信されたビデオデータをビットストリームとしてビデオデコーダ１３４に渡す（矢印１３３によって示される）。そして、ビデオデコーダ１３４は、（矢印１３５で示す）復号フレームデータを表示装置１３６に出力する。表示装置１３６の例には、陰極線管、スマートフォン、タブレットコンピュータ、コンピュータモニタ、またはスタンドアロンテレビセットなどの液晶ディスプレイが含まれる。また、ソース装置１１０および宛先装置１３０の各々の機能性が単一の装置で実現されることも可能であり、その例は、携帯電話ハンドセットおよびタブレットコンピュータを含む。
上記の例示的なデバイスにもかかわらず、ソース装置１１０および宛先装置１３０のそれぞれは、一般にハードウェアおよびソフトウェア構成要素の組合せを介して、汎用コンピューティングシステム内で構成され得る。図２Ａは、コンピュータモジュール２０１と、キーボード２０２、マウスポインタデバイス２０３、スキャナ２２６、ビデオソース１１２として構成することができるカメラ２２７、およびマイクロフォン２８０などの入力デバイスと、プリンタ２１５、表示装置１３６として構成することができるディスプレイデバイス２１４、およびスピーカ２１７を含む出力デバイスと、を含む、そのようなコンピュータシステム２００を示す。外部変復調器（モデム）トランシーバ装置２１６は、接続２２１を介して通信ネットワーク２２０との間で通信するためにコンピュータモジュール２０１によって使用され得る。通信チャネル１２０を表すことができる通信ネットワーク２２０は、インターネット、セルラ電気通信ネットワーク、またはプライベートＷＡＮなどの広域ネットワーク（ＷＡＮ）であってもよい。接続２２１が電話回線である場合、モデム２１６は従来の「ダイヤルアップ」モデムであってもよい。あるいは接続２２１が大容量（例えば、ケーブルまたは光）接続である場合、モデム２１６はブロードバンドモデムであってもよい。無線モデムはまた、通信ネットワーク２２０への無線接続のために使用されてもよい。トランシーバ装置２１６は、送信機１１６及び受信機１３２の機能性を提供することができ、通信チャネル１２０は、接続２２１内に具現化することができる。
コンピュータモジュール２０１は、典型的には少なくとも１つのプロセッサユニット２０５と、メモリユニット２０６とを含む。例えば、メモリユニット２０６は、半導体ランダムアクセスメモリ（ＲＡＭ）及び半導体リードオンリーメモリ（ROM）を有することができる。コンピュータモジュール２０１はまた、ビデオディスプレイ２１４、スピーカ２１７、およびマイクロフォン２８０に結合するオーディオビデオインターフェース２０７、キーボード２０２、マウス２０３、スキャナ２２６、カメラ２２７、およびオプションとしてジョイスティックまたは他のヒューマンインターフェースデバイス（図示せず）に結合するＩ／Ｏインターフェース２１３、ならびに外部モデム２１６およびプリンタ２１５のためのインターフェース２０８を含む、いくつかの入出力（Ｉ／Ｏ）インターフェースを含む。オーディオビデオインターフェース２０７からコンピュータモニタ２１４への信号は一般に、コンピュータグラフィックスカードの出力である。いくつかの実装では、モデム２１６が、例えばインターフェース２０８内のコンピュータモジュール２０１内に組み込まれてもよい。コンピュータモジュール２０１はまた、ローカルネットワークインターフェース２１１を有し、これは、接続２２３を介して、ローカルエリアネットワーク（ＬＡＮ）として知られるローカルエリア通信ネットワーク２２２への、コンピュータシステム２００の結合を可能にする。図２Ａに示すように、ローカル通信ネットワーク２２２は、通常、いわゆる「ファイアウォール」デバイスまたは同様の機能のデバイスを含む接続２２４を介してワイドネットワーク２２０に結合することもできる。ローカルネットワークインターフェース２１１は、イーサネットTM回路カード、ブルートゥースTMワイヤレス構成又はＩＥＥＥ８０２．１１ワイヤレス構成を含むことができるが、インターフェース２１１のために多くの他のタイプのインターフェースが実施されてもよい。ローカルネットワークインターフェース２１１は、また、送信機１１６の機能を提供することができ、受信機１３２および通信チャネル１２０はまた、ローカル通信ネットワーク２２２において具現化することができる。
Ｉ／Ｏインターフェース２０８および２１３は、シリアルコネクティビティおよびパラレルコネクティビティのいずれかまたは両方を提供することができ、前者は、典型的にはユニバーサルシリアルバス（ＵＳＢ）規格に従って実施され、対応するＵＳＢコネクタ（図示せず）を有する。記憶装置２０９が提供され、典型的にはハードディスクドライブ（ＨＤＤ）２１０を含む。フロッピーディスクドライブおよび磁気テープドライブ（図示せず）などの他の記憶装置も使用することができる。光ディスクドライブ２１２は、典型的にはデータの不揮発性ソースとして機能するために設けられる。例えば、光ディスク（例えば、ＣＤ－ＲＯＭ、ＤＶＤ、Blu ray DiscTM)、ＵＳＢ－ＲＡＭ、ポータブル、外部ハードドライブ、およびフロッピーディスクなどのポータブルメモリデバイスは、コンピュータシステム２００に対するデータの適切なソースとして使用することができる。典型的にはＨＤＤ２１０、光ドライブ２１２、ネットワーク２２０及び２２２のいずれかはビデオソース１１２として、又はディスプレイ２１４を介して再生するために記憶されるべき復号されたビデオデータのための宛先として動作するように構成されてもよい。システム１００のソース装置１１０および宛先装置１３０は、コンピュータシステム２００において具現化されてもよい。
コンピュータモジュール２０１の構成要素２０５～２１３は、典型的には相互接続バス２０４を介して、当業者に知られているコンピュータシステム２００の従来の動作モードをもたらす方法で通信する。例えば、プロセッサ２０５は、接続２１８を用いてシステムバス２０４に結合される。同様に、メモリ２０６および光ディスクドライブ２１２は、接続２１９によってシステムバス２０４に結合される。上記の構成が実行可能なコンピュータの例には、ＩＢＭ－ＰＣおよび互換機、Sun SPARCステーション、Apple MacTMまたは同様のコンピュータシステムが含まれる。
適切または必要な場合、ビデオエンコーダ１１４およびビデオデコーダ１３４、ならびに以下で説明する方法は、コンピュータシステム２００を使用して実施することができる。具体的には、ビデオエンコーダ１１４、ビデオデコーダ１３４、および説明される方法は、コンピュータシステム２００内で実行可能な１つまたは複数のソフトウェアアプリケーションプログラム２３３として実施することができる。具体的には、ビデオエンコーダ１１４、ビデオデコーダ１３４、および説明する方法のステップは、コンピュータシステム２００内で実行されるソフトウェア２３３内の命令２３１（図２Ｂ参照）によって実行される。ソフトウェア命令２３１は、それぞれが１つ以上の特定のタスクを実行するための１つ以上のコードモジュールとして形成されてもよい。ソフトウェアはまた、２つの別個の部分に分割されてもよく、その場合、第１の部分と対応するコードモジュールは説明される方法を実行し、第２の部分と対応するコードモジュールは、第１の部分とユーザとの間のユーザインターフェースを管理する。
ソフトウェアは例えば、以下に説明する記憶装置を含むコンピュータ可読媒体に記憶することができる。ソフトウェアは、コンピュータ可読媒体からコンピュータシステム２００にロードされ、その後、コンピュータシステム２００によって実行される。このようなソフトウェア又はコンピュータ可読媒体に記録されたコンピュータプログラムを有するコンピュータ可読媒体は、コンピュータプログラム製品である。コンピュータシステム２００におけるコンピュータプログラム製品の使用は、ビデオエンコーダ１１４、ビデオデコーダ１３４、および説明される方法を実施するための有利な装置をもたらすことが好ましい。
ソフトウェア２３３は、典型的にはＨＤＤ２１０またはメモリ２０６に記憶される。ソフトウェアは、コンピュータ可読媒体からコンピュータシステム２００にロードされ、コンピュータシステム２００によって実行される。したがって、例えば、ソフトウェア２３３は、光ディスクドライブ２１２によって読み取られる光学的に読み取り可能なディスク記憶媒体（例えば、ＣＤ－ＲＯＭ）２２５に記憶することができる。
場合によっては、アプリケーションプログラム２３３が１つ以上のＣＤ－ＲＯＭ２２５上で符号化されてユーザに供給され、対応するドライブ２１２を介して読み出されてもよく、あるいはネットワーク２２０または２２２からユーザによって読み出されてもよい。さらに、ソフトウェアは、他のコンピュータ可読媒体からコンピュータシステム２００にロードすることもできる。コンピュータ可読記憶媒体は、実行および／または処理のために記録された命令および／またはデータをコンピュータシステム２００に提供する任意の非一時的な有形の記憶媒体を指す。このような記憶媒体の例としては、フロッピーディスク、磁気テープ、ＣＤ－ＲＯＭ、ＤＶＤ、Blu-ray DiscTM、ハードディスクドライブ、ＲＯＭまたは集積回路、ＵＳＢメモリ、光磁気ディスク、またはＰＣＭＣＩＡカードなどのコンピュータ可読カードを含み、そのような装置がコンピュータモジュール２０１の内部または外部であるか否かは問わない。コンピュータモジュール４０１へのソフトウェア、アプリケーションプログラム、命令および／またはビデオデータまたは符号化されたビデオデータの提供にも参加し得る一時的なまたは非有形のコンピュータ可読伝送媒体の例には、無線または赤外線伝送チャネル、ならびに別のコンピュータまたはネットワーク接続された装置へのネットワーク接続、ならびにウェブサイトなどに記録された電子メール伝送および情報を含むインターネットまたはイントラネットが含まれる。
アプリケーションプログラム２３３の第２の部分および上記の対応するコードモジュールは、ディスプレイ２１４上でレンダリングされるかまたは他の方法で表される１つ以上のグラフィカルユーザインタフェース（ＧＵＩ）を実装するために実行されてもよい。典型的にはキーボード２０２およびマウス２０３の操作を通して、アプリケーションおよびコンピュータシステム２００のユーザは機能的に適応可能な方法でインターフェースを操作し、ＧＵＩに関連するアプリケーションに制御コマンドおよび／または入力を提供することができる。スピーカ２１７を介して出力されるスピーチプロンプトおよびマイクロフォン２８０を介して入力されるユーザ音声コマンドを利用するオーディオインターフェースなど、他の形態の機能的に適応可能なユーザインターフェースを実装することもできる。
図２Ｂは、プロセッサ２０５および「メモリ」２３４の詳細な概略ブロック図である。メモリ２３４は、図２Ａのコンピュータモジュール２０１がアクセス可能な全てのメモリモジュール（ＨＤＤ２０９及び半導体メモリ２０６を含む）の論理集合体を表す。
最初にコンピュータモジュール２０１の電源が入ると、パワーオン自己テスト（ＰＯＳＴ）プログラム２５０が実行される。ＰＯＳＴプログラム２５０は、典型的には図２Ａの半導体メモリ２０６のＲＯＭ２４９に記憶される。ソフトウェアを記憶するＲＯＭ２４９などのハードウェアデバイスは、ファームウェアと呼ばれることもある。ＰＯＳＴプログラム２５０は、コンピュータモジュール２０１内のハードウェアを検査して、適切に機能することを確認し、通常、正しい動作のために、プロセッサ２０５、メモリ２３４（２０９、２０６）、および基本入出力システムソフトウェア（ＢＩＯＳ）モジュール２５１（通常はＲＯＭ２４９にも格納される）をチェックする。ＰＯＳＴプログラム２５０が正常に実行されると、ＢＩＯＳ２５１は、図２Ａのハードディスクドライブ２１０を起動する。ハードディスクドライブ２１０を起動すると、ハードディスクドライブ２１０上に常駐するブートストラップローダプログラム２５２がプロセッサ２０５を介して実行される。これにより、オペレーティングシステム２５３がＲＡＭメモリ２０６にロードされ、その上でオペレーティングシステム２５３が動作を開始する。オペレーティングシステム２５３は、プロセッサ２０５によって実行可能なシステムレベルアプリケーションであり、プロセッサ管理、メモリ管理、デバイス管理、ストレージ管理、ソフトウェアアプリケーションインタフェース、および汎用ユーザインタフェースを含む様々な高レベルの機能を満たす。
オペレーティングシステム２５３は、メモリ２３４（２０９、２０６）を管理して、コンピュータモジュール２０１上で実行される各プロセスまたはアプリケーションが別のプロセスに割り当てられたメモリと衝突することなく実行するのに十分なメモリを有することを保証する。さらに、図２Ａのコンピュータシステム２００で利用可能な異なるタイプのメモリは、各プロセスが効果的に実行できるように、適切に使用されなければならない。したがって、集約メモリ２３４は、メモリの特定のセグメントが（特に明記されていない限り）どのように割り当てられるかを示すことを意図するものではなく、むしろ、コンピュータシステム２００によってアクセス可能なメモリの一般的なビューと、そのようなセグメントがどのように使用されるかを提供することを意図するものである。
図２Ｂに示すように、プロセッサ２０５は、制御部２３９、演算論理ユニット（ＡＬＵ）２４０、時にはキャッシュメモリと呼ばれるローカルまたは内部メモリ２４８、を含む多数の機能モジュールを含む。キャッシュメモリ２４８は、典型的にはレジスタセクション内に多数の記憶レジスタ２４４～２４６を含む。１つ以上の内部バス２４１は、これらの機能モジュールを機能的に相互接続する。プロセッサ２０５はまた、典型的には、接続２１８を使用して、システムバス２０４を介して外部装置と通信するための１つ以上のインターフェース２４２を有する。メモリ２３４は、接続２１９を使用してバス２０４に結合される。
アプリケーションプログラム２３３は、条件分岐およびループ命令を含み得る命令のシーケンス２３１を含む。プログラム２３３はまた、プログラム２３３の実行に使用されるデータ２３２を含んでもよい。命令２３１およびデータ２３２は、それぞれメモリ位置２２８、２２９、２３０および２３５、２３６、２３７に格納される。命令２３１とメモリ位置２２８～２３０の相対的なサイズに応じて、メモリ位置２３０に示される命令によって示されるように、特定の命令を単一のメモリ位置に記憶することができる。あるいは、命令がメモリ位置２２８および２２９に示される命令セグメントによって示されるように、各々が別個のメモリ位置に記憶されるいくつかの部分にセグメント化されてもよい。
一般に、プロセッサ２０５には、その中で実行される命令のセットが与えられる。プロセッサ２０５は後続の入力を待ち、この入力に対してプロセッサ２０５は、別の命令セットを実行することによって反応する。各入力は入力装置２０２、２０３のうちの１つまたは複数によって生成されたデータ、ネットワーク２２０、２０２のうちの１つを介して外部ソースから受信されたデータ、記憶装置２０６、２０９のうちの１つから取り出されたデータ、または対応するリーダ２１２に挿入された記憶媒体２２５から取り出されたデータを含む、いくつかのソースのうちの１つまたは複数から提供することができ、すべて図２Ａに示されている。命令のセットを実行すると、データが出力される場合がある。実行には、データまたは変数をメモリ２３４に記憶することも含まれ得る。
ビデオエンコーダ１１４、ビデオデコーダ１３４、および説明される方法は、メモリ２３４内の対応するメモリ位置２５５、２５６、２５７に格納されている入力変数２５４を使用することができる。ビデオエンコーダ１１４、ビデオデコーダ１３４、および説明される方法は、出力変数２６１を生成し、これらは、メモリ２３４内の対応するメモリ位置２６２、２６３、２６４に格納される。中間変数２５８は、メモリ位置２５９、２６０、２６６および２６７に格納され得る。
図２Ｂのプロセッサ２０５を参照すると、レジスタ２４４、２４５、２４６、演算論理ユニット（ＡＬＵ）２４０、および制御部２３９は、プログラム２３３を構成する命令セット内のすべての命令に対して「フェッチ、デコード、および実行」サイクルを実行するのに必要なマイクロオペレーションのシーケンスを実行するために協働する。各フェッチ、デコード、および実行サイクルは
（ａ）メモリ位置２２８、２２９、２３０から命令２３１をフェッチまたは読出すフェッチ動作
（ｂ）制御部２３９が、どの命令がフェッチされたかを判定するデコード動作
（ｃ）制御部２３９及び／又はＡＬＵ２４０が命令を実行する動作を実行する
を有する。
その後、次の命令のフェッチ、デコード、および実行サイクルをさらに実行することができる。同様に、制御部２３９がメモリ位置２３２に値を格納または書き込む格納サイクルを実行することができる。
後述する図１２および図１３の方法における各ステップまたはサブプロセスは、プログラム２３３の１つまたは複数のセグメントに関連付けられ、典型的にはプロセッサ２０５内のレジスタセクション２４４、２４５、２４７、ＡＬＵ２４０、および制御部２３９が協働して、プログラム２３３の注記されたセグメントに対する命令セット内のすべての命令に対してフェッチ、デコード、および実行サイクルを実行することによって実行される。
図３は、ビデオエンコーダ１１４の機能モジュールを示す概略ブロック図である。図４は、ビデオデコーダ１３４の機能モジュールを示す概略ブロック図である。一般に、データは、固定サイズのサブブロックへのブロックの分割などのサンプルまたは係数のグループで、または配列として、ビデオデコーダ１３４とビデオエンコーダ１１４の機能モジュールの間を通過する。ビデオエンコーダ１１４およびビデオデコーダ１３４は、図２Ａおよび図２Ｂに示すように、汎用コンピュータシステム２００を使用して実施することができ、様々な機能モジュールは、ハードディスクドライブ２０５上に常駐し、プロセッサ２０５によってその実行中に制御されるソフトウェアアプリケーションプログラム２３３の１つ以上のソフトウェアコードモジュールなど、コンピュータシステム２００内で実行可能なソフトウェアによって、コンピュータシステム２００内の専用ハードウェアによって実現することができる。あるいは、ビデオエンコーダ１１４およびビデオデコーダ１３４は、コンピュータシステム２００内で実行可能なソフトウェアおよび専用ハードウェアの組合せによって実装されてもよい。ビデオエンコーダ１１４、ビデオデコーダ１３４、および説明される方法は、代替として、説明される方法の機能またはサブ機能を実行する１つまたは複数の集積回路などの専用ハードウェアで実装され得る。そのような専用ハードウェアは、グラフィック処理ユニット（ＧＰＵ）、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け標準製品（ＡＳＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または１つまたは複数のマイクロプロセッサおよび関連するメモリを含むことができる。特に、ビデオエンコーダ１１４は、モジュール３１０～３８６を含み、ビデオデコーダ１３４は、ソフトウェアアプリケーションプログラム２３３の１つ以上のソフトウェアコードモジュールとしてそれぞれ実装され得るモジュール４２０～４９６を含む。
図３のビデオエンコーダ１１４は汎用ビデオ符号化（ＶＶＣ）ビデオ符号化パイプラインの一例であるが、本明細書で説明する処理ステージを実行するために他のビデオコーデックを使用することもできる。ビデオエンコーダ１１４は、一連のフレームなどの、撮像されたフレームデータ１１３を受信し、各フレームは１つ以上のカラーチャネルを含む。ブロックパーティショナ３１０は最初に、フレームデータ１１３を、一般には矩形形状のＣＴＵに分割し、ＣＴＵのための特定のサイズが使用されるように構成される。ＣＴＵのサイズは、例えば、６４×６４、１２８×１２８、または２５６×２５６輝度サンプルとすることができる。ブロックパーティショナ３１０はさらに、各ＣＴＵを１つまたは複数のＣＵに分割し、ＣＵは、二乗および非二乗アスペクト比の両方を含むことができる様々なサイズを有する。しかし、ＶＶＣ規格では、ＣＵ、ＰＵ、およびＴＵは常に２の累乗である辺長を有する。したがって、３１２として表される現在のＣＵは、ブロックパーティショナ３１０から出力され、ＣＴＵのコーディングツリーに従って、ＣＴＵの１つまたは複数のブロックにわたる反復に従って進行する。ＣＴＵをＣＵに分割するためのオプションは、図５および図６を参照して以下でさらに説明される。
フレームデータ１１３の第１の分割から得られるＣＴＵは、ラスタスキャン順序でスキャンされ、１つまたは複数の「スライス」にグループ化され得る。スライスは「イントラ」（または「Ｉ」）スライスであってもよく、イントラスライス（Ｉスライス）はスライス内のすべてのＣＵがイントラ予測されることを示す。代替的に、スライスは、単一または双予測（それぞれ、「Ｐ」または「Ｂ」スライス）であってもよく、それぞれ、スライスにおける単一および双予測のさらなる利用可能性を示す。フレームデータ１１３は通常、複数のカラーチャネルを含むので、ＣＴＵおよびＣＵはブロックパーティショナ３１０の動作から定義されたブロック領域と重複するすべてのカラーチャネルからのサンプルに関連付けられる。ＣＵは、フレームデータ１１３の各カラーチャネルに対して１つのコーディングブロック（ＣＢ）を含む。輝度チャネルと比較して彩度チャネルのサンプリングレートが潜在的に異なるために、彩度チャネルのＣＢの寸法は、輝度チャネルのＣＢの寸法とは異なり得る。４：２：０彩度フォーマットを使用する場合、ＣＵの彩度チャネルのＣＢは、ＣＵの輝度チャネルのためのＣＢの幅および高さの半分の寸法を有する。
各ＣＴＵに対して、ビデオエンコーダ１１４は２段階で動作する。第１の段階（「サーチ」ステージと呼ばれる）では、ブロックパーティショナ３１０がコーディングツリーの様々な潜在的な構成をテストする。コーディングツリーの各潜在的構成は、関連する「候補」ＣＵをもつ。最初の段階は、低歪みで高い圧縮効率を提供するＣＵを選択するために様々な候補ＣＵをテストすることを含む。このテストは一般にラグランジュ最適化を含み、それによって候補ＣＵがレート（符号化コスト）と歪（入力フレームデータ１１３に関する誤差）の重み付けされた組合せに基づいて評価される。「最良の」候補ＣＵ（最も低いレート／歪みを有するＣＵ）は、ビットストリーム１１５への後続の符号化のために選択される。候補ＣＵの評価には、所与のエリアに対してＣＵを使用するか、または様々なスプリットオプションに従ってエリアをスプリットし、結果として生じるより小さいエリアのそれぞれをさらなるＣＵで符号化するか、またはエリアをさらにスプリットするオプションが含まれる。その結果、ＣＵとコーディングツリー自体の両方が探索段階で選択される。
ビデオエンコーダ１１４は、各ＣＵ、例えばＣＵ３１２に対して矢印３２０で示される予測ユニット（ＰＵ）を生成する。ＰＵ３２０は、関連するＣＵ３１２のコンテンツの予測である。減算器モジュール３２２はＰＵ３２０とＣＵ３１２との間に、３２４（または「残差」、空間領域内にある差を参照する）として示される差を生成する。差３２４は、ＰＵ３２０およびＣＵ３１２における対応するサンプル間のブロックサイズの差である。差分３２４は、変換され、量子化され、矢印３３６によって示される変換ユニット（ＴＵ）として表される。ＰＵ３２０および関連するＴＵ３３６は、典型的には多くの可能な候補ＣＵのうちの「最良の」１つとして選択される。
候補コーディングユニット（ＣＵ）は、関連するＰＵおよび結果として生じる残差についてビデオエンコーダ１１４に利用可能な予測モードの１つから生じるＣＵである。各候補ＣＵは図１０～１２を参照して以下に記載されるように、１つ以上の対応するＴＵを生じる。ＴＵ３３６は、差分３２４の量子化され、変換された表現である。デコーダ１１４において予測されたＰＵと結合されると、ＴＵ３３６は、ビットストリームにおける追加の信号を犠牲にして、デコードされたＣＵとオリジナルのＣＵ３１２との間の差を低減する。
したがって、各候補コーディングユニット（ＣＵ）、すなわち変換ユニット（ＴＵ）と組み合わせた予測ユニット（ＰＵ）は、関連する符号化コスト（または「レート」）および関連する差（または「歪み」）を有する。レートは、典型的にはビット単位で測定される。ＣＵの歪みは、典型的には絶対差の和（ＳＡＤ）または二乗差の和（ＳＳＤ）などのサンプル値の差として推定される。各候補ＰＵから得られる推定は、モード選択器３８６によって、差３２４を用いて決定され、イントラ予測モード（矢印３８８によって表される）を決定する。各候補予測モードと対応する残差符号化に関連する符号化コストの推定は、残差のエントロピー符号化よりもかなり低いコストで実行できる。従って、レート歪み検知における最適モードを決定するために、多数の候補モードを評価することができる。
最適モードの決定は、典型的にはラグランジュ最適化の変形を用いて達成される。イントラ予測モード３８８の選択は、典型的には特定のイントラ予測モードの適用から生じる残差データのための符号化コストを決定することを含む。符号化コストは「絶対変換差の和」（ＳＡＴＤ）を使用することによって近似することができ、それによって、アダマール変換などの比較的単純な変換を使用して、推定された変換残差コストを得る。比較的単純な変換を使用するいくつかの実施形態では、単純化された推定方法から得られるコストがさもなければ完全な評価から決定されるのであろう実際のコストに単調に関係する。単調に関連する推定コストを有する実施形態では、単純化された推定方法を使用して、ビデオエンコーダ１１４の複雑さを低減しながら、同じ決定（すなわち、イントラ予測モード）を行うことができる。推定されたコストと実際のコストとの間の関係における可能な非単調性を可能にするために、簡略化された推定方法を使用して、最良の候補のリストを生成することができる。非単調性は例えば、残差データの符号化に利用可能なさらなるモード決定から生じ得る。最良の候補のリストは、任意の数であってもよい。最良の候補を使用して、より完全な探索を実行して、候補のそれぞれについて残差データを符号化するためのモード選択を確立することができ、他のモード決定と共にイントラ予測モードの最終選択を可能にする。
他のモード決定は、「変換スキップ」として知られる順方向変換をスキップする能力を含む。変換をスキップすることは、変換基底関数としての表現を介して符号化コストを低減するための適切な相関を欠く残差データに適している。比較的単純なコンピュータ生成グラフィックスのような特定のタイプのコンテンツは、同様の挙動を示すことがある。「スキップされた変換」の場合、変換自体が実行されなくても、残差係数は依然として符号化される。
ラグランジュ処理または類似の最適化処理を採用して、ＣＴＵのＣＵへの分割（ブロックパーティショナ３１０による）と、複数の可能性からの最良の予測モードの選択の両方を選択することができる。モード選択モジュール３８６における候補モードのラグランジュ最適化プロセスの適用を通して、最低コスト測定を有するイントラ予測モードが最良のモードとして選択される。最良のモードは、選択されたイントラ予測モード３８８であり、エントロピーエンコーダ３３８によってビットストリーム１１５に符号化される。モード選択モジュール３８６の動作によるイントラ予測モード３８８の選択は、ブロックパーティショナ３１０の動作に拡張する。例えば、イントラ予測モード３８８の選択のための候補は、所与のブロックに適用可能なモードと、さらに、所与のブロックと一緒に集合的に配置される複数のより小さいブロックに適用可能なモードとを含むことができる。所与のブロックおよびより小さいコロケートされたブロックに適用可能なモードを含む場合、候補を暗黙的に選択するプロセスは、ＣＴＵのＣＵへの最良の階層分解を決定するプロセスでもある。
ビデオエンコーダ１１４の第２の動作段階（「符号化」段階と呼ばれる）では、選択されたコーディングツリー、したがって選択された各ＣＵに対する反復がビデオエンコーダ１１４内で実行される。反復では、ＣＵが本明細書でさらに説明するように、ビットストリーム１１５に符号化される。
エントロピーエンコーダ３３８は、構文要素の可変長符号化と構文要素の算術符号化の両方をサポートする。算術符号化は、コンテキスト適応２進算術符号化処理を使用してサポートされる。算術的に符号化された構文要素は１つ以上の’ｂｉｎｓ’のシーケンスからなる。ビンはビットと同様に、「０」または「１」の値を持つ。しかし、ビンはビットストリーム１１５内で離散ビットとして符号化されていない。ビンは、「コンテキスト」として知られる、関連する予測（または「可能性」または「最も可能性のある」）値および関連する確率を有する。符号化される実際のビンが予測値と一致するとき、「最確シンボル」（ＭＰＳ）が符号化される。最も確率の高いシンボルを符号化することは、消費されるビットに関して比較的安価である。符号化されるべき実際のビンがありそうな値と一致しない場合、「最低確率シンボル」（ＬＰＳ）が符号化される。最低確率シンボルを符号化することは、消費されるビットに関して比較的高いコストを有する。ビン符号化技術は、「０」対「１」の確率がスキューされるビンの効率的な符号化を可能にする。２つの可能な値（すなわちｆｌａｇ）を持つ構文要素に対しては、単一のビンで十分である。可能な値が多い構文要素の場合は、一連のビンが必要である。
シーケンス中の後のビンの存在は、シーケンス中の前のビンの値に基づいて決定されてもよい。さらに、各ビンは、２つ以上のコンテキストに関連付けることができる。特定のコンテキストの選択は構文要素の以前のビン、隣接する構文要素のビン値（すなわち、隣接するブロックからのもの）などに依存することができる。コンテキスト符号化ビンが符号化されるたびに、そのビンに対して選択されたコンテキスト（もしあれば）は、新しいビン値を反映する方法で更新される。このように、２進算術符号化方式は適応型であると言われている。
また、ビデオエンコーダ１１４によってサポートされるのは、コンテキストを欠くビン（「バイパスビン」）である。バイパスビンは、「０」と「１」との間の等確率分布を仮定して符号化される。したがって、各ビンは、ビットストリーム１１５内の１ビットを占有する。コンテキストがないと、メモリが節約され、複雑さが軽減される。したがって、特定のビンの値の分布が偏っていない場合は、バイパスビンが使用される。コンテキストおよび適応を使用するエントロピーコーダの一例はＣＡＢＡＣ(コンテキスト適応バイナリ算術コーダ）として当技術分野で知られており、このコーダの多くの変形がビデオ符号化に使用されている。
エントロピーエンコーダ３３８は、コンテキスト符号化ビンとバイパス符号化ビンとの組合せを使用してイントラ予測モード３８８を符号化する。典型的には、「最確モード」のリストがビデオエンコーダ１１４において生成される。最も確率の高いモードのリストは典型的には３つまたは６つのモードのような固定長であり、以前のブロックで遭遇したモードを含むことができる。コンテキスト符号化ビンは、イントラ予測モードが最も確率の高いモードの１つかどうかを示すフラグを符号化する。イントラ予測モード３８８が最も確率の高いモードのうちの１つである場合、バイパス符号化されたビンを使用するさらなるシグナリングが符号化される。符号化されたさらなるシグナリングは例えば、切り捨てられた単項ビンストリングを使用して、どの最も確率の高いモードがイントラ予測モード３８８に対応するかを示す。そうでない場合、イントラ予測モード３８８は、「残りのモード」として符号化される。残りのモードとしての符号化は、バイパス符号化されたビンを使用しても符号化される固定長符号などの代替構文を使用して、最も確率の高いモードリストに存在するもの以外のイントラ予測モードを表現する。
マルチプレクサモジュール３８４は決定された最良のイントラ予測モード３８８に従ってＰＵ ３２０を出力し、各候補ＣＵのテストされた予測モードから選択する。候補予測モードは、ビデオエンコーダ１１４によってサポートされるすべての考えられる予測モードを含む必要はない。
予測モードは大きく二つのカテゴリーに分類される。第１のカテゴリは、「イントラフレーム予測」（「イントラ予測」とも呼ばれる）である。イントラフレーム予測では、ブロックに対する予測が生成され、生成方法は現在のフレームから得られた他のサンプルを使用してもよい。イントラ予測されたＰＵの場合、異なるイントラ予測モードが輝度および彩度のために使用されることが可能であり、したがって、イントラ予測は主に、ＰＵではなくＰＢ上での動作に関して説明される。
予測モードの第２のカテゴリは、「インターフレーム予測」（「インター予測」とも呼ばれる）である。インターフレーム予測では、ブロックの予測がビットストリーム内のフレームを符号化する順序で現在のフレームに先行する１つまたは２つのフレームからのサンプルを使用して生成される。
ビットストリーム内のフレームの符号化順は、キャプチャまたは表示時のフレームの順序とは異なる場合がある。１つのフレームが予測に使用される場合、ブロックは「単一予測」であると言われ、１つの関連する動きベクトルを有する。２つのフレームが予測に使用される場合、ブロックは「双予測」されると言われ、２つの関連する動きベクトルを有する。Ｐスライスの場合、各ＣＵは、イントラ予測または単一予測され得る。Ｂスライスの場合、各ＣＵは、イントラ予測、単一予測、または双予測され得る。フレームは、典型的にはフレームの時間的階層を可能にする「ピクチャのグループ」構造を使用して符号化される。フレームの時間的階層は、フレームがフレームを表示する順序で、先行するピクチャおよび後続するピクチャを参照することを可能にする。画像は、各フレームを復号するための依存関係が満たされていることを確認するために必要な順序で符号化される。
インター予測のサブカテゴリは、「スキップモード」と呼ばれる。インター予測およびスキップモードは、２つの別個のモードとして説明される。しかしながら、インター予測モード及びスキップモードの両方は、先行するフレームからのサンプルのブロックを参照する動きベクトルを含む。インター予測は符号化された動きベクトルデルタを含み、動きベクトル予測子に対する動きベクトルを指定する。動きベクトル予測子は、「マージインデックス」で選択された１つ以上の候補動きベクトルのリストから得られる。符号化された動きベクトルデルタは、選択された動きベクトル予測に空間オフセットを提供する。また、インター予測は、ビットストリーム１３３内の符号化された残差を使用する。スキップモードは、インデックス（「マージインデックス」とも呼ばれる）のみを使用して、いくつかの動きベクトル候補のうちの１つを選択する。選択された候補は、さらなるシグナリングなしに使用される。また、スキップモードは、残差係数の符号化をサポートしない。スキップモードが使用されるとき、符号化された残差係数がないことは、スキップモードのための変換を実行する必要がないことを意味する。したがって、スキップモードは、典型的にはパイプライン処理問題を生じない。パイプライン処理問題は、イントラ予測ＣＵおよびインター予測ＣＵの場合であり得る。スキップモードの限定されたシグナリングのために、スキップモードは比較的高品質の参照フレームが利用可能であるときに、非常に高い圧縮性能を達成するために有用である。ランダムアクセスピクチャグループ構造のより高い時間レイヤにおける双予測ＣＵは、典型的には基礎となる動きを正確に反映する高品質の参照ピクチャおよび動きベクトル候補を有する。その結果、スキップモードは、図８Ｂを参照して説明される、ランダムアクセスピクチャグループ構造内のより高い時間レイヤにおけるフレーム内の双予測ブロックに有用である。
サンプルは、動きベクトルおよび参照ピクチャインデックスに従って選択される。動きベクトルおよび参照ピクチャインデックスは、すべてのカラーチャネルに適用され、したがって、インター予測は主に、ＰＢではなくＰＵ上での動作に関して説明される。各カテゴリー内（すなわち、イントラおよびインターフレーム予測）では、ＰＵを生成するために異なる技法を適用することができる。例えば、イントラ予測は、所定のフィルタリング及び生成処理に従ってＰＵを生成する方向と組み合わせて、以前に再構成されたサンプルの隣接する行及び列からの値を使用することができる。あるいは、ＰＵが少数のパラメータを使用して記述されてもよい。インター予測法は、動きパラメータの数とその精度で変わる可能性がある。動きパラメータは通常、参照フレームのリストからのどの参照フレームが使用されるべきかを示す参照フレームインデックスと、参照フレームの各々のための空間変換とを含むが、より多くのフレーム、特別なフレーム、またはスケーリングおよび回転などの複雑なアフィンパラメータを含むことができる。さらに、参照サンプルブロックに基づいて高密度動き推定を生成するために、所定の動き精緻化処理を適用することができる。
最良のＰＵ３２０を決定し、選択し、減算器３２２で元のサンプルブロックからＰＵ ３２０を減算すると、符号化コストが最も低い３２４で表される残差が得られ、損失のある圧縮を受ける。損失性圧縮プロセスは、変換、量子化、およびエントロピー符号化のステップを含む。変換モジュール３２６は差分３２４に順変換を適用し、差分３２４を周波数領域に変換し、矢印３３２で表される変換係数を生成する。順変換は典型的には分離可能であり、行のセットを変換し、次いで、各ブロックの列のセットを変換する。行および列の各組の変換は最初にブロックの各行に１次元変換を適用して部分結果を生成し、次に部分結果の各列に１次元変換を適用して最終結果を生成することによって実行される。
変換係数３３２は、量子化器モジュール３３４に渡される。モジュール３３４では、「量子化パラメータ」による量子化が実行され、矢印３３６によって表される残差係数が生成される。量子化パラメータは所与のＴＢについて一定であり、したがって、ＴＢについての残差係数の生成のための均一なスケーリングをもたらす。「量子化行列」を適用することによって、不均一なスケーリングも可能であり、それによって、各残差係数に適用されるスケーリング係数は、量子化パラメータと、典型的にはＴＢのサイズに等しいサイズを有するスケーリング行列内の対応するエントリとの組合せから導出される。残差係数３３６は、ビットストリーム１１５における符号化のためにエントロピーエンコーダ３３８に供給される。典型的には、ＴＵの少なくとも１つの有意な残差係数を有する各ＴＢの残差係数がスキャンパターンに従って、値の順序付けられたリストを生成するためにスキャンされる。スキャンパターンは一般に、４×４「サブブロック」のシーケンスとしてＴＢをスキャンし、残差係数の４×４セットの粒度で規則的なスキャン動作を提供し、サブブロックの配置は、ＴＢのサイズに依存する。さらに、予測モード３８８および対応するブロック分割もビットストリーム１１５に符号化される。
上述したように、ビデオエンコーダ１１４は、ビデオデコーダ１３４に見られるフレーム表現に対応するフレーム表現にアクセスする必要がある。従って、残差係数３３６も逆量子化器モジュール３４０によって逆量子化され、矢印３４２によって表される逆変換係数を生成する。逆変換係数３４２は、ＴＵの、矢印３５０によって表される残差サンプルを生成するために、逆変換モジュール３４８を通過させられる。加算モジュール３５２は、残差サンプル３５０とＰＵ３２０とを加算して、ＣＵの再構成サンプル（矢印３５４によって示される）を生成する。
再構成されたサンプル３５４は、参照サンプルキャッシュ３５６およびループ内フィルタモジュール３６８に渡される。参照サンプルキャッシュ３５６は、通常ＡＳＩＣ上のスタティックＲＡＭを使用して実現され（したがって、コストのかかるオフチップメモリアクセスを回避する）、フレーム内の後続のＣＵのためのフレーム内ＰＢを生成するための依存関係を満たすために必要な最小限のサンプル記憶装置を提供する。最小依存関係は、典型的にはＣＴＵの行の最下部に沿ったサンプルの「ラインバッファ」を含み、ＣＴＵの次の行および列バッファリングによって使用され、その範囲はＣＴＵの高さによって設定される。参照サンプルキャッシュ３５６は、参照サンプルフィルタ３６０に参照サンプル（矢印３５８で示す）を供給する。サンプルフィルタ３６０は、平滑化演算を適用して、フィルタリングされた参照サンプル（矢印３６２によって示される）を生成する。フィルタリングされた参照サンプル３６２は、イントラフレーム予測モジュール３６４によって使用され、矢印３６６によって表されるサンプルのイントラ予測ブロックを生成する。各候補イントラ予測モードについて、イントラフレーム予測モジュール３６４は、サンプルのブロック、すなわち３６６を生成する。
ループ内フィルタモジュール３６８は、再構成されたサンプル３５４にいくつかのフィルタリング段階を適用する。フィルタリング段階は、不連続性から生じるアーチファクトを低減するために、ＣＵ境界に整列された平滑化を適用する「デブロッキングフィルタ」（ＤＢＦ）を含む。インループフィルタモジュール３６８に存在する別のフィルタリング段階は、「適応ループフィルタ」（ＡＬＦ）であり、これは、歪みをさらに低減するためにウィナーベースの適応フィルタを適用する。ループ内フィルタモジュール３６８における更なる利用可能なフィルタリング段階は、「サンプル適応オフセット」（ＳＡＯ）フィルタである。ＳＡＯフィルタは最初に、再構成されたサンプルを１つまたは複数のカテゴリに分類し、割り当てられたカテゴリに従って、サンプルレベルでオフセットを適用することによって動作する。
矢印３７０で表されるフィルタリングされたサンプルは、ループ内フィルタモジュール３６８から出力される。フィルタリングされたサンプル３７０は、フレームバッファ３７２に記憶される。フレームバッファ３７２は、典型的には、いくつかの（例えば、１６までの）ピクチャを格納するための容量を有し、従って、メモリ２０６に格納される。フレームバッファ３７２は、大きなメモリ消費が要求されるため、通常、オンチップメモリを使用して記憶されない。したがって、フレームバッファ３７２へのアクセスは、メモリ帯域幅に関してコストがかかる。フレームバッファ３７２は、参照フレーム（矢印３７４によって表される）を動き推定モジュール３７６および動き補償モジュール３８０に提供する。
動き推定モジュール３７６は、いくつかの「動きベクトル」（３７８として示される）を推定し、各々は現在のＣＵの位置からのデカルト空間オフセットであり、フレームバッファ３７２内の参照フレームのうちの１つ内のブロックを参照する。参照サンプルのフィルタリングされたブロック（３８２として表される）は、各動きベクトルに対して生成される。フィルタリングされた参照サンプル３８２は、モードセレクタ３８６による潜在的な選択に利用可能なさらなる候補モードを形成する。さらに、所与のＣＵについて、ＰＵ３２０は、１つの参照ブロック（「単一予測」）を使用して形成されてもよく、または２つの参照ブロック（「双予測」）を使用して形成されてもよい。選択された動きベクトルに対して、動き補償モジュール３８０は、動きベクトル内のサブピクセル精度をサポートするフィルタリング処理に従って、ＰＵ３２０を生成する。したがって、動き推定モジュール３７６（多くの候補動きベクトルに対して動作する）は、計算の複雑さを低減するために、動き補償モジュール３８０（選択された候補のみに対して動作する）と比較して、単純化されたフィルタリング処理を実行することができる。
図３のビデオエンコーダ１１４は汎用ビデオ符号化（ＶＶＣ）を参照して説明されるが、他のビデオ符号化規格または実装はモジュール３１０～３８６の処理段階を使用することもできる。フレームデータ１１３（およびビットストリーム１１５）は、メモリ２０６、ハードディスクドライブ２１０、ＣＤ－ＲＯＭ、Ｂｌｕ－ｒａｙディスクＴＭ、または他のコンピュータ可読記憶媒体から読み取る（または書き込む）こともできる。さらに、フレームデータ１１３（およびビットストリーム１１５）は、通信ネットワーク２２０または無線周波数受信機に接続されたサーバなどの外部ソースから受信（または送信）されてもよい。
ビデオデコーダ１３４を図４に示す。図４のビデオデコーダ１３４は、汎用ビデオコーディング（ＶＶＣ）ビデオデコーディングパイプラインの一例であるが、他のビデオコーデックを使用して、本明細書で説明する処理段階を実行することもできる。図４に示すように、ビットストリーム１３３はビデオデコーダ１３４に入力される。ビットストリーム１３３は、メモリ２０６、ハードディスクドライブ２１０、ＣＤ－ＲＯＭ、Ｂｌｕ－ｒａｙディスクＴＭ、または他の一時的でないコンピュータ可読記憶媒体から読み取ることができる。あるいは、ビットストリーム１３３が通信ネットワーク２２０または無線周波数受信機に接続されたサーバなどの外部ソースから受信されてもよい。ビットストリーム１３３は、復号される撮像フレームデータを表す符号化された構文要素を含む。
ビットストリーム１３３は、エントロピーデコーダモジュール４２０に入力される。エントロピーデコーダモジュール４２０は、ビットストリーム１３３から構文要素を抽出し、構文要素の値をビデオデコーダ１３４内の他のモジュールに渡す。エントロピーデコーダモジュール４２０は、ビットストリーム１３３から構文要素を復号するためにＣＡＢＡＣアルゴリズムを適用する。復号された構文要素は、ビデオデコーダ１３４内のパラメータを再構成するために使用される。パラメータは、残差係数（矢印４２４によって表される）と、イントラ予測モード（矢印４５８によって表される）などのモード選択情報とを含む。モード選択情報は、動きベクトル、および各ＣＴＵの１つまたは複数のＣＵへの分割などの情報も含む。パラメータは、典型的には以前に復号されたＣＵからのサンプルデータと組み合わせて、ＰＵを生成するために使用される。
残差係数４２４は、逆量子化器モジュール４２８に入力される。逆量子化器モジュール４２８は、量子化パラメータに従って、矢印４４０によって表される再構成された変換係数を生成するために、残差係数４２４に対して逆量子化（または「スケーリング」）を実行する。不均一な逆量子化行列の使用がビットストリーム１３３に示される場合、ビデオデコーダ１３４は、スケーリングファクタのシーケンスとしてビットストリーム１３３から量子化行列を読み出し、スケーリングファクタを行列に配置する。逆スケーリングは、量子化パラメータと組み合わせて量子化行列を使用して、再構成された中間変換係数を生成する。
再構成された変換係数４４０は、逆変換モジュール４４４に渡される。モジュール４４４は、係数を周波数領域から空間領域に戻すように変換する。ＴＢは、有効残差係数値および非有効残差係数値に事実上基づいている。モジュール４４４の動作の結果は、矢印４４８によって表される残差サンプルのブロックである。残差サンプル４４８は、対応するＣＵとサイズが等しい。残差サンプル４４８は、加算モジュール４５０に供給される。加算モジュール４５０において、残差サンプル４４８は、復号されたＰＵ（４５２として表される）に加算されて、矢印４５６によって表される再構成されたサンプルのブロックを生成する。再構成サンプル４５６は、再構成サンプルキャッシュ４６０およびループ内フィルタリングモジュール４８８に供給される。ループ内フィルタリングモジュール４８８は、４９２として表されるフレームサンプルの再構成されたブロックを生成する。フレームサンプル４９２は、フレームバッファ４９６に書き込まれる。
再構成サンプルキャッシュ４６０は、ビデオエンコーダ１１４の再構成サンプルキャッシュ３５６と同様に動作する。再構成されたサンプルキャッシュ４６０は（例えば、典型的には、オンチップメモリであるデータ２３２を代わりに使用することによって）メモリ２０６を介さずに後続のＣＵをイントラ予測するために必要とされる再構成されたサンプルのための記憶装置を提供する。矢印４６４によって表される参照サンプルは、再構成サンプルキャッシュ４６０から得られ、参照サンプルフィルタ４６８に供給されて、矢印４７２によって示されるフィルタリングされた参照サンプルを生成する。フィルタリングされた参照サンプル４７２は、イントラフレーム予測モジュール４７６に供給される。モジュール４７６は、ビットストリーム１３３でシグナリングされ、エントロピーデコーダ４２０によって復号されたイントラ予測モードパラメータ４５８に従って、矢印４８０によって表されるイントラ予測サンプルのブロックを生成する。
イントラ予測が現在のＣＵのためのビットストリーム１３３において示されるとき、イントラ予測サンプル４８０は、マルチプレクサモジュール４８４を介して復号されたＰＵ４５２を構成する。
インター予測が現在のＣＵのためのビットストリーム１３３において示されるとき、動き補償モジュール４３４は、フレームバッファ４９６からサンプルのブロックを選択してフィルタリングするために、動きベクトルおよび参照フレームインデックスを使用して、４３８として表されるインター予測サンプルのブロックを生成する。サンプル４９８のブロックは、フレームバッファ４９６に記憶された以前に復号されたフレームから得られる。双予測の場合、２つのサンプルブロックが生成され、一緒にブレンドされて、復号されたＰＵ４５２のためのサンプルが生成される。フレームバッファ４９６には、ループ内フィルタリングモジュール４８８からのフィルタリングされたブロックデータ４９２が入力される。ビデオエンコーダ１１４のループ内フィルタリングモジュール３６８と同様に、ループ内フィルタリングモジュール４８８は、ＤＢＦ、ＡＬＦ、およびＳＡＯフィルタリング動作のいずれか、少なくとも、またはすべてを適用する。ループ内フィルタリングモジュール３６８は、再構成されたサンプル４５６からフィルタリングされたブロックデータ４９２を生成する。
図５は、汎用ビデオ符号化のツリー構造内の１つまたは複数のサブ領域への領域の利用可能な分割（divisions）または分割（splits）の集合５００を示す概略ブロック図である。集合５００に示される分割（divisions）は、図３を参照して説明されるように、ラグランジュ最適化によって決定されるように、コーディングツリーに従って各ＣＴＵを１つまたは複数のＣＵに分割するために、エンコーダ１１４のブロックパーティショナ３１０に利用可能である。
集合５００は、正方形領域のみが他の、おそらくは正方形でないサブ領域に分割されていることを示すが、図５００は潜在的な分割を示しているが、包含領域が正方形であることを必要としないことを理解されたい。含有領域が非正方形の場合、分割から生じるブロックの寸法は含有ブロックの縦横比に従ってスケールされる。領域がそれ以上分割されなくなると、すなわち、コーディングツリーのリーフノードにおいて、ＣＵがその領域を占有する。ブロックパーティショナ３１０によるＣＴＵの１つまたは複数のＣＵへの特定のサブ分割は、ＣＴＵの「コーディングツリー」と呼ばれる。領域をサブ領域にサブ分割するプロセスは、結果として生じるサブ領域が最小ＣＵサイズに達したときに終了しなければならない。例えば、４×４より小さいサイズを禁止するようにＣＵを制約することに加えて、ＣＵは、４の最小幅または高さを有するように制約される。幅および高さの両方に関して、または幅または高さに関して、他の最小値も可能である。サブ分割のプロセスは、最も深いレベルの分解の前に終了することもでき、その結果、ＣＵが最小ＣＵサイズよりも大きくなる。分割が起こらず、その結果、単一のＣＵがＣＴＵの全体を占有することが可能である。ＣＴＵの全体を占有する単一のＣＵは、最大の利用可能な符号化単位サイズである。また、分割が発生しないＣＵは、処理領域サイズよりも大きい。コーディングツリーの最高レベルでの２分割または３分割の結果として、６４×１２８、１２８×６４、３２×１２８、および１２８×３２などのＣＵサイズも可能であり、それぞれも処理領域サイズより大きい。図１０Ａ～１０Ｆを参照してさらに説明される処理領域サイズよりも大きいＣＵＳの例。
コーディングツリーのリーフノードには、それ以上の細分化のないＣＵが存在する。例えば、リーフノード５１０は、１つのＣＵを含む。コーディングツリーの非リーフノードには２つ以上のさらなるノードへの分割が存在し、各ノードはリーフノード従って１つのＣＵを含むか、またはより小さな領域へのさらなる分割を含むことができる。
四分木分割５１２は図５に示すように、包含領域を４つの等しいサイズの領域に分割する。ＨＥＶＣと比較して、汎用ビデオ符号化（ＶＶＣ）は、水平２分割５１４および垂直２分割５１６を追加することにより、さらなる柔軟性を達成する。分割５１４および５１６の各々は、包含領域を２つの等しいサイズの領域に分割する。分割は、含有ブロック内の水平境界（５１４）または垂直境界（５１６）に沿っている。
水平３分割５１８および垂直３分割５２０を追加することにより、汎用ビデオ符号化においてさらなる柔軟性が達成される。３分割５１８および５２０は、ブロックを、包含領域の幅または高さの１／４および３／４に沿って水平方向（５１８）または垂直方向（５２０）のいずれかで境界をつけられた３つの領域に分割する。４分木、２分木、および３分木の組合せは、「ＱＴＢＴＴＴ」または代替的にマルチツリー（ＭＴ）と呼ばれる。
四分木のみをサポートし、したがって正方形ブロックのみをサポートするＨＥＶＣと比較して、ＱＴＢＴＴＴは、特に２分木および／または３分木分割の可能な再帰的適用を考慮すると、より多くの可能なＣＵサイズをもたらす。異常な（例えば、非正方形の）ブロックサイズの可能性は、ブロック幅または高さが４サンプル未満であるか、または４サンプルの倍数ではないかのいずれかになる分割を排除するように分割オプションを制約することによって低減され得る。一般に、この制約は、輝度サンプルを考慮する際に適用される。しかしながら、この制約は彩度チャネルのブロックに別々に適用することもでき、例えば、フレームデータが４：２：０彩度フォーマットである場合に、輝度対彩度の最小ブロックサイズが異なることになる可能性がある。各分割では、包含領域に関して辺寸法が変わらない、半分になっている、または４分の１になっているサブ領域が生成される。そして、ＣＴＵサイズは２のべき乗であるため、全てのＣＵの辺寸法も２のべき乗である。
図６は、汎用ビデオ符号化で使用されるＱＴＢＴＴＴ(または「コーディングツリー」）構造のデータフロー６００を示す概略フロー図である。ＱＴＢＴＴＴ構造は、ＣＴＵを１つまたは複数のＣＵに分割することを定義するために、各ＣＴＵに対して使用される。各ＣＴＵのＱＴＢＴＴＴ構造は、ビデオエンコーダ１１４内のブロックパーティショナ３１０によって決定され、ビットストリーム１１５に符号化されるか、またはビデオデコーダ１３４内のエントロピーデコーダ４２０によってビットストリーム１３３から復号される。データフロー６００はさらに、図５に示される分割に従って、ＣＴＵを１つまたは複数のＣＵに分割するためにブロックパーティショナ３１０に利用可能な許容可能な組合せを特徴付ける。
階層の最上位レベル、すなわちＣＴＵから始めて、ゼロまたはそれ以上の四分木分割が最初に実行される。具体的には、四分木（ＱＴ）分割決定６１０がブロックパーティショナ３１０によって行われる。「１」シンボルを返す６１０での決定は、四分木分割５１２に従って現在のノードを４つのサブノードに分割する決定を示す。その結果、６２０などの、４つの新しいノードが生成され、各新しいノードについて、ＱＴ分割決定６１０に戻る。各新しいノードは、ラスタ（またはＺスキャン）順序で考慮される。あるいは、ＱＴ分割決定６１０がさらなる分割が実行されるべきでないことを示す（「０」シンボルを返す）場合、四分木分割は停止し、マルチツリー（ＭＴ）分割がその後考慮される。
まず、ＭＴ分割決定６１２がブロックパーティショナ３１０によって行われる。６１２において、ＭＴ分割を実行する決定が示される。決定６１２で「０」のシンボルを返すことは、ノードのサブノードへのそれ以上の分割が実行されないことを示す。ノードのそれ以上の分割が実行されない場合、ノードはコーディングツリーのリーフノードであり、ＣＵに対応する。リーフノードは６２２で出力される。あるいは、ＭＴ分割６１２がＭＴ分割を実行する決定を示す（「１」シンボルを返す）場合、ブロックパーティショナ３１０は方向決定６１４に進む。
方向決定６１４は、水平（「Ｈ」または「０」）または垂直（「Ｖ」または「１」）のいずれかとしてＭＴ分割の方向を示す。ブロックパーティショナ３１０は、決定６１４が水平方向を示す「０」を返す場合、決定６１６に進む。ブロックパーティショナ３１０は、決定６１４が垂直方向を示す「１」を返す場合、決定６１８に進む。
決定６１６および６１８のそれぞれにおいて、ＭＴ分割のパーティション数は、ＢＴ／ＴＴ分割で２つ（２分割または「ＢＴ」ノード）または３つ（３分割または「ＴＴ」）のいずれかとして示される。すなわち、ＢＴ／ＴＴ分割決定６１６は、６１４からの指示された方向が水平であるときにブロックパーティショナ３１０によって行われ、ＢＴ／ＴＴ分割決定６１８は、６１４からの指示された方向が垂直であるときにブロックパーティショナ３１０によって行われる。
ＢＴ／ＴＴ分割決定６１６は、水平分割が「０」を返すことによって示される２分割５１４であるか、「１」を返すことによって示される３分割５１８であるかを示す。ＢＴ／ＴＴ分割決定６１６が２分割を示す場合、HBT CTUノード生成ステップ６２５において、水平２分割５１４に従って、２つのノードがブロックパーティショナ３１０によって生成される。ＢＴ／ＴＴ分割６１６が３分割を示す場合、HTT CTUノード生成ステップ６２６において、水平３分割５１８に従って、ブロックパーティショナ３１０によって３つのノードが生成される。
ＢＴ／ＴＴ分割決定６１８は、垂直分割が「０」を返すことによって示される２分割５１６であるか、「１」を返すことによって示される３分割５２０であるかを示す。ＢＴ／ＴＴ分割６１８が２分割を示す場合、VBT CTUノード生成ステップ６２７では、垂直２分割５１６に従って、ブロックパーティショナ３１０によって２つのノードが生成される。ＢＴ／ＴＴ分割６１８が３分割を示す場合、VTT CTUノード生成ステップ６２８において、垂直３分割５２０に従って、ブロックパーティショナ３１０によって３つのノードが生成される。ステップ６２５～６２８から生じる各ノードについて、ＭＴ分割決定６１２に戻るデータフロー６００の再帰が、方向６１４に応じて、左から右へ、または上から下への順序で適用される。その結果、２分木および３分木分割を適用して、様々なサイズを有するＣＵを生成することができる。
図７Ａおよび７Ｂは、ＣＴＵ７１０のいくつかのＣＵへの分割例７００を提供する。ＣＵ７１２の一例を図７Ａに示す。図７Ａは、ＣＴＵ７１０におけるＣＵの空間配置を示す。分割例７００は、図７Ｂにコーディングツリー７２０としても示されている。
図７ＡのＣＴＵ７１０内の各非リーフノード、例えばノード７１４、７１６および７１８において、収容されたノード（さらに分割されていてもよいし、ＣＵであってもよい）は、ノードのリストを作成するために「Ｚオーダー」でスキャンまたはトラバースされ、コーディングツリー７２０内のカラムとして表される。４分木分割の場合、Ｚオーダースキャンは、左上から右に続いて左下から右の順序になる。水平分割および垂直分割の場合、Ｚオーダースキャン（トラバーサル）は、それぞれ、上から下へ、および左から右へのスキャンに単純化する。図７Ｂのコーディングツリー７２０は、適用されたスキャンオーダーに従って、すべてのノードおよびＣＵをリストする。各分割は、リーフノード（ＣＵ）に到達するまで、ツリーの次のレベルで２、３、または４個の新しいノードのリストを生成する。
ブロックパーティショナ３１０によって画像をＣＴＵに分解し、さらにＣＵに分解し、図３を参照して説明されるように、各残差ブロック（３２４）を生成するためにＣＵを用いて、残差ブロックは、ビデオエンコーダ１１４によって順変換および量子化される。結果として得られるＴＢ３３６は、その後、エントロピー符号化モジュール３３８の動作の一部として、残差係数の順次リストを形成するためにスキャンされる。同等のプロセスがビットストリーム１３３からＴＢを得るために、ビデオデコーダ１３４内で実行される。
図８Ａは、ＣＴＵのシーケンス、例えば、ＣＴＵ８１２、それに続く後続のＣＴＵを含むフレーム８００の例を示す。各ＣＴＵは、１２８×１２８輝度サンプルのサイズを有する。フレーム８００が、ＣＴＵサイズ、１２８×１２８輝度サンプルのために、プロセッサ２０５のローカルメモリまたは集積回路を使用してＣＴＵごとに処理される場合、結果として生じるローカルメモリ要件は、法外なものとなる。本明細書で説明されるビデオエンコーダ１１４およびビデオデコーダ１３４の実施形態は、ＣＴＵの領域よりも小さい領域で画像データまたはビットストリームを処理することによって、オンチップメモリ消費を低減することができる。オンチップメモリは、ダイ上の大きな面積を消費するので、オンチップメモリは特に高価である。ソフトウェア実装では、より多くのメモリアクセスを低レベルのキャッシュ（Ｌ１キャッシュやＬ２キャッシュなど）に制限し、外部メモリにアクセスする必要性を減らすことによってもメリットがあります。したがって、メモリ消費を低減するために、ビデオエンコーダ１１４およびビデオデコーダ１３４の実装は、一度に１つのＣＴＵの粒度よりも小さい粒度でデータを処理することができる。
より小さい粒度は、ＣＴＵの１つの四分木細分化と同様に、６４×６４輝度サンプルの領域（または「パイプライン処理領域」）サイズとすることができる。さらに、より小さい粒状度は、不可分領域として扱われる領域を定義する。不可分領域は、パイプライン化されたアーキテクチャの各処理ステージを通じて渡される。パイプライン処理領域は、フレーム（フレーム８００など）上の特定のエリアに対応し、パイプラインを通過するデータの１つのアグリゲーションまたはチャンク（サンプル、ブロックおよび係数のコレクション、ビットストリームの一部など）を領域が定義するという意味で、不可分であると見なされる。領域内では、ＣＵの様々な配置が存在し得、ＣＵはより小さい粒度の領域の複数にわたることができる。領域は、各パイプライン処理段階が１２８×１２８のフルＣＴＵサイズに関連するデータとは対照的に、より小さい領域、例えば６４×６４輝度サンプル以下に関連するデータのみを局所的に記憶することを可能にする。
彩度データのための対応するローカルメモリ低減も、上述したパイプライン処理領域を用いて実現される。各ＣＴＵ内で、領域はＺ順に処理される。処理は領域スキャン８１０によって示されるように、ラスタスキャン方式でＣＴＵからＣＴＵに進行する。ビデオデコーダ１３４の観点から、第１パイプライン段階はエントロピーデコーダ４２０である。ビットストリーム１３３は順番に構文解析されるが、構文解析された構文要素は領域に従ってグループ化されてもよい。例えば、図８Ａの領域８１４は、最初にエントロピーデコーダ４２０によって処理される。１つの領域がエントロピーデコーダ４２０によって処理されると、関連する構文要素は第２のパイプライン段階に渡される。第２のパイプライン段階は、逆量子化器４２８および逆変換４４４であってもよい。モジュール４２８および４４４は、領域内のすべてのＣＵに対して実行して、その領域の残差サンプル４４８を生成する。第２段階が完了すると、その領域の残留サンプル４４８は第３段階に渡される。第３段階は、加算４５０（イントラ再構成）、参照サンプルキャッシュ４６０、参照サンプルフィルタ４６８、およびイントラフレーム予測モジュール４７６を含むことができる。第３段階モジュールは図４に示され、これを参照して説明されるように、フィードバックループを形成する。フィードバックループは隣接するＣＵ間に存在し、したがって、領域内および１つの領域から次の領域への両方に存在する。フィードバックループは、第３段階モジュールが１つのパイプライン段階内で実行されることを必要とする。ループ内フィルタリング４８８は、典型的には１つ以上の後続のパイプライン段階において実行される。
フレームバッファ４９６および動き補償モジュール４３４を含む、インター予測のための別個のフィードバックループも実装することができる。しかしながら、インター予測のためのフィードバックループは現在のフレームから先行フレームまでであり、従って、ＣＴＵレベルでのパイプライン動作には影響しない。まだ処理されていない図８Ａの領域、例えば８１６は、ライトシェーディングで示されている。
各ＣＴＵのコーディングツリーによれば、領域は例えば、図７Ａおよび図７Ｂに関して説明したように、様々なサイズの様々なＣＵを含むことができる。図７Ａおよび図７Ｂの例は、図７Ｂに７２６として示されるコーディングツリーの最上位レベルにおける４分木分割を含む。様々なサイズのＣＵにさらに分割される、４つの６４×６４領域への４分木分割は、６４×６４のパイプライン処理領域サイズで調整される。高度に詳細なテクスチャを含み、利用可能な参照画像がない画像フレームを符号化する場合、「イントラ」フレームの場合のように、少なくとも１つの４分木分割が起こる可能性は高い。したがって、イントラフレーム符号化の場合、１２８×１２８のインター予測フレームに使用されるＣＴＵサイズと比較して、より小さいＣＴＵサイズ、たとえば６４×６４を、ユーザに許容できないレベルの圧縮性能ペナルティを課すことなく使用することができる。
より小さいＣＴＵサイズ、特にパイプライン処理のための領域サイズを超えないサイズの使用は、ＣＵがなく、したがってＴＵが複数の領域にまたがらないことを保証する。変換は、各残差係数がＴＢからのすべての出力サンプルに影響を及ぼすように、ＴＢにわたる変換スパン内のデータ依存関係として、１つのパイプライン段階内で実行される必要がある演算である。その結果、変換はパイプライン動作が「アトミック」（さらに分割されない）でなければならない最小レベルを表し、したがって、所与の変換のためのデータは、パイプライン内の１つのパイプライン処理領域またはデータのチャンク内に完全に含まれなければならない。
しかし、パイプライン処理領域内では、各変換が処理領域内に完全に含まれるので、複数のＣＵ、したがって複数の変換が可能である。変換サイズの制限は、処理領域内で遭遇する可能性のある変換の数に対して最悪の場合を設定する。例えば、６４×６４の処理領域で、輝度チャネルを考慮すると、処理領域内で遭遇し得る４×４変換の最大個数は、１６×１６＝２５６である。処理領域内で遭遇し得る８×８変換の最大個数は８×８＝６４などであり、６４×６４変換までは、１つのパイプライン処理領域内で１つだけを実行することができる。同様の計算が彩度チャネルに適用される。
インター予測されたＣＵについては、比較的大きなＣＵが可能となる。高度に一致する参照ブロックを含み得る１つ以上の参照フレームが利用可能であるために、より大きなＣＵの可能性が生じる。ビデオエンコーダ１１４は大きなＣＵを選択し、そうする際に、参照フレームから現在のフレームにサンプルの大きなブロックをコピーすることができる。
インター予測されたＣＵを符号化する１つのアプローチは、「スキップモード」を介するものである。スキップモードで符号化されたＣＵは、有意な残差係数を有さず、「マージインデックス」を使用して選択された、空間的または時間的近傍から対応する動きベクトルを得るように示される。有意な残差係数がないことは、逆量子化または逆変換ステップを実行する必要がないことを意味する。したがって、ＣＴＵ内のスキップモードＣＵの配置は、パイプライン化の結果として制約されず、スキップモードＣＵのＴＵサイズを決定する必要はない。スキップモードＣＵは、パイプライン処理領域に関する特定のＣＵアラインメントの処理に困難をもたらすことはない。スキップモードＣＵは、典型的には高品質参照フレームが、容易にモデル化された動きパラメータと共に利用可能である場合に使用される。したがって、スキップモードＣＵは、デコーダが動きベクトルを正確に予測することができるブロックに対して選択される。動きベクトルは、ＣＵにおける所望の出力に高度に一致する参照ブロックを選択する。
スキップモードの使用は、比較的低い詳細を含む画像の部分に限定されない。高度に詳細なテクスチャを含む画像部分は、コーディングツリーが大きなＣＵサイズで終了し、空間変位を指定するための動きベクトルの符号化が、特にマージインデックスコーディングを介して、高度に効率的であるので、低コストでコピーすることができる。ランダムアクセスピクチャグループ構造のより高い時間レイヤにおけるフレームは、スキップモードが高度の圧縮性能を提供する例である。図６を用いて説明したフレキシブルブロック構造は、例えば１２８×１２８の比較的大きなＣＴＵサイズと組み合わせて、大きなＣＵを各ＣＴＵ内にかなりフレキシブルに配置することを可能にする。したがって、デコーダまたはエンコーダは例えば、典型的には前景オブジェクトと背景オブジェクトとの間の境界で起こるような、動きフィールドの変化に適応することができる。大きなＣＵは、典型的には低ビットレートで普及している。さらに、これらの大きなＣＵは、複数のパイプライン処理領域にまたがることがあり、複数のパイプライン処理領域にまたがることを回避するように制約される必要はない。複数のパイプライン処理領域にまたがることを回避するために制約を適用することは、ＣＴＵサイズの縮小と同等である。ＣＴＵサイズを小さくすると、ＣＵサイズと各ＣＴＵ内の配置の両方の柔軟性が制限され、圧縮効率が低下するため好ましくない。
図８Ｂは、ビデオ内のフレームの例示的な「ランダムアクセス」ピクチャグループ（ＧＯＰ）構成８５０である。１７フレームのシーケンスが示されている。各フレームについて、表示順序８５１、符号化順序８５２、および時間レイヤＩＤ８５３が構成８５０に示されている。ビデオは、イントラフレーム８６０から始まる。参照ピクチャバッファは空であるので、イントラフレーム８６０は、イントラ予測されたＣＵのみを含むことができる。符号化される第２のフレームは、（符号化順序８５２の第２の値が「１６」であるので）単一予測フレーム（Ｐスライス）８７０である。単一予測フレーム８７０は、イントラフレーム８６０に続いて符号化され、矢印８７２によって示されるように、フレーム８６０のみを参照することができる。しかしながら、フレーム８７０の表示順序は１６であるので、フレーム８６０と８７０との間のコンテンツの比較的大きな変化がありそうである。したがって、フレーム８７０の符号化コストは比較的高いが、フレーム８７０の符号化コストは、参照フレームが利用できないイントラフレーム８６０の符号化コストよりも低い。
中間フレームは、利用可能な参照フレームに対する２つの矢印、例えば、図８Ｂの矢印８９１および８９２を有する各フレームによって示されるように、双予測を使用することができる。より高い時間レイヤでは、フレームから対応する参照フレームまでの距離（表示順序におけるデルタ）はより小さい。一般に、フレームから対応する参照フレームまでの距離が小さいほど、フレーム間で基礎となる画像データの変化が少ないほど、圧縮性能が高くなる。より高い時間レイヤにおけるフレームは一般に、より大きなＣＵの両方を使用することができ、スキップモードをより頻繁に使用することができる。隠蔽されたオブジェクトが見えるようになる場合は例外である。遮蔽されたオブジェクトが見えるようになると、通常、ＧＯＰ（ｇｒｏｕｐ－ｏｆ－ｐｉｃｔｕｒｅｓ）構造の制約内の利用可能な参照ブロックは存在せず、イントラ予測を伴うより小さいＣＵの使用は、より可能性が高くなる。
図９は、輝度チャネルのためのＶＶＣ規格のサポートされる変換サイズの集合９００を示す。輝度チャネルのためにサポートされる変換サイズは、以下の通りである：４×４、４×８、４×１６、４×３２、８×４、８×８、８×１６、８×３２、１６×４、１６×８、１６×１６、１６×３２、３２×４、３２×８、３２×１６、３２×３２、６４×６４。４：２：０彩度フォーマットを使用する彩度チャネルについては、各輝度変換サイズについて、対応する彩度変換サイズが利用可能である。彩度変換サイズは、輝度変換サイズの幅および高さの半分を有する。２次元（２Ｄ）変換は分離可能であり、１次元（１Ｄ）ＤＣＴ－２変換のいずれかが水平と垂直の両方で実行される。あるいは、変換の水平および垂直段階に対して独立して制御可能な１Ｄ ＤＣＴ－７変換と１Ｄ ＤＳＴ－７変換との間の選択を実行することができる。
一般に、１つのＴＵがＣＵに関連付けられる。各カラーチャネルに対して、１つのＴＢがＴＵに関連付けられる。しかしながら、特定のカラーチャネルの変換のための有意な係数がない場合、カラーチャネルのためのＴＢは存在しないと言うことができる。残差係数の全ゼロアレイに対して変換を行う必要がないので、色チャネルは存在しないと言われる。１次元（１Ｄ）変換は、典型的には行列乗算演算に関して定義されるが、バタフライステップおよびリフティングステップを使用する実装は典型的には複雑さを低減するために使用される。アプリケーションの水平および垂直段階のために、各１Ｄ変換内および２Ｄブロックにわたる依存関係が存在する。したがって、各残差サンプルは、（逆変換の観点から）各残差係数によって影響され、対応する関係が順変換のために存在する。

順変換または逆変換を実行する作業は、例えば、ＴＢの半分を変換し、後に残りの半分を変換するために、セクションに分割することはできない。ＴＢの半分を決定する計算コストは、ＴＢ全体を決定するコストとほぼ同じである。したがって、セクション内の変換を決定するアーキテクチャは、（処理パイプラインの観点から）変換を「アトミック」（不可分）演算として決定するアーキテクチャよりもかなり高い複雑性を有する。対照的に、ＰＵはセクションで処理される場合、以下に説明するように、セクションサイズ対全体のＰＵサイズにほぼ比例する各セクションのコストを有する。
複数のパイプライン処理領域にわたる大きなＣＵをサポートするために、イントラ予測およびインター予測の場合のデータ依存関係が考慮される。イントラ予測の場合、予測ブロックは、空間的に隣接する参照サンプルおよびイントラ予測モードを用いて生成される。ＣＵがパイプライン処理領域サイズよりも大きい場合、パイプライン処理領域上で動作する予測パイプライン段階が（１つの領域について）部分ＰＢを計算し、（後続の領域について）追加の部分ＰＢを決定し、部分ＰＢが集合的にＰＢ全体を形成するように、ＰＵを複数の部分で決定することができる。
イントラ予測ブロックについて、部分ＰＢを決定することは、ＰＢのための参照サンプルを使用することを必要とする。参照サンプルは、部分ＰＢに隣接する必要はない。例えば、１２８×６４のＰＢが分割され、２つの６４×６４の部分ＰＢとして処理される。結果として得られる第２（右端の）６４×６４部分ＰＢは、第２の６４×６４部分予測ブロックの位置に存在する６４×６４予測ブロックで使用される参照サンプルではなく、オリジナルの（完全である）１２８×６４ＰＢに対応する参照サンプルを使用する。その結果、ＣＴＵサイズの粒度よりも小さい粒度で動作するパイプライン処理アーキテクチャは、部分ＰＢのための余分な参照サンプルをバッファリングする追加のコストを伴って、パイプライン処理領域サイズよりも大きいＰＢに対してイントラ予測を実行することができる。追加のバッファリング参照サンプルは、ＣＴＵの幅に従ってサイズ設定されたサンプルの行および列であるが、追加のフレーム幅のラインバッファは必要とされない。
インター予測ブロックの場合、使用される共通情報が動きベクトルおよび参照フレームインデックス／インデックスを含むので、ＰＵを複数の部分ＰＵに分割することは比較的単純である。したがって、ＰＵは複数のパイプライン処理領域にわたり、複数の部分ＰＵとして処理されてもよく、各部分ＰＵは、別個のパイプライン処理領域内に含まれる。複数のＰＵが複数のパイプライン処理段階にまたがっている場合であっても、複数のパイプライン処理領域にわたって使用するために関連する動きベクトルを記憶するコストは低い。インター予測のために大きなＰＵを使用することは、低ビットレートアプリケーションにとって、特に、「ランダムアクセス」などのピクチャグループ（ＧＯＰ）構造が使用される場合、より高いレベルにおいて非常に有益である。このようなピクチャグループ構造では、特に動きの少ない領域では、比較的大きなＰＵを使用することができる。大きなＰＵを使用すると、ビットストリームに存在する最小限の構文で全体像の比較的大きな部分がエンコードされる。
図１０Ａは、コーディングツリーの最上位レベルに垂直３分割を有し、それ以上の分割を有さないＣＴＵ１０００のＣＵおよびＴＵを示す。コーディングツリーを分割すると、それぞれ３２×１２８，６４×１２８，３２×１２８のサイズの３つのＣＵ１０２０，１０２２，１０２４が得られる。ＣＵ１０２０、１０２２、および１０２４は、それぞれオフセット（０、０）、（３２、０）、および（９６、０）でＣＴＵ内に位置する。各ＣＵについて、同じサイズの対応するＰＵが存在し、ＣＴＵ１０００において、対応するＰＵは、複数のパイプライン処理領域にわたる。１つまたは複数のＴＵもまた、各ＣＵに関連付けられる。
ＣＵサイズが変換サイズの１つに等しい場合、１つのＴＵがＣＵに関連付けられ、対応するサイズの変換に等しいサイズを有する。
図１０Ｂは、図１０ＡのコーディングツリーのＣＵに関連するＴＵの代替配置を有するＣＴＵ１０４０を示す。ＣＵサイズが変換サイズのいずれよりも大きい場合、複数のＴＵは、ＣＵの全体を占有するように「タイル状」に配置される。タイリングは、幅および高さの制約が与えられると、ＣＵ内で「適合」する最大の利用可能な変換を使用する。例えば、図１０Ｂに示すように、３２×１２８ ＣＵ１０４２および３２×１２８ ＣＵ１０４６は、タイル状に４つの３２×３２ＴＵを使用する。６４×１２８ ＣＵ１０４４は、６４×６４がＣＵ１０４４に利用可能な最大の変換サイズであるので、タイル状に２つの６４×６４ＴＵを使用する。上述のように、ＣＴＵ１０４０を分割することは、イントラ予測動作またはインター予測動作のいずれについても性能に関して問題を提起しない。しかしながら、関連するＴＵの処理は、パイプライン処理領域サイズの調整を必要とする。
図９を参照して説明したように、利用可能な変換サイズは、サイズの特定のセットに限定される。符号化または復号のための各ＴＢの処理は、パイプライン処理アーキテクチャの観点からは不可分の操作である。ＣＴＵ内のＣＵの様々な配置に適応する必要性、および１つのパイプライン段階内の領域について各変換を完全に実行する必要性のために、２つのアプローチが以下に記載される。
第１のアプローチでは、パイプライン処理領域が常に固定サイズ（例えば、６４×６４）であるとは限らない。その代わりに、パイプライン処理領域のサイズは、各ＣＴＵのコーディングツリーに適応する。したがって、第１のアプローチは、「フレキシブルパイプライン処理領域」と呼ぶことができる。用語「フレキシブルパイプライン処理領域」は、領域の固定サイズの場合と区別するために使用され、したがって、本開示の他の箇所で説明されるように、パイプライン処理領域の固定グリッドが画像フレーム内に存在する。特に、フレキシブルパイプライン処理領域を使用して、ＣＴＵ１０４０は、以下のように処理することができる：
領域０：３２×６４（ＣＵ１０４２の上半分は、２つの３２×３２ＴＵを含む）。
領域１：６４×６４（ＣＵ１０４４の上半分は、１つの６４×６４ＴＵを含む）。
領域２：３２×６４（ＣＵ１０４６の上半分は、２つの３２×３２ＴＵを含む）。
領域３：３２×６４（ＣＵ１０４２の下半分は、２つの３２×３２ＴＵを含む）。
領域４：６４×６４（ＣＵ１０４４の下半分は、１つの６４×６４ＴＵを含む）。
領域５：３２×６４（ＣＵ１０４６の下半分は、２つの３２×３２ＴＵを含む）。
したがって、ＣＴＵ１０４０内のＣＵの配置は、３２×６４および６４×６４のサイズの６つのフレキシブルパイプライン処理領域をもたらす。これは、フレキシブルパイプライン処理領域の数に対する最悪の場合である。
ＴＵがフレキシブルパイプライン処理領域境界にまたがらない場合（例えば、図７Ａの例のように、四分木分割のため）、フレキシブルパイプライン処理領域の数は４個であり、各々は６４×６４輝度サンプルのサイズを有する。フレキシブルパイプライン処理領域アプローチは、パイプライン化された実装においてＣＴＵにおけるＴＵの柔軟な配置を可能にするが、パイプラインの最悪の場合の処理速度は、パイプライン処理領域が各ＣＴＵにわたって、したがって画像フレームにわたって固定された配置を有するアーキテクチャと比較して、この例では５０％増加する。全体のサンプルレートは変化しないが、パイプラインアーキテクチャでは、個々の領域の処理レートが必ずしも領域サイズにのみリンクされず、したがって、より小さい領域は必ずしも、それらのより小さいサイズに比例するより高いレートで処理されるわけではなく、各領域を処理するオーバーヘッドのために、より低いレートで処理される。したがって、設計の最悪の場合は、すべての領域が同じサイズであるシステムの場合よりも高い。さらに、図１０Ｃを参照して説明されるように、フレキシブル処理領域がＣＴＵ当たり７つの領域を必要とする場合も存在し、このようなアーキテクチャの最悪の場合の領域レートをさらに増加させる。
第２のアプローチでは、「大きい」ＣＵ（利用可能な変換の幅または高さを超えるＣＵ）のタイリングアプローチが拡張されるように、ＣＵとＴＵとの間の関係が変更される。タイリングアプローチは、さもなければ複数のパイプライン処理領域にまたがるＴＵを有するＣＵにも適用されるように拡張される。例えば、ＣＵ１０２２は、３２×３２ＴＵの２×４アレイに分割される。より小さなＴＵへのＣＵ（１０２２）の分割は、ビットストリーム内にさらなる信号（例えば、追加のフラグ）を存在させる必要なしに、コーディングツリーと、ＣＴＵ内のＣＵのコーディングツリーの配置と、によって分割が決定されるという点で、暗黙的である。むしろ、分割はコーディングユニット自体の暗黙の特性に基づいて決定することができ、これはコーディングユニットの次元である。コーディングユニット１０２２の分割は、図１０ＡのＣＴＵ１０００の以下のパイプライン処理を可能にする：
領域０：６４×６４（ＣＵ１０２０の上半分、ＣＵ１０２２の上左４半分、全部で４つの３２×３２ＴＵ）。
領域１：６４×６４（ＣＵ１０２２の右上４半分、ＣＵ１０２４の上半分、全部で４つの３２×３２ＴＵ）。
領域２：６４×６４（ＣＵ１０２０の下半分、ＣＵ１０２２の左下４半分、全体で４つの３２×３２ＴＵ）。
領域３：６４×６４（ＣＵ１０２０の右下４半分、ＣＵ１０２２の下半分、全部で４つの３２×３２ＴＵ）。
したがって、第２のアプローチを使用すると、コーディングツリーにかかわらず、１２８×１２８ＣＴＵは、４つの６４×６４パイプライン処理領域を使用して常に処理される。変換ユニットの形状および／またはアスペクト比は、ＣＵの形状またはサイズとは異なる。パイプライン処理領域の処理速度は、結果として、ＣＴＵ内のＣＵの配置にかかわらず一定である。第２のアプローチでは、６４×６４ＴＵが左上の位置が画像フレームの左上隅に対して６４×６４格子に整列されているＣＵに対してのみ可能である。２５６×２５６ＣＵを有する分割操作を有さないコーディングツリーを有するＣＴＵ、または水平方向および垂直方向のそれぞれに多くとも１つの２分割を有するコーディングツリー（サイズ１２８×６４、６４×１２８、または６４×６４のＣＵを与える）、または単一の四分木分割（それぞれサイズ６４×６４の４つのＣＵを与える）を有するＣＴＵに対して、必要なコーディングユニット条件が生じる。
第３のアプローチでは、６４×６４ＴＵがビデオエンコーダ１１４およびビデオデコーダ１３４には存在せず、したがって、利用可能なＴＵサイズのセットには存在しない。６４×６４ＴＵは、比較的まれにしか使用されない。しかしながら、６４×６４ＴＵは非常に低いビットレートにおいて有益であり得、したがって、６４×６４変換サイズの欠如はＶＶＣ標準に対して圧縮性能ペナルティを課す。しかしながら、６４×６４変換を除去しても、ＣＵが複数のパイプライン処理領域にまたがるときのＴＵのタイリングが依然として必要とされる。例えば、図１０Ｅに示されるＣＴＵ１０３００は、２つの垂直３分割結果を有するコーディングツリーを有する。２つの垂直３分割は、ＣＴＵの中心に沿って垂直に配向されたサイズ３２×１２８のＣＵ１０３２０をもたらす。ＣＵ１０３２０は、ＣＴＵ１０３００の左上隅に対してオフセット（４８，０）に配置される。ＣＵ１０３２０は４つの６４×６４パイプライン処理領域の各々を占有し、比較的小さいＴＵを使用する。
図１０Ｅは、フレキシブルパイプライン処理領域の（第１の）アプローチに従って領域に分割されたＣＴＵ１０３００を示す。コーディングツリーは、３２×６４輝度サンプルの２つの追加領域を使用して適応させることができる２つの垂直３分割を有する。追加領域の各々は、２つの３２×３２ＴＵ（ＣＵ１０３２０内の１×４列として全体的に配置される）を含むことができ、４つの領域は４８×６４輝度サンプルを占有する。ＣＴＵ１０３２０の結果として生じる分割は、図１０Ｅの領域境界１０３３０によって示される。第１のアプローチでは、ＣＵ内のＴＵのタイリングは、変換サイズの利用可能性によってのみ制約される。最大の利用可能なサイズは、ＣＵをＴＵでタイル化するために使用される。
図１０ＦはＣＴＵ１０４００を示している。ＣＴＵ１０４００は、さらなるタイリングＴＵの第２のアプローチに従って領域に分割されたＣＴＵ１０３００に関する。図１０Ｆの例では、３２×１２８ＣＵ１０４２０（ＣＵ１０３２０に対応する）が３２×３２ＴＵの１×４アレイの代わりに、１６×３２ＴＵの２×４アレイに関連付けられる。１６×３２ＴＵの２×４アレイは、領域境界１０４３０によって示されるように、ＣＴＵの４つのパイプライン処理領域のうちの１つに含まれる各ＴＵをもたらす。図１０Ｆの例では、ＴＵは境界１０４３０を横切らず、ＴＵが２つ以上のパイプライン処理領域に重複または広がらないことを意味する。２つの垂直３分割を有するコーディングツリーの例は、複数のパイプライン処理領域にわたるＴＵを回避するために、ＣＵを複数のＴＵに分割する結果となる様々なコーディングツリーが可能であることを示す。さらに、例示的なケースは、６４×６４ＴＵを伴うものに限定されない。（第２の）アプローチでは、ＣＵ内のＴＵのタイリングが各ＴＵが複数のパイプライン処理領域にまたがらないという要件によってさらに制約される。結果として、使用されるよりも小さいＴＵが使用され、最大の利用可能な変換サイズは、ＣＵ内のＴＵのタイリングに対する制約であった。所与のサイズのブロックにわたって残差サンプルを非相関化するために変換が使用されるので、より小さいＴＵの使用は、より低い圧縮性能をもたらすことが期待され得る。しかしながら、インター予測されたＣＵについては、場合によってはより低い圧縮性能は生じない。単一の変換は、変換の比較的少ない基底関数にマッピングする値を含む残差サンプルを非相関化するのに効率的である。したがって、単一の変換は典型的には低周波数の残差サンプル、すなわち、周波数領域においてＴＢの左上隅に向かって位置する残差サンプルを非相関化するのに効率的である。しかしながら、コンピュータグラフィックスまたはテキストのような高度に不連続なコンテンツを含むか、またはブロックの一部分に集中したコンテンツを含む残差サンプルは、全ての基底関数がＴＢの全体に及ぶので、相関解除が不十分である。
残差サンプルがＣＵの一部分に集中する場合はインター予測ブロックに共通であり、例えば、前景と背景との間の境界のような差から生じる。一般に、より大きなブロックの使用は、改善された圧縮性能をもたらすが、前景および背景（または他の同様の境界）に及ぶブロックももたらす。前景と背景が異なる動きを有する場合、典型的には、ＣＵの１つの部分が（ゼロまたはゼロに近い値を有する残差サンプルを有する）参照ピクチャから良好に予測される。対照的に、ＣＵの別の部分は、参照ピクチャからはあまり予測されない。
１つの解決策は、ビデオエンコーダ１１４がコーディングツリーをさらに分割し、より小さいＣＵをもたらすことである。より小さいＣＵの各々は、基礎となる画像特徴により良く適応するために、異なる予測モードを割り当てられてもよい。オブジェクト境界において、または遮蔽された領域が見えるようになる場合、動き探索は一般に、適切なインター予測されたＣＵを見つけることができない。代わりに、イントラ予測が典型的に使用される。ＣＵ内のＴＵのタイリングは、個々の残差係数の影響の空間的範囲を、対応するＴＢのサイズに制限する。したがって、ＣＵ内のタイル状ＴＵの使用は、より大きなＣＵの選択を可能にすることができる。より大きなＣＵは、画像フレーム内の遮蔽された、前景および／または背景オブジェクトにわたるＣＵであってもよい。次いで、パイプライン処理領域境界によるＴＵのさらなるタイリングは、圧縮性能を過度に劣化させることはなく、ビデオエンコーダ１１４による場合よりも大きなＣＵの選択により利点さえも提供し得る。
図１０Ｃは、反対方向に２つの３分割を有するコーディングツリー１０１００に関連するＴＵを示す。垂直方向の第１の３分割は、３つの領域１０１０１、１０１０２、および１０１０３をもたらす。中間領域１０１０２はさらに、水平方向に３分割され、その結果、追加領域が得られる。特に、６４×６４のＣＵ１０１２２は、領域１０１０２におけるさらなる３分割から生じる。ＣＵ１０１２２は、ＣＴＵ１０１００の左上隅に対して（３２，３２）のオフセットに配置されている。ＣＵ１０１２２は、処理領域境界１０１１０から見られるように、４つのパイプライン処理領域にまたがる。
ＣＵ１０１２２のために６４×６４変換が使用される場合、７つの処理領域が必要とされ、ＣＵ１０１２２のためのサイズ６４×６４の１つの領域と、ＣＴＵ内の残りの領域を処理するための別の６つの領域（サイズ３２×６４の２つおよびサイズ６４×３２の４つ）とから構成される。通常の４つのパイプライン処理領域を超える実質的な増加が生じるので、６４×６４の変換サイズは、ＣＵ１０１２２に適していない。したがって、４つの３２×３２変換が、ＣＵ１０１２２の残差を符号化するために使用される。
図１０Ｄは、同一方向に２つの３分割を有し、対向方向に中間２分割を有するＣＴＵ１０２００のためのコーディングツリーに関連するＴＵを示す。ＣＴＵ１０２００のコーディングツリーの結果として、サイズ３２×６４のＣＵ１０２２２は、ＣＴＵ１０２００の左上隅に対して位置（０，４８）に位置する。ＣＵ１０２２２は、各領域がＣＵ１０２２２の１６×６４部分を含むように、２つのパイプライン処理領域にまたがる。図９の利用可能な変換サイズに基づいて、１６×３２のサイズが使用され、ＣＵ１０２００を占有するように２×２の方法でタイリングされる。次に、パイプライン化された実装は、境界１０２１０によって示されるように描かれた領域においてＣＴＵを処理することができる。さらに、パイプライン化された実装は、１つの領域の一部としてのＣＵ１０２２２の左端の２つの変換のための処理と、別の領域の一部としてのＣＵ１０２２２の右端の２つの変換のための処理と、を別々に実行することによって、ＣＵ１０２００を処理することができる。
イントラ用のタイリングされたＴＵは、各ＴＵ境界で再構成を実行することができる。各ＴＵ境界で再構成を行うと、各ＣＵ内の付加的なフィードバックループのために複雑さが増す。しかしながら、各ＴＵ境界で再構成を実行することは、より小さいＣＵを選択する代替案が同じ重大度のフィードバックループをもたらしたので、最悪の場合の複雑さを増加させない。インター予測されたＣＵについては、追加のフィードバックループは存在しない。
図１１は、コーディングツリーユニットのコーディングツリーにおけるコーディングユニットの予測モードを決定するための方法１１００を示している。方法１１００は、ビデオエンコーダ１１４およびビデオデコーダ１３４のパイプライン化された実装を実現することを可能にする。ＣＴＵのコーディングツリーを決定する際に、ビデオエンコーダ１１４は図６に関連して説明したように、コーディングツリーを決定するための探索を実行する。ＣＴＵの各「候補領域」がさらに分割されるのではなくＣＵを含むオプションは、リーフノード生成ステップ６２２によってテストされる。ステップ６２２で、方法１１００が呼び出されて、１つまたは複数の候補ＣＵが生成される。各候補ＣＵは、ＣＴＵの領域に対する最良の候補ＣＵと、領域をさらに分割することとの比較に基づいて評価される。分割から得られる最良の候補ＣＵを考慮する際に、結果として得られるＣＵのコーディングツリーおよび予測モードの両方が決定される。すなわち、「最良の」候補ＣＵが、ビットストリーム１１５において使用されるように選択される。ビデオエンコーダ１１４およびビデオデコーダ１３４の構成は、例えば、ＣＵサイズおよび／または時間レイヤＩＤなどの態様に基づいて、特定のＣＵのための利用可能な予測モードを制限し得る。制限は、予測モードの決定に影響を及ぼす。さらに、制限は特にステップ１２２２および１３２２に関して図１２および１３を参照して説明したように、影響を受けたＣＵのための必要な予測モードシグナリングも低減する。方法１１００は、構成されたＦＰＧＡ、ＡＳＩＣ、またはＡＳＳＰなどの装置によって実施され得る。さらに、方法１１００は、プロセッサ２０５の実行下でビデオエンコーダ１１４によって実行されてもよい。そのようなものとして、方法１１００は、コンピュータ読み取り可能な記憶媒体および／またはメモリ２０６に記憶することができる。各候補領域に対して呼び出される方法１１００は、スライスタイプテストステップ１１１０で開始する。
スライスタイプテストステップ１１１０において、プロセッサ２０５は、ビデオデータ１１３の現在のフレームのスライスをテストする。一般に、スライスタイプはＧＯＰ構造、例えば、図８ＢのランダムアクセスＧＯＰ構造から生じる。スライスタイプがイントラ（「Ｉ」）スライスの場合、イントラ候補ＣＵ１１５０は、評価のために追加される。スライスタイプがインター（「Ｐ」または「Ｂ」）スライスである場合、方法１１００は、ステップ１１１０から候補ＣＵサイズテストステップ１１２０に進む。
候補ＣＵサイズテストステップ１１２０において、プロセッサ２０５は、ＣＵのサイズをテストして、ＣＵがスキップモードを使用して符号化されることのみが可能であるべきかどうか、または他の予測モードも利用可能であるべきかどうかを決定する。ＣＵのいずれかの辺の長さ（すなわち、幅または高さ）が６４を超える場合、ステップ１１２０は「大きい」を返し、評価のためだけにスキップモード候補１１７０が追加される。ステップ１１２０で「大きい」を返すことは、ＣＵがステップｓ１２１０および１３１０に関連して説明される処理領域にオーバラップすることを推論する。ＣＵが垂直３分割の結果である場合、オーバーラップは垂直であってもよい。ＣＵが垂直３分割の結果である場合、オーバーラップは垂直であってもよい。
いずれかのサイズ長が６４を超えるＣＵについての評価のために１つのモードのみが追加されるので、６４を超えるサイド長のＣＵについてのスキップフラグを符号化または復号する必要はない。ＣＵのサイズがビデオデコーダ１３４がＣＵの予測モードを決定するのに十分であるため、スキップフラグを符号化または復号する必要はない。さらに、１２８×１２８のＣＴＵサイズに対して、６４を超えるサイズ長のＣＵをスキップとして符号化することは、そのような大きなＣＵに対して生じるパイプライン問題を防止するだけである。パイプライン問題はＣＵ内の追加のＴＵタイリングによって対処されるように、より小さなサイズのＣＵに対して依然として生じ得る。大きなＣＵに対してのみスキップコードを可能にすることはＣＵのための予測モードを選択するためのビデオエンコーダ１１４の柔軟性を制限するように思われるが、さらなるスプリットを実行する能力は、そわなければより大きなＣＵが配置されることになるより小さなＣＵをもたらすことが利用可能である。さらに、ＰまたはＢスライスにおいてイントラＣＵが望ましい場合、オクルージョンされたオブジェクトはオクルージョンされた領域の輪郭に従うために、より小さいサイズのＣＵを必要とする傾向があるので、オクルージョンされたオブジェクトがビデオシーケンスにおいて見えるようになる可能性が高い。ステップ１１２０は、ＣＵのどちらの辺の長さも６４を超えていない場合には、「通常」に戻る。その結果、候補ＣＵについて、イントラ候補モード１１５０、インター候補モード１１６０、およびスキップモード候補１１７０のそれぞれが評価される。
ＣＵについての候補予測モードの評価、すなわち１１５０、１１６０、および１１７０のうちの１つまたは複数の評価の後、最良のモードが候補ＣＵとして選択される。「最良」候補予測モードは、最低レートまたは歪みコストに基づいて選択される。図６を参照して説明したようなコーディングツリーのトラバースにより、分割から生じるＣＵの総コストと、包含領域内の１つのＣＵと、の比較により、コーディングツリーの決定が可能になる。
方法１１００の別の構成では、所与のＣＵに対するテストスキップモードのみに対する制限が、ＣＵがＣＴＵの３分割の結果である場合に限定される。例えば、ＣＵがサイズ３２×１２８、６４×１２８（分割の中心ＣＵ、４つのパイプライン処理領域にわたる）、１２８×３２、または４つのパイプライン処理領域にわたる１２８×６４（分割の中心ＣＵ）の場合に、テストモードへの制限が行われる。テストスキップモードへの制限は、複数の予測モードがテストされるので、スキップモードが推論されるケースの数を減少させ、ＣＵに対してシグナリングされる最良のものはＣＴＵの２分割から生じる。言い換えると、サイズ６４×１２８または１２８×６４のＣＵは、いずれも、複数のパイプライン処理領域にわたるＴＵをもたらさず、使用される。以下に説明される、図１２のステップ１２２２および図１３のステップ１３２２は、それに応じて変化される。
方法１１００のさらに別の構成では、テストスキップモードのみに対する制限がＣＴＵの３分割の中心ＣＵに制限される。すなわち、この制約は、６４×１２８ＣＵ（４つのパイプライン処理領域にわたる分割の中心ＣＵ）、または４つのパイプライン処理領域にわたる１２８×６４ＣＵ（分割の中心ＣＵ）に適用される。以下に記載される、図１２のステップ１２２２および図１３のステップ１３２２は、それに応じて変化される。
図１２は、ＣＴＵのコーディングツリーの結果として生じるＣＵをビットストリーム１１５に符号化するための方法１２００のフローチャート図であり、この方法は、パイプライン処理領域のサイズがＣＴＵのサイズよりも小さく、方法がパイプラインアーキテクチャで実行され得るように選択された変換サイズを有する。方法１２００では、各変換が処理グリッドに従って定義された領域内で全体的に処理され得るように、変換サイズが選択される。方法１２００は、構成されたＦＰＧＡ、ＡＳＩＣ、またはＡＳＳＰなどの装置によって実施され得る。さらに、方法１２００は、プロセッサ２０５の実行下でビデオエンコーダ１１４によって実行されてもよい。そのようなものとして、方法１２００は、コンピュータ読み取り可能な記憶媒体および／またはメモリ２０６に記憶することができる。方法１２００は、処理領域決定ステップ１２１０においてプロセッサ２０５から開始する。
処理領域決定ステップ１２１０において、ビデオエンコーダ１１４は、プロセッサ２０５の実行下で、画像フレームの分割を、画像フレームの全体を占める等しいサイズおよび正方形の処理領域の格子に決定する。処理領域は、ＣＴＵのサイズよりも小さいサイズを有する各画像フレームの部分を定義する。例えば、１２８×１２８のＣＴＵサイズでは処理領域サイズは６４×６４であってもよく、６４×６４のＣＴＵサイズでは処理領域サイズは３２×３２であってもよい。これらの場合の各々において、各ＣＴＵは、２×２アレイに配置された４つのパイプライン処理領域に分割される。処理領域の処理順序は、Ｚ順に設定される。Ｚ順スキャンの使用は、ＣＴＵ内のＣＵのスキャン順序と一致しており、したがって、１つのパイプライン処理領域から次に進むときにデータ依存関係が満たされることを保証するために必要な順序に整列される。ステップ１２１０は、画像フレームを複数の等しいサイズの処理領域に分割するように動作し、等しいサイズの処理領域のそれぞれは、ビットストリームを符号化するパイプラインの単一段階の間に処理されるブロックである。プロセッサ２０５内の制御は、ステップ１２１０からコーディングツリー符号化ステップ１２１５に進む。
コーディングツリー符号化ステップ１２１５において、ブロックパーティショナ３１０はプロセッサ２０５の実行下で、方法１１００によって決定されるように、ＣＴＵのためのコーディングツリーをビットストリーム１１５に符号化する。コーディングツリーは図５および図６を参照して説明したように、図７Ａおよび図７Ｂの例を使用して、一連の分割に従ってＣＴＵを１つまたは複数のＣＵに分解する。方法１１００では、ブロックパーティショナ３１０が図３を参照して説明したように、復号画像の忠実度を維持しながら、ＣＴＵが高い圧縮比で符号化されることを可能にする特定のコーディングツリーに到達するために、分割の多くの異なる組合せをテストした。方法１１００は、コーディングツリーを決定することによって、各コーディングユニット（ＣＵ）のサイズを効果的に決定する。プロセッサ２０５内の制御は、ステップ１２１５からＣＵ選択ステップ１２２０に進む。
ＣＵ選択ステップ１２２０において、ブロックパーティショナは、プロセッサ２０５の実行下で、ＣＴＵのコーディングツリーの１つのＣＵが選択される。ＣＵを符号化する場合、ステップ１２２０は、ステップ１２１５の符号化コーディングツリー内のＣＵごとに実行される。選択されたＣＵは、画像フレーム内の特定のサイズおよび位置を有し、したがって、収容しているＣＴＵの左上隅に対する位置を有する。したがって、選択されたＣＵは、包含するＣＴＵ内の所与の領域を占有すると言うことができる。プロセッサ２０５における制御は、ステップ１２２０から予測モードテストおよび符号化ステップ１２２２に進む。
予測モードテストおよび符号化ステップ１２２２において、プロセッサ２０５は方法１１００において決定されるように、選択されたＣＵの予測モードをテストする。フレームのスライスタイプが(ｉ)「Ｐ」または「Ｂ」の場合、または(ii)「skip flag」（または「ｃｕ＿ｓｋｉｐ＿ｆｌａｇ」）が符号化されている場合。スキップフラグは、スキップモードを使用してＣＵが符号化されているかどうかを示す。スキップモードを使用してＣＵが符号化されていない場合、「ｐｒｅｄ＿ｍｏｄｅ」フラグが符号化され、ＣＵにインター予測またはイントラ予測のどちらが使用されているかが示される。
図１１のステップ１１２０に関連して説明したように、スキップモードは、ＣＵのサイズに基づいて推論することができる。したがって、「大きい」ＣＵ（ステップ１１２０による）の場合、ＣＵは処理領域の１つ以上のサイズであり、スキップモードはＣＵの暗黙のサイズプロパティによって推論される。ＣＵは、処理領域のうちの１つの境界に効果的にオーバラップする。従ってスキップモードは推論され、スキップフラグはビットストリームに符号化されない。むしろ、マージインデックスは、ＣＵの暗黙のプロパティに基づいて決定される。あるいは推論されたスキップが３分割または３分割の中心ＣＵに基づく場合、マージインデックスは、ＣＵの形状および／または位置である、ＣＵの暗黙のプロパティに基づいて決定される。スキップモードが推論されない場合、ステップ１３２２は、ＣＵが処理領域の１つ以上のサイズではなく、スキップフラグを含むと判断する。推論スキップモードを有する構成では、スキップフラグが図１１のステップ１１２０を参照して説明したように、ＣＵサイズが所定の閾値未満である場合にのみ符号化される。例えば、いずれの辺の長さも６４サンプルを超えない。スキップフラグの符号化は、フレームの時間レイヤＩＤ（例えば８５３）が所定の閾値を下回る場合にのみ、追加的に符号化されてもよい。例えば、時間ＩＤの閾値は、ＧＯＰサイズが１６ピクチャである場合、４未満など、ＧＯＰ構造サイズの最大時間レイヤ未満であってもよい。推論されたスキップモードを有する構成は、閾値が満たされた場合（例えば、どちらか一方の辺の長さが６４より大きいＣＵ）、スキップフラグを符号化する必要はない。なぜならば、スキップコードのみが方法１１００においてそのようなケースについてテストされたからである。さらに、ステップ１２２２は、２つ以上の予測モードがＣＵについてテストされた場合のみ予測モード情報が符号化され、ビットストリーム１１５内に存在するシグナリングの対応する低減、したがって、結果としてより高い圧縮性能が達成され得るという点で、方法１１００と一致する。
「大きい」セットと「通常」セットとの間のＣＵの異なる分割は、以下の配置に示されるように可能である。「大きい」セットにおいてより多くのＣＵを有することは、これらのサイズのＣＵのための予測モードを選択する際にビデオエンコーダ１１４により少ない柔軟性を与えるという犠牲を払って、パイプライン処理問題を解決するためのＴＵタイリングのより少ないインスタンスをもたらす。
方法１１００のさらに別の構成では、使用されるべきスキップモードが推論されるＣＵの辺長に関する制約（ステップ１１２０は「大きい」を返す）が両辺が６４以上である任意のＣＵに適用される。両側が６４以上であることを要求すると、スキップ推論が行われるＣＵのセットは、１２８×１２８、６４×１２８、および１２８×６４となる。図１２のステップ１２２２および図１３のステップ１３２２は、それに応じて変化される。
方法１１００のさらに別の構成では、使用されるべきスキップモードが推論されるＣＵの辺長に関する制約（ステップ１１２０は「大きい」を返す）がいずれかの辺長が６４より大きい任意のＣＵに適用され、スキップ推論が行われるＣＵのセットは１２８×１２８、６４×１２８、１２８×６４、１２８×３２、３２×１２８、６４×６４である。再度、図１２のステップ１２２２および図１３のステップ１３２２は、それに応じて変化される。「大きい」セットと「通常」セットとの間の閾値（または境界）はシステム１００の「動作点」（例えば、ビットストリームの所望のビットレート）に依存し得る。固定された境界を有する代わりに、境界は閾値としてビットストリーム１１５においてシグナリングされることができ、ビデオエンコーダ１１５がシステム１００のための境界を選択することを可能にする。境界は、辺の長さのｌｏｇ２としてシグナリングすることができ、ＣＵの「どちらかの」側または「両方の」側が、「大きい」セット内にあると見なされるべきＣＵのためのシグナリングされた境界と一致しなければならないという要件もまた、シグナリングされ得る。
予測モードがスキップモードであると判定された（または推論された）場合（ステップ１２２２は「スキップ」を返す）、プロセッサ２０５の制御はステップ１２２２から動き補償実行ステップ１２７０に進む。そわない場合（予測モードはインター予測またはイントラ予測であり、ステップ１２２２は「イントラ又はインター」を返す）、プロセッサ２０５の制御はステップ１２２２から処理領域特定ステップ１２２５に進む。
処理領域特定ステップ１２２５で、プロセッサ２０５は、ステップ１２２０で選択されたＣＵの領域を使用して、選択されたＣＵとオーバーラップする処理領域を識別する。例えば、図１０ＡのＣＵ１０２２は、ＣＴＵ１０００内の４つの６４×６４処理領域とオーバーラップする。プロセッサ２０５内の制御はステップ１２２５からＣＵ変換サイズ制約決定ステップ１２３０へと進む。
ＣＵ変換サイズ制約決定ステップ１２３０において、プロセッサ２０５は、ＣＵの初期変換サイズを決定する。初期変換サイズは、選択されたＣＵの幅を超えない幅および選択されたＣＵの高さを超えない高さを有する、図９のものなどの変換サイズの所定のセットの最大変換サイズとして設定される。したがって、初期変換サイズは、選択されたＣＵに「適合する」最大サイズである。輝度チャネルを考慮すると、典型的には、単一の変換がＣＵの全体を占める。彩度チャネルは同様の関係を有し、彩度変換サイズは４：２：０輝度マフォーマット、すなわち、各変換の幅および高さの半分に調整された輝度チャネルのものに対応する。
単一の変換がＣＵを完全に占有しない場合、初期変換サイズは、ステップ１２３０で、変換を用いてＣＵの全体を占有するために「タイリング」プロセスを使用して適用される。例えば、３２×１２８のサイズを有するＣＵ１０２０の場合、ＣＵの全体を占有するために、１×４タイリングを伴う３２×３２の初期変換サイズが必要とされる。６４×１２８のサイズを有するＣＵ１０２２の場合、初期変換サイズは６４×６４であり、ＣＵの全体を占有するために１×２のファイルを有する。プロセッサ２０５における制御は、ステップ１２３０から処理領域境界重なりテストステップ１２３５に進む。
処理領域境界重なりテストステップ１２３５において、プロセッサ２０５は初期変換サイズの変換であって、選択されたＣＵに関連付けられた変換が２つ以上の処理領域にわたる（またはその境界を「またがる」）かどうかを判定する。言い換えれば、ステップ１２３５において、プロセッサ２０５は、コーディングユニットが処理領域間の境界に重なるかどうかを判定する。例えば、ＣＴＵ１０００の左上隅に対する位置（０，０）に位置するＣＵ１０２０の３２×３２の初期変換サイズで、各変換は、６４×６４パイプライン処理領域内に完全に含まれる。上の２つの３２×３２変換は１つの処理領域に配置され、下の２つの３２×３２変換は別の処理領域に配置される。このような場合、ステップ１２３５は「いいえ」を返し、プロセッサ２０５内の制御は、ＣＵ変換サイズステップ１２４０に進む。
しかしながら、６４×６４の初期変換サイズを有し、ＣＴＵ１０００の左上隅に対して位置（３２，０）に位置するＣＵ１０２２の場合、初期変換サイズは、（３２，０）から（９５，６４）までの領域を占める。処理領域が６４×６４格子に整列されると、最初の第１の変換は２つの処理領域を占め、（３２，６４）から（９５，１２７）までの領域を占める第２の変換は別の２つの処理領域を占める。結果として得られるこれらの提案された初期変換の少なくとも１つ（図１０Ａの例では両方とも）が２つ以上の処理領域間の境界にわたるので、ステップ１２３５は「Ｙｅｓ」を返し、プロセッサ２０５における制御はステップ１２４０から処理領域変換サイズステップ１２４５に進む。
一般的な規則として、２つ以上の処理領域にわたる変換の可能性は、コーディングツリーの最上位レベルでの３分割のアプリケーションから生じる。その結果、ＣＴＵサイズ、処理領域サイズ、変換のサイド寸法はすべて２のべき乗であり、ＣＴＵサイズは処理領域サイズの幅と高さの２倍であることに起因する。したがって、コーディングツリーの最上位レベルの３分割のみが、処理領域の幅または高さの半分だけ空間的に（水平または垂直に）オフセットされたＣＵを生成することができる。オフセットＣＵは初期変換サイズの変換を使用する場合、２つ以上の処理領域にわたる変換をもたらし、処理領域の粒度で動作するパイプライン化アーキテクチャのための実質的な実装課題を作り出す。
ＣＴＵサイズと、処理領域サイズと、変換サイド寸法サイズとの間の関係が与えられると、１つの解決策は、６４サンプルを超える辺長を有するコーディングツリー内の領域の３分割を禁止することであり得る。６４サンプルを超える辺長を有する領域の残りの選択肢は、それ以上の分割、２分割、または四分木分割ではない。さらなる分割が実行されない場合、４つの６４×６４変換のタイリングが可能であり、各々はパイプライン処理領域内に完全に含まれる。１２８×１２８ＣＴＵの２分割がいずれかの方向に実行された場合、結果として生じるサブ領域における反対方向の３分割の禁止は、２つのパイプライン処理領域にわたる可能な６４×６４ＣＵを防止する。しかしながら、３分割の中央（６４×６４）ＣＵをさらに分割することにより、パイプライン処理に関する変換配置問題を解決することができる。最初の禁止は、中間コーディングツリーが探索されるのを防止する。２分割がいずれかの方向に実行された場合（サイズ６４×１２８またはサイズ１２８×６４のいずれかの２つの領域をもたらす）、１辺の長さが１２８であるため、同じ方向に結果として生じるいずれかの領域の３分割を適用することも可能ではない。
しかしながら、同じ方向における３分割は、パイプライン処理領域間の境界にわたるいかなる変換ももたらさない。例えば、１２８×６４領域の水平３分割（ＣＴＵの水平２分割から生じる）は、１６×１２８、３２×１２８、および別の１６×１２８領域をもたらす。１２８の辺長に沿って、一般に辺長３２の変換が使用され、４回タイル張りされ、複数のパイプライン処理領域にわたるいかなる変換も生じない。最後に、四分木分割が実行された場合、結果として得られる各領域は別々のパイプライン処理領域内にあり、その後の分割に関係なく、それ以上のパイプライン処理の問題は発生しない。
したがって、パイプライン処理性能を解決するための１つのアプローチは辺長が６４を超える任意の領域上で３分割を禁止することであるが、この禁止は潜在的に有用なブロックサイズを禁止し、圧縮性能を低下させる。また、この制約は、残差係数を持たない場合、変換配置のためにパイプライン処理領域を引き起こさない「スキップモード」インター予測ＣＵの使用を防止する。したがって、スキップモードＣＵ、例えば、大きなＣＵの柔軟な配置が、特に低ビットレートで望ましいので、この制約は圧縮性能に悪影響を及ぼす。
説明したように、ステップ１２３５のテストは、ＣＴＵ内のＣＵサイズおよび位置に基づいて実行される。したがって、ステップ１２３５はビデオエンコーダ１１４の「探索空間」を増加させずに、暗黙のテストを実施する。すなわち、ビデオエンコーダ１１４はＴＵ構成を決定する際に、付加的な自由度（例えば、フラグの付加）を与えられない。自由度の結果を記憶するために、ビットストリーム１１５に追加の信号を必要としないというＴＵ構成手段を決定する際に、追加の自由度がないこと。言い換えれば、ステップ１２３５の動作は、ＣＴＵのコーディングツリーのプロパティに暗黙的に基づく。ステップ１２３５の出力はビットストリーム内で符号化されるべきＴＵサイズに関する明示的な信号とは独立しており、その生成には関係しない。
ＣＵ変換サイズステップ１２４０において、プロセッサ２０５は、ステップ１２３０の決定されたＣＵ変換サイズとなるＣＵのための変換サイズを選択する。結果として生じるＴＵは、複数のパイプライン処理領域にまたがらないので、ＣＵを追加のＴＵにさらに分割する必要はない。プロセッサ２０５内の制御は、ステップ１２４０から順変換適用および量子化ステップ１２５０まで進む。
処理領域変換サイズステップ１２４５において、プロセッサ２０５は結果として得られる変換のいずれもが、選択されたＣＵが及ぶパイプライン処理領域の２つ以上に及ぶことがないように、選択されたＣＵの変換サイズを決定する。例えば、サイズ６４×１２８のＣＵ１０２２は、収容ＣＴＵ１０００の左上に対して（３２，０）に位置する。したがって、ＣＵ１０２２は、（３２，０）から（９５，１２７）までの領域にわたる。水平方向には、ＣＵは６４のＸオフセットでパイプライン処理領域を通過する。したがって、水平方向には、ＴＵ幅が多くとも３２である必要があり、パイプライン化された実装に適した最大ＴＵ幅である必要がある。垂直方向には、ＴＵ幅が多くても６４である必要があり、パイプライン化された実施に適した最大ＴＵ幅である必要がある。しかしながら、図９に見られるように、利用可能な３２×６４ＴＵはない。利用可能な最大の利用可能なＴＵは３２×３２であるので、３２×３２サイズのＴＵが選択される。ＣＴＵ１０００のための３２×３２ＴＵの選択により、ＣＴＵは、図１０Ａを参照して説明したようにパイプライン方式で処理されてもよい。ステップ１２４５は例えば図９に示すように、利用可能な（複数の）変換サイズの集合からコーディングユニットの変換サイズを選択するように効果的に動作する。変換サイズは、コーディングユニット内に適合するように選択され、処理領域のサイズとは異なることができる。プロセッサ２０５内の制御は、ステップ１２４５から順変換適用および量子化ステップ１２５０へ進む。
順変換適用および量子化ステップ１２５０において、変換モジュール３２６および量子化モジュール３３４はプロセッサ２０５の実行下で、ステップ１２４０またはステップ１２４５のいずれかの選択された変換を適用して、差分３２４を変換し、残差係数３３６を生成する。ＣＵサイズが変換サイズに等しい場合、単一の変換が実行される。ＣＵサイズが変換サイズよりも大きい場合、差分３２４のすべてが変換されるように、変換がタイル方式で適用される。さらに、ステップ１２４５で選択された変換サイズにより、個々の変換は、パイプライン処理領域の２つ以上にまたがる領域をカバーしない。
ビデオ圧縮標準用の「参照ソフトウェア」などのソフトウェア実装は一般に、ＣＴＵサイズよりも小さい領域のパイプライン処理など、より細かい粒度の処理を使用せずに、各フレームを時間１ＣＴＵずつ処理する。参照ソフトウェア実装では、上記で特定されたパイプライン処理領域の問題などの問題は発生せず、通常、これらはリアルタイムまたはリソースに制約のあるデバイスで実行されないためである。実用的な実装、特にパイプラインアーキテクチャを利用するハードウェア実装と、いくつかのソフトウェア実装は、変換が完全に別個のパイプライン処理領域内に含まれることから利益を得る。変換がまったく別個のパイプライン領域内に含まれていることから利益を受けるソフトウェア実装には、局所性の改善のために同じパイプラインアーキテクチャを使用するマルチコア実装、または例が含まれる。別個のパイプライン領域内に完全に含まれる重要な利益変換は、パイプライン処理領域の均一なサイズおよび速度である。プロセッサ２０５における制御は、ステップ１２５０から残差係数符号化ステップ１２５５に進む。
残差係数符号化ステップ１２５５において、エントロピーエンコーダ３３８は、プロセッサ２０５の実行下で、ステップ１２５０の残差係数をビットストリーム１１５に符号化する。第１に、「ルート符号化ブロックフラグ」が符号化され、ステップ１２５０の量子化から生じる少なくとも１つの有意な残差係数の存在を示す。ルート符号化ブロックフラグは、ＣＵについて１回符号化され、ＣＵの任意のＴＵの任意のＴＢについてすべてのカラーチャネルにわたって、ＣＵの任意の変換について有意性を信号伝達する。少なくとも１つの有意な残差係数がＣＵの任意の色チャネルにわたる任意の変換のために存在する場合、各色チャネル内で、別個の符号化ブロックフラグが色チャネル内で適用される各変換のために符号化される。各符号化ブロックフラグは、対応する変換ブロックにおける少なくとも１つの有意な残差係数の存在を示す。少なくとも１つの有意な残差係数を有する変換については、有意性マップ、ならびに有意係数の大きさおよび符号も符号化される。プロセッサ２０５における制御は、ステップ１２５５からイントラモードテスト１２６０に進む。
イントラモードテスト１２６０では、選択されたＣＵの予測モードがプロセッサ２０５によってテストされる。予測モードがイントラ予測である場合（ステップ１２６０で「Ｙｅｓ」）、プロセッサ２０５の制御は、イントラ予測実行ステップ１２６５に進む。そわない場合（予測モードがインター予測であり、ステップ１２６０が「Ｎｏ」を返す）、プロセッサ２０５における制御は、動き補償実行ステップ１２７０に進む。
イントラ予測実行ステップ１２６５において、イントラフレーム予測モジュール３６４は、プロセッサ２０５の実行下で、サンプルのイントラ予測ブロック（３６６）を生成する。サンプルのイントラ予測ブロック３６６は、選択されたＣＵの各ＰＢについてのイントラ予測モードに従って、フィルタリングされた参照サンプル３６２を使用して生成される。ステップ１２４５により、複数のＴＵがＣＵに関連付けられると、選択されたＣＵの内部の各ＴＵ境界においてイントラ再構成プロセスが適用される。参照サンプルキャッシュ３５６は、各ＣＵ境界における再構成サンプルに加えて、ＣＵ内部の各ＴＵ境界における再構成サンプルで更新される。ＣＵ内部のＴＵ境界での再構成は、ＣＵ内部の現在のＴＵの上または左のＴＵの残差係数が現在のＴＵと一緒に配置されたＰＢの部分を生成するための参照サンプルに寄与することを可能にする。したがって、ＣＵ内部のＴＵ境界で再構成すると、歪みを減らし、圧縮効率を向上させることができる。プロセッサ２０５における制御は、ステップ１２６５からＣＵ再構成ステップ１２７５に進む。
動き補償実行ステップ１２７０において、動き補償モジュール３８０は、プロセッサ２０５の実行下で、フィルタリングされたブロックサンプル３８２を生成する。フィルタリングされたブロックサンプル３８２は、フレームバッファ３７２からサンプル３７４の１つまたは２つのブロックをフェッチすることによって生成される。サンプルの各ブロックに対して、フレームは参照ピクチャインデックスに従って選択され、選択されたＣＵに対するピクセル単位の空間変位は動きベクトルに従って指定される。フレームバッファ３７２からフェッチされたサンプルの各ブロックに対して、フィルタリングは、動きベクトルの「サブピクセル」変位部分に従って適用される。動きベクトルのサブピクセル変位部分の精度は、１／４ペル精度または１／１６ペル精度にできる。２つのブロックが使用される場合、結果として得られるフィルタリングされたブロックは、一緒にブレンドされる。参照ピクチャインデックスおよび動きベクトルは、方法１１００において決定される。プロセッサ２０５における制御は、ステップ１２７０からＣＵ再構成ステップ１２７５に進む。
ＣＵ再構成ステップ１２７５において、合計モジュール３５２は、プロセッサ２０５の実行下で、インター予測またはイントラ予測されたＣＵのための残差サンプル３５０およびＰＵ３２０を加えることによって、再構成されたサンプル３５４を生成する。スキップモードＣＵの場合、残差サンプルは存在せず、したがって、再構成サンプル３５４はＰＵ３２０から導出される。再構成されたサンプル３５４は、現在のフレームにおける後続のイントラ予測されたＣＵによる参照のために利用可能である。再構成されたサンプル３５４はループ内フィルタリングが適用された（すなわち、ループ内フィルタ３６８の適用）後に、フレームバッファ３７２に書き込まれ、後続のフレームにおけるインター予測ＣＵによって参照される。ループ内フィルタ３６８のデブロッキングフィルタリングは、ＣＵの内部境界に適用される。すなわち、デブロッキングフィルタリングは、ＣＵサイズおよびパイプライン処理領域境界の両方によるタイリングから生じる、ＣＵ内部のＴＵ間の境界に適用される。プロセッサ２０５内の制御は、ステップ１２７５から最後のＣＵテストステップ１２８５に進む。
最後のＣＵテストステップ１２８５において、プロセッサは、選択されたＣＵがＣＴＵ内の最後のＣＵであるかどうかをテストする。そわない場合（ステップ１１６０で「Ｎｏ」）、プロセッサ２０５内の制御はステップ１２１５に戻る。選択されたＣＵがＣＵスキャン順序、すなわち深さ優先Ｚ順序スキャンにおけるＣＴＵの最後のＣＵである場合、方法１２００は終了する。方法１２００が終了した後、次のＣＴＵが符号化されるか、またはビデオエンコーダ１１４がビデオの次の画像フレームに進む。
図１３は、ビットストリーム１３３からＣＴＵのＣＵを復号するための方法１３００を示す。方法１３００では、変換サイズが方法１３００がパイプラインアーキテクチャで実行され得るように選択される。対応するパイプライン処理領域はＣＴＵサイズよりもサイズが小さく、パイプライン処理領域のレートは各ＣＴＵのコーディングツリーに依存しない。方法１３００は、構成されたＦＰＧＡ、ＡＳＩＣ、またはＡＳＳＰなどの装置によって実施され得る。さらに、方法１３００は、プロセッサ２０５の実行下で、ビデオデコーダ１３４によって実行され得る。したがって、方法１３００は、コンピュータ読み取り可能な記憶媒体および／またはメモリ２０６に記憶されてもよい。方法１３００は、処理領域決定ステップ１３１０においてプロセッサ２０５から開始する。
処理領域決定ステップ１３１０において、ビデオデコーダ１３４は、プロセッサ２０５の実行下で、ビットストリームの画像フレームを、画像フレームの全体を占める等しいサイズおよび正方形の処理領域の格子に分割することを決定する。ステップ１３１０は、ステップ１２１０と一致するように画像フレームの分割を決定する。ステップ１３１０は、画像フレームを複数の等しいサイズの処理領域に分割するように動作し、等しいサイズの処理領域の各々は、ビットストリームを復号するパイプラインの単一の段階の間に処理されるブロックである。プロセッサ２０５内の制御は、ステップ１３１０からコーディングツリー復号ステップ１３１５に進む。
コーディングツリー復号ステップ１３１５において、エントロピーデコーダ４２０は、プロセッサ２０５の実行下で、ビットストリーム１３３からＣＴＵのためのコーディングツリーを復号する。コーディングツリーは図５および図６を参照して説明したように、図７Ａおよび図７Ｂの例を使用して、一連の分割に従ってＣＴＵを１つまたは複数のＣＵに分解する。ビットストリーム１３３から復号されたコーディングツリーは、図１２のステップ１２１５で決定されたコーディングツリーである。ステップ１３１５は、コーディングツリーを用いてＣＴＵを復号することによって、各コーディングユニット（ＣＵ）のサイズを効果的に決定する。プロセッサ２０５内の制御は、ステップ１３１５からＣＵ選択ステップ１３２０に進む。
ＣＵ選択ステップ１３２０において、ビデオデコーダ１３４は、プロセッサ２０５の実行下で、コーディングツリーに関連する構文がビットストリーム１３４内に存在する方向に対応する順方向へのコーディングツリーを介した反復に従って、復号されたコーディングツリーの１つのＣＵを選択する。順方向は、Ｚオーダースキャンに関連する。選択されたＣＵは画像フレーム内の特定のサイズおよび位置を有し、したがって、収容ＣＴＵの左上隅に対する位置を有する。したがって、選択されたＣＵは、収容ＣＴＵ内の所与の領域を占有すると言うことができる。プロセッサ２０５における制御は、ステップ１３２０から予測モード決定テストステップ１３２２に進む。
予測モード決定テストステップ１３２２において、プロセッサ２０５は、選択されたＣＵの予測モードを決定する。フレームのスライスタイプが「Ｐ」または「Ｂ」である場合、エントロピーデコーダ４２０は、スキップモードを使用してＣＵが符号化されているかどうかを示す「スキップフラグ」（または「ｃｕ＿ｓｋｉｐ＿ｆｌａｇ」）を復号する。ＣＵがスキップモードを使用して符号化されていない場合、エントロピーデコーダ４２０は「ｐｒｅｄ＿ｍｏｄｅ」フラグを復号する。「ｐｒｅｄ＿ｍｏｄｅ」フラグは、ＣＵにインター予測またはイントラ予測のどちらが使用されているかを示す。図１１のステップ１１２０に関連して説明したように、スキップモードは、ＣＵのサイズに基づいて推論することができる。したがって、「大きい」ＣＵ（ステップ１１２０による）の場合、ＣＵは処理領域の１つ以上のサイズであり、スキップモードはＣＵの暗黙のサイズプロパティによって推論される。スキップモードはそれに応じて推論され、スキップフラグはビットストリームに符号化されない。むしろ、マージインデックスは、ＣＵの暗黙のプロパティに基づいて決定される。あるいは推論されたスキップが３分割または３分割の中心ＣＵに基づく場合、マージインデックスはＣＵの形状および／または位置でＣＵの暗黙のプロパティに基づいて決定される。スキップモードが推論されない場合、ステップ１３２２はＣＵが処理領域の１つ以上のサイズではないと判断し、スキップフラグを含む。
推論されたスキップモードを有する構成では、スキップフラグが、ＣＵサイズが所定の閾値より小さい場合、例えば、どちらの辺長も６４サンプルを超えない場合にのみ復号される。そわなければ、ＣＵは「大きなＣＵ」であると決定され、スキップモードが使用されていると推論される。スキップフラグの符号化は時間レイヤＩＤが所定の閾値未満、例えば、ＧＯＰ構造サイズの最大時間レイヤ未満、例えば、ＧＯＰサイズが１６ピクチャである場合に４未満である場合にのみ、追加的に符号化されてもよい。推論されたスキップモードを有する構成は、閾値テストが満たされた場合（例えば、閾値を超える大きなＣＵサイズおよび／または時間レイヤＩＤ）、スキップコードのみが方法１１００においてそのようなケースについてテストされたので、スキップフラグｉを復号する必要はない。これにより、予測モードがスキップモードであると判定される。さらに、ステップ１３２２は、２つ以上の予測モードがＣＵについてテストされたときにのみ、予測モード情報が復号されるという点で、方法１１００と一致する。ＣＵについて１つの予測モードのみがテストされた場合、ビデオデコーダ１３４は予測モードを明示的に復号するのではなく、例えば、ＣＵサイズに基づいて予測モードを推論する。
予測モードがスキップモードであると判定された（または推論された）場合（ステップ１３２２で「スキップ」）、プロセッサ２０５の制御は、ステップ１３２２から動きパラメータ復号ステップ１３７０に進む。そわない場合（予測モードがインター予測またはイントラ予測である）、ステップ１３２２は「イントラまたはインター」を返し、プロセッサ２０５における制御は処理領域特定ステップ１３２５に進む。
処理領域特定ステップ１３２５で、プロセッサ２０５は、ステップ１３２０で選択されたＣＵの領域を使用して、選択されたＣＵとオーバーラップする処理領域を特定する。例えば、図１０Ａのコーディングユニット１０２２は、ＣＴＵ１０００内の４つの６４×６４処理領域とオーバーラップする。ステップ１３２５は、図１２のステップ１２２５と同様に動作する。プロセッサ２０５における制御は、ステップ１３２５からコーディングユニット変換サイズ制約決定ステップ１３３０に進む。
コーディングユニット変換サイズ制約決定ステップ１３３０において、プロセッサ２０５は、ＣＵの初期変換サイズを決定する。初期変換サイズは、ステップ１２３０の決定と同様の方法で設定される。プロセッサ２０５における制御は、ステップ１３３０から処理領域境界重なりテストステップ１３３５に進む。
処理領域境界重なりテストステップ１３３５において、プロセッサ２０５は重なりテストステップ１２３５と同様に、選択されたＣＵに関連する初期変換サイズの変換が２つ以上の処理領域に及ぶかどうかを判定する。言い換えると、ステップ１３３５は、コーディングユニットが処理領域間の境界と重なるかどうかを判定する。各変換が処理領域内に完全に含まれる場合（ステップ１３３５で「Ｎｏ」）、プロセッサ２０５内の制御はＣＵ変換サイズステップ１３４０に進む。初期変換サイズから生じる変換のうちの少なくとも１つが、２つ以上の処理領域間の境界に及ぶか、または「またがる」場合（ステップ１３３５で「Ｙｅｓ」）、プロセッサ２０５内の制御は処理領域変換サイズステップ１３４５に進む。テストステップ１３３５の結果はＣＴＵ内のＣＵサイズおよび位置に依存し、これらは、ＣＴＵのコーディングツリーによって完全に記述される。したがって、ＣＵが２つの処理領域にまたがるか否かを決定するために、ビットストリーム１３３から復号される必要のある追加の信号はない。むしろ、ＣＵの暗黙のプロパティ（サイズおよび位置）は、処理領域境界がオーバーラップしているかどうかをテストするために使用される。
ＣＵ変換サイズステップ１３４０において、プロセッサ２０５は、ステップ１２４０の変換サイズ選択に従って、ステップ１３３０の決定されたＣＵ変換サイズとなるＣＵの変換サイズを選択する。プロセッサ２０５における制御は、ステップ１３５０から残差係数復号ステップ１３５０に進む。
処理領域変換サイズステップ１３４５において、プロセッサ２０５は結果として得られる変換のいずれもが、選択されたＣＵが及ぶパイプライン処理領域の２つ以上に及ぶことがないように、選択されたＣＵの変換サイズを決定する。ステップ１３４５は、ステップ１２４５の変換サイズ選択に従って動作する。ステップ１３４５は例えば図９に示すように、利用可能な（複数の）変換サイズの集合からコーディングユニットの変換サイズを選択するように効果的に動作する。変換サイズは、コーディングユニット内に適合するように選択され、処理領域のサイズとは異なることができる。プロセッサ２０５における制御は、ステップ１３４５から残差係数復号ステップ１３５０に進む。
残差係数復号ステップ１３５０において、エントロピーデコーダ４２０は、プロセッサ２０５の実行下で、ビットストリーム１１５から残差係数を復号する。コーディングユニットにおける各変換ユニットの残差係数に逆変換を適用することによる符号化ユニット。
残差係数を復号する際には、まず、「ルート符号化ブロックフラグ」が復号される。ルート符号化ブロックフラグは、ＣＵの任意のＴＵにおける、すなわち、すべてのカラーチャネルにわたる、少なくとも１つの有意な残差係数の存在を示す。ルート符号化ブロックフラグが有意な残差係数がＣＵ内に存在することを示すとき、各色チャネル内で、別個の符号化ブロックフラグが、色チャネル内で適用される各変換について復号される。各符号化ブロックフラグは、対応する変換における少なくとも１つの有意な残差係数の存在を示す。少なくとも１つの有意な残差係数を有する変換の場合、有意性マップ、ならびに有意係数の大きさおよび符号も復号される。プロセッサ２０５における制御は、ステップ１３５０から逆量子化および逆変換適用ステップ１３５５に進む。
逆量子化および逆変換適用ステップ１３５５において、逆量子化モジュール４２８および逆変換モジュール４４４は、プロセッサ２０５の実行下で、逆量子化残差係数をスケーリングされた変換係数４４０を生成する。ステップ１３５５では、ステップ１３４０またはステップ１３４５のいずれかの選択された変換が適用され、スケールされた変換係数４４０を変換して、残差サンプル４４８を生成する。ステップ１２５０と同様に、変換の適用は、決定された変換サイズに従ってタイル方式で実行される。さらに、ステップ１３４５で選択された変換サイズにより、個々の変換は、パイプライン処理領域のうちの２つ以上にまたがる領域をカバーしない。方法１２００と同様に、実際的な実装、特にパイプラインアーキテクチャを利用するハードウェア実装、そしていくつかのソフトウェア実装は、変換が完全に別個のパイプライン処理領域内に包含されることから利益を得る。記載されている構成に利点をもたらすソフトウェア実装例は、データ局所性の改善のために同じパイプラインアーキテクチャを使用することができるマルチコア実装である。プロセッサ２０５における制御は、ステップ１３５５からイントラモードテストステップ１３６０に進む。
イントラモードテスト１３６０では、選択されたＣＵの決定された予測モードがプロセッサ２０５によってテストされる。予測モードがイントラ予測である場合（ステップ１３６０で「Ｙｅｓ」）、プロセッサ２０５の制御はイントラ予測実行ステップ１３６５に進む。そわない場合（予測モードがインター予測である場合）、ステップ１３６０は「Ｎｏ」を返し、プロセッサ２０５の制御は動きパラメータ復号ステップ１３７０に進む。
イントラ予測実行ステップ１３６５において、イントラフレーム予測モジュール４７６は、プロセッサ２０５の実行下で、サンプルのイントラ予測ブロック（４８０）を生成する。サンプルのイントラ予測ブロック４８０は、選択されたＣＵの各ＰＢについてのイントラ予測モードに従って、フィルタリングされた参照サンプル４７２を使用して生成される。複数のＴＵがステップ１３４５によるＣＵと関連付けられている場合、選択されたＣＵに内部的な各ＴＵ境界において、イントラ再構成処理が適用される。再構成サンプルキャッシュ４６０は、各ＣＵ境界における再構成サンプルに加えて、ＣＵ内部の各ＴＵ境界における再構成サンプルで更新される。ＣＵ内部のＴＵ境界での再構成は、ＣＵ内の現在のＴＵの上または左のＴＵの残りが、現在のＴＵと一緒に配置されたＰＢの部分を生成するための参照サンプルに寄与することを可能にする。ＣＵ内部のＴＵ境界での再構成は、歪みを低減し、圧縮効率を改善するために動作することができる。プロセッサ２０５における制御は、ステップ１３６５からＣＵ再構成ステップ１３８０に進む。
動きパラメータ復号ステップ１３７０において、エントロピーデコーダ４２０は、プロセッサ２０５の実行の下で、選択されたＣＵのための動きベクトルを復号する。動きベクトルを復号することは、（ｉ）スキップモードが推論された場合にマージインデックスを復号する（１１２０および１３２２におけるようにＣＵのプロパティから特定される）、または（ｉｉ）スキップモードがＣＵによって推論されなかった場合にマージインデックスを復号するためにスキップフラグを復号する、ことによって動きベクトルを選択することを含む。空間的および時間的に隣接するブロックを使用して、候補動きベクトルのリストが作成される（「マージリスト」と呼ばれる）。マージインデックスはマージリストから候補の１つを選択するために、ビットストリーム１３３から復号される。マージインデックスは、（上述のステップ１３２２に関連して説明したように）ＣＵの暗黙的なプロパティに基づいて、またはビットストリームから分割モードフラグを復号することから決定されてもよい。選択されたＣＵがスキップモードを使用して符号化されている場合、選択された候補がＣＵの動きベクトルになる。選択されたＣＵがインター予測を使用して符号化される場合、動きベクトルデルタがビットストリーム１３３から復号され、復号されたマージインデックスに従って選択された候補に追加される。プロセッサにおける制御は、ステップ１３７０から動き補償実行ステップ１３７５に進む。
動き補償実行ステップ１３７５において、動き補償モジュール４３４は、プロセッサ２０５の実行下で、フィルタリングされたブロックサンプル４３８を生成する。フィルタリングされたブロックサンプル４３８は、フレームバッファ４９６からサンプル４９８の１つまたは２つのブロックをフェッチすることによって生成される。サンプル４９８の各ブロックについて、フレームは参照ピクチャインデックスに従って選択され、選択されたＣＵに対するピクセル単位の空間変位は動きベクトルに従って指定される。フレームバッファ３７２からフェッチされたサンプルの各ブロックに対して、フィルタリングは、動きベクトルの「サブピクセル」変位部分に従って適用される。動きベクトルのサブピクセル変位部分の精度は、１／４ペル精度または１／１６ペル精度にできる。２つのブロックが使用される場合、結果として得られるフィルタリングされたブロックは、一緒にブレンドされる。参照ピクチャインデックスおよび動きベクトルは、ビットストリーム１３３から復号され、方法１１００で決定された。プロセッサ２０５における制御は、ステップ１３７５からＣＵ再構成ステップ１３８０に進む。
ＣＵ再構成ステップ１３８０において、加算モジュール４５０は、プロセッサ２０５の実行下で、再構成サンプル４５６を生成する。再構成されたサンプル４５６は、インター予測またはイントラ予測されたＣＵのための残差サンプル４４８およびＰＵ４５２を加算することによって生成される。スキップモードＣＵの場合、残差はないので、再構成サンプル４５６はＰＵ４５２から導出される。再構成されたサンプル４５６は、現在のフレームにおける後続のイントラ予測されたＣＵによる参照のために利用可能である。再構成されたサンプル４５６はループ内フィルタリングが適用された（すなわち、ループ内フィルタ４８８の適用）後に、フレームバッファ４９６に書き込まれ、後続のフレームにおけるインター予測ＣＵによって参照される。ループ内フィルタ４８８のデブロッキングフィルタリングは、ＣＵの内部境界に適用される。すなわち、デブロッキングフィルタリングは、ＣＵサイズおよびパイプライン処理領域境界の両方によるタイリングから生じる、ＣＵ内部のＴＵ間の境界に適用される。プロセッサ２０５における制御は、ステップ１３８０から最後のＣＵテストステップ１３８５に進む。
最後のＣＵテストステップ１３８５において、プロセッサ２０５は選択されたＣＵがＣＵスキャン順序におけるＣＴＵ内の最後のＣＵであり、深さ優先Ｚ順序スキャンであるかどうかをテストする。そわない場合（ステップ１３８５で「Ｎｏ」）、プロセッサ２０５の制御はステップ１３１５に戻る。選択されたＣＵがＣＴＵ内の最後のＣＵである場合（ステップ１３８５で「Ｙｅｓ」）、方法１３００は終了する。方法１３００が終了した後、次のＣＴＵが復号されるか、またはビデオデコーダ１３４がビットストリームの次の画像フレームに進むかのいずれかである。
ビデオエンコーダ１１４およびビデオデコーダ１３４の代替構成では、複数のパイプライン処理領域にわたるＣＵが「スキップモード」で符号化されると推定され、したがって、関連する残差係数を有さず、したがって、そのようなブロックを符号化または復号するために変換を実行する必要はない。したがって、ビデオエンコーダ１１４がステップ１２１５でコーディングツリーを決定しているとき、ＴＵが複数の処理領域にわたることになるようなＣＵをテストするとき、関連する残差係数なしに符号化されることが必要とされる。
産業上の利用可能性
記載された構成はコンピュータ及びデータ処理産業に適用可能であり、特に、ビデオ及び画像信号のような信号の復号を符号化するためのデジタル信号処理に適用可能であり、メモリ消費、最大のサポートされたブロックサイズ又はＣＴＵサイズよりも小さい処理領域サイズを有するパイプライン化された実装の可能性を与えることによるシリコン面積の点で過剰なコストなしに高い圧縮効率を達成する。いくつかの実装形態では、領域ＴＵのタイリングの実装（たとえば、ステップ１１４５および１２４５で実装）は、特にインター予測モードのパイプラインの非効率性を防ぐのに役立つため、説明されている構成はＶＶＣ標準に有用である。上述したように、本明細書に記載された実装のいくつかは、より大きなＣＵのために３値コーディングツリーが使用されること、または処理時間および／または品質への影響が低減された状態で６４×６４ＣＵが使用されることを可能にする。
上記は本発明のいくつかの実施形態のみを記載し、本発明の範囲および精神から逸脱することなく、本発明に修正および／または変更を加えることができ、実施形態は例示的であり、限定的ではない。
（オーストラリアのみ）本明細書の文脈において、「含む」という語は「主として含むが、必ずしもそれだけではない」または「有する」または「含む」を意味し、「のみからなる」を意味しない。「含む」および「含む」などの語「含む」の変形は、対応して変化する意味を有する。

Claims (16)

  1. 所定の方式に従って、ビットストリームからコーディングユニットを復号する方法であって、
    コーディングツリーユニットにおけるコーディングユニットを決定するための情報を前記ビットストリームから復号する第１の復号工程と、
    前記情報に基づいて、前記コーディングユニットを決定する第１の決定工程と、
    前記コーディングユニットにおける変換ユニットを決定する第２の決定工程と、
    前記コーディングユニットを、前記変換ユニットを用いて復号する第２の復号工程と
    を有し、
    前記所定の方式において、前記コーディングユニットの辺の長さは、１２８サンプルとすることが可能であり、
    前記変換ユニットを決定する際に第１の制約が用いられる場合における前記第２の決定工程において、前記コーディングユニットの少なくとも１つの辺の長さが１２８サンプルであったとしても、当該コーディングユニットにおける変換ユニットの輝度成分のサイズとして選択可能な最大サイズを３２サンプルとして前記変換ユニットを決定し、
    前記変換ユニットを決定する際に第２の制約が用いられる場合における前記第２の決定工程において、前記コーディングユニットの少なくとも１つの辺の長さが１２８サンプルであったとしても、前記最大サイズを６４サンプルとして前記変換ユニットを決定する
    ことを特徴とすることを方法。
  2. 前記コーディングユニットの少なくとも１つの辺の長さは１２８サンプルである
    ことを特徴とする請求項１に記載の方法。
  3. 前記コーディングユニットは、３分割を用いて前記コーディングツリーユニットを分割することで決定することができる
    ことを特徴とする請求項１に記載の方法。
  4. 前記コーディングユニットにおける複数の変換ユニットのそれぞれの形状は、当該コーディングユニットとは異なる
    ことを特徴とする請求項１に記載の方法。
  5. 前記コーディングユニットにおける複数の変換ユニットのそれぞれのアスペクト比は、当該コーディングユニットのアスペクト比とは異なる
    ことを特徴とする請求項１に記載の方法。
  6. 前記第１の制約と前記第２の制約とは代替的に用いられる
    ことを特徴とする請求項１に記載の方法。
  7. 所定の方式に従ってコーディングユニットを符号化する方法であって、
    コーディングツリーユニットにおけるコーディングユニットを決定する第１の決定工程と、
    前記コーディングユニットにおける変換ユニットを決定する第２の決定工程と、
    前記コーディングユニットを、前記変換ユニットを用いて符号化する符号化工程と
    を有し、
    前記所定の方式において、前記コーディングユニットの辺の長さは、１２８サンプルとすることが可能であり、
    前記変換ユニットを決定する際に第１の制約が用いられる場合における前記第２の決定工程において、前記コーディングユニットの少なくとも１つの辺の長さが１２８サンプルであったとしても、当該コーディングユニットにおける変換ユニットの輝度成分のサイズとして選択可能な最大サイズを３２サンプルとして前記変換ユニットを決定し、
    前記変換ユニットを決定する際に第２の制約が用いられる場合における前記第２の決定工程において、前記コーディングユニットの少なくとも１つの辺の長さが１２８サンプルであったとしても、前記最大サイズを６４サンプルとして前記変換ユニットを決定する
    ことを特徴とすることを方法。
  8. 前記コーディングユニットの少なくとも１つの辺の長さは、１２８サンプルである
    ことを特徴とする請求項７に記載の方法。
  9. 前記コーディングユニットは、３分割を用いて前記コーディングツリーユニットを分割することで決定することができる
    ことを特徴とする請求項７に記載の方法。
  10. 前記コーディングユニットにおける複数の変換ユニットのそれぞれの形状は、当該コーディングユニットとは異なる
    ことを特徴とする請求項７に記載の方法。
  11. 前記コーディングユニットにおける複数の変換ユニットのそれぞれのアスペクト比は、当該コーディングユニットのアスペクト比とは異なる
    ことを特徴とする請求項７に記載の方法。
  12. 前記第１の制約と前記第２の制約とは代替的に用いられる
    ことを特徴とする請求項７に記載の方法。
  13. 所定の方式に従って、ビットストリームからコーディングユニットを復号する装置であって、
    コーディングツリーユニットにおけるコーディングユニットを決定するための情報を前記ビットストリームから復号する第１の復号手段と、
    前記情報に基づいて、前記コーディングユニットを決定する第１の決定手段と、
    前記コーディングユニットにおける変換ユニットを決定する第２の決定手段と、
    前記コーディングユニットを、前記変換ユニットを用いて復号する第２の復号手段と
    を有し、
    前記所定の方式において、前記コーディングユニットの辺の長さは、１２８サンプルとすることが可能であり、
    前記変換ユニットを決定する際に第１の制約が用いられる場合、前記第２の決定手段は、前記コーディングユニットの少なくとも１つの辺の長さが１２８サンプルであったとしても、当該コーディングユニットにおける変換ユニットの輝度成分のサイズとして選択可能な最大サイズを３２サンプルとして前記変換ユニットを決定し、
    前記変換ユニットを決定する際に第２の制約が用いられる場合、前記第２の決定手段は、前記コーディングユニットの少なくとも１つの辺の長さが１２８サンプルであったとしても、前記最大サイズを６４サンプルとして前記変換ユニットを決定する
    ことを特徴とすることを装置。
  14. 所定の方式に従ってコーディングユニットを符号化する装置であって、
    コーディングツリーユニットにおけるコーディングユニットを決定する第１の決定手段と、
    前記コーディングユニットにおける変換ユニットを決定する第２の決定手段と、
    前記コーディングユニットを、前記変換ユニットを用いて符号化する符号化手段と
    を有し、
    前記所定の方式において、前記コーディングユニットの辺の長さは、１２８サンプルとすることが可能であり、
    前記変換ユニットを決定する際に第１の制約が用いられる場合、前記第２の決定手段は、前記コーディングユニットの少なくとも１つの辺の長さが１２８サンプルであったとしても、当該コーディングユニットにおける変換ユニットの輝度成分のサイズとして選択可能な最大サイズを３２サンプルとして前記変換ユニットを決定し、
    前記変換ユニットを決定する際に第２の制約が用いられる場合、前記第２の決定手段は、前記コーディングユニットの少なくとも１つの辺の長さが１２８サンプルであったとしても、前記最大サイズを６４サンプルとして前記変換ユニットを決定する
    ことを特徴とすることを装置。
  15. コンピュータに、請求項１～６のいずれか１項に記載の方法を実行させることを特徴とするプログラム。
  16. コンピュータに、請求項７～１２のいずれか１項に記載の方法を実行させることを特徴とするプログラム。
JP2021501306A 2018-08-17 2019-06-25 ビデオサンプルの変換されたブロックを符号化および復号する方法、装置、およびシステム Active JP7191195B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2022188696A JP7391171B2 (ja) 2018-08-17 2022-11-25 ビデオサンプルの変換されたブロックを符号化および復号する方法、装置、およびシステム

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
AU2018217336A AU2018217336A1 (en) 2018-08-17 2018-08-17 Method, apparatus and system for encoding and decoding a transformed block of video samples
AU2018217336 2018-08-17
PCT/AU2019/050656 WO2020033992A1 (en) 2018-08-17 2019-06-25 Method, apparatus and system for encoding and decoding a transformed block of video samples

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2022188696A Division JP7391171B2 (ja) 2018-08-17 2022-11-25 ビデオサンプルの変換されたブロックを符号化および復号する方法、装置、およびシステム

Publications (2)

Publication Number Publication Date
JP2021536156A JP2021536156A (ja) 2021-12-23
JP7191195B2 true JP7191195B2 (ja) 2022-12-16

Family

ID=69524537

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2021501306A Active JP7191195B2 (ja) 2018-08-17 2019-06-25 ビデオサンプルの変換されたブロックを符号化および復号する方法、装置、およびシステム
JP2022188696A Active JP7391171B2 (ja) 2018-08-17 2022-11-25 ビデオサンプルの変換されたブロックを符号化および復号する方法、装置、およびシステム

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2022188696A Active JP7391171B2 (ja) 2018-08-17 2022-11-25 ビデオサンプルの変換されたブロックを符号化および復号する方法、装置、およびシステム

Country Status (6)

Country Link
US (1) US20210306679A1 (ja)
JP (2) JP7191195B2 (ja)
CN (6) CN116684596A (ja)
AU (1) AU2018217336A1 (ja)
TW (2) TWI786032B (ja)
WO (1) WO2020033992A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11947462B1 (en) * 2022-03-03 2024-04-02 Apple Inc. Cache footprint management
CN117812273A (zh) * 2024-02-29 2024-04-02 浙江华创视讯科技有限公司 视频传输中的图像恢复方法、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012046435A1 (ja) 2010-10-04 2012-04-12 パナソニック株式会社 画像処理装置、画像符号化方法および画像処理方法
JP2013517665A (ja) 2010-01-14 2013-05-16 サムスン エレクトロニクス カンパニー リミテッド 階層的データ単位のパターン情報を利用するビデオ符号化方法及びその装置、並びにビデオ復号化方法及びその装置
WO2018129322A1 (en) 2017-01-06 2018-07-12 Qualcomm Incorporated Multi-type-tree framework for video coding
JP2018521555A (ja) 2015-05-29 2018-08-02 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ 高度算術コーダ

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7855665B1 (en) * 2007-04-27 2010-12-21 Marvell International Ltd. Enumerative DC-RLL constrained coding
KR101510108B1 (ko) * 2009-08-17 2015-04-10 삼성전자주식회사 영상의 부호화 방법 및 장치, 그 복호화 방법 및 장치
SI2924995T1 (sl) * 2010-07-09 2018-10-30 Samsung Electronics Co., Ltd. Postopek za dekodiranje videa z uporabo združevanja blokov
EP2625855B8 (en) * 2010-10-08 2021-03-10 GE Video Compression, LLC Picture coding supporting block partitioning and block merging
CN103828364B (zh) * 2011-09-29 2018-06-12 夏普株式会社 图像解码装置、图像解码方法及图像编码装置
US8964849B2 (en) * 2011-11-01 2015-02-24 Blackberry Limited Multi-level significance maps for encoding and decoding
US9807401B2 (en) * 2011-11-01 2017-10-31 Qualcomm Incorporated Transform unit partitioning for chroma components in video coding
GB201200654D0 (en) * 2012-01-16 2012-02-29 Snell Ltd Determining aspect ratio for display of video
US9749645B2 (en) * 2012-06-22 2017-08-29 Microsoft Technology Licensing, Llc Coded-block-flag coding and derivation
WO2015139165A1 (en) * 2014-03-17 2015-09-24 Microsoft Technology Licensing, Llc Encoder-side decisions for screen content encoding
US9591325B2 (en) * 2015-01-27 2017-03-07 Microsoft Technology Licensing, Llc Special case handling for merged chroma blocks in intra block copy prediction mode
US20160234494A1 (en) * 2015-02-10 2016-08-11 Qualcomm Incorporated Restriction on palette block size in video coding
US20170064298A1 (en) * 2015-09-02 2017-03-02 Blackberry Limited Video coding with delayed reconstruction
BR112018015266A2 (pt) * 2016-02-12 2018-12-18 Thomson Licensing método e dispositivo para codificação/decodificação intra-preditiva de uma unidade de codificação compreendendo dados de imagem, a dita codificação intra-preditiva dependendo de uma árvore de predição e de uma árvore de transformadas
US10542294B2 (en) * 2016-03-16 2020-01-21 Mediatek Inc. Method and apparatus of video data processing with restricted block size in video coding
CN113411580B (zh) * 2016-05-13 2024-01-30 夏普株式会社 图像解码装置及其方法、图像编码装置及其方法
US10560718B2 (en) * 2016-05-13 2020-02-11 Qualcomm Incorporated Merge candidates for motion vector prediction for video coding
US10553091B2 (en) * 2017-03-31 2020-02-04 Qualcomm Incorporated Methods and systems for shape adaptation for merged objects in video analytics
WO2019141012A1 (en) * 2018-01-18 2019-07-25 Mediatek Inc. Video processing methods and apparatuses for processing video data coded in large size coding units
US11606575B2 (en) * 2018-07-10 2023-03-14 Qualcomm Incorporated Multiple history based non-adjacent MVPs for wavefront processing of video coding

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013517665A (ja) 2010-01-14 2013-05-16 サムスン エレクトロニクス カンパニー リミテッド 階層的データ単位のパターン情報を利用するビデオ符号化方法及びその装置、並びにビデオ復号化方法及びその装置
WO2012046435A1 (ja) 2010-10-04 2012-04-12 パナソニック株式会社 画像処理装置、画像符号化方法および画像処理方法
JP2018521555A (ja) 2015-05-29 2018-08-02 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ 高度算術コーダ
WO2018129322A1 (en) 2017-01-06 2018-07-12 Qualcomm Incorporated Multi-type-tree framework for video coding
US20180199072A1 (en) 2017-01-06 2018-07-12 Qualcomm Incorporated Multi-type-tree framework for video coding
JP2020504506A (ja) 2017-01-06 2020-02-06 クアルコム，インコーポレイテッド ビデオコーディングのためのマルチタイプツリーフレームワーク

Also Published As

Publication number Publication date
AU2018217336A1 (en) 2020-03-05
JP2021536156A (ja) 2021-12-23
TWI786032B (zh) 2022-12-01
JP7391171B2 (ja) 2023-12-04
CN116684597A (zh) 2023-09-01
WO2020033992A1 (en) 2020-02-20
TWI776072B (zh) 2022-09-01
CN116684598A (zh) 2023-09-01
CN112602327A (zh) 2021-04-02
TW202243472A (zh) 2022-11-01
US20210306679A1 (en) 2021-09-30
CN116684600A (zh) 2023-09-01
TW202010309A (zh) 2020-03-01
CN116684596A (zh) 2023-09-01
CN112602327B (zh) 2023-06-20
CN116684599A (zh) 2023-09-01
JP2023018110A (ja) 2023-02-07

Similar Documents

Publication Publication Date Title
JP7191211B2 (ja) 復号する方法、コンピュータプログラム、ビデオ復号装置
JP2023099189A (ja) ビデオサンプルの変換されたブロックを符号化および復号する方法、装置、およびシステム
JP2021530124A (ja) ビデオサンプルの変換されたブロックを符号化および復号するための方法、装置、およびシステム
JP7391171B2 (ja) ビデオサンプルの変換されたブロックを符号化および復号する方法、装置、およびシステム
JP7391167B2 (ja) 符号化ブロックを復号する方法、符号化ブロックを符号化する方法、復号装置、符号化装置
JP2023513414A (ja) ビデオサンプルのブロックを符号化および復号するための方法、装置、およびシステム
JP2023154047A (ja) ビデオサンプルのツリー若しくはブロックを符号化および復号する方法、装置、およびシステム
JP2023123706A (ja) ビデオサンプルのブロックを符号化及び復号するための方法、装置、及びプログラム
AU2018278914A1 (en) Method, apparatus and system for encoding and decoding a transformed block of video samples
JP7394875B2 (ja) ビデオサンプルのブロックを符号化並びに復号するための方法、装置、及びシステム
TWI836542B (zh) 用以編碼及解碼視訊取樣之轉換區塊的方法、設備和非暫態電腦可讀取儲存媒體
AU2018278915A1 (en) Method, apparatus and system for encoding and decoding a transformed block of video samples

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210311

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211022

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20220425

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220603

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220715

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20221107

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20221206

R151 Written notification of patent or utility model registration

Ref document number: 7191195

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151