[I.ビデオ符号化エンコーダ及びデコーダ]
図2は、本開示の一実施形態による通信システム(200)の簡略化したブロック図を示す。通信システム(200)は、例えば、ネットワーク(250)を介して互いに通信できる複数の端末デバイスを含む。例えば、通信システム(200)は、ネットワーク(250)を介して相互接続された第1の対の端末デバイス(210)及び(220)を含む。図2の例では、第1の対の端末デバイス(210)及び(220)は、データの一方向伝送を実行する。例えば、端末デバイス(210)は、ネットワーク(250)を介して他の端末デバイス(220)に送信するために、ビデオデータ(例えば、端末デバイス(210)によってキャプチャされたビデオピクチャのストリーム)を符号化してもよい。符号化されたビデオデータは、1つ以上の符号化ビデオビットストリームの形式で送信されてもよい。端末デバイス(220)は、ネットワーク(250)から符号化ビデオデータを受信し、符号化ビデオデータを復号して、ビデオピクチャを復元して復元されたビデオデータに従ってビデオピクチャを表示してもよい。一方向データ伝送は、メディア提供アプリケーション等において一般的でもよい。
他の例では、通信システム(200)は、例えば、テレビ会議中に発生し得る符号化ビデオデータの双方向伝送を実行する第2の対の端末デバイス(230)及び(240)を含む。データの双方向伝送のために、一例では、端末デバイス(230)及び(240)の各端末デバイスは、ネットワーク(250)を介して端末デバイス(230)及び(240)の他方の端末デバイスに送信するために、ビデオデータ(例えば、端末デバイスによってキャプチャされたビデオピクチャのストリーム)を符号化してもよい。また、端末デバイス(230)及び(240)の各端末デバイスは、端末デバイス(230)及び(240)の他方の端末デバイスによって送信された符号化ビデオデータを受信してもよく、符号化ビデオデータを復号してビデオピクチャを復元してもよく、復元されたビデオデータに従って、アクセス可能な表示デバイスにビデオピクチャを表示してもよい。
図2の例では、端末デバイス(210)、(220)、(230)及び(240)は、サーバ、パーソナルコンピュータ及びスマートフォンとして示されることがあるが、本開示の原理はこれらに限定されない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレイヤ及び/又は専用のテレビ会議機器に適用がある。ネットワーク(250)は、例えば、有線(配線接続)及び/又は無線通信ネットワークを含む、端末デバイス(210)、(220)、(230)及び(240)の間で符号化ビデオデータを伝達するいずれかの数のネットワークを表す。通信ネットワーク(250)は、回線交換チャネル及び/又はパケット交換チャネルにおいてデータを交換してもよい。代表的なネットワークは、電気通信ネットワーク、ローカルエリアネットワーク、広域ネットワーク及び/又はインターネットを含む。本説明の目的では、ネットワーク(250)のアーキテクチャ及びトポロジは、本明細書において以下に説明しない限り、本開示の動作には重要ではない。
図3は、開示の対象物のアプリケーションの例として、ストリーミング環境におけるビデオエンコーダ及びビデオデコーダの配置を示す。開示の対象物は、例えば、テレビ会議、デジタルTV、デジタルメディア(CD、DVD、メモリスティック等を含む)上の圧縮ビデオの記憶等を含む、他のビデオ可能なアプリケーションにも同様に適用可能である。
ストリーミングシステムはキャプチャサブシステム(313)を含んでもよく、当該キャプチャサブシステム(313)は、例えば、非圧縮のビデオピクチャのストリーム(302)を生成するビデオソース(301)(例えば、デジタルカメラ)を含んでもよい。一例では、ビデオピクチャのストリーム(302)は、デジタルカメラによって撮影されたサンプルを含む。符号化ビデオデータ(304)(又は符号化ビデオビットストリーム)と比較したときに高いデータ量であることを強調する太線として描かれるビデオピクチャのストリーム(302)は、ビデオソース(301)に結合されたビデオエンコーダ(303)を含む電子デバイス(320)によって処理されてもよい。ビデオエンコーダ(303)は、以下により詳細に説明するように、開示の対象物の態様を可能にするため或いは実装するために、ハードウェア、ソフトウェア又はこれらの組み合わせを含んでもよい。ビデオピクチャのストリーム(302)と比較したときにより低いデータ量であることを強調するために細線として描かれる符号化ビデオデータ(304)(又は符号化ビデオビットストリーム(304))は、将来の使用のためにストリーミングサーバ(305)に記憶されてもよい。図3におけるクライアントサブシステム(306)及び(308)のような1つ以上のストリーミングクライアントサブシステムは、ストリーミングサーバ(305)にアクセスして符号化ビデオデータ(304)のコピー(307)及び(309)を取得してもよい。クライアントサブシステム(306)は、例えば、電子デバイス(330)内にビデオデコーダ(310)を含んでもよい。ビデオデコーダ(310)は、符号化ビデオデータの入力コピー(307)を復号し、ディスプレイ(312)(例えば、表示画面)又は他のレンダリングデバイス(図示せず)上にレンダリングできるビデオピクチャの出力ストリーム(311)を生成する。いくつかのストリーミングシステムでは、符号化ビデオデータ(304)、(307)及び(309)(例えば、ビデオビットストリーム)は、特定のビデオ符号化/圧縮標準に従って符号化されてもよい。これらの標準の例は、ITU-T勧告H.265を含む。一例では、開発中のビデオ符号化標準は、VVCとして非公式に知られている。開示の対象物は、VVCの背景において使用されてもよい。
電子デバイス(320)及び(330)は、他の構成要素(図示せず)を含んでもよい点に留意すべきである。例えば、電子デバイス(320)は、ビデオデコーダ(図示せず)を含んでもよく、また、電子デバイス(330)は、ビデオエンコーダ(図示せず)を含んでもよい。
図4は、本開示の一実施形態によるビデオデコーダ(410)のブロック図を示す。ビデオデコーダ(410)は、電子デバイス(430)に含まれてもよい。電子デバイス(430)は、受信機(431)(例えば、受信回路)を含んでもよい。図3の例では、ビデオデコーダ(310)の代わりにビデオデコーダ(410)が使用されてもよい。
受信機(431)は、ビデオデコーダ(410)によって復号されるべき1つ以上の符号化ビデオシーケンスを受信してもよく、同一又は他の実施形態では、一度に1つの符号化ビデオシーケンスを受信してもよく、各符号化ビデオシーケンスの復号は、他の符号化ビデオシーケンスとは独立している。符号化ビデオシーケンスは、チャネル(401)から受信されてもよく、当該チャネルは、符号化ビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクでもよい。受信機(431)は、符号化ビデオデータを、他のデータ(例えば、符号化オーディオデータ及び/又は補助データストリーム)と共に受信してもよく、これらは、それぞれの使用エンティティ(図示せず)に転送されてもよい。受信機(431)は、符号化ビデオシーケンスを他のデータから分離してもよい。ネットワークジッタを防止するために、バッファメモリ(415)は、受信機(431)とエントロピーデコーダ/パーサ(420)(以下、「パーサ(420)」という)との間に結合されてもよい。特定のアプリケーションでは、バッファメモリ(415)はビデオデコーダ(410)の一部である。他の場合には、ビデオデコーダ(410)の外側にあってもよい(図示せず)。更に他の場合には、例えば、ネットワークジッタを防止するために、ビデオデコーダ(410)の外側にバッファメモリ(図示せず)が存在してもよく、加えて、例えば、再生タイミングに対処するために、ビデオデコーダ(410)の内側に他のバッファメモリ(415)が存在してもよい。受信機(431)が、十分な帯域幅及び制御可能性を有する記憶/転送デバイスから、或いは、アイソクロナスネットワークからデータを受信している場合、バッファメモリ(415)は必要なくてもよく或いは小さくすることができる。インターネットのようなベストエフォート型パケットネットワークでの使用については、バッファメモリ(415)が必要とされてもよく、比較的大きくすることができ、有利には適応的なサイズとすることができ、ビデオデコーダ(410)の外側のオペレーティングシステム又は同様の要素(図示せず)に少なくとも部分的に実装されてもよい。
ビデオデコーダ(410)は、符号化ビデオシーケンスからシンボル(421)を復元するためのパーサ(420)を含んでもよい。これらのシンボルのカテゴリは、ビデオデコーダ(410)の動作を管理するために使用される情報を含み、レンダリングデバイス(412)(例えば、表示画面)のようなレンダリングデバイスを制御するための情報を潜在的に含む。当該レンダリングデバイス(412)は、図4に示されているように、電子デバイス(430)の一体的な部分ではないが、電子デバイス(430)に結合されてもよい。レンダリングデバイスの制御情報は、補足エンハンスメント情報(SEI, Supplemental Enhancement Information)(SEIメッセージ)又はビデオユーザビリティ情報(VUI, Video Usability Information)パラメータセットフラグメント(図示せず)の形式でもよい。パーサ(420)は、受信した符号化ビデオシーケンスを解析/エントロピー復号してもよい。符号化ビデオシーケンスの符号化は、ビデオ符号化技術又は標準に従ってもよく、可変長符号化、ハフマン符号化、コンテキスト感度を伴う或いは伴わない算術符号化等を含む様々な原理に従ってもよい。パーサ(420)は、グループに対応する少なくとも1つのパラメータに基づいて、符号化ビデオシーケンスから、ビデオデコーダ内の画素のサブグループのうち少なくとも1つについてのサブグループパラメータのセットを抽出してもよい。サブグループは、グループオブピクチャ(GOP, Group of Picture)、ピクチャ、タイル、スライス、マクロブロック、符号化ユニット(CU, Coding Unit)、ブロック、変換ユニット(TU, Transformation Unit)、予測ユニット(PU, Prediction Unit)等を含んでもよい。また、パーサ(420)は、符号化ビデオシーケンスから、変換係数、量子化パラメータ値、動きベクトル等のような情報を抽出してもよい。
パーサ(420)は、シンボル(421)を生成するために、バッファメモリ(415)から受信したビデオシーケンスに対してエントロピー復号/解析動作を実行してもよい。
シンボル(421)の復元には、符号化ビデオピクチャ又はその部分のタイプ(例えば、インターピクチャ及びイントラピクチャ、インターブロック及びイントラブロック)及び他の要因に依存して、複数の異なるユニットが関与してもよい。どのユニットがどのように関与するかは、パーサ(420)によって符号化ビデオシーケンスから解析されたサブグループ制御情報によって制御されてもよい。パーサ(420)と以下の複数ユニットとの間のこのようなサブグループ制御情報の流れは、明確にするために図示されていない。
上記の機能ブロックの他に、ビデオデコーダ(410)は、概念的に、以下に説明するような複数の機能ユニットに細分されてもよい。商用的な制約の下で動作する実用的な実装では、これらのユニットの多くは互いに密接に相互作用し、少なくとも部分的に互いに統合されてもよい。しかし、開示の対象物を説明する目的で、以下の機能ユニットに概念的に細分することが適切である。
第1のユニットは、スケーラ/逆変換ユニット(451)である。スケーラ/逆変換ユニット(451)は、パーサ(420)からシンボル(421)として、制御情報(どの変換を使用するべきか、ブロックサイズ、量子化係数、量子化スケーリング行列等を含む)と共に、量子化された変換係数を受信する。スケーラ/逆変換ユニット(451)は、アグリゲータ(455)に入力できるサンプル値を含むブロックを出力してもよい。
場合によっては、スケーラ/逆変換(451)の出力サンプルは、イントラ符号化ブロックに関連してもよく、すなわち、前に復元されたピクチャからの予測情報を使用していないが、カレントピクチャの前に復元された部分からの予測情報を使用できるブロックに関連してもよい。このような予測情報は、イントラピクチャ予測ユニット(452)によって提供されてもよい。場合によっては、イントラピクチャ予測ユニット(452)は、カレントピクチャバッファ(458)から取り出された周囲の既に復元された情報を使用して、復元中のブロックの同じサイズ及び形状のブロックを生成する。カレントピクチャバッファ(458)は、例えば、部分的に復元されたカレントピクチャ及び/又は完全に復元されたカレントピクチャをバッファする。場合によっては、アグリゲータ(455)は、サンプル毎に、イントラ予測ユニット(452)が生成した予測情報を、スケーラ/逆変換ユニット(451)によって提供された出力サンプル情報に追加する。
他の場合には、スケーラ/逆変換ユニット(451)の出力サンプルは、インター符号化されて潜在的に動き補償されたブロックに関連してもよい。このような場合、動き補償予測ユニット(453)は、参照ピクチャメモリ(457)にアクセスして、予測に使用されるサンプルを取り出してもよい。ブロックに関連するシンボル(421)に従って、取り出されたサンプルを動き補償した後に、これらのサンプルは、出力サンプル情報を生成するために、アグリゲータ(455)によってスケーラ/逆変換ユニット(451)の出力(この場合には、残差サンプル又は残差信号と呼ばれる)に追加されてもよい。動き補償予測ユニット(453)に利用可能な、動き補償予測ユニット(453)が予測サンプルを取り出す参照ピクチャメモリ(457)内のアドレスは、例えば、X、Y及び参照ピクチャ成分を有することができるシンボル(421)の形式で、動きベクトルによって制御されてもよい。また、動き補償は、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリ(457)から取り出されるサンプル値の補間、動きベクトル予測メカニズム等を含んでもよい。
アグリゲータ(455)の出力サンプルは、ループフィルタユニット(456)内の様々なループフィルタリング技術を受けてもよい。ビデオ圧縮技術はループ内フィルタ技術を含んでもよく、当該ループ内フィルタ技術は、符号化ビデオシーケンス(符号化ビデオビットストリームとも呼ばれる)に含まれるパラメータによって制御され、パーサ(420)からシンボル(421)としてループフィルタユニット(456)に利用可能にされるが、符号化ピクチャ又は符号化ビデオシーケンスの(復号順に)前の部分の復号の間に取得されたメタ情報に応答すると共に、前に復元されてループフィルタリングされたサンプル値にも応答してもよい。
ループフィルタユニット(456)の出力はサンプルストリームでもよく、当該サンプルストリームは、レンダリングデバイス(412)に出力されると共に、将来のインターピクチャ予測に使用するために参照ピクチャメモリ(457)に記憶されてもよい。
特定の符号化ピクチャは、完全に復元されると、将来の予測のための参照ピクチャとして使用されてもよい。例えば、カレントピクチャに対応する符号化ピクチャが完全に復元され、符号化ピクチャが(例えば、パーサ(420)によって)参照ピクチャとして識別されると、カレントピクチャバッファ(458)は参照ピクチャメモリ(457)の一部となってもよく、新たなカレントピクチャバッファが、後続の符号化ピクチャの復元を開始する前に再割り当てされてもよい。
ビデオデコーダ(410)は、ITU-T Rec. H.265のような標準における所定のビデオ圧縮技術に従って復号動作を実行してもよい。符号化ビデオシーケンスがビデオ圧縮技術又は標準のシンタックス及びビデオ圧縮技術又は標準に文書化されているプロファイルの双方に従うという意味で、符号化ビデオシーケンスは、使用されているビデオ圧縮技術又は標準によって指定されたシンタックスに適合してもよい。具体的には、プロファイルは、ビデオ圧縮技術又は標準で利用可能な全てのツールから特定のツールを、そのプロファイルで使用するのに利用可能な唯一のツールとして選択してもよい。また、コンプライアンスのために必要なことは、符号化ビデオシーケンスの複雑さが、ビデオ圧縮技術又は標準のレベルによって定義される範囲内にあることである。場合によっては、レベルは、最大ピクチャサイズ、最大フレームレート、最大復元サンプルレート(例えば、毎秒当たりのメガサンプル単位で測定される)、最大参照ピクチャサイズ等を制限する。場合によっては、レベルによって設定される制限は、仮想参照デコーダ(HRD, Hypothetical Reference Decoder)仕様及び符号化ビデオシーケンスで伝達されるHRDバッファ管理についてのメタデータを通じて更に制限されてもよい。
一実施形態では、受信機(431)は、符号化ビデオと共に更なる(冗長な)データを受信してもよい。更なるデータは、符号化ビデオシーケンスの一部として含まれてもよい。更なるデータは、データを適切に復号するために、及び/又は元のビデオデータをより正確に復元するために、ビデオデコーダ(410)によって使用されてもよい。更なるデータは、例えば、時間、空間又は信号雑音比(SNR, signal noise ratio)エンハンスメント層、冗長スライス、冗長ピクチャ、前方誤り訂正コード等の形式でもよい。
図5は、本開示の一実施形態によるビデオエンコーダ(503)のブロック図を示す。ビデオエンコーダ(503)は、電子デバイス(520)に含まれる。電子デバイス(520)は、送信機(540)(例えば、送信回路)を含む。図3の例では、ビデオエンコーダ(303)の代わりにビデオエンコーダ(503)が使用されてもよい。
ビデオエンコーダ(503)は、ビデオソース(501)(図5の例では電子デバイス(520)の一部ではない)からビデオサンプルを受信してもよく、当該ビデオソース(501)は、ビデオエンコーダ(503)によって符号化されるべきビデオ画像をキャプチャしてもよい。他の例では、ビデオソース(501)は電子デバイス(520)の一部である。
ビデオソース(501)は、デジタルビデオサンプルストリームの形式でビデオエンコーダ(503)によって符号化されるべきソースビデオシーケンスを提供してもよく、当該デジタルビデオサンプルストリームは、いずれかの適切なビット深度(例えば、8ビット、10ビット、12ビット等)、いずれかの色空間(例えば、BT.601 Y CrCB、RGB等)及びいずれかの適切なサンプリング構造(例えば、Y CrCb 4:2:0、Y CrCb 4:4:4)でもよい。メディア提供システムにおいて、ビデオソース(501)は、事前に準備されたビデオを記憶する記憶デバイスでもよい。テレビ会議システムでは、ビデオソース(501)は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラでもよい。ビデオデータは、順に見たときに動きを伝える複数の個々のピクチャとして提供されてもよい。ピクチャ自体は、画素の空間配列として構成されてもよく、各画素は、使用中のサンプリング構造、色空間等に依存して、1つ以上のサンプルを含んでもよい。当業者は、画素とサンプルとの関係を容易に理解することができる。以下の説明は、サンプルに焦点を当てる。
一実施形態によれば、ビデオエンコーダ(503)は、リアルタイムで或いはアプリケーションによって要求されるいずれかの他の時間制約下で、ソースビデオシーケンスのピクチャを、符号化ビデオシーケンス(543)に符号化及び圧縮してもよい。適切な符号化速度を実現することは、コントローラ(550)の1つの機能である。いくつかの実施形態では、コントローラ(550)は、以下に説明するように、他の機能ユニットを制御し、他の機能ユニットに機能的に結合される。結合は、明確にするために図示されていない。コントローラ(550)によって設定されるパラメータは、レート制御関連パラメータ(ピクチャスキップ、量子化、レート歪み最適化技術のラムダ値等)、ピクチャサイズ、グループオブピクチャ(GOP)のレイアウト、最大動きベクトル探索範囲等を含んでもよい。コントローラ(550)は、特定のシステム設計のために最適化されたビデオエンコーダ(503)に関連する他の適切な機能を有するように構成されてもよい。
いくつかの実施形態では、ビデオエンコーダ(503)は、符号化ループで動作するように構成される。非常に簡略化した説明として、一例では、符号化ループは、ソースコーダ(530)(例えば、符号化されるべき入力ピクチャ及び参照ピクチャに基づいて、シンボルストリームのようなシンボルを生成することを担う)と、ビデオエンコーダ(503)に埋め込まれた(ローカル)デコーダ(533)とを含んでもよい。デコーダ(533)は、(リモート)デコーダが生成するのと同様に(シンボルと符号化ビデオビットストリームとの間のいずれかの圧縮が、開示の対象物において検討されるビデオ圧縮技術において可逆であるように)、サンプルデータを生成するようにシンボルを復元する。復元されたサンプルストリーム(サンプルデータ)は、参照ピクチャメモリ(534)に入力される。シンボルストリームの復号は、デコーダの位置(ローカル又はリモート)と独立したビット単位の正確な結果をもたらすので、参照ピクチャメモリ(534)内の内容も、ローカルエンコーダとリモートエンコーダとの間でビット単位で正確である。言い換えると、エンコーダの予測部分は、デコーダが復号中に予測を使用するときに「見る」のと全く同じサンプル値を参照ピクチャサンプルとして「見る」。参照ピクチャの同期(例えば、チャネルエラーの理由で同期が維持できない場合の結果として生じるドリフトを含む)のこの基本原理は、いくつかの関連技術においても同様に使用される。
「ローカル」デコーダ(533)の動作は、ビデオデコーダ(410)のような「リモート」デコーダと同じでもよく、これは、図4に関連して上記において既に詳細に説明した。しかし、図4を簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ(545)及びパーサ(420)による符号化ビデオシーケンスへのシンボルの符号化/復号が可逆になり得るので、バッファメモリ(415)及びパーサ(420)を含むビデオデコーダ(410)のエントロピー復号部分は、ローカルデコーダ(533)に完全には実装されなくてもよい。
この時点で行うことができる考察は、デコーダ内に存在する解析/エントロピー復号を除く如何なるデコーダ技術も、必然的に対応するエンコーダ内に実質的に同一の機能形式で存在する必要があることである。このため、開示の対象物はデコーダ動作に焦点を当てる。エンコーダ技術の説明は、包括的に記載されるデコーダ技術の逆であるので、省略できる。特定の領域においてのみ、より詳細な説明が必要であり、以下に提供される。
いくつかの例では、動作中に、ソースコーダ(530)は、動き補償予測符号化を実行してもよく、当該動き補償予測符号化は、「参照ピクチャ」として指定されたビデオシーケンスからの1つ以上の前に符号化されたピクチャを参照して入力ピクチャを予測的に符号化する。このように、符号化エンジン(532)は、入力ピクチャの画素ブロックと、入力ピクチャに対する予測参照として選択され得る参照ピクチャの画素ブロックとの間の差を符号化する。
ローカルビデオデコーダ(533)は、ソースコーダ(530)によって生成されたシンボルに基づいて、参照ピクチャとして指定され得るピクチャの符号化ビデオデータを復号してもよい。符号化エンジン(532)の動作は、有利には、不可逆処理でもよい。符号化ビデオデータがビデオデコーダ(図5に図示せず)で復号され得る場合、復元されたビデオシーケンスは、典型的には、いくつかのエラーを伴うソースビデオシーケンスのレプリカになり得る。ローカルビデオデコーダ(533)は、参照ピクチャに対してビデオデコーダによって実行され得る復号処理を複製し、復元された参照ピクチャを参照ピクチャキャッシュ(534)に記憶させてもよい。このように、ビデオエンコーダ(503)は、遠端のビデオデコーダによって取得される(送信エラーのない)復元された参照ピクチャとして、共通の内容を有する復元された参照ピクチャのコピーをローカルに記憶してもよい。
予測器(535)は、符号化エンジン(532)のための予測探索を実行してもよい。すなわち、符号化されるべき新たなピクチャについて、予測器(535)は、(候補参照画素ブロックとしての)サンプルデータ又は特定のメタデータ(参照ピクチャ動きベクトル、ブロック形状等)を求めて参照ピクチャメモリ(534)を検索してもよい。これらは、新たなピクチャについての適切な予測参照として機能してもよい。予測器(535)は、適切な予測参照を検出するために、サンプルブロック毎画素ブロック毎(sample block-by-pixel block)に動作してもよい。場合によっては、予測器(535)によって取得された検索結果によって決定された入力ピクチャは、参照ピクチャメモリ(534)に記憶された複数の参照ピクチャから引き出された予測参照を有してもよい。
コントローラ(550)は、例えば、ビデオデータを符号化するために使用されるパラメータ及びサブグループパラメータの設定を含む、ソースコーダ(530)の符号化動作を管理してもよい。
全ての上記の機能ユニットの出力は、エントロピーコーダ(545)におけるエントロピー符号化を受けてもよい。エントロピーコーダ(545)は、ハフマン符号化、可変長符号化、算術符号化等のような技術に従って、シンボルを可逆圧縮することによって、様々な機能ユニットによって生成されたシンボルを符号化ビデオシーケンスに変換する。
送信機(540)は、エントロピーコーダ(545)によって生成された符号化ビデオシーケンスをバッファして、通信チャネル(560)を介した送信の準備をしてもよく、当該通信チャネル(560)は、符号化ビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクでもよい。送信機(540)は、ビデオコーダ(503)からの符号化ビデオデータを、送信されるべき他のデータ(例えば、符号化オーディオデータ及び/又は補助データストリーム(図示せず))とマージしてもよい。
コントローラ(550)は、ビデオエンコーダ(503)の動作を管理してもよい。符号化中に、コントローラ(550)は、各符号化ピクチャに、特定の符号化ピクチャタイプを割り当ててもよい。当該符号化ピクチャタイプは、各ピクチャに適用され得る符号化技術に影響を与えてもよい。例えば、ピクチャは、しばしば、以下のピクチャタイプのうち1つとして割り当てられてもよい。
イントラピクチャ(Iピクチャ)は、予測のソースとしてシーケンス内の他のピクチャを使用せずに、符号化及び復号され得るものでもよい。いくつかのビデオコーデックは、例えば、独立デコーダリフレッシュ(IDR, Independent Decoder Refresh)ピクチャを含む、異なるタイプのイントラピクチャを許容する。当業者は、Iピクチャのこれらの変形例と、それぞれの用途及び特徴を認識する。
予測ピクチャ(Pピクチャ)は、各ブロックのサンプル値を予測するために、最大で1つの動きベクトル及び参照インデックスを使用して、イントラ予測又はインター予測を使用して符号化及び復号され得るものでもよい。
双方向予測ピクチャ(Bピクチャ)は、各ブロックのサンプル値を予測するために、最大で2つの動きベクトル及び参照インデックスを使用して、イントラ予測又はインター予測を使用して符号化及び復号され得るものでもよい。同様に、複数の予測ピクチャは、単一のブロックの復元のために、2つより多くの参照ピクチャ及び関連するメタデータを使用してもよい。
一般的に、ソースピクチャは、空間的に複数のサンプルブロック(例えば、それぞれ4×4、8×8、4×8又は16×16のサンプルのブロック)に細分され、ブロック毎に符号化されてもよい。ブロックは、ブロックのそれぞれのピクチャに適用される符号化割り当てによって決定される通り、他の(既に符号化された)ブロックを参照して予測的に符号化されてもよい。例えば、Iピクチャのブロックは、非予測的に符号化されてもよく、或いは、同じピクチャの既に符号化されたブロックを参照して予測的に符号化されてもよい(空間予測又はイントラ予測)。Pピクチャの画素ブロックは、1つ前に符号化された参照ピクチャを参照して、空間予測又は時間予測を介して予測的に符号化されてもよい。Bピクチャのブロックは、1つ又は2つ前に符号化された参照ピクチャを参照して、空間予測又は時間予測を介して予測的に符号化されてもよい。
ビデオエンコーダ(503)は、ITU-T Rec. H.265のような所定のビデオ符号化技術又は標準に従って符号化動作を実行してもよい。その動作において、ビデオエンコーダ(503)は、入力ビデオシーケンスにおける時間的及び空間的冗長性を利用する予測符号化動作を含む様々な圧縮動作を実行してもよい。したがって、符号化ビデオデータは、使用されているビデオ符号化技術又は標準によって指定されたシンタックスに適合してもよい。
一実施形態では、送信機(540)は、符号化ビデオと共に更なるデータを送信してもよい。ソースコーダ(530)は、符号化ビデオシーケンスの一部としてこのようなデータを含んでもよい。更なるデータは、時間/空間/SNRエンハンスメント層、冗長ピクチャ及びスライス、SEIメッセージ、VUIパラメータセットフラグメント等のような他の形式の冗長データを含んでもよい。
ビデオは、時系列において複数のソースピクチャ(ビデオピクチャ)としてキャプチャされてもよい。イントラピクチャ予測(しばしばイントラ予測と略される)は、所与のピクチャ内の空間的相関を利用し、インターピクチャ予測は、ピクチャ間の(時間的又は他の)相関を利用する。一例では、カレントピクチャと呼ばれる符号化/復号中の特定のピクチャは、ブロックに分割される。カレントピクチャ内のブロックがビデオにおける前に符号化されて依然としてバッファされている参照ピクチャ内の参照ブロックに類似する場合、カレントピクチャ内のブロックは、動きベクトルと呼ばれるベクトルによって符号化されてもよい。動きベクトルは、参照ピクチャ内の参照ブロックを指し、複数の参照ピクチャが使用されている場合には、参照ピクチャを識別する第3の次元を有してもよい。
いくつかの実施形態では、双方向予測技術は、インターピクチャ予測において使用されてもよい。双方向予測技術によれば、ビデオにおけるカレントピクチャへの復号順で双方とも先行する(しかし、表示順ではそれぞれ過去及び将来のものでもよい)第1の参照ピクチャ及び第2の参照ピクチャのような2つの参照ピクチャが使用される。カレントピクチャ内のブロックは、第1の参照ピクチャ内の第1の参照ブロックを指す第1の動きベクトルと、第2の参照ピクチャ内の第2の参照ブロックを指す第2の動きベクトルとによって符号化されてもよい。ブロックは、第1の参照ブロックと第2の参照ブロックとの組み合わせによって予測されてもよい。
さらに、符号化効率を改善するために、インターピクチャ予測においてマージモード技術が使用できる。
本開示のいくつかの実施形態によれば、インターピクチャ予測及びイントラピクチャ予測のような予測は、ブロックの単位で実行される。例えば、HEVC標準によれば、ビデオピクチャのシーケンス内のピクチャは、圧縮のために符号化ツリーユニット(CTU, coding tree unit)に分割され、ピクチャ内のCTUは、64×64の画素、32×32の画素又は16×16の画素のように、同じサイズを有する。一般的に、CTUは、1つの輝度CTBと2つの色差CTBである3つの符号化ツリーブロック(CTB, coding tree block)を含む。各CTUは、1つ又は複数の符号化ユニット(CU, coding unit)に再帰的に四分木分割されてもよい。例えば、64×64の画素のCTUは、64×64の画素の1つのCU、32×32の画素の4つのCU又は16×16の画素の16個のCUに分割できる。一例では、各CUは、インター予測タイプ又はイントラ予測タイプのようなCUの予測タイプを決定するために分析される。CUは、時間的及び/又は空間的予測可能性に依存して1つ以上の予測ユニット(PU, prediction unit)に分割される。一般的に、各PUは、輝度予測ブロック(PB, prediction block)と2つの色差PBとを含む。一実施形態では、符号化(符号化/復号)における予測動作は、予測ブロックの単位で実行される。予測ブロックの一例として輝度予測ブロックを使用すると、予測ブロックは、8×8の画素、16×16の画素、8×16の画素、16×8の画素等のように、画素の値(例えば、輝度値)の行列を含む。
図6は、本開示の他の実施形態によるビデオエンコーダ(603)の図を示す。ビデオエンコーダ(603)は、ビデオピクチャのシーケンス内のカレントビデオピクチャ内のサンプル値の処理ブロック(例えば、予測ブロック)を受信し、処理ブロックを符号化ビデオシーケンスの一部である符号化ピクチャに符号化するように構成される。一例では、ビデオエンコーダ(603)は、図3の例のビデオエンコーダ(303)の代わりに使用される。
HEVCの例では、ビデオエンコーダ(603)は、8×8のサンプルの予測ブロック等のような処理ブロックのサンプル値の行列を受信する。ビデオエンコーダ(603)は、処理ブロックが、例えば、レート歪み最適化を使用して、イントラモードを使用して最も良く符号化されるか、インターモードを使用して最も良く符号化されるか、双方向予測モードを使用して最も良く符号化されるかを決定する。処理ブロックがイントラモードで符号化される場合、ビデオエンコーダ(603)は、処理ブロックを符号化ピクチャに符号化するためにイントラ予測技術を使用してもよい。処理ブロックがインターモード又は双方向予測モードで符号化される場合、ビデオエンコーダ(603)は、処理ブロックを符号化ピクチャに符号化するために、それぞれインター予測技術又は双方向予測技術を使用してもよい。特定のビデオ符号化技術では、マージモード(merge mode)は、動きベクトル予測子以外の符号化された動きベクトル成分の恩恵を受けずに、動きベクトルが1つ以上の動きベクトル予測子から導出されるインターピクチャ予測サブモードでもよい。特定の他のビデオ符号化技術では、対象のブロックに適用可能な動きベクトル成分が存在してもよい。一例では、ビデオエンコーダ(603)は、処理ブロックのモードを決定するためのモード決定モジュール(図示せず)のような他の構成要素を含む。
図6の例では、ビデオエンコーダ(603)は、図6に示されるように共に結合されたインターエンコーダ(630)と、イントラエンコーダ(622)と、残差計算器(623)と、スイッチ(626)と、残差エンコーダ(624)と、全体コントローラ(621)と、エントロピーエンコーダ(625)とを含む。
インターエンコーダ(630)は、カレントブロック(例えば、処理ブロック)のサンプルを受信し、当該ブロックを参照ピクチャ内の1つ以上の参照ブロック(例えば、前のピクチャ及び後のピクチャ内のブロック)と比較し、インター予測情報(例えば、インター符号化技術による冗長情報の記述、動きベクトル、マージモード情報)を生成し、いずれかの適切な技術を使用して、インター予測情報に基づいてインター予測結果(例えば、予測ブロック)を計算するように構成される。いくつかの例では、参照ピクチャは、符号化ビデオ情報に基づいて復号された復号参照ピクチャである。
イントラエンコーダ(622)は、カレントブロック(例えば、処理ブロック)のサンプルを受信し、場合によっては、当該ブロックを、同じピクチャ内で既に符号化されたブロックと比較し、変換後に量子化係数を生成し、場合によっては、イントラ予測情報(例えば、1つ以上のイントラ符号化技術によるイントラ予測方向情報)も生成するように構成される。また、一例では、イントラエンコーダ(622)は、同じピクチャ内のイントラ予測情報及び参照ブロックに基づいて、イントラ予測結果(例えば、予測ブロック)を計算する。
全体コントローラ(621)は、全体制御データを決定し、全体制御データに基づいてビデオエンコーダ(603)の他の構成要素を制御するように構成される。一例では、全体コントローラ(621)は、ブロックのモードを決定し、当該モードに基づいて制御信号をスイッチ(626)に提供する。例えば、モードがイントラモードである場合、全体コントローラ(621)は、残差計算器(623)によって使用されるイントラモード結果を選択するようにスイッチ(626)を制御し、イントラ予測情報を選択してイントラ予測情報をビットストリームに含めるようにエントロピーエンコーダ(625)を制御する。モードがインターモードである場合、全体コントローラ(621)は、残差計算器(623)によって使用されるインター予測結果を選択するようにスイッチ(626)を制御し、インター予測情報を選択してインター予測情報をビットストリームに含めるようにエントロピーエンコーダ(625)を制御する。
残差計算器(623)は、受信したブロックと、イントラエンコーダ(622)又はインターエンコーダ(630)から選択された予測結果との差(残差データ)を計算するように構成される。残差エンコーダ(624)は、残差データに基づいて動作し、残差データを符号化して変換係数を生成するように構成される。一例では、残差エンコーダ(624)は、残差データを空間ドメインから周波数ドメインに変換し、変換係数を生成するように構成される。次いで、変換係数は、量子化された変換係数を取得するための量子化処理を受ける。また、様々な実施形態では、ビデオエンコーダ(603)は、残差デコーダ(628)も含む。残差デコーダ(628)は、逆変換を実行し、復号された残差データを生成するように構成される。復号された残差データは、イントラエンコーダ(622)及びインターエンコーダ(630)によって適切に使用されてもよい。例えば、インターエンコーダ(630)は、復号された残差データ及びインター予測情報に基づいて復号ブロックを生成してもよく、イントラエンコーダ(622)は、復号された残差データ及びイントラ予測情報に基づいて復号ブロックを生成してもよい。復号ブロックは、復号ピクチャを生成するように適切に処理され、復号ピクチャは、メモリ回路(図示せず)にバッファされ、いくつかの例では参照ピクチャとして使用されてもよい。
エントロピーエンコーダ(625)は、符号化ブロックを含めるようにビットストリームをフォーマットするように構成される。エントロピーエンコーダ(625)は、HEVC標準のような適切な標準に従った様々な情報を含めるように構成される。一例では、エントロピーエンコーダ(625)は、全体制御データと、選択された予測情報(例えば、イントラ予測情報又はインター予測情報)と、残差情報と、他の適切な情報とをビットストリームに含めるように構成される。開示の対象物によれば、インターモード又は双方向予測モードのいずれかのマージサブモードでブロックを符号化する場合、残差情報は存在しない点に留意すべきである。
図7は、本開示の他の実施形態によるビデオデコーダ(710)の図を示す。ビデオデコーダ(710)は、符号化ビデオシーケンスの一部である符号化ピクチャを受信し、符号化ピクチャを復号して復元ピクチャを生成するように構成される。一例では、ビデオデコーダ(710)は、図3の例のビデオデコーダ(310)の代わりに使用される。
図7の例では、ビデオデコーダ(710)は、図7に示されるように共に結合されたエントロピーデコーダ(771)と、インターデコーダ(780)と、残差デコーダ(773)と、復元モジュール(774)と、イントラデコーダ(772)とを含む。
エントロピーデコーダ(771)は、符号化ピクチャから、当該符号化ピクチャが構成されるシンタックスエレメントを表す特定のシンボルを復元するように構成されてもよい。このようなシンボルは、例えば、ブロックが符号化されるモード(例えば、イントラモード、インターモード、双方向予測モード、マージサブモード又は他のサブモードにおける後者の2つ等)、それぞれイントラデコーダ(772)又はインターデコーダ(780)によって予測のために使用される特定のサンプル又はメタデータを識別できる予測情報(例えば、イントラ予測情報又はインター予測情報等)、例えば、量子化された変換係数の形式の残差情報等を含んでもよい。一例では、予測モードがインターモード又は双方向予測モードである場合、インター予測情報はインターデコーダ(780)に提供され、予測タイプがイントラ予測タイプである場合には、イントラ予測情報がイントラデコーダ(772)に提供される。残差情報は、逆量子化を受けてもよく、残差デコーダ(773)に提供される。
インターデコーダ(780)は、インター予測情報を受信し、インター予測情報に基づいてインター予測結果を生成するように構成される。
イントラデコーダ(772)は、イントラ予測情報を受信し、イントラ予測情報に基づいて予測結果を生成するように構成される。
残差デコーダ(773)は、逆量子化された変換係数を抽出するための逆量子化を実行し、逆量子化された変換係数を処理して残差を周波数ドメインから空間ドメインに変換するように構成される。また、残差デコーダ(773)は、特定の制御情報(量子化パラメータ(QP, Quantizer Parameter)を含む)を必要としてもよく、その情報は、エントロピーデコーダ(771)によって提供されてもよい(これは低ボリュームの制御情報のみである可能性があるので、データ経路は図示されていない)。
復元モジュール(774)は、空間ドメインにおいて、残差デコーダ(773)によって出力された残差と、予測結果(場合によっては、インター予測モジュール又はイントラ予測モジュールによって出力されたもの)とを結合して復元ブロックを形成するように構成され、当該復元ブロックは、復元ピクチャの一部でもよく、また、復元ビデオの一部でもよい。視覚品質を改善するために、デブッキング動作のような他の適切な動作が実行されてもよい点に留意すべきである。
ビデオエンコーダ(303)、(503)及び(603)並びにビデオデコーダ(310)、(410)及び(710)は、いずれかの適切な技術を使用して実装されてもよい点に留意すべきである。一実施形態では、ビデオエンコーダ(303)、(503)及び(603)並びにビデオデコーダ(310)、(410)及び(710)は、1つ以上の集積回路を使用して実装されてもよい。他の実施形態では、ビデオエンコーダ(303)、(503)及び(603)並びにビデオデコーダ(310)、(410)及び(710)は、ソフトウェア命令を実行する1つ以上のプロセッサを使用して実装されてもよい。
[II.インターピクチャ予測モード]
様々な実施形態では、例えば、ツリー構造ベースの分割方式を使用して、ピクチャがブロックに分割されてもよい。次いで、結果のブロックは、イントラ予測モード、インター予測モード(例えば、マージモード、スキップモード、高度動きベクトル予測(AMVP, advanced motion vector prediction)モード)等のような異なる処理モードで処理されてもよい。イントラ符号化ブロックは、イントラ予測モードで符号化されるブロックとすることができる。同様に、インター符号化ブロックは、インター予測モードで処理されるブロックとすることができる。
[1.通常のマージモード]
カレントブロックと呼ばれる現在処理されているブロックがマージモードで処理される場合、隣接ブロックがカレントブロックの空間又は時間隣接から選択されてもよい。カレントブロックは、選択された隣接ブロックからの同じのセットの動きデータ(或いは動き情報と呼ばれる)を共有することによって、選択された隣接ブロックとマージされてもよい。このマージモード動作は、隣接ブロックのグループ上で実行されてもよく、それにより、隣接ブロックの領域が一緒にマージされて、同じセットの動きデータを共有することができる。エンコーダからデコーダへの送信中に、選択された隣接ブロックの動きデータを示すインデックスが、全体のセットの動きデータを送信する代わりに、カレントブロックについて送信されてもよい。このように、動き情報の伝送のためのデータ量(ビット)が低減でき、符号化効率が改善できる。
上記の例では、動きデータを提供する隣接ブロックは、候補位置のセットから選択されてもよい。候補位置は、カレントブロックに対して予め定義されてもよい。例えば、候補位置は空間候補位置及び時間候補位置を含んでもよい。各空間候補位置は、カレントブロックに隣接する空間隣接ブロックに関連付けられる。各時間候補位置は、前に符号化されたピクチャである参照ピクチャに位置する時間隣接ブロックに関連付けられる。候補位置に重なる隣接ブロック(候補ブロックと呼ばれる)は、カレントブロックの全ての空間又は時間隣接ブロックのサブセットである。このように、候補ブロックは、全体のセットの隣接ブロックではなく、マージ対象のブロックを選択するために評価されてもよい。
図8は、候補位置の例を示す。これらの候補位置から、カレントピクチャ(830)内のカレントブロック(810)についてのマージ候補リストを構築するために、マージ候補のセットが選択されてもよい。カレントブロック(810)は、マージモードで処理されるものである。マージモード処理について、候補位置のセット{A1,B1,B0,A0,B2,C0,C1}が予め定義される。具体的には、候補位置{A1,B1,B0,A0,B2}は、カレントブロック(810)と同じピクチャ内にある候補ブロックの位置を表す空間候補位置である。候補位置{C0,C1}は、参照ピクチャ(840)内にあり且つカレントブロック(810)の同一位置のブロック(820)に隣接するか或いは重なる候補ブロックの位置を表す時間候補位置である。図8に示すように、候補位置C0は、同一位置のブロック(820)の右下角に隣接して位置してもよく、候補位置C1は、同一位置のブロック(820)の中心に隣接して位置してもよい。
異なる例では、候補位置はサンプルのブロック又はサンプルによって表されてもよい。図8において、各候補位置は、例えば4×4のサンプルのサイズを有するサンプルのブロックによって表される。候補位置に対応するこのようなサンプルのブロックのサイズは、カレントブロック(810)を生成するために使用されるツリーベースの分割方式について定義されるPBの最小許容サイズ(例えば、4×4のサンプル)以下でもよい。このような構成では、候補位置に対応するブロックは常に単一の隣接PB内でカバーされてもよい。他の例では、サンプル位置(例えば、ブロックA1内の右下のサンプル、又はブロックA0内の右上のサンプル)が、候補位置を表すために使用されてもよい。このようなサンプルは代表サンプルと呼ばれ、このような位置は代表位置と呼ばれる。
一例では、図8で定義された候補位置{A1,B1,B0,A0,B2,C0,C1}に基づいて、候補位置{A1,B1,B0,A0,B2,C0,C1}からマージ候補を選択して候補リストを構成するために、マージモード処理が実行されてもよい。候補リストは、Cmとして表される所定の最大数のマージ候補を有することができる。候補リスト内の各マージ候補は、動き補償予測に使用できる動きデータのセットを含んでもよい。
マージ候補は、特定の順序に従って候補リストにリストされてもよい。例えば、どのようにマージ候補が導出されるかに応じて、異なるマージ候補は、選択される確率が異なってもよい。選択される可能性が高いマージ候補は、選択される可能性が低いマージ候補の前に配置される。このような順序に基づいて、各マージ候補はインデックス(マージインデックスと呼ばれる)に関連付けられる。一実施形態では、選択される確率が高いマージ候補は、より小さいインデックス値を有し、その結果、より少ないビットがそれぞれのインデックスを符号化するために必要となる。
一例では、マージ候補の動きデータは、1つ又は2つの動きベクトルの水平及び垂直動きベクトル変位値と、1つ又は2つの動きベクトルに関連する1つ又は2つの参照ピクチャインデックスと、任意選択で参照ピクチャインデックスに関連する参照ピクチャリストの識別情報とを含んでもよい。
一例では、所定の順序に従って、第1の数のマージ候補Caは、順序{A1,B1,B0,A0,B2}に従って空間候補位置から導出され、第2の数のマージ候補Cb=Cm-Caは、順序{C0,C1}に従って時間候補位置から導出される。候補位置を表すための数字A1,B1,B0,A0,B2,C0及びC1もまた、マージ候補を参照するために使用されてもよい。例えば、候補位置A1から取得されるマージ候補は、マージ候補A1と呼ばれる。
いくつかのシナリオでは、候補位置におけるマージ候補が利用できない可能性がある。例えば、候補位置における候補ブロックは、カレントブロック(810)を含むスライス又はタイルの外側で、或いは、カレントブロック(810)と同じ符号化ツリーブロック(CTB, coding tree block)行にないところで、イントラ予測される可能性がある。いくつかのシナリオでは、候補位置におけるマージ候補が冗長になる可能性がある。例えば、カレントブロック(810)の1つの隣接ブロックは、2つの候補位置に重なる可能性がある。冗長なマージ候補は、(例えば、プルーニング処理を実行することによって)候補リストから削除されてもよい。候補リスト内の利用可能なマージ候補(冗長な候補が削除されている)の総数が、マージ候補の最大数Cmよりも小さい場合、候補リストが固定長を有するように維持できるように、候補リストを埋めるために更なるマージ候補が(例えば、予め設定されたルールに従って)生成されてもよい。例えば、更なるマージ候補は、組み合わせ双予測候補(combined bi-predictive candidate)及びゼロ動きベクトル候補を含んでもよい。
候補リストが構築された後に、エンコーダにおいて、候補リストからマージ候補を選択するための評価処理が実行されてもよい。例えば、各マージ候補に対応するレート歪み(RD, rate-distortion)性能が計算されてもよく、最良のRD性能を有するものが選択されてもよい。したがって、カレントブロック(810)について、選択されたマージ候補に関連するマージインデックスが決定され、デコーダに伝達されてもよい。
デコーダにおいて、カレントブロック(810)のマージインデックスが受信されてもよい。上記のように、エンコーダ側で生成された候補リストと同じ候補リストを生成するために、同様の候補リスト構築プロセスが実行されてもよい。いくつかの例では、候補リストが構築された後に、マージ候補は、更なる評価を実行することなく、受信したマージインデックスに基づいて候補リストから選択されてもよい。選択されたマージ候補の動きデータは、カレントブロック(810)の後続の動き補償予測に使用されてもよい。
いくつかの例では、スキップモードも導入されている。例えば、スキップモードでは、カレントブロックは、動きデータのセットを決定するために上記のマージモードを使用して予測されてもよいが、残差は生成されず、変換係数は送信されない。スキップフラグはカレントブロックに関連付けられてもよい。カレントブロックの関連する動き情報を示すスキップフラグ及びマージインデックスは、ビデオデコーダに伝達されてもよい。例えば、インターピクチャ予測スライス内のCUの開始時に、以下を意味するスキップフラグが伝達されてもよい。CUが1つのPU(2N×2N)のみを含み、マージモードが動きデータを導出するために使用され、残差データがビットストリームに存在しない。デコーダ側では、スキップフラグに基づいて、残差情報を追加することなく、それぞれのカレントブロックを復号するためのマージインデックスに基づいて予測情報が決定されてもよい。したがって、本明細書に開示のマージモードでのビデオ符号化の様々な方法は、スキップモードと組み合わせて利用されてもよい。
一例として、一実施形態では、マージフラグ又はスキップフラグがビットストリームにおいて真として伝達されると、マージ候補リスト内のどの候補がカレントブロックについての動きベクトルを提供するために使用されるかを示すために、マージインデックスが伝達される。最大で4つの空間隣接動きベクトルと、最大で1つの時間隣接動きベクトルがマージ候補リストに追加されてもよい。シンタックスMaxMergeCandsNumは、マージ候補リストのサイズとして定義される。シンタックスMaxMergeVandsNumはビットストリームで伝達されてもよい。
[2.アフィンマージモード]
図9は、一実施形態による、カレントブロック(或いは符号化ユニット(CU, coding unit)と呼ばれる)(901)の空間隣接ブロック及び時間隣接ブロックの概略図である。図9に示すように、空間隣接ブロックは、A0、A1、A2、B0、B1、B2及びB3(それぞれ902、903、907、904、905、906及び908)で示され、時間隣接ブロックは、C0(912)で示される。いくつかの例では、空間隣接ブロックA0、A1、A2、B0、B1、B2及びB3と、カレントブロック(901)とは、同じピクチャに属する。いくつかの例では、時間隣接ブロックC0は参照ピクチャに属し、カレントブロック(901)の同一位置のブロックの外側の、同一位置のブロックの右下角に隣接する位置に対応する。
いくつかの例では、カレントブロック(901)の動きベクトル及び/又はカレントブロックのサブブロックは、アフィンモデル(例えば、6パラメータのアフィンモデル又は4パラメータのアフィンモデル)を使用して導出されてもよい。いくつかの例では、アフィンモデルは、ブロックの動きベクトルを記述するために6つのパラメータを有する(例えば、6パラメータのアフィンモデル)。一例では、アフィン符号化ブロックの6つのパラメータは、ブロックの3つの異なる位置(例えば、図9における左上、右上及び左下の角における制御点CP0、CP1及びCP2)における3つの動きベクトル(3つの制御点動きベクトル(CPMV, control point motion vector)とも呼ばれる)によって表されてもよい。他の例では、簡略化したアフィンモデルは、アフィン符号化ブロックの動き情報を記述するために4つのパラメータを使用し、これは、ブロックの2つの異なる位置(例えば、図9における左上及び右上の角の制御点CP0及びCP1)における2つの動きベクトル(2つのCPMVとも呼ばれる)によって表されてもよい。
動き情報候補のリスト(アフィンマージ候補リストとも呼ばれる)は、空間隣接ブロック及び/又は時間隣接ブロックのうちの1つ以上の動き情報に基づいてアフィンマージモードを使用して構築されてもよい。いくつかの例では、アフィンマージモードは、カレントブロック(901)が8サンプル以上の幅及び高さを有する場合に適用されてもよい。アフィンマージモードによれば、カレントブロック(901)のCPMVは、リストにおける動き情報候補に基づいて決定されてもよい。いくつかの例では、動き情報候補のリストは、最大で5つのCPMV候補を含んでもよく、どのCPMV候補がカレントブロックに使用されるべきかを示すためにインデックスが伝達されてもよい。
いくつかの実施形態では、アフィンマージ候補リストは、継承アフィン候補(inherited affine candidate)、構築アフィン候補(constructed affine candidates)及びゼロMVを含む、3つのタイプのCPMV候補を有してもよい。継承アフィン候補は隣接ブロックのCPMVからの外挿によって導出されてもよい。構築アフィン候補は、隣接ブロックの並進MVを使用して導出されてもよい。
一例では、左側隣接ブロック(A0及びA1)から1つのブロックと上側隣接ブロック(B0、B1及びB2)から1つのブロックとを含み、隣接ブロックの対応するアフィン動きモデルから導出される最大で2つの継承アフィン候補が存在してもよい。左側からの候補については、隣接ブロックA0及びA1が順次検査されてもよく、隣接ブロックA0及びA1からの第1の利用可能な継承アフィン候補が左側からの継承アフィン候補として使用される。上側の候補については、隣接ブロックB0、B1及びB2が順次検査されてもよく、隣接ブロックB0、B1及びB2からの第1の利用可能な継承アフィン候補が上側からの継承アフィン候補として使用される。いくつかの例では、2つの継承アフィン候補の間でプルーニング検査は実行されない。
隣接アフィンブロックが識別されると、カレントブロック(901)のアフィンマージリストに追加されるべき対応する継承アフィン候補が、隣接アフィンブロックのCPMVから導出されてもよい。図9の例では、隣接ブロックA1がアフィンモードで符号化される場合、ブロックA1の左上角(制御点CP0A1)、右上角(制御点CP1A1)及び左下角(制御点CP2A1)の動きベクトルが取得されてもよい。ブロックA1が4パラメータのアフィンモデルを使用して符号化される場合、カレントブロック(901)の継承アフィン候補としての2つのCPMVは、制御点CP0A1及び制御点CP1A1の動きベクトルに従って計算されてもよい。ブロックA1が6パラメータのアフィンモデルを使用して符号化される場合、カレントブロック(901)の継承アフィン候補としての3つのCPMVは、制御点CP0A1、制御点CP1A1及び制御点CP2A1の動きベクトルに従って計算されてもよい。
さらに、構築アフィン候補は、各制御点の隣接する並進動き情報を組み合わせることによって導出されてもよい。制御点CP0、CP1及びCP2の動き情報は、指定の空間隣接ブロックA0、A1、A2、B0、B1、B2及びB3から導出される。
例えば、CPMVk(k=1,2,3,4)は、第kの制御点の動きベクトルを表し、CPMV1は制御点CP0に対応し、CPMV2は制御点CP1に対応し、CPMV3は制御点CP2に対応し、CPMV4は時間隣接ブロックC0に基づく時間制御点に対応する。CPMV1について、隣接ブロックB2、B3及びA2が順次検査されてもよく、隣接ブロックB2、B3及びA2からの第1の利用可能な動きベクトルがCPMV1として使用される。CPMV2について、隣接ブロックB1及びB0が順次検査されてもよく、隣接ブロックB1及びB0からの第1の利用可能な動きベクトルがCPMV2として使用される。CPMV3について、隣接ブロックA1及びA0が順次検査されてもよく、隣接ブロックA1及びA0からの第1の利用可能な動きベクトルがCPMV3として使用される。さらに、利用可能な場合、時間隣接ブロックC0の動きベクトルがCPMV4として使用されてもよい。
4つの制御点CP0、CP1、CP2及び時間制御点のCPMV1、CPMV2、CPMV3及びCPMV4が取得された後に、アフィンマージ候補リストは、{CPMV1,CPMV2,CPMV3}、{CPMV1,CPMV2,CPMV4}、{CPMV1,CPMV3,CPMV4}、{CPMV2,CPMV3,CPMV4}、{CPMV1,CPMV2}及び{CPMV1,CPMV3}の順で構築されるアフィンマージ候補を含むように構築されてもよい。3つのCPMVのいずれかの組み合わせが6パラメータのアフィンマージ候補を形成してもよく、2つのCPMVのいずれかの組み合わせが4パラメータのアフィンマージ候補を形成してもよい。いくつかの例では、動きスケーリングプロセスを回避するために、制御点のグループの参照インデックスが異なる場合、CPMVの対応する組み合わせが破棄されてもよい。
[3.サブブロックベース時間動きベクトル予測(SbTMVP, Subblock-Based Temporal Motion Vector Prediction)モード]
図10Aは、一実施形態に従って、空間隣接ブロックの動き情報に基づいて、サブブロックベース時間MV予測(SbTMVP)方法を使用して、カレントブロック(1011)についての動き情報を決定するために使用できる空間隣接ブロックの概略図である。図10Aは、カレントブロック(1011)と、A0、A1、B0及びB1として示されるその空間隣接ブロック(それぞれ、1012、1013、1014及び1015)とを示す。いくつかの例では、空間隣接ブロックA0、A1、B0及びB1とカレントブロック(1011)とは、同じピクチャに属する。
図10Bは、一実施形態に従って、この非限定的な例におけるブロックA1のような選択された空間隣接ブロックに基づいて、SbTMVP方法を使用してカレントブロック(1011)のサブブロックについての動き情報を決定する概略図である。この例では、カレントブロック(1011)はカレントピクチャ(1010)内にあり、参照ブロック(1061)は参照ピクチャ(1060)内にあり、カレントブロック(1011)と、動きベクトル(1022)によって示される参照ブロック(1061)との間の動きシフト(又は変位)に基づいて識別されてもよい。
いくつかの実施形態では、HEVCにおける時間動きベクトル予測(TMVP, temporal motion vector prediction)と同様に、SbTMVPは、カレントピクチャ内のカレントブロックについての参照ピクチャの様々な参照サブブロックにおける動き情報を使用する。いくつかの実施形態では、TMVPによって使用される同じ参照ピクチャがSbTMVPに使用されてもよい。いくつかの実施形態では、TMVPはCUレベルで動き情報を予測するが、SbTMVPはサブCUレベルで動き情報を予測する。いくつかの実施形態では、TMVPは、カレントブロックの右下角又は中心に隣接する対応する位置を有する、参照ピクチャ内の同一位置のブロックからの時間動きベクトルを使用し、SbTMVPは、カレントブロックの空間隣接ブロックのうち1つからの動きベクトルに基づいて動きシフトを実行することによって識別できる参照ブロックからの時間動きベクトルを使用する。
例えば、図10Aに示すように、隣接ブロックA1、B1、B0及びA0は、SbTMVPプロセスにおいて順次検査されてもよい。参照ピクチャ(1060)を参照ピクチャとして使用する動きベクトルを有する第1の空間隣接ブロック(例えば、参照ピクチャ(1060)内の参照ブロックAR1(1062)を指す動きベクトル(1022)を有するブロックA1(1013)等)が識別されるとすぐに、この動きベクトル(1022)は、動きシフトを実行するために使用されてもよい。空間隣接ブロックA1、B1、B0及びA0からこのような動きベクトルが利用不可能である場合、動きシフトは(0,0)に設定される。
動きシフトを決定した後に、参照ブロック(1061)は、カレントブロック(1011)の位置及び決定された動きシフトに基づいて識別されてもよい。図10Bにおいて、参照ブロック(1061)は、参照動き情報MRa~MRpを有する16個のサブブロックに更に分割されてもよい。いくつかの例では、参照ブロック(1061)内の各サブブロックについての参照動き情報は、このようなサブブロックの中心サンプルをカバーする最小の動きグリッドに基づいて決定されてもよい。動き情報は、動きベクトル及び対応する参照インデックスを含んでもよい。カレントブロック(1011)は、16個のサブブロックに更に分割されてもよく、カレントブロック(1011)内のサブブロックについての動き情報MVa~MVpは、TMVPプロセスと同様に、いくつかの例では時間スケーリングを用いて、参照動き情報MRa~MRpから導出されてもよい。
SbTMVPプロセスにおいて使用されるサブブロックサイズは、固定されてもよく(或いは他の方法で予め決定されてもよい)或いは伝達されてもよい。いくつかの例では、SbTMVPプロセスにおいて使用されるサブブロックサイズは、8×8のサンプルでもよい。いくつかの例では、SbTMVPプロセスは、固定又は伝達されたサイズ(例えば、8画素)以上の幅及び高さを有するブロックにのみ適用可能である。
一例では、SbTMVP候補とアフィンマージ候補とを含む結合サブブロックベースのマージリストが、サブブロックベースのマージモードの信号伝達に使用される。SbTMVPモードは、シーケンスパラメータセット(SPS, sequence parameter set)フラグによって有効又は無効にされてもよい。いくつかの例では、SbTMVPモードが有効である場合、SbTMVP候補は、サブブロックベースのマージリストの最初のエントリとして追加され、その後にアフィンマージ候補が追加される。いくつかの実施形態では、サブブロックベースのマージリストの最大許容サイズは5に設定される。しかし、他の実施形態では、他のサイズが利用されてもよい。
いくつかの実施形態では、更なるSbTMVPマージ候補の符号化ロジックは、他のマージ候補と同じである。すなわち、P又はBスライス内の各ブロックについて、SbTMVP候補を使用するか否かを決定するために、更なるレート歪み検査が実行されてもよい。
[4.履歴ベース動きベクトル予測(HMVP, History-Based Motion Vector Prediction)モード]
図11Aは、一実施形態に従って、履歴ベースMV予測(HMVP)方法を使用して動き情報候補のリストを構築及び更新するプロセス(1100)の概要を示すフローチャートである。
いくつかの実施形態では、HMVP方法を使用した動き情報候補のリストは、符号化又は復号プロセスの間に構築及び更新されてもよい。リストは履歴リストと呼ばれてもよい。履歴リストは、HMVPテーブル又はHMVPバッファの形式で記憶されてもよい。新たなスライスが始まると、履歴リストは空にされてもよい。いくつかの実施形態では、ちょうど符号化又は復号されたインター符号化非アフィンブロックが存在する場合には常に、関連する動き情報が、新たなHMVP候補として履歴リストの最後のエントリに追加されてもよい。したがって、カレントブロックを処理(符号化又は復号)する前に、HMVP候補を有する履歴リストがロードされてもよい(S1112)。カレントブロックは、履歴リスト内のHMVP候補を使用して符号化又は復号されてもよい(S1114)。その後、カレントブロックを符号化又は復号するために動き情報を使用して、履歴リストが更新されてもよい(S1116)。
図11Bは、一実施形態に従って履歴ベースMV予測方法を使用して動き情報候補のリストを更新する概略図である。図11Bは、Lのサイズを有する履歴リストを示しており、リスト内の各候補は、0~L-1の範囲のインデックスで識別されてもよい。Lは0以上の整数である。カレントブロックを符号化又は復号する前に、履歴リスト(1120)は、L個の候補HMVP0、HMVP1、HMVP2、…HMVPm、….、HMVPL-2及びHMVPL-1を含む。ここで、mは0~Lの範囲の整数である。カレントブロックを符号化又は復号した後に、新たなエントリHMVPCが履歴リストに追加される。
一例では、履歴リストのサイズは6に設定されてもよく、これは、最大で6つのHMVP候補が履歴リストに追加できることを示す。新たな動き候補(例えば、HMVPC)を履歴リストに挿入する場合、制約付きの先入れ先出し(FIFO, first-in-first-out)ルールが利用されてもよく、ここで、履歴リストに冗長なHMVPが存在するか否かを見つけるために冗長検査が最初に適用される。冗長なHMVPが見つからない場合、最初のHMVP候補(図11Bの例では、インデックス=0を有するHMVP1)がリストから除去され、その後、全ての他のHMVP候補が、例えば、1だけインデックスを低減して、前方に動かされる。新たなHMVPC候補は、結果のリスト(1130)に示すように、(例えば、図11Bにおけるインデックス=L-1によって)リストの最後のエントリに追加されてもよい。他方、冗長なHMVPが見つかった場合(図11Bの例におけるHMVP2等)、履歴リスト内の冗長なHMVPはリストから除去され、その後、全てのHMVP候補が、例えば、1だけインデックスを低減して、前方に動かされる。新たなHMVPC候補は、結果のリスト(1140)に示すように、(例えば、図11Bにおけるインデックス=L-1によって)リストの最後のエントリに追加されてもよい。
いくつかの例では、HMVP候補は、マージ候補リスト構築プロセスにおいて使用されてもよい。例えば、リスト内の最新のHMVP候補が順番に検査され、TMVP候補の後に候補リストに挿入されてもよい。いくつかの実施形態では、空間又は時間マージ候補に対するHMVP候補についてプルーニングが適用されてもよいが、サブブロック動き候補(すなわち、SbTMVP候補)に対しては適用されなくてもよい。
いくつかの実施形態では、プルーニング演算の数を減らすために、以下のルールのうち1つ以上に従ってもよい。
(a)Mによって示される検査されるべきHMVP候補の数は以下の通り設定される。
M=(N<=4)?L:(8-N)
ここで、Nは利用可能な非サブブロックマージ候補の数を示し、Lは履歴リスト内の利用可能なHMVP候補の数を示す。
(b)さらに、利用可能なマージ候補の総数が、伝達されたマージ候補の最大数よりも1だけ少なくなると、HMVPリストからのマージ候補リスト構築プロセスが終了してもよい。
(c)さらに、組み合わせ双方向予測マージ候補の導出のための対の数が12から6に低減されてもよい。
いくつかの実施形態では、HMVP候補は、AMVP候補リスト構築プロセスにおいて使用されてもよい。履歴リスト内の最後のK個のHMVP候補の動きベクトルは、TMVP候補の後にAMVP候補リストに追加されてもよい。いくつかの例では、AMVPターゲット参照ピクチャと同じ参照ピクチャを有するHMVP候補のみがAMVP候補リストに追加される。HMVP候補に対してプルーニングが適用されてもよい。いくつかの例では、Kが4に設定され、AMVPリストサイズは変更されずに(例えば、2に等しく)保持される。
[5.ペアワイズ平均動きベクトル候補]
いくつかの実施形態では、ペアワイズ平均候補は、現在のマージ候補リスト内の候補の所定のペアを平均化することによって生成されてもよい。例えば、一実施形態では、指定のペアは、{(0,1),(0,2),(1,2),(0,3),(1,3),(2,3)}として定義され、数字はマージ候補リストに対するマージインデックスを示す。例えば、平均化された動きベクトルは、各参照ピクチャリストについて別々に計算される。双方の平均化されるべき動きベクトルが1つのリストにおいて利用可能である場合、これらの2つの動きベクトルは、異なる参照ピクチャを指している場合であっても平均化される。1つの動きベクトルのみが利用可能である場合、利用可能な動きベクトルが直接利用されてもよい。一例では、動きベクトルが利用可能でない場合、それぞれのペアがスキップされる。いくつかの実施形態では、マージ候補リストを構築する際に、ペアワイズ平均候補が組み合わせの候補を置き換える。
[6.動きベクトル差を伴うマージ(MMVD, Merge with Motion Vector Difference)モード]
いくつかの実施形態では、動きベクトル差を伴うマージ(MMVD)モードが、カレントブロックの動きベクトル予測子を決定するために使用される。MMVDモードは、スキップモード又はマージモードが有効であるときに使用されてもよい。MMVDモードは、スキップモード又はマージモードのマージ候補リスト内のマージ候補を再利用する。例えば、マージ候補リストから選択されたマージ候補は、参照ピクチャにおける開始点を提供するために使用されてもよい。カレントブロックの動きベクトルは、開始点と、開始点に対する動きの大きさ及び動きの方向を含む動きオフセットとで表現されてもよい。エンコーダ側では、マージ候補の選択及び動きオフセットの決定は、探索プロセス(又は評価プロセス)に基づいてもよい。デコーダ側では、選択されたマージ候補及び動きオフセットは、エンコーダ側から伝達された予測情報に基づいて決定されてもよい。
MMVDモードは、本明細書に記載の様々なインター予測モードで構築されたマージ候補リストを再利用してもよい。いくつかの例では、MMVDモードについて、マージ候補リスト内のデフォルトのマージタイプ(例えば、MRG_TYPE_DEFAULT_N)の候補のみが考慮される。デフォルトのマージタイプのマージ候補の例は、(i)マージモードで使用されるマージ候補、(ii)HMVPモードにおける履歴バッファからのマージ候補、及び(iii)本明細書に記載のペアワイズ平均動きベクトル候補を含んでもよい。いくつかの例では、アフィンモード又はSbTMVPモードでのマージ候補は、MMVDモードでの拡張に使用されない。
ベース候補インデックス(IDX, index)が開始点を定義するために使用されてもよい。例えば、0~3のインデックスに関連するMVPのリストが表1に示されている。伝達されたIDXに従って、リスト内のMVPのうち1つが開始点を提供するために選択されてもよい。一実施形態では、リスト内のMVPの数が1に等しい場合、IDXは伝達されない。
距離インデックスが動きの大きさの情報を提供するために使用されてもよい。例えば、所定の画素距離のリストが表2に示されており、各画素距離は0~7のインデックスに関連する。伝達された距離インデックスに従って、リスト内の所定の画素距離のうち1つが動きの大きさを提供するために選択されてもよい。
方向インデックスは、動きの方向の情報を提供するために使用されてもよい。例えば、00~11(バイナリ)のインデックスを有する方向のリストが表3に示されてる。伝達された方向インデックスに従って、リスト内の方向のうち1つが、開始点に関する動きオフセットの方向を提供するために選択されてもよい。
MMVDシンタックスエレメントは、MMVCモードにおけるベース候補インデックス、方向インデックス及び距離インデックスを含むMMVDインデックスのセットを伝達するためにビットストリームで送信されてもよい。
いくつかの実施形態では、MMVD有効フラグは、カレントブロックを符号化するためにスキップフラグ又はマージフラグを送信した後に伝達される。例えば、スキップ又はマージフラグが真である場合、MMVDフラグが解析される。一例では、MMVDフラグが1に等しい場合、MMVDシンタックスエレメント(例えば、MMVDインデックスのセット)が解析される。一例では、MMVDフラグが1でない場合、AFFINEフラグのような他のモードに関連するフラグが解析される。AFFINEフラグが1に等しい場合、カレントブロックを処理するためにアフィンモードが使用される。一例では、AFFINEフラグが1でない場合、スキップ又はマージインデックスは、スキップ又はマージモードでカレントブロックを処理するために解析される。
図12~図13は、本開示の一実施形態によるMMVDモードでの探索プロセスの一例を示す。探索プロセスを実行することによって、カレントピクチャ(或いはカレントフレームと呼ばれる)内のカレントブロック(1201)について、ベース候補インデックス、方向インデックス及び距離インデックスを含むMMVDインデックスのセットが決定されてもよい。
図12~13に示すように、第1の動きベクトル(1211)及び第2の動きベクトル(1221)は、第1のマージ候補に属する。第1のマージ候補は、カレントブロック(1201)について構築されたマージ候補リスト内のマージ候補でもよい。第1及び第2の動きベクトル(1211)及び(1221)は、それぞれ、参照ピクチャリストL0及びL1における2つの参照ピクチャ(1202)及び(1203)に関連付けられてもよい。したがって、図13における2つの開始点(1311)及び(1321)は、それぞれ参照ピクチャ(1202)及び(1203)において決定されてもよい。
一例では、開始点(1311)及び(1321)に基づいて、参照ピクチャ(1202)及び(1203)における、開始点(1311)及び(1321)から垂直方向(+Y又は-Yで表される)又は水平方向(+X及び-Xで表される)に延在する複数の所定の点が評価されてもよい。一例では、点の対(1314)及び(1324)、又は点の対(1315)及び(1325)のような、それぞれの開始点(1311)又は(1321)に関して互いにミラーリングする点の対が、カレントブロック(1201)についての動きベクトル予測子候補を形成し得る動きベクトルの対を決定するために使用されてもよい。開始点(1311)又は(1321)の周囲の所定の点に基づいて決定されるこれらの動きベクトル予測子候補が評価されてもよい。
第1のマージ候補に加えて、カレントブロック(1201)のマージ候補リスト内の他の利用可能又は有効なマージ候補も同様に評価されてもよい。一例では、一方向予測マージ候補について、2つの参照ピクチャリストのうち1つに関連する1つの予測方向のみが評価される。
評価に基づいて、最良の動きベクトル予測子候補が決定されてもよい。したがって、最良の動きベクトル予測子候補に対応して、最良のマージ候補がマージリストから選択されてもよく、動き方向及び動き距離も決定されてもよい。例えば、選択されたマージ候補及び表1に基づいて、ベース候補インデックスが決定されてもよい。所定の点(1315)(又は(1325))に対応するもののような選択された動きベクトル予測子に基づいて、開始点(1311)に関する点(1315)の方向及び距離が決定されてもよい。表2及び表3に従って、方向インデックス及び距離インデックスがそれに従って決定されてもよい。
上記の例は、単に例示的な目的のためのものである点に留意すべきである。別の例では、MMVDモードにおいて提供される動きベクトル表現方法に基づいて、動き距離及び動き方向が異なるように定義されてもよい。さらに、評価プロセス(又は探索プロセス)が異なるように実行されてもよい。例えば、双方向予測マージ候補については、3つのタイプの予測方向(例えば、L0、L1、及びL0とL1との双方)が、最良の動きベクトル予測子を選択するために、所定の距離及び方向のセットに基づいて評価されてもよい。他の例では、一方向予測マージ候補は、双方向予測マージ候補にミラーリング又はスケーリングすることによって変換され、その後に評価されてもよい。上記の例では、評価プロセスから生じる予測方向(例えば、L0、L1、又はL0とL1との双方)を示す更なるシンタックスが伝達されてもよい。
上記のように、マージ候補リスト内のマージ候補は、エンコーダにおけるMMVDモードにおけるベース候補を決定するために評価される。デコーダでは、入力としてベース候補インデックスを使用して、マージ候補リストから動きベクトル予測子が選択されてもよい。したがって、マージ候補の記憶のためのラインバッファに加えて、MMVDモードのための更なるラインバッファは必要とされない。
[7.アフィンパラメータ及びベースMVによるアフィンモデル表現]
[7.1 アフィン動き導出]
4パラメータのアフィンモデルでは、位置(x, y)におけるMV(mvh,mvv)は以下のように導出されてもよい。
6パラメータのアフィンモデルでは、位置(x, y)におけるMV(mvh,mvv)は以下のように導出されてもよい。
上記の式(1)及び(2)において、MVbase(mvh
base,mvv
base)は、ベース位置(xbase,ybase)におけるベースMVであり、(a,b)又は(a,b,c,d)は、それぞれ4パラメータのアフィンモデル及び6パラメータのアフィンモデルのアフィンパラメータを表す。アフィンパラメータは次のように計算されてもよい。
ここで、MV0(mv0
h,mv0
v)、MV1(mv1
h,mv1
v)及びMV2(mv2
h,mv2
v)は、それぞれ位置(x0,y0)、(x1,y1)及び(x2,y2)における3つの制御点MV(CPMV, control point MV)を表す。(x0,y0)、(x1,y1)及び(x2,y2)は、典型的には、w×hのサイズを有するアフィン符号化ブロックの左上、右上及び左下角になるように設定される。したがって、Lxはwに設定されてもよく、Lyはhに設定されてもよい。
いくつかの実施形態では、ベースMVがアフィン符号化ブロックの左上角(x0,y0)のCPMV MV0になるように設定されているが、ベースMVは、アフィン符号化ブロックのCPMVのうち1つである必要はない点に留意すべきである。
[7.2 CTU行を横断するアフィン継承]
図14は、カレントCTU行(1430)及びカレントCTU行(1430)の上にある上側CTU行(1420)を示す。カレントCTU行(1430)は、アフィン符号化されたカレントCU(1410)を含む処理中のカレントCTU(1404)を含む。図示のように、カレントCU(1410)は、MVC0、MVC1及びMVC2の3つのCPMVに対応する座標(x0,y0)、(x1,y1)及び(x2,y2)を有する3つの制御点を含む。カレントCU(1410)はwの幅を有する。
上側CTU行(1420)は、CTU(1401)、(1402)及び(1403)と、LL、B3、B2、N0、B0、B1、N1、R、R2及びRRとして示される最小ブロック(又は4×4のブロック)のセットとを含む。CTU(1402)は、カレントCU(1410)のアフィン符号化された隣接CU(1411)を含む。
第1の例では、カレントCU(1410)のアフィンモデルが、上側CTU行(1420)の隣接する4×4のブロックから継承される場合、通常のMVバッファに記憶されたMVがアクセスされる。図14は、カレントCU(1410)がアフィンマージモードを適用し、隣接ブロックB0からアフィンモデルを継承する例を示す。この場合、コーデックは、B0(図14におけるWn)をカバーするCU(1411)の幅と、CU(1411)の左下の4×4のブロック(N0)及び右下の4×4のブロック(N1)のMV(図14におけるMVN0及びMVN1)と、N0の左下座標(xN0,yN0)であるベース位置とを記憶してもよい。この例では、MVN0がベースMVとして使用される。
通常のMVバッファに記憶されたMVにアクセスするために、ラインバッファ(例えばB0)における4×4のブロックについて、幅Wnと、4×4のブロックを含むCU(1411)の左下座標のx成分xN0とが記憶されてもよい。例えば、8×8のブロック毎に、Wnについて3ビット及びxN0について5ビットが記憶される必要がある。
ラインバッファのサイズを低減するために、第2の例では、CU幅及びそれぞれの8×8のブロックの左下座標のx成分の記憶がラインバッファから除去される。カレントCU (1410)が、図14におけるB0のような隣接する4×4のブロックからのアフィン継承を適用する場合、B0に右隣接するか或いはB0に左隣接し、アフィン符号化されており、B0と同じ参照ピクチャインデックスを有する4×4ブロックがB0’として選択される。B0及びB0’に記憶されている通常のMVは、MVB及びMVB’としてアクセスされる。MV0及びMV1は、Lx=4で式(3)によってa及びbを導出するために、MVB及びMVB’に設定される。カレントCU(1410)のCPMVは、B0の中心位置をベース位置とし、MVBをベースMVとして、式(1)によって導出される。
提案の方法では、図14に示すように、B3からR2への最大で36個の4×4のブロックは、CTU行境界においてアクセスされてもよい。キャッシュ上にロードされる必要がある更なる情報は、4464ビットから2×72=144ビット(又はバイトアラインメント実装では2×10=20バイト)に低減される。
[7.3 CTU行内のアフィン継承]
一例では、カレントCUのアフィンモデルがカレントCTU行の隣接する4×4のブロックから継承される場合、ローカルCPMVバッファ(CTU内バッファ)に記憶されたCPMVがアクセスされてもよい。カレントCUは、ローカルバッファに記憶されたCPMVに基づいて、隣接CUから4パラメータ又は6パラメータのアフィンモデルを継承してもよい。CTU内の4×4のブロックについて、2つの参照リストについての3つのCPMV、4×4のブロックを含むCUの幅、高さ及び左上座標が記憶されてもよい。
ローカルCPMVバッファのサイズを低減するために、他の例では、3つのCPMV及びブロックの大きさの代わりに、アフィンパラメータが記憶される。カレントCUがアフィン継承マージモードを適用する場合、アフィンパラメータは、継承されるべき隣接する4×4のブロック(Bとして示される)から直接コピーされる。カレントCU内の各サブブロックのMVは、例えば、Bの中心位置をベース位置とし、Bにおける通常のMVをベースMVとして、式(2)によって導出される。カレントCUがアフィンAMVPモードを適用する場合、カレントCUのCPMVも、Bの中心位置をベース位置とし、Bにおける通常のMVをベースMVとして、式(2)によって導出され、導出されたCPMVは、動きベクトル予測子(MVP, motion vector predictor)として機能する。
一例では、各アフィンパラメータは8ビット符号付き整数として記憶される。したがって、2×4×8=64ビットが、CTU内のそれぞれの8×8のブロックのアフィンパラメータについて記憶されてもよい。この方法では、CPMVの記憶と比較して、CTU内バッファは48×64=3072ビット(又はバイトアラインメント実装では48×8=384バイト)だけ増加する。この方法では、アフィンパラメータが2回計算され得るCPMVの記憶の方法と比較して、1つのセットのアフィンパラメータが最大で1回のみ計算される。
[8.履歴ベースのアフィン予測(アフィンHMVP)]
[8.1 アフィンHMVPテーブル]
いくつかの例では、アフィン動き候補を記憶するアフィンHMVPテーブルが使用される。アフィン符号化されたカレントCUを符号化した後に、カレントCUの動き情報がアフィンHMVPテーブルを更新するために使用される。通常のHMVPテーブル更新処理と同様に、新たな動き候補をアフィンHMVPテーブルに追加する場合、制約付きFIFOルールが利用される。例えば、アフィンHMVPテーブルに同じアフィンHMVP候補が存在するか否かを見つけるために、まず冗長検査が適用される。見つかった場合、同じアフィンHMVP候補がアフィンHMVPテーブルから除去される。その後、全てのアフィンHMVP候補は前方に動かされ、すなわち、インデックスが1だけ低減する。一例では、アフィンHMVPテーブルのサイズは、5(テーブル内の5つのエントリ)に設定され、これは、いくつかの実施形態で使用されるサブブロックマージリストサイズと同じである。一例では、HMVPテーブルはCTU行の開始時にリセットされる。
一例では、アフィンHMVPテーブルの各エントリについて、以下の動き情報が、リストされたメモリ要件によって記憶される。
2つの参照リストについてのアフィンCPMV mv0、mv1、mv2 (36ビット*2*3)
リスト0及び/又はリスト1の参照インデックス (4ビット*2)
インター予測方向(L0、L1又は双方向予測) (2ビット)
アフィンタイプ(4パラメータ又は6パラメータのアフィン) (1ビット)
位置(x, y) (16ビット*2)
CU幅及び高さ (5ビット*2)
一般化双方向予測インデックス(GBI, generalized bi-prediction index)(オプション) (3ビット)
必要合計メモリ:36*2*3+4*2+2+1+16*2+5*2+3=272ビット
したがって、異なるサイズのアフィンHMVPテーブルのためのメモリ要件は、以下の通りである。
テーブルサイズ1: 272ビット ~34バイト
テーブルサイズ4: 1088ビット ~136バイト
テーブルサイズ5: 1360ビット ~170バイト
[8.2 アフィンHMVPテーブルからのアフィンCPMVのコピー]
一例では、アフィンHMVP候補は、更なる候補としてマージ候補リスト又はAMVP候補リストに直接追加されてもよい。例えば、アフィンHMVP候補は、構築アフィン候補の後、且つ、ゼロMV候補の前の位置に追加されてもよい。一例では、アフィンHMVP候補をマージリストに追加するときにプルーニング検査は存在しない。一例では、アフィンHMVP候補のCPMVは、対応する履歴ブロックの形状及びサイズにかかわらず、カレントCUに直接適用される。
[8.3 アフィンHMVPテーブルからのアフィンモデル継承]
一例では、アフィンHMVP候補のアフィンモデルは、アフィンマージ候補又はアフィンAMVP候補を生成するために継承される。空間隣接からのアフィンモード継承(又はアフィン継承)と同様に、アフィンHMVPテーブルからのアフィン継承は、アフィン動き情報を生成するために、アフィンHMVPバッファに記憶された位置、ブロック幅及び/又は高さ、及びCPMVを使用する。
[8.3.1 アフィンHMVPテーブルからの継承による空間隣接からのアフィン継承の置き換え]
継承アフィンマージ候補及び継承アフィンAMVP候補は、アフィンモードで符号化された左側及び上側隣接ブロックから導出されてもよい。一例では、空間隣接から継承されたアフィン候補は、アフィンHMVPテーブルから導出された継承候補に置き換えられる。アフィンHMVPから継承されたアフィンマージ候補及びAMVP候補は、置き換えられた継承アフィン候補と同じ位置とすることができる。一例では、アフィンHMVPテーブルからの最大で2つの継承候補が、アフィンマージモードとアフィンAMVPモードとの双方で許可される。
一例では、アフィンHMVPテーブル内のエントリは、最新のエントリから始めて検査される。アフィンHMVP候補がカレントCUに隣接する場合にのみ、アフィンHMVP候補は、継承候補を導出するために使用される。アフィンHMVP候補がカレントCUの隣接であるか否かは、位置及びサイズ情報がアフィンHMVPテーブルに記憶されているので、決定できる。次いで、カレントCUの隣接として識別されたアフィンHMVP候補について、この識別された候補の幅、高さ及びCPMVが、空間隣接からのアフィン継承と同様に、カレントCUのCPMVを導出するために使用される。
[8.3.2 動きデータラインバッファを使用した上側CTUからのアフィン継承と組み合わせたアフィンHMVPテーブルからのアフィン継承]
一例では、8.3.1において説明したように、アフィンHMVP テーブルからのアフィン継承に加えて、動きデータラインバッファからのアフィン継承も、カレントCTUの上側境界に隣接して位置するブロックに使用される。
上側CTUからのアフィン動きデータ(又はアフィンモデル)継承について以下に記載する。アフィン動きデータ継承の候補CUが上側CTUライン(又は行)にある場合、CPMVの代わりにラインバッファ内の左下及び右下サブブロック(最小ブロック)(例えば、4×4の画素のサイズを有するブロック)の通常のMVが、アフィンMVP導出に使用される。このように、上側CTU行における候補CUに対応するCPMVは記憶されず、カレントCTU行内の候補CUのCPMVのみがローカルバッファに記憶される。
上側CTU行における候補CUが6パラメータのアフィンモデルで符号化されている場合、アフィンモデルは継承のために4パラメータのモデルに低下する。サブブロック(最小ブロック)のMVは、それぞれのサブブロックの中心における動きを表すので、候補CUの下側における2つの角のサブブロックのMVの距離は、neiW-4画素であり、neiWは候補CUの幅である。2のべき乗でない可能性がある、(neiW-4)による除算を回避するために、大まかな距離neiWが継承に使用される。左下及び右下角の座標は継承のために(xNb,yNb+neiH)及び(xNb+neiW,yNb+neiH)に設定され、neiHは候補CUの高さである。
図15は、上側CTUラインバッファからのアフィン継承の例を示す。図示のように、第1のCTU行はCTU境界(1511)の上にあり、第2のCTU行はCTU境界(1511)の下にある。カレントCTUは第2のCTU行にあり、制御点(x0,y0)、(x1,y1)及び(x2,y2)においてCPMV
を有するアフィン符号化されたカレントCUを含む。カレントCUは、アフィン符号化された隣接CU(又はブロック)E、B、C及びDを有する。ブロックEの左上及び右上角は、それぞれ(xE0,yE0)及び(xE1,yE1)の座標を有する。ブロックE、B、C及びDのそれぞれに対応するCPMV
が示されており、カレントCUの空間隣接からのアフィン継承のために、カレントCTUのローカルバッファに保存されてもよい。
また、破線の矢印(1502)及び実線の矢印(1503)で示すサブブロック(最小ブロック)動きベクトルも示されている。これらのサブブロック動きベクトルは、最小許容ブロックサイズ(典型的には、4×4の画素)を有する最小サブブロックに対応する。このようなそれぞれの最小ブロックの動き情報は、それぞれの最小ブロックを含むインター符号化ブロックが処理され、インター符号化ブロックの動き情報が利用可能である場合、メモリに記憶されてもよい。矢印(1502)及び(1503)で示すそれぞれの動きベクトルを含む最小ブロックに対応する動き情報は、動き補償(MC, motion compensation)、マージ/スキップモード、AMVPモード、デロッキング及びTMVPの導出のような全てのものに使用されてもよい。アフィン動き情報に関して、最小ブロックに対応する動き情報は、通常の動き情報と呼ばれてもよい。
さらに、CTU境界(1511)の上の最小ブロックの通常の動き情報は、上側CTU行ラインバッファ(1520)に記憶され、CTU境界(1511)に隣接するカレントCTU内のCUを符号化するためのアフィン継承に使用されてもよい。
一例として、上側CTU境界(1511)に沿って、CUの左下及び右下のサブブロック動きベクトルが、全てのものに使用され、ラインバッファ(1520)に記憶される。これらのサブブロックMVは、下側CTU(CTU境界1511の下の第2の行におけるCTU)における隣接アフィンCUのアフィン継承にも使用される。例えば、CU Eでは、左下及び右下角のサブブロックMV
(破線の矢印で記される)がラインバッファ1520に記憶され、アフィン継承に使用される。MV
は、それぞれのサブブロック内の中心位置(xLE0,yLE0)又は(xLE1,yLE1)からそれぞれ開始してもよい。一例では、MV
は、下側CTUにおける隣接CUのマージ/スキップ/AMVPリストの導出、及びデブロッキングにも使用されてもよい。
一例として、それぞれの位置(xLE0,yLE0)又は(xLE1,yLE1)におけるMV
に基づいて、カレントCUのCPMV
は、以下のように4パラメータモデルを使用することによって導出されてもよい。
また、カレントCUが6パラメータのアフィン動きモデルを使用する場合、制御点ベクトル
は、以下のように4パラメータモードを使用することによって導出されてもよい。
上記の式(6)~(8)において、MV
に対応する中心位置の座標は、以下のようにCU Eの左下及び右下角の座標と置き換えられる。
その結果、位置(xLE0,yLE0)と(xLE1,yLE1)との間の距離の代わりに、CU Eの幅が使用される。
[8.4 記憶されたアフィンパラメータを有するアフィンHMVPテーブル]
一例では、アフィンHMVPテーブルは、8.1において説明した方法と同様に構築される。しかし、アフィンCPMV値を記憶する代わりに、アフィンパラメータ(例えば式(3)及び(4)におけるパラメータa、b、c又はd)が各アフィンHMVPエントリに記憶される。アフィン継承は、アフィンマージ又はアフィンAMVP候補についてのアフィン動き情報を生成するために、アフィンHMVPからのアフィンパラメータを使用して実行されてもよい。一例では、履歴ベースのアフィンマージ候補(HAMC, history-based affine merge candidate)は、サブブロックベースのマージ候補リストに含まれる。
例えば、アフィン符号化CUを復号した後に、2つの参照ピクチャリストについてのアフィンパラメータのセット{a,b,c,d}及び関連する参照インデックスが、アフィンパラメータ履歴テーブルに入れられる。
HAMCは、テーブルに記憶されたアフィンパラメータのセットと、ベースMVとして機能する隣接する4×4のブロックの通常のMVとを組み合わせることによって導出されてもよい。例えば、位置(x,y)におけるカレントブロックのMVは、以下のように計算される。
ここで、(mvh
base, mvv
base)は隣接する4×4のブロックのMVを表し、(xbase,ybase)は隣接する4×4のブロックの中心位置を表し、(x,y)はCPMVを取得するためのカレントブロックの左上、右上及び左下角とすることができる。
一例では、記憶されたアフィンパラメータから導出されたHAMC及び空間隣接ブロックからのベースMVは、構築アフィンマージ候補の後に、サブブロックベースのマージリストに入れられる。HMVPテーブル内の記憶されたアフィンパラメータの各セットについて、アフィンパラメータのセットに関連するものと同じインター予測方向及び参照インデックスを有する第1の有効な隣接する4×4のブロックがHAMCを導出するために使用される。
一例では、記憶されたアフィンパラメータから導出されたHAMC及び時間隣接ブロックからのベースMVは、ゼロ候補の前に、サブブロックベースに入れられる。記憶されたアフィンパラメータの各セットについて、それぞれのTMVPは、HAMCを導出するために、パラメータが参照する参照ピクチャにスケーリングされる。
一例では、各アフィンモデルパラメータは、8ビット符号付き整数として記憶されてもよい。最大で6個のアフィンパラメータセットが記憶される。したがって、アフィンパラメータ履歴テーブルは小さくすることができ、例えば、6×(8×4×2+8)=432ビット(42バイト)のサイズを有する。
[III.アフィンHMVPバッファのアクセス]
関連する技術において、アフィンHMVPバッファがアフィンマージモード又はアフィンAMVPモードに使用される場合、アフィンHMVPバッファのアクセス順序は、直近に追加されたエントリからアクセスを開始することである。しかし、この特定のアクセス順序は、アフィンHMVPバッファの性能を制限する。したがって、本開示は、アフィンHMVPバッファにアクセスするための改良技術を提供する。
本技術は、アフィンHMVPバッファにアクセスする方法を対象とする。当該方法は、アフィンHMVPバッファの各エントリに何が記憶されているか、バッファのエントリの数、又はバッファのエントリからアフィン候補を導出する方法にかかわらず、適用されてもよい。当該方法は、別々に使用されてもよく或いはいずれかの順序で組み合わされてもよい。さらに、ブロックという用語は、予測ブロック、符号化ブロック又は符号化ユニット(CU, coding unit)として解釈されてもよい。
本開示の態様によれば、アフィンHMVPバッファの第1のアクセスエントリは、アフィンマージ候補又はアフィンAMVP候補の導出にかかわらず、直近に追加されたエントリ又は最初に追加されたエントリでもよい。
一実施形態では、アフィンマージ候補を導出する場合、アフィンHMVPバッファの第1のアクセスエントリは、直近に追加されたエントリでもよい。他の実施形態では、マージ候補を導出する場合、アフィンHMVPバッファの第1のアクセスエントリは、最初に追加されたエントリでもよい。
一実施形態では、アフィンAMVP候補を導出する場合、アフィンHMVPバッファの第1のアクセスエントリは、直近に追加されたエントリでもよい。他の実施形態では、AMVP候補を導出する場合、アフィンHMVPバッファの第1のアクセスエントリは、最初に追加されたエントリでもよい。
本開示の態様によれば、アフィンマージ候補を導出するための第1のアフィンHMVPバッファのアクセス順序は、アフィンAMVP候補を導出するための第2のアフィンHMVPバッファのアクセス順序とは異なってもよい。第1のアフィンHMVPバッファは、第2のアフィンHMVPバッファと同じでもよい点に留意すべきである。
一実施形態では、アフィンマージ候補を導出するための第1のアフィンHMVPバッファの第1のアクセスエントリが直近に追加されたエントリである場合、アフィンAMVP候補を導出するための第2のアフィンHMVPバッファの第1のアクセスエントリは最初に追加されたエントリでもよい。
他の実施形態では、アフィンマージ候補を導出するための第1のアフィンHMVPバッファの第1のアクセスエントリが最初に追加されたエントリである場合、アフィンAMVP候補を導出するための第2のアフィンHMVPバッファの第1のアクセスエントリは直近に追加されたエントリでもよい。
本開示の態様によれば、アフィンHMVPバッファのアクセス順序は、シーケンスパラメータセット(SPS, sequence parameter set)、タイル/タイルグループレベル又はピクチャレベルのようなシーケンスレベルで伝達されてもよい。
一実施形態では、アフィンHMVPバッファからアフィンマージ候補及びアフィンHMVP候補の双方を導出するために、1つの伝達されたアクセス順序が使用されてもよい。
他の実施形態では、アフィンマージ候補及びアフィンAMVP候補を導出するためのアクセス順序は、別々に伝達される。
図16は、本開示のいくつかの実施形態による例示的なプロセス(1600)の概要を示すフローチャートを示す。様々な実施形態では、プロセス(1600)は、端末デバイス(210)、(220)、(230)及び(240)内の処理回路、ビデオエンコーダ(303)の機能を実行する処理回路、ビデオデコーダ(310)の機能を実行する処理回路、ビデオデコーダ(410)の機能を実行する処理回路、ビデオエンコーダ(503)の機能を実行する処理回路等のような処理回路によって実行される。いくつかの実施形態では、プロセス(1600)は、ソフトウェア命令で実装され、したがって、処理回路がソフトウェア命令を実行すると、処理回路は、プロセス(1600)を実行する。
プロセス(1600)は、概してステップ(S1601)において始まってもよく、プロセス(1600)は、符号化ビデオシーケンスの一部であるカレントピクチャ内のカレントブロックの予測情報を復号する。予測情報は、カレントブロックの予測モードと、アフィン履歴ベース動きベクトル予測子(HMVP, history-based motion vector predictor)バッファのアクセス順序とを示す。次いで、プロセス(1600)はステップ(S1602)に進む。
ステップ(S1602)において、プロセス(1600)は、アクセス順序に従って、アフィンHMVPバッファからアフィンHMVP候補を含む動きベクトル予測子(MVP, motion vector predictor)リストを構築する。次いで、プロセス(1600)はステップ(S1603)に進む。
ステップ(S1603)において、プロセス(1600)は、MVPリストに基づいてカレントブロックを復元する。
カレントブロックを復元した後に、プロセス(1600)は終了する。
一実施形態では、予測モードがアフィンマージモードである場合、アクセス順序は、アフィンHMVP候補に関連するアフィンHMVPバッファのエントリを、直近に追加されたエントリになるように設定する。
一実施形態では、予測モードがアフィンマージモードである場合、アクセス順序は、アフィンHMVP候補に関連するアフィンHMVPバッファのエントリを、最初に追加されたエントリになるように設定する。
一実施形態では、予測モードがアフィン高度動きベクトル予測(AMVP, affine advanced motion vector prediction)モードである場合、アクセス順序は、アフィンHMVP候補に関連するアフィンHMVPバッファのエントリを、直近に追加されたエントリになるように設定する。
一実施形態では、予測モードがアフィンAMVPモードである場合、アクセス順序は、アフィンHMVP候補に関連するアフィンHMVPバッファのエントリを、最初に追加されたエントリになるように設定する。
一実施形態では、アフィンマージモードのアクセス順序と、アフィンAMVPモードのアクセス順序とは異なる。
一実施形態では、アクセス順序は予測情報に含まれる。一例では、伝達されたアクセス順序は、アフィンマージモードとアフィンAMVPモードとの双方に適用される。他の例では、アフィンマージモードのアクセス順序と、アフィンAMVPモードのアクセス順序とは、予測情報に別々に含まれる。
[IV.コンピュータシステム]
上記の技術は、コンピュータ読み取り可能命令を使用してコンピュータソフトウェアとして実装され、1つ以上のコンピュータ読み取り可能媒体に物理的に記憶されてもよい。例えば、図17は、開示の対象物の特定の実施形態を実装するのに適したコンピュータシステム(1700)を示す。
コンピュータソフトウェアは、いずれかの適切な機械コード又はコンピュータ言語を使用して符号化されてもよく、当該機械コード又はコンピュータ言語は、命令を含むコードを生成するために、アセンブリ、コンパイル、リンク又は類似のメカニズムを受けてもよく、当該命令は、1つ以上のコンピュータ中央処理装置(CPU, central processing unit)、グラフィックス処理ユニット(GPU, Graphics Processing Unit)等によって、直接的に或いはインタープリタ、マイクロコード実行等を通じて実行されてもよい。
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットのデバイス等を含む様々なタイプのコンピュータ又はその構成要素上で実行されてもよい。
コンピュータシステム(1700)について図17に示される構成要素は、本質的に例示的なものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用範囲又は機能に関する如何なる限定も示唆することを意図するものではない。また、構成要素の構成も、コンピュータシステム(1700)の例示的な実施形態に示される構成要素のいずれか1つ又は組み合わせに関する如何なる依存性又は要件も有するものとして解釈されるべきではない。
コンピュータシステム(1700)は、特定のヒューマンインタフェース入力デバイスを含んでもよい。このようなヒューマンインタフェース入力デバイスは、例えば、触覚入力(キーストローク、スワイプ、データグローブの動き等)、オーディオ入力(音声、拍手等)、視覚入力(ジェスチャ等)、嗅覚入力(図示せず)を通じて、1人以上の人間のユーザによる入力に応答してもよい。また、ヒューマンインタフェースデバイスは、オーディオ(例えば、会話、音楽、周辺音)、画像(スキャンされた画像、静止画カメラから取得された写真画像等)、ビデオ(2次元ビデオ、立体ピクチャを含む3次元ビデオ等)のような、人間による意識的入力に必ずしも直接関連しない特定のメディアをキャプチャするために使用されてもよい。
入力ヒューマンインタフェースデバイスは、キーボード(1701)、マウス(1702)、トラックパッド(1703)、タッチ画面(1710)、データグローブ(図示せず)、ジョイスティック(1705)、マイクロフォン(1706)、スキャナ(1707)、カメラ(1708)のうち1つ以上を含んでもよい。
また、コンピュータシステム(1700)は、特定のヒューマンインタフェース出力デバイスを含んでもよい。このようなヒューマンインタフェース出力デバイスは、例えば、触覚出力、音、光及び嗅覚/味覚を通じて、1人以上の人間のユーザの感覚を刺激してもよい。このようなヒューマンインタフェース出力デバイスは、触覚出力デバイス(例えば、タッチ画面(1710)、データグローブ(図示せず)又はジョイスティック(1705)による触覚フィードバック、ただし、入力デバイスとして機能しない触覚フィードバックデバイスが存在してもよい)と、オーディオ出力デバイス(スピーカ(1709)、ヘッドフォン(図示せず)等)と、視覚出力デバイス(それぞれがタッチ画面入力機能を有しても有さなくてもよく、それぞれが触覚フィードバック機能を有しても有さなくてもよく、いくつかが2次元視覚出力又は立体出力のような手段を通じた3次元以上の出力を出力可能でもよいCRT画面、LCD画面、プラズマ画面、OLED画面を含む画面(1710)、仮想現実メガネ(図示せず)、ホログラフィックディスプレイ及びスモークタンク(図示せず))と、プリンタ(図示せず)とを含んでもよい。これらの視覚出力デバイス(画面(1710)等)は、グラフィックスアダプタ(1750)によってシステムバス(1748)に接続されてもよい。
また、コンピュータシステム(1700)は、CD/DVD又は同様の媒体(1721)を有するCD/DVD ROM/RW(1720)を含む光媒体のような人間がアクセス可能な記憶デバイス及び関連する媒体、サムドライブ(1722)、取り外し可能ハードドライブ又はソリッドステートドライブ(1723)、テープ及びフロッピーディスク(図示せず)のようなレガシー磁気媒体、セキュリティドングル(図示せず)のような特殊なROM/ASIC/PLDに基づくデバイス等を含んでもよい。
また、当業者は、ここに開示の対象物に関連して使用される用語「コンピュータ読み取り可能媒体」が伝送媒体、搬送波又は他の非一時的な信号を含まないことを理解すべきである。
また、コンピュータシステム(1700)は、1つ以上の通信ネットワーク(1755)へのネットワークインタフェース(1754)を含んでもよい。1つ以上の通信ネットワーク(1755)は、例えば、無線、有線、光でもよい。1つ以上の通信ネットワーク(1755)は、ローカル、広域、メトロポリタン、車両及び産業、リアルタイム、遅延耐性等でもよい。1つ以上の通信ネットワーク(1755)の例は、イーサネット、無線LAN、セルラネットワーク(GSM、3G、4G、5G、LTE等を含む)、TV有線又は無線広域デジタルネットワーク(ケーブルTV、衛星TV、及び地上放送TVを含む)、車両及び産業(CANBusを含む)等を含む。特定のネットワークは、一般的に、特定の汎用データポート又は周辺バス(1749)に取り付けられる外部ネットワークインタフェースアダプタ(例えば、コンピュータシステム(1700)のUSBポート等)を必要とし、他のネットワークインタフェースアダプタは、一般的に、以下に説明するシステムバス(例えば、PCコンピュータシステムへのイーサネットインタフェース又はスマートフォンコンピュータシステムへのセルラネットワーク)に取り付けられることによって、コンピュータシステム(1700)のコアに統合される。これらのネットワークのいずれかを使用して、コンピュータシステム(1700)は、他のエンティティと通信することができる。このような通信は、一方向の受信のみ(例えば、放送TV)、一方向の送信のみ(例えば、特定のCANbusデバイスへのCANbus)でもよく、或いは、例えば、ローカル又は広域デジタルネットワークを使用する他のコンピュータシステムへの双方向でもよい。特定のプロトコル及びプロトコルスタックは、上記のようなネットワーク及びネットワークインタフェースのそれぞれにおいて使用されてもよい。
上記のヒューマンインタフェースデバイス、人間がアクセス可能な記憶デバイス及びネットワークインタフェースは、コンピュータシステム(1700)のコア(1740)に取り付けられてもよい。
コア(1740)は、1つ以上の中央処理装置(CPU)(1741)、グラフィックス処理ユニット(GPU)(1742)、フィールドプログラマブルゲートアレイ(FPGA, Field Programmable Gate Area)(1743)の形式の特殊なプログラム可能処理ユニット、特定のタスク用のハードウェアアクセラレータ(1744)等を含んでもよい。これらのデバイスは、読み取り専用メモリ(ROM)(1745)、ランダムアクセスメモリ(1746)、内部大容量記憶装置(内部のユーザアクセス不可能なハードドライブ、SSD等)(1747)と共に、システムバス(1748)を通じて接続されてもよい。いくつかのコンピュータシステムでは、システムバス(1748)は、更なるCPU、GPU等による拡張を可能にするために、1つ以上の物理プラグの形式でアクセス可能でもよい。周辺デバイスは、コアのシステムバス(1748)に直接取り付けられてもよく、或いは、周辺バス(1749)を通じて取り付けられてもよい。周辺バスのアーキテクチャは、PCI、USB等を含む。
CPU(1741)、GPU(1742)、FPGA(1743)及びアクセラレータ(1744)は特定の命令を実行してもよく、当該特定の命令は、組み合わせによって上記のコンピュータコードを構成してもよい。当該コンピュータコードは、ROM(1745)又はRAM(1746)に記憶されてもよい。また、一時的なデータは、RAM(1746)に記憶されてもよいが、永続的なデータは、例えば、内部大容量記憶装置(1747)に記憶されてもよい。1つ以上のCPU(1741)、GPU(1742)、大容量記憶装置(1747)、ROM(1745)、RAM(1746)等と密接に関連してもよいキャッシュメモリを使用することによって、メモリデバイスのいずれかへの高速記憶及び検索が可能になってもよい。
コンピュータ読み取り可能媒体は、様々なコンピュータに実装された動作を実行するためのコンピュータコードを有してもよい。媒体及びコンピュータコードは、本開示の目的のために特に設計及び構築されたものでよく、或いは、コンピュータソフトウェア分野における当業者に周知で入手可能なようなものでもよい。
限定ではなく一例として、アーキテクチャ(1700)、具体的には、コア(1740)を有するコンピュータシステムは、1つ以上の有形のコンピュータ読み取り可能媒体に具現されたソフトウェアを実行するプロセッサ(CPU、GPU、FPGA、アクセラレータ等を含む)の結果として機能を提供できる。このようなコンピュータ読み取り可能媒体は、コア内部の大容量記憶装置(1747)又はROM(1745)のような非一時的な性質のコア(1740)の特定の記憶装置と同様に、上記のようなユーザがアクセス可能な大容量記憶装置に関連する媒体でもよい。本開示の様々な実施形態を実装するソフトウェアは、このようなデバイスに記憶されてコア(1740)によって実行されてもよい。コンピュータ読み取り可能媒体は、特定のニーズに従って、1つ以上のメモリデバイス又はチップを含んでもよい。ソフトウェアは、コア(1740)、具体的には、その中のプロセッサ(CPU、GPU、FPGA等を含む)に、RAM(1746)に記憶されたデータ構造を定義し、ソフトウェアによって定義された処理に従ってこのようなデータ構造を修正することを含む、本明細書に記載の特定の処理又は特定の処理の特定の部分を実行させてもよい。さらに或いは代替として、コンピュータシステムは、回路(例えば、アクセラレータ(1744))内に配線されたロジック又は他の方法で具現されたロジックの結果として、機能を提供してもよく、当該回路は、本明細書に記載の特定の処理又は特定の処理の特定の部分を実行するために、ソフトウェアの代わりに或いはソフトウェアと共に動作してもよい。ソフトウェアへの言及は、ロジックを含み、必要に応じて、その逆も可能である。コンピュータ読み取り可能媒体への言及は、必要に応じて、実行するためのソフトウェアを記憶する回路(集積回路(IC)等)、実行するためのロジックを具現する回路又はこれらの双方を含んでもよい。本開示は、ハードウェア及びソフトウェアのいずれかの適切な組み合わせを含む。
本開示は、いくつかの例示的な実施形態を記載しているが、本開示の範囲内に入る変更、置換及び様々な代替の等価物が存在する。したがって、当業者は、本明細書に明示的に図示又は記載されていないが、本開示の原理を具現し、したがって、本開示の真意及び範囲内にある多数のシステム及び方法を考案することができることが認識される。
[付録A:略語]
AMVP: Advanced Motion Vector Prediction
ASIC: Application-Specific Integrated Circuit
BMS: Benchmark Set
BS: Boundary Strength
BV: Block Vector
CANBus: Controller Area Network Bus
CD: Compact Disc
CPR: Current Picture Referencing
CPU: Central Processing Unit
CRT: Cathode Ray Tube
CTB: Coding Tree Block
CTU: Coding Tree Unit
CU: Coding Unit
DPB: Decoder Picture Buffer
DVD: Digital Video Disc
FPGA: Field Programmable Gate Areas
GOP: Group of Picture
GPU: Graphics Processing Unit
GSM: Global System for Mobile communications
HDR: High Dynamic Range
HEVC: High Efficiency Video Coding
HRD: Hypothetical Reference Decoder
IBC: Intra Block Copy
IC: Integrated Circuit
JEM: Joint Exploration Model
LAN: Local Area Network
LCD: Liquid-Crystal Display
LIC: Local Illumination Compensation
LTE: Long-Term Evolution
MR-SAD: Mean-Removed Sum of Absolute Difference
MR-SATD: Mean-Removed Sum of Absolute Hadamard-Transformed Difference
MV: Motion Vector
OLED: Organic Light-Emitting Diode
PB: Prediction Block
PCI: Peripheral Component Interconnect
PLD: Programmable Logic Device
PPS: Picture Parameter Set
PU: Prediction Unit
RAM: Random Access Memory
ROM: Read-Only Memory
SCC: Screen Content Coding
SDR: Standard Dynamic Range
SEI: Supplementary Enhancement Information
SMVP: Spatial Motion Vector Predictor
SNR: Signal Noise Ratio
SPS: Sequence Parameter Set
SSD: Solid-state Drive
TMVP: Temporal Motion Vector Predictor
TU: Transform Unit
USB: Universal Serial Bus
VUI: Video Usability Information
VVC: Versatile Video Coding