IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ベイジン バイトダンス ネットワーク テクノロジー カンパニー リミテッドの特許一覧 ▶ バイトダンス インコーポレイテッドの特許一覧

特開2023-99077参照ピクチャ再サンプリングのための信号通知
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023099077
(43)【公開日】2023-07-11
(54)【発明の名称】参照ピクチャ再サンプリングのための信号通知
(51)【国際特許分類】
   H04N 19/132 20140101AFI20230704BHJP
   H04N 19/70 20140101ALI20230704BHJP
【FI】
H04N19/132
H04N19/70
【審査請求】有
【請求項の数】12
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2023072497
(22)【出願日】2023-04-26
(62)【分割の表示】P 2021567036の分割
【原出願日】2020-05-12
(31)【優先権主張番号】PCT/CN2019/086513
(32)【優先日】2019-05-12
(33)【優先権主張国・地域又は機関】CN
(71)【出願人】
【識別番号】520476341
【氏名又は名称】北京字節跳動網絡技術有限公司
【氏名又は名称原語表記】Beijing Bytedance Network Technology Co., Ltd.
【住所又は居所原語表記】Room B-0035, 2/F, No.3 Building, No.30, Shixing Road, Shijingshan District Beijing 100041 China
(71)【出願人】
【識別番号】520477474
【氏名又は名称】バイトダンス インコーポレイテッド
【氏名又は名称原語表記】BYTEDANCE INC.
【住所又は居所原語表記】12655 West Jefferson Boulevard, Sixth Floor, Suite No. 137 Los Angeles, California 90066 United States of America
(74)【代理人】
【識別番号】110002000
【氏名又は名称】弁理士法人栄光事務所
(72)【発明者】
【氏名】ジャン カイ
(72)【発明者】
【氏名】ジャン リー
(72)【発明者】
【氏名】リウ ホンビン
(72)【発明者】
【氏名】ワン ユエ
(57)【要約】      (修正有)
【課題】参照ピクチャの再サンプリングを含む、デジタル映像コーディングのための装置、システム、および方法を提供する。
【解決手段】映像処理方法は、1または複数の映像ユニットを含む1または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を行う。ビットストリーム表現は、フォーマット規則に準拠し、ARC(Adaptive Resolution Conversion)処理に関する情報を含み、フォーマット規則は、ARC処理の映像セグメントへの適用を規定し、映像セグメントの1または複数の映像ユニットが、異なる解像度でコーディングされることの指示が、ヘッダ構文構造、デコーダパラメータセット、映像パラメータセット、ピクチャパラメータセット、シーケンスパラメータセット、および適応パラメータセットとは異なる構文構造のビットストリーム表現に含まれる。
【選択図】図24E
【特許請求の範囲】
【請求項1】
映像処理のための方法であって、
1または複数の映像ユニットを有する1または複数の映像セグメントを有する映像と、前記映像のビットストリーム表現との間の変換を実行することを有し、
前記ビットストリーム表現は、フォーマット規則に準拠し、かつ、ARC(Adaptive Resolution Conversion)処理に関する情報を有し、
K次の指数ゴロム符号にてコーディングされた前記1または複数の映像ユニットの寸法は、前記ビットストリーム表現にて信号通知され、
Kは、正の整数であり、
前記フォーマット規則は、映像セグメントへの前記ARC処理の適用を規定し、
前記映像セグメントの前記1または複数の映像ユニットが異なる解像度にてコーディングされていることの指示は、構文構造の前記ビットストリーム表現に含まれる、方法。
【請求項2】
前記寸法は、前記映像ユニットの幅と、前記1または複数の映像ユニットのうちの映像ユニットの高さの少なくとも一方を有する、請求項1に記載の方法。
【請求項3】
前記1または複数の映像ユニットは、ピクチャを有する、請求項1に記載の方法。
【請求項4】
前記構文構造は、DPS(Decoder Parameter Set)、VPS(Video Parameter Set)、SPS(Sequence Parameter Set)、PPS(Picture Parameter Set)、APS(Adaptive Parameter Set)、ピクチャヘッダ、スライスヘッダ、またはタイルグループヘッダである、請求項1に記載の方法。
【請求項5】
前記構文構造は、RPS(Resolution Parameter Set)、またはCPS(Conversion Parameter Set)である、請求項1に記載の方法。
【請求項6】
映像処理のための方法であって、
1または複数の映像ユニットを有する1または複数の映像セグメントを有する映像と、前記映像のビットストリーム表現との間の変換を実行することを有し、
前記ビットストリーム表現は、フォーマット規則に準拠し、かつ、ARC(Adaptive Resolution Conversion)処理に関する情報を有し、
前記1または複数の映像ユニットのうちの映像ユニットの高さ(H)および幅(W)は、前記ビットストリーム表現にて信号通知され、
HおよびWは、正の整数であり、かつ、抑制され、
前記フォーマット規則は、映像セグメントへのARC(Adaptive Resolution Conversion)処理の適用を規定し、
前記映像セグメントの前記1または複数の映像ユニットが異なる解像度にてコーディングされていることの指示は、構文構造の前記ビットストリーム表現に含まれる、方法。
【請求項7】
W≦TWmaxであり、
TWmaxは、正の整数である、請求項6に記載の方法。
【請求項8】
TWmaxは、前記ビットストリーム表現にて信号通知される、請求項6に記載の方法。
【請求項9】
TWmin≦Wであり、
TWminは、正の整数である、請求項6に記載の方法。
【請求項10】
TWminは、前記ビットストリーム表現にて信号通知される、請求項9に記載の方法。
【請求項11】
H≦THmaxであり、
THmaxは、正の整数である、請求項6に記載の方法。
【請求項12】
THmaxは、前記ビットストリーム表現にて信号通知される、請求項11に記載の方法。
【請求項13】
THmin≦Hであり、
THminは、正の整数である、請求項6に記載の方法。
【請求項14】
THminは、前記ビットストリーム表現にて信号通知される、請求項11に記載の方法。
【請求項15】
前記高さH=h×Y、かつ、前記幅W=w×Xであり、
w、h、X、およびYは、正の整数であり、
w、およびhは、前記ビットストリーム表現にて信号通知される、請求項6に記載の方法。
【請求項16】
X=Y=4である、請求項15に記載の方法。
【請求項17】
XおよびYは、予め定義された整数である、請求項15に記載の方法。
【請求項18】
前記1または複数の映像ユニットは、ピクチャを有する、請求項6に記載の方法。
【請求項19】
映像処理のための方法であって、
1または複数の映像ユニットを有する1または複数の映像セグメントを有する映像と、前記映像のビットストリーム表現との間の変換を実行することを有し、
前記ビットストリーム表現は、フォーマット規則に準拠し、かつ、ARC(Adaptive Resolution Conversion)処理に関する情報を有し、
前記フォーマット規則は、映像セグメントへの前記ARC処理の適用を規定し、
前記映像セグメントの前記1または複数の映像ユニットが異なる解像度にてコーディングされていることの指示は、ヘッダ構文構造、DPS(Decoder Parameter Set)、VPS(Video Parameter Set)、PPS(Picture Parameter Set)、SPS(Sequence Parameter Set)、およびAPS(Adaptive Parameter Set)とは異なる構文構造の前記ビットストリーム表現に含まれる、方法。
【請求項20】
前記ARC処理に関する前記情報は、前記1または複数の映像ユニットを有するピクチ
ャの高さ(H)または幅(W)を有する、請求項19に記載の方法。
【請求項21】
前記ARC処理に関する前記情報は、SEI(Supplement Enhancement Information)メッセージにて信号通知される、請求項19または20に記載の方法。
【請求項22】
前記ヘッダ構文構造は、ピクチャヘッダ、スライスヘッダ、または、タイルグループヘッダを有する、請求項19または20に記載の方法。
【請求項23】
前記ARC処理に関する前記情報は、RPS(Resolution Parameter Set)、またはCPS(Conversion Parameter Set)にて信号通知される、請求項19または20に記載の方法。
【請求項24】
前記ARC処理に関する前記情報は、前記1または複数の映像ユニットを有するピクチャの幅に対する高さの比を有する、請求項19に記載の方法。
【請求項25】
前記ARC処理に関する前記情報は、前記1または複数の映像ユニットを有するピクチャの異なる幅に対する異なる高さの複数の比を有する、請求項19に記載の方法。
【請求項26】
前記複数の比のうちの許可された比に対応するインデックスは、PPS(Picture Parameter Set)にて信号通知される、請求項25に記載の方法。
【請求項27】
前記複数の比のうちのいずれかの比は、前記複数の比のうちの他の比とは異なる、請求項25に記載の方法。
【請求項28】
前記情報は、(i)第1の幅と第2の幅との差、(ii)第1の高さと第2の高さとの差、(iii)前記第1の幅と前記第2の幅との比、または(iv)前記第1の高さと前記第2の高さとの比のうちの少なくとも1つを有する、請求項19に記載の方法。
【請求項29】
前記情報は、ユーナリー符号、トランケイテッドユーナリー符号、または固定長符号にてコーディングされる、請求項28に記載の方法。
【請求項30】
前記ビットストリーム表現は更に、CTU(Coding Tree Unit)サイズを示す構文要素、最小CU(Coding Unit)サイズを示す構文要素、最大または最小TB(Transform Block)サイズを示す構文要素、前記1または複数の映像ユニットに適用可能な分割処理の最大深さを示す構文要素、または、特定のピクチャ解像度にてバインドするように構成される構文要素のうちの少なくとも1つを有する、請求項19に記載の方法。
【請求項31】
前記1または複数の映像ユニットを有する現在のピクチャに関連付けられた第1の参照ピクチャは、前記現在のピクチャの解像度と等しい第1の解像度を有し、
前記現在のピクチャに関連付けられた第2の参照ピクチャは、前記現在のピクチャの前記解像度よりも大きい第2の解像度を有し、
前記第2の参照ピクチャの参照インデックスは、前記第1の参照ピクチャの参照インデックスよりも大きい、請求項19に記載の方法。
【請求項32】
前記変換は、前記1または複数の映像ユニットを前記ビットストリーム表現から生成する、請求項19~31のいずれか一項に記載の方法。
【請求項33】
前記変換は、前記ビットストリーム表現を前記1または複数の映像ユニットから生成する、請求項19~31のいずれか一項に記載の方法。
【請求項34】
プロセッサと、命令を有する非一時的メモリを有する、映像システムにおける装置であって、
前記命令は、前記プロセッサにより実行されることにより前記プロセッサに請求項19~33のいずれか一項に記載の方法を実装させる、装置。
【請求項35】
非一時的コンピュータ可読媒体に格納されたコンピュータプログラムプロダクトであって、
請求項19~33のいずれか一項に記載の方法を実行するためのプログラムコードを含むコンピュータプログラムプロダクト。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
パリ条約に基づく適用可能な特許法および/または規則に基づいて、本願は、2019年5月12日出願の国際特許出願第PCT/CN2019/086513号の優先権および利益を適時に主張することを目的とする。法に基づくすべての目的のために、上記出願の開示全体は、本明細書の開示の一部として参照により援用される。
【0002】
この特許明細書は、映像コーディング技術、デバイスおよびシステムに関する。
【背景技術】
【0003】
映像圧縮の進歩にもかかわらず、デジタル映像は、依然として、インターネットおよび他のデジタル通信ネットワークにおいて最大の帯域幅の使用量を占めている。映像を受信および表示することが可能である接続されたユーザ機器の数が増加するにつれ、デジタル映像の使用に対する帯域幅の需要は増大し続けることが予測される。
【発明の概要】
【0004】
デジタル映像コーディングに関し、具体的には、映像コーディングのための参照ピクチャ再サンプリングに関するデバイス、システム、および方法に関する。記載された方法は、既存の映像コーディング規格(例えば、HEVC(High Efficiency Video Coding))および将来の映像コーディング規格またはビデオコーデックの両方に適用されてよい。
【0005】
1つの代表的な態様において、開示される技術は、映像処理の方法を提供するために使用してもよい。この方法は、1または複数の映像ユニットを有する1または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を行うことを含み、ビットストリーム表現は、フォーマット規則に準拠し、かつ、ARC(Adaptive Resolution Conversion)処理に関する情報を有し、フォーマット規則は、ARC処理の映像セグメントへの適用を規定し、映像セグメントの1または複数の映像ユニットが、異なる解像度でコーディングされることの指示が、ヘッダ構文構造、DPS(Decode Parameter Set)、VPS(Video Parameter Set)、PPS(Picture Parameter Set)、SPS(Sequence Parameter Set)、およびAPS(Adaptive Parameter Set)とは異なる構文構造のビットストリーム表現に含まれる。
【0006】
別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、1または複数の映像ユニットを有する1または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を行うことを含み、ビットストリーム表現は、フォーマット規則に準拠し、かつ、ARC(Adaptive Resolution Conversion)処理に関する情報を有し、K次の指数ゴロム符号でコーディングされている1または複数の映像ユニットは、ビットストリーム表現で信号通知され、Kは正の整数であり、フォーマット規則は、ARC処理の映像セグメントへの適用を規定し、映像セグメントの1または複数の映像ユニットの寸法が異なる解像度でコーディングされていることの指示が、構文構造のビットストリーム表現に含まれる。
【0007】
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、1または複数の映像ユニットを有する1または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を行うことを含み、ビットストリーム表現は、フォーマット規則に準拠し、かつ、ARC(Adaptive Resolution Conversion)処理に関する情報を有し、高さ(H)と幅(W)は、ビットストリーム表現にて信号通知され、HとWは、正の整数であり、かつ、抑制され、フォーマット規則は、ARC(Adaptive Resolution Conversion)処理の映像セグメントへの適用を規定し、映像セグメントの1または複数の映像ユニットが異なる解像度でコーディングされていることの指示が、構文構造のビットストリーム表現に含まれる。
【0008】
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、(a)映像の現在の映像ブロックの時間的に近傍の第1のブロックの第1の参照ピクチャの解像度が、現在の映像ブロックを有する現在のピクチャの解像度と同一であること、および(b)現在の映像ブロックの時間的に近傍の第2のブロックの第2の参照ピクチャの解像度が、現在のピクチャの解像度と異なること、を判定することと、判定に起因して、第1の時間的に近傍のブロックの予測における第2の時間的に近傍のブロックの動き情報の使用を無効化することによって、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を含む。
【0009】
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、(a)映像の現在の映像ブロックの時間的に近傍の第1のブロックの第1の参照ピクチャの解像度が、現在の映像ブロックを有する現在のピクチャの解像度と異なること、および(b)現在の映像ブロックの時間的に近傍の第2のブロックの第2の参照ピクチャの解像度が、現在のピクチャの解像度と同一であること、を判定することと、判定に起因して、第1の時間的に近傍のブロックの予測における第2の時間的に近傍のブロックの動き情報の使用を無効化することによって、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を含む。
【0010】
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、映像の現在の映像ブロックのために、現在の映像ブロックに関連付けられた映像ブロックを有する参照ピクチャの解像度が、現在の映像ブロックを有する現在のピクチャの解像度とは異なることを判定することと、判定に起因して、参照ピクチャの映像ブロックに基づく予測処理を無効化することによって、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することとを含む。
【0011】
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、ピクチャの少なくとも1つの寸法に基づいて、ピクチャが現在のピクチャの現在の映像ブロックのための並置された参照ピクチャとして使用することが許可されるかどうかに関する決定を行うことと、決定に基づいて、映像の現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することとを含む。
【0012】
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、映像の現在の映像ブロックの予測のために、並置されたブロックを有する並置された参照ピクチャの寸法が、現在の映像ブロックを有する現在のピクチャの寸法と同一であることの判定に基づいて、並置されたブロックを識別することと、並置されたブロックを使用して、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することとを含む。
【0013】
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、映像の現在の映像ブロックのために、現在の映像ブロックに関連付けられた参照ピクチャが、現在の映像ブロックを有する現在のピクチャの解像度とは異なる解像度を有することを判定することと、現在の映像ブロックと映像のビットストリーム表現との間の変換の一部として、参照ピクチャの1または複数の参照サンプル、および現在の映像ブロックに対する動き情報または現在の映像ブロックに対するコーディング情報においてアップサンプリング動作またはダウンサンプリング動作を実行することと、を含む。
【0014】
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、映像の現在の映像ブロックと映像のビットストリーム表現との間の変換のために、現在の映像ブロックを有する現在のピクチャの高さまたは幅が、現在の映像ブロックに関連付けられた並置された参照ピクチャの高さまたは幅とは異なることを判定することと、判定に基づいて、並置された参照ピクチャの1または複数の動きベクトルを格納するバッファにおいてアップサンプリング動作またはダウンサンプリング動作を実行することと、を含む。
【0015】
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、映像の現在の映像ブロックを有する現在のピクチャの寸法と、現在の映像ブロックに関連付けられた並置されたピクチャの寸法に基づいて、現在の映像ブロックに適用されるATMVP(Alternative Temporal Motion Vector Prediction)処理に関する情報を導出することと、時間的動きベクトルを使用して、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を含む。
【0016】
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用してもよい。この方法は、映像の現在の映像ブロックに対するARC(Adaptive Resolution Conversion)処理の適用のために、映像のビットストリーム表現を構成することであって、ARC処理に関する情報は、ビットストリーム表現にて信号通知され、現在の映像ブロックを有する現在のピクチャは、第1の解像度を有し、ARC処理は、第1の解像度とは異なる第2の解像度で現在の映像ブロックの一部分を再サンプリングすることを含む、ことと、構成することに基づいて、現在の映像ブロックと現在の映像ブロックのビットストリーム表現との間の変換を実行することと、を含む。
【0017】
さらに別の代表的な態様において、上記方法は、プロセッサが実行可能なコードの形式で実施され、コンピュータ可読プログラム媒体に記憶される。
【0018】
さらに別の代表的な態様において、上述した方法を行うように構成された、または動作可能なデバイスが開示される。デバイスは、この方法を実装するようにプログラムされたプロセッサを含んでもよい。
【0019】
さらに別の代表的な態様において、映像デコーダ装置は、本明細書で説明されるような方法を実装してもよい。
【0020】
開示される技術の上記および他の態様および特徴は、図面、説明および特許請求の範囲でより詳細に説明される。
【図面の簡単な説明】
【0021】
図1】異なる解像度でコーディングされた同じコンテンツの2つの表現の適応ストリームの例を示す。
図2】異なる解像度でコーディングされた同じコンテンツの2つの表現の適応ストリームの別の例を示し、セグメントは、閉GOP(Group Of Picture)または開GOPの予測構造のいずれかを使用する。
図3】2つの表現の開GOP予測構造の例を示す。
図4】開GOP位置での表現切り替えの例を示す。
図5】別のビットストリームからの再サンプリングされた参照ピクチャを、RASL(Random Access Skipped Leading)ピクチャを復号化するための参照として使用する例を示す。
図6】MCTS(Motion Constrainted Tile Set)に基づくRWMR(Region Wise Mixed-Resolution)ビューポート依存360ストリーミングの例を示す。
図7】異なるIRAP(Intra Random Access Point)の間隔および異なるサイズの並置されたサブピクチャ表現の例を示す。
図8】視線の向きの変更がセグメントの始まりに際する解像度の変更を引き起こすときに受信したセグメントの例を示す。
図9】視線の向きの変更の例を示す。
図10】2つのサブピクチャ位置のためのサブピクチャ表現の例を示す。
図11】ARC(Adaptive Resolution Conversion)のためのエンコーダの修正の例を示す。
図12】ARCのためのデコーダの修正の例を示す。
図13】ARCのためのタイルグループベースの再サンプリングの例を示す。
図14】ARC処理の例を示す。
図15】コーディングユニットのためのATMVP(Alternative Temporal Motion Vector Prediction)の例を示す。
図16A】簡略化したアフィン動きモデルの例を示す。
図16B】簡略化したアフィン動きモデルの例を示す。
図17】サブブロックごとのアフィンMVF(Motion Vector Field)の例を示す。
図18A】それぞれ4パラメータアフィンモデルおよび6パラメータアフィンモデルの例を示す。
図18B】それぞれ4パラメータアフィンモデルおよび6パラメータアフィンモデルの例を示す。
図19】継承されたアフィン候補に対するAF_INTERのMVP(Motion Vector Prediction)の例を示す。
図20】構築されたアフィン候補に対するAF_INTERのMVPの例を示す。
図21A】AF_MERGEの候補の例を示す。
図21B】AF_MERGEの候補の例を示す。
図22】アフィンマージモードの候補位置の例を示す。
図23】ARCを使用してTMVP/ATMVPを導出する例を示す。
図24A】映像処理のための例示的な方法のフローチャートを示す。
図24B】映像処理のための例示的な方法のフローチャートを示す。
図24C】映像処理のための例示的な方法のフローチャートを示す。
図24D】映像処理のための例示的な方法のフローチャートを示す。
図24E】映像処理のための例示的な方法のフローチャートを示す。
図24F】映像処理のための例示的な方法のフローチャートを示す。
図24G】映像処理のための例示的な方法のフローチャートを示す。
図24H】映像処理のための例示的な方法のフローチャートを示す。
図24I】映像処理のための例示的な方法のフローチャートを示す。
図24J】映像処理のための例示的な方法のフローチャートを示す。
図25】本特許明細書に記載されるビジュアルメディアの復号化またはビジュアルメディアの符号化技術を実装するためのハードウェアプラットフォームの一例を示すブロック図である。
図26】開示された技術を実装することができる例示的な映像処理システムを示すブロック図である。
【発明を実施するための形態】
【0022】
開示される技術の実施形態は、圧縮性能を向上させるために、既存の映像コーディング規格(例えば、HEVC、H.265)および将来の規格に適用されてもよい。本特許明細書では、説明の可読性を向上させるために章の見出しを使用しており、説明または実施形態(および/または実装形態)をそれぞれの章のみに限定するものではない。
【0023】
1. 映像コーディングの導入
【0024】
より高い解像度の映像の需要が増大しているため、近年の技術において、映像コーディング方法および技術は、いたるところに存在している。映像コーデックは、一般的に、デジタル映像を圧縮または展開する電子回路またはソフトウェアを含み、より高いコーディング効率を提供するために絶えず改良されている。映像コーデックは、非圧縮映像を圧縮フォーマットに変換する、またはその逆である。映像の品質、映像を表現するために使用されるデータの数(ビットレートで判定される)、符号化および復号化アルゴリズムの複雑性、データの損失およびエラーに対する敏感さ、編集のしやすさ、ランダムアクセス、およびエンドツーエンドの遅延(待ち時間)の間には複雑な関係がある。圧縮フォーマットは、通常、標準的な映像圧縮仕様、例えば、HEVC(High Efficiency Video Coding)規格(H.265またはMPEG-H Part2としても知られている)、確立されるべきVersatile Video Coding規格、または他の現在のおよび/または将来の映像コーディング規格に準拠する。
【0025】
映像コーディング規格は、主に周知のITU-TおよびISO/IEC規格の開発によって発展してきた。ITU-TはH.261とH.263を作り、ISO/IECはMPEG-1とMPEG-4 Visualを作り、両団体はH.262/MPEG-2 VideoとH.264/MPEG-4 AVC(Advanced Video Coding)とH.265/HEVC規格を共同で作った。H.262以来、映像コーディング規格は、時間的予測と変換コーディングが利用されるハイブリッド映像コーディング構造に基づく。HEVCを超えた将来の映像コーディング技術を探索するため、2015年には、VCEGとMPEGが共同でJVET(Joint Video Exploration Team)を設立した。それ以来、多くの新しい方法がJVETによって採用され、JEM(Joint Exploration Mode)と呼ばれる参照ソフトウェアに組み込まれてきた。2018年4月には、VCEG(Q6/16)とISO/IEC JTC1 SC29/WG11(MPEG)の間にJVET(Joint Video Expert Team)が発足し、HEVCと比較して50%のビットレート削減を目標にVVC規格の策定に取り組んでいる。
【0026】
AVCおよびHEVCは、IDRまたはIRAP(Intra Random Access Point)ピクチャを導入することなく解像度を変更する能力を有しておらず、そのような能力は、ARC(Adaptive Resolution Change)とも呼ばれる。以下を含む、ARC機能からの恩恵を受けることになる使用事例またはアプリケーションシナリオがある。
【0027】
-テレビ電話および会議におけるレート適応:コーディングされた映像を変化するネットワーク条件に適応させるために、ネットワーク条件が悪化し、利用可能な帯域幅が低下すると、エンコーダは、より解像度の低いピクチャを符号化することでこれに適応してよい。現在、ピクチャの解像度を変更することは、IRAPピクチャの後にしか行うことができないため、いくつかの問題がある。妥当な品質のIRAPピクチャは、インター符号化されたピクチャよりもずっと大きく、それに対応して復号化するのがより複雑となり、これにより時間とリソースがかかる。これは、ローディングの理由でデコーダが解像度の変更を要求した場合に問題となる。また、低遅延バッファ状態を壊し、オーディオを強制的に再同期させ、ストリームのエンドツーエンドの遅延が少なくとも一時的に増加する可能性がある。これにより、ユーザエクスペリアンスが低下する。
【0028】
-マルチパーティビデオ会議におけるアクティブスピーカの変更:マルチパーティによるビデオ会議の場合、アクティブスピーカは、残りの会議参加者の映像よりも大きい映像サイズで示されることが一般的である。アクティブスピーカが変わった場合、各参加者のピクチャ解像度を調整することも必要となり得る。ARC機能を有する必要性は、このようなアクティブスピーカの変更が頻繁に発生する場合に、より重要になる。
【0029】
-ストリーミングの高速スタート:ストリーミングアプリケーションの場合、アプリケーションは、表示を開始する前に、復号化されたピクチャの一定の長さをバッファリングすることが一般的である。より小さい解像度でビットストリームを開始することにより、アプリケーションがバッファ内に十分なピクチャを有し、より高速に表示を開始することができるようになる。
【0030】
ストリーミングにおける適応ストリームの切替:DASH(Dynamic Adaptive Streaming over HTTP)仕様は、@mediaStreamStructureIdと呼ばれる特徴を含む。これにより、開GOPランダムアクセスポイントにおける異なる表現と、復号化不可の先頭ピクチャ、例えば、HEVCにおいて関連付けられたRASLピクチャを有するCRAピクチャとの間で切り替えることができる。同じ映像の2つの異なる表現は、異なるビットレートを有するが、同じ空間的解像度を有し、@mediaStreamStructureIdの同じ値を有する場合、関連付けられたRASLピクチャを有するCRAピクチャで2つの表現の切り替えを行うことができ、CRAピクチャでの切り替えに関連付けられたRASLピクチャは、許容可能な品質で復号化することができるため、シームレスな切り替えを可能にする。ARCを使用すると、@mediaStreamStructureId機能は、異なる空間的解像度を有するDASH表現間の切り替えにも利用可能である。
【0031】
ARCは、動的解像度変換としても知られている。
【0032】
ARCは、H.263 Annex PなどのRPR(Reference Picture Resampling)の特殊な場合と見なされてもよい。
【0033】
1.1. H.263 Annex Pにおける参照ピクチャの再サンプリング
【0034】
このモードは、参照ピクチャを予測に使用する前に、この参照ピクチャをワープするためのアルゴリズムを説明する。それは、予測されるピクチャとは異なるソースフォーマットを有する参照ピクチャを再サンプリングするために有用となり得る。また、参照ピクチャの形状、サイズ、および位置をワープすることにより、グローバルな動き推定、または回転動きの推定に使用されてもよい。構文は、使用されるべきワーピングパラメータおよび再サンプリングアルゴリズムを含む。アップサンプリングおよびダウンサンプリングの処理に対してFIRフィルタのみを適用する必要があるため、参照ピクチャの再サンプリングモードに対する最もシンプルな動作レベルは、暗黙係数が4の再サンプリングである。この場合、(ピクチャヘッダに示された)新しいピクチャのサイズが前のピクチャのサイズと異なる場合にその使用が理解されるため、追加の信号通知のオーバーヘッドは必要ない。
【0035】
1.2. ARCのVVCへの貢献
1.2.1. JVET-M0135
【0036】
JCTVC-F158の一部を除き、以下に述べるARCの予備設計は、今回の議論のきっかけとなるプレースホルダーとなるべきである。
【0037】
1.2.1.1 基本ツールの説明
【0038】
ARCをサポートするための基本ツールの制約は、以下の通りである。
【0039】
空間的解像度は、両方の寸法に適用された場合、公称解像度とは係数0.5だけ異なってよい。空間的解像度は増加または減少し、0.5および2.0のスケーリング比をもたらし得る。
【0040】
映像フォーマットのアスペクト比および彩度フォーマットは変更されない。
【0041】
クロッピング領域は、空間的解像度に比例してスケーリングされる。
【0042】
参照ピクチャは、必要に応じて簡単に再スケーリングされ、インター予測が従来通りに適用される。
【0043】
1.2.1.2 スケーリング動作
【0044】
簡単な、ゼロ位相分離可能なダウンスケーリングフィルタおよびアップスケーリングフィルタを使用することを提案する。なお、これらのフィルタは予測のみのためのものであり、デコーダは、出力のために、より洗練されたスケーリングを使用してよい。
【0045】
ゼロ位相および5つのタップを有する以下の1:2のダウンスケーリングフィルタが使用される。
【0046】
(-1,9,16,9,-1)/32
【0047】
ダウンサンプリング点は、偶数個のサンプル位置にあり、かつ、同じ位置にある。輝度および彩度についても同じフィルタが使用される。
【0048】
2:1のアップサンプリングの場合、最新のVVC WDにおける1/2画素動き補償補間フィルタ係数を使用して、奇数グリッド位置の追加サンプルが生成される。
【0049】
組み合わされたアップサンプリングおよびダウンサンプリングは、位相、または彩度サンプリング点の位置を変化させない。
【0050】
1.2.1.3 パラメータセットにおける解像度記述
【0051】
SPSにおけるピクチャ解像度の信号通知は、以下のように変更され、本明細書の以下の説明および残りの部分の両方において、二重括弧で囲まれた部分が削除されている(例えば、[[a]]は、文字“a”の削除を意味する)。
【0052】
シーケンスパラメータセットRBSP構文および意味論
【0053】
【表1】
【0054】
[[pic_width_in_luma_samplesは、輝度サンプル単位で各復号化されたピクチャの幅を規定する。pic_width_in_luma_samplesは、0に等しくなく、かつ、MinCbSizeYの整数倍とする。
【0055】
pic_height_in_luma_samplesは、輝度サンプル単位で各復号化されたピクチャの高さを規定する。pic_height_in_luma_samplesは、0に等しくなく、かつ、MinCbSizeYの整数倍とする。]]
【0056】
num_pic_size_in_luma_samples_minus1+1は、コーディングされた映像シーケンスに存在し得る輝度サンプル単位でピクチャサイズ(幅および高さ)の数を規定する。
【0057】
pic_width_in_luma_samples[i]は、コーディングされた映像シーケンスに存在し得る輝度サンプル単位で復号化されたピクチャのi番目の幅を規定する。pic_width_in_luma_samples[i]は、0に等しくなく、かつ、MinCbSizeYの整数倍とする。
【0058】
pic_height_in_luma_samples[i]は、コーディングされた映像シーケンスに存在し得る輝度サンプル単位で復号化されたピクチャのi番目の高さを規定する。pic_height_in_luma_samples[i]は、0には等しくなく、かつ、MinCbSizeYの整数倍とする。
【0059】
ピクチャパラメータセットRBSP構文および意味論
【0060】
【表2】
【0061】
pic_size_idxは、シーケンスパラメータセットにおけるi番目のピクチャサイズのインデックスを規定する。ピクチャパラメータセットを参照するピクチャの幅は、輝度サンプルにおけるpic_width_in_luma_samples[pic_size_idx]である。同様に、ピクチャパラメータセットを参照するピクチャの高さは、輝度サンプルにおけるpic_height_in_luma_samples[pic_size_idx]である。
【0062】
1.2.2. JVET-M0259
1.2.2.1. 背景:サブピクチャ
【0063】
サブピクチャトラックという用語は、OMAF(Omnidirectional Media Format)において、以下のように定義される。トラックは、他のトラック(複数可)の空間的関係を有し、かつ、コンテンツ制作側で映像符号化する前に空間的サブセットに分割された元の映像コンテンツの空間的サブセットを表す。HEVCのためのサブピクチャトラックは、動き制約タイルセットのためのパラメータセットおよびスライスセグメントヘッダを、それが自立型HEVCビットストリームになるように書き換えることによって構築することができる。サブピクチャ表現は、サブピクチャトラックを搬送するDASH表現として定義され得る。
【0064】
JVET-M0261は、VVCの空間的分割ユニットとしてサブピクチャという用語を使用し、以下のようにまとめた。
1.ピクチャは、サブピクチャ、タイルグループ、およびタイルに分けられる。
2.サブピクチャは、tile_group_addressが0に等しいタイルグループから始まる矩形のタイルグループのセットである。
3.各サブピクチャは、それ自体のPPSを参照してよく、従って、それ自体のタイル分割を有していてよい。
4.サブピクチャは、復号化処理においてピクチャと同様に扱われる。
5.サブピクチャを復号化するための参照ピクチャは、復号化ピクチャバッファにおける参照ピクチャから、現在のサブピクチャと並置される領域を抽出することで生成される。抽出された領域は、復号化されたサブピクチャであり、すなわち、インター予測は、ピクチャ内の同じサイズで同じ位置のサブピクチャ間で行われる。
6.タイルグループは、サブピクチャのタイルラスタスキャンにおけるタイルのシーケンスである。
【0065】
この寄与において、我々は、JVET-M0261に定義されるような用語サブピクチャを参照する。しかしながら、JVET-M0261に定義されるようなサブピクチャシーケンスをカプセル化するトラックは、OMAFに定義されるサブピクチャトラックと非常に類似した特性を有し、以下に示される例は、いずれの場合も当てはまる。
【0066】
1.2.2.2. ユースケース
1.2.2.2.1. ストリーミングにおける適応的解像度の変更
【0067】
適応ストリーミングのサポートの要件
【0068】
MPEG N17074の5.13章(「適応ストリーミングのサポート」)は、VVCに対して以下の要件を含む。
【0069】
本規格は、それぞれが異なる特性(例えば、空間的解像度またはサンプルビット深度)を有する、同じコンテンツの複数の表現を提供する適応ストリーミングサービスの場合、高速表現切り替えをサポートするものとする。本規格は、異なる空間的解像度などの異なる特性の表現間の高速かつシームレスな表現切り替え能力を損なうことなく、効率的な予測構成(例えば、いわゆるピクチャの開グループ)を使用することを可能にする。
【0070】
表現切り替えを伴う開GOP予測構造の例
【0071】
適応ビットレートストリーミングのためのコンテンツ生成は、異なる空間的解像度を有し得る異なる表現の生成を含む。クライアントは、表現にセグメントを要求し、従って、どの解像度およびビットレートでコンテンツが受信されるかを決定することができる。クライアント側では、異なる表現のセグメントを連結し、復号化し、再生する。クライアントは、デコーダインスタンスでシームレスな再生を実現できなければならない。従来、図1に示すように、閉GOP構造(IDRピクチャで始まる)が使用されている。
【0072】
開GOP予測構造(CRAピクチャで始まる)は、それぞれの閉GOP予測構造よりも優れた圧縮性能を可能にする。例えば、IRAPピクチャ間隔が24ピクチャである場合、輝度ジョンテガール差分ビットレートの平均ビットレート低減は、5.6%となった。
【0073】
開GOP予測構造は、報告によれば、主観的に視認可能な品質のポンピングをも低減する。
【0074】
ストリーミングにおける開GOPの使用における課題は、表現を切り替えた後、RASLピクチャを正しい参照ピクチャで復号化することができないことである。以下、図2に提示された表現に関連して、この課題を説明する。
【0075】
CRAピクチャから始まるセグメントは、少なくとも1つの参照ピクチャが前のセグメントにあるRASLピクチャを含む。これは、図3に示されており、両方のビットストリームにおけるピクチャ0は、前のセグメントに存在し、RASLピクチャを予測するための基準として使用される。
【0076】
図4には、図2に破線の長方形が付けられた表現切り替えが示されている。RASLピクチャの参照ピクチャ(「ピクチャ0」)は復号化されていないことが分かる。その結果、RASLピクチャは復号化できず、映像の再生にギャップが生じる。
【0077】
しかしながら、本発明の実施形態に基づいて説明したように、再サンプリングした参照ピクチャにてRASLピクチャを復号化することは、主観的に許容可能であることが分かった。図5に、「ピクチャ0」を再サンプリングし、RASLピクチャを復号化するための参照ピクチャとして用いることを示す。
【0078】
1.2.2.2.2. RWMR(Region-Wise Mixed-Resolution)360°映像ストリーミングにおけるビューポートの変更
【0079】
背景:HEVCベースのRWMRストリーミング
【0080】
RWMR360°ストリーミングは、ビューポートの有効空間的解像度を向上させる。ビューポートをカバーするタイルが、6K(6144×3072)のERPピクチャまたは図6に示すように「4K」の復号化能力(HEVCレベル5.1)を有するのと等価なCMP解像度に由来するスキームは、OMAFのD.6.3項およびD.6.4項に含まれ、かつ、VR産業協議会の指針にも採用された。このような解像度は、クアッドHD(2560×1440)ディスプレイパネルを使用したヘッドマウントディスプレイに適していると主張されている。
【0081】
符号化:コンテンツは、それぞれキューブ面サイズ1536×1536および768×768の2つの空間的解像度で符号化される。両方のビットストリームにおいて、6×4のタイルグリッドが使用され、各タイル位置に対してMCTS(Motion Constrained Tile Set)がコーディングされる。
【0082】
カプセル化:各MCTSシーケンスは、サブピクチャトラックとしてカプセル化され、DASHにおけるサブピクチャ表現として利用可能にされる。
【0083】
ストリーミングされたMCTSの選択:高解像度ビットストリームから12個のMCTSが選択され、低解像度ビットストリームから相補的な12個のMCTSが抽出される。よって、ストリーミングされたコンテンツの半球(180°×180°)は、高解像度ビットストリームに由来する。
【0084】
MCTSの復号化されるビットストリームへのマージ:1つの時間インスタンスの受信されたMCTSは、HEVCレベル5.1に準拠する1920×4608のコーディングされたピクチャにマージされる。マージされたピクチャの別の選択肢は、幅768の4つのタイル列、幅384の2つのタイル列、および高さ768の3つのタイル行の輝度サンプルを有し、3840×2304の輝度サンプルのピクチャを得ることである。
【0085】
背景:ビューポートに依存する360°ストリーミングのための異なるIRAP間隔のいくつかの表現
【0086】
HEVCベースのビューポートに依存する360°のストリーミングにおいて、視線の向きが変化する場合、次のIRAPに整列されたセグメント境界において、サブピクチャ表現の新たな選択を有効にすることができる。サブピクチャ表現は、復号化のためにコーディングされたピクチャにマージされるので、VCL NALユニットタイプは、すべての選択されたサブピクチャ表現において整列される。
【0087】
視線の向きが安定している場合、視線方向の変化に反応する応答時間とレートひずみ性能との間をトレードオフするために、異なるIRAP間隔で複数のバージョンのコンテンツをコーディングすることができる。これは、図6に提示された符号化のための、並置された1セットのサブピクチャ表現として図7に示す。
【0088】
図8は、まずサブピクチャの位置が、より低い解像度(384×384)で受信するように選択される例を提示する。視線の向きを変えることにより、より高い解像度(768×768)でサブピクチャ位置を新たに選択することができる。この例において、視線の向きの変更は、セグメント4が短IRAP区間のサブピクチャ表現から受信されるように行われる。その後、視線の向きが安定しているので、セグメント5から始まる長IRAP間隔バージョンが使用できる。
【0089】
問題点について
【0090】
典型的な視認状況では、視線の向きが徐々に変化するため、RWMRビューポートに依存したストリーミングにおけるサブピクチャ位置のサブセットのみにおいて、解像度が変化する。図9は、図6からわずかに上向きに右側の立方体面に向かって見る向きの変化を示す。前回とは異なる解像度を有するキューブ面分割を「C」で示す。24個のキューブ面分割のうち6個のキューブ面分割において、解像度が変化したことがわかる。しかしながら、上述したように、IRAPピクチャから始まるセグメントは、視線の向きの変化に呼応して、24個のキューブ面分割全てについて受信する必要がある。IRAPピクチャから始まるセグメントですべてのサブピクチャの位置を更新することは、ストリーミングレートひずみ性能の点で非効率である。
【0091】
さらに、レートひずみ性能を改善し、閉GOP予測構造によって引き起こされる可視ピク品質のチャポンピングを回避するために、RWMR360°ストリーミングのサブピクチャ表現と共に開GOP予測構造を使用できることが望ましい。
【0092】
提案される設計目標
【0093】
以下の設計目標を提案する。
【0094】
1.VVC設計は、ランダムアクセスピクチャに由来するサブピクチャと非ランダムアクセスピクチャに由来する別のサブピクチャとを、VVCに準拠する同じコーディングされたピクチャにマージすることを可能にするべきである。
【0095】
2.VVC設計は、サブピクチャ表現を単一のVVCビットストリームにマージすることを可能にしつつ、異なる空間的解像度などの異なる特性のサブピクチャ表現間の高速かつシームレスな表現切り替え能力を損なうことなく、サブピクチャ表現における開GOP予測構造の使用を可能にするべきである。
【0096】
設計目標は、2つのサブピクチャ位置のサブピクチャ表現を提示する図10で説明することができる。両方のサブピクチャ位置に対して、2つの解像度と2つのランダムアクセス間隔との間の各組み合わせに対して、コンテンツの別個のバージョンがコーディングされる。セグメントのいくつかは、開GOP予測構造から始まる。視線の向きの変更により、セグメント4の開始時にサブピクチャ位置1の解像度が切り替えられる。セグメント4は、RASLピクチャに関連付けられたCRAピクチャから始まるので、セグメント3にあるRASLピクチャのこれらの参照ピクチャを再サンプリングすることが必要である。なお、この再サンプリングはサブピクチャ位置1に適用され、他のサブピクチャ位置の復号化サブピクチャは再サンプリングされない。この例において、視線の向きの変化は、サブピクチャ位置2の解像度を変化させず、従って、サブピクチャ位置2の復号化されたサブピクチャは再サンプリングされない。セグメント4の第1のピクチャにおいて、サブピクチャ位置1のセグメントは、CRAピクチャに由来するサブピクチャを含み、サブピクチャ位置2のセグメントは、非ランダムアクセスピクチャに由来するサブピクチャを含む。VVCにおいて、これらのサブピクチャを1つのコーディングされたピクチャにマージすることができるようにすることが提案される。
【0097】
1.2.2.2.3. テレビ会議における適応解像度変更
【0098】
JCTVC-F158は、主にテレビ会議用の適応解像度変更を提案している。JCTVC-F158から以下のサブセクションがコピーされ、適応解像度の変更が有用であると主張される使用事例を紹介する。
【0099】
シームレスなネットワーク適応およびエラー耐性
【0100】
ビデオ会議およびパケットネットワークを介したストリーミングなどの適用において、符号化されたストリームは、特にビットレートが高くなり過ぎてデータが失われている場合に、ネットワーク条件の変化に適用することが頻繁に求められている。そのような適用は、一般的に、エンコーダがエラーを検出し、調整を実行できるようにする戻りチャネルを有する。エンコーダには、ビットレートの低減と、時間的または空間的な解像度の変更という2つの主なツールがある。時間的解像度の変更は、階層予測構造を使用したコーディングによって有効に実現することができる。しかしながら、最高品質のために、空間的解像度は、映像通信のためのうまく設計されたエンコーダの一部と同様に、変更が必要である。
【0101】
AVC内の空間的解像度を変更するには、IDRフレームを送信し、ストリームをリセットする必要がある。これは重大な問題を引き起こす。妥当な品質のIDRフレームは、インターピクチャよりもずっと大きく、それに対応して復号化するのがより複雑となり、これにより時間とリソースがかかる。これは、ローディングの理由でデコーダが解像度の変更を要求した場合に問題となる。また、低遅延バッファ状態を壊し、オーディオを強制的に再同期させ、ストリームのエンドツーエンドの遅延が少なくとも一時的に増加する可能性がある。これにより、ユーザエクスペリアンスが低下する。
【0102】
これらの問題を最小限に抑えるために、IDRは、一般的に、Pフレームに類似したビット数を使用して低品質で送信され、所与の解像度の場合、十分な品質に戻るまでにかなりの時間がかかる。十分に低い遅延を得るために、品質は非常に低く、実際には、画像が「リフォーカス」される前に、目に見えるぼやけがあることが多い。実際において、イントラフレームは、圧縮の観点から見て、有用な作業が非常に少なく、ストリームを再スタートさせる方法に過ぎない。
【0103】
そのため、HEVCにおいて、主観的な体験への影響を最小限に抑えつつ、特に困難なネットワーク条件において、解像度を変更することができる方法が求められている。
【0104】
高速スタート
【0105】
最初のフレームが低解像度で送信され、次の数フレームにわたって解像度が向上する「高速スタート」モードを有することは、遅延を低減し、開始において受け入れられないほどの画像のぼやけを生じることなく、より迅速に通常の品質にするために有用である。
【0106】
会議「構成」
【0107】
また、テレビ会議は、話している人がフルスクリーンで表示され、他の参加者がより小さい解像度の窓に表示される特徴を有することが多い。これを効率的にサポートするために、小さなピクチャは低い解像度で送信されることが多い。そして、この解像度は、参加者がスピーカになり、フルスクリーンされた場合に高くなる。この時点でイントラフレームを送信すると、映像ストリームにおいて不快なヒックアップを引き起こす。この影響は、スピーカが急速に交互に変わる場合、非常に目立ち、不快になる可能性がある。
【0108】
1.2.2.3. 提案される設計目標
【0109】
以下は、VVCバージョン1のために提案されるハイレベル設計選択肢である。
【0110】
1.以下の使用事例のために、VVCバージョン1に参照ピクチャ再サンプリング処理を含めることを提案する。
【0111】
-異なる空間的解像度などの異なる特性の表現間の高速かつシームレスな表現切り替え能力を損なうことなく、適応ストリームにおける効率的な予測構造(例えば、いわゆるピクチャの開グループ)を使用すること。
【0112】
-大幅な遅延または遅延の変動を伴わずに、低遅延の会話型映像コンテンツをネットワーク条件およびアプリケーション起源の解像度の変化に適応させること。
【0113】
2.VVC設計は、ランダムアクセスピクチャに由来するサブピクチャと非ランダムアクセスピクチャに由来する別のサブピクチャとを、VVCに準拠する同じコーディングされたピクチャにマージすることを可能にするために提案される。これは、混合品質および混合解像度のビューポート適応型360°ストリーミングにおける視線の向きの変化を効率的に処理することを可能にするために主張される。
【0114】
3.VVCバージョン1において、サブピクチャワイズの再サンプリング処理を含めることを提案する。これは、混合解像度ビューポート適応型360°ストリーミングにおける視線の向きの変化をより効率的に処理するための効率的な予測構造を可能にするために主張される。
【0115】
1.2.3. JVET-N0048
【0116】
ARC(Adaptive resolution Changing)のための使用事例および設計目標は、JVET-M0259に詳細に記載されている。以下にその概要を示す:
【0117】
1.リアルタイム通信
【0118】
本来、JCTVC-F158には、適応解像度の変更のための以下の使用事例が含まれていた。
【0119】
a.シームレスなネットワーク適応およびエラー耐性(動的適応解像度の変更による)
【0120】
b.高速起動(セッション開始時またはリセット時に徐々に解像度を上げる)
【0121】
c.会議の「構成」(話している人の方に高い解像度を与える)
【0122】
2.適応ストリーミング
【0123】
MPEG N17074の5.13章(「適応ストリーミングのサポート」)は、VVCに対して以下の要件を含む。
【0124】
本規格は、それぞれが異なる特性(例えば、空間的解像度またはサンプルビット深度)を有する、同じコンテンツの複数の表現を提供する適応ストリーミングサービスの場合、高速表現切り替えをサポートする。本規格は、異なる空間的解像度などの異なる特性の表現間の高速かつシームレスな表現切り替え能力を損なうことなく、効率的な予測構造(例えば、いわゆるピクチャの開グループ)を使用することを可能にする。
【0125】
JVET-M0259は、先頭ピクチャの参照ピクチャを再サンプリングすることで、この要件をどのように満たすかを検討している。
【0126】
3. 360度ビューポート依存ストリーミング
【0127】
JVET-M0259は、先頭ピクチャの参照ピクチャの特定の独立してコーディングされたピクチャ領域を再サンプリングすることで、この使用事例にどのように対処するかを検討している。
【0128】
この寄与は、上述したすべての使用事例および設計目標を満たすことを主張する適応解像度コーディングアプローチを提案する。360度ビューポートに依存するストリーミングおよび会議「構成」の使用事例は、JVET-N0045(独立したサブピクチャ層を提案する)と共に本提案で取り扱う。
【0129】
提案仕様テキスト
【0130】
信号通知
【0131】
sps_max_rpr
【0132】
【表3】
【0133】
sps_max_rprは、CVSの任意のタイルグループの参照ピクチャリスト0または1の中で、現在のピクチャのpic_width_in_luma_samplesおよびpic_height_in_luma_samplesとそれぞれ等しくないpic_width_in_luma_samplesおよびpic_height_in_luma_samplesを有するアクティブな参照ピクチャの最大数を規定する。
【0134】
ピクチャの幅と高さ
【0135】
【表4】
【0136】
【表5】
【0137】
max_width_in_luma_samplesは、このSPSがアクティブになっているCVSの任意のピクチャに対する任意のアクティブなPPSのpic_width_in_luma_samplesがmax_width_in_luma_samples以下であることが、ビットストリーム適合性の要件であることを規定する。
max_height_in_luma_samplesは、このSPSがアクティブになっているCVSの任意のピクチャに対する任意のアクティブなPPSのpic_height_in_luma_samplesがmax_height_in_luma_samples以下であることが、ビットストリーム適合性の要件であることを規定する。
【0138】
高レベル復号化処理
【0139】
復号化処理は、現在のピクチャCurrPicに対して以下のように動作する。
1.NALユニットの復号化は8.2項で規定される。
2.8.3項の処理は、タイルグループヘッダ層およびそれより上位の構文要素を使用して、以下の復号化処理を規定する。
-ピクチャオーダカウントに関連する変数および関数は、8.3.1項で規定されるように導出される。これは、ピクチャの第1のタイルグループに対してのみ呼び出す必要がある。
-非IDRピクチャの各タイルグループに対する復号化処理の最初に、参照ピクチャリスト0(RefPicList[0])と参照ピクチャリスト1(RefPicList[1])の導出のために、8.3.2項に規定された参照ピクチャリスト構築のための復号化処理が呼び出される。
-8.3.3項の参照ピクチャマーキングのための復号化処理が呼び出され、参照ピクチャは、「参照のために使用されない」または「長期参照のために使用される」としてマークされてもよい。これは、ピクチャの第1のタイルグループに対してのみ呼び出す必要がある。
-RefPicList[0]およびRefPicList[1]の各アクティブ参照ピクチャのうち、pic_width_in_luma_samplesまたはpic_height_in_luma_samplesがCurrPicのpic_width_in_luma_samplesまたはpic_height_in_luma_samplesとそれぞれ等しくないものについては、以下のようになる。
-X.Y.Z項における再サンプリング処理は、入力と同じ参照ピクチャマーキングおよびピクチャオーダカウントを有する出力として呼び出される[Ed.(MH):追加される呼び出しパラメータの詳細]。
-再サンプリング処理の入力として使用された参照ピクチャは、「参照に使用されない」とマークされる。
3.[Ed.(YK):ここで、コーディングツリーユニット、スケーリング、変換、インループフィルタリング等の復号化処理の呼び出しを加える。]
4.現在のピクチャのすべてのタイルグループが復号化された後、現在の復号化されたピクチャは「短期参照に使用される」とマークされる。
【0140】
再サンプリング処理
【0141】
SHVC再サンプリング処理(HEVC H.8.1.4.2項)に以下を追加することを提案する。
・・・
sps_ref_wraparound_enabled_flagが0に等しい場合、n=0..7のサンプル値tempArray[n]は、以下のように導出される。
tempArray[n]=
(fL[xPhase,0]*rlPicSampleL[Clip3(0,refW-1,xRef-3),yPosRL]+
fL[xPhase,1]*rlPicSampleL[Clip3(0,refW-1,xRef-2),yPosRL]+
fL[xPhase,2]*rlPicSampleL[Clip3(0,refW-1,xRef-1),yPosRL]+
fL[xPhase,3]*rlPicSampleL[Clip3(0,refW-1,xRef),yPosRL]+
fL[xPhase,4]*rlPicSampleL[Clip3(0,refW-1,xRef+1),yPosRL]+
fL[xPhase,5]*rlPicSampleL[Clip3(0,refW-1,xRef+2),yPosRL]+
fL[xPhase,6]*rlPicSampleL[Clip3(0,refW-1,xRef+3),yPosRL]+
fL[xPhase,7]*rlPicSampleL[Clip3(0,refW-1,xRef+4),yPosRL])>>shift1 (H-38)
そうでない場合、n=0..7のサンプル値tempArray[n]は、以下のように導出される。
refOffset=(sps_ref_wraparound_offset_minus1+1)*MinCbSizeY
tempArray[n]=
(fL[xPhase,0]*rlPicSampleL[ClipH(refOffset,refW,xRef-3),yPosRL]+
fL[xPhase,1]*rlPicSampleL[ClipH(refOffset,refW,xRef-2),yPosRL]+
fL[xPhase,2]*rlPicSampleL[ClipH(refOffset,refW,xRef-1),yPosRL]+
fL[xPhase,3]*rlPicSampleL[ClipH(refOffset,refW,xRef),yPosRL]+
fL[xPhase,4]*rlPicSampleL[ClipH(refOffset,refW,xRef+1),yPosRL]+
fL[xPhase,5]*rlPicSampleL[ClipH(refOffset,refW,xRef+2),yPosRL]+
fL[xPhase,6]*rlPicSampleL[ClipH(refOffset,refW,xRef+3),yPosRL]+
fL[xPhase,7]*rlPicSampleL[ClipH(refOffset,refW,xRef+4),yPosRL])
>>shift1
・・・
sps_ref_wraparound_enabled_flagが0に等しい場合、n=0..3のサンプル値tempArray[n]は、以下のように導出される。
tempArray[n]=(fC[xPhase,0]*rlPicSampleC[Clip3(0,refWC-1,xRef-1),yPosRL]+
fC[xPhase,1]*rlPicSampleC[Clip3(0,refWC-1,xRef),yPosRL]+
fC[xPhase,2]*rlPicSampleC[Clip3(0,refWC-1,xRef+1),yPosRL]+
fC[xPhase,3]*rlPicSampleC[Clip3(0,refWC-1,xRef+2),yPosRL])>>shift1 (H-50)
そうでない場合、n=0..3のサンプル値tempArray[n]は、以下のように導出される。
refOffset=(sps_ref_wraparound_offset_minus1+1)*MinCbSizeY)/SubWidthC
tempArray[n]=
(fC[xPhase,0]*rlPicSampleC[ClipH(refOffset,refWC,xRef-1),yPosRL]+
fC[xPhase,1]*rlPicSampleC[ClipH(refOffset,refWC,xRef),yPosRL]+
fC[xPhase,2]*rlPicSampleC[ClipH(refOffset,refWC,xRef+1),yPosRL]+
fC[xPhase,3]*rlPicSampleC[ClipH(refOffset,refWC,xRef+2),yPosRL])
>>shift1
【0142】
1.2.4. JVET-N0052
【0143】
映像圧縮規格における概念としての適応型の解像度の変更は、少なくとも1996年あたりから行われており、特に、H.263+に関連した提案が、参照ピクチャ再サンプリング(RPR,Annex P)および低解像度更新(Annex Q)に対して行われている。最初はJCT-VCの時代にCisco社が提案したもので、次にVP9のコンテキストで(現在は適度に広く展開されている)、そして最近ではVVCのコンテキストで、一定の注目を集めるようになった。ARCは、所与のピクチャに対してコーディングされることが必要とされるサンプルの数を低減でき、所望される場合、結果として得られる参照ピクチャをより高い解像度にアップサンプリングできる。
【0144】
以下の2つのシナリオにおいて、ARCが特に興味深いと考える。
1)IDRピクチャのようなイントラ符号化ピクチャは、インターピクチャよりもかなり大きいことが多い。イントラ符号化されることが意図されたピクチャをダウンサンプリングすることは、理由にかかわらず、将来の予測のためのよりよい入力を提供することができる。それはまた、少なくとも低遅延の適用において、レート制御の観点からも明らかに有利である。
2)少なくとも一部のケーブルや衛星放送事業者が日常的に行っているように、コーデックを限界近くまで運用する場合、ARCはイントラ符号化されたピクチャではない映像でも、困難な遷移点のないシーン遷移などで便利な機能となる。
3)少し先の話になるが、固定解像度という概念は一般的に支持されるのだろうか?CRTがなくなり、レンダリングデバイスにスケーリングエンジンが普及したことで、レンダリングとコーディングの解像度のハードな縛りは過去のものとなった。また、当方は、映像シーケンスの中で多くの動作が行われている場合、たとえその動作が空間的に別の場所で行われていたとしても、多くの人は(おそらく高解像度に関連した)細かい部分に集中することができないことを示唆する利用可能な研究結果があることにも留意している。それが事実であり、一般的に受け入れられている場合、細かい粒度の解像度の変更は、適応QPよりも優れたレート制御メカニズムとなり得る。当方は、この点を今回の議論に取り上げた。なぜなら、当業者からのデータ-フィードバックが得られていないからである。もちろん、固定解像度のビットストリームという概念をなくすことは、無数のシステム層や実装上の影響があることは、(その詳細な性質はわからないまでも、少なくともその存在のレベルを)認識している。
【0145】
技術的には、ARCは参照ピクチャの再サンプリングとして実装することができる。参照ピクチャの再サンプリングを実装するには、再サンプリングフィルタと、ビットストリームにおける再サンプリング情報の信号通知という2つの大きな態様がある。本明細書では、後者に焦点を当て、前者については当社の実装経験の範囲内でのみ触れている。適切なフィルタ設計の更なる研究が望まれる
【0146】
既存のARC実装形態の概要
【0147】
図11および図12は、既存のARCエンコーダ/デコーダの実装形態をそれぞれ示す。本発明の実装形態において、ピクチャのタイプにかかわらず、ピクチャの粒度でピクチャの幅および高さを変更することが可能である。エンコーダにおいて、入力画像データを、現在のピクチャ符号化のために選択されたピクチャサイズにダウンサンプリングする。最初の入力ピクチャをイントラピクチャとして符号化した後、復号化されたピクチャをDPB(Decoded Picture Buffer)に記憶する。後続のピクチャを異なるサンプリング比でダウンサンプリングし、インターピクチャとして符号化する場合、DPBにおける参照ピクチャは、参照のピクチャサイズと現在のピクチャサイズとの間の空間的比率に従ってアップスケール/ダウンスケールされる。デコーダにおいて、復号化されたピクチャは再サンプリングされずにDPBに記憶される。しかしながら、DPBにおける参照ピクチャは、動き補償のために使用される場合、現在の復号化ピクチャと参照との間の空間的比率に対してアップスケール/ダウンスケールされる。復号化されたピクチャは、表示のためにバンプアウトされる時に、元のピクチャサイズまたは所望の出力ピクチャサイズにアップサンプリングされる。動き推定/補償処理において、動きベクトルは、ピクチャサイズ比およびピクチャオーダカウントの差との関連でスケーリングされる。
【0148】
ARCパラメータの信号通知
【0149】
ARCパラメータという用語は、本明細書では、ARCを動作させるために必要な任意のパラメータの組み合わせとして使用される。最も簡単な場合、それはズーム係数であってもよいし、または定義されたズーム係数を有する表へのインデックスであってもよい。これは、オブジェクト解像度(例えば、サンプルまたは最大CUサイズ粒度での)であってもよいし、またはJVET-M0135に提案されているように、オブジェクト解像度を提供する表へのインデックスであってもよい。また、使用されるアップ/ダウンサンプリングフィルタのフィルタセレクタまたはフィルタパラメータ(フィルタ係数まで)も含まれる。
【0150】
最初から、当方は、少なくとも概念的に、ピクチャの異なる部分に対して異なるARCパラメータを許可することを提案している。当方は、現在のVVC草案に基づく適切な構文構造は、長方形のTG(Tile Group)であることを提案する。スキャン順序のTGを使っている人たちは、ARCの使用がフルピクチャのみに制限されるか、スキャン順序のTGが長方形のTGに含まれる範囲に制限されることになる(これまでTGのネスティングが議論された記憶はなく、もしかしたら悪しきアイデアかもしれない)。これは、ビットストリーム制約によって容易に規定することができる。
【0151】
異なるTGは異なるARCパラメータを持つ可能性があるため、ARCパラメータの適切な場所は、TGヘッダの中かTGの範囲があるパラメータセットの中のどちらかであり、TGヘッダ、すなわち、現在のVVC草案での適応パラメータセット、または上位のパラメータセットの表へのより詳細な参照(インデックス)により参照される。これら3つの選択肢のうち、現時点では、TGヘッダを使用してARCパラメータを含む表のエントリへの参照をコーディングすることを提案するもので、その表をSPSに配置し、表の最大値を(来るべき)DPSにおいてコーディングする。パラメータセットの値を使用せずに、TGヘッダに直接ズーム係数をコーディングすることの受け入れも可能である。JVET-M0135で提案されているように、PPSを参照に使用することは、当方のようにARCパラメータのタイルグループごとの信号通知を設計基準としている場合には、逆に好ましくない。
【0152】
表のエントリそのものに関して、以下のような多くの選択肢がある。
●ダウンサンプル係数のコーディングは、寸法のいずれか一方または両方であるか、またはXおよびYの寸法において独立して行うか?これはほとんど(HWの)実装に関する議論であり、X寸法のズーム係数はかなり柔軟性があるが、Y寸法のズーム係数は1に固定されているか、または選択肢が非常に少ない選択を好む者もいるであろう。当方は、構文がこのような制約を表現するには場違いであると提言し、もし制約が望ましいのであれば、適合性の要件として制約が表現される方を好む。言い換えれば、構文をフレキシブルに保つ。
●コーディング対象の解像度。これについて、当方は下記のように提案する。現在の解像度に関連して、これらの解像度には多かれ少なかれ複雑な制約が存在し得、おそらくビットストリーム適合性で表される。
●ピクチャの組み立て/抽出を可能にするために、タイルグループごとのダウンサンプリングが好ましい。しかしながら、それは信号通知の観点から重要ではない。グループがARCをピクチャの粒度でのみ許可するという賢明でない決定をしていた場合、当方は、常に、すべてのTGが同じARCパラメータを使用するというビットストリーム適合性の要件を含めることができる。
●ARCに関する情報の制御。以下の発明者らの設計には、参照ピクチャサイズを含む。
●フィルタの設計に柔軟性を持たせる必要があるのか?一握りのコードポイントより大きいものはあるか?ある場合、それらをAPSに入れるか?(いいえ、再度のAPS更新の議論はしないでください。ダウンサンプルフィルタが変化し、ALFが維持される場合、ビットストリームはオーバーヘッドを受け入れなければならないと、当方は提案する。
【0153】
今回、提案された技術を(可能な限り)一貫したシンプルなものにするために、以下を提案する。
●固定フィルタの設計
●SPS内の表に表示されたターゲットの解像度、ビットストリームの制約TBD
●キャップの交換/交渉を容易にするためのDPSの最小/最大のターゲット解像度
【0154】
結果として得られる構文は、以下のように確認できる。
【0155】
デコーダパラメータセットRBSP構文
【0156】
【表6】
【0157】
max_pic_width_in_luma_samplesは、ビットストリームの輝度サンプル単位で復号化されたピクチャの最大の幅を規定する。max_pic_width_in_luma_samplesは、0に等しくなく、かつ、MinCbSizeYの整数倍とする。dec_pic_width_in_luma_samples[i]の値は、max_pic_width_in_luma_samplesの値よりも大きくすることはできない。
max_pic_height_in_luma_samplesは、輝度サンプル単位で復号化されたピクチャの最大の高さを規定する。max_pic_height_in_luma_samplesは、0に等しくなく、かつ、MinCbSizeYの整数倍でなければならない。dec_pic_height_in_luma_samples[i]の値は、max_pic_height_in_luma_samplesの値よりも大きくすることはできない。
【0158】
シーケンスパラメータセットRBSP構文
【0159】
【表7】
【0160】
1に等しいadaptive_pic_resolution_change_flagは、出力ピクチャサイズ(output_pic_width_in_luma_samples、output_pic_height_in_luma_samples)、復号化されたピクチャサイズの数の指示(num_dec_pic_size_in_luma_samples_minus1)、少なくとも1つの復号化されたピクチャサイズ(dec_pic_width_in_luma_samples[i]、dec_pic_height_in_luma_samples[i])がSPSに存在することを規定する。参照ピクチャサイズ(reference_pic_width_in_luma_samples、reference_pic_height_in_luma_samples)は、reference_pic_size_present_flagの値を条件に存在する。
output_pic_width_in_luma_samplesは、輝度サンプル単位で出力ピクチャの幅を規定する。output_pic_width_in_luma_samplesは0に等しくない。
output_pic_height_in_luma_samplesは、輝度サンプル単位で出力ピクチャの高さを規定する。output_pic_height_in_luma_samplesは0に等しくない。
1に等しいreference_pic_size_present_flagは、reference_pic_width_in_luma_samplesおよびreference_pic_height_in_luma_samplesが存在することを規定する。
reference_pic_width_in_luma_samplesは、輝度サンプル単位で参照ピクチャの幅を規定する。output_pic_width_in_luma_samplesは0に等しくない。存在しない場合、reference_pic_width_in_luma_samplesの値は、dec_pic_width_in_luma_samplesと等しいと推測される。
reference_pic_height_in_luma_samplesは、輝度サンプル単位で参照ピクチャの高さを規定する。output_pic_height_in_luma_samplesは0に等しくない。存在しない場合、reference_pic_height_in_luma_samplesの値は、dec_pic_height_in_luma_samplesと等しいと推測される。
【0161】
注1-出力ピクチャのサイズは、output_pic_width_in_luma_samplesおよびoutput_pic_height_in_luma_samplesの値と等しい。参照ピクチャのサイズは、参照ピクチャが動き補償に使用される場合、reference_pic_width_in_luma_samplesおよび_pic_height_in_luma_samplesの値と等しい。
num_dec_pic_size_in_luma_samples_minus1+1は、符号化された映像シーケンスにおいて、輝度サンプル単位で復号化されたピクチャサイズ(dec_pic_width_in_luma_samples[i]、dec_pic_height_in_luma_samples[i])の数を規定する。
dec_pic_width_in_luma_samples[i]は、符号化された映像シーケンスにおいて、輝度サンプルの単位で復号化されたピクチャサイズのi番目の幅を規定する。dec_pic_width_in_luma_samples[i]は、0に等しくなく、MinCbSizeYの整数倍とする。
dec_pic_height_in_luma_samples[i]は、符号化された映像シーケンスにおいて、輝度サンプル単位で復号化されたピクチャサイズのi番目の幅を規定する。dec_pic_height_in_luma_samples[i]は、0に等しくなく、MinCbSizeYの整数倍とする。
【0162】
注2-i番目の復号化ピクチャサイズ(dec_pic_width_in_luma_samples[i]、dec_pic_height_in_luma_samples[i])は、符号化された映像シーケンスの復号化されたピクチャサイズと等しくてもよい。
【0163】
タイルグループヘッダ構文
【0164】
【表8】
【0165】
dec_pic_size_idxは、復号化されたピクチャの幅がpic_width_in_luma_samples[dec_pic_size_idx]と等しく、かつ、復号化されたピクチャの高さがpic_height_in_luma_samples[dec_pic_size_idx]と等しくなることを規定する。
【0166】
フィルタ
【0167】
提案された設計は、概念的には、4つの異なるフィルタセット、即ち、元のピクチャから入力ピクチャへのダウンサンプリングフィルタ、動き推定/補償のための参照ピクチャを再スケーリングするためのアップ/ダウンサンプリングフィルタ、および、復号化ピクチャから出力ピクチャへのアップサンプリングフィルタ、を含む。最初および最後のものは、非標準的なものとして排除されてもよい。本明細書の範囲内で、アップ/ダウンサンプリングフィルタは、適切なパラメータセットにおいて明示的に信号通知されるか、または予め定義される必要がある。
【0168】
本実装形態は、動き補償に使用される参照ピクチャをリサイズするためにダウンサンプリングを行うための、12タップおよび2D分離可能フィルタである、SHVC(SHM第12.4版)のダウンサンプリングフィルタを使用する。現在の実装形態において、2進サンプリングのみがサポートされる。そのため、デフォルトでは、ダウンサンプリングフィルタの位相をゼロに設定する。アップサンプリングの場合、16位相を有する8タップ補間フィルタが使用され、位相をシフトさせ、輝度および彩度画素の位置を元の位置に合わせる。
【0169】
表1および表2は、輝度アップサンプリング処理に使用されるp=0..15およびx=0..7の8タップフィルタ係数fL[p,x]と、彩度アップサンプリング処理に使用されるp=0..15およびx=0..3の4タップフィルタ係数fC[p,x]とを示す。
【0170】
表3は、ダウンサンプリング処理における12タップのフィルタ係数を示す。同じフィルタ係数が、ダウンサンプリングのために輝度および彩度の両方に使用される。
【0171】
表1. 16位相を有する輝度アップサンプリングフィルタ
【0172】
【表9】
【0173】
表2. 16位相を有する彩度アップサンプリングフィルタ
【0174】
【表10】
【0175】
表3. 輝度および彩度のためのダウンサンプリングフィルタ係数
【0176】
【表11】
【0177】
当方は、他のフィルタ設計について実験していない。コンテンツおよび/またはスケーリング係数に適応可能なフィルタを使用する場合、(おそらく有意な)主観的および客観的な利得が期待され得るものと予想する。
【0178】
タイルグループ境界の議論について
【0179】
タイルグループに関連した多くの作業におそらく当てはまるので、本実装形態は、TG(Tile Group)ベースのARCに関しては、あまり完成されていない。当方は、圧縮ドメインにおいて、複数のサブピクチャの圧縮されたピクチャへの空間的な組み合わせや抽出に関する議論が、少なくとも作業草案を作成した後に、この実装形態を再検討したいと考えている。しかしながら、それは、私たちが結果をある程度外挿することを妨げず、そして私たちの信号通知の設計をそれに応じて適応させることを妨げない。
【0180】
ここで、既に述べた理由により、タイルグループヘッダは、上述したようにdec_pic_size_idxのようなもののための正しい場所であると考える。使用されるARCパラメータを示すために、タイルグループヘッダに条件付きで存在する単一のue(v)コードポイントdec_pic_size_idxを使用する。ピクチャごとだけのARCである本実装形態に合わせるためには、今すぐにでも仕様の空きにてやるべきことは、単一のタイルグループのみをコーディングするか、または、所与のコーディングされたピクチャのすべてのTGヘッダがdec_pic_size_idxの値が同じであること(存在する場合)をビットストリームコンプライアンスの条件とすることである。
【0181】
パラメータdec_pic_size_idxは、サブピクチャを開始するいかなるヘッダの中へも移動可能である。今のところ、タイルグループヘッダが継続して存在するのではないかと当方は考える。
【0182】
これらの構文上の考慮を超えて、タイルグループまたはサブピクチャベースのARCを可能にするために、いくつかの追加の作業が必要である。おそらく最も困難な部分は、サブピクチャをより低いサイズに再サンプリングした場合、ピクチャにおける不要なサンプルの問題にどのように対処するかである。
【0183】
4つのサブピクチャ(ビットストリーム構文では、おそらく4つの長方形のタイルグループとして表現される)で構成されている図13の右側の部分を考える。左側に向かって、右下のTGをサイズの半分にサブサンプリングする。「ハーフ」と記された該当する区域外のサンプルについて、どのように対処するか?
【0184】
既存の映像コーディング規格の中には、共通して、圧縮ドメインにおけるピクチャの一部の空間的抽出がサポートされていないものがある。これは、ピクチャの各サンプルが1または複数の構文要素によって表現され、各構文要素が少なくとも1つのサンプルに影響を与えることを意味する。この状態を維持したいのであれば、ダウンサンプリングされたTGでカバーされているサンプルの周辺に「ハーフ」というラベルを付けて、何らかの形で追加投入する必要がある。H.263+Annex Pは、この問題をパディングによって解決した。実際、パディングされたサンプルのサンプル値は、ビットストリームにおいて(ある厳しい制限内で)信号通知されてもよい。
【0185】
これまでの想定から大きく外れるかもしれないが、ピクチャの矩形部分に基づいてサブビットストリームの抽出(および組み合わせ)をサポートしたい場合には、いずれにしても必要となる可能性がある代替案は、(たとえその何かが、スキップされたブロックであっても)、再構成されたピクチャの各サンプルがコーディングされたピクチャの何かで表現されなければならないという現在の理解を緩和することになる。
【0186】
実装上の考慮事項、システムへの影響、プロファイル/レベル
【0187】
当方は、「ベースライン/メイン」プロファイルに含めるべき基本的なARCを提案する。特定の適用シナリオに必要でない場合、サブプロファイリングを使用してそれらを除去してもよい。特定の制限を許容可能としてもよい。この点については、あるH.263+のプロファイルや(プロファイルよりも前に作られた)「推奨モード」には、Annex Pを「4の暗黙係数」、すなわち、両方の寸法での2進ダウンサンプリングとしてのみ使用するという制限が含まれていることに、当方は留意している。テレビ会議における高速スタート(Iフレームを迅速に取得する)をサポートするのにそれで十分であった。
【0188】
その設計は、すべてのフィルタリングを「オンザフライ」で行うことができ、メモリの帯域幅の増加が全くない、またはごくわずかであると考えられる。その限りで、ARCをエキゾチックプロファイルに加える必要はない。
【0189】
マラケシュでJVET-M0135に関連して主張されたように、複雑な表などがケイパビリティ・エクスチェンジに有意義に使用できるとは考えていない。オファー・アンサーや同様の限定されたハンドシェイクを想定した場合、意味のあるクロスベンダーの相互運用を可能にするには、単純にオプションの数が多すぎる。現実的には、ケイパビリティ・エクスチェンジのシナリオで意味のある方法でARCをサポートするためには、せいぜい一握りのインターロップポイントに頼らざるを得ない。例えば、ARCなし、4の暗黙係数のARC、フルARCなど。別の方法として、すべてのARCに必要なサポートを仕様化し、ビットストリームの複雑性の制限を上位レベルのSDOに任せることもできる。これはいずれにしても、(サブプロファイリングやフラグコンテキストですでに行ったことを超えて)戦略的な議論をする必要がある。
【0190】
レベルについては、ビットストリーム適合性の条件として、ビットストリームでどれだけアップサンプリングが信号通知されていても、アップサンプリングされたピクチャのサンプル数はビットストリームのレベルに収まらなければならず、また、すべてのサンプルはアップサンプリングされたコーディングされたピクチャに収まらなければならないという基本的な設計原則が必要だと考える。なお、H263+ではこのようなことはなく、特定のサンプルが存在しない可能性があった。
【0191】
1.2.5. JVET-N0118
【0192】
以下の態様が提案される。
1)ピクチャの解像度のリストがSPSで信号通知され、リストのインデックスがPPSで信号通知され、個々のピクチャサイズが指定される。
2)出力されるピクチャについては、再サンプリング前の復号化されたピクチャが(必要に応じて)クロップし、出力され、つまり、再サンプリングされたピクチャは出力用ではなく、インター予測の参照用にのみ使用される。
3)1.5xおよび2xの再サンプリング率をサポート。任意の再サンプリング率をサポートしない。さらに、他の1、2種類の再サンプリング率の必要性を検討する。
4)ピクチャレベルの再サンプリングとブロックレベルの再サンプリングでは、ブロックレベルの再サンプリングの方が支持されている。
a.しかしながら、ピクチャレベルの再サンプリングを選択する場合、以下の態様が提案される。
i.参照ピクチャを再サンプリングするとき、再サンプリングされたバージョンの参照ピクチャと元の再サンプリングされたバージョンの参照ピクチャとの両方がDPBに記憶され、したがって、両方がDPBのフルネスに影響を及ぼす。
ii.対応する再サンプリングされていない参照ピクチャが「参照のために使用されない」とマークされている場合、再サンプリングされた参照ピクチャは、「参照のために使用されない」とマークされる。
iii.RPL信号通知構文は変更されず、RPL構築処理は以下のように修正される。参照ピクチャをRPLエントリに含めることが必要であり、かつ、現在のピクチャと同じ解像度を有するその参照ピクチャのバージョンがDPBに含まれていない場合、ピクチャ再サンプリング処理が呼び出され、かつ、その参照ピクチャの再サンプリングされたバージョンがRPLエントリに含まれる。
iv.DPBに存在し得る再サンプリングされた参照ピクチャの数は、例えば、2以下となるように制限される。
b.そうでない場合(ブロックレベルの再サンプリングが選択される)、以下が提案される。
i.最悪の場合のデコーダの複雑性を制限するために、現在のピクチャとは異なる解像度の参照ピクチャからのブロックの双方向予測が許可されないことを提案する。
ii.別の選択肢は、再サンプリングおよび1/4画素補間を行う必要がある場合、2つのフィルタを組み合わせ、この動作を直ちに適用することである。
5)ピクチャベースの再サンプリングアプローチとブロックベースの再サンプリングアプローチのどちらを選択するかに関わらず、必要に応じて時間的動きベクトルのスケーリングを適用することを提案する。
【0193】
1.2.5.1.実装
【0194】
ARCソフトウェアは、VTM-4.0.1の上に実装され、以下のように変更された。
-サポートされている解像度のリストがSPSにて信号通知される。
-空間的解像度信号通知は、SPSからPPSに移された。
-参照ピクチャを再サンプリングするために、ピクチャベースの再サンプリングスキームを実装した。ピクチャが復号化された後、再構成されたピクチャが異なる空間的解像度に再サンプリングされてよい。元の再構成ピクチャおよび再サンプリングされた再構成ピクチャは、両方ともDPBに記憶され、復号化の順序に将来のピクチャによって参照のために利用可能である。
-実装された再サンプリングフィルタは、JCTVC-H0234で試験されたフィルタに基づいており、以下のように行われる。
oアップサンプリングフィルタ:タップ(-4,54,16,-2)/64を有する、4タップ+/- 1/4位相DCTIF
oダウンサンプリングフィルタ:タップ(1,0,-3,0,10,16,10,0,-3,0,1)/32を有する、h11フィルタ
-現在のピクチャの参照ピクチャリスト(即ち、L0およびL1)を構築する場合、現在のピクチャと同じ解像度を有する参照ピクチャのみを使用する。なお、参照ピクチャサイズは、元のサイズでも、再サンプリングされたサイズでも利用可能であってよい。
-TMVPおよびATVMPは、有効化されてもよい。しかしながら、現在のピクチャと参照ピクチャの元のコーディング解像度が異なる場合、その参照ピクチャに対してTMVPおよびATMVPは無効化される。
-開始点ソフトウェアの実装形態の便宜上および簡素化のため、ピクチャを出力するとき、デコーダは最も高い利用可能な解像度を出力する。
【0195】
1.2.5.2. ピクチャサイズおよびピクチャ出力の信号通知について
1.ビットストリームにおけるコーディングされたピクチャの空間的解像度のリストにおいて
現在、CVSにおけるすべてのコーディングされたピクチャは同じ解像度を有する。従って、SPSにおいて1つの解像度(即ち、ピクチャの幅および高さ)のみを信号通知することは簡単である。ARCをサポートする場合、1つの解像度の代わりに、ピクチャ解像度のリストを信号通知することが必要であり、個々のピクチャサイズを規定するために、このリストがSPSにて信号通知され、このリストへのインデックスをPPSにて信号通知することを提案する。
2.ピクチャ出力について
出力されるピクチャについては、再サンプリング前の復号化されたピクチャを(必要に応じて)クロップし、出力する、つまり、再サンプリングされたピクチャは出力用ではなく、インター予測の参照用にのみ使用されることを提案する。ARC再サンプリングフィルタは、インター予測のために再サンプリングされたピクチャの使用を最適化するように設計されるべきであり、このようなフィルタは、ピクチャの出力/表示の目的に最適ではない場合があり、一方、映像端末デバイスは、通常、最適化された出力ズーム/スケーリング機能を既に実装している。
【0196】
1.2.5.3. 再サンプリングについて
【0197】
復号化されたピクチャの再サンプリングは、ピクチャベースのものであってもよいし、ブロックベースのものであってもよい。VVCの最終的なARC設計では、ピクチャベースの再サンプリングよりも、ブロックベースの再サンプリングを優先している。当方は、これら2つのアプローチを検討し、JVETがVVCにおけるARCサポートのためにこれら2つのアプローチのうちどちらを規定すべきかを決定することを推奨する。
【0198】
ピクチャベースの再サンプリング
【0199】
ARCのためのピクチャベースの再サンプリングにおいて、ピクチャは特定の解像度のために1回だけ再サンプリングされ、次いでDPBに記憶され、一方、同じピクチャの再サンプリングされていないバージョンもDPBに保持される。
【0200】
ARCに対してピクチャベースの再サンプリングを使用することには、以下の2つの問題がある。1)再サンプリングされた参照ピクチャを記憶するために、DPBバッファを追加する必要がある。2)DPBから参照ピクチャデータを読み取り、DPBに参照ピクチャデータを書き込む動作が増えるため、メモリの帯域幅を追加する必要がある。
【0201】
DPBにおいて1つのバージョンの参照ピクチャのみを保持することは、ピクチャベースの再サンプリングにとって好適なアイデアではない。再サンプリングされていないバージョンのみを保持する場合、複数のピクチャが同じ参照ピクチャを参照する場合があるので、参照ピクチャを複数回再サンプリングする必要がある場合がある。一方、参照ピクチャを再サンプリングし、再サンプリングされたバージョンのみを維持する場合、上述したように、再サンプリングされていないピクチャを出力する方がよいため、参照ピクチャを出力する必要がある場合、逆方向の再サンプリングを行う必要がある。これは、再サンプリング処理が可逆演算ではないため問題となる。ピクチャAをダウンサンプリングした後、アップサンプリングしてAと同じ解像度のA’を得たとしても、AとA’は同じではない。ダウンサンプリングとアップサンプリングの処理中に高周波の情報が失われているため、A’に含まれる情報はAよりも少なくなる。
【0202】
追加のDPBバッファおよびメモリ帯域幅の問題に対処するために、当方は、VVCにおけるARC設計がピクチャベースの再サンプリングを使用する場合、以下を適用することを提案する。
1.参照ピクチャを再サンプリングするとき、再サンプリングされたバージョンの参照ピクチャと元の再サンプリングされたバージョンの参照ピクチャとの両方がDPBに記憶され、したがって、両方がDPBのフルネスに影響を及ぼす。
2.対応する再サンプリングされていない参照ピクチャが「参照のために使用されない」とマークされている場合、再サンプリングされた参照ピクチャは、「参照のために使用されない」とマークされる。
3.各タイルグループのRPL(Reference Picture List)は、現在のピクチャと同じ解像度を有する参照ピクチャを含む。RPL信号通知構文を変更する必要はないが、RPL構築処理は、前文で言及されたことを保証するように、以下のように修正される。参照ピクチャをRPLエントリに含めることが必要であり、かつ、現在のピクチャと同じ解像度を有するその参照ピクチャのバージョンがまだ利用可能でない場合、ピクチャ再サンプリング処理が呼び出され、かつ、その参照ピクチャの再サンプリングされたバージョンが含まれる。
4.DPBに存在し得る再サンプリングされた参照ピクチャの数は、例えば、2以下となるように制限されるべきである。
【0203】
さらに、時間的MVが現在のものとは異なる解像度の参照フレームに由来する場合、時間的MVの使用(例えば、マージモードおよびATMVP)を可能にするために、当方は、時間的MVを必要に応じて現在の解像度にスケーリングすることを提案する。
【0204】
ブロックベースのARC再サンプリング
【0205】
ARCのためのブロックベースの再サンプリングにおいて、参照ブロックは必要に応じて再サンプリングされ、再サンプリングされたピクチャはDPBに記憶されない。
【0206】
ここでの主な問題は、付加的なデコーダの複雑性である。これは、参照ピクチャにおけるブロックが、別のピクチャにおける複数のブロックによって、および複数のピクチャにおける複数のブロックによって、複数回参照される場合があるためである。
【0207】
参照ピクチャにおけるブロックが現在のピクチャのブロックによって参照され、参照ピクチャの解像度と現在のピクチャの解像度が異なる場合、補間フィルタを呼び出すことによって、参照ブロックが整数画素の解像度を有するように参照ブロックを再サンプリングする。動きベクトルが1/4画素である場合、再び補間処理が呼び出され、1/4画素解像度で再サンプリングされた参照ブロックが取得される。従って、異なる解像度を伴う参照ブロックからの現在のブロックに対する各動き補償動作のために、1つの補間フィルタリング動作の代わりに2つまでの補間フィルタリング動作が必要である。ARCサポートがない場合、1つの補間フィルタ動作(すなわち、1/4画素の解像度での参照ブロックの生成)しか必要とされない。
【0208】
最悪の場合の複雑性を抑制するために、VVCにおけるARC設計がブロックベースの再サンプリングを使用する場合、以下が適用されることを提案する。
-現在のピクチャとは異なる解像度を有する参照ピクチャからのブロックの双方向予測が許可されない。
-より正確には、この制約は以下の通りである。現在のピクチャpicAにおける現在のブロックblkAが、参照ピクチャpicBにおける参照ブロックblkBを参照する際に、picAとpicBとが異なる解像度を有する場合、ブロックblkAは、単一予測ブロックであるとする。
【0209】
この制約により、ブロックを復号化するのに必要な最悪の場合の補間動作の数は、2回に限定される。ブロックが異なる解像度のピクチャからのブロックを参照する場合、上述したように、必要な補間動作の数は2回である。これは、補間演算の数も2回であるため(すなわち、各参照ブロックに対し1/4画素の解像度を得るため)、ブロックが同じ解像度のピクチャからの参照ブロックを参照し、双方向予測ブロックとして符号化した場合と同様である。
【0210】
実装形態を簡単にするために、当方は、VVCにおけるARC設計がブロックベースの再サンプリングを使用する場合、以下を適用する別の変形を提案する。
-参照フレームと現在のフレームの解像度が異なる場合、まず、予測子のすべての画素の対応する位置が計算され、次いで、補間が1回だけ適用される。即ち、2つの補間動作(即ち、1つは再サンプリングのためであり、1つは1/4画素補間のためである)を1つの補間演算のみに結合する。現在のVVCにおけるサブ画素補間フィルタは再利用可能であるが、この場合、補間の粒度を大きくするべきであるが、補間動作の回数を2から1に短縮する。
-時間的MVが現在のものとは異なる解像度の参照フレームに由来する場合に、時間的MVの使用(例えば、マージモードおよびATMVP)を可能にするために、当方は、時間的MVを必要に応じて現在の解像度にスケーリングすることを提案する。
【0211】
再サンプリング率
【0212】
JVET-M0135において、ARCに関する議論を始めるために、ARCの開始点として、2x(アップサンプリングの場合、2×2、ダウンサンプリングの場合、1/2×1/2を意味する)の再サンプリング比のみを考慮することが提案された。マラケシュ会議の後、このトピックをさらに検討したところ、2xの再サンプリング比のみをサポートすることは、非常に限られており、場合によっては、再サンプリング解像度と非再サンプリング解像度の差が小さいほど有益であることが分かった。
【0213】
任意の再サンプリング率をサポートすることが望ましい場合があるが、それをサポートすることは困難であると思われた。これは、任意の再サンプリング率をサポートするために、定義され実装されなければならない再サンプリングフィルタの数が多すぎ、デコーダの実装形態に大きな負担がかかるように思われたためである。
【0214】
当方は、2つ以上であるが少数の再サンプリング比をサポートすべきであるが、少なくとも1.5xおよび2xの再サンプリング比、および任意の再サンプリング比はサポートされないと提案する。
【0215】
最大DPBバッファサイズおよびバッファフルネス
【0216】
ARCの場合、DPBは、同じCVS内に、異なる空間的解像度の復号化ピクチャを含んでもよい。DPB管理および関連する態様の場合、復号化されたピクチャ単位でDPBのサイズおよびフルネスを計数することは、もはや機能しない。
【0217】
以下は、ARCがサポートされている場合、最終的なVVC規格における取り組むべきいくつかの特定の態様および可能な解決策の議論である(当方は、この会議において可能な解決策を採用することを提案していない)。
1.MaxDpbSize(すなわち、DPB内に存在してよい参照ピクチャの最大数)の導出のためにPicSizeInSamplesY(すなわち、PicSizeInSamplesY=pic_width_in_luma_samples*pic_height_in_luma_samples)の値を使用するのではなく、MinPicSizeInSamplesYの値に基づいて、MaxDpbSizeの導出を行う。MinPicSizeInSampleYは、以下のように定義される。
MinPicSizeInSampleY=(ビットストリームにおける最小のピクチャ解像度の幅)*(ビットストリームにおける最小の解像度の高さ)。
MaxDpbSizeの導出は、(HEVC式に基づいて)以下のように修正される。
if(MinPicSizeInSamplesY<=(MaxLumaPs>>2))
MaxDpbSize=Min(4*maxDpbPicBuf,16)
else if(MinPicSizeInSamplesY<=(MaxLumaPs>>1))
MaxDpbSize=Min(2*maxDpbPicBuf,16)
else if(MinPicSizeInSamplesY<=((3*MaxLumaPs)>>2))
MaxDpbSize=Min((4*maxDpbPicBuf)/3,16)
else
MaxDpbSize=maxDpbPicBuf
【0218】
2.各復号化されたピクチャは、PictureSizeUnitと呼ばれる値に関連付けられる。PictureSizeUnitは、復号化されたピクチャサイズがMinPicSizeInSampleYに対してどれぐらい大きいかを規定する整数値である。PictureSizeUnitの定義は、VVCにおけるARCのためにどのような再サンプリング比がサポートされるかに依存する。
例えば、ARCが2の再サンプリング比のみをサポートする場合、PictureSizeUnitは、次のように定義される。
-ビットストリームにおける最小の解像度を有する復号化されたピクチャは、1のPictureSizeUnitに関連付けられる。
-ビットストリームにおける最小の解像度の2×2の解像度を有する復号化されたピクチャは、4のPictureSizeUnit(即ち、1*4)に関連付けられる。
別の例の場合、ARCが1.5および2の両方の再サンプリング比をサポートする場合、PictureSizeUnitは、以下のように定義される。
-ビットストリームにおける最小の解像度を有する復号化されたピクチャは、4のPictureSizeUnitに関連付けられる。
-ビットストリームにおける最小の解像度の1.5×1.5の解像度を有する復号化されたピクチャは、9(すなわち、2.25*4)のPictureSizeUnitに関連付けられる。
-ビットストリームにおける最小の解像度の2×2の解像度を有する復号化されたピクチャは、16(即ち、4*4)のPictureSizeUnitに関連付けられる。
ARCがサポートする他の再サンプリングレートの場合、各ピクチャサイズに対するPictureSizeUnitの値を判定するために、上記の例に示されるのと同じ原理を使用すべきである。
【0219】
3.変数MinPictureSizeUnitをPictureSizeUnitの最小可能値とする。すなわち、ARCが2の再サンプリング比のみをサポートする場合、MinPictureSizeUnitは1であり、ARCが1.5および2の再サンプリング比をサポートする場合、MinPictureSizeUnitは4であり、同様に、同じ原理を使用してMinPictureSizeUnitの値を判定する。
【0220】
4.sps_max_dec_pic_buffering_minus1[i]の値の範囲は、0~(MinPictureSizeUnit*(MaxDpbSize-1))の範囲で規定される。変数MinPictureSizeUnitは、PictureSizeUnitの最小可能値である。
【0221】
5.DPBフルネス動作は、PictureSizeUnitに基づいて、以下のようで規定される。
-HRDは復号化ユニット0で初期化され、CPBおよびDPBの両方が空に設定される(DPBフルネスが0に等しく設定される)。
-DPBがフラッシュされる(即ち、すべてのピクチャがDPBから除去される)場合、DPBフルネスは0に等しく設定される。
-ピクチャがDPBから除去されるとき、DPBフルネスは、除去されたピクチャに関連付けられたPictureSizeUnitの値だけデクリメントされる。
-ピクチャがDPBに挿入されるとき、DPBフルネスは、挿入されたピクチャに関連付けられたPictureSizeUnitの値だけインクリメントされる。
【0222】
1.2.5.4. 再サンプリングフィルタ
【0223】
ソフトウェアの実装において、実装された再サンプリングフィルタは、単純に、JCTVC-H0234に記載されている以前に利用可能なフィルタから得られた。より優れた性能および/またはより低い複雑性を提供する場合、他の再サンプリングフィルタが試験され、使用されるべきである。当方は、複雑性と性能との間のトレードオフを取り決めるために、様々な再サンプリングフィルタを試験することを提案する。このような試験は、CEにおいて行うことができる。
【0224】
1.2.5.5. 既存のツールへのその他の必要な修正
【0225】
ARCをサポートするために、既存のコーディングツールの一部に何らかの修正および/または追加の動作が必要とされる場合がある。例えば、ARCソフトウェア実装のピクチャベースの再サンプリングにおいて、説明を簡単にするために、現在のピクチャと参照ピクチャの元のコーディング解像度が異なる場合、TMVPおよびATMVPを無効化した。
【0226】
1.2.6. JVET-N0279
【0227】
「将来の映像コーディング規格のための要件」によれば、この規格は、それぞれが異なる特性(例えば、空間的解像度またはサンプルビット深さ)を有する、同じコンテンツの複数の表現を提供する適応ストリーミングサービスの場合、高速表現切り替えをサポートするものとする。リアルタイムの映像通信において、Iピクチャを挿入せずにコーディングされた映像シーケンスにおける解像度の変更を許可することは、映像データを動的なチャネル条件またはユーザの好みにシームレスに適応させるだけでなく、Iピクチャに起因するビートの影響を除去することができる。適応解像度の変更の仮説例が、異なったサイズの参照ピクチャから現在のピクチャを予測する図14にて示される。
【0228】
この寄与は、適応解像度の変更を信号通知するための高レベルな構文と、VTMにおける現在の動き補償予測処理の修正を提案する。これらの修正は、既存の動き補償補間器を変更せずに、動きベクトルのスケーリングおよびサブ画素の位置の導出に限定される。これにより、既存の動き補償補間器を再利用することができ、追加のコストを招くような適応解像度の変更をサポートするための新しい処理ブロックを必要としない。
【0229】
1.2.6.1. 適応解像度の変更の信号通知
1.2.6.1.1. SPS
【0230】
【表12】
【0231】
[[pic_width_in_luma_samplesは、輝度サンプル単位で各復号化されたピクチャの幅を規定する。pic_width_in_luma_samplesは、0に等しくなく、かつ、MinCbSizeYの整数倍とする。]]
[[pic_height_in_luma_samplesは、輝度サンプル単位で各復号化されたピクチャの高さを規定する。pic_height_in_luma_samplesは、0に等しくなく、かつ、MinCbSizeYの整数倍とする]]
max_pic_width_in_luma_samplesは、輝度サンプル単位でSPSを参照する復号化されたピクチャの最大幅を規定する。max_pic_width_in_luma_samplesは、0に等しくなく、かつ、MinCbSizeYの整数倍とする。
max_pic_height_in_luma_samplesは、輝度サンプル単位でSPSを参照する復号化されたピクチャの最大幅を規定する。max_pic_width_in_luma_samplesは、0に等しくなく、かつ、MinCbSizeYの整数倍とする。
【0232】
1.2.6.1.2. PPS
【0233】
【表13】
【0234】
1に等しいpic_size_different_from_max_flagは、PPSは、参照されたSPSのmax_pic_width_in_luma_samplesおよびmax_pic_height_in_luma_sampleとは異なるピクチャ幅またはピクチャ高さ信号通知することを規定する。0に等しいpic_size_different_from_max_flagは、pic_width_in_luma_samplesおよびpic_height_in_luma_sampleが、参照されたSPSのmax_pic_width_in_luma_samplesおよびmax_pic_height_in_luma_sampleと同じであることを規定する。
pic_width_in_luma_samplesは、輝度サンプル単位で各復号化されたピクチャの幅を規定する。pic_width_in_luma_samplesは、0に等しくなく、かつ、MinCbSizeYの整数倍とする。pic_width_in_luma_samplesが存在しない場合、max_pic_width_in_luma_samplesに等しいと推測される。
pic_height_in_luma_samplesは、輝度サンプル単位で各復号化されたピクチャの高さを規定する。pic_height_in_luma_samplesは、0に等しくなく、かつ、MinCbSizeYの整数倍とする。pic_height_in_luma_samplesが存在しない場合、max_pic_height_in_luma_samplesに等しいと推測される。
【0235】
すべてのアクティブな参照ピクチャに対して、水平および垂直のスケーリング比が1/8~2の範囲内にあるべきであることがビットストリーム適合性の要件である。スケーリング比は、以下のように定義される。
-horizontal_scaling_ratio=((reference_pic_width_in_luma_samples<<14)+(pic_width_in_luma_samples/2))/pic_width_in_luma_samples
-vertical_scaling_ratio=((reference_pic_height_in_luma_samples<<14)+(pic_height_in_luma_samples/2))/pic_height_in_luma_samples
【0236】
【表14】
【0237】
参照ピクチャのスケーリング処理
【0238】
CVS内で解像度の変更がある場合、ピクチャは、その参照ピクチャの1または複数とは異なるサイズを有していてよい。この提案は、すべての動きベクトルを、それらが対応する参照ピクチャグリッドの代わりに、現在のピクチャグリッドに正規化する。これは、設計の一貫性を保ち、解像度の変更を動きベクトル予測処理に対してトランスペアレントにするために有益であると主張している。そうでない場合、スケールが異なるため、異なるサイズを有する参照ピクチャを指す近傍の動きベクトルを空間的動きベクトル予測に直接使用できない。
【0239】
解像度の変更が生じた場合、動き補償予測を行いながら、動きベクトルおよび参照ブロックの両方をスケーリングしなければならない。スケーリング範囲は[1/8,2]に限定され、即ち、アップスケーリングは1:8に限定され、ダウンスケーリングは2:1に限定される。なお、アップスケーリングは、参照ピクチャが現在のピクチャより小さい場合を指し、ダウンスケーリングは、参照ピクチャが現在のピクチャより大きい場合を指す。以下の章では、スケーリング処理をより詳細に説明する。
【0240】
輝度ブロック
【0241】
スケーリング係数およびその固定小数点表現は、以下のように定義される。
【0242】
【数1】
【0243】
【数2】
【0244】
このスケーリング処理は、2つの部分を含む。
1.現在のブロックの左上隅の画素を参照ピクチャにマッピングする。
2.水平および垂直ステップサイズを使用して、現在のブロックの他の画素の参照位置をアドレス指定する。
【0245】
現在のブロックの左上隅の画素の座標が(x,y)である場合、動きベクトル(mvX,mvY)が指す参照ピクチャにおけるサブ画素の位置(x’,y’)を、1/16画素
単位で以下のように規定する。
●参照ピクチャにおける水平位置は、
x’=((X<<4)+mvX)・hori_scale_fp (3)
であり、x’は10の小数ビットのみを維持するようにさらにスケールダウンされる。
x’=Sign(x’)・((Abs(x’)+(1<<7))>>8 (4)
●同様に、参照ピクチャにおける垂直方向の位置は、
y’=((y<<4)+mvY)・vert_scale_fp (5)
であり、y’はさらに次のようにスケールダウンされる。
y’=Sign(y’)・((Abs(y’)+(1<<7))>>8) (6)
【0246】
この時点で、現在のブロックの左上隅の画素の参照位置は、(w’,y’)にある。他の参照サブ画素/画素位置は、水平および垂直のステップサイズを有する(x’,y’)に関連して計算される。これらのステップサイズは、上記の水平および垂直スケーリング係数から、1/1024画素の精度で、以下のように導出される。
x_step=(hori_scale_fp+8)>>4 (7)
y_step=(vert_scale_fp+8)>>4 (8)
【0247】
一例として、現在のブロックにおける画素が左上隅の画素からi列j行離れている場合、その対応する参照画素の水平座標および垂直座標は、以下によって導出される。
x’=x’+i*x_step (9)
y’=y’+j*y_step (10)
【0248】
サブペル補間において、xi’およびyj’は、フル画素部分と小数画素部分とに分割されなければならない。
●参照ブロックをアドレス指定するためのフル画素部分は以下に等しい。
(x’+32)>>10 (11)
(y’+32)>>10 (12)
●補間フィルタを選択するために使用される小数画素部分は以下に等しい。
Δx=((x’+32)>>6)&15 (13)
Δy=((y’+32)>>6)&15 (14)
【0249】
参照ピクチャ内のフル画素位置および小数画素位置が判定されると、既存の動き補償補間器を追加の変更なしに使用できる。フル画素位置は、参照ピクチャから参照ブロックパッチをフェッチするために使用され、小数画素位置は、適切な補間フィルタを選択するために使用される。
【0250】
彩度ブロック
【0251】
彩度フォーマットが4:2:0である場合、彩度動きベクトルは、1/32画素の精度を有する。彩度動きベクトルおよび彩度参照ブロックのスケーリング処理は、彩度フォーマットに関連した調整を除いて、輝度ブロックとほぼ同じである。
【0252】
現在の彩度ブロックの左上隅の画素の座標が(xc,yc)である場合、参照彩度ピクチャにおける最初の水平および垂直位置は、以下に等しい。
’=((xc<<5)+mvX)・hori_scale_fp (1)
’=((yc<<5)+mvY)・vert_scale_fp (2)
【0253】
mvXおよびmvYは元の輝度動きベクトルであるが、ここでは1/32画素の精度で検査されるべきである。
【0254】
’、y’はさらにスケールダウンされ、1/1024画素の精度を維持する。
’=Sign(x’)・((Abs(x’)+(1<<8))>>9
(3)
’=Sign(y’)・((Abs(y’)+(1<<8))>>9
(4)
【0255】
関連する輝度の方程式と比較して、上記の右シフトは、1つの余分なビットだけ増加される。
【0256】
使用されるステップサイズは、輝度の場合と同じである。左上隅の画素に関する(i,j)における彩度画素の場合、その参照画素の水平座標および垂直座標は、以下のように導出される。
=x’+i*x_step (5)
=y’+j*y_step (6)
サブ画素補間において、xc’iおよびyc’jは、また、フル画素部分および小数画素部分に分けられる。
●参照ブロックをアドレス指定するためのフル画素部分は以下に等しい。
(x+16)>>10 (7)
(y+16)>>10 (8)
●補間フィルタを選択するために使用される小数画素部分は、以下に等しい。
Δx=((x+16)>>5)&31 (9)
Δy=((y+16)>>5)&31 (10)
【0257】
他のコーディングツールとの相互作用
【0258】
参照ピクチャのスケーリングを有する一部のコーディングツールとの相互作用に関連付けられた過度な複雑性とメモリ帯域幅のため、VVC仕様に以下の制限を加えることが推奨される。
-tile_group_temporal_mvp_enabled_flagが1に等しい場合、現在のピクチャとその並置されたピクチャは同じサイズを有するものとする。
-解像度の変更がシーケンス内で許可されている場合、デコーダ動きベクトルの改善は停止されるものとする。
-解像度の変更がシーケンス内で許可されている場合、sps_bdof_enabled_flagは0に等しいものとする。
【0259】
1.3. JVET-N0415におけるCTB(Coding Tree Block)ベースのALF(Adaptive Loop Filter)
【0260】
スライスレベル時間的フィルタ
【0261】
VTM4にはAPS(Adaptive Parameter Set)が採用された。各APSは、1つのセットの信号通知されたALFフィルタを含み、最大32個のAPSがサポートされる。本提案では、スライスレベルの時間的フィルタがテストされる。タイルグループは、APSからのALF情報を再利用することにより、オーバーヘッドを低減することができる。APSは、FIFO(First-In-First-Out)バッファとして更新される。
【0262】
CTBベースのALF
【0263】
輝度成分に対し、ALFが輝度CTBに適用される際に、16個の固定された、5個の時間的な、または1つの信号通知されたフィルタセットの中からの選択が示される。フィルタセットインデックスのみが信号通知される。1つのスライスに対して、25個のフィルタからなる1つの新しいセットのみを信号通知することができる。1つのスライスに対して新しいセットが信号通知された場合、同じスライス内のすべての輝度CTBはそのセットを共有する。固定フィルタセットを使用して新しいスライスレベルフィルタセットを予測することができ、これを輝度CTBに対する候補フィルタセットとして使用できる。
フィルタの数は合計64個である。
【0264】
彩度成分に対し、ALFが彩度CTBに適用される際に、スライスに対して新しいフィルタが信号通知する場合、CTBは新しいフィルタを使用し、そうでない場合、時間スケーラビリティ制約を満たす最も新しい時間的彩度フィルタが適用される。
【0265】
スライスレベルの時間的フィルタとして、APSは、FIFO(First-In-First-Out)バッファとして更新される。
【0266】
1.4. 代替時間的動きベクトル予測(別名、VVCにおけるサブブロックベースの時間マージ候補)
【0267】
ATMVP(Alternative Temporal Motion Vector Prediction)において、TMVP(Temporal Motion Vector Prediction)は、現在のCUより小さいブロックから複数セットの動き情報(動きベクトルおよび参照インデックスを含む)をフェッチすることで修正される。図15に示すように、サブCUは、正方形のN×Nブロックである(デフォルトでは、Nは8に設定される)。
【0268】
ATMVPは、CU内のサブCUの動きベクトルを2つのステップで予測する。第1のステップは、参照ピクチャにおける対応するブロックを、いわゆる時間的ベクトルで特定することである。参照ピクチャは、動きソースピクチャと呼ばれる。第2のステップは、図15に示すように、現在のCUをサブCUに分割し、各サブCUに対応するブロックから各サブCUの動きベクトルならびに参照インデックスを取得する。
【0269】
第1のステップにおいて、現在のCUの空間的に近傍のブロックの動き情報によって、参照ピクチャおよび対応するブロックが判定される。近傍のブロックの繰り返しスキャン処理を回避するために、現在のCUのマージ候補リストにおけるブロックA0(左ブロック)からのマージ候補が使用される。並置された参照ピクチャを参照するブロックA0から第1の利用可能な動きベクトルが、時間的ベクトルとなるように設定される。このように、ATMVPでは、TMVPに比べて、対応するブロックをより正確に特定することができ、対応するブロック(配列されたブロックと呼ばれることがある)は、常に現在のCUに対して右下または中心位置にある。
【0270】
第2のステップにおいて、現在のCUの座標に時間ベクトルを加えることにより、サブCUの対応するブロックが、動きソースピクチャにおける時間的ベクトルにより特定される。各サブCUに対し、その対応するブロックの動き情報(例えば、中心サンプルを覆う最小の動きグリッド)が使用され、サブCUの動き情報を導出する。対応するN×Nブロックの動き情報が特定された後、HEVCのTMVPと同様に、現在のサブCUの動きベクトルおよび参照インデックスに変換され、動きスケーリングや他の手順が適用される。
【0271】
1.5. アフィン動き予測
【0272】
HEVCにおいて、並進運動モデルのみが、MCP(Motion Compensation Prediction)のために適用される。一方、現実世界において、動きには様々な種類があり、例えば、ズームイン/ズームアウト、回転、透視運動、および他の不規則な動きがある。VVCにおいて、4パラメータアフィンモデルおよび6パラメータアフィンモデルを使用して、簡易アフィン変換動き補償予測が適用される。図16に示すように、ブロックのアフィン動きフィールドは、4パラメータアフィンモデルの場合、2つのCPMV(Control Point Motion Vector)によって表され、6パラメータアフィンモデルの場合、3つのCPMVによって表される。
【0273】
ブロックのMVF(Motion Vector Field)は、式(1)における4パラメータアフィンモデル(4パラメータを変数a、b、e、fとして定義される)および式(2)における6パラメータアフィンモデル(4パラメータを変数a、b、c、d、e、fとして定義される)をそれぞれ使用して、以下の式で表される。
【0274】
【数3】
【0275】
【数4】
【0276】
ここで、(mv ,mv )は、左上隅の制御点の動きベクトルであり、(mv ,mv )は、右上隅の制御点の動きベクトルであり、(mv ,mv )は、左下隅の制御点の動きベクトルであり、3つの動きベクトルはすべて、CPMV(Control Point Motion Vector)と呼ばれ、(x,y)は、現在のブロック内の左上サンプルに対する代表点の座標を表し、(mv(x,y),mv(x,y))は、(x,y)に位置するサンプルに対して導出された動きベクトルである。CP動きベクトルは、(アフィンAMVPモードのように)信号通知されてもよいし、または、(アフィンマージモードのように)オンザフライで導出されてもよい。wおよびhは、現在のブロックの幅および高さである。実際のところは、この分割は、丸め動作を有する右シフトによって実装される。VTMにおいて、代表点がサブブロックの中心位置として定義され、例えば、現在のブロックにおける左上のサンプルに対するサブブロックの左上の角の座標が(xs,ys)である場合、代表点の座標は(xs+2,ys+2)として定義される。各サブブロック(すなわち、VTMにおいて4×4)に対して、代表点を利用して、サブブロック全体の動きベクトルが導出される。
【0277】
動き補償予測をさらに簡単にするために、サブブロックベースのアフィン変換予測が適用される。各M×N(現在のVVCでは、MおよびNの両方が4に設定される)個のサブブロックの動きベクトルを導出するために、各サブブロックの中心サンプルの動きベクトルが、図17に示すように、式(1)および(2)に従って算出され、1/16の小数精度に丸める。そして、1/16画素の動き補償補間フィルタが適用され、導出された動きベクトルを使用して各サブブロックの予測が生成される。1/16画素の補間フィルタは、アフィンモードで導入される。
【0278】
MCP後、各サブブロックの高精度動きベクトルが丸められ、通常の動きベクトルと同じ精度で保存される。
【0279】
1.5.1. アフィン予測の信号通知
【0280】
並進動きモデルと同様に、アフィン予測によるサイド情報の信号通知のために2つのモードがある。それらは、AFFINE_INTERおよびAFFINE_MERGEモードである。
【0281】
1.5.2. AF_INTERモード
【0282】
幅と高さの両方が8より大きいCUの場合、AF_INTERモードを適用することができる。AF_INTERモードが使用されているかどうかを示すために、ビットストリームにおいてCUレベルのアフィンフラグが信号通知される。
【0283】
本モードにおいて、各参照ピクチャリスト(List0またはList1)に対して、アフィンAMVP候補リストが、以下の順に、3つのタイプのアフィン動き予測子を用いて構築され、各候補は、現在のブロックの推定されたCPMVを含む。エンコーダ側で見出された最良のCPMV(例えば、図18におけるmv、mv、mv)と推定されたCPMVとの差が信号通知される。さらに、推定されたCPMVが導出されたアフィンAMVP候補のインデックスが信号通知される。
【0284】
(1) 継承アフィン動き予測子
【0285】
チェック順序は、HEVC AMVPリスト構築における空間的MVPのチェック順序に類似している。まず、アフィンコーディングされ、かつ、現在のブロックと同じ参照ピクチャを有する{A1,A0}における第1のブロックから、左側の継承アフィン動き予測子が導出される。第2に、上記継承アフィン動き予測子は、アフィンコーディングされ、かつ、現在のブロックと同じ参照ピクチャを有する{B1,B0,B2}における第1のブロックから導出される。図19には、5つのブロックA1、A0、B1、B0、B2が示されている。
【0286】
近傍のブロックがアフィンモードでコーディングされていることがわかったら、近傍のブロックをカバーするコーディングユニットのCPMVを使用して、現在のブロックのCPMVの予測子が導出される。例えば、A1が非アフィンモードでコーディングされ、A0が4パラメータアフィンモードでコーディングされる場合、左側の継承アフィンMV予測子は、A0から導出される。この場合、図21Bの左上のCPMVをMV で表し、右上のCPMVをMV で表した、A0をカバーしているCUのCPMVを利用して、現在のブロックの左上(座標(x0,y0))、右上(座標(x1,y1))、右下(座標(x2,y2))の位置をMV 、MV 、MV で表した、現在のブロックの推定CPMVを導出する。
【0287】
(2) 構築されたアフィン動き予測子
【0288】
構築されたアフィン動き予測子は、図20に示すように、近傍のインター符号化されたブロックから導出された、同じ参照ピクチャを有するCPMV(Control-Point Motion Vector)からなる。現在のアフィン動きモデルが4パラメータアフィンである場合、CPMVの数は2であり、そうでない場合、現在のアフィン動きモデルが6パラメータアフィンである場合、CPMVの数は3である。左上のCPMV mv ̄は、インター符号化され、かつ、現在のブロックと同じ参照ピクチャを有するグループ{A,B,C}における第1のブロックのMVによって導出される。右上のCPMV mv ̄は、インター符号化され、かつ、現在のブロックと同じ参照ピクチャを有するグループ{D,E}における第1のブロックのMVによって導出される。左下のCPMV mv ̄は、インター符号化され、かつ、現在のブロックと同じ参照ピクチャを有するグループ{F,G}における第1のブロックのMVによって導出される。
-現在のアフィン動きモデルが4パラメータアフィンである場合、mv ̄とmv ̄の両方が成立する場合にのみ、構築されたアフィン動き予測子が候補リストに挿入され、すなわち、mv ̄とmv ̄は、現在のブロックの左上(座標(x0,y0))、右上(座標(x1,y1))の位置に対する推定CPMVとして使用される。
-現在のアフィン動きモデルが6パラメータアフィンである場合、mv ̄、mv ̄、およびmv ̄がすべて成立している場合にのみ、構築されたアフィン動き予測子が候補リストに挿入され、すなわち、mv ̄、mv ̄、およびmv ̄は、現在のブロックの左上(座標(x0,y0))、右上(座標(x1,y1))、および右下(座標(x2,y2))の位置に対する推定CPMVとして使用される。構築されたアフィン動き予測子を候補リストに挿入する場合、プルーニング処理は適用されない。
【0289】
1)通常のAMVP動き予測子
【0290】
アフィン動き予測子の数が最大に達するまで、以下が適用される。
1)利用可能であれば、すべてのCPMVをmv ̄に等しく設定することにより、アフィン動き予測子を導出する。
2)利用可能であれば、すべてのCPMVをmv ̄に等しく設定することにより、アフィン動き予測子を導出する。
3)利用可能であれば、すべてのCPMVをmv ̄に等しく設定することにより、アフィン動き予測子を導出する。
4)利用可能であれば、すべてのCPMVをHEVC TMVPに等しく設定することにより、アフィン動き予測子を導出する。
5)すべてのCPMVをゼロMVに設定することにより、アフィン動き予測子を導出する。
【0291】
なお、mv ̄は、構築されたアフィン動き予測子において導出されたものである。
【0292】
AF_INTERモードにおいて、4/6パラメータアフィンモードが使用される場合、2/3の制御点が必要であり、従って、図18Aおよび図18Bに示すように、これらの制御点のために2/3のMVDがコーディングされることが必要である。JVET-K0337において、MVを以下のように導出することが提案されており、すなわち、mvdからmvdおよびmvdが予測される。
【0293】
【数5】
【0294】
mv ̄、mvd、およびmvは、図18Bに示すように、それぞれ、左上の画素(i=0)、右上の画素(i=1)、または左下の画素(i=2)の予測された動きベクトル、動きベクトルの差分、動きベクトルである。なお、2つの動きベクトル(例えば、mvA(xA,yA)およびmvB(xB,yB))の和は、2つの成分を別個に合計したものに等しく、即ち、newMV=mvA+mvBであり、newMVの2つの成分は、それぞれ、(xA+xB)および(yA+yB)に設定される。
【0295】
1.5.2.1. AF_MERGEモード
【0296】
AF_MERGEモードにおいてCUを適用する場合、CUは、有効な近傍の再構成ブロックから、アフィンモードでコーディングされた第1のブロックを得る。そして、候補ブロックの選択順序は、図21Aに示すように、左、上、右上、左下、左上になる(順にA、B、C、D、Eと表記する)。例えば、図21BにおいてA0で示されるように、近傍の左下のブロックがアフィンモードでコーディングされる場合、ブロックAを含む近傍のCU/PUの左上隅、右上隅、および左下隅のCP(Control Point)動きベクトルmv 、mv 、およびmv がフェッチされる。そして、現在のCU/PUにおける左上隅/右上/左下の動きベクトルmv 、mv 、mv (6パラメータアフィンモデルにのみ使用される)が、mv 、mv 、およびmv に基づいて算出される。なお、VTM-2.0において、左上隅に位置するサブブロック(例えば、VTMにおける4×4ブロック)は、mv0を記憶し、右上隅に位置するサブブロックは、現在のブロックがアフィンコーディングされている場合、mv1を記憶する。現在のブロックが6パラメータアフィンモデルでコーディングされている場合、左下隅に位置するサブブロックはmv2を記憶し、そうでない場合(4パラメータアフィンモデルでコーディング)、LBはmv2’を記憶する。他のサブブロックは、MCに使用されるMVを記憶する。
【0297】
現在のCU mv 、mv 、およびmv のCPMVが導出された後、簡易アフィン動きモデルの式(1)、(2)に従って、現在のCUのMVFが生成される。現在のCUがAF_MERGEモードでコーディングされているかどうかを識別するために、アフィンモードでコーディングされた近傍のブロックが少なくとも1つある場合、ビットストリーム内にてアフィンフラグが信号通知される。
【0298】
JVET-L0142およびJVET-L0632において、アフィンマージ候補リストは、以下のステップを使用して構築される。
1)継承されたアフィン候補を挿入する
継承されたアフィン候補は、その有効な近傍のアフィンコーディングされたブロックのアフィン動きモデルから候補が導出されることを意味する。最大2つの継承されたアフィン候補が、近傍のブロックのアフィン動きモデルから導出され、候補リストに挿入される。左の予測子の場合、スキャン順序は{A0,A1}であり、上の予測子の場合、スキャン順序は{B0,B1,B2}である。
2)構築されたアフィン候補を挿入する
アフィンマージ候補リストにおける候補の数がMaxNumAffineCand(例えば、5)未満である場合、構築されたアフィン候補が候補リストに挿入される。構築されたアフィン候補は、各制御点の近傍動き情報を組み合わせることで候補が構築されることを意味する。
a)まず、制御点に対する動き情報が、図22に示される指定された空間的近傍と時間近傍から導出される。CPk(k=1,2,3,4)は、k番目の制御点を表す。A0、A1、A2、B0、B1、B2、およびB3は、CPk(k=1,2,3)を予測するための空間的位置であり、Tは、予測CP4の時間的位置である。
CP1、CP2、CP3、およびCP4の座標は、それぞれ、(0,0)、(W,0)、(H,0)、および(W,H)であり、WおよびHは、現在のブロックの幅および高さである。
各制御点の動き情報は、以下の優先順位に従って取得される。
-CP1の場合、チェックの優先順位はB2->B3->A2である。利用可能であれば、B2が使用される。一方、B2が利用可能であれば、B3が使用される。B2とB3の両方が利用不可能な場合、A2が使用される。3つの候補のすべてが利用不可能な場合、CP1の動き情報を取得することができない。
-CP2の場合、チェックの優先順位はB1->B0である。
-CP3の場合、チェックの優先順位はA1->A0である。
-CP4の場合、Tが使用される。
b)次に、制御点の組み合わせを使用して、アフィンマージ候補を構築する。
I.6パラメータアフィン候補を構築するためには、3つの制御点の動き情報が必要である。3つの制御点は、以下の4つの組み合わせ({CP1,CP2,CP4}、{CP1,CP2,CP3}、{CP2,CP3,CP4}、{CP1,CP3,CP4})の1つから選択できる。組み合わせ{CP1,CP2,CP3}、{CP2,CP3,CP4}、{CP2,CP3,CP4}、{CP1,CP3,CP4}は、左上、右上、および左下の制御点で表現される6パラメータ動きモデルに変換される。
II.4パラメータアフィン候補を構築するためには、2つの制御点の動き情報が必要である。2つの制御点は、2つの組み合わせ({CP1,CP2}、{CP1,CP3})のうちの1つから選択できる。2つの組み合わせは、左上および右上の制御点で表現される4パラメータ動きモデルに変換される。
III.構築されたアフィン候補の組み合わせは、以下の順にて候補リストに挿入される。
{CP1,CP2,CP3}、{CP1,CP2,CP4}、{CP1,CP3,CP4}、{CP2,CP3,CP4}、{CP1,CP2}、{CP1,CP3}
i.各組み合わせについて、各CPに対するリストXの参照インデックスがチェックされ、それらがすべて同じである場合、この組み合わせはリストXに対して有効なCPMVを有する。組み合わせがリスト0およびリスト1の両方に対して有効なCPMVを有していない場合、この組み合わせは無効としてマークされる。そうでない場合、それは有効であり、CPMVはサブブロックマージリストに入れられる。
3)動きベクトルがゼロの場合のパディング
アフィンマージ候補リストにおける候補の数が5未満である場合、リストが一杯になるまで、ゼロ参照インデックスを有するゼロ動きベクトルが候補リストに挿入される。
具体的には、サブブロックマージ候補リストについて、MVを有する4パラメータマージ候補が(0,0)に設定され、予測方向がリスト0からの単一予測(Pスライスの場合)、および、双方向予測(Bスライスの場合)に設定される。
【0299】
2. 既存の実装形態の欠点
VVCに適用される場合、ARCには以下の問題がある。
1.ARCに関する情報をどのように信号通知するかは、まだ不明である。
2.参照ピクチャ、並置されたピクチャ、および現在のピクチャが同じ解像度を有していない場合、アフィン/TMVPまたはATMVPをどのように適用するかは、依然として不明である。
3.ARCのためのダウンサンプリングまたはアップサンプリングフィルタの設計は、より優れた設計とすることができる。
【0300】
3. 適応解像度変換方法の例
以下の詳細な発明は、一般的な概念を説明するための例であると考えられるべきである。これらの発明は狭い意味で解釈されるべきではない。さらに、これらの発明は、任意の方法で組み合わせることができる。
以下の説明において、SatShift(x,n)は、以下のように定義される。
【0301】
【数6】
【0302】
Shift(x,n)は、Shift(x,n)=(x+offset0)>>nとして定義される。
一例において、offset0および/またはoffset1は、(1<<n)>>1または(1<<(n-1))に設定される。別の例において、offset0および/またはoffset1は、0に設定される。
別の例において、offset0=offset1=((1<<n)>>1)-1または((1<<(n-1)))-1である。
Clip3(min,max,x)は、以下のように定義される。
【0303】
【数7】
【0304】
floor(x)は、x以下の最大整数として定義される。
Ceil(x)は、x以上の最小の整数。
Log2(x)は、xの底を2とする対数として定義される。
【0305】
ARCのための信号通知
1.ARCに関するピクチャ寸法情報(幅および/または高さ)は、DPS、VPS、SPS、PPS、APS、ピクチャヘッダ、スライスヘッダ、タイルグループヘッダ以外の映像ユニットにて信号通知されてもよいと提案する。
a.一例において、ARCに関するピクチャ寸法情報は、SEI(Supplemental Enhancement Information)メッセージにて信号通知されてよい。
b.一例において、ARCに関するピクチャ寸法情報は、ARCのための個々の映像ユニットにおいて信号通知されてよい。例えば、映像ユニットは、RPS(Resolution Parameter Set)、CPS(Conversion Paramter Set)、または他の名称として命名されてよい。
i.一例において、RPSまたはCPSと命名されたような、ARCのための個々の映像ユニットにおいて、幅および高さの2つ以上の組み合わせが信号通知されてよい。
【0306】
2.なお、ピクチャの寸法(幅または高さ)は、0次の指数ゴロム符号ではないように信号通知されてよいと提案する。
a.一例において、固定長符号またはユーナリー符号でコーディングされてよい。
b.一例において、K次(K>0)の指数ゴロム符号でコーディングされてもよい。
c.寸法は、DPS、VPS、SPS、PPS、APS、ピクチャヘッダ、スライスヘッダ、タイルグループヘッダなどの映像ユニットにおいて、または、RPSもしくはCPSと命名されたARCのための個々の映像ユニットにおいて信号通知されてよい。
【0307】
3.複数の解像度を信号通知する代わりに、解像度比を信号通知することを提案する。
a.一例において、1つの基本解像度の指示を信号通知してもよい。また、許容される比率の組み合わせ(例えば、水平比率、垂直比率)の指示をさらに信号通知してもよい。
b.一例において、1つのピクチャの実際の解像度を示すために、許容される比の組み合わせの指示のインデックスがPPSにて信号通知されてよい。
【0308】
4.単一の映像ユニット、例えばDPS、VPS、SPS、PPS、APS、ピクチャヘッダ、スライスヘッダ、タイルグループヘッダなどにおいて、または、RPSもしくはCPSと命名されたようなARCのための個々の映像ユニットにおいて、ピクチャの幅と高さの2つ以上の組み合わせが信号通知される場合、第1の組み合わせにおける幅と高さが共に第2の組み合わせにおける幅と高さであることが許可されないようにすることを提案する。
【0309】
5.信号通知される寸法(幅Wおよび高さH)は制約内になければならないことを提案する。
a.例えば、Wは、TW_min<=W<=TW_maxを満たすべきである。
b.例えば、Hは、TH_min<=H<=TH_maxを満たすべきである。
c.一例において、W-TW_min-Bが信号通知されてもよく、Bは、0などの固定値である。
d.一例において、H-TH_min-Bが信号通知されてもよく、Bは、0などの固定値である。
e.一例において、TW_max-W-Bが信号通知されてもよく、Bは、0などの固定値である。
f.一例において、TH_max-H-Bが信号通知されてもよく、Bは、0などの固定値である。
g.一例において、TW_minおよび/またはTH_minが信号通知されてもよい。
h.一例において、TW_maxおよび/またはTH_maxが信号通知されてもよい。
【0310】
6.信号通知される寸法(幅Wおよび高さH)は、W=w*X、およびH=h*Yの形式でなければならず、XおよびYは、例えば、X=Y=4などの、予め定義された整数であることを提案する。
a.一例において、wおよびhが信号通知される。WおよびHは、wおよびhから導出される。
【0311】
7.ピクチャ寸法情報(幅および/または高さ)は、予測方式でコーディングされてもよいことを提案する。
a.一例において、第1の幅(W1)と第2の幅(W2)との差、すなわち、W2-W1、が信号通知されてよい。
i.代替的に、W2-W1-Bが信号通知されてもよく、Bは、1などの固定値である。
ii.一例において、W2はW1よりも大きくなるべきである。
iii.一例において、差は、ユーナリー符号、またはトランケイテッドユーナリー符号、または固定長符号、または固定長符号でコーディングされてもよい。
b.一例において、第1の高さ(H1)と第2の高さ(H2)との差、すなわち、H2-H1が信号通知されてもよい。
i.代替的に、H2-H1-Bが信号通知されてもよく、Bは、1などの固定値である。
ii.一例において、H2はH1よりも大きくなければならない。
iii.一例において、差は、ユーナリー符号、またはトランケイテッドユーナリー符号、または固定長符号、または固定長コーディングされてもよい。
c.一例において、第1の幅(W1)と第2の幅(W2)との間の比、すなわち、W2/W1が信号通知されてもよい。例えば、W2=F*W1である場合、Fが信号通知される。別の例において、W2=Shift(F*W1,P)である場合、Fが信号通知され、Pは、精度を表す数であり、例えば、P=10である。
i.代替的に、Fは、(W2*P+W1/2)/W1に等しくてよく、Pは、精度を表す数であり、例えば、P=10である。
ii.代替的に、F-Bが信号通知されてもよく、Bは、1などの固定値である。
iii.一例において、W2はW1よりも大きくなければならない。
iv.一例において、Fは、ユーナリー符号、またはトランケイテッドユーナリー符号、または固定長符号でコーディングされてもよく、または固定長コーディングされてもよい。
d.一例において、第1の高さ(H1)と第2の高さ(H2)との間の比、すなわちH2/H1が信号通知されてもよい。例えば、H2=F*H1である場合、Fが信号通知される。別の例において、H2=Shift(F*H1,P)である場合、Fが信号通知され、Pは、精度を表す数であり、例えば、P=10である。
i.代替的に、Fは、(H2*P+H1/2)/H1に等しくてもよく、Pは、精度を表す数であり、例えば、P=10である。
ii.代替的に、F-Bが信号通知されてもよく、Bは、1などの固定値である。
iii.一例において、H2はH1よりも大きくなければならない。
iv.一例において、差は、ユーナリー符号、またはトランケイテッドユーナリー符号、または固定長符号でコーディングされてもよく、または固定長コーディングされてもよい。
e.一例において、W2/W1はH2/H1に等しくなければならず、W2/W1またはH2/H1のみが信号通知されるべきである。
【0312】
8.異なる解像度/解像度比を信号通知する場合、以下の追加の構文要素がさらに信号通知されてよいことを提案する。
a.構文要素は、CTUのサイズの指示であってもよい。
b.構文要素は、最小コーディングユニットのサイズの指示であってもよい。
c.構文要素は、最大および/または最小変換ブロックサイズの指示であってもよい。
d.構文要素は、4分木および/または2分木/3分木の最大深さの指示であってもよい。
e.一例において、追加の構文要素は、特定のピクチャ解像度にバインドされてもよい。
【0313】
参照ピクチャリスト
9.適合ビットストリームは、現在のピクチャとは異なる解像度の参照ピクチャが、同じ解像度の参照ピクチャに比べてより大きい参照インデックスを割り当てられることを満足するものとする。
a.代替的に、1つのピクチャ/スライス/タイル/タイルグループを復号化する前に、参照ピクチャリストの場合、現在のピクチャとは異なる解像度の参照ピクチャが、同じ解像度の参照ピクチャに比べてより大きい参照インデックスを割り当てられるように、参照ピクチャリストが再配列されてもよい。
【0314】
ARCによる時間的ブロック(例えば、TMVPおよびATMVP)からの動き予測
10.2つのブロックAとBがあるとする。ブロックAの参照ピクチャが現在のブロックと同じ解像度の参照ピクチャであり、ブロックBの参照ピクチャが現在のブロックと異なる解像度の参照ピクチャである場合、ブロックBの動き情報を使用してブロックAを予測することを禁止することを提案する。
a.ブロックAの参照ピクチャが現在のブロックと異なる解像度の参照ピクチャであり、ブロックBの参照ピクチャが現在のブロックと同じ解像度の参照ピクチャである場合、ブロックBの動き情報を使用してブロックAを予測することを禁止することを提案する。
【0315】
11.現在のピクチャと異なる解像度を有する参照ピクチャにおけるブロックからの予測を許可しないことを提案する。
【0316】
12.参照ピクチャは、その幅が現在のピクチャの幅と異なるか、またはその高さが現在のピクチャの高さと異なる場合、並置された参照ピクチャでありえないようにすることを提案する。
b.代替的に、参照ピクチャは、その幅が現在のピクチャの幅と異なり、かつ、その高さが現在のピクチャの高さと異なる場合、並置された参照ピクチャでありえない。
【0317】
13.TMVP/ATMVPにおける並置されたブロック、またはATMVPにおける並置されたサブブロックをどのように見出すかは、並置された参照ピクチャと現在のピクチャとが同じピクチャ幅および高さを有するかどうかに依存してよい。
a.一例において、現在のピクチャの寸法がW0*H0であり、並置された参照ピクチャの寸法がW1*H1であるとすると、並置されたブロックの位置および/または寸法は、W0、H0、W1、およびH1に依存してよい。
i.一例において、現在のブロックまたはサブブロックの左上座標が(x,y)であるとすると、並置されたブロックまたはサブブロックは、並置された参照ピクチャにおける位置(x’,y’)をカバーするブロックとして導出されてもよく、(x’,y’)は、x’=Rx*(x+offsetX)+offsetX’およびy’=Ry*(y+offsetY)+offsetY’として計算してもよい。offsetX’とoffsetY’は、0のような値である。
1)一例において、現在のブロックまたは現在のサブブロックの寸法がw*hであるとすると、(offsetX,offsetY)は(x+w,y+h)に等しくてもよい。
a)代替例において、(offsetX,offsetY)は、(x+w/2,y+h/2)に等しくてもよい。
b)代替例において、(offsetX,offsetY)は、(x+w/2-1,y+h/2-1)に等しくてもよい。
c)代替例において、(offsetX,offsetY)は、(0,0)に等しくてもよい。
2)一例において、Rx=W1/W0である。
3)一例において、Ry=H1/H0である。
4)1つの代替例において、x’=Shift(Rx*(x+offsetX)
,P)であり、Pは、精度を表す値、例えば10である。
a)Rxは、Rx=(W1*P+offset)/W0として導出されてもよく、offsetは、0またはW0/2などの整数である。
5)1つの代替例において、y’=Shift(Ry*(y+offsetY),P)であり、Pは、精度を表す値、例えば10である。
a)Ryは、Ry=(H1*P+offset)/H0として導出されてもよく、offsetは、0またはH0/2などの整数である。
【0318】
14.現在のピクチャとは異なる解像度の参照ピクチャにおける参照サンプルをアップサンプリングまたはダウンサンプリングすることに加え、動き情報/符号情報をさらにアップサンプリングまたはダウンサンプリングすること、または、アップサンプリングまたはダウンサンプリングされた情報を、他のフレームにおける後続のブロックをコーディングするために利用できるようにすることを提案する。
【0319】
15.並置された参照ピクチャの幅または高さが現在のピクチャの幅または高さと異なる場合、並置されたMVを記憶するバッファをアップサンプリングしてもよいし、ダウンサンプリングしてもよい。
b.一例において、アップサンプリングされたまたはダウンサンプリングされたMVバッファ、および、アップサンプリングまたはダウンサンプリング前のMVバッファは、両方とも記憶されてもよい。
i.代替的に、アップサンプリングまたはダウンサンプリング前のMVバッファを除外してもよい。
c.一例において、アップサンプリングされたMVバッファにおける複数のMVは、アップサンプリングの前のMVバッファにおける1つのMVからコピーされる。
i.例えば、アップサンプリングされたMVバッファにおける複数のMVは、アップサンプリング前のMVバッファにおいてMVが存在する領域に対応する領域にあってもよい。
d.一例において、ダウンサンプリングされたMVバッファにおける1つのMVは、ダウンサンプリング前のMVバッファにおける複数のMVのうちの1つのMVから取り出されてもよい。
i.例えば、ダウンサンプリングされたMVバッファにおける1つのMVは、ダウンサンプリング前のMVバッファにおいて複数のMVが存在する領域に対応する領域にあってもよい。
【0320】
16.ATMVPにおける時間的MVの導出は、現在のピクチャの寸法W0*H0および並置されたピクチャの寸法W1*H1に依存してよいことを提案する。
c.例えば、並置されたピクチャの寸法と現在のピクチャの寸法とが同じでない場合、tMVとして表される時間的MVがtMV’に変換されてよい。
i.例えば、tMV=(tMVx,tMVy)、tMV’=(tMVx’,tMVy’)とすると、tMVx’は、tMVx’=Rx*tMVx+offsetxとして計算されてよく、tMVy’は、tMVy’=Ry*tMVy+offsetyとして算出されてよい。offsetxおよびoffsetyは、0などの値である。
1)一例において、Rx=W1/W0である。
2)一例において、Ry=H1/H0である。
3)1つの代替例において、tMVx’=Shift(Rx*(tMVx+offsetX),P)またはSatShift(Rx*(tMVx+offsetX),P)であり、Pは、精度を表す値であり、例えば10である。
a)Rxは、Rx=(W1*P+offset)/W0として導出されてもよく、offsetは、0またはW0/2などの整数である。
4)1つの代替例において、tMVy’=Shift(Ry*(tMVy+offsetY),P)またはSatShift(Ry*(tMVy+offsetY),P)であり、Pは、精度を表す値であり、例えば10である。
a)Ryは、Ry=(H1*P+offset)/H0として導出されてもよく、offsetは、0またはH0/2などの整数である。
【0321】
17.TMVP/ATMVPにおける現在のブロックまたは現在のサブブロックのMVP(MV Prediction)の導出は、現在のピクチャの寸法、および/または、MVPが参照する参照ピクチャの寸法、および/または、並置されたピクチャの寸法、および/または、並置されたMVが参照する並置されたピクチャの参照ピクチャの寸法に依存してよいことを提案する。並置されたMVは、並置されたブロックの中にあるMVを示す。図23は、現在のピクチャ(CurPic)、MVPが参照する参照ピクチャ(RefPic)、並置されたピクチャ(ColPic)、および並置されたMVが参照する並置されたピクチャの参照ピクチャ(RefColPic)が、それぞれ時刻(またはPOC)T0、T1、T2、T3にある場合の例を示している。そして、それらの寸法はそれぞれ、W0*H0、W1*H1、W2*H2、およびW3*H3である。現在のブロック/サブブロックのMVPは、MvCur=(MvCurX,MvCurY)として表され、並置されたMVは、MvCol(MvColX,MvColY)として表される。
d.MvCurXは、MvCurX=Rx*MvColX+offsetxとして計算されてよく、MvCurYは、MvCurY=Ry*MvColY+offsetyとして計算されてもよい。offsetxおよびoffsetyは、0などの値である。
e.一例において、Rx=W0/W2である。
f.一例において、Ry=H0/H2である。
g.ある代替例では、MvCurX=Shift(Rx*(MvColX+offsetX),P)またはMvCurX=SatShift(Rx*(MvColX+offsetX),P)となり、Pは精度を表す値であり、例えば10である。
i.Rxは、Rx=(W0*P+offset)/W2として導出されてよく、offsetは、0またはW2/2などの整数である。
h.1つの代替例では、MvCurY=Shift(Ry*(MvColY+offsetY),P)またはMvCurY=SatShift(Ry*(MvColY+offsetY),P)であり、Pは精度を表す値であり、例えば10である。
i.Ryは、Ry=(H0*P+offset)/H2として導出されてよく、offsetは、0またはH2/2などの整数である。
i.一例において、(W3,H3)は、(W2,H2)に等しくなければならない。そうでない場合、MvColは利用不可能であると見なされてよい。
j.一例において、(W0,H0)は、(W1,H1)に等しくなければならず、そうでなければ、MVCurは、利用可能でないと見なされてよい。
【0322】
ARCにおける補間とスケーリング
18.ARCのための1または複数のダウンサンプリングまたはアップサンプリングフィルタリング方法は、DPS、VPS、SPS、PPS、APS、ピクチャヘッダ、スライスヘッダ、タイルグループヘッダなどの映像ユニットにて、RPSもしくはCPSと命名されたARCのための個々の映像ユニットにて、信号通知されてよいことを提案する。
【0323】
19.JVET-N0279のアプローチにおいて、hori_scale_fpおよび/またはvert_scale_fpは、DPS、VPS、SPS、PPS、APS、ピクチャヘッダ、スライスヘッダ、タイルグループヘッダなどの映像ユニットにて、または、RPSもしくはCPSと命名されたARCのための個々の映像ユニットにて信号通知されてよい。
【0324】
20.hori_scale_fpおよび/またはvert_scale_fpの導出、またはbullet8_bult11におけるRxおよび/またはRyの導出など、RACにおけるスケーリング手法における任意の分割動作が、1または複数のテーブルが用いられてよい、1または複数の動作に置き換えまたは近似してもよいことを提案する。例えば、P1905289301に開示された方法は、分割動作を置き換えるかまたは近似するために使用されてもよい。
【0325】
上述した例は、以下に説明する方法のコンテキスト、例えば、方法2400、2410、2420、2430、2440、2450、2460、2470、2480、および2490に含まれてもよく、これらの方法は、映像デコーダまたは映像エンコーダにおいて実装されてよい。
【0326】
図24Aは、例示的な映像処理のための方法のフローチャートを示す。方法2400は、ステップ2402において、1または複数の映像ユニットを有する1または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を実行することを含む。いくつかの実施形態において、ビットストリーム表現は、フォーマット規則に準拠し、ARC(Adaptive Resolution Conversion)処理に関する情報を有し、フォーマット規則は、ARC処理の映像セグメントへの適用を規定し、映像セグメントの1または複数の映像ユニットが異なる解像度でコーディングされることの指示が、ヘッダ構文構造、DPS(Decoder Parameter Set)、VPS(Video Parameter Set)、PPS(Picture Parameter Set)、SPS(Sequence Parameter Set)、およびAPS(Adaptive Parameter Set)とは異なる構文構造のビットストリーム表現に含まれる。
【0327】
いくつかの実施形態において、ビットストリーム表現は、フォーマット規則に準拠し、ARC(Adaptive Resolution Conversion)処理に関する情報を有し、K次の指数ゴロム符号でコーディングされている1または複数の映像ユニットの寸法が、ビットストリーム表現で信号通知され、Kは正の整数であり、フォーマット規則は、ARC処理の映像セグメントへの適用を規定し、映像セグメントの1または複数の映像ユニットが異なる解像度でコーディングされているとことの指示が、構文構造のビットストリーム表現に含まれる。
【0328】
いくつかの実施形態において、ビットストリーム表現は、フォーマット規則に準拠し、ARC(Adaptive Resolution Conversion)処理に関する情報を有し、高さ(H)と幅(W)がビットストリーム表現で信号通知され、HとWは、正の整数であり、制約されており、フォーマット規則は、ARC(Adaptive Resolution Conversion)処理の映像セグメントへの適用を規定し、映像セグメントの1または複数の映像ユニットが異なる解像度でコーディングされているとこと指示が、構文構造のビットストリーム表現に含まれる。
【0329】
図24Bは、例示的な映像処理のための方法のフローチャートを示す。方法2410は、ステップ2412において、(a)映像の現在の映像ブロックの第1の時間的に近傍のブロックの第1の参照ピクチャの解像度が、現在のピクチャの解像度と同一であること、および(b)現在の映像ブロックの第2の時間的に近傍のブロックの第2の参照ピクチャの解像度が、現在のピクチャの解像度と異なることを判定することを含む。
【0330】
方法2410は、ステップ2414において、第1の時間的に近傍のブロックの予測における第2の時間的に近傍のブロックの動き情報の使用を、判定に起因して、無効化することにより、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することを含む。
【0331】
図24Cは、例示的な映像処理方法のフローチャートを示す。方法2420は、ステップ2422において、(a)映像の現在の映像ブロックの第1の時間的に近傍のブロックの第1の参照ピクチャの解像度が、現在のピクチャの解像度と異なること、および(b)現在の映像ブロックの第2の時間的に近傍のブロックの第2の参照ピクチャの解像度が、現在のピクチャの解像度と同一であることを判定することを含む。
【0332】
方法2420は、ステップ2424において、第1の時間的に近傍のブロックの予測における第2の時間的に近傍のブロックの動き情報の使用を、判定に起因して、無効化することにより、映像の現在の映像ブロックとビットストリーム表現との間の変換を実行することを含む。
【0333】
図24Dは、例示的な映像処理のための方法のフローチャートを示す。方法2430は、ステップ2432において、映像の現在の映像ブロックのために、現在の映像ブロックに関連付けられた映像ブロックを有する参照ピクチャの解像度が、現在の映像ブロックを有する現在のピクチャの解像度とは異なることを判定することを含む。
【0334】
方法2430は、ステップ2434において、参照ピクチャの映像ブロックに基づいた予測処理を、判定に起因して、無効化することにより、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することを含む。
【0335】
図24Eは、例示的な映像処理のための方法のフローチャートを示す。方法2440は、ステップ2442において、ピクチャの少なくとも1つの寸法に基づいて、ピクチャが現在のピクチャの現在の映像ブロックのための並置された参照ピクチャとして使用することが許可されるかどうかに関する決定を実行することを含む。
【0336】
方法2440は、ステップ2444において、決定に基づいて、映像の現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することを含む。
【0337】
図24Fは、例示的な映像処理のための方法のフローチャートを示す。方法2450は、ステップ2452において、映像の現在の映像ブロックの予測のために、並置されたブロックを有する並置された参照ピクチャの寸法が、現在の映像ブロックを有する現在のピクチャの寸法と同一であるとことの判定に基づいて、並置されたブロックを識別する。
【0338】
方法2450は、ステップ2454において、並置されたブロックを使用して、映像の現在の映像ブロックとビットストリーム表現との間の変換を実行することを含む。
【0339】
図24Gは、例示的な映像処理のための方法のフローチャートを示す。方法2460は、ステップ2462において、映像の現在の映像ブロックのために、現在の映像ブロックに関連付けられた参照ピクチャが、現在の映像ブロックを有する現在のピクチャの解像度とは異なる解像度を有することを判定する。
【0340】
方法2460は、ステップ2464において、映像の現在の映像ブロックとビットストリーム表現との間の変換の一部として、参照ピクチャの1または複数の参照サンプル、および現在の映像ブロックに対する動き情報または現在の映像ブロックに対するコーディング情報に対してアップサンプリング動作またはダウンサンプリング動作を実行することを含む。
【0341】
図24Hは、例示的な映像処理のための方法のフローチャートを示す。方法2470は、ステップ2472において、映像の現在の映像ブロックと映像のビットストリーム表現との間の変換のために、現在の映像ブロックを有する現在のピクチャの高さまたは幅が、現在の映像ブロックに関連付けられた並置された参照ピクチャの高さまたは幅と異なることを決定することを含む。
【0342】
方法2470は、ステップ2474において、決定に基づいて、並置された参照ピクチャの1または複数の動きベクトルを記憶するバッファに対してアップサンプリング動作またはダウンサンプリング動作を実行することを含む。
【0343】
図24Iは、例示的な映像処理のための方法のフローチャートを示す。方法2480は、ステップ2482において、映像の現在の映像ブロックを含む現在のピクチャの寸法と、現在の映像ブロックに関連付けられた、並置されたピクチャの寸法に基づいて、現在の映像ブロックに適用されたATMVP(Alternative Temporal Motion Vector Prediction)処理に関する情報を導出する。
【0344】
方法2480は、ステップ2484において、時間的動きベクトルを使用して、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することを含む。
【0345】
図24Jは、例示的な映像処理のための方法のフローチャートを示す。方法2490は、ステップ2492において、映像の現在の映像ブロックに対してARC(Adaptive Resolution Conversion)処理の適用のために、映像のビットストリーム表現を構成することを含む。いくつかの実施形態において、ARC処理に関する情報がビットストリーム表現で信号通知され、現在の映像ブロックを有する現在のピクチャは第1の解像度を有し、ARC処理は、現在の映像ブロックの一部を第1の解像度とは異なる第2の解像度で再サンプリングすることを有する。
【0346】
方法2490は、ステップ2494において、構成することに基づいて、現在の映像ブロックと現在の映像ブロックのビットストリーム表現との間で変換を実行することを含む。
【0347】
4. 開示される技術の例示的な実装形態
【0348】
図25は、映像処理装置2500のブロック図である。装置2500は、本明細書に記載の方法の1または複数を実装するために使用してもよい。装置2500は、スマートフォン、タブレット、コンピュータ、IoT(Internet of Things)受信機等に実施されてもよい。装置2500は、1または複数のプロセッサ2502と、1または複数のメモリ2504と、映像処理ハードウェア2506と、を含んでもよい。1または複数のプロセッサ2502は、本明細書に記載される1または複数の方法(方法2400、2410、2420、および2430を含むが、これに限定されない)を実装するように構成されてもよい。メモリ2504は、本明細書で説明される方法および技術を実装するために使用されるデータおよびコードを記憶するために使用してもよい。映像処理ハードウェア2506は、本明細書に記載される技術をハードウェア回路にて実装するために使用してもよい。
【0349】
いくつかの実施形態において、映像コーディング方法は、図25を参照して説明したように、ハードウェアプラットフォームに実装される装置を使用して実施してもよい。
【0350】
開示される技術のいくつかの実施形態は、映像処理ツールまたはモードを有効化するように決定または判定することを含む。一例において、映像処理ツールまたはモードが有効化される場合、エンコーダは、1つの映像ブロックを処理する際にこのツールまたはモードを使用するまたは実装するが、このツールまたはモードの使用に基づいて、結果として得られるビットストリームを必ずしも修正しなくてもよい。すなわち、映像のブロックから映像のビットストリーム表現への変換は、決定または判定に基づいて映像処理ツールまたはモードが有効化される場合に、この映像処理ツールまたはモードを使用する。別の例において、映像処理ツールまたはモードが有効化される場合、デコーダは、ビットストリームが映像処理ツールまたはモードに基づいて修正されたことを知って、ビットストリームを処理する。すなわち、決定または判定に基づいて有効化された映像処理ツールまたはモードを使用して、映像のビットストリーム表現から映像のブロックへの変換を行う。
【0351】
開示される技術のいくつかの実施形態は、映像処理ツールまたはモードを無効化するように決定または判定することを含む。一例において、映像処理ツールまたはモードが無効にされている場合、エンコーダは、映像のブロックを映像のビットストリーム表現に変換する際に、このツールまたはモードを使用しない。別の例において、映像処理ツールまたはモードが無効にされている場合、デコーダは、決定または判定に基づいて有効化された映像処理ツールまたはモードを使用してビットストリームが修正されていないことを知って、ビットストリームを処理する。
【0352】
図26は、本明細書で開示される様々な技術が実装され得る例示的な映像処理システム2600を示すブロック図である。様々な実装形態は、システム2600のコンポーネントの一部または全部を含んでもよい。システム2600は、映像コンテンツを受信するための入力2602を含んでもよい。映像コンテンツは、未加工または非圧縮フォーマット、例えば、8または10ビットのマルチコンポーネント画素値で受信されてもよく、または圧縮または符号化フォーマットで受信されてもよい。入力2602は、ネットワークインターフェース、周辺バスインターフェース、または記憶インターフェースを表してもよい。ネットワークインターフェースの例は、イーサネット(登録商標)、PON(Passive Optical Network)等の有線インターフェース、およびWi-Fi(登録商標)またはセルラーインターフェース等の無線インターフェースを含む。
【0353】
システム2600は、本明細書に記載される様々な符号化または符号化方法を実装することができるコーディングコンポーネント2604を含んでもよい。コーディングコンポーネント2604は、入力2602からの映像の平均ビットレートをコーディングコンポーネント2604の出力に低減し、映像のコーディングされた表現を生成してもよい。従って、このコーディング技術は、映像圧縮または映像コード変換技術と呼ばれることがある。コーディングコンポーネント2604の出力は、コンポーネント2606によって表されるように、記憶されてもよいし、接続された通信を介して送信されてもよい。入力2602において受信された、記憶されたまたは通信された映像のビットストリーム(またはコーディングされた)表現は、コンポーネント2608によって使用されて、表示インターフェース2610に送信される画素値または表示可能な映像を生成してもよい。ビットストリーム表現からユーザが見ることができる映像を生成する処理は、映像展開と呼ばれることがある。さらに、特定の映像処理動作を「コーディング」動作またはツールと呼ぶが、コーディングツールまたは動作は、エンコーダおよびそれに対応する、復号化の結果を逆にする復号化ツールまたは動作が、デコーダによって行われることが理解されよう。
【0354】
周辺バスインターフェースユニットまたは表示インターフェースユニットの例は、USB(Universal Serial Bus)またはHDMI(High Definition Multimedia Interface:登録商標)またはディスプレイポート等を含んでもよい。ストレージインターフェースの例は、SATA(Serial Advanced Technology Attachement)、PCI、IDEインターフェース等を含む。本明細書に記載される技術は、携帯電話、ノートパソコン、スマートフォン、またはデジタルデータ処理および/または映像表示を実施可能な他のデバイス等の様々な電子デバイスに実施されてもよい。
【0355】
いくつかの実施形態において、下記のような技術的解決策を実装することができる。
【0356】
A1. 映像処理のための方法であって、1または複数の映像ユニットを有する1または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を実行することを有し、ビットストリーム表現は、フォーマット規則に準拠し、かつ、ARC(Adaptive Resolution Conversion)処理に関する情報を有し、K次の指数ゴロム符号でコーディングされている1または複数の映像ユニットの寸法が、ビットストリーム表現で信号通知され、Kは正の整数であり、フォーマット規則は、ARC処理の映像セグメントへの適用を規定し、映像セグメントの1または複数の映像ユニットが異なる解像度でコーディングされていることの指示が、構文構造のビットストリーム表現に含まれる、方法。
【0357】
A2. 寸法は、1または複数の映像ユニットのうちの映像ユニットの幅および高さの少なくとも1つを含む、解決策A1に記載の方法。
【0358】
A3. 1または複数の映像ユニットはピクチャを含む、解決策A1に記載の方法。
【0359】
A4. 構文構造は、DPS(Decoder Parameter Set)、VPS(Video Parameter Set)、SPS(Sequence Parameter Set)、PPS(Picture Parameter Set)、APS(Adaptive Parameter Set)、ピクチャヘッダ、スライスヘッダ、またはタイルグループヘッダである、解決策A1に記載の方法。
【0360】
A5. 構文構造は、RPS(Resolution Parameter Set)またはCPS(Conversion Parameter Set)である、解決策A1に記載の方法。
【0361】
A6. 映像処理のための方法であって、1または複数の映像ユニットを有する1または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を実行することを有し、ビットストリーム表現は、フォーマット規則に準拠し、かつ、ARC(Adaptive Resolution Conversion)処理に関する情報を有し、1または複数の映像ユニットのうちの映像ユニットの高さ(H)と幅(W)がビットストリーム表現で信号通知され、HとWは、正の整数であり、かつ、抑制されており、フォーマット規則は、ARC(Adaptive Resolution Conversion)処理の映像セグメントへの適用を規定し、映像セグメントの1または複数の映像ユニットが異なる解像度でコーディングされていることの指示が、構文構造のビットストリーム表現に含まれる、方法。
【0362】
A7. W≦TWmaxであり、TWmaxは正の整数である、解決策A6に記載の方法。
【0363】
A8. TWmaxはビットストリーム表現で信号通知される、解決策A7に記載の方法。
【0364】
A9. TWmin≦Wであり、TWminは正の整数である、解決策A6に記載の方法。
【0365】
A10. TWminはビットストリーム表現で信号通知される、解決策A9に記載の方法。
【0366】
A11. H≦THmaxであり、THmaxは正の整数である、解決策A6に記載の方法。
【0367】
A12. THmaxはビットストリーム表現で信号通知される、解決策A11に記載の方法。
【0368】
A13. THmin≦Hであり、THminは正の整数である、解決策A6に記載の方法。
【0369】
A14. THminはビットストリーム表現で信号通知される、解決策A13に記載の方法。
【0370】
A15. 高さH=h×Yであり、幅W=w×Xであり、w、h、X、およびYは正の整数であり、w、hはビットストリーム表現で信号通知される、解決策A6に記載の方法。
【0371】
A16. X=Y=4である、解決策A15に記載の方法。
【0372】
A17. XおよびYが予め定義された整数である、解決策A15に記載の方法。
【0373】
A18. 1または複数の映像ユニットはピクチャを有する、解決策A6に記載の方法。
【0374】
A19. 映像処理のための方法であって、1または複数の映像ユニットを有する1または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を実行することを有し、ビットストリーム表現は、フォーマット規則に準拠し、かつ、ARC(Adaptive Resolution Conversion)処理に関する情報を有し、フォーマット規則は、ARC処理の映像セグメントへの適用を規定し、かつ、映像セグメントの1または複数の映像ユニットが、異なる解像度でコーディングされることの指示が、ヘッダ構文構造、DPS(Decoder Paramete Set)、VPS(Video Parameter Set)、PPS(Picture Parameter Set)、SPS(Sequence Parameter Set)、およびAPS(Adaptive Parameter Set)とは異なる構文構造のビットストリーム表現に含まれる、方法。
【0375】
A20. ARC処理に関する情報は、1または複数の映像ユニットを有するピクチャの高さ(H)または幅(W)を有する、解決策A19に記載の方法。
【0376】
A21. ARC処理に関する情報は、SEI(Supplemental Enhancement Information)メッセージで信号通知される、解決策A19またはA20に記載の方法。
【0377】
A22. ヘッダ構文構造は、ピクチャヘッダ、スライスヘッダ、またはタイルグループヘッダを有する、解決策A19またはA20に記載の方法。
【0378】
A23. ARC処理に関する情報は、RPS(Resolution Parameter Set)またはCPS(Conversion Parameter Set)にて信号通知される、解決策A19またはA20に記載の方法。
【0379】
A24. ARC処理に関する情報は、1または複数の映像ユニットを有するピクチャの幅に対する高さの比を有する、解決策A19に記載の方法。
【0380】
A25. ARC処理に関する情報は、1または複数の映像ユニットを有するピクチャの異なる幅に対する異なる高さの複数の比を有する、解決策A19に記載の方法。
【0381】
A26. 複数の比のうちの許容される比に対応するインデックスは、PPS(Picture Parameter Set)にて信号通知される、解決策A25に記載の方法。
【0382】
A27. 複数の比のうちの任意の1つの比は、複数の比のうちの任意の他の比と異なる、解決策A25に記載の方法。
【0383】
A28. 情報は、(i)第1の幅と第2の幅との差、(ii)第1の高さと第2の高さとの差、(iii)第1の幅と第2の幅との比、または(iv)第1の高さと第2の高さとの比のうちの少なくとも1つを含む、解決策A19に記載の方法。
【0384】
A29. 情報は、ユーナリー符号、トランケイテッドユーナリー符号、または固定長符号にてコーディングされる、解決策A28に記載の方法。
【0385】
A30. ビットストリーム表現は更に、CTU(Coding Tree Unit)サイズを示す構文要素、最小CU(Coding Unit)サイズを示す構文要素、最大または最小TB(Transform Block)サイズを示す構文要素、1または複数の映像ユニットに適用され得る分割処理の最大深さを示す構文要素、または特定のピクチャ解像度にバインドするように構成される構文要素のうちの少なくとも1つを含む、解決策A19に記載の方法。
【0386】
A31. 1または複数の映像ユニットを有する現在のピクチャに関連付けられた第1の参照ピクチャは、現在のピクチャの解像度に等しい第1の解像度を有し、現在のピクチャに関連付けられた第2の参照ピクチャは、現在のピクチャの解像度よりも大きい第2の解像度を有し、第2の参照ピクチャの参照インデックスは、第1の参照ピクチャの参照インデックスよりも大きい、解決策A19に記載の方法。
【0387】
A32. 変換は、ビットストリーム表現から1または複数の映像ユニットを生成する、解決策A19~A31のいずれかに記載の方法。
【0388】
A33. 変換は、1または複数の映像ユニットからビットストリーム表現を生成する、解決策A19~A31のいずれかに記載の方法。
【0389】
A34. プロセッサと、命令を有する非一時的メモリとを有する、映像システムにおける装置であって、命令は、プロセッサにより実行されることにより、プロセッサに解決策A19~A33のいずれかに記載の方法を実装させる装置。
【0390】
A35. 非一時的コンピュータ可読媒体に記憶されたコンピュータプログラムプロダクトであって、解決策A19~A33のいずれかに記載の方法を実行するためのプログラムコードを含む、コンピュータプログラムプロダクト。
【0391】
いくつかの実施形態において、下記のような技術的解決策を実装することができる。
【0392】
B1. 映像処理のための方法であって、(a)映像の現在の映像ブロックの時間的に近傍の第1のブロックの第1の参照ピクチャの解像度が、現在の映像ブロックを有する現在のピクチャの解像度と同一であること、および(b)現在の映像ブロックの時間的に近傍の第2のブロックの第2の参照ピクチャの解像度が、現在のピクチャの解像度と異なること、を判定することと、判定に起因して、第1の時間的に近傍のブロックの予測における第2の時間的に近傍のブロックの動き情報の使用を無効化することにより、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を有する、方法。
【0393】
B2. 映像処理のための方法であって、(a)映像の現在の映像ブロックの時間的に近傍の第1のブロックの第1の参照ピクチャの解像度が、現在の映像ブロックを有する現在のピクチャの解像度と異なること、および(b)現在の映像ブロックの時間的に近傍の第2のブロックの第2の参照ピクチャの解像度が、現在のピクチャの解像度と同一であること、を判定することと、判定に起因して、第1の時間的に近傍のブロックの予測における第2の時間的に近傍のブロックの動き情報の使用を無効化することにより、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を有する、方法。
【0394】
B3. 映像処理のための方法であって、映像の現在の映像ブロックのために、現在の映像ブロックに関連付けられた映像ブロックを有する参照ピクチャの解像度が、現在の映像ブロックを有する現在のピクチャの解像度とは異なることを判定することと、判定に起因して、参照ピクチャの映像ブロックに基づく予測処理を無効化することにより、現在の映像ブロックと映像のビットストリーム表現との間の変換を行うことと、を有する、映像処理方法。
【0395】
B4. 映像処理のための方法であって、ピクチャの少なくとも1つの寸法に基づいて、ピクチャを現在のピクチャの現在の映像ブロックのための並置された参照ピクチャとして使用することが許可されるかどうかに関する決定を実行することと、決定に基づいて、映像の現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を有する、方法。
【0396】
B5. 参照ピクチャの少なくとも1つの寸法は、現在の映像ブロックを有する現在のピクチャの対応する寸法と異なり、かつ、参照ピクチャは、並置された参照ピクチャとして指定されない、解決策B4に記載の方法。
【0397】
B6. 映像処理のための方法であって、映像の現在の映像ブロックの予測のために、並置されたブロックを有する並置された参照ピクチャの寸法が、現在の映像ブロックを有する現在のピクチャの寸法と同一であることの判定に基づいて、並置されたブロックを識別することと、並置されたブロックを使用して、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を有する、映像処理方法。
【0398】
B7. 予測は、TMVP(Temporal Motion Vector Prediction)処理またはATMVP(Alternative Temporal Motion Vector Prediction)処理を有する、解決策B6に記載の方法。
【0399】
B8. 現在のピクチャは寸法W0×H0を有し、並置された参照ピクチャは寸法W1×H1を有し、並置されたブロックの位置またはサイズは、W0、H0、W1またはH1のうちの少なくとも1つに基づき、W0、H0、W1、およびH1は正の整数である、解決策B7に記載の方法。
【0400】
B9. ATMVP処理における時間的動きベクトルの導出は、W0、H0、W1、またはH1のうちの少なくとも1つに基づく、解決策B8に記載の方法。
【0401】
B10. 現在の映像ブロックのための動きベクトル予測の導出は、W0、H0、W1、またはH1のうちの少なくとも1つに基づく、解決策B8に記載の方法。
【0402】
B11. 映像処理のための方法であって、映像の現在の映像ブロックのために、現在の映像ブロックに関連付けられた参照ピクチャが、現在の映像ブロックを有する現在のピクチャの解像度とは異なる解像度を有することを判定することと、現在の映像ブロックと映像のビットストリーム表現との間の変換の一部として、参照ピクチャの1または複数の参照サンプル、および現在の映像ブロックに対する動き情報または現在の映像ブロックに対するコーディング情報においてアップサンプリング動作またはダウンサンプリング動作を実行することと、を有する、映像処理方法。
【0403】
B12. 現在の映像ブロックを有する現在のフレームと異なるフレームにおける後続の映像ブロックをコーディングするために、アップサンプリング動作またはダウンサンプリング動作に関する情報を使用することをさらに含む、解決策B11に記載の方法。
【0404】
B13. 映像処理のための方法であって、映像の現在の映像ブロックと映像のビットストリーム表現との間の変換のために、現在の映像ブロックを有する現在のピクチャの高さまたは幅は、現在の映像ブロックに関連付けられた並置された参照ピクチャの高さまたは幅とは異なることを判定することと、判定に基づいて、並置された参照ピクチャの1または複数の動きベクトルを記憶するバッファに対してアップサンプリング動作またはダウンサンプリング動作を実行することと、を有する、方法。
【0405】
B14. 映像処理のための方法であって、映像の現在の映像ブロックを有する現在のピクチャの寸法と、現在の映像ブロックに関連付けられた、並置されたピクチャの寸法とに基づいて、現在の映像ブロックに適用されたATMVP(Alternative Temporal Motion Vector Prediction)処理のための情報を導出することと、時間的動きベクトルを使用して現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を有する、方法。
【0406】
B15. 情報は、時間的動きベクトルを有する、解決策B14に記載の方法。
【0407】
B16. 情報は、現在の映像ブロックのためのMVP(Motion Vector Prediction)を含み、導出することは更に、MVPによって参照される参照ピクチャの寸法に基づく、解決策B14に記載の方法。
【0408】
B17. 映像処理のための方法であって、映像の現在の映像ブロックに対するARC(Adaptive Resolution Conversion)処理の適用のために、映像のビットストリーム表現を構成することであって、ARC処理に関する情報は、ビットストリーム表現にて信号通知され、現在の映像ブロックを有する現在のピクチャは、第1の解像度を有し、ARC処理は、第1の解像度とは異なる第2の解像度にて現在の映像ブロックの一部を再サンプリングすることを有する、ことと、構成することに基づいて、現在の映像ブロックと現在の映像ブロックの前記ビットストリーム表現との間の変換を実行することと、を有する、方法。
【0409】
B18. ARC処理に関する情報は、1または複数のアップサンプリングまたはダウンサンプリングフィルタリング方法のためのパラメータを有する、解決策B17に記載の方法。
【0410】
B19. ARC処理に関する情報は、コーディングされた映像シーケンス内での解像度の変更を可能にするように、参照ピクチャをスケーリングするための水平方向のスケーリング係数または垂直方向のスケーリング係数を有する、解決策B17に記載の方法。
【0411】
B20. 情報は、DPS(Decoder Parameter Set)、VPS(Video Parameter Set)、SPS(Sequence Parameter Set)、PPS(Picture Parameter Set)、APS(Adaptive Parameter Set)、ピクチャヘッダ、スライスヘッダ、タイルグループヘッダ、または個々の映像ユニットにおいて信号通知される、解決策B18またはB19に記載の方法。
【0412】
B21. 個々の映像ユニットは、RPS(Resolution Parameter Set)またはCPS(Conversion Parameter Set)である、解決策B20に記載の方法。
【0413】
B22. 水平スケーリング係数または垂直スケーリング係数を導出することは、1または複数のテーブルを使用して実装される分割動作を含む、解決策B19に記載の方法。
【0414】
B23. 変換は、ビットストリーム表現から現在の映像ブロックを生成する、解決策B1~B22のいずれかに記載の方法。
【0415】
B24. 変換は、現在の映像ブロックからビットストリーム表現を生成する、解決策B1~B22のいずれかに記載の方法。
【0416】
B25. プロセッサと、命令を有する非一時的メモリとを有する、映像システムにおける装置であって、命令は、プロセッサにより実行されることにより、プロセッサに、解決策B1~B24のいずれかに記載の方法を実装させる装置。
【0417】
B26. 非一時的なコンピュータ可読媒体に記憶されたコンピュータプログラムプロダクトであって、解決策B1~B24のいずれかに記載の方法を実行するためのプログラムコードを含む、コンピュータプログラムプロダクト。
【0418】
いくつかの実施形態において、下記のような技術的解決策を実装することができる。
【0419】
C1. 映像処理のための方法であって、現在の映像ブロックに対するARC(Adaptive Resolution Conversion)処理の適用のために、現在の映像ブロックのビットストリーム表現を構成することであって、ARC処理に関する情報は、ビットストリーム表現で信号通知され、現在の映像ブロックは、第1の解像度を有し、ARC処理は、第1の解像度とは異なる第2の解像度で現在の映像ブロックの一部を再サンプリングすることを有する、ことと、構成することに基づいて、現在の映像ブロックと現在の映像ブロックのビットストリーム表現との間の変換を実行することと、を有する、方法。
【0420】
C2. ARC処理に関する情報は、現在の映像ブロックを有するピクチャの高さ(H)または幅(W)を有する、解決策C1に記載の方法。
【0421】
C3. ARC処理に関する情報は、DPS(Decoder Parameter Set)、VPS(Video Parameter Set)、SPS(Sequence Parameter Set)、PPS(Picture Parameter Set)、APS(Adaptive Parameter Set)、ピクチャヘッダ、スライスヘッダ、およびタイルグループヘッダとは異なるSEI(Supplemental Enhancement Information)メッセージにて信号通知される、解決策C1またはC2に記載の方法。
【0422】
C4. ARC処理に関する情報は、個々の映像ユニットにて信号通知される、解決策C1またはC2に記載の方法。
【0423】
C5. 個々の映像ユニットは、RPS(Resolution Parameter Set)またはCPS(Conversion Parameter Set)である、解決策C4に記載の方法。
【0424】
C6. ARC処理に関する情報は、固定長符号またはユーナリー符号でコーディングされる、解決策C1~C5のいずれかに記載の方法。
【0425】
C7. ARC処理に関する情報は、K次の指数ゴロム符号でコーディングされ、Kは正の整数である、解決策C1~C5のいずれかに記載の方法。
【0426】
C8. ARC処理に関する情報は、DPS(Decoder Parameter Set)、VPS(Video Parameter Set)、SPS(Sequence Parameter Set)、PPS(Picture Parameter Set)、APS(Adaptive Parameter Set)、ピクチャヘッダ、スライスヘッダ、またはタイルグループヘッダにて信号通知される、解決策C1またはC2に記載の方法。
【0427】
C9. ARC処理に関する情報は、現在の映像ブロックを有するピクチャの幅に対する高さの比を有する、解決策C1に記載の方法。
【0428】
C10. ARC処理に関する情報は、現在の映像ブロックを有するピクチャの異なる幅に対する異なる高さの複数の比を有する、解決策C1に記載の方法。
【0429】
C11. 複数の比のうちの許容される比に対応するインデックスが、PPS(Picture Parameter Set)にて信号通知される、解決策C10に記載の方法。
【0430】
C12. 複数の比のうちの任意の1つの比率が、複数の比率のうちの任意の他の比率と異なる、解決策C10に記載の方法。
【0431】
C13. TWmin≦W≦TWmaxであり、TWminおよびTWmaxは正の整数である、解決策C2に記載の方法。
【0432】
C14. TWminおよびTWmaxは、現在の映像ブロックのビットストリーム表現にて信号通知される、解決策C13に記載の方法。
【0433】
C15. THmin≦H≦THmaxであり、THminおよびTHmaxは正の整数である、解決策C2に記載の方法。
【0434】
C16. THminおよびTHmaxは、現在の映像ブロックのビットストリーム表現にて信号通知される、解決策C13に記載の方法。
【0435】
C17. 現在の映像ブロックを有するピクチャは、高さH=h×Yおよび幅W=w×Xを有し、w、h、W、H、X、およびYは正の整数であり、XおよびYは予め定義された整数であり、ARC処理に関する情報はwおよびhを有する、解決策C1に記載の方法。
【0436】
C18. X=Y=4である、解決策C17に記載の方法。
【0437】
C19. ARC処理に関する情報は、(i)第1の幅と第2の幅との差、(ii)第1の高さと第2の高さとの差、(iii)第1の幅と第2の幅との比、または(iv)第1の高さと第2の高さとの比のうちの少なくとも1つを含む、解決策C1に記載の方法。
【0438】
C20. 情報は、ユーナリー符号、トランケイテッドユーナリー符号、または固定長符号でコーディングされる、解決策C19に記載の方法。
【0439】
C21. ビットストリーム表現は更に、CTU(Coding Tree Unit)サイズを示す構文要素、最小CU(Coding Unit)サイズを示す構文要素、最大または最小TB(Transform Block)サイズを示す構文要素、現在の映像ブロックに適用され得る分割処理の最大深さを示す構文要素、または特定のピクチャ解像度にバインドするように構成される構文要素のうちの少なくとも1つを有する、解決策C1に記載の方法。
【0440】
C22. 映像処理の方法であって、現在の映像ブロックの予測のために、現在の映像ブロックの時間的に近傍のブロックの参照ピクチャを選択的に使用することに関する決定を実行することと、決定および現在の映像ブロックの参照ピクチャに基づいて、現在の映像ブロックと現在の映像ブロックのビットストリーム表現との間の変換を実行することと、を有する、方法。
【0441】
C23. 現在の映像ブロックの参照ピクチャの解像度は、現在の映像ブロックの解像度と同一であり、時間的に近傍のブロックの参照ピクチャの解像度は、現在の映像ブロックの解像度とは異なり、現在の映像ブロックの予測は、時間的に近傍のブロックに関連付けられた動き情報を使用しない、解決策C22に記載の方法。
【0442】
C24. 現在の映像ブロックの参照ピクチャの解像度は、現在の映像ブロックの解像度と異なり、時間的に近傍のブロックの参照ピクチャの解像度は、現在の映像ブロックの解像度とは異なり、現在の映像ブロックの予測は、時間的に近傍のブロックに関連付けられた動き情報を使用しない、解決策C22に記載の方法。
【0443】
C25. 映像処理の方法であって、現在の映像ブロックの参照ピクチャの少なくとも1つの寸法に基づいて、参照ピクチャの並置された参照ピクチャとしての指定に関する決定を実行することと、決定に基づいて、現在の映像ブロックと、現在の映像ブロックのビットストリーム表現との間の変換を実行することと、を有する、方法。
【0444】
C26. 参照ピクチャの少なくとも1つの寸法は、現在の映像ブロックを有する現在のピクチャの対応する寸法と異なり、前記参照ピクチャは、並置された参照ピクチャとして指定されない、解決策C25に記載の方法。
【0445】
C27. 映像処理のための方法であって、現在の映像ブロックを予測するために、並置されたブロックに関連付けられた並置された参照ピクチャの寸法と、現在の映像ブロックを有する現在のピクチャの寸法との比較に基づいて、並置されたブロックを識別することと、識別に基づいて、現在の映像ブロックの予測を実行することと、を有する、方法。
【0446】
C28. 予測は、時間的動きベクトル予測処理またはATMVP(AlternativeTemporal Motion Vector Prediction)処理を有する、解決策C27に記載の方法。
【0447】
C29. 現在のピクチャは寸法W0×H0を有し、並置された参照ピクチャは寸法W1×H1を有し、並置されたブロックの位置またはサイズは、W0、H0、W1、またはH1のうちの少なくとも1つに基づく、解決策C27またはC28に記載の方法。
【0448】
C30. ATMVP処理における時間的動きベクトルの導出は、W0、H0、W1、またはH1のうちの少なくとも1つに基づく、解決策C29に記載の方法。
【0449】
C31. 現在の映像ブロックのための動きベクトル予測の導出は、W0、H0、W1、またはH1のうちの少なくとも1つに基づく、解決策C29に記載の方法。
【0450】
C32. ARC処理に関する情報は、1または複数のアップサンプリングまたはダウンサンプリングフィルタリング方法のためのパラメータを有する、解決策C1に記載の方法。
【0451】
C33. ARC処理に関する情報は、CVS(Coded Video Sequence)内での解像度の変更を可能にするように、参照ピクチャをスケーリングするための水平方向のスケーリング係数または垂直方向のスケーリング係数を有する、解決策C1に記載の方法。
【0452】
C34. 情報は、DPS(Decoder Parameter Set)、VPS(Video Parameter Set)、SPS(Sequence Parameter Set)、PPS(Picture Parameter Set)、APS(Adaptive Parameter Set)、ピクチャヘッダ、スライスヘッダ、タイルグループヘッダ、または個々の映像ユニットにて信号通知される、解決策C32またはC33に記載の方法。
【0453】
C35. 個々の映像ユニットは、RPS(Resolution Parameter Set)またはCPS(Conversion Parameter Set)である、解決策C34に記載の方法。
【0454】
C36. プロセッサと、命令を有する非一時的メモリとを有する、映像システムにおける装置であって、命令は、プロセッサにより実行されることにより、プロセッサに、解決策C1~C35のいずれかに記載の方法を実施させる装置。
【0455】
C37. 非一時的コンピュータ可読媒体に記憶されたコンピュータプログラムプロダクトであって、解決策C1~C35のいずれかに記載の方法を実行するためのプログラムコードを含む、コンピュータプログラムプロダクト。
【0456】
以上、説明の目的で本開示の技術の特定の実施形態を説明したが、本発明の範囲から逸脱することなく様々な修正が可能であることは、理解されるであろう。従って、本開示の技術は、添付の特許請求の範囲による場合を除き、限定されない。
【0457】
本特許明細書に記載された主題および機能操作の実装形態は、本明細書に開示された構造およびその構造的等価物を含め、様々なシステム、デジタル電子回路、またはコンピュータソフトウェア、ファームウェア、若しくはハードウェアで実施されてもよく、またはそれらの1または複数の組み合わせで実施してもよい。本明細書に記載された主題の実装形態は、1または複数のコンピュータプログラムプロダクト、すなわち、データ処理装置によって実行されるため、またはデータ処理装置の動作を制御するために、有形で非可搬性のコンピュータ可読媒体上に符号化されたコンピュータプログラム命令の1または複数のモジュールとして実装することができる。このコンピュータ可読媒体は、機械可読記憶装置、機械可読記憶基板、メモリデバイス、機械可読伝播信号をもたらす物質の組成物、またはこれらの1または複数の組み合わせであってもよい。「データ処理ユニット」または「データ処理装置」という用語は、例えば、プログラマブルプロセッサ、コンピュータ、または複数のプロセッサ若しくはコンピュータを含み、データを処理するためのすべての装置、デバイス、および機械を含む。装置は、ハードウェアの他に、当該コンピュータプログラムの実行環境を作るコード、例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、またはこれらの1または複数の組み合わせを構成するコードを含むことができる。
【0458】
コンピュータプログラム(プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとも呼ばれる)は、コンパイルされた言語または解釈された言語を含む任意の形式のプログラミング言語で記述することができ、また、それは、スタンドアロンプログラムとして、またはコンピューティング環境で使用するのに適したモジュール、コンポーネント、サブルーチン、または他のユニットとして含む任意の形式で展開することができる。コンピュータプログラムは、必ずしもファイルシステムにおけるファイルに対応するとは限らない。プログラムは、他のプログラムまたはデータを保持するファイルの一部(例えば、マークアップ言語文書に格納された1または複数のスクリプト)に記録されていてもよいし、当該プログラム専用の単一のファイルに記憶されていてもよいし、複数の調整ファイル(例えば、1または複数のモジュール、サブプログラム、またはコードの一部を格納するファイル)に記憶されていてもよい。コンピュータプログラムを、1つのサイトに位置する1つのコンピュータ、または複数のサイトに分散され通信ネットワークによって相互接続される複数のコンピュータで実行させるように展開することも可能である。
【0459】
本明細書に記載された処理およびロジックフローは、入力データ上で動作し、出力を生成することによって機能を実行するための1または複数のコンピュータプログラムを実行する1または複数のプログラマブルプロセッサによって行うことができる。処理およびロジックフローはまた、特定用途のロジック回路、例えば、FPGA(Field Programmable Gate Array)またはASIC(Application Specific Integrated Circuit)によって実行することができ、装置はまた、特別目的のロジック回路として実装することができる。
【0460】
コンピュータプログラムの実行に適したプロセッサは、例えば、汎用および専用マイクロプロセッサの両方、並びに任意の種類のデジタルコンピュータの任意の1または複数のプロセッサを含む。一般的に、プロセッサは、読み出し専用メモリまたはランダムアクセスメモリまたはその両方から命令およびデータを受信する。コンピュータの本質的な要素は、命令を実行するためのプロセッサと、命令およびデータを記憶するための1または複数のメモリ装置とである。一般的に、コンピュータは、データを記憶するための1または複数の大容量記憶デバイス、例えば、磁気、光磁気ディスク、または光ディスクを含んでもよく、またはこれらの大容量記憶デバイスからデータを受信するか、またはこれらにデータを転送するように動作可能に結合されてもよい。しかしながら、コンピュータは、このようなデバイスを有する必要はない。コンピュータプログラム命令およびデータを記憶するのに適したコンピュータ可読媒体は、あらゆる形式の不揮発性メモリ、媒体、およびメモリデバイスを含み、例えば、EPROM、EEPROM、フラッシュメモリデバイス等の半導体メモリデバイスを含む。プロセッサおよびメモリは、特定用途のロジック回路によって補完されてもよく、または特定用途のロジック回路に組み込まれてもよい。
【0461】
本明細書は、図面とともに、例示のみを目的とするものであり、例示的とは例を意味することが意図される。本明細書において、「または」の使用は、文脈からそうでないことが明確に示されていない限り、「および/または」を含むことが意図される。
【0462】
本特許明細書は多くの詳細を含むが、これらは、任意の発明の範囲または特許請求の範囲を限定するものと解釈されるべきではなく、むしろ、特定の発明の特定の実施形態に特有であり得る特徴の説明と解釈されるべきである。本明細書において別個の実施形態の文脈で説明されている特定の特徴は、1つの例において組み合わせて実装してもよい。逆に、1つの例のコンテキストで説明された様々な特徴は、複数の実施形態において別個にまたは任意の適切なサブコンビネーションで実装してもよい。さらに、特徴は、特定の組み合わせで作用するものとして上記に記載され、最初にそのように主張されていてもよいが、主張された組み合わせからの1または複数の特徴は、場合によっては、組み合わせから抜粋されることができ、主張された組み合わせは、サブコンビネーションまたはサブコンビネーションのバリエーションに向けられてもよい。
【0463】
同様に、動作は図面において特定の順番で示されているが、これは、所望の結果を達成するために、このような動作が示された特定の順番でまたは連続した順番で行われること、または示された全ての動作が行われることを必要とするものと理解されるべきではない。また、本特許明細書に記載されている例における様々なシステムの構成要素の分離は、全ての実施形態においてこのような分離を必要とするものと理解されるべきではない。
【0464】
いくつかの実装形態および例のみが記載されており、この特許文献に記載され図示されているコンテンツに基づいて、他の実施形態、拡張および変形が可能である。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16A
図16B
図17
図18A
図18B
図19
図20
図21A
図21B
図22
図23
図24A
図24B
図24C
図24D
図24E
図24F
図24G
図24H
図24I
図24J
図25
図26
【手続補正書】
【提出日】2023-04-28
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
映像データの処理の方法であって、
映像のビジュアルメディアデータと、前記映像のビットストリームとの間の変換のために、前記ビジュアルメディアデータに対する第1のコーディングモードに関連づけられた第1の情報を決定することと、
前記第1のコーディングモードに少なくとも基づいて、前記変換を実行することと、
を有し、
前記第1のコーディングモードは、前記ビジュアルメディアデータを含む現在のピクチャの解像度とは異なる1または複数の解像度を有する1または複数の参照ピクチャに基づいて、予測サンプルを導出することを含み、
前記現在のピクチャの前記解像度は、前記第1の情報にて示され、
前記第1の情報は、前記現在のピクチャの幅Wおよび前記現在のピクチャの高さHの少なくとも1つを示し、
前記幅Wは、第1の値の整数倍であり、
前記高さHは、第2の値の整数倍である、方法。
【請求項2】
前記第1の情報は、SPS(Sequence Parameter Set)にて前記ビットストリームに含まれる、請求項1に記載の方法。
【請求項3】
前記第1の情報は、PPS(Picture Parameter Set)にて前記ビットストリームに含まれる、請求項1に記載の方法。
【請求項4】
前記幅Wは、最大値TW_max以下であり、かつ、最小値TW_min以上であり、
前記高さHは、最大値TH_max以下であり、かつ、最小値TH_min以上である、請求項1から3のいずれか一項に記載の方法。
【請求項5】
前記最大値TW_maxおよび/または前記最大値TH_maxは、前記ビットストリームに含まれる、請求項4に記載の方法。
【請求項6】
前記第1の値および前記第2の値はそれぞれ、少なくとも1つの所定の値に基づく、請求項1から5のいずれか一項に記載の方法。
【請求項7】
前記所定の値は、正の整数である、請求項6に記載の方法。
【請求項8】
前記変換は、前記ビジュアルメディアデータを前記ビットストリームに符号化することを含む、請求項1から7のいずれか一項に記載の方法。
【請求項9】
前記変換は、前記ビジュアルメディアデータを前記ビットストリームから復号することを含む、請求項1から7のいずれか一項に記載の方法。
【請求項10】
プロセッサと、命令を有する非一時的メモリとを有する、映像データを処理するための装置であって、
前記命令は、前記プロセッサによって実行された際に、前記プロセッサに、
映像のビジュアルメディアデータと、前記映像のビットストリームとの間の変換のために、前記ビジュアルメディアデータに対する第1のコーディングモードに関連づけられた第1の情報を決定することと、
前記第1のコーディングモードに少なくとも基づいて、前記変換を実行することと、
を実行させ、
前記第1のコーディングモードは、前記ビジュアルメディアデータを含む現在のピクチャの解像度とは異なる1または複数の解像度を有する1または複数の参照ピクチャに基づいて、予測サンプルを導出することを含み、
前記現在のピクチャの前記解像度は、前記第1の情報にて示され、
前記第1の情報は、前記現在のピクチャの幅Wおよび前記現在のピクチャの高さHの少なくとも1つを示し、
前記幅Wは、第1の値の整数倍であり、
前記高さHは、第2の値の整数倍である、装置。
【請求項11】
プロセッサに、
映像のビジュアルメディアデータと、前記映像のビットストリームとの間の変換のために、前記ビジュアルメディアデータに対する第1のコーディングモードに関連づけられた第1の情報を決定することと、
前記第1のコーディングモードに少なくとも基づいて、前記変換を実行することと、
を実行させ、
前記第1のコーディングモードは、前記ビジュアルメディアデータを含む現在のピクチャの解像度とは異なる1または複数の解像度を有する1または複数の参照ピクチャに基づいて、予測サンプルを導出することを含み、
前記現在のピクチャの前記解像度は、前記第1の情報にて示され、
前記第1の情報は、前記現在のピクチャの幅Wおよび前記現在のピクチャの高さHの少なくとも1つを示し、
前記幅Wは、第1の値の整数倍であり、
前記高さHは、第2の値の整数倍である、命令を格納する非一時的コンピュータ可読媒体。
【請求項12】
映像処理装置によって実行された方法によって生成されたビットストリームを格納する非一時的コンピュータ可読記録媒体であって、
前記方法は、
映像のビジュアルメディアデータに対する第1のコーディングモードに関連づけられた第1の情報を決定することと、
前記第1のコーディングモードに少なくとも基づいて、前記ビジュアルメディアデータから前記ビットストリームを生成することと、
を有し、
前記第1のコーディングモードは、前記ビジュアルメディアデータを含む現在のピクチャの解像度とは異なる1または複数の解像度を有する1または複数の参照ピクチャに基づいて、予測サンプルを導出することを含み、
前記現在のピクチャの前記解像度は、前記第1の情報にて示され、
前記第1の情報は、前記現在のピクチャの幅Wおよび前記現在のピクチャの高さHの少なくとも1つを示し、
前記幅Wは、第1の値の整数倍であり、
前記高さHは、第2の値の整数倍である、非一時的コンピュータ可読記録媒体。
【手続補正2】
【補正対象書類名】明細書
【補正対象項目名】0001
【補正方法】変更
【補正の内容】
【0001】
関連出願の相互参照
願は、2019年5月12日出願の国際特許出願第PCT/CN2019/086513号の優先権および利益主張する、2020年5月12日出願の国際特許出願第PCT/CN2020/089740号に基づく。上記出願の開示全体は、照によりここに援用される。
【外国語明細書】