JP2023171607A - 参照ピクチャー再サンプリングがある場合のラップアラウンド動き補償に関する方法、装置、コンピュータ・プログラム - Google Patents

Abstract

【課題】参照ピクチャー再サンプリングがある場合のラップアラウンド動き補償に関する方法、装置、コンピュータ・プログラムを提供する。
【解決手段】少なくとも1つのプロセッサを使用して、エンコードされたビデオ・ビットストリームを生成する方法であって、現在のピクチャーの現在の層が独立層であるかどうかに関する第1の決定を行う段階と；現在の層について参照ピクチャー再サンプリングが有効にされているかどうかに関する第2の決定を行う段階と；第1の決定および第2の決定に基づいて、現在の層についてラップアラウンド補償を無効にする段階と；ラップアラウンド補償なしで現在の層をエンコードする段階とを含む、方法。
【選択図】図７

Description

関連出願への相互参照
本願は、2019年12月31日に出願された米国仮特許出願第62/955,520号、および2020年10月6日に出願された米国特許出願第17/064,172号からの優先権を主張し、その全体が本明細書に組み込まれる。

分野
開示される主題は、ビデオ符号化および復号に関し、より詳細には、ラップアラウンド動き補償の有効化および無効化に関する。

動き補償のあるピクチャー間予測を用いたビデオ符号化および復号が知られている。非圧縮デジタル・ビデオは、一連のピクチャーで構成されることができ、各ピクチャーは、たとえば1920×1080のルミナンス・サンプルおよび関連するクロミナンス・サンプルの空間的寸法を有する。一連のピクチャーは、固定または可変のピクチャー・レート（非公式にはフレーム・レートとしても知られる）、たとえば、60ピクチャー毎秒または60Hzを有することができる。非圧縮ビデオは、かなりのビットレート要件を有する。たとえば、サンプル当たり8ビットの1080p60 4:2:0ビデオ（60Hzのフレーム・レートでの1920×1080のルミナンス・サンプル解像度）は、1.5Gbit/sに近い帯域幅を必要とする。そのようなビデオの1時間は、600Gバイトを超える記憶スペースを必要とする。

ビデオ符号化および復号の1つの目的は、圧縮による入力ビデオ信号の冗長性の低減でありうる。圧縮は、前述の帯域幅または記憶スペースの要件を、場合によっては2桁以上も低減するのに役立つことがある。可逆圧縮および不可逆圧縮の両方、ならびにそれらの組み合わせを用いることができる。可逆圧縮とは、圧縮されたもとの信号から、もとの信号の正確なコピーが再構成できる技術をいう。不可逆圧縮を使用する場合、再構成された信号は、もとの信号と同一ではないことがありうるが、もとの信号と再構成された信号との間の歪みは、再構成された信号を意図された用途のために有用にするのに十分小さい。ビデオの場合、不可逆圧縮が広く用いられている。許容される歪みの量はアプリケーションに依存し、たとえば、ある種の消費者ストリーミングアプリケーションのユーザーは、テレビ配信アプリケーションのユーザーよりも高い歪みを許容することがある。達成可能な圧縮比は、より高い許容可能／認容可能な歪みはより高い圧縮比をもたらすことができる、ということを反映できる。

ビデオ・エンコーダおよびデコーダは、たとえば動き補償、変換、量子化、およびエントロピー符号化を含むいくつかのおおまかなカテゴリーからの技術を利用することができる。そのいくつかは下記で紹介する。

歴史的に、ビデオ・エンコーダおよびデコーダは、所与のピクチャー・サイズに対して作用する傾向があり、該サイズは、ほとんどの場合、符号化ビデオ・シーケンス（coded video sequence、CVS）、ピクチャーグループ（Group of Pictures、GOP）、または類似のマルチピクチャー時間フレームについて定義され、一定のままであった。たとえば、MPEG-2では、システム設計は、シーンの活動のような要因に依存して水平解像度を（よって、ピクチャー・サイズを）変化させることが知られているが、それはIピクチャーにおいてのみであり、よって典型的にはGOPについてである。CVS内で異なる解像度を使用するための参照ピクチャーの再サンプリングは、たとえばITU-T Rec. H.263付属書Pから知られている。しかしながら、ここではピクチャー・サイズは変化せず、参照ピクチャーが再サンプリングされるだけであり、その結果、潜在的には、ピクチャー・キャンバスの一部のみが使用される（ダウンサンプリングの場合）、またはシーンの一部のみが捕捉される（アップサンプリングの場合）。さらに、H.263付属書Qは、個々のマクロブロックの（各次元において）2倍上下させる再サンプリングを許容する。ここでもまた、ピクチャー・サイズは同じままである。マクロブロックのサイズはH.263では固定されており、よって信号伝達される必要はない。

予測されたピクチャーにおけるピクチャー・サイズの変化は、現代のビデオ符号化においてより主流となった。たとえば、VP9は、ピクチャー全体についての参照ピクチャーの再サンプリングおよび解像度の変更を許容する。同様に、VVCに対してなされるある種の提案（たとえば、その全体が本明細書に組み込まれる非特許文献１を含む）は、参照ピクチャー全体を異なる――より高いまたはより低い――解像度に再サンプリングすることを許容する。その文書では、異なる候補解像度がシーケンスパラメータセットにおいて符号化され、ピクチャーパラメータセットにおけるピクチャーごとの構文要素によって参照されることが提案される。
Hendry, et. al、"On adaptive resolution change （ARC） for VVC"、Joint Video Team document JVET-M0135-v1, Jan 9-19, 2019

ある実施形態では、少なくとも1つのプロセッサを使用してエンコードされたビデオ・ビットストリームを生成する方法が提供される。本方法は、現在のピクチャーの現在の層が独立層であるかどうかに関する第1の決定を行うことと；参照ピクチャー再サンプリングが現在の層について有効にされているかどうかに関する第2の決定を行うことと；第1の決定および第2の決定に基づいて、現在の層についてラップアラウンド補償を無効にすることと；ラップアラウンド補償なしで現在の層をエンコードすることとを含む。

ある実施形態では、プログラム・コードを記憶するように構成された少なくとも1つのメモリと、前記プログラム・コードを読んで、前記プログラム・コードによって指示されるように動作するように構成された少なくとも1つのプロセッサとを含む、エンコードされたビデオ・ビットストリームを生成するための装置が提供される。前記プログラム・コードは：前記少なくとも1つのプロセッサに、現在のピクチャーの現在の層が独立層であるかどうかに関する第1の決定を行わせるように構成された第1決定コードと；前記少なくとも1つのプロセッサに、参照ピクチャー再サンプリングが現在の層について有効にされているかどうかに関する第2の決定を行わせるように構成された第2決定コードと；前記少なくとも1つのプロセッサに、第1の決定および第2の決定に基づいて、現在の層についてラップアラウンド補償を無効にさせるように構成された無効化コードと；前記少なくとも1つのプロセッサに、ラップアラウンド補償なしで現在の層をエンコードさせるように構成されたエンコード・コードとを含む。

ある実施形態では、命令を記憶している非一時的なコンピュータ読み取り可能な媒体が提供される。前記命令は、エンコードされたビデオ・ビットストリームを生成する装置の一つまたは複数のプロセッサによって実行されたときに、前記一つまたは複数のプロセッサに：現在のピクチャーの現在の層が独立層であるかどうかに関する第1の決定を行うことと；参照ピクチャー再サンプリングが現在の層について有効にされているかどうかに関する第2の決定を行うことと；第1の決定および第2の決定に基づいて、現在の層についてラップアラウンド補償を無効にすることと；ラップアラウンド補償なしで現在の層をエンコードすることと実行させる一つまたは複数の命令を含む。

開示される主題のさらなる特徴、性質、およびさまざまな利点は、以下の詳細な説明および添付の図面からより明らかになるであろう。

ある実施形態による通信システムの簡略化されたブロック図の概略図である。

ある実施形態による通信システムの簡略化されたブロック図の概略図である。

ある実施形態によるデコーダの簡略化されたブロック図の概略図である。

ある実施形態によるエンコーダの簡略化されたブロック図の概略図である。

A～Eは、ある実施形態による、ある実施形態によるARCパラメータを信号伝達するためのオプションの概略図である。

A～Bは、ある実施形態による構文テーブルの例の概略図である。

ある実施形態による構文テーブルの例の概略図である。

A～Cは、ある実施形態によるエンコードされたビデオ・ビットストリームを生成するための例示的なプロセスのフローチャートである。

ある実施形態によるコンピュータ・システムの概略図である。

図1は、本開示のある実施形態による通信システム（100）の簡略化されたブロック図を示す。システム（100）は、ネットワーク（150）を介して相互接続された少なくとも2つの端末（110～120）を含んでいてもよい。データの一方向伝送のためには、第1の端末（110）は、ネットワーク（150）を介して他方の端末（120）への伝送のために、ローカル位置でビデオ・データを符号化することができる。第2の端末（120）は、ネットワーク（150）から他方の端末の符号化されたビデオ・データを受信し、符号化されたデータを復号し、回復されたビデオ・データを表示することができる。一方向データ伝送は、メディア提供アプリケーション等において一般的でありうる。

図1は、たとえば、ビデオ会議中に発生しうる符号化されたビデオの双方向伝送をサポートするために設けられた端末（130、140）の第2の対を示す。データの双方向伝送については、各端末（130、140）は、ローカル位置で捕捉されたビデオ・データを、ネットワーク（150）を介した他方の端末への伝送のために符号化することができる。各端末（130、140）はまた、他方の端末によって送信された符号化されたビデオ・データを受信し、符号化されたデータをデコードし、回復されたビデオ・データをローカル表示装置において表示することができる。

図1において、端末（110～140）は、サーバー、パーソナルコンピュータおよびスマートフォンとして図示されてもよいが、本開示の原理は、それに限定されなくてもよい。本開示の実施形態は、ラップトップ・コンピュータ、タブレット・コンピュータ、メディア・プレーヤー、および／または専用のビデオ会議設備との応用を見出す。ネットワーク（150）は、たとえば有線および／または無線通信ネットワークを含む、端末（110～140）の間で、符号化されたビデオ・データを伝達する任意の数のネットワークを表わす。通信ネットワーク（150）は、回線交換および／またはパケット交換チャネルにおいてデータを交換することができる。代表的なネットワークは、遠隔通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワークおよび／またはインターネットを含む。今の議論の目的のためには、ネットワーク（150）のアーキテクチャーおよびトポロジーは、下記で説明しない限り、本開示の動作には重要ではないことがある。

図2は、開示された主題の適用のための例として、ストリーミング環境におけるビデオ・エンコーダおよびデコーダの配置を示す。開示された主題は、たとえば、ビデオ会議、デジタルTV、CD、DVD、メモリースティックなどを含むデジタルメディア上の圧縮ビデオの記憶などを含む、他のビデオ対応アプリケーションにも等しく適用可能でありうる。

ストリーミング・システムは、ビデオ源（201）、たとえばデジタル・カメラを含むことができ、たとえば非圧縮のビデオ・サンプル・ストリーム（202）を生成する捕捉サブシステム（213）を含んでいてもよい。サンプル・ストリーム（202）は、エンコードされたビデオ・ビットストリームと比較した場合の高いデータ・ボリュームを強調するために太線で描かれており、カメラ（201）に結合されたエンコーダ（203）によって処理されることができる。エンコーダ（203）は、以下により詳細に説明されるように、開示される主題の諸側面を可能にし、または実現するためのハードウェア、ソフトウェア、またはそれらの組み合わせを含むことができる。サンプル・ストリームと比較した場合の、より低いデータ・ボリュームを強調するために細線で描かれるエンコードされたビデオ・ビットストリーム（204）は、将来の使用のためにストリーミング・サーバー（205）に記憶されることができる。一つまたは複数のストリーミング・クライアント（206、208）は、ストリーミング・サーバー（205）にアクセスして、エンコードされたビデオ・ビットストリーム（204）のコピー（207、209）を取り出すことができる。クライアント（206）は、ビデオ・デコーダ（210）を含むことができる。ビデオ・デコーダは、エンコードされたビデオ・ビットストリーム（207）の入来コピーをデコードし、ディスプレイ（212）または他のレンダリング装置（図示せず）上にレンダリングできる出行ビデオ・サンプル・ストリーム（211）を生成する。いくつかのストリーミング・システムでは、ビデオ・ビットストリーム（204、207、209）は、ある種のビデオ符号化／圧縮標準に従ってエンコードされることができる。これらの標準の例はITU-T勧告H.265を含む。非公式に多用途ビデオ符号化またはVVCとして知られるビデオ符号化標準も開発中である。開示される主題はVVCのコンテキストで使用されてもよい。

図3は、本開示のある実施形態によるビデオ・デコーダ（210）の機能ブロック図であってもよい。

受領機（310）は、デコーダ（210）によってデコードされるべき一つまたは複数の符号化されたビデオ・シーケンスを受領してもよい；同じまたは別の実施形態において、一度に1つの符号化されたビデオ・シーケンスであり、各符号化されたビデオ・シーケンスのデコードは、他の符号化されたビデオ・シーケンスから独立である。符号化されたビデオ・シーケンスは、チャネル（312）から受信されてもよく、該チャネルは、エンコードされたビデオ・データを記憶する記憶装置へのハードウェア／ソフトウェア・リンクであってもよい。受領機（310）は、エンコードされたビデオ・データを、他のデータ、たとえば符号化されたオーディオ・データおよび／または補助データ・ストリームと一緒に受領してもよく、これらのデータは、それぞれの使用エンティティ（図示せず）を転送されてもよい。受領機（310）は、符号化されたビデオ・シーケンスを他のデータから分離することができる。ネットワーク・ジッタ対策として、バッファメモリ（315）が、受領器（310）とエントロピー・デコーダ／パーサー（320）（以下「パーサー」）との間に結合されてもよい。受領器（310）が、十分な帯域幅および制御可能性の記憶／転送装置から、またはアイソクロナス・ネットワークからデータを受領している場合は、バッファ（315）は、必要とされなくてもよく、または小さくてもよい。インターネットのようなベストエフォート型のパケット・ネットワークでの使用のためには、バッファ（315）が要求されることがあり、比較的大きいことがあり、有利には適応サイズであることができる。

ビデオ・デコーダ（210）は、エントロピー符号化されたビデオ・シーケンスからシンボル（321）を再構成するためのパーサー（320）を含んでいてもよい。これらのシンボルのカテゴリーは、デコーダ（210）の動作を管理するために使用される情報と、潜在的には、図3に示されたような、デコーダの一体的な部分ではないがデコーダに結合されることができるディスプレイ（212）のようなレンダリング装置を制御するための情報とを含む。レンダリング装置（単数または複数）のための制御情報は、補足向上情報（Supplementary Enhancement Information、SEIメッセージ）またはビデオユーザービリティ情報（Video Usability Information、VUI）パラメータセット・フラグメント（図示せず）の形であってもよい。パーサー（320）は、受領された符号化されたビデオ・シーケンスをパースする／エントロピー復号することができる。符号化されたビデオ・シーケンスの符号化は、ビデオ符号化技術または標準に従うことができ、可変長符号化、ハフマン符号化、コンテキスト感受性ありまたはなしの算術符号化などを含む、当業者によく知られたさまざまな原理に従うことができる。パーサー（320）は、符号化されたビデオ・シーケンスから、ビデオ・デコーダ内のピクセルのサブグループのうちの少なくとも1つについてのサブグループ・パラメータのセットを、グループに対応する少なくとも1つのパラメータに基づいて、抽出することができる。サブグループは、ピクチャーグループ（Group of Pictures、GOP）、ピクチャー、サブピクチャー、タイル、スライス、マクロブロック、符号化ツリー単位（Coding Tree Unit、CTU）、符号化単位（Coding Unit、CU）、ブロック、変換単位（Transform Unit、TU）、予測単位（Prediction Unit、PU）などを含むことができる。タイルは、ピクチャーにおける特定のタイル列および行内のCU/CTUの長方形領域を示しうる。ブリックは、特定のタイル内のCU/CTU行の長方形領域を示しうる。スライスは、ピクチャーの、NAL単位に含まれる一つまたは複数のブリックを示してもよい。サブピクチャーは、ピクチャー内の一つまたは複数のスライスの長方形領域を示してもよい。エントロピー・デコーダ／パーサーはまた、符号化されたビデオ・シーケンスから、変換係数、量子化器パラメータ値、動きベクトル等の情報を抽出することができる。

パーサー（320）は、バッファ（315）から受領されたビデオ・シーケンスに対してエントロピー・デコード／パース動作を実行し、それによりシンボル（321）を生成することができる。

シンボル（321）の再構成は、符号化されたビデオ・ピクチャーまたはその諸部分のタイプ（たとえばイントラ・ブロック）および他の要因に依存して、複数の異なるユニットに関わることができる。どのユニットがどのように関わるかは、符号化されたビデオ・シーケンスからパーサー（320）によってパースされたサブグループ制御情報によって制御されることができる。パーサー（320）と下記の複数のユニットとの間のそのようなサブグループ制御情報の流れは、明確のため、描かれていない。

すでに述べた機能ブロックのほかに、デコーダ210は、以下に説明するように、概念的に、いくつかの機能ユニットに分割できる。商業的制約の下で機能する実際的な実装では、これらのユニットの多くは互いに密接に相互作用し、少なくとも部分的に互いに統合されることができる。しかしながら、開示される主題を記述する目的のためには、下記の機能単位への概念的な細分が適切である。

第1のユニットは、スケーラー／逆変換ユニット（351）である。スケーラー／逆変換ユニット（351）は、パーサー（320）から、量子化された変換係数および制御情報をシンボル（単数または複数）（321）として受領する。制御情報は、どの変換を使用するか、ブロック・サイズ、量子化因子、量子化スケーリング行列などを含む。スケーラー／逆変換ユニットは、集計器（355）に入力できるサンプル値を含むブロックを出力することができる。

場合によっては、スケーラー／逆変換（351）の出力サンプルは、イントラ符号化されたブロック、すなわち、以前に再構成されたピクチャーからの予測情報を使用していないが、現在ピクチャーの、以前に再構成された部分からの予測情報を使用することができるブロックに関することができる。そのような予測情報は、イントラ・ピクチャー予測ユニット（352）によって提供されることができる。場合によっては、イントラ・ピクチャー予測ユニット（352）は、現在の（部分的に再構成された）ピクチャー（358）から取ってきた、周囲のすでに再構成された情報を使用して、再構成中のブロックと同じサイズおよび形状のブロックを生成する。集計器（355）は、場合によっては、サンプル毎に、イントラ予測ユニット（352）が生成した予測情報を、スケーラー／逆変換ユニット（351）によって提供される出力サンプル情報に加算する。

他の場合には、スケーラー／逆変換ユニット（351）の出力サンプルは、インター符号化され、潜在的には動き補償されたブロックに関することができる。そのような場合、動き補償予測ユニット（353）は、予測のために使用されるサンプルを取ってくるために参照ピクチャー・メモリ（357）にアクセスすることができる。取ってきたサンプルを、ブロックに関するシンボル（321）に従って動き補償した後、これらのサンプルは、集計器（355）によってスケーラー／逆変換ユニットの出力（この場合、残差サンプルまたは残差信号と呼ばれる）に加算されて、それにより出力サンプル情報を生成することができる。動き補償ユニットが予測サンプルを取ってくる参照ピクチャー・メモリ内のアドレスは、シンボル（321）の形で動き補償ユニットに利用可能な動きベクトルによって制御できる。該シンボルは、たとえばX、Y、および参照ピクチャー成分を有することができる。動き補償は、サンプル以下の正確な動きベクトルが使用されるときの参照ピクチャー・メモリから取ってこられるサンプル値の補間、動きベクトル予測機構などを含むことができる。

集計器（355）の出力サンプルは、ループ・フィルタ・ユニット（356）内でさまざまなループ・フィルタリング技法を受けることができる。ビデオ圧縮技術は、ループ内フィルタ技術を含むことができる。ループ内フィルタ技術は、符号化されたビデオ・ビットストリームに含まれるパラメータによって制御され、パーサー（320）からのシンボル（321）としてループ・フィルタ・ユニット（356）に利用可能にされるが、符号化されたピクチャーまたは符号化されたビデオ・シーケンスの（デコード順で）前の部分のデコード中に得られたメタ情報に応答するとともに、以前に再構成されループ・フィルタリングされたサンプル値に応答することもできる。

ループ・フィルタ・ユニット（356）の出力はサンプル・ストリームであることができ、これは、レンダー装置（212）に出力されることができ、また将来のインターピクチャー予測において使用するために参照ピクチャー・メモリに記憶されることができる。

ある符号化されたピクチャーは、いったん完全に再構成されると、将来の予測のための参照ピクチャーとして使用できる。たとえば、符号化されたピクチャーが完全に再構成され、該符号化されたピクチャーが（たとえば、パーサー（320）によって）参照ピクチャーとして同定されると、現在の参照ピクチャー（358）は参照ピクチャー・バッファ（357）の一部となることができ、後続の符号化されたピクチャーの再構成を開始する前に、新鮮な現在ピクチャー・メモリが再割当てされることができる。

ビデオ・デコーダ（210）は、ITU-T勧告H.265のような標準において文書化されていてもよい所定のビデオ圧縮技術に従ってデコード動作を実行することができる。符号化されたビデオ・シーケンスは、ビデオ圧縮技術の文書もしくは標準において、特にその中のプロファイル文書において指定されているビデオ圧縮技術または標準のシンタックスに従うという意味で、使用されているビデオ圧縮技術または標準によって指定されたシンタックスに準拠することができる。準拠のためにはまた、符号化されたビデオ・シーケンスの複雑さが、ビデオ圧縮技術または標準のレベルによって定義される範囲内にあることも必要であることがある。いくつかの場合には、レベルは、最大ピクチャー・サイズ、最大フレーム・レート、最大再構成サンプル・レート（たとえば、毎秒メガサンプルの単位で測られる）、最大参照ピクチャー・サイズなどを制約する。レベルによって設定された限界は、場合によっては、符号化されたビデオ・シーケンスにおいて信号伝達される、HRDバッファ管理のための仮設参照デコーダ（Hypothetical Reference Decoder、HRD）仕様およびメタデータを通じてさらに制約されることができる。

ある実施形態において、受領器（310）は、エンコードされたビデオとともに追加の（冗長な）データを受領してもよい。追加データは、符号化されたビデオ・シーケンス（単数または複数）の一部として含まれていてもよい。追加データは、データを適正にデコードするため、および／またはもとのビデオ・データをより正確に再構成するために、ビデオ・デコーダ（210）によって使用されてもよい。追加データは、たとえば、時間的、空間的、またはSNRの向上層、冗長スライス、冗長ピクチャー、前方誤り訂正符号などの形でありうる。

図4は、本開示のある実施形態によるビデオ・エンコーダ（203）の機能ブロック図でありうる。

エンコーダ（203）は、該エンコーダ（203）によって符号化されるべきビデオ画像を捕捉することができるビデオ源（201）（これはエンコーダの一部ではない）からビデオ・サンプルを受領することができる。

ビデオ源（201）は、任意の好適なビット深さ（たとえば、8ビット、10ビット、12ビット、…）、任意の色空間（たとえば、BT.601 YCrCB、RGB、…）および任意の好適なサンプリング構造（たとえば、YCrCb 4:2:0、YCrCb 4:4:4）でありうるデジタル・ビデオ・サンプル・ストリームの形で、エンコーダ（203）によって符号化されるべき源ビデオ・シーケンスを提供することができる。メディア・サービス・システムにおいては、ビデオ源（201）は、事前に準備されたビデオを記憶している記憶装置であってもよい。ビデオ会議システムにおいては、ビデオ源（203）は、ローカルでの画像情報をビデオ・シーケンスとして捕捉するカメラであってもよい。ビデオ・データは、シーケンスで見たときに動きを付与する複数の個々のピクチャーとして提供されてもよい。ピクチャー自体は、ピクセルの空間的アレイとして編成されてもよく、各ピクセルは、使用中のサンプリング構造、色空間などに依存して、一つまたは複数のサンプルを含むことができる。当業者は、ピクセルとサンプルとの間の関係を容易に理解することができる。下記の説明は、サンプルに焦点を当てる。

ある実施形態によれば、エンコーダ（203）は、源ビデオ・シーケンスのピクチャーを、リアルタイムで、またはアプリケーションによって要求される任意の他の時間的制約の下で、符号化および圧縮して、符号化されたビデオ・シーケンス（443）にすることができる。適切な符号化速度を施行することは、コントローラ（450）の一つの機能である。コントローラは、以下に記載されるような他の機能ユニットを制御し、それらのユニットに機能的に結合される。かかる結合は、明確のため描かれていない。コントローラによって設定されるパラメータは、レート制御に関連するパラメータ（ピクチャー・スキップ、量子化器、レート‐歪み最適化技術のラムダ値、…）、ピクチャー・サイズ、ピクチャーグループ（GOP）レイアウト、最大動きベクトル探索範囲などを含むことができる。当業者は、ある種のシステム設計のために最適化されたビデオ・エンコーダ（203）に関しうるようなコントローラ（450）の他の機能を容易に識別することができる。

いくつかのビデオ・エンコーダは、当業者が「符号化ループ」として容易に認識するものにおいて動作する。思い切って単純化した説明として、一例では、符号化ループは、エンコーダ（430）（以下、「源符号化器」）（符号化されるべき入力ピクチャーと参照ピクチャー（単数または複数）に基づいてシンボルを生成することを受け持つ）のエンコード部と、エンコーダ（203）に埋め込まれた（ローカル）デコーダ（433）とからなることができる。デコーダは、（リモートの）デコーダも生成するであろうサンプル・データを生成するよう前記シンボルを再構成する（開示される主題において考慮されるビデオ圧縮技術では、シンボルと符号化されたビデオ・ビットストリームとの間のどの圧縮も無損失である）。再構成されたサンプル・ストリームは、参照ピクチャー・メモリ（434）に入力される。シンボル・ストリームのデコードは、デコーダ位置（ローカルかリモートか）によらずビット正確な結果をもたらすので、参照ピクチャー・バッファの内容もローカル・エンコーダとリモート・エンコーダの間でビット正確である。言い換えると、エンコーダの予測部は、デコーダがデコード中に予測を使用するときに「見る」のとまったく同じサンプル値を参照ピクチャー・サンプルとして「見る」。参照ピクチャー同期性のこの基本原理（および、たとえば、チャネルエラーのために同期性が維持できない場合の結果として生じるドリフト）は、当業者にはよく知られている。

「ローカル」デコーダ（433）の動作は、図3との関連ですでに上記で詳細に述べた「リモート」デコーダ（210）の動作と同じであってよい。しかしながら、暫時図4も参照すると、シンボルが利用可能であり、エントロピー符号化器（445）およびパーサー（320）による、シンボルの符号化されたビデオ・シーケンスへのエンコード／デコードが可逆でありうるので、チャネル（312）、受領器（310）、バッファ（315）およびパーサー（320）を含むデコーダ（210）のエントロピー復号部は、ローカル・デコーダ（433）においては完全には実装されなくてもよい。

この時点で行なうことができる観察は、デコーダ内に存在するパース／エントロピー復号を除くどのデコーダ技術も、必ず、対応するエンコーダ内で実質的に同一の機能的形態で存在する必要があることである。この理由で、開示される主題は、デコーダ動作に焦点を当てる。エンコーダ技術の記述は、包括的に記述されるデコーダ技術の逆であるため、短縮することができる。ある種の領域においてのみ、より詳細な説明が必要であり、以下に提供される。

その動作の一部として、源符号化器（430）は、「参照フレーム」として指定された、ビデオ・シーケンスからの一つまたは複数の以前に符号化されたフレームを参照して、入力フレームを予測的に符号化する、動き補償された予測符号化を実行することができる。このようにして、符号化エンジン（432）は、入力フレームのピクセル・ブロックと、入力フレームに対する予測参照として選択されうる参照フレーム（単数または複数）のピクセル・ブロックとの間の差分を符号化する。

ローカル・ビデオ・デコーダ（433）は、源符号化器（430）によって生成されたシンボルに基づいて、参照フレームとして指定されうるフレームの符号化されたビデオ・データをデコードすることができる。符号化エンジン（432）の動作は、有利には、損失のあるプロセスでありうる。符号化されたビデオ・データがビデオ・デコーダ（図4には示さず）でデコードされうるとき、再構成されたビデオ・シーケンスは、典型的には、いくつかのエラーを伴う源ビデオ・シーケンスの複製でありうる。ローカル・ビデオ・デコーダ（433）は、ビデオ・デコーダによって参照フレームに対して実行されうるデコード・プロセスを複製し、再構成された参照フレームを参照ピクチャー・キャッシュ（434）に格納させることができる。このようにして、エンコーダ（203）は、遠端のビデオ・デコーダによって得られるであろう再構成された参照フレームとしての共通の内容を（伝送エラーがなければ）有する再構成された参照フレームのコピーを、ローカルに記憶することができる。

予測器（435）は、符号化エンジン（432）について予測探索を実行することができる。すなわち、符号化されるべき新しいフレームについて、予測器（435）は、新しいピクチャーのための適切な予測参照のはたらきをしうるサンプル・データ（候補参照ピクセル・ブロックとして）またはある種のメタデータ、たとえば参照ピクチャー動きベクトル、ブロック形状などを求めて、参照ピクチャー・メモリ（434）を探索することができる。予測器（435）は、適切な予測参照を見出すために、サンプル・ブロック／ピクセル・ブロック毎に（on a sample block-by-pixel block basis）動作しうる。場合によっては、予測器（435）によって得られた検索結果によって決定されるところにより、入力ピクチャーは、参照ピクチャー・メモリ（434）に記憶された複数の参照ピクチャーから引き出された予測参照を有することができる。

コントローラ（450）は、たとえば、ビデオ・データをエンコードするために使用されるパラメータおよびサブグループ・パラメータの設定を含め、ビデオ符号化器（430）の符号化動作を管理してもよい。

上記の機能ユニットすべての出力は、エントロピー符号化器（445）におけるエントロピー符号化を受けることができる。エントロピー符号化器は、たとえばハフマン符号化、可変長符号化、算術符号化などといった当業者に既知の技術に従ってシンボルを無損失圧縮することによって、さまざまな機能ユニットによって生成されたシンボルを符号化されたビデオ・シーケンスに変換する。

送信器（440）は、エントロピー符号化器（445）によって生成される符号化されたビデオ・シーケンスをバッファに入れて、通信チャネル（460）を介した送信のためにそれを準備することができる。通信チャネルは、エンコードされたビデオ・データを記憶する記憶装置へのハードウェア／ソフトウェア・リンクであってもよい。送信器（440）は、ビデオ符号化器（430）からの符号化されたビデオ・データを、送信されるべき他のデータ、たとえば符号化されたオーディオ・データおよび／または補助データ・ストリーム（源は図示せず）とマージすることができる。

コントローラ（450）は、エンコーダ（203）の動作を管理してもよい。符号化の間、コントローラ（450）は、それぞれの符号化されたピクチャーに、ある符号化ピクチャー・タイプを割り当てることができる。符号化ピクチャー・タイプは、それぞれのピクチャーに適用されうる符号化技法に影響しうる。たとえば、ピクチャーはしばしば、以下のフレーム・タイプのうちの1つとして割り当てられることがある。

イントラピクチャー（Iピクチャー）は、予測の源としてシーケンス内の他のピクチャーを使用せずに、符号化され、デコードされうるものでありうる。いくつかのビデオ・コーデックは、たとえば、独立デコーダ・リフレッシュ（Independent Decoder Refresh）・ピクチャーを含む、異なるタイプのイントラ・ピクチャーを許容する。当業者は、Iピクチャーのこれらの変形、ならびにそれらのそれぞれの用途および特徴を認識する。

予測ピクチャー（Pピクチャー）は、各ブロックのサンプル値を予測するために、最大で1つの動きベクトルおよび参照インデックスを用いるイントラ予測またはインター予測を用いて符号化およびデコードされうるものでありうる。

双方向予測ピクチャー（Bピクチャー）は、各ブロックのサンプル値を予測するために、最大で2つの動きベクトルおよび参照インデックスを用いるイントラ予測またはインター予測を用いて符号化およびデコードされうるものでありうる。同様に、マルチ予測ピクチャーは、単一のブロックの再構成のために、3つ以上の参照ピクチャーおよび関連するメタデータを使用することができる。

源ピクチャーは、普通、空間的に複数のサンプル・ブロック（たとえば、それぞれ4×4、8×8、4×8、または16×16サンプルのブロック）に分割され、ブロック毎に符号化されうる。ブロックは、ブロックのそれぞれのピクチャーに適用される符号化割り当てによって決定されるところにより、他の（すでに符号化された）ブロックを参照して予測的に符号化されうる。たとえば、Iピクチャーのブロックは、非予測的に符号化されてもよく、または、同じピクチャーのすでに符号化されたブロックを参照して予測的に符号化されてもよい（空間的予測またはイントラ予測）。Pピクチャーのピクセル・ブロックは、以前に符号化された一つの参照ピクチャーを参照して、空間的予測を介してまたは時間的予測を介して予測的に符号化されてもよい。Bピクチャーのブロックは、1つまたは2つの以前に符号化された参照ピクチャーを参照して、空間的予測を介して、または時間的予測を介して予測的に符号化されてもよい。

ビデオ符号化器（203）は、ITU-T勧告H.265などの所定のビデオ符号化技術または標準に従って符号化動作を実行することができる。その動作において、ビデオ符号化器（203）は、入力ビデオ・シーケンスにおける時間的および空間的冗長性を活用する予測符号化動作を含む、さまざまな圧縮動作を実行することができる。よって、符号化されたビデオ・データは、使用されるビデオ符号化技術または標準によって指定されるシンタックスに準拠しうる。

ある実施形態では、送信器（440）は、エンコードされたビデオと一緒に追加データを送信してもよい。ビデオ符号化器（430）は、符号化されたビデオ・シーケンスの一部としてそのようなデータを含めてもよい。追加データは、時間的／空間的／SNR向上層、冗長ピクチャーおよびスライスのような他の形の冗長データ、補足向上情報（SEI）メッセージ、視覚ユーザビリティー情報（VUI）パラメータ・セット・フラグメントなどを含んでいてもよい。

近年、複数の意味的に独立したピクチャー部分の、単一のビデオ・ピクチャーへの圧縮領域での集約および抽出が注目をいくらか集めている。特に、たとえば、360符号化またはある種の監視アプリケーションの文脈において、複数の意味的に独立したソースピクチャー（たとえば、立方体投影された360シーンの6つの立方体表面、またはマルチカメラ監視セットアップの場合の個々のカメラ入力）が、所与の時点での異なるシーン毎の活動に対処するために、別個の適応解像度設定を必要とすることがある。言い換えれば、エンコーダは、所定の時点で、360全体または監視シーンを構成する、異なる意味的に独立したピクチャーについて異なる再サンプリング因子を使用することを選択することができる。単一のピクチャーに組み合わされる場合、そのためには、参照ピクチャー再サンプリングが実行され、符号化されたピクチャーの諸部分について適応解像度符号化信号伝達が利用可能であることが必要とされる。

以下では、本稿の残りの部分で言及するいくつかの用語を紹介する。

サブピクチャーは、いくつかの場合には、サンプル、ブロック、マクロブロック、符号化単位、または意味的にグループ化され、変更された解像度で独立に符号化されるうる同様のエンティティの、長方形配置を指しうる。一つまたは複数のサブピクチャーがピクチャーを形成してもよい。一つまたは複数の符号化されたサブピクチャーが、符号化されたピクチャーを形成してもよい。一つまたは複数のサブピクチャーが1つのピクチャーに組み立てられてもよく、一つまたは複数のサブピクチャーが1つのピクチャーから抽出されてもよい。ある種の環境では、一つまたは複数の符号化されたサブピクチャーは、サンプルレベルにトランスコードすることなく、圧縮領域で、符号化されたピクチャーに組み立てられてもよく、同じ場合または他の場合において、一つまたは複数の符号化されたサブピクチャーが、圧縮領域で、符号化されたピクチャーから抽出されてもよい。

適応解像度変化（Adaptive Resolution Change、ARC）は、たとえば参照ピクチャー再サンプリングによって、符号化ビデオ・シーケンス内のピクチャーまたはサブピクチャーの解像度の変化を許容する機構を指しうる。以下、ARCパラメータは、適応解像度変化を実行するために必要とされる制御情報を指し、たとえば、フィルタ・パラメータ、スケーリング因子、出力および／または参照ピクチャーの解像度、さまざまな制御フラグなどを含みうる。

諸実施形態において、符号化および復号は、単一の意味的に独立した符号化されたビデオ・ピクチャーに対して実行されてもよい。独立したARCパラメータをもつ複数のサブピクチャーの符号化／復号の含意とその含意される追加的な複雑さを記述する前に、ARCパラメータを信号伝達するための諸オプションが記述される。

図5A～図5Eを参照すると、ARCパラメータを信号伝達するためのいくつかの実施形態が示されている。実施形態のそれぞれに関して記されるように、それらは、符号化効率、複雑さ、およびアーキテクチャーの観点から、ある種の利点およびある種の欠点を有しうる。ビデオ符号化標準または技術は、ARCパラメータを信号伝達するために、これらの実施形態または関連技術から既知のオプションのうちの一つまたは複数を選択することができる。それらの実施形態は、互いに背反でなくてもよく、用途の必要性、関連する標準技術、またはエンコーダの選択に基づいて交換されうることが考えられる。

ARCパラメータのクラスは、以下を含んでいてもよい。

・X次元およびY次元における別個のまたは組み合わされたアップサンプリング／ダウンサンプリング因子。

・アップサンプリング／ダウンサンプリング因子に、所与の数のピクチャーについての一定速度のズームイン／アウトを示す時間次元を加えたもの。

・上記の2つのいずれも、前記因子（単数または複数）を含むテーブル中をポイントしうる一つまたは複数の、おそらくは短い構文要素の符号化を含んでいてもよい。

・サンプル、ブロック、マクロブロック、符号化単位（CU）の単位での、または他の任意の好適な粒度での、入力ピクチャー、出力ピクチャー、参照ピクチャー、符号化ピクチャーの、X次元またはY次元の解像度。複数の解像度（たとえば、入力ピクチャーのために1つ、参照ピクチャーのために1つ）がある場合、ある種の場合には、1組の値が別の組の値から推測されうる。それは、たとえば、フラグの使用により、ゲーティングされることができる。より詳細な例については、以下を参照されたい。

・やはり上述したように好適な粒度での、H.263付属書Pで使用されているものと同様の「歪み（warping）」座標。H.263付属書Pは、そのような歪み座標を符号化するための1つの効率的な仕方を定義しているが、他の、潜在的にはより効率的な仕方も考案されうることが考えられる。たとえば、付属書Pの、可変長の可逆的な「ハフマン」式の、歪み座標の符号化は、好適な長さのバイナリ符号化で置き換えられることができる。ここで、バイナリ符号語の長さは、たとえば、最大ピクチャー・サイズ、可能性としては、最大ピクチャー・サイズの境界の外への「歪め」を許容するよう最大ピクチャー・サイズにある因子を乗算し、ある値だけオフセットしたものから、導出されることができる。

・アップサンプリングまたはダウンサンプリング・フィルタ・パラメータ。諸実施形態において、アップおよび／またはダウンサンプリングのための単一のフィルタのみが存在してもよい。しかしながら、諸実施形態において、フィルタ設計においてより大きな柔軟性を許容することが望ましく、そのことは、フィルタ・パラメータの信号伝達を必要とすることがある。そのようなパラメータは、可能なフィルタ設計のリストにおけるインデックスを通じて選択されてもよく、フィルタは、完全に指定されてもよく（たとえば、フィルタ係数のリストを通じて、好適なエントロピー符号化技術を用いて）、フィルタは、上述の機構のいずれかに従って信号伝達されるアップサンプリング／ダウンサンプリング比を通じて暗黙的に選択されてもよい。

以下、本稿は、符号語を通じて示される、アップサンプリング／ダウンサンプリング因子の有限集合（X次元およびY次元の両方で同じ因子が使用される）の符号化を想定する。その符号語は可変長符号化されてもよく、たとえば、H.264およびH.265のようなビデオ符号化仕様におけるある種の構文要素に共通のExt-Golomb（ゴロム）符号を使用する。値のアップサンプリング／ダウンサンプリング因子への1つの好適なマッピングは、たとえば、表1によるものであってもよい：

多くの同様のマッピングが、用途のニーズ、およびビデオ圧縮技術または標準において利用可能なアップスケールおよびダウンスケール機構の能力に従って考案できる。この表は、より多くの値に拡張できる。値は、たとえば、バイナリ符号化を使用して、Ext-Golomb符号以外のエントロピー符号化機構によって表現されてもよい。そのことは、たとえばMANEによって、ビデオ処理エンジン（エンコーダおよびデコーダ第一）自体の外部で再サンプリング因子が関心対象であった場合に、ある種の利点を有しうる。解像度変化が要求されない状況については、短いExt-Golomb符号を選択することができ、上の表では、1ビットのみであることに注意しておくべきである。これは、最も一般的な場合について、バイナリ符号を使用するよりも符号化効率が優れている可能性がある。

表中の項目の数とそれらの意味内容は、完全にあるいは部分的に構成設定可能であってもよい。たとえば、表の基本的な概要は、シーケンスまたはデコーダパラメータセットのような「高位の」パラメータセットにおいて伝達されてもよい。諸実施形態において、一つまたは複数のかかる表が、ビデオ符号化技術または標準において定義されてもよく、たとえばデコーダまたはシーケンスパラメータセットを通じて選択されてもよい。

以下では、上述したように符号化されたアップサンプリング／ダウンサンプリング因子（ARC情報）が、ビデオ符号化技術または標準構文にどのように含まれうるかについて説明する。同様の考慮は、アップ／ダウンサンプリング・フィルタを制御する1つまたは少数の符号語に適用されうる。フィルタや他のデータ構造のために比較的大量のデータが必要とされる場合の議論については、下記を参照されたい。

図5Aに示されるように、H.263付属書Pは、4つの歪み座標の形のARC情報（502）を、ピクチャー・ヘッダ（501）中に、特にH.263 PLUSPTYPE（503）ヘッダ拡張において含める。これは、a）利用可能なピクチャー・ヘッダがあり、b）ARC情報の頻繁な変更が予想される場合に、合理的な設計選択となりうる。しかしながら、H.263スタイルの信号伝達を使用する場合のオーバーヘッドは非常に高いことがあり、ピクチャー・ヘッダが一時的な性質のものである可能性があるため、スケーリング因子はピクチャー境界の間で関係しない可能性がある。

図5Bに示されるように、JVCET-M135-v1は、ピクチャーパラメータセット（504）内に位置するARC参照情報（505）（インデックス）を含み、それが、シーケンスパラメータセット（507）内に位置する目標解像度を含む表（506）をインデックス付けする。可能な解像度をシーケンスパラメータセット（507）内の表（506）に入れることは、作者によってなされる口頭の陳述によれば、機能交換（capability exchange）の間の相互運用性折衝点としてSPSを使用することによって正当化できる。解像度は、適切なピクチャーパラメータセット（504）を参照することによって、ピクチャーごとに、表（506）内の値によって設定された制限内で、変化することができる。

図5C～図5Eを参照すると、以下の実施形態は、ビデオ・ビットストリームにおいてARC情報を伝達するために存在しうる。これらのオプションのそれぞれは、上述の実施形態よりもある種の利点を有する。実施形態は、同じビデオ符号化技術または標準において同時に存在してもよい。

諸実施形態、たとえば図5Cに示される実施形態において、再サンプリング（ズーム）因子のようなARC情報（509）は、スライスヘッダ、GOPヘッダ、タイルヘッダ、またはタイル・グループ・ヘッダにあってもよい。図5Cは、タイル・グループ・ヘッダ（508）が使用される実施形態を示す。これは、ARC情報が小さく、たとえば、単一の可変長のue(v)またはたとえば上記で示したように数ビットの固定長の符号語である場合に十分でありうる。ARC情報をタイル・グループ・ヘッダ内に直接有することは、ARC情報がたとえば、そのピクチャー全体ではなくそのタイル・グループによって表されるサブピクチャーに適用可能でありうるという、追加的な利点を有する。以下も参照されたい。さらに、ビデオ圧縮技術または標準が（たとえば、タイル・グループ・ベースの適応解像度の変化ではなく）ピクチャー全体の適応解像度変化のみを想定しているとしても、ARC情報をタイル・グループ・ヘッダに入れることは、H.263スタイルのピクチャー・ヘッダに入れることと比較して、エラー耐性の観点からある種の利点を有する。

諸実施形態、たとえば図5Dに示される実施形態において、ARC情報（512）自体は、適切なパラメータセット、たとえばピクチャーパラメータセット、ヘッダパラメータセット、タイルパラメータセット、適応パラメータセットなどに存在してもよい。図5Dは、適応パラメータセット（adaptation parameter set）（511）が使用される実施形態を示す。そのパラメータセットの範囲は、有利には、ピクチャー、たとえばタイル・グループよりも大きくなくてもよい。ARC情報の使用は、関連するパラメータセットのアクティブ化を通じて暗黙的になされる。たとえば、ビデオ符号化技術または標準がピクチャーベースのARCのみを考えている場合、ピクチャーパラメータセットまたは同等物が適切でありうる。

実施形態、たとえば図5Eに示される実施形態において、ARC参照情報（513）は、タイル・グループ・ヘッダ（514）または類似のデータ構造内に存在してもよい。その参照情報（513）は、単一のピクチャーを超えたスコープをもつパラメータセット（516）、たとえばシーケンスパラメータセットまたはデコーダパラメータセット内で利用可能なARC情報（515）のサブセットを参照することができる。

JVET-M0135-v1で使用されているタイル・グループ・ヘッダ、PPS、SPSからのPPSの、追加的なレベルの間接参照に含意されるアクティブ化は不要と思われる。ピクチャーパラメータセットが、シーケンスパラメータセットと同様に、機能折衝またはアナウンス（capability negotiation or announcements）のために使用できる（そして、RFC3984のようなある種の標準ではもつことができる）からである。しかしながら、ARC情報が、たとえばタイル・グループによっても表現されるサブピクチャーに適用可能であるべきであれば、適応パラメータセットまたはヘッダパラメータセットのような、タイル・グループに限定されたアクティブ化スコープをもつパラメータセットがよりよい選択であるかもしれない。また、ARC情報が、無視できないほどの大きである、たとえば、多数のフィルタ係数のようなフィルタ制御情報を含む場合、パラメータは、直接的にヘッダ（508）を使用するよりも、符号化効率の観点から良い選択でありうる。なぜなら、それらの設定は、同じパラメータセットを参照することによって、将来のピクチャーまたはサブピクチャーによって再利用可能でありうるからである。

シーケンスパラメータセット、または複数のピクチャーにまたがるスコープをもつ別のより高位のパラメータセットを使用する場合は、ある種の考慮事項が適用されることがある。

1. ARC情報テーブル（516）を記憶するために設定されたパラメータは、いくつかの場合には、シーケンスパラメータセットでありうるが、他の場合には、有利には、デコーダパラメータセットでありうる。デコーダパラメータセットは、複数のCVS、すなわち符号化ビデオストリーム、すなわちセッション開始からセッション解除までのすべての符号化されたビデオ・ビットのアクティブ化スコープをもつことができる。可能なARC因子は、可能性としてはハードウェアで実装されるデコーダ機能であってもよく、ハードウェア機能は、どんなCVSでも（少なくとも一部の娯楽システムでは、CVSは1秒以下の長さのピクチャーグループである）変化しない傾向があるため、そのようなスコープのほうがより適切でありうる。とはいえ、テーブルをシーケンスパラメータセットに入れることは、特に下記のポイント2との関連で、本明細書に記載される配置オプションに明示的に含まれる。

2. ARC参照情報（513）は、有利には、JVCET-M0135-v1などでのようにピクチャーパラメータセットにではなく、ピクチャー／スライス タイル／GOP／タイル・グループ・ヘッダ、たとえばタイル・グループ・ヘッダ（514）の中に直接配置されてもよい。たとえば、エンコーダが、たとえばARC参照情報のような、ピクチャーパラメータセット内の単一の値を変更したい場合、新しいPPSを作成し、その新しいPPSを参照しなければならない。ARC参照情報のみが変化し、たとえばPPSにおける量子化マトリクス情報のような他の情報は変化しないと想定する。そのような情報は、かなりのサイズである可能性があり、新しいPPSを完全にするために再送される必要があるであろう。ARC参照情報（513）は、変化する唯一の値であろう、テーブルへのインデックスのような単一の符号語であってもよいので、たとえば量子化マトリクス情報の全部を再送することはわずらわしく、無駄であろう。そこで、JVET-M0135-v1で提案されているように、PPSを通じた間接参照を回避するために、符号化効率の観点から、かなり優れている可能性がある。同様に、ARC参照情報をPPSに入れることは、ARC参照情報（513）によって参照されるARC情報は、ピクチャーパラメータセットのアクティブ化のスコープがピクチャーであるため、サブピクチャーではなくピクチャー全体に適用される可能性があるという追加的な欠点をもつ。

同じ実施形態または別の実施形態において、ARCパラメータの信号伝達は、図6A～6Bに概説されている詳細な例に従うことができる。図6A～図6Bは、たとえば、少なくとも1993年以降のビデオ符号化標準で使用されるように、Cスタイルのプログラミングにほぼ従う記法を使用した表現型式での構文図を示す。太線はビットストリームに存在する構文要素を示し、太くしない線は制御フローや変数の設定を示すことが多い。

図6Aに示されるように、タイル・グループ・ヘッダ（601）は、ピクチャーの（可能性としては長方形の）一部分に適用可能なヘッダの例示的な構文構造として、条件付きで、可変長のExp-Golomb〔指数ゴロム〕符号化構文要素dec_pic_size_idx（602）を含むことができる（太字で示されている）。タイル・グループ・ヘッダ中のこの構文要素の存在は、適応解像度（603）――ここでは太字で示されていないフラグの値――を使用してゲーティングされることができる。これは、フラグが構文図中で現れる点においてビットストリーム中に存在することを意味する。適応解像度がこのピクチャーまたはその一部について使用されるか否かは、ビットストリームの内側または外側の任意の高レベル構文構造において信号伝達されることができる。示される例では、以下に概説されるように、シーケンスパラメータセットにおいて信号伝達される。

図6Bを参照すると、シーケンスパラメータセット（610）の抜粋も示されている。示されている最初の構文要素はadaptive_pic_resolution_change_flag（611）である。真の場合、そのフラグは、適応解像度の使用を示すことができ、これは、ある種の制御情報を必要とすることがある。この例では、そのような制御情報は、パラメータセット（612）およびタイル・グループ・ヘッダ（601）におけるif()文に基づいて、フラグの値に基づいて条件付きで存在する。

適応解像度を使用している場合、この例では、サンプルの単位での出力解像度（613）が符号化される。符号613は、output_pic_width_in_luma_samplesおよびoutput_pic_height_in_luma_samplesの両方を指し、これらは一緒になって、出力ピクチャーの解像度を定義することができる。ビデオ符号化技術または標準の他所において、どちらかの値に対するある種の制約が定義されることができる。たとえば、レベル定義は、これらの2つの構文要素の値の積であってもよい全出力サンプル数を制限しうる。また、ある種のビデオ符号化技術もしくは標準、または、たとえば、システム規格のような外部の技術もしくは標準は、番号付け範囲（たとえば、一方または両方の寸法が2の冪乗の数で割り切れねばならない）またはアスペクト比（たとえば、幅および高さは、4:3または16:9のような関係になければならない）を制限することがある。そのような制約は、ハードウェアの実装を容易にするために、または他の理由のために導入されてもよく、当技術分野では周知である。

ある種の用途では、暗黙のうちにそのサイズが出力ピクチャー・サイズであると想定するのではなく、エンコーダがデコーダにある参照ピクチャー・サイズを使用するように指示することが望ましいことがある。この例では、構文要素reference_pic_size_present_flag（614）が、参照ピクチャー寸法（615）の条件付き存在をゲーティングする（ここでもまた、数字は幅と高さの両方を指す）。

最後に、可能なデコード・ピクチャー幅および高さのテーブルが示される。そのようなテーブルは、たとえば、テーブル指示（num_dec_pic_size_in_luma_samples_minus1）（616）によって表すことができる。「minus1」〔1を引いたもの〕は、その構文要素の値の解釈を指すことができる。たとえば、符号化された値がゼロであれば、1つのテーブルエントリーが存在し、値が5であれば、6つのテーブルエントリーが存在する。テーブル中の各「行」について、デコードされたピクチャーの幅および高さが構文（617）に含まれる。

提示されたテーブルエントリー（617）は、タイル・グループ・ヘッダ内の構文要素dec_pic_size_idx（602）を使用してインデックス付けでき、それにより、タイル・グループ毎に異なるデコードされたサイズ――事実上はズーム因子――を許容する。

VVCの関連技術の実装では、参照ピクチャー幅が現在のピクチャー幅と異なる場合、ラップアラウンド動き補償が正しく機能できないという問題がありうる。諸実施形態において、ラップアラウンド動き補償は、現在のピクチャーの層が従属層である場合、または現在の層についてRPRが有効である場合、高レベル構文で無効にされてもよい。諸実施形態において、参照ピクチャー幅が現在のピクチャー幅と異なる場合、ラップアラウンド処理は、動き補償のための補間プロセスの間、無効にされてもよい。

ラップアラウンド動き補償は、たとえば正距円筒投影（equirectangular projection、ERP）フォーマットを有する360投影ピクチャーを符号化するのに有用な特徴でありうる。これは、継ぎ目におけるいくつかの視覚的アーチファクトを低減し、符号化利得を改善することができる。現在のVVC仕様書草案JVET-P2001（編集上、JVET-Q0041により更新された）では、SPSにおけるsps_ref_wraparound_offset_minus1は、水平方向のラップアラウンド位置の計算に使用されるオフセットを指定する。

ラップアラウンド・オフセット値がピクチャー幅に関連して決定されるという問題が生じうる。参照ピクチャーのピクチャー幅が現在のピクチャー幅と異なる場合、ラップアラウンド・オフセット値は、現在のピクチャーと参照ピクチャーとの間のスケーリング比に比例して変更されるべきである。しかしながら、実際的には、各参照ピクチャーのピクチャー幅に従ってオフセット値を調整することは、ラップアラウンド動き補償の利点と比較して、実装および計算の複雑さを大幅に増大させる可能性がある。異なるピクチャー・サイズのある層間予測と参照ピクチャー再サンプリング（reference picture resampling、RPR）は、層および時間的ピクチャーを横断して異なるピクチャー解像度のおそろしく多様な組み合わせをもたらす可能性がある。

実施形態はこの問題に取り組むことができる。たとえば、実施形態では、現在のピクチャーの層が従属層である場合、または現在の層についてRPRが有効にされている場合、sps_ref_wraparound_enabled_flagを0に等しく設定することによって、ラップアラウンド動き補償が無効にされてもよい。よって、ラップアラウンド動き補償は、現在の層が独立層であり、RPRが無効にされている場合にのみ使用できる。この条件下では、参照ピクチャー・サイズは現在のピクチャー・サイズに等しい。さらに、諸実施形態において、参照ピクチャー幅が現在のピクチャー幅と異なる場合、動き補償のための補間プロセスの間、ラップアラウンド動き補償プロセスが無効にされてもよい。

実施形態は、別個に使用されてもよく、または任意の順序で組み合わされてもよい。さらに、方法（または実施形態）、エンコーダ、およびデコーダのそれぞれは、処理回路（たとえば、一つまたは複数のプロセッサ、または一つまたは複数の集積回路）によって実装されてもよい。一例では、前記一つまたは複数のプロセッサは、非一時的なコンピュータ読み取り可能媒体に記憶されたプログラムを実行する。

図7は、諸実施形態による、例示的な構文表を示す。諸実施形態において、sps_ref_wraparound_enabled_flag（701）が1に等しいことは、水平方向のラップアラウンド動き補償がインター予測に適用されることを指定してもよい。sps_ref_wraparound_enabled_flag（701）が0に等しいことは、水平方向のラップアラウンド動き補償が適用されないことを指定することができる。（CtbSizeY/MinCbSizeY＋1）の値が（pic_width_in_luma_samples/MinCbSizeY－1）以下であり、ここで、pic_width_in_luma_samplesはSPSを参照する任意のPPSにおけるpic_width_in_luma_samplesの値である、場合、sps_ref_wraparound_enabled_flag（701）は0に等しくてもよい。vps_independent_layer_flag[GeneralLayerIdx[nuh_layer_id]]が0に等しいときはsps_ref_wraparound_enabled_flag（701）の値が0に等しいことは、ビットストリーム適合性の要件であってもよい。存在しない場合、sps_ref_wraparound_enabled_flag（701）の値は、0に等しいと推定されてもよい。

諸実施形態において、refPicWidthInLumaSamplesは、現在のピクチャーの現在の参照ピクチャーのpic_width_in_luma_samplesであってもよい。諸実施形態において、refPicWidthInLumaSamplesが現在のピクチャーのpic_width_in_luma_samplesに等しい場合、refWraparoundEnabledFlagは、sps_ref_wraparound_enabled_flagに等しく設定されてもよい。さもなければ、refWraparoundEnabledFlagは0に等しく設定されてもよい。

完全サンプル単位でのルーマ位置（xInti,yInti）は、i＝0..1について、以下のように導出されてもよい。

subpic_treated_as_pic_flag[SubPicIdx]が1に等しい場合、次が適用されてもよい：

そうでない場合（subpic_treated_as_pic_flag[subPicIdx]が0に等しい）、次が適用されてもよい：

完全サンプル単位でのルーマ位置（xInt,yInt）は、以下のように導出されてもよい。

subpic_treated_as_pic_flag[SubPicIdx]が1に等しい場合、次が適用されてもよい：

そうでない場合、次が適用されてもよい：

予測されるルーマ・サンプル値preSampleLXLは次のように導出されてもよい：preSampleLXL＝refPicLXL[xInt][yInt]<<shift3。

完全サンプル単位でのクロマ位置（xInti,yInti）は、i＝0..3について以下のように導出されてもよい。

subpic_treated_as_pic_flag[SubPicIdx]が1に等しい場合、次が適用されてもよい：

そうでない場合（subpic_treated_as_pic_flag[subPicIdx]が0に等しい）、次が適用されてもよい：

完全サンプル単位でのクロマ位置（xInti,yInti）は、さらに、i＝0..3について、次のように修正されてもよい：

図8A～8Cは、諸実施形態による、エンコードされたビデオ・ビットストリームを生成するための例示的なプロセス800A、800B、および800Cのフローチャートである。諸実施形態において、プロセス800A、800B、および800Cの任意のもの、またはプロセス800A、800B、および800Cの任意の部分は、任意の組み合わせまたは順列において、所望の任意の順序で、組み合わされてもよい。いくつかの実装では、図8A～8Cの一つまたは複数のプロセスブロックは、デコーダ210によって実行されてもよい。いくつかの実装では、図8A～8Cの一つまたは複数のプロセスブロックは、エンコーダ203のような、デコーダ210とは別個の、またはデコーダ210を含む、別の装置または装置群によって実行されてもよい。

図8Aに示されるように、プロセス800Aは、現在のピクチャーの現在の層が独立層であるかどうかに関する第1の決定を行うことを含んでいてもよい（ブロック811）。

図8Aにさらに示されるように、プロセス800Aは、参照ピクチャー再サンプリングが現在の層について有効にされているかどうかに関する第2の決定を行うことを含んでいてもよい（ブロック812）。

図8Aにさらに示されるように、プロセス800Aは、第1の決定および第2の決定に基づいて、現在のピクチャーについてラップアラウンド補償を無効にすることを含んでいてもよい（ブロック813）。

図8Aにさらに示されるように、プロセス800Aは、ラップアラウンド補償なしで現在のピクチャーをエンコードすることを含んでいてもよい（ブロック814）。

ある実施形態では、第1の決定は、第1の構文構造において信号伝達される第1のフラグに基づいてなされてもよく、第2の決定は、第1の構文構造よりも低位の第2の構文構造において信号伝達される第2のフラグに基づいてなされてもよい。

ある実施形態では、第1のフラグはビデオパラメータセットにおいて信号伝達されてもよく、第2のフラグはシーケンスパラメータセットにおいて信号伝達されてもよい。

ある実施形態では、ラップアラウンド補償は、第2のフラグがシーケンスパラメータセットにないことに基づいて無効にされてもよい。

図8Bに示されるように、プロセス800Bは、現在のピクチャーの現在の層が独立層であるかどうかを判定することを含んでいてもよい（ブロック821）。

図8Bにさらに示されるように、電流層が独立層でないと判定される場合（ブロック821でNO）、プロセス800Bはブロック822に進んでもよく、そこで、ラップアラウンド動き補償が無効化されてもよい。

図8Bにさらに示されるように、現在の層が独立層であると判定される場合（ブロック821でYES）、プロセス800Bはブロック823に進んでもよい。

図8Bにさらに示されるように、プロセス800Bは、参照ピクチャー再サンプリングが有効にされているかどうかを判断することを含んでいてもよい（ブロック823）。

図8Bにさらに示されるように、参照ピクチャー再サンプリングが有効にされていると判定される場合（ブロック823でYES）、プロセス800Bはブロック822に進んでもよく、そこで、ラップアラウンド動き補償が無効にされてもよい。

図8Bにさらに示されるように、参照ピクチャー再サンプリングが有効にされていないと判定される場合（ブロック823でNO）、プロセス800Bはブロック824に進んでもよく、そこで、ラップアラウンド動き補償が有効にされてもよい。

図8Cに示されるように、プロセス800Cは、現在のピクチャーの現在の層が独立層であると判定することを含んでいてもよい（ブロック831）。

図8Cにさらに示されるように、プロセス800Cは、参照ピクチャー再サンプリングが有効にされていることを判定することを含んでいてもよい（ブロック832）。

図8Cにさらに示されるように、プロセス800Cは、現在のピクチャーの幅が現在の参照ピクチャーの幅と異なるかどうかを判定することを含んでいてもよい（ブロック833）。

図8Cにさらに示されるように、現在のピクチャーの幅が現在の参照ピクチャーの幅と異なると判定される場合（ブロック833でYES）、プロセス800Cはブロック834に進んでもよく、そこで、ラップアラウンド動き補償が無効にされてもよい。

図8Cにさらに示されるように、現在のピクチャーの幅が現在の参照ピクチャーの幅と同じであると判定される場合（ブロック821でNO）、プロセス800Cはブロック835に進んでもよく、そこで、ラップアラウンド動き補償が有効にされてもよい。

ある実施形態では、ブロック833は、動き補償のための補間プロセスの間に実行されてもよい。

図8A～8Cは、プロセス800A、800B、および800Cの例示的なブロックを示しているが、いくつかの実装においては、プロセス800は、図8A～8Cに示されているブロックに比して、追加的なブロック、より少数のブロック、異なるブロック、または異なる配置のブロックを含んでいてもよい。追加的または代替的に、プロセス800A、800B、および800Cのブロックのうちの2つ以上は、並列に実行されてもよい。

さらに、提案された方法は、処理回路（たとえば、一つまたは複数のプロセッサまたは一つまたは複数の集積回路）によって実装されてもよい。一例では、前記一つまたは複数のプロセッサは、提案された方法の一つまたは複数を実行するために、非一時的なコンピュータ読み取り可能媒体に記憶されたプログラムを実行する。

上述の技法は、コンピュータ読み取り可能な命令を用いてコンピュータ・ソフトウェアとして実装されることができ、一つまたは複数のコンピュータ読み取り可能な媒体に物理的に記憶されることができる。たとえば、図9は、開示された主題のある種の実施形態を実装するのに好適なコンピュータ・システム900を示す。

コンピュータ・ソフトウェアは、任意の好適な機械コードまたはコンピュータ言語を用いてコーディングされることができ、アセンブリ、コンパイル、リンク、または同様の機構の対象とされて、コンピュータ中央処理ユニット（CPU）、グラフィックス処理ユニット（GPU）などによって、直接的に、またはインタープリット、マイクロコード実行などを通じて実行可能な命令を含むコードを作成することができる。

命令は、たとえば、パーソナルコンピュータ、タブレット・コンピュータ、サーバー、スマートフォン、ゲーム装置、モノのインターネット装置等を含むさまざまなタイプのコンピュータまたはそのコンポーネント上で実行されることができる。

コンピュータ・システム900について図9に示されるコンポーネントは、例としての性質であり、本開示の実施形態を実装するコンピュータ・ソフトウェアの使用または機能の範囲に関する制限を示唆することを意図したものではない。コンポーネントの構成も、コンピュータ・システム900の例示的実施形態において示されているコンポーネントの任意の1つまたは組み合わせに関する何らかの依存性または要件を有するものとして解釈されるべきではない。

コンピュータ・システム900は、ある種のヒューマン・インターフェース入力装置を含むことができる。そのようなヒューマン・インターフェース入力装置は、たとえば、触覚入力（たとえば、キーストローク、スワイプ、データグローブの動き）、音声入力（たとえば、声、拍手）、視覚入力（たとえば、ジェスチャー）、嗅覚入力（図示せず）を通じた一または複数の人間ユーザーによる入力に応答することができる。また、ヒューマン・インターフェース装置は、音声（たとえば、発話、音楽、周囲の音）、画像（たとえば、スキャンされた画像、スチール画像カメラから得られる写真画像）、ビデオ（たとえば、2次元ビデオ、立体視ビデオを含む3次元ビデオ）のような、人間による意識的入力に必ずしも直接関係しないある種のメディアを捕捉するために使用できる。

入力ヒューマン・インターフェース装置は、キーボード901、マウス902、トラックパッド903、タッチスクリーン910および付随するグラフィックスアダプター950、データグローブ、ジョイスティック905、マイクロフォン906、スキャナ907、カメラ908（それぞれの一つのみが描かれている）の一つまたは複数を含んでいてもよい。

コンピュータ・システム900はまた、ある種のヒューマン・インターフェース出力装置を含んでいてもよい。そのようなヒューマン・インターフェース出力装置は、たとえば、触覚出力、音、光、および臭い／味を通じて、一または複数の人間ユーザーの感覚を刺激するものであってもよい。そのようなヒューマン・インターフェース出力装置は、触覚出力装置（たとえば、タッチスクリーン910、データグローブまたはジョイスティック905による触覚フィードバック；ただし、入力装置のはたらきをしない触覚フィードバック装置もありうる）、音声出力装置（たとえば、スピーカー909、ヘッドフォン（図示せず））、視覚出力装置（たとえば、陰極線管（CRT）画面、液晶ディスプレイ（LCD）画面、プラズマスクリーン、有機発光ダイオード（OLED）画面を含む画面910；それぞれはタッチスクリーン入力機能があってもなくてもよく、それぞれは触覚フィードバック機能があってもなくてもよく、そのうちのいくつかは、2次元の視覚出力または立体視出力のような手段を通じた3次元より高い出力を出力することができてもよい；仮想現実感眼鏡（図示せず）、ホログラフィーディスプレイおよび煙タンク（図示せず））、およびプリンタ（図示せず）を含んでいてもよい。

コンピュータ・システム900はまた、人間がアクセス可能な記憶装置および関連する媒体、たとえば、CD/DVDまたは類似の媒体921とともにCD/DVD ROM/RW 920を含む光学式媒体、サムドライブ922、取り外し可能なハードドライブまたはソリッドステートドライブ923、テープおよびフロッピーディスクといったレガシー磁気媒体（図示せず）、セキュリティ・ドングルのような特化したROM/ASIC/PLDベースの装置（図示せず）などを含むことができる。

当業者はまた、現在開示されている主題に関連して使用される用語「コンピュータ読み取り可能な媒体」は、伝送媒体、搬送波、または他の一時的な信号を包含しないことを理解すべきである。

コンピュータ・システム900はまた、一つまたは複数の通信ネットワーク（955）へのインターフェースを含むことができる。ネットワークは、たとえば、無線、有線、光学式でありうる。ネットワークは、さらに、ローカル、広域、都市圏、車載および工業用、リアルタイム、遅延耐性などでありうる。ネットワークの例は、イーサネット〔登録商標〕、無線LAN、グローバル移動通信システム（GSM）、第三世代（3G）、第四世代（4G）、第五世代（5G）、ロングタームエボリューション（LTE）などを含むセルラー・ネットワーク、ケーブルテレビ、衛星テレビ、地上放送テレビを含むTV有線または無線の広域デジタルネットワーク、CANBusを含む車載および工業用などを含む。ある種のネットワークは、普通、ある種の汎用データ・ポートまたは周辺バス（949）（たとえば、コンピュータ・システム900のユニバーサルシリアルバス（USB）ポートなど）に取り付けられる外部ネットワーク・インターフェース・アダプター（954）を必要とする。他は、普通、後述するようなシステム・バスへの取り付けによって、コンピュータ・システム900のコアに統合される（たとえば、PCコンピュータ・システムへのイーサネット・インターフェースまたはスマートフォン・コンピュータ・システムへのセルラー・ネットワーク・インターフェース）。これらのネットワークのいずれかを使用して、コンピュータ・システム900は、他のエンティティと通信することができる。そのような通信は、一方向性、受信のみ（たとえば、放送テレビ）、一方向性送信専用（たとえば、ある種のCANbus装置へのCANbus）、または、たとえば、ローカルまたは広域デジタルネットワークを使用する他のコンピュータ・システムへの双方向性であってもよい。上述のようなそれらのネットワークおよびネットワークインターフェース（1154）のそれぞれで、ある種のプロトコルおよびプロトコルスタックが使用できる。

前述のヒューマン・インターフェース装置、人間がアクセス可能な記憶装置、およびネットワーク・インターフェースは、コンピュータ・システム900のコア940に取り付けることができる。

コア940は、一つまたは複数の中央処理装置（CPU）941、グラフィックス処理装置（GPU）942、フィールドプログラマブルゲートアレイ（FPGA）943の形の特化したプログラマブル処理装置、ある種のタスクのためのハードウェアアクセラレータ944などを含むことができる。これらの装置は、読み出し専用メモリ（ROM）945、ランダムアクセスメモリ（RAM）946、内部のユーザー・アクセス可能でないハードドライブ、ソリッドステートデバイス（SSD）などの内蔵大容量記憶装置など947とともに、システム・バス948を通じて接続されうる。いくつかのコンピュータ・システムでは、追加のCPU、GPUなどによる拡張を可能にするために、システム・バス948は、一つまたは複数の物理プラグの形でアクセス可能であってもよい。周辺装置は、コアのシステム・バス948に直接取り付けられることも、周辺バス949を通じて取り付けられることもできる。周辺バスのためのアーキテクチャーは、周辺コンポーネント相互接続（PCI）、USBなどを含む。

CPU 941、GPU 942、FPGA 943、およびアクセラレータ944は、組み合わせて上述のコンピュータコードを構成することができるある種の命令を、実行することができる。そのコンピュータコードは、ROM 945またはRAM 946に記憶できる。一時的データも、RAM 946に記憶されることができ、一方、持続的データは、たとえば、内部大容量記憶装置947に記憶されることができる。一つまたは複数のCPU 941、GPU 942、大容量記憶装置947、ROM 945、RAM 946などと密接に関連付けることができるキャッシュメモリを使用することを通じて、メモリデバイスのいずれかへの高速な記憶および取り出しを可能にすることができる。

コンピュータ読み取り可能な媒体は、さまざまなコンピュータ実装された動作を実行するためのコンピュータコードをその上に有することができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築されたものであってもよく、または、コンピュータ・ソフトウェア分野の技術を有する者に周知であり利用可能な種類のものであってもよい。

限定ではなく一例として、アーキテクチャー900、具体的にはコア940を有するコンピュータ・システムは、プロセッサ（CPU、GPU、FPGA、アクセラレータ等を含む）が一つまたは複数の有形のコンピュータ可読媒体に具現化されたソフトウェアを実行することの結果として、機能性を提供することができる。そのようなコンピュータ読み取り可能媒体は、上記で紹介したようなユーザー・アクセス可能な大容量記憶ならびにコア内部の大容量記憶装置947またはROM 945のような非一時的な性質のコア940のある種の記憶に関連する媒体であることができる。本開示のさまざまな実施形態を実装するソフトウェアは、そのような装置に記憶され、コア940によって実行されることができる。コンピュータ読み取り可能媒体は、特定のニーズに応じて、一つまたは複数のメモリデバイスまたはチップを含むことができる。ソフトウェアは、RAM 946に記憶されたデータ構造を定義し、ソフトウェアによって定義されたプロセスに従ってそのようなデータ構造を修正することを含む、本明細書に記載された特定のプロセスまたは特定のプロセスの特定の部分を、コア940および具体的にはその中のプロセッサ（CPU、GPU、FPGAなどを含む）に実行させることができる。追加的または代替的に、コンピュータ・システムは、回路（たとえば、アクセラレータ944）内に配線された、または他の仕方で具現された論理の結果として機能性を提供することができ、これは、本明細書に記載される特定のプロセスまたは特定のプロセスの特定の部分を実行するためのソフトウェアの代わりに、またはそれと一緒に動作することができる。ソフトウェアへの言及は、論理を含み、適宜その逆も可能である。コンピュータ読み取り可能媒体への言及は、適宜、実行のためのソフトウェアを記憶する回路（たとえば集積回路（IC））、実行のための論理を具現する回路、またはその両方を包含することができる。本開示は、ハードウェアおよびソフトウェアの任意の好適な組み合わせを包含する。

本開示は、いくつかの例示的実施形態を記載してきたが、変更、置換、およびさまざまな代替等価物があり、それらは本開示の範囲内にはいる。よって、当業者は、本明細書に明示的に示されていないかまたは記載されていないが、本開示の原理を具現し、よって、本開示の精神および範囲内にある多くのシステムおよび方法を考案することができることが理解されるであろう。

Claims (1)

1. 少なくとも1つのプロセッサによって、エンコードされたビデオ・ビットストリームを生成する方法であって：
   現在のピクチャーの現在の層が独立層であるかどうかに関する第1の決定を行う段階と；
   現在の層について参照ピクチャー再サンプリングが有効にされているかどうかに関する第2の決定を行う段階と；
   第1の決定および第2の決定に基づいて、現在の層についてラップアラウンド補償を無効にする段階と；
   前記第1の決定が現在の層が独立層でないことを示し、前記第2の決定が現在の層について前記参照ピクチャー再サンプリングが有効にされていることを示すことに基づいて、現在のピクチャーの幅が現在の参照ピクチャーの幅と異なるかどうかに関する第3の決定を行い、前記第3の決定が、現在のピクチャーの幅が現在の参照ピクチャーの幅と異なることを示すことに基づいて、前記ラップアラウンド補償を無効にする段階と；
   ラップアラウンド補償なしで現在の層をエンコードする段階とを含む、
   方法。