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

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

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

特許7518216異なるコーディングブロックサイズを有するインターレイヤ予測
<>
  • 特許-異なるコーディングブロックサイズを有するインターレイヤ予測 図1
  • 特許-異なるコーディングブロックサイズを有するインターレイヤ予測 図2
  • 特許-異なるコーディングブロックサイズを有するインターレイヤ予測 図3
  • 特許-異なるコーディングブロックサイズを有するインターレイヤ予測 図4
  • 特許-異なるコーディングブロックサイズを有するインターレイヤ予測 図5
  • 特許-異なるコーディングブロックサイズを有するインターレイヤ予測 図6
  • 特許-異なるコーディングブロックサイズを有するインターレイヤ予測 図7
  • 特許-異なるコーディングブロックサイズを有するインターレイヤ予測 図8
  • 特許-異なるコーディングブロックサイズを有するインターレイヤ予測 図9
  • 特許-異なるコーディングブロックサイズを有するインターレイヤ予測 図10
  • 特許-異なるコーディングブロックサイズを有するインターレイヤ予測 図11
  • 特許-異なるコーディングブロックサイズを有するインターレイヤ予測 図12
  • 特許-異なるコーディングブロックサイズを有するインターレイヤ予測 図13
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-07-08
(45)【発行日】2024-07-17
(54)【発明の名称】異なるコーディングブロックサイズを有するインターレイヤ予測
(51)【国際特許分類】
   H04N 19/70 20140101AFI20240709BHJP
   H04N 19/109 20140101ALI20240709BHJP
   H04N 19/174 20140101ALI20240709BHJP
【FI】
H04N19/70
H04N19/109
H04N19/174
【請求項の数】 13
(21)【出願番号】P 2022578766
(86)(22)【出願日】2021-06-16
(65)【公表番号】
(43)【公表日】2023-07-20
(86)【国際出願番号】 CN2021100316
(87)【国際公開番号】W WO2021254379
(87)【国際公開日】2021-12-23
【審査請求日】2022-12-27
(31)【優先権主張番号】PCT/CN2020/097293
(32)【優先日】2020-06-20
(33)【優先権主張国・地域又は機関】CN
(73)【特許権者】
【識別番号】520476341
【氏名又は名称】北京字節跳動網絡技術有限公司
【氏名又は名称原語表記】Beijing Bytedance Network Technology Co., Ltd.
【住所又は居所原語表記】Room B-0035, 2/F, No.3 Building, No.30, Shixing Road, Shijingshan District Beijing 100041 China
(73)【特許権者】
【識別番号】520477474
【氏名又は名称】バイトダンス インコーポレイテッド
【氏名又は名称原語表記】BYTEDANCE INC.
【住所又は居所原語表記】12655 West Jefferson Boulevard, Sixth Floor, Suite No. 137 Los Angeles, California 90066 United States of America
(74)【代理人】
【識別番号】110002000
【氏名又は名称】弁理士法人栄光事務所
(72)【発明者】
【氏名】ドン ジピン
(72)【発明者】
【氏名】ジャン リー
【審査官】田中 純一
(56)【参考文献】
【文献】特表2023-528775(JP,A)
【文献】国際公開第2021/249994(WO,A1)
【文献】Robert Skupin, et al.,AHG9: Miscellaneous cleanups [online], JVET-S JVET-S0174,ITU-T インターネット<URL:https://jvet-experts.org/doc_end_user/documents/19_Teleconference/wg11/JVET-S0174-v1.zip>,2020年06月10日,pp.1-4
【文献】Ye-Kui Wang, et al.,AHG9: Cleanups on RPL and related signalling [online], JVET-R JVET-R0059-v1,ITU-T インターネット<URL:https://jvet-experts.org/doc_end_user/documents/18_Alpbach/wg11/JVET-R0059-v1.zip>,2020年04月02日,pp.1-11
(58)【調査した分野】(Int.Cl.,DB名)
H04N 7/12
H04N 19/00 - 19/98
(57)【特許請求の範囲】
【請求項1】
映像データの処理の方法であって、
規則に従って、映像の現在のピクチャの映像ユニットと、前記映像のビットストリームとの間の変換を実行することを有し、
前記規則は、動き情報が前記変換のために用いられる同一位置の参照ピクチャとして利用可能とすべき所与のピクチャに対し、前記所与のピクチャが、前記現在のピクチャと同じコーディングツリーユニットサイズまたは同じコーディングツリーブロックサイズを有することを規定し、
前記規則は、前記所与のピクチャが異なるコーディングツリーユニットサイズまたは異なるコーディングツリーブロックサイズを有することに応じて、前記動き情報を使用するコーディングツールが無効であることを規定し、
前記コーディングツールは、時間的動きベクトル予測コーディングツール、または、サブブロックベースの時間的動きベクトル予測コーディングツールであり、
ピクチャヘッダの第4の構文フラグが、前記動き情報の使用が無効であることを規定している場合、前記同一位置の参照ピクチャが参照ピクチャリスト0または参照ピクチャリスト1から導出されることを規定する第1の構文フラグ、および、前記同一位置の参照ピクチャの参照インデックスは、前記ビットストリームから省略され、
前記第1の構文フラグは、sh_collocated_from_l0_flagまたはph_collocated_from_l0_flagとして示され、
前記参照インデックスは、sh_collocated_ref_idxまたはph_collocated_ref_idxとして示される、方法。
【請求項2】
前記映像ユニットは、スライスである、請求項に記載の方法。
【請求項3】
前記同一位置の参照ピクチャは、同一位置の参照ピクチャのリスト、および、前記同一位置の参照ピクチャの参照インデックスを規定するインデックスにより識別される、請求項1または2に記載の方法。
【請求項4】
前記同一位置の参照ピクチャのリストは、前記同一位置の参照ピクチャが、参照ピクチャリスト0または参照ピクチャリスト1から導出されるか否かを規定する第1の構文フラグによって決定される、請求項に記載の方法。
【請求項5】
前記第1の構文フラグは、sh_collocated_from_l0_flagとして表され、
前記参照インデックスは、sh_collocated_ref_idxとして表される、請求項に記載の方法。
【請求項6】
前記参照インデックスによって参照される前記同一位置の参照ピクチャに対する各コーディングツリーユニットを規定する第2の構文要素は、前記現在のピクチャに対する各コーディングツリーユニットのサイズを規定する第3の構文要素の値と等しい、請求項に記載の方法。
【請求項7】
前記第2の構文要素および前記第3の構文要素は、シーケンスパラメータセットに含まれ、sps_log2_ctu_size_minus5として表される、請求項に記載の方法。
【請求項8】
前記第4の構文フラグは、ph_temporal_mvp_enabled_flagとして表される、請求項に記載の方法。
【請求項9】
前記変換は、前記映像を前記ビットストリームに符号化することを含む、請求項1からのいずれか一項に記載の方法。
【請求項10】
前記変換は、前記映像を前記ビットストリームから復号することを含む、請求項1からのいずれか一項に記載の方法。
【請求項11】
プロセッサと、命令を有する非一時的メモリを備える、映像データを処理するための装置であって、
前記プロセッサにより前記命令が実行された際に、前記プロセッサに、
規則に従って、映像の現在のピクチャの映像ユニットと、前記映像のビットストリームとの間の変換を実行すること、
を実行させ、
前記規則は、動き情報が前記変換のために用いられる同一位置の参照ピクチャとして利用可能とすべき所与のピクチャに対し、前記所与のピクチャが、前記現在のピクチャと同じコーディングツリーユニットサイズまたは同じコーディングツリーブロックサイズを有することを規定し、
前記規則は、前記所与のピクチャが異なるコーディングツリーユニットサイズまたは異なるコーディングツリーブロックサイズを有することに応じて、前記動き情報を使用するコーディングツールが無効であることを規定し、
前記コーディングツールは、時間的動きベクトル予測コーディングツール、または、サブブロックベースの時間的動きベクトル予測コーディングツールであり、
ピクチャヘッダの第4の構文フラグが、前記動き情報の使用が無効であることを規定している場合、前記同一位置の参照ピクチャが参照ピクチャリスト0または参照ピクチャリスト1から導出されることを規定する第1の構文フラグ、および、前記同一位置の参照ピクチャの参照インデックスは、前記ビットストリームから省略され、
前記第1の構文フラグは、sh_collocated_from_l0_flagまたはph_collocated_from_l0_flagとして示され、
前記参照インデックスは、sh_collocated_ref_idxまたはph_collocated_ref_idxとして示される、装置。
【請求項12】
プロセッサに、
規則に従って、映像の現在のピクチャの映像ユニットと、前記映像のビットストリームとの間の変換を実行すること、
を実行させ、
前記規則は、動き情報が前記変換のために用いられる同一位置の参照ピクチャとして利用可能とすべき所与のピクチャに対し、前記所与のピクチャが、前記現在のピクチャと同じコーディングツリーユニットサイズまたは同じコーディングツリーブロックサイズを有することを規定し、
前記規則は、前記所与のピクチャが異なるコーディングツリーユニットサイズまたは異なるコーディングツリーブロックサイズを有することに応じて、前記動き情報を使用するコーディングツールが無効であることを規定し、
前記コーディングツールは、時間的動きベクトル予測コーディングツール、または、サブブロックベースの時間的動きベクトル予測コーディングツールであり、
ピクチャヘッダの第4の構文フラグが、前記動き情報の使用が無効であることを規定している場合、前記同一位置の参照ピクチャが参照ピクチャリスト0または参照ピクチャリスト1から導出されることを規定する第1の構文フラグ、および、前記同一位置の参照ピクチャの参照インデックスは、前記ビットストリームから省略され、
前記第1の構文フラグは、sh_collocated_from_l0_flagまたはph_collocated_from_l0_flagとして示され、
前記参照インデックスは、sh_collocated_ref_idxまたはph_collocated_ref_idxとして示される、命令を格納する非一時的コンピュータ可読記憶媒体。
【請求項13】
映像処理装置によって実行された方法によって生成された映像のビットストリームを格納するための方法であって、
規則に従って、前記映像のビットストリームを前記映像の現在のピクチャの映像ユニットから生成することと、
前記ビットストリームを非一時的コンピュータ可読記録媒体に格納することと、
を有し、
前記規則は、動き情報が前記生成のために用いられる同一位置の参照ピクチャとして利用可能とすべき所与のピクチャに対し、前記所与のピクチャが、前記現在のピクチャと同じコーディングツリーユニットサイズまたは同じコーディングツリーブロックサイズを有することを規定し、
前記規則は、前記所与のピクチャが異なるコーディングツリーユニットサイズまたは異なるコーディングツリーブロックサイズを有することに応じて、前記動き情報を使用するコーディングツールが無効であることを規定し、
前記コーディングツールは、時間的動きベクトル予測コーディングツール、または、サブブロックベースの時間的動きベクトル予測コーディングツールであり、
ピクチャヘッダの第4の構文フラグが、前記動き情報の使用が無効であることを規定している場合、前記同一位置の参照ピクチャが参照ピクチャリスト0または参照ピクチャリスト1から導出されることを規定する第1の構文フラグ、および、前記同一位置の参照ピクチャの参照インデックスは、前記ビットストリームから省略され、
前記第1の構文フラグは、sh_collocated_from_l0_flagまたはph_collocated_from_l0_flagとして示され、
前記参照インデックスは、sh_collocated_ref_idxまたはph_collocated_ref_idxとして示される、方法。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
願は、2020年6月20日出願の国際特許出願第PCT/CN2020/097293号の優先権および利益を張する、2021年6月16日出願の国際特許出願第PCT/CN2021/100316号の国内段階である。上記出願の開示全体は、本明細書の開示の一部として参照により援用される。
【0002】
この特許明細書は、画像および映像の符号化および復号に関する。
【背景技術】
【0003】
デジタル映像は、インターネットおよび他のデジタル通信ネットワークにおいて最大の帯域幅の使用量を占めている。映像を受信および表示することが可能である接続されたユーザ機器の数が増加するにつれ、デジタル映像の使用に対する帯域幅需要は増大し続けることが予測される。
【発明の概要】
【0004】
本願は、コーディングされた表現の復号に有用な制御情報を使用して、映像のコーディングされた表現を処理するために、映像エンコーダおよびデコーダにより使用され得る技術を開示する。
【0005】
1つの例示的な態様において、映像データを処理する方法は、規則に従って、映像の現在の映像ユニットと映像のビットストリームとの間の変換を実行することを含み、規則は、所与のピクチャが、動き情報が変換に用いられる参照ピクチャとして利用可能であるために、所与のピクチャが現在のピクチャと同じコーディングツリーユニットサイズまたは同じコーディングツリーブロックサイズを有することを規定する。
【0006】
別の例示的な態様において、映像処理方法が開示される。方法は、1または複数の映像ピクチャを含む映像との間の変換を実行することを含み、コーディングされた表現はフォーマット規則に準拠し、フォーマット規則は、シーケンスパラメータセットにおける2つ以上の構文フィールドが映像のRPR(Reference Picture Resolution)の変更を制御することを規定する。
【0007】
別の例示的な態様において、別の映像処理方法が開示される。方法は、1または複数の映像ピクチャを含む映像との変換を実行することを含み、コーディングされた表現はフォーマット規則に準拠し、フォーマット規則は、シーケンスパラメータセットにおける1つの構文フィールドが映像のRPR(Reference Picture Resolution)の変更を制御することを規定し、フォーマット規則は、単一の構文フィールドの値に関わらず、レイヤ間参照ピクチャのリサンプリングが変換に対して許可されることを規定する。
【0008】
別の例示的な態様において、別の映像処理方法が開示される。方法は、1または複数のサブピクチャを有する1または複数の映像ピクチャを有する1または複数のレイヤを含む映像との間で変換を実行することを含み、コーディングされた表現は、フォーマット規則に準拠し、フォーマット規則は、クロスレイヤアライメントに対する第1の制約、または、サブピクチャの組合せおよびインターレイヤピクチャのスケーラビリティに対する第2の制約を規定する。
【0009】
別の例示的な態様において、別の映像処理方法が開示される。方法は、1または複数のサブピクチャを有する1または複数の映像ピクチャを有する1または複数のレイヤを含む映像との間で変換を行うことを含み、変換は、インターレイヤ参照ピクチャまたは長期参照ピクチャが現在のピクチャの同一位置のピクチャであることを変換に対して許可されないことを規定するフォーマット規則に準拠する。
【0010】
別の例示的な態様において、別の映像処理方法が開示される。方法は、複数のピクチャを有する映像と、映像のコーディングされた表現との間の変換を実行することを含み、変換は、scaling_win_left_offset、scaling_win_right_offset、scaling_win_top_offset、およびscaling_win_bottom_offsetのそれぞれの値が、pic_width_in_luma_samplesおよびpic_height_in_luma_samplesの同じ値を有する、同じコーディングされたレイヤ映像シーケンスまたはコーディングされた映像シーケンス内の2つのピクチャに対して同じであることを規定する規則に準拠する。
【0011】
別の例示的な態様において、別の映像処理方法が開示される。方法は、複数のピクチャを含む映像と映像のコーディングされた表現との間の変換を実行することを含み、変換は、同じアクセスユニット内の現在のピクチャと他のピクチャとでピクチャの解像度またはスケーリングウィンドウが異なる場合、現在のピクチャがイントラランダムアクセスポイントピクチャである場合にのみ、インターレイヤ予測を許可することを規定する規則に準拠する。
【0012】
別の例示的な態様において、別の映像処理方法が開示される。方法は、映像の現在のピクチャの映像ブロックと映像のコーディングされた表現との間の変換のために、同一位置の映像ピクチャまたはインターレイヤピクチャの映像ブロックの第2のサイズと比較した映像ブロックの第1のサイズに基づいて規則を適用するかどうかを決定することと、決定に基づいて変換を実行することと、を含む。
【0013】
さらに別の例示的な態様において、映像エンコーダ装置が開示される。この映像エンコーダは、上述した方法を実装するように構成されたプロセッサを備える。
【0014】
さらに別の例示的な態様において、映像デコーダ装置が開示される。この映像デコーダは、上述した方法を実装するように構成されたプロセッサを備える。
【0015】
さらに別の例示的な態様では、コードが記憶されたコンピュータ可読媒体が開示される。このコードは、本明細書に記載の方法の1つをプロセッサが実行可能なコードの形式で実施する。
【0016】
これらのおよび他の特徴は、本文書全体にわたって説明される。
【図面の簡単な説明】
【0017】
図1】ピクチャのラスタスキャンスライス分割の例を示し、ピクチャは、12個のタイルと3個のラスタスキャンスライスとに分割される。
図2】ピクチャの矩形スライス分割の例を示し、ピクチャは、24個のタイル(6個のタイル列および4個のタイル行)と9個の矩形スライスとに分割される。
図3】タイルおよび矩形のスライスに分割されたピクチャの例を示し、ピクチャは、4つのタイル(2つのタイルの列および2つのタイルの行)と4つの矩形スライスとに分割される。
図4】15個のタイル、24個のスライス、および24個のサブピクチャに分割されたピクチャを示す。
図5】映像処理システム例を示すブロック図である。
図6】映像処理装置のブロック図である。
図7】映像処理方法の一例を示すフローチャートである。
図8】本開示のいくつかの実施形態による映像コーディングシステムを示すブロック図である。
図9】本開示のいくつかの実施形態によるエンコーダを示すブロック図である。
図10】本開示のいくつかの実施形態によるデコーダを示すブロック図である。
図11】典型的なサブピクチャに基づくビューポートに依存する360°映像コーディング方式の例を示す。
図12】サブピクチャおよび空間的スケーラビリティに基づくビューポート依存型360°映像コーディング方式を示す。
図13】本技術の1または複数の実施形態による映像処理の方法を表すフローチャートである。
【発明を実施するための形態】
【0018】
本明細書では、理解を容易にするために章の見出しを使用しており、その技術および各章に記載された実施形態の適用可能性をその章のみに限定するものではない。さらに、H.266という用語は、ある説明において、理解を容易にするためだけに用いられ、開示される技術の範囲を限定するために用いられたものではない。このように、本明細書で説明される技術は、他の映像コーデックプロトコルおよび設計にも適用可能である。本明細書において、編集変更は、VVC規格の現在の草案に対して、取り消されたテキストを示す取り消し線および付加されたテキストを示すハイライト(太字のイタリック体を含む)によってテキストに示す。
【0019】
1. 概要
本明細書は、映像コーディング技術に関する。具体的には、1)参照ピクチャのRPR(Reference Picture Resampling)、サブピクチャ、および映像コーディングにおけるスケーラビリティのうちの2つ以上の組み合わせ、2)現在のピクチャと、同じ空間的解像度を有する参照ピクチャとの間でのRPRの使用、および3)長期参照ピクチャと、同一位置のピクチャとの組み合わせ、である。この考えは、個々にまたは様々な組み合わせで、マルチレイヤ映像コーディング、例えば、現在開発されているVVC(Versatile Video Coding)をサポートする任意の映像コーディング標準または非標準映像コーデックに適用されてもよい。
【0020】
2. 略語
APS Adaptation Parameter Set
AU Access Unit
AUD Access Unit Delimiter
AVC Advanced Video Coding
CLVS Coded Layer Video Sequence
CCALF Cross-Component Adaptive Loop Filter
CPB Coded Picture Buffer
CRA Clean Random Access
CTU Coding Tree Unit
CVS Coded Video Sequence
DCI Decoding Capability Information
DPB Decoded Picture Buffer
EOB End Of Bitstream
EOS End Of Sequence
GDR Gradual Decoding Refresh
HEVC High Efficiency Video Coding
HRD Hypothetical Reference Decoder
IDR Instantaneous Decoding Refresh
ILP Inter-Layer Prediction
ILRP Inter-Layer Reference Picture
IRAP Intra Random Access Picture
JEM Joint Exploration Model
LTRP Long-Term Reference Picture
MCTS Motion-Constrained Tile Sets
NAL Network Abstraction Layer
OLS Output Layer Set
PH Picture Header
PPS Picture Parameter Set
PTL Profile,Tier and Level
PU Picture Unit
RAP Random Access Point
RBSP Raw Byte Sequence Payload
SEI Supplemental Enhancement Information
SPS Sequence Parameter Set
STRP Short-Term Reference Picture
SVC Scalable Video Coding
VCL Video Coding Layer
VPS Video Parameter Set
VTM VVC Test Model
VUI Video Usability Information
VVC Versatile Video Coding
【0021】
3. 初期の協議
映像コーディング規格は、主に周知のITU-TおよびISO/IEC規格の開発によって発展してきた。ITU-TはH.261とH.263を作り、ISO/IECはMPEG-1とMPEG-4Visualを作り、両団体はH.262/MPEG-2VideoとH.264/MPEG-4AVC(Advanced Video Coding)とH.265/HEVC規格を共同で作った。H.262以来、映像コーディング規格は、時間的予測と変換コーディングが利用されるハイブリッド映像コーディング構造に基づく。HEVCを超えた将来の映像コーディング技術を探索するため、2015年には、VCEGとMPEGが共同でJVET(Joint Video Exploration Team)を設立した。それ以来、多くの新しい方法がJVETによって採用され、JEM(Joint Exploration Model)と呼ばれる参照ソフトウェアに組み込まれてきた。JVETは四半期に1回開催され、新しいコーディング規格はHEVCに比べて50%のビットレート低減を目指している。2018年4月のJVET会議において、新しい映像コーディング規格を「VVC(Versatile Video Coding)」と正式に命名し、その時、第1版のVTM(VVC Test Model)をリリースした。VVCの標準化に寄与する努力が続けられているので、すべてのJVET会議において、VVC標準に新しいコーディング技術が採用されている。毎回の会議の後、VVC作業草案およびテストモデルVTMを更新する。VVCプロジェクトは、現在、2020年7月の会合における技術完成(FDIS)を目指している。
【0022】
3.1 HEVCにおけるピクチャ分割スキーム
HEVCには、正規のスライス、従属スライス、タイル、WPP(Wavefront Parallel Processing)という4つの異なるピクチャ分割スキームがあり、これらを適用することで、MTU(Maximum Transfer Unit)サイズのマッチング、並列処理、エンドツーエンドの遅延の低減が可能になる。
【0023】
正規のスライスは、H.264/AVCと同様である。各正規のスライスは、それ自体のNALユニットにカプセル化され、スライス境界にわたるインピクチャ予測(イントラサンプル予測、動き情報予測、コーディングモード予測)およびエントロピーコーディング依存性は無効化される。このように、1つの正規のライスを、同じピクチャ内の他の正規のスライスとは独立して再構成することができる(しかし、ループフィルタリング動作のために依然として相互依存性がある場合がある)。
【0024】
正規のスライスは、並列化に使用できる唯一のツールであり、H.264/AVCでもほぼ同じ形式で使用できる。正規のスライスに基づく並列化は、プロセッサ間通信またはコア間通信をあまり必要としない(予測コーディングされたピクチャを復号するとき、動き補償のためのプロセッサ間またはコア間データ共有を除いて、通常、インピクチャ予測のためにプロセッサ間またはコア間データ共有よりもはるかに重い)。しかしながら、同じ理由で、正規のスライスを使用すると、スライスヘッダのビットコストおよびスライス境界にわたる予測が欠如していることに起因して、コーディングのオーバーヘッドが大きくなる可能性がある。さらに、正規のスライスは(後述の他のツールとは対照的に)、正規のスライスのインピクチャの独立性および各正規のスライスがそれ自体のNALユニットにカプセル化されることに起因して、MTUサイズ要件に適応するようにビットストリームを分割するための鍵となるメカニズムとしても機能する。多くの場合、並列化の目標およびMTUサイズマッチングの目標は、ピクチャにおけるスライスレイアウトに矛盾する要求を課す。このような状況を実現したことにより、以下のような並列化ツールが開発された。
【0025】
従属スライスは、ショートスライスヘッダを有し、インピクチャ予測を一切中断することなく、ツリーブロック境界でビットストリームを分割することを可能にする。基本的に、従属スライスは、正規のスライスを複数のNALユニットに断片化し、正規のスライス全体のエンコーディングが完了する前に正規のスライスの一部を送出することを可能にすることによって、エンドツーエンド遅延を低減する。
【0026】
WPPにおいて、ピクチャは、単一行のCTB(Coding Tree Block)に分割される。エントロピー復号および予測は、他の分割におけるCTBからのデータを使用することを許可される。CTB行の並列復号によって並列処理が可能であり、1つのCTB行の復号の開始が2つのCTBだけ遅延され、それによって、対象のCTBが復号される前に、対象のCTBの上および右のCTBに関するデータが確実に利用可能になる。この互い違いのスタート(グラフで表される場合、波面のように見える)を使用することで、ピクチャがCTB行を含む数までのプロセッサ/コアを用いて並列化することが可能である。ピクチャ内の近傍のツリーブロック行間のインピクチャ予測が許可されるので、インピクチャ予測を可能にするために必要なプロセッサ間/コア間通信は十分となり得る。WPP分割は、適用されない場合と比較して、追加のNALユニットの生成をもたらさず、従って、WPPは、MTUサイズマッチングのためのツールではない。しかし、MTUサイズのマッチングが必要な場合、一定のコーディングオーバーヘッドを伴って、WPPで正規のスライスを使用することができる。
【0027】
タイルは、ピクチャをタイルの列および行に分割する水平および垂直境界を規定する。タイルの列は、ピクチャの上から下へと延びている。同様に、タイルの行は、ピクチャの左から右に延びる。ピクチャにおけるタイルの数は、単にタイルの列の数にタイル行の数を乗算することで得ることができる。
【0028】
CTBのスキャン順序は、タイル内でローカルになるように(タイルのCTBラスタスキャンの順に)変更され、その後、ピクチャのタイルラスタスキャンの順で、次のタイルの左上のCTBを復号する。正規のスライスと同様に、タイルは、インピクチャ予測の依存性およびエントロピー復号の依存性を損なう。しかしながら、これらは、個々のNALユニットに含まれる必要がなく(この点でWPPと同じ)、従って、タイルは、MTUサイズマッチングに使用できない。各タイルは、1つのプロセッサ/コアによって処理されてもよく、近傍のタイルを復号する処理ユニット間のインピクチャ予測に必要なプロセッサ間/コア間通信は、スライスが2つ以上のタイルにまたがっている場合の共有されたスライスヘッダの伝達、および、再構築されたサンプルおよびメタデータの関連する共有をループフィルタリングすることに制限されてよい。スライスに2つ以上のタイルまたはWPPセグメントが含まれる場合、スライスにおける、最初以外の各タイル、または、WPPセグメントに対するエントリポイントバイトオフセットが、スライスヘッダにおいて信号通知される。
【0029】
説明を簡単にするために、HEVCにおいては、4つの異なるピクチャ分割方式の適用に関する制限が規定されている。所与のコーディングされた映像シーケンスは、HEVCに指定されたプロファイルのほとんどについて、タイルと波面(wavefront)の両方を含むことができない。各スライスおよびタイルについて、以下の条件のいずれかまたは両方を満たさなければならない。1)スライスにおけるすべてのコーディングされたツリーブロックは、同じタイルに属し、2)タイルにおけるすべてのコーディングされたツリーブロックは、同じスライスに属する。最後に、波面セグメントはちょうど1つのCTB行を含み、WPPが使用されている際に、スライスがCTB行内で始まる場合、同じCTB行で終わらなければならない。
【0030】
最近のHEVCの修正により、HEVCは、3つのMCTS関連SEIメッセージ、即ち、時間MCTS SEIメッセージ、MCTS抽出情報セットSEIメッセージ、およびMCTS抽出情報ネスティングSEIメッセージを特定する。
【0031】
時間的MCTS SEIメッセージは、ビットストリーム中にMCTSが存在することを示し、MCTSに信号送信する。各MCTSに対し、動きベクトルは、MCTS内部のフルサンプル位置と、補間のためにMCTS内部のフルサンプル位置のみを必要とするフラクショナルサンプル位置とを指すように制限され、かつ、MCTS外部のブロックから導出された時間動きベクトル予測のための動きベクトル候補の使用は許可されない。このように、各MCTSは、MCTSに含まれていないタイルが存在せず、独立して復号されてもよい。
【0032】
MCTS抽出情報セットSEIメッセージは、MCTSサブビットストリーム抽出(SEIメッセージの意味の一部として規定される)において使用され得る補足情報を提供し、MCTSセットのための適合ビットストリームを生成する。この情報は、複数の抽出情報セットを含み、各抽出情報セットは、複数のMCTSセットを定義し、MCTSサブビットストリーム抽出処理において使用される代替VPS、SPS、およびPPSのRBSPバイトを含む。MCTSサブビットストリーム抽出プロセスによってサブビットストリームを抽出する場合、パラメータセット(VPS,SPS,PPS)を書き換えるかまたは置き換える必要があり、スライスアドレスに関連する構文要素の1つまたは全て(first_slice_segment_in_pic_flagおよびslice_segment_addressを含む)が異なる値となる必要があるため、スライスヘッダはわずかに更新される必要がある。
【0033】
3.2. VVCにおけるピクチャの分割
VVCにおいて、ピクチャは、1または複数のタイル行および1または複数のタイル列に分割される。タイルは、ピクチャの矩形領域を覆うCTUのシーケンスである。タイルにおけるCTUは、そのタイル内でラスタスキャン順にスキャンされる。
【0034】
スライスは、ピクチャのタイル内において、整数個の完全なタイルまたは整数個の連続した完全なCTU行を含む。
【0035】
スライスの2つのモード、即ちラスタスキャンスライスモードおよび矩形スライスモードに対応している。ラスタスキャンスライスモードにおいて、スライスは、ピクチャのタイルラスタスキャンにおける完全なタイルのシーケンスを含む。矩形スライスモードにおいて、スライスは、ピクチャの矩形領域を集合的に形成する複数の完全なタイル、またはピクチャの矩形領域を集合的に形成する1つのタイルの複数の連続した完全なCTU行のいずれかを含む。矩形スライス内のタイルを、そのスライスに対応する矩形領域内で、タイルラスタスキャンの順にスキャンする。
【0036】
サブピクチャは、ピクチャの矩形領域をまとめて覆う1または複数のスライスを含む。
【0037】
図1は、ピクチャのラスタスキャンスライス分割の例を示し、ピクチャは、12個のタイルと3個のラスタスキャンスライスとに分割される。
【0038】
図2は、ピクチャの矩形スライス分割の例を示し、ピクチャは、24個のタイル(6個のタイル列および4個のタイル行)と9個の矩形スライスとに分割される。
【0039】
図3は、タイルおよび矩形のスライスに分割されたピクチャの例を示し、ピクチャは、4つのタイル(2つのタイルの列および2つのタイルの行)と4つの矩形スライスとに分割される。
【0040】
図4は、ピクチャをサブピクチャで分割する例を示し、ピクチャは、18個のタイルに分割され、左側の12個が、4×4のCTUの1つのスライスをそれぞれ含み、右側の6個のタイルが、2×2のCTUの垂直方向に積み重ねられたスライスをそれぞれ含み、全体で24個のスライスおよび24個の異なる寸法のサブピクチャとなる(各スライスは、サブピクチャ)。
【0041】
3.3 シーケンス内のピクチャ解像度の変更
AVCおよびHEVCにおいて、ピクチャの空間的解像度は、新しいSPSを使用する新しいシーケンスがIRAPピクチャで始まらない限り、変更することができない。VVCは、常にイントラコーディングされるIRAPピクチャを符号化せずに、ある位置のシーケンス内でピクチャの解像度を変更することを可能にする。この特徴は、参照ピクチャが復号されている現在のピクチャと異なる解像度を有する場合、インター予測に使用される参照ピクチャをリサンプリングすることが必要であるため、RPR(Reference Picture Resampling)と称される。
【0042】
スケーリング比は、1/2(参照ピクチャから現在のピクチャへのダウンサンプリングの2倍)以上、8(8倍のアップサンプリング)以下に制限される。参照ピクチャと現在のピクチャとの間の様々なスケーリング比に対処するために、周波数カットオフが異なる3つのリサンプリングフィルタを規定する。3つのセットのリサンプリングフィルタは、それぞれ、1/2~1/1.75、1/1.75~1/1.25、および1/1.25~8の範囲のスケーリング比に適用される。各セットのリサンプリングフィルタは、動き補償補間フィルタの場合と同様に、輝度に対して16個のフェーズを有し、彩度に対して32個のフェーズを有する。実際には、通常のMC補間プロセスは、1/1.25~8の範囲のスケーリング比を有するリサンプリングプロセスの特殊な場合である。水平および垂直スケーリング比は、ピクチャの幅および高さ、並びに参照ピクチャおよび現在のピクチャに対して規定された左、右、上、および下のスケーリングオフセットに基づいて導出される。
【0043】
HEVCとは異なる、この特徴をサポートするためのVVC設計の他の態様は、i)SPSにおいて最大ピクチャ解像度を信号通知する間、SPSの代わりに、PPSにおいてピクチャ解像度および対応する適合性ウィンドウが信号通知される、ii)シングルレイヤビットストリームの場合、各ピクチャストア(1つの復号ピクチャを記憶するためのDPBにおける1つのスロット)は、最大ピクチャ解像度を有する復号ピクチャを記憶するために必要なバッファサイズを占めること、を含む。
【0044】
3.4 全般およびVVCにおけるSVC(Scalable Video Coding)
SVC(Scalable Video Coding、時には、映像コーディングにおけるスケーラビリティとも呼ばれる)は、BL(Base Layer:基本レイヤ)(時には、RL(Reference Layer:参照レイヤ)と呼ばれる)、および1または複数のスケーラブルEL(Enhancement Layer)が使用される映像コーディングを参照する。SVCにおいて、基本レイヤは、基本品質レベルの映像データを担持することができる。1または複数のエンハンスメントレイヤは、例えば、より高い空間的、時間的、および/またはSNR(Signal-to-Noise)レベルをサポートするように、追加の映像データを担持することができる。エンハンスメントレイヤは、前の符号化されたレイヤに対して定義されてもよい。例えば、下層がBLとして機能し、上層がELとして機能してよい。中間レイヤは、ELまたはRLのいずれか、またはその両方として機能してよい。例えば、中間レイヤ(例えば、最下のレイヤでも最上のレイヤでもないレイヤ)は、中間レイヤの下のレイヤ、例えば、基本レイヤまたは任意の介在するエンハンスメントレイヤのためのELであってもよく、同時に、中間レイヤの上の1または複数のエンハンスメントレイヤのためのRLとしての役割を果たす。同様に、HEVC規格のマルチビューまたは3D拡張では、複数のビューが存在してもよく、1つのビューの情報を利用して別のビューの情報をコーディング(例えば、符号化または復号)することができる(例えば、動き推定、動きベクトル予測および/または他の冗長性)。
【0045】
SVCにおいて、エンコーダまたはデコーダで使用されるパラメータは、それらを利用することができるコーディングレベル(例えば、映像レベル、シーケンスレベル、ピクチャレベル、スライスレベル等)に基づいてパラメータセットにグループ分けされる。例えば、ビットストリームにおける異なるレイヤの1または複数のコーディングされた映像シーケンスによって利用できるパラメータは、VPS(Video Parameter Set)に含まれてもよく、コーディングされた映像シーケンスにおける1または複数のピクチャによって利用されるパラメータは、SPS(Sequence Parameter Set)に含まれてもよい。同様に、ピクチャの1または複数のスライスで利用されるパラメータは、PPS(Picture Parameter Set)に含まれてもよく、単一のスライスに固有の他のパラメータは、スライスヘッダに含まれてもよい。同様に、特定のレイヤが所与の時間にどのパラメータセットを使用しているかの指示は、様々なコーディングレベルで提供されてもよい。
【0046】
VVCにおけるRPR(Reference Picture Resampling)のサポートのおかげで、空間的スケーラビリティサポートに必要なアップサンプリングはRPRアップサンプリングフィルタを使用するだけでよいので、追加の信号処理レベルのコーディングツールを必要とせずに、複数のレイヤ、例えば、VVCにおけるSDおよびHD解像度の2つのレイヤを含むビットストリームをサポートするように設計することができる。それにもかかわらず、スケーラビリティサポートのためには、高レベルの構文変更(スケーラビリティをサポートしない場合と比較して)が必要である。スケーラビリティサポートは、VVCバージョン1に規定されている。AVCおよびHEVCの拡張を含む、任意の以前の映像コーディング規格におけるスケーラビリティサポートとは異なり、VVCのスケーラビリティの設計は、シングルレイヤのデコーダの設計にできるだけ適したものにされてきた。マルチレイヤのビットストリームの復号能力は、ビットストリームにシングルレイヤしかなかったかの如く規定される。例えば、DPBサイズのような復号能力は、復号されるビットストリームのレイヤの数に依存しないようで規定される。基本的に、シングルレイヤのビットストリームのために設計されたデコーダは、マルチレイヤのビットストリームを復号することができるようにするために、多くの変更を必要としない。AVCおよびHEVCのマルチレイヤ拡張の設計と比較して、HLSの態様は、ある程度の柔軟性を犠牲にして大幅に簡略化されてきた。例えば、IRAP AUは、CVSに存在する各レイヤのピクチャを含むことが必要である。
【0047】
3.5 サブピクチャに基づくビューポート依存の360°映像ストリーミング
360°映像のストリーミング、すなわち、全方向性映像のストリーミングにおいて、任意の特定の瞬間に、全方向性映像球体全体のサブセット(例えば、現在のビューポート)のみがユーザにレンダリングされ、一方、ユーザは、自分の頭をいつでも回して視線の向きを変更し、その結果、現在のビューポートを変更することができる。クライアント側が現在のビューポートで覆われていない領域を少なくともある程度低品質に表現し、かつユーザにレンダリングする準備ができていることが望ましいが、ユーザが突然その視線方向を球面上の任意の場所に変えた場合に備えて、すぐにユーザにレンダリングされている現在のビューポートに対してのみ、全方向性映像の高品質表現が必要となる。全方位映像全体の高品質表現を適切な粒度でサブピクチャに分割することにより、このような最適化が有効化される。VVCを使用して、2つの表現は、互いに独立した2つのレイヤとして符号化され得る。
【0048】
典型的なサブピクチャに基づくビューポートに依存する360°の映像配信方式が図11に示されており、ここでは、フル映像のより高い解像度の表現がサブピクチャからなり、一方、フル映像のより低い解像度の表現は、サブピクチャを使用せず、より高い解像度の表現よりも頻度の低いランダムアクセスポイントでコーディングできる。クライアントは低解像度のフル映像を受信し、より高い解像度の映像については、現在のビューポートをカバーするサブピクチャのみを受信して復号する。
【0049】
3.6. パラメータセット
AVC、HEVC、VVCはパラメータセットを規定する。パラメータセットのタイプは、SPS、PPS、APS、VPSを含む。SPS、およびPPSは、AVC、HEVC、VVCのすべてでサポートされている。VPSは、HEVCから導入されたものであり、HEVCとVVCの両方に含まれる。APSは、AVCまたはHEVCに含まれていなかったが、最近のVVC草案のテキストに含まれている。
【0050】
SPSは、シーケンスレベルのヘッダ情報を伝送するように設計され、PPSは、頻繁に変化しないピクチャレベルのヘッダ情報を伝送するように設計された。SPSおよびPPSを用いると、シーケンスまたはピクチャごとに頻繁に変化する情報を繰り返す必要がないので、この情報の冗長な信号通知を回避することができる。さらに、SPSおよびPPSを使用することは、重要なヘッダ情報の帯域外伝送を有効化し、それにより、冗長な伝送の必要性を回避するだけでなく、誤り耐性を改善する。
【0051】
VPSは、マルチレイヤのビットストリームのすべてのレイヤに共通であるシーケンスレベルのヘッダ情報を担持するために導入された。
【0052】
APSは、コーディングするためのかなりのビットを必要とし、複数のピクチャによって共有され、そして、シーケンスにおいて非常に多くの異なる変形例が存在し得る、そのようなピクチャレベルまたはスライスレベルの情報を担持するために導入された。
【0053】
以下は、いくつかの実施形態におけるSPS/PPS/APSの意味論である。
sps_seq_parameter_set_idは、他の構文要素が参照するSPSの識別子を提供する。
SPS NALユニットは、nuh_layer_id値に関わらず、sps_seq_parameter_set_idの同じ値空間を共有する。
spsLayerIdを特定のSPS NALユニットのnuh_layer_idの値とし、vclLayerIdを特定のVCL NALユニットのnuh_layer_idの値とする。特定のVCL NALユニットは、spsLayerIdがvclLayerId以下であり、かつ復号されるOLSが、spsLayerIdに等しいnuh_layer_idを有するレイヤと、vclLayerIdに等しいnuh_layer_idを有するレイヤの両方を含む限り、特定のSPS NALユニットを参照しないものとする。
【0054】
pps_pic_parameter_set_idは、他の構文要素が参照するPPSを示す。pps_pic_parameter_set_idの値は、0~63の範囲内である。
PPS NALユニットは、nuh_layer_id値に関わらず、pps_pic_parameter_set_idの同じ値空間を共有する。
ppsLayerIdを特定のPPS NALユニットのnuh_layer_idの値とし、vclLayerIdを特定のVCL NALユニットのnuh_layer_idの値とする。特定のVCL NALユニットは、ppsLayerIdがvclLayerId以下であり、かつ復号されるOLSが、ppsLayerIdに等しいnuh_layer_idを有するレイヤと、vclLayerIdに等しいnuh_layer_idを有するレイヤの両方を含む限り、特定のPPS NALユニットを参照しないものとする。
【0055】
adaptation_parameter_set_idは、他の構文要素が参照するAPSの識別子を提供する。
aps_params_typeがALF_APSまたはSCALING_APSに等しい場合、adaptation_parameter_set_idの値は0~7の範囲に含まれるものとする。
aps_params_typeがLMCS_APSに等しい場合、adaptation_parameter_set_idの値は0~3の範囲にあるものとする。
apsLayerIdを特定のAPS NALユニットのnuh_layer_idの値とし、vclLayerIdを特定のVCL NALユニットのnuh_layer_idの値とする。特定のVCL NALユニットは、apsLayerIdがvclLayerId以下であり、かつ復号されるOLSが、apsLayerIdに等しいnuh_layer_idを有するレイヤと、vclLayerIdに等しいnuh_layer_idを有するレイヤの両方を含む限り、特定のAPS NALユニットを参照しないものとする。
【0056】
3.7. サブビットストリーム抽出処理
この処理への入力は、ビットストリームinBitstream、ターゲットOLSインデックスtargetOlsIdx、およびターゲットの最も高いTemporalId値tIdTargetである。
【0057】
この処理の出力は、サブビットストリームoutBitstreamである。
【0058】
入力ビットストリームに対するビットストリーム適合性の要件は、以下の条件のすべてを満たす任意の出力サブビットストリームが適合ビットストリームであるものとする。
-出力サブビットストリームは、VPSで規定されたOLSのリストのインデックスと等しいtargetOlsIdx、および0から6の範囲内の任意の値であるtIdTargetを入力として、本項で規定した処理の出力である。
-出力サブビットストリームは、LayerIdInOls[targetOlsIdx]における各々のnuh_layer_id値に等しいnuh_layer_idを有する少なくとも1つのVCL NALユニットを含む。
-出力サブビットストリームは、tIdTargetに等しいTemporalIdを有する少なくとも1つのVCL NALユニットを含む。
注-適合するビットストリームは、0に等しいTemporalIdを有する1または複数のコーディングされたスライスNALユニットを含むが、0に等しいnuh_layer_idを有するコーディングされたスライスNALユニットを含む必要はない。
【0059】
出力サブビットストリームoutBitstreamは、以下のように導出される。
-ビットストリームoutBitstreamは、ビットストリームinBitstreamと同一になるように設定される。
-tIdTargetよりも大きいTemporalIdを有する全てのNALユニットをoutBitstreamから削除する。
-VPS_NUT、DCI_NUT、およびEOB_NUTのいずれとも等しくないnal_unit_typeを有し、リストLayerIdInOls[targetOlsIdx]に含まれていないnuh_layer_idを有する全てのNALユニットをoutBitstreamから削除する。
-以下の全ての条件が真である全てのNALユニットをoutBitstreamから削除する。
-nal_unit_typeは、IDR_W_RADL、IDR_N_LP、またはCRA_NUTと等しくない。
-nuh_layer_idは、0からNumLayersInOls[targetOlsIdx]-1の範囲内のjの値に対するLayerIdInOls[targetOlsIdx][j]と等しい。
-TemporalIdは、NumSubLayersInLayerInOLS[targetOlsIdx][j]以上である。
【0060】
-1に等しいnesting_ols_flagを有するスケーラブルネスティングSEIメッセージを含むすべてのSEI NALユニットをoutBitstreamから削除し、NestingOlsIdx[i]がtargetOlsIdxと等しいような、0からnesting_num_olss_minus1の範囲におけるiの値は存在しない。
【0061】
-LayerIdInOls[targetOlsIdx]がビットストリーム内の全てのNALユニットにおけるnuh_layer_idの全ての値を含まない場合、以下が適用される。
-0(バッファリング時間)または130(復号ユニット情報)に等しいpayloadTypeを有する非スケーラブルネスト化されたSEIメッセージを含むすべてのSEI NALユニットをoutBitstreamから削除する。
-general_same_pic_timing_in_all_ols_flagが0に等しい場合、1(ピクチャタイミング)に等しいpayloadTypeを有する非スケーラブルネスト化されたSEIメッセージを含むすべてのSEI NALユニットをoutBitstreamから削除する。
-outBitstreamが、1に等しいnesting_ols_flagを有し、outBitstream(NestingOlsIdx[i]がtargetOlsIdxに等しい)に適用可能なスケーラブルネスティングSEIメッセージを含むSEI NALユニットを含む場合、以下が適用される。
-same_pic_timing_within_ols_flagが0に等しい場合、スケーラブルネスティングSEIメッセージから、0(バッファリング時間)、1(ピクチャタイミング)、または130(復号ユニット情報)に等しいpayloadTypeを有する適切な非スケーラブルネスティングSEIメッセージを抽出し、それらのSEIメッセージをoutBitstream内に含める。
-そうでない場合(same_pic_timing_within_ols_flagが1に等しい)、スケーラブルネストSEIメッセージから、0(バッファリング時間)または130(復号ユニット情報)に等しいpayloadTypeを有する適切な非スケーラブルネスト化されたSEIメッセージを抽出し、それらのSEIメッセージをoutBitstream内に含める。
【0062】
4. 開示される技術的解決策によって解決される技術課題
最近のVVCテキストにおける既存の設計は、以下の課題を有する。
【0063】
1) 現在のVVC設計は、図11に示すように、360°映像の典型的なコーディング方式をサポートする。しかしながら、現在のVVC設計においてスケーラビリティがサポートされているが、図12に示されるような改良された360°映像コーディング方式はサポートされていない。図11に示されたアプローチと比較した唯一の相違は、図12に示されたアプローチに対してILP(Inter-Layer Prediction)が適用されることである。
VVC草案における以下の2つの場所は、サブピクチャと空間的スケーラビリティとを組み合わせて使用することを許可していない。
a. VVCにおける空間的スケーラビリティ設計は、RPR機能に依存する。しかしながら、RPRとサブピクチャとの組み合わせは、現在、以下の意味論の制約によって許可されていない。
res_change_in_clvs_allowed_flagが1に等しい場合、subpic_info_present_flagの値は0に等しいものとする。
その結果、上位レイヤが参照するSPSに対しては、上記の制約が、subpic_info_present_flagを1に設定すること(1ピクチャ当たり複数のサブピクチャを使用すること)、かつ、同時に、res_change_in_clvs_allowed_flagを1に設定すること(ILPによる空間的スケーラビリティのために必要であるRPRを有効化すること)を許可しないため、このコーディング方式は、許可されない。
b. 現在のVVC草案は、サブピクチャとスケーラビリティとの組み合わせに関して、以下の制約を有する。
subpic_treated_as_pic_flag[i]が1に等しい場合、出力レイヤとしてi番目のサブピクチャを包含するレイヤを含むOLSにおける各出力レイヤおよびその参照レイヤについて、以下のすべての条件が真であることが、ビットストリーム適合性の要件である。
-出力レイヤおよびその参照レイヤにおけるすべてのピクチャは、pic_width_in_luma_samplesの値が同じであり、pic_height_in_luma_samplesの値が同じであるものとする。
-出力レイヤおよびその参照レイヤが参照するすべてのSPSは、同じsps_num_subpics_minus1の値を有し、かつ0からsps_num_subpics_minus1の範囲内にあるjの各値について、それぞれ、subpic_ctu_top_left_x[j]、subpic_ctu_top_left_y[j]、subpic_width_minus1[j]、およびloop_filter_across_subpic_enabled_flag[j]の同じ値を有するものとする。
-出力レイヤの各アクセスユニットにおけるすべてのピクチャは、その参照レイヤとともに、0からsps_num_subpics_minus1の範囲内にあるjの各値について、SubpicIdVal[j]の同じ値を有するものとする。
この上述の制約は、基本的に、サブピクチャとSNRスケーラビリティとの制限された組み合わせ以外の、サブピクチャおよびILPによるスケーラビリティとの任意の他の組み合わせを許可せず、ここで、各従属ツリー内のレイヤは、同じ空間的解像度および同じサブピクチャレイアウトを有する必要がある。
【0064】
2) subpic_treated_as_pic_flag[i]が1に等しい場合、i番目のサブピクチャの境界は、動き補償におけるピクチャの境界として扱われる。このような処理は、VVC草案テキストにおいて、動き補償に関する復号処理においてあるクリッピング演算を適用することで実現される。しかしながら、図12に示される改善されたコーディング方式の場合、下位レイヤは完全にデコーダに利用可能であるため、i番目のサブピクチャに対応する領域だけでなく、このようなクリッピングを適用する必要がなく、不必要なコーディング効率の低下を回避する。
【0065】
3)図12に示された改良されたコーディング方式のサポートを考慮しなければ、上述したようなサブピクチャの組み合わせおよびスケーラビリティに関する既存の制約は、以下の課題を有する(この記載は課題1bの記載に含まれる)。
a. この制約は、i番目のサブピクチャを含むレイヤがOLSの出力レイヤでない場合にも適用されるべきである。1つのレイヤがOLSの出力レイヤであるかどうかを考慮しない方法で、制約全体を特定すべきである。
b. subpic_treated_as_pic_flag[i]の値をレイヤ間で整列させるための要件を含めるべきであり、そうでない場合、レイヤ間で同じインデックスを有するサブピクチャシーケンスを抽出することは不可能であろう。
c. subpic_treated_as_pic_flag[i]]が1に等しく、サブピクチャシーケンスが抽出可能である限り、loop_filter_across_subpic_enabled_flag[i]の値をレイヤ間で整列させるための要件は、このフラグの値に関わらず除外されるべきである。loop_filter_across_subpic_enabled_flag[i]の値の設定は、エンコーダが、単一の抽出可能なサブピクチャシーケンスの品質と抽出可能なサブピクチャシーケンスのセットの品質とをトレードオフすることを決定するために、2つのフラグが互いに独立して信号通知される理由と同様に、行わなければならない。
d. 制約全体は、sps_num_subpics_minus1が0より大きい場合にのみ適用され、意図せずにサブピクチャごとに1つのサブピクチャが制約によってカバーされるすべてのケースを回避するべきである。
e. 制約が適用される時間的範囲、例えばAUのセットを明確に特定することが必要である。
f. 1つのピクチャ当たり複数のサブピクチャが存在する場合に、ITRPのRPRが必要とされないことを確認するために、レイヤ間で整列されるスケーリングウィンドウパラメータscaling_win_left_offset、scaling_win_right_offset、scaling_win_top_offset、およびscaling_win_bottom_offsetの各々の値に対する要件が含まれるべきである。
【0066】
4) 現在、現在のピクチャに対して同一位置の(collocated)ピクチャは、現在のピクチャと同じレイヤのLTRP(Long-Term Reference Picture)であってもよく、ILRP(Inter-Layer Reference Picture)であってもよく、例えば、現在のピクチャとは異なるレイヤの参照ピクチャであってもよい。しかし、いずれの場合も、POCに基づく動きベクトルのスケーリングは適用されず、したがって、これを可能にすることに起因するコーディング性能は非常に低いと予想される。その結果、現在のピクチャのために同一位置のピクチャがLTRPまたはILRPであることを許可しないほうがよい。
【0067】
5) 現在、CLVSにおいて同じ空間的解像度を有するピクチャは、異なるスケーリングウィンドウを有することができる。しかしながら、そうでない場合、RPRに対するSPSフラグおよびRPRに対する一般的な制約フラグを使用してRPRツールを完全に無効化することができないので、このようなことは許可されない。
6) 現在、サブビットストリーム抽出を行う際、現在の/ターゲットOLSに含まれないレイヤのパラメータセット(SPS/PPS/VPS)も抽出ビットストリームに含めることが可能である。しかしながら、layerAとlayerBの両方を含むVPSに定義されたOLSがあるかぎり、layerAとlayerBが復号される現在のOLSに含まれていなくても、layerAのスライスがlayerBのパラメータセットを参照することは設計上の意図ではない。
【0068】
7) APSの許容数は、APSの種類に依存する。しかしながら、APS IDの信号通知は、不要なビットを浪費する可能性がある許可されたAPSに関わらずu(5)に固定される。
8) 現在、スケーリングウィンドウオフセットは正の値として通知されるため、正の垂直および水平のオフセットのみがサポートされる。しかしながら、負のスケーリングウィンドウオフセットの信号通知を許可することで、参照するピクチャにスケーリングウィンドウが含まれない場合でも、負の垂直および水平のオフセットを導出することができるようにすることができる。さらに、1より大きなスケーリングファクタを許可することは、360°映像コーディングにおけるサブピクチャ使用ケースにも有益であり、例えば、基本レイヤに360°映像コンテンツ全体を低解像度でコーディングし、後で特定のビューポート(基本レイヤのピクチャからのズームイン等)を高解像度でコーディングされた特定のビューポートでエンハンスメントを行う。しかしながら、この機能をサポートするためには、現在の仕様のいくつかの箇所を修正する必要がある。
【0069】
9) 現在、TSRC(Transform Skip Residual Coding)が有効である場合、SDH(Sign Data Hiding)やDQ(Dependent Quantization)も使用できるが、これは無損失性コーディングの概念に反する。TSRCは、変換ブロックの全てのスキャン位置の量子化インデックスがコーディングされるモードである。SDHは、非0のインデックスに対する符号のコーディングを省略する技術である。DQは、サンプルの量子化が、前のサンプルの状態に依存するモードである。
10) 同一位置のピクチャのCTUサイズが現在のピクチャのものと同じである場合、同一位置のCTUまたは同一位置のピクチャの同一位置のCTUの右側のCTUのブロックの動き情報のみを取得する必要があるので、メモリの読み込みは順次実行されてもよい。しかしながら、インターレイヤ予測のため、この同一位置のピクチャはインターレイヤ参照ピクチャである可能性があり(即ち、異なるレイヤにある)、同一位置のピクチャのCTUサイズが現在のピクチャのCTUサイズと異なる場合(これは、インターレイヤ予測を使用する場合に起こり得る)、このことは、メモリの読み込みの点でハードウェア実装の問題を引き起こす可能性がある。
【0070】
5. 技術的解決策および実施形態の一覧
上記課題を解決するために、以下に示す方法が開示されている。これらの項目は、一般的な概念を説明するための例であり、狭義に解釈されるべきではない。さらに、これらの項目は、個々に適用されてもよく、または任意の方法で組み合わされてもよい。
【0071】
1) 課題1aを解決するために、RPRを制御するための1つのSPSフラグ(例えば、現在のVVC草案におけるような、res_change_in_clvs_allowed_flag)だけを有する代わりに、複数の(例えば、2つの)SPSフラグを規定および/または信号通知してもよい。
a. 例えば、第1のフラグ(例えば、ref_pic_resampling_enabled_flag)は、1または複数のピクチャの復号にRPRの使用の必要があるかどうかを規定する一方、第2のフラグ(例えば、res_change_in_clvs_allowed_flag)は、CLVS内でピクチャ解像度の変更が許容されるかどうかを規定する。
b. さらに、代替的に、第2のフラグは、第1のフラグが1または複数のピクチャの復号にRPRの使用が必要となる可能性があることを規定した場合にのみ信号通知される。さらに、信号が送信されていない場合、第2のフラグの値は、CLVS内でピクチャの解像度を変更することが許可されていないことを示す値であると推測される。
i. 代替的に、2つのフラグは互いに依存せず、信号通知される。
c. 代替的に、さらに、第1および第2のフラグの各々に対して1つの一般的な制約フラグがあるように、もう1つの一般的な制約フラグを追加する。
d. さらに、1に等しいres_change_in_clvs_allowed_flagを有するピクチャ当たり複数のサブピクチャの組み合わせは許可されないが、1に等しいref_pic_resampling_enabled_flagを有するピクチャ当たり複数のサブピクチャの組み合わせは許可される。
【0072】
【化1】
【0073】
f. 代替的に、SPS内の代わりに、VPS内で複数の(例えば2つの)フラグのうちの1つまたはすべてのフラグを信号通知してもよい。
i. 一例において、VPSにおける複数(例えば、2つ)のフラグのうちの1つまたはすべてのフラグは、VPSによって規定されたすべてのレイヤに適用される。
ii. 別の例において、VPSにおける複数(例えば、2つ)のフラグのうちの1つまたはすべては、VPSにおいて信号通知される複数のインスタンスをそれぞれ有することができ、各インスタンスは、1つの従属ツリーにおけるすべてのレイヤに適用される。
g. 一例において、複数のフラグの各々は、l個のビットu(l)を使用して、符号なしの整数としてコーディングされる。
h. 代替的に、1つの構文要素に非バイナリ値を信号通知してもよく、例えば、SPS/VPSにおいて、復号処理におけるRPRの使用およびCLVS内のピクチャ解像度の変更の許可を規定する。
i. 一例において、構文要素の値が0に等しい場合、それは、1または複数のピクチャの復号にRPRの使用が必要でないことを規定する。
ii. 一例において、構文要素の値が1に等しい場合、それは、CLVS内において、ピクチャ解像度の変更が許可されていない間、1または複数のピクチャの復号にRPRの使用が必要とされてよいことを規定する。
iii. 一例において、構文要素の値が2に等しい場合、それは、CLVS内において、ピクチャ解像度の変更が許可されている間、1または複数のピクチャの復号にRPRの使用が必要とされてよいことを規定する。
iv. さらに、代替的に、構文要素をどのように信号通知するかは、インターレイヤ予測が許可されるかどうかに依存してもよい。
v. 一例において、構文要素は、ue(v)を使用してコーディングされ、左ビットが1つ目の、符号なしの整数の0次の指数ゴロムコーディング構文要素を示す。
vi. 別の例において、構文要素は、Nビットu(N)を使用して符号なしの整数としてコーディングされ、例えば、Nは2に等しい。
【0074】
【化2】
【0075】
3) 課題1bを解決するために、サブピクチャおよびILPによるスケーラビリティとの組み合わせの制約を更新し、この制約は、クロスレイヤアライメント制限を現在のレイヤおよび現在のレイヤに依存するすべての上位レイヤにのみ課し、現在のレイヤまたは下位レイヤに依存しない上位レイヤには課すことはしない。
a. 代替的に、現在のレイヤと、現在のレイヤよりも高いすべてのレイヤにクロスレイヤアライメント制限のみを課すように、制約を更新する。
b. 代替的に、現在のレイヤと、現在のレイヤを含む各OLSにおけるすべての上位レイヤにクロスレイヤアライメント制限のみを課すように、制約を更新する。
c. 代替的に、現在のレイヤと、現在のレイヤの参照レイヤであるすべての下位レイヤにクロスレイヤアライメント制限のみを課すように制約を更新する。
d. 代替的に、現在のレイヤと、現在のレイヤよりも低いすべてのレイヤにクロスレイヤアライメント制限のみを課すように、この制約を更新する。
e. 代替的に、現在のレイヤと、現在のレイヤを含む各OLSにおけるすべての下位レイヤにレイヤ間アライメント制限のみを課すように、制約を更新する。
f. 代替的に、最上レイヤよりも低いすべてのレイヤにクロスレイヤアライメント制限のみを課すように制約を更新する。
g. 代替的に、最下レイヤよりも高いすべてのレイヤにクロスレイヤアライメント制限のみを課すように制約を更新する。
【0076】
4) 課題2を解決するために、ピクチャの境界として動き補償/動き予測におけるサブピクチャの境界をハンドリングするためのインター予測関連処理におけるクリッピング演算を含む1または複数の復号処理(例えば、8.5.2.11項の時間的輝度動きベクトル予測の導出処理、8.5.3.2.2項の輝度サンプル双線形補間処理、8.5.5.3項のサブブロックに基づく時間的マージ候補の導出処理、8.5.5.4項のサブブロックに基づく時間的マージベース動きデータベースの導出処理、8.5.5.6項の構築されたアフィン制御点動きベクトル合併候補の導出処理、8.5.6.3.2項の輝度サンプル補間フィルタリング処理、8.5.6.3.3項の輝度整数サンプルフェッチ処理、および8.5.6.3.4項の彩度サンプル補間処理)のうち、以下の変更が適用される。
a. 一例において、処理は、subpic_treated_as_pic_flag[CurrSubpicIdx]が1に等しく、かつ、参照ピクチャrefPicLXのsps_num_subpics_minus1が0よりも大きい場合、クリッピング演算が適用され、そうでない場合、適用されないように変更される。
i. 代替的に、ピクチャの同一位置のピクチャがILRPであることが許可されない場合、上述したように、参照ピクチャrefPicLXが同一位置のピクチャでない処理のみを変更し、参照ピクチャrefPicLXが同一位置のピクチャである処理は変更しない。
b. 一例において、処理は、subpic_treated_as_pic_flag[CurrSubpicIdx]が1に等しく、かつ、現在のスライスのnal_unit_typeの値がIDR_W_RADL、IDR_N_LP、またはCRA_NUTに等しい場合にはクリッピング演算が適用され、そうでない場合には適用されないように変更される。同時に、ILPは、IRAPピクチャのみのコーディングを許可される。
c. 一例において、これらの復号処理に対して何の変更も行われず、例えば、subpic_treated_as_pic_flag[CurrSubpicIdx]が1に等しい場合、クリッピング演算が適用され、それ以外の場合、現在のVVCテキストと同様に、クリッピング演算が適用されない。
【0077】
5) 課題3aを解決するために、サブピクチャおよびILPによるスケーラビリティの組み合わせの制約を更新し、この制約によって、各従属ツリーにおけるすべてのレイヤにクロスレイヤアライメント制限が課せられる。従属ツリーは、特定のレイヤを含み、すべてのレイヤは特定のレイヤを参照レイヤとして有し、特定のレイヤのすべての参照レイヤは、いずれか1つのレイヤがOLSの出力レイヤであるかどうかに依存しない。
6) 課題3bを解決するために、サブピクチャおよびILPによるスケーラビリティの組み合わせの制約を、subpic_treated_as_pic_flag[i]の値にクロスレイヤアライメント制限を課すように更新する。
7) 課題3cを解決するために、サブピクチャおよびILPによるスケーラビリティの組み合わせの制約を、loop_filter_across_subpic_enabled_flag[i]の値にクロスレイヤアライメント制限を課さないように更新する。
【0078】
8) 課題3dを解決するために、sps_num_subpics_minus1が0に等しい場合、制約が適用されないように、サブピクチャおよびILPによるスケーラビリティの組み合わせの制約を更新する。
a. 代替的に、subpic_info_present_flagが0に等しい場合、制約が適用されないように制約を更新する。
【0079】
9) 課題3eを解決するために、サブピクチャおよびILPによるスケーラビリティの組み合わせの制約を更新し、この制約によって、AUの任意のターゲットセットにおけるピクチャにクロスレイヤアライメント制限が課せられる。
a. 一例において、SPSを参照する現在のレイヤの各CLVSについて、AUのターゲットセットtargetAuSetを、復号順にCLVSの最初のピクチャを含むAUから始まって、復号順にCLVSの最後のピクチャを含むAUまでのすべてのAUとする。
【0080】
10) 課題3fを解決するために、サブピクチャおよびILPによるスケーラビリティの組み合わせの制約をスケーリングウィンドウパラメータscaling_win_left_offset、scaling_win_right_offset、scaling_win_top_offset、およびscaling_win_bottom_offsetの各々の値に対して、クロスレイヤアライメント制限を課すように更新する。
【0081】
11) 課題4を解決するために、現在のピクチャに対する同一位置のピクチャは、LTRP(Long-Term Reference Picture)であってはならないと制約される。
a. 代替的に、現在のピクチャに対する同一位置のピクチャは、ILRP(Inter-Layer Reference Picture)であってはならないと制約される。
b. 代替的に、現在のピクチャに対する同一位置のピクチャは、LTRPまたはILRPであってはならないと制約される。
c. 代替的に、現在のピクチャの同一位置のピクチャがLTRPまたはILRPである場合、同一位置のピクチャを指す動きベクトルを得るためにスケーリングは適用されない。
【0082】
12) 課題5を解決するために、scaling_win_left_offset、scaling_win_right_offset、scaling_win_top_offset、およびscaling_win_bottom_offsetの各々の値は、それぞれ、pic_width_in_luma_samplesおよびpic_height_in_luma_samplesの同じ値を有する同じCLVS内の任意の2つのピクチャに対して同じであるべきであると制約される。
a. 代替的に、上記「同じCLVS内」を「同じCVS内」に置き換える。
b. 代替的に、この制約は、以下のように規定される。
ppsAおよびppsBを、同じSPSを参照する任意の2つのPPSとする。ppsAおよびppsBがそれぞれpic_width_in_luma_samplesおよびpic_height_in_luma_samplesの同じ値を有する場合、ppsAおよびppsBは、それぞれscaling_win_left_offset、scaling_win_right_offset、scaling_win_top_offset、およびscaling_win_bottom_offsetと同じ値を有するものとすることが、ビットストリーム適合性の要件である。
c. 代替的に、この制約は、以下のように規定される。
scaling_win_left_offset、scaling_win_right_offset、scaling_win_top_offset、およびscaling_win_bottom_offsetのそれぞれの値は、同じCVS内の任意の2つのピクチャと同じであり、かつ、次の条件をすべて満たすものとする。
i. 2つのピクチャは、それぞれ、pic_width_in_luma_samplesおよびpic_height_in_luma_samplesの同じ値を有する。
ii. 2つのピクチャは、同じレイヤ、または、一方のレイヤが他方のレイヤの参照レイヤである2つのレイヤに属する。
【0083】
13) 現在のピクチャと同じアクセスユニット内の他のピクチャとでピクチャの解像度/スケーリングウィンドウが異なる場合、現在のピクチャがIRAPピクチャである場合にのみ、ILPを許可することが求められる。
14) 本ドキュメントにおいて、ピクチャ解像度は、ピクチャの幅および/または高さを指してもよく、またはピクチャのスケーリングウィンドウまたは適合性ウィンドウの幅および/または高さおよび/または左上隅の位置を指してもよい。
15) 本ドキュメントにおいて、RPRが使用されないことは、現在のピクチャの任意の参照ピクチャの解像度が現在のピクチャの解像度と同じであることを意味してよい。
【0084】
16) 課題6を解決するためのビットストリーム抽出については、以下のように1または複数の解決策が提案されている。
a. 一例において、出力サブビットストリームを導出するために、リストLayerIdInOls[targetOlsIdx]に含まれないnuh_layer_idを有するパラメータセット(例えば、SPS/PPS/APS NALユニット)を削除する。
b. 例えば、出力サブビットストリームOutBitstreamの導出は、以下のうちの1または複数に依存してもよい。
i. SPS_NUTに等しいnal_unit_typeを有し、かつ、リストLayerIdInOls[targetOlsIdx]に含まれないnuh_layer_idを有するすべてのNALユニットをoutBitstreamから削除する。
ii. PPS_NUTに等しいnal_unit_typeを有し、かつ、リストLayerIdInOls[targetOlsIdx]に含まれないnuh_layer_idを有するすべてのNALユニットをoutBitstreamから削除する。
iii. APS_NUTに等しいnal_unit_typeを有し、かつ、リストLayerIdInOls[targetOlsIdx]に含まれないnuh_layer_idを有するすべてのNALユニットをoutBitstreamから削除する。
iv. SPS_NUT、PPS_NUT、およびAPS_NUTのいずれかに等しいnal_unit_typeを有し、かつ、以下の条件のいずれかが真であるNALユニットをoutBitstreamから削除する。
1.少なくとも、0からNumLayersInOls[targetOlsIdx]-1の範囲におけるjの値に対し、nuh_layer_idがLayerIdInOls[targetOlsIdx][j]より大きい。
2.nuh_layer_idがリストLayerIdInOls[targetOlsIdx]に含まれていない。
v. SPS_NUT、PPS_NUT、およびAPS_NUTのいずれかに等しいnal_unit_typeを有する第1のNALユニットが抽出中に削除された場合、第1のNALユニットを参照する第2のNALユニットも削除される必要がある。
c. 例えば、出力サブビットストリームOutBitstreamの導出は、以下のうちの1または複数に依存してもよい。
i. VPS_NUT、DCI_NUT、およびEOB_NUTのいずれかに等しいnal_unit_typeを有し、かつ、リストLayerIdInOls[targetOlsIdx]に含まれないnuh_layer_idを有する全てのNALユニットをoutBitstreamから削除する。
【0085】
17) APS ID(例えば、adaptation_parameter_set_id)を信号通知するために必要なビットは、APSタイプに依存する。
a. APS ID(例えば、adaptation_parameter_set_id)の信号通知に必要なビットは、(3)からu(v)に変更される。
i. 一例において、ALF(Adaptive Loop Filter) APSの場合、APS IDはu(a)でコーディングされてもよい。
ii. 一例において、LMCS(Luma Mapping with Chroma Scaling)の場合、APS IDは、u(b)でコーディングされてもよい。
iii. 一例において、スケーリングリストAPSの場合、APS IDは、u(c)でコーディングされてもよい。
iv. 一例において、a/b/cは、対応するタイプのAPSの最大許容数に依存する。
1. 一例において、a>b、かつ、a>c。
2. 一例において、a>=b、かつ、a>c。
3. 一例において、c>b。
4. 一例において、b=2。
5. 一例において、c=3。
6. 一例において、a=3、または3より大きい(例えば、4、5、6、7、8、9)。
【0086】
18) APS ID(例えば、adaptation_parameter_set_id)とAPSタイプ(例えば、VVCテキスト内のaps_params_type)のコーディング順は、ビットストリームにおいてAPSタイプがAPS IDよりも前に存在するように切り替えられる。
19) APSで許可されるフィルタの総数は、ピクチャ/スライスタイプ、コーディング構造(デュアルツリーまたはシングルツリー)、レイヤ情報などのコーディングされた情報に従って制限されてもよい。
a. APSの許容フィルタ総数は、PUを有する全てのAPS NALユニットのALF APSにおける輝度/彩度ALFおよびCC-ALF)の総数を含んでもよい。
b. APSにおける許容されるフィルタの総数は、輝度成分に対する適応ループフィルタクラス(または輝度ALFフィルタ)の総数、彩度成分に対する代替フィルタ(彩度ALFフィルタ)の総数、および/またはPUを有するすべてのAPS NALユニットにおける彩度コンポーネントフィルタの総数を含んでもよい。
【0087】
20)第8の課題を解決するための1より大きいスケーリングファクタについては、以下のように1または複数の解決策が提案されている。
a. 一例において、スケーリング比計算のためにピクチャサイズに適用されるスケーリングウィンドウのオフセットは、負の値であってもよい。
i. 例えば、スケーリングウィンドウオフセット(例えば、scaling_win_left_offset、scaling_win_right_offset、scaling_win_top_offset、scaling_win_bottom_offset)の構文要素は、ae(v)、f(n)、i(n)、se(v)などの符号付き2値化でコーディングされてもよい。
【0088】
b. 一例において、ピクチャサイズ(例えば、ピクチャの幅/高さ)に基づくスケーリングウィンドウオフセットの値を制約する方法は、スケーリングウィンドウオフセットの値が負であるか否かに依存してもよい。
i. 例えば、スケーリングウィンドウオフセットが負であるか否かによって、オフセットとピクチャの幅/高さの制約が異なるよう規定されてもよい。
1. 例えば、左右のオフセットの両方が負であるか、および/または左右のオフセットの一方が負/正であるか、および/または左右のオフセットの両方が正であるかによって、1つまたは複数の制約が規定されてもよい。
2. 例えば、上下のオフセットの両方が負であるか否か、および/または、上下のオフセットの一方が負/正であるか否か、および/または、上下のオフセットの両方が正であるか否かに応じて1または複数の制約が規定されてもよい。
ii. 例えば、スケーリングウィンドウオフセットの値が正の値または0である場合のみ、スケーリングウィンドウオフセットの値は、ピクチャの寸法に従って制限される。
1. 例えば、scaling_win_left_offsetとscaling_win_right_offsetが負(または正)でない場合、SubWidthC*(scaling_win_left_offset+scaling_win_right_offset)の値はpic_width_in_luma_samplesより小さいものとする。
2. 例えば、scaling_win_top_offsetとscaling_win_bottom_offsetが負(または正)でない場合、SubHeightC*(scaling_win_top_offset+scaling_win_bottom_offset)の値はpic_height_in_luma_samplesより小さいものとする。
iii. 例えば、制約を規定するために絶対値オフセットを使用してもよい。
1. 例えば、SubWidthC*(abs(scaling_win_left_offset)+abs(scaling_win_right_offset))の値は、X1*pic_width_in_luma_samplesより小さいものとし、ここでX1はX1>=1などの正の整数とする。
2. 例えば、SubHeightC*(abs(scaling_win_top_offset)+abs(scaling_win_bottom_offset))の値は、X2*pic_height_in_luma_samplesより小さいものとし、X2においてX2>=1など正の整数とする。
iv. また、スケーリングウィンドウオフセット値が負の値である場合、オフセット値をピクチャの幅/高さで制約しない(例えば、負のオフセットを0値オフセットとして扱う)。
1. 例えば、SubWidthC*(max(0,scaling_win_left_offset)+max(0,scaling_win_right_offset))の値はpic_width_in_luma_samplesより小さいものとする。
2. 例えば、SubHeightC*(max(0,scaling_win_top_offset)+max(0,scaling_win_bottom_offset))の値はpic_height_in_luma_samplesより小さいものとする。
【0089】
c. 一例において、参照ピクチャ出力の幅/高さ、現在のピクチャ出力の幅/高さ、参照ピクチャの幅/高さ、現在のピクチャの幅/高さ、最大ピクチャの幅/高さ(例えば、refPicOutputWidthL、refPicOutputHeightL、PicOutputWidthL、PicOutputHeightL、refPicWidthInLumaSamples、refPicHeightInLumaSamples、pic_width/height_in_luma_samples、pic_width/height_max_in_luma_samples)間のビットストリーム適合/制約をどのように作成するかは、スケーリングウィンドウオフセット値が負か否か依存してもよい。
【0090】
d. 一例において、出力ピクチャの幅/高さ(例えば、PicOutputWidthL、PicOutputHeightL)を導出する方法は、スケーリングウィンドウオフセットの値が負か否かに依存してもよい。
i. 例えば、参照ピクチャのスケーリングオフセットの値が負である場合、参照ピクチャに対する出力ピクチャの幅/高さを計算するための0値オフセットとして扱ってもよい。
ii. 例えば、変数PicOutputWidthLは、以下のように導出されてもよい。PicOutputWidthL=pic_width_in_luma_samples-SubWidthC*(max(0,scaling_win_right_offset)+max(0,scaling_win_left_offset))
iii. 例えば、変数PicOutputHeightLは、以下のように導出されてもよい。PicOutputHeightL=pic_height_in_luma_samples-SubWidthC*(max(0,scaling_win_bottom_offset)+max(0,scaling_win_top_offset))
【0091】
e. 一例において、分数サンプル補間をどのように行うかは、スケーリングウィンドウオフセットの値が負か否かに依存してもよい。
i. 例えば、参照ピクチャのスケーリングウィンドウオフセットの値が負である場合、動き補償のための0値オフセットとして扱ってもよい。
1. 例えば、変数fRefLeftOffsetは、((SubWidthC*max(0,scaling_win_left_offset)<<10)に等しく設定されてもよく、scaling_win_left_offsetは参照ピクチャに対するscaling_win_left_offsetである。
2. 例えば、変数fRefTopOffsetは、((SubWidthC*max(0,scaling_win_top_offset))<<10)に等しく設定されてもよく、scaling_win_top_offsetは参照ピクチャに対するscaling_win_top_offsetである。
ii. 例えば、現在のピクチャのスケーリングウィンドウオフセット値が負である場合、分数サンプル補間のための0値オフセットとして扱ってもよい。
1. 例えば、(refxSb,refySb)を、1/16サンプル単位で与えられる動きベクトル(refMvLX[0],refMvLX[1])が指す輝度位置とする。変数refxSbおよびrefySbは、以下のように導出される。
a. refxSb=(((xSb-(SubWidthC*max(0,scaling_win_left_offset)))<<4)+refMvLX[0])*scalingRatio[0]
b. refySb=(((ySb-(SubWidthC*max(0,scaling_win_top_offset)))<<4)+refMvLX[1])*scalingRatio[1]
2. 例えば、(refxSb、refySb)を、1/32サンプル単位で与えられる動きベクトル(refMvLX[0],refMvLX[1])が指す彩度位置とする。変数refxSb,およびrefySbは、以下のように導出される。
a. refxSb=(((xSb-(SubWidthC*max(0,scaling_win_left_offset)))/SubWidthC<<5)+refMvLX[0])*scalingRatio[0]+addX
b. refySb=(((ySb-(SubWidthC*max(0,scaling_win_top_offset)))/SubHeightC<<5)+refMvLX[1])*scalingRatio[1]+addY
【0092】
21)9番目の問題を解決するためのTSRC/DQ/SHDの信号通知については、以下のような1または複数の解決策が提案されている。
a. 一例において、映像ユニットレベル(シーケンス/ピクチャのグループ/ピクチャ/スライスレベルなど)におけるSDH(Sign Data Hiding)およびDQ(Dependent Quantization)の有効/無効フラグの信号通知は、TSRC(Transform Skip Residual Coding)が有効か否かに依存してもよい。
i. 例えば、TSRCが有効かどうか(例えば、sps/pps/ph/slice_ts_residual_coding_disabled_flag)は、同じレベルのSDH/DQの有効/無効フラグ(例えば、sps/pps/ph/slice_dep_quant_enabled_flag、sps/pps/ph/slice_sign_data_hiding_enabled_flagという)よりも前に信号通知されてもよい。
ii. 例えば、SPS/PPS/PH/SHレベルのSDH/DQの有効/無効フラグの信号通知(例えば、sps/pps/ph/slice_dep_quant_enabled_flag、sps/pps/ph/slice_sign_data_hiding_enabled_flagという)は、同じレベルまたは上位のレベルでTSRCが無効にされているか否か(例えば、sps/pps/ph/slice_ts_residual_coding_disabled_flagが1と等しいか否か)を条件としてもよい。
iii. 例えば、SH(JVET-Q2001-vEの上)の構文信号通知は、以下のように変更することができる。
【0093】
【表1】
【0094】
iv. さらに、sps/pps/ph/slice_dep_quant_enabled_flagが存在しない場合、特定の値(0など)に等しいと推論する。
v. さらに、sps/pps/ph/slice_sign_data_hiding_enabled_flagが存在しない場合、特定の値(0など)に等しいと推論する。
b. 一例において、TSRCが有効であるか否かは、映像ユニットレベル(シーケンス/ピクチャのグループ/ピクチャ/スライスレベルなど)で信号通知されてもよい。
i. 例えば、SPS/PPS/PH/SHにおいて、(sps/ps/ph/slice)_ts_residual_coding_enabled_flagというフラグが信号通知されてもよい。
ii. あるいは、TSRCを無効とするか否かは映像ユニットレベル(シーケンス/ピクチャ/ピクチャ/スライスレベルなど)で信号通知されてもよい。
iii. 例えば、SPS/PPS/PH/SHにおいて、(sps/ps/ph/slice)_ts_residual_coding_disabled_flagというフラグが信号通知されてもよい。
【0095】
c. 一例において、TSRCが有効かどうかは、同じレベルまたは上位のレベルで変換スキップとDQとSDHが有効か否かに基づいて、条件付きで信号通知される。
i. 例えば、slice_ts_residual_coding_disabled_flagは、(sps_transform_skip_enabled_flag=1&&!slice_dep_quant_enabled_flag&&!slice_sign_data_hiding_enabled_flag)に基づいて条件付きで信号通知される。
ii. 例えば、ph_ts_residual_coding_disabled_flagは、(sps_transform_skip_enabled_flag=1&&!ph_dep_quant_enabled_flag&&!ph_sign_data_hiding_enabled_flag)に基づいて、条件付きで信号通知される。
iii. 例えば、pps_ts_residual_coding_disabled_flagは、(sps_transform_skip_enabled_flag=1&&!pps_dep_quant_enabled_flag&&!pps_sign_data_hiding_enabled_flag)に基づいて、条件付きで信号通知される。
iv. 上記の例では、sps_transform_skip_enabled_flagは、SPS TSRC有効フラグ/SPS TSRC無効フラグに置き換えてもよい。
v. 上記の例では、sps_transform_skip_enabled_flagは、PPS TS有効フラグ/PPS TSRC有効フラグ/PPS TSRC無効フラグに置き換えてもよい。
【0096】
d. 一例において、ブロック内でSDHとDQのどちらを適用するかは、TSおよび/またはTSRSのどちらを使用するかに依存してもよい。
e. 一例において、ブロック内でTSおよび/またはTSRSが使用されている場合、SDHおよび/またはDQは適用されない。一例において、ブロック内でTSおよび/またはTSRSが使用されている場合、SDHおよび/またはDQが使用されているか否かを示すSE(s)は信号通知されず、使用されていないと推論される。
f. 一例において、ブロック内でTSおよび/またはTSRSが使用されている場合、SDHおよび/またはDQは使用できないように制約される。
【0097】
22) スケーリングウィドウオフセット(scaling_win_right_offset,scaling_win_left_offset,scaling_win_top_offset,scaling_win_bottom_offset等)が整数Xより大きい(または小さくない)ことが求められる場合があり、ここでXは負である。
a. 一例において、Xはピクチャ寸法に依存してもよい。
【0098】
23) PicOutputWidthLおよびPicOutputHeightLの変数は以下のように導出される。
PicOutputWidthL=pic_width_in_luma_samples-SubWidthC*(scaling_win_right_offset+scaling_win_left_offset)
PicOutputHeightL=pic_height_in_luma_samples-SubWidthC*(scaling_win_bottom_offset+scaling_win_top_offset).
【0099】
その場合、以下の制限のうち1または複数を適用してよい。
a.((aX1*PicOutputWidthL+bX1)>>cX1)<=((dX1*X1+eX1)>>fX1)、ここで、X1は非負整数である。
b.((aX0*PicOutputWidthL+bX0)>>cX0)>=((dX0*X1+eX0)>>fX0)、ここで、X0は非負整数である。
c.((aY1*PicOutputHeightL+bY1)>>cY1)<=(dY1*Y1+eY1)>>fY1、ここで、Y1は非負整数である。
d.((aY0*PicOutputHeightL+bY0)>>cY0)<=(dY0*Y0+eY0)>>fY0、ここで、Y0は非負整数である。
e.((aXY1*PicOutputWidthL*PicOutputHeightL+bXY1)>>cXY1)<=(dXY1*XY1+eXY1)>>fXY1、ここで、XY1は非負整数である。
f.((aXY0*PicOutputWidthL*PicOutputHeightL+bXY0)>>cXY0)<=(dXY0*Y0+eXY0)>>fXY0、ここで、XY0は非負整数である。
【0100】
g. 上記制約において、aX1,bX1,…eX1,fX1,aX0,bX0,…eX0,fX0,aY1,bY1,…eY1,fY1,aY0,bY0,…eY0,fY0,aXY1,bXY1,…eXY1,fXY1,aXY0,bXY0,…eXY0,fXY0は、整数である。一例において、aX1=aX0=aY1=aY0=aXY1=aXY0=1,bX1=bX0=bY1=bY0=bXY1=bXY0=0,cX1=cX0=cY1=cY0=cXY1=cXY0=0,dX1=dX0=dY1=dY0=dXY1=dXY0=1,eX1=eX0=eY1=eY0=eXY1=eXY0=0,fX1=fX0=fY1=fY0=fXY1=fXY0=0,
h. 上記制約において、X1および/またはX0は、pic_width_in_luma_samplesに依存してもよい。
i. 一例において、X1はpic_width_in_luma_samplesに等しい。
ii. 一例において、PicOutputWidthL<=pic_width_in_luma_samples*K、ここで、Kは2,3,4,5,6,7,8のような正の整数である。
i. 上記制約において、Y1および/またはY0は、pic_height_in_luma_samplesに依存してもよい。
i. 一例において、Y1は、pic_height_in_luma_samplesに等しい。
ii. 一例において、PicOutputHeightL<=pic_height_in_luma_samples*K、ここで、Kは2,3,4,5,6,7,8のような正の整数である。
【0101】
24) 一例において、five_minus_max_num_subblock_merge_candの最大許容値は、Xに等しくてもよく、ここで、Xは5よりも小さい。例えば、X=4である。
a. 例えば、five_minus_max_num_subblock_merge_candは、SPSでサポートされるサブブロックベースのマージ動きベクトル予測候補の最大数を5から減算することを規定する。five_minus_max_num_subblock_merge_candの値は、0から4の範囲内である。存在しない場合、five_minus_max_num_subblock_merge_candの値は5に等しいと推測される。
【0102】
25) five_minus_max_num_subblock_merge_candの有効範囲をどのように定義するかは、five_minus_max_num_subblock_mergeが存在するか否かに依存してもよい。
a. 例えば、five_minus_max_num_subblock_mergeの有効範囲は、five_minus_max_num_subblock_mergeが存在する場合にのみ定義される。
b. 例えば、five_minus_max_num_subblock_mergeの異なる有効範囲は、five_minus_max_num_subblock_mergeが存在するか否かに依存して定義される。
c. 例えば、five_minus_max_num_subblock_merge_candは、SPSでサポートされるサブブロックベースのマージ動きベクトル予測候補の最大数を5から減算することを規定する。five_minus_max_num_subblock_merge_candの値は、five_minus_max_num_subblock_merge_candが存在する場合に、0から、5-sps_sbtmvp_enabled_flagの範囲内にあるものとする。存在しない場合、five_minus_max_num_subblock_merge_candの値は5に等しいと推測される。
【0103】
d. 例えば、five_minus_max_num_subblock_merge_candは、SPSでサポートされるサブブロックベースのマージ動きベクトル予測候補の最大数を5から減算することを規定する。存在しない場合、five_minus_max_num_subblock_merge_candの値は5に等しいと推測される。そうでない場合(five_minus_max_num_subblock_merge_candが存在する)、five_minus_max_num_subblock_merge_candの値は、0から、5-sps_sbtmvp_enabled_flagの範囲内にあるものとする。例えば、five_minus_max_num_subblock_merge_candは、SPSでサポートされるサブブロックベースマージ動きベクトル予測候補の最大数を5から減算することを規定する。five_minus_max_num_subblock_merge_candが存在する場合、five_minus_max_num_subblock_merge_candの値は、0から、5-sps_affine_enabled_flagの範囲内にあるものとする。存在しない場合、five_minus_max_num_subblock_merge_candの値は5に等しいと推測される。
e. 例えば、five_minus_max_num_subblock_merge_candは、SPSでサポートされるサブブロックベースのマージ動きベクトル予測候補の最大数を5から減算することを規定する。存在しない場合、five_minus_max_num_subblock_merge_candの値は5に等しいと推測される。そうでない場合(five_minus_max_num_subblock_merge_candが存在する)、five_minus_max_num_subblock_merge_candの値は、0から5-sps_affine_enabled_flag以内の範囲内にあるものとする。
【0104】
f. 例えば、five_minus_max_num_subblock_merge_candは、SPSでサポートされるサブブロックベースのマージ動きベクトル予測候補の最大数を5から減算することを規定する。five_minus_max_num_subblock_merge_candが存在する場合、five_minus_max_num_subblock_merge_candの値は、0から4の範囲内にあるものとする。存在しない場合、five_minus_max_num_subblock_merge_candの値は5に等しいと推測される。
g. 例えば、five_minus_max_num_subblock_merge_candは、SPSでサポートされるサブブロックベースのマージ動きベクトル予測候補の最大数を5から減算することを規定する。存在しない場合、five_minus_max_num_subblock_merge_candの値は5に等しいと推測される。そうでない場合(five_minus_max_num_subblock_merge_candが存在する)、five_minus_max_num_subblock_merge_candの値は、0から4の範囲内にあるものとする。
【0105】
26)10番目の課題を解決するための同一位置のピクチャのCTUサイズについて、以下のような1または複数の解決策が提案されている。
a. 一例において、同一位置の参照ピクチャのCTU/CTBサイズが現在のピクチャのCTU/CTBサイズより大きい(または未満、または等しくない)場合、現在のピクチャより小さい現在のスライス/タイル/タイルグループ/サブピクチャ/ピクチャ/映像ユニットに対して異なるピクチャからの動き情報(例えば、TMVP、およびまたはSbTMVP)を使用するいかなるコーディングツールも、不許可/無効とすることが必要とされる。
b. 1つの例において、インターレイヤ参照ピクチャが、現在のピクチャのCTU/CTBサイズよりも大きい(または小さい、または等しくない)CTU/CTBサイズを有する場合、異なるピクチャ(例えば、TMVP、および/またはSbTMVP)からの動き情報を使用する任意のコーディングツールを、現在のスライス/タイル/タイルグループ/サブピクチャ/映像ユニットに対して不許可/無効とすることが必要とされる。
【0106】
c. 上記の例において、異なるピクチャからの動き情報を使用するコーディングツールが不許可/無効とされている場合、TMVP/SbTMVPの使用の表示は0に等しいことが必要とされる。
i. 一例において、ph_temporal_mvp_enabled_flagは、0に等しいものとする。
【0107】
d. 一例において、異なるピクチャ(例えば、TMVP、および/またはSbTMVP)からの動き情報を使用するコーディングツールの有効化を信号通知するかどうか、またはどのように信号通知するかは、現在の映像ユニットの参照ピクチャリスト(例えば、スライス/ピクチャ)における参照ピクチャのCTUサイズに依存してよい。
i. 一例において、すべての参照ピクチャが、現在の映像ユニットのCTUサイズと異なる(例えば、より小さいまたはより大きい)CTUサイズを有する場合、適合ビットストリームは、時間的動きベクトル予測の使用が無効であることを満たすものとする。
ii. 一例において、すべての参照ピクチャが、現在の映像ユニットのCTUサイズと異なる(例えば、より小さい、またはより大きい)CTUサイズを有する場合、時間的動きベクトル予測の使用の指示(例えば、ph_temporal_mvp_enabled_flag)は、信号通知されない。
1. あるいは、さらに、無効であると推論される。
2. あるいは、さらに、同一位置の参照ピクチャの指示(例えば、sh_collocated_from_l0_flag,sh_collocated_ref_idx、ph_collocated_from_l0_flag、ph_collocated_ref_idx)は、これ以上信号通知されない。
【0108】
e. 一例において、現在のピクチャのCTU/CTBサイズよりも大きい(または小さい、または等しくない)CTU/CTBサイズを有する任意の参照ピクチャは、現在のスライス/タイル/タイルグループ/サブピクチャ/ピクチャ/映像ユニットの同一位置のピクチャであることは、許可されない。
f. 一例において、現在のピクチャのCTU/CTBサイズよりも大きい(または小さい、または等しくない)CTU/CTBサイズを有する任意のピクチャは、現在のスライス/タイル/タイルグループ/サブピクチャ/ピクチャ/映像ユニットの同一位置のピクチャとしてマーク付けすることは、許可されない。
【0109】
g. 一例において、同一位置のピクチャが、現在のピクチャ/スライス/タイル/ブリック/サブピクチャ/ピクチャより小さい映像ユニットに利用されるためには、同一位置のピクチャのCTU/CTBサイズが現在のピクチャ/スライス/タイル/ブリック/サブピクチャ/ピクチャより小さい映像ユニットのCTU/CTBサイズと等しくなることが必要とされる。
i. 一例において、参照ピクチャは、sh_collocated_from_10_flagおよび/またはsh_collocated_ref_idxによって識別される。
ii. 一例において、参照ピクチャは、ph_collocated_from_10_flagおよび/またはph_collocated_ref_idxによって識別される。
h. 一例において、上記同一位置のピクチャは、時間動きベクトル予測に用いられる同一位置のピクチャを示す。
i. 一例において、上記CTU/CTBサイズは、CTUサイズを特定するSPS構文要素(例えば、sps_log2_ctu_size_minus5)によって特定されてもよい。
j. 上記要件は、ビットストリーム制約/適合性として表すことができる。
【0110】
6. 実施形態
以下は、上記第5章に要約されたいくつかの発明の態様のためのいくつかの例示的な実施形態であり、VVC仕様に適用できる。太字のイタリック体において、既に追加または修正された最も関連する部分には下線を付し、削除された部分のうちのいくつかは、[[]]を使用して示す。
【0111】
6.1. 第1の実施形態
本実施例は、1、1.a、1.b、1.c、1.d、3、4.a.i、5、6、7、8、9、9.a、10、11および12b項に関する。
【0112】
7.3.2.3 シーケンスパラメータセット構文
【0113】
【表2】
【0114】
7.4.3.3 シーケンスパラメータセットRBSP意味論
...
【0115】
【化3】
【0116】
1に等しいsubpic_treated_as_pic_flag[i]は、CLVSの各コーディングされたピクチャのi番目のサブピクチャが、インループフィルタリング動作を除く復号処理においてピクチャとして扱われることを規定する。0に等しいsubpic_treated_as_pic_flag[i]は、CLVSの各コーディングされたピクチャのi番目のサブピクチャが、インループフィルタリング動作を除く復号処理においてピクチャとして扱われないことを規定する。存在しない場合、subpic_treated_as_pic_flag[i]の値はsps_independent_subpics_flagに等しいと推論される。
【0117】
【化4】
【0118】
7.4.3.4 ピクチャパラメータセットRBSP意味論
...
【0119】
【化5】
【0120】
scaling_win_left_offset、scaling_win_right_offset、scaling_win_top_offset、およびscaling_win_bottom_offsetは、スケーリング比の計算のためのピクチャサイズに適用されるオフセットを規定する。存在しない場合、scaling_win_left_offset、scaling_win_right_offset、scaling_win_top_offset、scaling_win_bottom_offsetの値は、それぞれpps_conf_win_left_offset、pps_conf_win_right_offset、pps_conf_win_top_offsetおよびpps_conf_win_bottom_offsetと等しいと推論される。
SubWidthC*(scaling_win_left_offset+scaling_win_right_offset)の値は、pic_width_in_luma_samplesより小さいものとし、SubHeightC*(scaling_win_top_offset+scaling_win_bottom_offset)の値は、pic_height_in_luma_samplesより小さいものとする。
【0121】
【化6】
【0122】
PicOutputWidthLおよびPicOutputHeightLの変数は以下のように導出される。
PicOutputWidthL=pic_width_in_luma_samples-SubWidthC*(scaling_win_right_offset+scaling_win_left_offset) (78)
PicOutputHeightL=pic_height_in_luma_samples-SubWidthC*(scaling_win_bottom_offset+scaling_win_top_offset) (79)
【0123】
PicOutputWidthL、およびPicOutputHeightLをそれぞれ、このPPSを参照する現在のピクチャの参照ピクチャのPicOutputWidthL、およびrefPicOutputHeightLとする。ビットストリーム適合性の要件は、以下のすべての条件を満たすことである。
-PicOutputWidthL*2は、refPicWidthInLumaSamples以上であるものとする。
-PicOutputHeightL*2は、refPicHeightInLumaSamples以上であるものとする。
-PicOutputWidthLは、refPicWidthInLumaSamples*8以下であるものとする。
-PicOutputHeightLは、refPicHeightInLumaSamples*8以下であるものとする。
-PicOutputWidthL*pic_width_max_in_luma_samplesは、refPicOutputWidthL*(pic_width_in_luma_samples-Max(8,MinCbSizeY)以上であるものとする。
-PicOutputHeightL*pic_height_max_in_luma_samplesは、refPicOutputHeightL*(pic_height_in_luma_samples-Max(8,MinCbSizeY))以上であるものとする。
...
【0124】
7.2.3.2 一般的な制約情報構文
【0125】
【表3】
【0126】
7.4.4.2 一般的な制約情報意味論
...
【0127】
【化7】
【0128】
7.4.8.1 一般スライスヘッダ意味論
...
1に等しいslice_collocated_from_l0_flagは、時間的動きベクトル予測に使用される同一位置のピクチャが参照ピクチャリスト0から導出されることを規定する。0に等しいslice_collocated_from_I0_flagは、時間的動きベクトル予測に使用される同一位置のピクチャが参照ピクチャリスト1から導出されることを規定する。
slice_typeがBまたはPであり、ph_temporal_mvp_enabled_flagが1に等しく、かつ、slice_collocated_from_l0_flagが存在しない場合、以下が適用される。
-rpl_info_in_ph_flagが1に等しい場合、slice_collocated_from_l0_flagは、ph_collocated_from_l0_flagに等しいと推論される。
-そうでない場合(rpl_info_in_ph_flagが0に等しく、かつ、slice_typeがPに等しい場合)、slice_collocated_from_l0_flagの値は1に等しいと推論される。
【0129】
slice_collocated_ref_idxは、時間的動きベクトル予測に使用される同一位置のピクチャの参照インデックスを規定する。
slice_typeがPに等しい場合、またはslice_typeがBに等しく、かつ、slice_collocated_from_l0_flagが1に等しい場合、slice_collocated_ref_idxは、参照ピクチャリスト0のエントリを参照し、slice_collocated_ref_idxの数値は、0からNumRefIdxActive[0]-1の範囲内にあるものとする。
slice_typeがBに等しく、かつ、slice_collocated_from_l0_flagが0に等しい場合、slice_collocated_ref_idxの値は、参照ピクチャリスト1のエントリを参照し、slice_collocated_ref_idxは、0からNumRefIdxActive[1]-1の範囲内にあるものとする。
【0130】
【化8】
【0131】
slice_collocated_ref_idxにて参照される参照ピクチャのpic_width_in_luma_samplesとpic_height_in_luma_samplesの値は、それぞれ現在のピクチャのpic_width_in_luma_samplesとpic_height_in_luma_samplesの値と同じであるものとし、RprConstraintsActive[slice_collocated_from_l0_flag?0:1][slice_collocated_ref_idx]は0に等しいものとすることが、ビットストリーム適合性の要件である。
...
【0132】
8.5.3.2.2 輝度サンプル双線形補間処理
...
【0133】
【化9】
【0134】
8.5.6.3.2 輝度サンプル補間フィルタリング処理
...
【0135】
【化10】
【0136】
8.5.6.3.3 輝度整数サンプルフェッチ処理
...
【0137】
【化11】
【0138】
8.5.6.3.4 彩度サンプル補間処理
...
【0139】
【化12】
【0140】
代替的に、強調表示された部分「かつ、参照ピクチャrefPicLXのsps_num_subpics_minus1が0よりも大きい」を、「かつ、参照ピクチャrefPicLXが現在のピクチャと同じ空間的解像度を有するILRPである場合」に置き換えてもよい。
代替的に、強調表示された部分「または、参照ピクチャrefPicLXのsps_num_subpics_minus1が0に等しい」を、「または、参照ピクチャrefPicLXが現在のピクチャとは異なる空間的解像度を有するILRPである場合」に置き換えてもよい。
【0141】
【化13】
【0142】
6.2. 第二の実施形態
【0143】
【化14】
【0144】
【化15】
【0145】
【化16】
【0146】
【化17】
【0147】
【化18】
【0148】
6.3. 第3の実施形態
本実施例では、ALFおよびCC-ALFフィルタの最大数の制限に関する以下の点を提案する。
【0149】
1) ALF APSの個数に関する制約をフィルタの個数に関する制約に置き換え、より具体的には、以下の制約を追加することが提案される。
【0150】
PUのための全てのAPS NALユニットにおいて、輝度成分の適応ループフィルタクラスの総数、彩度成分の代替フィルタの総数、およびクロスコンポーネントフィルタの総数がそれぞれ200、64、64と等しいまたはそれらより小さい
【0151】
2) 項目1)に加えて、APS構文におけるAPS IDのコーディングをu(5)からu(v)に変更し、ALF、LMCS、スケーリングリストAPSはそれぞれ9、2、3の長さとする。
【0152】
3) 項目1)に加えて、さらにPHとSHにおけるALF APSインデックスのコーディングとALF APSの数をu(v)からue(v)へと変更する。
【0153】
7.3.2.5 適応パラメータセットRBSP構文
【0154】
【表4】
【0155】
7.3.2.7 ピクチャヘッダ構造構文
【0156】
【表5】
【0157】
7.3.7.1 一般的なスライスセグメントヘッダ構文
【0158】
【表6】
【0159】
7.4.3.5 適応パラメータセット意味論
各APS RBSPは、それが参照される前に復号処理で利用できるか、それを参照するコーディングされたスライスNALユニットのTemporalId以下のTemporalIdを持つ少なくとも一つのAU内に含まれるか、外部手段を通じて提供されるものとする。
adaptation_parameter_set_idの特定の値を有し、かつPU内のaps_params_typeの特定の値を有するすべてのAPS NALユニットは、それらがプレフィクスであるかサフィックスAPS NALユニットであるかどうかに関わらず、同じコンテンツを有するものとする。
adaptation_parameter_set_idは、他の構文要素が参照するAPSの識別子を提供する。構文要素adaptation_parameter_set_idの長さは、ビットにおいて、aps_params_type=ALF_APS?9:(aps_params_type==LMCS_APS?2:3)である。
【0160】
【化19】
【0161】
apsLayerIdを特定のAPS NALユニットのnuh_layer_idの値とし、vclLayerIdを特定のVCL NALユニットのnuh_layer_idの値とする。apsLayerIdがvclLayerId以下であり、かつ、apsLayerIdに等しいnuh_layer_idを有するレイヤが、vclLayerIdに等しいnuh_layer_idを有するレイヤを含む少なくとも1つのOLSに含まれていない限り、特定のVCL NALユニットは、特定のAPS NALユニットを参照しないものとする。
aps_params_typeは、表6に示されるように、APSにおいて実行されるAPSパラメータのタイプを規定する。
【0162】
【化20】
【0163】
【化21】
【0164】
【化22】
【0165】
【化23】
【0166】
【化24】
【0167】
上記の例において、代わりに以下のものを使用してもよい。
adaptation_parameter_set_idは、他の構文要素が参照するAPSの識別子を提供する。構文要素adaptation_parameter_set_idの長さは、ビットにおいて、Mが3より大きい(例えば4、5、6、7、8、9)である、aps_params_type=ALF_APS?M:(aps_params_type==LMCS_APS?2:3)である。
「200、64、64」の値は、他のゼロでない整数値に置き換えてもよい。
「327」の値は、ゼロでない他の整数値に置き換えてもよい。
【0168】
6.4. 第4の実施形態
本実施例において、同一位置の参照ピクチャをどのように制約するかについてのいくつかの例が提供される。
1に等しいsh_collocated_from_l0_flagは、時間的動きベクトル予測に使用される同一位置のピクチャが参照ピクチャリスト0から導出されることを規定する。0に等しいsh_collocated_from_l0_flagは、時間的動きベクトル予測に使用される同一位置のピクチャが参照ピクチャリスト1から導出されることを規定する。
sh_slice_typeがBまたはPであり、ph_temporal_mvp_enabled_flagが1に等しく、かつ、sh_collocated_from_l0_flagが存在しない場合、以下が適用される。
-sh_slice_typeがBに等しい場合、sh_collocated_from_l0_flagは、ph_collocated_from_l0_flagに等しいと推論される。
-そうでない場合(sh_slice_typeがPに等しい)、sh_collocated_from_10_flagの値は、1に等しいと推論される。
【0169】
sh_collocated_ref_idxは、時間的動きベクトル予測に使用される同一位置のピクチャの参照インデックスを規定する。
sh_slice_typeがPである場合、または、sh_slice_typeがBに等しく、かつ、sh_collocated_from_l0_flagが1に等しい場合は、sh_collocated_ref_idxは、参照ピクチャリスト0のエントリを参照するsh_collocated_ref_idxの値は、0からNumRefIdxActive[0]-1の範囲内にあるものとする。
sh_slice_typeがBに等しく、かつ、sh_collocated_from_l0_flagが0に等しい場合、sh_collocated_ref_idxの値は、参照ピクチャリスト1のエントリを参照し、sh_collocated_ref_idxは、0からNumRefIdxActive[1]-1の範囲内にあるものとする。
【0170】
sh_collocated_ref_idxが存在しない場合、以下が適用される。
-pps_rpl_info_in_ph_flagが1に等しい場合、sh_collocated_ref_idxの値は、ph_collocated_ref_idxに等しいと推論される。
-そうでない場合(pps_rpl_info_in_ph_flagが0に等しい)、sh_collocated_ref_idxの値は、0に等しいと推論される。
【0171】
【化25】
【0172】
図5は、本明細書で開示される様々な技術が実装され得る例示的な映像処理システム1900を示すブロック図である。様々な実装形態は、システム1900のコンポーネントの一部または全部を含んでもよい。システム1900は、映像コンテンツを受信するための入力1902を含んでもよい。映像コンテンツは、未加工または非圧縮フォーマット、例えば、8または10ビットのマルチコンポーネント画素値で受信されてもよく、または圧縮または符号化されたフォーマットで受信されてもよい。入力1902は、ネットワークインタフェース、周辺バスインタフェース、または記憶インタフェースを表してもよい。ネットワークインタフェースの例は、イーサネット(登録商標)、PON(Passive Optical Network)等の有線インタフェース、およびWi-Fi(登録商標)またはセルラーインタフェース等の無線インタフェースを含む。
【0173】
システム1900は、本明細書に記載される様々なコーディングまたは符号化方法を実装することができるコーディングコンポーネント1904を含んでもよい。コーディングコンポーネント1904は、入力1902からの映像の平均ビットレートをコーディングコンポーネント1904の出力に低減し、映像のコーディング表現を生成してもよい。従って、このコーディング技術は、映像圧縮または映像コード変換技術と呼ばれることがある。コーディングコンポーネント1904の出力は、コンポーネント1906によって表されるように、記憶されてもよいし、接続された通信を介して送信されてもよい。入力1902において受信された、記憶されたまたは通信された映像のビットストリーム(またはコーディングされた)表現は、コンポーネント1908によって使用されて、表示インタフェース1910に送信される画素値または表示可能な映像を生成してもよい。ビットストリーム表現からユーザが見ることができる映像を生成する処理は、映像展開と呼ばれることがある。さらに、特定の映像処理動作を「コーディング」動作またはツールと呼ぶが、コーディングツールまたは動作は、エンコーダおよびそれに対応する、コーディングの結果を逆にするデコーデイングツールまたは動作が、デコーダによって行われることが理解されよう。
【0174】
周辺バスインタフェースまたは表示インタフェースの例は、USB(Universal Serial Bus)またはHDMI(High Definition Multimedia Interface;登録商標)またはディスプレイポート等を含んでもよい。ストレージインタフェースの例は、SATA(Serial Advanced Technology Attachment)、PCI、IDEインタフェース等を含む。本明細書に記載される技術は、携帯電話、ノートパソコン、スマートフォン、またはデジタルデータ処理および/または映像表示を実施可能な他のデバイス等の様々な電子デバイスに実施されてもよい。
【0175】
図6は、映像処理装置3600のブロック図である。装置3600は、本明細書に記載の方法の1または複数を実装するために使用されてもよい。装置3600は、スマートフォン、タブレット、コンピュータ、IoT(Internet of Things)受信機等に実施されてもよい。装置3600は、1または複数のプロセッサ3602と、1または複数のメモリ3604と、映像処理ハードウェア3606と、を含んでもよい。1または複数のプロセッサ3602は、本明細書に記載される1または複数の方法を実装するように構成されてもよい。1または複数のメモリ3604は、本明細書で説明される方法および技術を実装するために使用されるデータおよびコードを記憶するために使用してもよい。映像処理ハードウェア3606は、本明細書に記載される技術をハードウェア回路にて実装するために使用してもよい。
【0176】
図8は、本開示の技法を利用し得る例示的な映像コーディングシステム100を示すブロック図である。
【0177】
図8に示すように、映像コーディングシステム100は、送信元デバイス110と、送信先デバイス120と、を含んでよい。送信元デバイス110は、符号化映像データを生成するものであり、映像符号化デバイスとも呼ばれ得る。送信先デバイス120は、送信元デバイス110によって生成された、符号化された映像データを復号してよく、映像復号デバイスと呼ばれ得る。
【0178】
送信元デバイス110は、映像ソース112、映像エンコーダ114、および入出力(I/O)インタフェース116、を含んでよい。
【0179】
映像ソース112は、映像キャプチャデバイスなどのソース、映像コンテンツプロバイダからの映像データを受信するためのインタフェース、および/または映像データを生成するためのコンピュータグラフィックスシステム、またはこれらのソースの組み合わせを含んでよい。映像データは、1または複数のピクチャを含んでよい。映像エンコーダ114は、映像ソース112からの映像データを符号化し、ビットストリームを生成する。ビットストリームは、映像データのコーディング表現を形成するビットのシーケンスを含んでもよい。ビットストリームは、コーディングされたピクチャおよび関連付けられたデータを含んでもよい。コーディングされたピクチャは、ピクチャのコーディングされた表現である。関連付けられたデータは、シーケンスパラメータセット、ピクチャパラメータセット、および他の構文構造を含んでもよい。I/Oインタフェース116は、変復調器(モデム)および/または送信機を含んでもよい。エンコードされた映像データは、ネットワーク130aを介して、I/Oインタフェース116を介して送信先デバイス120に直接送信されてよい。エンコードされた映像データは、送信先デバイス120がアクセスするために、記録媒体/サーバ130bに記憶してもよい。
【0180】
送信先デバイス120は、I/Oインタフェース126、映像デコーダ124、および表示装置122を含んでもよい。
【0181】
I/Oインタフェース126は、受信機および/またはモデムを含んでもよい。I/Oインタフェース126は、送信元デバイス110または記憶媒体/サーバ130bから符号化された映像データを取得してもよい。映像デコーダ124は、符号化された映像データを復号してもよい。表示装置122は、復号された映像データをユーザに表示してもよい。表示装置122は、送信先デバイス120と一体化されてもよく、または外部表示装置とインタフェースで接続するように構成される送信先デバイス120の外部にあってもよい。
【0182】
映像エンコーダ114および映像デコーダ124は、HEVC(High Efficiency Video Coding)規格、VVM(Versatile Video Coding)規格、および他の現在のおよび/またはさらなる規格等の映像圧縮規格に従って動作してもよい。
【0183】
図9は、映像エンコーダ200の一例を示すブロック図であり、この映像エンコーダ200は、図8に示されるシステム100における映像エンコーダ114であってもよい。
【0184】
映像エンコーダ200は、本開示の技術のいずれかまたは全部を行うように構成されてもよい。図9の実施例において、映像エンコーダ200は、複数の機能性モジュールを含む。本開示で説明される技法は、映像エンコーダ200の様々なコンポーネント間で共有されてもよい。いくつかの例では、プロセッサは、本開示で説明される技術のいずれかまたはすべてを行うように構成してもよい。
【0185】
映像エンコーダ200の機能コンポーネントは、分割部201、予測部202、残差生成部207、変換部208、量子化部209、逆量子化部210、逆変換部211、再構成部212、バッファ213、およびエントロピー符号化部214を含んでもよく、予測部202は、モード選択部203、動き推定部204、動き補償部205、およびイントラ予測部206を含む。
【0186】
他の例において、映像エンコーダ200は、より多くの、より少ない、または異なる機能コンポーネントを含んでもよい。一例において、予測部202は、IBC(Intra Block Copy)部を含んでもよい。IBC部は、少なくとも1つの参照ピクチャが、現在の映像ブロックが位置するピクチャであるIBCモードにおいて予測を実行してもよい。
【0187】
さらに、動き推定部204および動き補償部205などのいくつかのコンポーネントは、高度に統合されてもよいが、説明のために、図9の例においては別個に表現されている。
【0188】
分割部201は、ピクチャを1または複数の映像ブロックに分割してもよい。映像エンコーダ200および映像デコーダ300は、様々な映像ブロックサイズをサポートしてもよい。
【0189】
モード選択部203は、例えば、誤りの結果に基づいて、イントラまたはインターのコーディングモードのうちの1つを選択し、得られたイントラまたはインターコーディングされたブロックを、残差ブロックデータを生成するために残差生成部207に供給し、符号化されたブロックを参照ピクチャとして使用するために再構成するために再構成部212に供給してもよい。いくつかの例において、モード選択部203は、インター予測信号およびイントラ予測信号に基づいて予測を行うCIIP(Combination of Intra and Inter Prediction)モードを選択してもよい。モード選択部203は、インター予測の場合、ブロックのために動きベクトルの解像度(例えば、サブピクセルまたは整数ピクセル精度)を選択してもよい。
【0190】
現在の映像ブロックに対してインター予測を行うために、動き推定部204は、バッファ213からの1または複数の参照フレームと現在の映像ブロックとを比較することにより、現在の映像ブロックに対する動き情報を生成してもよい。動き補償部205は、動き情報および現在の映像ブロックに関連付けられたピクチャ以外のバッファ213からのピクチャの復号されたサンプルに基づいて、現在の映像ブロックに対する予測映像ブロックを決定してもよい。
【0191】
動き推定部204および動き補償部205は、現在の映像ブロックがIスライスであるか、Pスライスであるか、またはBスライスであるかに基づいて、例えば、現在の映像ブロックに対して異なる動作を行ってもよい。
【0192】
いくつかの例において、動き推定部204は、現在の映像ブロックに対して単方向予測を実行し、動き推定部204は、現在の映像ブロックに対する参照映像ブロックのために、リスト0またはリスト1の参照ピクチャを検索してもよい。動き推定部204は、参照映像ブロックと、現在の映像ブロックと参照映像ブロックとの間の空間的変位を示す動きベクトルとを含む、リスト0またはリスト1における参照ピクチャを示す参照インデックスを生成してもよい。動き推定部204は、参照インデックス、予測方向インジケータ、および動きベクトルを、現在の映像ブロックの動き情報として出力してもよい。動き補償部205は、現在の映像ブロックの動き情報が示す参照映像ブロックに基づいて、現在のブロックの予測映像ブロックを生成してもよい。
【0193】
他の例において、動き推定部204は、現在の映像ブロックを双方向予測してもよく、動き推定部204は、現在の映像ブロックに対する参照映像ブロックについて、リスト0から参照ピクチャを検索してもよく、また、現在の映像ブロックに対する別の参照映像ブロックについて、リスト1における参照ピクチャも検索してもよい。そして、動き推定部204は、参照映像ブロックを含むリスト0およびリスト1における参照ピクチャを示す参照インデックスと、参照映像ブロックと現在の映像ブロックとの間の空間的変位を示す動きベクトルとを生成してもよい。動き推定部204は、現在の映像ブロックの参照インデックスおよび動きベクトルを、現在の映像ブロックの動き情報として出力してもよい。動き補償部205は、現在の映像ブロックの動き情報が示す参照映像ブロックに基づいて、現在の映像ブロックの予測映像ブロックを生成してもよい。
【0194】
いくつかの例において、動き推定部204は、デコーダの復号処理のために、動き情報のフルセットを出力してもよい。
【0195】
いくつかの例では、動き推定部204は、現在の映像のための動き情報のフルセットを出力しなくてもよい。むしろ、動き推定部204は、別の映像ブロックの動き情報を参照して、現在の映像ブロックの動き情報を信号通知してもよい。例えば、動き推定部204は、現在の映像ブロックの動き情報が近傍の映像ブロックの動き情報に十分に類似していることを判定してもよい。
【0196】
一例において、動き推定部204は、現在の映像ブロックに関連付けられた構文構造において、現在の映像ブロックが別の映像ブロックと同一の動き情報を有することを映像デコーダ300に示す値を示してもよい。
【0197】
他の例において、動き推定部204は、現在の映像ブロックに関連付けられた構文構造において、別の映像ブロックと、MVD(Motion Vector Difference)とを識別してもよい。動きベクトル差分は、現在の映像ブロックの動きベクトルと、示された映像ブロックの動きベクトルとの差分を示す。映像デコーダ300は、指定された映像ブロックの動きベクトルと動きベクトル差分とを使用して、現在の映像ブロックの動きベクトルを決定してもよい。
【0198】
上述したように、映像エンコーダ200は、動きベクトルを予測的に信号通知してもよい。映像エンコーダ200によって実装され得る予測信号通知技法の2つの例は、AMVP(Advanced Motion Vector Prediction)およびマージモード信号通知を含む。
【0199】
イントラ予測部206は、現在の映像ブロックに対してイントラ予測を行ってもよい。イントラ予測部206が現在の映像ブロックにおいてイントラ予測を実行する場合、イントラ予測部206は、同じピクチャにおける他の映像ブロックの復号されたサンプルに基づいて、現在の映像ブロックのための予測データを生成してもよい。現在の映像ブロックのための予測データは、予測された映像ブロックおよび様々な構文要素を含んでもよい。
【0200】
残差生成部207は、現在の映像ブロックから現在の映像ブロックの予測された映像ブロックを減算することによって(例えば、マイナス符号によって示されている)、現在の映像ブロックに対する残差データを生成してもよい。現在の映像ブロックの残差データは、現在の映像ブロックにおけるサンプルの異なるサンプル成分に対応する残差映像ブロックを含んでもよい。
【0201】
他の例において、例えば、スキップモードにおいて、現在の映像ブロックに対する残差データがなくてもよく、残差生成部207は、減算動作を行わなくてもよい。
【0202】
変換処理部208は、現在の映像ブロックに関連付けられた残差映像ブロックに1または複数の変換を適用することによって、現在の映像ブロックのための1または複数の変換係数映像ブロックを生成してもよい。
【0203】
変換処理部208が現在の映像ブロックに関連付けられた変換係数映像ブロックを生成した後、量子化部209は、現在の映像ブロックに関連付けられた1または複数の量子化パラメータ(QP:Quantization Parameter)値に基づいて、現在の映像ブロックに関連付けられた変換係数映像ブロックを量子化してもよい。
【0204】
逆量子化部210および逆変換部211は、変換係数映像ブロックに逆量子化および逆変換をそれぞれ適用し、変換係数映像ブロックから残差映像ブロックを再構成してもよい。再構成部212は、予測部202によって生成された1または複数の予測映像ブロックに対応するサンプルに再構成された残差映像ブロックを追加して、バッファ213に格納するための現在のブロックに関連付けられた再構成された映像ブロックを生成してもよい。
【0205】
再構成部212が映像ブロックを再構成した後、映像ブロックにおける映像ブロッキングアーチファクトを縮小するために、ループフィルタリング動作が行われてもよい。
【0206】
エントロピー符号化部214は、映像エンコーダ200の他の機能コンポーネントからデータを受信してもよい。エントロピー符号化部214がデータを受信した場合、エントロピー符号化部214は、1または複数のエントロピー符号化動作を行い、エントロピー符号化されたデータを生成し、エントロピー符号化されたデータを含むビットストリームを出力してもよい。
【0207】
図10は、映像デコーダ300の一例を示すブロック図であり、この映像デコーダ300は、図8に示すシステム100における映像デコーダ114であってもよい。
【0208】
映像デコーダ300は、本開示の技術のいずれかまたは全てを行うように構成されてもよい。図10の例において、映像デコーダ300は、複数の機能コンポーネントを含む。本開示で説明される技術は、映像デコーダ300の様々なコンポーネント間で共有されてもよい。いくつかの例では、プロセッサは、本開示で説明される技術のいずれかまたはすべてを行うように構成してもよい。
【0209】
図10の例において、映像デコーダ300は、エントロピー復号部301、動き補正部302、イントラ予測部303、逆量子化部304、逆変換部305、および再構成部306、並びにバッファ307を備える。映像デコーダ300は、いくつかの例では、映像エンコーダ200(図9)に関して説明した符号化パスとほぼ逆の復号パスを行ってもよい。
【0210】
エントロピー復号部301は、符号化されたビットストリームを取り出す。符号化されたビットストリームは、エントロピーコーディングされた映像データ(例えば、映像データの符号化されたブロック)を含んでもよい。エントロピー復号部301は、エントロピーコーディングされた映像データを復号してよく、エントロピー復号された映像データから、動き補償部302は、動きベクトル、動きベクトル精度、参照ピクチャリストインデックス、および他の動き情報を含む動き情報を決定してもよい。動き補償部302は、例えば、AMVPおよびマージモードを行うことで、このような情報を決定してもよい。
【0211】
動き補償部302は、動き補償されたブロックを生成してもよく、場合によっては、補間フィルタに基づいて補間を行う。サブピクセルの精度で使用される補間フィルタのための識別子が、構文要素に含まれてもよい。
【0212】
動き補償部302は、映像ブロックの符号化中に映像エンコーダ200によって使用されるような補間フィルタを使用して、参照ブロックのサブ整数画素のための補間値を計算してもよい。動き補償部302は、受信した構文情報に基づいて、映像エンコーダ200により使用される補間フィルタを決定し、予測ブロックを生成するために補間フィルタを使用してしてもよい。
【0213】
動き補償部302は、符号化された映像シーケンスのフレームおよび/またはスライスを符号化するために使用されるブロックのサイズを決定するための構文情報、符号化された映像シーケンスのピクチャの各マクロブロックがどのように分割されるかを記述する分割情報、各分割がどのように符号化されるかを示すモード、各インター符号化されたブロックに対する1または複数の参照フレーム(および参照フレームリスト)、および符号化された映像シーケンスを復号するための他の情報のうちいくつかを使用してもよい。
【0214】
イントラ予測部303は、例えば、ビットストリームにおいて受信したイントラ予測モードを使用して、空間的に隣接するブロックから予測ブロックを形成してもよい。逆量子化部303は、ビットストリームに提供され、エントロピー復号部301によって復号された量子化された映像ブロック係数を逆量子化(例えば、逆量子化)する。逆変換部303は、逆変換を適用する。
【0215】
再構成部306は、残差ブロックと、動き補償部202またはイントラ予測部303によって生成された対応する予測ブロックとを合計し、復号されたブロックを形成してもよい。所望であれば、ブロックアーチファクトを除去するために、復号されたブロックをフィルタリングするためにデブロッキングフィルタを適用してもよい。復号された映像ブロックは、バッファ307に記憶され、バッファ307は、後続の動き補償/イントラ予測のために参照ブロックを提供し、表示装置に表示するために復号された映像を生成する。
【0216】
次に、いくつかの実施形態において好適な解決策を列挙する。
【0217】
以下の解決策は、前章(例えば、項目1)で論じた技術の例示的な実施形態を示す。
【0218】
1.映像処理方法(例えば、図7に示される映像処理方法700)であって、1または複数の映像ピクチャを含む映像との間で変換を実行すること(702)を含み、コーディングされた表現がフォーマット規則に準拠し、フォーマット規則は、シーケンスパラメータセットにおける2つ以上の構文フィールドが映像のRPR(Reference Picture Resolution)の変更を制御することを規定する。
【0219】
2.2つ以上の構文フィールドの第1の構文フィールドは、RPRが1または複数のピクチャのために使用されるかどうかを示し、2つ以上の構文フィールドの第2の構文フィールドは、コーディングされた表現においてシーケンスレベルでピクチャ解像度を変更することができるかどうかを示す、解決策1に記載の方法。
【0220】
以下の解決策は、前章(例えば、項目2)で論じた技術の例示的な実施形態を示す。
【0221】
3.映像処理方法であって、1または複数の映像ピクチャを含む映像との間の変換を実行することを含み、コーディングされた表現はフォーマット規則に準拠し、フォーマット規則は、シーケンスパラメータセットにおける単一の構文フィールドが映像のRPR(Reference Picture Resolution)の変更を制御することを規定し、フォーマット規則は、単一の構文フィールドの値に関わらず、インターレイヤ参照ピクチャのリサンプリングが変換に対して許可されることを規定する。
【0222】
以下の解決策は、前章(例えば、項目3,5,6,7,9、10)で論じた技術の例示的な実施形態を示す。
【0223】
4.映像処理方法であって、1または複数のサブピクチャを含む1または複数の映像ピクチャを含む1または複数のレイヤを含む映像との間の変換を実行することを含み、コーディングされた表現は、フォーマット規則に準拠し、フォーマット規則は、クロスレイヤアライメントに対する第1の制約、または、サブピクチャの組合せおよびインターレイヤピクチャのスケーラビリティに対する第2の制約を規定する。
【0224】
5.第1の制約は、現在のレイヤの下のレイヤおよび現在のレイヤに依存しないすべての上のレイヤにアラインメント制限を課すことなく、現在のレイヤおよび現在のレイヤに依存するすべての上のレイヤへのクロスレイヤアライメント制限を規定する、解決策4に記載の方法。
【0225】
6.第2の制約は、特定のレイヤの各従属ツリーにおけるすべてのレイヤにクロスレイヤアライメント制限を課す、解決策4に記載の方法。
【0226】
7.第2の制約は、クロスレイヤアライメント制限に従って、subpic_treated_as_pic_flag[i]の値を制限する、解決策4に記載の方法。
【0227】
8.第2の制約は、クロスレイヤアライメント制限に従って、loop_filter_across_subpic_enabled_flag[i]の値を制限する、解決策4に記載の方法。
【0228】
9.第1の制約および/または第2の制約は、アクセスユニットのターゲットセットに対して規定される、解決策4から解決策8のいずれか1つに記載の方法。
【0229】
10.第2の制約は、クロスレイヤアライメント制限に従って、スケーリングウィンドウパラメータscaling_win_left_offset、scaling_win_right_offset、scaling_win_top_offset、およびscaling_win_bottom_offsetの各々の値を制限する、解決策4に記載の方法。
【0230】
以下の解決策は、前章(例えば、項目11)で論じた技術の例示的な実施形態を示す。
【0231】
11.映像処理方法であって、1または複数のサブピクチャを含む1または複数のレイヤを含む映像の間の変換を実行することを含み、変換は、インターレイヤ参照ピクチャまたは長期参照ピクチャが、現在のピクチャの同一位置のピクチャであることを変換に対して許可されないことを規定するフォーマット規則に準拠する。
【0232】
以下の解決策は、前章(例えば、項目12)で論じた技術の例示的な実施形態を示す。
【0233】
12.映像処理方法であって、複数のピクチャを含む映像と映像のコーディングされた表現との間の変換を実行することを含み、変換は、scaling_win_left_offset、scaling_win_right_offset、scaling_win_top_offset、およびscaling_win_bottom_offsetのそれぞれの値が、pic_width_in_luma_samplesおよびpic_height_in_luma_samplesの同じ値を有する同じコーディングされたレイヤ映像シーケンスまたはコーディングされた映像シーケンス内の任意の2つのピクチャに対して同じであることを規定する規則に準拠する。
【0234】
以下の解決策は、前章(例えば、項目13)で論じた技術の例示的な実施形態を示す。
【0235】
13.映像処理方法であって、複数のピクチャを含む映像と、映像のコーディングされた表現との間の変換を実行することを含み、変換は、同じアクセスユニット内の現在のピクチャと他のピクチャとでピクチャの解像度またはスケーリングウィンドウが異なる場合、現在のピクチャがイントラランダムアクセスポイントピクチャである場合にのみ、インターレイヤ予測を許可することを規定する規則に準拠する。
【0236】
以下の解決策は、前章(例えば、項目20)で論じた技術の例示的な実施形態を示す。
【0237】
14.映像処理方法であって、映像の現在のピクチャの映像ブロックと映像のコーディングされた表現との変換のために、同一位置の映像ピクチャまたはインターレイヤピクチャ内の映像ブロックの第2のサイズと比較した映像ブロックの第1のサイズに基づいて規則を適用すべきかどうかを決定することと、決定に基づいて変換を実行することとを含む。
【0238】
15.規則は、第1のサイズが第2のサイズよりも大きい場合、異なるピクチャからの動き情報を現在のピクチャにおける変換に使用できないようにすることを規定する、解決策14に記載の方法。
【0239】
16.規則は、第1のサイズが第2のサイズよりも大きい場合、異なるピクチャからの動き情報を現在のピクチャにおける変換に使用できないようにすることを規定する、解決策14に記載の方法。
【0240】
上記解決策において、映像ブロックは、コーディングツリーユニットまたはコーディングツリーブロックに対応してもよい。
【0241】
17. 変換は、映像をコーディングされた表現に符号化することを含む、解決策1から16のいずれかに記載の方法。
【0242】
18. 変換は、映像の画素値を生成するためにコーディングされた表現を復号することを含む、解決策1から16のいずれかに記載の方法。
【0243】
19. 解決策1から18の1または複数に記載の方法を実装するように構成されたプロセッサを備える、映像復号装置。
【0244】
20. 解決策1から18の1または複数に記載の方法を実装するように構成されたプロセッサを備える、映像符号化装置。
【0245】
21. コンピュータコードが記憶されたコンピュータプログラム製品であって、コードは、プロセッサにより実行されると、プロセッサに、解決策1から18のいずれかに記載の方法を実装させるコンピュータプログラム製品。
【0246】
22.本明細書に記載の方法、装置またはシステム。
【0247】
図13は、本技術にしたがった映像処理方法1300を示すフローチャートである。方法1300は、動作1310において、規則に従って、映像の現在のピクチャの映像ユニットと映像のビットストリームとの間の変換を実行することを含む。規則は、所与のピクチャがその動き情報を変換に用いる参照ピクチャとして利用可能にするために、所与のピクチャが現在のピクチャと同じコーディングツリーユニットサイズまたは同じコーディングツリーブロックサイズを有することを規定する。
【0248】
いくつかの実施形態において、規則は、異なるコーディングツリーユニットのサイズまたは異なるコーディングツリーブロックのサイズを有する所定のピクチャに応答して、動き情報を用いるコーディングツールを無効にすることを規定する。いくつかの実施形態において、映像ユニットは、スライスを含む。いくつかの実施形態において、動き情報は時間的動きベクトル予測に用いられる。いくつかの実施形態において、動き情報はサブブロックベースの時間的動きベクトル予測に用いられる。
【0249】
いくつかの実施形態において、所定のピクチャは同一位置のピクチャである。いくつかの実施形態において、同一位置のピクチャは、同一位置のピクチャのリストと、時間的動きベクトル予測に用いられる同一位置のピクチャの参照インデックスを規定するインデックスによって識別される。いくつかの実施形態において、同一位置のクチャのリストは、時間的動きベクトル予測に用いられる同一位置のピクチャが参照ピクチャリスト0または参照ピクチャリスト1から導出されたものであるかどうかを規定する第1の構文フラグによって判定される。いくつかの実施形態において、第1の構文フラグはsh_collocated_from_l0_flagであり、参照インデックスはsh_collocated_ref_idxと表される。いくつかの実施形態において、同一位置のピクチャのコーディングツリーユニットのサイズは、各コーディングツリーユニットのサイズを規定するシーケンスパラメータセットにおける変数で表される。いくつかの実施形態において、変数はsps_log2_ctu_size_minus5で表される。
【0250】
いくつかの実施形態において、所定のピクチャはインターレイヤピクチャである。いくつかの実施形態において、ピクチャヘッダにおける第2の構文フラグは動き情報の使用が無効にされることを規定する。いくつかの実施形態において、第2の構文フラグはph_temporal_mvp_enabled_flagで表される。
【0251】
いくつかの実施形態において、動き情報を用いるコーディングツールを変換に用いるか否かおよびどのように用いるかは、映像ユニットの1または複数の参照ピクチャリストにおける参照ピクチャのコーディングツリーユニットサイズに基づく。いくつかの実施形態において、コーディングツールは、現在のピクチャとは異なるコーディングツリーユニットのサイズまたは異なるコーディングツリーブロックのサイズを有するすべての参照ピクチャに応答して無効にされる。
【0252】
いくつかの実施形態において、変換は、映像をビットストリームに符号化することを含む。いくつかの実施形態において、変換は、ビットストリームから映像を復号することを含む。
【0253】
本明細書に記載の解決策において、エンコーダは、フォーマット規則に従ってコーディング表現を生成することで、フォーマット規則に準拠することができる。本明細書に記載の解決策において、デコーダは、フォーマット規則に従って、構文要素の有無を知りつつ、コーディング表現における構文要素を構文解析することで、復号された映像を生成するために、このフォーマット規則を使用してもよい。
【0254】
本明細書では、「映像処理」という用語は、映像符号化、映像復号、映像圧縮、または映像展開を指してよい。例えば、映像圧縮アルゴリズムは、映像の画素表現から対応するビットストリーム表現への変換中、またはその逆の変換中に適用されてもよい。現在の映像ブロックのビットストリーム表現は、例えば、構文によって規定されるように、ビットストリーム内の同じ場所または異なる場所に拡散されるビットに対応していてもよい。例えば、マクロブロックは、変換およびコーディングされた誤り残差値の観点から、また、ビットストリームにおけるヘッダおよび他のフィールドにおけるビットを使用して符号化されてもよい。さらに、変換中、デコーダは、上記解決策で説明されているように、判定に基づいて、いくつかのフィールドが存在しても存在しなくてもよいという知識を持って、ビットストリームを構文解析してもよい。同様に、エンコーダは、特定の構文フィールドが含まれるべきであるか、または含まれないべきであるかを判定し、構文フィールドをコーディングされた表現に含めるか、またはコーディングされた表現から除外することによって、それに応じてコーディングされた表現を生成してもよい。
【0255】
本明細書に記載された開示された、およびその他の解決策、実施例、実施形態、モジュール、および機能動作の実装形態は、本明細書に開示された構造およびその構造的等価物を含め、デジタル電子回路、またはコンピュータソフトウェア、ファームウェア、若しくはハードウェアで実施されてもよく、またはそれらの1または複数の組み合わせで実施してもよい。開示された、およびその他の実施形態は、1または複数のコンピュータプログラムプロダクト、たとえば、データ処理装置によって実装されるため、またはデータ処理装置の動作を制御するために、コンピュータ可読媒体上に符号化されたコンピュータプログラム命令の1または複数のモジュールとして実施することができる。このコンピュータ可読媒体は、機械可読記憶デバイス、機械可読記憶基板、メモリデバイス、機械可読伝播信号をもたらす物質の組成物、またはこれらの1または複数の組み合わせであってもよい。「データ処理装置」という用語は、例えば、プログラマブルプロセッサ、コンピュータ、または複数のプロセッサ、若しくはコンピュータを含む、データを処理するためのすべての装置、デバイス、および機械を含む。この装置は、ハードウェアの他に、当該コンピュータプログラムの実行環境を作るコード、例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、またはこれらの1または複数の組み合わせを構成するコードを含むことができる。伝播信号は、人工的に生成した信号、例えば、機械で生成した電気、光、または電磁信号であり、適切な受信装置に送信するための情報をエンコードするために生成される。
【0256】
コンピュータプログラム(プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとも呼ばれる)は、コンパイルされた言語または解釈された言語を含む任意の形式のプログラミング言語で記述することができ、また、それは、スタンドアロンプログラムとして、またはコンピューティング環境で使用するのに適したモジュール、コンポーネント、サブルーチン、または他のユニットとして含む任意の形式で展開することができる。コンピュータプログラムは、必ずしもファイルシステムにおけるファイルに対応するとは限らない。プログラムは、他のプログラムまたはデータを保持するファイルの一部(例えば、マークアップ言語文書に格納された1または複数のスクリプト)に記録されていてもよいし、当該プログラム専用の単一のファイルに記憶されていてもよいし、複数の調整ファイル(例えば、1または複数のモジュール、サブプログラム、またはコードの一部を格納するファイル)に記憶されていてもよい。コンピュータプログラムを、1つのコンピュータで実行するように展開することができ、あるいは、1つのサイトに位置する、または複数のサイトにわたって分散され通信ネットワークによって相互接続される複数のコンピュータで実行するように展開することができる。
【0257】
本明細書に記載された処理およびロジックフローは、入力データ上で動作し、出力を生成することによって機能を行うための1または複数のコンピュータプログラムを実行する1または複数のプログラマブルプロセッサによって行うことができる。処理およびロジックフローはまた、特定用途のロジック回路、例えば、FPGA(Field Programmable Gate Array)またはASIC(Application Specific Integrated Circuit)によって行うことができ、装置はまた、特別目的のロジック回路として実装することができる。
【0258】
コンピュータプログラムの実行に適したプロセッサは、例えば、汎用および専用マイクロプロセッサの両方、並びに任意の種類のデジタルコンピュータの任意の1または複数のプロセッサを含む。一般的に、プロセッサは、リードオンリーメモリまたはランダムアクセスメモリまたはその両方から命令およびデータを受信する。コンピュータの本質的な要素は、命令を実行するためのプロセッサと、命令およびデータを記憶するための1または複数のメモリデバイスとである。一般的に、コンピュータは、データを記憶するための1または複数の大容量記憶デバイス、例えば、磁気、光磁気ディスク、または光ディスクを含んでもよく、またはこれらの大容量記憶デバイスからデータを受信するか、またはこれらにデータを転送するように動作可能に結合されてもよい。しかしながら、コンピュータは、このようなデバイスを有する必要はない。コンピュータプログラム命令およびデータを記憶するのに適したコンピュータ可読媒体は、あらゆる形式の不揮発性メモリ、媒体、およびメモリデバイスを含み、例えば、EPROM、EEPROM、フラッシュ記憶装置、磁気ディスク、例えば内部ハードディスクまたはリムーバブルディスク、光磁気ディスク、およびCD ROMおよびDVD-ROMディスク等の半導体記憶装置を含む。プロセッサおよびメモリは、特定用途のロジック回路によって補完されてもよく、または特定用途のロジック回路に組み込まれてもよい。
【0259】
本特許明細書は多くの特徴を含むが、これらは、任意の主題の範囲または特許請求の範囲を限定するものと解釈されるべきではなく、むしろ、特定の技術の特定の実施形態に特有であり得る特徴の説明と解釈されるべきである。本特許文献において別個の実施形態のコンテキストで説明されている特定の特徴は、1つの例において組み合わせて実装してもよい。逆に、1つの例のコンテキストで説明された様々な特徴は、複数の実施形態において別個にまたは任意の適切なサブコンビネーションで実装してもよい。さらに、特徴は、特定の組み合わせで作用するものとして上記に記載され、最初にそのように主張されていてもよいが、主張された組み合わせからの1または複数の特徴は、場合によっては、組み合わせから抜粋されることができ、主張された組み合わせは、サブコンビネーションまたはサブコンビネーションのバリエーションに向けられてもよい。
【0260】
同様に、動作は図面において特定の順番で示されているが、これは、所望の結果を達成するために、このような動作が示された特定の順番でまたは連続した順番で行われること、または示された全ての動作が行われることを必要とするものと理解されるべきではない。また、本特許明細書に記載されている実施形態における様々なシステムの構成要素の分離は、全ての実施形態においてこのような分離を必要とするものと理解されるべきではない。
【0261】
いくつかの実装形態および実施例のみが記載されており、この特許文献に記載され図示されているコンテンツに基づいて、他の実施形態、拡張および変形が可能である。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13