(57)【要約】コーディング方法が提供される。方法は、符号器によって実装され得る。方法は、現在のインタブロックに対する利用可能な重みを重みサブセットに分けることと、重みサブセットの１つを選択することと、選択された重みサブセットの１つを識別するために使用される重みサブセットインデックスを含む重みサブセットフラグをビットストリームの特定の部分内に符号化することと、重みサブセットフラグを含むビットストリームを復号化デバイスへ送信することとを含む。
2020520174.tif 000002
【特許請求の範囲】
【請求項１】
復号器によって実装されるコーディング方法であって、
特定の部分において重みサブセットフラグを含むビットストリームを受信することと、
現在のインタブロックに対する利用可能な重みのサブセットを有する重みサブセットを、前記重みサブセットフラグを用いて識別することと、
電子デバイスのディスプレイ上で、前記重みサブセットフラグによって識別された前記重みサブセットを用いて生成される画像を表示することと
を有する方法。
【請求項２】
前記利用可能な重みは、一般化された双予測（ＧＢｉ）に対応する、
請求項１に記載の方法。
【請求項３】
前記特定の部分は、前記ビットストリームのシーケンス・パラメータ・セット（ＳＰＳ）レベルである、
請求項１に記載の方法。
【請求項４】
前記特定の部分は、前記ビットストリームのピクチャ・パラメータ・セット（ＰＰＳ）レベルである、
請求項１に記載の方法。
【請求項５】
前記特定の部分は、前記ビットストリームのスライスヘッダである、
請求項１に記載の方法。
【請求項６】
前記特定の部分は、コーディング・ツリー・ユニット（ＣＴＵ）又はＣＴＵのグループによって表される前記ビットストリームの領域である、
請求項１に記載の方法。
【請求項７】
前記現在のブロックに対する前記利用可能な重みは、−１／４、１／４、３／８、１／２、５／８、３／４、及び５／４に加えて少なくとも１つの重みを含む、
請求項１に記載の方法。
【請求項８】
符号器によって実装されるコーディング方法であって、
現在のインタブロックに対する利用可能な重みを重みサブセットに分けることと、
前記重みサブセットの１つを選択することと、
選択された前記重みサブセットの前記１つを識別するために使用される重みサブセットインデックスを含む重みサブセットフラグをビットストリームの特定の部分内に符号化することと、
前記重みサブセットフラグを含む前記ビットストリームを復号化デバイスへ送信することと
を有する方法。
【請求項９】
選択された前記重みサブセットの前記１つは、単一の重みしか含まない、
請求項８に記載の方法。
【請求項１０】
前記現在のインタブロックに対する前記利用可能な重みを前記重みサブセットに分けるステップは、前記利用可能な重みを最初により大きい重みサブセットに分けてから、該より大きい重みサブセットを、前記重みサブセットを形成するように分けることを有する、
請求項８に記載の方法。
【請求項１１】
選択された前記重みサブセットの前記１つから単一の重みを選択することを更に有する、
請求項１０に記載の方法。
【請求項１２】
前記特定の部分は、前記ビットストリームのシーケンス・パラメータ・セット（ＳＰＳ）レベル及び前記ビットストリームのピクチャ・パラメータ・セット（ＰＰＳ）レベル、前記ビットストリームのスライスヘッダ、並びにコーディング・ツリー・ユニット（ＣＴＵ）又はＣＴＵのグループによって表される前記ビットストリームの領域、の中の１つ以上である、
請求項８に記載の方法。
【請求項１３】
前記重みサブセットフラグにおけるビンの数が前記重みサブセットインデックスにおける重みの数よりも１少ないように、可変長符号化を用いて前記重みサブセットフラグを符号化することを更に有する、
請求項８に記載の方法。
【請求項１４】
前記重みサブセットフラグにおけるビンの数が前記重みサブセットインデックスにおける重みの数よりも少なくとも２少ないように、固定長符号化を用いて前記重みサブセットフラグを符号化することを更に有する、
請求項８に記載の方法。
【請求項１５】
特定の部分において重みサブセットフラグを含むビットストリームを受信するよう構成される受信器と、
前記受信器へ結合され、命令を含むメモリと、
前記メモリへ結合され、前記メモリに記憶されている前記命令を実行して、
前記特定の部分において前記重みサブセットフラグを取得するように前記ビットストリームをパースし、
現在のインタブロックに対する利用可能な重みのサブセットを有する重みサブセットを、前記重みサブセットフラグを用いて識別する
よう構成されるプロセッサと、
前記プロセッサへ結合され、前記重みサブセットに基づいて生成される画像を表示するよう構成されるディスプレイと
を有するコーディング装置。
【請求項１６】
前記特定の部分は、前記ビットストリームのシーケンス・パラメータ・セット（ＳＰＳ）レベルである、
請求項１５に記載のコーディング装置。
【請求項１７】
前記特定の部分は、前記ビットストリームのピクチャ・パラメータ・セット（ＰＰＳ）レベルである、
請求項１５に記載のコーディング装置。
【請求項１８】
前記特定の部分は、前記ビットストリームのスライスヘッダである、
請求項１５に記載のコーディング装置。
【請求項１９】
前記特定の部分は、コーディング・ツリー・ユニット（ＣＴＵ）又はＣＴＵのグループによって表される前記ビットストリームの領域である、
請求項１５に記載のコーディング装置。
【請求項２０】
前記利用可能な重みは、一般化された双予測（ＧＢｉ）で使用される全ての重みを有する、
請求項１５に記載のコーディング装置。
【発明の詳細な説明】
【背景技術】
【０００１】
比較的に短い映像でさえ描くのに必要とされる映像データの量はかなりであり、このことは、限られた帯域幅容量で通信ネットワークにわたってデータがストリーミング又は別なふうに通信されるべきである場合に困難をもたらすことがある。よって、映像データは一般的に、今日の電気通信ネットワークにわたって通信される前に、圧縮される。メモリ資源は有限である場合があるので、映像が記憶デバイスに記憶されるときに、映像のサイズも問題になる可能性がある。映像圧縮デバイスはしばしば、ソース側でソフトウェア及び／又はハードウェアを使用して、映像データを送信又は記憶の前に符号化し、それによって、デジタルビデオ画像を表現するのに必要なデータの量を減らす。圧縮されたデータは次いで、映像データを復号する映像圧縮解除デバイスによって送り先側で受信される。限られたネットワーク資源と、高品質の映像の需要の高まりとにより、画像品質を全く又はほとんど犠牲にせずに圧縮比を改善する改善された圧縮及び圧縮解除技術が望ましい。
【発明の概要】
【０００２】
本開示の一態様によれば、復号器によって実装されるコーディング方法が提供される。方法は、特定の部分において重みサブセットフラグを含むビットストリームを受信することと、現在のインタブロックに対する利用可能な重みのサブセットを有する重みサブセットを、前記重みサブセットフラグを用いて識別することと、電子デバイスのディスプレイ上で、前記重みサブセットフラグによって識別された前記重みサブセットを用いて生成される画像を表示することとを含む。
【０００３】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記利用可能な重みが一般化された双予測（ＧＢｉ）に対応することを提供する。
【０００４】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記特定の部分が前記ビットストリームのシーケンス・パラメータ・セット（ＳＰＳ）レベルであることを提供する。
【０００５】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記特定の部分が前記ビットストリームのピクチャ・パラメータ・セット（ＰＰＳ）レベルであることを提供する。
【０００６】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記特定の部分が前記ビットストリームのスライスヘッダであることを提供する。
【０００７】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記特定の部分が、コーディング・ツリー・ユニット（ＣＴＵ）又はＣＴＵのグループによって表される前記ビットストリームの領域であることを提供する。
【０００８】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記現在のブロックに対する前記利用可能な重みが、−１／４、１／４、３／８、１／２、５／８、３／４、及び５／４に加えて少なくとも１つの重みを含むことを提供する。
【０００９】
本開示の一態様によれば、符号器によって実装されるコーディング方法が提供される。方法は、現在のインタブロックに対する利用可能な重みを重みサブセットに分けることと、前記重みサブセットの１つを選択することと、選択された前記重みサブセットの前記１つを識別するために使用される重みサブセットインデックスを含む重みサブセットフラグをビットストリームの特定の部分内に符号化することと、前記重みサブセットフラグを含む前記ビットストリームを復号化デバイスへ送信することとを含む。
【００１０】
任意に、上記の態様のいずれかで、その態様の他の実施は、選択された前記重みサブセットの前記１つが単一の重みしか含まないことを提供する。
【００１１】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記現在のインタブロックに対する前記利用可能な重みを前記重みサブセットに分けるステップが、前記利用可能な重みを最初により大きい重みサブセットに分けてから、該より大きい重みサブセットを、前記重みサブセットを形成するように分けることを有することを提供する。
【００１２】
任意に、上記の態様のいずれかで、その態様の他の実施は、選択された前記重みサブセットの前記１つから単一の重みを選択することを提供する。
【００１３】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記特定の部分が、前記ビットストリームのシーケンス・パラメータ・セット（ＳＰＳ）レベル及び前記ビットストリームのピクチャ・パラメータ・セット（ＰＰＳ）レベル、前記ビットストリームのスライスヘッダ、並びにコーディング・ツリー・ユニット（ＣＴＵ）又はＣＴＵのグループによって表される前記ビットストリームの領域、の中の１つ以上であることを提供する。
【００１４】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記重みサブセットフラグにおけるビンの数が前記重みサブセットインデックスにおける重みの数よりも１少ないように、可変長符号化を用いて前記重みサブセットフラグを符号化することを提供する。
【００１５】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記重みサブセットフラグにおけるビンの数が前記重みサブセットインデックスにおける重みの数よりも少なくとも２少ないように、固定長符号化を用いて前記重みサブセットフラグを符号化することを提供する。
【００１６】
本開示の一態様によれば、コーディング装置が提供される。コーディング装置は、特定の部分において重みサブセットフラグを含むビットストリームを受信するよう構成される受信器と、前記受信器へ結合され、命令を含むメモリと、前記メモリへ結合され、前記メモリに記憶されている前記命令を実行して、前記特定の部分において前記重みサブセットフラグを取得するように前記ビットストリームをパースし、現在のインタブロックに対する利用可能な重みのサブセットを有する重みサブセットを、前記重みサブセットフラグを用いて識別するよう構成されるプロセッサと、前記プロセッサへ結合され、前記重みサブセットに基づいて生成される画像を表示するよう構成されるディスプレイとを含む。
【００１７】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記特定の部分が前記ビットストリームのシーケンス・パラメータ・セット（ＳＰＳ）レベルであることを提供する。
【００１８】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記特定の部分が前記ビットストリームのピクチャ・パラメータ・セット（ＰＰＳ）レベルであることを提供する。
【００１９】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記特定の部分が前記ビットストリームのスライスヘッダであることを提供する。
【００２０】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記特定の部分が、コーディング・ツリー・ユニット（ＣＴＵ）又はＣＴＵのグループによって表される前記ビットストリームの領域であることを提供する。
【００２１】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記利用可能な重みが、一般化された双予測（ＧＢｉ）で使用される全ての重みを有することを提供する。
【００２２】
明りょうさのために、上記の実施形態のいずれか１つは、本開示の適用範囲内で新しい実施形態をもたらすように、上記の他の実施形態のいずれか１つ以上と組み合わされてよい。
【００２３】
これら及び他の特徴は、添付の図面及び特許請求の範囲と結び付けられた以下の詳細な説明から、より明りょうに理解されるだろう。
【００２４】
本開示のより完全な理解のために、これより、添付の図面及び詳細な説明と関連して理解される以下の簡単な説明が参照され、このとき、同じ数字は同じ部分を表す。
【図面の簡単な説明】
【００２５】
【図１】双方向予測技術を利用し得るコーディングシステムの例を表すブロック図である。
【図２】双方向予測技術を実装し得るビデオ符号器の例を表すブロック図である。
【図３】双方向予測技術を実装し得るビデオ復号器の例を表すブロック図である。
【図４】現在のブロックと、空間的に隣接した一般化双方向（ＧＢｉ）ブロックとの図である。
【図５】ネットワークデバイスの概略図である。
【図６】コーディング方法の実施形態を表すフローチャートである。
【図７】コーディング方法の実施形態を表すフローチャートである。
【発明を実施するための形態】
【００２６】
１以上の実施形態の実例となる実施が以下で与えられているが、開示されるシステム及び／又は方法は、現在知られているか又は存在しているかにかかわらず、任意の数の技術を用いて実施されてよいことが最初に理解されるべきである。本開示は、本明細書で説明及び記載される例となる設計及び実施を含め、以下で説明される実例となる実施、図面、及び技術に決して制限されるべきではなく、添付の特許請求の範囲の適用範囲内でそれらの均等の全範囲とともに変更されてよい。
【００２７】
図１は、双方向予測技術を利用し得る、例となるコーディングシステム１０を表すブロック図である。図１に示されるように、コーディングシステム１０は、送り先デバイス１４によって後の時点で復号されるべき符号化された映像データを供給するソースデバイス１２を含む。特に、ソースデバイス１２は、映像データを送り先デバイス１４に対してコンピュータ可読媒体１６を介して供給してよい。ソースデバイス１２及び送り先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる“スマート”フォンのような電話送受器、いわゆる“スマート”パッド、テレビ受像機、カメラ、表示デバイス、デジタルメディアプレイヤー、ビデオゲーム機、ビデオストリーミングデバイス、などを含む広範囲のデバイスの中のいずれかを有してよい。いくつかの場合に、ソースデバイス１２及び送り先デバイス１４は、無線通信のために装備されてもよい。
【００２８】
送り先デバイス１４は、復号されるべき符号化された映像データを、コンピュータ可読媒体１６を介して受信してよい。コンピュータ可読媒体１６は、符号化された映像データをソースデバイス１２から送り先デバイス１４へ移動させることができる如何なるタイプの媒体又はデバイスも有してよい。一例では、コンピュータ可読媒体１６は、符号化された映像データを直接に送り先デバイス１４に対してリアルタイムで送信することをソースデバイス１２に可能にする通信媒体を有してよい。符号化された映像データは、無線通信プロトコルのような通信標準に従って変調され、そして、送り先デバイス１４へ送信されてよい。通信媒体は、無線周波数（ＲＦ）スペクトル又は１以上の物理伝送路のような如何なる無線又は有線通信媒体も有してよい。通信媒体は、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、又はインターネットのような世界規模のネットワークのような、パケットに基づくネットワークの部分を形成してよい。通信媒体は、ソースデバイス１２から送り先デバイス１４への通信を助けるのに有用であることができるルータ、スイッチ、基地局、又はあらゆる他の設備を含んでよい。
【００２９】
いくつかの例において、符号化されたデータは、出力インターフェイス２２から記憶デバイスへ出力されてよい。同様に、符号化されたデータは、入力インターフェイスによって記憶デバイスからアクセスされてよい。記憶デバイスは、ハードドライブ、ブルーレイディスク、デジタル・ビデオ・ディスク（ＤＶＤ）、コンパクト・ディスク・リード・オンリー・メモリ（ＣＤ−ＲＯＭ）、フラッシュメモリ、揮発性若しくは不揮発性メモリ、又は符号化された映像データを記憶するためのあらゆる他の適切なデジタル記憶媒体のような、様々な分散した又は局所的にアクセスされるデータ記憶媒体の中のいずれかを含んでよい。更なる例では、記憶デバイスは、ソースデバイス１２によって生成される符号化された映像を記憶し得るファイルサーバ又は他の中間記憶デバイスに対応してよい。送り先デバイス１４は、記憶された映像データに記憶デバイスからストリーミング又はダウンロードによりアクセスしてよい。ファイルサーバは、符号化された映像データを記憶し、その符号化された映像データを送り先デバイス１４へ送信することができる如何なるタイプのサーバであってもよい。ファイルサーバの例には、ウェブサーバ（例えば、ウェブサイト用）、ファイル転送プロトコル（ＦＴＰ）サーバ、ネットワーク・アッタチト・ストレージ（ＮＡＳ）デバイス、又はローカルディスクドライブがある。送り先デバイス１４は、インターネット接続を含む何らかの標準的なデータ接続を通じて、符号化された映像データにアクセスしてよい。これは、ファイルサーバ上に記憶されている符号化された映像データにアクセスすることに適している無線チャネル（例えば、Ｗｉ−Ｆｉ接続）、有線接続（例えば、デジタル加入者回線（ＤＳＬ）、ケーブルモデム、など）、又は両方の組み合わせを含んでよい。記憶デバイスからの符号化された映像データの送信は、ストリーミング伝送、ダウンロード伝送、又はそれらの組み合わせであってよい。
【００３０】
本開示の技術は、無線用途又は設定に必ずしも制限されない。技術は、無線テレビ放送、ケーブルテレビ伝送、衛星テレビ伝送、ダイナミック・アダプティブ・ストリーミング・オーバーＨＴＴＰ（ＤＡＳＨ）のようなインターネットストリーミングビデオ伝送、データ記憶媒体上に符号化されるデジタル映像、データ記憶媒体に記憶されたデジタル映像の復号化、又は他の応用のような、様々なマルチメディアアプリケーションの中のいずれかを支持して映像コーディングに適用され得る。いくつかの例において、コーディングシステム１０は、映像ストリーミング、映像再生、映像放送、及び／又はテレビ電話のような用途をサポートするために一方向又は双方向の映像伝送をサポートするよう構成されてよい。
【００３１】
図１の例において、ソースデバイス１２は、ビデオソース１８、ビデオ符号器２０、及び出力インターフェイス２２を含む。送り先デバイス１４は、入力インターフェイス２８、ビデオ復号器３０、及び表示デバイス３２を含む。本開示によれば、ソースデバイス１２のビデオ符号器２０及び／又は送り先デバイス１４のビデオ復号器３０は、双方向予測の技術を適用するよう構成されてよい。他の例では、ソースデバイス及び送り先デバイスは、他の構成要素又は配置を含んでもよい。例えば、ソースデバイス１２は、外部カメラのような外部ビデオソースから映像データを受信してよい。同様に、送り先デバイス１４は、一体化された表示デバイスを含むのではなく、外付けの表示デバイスとインターフェイス接続してよい。
【００３２】
図１の表されているコーディングシステム１０は、単に一例にすぎない。双方向予測の技術は、如何なるデジタルビデオ符号化及び／又は復号化デバイスによっても実行されてよい。本開示の技術は一般的にビデオコーディングデバイスによって実行されるが、本技術は、通常「ＣＯＤＥＣ」と呼ばれるビデオ符号器／復号器によっても実行されてよい。更に、本開示の技術は、ビデオプロセッサによっても実行されてよい。ビデオ符号器及び／又は復号器は、グラフィクス処理ユニット（ＧＰＵ）又は同様のデバイスであってよい。
【００３３】
ソースデバイス１２及び送り先デバイス１４は、単に、ソースデバイス１２が符号化された映像データを送り先デバイス１４への送信のために生成するところのそのようなコーディングデバイスの例にすぎない。いくつかの例において、ソースデバイス１２及び送り先デバイス１４は、ソースデバイス１２及び送り先デバイス１４の夫々がビデオ符号化及び復号化コンポーネントを含むように、実質的に対称的な様態で動作してよい。従って、コーディングシステム１０は、例えば、映像ストリーミング、映像再生、映像放送、又はテレビ電話のために、映像デバイス１２、１４の間の一方向又は双方向の伝送をサポートし得る。
【００３４】
ソースデバイス１２のビデオソース１８は、ビデオカメラのような映像捕捉デバイス、以前に捕捉された映像を含む映像アーカイブ、及び／又は映像コンテンツプロバイダから映像を受信する動画配信インターフェイスを含んでよい。更なる代替案として、ビデオソース１８は、ソースビデオのようなコンピュータグラフィクスに基づくデータ、又はライブ映像と、アーカイブ映像と、コンピュータにより生成された映像との組み合わせを生成し得る。
【００３５】
いくつかの場合に、ビデオソース１８がビデオカメラである場合に、ソースデバイス１２及び送り先デバイス１４は、いわゆるカメラ付き電話機又はテレビ電話機を形成し得る。なお、上述されたように、本開示で記載される技術は、映像コーディング全般に適用可能であり、無線及び／又は有線用途に適用されてよい。夫々の場合に、捕捉された、事前に捕捉された、又はコンピュータにより生成された映像は、ビデオ符号器２０によって符号化されてよい。符号化された映像情報は、次いで、出力インターフェイス２２によってコンピュータ可読媒体１６上に出力されてよい。
【００３６】
コンピュータ可読媒体１６は、無線放送若しくは有線ネットワーク伝送のような一時的な媒体、又はハードディスク、フラッシュドライブ、コンパクト・ディスク、デジタル・ビデオ・ディスク、ブルーレイディスク、若しくは他のコンピュータ可読媒体のような記憶媒体（すなわち、非一時的な記憶媒体）を含んでよい。いくつかの例において、ネットワークサーバ（図示せず。）は、符号化された映像データをソースデバイス１２から受信し、符号化された映像データを送り先デバイス１４に対して、例えば、ネットワーク伝送を介して、供給してよい。同様に、ディスク刻印設備のような媒体製造設備のコンピュータデバイスは、符号化された映像データをソースデバイス１２から受信し、符号化された映像データを含むディスクを製造し得る。従って、コンピュータ可読媒体１６は、様々な例において、様々な形の１以上のコンピュータ可読媒体を含むと理解され得る。
【００３７】
送り先デバイス１４の入力インターフェイス２８は、コンピュータ可読媒体１６から情報を受信する。コンピュータ可読媒体１６の情報は、ビデオ符号器２０によって定義されたシンタックス情報を含んでよく、これは、ビデオ復号器３０によっても使用され、ブロック及び他の符号化単位、例えば、グループ・オブ・ピクチャ（ＧＯＰ）の特性及び／又は処理を記述するシンタックス要素を含む。表示デバイス３２は、復号された映像データをユーザに表示し、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、又は他のタイプの表示デバイスのような様々な表示デバイスの中のいずれかを有してよい。
【００３８】
ビデオ符号器２０及びビデオ復号器３０は、目下開発中である高能率映像符号化（ＨＥＶＣ）標準のような映像符号化標準に従って動作してよく、ＨＥＶＣテストモデル（ＨＭ）に準拠してよい。代替的に、ビデオ符号器２０及びビデオ復号器３０は、モーション・ピクチャ・エキスパート・グループ（ＭＰＥＧ）−４、パート１０、アドバンスト・ビデオ・コーディング（ＡＶＣ）と代替的に呼ばれる国際電気通信連合電気通信標準化部門（ＩＴＵ−Ｔ）Ｈ．２６４標準、Ｈ．２６５／高能率映像符号化（ＨＥＶＣ）、又はそのような標準の拡張のような、他の独自仕様又は業界標準に従って動作してもよい。なお、本開示の技術は、如何なる特定の符号化標準にも制限されない。映像符号化標準の他の例には、ＭＰＥＧ−２及びＩＴＵ−Ｔ  Ｈ．２６３がある。図１に示されていないが、いくつかの態様において、ビデオ符号器２０及びビデオ復号器３０は、オーディオ符号器及び復号器と夫々一体化されてもよく、共通のデータストリーム又は別個のデータストリームにおける音声及び映像の両方の符号化を扱うために、適切なマルチプレクサ−デマルチプレクサ（ＭＵＸ−ＤＥＭＵＸ）ユニット、又は他のハードウェア及びソフトウェアを含んでもよい。適用可能な場合には、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ  Ｈ．２２３マルチプレクサプロトコル、又はユーザ・データグラム・プロトコル（ＵＤＰ）のような他のプロトコルに準拠してよい。
【００３９】
ビデオ符号器２０及びビデオ復号器３０は、１以上のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、ディスクリートロジック、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組み合わせのような、様々な適切な符号器回路の中のいずれかとして夫々実装されてよい。技術が部分的にソフトウェアにおいて実装される場合に、デバイスは、適切な非一時的コンピュータ可読媒体にソフトウェアの命令を記憶し、１以上のプロセッサを用いてハードウェアで命令を実行して、本開示の技術を実行し得る。ビデオ符号器２０及びビデオ復号器３０の夫々は、１以上の符号器又は復号器に含まれてよく、それらのうちのいずれか一方は、各々のデバイスにおいて複合的符号器／復号器（ＣＯＤＥＣ）の部分として組み込まれてよい。ビデオ符号器２０及び／又はビデオ復号器３０を含むデバイスは、集積回路、マイクロプロセッサ、及び／又は携帯電話機のような無線通信デバイスを有してよい。
【００４０】
図２は、双方向予測技術を実装し得るビデオ符号器２０を例示するブロック図である。ビデオ符号器２０は、ビデオスライス内のビデオブロックのイントラ及びインタコーディングを実行してよい。イントラコーディングは、所与のビデオフレーム又はピクチャ内で映像の空間的冗長性を低減又は除去するよう空間予測に依存する。インタコーディングは、ビデオシーケンスの隣接したフレーム又はピクチャ内で映像の時間的冗長性を低減又は除去するよう時間予測に依存する。イントラモード（Ｉモード）は、いくつかの空間ベースの符号化モードの中のいずれかを指し得る。一方向予測（Ｐモード）又は双予測（Ｂモード）のようなインタモードは、いくつかの時間ベースの符号化モードの中のいずれかを指し得る。
【００４１】
図２に示されるように、ビデオ符号器２０は、符号化されるべきビデオフレーム内の現在のビデオブロックを受信する。図２の例では、ビデオ符号器２０は、モード選択ユニット４０、参照フレームメモリ６４、加算器５０、変換処理ユニット５２、量子化ユニット５４、及びエントロピ符号化ユニット５６を含む。次いで、モード選択ユニット４０は、動き補償ユニット４４、動き推定ユニット４２、イントラ予測ユニット４６、及びパーティションユニット４８を含む。ビデオブロック再構成のために、ビデオ符号器２０は更に、逆量子化ユニット５８、逆変換ユニット６０、及び加算器６２を含む。デブロッキングフィルタ（図２に図示せず。）も、ブロック境界にフィルタをかけて、再構成された映像からブロック境界アーチファクトを除くために含まれてよい。必要ならば、デブロッキングフィルタは、通常は、加算器６２の出力にフィルタをかけることになる。追加のフィルタ（ループ内又はループ後）も、デブロッキングフィルタに加えて使用されてよい。そのようなフィルタは、簡潔さのために図示されないが、必要ならば、（ループ内フィルタとして）加算器５０の出力にフィルタをかけてもよい。
【００４２】
符号化プロセス中に、ビデオ符号器２０は、符号化されるべきビデオフレーム又はスライスを受信する。フレーム又はスライスは、複数のビデオブロックに分割されてよい。動き推定ユニット４２及び動き補償ユニット４４は、時間予測を提供するために１以上の参照フレーム内の１以上のブロックに対する受信されたビデオブロックのインタ予測符号化を実行する。イントラ予測ユニット４６が代替的に、空間予測を提供するために、符号化されるべきブロックと同じフレーム又はスライス内の１以上の隣接ブロックに対する受信されたビデオブロックのイントラ予測符号化を実行してもよい。ビデオ符号器２０は、例えば、ビデオデータの各ブロックごとに適切な符号化モードを選択するために、複数の符号化パスを実行してよい。
【００４３】
更に、パーティションユニット４８は、前の符号化パスにおける前の区分化スキームの評価に基づいて、ビデオのブロックをサブブロックに区分化し得る。例えば、パーティションユニット４８は最初に、フレーム又はスライスを最大符号化単位（ＬＣＵ）に区分化し、そして、レートひずみ解析（例えば、レートひずみ最適化）に基づいてＬＣＵの夫々をサブ符号化単位（ｓｕｂ−ＣＵ）に区分化してよい。モード選択ユニット４０は、サブＣＵへのＬＣＵの区分化を示す四分木データ構造を更に生成し得る。四分木のリーフノードＣＵは、１以上の予測単位（ＰＵ）及び１以上の変換単位（ＴＵ）を含み得る。
【００４４】
本開示は、ＨＥＶＣとの関連でＣＵ、ＰＵ、又はＴＵのいずれかに、あるいは、他の標準との関連で同様のデータ構造（例えば、Ｈ．２６４／ＡＶＣにおけるマクロブロック及びそのサブブロック）に言及するために、語「ブロック」を使用する。ＣＵは、符号化ノードと、符号化ノードに関連したＰＵ及びＴＵとを含む。ＣＵのサイズは、符号化ノードのサイズに対応し、正方形である。ＣＵのサイズは、８×８画素から、最大で６４×６４画素以上のツリーブロックのサイズまでの範囲をとり得る。各ＣＵは、１以上のＰＵ及び１以上のＴＵを含み得る。ＣＵに関連したシンタックスデータは、例えば、１以上のＰＵへのＣＵの区分化を記述し得る。区分化モードは、ＣＵがスキップ又は直接ダイレクトモードで符号化されるか、イントラ予測モードで符号化されるか、あるいは、インタ予測モードで符号化されるかによって異なり得る。ＰＵは、形状が正方形でないように区分化されてもよい。ＣＵに関連したシンタックスデータはまた、例えば、四分木に従う１以上のＴＵへのＣＵの区分化を記述し得る。ＴＵは、正方形又は非正方形（例えば、長方形）であることができる。
【００４５】
モード選択ユニット４０は、例えば、エラー結果に基づいて、符号化モードの１つ、イントラ又はインタを選択し、得られたイントラ又はインタ符号化されたブロックを、残差ブロックを生成するために加算器５０へ、そして、参照フレームとして使用される符号化されたブロックを再構成するために加算器６２へ供給する。モード選択ユニット４０はまた、動きベクトル、イントラモードインジケータ、パーティション情報、及び他のそのようなシンタックス情報などのシンタックス要素をエントロピ符号化ユニット５６へ供給する。
【００４６】
動き推定ユニット４２及び動き補償ユニット４４は高度に集積され得るが、概念上別々に表されている。動き推定ユニット４２によって実行される動き推定は、動きベクトルを生成するプロセスであり、ビデオブロックの動きを推定する。動きベクトルは、例えば、現在のフレーム内の符号化される現在のブロック（又は他の符号化単位）に対する基準フレーム内の予測ブロック（又は他の符号化単位）に対する現在のビデオフレーム又はピクチャ内のビデオブロックのＰＵの変位を示し得る。予測ブロックは、差分絶対値和（ＳＡＤ）、差分二乗和（ＳＳＤ）、又は他の差分メトリクスによって決定され得る画素差に関して、符号化されるブロックに一致することが判明したブロックである。いくつかの例において、ビデオ符号器２０は、参照フレームメモリ６４に記憶されている参照ピクチャのサブ整数画素位置について値を計算してよい。例えば、ビデオ符号器２０は、参照画素の４分の１画素位置、８分の１画素位置、又は他の分数画素位置の値を補間し得る。従って、動き推定ユニット４２は、全画素位置及び分数画素位置に対して動き探索を実行し、分数画素精度で動きベクトルを出力し得る。
【００４７】
動き推定ユニット４２は、インタ符号化されたスライスにおけるビデオブロックのＰＵについて、ＰＵの位置を参照ピクチャの予測ブロックの位置と比較することによって、動きベクトルを計算する。参照ピクチャは、第１参照ピクチャリスト（リスト０）又は第２参照ピクチャリスト（リスト１）から選択されてよく、それらのリストの夫々は、参照フレームメモリ６４に記憶されている１以上の参照ピクチャを特定する。動き推定ユニット４２は、計算された動きベクトルをエントロピ符号化ユニット５６及び動き補償ユニット４４へ送信する。
【００４８】
動き補償ユニット４４によって実行される動き補償は、動き推定ユニット４２によって決定された動きベクトルに基づいて予測ブロックをフェッチ又は生成することを含んでよい。やはり、動き推定ユニット４２及び動き補償ユニット４４は、いくつかの例では、機能的に集積されてよい。現在のビデオブロックのＰＵの動きベクトルを受け取ると、動き補償ユニット４４は、動きベクトルが参照ピクチャリストの一方において指し示す予測ブロックを見つけ得る。加算器５０は、後述されるように、符号化される現在のビデオブロックの画素値から予測ブロックの画素値を減じて画素差分値を形成することによって、残差ビデオブロックを形成する。一般に、動き推定ユニット４２は、ルマ成分に対して動き推定を実行し、動き補償ユニット４４は、ルマ成分に基づき計算された動きベクトルをクロマ成分及びルマ成分の両方に対して使用する。モード選択ユニット４０はまた、ビデオスライスのビデオブロックを復号する際にビデオ復号器３０によって使用されるように、ビデオブロック及びビデオスライスに関連したシンタックス要素を生成し得る。
【００４９】
イントラ予測ユニット４６は、上述された、動き推定ユニット４２及び動き補償ユニット４４によって実行されるインタ予測の代わりとして、現在のブロックをイントラ予測し得る。特に、イントラ予測ユニット４６は、現在のブロックを符号化するために使用するイントラ予測モードを決定し得る。いくつかの例において、イントラ予測ユニット４６は、例えば、別個の符号化パスの間に、様々なイントラ予測モードを用いて現在のブロックを符号化してよく、イントラ予測ユニット４６（又は、いくつかの例では、モード選択ユニット４０）は、テストされたモードから、使用する適切なイントラ予測モードを選択してよい。
【００５０】
例えば、イントラ予測ユニット４６は、テストされた様々なイントラ予測モードについてレートひずみ解析によりレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有しているイントラ予測モードを選択してよい。レートひずみ解析は、一般的に、符号化されたブロックと、符号化されたブロックを生成するために符号化された元の、符号化されていないブロックとの間のひずみ（又はエラー）の量とともに、符号化されたブロックを生成するために使用されたビットレート（すなわち、ビットの数）を決定する。イントラ予測ユニット４６は、様々な符号化されたブロックについて、ひずみ及びレートから比率を計算して、どのイントラ予測モードがそのブロックに対して最良のレートひずみ値を示すかを決定し得る。
【００５１】
更に、イントラ予測ユニット４６は、デプス・モデリング・モード（ＤＭＭ）を用いてデプスマップのデプスブロックを符号化するよう構成されてよい。モード選択ユニット４０は、例えば、レートひずみ最適化（ＲＯＤ）を用いて、利用可能なＤＭＭモードがイントラ予測モード及び他のＤＭＭモードよりも良い符号化結果をもたらすかどうかを決定し得る。デプスマップに対応するテクスチャ画像のデータは、参照フレームメモリ６４に記憶され得る。動き推定ユニット４２及び動き補償ユニット４４はまた、デプスマップのデプスブロックをインタ予測するよう構成されてよい。
【００５２】
ブロックに対してイントラ予測モード（例えば、従来のイントラ予測モード又はＤＭＭモードの１つ）を選択した後、イントラ予測ユニット４６は、そのブロックに対する選択されたイントラ予測モードを示す情報をエントロピ符号化ユニット５６へ供給してよい。エントロピ符号化ユニット５６は、選択されたイントラ予測モードを示す情報を符号化し得る。ビデオ符号器２０は、複数のイントラ予測モードインデックステーブル及び複数の変更されたイントラ予測モードインデックステーブル（コードワードマッピングテーブルとも呼ばれる。）と、様々なブロックについてのコンテキストの符号化の定義と、コンテキストの夫々のために使用すべき最も確からしいイントラ予測モード、イントラ予測モードインデックステーブル、及び変更されたイントラ予測モードインデックステーブルの表示とを含み得るコンフィグレーションデータを、送信されるビットストリームに含めてよい。
【００５３】
ビデオ符号器２０は、モード選択ユニット４０からの予測データを、符号化される元のビデオデータから減じることによって、残差ビデオブロックを形成する。加算器５０は、この減算を実行する１以上の構成要素を表す。
【００５４】
変換処理ユニット５２は、離散コサイン変換（ＤＣＴ）又は概念的に類似した変換のような変換を残差ブロックに適用して、残差変換係数値を含むビデオブロックを生成する。変換処理ユニット５２は、ＤＣＴ苦い年上類似している他の変換を実行してもよい。ウェーブレット変換、整数変換、サブバンド変換又は他のタイプの変換も使用され得る。
【００５５】
変換処理ユニット５２は、変換を残差ブロックに適用して、残差変換係数のブロックを生成する。変換は、残差情報を画素値領域から、周波数領域のような変換領域へと変換し得る。変換処理ユニット５２は、得られた変換係数を量子化ユニット５４へ送信し得る。量子化ユニット５４は、ビットレートを更に低減するように変換係数を量子化する。量子化プロセスは、一部又は全ての係数に関連したビットデプスを低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例において、量子化ユニット５４は次いで、量子化された変換係数を含む行列の走査を実行してよい。代替的に、エントロピ符号化ユニット５６が走査を実行してもよい。
【００５６】
量子化に続いて、エントロピ符号化ユニット５６は、量子化された変換係数をエントロピ符号化する。例えば、エントロピ符号化ユニット５６は、コンテキスト適応型可変長符号化（ＣＡＶＬＣ）、コンテキスト適応型２進演算符号化（ＣＡＢＡＣ）、シンタックスに基づくコンテキスト適応型２進演算符号化（ＳＢＡＣ）、確率区間区分エントロピ（ＰＩＰＥ）符号化又は他のエントロピ符号化技術を実行してよい。コンテキストに基づくエントロピ符号化の場合に、コンテキストは、隣接するブロックに基づき得る。エントロピ符号化ユニット５６によるエントロピ符号化に続いて、符号化されたビットストリームは、他のデバイス（例えば、ビデオ復号器３０）へ送信されても、あるいは、後の送信又は取り出しのためにアーカイブに保管されてもよい。
【００５７】
逆量子化ユニット５８及び逆変換ユニット６０は、例えば、参照ブロックとしての後の使用のために、画素領域において残差ブロックを再構成するように逆量子化及び逆変換を夫々適用する。動き補償ユニット４４は、参照フレームメモリ６４のフレームの中の１フレームの予測ブロックに対して残差ブロックを加えることによって、参照ブロックを計算し得る。動き補償ユニット４４はまた、動き推定における使用のためにサブ整数画素値を計算するように、再構成された残差ブロックに対して１以上の補間フィルタを適用してよい。加算器６２は、動き補償ユニット４４によって生成された動き補償された予測ブロックに対して再構成された残差ブロックを加えて、参照フレームメモリ６４での記憶のために、再構成されたビデオブロックを生成する。再構成されたビデオブロックは、その後のビデオフレームにおけるブロックをインタ符号化するために参照ブロックとして動き推定ユニット４２及び動き補償ユニット４４によって使用されてよい。
【００５８】
図３は、双方向予測技術を実装し得るビデオ復号器３０を例示するブロック図である。図３の例では、ビデオ復号器３０は、エントロピ復号化ユニット７０、動き補償ユニット７２、イントラ予測ユニット７４、逆量子化ユニット７６、逆変換ユニット７８、参照フレームメモリ８２、及び加算器８０を含む。ビデオ復号器３０は、いくつかの例において、ビデオ符号器２０（図２）に関して記載された符号化パスとは概して逆の復号化パスを実行し得る。動き補償ユニット７２は、エントロピ復号化ユニット７０から受け取られた動きベクトルに基づいて予測データを生成してよく、一方、イントラ予測ユニット７４は、エントロピ復号化ユニット７０から受け取られたイントラ予測モードインジケータに基づいて予測データを生成してよい。
【００５９】
復号化プロセス中に、ビデオ復号器３０は、符号化されたビデオスライスのビデオブロック及び関連するシンタックス要素を表す符号化されたビデオビットストリームをビデオ符号器２０から受信する。ビデオ復号器３０のエントロピ復号化ユニット７０は、ビットストリームを復号して、量子化された係数、動きベクトル又はイントラ予測モードインジケータ、及び他のシンタックス要素を生成する。エントロピ復号化ユニット７０は、動きベクトル及び他のシンタックス要素を動き補償ユニット７２へ転送する。ビデオ復号器３０は、ビデオスライスレベル及び／又はビデオブロックレベルでシンタックス要素を受信し得る。
【００６０】
ビデオスライスがイントラ符号化（Ｉ）スライスとして符号化されているときには、イントラ予測ユニット７４が、信号で伝えられたイントラ予測モードと、現在のフレーム又はピクチャの直前に復号されたブロックからのデータとに基づいて、現在のビデオスライスのビデオブロックについて予測データを生成し得る。ビデオフレームがインタ符号化（すなわち、Ｂ、Ｐ又はＧＰＢ）スライスとして符号化されているときには、動き補償ユニット７２が、エントロピ復号化ユニット７０から受け取られた動きベクトル及び他のシンタックス要素に基づいて、現在のビデオスライスのビデオブロックについて予測ブロックを生成する。予測ブロックは、参照ピクチャリストの１つの中の参照ピクチャの１つから生成され得る。ビデオ復号器３０は、参照フレームメモリ８２に記憶されている参照ピクチャに基づきデフォルトの構成技術により参照フレームリスト、リスト０及びリスト１、を構成してよい。
【００６１】
動き補償ユニット７２は、現在のビデオスライスのビデオブロックについて、動きベクトル及び他のシンタックス要素をパースすることによって予測情報を決定し、その予測情報を使用して、現在のビデオブロックが復号されるための予測ブロックを生成する。例えば、動き補償ユニット７２は、受け取られたシンタックス要素のいくつかを使用して、ビデオスライスのビデオブロックと、インタ予測スライスタイプ（例えば、Ｂスライス、Ｐスライス、又はＧＰＢスライス）と、スライスのための参照ピクチャリストの１つ以上についての構成情報と、スライスの夫々のインタ符号化されたビデオブロックの動きベクトルと、スライスの夫々のインタ符号化されたビデオブロックのインタ予測ステータスと、現在のビデオスライスにおけるビデオブロックを復号するための他の情報とを符号化するために使用された予測モード（例えば、イントラ又はインタ予測）を決定する。
【００６２】
動き補償ユニット７２はまた、補間フィルタに基づいて補間を実行してもよい。動き補償ユニット７２は、参照ブロックのサブ整数画素についての補間値を計算するためにビデオブロックの符号化中にビデオ符号器２０によって使用された補間フィルタを使用してよい。この場合に、動き補償ユニット７２は、受け取られたシンタックス要素から、ビデオ符号器２０によって使用された補間フィルタを決定し、その補間フィルタを使用して、予測ブロックを生成し得る。
【００６３】
デプスマップに対応するテクスチャ画像のデータが、参照フレームメモリ８２に記憶されてもよい。動き補償ユニット７２はまた、デプスマップのデプスブロックをインタ予測するよう構成されてよい。
【００６４】
当業者に明らかなように、図１のコーディングシステム１０はＧＢｉに適している。ＧＢｉは、ブロックレベル適応重みを用いて２つの動き補償された予測ブロックの加重平均を計算することによってブロックの予測信号を生成するインタ予測技術である。従来の双予測と異なり、ＧＢｉにおける重み（ＧＢｉ重みと呼ばれ得る。）の値は、０．５に制限されない。ＧＢｉのためのインタ予測技術は、次の通りに定式化され得る：
P[x]＝(1−w)×P0[x＋v0]＋ｗ×P1[x＋V1]          （１）
ここで、P[x]は、ピクチャ位置ｘに位置する現在のブロックサンプルの予測を表し、夫々のPi[x＋vi]，∀i∈{0,1}は、参照リストＬｉ内の参照ピクチャからの動きベクトル（ＭＶ）ｖｉに関連した現在のブロックサンプルの動き補償された予測であり、w及び1−wは、夫々、P0[x＋v0]及びP1[x＋v1]に適用される重み値を表す。
【００６５】
ＧＢｉには：
W1＝{3/8,1/2,5/8}、
W2＝W1∪{1/4,3/4}＝{1/4,3/8,1/2,5/8,3/4}、
W3＝W2∪{-1/4,5/4}＝{-1/4,1/4,3/8,1/2,5/8,3/4,5/4}
を含む３つの異なる組の重み候補が存在する。
【００６６】
コーディング中に、ブロックは、ビデオ符号器２０のような符号器によってパーティションに分けられる。例えば、６４×６４ブロックは、３２×３２ブロックに分けられてよい。これらのより小さいブロックは、四分木プラス二分木（ＱＴＢＴ）におけるリーフノードと呼ばれ得る。重み候補の組（例えば、Ｗ１、Ｗ２、又はＷ３）においてｗがどこに位置するかを示すために、インデックスがＱＴＢＴ構造のリーフノードで導入されて、重み候補の組（例えば、Ｗ１、Ｗ２、又はＷ３）においてｗがどこに位置するかを示す。その後に、インデックス２値化は、表１で特定される２つの２値化スキームのうちの１つにより行われる。示されるように、夫々のシーケンスレベルテスト（例えば、テスト１、テスト２、など）は、重み値（例えば、３／８）に対応するインデックス番号（例えば、０、１、２、３、など）と、スキームごとのビン（例えば、０又は１）から形成された２値化コードワード（例えば、００、１、０２、０００１、など）とを含む。
【表１】
2020520174.tif 000003
【００６７】
２値化スキームの選択は、第２参照ピクチャの動きベクトル差分（ＭＶＤ）がゼロに等しく、そのためビットストリームにおいて伝えられないかどうかを示すスライスレベルフラグmvd_l1_zero_flagの値に応じて、スライスごとに適応される。スライスレベルフラグが０に等しい場合には、スキーム＃１が使用される。スライスレベルフラグが１に等しい場合には、スキーム＃２が使用される。２値化コードワードにおける各ビン（例えば、０又は１）は次いで、２値化の後にコンテキスト符号化される。
【００６８】
ｗのこのインデックス（例えば、３／８、１／２、など）は、双予測ブロックがシグナリングＭＶＤを使用する場合に明示的に伝えられる。さもなければ、シンタックスからの追加のオーバヘッドは導入されない。次いで、以下のルールが、夫々のＰＵについて重み値を決定するために適用される。シグナリングＭＶＤ（すなわち、通常のインタ予測モード及びアフィン予測モード）を使用するＱＴＢＴリーフノードにおける夫々の双予測ブロックについて、その重み値は、明示的に伝えられるｗに等しくセットされる。マージモード、高度な時間動きベクトル予測、又はアフィンマージモードで符号化されるＱＴＢＴリーフノードにおける夫々の双予測ブロックについて、その重み値ｗは、関連するマージ候補のために使用される重み値から直接推測される。残りの双予測ブロックについては、それらの重み値は０．５に等しくセットされる。
【００６９】
既存の解決法では、夫々の符号化ブロックについて選択すべき７つの異なる重みが存在する。７つ全ての重みは、最大６つのビンを用いる様々な長さの符号化方法によって明示的に伝えられる。例えば、表１のテスト３の下で、７つの重み（例えば、−１／４、１／４、３／８、１／２、５／８、３／４、５／４）が与えられ、これは、６つのビンを含むコードワード（例えば、００００００、０００００１）を必要とする。いくつかの場合に、映像符号化プロセスで使用される重みが多ければ多いほど、生成される画像品質はますます良い。しかし、使用する重みの数が多くなると、より大きいコードワードが使用されなければならず、符号化の複雑さは増す。
【００７０】
本明細書には、７つの異なる重みの全てよりも少ない重みを使用して様々なレベルで適応重み付け双方向インタ予測を可能にし、実行し、及び信号により伝える方法が開示されている。例えば、本発明者は、局所領域における映像（又は画像）コンテンツがある程度の連続性を有していることに気付いた。従って、７つ全ての重みが符号化される必要はない。むしろ、局所的な又は領域及びブロックに基づいた適応重みが、符号化複雑性を低減し且つ符号化性能を改善するために使用され得る。この本開示は、そうするための方法の組を提示する。
【００７１】
実施形態において、利用可能な全ての重みの一部は選択され、ビットストリームの様々なレベル、例えば、シーケンス・パラメータ・セット（ＳＰＳ）、ピクチャ・パラメータ・セット（ＰＰＳ）、スライスヘッダ、又はコーディング・ツリー・ユニット（ＣＴＵ）若しくはＣＴＵのグループによって表される領域、で信号により伝えられる。本明細書で使用されるように、ＳＰＳはシーケンスレベルと呼ばれてよく、ＰＰＳはパラメータレベルと呼ばれてよく、スライスヘッダはスライスレベルと呼ばれてよい、など。その上、利用可能な重みの一部は、重みサブセット又はＧＢｉ重みサブセットと同義的に呼ばれることがある。
【００７２】
実施形態において、スライスヘッダにおける選択された重みは、ＳＰＳ又はＰＰＳにおける重みの一部であってよい。実施形態において、局所領域（例えば、ＣＴＵ又はＣＴＵのグループ）の選択された重みは、スライスヘッダ又はＳＰＳ若しくはＰＰＳにおける重みの一部であってよい。現在の符号化ブロックの重みは次いで、ＣＴＵ、ＣＴＵのグループ、スライスヘッダ、ＰＰＳ、又はＳＰＳであることができるその親レベルの部分集合から選択される。
【００７３】
３つの重みサブセット及び可変長符号化を使用するシグナリングの例が、説明のために与えられる。そのような場合に、重みサブセットフラグは、３つの重みサブセットインデックスを符号化するために２つのビンを使用する。ここで、Ｍは、重みインデックスの数を表す。そのようなものとして、Ｍ＝３。Ｍ−１個のビンが、選択されたブロック重みインデックスを伝えるために使用される。従って、２値化スキームで使用されるコードワードは、０、１０、１１である。
【表２】
2020520174.tif 000004
【００７４】
４つの重みサブセット及び固定長符号化を使用するシグナリングの他の例が、説明のために与えられる。そのような場合に、重みサブセットフラグは、４つの重みサブセットインデックスを符号化するために２つのビンを使用する。先と同じく、Ｍは、重みインデックスの数を表す。しかし、可変長符号化の例とは異なり、ｌｏｇ２（Ｍ）個のビンが、選択されたブロー重みインデックスを伝えるために使用される。そのようなものとして、Ｍ＝４。従って、２値化スキームで使用されるコードワードは、００、１０、０１、１１である。
【表３】
2020520174.tif 000005
【００７５】
実施形態において、重みサブセットインデックスは、例えば、次のシンタックスを用いるフラグで、シーケンスレベル（例えば、ＳＰＳ）において指示され得る：
【表４】
2020520174.tif 000006
ここで、sps_gbi_weight_subset_indexは、現在のシーケンスにおける再構成されたピクチャに適用されるＧＢｉ重みサブセットのインデックスを指定する。
【００７６】
実施形態において、重みサブセットインデックスは、例えば、次のシンタックスを用いるフラグで、ピクチャレベル（例えば、ＰＰＳ）において指示され得る：
【表５】
2020520174.tif 000007
ここで、pps_gbi_weight_subset_indexは、現在のピクチャにおける再構成されたブロックに適用されるＧＢｉ重みサブセットのインデックスを指定する。
【００７７】
実施形態において、重みサブセットの使用は、ＳＰＳレベル及びＰＰＳレベルの両方でではなく、ＳＰＳレベル又はＰＰＳレベルのどちらか一方で独立して信号により伝えられる。例えば、sps_gbi_weight_subset_indexが利用可能であるときには、pps_gbi_weight_subset_indexは存在せず、その逆もしかりである。
【００７８】
実施形態において、重みサブセットの使用は、ＳＰＳレベル及びＰＰＳレベルの両方で信号により伝えられる。そのようなものとして、ＰＰＳ信号及びＰＰＳ信号が両方とも存在する場合に、ＰＰＳ信号は優先し、ＳＰＳ信号を上書きする。
【００７９】
実施形態において、重みサブセットインデックスは、スライスレベルで指示され得る。重みサブセットインデックスは、例えば、次のシンタックスを用いるフラグで、スライスレベルにおいて指示され得る：
【表６】
2020520174.tif 000008
ここで、slice_gbi_weight_subset_indexは、現在のスライスにおける再構成されたブロックに適用されるＧＢｉ重みサブセットのインデックスを指定する。
【００８０】
実施形態において、現在のスライス（例えば、スライスヘッダで伝えられる。）のＧＢｉ重みは、現在のピクチャ（ＰＰＳ、又はＰＰＳでのＧＢｉシグナリングが存在しない場合にＳＰＳで伝えられる。）に対して許容されているＧＢｉ重みの全て又は許容されている（又は信号により伝えられた）ＧＢｉ重みの一部である。
【００８１】
実施形態において、重みサブセットインデックスは、ＣＴＵレベルにおいて指示され得る。重みサブセットインデックスは、例えば、次のシンタックスを用いるフラグで、ＣＴＵレベルにおいて指示され得る：
【表７】
2020520174.tif 000009
ここで、CTU_gbi_weight_subset_indexは、現在のＣＴＵにおける再構成されたブロックに適用されるＧＢｉ重みサブセットのインデックスを指定する。
【００８２】
一実施形態において、現在のＣＴＵのＧＢｉ重みは、現在のスライス（例えば、スライスヘッダで伝えられる。）に対して許容されているＧＢｉ重みの全て又は許容されている（又は信号により伝えられた）ＧＢｉ重みの一部、あるいは、現在のピクチャ（ＰＰＳ、又はＰＰＳでのＧＢｉシグナリングが存在しない場合にＳＰＳで伝えられる。）に対して許容されているＧＢｉ重みの全部又は一部である。
【００８３】
実施形態において、サブセット内の重みの数は１である。そのような実施形態では、夫々の符号化ブロックについて重みを信号により伝える必要がない。実際に、夫々の符号化ブロックに使用される重みは、その上位シンタックスで伝えられたものであると推測され得る。また、重みのサブセット（例えば、全部で７つの重みのうちの３又は４つの重み）の選択は、前のピクチャ又はスライス又は領域で使用された重みに依存し得る。すなわち、時間的情報に基づいて選択がなされる。
【００８４】
本明細書には、利用可能なＧＢｉ重みの全てから選択される単一の重みを使用する方法も開示されている。すなわち、利用可能な全てのＧＢｉの中のただ１つの重みが、フラグを使用することによって、夫々の異なったレベルで選択される。例えば、７つのＧＢｉ重みが利用可能である場合に、各重みインデックスの値及びその対応する重み値が表２に示されている。実施形態において、重みインデックスは、可変長符号化又は固定長符号化を使用することによって符号化される。
【表８】
2020520174.tif 000010
【００８５】
実施形態において、重みインデックスは、例えば、次のシンタックスを用いるフラグで、シーケンスレベルにおいて指示され得る：
【表９】
2020520174.tif 000011
ここで、sps_gbi_weight_indexは、現在のシーケンスにおける再構成されたピクチャに適用されるＧＢｉ重みのインデックスを指定する。
【００８６】
実施形態において、重みインデックスは、例えば、次のシンタックスを用いるフラグで、ピクチャレベルにおいて指示され得る：
【表１０】
2020520174.tif 000012
ここで、pps_gbi_weight_indexは、現在のピクチャにおける再構成されたブロックに適用されるＧＢｉ重みのインデックスを指定する。
【００８７】
実施形態において、重みサブセットの使用は、ＳＰＳレベル及びＰＰＳレベルの両方でではなく、ＳＰＳレベル又はＰＰＳレベルのどちらか一方で独立して信号により伝えられる。例えば、sps_gbi_weight_indexが利用可能であるときには、pps_gbi_weight_indexは存在せず、その逆もしかりである。
【００８８】
実施形態において、重みサブセットの使用は、ＳＰＳレベル及びＰＰＳレベルの両方で信号により伝えられる。そのようなものとして、ＰＰＳ信号及びＰＰＳ信号が両方とも存在する場合に、ＰＰＳ信号は優先し、ＳＰＳ信号を上書きする。
【００８９】
実施形態において、重みサブセットインデックスは、スライスレベルで指示され得る。重みサブセットインデックスは、例えば、次のシンタックスを用いるフラグで、スライスレベルにおいて指示され得る：
【表１１】
2020520174.tif 000013
ここで、slice_gbi_weight_indexは、現在のスライスにおける再構成されたブロックに適用されるＧＢｉ重みのインデックスを指定する。
【００９０】
一実施形態において、現在のスライス（例えば、スライスヘッダで伝えられる。）に対して許容されているＧＢｉ重みは、現在のピクチャ（ＰＰＳ、又はＰＰＳでのＧＢｉシグナリングが存在しない場合にＳＰＳで伝えられる。）に対して許容されている（又は信号により伝えられた）ＧＢｉ重みのうちのただ１つである。
【００９１】
実施形態において、重みサブセットインデックスは、ＣＴＵレベルにおいて指示され得る。重みサブセットインデックスは、例えば、次のシンタックスを用いるフラグで、ＣＴＵレベルにおいて指示され得る：
【表１２】
2020520174.tif 000014
ここで、CTU_gbi_weight_indexは、現在のＣＴＵにおける再構成されたブロックに適用されるＧＢｉ重みのインデックスを指定する。
【００９２】
一実施形態において、現在のＣＴＵに対して許容されているＧＢｉ重みは、現在のスライス（スライスヘッダで伝えられる。）に対して許容されている（又は信号により伝えられた）ＧＢｉ重みのうちのただ１つ、あるいは、現在のピクチャ（ＰＰＳ、又はＰＰＳでのＧＢｉシグナリングが存在しない場合にＳＰＳで伝えられる。）に対して許容されているＧＢｉ重みのうちの１つである。
【００９３】
特定のＧＢｉがピクチャ（ＳＰＳ、ＰＰＳ）、スライス（スライスヘッダ）又は領域（ＣＴＵヘッダ）レベルで選択される場合に、このピクチャ、スライス、又は領域内の全てのインタ符号化されたブロックは、このＧＢｉ重みを使用する。夫々のブロックにおいてＧＢｉ重みを信号により伝える必要はない。
【００９４】
本明細書には、全ての利用可能なＧＢｉ重みの中の重みサブセットから選択された単一の重みを使用する方法も開示されている。すなわち、利用可能な全てのＧＢｉ重みの中の重みサブセットからのただ１つの重みが、フラグを使用することによって、夫々の異なるレベルで選択される。
【００９５】
例えば、我々は、７つのＧＢｉ重みを３つの重みサブセットに分ける。夫々のサブセットは、利用可能なＧＢｉ重みの中の少なくとも１つを含む。
【表１３】
2020520174.tif 000015
【００９６】
第１サブセットに関して、重みインデックスと重み値との間の関係は、以下の表で示され得る。
【表１４】
2020520174.tif 000016
【００９７】
第２サブセットに関して、重みインデックスと重み値との間の関係は、以下の表で示され得る。
【表１５】
2020520174.tif 000017
【００９８】
第３サブセットに関して、重みインデックスと重み値との間の関係は、以下の表で示され得る。
【表１６】
2020520174.tif 000018
【００９９】
この実施形態では、ＧＢｉ重みサブセットインデックス及びＧＢｉ重みインデックスは、後述されるように、同じでレベルで示されるか、あるいは、異なるレベルで示され得る。
【０１００】
実施形態において、重みサブセットインデックス及び重みインデックスは、例えば、次のシンタックスを用いるフラグで、シーケンスレベルにおいて指示され得る：
【表１７】
2020520174.tif 000019
ここで、sps_gbi_weight_subset_indexは、現在のシーケンスにおける再構成されたピクチャに適用されるＧＢｉ重みサブセットのインデックスを指定し、ここで、sps_gbi_weight_indexは、現在のシーケンスにおける再構成されたピクチャに適用されるＧＢｉ重みのインデックスを指定する。
【０１０１】
夫々のシーケンス、ピクチャ、又はＣＴＵ若しくはＣＴＵのグループによって表される領域は、同じ方法を使用することができる。
【０１０２】
実施形態において、重みインデックスは、例えば、次のシンタックスを用いるフラグで、ピクチャレベルにおいて指示され得る：
【表１８】
2020520174.tif 000020
ここで、pps_gbi_weight_subset_indexは、現在のピクチャにおける再構成されたブロックに適用されるＧＢｉ重みサブセットのインデックスを指定し、ここで、pps_gbi_weight_indexは、現在のピクチャにおける再構成されたブロックに適用されるＧＢｉ重みのインデックスを指定する。
【０１０３】
実施形態において、重みインデックスは、例えば、次のシンタックスを用いるフラグで、スライスレベルにおいて指示され得る：
【表１９】
2020520174.tif 000021
ここで、slice_gbi_weight_subset_indexは、現在のスライスにおける再構成されたブロックに適用されるＧＢｉ重みサブセットのインデックスを指定し、ここで、slice_gbi_weight_indexは、現在のスライスにおける再構成されたブロックに適用されるＧＢｉ重みのインデックスを指定する。
【０１０４】
実施形態において、重みサブセットインデックス及び重みインデックスは、異なるレベルで信号により伝えられ得る。例えば、スライスに対して使用される重みの特定のサブセットは、ピクチャヘッダにおいて信号により伝えられ得る。その後に、スライスヘッダは、ピクチャヘッダにおける重みのサブセットから選択された重みに対応する重みインデックスを信号により伝える。一例となるシンタックステーブルが以下で示される。これは、他の変形に拡張されてもよい。
【表２０】
2020520174.tif 000022
ここで、sps_gbi_weight_subset_indexは、現在のシーケンスにおける再構成されたピクチャに適用されるＧＢｉ重みサブセットのインデックスを指定し、ここで、pps_gbi_weight_subset_indexは、現在のピクチャにおける再構成されたブロックに適用されるＧＢｉ重みサブセットのインデックスを指定し、ここで、slice_gbi_weight_indexは、現在のスライスにおける再構成されたブロックに適用されるＧＢｉ重みのインデックスを指定する。
【０１０５】
実施形態において、現在の領域の重みサブセットは、異なるレベルで信号により伝えられるフラグを用いて、隣接する領域に応じて適応的に指示され得る。現在の領域及び隣接する領域は、ＣＴＵのグループ、ＣＴＵ、ＣＵ、ＰＵ、などであることができる。例えば、ＣＴＵレベルにおいて、選択された重みサブセットは、次のシンタックスを用いて隣接ＣＴＵから導出され得る：
【表２１】
2020520174.tif 000023
ここで、１に等しいctu_gbi_merge_flagは、現在のコーディング・ツリー・ユニットのＧＢｉ重みサブセットが、隣接するコーディング・ツリー・ブロックの対応するシンタックス要素から導出されることを特定し、ここで、０に等しいctu_gbi_merge_flagは、それらのシンタックス要素が、隣接するコーディング・ツリー・ブロックの対応するシンタックス要素から導出されないことを特定する。
【０１０６】
本明細書には、現在のブロックの重みとして隣接ブロックの重みを使用する方法も開示されている。図４は、現在のブロック４０４及び空間的ＧＢｉ隣接ブロック４０４の図４００である。実施形態において、空間的ＧＢｉ隣接ブロック４０４は、左下の空間隣接ブロックＡ０、左の空間隣接ブロックＡ１、右上の空間隣接ブロックＢ０、上の空間隣接ブロックＢ１、及び左上の空間隣接ブロックＢ２を有する。別の実施形態では、現在のブロック４０２に対して異なる位置にある他の空間的ＧＢｉ隣接ブロック４０４が使用又は考慮されてもよい。
【０１０７】
実施形態において、現在のブロック４０２の重みは、その隣接するブロックのいずれか１つに使用されている重みと同じであってよい。隣接するブロックは、空間的ＧＢｉ隣接ブロック４０４、例えば、上、左、左上、右上、及び左下、など、又は時間的に隣接するブロックであってよい。実施形態において、時間的に隣接するブロックは、時間的動きベクトル予測子（ＴＭＶＰ）を用いて識別される、前に符号化されたピクチャの中の１つ、で見つけられる。プルーニングプロセスは、異なる隣接ブロックからの同じ重みを取り除くために実行されてよい。Ｍで表される残りの異なる重みは次いで、リストを形成する。それらのインデックスは、符号器から復号器へ信号伝達及び送信される。
【０１０８】
実施形態において、現在のブロック４０２の重みは、その上又は左で隣接するブロック（例えば、上の空間隣接ブロックＢ１及び左上の空間隣接ブロックＢ２）と同じであってよい。そのような場合に、フラグは、上又は左選択を信号により伝えるために使用される。フラグは、例えば、１ビン又は１ビットであってよい。２つ以上の隣接するブロックで使用される重みが同じである場合には、フラグを符号化又は送信する必要はない。実施形態において、フラグは、例えば、ＣＡＢＡＣを用いて、コンテキスト符号化されてよい。ＣＡＢＡＣは、Ｈ．２６４／ＭＰＥＧ−４  ＡＶＣ及びＨＥＶＣ標準で使用されるエントロピ符号化の一形式である。ＣＡＢＡＣは、ロスレス圧縮技術であるが、それが使用される映像符号化標準は、通常は、ロッシー圧縮に適用される。
【０１０９】
実施形態において、空間ＧＢｉ隣接ブロック４０４の重みは、例えば、次のシンタックスを用いて、ＧＢｉ重み候補リスト（例えば、GBiWeightCandList）を形成する。
i=0
if(availableFlagA1)
GBiWeightCandList[i++]=A1
if(availableFlagB1)
GBiWeightCandList[i++]=B1
if(availableFlagB0)
GBiWeightCandList[i++]=B0
if(availableFlagA0)
GBiWeightCandList[i++]=A0
if(availableFlagB2)
GBiWeightCandList[i++]=B2
【０１１０】
現在のブロック（例えば、ブロック４０２）のＧＢｉ重みは、GBiWeightSubstCandList内のＧＢｉ重みの１つに等しくなり得る。一例となるシンタックステーブルが以下で示されている。第１に、フラグ（例えば、cu_gbi_merge_flag）は、現在のブロックのＧＢｉ重みがその隣接するブロックの１つに等しいようにマージされるかどうかを指示するために、信号により伝えられる。そうである（フラグcu_gbi_merge_flagによって示される。）場合には、次いで、現在のブロックに対して使用されるＧＢｉ重みのインデックス（例えば、gbi_merge_idx）が信号により伝えられる。このインデックスは、コンテキストにより可変長符号化によって符号化され得る。現在のブロックのＧＢｉ重みがＧＢｉ重み候補リスト（例えば、GBiWeightCandList）内のいずれのＧＢｉ重みとも同じでないことを第１フラグ（例えば、cu_gbi_merge_flag）が指示する場合には、一実施形態において、現在のＧＢｉ重みインデックスは、本明細書で記載される方法又は実施形態の１つにより明示的に信号で伝えられる。実施形態において、現在のブロックのＧＢｉ重みは、特定の値、例えば、１／２に等しいと推測される。他の実施形態では、現在のブロックは、予測のためにＧＢｉを使用しない。
【表２２】
2020520174.tif 000024
ここで、１に等しいcu_gbi_merge_flagは、現在の符号化単位のＧＢｉ重みが重み候補リスト内の重みの１つに等しいことを特定し、ここで、０に等しいcu_gbi_merge_flagは、現在の符号化単位のＧＢｉ重みが重み候補リスト内の重みの１つに等しくないことを特定し、ここで、gbi_merge_idxは、候補リスト内のどの重みが現在の符号化単位のために使用されるかを特定する。
【０１１１】
実施形態において、符号化単位は、予測単位又はブロック全般によって置き換えられてもよい。
【０１１２】
本明細書には、現在のブロックのために最確重み及び残余重みを使用する方法も開示されている。そのような方法で、現在の符号化ブロックのとり得る重みは、２つのタイプ、例えば、最確重み（ＭＰＷ）及び残余重み（ＲＭＷ）に分類される。フラグは、現在のブロックの重みが最確重みの１つであるかどうかを信号により伝えるために使用される。フラグは、１ビット又は１ビンであってよく、コンテキスト符号化されてよい。
【０１１３】
実施形態において、最確重みは、隣接するブロック、例えば、上又は左の隣接ブロックによって使用される重みである。実施形態において、最確重みは、高い確率で使用される重みである。例えば、重み１／２及び５／８は、他の利用可能な重みに対して使用される確率が高い。
【０１１４】
重みが最確重みの１つである場合に、使用される最確重みを識別するために第２フラグが使用される。一実施形態において、コードワード０、０１、１１は、｛上、左、１／２、５／８、３／８｝又は｛左、上、１／２、５／８、３／８｝の中の最初の３つの利用可能な且つ有効な（異なる）重みについて信号により伝えられる。順序及び値は様々であり得る。実施形態において、ビン０、１が、｛上、左、１／２、５／８｝又は｛左、上、１／２、５／８｝又は左、上、１／２、３／８｝の中の最初の２つの利用可能な且つ有効な（異なる）重みについて信号により伝えられてもよい。順序及び値は様々であり得る。
【０１１５】
現在のブロックの重みがＭＰＷでない（すなわち、重みは残余重みの１つである）ことを第１フラグが指示する場合には、それがどの残余重みであるかを指示するために第２フラグが使用される。残余重みは、固定長符号化又は可変長符号化によって符号化されてよい。その上、ＭＰＷ又はＲＭＷを指示する第１フラグは、コンテキスト符号化されてよい。重みインデックスを指示する第２フラグは、コンテキスト符号化されても、又は部分的にコンテキスト符号化されてもよい。一例において、残余重みインデックスの最初のビンは、コンテキスト符号化され、一方、続く残りのビンは、バイパス符号化される。
【０１１６】
例えば、最確重みコンテキストにおいて７つの重みを使用すると、重みインデックスと対応する重み値との間のサンプル関係は、以下の表で示される。
【表２３】
2020520174.tif 000025
【０１１７】
最確重みに対するオン／オフ制御は、フラグを用いて異なるレベルで指示され得る。例えば、ＣＵレベルフラグが、以下でシンタックスによって示されるように使用されてよい。
【表２４】
2020520174.tif 000026
【０１１８】
アレイインデックスx0+i、y0+jは、ピクチャの左上ルーマサンプルに対して、考えられている予測ブロックの左上ルーマサンプルの位置（ｘ０＋ｉ，ｙ０＋ｊ）を特定する。１に等しいシンタックス要素prev_gbi_weight_flag[x0+i][y0+j]は、mpm_weight_idxの値が現在のＣＵ内の再構成されたピクチャに適用されることを特定する。０に等しいprev_gbi_weight_flag[x0+i][y0+j]は、rem_pred_weightの値が現在のＣＵ内の再構成されたピクチャに適用されることを特定する。
【０１１９】
mpm_weight_idx[x0+i][y0+j]は、最確重みのインデックスを指定する。その上、rem_pred_weight[x0+i][y0+j]は、最確重みとは異なる残余ＧＢｉ重みを指定する。
【０１２０】
７つのＧＢｉ重みが存在する例では、最確重みの組が３つの重みを含むときに、残余ＧＢｉ重みは残りの４つの重みである。この例で、２ビン固定長符号化が、残余重みを符号化するために使用され得る。
【０１２１】
実施形態において、ＧＢｉの予測される重みは、次の順序付けられたステップを用いて、隣接するブロックから導出される。最初に、隣接位置（ｘＮｂＡ，ｙＮｂＡ）及び（ｘＮｂＢ，ｙＮｂＢ）は、夫々、（ｘＰｂ−１，ｙＰｂ）及び（ｘＰｂ，ＹＰｂ−１）に等しくセットされる。
【０１２２】
第２に、ＸがＡ又はＢのどちらか一方によって置き換えられる場合に、変数CandIntraPredModeXが次のように導出される。  
参照により本願に援用される、“High  Efficiency  Video  Coding”，ITU-T  Recommendation  |  International  Organization  for  Standardization  (ISO)  /  International  Electrotechnical  Commission  (IEC)  23008-2，２０１６年１２月の６．４．１節で規定される、ｚスキャンオーダーでのブロックの利用可能性導出プロセスは、（ｘＰｂ，ｙＰｂ）に等しくセットされた位置（ｘＣｕｒｒ，ｙＣｕｒｒ）及び（ｘＮｂＸ，ｙＮｂＸ）に等しくセットされた隣接位置（ｘＮｂＹ，ｙＮｂＹ）を入力として呼び出され、出力は、availableXに割り当てられる。
【０１２３】
候補重みcandweightXは、次のように導出される：
availableXがＦＡＬＳＥに等しい場合には、candweightXは０．５に等しくセットされる。  
そうでない場合には、CandIntraPredModeXは、WeightPred[xNbX][yNbX]に等しくセットされる。
【０１２４】
candWeightList[x]は、次のように導出され、ｘは、０乃至重みの数であることができる。この実施形態では、ｘは、例えば、０乃至２に等しい。  
candWeightBがcandWeightAに等しい場合に、以下が適用される：
candWeightAが１／２又は５／８に等しい場合に、ｘ＝０・・２であるcandModeList[x]は、次のように導出される：
candWeightList[0]＝1/2
candWeightList[1]＝5/8
candWeightList[2]＝3/4
そうでない場合に、ｘ＝０・・２であるcandModeList[x]は、次のように導出される：
candWeightList[0]＝candWeightA
candWeightList[1]＝1/2
candWeightList[2]＝5/8
他の場合に（candWeightBがcandWeightAに等しくない。）、以下が適用される：
candWeightList[0]及びcandWeightList[1]が、次のように導出される：
candWeightList[0]＝candWeightA
candWeightList[1]＝candWeightB
candWeightList[0]及びcandWeightList[1]のどちらも１／２に等しくない場合に、candWeightList[2]は１／２に等しくセットされ、
さもなくば、candWeightList[0]及びcandWeightList[1]のどちらも５／８に等しくない場合に、candWeightList[2]は５／８に等しくセットされ、
その他の場合に、candModeList[2]は３／４に等しくセットされる。
【０１２５】
第３に、現在のブロックの重みは、次のプロシージャを適用することによって導出される：
prev_gbi_weight_flag[x0+i][y0+j]が１に等しい場合に、現在のブロックの重みは、candModeList[mpm_weight_idx]に等しくセットされる。  
そうでない場合に、現在のブロックの重みWeightPred[xPb][yPb]は、次の順序付けられたステップを適用することによって導出される：
WeightPred[xPb][yPb]は、rem_pred_weight[xPb][yPb]に等しくセットされる。  
ｉが０乃至２に等しい場合に、WeightPred[xPb][yPb]がcandModeList[i]以上であるときに、WeightPred[xPb][yPb]の値は１だけ増分される。
【０１２６】
実施形態において、ｉが０乃至２に等しい場合に、WeightPred[xPb][yPb]がcandModeList[i]以上であるときに、WeightPred[xPb][yPb]の値は１減じられる。
【０１２７】
実施形態において、上隣接領域及び左隣接領域に加えて、第３の隣接領域（例えば、左上隣接領域）も使用されてよい。実施形態において、ｘは、０乃至１であることができる。ｘが０乃至１であるようセットされる場合に、candWeightList[2]は存在しない。そのような場合に、candWeightList[0]及びcandWeightList[1]しか導出される必要がなく、方法の残りの部分は上記の通りに実行され得る。
【０１２８】
実施形態において、ｘは０乃至３であることができる。ｘが０乃至３であるようセットされる場合に、上隣接領域及び左隣接領域に加えて、第３の隣接領域（例えば、左上隣接領域）又は最も使用される重み（例えば、１／２）が候補として使用され得る。
【０１２９】
他の実施形態では、残余重みは、非最確重みである、Ｎとして表される重みであることもできる。ここで、Ｎは、ＧＢｉ重みの総数から最確重みを減じた結果よりも小さい。例が、説明のために以下で与えられている。
【０１３０】
｛１／２、３／８、５／８、１／４、３／４、−１／４、５／４｝の順序を有するＧＢｉ重みの場合に、最確重みが１／２、５／８、３／８であり、Ｎ＝３であるとき、残余重みは、非最確重みの最初の３つの重み、例えば、｛１／４、３／４、−１／４｝である。｛１／２、５／８、３／８、１／４、３／４、５／４、−１／４｝の順序を有するＧＢｉ重みの場合に、最確重みが１／２、５／８、３／８であり、Ｎ＝３であるとき、残余重みは、非最確重みの最初の３つの重み、例えば、｛１／４、３／４、５／４｝である。
【０１３１】
本明細書には、インタマージモードを使用する方法も開示されている。例えば、現在のブロックがインタマージモードを用いてインタ符号化されているとき、現在のブロックの重みは、ｍｖマージインデックスによって指示される動きベクトルによって指し示されるか又はインタマージインデックスによって指示されるインタ符号化されたブロックに使用される重みに等しいと推測される。
【０１３２】
図５は、本開示の実施形態に従うネットワークデバイス５００（例えば、コーディングデバイス）の概略図である。ネットワークデバイス５００は、本明細書で記載されている開示実施形態を実装するのに適している。実施形態において、ネットワークデバイス５００は、図１のビデオ復号器３０のような復号器又は図１のビデオ符号器２０のような符号器であってよい。実施形態において、ネットワークデバイス５００は、上述された図１のビデオ復号器３０又は図１のビデオ符号器２０の１以上の構成要素であってもよい。
【０１３３】
ネットワークデバイス５００は、データを受信する入口ポート５１０及び受信器ユニット（Ｒｘ）５２０と、データを処理するプロセッサ、論理ユニット、又は中央演算処理装置（ＣＰＵ）５３０と、データを送信する送信器ユニット（Ｔｘ）５４０及び出口ポート５５０と、データを記憶するメモリ５６０とを有する。ネットワークデバイス５００はまた、光又は電気信号の出口又は入口のために入口ポート５１０、受信器ユニット５２０、送信器ユニット５４０、及び出口ポート５５０へ結合された光−電気（ＯＥ）コンポーネント及び電気−光（ＥＯ）コンポーネントを有してもよい。
【０１３４】
プロセッサ５３０は、ハードウェア及びソフトウェアによって実装される。プロセッサ５３０は、１以上のＣＰＵチップ、コア（例えば、マルチコアプロセッサ）、ＦＰＧＡ、ＡＳＩＣ、及びＤＳＰとして実装されてよい。プロセッサ５３０は、入口ポート５１０、受信器ユニット５２０、送信器ユニット５４０、出口ポート５５０、及びメモリ５６０と通信する。プロセッサ５３０は、コーディングモジュール５７０を有する。コーディングモジュール５７０は、上記の開示実施形態を実装する。例えば、コーディングモジュール５７０は、様々なコーディング動作を実装、処理、準備、又は提供する。従って、コーディングモジュール５７０の包含は、ネットワークデバイス５００の機能性に対して実質的な改善を与え、異なる状態へのネットワークデバイス５００の変形をもたらす。代替的に、コーディングモジュール５７０は、メモリ５６０に記憶されてプロセッサ５３０によって実行される命令として実装される。
【０１３５】
メモリ５６０は、１以上のディスク、テープドライブ、及び固体状態ドライブを有し、プログラムを記憶するよう、プログラムが実行のために選択されるときにプログラムを記憶するために、且つ、プログラム実行中に読み出される命令及びデータを記憶するために、オーバーフローデータ記憶デバイスとして使用されてよい。メモリ５６０は、揮発性及び／又は不揮発性であってよく、リード・オンリー・メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、３値連想メモリ（ＴＣＡＭ）、及び／又は静的ランダム・アクセス・メモリ（ＳＲＡＭ）であってよい。
【０１３６】
図６は、コーディング方法６００の実施形態を表すフローチャートである。実施形態において、コーディング方法６００は、図１のビデオ復号器３０のような復号器で実装される。コーディング方法６００は、例えば、図１のビデオ符号器２０のような符号器から受け取られたビットストリームが、電子デバイスのディスプレイで画像を生成するために復号されるべきであるときに、実施されてよい。
【０１３７】
ブロック６０２で、特定の部分において重みサブセットフラグを含むビットストリームが受信される。特定の部分は、例えば、ビットストリームのＳＰＳ、ビットストリームのＰＰＳ、ビットストリームのスライスヘッダ、又はＣＴＵ若しくはＣＴＵのグループによって表されるビットストリームの領域であってよい。
【０１３８】
ブロック６０４で、重みサブセットは、重みサブセットフラグにより識別される。実施形態において、重みサブセットは、現在のインタブロックに対する利用可能な重みの一部を有する。実施形態において、現在のブロックに対する利用可能な重みは、少なくとも−１／４、１／４、３／８、１／２、５／８、３／４、及び５／４を含む。実施形態において、利用可能な重みは、−１／４、１／４、３／８、１／２、５／８、３／４、及び５／４に加えて少なくとも１の重みを含んでよい。
【０１３９】
ブロック６０６で、画像が電子デバイスのディスプレイに表示される。画像は、重みサブセットフラグによって識別された重みサブセットを用いて生成される。画像は、映像からのフレーム又はピクチャであってよい。
【０１４０】
図７は、コーディング方法７００の実施形態を表すフローチャートである。実施形態において、コーディング方法７００は、図１のビデオ符号器２０のような符号器で実装される。コーディング方法７００は、例えば、ビットストリームが生成され、図１のビデオ復号器３０のような復号化デバイスへ送信されるべきであるときに、実施されてよい。
【０１４１】
ブロック７０２で、現在のインタブロックに対する利用可能な重みが、重みサブセットに分けられる。例えば、利用可能な重みは、も−１／４、１／４、３／８、１／２、５／８、３／４、及び５／４の組であり、サブセットは、｛１／４、３／４、−１／４｝、｛１／４、３／４、５／４｝、及び｛１／４、３／８、１／２、５／８｝である。当然ながら、重みの様々な組み合わせを含む任意の数のサブセットが実際の用途では使用されてよい。
【０１４２】
ブロック７０４で、重みサブセットの１つが符号化のために選択される。例えば、｛１／４、３／４、−１／４｝のサブセットが選択されてよい。ブロック７０６で、重みサブセットフラグがビットストリームの特定の部分内に符号化される。重みサブセットフラグは、選択された重みサブセットの１つを識別するために使用される重みサブセットインデックスを含む。特定の部分は、例えば、ビットストリームのＳＰＳ、ビットストリームのＰＰＳ、ビットストリームのスライスヘッダ、又はＣＴＵ若しくはＣＴＵのグループによって表されるビットストリームの領域であってよい。
【０１４３】
ブロック７０８で、重みサブセットフラグを含むビットストリームは、図１のビデオ復号器３０のような復号化デバイスへ送信される。ビットストリームが復号化デバイスによって受信されるとき、復号化デバイスは、ビットストリームを復号するために図６のプロセスを実施してよい。
【０１４４】
以上に基づき、当業者は、既存の解決法が、７つの異なる重みが現在のインタブロックを符号化することを可能にすると認識するだろう。７つ全ての重みの重みインデックスは、最大６つのビンを用いる様々な長さの符号化方法によって明示的に伝えられる。対照的に、本開示は、局所的な領域又はエリア内の映像（又は画像）コンテンツがある程度の連続性を有していると気付くことに基づいて適応的な様態で重み、よってシグナリングビットの数を減らす方法の組を提示する。方法はまた、隣接ブロック情報を利用することによって現在のインタブロックの重みを推測するために、又は提案される最も確からしい重みの概念及びスキームを用いて重みを符号化するために提示されている。
【０１４５】
復号器によって実装されるコーディング方法。方法は、受信手段によって、特定の部分において重みサブセットフラグを含むビットストリームを受信することと、識別手段によって、現在のインタブロックに対する利用可能な重みのサブセットを有する重みサブセットを、前記重みサブセットフラグを用いて識別することと、表示手段によって、電子デバイスのディスプレイ上で、前記重みサブセットフラグによって識別された前記重みサブセットを用いて生成される画像を表示することとを含む。
【０１４６】
符号器によって実装されるコーディング方法。方法は、分割手段によって、現在のインタブロックに対する利用可能な重みを重みサブセットに分けることと、前記重みサブセットの１つを選択することと、符号化手段によって、選択された前記重みサブセットの前記１つを識別するために使用される重みサブセットインデックスを含む重みサブセットフラグをビットストリームの特定の部分内に符号化することと、送信手段によって、前記重みサブセットフラグを含む前記ビットストリームを復号化デバイスへ送信することとを含む。
【０１４７】
コーディング装置。コーディング装置は、特定の部分において重みサブセットフラグを含むビットストリームを受信するよう構成される受信手段と、該受信手段へ結合され、命令を含む記憶手段と、該記憶手段へ結合され、該記憶手段に記憶されている前記命令を実行して、前記特定の部分において前記重みサブセットフラグを取得するように前記ビットストリームをパースし、現在のインタブロックに対する利用可能な重みのサブセットを有する重みサブセットを、前記重みサブセットフラグを用いて識別するよう構成されるプロセッサ手段と、該プロセッサ手段へ結合され、前記重みサブセットに基づいて生成される画像を表示するよう構成される表示手段とを含む。
【０１４８】
いくつかの実施形態が本開示で与えられてきたが、開示されているシステム及び方法は、本開示の精神又は適用範囲から逸脱することなしに多数の他の特定の形態で具現され得ることが理解されるべきである。本例は、限定ではなく実例として見なされるべきであり、本明細書で与えられている詳細に制限されることは意図されない。例えば、様々な要素又はコンポーネントは、他のシステムでは結合又は一体化されてよく、あるいは、特定の特徴は、省略されても、又は実施されなくてもよい。
【０１４９】
更に、個別的又は別々に様々な実施形態で記載及び例示されている技術、システム、サブシステム、及び方法は、本開示の適用範囲から逸脱することなしに他のシステム、モジュール、又は方法と結合又は一体化されてもよい。互いと結合若しくは直接結合若しくは通信するように図示又は議論されている他のアイテムは、電気的、機械的、又は別な方法であろうとも、何らかのインターフェイス、デバイス、又は中間コンポーネントを通じて間接的に結合又は通信してもよい。変更、置換、及び修正の他の例は、当業者によって確かめられ、本明細書で開示されている精神及び適用範囲から逸脱することなしに行われ得る。
【０１５０】
関連出願の相互参照
この特許出願は、“Method  and  Apparatus  for  Bidirectional  Prediction  in  Video  Compression”と題されてShan  Liu等によって２０１７年５月１０日付けで出願された米国特許仮出願第６２／５０４４６６号の優先権を主張して、“Bidirectional  Prediction  In  Video  Compression”と題されて２０１８年４月６日付け出願された米国特許出願第１５／９４７２１９号の優先権を主張する。これら先願の教示及び開示は、その全文をこれをもって参照により本願に援用される。
【０１５１】
連邦政府による資金提供を受けた研究開発の記載
対象外
【０１５２】
マイクロフィッシュ付録の参照
対象外
【図１】
2020520174.tif 000027
【図２】
2020520174.tif 000028
【図３】
2020520174.tif 000029
【図４】
2020520174.tif 000030
【図５】
2020520174.tif 000031
【図６】
2020520174.tif 000032
【図７】
2020520174.tif 000033
【手続補正書】
【提出日】令和1年12月5日(2019.12.5)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
復号器によって実装されるコーディング方法であって、
特定の部分において重みサブセットフラグを含むビットストリームを受信することと、
現在のインタブロックに対する利用可能な重みのサブセットを有する重みサブセットを、前記重みサブセットフラグを用いて識別することと、
前記重みサブセットフラグによって識別された前記重みサブセットを用いて画像を生成することと
を有する方法。
【請求項２】
前記利用可能な重みは、一般化された双予測（ＧＢｉ）に対応する、
請求項１又は２に記載の方法。
【請求項３】
前記特定の部分は、前記ビットストリームのシーケンス・パラメータ・セット（ＳＰＳ）レベルである、
請求項１又は２に記載の方法。
【請求項４】
前記特定の部分は、前記ビットストリームのピクチャ・パラメータ・セット（ＰＰＳ）レベルである、
請求項１又は２に記載の方法。
【請求項５】
前記特定の部分は、前記ビットストリームのスライスヘッダである、
請求項１又は２に記載の方法。
【請求項６】
前記特定の部分は、コーディング・ツリー・ユニット（ＣＴＵ）又はＣＴＵのグループによって表される前記ビットストリームの領域である、
請求項１又は２に記載の方法。
【請求項７】
前記現在のブロックに対する前記利用可能な重みは、−１／４、１／４、３／８、１／２、５／８、３／４、及び５／４に加えて少なくとも１つの重みを含む、
請求項１乃至６のうちいずれか一項に記載の方法。
【請求項８】
符号器によって実装されるコーディング方法であって、
現在のインタブロックに対する利用可能な重みを重みサブセットに分けることと、
前記重みサブセットの１つを選択することと、
選択された前記重みサブセットの前記１つを識別するために使用される重みサブセットインデックスを含む重みサブセットフラグをビットストリームの特定の部分内に符号化することと、
前記重みサブセットフラグを含む前記ビットストリームを復号化デバイスへ送信することと
を有する方法。
【請求項９】
選択された前記重みサブセットの前記１つは、単一の重みしか含まない、
請求項８に記載の方法。
【請求項１０】
前記現在のインタブロックに対する前記利用可能な重みを前記重みサブセットに分けるステップは、前記利用可能な重みを最初により大きい重みサブセットに分けてから、該より大きい重みサブセットを、前記重みサブセットを形成するように分けることを有する、
請求項８又は９に記載の方法。
【請求項１１】
選択された前記重みサブセットの前記１つから単一の重みを選択することを更に有する、
請求項１０に記載の方法。
【請求項１２】
前記特定の部分は、前記ビットストリームのシーケンス・パラメータ・セット（ＳＰＳ）レベル及び前記ビットストリームのピクチャ・パラメータ・セット（ＰＰＳ）レベル、前記ビットストリームのスライスヘッダ、並びにコーディング・ツリー・ユニット（ＣＴＵ）又はＣＴＵのグループによって表される前記ビットストリームの領域、の中の１つ以上である、
請求項８乃至１１のうちいずれか一項に記載の方法。
【請求項１３】
前記重みサブセットフラグにおけるビンの数が前記重みサブセットインデックスにおける重みの数よりも１少ないように、可変長符号化を用いて前記重みサブセットフラグを符号化することを更に有する、
請求項８乃至１２のうちいずれか一項に記載の方法。
【請求項１４】
前記重みサブセットフラグにおけるビンの数が前記重みサブセットインデックスにおける重みの数よりも少なくとも２少ないように、固定長符号化を用いて前記重みサブセットフラグを符号化することを更に有する、
請求項８乃至１２のうちいずれか一項に記載の方法。
【請求項１５】
特定の部分において重みサブセットフラグを含むビットストリームを受信するよう構成される受信器と、
前記受信器へ結合され、命令を含むメモリと、
前記メモリへ結合され、前記メモリに記憶されている前記命令を実行して、
前記特定の部分において前記重みサブセットフラグを取得するように前記ビットストリームをパースし、
現在のインタブロックに対する利用可能な重みのサブセットを有する重みサブセットを、前記重みサブセットフラグを用いて識別し、
前記重みサブセットに基づいて画像を生成する
よう構成されるプロセッサと
を有するコーディング装置。
【請求項１６】
前記特定の部分は、前記ビットストリームのシーケンス・パラメータ・セット（ＳＰＳ）レベルである、
請求項１５に記載のコーディング装置。
【請求項１７】
前記特定の部分は、前記ビットストリームのピクチャ・パラメータ・セット（ＰＰＳ）レベルである、
請求項１５に記載のコーディング装置。
【請求項１８】
前記特定の部分は、前記ビットストリームのスライスヘッダである、
請求項１５に記載のコーディング装置。
【請求項１９】
前記特定の部分は、コーディング・ツリー・ユニット（ＣＴＵ）又はＣＴＵのグループによって表される前記ビットストリームの領域である、
請求項１５に記載のコーディング装置。
【請求項２０】
前記利用可能な重みは、一般化された双予測（ＧＢｉ）で使用される全ての重みを有する、
請求項１５乃至１９のうちいずれか一項に記載のコーディング装置。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００３
【補正方法】変更
【補正の内容】
【０００３】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記利用可能な重みが一般化された双予測（generalized  bi-prediction，ＧＢｉ）に対応することを提供する。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００４
【補正方法】変更
【補正の内容】
【０００４】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記特定の部分が前記ビットストリームのシーケンス・パラメータ・セット（sequence  parameter  set，ＳＰＳ）レベルであることを提供する。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０００５
【補正方法】変更
【補正の内容】
【０００５】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記特定の部分が前記ビットストリームのピクチャ・パラメータ・セット（picture  parameter  set，ＰＰＳ）レベルであることを提供する。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
任意に、上記の態様のいずれかで、その態様の他の実施は、前記特定の部分が、コーディング・ツリー・ユニット（coding  tree  unit，ＣＴＵ）又はＣＴＵのグループによって表される前記ビットストリームの領域であることを提供する。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００２５
【補正方法】変更
【補正の内容】
【００２５】
【図１】双方向予測技術を利用し得るコーディングシステムの例を表すブロック図である。
【図２】双方向予測技術を実装し得るビデオ符号器の例を表すブロック図である。
【図３】双方向予測技術を実装し得るビデオ復号器の例を表すブロック図である。
【図４】現在のブロックと、空間的に隣接した一般化双予測（ＧＢｉ）ブロックとの図である。
【図５】ネットワークデバイスの概略図である。
【図６】コーディング方法の実施形態を表すフローチャートである。
【図７】コーディング方法の実施形態を表すフローチャートである。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００２８
【補正方法】変更
【補正の内容】
【００２８】
送り先デバイス１４は、復号されるべき符号化された映像データを、コンピュータ可読媒体１６を介して受信してよい。コンピュータ可読媒体１６は、符号化された映像データをソースデバイス１２から送り先デバイス１４へ移動させることができる如何なるタイプの媒体又はデバイスも有してよい。一例では、コンピュータ可読媒体１６は、符号化された映像データを直接に送り先デバイス１４に対してリアルタイムで送信することをソースデバイス１２に可能にする通信媒体を有してよい。符号化された映像データは、無線通信プロトコルのような通信標準に従って変調され、そして、送り先デバイス１４へ送信されてよい。通信媒体は、無線周波数（radio  frequency，ＲＦ）スペクトル又は１以上の物理伝送路のような如何なる無線又は有線通信媒体も有してよい。通信媒体は、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、又はインターネットのような世界規模のネットワークのような、パケットに基づくネットワークの部分を形成してよい。通信媒体は、ソースデバイス１２から送り先デバイス１４への通信を助けるのに有用であることができるルータ、スイッチ、基地局、又はあらゆる他の設備を含んでよい。
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】００２９
【補正方法】変更
【補正の内容】
【００２９】
いくつかの例において、符号化されたデータは、出力インターフェイス２２から記憶デバイスへ出力されてよい。同様に、符号化されたデータは、入力インターフェイスによって記憶デバイスからアクセスされてよい。記憶デバイスは、ハードドライブ、ブルーレイディスク、デジタル・ビデオ・ディスク（digital  video  discs，ＤＶＤ）、コンパクト・ディスク・リード・オンリー・メモリ（Compact  Disc  Read-Only  Memories，ＣＤ−ＲＯＭ）、フラッシュメモリ、揮発性若しくは不揮発性メモリ、又は符号化された映像データを記憶するためのあらゆる他の適切なデジタル記憶媒体のような、様々な分散した又は局所的にアクセスされるデータ記憶媒体の中のいずれかを含んでよい。更なる例では、記憶デバイスは、ソースデバイス１２によって生成される符号化された映像を記憶し得るファイルサーバ又は他の中間記憶デバイスに対応してよい。送り先デバイス１４は、記憶された映像データに記憶デバイスからストリーミング又はダウンロードによりアクセスしてよい。ファイルサーバは、符号化された映像データを記憶し、その符号化された映像データを送り先デバイス１４へ送信することができる如何なるタイプのサーバであってもよい。ファイルサーバの例には、ウェブサーバ（例えば、ウェブサイト用）、ファイル転送プロトコル（file  transfer  protocol，ＦＴＰ）サーバ、ネットワーク・アッタチト・ストレージ（network  attached  storage，ＮＡＳ）デバイス、又はローカルディスクドライブがある。送り先デバイス１４は、インターネット接続を含む何らかの標準的なデータ接続を通じて、符号化された映像データにアクセスしてよい。これは、ファイルサーバ上に記憶されている符号化された映像データにアクセスすることに適している無線チャネル（例えば、Ｗｉ−Ｆｉ接続）、有線接続（例えば、デジタル加入者回線（digital  subscriber  line，ＤＳＬ）、ケーブルモデム、など）、又は両方の組み合わせを含んでよい。記憶デバイスからの符号化された映像データの送信は、ストリーミング伝送、ダウンロード伝送、又はそれらの組み合わせであってよい。
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】００３０
【補正方法】変更
【補正の内容】
【００３０】
本開示の技術は、無線用途又は設定に必ずしも制限されない。技術は、無線テレビ放送、ケーブルテレビ伝送、衛星テレビ伝送、ダイナミック・アダプティブ・ストリーミング・オーバーＨＴＴＰ（dynamic  adaptive  streaming  over  HTTP，ＤＡＳＨ）のようなインターネットストリーミングビデオ伝送、データ記憶媒体上に符号化されるデジタル映像、データ記憶媒体に記憶されたデジタル映像の復号化、又は他の応用のような、様々なマルチメディアアプリケーションの中のいずれかを支持して映像コーディングに適用され得る。いくつかの例において、コーディングシステム１０は、映像ストリーミング、映像再生、映像放送、及び／又はテレビ電話のような用途をサポートするために一方向又は双方向の映像伝送をサポートするよう構成されてよい。
【手続補正１０】
【補正対象書類名】明細書
【補正対象項目名】００３２
【補正方法】変更
【補正の内容】
【００３２】
図１の表されているコーディングシステム１０は、単に一例にすぎない。双方向予測の技術は、如何なるデジタルビデオ符号化及び／又は復号化デバイスによっても実行されてよい。本開示の技術は一般的にビデオコーディングデバイスによって実行されるが、本技術は、通常「ＣＯＤＥＣ」と呼ばれるビデオ符号器／復号器によっても実行されてよい。更に、本開示の技術は、ビデオプロセッサによっても実行されてよい。ビデオ符号器及び／又は復号器は、グラフィクス処理ユニット（graphics  processing  unit，ＧＰＵ）又は同様のデバイスであってよい。
【手続補正１１】
【補正対象書類名】明細書
【補正対象項目名】００３７
【補正方法】変更
【補正の内容】
【００３７】
送り先デバイス１４の入力インターフェイス２８は、コンピュータ可読媒体１６から情報を受信する。コンピュータ可読媒体１６の情報は、ビデオ符号器２０によって定義されたシンタックス情報を含んでよく、これは、ビデオ復号器３０によっても使用され、ブロック及び他の符号化単位、例えば、グループ・オブ・ピクチャ（group  of  pictures，ＧＯＰ）の特性及び／又は処理を記述するシンタックス要素を含む。表示デバイス３２は、復号された映像データをユーザに表示し、陰極線管（cathode  ray  tube，ＣＲＴ）、液晶ディスプレイ（liquid  crystal  display，ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（organic  light  emitting  diode，ＯＬＥＤ）ディスプレイ、又は他のタイプの表示デバイスのような様々な表示デバイスの中のいずれかを有してよい。
【手続補正１２】
【補正対象書類名】明細書
【補正対象項目名】００３８
【補正方法】変更
【補正の内容】
【００３８】
ビデオ符号器２０及びビデオ復号器３０は、目下開発中である高能率映像符号化（High  Efficiency  Video  Coding，ＨＥＶＣ）標準のような映像符号化標準に従って動作してよく、ＨＥＶＣテストモデル（HEVC  Test  Model，ＨＭ）に準拠してよい。代替的に、ビデオ符号器２０及びビデオ復号器３０は、モーション・ピクチャ・エキスパート・グループ（Motion  Picture  Expert  Group，ＭＰＥＧ）−４、パート１０、アドバンスト・ビデオ・コーディング（Advanced  Video  Coding，ＡＶＣ）と代替的に呼ばれる国際電気通信連合電気通信標準化部門（International  Telecommunications  Union  Telecommunication  Standardization  Sector，ＩＴＵ−Ｔ）Ｈ．２６４標準、Ｈ．２６５／高能率映像符号化（ＨＥＶＣ）、又はそのような標準の拡張のような、他の独自仕様又は業界標準に従って動作してもよい。なお、本開示の技術は、如何なる特定の符号化標準にも制限されない。映像符号化標準の他の例には、ＭＰＥＧ−２及びＩＴＵ−Ｔ  Ｈ．２６３がある。図１に示されていないが、いくつかの態様において、ビデオ符号器２０及びビデオ復号器３０は、オーディオ符号器及び復号器と夫々一体化されてもよく、共通のデータストリーム又は別個のデータストリームにおける音声及び映像の両方の符号化を扱うために、適切なマルチプレクサ−デマルチプレクサ（multiplexer-demultiplexer，ＭＵＸ−ＤＥＭＵＸ）ユニット、又は他のハードウェア及びソフトウェアを含んでもよい。適用可能な場合には、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ  Ｈ．２２３マルチプレクサプロトコル、又はユーザ・データグラム・プロトコル（user  datagram  protocol，ＵＤＰ）のような他のプロトコルに準拠してよい。
【手続補正１３】
【補正対象書類名】明細書
【補正対象項目名】００３９
【補正方法】変更
【補正の内容】
【００３９】
ビデオ符号器２０及びビデオ復号器３０は、１以上のマイクロプロセッサ、デジタル信号プロセッサ（digital  signal  processors，ＤＳＰ）、特定用途向け集積回路（application  specific  integrated  circuits，ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（field  programmable  gate  arrays，ＦＰＧＡ）、ディスクリートロジック、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組み合わせのような、様々な適切な符号器回路の中のいずれかとして夫々実装されてよい。技術が部分的にソフトウェアにおいて実装される場合に、デバイスは、適切な非一時的コンピュータ可読媒体にソフトウェアの命令を記憶し、１以上のプロセッサを用いてハードウェアで命令を実行して、本開示の技術を実行し得る。ビデオ符号器２０及びビデオ復号器３０の夫々は、１以上の符号器又は復号器に含まれてよく、それらのうちのいずれか一方は、各々のデバイスにおいて複合的符号器／復号器（combined  encoder/decoder，ＣＯＤＥＣ）の部分として組み込まれてよい。ビデオ符号器２０及び／又はビデオ復号器３０を含むデバイスは、集積回路、マイクロプロセッサ、及び／又は携帯電話機のような無線通信デバイスを有してよい。
【手続補正１４】
【補正対象書類名】明細書
【補正対象項目名】００４３
【補正方法】変更
【補正の内容】
【００４３】
更に、パーティションユニット４８は、前の符号化パスにおける前の区分化スキームの評価に基づいて、ビデオのブロックをサブブロックに区分化し得る。例えば、パーティションユニット４８は最初に、フレーム又はスライスを最大符号化単位（largest  coding  units，ＬＣＵ）に区分化し、そして、レートひずみ解析（例えば、レートひずみ最適化）に基づいてＬＣＵの夫々をサブ符号化単位（sub-coding  units，ｓｕｂ−ＣＵ）に区分化してよい。モード選択ユニット４０は、サブＣＵへのＬＣＵの区分化を示す四分木データ構造を更に生成し得る。四分木のリーフノードＣＵは、１以上の予測単位（prediction  units，ＰＵ）及び１以上の変換単位（transform  units，ＴＵ）を含み得る。
【手続補正１５】
【補正対象書類名】明細書
【補正対象項目名】００４６
【補正方法】変更
【補正の内容】
【００４６】
動き推定ユニット４２及び動き補償ユニット４４は高度に集積され得るが、概念上別々に表されている。動き推定ユニット４２によって実行される動き推定は、動きベクトルを生成するプロセスであり、ビデオブロックの動きを推定する。動きベクトルは、例えば、現在のフレーム内の符号化される現在のブロック（又は他の符号化単位）に対する基準フレーム内の予測ブロック（又は他の符号化単位）に対する現在のビデオフレーム又はピクチャ内のビデオブロックのＰＵの変位を示し得る。予測ブロックは、差分絶対値和（sum  of  absolute  difference，ＳＡＤ）、差分二乗和（sum  of  square  difference，ＳＳＤ）、又は他の差分メトリクスによって決定され得る画素差に関して、符号化されるブロックに一致することが判明したブロックである。いくつかの例において、ビデオ符号器２０は、参照フレームメモリ６４に記憶されている参照ピクチャのサブ整数画素位置について値を計算してよい。例えば、ビデオ符号器２０は、参照画素の４分の１画素位置、８分の１画素位置、又は他の分数画素位置の値を補間し得る。従って、動き推定ユニット４２は、全画素位置及び分数画素位置に対して動き探索を実行し、分数画素精度で動きベクトルを出力し得る。
【手続補正１６】
【補正対象書類名】明細書
【補正対象項目名】００５１
【補正方法】変更
【補正の内容】
【００５１】
更に、イントラ予測ユニット４６は、デプス・モデリング・モード（depth  modeling  mode，ＤＭＭ）を用いてデプスマップのデプスブロックを符号化するよう構成されてよい。モード選択ユニット４０は、例えば、レートひずみ最適化（rate-distortion  optimization，ＲＯＤ）を用いて、利用可能なＤＭＭモードがイントラ予測モード及び他のＤＭＭモードよりも良い符号化結果をもたらすかどうかを決定し得る。デプスマップに対応するテクスチャ画像のデータは、参照フレームメモリ６４に記憶され得る。動き推定ユニット４２及び動き補償ユニット４４はまた、デプスマップのデプスブロックをインタ予測するよう構成されてよい。
【手続補正１７】
【補正対象書類名】明細書
【補正対象項目名】００５４
【補正方法】変更
【補正の内容】
【００５４】
変換処理ユニット５２は、離散コサイン変換（discrete  cosine  transform，ＤＣＴ）又は概念的に類似した変換のような変換を残差ブロックに適用して、残差変換係数値を含むビデオブロックを生成する。変換処理ユニット５２は、ＤＣＴ苦い年上類似している他の変換を実行してもよい。ウェーブレット変換、整数変換、サブバンド変換又は他のタイプの変換も使用され得る。
【手続補正１８】
【補正対象書類名】明細書
【補正対象項目名】００５６
【補正方法】変更
【補正の内容】
【００５６】
量子化に続いて、エントロピ符号化ユニット５６は、量子化された変換係数をエントロピ符号化する。例えば、エントロピ符号化ユニット５６は、コンテキスト適応型可変長符号化（context  adaptive  variable  length  coding，ＣＡＶＬＣ）、コンテキスト適応型２進演算符号化（context  adaptive  binary  arithmetic  coding，ＣＡＢＡＣ）、シンタックスに基づくコンテキスト適応型２進演算符号化（syntax-based  context-adaptive  binary  arithmetic  coding，ＳＢＡＣ）、確率区間区分エントロピ（probability  interval  partitioning  entropy，ＰＩＰＥ）符号化又は他のエントロピ符号化技術を実行してよい。コンテキストに基づくエントロピ符号化の場合に、コンテキストは、隣接するブロックに基づき得る。エントロピ符号化ユニット５６によるエントロピ符号化に続いて、符号化されたビットストリームは、他のデバイス（例えば、ビデオ復号器３０）へ送信されても、あるいは、後の送信又は取り出しのためにアーカイブに保管されてもよい。
【手続補正１９】
【補正対象書類名】明細書
【補正対象項目名】００６４
【補正方法】変更
【補正の内容】
【００６４】
当業者に明らかなように、図１のコーディングシステム１０はＧＢｉに適している。ＧＢｉは、ブロックレベル適応重みを用いて２つの動き補償された予測ブロックの加重平均を計算することによってブロックの予測信号を生成するインタ予測技術である。従来の双予測と異なり、ＧＢｉにおける重み（ＧＢｉ重みと呼ばれ得る。）の値は、０．５に制限されない。ＧＢｉのためのインタ予測技術は、次の通りに定式化され得る：
P[x]＝(1−w)×P0[x＋v0]＋ｗ×P1[x＋V1]          （１）
ここで、P[x]は、ピクチャ位置ｘに位置する現在のブロックサンプルの予測を表し、夫々のPi[x＋vi]，∀i∈{0,1}は、参照リストＬｉ内の参照ピクチャからの動きベクトル（motion  vector，ＭＶ）ｖｉに関連した現在のブロックサンプルの動き補償された予測であり、w及び1−wは、夫々、P0[x＋v0]及びP1[x＋v1]に適用される重み値を表す。
【手続補正２０】
【補正対象書類名】明細書
【補正対象項目名】００６６
【補正方法】変更
【補正の内容】
【００６６】
コーディング中に、ブロックは、ビデオ符号器２０のような符号器によってパーティションに分けられる。例えば、６４×６４ブロックは、３２×３２ブロックに分けられてよい。これらのより小さいブロックは、四分木プラス二分木（quadtree  plus  binary  tree，ＱＴＢＴ）におけるリーフノードと呼ばれ得る。重み候補の組（例えば、Ｗ１、Ｗ２、又はＷ３）においてｗがどこに位置するかを示すために、インデックスがＱＴＢＴ構造のリーフノードで導入されて、重み候補の組（例えば、Ｗ１、Ｗ２、又はＷ３）においてｗがどこに位置するかを示す。その後に、インデックス２値化は、表１で特定される２つの２値化スキームのうちの１つにより行われる。示されるように、夫々のシーケンスレベルテスト（例えば、テスト１、テスト２、など）は、重み値（例えば、３／８）に対応するインデックス番号（例えば、０、１、２、３、など）と、スキームごとのビン（例えば、０又は１）から形成された２値化コードワード（例えば、００、１、０２、０００１、など）とを含む。
【表１】
2020520174.tif 000034
【手続補正２１】
【補正対象書類名】明細書
【補正対象項目名】００６７
【補正方法】変更
【補正の内容】
【００６７】
２値化スキームの選択は、第２参照ピクチャの動きベクトル差分（motion  vector  difference，ＭＶＤ）がゼロに等しく、そのためビットストリームにおいて伝えられないかどうかを示すスライスレベルフラグmvd_l1_zero_flagの値に応じて、スライスごとに適応される。スライスレベルフラグが０に等しい場合には、スキーム＃１が使用される。スライスレベルフラグが１に等しい場合には、スキーム＃２が使用される。２値化コードワードにおける各ビン（例えば、０又は１）は次いで、２値化の後にコンテキスト符号化される。
【手続補正２２】
【補正対象書類名】明細書
【補正対象項目名】００７４
【補正方法】変更
【補正の内容】
【００７４】
４つの重みサブセット及び固定長符号化を使用するシグナリングの他の例が、説明のために与えられる。そのような場合に、重みサブセットフラグは、４つの重みサブセットインデックスを符号化するために２つのビンを使用する。先と同じく、Ｍは、重みインデックスの数を表す。しかし、可変長符号化の例とは異なり、ｌｏｇ２（Ｍ）個のビンが、選択されたブロック重みインデックスを伝えるために使用される。そのようなものとして、Ｍ＝４。従って、２値化スキームで使用されるコードワードは、００、１０、０１、１１である。
【表３】
2020520174.tif 000035
【手続補正２３】
【補正対象書類名】明細書
【補正対象項目名】０１０５
【補正方法】変更
【補正の内容】
【０１０５】
実施形態において、現在の領域の重みサブセットは、異なるレベルで信号により伝えられるフラグを用いて、隣接する領域に応じて適応的に指示され得る。現在の領域及び隣接する領域は、ＣＴＵのグループ、ＣＴＵ、ＣＵ、ＰＵ、などであることができる。例えば、ＣＴＵレベルにおいて、選択された重みサブセットは、次のシンタックスを用いて隣接ＣＴＵから導出され得る：
【表２１】
2020520174.tif 000036
ここで、１に等しいctu_gbi_merge_flagは、現在のコーディング・ツリー・ユニットのＧＢｉ重みサブセットが、隣接するコーディング・ツリー・ユニットの対応するシンタックス要素から導出されることを特定し、ここで、０に等しいctu_gbi_merge_flagは、それらのシンタックス要素が、隣接するコーディング・ツリー・ユニットの対応するシンタックス要素から導出されないことを特定する。
【手続補正２４】
【補正対象書類名】明細書
【補正対象項目名】０１０７
【補正方法】変更
【補正の内容】
【０１０７】
実施形態において、現在のブロック４０２の重みは、その隣接するブロックのいずれか１つに使用されている重みと同じであってよい。隣接するブロックは、空間的ＧＢｉ隣接ブロック４０４、例えば、上、左、左上、右上、及び左下、など、又は時間的に隣接するブロックであってよい。実施形態において、時間的に隣接するブロックは、時間的動きベクトル予測子（temporal  motion  vector  predictor，ＴＭＶＰ）を用いて識別される、前に符号化されたピクチャの中の１つ、で見つけられる。プルーニングプロセスは、異なる隣接ブロックからの同じ重みを取り除くために実行されてよい。Ｍで表される残りの異なる重みは次いで、リストを形成する。それらのインデックスは、符号器から復号器へ信号伝達及び送信される。
【手続補正２５】
【補正対象書類名】明細書
【補正対象項目名】０１１２
【補正方法】変更
【補正の内容】
【０１１２】
本明細書には、現在のブロックのために最確重み及び残余重みを使用する方法も開示されている。そのような方法で、現在の符号化ブロックのとり得る重みは、２つのタイプ、例えば、最確重み（most  probable  weights，ＭＰＷ）及び残余重み（remaining  weights，ＲＭＷ）に分類される。フラグは、現在のブロックの重みが最確重みの１つであるかどうかを信号により伝えるために使用される。フラグは、１ビット又は１ビンであってよく、コンテキスト符号化されてよい。
【手続補正２６】
【補正対象書類名】明細書
【補正対象項目名】０１２４
【補正方法】変更
【補正の内容】
【０１２４】
candWeightList[x]は、次のように導出され、ｘは、０乃至重みの数であることができる。この実施形態では、ｘは、例えば、０乃至２に等しい。  
candWeightBがcandWeightAに等しい場合に、以下が適用される：
candWeightAが１／２又は５／８に等しい場合に、ｘ＝０・・２であるcandWeightList[x]は、次のように導出される：
candWeightList[0]＝1/2
candWeightList[1]＝5/8
candWeightList[2]＝3/4
そうでない場合に、ｘ＝０・・２であるcandWeightList [x]は、次のように導出される：
candWeightList[0]＝candWeightA
candWeightList[1]＝1/2
candWeightList[2]＝5/8
他の場合に（candWeightBがcandWeightAに等しくない。）、以下が適用される：
candWeightList[0]及びcandWeightList[1]が、次のように導出される：
candWeightList[0]＝candWeightA
candWeightList[1]＝candWeightB
candWeightList[0]及びcandWeightList[1]のどちらも１／２に等しくない場合に、candWeightList[2]は１／２に等しくセットされ、
さもなくば、candWeightList[0]及びcandWeightList[1]のどちらも５／８に等しくない場合に、candWeightList[2]は５／８に等しくセットされ、
その他の場合に、candWeightList[2]は３／４に等しくセットされる。
【手続補正２７】
【補正対象書類名】明細書
【補正対象項目名】０１２５
【補正方法】変更
【補正の内容】
【０１２５】
第３に、現在のブロックの重みは、次のプロシージャを適用することによって導出される：
prev_gbi_weight_flag[x0+i][y0+j]が１に等しい場合に、現在のブロックの重みは、candWeightList[mpm_weight_idx]に等しくセットされる。  
そうでない場合に、現在のブロックの重みWeightPred[xPb][yPb]は、次の順序付けられたステップを適用することによって導出される：
WeightPred[xPb][yPb]は、rem_pred_weight[xPb][yPb]に等しくセットされる。  
ｉが０乃至２に等しい場合に、WeightPred[xPb][yPb]がcandWeightList[i]以上であるときに、WeightPred[xPb][yPb]の値は１だけ増分される。
【手続補正２８】
【補正対象書類名】明細書
【補正対象項目名】０１２６
【補正方法】変更
【補正の内容】
【０１２６】
実施形態において、ｉが０乃至２に等しい場合に、WeightPred[xPb][yPb]がcandWeightList[i]以上であるときに、WeightPred[xPb][yPb]の値は１減じられる。
【手続補正２９】
【補正対象書類名】明細書
【補正対象項目名】０１４２
【補正方法】変更
【補正の内容】
【０１４２】
ブロック７０４で、重みサブセットの１つが符号化のために選択される。例えば、｛１／４、３／４、−１／４｝のサブセットが選択されてよい。ブロック７０７で、重みサブセットフラグがビットストリームの特定の部分内に符号化される。重みサブセットフラグは、選択された重みサブセットの１つを識別するために使用される重みサブセットインデックスを含む。特定の部分は、例えば、ビットストリームのＳＰＳ、ビットストリームのＰＰＳ、ビットストリームのスライスヘッダ、又はＣＴＵ若しくはＣＴＵのグループによって表されるビットストリームの領域であってよい。
【国際調査報告】
2020520174.tif 000037
2020520174.tif 000038
2020520174.tif 000039