特開2024-74922ビデオコーディングのための方法、装置及びコンピュータプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024074922
(43)【公開日】2024-05-31
(54)【発明の名称】ビデオコーディングのための方法、装置及びコンピュータプログラム
(51)【国際特許分類】
H04N 19/70 20140101AFI20240524BHJP
H04N 19/30 20140101ALI20240524BHJP
【ＦＩ】
H04N19/70
H04N19/30
【審査請求】有
【請求項の数】1
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2024060576
(22)【出願日】2024-04-04
(62)【分割の表示】P 2021550030の分割
【原出願日】2020-09-22
(31)【優先権主張番号】62/904,338
(32)【優先日】2019-09-23
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】17/024,288
(32)【優先日】2020-09-17
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100150197
【弁理士】
【氏名又は名称】松尾 直樹
(72)【発明者】
【氏名】ビョンドゥ・チェ
(72)【発明者】
【氏名】ステファン・ヴェンガー
(72)【発明者】
【氏名】シャン・リュウ
(57)【要約】
【課題】ビデオコーディングのための方法、装置及びコンピュータプログラムを提供する。
【解決手段】1つまたは複数のプロセッサに、ビデオデータを取得するステップと、ビデオデータのビデオパラメータセット（VPS）シンタックスをパーシングするステップと、VPSシンタックスのシンタックス要素の値が、ビデオデータのアクセスユニット（AU）の画像順序カウント（POC）値を示すかどうかを判定するステップと、シンタックス要素の値に基づいて、ビデオデータの複数の画像、スライス、およびタイルのうちの少なくとも1つをAUに設定するステップと、を実行させるように構成されたコンピュータコードを含む方法および装置が含まれる。
【選択図】図１０
【解決手段】1つまたは複数のプロセッサに、ビデオデータを取得するステップと、ビデオデータのビデオパラメータセット（VPS）シンタックスをパーシングするステップと、VPSシンタックスのシンタックス要素の値が、ビデオデータのアクセスユニット（AU）の画像順序カウント（POC）値を示すかどうかを判定するステップと、シンタックス要素の値に基づいて、ビデオデータの複数の画像、スライス、およびタイルのうちの少なくとも1つをAUに設定するステップと、を実行させるように構成されたコンピュータコードを含む方法および装置が含まれる。
【選択図】図１０
【特許請求の範囲】
【請求項1】
少なくとも1つのプロセッサによって実行されるビデオコーディングのための方法であって、前記方法は、
ビデオデータを取得するステップと、
前記ビデオデータのビデオパラメータセット（VPS）シンタックスをパーシングするステップと、
前記VPSシンタックスのシンタックス要素の値が、前記ビデオデータのアクセスユニット（AU）の画像順序カウント（POC）値を示すかどうかを判定するステップと、
前記シンタックス要素の前記値に基づいて、前記ビデオデータの複数の画像、スライス、およびタイルのうちの少なくとも1つを前記AUに設定するステップと、を含む、ビデオコーディングのための方法。
ビデオデータを取得するステップと、
前記ビデオデータのビデオパラメータセット（VPS）シンタックスをパーシングするステップと、
前記VPSシンタックスのシンタックス要素の値が、前記ビデオデータのアクセスユニット（AU）の画像順序カウント（POC）値を示すかどうかを判定するステップと、
前記シンタックス要素の前記値に基づいて、前記ビデオデータの複数の画像、スライス、およびタイルのうちの少なくとも1つを前記AUに設定するステップと、を含む、ビデオコーディングのための方法。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本願は、2019年9月23日に出願された米国仮特許出願第62／904，338号および2020年9月17日に出願された米国特許出願第17／024，288号の優先権を主張し、その全体が本明細書に組み込まれる。
本願は、2019年9月23日に出願された米国仮特許出願第62／904，338号および2020年9月17日に出願された米国特許出願第17／024，288号の優先権を主張し、その全体が本明細書に組み込まれる。
【0002】
開示される主題は、ビデオコーディングおよびデコーディングに関し、より具体的には、サブ画像分割による時間的／空間的スケーラビリティのサポートのためのプロファイル／階層／レベル情報のシグナリングに関する。
【背景技術】
【0003】
動き補償による画像間予測を使用したビデオのコーディングとデコーディングは、何十年も前から知られている。非圧縮デジタルビデオは、一連の画像で構成することができ、各画像は、例えば1920×1080の輝度サンプルおよび関連するクロミナンスサンプルの空間次元を有する。一連の画像は、例えば毎秒60画像または60Hzの固定または可変の画像レート（非公式にはフレームレートとも呼ばれる）を有することができる。非圧縮ビデオは重要なビットレート要件を有する。例えば、サンプルあたり8ビットの1080p60 4：2：0ビデオ（60 Hzフレームレートでの1920×1080輝度サンプル解像度）は、1．5 Gbit／sに近い帯域幅を必要とする。このようなビデオを1時間使用するには、600 GByteを超える記憶スペースが必要である。
【0004】
ビデオのコーディングとデコーディングの1つの目的は、圧縮によって入力ビデオ信号の冗長性を減らすことであり得る。圧縮は、前述の帯域幅または記憶スペースの要件を、場合によっては2桁以上削減するのに役立ち得る。可逆圧縮と非可逆圧縮の両方、およびそれらの組み合わせが使用されてもよい。可逆圧縮とは、圧縮された元の信号から元の信号の正確なコピーを再構築できる手法を指す。非可逆圧縮を使用すると、再構築された信号は元の信号と同一ではない可能性があるが、元の信号と再構築された信号の間の歪みが十分に小さいので、再構築された信号は目的の用途に有用である。ビデオの場合、非可逆圧縮が広く採用されている。許容される歪みの量は用途によって異なり、例えば、特定のコンシューマストリーミング用途のユーザは、テレビ寄与用途のユーザよりも高い歪みを許容することができる。達成可能な圧縮率は、許容可能な／耐えられる歪みが高いほど、より高い圧縮率が得られるということを反映できる。
【0005】
ビデオエンコーダとデコーダは、例えば動き補償、変換、量子化、エントロピーコーディングなど、いくつかの幅広いカテゴリからの技術を利用することができ、これらのいくつかは以下で導入される。
【0006】
歴史的に、ビデオエンコーダおよびデコーダは、ほとんどの場合、コーディング済ビデオシーケンス（CVS）、画像グループ（GOP）、または同様のマルチ画像タイムフレームに対して定義されて一定のままであった所与の画像サイズで動作する傾向があった。例えば、MPEG－2では、システム設計は、I画像においてのみであるが、シーンのアクティビティなどの要因に応じて水平解像度（それによって、画像サイズ）を変更することが公知であり、したがって通常はGOP用である。CVS内の異なる解像度を使用するための参照画像の再サンプリングは、例えばITU－T Rec．H．263 Annex Pで公知である。しかしながら、ここでは画像サイズは変化せず、参照画像のみが再サンプリングされ、画像キャンバスの一部のみが使用される（ダウンサンプリングの場合）、またはシーンの一部のみがキャプチャされる（アップサンプリングの場合）可能性がある。さらに、H．263 Annex Qは、個々のマクロブロックを上方または下方に（各次元で）2倍だけ再サンプリングすることを可能にする。ここでも、画像サイズは同じままである。マクロブロックのサイズはH．263では固定されているため、シグナリングする必要はない。
【0007】
予測画像の画像サイズの変更は、最新のビデオコーディングにおいてより主流になった。例えば、VP9は、参照画像の再サンプリングおよび画像全体の解像度の変更を可能にする。同様に、VVCに向けてなされた特定の提案（例えば、Hendry，et．al，“On adaptive resolution change（ARC）for VVC”，Joint Video Team document JVET－M0135－v1，Jan 9－19，2019が含まれ、その全体は本明細書に組み込まれる）は、異なる－より高いまたはより低い－解像度への参照画像全体の再サンプリングを可能にする。その文書では、シーケンスパラメータセット内でコーディングされ、画像パラメータセット内の画像ごとのシンタックス要素によって参照される異なる候補解像度が提案されている。
【発明の概要】
【課題を解決するための手段】
【0008】
コンピュータプログラムコードを記憶するように構成されたメモリと、コンピュータプログラムコードにアクセスし、コンピュータプログラムコードによって命令されるように動作するように構成された1つまたは複数のプロセッサと、を含む方法および装置が含まれる。コンピュータプログラムコードは、少なくとも1つのプロセッサにビデオデータを取得させるように構成された、取得するコードと、少なくとも1つのプロセッサに、ビデオデータのビデオパラメータセット（VPS）シンタックスをパーシングさせるように構成された、パーシングするコードと、少なくとも1つのプロセッサに、VPSシンタックスのシンタックス要素の値が、ビデオデータのアクセスユニット（AU）の画像順序カウント（POC）値を示すかどうかを判定させるように構成された、判定するコードと、少なくとも1つのプロセッサに、シンタックス要素の値に基づいて、ビデオデータの複数の画像、スライス、およびタイルのうちの少なくとも1つをAUに設定させるように構成された、設定するコードと、を含む。
【0009】
例示的な実施形態によれば、シンタックス要素の値は、AUに設定されるビデオデータの複数の画像、スライス、およびタイルのうちの連続する番号を示す。
【0010】
例示的な実施形態によれば、ビデオデータのVPSにVPSシンタックスが含まれ、ビデオデータの少なくとも1つのタイプのエンハンスメントレイヤの数を識別する。
【0011】
例示的な実施形態によれば、判定するコードは、少なくとも1つのプロセッサに、VPSシンタックスが、POC値がAUごとに均一に増加するかどうかを示すフラグを含むかどうか判定させるようにさらに構成される。
【0012】
例示的な実施形態によれば、VPSがフラグを含み、フラグが、POC値がAUごとに均一に増加しないことを示すとの判定に応答して、少なくとも1つのプロセッサに、ビデオデータのPOC値および画像レベル値からのアクセスユニットカウント（AUC）を計算させるように構成された、計算するコードがさらに存在する。
【0013】
例示的な実施形態によれば、VPSがフラグを含み、フラグが、POC値がAUごとに均一に増加することを示すとの判定に応答して、少なくとも1つのプロセッサに、ビデオデータのPOC値およびシーケンスレベル値からのアクセスユニットカウント（AUC）を計算させるように構成された、計算するコードがさらに存在する。
【0014】
例示的な実施形態によれば、判定するコードは、少なくとも1つのプロセッサに、VPSシンタックスが、画像のうちの少なくとも1つが複数のサブ領域に分割されているかどうかを示すフラグを含むかどうかを判定させるようにさらに構成される。
【0015】
例示的な実施形態によれば、設定するコードは、VPSシンタックスがフラグを含み、フラグが、画像のうちの少なくとも1つが複数のサブ領域に分割されていないことを示すとの判定に応答して、少なくとも1つのプロセッサに、画像のうちの少なくとも1つの入力画像サイズを、ビデオデータのシーケンスパラメータセット（SPS）においてシグナリングされたコーディング済画像サイズに設定させるようにさらに構成される。
【0016】
例示的な実施形態によれば、判定するコードは、VPSシンタックスがフラグを含み、フラグが画像のうちの少なくとも1つが複数のサブ領域に分割されていることを示すとの判定に応答して、少なくとも1つのプロセッサに、SPSがビデオデータのレイヤに対応するオフセットをシグナリングするシンタックス要素を含むかどうかを判定させるようにさらに構成される。
【0017】
例示的な実施形態によれば、オフセットは、幅方向のオフセットおよび高さ方向のオフセットを含む。
【0018】
開示される主題のさらなる特徴、性質、および様々な利点は、以下の詳細な説明および添付の図面からより明らかになるであろう。
【図面の簡単な説明】
【0019】
【図1】実施形態による通信システムの簡略化されたブロック図の概略図である。
【図2】実施形態による通信システムの簡略化されたブロック図の概略図である。
【図3】実施形態によるデコーダの簡略化されたブロック図の概略図である。
【図4】実施形態によるエンコーダの簡略化されたブロック図の概略図である。
【図5A】関連技術によるARCパラメータをシグナリングするためのオプションの概略図である。
【図5B】関連技術によるARCパラメータをシグナリングするためのオプションの概略図である。
【図5C】実施形態によるARCパラメータをシグナリングするためのオプションの概略図である。
【図5D】実施形態によるARCパラメータをシグナリングするためのオプションの概略図である。
【図5E】実施形態によるARCパラメータをシグナリングするためのオプションの概略図である。
【図6】実施形態によるシンタックステーブルの一例を示す図である。
【図7】実施形態によるコンピュータシステムの概略図である。
【図8】適応的解像度変更を伴うスケーラビリティのための予測構造の一例を示す図である。
【図9】実施形態によるシンタックステーブルの一例を示す図である。
【図10】実施形態による、アクセスユニット当たりのpocサイクルおよびアクセスユニットカウント値をパーシングおよびデコードする簡略ブロック図の概略図である。
【図11】実施形態による、マルチレイヤサブ画像を含むビデオビットストリーム構造の概略図である。
【図12】実施形態による、エンハンスされた解像度を有する選択されたサブ画像の表示の概略図である。
【図13】実施形態による、マルチレイヤサブ画像を含むビデオビットストリームのデコーディングおよび表示プロセスのブロック図である。
【図14】実施形態による、サブ画像のエンハンスメントレイヤを有する360ビデオ表示の概略図である。
【図15】実施形態による、サブ画像ならびにその対応するレイヤおよび画像予測構造のレイアウト情報の一例を示す図である。
【図16】実施形態による、局所領域の空間スケーラビリティ様式を有する、サブ画像ならびにその対応するレイヤおよび画像予測構造のレイアウト情報の一例を示す図である。
【図17】実施形態による、サブ画像レイアウト情報のためのシンタックステーブルの一例を示す図である。
【図18】実施形態による、サブ画像レイアウト情報のためのSEIメッセージのシンタックステーブルの一例を示す図である。
【図19】実施形態による、出力レイヤおよび各出力レイヤセットのプロファイル／階層／レベル情報を示すシンタックステーブルの一例を示す図である。
【図20】実施形態による各出力レイヤセットの出力レイヤモードを示すシンタックステーブルの一例を示す図である。
【図21】実施形態による、各出力レイヤセットの各レイヤの現在のサブ画像を示すシンタックステーブルの一例を示す図である。
【発明を実施するための形態】
【0020】
以下で説明する提案された特徴は、別々に使用されてもよいし、任意の順序で組み合わされてもよい。さらに、実施形態は、処理回路（例えば、1つまたは複数のプロセッサまたは1つまたは複数の集積回路）によって実施されてもよい。一例では、1つまたは複数のプロセッサは、非一時的なコンピュータ可読媒体に格納されているプログラムを実行する。
【0021】
最近、複数のセマンティックに独立した画像部分の単一のビデオ画像への圧縮ドメインアグリゲーションまたは抽出が、いくらかの注目を集めている。特に、例えば、360個のコーディングまたは特定の監視アプリケーションのコンテキストでは、複数のセマンティックに独立したソース画像（例えば、立方体投影された360シーンの6つの立方体表面、またはマルチカメラ監視設定の場合の個々のカメラ入力）は、所与の時点における異なるシーンごとのアクティビティに対処するために別々の適応的解像度設定を必要とする場合がある。言い換えれば、エンコーダは、所与の時点において、360全体または監視シーンを構成する異なるセマンティックに独立した画像に対して異なる再サンプリング係数を使用することを選択することができる。単一の画像に結合されると、それは、コーディング済画像の部分に対して、参照画像の再サンプリングが実行され、適応的解像度コーディングシグナリングが利用可能であることを必要とする。
【0022】
図1は、本開示の一実施形態による通信システム（100）の簡略化されたブロック図を示す。システム（100）は、ネットワーク（150）を介して相互接続された少なくとも2つの端末（110、120）を含むことができる。データの一方向送信の場合、第1の端末（110）は、ネットワーク（150）を介して他の端末（120）に送信するためにローカル位置でビデオデータをコーディングすることができる。第2の端末（120）は、ネットワーク（150）から他の端末のコーディング済ビデオデータを受信し、コーディング済データをデコードし、回復されたビデオデータを表示することができる。一方向のデータ送信は、メディアサービングアプリケーションなどでは一般的であり得る。
【0023】
図1は、例えば、ビデオ会議中に発生する可能性があるコーディング済ビデオの双方向送信をサポートするために提供される第2の端末のペア（130、140）を示す。データの双方向送信の場合、各端末（130、140）は、ネットワーク（150）を介して他の端末に送信するためにローカル位置でキャプチャされたビデオデータをコーディングすることができる。各端末（130、140）はまた、他の端末によって送信されたコーディング済ビデオデータを受信することができ、コーディング済データをデコードすることができ、回復されたビデオデータをローカルディスプレイ装置に表示することができる。
【0024】
図1では、端末（110，120，130，140）は、サーバ、パーソナルコンピュータ、およびスマートフォンとして例示され得るが、本開示の原理はそのように限定されない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、および／または専用のビデオ会議機器での用途を見出す。ネットワーク（150）は、例えば有線および／または無線通信ネットワークを含む、端末（110，120，130，140）間でコーディング済ビデオデータを伝達する任意の数のネットワークを表す。通信ネットワーク（150）は、回路切り替えおよび／またはパケット切り替えチャネルでデータを交換することができる。代表的なネットワークは、通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワークおよび／またはインターネットを含む。本議論の目的のために、ネットワーク（150）のアーキテクチャおよびトポロジーは、以下で本明細書において説明されない限り、本開示の動作にとって重要ではない場合がある。
【0025】
図2は、開示された主題に対する用途の例として、ストリーミング環境におけるビデオエンコーダおよびデコーダの配置を示す。開示された主題は、例えば、ビデオ会議、デジタルTV、CD、DVD、メモリスティックなどを含むデジタルメディアへの圧縮ビデオの格納などを含む他のビデオ対応アプリケーションに等しく適用可能であり得る。
【0026】
ストリーミングシステムは、例えば非圧縮ビデオサンプルストリーム（202）を作成する、例えばデジタルカメラなどのビデオソース（201）を含むことができるキャプチャサブシステム（213）を含むことができる。エンコード済ビデオビットストリームと比較して高いデータボリュームを強調するために太線で示されているサンプルストリーム（202）は、カメラ（201）に接続されたエンコーダ（203）で処理され得る。エンコーダ（203）は、以下でより詳細に説明するように、開示された主題の態様を可能にするまたは実施するために、ハードウェア、ソフトウェア、またはそれらの組み合わせを含むことができる。サンプルストリームと比較してデータ量が少ないことを強調するために細い線で示されている、エンコード済ビデオビットストリーム（204）は、将来使用するためにストリーミングサーバ（205）に格納され得る。1つまたは複数のストリーミングクライアント（206、208）は、ストリーミングサーバ（205）にアクセスして、エンコード済ビデオビットストリーム（204）のコピー（207、209）を取得することができる。クライアント（206）は、エンコード済ビデオビットストリーム（207）の着信コピーをデコードし、ディスプレイ（212）または他のレンダリングデバイス（図示せず）にレンダリングされ得る発信ビデオサンプルストリーム（211）を作成するビデオデコーダ（210）を含むことができる。いくつかのストリーミングシステムでは、ビデオビットストリーム（204、207、209）は、特定のビデオコーディング／圧縮標準規格に従ってエンコードされ得る。これらの標準規格の例は、ITU－T勧告H．265を含む。開発中のビデオコーディング標準規格は、非公式に多用途ビデオコーディングまたはVVCとして知られている。開示された主題は、VVCのコンテキストで使用され得る。
【0027】
図3は、本開示の一実施形態によるビデオデコーダ（210）の機能ブロック図であり得る。
【0028】
受信機（310）は、デコーダ（210）によってデコードされる1つまたは複数のコーデックビデオシーケンスを受信することができ、同一または別の実施形態では、一度に1つのコーディング済ビデオシーケンスであり、各コーディング済ビデオシーケンスのデコーディングは、他のコーディング済ビデオシーケンスから独立している。コーディング済ビデオシーケンスは、チャネル（312）から受信することができ、チャネルは、エンコード済ビデオデータを格納する記憶装置へのハードウェア／ソフトウェアリンクであり得る。受信機（310）は、それぞれの使用エンティティ（図示せず）に転送され得る他のデータ、例えば、コーディング済オーディオデータおよび／または補助データストリームと共に、エンコード済ビデオデータを受信することができる。受信機（310）は、コーディング済ビデオシーケンスを他のデータから分離することができる。ネットワークジッタに対抗するために、バッファメモリ（315）は、受信機（310）とエントロピーデコーダ／パーサ（320）（以後「パーサ」）との間に結合され得る。受信機（310）が十分な帯域幅と制御性の格納／転送デバイスから、または等時性ネットワークからデータを受信している場合に、バッファ（315）は必要とされないか、または小さくなり得る。インターネットなどのベストエフォートパケットネットワークで使用するために、バッファ（315）が必要となる場合があり、比較的大きくすることができ、有利には適応サイズにすることができる。
【0029】
ビデオデコーダ（210）は、エントロピーコーディング済ビデオシーケンスからシンボル（321）を再構築するためのパーサ（320）を含むことができる。これらのシンボルのカテゴリには、デコーダ（210）の動作を管理するために使用される情報と、場合によっては、図2に示すように、これはデコーダの統合部分ではないがデコーダに結合され得るディスプレイ（212）などのレンダリングデバイスを制御するための情報と、が含まれる。レンダリングデバイスの制御情報は、補足エンハンスメント情報（SEIメッセージ）またはビデオユーザビリティ情報（VUI）パラメータセットフラグメント（図示せず）の形であってもよい。パーサ（320）は、受信したコーディング済ビデオシーケンスを解析／エントロピーデコードすることができる。コーディング済ビデオシーケンスのコーディングは、ビデオコーディング技術または標準規格に準拠することができ、可変長コーディング、ハフマンコーディング、コンテキスト依存の有無にかかわらず算術コーディングなどを含む、当業者に周知の原理に従うことができる。パーサ（320）は、グループに対応する少なくとも1つのパラメータに基づいて、ビデオデコーダ内のピクセルのサブグループのうちの少なくとも1つについて一組のサブグループパラメータを、コーディング済ビデオシーケンスから抽出することができる。サブグループは、画像のグループ（GOP）、画像、タイル、スライス、マクロブロック、コーディングユニット（CU）、ブロック、変換ユニット（TU）、予測ユニット（PU）などを含むことができる。エントロピーデコーダ／パーサは、変換係数、量子化器パラメータ値、動きベクトルなどのコーディング済ビデオシーケンス情報からも抽出することができる。
【0030】
パーサ（320）は、バッファ（315）から受信されたビデオシーケンスに対してエントロピーデコーディング／パーシング動作を実行して、シンボル（321）を作成することができる。
【0031】
シンボル（321）の再構築は、コーディング済ビデオ画像またはその一部（インター画像およびイントラ画像、インターブロックおよびイントラブロックなど）のタイプ、およびその他の要因に応じて、多数の異なるユニットを含むことができる。どのユニットが含まれているか、およびどのように含まれているかは、パーサ（320）によってコーディング済ビデオシーケンスから解析されたサブグループ制御情報によって制御され得る。パーサ（320）と以下の多数のユニットとの間のそのようなサブグループ制御情報の流れは、明確にするために示されていない。
【0032】
既に述べた機能ブロックの他に、デコーダ210は、以下に説明するように、概念的にいくつかの機能ユニットに細分することができる。商業的な制約の下で動作する実際の実施態様では、これらのユニットの多くは互いに密接に相互作用し、少なくとも部分的には、互いに統合され得る。しかしながら、開示された主題を説明するために、以下の機能ユニットへの概念的な細分が適切である。
【0033】
第1のユニットは、スケーラ／逆変換ユニット（351）である。スケーラ／逆変換ユニット（351）は、量子化された変換係数、ならびに使用する変換、ブロックサイズ、量子化係数、量子化スケーリング行列などを含む制御情報を、パーサ（320）からシンボル（321）として受け取る。それは、アグリゲータ（355）に入力され得るサンプル値を含むブロックを出力することができる。
【0034】
場合によっては、スケーラ／逆変換（351）の出力サンプルは、イントラコーディング済ブロック、すなわち、以前に再構築された画像からの予測情報を使用していないが、現在の画像の以前に再構築された部分からの予測情報を使用できるブロックに関係することができる。そのような予測情報は、イントラ画像予測ユニット（352）によって提供され得る。場合によっては、イントラ画像予測ユニット（352）は、現在の（部分的に再構築された）画像（356）からフェッチされた周囲の既に再構築された情報を使用して、再構築中のブロックと同じサイズおよび形状のブロックを生成する。アグリゲータ（355）は、場合によっては、サンプルごとに、イントラ予測ユニット（352）が生成した予測情報を、スケーラ／逆変換ユニット（351）によって提供された出力サンプル情報に追加する。
【0035】
他の場合では、スケーラ／逆変換ユニット（351）の出力サンプルは、インターコーディング済の、場合によっては動き補償されたブロックに関係することができる。このような場合、動き補償予測ユニット（353）は、参照画像メモリ（357）にアクセスして、予測に使用されるサンプルをフェッチすることができる。フェッチされたサンプルをブロックに関係するシンボル（321）に従って動き補償した後に、これらのサンプルは、アグリゲータ（355）によってスケーラ／逆変換ユニット（この場合、残差サンプルまたは残差信号と呼ばれる）の出力に追加されて、出力サンプル情報を生成することができる。動き補償ユニットが予測サンプルをフェッチする参照画像メモリ形式内のアドレスは、動きベクトルによって制御でき、例えばX、Y、および参照画像の成分を有することができるシンボル（321）の形式で動き補償ユニットが利用することができる。動き補償は、サブサンプルの正確な動きベクトルが使用されているときに参照画像メモリからフェッチされたサンプル値の補間、動きベクトル予測機構なども含むことができる。
【0036】
アグリゲータ（355）の出力サンプルは、ループフィルタユニット（356）における様々なループフィルタリング技術の対象となり得る。ビデオ圧縮技術は、コーディング済ビデオビットストリームに含まれるパラメータによって制御され、パーサ（320）からのシンボル（321）としてループフィルタユニット（356）に提供されるループ内フィルタ技術を含むことができるが、コーディング済画像またはコーディング済ビデオシーケンスの以前の（デコード順で）部分のデコード中に取得されたメタ情報に応答し、および以前に再構築されループフィルタ処理されたサンプル値に応答することもできる。
【0037】
ループフィルタユニット（356）の出力は、レンダリングデバイス（212）に出力することができて、将来の画像間予測で使用するために参照画像メモリ（356）に格納することができるサンプルストリームとすることができる。
【0038】
特定のコーディング済画像は、完全に再構築されると、将来の予測のための参照画像として使用することができる。コーディング済画像が完全に再構築され、コーディング済画像が（例えば、パーサ（320）によって）参照画像として識別されると、現在の参照画像（356）は、参照画像バッファ（357）の一部となることができ、そして、次のコーディング済画像の再構築を開始する前に、新しい現在の画像メモリを再割り当てすることができる。
【0039】
ビデオデコーダ320は、ITU－T Rec．H．265などの標準規格で文書化され得る所定のビデオ圧縮技術に従ってデコーディング動作を実行することができる。コーディング済ビデオシーケンスは、ビデオ圧縮技術文書または標準規格、特にその中のプロファイル文書で指定されているビデオ圧縮技術または標準規格のシンタックスを厳守しているという意味で、使用されているビデオ圧縮技術または標準規格で指定されたシンタックスに準拠することができる。また、コーディング済ビデオシーケンスの複雑さが、ビデオ圧縮技術または標準規格のレベルで定義されている範囲内にあることも、コンプライアンスに必要である。場合によっては、レベルによって、最大画像サイズ、最大フレームレート、最大再構築サンプルレート（例えば、メガサンプル／秒で測定される）、最大参照画像サイズなどが制限される。レベルによって設定された制限は、場合によっては、仮想参照デコーダ（HRD）の仕様と、コーディング済ビデオシーケンスで通知されるHRDバッファ管理のためのメタデータによってさらに制限され得る。
【0040】
一実施形態では、受信機（310）は、エンコード済ビデオと共に追加の（冗長な）データを受信することができる。追加のデータは、コーディング済ビデオシーケンスの一部として含まれてもよい。追加のデータは、データを適切にデコードし、かつ／または元のビデオデータをより正確に再構築するためにビデオデコーダ（320）によって使用され得る。追加のデータは、例えば、時間的、空間的、またはSNR（信号対雑音／品質スケーラビリティ）エンハンスメントレイヤ、冗長スライス、冗長画像、前方誤り訂正符号などの形式にすることができる。
【0041】
図4は、本開示の一実施形態によるビデオエンコーダ（203）の機能ブロック図であり得る。
【0042】
エンコーダ（203）は、エンコーダ（203）によってコーディングされるビデオ画像をキャプチャすることができる（エンコーダの一部ではない）ビデオソース（201）からビデオサンプルを受信することができる。
【0043】
ビデオソース（201）は、任意の適切なビット深度（例えば、8ビット、10ビット、12ビット、…）、任意の色空間（例えば、BT．601 Y CrCB、RGB、…）、および任意の適切なサンプリング構造（例えば、Y CrCb 4：2：0、Y CrCb 4：4：4）であり得るデジタルビデオサンプルストリームの形式でエンコーダ（203）によってコーディングされるソースビデオシーケンスを提供することができる。メディアサービングシステムでは、ビデオソース（201）は、以前に準備されたビデオを格納する記憶装置であってもよい。ビデオ会議システムでは、ビデオソース（203）は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラであってもよい。ビデオデータは、順番に見たときに動きを与える複数の個別の画像として提供されてもよい。画像自体は、ピクセルの空間アレイとして編成することができ、各ピクセルは、使用中のサンプリング構造、色空間などに応じて、1つまたは複数のサンプルを含むことができる。当業者は、ピクセルとサンプルとの間の関係を容易に理解することができる。以下の説明では、サンプルを中心に説明する。
【0044】
一実施形態によれば、エンコーダ（203）は、用途により必要に応じて、リアルタイムで、または任意の他の時間制約の下で、ソースビデオシーケンスの画像をコーディングし、コーディング済ビデオシーケンス（443）に圧縮することができる。適切なコーディング速度を強制することは、コントローラ（450）の機能の1つである。コントローラは、以下に説明するように他の機能ユニットを制御し、これらのユニットに機能的に結合されている。明確にするために、結合は描かれていない。コントローラによって設定されるパラメータは、レート制御に関連するパラメータ（画像スキップ、量子化器、レート歪み最適化手法のラムダ値など）、画像サイズ、画像のグループ（GOP）レイアウト、最大動きベクトル検索範囲などを含むことができる。当業者は、コントローラ（450）の他の機能が、特定のシステム設計に最適化されたビデオエンコーダ（203）に関係することができるので、それらを容易に識別することができる。
【0045】
一部のビデオエンコーダは、当業者が「コーディングループ」として容易に認識するもので動作する。過度に簡略化した説明として、コーディングループは、エンコーダ（430）（以降「ソースコーダ」）（コーディングされる入力画像と参照画像に基づいてシンボルを作成する役割を果たす）のエンコーディング部分、およびシンボルを再構築して（リモート）デコーダも作成するであろうサンプルデータを作成するエンコーダ（203）に組み込まれた（ローカル）デコーダ（433）で構成され得る（シンボルとコーディング済ビデオビットストリームとの間の任意の圧縮は、開示された主題で考慮されているビデオ圧縮技術では無損失であるため）。その再構築されたサンプルストリームは、参照画像メモリ（434）に入力される。シンボルストリームのデコーディングにより、デコーダの場所（ローカルまたはリモート）に関係なくビットが正確な結果が得られるので、参照画像バッファの内容もローカルエンコーダとリモートエンコーダとの間でビットが正確である。言い換えると、エンコーダの予測部分は、デコード中に予測を使用する場合にデコーダが「見る」であろうものとまったく同じサンプル値を参照画像サンプルとして「見る」。参照画像同期性のこの基本原理（および、例えばチャネルエラーのために同期性が維持できない場合に生じるドリフト）は、当業者によく知られている。
【0046】
「ローカル」デコーダ（433）の動作は、「リモート」デコーダ（210）の動作と同じにすることができ、これは、図3に関連して上で既に詳細に説明されている。しかしながら、図3も簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ（445）およびパーサ（320）によるコーディング済ビデオシーケンスへのシンボルのエンコーディング／デコーディングは無損失であり得るので、チャネル（312）、受信機（310）、バッファ（315）、およびパーサ（320）を含むデコーダ（210）のエントロピーデコーディング部分は、ローカルデコーダ（433）で完全に実施されなくてもよい。
【0047】
この時点で行うことができる観察は、デコーダに存在するパーシング／エントロピーデコーディング以外の任意のデコーダ技術も、対応するエンコーダに実質的に同一の機能形式で必ず存在している必要があるということである。このため、開示された主題はデコーダ動作に焦点を合わせている。エンコーダ技術の説明は、包括的に説明されたデコーダ技術の逆であるから、省略することができる。特定の領域でのみ、より詳細な説明が必要であり、以下に提供される。
【0048】
その動作の一部として、ソースコーダ（430）は、動き補償予測コーディングを実行することができ、それは、「参照フレーム」として指定されたビデオシーケンスからの1つまたは複数の以前にコーディング済フレームを参照して入力フレームを予測的にコーディングする。このようにして、コーディングエンジン（432）は、入力フレームのピクセルブロックと、入力フレームに対する予測参照として選択され得る参照フレームのピクセルブロックとの間の差をコーディングする。
【0049】
ローカルビデオデコーダ（433）は、ソースコーダ（430）によって作成されたシンボルに基づいて、参照フレームとして指定され得るフレームのコーディング済ビデオデータをデコードすることができる。コーディングエンジン（432）の動作は、有利には、損失のあるプロセスであってもよい。コーディング済ビデオデータがビデオデコーダ（図4には示されていない）でデコードされ得る場合、再構築されたビデオシーケンスは、通常、いくつかの誤差を伴うソースビデオシーケンスのレプリカであり得る。ローカルビデオデコーダ（433）は、参照フレームに対してビデオデコーダによって実行され得るデコーディングプロセスを複製し、再構築された参照フレームを参照画像キャッシュ（434）に格納させることができる。このようにして、エンコーダ（203）は、遠端ビデオデコーダによって得られる（送信エラーがない）再構築参照フレームとして共通のコンテンツを有する再構築参照フレームのコピーをローカルに格納することができる。
【0050】
予測器（435）は、コーディングエンジン（432）の予測検索を実行することができる。すなわち、コーディングされる新しいフレームについて、予測器（435）は、（候補参照ピクセルブロックとしての）サンプルデータまたは参照画像の動きベクトル、ブロック形状などの特定のメタデータについて参照画像メモリ（434）を検索することができ、それは新しい画像の適切な予測参照として機能することができる。予測器（435）は、適切な予測参照を見つけるために、サンプルブロックバイピクセルブロックに基づいて動作することができる。場合によっては、予測器（435）によって得られた検索結果によって決定されるように、入力画像は、参照画像メモリ（434）に格納された多数の参照画像から引き出された予測参照を有してもよい。
【0051】
コントローラ（450）は、例えば、ビデオデータをコーディングするために使用されるパラメータおよびサブグループパラメータの設定を含む、ビデオコーダ（430）のコーディング動作を管理することができる。
【0052】
前述のすべての機能ユニットの出力は、エントロピーコーダ（445）でエントロピーコーディングを受けることができる。エントロピーコーダは、例えばハフマンコーディング、可変長コーディング、算術コーディングなどの当業者に知られている技術に従ってシンボルを無損失圧縮することにより、様々な機能ユニットによって生成されたシンボルをコーディング済ビデオシーケンスに変換する。
【0053】
送信機（440）は、エントロピーコーダ（445）によって作成されたコーディング済ビデオシーケンスをバッファリングして、通信チャネル（460）を介して送信の準備をすることができ、通信チャネル（460）は、エンコード済ビデオデータを格納するであろう記憶装置へのハードウェア／ソフトウェアリンクであり得る。送信機（440）は、ビデオコーダ（430）からのコーディング済ビデオデータを、送信される他のデータ、例えばコーディング済オーディオデータおよび／または補助データストリーム（ソースは図示せず）とマージすることができる。
【0054】
コントローラ（450）は、エンコーダ（203）の動作を管理することができる。コーディング中に、コントローラ（450）は、各コーディング済画像に特定のコーディング済画像タイプを割り当てることができ、これは、それぞれの画像に適用され得るコーディング技法に影響を及ぼすことができる。例えば、多くの場合、画像は次のフレームタイプの1つとして割り当てられ得る。
【0055】
イントラ画像（I画像）は、シーケンス内のいかなる他のフレームも予測のソースとして使用せずにコーディングおよびデコードされ得るものであり得る。一部のビデオコーデックでは、例えば、独立なデコーダリフレッシュ画像など、様々なタイプのイントラ画像を使用できる。当業者は、I画像のそれらの変形およびそれらのそれぞれの用途および特徴を知っている。
【0056】
予測画像（P画像）は、各ブロックのサンプル値を予測するために最大で1つの動きベクトルおよび参照インデックスを使用するイントラ予測またはインター予測を使用してコーディングおよびデコードされ得るものであり得る。
【0057】
双方向予測画像（B画像）は、各ブロックのサンプル値を予測するために最大で2つの動きベクトルおよび参照インデックスを使用するイントラ予測またはインター予測を使用してコーディングおよびデコードされ得るものであり得る。同様に、多数の予測画像は、単一のブロックの再構築に3つ以上の参照画像と関連メタデータを使用することができる。
【0058】
ソース画像は、通常、空間的に複数のサンプルブロック（例えば、それぞれ4×4、8×8、4×8、または16×16サンプルのブロック）に分割され、ブロックごとにコーディングされる。ブロックは、ブロックのそれぞれの画像に適用されたコーディング割り当てによって決定されるように、他の（既にコーディング済）ブロックを参照して予測的にコーディングされ得る。例えば、I画像のブロックは非予測的にコーディングされてもよく、またはそれらは同じ画像の既にコーディング済ブロック（空間予測またはイントラ予測）を参照して予測的にコーディングされてもよい。P画像のピクセルブロックは、空間的予測を介して、または以前にコーディング済1つの参照画像を参照する時間的予測を介して、非予測的にコーディングされ得る。B画像のブロックは、空間的予測を介して、または以前にコーディング済1つまたは2つの参照画像を参照する時間的予測を介して、非予測的にコーディングされ得る。
【0059】
ビデオコーダ（203）は、ITU－T Rec．H．265などの所定のビデオコーディング技術または標準規格に従ってコーディング動作を実行することができる。その動作では、ビデオコーダ（203）は、様々な圧縮動作を実行することができ、それは入力ビデオシーケンスにおける時間的および空間的冗長性を活用する予測コーディング動作を含む。したがって、コーディング済ビデオデータは、使用されているビデオコーディング技術または標準規格で指定されたシンタックスに準拠することができる。
【0060】
一実施形態では、送信機（440）は、エンコード済ビデオと共に追加のデータを送信することができる。ビデオコーダ（430）は、コーディング済ビデオシーケンスの一部としてそのようなデータを含むことができる。追加のデータは、時間的／空間的／SNRエンハンスメントレイヤ、冗長な画像およびスライスなどの冗長データの他の形式、補足拡張情報（SEI）メッセージ、ビジュアルユーザビリティ情報（VUI）パラメータセットフラグメントなどを含むことができる。
【0061】
開示された主題の特定の態様をより詳細に説明する前に、この説明の残りの部分で参照されるいくつかの用語を導入する必要がある。
【0062】
以下、サブ画像は、セマンティックにグループ化され、変更された解像度で独立してコーディングされ得るサンプル、ブロック、マクロブロック、コーディングユニット、または同様のエンティティの、場合によっては、矩形配置を指す。1つの画像に対して1つまたは複数のサブ画像があり得る。1つまたは複数のコーディング済サブ画像は、コーディング済画像を形成することができる。1つまたは複数のサブ画像を画像にアセンブルすることができ、1つまたは複数のサブ画像を画像から抽出することができる。ある特定の環境では、1つまたは複数のコーディング済サブ画像は、サンプルレベルへのコーディング済画像へのトランスコーディングを行わずに、圧縮された領域においてアセンブルされ得る。そして、同一またはある特定の他のケースでは、1つまたは複数のコーディング済サブ画像が、圧縮された領域におけるコーディング済画像から抽出され得る。
【0063】
これ以降、適応的解像度変更（ARC）は、例えば、参照画像再サンプリングによって、コーディング済ビデオシーケンス内の画像またはサブ画像の解像度の変更を可能にする機構を指す。以降、ARCパラメータは、適応的解像度変更を実行するために必要とされる制御情報を指し、これは、例えば、フィルタパラメータ、スケーリング係数、出力画像および／または参照画像の解像度、様々な制御フラグなどを含むことができる。
【0064】
上記の説明は、単一のセマンティックに独立したコーディング済ビデオ画像のコーディングおよびデコーディングに焦点を当てている。独立したARCパラメータを有する複数のサブ画像のコーディング／デコーディングの含意およびその含意される追加の複雑さを説明する前に、ARCパラメータをシグナリングするためのオプションを説明するものとする。
【0065】
図5A～図5Eを参照すると、ARCパラメータをシグナリングするためのいくつかの新規なオプションが示されている。各オプションで述べたように、それらは、コーディング効率、複雑さ、およびアーキテクチャの観点から、特定の利点および特定の欠点を有する。ビデオコーディング標準規格または技術は、ARCパラメータをシグナリングするために、これらのオプション、または従来技術から知られているオプションのうちの1つまたは複数を選択することができる。オプションは、相互に排他的でなくてもよく、アプリケーションのニーズ、関連する標準技術、またはエンコーダの選択に基づいて交換されてもよいと考えられる。
【0066】
ARCパラメータのクラスは、以下を含むことができる。
－X次元およびY次元で分離または結合されたアップ／ダウンサンプル係数、
－時間次元を追加したアップ／ダウンサンプル係数であって、所与の数の画像に対する一定速度のズームイン／アウトを示す、アップ／ダウンサンプル係数、
－X次元およびY次元で分離または結合されたアップ／ダウンサンプル係数、
－時間次元を追加したアップ／ダウンサンプル係数であって、所与の数の画像に対する一定速度のズームイン／アウトを示す、アップ／ダウンサンプル係数、
【0067】
－上記の2つのうちのいずれかは、係数を含むテーブルを指すことができる1つまたは複数の推定的に短いシンタックス要素のコーディングを含んでもよい、
－サンプル、ブロック、マクロブロック、CU、またはその他の適切な粒度の単位で、組み合わされた、または個別の、入力画像、出力画像、参照画像、コーディング済画像のXまたはY次元の解像度（2つ以上の解像度がある場合（例えば、入力画像用に1つ、参照画像用に1つなど）には、場合によっては、一組の値が別の組の値から推測され得る。これは、例えば、フラグを使用することによってゲーティングすることができる。より詳細な例については、以下を参照されたい）。
－「ワーピング」座標は、H．263 Annex Pで使用されるものと同様に、上述したように適切な粒度である（H．263 Annex Pは、そのようなワーピング座標をコーディングする1つの効率的な方法を定義するが、他の潜在的により効率的な方法も考案されることが考えられる。例えば、実施形態によれば、Annex Pのワーピング座標の可変長可逆「ハフマン」スタイルコーディングは、適切な長さのバイナリコーディングに置き換えられ、バイナリコードワードの長さは、例えば、最大画像サイズから導出され、場合によっては特定の係数を乗算し、特定の値をオフセットすることができ、それにより、最大画像サイズの境界の外側の「ワーピング」を可能にする）、および／または
－アップまたはダウンサンプルフィルタパラメータ。最も簡単な場合には、アップサンプリングおよび／またはダウンサンプリングのための単一のフィルタのみが存在してもよい。しかしながら、特定の場合には、フィルタ設計においてより多くの柔軟性を可能にすることが有利であり得、それはフィルタパラメータのシグナリングを必要とする場合がある。そのようなパラメータは、可能なフィルタ設計のリスト内のインデックスを介して選択されてもよく、フィルタは完全に指定されてもよく（例えば、適切なエントロピーコーディング技術を使用して、フィルタ係数のリストを介して）、フィルタは、アップ／ダウンサンプル比を介して暗黙的に選択されてもよく、アップ／ダウンサンプル比は、上述の機構のいずれかに従ってシグナリングされ、以下同様である。
－サンプル、ブロック、マクロブロック、CU、またはその他の適切な粒度の単位で、組み合わされた、または個別の、入力画像、出力画像、参照画像、コーディング済画像のXまたはY次元の解像度（2つ以上の解像度がある場合（例えば、入力画像用に1つ、参照画像用に1つなど）には、場合によっては、一組の値が別の組の値から推測され得る。これは、例えば、フラグを使用することによってゲーティングすることができる。より詳細な例については、以下を参照されたい）。
－「ワーピング」座標は、H．263 Annex Pで使用されるものと同様に、上述したように適切な粒度である（H．263 Annex Pは、そのようなワーピング座標をコーディングする1つの効率的な方法を定義するが、他の潜在的により効率的な方法も考案されることが考えられる。例えば、実施形態によれば、Annex Pのワーピング座標の可変長可逆「ハフマン」スタイルコーディングは、適切な長さのバイナリコーディングに置き換えられ、バイナリコードワードの長さは、例えば、最大画像サイズから導出され、場合によっては特定の係数を乗算し、特定の値をオフセットすることができ、それにより、最大画像サイズの境界の外側の「ワーピング」を可能にする）、および／または
－アップまたはダウンサンプルフィルタパラメータ。最も簡単な場合には、アップサンプリングおよび／またはダウンサンプリングのための単一のフィルタのみが存在してもよい。しかしながら、特定の場合には、フィルタ設計においてより多くの柔軟性を可能にすることが有利であり得、それはフィルタパラメータのシグナリングを必要とする場合がある。そのようなパラメータは、可能なフィルタ設計のリスト内のインデックスを介して選択されてもよく、フィルタは完全に指定されてもよく（例えば、適切なエントロピーコーディング技術を使用して、フィルタ係数のリストを介して）、フィルタは、アップ／ダウンサンプル比を介して暗黙的に選択されてもよく、アップ／ダウンサンプル比は、上述の機構のいずれかに従ってシグナリングされ、以下同様である。
【0068】
以下では、説明は、コードワードによって示される有限なセットのアップ／ダウンサンプル係数（X次元およびY次元の両方で使用される同じ係数）のコーディングを想定している。そのコードワードは、有利には、例えば、H．264およびH．265などのビデオコーディング仕様における特定のシンタックス要素に共通のExt－Golomb符号を使用して、可変長コーディングすることができる。アップ／ダウンサンプル係数への値の1つの適切なマッピングは、例えば、以下の表に従うことができる。
【0069】
【表1】
【0070】
アプリケーションのニーズ、およびビデオ圧縮技術または標準規格で利用可能なアップスケール機構およびダウンスケール機構の能力に従って、多くの同様のマッピングを考案することができる。テーブルは、より多くの値に拡張することができる。値はまた、例えばバイナリコーディングを使用して、Ext－Golomb符号以外のエントロピーコーディング機構によって表されてもよい。これは、例えばMANEによって、再サンプリング係数がビデオ処理エンジン自体の外部（エンコーダおよびデコーダが最も重要）であった場合に、特定の利点を有することができる。解像度変更が必要とされない（おそらく）最も一般的なケースでは、短いExt－Golomb符号が選択され得ることに留意されたい。上記の表では、単一ビットのみである。これは、最も一般的な場合にバイナリコードを使用するよりもコーディング効率の利点を有することができる。
【0071】
テーブル内のエントリの数、ならびにそれらのセマンティクスは、完全にまたは部分的に構成可能であり得る。例えば、テーブルの基本的な概要は、シーケンスまたはデコーダパラメータセットなどの「高」パラメータセットで伝達されてもよい。代替的または追加的に、1つまたは複数のそのようなテーブルは、ビデオコーディング技術または標準規格で定義されてもよく、例えばデコーダまたはシーケンスパラメータセットを介して選択されてもよい。
【0072】
以下では、上述のようにコーディングされたアップサンプル／ダウンサンプル係数（ARC情報）がビデオコーディング技術または標準シンタックスにどのように含まれ得るかを説明する。アップ／ダウンサンプルフィルタを制御する1つまたはいくつかのコードワードにも同様の考慮事項が適用され得る。フィルタまたは他のデータ構造に比較的大量のデータが必要な場合の説明については、以下を参照されたい。
【0073】
図5Aの例に示されているように、図（500A）は、H．263 Annex Pが画像ヘッダ501へ、具体的にはH．263 PLUSPTYPE（503）ヘッダ拡張において、4つのワーピング座標の形態でARC情報502を含むことを示している。これは、a）利用可能な画像ヘッダがあり、b）ARC情報の頻繁な変更が予想される場合に、賢明な設計選択となり得る。しかしながら、H．263スタイルのシグナリングを使用する場合のオーバーヘッドは非常に高くなる可能性があり、画像ヘッダは一時的な性質であり得るため、スケーリング係数は画像境界間に関係しない可能性がある。さらに、図5Bの例に示すように、図（500B）は、JVET－M 0135がPPS情報（504）、ARC参照情報（505）、SPS情報（507）、およびターゲットResテーブル情報（506）を含むことを示している。
【0074】
例示的な実施形態によれば、図5Cは、タイルグループヘッダ情報（508）およびARC情報（509）が示されている例（500C）を示し、図5Dは、タイルグループヘッダ情報（514）、ARC参照情報（513）、SPS情報（516）およびARC情報（515）が示されている例（500D）を示し、図5Eは、適応パラメータセット（APS）情報（511）およびARC情報（512）が示されている例（500E）を示す。
【0075】
JVCET－M 135－v1は、画像パラメータセット（504）内に位置するARC参照情報（505）（インデックス）を含み、シーケンスパラメータセット（507）内に位置するターゲット解像度を含むテーブル（506）をインデックス付けする。シーケンスパラメータセット（507）内のテーブル（506）における可能な解決策の配置は、著者によって行われた口頭の陳述に従って、能力交換中に相互運用交渉点としてSPSを使用することによって正当化され得る。解像度は、適切な画像パラメータセット（504）を参照することによって、画像ごとにテーブル（506）内の値によって設定された制限内で変化することができる。
【0076】
さらに図5を参照すると、ビデオビットストリームでARC情報を伝達するために、以下の追加オプションが存在することができる。これらのオプションの各々は、上述のように既存の技術を超える特定の利点を有する。オプションは、同じビデオコーディング技術または標準規格に同時に存在してもよい。
【0077】
一実施形態では、再サンプリング（ズーム）係数などのARC情報（509）は、スライスヘッダ、GOBヘッダ、タイルヘッダ、またはタイルグループヘッダ（以下、タイルグループヘッダ）（508）に存在することができる。これは、例えば上で示したように、単一の可変長ue（v）または数ビットの固定長コードワードなど、ARC情報が小さい場合には適切であり得る。タイルグループヘッダ内にARC情報を直接有することは、ARC情報のさらなる利点を有し、画像全体ではなく、例えば、そのタイルグループによって表されるサブ画像に適用可能であり得る。以下も参照されたい。加えて、ビデオ圧縮技術または標準規格が（例えば、タイルグループベースの適応的解像度の変化とは対照的に）全画像適応的解像度変更のみを想定している場合であっても、ARC情報をH．263スタイルの画像ヘッダに入れることに対して、ARC情報をタイルグループヘッダに入れることは、エラー回復力の観点から一定の利点を有する。
【0078】
同一または別の実施形態では、ARC情報（512）自体は、例えば、画像パラメータセット、ヘッダパラメータセット、タイルパラメータセット、適応パラメータセットなど（図示されている適応パラメータセット）のような適切なパラメータセット（511）に存在してもよい。そのパラメータセットの範囲は、有利には、画像、例えばタイルグループより大きくしないことができる。ARC情報の使用は、関連するパラメータセットの活性化によって暗黙的に行われる。例えば、ビデオコーディング技術または標準規格が画像ベースのARCのみを企図する場合、画像パラメータセットまたは同等物が適切であり得る。
【0079】
同じ実施形態または別の実施形態では、ARC参照情報（513）は、タイルグループヘッダ（514）または類似のデータ構造に存在してもよい。その参照情報（513）は、単一画像を超えるスコープ、例えばシーケンスパラメータセットまたはデコーダパラメータセットを有するパラメータセット（516）において利用可能なARC情報（515）のサブセットを指すことができる。
【0080】
JVET－M 0135－v1で使用されるタイルグループヘッダPPS，SPSからのPPSの間接的な追加レベルの暗示的な活性化は、例示的な実施形態によれば、画像パラメータセットとして、シーケンスパラメータセットと同様に、機能ネゴシエーションまたはアナウンスに使用することができる（およびRFC 3984などの特定の標準規格で有する）ので不要であるように思われる。しかしながら、ARC情報が、例えばタイルグループによっても表現されるサブ画像に適用可能であるべきである場合には、適応パラメータセットまたはヘッダパラメータセットのような、タイルグループに限定された活性化範囲を有するパラメータセットが、より良い選択であり得る。また、ARC情報が無視できないサイズである場合には、例えば、多数のフィルタ係数などのフィルタ制御情報を含む場合には、パラメータは、コーディング効率の観点から直接ヘッダ（508）を使用するよりも良い選択であり得る。なぜなら、これらの設定は、例示的な実施形態に従って同じパラメータセットを参照することによって、将来の画像またはサブ画像によって再利用可能であり得るからである。
【0081】
シーケンスパラメータセットまたは複数の画像にまたがる範囲を有する別のより高いパラメータセットを使用する場合、特定の考慮事項が適用され得る。
1．ARC情報テーブル（516）を格納するためのパラメータセットは、場合によってはシーケンスパラメータセットであってもよいが、他の場合ではデコーダパラメータセットが有利である。デコーダパラメータセットは、複数のCVS、すなわちコーディング済ビデオストリーム、すなわちセッション開始からセッション終了までのすべてのコーディング済ビデオビットの活性化範囲を有することができる。そのような範囲は、可能性のあるARC因子が、おそらくハードウェアに実装されるデコーダ機能であり得、ハードウェア機能は、CVSによって変化しない傾向があるため、より適切であり得る（少なくともいくつかの娯楽システムでは、長さが1／2以下の画像のグループである）。とは言え、テーブルをシーケンスパラメータセットに入れることは、特に以下の点2に関連して、本明細書に記載の配置オプションに明確に含まれる。
2．ARC参照情報（513）は、有利には、JVCET－M 0135－v1のように画像パラメータセット内にではなく、画像／スライスタイル／GOB／タイルグループヘッダ（以下、タイルグループヘッダ）（514）内に直接配置され得る。その理由は、エンコーダが、例えばARC参照情報などの画像パラメータセット内の単一の値を変更したい場合、新しいPPSを作成し、その新しいPPSを参照する必要があるためである。ARC参照情報のみが変更されるが、例えばPPS内の量子化行列情報などの他の情報は残ると仮定する。そのような情報は実質的なサイズであり得、新しいPPSを完成させるために再送信される必要がある。ARC参照情報は、テーブル（513）へのインデックスのような単一のコードワードであってもよく、それは変化する唯一の値であるので、例えば量子化行列情報のすべてを再送信することは面倒で無駄である。その限りにおいて、は、JVET－M 0135－v1で提案されているように、PPSを通る間接を回避するためにコーディング効率の観点からかなり良好であり得る。同様に、ARC参照情報をPPSに入れることには、画像パラメータセット活性化の範囲が画像であるので、ARC参照情報（513）によって参照されるARC情報は、必ずしもサブ画像ではなく画像全体に適用される必要があるというさらなる欠点がある。
1．ARC情報テーブル（516）を格納するためのパラメータセットは、場合によってはシーケンスパラメータセットであってもよいが、他の場合ではデコーダパラメータセットが有利である。デコーダパラメータセットは、複数のCVS、すなわちコーディング済ビデオストリーム、すなわちセッション開始からセッション終了までのすべてのコーディング済ビデオビットの活性化範囲を有することができる。そのような範囲は、可能性のあるARC因子が、おそらくハードウェアに実装されるデコーダ機能であり得、ハードウェア機能は、CVSによって変化しない傾向があるため、より適切であり得る（少なくともいくつかの娯楽システムでは、長さが1／2以下の画像のグループである）。とは言え、テーブルをシーケンスパラメータセットに入れることは、特に以下の点2に関連して、本明細書に記載の配置オプションに明確に含まれる。
2．ARC参照情報（513）は、有利には、JVCET－M 0135－v1のように画像パラメータセット内にではなく、画像／スライスタイル／GOB／タイルグループヘッダ（以下、タイルグループヘッダ）（514）内に直接配置され得る。その理由は、エンコーダが、例えばARC参照情報などの画像パラメータセット内の単一の値を変更したい場合、新しいPPSを作成し、その新しいPPSを参照する必要があるためである。ARC参照情報のみが変更されるが、例えばPPS内の量子化行列情報などの他の情報は残ると仮定する。そのような情報は実質的なサイズであり得、新しいPPSを完成させるために再送信される必要がある。ARC参照情報は、テーブル（513）へのインデックスのような単一のコードワードであってもよく、それは変化する唯一の値であるので、例えば量子化行列情報のすべてを再送信することは面倒で無駄である。その限りにおいて、は、JVET－M 0135－v1で提案されているように、PPSを通る間接を回避するためにコーディング効率の観点からかなり良好であり得る。同様に、ARC参照情報をPPSに入れることには、画像パラメータセット活性化の範囲が画像であるので、ARC参照情報（513）によって参照されるARC情報は、必ずしもサブ画像ではなく画像全体に適用される必要があるというさらなる欠点がある。
【0082】
同一および他の実施形態では、ARCパラメータのシグナリングは、図6に概説されるような詳細な例に従うことができる。図6は、ビデオコーディング標準規格で使用される表現（600）のシンタックス図を示す。このようなシンタックス図の表記は、大雑把にはCスタイルプログラミングに従う。太字のラインはビットストリームに存在するシンタックス要素を示し、太字のないラインは制御フローまたは変数の設定を示すことが多い。
【0083】
画像の（場合によっては長方形の）部分に適用可能なヘッダの例示的なシンタックス構造としてのタイルグループヘッダ（601）は、条件付きで、可変長のExp－Golombコーディング済シンタックス要素dec＿pic＿size＿idx（602）（太字で示されている）を含むことができる。タイルグループヘッダ内のこのシンタックス要素の存在は、適応的解像度（603）、ここでは太字で示されていないフラグの値を使用してゲーティングすることができ、これは、フラグがシンタックス図内で発生する点でビットストリーム内に存在することを意味する。適応的解像度がこの画像またはその一部に使用されているか否かは、ビットストリームの内部または外部の任意の高レベルシンタックス構造でシグナリングすることができる。示されている例では、以下に概説するようにシーケンスパラメータセットでシグナリングされる。
【0084】
さらに図6を参照すると、シーケンスパラメータセット（610）の抜粋も示されている。示されている第1のシンタックス要素は、adaptive＿pic＿resolution＿change＿flag（611）である。真の場合、そのフラグは適応的解像度の使用を示すことができ、適応的解像度は特定の制御情報を必要とする場合がある。この例では、このような制御情報は、パラメータセット（612）内のif（）文に基づくフラグの値とタイルグループヘッダ（601）とに基づいて、条件付きで存在する。
【0085】
適応的解像度が使用されている場合、例示的な実施形態によれば、コーディングされるのはサンプル単位の出力解像度である（613）。符号613は、出力画像の解像度を共に定義することができる、output＿pic＿width＿in＿luma＿samplesおよびoutput＿pic＿height＿in＿luma＿samplesの両方を指す。ビデオコーディング技術または標準規格の他の場所では、いずれかの値に対する特定の制限を定義することができる。例えば、レベル定義は、それらの2つのシンタックス要素の値の積とすることができる総出力サンプルの数を制限することができる。また、特定のビデオコーディング技術もしくは標準規格、または例えばシステム規格などの外部技術もしくは規格は、番号付け範囲（例えば、一方または両方の次元は、2の累乗で割り切れなければならない）、またはアスペクト比（例えば、幅と高さは4：3または16：9などの関係でなければならない）を制限することができる。そのような制限は、ハードウェア実装を容易にするために、または他の理由のために導入されてもよい。
【0086】
特定の用途では、エンコーダは、サイズが出力画像サイズであると暗黙的に仮定するのではなく、特定の参照画像サイズを使用するようにデコーダに指示することが望ましい場合がある。この例では、シンタックス要素reference＿pic＿size＿present＿flag（614）は、参照画像次元（615）（この場合も、符号は幅と高さの両方を指す）の条件付き存在をゲートする。
【0087】
最後に、可能なデコーディング画像の幅および高さの表が示されている。このような表は、例えば、テーブル表示（num＿dec＿pic＿size＿in＿luma＿samples＿minus1）（616）で表すことができる。「minus1」は、そのシンタックス要素の値の解釈を指すことができる。例えば、コーディングされた値がゼロである場合には、1つのテーブルエントリが存在する。値が5である場合には、6つのテーブルエントリが存在する。テーブル内の各「ライン」について、デコード済画像の幅および高さがシンタックスに含まれる（617）。
【0088】
提示されたテーブルエントリ（617）は、タイルグループヘッダ内のシンタックス要素dec＿pic＿size＿idx（602）を使用してインデックス付けすることができ、それにより、タイルグループごとに異なるデコード済サイズ、実際にはズーム係数を可能にする。
【0089】
例えばVP9のような特定のビデオコーディング技術または標準規格は、空間スケーラビリティを可能にするために、（開示された主題とは全く異なるようにシグナリングされた）特定の形式の参照画像再サンプリングを、時間スケーラビリティと併せて実施することによって、空間スケーラビリティをサポートする。特に、特定の参照画像は、ARCスタイル技術を使用してより高い解像度にアップサンプリングされ、空間エンハンスメントレイヤのベースを形成することができる。これらのアップサンプリングされた画像は、詳細を追加するために、高解像度で通常の予測機構を使用して洗練され得る。
【0090】
開示された主題は、そのような環境で使用することができる。場合によっては、同一および他の実施形態では、NALユニットヘッダ内の値、例えば時間IDフィールドを使用して、時間レイヤだけでなく空間レイヤも示すことができる。そうすることは、特定のシステム設計において特定の利点を有する。例えば、NALユニットヘッダ時間ID値に基づいて時間レイヤ選択転送のために作成および最適化された既存の選択転送ユニット（SFU）は、スケーラブル環境のために、修正なしで使用することができる。これを可能にするために、コーディング済画像サイズと時間レイヤとの間のマッピングに対する要件が存在してもよく、これはNALユニットヘッダ内の時間IDフィールドによって示される。
【0091】
いくつかのビデオコーディング技術では、アクセスユニット（AU）は、所与の時間インスタンスにおいてそれぞれの画像／スライス／タイル／NALユニットビットストリームに取り込まれて構成された、コーディング済画像、スライス、タイル、NALユニットなどを参照することができる。その時間内のインスタンスは、合成時間であり得る。
【0092】
HEVC、および特定の他のビデオコーディング技術では、デコード済画像バッファ（DPB）に格納された複数の参照画像の中から選択された参照画像を示すために画像順序カウント（POC）値を使用することができる。アクセスユニット（AU）が1つまたは複数の画像、スライス、またはタイルを含む場合、同じAUに属する各画像、スライス、またはタイルは、同じPOC値を有することができ、そこから、それらが同じ合成時間のコンテンツから作成されたことを導出することができる。言い換えれば、2つの画像／スライス／タイルが同じ所与のPOC値を搬送するシナリオでは、それは同じAUに属し、同じ合成時間を有する2つの画像／スライス／タイルを示すことができる。逆に、異なるPOC値を有する2つの画像／タイル／スライスは、異なるAUに属し、異なる合成時間を有するそれらの画像／スライス／タイルを示すことができる。
【0093】
開示された主題の例示的な実施形態によれば、アクセスユニットが異なるPOC値を有する画像、スライス、またはタイルを含むことができるという点で、前述の厳格な関係を緩和することができる。AU内で異なるPOC値を許容することにより、POC値を使用して、同一の提示時間を有する、潜在的に独立してデコード可能な画像／スライス／タイルを識別することが可能になる。これにより、以下でより詳細に説明するように、参照画像選択シグナリング（例えば、参照画像セットシグナリングまたは参照画像リストシグナリング）を変更することなく、複数のスケーラブルレイヤのサポートを可能にすることができる。
【0094】
しかしながら、異なるPOC値を有する他の画像／スライス／タイルに関して、POC値のみから、画像／スライス／タイルが属するAUを識別できることが依然として望ましい。これは、以下に説明するように達成することができる。
【0095】
同一および他の実施形態では、アクセスユニットカウント（AUC）は、NALユニットヘッダ、スライスヘッダ、タイルグループヘッダ、SEIメッセージ、パラメータセットまたはAUデリミタなどの高レベルシンタックス構造でシグナリングされてもよい。AUCの値は、所与のAUに属するNALユニット、画像、スライス、またはタイルを識別するために使用され得る。AUCの値は、別個の合成時間インスタンスに対応することができる。AUC値は、POC値の倍数に等しくてもよい。POC値を整数値で除算することにより、AUC値を算出することができる。場合によっては、除算演算は、デコーダの実装に一定の負担をかける可能性がある。このような場合、AUC値の番号付けスペースの制約が小さいため、除算演算をシフト演算に置き換えることができる。例えば、AUC値は、POC値範囲の最上位ビット（MSB）値に等しくてもよい。
【0096】
同一および他の実施形態では、AUごとの画像順序カウント（POC）サイクル（poc＿cycle＿au）の値は、NALユニットヘッダ、スライスヘッダ、タイルグループヘッダ、SEIメッセージ、パラメータセットまたはAUデリミタなどの高レベルシンタックス構造でシグナリングされてもよい。poc＿cycle＿auは、同じAUに関連付けられ得る異なる連続するPOC値の数を示すことができる。例えば、poc＿cycle＿auの値が4に等しい場合には、POC値が0～3に等しい画像、スライスまたはタイルは、AUC値が0に等しいAUに関連付けられ、POC値が4～7に等しい画像、スライスまたはタイルは、AUC値が1に等しいAUに関連付けられる。したがって、AUCの値は、POC値をpoc＿cycle＿auの値で除算することによって推測することができる。
【0097】
同一および他の実施形態では、poc＿cyle＿auの値は、例えばビデオパラメータセット（VPS）に位置する、コーディング済ビデオシーケンスにおける空間レイヤまたはSNRレイヤの数を識別する情報から導出され得る。以下、このような関係を簡単に説明する。上述したような導出は、VPSにおいて数ビットを節約することができ、したがってコーディング効率を改善することができるが、ビデオパラメータセットの下位に階層的に適切な高レベルシンタックス構造でpoc＿cycle＿auを明示的にコーディングして、画像などのビットストリームの所与の小部分についてpoc＿cycle＿auを最小化することができることが有利であり得る。この最適化は、POC値（および／またはPOCを間接的に参照するシンタックス要素の値）が低レベルのシンタックス構造でコーディングされ得るため、上記の導出プロセスを通して節約できるよりも多くのビットを節約することができる。
【0098】
同一または別の実施形態では、図9は、コーディング済ビデオシーケンス内のすべての画像／スライスに使用されるpoc＿cycle＿auを示すVPS（またはSPS）内のvps＿poc＿cycle＿auのシンタックス要素、およびスライスヘッダ内の現在のスライスのpoc＿cycle＿auを示すslice＿poc＿cycle＿auのシンタックス要素をシグナリングするためのシンタックステーブルの例（900）を示す。POC値がAUごとに一律に増加する場合、VPSにおけるvps＿contant＿poc＿cycle＿per＿auを1とし、VPSにおいてvps＿poc＿cycle＿auをシグナリングする。この場合、slice＿poc＿cycle＿auは明示的にシグナリングされず、POCの値をvps＿poc＿cycle＿auで除算することにより、各AUのAUCの値が算出される。POC値がAUごとに一律に増加しない場合には、VPSにおけるvps＿contant＿poc＿cycle＿per＿auを0に等しく設定する。この場合、vps＿access＿unit＿cntはシグナリングされず、slice＿access＿unit＿cntは、スライスまたは画像ごとにスライスヘッダでシグナリングされる。各スライスまたは画像は、異なる値のslice＿access＿unit＿cntを有してもよい。各AUのAUCの値は、POCの値をslice＿poc＿cycle＿auで除算することにより算出される。図10は、関連するワークフロー（1000）を示すブロック図を示し、S100において、VPS／SPSをパーシングし、AUごとのPOCサイクルが一定であるか否かを識別することが考慮され、S101において、コーディング済ビデオシーケンス内のAU定数ごとのPOCサイクルが決定される。そうでない場合には、S103において、画像レベルpoc＿cycle au値およびPOC値からアクセスユニットカウントの値を計算し、そうである場合には、S102において、シーケンスレベルpoc＿cycle＿au＿valueおよびPOC値からアクセスユニットカウントの値を計算する。S104において、VPS／SPSをパーシングし、AUごとのPOCサイクルが一定であるか否かを識別することが再び考慮され、これは周期的に継続するか、そうでなければワークフロー（1000）の1つまたは複数の部分であってもよい。
【0099】
同一および他の実施形態では、画像、スライス、またはタイルのPOCの値が異なっていても、同じAUC値を有するAUに対応する画像、スライス、またはタイルは、同じデコーディングまたは出力時間インスタンスに関連付けられ得る。したがって、同じAU内の画像、スライス、またはタイルにわたるパーシング／デコーディング間の依存関係なしに、同じAUに関連付けられた画像、スライス、またはタイルのすべてまたはサブセットを並列にデコードすることができ、同時に出力することができる。
【0100】
同一および他の実施形態では、画像、スライス、またはタイルのPOCの値が異なっていても、同じAUC値を有するAUに対応する画像、スライス、またはタイルは、同じ合成／表示時間インスタンスに関連付けられ得る。合成時間がコンテナ形式に含まれている場合、画像が異なるAUに対応していても、画像が同じ合成時間を有する場合、それらの画像は同じ時間インスタンスで表示することができる。
【0101】
同一および他の実施形態では、各画像、スライス、またはタイルは、同じAU内の同じ時間識別子（temporal＿id）を有することができる。時間インスタンスに対応する画像、スライス、またはタイルのすべてまたはサブセットは、同じ時間サブレイヤに関連付けられ得る。同一および他の実施形態では、各画像、スライス、またはタイルは、同じAU内の同一または異なる空間レイヤid（layer＿id）を有することができる。時間インスタンスに対応する画像、スライス、またはタイルのすべてまたはサブセットは、同一または異なる空間レイヤに関連付けられ得る。
【0102】
図8は、適応的解像度変化を伴うtemporal＿id、layer＿id、POC、およびAUC値の組み合わせを有するビデオシーケンス構造の例（800）を示す。この例では、AUC＝0の第1のAU内の画像、スライス、またはタイルは、temporal＿id＝0およびlayer＿id＝0もしくは1を有することができるが、AUC＝1の第2のAU内の画像、スライス、またはタイルは、それぞれtemporal＿id＝1およびlayer＿id＝0もしくは1を有することができる。temporal＿idおよびlayer＿idの値にかかわらず、POCの値は画像ごとに1ずつ増加する。この例では、poc＿cycle＿auの値は2に等しくすることができる。好ましくは、poc＿cycle＿auの値は、（空間スケーラビリティ）レイヤの数に等しく設定されてもよい。したがって、この例では、POCの値は2だけ増加し、AUCの値は1だけ増加する。
【0103】
例示的な実施形態では、画像間またはレイヤ間予測構造および参照画像指示のすべてまたはサブセットは、HEVCにおける既存の参照画像セット（RPS）シグナリングまたは参照画像リスト（RPL）シグナリングを使用することによってサポートされ得る。RPSまたはRPLでは、選択された参照画像は、現在の画像と選択された参照画像との間のPOCの値またはPOCのデルタ値をシグナリングすることによって示される。開示された主題の場合、RPSおよびRPLは、シグナリングを変更せずに、ただし以下の制限を伴って、画像間またはレイヤ間予測構造を示すために使用され得る。参照画像のtemporal＿idの値がtemporal＿id現在の画像の値より大きい場合には、現在の画像は、動き補償または他の予測のために参照画像を使用しない場合がある。参照画像のlayer＿idの値がlayer＿id現在の画像の値より大きい場合、現在の画像は、動き補償または他の予測のために参照画像を使用しない場合がある。
【0104】
同一および他の実施形態では、時間的動きベクトル予測のためのPOC差に基づく動きベクトルのスケーリングは、アクセスユニット内の複数の画像にわたって無効にすることができる。したがって、各画像はアクセスユニット内で異なるPOC値を有することができるが、動きベクトルはスケーリングされず、アクセスユニット内の時間的動きベクトル予測に使用されない。これは、同じAU内のPOCが異なる参照画像は、同じ時刻インスタンスを有する参照画像とみなされるためである。したがって、例示的な実施形態では、参照画像が現在の画像に関連付けられたAUに属する場合、動きベクトルスケーリング関数は1を返すことができる。
【0105】
同一および他の実施形態では、参照画像の空間解像度が現在の画像の空間解像度と異なる場合、時間的動きベクトル予測のためのPOC差に基づく動きベクトルのスケーリングは、複数の画像にわたってオプションとして無効にすることができる。動きベクトルのスケーリングが許可されている場合、動きベクトルは、現在の画像と参照画像との間のPOC差および空間解像度比の両方に基づいてスケーリングされる。
【0106】
同一または別の実施形態では、動きベクトルは、特にpoc＿cycle＿auが不均一な値を有する場合（vps＿contant＿poc＿cycle＿per＿au＝＝0の場合）、時間的動きベクトル予測のために、POC差ではなくAUC差に基づいてスケーリングされてもよい。そうでない場合（vps＿contant＿poc＿cycle＿per＿au＝＝1の場合）、AUC差分に基づく動きベクトルのスケーリングは、POC差分に基づく動きベクトルのスケーリングと同一であってもよい。
【0107】
同一または別の実施形態では、動きベクトルがAUC差に基づいてスケーリングされる場合、現在の画像と同じAU（同じAUC値を有する）内の参照動きベクトルは、AUC差に基づいてスケーリングされず、現在の画像と参照画像との間の空間解像度比に基づくスケーリングなしまたはスケーリングありの動きベクトル予測に使用される。
【0108】
同一および他の実施形態では、AUC値は、AUの境界を識別するために使用され、AU粒度を有する入力および出力タイミングを必要とする仮想参照デコーダ（HRD）動作のために使用される。ほとんどの場合、AU内の最上位レイヤを有するデコード済画像が、表示のために出力され得る。AUC値およびlayer＿id値は、出力画像の識別に用いることができる。
【0109】
例示的な実施形態では、画像は、1つまたは複数のサブ画像から構成されてもよい。各サブ画像は、画像の局所領域または全領域をカバーすることができる。サブ画像によってサポートされる領域は、別のサブ画像によってサポートされる領域と重なっていてもよいし、重なっていなくてもよい。1つまたは複数のサブ画像によって構成される領域は、画像の全領域をカバーしてもしなくてもよい。画像がサブ画像から構成される場合には、サブ画像によってサポートされる領域は画像によってサポートされる領域と同一である。
【0110】
同一および他の実施形態では、サブ画像は、コーディング済画像に使用されるコーディング方法と同様のコーディング方法によってコーディングされてもよい。サブ画像は、独立してコーディングされ得るか、または、別のサブ画像またはコーディング済画像に依存してコーディングされ得る。サブ画像は、別のサブ画像またはコーディング済画像からのパーシング依存性を有しても、有しなくてもよい。
【0111】
同一および他の実施形態では、コーディング済サブ画像は、1つまたは複数のレイヤに含まれてもよい。レイヤ内のコーディング済サブ画像は、異なる空間解像度を有することができる。元のサブ画像は、空間的に再サンプリング（アップサンプリングまたはダウンサンプリング）され、異なる空間解像度パラメータでコーディングされ、レイヤに対応するビットストリームに含まれ得る。
【0112】
同一および他の実施形態では、（W，H）を有するサブ画像がコーディングされてレイヤ0に対応するコーディング済ビットストリームに含まれてもよく、ここでWはサブ画像の幅を示し、Hはサブ画像の高さをそれぞれ示し、一方、（W＊Sw，k，H＊ Sh，k）を有する元の空間解像度を有するサブ画像からアップサンプリングされた（またはダウンサンプリングされた）サブ画像がコーディングされてレイヤkに対応するコーディング済ビットストリームに含まれてもよく、ここでSw，k，Sh，kは水平方向および垂直方向の再サンプリング比を示す。Sw，k、Sh，kの値が1より大きい場合には、再サンプリングはアップサンプリングに等しい。一方、Sw，k、Sh，kの値が1より小さい場合には、再サンプリングはダウンサンプリングに等しい。
【0113】
同一および他の実施形態では、レイヤ内のコーディング済サブ画像は、同じサブ画像または異なるサブ画像内の別のレイヤ内のコーディング済サブ画像の視覚的品質とは異なる視覚的品質を有することができる。例えば、レイヤn内のサブ画像iは量子化パラメータQi，nでコーディングされ、レイヤm内のサブ画像jは量子化パラメータQj，mでコーディングされる。
【0114】
同一および他の実施形態では、レイヤ内のコーディング済サブ画像は、同じ局所領域の別のレイヤ内のコーディング済サブ画像からのパーシングまたはデコーディングの依存関係なしに、独立してデコード可能であり得る。同じ局所領域の別のサブ画像レイヤを参照することなく独立してデコード可能であり得るサブ画像レイヤは、独立したサブ画像レイヤである。独立したサブ画像レイヤ内のコーディング済サブ画像は、同じサブ画像レイヤ内の以前のコーディング済サブ画像からのデコーディングまたはパーシングの依存関係を有しても有しなくてもよいが、コーディング済サブ画像は、別のサブ画像レイヤ内のコーディング済画像からのいかなる依存関係も有しなくてもよい。
【0115】
同一および他の実施形態では、レイヤ内のコーディング済サブ画像は、同じ局所領域の別のレイヤ内のコーディング済サブ画像からの任意のパーシングまたはデコーディング依存性を伴って、依存してデコード可能であり得る。同じ局所領域の別のサブ画像レイヤを参照して従属的にデコード可能であり得るサブ画像レイヤは、従属サブ画像レイヤである。依存サブ画像内のコーディング済サブ画像は、同じサブ画像に属するコーディング済サブ画像、同じサブ画像レイヤ内の以前のコーディング済サブ画像、または両方の参照サブ画像を参照することができる。
【0116】
同一および他の実施形態では、コーディング済サブ画像は、1つまたは複数の独立したサブ画像レイヤならびに1つまたは複数の依存サブ画像レイヤから構成される。しかしながら、コーディング済サブ画像に対して少なくとも1つの独立したサブ画像レイヤが存在してもよい。独立したサブ画像レイヤは、0に等しい、NALユニットヘッダまたは別の高レベルシンタックス構造に存在することができるレイヤ識別子（layer＿id）の値を有することができる。layer＿idが0に等しいサブ画像レイヤはベースサブ画像レイヤである。
【0117】
同一および他の実施形態では、画像は、1つまたは複数の前景サブ画像および1つの背景サブ画像から構成されてもよい。背景サブ画像によってサポートされる領域は、画像の領域と等しくてもよい。前景サブ画像によってサポートされる領域は、背景サブ画像によってサポートされる領域と重複してもよい。背景サブ画像はベースサブ画像レイヤであってもよく、前景サブ画像はノンベース（エンハンスメント）サブ画像レイヤであってもよい。1つまたは複数のノンベースサブ画像レイヤは、デコーディングのために同じベースレイヤを参照してもよい。layer＿idがaに等しい各ノンベースサブ画像レイヤは、layer＿idがbに等しいノンベースサブ画像レイヤを参照することができ、aはbより大きい。
【0118】
同一または別の実施形態では、画像は、背景サブ画像の有無にかかわらず、1つまたは複数の前景サブ画像から構成されてもよい。各サブ画像は、それ自体のベースサブ画像レイヤおよび1つもしくは複数のノンベース（エンハンスメント）レイヤを有してもよい。各ベースサブ画像レイヤは、1つまたは複数のノンベースサブ画像レイヤによって参照されてもよい。layer＿idがaに等しい各ノンベースサブ画像レイヤは、layer＿idがbに等しいノンベースサブ画像レイヤを参照することができ、aはbより大きい。
【0119】
同一および他の実施形態では、画像は、背景サブ画像の有無にかかわらず、1つまたは複数の前景サブ画像から構成されてもよい。（ベースまたはノンベース）サブ画像レイヤ内の各コーディング済サブ画像は、同じサブ画像に属する1つまたは複数のノンベースレイヤサブ画像と、同じサブ画像に属さない1つまたは複数のノンベースレイヤサブ画像とによって参照されてもよい。
【0120】
同一および他の実施形態では、画像は、背景サブ画像の有無にかかわらず、1つまたは複数の前景サブ画像から構成されてもよい。レイヤa内のサブ画像は、同じレイヤ内の複数のサブ画像にさらに分割され得る。レイヤb内の1つまたは複数のコーディング済サブ画像は、レイヤa内の分割されたサブ画像を参照することができる。
【0121】
同一および他の実施形態では、コーディング済ビデオシーケンス（CVS）は、コーディング済画像のグループであってもよい。CVSは、1つまたは複数のコーディング済サブ画像シーケンス（CSPS）から構成されてもよく、CSPSは、画像の同じ局所領域をカバーするコーディング済サブ画像のグループであってもよい。CSPSは、コーディング済ビデオシーケンスの時間解像度と同一または異なる時間解像度を有してもよい。
【0122】
同一および他の実施形態では、CSPSはコーディングされ、1つまたは複数のレイヤに含まれてもよい。CSPSは、1つまたは複数のCSPSレイヤから構成されてもよい。CSPSに対応する1つまたは複数のCSPSレイヤをデコードすることにより、同じ局所領域に対応するサブ画像のシーケンスを再構築することができる。
【0123】
同一および他の実施形態では、CSPSに対応するCSPSレイヤの数は、別のCSPSに対応するCSPSレイヤの数と同一であっても異なっていてもよい。
【0124】
同一または別の実施形態では、CSPSレイヤは、別のCSPSレイヤとは異なる時間分解能（例えば、フレームレート）を有してもよい。元の（非圧縮）サブ画像シーケンスは、時間的に再サンプリング（アップサンプリングまたはダウンサンプリング）され、異なる時間解像度パラメータでコーディングされ、レイヤに対応するビットストリームに含まれてもよい。
【0125】
同一または別の実施形態では、フレームレートFを有するサブ画像シーケンスがコーディングされ、レイヤ0に対応するコーディング済ビットストリームに含まれてもよく、F＊St，kを有する元のサブ画像シーケンスから時間的にアップサンプリングされた（またはダウンサンプリングされた）サブ画像シーケンスがコーディングされ、レイヤkに対応するコーディング済ビットストリームに含まれてもよく、ここで、St，kはレイヤkの時間的サンプリング比を示す。St，kの値が1より大きい場合には、時間的再サンプリングプロセスはフレームレートアップ変換に等しい。一方、St，kの値が1より小さい場合には、時間的再サンプリングプロセスはフレームレートダウン変換に等しい。
【0126】
同一および他の実施形態では、CSPSレイヤaを有するサブ画像が動き補償または任意のレイヤ間予測のためにCSPSレイヤbを有するサブ画像によって参照される場合、CSPSレイヤaの空間解像度がCSPSレイヤbの空間解像度と異なる場合には、CSPSレイヤa内のデコード済画素は再サンプリングされ、参照に使用される。再サンプリングプロセスは、アップサンプリングフィルタリングまたはダウンサンプリングフィルタリングを必要とする場合がある。
【0127】
図11は、layer＿idが0に等しい背景ビデオCSPSおよび複数の前景CSPSレイヤを含む例示的なビデオストリーム（1100）を示す。コーディング済サブ画像は1つまたは複数のCSPSレイヤから構成され得るが、いかなる前景CSPSレイヤにも属さない背景領域はベースレイヤから構成されてもよい。ベースレイヤは背景領域および前景領域を含むことができ、一方、エンハンスメントCSPSレイヤは前景領域を含む。エンハンスメントCSPSレイヤは、同じ領域において、ベースレイヤよりも良好な視覚的品質を有することができる。エンハンスメントCSPSレイヤは、同じ領域に対応する、再構築されたピクセルおよびベースレイヤの動きベクトルを参照することができる。
【0128】
同一および他の実施形態では、ベースレイヤに対応するビデオビットストリームはトラックに含まれ、各サブ画像に対応するCSPSレイヤはビデオファイル内の分離されたトラックに含まれる。
【0129】
同一および他の実施形態では、ベースレイヤに対応するビデオビットストリームはトラックに含まれ、同じlayer＿idを有するCSPSレイヤは分離されたトラックに含まれる。この例では、レイヤkに対応するトラックは、レイヤkに対応するCSPSレイヤのみを含む。
【0130】
同一および他の実施形態では、各サブ画像の各CSPSレイヤは、別個のトラックに格納される。各トラックは、1つまたは複数の他のトラックからのパーシングまたはデコーディング依存性を有していても、有していなくてもよい。
【0131】
同一および他の実施形態では、各トラックは、サブ画像のすべてまたはサブセットのCSPSレイヤのレイヤiからレイヤjに対応するビットストリームを含むことができ、ここで、0＜i＝＜j＝＜kであり、kはCSPSの最上位レイヤである。
【0132】
同一および他の実施形態では、画像は、深度マップ、アルファマップ、3Dジオメトリデータ、占有マップなどを含む1つまたは複数の関連するメディアデータから構成される。そのような関連する時限メディアデータは、各々が1つのサブ画像に対応する1つまたは複数のデータサブストリームに分割することができる。
【0133】
同一および他の実施形態では、図12は、マルチレイヤサブ画像方法に基づくビデオ会議（1200）の一例を示す。ビデオストリームには、背景画像に対応する1つのベースレイヤビデオビットストリームと、前景サブ画像に対応する1つまたは複数のエンハンスメントレイヤビデオビットストリームと、が含まれる。各エンハンスメントレイヤビデオビットストリームは、CSPSレイヤに対応する。ディスプレイでは、ベースレイヤに対応する画像がデフォルトで表示される。これは、画像内の1つまたは複数のユーザの画像（PIP）を含む。クライアントの制御によって特定のユーザが選択されると、選択されたユーザに対応するエンハンスメントCSPSレイヤがデコードされ、エンハンスされた品質または空間解像度で表示される。図13は、S130においてマルチレイヤを有するビデオビットストリームのデコーディングがあり、S131において背景領域および1つもしくは複数の前景サブ画像の識別がある動作のための図（1300）を示す。S132において、特定のサブ画像領域が選択されているかどうかが判定される。そうでない場合には、S134において、背景領域のデコーディングおよび表示が行われ、そうである場合には、S133において、エンハンスされたサブ画像のデコーディングおよび表示が行われ、図（1300）はそこから周期的に継続してもよく、または他の動作と順次もしくは並行して進行してもよい。
【0134】
同一および他の実施形態では、ネットワーク中間ボックス（ルータなど）は、その帯域幅に応じて、ユーザに送信するレイヤのサブセットを選択することができる。画像／サブ画像編成は、帯域幅適応のために使用されてもよい。例えば、ユーザが帯域幅を有していない場合には、ルータは、それらの重要性に起因して、または使用される設定に基づいて、レイヤのストリップまたはいくつかのサブ画像を選択し、これは、帯域幅を採用するために動的に行うことができる。
【0135】
図14は、360ビデオのユースケース（1400）を示す。球面360画像が平面画像上に投影される場合、投影360画像は、ベースレイヤとして複数のサブ画像に分割され得る。特定のサブ画像のエンハンスメントレイヤは、コーディングされ、クライアントに送信され得る。デコーダは、すべてのサブ画像を含むベースレイヤと選択されたサブ画像のエンハンスメントレイヤの両方をデコードすることができる。現在のビューポートが選択されたサブ画像と同一である場合、表示された画像は、エンハンスメントレイヤを有するデコード済サブ画像でより高い品質を有することができる。そうでなければ、ベースレイヤを有するデコード済画像を低品質で表示することができる。
【0136】
同一および他の実施形態では、表示用の任意のレイアウト情報が、補足情報（SEIメッセージまたはメタデータなど）としてファイルに存在してもよい。1つまたは複数のデコードされたサブ画像は、シグナリングされたレイアウト情報に応じて再配置および表示され得る。レイアウト情報は、ストリーミングサーバまたはブロードキャスタによってシグナリングされてもよいし、ネットワークエンティティまたはクラウドサーバによって再生成されてもよいし、ユーザのカスタマイズされた設定によって決定されてもよい。
【0137】
例示的な実施形態では、入力画像が1つまたは複数の（長方形の）サブ領域に分割される場合、各サブ領域は独立したレイヤとしてコーディングされてもよい。局所領域に対応する各独立レイヤは、一意のlayer＿id値を有することができる。各独立したレイヤについて、サブ画像サイズおよび位置情報がシグナリングされ得る。例えば、画像サイズ（幅、高さ）、左上隅のオフセット情報（xオフセット、yオフセット）である。図15は、分割されたサブ画像のレイアウト、そのサブ画像サイズおよび位置情報、ならびにその対応する画像予測構造の一例（1500）を示す。サブ画像サイズおよびサブ画像位置を含むレイアウト情報は、パラメータセット、スライスもしくはタイルグループのヘッダ、またはSEIメッセージなどの高レベルシンタックス構造でシグナリングされ得る。
【0138】
同一または他の実施形態では、独立したレイヤに対応する各サブ画像は、AU内に固有のPOC値を有してもよい。DPBに格納された画像のうちの参照画像が、RPSまたはRPL構造のシンタックス要素を使用して示される場合、レイヤに対応する各サブ画像のPOC値が使用されてもよい。
【0139】
同一および他の実施形態では、（レイヤ間）予測構造を示すために、layer＿idは使用されなくてもよく、POC（デルタ）値が使用されてもよい。
【0140】
同一および他の実施形態では、レイヤ（または局所領域）に対応するNに等しいPOC値を有するサブ画像は、動き補償予測のための同じレイヤ（または同じ局所領域）に対応する、N＋Kに等しいPOC値を有するサブ画像の参照画像として使用されてもされなくてもよい。ほとんどの場合、数Kの値は、（独立した）レイヤの最大数に等しくてもよく、これはサブ領域の数と同一であってもよい。
【0141】
同一および他の実施形態では、図16は、図15の拡張ケース（1600）を示す。入力画像が複数の（例えば4つの）サブ領域に分割される場合、各局所領域は1つまたは複数のレイヤでコーディングされ得る。この場合、独立したレイヤの数はサブ領域の数に等しくてもよく、1つまたは複数のレイヤがサブ領域に対応してもよい。したがって、各サブ領域は、1つまたは複数の独立したレイヤならびに0または1以上の従属レイヤを用いてコーディングされ得る。
【0142】
同一および他の実施形態では、図16において、入力画像は、4つのサブ領域に分割され得る。右上部サブ領域は、レイヤ1およびレイヤ4である2つのレイヤとしてコーディングされてもよく、右下部サブ領域は、レイヤ3およびレイヤ5である2つのレイヤとしてコーディングされてもよい。この場合、レイヤ4は、動き補償予測のためにレイヤ1を参照することができ、レイヤ5は、動き補償のためにレイヤ3を参照することができる。
【0143】
同一および他の実施形態では、レイヤ境界にわたるループ内フィルタリング（デブロッキングフィルタ、適応インループフィルタ、リシェーパ、バイラテラルフィルタ、または任意のディープラーニングベースのフィルタリングなど）を（オプションとして）無効にすることができる。
【0144】
同一および他の実施形態では、レイヤ境界にわたる動き補償予測またはブロック内コピーは、（オプションとして）無効にすることができる。
【0145】
同一および他の実施形態では、サブ画像の境界における動き補償予測またはインループフィルタリングのための境界パディングは、オプションとして処理されてもよい。境界パディングが処理されるか否かを示すフラグは、パラメータセット（VPS、SPS、PPS、またはAPS）、スライスもしくはタイルグループヘッダ、またはSEIメッセージなどの高レベルシンタックス構造でシグナリングすることができる。
【0146】
同一および他の実施形態では、サブ領域（またはサブ画像）のレイアウト情報は、VPSまたはSPSにおいてシグナリングされ得る。図17は、VPSおよびSPSにおけるシンタックス要素の例（1700）を示す。この例では、vps＿sub＿picture＿dividing＿flagがVPSにおいてシグナリングされる。このフラグは、入力画像が複数のサブ領域に分割されるか否かを示すことができる。vps＿sub＿picture＿dividing＿flagの値が0に等しい場合、現在のVPSに対応するコーディング済ビデオシーケンス内の入力画像は、複数のサブ領域に分割されなくてもよい。この場合、入力画像サイズは、SPSにおいてシグナリングされるコーディング済画像サイズ（pic＿width＿in＿luma＿samples、pic＿height＿in＿luma＿samples）に等しくてもよい。vps＿sub＿picture＿dividing＿flagの値が1に等しい場合、入力画像は複数のサブ領域に分割されてもよい。この場合、シンタックス要素vps＿full＿pic＿width＿in＿luma＿samplesおよびvps＿full＿pic＿height＿in＿luma＿samplesは、VPSでシグナリングされる。vps＿full＿pic＿width＿in＿luma＿samplesおよびvps＿full＿pic＿height＿in＿luma＿samplesの値は、それぞれ入力画像の幅および高さに等しくてもよい。
【0147】
同一および他の実施形態では、vps＿full＿pic＿width＿in＿luma＿samplesおよびvps＿full＿pic＿height＿in＿luma＿samplesの値はデコーディングに使用されなくてもよく、合成および表示に使用されてもよい。
【0148】
同一および他の実施形態では、vps＿sub＿picture＿dividing＿flagの値が1に等しい場合、シンタックス要素pic＿offset＿xおよびpic＿offset＿yは、特定のレイヤに対応するSPSにおいてシグナリングされてもよい。この場合、SPSでシグナリングされるコーディング済画像サイズ（pic＿width＿in＿luma＿samples、pic＿height＿in＿luma＿samples）は、特定のレイヤに対応するサブ領域の幅および高さに等しくてもよい。また、サブ領域の左上隅の位置（pic＿offset＿x，pic＿offset＿y）は、SPSでシグナリングされてもよい。
【0149】
同一および他の実施形態では、サブ領域の左上隅の位置情報（pic＿offset＿x，pic＿offset＿y）は、デコーディングに使用されなくてもよく、合成および表示に使用されてもよい。
【0150】
同一または別の実施形態では、入力画像のすべてまたはサブセットサブ領域のレイアウト情報（サイズおよび位置）、レイヤ間の依存関係情報は、パラメータセットまたはSEIメッセージでシグナリングされてもよい。図18は、サブ領域のレイアウト、レイヤ間の依存性、およびサブ領域と1つまたは複数のレイヤとの間の関係の情報を示すシンタックス要素の一例（1800）を示す。この例（1800）では、シンタックス要素num＿sub＿regionは、現在のコーディング済ビデオシーケンス内の（長方形の）サブ領域の数を示す。シンタックス要素num＿layersは、現在のコーディング済ビデオシーケンス内のレイヤ数を示す。num＿layersの値は、num＿sub＿regionの値以上であってもよい。任意のサブ領域が単一のレイヤとしてコーディングされる場合、num＿layersの値は、num＿sub＿regionの値と等しくてもよい。1つまたは複数のサブ領域が複数のレイヤとしてコーディングされる場合、num＿layersの値は、num＿sub＿regionの値よりも大きくてもよい。シンタックス要素direct＿dependency＿flag［i］［j］は、第jのレイヤから第iのレイヤへの依存性を示す。num＿layers＿for＿region［i］は、第iのサブ領域に関連するレイヤ数を示す。sub＿region＿layer＿id［i］［j］は、第iのサブ領域に関連する第jのレイヤのlayer＿idを示す。sub＿region＿offset＿x［i］およびsub＿region＿offset＿y［i］は、それぞれ、第iのサブ領域の左上隅の水平および垂直位置を示す。sub＿region＿width［i］およびsub＿region＿height［i］は、それぞれ第iのサブ領域の幅および高さを示す。
【0151】
一実施形態では、プロファイル階層レベル情報の有無にかかわらず出力される複数のレイヤのうちの1つを示すように設定された出力レイヤを指定する1つまたは複数のシンタックス要素は、高レベルシンタックス構造、例えば、VPS、DPS、SPS、PPS、APSまたはSEIメッセージでシグナリングされてもよい。図19の例（1900）を参照すると、VPSを参照するコーディング済ビデオシーケンスにおける出力レイヤセット（OLS）の数を示すシンタックス要素num＿output＿layer＿setsは、VPSにおいてシグナリングされてもよい。各出力レイヤセットについて、出力レイヤの数と同じ数だけoutput＿layer＿flagがシグナリングされてもよい。
【0152】
同一または他の実施形態では、1に等しいoutput＿layer＿flag［i］は、第iのレイヤが出力されることを指定する。0と等しいvps＿output＿layer＿flag［i］は、第iのレイヤを出力しないことを指定する。
【0153】
同一および他の実施形態では、各出力レイヤセットのプロファイル階層レベル情報を指定する1つまたは複数のシンタックス要素は、高レベルシンタックス構造、例えばVPS、DPS、SPS、PPS、APSまたはSEIメッセージでシグナリングされてもよい。さらに図19を参照すると、VPSを参照するコーディング済ビデオシーケンス内のOLSごとのプロファイル階層レベル情報の数を示すシンタックス要素num＿profile＿tile＿levelは、VPSでシグナリングされてもよい。各出力レイヤセットについて、プロファイル階層レベル情報のシンタックス要素のセット、またはプロファイル階層レベル情報内のエントリの中の特定のプロファイル階層レベル情報を示すインデックスは、出力レイヤの数と同じ数だけシグナリングされてもよい。
【0154】
同一および他の実施形態では、profile＿tier＿level＿idx［i］［j］は、VPS内のprofile＿tier＿level（）シンタックス構造のリスト内で、第iのOLSの第jのレイヤに適用されるprofile＿tier＿level（）シンタックス構造のインデックスを指定する。
【0155】
同一および他の実施形態では、図20の例（2000）を参照すると、シンタックス要素num＿profile＿tile＿levelおよび／またはnum＿output＿layer＿setsは、最大レイヤ数が1より大きい（vps＿max＿layers＿minus1＞0）場合にシグナリングされてもよい。
【0156】
同一および他の実施形態では、図20を参照すると、第iの出力レイヤセットについての出力レイヤシグナリングのモードを示すシンタックス要素vps＿output＿layers＿mode［i］がVPS内に存在してもよい。
【0157】
同一または他の実施形態では、0に等しいvps＿output＿layers＿mode［i］は、第iの出力レイヤセットで最上位レイヤのみが出力されることを指定する。1に等しいvps＿output＿layer＿mode［i］は、すべてのレイヤが第iの出力レイヤセットで出力されることを指定する。2に等しいvps＿output＿layer＿mode［i］は、出力されるレイヤが、第iの出力レイヤが設定された1に等しいvps＿output＿layer＿flag［i］［j］を有するレイヤであることを指定する。実施形態によれば、より多くの値が予約されてもよい。
【0158】
同一または他の実施形態では、出力＿layer＿flag［i］［j］は、第iの出力レイヤセットのvps＿output＿layers＿mode［i］の値に応じてシグナリングされてもされなくてもよい。
【0159】
同一および他の実施形態では、図20を参照すると、第iの出力レイヤセットについてフラグvps＿ptl＿signal＿flag［i］が存在してもよい。vps＿ptl＿signal＿flag［i］の値を省略すると、第iの出力レイヤセットのプロファイル階層レベル情報はシグナリングされてもされなくてもよい。
【0160】
同一および他の実施形態では、図21を参照すると、現在のCVS内のサブ画像の数max＿subpics＿minus1は、例えばVPS、DPS、SPS、PPS、APSまたはSEIメッセージなどの高レベルシンタックス構造でシグナリングされてもよい。
【0161】
同一および他の実施形態では、図21を参照すると、サブ画像の数が1より大きい（max＿subpics＿minus1＞0）場合、第iのサブ画像のサブ画像識別子sub＿pic＿id［i］がシグナリングされてもよい。
【0162】
同一および他の実施形態では、各出力レイヤセットの各レイヤに属するサブ画像識別子を示す1つまたは複数のシンタックス要素は、VPSでシグナリングされてもよい。図21を参照すると、sub＿pic＿id＿layer［i］［j］［k］は、第iの出力レイヤセットの第jのレイヤに存在する第kのサブ画像を示す。これらの情報を用いて、デコーダは、特定の出力レイヤセットのレイヤごとにどのサブ画像がデコードされて出力されてもよいかを認識することができる。
【0163】
同一および他の実施形態では、以下のシンタックス要素を使用して、レイヤ間または単一レイヤ内のサブ画像のレイアウトを定義することができる。サブ画像分割を有する出力レイヤセットは、VPSまたはSPSのプロファイル／階層／レイヤ情報でシグナリングされてもよい。PPSでは、画像サイズが参照画像再サンプリングによって更新される場合、サブ画像の更新されたレイアウト情報が存在してもよい。VPSの場合、表2を考慮することができる。
【0164】
【表2A】
【表2B】
【0165】
例示的な実施形態によれば、1に等しい表2 vps＿sub＿picture＿info＿present＿flagは、サブ画像レイアウトおよび識別子を示すシンタックス要素がVPS内に存在することを指定する。0に等しいvps＿sub＿picture＿info＿present＿flagは、サブ画像レイアウトおよび識別子を示すシンタックス要素がVPS内に存在しないことを指定する。
【0166】
例示的な実施形態によれば、1に等しい表2のvps＿sub＿pic＿id＿present＿flagは、vps＿sub＿pic＿id［i］［j］がVPSに存在することを指定する。0に等しいvps＿sub＿pic＿id＿present＿flagは、vps＿sub＿pic＿id［i］［j］がVPSに存在しないことを指定する。
【0167】
例示的な実施形態によれば、表2 vps＿sub＿pic＿id＿length＿minus1に1を加えたものは、シンタックス要素vps＿sub＿pic＿id［i］［j］を表すために使用されるビット数を指定する。vps＿sub＿pic＿id＿length＿minus1の値は、0～15の範囲とする。存在しない場合、vps＿sub＿pic＿id＿length＿minus1の値は、第iのレイヤについては、Ceil（Log2（Max（2，vps＿num＿sub＿pic＿in＿pic＿minus1［i］＋1）））－1に等しいと推測される。
【0168】
例示的な実施形態によれば、表2 vps＿sub＿pic＿id［i］［j］は、第iのレイヤの第jのサブ画像のサブ画像IDを指定する。vps＿sub＿pic＿id［i］［j］シンタックス要素の長さは、vps＿sub＿pic＿id＿length＿minus1＋1ビットである。存在しない場合、0～vps＿num＿sub＿pic＿in＿pic＿minus1［i］の範囲の各jについて、vps＿sub＿pic＿id［i］［j］はjと等しいと推測される。
【0169】
例示的な実施形態によれば、表2 vps＿pic＿width＿max＿in＿luma＿samples［i］は、第iのレイヤの各デコード済画像の輝度サンプル単位の最大幅を指定する。pic＿width＿max＿in＿luma＿samplesは0に等しくないものとし、MinCbSizeYの整数倍であるものとする。
【0170】
例示的な実施形態によれば、表2 pic＿height＿max＿in＿luma＿samplesは、SPSを参照する各デコード済画像の輝度サンプル単位の最大高さを指定する。pic＿height＿max＿in＿luma＿samplesは0に等しくないものとし、MinCbSizeYの整数倍であるものとする。
【0171】
例示的な実施形態によれば、表2 vps＿sub＿pic＿offset＿x＿in＿luma＿samples［i］［j］は、合成画像の左上隅輝度サンプルに対する第iのレイヤの第jのサブ画像の左上隅輝度サンプルの、輝度サンプル単位の水平オフセットを指定する。存在しない場合、vps＿sub＿pic＿offset＿x＿in＿luma＿samples［i］［j］の値は0に等しいと推測される。vps＿sub＿pic＿offset＿x＿in＿luma＿samples［i］［j］はCTBサイズの整数倍であるものとする。
【0172】
例示的な実施形態によれば、表2 vps＿sub＿pic＿offset＿y＿in＿luma＿samples［i］［j］は、合成画像の左上隅輝度サンプルに対する第iのレイヤの第jのサブ画像の左上隅輝度サンプルの、輝度サンプル単位の垂直オフセットを指定する。存在しない場合、vps＿sub＿pic＿offset＿y＿in＿luma＿samples［i］［j］の値は0に等しいと推測される。vps＿sub＿pic＿offset＿y＿in＿luma＿samples［i］［j］はCTBサイズの整数倍であるものとする。
【0173】
例示的な実施形態によれば、表2 vps＿sub＿pic＿width＿in＿luma＿samples［i］［j］は、第iのレイヤの第jのサブ画像の幅を輝度サンプル単位で指定する。vps＿sub＿pic＿width＿in＿luma＿samples［i］［j］は、CTBサイズの整数倍であるものとする。
【0174】
例示的な実施形態によれば、表2 vps＿sub＿pic＿height＿in＿luma＿samples［i］［j］は、第iのレイヤの第jサブ画像の高さを輝度サンプルの単位で指定する。vps＿sub＿pic＿height＿in＿luma＿samples［i］［j］は、CTBサイズの整数倍であるものとする。
【0175】
例示的な実施形態によれば、表2 vps＿num＿output＿layer＿sets＿minus1に1を加えたものは、VPSを参照するコーディング済ビデオシーケンス内に設定された出力レイヤの数を指定する。存在しない場合、vps＿num＿output＿layer＿sets＿minus1の値は0に等しいと推測される。
【0176】
例示的な実施形態によれば、表2 vps＿num＿profile＿tile＿levels＿minus1に1を加えたものは、VPSを参照するコーディング済ビデオシーケンス内のプロファイル／階層／レベル情報の数を指定する。存在しない場合、vps＿num＿profile＿tile＿levels＿minus1の値は0に等しいと推測される。
【0177】
例示的な実施形態によれば、0に等しい表2 vps＿output＿layers＿mode［i］は、第iの出力レイヤセットにおいて最上位レイヤのみが出力されることを指定する。1に等しいvps＿output＿layer＿mode［i］は、第iの出力レイヤセットにおいてすべてのレイヤが出力されることを指定する。2に等しいvps＿output＿layer＿mode［i］は、出力されるレイヤが、第iの出力レイヤセットにおいてvps＿output＿layer＿flag［i］［j］が1に等しいレイヤであることを指定する。vps＿output＿layers＿mode［i］の値は、0～2の範囲とする。vps＿output＿layer＿mode［i］の値3は、ITU－T｜ISO／IECによる将来の使用のために予約されている。
【0178】
例示的な実施形態によれば、表2 vps＿num＿output＿subpic＿layer＿minus1［i］［j］は、第iの出力レイヤセットの第jのレイヤのサブ画像の数を指定する。
【0179】
例示的な実施形態によれば、表2 vps＿sub＿pic＿id＿layer［i］［j］［k］は、第iのレイヤの第jのサブ画像の第kの出力サブ画像のサブ画像IDを指定する。vps＿sub＿pic＿id＿layer［i］［j］［k］シンタックス要素の長さは、vps＿sub＿pic＿id＿length＿minus1＋1ビットである。存在しない場合、0～num＿output＿subpic＿layer＿minus1［i］［j］の範囲の各jについて、vps＿sub＿pic＿id＿layer［i］［j］［k］はkと等しいと推測される。
【0180】
例示的な実施形態によれば、1に等しい表2 vps＿output＿layer＿flag［i］［j］は、第iの出力レイヤセットの第jのレイヤが出力されることを指定する。0に等しいvps＿output＿layer＿flag［i］［j］は、第iの出力レイヤセットの第jのレイヤが出力されないことを指定する。
【0181】
例示的な実施形態によれば、表2 vps＿profile＿tier＿level＿idx［i］［j］は、第iの出力レイヤセットの第jのレイヤに適用されるprofile＿tier＿level（）シンタックス構造の、VPS内のprofile＿tier＿level（）シンタックス構造のリストへのインデックスを指定する。
【0182】
SPSの場合、表3を考慮することができる。
【0183】
【表3A】
【表3B】
【0184】
例示的な実施形態によれば、表3 pic＿width＿max＿in＿luma＿samplesは、SPSを参照する各デコード済画像の輝度サンプル単位の最大幅を指定する。pic＿width＿max＿in＿luma＿samplesは0に等しくないものとし、MinCbSizeYの整数倍であるものとする。
【0185】
例示的な実施形態によれば、表3 pic＿height＿max＿in＿luma＿samplesは、SPSを参照する各デコード済画像の輝度サンプル単位の最大高さを指定する。pic＿height＿max＿in＿luma＿samplesは0に等しくないものとし、MinCbSizeYの整数倍であるものとする。
【0186】
例示的な実施形態によれば、1に等しい表3のsubpics＿present＿flagは、サブ画像パラメータがSPS RBSPシンタックスに存在することを示す。0に等しいsubpics＿present＿flagは、サブ画像パラメータがSPS RBSPシンタックスに存在しないことを示す。
【0187】
例示的な実施形態によれば、ビットストリームがサブビットストリーム抽出プロセスの結果であり、サブビットストリーム抽出プロセスへの入力ビットストリームのサブ画像のサブセットのみを含む場合、SPSのRBSPにおいてsubpics＿present＿flagの値を1に等しく設定することが必要かもしれない。
【0188】
例示的な実施形態によれば、1に等しい表3のsps＿sub＿pic＿id＿present＿flagは、sps＿sub＿pic＿id［i］がSPSに存在することを指定し、0に等しいsps＿sub＿pic＿id＿present＿flagは、sps＿sub＿pic＿id［i］がSPSに存在しないことを指定する。
【0189】
例示的な実施形態によれば、表3 sps＿sub＿pic＿id＿length＿minus1に1を加えたものは、シンタックス要素sps＿sub＿pic＿id［i］［j］を表すために使用されるビット数を指定する。sps＿sub＿pic＿id＿length＿minus1の値は、0～15の範囲とする。存在しない場合、sps＿sub＿pic＿id＿length＿minus1の値は、Ceil（Log2（Max（2，sps＿num＿sub＿pic＿in＿pic＿minus1＋1）））－1に等しいと推測される。
【0190】
例示的な実施形態によれば、表3 sps＿sub＿pic＿id［i］は、第iのサブ画像のサブ画像IDを指定する。sps＿sub＿pic＿id［i］シンタックス要素の長さは、sps＿sub＿pic＿id＿length＿minus1＋1ビットである。存在しない場合、0～sps＿num＿sub＿pic＿in＿pic＿minus1の範囲の各iについて、sps＿sub＿pic＿id［i］はiと等しいと推測される。
【0191】
例示的な実施形態によれば、表3 sps＿sub＿pic＿offset＿x＿in＿luma＿samples［i］は、合成画像の左上隅輝度サンプルに対する第iのサブ画像の左上隅輝度サンプルの、輝度サンプル単位の水平オフセットを指定する。存在しない場合、sps＿sub＿pic＿offset＿x＿in＿luma＿samples［i］の値は0に等しいと推測される。sps＿sub＿pic＿offset＿x＿in＿luma＿samples［i］はCTBサイズの整数倍であるものとする。
【0192】
例示的な実施形態によれば、表3 sps＿sub＿pic＿offset＿y＿in＿luma＿samples［i］は、合成画像の左上隅輝度サンプルに対する第iのサブ画像の左上隅輝度サンプルの、輝度サンプル単位の垂直オフセットを指定する。存在しない場合、sps＿sub＿pic＿offset＿y＿in＿luma＿samples［i］の値は0に等しいと推測される。sps＿sub＿pic＿offset＿y＿in＿luma＿samples［i］はCTBサイズの整数倍であるものとする。
【0193】
例示的な実施形態によれば、表3 sps＿sub＿pic＿width＿in＿luma＿samples［i］は、輝度サンプルの単位で第iのサブ画像の幅を指定する。sps＿sub＿pic＿width＿in＿luma＿samples［i］はCTBサイズの整数倍であるものとする。
【0194】
例示的な実施形態によれば、表3 sps＿sub＿pic＿height＿in＿luma＿samples［i］は、輝度サンプルの単位で第iのサブ画像の高さを指定する。sps＿sub＿pic＿height＿in＿luma＿samples［i］はCTBサイズの整数倍であるものとする。
【0195】
例示的な実施形態によれば、表3 sps＿num＿output＿subpic＿sets＿minus1 plus 1は、SPSを参照するコーディング済ビデオシーケンス内の出力サブ画像セットの数を指定する。存在しない場合、sps＿num＿output＿layer＿sets＿minus1の値は0に等しいと推測される。
【0196】
例示的な実施形態によれば、表3 sps＿num＿output＿subpic＿minus1［i］は、第iの出力サブ画像セットのサブ画像の数を指定する。
【0197】
例示的な実施形態によれば、表3 sps＿sub＿pic＿id＿oss［i］［j］は、第iのサブ画像の第jの出力サブ画像のサブ画像IDを指定する。sps＿sub＿pic＿id＿oss［i］［j］シンタックス要素の長さは、sps＿sub＿pic＿id＿length＿minus1＋1ビットである。存在しない場合、0～sps＿num＿output＿subpic＿minus1［i］の範囲の各iについて、sps＿sub＿pic＿id＿oss［i］［j］はjと等しいと推測される。
【0198】
PPSの場合、表4を考慮することができる。
【0199】
【表4】
【0200】
例示的な実施形態によれば、1に等しい表4のsubpics＿updated＿flagは、PPS内の更新されたサブ画像レイアウト情報を示すシンタックス要素によってサブ画像のレイアウト情報が更新されることを指定し、0に等しいsubpics＿updated＿flagは、サブ画像のレイアウト情報が更新されないことを指定する。
【0201】
例示的な実施形態によれば、1に等しい表4 pps＿sub＿pic＿id＿present＿flagは、pps＿sub＿pic＿id［i］がPPSに存在することを指定し、0に等しいsps＿sub＿pic＿id＿present＿flagは、pps＿sub＿pic＿id［i］がPPSに存在しないことを指定する。
【0202】
例示的な実施形態によれば、表4 pps＿sub＿pic＿id＿length＿minus1に1を加えたものは、シンタックス要素pps＿sub＿pic＿id［i］［j］を表すために使用されるビット数を指定する。pps＿sub＿pic＿id＿length＿minus1の値は、0～15の範囲とする。存在しない場合、pps＿sub＿pic＿id＿length＿minus1の値は、Ceil（Log2（Max（2，pps＿num＿sub＿pic＿in＿pic＿minus1＋1）））－1に等しいと推測される。
【0203】
例示的な実施形態によれば、表4 pps＿sub＿pic＿id［i］は、第iのサブ画像のサブ画像IDを指定する。pps＿sub＿pic＿id［i］シンタックス要素の長さは、sps＿sub＿pic＿id＿length＿minus1＋1ビットである。存在しない場合、0～pps＿num＿sub＿pic＿in＿pic＿minus1の範囲の各iについて、pps＿sub＿pic＿id［i］はiと等しいと推測される。
【0204】
例示的な実施形態によれば、表4 pps＿sub＿pic＿offset＿x＿in＿luma＿samples［i］は、合成画像の左上隅輝度サンプルに対する第iのサブ画像の左上隅輝度サンプルの、輝度サンプル単位の水平オフセットを指定する。存在しない場合、pps＿sub＿pic＿offset＿x＿in＿luma＿samples［i］の値は0に等しいと推測される。pps＿sub＿pic＿offset＿x＿in＿luma＿samples［i］はCTBサイズの整数倍であるものとする。
【0205】
例示的な実施形態によれば、表4 pps＿sub＿pic＿offset＿y＿in＿luma＿samples［i］は、合成画像の左上隅輝度サンプルに対する第iのサブ画像の左上隅輝度サンプルの、輝度サンプル単位の垂直オフセットを指定する。存在しない場合、sps＿sub＿pic＿offset＿y＿in＿luma＿samples［i］の値は0に等しいと推測される。sps＿sub＿pic＿offset＿y＿in＿luma＿samples［i］はCTBサイズの整数倍であるものとする。
【0206】
例示的な実施形態によれば、表4 pps＿sub＿pic＿width＿in＿luma＿samples［i］は、輝度サンプルの単位で第iのサブ画像の幅を指定する。pps＿sub＿pic＿width＿in＿luma＿samples［i］は、CTBサイズの整数倍であるものとする。
【0207】
例示的な実施形態によれば、表4 pps＿sub＿pic＿height＿in＿luma＿samples［i］は、輝度サンプルの単位で第iのサブ画像の高さを指定する。pps＿sub＿pic＿height＿in＿luma＿samples［i］は、CTBサイズの整数倍であるものとする。
【0208】
例示的な実施形態によれば、表4 pps＿num＿output＿subpic＿sets＿minus1 plus 1は、PPSを参照する画像内の出力サブ画像セットの数を指定する。存在しない場合、pps＿num＿output＿layer＿sets＿minus1の値は0に等しいと推測される。
【0209】
例示的な実施形態によれば、表4 pps＿num＿output＿subpic＿minus1［i］は、第iの出力サブ画像セットのサブ画像の数を指定する。
【0210】
例示的な実施形態によれば、表4 pps＿sub＿pic＿id＿oss［i］［j］は、第iのサブ画像の第jの出力サブ画像のサブ画像IDを指定する。pps＿sub＿pic＿id＿oss［i］［j］シンタックス要素の長さは、pps＿sub＿pic＿id＿length＿minus1＋1ビットである。存在しない場合、0～pps＿num＿output＿subpic＿minus1［i］の範囲の各iについて、pps＿sub＿pic＿id＿oss［i］［j］はjと等しいと推測される。
【0211】
上記の適応的解像度パラメータをシグナリングするための技術は、コンピュータ可読命令を使用してコンピュータソフトウェアとして実装され、1つまたは複数のコンピュータ可読媒体に物理的に格納され得る。例えば、図7は、開示された主題の特定の実施形態を実施するのに適したコンピュータシステム（700）を示す。
【0212】
コンピュータソフトウェアは、コンピュータ中央処理ユニット（CPU）、グラフィックス処理ユニット（GPU）などにより、アセンブリ、コンパイル、リンク、または同様の機構の対象となり得、直接に、または翻訳、マイクロコードの実行などを通じて実行され得る命令を含むコードを作成することができる、任意の適切なマシンコードまたはコンピュータ言語を使用してコーディングすることができる。
【0213】
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットデバイスなどを含む、様々なタイプのコンピュータまたはその構成要素上で実行することができる。
【0214】
コンピュータシステム（700）について図7に示す構成要素は、本質的に例示的なものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用または機能の範囲に関する制限を示唆することを意図するものではない。また、構成要素の構成は、コンピュータシステム（700）の例示的な実施形態に示されている構成要素のいずれか1つまたは組み合わせに関する依存性または要件を有するものとして解釈されるべきではない。
【0215】
コンピュータシステム（700）は、特定のヒューマンインターフェース入力デバイスを含むことができる。そのようなヒューマンインターフェース入力デバイスは、例えば、触覚入力（キーストローク、スワイプ、データグローブの動きなど）、オーディオ入力（音声、拍手など）、視覚入力（ジェスチャーなど）、嗅覚入力（図示せず）による、1人または複数の人間ユーザによる入力に応答することができる。ヒューマンインターフェースデバイスを使用して、音声（スピーチ、音楽、環境音など）、画像（スキャンされた画像、静止画像カメラから得られる写真画像など）、ビデオ（2次元ビデオ、立体ビデオを含む3次元ビデオなど）などの人間による意識的な入力に必ずしも直接関係しない特定のメディアをキャプチャすることもできる。
【0216】
入力ヒューマンインターフェースデバイスは、キーボード（701）、マウス（702）、トラックパッド（703）、タッチスクリーン（710）、ジョイスティック（705）、マイク（706）、スキャナ（707）、カメラ（708）のうちの1つまたは複数（各1つのみを表示）を含むことができる。
【0217】
コンピュータシステム（700）はまた、特定のヒューマンインターフェース出力デバイスを含むことができる。そのようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音、光、および嗅覚／味覚を通じて、1人または複数の人間のユーザの感覚を刺激することができる。このようなヒューマンインターフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン（710）またはジョイスティック（705）による触覚フィードバックであるが、入力デバイスとして機能しない触覚フィードバックデバイスもあり得る）、オーディオ出力デバイス（スピーカ（709）、ヘッドフォン（図示せず）など）、視覚出力デバイス（CRT画面、LCD画面、プラズマ画面、OLED画面を含む画面（710）などであって、それぞれタッチスクリーン入力機能の有無にかかわらず、また触覚フィードバック機能の有無にかかわらず、－これらの一部は、ステレオグラフィック出力、仮想現実眼鏡（図示せず）、ホログラフィックディスプレイ、およびスモークタンク（図示せず）などの手段を介して、2次元の視覚的出力または3次元を超える出力を出力することができる）、ならびにプリンタ（図示せず）を含むことができる。
【0218】
コンピュータシステム（700）はまた、CD／DVDまたは同様の媒体（721）を備えたCD／DVD ROM／RW（720）を含む光学メディア、サムドライブ（7220、取り外し可能なハードドライブまたはソリッドステートドライブ（723）、テープおよびフロッピーディスク（図示せず）などの従来の磁気媒体、セキュリティドングル（図示せず）などの専用のROM／ASIC／PLDベースのデバイスなどの、人間がアクセス可能な記憶装置および関連メディアを含むことができる。
【0219】
当業者はまた、ここで開示される主題に関連して使用される「コンピュータ可読媒体」という用語は、伝送媒体、搬送波、または他の一時的な信号を包含しないことを理解するべきである。
【0220】
コンピュータシステム（700）は、1つまたは複数の通信ネットワークへのインターフェースも含むことができる。ネットワークは、例えば、無線、有線、光であり得る。さらに、ネットワークは、ローカル、広域、大都市圏、車両および産業、リアルタイム、遅延耐性などであり得る。ネットワークの例には、イーサネット、無線LANなどのローカルエリアネットワーク、GSM、3G、4G、5G、LTEなどを含むセルラーネットワーク、ケーブルTV、衛星TV、および地上波放送TVを含むテレビ有線または無線広域デジタルネットワーク、CANBusを含む車両および産業用などが含まれる。特定のネットワークでは、一般に、特定の汎用データポートまたは周辺バス（749）（例えばコンピュータシステム（700）のUSBポートなど）に接続された外部ネットワークインターフェースアダプタが必要であり、その他のネットワークは、一般に、後述するようにシステムバスへの取り付けによりコンピュータシステム（700）のコアに統合されている（例えば、PCコンピュータシステムへのイーサネットインターフェースまたはスマートフォンコンピュータシステムへのセルラーネットワークインターフェース）。これらのネットワークのいずれかを使用して、コンピュータシステム（700）は、他のエンティティと通信することができる。このような通信は、単方向、受信のみ（例えば、放送TV）、単方向送信のみ（例えば、CANbusから特定のCANbusデバイス）、または双方向、例えば、ローカルエリアまたはワイドエリアデジタルネットワークを使用する他のコンピュータシステムへの通信であり得る。上記のように、特定のプロトコルとプロトコルスタックは、これらのネットワークとネットワークインターフェースのそれぞれで使用することができる。
【0221】
前述のヒューマンインターフェースデバイス、ヒューマンアクセス可能な記憶装置、およびネットワークインターフェースは、コンピュータシステム（700）のコア（740）に取り付けることができる。
【0222】
コア（740）は、1つまたは複数の中央処理装置（CPU）（741）、グラフィック処理装置（GPU）（742）、フィールドプログラマブルゲートエリア（FPGA）（743）の形態の専用プログラマブル処理装置、特定のタスク用のハードウェアアクセラレータ（744）などを含むことができる。これらのデバイスは、読取り専用メモリ（ROM）（745）、ランダムアクセスメモリ（746）、ユーザがアクセスできない内部ハードドライブ、SSD（747）などの内部大容量記憶装置と共に、システムバス（748）を介して接続されてもよい。一部のコンピュータシステムでは、システムバス（748）は1つまたは複数の物理プラグの形でアクセスでき、追加のCPU、GPUなどによる拡張を可能にする。周辺機器は、コアのシステムバス（748）に直接、または周辺バス（749）を介して接続することができる。周辺バスのアーキテクチャには、PCI、USBなどが含まれる。
【0223】
CPU（741）、GPU（742）、FPGA（743）、およびアクセラレータ（744）は、組み合わせて上述のコンピュータコードを構成することができる特定の命令を実行することができる。そのコンピュータコードは、ROM（745）またはRAM（746）に格納することができる。移行データはまた、RAM（746）に格納することができ、一方、永続データは、例えば内部大容量記憶装置（747）に格納することができる。メモリデバイスのいずれかへの高速記憶および検索は、1つまたは複数のCPU（741）、GPU（742）、大容量記憶装置（747）、ROM（745）、RAM（746）などと密接に関連付けることができるキャッシュメモリの使用によって可能にすることができる。
【0224】
コンピュータ可読媒体は、様々なコンピュータ実施動作を実行するためのコンピュータコードをその上に有することができる。メディアおよびコンピュータコードは、本開示の目的のために特別に設計および構築されたものであり得るか、またはそれらは、コンピュータソフトウェア技術の当業者に周知であり利用可能な種類のものであり得る。
【0225】
限定ではなく例として、アーキテクチャ、具体的にはコア（740）を有するコンピュータシステム（700）は、1つまたは複数の有形のコンピュータ可読媒体に組み込まれたソフトウェアを実行するプロセッサ（CPU、GPU、FPGA、アクセラレータなどを含む）の結果として機能を提供することができる。そのようなコンピュータ可読媒体は、上で紹介されたようなユーザがアクセス可能な大容量記憶装置、ならびにコア内部大容量記憶装置（747）またはROM（745）などの非一時的な性質のコア（740）の特定の記憶装置に関連する媒体であり得る。本開示の様々な実施形態を実装するソフトウェアは、そのようなデバイスに格納され、コア（740）によって実行され得る。コンピュータ可読媒体は、特定のニーズに従って、1つまたは複数のメモリデバイスまたはチップを含むことができる。ソフトウェアは、コア（740）および具体的にはその中のプロセッサ（CPU、GPU、FPGAなどを含む）に、ソフトウェアで定義されたプロセスに従ってRAM（746）に格納されているデータ構造の定義やそのようなデータ構造の変更など、ここで説明する特定のプロセスまたは特定のプロセスの特定の部分を実行させることができる。加えて、または代替例として、コンピュータシステムは、ハードウェアに組み込まれた、または回路（例えばアクセラレータ（744））に組み込まれたロジックの結果として、ここで説明する特定のプロセスまたは特定のプロセスの特定の部分を実行するソフトウェアの代わりにまたは一緒に動作できる機能を提供することができる。ソフトウェアへの言及はロジックを含むことができ、妥当な場合には、その逆も可能である。コンピュータ可読媒体への言及は、実行のためのソフトウェア、実行のためのロジックを具体化する回路、または妥当な場合には、その両方を格納する回路（集積回路（IC）など）を包含することができる。本開示は、ハードウェアとソフトウェアの任意の適切な組み合わせを包含する。
【0226】
本開示はいくつかの例示的な実施形態を説明してきたが、本開示の範囲内にある変更、置換、および様々な代替均等物が存在する。したがって、当業者は、本明細書では明示的に示されていないか、または記載されていないが、本開示の原理を具現化し、したがってその趣旨および範囲内にある多数のシステムおよび方法を考案できることが理解されよう。
【符号の説明】
【0227】
100 通信システム
110 第1の端末
120 第2の端末
130 端末
140 端末
150 通信ネットワーク
201 カメラ／ビデオソース
202 非圧縮ビデオサンプルストリーム
203 ビデオエンコーダ／ビデオソース
204 エンコード済ビデオビットストリーム
205 ストリーミングサーバ
206 ストリーミングクライアント
207 コピー／ビデオビットストリーム
208 ストリーミングクライアント
209 コピー／ビデオビットストリーム
210 ビデオデコーダ
211 発信ビデオサンプルストリーム
212 ディスプレイ／レンダリングデバイス
213 キャプチャサブシステム
310 受信機
312 チャネル
315 バッファメモリ
320 エントロピーデコーダ／パーサ
321 シンボル
351 スケーラ／逆変換ユニット
352 イントラ画像予測ユニット
353 動き補償予測ユニット
355 アグリゲータ
356 ループフィルタユニット／参照画像メモリ
357 参照画像メモリ
430 ソースコーダ／ビデオコーダ
432 コーディングエンジン
433 ローカルビデオデコーダ
434 参照画像メモリ
435 予測器
440 送信機
443 コーディング済ビデオシーケンス
445 エントロピーコーダ
450 コントローラ
460 通信チャネル
500A 図
500B 図
500C 例
500D 例
501 画像ヘッダ
502 ARC情報
504 画像パラメータセット
505 ARC参照情報
506 ターゲットResテーブル情報
507 シーケンスパラメータセット
508 タイルグループヘッダ情報
509 ARC情報
511 適応パラメータセット（APS）情報
512 ARC情報
513 ARC参照情報
514 タイルグループヘッダ情報
515 ARC情報
516 SPS情報
600 表現
601 タイルグループヘッダ
602 シンタックス要素
603 適応的解像度
610 シーケンスパラメータセット
611 シンタックス要素
612 パラメータセット
613 サンプル
614 シンタックス要素
615 参照画像次元
616 テーブル表示
617 テーブルエントリ
700 コンピュータシステム
701 キーボード
702 マウス
703 トラックパッド
705 ジョイスティック
706 マイク
707 スキャナ
708 カメラ
709 スピーカ
710 タッチスクリーン
721 媒体
722 サムドライブ
723 ソリッドステートドライブ
740 コア
743 フィールドプログラマブルゲートエリア（FPGA）
744 ハードウェアアクセラレータ
745 読取り専用メモリ（ROM）
746 ランダムアクセスメモリ
747 内部大容量記憶装置
748 システムバス
749 周辺バス
1000 ワークフロー
1100 ビデオストリーム
1200 ビデオ会議
1300 図
1400 ユースケース
1600 拡張ケース
1700 シンタックス要素の例
1800 シンタックス要素の例
1900 図19の例
2000 図20の例
110 第1の端末
120 第2の端末
130 端末
140 端末
150 通信ネットワーク
201 カメラ／ビデオソース
202 非圧縮ビデオサンプルストリーム
203 ビデオエンコーダ／ビデオソース
204 エンコード済ビデオビットストリーム
205 ストリーミングサーバ
206 ストリーミングクライアント
207 コピー／ビデオビットストリーム
208 ストリーミングクライアント
209 コピー／ビデオビットストリーム
210 ビデオデコーダ
211 発信ビデオサンプルストリーム
212 ディスプレイ／レンダリングデバイス
213 キャプチャサブシステム
310 受信機
312 チャネル
315 バッファメモリ
320 エントロピーデコーダ／パーサ
321 シンボル
351 スケーラ／逆変換ユニット
352 イントラ画像予測ユニット
353 動き補償予測ユニット
355 アグリゲータ
356 ループフィルタユニット／参照画像メモリ
357 参照画像メモリ
430 ソースコーダ／ビデオコーダ
432 コーディングエンジン
433 ローカルビデオデコーダ
434 参照画像メモリ
435 予測器
440 送信機
443 コーディング済ビデオシーケンス
445 エントロピーコーダ
450 コントローラ
460 通信チャネル
500A 図
500B 図
500C 例
500D 例
501 画像ヘッダ
502 ARC情報
504 画像パラメータセット
505 ARC参照情報
506 ターゲットResテーブル情報
507 シーケンスパラメータセット
508 タイルグループヘッダ情報
509 ARC情報
511 適応パラメータセット（APS）情報
512 ARC情報
513 ARC参照情報
514 タイルグループヘッダ情報
515 ARC情報
516 SPS情報
600 表現
601 タイルグループヘッダ
602 シンタックス要素
603 適応的解像度
610 シーケンスパラメータセット
611 シンタックス要素
612 パラメータセット
613 サンプル
614 シンタックス要素
615 参照画像次元
616 テーブル表示
617 テーブルエントリ
700 コンピュータシステム
701 キーボード
702 マウス
703 トラックパッド
705 ジョイスティック
706 マイク
707 スキャナ
708 カメラ
709 スピーカ
710 タッチスクリーン
721 媒体
722 サムドライブ
723 ソリッドステートドライブ
740 コア
743 フィールドプログラマブルゲートエリア（FPGA）
744 ハードウェアアクセラレータ
745 読取り専用メモリ（ROM）
746 ランダムアクセスメモリ
747 内部大容量記憶装置
748 システムバス
749 周辺バス
1000 ワークフロー
1100 ビデオストリーム
1200 ビデオ会議
1300 図
1400 ユースケース
1600 拡張ケース
1700 シンタックス要素の例
1800 シンタックス要素の例
1900 図19の例
2000 図20の例
【図1】
【図2】
【図3】
【図4】
【図5A】
【図5B】
【図5C】
【図5D】
【図5E】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【外国語明細書】