JP7266710B2 - ビデオコーディングのための方法、装置、およびコンピュータプログラム - Google Patents

Description

関連出願への相互参照
本出願は、2020年6月10日に出願された米国仮特許出願第63／037，170号および2021年5月13日に出願された米国特許出願第17／319，328号に基づく優先権を主張し、これらの出願は、その全体が参照により本明細書に明示的に組み込まれる。

本開示は、適応色変換（adaptive color transform：ACT）モードを用いたコーディングブロックのコーディングユニット（coding unit：CU）レベルの有効化フラグおよび変換ユニット（transform unit：TU）レベルのルマコーディングフラグのシグナリングに関する。

ITU－T VCEG（Q6／16）およびISO／IEC MPEG（JTC1／SC29／WG 11）は、2013（バージョン1）2014（バージョン2）2015（バージョン3）および2016（バージョン4）において、H．265／HEVC（High Efficiency Video Coding）規格を公開した。2015年、これら2つの標準化団体は、HEVCを超える次のビデオコーディング規格を開発する可能性を探るべく、共同でJVET（ジョイント・ビデオ・エクスポレーション・チーム）を作った。2017年10月、彼らは、HEVCを超える能力を有するビデオ圧縮についての共同提案募集（Joint Call for Proposals on Video Compression with Capability beyond HEVC（CfP））を発行した。2018年2月15日までに、標準ダイナミックレンジ（standard dynamic range：SDR）についての合計22件のCfP応答、ハイダイナミックレンジ（high dynamic range：HDR）についての12件のCfP応答、および360個のビデオカテゴリについての12件のCfP応答がそれぞれ提出された。2018年4月、すべての受領されたCfP応答は、122 MPEG／10th JVET会議において評価された。この会議の結果、JVETは、HEVCを超える次世代ビデオコーディングの標準化プロセスを正式に立ち上げた。この新たな規格は、多用途ビデオコーディング（Versatile Video Coding：VVC）と名付けられ、JVETは、ジョイント・ビデオ・エキスパート・チーム（Joint Video Expert Team）と名付けられた。

しかしながら、コーディングされたCUブロックが係数を有していない場合、ACTモードシグナリングは冗長であり得るか、またはACTモードを有するCUは、コーディングされたCUブロック内に1つまたは複数の係数を有する必要があるなどの技術的問題がある。ACTモードを有するインターブロックの場合、CUが変換ユニット内に少なくとも1つの係数を有することを表すためにcu＿coded＿flagが1でなければならない場合、ACTモードを有するイントラCUに対応する制約はなく、色差チャネルのTUコード化フラグが両方とも0である場合、ACTモードを有するイントラブロックのみが1と推測されるべきである。また、cu＿act＿enabled＿flagは、現在のCUブロックの異なる予測モードに基づいて2回シグナリングされるべきである。したがって、例えば、そのような問題に対する技術的解決策が本明細書に記載されている。

例示的な実施形態によれば、コンピュータプログラムコードを記憶するように構成されたメモリと、コンピュータプログラムコードにアクセスし、コンピュータプログラムコードの指示に従って動作するように構成された1つまたは複数のプロセッサとを含む方法および装置が含まれる。コンピュータプログラムコードは、少なくとも1つのプロセッサにビデオデータを取得させるように構成された第1の取得コードと、少なくとも1つのプロセッサにビデオデータのコーディングユニット（CU）ブロックを取得させるように構成された第2の取得コードと、少なくとも1つのプロセッサに、CUブロックのフラグが所定のフラグ条件に設定されているか否かを判定させるように構成された第1の判定コードと、少なくとも1つのプロセッサに、CUブロックのツリータイプが所定のツリータイプに設定されているか否かを判定させるように構成された第2の判定コードと、CUブロックのフラグが所定のフラグ条件に設定されているか否か、およびCUブロックのツリータイプが所定のツリータイプに設定されているか否かのいずれかに基づいて、少なくとも1つのプロセッサに適応色変換（ACT）フラグをシグナリングするか否かを判定させるように構成された第3の判定コードと、ACTフラグがシグナリングされるか否かに基づいて、少なくとも1つのプロセッサにビデオデータをコーディングさせるように構成されたコーディングコードと、が含まれる。

例示的な実施形態によれば、ACTフラグをシグナリングするか否かの判定は、CUブロックのフラグが所定のフラグ条件に設定されているか否かのみに基づく。

例示的な実施形態によれば、ACTフラグをシグナリングするか否かを判定することは、CUブロックのフラグが所定のフラグ条件に設定されているか否か、およびCUブロックのツリータイプが所定のツリータイプに設定されているか否かの両方に基づく。

例示的な実施形態によれば、所定のツリータイプは、デュアルツリータイプではなくシングルツリータイプを示す。

例示的な実施形態によれば、適応色変換（ACT）フラグをシグナリングするか否かの判定は、CUの予測モードがイントラモードであるか否かにかかわらず実施される。

例示的な実施形態によれば、コンピュータプログラムコードは、少なくとも1つのプロセッサに、変換ユニット（TU）コーディングフラグが両方とも0であるか否か、およびCUがACTモードでコーディングされているか否かを判定させるように構成された第4の判定コードをさらに含む。

例示的な実施形態によれば、TUコーディングフラグは、色差チャネルのフラグである。

例示的な実施形態によれば、コンピュータプログラムコードは、少なくとも1つのプロセッサに、TUコード化フラグが両方とも0であること、およびCUがACTモードでコード化されていることの判定に基づいて、輝度のTUコード化フラグが1であると推測されるべきか否かを判定させるように構成された第5の判定コードをさらに含む。

例示的な実施形態によれば、輝度のTUコーディングフラグが1であると推測されるべきであると判定することは、CUの予測モードがイントラモードであるか否かにかかわらず実施される。

例示的な実施形態によれば、ビデオデータをコーディングすることは、輝度のTUコーディングフラグが1であると推測されるべきか否かを判定することにさらに基づく。

開示された主題のさらなる特徴、性質、および様々な利点は、以下の詳細な説明および添付の図面からより明らかになるであろう。

実施形態による概略図の簡略図である。 実施形態による概略図の簡略図である。 実施形態による概略図の簡略図である。 実施形態による概略図の簡略図である。 実施形態による図の簡略図である。 実施形態による図の簡略図である。 実施形態による図の簡略図である。 実施形態による図の簡略図である。 実施形態による図の簡略図である。 実施形態による図の簡略図である。 実施形態によるフローチャートの簡略図である。 実施形態によるフローチャートの簡略図である。 実施形態によるフローチャートの簡略図である。 実施形態による図の簡略図である。 実施形態による図の簡略図である。 実施形態による概略図の簡略図である。

以下で説明する提案された特徴は、別々に使用されてもよいし、任意の順序で組み合わされてもよい。さらに、実施形態は、処理回路（例えば、1つもしくは複数のプロセッサまたは1つもしくは複数の集積回路）によって実装され得る。一例では、1つまたは複数のプロセッサは、非一時的コンピュータ可読媒体に記憶されたプログラムを実行する。

図1は、本開示の一実施形態による通信システム100の簡略ブロック図を示す。通信システム100は、ネットワーク105を介して相互接続された少なくとも2つの端末102、103を含み得る。データの一方向送信の場合、第1の端末103は、ネットワーク105を介して他の端末102に送信するために、ローカル位置でビデオデータをコーディングすることができる。第2の端末102は、ネットワーク105から他の端末のコーディングされたビデオデータを受信し、コーディングされたデータをデコードし、復元されたビデオデータを表示することができる。単方向データ伝送は、メディアサービングアプリケーションなどにおいて一般的であり得る。

図1は、例えば、ビデオ会議中に発生する可能性があるコーディングされたビデオの双方向送信をサポートするために提供される第2の対の端末101、104を示す。データの双方向送信の場合、各端末101、104は、ネットワーク105を介して他の端末に送信するために、ローカル位置でキャプチャされたビデオデータをコーディングすることができる。各端末101、104はまた、他の端末によって送信されたコーディングされたビデオデータを受信し、コーディングされたデータをデコードし、復元されたビデオデータをローカルディスプレイ装置に表示し得る。

図1の例では、端末101、102、103、および104は、サーバ、パーソナルコンピュータおよびスマートフォンとして示され得るが、本開示の原理はそのように限定されない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤおよび／または専用ビデオ会議機器に適用される。ネットワーク105は、例えば有線および／または無線通信ネットワークを含む、端末101、102、103、および104間でコーディングされたビデオデータを伝達する任意の数のネットワークを表す。通信ネットワーク105は、回路交換チャネルおよび／またはパケット交換チャネルでデータを交換することができる。代表的なネットワークには、電気通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワークおよび／またはインターネットが含まれる。本説明の目的のために、ネットワーク105のアーキテクチャおよびトポロジは、本明細書で以下に説明されない限り、本開示の動作に重要ではない場合がある。

図2は、開示された主題のためのアプリケーションの例として、ストリーミング環境におけるビデオエンコーダおよびデコーダの配置を示す。開示された主題は、例えば、ビデオ会議、デジタルTV、CD、DVD、メモリスティックなどを含むデジタル媒体への圧縮ビデオの格納などを含む、他のビデオ対応アプリケーションにも等しく適用可能であり得る。

ストリーミングシステム200は、例えば非圧縮のビデオサンプルストリーム213を作成する、例えばデジタルカメラなどのビデオソース201を含み得るキャプチャサブシステム203を含み得る。そのサンプルストリーム213は、コーディングされたビデオビットストリームと比較したときに大量のデータを強調するために太線で示されてもよく、カメラ201に結合されたエンコーダ202によって処理することができる。エンコーダ202は、以下でより詳細に説明されるように、開示された主題の態様を有効化するまたは実装するためのハードウェア、ソフトウェア、またはそれらの組み合わせを含み得る。サンプルストリームと比較してデータ量が少ないことを強調され得るコーディングされたビデオビットストリーム204は、将来の使用のためにストリーミングサーバ205に格納され得る。1つまたは複数のストリーミングクライアント212、207は、ストリーミングサーバ205にアクセスして、コーディングされたビデオビットストリーム204の複製208、206を探索することができる。クライアント212は、コーディングされたビデオビットストリーム208の着信複製をデコードし、ディスプレイ209または他のレンダリング装置（描かれていない）上でレンダリングすることができる発信ビデオサンプルストリーム210を作成するビデオデコーダ211を含むことができる。一部のストリーミングシステムでは、ビデオビットストリーム204、206、および208を特定のビデオコーディング／圧縮規格に従ってコーディングできる。これらの標準の例は、上記で言及され、本明細書でさらに説明される。

図3は、本発明の実施形態によるビデオデコーダ300の機能ブロック図であり得る。

受信器302は、デコーダ300によってデコードされる1つまたは複数のコーデックビデオシーケンスを受信することができ、同じまたは別の実施形態では、一度に1つのコーディングされたビデオシーケンスであり、各コーディングされたビデオシーケンスのデコードは、他のコーディングされたビデオシーケンスから独立している。コーディングされたビデオシーケンスは、コーディングビデオデータを記憶する記憶装置へのハードウェア／ソフトウェアリンクであり得るチャネル301から受信され得る。受信器302は、エンティティ（図示せず）を使用してそれぞれに転送され得る他のデータ、例えば、コーディングされた音声データおよび／または補助データストリームを有するコーディングビデオデータを受信することができる。受信器302は、コーディングされたビデオシーケンスを他のデータから分離することができる。ネットワークジッタに対抗するために、受信器302とエントロピーデコーダ／パーサ304（以降、「パーサ」）との間にバッファメモリ303が結合され得る。受信器302が十分な帯域幅および制御性を有するストア／フォワード装置から、または等同期ネットワークからデータを受信している場合、バッファ303は必要ないか、小さくてもよい。インターネットなどのベストエフォートパケットネットワークで使用するために、バッファ303が必要とされる場合があり、比較的大きくすることができ、有利に適応サイズにすることができる。

ビデオデコーダ300は、エントロピーコーディングされたビデオシーケンスからシンボル313を再構築するためのパーサ304を含み得る。これらのシンボルのカテゴリには、デコーダ300の動作を管理するために使用される情報、およびデコーダの不可欠な部分ではないがそれに結合することができるディスプレイ312などのレンダリング装置を制御するための潜在的な情報が含まれる。レンダリング装置の制御情報は、補足拡張情報（SEIメッセージ）またはビデオユーザビリティ情報パラメータセットフラグメント（図示せず）の形であり得る。パーサ304は、受信されたコーディングされたビデオシーケンスを解析／エントロピーデコードすることができる。コーディングされたビデオシーケンスのコーディングは、ビデオコーディング技術またはビデオコーディング規格に従うことができ、可変長コーディング、ハフマンコーディング、文脈依存性の有無にかかわらず算術コーディングなどを含む、当業者に周知の原理に従い得る。パーサ304は、グループに対応する少なくとも1つのパラメータに基づいて、ビデオデコーダ内の画素のサブグループのうちの少なくとも1つのサブグループパラメータの組を、コーディングされたビデオシーケンスから抽出することができる。サブグループは、Groups of Pictures（GOP）、ピクチャ、タイル、スライス、マクロブロック、コーディングユニット（CU）、ブロック、変換ユニット（TU）、予測ユニット（PU）などを含むことができる。エントロピーデコーダ／パーサはまた、変換係数、量子化器パラメータ値、動きベクトルなどのようなコーディングされたビデオシーケンス情報から抽出することができる。

パーサ304は、シンボル313を作成するために、バッファ303から受信されたビデオシーケンスに対してエントロピーデコード／パース操作を行うことができる。パーサ304は、コーディングされたデータを受信し、特定のシンボル313を選択的にデコードすることができる。さらに、パーサ304は、特定のシンボル313が、動き補償予測ユニット306、スケーラ／逆変換ユニット305、イントラ予測ユニット307、またはループフィルタ311に提供されるべきか否かを判定し得る。

シンボル313の再構築は、コーディングされたビデオピクチャまたはその一部（例えば、インターピクチャおよびイントラピクチャ、インターブロックおよびイントラブロック）の形式、およびその他の要因に依存して、複数の異なるユニットが関与しうる。どのユニットがどのように関与するかは、パーサ304によってコーディングされたビデオシーケンスから解析されたサブグループ制御情報によって制御され得る。パーサ304と以下の複数のユニットとの間のそのようなサブグループ制御情報のフローは、明確性のために示されていない。

すでに述べた機能ブロックの他に、デコーダ300は、概念的には、以下で説明するように、いくつかの機能ユニットに細分化され得る。商業的制約の下で動作する実際の実装では、これらのユニットの多くは互いに密接に相互作用し、少なくとも部分的に互いに統合することができる。しかしながら、開示された主題を説明する目的で、以下の機能ユニットへの概念的細分化が適切である。

第1のユニットはスケーラ／逆変換ユニット305である。スケーラ／逆変換ユニット305は、使用する変換、ブロックサイズ、量子化係数、量子化スケーリング行列などを含む制御情報と同様に、量子化された変換係数をパーサ304からシンボル313として受け取る。これは、アグリゲータ310に入力されうるサンプル値を含むブロックを出力しうる。

場合によっては、スケーラ／逆変換305の出力サンプルは、イントラコーディングされたブロックに関連し得る。すなわち、以前に再構築されたピクチャからの予測情報を使用していないが、現在ピクチャの以前に再構築された部分からの予測情報を使用することができるブロックである。そのような予測情報は、イントラピクチャ予測ユニット307によって提供することができる。場合によっては、イントラピクチャ予測ユニット307は、現在（部分的に再構築された）ピクチャ309からフェッチされた周囲のすでに再構成された情報を使用して、再構成中のブロックと同じサイズおよび形状のブロックを生成する。アグリゲータ310は、場合によっては、イントラ予測ユニット307が生成した予測情報を、スケーラ／逆変換ユニット305からの出力サンプル情報に、サンプル単位で付加する。

他の場合には、スケーラ／逆変換ユニット305の出力サンプルは、インターコーディングされた、潜在的に動き補償されたブロックに関連し得る。そのような場合、動き補償予測ユニット306は、参照ピクチャメモリ308にアクセスして、予測に使用されるサンプルをフェッチすることができる。フェッチされたサンプルをブロックに関連するシンボル313に従って動き補償した後、これらのサンプルは、出力サンプル情報を生成するために、アグリゲータ310によってスケーラ／逆変換ユニットの出力に追加され得る（この場合、残差サンプルまたは残差信号と呼ばれる）。動き補償ユニットが予測サンプルをフェッチする参照ピクチャメモリ内のアドレスは、例えば、X、Y、および参照ピクチャ構成要素を有し得るシンボル313の形で動き補償ユニットが利用できる動きベクトルによって制御され得る。動き補償はまた、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリからフェッチされたサンプル値の補間、動きベクトル予測メカニズムなどをも含み得る。

アグリゲータ310の出力サンプルは、ループフィルタユニット311における様々なループフィルタ処理技術を受けうる。ビデオ圧縮技術には、コーディングされたビデオビットストリームに含まれるパラメータによって制御され、パーサ304からのシンボル313としてループフィルタユニット311で利用できるループ内フィルタ技術を含めることができるが、コーディングされたピクチャまたはコーディングされたビデオシーケンスの以前の（デコード順で）部分のデコード中に取得されたメタ情報に応答したり、以前に再構築およびループフィルタされたサンプル値に応答したりすることもできる。

ループフィルタユニット311の出力は、レンダリング装置312へ出力されうると共に、将来のピクチャ間予測に使用するために参照ピクチャメモリ557に格納されうるサンプルストリームとすることができる。

あるコーディングピクチャは、完全に再構築されると、将来の予測のための参照ピクチャとして使用されうる。コーディングされたピクチャが完全に再構築され、コーディングされたピクチャが（例えば、パーサ304によって）参照ピクチャとして識別されると、現在の参照ピクチャ309は参照ピクチャバッファ308の一部になり得、次のコーディングされたピクチャの再構成を開始する前に、新鮮な現在のピクチャメモリが再割り当てされうる。

ビデオデコーダ300は、ITU－T Rec．H．265などの規格に文書化され得る所定のビデオ圧縮技術に従ってデコード動作を行うことができる。コーディングされたビデオシーケンスは、ビデオ圧縮技術または規格の構文と、ビデオ圧縮技術文書または規格、特にその中のプロフィール文書に準拠しているという意味において、使用されているビデオ圧縮技術または規格によって指定された構文に準拠している場合がある。また、コーディングされたビデオシーケンスの複雑さが、ビデオ圧縮技術または規格のレベルで定義されている範囲内にあることも、コンプライアンスに必要である。場合によっては、レベルは、最大ピクチャサイズ、最大フレームレート、最大再構築サンプルレート（例えば毎秒メガサンプルで測定される）、最大参照ピクチャサイズなどを制限する。レベルによって設定される制限は、場合によっては、仮想基準デコーダ（HRD）仕様およびコーディングされたビデオシーケンスにおいてシグナリングされたHRDバッファ管理のためのメタデータによってさらに制限され得る。

一実施形態では、受信器302は、コーディングされたビデオを有する追加の（冗長な）データを受信することができる。追加のデータは、コーディングされたビデオシーケンスの一部として含まれ得る。データを適切にデコードするために、および／または元のビデオデータをより正確に再構築するために、ビデオデコーダ300によって追加のデータが使用され得る。追加のデータは、例えば、時間、空間、または信号雑音比（SNR）強化層、冗長スライス、冗長ピクチャ、前方誤り訂正符号などの形態であり得る。

図4は、本開示の実施形態によるビデオエンコーダ400の機能ブロック図であり得る。

エンコーダ400は、エンコーダ400によってコーディングされるビデオ画像をキャプチャすることができるビデオソース401（エンコーダの一部ではない）からビデオサンプルを受信することができる。

ビデオソース401は、エンコーダ（303）によってコーディングされるソースビデオシーケンスを、任意の適切なビット深度（例えば、8ビット、10ビット、12ビット、…）であり得、任意の色空間（例えば、BT．601 Y CrCB、RGB、…）および適切なサンプリング構造（例えば、Y CrCb 4：2：0、Y CrCb 4：4：4）であり得るデジタルビデオサンプルストリームの形態で提供し得る。メディアサービングシステムにおいて、ビデオソース401は、予め用意されたビデオを記憶する記憶装置であってもよい。ビデオ会議システムでは、ビデオソース401は、ビデオシーケンスとしてローカル画像情報を取り込むカメラであってもよい。ビデオデータは、連続して見たときに動きを与える複数の個々のピクチャとして提供されてもよい。ピクチャ自体は、画素の空間配列として編成することができ、各画素は、使用中のサンプリング構造、色空間などに応じて1つまたは複数のサンプルを含むことができる。当業者であれば、画素とサンプルとの関係を容易に理解することができる。以下、サンプルに着目して説明する。

一実施形態によれば、エンコーダ400は、アプリケーションによって要求されるように、リアルタイムで、または任意の他の時間制約の下で、ソースビデオシーケンスのピクチャをコーディングし、コーディングされたビデオシーケンス410に圧縮し得る。適切なコーディング速度を強制することは、コントローラ402の1つの機能である。コントローラは、以下に説明するように他の機能ユニットを制御し、これらのユニットに機能的に結合される。分かりやすくするために、結合は描かれていない。コントローラによって設定されたパラメータには、レート制御関連パラメータ（ピクチャスキップ、量子化器、レート歪み最適化手法のラムダ値など）、ピクチャサイズ、Group of Pictures（GOP）レイアウト、最大動きベクトル探索範囲などが含まれ得る。当業者は、特定のシステム設計用に最適化されたビデオエンコーダ400に関係し得るので、コントローラ402の他の機能を容易に識別することができる。

いくつかのビデオエンコーダは、当業者が「コーディングループ」として容易に認識できる方法で動作する。過度に単純化された説明として、コーディングループは、エンコーダ402（以下、「ソースコーダ」）のコーディング部分（コーディングされる入力ピクチャおよび参照ピクチャに基づいてシンボルを作成する責任がある）からなることができ、エンコーダ400に埋め込まれた（ローカル）デコーダ406は、シンボルを再構築してサンプルデータを作成する（リモート）デコーダも作成する（シンボルとコーディングされたビデオビットストリーム間の圧縮は、ビデオ圧縮技術では損失がないため）開示された主題で考慮される。再構成されたサンプルストリームは、参照ピクチャメモリ405に入力される。シンボルストリームのデコードは、デコーダの場所（ローカルまたはリモート）に関係なくビット正確な結果をもたらすため、参照ピクチャバッファコンテンツもローカルエンコーダとリモートエンコーダとの間でビットが正確である。言い換えると、エンコーダの予測部分は、デコーダがデコード中に予測を使用するときに「参照」するのとまったく同じサンプル値を参照ピクチャのサンプルとして「見なす」。参照ピクチャの同期性のこの基本原理（および、例えばチャネルエラーのために同期性を維持できない場合に生じるドリフト）は、当業者によく知られている。

「ローカル」デコーダ406の動作は、「リモート」デコーダ300の動作と同じであり得、これは、図3に関連して上で詳細にすでに説明されている。しかしながら、図4も簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ408およびパーサ304によるコーディングされたビデオシーケンスへのシンボルのコーディング／デコーディングは無損失であり得るため、チャネル301、受信器302、バッファ303、およびパーサ304を含むデコーダ300のエントロピーデコード部分は、ローカルデコーダ406に完全に実装されない場合がある。

この時点でなされ得る観測は、デコーダ内に存在する構文解析／エントロピーデコードを除く任意のデコーダ技術もまた、対応するエンコーダ内に実質的に同一の機能形態で存在する必要があるということである。エンコーダ技術の説明は、それらが包括的に説明されたデコーダ技術の逆であるので省略することができる。特定の領域においてのみ、より詳細な説明が必要とされ、以下に提供される。

動作の一部として、ソースコーダ403は、「参照フレーム」として指定されたビデオシーケンスからの1つまたは複数の以前にコーディングされたフレームを参照して入力フレームを予測的にコーディングする動き補償予測コーディングを実行し得る。このようにして、コーディングエンジン407は、入力フレームの画素ブロックと、入力フレームへの予測参照として選択され得る参照フレームの画素ブロックとの間の差異をコーディングする。

ローカルビデオデコーダ406は、ソースコーダ403によって作成されたシンボルに基づいて、参照フレームとして指定され得るフレームのコーディングされたビデオデータをデコードし得る。コーディングエンジン407の動作は、有利には非可逆処理であり得る。コーディングビデオデータがビデオデコーダ（図4には示されていない）でデコードされ得るとき、再構築されたビデオシーケンスは、通常、いくつかのエラーを有するソースビデオシーケンスのレプリカであり得る。ローカルビデオデコーダ406は、参照フレームに対してビデオデコーダによって実行され得るデコード処理を複製し、再構成された参照フレームを参照ピクチャキャッシュ405に記憶させることができる。このようにして、エンコーダ400は、遠端ビデオデコーダによって得られる（送信エラーがない）再構成参照フレームとして共通のコンテンツを有する再構成参照フレームの複製をローカルに格納し得る。

予測器404は、コーディングエンジン407の予測探索を実行することができる。すなわち、コーディングされる新しいフレームについて、予測器404は、（候補参照画素ブロックとしての）サンプルデータまたは参照ピクチャの動きベクトル、ブロック形状などの、新しいピクチャの適切な予測参照として機能する特定のメタデータについて参照ピクチャメモリ405を探索することができる。予測器404は、適切な予測参照を見つけるために、サンプルブロックと画素ブロックごとに動作することができる。場合によっては、予測器404によって取得された探索結果によって判定されるように、入力ピクチャは、参照ピクチャメモリ405に格納された複数の参照ピクチャから描画された予測参照を有することができる。

コントローラ402は、例えば、ビデオデータをコーディングするために使用されるパラメータおよびサブグループパラメータの設定を含む、ビデオコーダ403のコーディング動作を管理し得る。

前述のすべての機能ユニットの出力は、エントロピーコーダ408においてエントロピーコーディングを受けることができる。エントロピーコーダは、例えばハフマンコーディング、可変長コーディング、算術コーディングなどの当業者に知られている技術に従ってシンボルを可逆圧縮することにより、様々な機能ユニットにより生成されたシンボルをコーディングされたビデオシーケンスに変換する。

送信器409は、エントロピーコーダ408によって作成されたコーディングされたビデオシーケンスをバッファリングして、コーディングされたビデオデータを格納する記憶装置へのハードウェア／ソフトウェアリンクであり得る通信チャネル411を介した送信に備えることができる。送信器409は、ビデオコーダ403からのコーディングビデオデータを、送信される他のデータ、例えば、コーディングされた音声データおよび／または補助データストリーム（ソースは図示せず）とマージすることができる。

コントローラ402は、エンコーダ400の動作を管理し得る。コーディング中、コントローラ405は、各コーディングピクチャに特定のコーディングピクチャ形式を割り当てることができ、これは、それぞれのピクチャに適用され得るコーディング技術に影響を及ぼし得る。例えば、多くの場合、ピクチャは次のフレームタイプのうちの1つとして割り当てられ得る。

イントラピクチャ（Iピクチャ）は、シーケンス内の他のフレームを予測のソースとして使用せずにコーディングおよびデコードできるものである。一部のビデオコーデックでは、例えばIndependent Decoder Refreshピクチャなど、様々なタイプのイントラピクチャを使用できる。当業者は、Iピクチャのこれらの変形ならびにそれらのそれぞれの用途および特徴を認識している。

予測ピクチャ（Pピクチャ）は、各ブロックのサンプル値を予測するために最大で1つの動きベクトルおよび参照インデックスを使用するイントラ予測またはインター予測を使用してコーディングおよびデコードされ得るものであり得る。

双方向予測ピクチャ（Bピクチャ）は、各ブロックのサンプル値を予測するために最大で2つの動きベクトルおよび参照インデックスを使用するイントラ予測またはインター予測を使用してコーディングおよびデコードされ得るものであり得る。同様に、複数の予測ピクチャは、シングルブロックの再構築のために3つ以上の参照ピクチャおよび関連するメタデータを使用することができる。

ソースピクチャは、一般に、複数のサンプルブロック（例えば、各々、4×4、8×8、4×8、または16×16のサンプルのブロック）に空間的に細分化され、ブロックごとにコーディングされ得る。ブロックは、ブロックのそれぞれのピクチャに適用されるコーディング割り当てによって決定されるように、他の（すでにコーディングされた）ブロックを参照して予測的にコーディングされ得る。例えば、Iピクチャのブロックは非予測的にコーディングされてもよく、またはそれらは同じピクチャのすでにコーディングされたブロックを参照して予測的にコーディングされてもよい（空間予測またはイントラ予測）。Pピクチャの画素ブロックは、以前にコーディングされた1つの参照ピクチャを参照して、空間的予測を介して、または時間的予測を介して、非予測的にコーディングされ得る。Bピクチャのブロックは、1つまたは2つの以前にコーディングされた参照ピクチャを参照して、空間的予測を介して、または時間的予測を介して、非予測的にコーディングされ得る。

ビデオコーダ400は、ITU－T Rec．H．265などの所定のビデオコーディング技術または規格に従ってコーディング動作を実行し得る。その動作において、ビデオコーダ400は、入力ビデオシーケンスの時間的および空間的冗長性を活用する予測コーディング操作を含む、様々な圧縮操作を実行し得る。したがって、コーディングビデオデータは、使用されているビデオコーディング技術または規格によって指定された構文に準拠することができる。

一実施形態では、送信器409は、コーディングされたビデオと共に追加のデータを送信することができる。ソースコーダ403は、コーディングされたビデオシーケンスの一部としてそのようなデータを含むことができる。追加のデータには、時間的／空間的／SNR拡張レイヤ、冗長なピクチャやスライスなどの冗長データの他の形式、補足拡張情報（SEI）メッセージ、視覚ユーザビリティ情報（VUI）パラメータセットフラグメントなどが含まれ得る。

図5は、HEVCおよびJEMで使用されるイントラ予測モードを示す。自然なビデオに示される任意のエッジ方向をキャプチャするために、指向性イントラモードの数は、HEVCで使用されている33から65へ拡張される。HEVCに加えてJEMにおける追加の指向性モードは、図1（b）において点線矢印として示されており、planarモードおよびDCモードは同じままである。これらのより高密度の指向性イントラ予測モードは、すべてのブロックサイズおよびルマおよびクロマイントラ予測の両方に適用される。図5に示すように、奇数イントラ予測モードインデックスに関連付けられた、点線の矢印によって識別される指向性イントラ予測モードは、奇数イントラ予測モードと呼ばれる。実線矢印で識別される、偶数イントラ予測モードインデックスに関連付けられた指向性イントラ予測モードは、偶数イントラ予測モードと呼ばれる。本明細書では、図5の実線または点線の矢印で示される方向性イントラ予測モードは、angularモードとも呼ばれる。

JEMでは、ルマイントラ予測に合計67個のイントラ予測モードが用いられる。イントラモードをコーディングするために、サイズ6の最確モード（most probable mode：MPM）リストが、近傍ブロックのイントラモードに基づいて構築される。イントラモードがMPMリストからのものでない場合、イントラモードが選択されたモードに属するか否かを示すフラグがシグナリングされる。JEM－3．0では、16個の選択されたモードがあり、これらは4つのangularモードごとに一様に選択される。JVET－D0114およびJVET－G0060では、一様に選択されたモードを置き換えるために16個の二次MPMが導出される。

図6は、イントラ指向性モードのために利用されるN個の基準階層を示す。ブロックユニット611、セグメントA 601、セグメントB 602、セグメントC 603、セグメントD 604、セグメントE 605、セグメントF 606、第1基準階層610、第2基準階層609、第3基準階層608および第4基準階層607がある。

HEVCおよびJEM、ならびにH．264／AVCなどの他のいくつかの規格では、現在のブロックを予測するために使用される参照サンプルは、最も近い基準線（行または列）に制限される。複数の基準線イントラ予測の方法では、候補基準線（行または列）の数は、イントラ方向モードに対して1（すなわち、最も近い）からNに増加され、Nは1以上の整数である。図2は、多回線イントラ方向予測方法の概念を示すために、例として4×4予測ユニット（PU）を取る。イントラ方向モードは、予測器を生成するためにN個の基準階層のうちの1つを任意に選択することができる。換言すれば、予測器p（x、y）は、参照サンプルS1、S2、．．．、SNのうちの1つから生成される。フラグは、どの基準階層がイントラ方向モードのために選択されるかを示すためにシグナリングされる。Nが1に設定される場合、イントラ方向予測方法は、JEM 2．0の従来の方法と同じである。図6では、基準線610、609、608および607は、左上基準サンプルと共に6つのセグメント601、602、603、604、605および606から構成される。本明細書では、基準階層は基準線とも呼ばれる。現在のブロックユニット内の左上画素の座標は（0、0）であり、第1の基準線内の左上画素は（－1、－1）である。

JEMでは、ルマ成分について、イントラ予測サンプル生成に使用される近傍サンプルは、生成プロセスの前にフィルタリングされる。フィルタリングは、所与のイントラ予測モードおよび変換ブロックサイズによって制御される。イントラ予測モードがDCであるか、または変換ブロックサイズが4×4に等しい場合、近傍サンプルはフィルタリングされない。所与のイントラ予測モードと垂直モード（または水平モード）との間の距離が所定のしきい値よりも大きい場合、フィルタ処理が有効化される。近傍サンプルフィルタリングには、［1，2，1］フィルタおよびバイリニアフィルタが使用される。

位置依存イントラ予測合成（PDPC）方法は、フィルタリングされていない境界参照サンプルと、フィルタリングされた境界参照サンプルを有するHEVCスタイルのイントラ予測との組み合わせを呼び出すイントラ予測方法である。（x、y）に位置する各予測サンプルpred［x］［y］は、以下のように計算される。
Pred［x］［y］＝（wL＊R_－1，y＋wT＊R_x，－1＋wTL＊R_－1，－1＋（64 wL－wT－wTL）＊pred［x］［y］＋32）≫6（式1）
式中、R_x，－1，R_－1，yは、それぞれ現在のサンプル（x、y）の上および左に位置するフィルタ処理されていない参照サンプルを表し、R_－1，－1は、現在のブロックの左上隅に位置するフィルタ処理されていない参照サンプルを表す。重み付けは以下のように計算される。
wT＝32≫（（y≪1）≫shift）（式2）
wL＝32≫（（x≪1）≫shift）（式3）
wTL＝－（wL≫4）－（wT≫4）（式4）
shift＝（log2（width）＋log2（height）＋2≫2（式5）。

図7は、1つの4×4ブロック内の（0、0）および（1、0）位置に対してDCモードPDPCが（wL、wT、wTL）重み付けする図700を示す。PDPCがDC、planar、水平、および垂直イントラモードに適用される場合、HEVC DCモード境界フィルタまたは水平／垂直モードエッジフィルタなどの追加の境界フィルタは必要とされない。図7は、右上対角モードに適用されたPDPCの基準サンプルRx、－1、R－1、yおよびR－1、－1の定義を示す。予測サンプルpred（x’、y’）は、予測ブロック内の（x’、y’）に位置する。基準サンプルRx，－1の座標xは、x＝x’＋y’＋1によって与えられ、基準サンプルR－1，yの座標yも同様に、y＝x’＋y’＋1によって与えられる。

図8は、局所照明補償（LIC）図800を示し、スケーリングファクタaおよびオフセットbを使用した、照明変化の線形モデルに基づいている。そして、各々のインターモードコーディングされたコーディングユニット（CU）に対して適応的に有効または無効にされる。

LICがCUに適用する場合、最小二乗誤差法を使用して、現在CUの近傍サンプルおよびそれらの対応する参照サンプルを使用してパラメータaおよびbを導出する。より具体的には、図8に例示されるように、CUのサブサンプル（2：1サブサンプル）された近傍サンプル、および、参照ピクチャにおける（現在CUまたはサブCUの動き情報によって識別される）対応するサンプルが使用される。ICパラメータは、各予測方向に対して別々に導出され適用される。

CUがマージモードでコーディングされる場合、LICフラグは、マージモードにおける動き情報コピーと同様の方法で、近傍ブロックからコピーされる。そうでない場合、LICフラグがCUのためにシグナリングされて、LICが適用されるか否かを示す。

図9Aは、HEVCで使用されるイントラ予測モード900を示す。HEVCには、合計35のイントラ予測モードがあり、そのうちモード10は水平モード、モード26は垂直モード、モード2、モード18、モード34は対角モードである。イントラ予測モードは、3つの最も可能性の高いモード（most probable modes：MPM）および32個の残りのモードによってシグナリングされる。

図9Bは、VVCの実施形態において、モード18が水平モードであり、モード50が垂直モードであり、モード2、モード34およびモード66が対角モードである合計87個のイントラ予測モードがあることを示す。モード－1～－10およびモード67～76は、広角イントラ予測（Wide－Angle Intra Prediction：WAIP）モードと呼ばれる。

位置（x、y）に位置する予測サンプルpred（x、y）は、イントラ予測モード（DC、planar、angular）と参照サンプルの線形組み合わせを用いてPDPC式に従って予測される。
pred（x，y）＝（wL×R－1，y＋wT×Rx，－1－wTL×R－1，－1＋（64－wL－wT＋wTL）×pred（x，y）＋32）＞＞6（6）
式中、Rx，－1、R－1，yは、それぞれ、現在のサンプル（x、y）の上および左に位置する参照サンプルを表し、そしてR－1，－1は、現在のブロックの左上隅に位置する参照サンプルを表す。

DCモードの場合、重量は、幅と高さの寸法を持つブロックに対して次のように計算される。
wT＝32＞＞（（y＜＜1）＞＞nScale），wL＝32＞＞（（x＜＜1）＞＞nScale），wTL＝（wL＞＞4）＋（wT＞＞4），（7）
ここで、nScale＝（log2（width）－2＋log2（height）－2＋2）＞＞2、であり、
式中、wTは、同じ水平座標を有する上記の基準線に位置する参照サンプルの重み係数を表し、wLは、同じ垂直座標を有する左基準線に位置する参照サンプルの重み係数を表し、wTLは、現在のブロックの左上参照サンプルの重み係数を表し、nScaleは、軸に沿って重み係数がどれだけ速く減少するか（wLは左から右に減少するか、またはwTは上から下に減少する）、すなわち重み係数の減少率を指定し、現在の設計では、x軸（左から右）およびy軸（上から下）に沿って同じである。また、32は近傍サンプルの初期重み係数を示し、初期重み係数はまた、現在のCBにおいて左上サンプルに割り当てられた上（左または左上）の重みであり、PDPC処理における近傍サンプルの重み係数は、この初期重み係数以下でなければならない。

平面モードの場合はwTL＝0であり、一方、水平モードの場合はwTL＝wT、垂直モードの場合はwTL＝wLである。PDPC重みは、加算およびシフトのみで計算することができる。pred（x，y）の値は、式1を使用して1つのステップで計算できる。

本明細書では、提案された方法は、別々に使用されてもよいし、任意の順序で組み合わされてもよい。さらに、方法（または実施形態）、エンコーダ、およびデコーダの各々は、処理回路（例えば、1つまたは複数のプロセッサまたは1つまたは複数の集積回路）によって実施されてもよい。一例では、1つまたは複数のプロセッサは、非一時的コンピュータ可読媒体に記憶されたプログラムを実行する。以下では、用語ブロックは、予測ブロック、コーディングブロック、またはコーディングユニット、すなわちCUとして解釈され得る。

図10は、S100において、コーディングユニットおよび変換ユニットなどのユニットの処理を実施するか否かをS101において判定することができるように、データを受信することができるようなフローチャート1000の例示的な実施形態を示す。そうである場合、S102において、コーディングユニットがイントラモード予測を含んでいるか否かが判定され得る。そうである場合、S103において、コーディングユニットがSPS ACTが有効であるか否かを示すフラグを含むか否かを判定することができ、そのようなフラグにそのような指示がある場合、S104において、コーディングユニットのツリータイプがシングルツリータイプであるか否かも判定することができる。例示的な実施形態によれば、1に等しいsps＿act＿enabled＿flagは、適応色変換が使用され得、cu＿act＿enabled＿flagがコーディングユニット構文内に存在し得ることを指定する。0に等しいsps＿act＿enabled＿flagは、適応色変換が使用されない可能性があり、cu＿act＿enabled＿flagがコーディングユニット構文に存在しない可能性があることを指定することができる。sps＿act＿enabled＿flagが存在しない場合、0に等しいと推測することができる。

S102、S103、およびS104において、イントラモード、SPS ACTの有効化を示すフラグ、およびツリーがシングルツリータイプであると判定された場合、S105において、処理は、S105において、ACTが有効であることを示すフラグをそのコーディングユニットに設定することができる。例示的な実施形態によれば、1に等しいcu＿act＿enabled＿flagは、現在のコーディングユニットの残差がYCgCo色空間でコーディングされることを指定することができる。0に等しいcu＿act＿enabled＿flagは、現在のコーディングユニットの残差が元の色空間においてコーディングされることを指定することができる。cu＿act＿enabled＿flagが存在しない場合、それは0に等しいと推測することができる。したがって、そのような構文に基づいて、cu＿coded＿flagが1である場合、インターブロックはACTモードでコーディングすることができ、これは、現在CUに2つ以上の係数がある場合にインターブロックに対してACTモードが有効化され得ることを意味すると解釈され得る。

次に、S106において、本明細書で説明されるさらなる処理、ならびに上述のS101へのループが実施され得る。あるいは、S102において、モードがイントラに設定されていないと判定された場合、および／またはS103において、sps＿act＿enabledフラグがそのような有効化された指示を含まないと判定された場合、S107において、PLT予測フラグに関する指示があるか否かが判定され、そうでない場合、S108において、general＿merge＿flagの値の判定がされる。S102、S107、およびS108におけるそのような値が以下で説明するように設定される場合、処理は、S109において、cu＿coded＿flagを設定することができ、その後、S110において、またはS107およびS108から、そのようなcu＿coded＿flagが現在設定されている場合、S111において、コーディングユニットがSPS ACTが有効であるか否かを示すフラグを含むか否かを判定することができ、そのようなフラグにそのような指示がある場合、S112において、イントラモードが現在示されているか否かを判定することができ、そうでない場合、処理は上述したようにS104において進むことができる。

図11は、S100において、コーディングユニットおよび／または変換ユニットの処理を実施するか否かがS101において決定され得るようにデータが受信され得るようなフローチャート1100の例示的な実施形態を示す。例えば、S201またはS202において、予測モードIntraにある現在CUがあるか（S201）否か（S202）にかかわらず、処理はS203に進み、色差チャネルのTUコード化フラグが両方とも0である場合を判定することができる。そうである場合、S203において、次に図示されたY’によって、S203におけるそのような判定は、輝度のTUコード化フラグが1に推論されるべきであると推論する際にS204に進むのに十分であり得、したがって、そのような推論は、現在のCUブロックの現在の予測モードがMODE＿INTRAであるか否かにかかわらず行われ得る。さらに、S203におけるそのような肯定的な判定に加えて、色差チャネルのTUコーディングフラグが両方とも0であり、現在CUもACTモードでコーディングされているか否かであってもよく、そうである場合、進行はS203の直後ではなくS204に進むことができる。それにもかかわらず、その後のS204において、およびS203において否定判定されると、処理は、上述したようにS100およびS106のいずれかにおいて説明したように進むことができる。実施形態によれば、ACTがオンであるコーディングブロックの場合、tu＿y＿coded＿flagはビットストリーム内でシグナリングされない場合があり、色差チャネルのTUコーディングフラグが両方とも0であるときは、1であると推論されるべきである。さらに、そのような例示的な実施形態によれば、cu＿act＿enabled＿flag信号は、現在のCUブロックの予測モードのチェックなしにシグナリングされてもよく（S201およびまたはS202）、その結果、実施形態では、例えば、コーディングユニットについて、cu＿act＿enabled＿flagのシグナリングについて、2つの条件、sps＿act＿enabled＿flagおよびtreeTypeがSINGLE＿TREEである、のみがチェックされてもよく、したがって、予測モードに基づいてcu＿act＿enabled＿flagの条件付きシグナリングを2回回避する利点が、以下に説明され、例えば図12にも示されるように達成されてもよい。

両方のクロマチャネルのTUコードフラグが0であり、ACTフラグが1であるときに、意図的にシグナリングされない可能性がある現在のCUブロックのtu＿y＿coded＿flagを有する実施形態については、表1を参照されたく、とりわけ、．．．CuPredMode［chType］［x0］［y0］＝＝MODE＿INTRA「＆＆！cu＿act＿enabled＿flag」．．．が、ACTのTUレベルのシグナリングに含まれる。

ACTについてのCUレベルでのcu＿act＿enabled＿flagシグナリングに関して表2によって示される例示的な実施形態のみによる、sps＿act＿enabled＿flagおよびtree＿typeを含む現在のCUブロックについてのcu＿act＿enabled＿flagシグナリングの条件を有する実施形態によれば、

例えば、図12は、S100において、コーディングユニットおよびまたは変換ユニットの処理を実施するか否かをS301で判定することができるようにデータを受信することができるようにフローチャート1200の例示的な実施形態を示す。そうである場合、S302において、コーディングユニットがSPS ACTが有効であるか否かを示すフラグを含むか否かを判定することができ、そのようなフラグにそのような指示がある場合、S304において、コーディングユニットのツリータイプがシングルツリータイプであるか否かも判定することができる。このような例示的な実施形態によれば、1に等しいsps＿act＿enabled＿flagは、適応色変換が使用されてもよく、cu＿act＿enabled＿flagがコーディングユニット構文に存在してもよいことを指定する。0に等しいsps＿act＿enabled＿flagは、適応色変換が使用されない可能性があり、cu＿act＿enabled＿flagがコーディングユニット構文に存在しない可能性があることを意味する。sps＿act＿enabled＿flagが存在しない場合、0に等しいと推測することができる。

S302およびS304において、フラグがSPS ACTの有効化を示し、ツリーがシングルツリータイプであると判定された場合、S305において、処理は、S305において、ACTが有効であることを示すフラグをそのコーディングユニットに設定することができる。例示的な実施形態によれば、cu＿act＿enabled＿flagが1に等しいことは、現在のコーディングユニットの残差がYCgCo色空間でコーディングされることを指定することができる。cu＿act＿enabled＿flagが0に等しいことは、現在のコーディングユニットの残差が元の色空間においてコーディングされることを指定することができる。cu＿act＿enabled＿flagが存在しない場合、それは0に等しいと推測することができる。したがって、そのような構文に基づいて、cu＿coded＿flagが1である場合、インターブロックはACTモードでコーディングすることができ、これは、現在CUに2つ以上の係数があるならばインターブロックのためにACTモードが有効化され得ることを意味すると解釈され得る。

次に、S106において、本明細書で説明されるさらなる処理、ならびに上述のS301へのループが実施され得る。あるいは、S302において、sps＿act＿enabledフラグがそのような有効化された指示を含まないと判定されたならば、S307において、PLT予測フラグに関する指示があるか否かを判定することができ、そうでない場合、S808において、general＿merge＿flagの値の判定を行うことができる。S302、S307、およびS308におけるそのような値が図8に示すようにそれに応じて設定される場合、処理は、S309において、上述のcu＿coded＿flagを設定することができる。

したがって、このような実施形態は、様々な技術的問題を解決し、例えば、コーディングされたCUブロックがいかなる係数も有していない場合、ACTモードはもはやシグナリングされるべきではなく、したがって、ACTモードを有するCUは、コーディングされたCUブロック内に1つまたは複数の係数を有するはずであり、ACTモードを有するインターブロックの場合、CUが変換ユニット内に少なくとも1つの係数を有することを表すためにcu＿coded＿flagが1であるはずであり、それによって、ACTモードを有するイントラCUについて不存在の制約を解決する。

そのような特徴は、RGBビデオなどのための有利なコーディングツールを表す。例えば、図13の図1300を参照すると、コーディングフロー1301およびデコードフロー1302が示されており、画面コーディングモデル（SCM）（HEVCの画面コンテンツコーディング拡張のソフトウェアテストモデルなど）に採用されたインループACTが示されており、ACTは残差ドメインで動作するものとして示されており、CUレベルフラグは色空間変換の使用を示すためにシグナリングされ得る。SCMで使用されるそのような色変換は、例示的な実施形態によれば、以下の通りであってもよい。

さらに、図14の図1400には、ACTを用いた例示的な実施形態によるデコードプロセスが示されており、上述の実施形態およびフローチャートを考慮して、HEVCのACTツールをVVCフレームワークに含めて、ビデオコーディングの効率を向上させ、ACTを用いたデコードをそのように適用することができる。図14のように、色空間変換が残差ドメインで行われてもよく、具体的には、YCgCoドメインからの残差を元のドメインに戻すように変換するために、逆変換の後などに、追加のデコードモジュール、すなわち逆ACTが導入されてもよいことが図1400に示されている。したがって、他の開示の中でも上述の図10～図12を見ると、VVCの特徴に対する利点が実現され、最大変換サイズが1つのコーディングユニット（CU）の幅または高さ以上である場合に、1つのCUリーフノードも変換処理の単位として使用することができ、したがって、本明細書の実施形態では、1つのCUに対してACTフラグをシグナリングして、その残差をコーディングするための色空間を選択することができ、そのようなHEVC ACT設計に従って、ブロック間およびブロック内コピー（IBC）CUの場合、CUに少なくとも1つの非ゼロ係数があるときにのみACTを有効化することができ、イントラCUの場合、クロマ成分がルマ成分の同じイントラ予測モード、すなわちDMモードを選択したときにのみACTを有効化することができ、それにより、例示的な実施形態によるそのような不要なまたは冗長なシグナリングを有利に少なくとも回避することができる。

例示的な実施形態によれば、色空間変換に使用されるコア変換は、適用されるように、以下に説明するように、以下の順方向および逆方向YCgCo色変換行列に関するものであってもよい。例えば、

さらに、色変換の前後の残差信号のダイナミックレンジの変化を補償するために、（－5，－5，－3）などのQP調整を変換残差に適用することができる。一方、（1）に示すように、順方向および逆方向の色変換は、3つすべての成分の残差にアクセスする必要があり得る。これに対応して、本出願の実施形態では、3つの構成要素のすべての残差が利用可能ではない以下のシナリオでACTを無効にすることを可能にする技術的改善が図られる。例えば、図10～図12および説明を参照すると、分離木が適用されるとき、1つのCTU内のルマおよびクロマサンプルが異なる構造によって分割されるような分離木パーティションケースがあり、これは、ルマツリー内のCUがルマ成分のみを含み、クロマツリー内のCUが2つのクロマ成分のみを含み、また、ISPサブパーティションが、クロマ信号が分割せずにコーディングされている間にルマにのみ適用され得るイントラサブパーティション予測（ISP）ケースもあり、そのようなISP設計では、最後のISPサブパーティションを除いて、他のサブパーティションは、実施形態によるルマ成分のみを含む。

したがって、上記の表および／または表3などのコーディング構文表に従ってCUレベルACT関連シグナリングが含まれ得るACTのそのようなCUレベルシグナリングがあり得る。

実施形態では、sps＿act＿enabled＿flagが1に等しいことは、適応色変換が使用され得ること、およびcu＿act＿enabled＿flagがコーディングユニット構文に存在し得ることを指定することができ、sps＿act＿enabled＿flagが0に等しいことは、適応色変換が使用され得ないこと、およびcu＿act＿enabled＿flagがコーディングユニット構文に存在し得ないことを指定することができ、sps＿act＿enabled＿flagが存在しない場合、それは0に等しいと推測され得る。実施形態では、cu＿act＿enabled＿flagが1に等しいことは、現在のコーディングユニットの残差がYCgCo色空間でコーディングされることを指定することができ、cu＿act＿enabled＿flagが0に等しいことは、現在のコーディングユニットの残差が元の色空間でコーディングされることを指定することができ、cu＿act＿enabled＿flagが存在しない場合、それは0に等しいと推測することができる。例示的な実施形態によれば、上記の構文に基づいて、cu＿coded＿flagが1である場合にインターブロックをACTモードでコーディングすることができ、それによって、現在CUに2つ以上の係数がある場合などにインターブロックに対してACTモードを有効化することができる。

さらに、3つのカラーチャネル用のTUコーディングフラグなどの、ACTブロック用のTUレベルルマコーディングフラグシグナリングに関する構文は、以下の変換ユニット構文テーブル、表4に従って含まれ得る。

例示的な実施形態によれば、ルマ成分関連セマンティクスのTUコーディングフラグは、以下のように示すこともできる。1に等しいtu＿y＿coded＿flag［x0］［y0］は、ルマ変換ブロックが0に等しくない1つまたは複数の変換係数レベルを含むことを指定することができ、配列インデックスx0、y0は、ピクチャの左上ルマサンプルに対する考慮される変換ブロックの左上ルマサンプルの位置（x0、y0）を指定することができ、tu＿y＿coded＿flag［x0］［y0］が存在しない場合、その値は、以下のように推測することができる。cu＿sbt＿flagが1に等しく、以下の（a）、（b）の条件のうちの1つが真である場合、tu＿y＿coded＿flag［x0］［y0］は0に等しいと推論され、（a）subTuIndexは0に等しく、cu＿sbt＿pos＿flagは1に等しく、（b）subTuIndexは1に等しく、cu＿sbt＿pos＿flagは0に等しく、そうでない場合、treeTypeがDUAL＿TREE＿CHROMAに等しい場合、tu＿y＿coded＿flag［x0］［y0］は0に等しいと推論され、さらにそうでない場合、tu＿y＿coded＿flag［x0］［y0］は1に等しいと推論されてもよい。そのような構文および関連するセマンティクスでは、TUコード化フラグのACTブロックに関する条件チェックは存在しない場合がある。

さらに、ACTブロックの例示的なtu＿y＿coded＿flagについて、輝度成分のTUコーディングフラグは、以下のように記述することができる。
if（！isChroma（partitioner．chType））
｛
if（！CU：：isIntra（cu）＆＆trDepth＝＝0＆＆！chromaCbfs．sigChroma（area．chromaFormat））
｛
TU：：setCbfAtDepth（tu，COMPONENT＿Y，trDepth，1）；
｝
else if（cu．sbtInfo＆＆tu．noResidual）
｛
TU：：setCbfAtDepth（tu，COMPONENT＿Y，trDepth，0）；
｝
else if（cu．sbtInfo＆＆！chromaCbfs．sigChroma（area．chromaFormat））
｛
assert（！tu．noResidual）；
TU：：setCbfAtDepth（tu，COMPONENT＿Y，trDepth，1）；
｝
else
｛
bool lumaCbfIsInferredACT＝（cu．colorTransform＆＆cu．predMode＝＝MODE＿INTRA＆＆
trDepth＝＝0＆＆！chromaCbfs．sigChroma（area．chromaFormat））；
bool lastCbfIsInferred＝lumaCbfIsInferredACT；／／ISPとACTは相互に排他的である
bool previous Cbf＝false；
bool rootCbfSoFar＝false；
if（cu．ispMode）
｛
．．．
｝
bool cbfY＝lastCbfIsInferred？true：
cbf＿comp（cs，tu．Y（），trDepth，previousCbf，cu．ispMode）；
TU：：setCbfAtDepth（tu，COMPONENT＿Y，trDepth，（cbfY？1：0））；
｝
｝

したがって、色差チャネルのTUコーディングフラグが両方とも0であり、現在CUがイントラブロックであり、ACTモードでコーディングされている場合、輝度のTUコーディングフラグは1に推論され得る。

本明細書に記載されるように、例示的な実施形態による本明細書に記載された値のうちの1つの間の所定のデルタ値（差分）を決定または格納するように構成された、バッファ、算術論理演算ユニット、メモリ命令などの1つまたは複数のハードウェアプロセッサおよびコンピュータ構成要素が存在してもよい。

したがって、本明細書に記載の例示的な実施形態によって、上記の技術的問題は、これらの技術的解決策の1つまたは複数によって有利に改善され得る。すなわち、実施形態によれば、1つまたは複数の異なる技術的問題に対処するために、本開示は、アクセスユニットデリミタNALユニットを含むアクセスユニット内のコーディングピクチャのスライス内にどのslice＿type値が存在するかを示すために、アクセスユニットデリミタ（AUD）が有利にシグナリングされ得る新規な技術的態様を説明する。pic＿typeは、AUが外部AUから独立しているか依存しているかを識別するために使用され得る。さらに、そのような新規の構文要素シグナリングは、それぞれ例示的な実施形態によるランダムアクセスAUおよびAU境界検出のロバスト性の表示に有利であり、したがって、例えば、精度および効率の改善に有利であると主張される。

上述した技術は、コンピュータ可読命令を使用し、1つまたは複数のコンピュータ可読媒体に物理的に記憶されるか、または具体的に構成された1つまたは複数のハードウェアプロセッサによってコンピュータソフトウェアとして実装することができる。例えば、図12は、開示された主題の特定の実施形態を実装するのに適したコンピュータシステム1200を示している。

コンピュータソフトウェアは、任意の適切な機械コードまたはコンピュータ言語を使用してコーディングでき、アセンブリ、コンパイル、リンク、または同様のメカニズムの対象となり、コンピュータ中央処理装置（CPU）、グラフィック処理装置（GPU）などにより直接的に、または解釈、マイクロコードの実行などを通じて実行できる命令を含むコードを作成する。

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム装置、モノのインターネット装置などを含む様々な種類のコンピュータまたはその構成要素上で実行することができる。

コンピュータシステム1500について図15に示される構成要素は、本質的に例示であり、本開示の実施形態を実装するコンピュータソフトウェアの使用または機能の範囲に関していかなる制限を示唆することを意図しない。また、構成要素の構成は、コンピュータシステム1500の例示的な実施形態に示されている構成要素のいずれか1つまたは組み合わせに関する依存性または要件を有するものとして解釈されるべきではない。

コンピュータシステム1500は、特定のヒューマンインターフェース入力装置を含み得る。そのようなヒューマンインターフェース入力装置は、例えば、触覚入力（キーストローク、スワイプ、データグローブの動きなど）、音声入力（声、拍手など）、視覚入力（ジェスチャなど）、嗅覚入力（図示せず）など、1人または複数の人間のユーザによる入力に応答し得る。ヒューマンインターフェース装置を使用して、音声（スピーチ、音楽、環境音など）、画像（走査した画像、静止画像カメラから得られる写真画像など）、ビデオ（2次元ビデオ、立体ビデオを含む3次元ビデオなど）など、人間による意識的な入力に必ずしも直接関係しない特定の媒体をキャプチャすることもできる。

入力ヒューマンインターフェース装置には、キーボード1501、マウス1502、トラックパッド1503、タッチスクリーン1510、ジョイスティック1505、マイク1506、スキャナ1508、カメラ1507のうち1つまたは複数（それぞれ図示のものの1つのみ）が含まれ得る。

コンピュータシステム1500はまた、特定のヒューマンインターフェース出力装置を含み得る。そのようなヒューマンインターフェース出力装置は、例えば、触知出力、音、光、および匂い／味によって1人または複数の人間のユーザの感覚を刺激することができる。そのようなヒューマンインターフェース出力装置は、触覚出力装置（例えば、タッチスクリーン1510、またはジョイスティック1505による触覚フィードバックを含み得るが、入力装置として機能しない触覚フィードバック装置もあり得る）、音声出力装置（スピーカ1509、ヘッドホン（図示せず）など）、視覚的出力装置（それぞれにタッチスクリーン入力機能の有無にかかわらず、それぞれ触覚フィードバック機能の有無にかかわらず、ステレオグラフィック出力、仮想現実の眼鏡（図示せず）、ホログラフィックディスプレイおよびスモークタンク（図示せず）などの手段により、2次元の視覚的出力または3次元以上の出力を出力できるものもある、CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含むスクリーン1510など）、およびプリンタ（図示せず）を含み得る。

コンピュータシステム1500には、人間がアクセスできる記憶装置と、CD／DVD 1511を含むCD／DVD ROM／RW 1520などの光学メディア、サムドライブ1522、リムーバブルハードドライブまたはソリッドステートドライブ1523、テープおよびフロッピーディスク（図示せず）などのレガシー磁気媒体、セキュリティドングル（図示せず）などの専用のROM／ASIC／PLDベースの装置などの関連媒体も含めることができる。

当業者はまた、ここで開示される主題に関連して使用される「コンピュータ可読媒体」という用語は、送信媒体、搬送波、または他の一時的な信号を包含しないことを理解するべきである。

コンピュータシステム1500は、1つまたは複数の通信ネットワーク1598へのインターフェース1599も含み得る。ネットワーク1598は、例えば、無線、有線、光であり得る。さらに、ネットワーク1598は、ローカル、広域、大都市圏、車両および産業、リアルタイム、遅延耐性などがある。ネットワーク1598の例としては、イーサネット、無線LAN、GSM、3G、4G、5G、LTEなどを含むセルラーネットワークなどのローカルエリアネットワーク、ケーブルテレビ、衛星テレビ、地上波放送テレビを含むTV有線または無線広域デジタルネットワーク、CANBusなどが含まれる車両用、産業用など、がある。特定のネットワーク1598では、一般に、特定の汎用データポートまたは周辺バス（1550および1551）（例えば、コンピュータシステムのUSBポート1500など）に接続された外部ネットワークインターフェースアダプタが必要であり、他のものは一般に、以下に説明するようにシステムバスに接続することにより、コンピュータシステムのコア1500に統合される（例えば、PCコンピュータシステムへのイーサネットインターフェースまたはスマートフォンコンピュータシステムへのセルラーネットワークインターフェース）。これらのネットワーク1598のいずれかを使用して、コンピュータシステム1500は他のエンティティと通信できる。このような通信は、単方向、受信のみ（例えば、放送TV）、単方向送信のみ（例えば、CANbusから特定のCANbus装置）、または双方向、例えば、ローカルエリアデジタルネットワークまたはワイドエリアデジタルネットワークを使用する他のコンピュータシステムへの通信であり得る。特定のプロトコルおよびプロトコルスタックは、上述したように、それらのネットワークおよびネットワークインターフェースのそれぞれで使用することができる。

前述のヒューマンインターフェース装置、ヒューマンアクセス可能な記憶装置、およびネットワークインターフェースは、コンピュータシステム1500のコア1540に接続することができる。

コア1540は、1つまたは複数の中央処理装置（CPU）1541、グラフィック処理装置（GPU）1542、グラフィックアダプタ1517、フィールド・プログラマブル・ゲート・エリア（FPGA）1543の形態の専用プログラマブル処理装置、特定のタスク用のハードウェアアクセラレータ1544などを含むことができる。これらの装置は、読み取り専用メモリ（ROM）1545、ランダムアクセスメモリ1546、ユーザがアクセスできない内部ハードドライブ、SSDなどの内部大容量記憶装置1547と共に、システムバス1548を介して接続され得る。いくつかのコンピュータシステムでは、システムバス1548に1つまたは複数の物理プラグの形でアクセスして、追加のCPU、GPUなどによる拡張を有効化することができる。周辺機器は、コアのシステムバス1548に直接、または周辺バス1551を介して接続できる。周辺バスのアーキテクチャには、PCI、USBなどが含まれる。

CPU 1541、GPU 1542、FPGA 1543、およびアクセラレータ1544は、組み合わせて前述のコンピュータコードを構成できる特定の命令を実行できる。そのコンピュータコードは、ROM 1545またはRAM 1546に記憶することができる。移行データはまた、RAM 1546に記憶することができ、一方、永続データは、例えば内部大容量記憶装置1547に記憶することができる。1つまたは複数のCPU 1541、GPU 1542、大容量記憶装置1547、ROM 1545、RAM 1546などと密接に関連付けることができるキャッシュメモリを使用することにより、任意のメモリ装置に対する高速記憶および読み出しが可能になる。

コンピュータ可読媒体は、様々なコンピュータ実装動作を実行するためのコンピュータコードを有することができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築されたものであってもよく、またはコンピュータソフトウェア技術の当業者に周知で利用可能な種類のものであってもよい。

限定ではなく例として、アーキテクチャ1500、特にコア1540を有するコンピュータシステムは、1つまたは複数の有形のコンピュータ可読媒体に組み込まれたソフトウェアを実行するプロセッサ（CPU、GPU、FPGA、アクセラレータなどを含む）の結果として機能を提供できる。このようなコンピュータ可読媒体は、上で紹介したユーザがアクセス可能な大容量記憶装置、およびコア内部大容量記憶装置1547やROM 1545などの非一時的な性質を持つコア1540の特定の記憶装置に関連付けられた媒体であり得る。本開示の様々な実施形態を実装するソフトウェアは、そのような装置に記憶され、コア1540によって実行され得る。コンピュータ可読媒体は、特定のニーズに従って、1つまたは複数のメモリ装置またはチップを含み得る。ソフトウェアは、コア1540、特にその中のプロセッサ（CPU、GPU、FPGAなどを含む）に、RAM 1546に格納されているデータ構造を定義すること、およびソフトウェアで定義された処理に従ってそのようなデータ構造を変更することを含む、ここで説明する特定の処理または特定の処理の特定の部分を実行させることができる。加えて、または代替として、コンピュータシステムは、ハードワイヤードまたは他の方法で回路（例えば、アクセラレータ1544）に具現化された論理の結果として機能を提供することができ、ソフトウェアの代わりに、またはソフトウェアと共に動作して、本明細書に記載の特定の処理または特定の処理の特定の部分を実行することができる。ソフトウェアへの参照はロジックを含むことができ、その逆も適宜可能である。コンピュータ可読媒体への言及は、必要に応じて、実行のためのソフトウェアを記憶する回路（集積回路（IC）など）、実行のための論理を具現化する回路、またはその両方を包含することができる。本開示は、ハードウェアとソフトウェアとの任意の適切な組み合わせを包含する。

本開示はいくつかの例示的な実施形態を説明してきたが、本開示の範囲内にある変更、置換、および様々な代替均等物が存在する。したがって、当業者は、本明細書に明示的に示されていないまたは記載されていないが、本開示の原理を具体化し、したがってその趣旨および範囲内にある多数のシステムおよび方法を考案することができることが理解されよう。

100 通信システム
101 端末
102 端末
103 端末
104 端末
105 通信ネットワーク
200 ストリーミングシステム
201 カメラ
201 ビデオソース
202 エンコーダ
203 キャプチャサブシステム
204 ビデオビットストリーム
205 ストリーミングサーバ
206 ビデオビットストリーム
207 ストリーミングクライアント
208 ビデオビットストリーム
209 ディスプレイ
210 発信ビデオサンプルストリーム
211 ビデオデコーダ
212 ストリーミングクライアント
213 ビデオサンプルストリーム
300 ビデオデコーダ
301 チャネル
302 受信器
303 バッファメモリ、バッファ
304 パーサ
305 逆変換、逆変換ユニット
306 動き補償予測ユニット
307 イントラ予測ユニット、イントラピクチャ予測ユニット
308 参照ピクチャバッファ、参照ピクチャメモリ
309 参照ピクチャ
310 アグリゲータ
311 ループフィルタ、ループフィルタユニット
312 レンダリング装置、ディスプレイ
313 シンボル
400 ビデオコーダ、ビデオエンコーダ
401 ビデオソース
402 エンコーダ、コントローラ
403 ソースコーダ、ビデオコーダ
404 予測器
405 コントローラ、参照ピクチャメモリ、参照ピクチャキャッシュ
406 ローカルビデオデコーダ、ローカルデコーダ
407 コーディングエンジン
408 エントロピーコーダ
409 送信器
410 ビデオシーケンス
411 通信チャネル
557 参照ピクチャメモリ
601 セグメント
602 セグメント
603 セグメント
604 セグメント
605 セグメント
607 第4基準階層
608 基準線、第3基準階層
609 第2基準階層、基準線
610 第1基準階層、基準線
611 ブロックユニット
900 イントラ予測モード
1000 フローチャート
1100 フローチャート
1200 フローチャート、コンピュータシステム
1301 コーディングフロー
1302 デコードフロー
1500 コンピュータシステム、USBポート、アーキテクチャ、コア
1501 キーボード
1502 マウス
1503 トラックパッド
1505 ジョイスティック
1506 マイク
1507 カメラ
1508 スキャナ
1509 スピーカ
1510 タッチスクリーン
1517 グラフィックアダプタ
1522 サムドライブ
1523 ソリッドステートドライブ
1540 コア
1544 ハードウェアアクセラレータ
1546 ランダムアクセスメモリ
1547 コア内部大容量記憶装置
1548 システムバス
1551 周辺バス
1598 通信ネットワーク
1599 インターフェース

Claims (11)

1. 少なくとも1つのプロセッサによって実行されるビデオコーディングのための方法であって、
   ビデオデータを取得するステップと、
   ビデオデータのコーディングユニット（CU）ブロックを取得するステップと、
   前記CUブロックのフラグが所定のフラグ条件に設定されているか否かを判定するステップと、
   前記CUブロックのツリータイプが所定のツリータイプに設定されているか否かを判定するステップと、
   前記CUブロックの前記フラグが前記所定のフラグ条件に設定されているか否か、および前記CUブロックの前記ツリータイプが前記所定のツリータイプに設定されているか否かのいずれかに基づいて、適応色変換（ACT）フラグをシグナリングするか否かを判定するステップと、
   前記ACTフラグがシグナリングされるか否かに基づいて前記ビデオデータをコーディングするステップと、
   を含み、
   変換ユニット（TU）コーディングフラグが両方とも0であるか否か、および前記CUがACTモードでコーディングされているか否かを判定するステップであって、前記TUコーディングフラグは色差チャネルのフラグである、ステップと、
   前記TUコーディングフラグが両方とも0であり、前記CUが前記ACTモードでコーディングされていると判定することに基づいて、輝度のTUコーディングフラグが1であると推論されるべきであると判定するステップと
   をさらに含む、方法。
2. 前記ACTフラグをシグナリングするか否かを判定するステップは、前記CUブロックの前記フラグが前記所定のフラグ条件に設定されているか否か、および前記CUブロックの前記ツリータイプが前記所定のツリータイプに設定されているか否かの両方に基づく、請求項1に記載の方法。
3. 前記所定のツリータイプはシングルツリータイプを示し、前記所定のフラグ条件は、sps＿act＿enabled＿flagが1に等しいことを含む、請求項1から2のうちいずれか一項に記載の方法。
4. 前記ACTフラグをシグナリングするか否かを判定するステップは、前記CUの予測モードがイントラモードであるか否かにかかわらず実施される、請求項1から3のうちいずれか一項に記載の方法。
5. 輝度の前記TUコーディングフラグが1であると推測されるべきであると判定するステップが、前記CUの予測モードがイントラモードであるか否かにかかわらず実施される、請求項1に記載の方法。
6. 前記ビデオデータをコーディングするステップは、輝度の前記TUコーディングフラグが1であると推論されるべきか否かを判定することにさらに基づく、請求項5に記載の方法。
7. 請求項１から６のいずれか一項に記載の方法を行うように構成されたビデオコーディングのための装置。
8. ビデオコーディングのための装置の少なくとも１つのプロセッサに請求項１から６のいずれか一項に記載の方法を実行させるためのコンピュータプログラム。
9. 少なくとも1つのプロセッサによって実行されるビデオ符号化のための方法であって、
   輝度の変換ユニット（TU）コーディングフラグを取得するステップと、
   輝度の前記TUコーディングフラグの値が1である場合、色差チャネルの前記TUコーディングフラグを両方とも0に設定し、コーディングユニット（CU）を適応色変換（ACT）モードでコーディングするステップと、
   輝度の前記TUコーディングフラグを含まないビデオデータをシグナリングするステップと
   を含む、方法。
10. 請求項９に記載の方法を行うように構成されたビデオ符号化のための装置。
11. ビデオ符号化のための装置の少なくとも１つのプロセッサに請求項９に記載の方法を実行させるためのコンピュータプログラム。

Images