特開 2024-177195 ビデオコーディングツールのための高レベルシンタックス

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024177195

(43)【公開日】2024-12-19

(54)【発明の名称】ビデオコーディングツールのための高レベルシンタックス

(51)【国際特許分類】

   H04N 19/70 20140101AFI20241212BHJP

   H04N 19/513 20140101ALI20241212BHJP

【ＦＩ】

H04N19/70

H04N19/513

【審査請求】有

【請求項の数】18

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2024158878

(22)【出願日】2024-09-13

(62)【分割の表示】P 2022521585の分割

【原出願日】2020-10-12

(31)【優先権主張番号】PCT/CN2019/110905

(32)【優先日】2019-10-12

(33)【優先権主張国・地域又は機関】CN

(71)【出願人】

【識別番号】520476341

【氏名又は名称】北京字節跳動網絡技術有限公司

【氏名又は名称原語表記】Ｂｅｉｊｉｎｇ Ｂｙｔｅｄａｎｃｅ Ｎｅｔｗｏｒｋ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ．

【住所又は居所原語表記】Ｒｏｏｍ Ｂ－００３５， ２／Ｆ， Ｎｏ．３ Ｂｕｉｌｄｉｎｇ， Ｎｏ．３０， Ｓｈｉｘｉｎｇ Ｒｏａｄ， Ｓｈｉｊｉｎｇｓｈａｎ Ｄｉｓｔｒｉｃｔ Ｂｅｉｊｉｎｇ １０００４１ Ｃｈｉｎａ

(71)【出願人】

【識別番号】520477474

【氏名又は名称】バイトダンス インコーポレイテッド

【氏名又は名称原語表記】ＢＹＴＥＤＡＮＣＥ ＩＮＣ．

【住所又は居所原語表記】１２６５５ Ｗｅｓｔ Ｊｅｆｆｅｒｓｏｎ Ｂｏｕｌｅｖａｒｄ， Ｓｉｘｔｈ Ｆｌｏｏｒ， Ｓｕｉｔｅ Ｎｏ． １３７ Ｌｏｓ Ａｎｇｅｌｅｓ， Ｃａｌｉｆｏｒｎｉａ ９００６６ Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】110004381

【氏名又は名称】弁理士法人ＩＴＯＨ

(72)【発明者】

【氏名】ザン，カイ

(72)【発明者】

【氏名】ザン，リー

(72)【発明者】

【氏名】リュウ，ホンビン

(72)【発明者】

【氏名】ワン，ユエ

(57)【要約】

【課題】 改善されたビデオデータの処理方法を提供する。
【解決手段】 本方法は、ビデオのピクチャのビデオ領域と該ビデオのビットストリームとの間での変換のために、第１のシンタックス要素に基づいて前記ピクチャに対してコーディングツールが無効かどうかを判定することと、判定に基づいて前記変換を行うことと、を含み、前記ピクチャに対して前記コーディングツールが無効かどうかを示す前記第１のシンタックス要素はピクチャヘッダでシグナリングされる。
【選択図】 図２３

【特許請求の範囲】

【請求項1】

ビデオデータを処理する方法であって、
ビデオのピクチャのビデオ領域と該ビデオのビットストリームとの間での変換のために、第１のシンタックス要素に基づいて前記ピクチャに対してコーディングツールが無効かどうかを判定することと、
前記判定に基づいて前記変換を行うことと、
を含み、
前記ピクチャに対して前記コーディングツールが無効かどうかを示す前記第１のシンタックス要素はピクチャヘッダでシグナリングされる、方法。

【請求項2】

前記ピクチャよりも小さいビデオユニットのために前記コーディングツールが無効か又は有効かは前記第１のシンタックス要素及び／又は前記ビデオのスライスタイプに依存する、請求項１に記載の方法。

【請求項3】

前記第１のシンタックス要素が真の場合、前記コーディングツールは前記ピクチャに対して無効である、請求項１又は２に記載の方法。

【請求項4】

前記第１のシンタックス要素が偽の場合、前記コーディングツールは前記ピクチャに対して有効である、請求項１乃至３のいずれか一項に記載の方法。

【請求項5】

前記コーディングツールは、前記ピクチャ内の全てのサンプルに対して無効又は有効である、請求項１乃至４のいずれか一項に記載の方法。

【請求項6】

前記第１のシンタックス要素が前記ピクチャヘッダでシグナリングされるかどうかは、前記ビデオ領域に関連するシーケンスパラメータセット（ＳＰＳ）内の１つ以上のシンタックス要素に依存する、請求項１乃至５のいずれか一項に記載の方法。

【請求項7】

前記１つ以上のシンタックス要素は前記ピクチャヘッダに前記第１のシンタックス要素が存在することを示す第２のシンタックス要素と、前記コーディングツールが前記ビデオのシーケンスに対して有効かどうかを示す第３のシンタックス要素とを含む、請求項６に記載の方法。

【請求項8】

前記第２のシンタックス要素は、前記第３のシンタックス要素に基づいて、前記ＳＰＳで条件的にシグナリングされる、請求項７に記載の方法。

【請求項9】

前記第２のシンタックス要素が真の場合、前記第１のシンタックス要素が前記ピクチャヘッダでシグナリングされ、前記コーディングツールが前記ビデオのシーケンスに対して有効の場合、前記第２のシンタックス要素が前記ＳＰＳ内でシグナリングされる、請求項７又は８に記載の方法。

【請求項10】

前記第１のシンタックス要素及び／又は前記第２のシンタックス要素は１ビットで符号化されている、請求項７乃至９のいずれか一項に記載の方法。

【請求項11】

前記コーディングツールは、
アフィンモードで符号化された現在のビデオブロックのサブブロックのさを生成することと、
オプティカルフロー演算を適用し、動きベクトルの差ｄＭｖＨ及び／又はｄＭｖＶに基づいて予測精密化を導出することにより、前記サブブロックの最終予測サンプルを生成することであって、ｄＭｖＨ及びｄＭｖＶは、水平方向及び垂直方向に沿った動きベクトルの差を示す、ことと、
のために用いられる第１のコーディングツールを含む、請求項１乃至１０のいずれか一項に記載の方法。

【請求項12】

前記コーディングツールは、シグナリングされた動きベクトルに対するオフセットを有する少なくとも１つの動きベクトルに基づいて該シグナリングされた動きベクトルの精密化のために用いられる第２のコーディングツールを含む、請求項１乃至１０のいずれか一項に記載の方法。

【請求項13】

前記コーディングツールは、現在のブロックの参照ブロック内のサンプルに対応する少なくとも１つの勾配値に基づいて動きベクトルの精密化を得るために用いられる第３のコーディングツールを含む、請求項１乃至１０のいずれか一項に記載の方法。

【請求項14】

前記変換は、前記ビデオを前記ビットストリームにエンコードすることを含む、請求項１乃至１３のいずれか一項に記載の方法。

【請求項15】

前記変換は、前記ビデオを前記ビットストリームからデコードすることを含む、請求項１乃至１３のいずれか一項に記載の方法。

【請求項16】

プロセッサと、命令が記憶された非一時的メモリとを含む、ビデオデータを処理するための装置であって、前記命令は前記プロセッサによって実行された場合、前記プロセッサに、
ビデオのピクチャのビデオ領域と該ビデオのビットストリームとの間での変換のために、第１のシンタックス要素に基づいて前記ピクチャに対してコーディングツールが無効かどうかを判定することと、
前記判定に基づいて前記変換を行うことと、
を行わせ、
前記ピクチャに対して前記コーディングツールが無効かどうかを示す前記第１のシンタックス要素はピクチャヘッダでシグナリングされる、装置。

【請求項17】

命令が記憶された非一時的コンピュータ読み取り可能記憶媒体であって、該命令はプロセッサに、
ビデオのピクチャのビデオ領域と該ビデオのビットストリームとの間での変換のために、第１のシンタックス要素に基づいて前記ピクチャに対してコーディングツールが無効かどうかを判定することと、
前記判定に基づいて前記変換を行うことと、
を行わせ、
前記ピクチャに対して前記コーディングツールが無効かどうかを示す前記第１のシンタックス要素はピクチャヘッダでシグナリングされる、非一時的コンピュータ読み取り可能記憶媒体。

【請求項18】

ビデオ処理装置によって行われる方法によって生成されるビデオのビットストリームを記憶する非一時的コンピュータ読み取り可能記録媒体であって、該方法は、
前記ビデオのピクチャのビデオ領域について、第１のシンタックス要素に基づいて前記ピクチャに対してコーディングツールが無効かどうかを判定することと、
前記判定に基づいて前記ビデオのビットストリームを生成することと、
を含み、
前記ピクチャに対して前記コーディングツールが無効かどうかを示す前記第１のシンタックス要素はピクチャヘッダでシグナリングされる、非一時的コンピュータ読み取り可能記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

［関連出願の相互参照］
本願は、２０１９年１０月１２日に出願された国際特許出願第ＰＣＴ／ＣＮ２０１９／１１０９０５号の優先権及び利益を適時に主張する、２０２０年１０月１２日に出願された国際特許出願第ＰＣＴ／ＣＮ２０２０／１２０２８７号に基づく特願２０２２－５２１５８５号の分割出願である。前述の出願の全ては、その全体が参照により本特許出願に組み込まれる。

【0002】

本特許文書はビデオ符号化技術、装置及びシステムに関する。

【背景技術】

【0003】

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

【発明の概要】

【課題を解決するための手段】

【0004】

デジタルビデオ符号化、特にビデオ符号化のためのアダプティブループフィルタリングに関連する装置、システム及び方法を説明する。説明する方法は、既存のビデオ符号化規格（例えば、高効率ビデオ符号化（ＨＥＶＣ））及び将来のビデオ符号化規格（例えば、汎用ビデオ符号化（ＶＶＣ））又はコーデックの両方に適用され得る。

【0005】

ビデオ符号化規格は、周知のＩＴＵ－Ｔ及びＩＳＯ/ＩＥＣ規格の開発を通じて主に発展してきた。ＩＴＵ－ＴはＨ．２６１及びＨ.２６３を作り出し、ＩＳＯ/ＩＥＣはＭＰＥＧ－１及びＭＰＥＧ－４ Ｖｉｓｕａｌを作り出し、２つの組織はＨ．２６２/ＭＰＥＧ－２ Ｖｉｄｅｏ及びＨ．２６４/ＭＰＥＧ－４ Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）及びＨ．２６５/ＨＥＶＣ規格を共同で作り出した。Ｈ．２６２以来、ビデオ符号化規格は、時間的予測と変換符号化が利用されるハイブリッドビデオ符号化構造に基づく。ＨＥＶＣを越えた将来のビデオ符号化技術を探求するため、２０１５年にＶＣＥＧ及びＭＰＥＧによって共同でＪＶＥＴ（Joint Video Exploration Team）が設立された。それ以来、JVETによって多くの新たな方法が採用され、ＪＥＭ（Joint Exploration Model）という名称の参照ソフトウェアに入れられている。２０１８年４月には、ＨＥＶＣに比べて５０％のビットレート低減を目指すＶＶＣ規格に取り組むためにＶＣＥＧ（Ｑ６／１６）とＩＳＯ／ＩＥＣ ＪＴＣ１ ＳＣ２９／ＷＧ１１（ＭＰＥＧ）との間でＪＶＥＴ（Joint Video Expert Team）が発足された。

【0006】

代表的な一態様では、開示の技術はビデオ処理のための方法を提供するために用いられ、当該方法は、ビデオのピクチャのビデオ領域と該ビデオの符号化表現との間での変換のために、該符号化表現におけるビデオ領域を表すために用いられる符号化ツールの有効状態を判定することと、前記判定に従って前記変換を行うこと、とを含み、前記ピクチャのための前記符号化ツールの有効状態を示すために、第１のフラグがピクチャヘッダに含まれている。

【0007】

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

【0008】

さらに別の代表的な態様では、上述の方法を実行するように又は行うように構成された装置が開示される。装置は、本方法を実施するようにプログラムされたプロセッサを含み得る。

【0009】

さらに別の代表的な態様では、ビデオデコーダ装置は、本明細書で説明される方法を実施し得る。

【0010】

開示する技術の上記の及び他の態様及び特徴は、図面、明細書及び特許請求の範囲でより詳細に説明されている。

【図面の簡単な説明】

【0011】

【図1】図１は、異なる解像度でコード化された同じコンテンツの２つの表現のアダプティブストリーミングの例を示す。

【図2】図２は、異なる解像度でコード化された同じコンテンツの２つの表現のアダプティブストリーミングの例を示す。

【図3】図３は、２つの表現のオープンＧＯＰ予測構造の例を示す。

【図4】図４は、オープンＧＯＰ位置での表現スイッチングの例を示す。

【図5】図５は、他のビットストリームからの再サンプリングされた参照ピクチャを参照として用いることによる、ＲＡＳＬピクチャのためのデコーデイングプロセスの例を示す。

【図6】図６Ａ～図６Ｃは、ＭＣＴＳベースのＲＷＭＲビューポート依存３６０°ストリーミングの例を示す。

【図7】図７は、異なるＩＲＡＰ間隔及び異なるサイズのコロケートされたサブピクチャ表現の例を示す。

【図8】図８は、視聴向きの変化によって解像度の変化がもたらされた場合に受信されたセグメントの例を示す。

【図9】図９は、図６と比較して、わずかに上方に且つ右側の立方面の方への視聴向きの変化の例を示す。

【図10】図１０は、２つのサブピクチャ位置のためのサブピクチャ表現が示される実施の例を示す。

【図11】図１１はＡＲＣエンコーダの実施を示す。

【図12】図１２はＡＲＣデコーダの実施を示す。

【図13】図１３は、ＡＲＣのためのタイル群ベースの再サンプリングの例を示す。

【図14】図１４は、適応的解像度変更の例を示す。

【図15】図１５は、ＣＵのためのＡＴＭＶＰ動き予測の一例を示す。

【図16】図１６Ａ及び図１６Ｂは、単純化された４パラメータアフィン動きモデル及び単純化された６パラメータアフィン動きモデルの例をそれぞれ示す。

【図17】図１７は、サブブロック当たりのアフィンＭＶＦの例を示す。

【図18】図１８Ａ及び図１８Ｂは、４パラメータアフィンモデル及び６パラメータアフィンモデルの例をそれぞれ示す

【図19】図１９は、継承されたアフィン候補についてのＡＦ＿ＩＮＴＥＲに対するＭＶＰ（Motion Vector Difference）を示す。

【図20】図２０は、構築されたアフィン候補についてのＡＦ＿ＩＮＴＥＲに対するＭＶＰを示す。

【図21】図１Ａ及び図２１Ｂは、５つの隣接ブロック及びＣＰＭＶ予測子の導出をそれぞれ示す。

【図22】図２２は、アフィンマージモードの候補位置の例を示す。

【図23】図２３は、開示の技術に係るビデオ処理のための例示の方法のフローチャートを示す。

【図24A】図２４Ａは、本願で説明するビジュアルメディアデコーデイング又はビジュアルメディアエンコーディング技術を実施するためのハードウェアプラットフォームの例のブロック図である。

【図24B】図２４Ｂは、本願で説明するビジュアルメディアデコーデイング又はビジュアルメディアエンコーディング技術を実施するためのハードウェアプラットフォームの例のブロック図である。

【図25】図２５は、例示のビデオコーディングシステムを示すブロック図である。

【図26】図２６は、開示の技術の一部の実施形態に係るエンコーダを示すブロック図である。

【図27】図２７は、開示の技術の一部の実施形態に係るデコーダを示すブロック図である。

【図28】図２８は、開示の技術の一部の実施形態に係るビデオ処理の例示の方法のフローチャートを示す。

【発明を実施するための形態】

【0012】

本願で開示する技術及び装置は、適応的解像度変更（ａｄａｐｔｉｖｅ ｒｅｓｏｌｕｔｉｏｎ ｃｈａｎｇｅ）有するコーディングツールを提供する。ＡＶＣ及びＨＥＶＣは、ＩＤＲ又はイントラランダムアクセスポイント（ＩＲＡＰ）ピクチャを導入する必要なしに解像度を変更する能力を有していない。そのような能力は、適応的解像度変更（ＡＲＣ）と呼ぶことができる。ＡＲＣ機能から恩恵を受けるユースケース又は適用シナリオとしては以下が挙げられる。

【0013】

－テレビ電話及び会議におけるレート適応：変化するネットワーク条件にコード化されたビデオを適応させるために、ネットワーク条件が悪化し、利用可能な帯域幅が小さくなると、エンコーダは、より小さな解像度のピクチャをエンコードすることにより、それに適応し得る。現在、ピクチャの解像度の変更はＩＲＡＰピクチャの後にのみ行うことができるが、これにはいくつかの問題がある。妥当な品質のＩＲＡＰピクチャは、インターコード化ピクチャよりもはるかに大きく、それに対応してデコードするのがより複雑である。これには時間及びリソースがかかる。これは、負荷の理由でデコーダによって解像度の変更が要求された場合に問題となる。また、低遅延のバッファ条件を壊し、オーディオの再同期が強制され、ストリームのエンドツーエンド遅延が少なくとも一時的に増加することになる。これにより、ユーザ体験が悪くなり得る。

【0014】

－マルチパーティビデオ会議におけるアクティブスピーカの変更：マルチパーティビデオ会議の場合、アクティブスピーカは、残りの会議参加者のビデオよりも大きなビデオサイズで表示させるのが一般的である。アクティブスピーカが変更されると、各参加者のピクチャ解像度も調整する必要があり得る。ＡＲＣ機能の必要性は、そのようなアクティブスピーカにおける変更が頻繁に行われる場合により重要となる。

【0015】

－ストリーミングにおけるファストスタート：ストリーミングアプリケーションの場合、アプリケーションが表示を開始する前に、特定の長さのデコードされたピクチャまでバッファリングを行うことが一般的である。解像度がより小さいビットストリームを開始することは、アプリケーションが表示をより早く開始するのに十分なピクチャをバッファ内に有することを可能にする。

【0016】

ストリーミングにおける適応的ストリーム切り替え：ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）規格は@mediaStreamStructureIdと名前の機能を含む。これは、例えば、HEVCにおいて関連するＲＡＳＬピクチャを有するＣＲＡピクチャのような、デコード不可能なリーディングピクチャを有するオープンGOPランダムアクセスポイントにおける異なる表現間のスイッチングを可能にする。同じビデオの２つの異なる表現が異なるビットレートを有するが、同じ空間分解能を有する一方で、それらが同じ値の@mediaStreamStructureIdを有する場合、関連するＲＡＳＬピクチャとＣＲＡピクチャの２つの表現の間でスイッチングを行うことができ、ＣＲＡピクチャでのスイッチングに関連するＲＡＳＬピクチャを許容可能な品質でデコードできるため、シームレスなスイッチングが可能になる。ＡＲＣでは、@mediaStreamStructureId機能は、空間分解能が異なるDASH表現間の切り替えのためにも用いることができる。

【0017】

ＡＲＣは動的解像度変換としても知られている。

【0018】

ＡＲＣは、Ｈ．２６３ Ａｎｎｅｘ Ｐ等の参照ピクチャ再サンプリング（ＲＰＲ）の特殊なケースとしても見なされ得る。

【0019】

１．１ Ｈ．２６３ Ａｎｎｅｘ Ｐにおける参照ピクチャ再サンプリング
このモードは、参照ピクチャを、予測のためのその使用の前にワーピングするアルゴリズムを記述する。これは、予測されるピクチャとは異なるソースフォーマットを有する参照ピクチャを再サンプリングするのに有用であり得る。これは、参照ピクチャの形状、サイズ及び位置をワーピングすることにより、全体的な動き推定又は回転動作の推定に用いることもできる。シンタックスは、用いられるべきワーピングパラメータ及び再サンプリングアルゴリズムを含む。参照ピクチャ再サンプリングモードの最も単純なレベルの動作は、アップサンプリング及びダウンサンプリングプロセスにＦＩＲフィルタを適用するだけでだけでいいことから、暗黙的係数が４の再サンプリング（implicit factor of 4 resampling）である。この場合、（ピクチャヘッダで示される）新たなピクチャのサイズが前のピクチャのサイズと異なる場合にその使用が理解されるため、追加のシグナリングオーバーヘッドが必要ではない。

【0020】

１．２ ＶＶＣに対するＡＲＣの寄与
１．２．１ ＪＶＥＴ－Ｍ０１３５
ＪＣＴＶＣ－Ｆ１５８から一部を抜粋した、以下で説明するＡＲＣの予備的な設計は、議論を引き起こすためだけのプレースホルダであることが示唆されている。

【0021】

２．２．１．１ 基本ツールの説明
ＡＲＣをサポートするための基本ツールの制約は次のとおりである。
－空間分解能は、両方の寸法に適用される係数０.５だけ公称分解能と異なり得る。空間分解能は増減してもよく、０.５及び２.０の倍率が得られる。
－ビデオフォーマットのアスペクト比及びクロマフォーマットは変更されない。
－クロッピング面積は空間分解能に比例してスケーリングされる。
－参照ピクチャは必要に応じて単純に再スケーリングされ、インター予測は従来どおり適用される。

【0022】

２．２．１．２ スケーリング動作
単純なゼロ相の分離可能なダウン及びアップスケーリングフィルタを用いることが提案される。なお、これらのフィルタは予測専用であり、デコーダは出力のためにより高度なスケーリングを用いり得る。

【0023】

以下の１：２ダウンスケーリングフィルタが用いられ、ゼロ相及び５タップを有する：
（－１、９、１６、９、－１）／３２

【0024】

ダウンサンプリング点は偶数サンプル位置にあり、共に置かれている（co-sited）。同じフィルタがルーマ及びクロマに用いられる。

【0025】

２：１アップサンプリングのために、奇数グリッド位置にある追加サンプルが、最新のＶＶＣ ＷＤにおける半画素動き補償補間フィルタ係数を用いて生成される。

【0026】

組み合わされたアップ及びダウンサンプリングは、クロマサンプリング点の位置又は位相を変化させない。

【0027】

２．２．１．２ パラメータ集合における解像度記述
ＳＰＳにおけるピクチャ解像度のシグナリングは以下のように変更される。変更のうち、削除される部分は二重括弧でマークされている(例えば、［［ａ］］は文字「ａ」の削除を意味する)。

【0028】

【表1】

【0029】

[[pic_width_in_luma_samplesは、各復号ピクチャの幅をルーマサンプルの単位で指定する。pic_width_in_luma_samplesは０と等しくなく、そしてＭｉｎＣｂＳｉｚｅＹの整数倍とする。
pic_height_in_luma_samplesは、各復号ピクチャの高さをルーマサンプルの単位で指定する。pic_height_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。］］

【0030】

num_pic_size_in_luma_samples_minus１
plus １は、ピクチャサイズ（幅及び高さ）の数を、符号化ビデオシーケンスに存在し得るルミナンスサンプルの単位で指定する。

【0031】

pic_width_in_luma_samples[i]は、復号ピクチャのｉ番目の幅を、符号化ビデオシーケンスに存在し得るルミナンスサンプルの単位で指定する。pic_width_in_luma_samples[i]は０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。

【0032】

pic_height_in_luma_samples[i]
は、復号ピクチャのｉ番目の高さを、符号化ビデオシーケンスに存在し得るルミナンスサンプルの単位で指定する。pic_height_in_luma_samples[i]は０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。

【0033】

【表2】

【0034】

pic_size_idxはシーケンスパラメータセットのｉ番目のピクチャサイズへのインデックスを指定する。ピクチャパラメータセットを参照するピクチャの幅は、ルーマサンプルにおけるpic_width_in_luma_samples[pic_size_idx]である。同様に、ピクチャパラメータセットを参照するピクチャの高さは、ルーマサンプルにおけるpic_height_in_luma_samples[pic_size_idx]である。

【0035】

１．２．２ ＪＶＥＴ－Ｍ０２５９
１．２．２．１ 背景:サブピクチャ
サブピクチャトラックという用語はＯＭＡＦ（Omnidirectional Media Format）において以下のように定義される:トラックは、他のトラックと空間関係を有し、オリジナルのビデオコンテンツの空間的サブセットを表すトラックであって、コンテンツ制作側でビデオ符号化を行う前に空間的サブセットに分割されている。ＨＥＶＣのためのサブピクチャトラックは、それが自立型ＨＥＶＣビットストリームになるように、モーション制約タイルセットのためのパラメータセット及びスライスセグメントヘッダを書き換えることによって構築できる。サブピクチャ表現は、サブピクチャトラックを保持するＤＡＳＨ表現として定義できる。

【0036】

ＶＶＣのための空間分割単位としてサブピクチャという用語を用いるＪＶＥＴ－Ｍ０２６１は以下のように要約される。
１． 写真は、サブピクチャ、タイルグループ及びタイルに分割される。
２． サブピクチャは、tile_group_addressが０のタイルグループで始まるタイルグループの長方形のセットである。
３． 各サブピクチャは、それ自身のＰＰＳを参照してもよく、故にそれ自身のタイル分割を有し得る。
４． サブピクチャは復号プロセスでピクチャの様に扱われる。
５． サブピクチャを復号化するための参照ピクチャは、復号ピクチャバッファ内の参照ピクチャから、現在のサブピクチャと同一場所にある領域を抽出することにより生成される。抽出された領域は復号サブピクチャである。すなわち、ピクチャ内の同じサイズ及び同じ位置のサブピクチャ間でインター予測が行われる。
６． タイルグループは、サブピクチャのタイルラスタスキャンにおける一連のタイルである。

【0037】

この寄稿では、サブピクチャという用語は、ＪＶＥＴＭ０２６１で定義されているものとして理解することができる。しかしながら、ＪＶＥＴＭ０２６１で定義されているサブピクチャシーケンスをカプセル化するトラックは、ＯＭＡＦで定義されているサブピクチャトラックと非常に類似した特性を有する。以下の例は両方の場合に適用される。

【0038】

１．２．２．２ 使用事例
１．２．２．２．１ ストリーミングにおける適応的解像度変更
アダプティブストリーミングのサポートのための要件
ＭＰＥＧ Ｎ１７０７４のセクション５.１３（「アダプティブストリーミングのサポートのための要件」）はＶＶＣのための以下の要件を含む：それぞれが異なる特性（例えば、空間分解能又はサンプルビット深度）を有する同一コンテンツの複数の表現を提供するアダプティブストリーミングサービスの場合、規格は高速な表現スイッチングをサポートするものとする。規格は、異なる空間分解能等の異なる特性の表現の間の高速且つシームレスな表現スイッチング能力を損なうことなく、効率的な予測構造（例えば、所謂オープンピクチャ群）の使用を可能にするものとする。

【0039】

表現スイッチングを伴うオープンＧＯＰ予測構造の例
アダプティブビットレートストリーミングのためのコンテンツ生成は、異なる空間分解能を有することができる異なる表現の生成を含む。クライアントは表現からセグメントを要求し、故にどの解像度及びビットレートでコンテンツを受信するかを決定できる。クライアントでは、異なる表現のセグメントが連結され、復号され、再生される。クライアントは、１つのデコーダインスタンスでシームレスな再生を実現できる必要がある。（ＩＤＲピクチャで始まる）クローズドＧＯＰ構造は、図１に示すように従来的に用いられる。図１は、異なる解像度で符号化された同じコンテンツの２つの表現のアダプティブストリーミングを示す。

【0040】

（ＣＲＡピクチャで始まる）オープンＧＯＰ予測構造は、それぞれのクローズドＧＯＰ予測構造よりも優れた圧縮性能を可能にする。例えば、間隔が２４のピクチャのＩＲＡＰピクチャで、ルーマＢｊｏｎｔｅｇａａｒｄデルタビットレートに関して５.６％の平均ビットレート削減が得られた。便宜上、［２］のシミュレーション条件及び結果をセクションＹＹで要約する。

【0041】

オープンＧＯＰ予測構造は、品質が主観的に可視的なポンピングを低減すると報告されている。

【0042】

ストリーミングにおいてオープンＧＯＰを用いることの課題は、表現をスイッチングした後にＲＡＳＬピクチャを正しい参照ピクチャで復号できないことである。表現に関するこの課題は、異なる解像度で符号化された同じコンテンツの２つの表現のアダプティブストリーミングを示す図２に示されている。図２において、セグメントは、クローズドＧＯＰ又はオープンＧＯＰ予測構造のいずれかを用いる。

【0043】

ＣＲＡピクチャで始まるセグメントは、少なくとも１つの参照ピクチャが前のセグメントにあるＲＡＳＬピクチャを含む。これは、２つの表現のオープンＧＯＰ予測構造を示す図３に示す。図３において、両方のビットストリームにおけるピクチャ０は前のセグメントに存在し、ＲＡＳＬピクチャを予測するための参考として用いられている。

【0044】

図２において破線の矩形でマークされた表現スイッチングは、オープンＧＯＰ位置での表現スイッチングを示す図４で以下に示す。ＲＡＳＬピクチャの参照ピクチャ（「ピクチャ０」）は復号されていないことが分かる。その結果、ＲＡＳＬピクチャは復号できず、ビデオの再生にギャップがある。

【0045】

しかしながら、再サンプリングされた参照ピクチャでＲＡＳＬ画像を復号することが主観的に受け入れられることが分かっている。セクション４を参照。「ピクチャ０」を再サンプリングし、それをＲＡＳＬピクチャを復号するための参照ピクチャとして用いることを図５に示す。図５は、他方のビットストリームから再サンプリングされた参照ピクチャを参照として用いることによる、ＲＡＳＬピクチャの復号プロセスを示す。

【0046】

２．２．２．２．２ リージョンワイズ混合解像度（ＲＷＭＲ）３６０°ビデオストリーミングにおけるビューポート変更
背景：ＨＥＶＣベースのＲＷＭＲストリーミング
ＲＷＭＲ３６０°ストリーミングは、向上された効果的なビューポート有効空間分解能を提供する。ビューポートをカバーするタイルが、「４Ｋ」の復号能力（ＨＥＶＣレベル５．１）を有する、図６に示す６Ｋ（６１４４×３０７２）のＥＲＰピクチャ又は同等のＣＭＰ解像度に由来するスキームはＯＭＡＦのＤ．６．３項及びＤ．６．４項に含まれており、ＶＲ産業フォーラムのガイドラインでも採用されている。そのような解像度はクワッドＨＤ（２５６０×１４４０）ディスプレイパネルを用いたヘッドマウントディスプレイに適していると主張されている。

【0047】

符号化：コンテンツは、キューブ面サイズ（cube face size）がそれぞれ１５３６×１５３６及び７６８×７６８である２つの空間分解能で符号化されている。両方のビットストリームにおいて、６×４のタイルグリッドが用いられ、各タイル位置に動き制約タイルセット（ＭＣＴＳ）が符号化されている。

【0048】

カプセル化：各ＭＣＴＳシーケンスはサブピクチャトラックとしてカプセル化され、ＤＡＳＨのサブピクチャ表現として利用可能にされる。

【0049】

ストリーミングされるＭＣＴＳの選択：高解像度ビットストリームから１２のＭＣＴＳが選択され、相補的な１２のＭＣＴＳが低解像度ビットストリームから抽出される。そのため、ストリーミングされるコンテンツの半球（１８０°×１８０°）は高解像度ビットストリームに由来する。

【0050】

復号すべきビットストリームへのＭＣＴＳのマージ：単一の時間インスタンスの受信されたＭＣＴＳは、ＨＥＶＣレベル５.１に準拠する１９２０×４６０８の符号化ピクチャにマージされる。マージされたピクチャのための別のオプションは、３８４０×２３０４ルーマサンプルのピクチャになる、幅７６８の４つのタイル列、幅３８４の２つのタイル列及び高さ７６８の３のタイル列のルーマサンプルを有することである。

【0051】

図６は、ＭＣＴＳベースのＲＷＭＲビューポート依存の３６０°ストリーミングの例を示す。図６Ａは符号化ビットストリームの例を示し、図６Ｂはストリーミングのために選択されたＭＣＴＳの例を示し、図６Ｃは、ＭＣＴＳからマージされたピクチャの例を示す。

【0052】

背景：ビューポート依存３６０°ストリーミングのための異なるＩＲＡＰ間隔のいくつかの表現
ＨＥＶＣベースのビューポート依存の３６０°ストリーミングにおいて視聴向きが変化した場合、サブピクチャ表現の新たな選択は次のＩＲＡＰ整列セグメント境界で有効になる。復号のためにサブピクチャ表現は符号化されたピクチャにマージされ、故に選択された全てのサブピクチャ表現でＶＣＬ ＮＡＬユニットタイプが整列される。

【0053】

視聴向きの変化に反応する応答時間と視聴方向が安定しているときのレート歪み性能との間でトレードオフを提供するために、異なるＩＲＡＰ間隔で複数のバージョンのコンテンツを符号化できる。これは、図６に示す符号化のための１組の配列されたサブピクチャ表現について図７に示されており、Ｈ． Ｃｈｅｎ、 Ｈ． Ｙａｎｇ、 Ｊ． Ｃｈｅｎの「サブブロックマージ候補のための別のリスト」（ＪＶＥＴ－Ｌ０３６８、２０１８年１０月）の３節で詳細に論じられている。

【0054】

図７は、異なるＩＲＡＰ間隔及び異なるサイズの配列されたサブピクチャ表現の例を示す。

【0055】

図８は、サブピクチャ位置が先ずより低い解像度（３８４×３８４）で受信されるように選択される例を示す。視聴向きを変化は、サブピクチャ位置がより高い解像度（７６８×７６８）で受信される新たな選択をもたらす。図８の例では、視聴向きの変化が解像度の変化を引き起こすときに受信されるセグメントはセグメント４の先頭にある。この例では、視聴向きの変化が起こるため、セグメント４が短いＩＲＡＰ間隔のサブピクチャ表現から受信される。その後、視聴方向は安定するため、セグメント５以降からはＩＲＡＰ間隔が長いバージョンを用いることができる。

【0056】

全てのサブピクチャ位置を更新することの難点
典型的な視聴状況では、視聴向きは徐々に移動するため、解像度は、ＲＷＭＲビューポート依存ストリーミングにおけるサブピクチャ位置のサブセットのみで変化する。図９は、図６から僅かに上方に且つ右側のキューブ面の方に変化した視聴向きを示す。先のものとは解像度が異なるキューブ面区画を「Ｃ」で示す。２４のキューブ面区画のうち６つで解像度が変化したことが分かる。しかしながら、上述したように、ＩＲＡＰピクチャで始まるセグメントは、視聴向きの変化に応答して２４のキューブ面区画の全てに対して受信される必要がある。ＩＲＡＰピクチャで始まるセグメントで、全てのサブピクチャ位置を更新することは、ストリーミングレート歪み性能の観点から非効率的である。

【0057】

加えて、レート歪み性能を改善し、クローズドＧＯＰ予測構造によって引き起こされる可視的なピクチャ品質のポンピングを回避するために、ＲＷＭＲ３６０°ストリーミングのサブピクチャ表現でオープンＧＯＰ予測構造を用いることができることが望ましい。

【0058】

提案する設計例
以下の設計目標を提案する。
１． ＶＶＣ設計は、ランダムアクセスピクチャに由来するサブピクチャと、非ランダムアクセスピクチャに由来する別のサブピクチャを、ＶＶＣに準拠する同じ符号化ピクチャにマージできるようにすべきである。
２． ＶＶＣ設計は、異なる空間分解能等の異なるプロパティのサブピクチャ表現間の高速且つシームレスな表現スイッチング能力を損なうことなく、サブピクチャ表現におけるオープンＧＯＰ予測構造の使用を可能にしながら、サブピクチャ表現を単一のＶＶＣビットストリームにマージできるようにすべきである。

【0059】

設計目標の例は、２つのサブピクチャ位置についてのサブピクチャ表現が示される図１０に示すことができる。双方のサブピクチャの場所について、コンテンツの別々のバージョンが、２つの解像度及び２つのランダムアクセス間隔のうちの各組み合わせに対して符号化される。セグメントの一部は、オープンＧＯＰ予測構造から始まる。視聴向きの変化によって、サブピクチャ位置１の解像度がセグメント４の始まりで切り替わる。セグメント４は、ＲＡＳＬピクチャに関連するＣＲＡピクチャで始まるため、セグメント３にあるＲＡＳＬピクチャの参照ピクチャを再サンプリングする必要がある。なお、この再サンプリングはサブピクチャ位置１に適用されるが、他の一部のサブピクチャ位置のデコードされたサブピクチャは再サンプリングされない。この例では、視聴向きの変化は、サブピクチャ位置２の解像度の変化を引き起こさないため、サブピクチャ位置２のデコードされたサブピクチャは再サンプリングされない。セグメント４の最初のピクチャでは、サブピクチャ位置１のセグメントはＣＲＡピクチャに由来するサブピクチャを含むのに対して、サブピクチャ位置２のセグメントは非ランダムアクセスピクチャに由来するサブピクチャを含む。符号化ピクチャへのこれらのサブピクチャのマージはＶＶＣで可能であることが示唆されている。

【0060】

２．２．２．２．３ テレビ会議における適応的解像度変更
ＪＣＴＶＣ―Ｆ１５８は、主にビデオ会議のための適応的解像度変更を提案する。以下のサブセクションがＪＣＴＶＣ－Ｆ１５８からコピーされ、適応的解像度変更が有用であると主張される使用事例を示す。

【0061】

シームレスなネットワーク適応及びエラー耐性
ビデオ会議やパケットネットワークを介したストリーミング等の用途は、特にビットレートが高すぎてデータが失われる場合に、符号化ストリームが変化するネットワーク条件に適応することがしばしば必要になる。そのような用途は、エンコーダがエラーを検出し、調整を行うことを可能にするリターンチャネルを通常有する。エンコーダは、時間的又は空間的のいずれかのビットレートの低減及び解像度変更という２つの主なツールを使える。時間分解能変更は、階層的予測構造を用いた符号化によって効果的に実現できる。しかしながら、最良の品質のためには、ビデオ通信のための適切に設計されたエンコーダの一部に加えて、空間分解能の変更が必要である。

【0062】

ＡＶＣ内で空間解像度を変更する場合、ＩＤＲフレームが送信され、ストリームがリセットされる必要がある。これは重大な問題をもたらす。妥当な品質のＩＤＲフレームはインターピクチャよりもはるかに大きく、それに対応して復号がより複雑になる。これには時間及びリソースがかかる。負荷の理由でデコーダによって解像度の変更が要求された場合にこれは問題となる。また、低遅延バッファ条件が崩れて、オーディオの再同期が強制され、ストリームのエンドツーエンド遅延が少なくとも一時的に増加し得る。これは、ユーザ体験の悪化をもたらす。

【0063】

これらのモダンを最小化に抑えるために、Ｐフレームに対して同様の数のビットを用いてＩＤＲが低品質で通常送信され、所与の解像度のために完全な品質に戻るのにかなりの時間を要する。遅延を十分に小さくするために、品質は実際に非常に低くなることがあり、画像が「再フォーカス」される前に目に見えるぼやけが生じることが多い。事実上、イントラフレームは圧縮条件ではほとんど役に立たない。これはストリームを再始動する方法にすぎない。

【0064】

そのため、ＨＥＶＣにおいて、特に困難なネットワーク条件で、主観的経験への影響を最小限に抑えながら解像度の変更を可能にする方法が必要とされている。

【0065】

ファストスタート
最初に許容不能な画像のぼやけを生じることなく、遅延を低減し、通常の品質により迅速に到達するために、第１のフレームが低減された解像度で送信され、次の数フレームにわたって解像度が増大される「ファストスタート」モードを有することは有用であろう。

【0066】

会議「コンポーズ」（Conference “compose”）
ビデオ会議は、話し手がフルスクリーンで表示され、他の参加者がより小さな解像度のウィンドウで表示される機能を有するも多い。これを効率的にサポートするために、より小さなピクチャがより低い解像度で送信されることが多い。この解像度は、参加者がスピーカーになり、フルスクリーンになった場合に高くなる。この時点でイントラフレームを送信すると、ビデオストリームにおいて不快な中断がもたらされる。この効果は話し手が素早く交替する場合に非常に顕著で不快なものになり得る。

【0067】

２.２.２.３ 提案される設計目標
ＶＶＣバージョン１のために以下の高レベルな設計の選択肢が提案されている。

【0068】

１． 以下の使用事例のために、参照ピクチャ再サンプリングプロセスをＶＶＣバージョン１に含めることが提案される。
－異なる空間分解能等特性が異なる表現間の高速でシームレスな表現スイッチング能力を損なうことなく、アダプティブストリーミングにおいて効率的な予測構造（例えば、所謂オープンピクチャ群）を用いること。
－著しい遅延又は遅延変化なしに、ネットワーク条件及びアプリケーションに起因する解像度変化に低遅延の会話型ビデオコンテンツを適応させること。

【0069】

２． ランダムアクセスピクチャに由来するサブピクチャと、非ランダムアクセスピクチャに由来する別のサブピクチャとを、ＶＶＣに準拠する同じ符号化ピクチャにマージできるようにするＶＶＣ設計が提案される。これは、混合品質及び混合解像度のビューポートアダプティブ３６０°ストリーミングにおける視聴向きの変化の効率的な対処を可能にするものと断定される。

【0070】

３． サブピクチャワイズ再サンプリングプロセスをＶＶＣバージョン１に含めることが提案される。これは、混合品質及び混合解像度のビューポートアダプティブ３６０°ストリーミングにおける視聴向きの変化の効率的な対処を可能にするものと断定される。

【0071】

２．２．３． ＪＶＥＴ－Ｎ００４８
適応的解像度変更（ＡＲＣ）のための使用事例及び設計目標がＪＶＥＴ―Ｍ０２５９で詳細に論じられている。その要約は以下の通りである。

【0072】

１． リアルタイム通信
適応的解像度変更についての以下の使用事例がＪＣＴＶＣ－Ｆ１５８に当初含まれていた。
ａ．（動的な適応的解像度変更を介した）シームレスなネットワーク適応及びエラー耐性
ｂ．ファストスタート（セッション開始時又はリセット時の解像度の漸増）
ｃ．会議「コンポーズ」(話し手により高い解像度が与えられる)

【0073】

２． アダプティブストリーミング
ＭＰＥＧ Ｎ１７０７４のセクション５.１３（「アダプティブストリーミングのサポート」)にはＶＶＣのための以下の要件が含まれる：それぞれが異なる特性（例えば、空間分解能又はサンプルビット深度）を有する同一コンテンツの複数の表現を提供するアダプティブストリーミングサービスの場合、規格は高速な表現スイッチングをサポートするものとする。規格は、異なる空間分解能等の異なる特性の表現の間の高速且つシームレスな表現スイッチング能力を損なうことなく、効率的な予測構造（例えば、所謂オープンピクチャ群）の使用を可能にするものとする。

【0074】

ＪＶＥＴ－Ｍ０２５９では、リーディングピクチャの参照ピクチャを再サンプリングすることにより、この要件をどのように満たすかが議論されている。

【0075】

３． ３６０°ビューポート依存ストリーミング
ＪＶＥＴ－Ｍ０２５９では、リーディングピクチャの参照ピクチャの特定の独立的に符号化されたピクチャ領域を再サンプリングすることにより、この使用事例をどのように対処するかが議論されている。

【0076】

この貢献は、上記の使用事例及び設計目標の全てを満たすと断定される適応的解像度変更アプローチを提案する。３６０°ビューポート依存ストリーミング及び会議「コンポーズ」の使用事例は、（独立したサブピクチャレイヤを提案する）ＪＶＥＴ－Ｎ００４５と共に本提案によって取り扱われる。

【0077】

提案される仕様テキスト
シグナリング

【0078】

【表3】

【0079】

sps_max_rprは、pic_width_in_luma_samples及びpic_height_in_luma_samplesが現在のピクチャのpic_width_in_luma_samples及びpic_height_in_luma_samplesのそれぞれと等しくないＣＶＳにおけるタイルグループの、参照ピクチャリスト０又は１のアクティブ参照ピクチャの最大数を指定する。

【0080】

【表4】

【0081】

【表5】

【0082】

max_width_in_luma_samplesは、このＳＰＳがアクティブであるＣＶＳの任意のピクチャのための任意のアクティブＰＰＳにおけるpic_width_in_luma_samples がmax_width_in_luma_samples
以下であることがビットストリーム適合の要件であることを指定する。

【0083】

max_height_in_luma_samplesは、このＳＰＳがアクティブであるＣＶＳの任意のピクチャのための任意のアクティブＰＰＳにおけるpic_height_in_luma_samples がmax_height_in_luma_samples
以下であることがビットストリーム適合の要件であることを指定する。

【0084】

高レベル復号化プロセス
現在の画像CurrPicに対してデコード処理は以下のように動作する。
１． ＮＡＬユニットの復号化は８．２項で規定されている。
２． ８．３項のプロセスは、タイルグループヘッダレイヤ及び上でシンタックス要素を用いる以下の復号化プロセスを規定する。

【0085】

－ピクチャオーダカウントに関する変数及び関数は、８．３．１節で規定されているように導出される。これは、第１のピクチャタイル群に対してのみ呼び出すだけでよい。

【0086】

－非ＩＤＲピクチャの各タイル群に対する復号化プロセスの開始時に、８．３．２項に規定の参照ピクチャリスト構成の復号化処理が参照ピクチャリスト０（RefPicList[０]）及び参照ピクチャリスト１（RefPicList[１]）の導出のために呼び出される。

【0087】

－８.３.３項における参照ピクチャマーキングのための復号化プロセスが呼び出され、参照ピクチャは「参照のために使用されない（unused for reference）」又は「長期参照のために使用（used for
long-term reference）」とマークされ得る。これは、第１のピクチャタイル群に対してのみ呼び出すだけでよい。

【0088】

－pic_width_in_luma_samples又はpic_height_in_luma_samplesが、CurrPicのpic_width_in_luma_samples又はpic_height_in_luma_samplesのそれぞれと等しくないRefPicList[０]及びRefPicList[１]における各アクティブ参照ピクチャについて、以下が適用される。

【0089】

－Ｘ．Ｙ．Ｚ項の再サンプリングプロセスが呼び出され［Ｅｄ．（ＭＨ）:追加すべき呼び出しパラメータの詳細］、出力は入力と同じ参照ピクチャマーキング及びピクチャオーダカウントを有する。

【0090】

－再サンプリングプロセスへの入力として用いられる参照ピクチャは、「参照のために使用されていない」とマークされている。

【0091】

ＣＴＵ（coding tree units）、スケーリング、変換、インループフィルタリング等のための復号化プロセスの呼び出しをさらに論じることができる。

【0092】

現在のピクチャの全てのタイルグループが復号された後で、現在の復号ピクチャは「短期間の参照のために用いられる（used for short-term reference）」とマークされる。

【0093】

再サンプリングプロセス
ＳＨＶＣ再サンプリングプロセス（ＨＥＶＣのＨ８．１．４．２節）は、以下の追加を伴って提案される。

【0094】

sps_ref_wrapaund_enabled_flag＝０の場合、サンプル値tempArray[n]（ｎ＝０．．７）は以下のように導出される。

【0095】

【数1】

【0096】

それ以外の場合、サンプル値tempArray[n]（ｎ＝０．．７）は以下のように導出される。

【0097】

【数2】

【0098】

sps_ref_wrapaund_enabled_flag＝０の場合、サンプル値tempArray[n]（ｎ＝０．．３）は以下のように導出される。

【0099】

【数3】

【0100】

それ以外の場合、サンプル値tempArray[n]（ｎ＝０．．３）は以下のように導出される。

【0101】

【数4】

【0102】

２.２.４. ＪＶＥＴ－Ｎ００５２
ビデオ圧縮規格における概念である適応的解像度変更は、少なくとも１９９６年以来からあり、特に参照ピクチャの再サンプリング（ＲＰＲ、Ａｎｎｅｘ Ｐ）及び縮小解像度更新（Ａｎｎｅｘ Ｑ）に向けたＨ．２６３＋関連の提案である。先ず、ＪＣＴ－ＶＣ時代にＣｉｓｃｏによって提案され、次いで（今日では適度に広く展開されている）ＶＰ９の文脈で、そしてさらに最近ではＶＶＣの文脈でという流れで、一定の注目を最近集めている。ＡＲＣは、所定のピクチャについて符号化する必要があるサンプルの数を低減し、それが望ましい場合には、結果として得られる参照ピクチャをより高い解像度までアップサンプリングすることを可能にする。

【0103】

特に関心のあるＡＲＣは２つのシナリオで検討される。

【0104】

１）ＩＤＲピクチャ等のイントラ符号化ピクチャは、インターピクチャよりもかなり大きいことが多い。理由にかかわらず、イントラ符号化を意図したダウンサンプリングピクチャは、将来の予測のためのより良好な入力を提供し得る。また、少なくとも低遅延のアプリケーションでは、速度制御の観点からもこれは明らかに有利である。

【0105】

２）少なくとも一部のケーブル及び衛星オペレータが日常的に行っているように、コーデックをそのブレーキングポイントの近くで動作させる場合、ＡＲＣは、ハーな遷移点を伴わないシーン遷移等の非イントラ符号化ピクチャに対してさえも便利になり得る。

【0106】

３）多分前向きになりすぎている（Looking perhaps a bit too much forward）：固定解像度の概念は概して正当可能であろうか？ＣＲＴからの離脱とレンダリング装置におけるスケーリングエンジンの普及に伴い、レンダリングと符号化解像度とのハードバインドは過去のものである。また、ビデオシーケンスにおいて多くのアクティビティが行われている場合、たとえそのアクティビティが空間的に他の場所で行われていても、大半の人は（おそらくは高解像度に関連する）細部に集中できないことを示唆する利用可能な研究がある。もしそれが正しく且つ一般に受け入れられていれば、細かい粒度分解能の変化は適応的ＱＰよりも優れた速度制御メカニズムになり得る。この点については現在議論されている。固定解像度ビットストリームの概念を取り除くことは、無数のシステム層及び実施のインプリケーションがあり、（少なくとも、それらの詳細な性質ではないにしても、それらの存在レベルでは）よく知られている。

【0107】

技術的に、ＡＲＣは参照ピクチャ再サンプリングとして実施することができる。参照ピクチャ再サンプリングの実施には、再サンプリングフィルタ及びビットストリームにおける再サンプリング情報のシグナリングという２つの主要な側面がある。本願は後者に焦点を当て、実施経験がある程度に前者に触れる。適切なフィルタ設計のさらなる研究が奨励され、提供される素案の設計を実質的に改善する点に関して、Ｔｅｎｃｅｎｔが慎重に検討され、適切な場合には、あらゆる提案を支持する。

【0108】

ＴｅｎｃｅｎｔのＡＲＣ実施の概要
図１１及び図１２は、ＴｅｎｃｅｎｔのＡＲＣエンコーダ及びデコーダの実装をそれぞれ示す。開示の技術の実施は、ピクチャの種類に関係なく、ピクチャの粒度毎にピクチャの幅及び高さを変更することを可能にする。エンコーダでは、入力された画像データは、現在のピクチャ符号化のために選択されたピクチャサイズにダウンサンプリングされる。第１の入力ピクチャがイントラピクチャとして符号化された後で、復号化されたピクチャが復号ピクチャバッファ（ＤＰＢ）に格納される。結果として得られたピクチャが異なるサンプリング比でダウンサンプリングされ、インターピクチャとして符号化される場合、ＤＰＢ内の参照ピクチャは、参照のピクチャサイズと現在のピクチャサイズとの間の空間比に従ってアップ／ダウンスケーリングされる。デコーダでは、復号化されたピクチャは再サンプリングすることなくＤＰＢに格納される。しかしながら、ＤＰＢ内の参照ピクチャは、動き補正のために用いられる場合、現在復号化されているピクチャと参照との間の空間比に関連してアップ／ダウンスケーリングされる。復号化されたピクチャは、表示のためにバンプアウトされた場合、元のピクチャサイズ又は所望の出力ピクチャサイズにアップサンプリングされる。動き推定／補償プロセスでは、動きベクトルは、ピクチャサイズ比及びピクチャオーダカウント差に関連してスケーリングされる。

【0109】

ＡＲＣパラメータのシグナリング
本明細書では、ＡＲＣパラメータという用語は、ＡＲＣを機能させるために必要な任意のパラメータの組み合わせとして用いられる。最も簡単な場合は、ズーム係数又は定義されたズーム係数でテーブルへのインデックスである。これは、ＪＶＥＴ－Ｍ０１３５で提案されたように、ターゲット解像度（例えば、サンプル又は最大ＣＵサイズの粒度）又はターゲット解像度を提供するテーブルへのインデックスであり得る。また、使用中のアップ／ダウンサンプリングフィルタのフィルタパラメータ（フィルタ係数に至るまで）又はフィルタセレクタも含まれ得る。

【0110】

最初から、本明細書で提案する実施は、少なくとも概念的に、ピクチャの異なる部分について異なるＡＲＣパラメータを可能にすることである。現在のＶＶＣ草案の通り、適切なシンタックス構造は矩形タイル群（ＴＧ）であり得ることが提案される。スキャンオーダーＴＧを用いるものは、ＡＲＣをフルピクチャのみに用いるものに制限され得るか又はスキャンオーダーＴＧが矩形ＴＧに含まれる程度に制限され得る。これは、ビットストリーム制約で簡単に指定できる。

【0111】

異なるＴＧは異なるＡＲＣパラメータを有し得るため、ＡＲＣパラメータの適切な位置は、ＴＧヘッダ内又はＴＧの範囲を持つパラメータセット内であり、ＴＧヘッダによって参照されるか（現在のＶＶＣ草案における適応パラメータセット）又はより高いパラメータセットにおけるテーブルへのより詳細な参照（インデックス）であり得る。これら３つの選択肢のうち、この時点で、ＴＧヘッダを用いてＡＲＣパラメータを含むテーブルエントリへの参照を符号化することが提案され、そのテーブルはＳＰＳ内に位置し、（今回の）ＤＰＳに符号化されている。ズーム係数はパラメータ設定値を用いることなく、ＴＧヘッダに直接符号化できる。ＪＶＥＴ－Ｍ０１３５で提案されているように、参照のためのＰＰＳを用いることは、ＡＲＣパラメータのタイル群毎のシグナリングが設計基準である場合には対比的に示される。

【0112】

テーブルエントリ自体については、以下のオプションが利用可能である。

【0113】

－両方の次元についていずれか１つ又はＸ及びＹの次元で独立してダウンサンプル係数を符号化すること。これはほとんど（ＨＷ－）実施の議論であり、Ｘ次元のズーム係数がかなり柔軟であるが、Ｙ次元が１に固定されているか又は選択肢が非常に少ない結果を好むものもあるだろう。そのような制約を表現するのにシンタックスは間違った場所であり、もしそれらが望ましいなら、適合のための要件として表現される制約は好ましいと提案される。つまり、シンタックスの柔軟に保たれる。

【0114】

－ターゲット解像度を符号化することが以下で提案される。現在の解像度との関連でこれらの解像度についてより多くの又は少ない複雑な制約がある場合があり、多分ビットストリーム適応要件で表される。

【0115】

－ピクチャ合成／抽出を可能にするために、タイル群毎のダウンサンプリングが好ましい。しかしながら、シグナリングの観点からは重要ではない。もしグループがピクチャの粒度でのみＡＲＣを許容するという賢明でない決定をしているなら、全てのＴＧが同じＡＲＣパラメータを用いるというビットストリーム適合性要件を含めることができる。

【0116】

－ＡＲＣに関する制御情報。我々の以下の設計では、それは参照ピクチャサイズを含む。

【0117】

－フィルタ設計の柔軟性は必要か？わずかなコードポイントより多い必要があるか？答えが「はい」の場合、それらをＡＰＳに入れるか？一部の実施では、ダウンサンプルフィルタが変化し、ＡＬＦが留まる場合、ビットストリームはオーバーヘッドを受け入れる（eat）必要があることが提案される。

【0118】

現時点では、提案された技術を(可能な限り)整合させ、シンプルに保つために、以下を提案する:
－固定フィルタ設計
－ビットストリーム制約ＴＢＤのＳＰＳ内のテーブルのターゲット解像度
－キャップ交換／ネゴシエーションを促進にするＤＰＳにおける最小／最大ターゲット解像度
結果として得られるシンタックスは以下のようになり得る。

【0119】

【表6】

【0120】

max_pic_width_in_luma_samplesは、ビットストリームにおけるルーマサンプル単位で復号されたピクチャの最大幅を指定する。max_pic_width_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。dec_pic_width_in_luma_samples[i]の値はmax_pic_width_in_luma_samplesの値より大きくなることはできない。

【0121】

max_pic_height_in_luma_samplesは、ビットストリームにおけるルーマサンプル単位で復号されたピクチャの最大高さを指定する。max_pic_height_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。dec_pic_height_in_luma_samples[i]の値はmax_pic_height_in_luma_samplesの値より大きくなることはできない。

【0122】

【表7】

【0123】

adaptive_pic_resolution_change_flag＝０は、出力ピクチャサイズ（output_pic_width_in_luma_samples、output_pic_height_in_luma_samples）、復号ピクチャサイズの数（num_dec_pic_size_in_luma_samples_minus１）及び少なくとも１つの復号ピクチャサイズ（dec_pic_width_in_luma_samples[i]、dec_pic_height_in_luma_samples[i]）がＳＰＳに存在することを指定する。参照ピクチャサイズ（reference_pic_width_in_luma_samples、reference_pic_height_in_luma_samples）が存在し、reference_pic_size_present_flagの値の条件とされている。

【0124】

output_pic_width_in_luma_samplesは、ルーマサンプルの単位で出力ピクチャの幅を指定する。output_pic_width_in_luma_samplesは０と等しくないものとする。

【0125】

output_pic_height_in_luma_samplesは、ルーマサンプルの単位で出力ピクチャの高さを指定する。output_pic_height_in_luma_samplesは０と等しくないものとする。

【0126】

reference_pic_size_present_flag＝１は、reference_pic_width_in_luma_samples及びreference_pic_height_in_luma_samplesが存在することを指定する。

【0127】

reference_pic_width_in_luma_samplesは、ルーマサンプルの単位で参照ピクチャの幅を指定する。output_pic_width_in_luma_samplesは０と等しくないものとする。存在しない場合、reference_pic_width_in_luma_samplesの値はdec_pic_width_in_luma_samples[i]と等しいと推定される。

【0128】

reference_pic_height_in_luma_samplesは、ルーマサンプルの単位で参照ピクチャの高さを指定する。output_pic_height_in_luma_samplesは０と等しくないものとする。存在しない場合、reference_pic_height_in_luma_samplesの値はdec_pic_height_in_luma_samples[i]と等しいと推定される。

【0129】

注記１－出力ピクチャのサイズは、output_pic_width_in_luma_samples及びoutput_pic_height_in_luma_samplesの値と等しいものとする。参照ピクチャのサイズは、参照ピクチャが動き補正に用いられる場合、reference_pic_width_in_luma_samples及びreference_pic_height_in_luma_samplesの値と等しいものとする。

【0130】

num_dec_pic_size_in_luma_samples_minus１+１は、符号化ビデオシーケンスのルーマサンプルの単位で復号ピクチャサイズ（dec_pic_width_in_luma_samples[i]、dec_pic_height_in_luma_samples[i]）の数を指定する。

【0131】

dec_pic_width_in_luma_samples[i]は符号化ビデオシーケンスのルーマサンプルの単位で復号ピクチャサイズのｉ番目の幅を指定する。dec_pic_width_in_luma_samples[i]は０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。

【0132】

dec_pic_height_in_luma_samples[i]は符号化ビデオシーケンスのルーマサンプルの単位で復号ピクチャサイズのｉ番目の高さを指定する。dec_pic_height_in_luma_samples[i]は０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。

【0133】

注記２－ｉ番目の復号ピクチャサイズ（dec_pic_width_in_luma_samples[i]、dec_pic_height_in_luma_samples[i]）は、符号化ビデオシーケンスにおける復号ピクチャの復号ピクチャサイズと等しくてもよい。

【0134】

【表8】

【0135】

dec_pic_size_idxは、復号ピクチャの幅はpic_width_in_luma_samples[dec_pic_size_idx]と等しく、復号ピクチャの高さはpic_height _in_luma_samples[dec_pic_size_idx]と等しいものとすることを指定する。

【0136】

フィルタ
提案した設計は概念的に、元のピクチャから入力ピクチャへのダウンサンプリングフィルタと、動き推定／補償のために参照ピクチャを再スケーリングするアップ／ダウンサンプリングフィルタと、復号ピクチャから出力ピクチャへのアップサンプリングフィルタという４つの異なるフィルタセットを含む。最初及び最後のものは、非標準的事項として残すことができる。仕様の範囲では、アップ／ダウンサンプリングフィルタは、適切なパラメータセットにおいて明示的にシグナリングされるか又は予め定義される必要がある。

【0137】

我々の実施は、動き補償のために用いられるべき参照ピクチャをサイズ変更するダウンサンプリングのために、１２タップ２Ｄ分離可能フィルタであるＳＨＶＣのダウンサンプリングフィルタ（ＳＨＭ ｖｅｒ．１２．４）を用いる。現在の実施では、ダイアディックサンプリングのみがサポートされる。したがって、ダウンサンプリングフィルタの位相は、デフォルトでゼロに設定される。アップサンプリングについては、位相をシフトし、ルーマ及びクロマピクセル位置を元の位置に合わせるために１６相の８タップ補間フィルタが用いられる。

【0138】

表９及び表１０は、ルーマアップサンプリングプロセスに用いられる８タップフィルタ係数ｆＬ［ｐ，ｘ］（ｐ＝０．．１５及びｘ＝０．．７）と、クロマアップサンプリングプロセスに用いられる４タップフィルタ係数ｆＣ［ｐ，ｘ］（ｐ＝０．．１５及びｘ＝０．．３）を示す。

【0139】

表１１は、ダウンサンプリングプロセスのための１２タップフィルタ係数を示す。ダウンサンプリングでは、ルーマ及びクロマの両方に同じフィルタ係数が用いられている。

【0140】

【表9】

【0141】

【表10】

【0142】

【表11】

【0143】

コンテンツ及び／又はスケーリング係数に適応するフィルタを用いる場合、（おそらく有意な）主観的及び客観的な利得が期待されることが予想される。

【0144】

タイルグループ境界の議論
タイル群に関連する多くの研究についてもおそらく当てはまることであるが、タイル群（ＴＧ）ベースのＡＲＣに関する我々の実施は完全に終わっているとは言えない。我々の選好は、圧縮領域において、複数のサブピクチャを合成されたピクチャにする空間的構成及び抽出の議論が少なくともたたき台をもたらした場合に、その実施を再考することである。しかしながら、このことは、結果をある程度推定し、それに従って我々のシグナリング設計を適応させることを妨げるものではない。

【0145】

今のところ、タイルグループヘッダは、すでに述べた理由から、上記で提案したように、dec_pic_size_idx等のものにとって正しい場所である。単一のｕｅ（ｖ）コードポイントdec_pic_size_idxは、タイルグループヘッダに条件付きで存在し、使用されるＡＲＣパラメータを示すために用いられる。ピクチャ毎のＡＲＣのみである実施を一致させるために、スペック空間では、単一のタイルグループのみを符号化するか又は所与の符号化ピクチャの全てのＴＧヘッダが（存在する場合）dec_pic_size_idxの値が同じであることをビットストリームコンプライアンスの条件とする必要がある。

【0146】

パラメータdec_pic_size_idxは、サブピクチャを開始するヘッダのいずれかに移動させることができる。それは引き続きタイルグループヘッダであり得る。

【0147】

これらのシンタックスな考慮以外に、タイルグループ又はサブピクチャベースのＡＲＣを可能にするために、いくつかの追加作業が必要である。おそらく最も困難な部分は、サブピクチャがより小さいサイズに再サンプリングされたピクチャ内の不要なサンプルの問題をどのように対処するかである。

【0148】

図１３は、ＡＲＣのためのタイル群ベースの再サンプリングの例を示す。４つのサブピクチャ（ビットストリームシンタックスにおいて４つの矩形のタイルグループとしておそらく表される）から構成される右側のピクチャを考えてみる。左側の右下のＴＧは半分のサイズにサブサンプリングされている。「半分」と表記される、関連領域の外のサンプルをどのようにするかを議論する必要がある。

【0149】

多くの（大半？、全て？）の以前のビデオ符号化規格では、圧縮ドメイン内のピクチャの部分の空間的抽出はサポートされていないという共通点があった。これは、ピクチャの各サンプルが１つ以上のシンタックス要素によって表され、各シンタックス要素は少なくとも１つのサンプルに影響を与えることを意味する。これを維持するために、「半分」とラベル付けされたダウンサンプリングされたＴＧによってカバーされるサンプルの周囲の領域をどうにかして追加する必要があり得る。Ｈ．２６３＋のＡｎｎｅｘ Ｐでは、パディングによってこの問題を解決する。実際、パディングされたサンプルのサンプル値は、ビットストリームで（特定の厳密な制限の範囲内で）シグナリングすることができ得る。

【0150】

以前の仮定からの大幅な逸脱を多分構成し得るが、ピクチャの矩形部分に基づくサブビットストリーム抽出（及び構成）をサポートする必要があり得る代替案は、復元されたピクチャの各サンプルが符号化ピクチャ内の何か（たとえ、それの何かがスキップされたブロックだけであっても）によって表される必要があるという現在の理解を緩和することであり得る。

【0151】

実施上の考慮事項、システムインプリケーション及びプロファイル／レベル
「ベースライン／メイン」プロファイルに含まれるべき基本的なＡＲＣを提案する。特定のアプリケーションシナリオで必要でない場合は、サブプロファイリングを用いてそれらを削除してもよい。一定の制限が許容され得る。この点に関し、特定のＨ．２６３＋プロファイル及び（プロファイルの前の）「推奨モード」には、「暗黙の係数４（implicit factor of 4）」、すなわち、両方の次元における二項ダウンサンプリング、としてのみ用いられるＡｎｎｅｘ Ｐが含まれたことに留意されたい。これは、テレビ会議のファストスタートをサポートするのに十分であった(Ｉフレームを素早く乗り越える)のには十分だった。

【0152】

この設計は、全てのフィルタリングを「臨機応変に（on the fly）」で行うことができ、メモリ帯域幅の増加がないか又は無視できる程度である。そうであれば、ＡＲＣをエキゾチックなプロファイルに移す必要はないように思われる。

【0153】

複雑な表等は、ＪＶＥＴ－Ｍ０１３５と共にMarrakechで論じられているように、能力交換には有意義に用いられないかもしれない。オプションの数は、オファーアンサーや同様の限定された深度のハンドシェイクを仮定して、意味のあるクロスベンダインターオプを可能にするために、単純に大きくなる。現実的には、能力交換シナリオにおいてＡＲＣを有意義にサポートするために、大半のインターオップポイントでほんの少数にフォールバックしなければならない。例えば、ＡＲＣなし、暗黙の係数４のＡＲＣ、完全なＡＲＣである。代替的に、全てのＡＲＣに必要なサポートを指定し、ビットストリームの複雑性の制限をより高いレベルのＳＤＯに任せることが可能である。これは、いずれにせよ（サブプロファイリング及びフラグの文脈で既に議論したものを越えて）ある時点で行うべき戦略的議論である。

【0154】

レベルに関して、基本的な設計原理は、ビットストリーム適合の条件として、ビットストリームにおいてアップサンプリングがそれだけシグナリングされてもアップサンプリングされたピクチャのサンプルカウントはビットストリームのレベルに適合する必要があり、全てのサンプルはアップサンプリングされた符号化ピクチャに適合する必要がある。なお、これはＨ２６３＋では当てはまらず、特定のサンプルが存在しない可能性がある。

【0155】

２．２．５． ＪＶＥＴ－Ｎ０１１８
以下の側面が提案されている。

【0156】

１． ピクチャ解像度のリストはＳＰＳでシグナリングされ、リストのインデックスは個々のピクチャのサイズを指定するためにＰＰＳでシグナリングされる。

【0157】

２． 出力すべきピクチャについて、再サンプリング前の復号ピクチャは（必要に応じて）クロップされて出力される。すなわち、再サンプリングされたピクチャは出力用ではなく、インター予測参照のためだけのものである。

【0158】

３． １．５倍及び２倍の再サンプリング比をサポートする。任意の再サンプリング比はサポートしない。１つ又は２つ以上の他の再サンプリング比の必要性を検討する。

【0159】

４． ピクチャレベルの再サンプリングとブロックレベルの再サンプリングとの間では、提唱者らはブロックレベルの再サンプリングを好む。

【0160】

ａ．しかしながら、ピクチャレベルの再サンプリングが選択される場合、以下の側面が提案される。

【0161】

ｉ．参照ピクチャが再サンプリングされる場合、参照ピクチャの再サンプリングされたバージョンと、オリジナルの再サンプリングされたバージョンとの双方がＤＰＢに格納されるため、双方はＤＰＢのフルネスに影響を及ぼす。

【0162】

ｉｉ．再サンプリングされた参照ピクチャは、対応する再サンプリングされていない参照ピクチャが「参照のために使用されない」とマークされている場合、「参照のために使用されない」とマークされる。

【0163】

ｉｉｉ．ＲＰＬシグナリングシンタックスは変更されずに維持されるのに対して、ＲＰＬ構築プロセスは次のように変更される。参照ピクチャをＲＰＬエントリに含める必要があり、現在のピクチャと同じ解像度を有する参照ピクチャのバージョンがＤＰＢ内にない場合、ピクチャ再サンプリングプロセスが呼び出され、その参照ピクチャの再サンプリングバージョンはＲＰＬエントリに含められる。

【0164】

ｉｖ．ＤＰＢに存在する再サンプリングされた参照ピクチャの数は、例えば２以下に制限されるべきである。

【0165】

ｂ．そうでなければ（ブロックレベル再サンプリングが選択された場合）、以下が提案される。

【0166】

ｉ．最悪ケースのデコーダの複雑性を制限するために、現在のピクチャとは異なる解像度を有する参照ピクチャからのブロックの双方向予測を禁止することが提案されている。

【0167】

ｉｉ．別の選択肢は、再サンプリング及び１／４ピクセル単位の補間を行う必要がある場合、２つのフィルタが組み合わされ、動作が一度に適用されることである。

【0168】

５．ピクチャベース及びブロックベースの再サンプリングアプローチのいずれが選択されるかにかかわらず、時間的動きベクトルスケーリングが必要に応じて適用されることが提案される。

【0169】

２．２．５．１． 実施
ＡＲＣソフトウェアは、以下の変更を加えてＶＴＭ－４．０．１上で実施された。

【0170】

－サポートされている解像度のリストはＳＰＳでシグナリングされる。

【0171】

－空間分解能シグナリングがＳＰＳからＰＰＳに移動された。

【0172】

－参照ピクチャを再サンプリングするために、ピクチャベースの再サンプリングスキームが実施された。ピクチャが復号された後に、再構成されたピクチャは異なる空間分解能に再サンプリングされ得る。元の再構成ピクチャ及び再サンプリングされ再構成されたピクチャの双方は、ＤＰＢに格納され、将来のピクチャにより復号化順で参照するために利用可能である。

【0173】

－実施されている再サンプリングフィルタは、ＪＣＴＶＣ－Ｈ０２３４で以下のようにテストされたフィルタに基づく。

【0174】

－アップサンプリングフィルタ：タップが（－４、５４、１６、－２）／６４の４タップ＋／－１／４相ＤＣＴＩＦ
－ダウンサンプリングフィルタ：タップが（１、０、－３、０、１０、１６、１０、０、－３、０、１）/３２のｈ１１フィルタ
－現在のピクチャ（すなわち、Ｌ０及びＬ１）の参照ピクチャリストを構成する場合、現在のピクチャと同じ解像度を有する参照ピクチャのみが用いられる。なお、参照ピクチャはそれらの元のサイズ又は再サンプリングしたサイズの両方で利用可能であり得る。

【0175】

－ＴＭＶＰ及びＡＴＶＭＰが有効にされ得る。しかしながら、現在のピクチャ及び参照ピクチャの元の符号化解像度が異なる場合、その参照ピクチャについてはＴＭＶＰ及びＡＴＭＶＰが無効になる。

【0176】

－開始点ソフトウェアの実施を簡単及び簡素にするために、ピクチャを出力する場合、デコーダは最高の利用可能な解像度を出力する。

【0177】

ピクチャサイズ及びピクチャ出力のシグナリングについて
１． ビットストリームにおける符号化ピクチャの空間分解能のリストについて
現在、ＣＶＳ内の全ての符号化ピクチャは同じ解像度を有する。そのため、ＳＰＳにおいて、ただ１つの解像度（すなわち、ピクチャの幅及び高さ）をシグナリングするのが分かりやすい。ＡＲＣのサポートでは、１つの解像度ではなく、ピクチャ解像度のリストをシグナリングする必要がある。このリストをＳＰＳでシグナリングし、個々のピクチャのサイズを指定するためにリストのインデックスをＰＰＳでシグナリングすることが提案される。

【0178】

２. ピクチャ出力について
出力されるべきピクチャについては、再サンプリング前の復号ピクチャは（必要に応じて）クロップされて出力される、すなわち再サンプリングされたピクチャは出力のためのものではなく、インター予測参照のためだけのものであることが提案される。ＡＲＣ再サンプリングフィルタは、インター予測のための再サンプリングされたピクチャの使用が最適化されるように設計される必要があり、そのようなフィルタは、ピクチャの出力／表示目的には最適でない可能性があるのに対して、ビデオ端末装置は、既に実施されている、最適化された出力ズーミング／スケーリング機能を通常有する。

【0179】

２．２．５．３． 再サンプリングについて
復号ピクチャの再サンプリングは、ピクチャベース又はブロックベースのいずれかであり得る。ＶＶＣにおける最終的なＡＲＣ設計では、ブロックベースの再サンプリングがピクチャベースの再サンプリングよりも望ましい。これらの２つのアプローチを議論し、これらの２つのうちのどちらをＶＶＣにおけるＡＲＣサポートに指定するかをＪＶＥＴが決定することを推奨する。

【0180】

ピクチャベースの再サンプリング
ＡＲＣのためのピクチャベースの再サンプリングでは、ピクチャは特定の解像度のために１回だけが再サンプリングされ、その後にそれがＤＰＢに格納されるのに対して、同じピクチャの再サンプリングされていないバージョンもＤＰＢに維持される。

【0181】

ＡＲＣのためにピクチャベースの再サンプリングの用いることには、１）再サンプリングされた参照ピクチャを格納するために追加のＤＰＢバッファが必要になること及び２）ＤＰＢからの参照ピクチャデータの読み出し及びＤＰＢへの参照ピクチャデータの書き込み動作の増加により、追加のメモリ帯域幅が必要であること、という２つの問題がある。

【0182】

ＤＰＢで参照ピクチャの１バージョンのみを保持することは、ピクチャベースの再サンプリングの場合良案ではない。再サンプリングされていないバージョンのみが保存されている場合、複数のピクチャは同じ参照ピクチャを参照し得るため、参照ピクチャを複数回再サンプリングする必要があり得る。他方で、参照ピクチャが再サンプリングされ、再サンプリングされたバージョンのみが保持される場合、参照ピクチャを出力する必要がある場合に逆再サンプリングを適用する必要がある。何故なら、上述したように、再サンプリングされていないピクチャを出力したほうが良いからである。これは、再サンプリングプロセスは可逆演算ではないため問題である。ピクチャＡをとり、それをダウンサンプリングし、その後にアップサンプリングしてＡと同じ解像度のＡ’を得た場合、ＡとＡ’とは同じではない。ダウンサンプリング及びアップサンプリングプロセスの間に一部の高周波数情報が失われたため、Ａ’に含まれる情報はＡよりも少なくなり得る。

【0183】

追加のＤＰＢバッファ及びメモリ帯域幅の問題に対処するために、ＶＶＣにおけるＡＲＣ設計がピクチャベースの再サンプリングを用いる場合、以下が適用されることが提案される。

【0184】

１．参照ピクチャが再サンプリングされる場合、参照ピクチャの再サンプリングされたバージョンと元の再サンプリングされたバージョンの双方がＤＰＢに格納されるため、双方はＤＰＢのフルネスに影響を及ぼす。

【0185】

２． 再サンプリングされた参照ピクチャは、対応する再サンプリングされていない参照ピクチャが「参照のために使用されない」とマークされている場合、「参照のために使用されない」とマークされる。

【0186】

３． 各タイルグループの参照ピクチャリスト（ＲＰＬ）は、現在のピクチャと同じ解像度を有する参照ピクチャを含む。ＲＰＬシグナリングシンタックスを変更する必要はないが、ＲＰＬ構築プロセスは、先の文で述べられたことを確実にするために、次のように修正される：参照ピクチャをＲＰＬエントリに含める必要がある場合に、その参照ピクチャの現在のピクチャと同じ解像度を有するバージョンがまだ利用可能ではない場合、ピクチャ再サンプリングプロセスが呼び出され、その参照ピクチャの再サンプリングバージョンが含まれる。

【0187】

４． ＤＰＢ内に存在し得る再サンプリングされた参照ピクチャの数は、例えば２以下に制限されるべきである。

【0188】

さらに、時間的ＭＶが現在のフレームとは異なる解像度で参照フレームから来る場合に時間的ＭＶの使用（例えば、マージモード及びＡＴＭＶＰ）を可能にするために、時間的ＭＶを現在の解像度に必要に応じてスケーリングすることを提案する。

【0189】

ブロックベースのＡＲＣ再サンプリング
ＡＲＣのためのブロックベースの再サンプリングでは、参照ブロックは必要に応じて再サンプリングされ、再サンプリングされたピクチャはＤＰＢに格納されない。

【0190】

ここでの主な問題は、付加的なデコーダの複雑性である。これは、参照ピクチャ内のブロックが、他のピクチャ内の複数のブロックにより及び複数のピクチャ内の複数のブロックにより複数回参照され得るからである。

【0191】

参照ピクチャ内のブロックが現在ピクチャ内のブロックによって参照され、参照ピクチャと現在ピクチャとの解像度が異なる場合、参照ブロックは、参照ブロックが整数ピクセルの解像度を有するように補間フィルタの呼び出しによって再サンプリングされる。動きベクトルが１／４ピクセル単位の場合、１／４ピクセル単位の解像度で再サンプリングされた参照ブロックを得るために補間プロセスが再度呼び出される。したがって、異なる解像度を伴う参照ブロックからの現在のブロックのための各動き補償動作に対して、１つの代わりに最大で２回の補間フィルタリング動作が必要になる。ＡＲＣサポートなしでは、最大で１回だけの補間フィルタリング動作（即ち、１／４ピクセル単位の解像度での参照ブロックの生成）が必要になる。

【0192】

最悪ケースの複雑性を制限するために、ＶＶＣにおけるＡＲＣ設計がブロックベースの再サンプリングを用いる場合、以下が適用されることが提案される。

【0193】

－現在のピクチャとは異なる解像度を有する参照ピクチャからのブロックの双方向予測を禁止される。

【0194】

－より正確に言えば、制約は次の通りである。現在のピクチャピクチャｐｉｃＡ内の現在のブロックｂｌｋＡが参照ピクチャｐｉｃＢ内の参照ブロックｂｌｋＢを参照する場合、ｐｉｃＡ及びｐｉｃＢが異なる解像度を有する場合、ブロックｂｌｋＡは単方向予測ブロックとする。

【0195】

この制約により、ブロックを復号化するために必要な最悪の場合の補間動作の数は２つに制限される。ブロックが異なる解像度のピクチャからのブロックを参照する場合、必要な補間動作の数は、上述のように２である。これは、ブロックが同じ解像度のピクチャからの参照ブロックを参照し、双方向予測ブロックとして符号化される場合と同じである。何故なら、補間動作の数も２だからである（すなわち、各参照ブロックについて１／４ピクセル単位の解像度を得るために１回）。

【0196】

実施を簡素化するために、ＶＶＣにおけるＡＲＣ設計がブロックベースの再サンプリングを用いる場合、以下が適用される別のバリエーションが提案される。

【0197】

－参照フレーム及び現在のフレームが異なる解像度を有する場合、予測子の各ピクセルの対応する位置が最初に計算され、その後に補間は１回だけ適用される。すなわち、２回の補間動作（すなわち、再サンプリングのための１回及び１／４ピクセル単位の補間のために１回）は１回だけの補間動作に組み合わされる。現在のＶＶＣにおけるサブペル（sub-pel）補間フィルタは再利用できるが、この場合、補間の粒度は拡大されるべきであるが、補間動作の回数は２回から１回に減らされる。

【0198】

－時間的ＭＶが現在のフレームとは異なる解像度で参照フレームから来る場合に時間的ＭＶの使用（例えば、マージモード及びＡＴＭＶＰ）を可能にするために、時間的ＭＶを現在の解像度に必要に応じてスケーリングすることを提案する。

【0199】

再サンプリング比
ＪＶＥＴ－Ｍ０１３５［１］では、ＡＲＣについての議論を開始するために、ＡＲＣの開始点について、２倍（アップサンプリングでは２×２、ダウンサンプリングでは１／２×１／２を意味する）の再サンプリング比のみを考慮することが提案されている。マラケシュ会議後のこの話題に関するさらなる議論から、２倍の再サンプリング比のみをサポートすることは非常に限定的であることが分かった。何故なら、場合によっては、再サンプリングされた解像度と再サンプリングされていない解像度との差が小さい方が有益であり得るからである。

【0200】

任意の再サンプリング比をサポートすることが望ましいかもしれないが、それをサポートすることは困難であり得る。何故なら、任意の再サンプリング比をサポートするためには、定義して実施する必要がある再サンプリングフィルタの数が多すぎることになり、デコーダの実施に大きな負担を課すことになるからである。

【0201】

１よりも大きいが小さな数（少なくとも１.５倍及び２倍の再サンプリング比）の再サンプリング比がサポートされる必要であり、任意の再サンプリング比はサポートされないことが提案されている。

【0202】

２．２．５．４ 最大ＤＰＢバッファサイズ及びバッファフルネス
ＡＲＣでは、ＤＰＢは同じＣＶＳ内で異なる空間分解能の復号ピクチャを含み得る。ＤＰＢ管理及び関連する側面について、復号ピクチャの単位でＤＰＢサイズ及びフルネスをカウントすることはもはや機能しない。

【0203】

以下は、ＡＲＣがサポートされている場合に対処する必要がある特定の側面と、最終的なＶＶＣの仕様における可能性のある解決策についての議論である。

【0204】

１． PicSizeInSamplesY（すなわち、PicSizeInSamplesY =
pic_width_in_luma_samples ＊ pic_height_in_luma_samples）の値をMaxDpSize（すなわち、ＤＰＢに存在し得る参照ピクチャの最大数）の導出に用いる代わりに、MaxDpbSizeの導出は、MinPicSizeInSamplesYの値に基づく。MinPicSizeInSamplesYは以下のように定義される。

【0205】

MinPicSizeInSampleY＝（ビットストリームにおける最小ピクチャ解像度の幅）＊（ビットストリームにおける最小解像度の高さ）
MaxDpbSizeの導出は（ＨＥＶＣ式に基づいて）以下のように修正される。

【0206】

【数5】

【0207】

２． 各復号ピクチャは、PictureSizeUnitと呼ばれる値に関連する。PictureSizeUnitは、復号ピクチャサイズがMinPicSizeInSampleYに対してどれくらい大きいかを指定する整数の値である。PictureSizeUnitの定義は、ＶＶＣにおけるＡＲＣでどの再サンプリング比がサポートされているかによって決まる。

【0208】

例えば、ＡＲＣが再サンプリング比２のみをサポートする場合、PictureSizeUnitは次のように定義される。

【0209】

－ビットストリームにおける最小解像度を有する復号ピクチャは、１のPictureSizeUnitに関連する。

【0210】

－ビットストリームにおける最小解像度の２×２の解像度を有する復号ピクチャは、４のPictureSizeUnit（すなわち、１×４）に関連する。

【0211】

別の例では、ＡＲＣが１.５及び２の再サンプリング比の両方をサポートする場合、PictureSizeUnitは以下のように定義される。

【0212】

－ビットストリームにおける最小解像度を有する復号ピクチャは、４のPictureSizeUnitに関連する。

【0213】

－ビットストリームにおける最小解像度の１.５×１.５の解像度を有する復号ピクチャは、９のPictureSizeUnit（すなわち、２．２５×４）に関連する。

【0214】

－ビットストリームにおける最小解像度の２×２の解像度を有する復号ピクチャは、１６のPictureSizeUnit（すなわち、４×４）に関連する。

【0215】

ＡＲＣによってサポートされるその他の再サンプリング比については、上記の例と同じ原則を用いて、各ピクチャサイズについてのPictureSizeUnitの値を決定すべきである。

【0216】

３． 変数MinPictureSizeUnitをPictureSizeUnitの可能な最小値とする。つまり、ＡＲＣが再サンプリング比２のみをサポートする場合、MinPictureSizeUnitは１であり、ＡＲＣが再サンプリング比１.５及び２をサポートする場合、MinPictureSizeUnitは４であり、MinPictureSizeUnitの値を決定するための同じ原理が用いられる。

【0217】

４． sps_max_dec_pic_buffering_minus１[i]の値の範囲は、０～（MinPictureSizeUnit * （MaxDpbSize - １））の範囲に指定される。変数MinPictureSizeUnitは、PictureSizeUnitの可能な最小値である。

【0218】

５．ＤＰＢフルネス動作は、PictureSizeUnitに基づいて以下のように規定される。

【0219】

－ＨＲＤは復号ユニット０で初期化され、ＣＰＢ及びＤＰＢは共に空に設定される（ＤＰＢフルネスは０に設定される）。

【0220】

－ＤＰＢがフラッシュされる（すなわち、全てのピクチャがＤＰＢから削除される）場合、ＤＰＢフルネスは０に設定される。

【0221】

－ピクチャがＤＰＢから削除された場合、ＤＰＢフルネスは削除されたピクチャに関連するPictureSizeUnitの値だけデクリメントされる。

【0222】

－ピクチャがＤＰＢに挿入された場合、ＤＰＢフルネスは、挿入されたピクチャに関連するPictureSizeUnitの値だけインクリメントされる。

【0223】

２．２．５．５ 再サンプリングフィルタ
ソフトウェア実施では、実施される再サンプリングフィルタは、ＪＣＴＶＣ－Ｈ０２３４［３］に記載されている前に利用可能なフィルタから単純に取られている。他の再サンプリングフィルタをテストし、それらがより良い性能及び／又はより低い複雑性を提供する場合には、それらを用いるべきである。複雑性と性能の間のトレードオフを取り決めるために、様々な再サンプリングフィルタをテストすることが提案される。そのようなテストはＣＥで行うことができる。

【0224】

２．２．５．６ 既存のツールに対するその他の必要な修正
ＡＲＣをサポートするために、既存のコーディングツールの一部に対して、いくつかの修正及び／又は追加の動作が必要になり得る。例えば、ＡＲＣソフトウェア実施のピクチャベースの再サンプリングでは、簡素化のために、現在のピクチャ及び参照ピクチャの元の符号化解像度が異なる場合に、ＴＭＶＰ及びＡＴＭＶＰは無効にされる。

【0225】

２．２．６ ＪＶＥＴ－Ｎ０２７９
「将来のビデオ符号化規格のための要件」によれば、「それぞれが異なる特性（例えば、空間分解能又はサンプルビット深度）を有する同一コンテンツの複数の表現を提供するアダプティブストリーミングサービスの場合、規格は高速な表現スイッチングをサポートするものとする」とされている。リアルタイムのビデオ通信では、Ｉピクチャを挿入することなく、符号化ビデオシーケンス内の解像度を変化させることは、ビデオデータを動的チャネル条件又はユーザの好みにシームレスに適合させるだけでなく、Ｉピクチャによってもたらされるビート効果を取り除くことができる。適応的解像度変更の仮想的な例が図１４に示され、ここでは、現在のピクチャは異なるサイズの参照ピクチャから予測される。

【0226】

この貢献は、ＶＴＭにおける現在の動き補償予測プロセスに、適応的解像度変更及び修正をシグナリングする高レベルシンタックスを提案する。これらの修正は、既存の動き補償補間器に変更を加えずに、動きベクトルスケーリング及びサブペル位置導出に限定される。これは、既存の動き補償補間器が再利用されることを可能にし、追加コストをもたらし得る適応的解像度変更をサポートするための新たな処理ブロックを必要としない。

【0227】

２．２．６．１ 適応的解像度変更シグナリング

【0228】

【表12】

【0229】

[[pic_width_in_luma_samples]
は、各復号ピクチャの幅をルーマサンプル単位で指定する。pic_width_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。
pic_height_in_luma_samplesは、各復号ピクチャの高さをルーマサンプル単位で指定する。pic_height_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。]]

【0230】

max_pic_width_in_luma_samplesは、ＳＰＳを参照する復号ピクチャの最大幅をルーマサンプル単位で指定する。max_pic_width_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。

【0231】

max_pic_height_in_luma_samplesは、ＳＰＳを参照する復号ピクチャの最大高さをルーマサンプル単位で指定する。max_pic_height_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。

【0232】

【表13】

【0233】

pic_size_difference_from_max_flag=１は、ＰＰＳが参照されたＳＰＳのmax_pic_width_in_luma_samples及びmax_pic_height_in_luma_sampleとは異なるピクチャ幅又ピクチャ高さをシグナリングすることを指定する。pic_size_different_from_max_flag＝０は、pic_width_in_luma_samples及びpic_height_in_luma_samplesが、参照されたＳＰＳのmax_pic_width_in_luma_samples及びmax_pic_height_in_luma_sampleと同じであることを指定する。

【0234】

pic_width_in_luma_samplesは、各復号ピクチャの幅をルーマサンプル単位で指定する。pic_width_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。pic_width_in_luma_samplesが存在しない場合、それはmax_pic_width_in_luma_samplesと等しいと推定される。

【0235】

pic_height_in_luma_samplesは、各復号ピクチャの高さをルーマサンプル単位で指定する。pic_height_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。pic_height_in_luma_samplesが存在しない場合、それはmax_pic_height_in_luma_samplesと等しいと推定される。

【0236】

水平及び垂直スケーリング比は、全てのアクティブ参照ピクチャに対して、１／８～２の範囲とすることがビットストリーム適合の要件である。スケーリング比は以下のように定義される。

【0237】

horizontal_scaling_ratio＝（（reference_pic_width_in_luma_samples＜＜１４）＋（pic_width_in_luma_samples／２））／pic_width_in_luma_samples
vertical_scaling_ratio＝（（reference_pic_height_in_luma_samples＜＜１４)＋（pic_height_in_luma_samples／２））／pic_height_in_luma_samples

【0238】

【表14】

【0239】

参照ピクチャスケーリングプロセス
ＣＶＳ内で解像度変更がある場合、ピクチャは、その参照ピクチャの１つ以上と異なるサイズを有し得る。この提案は、全ての動きベクトルを、それらの対応する参照ピクチャのグリッドの代わりに、現在のピクチャのグリッドに正規化する。これは、設計の一貫性を維持し、解像度変更を動きベクトル予測プロセスに対して透明性のあるものにする上で有益であると主張される。さもなければ、異なるサイズの参照ピクチャを指す隣接する動きベクトルは、スケーリングが異なることにより、空間的動きベクトル予測に直接用いることができない。

【0240】

解像度変更が起こると、動き補償予測を行う間に動きベクトル及び参照ブロックの双方をスケーリングする必要がある。スケーリング範囲は［１／８、２］に限定されている。すなわち、アップスケーリングは１：８に制限され、ダウンスケーリングは２：１に制限されている。なお、アップスケーリングとは、参照ピクチャが現在のピクチャよりも小さい場合を意味するのに対して、ダウンスケーリングとは、参照ピクチャが現在のピクチャより大きい場合を意味する。以下のセクションでは、スケーリングプロセスをより詳細に説明する。

【0241】

ルーマブロック
スケーリング係数及びそれらの固定点表現は以下のように定義される。

【0242】

【数6】

【0243】

【数7】

スケーリングプロセスには２つの部分がある。

【0244】

１．現在のブロックの左上隅のピクセルを参照ピクチャにマップする。

【0245】

２．現在のブロックの他のピクセルの参照位置を指定するために水平及び垂直のステップサイズを用いる。

【0246】

現在のブロックの左上隅のピクセルの座標が（ｘ、ｙ）の場合、１／１６ピクセルの単位で動きベクトル（ｍｖＸ、ｍｖＹ）によって指される参照ピクチャ内のサブペル位置（ｘ＾’、ｙ＾’）は以下のように指定される。

【0247】

参照ピクチャの水平位置は次のようになる。

【0248】

【数8】

【0249】

１０ビットだけを保持するためにｘ’がさらに縮小される。

【0250】

【数9】

【0251】

同様に、参照ピクチャの垂直位置は次のようになる。

【数10】

【0252】

ｙ’はさらに縮小される。

【0253】

【数11】

【0254】

この時点で、現在のブロックの左上隅のピクセルの参照位置は（ｘ＾’、ｙ＾’）にある。他の参照サブプル／ピクセル位置は、水平及び垂直ステップサイズで（ｘ＾’、ｙ＾’）に対して計算される。これらのステップサイズは、上記の水平及び垂直スケーリング係数から１／１０２４ピクセル単位の精度で以下のように導出される。

【0255】

【数12】

【0256】

【数13】

一例として、現在のブロック内のピクセルがｉ列であり、左上隅のピクセルからj列離れている場合、その対応する参照ピクセルの水平及び垂直座標は以下のように導出される。

【0257】

【数14】

【0258】

【数15】

【0259】

サブペル補間では、ｘ’_ｉ、ｙ’_ｊをフルペル部及び部分ペル部に分割する必要がある。

【0260】

－参照ブロックをアドレスするためのフルペル部は以下と等しい。

【0261】

【数16】

【0262】

【数17】

【0263】

－補間フィルタの選択に用いられ得る部分ペル部は以下と等しい。

【0264】

【数18】

【0265】

【数19】

【0266】

参照ピクチャ内のフルペル位置及び部分ペル位置が特定された場合、追加の変更なしに既存の動き補償を用いることができる。フルペル位置は、参照ピクチャから基準ブロックパッチを取得するために用いられ、部分ペル位置は、適切な補間フィルタを選択するために用いられる。

【0267】

クロマブロック
クロマフォーマットが４：２：０の場合、クロマ動きベクトルは１／３２ピクセル単位の精度を有する。クロマ動きベクトル及びクロマ参照ブロックのスケーリングプロセスは、クロマフォーマット関連の調整を除いて、ルーマブロックの場合とほぼ同じである。

【0268】

現在のクロマブロックの左上隅のピクセルの座標が（ｘｃ、ｙｃ）の場合、参照クロマピクチャの初期水平及び垂直位置は次のようになる。

【0269】

【数20】

【0270】

【数21】

【0271】

ここで、ｍｖＸ及びｍｖＹは元のルーマ動きベクトルであるが、今度は１／３２ピクセル単位の精度で検査すべきである。

【0272】

１／１０２４ピクセル単位の精度を維持するために、ｘｃ’及びｙｃ’がさらに縮小される。

【0273】

【数22】

【0274】

【数23】

【0275】

関連するルーマの方程式と比較して、上記の右側へのシフトは１ビット増加する。

【0276】

使用するステップサイズはルーマとの場合と同じである。左上隅のピクセルに対して（ｉ、ｊ）にあるクロマピクセルについて、その参照ピクセルの水平及び垂直座標は下記に導出される。

【0277】

【数24】

【0278】

【数25】

【0279】

サブペル補間では、ｘ_ｃ’_ｉ、ｙ_ｃ’_ｊもフルペル部及び部分ペル部に分割される。

【0280】

－参照ブロックをアドレスするためのフルペル部は以下と等しい。

【0281】

【数26】

【0282】

【数27】

【0283】

補間フィルタの選択に用いられる部分ペル部は以下と等しい。

【0284】

【数28】

【0285】

【数29】

【0286】

他の符号化ツールとの相互作用
一部の符号化ツールと参照ピクチャスケーリングとの相互作用に伴う複雑性及びメモリ帯域幅の増加により、ＶＶＣ仕様に以下の制約を加えることが推奨される。

【0287】

tile_group_temporal_mvp_enabled_flag＝１の場合、現在のピクチャ及びそのコロケーションされたピクチャは同じサイズを有するものとする。

【0288】

シーケンス内で解像度変更が許容される場合、デコーダの動きベクトル精密化はオフにすべきである。

【0289】

シーケンス内で解像度変更が許可される場合、sps_bdof_enabled_flag＝０とする。

【0290】

２．３ ＪＶＥＴ－Ｎ０４１５における符号化ツリーブロック（ＣＴＢ）ベースの適応ループフィルタ（ＡＬＦ)
スライスレベルの時間フィルタ
ＶＴＭ４では適応パラメータセット（ＡＰＳ）が採用された。各ＡＰＳは１セットのシグナリングＡＬＦフィルタを含み、最大で３２のＡＰＳがサポートされる。提案では、スライスレベルの時間フィルタがテストされた。タイルグループは、オーバーヘッドを減らすためにＡＰＳからのＡＬＦ情報を再利用できる。ＡＰＳは先入れ先出し（ＦＩＦＯ）バッファとして更新される。

【0291】

ＣＴＢベースのＡＬＦ
ルーマコンポーネントの場合、ＡＬＦがルーマＣＴＢに適用された場合、１６の固定フィルタセット、５つの時間フィルタセット又は１つの信号フィルタセットのうちの選択肢が示される。フィルタセットインデックスのみがシグナリングされる。１つのスライスに対して、新たな２５のフィルタセット１つだけをシグナリングできる。新たなセットがスライスにシグナリングされた場合、同じスライス内の全てのルーマＣＴＢはそのセットを共有する。固定フィルタセットは新たなスライスレベルフィルタセットを予測するために用いることができ、ルーマＣＴＢのフィルタセット候補として用いることができる。フィルタの数は合計で６４である。

【0292】

クロマコンポーネントの場合、ＡＬＦがクロマＣＴＢに適用された場合、新たなフィルタがスライスに対してシグナリングされた場合、ＣＴＢは新たなフィルタを用い、さもなくば、時間的スケーラビリティ制約を満たす最新の時間的クロマフィルタが適用される。

【0293】

スライスレベルの時間フィルタとして、ＡＰＳは先入れ先出し（ＦＩＦＯ）バッファとして更新される。

【0294】

２.４ 代替的な時間的動きベクトル予測（ＶＶＣにおけるサブブロックベースの時間的マージ候補としても知られる）
代替的な時間的動きベクトル予測（ＡＴＭＶＰ）法では、動きベクトル時間的動きベクトル予測（ＴＭＶＰ）を、現在のＣＵよりも小さいブロックから複数のセットの動き情報（動きベクトル及び参照インデックスを含む）を取り出すことにより修正されている。図１４に示すように、サブＣＵは正方形のＮ×Ｎブロックである（Ｎはデフォルトで８に設定されている）。

【0295】

ＡＴＭＶＰは、ＣＵ内のサブＣＵの動きベクトルを２段階で予測する。第１のステップは、いわゆる時間ベクトルを用いて参照ピクチャ内の対応するブロックを識別することである。この参照ピクチャは動きソースピクチャと呼ばれる。第２のステップは、現在のＣＵをサブＣＵに分割して、ＣＵのＡＴＭＶＰ動き予測の例を示す図１５に示すように、各サブＣＵに対応するブロックから、各サブＣＵの参照インデックスに加えて動きベクトルを得ることである。

【0296】

第１のステップでは、参照ピクチャ及び対応するブロックは、現在のＣＵの空間的隣接ブロックの動き情報によって決定される。隣接ブロックの繰り返しの走査プロセスを避けるために、現在のＣＵのマージ候補リスト内のブロックＡ０（左ブロック）からのマージ候補が用いられる。コロケーションされた参照ピクチャを参照するブロックＡ０からの第１の利用可能な動きベクトルは時間ベクトルとして設定される。このように、ＡＴＭＶＰでは、対応するブロックは、ＴＭＶＰに比べてより正確に識別され得る。対応するブロック（コロケーションされたブロックと呼ばれることもある）は、現在のＣＵに対して常に右下又は中心位置にある。

【0297】

第２のステップにおいて、サブＣＵの対応するブロックは、現在のＣＵの座標に時間ベクトルを加えることにより、動きソースピクチャ内の時間ベクトルによって識別される。各サブＣＵに対して、その対応するブロックの動き情報（中心サンプルをカバーする最小の動きグリッド）を用いてサブＣＵの動き情報が導出される。対応するＮ×Ｎブロックの動き情報が識別された後で、ＨＥＶＣのＴＭＶＰと同じ様に、現在のサブＣＵの動きベクトル及び参照インデックスに変換され、動きスケーリング及び他の手順が適用される。

【0298】

２．５ アフィン動き予測
ＨＥＶＣでは、並進運動モデル（translation motion model）しか動き補償予測（Motion Compensation Prediction，ＭＣＰ）のために適用されない。現実世界では、多くの種類の動き、例えば、ズームイン／アウト、回転、射影運動及び他の不規則な動きを有する可能性がある。ＶＶＣでは、簡素化されたアフィン変換動き補償予測が４パラメータアフィンモデル及び６パラメータアフィンモデルにより適用される。図１６ａ及び図１６ｂは簡素化された４パラメータアフィンモデル及び６パラメータアフィンモデルをそれぞれ示す。図１６ａ及び図１６ｂに示すように、ブロックのアフィン運動場は、４パラメータアフィンモデルについては２つの制御点動きベクトル（Control Point Motion Vectors，ＣＰＭＶ）及び６パラメータアフィンモデルについては３つのＣＰＭＶによって記述される。

【0299】

ブロックの動きベクトル場（Motion Vector Field、ＭＶＦ）は、式（１）の４パラメータアフィンモデル（ここで、４パラメータは、変数ａ、ｂ、ｅ及びｆとして定義されている）及び式（２）の６パラメータアフィンモデル（ここで、６パラメータは、ａ、ｂ、ｃ、ｄ、ｅ及びｆとして定義されている。）によりそれぞれ、次の式によって記述される。

【0300】

【数30】

【0301】

ここで、（ｍｖｈ０、ｍｖｈ０）は、左上隅の制御点の動きベクトルであり、（ｍｖｈ１、ｍｖｈ１）は、右上隅の制御点の動きベクトルであり、（ｍｖｈ２、ｍｖｈ２）は、左下隅の制御点の動きベクトルであり、これら３つの動きベクトルは全てが制御点動きベクトル（ＣＰＭＶ）と呼ばれ、（ｘ、ｙ）は、現在のブロック内の左上サンプルに対する代表点の座標を表し、（ｍｖｈ（ｘ、ｙ）、ｍｖｖ（ｘ、ｙ））は、（ｘ、ｙ）に位置しているサンプルについて導出された動きベクトルである。ＣＰ動きベクトルは、シグナリング（アフィンＡＭＶＰモードと同様）されるか又はオンザフライで導出（アフィンモードと同様）されてよい。ｗ及びｈは、現在のブロックの幅及び高さである。実際に、分割は、丸め演算付き右シフトによって実施される。ＶＴＭでは、代表点は、サブブロックの中心位置であるよう定義され、例えば、現在のブロック内の左上サンプルに対するサブブロックの左上隅の座標が（ｘｓ、ｙｓ）である場合に、代表点の座標は、（ｘｓ＋２、ｙｓ＋２）であるよう定義される。各サブブロック（すなわち、ＶＴＭでは４×４）について、代表点は、そのサブブロック全体の動きベクトルを導出するために利用される。

【0302】

動き補償予測をさらに簡素化するために、サブブロックベースのアフィン変換予測が適用される。各Ｍ×Ｎサブブロック（Ｍ及びＮは両方とも、現在のＶＶＣでは、４にセットされる。）の動きベクトルを導出するために、図１７に示される各サブブロックの中心サンプルの動きベクトルは、式（２５）及び（２６）に従って計算され、１／１６分数精度に丸められ得る。次いで、１／１６ペルのための動き補償補間フィルタが、導出された動きベクトルにより各サブブロックの予測を生成するために適用される。１／１６ペルのための補間フィルタがアフィンモードによって導入される。

【0303】

ＭＣＰの後、各サブブロックの高精度動きベクトルは丸められ、通常の動きベクトルと同じ精度としてセーブされる。

【0304】

２．５．１ アフィン予測のシグナリング
並進運動モデルと同様に、アフィンモデルによるサイド情報をシグナリングするための２つのモードもある。それらは、ＡＦＦＩＮＥ＿ＩＮＴＥＲモード及びＡＦＦＩＮＥ＿ＭＥＲＧＥモードである。

【0305】

２．５．２ ＡＦ＿ＩＮＴＥＲモード
幅及び高さの両方が８よりも大きいＣＵについては、ＡＦ＿ＩＮＴＥＲモードが適用され得る。ＣＵレベルでのアフィンフラグは、ＡＦ＿ＩＮＴＥＲモードが使用されるかどうかを示すためにビットストリームでシグナリングされる。

【0306】

このモードで、各参照ピクチャリスト（Ｌｉｓｔ０又はＬｉｓｔ１）について、アフィンＡＭＶＰ候補リストは、次の順序で３つのタイプのアフィン動き予測子により構成され、各候補は、現在のブロックの推定されたＣＰＭＶを含む。エンコーダ側で見つけられた最良のＣＰＭＶ（例えば、図１８ａ及び図１８ｂのｍｖ_０、ｍｖ_１、ｍｖ_２）と推定されたＣＰＭＶとの差がシグナリングされる。加えて、推定されたＣＰＭＶが導出されるアフィンＡＭＶＰ候補のインデックスがさらにシグナリングされる。

【0307】

１）遺伝的アフィン動き予測子
検査順序は、ＨＥＶＣ ＡＭＶＰリスト構成における空間ＭＶＰのそれと同様である。最初に、現在のブロックと同じ参照ピクチャを有し、アフィンコーディングされている｛Ａ１、Ａ０｝内の最初のブロックから、左側の遺伝的アフィン動き予測子が導出される。第２に、現在のブロックと同じ参照ピクチャを有し、アフィンコーディングされている｛Ｂ１、Ｂ０、Ｂ２｝内の最初のブロックから、上側の遺伝的アフィン動き予測子が導出される。５つのブロックＡ１、Ａ０、Ｂ１、Ｂ０、Ｂ２は図１９に表されている。

【0308】

隣接するブロックがアフィンモードでコーディングされていると分かると、隣接するブロックをカバーするコーディングユニットのＣＰＭＶは、現在のブロックのＣＰＭＶの予測子を導出するために使用される。例えば、Ａ１が非アフィンモードでコーディングされ、Ａ０が４パラメータアフィンモードでコーディングされる場合に、左側の遺伝的アフィンＭＶ予測子はＡ０から導出されることになる。この場合に、図１８ｂで左上ＣＰＭＶについてはＭＶ_０ ^Ｎ及び右上ＣＰＭＶについてはＭＶ_１ ^Ｎによって表されている、Ａ０をカバーするＣＵのＣＰＭＶは、現在のブロックの左上位置（座標（ｘ０、ｙ０）を有する）、右上位置（座標（ｘ１、ｙ１）を有する）及び右下位置（座標（ｘ２、ｙ２）を有する）についてＭＶ_０ ^Ｃ、ＭＶ_１ ^Ｃ、ＭＶ_２ ^Ｃによって表される現在のブロックの推定されたＣＰＭＶを導出するために利用される。

【0309】

２）構成されたアフィン動き予測子
構成されたアフィン動き予測子は、同じ参照ピクチャを有している、図２０に示されるような隣接するインターコーディングされたブロックから導出される制御点動きベクトル（ＣＰＭＶ）から成る。現在のアフィン運動モデルが４パラメータアフィンである場合に、ＣＰＭＶの数は２であり、そうではなく、現在のアフィン運動モデルが６パラメータアフィンである場合に、ＣＰＭＶの数は３である。左上ＣＰＭＶ
〔外１〕

（以降、バーｍｖ_０）は、現在のブロックと同じ参照ピクチャを有している、インターコーディングされているグループ｛Ａ、Ｂ、Ｃ｝内の最初のブロックでのＭＶによって、導出される。右上ＣＰＭＶ
〔外２〕

（以降、バーｍｖ_１）は、現在のブロックと同じ参照ピクチャを有している、インターコーディングされているグループ｛Ｄ、Ｅ｝内の最初のブロックでのＭＶによって、導出される。左下ＣＰＭＶ
〔外３〕

（以降、バーｍｖ_２）は、現在のブロックと同じ参照ピクチャを有している、インターコーディングされているグループ｛Ｆ、Ｇ｝内の最初のブロックでのＭＶによって、導出される。

【0310】

－現在のアフィン運動モデルが４パラメータアフィンである場合に、構成されたアフィン動き予測子は、バーｍｖ_０及びバーｍｖ_１の両方が求められる、つまり、バーｍｖ_０及びバーｍｖ_１が現在のブロックの左上位置（座標（ｘ０、ｙ０）を有する）及び右上位置（座標（ｘ１、ｙ１）を有する）についての推定されたＣＰＭＶとして使用される場合にのみ、候補リストに挿入される。

【0311】

－現在のアフィン運動モデルが６パラメータアフィンである場合に、構成されたアフィン動き予測子は、バーｍｖ_０、バーｍｖ_１、及びバーｍｖ_２が全て求められる、つまり、バーｍｖ_０、バーｍｖ_１、及びバーｍｖ_２が現在のブロックの左上位置（座標（ｘ０、ｙ０）を有する）、右上位置（座標（ｘ１、ｙ１）を有する）及び右下位置（座標（ｘ２、ｙ２）を有する）についての推定されたＣＰＭＶとして使用される場合にのみ、候補リストに挿入される。

【0312】

構成されたアフィン動き予測子を候補リストに挿入する場合に、プルーニングプロセスは適用されない。

【0313】

３）通常のＡＭＶＰ動き予測子
以下は、アフィン動き予測子の数が最大値に達するまで適用される。

【0314】

ｉ．利用可能である場合に全てのＣＰＭＶをバーｍｖ_２に等しくセットすることによってアフィン動き予測子を導出する。

【0315】

ｉｉ．利用可能である場合に全てのＣＰＭＶをバーｍｖ_１に等しくセットすることによってアフィン動き予測子を導出する。

【0316】

ｉｉｉ．利用可能である場合に全てのＣＰＭＶをバーｍｖ_０に等しくセットすることによってアフィン動き予測子を導出する。

【0317】

ｉｖ．利用可能である場合に全てのＣＰＭＶをＨＥＶＣ ＴＭＶＰに等しくセットすることによってアフィン動き予測子を導出する。

【0318】

ｖ．全てのＣＰＭＶをゼロＭＶにセットすることによってアフィン動き予測子を導出する。

【0319】

留意されるべきは、
〔外４〕

（以降、バーｍｖ_ｉ）は、構成されたアフィン運動では既に導出されている点である。

【0320】

ＡＦ＿ＩＮＴＥＲモードでは、４又は６パラメータアフィンモードが使用される場合に、２又は３つの制御点が必要とされるので、２つ又は３つのＭＶＤが、図１８ａ及び図１８ｂに示されるように、それらの制御点に対してコーディングされる必要がある。ＪＶＥＴ－Ｋ０３３７では、ＭＶを次のように導出することが提案されており、すなわち、ｍｖｄ_０からｍｖｄ_１及びｍｖｄ_２が予測される。

【0321】

【数31】

【0322】

ここで、バーｍｖ_ｉ、ｍｖｄ_ｉ及びｍｖ_ｉは、図１８（ｂ）に示されるように、それぞれ、左上ピクセル（ｉ＝０）、右上ピクセル（ｉ＝１）、又は左下ピクセル（ｉ＝２）の予測された動きベクトル、動きベクトル差分及び動きベクトルである。なお、２つの動きベクトル（例えば、ｍｖＡ（ｘＡ、ｙＡ）及びｍｖＢ（ｘＢ、ｙＢ））の追加は、別々に２つの成分の和に等しい。すなわち、ｎｅｗＭＶ＝ｍｖＡ＋ｍｖＢであり、ｎｅｗＭＶの２つの成分はそれぞれ、（ｘＡ＋ｘＢ）及び（ｙＡ＋ｙＢ）にセットされる。

【0323】

２．５．２．１ ＡＦ＿ＭＥＲＧＥモード
ＣＵがＡＦ＿ＭＥＲＧＥモードで適用される場合に、それは、有効な隣接する再構成されたブロックからアフィンモードによりコーディングされた最初のブロックを得る。図２１はＡＦ＿ＭＥＲＧＥの候補を示す。候補ブロックの選択順序は、図２１ａに示されるように、左から、上、右上、左下、左上へである（順にＡ、Ｂ、Ｃ、Ｄ、Ｅによって表される）。例えば、隣接する左下ブロックが、図２１ｂでＡ０によって表されるように、アフィンモードでコーディングされる場合に、ブロックＡを含む隣接するＣＵ／ＰＵの左上隅、右上隅、及び左下隅の制御点（ＣＰ）動きベクトルｍｖ_０ ^Ｎ、ｍｖ_１ ^Ｎ及びｍｖ_２ ^Ｎがフェッチされる。そして、現在のＣＵ／ＰＵ上の左上隅／右上／左下の動きベクトルｍｖ_０ ^Ｃ、ｍｖ_１ ^Ｃ及びｍｖ_２ ^Ｃ（６パラメータアフィンモデルのためにのみ使用される）は、ｍｖ_０ ^Ｎ、ｍｖ_１ ^Ｎ及びｍｖ_２ ^Ｎに基づいて計算される。なお、ＶＴＭ－２．０では、現在のブロックがアフィンコーディングされている場合に、左上隅に位置するサブブロック（例えば、ＶＴＭでは、４×４ブロック）は、ｍｖ０を保存し、右上隅にあるサブブロックは、ｍｖ１を保存する。現在のブロックが６パラメータアフィンモデルでコーディングされる場合には、左下隅にあるサブブロックは、ｍｖ２を保存し、そうでない（４パラメータアフィンモデルによる）場合には、ＬＢはｍｖ２’を保存する。他のサブブロックは、ＭＣのために使用されるＭＶを保存する。

【0324】

現在のＣＵのＣＰＭＶであるｍｖ０Ｃ、ｍｖ１Ｃ及びｍｖ２Ｃが、簡素化されたアフィン運動モデルである式２５及び２６に従って導出された後、現在のＣＵのＭＶＦが生成される。現在のＣＵがＡＦ＿ＭＥＲＧＥモードでコーディングされているかどうかを識別するために、アフィンモードでコーディングされている少なくとも１つの隣接ブロックがある場合に、アフィンフラグがビットストリームでシグナリングされる。

【0325】

ＪＶＥＴ－Ｌ０１４２及びＪＶＥＴ－Ｌ０６３２では、アフィンマージ候補リストは、次のステップで構成される。

【0326】

１）遺伝的アフィン候補の挿入
遺伝によるアフィン候補（inherited affine candidate）とは、候補が、その有効な隣接するアフィンコーディングされたブロックのアフィン運動モデルから導出されることを意味する。最大２つの遺伝的アフィン候補が、隣接ブロックのアフィン運動モデルから導出され、候補リストに挿入される。左側予測子については、走査順序は｛Ａ０、Ａ１｝であり、上側予測子については、走査順序は｛Ｂ０、Ｂ１、Ｂ２｝である。

【0327】

２）構成されたアフィン候補の挿入
アフィンマージ候補リスト内の候補の数がＭａｘＮｕｍＡｆｆｉｎｅＣａｎｄ（例えば、５つ）に満たない場合には、構成されたアフィン候補（constructed affine candidates）が候補リストに挿入される。構成されたアフィン候補とは、候補が、各制御点の隣接動き情報を結合することによって構成されることを意味する。

【0328】

ａ）制御点の動き情報は、最初に、図２２に示されている指定された空間近傍及び時間近傍から導出される。ＣＰｋ（ｋ＝１、２、３、４）は、ｋ番目の制御点を表す。Ａ０、Ａ１、Ａ２、Ｂ０、Ｂ１、Ｂ２及びＢ３は、ＣＰｋ（ｋ＝１、２、３）を予測するための空間的位置である。Ｔは、ＣＰ４を予測するための時間的位置である。

【0329】

ＣＰ１、ＣＰ２、ＣＰ３及びＣＰ４の座標は、それぞれ（０、０）、（Ｗ、０）、（Ｈ、０）及び（Ｗ、Ｈ）であり、ここで、Ｗ及びＨは、現在のブロックの幅及び高さである。

【0330】

各制御点の動き情報は、次の優先順序に従って取得される：
－ＣＰ１については、チェック優先度はＢ２→Ｂ３→Ａ２である。Ｂ２は、それが利用可能である場合に使用される。そうではない場合に、Ｂ３が利用可能であるならば、Ｂ３が使用される。Ｂ２及びＢ３の両方が利用不可能である場合には、Ａ２が使用される。３つ全ての候補が利用不可能である場合には、ＣＰ１の動き情報は取得不可能である。

【0331】

－ＣＰ２については、チェック優先度はＢ１→Ｂ０である。

【0332】

－ＣＰ３については、チェック優先度はＡ１→Ａ０である。

【0333】

－ＣＰ４については、Ｔが使用される。

【0334】

ｂ）第２に、制御点の組み合わせが、アフィンマージ候補を構成するために使用される。

【0335】

－３つの制御点の動き情報が、６パラメータアフィン候補を構成するために必要とされる。３つの制御点は、次の４つの組み合わせ（｛ＣＰ１、ＣＰ２、ＣＰ４｝、｛ＣＰ１、ＣＰ２、ＣＰ３｝、｛ＣＰ２、ＣＰ３、ＣＰ４｝、｛ＣＰ１、ＣＰ３、ＣＰ４｝）のうちの１つから選択され得る。組み合わせ｛ＣＰ１、ＣＰ２、ＣＰ３｝、｛ＣＰ２、ＣＰ３、ＣＰ４｝、｛ＣＰ１、ＣＰ３、ＣＰ４｝は、左上、右上、及び左下制御点によって表される６パラメータ運動モデルへ変換されることになる。

【0336】

－２つの制御点の動きベクトルが、４パラメータアフィン候補を構成するために必要とされる。２つの制御点は、次の２つの組み合わせ（｛ＣＰ１、ＣＰ２｝、｛ＣＰ１、ＣＰ３｝）のうちの１つから選択され得る。２つの組み合わせは、左上及び右上制御点によって表される４パラメータ運動モデルへ変換されることになる。

【0337】

－構成されたアフィン候補の組み合わせは、次の順序：｛ＣＰ１、ＣＰ２、ＣＰ３｝、｛ＣＰ１、ＣＰ２、ＣＰ４｝、｛ＣＰ１、ＣＰ３、ＣＰ４｝、｛ＣＰ２、ＣＰ３、ＣＰ４｝、｛ＣＰ１、ＣＰ２｝、｛ＣＰ１、ＣＰ３｝として候補リストに挿入される。

【0338】

ｉ．組み合わせごとに、各ＣＰのためのリストＸの参照インデックスはチェックされ、それらが全て同じである場合に、この組み合わせはリストＸの有効なＣＰＭＶを有している。組み合わせがリスト０及びリスト１の両方の有効なＣＰＭＶを有してない場合には、この組み合わせは無効とマークされる。そうでない場合には、それは有効であり、ＣＰＭＶはサブブロックマージリストに置かれる。

【0339】

３）ゼロアフィン動きベクトル候補によるパディング
アフィンマージ候補リスト内の候補の数が５よりも少ない場合に、リストがフルになるまでゼロ参照インデックスのゼロ動きベクトルが候補リストに挿入される。

【0340】

より具体的には、サブブロックマージ候補リストについて、４パラメータマージ候補は、ＭＶが（０、０）にセットされ、予測方向がリスト０からの一方向予測（Ｐスライスの場合）及び双方向予測（Ｂスライスの場合）にセットされる。

【0341】

既存の実装の欠点
ＶＶＣに適用する場合、ＡＲＣは以下の課題を有し得る。

【0342】

ＡＬＦ、ルーママッピングクロマスケーリング（ＬＭＣＳ）、デコーダ側動きベクトルリファインメント（ＤＭＶＲ）、双方向光学フロー（ＢＤＯＦ）、アフィン予測、三角予測モード（ＴＰＭ）、対称動きベクトル差（ＳＭＶＤ）、マージ動きベクトル差（ＭＭＶＤ）、インターイントラ予測（ＶＶＣでは併用インターピクチャマージ及びイントラピクチャマージ（ＣＩＩＰ）としても知られている）、局所化照明圧縮（ＬＩＣ）及び履歴ベースの動きベクトル予測（ＨＭＶＰ）等の符号化ツールをＶＶＣに適用されるかは不明である。

【0343】

適応的解像度変換でツールを符号化するための例示の方法
開示の技術の実施形態は既存の実施の欠点を克服する。以下に示す開示の技術の例は、開示の技術の理解を促進するために議論され、開示の技術を制限する方法で解釈されるべきである。別段明示がない限り、これらの例で説明する様々な特徴は組み合わせることができる。

【0344】

以下の議論では、ＳａｔＳｈｉｆｔ（ｘ、ｎ）は以下のように定義される。

【0345】

【数32】

【0346】

Ｓｈｉｆｔ（ｘ、ｎ）は、Ｓｈｉｆｔ（ｘ、ｎ）＝（ｘ＋ｏｆｆｓｅｔ０）＞＞ｎと定義される。

【0347】

１つの例では、ｏｆｆｓｅｔ０及び／又はｏｆｆｓｅｔ１は、（１＜＜ｎ）＞＞１又は（１＜＜（ｎ－１））に設定される。別の例では、ｏｆｆｓｅｔ０及び／又はｏｆｆｓｅｔ１は０に設定される。

【0348】

別の例では、ｏｆｆｓｅｔ０＝ｏｆｆｓｅｔ１＝（（１＜＜ｎ）＞＞１）－１又は（（１＜＜（ｎ－１）））－１である。

【0349】

Ｃｌｉｐ３（ｍｉｎ、ｍａｘ、ｘ）は以下のように定義される。

【0350】

【数33】

【0351】

Ｆｌｏｏｒ（ｘ）はｘ以下の最も大きい整数として定義される。

【0352】

Ｃｅｉｌ（ｘ）はｘ以上の最も小さい整数である。

【0353】

Ｌｏｇ２（ｘ）はｘの基数-２の対数として定義される。

【0354】

開示の技術の実施の一部の側面を以下に列挙する。

【0355】

１． ＭＭＶＤ／ＳＭＶＤにおけるＭＶオフセット及び／又はコーダ側導出プロセスにおける精密化された動きベクトルの導出は、現在のブロックに関連する参照ピクチャの解像度及び現在のピクチャの解像度に依存し得る。
ａ．例えば、第２の参照ピクチャを参照する第２のＭＶオフセットは、第１の参照ピクチャを参照する第１のＭＶオフセットからスケーリングされ得る。スケーリング係数は、第１及び第２の参照ピクチャの解像度に依存し得る。

【0356】

２． 動き候補リスト構築プロセスは、空間的／時間的／履歴的な動き候補に関連する参照ピクチャ解像度に従って構築され得る。
ａ．１つの例では、解像度がより高い参照ピクチャを参照するマージ候補は、解像度がより低い参照ピクチャを参照するマージ候補よりも高い優先度を有し得る。議論では、Ｗ０＜Ｗ１及びＨ０＜Ｈ１の場合、解像度Ｗ０＊Ｈ０は解像度Ｗ１＊Ｈ１より低い。
ｂ．例えば、マージ候補リストにおいて、解像度がより高い参照ピクチャを参照するマージ候補は解像度がより低い参照ピクチャを参照するマージ候補の前に置かれ得る。
ｃ．例えば、現在のピクチャの解像度よりも低い解像度を有する参照ピクチャを参照する動きベクトルはマージ候補リストに入れることはできない。
ｄ．１つの例では、履歴バッファ（参照テーブル）を更新するかどうか及び／又はどのように更新するかは、復号動き候補に関連する参照ピクチャ解像度に依存し得る。
ｉ．１つの例では、復号動き候補に関連する１つの参照ピクチャが異なる解像度を有する場合、そのような動き候補は履歴バッファを更新するために許可されない。

【0357】

３． ピクチャは、対応する寸法に関連するＡＬＦパラメータでフィルタリングされるべきことが提案される。
ａ．一例では、ＡＰＳのようなビデオユニットでシグナリングするＡＬＦパラメータは、１つまたは複数の画像寸法に関連付けることができる。
ｂ．一例では、ＡＰＳシグナリングＡＬＦパラメータのようなビデオユニットは、１つまたは複数の画像寸法に関連付けることができる。
ｃ．例えば、画像は、同じ寸法に関連付けられたAPSのようなビデオユニットで信号化されたALFパラメータのみを適用することができる。
ｄ．ＰＰＳの解像度/インデックス/解像度の表示は、ＡＬＦ ＡＰＳでシグナリングすることができる。
ｅ．ＡＬＦパラメータは、同じ解像度を持つ画像に対して使用されるものからのみ継承/予測されることがあることが制限される。

【0358】

４． 第１の対応する寸法に関連するＡＬＦパラメータは、第２の対応する寸法に関連するＡＬＦパラメータを継承し得るか又はＡＬＦパラメータから予測され得ることが提案される。
ａ．１つの例では、第１の対応する寸法は、第２の対応する寸法と同じでなければならない。
ｂ．１つの例では、第１の対応する寸法は、第２の対応する寸法と異なり得る。

【0359】

５． ピクチャ内のサンプルは、対応する寸法に関連するＬＭＣＳパラメータで再成形されるべきであることが提案される。
ａ．１つの例では、ＡＰＳ等のビデオユニットでシグナリングされるＬＭＣＳパラメータは、１つ以上のピクチャ寸法に関連し得る。
ｂ．１つの例では、ＬＭＣＳパラメータをシグナリングするＡＰＳ等のビデオユニットは、１つ以上のピクチャ寸法に関連し得る。
ｃ．例えば、ピクチャは、同じ寸法に関連するＡＰＳ等のビデオユニットでシグナリングされるＬＭＣＳパラメータのみを適用し得る。
ｄ．ＰＰＳの解像度／インデックス／解像度の表示は、ＬＭＣＳ ＡＰＳでシグナリングされ得る。
ｅ．ＬＭＣＳパラメータは、同じ解像度を有するピクチャに対して用いられるものからのみ継承／予測され得ると制限される。

【0360】

６． 第１の対応する寸法に関連するＬＭＣＳパラメータは、第２の対応する寸法に関連するＬＭＣＳパラメータを継承し得るか又は予測され得ることが提案される。
ａ．１つの例では、第１の対応する寸法は、第２の対応する寸法と同じでなければならない。
ｂ．１つの例では、第１の対応する寸法は、第２の対応する寸法と異なり得る。

【0361】

７． ＴＰＭ（三角予測モード）／ＧＥＯ（幾何学的分割を用いたインター予測）又は１つのブロックを２つ又は複数のサブパーティションに分割し得る他の符号化ツールを有効にするかどうか及び／又はどのように有効にするかは、２つ又は複数のサブパーティションの関連する参照ピクチャ情報によって決まる。
ａ．１つの例では、それは、２つの参照ピクチャのうちの１つの解像度及び現在のピクチャの解像度に依存し得る。
ｉ．１つの例では、２つの参照ピクチャのうちの少なくとも１つが現在のピクチャと比較して異なる解像度に関連する場合、そのような符号化ツールは無効にされる。
ｂ．１つの例では、それは、２つの参照ピクチャの解像度が同じかどうかに依存し得る。
ｉ．１つの例では、２つの参照ピクチャが異なる解像度と関連する場合、そのような符号化ツールは無効にされ得る。
ｉｉ．１つの例では、２つの参照ピクチャの両方が現在のピクチャと比較して異なる解像度に関連する場合、そのような符号化ツールは無効にされる。
ｉｉｉ．あるいは、２つの参照ピクチャの両方が現在のピクチャと比較して異なる解像度に関連するが、２つの参照ピクチャが同じ解像度の場合、そのような符号化ツールは依然として無効にされ得る。
ｉｖ．あるいは、参照ピクチャのうちの少なくとも１つが現在のピクチャとは異なる解像度を有し、参照ピクチャが異なる解像度を有する場合、符号化ツールＸは無効にされ得る。
ｃ．あるいは、さらに、２つの参照ピクチャが同じ参照ピクチャであるかどうかに依存し得る。
ｄ．あるいは、さらに、２つの参照ピクチャが同じ参照リストにあるかどうかに依存し得る。
ｅ．あるいは、そのような符号化ツールは、ＲＰＲ（参照ピクチャの再サンプリングがスライス／ピクチャヘッダ／シーケンスパラメータセットで有効)の場合、常に無効にされ得る。

【0362】

８． ブロックが現在のピクチャとは異なる寸法を有する少なくとも１つの参照ピクチャを参照する場合、該ブロックに対して符号化ツールＸが無効にされ得ることが提案される。
ａ．１つの例では、符号化ツールＸに関する情報はシグナリングされなくてもよい。
ｂ．１つの例では、そのようなブロックの動き情報はＨＭＶＰテーブルに挿入されなくてもよい。
ｃ．あるいは、ブロックに符号化ツールＸが適用される場合、ブロックは、現在のピクチャとは異なる寸法の参照ピクチャを参照することができない。
ｉ．１つの例では、現在のピクチャとは異なる寸法を有する参照ピクチャを参照するマージ候補はスキップされ得るか又はマージ候補リストに入れられない。
ｉｉ．１つの例では、現在のピクチャとは異なる寸法の参照ピクチャに対応する参照インデックスはスキップされ得るか又はシグナリングされることが許可されない。
ｄ．あるいは、符号化ツールＸは、現在のピクチャの解像度及び参照ピクチャの解像度に従って２つの参照ブロック又はピクチャをスケーリングした後で適用され得る。
ｅ．あるいは、符号化ツールＸは、現在のピクチャの解像度及び参照ピクチャの解像度に従って２つのＭＶ又はＭＶＤをスケーリングした後で適用され得る。
ｆ．１つの例では、ブロック（例えば、異なる参照ピクチャ又は異なるＭＶを有する同じ参照ピクチャリストからの複数仮説を有するブロック又は双方向符号化ブロック又は異なる参照ピクチャリストからの複数仮説を有するブロック）について、符号化ツールＸを無効にするか又は有効にするかは、参照ピクチャリスト及び／又は現在の参照ピクチャに関連する参照ピクチャの解像度に依存し得る。
ｉ．１つの例では、符号化ツールＸは一方の参照ピクチャリストについて無効にされ得るが、他方の参照ピクチャリストについては有効であり得る。
ｉｉ．１つの例では、符号化ツールＸは一方の参照ピクチャについては無効にされ得るが、他方の参照ピクチャについては有効であり得る。ここで、２つの参照ピクチャは異なる参照ピクチャリスト又は同じ参照ピクチャリストからのものであり得る。
ｉｉｉ．１つの例では、各参照ピクチャリストＬについて、符号化ツールの有効化／無効化は、リストＬとは異なる他の参照ピクチャリスト内の参照ピクチャに関係なく決定される。
１．１つの例では、リストＬの参照ピクチャ及び現在のピクチャによって決定され得る。
２．１つの例では、リストＬの関連する参照ピクチャが現在のピクチャと異なる場合、ツールはリストＬについて無効にされ得る。
ｉｖ．あるいは、符号化ツールの有効化／無効化は、全ての参照ピクチャ及び／又は現在のピクチャの解像度によって決定される。
１．１つの例では、参照ピクチャのうちの少なくとも１つが現在のピクチャと異なる解像度を有する場合、符号化ツールＸは無効にされ得る。
２．１つの例では、参照ピクチャのうちの少なくとも１つが現在のピクチャと異なる解像度を有するが、参照ピクチャ同士が同じ解像度を有する場合、符号化ツールＸは依然有効にされ得る。
３．１つの例では、参照ピクチャのうちの少なくとも１つが現在のピクチャと異なる解像度を有し、参照ピクチャ同士が異なる解像度を有する場合、符号化ツールＸは無効にされ得る。
ｇ．符号化ツールＸは以下のいずれかであり得る。
ｉｉｉ．ＤＭＶＲ
ｉｖ．ＢＤＯＦ
ｖ．アフィン予測
ｖｉ．三角形予測モード
ｖｉｉ．ＳＭＶＤ
ｖｉｉｉ．ＭＭＶＤ
ｉｘ．ＶＶＣにおけるインターイントラ予測
ｘ．ＬＩＣ
ｘｉ．ＨＭＶＰ
ｘｉｉ．複数変換セット（ＭＴＳ）
ｘｉｉｉ．サブブロック変換（ＳＢＴ）
ｘｉｖ．ＰＲＯＦ及び／又は他の復号側の動き/予測の精緻化方法
ｘｖ．ＬＦＮＳＴ（低周波非二乗変換）
ｘｖｉ．フィルタリング方法（例：デブロッキングフィルタ／ＳＡＯ/ＡＬＦ）
ｘｖｉｉ．ＧＥＯ/ＴＰＭ/クロスコンポーネントＡＬＦ

【0363】

９． ピクチャの参照ピクチャリストに含まれる異なる解像度はＫ個以下である。
ａ．１つの例では、Ｋ＝２である。

【0364】

１０． Ｎ個の連続する（復号順序又は表示順序）ピクチャに対して、Ｋ個以下の異なる解像度しか許容されない。
ａ．１つの例では、Ｎ＝３、Ｋ＝３である。
ｂ．１つの例では、Ｎ＝１０、Ｋ＝３である。
ｃ．１つの例では、ＧＯＰにおいてＫ個以下の異なる解像度しか許容されない。
ｄ．１つの例では、同じ特定の時間的レイヤＩＤ（ｔｉｄと表記される）を有する２つのピクチャの間で、Ｋ個以下の異なる解像度しか許容されない。
ｉ．例えば、Ｋ＝３、ｔｉｄ＝０である。

【0365】

１１． 解像度変更は、イントラピクチャに対してしか許容されない。

【0366】

１２． １つのブロックの１つ又は２つの参照ピクチャが現在のピクチャとは異なる解像度を有する場合、復号化プロセスにおいて双方向予測は単方向予測に変換され得る。
ａ．１つの例では、現在のピクチャと異なる解像度を有する対応する参照ピクチャを有するリストＸからの予測が破棄され得る。

【0367】

１３． 異なる解像度の参照ピクチャからのインター予測を有効又は無効にするかどうかは、動きベクトル精度及び／又は解像度比に依存し得る。
ａ．１つの例では、解像度比に従ってスケーリングされた動きベクトルが整数位置を指す場合、インター予測が依然として適用され得る。
ｂ．１つの例では、解像度比に従ってスケーリングされた動きベクトルが、ＡＲＣを伴わない場合に許容されるサブペル位置（例えば、１／４ペル）を指す場合、インター予測が依然として適用され得る。
ｃ．あるいは、両方の参照ピクチャが現在のピクチャとは異なる解像度を持つ場合、双方向予測が許可されないことがある。
ｄ．あるいは、一方の参照ピクチャが現在のピクチャと異なる解像度を有し、他方が同じ解像度を有する場合に、双方向予測が有効にされ得る。
ｅ．あるいは、参照ピクチャが現在のピクチャとは異なる解像度を有し、ブロック寸法が一定の条件を満たす場合、該ブロックに対して単方向予測が禁止され得る。

【0368】

１４． 符号化ツールＸが無効であるかどうかを示す第１のフラグ（例えば、pic_disable_X_flag）は、ピクチャヘッダでシグナリングされ得る。
ａ．スライス／タイル／ブリック／サブピクチャ／ピクチャよりも小さい他のビデオユニットに対する符号化ツールを有効にするかどうかは、ピクチャヘッダ内のこのフラグ及び／又はスライスタイプによって制御され得る。
ｂ．１つの例では、第１のフラグが真の場合、符号化ツールＸは無効にされる。
ｉ．あるいは、第１のフラグが偽の場合、符号化ツールＸが有効にされる。
ｉｉ．１つの例では、ピクチャ内の全てのサンプルに対してそれが有効／無効にされる。
ｃ．１つの例では、第１のフラグのシグナリングは、ＳＰＳ／ＶＰＳ／ＤＰＳ／ＰＰＳにおけるシンタックス要素又は複数のシンタックス要素に依存し得る。
ｉ．１つの例では、フラグのシグナリングは、ＳＰＳにおける符号化ツールＸの有効フラグに依存し得る。
ｉｉ．あるいは、さらに、ピクチャヘッダ内の第１のフラグの存在を示す第２のフラグ（例えば、sps_X_slice_present_flag）がＳＰＳにおいてシグナリングされ得る。
１）あるいは、さらに、符号化ツールＸがシーケンスに対して有効である場合（例えば、sps_X_enabled_flagが真である場合）、第２のフラグは条件付きでシグナリングされ得る。
２）あるいは、さらに、第２のフラグのみが第１のフラグが存在することを示し、第１のフラグはピクチャヘッダにおいてシグナリングされ得る。
ｄ．１つの例では、第１及び／又は第２のフラグは１ビットで符号化される。
ｅ．符号化ツールＸは以下のようになり得る。
ｉ．１つの例では、符号化ツールＸはＰＲＯＦである。
ｉｉ．１つの例では、符号化ツールＸはＤＭＶＲである。
ｉｉｉ．１つの例では、符号化ツールＸはＢＤＯＦである
ｉｖ．１つの例では、符号化ツールＸはクロスコンポーネントＡＬＦである。
ｖ．１つの例では、符号化ツールＸはＧＥＯである。
ｖｉ．１つの例では、符号化ツールＸはＴＰＭである。
ｖｉｉ．１つの例では、符号化ツールＸはＭＴＳである。

【0369】

１５． ブロックが、現在のピクチャと異なる寸法を有する参照ピクチャを参照できるかどうかは、ブロックの幅（ＷＢ）及び／又は高さ（ＨＢ）及び／又はブロック予測モード（すなわち、双方向予測又は短方向予測）に依存し得る。
ａ．１つの例では、ブロックは、ＷＢ＞＝Ｔ１及びＨＢ＞＝Ｔ２の場合、例えば、Ｔ１＝Ｔ２＝８の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｂ．１つの例では、ブロックは、ＷＢ＊ＨＢ＞＝Ｔの場合、例えば、Ｔ１＝６４の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｃ．１つの例では、ブロックは、Ｍｉｎ（ＷＢ、ＨＢ）＞＝Ｔの場合、例えば、Ｔ＝８の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｄ．１つの例では、ブロックは、Ｍａｘ（ＷＢ、ＨＢ）＞＝Ｔの場合、例えば、Ｔ＝８の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｅ．１つの例では、ブロックは、ＷＢ＜＝Ｔ１及びＨＢ＜＝Ｔ２の場合、例えば、Ｔ１＝Ｔ２＝６２の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｆ．１つの例では、ブロックは、ＷＢ＊ＨＢ＜＝Ｔの場合、例えば、Ｔ１＝４０９６の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｇ．１つの例では、ブロックは、Ｍｉｎ（ＷＢ、ＨＢ）＜＝Ｔの場合、例えば、Ｔ＝６４の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｈ．１つの例では、ブロックは、Ｍａｘ（ＷＢ、ＨＢ）＜＝Ｔの場合、例えば、Ｔ＝６４の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｉ．あるいは、ブロックは、ＷＢ＜＝Ｔ１及び／又はＨＢ＜＝Ｔ２の場合、例えば、Ｔ１＝Ｔ２＝８の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照することが禁止される。
ｊ．あるいは、ブロックは、ＷＢ＜＝Ｔ１及び／又はＨＢ＜＝Ｔ２の場合、例えば、Ｔ１＝Ｔ２＝８の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照することが禁止される。

【0370】

図２３は、ビデオ処理のための例示の方法のフローチャートを示す。図２３を参照して、方法２３００は、ステップ２３１０で、現在のビデオブロックと現在のビデオブロックのビットストリーム表現との間での変換の間に、現在のビデオブロックに関連する参照ピクチャの解像度及び現在のピクチャの解像度に基づいて動きベクトルオフセットを導出することを含む。方法２３００は、ステップ２３２０で、動きベクトルオフセットを用いて変換を行うことをさらに含む。

【0371】

一部の実施では、動きベクトルオフセットを導出することは、第１の参照ピクチャを参照する第１の動きベクトルオフセットを導出することと、第１の動きベクトルオフセットに基づいて、第２の参照ピクチャを参照する第２の動きベクトルオフセットを導出するステップとを含む。一部の実施では、本方法は、現在のビデオブロックに対して、空間的、時間的又は履歴的動き候補に関連する参照ピクチャ解像度に基づく動き候補リスト構築プロセスを行うことをさらに含む。一部の実施では、ルックアップテーブルを更新するかどうか又はどのように更新するかは、復号動き候補に関連する参照ピクチャ解像度によって決まる。一部の実施では、本方法は、現在のピクチャに対して、対応する寸法に関連する適応ループフィルタ（ＡＬＦ）パラメータを用いてフィルタリング動作を行うことをさらに含む。一部の実施では、ＡＬＦパラメータは、第１の対応する寸法に関連する第１のＡＬＦパラメータと、第２の対応する寸法に関連する第２のＡＬＦパラメータとを含み、第２のＡＬＦパラメータは、第１のＡＬＦパラメータから継承されるか又は予測される。

【0372】

一部の実施では、本方法は、対応する寸法に関連するＬＭＣＳ（ルーママッピングクロマスケーリング）パラメータを用いて、現在のピクチャ内のサンプルを再成形することをさらに含む。一部の実施では、ＬＭＣＳパラメータは、第１の対応する寸法に関連する第１のＬＭＣＳパラメータと、第２の対応する寸法に関連する第２のＬＭＣＳパラメータとを含み、第２のＬＭＣＳパラメータは第１のＬＭＣＳパラメータから継承されるか又は予測される。一部の実施では、ビデオユニット内でシグナリングされるＡＬＦパラメータ又はＬＭＣＳパラメータは、１つ又は複数のピクチャ寸法に関連する。一部の実施では、本方法は、現在のビデオブロックが、現在のピクチャとは異なる寸法を有する少なくとも１つの参照ピクチャを参照する場合に、現在のビデオブロックに対して符号化ツールを無効にすることをさらに含む。一部の実施では、本方法は、現在のピクチャの寸法から異なる寸法を有する参照ピクチャを参照するマージ候補をスキップすること又は省略することをさらに含む。一部の実施では、本方法は、参照ピクチャの解像度及び現在ピクチャの解像度に基づいて、２つの参照ブロック又は２つの参照ピクチャをスケーリングした後で又は参照ピクチャの解像度及び現在ピクチャの解像度に基づいて、２つのＭＶ又はＭＶＤをスケーリングした後で、符号化ツールを適用することをさらに含む。一部の実施では、現在のピクチャは異なる解像度をＫ個以下しか含まず、Ｋは自然数である。一部の実施では、Ｎ個の連続したピクチャに対してＫ個の異なる解像度が許容され、Ｎは自然数である。

【0373】

一部の実施では、本方法は、イントラピクチャである現在のピクチャに対して解像度変更を適用することをさらに含む。一部の実施では、本方法は、現在のビデオブロックの１つ又は２つの参照ピクチャが現在のピクチャの解像度と異なる解像度を有する場合に、双方向き予測を単方向予測に変換することをさらに含む。一部の実施では、本方法は、現在のブロック寸法と参照ブロック寸法との間の解像度比又は動きベクトル精度のうちの少なくとも１つによって決まり、異なる解像度の参照ピクチャからのインター予測を有効又は無効にすることをさらに含む。現在のブロック寸法がＷ＊Ｈとすると、参照ブロック寸法はＷ１＊Ｈ１であり、解像度比はＷ１／Ｗ、Ｈ１／Ｈ、（Ｗ１＊Ｈ１）／（Ｗ＊Ｈ）、ｍａｘ（Ｗ１／Ｗ、Ｈ１／Ｈ）又はｍｉｎ（Ｗ１／Ｗ、Ｈ１／Ｈ）等を参照し得る。一部の実施では、本方法は、両方の参照ピクチャ又は一方の参照ピクチャが現在のピクチャとは異なる解像度を有するかどうかに応じて、双方向予測を適用することをさらに含む。一部の実施では、現在のビデオブロックが現在のピクチャとは異なる寸法を有する参照ピクチャを参照するかどうかは、現在のビデオブロックのサイズ又はブロック予測モードのうちの少なくとも１つによって決まる。一部の実施では、変換を行うことは、ビットストリーム表現から現在のビデオブロックを生成することを含む。一部の実施では、変換を行うことは、現在のビデオブロックからビットストリーム表現を生成することを含む。

【0374】

図２４Ａは、ビデオ処理装置２４００のブロック図である。装置２４００は、本明細書で説明する方法のうちの１つ以上を実施するために用いられ得る。装置２４００は、スマートフォン、タブレット、コンピュータ、モノのインターネット（ＩｏＴ）受信機等で具体化され得る。装置２４００は、１つ以上のプロセッサ２４０２、１つ以上のメモリ２４０４及びビデオ処理ハードウェア２４０６を含み得る。プロセッサ２４０２は、本明細書で説明する１つ以上の方法（限定されないが、方法２３００を含む）を実施するように構成され得る。メモリ（複数のメモリ）２４０４は、本明細書で説明する方法及び技術を実施するために用いられるデータ及びコードを記憶するために用いられ得る。ビデオ処理ハードウェア２４０６は、ハードウェア回路で、本明細書で説明するいくつかの技術を実施するために用いられ得る。一部の実施では、ハードウェア２４０６は、例えばグラフィックスプロセッサとして、完全に又は部分的にプロセッサ２４０１内にあり得る。

【0375】

図２４Ｂは、本明細書に開示の様々な技術が実施され得る例示のビデオ処理システム２４１０を示すブロック図である。様々な実施は、システム２４１００の構成要素の一部又は全てを含み得る。システム２４１０は、ビデオコンテンツを受信するための入力２４１２を含み得る。ビデオコンテンツは生の状態又は非圧縮形式で、例えば８又は１０ビットの多成分画素値で受信され得るか又は圧縮又は符号化形式で受信され得る。入力２４１２は、ネットワークインターフェイス、周辺バスインターフェイス又は記憶インターフェイスを表し得る。ネットワークインターフェイスの例としては、イーサネット、受動光ネットワーク（ＰＯＮ）等の有線インターフェイス等及びＷｉ－Ｆｉ又はセルラーインターフェイス等の無線インターフェイスが挙げられる。

【0376】

システム２４１０は、本明細書で説明する様々なコーディング又はエンコーディング方法を実施し得る符号化コンポーネント２４１４を含み得る。符号化コンポーネント２４１４は、入力２４１２から符号化コンポーネント２４１４の出力へのビデオの平均ビットレートを低減して、ビデオの符号化表現を生成し得る。したがって、コーディング技術は、ビデオ圧縮又はビデオトランスコーディング技術と呼ばれることがある。符号化コンポーネント２４１４の出力は格納されるか又はコンポーネント２４１６によって表されるように、通信接続を介して送信され得る。入力２４１２で受信されたビデオの格納又は通信されたビットストリーム（又は符号化）表現は、ディスプレイインターフェイス２４２０に送られる表示可能なビデオ又は画素値を生成するためにコンポーネント２４１８によって用いられ得る。ビットストリーム表現からユーザが視聴可能なビデオを生成するプロセスは、ビデオ解凍と時々呼ばれる。さらに、特定のビデオ処理動作は、「符号化」動作又はツールと呼ばれるが、符号化ツール又は動作はエンコーダで用いられ、符号化の結果を反転する対応する復号化ツール又は動作はデコーダで行われることになるのが理解されよう。

【0377】

周辺バスインターフェイス又はディスプレイインターフェイスの例としては、ユニバーサルシリアルバス（ＵＳＢ）又は高精細度マルチメディアインターフェイス（ＨＤＭＩ（登録商標））又はディスプレイポート等が挙げられる。記憶インターフェイスの例としては、ＳＡＴＡ（serial advanced technology attachment）、ＰＣＩ、ＩＤＥインターフェイス等が挙げられる。本明細書で説明する技術は、携帯電話、ラップトップ、スマートフォン又はデジタルデータ処理及び／又はビデオ表示を行うことが可能な他の装置といった様々な電子装置で具現化され得る。

【0378】

一部の実施では、ビデオ符号化方法は、図２４Ａ又は図２４Ｂに関して説明したようなハードウェアプラットフォーム上に実施される装置を用いて実施され得る。

【0379】

図２５は、本開示の技術を利用し得る例示のビデオコーディングシステム１００を示すブロック図である。

【0380】

図２５に示すように、ビデオコーディングシステム１００はソース装置１１０及び宛先装置１２０を含み得る。ソース装置１１０はエンコードされたビデオデータを生成し、ビデオコーディング装置と呼ばれ得る。宛先装置１２０は、ソース装置１１０によって生成されたエンコードされたビデオデータをデコードし、ビデオデコーデイング装置と呼ばれ得る。

【0381】

ソース装置１１０は、ビデオソース１１２、ビデオエンコーダ１１４及び入出力インターフェイス１１６を含み得る。

【0382】

ビデオソース１１２は、ビデオキャプチャ装置等のソース、ビデオコンテンツプロバイダからビデオデータを受信するためのインターフェイス及び／又はビデオデータを生成するためのコンピュータグラフィックスシステム又はそのようなソースの組み合わせを含み得る。ビデオデータは１つ以上のピクチャを含み得る。ビデオエンコーダ１１４は、ビットストリームを生成するためにビデオソース１１２からのビデオデータをエンコードする。ビットストリームは、ビデオデータのコード化表現を形成するビットのシーケンスを含み得る。ビットストリームは、コード化されたピクチャ及び関連するデータを含み得る。コード化されたピクチャはピクチャのコード化された表現である。関連するデータは、シーケンスパラメータセット、ピクチャパラメータセット及び他のシンタックス構造を含み得る。Ｉ／Ｏインターフェイス１１６は、変調器／復調器（モデム）及び／又は送信器を含み得る。コード化されたビデオデータは、ネットワーク１３０ａを介してＩ／Ｏインターフェイス１１６を介して宛先装置１２０に直接送信され得る。エンコードされたビデオデータは、宛先装置１２０によるアクセスのために記憶媒体／サーバ１３０ｂにも記憶され得る。

【0383】

宛先装置１２０は、Ｉ／Ｏインターフェイス１２６、ビデオデコーダ１２４及びディスプレイ装置１２２を含み得る。

【0384】

Ｉ／Ｏインターフェイス１２６は受信器及び／又はモデムを含み得る。Ｉ／Ｏインターフェイス１２６は、ソース装置１１０又は記憶媒体／サーバ１３０ｂからエンコードされたビデオデータを取得し得る。ビデオデコーダ１２４は、エンコードされたビデオデータをデコードし得る。ディスプレイ装置１２２は、デコードされたビデオデータをユーザに表示し得る。ディスプレイ装置１２２は宛先装置１２０と一体化され得るか又は外部ディスプレイ装置とやりとりするように構成された宛先装置１２０の外部にあってもよい。

【0385】

ビデオエンコーダ１１４及びビデオデコーダ１２４は、高効率ビデオコーディング（ＨＥＶＣ）規格、汎用ビデオコーディング（ＶＶＣ）規格及びその他の現在の及び／又は更なる規格等のビデオ圧縮規格に従って動作し得る。

【0386】

図２６は、図２５に示すシステム１００内のビデオエンコーダ１１４であり得るビデオエンコーダ２００の一例を示すブロック図である。

【0387】

ビデオエンコーダ２００は、本開示の技術のいずれか又は全てを行うように構成され得る。図２６の例では、ビデオエンコーダ２００は複数の機能コンポーネントを含む。本開示で説明する技術は、ビデオエンコーダ２００の様々なコンポーネントの間で共有され得る。一部の例では、プロセッサは、本開示で説明する技術のいずれか又は全てを行うように構成され得る。

【0388】

ビデオエンコーダ２００の機能コンポーネントは、分割ユニット２０１と、モード選択ユニット２０３、動き推定ユニット２０４、動き補償ユニット２０５及びイントラ予測ユニット２０６を含み得る予測ユニット２０２と、残差生成ユニット２０７と、変換ユニット２０８と、量子化ユニット２０９と、逆量子化ユニット２１０と、逆変換ユニット２１１と、再構成ユニット２１２と、バッファ２１３と、エントロピー符号化ユニット２１４とを含み得る。

【0389】

他の例では、ビデオエンコーダ２００はより多くの、より少ない又は異なる機能コンポーネントを含み得る。１つの例では、予測ユニット２０２は、イントラブロックコピー（ＩＢＣ）ユニットを含み得る。ＩＢＣユニットは、少なくとも１つの参照ピクチャが現在のビデオブロックが位置するピクチャであるＩＢＣモードで予測を行い得る。

【0390】

さらに、動き推定ユニット２０４及び動き補償ユニット２０５等の一部のコンポーネントは高度に統合されてもよいが、説明のために図２６の例では別々に表されている。

【0391】

分割ユニット２０１は、ピクチャを１つ以上のビデオブロックに分割し得る。ビデオエンコーダ２００及びビデオデコーダ３００は様々なビデオブロックサイズをサポートし得る。

【0392】

モード選択ユニット２０３は、例えばエラー結果に基づいて、コーディングモード（イントラ又はインター）のうちの１つを選択し、結果として得られたイントラ又はインターコード化ブロックを、残差ブロックデータを生成するために残差生成ユニット２０７に、参照ピクチャとして用いるためにエンコードされたブロックを再構成するために再構成ユニット２１２に提供する。一部の例では、モード選択ユニット２０３は、予測がインター予測信号及びイントラ予測信号に基づく、イントラ及びインター予測（ＣＩＩＰ）モードの組み合わせを選択し得る。モード選択ユニット２０３は、インター予測の場合に、ブロックための動きベクトルの解像度（例えば、サブピクセル又は整数ピクセル精度）も選択し得る。

【0393】

現在のビデオブロックにインター予測を行うために、動き推定ユニット２０４は、バッファ２１３から１つ以上の参照フレームを現在のビデオブロックと比較することによって、現在のビデオブロックのためのモーション情報を生成し得る。動き補償ユニット２０５は、現在のビデオブロックに関連するピクチャ以外にバッファ２１３からのピクチャの動き情報及びデコードされたサンプルに基づいて、現在のビデオブロックのための予測ビデオブロックを特定し得る。

【0394】

動き推定ユニット２０４及び動き補償ユニット２０５は、例えば、現在のビデオブロックがＩスライスにあるか、Ｐスライスにあるか又はＢスライスにあるかによって、現在のビデオブロックに対して異なる動作を行い得る。

【0395】

一部の例では、動き推定ユニット２０４は、現在のビデオブロックに対して単一方向の予測を行ってもよく、動き推定ユニット２０４は、現在のビデオブロック用の参照ビデオブロックのためにリスト０又はリスト１の参照ピクチャを検索し得る。次に、動き推定ユニット２０４は、参照ビデオブロックと、現在のビデオブロックと参照ビデオブロックとの間の空間的変位を示す動きベクトルとを含む、リスト０又はリスト１内の参照ピクチャを示す参照インデックスを生成し得る。動き推定ユニット２０４は、現在のビデオブロックの動き情報として、参照インデックス、予測方向インジケータ及び動きベクトルを出力し得る。動き補償ユニット２０５は、現在のビデオブロックの動き情報によって示される参照ビデオブロックに基づいて、現在のブロックの予測ビデオブロックを生成し得る。

【0396】

他の例では、動き推定ユニット２０４は、現在のビデオブロックについて双方向予測を行ってもよく、動き推定ユニット２０４は、現在のビデオブロック用の参照ビデオブロックについてリスト０内の参照ピクチャを検索し、現在のビデオブロック用の別の参照ビデオブロックについてもリスト１内の参照ピクチャを検索し得る。次に、動き推定ユニット２０４は、参照ビデオブロックと、参照ビデオブロックと現在のビデオブロックとの間の空間的変位を示す動きベクトルとを含むリスト０及びリスト１における参照ピクチャを示す参照インデックスを生成し得る。動き推定ユニット２０４は、現在のビデオブロックの参照インデックス及び動きベクトルを現在のビデオブロックの動き情報として出力し得る。動き補償ユニット２０５は、現在のビデオブロックの動き情報によって示される参照ビデオブロックに基づいて、現在のビデオブロックの予測ビデオブロックを生成し得る。

【0397】

一部の例では、動き推定ユニット２０４は、デコーダのデコーディング処理のために完全な動き情報のセットを出力し得る。

【0398】

一部の例では、動き推定ユニット２０４は、現在のビデオのための完全な動き情報のセットを出力しなくてもよい。むしろ、動き推定ユニット２０４は、他のビデオブロックの動き情報を参照して現在のビデオブロックの動き情報を信号化することができる。例えば、動き推定ユニット２０４は、現在のビデオブロックのモーション情報が隣接するビデオブロックのモーション情報と十分に類似していると判断することができる。

【0399】

１つの例では、動き推定ユニット２０４は、現在のビデオブロックに関連するシンタックス構造において、現在のビデオブロックが別のビデオブロックと同じ動き情報を有することをビデオデコーダ３００に示す値を示し得る。

【0400】

別の例では、動き推定ユニット２０４は、現在のビデオブロックに関連するシンタックス構造において、別のビデオブロック及び動きベクトル差（ＭＶＤ）を識別し得る。動きベクトル差は、現在のビデオブロックの動きベクトルと、示されたビデオブロックの動きベクトルとの間の差を示す。ビデオデコーダ３００は、示されたビデオブロックの動きベクトルと動きベクトル差とを用いて、現在のビデオブロックの動きベクトルを特定し得る。

【0401】

上述のように、ビデオエンコーダ２００は、動きベクトルを予測的にシグナリングし得る。ビデオエンコーダ２００によって実現され得る予測シグナリング技術の２つの例は、高度動きベクトル予測（ＡＭＶＰ）及びマージモードシグナリングを含む。

【0402】

イントラ予測ユニット２０６は、現在のビデオブロックに対してイントラ予測を行い得る。イントラ予測ユニット２０６が現在のビデオブロックに対してイントラ予測を行う場合、イントラ予測ユニット２０６は、同じピクチャ内の他のビデオブロックのデコードされたサンプルに基づいて、現在のビデオブロックのための予測データを生成し得る。現在のビデオブロックのための予測データは、予測されたビデオブロック及び様々なシンタックス要素を含み得る。

【0403】

残差生成ユニット２０７は、現在のビデオブロックから現在のビデオブロックの予測されたビデオブロックを差し引くことにより（例えば、マイナス記号によって示される）、現在のビデオブロックのための残差データを生成し得る。現在のビデオブロックの残差データは、現在のビデオブロック内のサンプルの異なるサンプル成分に対応する残差ビデオブロックを含み得る。

【0404】

他の例では、例えばスキップモードでは、現在のビデオブロックのための現在のビデオブロックのための残差データが存在しないことがあり、残差生成ユニット２０７は減算動作を行わなくてもよい。

【0405】

変換処理ユニット２０８は、現在のビデオブロックに関連する残差ビデオブロックに対して１つ以上の変換を適用することにより、現在のビデオブロックのための１つ以上の変換係数ビデオブロックを生成し得る。

【0406】

変換処理ユニット２０８が現在のビデオブロックに関連する変換係数ビデオブロックを生成した後で、量子化ユニット２０９は、現在のビデオブロックに関連する１つ以上の量子化パラメータ（ＱＰ）値に基づいて、現在のビデオブロックに関連する変換係数ビデオブロックを量子化し得る。

【0407】

逆量子化ユニット２１０及び逆変換ユニット２１１は、変換係数ビデオブロックから残差ビデオブロックを再構成するために、変換係数ビデオブロックにそれぞれ逆量子化及び逆変換を適用し得る。再構成ユニット２１２は、予測ユニット２０２によって生成された１つ以上の予測されたビデオブロックからの対応するサンプルに、再構成された残差ビデオブロックを追加して、現在のブロックに関連する再構成されたビデオブロックをバッファ２１３に格納するために生成し得る。

【0408】

再構成ユニット２１２がビデオブロックを再構成した後、ビデオブロックにおけるビデオブロッキングアーチファクトを低減するためにループフィルタ動作が行われ得る。

【0409】

エントロピー符号化ユニット２１４は、ビデオエンコーダ２００の他の機能コンポーネントからデータを受信し得る。エントロピー符号化ユニット２１４がデータを受信すると、エントロピー符号化ユニット２１４は、１つ以上のエントロピー符号化動作を行って、エントロピー符号化データを生成し、エントロピー符号化データを含むビットストリームを出力し得る。

【0410】

図２７は、図２５に示すシステム１００におけるビデオデコーダ１１４であり得るビデオデコーダ３００の一例を示すブロック図である。

【0411】

ビデオデコーダ３００は、本開示の技術のいずれか又は全てを行うように構成され得る。図２７の例では、ビデオデコーダ３００は、複数の機能コンポーネントを含む。本開示で説明する技術は、ビデオデコーダ３００の様々なコンポーネントの間で共有され得る。いくつかの例では、プロセッサは、本開示で説明する技術のいずれか又は全てを行うように構成され得る。

【0412】

図２７の例では、ビデオデコーダ３００は、エントロピー復号化ユニット３０１、動き補償ユニット３０２、イントラ予測ユニット３０３、逆量子化ユニット３０４、逆変換ユニット３０５及び再構成ユニット３０６及びバッファ３０７を含む。ビデオデコーダ３００は、一部の例では、ビデオエンコーダ２００（例えば、図２６）に関して説明したエンコーディングパスと概ね逆のデコーディングパスを行い得る。

【0413】

エントロピー復号化ユニット３０１は、符号化ビットストリームを読み出し得る。符号化ビットストリームはエントロピー符号化ビデオデータ（例えば、ビデオデータの符号化ブロック）を含み得る。エントロピー復号化ユニット３０１はエントロピー符号化ビデオデータを復号化し、エントロピー復号化ビデオデータから、動き補償ユニット３０２は動きベクトル、動きベクトル精度、参照ピクチャリストインデックス及び他の動き情報を含む動き情報を特定し得る。動き補償ユニット３０２は、例えば、ＡＭＶＰ及びマージモードを実行することにより、そのような情報を特定し得る。

【0414】

動き補償ユニット３０２は動き補償ブロックを生成し、場合によっては補償フィルタに基づいて補間を行い得る。サブピクセル精度で用いられるべき補間フィルタのための識別子は、シンタックス要素に含まれ得る。

【0415】

動き補償ユニット３０２は、ビデオブロックの符号化の間にビデオエンコーダ２０によって用いられる補間フィルタを用いて、参照ブロックのサブ整数ピクセルのための補間値を計算し得る。動き補償ユニット３０２は、受信されたシンタックス情報に従ってビデオエンコーダ２００によって用いられる補間フィルタを決定し、予測ブロックを生成するために補間フィルタを用い得る。

【0416】

動き補償ユニット３０２は、符号化ビデオシーケンスのフレーム及び／又はスライスを符号化するために用いられるブロックのサイズ、符号化ビデオシーケンスのピクチャの各マクロブロックがどのように分割されるかを記述する分割情報、各分割がどのように符号化されるかを示すモード、各インター符号化ブロックのための１つ以上の参照フレーム（及び参照フレームリスト）及び符号化ビデオシーケンスを復号するための他の情報を決定するために、シンタックス情報の一部を用いり得る。

【0417】

イントラ予測ユニット３０３は、例えば、ビットストリームで受信されたイントラ予測モードを用いて、空間的に隣接するブロックから予測ブロックを形成し得る。逆量子化ユニット３０４は、ビットストリーム内で提供され、エントロピー復号化ユニット３０１によって復号化される量子化ビデオブロック係数を逆量子化、すなわち脱量子化する。逆変換ユニット３０５は逆変換を適用する。

【0418】

再構成ユニット３０６は、残差ブロックを動き補償ユニット２０５又はイントラ予測ユニット３０３によって生成された対応する予測ブロックと合算して、復号化ブロックを形成し得る。所望により、ブロック性アーチファクトを除去するために、復号化ブロックをフィルタリングするためデブロックフィルタも適用され得る。次いで、復号化ビデオブロックはバッファ３０７に格納され、バッファ３０７は、後続の動き補償のための参照ブロックを提供する。

【0419】

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

【0420】

開示の技術の一部の実施形態は、ビデオ処理ツール又はモードを無効にする決定又は判断を行うことを含む。１つの例では、ビデオ処理ツール又はモードが無効にされている場合、エンコーダは、ビデオのブロックをビデオのビットストリーム表現に変換する際にツール又はモードを用いない。別の例では、ビデオ処理ツール又はモードが無効にされている場合、デコーダは、決定又は判断に基づいて無効にされたビデオ処理ツール又はモードを用いてビットストリームが修正されていないとの知識によりビットストリームを処理する。

【0421】

本願において、「ビデオ処理」という用語は、ビデオ符号化、ビデオ復号化、ビデオ圧縮又はビデオ解凍を意味し得る。例えば、ビデオ圧縮アルゴリズムは、ビデオのピクセル表現から対応するビットストリーム表現へ又はその逆への変換の間に適用され得る。現在のビデオブロックのビットストリーム表現は、例えば、シンタックスによって定義されるように、同一場所に配置されているか又はビットストリーム内の異なる場所に分散されているかのいずれかのビットに対応し得る。例えば、マクロブロックは、変換及び符号化エラー残差値の観点から及びビットストリームにおけるヘッダ及び他のフィールド内のビットを用いて符号化され得る。

【0422】

以下の第１の項（clause）のセットが一部の実施形態で実施され得る。

【0423】

１．ビデオ処理のための方法であって、現在のビデオブロックと、現在のビデオブロックのビットストリーム表現との間での変換の間に、現在のビデオブロックに関連する参照ピクチャの解像度と、現在のピクチャの解像度とに基づいて、動きベクトルオフセットを導出すことと、該動きベクトルオフセットを用いて前記変換を行うこととを含む、方法。

【0424】

２．前記動きベクトルオフセットを導出することは、第１の参照ピクチャを参照する第１の動きベクトルオフセットを導出することと、前記第１の動作ベクトルオフセットに基づいて、第２の参照ピクチャを参照する第２の動作ベクトルオフセットを導出することとを含む、１項に記載の方法。

【0425】

３．前記現在のビデオブロックに対して、空間的、時間的又は履歴的な動き候補に関連する参照ピクチャ解像度に基づいて、動き候補リスト構築プロセスを行うことをさらに含む、１項に記載の方法。

【0426】

４．ルックアップテーブルを更新するかどうか又はどのように更新するかは、復号化動き候補に関連する参照ピクチャ解像度によって決まる、１項に記載の方法。

【0427】

５．前記現在のピクチャに対して、対応する寸法に関連する適応ループフィルタ（ＡＬＦ）パラメータを用いてフィルタリング動作を行うことをさらに含む、１項に記載の方法。

【0428】

６．前記ＡＬＦパラメータは、第１の対応する寸法に関連する第１のＡＬＦパラメータと、第２の対応する寸法に関連する第２のＡＬＦパラメータとを含み、該第２のＡＬＦパラメータは第１のＡＬＦパラメータから継承されるか又は予測される、５項に記載の方法。

【0429】

７．対応する寸法に関連するＬＭＣＳ（ルーママッピングクロマスケーリング）パラメータを用いて、現在のピクチャ内のサンプルを再成形することをさらに含む、１項に記載の方法。

【0430】

８．前記ＬＭＣＳパラメータは、第１の対応する寸法に関連する第１のＬＭＣＳパラメータと、第２の対応する寸法に関連する第２のＬＭＣＳパラメータとを含み、該第２のＬＭＣＳパラメータは該第１のＬＭＣＳパラメータから継承されるか又は予測される、７項に記載の方法。

【0431】

９．ビデオユニットにおいてシグナリングされるＡＬＦパラメータ又はＬＭＣＳパラメータは、１つ又は複数のピクチャ寸法に関連する５又は７項に記載の方法。

【0432】

１０．現在のビデオブロックが、現在のピクチャと異なる寸法を有する少なくとも１つの参照ピクチャを参照する場合、現在のビデオブロックのための符号化ツールを無効にすることをさらに含む、１項に記載の方法。

【0433】

１１．現在のピクチャの寸法と異なる寸法を有する参照ピクチャを参照するマージ候補をスキップするか又は省略することをさらに含む、１０項に記載の方法。

【0434】

１２．参照ピクチャの解像度及び現在ピクチャの解像度に基づいて、２つの参照ブロック又は２つの参照ピクチャをスケーリングした後に又は参照ピクチャの解像度及び現在ピクチャの解像度に基づいて２つのＭＶ又はＭＶＤ（動きベクトル差）をスケーリングした後に、符号化ツールを適用することさらに含む、１項に記載の方法。

【0435】

１３．前記現在のピクチャが含む異なる解像度はＫ個以下であり、Ｋは自然数である、１項に記載の方法。

【0436】

１４．Ｎ個の連続したピクチャに対して前記Ｋ個の異なる解像度が許され、Ｎは自然数である、１３項に記載の方法。

【0437】

１５．イントラピクチャである現在のピクチャに解像度変更を適用することをさらに含む、１項に記載の方法。

【0438】

１６．現在のビデオブロックの１つ又は２つの参照ピクチャが現在のピクチャの解像度と異なる解像度を有する場合に、双方向予測を単方向予測に変換することをさらに含む、１項に記載の方法。

【0439】

１７．動きベクトル精度又は現在のブロック寸法と参照ブロック寸法との間の解像度のうちの少なくとも１つによって、異なる解像度の参照ピクチャからのインター予測を有効又は無効にすることをさらに含む、１項に記載の方法。

【0440】

１８．両方の参照ピクチャ又は一方の参照ピクチャが現在のピクチャとは異なる解像度を有するかどうかによって、双方向予測を適用することをさらに含む、１項に記載の方法。

【0441】

１９．現在のビデオブロックは現在のピクチャとは異なる寸法を有する参照ピクチャを参照するかどうかは、現在のビデオブロックのサイズ又はブロック予測モードのうちの少なくとも１つによって決まる、１項に記載の方法。

【0442】

２０．前記変換を行うことは、前記ビットストリーム表現から前記現在のビデオブロックを生成することを含む、１項に記載の方法。

【0443】

２１．前記変換を行うことは、前記現在のビデオブロックから前記ビットストリーム表現を生成することを含む、１項に記載の方法。

【0444】

２２．プロセッサと、命令を有する非一時メモリとを含むビデオシステム内の装置であって、前記プロセッサによる実行の際に、前記命令は、前記プロセッサに、１項乃至２１項のいずれか１項に記載の方法を実行させる、装置。

【0445】

２３．非一時的コンピュータ読み取り可能媒体に記憶されたコンピュータプログラム製品であって、１項乃至２１項のいずれか一項に記載の方法を行うためのプログラムコードを含む、コンピュータプログラム製品。

【0446】

第２の項のセットは、先のセクションで開示した技術の特定の特徴及び態様を説明する。

【0447】

１.ビデオ処理のための方法（例えば、図２８に示す方法２８００）であって、ビデオのピクチャのビデオ領域と該ビデオの符号化表現との間での変換のために、該符号化表現におけるビデオ領域を表すために用いられる符号化ツールの有効状態を判定ことと（２８１０）、該判定に従って前記変換を行うこと（２８２０）とを含み、前記ピクチャのための前記符号化ツールの有効状態を示すために、第１のフラグがピクチャヘッダに含まれている、方法。

【0448】

２．前記有効状態は、前記第１のフラグ及び／又は前記ビデオのスライスタイプによって、前記符号化が前記ビデオ領域に対して無効であるか又は有効であるかを示す、１項に記載の方法。

【0449】

３．前記判定することは、前記第１のフラグが真の場合に前記符号化ツールが無効であると判定する、１項に記載の方法。

【0450】

４．前記判定することは、前記第１のフラグが偽の場合に前記符号化ツールが無効であると判定する、１項に記載の方法。

【0451】

５．前記判定することは、前記第１のフラグが偽の場合に前記符号化ツールが有効であると判定する、１項に記載の方法。

【0452】

６．前記判定することは、前記第１のフラグが真の場合に前記符号化ツールが有効であると判定する、１項に記載の方法。

【0453】

７．前記符号化ツールは、前記ピクチャ内の全てのサンプルに対して無効にされているか又は有効にされている、１項に記載の方法。

【0454】

８．前記第１のフラグのシグナリングは、前記ビデオ領域に関連するシーケンスパラメータセット（ＳＰＳ）、ビデオパラメータセット（ＶＰＳ）、依存性パラメータセット（ＤＰＳ）又はピクチャパラメータセット（ＰＰＳ）における１つ以上のシンタックス要素によって決まる、１項に記載の方法。

【0455】

９．前記第１のフラグのシグナリングは、前記シーケンスパラメータセット（ＳＰＳ）におけて前記符号化ツールの有効を示す表示によって決まる、８項に記載の方法。

【0456】

１０．前記ピクチャヘッダ内の前記第１のフラグの存在を示す第２のフラグは、前記シーケンスパラメータセット（ＳＰＳ）でシグナリングされる、８項に記載の方法。

【0457】

１１．前記ピクチャヘッダ内の前記第１のフラグの存在を示す第２のフラグは、前記符号化ツールが前記ビデオのシーケンスに対して有効にされている場合にシグナリングされる、８項に記載の方法。

【0458】

１２．前記第１のフラグの存在を示す前記第２のフラグが前記第１のフラグの存在を示す場合、前記第１のフラグは前記ピクチャヘッダでシグナリングされる、８項に記載の方法。

【0459】

１３．前記第１のフラグ及び／又は前記第２のフラグは１ビットで符号化される、１項乃至１２項のいずれかに記載の方法。

【0460】

１４．前記符号化ツールは、１つ以上の初期アフィン予測がオプティカルフロー計算に基づいて精緻化される、オプティカルフローを用いた予測精緻化（ＰＲＯＦ）である、１項乃至１３項のいずれかに記載の方法。

【0461】

１５．前記符号化ツールは、動き情報が予測ブロックを用いて精緻化されるデコーダ側動きベクトル精緻化（ＤＭＶＲ）である、１項乃至１３項のいずれかに記載の方法。

【0462】

１６．前記符号化ツールは、１つ以上の初期予測がオプティカルフロー計算を用いて精緻化される双方向オプティカルフロー（ＢＤＯＦ）である、１項乃至１３項のいずれかに記載の方法。

【0463】

１７．前記符号化ツールは、線形フィルタがルーマ情報に基づいてクロマサンプルに適用されるクロスコンポーネント適応ループフィルタ（ＣＣＡＬＦ）である、１項乃至１３項のいずれかに記載の方法。

【0464】

１８．前記符号化ツールは、予測サンプルが重み付け値を用いて生成される幾何学的分割（ＧＥＯ）であり、該予測サンプルは、非水平又は非垂直の線に従った前記ビデオ領域の分割に基づく、１項乃至１３項のいずれかに記載の方法。

【0465】

１９．前記符号化ツールは、予測サンプルが重み付け値を用いて生成される三角予測モード（ＴＰＭ）であり、該予測サンプルは、前記ビデオ領域を２つの三角パーティションに分割することに基づく、１項乃至１３項のいずれかに記載の方法。

【0466】

２０．前記変換は、前記ビデオをビットストリーム表現に符号化することを含む、１項乃至１９項のいずれかに記載の方法。

【0467】

２１．前記変換は、前記ビデオを生成するために前記ビットストリーム表現を復号することを含む、１項乃至１９項のいずれかに記載の方法。

【0468】

２２．１項乃至２１項の１つ以上に記載の方法を実施するように構成されたプロセッサ含むビデオ処理装置。

【0469】

２３．実行された場合に、プロセッサに、１項乃至２１項の１つ以上に記載の方法を実施させるプログラムコードを記憶するコンピュータ読み取り可能媒体。

【0470】

２４．上述の方法のいずれかに従って生成される符号化表現又はビットストリーム表現を記憶するコンピュータ読み取り可能媒体。

【0471】

以上から、本開示の技術の特定の実施形態は説明を目的として本明細書に記載されているが、開示の技術の範囲から逸脱することなく、様々な修正を行うことができることが理解されるであろう。したがって、本開示の技術は、添付の特許請求の範囲を除いて、限定されない。

【0472】

本明細書で説明した主題及び機能動作の実施は、本明細書で開示の構造及びそれらの構造的同等物又はそれらのうちの１つ以上の組み合わせを含む、様々なシステム、デジタル電子回路又はコンピュータソフトウェア、ファームウェア又はハードウェアで実施することができる。本明細書で説明した主題の実施は、１つ以上のコンピュータプログラム製品、すなわち、データ処理装置による実行のために又はデータ処理装置の動作を制御するために、有形及び非一時的なコンピュータ読み取り可能媒体上にエンコードされているコンピュータプログラム命令の１つ以上のモジュールとして実施可能である。コンピュータ読み取り可能媒体は、機械により読み出し可能な記憶デバイス、機械により読み出し可能な記憶担体、メモリデバイス、機械により読み出し可能な伝搬信号をもたらす組成物又はそれらの１つ以上の組み合わせであることができる。「データ処理ユニット」又は「データ処理装置」という用語は、例として、プログラム可能なプロセッサ、コンピュータ又は複数のプロセッサ若しくはコンピュータを含む、データを処理する全ての装置、デバイス及び機械を包含する。装置は、ハードウェアに加えて、問題となっているコンピュータプログラムのための実行環境を作り出すコード、例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム又はそれらの１つ以上の組み合わせを構成するコードを含むことができる。

【0473】

コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト又はコードとしても知られる）は、コンパイル済み又は解釈済みの言語を含む如何なる形式のプログラミング言語でも記述可能であり、それは、スタンドアロンプログラムとして又はコンピューティング環境における使用に適したモジュール、コンポーネント、サブルーチン若しくは他のユニットとして、を含め、如何なる形式でもデプロイ可能である。コンピュータプログラムは、必ずしもファイルシステムにおけるファイルに対応しない。プログラムは、問題となっているプログラムに専用の単一のファイルで、又は複数の協調したファイル（例えば、１つ以上のモジュール、サブプログラム、又はコードの部分を保存するファイル）で、他のプログラム又はデータ（例えば、マークアップ言語文書で保存された１つ以上のスクリプト）を保持するファイルの部分において保存可能である。コンピュータプログラムは、１つのコンピュータで、あるいは、１つの場所に位置しているか、又は複数の場所にわたって分布しており、通信ネットワークによって相互接続されている複数のコンピュータで、実行されるようデプロイ可能である。

【0474】

本明細書で記載されているプロセス及び論理フローは、入力データに作用して出力を生成することによって機能を実行するよう１つ以上のコンピュータプログラムを実行する１つ以上のプログラム可能なプロセッサによって実行可能である。プロセス及び論理フローはまた、専用のロジック回路、例えば、ＦＰＧＡ（Field Programmable Gate Array）又はＡＳＩＣ（Application-Specific Integrated Circuit）によっても実行可能であり、装置は、そのようなものとしても実装可能である。

【0475】

コンピュータプログラムの実行に適したプロセッサは、例として、汎用のマイクロプロセッサ及び専用のマイクロプロセッサの両方、並びにあらゆる種類のデジタルコンピュータのいずれか１つ以上のプロセッサを含む。一般に、プロセッサは、リードオンリーメモリ若しくはランダムアクセスメモリ又はその両方から命令及びデータを受け取ることになる。コンピュータの必須の要素は、命令を実行するプロセッサと、命令及びデータを保存する１つ以上のメモリデバイスと、である。一般に、コンピュータはまた、データを保存する１つ以上の大容量記憶デバイス、例えば、磁気、光学磁気ディスク、又は光ディスクを含むか、あるいは、そのような１つ以上の大容量記憶デバイスからのデータの受信若しくはそれへのデータの転送又はその両方のために動作可能に結合されることになる。しかしながら、コンピュータは、そのようなデバイスを有する必要はない。コンピュータプログラム命令及びデータを保存するのに適したコンピュータ読み取り可能媒体は、例として、半導体メモリデバイス、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、及びフラッシュメモリデバイスを含む全ての形式の不揮発性メモリ、媒体及びメモリデバイスを含む。プロセッサ及びメモリは、専用のロジック回路によって強化されるか、あるいは、それに組み込まれ得る。

【0476】

本明細書は、図面と共に例示のみとしてみなされることを意図している。例示とは例を意味する。本明細書で使用する単数形「ａ」、「ａｎ」及び「ｔｈｅ」は、別段明記されていない限り、複数形を含むことを意図している。加えて、「又は」の使用は、別段明記されていない限り、「及び／又は」を含むことを意図する。

【0477】

本明細書は、多数の詳細を含むが、それらは、あらゆる発明の又は請求される可能性があるものの範囲に対する限定としてではなく、むしろ、特定の発明の特定の実施形態に特有であり得る特徴の説明として解釈されるべきである。別々の実施形態に関連して本明細書に記載されている特定の特徴は、単一の実施形態と組み合わせても実装可能である。逆に、単一の実施形態に関連して記載されている様々な特徴はまた、複数の実施形態で別々に、又は何らかの適切なサブコンビネーションで実装可能である。更に、特徴は、特定の組み合わせで動作するものとして上述され、そのようなものとして最初に請求されることさえあるが、請求されている組み合わせからの１つ以上の特徴は、いくつかの場合に、その組み合わせから削除可能であり、請求されている組み合わせは、サブコンビネーション又はサブコンビネーションの変形に向けられてもよい。

【0478】

同様に、動作は、特定の順序で図面において表されているが、これは、所望の結果を達成するために、そのような動作が、示されているその特定の順序で、又は順次的な順序で実行されること、あるいは、表されている全ての動作が実行されることを求めている、と理解されるべきではない。さらに、本明細書に記載されている実施形態における様々なシステムコンポーネントの分離は、全ての実施形態でそのような分離を求めている、と理解されるべきではない。

【0479】

ほんのわずかの実施及び例が説明されており、他の実施、強化及び変形は、本明細書で記載及び例示されているものに基づいて行われ得る。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24A】

【図24B】

【図25】

【図26】

【図27】

【図28】

【手続補正書】

【提出日】2024-10-10

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

ビデオデータを処理する方法であって、
ビデオのピクチャのビデオ領域と該ビデオのビットストリームとの間での変換のために、第１のシンタックス要素に基づいて前記ピクチャに対してコーディングツールが無効かどうかを判定することと、
前記判定に基づいて前記変換を行うことと、
を含み、
前記ピクチャに対して前記コーディングツールが無効かどうかを示す前記第１のシンタックス要素はピクチャヘッダでシグナリングされる、方法。

【請求項2】

前記ピクチャよりも小さいビデオユニットのために前記コーディングツールが無効か又は有効かは前記第１のシンタックス要素及び／又は前記ビデオのスライスタイプに依存する、請求項１に記載の方法。

【請求項3】

前記第１のシンタックス要素が真の場合、前記コーディングツールは前記ピクチャに対して無効である、請求項１又は２に記載の方法。

【請求項4】

前記第１のシンタックス要素が偽の場合、前記コーディングツールは前記ピクチャに対して有効である、請求項１乃至３のいずれか一項に記載の方法。

【請求項5】

前記コーディングツールは、前記ピクチャ内の全てのサンプルに対して無効又は有効である、請求項１乃至４のいずれか一項に記載の方法。

【請求項6】

前記第１のシンタックス要素が前記ピクチャヘッダでシグナリングされるかどうかは、前記ビデオ領域に関連するシーケンスパラメータセット（ＳＰＳ）内の１つ以上のシンタックス要素に依存する、請求項１乃至５のいずれか一項に記載の方法。

【請求項7】

前記１つ以上のシンタックス要素は前記ピクチャヘッダに前記第１のシンタックス要素が存在することを示す第２のシンタックス要素と、前記コーディングツールが前記ビデオのシーケンスに対して有効かどうかを示す第３のシンタックス要素とを含む、請求項６に記載の方法。

【請求項8】

前記第２のシンタックス要素は、前記第３のシンタックス要素に基づいて、前記ＳＰＳで条件的にシグナリングされる、請求項７に記載の方法。

【請求項9】

前記第２のシンタックス要素が真の場合、前記第１のシンタックス要素が前記ピクチャヘッダでシグナリングされ、前記コーディングツールが前記ビデオのシーケンスに対して有効の場合、前記第２のシンタックス要素が前記ＳＰＳ内でシグナリングされる、請求項７又は８に記載の方法。

【請求項10】

前記第１のシンタックス要素及び／又は前記第２のシンタックス要素は１ビットでコード化されている、請求項７乃至９のいずれか一項に記載の方法。

【請求項11】

前記コーディングツールは、
アフィンモードでコード化された現在のビデオブロックのサブブロックの初期予測サンプルを生成することと、
オプティカルフロー演算を適用し、動きベクトルの差ｄＭｖＨ及び／又はｄＭｖＶに基づいて予測精密化を導出することにより、前記サブブロックの最終予測サンプルを生成することであって、ｄＭｖＨ及びｄＭｖＶは、水平方向及び垂直方向に沿った動きベクトルの差を示す、ことと、
のために用いられる第１のコーディングツールを含む、請求項１乃至１０のいずれか一項に記載の方法。

【請求項12】

前記コーディングツールは、シグナリングされた動きベクトルに対するオフセットを有する少なくとも１つの動きベクトルに基づいて該シグナリングされた動きベクトルの精密化のために用いられる第２のコーディングツールを含む、請求項１乃至１０のいずれか一項に記載の方法。

【請求項13】

前記コーディングツールは、現在のブロックの参照ブロック内のサンプルに対応する少なくとも１つの勾配値に基づいて動きベクトルの精密化を得るために用いられる第３のコーディングツールを含む、請求項１乃至１０のいずれか一項に記載の方法。

【請求項14】

前記変換は、前記ビデオを前記ビットストリームにエンコードすることを含む、請求項１乃至１３のいずれか一項に記載の方法。

【請求項15】

前記変換は、前記ビデオを前記ビットストリームからデコードすることを含む、請求項１乃至１３のいずれか一項に記載の方法。

【請求項16】

プロセッサと、命令が記憶された非一時的メモリとを含む、ビデオデータを処理するための装置であって、前記命令は前記プロセッサによって実行された場合、前記プロセッサに、
ビデオのピクチャのビデオ領域と該ビデオのビットストリームとの間での変換のために、第１のシンタックス要素に基づいて前記ピクチャに対してコーディングツールが無効かどうかを判定することと、
前記判定に基づいて前記変換を行うことと、
を行わせ、
前記ピクチャに対して前記コーディングツールが無効かどうかを示す前記第１のシンタックス要素はピクチャヘッダでシグナリングされる、装置。

【請求項17】

命令が記憶された非一時的コンピュータ読み取り可能記憶媒体であって、該命令はプロセッサに、
ビデオのピクチャのビデオ領域と該ビデオのビットストリームとの間での変換のために、第１のシンタックス要素に基づいて前記ピクチャに対してコーディングツールが無効かどうかを判定することと、
前記判定に基づいて前記変換を行うことと、
を行わせ、
前記ピクチャに対して前記コーディングツールが無効かどうかを示す前記第１のシンタックス要素はピクチャヘッダでシグナリングされる、非一時的コンピュータ読み取り可能記憶媒体。

【請求項18】

ビデオ処理装置によって行われる方法によって生成されるビデオのビットストリームを記憶する非一時的コンピュータ読み取り可能記録媒体であって、該方法は、
前記ビデオのピクチャのビデオ領域について、第１のシンタックス要素に基づいて前記ピクチャに対してコーディングツールが無効かどうかを判定することと、
前記判定に基づいて前記ビデオのビットストリームを生成することと、
を含み、
前記ピクチャに対して前記コーディングツールが無効かどうかを示す前記第１のシンタックス要素はピクチャヘッダでシグナリングされる、非一時的コンピュータ読み取り可能記憶媒体。

【手続補正2】

【補正対象書類名】明細書

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【発明の詳細な説明】

【技術分野】

【0001】

［関連出願の相互参照］
本願は、２０１９年１０月１２日に出願された国際特許出願第ＰＣＴ／ＣＮ２０１９／１１０９０５号の優先権及び利益を適時に主張する、２０２０年１０月１２日に出願された国際特許出願第ＰＣＴ／ＣＮ２０２０／１２０２８７号に基づく特願２０２２－５２１５８５号の分割出願である。前述の出願の全ては、その全体が参照により本特許出願に組み込まれる。

【0002】

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

【背景技術】

【0003】

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

【発明の概要】

【課題を解決するための手段】

【0004】

デジタルビデオコーディング、特にビデオコーディングのためのアダプティブループフィルタリングに関連する装置、システム及び方法を説明する。説明する方法は、既存のビデオコーディング規格（例えば、高効率ビデオコーディング（ＨＥＶＣ））及び将来のビデオコーディング規格（例えば、汎用ビデオコーディング（ＶＶＣ））又はコーデックの両方に適用され得る。

【0005】

ビデオコーディング規格は、周知のＩＴＵ－Ｔ及びＩＳＯ/ＩＥＣ規格の開発を通じて主に発展してきた。ＩＴＵ－ＴはＨ．２６１及びＨ.２６３を作り出し、ＩＳＯ/ＩＥＣはＭＰＥＧ－１及びＭＰＥＧ－４ Ｖｉｓｕａｌを作り出し、２つの組織はＨ．２６２/ＭＰＥＧ－２ Ｖｉｄｅｏ及びＨ．２６４/ＭＰＥＧ－４ Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）及びＨ．２６５/ＨＥＶＣ規格を共同で作り出した。Ｈ．２６２以来、ビデオコーディング規格は、時間的予測と変換コーディングが利用されるハイブリッドビデオコーディング構造に基づく。ＨＥＶＣを越えた将来のビデオコーディング技術を探求するため、２０１５年にＶＣＥＧ及びＭＰＥＧによって共同でＪＶＥＴ（Joint Video
Exploration Team）が設立された。それ以来、JVETによって多くの新たな方法が採用され、ＪＥＭ（Joint Exploration Model）という名称の参照ソフトウェアに入れられている。２０１８年４月には、ＨＥＶＣに比べて５０％のビットレート低減を目指すＶＶＣ規格に取り組むためにＶＣＥＧ（Ｑ６／１６）とＩＳＯ／ＩＥＣ ＪＴＣ１ ＳＣ２９／ＷＧ１１（ＭＰＥＧ）との間でＪＶＥＴ（Joint Video Expert Team）が発足された。

【0006】

代表的な一態様では、開示の技術はビデオ処理のための方法を提供するために用いられ、当該方法は、ビデオのピクチャのビデオ領域と該ビデオのコード化表現との間での変換のために、該コード化表現におけるビデオ領域を表すために用いられるコーディングツールの有効状態を判定することと、前記判定に従って前記変換を行うこと、とを含み、前記ピクチャのための前記コーディングツールの有効状態を示すために、第１のフラグがピクチャヘッダに含まれている。

【0007】

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

【0008】

さらに別の代表的な態様では、上述の方法を実行するように又は行うように構成された装置が開示される。装置は、本方法を実施するようにプログラムされたプロセッサを含み得る。

【0009】

さらに別の代表的な態様では、ビデオデコーダ装置は、本明細書で説明される方法を実施し得る。

【0010】

開示する技術の上記の及び他の態様及び特徴は、図面、明細書及び特許請求の範囲でより詳細に説明されている。

【図面の簡単な説明】

【0011】

【図1】図１は、異なる解像度でコード化された同じコンテンツの２つの表現のアダプティブストリーミングの例を示す。

【図2】図２は、異なる解像度でコード化された同じコンテンツの２つの表現のアダプティブストリーミングの例を示す。

【図3】図３は、２つの表現のオープンＧＯＰ予測構造の例を示す。

【図4】図４は、オープンＧＯＰ位置での表現スイッチングの例を示す。

【図5】図５は、他のビットストリームからの再サンプリングされた参照ピクチャを参照として用いることによる、ＲＡＳＬピクチャのためのデコーデイングプロセスの例を示す。

【図6】図６Ａ～図６Ｃは、ＭＣＴＳベースのＲＷＭＲビューポート依存３６０°ストリーミングの例を示す。

【図7】図７は、異なるＩＲＡＰ間隔及び異なるサイズのコロケートされたサブピクチャ表現の例を示す。

【図8】図８は、視聴向きの変化によって解像度の変化がもたらされた場合に受信されたセグメントの例を示す。

【図9】図９は、図６と比較して、わずかに上方に且つ右側の立方面の方への視聴向きの変化の例を示す。

【図10】図１０は、２つのサブピクチャ位置のためのサブピクチャ表現が示される実施の例を示す。

【図11】図１１はＡＲＣエンコーダの実施を示す。

【図12】図１２はＡＲＣデコーダの実施を示す。

【図13】図１３は、ＡＲＣのためのタイル群ベースの再サンプリングの例を示す。

【図14】図１４は、適応的解像度変更の例を示す。

【図15】図１５は、ＣＵのためのＡＴＭＶＰ動き予測の一例を示す。

【図16】図１６Ａ及び図１６Ｂは、単純化された４パラメータアフィン動きモデル及び単純化された６パラメータアフィン動きモデルの例をそれぞれ示す。

【図17】図１７は、サブブロック当たりのアフィンＭＶＦの例を示す。

【図18】図１８Ａ及び図１８Ｂは、４パラメータアフィンモデル及び６パラメータアフィンモデルの例をそれぞれ示す

【図19】図１９は、継承されたアフィン候補についてのＡＦ＿ＩＮＴＥＲに対するＭＶＰ（Motion Vector Difference）を示す。

【図20】図２０は、構築されたアフィン候補についてのＡＦ＿ＩＮＴＥＲに対するＭＶＰを示す。

【図21】図１Ａ及び図２１Ｂは、５つの隣接ブロック及びＣＰＭＶ予測子の導出をそれぞれ示す。

【図22】図２２は、アフィンマージモードの候補位置の例を示す。

【図23】図２３は、開示の技術に係るビデオ処理のための例示の方法のフローチャートを示す。

【図24A】図２４Ａは、本願で説明するビジュアルメディアデコーデイング又はビジュアルメディアエンコーディング技術を実施するためのハードウェアプラットフォームの例のブロック図である。

【図24B】図２４Ｂは、本願で説明するビジュアルメディアデコーデイング又はビジュアルメディアエンコーディング技術を実施するためのハードウェアプラットフォームの例のブロック図である。

【図25】図２５は、例示のビデオコーディングシステムを示すブロック図である。

【図26】図２６は、開示の技術の一部の実施形態に係るエンコーダを示すブロック図である。

【図27】図２７は、開示の技術の一部の実施形態に係るデコーダを示すブロック図である。

【図28】図２８は、開示の技術の一部の実施形態に係るビデオ処理の例示の方法のフローチャートを示す。

【発明を実施するための形態】

【0012】

本願で開示する技術及び装置は、適応的解像度変更（ａｄａｐｔｉｖｅ ｒｅｓｏｌｕｔｉｏｎ ｃｈａｎｇｅ）有するコーディングツールを提供する。ＡＶＣ及びＨＥＶＣは、ＩＤＲ又はイントラランダムアクセスポイント（ＩＲＡＰ）ピクチャを導入する必要なしに解像度を変更する能力を有していない。そのような能力は、適応的解像度変更（ＡＲＣ）と呼ぶことができる。ＡＲＣ機能から恩恵を受けるユースケース又は適用シナリオとしては以下が挙げられる。

【0013】

－テレビ電話及び会議におけるレート適応：変化するネットワーク条件にコード化されたビデオを適応させるために、ネットワーク条件が悪化し、利用可能な帯域幅が小さくなると、エンコーダは、より小さな解像度のピクチャをエンコードすることにより、それに適応し得る。現在、ピクチャの解像度の変更はＩＲＡＰピクチャの後にのみ行うことができるが、これにはいくつかの問題がある。妥当な品質のＩＲＡＰピクチャは、インターコード化ピクチャよりもはるかに大きく、それに対応してデコードするのがより複雑である。これには時間及びリソースがかかる。これは、負荷の理由でデコーダによって解像度の変更が要求された場合に問題となる。また、低遅延のバッファ条件を壊し、オーディオの再同期が強制され、ストリームのエンドツーエンド遅延が少なくとも一時的に増加することになる。これにより、ユーザ体験が悪くなり得る。

【0014】

－マルチパーティビデオ会議におけるアクティブスピーカの変更：マルチパーティビデオ会議の場合、アクティブスピーカは、残りの会議参加者のビデオよりも大きなビデオサイズで表示させるのが一般的である。アクティブスピーカが変更されると、各参加者のピクチャ解像度も調整する必要があり得る。ＡＲＣ機能の必要性は、そのようなアクティブスピーカにおける変更が頻繁に行われる場合により重要となる。

【0015】

－ストリーミングにおけるファストスタート：ストリーミングアプリケーションの場合、アプリケーションが表示を開始する前に、特定の長さのデコードされたピクチャまでバッファリングを行うことが一般的である。解像度がより小さいビットストリームを開始することは、アプリケーションが表示をより早く開始するのに十分なピクチャをバッファ内に有することを可能にする。

【0016】

ストリーミングにおける適応的ストリーム切り替え：ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）規格は@mediaStreamStructureIdと名前の機能を含む。これは、例えば、HEVCにおいて関連するＲＡＳＬピクチャを有するＣＲＡピクチャのような、デコード不可能なリーディングピクチャを有するオープンGOPランダムアクセスポイントにおける異なる表現間のスイッチングを可能にする。同じビデオの２つの異なる表現が異なるビットレートを有するが、同じ空間分解能を有する一方で、それらが同じ値の@mediaStreamStructureIdを有する場合、関連するＲＡＳＬピクチャとＣＲＡピクチャの２つの表現の間でスイッチングを行うことができ、ＣＲＡピクチャでのスイッチングに関連するＲＡＳＬピクチャを許容可能な品質でデコードできるため、シームレスなスイッチングが可能になる。ＡＲＣでは、@mediaStreamStructureId機能は、空間分解能が異なるDASH表現間の切り替えのためにも用いることができる。

【0017】

ＡＲＣは動的解像度変換としても知られている。

【0018】

ＡＲＣは、Ｈ．２６３ Ａｎｎｅｘ Ｐ等の参照ピクチャ再サンプリング（ＲＰＲ）の特殊なケースとしても見なされ得る。

【0019】

１．１ Ｈ．２６３ Ａｎｎｅｘ Ｐにおける参照ピクチャ再サンプリング
このモードは、参照ピクチャを、予測のためのその使用の前にワーピングするアルゴリズムを記述する。これは、予測されるピクチャとは異なるソースフォーマットを有する参照ピクチャを再サンプリングするのに有用であり得る。これは、参照ピクチャの形状、サイズ及び位置をワーピングすることにより、全体的な動き推定又は回転動作の推定に用いることもできる。シンタックスは、用いられるべきワーピングパラメータ及び再サンプリングアルゴリズムを含む。参照ピクチャ再サンプリングモードの最も単純なレベルの動作は、アップサンプリング及びダウンサンプリングプロセスにＦＩＲフィルタを適用するだけでだけでいいことから、暗黙的係数が４の再サンプリング（implicit factor of 4 resampling）である。この場合、（ピクチャヘッダで示される）新たなピクチャのサイズが前のピクチャのサイズと異なる場合にその使用が理解されるため、追加のシグナリングオーバーヘッドが必要ではない。

【0020】

１．２ ＶＶＣに対するＡＲＣの寄与
１．２．１ ＪＶＥＴ－Ｍ０１３５
ＪＣＴＶＣ－Ｆ１５８から一部を抜粋した、以下で説明するＡＲＣの予備的な設計は、議論を引き起こすためだけのプレースホルダであることが示唆されている。

【0021】

２．２．１．１ 基本ツールの説明
ＡＲＣをサポートするための基本ツールの制約は次のとおりである。
－空間分解能は、両方の寸法に適用される係数０.５だけ公称分解能と異なり得る。空間分解能は増減してもよく、０.５及び２.０の倍率が得られる。
－ビデオフォーマットのアスペクト比及びクロマフォーマットは変更されない。
－クロッピング面積は空間分解能に比例してスケーリングされる。
－参照ピクチャは必要に応じて単純に再スケーリングされ、インター予測は従来どおり適用される。

【0022】

２．２．１．２ スケーリング動作
単純なゼロ相の分離可能なダウン及びアップスケーリングフィルタを用いることが提案される。なお、これらのフィルタは予測専用であり、デコーダは出力のためにより高度なスケーリングを用いり得る。

【0023】

以下の１：２ダウンスケーリングフィルタが用いられ、ゼロ相及び５タップを有する：
（－１、９、１６、９、－１）／３２

【0024】

ダウンサンプリング点は偶数サンプル位置にあり、共に置かれている（co-sited）。同じフィルタがルーマ及びクロマに用いられる。

【0025】

２：１アップサンプリングのために、奇数グリッド位置にある追加サンプルが、最新のＶＶＣ ＷＤにおける半画素動き補償補間フィルタ係数を用いて生成される。

【0026】

組み合わされたアップ及びダウンサンプリングは、クロマサンプリング点の位置又は位相を変化させない。

【0027】

２．２．１．２ パラメータ集合における解像度記述
ＳＰＳにおけるピクチャ解像度のシグナリングは以下のように変更される。変更のうち、削除される部分は二重括弧でマークされている(例えば、［［ａ］］は文字「ａ」の削除を意味する)。

【0028】

【表1】

【0029】

[[pic_width_in_luma_samplesは、各デコードされたピクチャの幅をルーマサンプルの単位で指定する。pic_width_in_luma_samplesは０と等しくなく、そしてＭｉｎＣｂＳｉｚｅＹの整数倍とする。
pic_height_in_luma_samplesは、各デコードされたピクチャの高さをルーマサンプルの単位で指定する。pic_height_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。］］

【0030】

num_pic_size_in_luma_samples_minus１ plus １は、ピクチャサイズ（幅及び高さ）の数を、コード化ビデオシーケンスに存在し得るルミナンスサンプルの単位で指定する。

【0031】

pic_width_in_luma_samples[i]は、デコードされたピクチャのｉ番目の幅を、コード化ビデオシーケンスに存在し得るルミナンスサンプルの単位で指定する。pic_width_in_luma_samples[i]は０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。

【0032】

pic_height_in_luma_samples[i] は、デコードされたピクチャのｉ番目の高さを、コード化ビデオシーケンスに存在し得るルミナンスサンプルの単位で指定する。pic_height_in_luma_samples[i]は０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。

【0033】

【表2】

【0034】

pic_size_idxはシーケンスパラメータセットのｉ番目のピクチャサイズへのインデックスを指定する。ピクチャパラメータセットを参照するピクチャの幅は、ルーマサンプルにおけるpic_width_in_luma_samples[pic_size_idx]である。同様に、ピクチャパラメータセットを参照するピクチャの高さは、ルーマサンプルにおけるpic_height_in_luma_samples[pic_size_idx]である。

【0035】

１．２．２ ＪＶＥＴ－Ｍ０２５９
１．２．２．１ 背景:サブピクチャ
サブピクチャトラックという用語はＯＭＡＦ（Omnidirectional Media Format）において以下のように定義される:トラックは、他のトラックと空間関係を有し、オリジナルのビデオコンテンツの空間的サブセットを表すトラックであって、コンテンツ制作側でビデオエンコーディングを行う前に空間的サブセットに分割されている。ＨＥＶＣのためのサブピクチャトラックは、それが自立型ＨＥＶＣビットストリームになるように、モーション制約タイルセットのためのパラメータセット及びスライスセグメントヘッダを書き換えることによって構築できる。サブピクチャ表現は、サブピクチャトラックを保持するＤＡＳＨ表現として定義できる。

【0036】

ＶＶＣのための空間分割単位としてサブピクチャという用語を用いるＪＶＥＴ－Ｍ０２６１は以下のように要約される。
１． 写真は、サブピクチャ、タイルグループ及びタイルに分割される。
２． サブピクチャは、tile_group_addressが０のタイルグループで始まるタイルグループの長方形のセットである。
３． 各サブピクチャは、それ自身のＰＰＳを参照してもよく、故にそれ自身のタイル分割を有し得る。
４． サブピクチャはデコーディングプロセスでピクチャの様に扱われる。
５． サブピクチャをデコーディングするための参照ピクチャは、デコードされたピクチャバッファ内の参照ピクチャから、現在のサブピクチャと同一場所にある領域を抽出することにより生成される。抽出された領域はデコードされたサブピクチャである。すなわち、ピクチャ内の同じサイズ及び同じ位置のサブピクチャ間でインター予測が行われる。
６． タイルグループは、サブピクチャのタイルラスタスキャンにおける一連のタイルである。

【0037】

この寄稿では、サブピクチャという用語は、ＪＶＥＴＭ０２６１で定義されているものとして理解することができる。しかしながら、ＪＶＥＴＭ０２６１で定義されているサブピクチャシーケンスをカプセル化するトラックは、ＯＭＡＦで定義されているサブピクチャトラックと非常に類似した特性を有する。以下の例は両方の場合に適用される。

【0038】

１．２．２．２ 使用事例
１．２．２．２．１ ストリーミングにおける適応的解像度変更
アダプティブストリーミングのサポートのための要件
ＭＰＥＧ Ｎ１７０７４のセクション５.１３（「アダプティブストリーミングのサポートのための要件」）はＶＶＣのための以下の要件を含む：それぞれが異なる特性（例えば、空間分解能又はサンプルビット深度）を有する同一コンテンツの複数の表現を提供するアダプティブストリーミングサービスの場合、規格は高速な表現スイッチングをサポートするものとする。規格は、異なる空間分解能等の異なる特性の表現の間の高速且つシームレスな表現スイッチング能力を損なうことなく、効率的な予測構造（例えば、所謂オープンピクチャ群）の使用を可能にするものとする。

【0039】

表現スイッチングを伴うオープンＧＯＰ予測構造の例
アダプティブビットレートストリーミングのためのコンテンツ生成は、異なる空間分解能を有することができる異なる表現の生成を含む。クライアントは表現からセグメントを要求し、故にどの解像度及びビットレートでコンテンツを受信するかを決定できる。クライアントでは、異なる表現のセグメントが連結され、デコードされ、再生される。クライアントは、１つのデコーダインスタンスでシームレスな再生を実現できる必要がある。（ＩＤＲピクチャで始まる）クローズドＧＯＰ構造は、図１に示すように従来的に用いられる。図１は、異なる解像度でコード化された同じコンテンツの２つの表現のアダプティブストリーミングを示す。

【0040】

（ＣＲＡピクチャで始まる）オープンＧＯＰ予測構造は、それぞれのクローズドＧＯＰ予測構造よりも優れた圧縮性能を可能にする。例えば、間隔が２４のピクチャのＩＲＡＰピクチャで、ルーマＢｊｏｎｔｅｇａａｒｄデルタビットレートに関して５.６％の平均ビットレート削減が得られた。便宜上、［２］のシミュレーション条件及び結果をセクションＹＹで要約する。

【0041】

オープンＧＯＰ予測構造は、品質が主観的に可視的なポンピングを低減すると報告されている。

【0042】

ストリーミングにおいてオープンＧＯＰを用いることの課題は、表現をスイッチングした後にＲＡＳＬピクチャを正しい参照ピクチャでデコードできないことである。表現に関するこの課題は、異なる解像度でコード化された同じコンテンツの２つの表現のアダプティブストリーミングを示す図２に示されている。図２において、セグメントは、クローズドＧＯＰ又はオープンＧＯＰ予測構造のいずれかを用いる。

【0043】

ＣＲＡピクチャで始まるセグメントは、少なくとも１つの参照ピクチャが前のセグメントにあるＲＡＳＬピクチャを含む。これは、２つの表現のオープンＧＯＰ予測構造を示す図３に示す。図３において、両方のビットストリームにおけるピクチャ０は前のセグメントに存在し、ＲＡＳＬピクチャを予測するための参考として用いられている。

【0044】

図２において破線の矩形でマークされた表現スイッチングは、オープンＧＯＰ位置での表現スイッチングを示す図４で以下に示す。ＲＡＳＬピクチャの参照ピクチャ（「ピクチャ０」）はデコードされていないことが分かる。その結果、ＲＡＳＬピクチャはデコードできず、ビデオの再生にギャップがある。

【0045】

しかしながら、再サンプリングされた参照ピクチャでＲＡＳＬ画像をデコードすることが主観的に受け入れられることが分かっている。セクション４を参照。「ピクチャ０」を再サンプリングし、それをＲＡＳＬピクチャをデコードするための参照ピクチャとして用いることを図５に示す。図５は、他方のビットストリームから再サンプリングされた参照ピクチャを参照として用いることによる、ＲＡＳＬピクチャのデコーディングプロセスを示す。

【0046】

２．２．２．２．２ リージョンワイズ混合解像度（ＲＷＭＲ）３６０°ビデオストリーミングにおけるビューポート変更
背景：ＨＥＶＣベースのＲＷＭＲストリーミング
ＲＷＭＲ３６０°ストリーミングは、向上された効果的なビューポート有効空間分解能を提供する。ビューポートをカバーするタイルが、「４Ｋ」のデコーディング能力（ＨＥＶＣレベル５．１）を有する、図６に示す６Ｋ（６１４４×３０７２）のＥＲＰピクチャ又は同等のＣＭＰ解像度に由来するスキームはＯＭＡＦのＤ．６．３項及びＤ．６．４項に含まれており、ＶＲ産業フォーラムのガイドラインでも採用されている。そのような解像度はクワッドＨＤ（２５６０×１４４０）ディスプレイパネルを用いたヘッドマウントディスプレイに適していると主張されている。

【0047】

エンコーディング：コンテンツは、キューブ面サイズ（cube face size）がそれぞれ１５３６×１５３６及び７６８×７６８である２つの空間分解能でエンコードされている。両方のビットストリームにおいて、６×４のタイルグリッドが用いられ、各タイル位置に動き制約タイルセット（ＭＣＴＳ）がコード化されている。

【0048】

カプセル化：各ＭＣＴＳシーケンスはサブピクチャトラックとしてカプセル化され、ＤＡＳＨのサブピクチャ表現として利用可能にされる。

【0049】

ストリーミングされるＭＣＴＳの選択：高解像度ビットストリームから１２のＭＣＴＳが選択され、相補的な１２のＭＣＴＳが低解像度ビットストリームから抽出される。そのため、ストリーミングされるコンテンツの半球（１８０°×１８０°）は高解像度ビットストリームに由来する。

【0050】

デコードすべきビットストリームへのＭＣＴＳのマージ：単一の時間インスタンスの受信されたＭＣＴＳは、ＨＥＶＣレベル５.１に準拠する１９２０×４６０８のコード化ピクチャにマージされる。マージされたピクチャのための別のオプションは、３８４０×２３０４ルーマサンプルのピクチャになる、幅７６８の４つのタイル列、幅３８４の２つのタイル列及び高さ７６８の３のタイル列のルーマサンプルを有することである。

【0051】

図６は、ＭＣＴＳベースのＲＷＭＲビューポート依存の３６０°ストリーミングの例を示す。図６Ａはコード化ビットストリームの例を示し、図６Ｂはストリーミングのために選択されたＭＣＴＳの例を示し、図６Ｃは、ＭＣＴＳからマージされたピクチャの例を示す。

【0052】

背景：ビューポート依存３６０°ストリーミングのための異なるＩＲＡＰ間隔のいくつかの表現
ＨＥＶＣベースのビューポート依存の３６０°ストリーミングにおいて視聴向きが変化した場合、サブピクチャ表現の新たな選択は次のＩＲＡＰ整列セグメント境界で有効になる。デコーディングのためにサブピクチャ表現はコード化されたピクチャにマージされ、故に選択された全てのサブピクチャ表現でＶＣＬ ＮＡＬユニットタイプが整列される。

【0053】

視聴向きの変化に反応する応答時間と視聴方向が安定しているときのレート歪み性能との間でトレードオフを提供するために、異なるＩＲＡＰ間隔で複数のバージョンのコンテンツをコード化できる。これは、図６に示すエンコーディングのための１組の配列されたサブピクチャ表現について図７に示されており、Ｈ． Ｃｈｅｎ、 Ｈ． Ｙａｎｇ、 Ｊ． Ｃｈｅｎの「サブブロックマージ候補のための別のリスト」（ＪＶＥＴ－Ｌ０３６８、２０１８年１０月）の３節で詳細に論じられている。

【0054】

図７は、異なるＩＲＡＰ間隔及び異なるサイズの配列されたサブピクチャ表現の例を示す。

【0055】

図８は、サブピクチャ位置が先ずより低い解像度（３８４×３８４）で受信されるように選択される例を示す。視聴向きを変化は、サブピクチャ位置がより高い解像度（７６８×７６８）で受信される新たな選択をもたらす。図８の例では、視聴向きの変化が解像度の変化を引き起こすときに受信されるセグメントはセグメント４の先頭にある。この例では、視聴向きの変化が起こるため、セグメント４が短いＩＲＡＰ間隔のサブピクチャ表現から受信される。その後、視聴方向は安定するため、セグメント５以降からはＩＲＡＰ間隔が長いバージョンを用いることができる。

【0056】

全てのサブピクチャ位置を更新することの難点
典型的な視聴状況では、視聴向きは徐々に移動するため、解像度は、ＲＷＭＲビューポート依存ストリーミングにおけるサブピクチャ位置のサブセットのみで変化する。図９は、図６から僅かに上方に且つ右側のキューブ面の方に変化した視聴向きを示す。先のものとは解像度が異なるキューブ面区画を「Ｃ」で示す。２４のキューブ面区画のうち６つで解像度が変化したことが分かる。しかしながら、上述したように、ＩＲＡＰピクチャで始まるセグメントは、視聴向きの変化に応答して２４のキューブ面区画の全てに対して受信される必要がある。ＩＲＡＰピクチャで始まるセグメントで、全てのサブピクチャ位置を更新することは、ストリーミングレート歪み性能の観点から非効率的である。

【0057】

加えて、レート歪み性能を改善し、クローズドＧＯＰ予測構造によって引き起こされる可視的なピクチャ品質のポンピングを回避するために、ＲＷＭＲ３６０°ストリーミングのサブピクチャ表現でオープンＧＯＰ予測構造を用いることができることが望ましい。

【0058】

提案する設計例
以下の設計目標を提案する。
１． ＶＶＣ設計は、ランダムアクセスピクチャに由来するサブピクチャと、非ランダムアクセスピクチャに由来する別のサブピクチャを、ＶＶＣに準拠する同じコード化ピクチャにマージできるようにすべきである。
２． ＶＶＣ設計は、異なる空間分解能等の異なるプロパティのサブピクチャ表現間の高速且つシームレスな表現スイッチング能力を損なうことなく、サブピクチャ表現におけるオープンＧＯＰ予測構造の使用を可能にしながら、サブピクチャ表現を単一のＶＶＣビットストリームにマージできるようにすべきである。

【0059】

設計目標の例は、２つのサブピクチャ位置についてのサブピクチャ表現が示される図１０に示すことができる。双方のサブピクチャの場所について、コンテンツの別々のバージョンが、２つの解像度及び２つのランダムアクセス間隔のうちの各組み合わせに対してコード化される。セグメントの一部は、オープンＧＯＰ予測構造から始まる。視聴向きの変化によって、サブピクチャ位置１の解像度がセグメント４の始まりで切り替わる。セグメント４は、ＲＡＳＬピクチャに関連するＣＲＡピクチャで始まるため、セグメント３にあるＲＡＳＬピクチャの参照ピクチャを再サンプリングする必要がある。なお、この再サンプリングはサブピクチャ位置１に適用されるが、他の一部のサブピクチャ位置のデコードされたサブピクチャは再サンプリングされない。この例では、視聴向きの変化は、サブピクチャ位置２の解像度の変化を引き起こさないため、サブピクチャ位置２のデコードされたサブピクチャは再サンプリングされない。セグメント４の最初のピクチャでは、サブピクチャ位置１のセグメントはＣＲＡピクチャに由来するサブピクチャを含むのに対して、サブピクチャ位置２のセグメントは非ランダムアクセスピクチャに由来するサブピクチャを含む。コード化ピクチャへのこれらのサブピクチャのマージはＶＶＣで可能であることが示唆されている。

【0060】

２．２．２．２．３ テレビ会議における適応的解像度変更
ＪＣＴＶＣ―Ｆ１５８は、主にビデオ会議のための適応的解像度変更を提案する。以下のサブセクションがＪＣＴＶＣ－Ｆ１５８からコピーされ、適応的解像度変更が有用であると主張される使用事例を示す。

【0061】

シームレスなネットワーク適応及びエラー耐性
ビデオ会議やパケットネットワークを介したストリーミング等の用途は、特にビットレートが高すぎてデータが失われる場合に、エンコードされたストリームが変化するネットワーク条件に適応することがしばしば必要になる。そのような用途は、エンコーダがエラーを検出し、調整を行うことを可能にするリターンチャネルを通常有する。エンコーダは、時間的又は空間的のいずれかのビットレートの低減及び解像度変更という２つの主なツールを使える。時間分解能変更は、階層的予測構造を用いたコーディングによって効果的に実現できる。しかしながら、最良の品質のためには、ビデオ通信のための適切に設計されたエンコーダの一部に加えて、空間分解能の変更が必要である。

【0062】

ＡＶＣ内で空間解像度を変更する場合、ＩＤＲフレームが送信され、ストリームがリセットされる必要がある。これは重大な問題をもたらす。妥当な品質のＩＤＲフレームはインターピクチャよりもはるかに大きく、それに対応してデコードするのがより複雑になる。これには時間及びリソースがかかる。負荷の理由でデコーダによって解像度の変更が要求された場合にこれは問題となる。また、低遅延バッファ条件が崩れて、オーディオの再同期が強制され、ストリームのエンドツーエンド遅延が少なくとも一時的に増加し得る。これは、ユーザ体験の悪化をもたらす。

【0063】

これらのモダンを最小化に抑えるために、Ｐフレームに対して同様の数のビットを用いてＩＤＲが低品質で通常送信され、所与の解像度のために完全な品質に戻るのにかなりの時間を要する。遅延を十分に小さくするために、品質は実際に非常に低くなることがあり、画像が「再フォーカス」される前に目に見えるぼやけが生じることが多い。事実上、イントラフレームは圧縮条件ではほとんど役に立たない。これはストリームを再始動する方法にすぎない。

【0064】

そのため、ＨＥＶＣにおいて、特に困難なネットワーク条件で、主観的経験への影響を最小限に抑えながら解像度の変更を可能にする方法が必要とされている。

【0065】

ファストスタート
最初に許容不能な画像のぼやけを生じることなく、遅延を低減し、通常の品質により迅速に到達するために、第１のフレームが低減された解像度で送信され、次の数フレームにわたって解像度が増大される「ファストスタート」モードを有することは有用であろう。

【0066】

会議「コンポーズ」（Conference “compose”）
ビデオ会議は、話し手がフルスクリーンで表示され、他の参加者がより小さな解像度のウィンドウで表示される機能を有するも多い。これを効率的にサポートするために、より小さなピクチャがより低い解像度で送信されることが多い。この解像度は、参加者がスピーカーになり、フルスクリーンになった場合に高くなる。この時点でイントラフレームを送信すると、ビデオストリームにおいて不快な中断がもたらされる。この効果は話し手が素早く交替する場合に非常に顕著で不快なものになり得る。

【0067】

２.２.２.３ 提案される設計目標
ＶＶＣバージョン１のために以下の高レベルな設計の選択肢が提案されている。

【0068】

１． 以下の使用事例のために、参照ピクチャ再サンプリングプロセスをＶＶＣバージョン１に含めることが提案される。
－異なる空間分解能等特性が異なる表現間の高速でシームレスな表現スイッチング能力を損なうことなく、アダプティブストリーミングにおいて効率的な予測構造（例えば、所謂オープンピクチャ群）を用いること。
－著しい遅延又は遅延変化なしに、ネットワーク条件及びアプリケーションに起因する解像度変化に低遅延の会話型ビデオコンテンツを適応させること。

【0069】

２． ランダムアクセスピクチャに由来するサブピクチャと、非ランダムアクセスピクチャに由来する別のサブピクチャとを、ＶＶＣに準拠する同じコード化ピクチャにマージできるようにするＶＶＣ設計が提案される。これは、混合品質及び混合解像度のビューポートアダプティブ３６０°ストリーミングにおける視聴向きの変化の効率的な対処を可能にするものと断定される。

【0070】

３． サブピクチャワイズ再サンプリングプロセスをＶＶＣバージョン１に含めることが提案される。これは、混合品質及び混合解像度のビューポートアダプティブ３６０°ストリーミングにおける視聴向きの変化の効率的な対処を可能にするものと断定される。

【0071】

２．２．３． ＪＶＥＴ－Ｎ００４８
適応的解像度変更（ＡＲＣ）のための使用事例及び設計目標がＪＶＥＴ―Ｍ０２５９で詳細に論じられている。その要約は以下の通りである。

【0072】

１． リアルタイム通信
適応的解像度変更についての以下の使用事例がＪＣＴＶＣ－Ｆ１５８に当初含まれていた。
ａ．（動的な適応的解像度変更を介した）シームレスなネットワーク適応及びエラー耐性
ｂ．ファストスタート（セッション開始時又はリセット時の解像度の漸増）
ｃ．会議「コンポーズ」(話し手により高い解像度が与えられる)

【0073】

２． アダプティブストリーミング
ＭＰＥＧ Ｎ１７０７４のセクション５.１３（「アダプティブストリーミングのサポート」)にはＶＶＣのための以下の要件が含まれる：それぞれが異なる特性（例えば、空間分解能又はサンプルビット深度）を有する同一コンテンツの複数の表現を提供するアダプティブストリーミングサービスの場合、規格は高速な表現スイッチングをサポートするものとする。規格は、異なる空間分解能等の異なる特性の表現の間の高速且つシームレスな表現スイッチング能力を損なうことなく、効率的な予測構造（例えば、所謂オープンピクチャ群）の使用を可能にするものとする。

【0074】

ＪＶＥＴ－Ｍ０２５９では、リーディングピクチャの参照ピクチャを再サンプリングすることにより、この要件をどのように満たすかが議論されている。

【0075】

３． ３６０°ビューポート依存ストリーミング
ＪＶＥＴ－Ｍ０２５９では、リーディングピクチャの参照ピクチャの特定の独立的にコード化されたピクチャ領域を再サンプリングすることにより、この使用事例をどのように対処するかが議論されている。

【0076】

この貢献は、上記の使用事例及び設計目標の全てを満たすと断定される適応的解像度コーディングアプローチを提案する。３６０°ビューポート依存ストリーミング及び会議「コンポーズ」の使用事例は、（独立したサブピクチャレイヤを提案する）ＪＶＥＴ－Ｎ００４５と共に本提案によって取り扱われる。

【0077】

提案される仕様テキスト
シグナリング

【0078】

【表3】

【0079】

sps_max_rprは、pic_width_in_luma_samples及びpic_height_in_luma_samplesが現在のピクチャのpic_width_in_luma_samples及びpic_height_in_luma_samplesのそれぞれと等しくないＣＶＳにおけるタイルグループの、参照ピクチャリスト０又は１のアクティブ参照ピクチャの最大数を指定する。

【0080】

【表4】

【0081】

【表5】

【0082】

max_width_in_luma_samplesは、このＳＰＳがアクティブであるＣＶＳの任意のピクチャのための任意のアクティブＰＰＳにおけるpic_width_in_luma_samples がmax_width_in_luma_samples 以下であることがビットストリーム適合の要件であることを指定する。

【0083】

max_height_in_luma_samplesは、このＳＰＳがアクティブであるＣＶＳの任意のピクチャのための任意のアクティブＰＰＳにおけるpic_height_in_luma_samples がmax_height_in_luma_samples 以下であることがビットストリーム適合の要件であることを指定する。

【0084】

高レベルデコーディングプロセス
現在の画像CurrPicに対してデコーディング処理は以下のように動作する。
１． ＮＡＬユニットのデコーディングは８．２項で規定されている。
２． ８．３項のプロセスは、タイルグループヘッダレイヤ及び上でシンタックス要素を用いる以下のデコーディングプロセスを規定する。

【0085】

－ピクチャオーダカウントに関する変数及び関数は、８．３．１節で規定されているように導出される。これは、第１のピクチャタイル群に対してのみ呼び出すだけでよい。

【0086】

－非ＩＤＲピクチャの各タイル群に対するデコーディングプロセスの開始時に、８．３．２項に規定の参照ピクチャリスト構成のデコーディング処理が参照ピクチャリスト０（RefPicList[０]）及び参照ピクチャリスト１（RefPicList[１]）の導出のために呼び出される。

【0087】

－８.３.３項における参照ピクチャマーキングのためのデコーディングプロセスが呼び出され、参照ピクチャは「参照のために使用されない（unused for reference）」又は「長期参照のために使用（used for long-term reference）」とマークされ得る。これは、第１のピクチャタイル群に対してのみ呼び出すだけでよい。

【0088】

－pic_width_in_luma_samples又はpic_height_in_luma_samplesが、CurrPicのpic_width_in_luma_samples又はpic_height_in_luma_samplesのそれぞれと等しくないRefPicList[０]及びRefPicList[１]における各アクティブ参照ピクチャについて、以下が適用される。

【0089】

－Ｘ．Ｙ．Ｚ項の再サンプリングプロセスが呼び出され［Ｅｄ．（ＭＨ）:追加すべき呼び出しパラメータの詳細］、出力は入力と同じ参照ピクチャマーキング及びピクチャオーダカウントを有する。

【0090】

－再サンプリングプロセスへの入力として用いられる参照ピクチャは、「参照のために使用されていない」とマークされている。

【0091】

ＣＴＵ（coding tree units）、スケーリング、変換、インループフィルタリング等のためのデコーディングプロセスの呼び出しをさらに論じることができる。

【0092】

現在のピクチャの全てのタイルグループがデコードされた後で、現在のデコードされたピクチャは「短期間の参照のために用いられる（used for short-term reference）」とマークされる。

【0093】

再サンプリングプロセス
ＳＨＶＣ再サンプリングプロセス（ＨＥＶＣのＨ８．１．４．２節）は、以下の追加を伴って提案される。

【0094】

sps_ref_wrapaund_enabled_flag＝０の場合、サンプル値tempArray[n]（ｎ＝０．．７）は以下のように導出される。

【0095】

【数1】

【0096】

それ以外の場合、サンプル値tempArray[n]（ｎ＝０．．７）は以下のように導出される。

【0097】

【数2】

【0098】

sps_ref_wrapaund_enabled_flag＝０の場合、サンプル値tempArray[n]（ｎ＝０．．３）は以下のように導出される。

【0099】

【数3】

【0100】

それ以外の場合、サンプル値tempArray[n]（ｎ＝０．．３）は以下のように導出される。

【0101】

【数4】

【0102】

２.２.４. ＪＶＥＴ－Ｎ００５２
ビデオ圧縮規格における概念である適応的解像度変更は、少なくとも１９９６年以来からあり、特に参照ピクチャの再サンプリング（ＲＰＲ、Ａｎｎｅｘ Ｐ）及び縮小解像度更新（Ａｎｎｅｘ Ｑ）に向けたＨ．２６３＋関連の提案である。先ず、ＪＣＴ－ＶＣ時代にＣｉｓｃｏによって提案され、次いで（今日では適度に広く展開されている）ＶＰ９の文脈で、そしてさらに最近ではＶＶＣの文脈でという流れで、一定の注目を最近集めている。ＡＲＣは、所定のピクチャについてコード化する必要があるサンプルの数を低減し、それが望ましい場合には、結果として得られる参照ピクチャをより高い解像度までアップサンプリングすることを可能にする。

【0103】

特に関心のあるＡＲＣは２つのシナリオで検討される。

【0104】

１）ＩＤＲピクチャ等のイントラコード化ピクチャは、インターピクチャよりもかなり大きいことが多い。理由にかかわらず、イントラコード化を意図したダウンサンプリングピクチャは、将来の予測のためのより良好な入力を提供し得る。また、少なくとも低遅延のアプリケーションでは、速度制御の観点からもこれは明らかに有利である。

【0105】

２）少なくとも一部のケーブル及び衛星オペレータが日常的に行っているように、コーデックをそのブレーキングポイントの近くで動作させる場合、ＡＲＣは、ハーな遷移点を伴わないシーン遷移等の非イントラコード化ピクチャに対してさえも便利になり得る。

【0106】

３）多分前向きになりすぎている（Looking perhaps a bit too much forward）：固定解像度の概念は概して正当可能であろうか？ＣＲＴからの離脱とレンダリング装置におけるスケーリングエンジンの普及に伴い、レンダリングとコーディング解像度とのハードバインドは過去のものである。また、ビデオシーケンスにおいて多くのアクティビティが行われている場合、たとえそのアクティビティが空間的に他の場所で行われていても、大半の人は（おそらくは高解像度に関連する）細部に集中できないことを示唆する利用可能な研究がある。もしそれが正しく且つ一般に受け入れられていれば、細かい粒度分解能の変化は適応的ＱＰよりも優れた速度制御メカニズムになり得る。この点については現在議論されている。固定解像度ビットストリームの概念を取り除くことは、無数のシステム層及び実施のインプリケーションがあり、（少なくとも、それらの詳細な性質ではないにしても、それらの存在レベルでは）よく知られている。

【0107】

技術的に、ＡＲＣは参照ピクチャ再サンプリングとして実施することができる。参照ピクチャ再サンプリングの実施には、再サンプリングフィルタ及びビットストリームにおける再サンプリング情報のシグナリングという２つの主要な側面がある。本願は後者に焦点を当て、実施経験がある程度に前者に触れる。適切なフィルタ設計のさらなる研究が奨励され、提供される素案の設計を実質的に改善する点に関して、Ｔｅｎｃｅｎｔが慎重に検討され、適切な場合には、あらゆる提案を支持する。

【0108】

ＴｅｎｃｅｎｔのＡＲＣ実施の概要
図１１及び図１２は、ＴｅｎｃｅｎｔのＡＲＣエンコーダ及びデコーダの実装をそれぞれ示す。開示の技術の実施は、ピクチャの種類に関係なく、ピクチャの粒度毎にピクチャの幅及び高さを変更することを可能にする。エンコーダでは、入力された画像データは、現在のピクチャのエンコーディングのために選択されたピクチャサイズにダウンサンプリングされる。第１の入力ピクチャがイントラピクチャとしてエンコードされた後で、デコードされたピクチャがデコードされたピクチャバッファ（ＤＰＢ）に格納される。結果として得られたピクチャが異なるサンプリング比でダウンサンプリングされ、インターピクチャとしてエンコードされる場合、ＤＰＢ内の参照ピクチャは、参照のピクチャサイズと現在のピクチャサイズとの間の空間比に従ってアップ／ダウンスケーリングされる。デコーダでは、デコードされたピクチャは再サンプリングすることなくＤＰＢに格納される。しかしながら、ＤＰＢ内の参照ピクチャは、動き補正のために用いられる場合、現在デコードされているピクチャと参照との間の空間比に関連してアップ／ダウンスケーリングされる。デコードされたピクチャは、表示のためにバンプアウトされた場合、元のピクチャサイズ又は所望の出力ピクチャサイズにアップサンプリングされる。動き推定／補償プロセスでは、動きベクトルは、ピクチャサイズ比及びピクチャオーダカウント差に関連してスケーリングされる。

【0109】

ＡＲＣパラメータのシグナリング
本明細書では、ＡＲＣパラメータという用語は、ＡＲＣを機能させるために必要な任意のパラメータの組み合わせとして用いられる。最も簡単な場合は、ズーム係数又は定義されたズーム係数でテーブルへのインデックスである。これは、ＪＶＥＴ－Ｍ０１３５で提案されたように、ターゲット解像度（例えば、サンプル又は最大ＣＵサイズの粒度）又はターゲット解像度を提供するテーブルへのインデックスであり得る。また、使用中のアップ／ダウンサンプリングフィルタのフィルタパラメータ（フィルタ係数に至るまで）又はフィルタセレクタも含まれ得る。

【0110】

最初から、本明細書で提案する実施は、少なくとも概念的に、ピクチャの異なる部分について異なるＡＲＣパラメータを可能にすることである。現在のＶＶＣ草案の通り、適切なシンタックス構造は矩形タイル群（ＴＧ）であり得ることが提案される。スキャンオーダーＴＧを用いるものは、ＡＲＣをフルピクチャのみに用いるものに制限され得るか又はスキャンオーダーＴＧが矩形ＴＧに含まれる程度に制限され得る。これは、ビットストリーム制約で簡単に指定できる。

【0111】

異なるＴＧは異なるＡＲＣパラメータを有し得るため、ＡＲＣパラメータの適切な位置は、ＴＧヘッダ内又はＴＧの範囲を持つパラメータセット内であり、ＴＧヘッダによって参照されるか（現在のＶＶＣ草案における適応パラメータセット）又はより高いパラメータセットにおけるテーブルへのより詳細な参照（インデックス）であり得る。これら３つの選択肢のうち、この時点で、ＴＧヘッダを用いてＡＲＣパラメータを含むテーブルエントリへの参照をコード化することが提案され、そのテーブルはＳＰＳ内に位置し、（今回の）ＤＰＳにコード化されている。ズーム係数はパラメータ設定値を用いることなく、ＴＧヘッダに直接コード化できる。ＪＶＥＴ－Ｍ０１３５で提案されているように、参照のためのＰＰＳを用いることは、ＡＲＣパラメータのタイル群毎のシグナリングが設計基準である場合には対比的に示される。

【0112】

テーブルエントリ自体については、以下のオプションが利用可能である。

【0113】

－両方の次元についていずれか１つ又はＸ及びＹの次元で独立してダウンサンプル係数をコーディングすること。これはほとんど（ＨＷ－）実施の議論であり、Ｘ次元のズーム係数がかなり柔軟であるが、Ｙ次元が１に固定されているか又は選択肢が非常に少ない結果を好むものもあるだろう。そのような制約を表現するのにシンタックスは間違った場所であり、もしそれらが望ましいなら、適合のための要件として表現される制約は好ましいと提案される。つまり、シンタックスの柔軟に保たれる。

【0114】

－ターゲット解像度をコーディングすることが以下で提案される。現在の解像度との関連でこれらの解像度についてより多くの又は少ない複雑な制約がある場合があり、多分ビットストリーム適応要件で表される。

【0115】

－ピクチャ合成／抽出を可能にするために、タイル群毎のダウンサンプリングが好ましい。しかしながら、シグナリングの観点からは重要ではない。もしグループがピクチャの粒度でのみＡＲＣを許容するという賢明でない決定をしているなら、全てのＴＧが同じＡＲＣパラメータを用いるというビットストリーム適合性要件を含めることができる。

【0116】

－ＡＲＣに関する制御情報。我々の以下の設計では、それは参照ピクチャサイズを含む。

【0117】

－フィルタ設計の柔軟性は必要か？わずかなコードポイントより多い必要があるか？答えが「はい」の場合、それらをＡＰＳに入れるか？一部の実施では、ダウンサンプルフィルタが変化し、ＡＬＦが留まる場合、ビットストリームはオーバーヘッドを受け入れる（eat）必要があることが提案される。

【0118】

現時点では、提案された技術を(可能な限り)整合させ、シンプルに保つために、以下を提案する:
－固定フィルタ設計
－ビットストリーム制約ＴＢＤのＳＰＳ内のテーブルのターゲット解像度
－キャップ交換／ネゴシエーションを促進にするＤＰＳにおける最小／最大ターゲット解像度
結果として得られるシンタックスは以下のようになり得る。

【0119】

【表6】

【0120】

max_pic_width_in_luma_samplesは、ビットストリームにおけるルーマサンプル単位でデコードされたピクチャの最大幅を指定する。max_pic_width_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。dec_pic_width_in_luma_samples[i]の値はmax_pic_width_in_luma_samplesの値より大きくなることはできない。

【0121】

max_pic_height_in_luma_samplesは、ビットストリームにおけるルーマサンプル単位でデコードされたピクチャの最大高さを指定する。max_pic_height_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。dec_pic_height_in_luma_samples[i]の値はmax_pic_height_in_luma_samplesの値より大きくなることはできない。

【0122】

【表7】

【0123】

adaptive_pic_resolution_change_flag＝０は、出力ピクチャサイズ（output_pic_width_in_luma_samples、output_pic_height_in_luma_samples）、デコードされたピクチャサイズの数（num_dec_pic_size_in_luma_samples_minus１）及び少なくとも１つのデコードされたピクチャサイズ（dec_pic_width_in_luma_samples[i]、dec_pic_height_in_luma_samples[i]）がＳＰＳに存在することを指定する。参照ピクチャサイズ（reference_pic_width_in_luma_samples、reference_pic_height_in_luma_samples）が存在し、reference_pic_size_present_flagの値の条件とされている。

【0124】

output_pic_width_in_luma_samplesは、ルーマサンプルの単位で出力ピクチャの幅を指定する。output_pic_width_in_luma_samplesは０と等しくないものとする。

【0125】

output_pic_height_in_luma_samplesは、ルーマサンプルの単位で出力ピクチャの高さを指定する。output_pic_height_in_luma_samplesは０と等しくないものとする。

【0126】

reference_pic_size_present_flag＝１は、reference_pic_width_in_luma_samples及びreference_pic_height_in_luma_samplesが存在することを指定する。

【0127】

reference_pic_width_in_luma_samplesは、ルーマサンプルの単位で参照ピクチャの幅を指定する。output_pic_width_in_luma_samplesは０と等しくないものとする。存在しない場合、reference_pic_width_in_luma_samplesの値はdec_pic_width_in_luma_samples[i]と等しいと推定される。

【0128】

reference_pic_height_in_luma_samplesは、ルーマサンプルの単位で参照ピクチャの高さを指定する。output_pic_height_in_luma_samplesは０と等しくないものとする。存在しない場合、reference_pic_height_in_luma_samplesの値はdec_pic_height_in_luma_samples[i]と等しいと推定される。

【0129】

注記１－出力ピクチャのサイズは、output_pic_width_in_luma_samples及びoutput_pic_height_in_luma_samplesの値と等しいものとする。参照ピクチャのサイズは、参照ピクチャが動き補正に用いられる場合、reference_pic_width_in_luma_samples及びreference_pic_height_in_luma_samplesの値と等しいものとする。

【0130】

num_dec_pic_size_in_luma_samples_minus１+１は、コード化ビデオシーケンスのルーマサンプルの単位でデコードされたピクチャサイズ（dec_pic_width_in_luma_samples[i]、dec_pic_height_in_luma_samples[i]）の数を指定する。

【0131】

dec_pic_width_in_luma_samples[i]はコード化ビデオシーケンスのルーマサンプルの単位でデコードされたピクチャサイズのｉ番目の幅を指定する。dec_pic_width_in_luma_samples[i]は０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。

【0132】

dec_pic_height_in_luma_samples[i]はコード化ビデオシーケンスのルーマサンプルの単位でデコードされたピクチャサイズのｉ番目の高さを指定する。dec_pic_height_in_luma_samples[i]は０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。

【0133】

注記２－ｉ番目のデコードされたピクチャサイズ（dec_pic_width_in_luma_samples[i]、dec_pic_height_in_luma_samples[i]）は、コード化ビデオシーケンスにおけるデコードされたピクチャのデコードされたピクチャサイズと等しくてもよい。

【0134】

【表8】

【0135】

dec_pic_size_idxは、デコードされたピクチャの幅はpic_width_in_luma_samples[dec_pic_size_idx]と等しく、デコードされたピクチャの高さはpic_height _in_luma_samples[dec_pic_size_idx]と等しいものとすることを指定する。

【0136】

フィルタ
提案した設計は概念的に、元のピクチャから入力ピクチャへのダウンサンプリングフィルタと、動き推定／補償のために参照ピクチャを再スケーリングするアップ／ダウンサンプリングフィルタと、デコードされたピクチャから出力ピクチャへのアップサンプリングフィルタという４つの異なるフィルタセットを含む。最初及び最後のものは、非標準的事項として残すことができる。仕様の範囲では、アップ／ダウンサンプリングフィルタは、適切なパラメータセットにおいて明示的にシグナリングされるか又は予め定義される必要がある。

【0137】

我々の実施は、動き補償のために用いられるべき参照ピクチャをサイズ変更するダウンサンプリングのために、１２タップ２Ｄ分離可能フィルタであるＳＨＶＣのダウンサンプリングフィルタ（ＳＨＭ ｖｅｒ．１２．４）を用いる。現在の実施では、ダイアディックサンプリングのみがサポートされる。したがって、ダウンサンプリングフィルタの位相は、デフォルトでゼロに設定される。アップサンプリングについては、位相をシフトし、ルーマ及びクロマピクセル位置を元の位置に合わせるために１６相の８タップ補間フィルタが用いられる。

【0138】

表９及び表１０は、ルーマアップサンプリングプロセスに用いられる８タップフィルタ係数ｆＬ［ｐ，ｘ］（ｐ＝０．．１５及びｘ＝０．．７）と、クロマアップサンプリングプロセスに用いられる４タップフィルタ係数ｆＣ［ｐ，ｘ］（ｐ＝０．．１５及びｘ＝０．．３）を示す。

【0139】

表１１は、ダウンサンプリングプロセスのための１２タップフィルタ係数を示す。ダウンサンプリングでは、ルーマ及びクロマの両方に同じフィルタ係数が用いられている。

【0140】

【表9】

【0141】

【表10】

【0142】

【表11】

【0143】

コンテンツ及び／又はスケーリング係数に適応するフィルタを用いる場合、（おそらく有意な）主観的及び客観的な利得が期待されることが予想される。

【0144】

タイルグループ境界の議論
タイル群に関連する多くの研究についてもおそらく当てはまることであるが、タイル群（ＴＧ）ベースのＡＲＣに関する我々の実施は完全に終わっているとは言えない。我々の選好は、圧縮領域において、複数のサブピクチャを合成されたピクチャにする空間的構成及び抽出の議論が少なくともたたき台をもたらした場合に、その実施を再考することである。しかしながら、このことは、結果をある程度推定し、それに従って我々のシグナリング設計を適応させることを妨げるものではない。

【0145】

今のところ、タイルグループヘッダは、すでに述べた理由から、上記で提案したように、dec_pic_size_idx等のものにとって正しい場所である。単一のｕｅ（ｖ）コードポイントdec_pic_size_idxは、タイルグループヘッダに条件付きで存在し、使用されるＡＲＣパラメータを示すために用いられる。ピクチャ毎のＡＲＣのみである実施を一致させるために、スペック空間では、単一のタイルグループのみをコーディングするか又は所与のコード化ピクチャの全てのＴＧヘッダが（存在する場合）dec_pic_size_idxの値が同じであることをビットストリームコンプライアンスの条件とする必要がある。

【0146】

パラメータdec_pic_size_idxは、サブピクチャを開始するヘッダのいずれかに移動させることができる。それは引き続きタイルグループヘッダであり得る。

【0147】

これらのシンタックスな考慮以外に、タイルグループ又はサブピクチャベースのＡＲＣを可能にするために、いくつかの追加作業が必要である。おそらく最も困難な部分は、サブピクチャがより小さいサイズに再サンプリングされたピクチャ内の不要なサンプルの問題をどのように対処するかである。

【0148】

図１３は、ＡＲＣのためのタイル群ベースの再サンプリングの例を示す。４つのサブピクチャ（ビットストリームシンタックスにおいて４つの矩形のタイルグループとしておそらく表される）から構成される右側のピクチャを考えてみる。左側の右下のＴＧは半分のサイズにサブサンプリングされている。「半分」と表記される、関連領域の外のサンプルをどのようにするかを議論する必要がある。

【0149】

多くの（大半？、全て？）の以前のビデオコーディング規格では、圧縮ドメイン内のピクチャの部分の空間的抽出はサポートされていないという共通点があった。これは、ピクチャの各サンプルが１つ以上のシンタックス要素によって表され、各シンタックス要素は少なくとも１つのサンプルに影響を与えることを意味する。これを維持するために、「半分」とラベル付けされたダウンサンプリングされたＴＧによってカバーされるサンプルの周囲の領域をどうにかして追加する必要があり得る。Ｈ．２６３＋のＡｎｎｅｘ Ｐでは、パディングによってこの問題を解決する。実際、パディングされたサンプルのサンプル値は、ビットストリームで（特定の厳密な制限の範囲内で）シグナリングすることができ得る。

【0150】

以前の仮定からの大幅な逸脱を多分構成し得るが、ピクチャの矩形部分に基づくサブビットストリーム抽出（及び構成）をサポートする必要があり得る代替案は、復元されたピクチャの各サンプルがコード化ピクチャ内の何か（たとえ、それの何かがスキップされたブロックだけであっても）によって表される必要があるという現在の理解を緩和することであり得る。

【0151】

実施上の考慮事項、システムインプリケーション及びプロファイル／レベル
「ベースライン／メイン」プロファイルに含まれるべき基本的なＡＲＣを提案する。特定のアプリケーションシナリオで必要でない場合は、サブプロファイリングを用いてそれらを削除してもよい。一定の制限が許容され得る。この点に関し、特定のＨ．２６３＋プロファイル及び（プロファイルの前の）「推奨モード」には、「暗黙の係数４（implicit factor of 4）」、すなわち、両方の次元における二項ダウンサンプリング、としてのみ用いられるＡｎｎｅｘ Ｐが含まれたことに留意されたい。これは、テレビ会議のファストスタートをサポートするのに十分であった(Ｉフレームを素早く乗り越える)のには十分だった。

【0152】

この設計は、全てのフィルタリングを「臨機応変に（on the fly）」で行うことができ、メモリ帯域幅の増加がないか又は無視できる程度である。そうであれば、ＡＲＣをエキゾチックなプロファイルに移す必要はないように思われる。

【0153】

複雑な表等は、ＪＶＥＴ－Ｍ０１３５と共にMarrakechで論じられているように、能力交換には有意義に用いられないかもしれない。オプションの数は、オファーアンサーや同様の限定された深度のハンドシェイクを仮定して、意味のあるクロスベンダインターオプを可能にするために、単純に大きくなる。現実的には、能力交換シナリオにおいてＡＲＣを有意義にサポートするために、大半のインターオップポイントでほんの少数にフォールバックしなければならない。例えば、ＡＲＣなし、暗黙の係数４のＡＲＣ、完全なＡＲＣである。代替的に、全てのＡＲＣに必要なサポートを指定し、ビットストリームの複雑性の制限をより高いレベルのＳＤＯに任せることが可能である。これは、いずれにせよ（サブプロファイリング及びフラグの文脈で既に議論したものを越えて）ある時点で行うべき戦略的議論である。

【0154】

レベルに関して、基本的な設計原理は、ビットストリーム適合の条件として、ビットストリームにおいてアップサンプリングがそれだけシグナリングされてもアップサンプリングされたピクチャのサンプルカウントはビットストリームのレベルに適合する必要があり、全てのサンプルはアップサンプリングされたコード化ピクチャに適合する必要がある。なお、これはＨ２６３＋では当てはまらず、特定のサンプルが存在しない可能性がある。

【0155】

２．２．５． ＪＶＥＴ－Ｎ０１１８
以下の側面が提案されている。

【0156】

１． ピクチャ解像度のリストはＳＰＳでシグナリングされ、リストのインデックスは個々のピクチャのサイズを指定するためにＰＰＳでシグナリングされる。

【0157】

２． 出力すべきピクチャについて、再サンプリング前のデコードされたピクチャは（必要に応じて）クロップされて出力される。すなわち、再サンプリングされたピクチャは出力用ではなく、インター予測参照のためだけのものである。

【0158】

３． １．５倍及び２倍の再サンプリング比をサポートする。任意の再サンプリング比はサポートしない。１つ又は２つ以上の他の再サンプリング比の必要性を検討する。

【0159】

４． ピクチャレベルの再サンプリングとブロックレベルの再サンプリングとの間では、提唱者らはブロックレベルの再サンプリングを好む。

【0160】

ａ．しかしながら、ピクチャレベルの再サンプリングが選択される場合、以下の側面が提案される。

【0161】

ｉ．参照ピクチャが再サンプリングされる場合、参照ピクチャの再サンプリングされたバージョンと、オリジナルの再サンプリングされたバージョンとの双方がＤＰＢに格納されるため、双方はＤＰＢのフルネスに影響を及ぼす。

【0162】

ｉｉ．再サンプリングされた参照ピクチャは、対応する再サンプリングされていない参照ピクチャが「参照のために使用されない」とマークされている場合、「参照のために使用されない」とマークされる。

【0163】

ｉｉｉ．ＲＰＬシグナリングシンタックスは変更されずに維持されるのに対して、ＲＰＬ構築プロセスは次のように変更される。参照ピクチャをＲＰＬエントリに含める必要があり、現在のピクチャと同じ解像度を有する参照ピクチャのバージョンがＤＰＢ内にない場合、ピクチャ再サンプリングプロセスが呼び出され、その参照ピクチャの再サンプリングバージョンはＲＰＬエントリに含められる。

【0164】

ｉｖ．ＤＰＢに存在する再サンプリングされた参照ピクチャの数は、例えば２以下に制限されるべきである。

【0165】

ｂ．そうでなければ（ブロックレベル再サンプリングが選択された場合）、以下が提案される。

【0166】

ｉ．最悪ケースのデコーダの複雑性を制限するために、現在のピクチャとは異なる解像度を有する参照ピクチャからのブロックの双方向予測を禁止することが提案されている。

【0167】

ｉｉ．別の選択肢は、再サンプリング及び１／４ピクセル単位の補間を行う必要がある場合、２つのフィルタが組み合わされ、動作が一度に適用されることである。

【0168】

５．ピクチャベース及びブロックベースの再サンプリングアプローチのいずれが選択されるかにかかわらず、時間的動きベクトルスケーリングが必要に応じて適用されることが提案される。

【0169】

２．２．５．１． 実施
ＡＲＣソフトウェアは、以下の変更を加えてＶＴＭ－４．０．１上で実施された。

【0170】

－サポートされている解像度のリストはＳＰＳでシグナリングされる。

【0171】

－空間分解能シグナリングがＳＰＳからＰＰＳに移動された。

【0172】

－参照ピクチャを再サンプリングするために、ピクチャベースの再サンプリングスキームが実施された。ピクチャがデコードされた後に、再構成されたピクチャは異なる空間分解能に再サンプリングされ得る。元の再構成ピクチャ及び再サンプリングされ再構成されたピクチャの双方は、ＤＰＢに格納され、将来のピクチャによりデコーディング順で参照するために利用可能である。

【0173】

－実施されている再サンプリングフィルタは、ＪＣＴＶＣ－Ｈ０２３４で以下のようにテストされたフィルタに基づく。

【0174】

－アップサンプリングフィルタ：タップが（－４、５４、１６、－２）／６４の４タップ＋／－１／４相ＤＣＴＩＦ
－ダウンサンプリングフィルタ：タップが（１、０、－３、０、１０、１６、１０、０、－３、０、１）/３２のｈ１１フィルタ
－現在のピクチャ（すなわち、Ｌ０及びＬ１）の参照ピクチャリストを構成する場合、現在のピクチャと同じ解像度を有する参照ピクチャのみが用いられる。なお、参照ピクチャはそれらの元のサイズ又は再サンプリングしたサイズの両方で利用可能であり得る。

【0175】

－ＴＭＶＰ及びＡＴＶＭＰが有効にされ得る。しかしながら、現在のピクチャ及び参照ピクチャの元のコーディング解像度が異なる場合、その参照ピクチャについてはＴＭＶＰ及びＡＴＭＶＰが無効になる。

【0176】

－開始点ソフトウェアの実施を簡単及び簡素にするために、ピクチャを出力する場合、デコーダは最高の利用可能な解像度を出力する。

【0177】

ピクチャサイズ及びピクチャ出力のシグナリングについて
１． ビットストリームにおけるコード化ピクチャの空間分解能のリストについて
現在、ＣＶＳ内の全てのコード化ピクチャは同じ解像度を有する。そのため、ＳＰＳにおいて、ただ１つの解像度（すなわち、ピクチャの幅及び高さ）をシグナリングするのが分かりやすい。ＡＲＣのサポートでは、１つの解像度ではなく、ピクチャ解像度のリストをシグナリングする必要がある。このリストをＳＰＳでシグナリングし、個々のピクチャのサイズを指定するためにリストのインデックスをＰＰＳでシグナリングすることが提案される。

【0178】

２. ピクチャ出力について
出力されるべきピクチャについては、再サンプリング前のデコードされたピクチャは（必要に応じて）クロップされて出力される、すなわち再サンプリングされたピクチャは出力のためのものではなく、インター予測参照のためだけのものであることが提案される。ＡＲＣ再サンプリングフィルタは、インター予測のための再サンプリングされたピクチャの使用が最適化されるように設計される必要があり、そのようなフィルタは、ピクチャの出力／表示目的には最適でない可能性があるのに対して、ビデオ端末装置は、既に実施されている、最適化された出力ズーミング／スケーリング機能を通常有する。

【0179】

２．２．５．３． 再サンプリングについて
デコードされたピクチャの再サンプリングは、ピクチャベース又はブロックベースのいずれかであり得る。ＶＶＣにおける最終的なＡＲＣ設計では、ブロックベースの再サンプリングがピクチャベースの再サンプリングよりも望ましい。これらの２つのアプローチを議論し、これらの２つのうちのどちらをＶＶＣにおけるＡＲＣサポートに指定するかをＪＶＥＴが決定することを推奨する。

【0180】

ピクチャベースの再サンプリング
ＡＲＣのためのピクチャベースの再サンプリングでは、ピクチャは特定の解像度のために１回だけが再サンプリングされ、その後にそれがＤＰＢに格納されるのに対して、同じピクチャの再サンプリングされていないバージョンもＤＰＢに維持される。

【0181】

ＡＲＣのためにピクチャベースの再サンプリングの用いることには、１）再サンプリングされた参照ピクチャを格納するために追加のＤＰＢバッファが必要になること及び２）ＤＰＢからの参照ピクチャデータの読み出し及びＤＰＢへの参照ピクチャデータの書き込み動作の増加により、追加のメモリ帯域幅が必要であること、という２つの問題がある。

【0182】

ＤＰＢで参照ピクチャの１バージョンのみを保持することは、ピクチャベースの再サンプリングの場合良案ではない。再サンプリングされていないバージョンのみが保存されている場合、複数のピクチャは同じ参照ピクチャを参照し得るため、参照ピクチャを複数回再サンプリングする必要があり得る。他方で、参照ピクチャが再サンプリングされ、再サンプリングされたバージョンのみが保持される場合、参照ピクチャを出力する必要がある場合に逆再サンプリングを適用する必要がある。何故なら、上述したように、再サンプリングされていないピクチャを出力したほうが良いからである。これは、再サンプリングプロセスは可逆演算ではないため問題である。ピクチャＡをとり、それをダウンサンプリングし、その後にアップサンプリングしてＡと同じ解像度のＡ’を得た場合、ＡとＡ’とは同じではない。ダウンサンプリング及びアップサンプリングプロセスの間に一部の高周波数情報が失われたため、Ａ’に含まれる情報はＡよりも少なくなり得る。

【0183】

追加のＤＰＢバッファ及びメモリ帯域幅の問題に対処するために、ＶＶＣにおけるＡＲＣ設計がピクチャベースの再サンプリングを用いる場合、以下が適用されることが提案される。

【0184】

１．参照ピクチャが再サンプリングされる場合、参照ピクチャの再サンプリングされたバージョンと元の再サンプリングされたバージョンの双方がＤＰＢに格納されるため、双方はＤＰＢのフルネスに影響を及ぼす。

【0185】

２． 再サンプリングされた参照ピクチャは、対応する再サンプリングされていない参照ピクチャが「参照のために使用されない」とマークされている場合、「参照のために使用されない」とマークされる。

【0186】

３． 各タイルグループの参照ピクチャリスト（ＲＰＬ）は、現在のピクチャと同じ解像度を有する参照ピクチャを含む。ＲＰＬシグナリングシンタックスを変更する必要はないが、ＲＰＬ構築プロセスは、先の文で述べられたことを確実にするために、次のように修正される：参照ピクチャをＲＰＬエントリに含める必要がある場合に、その参照ピクチャの現在のピクチャと同じ解像度を有するバージョンがまだ利用可能ではない場合、ピクチャ再サンプリングプロセスが呼び出され、その参照ピクチャの再サンプリングバージョンが含まれる。

【0187】

４． ＤＰＢ内に存在し得る再サンプリングされた参照ピクチャの数は、例えば２以下に制限されるべきである。

【0188】

さらに、時間的ＭＶが現在のフレームとは異なる解像度で参照フレームから来る場合に時間的ＭＶの使用（例えば、マージモード及びＡＴＭＶＰ）を可能にするために、時間的ＭＶを現在の解像度に必要に応じてスケーリングすることを提案する。

【0189】

ブロックベースのＡＲＣ再サンプリング
ＡＲＣのためのブロックベースの再サンプリングでは、参照ブロックは必要に応じて再サンプリングされ、再サンプリングされたピクチャはＤＰＢに格納されない。

【0190】

ここでの主な問題は、付加的なデコーダの複雑性である。これは、参照ピクチャ内のブロックが、他のピクチャ内の複数のブロックにより及び複数のピクチャ内の複数のブロックにより複数回参照され得るからである。

【0191】

参照ピクチャ内のブロックが現在ピクチャ内のブロックによって参照され、参照ピクチャと現在ピクチャとの解像度が異なる場合、参照ブロックは、参照ブロックが整数ピクセルの解像度を有するように補間フィルタの呼び出しによって再サンプリングされる。動きベクトルが１／４ピクセル単位の場合、１／４ピクセル単位の解像度で再サンプリングされた参照ブロックを得るために補間プロセスが再度呼び出される。したがって、異なる解像度を伴う参照ブロックからの現在のブロックのための各動き補償動作に対して、１つの代わりに最大で２回の補間フィルタリング動作が必要になる。ＡＲＣサポートなしでは、最大で１回だけの補間フィルタリング動作（即ち、１／４ピクセル単位の解像度での参照ブロックの生成）が必要になる。

【0192】

最悪ケースの複雑性を制限するために、ＶＶＣにおけるＡＲＣ設計がブロックベースの再サンプリングを用いる場合、以下が適用されることが提案される。

【0193】

－現在のピクチャとは異なる解像度を有する参照ピクチャからのブロックの双方向予測を禁止される。

【0194】

－より正確に言えば、制約は次の通りである。現在のピクチャピクチャｐｉｃＡ内の現在のブロックｂｌｋＡが参照ピクチャｐｉｃＢ内の参照ブロックｂｌｋＢを参照する場合、ｐｉｃＡ及びｐｉｃＢが異なる解像度を有する場合、ブロックｂｌｋＡは単方向予測ブロックとする。

【0195】

この制約により、ブロックをデコードするために必要な最悪の場合の補間動作の数は２つに制限される。ブロックが異なる解像度のピクチャからのブロックを参照する場合、必要な補間動作の数は、上述のように２である。これは、ブロックが同じ解像度のピクチャからの参照ブロックを参照し、双方向予測ブロックとしてコード化される場合と同じである。何故なら、補間動作の数も２だからである（すなわち、各参照ブロックについて１／４ピクセル単位の解像度を得るために１回）。

【0196】

実施を簡素化するために、ＶＶＣにおけるＡＲＣ設計がブロックベースの再サンプリングを用いる場合、以下が適用される別のバリエーションが提案される。

【0197】

－参照フレーム及び現在のフレームが異なる解像度を有する場合、予測子の各ピクセルの対応する位置が最初に計算され、その後に補間は１回だけ適用される。すなわち、２回の補間動作（すなわち、再サンプリングのための１回及び１／４ピクセル単位の補間のために１回）は１回だけの補間動作に組み合わされる。現在のＶＶＣにおけるサブペル（sub-pel）補間フィルタは再利用できるが、この場合、補間の粒度は拡大されるべきであるが、補間動作の回数は２回から１回に減らされる。

【0198】

－時間的ＭＶが現在のフレームとは異なる解像度で参照フレームから来る場合に時間的ＭＶの使用（例えば、マージモード及びＡＴＭＶＰ）を可能にするために、時間的ＭＶを現在の解像度に必要に応じてスケーリングすることを提案する。

【0199】

再サンプリング比
ＪＶＥＴ－Ｍ０１３５［１］では、ＡＲＣについての議論を開始するために、ＡＲＣの開始点について、２倍（アップサンプリングでは２×２、ダウンサンプリングでは１／２×１／２を意味する）の再サンプリング比のみを考慮することが提案されている。マラケシュ会議後のこの話題に関するさらなる議論から、２倍の再サンプリング比のみをサポートすることは非常に限定的であることが分かった。何故なら、場合によっては、再サンプリングされた解像度と再サンプリングされていない解像度との差が小さい方が有益であり得るからである。

【0200】

任意の再サンプリング比をサポートすることが望ましいかもしれないが、それをサポートすることは困難であり得る。何故なら、任意の再サンプリング比をサポートするためには、定義して実施する必要がある再サンプリングフィルタの数が多すぎることになり、デコーダの実施に大きな負担を課すことになるからである。

【0201】

１よりも大きいが小さな数（少なくとも１.５倍及び２倍の再サンプリング比）の再サンプリング比がサポートされる必要であり、任意の再サンプリング比はサポートされないことが提案されている。

【0202】

２．２．５．４ 最大ＤＰＢバッファサイズ及びバッファフルネス
ＡＲＣでは、ＤＰＢは同じＣＶＳ内で異なる空間分解能のデコードされたピクチャを含み得る。ＤＰＢ管理及び関連する側面について、デコードされたピクチャの単位でＤＰＢサイズ及びフルネスをカウントすることはもはや機能しない。

【0203】

以下は、ＡＲＣがサポートされている場合に対処する必要がある特定の側面と、最終的なＶＶＣの仕様における可能性のある解決策についての議論である。

【0204】

１． PicSizeInSamplesY（すなわち、PicSizeInSamplesY = pic_width_in_luma_samples ＊
pic_height_in_luma_samples）の値をMaxDpSize（すなわち、ＤＰＢに存在し得る参照ピクチャの最大数）の導出に用いる代わりに、MaxDpbSizeの導出は、MinPicSizeInSamplesYの値に基づく。MinPicSizeInSamplesYは以下のように定義される。

【0205】

MinPicSizeInSampleY＝（ビットストリームにおける最小ピクチャ解像度の幅）＊（ビットストリームにおける最小解像度の高さ）
MaxDpbSizeの導出は（ＨＥＶＣ式に基づいて）以下のように修正される。

【0206】

【数5】

【0207】

２． 各デコードされたピクチャは、PictureSizeUnitと呼ばれる値に関連する。PictureSizeUnitは、デコードされたピクチャサイズがMinPicSizeInSampleYに対してどれくらい大きいかを指定する整数の値である。PictureSizeUnitの定義は、ＶＶＣにおけるＡＲＣでどの再サンプリング比がサポートされているかによって決まる。

【0208】

例えば、ＡＲＣが再サンプリング比２のみをサポートする場合、PictureSizeUnitは次のように定義される。

【0209】

－ビットストリームにおける最小解像度を有するデコードされたピクチャは、１のPictureSizeUnitに関連する。

【0210】

－ビットストリームにおける最小解像度の２×２の解像度を有するデコードされたピクチャは、４のPictureSizeUnit（すなわち、１×４）に関連する。

【0211】

別の例では、ＡＲＣが１.５及び２の再サンプリング比の両方をサポートする場合、PictureSizeUnitは以下のように定義される。

【0212】

－ビットストリームにおける最小解像度を有するデコードされたピクチャは、４のPictureSizeUnitに関連する。

【0213】

－ビットストリームにおける最小解像度の１.５×１.５の解像度を有するデコードされたピクチャは、９のPictureSizeUnit（すなわち、２．２５×４）に関連する。

【0214】

－ビットストリームにおける最小解像度の２×２の解像度を有するデコードされたピクチャは、１６のPictureSizeUnit（すなわち、４×４）に関連する。

【0215】

ＡＲＣによってサポートされるその他の再サンプリング比については、上記の例と同じ原則を用いて、各ピクチャサイズについてのPictureSizeUnitの値を決定すべきである。

【0216】

３． 変数MinPictureSizeUnitをPictureSizeUnitの可能な最小値とする。つまり、ＡＲＣが再サンプリング比２のみをサポートする場合、MinPictureSizeUnitは１であり、ＡＲＣが再サンプリング比１.５及び２をサポートする場合、MinPictureSizeUnitは４であり、MinPictureSizeUnitの値を決定するための同じ原理が用いられる。

【0217】

４． sps_max_dec_pic_buffering_minus１[i]の値の範囲は、０～（MinPictureSizeUnit * （MaxDpbSize - １））の範囲に指定される。変数MinPictureSizeUnitは、PictureSizeUnitの可能な最小値である。

【0218】

５．ＤＰＢフルネス動作は、PictureSizeUnitに基づいて以下のように規定される。

【0219】

－ＨＲＤはデコーディングユニット０で初期化され、ＣＰＢ及びＤＰＢは共に空に設定される（ＤＰＢフルネスは０に設定される）。

【0220】

－ＤＰＢがフラッシュされる（すなわち、全てのピクチャがＤＰＢから削除される）場合、ＤＰＢフルネスは０に設定される。

【0221】

－ピクチャがＤＰＢから削除された場合、ＤＰＢフルネスは削除されたピクチャに関連するPictureSizeUnitの値だけデクリメントされる。

【0222】

－ピクチャがＤＰＢに挿入された場合、ＤＰＢフルネスは、挿入されたピクチャに関連するPictureSizeUnitの値だけインクリメントされる。

【0223】

２．２．５．５ 再サンプリングフィルタ
ソフトウェア実施では、実施される再サンプリングフィルタは、ＪＣＴＶＣ－Ｈ０２３４［３］に記載されている前に利用可能なフィルタから単純に取られている。他の再サンプリングフィルタをテストし、それらがより良い性能及び／又はより低い複雑性を提供する場合には、それらを用いるべきである。複雑性と性能の間のトレードオフを取り決めるために、様々な再サンプリングフィルタをテストすることが提案される。そのようなテストはＣＥで行うことができる。

【0224】

２．２．５．６ 既存のツールに対するその他の必要な修正
ＡＲＣをサポートするために、既存のコーディングツールの一部に対して、いくつかの修正及び／又は追加の動作が必要になり得る。例えば、ＡＲＣソフトウェア実施のピクチャベースの再サンプリングでは、簡素化のために、現在のピクチャ及び参照ピクチャの元のコーディング解像度が異なる場合に、ＴＭＶＰ及びＡＴＭＶＰは無効にされる。

【0225】

２．２．６ ＪＶＥＴ－Ｎ０２７９
「将来のビデオコーディング規格のための要件」によれば、「それぞれが異なる特性（例えば、空間分解能又はサンプルビット深度）を有する同一コンテンツの複数の表現を提供するアダプティブストリーミングサービスの場合、規格は高速な表現スイッチングをサポートするものとする」とされている。リアルタイムのビデオ通信では、Ｉピクチャを挿入することなく、コード化ビデオシーケンス内の解像度を変化させることは、ビデオデータを動的チャネル条件又はユーザの好みにシームレスに適合させるだけでなく、Ｉピクチャによってもたらされるビート効果を取り除くことができる。適応的解像度変更の仮想的な例が図１４に示され、ここでは、現在のピクチャは異なるサイズの参照ピクチャから予測される。

【0226】

この貢献は、ＶＴＭにおける現在の動き補償予測プロセスに、適応的解像度変更及び修正をシグナリングする高レベルシンタックスを提案する。これらの修正は、既存の動き補償補間器に変更を加えずに、動きベクトルスケーリング及びサブペル位置導出に限定される。これは、既存の動き補償補間器が再利用されることを可能にし、追加コストをもたらし得る適応的解像度変更をサポートするための新たな処理ブロックを必要としない。

【0227】

２．２．６．１ 適応的解像度変更シグナリング

【0228】

【表12】

【0229】

[[pic_width_in_luma_samples] は、各デコードされたピクチャの幅をルーマサンプル単位で指定する。pic_width_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。
pic_height_in_luma_samplesは、各デコードされたピクチャの高さをルーマサンプル単位で指定する。pic_height_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。]]

【0230】

max_pic_width_in_luma_samplesは、ＳＰＳを参照するデコードされたピクチャの最大幅をルーマサンプル単位で指定する。max_pic_width_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。

【0231】

max_pic_height_in_luma_samplesは、ＳＰＳを参照するデコードされたピクチャの最大高さをルーマサンプル単位で指定する。max_pic_height_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。

【0232】

【表13】

【0233】

pic_size_difference_from_max_flag=１は、ＰＰＳが参照されたＳＰＳのmax_pic_width_in_luma_samples及びmax_pic_height_in_luma_sampleとは異なるピクチャ幅又ピクチャ高さをシグナリングすることを指定する。pic_size_different_from_max_flag＝０は、pic_width_in_luma_samples及びpic_height_in_luma_samplesが、参照されたＳＰＳのmax_pic_width_in_luma_samples及びmax_pic_height_in_luma_sampleと同じであることを指定する。

【0234】

pic_width_in_luma_samplesは、各デコードされたピクチャの幅をルーマサンプル単位で指定する。pic_width_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。pic_width_in_luma_samplesが存在しない場合、それはmax_pic_width_in_luma_samplesと等しいと推定される。

【0235】

pic_height_in_luma_samplesは、各デコードされたピクチャの高さをルーマサンプル単位で指定する。pic_height_in_luma_samplesは０と等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。pic_height_in_luma_samplesが存在しない場合、それはmax_pic_height_in_luma_samplesと等しいと推定される。

【0236】

水平及び垂直スケーリング比は、全てのアクティブ参照ピクチャに対して、１／８～２の範囲とすることがビットストリーム適合の要件である。スケーリング比は以下のように定義される。

【0237】

horizontal_scaling_ratio＝（（reference_pic_width_in_luma_samples＜＜１４）＋（pic_width_in_luma_samples／２））／pic_width_in_luma_samples
vertical_scaling_ratio＝（（reference_pic_height_in_luma_samples＜＜１４)＋（pic_height_in_luma_samples／２））／pic_height_in_luma_samples

【0238】

【表14】

【0239】

参照ピクチャスケーリングプロセス
ＣＶＳ内で解像度変更がある場合、ピクチャは、その参照ピクチャの１つ以上と異なるサイズを有し得る。この提案は、全ての動きベクトルを、それらの対応する参照ピクチャのグリッドの代わりに、現在のピクチャのグリッドに正規化する。これは、設計の一貫性を維持し、解像度変更を動きベクトル予測プロセスに対して透明性のあるものにする上で有益であると主張される。さもなければ、異なるサイズの参照ピクチャを指す隣接する動きベクトルは、スケーリングが異なることにより、空間的動きベクトル予測に直接用いることができない。

【0240】

解像度変更が起こると、動き補償予測を行う間に動きベクトル及び参照ブロックの双方をスケーリングする必要がある。スケーリング範囲は［１／８、２］に限定されている。すなわち、アップスケーリングは１：８に制限され、ダウンスケーリングは２：１に制限されている。なお、アップスケーリングとは、参照ピクチャが現在のピクチャよりも小さい場合を意味するのに対して、ダウンスケーリングとは、参照ピクチャが現在のピクチャより大きい場合を意味する。以下のセクションでは、スケーリングプロセスをより詳細に説明する。

【0241】

ルーマブロック
スケーリング係数及びそれらの固定点表現は以下のように定義される。

【0242】

【数6】

【0243】

【数7】

スケーリングプロセスには２つの部分がある。

【0244】

１．現在のブロックの左上隅のピクセルを参照ピクチャにマップする。

【0245】

２．現在のブロックの他のピクセルの参照位置を指定するために水平及び垂直のステップサイズを用いる。

【0246】

現在のブロックの左上隅のピクセルの座標が（ｘ、ｙ）の場合、１／１６ピクセルの単位で動きベクトル（ｍｖＸ、ｍｖＹ）によって指される参照ピクチャ内のサブペル位置（ｘ＾’、ｙ＾’）は以下のように指定される。

【0247】

参照ピクチャの水平位置は次のようになる。

【0248】

【数8】

【0249】

１０ビットだけを保持するためにｘ’がさらに縮小される。

【0250】

【数9】

【0251】

同様に、参照ピクチャの垂直位置は次のようになる。

【数10】

【0252】

ｙ’はさらに縮小される。

【0253】

【数11】

【0254】

この時点で、現在のブロックの左上隅のピクセルの参照位置は（ｘ＾’、ｙ＾’）にある。他の参照サブプル／ピクセル位置は、水平及び垂直ステップサイズで（ｘ＾’、ｙ＾’）に対して計算される。これらのステップサイズは、上記の水平及び垂直スケーリング係数から１／１０２４ピクセル単位の精度で以下のように導出される。

【0255】

【数12】

【0256】

【数13】

一例として、現在のブロック内のピクセルがｉ列であり、左上隅のピクセルからj列離れている場合、その対応する参照ピクセルの水平及び垂直座標は以下のように導出される。

【0257】

【数14】

【0258】

【数15】

【0259】

サブペル補間では、ｘ’_ｉ、ｙ’_ｊをフルペル部及び部分ペル部に分割する必要がある。

【0260】

－参照ブロックをアドレスするためのフルペル部は以下と等しい。

【0261】

【数16】

【0262】

【数17】

【0263】

－補間フィルタの選択に用いられ得る部分ペル部は以下と等しい。

【0264】

【数18】

【0265】

【数19】

【0266】

参照ピクチャ内のフルペル位置及び部分ペル位置が特定された場合、追加の変更なしに既存の動き補償を用いることができる。フルペル位置は、参照ピクチャから基準ブロックパッチを取得するために用いられ、部分ペル位置は、適切な補間フィルタを選択するために用いられる。

【0267】

クロマブロック
クロマフォーマットが４：２：０の場合、クロマ動きベクトルは１／３２ピクセル単位の精度を有する。クロマ動きベクトル及びクロマ参照ブロックのスケーリングプロセスは、クロマフォーマット関連の調整を除いて、ルーマブロックの場合とほぼ同じである。

【0268】

現在のクロマブロックの左上隅のピクセルの座標が（ｘｃ、ｙｃ）の場合、参照クロマピクチャの初期水平及び垂直位置は次のようになる。

【0269】

【数20】

【0270】

【数21】

【0271】

ここで、ｍｖＸ及びｍｖＹは元のルーマ動きベクトルであるが、今度は１／３２ピクセル単位の精度で検査すべきである。

【0272】

１／１０２４ピクセル単位の精度を維持するために、ｘｃ’及びｙｃ’がさらに縮小される。

【0273】

【数22】

【0274】

【数23】

【0275】

関連するルーマの方程式と比較して、上記の右側へのシフトは１ビット増加する。

【0276】

使用するステップサイズはルーマとの場合と同じである。左上隅のピクセルに対して（ｉ、ｊ）にあるクロマピクセルについて、その参照ピクセルの水平及び垂直座標は下記に導出される。

【0277】

【数24】

【0278】

【数25】

【0279】

サブペル補間では、ｘ_ｃ’_ｉ、ｙ_ｃ’_ｊもフルペル部及び部分ペル部に分割される。

【0280】

－参照ブロックをアドレスするためのフルペル部は以下と等しい。

【0281】

【数26】

【0282】

【数27】

【0283】

補間フィルタの選択に用いられる部分ペル部は以下と等しい。

【0284】

【数28】

【0285】

【数29】

【0286】

他のコーディングツールとの相互作用
一部のコーディングツールと参照ピクチャスケーリングとの相互作用に伴う複雑性及びメモリ帯域幅の増加により、ＶＶＣ仕様に以下の制約を加えることが推奨される。

【0287】

tile_group_temporal_mvp_enabled_flag＝１の場合、現在のピクチャ及びそのコロケーションされたピクチャは同じサイズを有するものとする。

【0288】

シーケンス内で解像度変更が許容される場合、デコーダの動きベクトル精密化はオフにすべきである。

【0289】

シーケンス内で解像度変更が許可される場合、sps_bdof_enabled_flag＝０とする。

【0290】

２．３ ＪＶＥＴ－Ｎ０４１５におけるコーディングツリーブロック（ＣＴＢ）ベースの適応ループフィルタ（ＡＬＦ)
スライスレベルの時間フィルタ
ＶＴＭ４では適応パラメータセット（ＡＰＳ）が採用された。各ＡＰＳは１セットのシグナリングＡＬＦフィルタを含み、最大で３２のＡＰＳがサポートされる。提案では、スライスレベルの時間フィルタがテストされた。タイルグループは、オーバーヘッドを減らすためにＡＰＳからのＡＬＦ情報を再利用できる。ＡＰＳは先入れ先出し（ＦＩＦＯ）バッファとして更新される。

【0291】

ＣＴＢベースのＡＬＦ
ルーマコンポーネントの場合、ＡＬＦがルーマＣＴＢに適用された場合、１６の固定フィルタセット、５つの時間フィルタセット又は１つの信号フィルタセットのうちの選択肢が示される。フィルタセットインデックスのみがシグナリングされる。１つのスライスに対して、新たな２５のフィルタセット１つだけをシグナリングできる。新たなセットがスライスにシグナリングされた場合、同じスライス内の全てのルーマＣＴＢはそのセットを共有する。固定フィルタセットは新たなスライスレベルフィルタセットを予測するために用いることができ、ルーマＣＴＢのフィルタセット候補として用いることができる。フィルタの数は合計で６４である。

【0292】

クロマコンポーネントの場合、ＡＬＦがクロマＣＴＢに適用された場合、新たなフィルタがスライスに対してシグナリングされた場合、ＣＴＢは新たなフィルタを用い、さもなくば、時間的スケーラビリティ制約を満たす最新の時間的クロマフィルタが適用される。

【0293】

スライスレベルの時間フィルタとして、ＡＰＳは先入れ先出し（ＦＩＦＯ）バッファとして更新される。

【0294】

２.４ 代替的な時間的動きベクトル予測（ＶＶＣにおけるサブブロックベースの時間的マージ候補としても知られる）
代替的な時間的動きベクトル予測（ＡＴＭＶＰ）法では、動きベクトル時間的動きベクトル予測（ＴＭＶＰ）を、現在のＣＵよりも小さいブロックから複数のセットの動き情報（動きベクトル及び参照インデックスを含む）を取り出すことにより修正されている。図１４に示すように、サブＣＵは正方形のＮ×Ｎブロックである（Ｎはデフォルトで８に設定されている）。

【0295】

ＡＴＭＶＰは、ＣＵ内のサブＣＵの動きベクトルを２段階で予測する。第１のステップは、いわゆる時間ベクトルを用いて参照ピクチャ内の対応するブロックを識別することである。この参照ピクチャは動きソースピクチャと呼ばれる。第２のステップは、現在のＣＵをサブＣＵに分割して、ＣＵのＡＴＭＶＰ動き予測の例を示す図１５に示すように、各サブＣＵに対応するブロックから、各サブＣＵの参照インデックスに加えて動きベクトルを得ることである。

【0296】

第１のステップでは、参照ピクチャ及び対応するブロックは、現在のＣＵの空間的隣接ブロックの動き情報によって決定される。隣接ブロックの繰り返しの走査プロセスを避けるために、現在のＣＵのマージ候補リスト内のブロックＡ０（左ブロック）からのマージ候補が用いられる。コロケーションされた参照ピクチャを参照するブロックＡ０からの第１の利用可能な動きベクトルは時間ベクトルとして設定される。このように、ＡＴＭＶＰでは、対応するブロックは、ＴＭＶＰに比べてより正確に識別され得る。対応するブロック（コロケーションされたブロックと呼ばれることもある）は、現在のＣＵに対して常に右下又は中心位置にある。

【0297】

第２のステップにおいて、サブＣＵの対応するブロックは、現在のＣＵの座標に時間ベクトルを加えることにより、動きソースピクチャ内の時間ベクトルによって識別される。各サブＣＵに対して、その対応するブロックの動き情報（中心サンプルをカバーする最小の動きグリッド）を用いてサブＣＵの動き情報が導出される。対応するＮ×Ｎブロックの動き情報が識別された後で、ＨＥＶＣのＴＭＶＰと同じ様に、現在のサブＣＵの動きベクトル及び参照インデックスに変換され、動きスケーリング及び他の手順が適用される。

【0298】

２．５ アフィン動き予測
ＨＥＶＣでは、並進運動モデル（translation motion model）しか動き補償予測（Motion Compensation Prediction，ＭＣＰ）のために適用されない。現実世界では、多くの種類の動き、例えば、ズームイン／アウト、回転、射影運動及び他の不規則な動きを有する可能性がある。ＶＶＣでは、簡素化されたアフィン変換動き補償予測が４パラメータアフィンモデル及び６パラメータアフィンモデルにより適用される。図１６ａ及び図１６ｂは簡素化された４パラメータアフィンモデル及び６パラメータアフィンモデルをそれぞれ示す。図１６ａ及び図１６ｂに示すように、ブロックのアフィン運動場は、４パラメータアフィンモデルについては２つの制御点動きベクトル（Control Point Motion Vectors，ＣＰＭＶ）及び６パラメータアフィンモデルについては３つのＣＰＭＶによって記述される。

【0299】

ブロックの動きベクトル場（Motion Vector Field、ＭＶＦ）は、式（１）の４パラメータアフィンモデル（ここで、４パラメータは、変数ａ、ｂ、ｅ及びｆとして定義されている）及び式（２）の６パラメータアフィンモデル（ここで、６パラメータは、ａ、ｂ、ｃ、ｄ、ｅ及びｆとして定義されている。）によりそれぞれ、次の式によって記述される。

【0300】

【数30】

【0301】

ここで、（ｍｖｈ０、ｍｖｈ０）は、左上隅の制御点の動きベクトルであり、（ｍｖｈ１、ｍｖｈ１）は、右上隅の制御点の動きベクトルであり、（ｍｖｈ２、ｍｖｈ２）は、左下隅の制御点の動きベクトルであり、これら３つの動きベクトルは全てが制御点動きベクトル（ＣＰＭＶ）と呼ばれ、（ｘ、ｙ）は、現在のブロック内の左上サンプルに対する代表点の座標を表し、（ｍｖｈ（ｘ、ｙ）、ｍｖｖ（ｘ、ｙ））は、（ｘ、ｙ）に位置しているサンプルについて導出された動きベクトルである。ＣＰ動きベクトルは、シグナリング（アフィンＡＭＶＰモードと同様）されるか又はオンザフライで導出（アフィンモードと同様）されてよい。ｗ及びｈは、現在のブロックの幅及び高さである。実際に、分割は、丸め演算付き右シフトによって実施される。ＶＴＭでは、代表点は、サブブロックの中心位置であるよう定義され、例えば、現在のブロック内の左上サンプルに対するサブブロックの左上隅の座標が（ｘｓ、ｙｓ）である場合に、代表点の座標は、（ｘｓ＋２、ｙｓ＋２）であるよう定義される。各サブブロック（すなわち、ＶＴＭでは４×４）について、代表点は、そのサブブロック全体の動きベクトルを導出するために利用される。

【0302】

動き補償予測をさらに簡素化するために、サブブロックベースのアフィン変換予測が適用される。各Ｍ×Ｎサブブロック（Ｍ及びＮは両方とも、現在のＶＶＣでは、４にセットされる。）の動きベクトルを導出するために、図１７に示される各サブブロックの中心サンプルの動きベクトルは、式（２５）及び（２６）に従って計算され、１／１６分数精度に丸められ得る。次いで、１／１６ペルのための動き補償補間フィルタが、導出された動きベクトルにより各サブブロックの予測を生成するために適用される。１／１６ペルのための補間フィルタがアフィンモードによって導入される。

【0303】

ＭＣＰの後、各サブブロックの高精度動きベクトルは丸められ、通常の動きベクトルと同じ精度としてセーブされる。

【0304】

２．５．１ アフィン予測のシグナリング
並進運動モデルと同様に、アフィンモデルによるサイド情報をシグナリングするための２つのモードもある。それらは、ＡＦＦＩＮＥ＿ＩＮＴＥＲモード及びＡＦＦＩＮＥ＿ＭＥＲＧＥモードである。

【0305】

２．５．２ ＡＦ＿ＩＮＴＥＲモード
幅及び高さの両方が８よりも大きいＣＵについては、ＡＦ＿ＩＮＴＥＲモードが適用され得る。ＣＵレベルでのアフィンフラグは、ＡＦ＿ＩＮＴＥＲモードが使用されるかどうかを示すためにビットストリームでシグナリングされる。

【0306】

このモードで、各参照ピクチャリスト（Ｌｉｓｔ０又はＬｉｓｔ１）について、アフィンＡＭＶＰ候補リストは、次の順序で３つのタイプのアフィン動き予測子により構成され、各候補は、現在のブロックの推定されたＣＰＭＶを含む。エンコーダ側で見つけられた最良のＣＰＭＶ（例えば、図１８ａ及び図１８ｂのｍｖ_０、ｍｖ_１、ｍｖ_２）と推定されたＣＰＭＶとの差がシグナリングされる。加えて、推定されたＣＰＭＶが導出されるアフィンＡＭＶＰ候補のインデックスがさらにシグナリングされる。

【0307】

１）遺伝的アフィン動き予測子
検査順序は、ＨＥＶＣ ＡＭＶＰリスト構成における空間ＭＶＰのそれと同様である。最初に、現在のブロックと同じ参照ピクチャを有し、アフィンコーディングされている｛Ａ１、Ａ０｝内の最初のブロックから、左側の遺伝的アフィン動き予測子が導出される。第２に、現在のブロックと同じ参照ピクチャを有し、アフィンコーディングされている｛Ｂ１、Ｂ０、Ｂ２｝内の最初のブロックから、上側の遺伝的アフィン動き予測子が導出される。５つのブロックＡ１、Ａ０、Ｂ１、Ｂ０、Ｂ２は図１９に表されている。

【0308】

隣接するブロックがアフィンモードでコーディングされていると分かると、隣接するブロックをカバーするコーディングユニットのＣＰＭＶは、現在のブロックのＣＰＭＶの予測子を導出するために使用される。例えば、Ａ１が非アフィンモードでコーディングされ、Ａ０が４パラメータアフィンモードでコーディングされる場合に、左側の遺伝的アフィンＭＶ予測子はＡ０から導出されることになる。この場合に、図１８ｂで左上ＣＰＭＶについてはＭＶ_０ ^Ｎ及び右上ＣＰＭＶについてはＭＶ_１ ^Ｎによって表されている、Ａ０をカバーするＣＵのＣＰＭＶは、現在のブロックの左上位置（座標（ｘ０、ｙ０）を有する）、右上位置（座標（ｘ１、ｙ１）を有する）及び右下位置（座標（ｘ２、ｙ２）を有する）についてＭＶ_０ ^Ｃ、ＭＶ_１ ^Ｃ、ＭＶ_２ ^Ｃによって表される現在のブロックの推定されたＣＰＭＶを導出するために利用される。

【0309】

２）構成されたアフィン動き予測子
構成されたアフィン動き予測子は、同じ参照ピクチャを有している、図２０に示されるような隣接するインターコーディングされたブロックから導出される制御点動きベクトル（ＣＰＭＶ）から成る。現在のアフィン運動モデルが４パラメータアフィンである場合に、ＣＰＭＶの数は２であり、そうではなく、現在のアフィン運動モデルが６パラメータアフィンである場合に、ＣＰＭＶの数は３である。左上ＣＰＭＶ
〔外１〕

（以降、バーｍｖ_０）は、現在のブロックと同じ参照ピクチャを有している、インターコーディングされているグループ｛Ａ、Ｂ、Ｃ｝内の最初のブロックでのＭＶによって、導出される。右上ＣＰＭＶ
〔外２〕

（以降、バーｍｖ_１）は、現在のブロックと同じ参照ピクチャを有している、インターコーディングされているグループ｛Ｄ、Ｅ｝内の最初のブロックでのＭＶによって、導出される。左下ＣＰＭＶ
〔外３〕

（以降、バーｍｖ_２）は、現在のブロックと同じ参照ピクチャを有している、インターコーディングされているグループ｛Ｆ、Ｇ｝内の最初のブロックでのＭＶによって、導出される。

【0310】

－現在のアフィン運動モデルが４パラメータアフィンである場合に、構成されたアフィン動き予測子は、バーｍｖ_０及びバーｍｖ_１の両方が求められる、つまり、バーｍｖ_０及びバーｍｖ_１が現在のブロックの左上位置（座標（ｘ０、ｙ０）を有する）及び右上位置（座標（ｘ１、ｙ１）を有する）についての推定されたＣＰＭＶとして使用される場合にのみ、候補リストに挿入される。

【0311】

－現在のアフィン運動モデルが６パラメータアフィンである場合に、構成されたアフィン動き予測子は、バーｍｖ_０、バーｍｖ_１、及びバーｍｖ_２が全て求められる、つまり、バーｍｖ_０、バーｍｖ_１、及びバーｍｖ_２が現在のブロックの左上位置（座標（ｘ０、ｙ０）を有する）、右上位置（座標（ｘ１、ｙ１）を有する）及び右下位置（座標（ｘ２、ｙ２）を有する）についての推定されたＣＰＭＶとして使用される場合にのみ、候補リストに挿入される。

【0312】

構成されたアフィン動き予測子を候補リストに挿入する場合に、プルーニングプロセスは適用されない。

【0313】

３）通常のＡＭＶＰ動き予測子
以下は、アフィン動き予測子の数が最大値に達するまで適用される。

【0314】

ｉ．利用可能である場合に全てのＣＰＭＶをバーｍｖ_２に等しくセットすることによってアフィン動き予測子を導出する。

【0315】

ｉｉ．利用可能である場合に全てのＣＰＭＶをバーｍｖ_１に等しくセットすることによってアフィン動き予測子を導出する。

【0316】

ｉｉｉ．利用可能である場合に全てのＣＰＭＶをバーｍｖ_０に等しくセットすることによってアフィン動き予測子を導出する。

【0317】

ｉｖ．利用可能である場合に全てのＣＰＭＶをＨＥＶＣ ＴＭＶＰに等しくセットすることによってアフィン動き予測子を導出する。

【0318】

ｖ．全てのＣＰＭＶをゼロＭＶにセットすることによってアフィン動き予測子を導出する。

【0319】

留意されるべきは、
〔外４〕

（以降、バーｍｖ_ｉ）は、構成されたアフィン運動では既に導出されている点である。

【0320】

ＡＦ＿ＩＮＴＥＲモードでは、４又は６パラメータアフィンモードが使用される場合に、２又は３つの制御点が必要とされるので、２つ又は３つのＭＶＤが、図１８ａ及び図１８ｂに示されるように、それらの制御点に対してコーディングされる必要がある。ＪＶＥＴ－Ｋ０３３７では、ＭＶを次のように導出することが提案されており、すなわち、ｍｖｄ_０からｍｖｄ_１及びｍｖｄ_２が予測される。

【0321】

【数31】

【0322】

ここで、バーｍｖ_ｉ、ｍｖｄ_ｉ及びｍｖ_ｉは、図１８（ｂ）に示されるように、それぞれ、左上ピクセル（ｉ＝０）、右上ピクセル（ｉ＝１）、又は左下ピクセル（ｉ＝２）の予測された動きベクトル、動きベクトル差分及び動きベクトルである。なお、２つの動きベクトル（例えば、ｍｖＡ（ｘＡ、ｙＡ）及びｍｖＢ（ｘＢ、ｙＢ））の追加は、別々に２つの成分の和に等しい。すなわち、ｎｅｗＭＶ＝ｍｖＡ＋ｍｖＢであり、ｎｅｗＭＶの２つの成分はそれぞれ、（ｘＡ＋ｘＢ）及び（ｙＡ＋ｙＢ）にセットされる。

【0323】

２．５．２．１ ＡＦ＿ＭＥＲＧＥモード
ＣＵがＡＦ＿ＭＥＲＧＥモードで適用される場合に、それは、有効な隣接する再構成されたブロックからアフィンモードによりコーディングされた最初のブロックを得る。図２１はＡＦ＿ＭＥＲＧＥの候補を示す。候補ブロックの選択順序は、図２１ａに示されるように、左から、上、右上、左下、左上へである（順にＡ、Ｂ、Ｃ、Ｄ、Ｅによって表される）。例えば、隣接する左下ブロックが、図２１ｂでＡ０によって表されるように、アフィンモードでコーディングされる場合に、ブロックＡを含む隣接するＣＵ／ＰＵの左上隅、右上隅、及び左下隅の制御点（ＣＰ）動きベクトルｍｖ_０ ^Ｎ、ｍｖ_１ ^Ｎ及びｍｖ_２ ^Ｎがフェッチされる。そして、現在のＣＵ／ＰＵ上の左上隅／右上／左下の動きベクトルｍｖ_０ ^Ｃ、ｍｖ_１ ^Ｃ及びｍｖ_２ ^Ｃ（６パラメータアフィンモデルのためにのみ使用される）は、ｍｖ_０ ^Ｎ、ｍｖ_１ ^Ｎ及びｍｖ_２ ^Ｎに基づいて計算される。なお、ＶＴＭ－２．０では、現在のブロックがアフィンコーディングされている場合に、左上隅に位置するサブブロック（例えば、ＶＴＭでは、４×４ブロック）は、ｍｖ０を保存し、右上隅にあるサブブロックは、ｍｖ１を保存する。現在のブロックが６パラメータアフィンモデルでコーディングされる場合には、左下隅にあるサブブロックは、ｍｖ２を保存し、そうでない（４パラメータアフィンモデルによる）場合には、ＬＢはｍｖ２’を保存する。他のサブブロックは、ＭＣのために使用されるＭＶを保存する。

【0324】

現在のＣＵのＣＰＭＶであるｍｖ０Ｃ、ｍｖ１Ｃ及びｍｖ２Ｃが、簡素化されたアフィン運動モデルである式２５及び２６に従って導出された後、現在のＣＵのＭＶＦが生成される。現在のＣＵがＡＦ＿ＭＥＲＧＥモードでコーディングされているかどうかを識別するために、アフィンモードでコーディングされている少なくとも１つの隣接ブロックがある場合に、アフィンフラグがビットストリームでシグナリングされる。

【0325】

ＪＶＥＴ－Ｌ０１４２及びＪＶＥＴ－Ｌ０６３２では、アフィンマージ候補リストは、次のステップで構成される。

【0326】

１）遺伝的アフィン候補の挿入
遺伝によるアフィン候補（inherited affine candidate）とは、候補が、その有効な隣接するアフィンコーディングされたブロックのアフィン運動モデルから導出されることを意味する。最大２つの遺伝的アフィン候補が、隣接ブロックのアフィン運動モデルから導出され、候補リストに挿入される。左側予測子については、走査順序は｛Ａ０、Ａ１｝であり、上側予測子については、走査順序は｛Ｂ０、Ｂ１、Ｂ２｝である。

【0327】

２）構成されたアフィン候補の挿入
アフィンマージ候補リスト内の候補の数がＭａｘＮｕｍＡｆｆｉｎｅＣａｎｄ（例えば、５つ）に満たない場合には、構成されたアフィン候補（constructed affine candidates）が候補リストに挿入される。構成されたアフィン候補とは、候補が、各制御点の隣接動き情報を結合することによって構成されることを意味する。

【0328】

ａ）制御点の動き情報は、最初に、図２２に示されている指定された空間近傍及び時間近傍から導出される。ＣＰｋ（ｋ＝１、２、３、４）は、ｋ番目の制御点を表す。Ａ０、Ａ１、Ａ２、Ｂ０、Ｂ１、Ｂ２及びＢ３は、ＣＰｋ（ｋ＝１、２、３）を予測するための空間的位置である。Ｔは、ＣＰ４を予測するための時間的位置である。

【0329】

ＣＰ１、ＣＰ２、ＣＰ３及びＣＰ４の座標は、それぞれ（０、０）、（Ｗ、０）、（Ｈ、０）及び（Ｗ、Ｈ）であり、ここで、Ｗ及びＨは、現在のブロックの幅及び高さである。

【0330】

各制御点の動き情報は、次の優先順序に従って取得される：
－ＣＰ１については、チェック優先度はＢ２→Ｂ３→Ａ２である。Ｂ２は、それが利用可能である場合に使用される。そうではない場合に、Ｂ３が利用可能であるならば、Ｂ３が使用される。Ｂ２及びＢ３の両方が利用不可能である場合には、Ａ２が使用される。３つ全ての候補が利用不可能である場合には、ＣＰ１の動き情報は取得不可能である。

【0331】

－ＣＰ２については、チェック優先度はＢ１→Ｂ０である。

【0332】

－ＣＰ３については、チェック優先度はＡ１→Ａ０である。

【0333】

－ＣＰ４については、Ｔが使用される。

【0334】

ｂ）第２に、制御点の組み合わせが、アフィンマージ候補を構成するために使用される。

【0335】

－３つの制御点の動き情報が、６パラメータアフィン候補を構成するために必要とされる。３つの制御点は、次の４つの組み合わせ（｛ＣＰ１、ＣＰ２、ＣＰ４｝、｛ＣＰ１、ＣＰ２、ＣＰ３｝、｛ＣＰ２、ＣＰ３、ＣＰ４｝、｛ＣＰ１、ＣＰ３、ＣＰ４｝）のうちの１つから選択され得る。組み合わせ｛ＣＰ１、ＣＰ２、ＣＰ３｝、｛ＣＰ２、ＣＰ３、ＣＰ４｝、｛ＣＰ１、ＣＰ３、ＣＰ４｝は、左上、右上、及び左下制御点によって表される６パラメータ運動モデルへ変換されることになる。

【0336】

－２つの制御点の動きベクトルが、４パラメータアフィン候補を構成するために必要とされる。２つの制御点は、次の２つの組み合わせ（｛ＣＰ１、ＣＰ２｝、｛ＣＰ１、ＣＰ３｝）のうちの１つから選択され得る。２つの組み合わせは、左上及び右上制御点によって表される４パラメータ運動モデルへ変換されることになる。

【0337】

－構成されたアフィン候補の組み合わせは、次の順序：｛ＣＰ１、ＣＰ２、ＣＰ３｝、｛ＣＰ１、ＣＰ２、ＣＰ４｝、｛ＣＰ１、ＣＰ３、ＣＰ４｝、｛ＣＰ２、ＣＰ３、ＣＰ４｝、｛ＣＰ１、ＣＰ２｝、｛ＣＰ１、ＣＰ３｝として候補リストに挿入される。

【0338】

ｉ．組み合わせごとに、各ＣＰのためのリストＸの参照インデックスはチェックされ、それらが全て同じである場合に、この組み合わせはリストＸの有効なＣＰＭＶを有している。組み合わせがリスト０及びリスト１の両方の有効なＣＰＭＶを有してない場合には、この組み合わせは無効とマークされる。そうでない場合には、それは有効であり、ＣＰＭＶはサブブロックマージリストに置かれる。

【0339】

３）ゼロアフィン動きベクトル候補によるパディング
アフィンマージ候補リスト内の候補の数が５よりも少ない場合に、リストがフルになるまでゼロ参照インデックスのゼロ動きベクトルが候補リストに挿入される。

【0340】

より具体的には、サブブロックマージ候補リストについて、４パラメータマージ候補は、ＭＶが（０、０）にセットされ、予測方向がリスト０からの一方向予測（Ｐスライスの場合）及び双方向予測（Ｂスライスの場合）にセットされる。

【0341】

既存の実装の欠点
ＶＶＣに適用する場合、ＡＲＣは以下の課題を有し得る。

【0342】

ＡＬＦ、ルーママッピングクロマスケーリング（ＬＭＣＳ）、デコーダ側動きベクトルリファインメント（ＤＭＶＲ）、双方向光学フロー（ＢＤＯＦ）、アフィン予測、三角予測モード（ＴＰＭ）、対称動きベクトル差（ＳＭＶＤ）、マージ動きベクトル差（ＭＭＶＤ）、インターイントラ予測（ＶＶＣでは併用インターピクチャマージ及びイントラピクチャマージ（ＣＩＩＰ）としても知られている）、局所化照明圧縮（ＬＩＣ）及び履歴ベースの動きベクトル予測（ＨＭＶＰ）等のコーディングツールをＶＶＣに適用されるかは不明である。

【0343】

適応的解像度変換でツールをコーディングするための例示の方法
開示の技術の実施形態は既存の実施の欠点を克服する。以下に示す開示の技術の例は、開示の技術の理解を促進するために議論され、開示の技術を制限する方法で解釈されるべきである。別段明示がない限り、これらの例で説明する様々な特徴は組み合わせることができる。

【0344】

以下の議論では、ＳａｔＳｈｉｆｔ（ｘ、ｎ）は以下のように定義される。

【0345】

【数32】

【0346】

Ｓｈｉｆｔ（ｘ、ｎ）は、Ｓｈｉｆｔ（ｘ、ｎ）＝（ｘ＋ｏｆｆｓｅｔ０）＞＞ｎと定義される。

【0347】

１つの例では、ｏｆｆｓｅｔ０及び／又はｏｆｆｓｅｔ１は、（１＜＜ｎ）＞＞１又は（１＜＜（ｎ－１））に設定される。別の例では、ｏｆｆｓｅｔ０及び／又はｏｆｆｓｅｔ１は０に設定される。

【0348】

別の例では、ｏｆｆｓｅｔ０＝ｏｆｆｓｅｔ１＝（（１＜＜ｎ）＞＞１）－１又は（（１＜＜（ｎ－１）））－１である。

【0349】

Ｃｌｉｐ３（ｍｉｎ、ｍａｘ、ｘ）は以下のように定義される。

【0350】

【数33】

【0351】

Ｆｌｏｏｒ（ｘ）はｘ以下の最も大きい整数として定義される。

【0352】

Ｃｅｉｌ（ｘ）はｘ以上の最も小さい整数である。

【0353】

Ｌｏｇ２（ｘ）はｘの基数-２の対数として定義される。

【0354】

開示の技術の実施の一部の側面を以下に列挙する。

【0355】

１． ＭＭＶＤ／ＳＭＶＤにおけるＭＶオフセット及び／又はデコーダ側導出プロセスにおける精密化された動きベクトルの導出は、現在のブロックに関連する参照ピクチャの解像度及び現在のピクチャの解像度に依存し得る。
ａ．例えば、第２の参照ピクチャを参照する第２のＭＶオフセットは、第１の参照ピクチャを参照する第１のＭＶオフセットからスケーリングされ得る。スケーリング係数は、第１及び第２の参照ピクチャの解像度に依存し得る。

【0356】

２． 動き候補リスト構築プロセスは、空間的／時間的／履歴的な動き候補に関連する参照ピクチャ解像度に従って構築され得る。
ａ．１つの例では、解像度がより高い参照ピクチャを参照するマージ候補は、解像度がより低い参照ピクチャを参照するマージ候補よりも高い優先度を有し得る。議論では、Ｗ０＜Ｗ１及びＨ０＜Ｈ１の場合、解像度Ｗ０＊Ｈ０は解像度Ｗ１＊Ｈ１より低い。
ｂ．例えば、マージ候補リストにおいて、解像度がより高い参照ピクチャを参照するマージ候補は解像度がより低い参照ピクチャを参照するマージ候補の前に置かれ得る。
ｃ．例えば、現在のピクチャの解像度よりも低い解像度を有する参照ピクチャを参照する動きベクトルはマージ候補リストに入れることはできない。
ｄ．１つの例では、履歴バッファ（参照テーブル）を更新するかどうか及び／又はどのように更新するかは、デコードされた動き候補に関連する参照ピクチャ解像度に依存し得る。
ｉ．１つの例では、デコードされた動き候補に関連する１つの参照ピクチャが異なる解像度を有する場合、そのような動き候補は履歴バッファを更新するために許可されない。

【0357】

３． ピクチャは、対応する寸法に関連するＡＬＦパラメータでフィルタリングされるべきことが提案される。
ａ．一例では、ＡＰＳのようなビデオユニットでシグナリングするＡＬＦパラメータは、１つまたは複数の画像寸法に関連付けることができる。
ｂ．一例では、ＡＰＳシグナリングＡＬＦパラメータのようなビデオユニットは、１つまたは複数の画像寸法に関連付けることができる。
ｃ．例えば、画像は、同じ寸法に関連付けられたAPSのようなビデオユニットで信号化されたALFパラメータのみを適用することができる。
ｄ．ＰＰＳの解像度/インデックス/解像度の表示は、ＡＬＦ ＡＰＳでシグナリングすることができる。
ｅ．ＡＬＦパラメータは、同じ解像度を持つ画像に対して使用されるものからのみ継承/予測されることがあることが制限される。

【0358】

４． 第１の対応する寸法に関連するＡＬＦパラメータは、第２の対応する寸法に関連するＡＬＦパラメータを継承し得るか又はＡＬＦパラメータから予測され得ることが提案される。
ａ．１つの例では、第１の対応する寸法は、第２の対応する寸法と同じでなければならない。
ｂ．１つの例では、第１の対応する寸法は、第２の対応する寸法と異なり得る。

【0359】

５． ピクチャ内のサンプルは、対応する寸法に関連するＬＭＣＳパラメータで再成形されるべきであることが提案される。
ａ．１つの例では、ＡＰＳ等のビデオユニットでシグナリングされるＬＭＣＳパラメータは、１つ以上のピクチャ寸法に関連し得る。
ｂ．１つの例では、ＬＭＣＳパラメータをシグナリングするＡＰＳ等のビデオユニットは、１つ以上のピクチャ寸法に関連し得る。
ｃ．例えば、ピクチャは、同じ寸法に関連するＡＰＳ等のビデオユニットでシグナリングされるＬＭＣＳパラメータのみを適用し得る。
ｄ．ＰＰＳの解像度／インデックス／解像度の表示は、ＬＭＣＳ ＡＰＳでシグナリングされ得る。
ｅ．ＬＭＣＳパラメータは、同じ解像度を有するピクチャに対して用いられるものからのみ継承／予測され得ると制限される。

【0360】

６． 第１の対応する寸法に関連するＬＭＣＳパラメータは、第２の対応する寸法に関連するＬＭＣＳパラメータを継承し得るか又は予測され得ることが提案される。
ａ．１つの例では、第１の対応する寸法は、第２の対応する寸法と同じでなければならない。
ｂ．１つの例では、第１の対応する寸法は、第２の対応する寸法と異なり得る。

【0361】

７． ＴＰＭ（三角予測モード）／ＧＥＯ（幾何学的分割を用いたインター予測）又は１つのブロックを２つ又は複数のサブパーティションに分割し得る他のコーディングツールを有効にするかどうか及び／又はどのように有効にするかは、２つ又は複数のサブパーティションの関連する参照ピクチャ情報によって決まる。
ａ．１つの例では、それは、２つの参照ピクチャのうちの１つの解像度及び現在のピクチャの解像度に依存し得る。
ｉ．１つの例では、２つの参照ピクチャのうちの少なくとも１つが現在のピクチャと比較して異なる解像度に関連する場合、そのようなコーディングツールは無効にされる。
ｂ．１つの例では、それは、２つの参照ピクチャの解像度が同じかどうかに依存し得る。
ｉ．１つの例では、２つの参照ピクチャが異なる解像度と関連する場合、そのようなコーディングツールは無効にされ得る。
ｉｉ．１つの例では、２つの参照ピクチャの両方が現在のピクチャと比較して異なる解像度に関連する場合、そのようなコーディングツールは無効にされる。
ｉｉｉ．あるいは、２つの参照ピクチャの両方が現在のピクチャと比較して異なる解像度に関連するが、２つの参照ピクチャが同じ解像度の場合、そのようなコーディングツールは依然として無効にされ得る。
ｉｖ．あるいは、参照ピクチャのうちの少なくとも１つが現在のピクチャとは異なる解像度を有し、参照ピクチャが異なる解像度を有する場合、コーディングツールＸは無効にされ得る。
ｃ．あるいは、さらに、２つの参照ピクチャが同じ参照ピクチャであるかどうかに依存し得る。
ｄ．あるいは、さらに、２つの参照ピクチャが同じ参照リストにあるかどうかに依存し得る。
ｅ．あるいは、そのようなコーディングツールは、ＲＰＲ（参照ピクチャの再サンプリングがスライス／ピクチャヘッダ／シーケンスパラメータセットで有効)の場合、常に無効にされ得る。

【0362】

８． ブロックが現在のピクチャとは異なる寸法を有する少なくとも１つの参照ピクチャを参照する場合、該ブロックに対してコーディングツールＸが無効にされ得ることが提案される。
ａ．１つの例では、コーディングツールＸに関する情報はシグナリングされなくてもよい。
ｂ．１つの例では、そのようなブロックの動き情報はＨＭＶＰテーブルに挿入されなくてもよい。
ｃ．あるいは、ブロックにコーディングツールＸが適用される場合、ブロックは、現在のピクチャとは異なる寸法の参照ピクチャを参照することができない。
ｉ．１つの例では、現在のピクチャとは異なる寸法を有する参照ピクチャを参照するマージ候補はスキップされ得るか又はマージ候補リストに入れられない。
ｉｉ．１つの例では、現在のピクチャとは異なる寸法の参照ピクチャに対応する参照インデックスはスキップされ得るか又はシグナリングされることが許可されない。
ｄ．あるいは、コーディングツールＸは、現在のピクチャの解像度及び参照ピクチャの解像度に従って２つの参照ブロック又はピクチャをスケーリングした後で適用され得る。
ｅ．あるいは、コーディングツールＸは、現在のピクチャの解像度及び参照ピクチャの解像度に従って２つのＭＶ又はＭＶＤをスケーリングした後で適用され得る。
ｆ．１つの例では、ブロック（例えば、異なる参照ピクチャ又は異なるＭＶを有する同じ参照ピクチャリストからの複数仮説を有するブロック又は双方向コード化ブロック又は異なる参照ピクチャリストからの複数仮説を有するブロック）について、コーディングツールＸを無効にするか又は有効にするかは、参照ピクチャリスト及び／又は現在の参照ピクチャに関連する参照ピクチャの解像度に依存し得る。
ｉ．１つの例では、コーディングツールＸは一方の参照ピクチャリストについて無効にされ得るが、他方の参照ピクチャリストについては有効であり得る。
ｉｉ．１つの例では、コーディングツールＸは一方の参照ピクチャについては無効にされ得るが、他方の参照ピクチャについては有効であり得る。ここで、２つの参照ピクチャは異なる参照ピクチャリスト又は同じ参照ピクチャリストからのものであり得る。
ｉｉｉ．１つの例では、各参照ピクチャリストＬについて、コーディングツールの有効化／無効化は、リストＬとは異なる他の参照ピクチャリスト内の参照ピクチャに関係なく決定される。
１．１つの例では、リストＬの参照ピクチャ及び現在のピクチャによって決定され得る。
２．１つの例では、リストＬの関連する参照ピクチャが現在のピクチャと異なる場合、ツールはリストＬについて無効にされ得る。
ｉｖ．あるいは、コーディングツールの有効化／無効化は、全ての参照ピクチャ及び／又は現在のピクチャの解像度によって決定される。
１．１つの例では、参照ピクチャのうちの少なくとも１つが現在のピクチャと異なる解像度を有する場合、コーディングツールＸは無効にされ得る。
２．１つの例では、参照ピクチャのうちの少なくとも１つが現在のピクチャと異なる解像度を有するが、参照ピクチャ同士が同じ解像度を有する場合、コーディングツールＸは依然有効にされ得る。
３．１つの例では、参照ピクチャのうちの少なくとも１つが現在のピクチャと異なる解像度を有し、参照ピクチャ同士が異なる解像度を有する場合、コーディングツールＸは無効にされ得る。
ｇ．コーディングツールＸは以下のいずれかであり得る。
ｉｉｉ．ＤＭＶＲ
ｉｖ．ＢＤＯＦ
ｖ．アフィン予測
ｖｉ．三角形予測モード
ｖｉｉ．ＳＭＶＤ
ｖｉｉｉ．ＭＭＶＤ
ｉｘ．ＶＶＣにおけるインターイントラ予測
ｘ．ＬＩＣ
ｘｉ．ＨＭＶＰ
ｘｉｉ．複数変換セット（ＭＴＳ）
ｘｉｉｉ．サブブロック変換（ＳＢＴ）
ｘｉｖ．ＰＲＯＦ及び／又は他のデコード側の動き/予測の精緻化方法
ｘｖ．ＬＦＮＳＴ（低周波非二乗変換）
ｘｖｉ．フィルタリング方法（例：デブロッキングフィルタ／ＳＡＯ/ＡＬＦ）
ｘｖｉｉ．ＧＥＯ/ＴＰＭ/クロスコンポーネントＡＬＦ

【0363】

９． ピクチャの参照ピクチャリストに含まれる異なる解像度はＫ個以下である。
ａ．１つの例では、Ｋ＝２である。

【0364】

１０． Ｎ個の連続する（デコーディング順序又は表示順序）ピクチャに対して、Ｋ個以下の異なる解像度しか許容されない。
ａ．１つの例では、Ｎ＝３、Ｋ＝３である。
ｂ．１つの例では、Ｎ＝１０、Ｋ＝３である。
ｃ．１つの例では、ＧＯＰにおいてＫ個以下の異なる解像度しか許容されない。
ｄ．１つの例では、同じ特定の時間的レイヤＩＤ（ｔｉｄと表記される）を有する２つのピクチャの間で、Ｋ個以下の異なる解像度しか許容されない。
ｉ．例えば、Ｋ＝３、ｔｉｄ＝０である。

【0365】

１１． 解像度変更は、イントラピクチャに対してしか許容されない。

【0366】

１２． １つのブロックの１つ又は２つの参照ピクチャが現在のピクチャとは異なる解像度を有する場合、デコーディングプロセスにおいて双方向予測は単方向予測に変換され得る。
ａ．１つの例では、現在のピクチャと異なる解像度を有する対応する参照ピクチャを有するリストＸからの予測が破棄され得る。

【0367】

１３． 異なる解像度の参照ピクチャからのインター予測を有効又は無効にするかどうかは、動きベクトル精度及び／又は解像度比に依存し得る。
ａ．１つの例では、解像度比に従ってスケーリングされた動きベクトルが整数位置を指す場合、インター予測が依然として適用され得る。
ｂ．１つの例では、解像度比に従ってスケーリングされた動きベクトルが、ＡＲＣを伴わない場合に許容されるサブペル位置（例えば、１／４ペル）を指す場合、インター予測が依然として適用され得る。
ｃ．あるいは、両方の参照ピクチャが現在のピクチャとは異なる解像度を持つ場合、双方向予測が許可されないことがある。
ｄ．あるいは、一方の参照ピクチャが現在のピクチャと異なる解像度を有し、他方が同じ解像度を有する場合に、双方向予測が有効にされ得る。
ｅ．あるいは、参照ピクチャが現在のピクチャとは異なる解像度を有し、ブロック寸法が一定の条件を満たす場合、該ブロックに対して単方向予測が禁止され得る。

【0368】

１４． デコーディングツールＸが無効であるかどうかを示す第１のフラグ（例えば、pic_disable_X_flag）は、ピクチャヘッダでシグナリングされ得る。
ａ．スライス／タイル／ブリック／サブピクチャ／ピクチャよりも小さい他のビデオユニットに対するデコーディングツールを有効にするかどうかは、ピクチャヘッダ内のこのフラグ及び／又はスライスタイプによって制御され得る。
ｂ．１つの例では、第１のフラグが真の場合、デコーディングツールＸは無効にされる。
ｉ．あるいは、第１のフラグが偽の場合、デコーディングツールＸが有効にされる。
ｉｉ．１つの例では、ピクチャ内の全てのサンプルに対してそれが有効／無効にされる。
ｃ．１つの例では、第１のフラグのシグナリングは、ＳＰＳ／ＶＰＳ／ＤＰＳ／ＰＰＳにおけるシンタックス要素又は複数のシンタックス要素に依存し得る。
ｉ．１つの例では、フラグのシグナリングは、ＳＰＳにおけるデコーディングツールＸの有効フラグに依存し得る。
ｉｉ．あるいは、さらに、ピクチャヘッダ内の第１のフラグの存在を示す第２のフラグ（例えば、sps_X_slice_present_flag）がＳＰＳにおいてシグナリングされ得る。
１）あるいは、さらに、コーディングツールＸがシーケンスに対して有効である場合（例えば、sps_X_enabled_flagが真である場合）、第２のフラグは条件付きでシグナリングされ得る。
２）あるいは、さらに、第２のフラグのみが第１のフラグが存在することを示し、第１のフラグはピクチャヘッダにおいてシグナリングされ得る。
ｄ．１つの例では、第１及び／又は第２のフラグは１ビットでコーディングされる。
ｅ．デコーディングツールＸは以下のようになり得る。
ｉ．１つの例では、デコーディングツールＸはＰＲＯＦである。
ｉｉ．１つの例では、デコーディングツールＸはＤＭＶＲである。
ｉｉｉ．１つの例では、デコーディングツールＸはＢＤＯＦである
ｉｖ．１つの例では、デコーディングツールＸはクロスコンポーネントＡＬＦである。
ｖ．１つの例では、デコーディングツールＸはＧＥＯである。
ｖｉ．１つの例では、デコーディングツールＸはＴＰＭである。
ｖｉｉ．１つの例では、デコーディングツールＸはＭＴＳである。

【0369】

１５． ブロックが、現在のピクチャと異なる寸法を有する参照ピクチャを参照できるかどうかは、ブロックの幅（ＷＢ）及び／又は高さ（ＨＢ）及び／又はブロック予測モード（すなわち、双方向予測又は短方向予測）に依存し得る。
ａ．１つの例では、ブロックは、ＷＢ＞＝Ｔ１及びＨＢ＞＝Ｔ２の場合、例えば、Ｔ１＝Ｔ２＝８の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｂ．１つの例では、ブロックは、ＷＢ＊ＨＢ＞＝Ｔの場合、例えば、Ｔ１＝６４の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｃ．１つの例では、ブロックは、Ｍｉｎ（ＷＢ、ＨＢ）＞＝Ｔの場合、例えば、Ｔ＝８の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｄ．１つの例では、ブロックは、Ｍａｘ（ＷＢ、ＨＢ）＞＝Ｔの場合、例えば、Ｔ＝８の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｅ．１つの例では、ブロックは、ＷＢ＜＝Ｔ１及びＨＢ＜＝Ｔ２の場合、例えば、Ｔ１＝Ｔ２＝６２の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｆ．１つの例では、ブロックは、ＷＢ＊ＨＢ＜＝Ｔの場合、例えば、Ｔ１＝４０９６の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｇ．１つの例では、ブロックは、Ｍｉｎ（ＷＢ、ＨＢ）＜＝Ｔの場合、例えば、Ｔ＝６４の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｈ．１つの例では、ブロックは、Ｍａｘ（ＷＢ、ＨＢ）＜＝Ｔの場合、例えば、Ｔ＝６４の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照できる。
ｉ．あるいは、ブロックは、ＷＢ＜＝Ｔ１及び／又はＨＢ＜＝Ｔ２の場合、例えば、Ｔ１＝Ｔ２＝８の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照することが禁止される。
ｊ．あるいは、ブロックは、ＷＢ＜＝Ｔ１及び／又はＨＢ＜＝Ｔ２の場合、例えば、Ｔ１＝Ｔ２＝８の場合、現在のピクチャとは異なる寸法を有する参照ピクチャを参照することが禁止される。

【0370】

図２３は、ビデオ処理のための例示の方法のフローチャートを示す。図２３を参照して、方法２３００は、ステップ２３１０で、現在のビデオブロックと現在のビデオブロックのビットストリーム表現との間での変換の間に、現在のビデオブロックに関連する参照ピクチャの解像度及び現在のピクチャの解像度に基づいて動きベクトルオフセットを導出することを含む。方法２３００は、ステップ２３２０で、動きベクトルオフセットを用いて変換を行うことをさらに含む。

【0371】

一部の実施では、動きベクトルオフセットを導出することは、第１の参照ピクチャを参照する第１の動きベクトルオフセットを導出することと、第１の動きベクトルオフセットに基づいて、第２の参照ピクチャを参照する第２の動きベクトルオフセットを導出するステップとを含む。一部の実施では、本方法は、現在のビデオブロックに対して、空間的、時間的又は履歴的動き候補に関連する参照ピクチャ解像度に基づく動き候補リスト構築プロセスを行うことをさらに含む。一部の実施では、ルックアップテーブルを更新するかどうか又はどのように更新するかは、デコーされた動き候補に関連する参照ピクチャ解像度によって決まる。一部の実施では、本方法は、現在のピクチャに対して、対応する寸法に関連する適応ループフィルタ（ＡＬＦ）パラメータを用いてフィルタリング動作を行うことをさらに含む。一部の実施では、ＡＬＦパラメータは、第１の対応する寸法に関連する第１のＡＬＦパラメータと、第２の対応する寸法に関連する第２のＡＬＦパラメータとを含み、第２のＡＬＦパラメータは、第１のＡＬＦパラメータから継承されるか又は予測される。

【0372】

一部の実施では、本方法は、対応する寸法に関連するＬＭＣＳ（ルーママッピングクロマスケーリング）パラメータを用いて、現在のピクチャ内のサンプルを再成形することをさらに含む。一部の実施では、ＬＭＣＳパラメータは、第１の対応する寸法に関連する第１のＬＭＣＳパラメータと、第２の対応する寸法に関連する第２のＬＭＣＳパラメータとを含み、第２のＬＭＣＳパラメータは第１のＬＭＣＳパラメータから継承されるか又は予測される。一部の実施では、ビデオユニット内でシグナリングされるＡＬＦパラメータ又はＬＭＣＳパラメータは、１つ又は複数のピクチャ寸法に関連する。一部の実施では、本方法は、現在のビデオブロックが、現在のピクチャとは異なる寸法を有する少なくとも１つの参照ピクチャを参照する場合に、現在のビデオブロックに対してコーディングツールを無効にすることをさらに含む。一部の実施では、本方法は、現在のピクチャの寸法から異なる寸法を有する参照ピクチャを参照するマージ候補をスキップすること又は省略することをさらに含む。一部の実施では、本方法は、参照ピクチャの解像度及び現在ピクチャの解像度に基づいて、２つの参照ブロック又は２つの参照ピクチャをスケーリングした後で又は参照ピクチャの解像度及び現在ピクチャの解像度に基づいて、２つのＭＶ又はＭＶＤをスケーリングした後で、コーディングツールを適用することをさらに含む。一部の実施では、現在のピクチャは異なる解像度をＫ個以下しか含まず、Ｋは自然数である。一部の実施では、Ｎ個の連続したピクチャに対してＫ個の異なる解像度が許容され、Ｎは自然数である。

【0373】

一部の実施では、本方法は、イントラピクチャである現在のピクチャに対して解像度変更を適用することをさらに含む。一部の実施では、本方法は、現在のビデオブロックの１つ又は２つの参照ピクチャが現在のピクチャの解像度と異なる解像度を有する場合に、双方向き予測を単方向予測に変換することをさらに含む。一部の実施では、本方法は、現在のブロック寸法と参照ブロック寸法との間の解像度比又は動きベクトル精度のうちの少なくとも１つによって決まり、異なる解像度の参照ピクチャからのインター予測を有効又は無効にすることをさらに含む。現在のブロック寸法がＷ＊Ｈとすると、参照ブロック寸法はＷ１＊Ｈ１であり、解像度比はＷ１／Ｗ、Ｈ１／Ｈ、（Ｗ１＊Ｈ１）／（Ｗ＊Ｈ）、ｍａｘ（Ｗ１／Ｗ、Ｈ１／Ｈ）又はｍｉｎ（Ｗ１／Ｗ、Ｈ１／Ｈ）等を参照し得る。一部の実施では、本方法は、両方の参照ピクチャ又は一方の参照ピクチャが現在のピクチャとは異なる解像度を有するかどうかに応じて、双方向予測を適用することをさらに含む。一部の実施では、現在のビデオブロックが現在のピクチャとは異なる寸法を有する参照ピクチャを参照するかどうかは、現在のビデオブロックのサイズ又はブロック予測モードのうちの少なくとも１つによって決まる。一部の実施では、変換を行うことは、ビットストリーム表現から現在のビデオブロックを生成することを含む。一部の実施では、変換を行うことは、現在のビデオブロックからビットストリーム表現を生成することを含む。

【0374】

図２４Ａは、ビデオ処理装置２４００のブロック図である。装置２４００は、本明細書で説明する方法のうちの１つ以上を実施するために用いられ得る。装置２４００は、スマートフォン、タブレット、コンピュータ、モノのインターネット（ＩｏＴ）受信機等で具体化され得る。装置２４００は、１つ以上のプロセッサ２４０２、１つ以上のメモリ２４０４及びビデオ処理ハードウェア２４０６を含み得る。プロセッサ２４０２は、本明細書で説明する１つ以上の方法（限定されないが、方法２３００を含む）を実施するように構成され得る。メモリ（複数のメモリ）２４０４は、本明細書で説明する方法及び技術を実施するために用いられるデータ及びコードを記憶するために用いられ得る。ビデオ処理ハードウェア２４０６は、ハードウェア回路で、本明細書で説明するいくつかの技術を実施するために用いられ得る。一部の実施では、ハードウェア２４０６は、例えばグラフィックスプロセッサとして、完全に又は部分的にプロセッサ２４０１内にあり得る。

【0375】

図２４Ｂは、本明細書に開示の様々な技術が実施され得る例示のビデオ処理システム２４１０を示すブロック図である。様々な実施は、システム２４１００の構成要素の一部又は全てを含み得る。システム２４１０は、ビデオコンテンツを受信するための入力２４１２を含み得る。ビデオコンテンツは生の状態又は非圧縮形式で、例えば８又は１０ビットの多成分画素値で受信され得るか又は圧縮又はエンコード形式で受信され得る。入力２４１２は、ネットワークインターフェイス、周辺バスインターフェイス又は記憶インターフェイスを表し得る。ネットワークインターフェイスの例としては、イーサネット、受動光ネットワーク（ＰＯＮ）等の有線インターフェイス等及びＷｉ－Ｆｉ又はセルラーインターフェイス等の無線インターフェイスが挙げられる。

【0376】

システム２４１０は、本明細書で説明する様々なコーディング又はエンコーディング方法を実施し得るコーディングコンポーネント２４１４を含み得る。コーディングコンポーネント２４１４は、入力２４１２からコーディングコンポーネント２４１４の出力へのビデオの平均ビットレートを低減して、ビデオのコード化表現を生成し得る。したがって、コーディング技術は、ビデオ圧縮又はビデオトランスコーディング技術と呼ばれることがある。コーディングコンポーネント２４１４の出力は格納されるか又はコンポーネント２４１６によって表されるように、通信接続を介して送信され得る。入力２４１２で受信されたビデオの格納又は通信されたビットストリーム（又はコード化）表現は、ディスプレイインターフェイス２４２０に送られる表示可能なビデオ又は画素値を生成するためにコンポーネント２４１８によって用いられ得る。ビットストリーム表現からユーザが視聴可能なビデオを生成するプロセスは、ビデオ解凍と時々呼ばれる。さらに、特定のビデオ処理動作は、「コーディング」動作又はツールと呼ばれるが、コーディングツール又は動作はエンコーダで用いられ、コーディングの結果を反転する対応するデコーディングツール又は動作はデコーダで行われることになるのが理解されよう。

【0377】

周辺バスインターフェイス又はディスプレイインターフェイスの例としては、ユニバーサルシリアルバス（ＵＳＢ）又は高精細度マルチメディアインターフェイス（ＨＤＭＩ（登録商標））又はディスプレイポート等が挙げられる。記憶インターフェイスの例としては、ＳＡＴＡ（serial advanced technology attachment）、ＰＣＩ、ＩＤＥインターフェイス等が挙げられる。本明細書で説明する技術は、携帯電話、ラップトップ、スマートフォン又はデジタルデータ処理及び／又はビデオ表示を行うことが可能な他の装置といった様々な電子装置で具現化され得る。

【0378】

一部の実施では、ビデオコーディング方法は、図２４Ａ又は図２４Ｂに関して説明したようなハードウェアプラットフォーム上に実施される装置を用いて実施され得る。

【0379】

図２５は、本開示の技術を利用し得る例示のビデオコーディングシステム１００を示すブロック図である。

【0380】

図２５に示すように、ビデオコーディングシステム１００はソース装置１１０及び宛先装置１２０を含み得る。ソース装置１１０はエンコードされたビデオデータを生成し、ビデオコーディング装置と呼ばれ得る。宛先装置１２０は、ソース装置１１０によって生成されたエンコードされたビデオデータをデコードし、ビデオデコーデイング装置と呼ばれ得る。

【0381】

ソース装置１１０は、ビデオソース１１２、ビデオエンコーダ１１４及び入出力インターフェイス１１６を含み得る。

【0382】

ビデオソース１１２は、ビデオキャプチャ装置等のソース、ビデオコンテンツプロバイダからビデオデータを受信するためのインターフェイス及び／又はビデオデータを生成するためのコンピュータグラフィックスシステム又はそのようなソースの組み合わせを含み得る。ビデオデータは１つ以上のピクチャを含み得る。ビデオエンコーダ１１４は、ビットストリームを生成するためにビデオソース１１２からのビデオデータをエンコードする。ビットストリームは、ビデオデータのコード化表現を形成するビットのシーケンスを含み得る。ビットストリームは、コード化されたピクチャ及び関連するデータを含み得る。コード化されたピクチャはピクチャのコード化された表現である。関連するデータは、シーケンスパラメータセット、ピクチャパラメータセット及び他のシンタックス構造を含み得る。Ｉ／Ｏインターフェイス１１６は、変調器／復調器（モデム）及び／又は送信器を含み得る。エンコードされたビデオデータは、ネットワーク１３０ａを介してＩ／Ｏインターフェイス１１６を介して宛先装置１２０に直接送信され得る。エンコードされたビデオデータは、宛先装置１２０によるアクセスのために記憶媒体／サーバ１３０ｂにも記憶され得る。

【0383】

宛先装置１２０は、Ｉ／Ｏインターフェイス１２６、ビデオデコーダ１２４及びディスプレイ装置１２２を含み得る。

【0384】

Ｉ／Ｏインターフェイス１２６は受信器及び／又はモデムを含み得る。Ｉ／Ｏインターフェイス１２６は、ソース装置１１０又は記憶媒体／サーバ１３０ｂからエンコードされたビデオデータを取得し得る。ビデオデコーダ１２４は、エンコードされたビデオデータをデコードし得る。ディスプレイ装置１２２は、デコードされたビデオデータをユーザに表示し得る。ディスプレイ装置１２２は宛先装置１２０と一体化され得るか又は外部ディスプレイ装置とやりとりするように構成された宛先装置１２０の外部にあってもよい。

【0385】

ビデオエンコーダ１１４及びビデオデコーダ１２４は、高効率ビデオコーディング（ＨＥＶＣ）規格、汎用ビデオコーディング（ＶＶＣ）規格及びその他の現在の及び／又は更なる規格等のビデオ圧縮規格に従って動作し得る。

【0386】

図２６は、図２５に示すシステム１００内のビデオエンコーダ１１４であり得るビデオエンコーダ２００の一例を示すブロック図である。

【0387】

ビデオエンコーダ２００は、本開示の技術のいずれか又は全てを行うように構成され得る。図２６の例では、ビデオエンコーダ２００は複数の機能コンポーネントを含む。本開示で説明する技術は、ビデオエンコーダ２００の様々なコンポーネントの間で共有され得る。一部の例では、プロセッサは、本開示で説明する技術のいずれか又は全てを行うように構成され得る。

【0388】

ビデオエンコーダ２００の機能コンポーネントは、分割ユニット２０１と、モード選択ユニット２０３、動き推定ユニット２０４、動き補償ユニット２０５及びイントラ予測ユニット２０６を含み得る予測ユニット２０２と、残差生成ユニット２０７と、変換ユニット２０８と、量子化ユニット２０９と、逆量子化ユニット２１０と、逆変換ユニット２１１と、再構成ユニット２１２と、バッファ２１３と、エントロピーエンコーディングユニット２１４とを含み得る。

【0389】

他の例では、ビデオエンコーダ２００はより多くの、より少ない又は異なる機能コンポーネントを含み得る。１つの例では、予測ユニット２０２は、イントラブロックコピー（ＩＢＣ）ユニットを含み得る。ＩＢＣユニットは、少なくとも１つの参照ピクチャが現在のビデオブロックが位置するピクチャであるＩＢＣモードで予測を行い得る。

【0390】

さらに、動き推定ユニット２０４及び動き補償ユニット２０５等の一部のコンポーネントは高度に統合されてもよいが、説明のために図２６の例では別々に表されている。

【0391】

分割ユニット２０１は、ピクチャを１つ以上のビデオブロックに分割し得る。ビデオエンコーダ２００及びビデオデコーダ３００は様々なビデオブロックサイズをサポートし得る。

【0392】

モード選択ユニット２０３は、例えばエラー結果に基づいて、コーディングモード（イントラ又はインター）のうちの１つを選択し、結果として得られたイントラ又はインターコード化ブロックを、残差ブロックデータを生成するために残差生成ユニット２０７に、参照ピクチャとして用いるためにエンコードされたブロックを再構成するために再構成ユニット２１２に提供する。一部の例では、モード選択ユニット２０３は、予測がインター予測信号及びイントラ予測信号に基づく、イントラ及びインター予測（ＣＩＩＰ）モードの組み合わせを選択し得る。モード選択ユニット２０３は、インター予測の場合に、ブロックための動きベクトルの解像度（例えば、サブピクセル又は整数ピクセル精度）も選択し得る。

【0393】

現在のビデオブロックにインター予測を行うために、動き推定ユニット２０４は、バッファ２１３から１つ以上の参照フレームを現在のビデオブロックと比較することによって、現在のビデオブロックのためのモーション情報を生成し得る。動き補償ユニット２０５は、現在のビデオブロックに関連するピクチャ以外にバッファ２１３からのピクチャの動き情報及びデコードされたサンプルに基づいて、現在のビデオブロックのための予測ビデオブロックを特定し得る。

【0394】

動き推定ユニット２０４及び動き補償ユニット２０５は、例えば、現在のビデオブロックがＩスライスにあるか、Ｐスライスにあるか又はＢスライスにあるかによって、現在のビデオブロックに対して異なる動作を行い得る。

【0395】

一部の例では、動き推定ユニット２０４は、現在のビデオブロックに対して単一方向の予測を行ってもよく、動き推定ユニット２０４は、現在のビデオブロック用の参照ビデオブロックのためにリスト０又はリスト１の参照ピクチャを検索し得る。次に、動き推定ユニット２０４は、参照ビデオブロックと、現在のビデオブロックと参照ビデオブロックとの間の空間的変位を示す動きベクトルとを含む、リスト０又はリスト１内の参照ピクチャを示す参照インデックスを生成し得る。動き推定ユニット２０４は、現在のビデオブロックの動き情報として、参照インデックス、予測方向インジケータ及び動きベクトルを出力し得る。動き補償ユニット２０５は、現在のビデオブロックの動き情報によって示される参照ビデオブロックに基づいて、現在のブロックの予測ビデオブロックを生成し得る。

【0396】

他の例では、動き推定ユニット２０４は、現在のビデオブロックについて双方向予測を行ってもよく、動き推定ユニット２０４は、現在のビデオブロック用の参照ビデオブロックについてリスト０内の参照ピクチャを検索し、現在のビデオブロック用の別の参照ビデオブロックについてもリスト１内の参照ピクチャを検索し得る。次に、動き推定ユニット２０４は、参照ビデオブロックと、参照ビデオブロックと現在のビデオブロックとの間の空間的変位を示す動きベクトルとを含むリスト０及びリスト１における参照ピクチャを示す参照インデックスを生成し得る。動き推定ユニット２０４は、現在のビデオブロックの参照インデックス及び動きベクトルを現在のビデオブロックの動き情報として出力し得る。動き補償ユニット２０５は、現在のビデオブロックの動き情報によって示される参照ビデオブロックに基づいて、現在のビデオブロックの予測ビデオブロックを生成し得る。

【0397】

一部の例では、動き推定ユニット２０４は、デコーダのデコーディング処理のために完全な動き情報のセットを出力し得る。

【0398】

一部の例では、動き推定ユニット２０４は、現在のビデオのための完全な動き情報のセットを出力しなくてもよい。むしろ、動き推定ユニット２０４は、他のビデオブロックの動き情報を参照して現在のビデオブロックの動き情報を信号化することができる。例えば、動き推定ユニット２０４は、現在のビデオブロックのモーション情報が隣接するビデオブロックのモーション情報と十分に類似していると判断することができる。

【0399】

１つの例では、動き推定ユニット２０４は、現在のビデオブロックに関連するシンタックス構造において、現在のビデオブロックが別のビデオブロックと同じ動き情報を有することをビデオデコーダ３００に示す値を示し得る。

【0400】

別の例では、動き推定ユニット２０４は、現在のビデオブロックに関連するシンタックス構造において、別のビデオブロック及び動きベクトル差（ＭＶＤ）を識別し得る。動きベクトル差は、現在のビデオブロックの動きベクトルと、示されたビデオブロックの動きベクトルとの間の差を示す。ビデオデコーダ３００は、示されたビデオブロックの動きベクトルと動きベクトル差とを用いて、現在のビデオブロックの動きベクトルを特定し得る。

【0401】

上述のように、ビデオエンコーダ２００は、動きベクトルを予測的にシグナリングし得る。ビデオエンコーダ２００によって実現され得る予測シグナリング技術の２つの例は、高度動きベクトル予測（ＡＭＶＰ）及びマージモードシグナリングを含む。

【0402】

イントラ予測ユニット２０６は、現在のビデオブロックに対してイントラ予測を行い得る。イントラ予測ユニット２０６が現在のビデオブロックに対してイントラ予測を行う場合、イントラ予測ユニット２０６は、同じピクチャ内の他のビデオブロックのデコードされたサンプルに基づいて、現在のビデオブロックのための予測データを生成し得る。現在のビデオブロックのための予測データは、予測されたビデオブロック及び様々なシンタックス要素を含み得る。

【0403】

残差生成ユニット２０７は、現在のビデオブロックから現在のビデオブロックの予測されたビデオブロックを差し引くことにより（例えば、マイナス記号によって示される）、現在のビデオブロックのための残差データを生成し得る。現在のビデオブロックの残差データは、現在のビデオブロック内のサンプルの異なるサンプル成分に対応する残差ビデオブロックを含み得る。

【0404】

他の例では、例えばスキップモードでは、現在のビデオブロックのための現在のビデオブロックのための残差データが存在しないことがあり、残差生成ユニット２０７は減算動作を行わなくてもよい。

【0405】

変換処理ユニット２０８は、現在のビデオブロックに関連する残差ビデオブロックに対して１つ以上の変換を適用することにより、現在のビデオブロックのための１つ以上の変換係数ビデオブロックを生成し得る。

【0406】

変換処理ユニット２０８が現在のビデオブロックに関連する変換係数ビデオブロックを生成した後で、量子化ユニット２０９は、現在のビデオブロックに関連する１つ以上の量子化パラメータ（ＱＰ）値に基づいて、現在のビデオブロックに関連する変換係数ビデオブロックを量子化し得る。

【0407】

逆量子化ユニット２１０及び逆変換ユニット２１１は、変換係数ビデオブロックから残差ビデオブロックを再構成するために、変換係数ビデオブロックにそれぞれ逆量子化及び逆変換を適用し得る。再構成ユニット２１２は、予測ユニット２０２によって生成された１つ以上の予測されたビデオブロックからの対応するサンプルに、再構成された残差ビデオブロックを追加して、現在のブロックに関連する再構成されたビデオブロックをバッファ２１３に格納するために生成し得る。

【0408】

再構成ユニット２１２がビデオブロックを再構成した後、ビデオブロックにおけるビデオブロッキングアーチファクトを低減するためにループフィルタ動作が行われ得る。

【0409】

エントロピーエンコーディングユニット２１４は、ビデオエンコーダ２００の他の機能コンポーネントからデータを受信し得る。エントロピーコーディングユニット２１４がデータを受信すると、エントロピーコーディングユニット２１４は、１つ以上のエントロピーコーディング動作を行って、エントロピーエンコードされたデータを生成し、エントロピーエンコードされたデータを含むビットストリームを出力し得る。

【0410】

図２７は、図２５に示すシステム１００におけるビデオデコーダ１１４であり得るビデオデコーダ３００の一例を示すブロック図である。

【0411】

ビデオデコーダ３００は、本開示の技術のいずれか又は全てを行うように構成され得る。図２７の例では、ビデオデコーダ３００は、複数の機能コンポーネントを含む。本開示で説明する技術は、ビデオデコーダ３００の様々なコンポーネントの間で共有され得る。いくつかの例では、プロセッサは、本開示で説明する技術のいずれか又は全てを行うように構成され得る。

【0412】

図２７の例では、ビデオデコーダ３００は、エントロピーデコーディングユニット３０１、動き補償ユニット３０２、イントラ予測ユニット３０３、逆量子化ユニット３０４、逆変換ユニット３０５及び再構成ユニット３０６及びバッファ３０７を含む。ビデオデコーダ３００は、一部の例では、ビデオエンコーダ２００（例えば、図２６）に関して説明したエンコーディングパスと概ね逆のデコーディングパスを行い得る。

【0413】

エントロピーデコーディングユニット３０１は、エンコードされたビットストリームを読み出し得る。エンコードされたビットストリームはエントロピーコード化ビデオデータ（例えば、ビデオデータのエンコードされたブロック）を含み得る。エントロピーデコーディングユニット３０１はエントロピーコード化ビデオデータをデコードし、エントロピーデコードされたビデオデータから、動き補償ユニット３０２は動きベクトル、動きベクトル精度、参照ピクチャリストインデックス及び他の動き情報を含む動き情報を特定し得る。動き補償ユニット３０２は、例えば、ＡＭＶＰ及びマージモードを実行することにより、そのような情報を特定し得る。

【0414】

動き補償ユニット３０２は動き補償ブロックを生成し、場合によっては補償フィルタに基づいて補間を行い得る。サブピクセル精度で用いられるべき補間フィルタのための識別子は、シンタックス要素に含まれ得る。

【0415】

動き補償ユニット３０２は、ビデオブロックのエンコーディングの間にビデオエンコーダ２０によって用いられる補間フィルタを用いて、参照ブロックのサブ整数ピクセルのための補間値を計算し得る。動き補償ユニット３０２は、受信されたシンタックス情報に従ってビデオエンコーダ２００によって用いられる補間フィルタを決定し、予測ブロックを生成するために補間フィルタを用い得る。

【0416】

動き補償ユニット３０２は、エンコードされたビデオシーケンスのフレーム及び／又はスライスをエンコードするために用いられるブロックのサイズ、エンコードされたビデオシーケンスのピクチャの各マクロブロックがどのように分割されるかを記述する分割情報、各分割がどのようにエンコードされるかを示すモード、各インターエンコードされたブロックのための１つ以上の参照フレーム（及び参照フレームリスト）及びエンコードされたビデオシーケンスをデコードするための他の情報を決定するために、シンタックス情報の一部を用いり得る。

【0417】

イントラ予測ユニット３０３は、例えば、ビットストリームで受信されたイントラ予測モードを用いて、空間的に隣接するブロックから予測ブロックを形成し得る。逆量子化ユニット３０４は、ビットストリーム内で提供され、エントロピーデコーディングユニット３０１によってデコードされる量子化ビデオブロック係数を逆量子化、すなわち脱量子化する。逆変換ユニット３０５は逆変換を適用する。

【0418】

再構成ユニット３０６は、残差ブロックを動き補償ユニット２０５又はイントラ予測ユニット３０３によって生成された対応する予測ブロックと合算して、デコードされたブロックを形成し得る。所望により、ブロック性アーチファクトを除去するために、デコードされたブロックをフィルタリングするためデブロックフィルタも適用され得る。次いで、デコードされたビデオブロックはバッファ３０７に格納され、バッファ３０７は、後続の動き補償のための参照ブロックを提供する。

【0419】

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

【0420】

開示の技術の一部の実施形態は、ビデオ処理ツール又はモードを無効にする決定又は判断を行うことを含む。１つの例では、ビデオ処理ツール又はモードが無効にされている場合、エンコーダは、ビデオのブロックをビデオのビットストリーム表現に変換する際にツール又はモードを用いない。別の例では、ビデオ処理ツール又はモードが無効にされている場合、デコーダは、決定又は判断に基づいて無効にされたビデオ処理ツール又はモードを用いてビットストリームが修正されていないとの知識によりビットストリームを処理する。

【0421】

本願において、「ビデオ処理」という用語は、ビデオエンコーディング、ビデオデコーディング、ビデオ圧縮又はビデオ解凍を意味し得る。例えば、ビデオ圧縮アルゴリズムは、ビデオのピクセル表現から対応するビットストリーム表現へ又はその逆への変換の間に適用され得る。現在のビデオブロックのビットストリーム表現は、例えば、シンタックスによって定義されるように、同一場所に配置されているか又はビットストリーム内の異なる場所に分散されているかのいずれかのビットに対応し得る。例えば、マクロブロックは、変換及びコード化エラー残差値の観点から及びビットストリームにおけるヘッダ及び他のフィールド内のビットを用いてエンコードされ得る。

【0422】

以下の第１の項（clause）のセットが一部の実施形態で実施され得る。

【0423】

１．ビデオ処理のための方法であって、現在のビデオブロックと、現在のビデオブロックのビットストリーム表現との間での変換の間に、現在のビデオブロックに関連する参照ピクチャの解像度と、現在のピクチャの解像度とに基づいて、動きベクトルオフセットを導出すことと、該動きベクトルオフセットを用いて前記変換を行うこととを含む、方法。

【0424】

２．前記動きベクトルオフセットを導出することは、第１の参照ピクチャを参照する第１の動きベクトルオフセットを導出することと、前記第１の動作ベクトルオフセットに基づいて、第２の参照ピクチャを参照する第２の動作ベクトルオフセットを導出することとを含む、１項に記載の方法。

【0425】

３．前記現在のビデオブロックに対して、空間的、時間的又は履歴的な動き候補に関連する参照ピクチャ解像度に基づいて、動き候補リスト構築プロセスを行うことをさらに含む、１項に記載の方法。

【0426】

４．ルックアップテーブルを更新するかどうか又はどのように更新するかは、デコードされた動き候補に関連する参照ピクチャ解像度によって決まる、１項に記載の方法。

【0427】

５．前記現在のピクチャに対して、対応する寸法に関連する適応ループフィルタ（ＡＬＦ）パラメータを用いてフィルタリング動作を行うことをさらに含む、１項に記載の方法。

【0428】

６．前記ＡＬＦパラメータは、第１の対応する寸法に関連する第１のＡＬＦパラメータと、第２の対応する寸法に関連する第２のＡＬＦパラメータとを含み、該第２のＡＬＦパラメータは第１のＡＬＦパラメータから継承されるか又は予測される、５項に記載の方法。

【0429】

７．対応する寸法に関連するＬＭＣＳ（ルーママッピングクロマスケーリング）パラメータを用いて、現在のピクチャ内のサンプルを再成形することをさらに含む、１項に記載の方法。

【0430】

８．前記ＬＭＣＳパラメータは、第１の対応する寸法に関連する第１のＬＭＣＳパラメータと、第２の対応する寸法に関連する第２のＬＭＣＳパラメータとを含み、該第２のＬＭＣＳパラメータは該第１のＬＭＣＳパラメータから継承されるか又は予測される、７項に記載の方法。

【0431】

９．ビデオユニットにおいてシグナリングされるＡＬＦパラメータ又はＬＭＣＳパラメータは、１つ又は複数のピクチャ寸法に関連する５又は７項に記載の方法。

【0432】

１０．現在のビデオブロックが、現在のピクチャと異なる寸法を有する少なくとも１つの参照ピクチャを参照する場合、現在のビデオブロックのためのコーディングツールを無効にすることをさらに含む、１項に記載の方法。

【0433】

１１．現在のピクチャの寸法と異なる寸法を有する参照ピクチャを参照するマージ候補をスキップするか又は省略することをさらに含む、１０項に記載の方法。

【0434】

１２．参照ピクチャの解像度及び現在ピクチャの解像度に基づいて、２つの参照ブロック又は２つの参照ピクチャをスケーリングした後に又は参照ピクチャの解像度及び現在ピクチャの解像度に基づいて２つのＭＶ又はＭＶＤ（動きベクトル差）をスケーリングした後に、コーディングツールを適用することさらに含む、１項に記載の方法。

【0435】

１３．前記現在のピクチャが含む異なる解像度はＫ個以下であり、Ｋは自然数である、１項に記載の方法。

【0436】

１４．Ｎ個の連続したピクチャに対して前記Ｋ個の異なる解像度が許され、Ｎは自然数である、１３項に記載の方法。

【0437】

１５．イントラピクチャである現在のピクチャに解像度変更を適用することをさらに含む、１項に記載の方法。

【0438】

１６．現在のビデオブロックの１つ又は２つの参照ピクチャが現在のピクチャの解像度と異なる解像度を有する場合に、双方向予測を単方向予測に変換することをさらに含む、１項に記載の方法。

【0439】

１７．動きベクトル精度又は現在のブロック寸法と参照ブロック寸法との間の解像度のうちの少なくとも１つによって、異なる解像度の参照ピクチャからのインター予測を有効又は無効にすることをさらに含む、１項に記載の方法。

【0440】

１８．両方の参照ピクチャ又は一方の参照ピクチャが現在のピクチャとは異なる解像度を有するかどうかによって、双方向予測を適用することをさらに含む、１項に記載の方法。

【0441】

１９．現在のビデオブロックは現在のピクチャとは異なる寸法を有する参照ピクチャを参照するかどうかは、現在のビデオブロックのサイズ又はブロック予測モードのうちの少なくとも１つによって決まる、１項に記載の方法。

【0442】

２０．前記変換を行うことは、前記ビットストリーム表現から前記現在のビデオブロックを生成することを含む、１項に記載の方法。

【0443】

２１．前記変換を行うことは、前記現在のビデオブロックから前記ビットストリーム表現を生成することを含む、１項に記載の方法。

【0444】

２２．プロセッサと、命令を有する非一時メモリとを含むビデオシステム内の装置であって、前記プロセッサによる実行の際に、前記命令は、前記プロセッサに、１項乃至２１項のいずれか１項に記載の方法を実行させる、装置。

【0445】

２３．非一時的コンピュータ読み取り可能媒体に記憶されたコンピュータプログラム製品であって、１項乃至２１項のいずれか一項に記載の方法を行うためのプログラムコードを含む、コンピュータプログラム製品。

【0446】

第２の項のセットは、先のセクションで開示した技術の特定の特徴及び態様を説明する。

【0447】

１.ビデオ処理のための方法（例えば、図２８に示す方法２８００）であって、ビデオのピクチャのビデオ領域と該ビデオのコード化表現との間での変換のために、該コード化表現におけるビデオ領域を表すために用いられるコーディングツールの有効状態を判定ことと（２８１０）、該判定に従って前記変換を行うこと（２８２０）とを含み、前記ピクチャのための前記コーディングツールの有効状態を示すために、第１のフラグがピクチャヘッダに含まれている、方法。

【0448】

２．前記有効状態は、前記第１のフラグ及び／又は前記ビデオのスライスタイプによって、前記コーディングが前記ビデオ領域に対して無効であるか又は有効であるかを示す、１項に記載の方法。

【0449】

３．前記判定することは、前記第１のフラグが真の場合に前記コーディングツールが無効であると判定する、１項に記載の方法。

【0450】

４．前記判定することは、前記第１のフラグが偽の場合に前記コーディングツールが無効であると判定する、１項に記載の方法。

【0451】

５．前記判定することは、前記第１のフラグが偽の場合に前記コーディングツールが有効であると判定する、１項に記載の方法。

【0452】

６．前記判定することは、前記第１のフラグが真の場合に前記コーディングツールが有効であると判定する、１項に記載の方法。

【0453】

７．前記コーディングツールは、前記ピクチャ内の全てのサンプルに対して無効にされているか又は有効にされている、１項に記載の方法。

【0454】

８．前記第１のフラグのシグナリングは、前記ビデオ領域に関連するシーケンスパラメータセット（ＳＰＳ）、ビデオパラメータセット（ＶＰＳ）、依存性パラメータセット（ＤＰＳ）又はピクチャパラメータセット（ＰＰＳ）における１つ以上のシンタックス要素によって決まる、１項に記載の方法。

【0455】

９．前記第１のフラグのシグナリングは、前記シーケンスパラメータセット（ＳＰＳ）におけて前記コーディングツールの有効を示す表示によって決まる、８項に記載の方法。

【0456】

１０．前記ピクチャヘッダ内の前記第１のフラグの存在を示す第２のフラグは、前記シーケンスパラメータセット（ＳＰＳ）でシグナリングされる、８項に記載の方法。

【0457】

１１．前記ピクチャヘッダ内の前記第１のフラグの存在を示す第２のフラグは、前記コーディングツールが前記ビデオのシーケンスに対して有効にされている場合にシグナリングされる、８項に記載の方法。

【0458】

１２．前記第１のフラグの存在を示す前記第２のフラグが前記第１のフラグの存在を示す場合、前記第１のフラグは前記ピクチャヘッダでシグナリングされる、８項に記載の方法。

【0459】

１３．前記第１のフラグ及び／又は前記第２のフラグは１ビットでコード化される、１項乃至１２項のいずれかに記載の方法。

【0460】

１４．前記コーディングツールは、１つ以上の初期アフィン予測がオプティカルフロー計算に基づいて精緻化される、オプティカルフローを用いた予測精緻化（ＰＲＯＦ）である、１項乃至１３項のいずれかに記載の方法。

【0461】

１５．前記コーディングツールは、動き情報が予測ブロックを用いて精緻化されるデコーダ側動きベクトル精緻化（ＤＭＶＲ）である、１項乃至１３項のいずれかに記載の方法。

【0462】

１６．前記コーディングツールは、１つ以上の初期予測がオプティカルフロー計算を用いて精緻化される双方向オプティカルフロー（ＢＤＯＦ）である、１項乃至１３項のいずれかに記載の方法。

【0463】

１７．前記コーディングツールは、線形フィルタがルーマ情報に基づいてクロマサンプルに適用されるクロスコンポーネント適応ループフィルタ（ＣＣＡＬＦ）である、１項乃至１３項のいずれかに記載の方法。

【0464】

１８．前記コーディングツールは、予測サンプルが重み付け値を用いて生成される幾何学的分割（ＧＥＯ）であり、該予測サンプルは、非水平又は非垂直の線に従った前記ビデオ領域の分割に基づく、１項乃至１３項のいずれかに記載の方法。

【0465】

１９．前記コーディングツールは、予測サンプルが重み付け値を用いて生成される三角予測モード（ＴＰＭ）であり、該予測サンプルは、前記ビデオ領域を２つの三角パーティションに分割することに基づく、１項乃至１３項のいずれかに記載の方法。

【0466】

２０．前記変換は、前記ビデオをビットストリーム表現にエンコーディングすることを含む、１項乃至１９項のいずれかに記載の方法。

【0467】

２１．前記変換は、前記ビデオを生成するために前記ビットストリーム表現をデコーディングすることを含む、１項乃至１９項のいずれかに記載の方法。

【0468】

２２．１項乃至２１項の１つ以上に記載の方法を実施するように構成されたプロセッサ含むビデオ処理装置。

【0469】

２３．実行された場合に、プロセッサに、１項乃至２１項の１つ以上に記載の方法を実施させるプログラムコードを記憶するコンピュータ読み取り可能媒体。

【0470】

２４．上述の方法のいずれかに従って生成されるコード化表現又はビットストリーム表現を記憶するコンピュータ読み取り可能媒体。

【0471】

以上から、本開示の技術の特定の実施形態は説明を目的として本明細書に記載されているが、開示の技術の範囲から逸脱することなく、様々な修正を行うことができることが理解されるであろう。したがって、本開示の技術は、添付の特許請求の範囲を除いて、限定されない。

【0472】

本明細書で説明した主題及び機能動作の実施は、本明細書で開示の構造及びそれらの構造的同等物又はそれらのうちの１つ以上の組み合わせを含む、様々なシステム、デジタル電子回路又はコンピュータソフトウェア、ファームウェア又はハードウェアで実施することができる。本明細書で説明した主題の実施は、１つ以上のコンピュータプログラム製品、すなわち、データ処理装置による実行のために又はデータ処理装置の動作を制御するために、有形及び非一時的なコンピュータ読み取り可能媒体上にエンコードされているコンピュータプログラム命令の１つ以上のモジュールとして実施可能である。コンピュータ読み取り可能媒体は、機械により読み出し可能な記憶デバイス、機械により読み出し可能な記憶担体、メモリデバイス、機械により読み出し可能な伝搬信号をもたらす組成物又はそれらの１つ以上の組み合わせであることができる。「データ処理ユニット」又は「データ処理装置」という用語は、例として、プログラム可能なプロセッサ、コンピュータ又は複数のプロセッサ若しくはコンピュータを含む、データを処理する全ての装置、デバイス及び機械を包含する。装置は、ハードウェアに加えて、問題となっているコンピュータプログラムのための実行環境を作り出すコード、例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム又はそれらの１つ以上の組み合わせを構成するコードを含むことができる。

【0473】

コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト又はコードとしても知られる）は、コンパイル済み又は解釈済みの言語を含む如何なる形式のプログラミング言語でも記述可能であり、それは、スタンドアロンプログラムとして又はコンピューティング環境における使用に適したモジュール、コンポーネント、サブルーチン若しくは他のユニットとして、を含め、如何なる形式でもデプロイ可能である。コンピュータプログラムは、必ずしもファイルシステムにおけるファイルに対応しない。プログラムは、問題となっているプログラムに専用の単一のファイルで、又は複数の協調したファイル（例えば、１つ以上のモジュール、サブプログラム、又はコードの部分を保存するファイル）で、他のプログラム又はデータ（例えば、マークアップ言語文書で保存された１つ以上のスクリプト）を保持するファイルの部分において保存可能である。コンピュータプログラムは、１つのコンピュータで、あるいは、１つの場所に位置しているか、又は複数の場所にわたって分布しており、通信ネットワークによって相互接続されている複数のコンピュータで、実行されるようデプロイ可能である。

【0474】

本明細書で記載されているプロセス及び論理フローは、入力データに作用して出力を生成することによって機能を実行するよう１つ以上のコンピュータプログラムを実行する１つ以上のプログラム可能なプロセッサによって実行可能である。プロセス及び論理フローはまた、専用のロジック回路、例えば、ＦＰＧＡ（Field Programmable Gate Array）又はＡＳＩＣ（Application-Specific Integrated Circuit）によっても実行可能であり、装置は、そのようなものとしても実装可能である。

【0475】

コンピュータプログラムの実行に適したプロセッサは、例として、汎用のマイクロプロセッサ及び専用のマイクロプロセッサの両方、並びにあらゆる種類のデジタルコンピュータのいずれか１つ以上のプロセッサを含む。一般に、プロセッサは、リードオンリーメモリ若しくはランダムアクセスメモリ又はその両方から命令及びデータを受け取ることになる。コンピュータの必須の要素は、命令を実行するプロセッサと、命令及びデータを保存する１つ以上のメモリデバイスと、である。一般に、コンピュータはまた、データを保存する１つ以上の大容量記憶デバイス、例えば、磁気、光学磁気ディスク、又は光ディスクを含むか、あるいは、そのような１つ以上の大容量記憶デバイスからのデータの受信若しくはそれへのデータの転送又はその両方のために動作可能に結合されることになる。しかしながら、コンピュータは、そのようなデバイスを有する必要はない。コンピュータプログラム命令及びデータを保存するのに適したコンピュータ読み取り可能媒体は、例として、半導体メモリデバイス、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、及びフラッシュメモリデバイスを含む全ての形式の不揮発性メモリ、媒体及びメモリデバイスを含む。プロセッサ及びメモリは、専用のロジック回路によって強化されるか、あるいは、それに組み込まれ得る。

【0476】

本明細書は、図面と共に例示のみとしてみなされることを意図している。例示とは例を意味する。本明細書で使用する単数形「ａ」、「ａｎ」及び「ｔｈｅ」は、別段明記されていない限り、複数形を含むことを意図している。加えて、「又は」の使用は、別段明記されていない限り、「及び／又は」を含むことを意図する。

【0477】

本明細書は、多数の詳細を含むが、それらは、あらゆる発明の又は請求される可能性があるものの範囲に対する限定としてではなく、むしろ、特定の発明の特定の実施形態に特有であり得る特徴の説明として解釈されるべきである。別々の実施形態に関連して本明細書に記載されている特定の特徴は、単一の実施形態と組み合わせても実装可能である。逆に、単一の実施形態に関連して記載されている様々な特徴はまた、複数の実施形態で別々に、又は何らかの適切なサブコンビネーションで実装可能である。更に、特徴は、特定の組み合わせで動作するものとして上述され、そのようなものとして最初に請求されることさえあるが、請求されている組み合わせからの１つ以上の特徴は、いくつかの場合に、その組み合わせから削除可能であり、請求されている組み合わせは、サブコンビネーション又はサブコンビネーションの変形に向けられてもよい。

【0478】

同様に、動作は、特定の順序で図面において表されているが、これは、所望の結果を達成するために、そのような動作が、示されているその特定の順序で、又は順次的な順序で実行されること、あるいは、表されている全ての動作が実行されることを求めている、と理解されるべきではない。さらに、本明細書に記載されている実施形態における様々なシステムコンポーネントの分離は、全ての実施形態でそのような分離を求めている、と理解されるべきではない。

【0479】

ほんのわずかの実施及び例が説明されており、他の実施、強化及び変形は、本明細書で記載及び例示されているものに基づいて行われ得る。

【外国語明細書】