JP7707265B2 - イントラブロックコピー仮想バッファに対するサイズ制限 - Google Patents

Description

本特許文書は、ビデオコーディング技術、装置、およびシステムに関する。

関連出願の相互参照
本出願は、2022年1月24日に提出された特願2022-504685の分割出願であり、2020年7月24日に出願された国際特許出願PCT/CN2020/104081号に基づくものである。該出願は、2019年7月25日に出願された国際特許出願PCT/CN2019/0907742、および、2019年10月7日に出願された国際特許出願番号PCT/CN2019/109849について、優先権の利益を主張するものである。前述の全ての特許出願は、その全体が参照により本明細書に組み込まれている。

ビデオ圧縮の進歩にもかかわらず、デジタルビデオは、依然として、インターネットおよび他のデジタル通信ネットワークにおける最大の帯域幅使用を占めている。ビデオの受信および表示が可能な接続ユーザデバイスの数が増加するにつれて、デジタルビデオの利用に対する帯域幅の需要は増加し続けることが予想される。

装置、システム、および方法は、デジタルビデオコーディング、そして、特には、イントラブロックコピー(intra block copy、IBC)のための一般的な仮想バッファに関連する。説明される方法は、既存のビデオコーディング規格(例えば、高効率ビデオコーディング（HEVC）)、および、将来のビデオコーディング規格またはビデオコーデックの両方に適用され得る。

一つの代表的な態様において、開示される技術は、ビデオ処理のための方法を提供するために使用され得る。この方法は、仮想パイプラインデータユニット(VPDU)のサイズ、コーディングツリーブロック(CTB)のサイズ、またはコーディングツリーユニット(CTU)のサイズに基づいて、ビデオのビデオピクチャの現在ビデオブロックと前記ビデオのコード化表現との間の変換のために、現在ビデオブロックを予測するために参照サンプルが使用されるビデオピクチャの参照領域のサイズに関して決定を行うステップと、決定に基づいて変換を実行するステップと、を含む。

さらに別の代表的な態様において、上述の方法は、プロセッサで実行可能なコードの形態で具体化され、そして、コンピュータで読取り可能なプログラム媒体に保管される。

さらに別の代表的な態様においては、上述の方法を実行するように構成された、または、動作可能なデバイスが開示される。装置は、この方法を実施するようにプログラムされたプロセッサを含んでよい。

さらに別の代表的な態様において、ビデオデコーダ装置は、ここにおいて説明される方法を実装することができる。

開示される技術に係る上記の態様および特徴は、図面、明細書、および請求項によって、より詳細に説明される。

図1は、現在ピクチャ参照の一つの例を示す図である。 図2は、JVET-M0407における動的参照領域（reference area）の例を示している。 図3は、再形成（reshaping）を伴うデコーディングフローに係るフローチャートを示している。 図4は、現在CU(602における青色)について、一つの例を示しており、赤色で埋められたブロック(604)は交差（crossing）VPDU列参照ブロック（column reference block）であり、黄色で埋められたブロック(606)は交差VPDU行（row）参照ブロックである。各大きなブロックは、64×64のVPDUを示しており、そして、緑色の領域(608)は、IBC参照のために使用され得る再形成ピクセルを示している。 図5は、本文書において説明されるビジュアルメディアデコーディングまたはビジュアルメディアエンコーディング技術を実装するためのハードウェアプラットフォームの一つの例に係るブロック図である。 図6は、開示される技術を実施することができるビデオ処理システムの一つの例に係るブロック図である。 図7Aは、開示される技術のいくつかの実装に基づくビデオ処理のための例示的な方法に係るフローチャートを示している。 図7Bは、開示される技術のいくつかの実装に基づくビデオ処理のための例示的な方法に係るフローチャートを示している。 図7Cは、開示される技術のいくつかの実装に基づくビデオ処理のための例示的な方法に係るフローチャートを示している。 図8は、開示される技術のいくつかの実装に基づく一つの例示的なビデオ処理のためのフローチャートを示している。

開示される技術の実施形態は、圧縮性能を改善するために、既存のビデオコーディング規格(例えば、HEVC、H.265)および将来の標準に対して適用され得る。本文書では、説明の可読性を向上させるためにセクション見出しを使用しており、説明または実施形態(及び／又は実装)を各セクションのみに限定するものではない。

2 ビデオコーディング紹介
より高解像度のビデオに対する要求が高まっているため、ビデオコーディング方法および技術は、現代の技術において至るところに存在している（ubiquitous）。ビデオコーデックは、典型的には、デジタルビデオを圧縮または解凍する電子回路またはソフトウェアを含み、より高い符号化効率を提供するために絶えず改良されている。ビデオコーデックは、圧縮されていないビデオを圧縮形式に変換する。ビデオ品質、ビデオを表現するために使用されるデータ量(ビットレートによって決定される)、エンコーディングおよびデコーディングアルゴリズムの複雑さ、データ損失およびエラーに対する感度、編集の容易さ、ランダムアクセス、およびエンドツーエンド遅延(待ち時間)の間には複雑な関係がある。圧縮フォーマットは、通常、標準的なビデオ圧縮仕様、例えば、高効率ビデオコーディング(High Efficiency Video Coding)規格(H.265またはMPEG-H Part2としても知られているもの)、最終化される汎用ビデオコーディング規格、または、他の現在及び／又は将来のビデオコーディング規格に準拠している。

ビデオコーディング規格は、主に、周知のITU-TおよびISO/IEC規格の開発を通じて発展してきた。ITU-TはH.261とH.263を、ISO/IECはMPEG-1とMPEG-4 Visual、そして、２つの組織はH.262/MPEG-2
VideoとH.264/MPEG-4 Advanced Video Coding(AVC)とH.265/HEVC規格を共同で作成した。H.262から、ビデオコーディング規格は、時間的予測と変換符号化が利用されるハイブリッドビデオコーディング構造に基づいている。HEVCを越える将来のビデオコーディング技術を探求するため、2015年にVCEGとMPEGが共同で共同ビデオ探査チーム(Joint Video Exploration Team、JVET)を設立した。それ以来、JVETによって多くの新しい方法が採用され、JEM(Joint Exploration Model)と名付けられた参照ソフトウェアに入れられた。2018年4月には、VCEG(Q6/16)とISO/IEC JTC1 SC29/WG11(MPEG)の合同ビデオエキスパートチーム(JVET)を発足させ、HEVCに対して50%のビットレート低減を目指すVVC規格に取り組んでいる。

2.1 HEVC/H.265におけるイントラ予測
各イントラ予測PUは、１つまたは２つの参照ピクチャリストのための動きパラメータを有する。動きパラメータは、動きベクトルおよび参照ピクチャインデックスを含む。２つの参照ピクチャリストの１つの使用は、また、inter_pred_idcを使用して信号化され得る。動きベクトルは、予測因子（predictor）に対してデルタとして明示的にコード化されてよい。

CUがスキップモードでコード化される場合、１つのPUはCUと関連付けられ、有意な残差係数、コード化動きベクトルデルタ、または、参照ピクチャは存在しない。マージモードは、現在PUのための動きパラメータが、空間的および時間的な候補を含む隣接PUから取得されるように指定される。マージモードは、スキップモードだけでなく、任意のイントラ予測PUに適用することができる。マージモードの代わりは、動きパラメータの明示的な伝送であり、ここで、動きベクトル(より正確には、動きベクトル予測器と比較した動きベクトル差(MVD))、各参照ピクチャリストについて対応する参照ピクチャインデックス、および、参照ピクチャリスト使用は、各PUごとに明示的に信号化される。そうしたモードは、本開示においては、高度な動きベクトル予測（Advanced motion vector prediction、AMVP）と呼ばれる。

２つの参照ピクチャリストのうち１つが使用されるべきであることをシグナリング（signaling）が示す場合、PUは、サンプルの１つのブロックから生成される。これは「単予測（“uni-prediction”）」と呼ばれる。単予測は、P-スライスとB-スライスの両方について利用可能である。

両方の参照ピクチャリストが使用されるべきであることをシグナリングが示す場合、PUは、２つのサンプルブロックから生成される。これは「双予測（“bi-prediction”）」と呼ばれる。双予測は、B-sliceのみについて利用可能である。

以下のテキストは、HEVCで指定されたイントラ予測モードの詳細を示している。説明はマージモードで始まる。

2.2 現在ピクチャ参照
HEVCスクリーンコンテンツコーディング拡張(HEVC‐SCC)および現在のVVCテストモデル(VTM‐3.0)では、現在ピクチャ参照(Current Picture Referencing、CPR)、またはイントラブロックコピー(IBC)として一旦命名されたものが採用されている。IBCは、動き補償の概念を、インターフレーム（inter-frame）コーディングからイントラフレーム（intra-frame）コーディングに拡張する。図1に示されるように、現在ブロックは、CPRが適用されたときに同じピクチャ内の参照ブロックによって予測される。参照ブロック内のサンプルは、現在ブロックがコーディングまたはデコーディングされる前に、既に再形成されていなければならない。大部分のカメラでキャプチャされた（camera-captured）シーケンスにおいて、CPRは、それほど効率的ではないが、スクリーンコンテンツのコード化には大きな利点がある。その理由は、スクリーンコンテンツピクチャにはアイコンやテキスト文字などの反復パターンが多数存在するためである。CPRは、これらの反復パターン間の冗長性を効果的に除去することができる。HEVC‐SCCでは、現在ピクチャを参照ピクチャとして選択する場合、インターコード化（inter-coded）コーディングユニット(CU)はCPRを適用することができる。この場合、MVは、ブロックベクトル(BV)として名称変更され、そして、BVは常に整数ピクセル精度（integer-pixel precision）を有する。メインプロファイルHEVCとの互換性のために、現在ピクチャは、デコードピクチャバッファ(DPB)において「長期（“long-term”）」参照ピクチャとしてマークされ、同様に、マルチビュー／3Dビデオコーディング規格において、インタービュー（inter-view）参照ピクチャも、また、「長期」参照ピクチャとしてマーク付けされることに注意すべきである。

BVが、その参照ブロックを見つけた後で、参照ブロックをコピーすることにより予測を生成することができる。残差（residual）は、元の信号から基準ピクセルを差し引くことによって得ることができる。次いで、変換および量子化は、他のコーディングモードと同様に適用することができる。

しかしながら、参照ブロックがピクチャの外側にある場合、現在ブロックとオーバーラップする場合、再形成された領域の外側にある場合、または、いくつかの制約によって制限されている有効領域の外側にある場合には、部分または全部のピクセル値が定義されない。このような問題に対処するためには、基本的に２つのソリューションが存在している。一方は、例えば、ビットストリーム適合において、そうした状況を許容しないことである。他方は、未定義のピクセル値にパディングを適用することである。以下のサブセッションは、ソリューションを詳細に説明する。

2.3 HEVCスクリーンコンテンツコーディング拡張におけるCPR
HEVCスクリーンコンテンツコーディング拡張において、ブロックが現在ピクチャを参照として使用する場合、次の仕様テキストに示されるように、参照ブロック全体が利用可能な再形成領域内にあることを保証すべきである。

従って、参照ブロックが現在ブロックとオーバーラップし、または、参照ブロックがピクチャの外側にある、場合は発生しない。参照ブロックや予測ブロックを埋める（pad）必要はない。

2.4 VVCテストモデルにおけるCPR/IBC
現在のVVCテストモデル、すなわち、VTM-3.0デザインでは、参照ブロック全体は現在コーディングツリーユニット(CTU)であるべきであり、そして、現在ブロックとオーバーラップしない。従って、参照ブロックまたは予測ブロックを埋める必要はない。

デュアルツリーをイネーブルする場合、ルマCTUからクロマCTUまで、パーティション構造が異なってよい。従って、4:2:0カラーフォーマットについて、１つのクロマブロック(例えば、CU)は、複数のルマCUに分割された１つの共配置された（collocated）ルマ領域に対応し得る。

クロマブロックは、以下の条件が真である場合のみ、CPRモードでコード化され得る。

(1)共配置されたルマブロック内の各ルマCUは、CPRモードでコード化される。

(2)ルマ4×4ブロックのBVそれぞれは、まずクロマブロックのBVに変換され、かつ、クロマブロックのBVは有効なBVである。

２つの条件のいずれかが偽（false）である場合、クロマブロックはCPRモードでコード化されない。

「有効なBV（“valid BV”）」の定義には、以下の制約があることに注意する。

(1)BVによって識別される参照ブロック内の全てのサンプルは、制限された検索範囲内でなければならない(例えば、現在のVVCデザインにおける同一のCTU内にある)。

(2)BVによって識別される参照ブロック内の全てのサンプルが、再形成されている。

2.5 JVET-L0297/JVET-M0407/JVET-M0408におけるCPR/IBC
VTM3.0では、CPR/IBCの参照領域は現在CTU、128×128まで、に限定されている。JVET-L0297/JVET-M0407/JVET-M0408では、CPR/IBCブロックがより多くの参照候補を有し、一方で、CPR/IBCの参照バッファが１つのCTUから維持または縮小できるように、参照領域を動的に再利用メモリに変更してCPR/IBCの参照サンプルを保管する方法を提示している。

図2は、ブロックが64×64であり、CTUが4個の64×64ブロックを含む方法を示している。64×64ブロックをコーディングする場合、以前の3個の64×64ブロックを参照として使用することができる。そうすることにより、デコーダは、CPR/IBCをサポートするために、4個の64×64ブロックを保管することだけが必要である。上記の方法はVTM4.0に採用された。

ピクチャの左上隅に対する現在のルマCUの位置が(x,y)であり、かつ、ブロックベクトルが(BVx,BVy)であるとする。現在のデザインでは、BVが有効であるかは、ルマ位置((x+BVx)>6<6+(1<7),(y+BVy)>>6<6)は再形成されておらず、かつ、((x+BVx)>6<6+(1<7),(y+BVy)>>6<6)が(x>6<6,<y>6<6)と等しくないことによって分かる。

2.6 JVET-O1170で提案されている仮想IBCバッファ
IBC予測モードのための参照領域を記述するのに役立つ仮想バッファ概念が導入された。CTUサイズがctbSizeである場合、wIbcBuf=128*128/ctbSizeを示し、仮想IBCバッファ、ibcBufを定義する。幅はwIbcBufであり、かつ、高さはctbSizeである。従って、以下のようである。

－CTUサイズが128×128の場合、ibcBufのサイズも、また、128×128である。

－CTUサイズが64×64の場合、ibcBufのサイズは256×64である。

－CTUサイズが32×32の場合、ibcBufのサイズは512×32である。

VPDUの幅と高さは、min(ctbSize,64)であることに留意されたい。Wv=min(ctbSize,64)を示す。

仮想IBCバッファibcBufは、以下のように維持される。

(1)各CTU行のデコーディングの開始時に、ibcBuf全体を値(-1)でリフレッシュする。

(2)ピクチャの左上隅に対するVPDU(xVPDU,yVPDU)のデコーディングの開始時に、ibcBuf[x][y]=-1を設定する。x=xVPDU%wIbcBuf,...,xVPDU%wIbcBuf+Wv-1;y=yVPDU%ctbSize,...,yVPDU%ctbSize+Wv-1である。

(3)デコーディング後、CUはピクチャの左上に対して(x,y)を含み、以下を設定する。

ibcBuf[x%wIbcBuf][y%ctbSize]=recSample[x][y]

従って、ビットストリーム制約は、単純に次のように記述できる。

IBC参照バッファの概念で、サブブロックプロセスを含む、補間および動き補償プロセスへの参照を回避することにより、デコーディングプロセスのテキストも、また、単純化する。

2.7 VPDU
仮想パイプラインデータユニット(Virtual pipeline data unit、VPDU)は、ピクチャ内の非オーバーラップ（non-overlapping）ユニットとして定義される。ハードウェアデコーダでは、連続するVPDUが複数のパイプラインステージ（stage）によって同時に処理される。VPDUサイズは、大部分のパイプラインステージにおいてバッファサイズにほぼ比例するため、VPDUサイズを小さく保つことが重要である。大部分のハードウェアデコーダでは、VPDUサイズが最大変換ブロック(TB)サイズに設定できる。しかしながら、VVCでは、３値ツリー(ternary tree、TT)および２値ツリー(binary tree、BT)パーティションは、VPDUサイズの増加を導き得る。

VPDUサイズを64×64ルマサンプルとして維持するために、VTM5では以下の標準的なパーティション制限(シンタックスシグナリング修正を含む)が適用される。

－幅または高さのいずれか、もしくは、幅と高さの両方が128に等しいCUについて、TT分割は許可されない。

－N≦64(すなわち、幅が128に等しく、かつ、高さが128未満)の128×NのCUについて、水平BTは許可されない。

－N≦64(すなわち、幅が128に等しく、かつ、高さが128未満)のN×128のCUについて、垂直BTは許可されない。

VVCでは、一般的に、ルマサンプルにおいてVPDUの幅と高さはmin(64,CtbSizeY)であることが合意されている。従って、CTB/CTUサイズが64×64、128×128、256×256である場合、VPDUサイズは64×64である。CTB/CTUサイズが32×32の場合、VPDUサイズは32×32である。

2.8 イントラブロックコピーのためのバッファ管理とブロックベクトルコーディング
種々のIBCバッファの特徴および対応する管理の詳細は、PCT/CN2019/093552において記載されており、これは参照により組み込まれている。

2.9 JVET-M0427におけるインループ再形成(ILR)
インループ再形成(in-loop reshaping、ILR)の基本的なアイデアは、元の(第１ドメイン)信号(予測／再形成信号)を第２ドメイン(再形成ドメイン)に変換することである。

インループルマ再形成は、ルックアップテーブル(LUT)のペアとして実装されるが、２つのLUTのうちの１つだけが信号化される必要がある。他方は、信号化されたLUTから計算できるからである。各LUTは一次元、10ビット、1024エントリマッピングテーブル(1D-LUT)である。一方のLUTは、前方（forward）LUT、FwdLUTであり、入力ルマコード値Y_iを変更された値Y_rにマップする、Y_r=FwdLUT[Y_i]。他方のLUTは、逆（inverse）LUT、InvLUTであり、変更されたコード値Y_rをY^_iにマップする、Y^_i=InvLUT[Y_r]（Y^_iは、Y_iの再形成値を表す）。

2.9.1 PWLモデル
概念的に、区分線形(piece-wise linear、PWL)は、以下のように実装される。

x1、x2を２つの入力ピボット点、y1,y2を１ピースの対応する出力ピボット点とする。x1とx2の間の任意の入力値xに対する出力値yは、以下の式で補間され得る。

y=((y2-y1)/(x2-x1))*(x-x1)+y1

固定小数点実装では、次のように等式を書き換えることができる。

y=((m*x+2FP_PREC-1)>>FP_PREC)+c

ここで、mはスカラー、cはオフセット、そして、FP_PRECは精度を指定するための定数値である。

CE-12ソフトウェアにおいて、PWLモデルは1024エントリのFwdLUTおよびInvLUTマッピングテーブルを予め計算するために使用されるが、PWLモデルは、また、LUTを予め計算することなく、実装がオンザフライで同一のマッピング値を計算することを可能にすることに注意すること。

2.9.2 CE12-2試験
2.9.2.1 ルマ再形成
インループルマ再形成の試験2(すなわち、提案のCE12-2)は、複雑度の低いパイプラインを提供し、インタースライス再形成におけるブロック毎のイントラ予測のためのデコーディング待ち時間（latency）も、また、排除する。イントラ予測は、インタースライスとイントラスライスの両方に対して再形成ドメインで実行される。

イントラ予測は、スライスのタイプに関係なく、いつでも再形成ドメインで実行される。このような構成では、以前のTU再構成（reconstruction）が行われた直後にイントラ予測を開始できる。このような配置は、また、スライス依存性である代わりに、イントラモードに対して統一されたプロセスを提供することもできる。図3は、モードに基づくCE12-2デコーディングプロセスのブロック図を示している。

CE12-2は、また、CE12-1の32ピースPWLモデルの代わりに、ルマおよびクロマ残差スケーリングについて16ピース区分線形(PWL)モデルを試験する。

インタースライス再形成はCE12-2におけるインループルマ再形成を伴う(より明るい陰影ブロックは、再形成ドメイン内の信号を示す。ルマ残基、イントラルマ予測、およびイントラルマ再形成である)

2.9.2.2 ルマ依存クロマ残差スケーリング
ルマ依存クロマ残差スケーリング（luma-dependent chroma residue scaling）は、固定小数点整数演算で実装される乗法プロセスである。クロマ残差スケーリングは、クロマシグナルとルマシグナルの相互作用を補償する。クロマ残差スケーリングはTUレベルで適用される。より具体的には、以下が適用される。

－イントラについて、再形成ルマは平均化される。

－インターについて、予測ルマは平均化される。

平均値は、PWLモデルのインデックスを識別するために使用される。インデックスは、スケーリング係数cScaleInvを識別する。クロマの残差が、その数によって乗算される。

クロマスケーリング係数は、再形成されたルマ値ではなく、むしろ前方マップ予測ルマ値から計算されることに留意されたい。

2.9.2.3 ILR側情報のシグナリング
パラメータは(現在)タイルグループヘッダにおいて送信される(ALFと同様)。これらは40－100ビットを要すると言われている。

2.9.2.4 ILRの使用
エンコーダ側では、各ピクチャ(またはタイルグループ)が最初に再形成ドメインに変換される。そして、全てのコーディングプロセスは、再形成されたドメインで実行される。イントラ予測について、隣接ブロックは再形成ドメイン内にあり、イントラ予測について、参照ブロック(デコードされたピクチャバッファからの元のドメインから生成されたもの)は、最初に再形成ドメインに変換される。次いで、残差が生成され、そして、ビットストリームにコード化される。

ピクチャ全体(またはタイルグループ)のエンコーディング／デコーディングが終了した後で、再形成ドメイン内のサンプルは元のドメインに変換され、次いで、デブロッキング（deblocking）フィルタおよび他のフィルタが適用される。

以下の場合について、予測信号への前方再形成（forward reshaping）がディセーブルされる。

○現在ブロックがイントラコード化される。

○現在ブロックがCPR(現在ピクチャ参照（current picture referencing）、別名イントラブロックコピー（intra block copy、IBC）)としてコード化される。

○現在ブロックは結合インター－イントラモード(combined inter-intra mode、CIIP)としてコード化され、そして、イントラ予測ブロックについて前方再形成はディセーブルされる。

3 既存の実装の欠点
IBC仮想バッファの現在のデザインでは、いくつかの問題が存在している。

(1)CTUサイズが128×128より大きい場合のIBC仮想バッファの維持方法が定義されていないこと。

(2)仮想バッファサイズと参照サンプルサイズの関係が明確でないこと。

(3)IBCモードについてラインバッファ、および、CTUについてBVが削減され得ること。

(4)サブピクチャが制限され過ぎる可能性があること。

(5)クロマQPテーブルが正しい方法でデザインされない可能性があること。

4 IBCについて一般的な仮想バッファのための例示的な方法
VPDUの幅と高さをvSizeによって示す。例えば、vSize=min(64,ctbSizeY)であり、ここで、ctbSizeYはルマCTB/CTUの幅／高さである。

本開示の技術の実施形態は、既存の実施形態の欠点を克服し、それにより、より高い符号化効率を有するビデオコーディングを提供する。開示される技術に基づいて、IBCについて一般的な仮想バッファのための方法は、既存および将来のビデオコーディング規格の両方を向上させる可能性があり、種々の実装について説明される以下の実施例において解明される。以下に提供された開示される技術の例は、一般的な概念を説明するものであり、そして、限定的なものとして解釈されるように意図されてはいない。例において、明示的に反対に示されない限り、これらの実施例において説明される種々の特徴を組み合わせることができる。
IBCバッファ関連
1.IBC仮想バッファのサイズ(例えば、ブロックベクトルまたはマップされたサンプルが妥当か否かを決定するために使用されるもの)は、VPDUサイズ、CTB/CTUサイズに依存し得る。
a.一つの例において、仮想バッファの幅×高さは固定されてよい。しかしながら、仮想バッファの幅及び／又は高さは、VPDUサイズ及び／又はCTB/CTUサイズに依存し得る。
b.一つの例において、仮想バッファの高さは、CTB/CTUの高さに等しくてよい。
i.代替的に、さらに、仮想バッファの幅が(IBC仮想バッファのサイズ/CTBの高さ)に設定され得る。
c.一つの例において、仮想バッファの幅は、CTB/CTUの幅に等しくてよい。
d.一つの例において、仮想バッファの幅は、VPDU幅の１倍または複数倍であってよい。
e.一つの例において、仮想バッファの高さは、VPDU高さの１倍または複数倍であってよい。
2.IBC BV探索領域について必要とされるメモリサイズと比較して、より大きなIBC仮想バッファサイズを割り当てることが提案されている。
a.一つの例において、IBC仮想バッファサイズは、IBCに使用されるVPDUメモリの合計サイズよりも大きくてよい。
i.一つの例において、１つ以上のCTUがIBC仮想バッファに割り当てられ得る。
b.一つの例において、IBC仮想バッファサイズの幅は、(128*128/ctbSizeY+ctbSizeY)であってよい。
c.一つの例において、IBC仮想バッファサイズの幅は(128*128/ctbSizeY+ctbSizeY)であってよく、かつ、IBC仮想バッファサイズの高さはctbSizeYであってよい。
d.一つの例において、IBC仮想バッファの幅は(256*128/ctbSizeY)であってよい。代替的に、IBC仮想バッファの高さは、ctbSizeYであってよい。
e.一つの例において、より大きなIBC仮想バッファをより大きなCTU/CTBに割り当てることができる。
i.一つの例において、CTUサイズがK(例えば、K=128)より小さくない場合、IBC仮想バッファの幅は(128×128/ctbSizeY+ctbSizeY)であってよい。代替的に、IBC仮想バッファの高さは、ctbSizeYであってよい。
ii.一つの例において、CTUサイズがK(例えば、K=128)より小さい場合、IBC仮想バッファの幅は(128×128/ctbSizeY)であってよい。代替的に、IBC仮想バッファの高さは、ctbSizeYであってよい。
3.IBCブロックの参照ブロックは、特定のVPDU行またはVPDU列内に完全に存在するように制約されてよい。
a.一つの例において、参照ブロックは、異なるVPDU行を横切る（cross）ことを禁止され得る。
b.一つの例において、参照ブロックは、異なるVPDU列を横切ることを禁止され得る。
c.一つの例において、上記のVPDU行または列は、ピクチャに対して相対的であり得る。
d.一つの例において、上記のVPDU行または列は、IBC仮想バッファに対して相対的であり得る。
e.代替的に、BVが指す参照ブロックが２つ以上のCTU/CTBを横切る場合には、上記の方法が起動され得る。
4.IBCブロックに対する参照ブロックは、複数のVPDUを横切り、異なるVPDU行／VPDU列を横切ることができる。しかしながら、参照ブロックのいくつかの予測値を埋めるために、追加の操作が必要とされ得る。
a.一つの例において、いくつかのデフォルト値が、いくつかの予測値を埋めるために利用され得る。
5.範囲制約（range constrain）は、IBCモードで使用されるブロックベクトル(BV)及び／又はブロックベクトル差(BVD)に適用され得る。
a.一つの例において、BV/BVDの許容範囲は、現在ブロックをカバーするCTU/CTBに対するコーディネータといった、現在IBCコーディングブロックの位置に依存し得る。
b.一つの例において、ブロックベクトルは[-2^m,2^m-1]の範囲で制約され得る。
c.一つの例において、精度変換後のブロックベクトル差は、[-2ⁿ,2ⁿ-1]の範囲に制約され得る。
d.一つの例において、精度変換後のブロックベクトル差は、[-2ⁿ+1,2ⁿ-1]の範囲に制約され得る。
e.一つの例において、ビットストリームにおいて信号化されたブロックベクトル差は、[-2ⁿ,2ⁿ-1]の範囲で制約され得る。
f.一つの例において、ビットストリームにおいて信号化されたブロックベクトル差は、[-2ⁿ+1,2ⁿ-1]の範囲で制約され得る。
g.一つの例において、mは18、または17、または15に設定されている。
h.一つの例において、nは17、または16、または14に設定されている。
i.一つの例において、m及び／又nは、BV/動きベクトルストレージの精度及び／又はブロックベクトル差に関連する精度に依存し得る。
j.一つの例において、ブロックベクトルは、イントラ予測モードのために使用される動きベクトルと同じ範囲内に制約され得る。
k.一つの例において、ブロックベクトル差は、イントラ予測モードのために使用される動きベクトルのベクトルと同じ範囲内に制約され得る。
l.一つの例において、適合性ビットストリーム（conformance bitstream）は、上記のサブ項目（sub-bullet）が満たされることを満足する。
i.代替的に、BV/BVDがブロックをエンコーディング／デコーディングするために利用される前に、BV/BVDへのクリッピングプロセスがデコードされたBV/BVDに適用され得る。
6.IBC仮想バッファにマップされた利用可能なサンプルの数が制限され得る。
a.一つの例において、バッファにマップされた利用可能なサンプルの最大数は、IBC仮想バッファサイズよりも小さくてよい。
b.一つの例において、CTB/CTUサイズが64×64より大きい場合、IBC仮想バッファにマップされた利用可能なサンプルの最大数が固定され得る。
c.一つの例において、IBC仮想バッファにマップされた利用可能なサンプルの数は、VPDU内のサンプルの数の１倍または複数倍より小さくなるように制限され得る。
i.一つの例において、IBC仮想バッファにマップされた利用可能なサンプルの数は、CTU/CTBサイズが64×64より大きい場合、VPDU内のサンプルの数の３倍以下になるように制限され得る。
7.IBC仮想バッファにマップされたIBC参照サンプルの使用不可（unavailability）マーキングは、VPDUの粒度（granularity）で実行できる。
a.一つの例において、サンプルが使用不可としてマーク付けされる必要がある場合、同じVPDU内のサンプルも、また、使用不可としてマーク付けされ得る。
b.一つの例において、１つまたは複数のVPDUが同時に使用不可としてマークされ得る。
c.一つの例において、どのVPDUのサンプルが使用不可にマーク付けされるかは、現在のVPDUの位置に依存し得る。
d.一つの例において、どのVPDUのサンプルが使用不可にマークされてるかは、以前の、または、直近にデコードされたVPDUの位置に依存し得る。
8.CTU/CTBサイズが64×64より大きい場合、IBC参照は、現在VPDUおよび直近にデコードされた３つのVPDUであり得る。
a.一つの例において、各VPDUのデコーディング順序を追跡（track）するために、仮想IBCバッファにマップされた各VPDUについてインデックスが維持され得る。
9.カウンタは、バッファにマップされた利用可能なVPDUの数を追跡するために維持され得る。
a.一つの例において、カウンタは、各CTU行のデコードの開始時に0にリセットされ、そして、バッファにマップされた１つのVPDUがデコードされた時に１だけ増加される。
b.一つの例において、カウンタが所定の値、例えば３、より大きい場合、バッファにマップされた１つのVPDUのサンプルは、使用不可としてマークされ得る。そして、カウンタは、1だけ減少され得る。
10.CTU/CTBサイズが128×128の場合、対応するIBC仮想バッファはサイズ256×128であってよい。
a.代替的に、IBC仮想バッファは、サイズ(k*64)×128であってよい。ここで、k>2である。
11.CTU/CTBサイズが256×256の場合、対応するIBC仮想バッファは、参照サンプルの利用可能性を追跡するために、サイズ64×256であってよい。すなわち、ibcBufW=64、ibcBufH=256である。
a.一つの例において、左上位置(x0,y0)を有するVPDUをデコードする前に、IBCバッファ内の対応するVPDU行(0,y0%256)が-1に設定される。
12.CTU/CTBサイズが256×256の場合、対応するIBC仮想バッファは、参照サンプルの利用可能性を追跡するために128×256のサイズであってよい。すなわち、ibcBufW=128、ibcBufH=256である。
a.一つの例において、所定のVPDU行を除いて、バッファ内の各VPDU行に対して、１つのVPDUのみを保持することができる(現在VPDUを除く)。
i.一つの例において、最後のVPDU行を除いて、バッファ内の各VPDU行に対して１つのVPDUのみを保持することができる(現在VPDUを除く)。
13.CTU行の先頭では、IBCバッファはリセットされないことがある。
a.一つの例において、上記のCTU行から継承されたIBC仮想バッファは、現在CTU行の初期状態として使用され得る。
b.代替的に、IBC仮想バッファは、CTU行の開始時に部分的にリセットされ得る。
i.一つの例において、上記CTU行のVPDUが現在IBCバッファに継承され、一方で、他のバッファ領域がリセットされ得る。
ii.一つの例において、上記CTU行の最も左下VPDUが現在IBCバッファに継承され、一方で、他のバッファ領域がリセットされ得る。
14.バッファ内のサンプルを使用不可としてマーク付けするか否か、及び／又は、どのようにマーク付けするかは、クロマブロックの位置に依存しないことがある。
a.一つの例において、ルマブロックがVPDU内の第１ブロックである場合のみ、IBCバッファ内の対応するサンプルが使用不可としてマークされ得る。
b.一つの例において、クロマコーディングユニットをデコードするときに、バッファ内のサンプルをリセットし、または、使用不可としてマークすることが許容されないことがある。
15.各VPDUのデコーディングの開始時に、現在VPDUの位置に基づいて対応するIBC仮想バッファ領域がリセットされ得ることが提案されている。
a.一つの例において、(xVPDU+ctbSizeY,yVPDU)に対応するIBC仮想バッファ領域がリセットされる。ここで、(xVPDU,yVPDU)は、ピクチャの左上に対する現在VPDUの位置を示す。
16.IBC仮想バッファ内のサンプルをマーク付けするか否か、及び／又は、どのようにマーク付けするかは、直近にデコードされたVPDUの位置とVPDUサイズに依存し得る。
a.一つの例において、IBC仮想バッファ内のサンプルを使用不可としてマーク付けするか否か、及び／又は、どのようにマーク付けするかは、ブリック／スライス／タイル／ピクチャの直近にデコードされたVPDUの位置に依存し得る。
b.一つの例において、IBC仮想バッファ内のサンプルを使用不可としてマーク付けするか否か、及び／又は、どのようにマーク付けするかは、ブリック／スライス／タイル/ピクチャのCTU行内の直近にデコードされたVPDUの位置に依存し得る。
c.一つの例において、IBC仮想バッファ内のどのサンプルが使用不可としてマーク付けされるかは、現在ブロックの位置とは独立であってよい。

IBCラインバッファ関連
17.CTU行全体にわたる（acrossing）ブロックベクトル予測は、許容されないことがある。
a.一つの例において、ブロックベクトル予測が現在CTU行と比べて異なるCTU行からのものである場合、それは使用不可とみなされ得る。
18.CTU行にわたる現在IBCブロックに対するデブロッキングの決定は、他のブロックのブロックベクトルまたは動きベクトルとは独立であってよい。
a.一つの例において、２つのブロックが異なるCTU行であり、そして、一方のブロックがIBCモードでコード化され、かつ、他方がIBCまたはインターモードでコード化される場合、デブロッキング境界強度は常に１に等しく設定され得る。
b.一つの例において、２つのブロックが異なるCTU行であり、そして、一方のブロックがIBCモードでコード化され、かつ、他方がIBCまたはインターモードでコード化される場合、デブロッキング境界強度は常に0に等しく設定され得る。
19.CTU行にわたる現在IBCブロックに対するデブロッキングの決定は、他のブロックがIBCモードでコード化されているか、または、インターモードでコード化されているかに依存しなくてよい。
a.一つの例において、２つのブロックが異なるCTU行であり、そして、一方のブロックがIBCモードでコード化され、かつ、他方がイントラモードでコード化されない場合、デブロッキング境界強度は常に1に等しく設定され得る。

関連するサブピクチャ
20.所定の条件下で２つのサブピクチャ間の予測(例えば、動き／サンプル予測)を可能にすることが提案されている。
a.一つの例において、第１サブピクチャの境界がピクチャ境界(または、適合性ウィンドウ境界)と一致する場合、第２サブピクチャからの情報を使用することが許容され得る。
i.代替的に、さらに、サブピクチャ境界は、左または右のサブピクチャ境界である。
ii.代替的に、ピクチャ境界は、左または右のピクチャ境界である。
iii.一つの例において、第２サブピクチャの左(または、右)境界は、ピクチャの左(または、右)境界と一致し得る。
b.ピクチャのラッピングが許可されている場合のみ(例えば、sps_ref_wraparound_enabled_flagが1に等しい)、条件は真である。
21.ピクチャラッピング（picture wrapping）は、サブピクチャを除外する。
a.一つの例において、サブピクチャが使用されている場合に、ピクチャラッピングは、イネーブルされる。
b.一つの例において、ピクチャラッピングがイネーブルされている場合、サブピクチャは使用できない。
c.代替的に、サブピクチャが使用されるときに、ピクチャラッピングがイネーブルされ得る。
iv.一つの例において、ピクチャラッピングは、ピクチャ境界と一致する境界を有するサブピクチャに対してイネーブルされ得る。

関連するクロマQPテーブル
22.クロマQPテーブルの最小インデックスは、クロマ成分のビット深度に依存しなくてよい。
a.一つの例において、クロマQPテーブルの最小インデックスは、ルマ成分のビット深度に依存し得る。
b.一つの例において、クロマQPテーブルの最小インデックスは、QpBdOffset_Y、すなわち6*bit_depth_luma_minus8であってよい。

5 開示される技術の実施例
5.1 実施形態#1
CTUサイズが256×256の場合、64×256のIBC仮想バッファibcBufが維持される、すなわちibcBufW=64、ibcBufH=256である。VPDUサイズは64×64であり、そして、現在VPDUの他に、3個のVPDUのオンチップメモリがIBC参照サンプルを保管するために使用される。

バッファibcBufは、CTU行のデコーディングの開始時に-1にリセットされる。

ピクチャの左上隅に対する左上位置(x0,y0)を有する新たなVPDUのデコーディングの開始時に、以下が適用される。

1)x=x0..x0+63、y=y0..y0+63について、ibcBuf[x%ibcBufW][y%ibcBufH]=-1

2)CUをデコーディングした後、ピクチャの左上隅に対するそのCU内の(x,y)について、インループフィルタリング、例えば、SAO、デブロッキング、ALFの前に、サンプル(x,y)の再形成値としてibcBuf[x%ibcBufW][y%ibcBufH]を設定する。

3)bvが与えられると、(x,y)のリファレンスはibcBuf[(x+bv[0])%ibcBufW][(y+bv[1])%ibcBufH]である。

以下の２つの条件が真であることが、ビットストリームの制約である

1)ピクチャの左上に対する位置(x,y)を有するW×Hブロックが与えられると、(y%ibcBufH)+H<=ibcBufHである。

2)ibcBuf[(x+bv[0])%ibcBufW][(y+bv[1])%ibcBufH]は、無効なピクセル値を含まない。例えば、x=0..W-1、y=0..H-1に対して-1である。

5.2 実施形態#2
CTUサイズが256×256の場合、128×256のIBC仮想バッファibcBufが維持される、すなわちibcBufW=128、ibcBufH=256である。VPDUサイズは64×64であり、そして、現在VPDUの他に、3個のVPDUのオンチップメモリがIBC参照サンプルを保管するために使用される。

バッファibcBufは、CTU行のデコーディングの開始時に-1にリセットされる。xPrevVPDU=0かつyPrevVPDU=0である。

ピクチャの左上隅に対する左上位置(x0,y0)を有する新たなVPDUのデコーディングの開始時に、以下が適用される。

1)(yPrevVPDU+64)%ibcBufHが0に等しくない場合、

x=x0..x0+63、y=y0..y0+63について、
ibcBuf[(x+xPrevVPDU-64)%ibcBufW][(y+yPrevVPDU)%ibcBufH]=-1

2)それ以外の場合((yPrevVPDU+64)%ibcBufHが0に等しい)、

x=x0..x0+63、y=y0..y0+63について、
ibcBuf[(x+xPrevVPDU)%ibcBufW][(y+yPrevVPDU)%ibcBufH]=-1

3)xPrevVPDU=x0かつyPrevVPDU=y0

以下の２つの条件が真であることが、ビットストリームの制約である

1) ピクチャの左上に対する位置(x,y)を有するWxHブロックが与えられると、(y%ibcBufH)+H<=ibcBufHである。

2)ibcBuf[(x+bv[0])%ibcBufW][(y+bv[1])%ibcBufH]は、無効なピクセル値を含まない。例えば、x=0..W-1、y=0..H-1に対して-1である。

図4は、VPDU列およびVPDU行を交差している（crossing）参照ブロックの例を示している。図4に示されるように、現在CU(青色の602)について、赤色(604)で埋められたブロックは交差VPDU列参照ブロックであり、そして、黄色(606)で埋められたブロックは交差VPDU行参照ブロックである。各大きなブロックは、64×64のVPDUを示しており、そして、緑色の領域(608)は、IBC参照のために使用され得る再形成ピクセルを示している。

図5は、ビデオ処理装置500のブロック図である。装置500は、ここにおいて説明される１つ以上の方法を実装するために使用され得る。装置500は、スマートフォン、タブレット、コンピュータ、モノのインターネット(IoT)受信器、等で具体化することができる。装置500は、１つ以上のプロセッサ502、１つ以上のメモリ504、およびビデオ処理ハードウェア506を含んでよい。プロセッサ502は、本文書に記載される１つ以上の方法(方法400を含むが、これに限定されない)を実装するように構成され得る。メモリ(複数のメモリ)504は、ここにおいて説明される方法および技術を実施するために使用されるデータおよびコードを保管するために使用され得る。ビデオ処理ハードウェア506は、ハードウェア回路において、本文書に記載されるいくつかの技術を実装するために使用され得る。

図6は、ここにおいて開示される様々な技術が実装され得る例示的なビデオ処理システム1900を示すブロック図である。種々の実装は、システム1900のコンポーネントの一部または全部を含み得る。システム1900は、ビデオコンテンツを受信するための入力1902を含み得る。ビデオコンテンツは、生（raw）または非圧縮フォーマット、例えば、8または10ビットのマルチコンポーネント値で受信されてよく、または、圧縮または符号化フォーマットで受信されてもよい。入力1902は、ネットワークインターフェイス、ペリフェラルバスインターフェイス、または、ストレージインターフェイスを表すことができる。ネットワークインターフェイスの例は、イーサネット、受動光ネットワーク（passive optical network、PON）、等といった有線インターフェイス、および、Wi-Fi（登録商標）またはセルラーインターフェイスといった無線インターフェイスを含む。

システム1900は、本文書に記載される種々のコーディングまたは符号化方法を実装することができる符号化コンポーネント1904を含み得る。符号化コンポーネント1904は、入力1902から符号化コンポーネント1904の出力までのビデオの平均ビットレートを低減して、ビデオのコード化表現を生成することができる。従って、コーディング技術は、ときどき、ビデオ圧縮またはビデオトランスコーディング技術と呼ばれる。符号化コンポーネント1904の出力は、コンポーネント1906によって表されるように、保管され、または、接続された通信を介して送信され得る。入力1902で受信されたビデオの保管され、または、通信されたビットストリーム(または、コード化)表現は、ディスプレイインターフェイス1910に送られる画素値、または、表示可能なビデオを生成するために、コンポーネント1908によって使用されてよい。ビットストリーム表現からユーザが見ることができるビデオを生成するプロセスは、ときどき、ビデオ解凍（decompression）と呼ばれる。さらに、所定のビデオ処理操作は、「コーディング（“coding”）」操作またはツールと称されるが、コーディングツールまたは操作は、エンコーダで使用され、そして、コーディングの結果を反転する、対応しているデコーディングツールまたは操作は、デコーダで実行されることが理解されるだろう。

ペリフェラルバスインターフェイスまたはディスプレイインターフェイスの例は、ユニバーサルシリアルバス（USB）、または高精細度マルチメディアインターフェイス（HDMI（登録商標））、またはディスプレイポート、などを含み得る。ストレージインターフェイスの例は、SATA（serial advanced technology attachment）、PCI、IDEインターフェイス、などを含む。本文書において記載される技術は、携帯電話、ラップトップ、スマートフォン、または、デジタルデータ処理及び／又はビデオ表示を実行することができる他の装置、といった種々の電子装置において具体化され得る。

いくつかの実施形態において、ビデオコーディング方法は、図5または図6に関して説明したようなハードウェアプラットフォーム上に実装される装置を使用して実施することができる。

上述の例は、以下に記載される方法、例えば、ビデオデコーダまたはビデオエンコーダで実装され得る方法710、720、730、810のコンテキストに組み込むことができる。

図7Aは、ビデオ処理のための例示的な方法710のフローチャートを示している。この方法710は、ステップ712において、参照ブロック内のピクセルに基づいてコード化された現在ブロックに関連する仮想バッファのサイズに基づいて、ブロックベクトルの妥当性、または、仮想バッファにマップされた１つ以上のサンプルに関して決定するステップであり、現在ピクチャは、現在ブロックおよび参照ブロックを含み、かつ、仮想バッファのサイズが、仮想パイプラインデータユニットのサイズ、コーディングツリーブロックのサイズまたはコーディングツリーユニットのサイズに基づいている、ステップを含む。方法700は、ステップ714において、決定に基づいて、現在ブロックと現在ブロックのビットストリーム表現との間の変換を実行するステップ、を含む。

図7Bは、ビデオ処理のための例示的な方法720のフローチャートを示している。方法720は、ステップ722において、参照ブロック内のピクセルに基づいてコード化された現在ブロックについて、参照ブロックの１つ以上の参照サンプルを使用不可として指定するステップであり、１つ以上の参照サンプルそれぞれは、仮想バッファにマップされており、かつ、参照ブロックに関連する少なくとも現在の仮想パイプラインデータユニット(VPDU)内に対応するサンプルを有しており、そして、現在ピクチャは、現在ブロックおよび参照ブロックを含んでいる、ステップを含む。方法720は、ステップ724において、指定に基づいて、現在ブロックと現在ブロックのビットストリーム表現との間の変換を実行するステップ、を含む。

図7Cは、ビデオ処理のための例示的な方法730のフローチャートを示している。方法730は、ステップ732において、参照ブロック内のピクセルに基づいてコード化された現在ブロックについて、コーディングツリーブロック（CTB）のサイズまたは現在ブロックのコーディングツリーユニット（CTU）のサイズに基づいて、参照ブロックに関連付けられた、仮想バッファのサイズを決定するステップであり、現在ピクチャは、現在ブロックおよび参照ブロックを含んでいる、ステップを含む。方法730は、ステップ734において、決定に基づいて、現在ブロックと現在ブロックのビットストリーム表現との間の変換を実行するステップ、を含む。

図8は、ビデオ処理のための例示的方法810のフローチャートを示している。方法810は、ステップ812において、ビデオのビデオピクチャの現在ビデオブロックとビデオのコード化表現との間の変換のために、現在ビデオブロックを予測するために参照サンプルがそこから使用されるビデオピクチャの参照領域のサイズに関して、仮想パイプラインデータユニット（VPDU）のサイズ、コーディングツリーブロック（CTB）のサイズ、または、コーディングツリーユニット（CYU）のサイズに基づいて、決定を行うステップ、を含む。方法810は、ステップ814において、決定に基づいて変換を実行するステップ、をさらに含む。

開示される技術のいくつかの実施形態は、ビデオ処理ツールまたはモードをイネーブルにする決定または判断を行うステップを含む。一つの例において、ビデオ処理ツールまたはモードがイネーブルされている場合、エンコーダは、ビデオのブロックの処理においてツールまたはモードを使用または実装するが、ツールまたはモードの使用に基づいて結果として生じるビットストリームを必ずしも修正しなくてよい。すなわち、ビデオのブロックからビデオのビットストリーム表現への変換は、決定または判断に基づいてイネーブルされたときに、ビデオ処理ツールまたはモードを使用する。別の例において、ビデオ処理ツールまたはモードがイネーブルされている場合、デコーダは、ビットストリームがビデオ処理ツールまたはモードに基づいて修正されたことを知って、ビットストリームを処理する。すなわち、ビデオのビットストリーム表現からビデオのブロックへの変換は、決定または判断に基づいてイネーブルされたビデオ処理ツールまたはモードを使用して実行される。

開示される技術のいくつかの実施形態は、ビデオ処理ツールまたはモードディセーブルにする決定または判断を行うステップを含む。一つの例において、ビデオ処理ツールまたはモードがディセーブルされている場合、エンコーダは、ビデオのブロックをビデオのビットストリーム表現に変換する際に、ツールまたはモードを使用しない。別の例において、ビデオ処理ツールまたはモードがディセーブルされた場合、デコーダは、決定または判断に基づいてディセーブルされたビデオ処理ツールまたはモードを使用してビットストリームが修正されていないことを知って、ビットストリームを処理する。

本文書において、「ビデオ処理（“video processing”）」という用語は、ビデオコーディング、ビデオデコーディング、ビデオ圧縮（compression）、またはビデオ解凍（decompression）を指すことができる。例えば、ビデオ圧縮アルゴリズムは、ビデオのピクセル表現から対応するビットストリーム表現への変換の最中に適用され得る。また、その逆も同様である。現在ビデオブロックのビットストリーム表現は、例えば、シンタックスによって定義されるように、ビットストリーム内の異なる場所に共配置（co-located）されるか、または、拡散されるビットに対応し得る。例えば、マクロブロックは、変換され、そして、コード化されたエラー残差値の観点で、また、ビットストリーム内のヘッダおよび他のフィールドにおけるビットを使用して、エンコーディングされ得る。

本文書に記載される様々なソリューションおよび実施形態が、条項（clauses）のリストを使用して、さらに説明される。条項の第１セットは、以前のセクションで開示された技術に係る所定の特徴および態様を記述する。

1.ビデオ処理のための方法であって、参照ブロック内のピクセルに基づいてコード化された現在ブロックに関連する仮想バッファのサイズに基づいて、ブロックベクトルまたは仮想バッファに対してマップされた１つ以上のサンプルの有効性に関する決定を行うステップであり、現在ピクチャは現在ブロックおよび参照ブロックを含み、仮想バッファのサイズは仮想パイプラインデータユニット(VPDU)のサイズ、コーディングツリーブロック(CTB)サイズ、またはコーディングツリーユニット(CTU)のサイズに基づいている、ステップ、および、決定に基づいて、現在ブロックと現在ブロックのビットストリーム表現との間の変換を実行するステップ、を含む。

2.前記仮想バッファの高さと幅の積は固定されており、かつ、前記高さまたは前記幅は、前記VPDUのサイズ、前記CTBのサイズまたは前記CTUのサイズに基づいている、条項1に記載の方法。

3.前記仮想バッファの幅は、前記CTBの幅または前記CTUの幅に等しい、条項1に記載の方法。

4.前記仮想バッファの幅または高さは、それぞれ前記VPDUの幅または高さのN倍であり、Nは、N≧1であり、整数である、条項1に記載の方法。

5.前記１つ以上のサンプルの最大数は、前記仮想バッファのサイズより小さい、条項1に記載の方法。

6.１つ以上のサンプルの最大数は、CTBのサイズまたはCTUのサイズが64×64より大きいという決定に基づいて固定される、条項1に記載の方法。

7.１つ以上のサンプルの数は、VPDU内のサンプル数のN倍以下であり、Nは、N≧1であり、整数である、条項1に記載の方法。

8.CTBのサイズまたはCTUのサイズが64×64より大きいと決定された場合、N=3である、条項7に記載の方法。

9.ビデオ処理のための方法であって、参照ブロック内のピクセルに基づいてコード化される現在ブロックについて、参照ブロックの１つ以上の参照サンプルを使用不可として指定するステップであり、１つ以上の参照サンプルそれぞれは、仮想バッファにマップされ、参照ブロックに関連する少なくとも現在仮想パイプラインデータユニット(VPDU)内に対応するサンプルを有し、かつ、現在ピクチャは、現在ブロックおよび参照ブロックを含む、ステップ、および、指定に基づいて、現在ブロックと現在ブロックのビットストリーム表現との間の変換を実行するステップ、を含む。

10.前記方法は、さらに、前記現在VPDU中の対応するサンプルを使用不可として指定するステップ、を含む、条項9に記載の方法。

11.前記対応するサンプルを指定するステップは、現在VPDUの位置に基づいている、条項10に記載の方法。

12.前記対応するサンプルを指定するステップは、以前のVPDUまたは最近デコーディングされたVPDUの位置に基づいている、条項10に記載の方法。

13.前記１つ以上の参照サンプルそれぞれは、直近にデコードされた3個のVPDUそれぞれ対応するサンプルを有する、条項9に記載の方法。

14.ビデオ処理のための方法であって、参照ブロック内のピクセルに基づいてコード化される現在ブロックについて、現在ブロックのコーディングツリーブロックのサイズまたはコーディングツリーユニットのサイズに基づいて、参照ブロックに関連する仮想バッファのサイズを決定するステップであり、現在ピクチャは、現在ブロックおよび参照ブロックを含む、ステップ、および、前記決定に基づいて、現在ブロックと現在ブロックのビットストリーム表現との間の変換を実行するステップ、を含む。

15.CTBまたはCTUのサイズが128×128であると決定された場合、仮想バッファのサイズは256×128である、条項14に記載の方法。

16.CTBまたはCTUのサイズが256×256であると決定された場合、仮想バッファのサイズは64×256である、条項14に記載の方法。

17.CTBまたはCTUのサイズが256×256であると決定された場合、仮想バッファのサイズは128×256である、条項14に記載の方法。

18.現在ブロックを構成する現在ピクチャ内の参照ブロック内のピクセルに基づいて現在ブロックをコード化することがイントラブロックコピー(IBC)演算であり、ここで、仮想バッファはIBC仮想バッファである、条項1-17のいずれかに記載の方法。

19.ビデオ処理の方法であって、ビデオの現在ブロックのビットストリーム表現と現在ブロックとの間の変換について、前記変換のためのブロックベクトル探索領域の最小サイズより大きいイントラブロックコーディング（IBC）仮想バッファサイズを割り当てるステップ、および、前記割り当てに基づいて前記変換を実行するステップ、を含む。

20.前記IBCバッファサイズは、前記変換に使用される仮想パイプラインデータユニットメモリの合計サイズより大きい、条項19に記載の方法。

21.前記IBC仮想バッファサイズの幅は(128*128/ctbSizeY+ctbSizeY)である、条項19または20に記載の方法。

22.ビデオ処理の方法であって、ビデオの現在ブロックのビットストリーム表現と前記現在ブロックとの間の変換について、ルールに基づいたイントラブロック予測コーディングに基づいて、前記変換のための参照ブロックのサイズを決定するステップ、および、前記決定に基づいて前記変換を実行するステップであり、前記ルールは、前記参照ブロックを仮想パイプラインデータユニット（VPUD）列または仮想パイプラインデータユニット行の中にあるように制約する、ステップ、を含む。

23.前記ルールは、前記参照ブロックが異なるVPDU行にまたがることを禁止する、条項22に記載の方法。

24.前記ルールは、前記参照ブロックが異なるVPDU列にまたがることを禁止する、条項22に記載の方法。

25.VPDU列またはVPDU行は、現在ブロックを含むピクチャに対するものである、条項22-24のいずれかに記載の方法。

26.前記VPDU列または前記VPDU行は、イントラブロックコピー仮想バッファに対するものである、条項22-24のいずれかに記載の方法。

27.前記変換は、前記現在ブロックからビットストリーム表現を生成するためのビデオコーディングを含む、条項1-26のいずれかに記載の方法。

28.前記変換は、前記ビットストリーム表現から前記現在ブロックを生成するためのビデオデコーディングを含む、条項1-26のいずれかに記載の方法。

29.プロセッサと、その上に命令を有する非一時的メモリとを備えるビデオシステム内の装置であって、前記プロセッサによる実行の際に、前記命令は、条項1-28のいずれかに記載の方法を前記プロセッサに実行させる、装置。

30.非一時的なコンピュータ可読媒体に保管されたコンピュータプログラム製品であって、条項1-28のいずれかに記載の方法を実行するためのプログラムコードを含む、コンピュータプログラム製品。

31.ここにおいて説明される方法、装置、またはシステム。

条項の第２セットは、以前のセクションで開示された技術に係る所定の特徴および態様を記述する。例えば、実施例1、2、6－8である。

1.ビデオ処理のための方法であって、ビデオのビデオピクチャの現在ビデオブロックと前記ビデオのコード化表現との間の変換のために、仮想パイプラインデータユニット(VPDU)のサイズ、コーディングツリーブロック(CTB)のサイズ、または、コーディングツリーユニット(CTU)のサイズに基づいて、前記現在ビデオブロックを予測するために参照サンプルが使用される前記ビデオピクチャの参照領域のサイズに関する決定を行うステップ、および、前記決定に基づいて前記変換を実行するステップ、を含む。

2.前記現在ビデオブロックは、前記現在ビデオブロックを含むビデオフレームを指し示している少なくとも１つのブロックベクトルを使用して予測ブロックを生成する、イントラブロックコピー(IBC)モードを使用してコード化され、かつ、前記参照領域はIBC仮想バッファである、条項1に記載の方法。

3.前記方法は、さらに、前記参照領域のサイズに基づいて、ブロックベクトル、または、前記参照領域にマップされた１つ以上のサンプルの妥当性を決定するステップ、を含む、条項1または2に記載の方法。

4.前記参照領域の高さと幅の積は固定されており、かつ、前記高さまたは前記幅は、前記VPDUのサイズ、前記CTBのサイズ、または前記CTUのサイズに基づいている、条項1または2に記載の方法。

5.前記参照領域の高さは、前記CTBの高さまたは前記CTUの高さに等しい、条項1または2に記載の方法。

6.前記参照領域の幅は、前記参照領域のサイズを前記CTBの高さで除算して得られた値に設定されている、条項1または2に記載の方法。

7.前記参照領域の幅は、前記CTBの幅または前記CTUの幅に等しい、条項1または2に記載の方法。

8.前記参照領域の幅は、前記VPDUの幅のN倍であり、かつ、Nは、N≧1であり、整数である、条項1または2に記載の方法。

9.前記参照領域の高さは、それぞれに、前記VPDUの高さのN倍であり、Nは、N≧1であり、整数である、条項1または2に記載の方法。

10.前記参照領域の幅は、256*128/ctbSizeYであり、ctbSizeYは、ルマCTBまたはCTUの幅または高さを示す、条項1または2に記載の方法。

11.前記参照領域の高さは、ctbSizeYであり、ctbSizeYは、ルマCTBまたはCTUの幅または高さを示す、条項1または2に記載の方法。

12.前記参照領域のサイズは、より大きな参照領域が、より大きなCTUまたはより大きなCTBに対して割り当てられるように、決定される、条項1または2に記載の方法。

13.前記参照領域の幅は、(128*128/ctbSizeY+ctbSizeY)であり、ctbSizeYは、ルマCTBまたはCTUの幅または高さを示す、条項1または2に記載の方法。

14.前記CTBのサイズまたは前記CTUのサイズが128×128ルマサンプルのサイズを有する場合に、前記参照領域のサイズは、256×128ルマサンプルのサイズに対応する、条項1または2に記載の方法。

15.前記参照領域のサイズは、(k×64)×128ルマサンプルのサイズに対応し、Kは2より大きい、条項1または2に記載の方法。

16.前記CTBのサイズまたは前記CTUのサイズが256×256ルマサンプルのサイズに対応する場合に、前記参照領域のサイズは、64×256ルマサンプルのサイズに対応する、条項1または2に記載の方法。

17.前記VPDUを左上位置(x0,y0)でデコーディングする前に、前記参照領域内の対応するVPDU行は-1に設定される、条項16に記載の方法。

18.前記CTBのサイズまたは前記CTUのサイズが256×256ルマサンプルのサイズを有する場合に、前記参照領域のサイズは、128×256ルマサンプルのサイズに対応する、条項1または2に記載の方法。

19.現在VPDU以外の１つのVPDUだけが、所定のVPDU行を除いて、前記参照領域内の各VPDU行に対して保持される、条項18に記載の方法。

20.前記変換は、前記現在ビデオブロックを前記コード化表現へとエンコーディングすることを含む、条項1-19のいずれかに記載の方法。

21.前記変換は、前記コード化表現を前記現在ビデオブロックからデコーディングすることを含む、条項1-19のいずれかに記載の方法。

22.条項1-21のいずれかに記載の方法を実施するように構成されたプロセッサを備える、ビデオ処理装置。

23.プログラムコードを保管しているコンピュータ可読媒体であって、実行されると、条項1-21のいずれかに記載の方法をプロセッサに実装させる、コンピュータ可読媒体。

以上から、ここにおいて、説明の目的で、本開示の技術の特定の実施形態を説明してきたが、本発明の範囲を逸脱することなく、種々の修正を行うことができることが理解されるだろう。従って、現在開示されている技術は、添付の請求項による場合を除き、限定されない。

この特許文書において説明される技術的事項（subject matter）の実装および機能動作は、ここにおいて開示されている構造およびそれらの構造的等価物を含む、種々のシステム、デジタル電子回路、またはコンピュータソフトウェア、ファームウェア、もしくはハードウェアにおいて、または、それらの１つ以上の組み合わせにおいて実施することができる。ここにおいて説明される技術的事項の実装は、１つ以上のコンピュータプログラム製品、すなわち、データ処理装置による、またはデータ処理装置の動作を制御するための、有形および非一時的なコンピュータで読取り可能な媒体上にエンコーディングされたコンピュータプログラム命令の１つ以上のモジュールとして実装することができる。コンピュータで読取り可能な媒体は、マシンで読取り可能なストレージ装置、マシンで読取り可能なストレージ基板、メモリ装置、マシンで読取り可能な伝搬信号に影響を与える物質の組成、または、それらの１つ以上の組み合わせであり得る。用語「データ処理ユニット（“data processing unit”）」または「データ処理装置（“data processing apparatus”）」は、例えば、プログラマブルプロセッサ、コンピュータ、もしくは、複数のプロセッサまたはコンピュータを含む、データを処理するための全ての装置、デバイス、およびマシンを包含する。装置は、ハードウェアに加えて、問題のコンピュータプログラムの実行環境を生成するコード、例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、または、それらの１つ以上の組み合わせを構成するコードを含み得る。

コンピュータプログラム(プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとしても知られるもの)は、コンパイルまたはインタープリートされた（interpreted）言語を含む、任意の形態のプログラミング言語で書くことができ、それは、スタンドアロンプログラムとして、もしくは、コンピューティング環境での使用に適したモジュール、コンポーネント、サブルーチン、または他のユニットとして、を含み、任意の形態で展開することができる。コンピュータプログラムは、必ずしもファイルシステム内のファイルに対応するものではない。プログラムは、他のプログラムまたはデータを保持するファイルの一部分(例えば、マークアップ言語文書において保管される１つ以上のスクリプト)、問題のプログラム専用の単一ファイル、または、複数の協調ファイル（coordinated files）(例えば、１つ以上のモジュール、サブプログラム、または、コードの一部分を保管するファイル)に保管され得る。コンピュータプログラムは、１つのコンピュータまたは１つのサイトに配置されるか、または、複数のサイトに分散され、通信ネットワークによって相互接続される複数のコンピュータ上で実行されるように展開され得る。

ここにおいて説明されるプロセスおよび論理フローは、入力データ上で動作し、出力を生成することによって機能を実行するために、１つ以上のコンピュータプログラムを実行する１つ以上のプログラマブルプロセッサによって実行され得る。プロセスおよび論理フローは、また、特殊目的論理回路、例えば、FPGA(フィールドプログラマブルゲートアレイ)またはASIC(特定用途向け集積回路)、によっても実行することができ、そして、装置も、また、実装され得る。

コンピュータプログラムの実行に適したプロセッサは、例えば、汎用および専用マイクロプロセッサの両方、および、任意の種類のデジタルコンピュータの任意の１つ以上のプロセッサを含む。一般的に、プロセッサは、リードオンリーメモリまたはランダムアクセスメモリ、もしくは、その両方から命令およびデータを受信する。コンピュータの必須要素は、命令を実行するためのプロセッサと、命令およびデータを保管するための１つ以上のメモリデバイスである。一般的に、コンピュータは、また、データを保管するための１つ以上の大容量ストレージ装置、例えば、磁気ディスク、磁気光ディスク、または光ディスクからデータを受信し、または、データを転送するために動作可能に結合される。しかしながら、コンピュータは、そうした装置を有する必要はない。コンピュータプログラム命令及びデータを保管するのに適したコンピュータで読取り可能な媒体は、あらゆる形態の不揮発性メモリ、媒体、およびメモリデバイスを含む。半導体メモリデバイス、例えば、EPROM、EEPROM、およびフラッシュメモリデバイスを、例として含むものである。プロセッサおよびメモリは、特殊目的論理回路によって補足されるか、または、内蔵され得る。

明細書は、図面と共に、例示的なだけあるとみなされるが、ここで、例示的は、実施例を意味する。ここにおいて使用される場合、「または（“or”）」の使用は、コンテキストが他のことを明確に示さない限り、「及び／又は（“and/or”）」を含むように意図されている。

この特許文書は多くの詳細を含んでいるが、これらは、任意の発明の範囲または特許請求され得るものを限定するものではなく、むしろ、特定の発明の特定の実施形態に特有であり得る特徴の説明として解釈されるべきである。別個の実施形態のコンテキストにおいてこの特許文書に説明されている特定の特徴は、単一の実施形態において組み合わせて実施することもできる。逆に、単一の実施形態のコンテキストにおいて説明される種々の特徴は、複数の実施形態において別々に、または、任意の適切なサブコンビネーションで実施することもできる。さらに、特徴は、所定の組み合わせで動作するものとして上述され、かつ、そのように最初に請求され得るが、請求される組み合わせから１つ以上の特徴は、場合によって、組み合わせから削除されてよく、そして、請求される組み合わせは、サブコンビネーションまたはサブコンビネーション変形に対して向けられ得る。

同様に、図面には特定の順序で動作が示されているが、これは、所望の結果を達成するためには、そうした動作を示される特定の順序でまたは連続的な順序で実行すること、または、説明される全ての動作を実行することを要求するものとして理解されるべきではない。さらに、この特許文書に記載されている実施形態における種々のシステム構成要素の分離は、そうした分離を全ての実施形態において必要とするものとして理解されるべきではない。

少数の実施形態および実施例だけが記述されており、そして、この特許文書において記載され、かつ、説明されていることに基づいて、他の実施形態、拡張、および変形を行うことができる。

Claims (13)

1. ビデオデータを処理する方法であって、
   ビデオのビデオピクチャの現在ビデオブロックと前記ビデオのビットストリームとの間の変換について、前記現在ビデオブロックに予測モードが適用されることを決定するステップと、
   前記予測モードについて、前記ビデオピクチャから導出された参照サンプルを含む仮想バッファを維持するステップと、
   前記予測モードにおいて、前記仮想バッファ内の利用可能な参照サンプルを指し示すブロックベクトルに基づいて、前記現在ビデオブロックについて予測サンプルを導出するステップと、
   前記予測サンプルに基づいて、前記変換を実行するステップと、
   を含み、
   前記仮想バッファの面積は、固定されており、かつ、256×128に等しく、
   前記仮想バッファの高さは、ctbSizeYに等しく、かつ、
   前記仮想バッファの幅は、256×128/ctbSizeYに等しく、
   ctbSizeYは、前記現在ビデオブロックを含むルマコーディングツリーブロック（CTB）のサイズを示す、
   方法。
2. 前記予測モードは、イントラブロックコピー(IBC)モードであり、かつ、
   前記仮想バッファは、IBC仮想バッファである、
   請求項１に記載の方法。
3. 前記仮想バッファの幅は、仮想ユニットの幅の１倍以上であり、
   前記仮想ユニットの幅は、(ctbSizeY，64)の最小値（min）である、
   請求項１に記載の方法。
4. 前記仮想バッファの高さは、仮想ユニットの高さの１倍以上であり、
   前記仮想ユニットの高さは、(ctbSizeY，64)の最小値（min）である、
   請求項１に記載の方法。
5. 前記予測サンプルを導出するための前記仮想バッファ内の１つ以上の利用可能でないサンプルの位置は、仮想ユニットの幅と高さに基づいて決定される、
   請求項１に記載の方法。
6. 前記仮想ユニットに対応する前記仮想バッファ内のブロックのサンプルは、-1に設定されており、かつ、前記予測サンプルを導出するためには利用可能でない、
   請求項５に記載の方法。
7. 前記ビットストリームによって満足されるビットストリーム適合性制約は、前記仮想バッファ内の参照サンプルを指し示すブロックベクトルによって決定される参照ブロックが、-1に等しい値を持たないこと、を含む、
   請求項１に記載の方法。
8. 前記仮想バッファは、各コーティングツリーユニット行の開始において、値-1でリフレッシュされる、
   請求項１に記載の方法。
9. 前記変換は、前記現在ビデオブロックを前記ビットストリームへエンコーディングすることを含む、
   請求項１乃至８いずれか一項に記載の方法。
10. 前記変換は、前記ビットストリームから前記現在ビデオブロックをデコーディングすることを含む、
    請求項１乃至８いずれか一項に記載の方法。
11. ビデオデータを処理するための装置であって、プロセッサと、命令を含む非一時メモリとを備え、前記命令が前記プロセッサによって実行されると、
    前記プロセッサに、
    ビデオのビデオピクチャの現在ビデオブロックと前記ビデオのビットストリームとの間の変換について、前記現在ビデオブロックに予測モードが適用されることを決定し、
    前記予測モードについて、前記ビデオピクチャから導出された参照サンプルを含む仮想バッファを維持し、
    前記予測モードにおいて、前記仮想バッファ内の利用可能な参照サンプルを指し示すブロックベクトルに基づいて、前記現在ビデオブロックについて予測サンプルを導出し、かつ、
    前記予測サンプルに基づいて、前記変換を実行する、ようにさせ、
    前記仮想バッファの面積は、固定されており、かつ、256×128に等しく、
    前記仮想バッファの高さは、ctbSizeYに等しく、かつ、
    前記仮想バッファの幅は、256×128/ctbSizeYに等しく、
    ctbSizeYは、前記現在ビデオブロックを含むルマコーディングツリーブロック（CTB）のサイズを示す、
    装置。
12. 命令を保管している非一時的なコンピュータ読取可能記憶媒体であって、
    前記命令は、プロセッサに、
    ビデオのビデオピクチャの現在ビデオブロックと前記ビデオのビットストリームとの間の変換について、前記現在ビデオブロックに予測モードが適用されることを決定し、
    前記予測モードについて、前記ビデオピクチャから導出された参照サンプルを含む仮想バッファを維持し、
    前記予測モードにおいて、前記仮想バッファ内の利用可能な参照サンプルを指し示すブロックベクトルに基づいて、前記現在ビデオブロックについて予測サンプルを導出し、かつ、
    前記予測サンプルに基づいて、前記変換を実行する、ようにさせ、
    前記仮想バッファの面積は、固定されており、かつ、256×128に等しく、
    前記仮想バッファの高さは、ctbSizeYに等しく、かつ、
    前記仮想バッファの幅は、256×128/ctbSizeYに等しく、
    ctbSizeYは、前記現在ビデオブロックを含むルマコーディングツリーブロック（CTB）のサイズを示す、
    非一時的なコンピュータ読取可能記憶媒体。
13. ビデオのビットストリームを保管する方法であって、
    ビデオのビデオピクチャの現在ビデオブロックと前記ビデオのビットストリームとの間の変換について、前記現在ビデオブロックに予測モードが適用されることを決定するステップと、
    前記予測モードについて、前記ビデオピクチャから導出された参照サンプルを含む仮想バッファを維持するステップと、
    前記予測モードにおいて、前記仮想バッファ内の利用可能な参照サンプルを指し示すブロックベクトルに基づいて、前記現在ビデオブロックについて予測サンプルを導出するステップと、
    前記予測サンプルに基づいて、前記ビットストリームを生成するステップと、
    前記ビットストリームを非一時的コンピュータ読取可能記憶媒体に保管するステップと、
    を含み、
    前記仮想バッファの面積は、固定されており、かつ、256×128に等しく、
    前記仮想バッファの高さは、ctbSizeYに等しく、かつ、
    前記仮想バッファの幅は、256×128/ctbSizeYに等しく、
    ctbSizeYは、前記現在ビデオブロックを含むルマコーディングツリーブロック（CTB）のサイズを示す、
    方法。

Images