(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-11-01
(45)【発行日】2023-11-10
(54)【発明の名称】ハイブリッドビデオ符号化ツールのための使用事例駆動コンテキストモデル選択
(51)【国際特許分類】
H04N 19/13 20140101AFI20231102BHJP
H04N 19/136 20140101ALI20231102BHJP
H04N 19/176 20140101ALI20231102BHJP
H04N 19/91 20140101ALI20231102BHJP
【FI】
H04N19/13
H04N19/136
H04N19/176
H04N19/91
(21)【出願番号】P 2021551521
(86)(22)【出願日】2020-03-04
(86)【国際出願番号】 EP2020055732
(87)【国際公開番号】W WO2020178352
(87)【国際公開日】2020-09-10
【審査請求日】2021-10-25
(32)【優先日】2019-03-05
(33)【優先権主張国・地域又は機関】EP
(73)【特許権者】
【識別番号】500341779
【氏名又は名称】フラウンホーファー-ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン
(74)【代理人】
【識別番号】110002952
【氏名又は名称】弁理士法人鷲田国際特許事務所
(74)【代理人】
【識別番号】100134119
【氏名又は名称】奥町 哲行
(72)【発明者】
【氏名】ファフ・ヨナサン
(72)【発明者】
【氏名】ヘレ・フィリップ
(72)【発明者】
【氏名】シェーファー・ミヒャエル
(72)【発明者】
【氏名】ヒンツ・トビアス
(72)【発明者】
【氏名】スタレンバーガー・ビョルン
(72)【発明者】
【氏名】マークル・フィリップ
(72)【発明者】
【氏名】シュヴァルツ・ハイコー
(72)【発明者】
【氏名】マルペ・デトレフ
(72)【発明者】
【氏名】ヴィーガンド・トーマス
【審査官】田中 純一
(56)【参考文献】
【文献】国際公開第2019/009503(WO,A1)
【文献】米国特許出願公開第2021/0152823(US,A1)
【文献】特表2022-506152(JP,A)
【文献】特表2022-531334(JP,A)
【文献】米国特許出願公開第2020/0359033(US,A1)
【文献】Jonathan Pfaff, et al.,CE3: Affine linear weighted intra prediction (test 1.2.1, test 1.2.2),Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 13th Meeting: Marrakech, MA, 9-18 Jan. 2019,JVET-M0043,URL:http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/13_Marrakech/wg11/JVET-M0043-v2.zip,2019年01月09日,pp. 1~11,学術文献等DB
(58)【調査した分野】(Int.Cl.,DB名)
H04N 7/12
H04N 19/00 - 19/98
IEEE Xplore
(57)【特許請求の範囲】
【請求項1】
CABACエンコーダを含むエンコーダであって、前記エンコーダは画像又はビデオデータを受信し、受信した前記画像又はビデオデータを符号化し、前記画像又はビデオデータを表すビットストリームを提供するように構成され、
前記CABACエンコーダは、符号化される前記画像又はビデオデータのブロックに関連付けられたバイナリ値構文要素を受信し、選択されたコンテキストモデルを使用して、前記バイナリ値構文要素を前記ビットストリームの符号化されたビットに符号化するように構成され、
前記バイナリ値構文要素は、行列ベースのイントラ予測,MIPに対応する、線形重み付きイントラ予測,LWIPのような特定の符号化ツールが、前記画像又はビデオデータのブロックを符号化するときに使用されるかどうかを示すツールフラグを表し、
アスペクト比が2より大きい前記画像又はビデオデータのブロックについて、前記特定の符号化ツールが適用可能である場合、前記ツールフラグを符号化するための第1のコンテキストモデルが、1つ又は複数の第1のコンテキストモデルのグループから選択され、
アスペクト比が2以下であり、前記特定の符号化ツールが適用可能な前記画像又はビデオデータのブロックについて、前記ツールフラグを符号化するための第2のコンテキストモデルが、1つ又は複数の第2のコンテキストモデルのグループから選択される、エンコーダ
を備える、装置。
【請求項2】
前記符号化ツールは、線形重み付きイントラ予測,LWIPであり、前記第1のコンテキストモデルは、2より大きいアスペクト比を有する前記画像又はビデオデータのブロックの前記ツールフラグを送信するためのCABACコンテキストを含み、
アスペクト比が2より大きい前記ブロックについてLWIPモードがテストされない場合、前記
ツールフラグは常に0であり、追加のCABACコンテキストは1を送信する確率がゼロになるように適応し、
アスペクト比が2より大きい前記ブロックについてLWIPモードがテストされる場合、前記
ツールフラグは一定の確率で1である、
請求項1に記載の装置。
【請求項3】
前記CABACエンコーダは、選択指標に応答して、現在処理されているブロックの前記第1のコンテキストモデル及び前記第2のコンテキストモデルを選択し、前記選択指標は、現在処理されているブロックが2より大きいアスペクト比を有するか、又は2以下のアスペクト比を有することを示す、請求項1又は2に記載の装置。
【請求項4】
CABACデコーダを含むデコーダであって、前記デコーダは符号化された画像又はビデオデータを含むビットストリームを受信し、受信した前記ビットストリームから符号化された前記画像又はビデオデータを復号し、復号された前記画像又はビデオデータを提供するように構成され、
前記CABACデコーダは選択されたコンテキストモデルを使用して、符号化された前記画像又はビデオデータのブロックに関連付けられたバイナリ値構文要素を、前記ビットストリームから復号するように構成され、
前記バイナリ値構文要素は、行列ベースのイントラ予測,MIPに対応する、線形重み付きイントラ予測,LWIPのような特定の符号化ツールが、前記画像又はビデオデータのブロックを復号するために使用されたかどうかを示すツールフラグを表し、
アスペクト比が2より大きい前記画像又はビデオデータのブロックについて、前記特定の符号化ツールが適用可能である場合、前記ツールフラグを復号するための第1のコンテキストモデルが、1つ又は複数の第1のコンテキストモデルのグループから選択され、
アスペクト比が2以下であり、前記特定の符号化ツールが適用可能な前記画像又はビデオデータのブロックについて、前記ツールフラグを復号するための第2のコンテキストモデルが、1つ又は複数の第2のコンテキストモデルのグループから選択される、デコーダ
を備える、装置。
【請求項5】
画像又はビデオデータを符号化する方法であって、前記方法は、
画像又はビデオデータを受信することと、
受信した前記画像又はビデオデータを符号化することと、
前記画像又はビデオデータを表すビットストリームを提供することと
を含み、
受信した前記画像又はビデオデータを符号化することは、
CABACエンコーダを使用して、符号化される前記画像又はビデオデータのブロックに関連付けられたバイナリ値構文要素を受信することと、
選択されたコンテキストモデルを使用して、前記バイナリ値構文要素を前記ビットストリームの符号化されたビットに符号化することと
を含み、
前記バイナリ値構文要素は、行列ベースのイントラ予測,MIPに対応する、線形重み付きイントラ予測,LWIPのような特定の符号化ツールが、前記画像又はビデオデータのブロックを符号化するときに使用されるかどうかを示すツールフラグを表し、
アスペクト比が2より大きい前記画像又はビデオデータのブロックについて、前記特定の符号化ツールが適用可能である場合、前記ツールフラグを符号化するための第1のコンテキストモデルが、1つ又は複数の第1のコンテキストモデルのグループから選択され、
アスペクト比が2以下であり、前記特定の符号化ツールが適用可能な前記画像又はビデオデータのブロックについて、前記ツールフラグを符号化するための第2のコンテキストモデルが、1つ又は複数の第2のコンテキストモデルのグループから選択される、
方法。
【請求項6】
画像又はビデオデータを復号する方法であって、前記方法は、
符号化された画像又はビデオデータを含むビットストリームを受信することと、
受信した前記ビットストリームから符号化された前記画像又はビデオデータを復号することと、
復号された前記画像又はビデオデータを提供することと
を含み、
受信した前記画像又はビデオデータを復号することは、CABACデコーダ及び選択されたコンテキストモデルを使用して、符号化された前記画像又はビデオデータのブロックに関連付けられたバイナリ値構文要素を、前記ビットストリームから復号すること
を含み、
前記バイナリ値構文要素は、行列ベースのイントラ予測,MIPに対応する、線形重み付きイントラ予測,LWIPのような特定の符号化ツールが、前記画像又はビデオデータのブロックを復号するために使用されたかどうかを示すツールフラグを表し、
アスペクト比が2より大きい前記画像又はビデオデータのブロックについて、前記特定の符号化ツールが適用可能である場合、前記ツールフラグを復号するための第1のコンテキストモデルが、1つ又は複数の第1のコンテキストモデルのグループから選択され、
アスペクト比が2以下であり、前記特定の符号化ツールが適用可能な前記画像又はビデオデータのブロックについて、前記ツールフラグを復号するための第2のコンテキストモデルが、1つ又は複数の第2のコンテキストモデルのグループから選択される、
方法。
【請求項7】
命令を含むコンピュータ読み取り可能な記憶媒体であって、前記命令は、コンピュータによって実行されると、前記コンピュータに請求項5又は6のいずれか一項に記載の方法を実行させる、コンピュータ読み取り可能な記憶媒体。
【請求項8】
エンコーダであって、前記エンコーダは画像又はビデオデータを受信し、受信した前記画像又はビデオデータを符号化し、前記画像又はビデオデータを表すビットストリームを提供し、
前記エンコーダはCABACエンコーダを含み、前記CABACエンコーダは、符号化される前記画像又はビデオデータの特定のデータブロックに関連付けられたバイナリ値構文要素を受信し、選択されたコンテキストモデルを使用して、前記バイナリ値構文要素を前記ビットストリームの符号化されたビットに符号化し、
前記バイナリ値構文要素は、特定の符号化ツールが、前記画像又はビデオデータを符号化するときに使用されるかどうかを示すツールフラグを含み、
前記ツールフラグを符号化するための第1のコンテキストモデルのグループは、アプリケーションとは無関係に、前記符号化ツールが常に適用可能である前記特定のデータブロックの1つ又は複数の第1の部分に対して選択され、
前記ツールフラグを符号化するための第2のコンテキストモデルのグループは、前記アプリケーションに応じて、前記符号化ツールが適用可能又は適用不可能である前記特定のデータブロックの1つ又は複数の第2の部分に対して選択される、エンコーダ
を備える、装置。
【請求項9】
前記CABACエンコーダは、選択指標に応答して、前記特定のデータブロックの現在処理されている部分に対して前記第1のコンテキストモデル又は前記第2のコンテキストモデルを選択し、前記選択指標は、前記特定のデータブロックの前記現在処理されている部分が前記第1の部分であることを示す第1の値を有し、前記選択指標は、前記特定のデータブロックの前記現在処理されている部分が前記第2の部分であることを示す第2の値を有する、請求項8に記載の装置。
【請求項10】
デコーダであって、前記デコーダは符号化された画像又はビデオデータを含むビットストリームを受信し、受信した前記ビットストリームから符号化された前記画像又はビデオデータを復号し、復号された前記画像又はビデオデータを提供し、
前記デコーダはCABACデコーダを含み、前記CABACデコーダは選択されたコンテキストモデルを使用して、符号化された前記画像又はビデオデータの特定のデータブロックに関連付けられたバイナリ値構文要素を、前記ビットストリームから復号し、
前記バイナリ値構文要素は、特定の符号化ツールが、前記画像又はビデオデータを符号化するときに使用されるかどうかを示すツールフラグを含み、
前記ツールフラグを復号するための第1のコンテキストモデルのグループは、アプリケーションとは無関係に、前記符号化ツールが常に適用可能である前記特定のデータブロックの部分に対して選択され、
前記ツールフラグを復号するための第2のコンテキストモデルのグループは、アプリケーションに応じて、前記符号化ツールが適用可能又は適用不可能である前記特定のデータブロックの部分に対して選択される、デコーダ
を備える、装置。
【請求項11】
前記CABACデコーダは、選択指標に応答して、前記特定のデータブロックの現在処理されている部分に対して前記第1のコンテキストモデル又は前記第2のコンテキストモデルを選択し、前記選択指標は、前記特定のデータブロックの前記現在処理されている部分が第1の部分であることを示す第1の値を有し、前記選択指標は、前記特定のデータブロックの前記現在処理されている部分が第2の部分であることを示す第2の値を有する、請求項10に記載の装置。
【請求項12】
前記第1のコンテキストモデルのグループは、1つの第1のコンテキストモデル又は様々な第1のコンテキストモデルを含み、前記第2のコンテキストモデルのグループは、1つの第2のコンテキストモデル又は様々な第2のコンテキストモデルを含む、請求項8から11のいずれか一項に記載の装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ピクチャ、画像又はビデオを符号化/復号する分野に関し、より具体的には、コンテキスト適応バイナリ算術符号化CABACエンジンのコンテキスト若しくはコンテキストモードを使用する、多用途のビデオ符号化VVC規格の、アフィン線形重み付きイントラ予測LWIP、又は行列ベースのイントラ予測MIPなどの、1つ又は複数の符号化ツールの符号化に関する。実施形態は、処理される画像又はビデオデータのブロックのアスペクト比に応じて選択されたコンテキストモデルに基づくVVC規格のLWIP又はMIPの適用可能性を示す、intra_mip_flagのようなフラグの符号化に関する。
【背景技術】
【0002】
ITU T H.265|MPEG H HEVC[1]のような最先端のビデオ符号化規格では、ピクチャは固定された正方形サイズのCodingTreeUnitに分割され、これはより小さいブロックに更に細分化することができる。このようなブロックの再構築された信号は、通常、予測信号と残差信号との重畳である。予測信号は、隣接する近隣のサンプルを現在のブロックに外挿すること(イントラ予測)、又は1つ若しくは2つの参照ピクチャからのサンプルのフィルタリングされた表現若しくはフィルタリングされていない表現をコピーすること(インター予測)のいずれかによって得られる。参照ピクチャは、ビットストリームから既に再構築されており、参照のためにピクチャバッファに格納されているピクチャである。残差信号は、ビットストリームから読み出された逆量子化された変換係数を逆変換することによって得られる。ブロック再構築プロセスの後、再構築されたブロックの信号を強調し、再構築されたピクチャを取得するために、インループフィルタが適用される。
【0003】
ビットストリームから変換係数、デルタQP、イントラ予測モード、動きベクトルの違いなどのシンボルを読み取るエントロピー復号プロセスは、コンテキスト適応バイナリ算術符号化(CABAC)エンジンを使用して、ビットストリームから読み取られたビットをバイナリ決定(ビン)に変換するパーサによって行われる。パーサは、これらのビンをシンボル又は構文要素に変換又は結合する。エントロピー符号化プロセスの適応性は、CABACコンテキスト(CC)を使用することによって実現される。各コンテキストは、特定のシンボル又はシンボルのセットのエントロピーをモデル化する適応確率モデルを表す。適応という用語は、現在の符号化状態に向かうモデルの永続的な更新を示す。したがって、モデルは、対応するシンボルのローカル統計に適応する。更新ステップは、通常、算術符号化演算に埋め込まれる。まず、CCの現在の状態は、算術符号化プロセスをパラメータ化するために使用される。次に、復号されたシンボルが導出されると、それは、現在の復号された確率に対して所与のステップサイズでCCを更新するために使用される。
【0004】
JEM-Software[2]並びに近い将来のVVC規格[3]においても、算術符号化処理に関する種々の改良が評価され、採用されている。算術符号化エンジンは変更されており、CCの初期化及び更新プロセスも改善されている。確率表現のダイナミックレンジ並びにCCの更新プロセスの挙動が改良されている。各CCは、現在の確率に対するCCの適応強度を制御する個々の2レベル更新ステップを有する。この改善は、予想されるCC使用統計に従ってCC更新プロセスをカスタマイズするのに役立つ。
【0005】
構文要素を送信するために必要とされるバイナリ決定の数が多いため、また、そのような構文要素の数のため、バイナリ決定は、デコーダによって処理され得るCCの実用的な数又は量に達するために、同じCCを使用してグループ化されなければならない。更に、グループ化は、更新プロセスがローカル統計を活用するのに役立ち、基礎となる確率モデルの安定性を改善する。
【0006】
同じ構文要素に属する統計的に類似した確率を有するバイナリ決定は、通常、1つのCCにグループ化される。この種のグループ化の例外は、バイナリ決定が隣接する近隣の既に復号されたシンボルから予測できる確率が異なる可能性が高い事例で行われる。この事例では、選択されたCCは、隣接する近隣の既に復号されたシンボルから予測される。このような手順は、通常、ビットストリームでかなり頻繁に送信されるシンボルに適用される。
【0007】
コンテキスト制御算術符号化の他に、0.5の固定確率を有するバイパスモードがある。算術コーダに組み込まれたこのバイパスモードは、高スループットのための低複雑度モードである。バイパスモードは、例えば、変換符号化に広く使用される。
【発明の概要】
【発明が解決しようとする課題】
【0008】
ビデオ符号化方法の進化は、ますます多様なブロック形状及びますます多くの符号化ツールを示しており、良好な符号化表現を見つけるためのエンコーダにおけるかなりの量のアルゴリズム複雑性をもたらしている。したがって、エンコーダでは、特定のコンテキストにおける符号化ツールの評価(すなわち、スイッチオフ)をスキップして、より良好な複雑さ対圧縮効率トレードオフを達成することが有益であり得る。ブロックに対する符号化ツールの使用は、通常、ビットストリーム内のコンテキストモデル化ツール有効化フラグを送信することによってデコーダに伝達される。
【0009】
理想的には、デコーダは、ツール有効化フラグ、すなわち、例えば符号化モード又は予測モードのようなツールが特定のブロックに適用されるか否かを決定するフラグが、ビットストリームで送信されるか否かについての制約を最小限に有する。その理由は、特定の事例でツールを無効にすると、これらのシナリオがかなり可能性が低い事例であっても、いくつかのシナリオで圧縮性能への影響が悪化する可能性があるためである。実際、ハイブリッドビデオコーデックの効率性の主な理由の1つは、非常に多種多様な競合する符号化ツールが常に可能であり、所与の事例でこれらのツールのうちの1つのみが選択されることである。
【0010】
例えば、小さなブロックサイズに対してのみツールを許可し、したがってツール有効化フラグを送信することに対する制約は、小さなブロックの小さな部分のみを通常含む非常に高い解像度を有する将来のアプリケーションの符号化効率を潜在的に低下させる。
【0011】
一方、可能性のあるすべての事例についてツール有効化フラグを送信することは、いくつかの事例について高速エンコーダ探索戦略がツールをテストしないアプリケーションシナリオでは非効率的であり、これは、これらの事例では、ツールが実行時間の点で高価すぎるために選択される可能性が低いか、又はこれらの事例でツールを使用することによる全体的な符号化効率への影響がかなり小さいためである。そのような設定では、特定の事例でツールをテストしないことは、より高速なエンコーダをもたらすが、符号化効率がいくらか低下するという代償を払う。特定の事例では、ツール有効化フラグがビットストリームで送信されるが、ツールは所与のシナリオではその事例に使用されない。したがって、このシナリオでは、エンコーダ探索制約がビットストリーム内でツール有効化フラグを送信する際の制約によっても表される場合、符号化効率はより高くなる。
【課題を解決するための手段】
【0012】
上述したような従来技術から、ピクチャ、画像、又はビデオを符号化/復号するために使用される1つ又は複数の符号化ツールの符号化のための改善又は強化が必要とされることがある。
本発明の実施形態は、添付の図面を参照して更に詳細に説明される。
【図面の簡単な説明】
【0013】
【
図1】本発明の実施形態による画像又はビデオデータを符号化するための装置を示す図である。
【
図2】本発明の実施形態による、符号化された画像又はビデオデータを復号するための装置を示す図である。
【
図3】2より大きいアスペクト比を有するブロックのフラグを送信するための個々の追加のCABACコンテキストを導入する、本発明の実施形態による画像又はビデオデータを符号化するための装置を示す図である。
【
図4】
図3の装置を使用して符号化された、2より大きいアスペクト比を有するブロックのフラグのための個々の追加のCABACコンテキストを導入する、本発明の実施形態による画像又はビデオデータを復号するための装置を示す図である。
【
図5】本発明の手法に従って説明されるユニット又はモジュール並びに方法のステップが実行され得るコンピュータシステムの一例を示す。
【発明を実施するための形態】
【0014】
ここで、本発明の実施形態を添付の図面を参照してより詳細に説明するが、同じ又は類似の要素には同じ参照符号が割り当てられている。
【0015】
上述したように、バイナリ決定をコンテキストモデルにグループ化する方法に関する設計では、以前の規格では、使用されるコンテキストモデルの数に対して全体的なエントロピーを下げる態様のみが考慮されている。この手法とは対照的に、本発明によれば、バイナリ決定をコンテキストモデルにどのようにグループ化するかに関する設計のための新しい態様が提示される。この手法は、アルゴリズム自体の複雑さの増大を考慮する。本発明は、符号化コンテキストを特定の符号化ツールをオフにするのに適したコンテキストと整列させるために、例えばコンテキストを挿入することによってコンテキストモデル化を適合させる。これにより、エンコーダは、圧縮効率の低下を回避しながら、アルゴリズムの複雑さが異なる動作点を選択することが可能になる。
【0016】
本発明の手法は、以下の例を使用して説明される。確率モデル化されたバイナリ決定が、アルゴリズム1によって表される第1のツールと、アルゴリズム2によって表される第2のツールとの間で切り替わると仮定する。ここで、第2のツールはベースラインツールであると考えられ、第1のツールはより特殊なツールであると考えられる。この仮定によれば、第2のツールは、第1のツールよりも全体的に選択される可能性が高い。一例として、第1のツールが第2のツールよりも好まれる全体確率が0.3であると仮定する。
【0017】
ここで、2つの適用シナリオが与えられていると仮定する。第1のアプリケーションAでは、両方のツールが試験され、最良の性能のツールが選択されるN個の事例がある。第2のアプリケーションBでは、何らかの理由で、N個すべての場合の決定された部分についてのみ、両方のツールが試験され、残りの場合については、ベースラインツール、すなわち第2のツールのみが選択される。両方のアプリケーションについて、N個すべての事例の決定は、コンテキストモデル化され、ビットストリームで送信される必要がある。一例として、アプリケーションBにおいて両方のツールがテストされる事例の数がN/2に等しいと仮定する。他のN/2の事例については、ツールはアプリケーションAで試験されるが、アプリケーションBでは試験されない。
【0018】
ツールフラグが単一のCCでコンテキスト符号化されている場合、第1のアプリケーションAでは、アルゴリズム1の確率が0.3の安定値を有するが、第2のアプリケーションBでは、その平均確率が0.15に低下し、N個すべての場合に対して±0.15の固定された確率ペナルティが導入される。ツールがアプリケーションBでテストされる場合、真の確率は0.15ではなく0.3になり、ツールがアプリケーションBでテストされない場合、真の確率は0になる。言い換えれば、アプリケーションBでは、単一のCCを使用して、実際の決定の確率は、ビットストリームで送信されたときにより高いビットレートをもたらす非最適方法でモデル化される。
【0019】
本発明の手法では、決定の確率のこのような非最適モデル化の欠点は、以下のように克服される。すべての決定に1つの確率モデルを使用する代わりに、2つ(又はそれ以上)の確率モデルをそれぞれ使用する。CABACコンテキストは同じ決定に割り当てられる。N個の事例のそれぞれについて、どの確率モデルを用いるかは、選択指標を用いて選択される。
【0020】
上記の例を再度検討すると、選択指標は、アルゴリズム1及びアルゴリズム2がテストされる決定された部分と、アルゴリズム2のみが第2のアプリケーションBでテストされる残りの部分とを区別するように選択される。言い換えれば、2つの異なる事例はクラスタ化され、選択指標の異なる値によって表される。
【0021】
アプリケーションAにおいて2つの確率モデルでこの選択指標を使用する場合、選択指標は2つの確率モデル間で切り替わるが、いくつかの異なるCCは依然としてツールフラグの統計をモデル化することができる。両方のモデルにおいて、アルゴリズム1によって表されるツールは0.3の確率を有する。これは、1つの確率モデルのみでモデル化された元の場合と同等のモデル化をもたらす。
【0022】
しかしながら、第2のアプリケーションBにおいて2つの確率モデルで前述の選択指標を使用することは、この事例でも最適なモデル化を引き起こす。両方のアルゴリズムが試験されるすべてのN/2の場合の決定された部分について、アルゴリズム1の確率は0.3であり、ベースラインアルゴリズム2のみを試験する残りの部分について、アルゴリズム1の確率は0.0である。両方の確率は、2つの確率モデルにおいて十分に区別された方法で捕捉され、したがって、モデル化ペナルティなしでモデル化をもたらし、その結果、ビットストリームで送信されたときに低いビットレートをもたらす。
【0023】
したがって、本発明の手法の実施形態は、ツール有効化フラグを送信するための追加のCABACコンテキストを導入することに基づく。この追加のコンテキストは、条件が満たされた場合にのみ適用される。そうでない場合、CABACコンテキストは通常通り選択される。一実施形態によれば、条件は、現在のブロックのサイズが、高速エンコーダ探索戦略によってスキップされ得るが、高い符号化効率を必要とするアプリケーションには有益であり得るブロックサイズの所定のサブセットに属することであり得る。別の実施形態によれば、条件は、現在のブロックのアスペクト比が、高速エンコーダ探索戦略によってスキップされ得るが、高い符号化効率を必要とし、ピクチャレベル又はスライスレベルではなくブロックレベルで制御され得るアプリケーションにとって有益であり得る2のような特定の値を上回ることであり得る。
【0024】
一方で、CABACコンテキストの確率適応のために、適用シナリオにおいて、条件によって定義された特定の事例についてツールが決してテストされない場合、これらの事例のツールフラグを送信するためのシグナリングオーバーヘッドは非常に小さくなる。したがって、符号化効率は、これらの事例でツールフラグが送信されない場合とほぼ同じくらい良好である。
【0025】
一方、CABACコンテキストの確率適応のために、異なる適用シナリオで条件によって決定された事例でもツールがエンコーダによってテストされる場合、条件によって決定された事例に個別のCABACコンテキストが使用される場合、ツールフラグを送信するための符号化効率は大幅に低下しない。
【0026】
したがって、最新技術の手法とは対照的に、本発明によって提案されるような異なるCABACコンテキストの割り当ては、ツールフラグの全体的な条件付き確率分布をモデル化しようと試みることによって導かれない。代わりに、上記の例で説明したように、異なるCABACコンテキストの割り当ては、ツールの異なるアプリケーションシナリオに対応する。ここで、各アプリケーションシナリオは、所与のツールの実行が原理的に可能であるが、所与のシナリオにおいてエンコーダによって決してテストされない特定の条件として定義される。
【0027】
特定の条件下でそれぞれのツールとアルゴリズムを除外する理由は様々であり、以下では、条件によって決定される場合のいくつかの実施形態が与えられるが、本発明はこれらの実施形態に限定されない。第1に、除外されるアルゴリズムは、これらの場合には複雑すぎ得る。第2に、アルゴリズムは、例えばハードウェア又はリソースの制限のために、これらの場合には実装されないか、又は実装不可能でさえあり得る。第3に、これらの事例に使用されるアルゴリズムが圧縮性能をわずかにしか改善しないことがあるシナリオがある。第4に、これらの事例に基礎となるアルゴリズムを使用することは、基本的に常に非常に限られた圧縮利益を与え、したがって最大圧縮性能が目標とされる場合にのみ実行可能である。第5に、これらの事例は、それぞれのアルゴリズムのコア応用分野を含まず、ツールは最初に設計されたものである。
ツールのための2つ以上のコンテキスト分割
【0028】
本発明の実施形態はまた、コンテキストの様々なコンテキストへの分割を組み込み、追加のコンテキストの各々は、基礎となるツールの異なる使用事例シナリオに対応する。本明細書の実施形態は、以下の通りであり得る。オリジナル又は従来のツール有効化フラグは、単一のコンテキストによってモデル化される。実施形態によれば、本発明の手法は、代わりに3つのコンテキストを使用し、選択指標は、例えばブロック領域の量子化バージョンによって制御される。ここで、選択指標は、以下のように割り当てられてもよい:
【0029】
0|(block_area>=max_block_area/4)、
SelectionIndex=1|(block_area>=max_block_area/16)AND(block_area<max_block_area/4)、
2|そうでない場合
他の実施形態によれば、本発明の手法は、汎用ビデオ符号化VVC規格のアフィン線形重み付きイントラ予測LWIP、又は行列ベースのイントラ予測MIPを表す構文要素intra_mip_flagの2値化のために4つのコンテキスト又はコンテキストモデルを使用する。選択指標は、現在のブロックのアスペクト比(幅/高さ又は高さ/幅)によって制御される:
0|そうでない場合、
1|そうでない場合、
SelectionIndex=2|そうでない場合、
3|現在のブロックのアスペクト比が2より大きい場合
【0030】
図1は、本発明の実施形態による、画像又はビデオデータを符号化するための装置100を示す。装置100は、エンコーダ102を含む。エンコーダ102は、画像又はビデオデータ104を受信し、受信した画像又はビデオデータ104を符号化して、符号化された画像又はビデオデータを表すビットストリーム106を提供する。エンコーダ102は、CABACエンコーダ108を含む。CABACエンコーダ108は、符号化される画像又はビデオデータの特定のデータブロックに関連付けられたバイナリ値構文要素110を受信し、選択されたコンテキストモデルを使用して、バイナリ値構文要素をビットストリーム用の符号化ビット112に符号化する。バイナリ値構文要素は、画像やビデオデータを符号化する際に、特定の符号化ツールを採用するか否かを示すツールフラグを含む。ツールフラグを符号化するための第1のコンテキストモデルのグループは、アプリケーションとは無関係に、符号化ツールが常に適用可能である特定のデータブロックの1つ又は複数の第1の部分に対して選択される。ツールフラグを符号化するための第2のコンテキストモデルのグループは、アプリケーションに応じて、符号化ツールが適用可能又は適用不可能である特定のデータブロックの1つ又は複数の第2の部分に対して選択される。実施形態によれば、以下にも説明するように、CABACエンコーダ108は、選択指標に応答して、特定のデータブロックの現在処理されている部分に対して第1のコンテキストモデル又は第2のコンテキストモデルを選択する。選択指標は、特定のデータブロックの現在処理されている部分が第1の部分であることを示す第1の値を有し、選択指標は、特定のデータブロックの現在処理されている部分が第2の部分であることを示す第2の値を有する。
【0031】
図2は、本発明の実施形態による、符号化された画像又はビデオデータを復号するための装置200を示す図である。装置200は、デコーダ202を含む。デコーダ202は、
図1のエンコーダ102によって提供されるビットストリームと同様に、ビットストリーム106を受信する。ビットストリーム106は、符号化された画像又はビデオデータを含み、デコーダ202は、受信されたビットストリームから符号化された画像又はビデオデータを復号し、復号された画像又はビデオデータ204を提供する。デコーダは、選択されたコンテキストモデルを使用して、ビットストリーム106から、符号化された画像又はビデオデータの特定のデータブロックに関連付けられたバイナリ値構文要素110を復号するCABACデコーダ206を含む。バイナリ値構文要素は、画像やビデオデータを符号化する際に、特定の符号化ツールを採用するか否かを示すツールフラグを含む。ツールフラグを復号するための第1のコンテキストモデルのグループは、アプリケーションとは無関係に、符号化ツールが常に適用可能である特定のデータブロックの部分に対して選択され、ツールフラグを復号するための第2のコンテキストモデルのグループは、アプリケーションに応じて、符号化ツールが適用可能又は適用不可能である特定のデータブロックの部分に対して選択される。実施形態によれば、以下にも説明するように、CABACデコーダ206は、選択指標に応答して、特定のデータブロックの現在処理されている部分に対して第1のコンテキストモデル又は第2のコンテキストモデルを選択する。選択指標は、特定のデータブロックの現在処理されている部分が第1の部分であることを示す第1の値を有し、選択指標は、特定のデータブロックの現在処理されている部分が第2の部分であることを示す第2の値を有する。
【0032】
実施形態によれば、第1のコンテキストモデルのグループは、1つの第1のコンテキストモデル又は様々な第1のコンテキストモデルを含み、第2のコンテキストモデルのグループは、1つの第2のコンテキストモデル又は様々な第2のコンテキストモデルを含む。
【0033】
元のコンテキスト指標付けとの組み合わせ
前述したように、多くの事例では、ツール有効化フラグは、バイナリ決定が隣接する近隣の既に復号されたシンボルから予測され得る異なる確率を有する可能性が高い場合に、2つ以上のコンテキストモデルによってモデル化される。本発明の手法はまた、そのようなエントロピー駆動コンテキスト選択と本発明の選択指標との組み合わせとして適用することができる。元のエントロピー駆動コンテキスト指標付けも分離後に適切であり得るので、そのような組み合わせの動機は明らかである。
【0034】
ツールフラグのコンテキストモデルがエントロピー駆動コンテキスト選択及び本発明の手法の両方によって選択される実施形態は、以下の通りである。
0|ツールは、現在のブロックの上のブロック又は左のブロックでは使用されない
EntropyIndex=1|ツールは、現在のブロックの上又は左のブロックのうちの1つでのみ使用される
2|ツールは、現在のブロックの上のブロックと左のブロックで使用される
SelectionIndex=0|(block_area>=max_block_area/16)、
1|そうでない場合
CombinedIndex=EntropyIndex+3*SelectionIndex。
【0035】
したがって、この実施形態では、純粋にエントロピー駆動のコンテキスト選択は、所与のツールフラグに対して3つの可能なコンテキストモデルをもたらすが、本発明のコンテキストモデル選択との組み合わせは、指標CombinedIndexによって指標付けされる6つの可能なコンテキストモデルをもたらす。
【0036】
バイパスモード符号化イネーブルフラグの置換
本発明の手法は、バイパスモードを使用して従来のように符号化されているフラグにも適用可能である。そのような場合、使用事例駆動の実装を実現するために、1つ又は2つの追加のコンテキストモデルが必要とされる。1つの追加のコンテキストモデルのみが使用される場合、選択指標は、事例の影響を受けていない部分を符号化するためのバイパスモードの使用と、ツールをオン及びオフに切り替えることができる他のすべての事例のための1つのコンテキストモデルの使用とを区別する。
【0037】
2つのコンテキストモデルが使用される場合、バイパスモードはコンテキストモデル化算術符号化によって完全に置き換えられ、選択指標は2つのコンテキストモデルを区別する。近い将来のVVC規格における改善された更新技術により、事例の切り替え不可能な部分をモデル化する1つのコンテキストは、準定常モデルを達成するために小さい更新強度で更新され得ることに留意されたい。
【0038】
事例の切り替え可能な部分をモデル化する追加のモデルは、ツールオン確率又はツールオフ確率のいずれかに対するコンテキストモデルの迅速な適応を達成するために、非常に強力な更新強度で確かに使用されることにも留意されたい。
【0039】
パラメータセットにおける部分的なツール有効化をシグナリングする代替方法
前述の部分的なツール有効化動作は、例えば各スライスについて、1つ又は複数のフレームの所定の部分ごとにビットストリームでシグナリングされるパラメータセットでシグナリングすることもできる。この場合、パラメータセットから送信されたフラグはすべての必要な情報を含むため、コンテキスト分離は必要とされない。しかしながら、使用事例駆動コンテキストモデル選択と比較したこの種のシグナリングの欠点は、前者の場合、パラメータセットが適用されるビデオシーケンスのすべての部分を通して、ツールは、適用シナリオに対応する事例にのみ完全に有効又は無効にされ得るだけであるが、後者の場合、デコーダに知られている、それぞれ事前に決定される必要のないビデオシーケンスの任意の可変部分内で無効にされ得ることもできることである。その理由は、後者の場合、ツールフラグ用の特別なコンテキストモデルが、特定のアプリケーションシナリオについてツールを無効にすることが時として実現可能であるすべての事例に割り当てられている場合、順次符号化のいずれかから始めると、特定のアプリケーションシナリオに対応するエンコーダは、ビデオシーケンスのこの特定の部分のアプリケーションシナリオに対応するすべての事例についてツールが完全に禁止される状況と比較して、わずかなシグナルオーバーヘッドのみを伴う順次符号化の柔軟なポイントまで、対応する事例についてツールをテストすることができないからである。
【0040】
任意の符号化ツールを用いたアプリケーション
本発明のコンテキスト分割は、有効化フラグによって制御される任意の符号化ツールに適用することができる。本発明の手法で使用することができる将来のVVC規格で発生する現在の候補ツールを以下に列挙する。しかしながら、本発明の手法の適用はこれらのツールに限定されない。候補ツールは、DMVR、OBMC、BIO、FRUC、LIC、ISP、ALF、SAO、インター又はイントラMTS、65方向性イントラモード、MRL、及びQTBT、MTT又はQTBT+TTのような分割ツールである。
【0041】
本発明の手法は、指標値によって表される異なる構成を有するツールにも適用することができる。ここで、本発明のCC割り当ては、いくつかのアプリケーションシナリオでは、ツールのすべての構成のサブセットのみが、特定の場合、又は一般に実現可能であるという事実によって決定される。本発明のCC割り当ては、シナリオに対してツールが実行不可能な構成に追加のCCを割り当てることによって、これらの異なるアプリケーションシナリオを考慮する。本発明のこの態様の一実施形態は、予測残差の逆変換のためにn個の変換のうちの1つを適用するツールであり、変換の指標はビットストリームで送信される。
【0042】
本発明の手法を利用すると、ツールの多くは、特定の状況下でのみいくつかのコンテキスト分割可能ツールを備えることができる。ここで、本発明によるコンテキスト分割は、特定のアプリケーションシナリオにおいて特定のツールが実行不可能であり得る特定の事例に従う。これらの具体的な事例は、ツールの重要な特性に依存する。本発明の使用事例に限定されない特定の状況に対して評価又は組み合わせることができる特性のリストは、ブロックサイズ、ブロック形状、ブロックアスペクト比、時間レベル、QP、ピクチャタイプ、ピクチャ解像度、ピクチャのダイナミックレンジ、参照ピクチャ、GOPの先頭ピクチャである。
特定の状況は、これらの前述の特性の組み合わせであってもよい。
【0043】
コンテキスト割り当ての本発明の手法の適用の実施形態
アフィン線形重み付きイントラ予測(LWIP)[4]は、新たなイントラ予測技術である。従来のイントラ予測と同様に、LWIPは予測モードのセットからなる。左及び上の再構築(参照)サンプルを考えると、シグナリングされた予測モードの各々は、異なる予測信号を生成する予測関数に対応する。
【0044】
利用可能な従来モードとLWIPモードの両方で、エンコーダは従来モードとLWIPモードのレート-歪みコストを比較し、全体コストが最も低いモードを決定する。次に、選択された予測モードはビットストリーム内のデコーダに送信され、ブロックを予測するための対応する予測関数を選択するために使用される。予測モードをシグナリングする構文は以下の通りである:まず、ブロックが従来モードで予測されるかLWIPモードで予測されるかを示すフラグが送信される。従来の予測が選択される場合、従来の予測モードがイントラ予測信号に従ってビットストリームから読み出される。そうではなく、LWIP予測が選択された場合、フラグの後に、利用可能なLWIPモードのセット内のモード指標が送信される。従来のモードとLWIPモードの両方が、イントラ予測のためにコーデックによって一般にサポートされるすべてのブロックサイズに対して利用可能であるため、フラグはブロックごとに送信されなければならない。
【0045】
VVC符号化規格は、現在、範囲
内のルーマブロックサイズのイントラ予測をサポートする。明らかに、すべての異なるブロックサイズのレート歪みコスト(より大きいブロックをより小さいブロックに分割することから生じる)がすべての異なる予測モードについて評価されるので、レート歪み最適化(RDO)を用いたエンコーダ探索は非常に複雑になる可能性がある。エンコーダの複雑さを低減するために、最適化は、典型的には、最低レート歪みコストをもたらす統計的に可能性が低い場合を除いて、テストされる組み合わせの数を低減する。
【0046】
LWIPのコア予測は、
を有する正方形ブロックのみをサポートする。他のすべてのブロックサイズのLWIP予測を有効にするために、参照サンプルはコア予測サイズと一致するようにダウンサンプリングされ、出力はブロックサイズと一致するようにアップサンプリングされる。これは、水平方向及び垂直方向についてダウンサンプリング比及びアップサンプリング比が非常に不均等なブロック形状に対して予測品質が低下するという影響を有する。これは、アスペクト比が2より大きいブロック、すなわち、
又は
は、LWIPモードが従来の予測モードよりも低いレート歪みコストをもたらす可能性が低いことを意味する。
【0047】
この効果を使用して、アスペクト比が2以下のブロックにLWIPモードを制限し、アスペクト比がより高いブロックについてはテストしないことにより、エンコーダの複雑さを低減することができる。ただし、これにより、符号化効率も多少低下する。アスペクト比が2より大きいブロックのフラグを送信しないと、符号化効率の損失を低減するが、異なるアプリケーションに必要とされ得るアスペクト比が2より大きいブロックのLWIPモードをテストすることによって全体的な符号化効率を向上させるエンコーダを実現することも不可能になる。
【0048】
高速及び高圧縮効率のエンコーダの両方をサポートする解決策は、2より大きいアスペクト比を有するブロックのフラグを送信するための個別の追加のCABACコンテキストを導入することである。ここで、LWIPモードがそれらのブロックについてエンコーダでテストされない場合、フラグは常に0であり(=LWIPモードで予測されないブロック)、フラグを送信することはほとんどオーバーヘッドを引き起こさず(1を送信するためにコンテキストを0確率に適応させるためだけ)、これは、符号化効率がそれらのブロックのフラグを送信しない解決策に非常に近いことを意味する。LWIPブロックがそれらのブロックについてエンコーダでテストされる場合、フラグは特定の確率で1であり(=ブロックはLWIPモードで予測される)、フラグを送信することはほとんどオーバーヘッドを引き起こさず、これは、符号化効率がすべてのブロックサイズについて同じコンテキストでフラグを送信する解決策に非常に近いことを意味する。
【0049】
言い換えれば、上述したように、実施形態によれば、本発明の手法は、汎用ビデオ符号化VVC規格のアフィン線形重み付きイントラ予測LWIP又は行列ベースのイントラ予測MIPを表す構文要素intra_mip_flagの2値化のために4つのコンテキスト又はコンテキストモデルを使用する。選択指標は、現在のブロックのアスペクト比(幅/高さ又は高さ/幅)によって制御される:
0|そうでない場合、
1|そうでない場合、
SelectionIndex=2|そうでない場合、
3|現在のブロックのアスペクト比が2より大きい場合
【0050】
図3は、2より大きいアスペクト比を有するブロックのフラグを送信するための個々の追加のCABACコンテキストを導入する、本発明の実施形態による画像又はビデオデータを符号化するための装置、例えば
図1の装置と同様の装置を示す図である。エンコーダ102は、画像又はビデオデータ104を受信し、受信した画像又はビデオデータ104を符号化して、符号化された画像又はビデオデータを表すビットストリーム106を提供する。CABACエンコーダ108は、画像又はビデオデータのブロックを符号化するときにアフィン線形重み付きイントラ予測、LWIPのような特定の符号化ツールが用いられるかどうかを示すツールフラグ110を受け取る。アフィン線形重み付きイントラ予測LWIPは、汎用ビデオ符号化VVC規格において、行列ベースのイントラ予測MIPとも呼ばれ、ツールフラグは、VVC規格のアフィンLWIP又はMIPの適用可能性を示すintra_mip_flagとも呼ばれる。2より大きいアスペクト比を有し、特定の符号化ツールが適用可能な画像又はビデオデータのブロック300について、ツールフラグを符号化するための第1のコンテキストモデルが、1つ又は複数の第1のコンテキストモデルのグループから選択され、CABAC 108に提供される。2以下のアスペクト比を有し、特定の符号化ツールが適用可能な画像又はビデオデータのブロック302について、ツールフラグを符号化するための第2のコンテキストモデルが、1つ又は複数の第2のコンテキストモデルのグループから選択され、CABAC 108に提供される。例えば、アスペクト比が2より大きいブロック300についてLWIPモードがテストされない場合、フラグは常に0であり、追加のCABACコンテキストは1を送信する確率がゼロになるように適応し、アスペクト比が2より大きいブロック300についてLWIPモードがテストされる場合、フラグは一定の確率で1である。実施形態によれば、CABACエンコーダ108は、選択指標に応答して、現在処理されているブロックの第一コンテキストモデル及び第二コンテキストモデルを選択することができる。選択指標は、現在処理されているブロックのアスペクト比が2より大きいか、又はアスペクト比が2以下であることを示す。
【0051】
図4は、
図3の装置を使用して符号化された、2より大きいアスペクト比を有するブロックのフラグのための個々の追加のCABACコンテキストを導入する、本発明の実施形態による画像又はビデオデータを復号するための装置、例えば
図2の装置と同様の装置100を示す図である。2より大きいアスペクト比を有し、特定の符号化ツールが適用可能な画像又はビデオデータのブロック300について、ツールフラグを符号化するための第1のコンテキストモデルが、1つ又は複数の第1のコンテキストモデルのグループから選択され、CABAC206に提供される。2以下のアスペクト比を有し、特定の符号化ツールが適用可能な画像又はビデオデータのブロック302について、ツールフラグを符号化するための第2のコンテキストモデルが、1つ又は複数の第2のコンテキストモデルのグループから選択され、CABAC206に提供される。
【0052】
例えば、構文要素intra_mip_flagの2値化は、以下のようにコンテキスト指標{0,1,2,3}を有する合計4つのコンテキストモデルを使用することができる:
現在のブロックのアスペクト比(幅/高さ又は高さ/幅)が2より大きい場合、指標3を有するコンテキストモデルを使用し、
【0053】
そうでなければ、コンテキストモデル0、1、2のうちの1つを使用し、選択は、例えば、いくつかの他の構文要素について知られて使用されるように、現在のブロックの左及び上のブロックのintra_mip_flagに依存し得る。
【0054】
VVC仕様では、符号化ユニット構文は以下の通りであり得る(例えば、[5]の7.3.10.5-符号化ユニット構文を参照):
【表1】
【0055】
1に等しいintra_mip_flag[x0][y0]は、ルーマサンプルのイントラ予測タイプが行列ベースのイントラ予測であることを指定する。0に等しいintra_mip_flag[x0][y0]は、ルーマサンプルのイントラ予測タイプが行列ベースのイントラ予測ではないことを指定する(例えば、[5]の7.4.11.5-符号化ユニットセマンティクスを参照)。
【0056】
構文要素intra_mip_flagの2値化は、以下のようにすることができる(例えば、[5]の9.3.4.2を参照されたい-ctxTable、ctxIdx、及びbypassFlagの導出プロセス):
【0057】
【0058】
説明された概念のいくつかの態様は、装置の文脈で説明されているが、これらの態様は、対応する方法の説明も表しており、ブロック又は装置は、方法ステップ又は方法ステップの特徴に対応することは明らかである。同様に、方法ステップの文脈で説明される態様は、対応するブロック又は対応する装置のアイテム又は特徴の記述も表す。
【0059】
本発明の様々な要素及び特徴は、アナログ及び/又はデジタル回路を使用するハードウェア、ソフトウェア、1つ又は複数の汎用又は専用プロセッサによる命令の実行を通じて、又はハードウェアとソフトウェアの組み合わせとして実装されてもよい。例えば、本発明の実施形態は、コンピュータシステム又は別の処理システムの環境で実施することができる。
図5は、コンピュータシステム400の一例を示す。ユニット又はモジュール、並びにこれらのユニットによって実行される方法のステップは、1つ又は複数のコンピュータシステム400上で実行することができる。コンピュータシステム400は、専用又は汎用デジタル信号プロセッサのような、1つ又は複数のプロセッサ402を含む。プロセッサ402は、バス又はネットワークのような通信インフラストラクチャ404に接続される。コンピュータシステム400は、例えばランダムアクセスメモリ(RAM)などのメインメモリ406と、例えばハードディスクドライブ及び/又はリムーバブルストレージドライブなどのセカンダリメモリ408とを含む。セカンダリメモリ408は、コンピュータプログラム又は他の命令がコンピュータシステム400にロードされることを可能にすることができる。コンピュータシステム400は、ソフトウェア及びデータが、コンピュータシステム400と外部デバイスとの間で転送されることを可能にする通信インタフェース410を更に含むことができる。通信は、電子信号、電磁信号、光学信号、又は通信インタフェースによって処理することができる他の信号からのものであってもよい。通信は、ワイヤ又はケーブル、光ファイバ、電話回線、携帯電話リンク、RFリンク、及び他の通信チャネル412を使用することができる。
【0060】
「コンピュータプログラム媒体」及び「コンピュータ可読媒体」という用語は、一般に、リムーバブルストレージユニット又はハードディスクドライブにインストールされたハードディスクなどの有形の記憶媒体を指すために使用される。これらのコンピュータプログラム製品は、コンピュータシステム400にソフトウェアを提供するための手段である。コンピュータ制御ロジックとも呼ばれるコンピュータプログラムは、メインメモリ406及び/又はセカンダリメモリ408に格納される。コンピュータプログラムはまた、通信インタフェース410を介して受信されてもよい。コンピュータプログラムは、実行されると、コンピュータシステム400が本発明を実施することを可能にする。特に、コンピュータプログラムは、実行されると、プロセッサ402が本明細書に記載の方法のいずれかなどの本発明のプロセスを実施することを可能にする。したがって、そのようなコンピュータプログラムは、コンピュータシステム400のコントローラを表すことができる。本開示がソフトウェアを使用して実施される場合、ソフトウェアは、コンピュータプログラム製品に格納され、リムーバブルストレージドライブ、通信インタフェース410のようなインタフェースを使用してコンピュータシステム400にロードされ得る。
【0061】
ハードウェア又はソフトウェアの実施形態は、中に格納される電子的に読み取り可能な制御信号を有し、各方法が実行されるようにプログラム可能なコンピュータシステムと協働する(又は協働可能な)、例えばクラウドストレージ、フロッピーディスク、DVD、ブルーレイ、CD、ROM、PROM、EPROM、EEPROM又はフラッシュメモリなどのデジタル記憶媒体を使用して実行することができる。したがって、デジタル記憶媒体はコンピュータ可読であってもよい。
【0062】
本発明によるいくつかの実施形態は、プログラム可能なコンピュータシステムと協働して、本明細書に記載の方法の1つが実行されるような、電子的に読み取り可能な制御信号を有するデータキャリアを備える。
【0063】
一般に、本発明の実施形態は、コンピュータプログラム製品がコンピュータ上で動作するときに、本方法の1つを実行するように動作するプログラムコードを有するコンピュータプログラム製品として実施し得る。プログラムコードは、例えば、機械読み取り可能なキャリアに格納することができる。
【0064】
他の実施形態は、本明細書に記載の方法の1つを実行するためのコンピュータプログラムを含み、機械読み取り可能なキャリアに格納される。換言すれば、本発明の方法の実施形態は、コンピュータプログラムがコンピュータ上で実行されるときに、本明細書に記載の方法の1つを実行するためのプログラムコードを有するコンピュータプログラムである。
【0065】
したがって、本発明の方法の更なる実施形態は、本明細書に記載の方法のうちの1つを実行するためのコンピュータプログラムを含み、そこに記録される、データキャリア(又はデジタル記憶媒体又はコンピュータ可読媒体)である。したがって、本発明の方法の更なる実施形態は、本明細書に記載の方法のうちの1つを実行するためのコンピュータプログラムを表すデータストリーム又は信号のシーケンスである。データストリーム又は信号のシーケンスは、例えば、データ通信接続、例えばインターネットを介して転送されるように構成することができる。更なる実施形態は、本明細書に記載の方法のうちの1つを実行するように構成された、又は適用される処理手段、例えばコンピュータ又はプログラマブル論理装置を含む。更なる実施形態は、本明細書で説明される方法の1つを実行するためのコンピュータプログラムがインストールされたコンピュータを含む。
【0066】
いくつかの実施形態では、プログラマブルロジック装置(例えば、フィールドプログラマブルゲートアレイ)を使用して、本明細書に記載の方法の機能の一部又は全部を実行することができる。いくつかの実施形態では、フィールドプログラマブルゲートアレイは、本明細書で説明する方法の1つを実行するためにマイクロ処理部と協働することができる。一般に、これらの方法は、好ましくは、任意のハードウェア装置によって実行される。
【0067】
上述の実施形態は、本発明の原理の単なる例示である。本明細書に記載された構成及び詳細の修正及び変形は、他の当業者には明らかであることが理解される。したがって、差し迫った特許請求の範囲によってのみ限定され、本明細書の実施形態の記載及び説明によって示される特定の詳細によっては限定されないことが意図される。
【0068】
参考文献
[1] ISO/IEC, ITU-T. High efficiency video coding. ITU-T Recommendation H.265 | ISO/IEC 23008 10 (HEVC), edition 1, 2013; edition 2, 2014.
【0069】
[2] JEM reference software, https://jvet.hhi.fraunhofer.de/svn/svn_HMJEMSoftware/.
【0070】
[3] B. Bross, J. Chen, Shan Liu, “Versatile Video Coding (Draft 4)”, JVET-M1001-v5, February 2019, Marrakesh, Morocco
【0071】
[4] J. Pfaff, B. Stallenberger, M. Schaefer, P. Merkle, P. Helle, R. Rische, H. Schwarz, D. Marpe, T. Wiegand, “Affine Linear Weighted Intra Prediction”, JVET-M0043, February 2019, Marrakesh, Morocco
【0072】
[5] B. Bross, J. Chen, Shan Liu, “Versatile Video Coding (Draft 8)”, JVET-Q2001-vD, February 2020, Brussels, Belgium