特開2023-179667参照ピクチャ・リサンプリングをリサンプリング・ピクチャ・サイズ指示とともにビデオ・ビットストリームでシグナリングすること
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023179667
(43)【公開日】2023-12-19
(54)【発明の名称】参照ピクチャ・リサンプリングをリサンプリング・ピクチャ・サイズ指示とともにビデオ・ビットストリームでシグナリングすること
(51)【国際特許分類】
H04N 19/59 20140101AFI20231212BHJP
H04N 19/70 20140101ALI20231212BHJP
H04N 19/503 20140101ALI20231212BHJP
【ＦＩ】
H04N19/59
H04N19/70
H04N19/503
【審査請求】有
【請求項の数】1
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2023176370
(22)【出願日】2023-10-12
(62)【分割の表示】P 2021564819の分割
【原出願日】2020-09-10
(31)【優先権主張番号】62/903,639
(32)【優先日】2019-09-20
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】62/905,319
(32)【優先日】2019-09-24
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】17/010,163
(32)【優先日】2020-09-02
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】チョイ，ビョンドゥ
(72)【発明者】
【氏名】ウェンジャー，ステファン
(72)【発明者】
【氏名】リィウ，シャン
(57)【要約】 （修正有）
【課題】ビデオ・ビットストリームを復号化する方法、装置及びコンピュータ読み取り可能な媒体における参照ピクチャ・リサンプリング方法を提供する。
【解決手段】方法は、現在のピクチャにコンフォーマンス・ウィンドウが存在することを示す第1フラグを取得し、第1フラグに基づいて、コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されるかどうかを示す第2フラグを取得し、第2フラグがコンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されることを示す場合は、現在のピクチャ及び参照ピクチャの間のリサンプリング比率を、コンフォーマンス・ウィンドウ・サイズに基づいて決定し、第2フラグがコンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されないことを示す場合は、リサンプリング比率をリサンプリング・ピクチャ・サイズに基づいて決定する。
【選択図】図１０
【解決手段】方法は、現在のピクチャにコンフォーマンス・ウィンドウが存在することを示す第1フラグを取得し、第1フラグに基づいて、コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されるかどうかを示す第2フラグを取得し、第2フラグがコンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されることを示す場合は、現在のピクチャ及び参照ピクチャの間のリサンプリング比率を、コンフォーマンス・ウィンドウ・サイズに基づいて決定し、第2フラグがコンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されないことを示す場合は、リサンプリング比率をリサンプリング・ピクチャ・サイズに基づいて決定する。
【選択図】図１０
【特許請求の範囲】
【請求項1】
少なくとも1つのプロセッサを利用して、符号化されたビデオ・ビットストリームを復号化する方法であって、
現在のピクチャにコンフォーマンス・ウィンドウが存在することを示す第1フラグを取得するステップと、
前記コンフォーマンス・ウィンドウが存在することを示す前記第1フラグに基づいて、前記コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されるかどうかを示す第2フラグを取得するステップと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されることを示す前記第2フラグに基づいて、前記現在のピクチャ及び参照ピクチャの間のリサンプリング比率を、前記コンフォーマンス・ウィンドウのコンフォーマンス・ウィンドウ・サイズに基づいて決定するステップと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されないことを示す前記第2フラグに基づいて、前記リサンプリング比率をリサンプリング・ピクチャ・サイズに基づいて決定するステップと、
前記リサンプリング比率を利用して、前記現在のピクチャに対する前記参照ピクチャ・リサンプリングを実行するステップと
を含む方法。
現在のピクチャにコンフォーマンス・ウィンドウが存在することを示す第1フラグを取得するステップと、
前記コンフォーマンス・ウィンドウが存在することを示す前記第1フラグに基づいて、前記コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されるかどうかを示す第2フラグを取得するステップと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されることを示す前記第2フラグに基づいて、前記現在のピクチャ及び参照ピクチャの間のリサンプリング比率を、前記コンフォーマンス・ウィンドウのコンフォーマンス・ウィンドウ・サイズに基づいて決定するステップと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されないことを示す前記第2フラグに基づいて、前記リサンプリング比率をリサンプリング・ピクチャ・サイズに基づいて決定するステップと、
前記リサンプリング比率を利用して、前記現在のピクチャに対する前記参照ピクチャ・リサンプリングを実行するステップと
を含む方法。
【発明の詳細な説明】
【背景技術】
【0001】
関連出願の相互参照
本願は、2019年9月20日付で出願された米国仮出願第62/903,639号、2019年9月24日付で出願された米国仮出願第62/905,319号、及び2020年9月2日付で出願された米国特許出願第17/010,163号に対する優先権を主張しており、それら全体が本願に組み込まれる。
本願は、2019年9月20日付で出願された米国仮出願第62/903,639号、2019年9月24日付で出願された米国仮出願第62/905,319号、及び2020年9月2日付で出願された米国特許出願第17/010,163号に対する優先権を主張しており、それら全体が本願に組み込まれる。
【0002】
技術分野
開示される対象事項は、ビデオ・コーディング及びデコーディング、より具体的には、リサンプリング・ピクチャ・サイズ指示を伴う参照ピクチャ・リサンプリングのシグナリングに関連する。
開示される対象事項は、ビデオ・コーディング及びデコーディング、より具体的には、リサンプリング・ピクチャ・サイズ指示を伴う参照ピクチャ・リサンプリングのシグナリングに関連する。
【0003】
背景技術
動き補償を伴うインター・ピクチャ予測を利用するビデオ・コーディング及びデコーディングが知られている。非圧縮デジタル・ビデオは一連のピクチャから構成することが可能であり、各ピクチャは、例えば1920×1080のルミナンス・サンプル及び関連するクロミナンス・サンプルの空間的な大きさを有する。一連のピクチャは、例えば毎秒60ピクチャ、即ち60Hzという一定の又は可変のピクチャ・レート（非公式に、フレーム・レートとしても知られている）を有する可能性がある。非圧縮ビデオは、かなりのビットレート要件を有する。例えば、サンプル当たり8ビットでの1080p60 4:2:0ビデオ（60Hzフレーム・レートでは1920×1080のルミナンス・サンプル解像度）は、1.5 Gbit/sに近接する帯域幅を必要とする。このようなビデオの1時間は、600Gバイトを超える記憶スペースを必要とする。
動き補償を伴うインター・ピクチャ予測を利用するビデオ・コーディング及びデコーディングが知られている。非圧縮デジタル・ビデオは一連のピクチャから構成することが可能であり、各ピクチャは、例えば1920×1080のルミナンス・サンプル及び関連するクロミナンス・サンプルの空間的な大きさを有する。一連のピクチャは、例えば毎秒60ピクチャ、即ち60Hzという一定の又は可変のピクチャ・レート（非公式に、フレーム・レートとしても知られている）を有する可能性がある。非圧縮ビデオは、かなりのビットレート要件を有する。例えば、サンプル当たり8ビットでの1080p60 4:2:0ビデオ（60Hzフレーム・レートでは1920×1080のルミナンス・サンプル解像度）は、1.5 Gbit/sに近接する帯域幅を必要とする。このようなビデオの1時間は、600Gバイトを超える記憶スペースを必要とする。
【0004】
ビデオ・コーディング及びデコーディングの1つの目的は、圧縮によって入力ビデオ信号の冗長性を低減することである可能性がある。圧縮は、前述の帯域幅又は記憶スペースの要件を、場合によっては、2桁以上減らすことに役立つ可能性がある。ロスレス及び非ロスレス圧縮の両方、並びにそれらの組み合わせを用いることができる。ロスレス圧縮とは、オリジナル信号の正確なコピーが、圧縮されたオリジナル信号から再構成することができる技術をいう。非ロスレス圧縮を使用する場合、再構成された信号は、オリジナル信号と同一ではないかもしれないが、オリジナル信号と再構成された信号との間の歪は、再構成された信号を、意図された用途については有用にできる程度に十分小さい。ビデオの場合、非ロスレス圧縮が広く使用されている。耐え得る歪の量は、アプリケーションに依存し、例えば、特定のコンシューマ・ストリーミング・アプリケーションのユーザーは、テレビジョンが貢献するアプリケーションのユーザーよりも高い歪に耐え得る。達成可能な圧縮比は、より高い許容可能な/耐え得る歪はより高い圧縮比をもたらし得ることを、反映することができる。
【0005】
ビデオ・エンコーダ及びデコーダは、例えば動き補償、変換、量子化、エントロピー・コーディングを含む、幾つもの広範囲に及びカテゴリの技術を利用することができ、その幾つかを以下に紹介する。
【0006】
歴史的には、ビデオ・エンコーダ及びデコーダは所与のピクチャ・サイズで動作する傾向があり、ピクチャ・サイズは、ほとんどの場合、コーディングされたビデオ・シーケンス（CVS）、グループ・オブ・ピクチャ（GOP）、又は類似のマルチ・ピクチャ・タイムフレームに対して定められ且つ一定のままであった。例えば、MPEG-2では、システム設計は、シーンのアクティビティのような要因に依存して水平解像度（従って、ピクチャ・サイズ）を変化させることが知られているが、Iピクチャにおいてのみであり、従って典型的にはGOPに対するものである。CVS内で異なる解像度を使用するための参照ピクチャのリサンプリングは、例えば、ITU-T Rec. H.263AnnexPにより知られている。しかしながら、この場合、ピクチャ・サイズは変わらず、参照ピクチャのみがリサンプリングされ、その結果、（ダウンサンプリングの場合は）ピクチャ・キャンバスの一部分のみが使用されること、又は（アップサンプリングの場合は）シーンの一部分のみが使用されることとなってしまう可能性がある。更に、H.263AnnexQは、個々のマクロブロック（各次元で）を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フラグに基づいて、コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されるかどうかを示す第2フラグを取得するステップと、コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されることを示す第2フラグに基づいて、現在のピクチャ及び参照ピクチャの間のリサンプリング比率を、コンフォーマンス・ウィンドウのコンフォーマンス・ウィンドウ・サイズに基づいて決定するステップと、コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されないことを示す第2フラグに基づいて、リサンプリング比率をリサンプリング・ピクチャ・サイズに基づいて決定するステップと、リサンプリング比率を利用して、現在のピクチャに対する前記参照ピクチャ・リサンプリングを実行するステップとを含む。
【0009】
実施形態では、符号化されたビデオ・ビットストリームを復号化する装置が提供され、本装置は、プログラム・コードを記憶するように構成された少なくとも1つのメモリと、プログラム・コードを読み込み、プログラム・コードによって指示されるように動作する少なくとも1つのプロセッサとを含み、プログラム・コードは、現在のピクチャにコンフォーマンス・ウィンドウが存在することを示す第1フラグを取得することを、少なくとも1つのプロセッサに行わせるように構成された第1取得コードと、コンフォーマンス・ウィンドウが存在することを示す第1フラグに基づいて、コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されるかどうかを示す第2フラグを取得することを、少なくとも1つのプロセッサに行わせるように構成された第2取得コードと、コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されることを示す第2フラグに基づいて、現在のピクチャ及び参照ピクチャの間のリサンプリング比率を、コンフォーマンス・ウィンドウのコンフォーマンス・ウィンドウ・サイズに基づいて決定することを、少なくとも1つのプロセッサに行わせるように構成された第1決定コードと、コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されないことを示す第2フラグに基づいて、リサンプリング比率をリサンプリング・ピクチャ・サイズに基づいて決定することを、少なくとも1つのプロセッサに行わせるように構成された第2決定コードと、リサンプリング比率を利用して、現在のピクチャに対する参照ピクチャ・リサンプリングを実行することを、少なくとも1つのプロセッサに行わせるように構成された実行コードとを含む。
【0010】
実施形態では、命令を記憶する非一時的なコンピュータ読み取り可能な媒体が提供され、命令は、符号化されたビデオ・ビットストリームを復号化するために装置の1つ以上のプロセッサで実行されると、1つ以上のプロセッサに、現在のピクチャにコンフォーマンス・ウィンドウが存在することを示す第1フラグを取得するステップと、コンフォーマンス・ウィンドウが存在することを示す第1フラグに基づいて、コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されるかどうかを示す第2フラグを取得するステップと、コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されることを示す第2フラグに基づいて、現在のピクチャ及び参照ピクチャの間のリサンプリング比率を、コンフォーマンス・ウィンドウのコンフォーマンス・ウィンドウ・サイズに基づいて決定するステップと、コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されないことを示す第2フラグに基づいて、リサンプリング比率をリサンプリング・ピクチャ・サイズに基づいて決定するステップと、リサンプリング比率を利用して、現在のピクチャに対する参照ピクチャ・リサンプリングを実行するステップとを実行させる。
【図面の簡単な説明】
【0011】
開示される対象事項の更なる特徴、性質、及び種々の利点は、以下の詳細な説明及び添付図面からより明らかになるであろう。
【0012】
【図1】実施形態による通信システムの簡略化されたブロック図の概略図である。
【0013】
【図2】実施形態による通信システムの簡略化されたブロック図の概略図である。
【0014】
【図3】実施形態によるデコーダの簡略化されたブロック図の概略図である。
【0015】
【図4】実施形態によるエンコーダの簡略化されたブロック図の概略図である。
【0016】
【図5】実施形態によるARCパラメータをシグナリングするためのオプションの概略図である。
【0017】
【0018】
【図7】実施形態によるSPSにおけるシグナリング・ピクチャサイズ及びコンフォーマンス・ウィンドウの概略図である
【0019】
【図8A】実施形態によるPPSにおけるシグナリング・ピクチャサイズ及びコンフォーマンス・ウィンドウの概略図である。
【図8B】実施形態によるPPSにおけるシグナリング・ピクチャサイズ及びコンフォーマンス・ウィンドウの概略図である。
【0020】
【図9】実施形態によるPPSにおけるリサンプリング・ピクチャ・サイズをシグナリングする概略図である。
【0021】
【図10】実施形態による符号化されたビデオ・ビットストリームを復号化するための例示的なプロセスのフローチャートである。
【0022】
【図11】実施形態によるコンピュータ・システムの概略図である。
【発明を実施するための形態】
【0023】
図1は、本開示の実施形態による通信システム（100）の簡略化されたブロック図を示す。システム（100）は、ネットワーク（150）を介して相互接続された少なくとも2つの端末（110～120）を含んでもよい。データの一方向伝送のために、第1端末（110）は、ネットワーク（150）を介して他方の端末（120）へ伝送するために、ローカル位置でビデオ・データをコーディングすることができる。第2端末（120）は、他方の端末のコーディングされたビデオ・データをネットワーク（150）から受信し、コーディングされたデータを復号化し、復元されたビデオ・データを表示することができる。一方向データ伝送は、メディア・サービング・アプリケーション等において一般的である。
【0024】
図1は、例えばビデオ会議中に生じる可能性のあるコーディングされたビデオの双方向伝送をサポートするために提供される端末の第2ペア（130，140）を示す。データの双方向伝送のために、各端末（130，140）は、ローカル位置で捕捉されたビデオ・データを、ネットワーク（150）を介して他方の端末へ伝送するためにコーディングすることができる。各端末（130，140）はまた、他方の端末によって送信されたコーディングされたビデオ・データを受信することができ、コーディングされたデータを復号化することができ、復元されたビデオ・データをローカル・ディスプレイ装置で表示することができる。
【0025】
図1において、端末（110-140）は、サーバー、パーソナル・コンピュータ、スマートフォンとして図示されているかもしれないが、本開示の原理はそれに限定されるものではない。本開示の実施形態は、ラップトップ・コンピュータ、タブレット・コンピュータ、メディア・プレーヤ、及び/又は専用のビデオ会議装置の用途を見出している。ネットワーク（150）は、例えば有線及び/又は無線通信ネットワークを含む、コーディングされたビデオ・データを端末（110～140）間で伝送する任意数のネットワークを表す。通信ネットワーク（150）は、回線交換及び/又はパケット交換チャネルでデータを交換することができる。代表的なネットワークは、通信ネットワーク、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク及び/又はインターネットを含む。本説明の目的のために、ネットワーク（150）のアーキテクチャ及びトポロジーは、以下で説明されない限り、本開示の動作にとって重要ではない可能性がある。
【0026】
図2は、開示される対象事項の適用例として、ストリーミング環境におけるビデオ・エンコーダ及びデコーダの配置を示す。開示される対象事項は、例えば、ビデオ会議、デジタルTV、圧縮ビデオのデジタル媒体での記憶（CD、DVD、メモリ・スティックなどを含む）などを含む、他のビデオ対応アプリケーションにも同様に適用可能である可能性がある。
【0027】
ストリーミング・システムは、例えば、非圧縮ビデオ・サンプル・ストリーム（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を含む。汎用ビデオ符号化（Versatile Video Coding，VVC）として非公式に知られているビデオ・コーディング規格は、開発中である。
【0028】
図3は、本開示の実施形態によるビデオ・デコーダ（210）の機能ブロック図であるとすることが可能である。
【0029】
受信機（310）は、デコーダ（210）によって復号化されるべき1つ以上のコーデック・ビデオ・シーケンス、同一の又は別の実施形態では、1度に1つのコーディングされたビデオ・シーケンスを受信することができ、この場合において、各々のコーディングされたビデオ・シーケンスの復号化は、他のコーディングされたビデオ・シーケンスから独立している。コーディングされたビデオ・シーケンスは、チャネル（312）から受信することができ、このチャネルは、符号化されたビデオ・データを記憶する記憶装置へのハードウェア/ソフトウェア・リンクであってもよい。受信機（310）は、符号化されたビデオ・データを、他のデータ、例えば符号化されたオーディオ・データ及び/又は補助的なデータ・ストリームと共に受信することができ、これらのデータは、エンティティ（図示せず）を利用してそれぞれ転送されることが可能である。受信機（310）は、符号化されたビデオ・シーケンスを他のデータから分離することができる。ネットワーク・ジッタに対処するために、バッファ・メモリ（315）が、受信機（310）とエントロピー・デコーダ/パーサー（320）（今後「パーサー」という）との間に結合されてもよい。受信機（310）が、十分な帯域幅及び制御可能性を有するストア/フォワード装置から、又はアイソシンクロナス・ネットワークから、データを受信している場合、バッファ（315）は不要である可能性があり、或いは小さいものであるとすることが可能である。インターネットのようなベスト・エフォート・パケット・ネットワークでの使用のために、バッファ（315）が必要とされる可能性があり、比較的大きくすることが可能であり、且つ有利なことに適応的なサイズであるとすることが可能である。
【0030】
ビデオ・デコーダ（210）は、エントロピー符号化されたビデオ・シーケンスからシンボル（321）を再構成するためのパーサー（320）を含んでもよい。これらのシンボルのカテゴリは、デコーダ（210）の動作を管理するために使用される情報と、図3に示されているように、デコーダの不可欠な部分ではないが、デコーダに結合されることが可能なディスプレイ（212）のようなレンダリング装置を制御する可能性のある情報とを含む。レンダリング・デバイスの制御情報は、補足エンハンスメント情報（SEI（Supplementary Enhancement Information）メッセージ）又はビデオ・ユーザビリティ情報（Video Usability Information，VUI）パラメータ・セット・フラグメント（図示せず）の形式であってもよい。パーサー（320）は、受信したコーディングされたビデオ・シーケンスを解析/エントロピー復号化することができる。コーディングされたビデオ・シーケンスのコーディングは、ビデオ・コーディング技術又は規格に従うことが可能であり、可変長コーディング、ハフマン・コーディング、コンテキストの影響を伴うか又は伴わない算術コーディングなどを含む、当業者に周知の原理に従うことができる。パーサー（320）は、グループに対応する少なくとも1つのパラメータに基づいて、ビデオ・デコーダ内のピクセルのサブグループのうちの少なくとも1つに対するサブグループ・パラメータのセットを、コーディングされたビデオ・シーケンスから抽出することができる。サブグループは、グループ・オブ・ピクチャ（GOP）、ピクチャ、サブ・ピクチャ、タイル、スライス、ブリック、マクロブロック、コーディング・ツリー・ユニット（CTU）、コーディング・ユニット（CU）、ブロック、変換ユニット（TU）、予測ユニット（PU）などを含むことが可能である。タイルは、ピクチャ内の特定のタイル列及び行の内のCU/CTUの矩形領域を示す可能性がある。ブリックは、特定のタイル内のCU/CTU行（複数行）のうちの矩形領域を示すことが可能である。スライスは、NALユニットに含まれるピクチャの1つ以上のブリックを示すことが可能である。サブ・ピクチャは、1つのピクチャ内の1つ以上のスライスの矩形領域を示すことが可能である。エントロピー・デコーダ/パーサーはまた、変換係数、量子化パラメータ値、動きベクトル等のような情報を、コーディングされたビデオ・シーケンスから抽出することができる。
【0031】
パーサー（320）は、シンボル（321）を作成するために、バッファ（315）から受信したビデオ・シーケンスに対してエントロピー復号化/解析オペレーションを実行することができる。
【0032】
シンボル（321）の再構成は、コーディングされたビデオ・ピクチャ又はその部分のタイプ（例えば、ピクチャ間、ピクチャ内、ブロック間、ブロック内）やその他の要因に応じて、複数の異なるユニットを含むことが可能である。どのユニットがどのように関与するかは、コーディングされたビデオ・シーケンスからパーサー（320）によって解析されたサブグループ制御情報によって、制御されることが可能である。パーサー（320）と後の複数ユニットとの間のこのようなサブグループ制御情報の流れは、明確化のために描かれてはいない。
【0033】
デコーダ210は、既に言及した機能ブロックを超えて、概念的には、以下に説明するような複数の機能ユニットに細分されることが可能である。商業的制約の下で動作する実用的な実装では、これらの多くのユニットは互いに密接に相互作用し、少なくとも部分的に互いに統合されることが可能である。しかしながら、開示される対象事項を説明するために、以下の機能ユニットへの概念的な細分化は相応しい。
【0034】
最初のユニットは、スケーラ/逆変換ユニット（351）である。スケーラ/逆変換ユニット（351）は、制御情報と同様に量子化された変換係数を受信し、制御情報は、どの変換を使用するか、ブロック・サイズ、量子化係数、量子化スケーリング行列などを、パーサー（320）からのシンボル（321）として含む。そのユニットは、アグリゲータ（355）に入力されることが可能なサンプル値を含むブロックを出力することが可能である。
【0035】
場合によっては、スケーラ/逆変換（351）の出力サンプルは、イントラ・コーディングされたブロック、即ち、以前に再構成されたピクチャからの予測情報を使用していないが、現在のピクチャの以前に再構成された部分からの予測情報を使用することができるブロック、に関連付けることが可能である。このような予測情報は、イントラ・ピクチャ予測ユニット（352）によって提供されることが可能である。場合によっては、イントラ・ピクチャ予測ユニット（352）は、現在の（部分的に再構成された）ピクチャ（358）から取り出された周辺の既に再構成された情報を使用して、再構成中のブロックの同じサイズ及び形状のブロックを生成する。アグリゲータ（355）は、場合によってはサンプル毎に、イントラ予測ユニット（352）が生成した予測情報を、スケーラ/逆変換ユニット（351）によって提供されるような出力サンプル情報に追加する。
【0036】
それ以外のケースにおいて、スケーラ/逆変換ユニット（351）の出力サンプルは、インター・コーディングされた、潜在的に動き補償されたブロックに関連することが可能である。このようなケースでは、動き補償予測ユニット（353）は、参照ピクチャ・メモリ（357）にアクセスして、予測に使用されるサンプルを取り出すことができる。ブロックに関連するシンボル（321）に従って、取り出されたサンプルを動き補償した後に、これらのサンプルは、アグリゲータ（355）によって、スケーラ/逆変換ユニットの出力に加えられ（この場合、残差サンプル又は残差信号と呼ばれる）、出力サンプル情報を生成することができる。動き補償ユニットが予測サンプルを取り出す場合において、参照ピクチャ・メモリ形態内のアドレスは、例えばX、Y、及び参照ピクチャ成分を有することが可能なシンボル（321）の形態で動き補償ユニットにとって利用可能な動きベクトルによって、制御されることが可能である。また、動き補償は、サブ・サンプル・イグザクト動きベクトル（sub-sample exact motion vectors）が使用される場合に、参照ピクチャ・メモリからフェッチされるサンプル値の補間、動きベクトル予測メカニズム等を含むことができる。
【0037】
アグリゲータ（355）の出力サンプルは、ループ・フィルタ・ユニット（356）内の様々なループ・フィルタリング技術の影響を受ける可能性がある。ビデオ圧縮技術はループ内フィルタ技術を含むことが可能であり、その技術は、コーディングされたビデオ・ビットストリームに含まれるパラメータによって制御され、ループ・フィルタ・ユニット（356）にとってパーサー（320）からのシンボル（321）として利用可能にされるが、コーディングされたピクチャ又はコーディングされたビデオ・シーケンスの（復号化順で）以前の部分の復号化中に得られたメタ情報に応答することが可能であり、また、以前に再構成されループ・フィルタリングされたサンプル値に応答することも可能である。
【0038】
ループ・フィルタ・ユニット（356）の出力は、レンダリング装置（212）に出力されることが可能であり、且つ将来のインター・ピクチャ予測に使用するために参照ピクチャ・メモリに記憶されることが可能なサンプル・ストリームであるすることが可能である。
【0039】
幾らかのコーディングされたピクチャは、いったん完全に再構成されると、将来の予測のための参照ピクチャとして使用することが可能である。コーディングされたピクチャが完全に再構成され、コーディングされたピクチャが参照ピクチャとして（例えば、パーサー（320）によって）識別されると、現在の参照ピクチャ（358）は参照ピクチャ・バッファ（357）の一部となることが可能であり、以後のコーディングされたピクチャの再構成を開始する前に、新しい現在ピクチャ・メモリが改めて割り当てられることが可能である。
【0040】
ビデオ・デコーダ210は、ITU-T Rec. H.265のような規格で文書化される可能性のある所定のビデオ圧縮技術に従って、復号化動作を実行することができる。コーディングされたビデオ・シーケンスは、ビデオ圧縮技術文書又は規格の中で、特にその中のプロファイル文書の中で規定されているように、ビデオ圧縮技術又は規格のシンタックスに従うという意味で、使用されているビデオ圧縮技術又は規格によって規定されるシンタックスに従うことができる。また、コンプライアンスのために必要なことは、コーディングされたビデオ・シーケンスの複雑性が、ビデオ圧縮技術又は規格のレベルによって定められる範囲内にあることである可能性がある。場合によっては、レベルは、最大ピクチャ・サイズ、最大フレーム・レート、最大再構成サンプル・レート（例えば、毎秒当たりのメガサンプルで測定される）、最大参照ピクチャ・サイズなどを制限する。レベルによって設定される制限は、場合によっては、コーディングされたビデオ・シーケンスでシグナリングされるHRDバッファ管理のためのメタデータ及び仮説参照デコーダ（HRD）仕様によって、更に制限される可能性がある。
【0041】
実施形態では、受信機（310）は、符号化されたビデオと共に追加の（冗長な）データを受信することができる。追加データは、コーディングされたビデオ・シーケンスの一部として含まれる可能性がある。追加のデータは、データを適切に復号化するため、及び/又はオリジナル・ビデオ・データをより正確に再構成するために、ビデオ・デコーダ（210）によって使用されてもよい。追加のデータは、例えば、時間的、空間的、又はSNRエンハンスメント層、冗長スライス、冗長ピクチャ、前方誤り訂正コードなどの形態におけるものであるとすることが可能である。
【0042】
図4は、本開示の実施形態によるビデオ・エンコーダ（203）の機能ブロック図であるとすることが可能である。
【0043】
エンコーダ（203）は、エンコーダ（203）によってコーディングされるべきビデオ画像を捕捉することが可能なビデオ・ソース（201）（エンコーダの一部ではない）からビデオ・サンプルを受信することができる。
【0044】
ビデオ・ソース（201）は、任意の適切なビット深度（例えば、8ビット、10ビット、12ビット、・・・）、任意の色空間（例えば、BT.601 YCrCB、RGB、・・・）及び任意の適切なサンプリング構造（例えば、YCrCb 4:2:0、YCrCb 4:4:4）によるものであるとすることが可能なデジタル・ビデオ・サンプル・ストリームの形態で、エンコーダ（203）によってコーディングされるソース・ビデオ・シーケンスを提供することができる。メディア・サービング・システムにおいて、ビデオ・ソース（201）は、前もって準備されたビデオを記憶する記憶装置であってもよい。ビデオ会議システムにおいては、ビデオ・ソース（203）は、ローカル画像情報をビデオ・シーケンスとして捕捉するカメラであってもよい。ビデオ・データは、シーケンスで見た場合に動きを伝える複数の個々のピクチャとして提供されてもよい。ピクチャ自体は、ピクセルの空間アレイとして組織されてもよく、各ピクセルは、使用中のサンプリング構造、色空間などに応じて、1つ以上のサンプルを含むことができる。当業者は、ピクセルとサンプルとの間の関係を容易に理解することができる。以下の説明はサンプルに焦点を当てている。
【0045】
実施形態によれば、エンコーダ（203）は、リアルタイムで、又はアプリケーションによって要求される他の任意の時間的制約の下で、ソース・ビデオ・シーケンスのピクチャを、コーディングされたビデオ・シーケンス（443）に、コーディングして圧縮することができる。適切なコーティング速度を強いることは、コントローラ（450）の1つの機能である。コントローラは、以下で説明されるように他の機能ユニットを制御し、これらのユニットに機能的に結合される。その結合は明確性のために描かれていない。コントローラによって設定されるパラメータは、レート制御関連パラメータ（ピクチャ・スキップ、量子化器、レート歪最適化技術のラムダ値、・・・）、ピクチャ・サイズ、グループ・オブ・ピクチャ（GOP）のレイアウト、最大動きベクトル探索範囲などを含むことができる。当業者は、コントローラ（450）の他の機能を容易に識別することが可能であり、なぜならそれらは特定のシステム設計のために最適化されたビデオ・エンコーダ（203）に関連し得るからである。
【0046】
幾つかのビデオ・エンコーダは、「コーディング・ループ」として当業者が容易に認識するものにおいて動作する。極端に簡略化した説明として、コーディング・ループは、エンコーダ（430）（以下、「ソース・コーダー」という）（コーディングされるべき入力ピクチャ及び参照ピクチャに基づいてシンボルを生成する責任を負う）と、エンコーダ（203）に組み込まれた（ローカル）デコーダ（433）とによる符号化部分で構成されることが可能であり、（ローカル）デコーダ（433）はサンプル・データを作成するためにシンボルを再構成し、（開示される対象事項で考慮されるビデオ圧縮技術において、シンボルとコーディングされたビデオ・ビットストリームとの間の任意の圧縮はロスレスであるので）（リモート）デコーダもまたそのサンプル・データを作成するであろう。再構成されたサンプル・ストリームは、参照ピクチャ・メモリ（434）に入力される。シンボル・ストリームの復号化は、デコーダの位置（ローカル又はリモート）に依存しないビット・イグザクト（bit-exact）な結果をもたらすので、参照ピクチャ・バッファの内容もまた、ローカル・エンコーダとリモート・エンコーダの間でビット・イグザクトである。言い換えると、エンコーダの予測部分は、デコーダが復号化中に予測を使用する場合に「見る」であろうものと全く同じサンプル値を、参照ピクチャ・サンプルとして「見る」。参照ピクチャの同期性のこの基本原理（例えば、チャネル・エラーに起因して、同期性を維持することができない場合には、結果としてドリフトが生じる）は、当業者に周知である。
【0047】
「ローカル」デコーダ（433）の動作は、「リモート」デコーダ（210）のものと同じであるとすることが可能であり、それは図3に関連して既に詳細に説明されている。しかしながら手短に図4を参照すると、シンボルが利用可能であり、且つコーディングされたビデオ・シーケンスに対するエントロピー・コーダー（445）及びパーサー（320）によるシンボルの符号化/復号化はロスレスであるとすることが可能であるので、チャネル（312）、受信機（310）、バッファ（315）及びパーサー（320）を含むデコーダ（210）のエントロピー復号化部分は、ローカル・デコーダ（433）において完全には実装されなくてもよい。
【0048】
この時点で行うことができる洞察は、解析/エントロピー復号化を除いてデコーダに存在する任意のデコーダ技術は、必然的に、実質的に同一の機能形態で、対応するエンコーダにも存在する必要があることである。この理由のために、開示される対象事項は、デコーダの動作に焦点を当てる。エンコーダ技術の説明は、包括的に説明されるデコーダ技術の逆であるので、省略することが可能である。特定の分野においてのみ、より詳細な説明が必要とされ、以下において提供される。
【0049】
ソース・コーダー（430）は、動作の一部として、動き補償された予測コーディングを実行することができ、それは、「参照フレーム」として指定されたビデオ・シーケンスからの1つ以上の以前にコーディングされたフレームを参照して、入力フレームを予測コーディングする。このようにして、コーディング・エンジン（432）は、入力フレームのピクセル・ブロックと、入力フレームに対する予測参照として選択され得る参照フレームのピクセル・ブロックとの間の差分をコーディングする。
【0050】
ローカル・ビデオ・デコーダ（433）は、ソース・コーダー（430）によって生成されたシンボルに基づいて、参照フレームとして指定され得るフレームの符号化されたビデオ・データを復号化することができる。コーディング・エンジン（432）の動作は、有利なことに、ロスレス・プロセスである可能性がある。コーディングされたビデオ・データがビデオ・デコーダ（図4では示されていない）で復号化される場合、再構成されたビデオ・シーケンスは、典型的には、幾らかのエラーを伴うソース・ビデオ・シーケンスのレプリカである可能性がある。ローカル・ビデオ・デコーダ（433）は、参照フレームに対してビデオ・デコーダによって実行され得る復号化プロセスを再現し、再構成された参照フレームが、参照ピクチャ・キャッシュ（434）に記憶されることを引き起こすことが可能である。このようにして、エンコーダ（203）は、遠方端のビデオ・デコーダによって（伝送エラーが無い場合に）得られる再構成された参照フレームと共通の内容を有するローカルに再構成された参照フレームのコピーを記憶することができる。
【0051】
予測器（435）は、コーディング・エンジン（432）のために予測探索を実行することができる。即ち、コーディングされるべき新しいフレームに対して、予測器（435）は、サンプル・データ（候補参照ピクセル・ブロックとして）又は特定のメタデータ（例えば、参照ピクチャ動きベクトル、ブロック形状など）について、参照ピクチャ・メモリ（434）を探索することが可能であり、これらは新しいピクチャに対する適切な予測参照として役立つ可能性がある。予測器（435）は、適切な予測参照を発見するために、サンプルに対してブロック毎に動作することが可能である。場合によっては、予測器（435）によって得られた探索結果によって決定されるように、入力ピクチャは、参照ピクチャ・メモリ（434）に記憶された複数の参照ピクチャから引き出される予測参照を有する可能性がある。
【0052】
コントローラ（450）は、例えば、ビデオ・データを符号化するために使用されるパラメータ及びサブグループ・パラメータの設定を含む、ビデオ・コーダー（430）のコーディング動作を管理することができる。
【0053】
前述のすべての機能ユニットの出力は、エントロピー・コーダー（445）においてエントロピー・コーディングの影響を受ける可能性がある。エントロピー・コーダーは、例えば、ハフマン・コーディング、可変長コーディング、算術コーディング等のように当業者に既知の技術に従って、シンボルをロスレス圧縮することによって、種々の機能ユニットで生成された記号を、コーディングされたビデオ・シーケンスに変換する。
【0054】
送信機（440）は、エントロピー・コーダー（445）によって作成されるようなコーディングされたビデオ・シーケンスをバッファリングし、通信チャネル（460）を介して送信するために準備することが可能であり、通信チャネル（460）は、符号化されたビデオ・データを記憶する記憶装置へのハードウェア/ソフトウェア・リンクであってもよい。送信機（440）は、ビデオ・コーダ（430）からのコーディングされたビデオ・データを、送信されるべき他のデータ、例えばコーディングされたオーディオ・データ及び/又は補助的なデータ・ストリーム（ソースは図示せず）とマージすることが可能である。
【0055】
コントローラ（450）はエンコーダ（203）の動作を管理することが可能である。コーディングの間に、コントローラ（450）は、各々のコーディングされたピクチャに、特定のコーディング済みピクチャ・タイプを割り当てることが可能であり、これは、個々のピクチャに適用され得るコーディング技術に影響を及ぼす可能性がある。例えば、ピクチャはしばしば次のフレーム・タイプのうちの1つとして指定されることが可能である：
【0056】
イントラ・ピクチャ（Iピクチャ）は、シーケンス内の他の何れのフレームも予測のソースとして使用せずに、符号化及び復号化され得るものであり得る。幾つかのビデオ・コーデックは、例えば、独立デコーダ・リフレッシュ・ピクチャを含む、異なるタイプのイントラ・ピクチャを許容する。当業者は、Iピクチャのこれらの変形例、並びにそれらのそれぞれの用途及び特徴を把握している。
【0057】
予測ピクチャ（Pピクチャ）は、各ブロックのサンプル値を予測するために、最大1つの動きベクトルと参照インデックスを用いて、イントラ予測又はインター予測を用いて符号化及び復号化され得るものであり得る。
【0058】
双方向予測ピクチャ（Bピクチャ）は、各ブロックのサンプル値を予測するために、最大2つの動きベクトルと参照インデックスを用いて、イントラ予測又はインター予測を用いて符号化及び復号化され得るものであり得る。同様に、複数の予測ピクチャは、1つのブロックの再構成のために、2つより多い参照ピクチャ及び関連するメタデータを使用することが可能である。
【0059】
ソース・ピクチャは、通常、複数のサンプル・ブロック（例えば、4×4、8×8、4×8、又は16×16の各サンプルのブロック）に空間的に分割され、ブロック毎にコーディングされることが可能である。ブロックは、ブロックのそれぞれのピクチャに適用されるコーディング割り当てによって決定されるように、他の（既にコーディングされた）ブロックを参照して予測コーディングされることが可能である。例えば、Iピクチャのブロックは、非予測的にコーディングされてもよいし、又はそれらは同じピクチャの既にコーディングされたブロックを参照して予測コーディング（空間予測又はイントラ予測）されてもよい。Pピクチャのピクセル・ブロックは、以前にコーディングされた1つの参照ピクチャを参照して、空間的予測により、又は時間的予測により、非予測的にコーディングされる可能性がある。Bピクチャのブロックは、1つ又は2つの以前にコーディングされた参照ピクチャを参照して、空間的予測により、又は時間的予測により、非予測的にコーディングされる可能性がある。
【0060】
ビデオ・コーダー（203）は、ITU-T Rec. H.265のような所定のビデオ・コーディング技術又は規格に従ってコーディング動作を実行することが可能である。動作の際に、ビデオ・コーダー（203）は、入力ビデオ・シーケンスにおける時間的及び空間的な冗長性を活用する予測コーディング動作を含む種々の圧縮動作を実行することができる。従って、コーディングされたビデオ・データは、使用されているビデオ・コーディング技術又は規格によって指定されたシンタックスに従うことが可能である。
【0061】
実施形態では、送信機（440）は、符号化されたビデオと共に追加データを送信することが可能である。ビデオ・コーダー（430）は、コーディングされたビデオ・シーケンスの一部としてそのようなデータを含むことが可能である。追加データは、時間的/空間的/SNRエンハンスメント層、冗長ピクチャ及びスライスのような他の形式の冗長データ、補足エンハンスメント情報（SEI）メッセージ、視覚的ユーザビリティ情報（VUI）パラメータ・セット・フラグメントなどを含んでもよい。
【0062】
最近、複数の意味的に独立したピクチャ部分の単一のビデオ・ピクチャへの圧縮ドメイン集約（aggregation）又は抽出（extraction）が注目を集めている。特に、例えば360コーディング又は特定の監視アプリケーションの状況において、複数の意味的に独立したソース・ピクチャ（例えば、キューブ投影360シーンの6つの立方体表面、又はマルチ・カメラ監視セットアップの場合の個々のカメラ入力）は、所与の時点での様々なシーン毎のアクティビティに対処するために、別々の適応的な解像度設定を必要とする可能性がある。言い換えれば、エンコーダは、所定の時点で、360全体又は監視シーンを構築する異なる意味的に独立したピクチャに対して、異なるリサンプリング因子を使用することを選択する可能性がある。単一のピクチャにコンバインされる場合、それは、参照ピクチャ・リサンプリングが実行され、コーディングされたピクチャの部分に対して、適応的な解像度コーディング・シグナリングが利用可能であることを要求する。
【0063】
以下、本説明の残りの部分で参照される幾つかの用語を紹介する。
【0064】
サブ・ピクチャは、場合によっては、サンプル、ブロック、マクロブロック、コーディング・ユニット、又は意味的にグループ化された同様なエンティティであって、変更された解像度で独立にコーディングされる可能性があるエンティティについての、サンプルの矩形配列を指すことが可能である。1つ以上のサブ・ピクチャはピクチャを形成することが可能である。1つ以上のコーディングされたサブ・ピクチャは、コーディングされたピクチャを形成することが可能である。1つ以上のサブ・ピクチャは、1つのピクチャに組み立てられることが可能であり、1つ以上のサブ・ピクチャが、1つのピクチャから抽出されることが可能である。特定の環境では、1つ以上のコーディングされたサブ・ピクチャは、サンプル・レベルを、コーディングされたピクチャにトランスコーディングすることなく、圧縮されたドメイン内で組み立てられてもよく、同じ場合又は他の場合に、1つ以上のコーディングされたサブ・ピクチャは、圧縮されたドメイン内のコーディングされたピクチャから抽出されてもよい。
【0065】
参照ピクチャ・リサンプリング（RPR）又は適応解像度変更（ARC）は、例えば参照ピクチャ・リサンプリングによって、コーディングされたビデオ・シーケンス内のピクチャ又はサブ・ピクチャの解像度の変更を可能にするメカニズムを指す可能性がある。以下、RPR/ARCパラメータは、適応解像度変更を実行するために必要とされる制御情報を指し、これは、例えば、フィルタ・パラメータ、スケーリング因子、出力及び/又は参照ピクチャの解像度、種々の制御フラグ等を含む可能性がある。
【0066】
実施形態において、コーディング及びデコーディングは、単一の意味的に独立したコーディングされたビデオ・ピクチャに対して実行される可能性がある。独立したRPR/ARCパラメータを有する複数のサブ・ピクチャのコーディング/デコーディングの意味と含意の追加的な複雑性を説明する前に、RPR/ARCパラメータをシグナリングするためのオプションを説明するものとする。
【0067】
図5A～図5Eに関し、RPR/ARCパラメータをシグナリングするための幾つかの実施形態が示される。実施形態の各々で言及されるように、それらは、符号化効率、複雑性、及びアーキテクチャの観点から、特定の利点及び特定の欠点を有する可能性がある。ビデオ・コーディング規格又は技術は、RPR/ARCパラメータをシグナリングするために、これらの実施形態のうちの1つ以上、又は関連技術から分かるオプションを選択することができる。実施形態は、相互に排他的ではない可能性があり、アプリケーションの必要性、関連する標準化技術、又はエンコーダの選択に基づいて考えられる限り相互に交換されてもよい。
【0068】
RPR/ARCパラメータのクラスは次のものを含む可能性がある：
【0069】
－アップ/ダウンサンプル因子。X及びY次元で別々であるか又は組み合わせられる。
【0070】
－アップ/ダウンサンプル因子。時間の次元を追加しており、所定数のピクチャに対する一定の速度のズーム・イン/アウトを示す。
【0071】
－上記2つの何れかは、因子を含むテーブルを指し示すことが可能な1つ以上のおそらくは短いシンタックス要素のコーディングを含むことが可能である。
【0072】
－解像度。入力ピクチャ、出力ピクチャ、参照ピクチャ、コーディングされたピクチャの各々又は結合についての、サンプル、ブロック、マクロブロック、コーディング・ユニット（CU）、又は他の任意の適切な粒度の単位でのX又はY次元におけるものである。1つより多い解像度がある場合（例えば、入力ピクチャについて1つ、参照ピクチャについて1つ）、場合によっては、1組の値が別の組の値から推測されてもよい。これらは、例えば、フラグを使用することによってゲート制御されることが可能である。より詳細な例については、以下を参照されたい。
【0073】
－「ワーピング（warping）」座標。H.263AnnexPで使用されるものと同様であり、上述したようにここでも適切な粒度におけるものである。H.263AnnexPは、このようなワーピング座標をコーディングするための1つの効率的な方法を規定しているが、他の潜在的により効率的な方法も考えられる。AnnexPのワーピング座標の可変長でリバーシブルな「ハフマン（Huffman）」スタイルのコーディングは、適切な長さのバイナリ・コーディングに置き換えることが可能であり、この場合において、バイナリ・コード・ワードの長さは、例えば最大ピクチャ・サイズから、おそらくは特定の因子を乗算して、特定の値だけオフセットすることによって導出され、最大ピクチャ・サイズの境界の外の「ワーピング」を許容する。
【0074】
－アップ又はダウンサンプル・フィルタ・パラメータ。実施形態において、アップ及び/又はダウンサンプリングのために単一のフィルタのみが存在する可能性がある。しかしながら、実施形態では、フィルタ設計においてより多くの柔軟性を可能にすることが望ましい可能性があり、それはフィルタ・パラメータのシグナリングを必要とする可能性がある。そのようなパラメータは、可能なフィルタ設計のリスト内のインデックスによって選択されることが可能であり、（例えば、フィルタ係数のリストによって、適切なエントロピー・コーディング技術を用いることで）フィルタは完全に指定されることが可能であり、フィルタは、上述のメカニズムのうちの何れかに従ってシグナリングされるアップ/ダウンサンプル比によって暗黙的に選択されることが可能である。
【0075】
以下、本説明は、コードワードによって指定される、アップ/ダウンサンプル因子（X及びY次元の両方で使用されるのと同じ因子）の有限セットのコーディングを仮定する。このコードワードは、例えばH.264及びH.265のようなビデオ・コーディング仕様における特定のシンタックス要素に共通のExt-Golombコードを使用して、可変長コーディングされることが可能である。値のアップ/ダウンサンプル・ファクターへの1つの適切なマッピングは、例えば、テーブル1によるものとすることが可能である：
テーブル1
テーブル1
【表1】
【0076】
アプリケーションのニーズと、ビデオ圧縮技術や標準で利用可能なアップ及びダウンスケール・メカニズムの能力とに応じて、多くの類似したマッピングを案出することができる。テーブルは、より多くの値に拡張されることが可能である。値は、例えば、バイナリ・コーディングを使用して、Ext-Golombコード以外のエントロピー・コーディング・メカニズムによって表現されることも可能である。これは、ビデオ処理エンジン（エンコーダ及びデコーダが最重要）自体の外側で、例えばMANEによって、リサンプリング因子が関心事であった場合に、ある種の利点を有する可能性がある。解像度の変更が要求されない状況では、短いExt-Golombコードを選択することが可能であり；上記のテーブルでは、1ビットのみであることに留意すべきである。これは、最も一般的なケースに対してバイナリ・コードを使用することを上回る符号化効率の利点を有する可能性がある。
【0077】
テーブル内のエントリの数、及びそのそれらのセマンティクスは、完全又は部分的に設定可能であってもよい。例えば、テーブルの基本的な概要は、シーケンス又はデコーダ・パラメータ・セットのような「高」パラメータ・セットで伝達されることが可能である。実施形態において、1つ以上のそのようなテーブルは、ビデオ・コーディング技術又は標準で規定されることが可能であり、例えばデコーダ又はシーケンス・パラメータ・セットを通じて選択されることが可能である。
【0078】
以下、上述したようにコーディングされたアップサンプル/ダウンサンプル因子（ARC情報）が、ビデオ・コーディング技術又は標準シンタックスにどのように包含され得るかについて説明する。同様の考察は、アップ/ダウンサンプル・フィルタを制御する1つ又は数個のコードワードに適用されることが可能である。フィルタ又はその他のデータ構造に、比較的大量のデータが必要とされる場合には、以下の説明を参照されたい。
【0079】
図5に示すように、H.263AnnexPは、4つのワーピング座標の形式におけるARC情報（502）をピクチャ・ヘッダ（501）に、特にH.263 PLUSPTYPE （503）ヘッダ拡張に含める。これは、a）利用可能なピクチャ・ヘッダが存在し、b）ARC情報の頻繁な変更が予想される場合に、賢明な設計選択となる可能性がある。しかしながら、H.263スタイルのシグナリングを使用する場合のオーバヘッドは極めて大きくなる可能性があり、ピクチャ・ヘッダは一時的な性質のものである可能性があるので、ピクチャ境界の間でスケーリング因子が関わらない可能性がある。
【0080】
同一又は別の実施形態において、ARCパラメータのシグナリングは、図6A～6Bに概説される詳細な実施例に従うことができる。図6A～図6Bは、例えば、少なくとも1993年以降のビデオ・コーディング規格で使用されるようなCスタイルのプログラミングに概ね従う表記法を使用した一種の表現におけるシンタックス図を示す。太い線はビットストリームに存在するシンタックス要素を示し、太字でない線は制御フローや変数の設定をしばしば示している。
【0081】
図6Aに示すように、（おそらくは矩形の）ピクチャの一部分に適用可能なヘッダの例示的なシンタックス構造としてのタイル・グループ・ヘッダ（601）は、条件付きで、可変長のExp-Golombコーディングされたシンタックス要素dec_pic_size_idx （602）（太字）を含むことができる。タイル・グループ・ヘッダ中のこのシンタックス要素の存在は、適応解像度（603）の使用によって－ここでは太字で描かれていないフラグの値によって、ゲート制御されることが可能であり、これは、シンタックス・ダイヤグラム内で生じる地点で、フラグがビットストリームに存在することを意味する。適応解像度がこのピクチャ又はその一部に対して使用されているか否かは、ビットストリームの内側又は外側の任意の高レベル・シンタックス構造でシグナリングされることが可能である。図示の例では、以下で概説されるように、シーケンス・パラメータ・セットでシグナリングされる。
【0082】
図6Bを参照すると、シーケンス・パラメータ・セット（610）の抜粋が示されている。図示されている最初のシンタックス要素は、adaptive_pic_resolution_change_flag（611）である。true（真）である場合、そのフラグは適応解像度を使用することを指定することが可能であり、それは特定の制御情報を必要とする可能性がある。この例では、このような制御情報は、パラメータ・セット（612）及びタイル・グループ・ヘッダ（601）におけるif()ステートメントに基づくフラグの値に基づいて、条件付きで存在する。
【0083】
適応解像度が使用中である場合、この例では、出力解像度はサンプル単位でコーディングされる（613）。数字613は、output_pic_width_in_luma_samples及びoutput_pic_height_in_luma_samplesの両方を指し、共に出力ピクチャの解像度を規定することが可能である。ビデオ・コーディング技術又は規格のどこかで、何れかの値に対する特定の制約を規定することが可能である。例えば、レベルの規定は、これらの2つのシンタックス要素の値の積であるとすることが可能な出力サンプル総数を制限することが可能である。また、特定のビデオ・コーディング技術若しくは規格、又は外部の技術若しくは規格、例えばシステム規格は、数字の範囲を制限してもよいし（例えば、一方又は両方の寸法は2のべき乗の数で割り切れなければならない）又はアスペクト比を制限してもよい（例えば、幅及び高さは、4:3又は16:9のような関係になければならない）このような制限は、ハードウェアの実装を容易にするために、又は他の理由のために導入されてもよく、当技術分野では周知である。
【0084】
特定のアプリケーションでは、そのサイズが出力ピクチャ・サイズであることを暗黙的に仮定するのではなく、特定の参照ピクチャ・サイズを使用することを、エンコーダがデコーダに指示することが望ましい可能性がある。この例では、シンタックス要素reference_pic_size_present_flag（614）は、参照ピクチャ寸法（615）の条件付きの存在をゲート制御する（ここでも数字は幅と高さの両方を指す）。
【0085】
最終的に、可能な復号化ピクチャの幅と高さのテーブルが示される。このようなテーブルは、例えば、テーブル指示（num_dec_pic_size_in_luma_samples_minus1）（616）によって表現されることが可能である。“minus1”はシンタックス要素の値の解釈を示す。例えば、コーディングされた値がゼロである場合、1つのテーブル・エントリが存在する。値が5である場合、6つのテーブル・エントリが存在する。テーブル内の各“ライン”に対して、復号化されたピクチャの幅と高さが次いでシンタックス（617）に含まれる。
【0086】
提示さえるテーブル・エントリ（617）は、タイル・グループ・ヘッダ内のシンタックス要素dec_pic_size_idx（602）を使用してインデックス指定されることが可能であり、それにより、タイル・グループ毎の様々な復号化されたサイズ（事実上のズーム因子）を許容する。
【0087】
特定のビデオ・コーディング技術又は規格、例えばVP9は、時間的スケーラビリティと共に特定の形式の参照ピクチャ・リサンプリング（開示される対象事項とは全く相違してシグナリングされる）を実装することによって、空間的スケーラビリティをサポートし、空間的スケーラビリティを可能にする。特に、特定の参照ピクチャは、ARCスタイルの技術を用いて、より高い解像度までアップサンプリングされ、空間的エンハンスメント層のベースを形成することができる。これらのアップサンプリングされたピクチャは、高解像度での通常の予測メカニズムを用いて、精緻化することができるので、詳細を加えることができる。
【0088】
本願で説明される実施形態は、このような環境で使用することができる。特定の場合には、同じ又は別の実施形態において、NALユニット・ヘッダの値、例えば、テンポラルID（Temporal ID）フィールドが、時間的な層だけでなく、空間的な層も示すために使用されることが可能である。そうすることは、特定のシステム設計に対してある種の利点を有する可能性がある；例えば、NALユニット・ヘッダのTemporal ID値に基づく時間的な層の選択された転送のために作成され最適化される既存の選択転送ユニット（SFU）は、スケーラブルな環境のために、変更することなく使用することができる。これを可能にするために、コーディングされたピクチャ・サイズと時間的な層との間のマッピングに条件が存在する可能性があり、NALユニット・ヘッダのテンポラルIDフィールドによって指定される。
【0089】
最近、複数の意味的に独立したピクチャ部分の単一のビデオ・ピクチャへの圧縮ドメイン集約又は抽出が注目を集めている。特に、例えば、360コーディング又は特定の監視アプリケーションの状況において、複数の意味的に独立したソース・ピクチャ（例えば、立方体投影360シーンの6つの立方体表面、又はマルチ・カメラ監視セットアップの場合の個々のカメラ入力）は、所与の時点での様々なシーン毎のアクティビティに対処するために、別々の適応的な解像度設定を必要とする可能性がある。言い換えれば、エンコーダは、所定の時点で、360全体又は監視シーンを構築する異なる意味的に独立したピクチャに対して、異なるリサンプリング因子を使用することを選択する可能性がある。単一のピクチャにコンバインされる場合、それは、参照ピクチャ・リサンプリングが実行され、コーディングされたピクチャの部分に対して、適応的な解像度コーディング・シグナリングが利用可能であることを要求する。
【0090】
実施形態では、コンフォーマンス・ウィンドウは、ピクチャの矩形のサブ・パートである可能性があり、サブ・パートのうちのサンプルはデコーダによって出力されるのに対して、ウィンドウの外側のサンプルはデコーダによる出力から省略されてもよいことを、エンコーダは指定している。
【0091】
ここで取り上げる問題の1つは、コンフォーマンス・ウィンドウが2つの目的を果たす可能性があることである。1つの目的は、上述のように出力サイズを規定することである。出力サイズは、アプリケーション主導であることが可能であり、例えば立体視又は360キューブ・マップのアプリケーションでは、コーディングされたピクチャ・サイズとは全く異なる可能性がある。第2の目的は、コンフォーマンス・ウィンドウが、上述の参照ピクチャ・リサンプリングにも入力されることである可能性がある。
【0092】
コーディングされたピクチャ及びリサンプリングされたピクチャの両方について、コンフォーマンス・ウィンドウ・サイズ及びピクチャ・サイズの特定の組み合わせを有する場合、パディング・エリアの外側のサンプルが参照される可能性がある。この問題は、コンフォーマンス・ウィンドウのサイズに関するビットストリーム制約により、解決できるかもしれないが、その解決策は、コンフォーマンス・ウィンドウがもはやアプリケーションによって自由に選択できないという欠点をもたらすであろう。2つの機能性を分離することが、幾つかのアプリケーションでは有利であるかもしれない。
【0093】
実施形態において、コンフォーマンス・ウィンドウ・サイズは、PPSでシグナリングされてもよい。コンフォーマンス・ウィンドウ・パラメータは、参照ピクチャのコンフォーマンス・ウィンドウ・サイズが現在のピクチャのものと相違する場合に、リサンプリング比率を計算するために使用されることが可能である。デコーダは、リサンプリング・プロセスが必要であるかどうかを決定するために、各ピクチャのコンフォーマンス・ウィンドウ・サイズを認識する必要がある可能性がある。
【0094】
実施形態では、参照ピクチャ・リサンプリング（RPR）のためのスケール因子は、現在のピクチャと参照ピクチャとの間の、コンフォーマンス・ウィンドウ・パラメータから導出されることが可能な出力幅と出力高さとに基づいて、計算されることが可能である。これは、復号化されたピクチャ・サイズを使用することと比較して、スケーリング因子がより正確に計算されることを許容する可能性がある。これは、ほとんどのビデオ・シーケンスで良好に機能する可能性があり、出力ピクチャ・サイズは復号化されたピクチャ・サイズとほぼ同じであり、僅かなパディングされた領域を有する。
【0095】
しかしながら、これも様々な問題を引き起こす可能性がある。例えば、イマーシブ・メディア・アプリケーション（例えば、360キューブ・マップ、立体視、ポイント・クラウド）に関し、コンフォーマンス・ウィンドウ・サイズが、大きなオフセット値により、復号化されたピクチャ・サイズと全く異なる場合、コンフォーマンス・ウィンドウ・サイズに基づくスケーリング因子の計算は、異なる解像度でのインター予測の品質を保証しない可能性がある。極端な場合には、参照ピクチャ内で現在のCUの同等位置の領域（collocated region）が存在しない可能性がある。RPRが多層のスケーラビリティに使用される場合、コンフォーマンス・ウィンドウ・オフセットは、層間で参照される領域の計算に使用されない可能性がある。直接的に依存する各層のうちの参照される領域は、HEVCスケーラビリティ拡張（SHVC）では、PPS-extensionで明示的にシグナリングされることに留意されたい。特定の領域（サブ・ピクチャ）をターゲットとするサブ・ビットストリームが、ビットストリーム全体から抽出される場合、コンフォーマンス・ウィンドウ・サイズは、ピクチャ・サイズと全く一致しない。一旦ビットストリームが符号化されると、パラメータがスケーリング計算に使用される限り、コンフォーマンス・ウィンドウ・パラメータは更新され得ないことに留意されたい。
【0096】
上記の潜在的な問題に起因して、コンフォーマンス・ウィンドウ・サイズに基づくスケーリング因子の計算は、コーナー・ケースを有する可能性があり、その場合には代替的なパラメータが必要とされる。フォールバックとして、コンフォーマンス・ウィンドウ・パラメータがスケーリング因子の計算に使用されない場合、RPR及びスケーラビリティのスケーリングを計算するために使用することが可能な参照領域パラメータをシグナリングすることが提案される。
【0097】
図7を参照すると、実施形態では、conformance_window_flagは、PPSでシグナリングされることが可能である。1に等しいconformance_window_flagは、コンフォーマンス・クロッピング・ウィンドウ・オフセット・パラメータがPPS内で次に続くことを指定することが可能である。0に等しいconformance_window_flagは、コンフォーマンス・クロッピング・ウィンドウ・オフセット・パラメータが存在しないことを指定することが可能である。
【0098】
引き続き図7を参照すると、実施形態では、conf_win_left_offset， conf_win_right_offset，conf_win_top_offset，及びconf_win_bottom_offsetは、復号化プロセスにより出力されるPPSを参照するピクチャのサンプルを、出力用のピクチャ座標で指定される矩形領域の観点から指定する。conformance_window_flagが0に等しい場合、conf_win_left_offset，conf_win_right_offset，conf_win_top_offset，及び conf_win_bottom_offsetの値は、0に等しいと推定されてもよい。
【0099】
実施形態において、コンフォーマンス・クロッピング・ウィンドウは、SubWidthC * conf_win_left_offsetからpic_width_in_luma_samples ― ( SubWidthC * conf_win_right_offset + 1 )までの水平ピクチャ座標と、SubHeightC * conf_win_top_offsetからpic_height_in_luma_samples ― ( SubHeightC * conf_win_bottom_offset + 1 )までの垂直座標とを両端を含めて伴うルマ・サンプルを含む可能性がある。
【0100】
SubWidthC * ( conf_win_left_offset + conf_win_right_offset )の値は、pic_width_in_luma_samplesより小さい可能性があり、SubHeightC * ( conf_win_top_offset + conf_win_bottom_offset )の値は、pic_height_in_luma_samplesより小さいものとする。
【0101】
変数PicOutputWidthL及びPicOutputHeightLは、以下の式（Equation 1）及び（Equation 2）に示されるようにして導出されてもよい：
PicOutputWidthL = pic_width_in_luma_samples ―
SubWidthC * ( conf_win_right_offset + conf_win_left_offset ) (Equation 1)
PicOutputHeightL = pic_height_in_pic_size_units ―
SubHeightC * ( conf_win_bottom_offset + conf_win_top_offset ) (Equation 2)
PicOutputWidthL = pic_width_in_luma_samples ―
SubWidthC * ( conf_win_right_offset + conf_win_left_offset ) (Equation 1)
PicOutputHeightL = pic_height_in_pic_size_units ―
SubHeightC * ( conf_win_bottom_offset + conf_win_top_offset ) (Equation 2)
【0102】
ChromaArrayTypeが0に等しくない場合、2つのクロマ・アレイの対応する指定されるサンプルは、ピクチャ座標を有するサンプルであるとすることが可能であり（x / SubWidthC, y / SubHeightC）、ここで、（x，y）は指定されたルマ・サンプルのピクチャ座標である。
【0103】
実施形態では、フラグは、PPS又は他のパラメータ・セット内に存在することが可能であり、リサンプリング・ピクチャサイズ（幅及び高さ）が、PPS又は他のパラメータ・セット内で明示的にシグナリングされるかどうかを示すことが可能である。リサンプリング・ピクチャ・サイズ・パラメータが明示的にシグナリングされる場合、現在のピクチャと参照ピクチャとの間のリサンプリング比率は、リサンプリング・ピクチャ・サイズ・パラメータに基づいて計算されてもよい。
【0104】
図8Aを参照すると、実施形態では、0に等しいuse_conf_win_for_rpr_flagは、resampled_pic_width_in_luma_samples及びresampled_pic_height_in_luma_samplesが、適切な位置、例えばPPS内で次に続くことを指定することが可能である。
【0105】
実施形態では、1に等しいuse_conf_win_for_rpr_flagは、resampling_pic_width_in_luma_samples及びresampling_pic_height_in_luma_samplesが、存在しないことを指定することが可能である。
【0106】
実施形態では、resampling_pic_width_in_luma_samplesは、リサンプリングのために、PPSを参照する各参照ピクチャの幅を、ルマ・サンプルの単位で指定することが可能である。resampling_pic_width_in_luma_samplesは、0に等しくない可能性があり、Max( 8, MinCbSizeY )の整数倍である可能性があり、pic_width_max_in_luma_samples以下である可能性がある。
【0107】
実施形態では、resampling_pic_height_in_luma_samplesは、リサンプリングのために、PPSを参照する各参照ピクチャの高さを、ルマ・サンプルの単位で指定することが可能である。resampling_pic_height_in_luma_samplesは、0に等しくない可能性があり、Max( 8, MinCbSizeY )の整数倍である可能性があり、pic_height_max_in_luma_samples以下である可能性がある。
【0108】
シンタックス要素resampling_pic_width_in_luma_samplesが存在しない場合、resampling_pic_width_in_luma_samplesの値は、PicOutputWidthLに等しいと推定されてもよい。
【0109】
シンタックス要素resampling_pic_height_in_luma_samplesが存在しない場合、resampling_pic_height_in_luma_samplesの値は、PicOutputHeightLに等しいと推定されてもよい。
【0110】
実施形態では、参照ピクチャ・リサンプリングを伴う部分補間プロセス例は、以下のようにして処理されることが可能である：
【0111】
このプロセスに対する入力は：現在のピクチャの左上ルマ・サンプルに対する、現在のコーディング・サブブロックの左上サンプルを指定するルマ位置（xSb, ySb），現在のコーディング・サブブロックの幅を指定する変数sbWidth，現在のコーディング・サブブロックの高さを指定する変数sbHeight，動きベクトル・オフセットmvOffset，洗練された動きベクトルrefMvLX，選択された参照ピクチャ・サンプル・アレイrefPicLX，ハーフ・サンプル補間フィルタ・インデックスhpelIfIdx，双方向オプティカル・フロー・フラグbdofFlag，及び現在のブロックのカラー成分インデックスを指定する変数cIdxであってもよい。
【0112】
このプロセスの出力は：予測サンプル値の(sbWidth + brdExtSize)x(sbHeight + brdExtSize)のアレイpredSamplesLXであってもよい。
【0113】
予測ブロック・ボーダー拡張サイズbrdExtSizeは、式（Equation 3）に従って導出されてもよい：
brdExtSize = ( bdofFlag | | ( inter_affine_flag[ xSb ][ ySb ] && sps_affine_prof_enabled_flag ) ) ? 2 : 0 (Equation 3)
brdExtSize = ( bdofFlag | | ( inter_affine_flag[ xSb ][ ySb ] && sps_affine_prof_enabled_flag ) ) ? 2 : 0 (Equation 3)
【0114】
変数fRefWidthは、ルマ・サンプルにおける参照ピクチャのresampling_pic_width_in_luma_samplesに等しく設定されてもよい。
【0115】
変数fRefHeightは、ルマ・サンプルにおける参照ピクチャのresampling_pic_height_in_luma_samplesに等しく設定されてもよい。
【0116】
動きベクトルmvLXは、( refMvLX ― mvOffset )に等しく設定されてもよい。
【0117】
cIdxが0に等しい場合、スケーリング因子及びそれらの固定点表現は、以下の式（Equation 4）及び（Equation 5）に従って定められてもよい：
hori_scale_fp = ((fRefWidth << 14 ) + ( resampling_pic_width_in_luma_samples >> 1)) / resampling_pic_width_in_luma_samples (Equation 4)
vert_scale_fp = ((fRefHeight << 14 ) + ( resampling_pic_height_in_luma_samples >> 1)) / resampling_pic_height_in_luma_samples (Equation 5)
hori_scale_fp = ((fRefWidth << 14 ) + ( resampling_pic_width_in_luma_samples >> 1)) / resampling_pic_width_in_luma_samples (Equation 4)
vert_scale_fp = ((fRefHeight << 14 ) + ( resampling_pic_height_in_luma_samples >> 1)) / resampling_pic_height_in_luma_samples (Equation 5)
【0118】
(xIntL, yIntL)をフル・サンプル単位で与えられるルマ位置であるとし、(xFracL, yFracL)を1/16サンプル単位で与えられるオフセットであるとする。これらの変数は、参照サンプル・アレイrefPicLX内の分数サンプル位置を指定するために使用することができる。
【0119】
参照サンプル・パディングの境界ブロックの左上の座標( xSbIntL, ySbIntL )は、( xSb + ( mvLX[ 0 ] >> 4 ), ySb + ( mvLX[ 1 ] >> 4 ) )に等しく設定されてもよい。
【0120】
予測ルマ・サンプル・アレイpredSamplesLX内の各ルマ・サンプル位置( xL = 0..sbWidth ― 1 + brdExtSize, yL = 0..sbHeight ― 1 + brdExtSize )に関し、対応する予測ルマ・サンプル値predSamplesLX[ xL ][ yL ]は、次のようにして導出されてもよい：
－ ( refxSbL, refySbL )及び( refxL, refyL )を、1/16サンプル単位で与えられる動きベクトル( refMvLX, refMvLX )で指し示されるルマ位置であるとする。変数refxSbL, refxL, refySbL, 及びrefyLは、以下に示される式（Equation 6）ないし（Equation 9）で示されるようにして導出されてもよい：
refxSbL = ( ( xSb << 4 ) + refMvLX[ 0 ] ) * hori_scale_fp (Equation 6)
refxL = ( ( Sign( refxSb ) * ( ( Abs( refxSb ) + 128 ) >> 8 )
+ xL * ( ( hori_scale_fp + 8 ) >> 4 ) ) + 32 ) >> 6 (Equation 7)
refySbL = ( ( ySb << 4 ) + refMvLX[ 1 ] ) * vert_scale_fp (Equation 8)
refyL = ( ( Sign( refySb ) * ( ( Abs( refySb ) + 128 ) >> 8 ) + yL *
( ( vert_scale_fp + 8 ) >> 4 ) ) + 32 ) >> 6 (Equation 9)
－ 変数xIntL, yIntL, xFracL及びyFracLは、以下に示される式（Equation 10）ないし（Equation 13）で示されるようにして導出されてもよい：
xIntL = refxL >> 4 (Equation 10)
yIntL = refyL >> 4 (Equation 11)
xFracL = refxL & 15 (Equation 12)
yFracL = refyL & 15 (Equation 13)
－ ( refxSbL, refySbL )及び( refxL, refyL )を、1/16サンプル単位で与えられる動きベクトル( refMvLX, refMvLX )で指し示されるルマ位置であるとする。変数refxSbL, refxL, refySbL, 及びrefyLは、以下に示される式（Equation 6）ないし（Equation 9）で示されるようにして導出されてもよい：
refxSbL = ( ( xSb << 4 ) + refMvLX[ 0 ] ) * hori_scale_fp (Equation 6)
refxL = ( ( Sign( refxSb ) * ( ( Abs( refxSb ) + 128 ) >> 8 )
+ xL * ( ( hori_scale_fp + 8 ) >> 4 ) ) + 32 ) >> 6 (Equation 7)
refySbL = ( ( ySb << 4 ) + refMvLX[ 1 ] ) * vert_scale_fp (Equation 8)
refyL = ( ( Sign( refySb ) * ( ( Abs( refySb ) + 128 ) >> 8 ) + yL *
( ( vert_scale_fp + 8 ) >> 4 ) ) + 32 ) >> 6 (Equation 9)
－ 変数xIntL, yIntL, xFracL及びyFracLは、以下に示される式（Equation 10）ないし（Equation 13）で示されるようにして導出されてもよい：
xIntL = refxL >> 4 (Equation 10)
yIntL = refyL >> 4 (Equation 11)
xFracL = refxL & 15 (Equation 12)
yFracL = refyL & 15 (Equation 13)
【0121】
bdofFlagがTRUEに等しいか、又は( sps_affine_prof_enabled_flagがTRUEに等しく、且つinter_affine_flag[ xSb ][ ySb ]がTRUEに等しく)、且つ以下の条件のうちの1つ以上がTRUEである場合、予測ルマ・サンプル値predSamplesLX[ xL ][ yL ]は、( xIntL + ( xFracL >> 3) ― 1), yIntL + ( yFracL >> 3 ) ― 1 )を入力として、ルマ整数サンプル取得プロセスを起動することによって導出されてもよい：
－ xLが0に等しいこと。
－ xLがsbWidth + 1に等しいこと。
－ yLが0に等しいこと。
－ yLがsbHeight + 1に等しいこと。
－ xLが0に等しいこと。
－ xLがsbWidth + 1に等しいこと。
－ yLが0に等しいこと。
－ yLがsbHeight + 1に等しいこと。
【0122】
それ以外の場合、予測ルマ・サンプル値predSamplesLX[ xL ][ yL ]は、( xIntL ― ( brdExtSize > 0 ? 1 : 0 ), yIntL ― ( brdExtSize > 0 ? 1 : 0 ) ), ( xFracL, yFracL ), ( xSbIntL, ySbIntL ), refPicLX, hpelIfIdx, sbWidth, sbHeight及び( xSb, ySb )を入力として、ルマ・サンプル8タップ補間フィルタリング・プロセスを起動することによって導出される。
【0123】
それ以外の場合（cIdxが0に等しくない場合）、以下を適用してもよい：
【0124】
(xIntC, yIntC)をフル・サンプル単位で与えられるクロマ位置であるとし、(xFracC, yFracC)を1/32サンプル単位で与えられるオフセットであるとする。これらの変数は、参照サンプル・アレイrefPicLX内の一般的な分数サンプル位置を指定するために使用されることが可能である。
【0125】
参照サンプル・パディングのための境界ボックスの左上座標( xSbIntC, ySbIntC )は、 ( (xSb / SubWidthC ) + ( mvLX[ 0 ] >> 5), ( ySb / SubHeightC ) + ( mvLX[ 1 ] >> 5 ) )に等しく設定されてもよい。
【0126】
予測クロマ・サンプル・アレイpreSamplesLX内の各クロマ・サンプル位置(xC = 0..sbWidth - 1, yC = 0..sbHeight - 1)に関し、対応する予測クロマ・サンプル値preSamplesLX [xC][yC]は、次のようにして導出されてもよい：
－ (refxSbC, refySbC)及び( refxC, refyC )を、1/32サンプル単位で与えられる動きベクトル(mvLX[ 0 ], mvLX[ 1 ])を指し示すクロマ位置であるとする。変数refxSbC, refySbC, refxC及びrefyCは、以下に示される式（Equation 14）ないし（Equation 17）で示されるようにして導出されてもよい：
refxSbC = ( ( xSb / SubWidthC << 5 ) + mvLX[ 0 ] ) * hori_scale_fp (Equation 14)
refxC = ( ( Sign( refxSbC ) * ( ( Abs( refxSbC ) + 256 ) >> 9 )
+ xC * ( ( hori_scale_fp + 8 ) >> 4 ) ) + 16 ) >> 5 (Equation 15)
refySbC = ( ( ySb / SubHeightC << 5 ) + mvLX[ 1 ] ) * vert_scale_fp (Equation 16)
refyC = ( ( Sign( refySbC ) * ( ( Abs( refySbC ) + 256 ) >> 9 )
+ yC* ( ( vert_scale_fp + 8 ) >> 4 ) ) + 16 ) >> 5 (Equation 17)
－ 変数xIntC, yIntC, xFracC及びyFracCは、以下に示される式（Equation 18）ないし（Equation 21）で示されるようにして導出されてもよい：
xIntC = refxC >> 5 (Equation 18)
yIntC = refyC >> 5 (Equation 19)
xFracC = refyC & 31 (Equation 20)
yFracC = refyC & 31 (Equation 21)
－ (refxSbC, refySbC)及び( refxC, refyC )を、1/32サンプル単位で与えられる動きベクトル(mvLX[ 0 ], mvLX[ 1 ])を指し示すクロマ位置であるとする。変数refxSbC, refySbC, refxC及びrefyCは、以下に示される式（Equation 14）ないし（Equation 17）で示されるようにして導出されてもよい：
refxSbC = ( ( xSb / SubWidthC << 5 ) + mvLX[ 0 ] ) * hori_scale_fp (Equation 14)
refxC = ( ( Sign( refxSbC ) * ( ( Abs( refxSbC ) + 256 ) >> 9 )
+ xC * ( ( hori_scale_fp + 8 ) >> 4 ) ) + 16 ) >> 5 (Equation 15)
refySbC = ( ( ySb / SubHeightC << 5 ) + mvLX[ 1 ] ) * vert_scale_fp (Equation 16)
refyC = ( ( Sign( refySbC ) * ( ( Abs( refySbC ) + 256 ) >> 9 )
+ yC* ( ( vert_scale_fp + 8 ) >> 4 ) ) + 16 ) >> 5 (Equation 17)
－ 変数xIntC, yIntC, xFracC及びyFracCは、以下に示される式（Equation 18）ないし（Equation 21）で示されるようにして導出されてもよい：
xIntC = refxC >> 5 (Equation 18)
yIntC = refyC >> 5 (Equation 19)
xFracC = refyC & 31 (Equation 20)
yFracC = refyC & 31 (Equation 21)
【0127】
予測サンプル値predSamplesLX[ xC ][ yC ]は、( xIntC, yIntC ), ( xFracC, yFracC ), ( xSbIntC, ySbIntC ), sbWidth, sbHeight及びrefPicLXを入力としてプロセスを起動することによって導出されてもよい。
【0128】
図8Bを参照すると、実施形態では、0に等しいuse_conf_win_for_rpr_flagは、resampled_pic_width_in_luma_samples及びresampled_pic_height_in_luma_samplesが、PPS内で次に続くことを指定することが可能である。1に等しいuse_conf_wid_for_rpr_flagは、resampling_pic_width_in_luma_samples及びresampling_pic_height_in_luma_samplesが存在しないことを指定する。
【0129】
実施形態では、ref_region_left_offsetは、復号化されたピクチャ内の参照領域の左上ルマ・サンプル間の水平オフセットを指定することが可能である。ref_region_left_offsetの値は、-214～214-1の両端を含む範囲内にあるものとする。存在しない場合、ref_region_left_offsetの値は、conf_win_left_offsetに等しいと推定されてもよい。
【0130】
実施形態では、ref_region_top_offsetは、復号化されたピクチャ内の参照領域の左上ルマ・サンプル間の垂直オフセットを指定することが可能である。ref_region_top_offsetの値は、-214～214-1の両端を含む範囲内にあるものとする。存在しない場合、ref_region_top_offsetの値は、conf_win_right_offsetに等しいと推定されてもよい。
【0131】
実施形態では、ref_region_right_offsetは、復号化されたピクチャ内の参照領域の右下ルマ・サンプル間の水平オフセットを指定することが可能である。ref_layer_right_offsetの値は、-214～214-1の両端を含む範囲内にあるものとする。存在しない場合、ref_region_right_offsetの値は、conf_win_top_offsetに等しいと推定されてもよい。
【0132】
実施形態では、ref_region_bottom_offsetは、復号化されたピクチャ内の参照領域の右下ルマ・サンプル間の垂直オフセットを指定することが可能である。ref_layer_bottom_offsetの値は、-214～214-1の両端を含む範囲内にあるものとする。存在しない場合、ref_region_bottom_offset[ ref_loc_offset_layer_id[ i ] ]の値は、conf_win_bottom_offsetに等しいと推定されてもよい。
【0133】
変数PicRefWidthL及びPicRefHeightLは、以下に示される式（Equation 22）ないし（Equation 23）で示されるようにして導出されてもよい：
PicRefWidthL = pic_width_in_luma_samples ―
SubWidthC * ( ref_region_right_offset + ref_region_left_offset ) (Equation 22)
PicRefHeightL = pic_height_in_pic_size_units ―
SubHeightC * ( ref_region_bottom_offset + ref_region_top_offset) (Equation 23)
PicRefWidthL = pic_width_in_luma_samples ―
SubWidthC * ( ref_region_right_offset + ref_region_left_offset ) (Equation 22)
PicRefHeightL = pic_height_in_pic_size_units ―
SubHeightC * ( ref_region_bottom_offset + ref_region_top_offset) (Equation 23)
【0134】
変数fRefWidthは、ルマ・サンプルの参照ピクチャのPicRefWidthLに等しく設定されてもよい。
【0135】
変数fRefHeightは、ルマ・サンプルの参照ピクチャのPicRefHeightLに等しく設定されてもよい。
【0136】
動きベクトルmvLXは、( refMvLX ― mvOffset )に等しく設定されてもよい。
【0137】
cIdxが0に等しい場合、スケーリング因子及びそれらの固定点表現は、以下に示されるように式（Equation 24）及び（Equation 25）に示されるようにして定められてもよい：
hori_scale_fp = ( ( fRefWidth << 14 ) + ( PicRefWidthL >> 1 ) ) / PicRefWidthL (Equation 24)
vert_scale_fp = ( ( fRefHeight << 14 ) + ( PicRefHeightL >> 1 ) ) / PicRefHeight (Equation 25)
hori_scale_fp = ( ( fRefWidth << 14 ) + ( PicRefWidthL >> 1 ) ) / PicRefWidthL (Equation 24)
vert_scale_fp = ( ( fRefHeight << 14 ) + ( PicRefHeightL >> 1 ) ) / PicRefHeight (Equation 25)
【0138】
参照サンプル・パディングのための境界ボックスの左上座標( xSbIntL, ySbIntL )は、( xSb + ( mvLX[ 0 ] >> 4 ), ySb + ( mvLX[ 1 ] >> 4 ) )に等しく設定されてもよい。
【0139】
予測ルマ・サンプル・アレイpredSamplesLX内の各ルマ・サンプル位置( xL = 0..sbWidth ― 1 + brdExtSize, yL = 0..sbHeight ― 1 + brdExtSize )に関し、対応する予測ルマ・サンプル値predSamplesLX[ xL ][ yL ]は、次のようにして導出されてもよい：
－ ( refxSbL, refySbL )及び( refxL, refyL )を、1/16サンプル単位で与えられる動きベクトル( refMvLX, refMvLX )で指し示されるルマ位置であるとする。変数refxSbL, refxL, refySbL,及びrefyLは、以下に示される式（Equation 26）ないし（Equation 29）で示されるようにして導出されてもよい：
refxSbL = ( ( (xSb+ ref_region_left_offset) << 4 ) + refMvLX[ 0 ] ) * hori_scale_fp (Equation 26)
refxL = ( ( Sign( refxSb ) * ( ( Abs( refxSb ) + 128 ) >> 8 )
+ xL * ( ( hori_scale_fp + 8 ) >> 4 ) ) + 32 ) >> 6 (Equation 27)
refySbL = ( ( (ySb+ ref_region_top_offset) << 4 ) + refMvLX[ 1 ] ) * vert_scale_fp (Equation 28)
refyL = ( ( Sign( refySb ) * ( ( Abs( refySb ) + 128 ) >> 8 ) + yL *
( ( vert_scale_fp + 8 ) >> 4 ) ) + 32 ) >> 6 (Equation 29)
－ ( refxSbL, refySbL )及び( refxL, refyL )を、1/16サンプル単位で与えられる動きベクトル( refMvLX, refMvLX )で指し示されるルマ位置であるとする。変数refxSbL, refxL, refySbL,及びrefyLは、以下に示される式（Equation 26）ないし（Equation 29）で示されるようにして導出されてもよい：
refxSbL = ( ( (xSb+ ref_region_left_offset) << 4 ) + refMvLX[ 0 ] ) * hori_scale_fp (Equation 26)
refxL = ( ( Sign( refxSb ) * ( ( Abs( refxSb ) + 128 ) >> 8 )
+ xL * ( ( hori_scale_fp + 8 ) >> 4 ) ) + 32 ) >> 6 (Equation 27)
refySbL = ( ( (ySb+ ref_region_top_offset) << 4 ) + refMvLX[ 1 ] ) * vert_scale_fp (Equation 28)
refyL = ( ( Sign( refySb ) * ( ( Abs( refySb ) + 128 ) >> 8 ) + yL *
( ( vert_scale_fp + 8 ) >> 4 ) ) + 32 ) >> 6 (Equation 29)
【0140】
図9を参照すると、実施形態では、参照ピクチャ・リサンプリングのためのリサンプリング比率がコンフォーマンス・ウィンドウ・サイズに基づいて計算される場合に、インター・ピクチャ動き補償予測を伴う現在のブロック復号化プロセスを実行するデコーダは、参照ピクチャ内の復号化されたピクセルの外にある1つ以上のピクセルにアクセスする可能性がある。幾つかの例では、復号化プロセスは、DPBにおいて利用不能な復号化されたピクチャを使用する可能性があり、その結果、デコーダがクラッシュしてしまったり、或いは望ましくない復号化挙動が生じてしまったりする可能性がある。
【0141】
例えば、図9に示すように、復号化されたピクチャ・サイズ903及びコンフォーマンス・ウィンドウ・サイズ904を有する復号化されたピクチャと、復号化されたピクチャ・サイズ901及びコンフォーマンス・ウィンドウ・サイズ902を有する参照ピクチャとに基づいて、現在のブロック906に対する復号化プロセスは、利用不能である参照ブロック905を使用してしまう可能性がある。
【0142】
このような問題に対処するために、場合によっては、参照ピクチャのリサンプリングのためのリサンプリング比率の計算に、リサンプリング・ピクチャ・サイズの明示的なシグナリングを使用することが可能である。
【0143】
実施形態では、コンフォーマンス・ウィンドウ・サイズが実際のリサンプリング比率に整合しない場合、コンフォーマンス・ウィンドウ・サイズは、参照ピクチャ・リサンプリングのためのリサンプリング比率の計算に使用するには適切でない可能性がある。例えば、現在のピクチャが立体視サブ・ピクチャ（左及び右）、又は360ピクチャの複数フェース（例えば、キューブマップ投影の6面）で構成される場合、コンフォーマンス・ウィンドウ・サイズは、所望のリサンプリング比率と異なる可能性がある。場合によっては、コンフォーマンス・ウィンドウ・サイズは、復号化されたピクチャのサブ領域をカバーしている可能性がある。そのような場合、代替的に、リサンプリング・ピクチャ・サイズがリサンプリング比率の計算のために使用されてもよい。
【0144】
図10は、符号化されたビデオ・ビットストリームを復号化するための例示的なプロセス1000である。幾つかの実装形態では、図10の1つ以上のプロセス・ブロックは、デコーダ210によって実行されてもよい。幾つかの実装形態では、図10の1つ以上のプロセス・ブロックは、デコーダ203のようなデコーダ210から分離された、又はデコーダ210を含む、別のデバイス又はデバイス群によって実行されてもよい。
【0145】
図10に示すように、プロセス1000は、現在のピクチャにコンフォーマンス・ウィンドウが存在することを示す第1フラグを取得することを含むことが可能である（ブロック1010）。
【0146】
図10に更に示されるように、プロセス1000は、コンフォーマンス・ウィンドウが存在することを示す第1フラグに基づいて、コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されるかどうかを示す第2フラグを取得することを含むことが可能である（ブロック1020）。
【0147】
図10に更に示されるように、プロセス1000は、第2フラグがコンフォーマンス・ウィンドウは参照ピクチャ・リサンプリングに使用されることを示すかどうかを判定することを含む可能性がある（ブロック1030）。第2フラグがコンフォーマンス・ウィンドウは参照ピクチャ・リサンプリングに使用されることを示していると判定された場合（ブロック1030でYES）、プロセス1000はブロック1040へ、次いでブロック1060へ進むことが可能である。ブロック1040において、プロセス1000は、コンフォーマンス・ウィンドウのコンフォーマンス・ウィンドウ・サイズに基づいて、現在のピクチャと参照ピクチャとの間のリサンプリング比率を決定することを含むことが可能である。
【0148】
第2フラグがコンフォーマンス・ウィンドウは参照ピクチャ・リサンプリングに使用されることを示していないと判定された場合（ブロック1030でNO）、プロセス1000はブロック1050へ、次いでブロック1060へ進むことが可能である。ブロック1050において、プロセス1000は、リサンプリング・ピクチャ・サイズに基づいてリサンプリング比率を決定することを含むことが可能である。
【0149】
図10に更に示されるように、プロセス1000は、リサンプリング比率を使用して、現在のピクチャに対して参照ピクチャ・リサンプリングを実行することを含むことが可能である（ブロック1060）。
【0150】
実施形態では、第1フラグ及び第2フラグは、ピクチャ・パラメータ・セットでシグナリングされてもよい。
【0151】
実施形態では、コンフォーマンス・ウィンドウ・サイズは、現在のピクチャの境界からの少なくとも1つのオフセット距離に基づいて決定されてもよい。
【0152】
実施形態では、少なくとも1つのオフセット距離は、ピクチャ・パラメータ・セットでシグナリングされてもよい。
【0153】
実施形態では、リサンプリング・ピクチャ・サイズは、リサンプリング・ピクチャ・サイズの幅及びリサンプリング・ピクチャ・サイズの高さのうちの少なくとも1つとして、符号化されたビデオ・ビットストリームで指定されてもよい。
【0154】
実施形態では、幅及び高さのうちの少なくとも1つは、ピクチャ・パラメータ・セットでシグナリングされてもよい。
【0155】
実施形態では、幅及び高さのうちの少なくとも1つは、幅及び高さのうちの少なくとも1つに含まれる複数のルマ・サンプルの数として表現されてもよい。
【0156】
実施形態では、リサンプリング・ピクチャ・サイズは、現在のピクチャの参照領域の左上ルマ・サンプルからの少なくとも1つのオフセット距離に基づいて決定されてもよい。
【0157】
実施形態では、少なくとも1つのオフセット距離は、ピクチャ・パラメータ・セットでシグナリングされてもよい。
【0158】
図10は、プロセス1000の例示的なブロックを示すが、幾つかの実装において、プロセス1000は、図10に示されているものに対して、追加のブロック、より少ないブロック、異なるブロック、又は別様に配置されたブロックを含んでもよい。追加的又は代替的に、プロセス1000のうちの2つ以上のブロックは、並行して実行されてもよい。
【0159】
更に、提案される方法は、処理回路（例えば、1つ以上のプロセッサ又は1つ以上の集積回路）によって実装されてもよい。一例において、1つ以上のプロセッサは、提案された方法のうちの1つ以上を実行するために、非一時的なコンピュータ読み取り可能な媒体に記憶されるプログラムを実行する。
【0160】
上述した技術は、コンピュータ読み取り可能な命令を用いるコンピュータ・ソフトウェアであって、1つ以上のコンピュータ読み取り可能な媒体に物理的に記憶することが可能なコンピュータ・ソフトウェアとして実装することが可能である。例えば、図11は、開示される対象事項の特定の実施形態を実施するのに適したコンピュータ・システム1100を示す。
【0161】
コンピュータ・ソフトウェアは、直接的に又は解釈、マイクロコード実行等を介して、コンピュータ中央処理ユニット（CPU）、グラフィックス処理ユニット（GPU）等によって実行されることが可能な命令を含むコードを生成するために、アセンブリ、コンパイル、リンク等のメカニズムの影響を受けることが可能な、任意の適切なマシン・コード又はコンピュータ言語を使用してコーディングされることが可能である。
【0162】
命令は、例えば、パーソナル・コンピュータ、タブレット・コンピュータ、サーバー、スマートフォン、ゲーム装置、モノのインターネット（IoT）等を含む、種々の種類のコンピュータ又はその構成部品において実行されることが可能である。
【0163】
コンピュータ・システム1100に関する図11に示される構成要素は、本質的に例示的なものであり、本開示の実施形態を実現するコンピュータ・ソフトウェアの用途又は機能性の範囲に関する如何なる限定も示唆するようには意図されていない。また、構成要素の構成は、コンピュータ・システム1100の例示的な実施形態に示される構成要素の任意の1つ又は組み合わせに関する何らかの従属性又は要件を有するものとして解釈されるべきではない。
【0164】
コンピュータ・システム1100は、特定のヒューマン・インターフェース入力装置を含んでもよい。このようなヒューマン・インターフェース入力装置は、例えば、触覚入力（例えば、キーストローク、スワイプ、データ・グローブの動き）、オーディオ入力（例えば、声、拍手）、視覚入力（例えば、ジェスチャ）、嗅覚入力（図示せず）を介して、1人以上の人間ユーザーによる入力に応答することができる。また、ヒューマン・インターフェース装置は、オーディオ（例えば、会話、音楽、周囲の音）、画像（例えば、スキャンされた画像、静止画像カメラから得られる写真画像）、ビデオ（例えば、2次元ビデオ、立体ビデオを含む3次元ビデオ）のような、人間による意識的入力に必ずしも直接的に関係しない特定の媒体を捕捉するために使用することも可能である。
【0165】
入力ヒューマン・インターフェース装置は、キーボード1101、マウス1102、トラックパッド1103、タッチ・スクリーン1110及び関連するグラフィックス・アダプタ1150、データ・グローブ、ジョイスティック1105、マイクロホン1106、スキャナ1107、カメラ1108のうちの1つ以上を含んでもよい。
【0166】
コンピュータ・システム1100は、特定のヒューマン・インターフェース出力装置を含むことも可能である。このようなヒューマン・インターフェース出力装置は、例えば、触覚出力、音、光、及び匂い/味を通じて、1人以上の人間ユーザーの感覚を刺激することができる。このようなヒューマン・インターフェース出力装置は、触覚出力装置（例えば、タッチ・スクリーン1110、データ・グローブ、又はジョイスティック1105による触覚フィードバックであるが、入力装置として機能しない触覚フィードバック装置が存在することも可能である）、オーディオ出力装置（例えば、スピーカ1109、ヘッドフォン（図示せず））、視覚出力装置（例えば、陰極線管（CRT）スクリーン、液晶ディスプレイ（LCD）スクリーン、プラズマ・スクリーン、有機発光ダイオード（OLED）スクリーンを含むスクリーン1110（各々はタッチ・スクリーン入力機能を備えているか又は備えておらず、各々は触覚フィードバック能力を備えているか又は備えておらず、それらのうちの一部は、2次元的な視覚出力又は立体視出力のような手段による3以上の次元の出力を出力することが可能である）、仮想現実メガネ（図示せず）、ホログラフィック・ディスプレイ、及びスモーク・タンク（図示せず））、及びプリンタ（図示せず）を含むことが可能である。
【0167】
コンピュータ・システム1100は、CD/DVD又は類似の媒体1121を有するCD/DVD ROM/RW 1120を含む光媒体、サム・ドライブ1122、取り外し可能なハード・ドライブ又はソリッド・ステート・ドライブ1123、テープ及びフロッピー・ディスク（図示せず）のようなレガシー磁気媒体、セキュリティ・ドングル（図示せず）のような特殊化されたROM/ASIC/PLDベースの装置などのような、人間がアクセスできる記憶装置及びそれらの関連媒体を含むことも可能である。
【0168】
当業者は、本開示の対象事項に関連して使用される用語「コンピュータ読み取り可能な媒体」は、伝送媒体、搬送波、又は他の一時的な信号を包含しないことも理解するはずである。
【0169】
コンピュータ・システム1100は、1つ以上の通信ネットワーク（1155）に対するインターフェースを含むことも可能である。ネットワークは、例えば、無線、有線、光であるとすることが可能である。ネットワークは、更に、ローカル、ワイド・エリア、メトロポリタン、車両及びインダストリアル、リアルタイム、遅延耐性などであるとすることが可能である。ネットワークの例は、イーサーネット、無線LAN、セルラー・ネットワーク（移動通信のためのグローバル・システム（GSM）、第3世代（3G）、第4世代（4G）、第5世代（5G）、ロング・ターム・エボリューション化などを含む）、TV有線又は無線ワイド・エリア・デジタル・ネットワーク（ケーブルTV、衛星TV、地上放送TVを含む）、CANBusを含む車両及びインダストリアル等を含む。特定のネットワークは、一般に、特定の汎用データ・ポート又は周辺バス（1149）に接続される外部ネットワーク・インターフェース・アダプタ（1154）（例えば、コンピュータ・システム1100のユニバーサル・シリアル・バス（USB）ポート）を必要とし；他のネットワークは、一般に、後述するようなシステム・バスへの接続によって、コンピュータ・システム1100のコアに組み込まれる（例えば、イーサーねと・インターフェースはPCコンピュータ・システムに組み込まれ、セルラー・ネットワーク・インターフェースはスマートフォン・コンピュータ・システムに組み込まれる）。一例として、ネットワーク1155は、ネットワーク・インターフェース1154を使用して周辺バス1149に接続されてもよい。これらの任意のネットワークを使用して、コンピュータ・システム1100は、他のエンティティと通信することができる。このような通信は、片－指向性、受信専用（例えば、放送TV）、片－指向性送信専用（例えば、特定のCANbus装置に対するCANbus）、又は、双－指向性、例えばローカル又はワイド・エリア・デジタル・ネットワークを使用する他のコンピュータ・システムに対するものであるとすることが可能である。特定のプロトコル及びプロトコル・スタックは、上述のように、それらのネットワーク及びネットワーク・インターフェース（1154）の各々で使用されることが可能である。
【0170】
前述のヒューマン・インターフェース装置、人間がアクセス可能な記憶装置、及びネットワーク・インターフェースは、コンピュータ・システム1100のコア1140に取り付けることが可能である。
【0171】
コア1140は、1つ以上の中央処理ユニット（CPU）1141、グラフィックス処理ユニット（GPU）1142、フィールド・プログラマブル・ゲート・エリア（FPGA）1143の形態における特定のプログラマブル処理ユニット、特定のタスクのためのハードウェア・アクセラレータ1144などを含むことが可能である。これらの装置は、リード・オンリ・メモリ（ROM）1145、ランダム・アクセス・メモリ（RAM）1146、内部大容量ストレージ、例えば内部のユーザー・アクセス不能なハード・ドライブ、ソリッド・ステート・ドライブ（SSD）、及び類似のもの1147と共に、システム・バス1148を介して接続されてもよい。幾つかのコンピュータ・システムでは、システム・バス1148は、追加のCPU、GPUなどによる拡張を可能にするために、1つ以上の物理プラグの形態でアクセス可能であるとすることが可能である。周辺装置は、コアのシステム・バス1148に直接的に取り付けること、或いは周辺バス1149を介して取り付けることが可能である。周辺バスのアーキテクチャは、周辺コンポーネント相互接続（PCI）、USB等を含む。
【0172】
CPU1141、GPU1142、FPGA1143、及びアクセラレータ1144は、組み合わされて、上述のコンピュータ・コードを構築することが可能な特定の命令を実行することが可能である。そのコンピュータ・コードは、ROM 1145又はRAM 1146に記憶することが可能である。一時的なデータはRAM 1146に記憶することも可能である一方、永続的なデータは、例えば内部大容量ストレージ1147に記憶することが可能である。1つ以上のCPU 1141、GPU1142、大容量ストレージ1147、ROM 1145、RAM 1146などと密接に関連付けることが可能なキャッシュ・メモリを使用することによって、任意のメモリ・デバイスに対する高速な記憶及び検索を可能にすることができる。
【0173】
コンピュータ読み取り可能な媒体は、様々なコンピュータ実装済み動作を実行するためのコンピュータ・コードをそこに有することが可能である。媒体及びコンピュータ・コードは、本開示の目的のために特別に設計及び構築されたものであるとすることが可能であり、或いはそれらは、コンピュータ・ソフトウェアの分野の当業者に周知で利用可能な種類のものであるとすることが可能である。
【0174】
限定ではなく一例として、アーキテクチャ1100、具体的にはコア1140を有するコンピュータ・システムは、1つ以上の有形のコンピュータ読み取り可能な媒体に具現化されたソフトウェアを実行するプロセッサ（CPU、GPU、FPGA、アクセラレータ等を含む）に由来する機能を提供することができる。そのようなコンピュータ読み取り可能な媒体は、コア内部大容量ストレージ1147又はROM 1145のような非一時的な性質のコア1140の特定のストレージと同様に、上述したようなユーザー・アクセス可能な大容量ストレージに関連する媒体であるとすることが可能である。本開示の様々な実施形態を実装するソフトウェアは、そのような装置に記憶され、コア1140によって実行されることが可能である。コンピュータ読み取り可能な媒体は、特定のニーズに応じて、1つ以上のメモリ・デバイス又はチップを含むことが可能である。ソフトウェアは、コア1140、特にその中のプロセッサ（CPU、GPU、FPGAなどを含む）が、RAM 1146に記憶されたデータ構造を定め、そのようなデータ構造をソフトウェアによって定められたプロセスに従って修正することを含む、本願で説明される特定のプロセス又は特定のプロセスの一部分を実行することを引き起こすことが可能である。更に又は代替として、コンピュータ・システムは、回路（例えば、アクセラレータ1144）内に配線されたロジック又はその他の方法で組み込まれたものの結果として機能を提供することが可能であり、回路は、本願で説明される特定のプロセス又は特定のプロセスの特定の部分を実行するために、ソフトウェアの代わりに又はソフトウェアと共に動作することが可能である。ソフトウェアに対する言及は、ロジックを含むことが可能であり、必要に応じてその逆も可能である。コンピュータ読み取り可能な媒体に対する参照は、実行用のソフトウェアを記憶する回路（例えば、集積回路（IC））、実行用のロジックを具現化する回路、又は適切な場合にはそれら両方を含むことが可能である。本開示は、ハードウェア及びソフトウェアの任意の適切な組み合わせを包含する。
【0175】
本開示は、幾つかの例示的な実施形態を説明してきたが、本開示の範囲内に該当する変更、置換、及び種々の代替的な均等物が存在する。従って、本願で明示的には図示も説明もされていないが、本開示の原理を具現化し、従ってその精神及び範囲内にある多くのシステム及び方法を、当業者は案出することが可能であろうということが、認められるであろう。
【0176】
（付記1）
少なくとも1つのプロセッサを利用して、符号化されたビデオ・ビットストリームを復号化する方法であって、
現在のピクチャにコンフォーマンス・ウィンドウが存在することを示す第1フラグを取得するステップと、
前記コンフォーマンス・ウィンドウが存在することを示す前記第1フラグに基づいて、前記コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されるかどうかを示す第2フラグを取得するステップと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されることを示す前記第2フラグに基づいて、前記現在のピクチャ及び参照ピクチャの間のリサンプリング比率を、前記コンフォーマンス・ウィンドウのコンフォーマンス・ウィンドウ・サイズに基づいて決定するステップと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されないことを示す前記第2フラグに基づいて、前記リサンプリング比率をリサンプリング・ピクチャ・サイズに基づいて決定するステップと、
前記リサンプリング比率を利用して、前記現在のピクチャに対する前記参照ピクチャ・リサンプリングを実行するステップと
を含む方法。
（付記2）
前記第1フラグ及び前記第2フラグは、ピクチャ・パラメータ・セットでシグナリングされる、付記1に記載の方法。
（付記3）
前記コンフォーマンス・ウィンドウ・サイズは、前記現在のピクチャのボーダーからの少なくとも1つのオフセット距離に基づいて決定される、付記1に記載の方法。
（付記4）
前記少なくとも1つのオフセット距離は、ピクチャ・パラメータ・セットでシグナリングされる、付記3に記載の方法。
（付記5）
前記リサンプリング・ピクチャ・サイズは、前記リサンプリング・ピクチャ・サイズの幅及び前記リサンプリング・ピクチャ・サイズの高さのうちの少なくとも1つとして、前記符号化されたビデオ・ビットストリームで指定される、付記1に記載の方法。
（付記6）
前記幅及び前記は高さのうちの少なくとも1つは、ピクチャ・パラメータ・セットでシグナリングされる、付記5に記載の方法。
（付記7）
前記幅及び前記は高さのうちの少なくとも1つは、前記幅及び前記は高さのうちの少なくとも1つに含まれるルマ・サンプルの数として表現される、付記5に記載の方法。
（付記8）
前記リサンプリング・ピクチャ・サイズは、前記現在のピクチャの参照領域の左上ルマ・サンプルからの少なくとも1つのオフセット距離に基づいて決定される、付記1に記載の方法。
（付記9）
前記少なくとも1つのオフセット距離は、ピクチャ・パラメータ・セットでシグナリングされる、付記8に記載の方法。
（付記10）
符号化されたビデオ・ビットストリームを復号化する装置であって、
プログラム・コードを記憶するように構成された少なくとも1つのメモリと、
前記プログラム・コードを読み込み、前記プログラム・コードによって指示されるように動作する少なくとも1つのプロセッサと
を含み、前記プログラム・コードは、
現在のピクチャにコンフォーマンス・ウィンドウが存在することを示す第1フラグを取得することを、前記少なくとも1つのプロセッサに行わせるように構成された第1取得コードと、
前記コンフォーマンス・ウィンドウが存在することを示す前記第1フラグに基づいて、前記コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されるかどうかを示す第2フラグを取得することを、前記少なくとも1つのプロセッサに行わせるように構成された第2取得コードと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されることを示す前記第2フラグに基づいて、前記現在のピクチャ及び参照ピクチャの間のリサンプリング比率を、前記コンフォーマンス・ウィンドウのコンフォーマンス・ウィンドウ・サイズに基づいて決定することを、前記少なくとも1つのプロセッサに行わせるように構成された第1決定コードと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されないことを示す前記第2フラグに基づいて、前記リサンプリング比率をリサンプリング・ピクチャ・サイズに基づいて決定することを、前記少なくとも1つのプロセッサに行わせるように構成された第2決定コードと、
前記リサンプリング比率を利用して、前記現在のピクチャに対する前記参照ピクチャ・リサンプリングを実行することを、前記少なくとも1つのプロセッサに行わせるように構成された実行コードと
を含む、装置。
（付記11）
前記第1フラグ及び前記第2フラグは、ピクチャ・パラメータ・セットでシグナリングされる、付記10に記載の装置。
（付記12）
前記コンフォーマンス・ウィンドウ・サイズは、前記現在のピクチャのボーダーからの少なくとも1つのオフセット距離に基づいて決定される、付記10に記載の装置。
（付記13）
前記少なくとも1つのオフセット距離は、ピクチャ・パラメータ・セットでシグナリングされる、付記12に記載の装置。
（付記14）
前記リサンプリング・ピクチャ・サイズは、前記リサンプリング・ピクチャ・サイズの幅及び前記リサンプリング・ピクチャ・サイズの高さのうちの少なくとも1つとして、前記符号化されたビデオ・ビットストリームで指定される、付記10に記載の装置。
（付記15）
前記幅及び前記は高さのうちの少なくとも1つは、ピクチャ・パラメータ・セットでシグナリングされる、付記14に記載の装置。
（付記16）
前記幅及び前記は高さのうちの少なくとも1つは、前記幅及び前記は高さのうちの少なくとも1つに含まれるルマ・サンプルの数として表現される、付記14に記載の装置。
（付記17）
前記リサンプリング・ピクチャ・サイズは、前記現在のピクチャの参照領域の左上ルマ・サンプルからの少なくとも1つのオフセット距離に基づいて決定される、付記10に記載の装置。
（付記18）
前記少なくとも1つのオフセット距離は、ピクチャ・パラメータ・セットでシグナリングされる、付記17に記載の装置。
（付記19）
命令を記憶する非一時的なコンピュータ読み取り可能な媒体であって、前記命令は、符号化されたビデオ・ビットストリームを復号化するために装置の1つ以上のプロセッサで実行されると、前記1つ以上のプロセッサに、
現在のピクチャにコンフォーマンス・ウィンドウが存在することを示す第1フラグを取得するステップと、
前記コンフォーマンス・ウィンドウが存在することを示す前記第1フラグに基づいて、前記コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されるかどうかを示す第2フラグを取得するステップと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されることを示す前記第2フラグに基づいて、前記現在のピクチャ及び参照ピクチャの間のリサンプリング比率を、前記コンフォーマンス・ウィンドウのコンフォーマンス・ウィンドウ・サイズに基づいて決定するステップと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されないことを示す前記第2フラグに基づいて、前記リサンプリング比率をリサンプリング・ピクチャ・サイズに基づいて決定するステップと、
前記リサンプリング比率を利用して、前記現在のピクチャに対する前記参照ピクチャ・リサンプリングを実行するステップと
を実行させる、非一時的なコンピュータ読み取り可能な媒体。
（付記20）
前記第1フラグ及び前記第2フラグは、ピクチャ・パラメータ・セットでシグナリングされる、付記19に記載の非一時的なコンピュータ読み取り可能な媒体。
少なくとも1つのプロセッサを利用して、符号化されたビデオ・ビットストリームを復号化する方法であって、
現在のピクチャにコンフォーマンス・ウィンドウが存在することを示す第1フラグを取得するステップと、
前記コンフォーマンス・ウィンドウが存在することを示す前記第1フラグに基づいて、前記コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されるかどうかを示す第2フラグを取得するステップと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されることを示す前記第2フラグに基づいて、前記現在のピクチャ及び参照ピクチャの間のリサンプリング比率を、前記コンフォーマンス・ウィンドウのコンフォーマンス・ウィンドウ・サイズに基づいて決定するステップと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されないことを示す前記第2フラグに基づいて、前記リサンプリング比率をリサンプリング・ピクチャ・サイズに基づいて決定するステップと、
前記リサンプリング比率を利用して、前記現在のピクチャに対する前記参照ピクチャ・リサンプリングを実行するステップと
を含む方法。
（付記2）
前記第1フラグ及び前記第2フラグは、ピクチャ・パラメータ・セットでシグナリングされる、付記1に記載の方法。
（付記3）
前記コンフォーマンス・ウィンドウ・サイズは、前記現在のピクチャのボーダーからの少なくとも1つのオフセット距離に基づいて決定される、付記1に記載の方法。
（付記4）
前記少なくとも1つのオフセット距離は、ピクチャ・パラメータ・セットでシグナリングされる、付記3に記載の方法。
（付記5）
前記リサンプリング・ピクチャ・サイズは、前記リサンプリング・ピクチャ・サイズの幅及び前記リサンプリング・ピクチャ・サイズの高さのうちの少なくとも1つとして、前記符号化されたビデオ・ビットストリームで指定される、付記1に記載の方法。
（付記6）
前記幅及び前記は高さのうちの少なくとも1つは、ピクチャ・パラメータ・セットでシグナリングされる、付記5に記載の方法。
（付記7）
前記幅及び前記は高さのうちの少なくとも1つは、前記幅及び前記は高さのうちの少なくとも1つに含まれるルマ・サンプルの数として表現される、付記5に記載の方法。
（付記8）
前記リサンプリング・ピクチャ・サイズは、前記現在のピクチャの参照領域の左上ルマ・サンプルからの少なくとも1つのオフセット距離に基づいて決定される、付記1に記載の方法。
（付記9）
前記少なくとも1つのオフセット距離は、ピクチャ・パラメータ・セットでシグナリングされる、付記8に記載の方法。
（付記10）
符号化されたビデオ・ビットストリームを復号化する装置であって、
プログラム・コードを記憶するように構成された少なくとも1つのメモリと、
前記プログラム・コードを読み込み、前記プログラム・コードによって指示されるように動作する少なくとも1つのプロセッサと
を含み、前記プログラム・コードは、
現在のピクチャにコンフォーマンス・ウィンドウが存在することを示す第1フラグを取得することを、前記少なくとも1つのプロセッサに行わせるように構成された第1取得コードと、
前記コンフォーマンス・ウィンドウが存在することを示す前記第1フラグに基づいて、前記コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されるかどうかを示す第2フラグを取得することを、前記少なくとも1つのプロセッサに行わせるように構成された第2取得コードと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されることを示す前記第2フラグに基づいて、前記現在のピクチャ及び参照ピクチャの間のリサンプリング比率を、前記コンフォーマンス・ウィンドウのコンフォーマンス・ウィンドウ・サイズに基づいて決定することを、前記少なくとも1つのプロセッサに行わせるように構成された第1決定コードと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されないことを示す前記第2フラグに基づいて、前記リサンプリング比率をリサンプリング・ピクチャ・サイズに基づいて決定することを、前記少なくとも1つのプロセッサに行わせるように構成された第2決定コードと、
前記リサンプリング比率を利用して、前記現在のピクチャに対する前記参照ピクチャ・リサンプリングを実行することを、前記少なくとも1つのプロセッサに行わせるように構成された実行コードと
を含む、装置。
（付記11）
前記第1フラグ及び前記第2フラグは、ピクチャ・パラメータ・セットでシグナリングされる、付記10に記載の装置。
（付記12）
前記コンフォーマンス・ウィンドウ・サイズは、前記現在のピクチャのボーダーからの少なくとも1つのオフセット距離に基づいて決定される、付記10に記載の装置。
（付記13）
前記少なくとも1つのオフセット距離は、ピクチャ・パラメータ・セットでシグナリングされる、付記12に記載の装置。
（付記14）
前記リサンプリング・ピクチャ・サイズは、前記リサンプリング・ピクチャ・サイズの幅及び前記リサンプリング・ピクチャ・サイズの高さのうちの少なくとも1つとして、前記符号化されたビデオ・ビットストリームで指定される、付記10に記載の装置。
（付記15）
前記幅及び前記は高さのうちの少なくとも1つは、ピクチャ・パラメータ・セットでシグナリングされる、付記14に記載の装置。
（付記16）
前記幅及び前記は高さのうちの少なくとも1つは、前記幅及び前記は高さのうちの少なくとも1つに含まれるルマ・サンプルの数として表現される、付記14に記載の装置。
（付記17）
前記リサンプリング・ピクチャ・サイズは、前記現在のピクチャの参照領域の左上ルマ・サンプルからの少なくとも1つのオフセット距離に基づいて決定される、付記10に記載の装置。
（付記18）
前記少なくとも1つのオフセット距離は、ピクチャ・パラメータ・セットでシグナリングされる、付記17に記載の装置。
（付記19）
命令を記憶する非一時的なコンピュータ読み取り可能な媒体であって、前記命令は、符号化されたビデオ・ビットストリームを復号化するために装置の1つ以上のプロセッサで実行されると、前記1つ以上のプロセッサに、
現在のピクチャにコンフォーマンス・ウィンドウが存在することを示す第1フラグを取得するステップと、
前記コンフォーマンス・ウィンドウが存在することを示す前記第1フラグに基づいて、前記コンフォーマンス・ウィンドウが参照ピクチャ・リサンプリングに使用されるかどうかを示す第2フラグを取得するステップと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されることを示す前記第2フラグに基づいて、前記現在のピクチャ及び参照ピクチャの間のリサンプリング比率を、前記コンフォーマンス・ウィンドウのコンフォーマンス・ウィンドウ・サイズに基づいて決定するステップと、
前記コンフォーマンス・ウィンドウが前記参照ピクチャ・リサンプリングに使用されないことを示す前記第2フラグに基づいて、前記リサンプリング比率をリサンプリング・ピクチャ・サイズに基づいて決定するステップと、
前記リサンプリング比率を利用して、前記現在のピクチャに対する前記参照ピクチャ・リサンプリングを実行するステップと
を実行させる、非一時的なコンピュータ読み取り可能な媒体。
（付記20）
前記第1フラグ及び前記第2フラグは、ピクチャ・パラメータ・セットでシグナリングされる、付記19に記載の非一時的なコンピュータ読み取り可能な媒体。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6A】
【図6B】
【図7】
【図8A】
【図8B】
【図9】
【図10】
【図11】
【外国語明細書】