JP2022532334A - 参照ピクチャ再サンプリングのための信号通知 - Google Patents

参照ピクチャ再サンプリングのための信号通知 Download PDF

Info

Publication number
JP2022532334A
JP2022532334A JP2021567036A JP2021567036A JP2022532334A JP 2022532334 A JP2022532334 A JP 2022532334A JP 2021567036 A JP2021567036 A JP 2021567036A JP 2021567036 A JP2021567036 A JP 2021567036A JP 2022532334 A JP2022532334 A JP 2022532334A
Authority
JP
Japan
Prior art keywords
video
picture
resolution
block
current
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2021567036A
Other languages
English (en)
Other versions
JP7273193B2 (ja
Inventor
カイ ジャン
リー ジャン
ホンビン リウ
ユエ ワン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing ByteDance Network Technology Co Ltd
ByteDance Inc
Original Assignee
Beijing ByteDance Network Technology Co Ltd
ByteDance Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing ByteDance Network Technology Co Ltd, ByteDance Inc filed Critical Beijing ByteDance Network Technology Co Ltd
Publication of JP2022532334A publication Critical patent/JP2022532334A/ja
Priority to JP2023072497A priority Critical patent/JP7513796B2/ja
Application granted granted Critical
Publication of JP7273193B2 publication Critical patent/JP7273193B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/132—Sampling, masking or truncation of coding units, e.g. adaptive resampling, frame skipping, frame interpolation or high-frequency transform coefficient masking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/105—Selection of the reference unit for prediction within a chosen coding or prediction mode, e.g. adaptive choice of position and number of pixels used for prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
    • H04N19/159—Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/172—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a picture, frame or field
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/177—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a group of pictures [GOP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/189—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding
    • H04N19/196—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding being specially adapted for the computation of encoding parameters, e.g. by averaging previously computed encoding parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H04N19/31—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability in the temporal domain
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H04N19/33—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability in the spatial domain
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/423—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements
    • H04N19/426—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements using memory downsizing methods
    • H04N19/428—Recompression, e.g. by spatial or temporal decimation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

参照ピクチャの再サンプリングを含む、デジタル映像符号化のための装置、システム、および方法が記載される。例示の映像処理方法は、１または複数の映像ユニットを含む１または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を行うことを有し、ビットストリーム表現は、フォーマット規則に準拠し、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理に関する情報を含み、フォーマット規則は、ＡＲＣ処理の映像セグメントへの適用を規定し、映像セグメントの１または複数の映像ユニットが、異なる解像度で符号化されることの指示が、ヘッダ構文構造、デコーダパラメータセット、映像パラメータセット、ピクチャパラメータセット、シーケンスパラメータセット、および適応パラメータセットとは異なる構文構造のビットストリーム表現に含まれる。【選択図】図２４Ｂ

Description

関連出願の相互参照
パリ条約に基づく適用可能な特許法および／または規則に基づいて、本願は、２０１９年５月１２日出願の国際特許出願第ＰＣＴ／ＣＮ２０１９／０８６５１３号の優先権および利益を適時に主張することを目的とする。法に基づくすべての目的のために、上記出願の開示全体は、本明細書の開示の一部として参照により援用される。
この特許明細書は、映像符号化技術、デバイスおよびシステムに関する。
映像圧縮の進歩にもかかわらず、デジタル映像は、依然として、インターネットおよび他のデジタル通信ネットワークにおいて最大の帯域幅の使用量を占めている。映像を受信および表示することが可能である接続されたユーザ機器の数が増加するにつれ、デジタル映像の使用に対する帯域幅の需要は増大し続けることが予測される。
デジタル映像符号化に関し、具体的には、映像符号化のための参照ピクチャ再サンプリングに関するデバイス、システム、および方法に関する。記載された方法は、既存の映像符号化規格（例えば、ＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ））および将来の映像符号化規格またはビデオコーデックの両方に適用されてよい。
１つの代表的な態様において、開示される技術は、映像処理の方法を提供するために使用してもよい。この方法は、１または複数の映像ユニットを有する１または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を行うことを含み、ビットストリーム表現は、フォーマット規則に準拠し、かつ、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理に関する情報を有し、フォーマット規則は、ＡＲＣ処理の映像セグメントへの適用を規定し、映像セグメントの１または複数の映像ユニットが、異なる解像度で符号化されることの指示が、ヘッダ構文構造、ＤＰＳ（Ｄｅｃｏｄｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＶＰＳ（Ｖｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、およびＡＰＳ（Ａｄａｐｔｉｖｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）とは異なる構文構造のビットストリーム表現に含まれる。
別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、１または複数の映像ユニットを有する１または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を行うことを含み、ビットストリーム表現は、フォーマット規則に準拠し、かつ、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理に関する情報を有し、Ｋ次の指数ゴロム符号で符号化されている１または複数の映像ユニットは、ビットストリーム表現で信号通知され、Ｋは正の整数であり、フォーマット規則は、ＡＲＣ処理の映像セグメントへの適用を規定し、映像セグメントの１または複数の映像ユニットの寸法が異なる解像度で符号化されていることの指示が、構文構造のビットストリーム表現に含まれる。
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、１または複数の映像ユニットを有する１または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を行うことを含み、ビットストリーム表現は、フォーマット規則に準拠し、かつ、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理に関する情報を有し、高さ（Ｈ）と幅（Ｗ）は、ビットストリーム表現にて信号通知され、ＨとＷは、正の整数であり、かつ、抑制され、フォーマット規則は、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理の映像セグメントへの適用を規定し、映像セグメントの１または複数の映像ユニットが異なる解像度で符号化されていることの指示が、構文構造のビットストリーム表現に含まれる。
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、（ａ）映像の現在の映像ブロックの時間的に近傍の第１のブロックの第１の参照ピクチャの解像度が、現在の映像ブロックを有する現在のピクチャの解像度と同一であること、および（ｂ）現在の映像ブロックの時間的に近傍の第２のブロックの第２の参照ピクチャの解像度が、現在のピクチャの解像度と異なること、を判定することと、判定に起因して、第１の時間的に近傍のブロックの予測における第２の時間的に近傍のブロックの動き情報の使用を無効化することによって、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を含む。
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、（ａ）映像の現在の映像ブロックの時間的に近傍の第１のブロックの第１の参照ピクチャの解像度が、現在の映像ブロックを有する現在のピクチャの解像度と異なること、および（ｂ）現在の映像ブロックの時間的に近傍の第２のブロックの第２の参照ピクチャの解像度が、現在のピクチャの解像度と同一であること、を判定することと、判定に起因して、第１の時間的に近傍のブロックの予測における第２の時間的に近傍のブロックの動き情報の使用を無効化することによって、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を含む。
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、映像の現在の映像ブロックのために、現在の映像ブロックに関連付けられた映像ブロックを有する参照ピクチャの解像度が、現在の映像ブロックを有する現在のピクチャの解像度とは異なることを判定することと、判定に起因して、参照ピクチャの映像ブロックに基づく予測処理を無効化することによって、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することとを含む。
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、ピクチャの少なくとも１つの寸法に基づいて、ピクチャが現在のピクチャの現在の映像ブロックのための並置された参照ピクチャとして使用することが許可されるかどうかに関する決定を行うことと、決定に基づいて、映像の現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することとを含む。
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、映像の現在の映像ブロックの予測のために、並置されたブロックを有する並置された参照ピクチャの寸法が、現在の映像ブロックを有する現在のピクチャの寸法と同一であることの判定に基づいて、並置されたブロックを識別することと、並置されたブロックを使用して、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することとを含む。
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、映像の現在の映像ブロックのために、現在の映像ブロックに関連付けられた参照ピクチャが、現在の映像ブロックを有する現在のピクチャの解像度とは異なる解像度を有することを判定することと、現在の映像ブロックと映像のビットストリーム表現との間の変換の一部として、参照ピクチャの１または複数の参照サンプル、および現在の映像ブロックに対する動き情報または現在の映像ブロックに対する符号化情報においてアップサンプリング動作またはダウンサンプリング動作を実行することと、を含む。
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、映像の現在の映像ブロックと映像のビットストリーム表現との間の変換のために、現在の映像ブロックを有する現在のピクチャの高さまたは幅が、現在の映像ブロックに関連付けられた並置された参照ピクチャの高さまたは幅とは異なることを判定することと、判定に基づいて、並置された参照ピクチャの１または複数の動きベクトルを格納するバッファにおいてアップサンプリング動作またはダウンサンプリング動作を実行することと、を含む。
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用されてよい。この方法は、映像の現在の映像ブロックを有する現在のピクチャの寸法と、現在の映像ブロックに関連付けられた並置されたピクチャの寸法に基づいて、現在の映像ブロックに適用されるＡＴＭＶＰ（Ａｌｔｅｒｎａｔｉｖｅ Ｔｅｍｐｏｒａｌ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ）処理に関する情報を導出することと、時間的動きベクトルを使用して、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を含む。
さらに別の代表的な態様では、開示される技術は、映像処理の方法を提供するために使用してもよい。この方法は、映像の現在の映像ブロックに対するＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理の適用のために、映像のビットストリーム表現を構成することであって、ＡＲＣ処理に関する情報は、ビットストリーム表現にて信号通知され、現在の映像ブロックを有する現在のピクチャは、第１の解像度を有し、ＡＲＣ処理は、第１の解像度とは異なる第２の解像度で現在の映像ブロックの一部分を再サンプリングすることを含む、ことと、構成することに基づいて、現在の映像ブロックと現在の映像ブロックのビットストリーム表現との間の変換を実行することと、を含む。
さらに別の代表的な態様において、上記方法は、プロセッサが実行可能なコードの形式で実施され、コンピュータ可読プログラム媒体に記憶される。
さらに別の代表的な態様において、上述した方法を行うように構成された、または動作可能なデバイスが開示される。デバイスは、この方法を実装するようにプログラムされたプロセッサを含んでもよい。
さらに別の代表的な態様において、映像デコーダ装置は、本明細書で説明されるような方法を実装してもよい。
開示される技術の上記および他の態様および特徴は、図面、説明および特許請求の範囲でより詳細に説明される。
異なる解像度で符号化された同じコンテンツの２つの表現の適応ストリームの例を示す。 異なる解像度で符号化された同じコンテンツの２つの表現の適応ストリームの別の例を示し、セグメントは、閉ＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅ）または開ＧＯＰの予測構造のいずれかを使用する。 ２つの表現の開ＧＯＰ予測構造の例を示す。 開ＧＯＰ位置での表現切り替えの例を示す。 別のビットストリームからの再サンプリングされた参照ピクチャを、ＲＡＳＬ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｓｋｉｐｐｅｄ Ｌｅａｄｉｎｇ）ピクチャを復号化するための参照として使用する例を示す。 ＭＣＴＳ（Ｍｏｔｉｏｎ Ｃｏｎｓｔｒａｉｎｔｅｄ Ｔｉｌｅ Ｓｅｔ）に基づくＲＷＭＲ（Ｒｅｇｉｏｎ Ｗｉｓｅ Ｍｉｘｅｄ－Ｒｅｓｏｌｕｔｉｏｎ）ビューポート依存３６０ストリーミングの例を示す。 異なるＩＲＡＰ（Ｉｎｔｒａ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ）の間隔および異なるサイズの並置されたサブピクチャ表現の例を示す。 視線の向きの変更がセグメントの始まりに際する解像度の変更を引き起こすときに受信したセグメントの例を示す。 視線の向きの変更の例を示す。 ２つのサブピクチャ位置のためのサブピクチャ表現の例を示す。 ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）のためのエンコーダの修正の例を示す。 ＡＲＣのためのデコーダの修正の例を示す。 ＡＲＣのためのタイルグループベースの再サンプリングの例を示す。 ＡＲＣ処理の例を示す。 符号化ユニットのためのＡＴＭＶＰ（Ａｌｔｅｒｎａｔｉｖｅ Ｔｅｍｐｏｒａｌ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ）の例を示す。 簡略化したアフィン動きモデルの例を示す。 簡略化したアフィン動きモデルの例を示す。 サブブロックごとのアフィンＭＶＦ（Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｆｉｅｌｄ）の例を示す。 それぞれ４パラメータアフィンモデルおよび６パラメータアフィンモデルの例を示す。 それぞれ４パラメータアフィンモデルおよび６パラメータアフィンモデルの例を示す。 継承されたアフィン候補に対するＡＦ＿ＩＮＴＥＲのＭＶＰ（Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ）の例を示す。 構築されたアフィン候補に対するＡＦ＿ＩＮＴＥＲのＭＶＰの例を示す。 ＡＦ＿ＭＥＲＧＥの候補の例を示す。 ＡＦ＿ＭＥＲＧＥの候補の例を示す。 アフィンマージモードの候補位置の例を示す。 ＡＲＣを使用してＴＭＶＰ／ＡＴＭＶＰを導出する例を示す。 映像処理のための例示的な方法のフローチャートを示す。 映像処理のための例示的な方法のフローチャートを示す。 映像処理のための例示的な方法のフローチャートを示す。 映像処理のための例示的な方法のフローチャートを示す。 映像処理のための例示的な方法のフローチャートを示す。 映像処理のための例示的な方法のフローチャートを示す。 映像処理のための例示的な方法のフローチャートを示す。 映像処理のための例示的な方法のフローチャートを示す。 映像処理のための例示的な方法のフローチャートを示す。 映像処理のための例示的な方法のフローチャートを示す。 本特許明細書に記載されるビジュアルメディアの復号化またはビジュアルメディアの符号化技術を実装するためのハードウェアプラットフォームの一例を示すブロック図である。 開示された技術を実装することができる例示的な映像処理システムを示すブロック図である。
開示される技術の実施形態は、圧縮性能を向上させるために、既存の映像符号化規格（例えば、ＨＥＶＣ、Ｈ．２６５）および将来の規格に適用されてもよい。本特許明細書では、説明の可読性を向上させるために章の見出しを使用しており、説明または実施形態（および／または実装形態）をそれぞれの章のみに限定するものではない。
１． 映像符号化の導入
より高い解像度の映像の需要が増大しているため、近年の技術において、映像符号化法および技術は、いたるところに存在している。映像コーデックは、一般的に、デジタル映像を圧縮または展開する電子回路またはソフトウェアを含み、より高い符号化効率を提供するために絶えず改良されている。映像コーデックは、非圧縮映像を圧縮フォーマットに変換する、またはその逆である。映像の品質、映像を表現するために使用されるデータの数（ビットレートで判定される）、符号化および復号化アルゴリズムの複雑性、データの損失およびエラーに対する敏感さ、編集のしやすさ、ランダムアクセス、およびエンドツーエンドの遅延（待ち時間）の間には複雑な関係がある。圧縮フォーマットは、通常、標準的な映像圧縮仕様、例えば、ＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）規格（Ｈ．２６５またはＭＰＥＧ－Ｈ Ｐａｒｔ２としても知られている）、確立されるべきＶｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ規格、または他の現在のおよび／または将来の映像符号化基準に準拠する。
映像符号化規格は、主に周知のＩＴＵ－ＴおよびＩＳＯ／ＩＥＣ規格の開発によって発展してきた。ＩＴＵ－ＴはＨ．２６１とＨ．２６３を作り、ＩＳＯ／ＩＥＣはＭＰＥＧ－１とＭＰＥＧ－４ Ｖｉｓｕａｌを作り、両団体はＨ．２６２／ＭＰＥＧ－２ ＶｉｄｅｏとＨ．２６４／ＭＰＥＧ－４ ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）とＨ．２６５／ＨＥＶＣ規格を共同で作った。Ｈ．２６２以来、映像符号化規格は、時間的予測と変換符号化が利用されるハイブリッド映像符号化構造に基づく。ＨＥＶＣを超えた将来の映像符号化技術を探索するため、２０１５年には、ＶＣＥＧとＭＰＥＧが共同でＪＶＥＴ（Ｊｏｉｎｔ Ｖｉｄｅｏ Ｅｘｐｌｏｒａｔｉｏｎ Ｔｅａｍ）を設立した。それ以来、多くの新しい方法がＪＶＥＴによって採用され、ＪＥＭ（Ｊｏｉｎｔ Ｅｘｐｌｏｒａｔｉｏｎ Ｍｏｄｅ）と呼ばれる参照ソフトウェアに組み込まれてきた。２０１８年４月には、ＶＣＥＧ（Ｑ６／１６）とＩＳＯ／ＩＥＣ ＪＴＣ１ ＳＣ２９／ＷＧ１１（ＭＰＥＧ）の間にＪＶＥＴ（Ｊｏｉｎｔ Ｖｉｄｅｏ Ｅｘｐｅｒｔ Ｔｅａｍ）が発足し、ＨＥＶＣと比較して５０％のビットレート削減を目標にＶＶＣ規格の策定に取り組んでいる。
ＡＶＣおよびＨＥＶＣは、ＩＤＲまたはＩＲＡＰ（Ｉｎｔｒａ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ）ピクチャを導入することなく解像度を変更する能力を有しておらず、そのような能力は、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｈａｎｇｅ）とも呼ばれる。以下を含む、ＡＲＣ機能からの恩恵を受けることになる使用事例またはアプリケーションシナリオがある。
－テレビ電話および会議におけるレート適応：符号化映像を変化するネットワーク条件に適応させるために、ネットワーク条件が悪化し、利用可能な帯域幅が低下すると、エンコーダは、より解像度の低いピクチャを符号化することでこれに適応してよい。現在、ピクチャの解像度を変更することは、ＩＲＡＰピクチャの後にしか行うことができないため、いくつかの問題がある。妥当な品質のＩＲＡＰピクチャは、インター符号化されたピクチャよりもずっと大きく、それに対応して復号化するのがより複雑となり、これにより時間とリソースがかかる。これは、ローディングの理由でデコーダが解像度の変更を要求した場合に問題となる。また、低遅延バッファ状態を壊し、オーディオを強制的に再同期させ、ストリームのエンドツーエンドの遅延が少なくとも一時的に増加する可能性がある。これにより、ユーザエクスペリアンスが低下する。
－マルチパーティビデオ会議におけるアクティブスピーカの変更：マルチパーティによるビデオ会議の場合、アクティブスピーカは、残りの会議参加者の映像よりも大きい映像サイズで示されることが一般的である。アクティブスピーカが変わった場合、各参加者のピクチャ解像度を調整することも必要となり得る。ＡＲＣ機能を有する必要性は、このようなアクティブスピーカの変更が頻繁に発生する場合に、より重要になる。
－ストリーミングの高速スタート：ストリーミングアプリケーションの場合、アプリケーションは、表示を開始する前に、復号化されたピクチャの一定の長さをバッファリングすることが一般的である。より小さい解像度でビットストリームを開始することにより、アプリケーションがバッファ内に十分なピクチャを有し、より高速に表示を開始することができるようになる。
ストリーミングにおける適応ストリームの切替：ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）仕様は、＠ｍｅｄｉａＳｔｒｅａｍＳｔｒｕｃｔｕｒｅＩｄと呼ばれる特徴を含む。これにより、開ＧＯＰランダムアクセスポイントにおける異なる表現と、復号化不可の先頭ピクチャ、例えば、ＨＥＶＣにおいて関連付けられたＲＡＳＬピクチャを有するＣＲＡピクチャとの間で切り替えることができる。同じ映像の２つの異なる表現は、異なるビットレートを有するが、同じ空間的解像度を有し、＠ｍｅｄｉａＳｔｒｅａｍＳｔｒｕｃｔｕｒｅＩｄの同じ値を有する場合、関連付けられたＲＡＳＬピクチャを有するＣＲＡピクチャで２つの表現の切り替えを行うことができ、ＣＲＡピクチャでの切り替えに関連付けられたＲＡＳＬピクチャは、許容可能な品質で復号化することができるため、シームレスな切り替えを可能にする。ＡＲＣを使用すると、＠ｍｅｄｉａＳｔｒｅａｍＳｔｒｕｃｔｕｒｅＩｄ機能は、異なる空間的解像度を有するＤＡＳＨ表現間の切り替えにも利用可能である。
ＡＲＣは、動的解像度変換としても知られている。
ＡＲＣは、Ｈ．２６３ Ａｎｎｅｘ ＰなどのＲＰＲ（Ｒｅｆｅｒｅｎｃｅ Ｐｉｃｔｕｒｅ Ｒｅｓａｍｐｌｉｎｇ）の特殊な場合と見なされてもよい。
１．１． Ｈ．２６３ Ａｎｎｅｘ Ｐにおける参照ピクチャの再サンプリング
このモードは、参照ピクチャを予測に使用する前に、この参照ピクチャをワープするためのアルゴリズムを説明する。それは、予測されるピクチャとは異なるソースフォーマットを有する参照ピクチャを再サンプリングするために有用となり得る。また、参照ピクチャの形状、サイズ、および位置をワープすることにより、グローバルな動き推定、または回転動きの推定に使用されてもよい。構文は、使用されるべきワーピングパラメータおよび再サンプリングアルゴリズムを含む。アップサンプリングおよびダウンサンプリングの処理に対してＦＩＲフィルタのみを適用する必要があるため、参照ピクチャの再サンプリングモードに対する最もシンプルな動作レベルは、暗黙係数が４の再サンプリングである。この場合、（ピクチャヘッダに示された）新しいピクチャのサイズが前のピクチャのサイズと異なる場合にその使用が理解されるため、追加の信号通知のオーバーヘッドは必要ない。
１．２． ＡＲＣのＶＶＣへの貢献
１．２．１． ＪＶＥＴ－Ｍ０１３５
ＪＣＴＶＣ－Ｆ１５８の一部を除き、以下に述べるＡＲＣの予備設計は、今回の議論のきっかけとなるプレースホルダーとなるべきである。
１．２．１．１ 基本ツールの説明
ＡＲＣをサポートするための基本ツールの制約は、以下の通りである。
空間的解像度は、両方の寸法に適用された場合、公称解像度とは係数０．５だけ異なってよい。空間的解像度は増加または減少し、０．５および２．０のスケーリング比をもたらし得る。
映像フォーマットのアスペクト比および彩度フォーマットは変更されない。
クロッピング領域は、空間的解像度に比例してスケーリングされる。
参照ピクチャは、必要に応じて簡単に再スケーリングされ、インター予測が従来通りに適用される。
１．２．１．２ スケーリング動作
簡単な、ゼロ位相分離可能なダウンスケーリングフィルタおよびアップスケーリングフィルタを使用することを提案する。なお、これらのフィルタは予測のみのためのものであり、デコーダは、出力のために、より洗練されたスケーリングを使用してよい。
ゼロ位相および５つのタップを有する以下の１：２のダウンスケーリングフィルタが使用される。
（－１，９，１６，９，－１）／３２
ダウンサンプリング点は、偶数個のサンプル位置にあり、かつ、同じ位置にある。輝度および彩度についても同じフィルタが使用される。
２：１のアップサンプリングの場合、最新のＶＶＣ ＷＤにおける１／２画素動き補償補間フィルタ係数を使用して、奇数グリッド位置の追加サンプルが生成される。
組み合わされたアップサンプリングおよびダウンサンプリングは、位相、または彩度サンプリング点の位置を変化させない。
１．２．１．３ パラメータセットにおける解像度記述
ＳＰＳにおけるピクチャ解像度の信号通知は、以下のように変更され、本明細書の以下の説明および残りの部分の両方において、二重括弧で囲まれた部分が削除されている（例えば、［［ａ］］は、文字“ａ”の削除を意味する）。
シーケンスパラメータセットＲＢＳＰ構文および意味論
Figure 2022532334000002
［［ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、輝度サンプル単位で各復号化されたピクチャの幅を規定する。ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、０に等しくなく、かつ、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。
ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、輝度サンプル単位で各復号化されたピクチャの高さを規定する。ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、０に等しくなく、かつ、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。］］
ｎｕｍ＿ｐｉｃ＿ｓｉｚｅ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＿ｍｉｎｕｓ１＋１は、符号化映像シーケンスに存在し得る輝度サンプル単位でピクチャサイズ（幅および高さ）の数を規定する。
ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］は、符号化映像シーケンスに存在し得る輝度サンプル単位で復号化されたピクチャのｉ番目の幅を規定する。ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］は、０に等しくなく、かつ、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。
ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］は、符号化映像シーケンスに存在し得る輝度サンプル単位で復号化されたピクチャのｉ番目の高さを規定する。ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］は、０には等しくなく、かつ、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。
ピクチャパラメータセットＲＢＳＰ構文および意味論
Figure 2022532334000003
ｐｉｃ＿ｓｉｚｅ＿ｉｄｘは、シーケンスパラメータセットにおけるｉ番目のピクチャサイズのインデックスを規定する。ピクチャパラメータセットを参照するピクチャの幅は、輝度サンプルにおけるｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｐｉｃ＿ｓｉｚｅ＿ｉｄｘ］である。同様に、ピクチャパラメータセットを参照するピクチャの高さは、輝度サンプルにおけるｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｐｉｃ＿ｓｉｚｅ＿ｉｄｘ］である。
１．２．２． ＪＶＥＴ－Ｍ０２５９
１．２．２．１． 背景：サブピクチャ
サブピクチャトラックという用語は、ＯＭＡＦ（Ｏｍｎｉｄｉｒｅｃｔｉｏｎａｌ Ｍｅｄｉａ Ｆｏｒｍａｔ）において、以下のように定義される。トラックは、他のトラック（複数可）の空間的関係を有し、かつ、コンテンツ制作側で映像符号化する前に空間的サブセットに分割された元の映像コンテンツの空間的サブセットを表す。ＨＥＶＣのためのサブピクチャトラックは、動き制約タイルセットのためのパラメータセットおよびスライスセグメントヘッダを、それが自立型ＨＥＶＣビットストリームになるように書き換えることによって構築することができる。サブピクチャ表現は、サブピクチャトラックを搬送するＤＡＳＨ表現として定義され得る。
ＪＶＥＴ－Ｍ０２６１は、ＶＶＣの空間的分割ユニットとしてサブピクチャという用語を使用し、以下のようにまとめた。
１．ピクチャは、サブピクチャ、タイルグループ、およびタイルに分けられる。
２．サブピクチャは、ｔｉｌｅ＿ｇｒｏｕｐ＿ａｄｄｒｅｓｓが０に等しいタイルグループから始まる矩形のタイルグループのセットである。
３．各サブピクチャは、それ自体のＰＰＳを参照してよく、従って、それ自体のタイル分割を有していてよい。
４．サブピクチャは、復号化処理においてピクチャと同様に扱われる。
５．サブピクチャを復号化するための参照ピクチャは、復号化ピクチャバッファにおける参照ピクチャから、現在のサブピクチャと並置される領域を抽出することで生成される。抽出された領域は、復号化されたサブピクチャであり、すなわち、インター予測は、ピクチャ内の同じサイズで同じ位置のサブピクチャ間で行われる。
６．タイルグループは、サブピクチャのタイルラスタスキャンにおけるタイルのシーケンスである。
この寄与において、我々は、ＪＶＥＴ－Ｍ０２６１に定義されるような用語サブピクチャを参照する。しかしながら、ＪＶＥＴ－Ｍ０２６１に定義されるようなサブピクチャシーケンスをカプセル化するトラックは、ＯＭＡＦに定義されるサブピクチャトラックと非常に類似した特性を有し、以下に示される例は、いずれの場合も当てはまる。
１．２．２．２． ユースケース
１．２．２．２．１． ストリーミングにおける適応的解像度の変更
適応ストリーミングのサポートの要件
ＭＰＥＧ Ｎ１７０７４の５．１３章（「適応ストリーミングのサポート」）は、ＶＶＣに対して以下の要件を含む。
本規格は、それぞれが異なる特性（例えば、空間的解像度またはサンプルビット深度）を有する、同じコンテンツの複数の表現を提供する適応ストリーミングサービスの場合、高速表現切り替えをサポートするものとする。本規格は、異なる空間的解像度などの異なる特性の表現間の高速かつシームレスな表現切り替え能力を損なうことなく、効率的な予測構成（例えば、いわゆるピクチャの開グループ）を使用することを可能にする。
表現切り替えを伴う開ＧＯＰ予測構造の例
適応ビットレートストリーミングのためのコンテンツ生成は、異なる空間的解像度を有し得る異なる表現の生成を含む。クライアントは、表現にセグメントを要求し、従って、どの解像度およびビットレートでコンテンツが受信されるかを決定することができる。クライアント側では、異なる表現のセグメントを連結し、復号化し、再生する。クライアントは、デコーダインスタンスでシームレスな再生を実現できなければならない。従来、図１に示すように、閉ＧＯＰ構造（ＩＤＲピクチャで始まる）が使用されている。
開ＧＯＰ予測構造（ＣＲＡピクチャで始まる）は、それぞれの閉ＧＯＰ予測構造よりも優れた圧縮性能を可能にする。例えば、ＩＲＡＰピクチャ間隔が２４ピクチャである場合、輝度ジョンテガール差分ビットレートの平均ビットレート低減は、５．６％となった。
開ＧＯＰ予測構造は、報告によれば、主観的に視認可能な品質のポンピングをも低減する。
ストリーミングにおける開ＧＯＰの使用における課題は、表現を切り替えた後、ＲＡＳＬピクチャを正しい参照ピクチャで復号化することができないことである。以下、図２に提示された表現に関連して、この課題を説明する。
ＣＲＡピクチャから始まるセグメントは、少なくとも１つの参照ピクチャが前のセグメントにあるＲＡＳＬピクチャを含む。これは、図３に示されており、両方のビットストリームにおけるピクチャ０は、前のセグメントに存在し、ＲＡＳＬピクチャを予測するための基準として使用される。
図４には、図２に破線の長方形が付けられた表現切り替えが示されている。ＲＡＳＬピクチャの参照ピクチャ（「ピクチャ０」）は復号化されていないことが分かる。その結果、ＲＡＳＬピクチャは復号化できず、映像の再生にギャップが生じる。
しかしながら、本発明の実施形態に基づいて説明したように、再サンプリングした参照ピクチャにてＲＡＳＬピクチャを復号化することは、主観的に許容可能であることが分かった。図５に、「ピクチャ０」を再サンプリングし、ＲＡＳＬピクチャを復号化するための参照ピクチャとして用いることを示す。
１．２．２．２．２． ＲＷＭＲ（Ｒｅｇｉｏｎ－Ｗｉｓｅ Ｍｉｘｅｄ－Ｒｅｓｏｌｕｔｉｏｎ）３６０°映像ストリーミングにおけるビューポートの変更
背景：ＨＥＶＣベースのＲＷＭＲストリーミング
ＲＷＭＲ３６０°ストリーミングは、ビューポートの有効空間的解像度を向上させる。ビューポートをカバーするタイルが、６Ｋ（６１４４×３０７２）のＥＲＰピクチャまたは図６に示すように「４Ｋ」の復号化能力（ＨＥＶＣレベル５．１）を有するのと等価なＣＭＰ解像度に由来するスキームは、ＯＭＡＦのＤ．６．３項およびＤ．６．４項に含まれ、かつ、ＶＲ産業協議会の指針にも採用された。このような解像度は、クアッドＨＤ（２５６０×１４４０）ディスプレイパネルを使用したヘッドマウントディスプレイに適していると主張されている。
符号化：コンテンツは、それぞれキューブ面サイズ１５３６×１５３６および７６８×７６８の２つの空間的解像度で符号化される。両方のビットストリームにおいて、６×４のタイルグリッドが使用され、各タイル位置に対してＭＣＴＳ（Ｍｏｔｉｏｎ Ｃｏｎｓｔｒａｉｎｅｄ Ｔｉｌｅ Ｓｅｔ）が符号化される。
カプセル化：各ＭＣＴＳシーケンスは、サブピクチャトラックとしてカプセル化され、ＤＡＳＨにおけるサブピクチャ表現として利用可能にされる。
ストリーミングされたＭＣＴＳの選択：高解像度ビットストリームから１２個のＭＣＴＳが選択され、低解像度ビットストリームから相補的な１２個のＭＣＴＳが抽出される。よって、ストリーミングされたコンテンツの半球（１８０°×１８０°）は、高解像度ビットストリームに由来する。
ＭＣＴＳの復号化されるビットストリームへのマージ：１つの時間インスタンスの受信されたＭＣＴＳは、ＨＥＶＣレベル５．１に準拠する１９２０×４６０８の符号化ピクチャにマージされる。マージされたピクチャの別の選択肢は、幅７６８の４つのタイル列、幅３８４の２つのタイル列、および高さ７６８の３つのタイル行の輝度サンプルを有し、３８４０×２３０４の輝度サンプルのピクチャを得ることである。
背景：ビューポートに依存する３６０°ストリーミングのための異なるＩＲＡＰ間隔のいくつかの表現
ＨＥＶＣベースのビューポートに依存する３６０°のストリーミングにおいて、視線の向きが変化する場合、次のＩＲＡＰに整列されたセグメント境界において、サブピクチャ表現の新たな選択を有効にすることができる。サブピクチャ表現は、復号化のために符号化ピクチャにマージされるので、ＶＣＬ ＮＡＬユニットタイプは、すべての選択されたサブピクチャ表現において整列される。
視線の向きが安定している場合、視線方向の変化に反応する応答時間とレートひずみ性能との間をトレードオフするために、異なるＩＲＡＰ間隔で複数のバージョンのコンテンツを符号化することができる。これは、図６に提示された符号化のための、並置された１セットのサブピクチャ表現として図７に示す。
図８は、まずサブピクチャの位置が、より低い解像度（３８４×３８４）で受信するように選択される例を提示する。視線の向きを変えることにより、より高い解像度（７６８×７６８）でサブピクチャ位置を新たに選択することができる。この例において、視線の向きの変更は、セグメント４が短ＩＲＡＰ区間のサブピクチャ表現から受信されるように行われる。その後、視線の向きが安定しているので、セグメント５から始まる長ＩＲＡＰ間隔バージョンが使用できる。
問題点について
典型的な視認状況では、視線の向きが徐々に変化するため、ＲＷＭＲビューポートに依存したストリーミングにおけるサブピクチャ位置のサブセットのみにおいて、解像度が変化する。図９は、図６からわずかに上向きに右側の立方体面に向かって見る向きの変化を示す。前回とは異なる解像度を有するキューブ面分割を「Ｃ」で示す。２４個のキューブ面分割のうち６個のキューブ面分割において、解像度が変化したことがわかる。しかしながら、上述したように、ＩＲＡＰピクチャから始まるセグメントは、視線の向きの変化に呼応して、２４個のキューブ面分割全てについて受信する必要がある。ＩＲＡＰピクチャから始まるセグメントですべてのサブピクチャの位置を更新することは、ストリーミングレートひずみ性能の点で非効率である。
さらに、レートひずみ性能を改善し、閉ＧＯＰ予測構造によって引き起こされる可視ピク品質のチャポンピングを回避するために、ＲＷＭＲ３６０°ストリーミングのサブピクチャ表現と共に開ＧＯＰ予測構造を使用できることが望ましい。
提案される設計目標
以下の設計目標を提案する。
１．ＶＶＣ設計は、ランダムアクセスピクチャに由来するサブピクチャと非ランダムアクセスピクチャに由来する別のサブピクチャとを、ＶＶＣに準拠する同じ符号化ピクチャにマージすることを可能にするべきである。
２．ＶＶＣ設計は、サブピクチャ表現を単一のＶＶＣビットストリームにマージすることを可能にしつつ、異なる空間的解像度などの異なる特性のサブピクチャ表現間の高速かつシームレスな表現切り替え能力を損なうことなく、サブピクチャ表現における開ＧＯＰ予測構造の使用を可能にするべきである。
設計目標は、２つのサブピクチャ位置のサブピクチャ表現を提示する図１０で説明することができる。両方のサブピクチャ位置に対して、２つの解像度と２つのランダムアクセス間隔との間の各組み合わせに対して、コンテンツの別個のバージョンが符号化される。セグメントのいくつかは、開ＧＯＰ予測構造から始まる。視線の向きの変更により、セグメント４の開始時にサブピクチャ位置１の解像度が切り替えられる。セグメント４は、ＲＡＳＬピクチャに関連付けられたＣＲＡピクチャから始まるので、セグメント３にあるＲＡＳＬピクチャのこれらの参照ピクチャを再サンプリングすることが必要である。なお、この再サンプリングはサブピクチャ位置１に適用され、他のサブピクチャ位置の復号化サブピクチャは再サンプリングされない。この例において、視線の向きの変化は、サブピクチャ位置２の解像度を変化させず、従って、サブピクチャ位置２の復号化されたサブピクチャは再サンプリングされない。セグメント４の第１のピクチャにおいて、サブピクチャ位置１のセグメントは、ＣＲＡピクチャに由来するサブピクチャを含み、サブピクチャ位置２のセグメントは、非ランダムアクセスピクチャに由来するサブピクチャを含む。ＶＶＣにおいて、これらのサブピクチャを１つの符号化ピクチャにマージすることができるようにすることが提案される。
１．２．２．２．３． テレビ会議における適応解像度変更
ＪＣＴＶＣ－Ｆ１５８は、主にテレビ会議用の適応解像度変更を提案している。ＪＣＴＶＣ－Ｆ１５８から以下のサブセクションがコピーされ、適応解像度の変更が有用であると主張される使用事例を紹介する。
シームレスなネットワーク適応およびエラー耐性
ビデオ会議およびパケットネットワークを介したストリーミングなどの適用において、符号化されたストリームは、特にビットレートが高くなり過ぎてデータが失われている場合に、ネットワーク条件の変化に適用することが頻繁に求められている。そのような適用は、一般的に、エンコーダがエラーを検出し、調整を実行できるようにする戻りチャネルを有する。エンコーダには、ビットレートの低減と、時間的または空間的な解像度の変更という２つの主なツールがある。時間的解像度の変更は、階層予測構造を使用した符号化によって有効に実現することができる。しかしながら、最高品質のために、空間的解像度は、映像通信のためのうまく設計されたエンコーダの一部と同様に、変更が必要である。
ＡＶＣ内の空間的解像度を変更するには、ＩＤＲフレームを送信し、ストリームをリセットする必要がある。これは重大な問題を引き起こす。妥当な品質のＩＤＲフレームは、インターピクチャよりもずっと大きく、それに対応して復号化するのがより複雑となり、これにより時間とリソースがかかる。これは、ローディングの理由でデコーダが解像度の変更を要求した場合に問題となる。また、低遅延バッファ状態を壊し、オーディオを強制的に再同期させ、ストリームのエンドツーエンドの遅延が少なくとも一時的に増加する可能性がある。これにより、ユーザエクスペリアンスが低下する。
これらの問題を最小限に抑えるために、ＩＤＲは、一般的に、Ｐフレームに類似したビット数を使用して低品質で送信され、所与の解像度の場合、十分な品質に戻るまでにかなりの時間がかかる。十分に低い遅延を得るために、品質は非常に低く、実際には、画像が「リフォーカス」される前に、目に見えるぼやけがあることが多い。実際において、イントラフレームは、圧縮の観点から見て、有用な作業が非常に少なく、ストリームを再スタートさせる方法に過ぎない。
そのため、ＨＥＶＣにおいて、主観的な体験への影響を最小限に抑えつつ、特に困難なネットワーク条件において、解像度を変更することができる方法が求められている。
高速スタート
最初のフレームが低解像度で送信され、次の数フレームにわたって解像度が向上する「高速スタート」モードを有することは、遅延を低減し、開始において受け入れられないほどの画像のぼやけを生じることなく、より迅速に通常の品質にするために有用である。
会議「構成」
また、テレビ会議は、話している人がフルスクリーンで表示され、他の参加者がより小さい解像度の窓に表示される特徴を有することが多い。これを効率的にサポートするために、小さなピクチャは低い解像度で送信されることが多い。そして、この解像度は、参加者がスピーカになり、フルスクリーンされた場合に高くなる。この時点でイントラフレームを送信すると、映像ストリームにおいて不快なヒックアップを引き起こす。この影響は、スピーカが急速に交互に変わる場合、非常に目立ち、不快になる可能性がある。
１．２．２．３． 提案される設計目標
以下は、ＶＶＣバージョン１のために提案されるハイレベル設計選択肢である。
１．以下の使用事例のために、ＶＶＣバージョン１に参照ピクチャ再サンプリング処理を含めることを提案する。
－異なる空間的解像度などの異なる特性の表現間の高速かつシームレスな表現切り替え能力を損なうことなく、適応ストリームにおける効率的な予測構造（例えば、いわゆるピクチャの開グループ）を使用すること。
－大幅な遅延または遅延の変動を伴わずに、低遅延の会話型映像コンテンツをネットワーク条件およびアプリケーション起源の解像度の変化に適応させること。
２．ＶＶＣ設計は、ランダムアクセスピクチャに由来するサブピクチャと非ランダムアクセスピクチャに由来する別のサブピクチャとを、ＶＶＣに準拠する同じ符号化ピクチャにマージすることを可能にするために提案される。これは、混合品質および混合解像度のビューポート適応型３６０°ストリーミングにおける視線の向きの変化を効率的に処理することを可能にするために主張される。
３．ＶＶＣバージョン１において、サブピクチャワイズの再サンプリング処理を含めることを提案する。これは、混合解像度ビューポート適応型３６０°ストリーミングにおける視線の向きの変化をより効率的に処理するための効率的な予測構造を可能にするために主張される。
１．２．３． ＪＶＥＴ－Ｎ００４８
ＡＲＣ（Ａｄａｐｔｉｖｅ ｒｅｓｏｌｕｔｉｏｎ Ｃｈａｎｇｉｎｇ）のための使用事例および設計目標は、ＪＶＥＴ－Ｍ０２５９に詳細に記載されている。以下にその概要を示す：
１．リアルタイム通信
本来、ＪＣＴＶＣ－Ｆ１５８には、適応解像度の変更のための以下の使用事例が含まれていた。
ａ．シームレスなネットワーク適応およびエラー耐性（動的適応解像度の変更による）
ｂ．高速起動（セッション開始時またはリセット時に徐々に解像度を上げる）
ｃ．会議の「構成」（話している人の方に高い解像度を与える）
２．適応ストリーミング
ＭＰＥＧ Ｎ１７０７４の５．１３章（「適応ストリーミングのサポート」）は、ＶＶＣに対して以下の要件を含む。
本規格は、それぞれが異なる特性（例えば、空間的解像度またはサンプルビット深度）を有する、同じコンテンツの複数の表現を提供する適応ストリーミングサービスの場合、高速表現切り替えをサポートする。本規格は、異なる空間的解像度などの異なる特性の表現間の高速かつシームレスな表現切り替え能力を損なうことなく、効率的な予測構造（例えば、いわゆるピクチャの開グループ）を使用することを可能にする。
ＪＶＥＴ－Ｍ０２５９は、先頭ピクチャの参照ピクチャを再サンプリングすることで、この要件をどのように満たすかを検討している。
３． ３６０度ビューポート依存ストリーミング
ＪＶＥＴ－Ｍ０２５９は、先頭ピクチャの参照ピクチャの特定の独立して符号化されたピクチャ領域を再サンプリングすることで、この使用事例にどのように対処するかを検討している。
この寄与は、上述したすべての使用事例および設計目標を満たすことを主張する適応解像度符号化アプローチを提案する。３６０度ビューポートに依存するストリーミングおよび会議「構成」の使用事例は、ＪＶＥＴ－Ｎ００４５（独立したサブピクチャ層を提案する）と共に本提案で取り扱う。
提案仕様テキスト
信号通知
ｓｐｓ＿ｍａｘ＿ｒｐｒ
Figure 2022532334000004
ｓｐｓ＿ｍａｘ＿ｒｐｒは、ＣＶＳの任意のタイルグループの参照ピクチャリスト０または１の中で、現在のピクチャのｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓおよびｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓとそれぞれ等しくないｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓおよびｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓを有するアクティブな参照ピクチャの最大数を規定する。
ピクチャの幅と高さ
Figure 2022532334000005
Figure 2022532334000006
ｍａｘ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、このＳＰＳがアクティブになっているＣＶＳの任意のピクチャに対する任意のアクティブなＰＰＳのｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓがｍａｘ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ以下であることが、ビットストリーム適合性の要件であることを規定する。
ｍａｘ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、このＳＰＳがアクティブになっているＣＶＳの任意のピクチャに対する任意のアクティブなＰＰＳのｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓがｍａｘ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ以下であることが、ビットストリーム適合性の要件であることを規定する。
高レベル復号化処理
復号化処理は、現在のピクチャＣｕｒｒＰｉｃに対して以下のように動作する。
１．ＮＡＬユニットの復号化は８．２項で規定される。
２．８．３項の処理は、タイルグループヘッダ層およびそれより上位の構文要素を使用して、以下の復号化処理を規定する。
－ピクチャオーダカウントに関連する変数および関数は、８．３．１項で規定されるように導出される。これは、ピクチャの第１のタイルグループに対してのみ呼び出す必要がある。
－非ＩＤＲピクチャの各タイルグループに対する復号化処理の最初に、参照ピクチャリスト０（ＲｅｆＰｉｃＬｉｓｔ［０］）と参照ピクチャリスト１（ＲｅｆＰｉｃＬｉｓｔ［１］）の導出のために、８．３．２項に規定された参照ピクチャリスト構築のための復号化処理が呼び出される。
－８．３．３項の参照ピクチャマーキングのための復号化処理が呼び出され、参照ピクチャは、「参照のために使用されない」または「長期参照のために使用される」としてマークされてもよい。これは、ピクチャの第１のタイルグループに対してのみ呼び出す必要がある。
－ＲｅｆＰｉｃＬｉｓｔ［０］およびＲｅｆＰｉｃＬｉｓｔ［１］の各アクティブ参照ピクチャのうち、ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓまたはｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓがＣｕｒｒＰｉｃのｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓまたはｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓとそれぞれ等しくないものについては、以下のようになる。
－Ｘ．Ｙ．Ｚ項における再サンプリング処理は、入力と同じ参照ピクチャマーキングおよびピクチャオーダカウントを有する出力として呼び出される［Ｅｄ．（ＭＨ）：追加される呼び出しパラメータの詳細］。
－再サンプリング処理の入力として使用された参照ピクチャは、「参照に使用されない」とマークされる。
３．［Ｅｄ．（ＹＫ）：ここで、符号化ツリーユニット、スケーリング、変換、インループフィルタリング等の復号化処理の呼び出しを加える。］
４．現在のピクチャのすべてのタイルグループが復号化された後、現在の復号化されたピクチャは「短期参照に使用される」とマークされる。
再サンプリング処理
ＳＨＶＣ再サンプリング処理（ＨＥＶＣ Ｈ．８．１．４．２項）に以下を追加することを提案する。
・・・
ｓｐｓ＿ｒｅｆ＿ｗｒａｐａｒｏｕｎｄ＿ｅｎａｂｌｅｄ＿ｆｌａｇが０に等しい場合、ｎ＝０．．７のサンプル値ｔｅｍｐＡｒｒａｙ［ｎ］は、以下のように導出される。
ｔｅｍｐＡｒｒａｙ［ｎ］＝
（ｆＬ［ｘＰｈａｓｅ，０］＊ｒｌＰｉｃＳａｍｐｌｅＬ［Ｃｌｉｐ３（０，ｒｅｆＷ－１，ｘＲｅｆ－３），ｙＰｏｓＲＬ］＋
ｆＬ［ｘＰｈａｓｅ，１］＊ｒｌＰｉｃＳａｍｐｌｅＬ［Ｃｌｉｐ３（０，ｒｅｆＷ－１，ｘＲｅｆ－２），ｙＰｏｓＲＬ］＋
ｆＬ［ｘＰｈａｓｅ，２］＊ｒｌＰｉｃＳａｍｐｌｅＬ［Ｃｌｉｐ３（０，ｒｅｆＷ－１，ｘＲｅｆ－１），ｙＰｏｓＲＬ］＋
ｆＬ［ｘＰｈａｓｅ，３］＊ｒｌＰｉｃＳａｍｐｌｅＬ［Ｃｌｉｐ３（０，ｒｅｆＷ－１，ｘＲｅｆ），ｙＰｏｓＲＬ］＋
ｆＬ［ｘＰｈａｓｅ，４］＊ｒｌＰｉｃＳａｍｐｌｅＬ［Ｃｌｉｐ３（０，ｒｅｆＷ－１，ｘＲｅｆ＋１），ｙＰｏｓＲＬ］＋
ｆＬ［ｘＰｈａｓｅ，５］＊ｒｌＰｉｃＳａｍｐｌｅＬ［Ｃｌｉｐ３（０，ｒｅｆＷ－１，ｘＲｅｆ＋２），ｙＰｏｓＲＬ］＋
ｆＬ［ｘＰｈａｓｅ，６］＊ｒｌＰｉｃＳａｍｐｌｅＬ［Ｃｌｉｐ３（０，ｒｅｆＷ－１，ｘＲｅｆ＋３），ｙＰｏｓＲＬ］＋
ｆＬ［ｘＰｈａｓｅ，７］＊ｒｌＰｉｃＳａｍｐｌｅＬ［Ｃｌｉｐ３（０，ｒｅｆＷ－１，ｘＲｅｆ＋４），ｙＰｏｓＲＬ］）＞＞ｓｈｉｆｔ１ （Ｈ－３８）
そうでない場合、ｎ＝０．．７のサンプル値ｔｅｍｐＡｒｒａｙ［ｎ］は、以下のように導出される。
ｒｅｆＯｆｆｓｅｔ＝（ｓｐｓ＿ｒｅｆ＿ｗｒａｐａｒｏｕｎｄ＿ｏｆｆｓｅｔ＿ｍｉｎｕｓ１＋１）＊ＭｉｎＣｂＳｉｚｅＹ
ｔｅｍｐＡｒｒａｙ［ｎ］＝
（ｆＬ［ｘＰｈａｓｅ，０］＊ｒｌＰｉｃＳａｍｐｌｅＬ［ＣｌｉｐＨ（ｒｅｆＯｆｆｓｅｔ，ｒｅｆＷ，ｘＲｅｆ－３），ｙＰｏｓＲＬ］＋
ｆＬ［ｘＰｈａｓｅ，１］＊ｒｌＰｉｃＳａｍｐｌｅＬ［ＣｌｉｐＨ（ｒｅｆＯｆｆｓｅｔ，ｒｅｆＷ，ｘＲｅｆ－２），ｙＰｏｓＲＬ］＋
ｆＬ［ｘＰｈａｓｅ，２］＊ｒｌＰｉｃＳａｍｐｌｅＬ［ＣｌｉｐＨ（ｒｅｆＯｆｆｓｅｔ，ｒｅｆＷ，ｘＲｅｆ－１），ｙＰｏｓＲＬ］＋
ｆＬ［ｘＰｈａｓｅ，３］＊ｒｌＰｉｃＳａｍｐｌｅＬ［ＣｌｉｐＨ（ｒｅｆＯｆｆｓｅｔ，ｒｅｆＷ，ｘＲｅｆ），ｙＰｏｓＲＬ］＋
ｆＬ［ｘＰｈａｓｅ，４］＊ｒｌＰｉｃＳａｍｐｌｅＬ［ＣｌｉｐＨ（ｒｅｆＯｆｆｓｅｔ，ｒｅｆＷ，ｘＲｅｆ＋１），ｙＰｏｓＲＬ］＋
ｆＬ［ｘＰｈａｓｅ，５］＊ｒｌＰｉｃＳａｍｐｌｅＬ［ＣｌｉｐＨ（ｒｅｆＯｆｆｓｅｔ，ｒｅｆＷ，ｘＲｅｆ＋２），ｙＰｏｓＲＬ］＋
ｆＬ［ｘＰｈａｓｅ，６］＊ｒｌＰｉｃＳａｍｐｌｅＬ［ＣｌｉｐＨ（ｒｅｆＯｆｆｓｅｔ，ｒｅｆＷ，ｘＲｅｆ＋３），ｙＰｏｓＲＬ］＋
ｆＬ［ｘＰｈａｓｅ，７］＊ｒｌＰｉｃＳａｍｐｌｅＬ［ＣｌｉｐＨ（ｒｅｆＯｆｆｓｅｔ，ｒｅｆＷ，ｘＲｅｆ＋４），ｙＰｏｓＲＬ］）
＞＞ｓｈｉｆｔ１
・・・
ｓｐｓ＿ｒｅｆ＿ｗｒａｐａｒｏｕｎｄ＿ｅｎａｂｌｅｄ＿ｆｌａｇが０に等しい場合、ｎ＝０．．３のサンプル値ｔｅｍｐＡｒｒａｙ［ｎ］は、以下のように導出される。
ｔｅｍｐＡｒｒａｙ［ｎ］＝（ｆＣ［ｘＰｈａｓｅ，０］＊ｒｌＰｉｃＳａｍｐｌｅＣ［Ｃｌｉｐ３（０，ｒｅｆＷＣ－１，ｘＲｅｆ－１），ｙＰｏｓＲＬ］＋
ｆＣ［ｘＰｈａｓｅ，１］＊ｒｌＰｉｃＳａｍｐｌｅＣ［Ｃｌｉｐ３（０，ｒｅｆＷＣ－１，ｘＲｅｆ），ｙＰｏｓＲＬ］＋
ｆＣ［ｘＰｈａｓｅ，２］＊ｒｌＰｉｃＳａｍｐｌｅＣ［Ｃｌｉｐ３（０，ｒｅｆＷＣ－１，ｘＲｅｆ＋１），ｙＰｏｓＲＬ］＋
ｆＣ［ｘＰｈａｓｅ，３］＊ｒｌＰｉｃＳａｍｐｌｅＣ［Ｃｌｉｐ３（０，ｒｅｆＷＣ－１，ｘＲｅｆ＋２），ｙＰｏｓＲＬ］）＞＞ｓｈｉｆｔ１ （Ｈ－５０）
そうでない場合、ｎ＝０．．３のサンプル値ｔｅｍｐＡｒｒａｙ［ｎ］は、以下のように導出される。
ｒｅｆＯｆｆｓｅｔ＝（ｓｐｓ＿ｒｅｆ＿ｗｒａｐａｒｏｕｎｄ＿ｏｆｆｓｅｔ＿ｍｉｎｕｓ１＋１）＊ＭｉｎＣｂＳｉｚｅＹ）／ＳｕｂＷｉｄｔｈＣ
ｔｅｍｐＡｒｒａｙ［ｎ］＝
（ｆＣ［ｘＰｈａｓｅ，０］＊ｒｌＰｉｃＳａｍｐｌｅＣ［ＣｌｉｐＨ（ｒｅｆＯｆｆｓｅｔ，ｒｅｆＷＣ，ｘＲｅｆ－１），ｙＰｏｓＲＬ］＋
ｆＣ［ｘＰｈａｓｅ，１］＊ｒｌＰｉｃＳａｍｐｌｅＣ［ＣｌｉｐＨ（ｒｅｆＯｆｆｓｅｔ，ｒｅｆＷＣ，ｘＲｅｆ），ｙＰｏｓＲＬ］＋
ｆＣ［ｘＰｈａｓｅ，２］＊ｒｌＰｉｃＳａｍｐｌｅＣ［ＣｌｉｐＨ（ｒｅｆＯｆｆｓｅｔ，ｒｅｆＷＣ，ｘＲｅｆ＋１），ｙＰｏｓＲＬ］＋
ｆＣ［ｘＰｈａｓｅ，３］＊ｒｌＰｉｃＳａｍｐｌｅＣ［ＣｌｉｐＨ（ｒｅｆＯｆｆｓｅｔ，ｒｅｆＷＣ，ｘＲｅｆ＋２），ｙＰｏｓＲＬ］）
＞＞ｓｈｉｆｔ１
１．２．４． ＪＶＥＴ－Ｎ００５２
映像圧縮規格における概念としての適応型の解像度の変更は、少なくとも１９９６年あたりから行われており、特に、Ｈ．２６３＋に関連した提案が、参照ピクチャ再サンプリング（ＲＰＲ，Ａｎｎｅｘ Ｐ）および低解像度更新（Ａｎｎｅｘ Ｑ）に対して行われている。最初はＪＣＴ－ＶＣの時代にＣｉｓｃｏ社が提案したもので、次にＶＰ９のコンテキストで（現在は適度に広く展開されている）、そして最近ではＶＶＣのコンテキストで、一定の注目を集めるようになった。ＡＲＣは、所与のピクチャに対して符号化されることが必要とされるサンプルの数を低減でき、所望される場合、結果として得られる参照ピクチャをより高い解像度にアップサンプリングできる。
以下の２つのシナリオにおいて、ＡＲＣが特に興味深いと考える。
１）ＩＤＲピクチャのようなイントラ符号化ピクチャは、インターピクチャよりもかなり大きいことが多い。イントラ符号化されることが意図されたピクチャをダウンサンプリングすることは、理由にかかわらず、将来の予測のためのよりよい入力を提供することができる。それはまた、少なくとも低遅延の適用において、レート制御の観点からも明らかに有利である。
２）少なくとも一部のケーブルや衛星放送事業者が日常的に行っているように、コーデックを限界近くまで運用する場合、ＡＲＣはイントラ符号化ピクチャではない映像でも、困難な遷移点のないシーン遷移などで便利な機能となる。
３）少し先の話になるが、固定解像度という概念は一般的に支持されるのだろうか？ＣＲＴがなくなり、レンダリングデバイスにスケーリングエンジンが普及したことで、レンダリングと符号化の解像度のハードな縛りは過去のものとなった。また、当方は、映像シーケンスの中で多くの動作が行われている場合、たとえその動作が空間的に別の場所で行われていたとしても、多くの人は（おそらく高解像度に関連した）細かい部分に集中することができないことを示唆する利用可能な研究結果があることにも留意している。それが事実であり、一般的に受け入れられている場合、細かい粒度の解像度の変更は、適応ＱＰよりも優れたレート制御メカニズムとなり得る。当方は、この点を今回の議論に取り上げた。なぜなら、当業者からのデータ－フィードバックが得られていないからである。もちろん、固定解像度のビットストリームという概念をなくすことは、無数のシステム層や実装上の影響があることは、（その詳細な性質はわからないまでも、少なくともその存在のレベルを）認識している。
技術的には、ＡＲＣは参照ピクチャの再サンプリングとして実装することができる。参照ピクチャの再サンプリングを実装するには、再サンプリングフィルタと、ビットストリームにおける再サンプリング情報の信号通知という２つの大きな態様がある。本明細書では、後者に焦点を当て、前者については当社の実装経験の範囲内でのみ触れている。適切なフィルタ設計の更なる研究が望まれる
既存のＡＲＣ実装形態の概要
図１１および図１２は、既存のＡＲＣエンコーダ／デコーダの実装形態をそれぞれ示す。本発明の実装形態において、ピクチャのタイプにかかわらず、ピクチャの粒度でピクチャの幅および高さを変更することが可能である。エンコーダにおいて、入力画像データを、現在のピクチャ符号化のために選択されたピクチャサイズにダウンサンプリングする。最初の入力ピクチャをイントラピクチャとして符号化した後、復号化されたピクチャをＤＰＢ（Ｄｅｃｏｄｅｄ Ｐｉｃｔｕｒｅ Ｂｕｆｆｅｒ）に記憶する。後続のピクチャを異なるサンプリング比でダウンサンプリングし、インターピクチャとして符号化する場合、ＤＰＢにおける参照ピクチャは、参照のピクチャサイズと現在のピクチャサイズとの間の空間的比率に従ってアップスケール／ダウンスケールされる。デコーダにおいて、復号化されたピクチャは再サンプリングされずにＤＰＢに記憶される。しかしながら、ＤＰＢにおける参照ピクチャは、動き補償のために使用される場合、現在の復号化ピクチャと参照との間の空間的比率に対してアップスケール／ダウンスケールされる。復号化されたピクチャは、表示のためにバンプアウトされる時に、元のピクチャサイズまたは所望の出力ピクチャサイズにアップサンプリングされる。動き推定／補償処理において、動きベクトルは、ピクチャサイズ比およびピクチャオーダカウントの差との関連でスケーリングされる。
ＡＲＣパラメータの信号通知
ＡＲＣパラメータという用語は、本明細書では、ＡＲＣを動作させるために必要な任意のパラメータの組み合わせとして使用される。最も簡単な場合、それはズーム係数であってもよいし、または定義されたズーム係数を有する表へのインデックスであってもよい。これは、オブジェクト解像度（例えば、サンプルまたは最大ＣＵサイズ粒度での）であってもよいし、またはＪＶＥＴ－Ｍ０１３５に提案されているように、オブジェクト解像度を提供する表へのインデックスであってもよい。また、使用されるアップ／ダウンサンプリングフィルタのフィルタセレクタまたはフィルタパラメータ（フィルタ係数まで）も含まれる。
最初から、当方は、少なくとも概念的に、ピクチャの異なる部分に対して異なるＡＲＣパラメータを許可することを提案している。当方は、現在のＶＶＣ草案に基づく適切な構文構造は、長方形のＴＧ（Ｔｉｌｅ Ｇｒｏｕｐ）であることを提案する。スキャン順序のＴＧを使っている人たちは、ＡＲＣの使用がフルピクチャのみに制限されるか、スキャン順序のＴＧが長方形のＴＧに含まれる範囲に制限されることになる（これまでＴＧのネスティングが議論された記憶はなく、もしかしたら悪しきアイデアかもしれない）。これは、ビットストリーム制約によって容易に規定することができる。
異なるＴＧは異なるＡＲＣパラメータを持つ可能性があるため、ＡＲＣパラメータの適切な場所は、ＴＧヘッダの中かＴＧの範囲があるパラメータセットの中のどちらかであり、ＴＧヘッダ、すなわち、現在のＶＶＣ草案での適応パラメータセット、または上位のパラメータセットの表へのより詳細な参照（インデックス）により参照される。これら３つの選択肢のうち、現時点では、ＴＧヘッダを使用してＡＲＣパラメータを含む表のエントリへの参照を符号化することを提案するもので、その表をＳＰＳに配置し、表の最大値を（来るべき）ＤＰＳにおいて符号化する。パラメータセットの値を使用せずに、ＴＧヘッダに直接ズーム係数を符号化することの受け入れも可能である。ＪＶＥＴ－Ｍ０１３５で提案されているように、ＰＰＳを参照に使用することは、当方のようにＡＲＣパラメータのタイルグループごとの信号通知を設計基準としている場合には、逆に好ましくない。
表のエントリそのものに関して、以下のような多くの選択肢がある。
●ダウンサンプル係数の符号化は、寸法のいずれか一方または両方であるか、またはＸおよびＹの寸法において独立して行うか？これはほとんど（ＨＷの）実装に関する議論であり、Ｘ寸法のズーム係数はかなり柔軟性があるが、Ｙ寸法のズーム係数は１に固定されているか、または選択肢が非常に少ない選択を好む者もいるであろう。当方は、構文がこのような制約を表現するには場違いであると提言し、もし制約が望ましいのであれば、適合性の要件として制約が表現される方を好む。言い換えれば、構文をフレキシブルに保つ。
●符号化対象の解像度。これについて、当方は下記のように提案する。現在の解像度に関連して、これらの解像度には多かれ少なかれ複雑な制約が存在し得、おそらくビットストリーム適合性で表される。
●ピクチャの組み立て／抽出を可能にするために、タイルグループごとのダウンサンプリングが好ましい。しかしながら、それは信号通知の観点から重要ではない。グループがＡＲＣをピクチャの粒度でのみ許可するという賢明でない決定をしていた場合、当方は、常に、すべてのＴＧが同じＡＲＣパラメータを使用するというビットストリーム適合性の要件を含めることができる。
●ＡＲＣに関する情報の制御。以下の発明者らの設計には、参照ピクチャサイズを含む。
●フィルタの設計に柔軟性を持たせる必要があるのか？一握りのコードポイントより大きいものはあるか？ある場合、それらをＡＰＳに入れるか？（いいえ、再度のＡＰＳ更新の議論はしないでください。ダウンサンプルフィルタが変化し、ＡＬＦが維持される場合、ビットストリームはオーバーヘッドを受け入れなければならないと、当方は提案する。
今回、提案された技術を（可能な限り）一貫したシンプルなものにするために、以下を提案する。
●固定フィルタの設計
●ＳＰＳ内の表に表示されたターゲットの解像度、ビットストリームの制約ＴＢＤ
●キャップの交換／交渉を容易にするためのＤＰＳの最小／最大のターゲット解像度
結果として得られる構文は、以下のように確認できる。
デコーダパラメータセットＲＢＳＰ構文
Figure 2022532334000007
ｍａｘ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、ビットストリームの輝度サンプル単位で符号化されたピクチャの最大の幅を規定する。ｍａｘ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、０に等しくなく、かつ、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。ｄｅｃ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］の値は、ｍａｘ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓの値よりも大きくすることはできない。
ｍａｘ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、輝度サンプル単位で復号化されたピクチャの最大の高さを規定する。ｍａｘ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、０に等しくなく、かつ、ＭｉｎＣｂＳｉｚｅＹの整数倍でなければならない。ｄｅｃ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］の値は、ｍａｘ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓの値よりも大きくすることはできない。
シーケンスパラメータセットＲＢＳＰ構文
Figure 2022532334000008
１に等しいａｄａｐｔｉｖｅ＿ｐｉｃ＿ｒｅｓｏｌｕｔｉｏｎ＿ｃｈａｎｇｅ＿ｆｌａｇは、出力ピクチャサイズ（ｏｕｔｐｕｔ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ、ｏｕｔｐｕｔ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ）、復号化されたピクチャサイズの数の指示（ｎｕｍ＿ｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＿ｍｉｎｕｓ１）、少なくとも１つの復号化されたピクチャサイズ（ｄｅｃ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］、ｄｅｃ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］）がＳＰＳに存在することを規定する。参照ピクチャサイズ（ｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ、ｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ）は、ｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｓｉｚｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値を条件に存在する。
ｏｕｔｐｕｔ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、輝度サンプル単位で出力ピクチャの幅を規定する。ｏｕｔｐｕｔ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは０に等しくない。
ｏｕｔｐｕｔ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、輝度サンプル単位で出力ピクチャの高さを規定する。ｏｕｔｐｕｔ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは０に等しくない。
１に等しいｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｓｉｚｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、ｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓおよびｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓが存在することを規定する。
ｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、輝度サンプル単位で参照ピクチャの幅を規定する。ｏｕｔｐｕｔ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは０に等しくない。存在しない場合、ｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓの値は、ｄｅｃ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓと等しいと推測される。
ｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、輝度サンプル単位で参照ピクチャの高さを規定する。ｏｕｔｐｕｔ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは０に等しくない。存在しない場合、ｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓの値は、ｄｅｃ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓと等しいと推測される。
注１－出力ピクチャのサイズは、ｏｕｔｐｕｔ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓおよびｏｕｔｐｕｔ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓの値と等しい。参照ピクチャのサイズは、参照ピクチャが動き補償に使用される場合、ｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓおよび＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓの値と等しい。
ｎｕｍ＿ｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＿ｍｉｎｕｓ１＋１は、符号化された映像シーケンスにおいて、輝度サンプル単位で復号化されたピクチャサイズ（ｄｅｃ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］、ｄｅｃ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］）の数を規定する。
ｄｅｃ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］は、符号化された映像シーケンスにおいて、輝度サンプルの単位で復号化されたピクチャサイズのｉ番目の幅を規定する。ｄｅｃ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］は、０に等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。
ｄｅｃ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］は、符号化された映像シーケンスにおいて、輝度サンプル単位で復号化されたピクチャサイズのｉ番目の幅を規定する。ｄｅｃ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］は、０に等しくなく、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。
注２－ｉ番目の復号化ピクチャサイズ（ｄｅｃ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］、ｄｅｃ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｉ］）は、符号化された映像シーケンスの復号化されたピクチャサイズと等しくてもよい。
タイルグループヘッダ構文
Figure 2022532334000009
ｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｄｘは、復号化されたピクチャの幅がｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｄｘ］と等しく、かつ、復号化されたピクチャの高さがｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ［ｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｄｘ］と等しくなることを規定する。
フィルタ
提案された設計は、概念的には、４つの異なるフィルタセット、即ち、元のピクチャから入力ピクチャへのダウンサンプリングフィルタ、動き推定／補償のための参照ピクチャを再スケーリングするためのアップ／ダウンサンプリングフィルタ、および、復号化ピクチャから出力ピクチャへのアップサンプリングフィルタ、を含む。最初および最後のものは、非標準的なものとして排除されてもよい。本明細書の範囲内で、アップ／ダウンサンプリングフィルタは、適切なパラメータセットにおいて明示的に信号通知されるか、または予め定義される必要がある。
本実装形態は、動き補償に使用される参照ピクチャをリサイズするためにダウンサンプリングを行うための、１２タップおよび２Ｄ分離可能フィルタである、ＳＨＶＣ（ＳＨＭ第１２．４版）のダウンサンプリングフィルタを使用する。現在の実装形態において、２進サンプリングのみがサポートされる。そのため、デフォルトでは、ダウンサンプリングフィルタの位相をゼロに設定する。アップサンプリングの場合、１６位相を有する８タップ補間フィルタが使用され、位相をシフトさせ、輝度および彩度画素の位置を元の位置に合わせる。
表１および表２は、輝度アップサンプリング処理に使用されるｐ＝０．．１５およびｘ＝０．．７の８タップフィルタ係数ｆＬ［ｐ，ｘ］と、彩度アップサンプリング処理に使用されるｐ＝０．．１５およびｘ＝０．．３の４タップフィルタ係数ｆＣ［ｐ，ｘ］とを示す。
表３は、ダウンサンプリング処理における１２タップのフィルタ係数を示す。同じフィルタ係数が、ダウンサンプリングのために輝度および彩度の両方に使用される。
表１． １６位相を有する輝度アップサンプリングフィルタ
Figure 2022532334000010
表２． １６位相を有する彩度アップサンプリングフィルタ
Figure 2022532334000011
表３． 輝度および彩度のためのダウンサンプリングフィルタ係数
Figure 2022532334000012
当方は、他のフィルタ設計について実験していない。コンテンツおよび／またはスケーリング係数に適応可能なフィルタを使用する場合、（おそらく有意な）主観的および客観的な利得が期待され得るものと予想する。
タイルグループ境界の議論について
タイルグループに関連した多くの作業におそらく当てはまるので、本実装形態は、ＴＧ（Ｔｉｌｅ Ｇｒｏｕｐ）ベースのＡＲＣに関しては、あまり完成されていない。当方は、圧縮ドメインにおいて、複数のサブピクチャの圧縮されたピクチャへの空間的な組み合わせや抽出に関する議論が、少なくとも作業草案を作成した後に、この実装形態を再検討したいと考えている。しかしながら、それは、私たちが結果をある程度外挿することを妨げず、そして私たちの信号通知の設計をそれに応じて適応させることを妨げない。
ここで、既に述べた理由により、タイルグループヘッダは、上述したようにｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｄｘのようなもののための正しい場所であると考える。使用されるＡＲＣパラメータを示すために、タイルグループヘッダに条件付きで存在する単一のｕｅ（ｖ）コードポイントｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｄｘを使用する。ピクチャごとだけのＡＲＣである本実装形態に合わせるためには、今すぐにでも仕様の空きにてやるべきことは、単一のタイルグループのみを符号化するか、または、所与の符号化されたピクチャのすべてのＴＧヘッダがｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｄｘの値が同じであること（存在する場合）をビットストリームコンプライアンスの条件とすることである。
パラメータｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｄｘは、サブピクチャを開始するいかなるヘッダの中へも移動可能である。今のところ、タイルグループヘッダが継続して存在するのではないかと当方は考える。
これらの構文上の考慮を超えて、タイルグループまたはサブピクチャベースのＡＲＣを可能にするために、いくつかの追加の作業が必要である。おそらく最も困難な部分は、サブピクチャをより低いサイズに再サンプリングした場合、ピクチャにおける不要なサンプルの問題にどのように対処するかである。
４つのサブピクチャ（ビットストリーム構文では、おそらく４つの長方形のタイルグループとして表現される）で構成されている図１３の右側の部分を考える。左側に向かって、右下のＴＧをサイズの半分にサブサンプリングする。「ハーフ」と記された該当する区域外のサンプルについて、どのように対処するか？
既存の映像符号化規格の中には、共通して、圧縮ドメインにおけるピクチャの一部の空間的抽出がサポートされていないものがある。これは、ピクチャの各サンプルが１または複数の構文要素によって表現され、各構文要素が少なくとも１つのサンプルに影響を与えることを意味する。この状態を維持したいのであれば、ダウンサンプリングされたＴＧでカバーされているサンプルの周辺に「ハーフ」というラベルを付けて、何らかの形で追加投入する必要がある。Ｈ．２６３＋Ａｎｎｅｘ Ｐは、この問題をパディングによって解決した。実際、パディングされたサンプルのサンプル値は、ビットストリームにおいて（ある厳しい制限内で）信号通知されてもよい。
これまでの想定から大きく外れるかもしれないが、ピクチャの矩形部分に基づいてサブビットストリームの抽出（および組み合わせ）をサポートしたい場合には、いずれにしても必要となる可能性がある代替案は、（たとえその何かが、スキップされたブロックであっても）、再構成されたピクチャの各サンプルが符号化されたピクチャの何かで表現されなければならないという現在の理解を緩和することになる。
実装上の考慮事項、システムへの影響、プロファイル／レベル
当方は、「ベースライン／メイン」プロファイルに含めるべき基本的なＡＲＣを提案する。特定の適用シナリオに必要でない場合、サブプロファイリングを使用してそれらを除去してもよい。特定の制限を許容可能としてもよい。この点については、あるＨ．２６３＋のプロファイルや（プロファイルよりも前に作られた）「推奨モード」には、Ａｎｎｅｘ Ｐを「４の暗黙係数」、すなわち、両方の寸法での２進ダウンサンプリングとしてのみ使用するという制限が含まれていることに、当方は留意している。テレビ会議における高速スタート（Ｉフレームを迅速に取得する）をサポートするのにそれで十分であった。
その設計は、すべてのフィルタリングを「オンザフライ」で行うことができ、メモリの帯域幅の増加が全くない、またはごくわずかであると考えられる。その限りで、ＡＲＣをエキゾチックプロファイルに加える必要はない。
マラケシュでＪＶＥＴ－Ｍ０１３５に関連して主張されたように、複雑な表などがケイパビリティ・エクスチェンジに有意義に使用できるとは考えていない。オファー・アンサーや同様の限定されたハンドシェイクを想定した場合、意味のあるクロスベンダーの相互運用を可能にするには、単純にオプションの数が多すぎる。現実的には、ケイパビリティ・エクスチェンジのシナリオで意味のある方法でＡＲＣをサポートするためには、せいぜい一握りのインターロップポイントに頼らざるを得ない。例えば、ＡＲＣなし、４の暗黙係数のＡＲＣ、フルＡＲＣなど。別の方法として、すべてのＡＲＣに必要なサポートを仕様化し、ビットストリームの複雑性の制限を上位レベルのＳＤＯに任せることもできる。これはいずれにしても、（サブプロファイリングやフラグコンテキストですでに行ったことを超えて）戦略的な議論をする必要がある。
レベルについては、ビットストリーム適合性の条件として、ビットストリームでどれだけアップサンプリングが信号通知されていても、アップサンプリングされたピクチャのサンプル数はビットストリームのレベルに収まらなければならず、また、すべてのサンプルはアップサンプリングされた符号化ピクチャに収まらなければならないという基本的な設計原則が必要だと考える。なお、Ｈ２６３＋ではこのようなことはなく、特定のサンプルが存在しない可能性があった。
１．２．５． ＪＶＥＴ－Ｎ０１１８
以下の態様が提案される。
１）ピクチャの解像度のリストがＳＰＳで信号通知され、リストのインデックスがＰＰＳで信号通知され、個々のピクチャサイズが指定される。
２）出力されるピクチャについては、再サンプリング前の復号化されたピクチャが（必要に応じて）クロップし、出力され、つまり、再サンプリングされたピクチャは出力用ではなく、インター予測の参照用にのみ使用される。
３）１．５ｘおよび２ｘの再サンプリング率をサポート。任意の再サンプリング率をサポートしない。さらに、他の１、２種類の再サンプリング率の必要性を検討する。
４）ピクチャレベルの再サンプリングとブロックレベルの再サンプリングでは、ブロックレベルの再サンプリングの方が支持されている。
ａ．しかしながら、ピクチャレベルの再サンプリングを選択する場合、以下の態様が提案される。
ｉ．参照ピクチャを再サンプリングするとき、再サンプリングされたバージョンの参照ピクチャと元の再サンプリングされたバージョンの参照ピクチャとの両方がＤＰＢに記憶され、したがって、両方がＤＰＢのフルネスに影響を及ぼす。
ｉｉ．対応する再サンプリングされていない参照ピクチャが「参照のために使用されない」とマークされている場合、再サンプリングされた参照ピクチャは、「参照のために使用されない」とマークされる。
ｉｉｉ．ＲＰＬ信号通知構文は変更されず、ＲＰＬ構築処理は以下のように修正される。参照ピクチャをＲＰＬエントリに含めることが必要であり、かつ、現在のピクチャと同じ解像度を有するその参照ピクチャのバージョンがＤＰＢに含まれていない場合、ピクチャ再サンプリング処理が呼び出され、かつ、その参照ピクチャの再サンプリングされたバージョンがＲＰＬエントリに含まれる。
ｉｖ．ＤＰＢに存在し得る再サンプリングされた参照ピクチャの数は、例えば、２以下となるように制限される。
ｂ．そうでない場合（ブロックレベルの再サンプリングが選択される）、以下が提案される。
ｉ．最悪の場合のデコーダの複雑性を制限するために、現在のピクチャとは異なる解像度の参照ピクチャからのブロックの双方向予測が許可されないことを提案する。
ｉｉ．別の選択肢は、再サンプリングおよび１／４画素補間を行う必要がある場合、２つのフィルタを組み合わせ、この動作を直ちに適用することである。
５）ピクチャベースの再サンプリングアプローチとブロックベースの再サンプリングアプローチのどちらを選択するかに関わらず、必要に応じて時間的動きベクトルのスケーリングを適用することを提案する。
１．２．５．１．実装
ＡＲＣソフトウェアは、ＶＴＭ－４．０．１の上に実装され、以下のように変更された。
－サポートされている解像度のリストがＳＰＳにて信号通知される。
－空間的解像度信号通知は、ＳＰＳからＰＰＳに移された。
－参照ピクチャを再サンプリングするために、ピクチャベースの再サンプリングスキームを実装した。ピクチャが復号化された後、再構成されたピクチャが異なる空間的解像度に再サンプリングされてよい。元の再構成ピクチャおよび再サンプリングされた再構成ピクチャは、両方ともＤＰＢに記憶され、復号化の順序に将来のピクチャによって参照のために利用可能である。
－実装された再サンプリングフィルタは、ＪＣＴＶＣ－Ｈ０２３４で試験されたフィルタに基づいており、以下のように行われる。
ｏアップサンプリングフィルタ：タップ（－４，５４，１６，－２）／６４を有する、４タップ＋／－ １／４位相ＤＣＴＩＦ
ｏダウンサンプリングフィルタ：タップ（１，０，－３，０，１０，１６，１０，０，－３，０，１）／３２を有する、ｈ１１フィルタ
－現在のピクチャの参照ピクチャリスト（即ち、Ｌ０およびＬ１）を構築する場合、現在のピクチャと同じ解像度を有する参照ピクチャのみを使用する。なお、参照ピクチャサイズは、元のサイズでも、再サンプリングされたサイズでも利用可能であってよい。
－ＴＭＶＰおよびＡＴＶＭＰは、有効化されてもよい。しかしながら、現在のピクチャと参照ピクチャの元の符号化解像度が異なる場合、その参照ピクチャに対してＴＭＶＰおよびＡＴＭＶＰは無効化される。
－開始点ソフトウェアの実装形態の便宜上および簡素化のため、ピクチャを出力するとき、デコーダは最も高い利用可能な解像度を出力する。
１．２．５．２． ピクチャサイズおよびピクチャ出力の信号通知について
１．ビットストリームにおける符号化されたピクチャの空間的解像度のリストにおいて
現在、ＣＶＳにおけるすべての符号化されたピクチャは同じ解像度を有する。従って、ＳＰＳにおいて１つの解像度（即ち、ピクチャの幅および高さ）のみを信号通知することは簡単である。ＡＲＣをサポートする場合、１つの解像度の代わりに、ピクチャ解像度のリストを信号通知することが必要であり、個々のピクチャサイズを規定するために、このリストがＳＰＳにて信号通知され、このリストへのインデックスをＰＰＳにて信号通知することを提案する。
２．ピクチャ出力について
出力されるピクチャについては、再サンプリング前の復号化されたピクチャを（必要に応じて）クロップし、出力する、つまり、再サンプリングされたピクチャは出力用ではなく、インター予測の参照用にのみ使用されることを提案する。ＡＲＣ再サンプリングフィルタは、インター予測のために再サンプリングされたピクチャの使用を最適化するように設計されるべきであり、このようなフィルタは、ピクチャの出力／表示の目的に最適ではない場合があり、一方、映像端末デバイスは、通常、最適化された出力ズーム／スケーリング機能を既に実装している。
１．２．５．３． 再サンプリングについて
復号化されたピクチャの再サンプリングは、ピクチャベースのものであってもよいし、ブロックベースのものであってもよい。ＶＶＣの最終的なＡＲＣ設計では、ピクチャベースの再サンプリングよりも、ブロックベースの再サンプリングを優先している。当方は、これら２つのアプローチを検討し、ＪＶＥＴがＶＶＣにおけるＡＲＣサポートのためにこれら２つのアプローチのうちどちらを規定すべきかを決定することを推奨する。
ピクチャベースの再サンプリング
ＡＲＣのためのピクチャベースの再サンプリングにおいて、ピクチャは特定の解像度のために１回だけ再サンプリングされ、次いでＤＰＢに記憶され、一方、同じピクチャの再サンプリングされていないバージョンもＤＰＢに保持される。
ＡＲＣに対してピクチャベースの再サンプリングを使用することには、以下の２つの問題がある。１）再サンプリングされた参照ピクチャを記憶するために、ＤＰＢバッファを追加する必要がある。２）ＤＰＢから参照ピクチャデータを読み取り、ＤＰＢに参照ピクチャデータを書き込む動作が増えるため、メモリの帯域幅を追加する必要がある。
ＤＰＢにおいて１つのバージョンの参照ピクチャのみを保持することは、ピクチャベースの再サンプリングにとって好適なアイデアではない。再サンプリングされていないバージョンのみを保持する場合、複数のピクチャが同じ参照ピクチャを参照する場合があるので、参照ピクチャを複数回再サンプリングする必要がある場合がある。一方、参照ピクチャを再サンプリングし、再サンプリングされたバージョンのみを維持する場合、上述したように、再サンプリングされていないピクチャを出力する方がよいため、参照ピクチャを出力する必要がある場合、逆方向の再サンプリングを行う必要がある。これは、再サンプリング処理が可逆演算ではないため問題となる。ピクチャＡをダウンサンプリングした後、アップサンプリングしてＡと同じ解像度のＡ’を得たとしても、ＡとＡ’は同じではない。ダウンサンプリングとアップサンプリングの処理中に高周波の情報が失われているため、Ａ’に含まれる情報はＡよりも少なくなる。
追加のＤＰＢバッファおよびメモリ帯域幅の問題に対処するために、当方は、ＶＶＣにおけるＡＲＣ設計がピクチャベースの再サンプリングを使用する場合、以下を適用することを提案する。
１．参照ピクチャを再サンプリングするとき、再サンプリングされたバージョンの参照ピクチャと元の再サンプリングされたバージョンの参照ピクチャとの両方がＤＰＢに記憶され、したがって、両方がＤＰＢのフルネスに影響を及ぼす。
２．対応する再サンプリングされていない参照ピクチャが「参照のために使用されない」とマークされている場合、再サンプリングされた参照ピクチャは、「参照のために使用されない」とマークされる。
３．各タイルグループのＲＰＬ（Ｒｅｆｅｒｅｎｃｅ Ｐｉｃｔｕｒｅ Ｌｉｓｔ）は、現在のピクチャと同じ解像度を有する参照ピクチャを含む。ＲＰＬ信号通知構文を変更する必要はないが、ＲＰＬ構築処理は、前文で言及されたことを保証するように、以下のように修正される。参照ピクチャをＲＰＬエントリに含めることが必要であり、かつ、現在のピクチャと同じ解像度を有するその参照ピクチャのバージョンがまだ利用可能でない場合、ピクチャ再サンプリング処理が呼び出され、かつ、その参照ピクチャの再サンプリングされたバージョンが含まれる。
４．ＤＰＢに存在し得る再サンプリングされた参照ピクチャの数は、例えば、２以下となるように制限されるべきである。
さらに、時間的ＭＶが現在のものとは異なる解像度の参照フレームに由来する場合、時間的ＭＶの使用（例えば、マージモードおよびＡＴＭＶＰ）を可能にするために、当方は、時間的ＭＶを必要に応じて現在の解像度にスケーリングすることを提案する。
ブロックベースのＡＲＣ再サンプリング
ＡＲＣのためのブロックベースの再サンプリングにおいて、参照ブロックは必要に応じて再サンプリングされ、再サンプリングされたピクチャはＤＰＢに記憶されない。
ここでの主な問題は、付加的なデコーダの複雑性である。これは、参照ピクチャにおけるブロックが、別のピクチャにおける複数のブロックによって、および複数のピクチャにおける複数のブロックによって、複数回参照される場合があるためである。
参照ピクチャにおけるブロックが現在のピクチャのブロックによって参照され、参照ピクチャの解像度と現在のピクチャの解像度が異なる場合、補間フィルタを呼び出すことによって、参照ブロックが整数画素の解像度を有するように参照ブロックを再サンプリングする。動きベクトルが１／４画素である場合、再び補間処理が呼び出され、１／４画素解像度で再サンプリングされた参照ブロックが取得される。従って、異なる解像度を伴う参照ブロックからの現在のブロックに対する各動き補償動作のために、１つの補間フィルタリング動作の代わりに２つまでの補間フィルタリング動作が必要である。ＡＲＣサポートがない場合、１つの補間フィルタ動作（すなわち、１／４画素の解像度での参照ブロックの生成）しか必要とされない。
最悪の場合の複雑性を抑制するために、ＶＶＣにおけるＡＲＣ設計がブロックベースの再サンプリングを使用する場合、以下が適用されることを提案する。
－現在のピクチャとは異なる解像度を有する参照ピクチャからのブロックの双方向予測が許可されない。
－より正確には、この制約は以下の通りである。現在のピクチャｐｉｃＡにおける現在のブロックｂｌｋＡが、参照ピクチャｐｉｃＢにおける参照ブロックｂｌｋＢを参照する際に、ｐｉｃＡとｐｉｃＢとが異なる解像度を有する場合、ブロックｂｌｋＡは、単一予測ブロックであるとする。
この制約により、ブロックを復号化するのに必要な最悪の場合の補間動作の数は、２回に限定される。ブロックが異なる解像度のピクチャからのブロックを参照する場合、上述したように、必要な補間動作の数は２回である。これは、補間演算の数も２回であるため（すなわち、各参照ブロックに対し１／４画素の解像度を得るため）、ブロックが同じ解像度のピクチャからの参照ブロックを参照し、双方向予測ブロックとして符号化した場合と同様である。
実装形態を簡単にするために、当方は、ＶＶＣにおけるＡＲＣ設計がブロックベースの再サンプリングを使用する場合、以下を適用する別の変形を提案する。
－参照フレームと現在のフレームの解像度が異なる場合、まず、予測子のすべての画素の対応する位置が計算され、次いで、補間が１回だけ適用される。即ち、２つの補間動作（即ち、１つは再サンプリングのためであり、１つは１／４画素補間のためである）を１つの補間演算のみに結合する。現在のＶＶＣにおけるサブ画素補間フィルタは再利用可能であるが、この場合、補間の粒度を大きくするべきであるが、補間動作の回数を２から１に短縮する。
－時間的ＭＶが現在のものとは異なる解像度の参照フレームに由来する場合に、時間的ＭＶの使用（例えば、マージモードおよびＡＴＭＶＰ）を可能にするために、当方は、時間的ＭＶを必要に応じて現在の解像度にスケーリングすることを提案する。
再サンプリング率
ＪＶＥＴ－Ｍ０１３５において、ＡＲＣに関する議論を始めるために、ＡＲＣの開始点として、２ｘ（アップサンプリングの場合、２×２、ダウンサンプリングの場合、１／２×１／２を意味する）の再サンプリング比のみを考慮することが提案された。マラケシュ会議の後、このトピックをさらに検討したところ、２ｘの再サンプリング比のみをサポートすることは、非常に限られており、場合によっては、再サンプリング解像度と非再サンプリング解像度の差が小さいほど有益であることが分かった。
任意の再サンプリング率をサポートすることが望ましい場合があるが、それをサポートすることは困難であると思われた。これは、任意の再サンプリング率をサポートするために、定義され実装されなければならない再サンプリングフィルタの数が多すぎ、デコーダの実装形態に大きな負担がかかるように思われたためである。
当方は、２つ以上であるが少数の再サンプリング比をサポートすべきであるが、少なくとも１．５ｘおよび２ｘの再サンプリング比、および任意の再サンプリング比はサポートされないと提案する。
最大ＤＰＢバッファサイズおよびバッファフルネス
ＡＲＣの場合、ＤＰＢは、同じＣＶＳ内に、異なる空間的解像度の復号化ピクチャを含んでもよい。ＤＰＢ管理および関連する態様の場合、復号化されたピクチャ単位でＤＰＢのサイズおよびフルネスを計数することは、もはや機能しない。
以下は、ＡＲＣがサポートされている場合、最終的なＶＶＣ規格における取り組むべきいくつかの特定の態様および可能な解決策の議論である（当方は、この会議において可能な解決策を採用することを提案していない）。
１．ＭａｘＤｐｂＳｉｚｅ（すなわち、ＤＰＢ内に存在してよい参照ピクチャの最大数）の導出のためにＰｉｃＳｉｚｅＩｎＳａｍｐｌｅｓＹ（すなわち、ＰｉｃＳｉｚｅＩｎＳａｍｐｌｅｓＹ＝ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＊ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ）の値を使用するのではなく、ＭｉｎＰｉｃＳｉｚｅＩｎＳａｍｐｌｅｓＹの値に基づいて、ＭａｘＤｐｂＳｉｚｅの導出を行う。ＭｉｎＰｉｃＳｉｚｅＩｎＳａｍｐｌｅＹは、以下のように定義される。
ＭｉｎＰｉｃＳｉｚｅＩｎＳａｍｐｌｅＹ＝（ビットストリームにおける最小のピクチャ解像度の幅）＊（ビットストリームにおける最小の解像度の高さ）。
ＭａｘＤｐｂＳｉｚｅの導出は、（ＨＥＶＣ式に基づいて）以下のように修正される。
ｉｆ（ＭｉｎＰｉｃＳｉｚｅＩｎＳａｍｐｌｅｓＹ＜＝（ＭａｘＬｕｍａＰｓ＞＞２））
ＭａｘＤｐｂＳｉｚｅ＝Ｍｉｎ（４＊ｍａｘＤｐｂＰｉｃＢｕｆ，１６）
ｅｌｓｅ ｉｆ（ＭｉｎＰｉｃＳｉｚｅＩｎＳａｍｐｌｅｓＹ＜＝（ＭａｘＬｕｍａＰｓ＞＞１））
ＭａｘＤｐｂＳｉｚｅ＝Ｍｉｎ（２＊ｍａｘＤｐｂＰｉｃＢｕｆ，１６）
ｅｌｓｅ ｉｆ（ＭｉｎＰｉｃＳｉｚｅＩｎＳａｍｐｌｅｓＹ＜＝（（３＊ＭａｘＬｕｍａＰｓ）＞＞２））
ＭａｘＤｐｂＳｉｚｅ＝Ｍｉｎ（（４＊ｍａｘＤｐｂＰｉｃＢｕｆ）／３，１６）
ｅｌｓｅ
ＭａｘＤｐｂＳｉｚｅ＝ｍａｘＤｐｂＰｉｃＢｕｆ
２．各復号化されたピクチャは、ＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔと呼ばれる値に関連付けられる。ＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔは、復号化されたピクチャサイズがＭｉｎＰｉｃＳｉｚｅＩｎＳａｍｐｌｅＹに対してどれぐらい大きいかを規定する整数値である。ＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔの定義は、ＶＶＣにおけるＡＲＣのためにどのような再サンプリング比がサポートされるかに依存する。
例えば、ＡＲＣが２の再サンプリング比のみをサポートする場合、ＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔは、次のように定義される。
－ビットストリームにおける最小の解像度を有する復号化されたピクチャは、１のＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔに関連付けられる。
－ビットストリームにおける最小の解像度の２×２の解像度を有する復号化されたピクチャは、４のＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔ（即ち、１＊４）に関連付けられる。
別の例の場合、ＡＲＣが１．５および２の両方の再サンプリング比をサポートする場合、ＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔは、以下のように定義される。
－ビットストリームにおける最小の解像度を有する復号化されたピクチャは、４のＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔに関連付けられる。
－ビットストリームにおける最小の解像度の１．５×１．５の解像度を有する復号化されたピクチャは、９（すなわち、２．２５＊４）のＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔに関連付けられる。
－ビットストリームにおける最小の解像度の２×２の解像度を有する復号化されたピクチャは、１６（即ち、４＊４）のＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔに関連付けられる。
ＡＲＣがサポートする他の再サンプリングレートの場合、各ピクチャサイズに対するＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔの値を判定するために、上記の例に示されるのと同じ原理を使用すべきである。
３．変数ＭｉｎＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔをＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔの最小可能値とする。すなわち、ＡＲＣが２の再サンプリング比のみをサポートする場合、ＭｉｎＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔは１であり、ＡＲＣが１．５および２の再サンプリング比をサポートする場合、ＭｉｎＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔは４であり、同様に、同じ原理を使用してＭｉｎＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔの値を判定する。
４．ｓｐｓ＿ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇ＿ｍｉｎｕｓ１［ｉ］の値の範囲は、０～（ＭｉｎＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔ＊（ＭａｘＤｐｂＳｉｚｅ－１））の範囲で規定される。変数ＭｉｎＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔは、ＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔの最小可能値である。
５．ＤＰＢフルネス動作は、ＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔに基づいて、以下のようで規定される。
－ＨＲＤは復号化ユニット０で初期化され、ＣＰＢおよびＤＰＢの両方が空に設定される（ＤＰＢフルネスが０に等しく設定される）。
－ＤＰＢがフラッシュされる（即ち、すべてのピクチャがＤＰＢから除去される）場合、ＤＰＢフルネスは０に等しく設定される。
－ピクチャがＤＰＢから除去されるとき、ＤＰＢフルネスは、除去されたピクチャに関連付けられたＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔの値だけデクリメントされる。
－ピクチャがＤＰＢに挿入されるとき、ＤＰＢフルネスは、挿入されたピクチャに関連付けられたＰｉｃｔｕｒｅＳｉｚｅＵｎｉｔの値だけインクリメントされる。
１．２．５．４． 再サンプリングフィルタ
ソフトウェアの実装において、実装された再サンプリングフィルタは、単純に、ＪＣＴＶＣ－Ｈ０２３４に記載されている以前に利用可能なフィルタから得られた。より優れた性能および／またはより低い複雑性を提供する場合、他の再サンプリングフィルタが試験され、使用されるべきである。当方は、複雑性と性能との間のトレードオフを取り決めるために、様々な再サンプリングフィルタを試験することを提案する。このような試験は、ＣＥにおいて行うことができる。
１．２．５．５． 既存のツールへのその他の必要な修正
ＡＲＣをサポートするために、既存の符号化ツールの一部に何らかの修正および／または追加の動作が必要とされる場合がある。例えば、ＡＲＣソフトウェア実装のピクチャベースの再サンプリングにおいて、説明を簡単にするために、現在のピクチャと参照ピクチャの元の符号化解像度が異なる場合、ＴＭＶＰおよびＡＴＭＶＰを無効化した。
１．２．６． ＪＶＥＴ－Ｎ０２７９
「将来の映像符号化規格のための要件」によれば、この規格は、それぞれが異なる特性（例えば、空間的解像度またはサンプルビット深さ）を有する、同じコンテンツの複数の表現を提供する適応ストリーミングサービスの場合、高速表現切り替えをサポートするものとする。リアルタイムの映像通信において、Ｉピクチャを挿入せずに符号化された映像シーケンスにおける解像度の変更を許可することは、映像データを動的なチャネル条件またはユーザの好みにシームレスに適応させるだけでなく、Ｉピクチャに起因するビートの影響を除去することができる。適応解像度の変更の仮説例が、異なったサイズの参照ピクチャから現在のピクチャを予測する図１４にて示される。
この寄与は、適応解像度の変更を信号通知するための高レベルな構文と、ＶＴＭにおける現在の動き補償予測処理の修正を提案する。これらの修正は、既存の動き補償補間器を変更せずに、動きベクトルのスケーリングおよびサブ画素の位置の導出に限定される。これにより、既存の動き補償補間器を再利用することができ、追加のコストを招くような適応解像度の変更をサポートするための新しい処理ブロックを必要としない。
１．２．６．１． 適応解像度の変更の信号通知
１．２．６．１．１． ＳＰＳ
Figure 2022532334000013
［［ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、輝度サンプル単位で各復号化されたピクチャの幅を規定する。ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、０に等しくなく、かつ、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。］］
［［ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、輝度サンプル単位で各復号化されたピクチャの高さを規定する。ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、０に等しくなく、かつ、ＭｉｎＣｂＳｉｚｅＹの整数倍とする］］
ｍａｘ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、輝度サンプル単位でＳＰＳを参照する復号化されたピクチャの最大幅を規定する。ｍａｘ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、０に等しくなく、かつ、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。
ｍａｘ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、輝度サンプル単位でＳＰＳを参照する復号化されたピクチャの最大幅を規定する。ｍａｘ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、０に等しくなく、かつ、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。
１．２．６．１．２． ＰＰＳ
Figure 2022532334000014
１に等しいｐｉｃ＿ｓｉｚｅ＿ｄｉｆｆｅｒｅｎｔ＿ｆｒｏｍ＿ｍａｘ＿ｆｌａｇは、ＰＰＳは、参照されたＳＰＳのｍａｘ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓおよびｍａｘ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅとは異なるピクチャ幅またはピクチャ高さ信号通知することを規定する。０に等しいｐｉｃ＿ｓｉｚｅ＿ｄｉｆｆｅｒｅｎｔ＿ｆｒｏｍ＿ｍａｘ＿ｆｌａｇは、ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓおよびｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅが、参照されたＳＰＳのｍａｘ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓおよびｍａｘ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅと同じであることを規定する。
ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、輝度サンプル単位で各復号化されたピクチャの幅を規定する。ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、０に等しくなく、かつ、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓが存在しない場合、ｍａｘ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓに等しいと推測される。
ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、輝度サンプル単位で各復号化されたピクチャの高さを規定する。ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓは、０に等しくなく、かつ、ＭｉｎＣｂＳｉｚｅＹの整数倍とする。ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓが存在しない場合、ｍａｘ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓに等しいと推測される。
すべてのアクティブな参照ピクチャに対して、水平および垂直のスケーリング比が１／８～２の範囲内にあるべきであることがビットストリーム適合性の要件である。スケーリング比は、以下のように定義される。
－ｈｏｒｉｚｏｎｔａｌ＿ｓｃａｌｉｎｇ＿ｒａｔｉｏ＝（（ｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＜＜１４）＋（ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／２））／ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ
－ｖｅｒｔｉｃａｌ＿ｓｃａｌｉｎｇ＿ｒａｔｉｏ＝（（ｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＜＜１４）＋（ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ／２））／ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ
Figure 2022532334000015
参照ピクチャのスケーリング処理
ＣＶＳ内で解像度の変更がある場合、ピクチャは、その参照ピクチャの１または複数とは異なるサイズを有していてよい。この提案は、すべての動きベクトルを、それらが対応する参照ピクチャグリッドの代わりに、現在のピクチャグリッドに正規化する。これは、設計の一貫性を保ち、解像度の変更を動きベクトル予測処理に対してトランスペアレントにするために有益であると主張している。そうでない場合、スケールが異なるため、異なるサイズを有する参照ピクチャを指す近傍の動きベクトルを空間的動きベクトル予測に直接使用できない。
解像度の変更が生じた場合、動き補償予測を行いながら、動きベクトルおよび参照ブロックの両方をスケーリングしなければならない。スケーリング範囲は［１／８，２］に限定され、即ち、アップスケーリングは１：８に限定され、ダウンスケーリングは２：１に限定される。なお、アップスケーリングは、参照ピクチャが現在のピクチャより小さい場合を指し、ダウンスケーリングは、参照ピクチャが現在のピクチャより大きい場合を指す。以下の章では、スケーリング処理をより詳細に説明する。
輝度ブロック
スケーリング係数およびその固定小数点表現は、以下のように定義される。
Figure 2022532334000016
Figure 2022532334000017
このスケーリング処理は、２つの部分を含む。
１．現在のブロックの左上隅の画素を参照ピクチャにマッピングする。
２．水平および垂直ステップサイズを使用して、現在のブロックの他の画素の参照位置をアドレス指定する。
現在のブロックの左上隅の画素の座標が（ｘ，ｙ）である場合、動きベクトル（ｍｖＸ，ｍｖＹ）が指す参照ピクチャにおけるサブ画素の位置（ｘ’，ｙ’）を、１／１６画素単位で以下のように規定する。
●参照ピクチャにおける水平位置は、
ｘ’＝（（Ｘ＜＜４）＋ｍｖＸ）・ｈｏｒｉ＿ｓｃａｌｅ＿ｆｐ （３）
であり、ｘ’は１０の小数ビットのみを維持するようにさらにスケールダウンされる。
ｘ’＝Ｓｉｇｎ（ｘ’）・（（Ａｂｓ（ｘ’）＋（１＜＜７））＞＞８ （４）
●同様に、参照ピクチャにおける垂直方向の位置は、
ｙ’＝（（ｙ＜＜４）＋ｍｖＹ）・ｖｅｒｔ＿ｓｃａｌｅ＿ｆｐ （５）
であり、ｙ’はさらに次のようにスケールダウンされる。
ｙ’＝Ｓｉｇｎ（ｙ’）・（（Ａｂｓ（ｙ’）＋（１＜＜７））＞＞８） （６）
この時点で、現在のブロックの左上隅の画素の参照位置は、（ｗ’，ｙ’）にある。他の参照サブ画素／画素位置は、水平および垂直のステップサイズを有する（ｘ’，ｙ’）に関連して計算される。これらのステップサイズは、上記の水平および垂直スケーリング係数から、１／１０２４画素の精度で、以下のように導出される。
ｘ＿ｓｔｅｐ＝（ｈｏｒｉ＿ｓｃａｌｅ＿ｆｐ＋８）＞＞４ （７）
ｙ＿ｓｔｅｐ＝（ｖｅｒｔ＿ｓｃａｌｅ＿ｆｐ＋８）＞＞４ （８）
一例として、現在のブロックにおける画素が左上隅の画素からｉ列ｊ行離れている場合、その対応する参照画素の水平座標および垂直座標は、以下によって導出される。
ｘ’ｉ＝ｘ’＋ｉ＊ｘ＿ｓｔｅｐ （９）
ｙ’ｊ＝ｙ’＋ｊ＊ｙ＿ｓｔｅｐ （１０）
サブペル補間において、ｘｉ’およびｙｊ’は、フル画素部分と小数画素部分とに分割されなければならない。
●参照ブロックをアドレス指定するためのフル画素部分は以下に等しい。
（ｘ’ｉ＋３２）＞＞１０ （１１）
（ｙ’ｊ＋３２）＞＞１０ （１２）
●補間フィルタを選択するために使用される小数画素部分は以下に等しい。
Δｘ＝（（ｘ’ｉ＋３２）＞＞６）＆１５ （１３）
Δｙ＝（（ｙ’ｊ＋３２）＞＞６）＆１５ （１４）
参照ピクチャ内のフル画素位置および小数画素位置が判定されると、既存の動き補償補間器を追加の変更なしに使用できる。フル画素位置は、参照ピクチャから参照ブロックパッチをフェッチするために使用され、小数画素位置は、適切な補間フィルタを選択するために使用される。
彩度ブロック
彩度フォーマットが４：２：０である場合、彩度動きベクトルは、１／３２画素の精度を有する。彩度動きベクトルおよび彩度参照ブロックのスケーリング処理は、彩度フォーマットに関連した調整を除いて、輝度ブロックとほぼ同じである。
現在の彩度ブロックの左上隅の画素の座標が（ｘｃ，ｙｃ）である場合、参照彩度ピクチャにおける最初の水平および垂直位置は、以下に等しい。
ｘｃ’＝（（ｘｃ＜＜５）＋ｍｖＸ）・ｈｏｒｉ＿ｓｃａｌｅ＿ｆｐ （１）
ｙｃ’＝（（ｙｃ＜＜５）＋ｍｖＹ）・ｖｅｒｔ＿ｓｃａｌｅ＿ｆｐ （２）
ｍｖＸおよびｍｖＹは元の輝度動きベクトルであるが、ここでは１／３２画素の精度で検査されるべきである。
ｘｃ’、ｙｃ’はさらにスケールダウンされ、１／１０２４画素の精度を維持する。
ｘｃ’＝Ｓｉｇｎ（ｘｃ’）・（（Ａｂｓ（ｘｃ’）＋（１＜＜８））＞＞９ （３）
ｙｃ’＝Ｓｉｇｎ（ｙｃ’）・（（Ａｂｓ（ｙｃ’）＋（１＜＜８））＞＞９ （４）
関連する輝度の方程式と比較して、上記の右シフトは、１つの余分なビットだけ増加される。
使用されるステップサイズは、輝度の場合と同じである。左上隅の画素に関する（ｉ，ｊ）における彩度画素の場合、その参照画素の水平座標および垂直座標は、以下のように導出される。
ｘｃ’ｉ＝ｘｃ’＋ｉ＊ｘ＿ｓｔｅｐ （５）
ｙｃ’ｊ＝ｙｃ’＋ｊ＊ｙ＿ｓｔｅｐ （６）
サブ画素補間において、ｘｃ’ｉおよびｙｃ’ｊは、また、フル画素部分および小数画素部分に分けられる。
●参照ブロックをアドレス指定するためのフル画素部分は以下に等しい。
（ｘｃ’ｉ＋１６）＞＞１０ （７）
（ｙｃ’ｊ＋１６）＞＞１０ （８）
●補間フィルタを選択するために使用される小数画素部分は、以下に等しい。
Δｘ＝（（ｘｃ’ｉ＋１６）＞＞５）＆３１ （９）
Δｙ＝（（ｙｃ’ｊ＋１６）＞＞５）＆３１ （１０）
他の符号化ツールとの相互作用
参照ピクチャのスケーリングを有する一部の符号化ツールとの相互作用に関連付けられた過度な複雑性とメモリ帯域幅のため、ＶＶＣ仕様に以下の制限を加えることが推奨される。
－ｔｉｌｅ＿ｇｒｏｕｐ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇが１に等しい場合、現在のピクチャとその並置されたピクチャは同じサイズを有するものとする。
－解像度の変更がシーケンス内で許可されている場合、デコーダ動きベクトルの改善は停止されるものとする。
－解像度の変更がシーケンス内で許可されている場合、ｓｐｓ＿ｂｄｏｆ＿ｅｎａｂｌｅｄ＿ｆｌａｇは０に等しいものとする。
１．３． ＪＶＥＴ－Ｎ０４１５におけるＣＴＢ（Ｃｏｄｉｎｇ Ｔｒｅｅ Ｂｌｏｃｋ）ベースのＡＬＦ（Ａｄａｐｔｉｖｅ Ｌｏｏｐ Ｆｉｌｔｅｒ）
スライスレベル時間的フィルタ
ＶＴＭ４にはＡＰＳ（Ａｄａｐｔｉｖｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）が採用された。各ＡＰＳは、１つのセットの信号通知されたＡＬＦフィルタを含み、最大３２個のＡＰＳがサポートされる。本提案では、スライスレベルの時間的フィルタがテストされる。タイルグループは、ＡＰＳからのＡＬＦ情報を再利用することにより、オーバーヘッドを低減することができる。ＡＰＳは、ＦＩＦＯ（Ｆｉｒｓｔ－Ｉｎ－Ｆｉｒｓｔ－Ｏｕｔ）バッファとして更新される。
ＣＴＢベースのＡＬＦ
輝度成分に対し、ＡＬＦが輝度ＣＴＢに適用される際に、１６個の固定された、５個の時間的な、または１つの信号通知されたフィルタセットの中からの選択が示される。フィルタセットインデックスのみが信号通知される。１つのスライスに対して、２５個のフィルタからなる１つの新しいセットのみを信号通知することができる。１つのスライスに対して新しいセットが信号通知された場合、同じスライス内のすべての輝度ＣＴＢはそのセットを共有する。固定フィルタセットを使用して新しいスライスレベルフィルタセットを予測することができ、これを輝度ＣＴＢに対する候補フィルタセットとして使用できる。フィルタの数は合計６４個である。
彩度成分に対し、ＡＬＦが彩度ＣＴＢに適用される際に、スライスに対して新しいフィルタが信号通知する場合、ＣＴＢは新しいフィルタを使用し、そうでない場合、時間スケーラビリティ制約を満たす最も新しい時間的彩度フィルタが適用される。
スライスレベルの時間的フィルタとして、ＡＰＳは、ＦＩＦＯ（Ｆｉｒｓｔ－Ｉｎ－Ｆｉｒｓｔ－Ｏｕｔ）バッファとして更新される。
１．４． 代替時間的動きベクトル予測（別名、ＶＶＣにおけるサブブロックベースの時間マージ候補）
ＡＴＭＶＰ（Ａｌｔｅｒｎａｔｉｖｅ Ｔｅｍｐｏｒａｌ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ）において、ＴＭＶＰ（Ｔｅｍｐｏｒａｌ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ）は、現在のＣＵより小さいブロックから複数セットの動き情報（動きベクトルおよび参照インデックスを含む）をフェッチすることで修正される。図１５に示すように、サブＣＵは、正方形のＮ×Ｎブロックである（デフォルトでは、Ｎは８に設定される）。
ＡＴＭＶＰは、ＣＵ内のサブＣＵの動きベクトルを２つのステップで予測する。第１のステップは、参照ピクチャにおける対応するブロックを、いわゆる時間的ベクトルで特定することである。参照ピクチャは、動きソースピクチャと呼ばれる。第２のステップは、図１５に示すように、現在のＣＵをサブＣＵに分割し、各サブＣＵに対応するブロックから各サブＣＵの動きベクトルならびに参照インデックスを取得する。
第１のステップにおいて、現在のＣＵの空間的に近傍のブロックの動き情報によって、参照ピクチャおよび対応するブロックが判定される。近傍のブロックの繰り返しスキャン処理を回避するために、現在のＣＵのマージ候補リストにおけるブロックＡ０（左ブロック）からのマージ候補が使用される。並置された参照ピクチャを参照するブロックＡ０から第１の利用可能な動きベクトルが、時間的ベクトルとなるように設定される。このように、ＡＴＭＶＰでは、ＴＭＶＰに比べて、対応するブロックをより正確に特定することができ、対応するブロック（配列されたブロックと呼ばれることがある）は、常に現在のＣＵに対して右下または中心位置にある。
第２のステップにおいて、現在のＣＵの座標に時間ベクトルを加えることにより、サブＣＵの対応するブロックが、動きソースピクチャにおける時間的ベクトルにより特定される。各サブＣＵに対し、その対応するブロックの動き情報（例えば、中心サンプルを覆う最小の動きグリッド）が使用され、サブＣＵの動き情報を導出する。対応するＮ×Ｎブロックの動き情報が特定された後、ＨＥＶＣのＴＭＶＰと同様に、現在のサブＣＵの動きベクトルおよび参照インデックスに変換され、動きスケーリングや他の手順が適用される。
１．５． アフィン動き予測
ＨＥＶＣにおいて、並進運動モデルのみが、ＭＣＰ（Ｍｏｔｉｏｎ Ｃｏｍｐｅｎｓａｔｉｏｎ Ｐｒｅｄｉｃｔｉｏｎ）のために適用される。一方、現実世界において、動きには様々な種類があり、例えば、ズームイン／ズームアウト、回転、透視運動、および他の不規則な動きがある。ＶＶＣにおいて、４パラメータアフィンモデルおよび６パラメータアフィンモデルを使用して、簡易アフィン変換動き補償予測が適用される。図１６に示すように、ブロックのアフィン動きフィールドは、４パラメータアフィンモデルの場合、２つのＣＰＭＶ（Ｃｏｎｔｒｏｌ Ｐｏｉｎｔ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ）によって表され、６パラメータアフィンモデルの場合、３つのＣＰＭＶによって表される。
ブロックのＭＶＦ（Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｆｉｅｌｄ）は、式（１）における４パラメータアフィンモデル（４パラメータを変数ａ、ｂ、ｅ、ｆとして定義される）および式（２）における６パラメータアフィンモデル（４パラメータを変数ａ、ｂ、ｃ、ｄ、ｅ、ｆとして定義される）をそれぞれ使用して、以下の式で表される。
Figure 2022532334000018
Figure 2022532334000019
ここで、（ｍｖｈ ０，ｍｖｈ ０）は、左上隅の制御点の動きベクトルであり、（ｍｖｈ １，ｍｖｈ １）は、右上隅の制御点の動きベクトルであり、（ｍｖｈ ２，ｍｖｈ ２）は、左下隅の制御点の動きベクトルであり、３つの動きベクトルはすべて、ＣＰＭＶ（Ｃｏｎｔｒｏｌ Ｐｏｉｎｔ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ）と呼ばれ、（ｘ，ｙ）は、現在のブロック内の左上サンプルに対する代表点の座標を表し、（ｍｖｈ（ｘ，ｙ），ｍｖｖ（ｘ，ｙ））は、（ｘ，ｙ）に位置するサンプルに対して導出された動きベクトルである。ＣＰ動きベクトルは、（アフィンＡＭＶＰモードのように）信号通知されてもよいし、または、（アフィンマージモードのように）オンザフライで導出されてもよい。ｗおよびｈは、現在のブロックの幅および高さである。実際のところは、この分割は、丸め動作を有する右シフトによって実装される。ＶＴＭにおいて、代表点がサブブロックの中心位置として定義され、例えば、現在のブロックにおける左上のサンプルに対するサブブロックの左上の角の座標が（ｘｓ，ｙｓ）である場合、代表点の座標は（ｘｓ＋２，ｙｓ＋２）として定義される。各サブブロック（すなわち、ＶＴＭにおいて４×４）に対して、代表点を利用して、サブブロック全体の動きベクトルが導出される。
動き補償予測をさらに簡単にするために、サブブロックベースのアフィン変換予測が適用される。各Ｍ×Ｎ（現在のＶＶＣでは、ＭおよびＮの両方が４に設定される）個のサブブロックの動きベクトルを導出するために、各サブブロックの中心サンプルの動きベクトルが、図１７に示すように、式（１）および（２）に従って算出され、１／１６の小数精度に丸める。そして、１／１６画素の動き補償補間フィルタが適用され、導出された動きベクトルを使用して各サブブロックの予測が生成される。１／１６画素の補間フィルタは、アフィンモードで導入される。
ＭＣＰ後、各サブブロックの高精度動きベクトルが丸められ、通常の動きベクトルと同じ精度で保存される。
１．５．１． アフィン予測の信号通知
並進動きモデルと同様に、アフィン予測によるサイド情報の信号通知のために２つのモードがある。それらは、ＡＦＦＩＮＥ＿ＩＮＴＥＲおよびＡＦＦＩＮＥ＿ＭＥＲＧＥモードである。
１．５．２． ＡＦ＿ＩＮＴＥＲモード
幅と高さの両方が８より大きいＣＵの場合、ＡＦ＿ＩＮＴＥＲモードを適用することができる。ＡＦ＿ＩＮＴＥＲモードが使用されているかどうかを示すために、ビットストリームにおいてＣＵレベルのアフィンフラグが信号通知される。
本モードにおいて、各参照ピクチャリスト（Ｌｉｓｔ０またはＬｉｓｔ１）に対して、アフィンＡＭＶＰ候補リストが、以下の順に、３つのタイプのアフィン動き予測子を用いて構築され、各候補は、現在のブロックの推定されたＣＰＭＶを含む。エンコーダ側で見出された最良のＣＰＭＶ（例えば、図１８におけるｍｖ０、ｍｖ１、ｍｖ２）と推定されたＣＰＭＶとの差が信号通知される。さらに、推定されたＣＰＭＶが導出されたアフィンＡＭＶＰ候補のインデックスが信号通知される。
（１） 継承アフィン動き予測子
チェック順序は、ＨＥＶＣ ＡＭＶＰリスト構築における空間的ＭＶＰのチェック順序に類似している。まず、アフィン符号化され、かつ、現在のブロックと同じ参照ピクチャを有する｛Ａ１，Ａ０｝における第１のブロックから、左側の継承アフィン動き予測子が導出される。第２に、上記継承アフィン動き予測子は、アフィン符号化され、かつ、現在のブロックと同じ参照ピクチャを有する｛Ｂ１，Ｂ０，Ｂ２｝における第１のブロックから導出される。図１９には、５つのブロックＡ１、Ａ０、Ｂ１、Ｂ０、Ｂ２が示されている。
近傍のブロックがアフィンモードで符号化されていることがわかったら、近傍のブロックをカバーする符号化ユニットのＣＰＭＶを使用して、現在のブロックのＣＰＭＶの予測子が導出される。例えば、Ａ１が非アフィンモードで符号化され、Ａ０が４パラメータアフィンモードで符号化される場合、左側の継承アフィンＭＶ予測子は、Ａ０から導出される。この場合、図２１Ｂの左上のＣＰＭＶをＭＶ０ Ｎで表し、右上のＣＰＭＶをＭＶ１ Ｎで表した、Ａ０をカバーしているＣＵのＣＰＭＶを利用して、現在のブロックの左上（座標（ｘ０，ｙ０））、右上（座標（ｘ１，ｙ１））、右下（座標（ｘ２，ｙ２））の位置をＭＶ０ Ｃ、ＭＶ１ Ｃ、ＭＶ２ Ｃで表した、現在のブロックの推定ＣＰＭＶを導出する。
（２） 構築されたアフィン動き予測子
構築されたアフィン動き予測子は、図２０に示すように、近傍のインター符号化ブロックから導出された、同じ参照ピクチャを有するＣＰＭＶ（Ｃｏｎｔｒｏｌ－Ｐｏｉｎｔ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ）からなる。現在のアフィン動きモデルが４パラメータアフィンである場合、ＣＰＭＶの数は２であり、そうでない場合、現在のアフィン動きモデルが６パラメータアフィンである場合、ＣＰＭＶの数は３である。左上のＣＰＭＶ ｍｖ０￣は、インター符号化され、かつ、現在のブロックと同じ参照ピクチャを有するグループ｛Ａ，Ｂ，Ｃ｝における第１のブロックのＭＶによって導出される。右上のＣＰＭＶ ｍｖ１￣は、インター符号化され、かつ、現在のブロックと同じ参照ピクチャを有するグループ｛Ｄ，Ｅ｝における第１のブロックのＭＶによって導出される。左下のＣＰＭＶ ｍｖ２￣は、インター符号化され、かつ、現在のブロックと同じ参照ピクチャを有するグループ｛Ｆ，Ｇ｝における第１のブロックのＭＶによって導出される。
－現在のアフィン動きモデルが４パラメータアフィンである場合、ｍｖ０￣とｍｖ１￣の両方が成立する場合にのみ、構築されたアフィン動き予測子が候補リストに挿入され、すなわち、ｍｖ０￣とｍｖ１￣は、現在のブロックの左上（座標（ｘ０，ｙ０））、右上（座標（ｘ１，ｙ１））の位置に対する推定ＣＰＭＶとして使用される。
－現在のアフィン動きモデルが６パラメータアフィンである場合、ｍｖ０￣、ｍｖ１￣、およびｍｖ２￣がすべて成立している場合にのみ、構築されたアフィン動き予測子が候補リストに挿入され、すなわち、ｍｖ０￣、ｍｖ１￣、およびｍｖ２￣は、現在のブロックの左上（座標（ｘ０，ｙ０））、右上（座標（ｘ１，ｙ１））、および右下（座標（ｘ２，ｙ２））の位置に対する推定ＣＰＭＶとして使用される。
構築されたアフィン動き予測子を候補リストに挿入する場合、プルーニング処理は適用されない。
１）通常のＡＭＶＰ動き予測子
アフィン動き予測子の数が最大に達するまで、以下が適用される。
１）利用可能であれば、すべてのＣＰＭＶをｍｖ２￣に等しく設定することにより、アフィン動き予測子を導出する。
２）利用可能であれば、すべてのＣＰＭＶをｍｖ１￣に等しく設定することにより、アフィン動き予測子を導出する。
３）利用可能であれば、すべてのＣＰＭＶをｍｖ０￣に等しく設定することにより、アフィン動き予測子を導出する。
４）利用可能であれば、すべてのＣＰＭＶをＨＥＶＣ ＴＭＶＰに等しく設定することにより、アフィン動き予測子を導出する。
５）すべてのＣＰＭＶをゼロＭＶに設定することにより、アフィン動き予測子を導出する。
なお、ｍｖｉ￣は、構築されたアフィン動き予測子において導出されたものである。
ＡＦ＿ＩＮＴＥＲモードにおいて、４／６パラメータアフィンモードが使用される場合、２／３の制御点が必要であり、従って、図１８Ａおよび図１８Ｂに示すように、これらの制御点のために２／３のＭＶＤが符号化されることが必要である。ＪＶＥＴ－Ｋ０３３７において、ＭＶを以下のように導出することが提案されており、すなわち、ｍｖｄ０からｍｖｄ１およびｍｖｄ２が予測される。
Figure 2022532334000020
ｍｖｉ￣、ｍｖｄｉ、およびｍｖ１は、図１８Ｂに示すように、それぞれ、左上の画素（ｉ＝０）、右上の画素（ｉ＝１）、または左下の画素（ｉ＝２）の予測された動きベクトル、動きベクトルの差分、動きベクトルである。なお、２つの動きベクトル（例えば、ｍｖＡ（ｘＡ，ｙＡ）およびｍｖＢ（ｘＢ，ｙＢ））の和は、２つの成分を別個に合計したものに等しく、即ち、ｎｅｗＭＶ＝ｍｖＡ＋ｍｖＢであり、ｎｅｗＭＶの２つの成分は、それぞれ、（ｘＡ＋ｘＢ）および（ｙＡ＋ｙＢ）に設定される。
１．５．２．１． ＡＦ＿ＭＥＲＧＥモード
ＡＦ＿ＭＥＲＧＥモードにおいてＣＵを適用する場合、ＣＵは、有効な近傍の再構成ブロックから、アフィンモードで符号化された第１のブロックを得る。そして、候補ブロックの選択順序は、図２１Ａに示すように、左、上、右上、左下、左上になる（順にＡ、Ｂ、Ｃ、Ｄ、Ｅと表記する）。例えば、図２１ＢにおいてＡ０で示されるように、近傍の左下のブロックがアフィンモードで符号化される場合、ブロックＡを含む近傍のＣＵ／ＰＵの左上隅、右上隅、および左下隅のＣＰ（Ｃｏｎｔｒｏｌ Ｐｏｉｎｔ）動きベクトルｍｖ０ Ｎ、ｍｖ１ Ｎ、およびｍｖ２ Ｎがフェッチされる。そして、現在のＣＵ／ＰＵにおける左上隅／右上／左下の動きベクトルｍｖ０ Ｃ、ｍｖ１ Ｃ、ｍｖ２ Ｃ（６パラメータアフィンモデルにのみ使用される）が、ｍｖ０ Ｎ、ｍｖ１ Ｎ、およびｍｖ２ Ｎに基づいて算出される。なお、ＶＴＭ－２．０において、左上隅に位置するサブブロック（例えば、ＶＴＭにおける４×４ブロック）は、ｍｖ０を記憶し、右上隅に位置するサブブロックは、現在のブロックがアフィン符号化されている場合、ｍｖ１を記憶する。現在のブロックが６パラメータアフィンモデルで符号化されている場合、左下隅に位置するサブブロックはｍｖ２を記憶し、そうでない場合（４パラメータアフィンモデルで符号化）、ＬＢはｍｖ２’を記憶する。他のサブブロックは、ＭＣに使用されるＭＶを記憶する。
現在のＣＵ ｍｖ０ Ｃ、ｍｖ１ Ｃ、およびｍｖ２ ＣのＣＰＭＶが導出された後、簡易アフィン動きモデルの式（１）、（２）に従って、現在のＣＵのＭＶＦが生成される。現在のＣＵがＡＦ＿ＭＥＲＧＥモードで符号化されているかどうかを識別するために、アフィンモードで符号化された近傍のブロックが少なくとも１つある場合、ビットストリーム内にてアフィンフラグが信号通知される。
ＪＶＥＴ－Ｌ０１４２およびＪＶＥＴ－Ｌ０６３２において、アフィンマージ候補リストは、以下のステップを使用して構築される。
１）継承されたアフィン候補を挿入する
継承されたアフィン候補は、その有効な近傍のアフィン符号化ブロックのアフィン動きモデルから候補が導出されることを意味する。最大２つの継承されたアフィン候補が、近傍のブロックのアフィン動きモデルから導出され、候補リストに挿入される。左の予測子の場合、スキャン順序は｛Ａ０，Ａ１｝であり、上の予測子の場合、スキャン順序は｛Ｂ０，Ｂ１，Ｂ２｝である。
２）構築されたアフィン候補を挿入する
アフィンマージ候補リストにおける候補の数がＭａｘＮｕｍＡｆｆｉｎｅＣａｎｄ（例えば、５）未満である場合、構築されたアフィン候補が候補リストに挿入される。構築されたアフィン候補は、各制御点の近傍動き情報を組み合わせることで候補が構築されることを意味する。
ａ）まず、制御点に対する動き情報が、図２２に示される指定された空間的近傍と時間近傍から導出される。ＣＰｋ（ｋ＝１，２，３，４）は、ｋ番目の制御点を表す。Ａ０、Ａ１、Ａ２、Ｂ０、Ｂ１、Ｂ２、およびＢ３は、ＣＰｋ（ｋ＝１，２，３）を予測するための空間的位置であり、Ｔは、予測ＣＰ４の時間的位置である。
ＣＰ１、ＣＰ２、ＣＰ３、およびＣＰ４の座標は、それぞれ、（０，０）、（Ｗ，０）、（Ｈ，０）、および（Ｗ，Ｈ）であり、ＷおよびＨは、現在のブロックの幅および高さである。
各制御点の動き情報は、以下の優先順位に従って取得される。
－ＣＰ１の場合、チェックの優先順位はＢ２－＞Ｂ３－＞Ａ２である。利用可能であれば、Ｂ２が使用される。一方、Ｂ２が利用可能であれば、Ｂ３が使用される。Ｂ２とＢ３の両方が利用不可能な場合、Ａ２が使用される。３つの候補のすべてが利用不可能な場合、ＣＰ１の動き情報を取得することができない。
－ＣＰ２の場合、チェックの優先順位はＢ１－＞Ｂ０である。
－ＣＰ３の場合、チェックの優先順位はＡ１－＞Ａ０である。
－ＣＰ４の場合、Ｔが使用される。
ｂ）次に、制御点の組み合わせを使用して、アフィンマージ候補を構築する。
Ｉ．６パラメータアフィン候補を構築するためには、３つの制御点の動き情報が必要である。３つの制御点は、以下の４つの組み合わせ（｛ＣＰ１，ＣＰ２，ＣＰ４｝、｛ＣＰ１，ＣＰ２，ＣＰ３｝、｛ＣＰ２，ＣＰ３，ＣＰ４｝、｛ＣＰ１，ＣＰ３，ＣＰ４｝）の１つから選択できる。組み合わせ｛ＣＰ１，ＣＰ２，ＣＰ３｝、｛ＣＰ２，ＣＰ３，ＣＰ４｝、｛ＣＰ２，ＣＰ３，ＣＰ４｝、｛ＣＰ１，ＣＰ３，ＣＰ４｝は、左上、右上、および左下の制御点で表現される６パラメータ動きモデルに変換される。
ＩＩ．４パラメータアフィン候補を構築するためには、２つの制御点の動き情報が必要である。２つの制御点は、２つの組み合わせ（｛ＣＰ１，ＣＰ２｝、｛ＣＰ１，ＣＰ３｝）のうちの１つから選択できる。２つの組み合わせは、左上および右上の制御点で表現される４パラメータ動きモデルに変換される。
ＩＩＩ．構築されたアフィン候補の組み合わせは、以下の順にて候補リストに挿入される。
｛ＣＰ１，ＣＰ２，ＣＰ３｝、｛ＣＰ１，ＣＰ２，ＣＰ４｝、｛ＣＰ１，ＣＰ３，ＣＰ４｝、｛ＣＰ２，ＣＰ３，ＣＰ４｝、｛ＣＰ１，ＣＰ２｝、｛ＣＰ１，ＣＰ３｝
ｉ．各組み合わせについて、各ＣＰに対するリストＸの参照インデックスがチェックされ、それらがすべて同じである場合、この組み合わせはリストＸに対して有効なＣＰＭＶを有する。組み合わせがリスト０およびリスト１の両方に対して有効なＣＰＭＶを有していない場合、この組み合わせは無効としてマークされる。そうでない場合、それは有効であり、ＣＰＭＶはサブブロックマージリストに入れられる。
３）動きベクトルがゼロの場合のパディング
アフィンマージ候補リストにおける候補の数が５未満である場合、リストが一杯になるまで、ゼロ参照インデックスを有するゼロ動きベクトルが候補リストに挿入される。
具体的には、サブブロックマージ候補リストについて、ＭＶを有する４パラメータマージ候補が（０，０）に設定され、予測方向がリスト０からの単一予測（Ｐスライスの場合）、および、双方向予測（Ｂスライスの場合）に設定される。
２． 既存の実装形態の欠点
ＶＶＣに適用される場合、ＡＲＣには以下の問題がある。
１．ＡＲＣに関する情報をどのように信号通知するかは、まだ不明である。
２．参照ピクチャ、並置されたピクチャ、および現在のピクチャが同じ解像度を有していない場合、アフィン／ＴＭＶＰまたはＡＴＭＶＰをどのように適用するかは、依然として不明である。
３．ＡＲＣのためのダウンサンプリングまたはアップサンプリングフィルタの設計は、より優れた設計とすることができる。
３． 適応解像度変換方法の例
以下の詳細な発明は、一般的な概念を説明するための例であると考えられるべきである。これらの発明は狭い意味で解釈されるべきではない。さらに、これらの発明は、任意の方法で組み合わせることができる。
以下の説明において、ＳａｔＳｈｉｆｔ（ｘ，ｎ）は、以下のように定義される。
Figure 2022532334000021
Ｓｈｉｆｔ（ｘ，ｎ）は、Ｓｈｉｆｔ（ｘ，ｎ）＝（ｘ＋ｏｆｆｓｅｔ０）＞＞ｎとして定義される。
一例において、ｏｆｆｓｅｔ０および／またはｏｆｆｓｅｔ１は、（１＜＜ｎ）＞＞１または（１＜＜（ｎ－１））に設定される。別の例において、ｏｆｆｓｅｔ０および／またはｏｆｆｓｅｔ１は、０に設定される。
別の例において、ｏｆｆｓｅｔ０＝ｏｆｆｓｅｔ１＝（（１＜＜ｎ）＞＞１）－１または（（１＜＜（ｎ－１）））－１である。
Ｃｌｉｐ３（ｍｉｎ，ｍａｘ，ｘ）は、以下のように定義される。
Figure 2022532334000022
ｆｌｏｏｒ（ｘ）は、ｘ以下の最大整数として定義される。
Ｃｅｉｌ（ｘ）は、ｘ以上の最小の整数。
Ｌｏｇ２（ｘ）は、ｘの底を２とする対数として定義される。
ＡＲＣのための信号通知
１．ＡＲＣに関するピクチャ寸法情報（幅および／または高さ）は、ＤＰＳ、ＶＰＳ、ＳＰＳ、ＰＰＳ、ＡＰＳ、ピクチャヘッダ、スライスヘッダ、タイルグループヘッダ以外の映像ユニットにて信号通知されてもよいと提案する。
ａ．一例において、ＡＲＣに関するピクチャ寸法情報は、ＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージにて信号通知されてよい。
ｂ．一例において、ＡＲＣに関するピクチャ寸法情報は、ＡＲＣのための個々の映像ユニットにおいて信号通知されてよい。例えば、映像ユニットは、ＲＰＳ（Ｒｅｓｏｌｕｔｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＣＰＳ（Ｃｏｎｖｅｒｓｉｏｎ Ｐａｒａｍｔｅｒ Ｓｅｔ）、または他の名称として命名されてよい。
ｉ．一例において、ＲＰＳまたはＣＰＳと命名されたような、ＡＲＣのための個々の映像ユニットにおいて、幅および高さの２つ以上の組み合わせが信号通知されてよい。
２．なお、ピクチャの寸法（幅または高さ）は、０次の指数ゴロム符号ではないように信号通知されてよいと提案する。
ａ．一例において、固定長符号またはユーナリー符号で符号化されてよい。
ｂ．一例において、Ｋ次（Ｋ＞０）の指数ゴロム符号で符号化されてもよい。
ｃ．寸法は、ＤＰＳ、ＶＰＳ、ＳＰＳ、ＰＰＳ、ＡＰＳ、ピクチャヘッダ、スライスヘッダ、タイルグループヘッダなどの映像ユニットにおいて、または、ＲＰＳもしくはＣＰＳと命名されたＡＲＣのための個々の映像ユニットにおいて信号通知されてよい。
３．複数の解像度を信号通知する代わりに、解像度比を信号通知することを提案する。
ａ．一例において、１つの基本解像度の指示を信号通知してもよい。また、許容される比率の組み合わせ（例えば、水平比率、垂直比率）の指示をさらに信号通知してもよい。
ｂ．一例において、１つのピクチャの実際の解像度を示すために、許容される比の組み合わせの指示のインデックスがＰＰＳにて信号通知されてよい。
４．単一の映像ユニット、例えばＤＰＳ、ＶＰＳ、ＳＰＳ、ＰＰＳ、ＡＰＳ、ピクチャヘッダ、スライスヘッダ、タイルグループヘッダなどにおいて、または、ＲＰＳもしくはＣＰＳと命名されたようなＡＲＣのための個々の映像ユニットにおいて、ピクチャの幅と高さの２つ以上の組み合わせが信号通知される場合、第１の組み合わせにおける幅と高さが共に第２の組み合わせにおける幅と高さであることが許可されないようにすることを提案する。
５．信号通知される寸法（幅Ｗおよび高さＨ）は制約内になければならないことを提案する。
ａ．例えば、Ｗは、ＴＷ＿ｍｉｎ＜＝Ｗ＜＝ＴＷ＿ｍａｘを満たすべきである。
ｂ．例えば、Ｈは、ＴＨ＿ｍｉｎ＜＝Ｈ＜＝ＴＨ＿ｍａｘを満たすべきである。
ｃ．一例において、Ｗ－ＴＷ＿ｍｉｎ－Ｂが信号通知されてもよく、Ｂは、０などの固定値である。
ｄ．一例において、Ｈ－ＴＨ＿ｍｉｎ－Ｂが信号通知されてもよく、Ｂは、０などの固定値である。
ｅ．一例において、ＴＷ＿ｍａｘ－Ｗ－Ｂが信号通知されてもよく、Ｂは、０などの固定値である。
ｆ．一例において、ＴＨ＿ｍａｘ－Ｈ－Ｂが信号通知されてもよく、Ｂは、０などの固定値である。
ｇ．一例において、ＴＷ＿ｍｉｎおよび／またはＴＨ＿ｍｉｎが信号通知されてもよい。
ｈ．一例において、ＴＷ＿ｍａｘおよび／またはＴＨ＿ｍａｘが信号通知されてもよい。
６．信号通知される寸法（幅Ｗおよび高さＨ）は、Ｗ＝ｗ＊Ｘ、およびＨ＝ｈ＊Ｙの形式でなければならず、ＸおよびＹは、例えば、Ｘ＝Ｙ＝４などの、予め定義された整数であることを提案する。
ａ．一例において、ｗおよびｈが信号通知される。ＷおよびＨは、ｗおよびｈから導出される。
７．ピクチャ寸法情報（幅および／または高さ）は、予測方式で符号化されてもよいことを提案する。
ａ．一例において、第１の幅（Ｗ１）と第２の幅（Ｗ２）との差、すなわち、Ｗ２－Ｗ１、が信号通知されてよい。
ｉ．代替的に、Ｗ２－Ｗ１－Ｂが信号通知されてもよく、Ｂは、１などの固定値である。
ｉｉ．一例において、Ｗ２はＷ１よりも大きくなるべきである。
ｉｉｉ．一例において、差は、ユーナリー符号、またはトランケイテッドユーナリー符号、または固定長符号、または固定長符号で符号化されてもよい。
ｂ．一例において、第１の高さ（Ｈ１）と第２の高さ（Ｈ２）との差、すなわち、Ｈ２－Ｈ１が信号通知されてもよい。
ｉ．代替的に、Ｈ２－Ｈ１－Ｂが信号通知されてもよく、Ｂは、１などの固定値である。
ｉｉ．一例において、Ｈ２はＨ１よりも大きくなければならない。
ｉｉｉ．一例において、差は、ユーナリー符号、またはトランケイテッドユーナリー符号、または固定長符号、または固定長符号化されてもよい。
ｃ．一例において、第１の幅（Ｗ１）と第２の幅（Ｗ２）との間の比、すなわち、Ｗ２／Ｗ１が信号通知されてもよい。例えば、Ｗ２＝Ｆ＊Ｗ１である場合、Ｆが信号通知される。別の例において、Ｗ２＝Ｓｈｉｆｔ（Ｆ＊Ｗ１，Ｐ）である場合、Ｆが信号通知され、Ｐは、精度を表す数であり、例えば、Ｐ＝１０である。
ｉ．代替的に、Ｆは、（Ｗ２＊Ｐ＋Ｗ１／２）／Ｗ１に等しくてよく、Ｐは、精度を表す数であり、例えば、Ｐ＝１０である。
ｉｉ．代替的に、Ｆ－Ｂが信号通知されてもよく、Ｂは、１などの固定値である。
ｉｉｉ．一例において、Ｗ２はＷ１よりも大きくなければならない。
ｉｖ．一例において、Ｆは、ユーナリー符号、またはトランケイテッドユーナリー符号、または固定長符号で符号化されてもよく、または固定長符号化されてもよい。
ｄ．一例において、第１の高さ（Ｈ１）と第２の高さ（Ｈ２）との間の比、すなわちＨ２／Ｈ１が信号通知されてもよい。例えば、Ｈ２＝Ｆ＊Ｈ１である場合、Ｆが信号通知される。別の例において、Ｈ２＝Ｓｈｉｆｔ（Ｆ＊Ｈ１，Ｐ）である場合、Ｆが信号通知され、Ｐは、精度を表す数であり、例えば、Ｐ＝１０である。
ｉ．代替的に、Ｆは、（Ｈ２＊Ｐ＋Ｈ１／２）／Ｈ１に等しくてもよく、Ｐは、精度を表す数であり、例えば、Ｐ＝１０である。
ｉｉ．代替的に、Ｆ－Ｂが信号通知されてもよく、Ｂは、１などの固定値である。
ｉｉｉ．一例において、Ｈ２はＨ１よりも大きくなければならない。
ｉｖ．一例において、差は、ユーナリー符号、またはトランケイテッドユーナリー符号、または固定長符号で符号化されてもよく、または固定長符号化されてもよい。
ｅ．一例において、Ｗ２／Ｗ１はＨ２／Ｈ１に等しくなければならず、Ｗ２／Ｗ１またはＨ２／Ｈ１のみが信号通知されるべきである。
８．異なる解像度／解像度比を信号通知する場合、以下の追加の構文要素がさらに信号通知されてよいことを提案する。
ａ．構文要素は、ＣＴＵのサイズの指示であってもよい。
ｂ．構文要素は、最小符号化ユニットのサイズの指示であってもよい。
ｃ．構文要素は、最大および／または最小変換ブロックサイズの指示であってもよい。
ｄ．構文要素は、４分木および／または２分木／３分木の最大深さの指示であってもよい。
ｅ．一例において、追加の構文要素は、特定のピクチャ解像度にバインドされてもよい。
参照ピクチャリスト
９．適合ビットストリームは、現在のピクチャとは異なる解像度の参照ピクチャが、同じ解像度の参照ピクチャに比べてより大きい参照インデックスを割り当てられることを満足するものとする。
ａ．代替的に、１つのピクチャ／スライス／タイル／タイルグループを復号化する前に、参照ピクチャリストの場合、現在のピクチャとは異なる解像度の参照ピクチャが、同じ解像度の参照ピクチャに比べてより大きい参照インデックスを割り当てられるように、参照ピクチャリストが再配列されてもよい。
ＡＲＣによる時間的ブロック（例えば、ＴＭＶＰおよびＡＴＭＶＰ）からの動き予測
１０．２つのブロックＡとＢがあるとする。ブロックＡの参照ピクチャが現在のブロックと同じ解像度の参照ピクチャであり、ブロックＢの参照ピクチャが現在のブロックと異なる解像度の参照ピクチャである場合、ブロックＢの動き情報を使用してブロックＡを予測することを禁止することを提案する。
ａ．ブロックＡの参照ピクチャが現在のブロックと異なる解像度の参照ピクチャであり、ブロックＢの参照ピクチャが現在のブロックと同じ解像度の参照ピクチャである場合、ブロックＢの動き情報を使用してブロックＡを予測することを禁止することを提案する。
１１．現在のピクチャと異なる解像度を有する参照ピクチャにおけるブロックからの予測を許可しないことを提案する。
１２．参照ピクチャは、その幅が現在のピクチャの幅と異なるか、またはその高さが現在のピクチャの高さと異なる場合、並置された参照ピクチャでありえないようにすることを提案する。
ｂ．代替的に、参照ピクチャは、その幅が現在のピクチャの幅と異なり、かつ、その高さが現在のピクチャの高さと異なる場合、並置された参照ピクチャでありえない。
１３．ＴＭＶＰ／ＡＴＭＶＰにおける並置されたブロック、またはＡＴＭＶＰにおける並置されたサブブロックをどのように見出すかは、並置された参照ピクチャと現在のピクチャとが同じピクチャ幅および高さを有するかどうかに依存してよい。
ａ．一例において、現在のピクチャの寸法がＷ０＊Ｈ０であり、並置された参照ピクチャの寸法がＷ１＊Ｈ１であるとすると、並置されたブロックの位置および／または寸法は、Ｗ０、Ｈ０、Ｗ１、およびＨ１に依存してよい。
ｉ．一例において、現在のブロックまたはサブブロックの左上座標が（ｘ，ｙ）であるとすると、並置されたブロックまたはサブブロックは、並置された参照ピクチャにおける位置（ｘ’，ｙ’）をカバーするブロックとして導出されてもよく、（ｘ’，ｙ’）は、ｘ’＝Ｒｘ＊（ｘ＋ｏｆｆｓｅｔＸ）＋ｏｆｆｓｅｔＸ’およびｙ’＝Ｒｙ＊（ｙ＋ｏｆｆｓｅｔＹ）＋ｏｆｆｓｅｔＹ’として計算してもよい。ｏｆｆｓｅｔＸ’とｏｆｆｓｅｔＹ’は、０のような値である。
１）一例において、現在のブロックまたは現在のサブブロックの寸法がｗ＊ｈであるとすると、（ｏｆｆｓｅｔＸ，ｏｆｆｓｅｔＹ）は（ｘ＋ｗ，ｙ＋ｈ）に等しくてもよい。
ａ）代替例において、（ｏｆｆｓｅｔＸ，ｏｆｆｓｅｔＹ）は、（ｘ＋ｗ／２，ｙ＋ｈ／２）に等しくてもよい。
ｂ）代替例において、（ｏｆｆｓｅｔＸ，ｏｆｆｓｅｔＹ）は、（ｘ＋ｗ／２－１，ｙ＋ｈ／２－１）に等しくてもよい。
ｃ）代替例において、（ｏｆｆｓｅｔＸ，ｏｆｆｓｅｔＹ）は、（０，０）に等しくてもよい。
２）一例において、Ｒｘ＝Ｗ１／Ｗ０である。
３）一例において、Ｒｙ＝Ｈ１／Ｈ０である。
４）１つの代替例において、ｘ’＝Ｓｈｉｆｔ（Ｒｘ＊（ｘ＋ｏｆｆｓｅｔＸ），Ｐ）であり、Ｐは、精度を表す値、例えば１０である。
ａ）Ｒｘは、Ｒｘ＝（Ｗ１＊Ｐ＋ｏｆｆｓｅｔ）／Ｗ０として導出されてもよく、ｏｆｆｓｅｔは、０またはＷ０／２などの整数である。
５）１つの代替例において、ｙ’＝Ｓｈｉｆｔ（Ｒｙ＊（ｙ＋ｏｆｆｓｅｔＹ），Ｐ）であり、Ｐは、精度を表す値、例えば１０である。
ａ）Ｒｙは、Ｒｙ＝（Ｈ１＊Ｐ＋ｏｆｆｓｅｔ）／Ｈ０として導出されてもよく、ｏｆｆｓｅｔは、０またはＨ０／２などの整数である。
１４．現在のピクチャとは異なる解像度の参照ピクチャにおける参照サンプルをアップサンプリングまたはダウンサンプリングすることに加え、動き情報／符号情報をさらにアップサンプリングまたはダウンサンプリングすること、または、アップサンプリングまたはダウンサンプリングされた情報を、他のフレームにおける後続のブロックを符号化するために利用できるようにすることを提案する。
１５．並置された参照ピクチャの幅または高さが現在のピクチャの幅または高さと異なる場合、並置されたＭＶを記憶するバッファをアップサンプリングしてもよいし、ダウンサンプリングしてもよい。
ｂ．一例において、アップサンプリングされたまたはダウンサンプリングされたＭＶバッファ、および、アップサンプリングまたはダウンサンプリング前のＭＶバッファは、両方とも記憶されてもよい。
ｉ．代替的に、アップサンプリングまたはダウンサンプリング前のＭＶバッファを除外してもよい。
ｃ．一例において、アップサンプリングされたＭＶバッファにおける複数のＭＶは、アップサンプリングの前のＭＶバッファにおける１つのＭＶからコピーされる。
ｉ．例えば、アップサンプリングされたＭＶバッファにおける複数のＭＶは、アップサンプリング前のＭＶバッファにおいてＭＶが存在する領域に対応する領域にあってもよい。
ｄ．一例において、ダウンサンプリングされたＭＶバッファにおける１つのＭＶは、ダウンサンプリング前のＭＶバッファにおける複数のＭＶのうちの１つのＭＶから取り出されてもよい。
ｉ．例えば、ダウンサンプリングされたＭＶバッファにおける１つのＭＶは、ダウンサンプリング前のＭＶバッファにおいて複数のＭＶが存在する領域に対応する領域にあってもよい。
１６．ＡＴＭＶＰにおける時間的ＭＶの導出は、現在のピクチャの寸法Ｗ０＊Ｈ０および並置されたピクチャの寸法Ｗ１＊Ｈ１に依存してよいことを提案する。
ｃ．例えば、並置されたピクチャの寸法と現在のピクチャの寸法とが同じでない場合、ｔＭＶとして表される時間的ＭＶがｔＭＶ’に変換されてよい。
ｉ．例えば、ｔＭＶ＝（ｔＭＶｘ，ｔＭＶｙ）、ｔＭＶ’＝（ｔＭＶｘ’，ｔＭＶｙ’）とすると、ｔＭＶｘ’は、ｔＭＶｘ’＝Ｒｘ＊ｔＭＶｘ＋ｏｆｆｓｅｔｘとして計算されてよく、ｔＭＶｙ’は、ｔＭＶｙ’＝Ｒｙ＊ｔＭＶｙ＋ｏｆｆｓｅｔｙとして算出されてよい。ｏｆｆｓｅｔｘおよびｏｆｆｓｅｔｙは、０などの値である。
１）一例において、Ｒｘ＝Ｗ１／Ｗ０である。
２）一例において、Ｒｙ＝Ｈ１／Ｈ０である。
３）１つの代替例において、ｔＭＶｘ’＝Ｓｈｉｆｔ（Ｒｘ＊（ｔＭＶｘ＋ｏｆｆｓｅｔＸ），Ｐ）またはＳａｔＳｈｉｆｔ（Ｒｘ＊（ｔＭＶｘ＋ｏｆｆｓｅｔＸ），Ｐ）であり、Ｐは、精度を表す値であり、例えば１０である。
ａ）Ｒｘは、Ｒｘ＝（Ｗ１＊Ｐ＋ｏｆｆｓｅｔ）／Ｗ０として導出されてもよく、ｏｆｆｓｅｔは、０またはＷ０／２などの整数である。
４）１つの代替例において、ｔＭＶｙ’＝Ｓｈｉｆｔ（Ｒｙ＊（ｔＭＶｙ＋ｏｆｆｓｅｔＹ），Ｐ）またはＳａｔＳｈｉｆｔ（Ｒｙ＊（ｔＭＶｙ＋ｏｆｆｓｅｔＹ），Ｐ）であり、Ｐは、精度を表す値であり、例えば１０である。
ａ）Ｒｙは、Ｒｙ＝（Ｈ１＊Ｐ＋ｏｆｆｓｅｔ）／Ｈ０として導出されてもよく、ｏｆｆｓｅｔは、０またはＨ０／２などの整数である。
１７．ＴＭＶＰ／ＡＴＭＶＰにおける現在のブロックまたは現在のサブブロックのＭＶＰ（ＭＶ Ｐｒｅｄｉｃｔｉｏｎ）の導出は、現在のピクチャの寸法、および／または、ＭＶＰが参照する参照ピクチャの寸法、および／または、並置されたピクチャの寸法、および／または、並置されたＭＶが参照する並置されたピクチャの参照ピクチャの寸法に依存してよいことを提案する。並置されたＭＶは、並置されたブロックの中にあるＭＶを示す。図２３は、現在のピクチャ（ＣｕｒＰｉｃ）、ＭＶＰが参照する参照ピクチャ（ＲｅｆＰｉｃ）、並置されたピクチャ（ＣｏｌＰｉｃ）、および並置されたＭＶが参照する並置されたピクチャの参照ピクチャ（ＲｅｆＣｏｌＰｉｃ）が、それぞれ時刻（またはＰＯＣ）Ｔ０、Ｔ１、Ｔ２、Ｔ３にある場合の例を示している。そして、それらの寸法はそれぞれ、Ｗ０＊Ｈ０、Ｗ１＊Ｈ１、Ｗ２＊Ｈ２、およびＷ３＊Ｈ３である。現在のブロック／サブブロックのＭＶＰは、ＭｖＣｕｒ＝（ＭｖＣｕｒＸ，ＭｖＣｕｒＹ）として表され、並置されたＭＶは、ＭｖＣｏｌ（ＭｖＣｏｌＸ，ＭｖＣｏｌＹ）として表される。
ｄ．ＭｖＣｕｒＸは、ＭｖＣｕｒＸ＝Ｒｘ＊ＭｖＣｏｌＸ＋ｏｆｆｓｅｔｘとして計算されてよく、ＭｖＣｕｒＹは、ＭｖＣｕｒＹ＝Ｒｙ＊ＭｖＣｏｌＹ＋ｏｆｆｓｅｔｙとして計算されてもよい。ｏｆｆｓｅｔｘおよびｏｆｆｓｅｔｙは、０などの値である。
ｅ．一例において、Ｒｘ＝Ｗ０／Ｗ２である。
ｆ．一例において、Ｒｙ＝Ｈ０／Ｈ２である。
ｇ．ある代替例では、ＭｖＣｕｒＸ＝Ｓｈｉｆｔ（Ｒｘ＊（ＭｖＣｏｌＸ＋ｏｆｆｓｅｔＸ），Ｐ）またはＭｖＣｕｒＸ＝ＳａｔＳｈｉｆｔ（Ｒｘ＊（ＭｖＣｏｌＸ＋ｏｆｆｓｅｔＸ），Ｐ）となり、Ｐは精度を表す値であり、例えば１０である。
ｉ．Ｒｘは、Ｒｘ＝（Ｗ０＊Ｐ＋ｏｆｆｓｅｔ）／Ｗ２として導出されてよく、ｏｆｆｓｅｔは、０またはＷ２／２などの整数である。
ｈ．１つの代替例では、ＭｖＣｕｒＹ＝Ｓｈｉｆｔ（Ｒｙ＊（ＭｖＣｏｌＹ＋ｏｆｆｓｅｔＹ），Ｐ）またはＭｖＣｕｒＹ＝ＳａｔＳｈｉｆｔ（Ｒｙ＊（ＭｖＣｏｌＹ＋ｏｆｆｓｅｔＹ），Ｐ）であり、Ｐは精度を表す値であり、例えば１０である。
ｉ．Ｒｙは、Ｒｙ＝（Ｈ０＊Ｐ＋ｏｆｆｓｅｔ）／Ｈ２として導出されてよく、ｏｆｆｓｅｔは、０またはＨ２／２などの整数である。
ｉ．一例において、（Ｗ３，Ｈ３）は、（Ｗ２，Ｈ２）に等しくなければならない。そうでない場合、ＭｖＣｏｌは利用不可能であると見なされてよい。
ｊ．一例において、（Ｗ０，Ｈ０）は、（Ｗ１，Ｈ１）に等しくなければならず、そうでなければ、ＭＶＣｕｒは、利用可能でないと見なされてよい。
ＡＲＣにおける補間とスケーリング
１８．ＡＲＣのための１または複数のダウンサンプリングまたはアップサンプリングフィルタリング方法は、ＤＰＳ、ＶＰＳ、ＳＰＳ、ＰＰＳ、ＡＰＳ、ピクチャヘッダ、スライスヘッダ、タイルグループヘッダなどの映像ユニットにて、ＲＰＳもしくはＣＰＳと命名されたＡＲＣのための個々の映像ユニットにて、信号通知されてよいことを提案する。
１９．ＪＶＥＴ－Ｎ０２７９のアプローチにおいて、ｈｏｒｉ＿ｓｃａｌｅ＿ｆｐおよび／またはｖｅｒｔ＿ｓｃａｌｅ＿ｆｐは、ＤＰＳ、ＶＰＳ、ＳＰＳ、ＰＰＳ、ＡＰＳ、ピクチャヘッダ、スライスヘッダ、タイルグループヘッダなどの映像ユニットにて、または、ＲＰＳもしくはＣＰＳと命名されたＡＲＣのための個々の映像ユニットにて信号通知されてよい。
２０．ｈｏｒｉ＿ｓｃａｌｅ＿ｆｐおよび／またはｖｅｒｔ＿ｓｃａｌｅ＿ｆｐの導出、またはｂｕｌｌｅｔ８＿ｂｕｌｔ１１におけるＲｘおよび／またはＲｙの導出など、ＲＡＣにおけるスケーリング手法における任意の分割動作が、１または複数のテーブルが用いられてよい、１または複数の動作に置き換えまたは近似してもよいことを提案する。例えば、Ｐ１９０５２８９３０１に開示された方法は、分割動作を置き換えるかまたは近似するために使用されてもよい。
上述した例は、以下に説明する方法のコンテキスト、例えば、方法２４００、２４１０、２４２０、２４３０、２４４０、２４５０、２４６０、２４７０、２４８０、および２４９０に含まれてもよく、これらの方法は、映像デコーダまたは映像エンコーダにおいて実装されてよい。
図２４Ａは、例示的な映像処理のための方法のフローチャートを示す。方法２４００は、ステップ２４０２において、１または複数の映像ユニットを有する１または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を実行することを含む。いくつかの実施形態において、ビットストリーム表現は、フォーマット規則に準拠し、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理に関する情報を有し、フォーマット規則は、ＡＲＣ処理の映像セグメントへの適用を規定し、映像セグメントの１または複数の映像ユニットが異なる解像度で符号化されることの指示が、ヘッダ構文構造、ＤＰＳ（Ｄｅｃｏｄｅｒ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＶＰＳ（Ｖｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、およびＡＰＳ（Ａｄａｐｔｉｖｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）とは異なる構文構造のビットストリーム表現に含まれる。
いくつかの実施形態において、ビットストリーム表現は、フォーマット規則に準拠し、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理に関する情報を有し、Ｋ次の指数ゴロム符号で符号化されている１または複数の映像ユニットの寸法が、ビットストリーム表現で信号通知され、Ｋは正の整数であり、フォーマット規則は、ＡＲＣ処理の映像セグメントへの適用を規定し、映像セグメントの１または複数の映像ユニットが異なる解像度で符号化されているとことの指示が、構文構造のビットストリーム表現に含まれる。
いくつかの実施形態において、ビットストリーム表現は、フォーマット規則に準拠し、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理に関する情報を有し、高さ（Ｈ）と幅（Ｗ）がビットストリーム表現で信号通知され、ＨとＷは、正の整数であり、制約されており、フォーマット規則は、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理の映像セグメントへの適用を規定し、映像セグメントの１または複数の映像ユニットが異なる解像度で符号化されているとこと指示が、構文構造のビットストリーム表現に含まれる。
図２４Ｂは、例示的な映像処理のための方法のフローチャートを示す。方法２４１０は、ステップ２４１２において、（ａ）映像の現在の映像ブロックの第１の時間的に近傍のブロックの第１の参照ピクチャの解像度が、現在のピクチャの解像度と同一であること、および（ｂ）現在の映像ブロックの第２の時間的に近傍のブロックの第２の参照ピクチャの解像度が、現在のピクチャの解像度と異なることを判定することを含む。
方法２４１０は、ステップ２４１４において、第１の時間的に近傍のブロックの予測における第２の時間的に近傍のブロックの動き情報の使用を、判定に起因して、無効化することにより、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することを含む。
図２４Ｃは、例示的な映像処理方法のフローチャートを示す。方法２４２０は、ステップ２４２２において、（ａ）映像の現在の映像ブロックの第１の時間的に近傍のブロックの第１の参照ピクチャの解像度が、現在のピクチャの解像度と異なること、および（ｂ）現在の映像ブロックの第２の時間的に近傍のブロックの第２の参照ピクチャの解像度が、現在のピクチャの解像度と同一であることを判定することを含む。
方法２４２０は、ステップ２４２４において、第１の時間的に近傍のブロックの予測における第２の時間的に近傍のブロックの動き情報の使用を、判定に起因して、無効化することにより、映像の現在の映像ブロックとビットストリーム表現との間の変換を実行することを含む。
図２４Ｄは、例示的な映像処理のための方法のフローチャートを示す。方法２４３０は、ステップ２４３２において、映像の現在の映像ブロックのために、現在の映像ブロックに関連付けられた映像ブロックを有する参照ピクチャの解像度が、現在の映像ブロックを有する現在のピクチャの解像度とは異なることを判定することを含む。
方法２４３０は、ステップ２４３４において、参照ピクチャの映像ブロックに基づいた予測処理を、判定に起因して、無効化することにより、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することを含む。
図２４Ｅは、例示的な映像処理のための方法のフローチャートを示す。方法２４４０は、ステップ２４４２において、ピクチャの少なくとも１つの寸法に基づいて、ピクチャが現在のピクチャの現在の映像ブロックのための並置された参照ピクチャとして使用することが許可されるかどうかに関する決定を実行することを含む。
方法２４４０は、ステップ２４４４において、決定に基づいて、映像の現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することを含む。
図２４Ｆは、例示的な映像処理のための方法のフローチャートを示す。方法２４５０は、ステップ２４５２において、映像の現在の映像ブロックの予測のために、並置されたブロックを有する並置された参照ピクチャの寸法が、現在の映像ブロックを有する現在のピクチャの寸法と同一であるとことの判定に基づいて、並置されたブロックを識別する。
方法２４５０は、ステップ２４５４において、並置されたブロックを使用して、映像の現在の映像ブロックとビットストリーム表現との間の変換を実行することを含む。
図２４Ｇは、例示的な映像処理のための方法のフローチャートを示す。方法２４６０は、ステップ２４６２において、映像の現在の映像ブロックのために、現在の映像ブロックに関連付けられた参照ピクチャが、現在の映像ブロックを有する現在のピクチャの解像度とは異なる解像度を有することを判定する。
方法２４６０は、ステップ２４６４において、映像の現在の映像ブロックとビットストリーム表現との間の変換の一部として、参照ピクチャの１または複数の参照サンプル、および現在の映像ブロックに対する動き情報または現在の映像ブロックに対する符号化情報に対してアップサンプリング動作またはダウンサンプリング動作を実行することを含む。
図２４Ｈは、例示的な映像処理のための方法のフローチャートを示す。方法２４７０は、ステップ２４７２において、映像の現在の映像ブロックと映像のビットストリーム表現との間の変換のために、現在の映像ブロックを有する現在のピクチャの高さまたは幅が、現在の映像ブロックに関連付けられた並置された参照ピクチャの高さまたは幅と異なることを決定することを含む。
方法２４７０は、ステップ２４７４において、決定に基づいて、並置された参照ピクチャの１または複数の動きベクトルを記憶するバッファに対してアップサンプリング動作またはダウンサンプリング動作を実行することを含む。
図２４Ｉは、例示的な映像処理のための方法のフローチャートを示す。方法２４８０は、ステップ２４８２において、映像の現在の映像ブロックを含む現在のピクチャの寸法と、現在の映像ブロックに関連付けられた、並置されたピクチャの寸法に基づいて、現在の映像ブロックに適用されたＡＴＭＶＰ（Ａｌｔｅｒｎａｔｉｖｅ Ｔｅｍｐｏｒａｌ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ）処理に関する情報を導出する。
方法２４８０は、ステップ２４８４において、時間的動きベクトルを使用して、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することを含む。
図２４Ｊは、例示的な映像処理のための方法のフローチャートを示す。方法２４９０は、ステップ２４９２において、映像の現在の映像ブロックに対してＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理の適用のために、映像のビットストリーム表現を構成することを含む。いくつかの実施形態において、ＡＲＣ処理に関する情報がビットストリーム表現で信号通知され、現在の映像ブロックを有する現在のピクチャは第１の解像度を有し、ＡＲＣ処理は、現在の映像ブロックの一部を第１の解像度とは異なる第２の解像度で再サンプリングすることを有する。
方法２４９０は、ステップ２４９４において、構成することに基づいて、現在の映像ブロックと現在の映像ブロックのビットストリーム表現との間で変換を実行することを含む。
４． 開示される技術の例示的な実装形態
図２５は、映像処理装置２５００のブロック図である。装置２５００は、本明細書に記載の方法の１または複数を実装するために使用してもよい。装置２５００は、スマートフォン、タブレット、コンピュータ、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）受信機等に実施されてもよい。装置２５００は、１または複数のプロセッサ２５０２と、１または複数のメモリ２５０４と、映像処理ハードウェア２５０６と、を含んでもよい。１または複数のプロセッサ２５０２は、本明細書に記載される１または複数の方法（方法２４００、２４１０、２４２０、および２４３０を含むが、これに限定されない）を実装するように構成されてもよい。メモリ２５０４は、本明細書で説明される方法および技術を実装するために使用されるデータおよびコードを記憶するために使用してもよい。映像処理ハードウェア２５０６は、本明細書に記載される技術をハードウェア回路にて実装するために使用してもよい。
いくつかの実施形態において、映像符号化法は、図２５を参照して説明したように、ハードウェアプラットフォームに実装される装置を使用して実施してもよい。
開示される技術のいくつかの実施形態は、映像処理ツールまたはモードを有効化するように決定または判定することを含む。一例において、映像処理ツールまたはモードが有効化される場合、エンコーダは、１つの映像ブロックを処理する際にこのツールまたはモードを使用するまたは実装するが、このツールまたはモードの使用に基づいて、結果として得られるビットストリームを必ずしも修正しなくてもよい。すなわち、映像のブロックから映像のビットストリーム表現への変換は、決定または判定に基づいて映像処理ツールまたはモードが有効化される場合に、この映像処理ツールまたはモードを使用する。別の例において、映像処理ツールまたはモードが有効化される場合、デコーダは、ビットストリームが映像処理ツールまたはモードに基づいて修正されたことを知って、ビットストリームを処理する。すなわち、決定または判定に基づいて有効化された映像処理ツールまたはモードを使用して、映像のビットストリーム表現から映像のブロックへの変換を行う。
開示される技術のいくつかの実施形態は、映像処理ツールまたはモードを無効化するように決定または判定することを含む。一例において、映像処理ツールまたはモードが無効にされている場合、エンコーダは、映像のブロックを映像のビットストリーム表現に変換する際に、このツールまたはモードを使用しない。別の例において、映像処理ツールまたはモードが無効にされている場合、デコーダは、決定または判定に基づいて有効化された映像処理ツールまたはモードを使用してビットストリームが修正されていないことを知って、ビットストリームを処理する。
図２６は、本明細書で開示される様々な技術が実装され得る例示的な映像処理システム２６００を示すブロック図である。様々な実装形態は、システム２６００のコンポーネントの一部または全部を含んでもよい。システム２６００は、映像コンテンツを受信するための入力２６０２を含んでもよい。映像コンテンツは、未加工または非圧縮フォーマット、例えば、８または１０ビットのマルチコンポーネント画素値で受信されてもよく、または圧縮または符号化フォーマットで受信されてもよい。入力２６０２は、ネットワークインターフェース、周辺バスインターフェース、または記憶インターフェースを表してもよい。ネットワークインターフェースの例は、イーサネット（登録商標）、ＰＯＮ（Ｐａｓｓｉｖｅ Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ）等の有線インターフェース、およびＷｉ－Ｆｉ（登録商標）またはセルラーインターフェース等の無線インターフェースを含む。
システム２６００は、本明細書に記載される様々な符号化または符号化方法を実装することができる符号化コンポーネント２６０４を含んでもよい。符号化コンポーネント２６０４は、入力２６０２からの映像の平均ビットレートを符号化コンポーネント２６０４の出力に低減し、映像の符号化表現を生成してもよい。従って、この符号化技術は、映像圧縮または映像コード変換技術と呼ばれることがある。符号化コンポーネント２６０４の出力は、コンポーネント２６０６によって表されるように、記憶されてもよいし、接続された通信を介して送信されてもよい。入力２６０２において受信された、記憶されたまたは通信された映像のビットストリーム（または符号化）表現は、コンポーネント２６０８によって使用されて、表示インターフェース２６１０に送信される画素値または表示可能な映像を生成してもよい。ビットストリーム表現からユーザが見ることができる映像を生成する処理は、映像展開と呼ばれることがある。さらに、特定の映像処理動作を「符号化」動作またはツールと呼ぶが、符号化ツールまたは動作は、エンコーダおよびそれに対応する、復号化の結果を逆にする復号化ツールまたは動作が、デコーダによって行われることが理解されよう。
周辺バスインターフェースユニットまたは表示インターフェースユニットの例は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）またはＨＤＭＩ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ：登録商標）またはディスプレイポート等を含んでもよい。ストレージインターフェースの例は、ＳＡＴＡ（Ｓｅｒｉａｌ Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｅｍｅｎｔ）、ＰＣＩ、ＩＤＥインターフェース等を含む。本明細書に記載される技術は、携帯電話、ノートパソコン、スマートフォン、またはデジタルデータ処理および／または映像表示を実施可能な他のデバイス等の様々な電子デバイスに実施されてもよい。
いくつかの実施形態において、下記のような技術的解決策を実装することができる。
Ａ１． 映像処理のための方法であって、１または複数の映像ユニットを有する１または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を実行することを有し、ビットストリーム表現は、フォーマット規則に準拠し、かつ、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理に関する情報を有し、Ｋ次の指数ゴロム符号で符号化されている１または複数の映像ユニットの寸法が、ビットストリーム表現で信号通知され、Ｋは正の整数であり、フォーマット規則は、ＡＲＣ処理の映像セグメントへの適用を規定し、映像セグメントの１または複数の映像ユニットが異なる解像度で符号化されていることの指示が、構文構造のビットストリーム表現に含まれる、方法。
Ａ２． 寸法は、１または複数の映像ユニットのうちの映像ユニットの幅および高さの少なくとも１つを含む、解決策Ａ１に記載の方法。
Ａ３． １または複数の映像ユニットはピクチャを含む、解決策Ａ１に記載の方法。
Ａ４． 構文構造は、ＤＰＳ（Ｄｅｃｏｄｅｒ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＶＰＳ（Ｖｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＡＰＳ（Ａｄａｐｔｉｖｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ピクチャヘッダ、スライスヘッダ、またはタイルグループヘッダである、解決策Ａ１に記載の方法。
Ａ５． 構文構造は、ＲＰＳ（Ｒｅｓｏｌｕｔｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）またはＣＰＳ（Ｃｏｎｖｅｒｓｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）である、解決策Ａ１に記載の方法。
Ａ６． 映像処理のための方法であって、１または複数の映像ユニットを有する１または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を実行することを有し、ビットストリーム表現は、フォーマット規則に準拠し、かつ、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理に関する情報を有し、１または複数の映像ユニットのうちの映像ユニットの高さ（Ｈ）と幅（Ｗ）がビットストリーム表現で信号通知され、ＨとＷは、正の整数であり、かつ、抑制されており、フォーマット規則は、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理の映像セグメントへの適用を規定し、映像セグメントの１または複数の映像ユニットが異なる解像度で符号化されていることの指示が、構文構造のビットストリーム表現に含まれる、方法。
Ａ７． Ｗ≦ＴＷｍａｘであり、ＴＷｍａｘは正の整数である、解決策Ａ６に記載の方法。
Ａ８． ＴＷｍａｘはビットストリーム表現で信号通知される、解決策Ａ７に記載の方法。
Ａ９． ＴＷｍｉｎ≦Ｗであり、ＴＷｍｉｎは正の整数である、解決策Ａ６に記載の方法。
Ａ１０． ＴＷｍｉｎはビットストリーム表現で信号通知される、解決策Ａ９に記載の方法。
Ａ１１． Ｈ≦ＴＨｍａｘであり、ＴＨｍａｘは正の整数である、解決策Ａ６に記載の方法。
Ａ１２． ＴＨｍａｘはビットストリーム表現で信号通知される、解決策Ａ１１に記載の方法。
Ａ１３． ＴＨｍｉｎ≦Ｈであり、ＴＨｍｉｎは正の整数である、解決策Ａ６に記載の方法。
Ａ１４． ＴＨｍｉｎはビットストリーム表現で信号通知される、解決策Ａ１３に記載の方法。
Ａ１５． 高さＨ＝ｈ×Ｙであり、幅Ｗ＝ｗ×Ｘであり、ｗ、ｈ、Ｘ、およびＹは正の整数であり、ｗ、ｈはビットストリーム表現で信号通知される、解決策Ａ６に記載の方法。
Ａ１６． Ｘ＝Ｙ＝４である、解決策Ａ１５に記載の方法。
Ａ１７． ＸおよびＹが予め定義された整数である、解決策Ａ１５に記載の方法。
Ａ１８． １または複数の映像ユニットはピクチャを有する、解決策Ａ６に記載の方法。
Ａ１９． 映像処理のための方法であって、１または複数の映像ユニットを有する１または複数の映像セグメントを有する映像と、映像のビットストリーム表現との間の変換を実行することを有し、ビットストリーム表現は、フォーマット規則に準拠し、かつ、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理に関する情報を有し、フォーマット規則は、ＡＲＣ処理の映像セグメントへの適用を規定し、かつ、映像セグメントの１または複数の映像ユニットが、異なる解像度で符号化されることの指示が、ヘッダ構文構造、ＤＰＳ（Ｄｅｃｏｄｅｒ Ｐａｒａｍｅｔｅ Ｓｅｔ）、ＶＰＳ（Ｖｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、およびＡＰＳ（Ａｄａｐｔｉｖｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）とは異なる構文構造のビットストリーム表現に含まれる、方法。
Ａ２０． ＡＲＣ処理に関する情報は、１または複数の映像ユニットを有するピクチャの高さ（Ｈ）または幅（Ｗ）を有する、解決策Ａ１９に記載の方法。
Ａ２１． ＡＲＣ処理に関する情報は、ＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージで信号通知される、解決策Ａ１９またはＡ２０に記載の方法。
Ａ２２． ヘッダ構文構造は、ピクチャヘッダ、スライスヘッダ、またはタイルグループヘッダを有する、解決策Ａ１９またはＡ２０に記載の方法。
Ａ２３． ＡＲＣ処理に関する情報は、ＲＰＳ（Ｒｅｓｏｌｕｔｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）またはＣＰＳ（Ｃｏｎｖｅｒｓｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）にて信号通知される、解決策Ａ１９またはＡ２０に記載の方法。
Ａ２４． ＡＲＣ処理に関する情報は、１または複数の映像ユニットを有するピクチャの幅に対する高さの比を有する、解決策Ａ１９に記載の方法。
Ａ２５． ＡＲＣ処理に関する情報は、１または複数の映像ユニットを有するピクチャの異なる幅に対する異なる高さの複数の比を有する、解決策Ａ１９に記載の方法。
Ａ２６． 複数の比のうちの許容される比に対応するインデックスは、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）にて信号通知される、解決策Ａ２５に記載の方法。
Ａ２７． 複数の比のうちの任意の１つの比は、複数の比のうちの任意の他の比と異なる、解決策Ａ２５に記載の方法。
Ａ２８． 情報は、（ｉ）第１の幅と第２の幅との差、（ｉｉ）第１の高さと第２の高さとの差、（ｉｉｉ）第１の幅と第２の幅との比、または（ｉｖ）第１の高さと第２の高さとの比のうちの少なくとも１つを含む、解決策Ａ１９に記載の方法。
Ａ２９． 情報は、ユーナリー符号、トランケイテッドユーナリー符号、または固定長符号にて符号化される、解決策Ａ２８に記載の方法。
Ａ３０． ビットストリーム表現は更に、ＣＴＵ（Ｃｏｄｉｎｇ Ｔｒｅｅ Ｕｎｉｔ）サイズを示す構文要素、最小ＣＵ（Ｃｏｄｉｎｇ Ｕｎｉｔ）サイズを示す構文要素、最大または最小ＴＢ（Ｔｒａｎｓｆｏｒｍ Ｂｌｏｃｋ）サイズを示す構文要素、１または複数の映像ユニットに適用され得る分割処理の最大深さを示す構文要素、または特定のピクチャ解像度にバインドするように構成される構文要素のうちの少なくとも１つを含む、解決策Ａ１９に記載の方法。
Ａ３１． １または複数の映像ユニットを有する現在のピクチャに関連付けられた第１の参照ピクチャは、現在のピクチャの解像度に等しい第１の解像度を有し、現在のピクチャに関連付けられた第２の参照ピクチャは、現在のピクチャの解像度よりも大きい第２の解像度を有し、第２の参照ピクチャの参照インデックスは、第１の参照ピクチャの参照インデックスよりも大きい、解決策Ａ１９に記載の方法。
Ａ３２． 変換は、ビットストリーム表現から１または複数の映像ユニットを生成する、解決策Ａ１９～Ａ３１のいずれかに記載の方法。
Ａ３３． 変換は、１または複数の映像ユニットからビットストリーム表現を生成する、解決策Ａ１９～Ａ３１のいずれかに記載の方法。
Ａ３４． プロセッサと、命令を有する非一時的メモリとを有する、映像システムにおける装置であって、命令は、プロセッサにより実行されることにより、プロセッサに解決策Ａ１９～Ａ３３のいずれかに記載の方法を実装させる装置。
Ａ３５． 非一時的コンピュータ可読媒体に記憶されたコンピュータプログラムプロダクトであって、解決策Ａ１９～Ａ３３のいずれかに記載の方法を実行するためのプログラムコードを含む、コンピュータプログラムプロダクト。
いくつかの実施形態において、下記のような技術的解決策を実装することができる。
Ｂ１． 映像処理のための方法であって、（ａ）映像の現在の映像ブロックの時間的に近傍の第１のブロックの第１の参照ピクチャの解像度が、現在の映像ブロックを有する現在のピクチャの解像度と同一であること、および（ｂ）現在の映像ブロックの時間的に近傍の第２のブロックの第２の参照ピクチャの解像度が、現在のピクチャの解像度と異なること、を判定することと、判定に起因して、第１の時間的に近傍のブロックの予測における第２の時間的に近傍のブロックの動き情報の使用を無効化することにより、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を有する、方法。
Ｂ２． 映像処理のための方法であって、（ａ）映像の現在の映像ブロックの時間的に近傍の第１のブロックの第１の参照ピクチャの解像度が、現在の映像ブロックを有する現在のピクチャの解像度と異なること、および（ｂ）現在の映像ブロックの時間的に近傍の第２のブロックの第２の参照ピクチャの解像度が、現在のピクチャの解像度と同一であること、を判定することと、判定に起因して、第１の時間的に近傍のブロックの予測における第２の時間的に近傍のブロックの動き情報の使用を無効化することにより、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を有する、方法。
Ｂ３． 映像処理のための方法であって、映像の現在の映像ブロックのために、現在の映像ブロックに関連付けられた映像ブロックを有する参照ピクチャの解像度が、現在の映像ブロックを有する現在のピクチャの解像度とは異なることを判定することと、判定に起因して、参照ピクチャの映像ブロックに基づく予測処理を無効化することにより、現在の映像ブロックと映像のビットストリーム表現との間の変換を行うことと、を有する、映像処理方法。
Ｂ４． 映像処理のための方法であって、ピクチャの少なくとも１つの寸法に基づいて、ピクチャを現在のピクチャの現在の映像ブロックのための並置された参照ピクチャとして使用することが許可されるかどうかに関する決定を実行することと、決定に基づいて、映像の現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を有する、方法。
Ｂ５． 参照ピクチャの少なくとも１つの寸法は、現在の映像ブロックを有する現在のピクチャの対応する寸法と異なり、かつ、参照ピクチャは、並置された参照ピクチャとして指定されない、解決策Ｂ４に記載の方法。
Ｂ６． 映像処理のための方法であって、映像の現在の映像ブロックの予測のために、並置されたブロックを有する並置された参照ピクチャの寸法が、現在の映像ブロックを有する現在のピクチャの寸法と同一であることの判定に基づいて、並置されたブロックを識別することと、並置されたブロックを使用して、現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を有する、映像処理方法。
Ｂ７． 予測は、ＴＭＶＰ（Ｔｅｍｐｏｒａｌ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ）処理またはＡＴＭＶＰ（Ａｌｔｅｒｎａｔｉｖｅ Ｔｅｍｐｏｒａｌ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ）処理を有する、解決策Ｂ６に記載の方法。
Ｂ８． 現在のピクチャは寸法Ｗ０×Ｈ０を有し、並置された参照ピクチャは寸法Ｗ１×Ｈ１を有し、並置されたブロックの位置またはサイズは、Ｗ０、Ｈ０、Ｗ１またはＨ１のうちの少なくとも１つに基づき、Ｗ０、Ｈ０、Ｗ１、およびＨ１は正の整数である、解決策Ｂ７に記載の方法。
Ｂ９． ＡＴＭＶＰ処理における時間的動きベクトルの導出は、Ｗ０、Ｈ０、Ｗ１、またはＨ１のうちの少なくとも１つに基づく、解決策Ｂ８に記載の方法。
Ｂ１０． 現在の映像ブロックのための動きベクトル予測の導出は、Ｗ０、Ｈ０、Ｗ１、またはＨ１のうちの少なくとも１つに基づく、解決策Ｂ８に記載の方法。
Ｂ１１． 映像処理のための方法であって、映像の現在の映像ブロックのために、現在の映像ブロックに関連付けられた参照ピクチャが、現在の映像ブロックを有する現在のピクチャの解像度とは異なる解像度を有することを判定することと、現在の映像ブロックと映像のビットストリーム表現との間の変換の一部として、参照ピクチャの１または複数の参照サンプル、および現在の映像ブロックに対する動き情報または現在の映像ブロックに対する符号化情報においてアップサンプリング動作またはダウンサンプリング動作を実行することと、を有する、映像処理方法。
Ｂ１２． 現在の映像ブロックを有する現在のフレームと異なるフレームにおける後続の映像ブロックを符号化するために、アップサンプリング動作またはダウンサンプリング動作に関する情報を使用することをさらに含む、解決策Ｂ１１に記載の方法。
Ｂ１３． 映像処理のための方法であって、映像の現在の映像ブロックと映像のビットストリーム表現との間の変換のために、現在の映像ブロックを有する現在のピクチャの高さまたは幅は、現在の映像ブロックに関連付けられた並置された参照ピクチャの高さまたは幅とは異なることを判定することと、判定に基づいて、並置された参照ピクチャの１または複数の動きベクトルを記憶するバッファに対してアップサンプリング動作またはダウンサンプリング動作を実行することと、を有する、方法。
Ｂ１４． 映像処理のための方法であって、映像の現在の映像ブロックを有する現在のピクチャの寸法と、現在の映像ブロックに関連付けられた、並置されたピクチャの寸法とに基づいて、現在の映像ブロックに適用されたＡＴＭＶＰ（Ａｌｔｅｒｎａｔｉｖｅ Ｔｅｍｐｏｒａｌ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ）処理のための情報を導出することと、時間的動きベクトルを使用して現在の映像ブロックと映像のビットストリーム表現との間の変換を実行することと、を有する、方法。
Ｂ１５． 情報は、時間的動きベクトルを有する、解決策Ｂ１４に記載の方法。
Ｂ１６． 情報は、現在の映像ブロックのためのＭＶＰ（Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ）を含み、導出することは更に、ＭＶＰによって参照される参照ピクチャの寸法に基づく、解決策Ｂ１４に記載の方法。
Ｂ１７． 映像処理のための方法であって、映像の現在の映像ブロックに対するＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理の適用のために、映像のビットストリーム表現を構成することであって、ＡＲＣ処理に関する情報は、ビットストリーム表現にて信号通知され、現在の映像ブロックを有する現在のピクチャは、第１の解像度を有し、ＡＲＣ処理は、第１の解像度とは異なる第２の解像度にて現在の映像ブロックの一部を再サンプリングすることを有する、ことと、構成することに基づいて、現在の映像ブロックと現在の映像ブロックの前記ビットストリーム表現との間の変換を実行することと、を有する、方法。
Ｂ１８． ＡＲＣ処理に関する情報は、１または複数のアップサンプリングまたはダウンサンプリングフィルタリング方法のためのパラメータを有する、解決策Ｂ１７に記載の方法。
Ｂ１９． ＡＲＣ処理に関する情報は、符号化映像シーケンス内での解像度の変更を可能にするように、参照ピクチャをスケーリングするための水平方向のスケーリング係数または垂直方向のスケーリング係数を有する、解決策Ｂ１７に記載の方法。
Ｂ２０． 情報は、ＤＰＳ（Ｄｅｃｏｄｅｒ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＶＰＳ（Ｖｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＡＰＳ（Ａｄａｐｔｉｖｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ピクチャヘッダ、スライスヘッダ、タイルグループヘッダ、または個々の映像ユニットにおいて信号通知される、解決策Ｂ１８またはＢ１９に記載の方法。
Ｂ２１． 個々の映像ユニットは、ＲＰＳ（Ｒｅｓｏｌｕｔｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）またはＣＰＳ（Ｃｏｎｖｅｒｓｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）である、解決策Ｂ２０に記載の方法。
Ｂ２２． 水平スケーリング係数または垂直スケーリング係数を導出することは、１または複数のテーブルを使用して実装される分割動作を含む、解決策Ｂ１９に記載の方法。
Ｂ２３． 変換は、ビットストリーム表現から現在の映像ブロックを生成する、解決策Ｂ１～Ｂ２２のいずれかに記載の方法。
Ｂ２４． 変換は、現在の映像ブロックからビットストリーム表現を生成する、解決策Ｂ１～Ｂ２２のいずれかに記載の方法。
Ｂ２５． プロセッサと、命令を有する非一時的メモリとを有する、映像システムにおける装置であって、命令は、プロセッサにより実行されることにより、プロセッサに、解決策Ｂ１～Ｂ２４のいずれかに記載の方法を実装させる装置。
Ｂ２６． 非一時的なコンピュータ可読媒体に記憶されたコンピュータプログラムプロダクトであって、解決策Ｂ１～Ｂ２４のいずれかに記載の方法を実行するためのプログラムコードを含む、コンピュータプログラムプロダクト。
いくつかの実施形態において、下記のような技術的解決策を実装することができる。
Ｃ１． 映像処理のための方法であって、現在の映像ブロックに対するＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理の適用のために、現在の映像ブロックのビットストリーム表現を構成することであって、ＡＲＣ処理に関する情報は、ビットストリーム表現で信号通知され、現在の映像ブロックは、第１の解像度を有し、ＡＲＣ処理は、第１の解像度とは異なる第２の解像度で現在の映像ブロックの一部を再サンプリングすることを有する、ことと、構成することに基づいて、現在の映像ブロックと現在の映像ブロックのビットストリーム表現との間の変換を実行することと、を有する、方法。
Ｃ２． ＡＲＣ処理に関する情報は、現在の映像ブロックを有するピクチャの高さ（Ｈ）または幅（Ｗ）を有する、解決策Ｃ１に記載の方法。
Ｃ３． ＡＲＣ処理に関する情報は、ＤＰＳ（Ｄｅｃｏｄｅｒ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＶＰＳ（Ｖｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＡＰＳ（Ａｄａｐｔｉｖｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ピクチャヘッダ、スライスヘッダ、およびタイルグループヘッダとは異なるＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージにて信号通知される、解決策Ｃ１またはＣ２に記載の方法。
Ｃ４． ＡＲＣ処理に関する情報は、個々の映像ユニットにて信号通知される、解決策Ｃ１またはＣ２に記載の方法。
Ｃ５． 個々の映像ユニットは、ＲＰＳ（Ｒｅｓｏｌｕｔｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）またはＣＰＳ（Ｃｏｎｖｅｒｓｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）である、解決策Ｃ４に記載の方法。
Ｃ６． ＡＲＣ処理に関する情報は、固定長符号またはユーナリー符号で符号化される、解決策Ｃ１～Ｃ５のいずれかに記載の方法。
Ｃ７． ＡＲＣ処理に関する情報は、Ｋ次の指数ゴロム符号で符号化され、Ｋは正の整数である、解決策Ｃ１～Ｃ５のいずれかに記載の方法。
Ｃ８． ＡＲＣ処理に関する情報は、ＤＰＳ（Ｄｅｃｏｄｅｒ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＶＰＳ（Ｖｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＡＰＳ（Ａｄａｐｔｉｖｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ピクチャヘッダ、スライスヘッダ、またはタイルグループヘッダにて信号通知される、解決策Ｃ１またはＣ２に記載の方法。
Ｃ９． ＡＲＣ処理に関する情報は、現在の映像ブロックを有するピクチャの幅に対する高さの比を有する、解決策Ｃ１に記載の方法。
Ｃ１０． ＡＲＣ処理に関する情報は、現在の映像ブロックを有するピクチャの異なる幅に対する異なる高さの複数の比を有する、解決策Ｃ１に記載の方法。
Ｃ１１． 複数の比のうちの許容される比に対応するインデックスが、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）にて信号通知される、解決策Ｃ１０に記載の方法。
Ｃ１２． 複数の比のうちの任意の１つの比率が、複数の比率のうちの任意の他の比率と異なる、解決策Ｃ１０に記載の方法。
Ｃ１３． ＴＷｍｉｎ≦Ｗ≦ＴＷｍａｘであり、ＴＷｍｉｎおよびＴＷｍａｘは正の整数である、解決策Ｃ２に記載の方法。
Ｃ１４． ＴＷｍｉｎおよびＴＷｍａｘは、現在の映像ブロックのビットストリーム表現にて信号通知される、解決策Ｃ１３に記載の方法。
Ｃ１５． ＴＨｍｉｎ≦Ｈ≦ＴＨｍａｘであり、ＴＨｍｉｎおよびＴＨｍａｘは正の整数である、解決策Ｃ２に記載の方法。
Ｃ１６． ＴＨｍｉｎおよびＴＨｍａｘは、現在の映像ブロックのビットストリーム表現にて信号通知される、解決策Ｃ１３に記載の方法。
Ｃ１７． 現在の映像ブロックを有するピクチャは、高さＨ＝ｈ×Ｙおよび幅Ｗ＝ｗ×Ｘを有し、ｗ、ｈ、Ｗ、Ｈ、Ｘ、およびＹは正の整数であり、ＸおよびＹは予め定義された整数であり、ＡＲＣ処理に関する情報はｗおよびｈを有する、解決策Ｃ１に記載の方法。
Ｃ１８． Ｘ＝Ｙ＝４である、解決策Ｃ１７に記載の方法。
Ｃ１９． ＡＲＣ処理に関する情報は、（ｉ）第１の幅と第２の幅との差、（ｉｉ）第１の高さと第２の高さとの差、（ｉｉｉ）第１の幅と第２の幅との比、または（ｉｖ）第１の高さと第２の高さとの比のうちの少なくとも１つを含む、解決策Ｃ１に記載の方法。
Ｃ２０． 情報は、ユーナリー符号、トランケイテッドユーナリー符号、または固定長符号で符号化される、解決策Ｃ１９に記載の方法。
Ｃ２１． ビットストリーム表現は更に、ＣＴＵ（Ｃｏｄｉｎｇ Ｔｒｅｅ Ｕｎｉｔ）サイズを示す構文要素、最小ＣＵ（Ｃｏｄｉｎｇ Ｕｎｉｔ）サイズを示す構文要素、最大または最小ＴＢ（Ｔｒａｎｓｆｏｒｍ Ｂｌｏｃｋ）サイズを示す構文要素、現在の映像ブロックに適用され得る分割処理の最大深さを示す構文要素、または特定のピクチャ解像度にバインドするように構成される構文要素のうちの少なくとも１つを有する、解決策Ｃ１に記載の方法。
Ｃ２２． 映像処理の方法であって、現在の映像ブロックの予測のために、現在の映像ブロックの時間的に近傍のブロックの参照ピクチャを選択的に使用することに関する決定を実行することと、決定および現在の映像ブロックの参照ピクチャに基づいて、現在の映像ブロックと現在の映像ブロックのビットストリーム表現との間の変換を実行することと、を有する、方法。
Ｃ２３． 現在の映像ブロックの参照ピクチャの解像度は、現在の映像ブロックの解像度と同一であり、時間的に近傍のブロックの参照ピクチャの解像度は、現在の映像ブロックの解像度とは異なり、現在の映像ブロックの予測は、時間的に近傍のブロックに関連付けられた動き情報を使用しない、解決策Ｃ２２に記載の方法。
Ｃ２４． 現在の映像ブロックの参照ピクチャの解像度は、現在の映像ブロックの解像度と異なり、時間的に近傍のブロックの参照ピクチャの解像度は、現在の映像ブロックの解像度とは異なり、現在の映像ブロックの予測は、時間的に近傍のブロックに関連付けられた動き情報を使用しない、解決策Ｃ２２に記載の方法。
Ｃ２５． 映像処理の方法であって、現在の映像ブロックの参照ピクチャの少なくとも１つの寸法に基づいて、参照ピクチャの並置された参照ピクチャとしての指定に関する決定を実行することと、決定に基づいて、現在の映像ブロックと、現在の映像ブロックのビットストリーム表現との間の変換を実行することと、を有する、方法。
Ｃ２６． 参照ピクチャの少なくとも１つの寸法は、現在の映像ブロックを有する現在のピクチャの対応する寸法と異なり、前記参照ピクチャは、並置された参照ピクチャとして指定されない、解決策Ｃ２５に記載の方法。
Ｃ２７． 映像処理のための方法であって、現在の映像ブロックを予測するために、並置されたブロックに関連付けられた並置された参照ピクチャの寸法と、現在の映像ブロックを有する現在のピクチャの寸法との比較に基づいて、並置されたブロックを識別することと、識別に基づいて、現在の映像ブロックの予測を実行することと、を有する、方法。
Ｃ２８． 予測は、時間的動きベクトル予測処理またはＡＴＭＶＰ（ＡｌｔｅｒｎａｔｉｖｅＴｅｍｐｏｒａｌ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ）処理を有する、解決策Ｃ２７に記載の方法。
Ｃ２９． 現在のピクチャは寸法Ｗ０×Ｈ０を有し、並置された参照ピクチャは寸法Ｗ１×Ｈ１を有し、並置されたブロックの位置またはサイズは、Ｗ０、Ｈ０、Ｗ１、またはＨ１のうちの少なくとも１つに基づく、解決策Ｃ２７またはＣ２８に記載の方法。
Ｃ３０． ＡＴＭＶＰ処理における時間的動きベクトルの導出は、Ｗ０、Ｈ０、Ｗ１、またはＨ１のうちの少なくとも１つに基づく、解決策Ｃ２９に記載の方法。
Ｃ３１． 現在の映像ブロックのための動きベクトル予測の導出は、Ｗ０、Ｈ０、Ｗ１、またはＨ１のうちの少なくとも１つに基づく、解決策Ｃ２９に記載の方法。
Ｃ３２． ＡＲＣ処理に関する情報は、１または複数のアップサンプリングまたはダウンサンプリングフィルタリング方法のためのパラメータを有する、解決策Ｃ１に記載の方法。
Ｃ３３． ＡＲＣ処理に関する情報は、ＣＶＳ（Ｃｏｄｅｄ Ｖｉｄｅｏ Ｓｅｑｕｅｎｃｅ）内での解像度の変更を可能にするように、参照ピクチャをスケーリングするための水平方向のスケーリング係数または垂直方向のスケーリング係数を有する、解決策Ｃ１に記載の方法。
Ｃ３４． 情報は、ＤＰＳ（Ｄｅｃｏｄｅｒ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＶＰＳ（Ｖｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＡＰＳ（Ａｄａｐｔｉｖｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ピクチャヘッダ、スライスヘッダ、タイルグループヘッダ、または個々の映像ユニットにて信号通知される、解決策Ｃ３２またはＣ３３に記載の方法。
Ｃ３５． 個々の映像ユニットは、ＲＰＳ（Ｒｅｓｏｌｕｔｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）またはＣＰＳ（Ｃｏｎｖｅｒｓｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）である、解決策Ｃ３４に記載の方法。
Ｃ３６． プロセッサと、命令を有する非一時的メモリとを有する、映像システムにおける装置であって、命令は、プロセッサにより実行されることにより、プロセッサに、解決策Ｃ１～Ｃ３５のいずれかに記載の方法を実施させる装置。
Ｃ３７． 非一時的コンピュータ可読媒体に記憶されたコンピュータプログラムプロダクトであって、解決策Ｃ１～Ｃ３５のいずれかに記載の方法を実行するためのプログラムコードを含む、コンピュータプログラムプロダクト。
以上、説明の目的で本開示の技術の特定の実施形態を説明したが、本発明の範囲から逸脱することなく様々な修正が可能であることは、理解されるであろう。従って、本開示の技術は、添付の特許請求の範囲による場合を除き、限定されない。
本特許明細書に記載された主題および機能操作の実装形態は、本明細書に開示された構造およびその構造的等価物を含め、様々なシステム、デジタル電子回路、またはコンピュータソフトウェア、ファームウェア、若しくはハードウェアで実施されてもよく、またはそれらの１または複数の組み合わせで実施してもよい。本明細書に記載された主題の実装形態は、１または複数のコンピュータプログラムプロダクト、すなわち、データ処理装置によって実行されるため、またはデータ処理装置の動作を制御するために、有形で非可搬性のコンピュータ可読媒体上に符号化されたコンピュータプログラム命令の１または複数のモジュールとして実装することができる。このコンピュータ可読媒体は、機械可読記憶装置、機械可読記憶基板、メモリデバイス、機械可読伝播信号をもたらす物質の組成物、またはこれらの１または複数の組み合わせであってもよい。「データ処理ユニット」または「データ処理装置」という用語は、例えば、プログラマブルプロセッサ、コンピュータ、または複数のプロセッサ若しくはコンピュータを含み、データを処理するためのすべての装置、デバイス、および機械を含む。装置は、ハードウェアの他に、当該コンピュータプログラムの実行環境を作るコード、例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、またはこれらの１または複数の組み合わせを構成するコードを含むことができる。
コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとも呼ばれる）は、コンパイルされた言語または解釈された言語を含む任意の形式のプログラミング言語で記述することができ、また、それは、スタンドアロンプログラムとして、またはコンピューティング環境で使用するのに適したモジュール、コンポーネント、サブルーチン、または他のユニットとして含む任意の形式で展開することができる。コンピュータプログラムは、必ずしもファイルシステムにおけるファイルに対応するとは限らない。プログラムは、他のプログラムまたはデータを保持するファイルの一部（例えば、マークアップ言語文書に格納された１または複数のスクリプト）に記録されていてもよいし、当該プログラム専用の単一のファイルに記憶されていてもよいし、複数の調整ファイル（例えば、１または複数のモジュール、サブプログラム、またはコードの一部を格納するファイル）に記憶されていてもよい。コンピュータプログラムを、１つのサイトに位置する１つのコンピュータ、または複数のサイトに分散され通信ネットワークによって相互接続される複数のコンピュータで実行させるように展開することも可能である。
本明細書に記載された処理およびロジックフローは、入力データ上で動作し、出力を生成することによって機能を実行するための１または複数のコンピュータプログラムを実行する１または複数のプログラマブルプロセッサによって行うことができる。処理およびロジックフローはまた、特定用途のロジック回路、例えば、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）またはＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）によって実行することができ、装置はまた、特別目的のロジック回路として実装することができる。
コンピュータプログラムの実行に適したプロセッサは、例えば、汎用および専用マイクロプロセッサの両方、並びに任意の種類のデジタルコンピュータの任意の１または複数のプロセッサを含む。一般的に、プロセッサは、読み出し専用メモリまたはランダムアクセスメモリまたはその両方から命令およびデータを受信する。コンピュータの本質的な要素は、命令を実行するためのプロセッサと、命令およびデータを記憶するための１または複数のメモリ装置とである。一般的に、コンピュータは、データを記憶するための１または複数の大容量記憶デバイス、例えば、磁気、光磁気ディスク、または光ディスクを含んでもよく、またはこれらの大容量記憶デバイスからデータを受信するか、またはこれらにデータを転送するように動作可能に結合されてもよい。しかしながら、コンピュータは、このようなデバイスを有する必要はない。コンピュータプログラム命令およびデータを記憶するのに適したコンピュータ可読媒体は、あらゆる形式の不揮発性メモリ、媒体、およびメモリデバイスを含み、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリデバイス等の半導体メモリデバイスを含む。プロセッサおよびメモリは、特定用途のロジック回路によって補完されてもよく、または特定用途のロジック回路に組み込まれてもよい。
本明細書は、図面とともに、例示のみを目的とするものであり、例示的とは例を意味することが意図される。本明細書において、「または」の使用は、文脈からそうでないことが明確に示されていない限り、「および／または」を含むことが意図される。
本特許明細書は多くの詳細を含むが、これらは、任意の発明の範囲または特許請求の範囲を限定するものと解釈されるべきではなく、むしろ、特定の発明の特定の実施形態に特有であり得る特徴の説明と解釈されるべきである。本明細書において別個の実施形態の文脈で説明されている特定の特徴は、１つの例において組み合わせて実装してもよい。逆に、１つの例のコンテキストで説明された様々な特徴は、複数の実施形態において別個にまたは任意の適切なサブコンビネーションで実装してもよい。さらに、特徴は、特定の組み合わせで作用するものとして上記に記載され、最初にそのように主張されていてもよいが、主張された組み合わせからの１または複数の特徴は、場合によっては、組み合わせから抜粋されることができ、主張された組み合わせは、サブコンビネーションまたはサブコンビネーションのバリエーションに向けられてもよい。
同様に、動作は図面において特定の順番で示されているが、これは、所望の結果を達成するために、このような動作が示された特定の順番でまたは連続した順番で行われること、または示された全ての動作が行われることを必要とするものと理解されるべきではない。また、本特許明細書に記載されている例における様々なシステムの構成要素の分離は、全ての実施形態においてこのような分離を必要とするものと理解されるべきではない。
いくつかの実装形態および例のみが記載されており、この特許文献に記載され図示されているコンテンツに基づいて、他の実施形態、拡張および変形が可能である。
関連出願の相互参照
本願は、２０１９年５月１２日出願の国際特許出願第ＰＣＴ／ＣＮ２０１９／０８６５１３号の優先権および利益を主張する、２０２０年５月１２日出願の国際特許出願第ＰＣＴ／ＣＮ２０２０／０８９７４０号に基づく。全ての上記特許出願は、それらの全体における参照によりここで援用される。

Claims (35)

  1. 映像処理のための方法であって、
    １または複数の映像ユニットを有する１または複数の映像セグメントを有する映像と、前記映像のビットストリーム表現との間の変換を実行することを有し、
    前記ビットストリーム表現は、フォーマット規則に準拠し、かつ、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理に関する情報を有し、
    Ｋ次の指数ゴロム符号にて符号化された前記１または複数の映像ユニットの寸法は、前記ビットストリーム表現にて信号通知され、
    Ｋは、正の整数であり、
    前記フォーマット規則は、映像セグメントへの前記ＡＲＣ処理の適用を規定し、
    前記映像セグメントの前記１または複数の映像ユニットが異なる解像度にて符号化されていることの指示は、構文構造の前記ビットストリーム表現に含まれる、方法。
  2. 前記寸法は、前記映像ユニットの幅と、前記１または複数の映像ユニットのうちの映像ユニットの高さの少なくとも一方を有する、請求項１に記載の方法。
  3. 前記１または複数の映像ユニットは、ピクチャを有する、請求項１に記載の方法。
  4. 前記構文構造は、ＤＰＳ（Ｄｅｃｏｄｅｒ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＶＰＳ（Ｖｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＡＰＳ（Ａｄａｐｔｉｖｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ピクチャヘッダ、スライスヘッダ、またはタイルグループヘッダである、請求項１に記載の方法。
  5. 前記構文構造は、ＲＰＳ（Ｒｅｓｏｌｕｔｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、またはＣＰＳ（Ｃｏｎｖｅｒｓｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）である、請求項１に記載の方法。
  6. 映像処理のための方法であって、
    １または複数の映像ユニットを有する１または複数の映像セグメントを有する映像と、前記映像のビットストリーム表現との間の変換を実行することを有し、
    前記ビットストリーム表現は、フォーマット規則に準拠し、かつ、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理に関する情報を有し、
    前記１または複数の映像ユニットのうちの映像ユニットの高さ（Ｈ）および幅（Ｗ）は、前記ビットストリーム表現にて信号通知され、
    ＨおよびＷは、正の整数であり、かつ、抑制され、
    前記フォーマット規則は、映像セグメントへのＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理の適用を規定し、
    前記映像セグメントの前記１または複数の映像ユニットが異なる解像度にて符号化されていることの指示は、構文構造の前記ビットストリーム表現に含まれる、方法。
  7. Ｗ≦ＴＷｍａｘであり、
    ＴＷｍａｘは、正の整数である、請求項６に記載の方法。
  8. ＴＷｍａｘは、前記ビットストリーム表現にて信号通知される、請求項６に記載の方法。
  9. ＴＷｍｉｎ≦Ｗであり、
    ＴＷｍｉｎは、正の整数である、請求項６に記載の方法。
  10. ＴＷｍｉｎは、前記ビットストリーム表現にて信号通知される、請求項９に記載の方法。
  11. Ｈ≦ＴＨｍａｘであり、
    ＴＨｍａｘは、正の整数である、請求項６に記載の方法。
  12. ＴＨｍａｘは、前記ビットストリーム表現にて信号通知される、請求項１１に記載の方法。
  13. ＴＨｍｉｎ≦Ｈであり、
    ＴＨｍｉｎは、正の整数である、請求項６に記載の方法。
  14. ＴＨｍｉｎは、前記ビットストリーム表現にて信号通知される、請求項１１に記載の方法。
  15. 前記高さＨ＝ｈ×Ｙ、かつ、前記幅Ｗ＝ｗ×Ｘであり、
    ｗ、ｈ、Ｘ、およびＹは、正の整数であり、
    ｗ、およびｈは、前記ビットストリーム表現にて信号通知される、請求項６に記載の方法。
  16. Ｘ＝Ｙ＝４である、請求項１５に記載の方法。
  17. ＸおよびＹは、予め定義された整数である、請求項１５に記載の方法。
  18. 前記１または複数の映像ユニットは、ピクチャを有する、請求項６に記載の方法。
  19. 映像処理のための方法であって、
    １または複数の映像ユニットを有する１または複数の映像セグメントを有する映像と、前記映像のビットストリーム表現との間の変換を実行することを有し、
    前記ビットストリーム表現は、フォーマット規則に準拠し、かつ、ＡＲＣ（Ａｄａｐｔｉｖｅ Ｒｅｓｏｌｕｔｉｏｎ Ｃｏｎｖｅｒｓｉｏｎ）処理に関する情報を有し、
    前記フォーマット規則は、映像セグメントへの前記ＡＲＣ処理の適用を規定し、
    前記映像セグメントの前記１または複数の映像ユニットが異なる解像度にて符号化されていることの指示は、ヘッダ構文構造、ＤＰＳ（Ｄｅｃｏｄｅｒ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＶＰＳ（Ｖｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、およびＡＰＳ（Ａｄａｐｔｉｖｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）とは異なる構文構造の前記ビットストリーム表現に含まれる、方法。
  20. 前記ＡＲＣ処理に関する前記情報は、前記１または複数の映像ユニットを有するピクチャの高さ（Ｈ）または幅（Ｗ）を有する、請求項１９に記載の方法。
  21. 前記ＡＲＣ処理に関する前記情報は、ＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージにて信号通知される、請求項１９または２０に記載の方法。
  22. 前記ヘッダ構文構造は、ピクチャヘッダ、スライスヘッダ、または、タイルグループヘッダを有する、請求項１９または２０に記載の方法。
  23. 前記ＡＲＣ処理に関する前記情報は、ＲＰＳ（Ｒｅｓｏｌｕｔｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、またはＣＰＳ（Ｃｏｎｖｅｒｓｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）にて信号通知される、請求項１９または２０に記載の方法。
  24. 前記ＡＲＣ処理に関する前記情報は、前記１または複数の映像ユニットを有するピクチャの幅に対する高さの比を有する、請求項１９に記載の方法。
  25. 前記ＡＲＣ処理に関する前記情報は、前記１または複数の映像ユニットを有するピクチャの異なる幅に対する異なる高さの複数の比を有する、請求項１９に記載の方法。
  26. 前記複数の比のうちの許可された比に対応するインデックスは、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）にて信号通知される、請求項２５に記載の方法。
  27. 前記複数の比のうちのいずれかの比は、前記複数の比のうちの他の比とは異なる、請求項２５に記載の方法。
  28. 前記情報は、（ｉ）第１の幅と第２の幅との差、（ｉｉ）第１の高さと第２の高さとの差、（ｉｉｉ）前記第１の幅と前記第２の幅との比、または（ｉｖ）前記第１の高さと前記第２の高さとの比のうちの少なくとも１つを有する、請求項１９に記載の方法。
  29. 前記情報は、ユーナリー符号、トランケイテッドユーナリー符号、または固定長符号にて符号化される、請求項２８に記載の方法。
  30. 前記ビットストリーム表現は更に、ＣＴＵ（Ｃｏｄｉｎｇ Ｔｒｅｅ Ｕｎｉｔ）サイズを示す構文要素、最小ＣＵ（Ｃｏｄｉｎｇ Ｕｎｉｔ）サイズを示す構文要素、最大または最小ＴＢ（Ｔｒａｎｓｆｏｒｍ Ｂｌｏｃｋ）サイズを示す構文要素、前記１または複数の映像ユニットに適用可能な分割処理の最大深さを示す構文要素、または、特定のピクチャ解像度にてバインドするように構成される構文要素のうちの少なくとも１つを有する、請求項１９に記載の方法。
  31. 前記１または複数の映像ユニットを有する現在のピクチャに関連付けられた第１の参照ピクチャは、前記現在のピクチャの解像度と等しい第１の解像度を有し、
    前記現在のピクチャに関連付けられた第２の参照ピクチャは、前記現在のピクチャの前記解像度よりも大きい第２の解像度を有し、
    前記第２の参照ピクチャの参照インデックスは、前記第１の参照ピクチャの参照インデックスよりも大きい、請求項１９に記載の方法。
  32. 前記変換は、前記１または複数の映像ユニットを前記ビットストリーム表現から生成する、請求項１９～３１のいずれか一項に記載の方法。
  33. 前記変換は、前記ビットストリーム表現を前記１または複数の映像ユニットから生成する、請求項１９～３１のいずれか一項に記載の方法。
  34. プロセッサと、命令を有する非一時的メモリを有する、映像システムにおける装置であって、
    前記命令は、前記プロセッサにより実行されることにより前記プロセッサに請求項１９～３３のいずれか一項に記載の方法を実装させる、装置。
  35. 非一時的コンピュータ可読媒体に格納されたコンピュータプログラムプロダクトであって、
    請求項１９～３３のいずれか一項に記載の方法を実行するためのプログラムコードを含むコンピュータプログラムプロダクト。
JP2021567036A 2019-05-12 2020-05-12 参照ピクチャ再サンプリングのための信号通知 Active JP7273193B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023072497A JP7513796B2 (ja) 2019-05-12 2023-04-26 参照ピクチャ再サンプリングのための信号通知

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN2019086513 2019-05-12
CNPCT/CN2019/086513 2019-05-12
PCT/CN2020/089740 WO2020228691A1 (en) 2019-05-12 2020-05-12 Signaling for reference picture resampling

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2023072497A Division JP7513796B2 (ja) 2019-05-12 2023-04-26 参照ピクチャ再サンプリングのための信号通知

Publications (2)

Publication Number Publication Date
JP2022532334A true JP2022532334A (ja) 2022-07-14
JP7273193B2 JP7273193B2 (ja) 2023-05-12

Family

ID=73289080

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2021567036A Active JP7273193B2 (ja) 2019-05-12 2020-05-12 参照ピクチャ再サンプリングのための信号通知
JP2023072497A Active JP7513796B2 (ja) 2019-05-12 2023-04-26 参照ピクチャ再サンプリングのための信号通知

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2023072497A Active JP7513796B2 (ja) 2019-05-12 2023-04-26 参照ピクチャ再サンプリングのための信号通知

Country Status (6)

Country Link
US (2) US11671602B2 (ja)
EP (1) EP3954124A4 (ja)
JP (2) JP7273193B2 (ja)
KR (1) KR102653570B1 (ja)
CN (2) CN113875250A (ja)
WO (2) WO2020228692A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022546155A (ja) * 2019-07-09 2022-11-04 アリババ・グループ・ホールディング・リミテッド 解像度適応型ビデオコーディング

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
BR112021002832A2 (pt) * 2018-08-17 2021-05-04 Huawei Technologies Co., Ltd. gerenciamento de imagem de referência em codificação de vídeo
CA3133224A1 (en) * 2019-03-11 2020-09-17 Yong He Methods and apparatus for sub-picture adaptive resolution change
WO2020200235A1 (en) 2019-04-01 2020-10-08 Beijing Bytedance Network Technology Co., Ltd. Half-pel interpolation filter in intra block copy coding mode
EP4011085A4 (en) * 2019-08-06 2023-07-26 OP Solutions, LLC ADAPTIVE RESOLUTION MANAGEMENT USING SUBFRAME
BR112022002480A2 (pt) 2019-08-20 2022-04-26 Beijing Bytedance Network Tech Co Ltd Método para processamento de vídeo, aparelho em um sistema de vídeo, e, produto de programa de computador armazenado em uma mídia legível por computador não transitória
US20220417499A1 (en) * 2019-12-13 2022-12-29 Sony Group Corporation Image processing apparatus and method
US11863789B2 (en) * 2020-03-31 2024-01-02 Tencent America LLC Method for signaling rectangular slice partitioning in coded video stream
KR20230165766A (ko) * 2021-04-02 2023-12-05 베이징 바이트댄스 네트워크 테크놀로지 컴퍼니, 리미티드 확장성 차원 정보(scalability dimension information)의 사용
CN113783600B (zh) * 2021-08-31 2023-06-02 西南电子技术研究所（中国电子科技集团公司第十研究所） 巨型低轨互联网星座路由方法
US20230177649A1 (en) * 2021-12-03 2023-06-08 Nvidia Corporation Temporal image blending using one or more neural networks
WO2023184467A1 (en) * 2022-04-01 2023-10-05 Intel Corporation Method and system of video processing with low latency bitstream distribution
US20240251106A1 (en) * 2023-01-10 2024-07-25 Sharp Kabushiki Kaisha Systems and methods for signaling picture resolution information in video coding

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100772878B1 (ko) * 2006-03-27 2007-11-02 삼성전자주식회사 비트스트림의 비트율 조절을 위한 우선권 할당 방법,비트스트림의 비트율 조절 방법, 비디오 디코딩 방법 및 그방법을 이용한 장치
JP5651560B2 (ja) * 2011-09-07 2015-01-14 日本放送協会 動きベクトル予測装置、符号化装置、復号装置、及びこれらのプログラム
US9451252B2 (en) * 2012-01-14 2016-09-20 Qualcomm Incorporated Coding parameter sets and NAL unit headers for video coding
WO2014053085A1 (en) * 2012-10-03 2014-04-10 Mediatek Inc. Method and apparatus of motion information management in video coding
US9998735B2 (en) 2013-04-01 2018-06-12 Qualcomm Incorporated Inter-layer reference picture restriction for high level syntax-only scalable video coding
US9509999B2 (en) 2013-06-11 2016-11-29 Qualcomm Incorporated Inter-layer prediction types in multi-layer video coding
WO2015006281A2 (en) * 2013-07-09 2015-01-15 Sony Corporation High level syntax improvement on inter-layer prediction for shvc/mv-hevc
US20150078457A1 (en) * 2013-09-13 2015-03-19 Qualcomm Incorporated Representation format signaling in multi-layer video coding
CN105723712B (zh) * 2013-10-14 2019-06-28 韩国电子通信研究院 基于多层的图像编码/解码方法和设备
WO2015104451A1 (en) * 2014-01-07 2015-07-16 Nokia Technologies Oy Method and apparatus for video coding and decoding
US20150264404A1 (en) * 2014-03-17 2015-09-17 Nokia Technologies Oy Method and apparatus for video coding and decoding
CN114554199B (zh) * 2014-09-30 2023-11-10 寰发股份有限公司 用于视频编码的自适应运动向量分辨率的方法
US9918105B2 (en) * 2014-10-07 2018-03-13 Qualcomm Incorporated Intra BC and inter unification
US10075712B2 (en) * 2014-11-20 2018-09-11 Hfi Innovation Inc. Method of motion vector and block vector resolution control
MX2017008774A (es) * 2014-12-31 2018-02-13 Nokia Technologies Oy Prediccion inter-capa para codificacion y decodificacion de video escalable.
US10148969B2 (en) * 2015-02-11 2018-12-04 Qualcomm Incorporated Of sample entry and operation point signalling in a layered video file format
US20160373771A1 (en) * 2015-06-18 2016-12-22 Qualcomm Incorporated Design of tracks and operation point signaling in layered hevc file format
WO2017052409A1 (en) * 2015-09-25 2017-03-30 Huawei Technologies Co., Ltd. Apparatus and method for video motion compensation with selectable interpolation filter
WO2018045108A1 (en) * 2016-09-02 2018-03-08 Vid Scale, Inc. Method and system for signaling of 360-degree video information
WO2018221368A1 (ja) 2017-05-31 2018-12-06 シャープ株式会社 動画像復号装置、及び動画像符号化装置
FR3073999B1 (fr) * 2017-11-23 2024-02-09 Ateme Compression intelligente de contenus video graines
CN108833916B (zh) * 2018-06-20 2021-09-24 腾讯科技（深圳）有限公司 视频编码、解码方法、装置、存储介质和计算机设备
US10764603B2 (en) * 2018-12-31 2020-09-01 Alibaba Group Holding Limited Resolution-adaptive video coding
JP2022530172A (ja) * 2019-03-11 2022-06-28 アリババ・グループ・ホールディング・リミテッド 適応解像度ビデオ符号化のためのインター符号化
US11399195B2 (en) * 2019-10-30 2022-07-26 Tencent America LLC Range of minimum coding block size in video coding

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
HENDRY, ET AI.: "On adaptive resolution change (ARC) for VVC", JOINT VIDEO EXPERTS TEAM (JVET) OF ITU-T SG 16 WP 3 AND ISO/IEC JTC 1/SC 29/WG 11, vol. JVET-M0135-v1, JPN6020040371, January 2019 (2019-01-01), pages 1 - 3, ISSN: 0004921424 *
MISKA M. HANNUKSELA, AND ALIREZA AMINLOU: "Use cases and proposed design choices for adaptive resolution changing (ARC)", JOINT VIDEO EXPERTS TEAM (JVET) OF ITU-T SG 16 WP 3 AND ISO/IEC JTC 1/SC 29/WG 11, vol. JVET-M0259, JPN6022038030, January 2019 (2019-01-01), pages 1 - 10, ISSN: 0004921425 *
PEISONG CHEN, ET AL.: "AHG 19: Adaptive Resolution Change", JOINT VIDEO EXPERTS TEAM (JVET) OF ITU-T SG 16 WP 3 AND ISO/IEC JTC 1/SC 29/WG 11, vol. JVET-N0279, JPN6020040370, March 2019 (2019-03-01), pages 1 - 7, ISSN: 0004921423 *
STEPHAN WENGER, BYEONGDOO CHOI, AND SHAN LIU: "[AHG19] On Signaling of Adaptive Resolution Change", JOINT VIDEO EXPERTS TEAM (JVET) OF ITU-T SG 16 WP 3 AND ISO/IEC JTC 1/SC 29/WG 11, vol. JVET-N0052, JPN6020040368, March 2019 (2019-03-01), pages 1 - 11, XP030202788, ISSN: 0004921422 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022546155A (ja) * 2019-07-09 2022-11-04 アリババ・グループ・ホールディング・リミテッド 解像度適応型ビデオコーディング
JP7539928B2 (ja) 2019-07-09 2024-08-26 アリババ・グループ・ホールディング・リミテッド 解像度適応型ビデオコーディング

Also Published As

Publication number Publication date
CN113875246A (zh) 2021-12-31
WO2020228692A1 (en) 2020-11-19
KR20220006048A (ko) 2022-01-14
US20220060712A1 (en) 2022-02-24
US11671602B2 (en) 2023-06-06
JP2023099077A (ja) 2023-07-11
CN113875250A (zh) 2021-12-31
JP7273193B2 (ja) 2023-05-12
JP7513796B2 (ja) 2024-07-09
US20230319284A1 (en) 2023-10-05
KR102653570B1 (ko) 2024-04-02
CN113875246B (zh) 2024-09-10
WO2020228691A1 (en) 2020-11-19
EP3954124A1 (en) 2022-02-16
EP3954124A4 (en) 2022-08-03

Similar Documents

Publication Publication Date Title
JP7513796B2 (ja) 参照ピクチャ再サンプリングのための信号通知
KR102627834B1 (ko) 비디오 프로세싱에서의 코딩 툴들의 선택적 사용
US11689747B2 (en) High level syntax for video coding tools
CN113826382B (zh) 视频编解码中的自适应比特深度转换
JP7391203B2 (ja) ビデオコーディングツールを洗練する使用およびシグナリング

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211110

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20211110

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220610

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20221115

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230213

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230328

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230427

R150 Certificate of patent or registration of utility model

Ref document number: 7273193

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150