ここで、具体的な実装を詳細に参照し、その例が添付の図面に示されている。以下の詳細な説明において、本明細書において提示される主題を理解する助けとするために、多数の非限定的な具体的詳細が記載される。しかしながら、請求項の範囲から逸脱しない限りにおいて様々な代替例が用いられてよく、主題がこれらの具体的詳細なしに実施されてよいことは、当業者には明らかであろう。例えば、本明細書において提示される主題が、デジタルビデオ機能を有する多くのタイプの電子デバイス上で実装され得ることは、当業者には明らかであろう。
図1は、本開示のいくつかの実装に係る、ビデオブロックを並列に符号化および復号するための例示的システム10を示すブロック図である。図1に示されるように、システム10は、後に宛先デバイス14によって復号されるビデオデータを生成および符号化するソースデバイス12を含む。ソースデバイス12および宛先デバイス14は、デスクトップまたはラップトップコンピュータ、タブレットコンピュータ、スマートフォン、セットトップボックス、デジタルテレビ、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイス等を含む多種多様な電子デバイスのいずれかを含んでよい。いくつかの実装において、ソースデバイス12および宛先デバイス14には、無線通信機能が搭載される。
いくつかの実装において、宛先デバイス14は、リンク16を介して復号対象の符号化済みビデオデータを受信してよい。リンク16は、符号化済みビデオデータをソースデバイス12から宛先デバイス14へと移動させることが可能な任意のタイプの通信媒体またはデバイスを含んでよい。一例において、リンク16は、ソースデバイス12が符号化済みビデオデータをリアルタイムで宛先デバイス14に直接伝送することを可能とする通信媒体を含んでよい。符号化済みビデオデータは、無線通信プロトコルなどの通信規格に従って変調され、宛先デバイス14に伝送されてよい。通信媒体は、無線周波数(RF)スペクトルまたは1つまたは複数の物理的伝送線などの任意の無線または有線通信媒体を含んでよい。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどのパケットベースのネットワークの一部を形成してよい。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス12から宛先デバイス14への通信を促進するのに有用であり得る任意の他の機器を含んでよい。
いくつかの他の実装において、符号化済みビデオデータは、出力インターフェース22からストレージデバイス32に伝送されてよい。その後、ストレージデバイス32における符号化済みビデオデータは、入力インターフェース28を介して宛先デバイス14によってアクセスされてよい。ストレージデバイス32は、ハード・ドライブ、Blu-rayディスク、DVD、CD-ROM、フラッシュメモリ、揮発性または不揮発性メモリ、または符号化済みビデオデータを格納するための任意の他の適当なデジタル記憶媒体などの、種々の分散型のまたはローカルでアクセスされるデータ記憶媒体のいずれかを含んでよい。さらなる例において、ストレージデバイス32は、ソースデバイス12によって生成される符号化済みビデオデータを保持し得るファイルサーバまたは別の中間ストレージデバイスに対応してよい。宛先デバイス14は、格納されたビデオデータに対して、ストレージデバイス32からストリーミングまたはダウンロードを介してアクセスしてよい。ファイルサーバは、符号化済みビデオデータを格納し符号化済みビデオデータを宛先デバイス14に伝送することが可能な任意のタイプのコンピュータであってよい。例示的なファイルサーバは、(例えばウェブサイト用の)ウェブ・サーバ、FTPサーバ、ネットワーク・アタッチド・ストレージ(NAS)デバイス、またはローカル・ディスク・ドライブを含む。宛先デバイス14は、ファイルサーバに格納された符号化済みビデオデータにアクセスするのに適当な無線チャネル(例えばWi-Fi接続)、有線接続(例えばDSL、ケーブル・モデム等)、またはそれら両方の組み合わせを含む任意の標準的なデータ接続を通して符号化済みビデオデータにアクセスしてよい。ストレージデバイス32からの符号化済みビデオデータの伝送は、ストリーミング伝送、ダウンロード伝送、またはそれら両方の組み合わせであってよい。
図1に示されるように、ソースデバイス12は、ビデオソース18、ビデオエンコーダ20および出力インターフェース22を含む。ビデオソース18は、例えばビデオカメラのようなビデオキャプチャデバイス、以前にキャプチャされたビデオを含むビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェース、および/またはソースビデオとしてのコンピュータグラフィクスデータを生成するためのコンピュータグラフィクスシステム、またはそのようなソースの組み合わせなどのソースを含んでよい。一例として、ビデオソース18が警備監視システムのビデオカメラである場合、ソースデバイス12および宛先デバイス14は、カメラフォンまたはビデオフォンを形成してよい。しかしながら、本出願において説明される実装は、一般にビデオ符号化に適用可能であってよく、無線および/または有線のアプリケーションに適用されてよい。
キャプチャされ、予めキャプチャされ、またはコンピュータで生成されたビデオは、ビデオエンコーダ20によって符号化されてよい。符号化済みビデオデータは、ソースデバイス12の出力インターフェース22を介して宛先デバイス14に直接伝送されてよい。符号化済みビデオデータはさらに(または代替的に)、復号および/または再生のために宛先デバイス14または他のデバイスによって後にアクセスするために、ストレージデバイス32に格納されてよい。出力インターフェース22は、モデムおよび/または送信機をさらに含んでよい。
宛先デバイス14は、入力インターフェース28、ビデオデコーダ30、およびディスプレイデバイス34を含む。入力インターフェース28は、受信機および/またはモデムを含み、リンク16を介して符号化済みビデオデータを受信してよい。リンク16を介して通信され、またはストレージデバイス32上で提供される符号化済みビデオデータは、ビデオデータを復号する際におけるビデオデコーダ30による使用のためにビデオエンコーダ20によって生成される種々の構文要素を含んでよい。そのような構文要素は、通信媒体上で伝送され、記憶媒体に格納され、またはファイルサーバに格納される符号化済みビデオデータ内に含まれてよい。
いくつかの実装において、宛先デバイス14は、一体化されたディスプレイデバイスおよび宛先デバイス14と通信するように構成された外部ディスプレイデバイスであり得るディスプレイデバイス34を含んでよい。ディスプレイデバイス34は、復号されたビデオデータをユーザに表示し、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなどの種々のディスプレイデバイスのいずれかを含んでよい。
ビデオエンコーダ20およびビデオデコーダ30は、VVC、HEVC、MPEG-4、Part 10、Advanced Video Coding(AVC)、またはそのような規格の拡張版などの独自規格または産業規格に従って動作してよい。本出願は、特定のビデオ符号化/復号規格に限定されず、他のビデオ符号化/復号規格に適用可能であってよいことが理解されるべきである。ソースデバイス12のビデオエンコーダ20は、これらの現在または将来の規格のいずれかに従ってビデオデータを符号化するように構成されてよいことが一般に想定される。同様に、宛先デバイス14のビデオデコーダ30は、これらの現在または将来の規格のいずれかに従ってビデオデータを復号するように構成されてよいこともまた、一般に想定される。
ビデオエンコーダ20およびビデオデコーダ30は各々、1つまたは複数のマイクロプロセッサ、デジタル・シグナル・プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールド・プログラマブル・ゲート・アレイ(FPGA)、ディスクリート・ロジック、ソフトウェア、ハードウェア、ファームウェアまたはそれらの任意の組み合わせなどの種々の適当なエンコーダ回路のいずれかとして実装されてよい。部分的にソフトウェアで実装される場合、電子デバイスが、当該ソフトウェアのための命令を適当な非一時的コンピュータ可読媒体に格納し、本開示において開示されるビデオ符号化/復号動作を行うよう、1つまたは複数のプロセッサを用いてそれらの命令をハードウェアで実行してよい。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、そのいずれも、それぞれのデバイスにおいて、組み合わされたエンコーダ/デコーダ(CODEC)の一部として一体化されてよい。
図2は、本出願において説明されるいくつかの実装に係る例示的なビデオエンコーダ20を示すブロック図である。ビデオエンコーダ20は、ビデオフレーム内のビデオブロックのイントラおよびインター予測符号化を行ってよい。イントラ予測符号化は、所与のビデオフレームまたはピクチャ内のビデオデータにおける空間的冗長性を低減または除去するための空間的予測に依拠する。インター予測符号化は、ビデオシーケンスの隣接するビデオフレームまたはピクチャ内のビデオデータにおける時間的冗長性を低減または除去するための時間的予測に依拠する。
図2に示されるように、ビデオエンコーダ20は、ビデオデータメモリ40、予測処理ユニット41、復号化ピクチャバッファ(DPB)64、加算器50、変換処理ユニット52、量子化ユニット54、およびエントロピー符号化ユニット56を含む。予測処理ユニット41は、動き推定ユニット42、動き補償ユニット44、区分ユニット45、イントラ予測処理ユニット46、およびイントラブロックコピー(BC)ユニット48をさらに含む。いくつかの実装において、ビデオエンコーダ20はまた、ビデオブロック再構成のための逆量子化ユニット58、逆変換処理ユニット60、および加算器62を含む。再構成されたビデオからブロック歪みアーチファクトを除去するようブロック境界をフィルタリングするために、デブロッキングフィルタ(不図示)が加算器62とDPB 64との間に配置されてよい。加算器62の出力をフィルタリングするために、デブロッキングフィルタに加えてループ内フィルタ(不図示)が用いられてもよい。ビデオエンコーダ20は、固定のまたはプログラミング可能なハードウェアユニットの形態を取ってもよく、または、例示される固定のまたはプログラミング可能なハードウェアユニットのうちの1つまたは複数の間で分割されてもよい。
ビデオデータメモリ40は、ビデオエンコーダ20の構成要素によって符号化されるビデオデータを格納してよい。ビデオデータメモリ40におけるビデオデータは、例えばビデオソース18から得られてよい。DPB 64は、(例えばイントラまたはインター予測符号化モードで)ビデオエンコーダ20によってビデオデータを符号化する際に用いるための参照ビデオデータを格納するバッファである。ビデオデータメモリ40およびDPB 64は、種々のメモリデバイスのいずれかによって形成されてよい。様々な例において、ビデオデータメモリ40は、ビデオエンコーダ20の他の構成要素と同一チップ上、またはそれらの構成要素に対してチップ外であってよい。
図2に示されるように、ビデオデータを受信した後、予測処理ユニット41内の区分ユニット45は、ビデオデータをビデオブロックに区分する。この区分は、ビデオデータに関連付けられる四分木構造などの予め定められた分割構造に従って、ビデオフレームをスライス、タイル、または他のより大きい符号化ユニット(CU)に区分することを含んでもよい。ビデオフレームは、複数のビデオブロック(またはタイルと称されるビデオブロックのセット)に分割されてよい。予測処理ユニット41は、誤り結果(例えば符号化率および歪みレベル)に基づいて、現在のビデオブロックについて、複数のイントラ予測符号化モードのうちの1つ、または複数のインター予測符号化モードのうちの1つなどの、複数の可能な予測符号化モードのうちの1つを選択してよい。予測処理ユニット41は、結果として得られるイントラまたはインター予測符号化されたブロックを、残差ブロックを生成するために加算器50に、また、後に参照フレームの一部として用いるために符号化済みブロックを再構成するために加算器62に提供してよい。予測処理ユニット41はまた、動きベクトル、イントラモード・インジケータ、区分情報、および他のそのような構文情報などの構文要素を、エントロピー符号化ユニット56に提供する。
現在のビデオブロックについて適切なイントラ予測符号化モードを選択するべく、予測処理ユニット41内のイントラ予測処理ユニット46は、空間的予測を提供するために、符号化対象の現在のブロックと同じフレームにおける1つまたは複数の隣接ブロックに対して現在のビデオブロックのイントラ予測符号化を行ってよい。予測処理ユニット41内の動き推定ユニット42および動き補償ユニット44は、時間的予測を提供するために、1つまたは複数の参照フレームにおける1つまたは複数の予測ブロックに対して現在のビデオブロックのインター予測符号化を行う。ビデオエンコーダ20は、例えばビデオデータの各ブロックについて適切な符号化モードを選択するために、複数の符号化パスを行ってよい。
いくつかの実装において、動き推定ユニット42は、ビデオフレームのシーケンス内の予め決定されたパターンに従って、参照ビデオフレーム内の予測ブロックに対する現在のビデオフレーム内のビデオブロックの予測ユニット(PU)の変位を示す動きベクトルを生成することにより、現在のビデオフレームについてのインター予測モードを決定する。動き推定ユニット42によって行われる動き推定は、ビデオブロックについての動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、例えば、現在のフレーム(または他の符号化単位)内で符号化されている現在のブロックに対する参照フレーム(または他の符号化単位)内の予測ブロックに対する現在のビデオフレームまたはピクチャ内のビデオブロックのPUの変位を示してよい。予め決定されたパターンは、シーケンスにおけるビデオフレームをPフレームまたはBフレームとして指定してよい。イントラBCユニット48は、インター予測のための動き推定ユニット42による動きベクトルの決定と同様の方式で、イントラBC符号化のために例えばブロックベクトルのようなベクトルを決定してよく、または、動き推定ユニット42を利用してブロックベクトルを決定してよい。
予測ブロックは、差分絶対値和(SAD)、差分二乗和(SSD)、または他の差分メトリックによって決定され得る画素差に関して、符号化対象のビデオブロックのPUと密接に合致するものとみなされる参照フレームのブロックである。いくつかの実装において、ビデオエンコーダ20は、DPB 64に格納された参照フレームのサブ整数画素位置についての値を算出してよい。例えば、ビデオエンコーダ20は、参照フレームの4分の1画素位置、8分の1画素位置、または他の分数画素位置の値を補間してよい。したがって、動き推定ユニット42は、フル画素位置および分数画素位置に対して動き探索を行い、分数画素精度と共に動きベクトルを出力してよい。
動き推定ユニット42は、第1の参照フレームリスト(リスト0)または第2の参照フレームリスト(リスト1)(その各々が、DPB 64に格納された1つまたは複数の参照フレームを特定する)から選択される参照フレームの予測ブロックの位置とPUの位置を比較することにより、インター予測符号化されたフレームにおけるビデオブロックのPUについての動きベクトルを算出する。動き推定ユニット42は、算出された動きベクトルを動き補償ユニット44に、次いでエントロピー符号化ユニット56に送信する。
動き補償ユニット44によって行われる動き補償は、動き推定ユニット42によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成することを伴ってよい。現在のビデオブロックのPUについての動きベクトルを受信すると、動き補償ユニット44は、動きベクトルが参照フレームリストのうちの1つにおいて指し示す予測ブロックの位置を特定し、DPB 64から予測ブロックを取得し、予測ブロックを加算器50に転送してよい。加算器50は次いで、動き補償ユニット44によって提供された予測ブロックの画素値を、符号化されている現在のビデオブロックの画素値から減算することにより、画素差分値の残差ビデオブロックを形成する。残差ビデオブロックを形成する画素差分値は、輝度または彩度の差分成分またはその両方を含んでよい。動き補償ユニット44はまた、ビデオフレームのビデオブロックを復号する際におけるビデオデコーダ30による使用のために、ビデオフレームのビデオブロックに関連付けられる構文要素を生成してよい。構文要素は、例えば、予測ブロックを特定するために用いられる動きベクトルを定義する構文要素、予測モードを示す任意のフラグ、または本明細書に説明される任意の他の構文情報を含んでよい。動き推定ユニット42および動き補償ユニット44は、高度に一体化されてよいが、概念的な目的で別個に示されていることに留意されたい。
いくつかの実装において、イントラBCユニット48は、動き推定ユニット42および動き補償ユニット44に関連して上記で説明されているものと同様の方式で、ベクトルを生成し予測ブロックをフェッチしてよいが、予測ブロックは、符号化されている現在のブロックと同じフレームにおけるものであり、ベクトルは、動きベクトルとは対照的にブロックベクトルと称される。特に、イントラBCユニット48は、現在のブロックを符号化するために用いるべきイントラ予測モードを決定してよい。いくつかの例において、イントラBCユニット48は、例えば別個の符号化パスの間に、様々なイントラ予測モードを用いて現在のブロックを符号化し、レート歪み解析によってそれらの性能を試験してよい。次に、イントラBCユニット48は、様々な試験されるイントラ予測モードの中から、用いるべき適切なイントラ予測モードを選択し、それに応じてイントラモード・インジケータを生成してよい。例えば、イントラBCユニット48は、様々な試験されるイントラ予測モードについてレート歪み解析を用いてレート歪み値を算出し、試験モードのうち最良のレート歪み特性を有するイントラ予測モードを、用いるべき適切なイントラ予測モードとして選択してよい。レート歪み解析は、一般に、符号化済みブロックを作成するために用いられるビットレート(すなわちビットの数)と共に、符号化済みブロックと、符号化済みブロックを作成するように符号化された元の未符号化ブロックとの間の歪み(または誤差)の量を決定する。イントラBCユニット48は、どのイントラ予測モードがブロックについての最良のレート歪み値を呈するかを決定するために、様々な符号化済みブロックについての歪みおよびレートからの比を算出してよい。
他の例において、イントラBCユニット48は、本明細書において説明される実装に従って、イントラBC予測のためのそのような機能を行うために、全体的または部分的に動き推定ユニット42および動き補償ユニット44を用いてよい。いずれの場合においても、イントラブロックコピーについて、予測ブロックは、差分絶対値和(SAD)、差分二乗和(SSD)、または他の差分メトリックによって決定され得る画素差に関して、符号化対象のブロックと密接に合致するものとみなされるブロックであってよく、予測ブロックの特定は、サブ整数画素位置についての値の算出を含んでよい。
予測ブロックがイントラ予測による同じフレームからのものであるか、またはインター予測による異なるフレームからのものであるかに関わらず、ビデオエンコーダ20は、符号化されている現在のビデオブロックの画素値から予測ブロックの画素値を減算することにより、残差ビデオブロックを形成してよく、これにより画素差分値を形成する。残差ビデオブロックを形成する画素差分値は、輝度および彩度の両成分の差分を含んでよい。
イントラ予測処理ユニット46は、上述のように、動き推定ユニット42および動き補償ユニット44によって行われるインター予測、またはイントラBCユニット48によって行われるイントラブロックコピー予測の代替として、現在のビデオブロックをイントラ予測してよい。特に、イントラ予測処理ユニット46は、現在のブロックを符号化するために用いるべきイントラ予測モードを決定してよい。これを行うために、イントラ予測処理ユニット46は、例えば別個の符号化パスの間に、様々なイントラ予測モードを用いて現在のブロックを符号化してよく、イントラ予測処理ユニット46(またはいくつかの例においてはモード選択ユニット)は、試験されたイントラ予測モードから、用いるべき適切なイントラ予測モードを選択してよい。イントラ予測処理ユニット46は、そのブロックについての選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット56に提供してよい。エントロピー符号化ユニット56は、選択されたイントラ予測モードを示す情報をビットストリームにおいて符号化してよい。
予測処理ユニット41がインター予測またはイントラ予測のいずれかを介して現在のビデオブロックについての予測ブロックを決定した後、加算器50は現在のビデオブロックから予測ブロックを減算することにより残差ビデオブロックを形成する。残差ブロックにおける残差ビデオデータは、1つまたは複数の変換ユニット(TU)に含まれてよく、変換処理ユニット52に提供される。変換処理ユニット52は、離散コサイン変換(DCT)または概念的に類似の変換などの変換を用いて、残差ビデオデータを残差変換係数に変換する。
変換処理ユニット52は、結果として得られた変換係数を量子化ユニット54に送信してよい。量子化ユニット54は、ビット・レートをさらに低減するために、変換係数を量子化する。量子化プロセスは、係数の一部または全てに関連付けられるビット深度を低減してもよい。量子化度は、量子化パラメータを調整することにより修正されてよい。いくつかの例において、量子化ユニット54は次いで、量子化された変換係数を含む行列の走査を行ってよい。代替的に、エントロピー符号化ユニット56がこの走査を行ってよい。
量子化に続き、エントロピー符号化ユニット56は、例えばコンテキスト適応可変長符号化(CAVLC)、コンテキスト適応バイナリ算術符号化(CABAC)、シンタックスベースのコンテキスト適応バイナリ算術符号化(SBAC)、確率区間区分エントロピー(PIPE)符号化または別のエントロピー符号化方法または技法を用いて、量子化された変換係数をビデオビットストリームにエントロピー符号化する。符号化済みビットストリームは次いで、ビデオデコーダ30に伝送され、または、後のビデオデコーダ30への伝送またはビデオデコーダ30による取得のためにストレージデバイス32にアーカイブされてよい。エントロピー符号化ユニット56は、符号化されている現在のビデオフレームについての動きベクトルおよび他の構文要素をエントロピー符号化してもよい。
逆量子化ユニット58および逆変換処理ユニット60は、それぞれ逆量子化および逆変換を適用することで、他のビデオブロックの予測のための参照ブロックを生成するために、残差ビデオブロックを画素ドメインに再構成する。上記のように、動き補償ユニット44は、DPB 64に格納されたフレームの1つまたは複数の参照ブロックから、動き補償された予測ブロックを生成してよい。動き補償ユニット44は、動き推定に用いるためのサブ整数画素値を算出するために、予測ブロックに1つまたは複数の補間フィルタを適用してもよい。
加算器62は、DPB 64への格納のために参照ブロックを作成するために、再構成された残差ブロックを、動き補償ユニット44によって作成された動き補償された予測ブロックに加算する。参照ブロックは次いで、イントラBCユニット48、動き推定ユニット42および動き補償ユニット44によって、後続のビデオフレームにおける別のビデオブロックをインター予測するための予測ブロックとして用いられてよい。
図3は、本出願のいくつかの実装に係る例示的なビデオデコーダ30を示すブロック図である。ビデオデコーダ30は、ビデオデータメモリ79、エントロピー復号ユニット80、予測処理ユニット81、逆量子化ユニット86、逆変換処理ユニット88、加算器90、およびDPB 92を含む。予測処理ユニット81は、動き補償ユニット82、イントラ予測処理ユニット84、およびイントラBCユニット85をさらに含む。ビデオデコーダ30は、図2に関連してビデオエンコーダ20に関して上記で説明されている符号化プロセスと概して反対の復号プロセスを行ってよい。例えば、動き補償ユニット82は、エントロピー復号ユニット80から受信された動きベクトルに基づいて予測データを生成してよく、一方でイントラ予測ユニット84は、エントロピー復号ユニット80から受信されたイントラ予測モード・インジケータに基づいて予測データを生成してよい。
いくつかの例において、ビデオデコーダ30のあるユニットが、本出願の実装を実行することを課されてよい。また、いくつかの例において、本開示の実装は、ビデオデコーダ30の1つまたは複数のユニットの間で分割されてよい。例えば、イントラBCユニット85は、単独で、または動き補償ユニット82、イントラ予測処理ユニット84、およびエントロピー復号ユニット80などのビデオデコーダ30の他のユニットとの組み合わせで、本出願の実装を行ってよい。いくつかの例において、ビデオデコーダ30は、イントラBCユニット85を含まなくてよく、イントラBCユニット85の機能は、動き補償ユニット82などの予測処理ユニット81の他の構成要素によって行われてよい。
ビデオデータメモリ79は、ビデオデコーダ30の他の構成要素によって復号される、符号化済みビデオビットストリームなどのビデオデータを格納してよい。ビデオデータメモリ79に格納されたビデオデータは、例えば、ストレージデバイス32から、カメラなどのローカルのビデオソースから、ビデオデータの有線または無線ネットワーク通信を介して、または物理的データ記憶媒体(例えばフラッシュドライブまたはハードディスク)にアクセスすることにより、得られてよい。ビデオデータメモリ79は、符号化済みビデオビットストリームからの符号化済みビデオデータを格納する符号化ピクチャバッファ(CPB)を含んでよい。ビデオデコーダ30の復号化ピクチャバッファ(DPB)92は、(例えばイントラまたはインター予測符号化モードで)ビデオデコーダ30によってビデオデータを復号する際に用いるための参照ビデオデータを格納する。ビデオデータメモリ79およびDPB 92は、シンクロナスDRAM(SDRAM)を含むダイナミック・ランダム・アクセス・メモリ(DRAM)、磁気抵抗RAM(MRAM)、抵抗変化RAM(RRAM)、または他のタイプのメモリデバイスなどの種々のメモリデバイスのいずれかによって形成されてよい。例示の目的で、ビデオデータメモリ79およびDPB 92は、図3においてビデオデコーダ30の2つの別個の構成要素として図示されている。しかしながら、ビデオデータメモリ79およびDPB 92が同じメモリデバイスまたは別個のメモリデバイスによって提供されてよいことは、当業者には明らかであろう。いくつかの例において、ビデオデータメモリ79は、ビデオデコーダ30の他の構成要素と同一チップ上、またはそれらの構成要素に対してチップ外であってよい。
復号プロセスの間、ビデオデコーダ30は、符号化済みビデオフレームのビデオブロックおよび関連付けられる構文要素を表す符号化済みビデオビットストリームを受信する。ビデオデコーダ30は、ビデオフレームのレベルおよび/またはビデオブロックのレベルで構文要素を受信してよい。ビデオデコーダ30のエントロピー復号ユニット80は、ビットストリームをエントロピー復号して、量子化係数、動きベクトルまたはイントラ予測モード・インジケータ、および他の構文要素を生成する。エントロピー復号ユニット80は次いで、動きベクトルおよび他の構文要素を予測処理ユニット81に転送する。
ビデオフレームが、イントラ予測符号化された(I)フレームとして、または他のタイプのフレームにおけるイントラ符号化された予測ブロックについて符号化される場合、予測処理ユニット81のイントラ予測処理ユニット84は、信号伝送されるイントラ予測モードと、現在のフレームの以前に復号されたブロックからの参照データとに基づいて、現在のビデオフレームのビデオブロックについての予測データを生成してよい。
ビデオフレームが、インター予測符号化された(すなわちBまたはP)フレームとして符号化される場合、予測処理ユニット81の動き補償ユニット82は、エントロピー復号ユニット80から受信された動きベクトルおよび他の構文要素に基づいて、現在のビデオフレームのビデオブロックについての1つまたは複数の予測ブロックを作成する。予測ブロックの各々は、参照フレームリストのうちの1つにおける参照フレームから作成されてよい。ビデオデコーダ30は、DPB 92に格納された参照フレームに基づいて、デフォルトの構成技法を用いて、参照フレームリスト、リスト0およびリスト1を構成してよい。
いくつかの例において、ビデオブロックが本明細書において説明されるイントラBCモードに従って符号化される場合、予測処理ユニット81のイントラBCユニット85は、エントロピー復号ユニット80から受信されたブロックベクトルおよび他の構文要素に基づいて、現在のビデオブロックについての予測ブロックを作成する。予測ブロックは、ビデオエンコーダ20によって定められる現在のビデオブロックと同じピクチャの再構成された領域内のものであってよい。
動き補償ユニット82および/またはイントラBCユニット85は、動きベクトルおよび他の構文要素を構文解析することにより、現在のビデオフレームのビデオブロックについての予測情報を決定し、次いで、予測情報を用いて、復号されている現在のビデオブロックについての予測ブロックを作成する。例えば、動き補償ユニット82は、受信された構文要素のいくつかを用いて、ビデオフレームのビデオブロックを符号化するために用いられる予測モード(例えばイントラまたはインター予測)、インター予測フレーム・タイプ(例えばBまたはP)、フレームについての参照フレームリストのうちの1つまたは複数についての構成情報、フレームのインター予測符号化された各ビデオブロックについての動きベクトル、フレームのインター予測符号化された各ビデオブロックについてのインター予測ステータス、現在のビデオフレームにおけるビデオブロックを復号するための他の情報を決定する。
同様に、イントラBCユニット85は、例えばフラグのような受信された構文要素のいくつかを用いて、現在のビデオブロックがイントラBCモードを用いて予測されたこと、フレームのどのビデオブロックが再構成された領域内にあり、DPB 92に格納されているはずであるかについての構成情報、フレームのイントラBC予測された各ビデオブロックについてのブロックベクトル、フレームのイントラBC予測された各ビデオブロックについてのイントラBC予測ステータス、および現在のビデオフレームにおけるビデオブロックを復号するための他の情報を決定してよい。
動き補償ユニット82はまた、ビデオブロックの符号化の間にビデオエンコーダ20によって用いられるように、補間フィルタを用いて補間を行って、参照ブロックのサブ整数画素についての補間された値を算出してよい。この場合、動き補償ユニット82は、受信された構文要素からビデオエンコーダ20によって用いられる補間フィルタを決定し、補間フィルタを用いて予測ブロックを作成してよい。
逆量子化ユニット86は、ビデオフレームにおける各ビデオブロックについてビデオエンコーダ20によって算出されたものと同じ量子化パラメータを用いて、ビットストリームにおいて提供され、エントロピー復号ユニット80によってエントロピー復号された量子化された変換係数を逆量子化して、量子化度を決定する。逆変換処理ユニット88は、残差ブロックを画素ドメインにおいて再構成するために、例えば逆DCT、逆整数変換、または概念的に類似の逆変換プロセスのような逆変換を変換係数に適用する。
動き補償ユニット82またはイントラBCユニット85が、ベクトルおよび他の構文要素に基づいて、現在のビデオブロックについての予測ブロックを生成した後、加算器90は、逆変換処理ユニット88からの残差ブロックと、動き補償ユニット82およびイントラBCユニット85によって生成された対応する予測ブロックとを加算することにより、現在のビデオブロックについての復号済みビデオブロックを再構成する。復号済みビデオブロックをさらに処理するために、ループ内フィルタ(不図示)が加算器90とDPB 92との間に配置されてよい。所与のフレームにおける復号済みビデオブロックは、次いで、次のビデオブロックの後続の動き補償に用いられる参照フレームを格納するDPB 92に格納される。DPB 92、またはDPB 92とは別個のメモリデバイスは、図1のディスプレイデバイス34などのディスプレイデバイス上における後の提示のために、復号済みビデオを格納してもよい。
典型的なビデオ符号化プロセスにおいて、ビデオシーケンスは典型的に、フレームまたはピクチャの順序付けられたセットを含む。各フレームは、SL、SCb、およびSCrと表記される3つのサンプル配列を含んでよい。SLは、輝度サンプルの2次元配列である。SCbは、Cb彩度サンプルの2次元配列である。SCrは、Cr彩度サンプルの2次元配列である。他の事例において、フレームは、単色であってよく、したがって輝度サンプルの1つの2次元配列のみを含む。
図4Aに示されるように、ビデオエンコーダ20(またはより具体的には区分ユニット45)は、まずフレームを符号化ツリーユニット(CTU)のセットに区分することにより、フレームの符号化表現を生成する。ビデオフレームは、左から右へ、上から下へのラスター・スキャン順に連続して順序付けられた整数のCTUを含んでよい。各CTUは、最も大きい論理的符号化ユニットであり、ビデオシーケンスにおける全てのCTUが128×128、64×64、32×32、および16×16のいずれかの同じサイズを有するように、CTUの幅および高さが、シーケンスパラメータセットにおいてビデオエンコーダ20によって信号伝送される。しかしながら、本出願は、必ずしも特定のサイズに限定されないことが留意されるべきである。図4Bに示されるように、各CTUは、輝度サンプルの1つの符号化ツリーブロック(CTB)と、彩度サンプルの2つの対応する符号化ツリーブロックと、符号化ツリーブロックのサンプルを符号化するために用いられる構文要素とを含んでよい。構文要素は、インターまたはイントラ予測、イントラ予測モード、動きベクトル、および他のパラメータを含む、符号化される画素ブロックの異なるタイプの単位の特性、および、ビデオシーケンスがどのようにビデオデコーダ30において再構成され得るかを記述する。単色ピクチャ、または3つの別個の色平面を有するピクチャにおいて、CTUは、単一の符号化ツリーブロックと、符号化ツリーブロックのサンプルを符号化するために用いられる構文要素とを含んでよい。符号化ツリーブロックは、サンプルのN×Nブロックであってよい。
より良好な性能を実現するために、ビデオエンコーダ20は、CTUの符号化ツリーブロックに対して二分木区分、三分木区分、四分木区分、または両方の組み合わせなどの分木区分を再帰的に行い、CTUをより小さい符号化ユニット(CU)に分割してよい。図4Cに図示されるように、まず64×64のCTU 400が、各々32×32のブロック・サイズを有する4つのより小さいCUに分割される。4つのより小さいCUのうち、CU 410およびCU 420が、各々、ブロック・サイズ16×16の4つのCUに分割される。2つの16×16のCU 430および440は、各々、ブロック・サイズ8×8の4つのCUにさらに分割される。図4Dは、図4Cに図示されるようなCTU 400の区分プロセスの最終結果を示す四分木データ構造を図示し、四分木の各葉ノードは、それぞれのサイズが32×32から8×8までの範囲である1つのCUに対応する。図4Bに図示されるCTUと同様、各CUは、同じサイズのフレームの、輝度サンプルの符号化ブロック(CB)および彩度サンプルの2つの対応する符号化ブロックと、符号化ブロックのサンプルを符号化するために用いられる構文要素とを含んでよい。単色ピクチャ、または3つの別個の色平面を有するピクチャにおいて、CUは、単一の符号化ブロックと、符号化ブロックのサンプルを符号化するために用いられる構文構造とを含んでよい。図4Cおよび図4Dに図示される四分木区分は、単に例示を目的としたものであり、四分木/三分木/二分木区分に基づいて様々な局所的特性に適合するように、1つのCTUがCUに分けられ得ることが、留意されるべきである。多分木構造においては、1つのCTUが、四分木構造によって区分され、四分木の各葉CUが、二分木および三分木構造によってさらに区分され得る。図4Eに示されるように、5つの区分タイプ、すなわち四区分、水平二区分、垂直二区分、水平三区分、および垂直三区分が存在する。
いくつかの実装において、ビデオエンコーダ20は、CUの符号化ブロックを1つまたは複数のM×N予測ブロック(PB)にさらに区分してよい。予測ブロックは、インターまたはイントラの同じ予測が適用されるサンプルの矩形(正方形または非正方形)ブロックである。CUの予測ユニット(PU)は、輝度サンプルの予測ブロックと、彩度サンプルの2つの対応する予測ブロックと、予測ブロックを予測するために用いられる構文要素とを含んでよい。単色ピクチャ、または3つの別個の色平面を有するピクチャにおいて、PUは、単一の予測ブロックと、予測ブロックを予測するために用いられる構文構造とを含んでよい。ビデオエンコーダ20は、CUの各PUの輝度、Cb、およびCr予測ブロックについての予測輝度、Cb、およびCrブロックを生成してよい。
ビデオエンコーダ20は、イントラ予測またはインター予測を用いて、PUについての予測ブロックを生成してよい。ビデオエンコーダ20がイントラ予測を用いてPUについての予測ブロックを生成する場合、ビデオエンコーダ20は、PUに関連付けられたフレームの復号されたサンプルに基づいて、PUの予測ブロックを生成してよい。ビデオエンコーダ20がインター予測を用いてPUについての予測ブロックを生成する場合、ビデオエンコーダ20は、PUに関連付けられたフレーム以外の1つまたは複数のフレームの復号されたサンプルに基づいて、PUの予測ブロックを生成してよい。
ビデオエンコーダ20がCUの1つまたは複数のPUについての予測輝度、Cb、およびCrブロックを生成した後、ビデオエンコーダ20は、CUの輝度残差ブロックにおける各サンプルが、CUの予測輝度ブロックのうちの1つにおける輝度サンプルと、CUの元の輝度符号化ブロックにおける対応するサンプルとの間の差を示すように、CUの予測輝度ブロックをその元の輝度符号化ブロックから減算することにより、CUについての輝度残差ブロックを生成してよい。同様に、ビデオエンコーダ20は、それぞれ、CUのCb残差ブロックにおける各サンプルが、CUの予測Cbブロックのうちの1つにおけるCbサンプルと、CUの元のCb符号化ブロックにおける対応するサンプルとの間の差を示し、CUのCr残差ブロックにおける各サンプルが、CUの予測Crブロックのうちの1つにおけるCrサンプルと、CUの元のCr符号化ブロックにおける対応するサンプルとの間の差を示し得るように、CUについてのCb残差ブロックおよびCr残差ブロックを生成してよい。
さらに、図4Cに例示されるように、ビデオエンコーダ20は、四分木区分を用いて、CUの輝度、Cb、およびCr残差ブロックを1つまたは複数の輝度、Cb、およびCr変換ブロックに分解してよい。変換ブロックは、同じ変換が適用されるサンプルの矩形(正方形または非正方形)ブロックである。CUの変換ユニット(TU)は、輝度サンプルの変換ブロックと、彩度サンプルの2つの対応する変換ブロックと、変換ブロックサンプルを変換するために用いられる構文要素とを含んでよい。よって、CUの各TUは、輝度変換ブロック、Cb変換ブロック、およびCr変換ブロックに関連付けられてよい。いくつかの例において、TUに関連付けられた輝度変換ブロックは、CUの輝度残差ブロックのサブブロックであってよい。Cb変換ブロックは、CUのCb残差ブロックのサブブロックであってよい。Cr変換ブロックは、CUのCr残差ブロックのサブブロックであってよい。単色ピクチャ、または3つの別個の色平面を有するピクチャにおいて、TUは、単一の変換ブロックと、変換ブロックのサンプルを変換するために用いられる構文構造とを含んでよい。
ビデオエンコーダ20は、1つまたは複数の変換をTUの輝度変換ブロックに適用して、TUについての輝度係数ブロックを生成してよい。係数ブロックは、変換係数の2次元配列であってよい。変換係数は、スカラ量であってよい。ビデオエンコーダ20は、1つまたは複数の変換をTUのCb変換ブロックに適用して、TUについてのCb係数ブロックを生成してよい。ビデオエンコーダ20は、1つまたは複数の変換をTUのCr変換ブロックに適用して、TUについてのCr係数ブロックを生成してよい。
係数ブロック(例えば輝度係数ブロック、Cb係数ブロック、またはCr係数ブロック)を生成した後、ビデオエンコーダ20は、係数ブロックを量子化してよい。量子化は、一般に、可能な場合に変換係数を表すために用いられるデータの量を低減することで、さらなる圧縮を提供するために、変換係数が量子化されるプロセスを指す。ビデオエンコーダ20が係数ブロックを量子化した後、ビデオエンコーダ20は、量子化された変換係数を示す構文要素をエントロピー符号化してよい。例えば、ビデオエンコーダ20は、量子化された変換係数を示す構文要素に対してコンテキスト適応バイナリ算術符号化(CABAC)を行ってよい。最後に、ビデオエンコーダ20は、ストレージデバイス32に保存されるか、または宛先デバイス14に伝送される、符号化されたフレームおよび関連付けられたデータの表現を形成するビット系列を含むビットストリームを出力してよい。
ビデオエンコーダ20によって生成されたビットストリームを受信した後、ビデオデコーダ30は、ビットストリームを構文解析して、ビットストリームから構文要素を得てよい。ビデオデコーダ30は、ビットストリームから得られた構文要素に少なくとも部分的に基づいて、ビデオデータのフレームを再構成してよい。ビデオデータを再構成するプロセスは、ビデオエンコーダ20によって行われる符号化プロセスと概して反対である。例えば、ビデオデコーダ30は、現在のCUのTUに関連付けられた係数ブロックを逆変換して、現在のCUのTUに関連付けられた残差ブロックを再構成してよい。ビデオデコーダ30はまた、現在のCUのPUについての予測ブロックのサンプルを、現在のCUのTUの変換ブロックの対応するサンプルに加算することにより、現在のCUの符号化ブロックを再構成する。フレームの各CUについての符号化ブロックを再構成した後、ビデオデコーダ30は、フレームを再構成してよい。
上記のように、ビデオ符号化は、主に2つのモード、すなわちフレーム内予測(またはイントラ予測)およびフレーム間予測(またはインター予測)を用いて、ビデオ圧縮を実現する。パレットベース符号化は、多くのビデオ符号化規格によって採用されている別の符号化方式である。スクリーン生成されたコンテンツの符号化に特に適当であり得るパレットベース符号化においては、ビデオ符号器(例えばビデオエンコーダ20またはビデオデコーダ30)が、所与のブロックのビデオデータを表す色のパレットテーブルを形成する。パレットテーブルは、所与のブロックにおける最も支配的な(例えば頻繁に使用される)画素値を含む。所与のブロックのビデオデータにおいて頻繁に現れない画素値は、パレットテーブルに含まれないか、またはエスケープ色としてパレットテーブルに含まれる。
パレットテーブルにおける各エントリは、パレットテーブルにおける対応する画素値についてのインデックスを含む。ブロックにおけるサンプルについてのパレットインデックスは、パレットテーブルからのどのエントリが、どのサンプルを予測または再構成するために用いられるべきであるかを示すように符号化されてよい。このパレットモードは、ピクチャ、スライス、タイル、または他のそのようなビデオブロックの分類の第1のブロックについてのパレット予測子を生成するプロセスで開始する。下記で説明されるように、後続のビデオブロックについてのパレット予測子は、典型的には、以前に使用されたパレット予測子を更新することによって生成される。例示の目的で、パレット予測子がピクチャのレベルで定義されることが仮定される。換言すると、ピクチャは、各々がそれ自体のパレットテーブルを有する複数の符号化ブロックを含んでよいが、ピクチャ全体について1つのパレット予測子が存在する。
ビデオビットストリームにおいてパレットエントリを信号伝送するために必要なビットを低減するべく、ビデオデコーダは、ビデオブロックを再構成するために用いられるパレットテーブルにおける新たなパレットエントリを決定するためにパレット予測子を利用してよい。例えば、パレット予測子は、以前に使用されたパレットテーブルからのパレットエントリを含んでよく、または、ごく最近使用されたパレットテーブルの全てのエントリを含めることにより、ごく最近使用されたパレットテーブルで初期化されてもよい。いくつかの実装において、パレット予測子は、ごく最近使用されたパレットテーブルからの全てのエントリよりも少数のエントリを含んでよく、このとき、他の以前に使用されたパレットテーブルからのいくつかのエントリを組み入れてよい。パレット予測子は、異なるブロックを符号化するために用いられるパレットテーブルと同じサイズを有してもよく、または、異なるブロックを符号化するために用いられるパレットテーブルよりも大きいまたは小さくてもよい。一例において、パレット予測子は、64のパレットエントリを含む先入れ先出し(FIFO)テーブルとして実装される。
パレット予測子からビデオデータのブロックについてのパレットテーブルを生成するべく、ビデオデコーダは、パレット予測子の各エントリについての1ビット・フラグを符号化済みビデオビットストリームから受信してよい。1ビット・フラグは、パレット予測子の関連付けられたエントリがパレットテーブルに含まれるべきであることを示す第1の値(例えば二値の1)、または、パレット予測子の関連付けられたエントリがパレットテーブルに含まれるべきでないことを示す第2の値(例えば二値の0)を有してよい。パレット予測子のサイズが、ビデオデータのブロックに用いられるパレットテーブルよりも大きい場合、ビデオデコーダは、パレットテーブルについての最大サイズに達した時点で、それ以上のフラグを受信することを停止してよい。
いくつかの実装において、パレットテーブルにおけるいくつかのエントリは、パレット予測子を用いて決定される代わりに、符号化済みビデオビットストリームにおいて直接信号伝送されてよい。そのようなエントリについて、ビデオデコーダは、エントリに関連付けられた輝度および2つの彩度成分についての画素値を示す3つの別個のmビット値を、符号化済みビデオビットストリームから受信してよく、ここでmはビデオデータのビット深度を表す。直接信号伝送されるパレットエントリに必要とされる複数のmビット値と比較して、パレット予測子から導出されるパレットエントリは、1ビット・フラグのみを必要とする。したがって、パレット予測子を用いて一部または全てのパレットエントリを信号伝送することは、新たなパレットテーブルのエントリを信号伝送するのに必要とされるビットの数を大幅に低減することができ、これにより、パレットモード符号化の全体的な符号化効率が向上する。
多くの事例において、1つのブロックについてのパレット予測子は、1つまたは複数の以前に符号化されたブロックを符号化するために用いられたパレットテーブルに基づいて決定される。しかしながら、ピクチャ、スライスまたはタイルにおける最初の符号化ツリーユニットを符号化するときは、以前に符号化されたブロックのパレットテーブルが利用可能でない場合がある。したがって、以前に使用されたパレットテーブルのエントリを用いてパレット予測子が生成されることができない。そのような場合には、以前に使用されたパレットテーブルが利用可能でない場合にパレット予測子を生成するために用いられる値であるシーケンスパラメータセット(SPS)および/またはピクチャパラメータセット(PPS)において、一連のパレット予測子初期化子(palette predictor initializer)が信号伝送されてよい。SPSは一般に、各スライスセグメントヘッダに見出される構文要素によって参照されるPPSに見出される構文要素の内容によって決定される、符号化ビデオシーケンス(CVS)と称される一連の連続した符号化済みビデオピクチャに適用する構文要素の構文構造を指す。PPSは一般に、各スライスセグメントヘッダに見出される構文要素によって決定される、CVS内の1つまたは複数の個々のピクチャに適用する構文要素の構文構造を指す。よって、SPSは一般に、PPSよりも上位レベルの構文構造とみなされ、これは、SPSに含まれる構文要素は、一般に、PPSに含まれる構文要素と比較して、より低頻度で変化し、ビデオデータのより大部分に適用することを意味する。
図5Aから図5Bは、本開示のいくつかの実装に係る、RGBの色空間とYCgCoの色空間との間の残差を変換するために適応色空間変換(ACT)の技法を適用する例を示すブロック図である。
HEVCスクリーンコンテンツ符号化拡張では、ACTは、残差を1つの色空間(例えば、RGB)から別の色空間(例えば、YCgCo)へ適応的に変換するために適用され、したがって3つの色成分(例えば、R、G、およびB)間の相関関係(例えば、冗長性)が、YCgCoの色空間では大幅に低減される。さらに、既存のACT設計では、異なる色空間の適応は、変換ユニット(TU)レベルで、1つのフラグtu_act_enabled_flagを各TUに対して信号伝送することによって実施される。フラグtu_act_enabled_flagが1に等しいとき、これは、現在のTUの残差がYCgCo空間で符号化されていることを示し、そうでない場合(すなわち、フラグが0に等しい)、これは、現在のTUの残差が元の色空間で(すなわち、色空間変換なしで)符号化されていることを示す。加えて、現在のTUが無損失モードで符号化されているか、それとも有損失モードで符号化されているかに応じて、異なる色空間変換式が適用される。具体的には、有損失モードに対するRGBの色空間とYCgCoの色空間との間の順方向および逆方向の色空間変換式が、図5Aに定義される。
無損失モードの場合、可逆性のRGB-YCgCo変換(YCgCo-LSとしても知られている)が使用される。可逆性のRGB-YCgCo変換は、図5Bおよび関連説明に示す持上げ動作に基づいて実施される。
図5Aに示すように、有損失モードで使用される順方向および逆方向の色変換行列は、正規化されていない。したがって、YCgCo信号の大きさは、色変換が適用された後の元の信号の大きさより小さい。順方向の色変換によって引き起こされる大きさの減少を補償するために、調整済みの量子化パラメータが、YCgCoドメインの残差に適用される。具体的には、色空間変換が適用されるとき、YCgCoドメイン残差を量子化するために使用されるQP値QPY、QPCg、およびQPCoは、それぞれQP-5、QP-5、およびQP-3になるように設定され、ここでQPは、元の色空間で使用される量子化パラメータである。
図6は、本開示のいくつかの実装に係る、例示的なビデオデータ復号プロセスで彩度スケーリングによる輝度マッピング(LMCS)の技法を適用するブロック図である。
VVCでは、LMCSが、ループ内フィルタ(例えば、デブロッキングフィルタ、SAO、および、ALF)の前に適用される新しい符号化ツールとして使用される。一般に、LMCSは、1)適応型区分的線形モデルに基づく輝度成分のループ内マッピング、2)輝度に依存する彩度残差スケーリングという2つの主モジュールを有する。図6は、LMCSが適用される修正された復号プロセスを示す。図6で、マッピングされたドメインで行われる復号モジュールは、エントロピー復号モジュール、逆量子化モジュール、逆変換モジュール、輝度イントラ予測モジュール、および輝度サンプル再構成モジュール(すなわち、輝度予測サンプルおよび輝度残差サンプルの追加)を含む。元の(すなわち、マッピングされていない)ドメインで行われる復号モジュールは、動き補償予測モジュール、彩度イントラ予測モジュール、彩度サンプル再構成モジュール(すなわち、彩度予測サンプルおよび彩度残差サンプルの追加)、ならびにデブロッキングモジュール、SAOモジュール、およびALFモジュールなどの全てのループ内フィルタモジュールを含む。LMCSによって導入される新しい動作モジュールは、輝度サンプルの順方向マッピングモジュール610、輝度サンプルの逆方向マッピングモジュール620、および彩度残差スケーリングモジュール630を含む。
LMCSのループ内マッピングは、符号化効率を改善するために、入力信号のダイナミックレンジを調整することができる。既存のLMCS設計における輝度サンプルのループ内マッピングは、1つの順方向マッピング関数FwdMapおよび1つの対応する逆方向マッピング関数InvMapという2つのマッピング関数に基づいて構築されている。順方向マッピング関数は、16個の等しいサイズのピースを含む1つの区分的線形モデルを使用して、エンコーダからデコーダへ信号伝送される。逆方向マッピング関数は、順方向マッピング関数から直接導出されてよく、したがって信号伝送される必要はない。
輝度マッピングモデルのパラメータは、スライスレベルで信号伝送される。まず、現在のスライスに対して輝度マッピングモデルが信号伝送されるべきかどうかを示すために、存在フラグが信号伝送される。輝度マッピングモデルが現在のスライス内に存在する場合、対応する区分的線形モデルパラメータがさらに信号伝送される。加えて、スライスレベルでは、スライスに対するLMCSを有効化/無効化するために、別のLMCS制御フラグが信号伝送される。
彩度残差スケーリングモジュール630は、ループ内マッピングが輝度信号に適用されるとき、輝度信号とそれに対応する彩度信号との間で量子化精度の相互作用を補償するように設計される。現在のスライスに対して彩度残差スケーリングが有効化されているか、それとも無効化されているかもまた、スライスヘッダ内で信号伝送される。輝度マッピングが有効化されている場合、輝度に依存する彩度残差スケーリングが適用されるか否かを示すために、追加のフラグが信号伝送される。輝度マッピングが使用されていない場合、輝度に依存する彩度残差スケーリングは常に無効化され、追加のフラグは必要とされない。加えて、彩度残差スケーリングは、4つ以下の彩度サンプルを含むCUに対しては常に無効化される。
図7は、本開示のいくつかの実装に係る、ビデオデコーダが逆適応色空間変換(ACT)の技法を実施する例示的なビデオ復号プロセスを示すブロック図である。
HEVCのSCCにおけるACT設計と同様に、VVCのACTは、4:4:4の彩度形式の1つのCUのイントラ/インター予測残差を、元の色空間(例えば、RGBの色空間)からYCgCoの色空間へ変換する。その結果、より良好な符号化効率のために、3つの色成分間の冗長性が低減され得る。図7は、逆ACTモジュール710の追加によってVVCの枠組みで逆ACTが適用される復号のフローチャートを示す。ACTが有効化された状態で符号化されたCUを処理するとき、エントロピー復号、逆量子化、および逆DCT/DSTに基づく変換がまず、CUに適用される。その後、図7に示すように、逆ACTが起動されて、復号された残差を、YCgCoの色空間から元の色空間(例えば、RGBおよびYCbCr)へ変換する。加えて、ACTは有損失モードで正規化されないため、変換された残差の大きさの変化を補償するために、(-5,-5,-3)のQP調整がY、Cg、およびCo成分に適用される。
いくつかの実施形態において、ACT方法は、同じHEVCのACTコア変換を再使用して、異なる色空間間の色変換を行う。具体的には、現在のCUが有損失で符号化されているか、それとも無損失で符号化されているかに応じて、2つの異なる色変換が適用される。有損失の場合、順方向および逆方向の色変換は、図5Aに示す不可逆性のYCgCo変換行列を使用する。無損失の場合、図5Bに示す可逆性の色変換YCgCo-LSが適用される。さらに、既存のACT設計とは異なり、VVC規格の他の符号化ツールとの相互作用に対処するために、提案されるACT方式には以下の変更が導入される。
例えば、HEVCの1つのCUの残差は、複数のTUに区分され得るため、色空間変換が適用される必要があるか否かを示すために、ACT制御フラグが各TUに対して別個に信号伝送される。しかし、図4Eに関連して上記で説明したように、複数区分型の概念に取って代わり、したがってHEVCの別個のCU、PU、およびTU区分を除去するために、VVCでは二区分および三区分構造によって入れ子状にされた1つの四分木が適用される。これは、ほとんどの場合、対応される最大変換サイズがCUの1つの成分の幅または高さより小さい限り、1つのCUの葉ノードが、さらなる区分なく、予測および変換処理のユニットとしても使用されることを意味する。そのような区分構造に基づいて、本開示では、CUレベルでACTを適応的に有効化および無効化することが提案される。具体的には、CUの残差の符号化のために元の色空間とYCgCoの色空間との間で選択するために、1つのフラグcu_act_enabled_flagが、各CUに対して信号伝送される。フラグが1に等しい場合、これは、CU内の全てのTUの残差がYCgCoの色空間で符号化されていることを示す。そうではなく、フラグcu_act_enabled_flagが0に等しい場合、CUの全ての残差が元の色空間で符号化される。
図8は、本開示のいくつかの実装に係る、逆適応色空間変換(ACT)の技法を条件付きで実行することによって、ビデオデコーダがビデオデータを復号する例示的なプロセスを示すフローチャート800である。
図5Aおよび図5Bに示すように、ACTは、現在のCUが少なくとも1つの0以外の係数を含むときのみ、復号された残差に影響を与えることができる。エントロピー復号から得られる全ての係数が0である場合、逆ACTが適用されるかどうかに関わらず、再構成された残差も0のままである。インター・モードおよびイントラブロックコピー(IBC)モードの場合、1つのCUが0以外の係数を含むか否かの情報は、CUルート符号化ブロック・フラグ(CBF)、すなわちcu_cbfによって示される。フラグが1に等しいとき、これは、現在のCUに対するビデオビットストリーム内に残差構文要素が存在することを意味する。そうでない場合(すなわち、フラグが0に等しい)、これは、現在のCUの残差構文要素がビデオビットストリーム内で信号伝送されないこと、または言い換えれば、CUの全ての残差が0であると推測されることを意味する。したがって、いくつかの実施形態において、現在のCUのルートCBFフラグcu_cbfが、インターおよびIBCモードに対して1に等しいときのみ、フラグcu_act_enabled_flagが信号伝送されることが提案される。そうでない場合(すなわち、フラグcu_cbfが0に等しい)、フラグcu_act_enabled_flagは信号伝送されず、ACTは、現在のCUの残差を復号することが無効化される。他方では、インターおよびIBCモードとは異なり、ルートCBFフラグは、イントラ・モードに対して信号伝送されず、すなわちイントラCUに対してフラグcu_act_enabled_flagの存在を条件付けるために、cu_cbfのフラグが使用されることはない。逆に、ACTが1つのイントラCUに適用されるとき、ACTフラグを使用して、輝度成分のCBFの信号伝送を条件付きで有効化/無効化することが提案される。例えば、1つのイントラCUがACTを使用する場合、デコーダは、少なくとも1つの成分が0以外の係数を含むと仮定する。したがって、ACTが1つのイントラCUに対して有効化されており、かつ最後の変換ブロックを除いてその変換ブロック内に0以外の残差が存在しないときは、信号伝送なく、その最後の変換ブロックに対するCBFが1であると推測される。ちょうど1つのTUを含むイントラCUに対して、その2つの彩度成分(tu_cbf_cbおよびtu_cbf_crによって示される)に対するCBFが0である場合、信号伝送なく、最後の成分のCBFフラグ(すなわち、tu_cbf_luma)は常に1であると推測される。一実施形態において、輝度CBFのそのような推測規則は、残差の符号化のために1つの単一のTUのみを含むイントラCUに対してのみ有効化される。
符号化ユニットで逆ACTを条件付きで実行するために、ビデオデコーダはまず、符号化ユニットに対応するビデオデータ(例えば、4:4:4の形式で符号化される)をビットストリームから受信し、符号化ユニットは、インター予測モードまたはイントラブロックコピーモードで符号化される(810)。
次に、ビデオデコーダは、ビデオデータから第1の構文要素(例えば、CUルート符号化ブロック・フラグcu_cbf)を受信し、第1の構文要素は、符号化ユニットが0以外の残差を有するかどうかを示す(820)。
第1の構文要素が0以外の値(例えば、符号化ユニットのためにビットストリーム内に残差構文要素が存在することを示す1)を有する場合(830)、ビデオデコーダは次いで、ビデオデータから第2の構文要素(例えば、cu_act_enabled_flag)を受信し、第2の構文要素は、符号化ユニットが適応色空間変換(ACT)を使用して符号化されているかどうかを示す(830-1)。
他方では、第1の構文要素が0の値(例えば、符号化ユニットのためにビットストリーム内に残差構文要素が存在しないことを示す0)を有する場合(840)、ビデオデコーダは、第2の構文要素に0の値を割り当てる(例えば、cu_act_enabled_flagを0に設定する)(840-1)。
ビデオデコーダは次いで、第2の構文要素の値に従って、符号化ユニットのビデオデータに対して逆ACTを実行するか否かを決定する(例えば、第2の構文要素が0の値を有する場合、逆ACTの実行を取りやめ、第2の構文要素が0以外の値を有する場合、逆ACTを実行する。第2の構文要素の値は、ビデオデータから受信されても、上述した論理に基づいて割り当てられてもよい)(850)。
いくつかの実施形態において、符号化ユニットは、4:4:4の彩度形式で符号化され、成分(例えば、1つの輝度および2つの彩度)の各々は、同じサンプル率を有する。
いくつかの実施形態において、第1の構文要素が0の値を有することは、符号化ユニットのためにビットストリーム内に残差構文要素が存在しないことを示し、第1の構文要素が0以外の値を有することは、符号化ユニットのためにビットストリーム内に残差構文要素が存在することを示す。
いくつかの実施形態において、第1の構文要素はcu_cbfフラグを含み、第2の構文要素はcu_act_enabledフラグを含む。
いくつかの実施形態において、符号化ユニットがイントラ予測モードで符号化されているとき、ビデオデコーダは、符号化ユニットの輝度成分を復号するための構文要素(例えば、tu_cbf_y)を条件付きで受信する。
輝度成分を復号するための構文要素を条件付きで受信するために、ビデオデコーダはまず、符号化ユニットに対応するビデオデータをビットストリームから受信する。符号化ユニットは、イントラ予測モードで符号化されており、符号化ユニットは、第1の彩度成分、第2の彩度成分、および1つの輝度成分を含む。いくつかの実施形態において、符号化ユニットは、1つの変換ユニットのみを含む。
次に、ビデオデコーダは、符号化ユニットがACTを使用して符号化されているかどうかを示す第1の構文要素(例えば、cu_act_enabled_flag)をビデオデータから受信する。例えば、cu_act_enabled_flagが「1」に等しいことは、符号化ユニットがACTを使用して符号化されていることを示し、cu_act_enabled_flagが「0」に等しいことは、符号化ユニットがACTを使用して符号化されていない(例えば、したがって逆ACTが実行される必要がない)ことを示す。
ビデオデータから第1の構文要素を受信した後、ビデオデコーダは、ビデオデータから第2の構文要素(例えば、tu_cbf_cb)および第3の構文要素(例えば、tu_cbf_cr)を受信し、第2の構文要素は、第1の彩度成分が0以外の残差を有するかどうかを示し、第3の構文要素は、第2の彩度成分が0以外の残差を有するかどうかを示す。例えば、tu_cbf_cbまたはtu_cbf_crが「1」に等しいことは、第1の彩度成分または第2の彩度成分がそれぞれ少なくとも1つの0以外の残差を有することを示し、tu_cbf_cbまたはtu_cbf_crが「0」等しいことは、第1の彩度成分または第2の彩度成分がそれぞれ0以外の残差を有していないことを示す。
第1の構文要素が0以外の値(例えば、逆ACTが実行されるべきであることを示す1)を有し、かつ2つの彩度成分のうちの少なくとも1つが0以外の残差を含む(例えば、tu_cbf_cb==1またはtu_cbf_cr==1)である場合、ビデオデコーダは、ビデオデータから第4の構文要素(例えば、tu_cbf_y)を受信し、第4の構文要素は、輝度成分が0以外の残差を有するか否かを示す。
他方では、第1の構文要素が0以外の値を有し、かつ両方の彩度成分が0の残差のみを有する(例えば、tu_cbf_cb==0およびtu_cbf_cr==0)場合、ビデオデコーダは、第4の構文要素に、輝度成分が0以外の残差を有することを示す既定値(例えば、0以外の値)を割り当てる。その結果、ビデオデコーダは、第4の構文要素に対する値をビデオデータから受信しなくなる。
第4の構文要素に対する値を決定した後(例えば、ビデオデータから値を受信したこと、または第4の構文要素に0以外の既定値を割り当てたことによる)、ビデオデコーダは、第4の構文要素に従って、ビデオデータから符号化ユニットを再構成するか否かを決定する。
いくつかの実施形態において、符号化ユニットは、1つの変換ユニット(TU)のみを含む。
いくつかの実施形態において、第4の構文要素に従ってビデオデータから符号化ユニットを再構成するか否かを決定することは、第4の構文要素が0以外の値を有するとの決定に従って、輝度成分の残差を再構成することと、第4の構文要素が0の値を有するとの決定に従って、輝度成分の残差の再構成を取りやめることとを含む。
4:4:4ビデオの3つの成分間の強い相関関係を考慮すると、輝度成分および彩度成分を予測するために使用されるイントラ・モードは、所与の符号化ブロックに対して同一であることが多い。したがって、ACT信号伝送オーバヘッドを低減させるために、その彩度成分が同じイントラ予測モード(すなわち、DMモード)を輝度成分として使用するときのみ、1つのイントラCUに対してACTを有効化することが提案される。いくつかの実施形態において、ACT有効化/無効化フラグおよび彩度イントラ予測モードを条件付きで信号伝送するための2つの方法がある。本開示の一実施形態において、1つのイントラCUのイントラ予測モードの信号伝送前に、ACT有効化/無効化フラグを信号伝送することが提案される。言い換えれば、ACTフラグ(すなわち、cu_act_enabled_flag)が1に等しいとき、彩度成分のイントラ予測モードは信号伝送されないが、DMモードであると推測される(すなわち、輝度成分と同じイントラ予測モードを再使用する)。そうでない場合(すなわち、cu_act_enabled_flagが0である)、彩度成分のイントラ予測モードはやはり信号伝送される。本開示の別の実施形態において、イントラ予測モードの信号伝送後に、ACT有効化/無効化フラグを信号伝送することが提案される。この場合、ACTフラグcu_act_enabled_flagは、構文解析された彩度イントラ予測モードの値がDMモードであるときのみ、信号伝送される必要がある。そうでない場合(すなわち、彩度イントラ予測モードがDMに等しくない)、フラグcu_act_enabled_flagは信号伝送される必要がなく、0であると推測される。さらに別の実施形態において、全ての可能な彩度イントラ・モードに対してACTを有効化することが提案される。そのような方法が適用される場合、フラグcu_act_enabled_flagは、彩度イントラ予測モードに関わらず、常に信号伝送される。
ACT有効化/無効化フラグおよび彩度イントラ予測モードを条件付きで信号伝送するために、ビデオデコーダはまず、符号化ユニットに対応するビデオデータをビットストリームから受信し、符号化ユニットは、イントラ予測モードで符号化され、符号化ユニットは、2つの彩度成分および1つの輝度成分を含む。
ビデオデコーダは次いで、符号化ユニットがACTを使用して符号化されていることを示す第1の構文要素(例えば、cu_act_enabled_flag)を、ビデオデータから受信する。
ビデオデコーダは次に、ビデオデータから第2の構文要素を受信し、第2の構文要素は、符号化ユニットの輝度成分のイントラ予測パラメータ(例えば、67のイントラ予測方向のうちの1つを表す)を表す。
第2の構文要素が、符号化ユニットがACTを使用して符号化されていることを示す0以外の値を有する場合、ビデオデコーダは、符号化ユニットの輝度成分と同じイントラ予測パラメータを符号化ユニットの2つの彩度成分に適用することによって、符号化ユニットの2つの彩度成分を再構成する。
いくつかの実施形態において、イントラ予測パラメータは、符号化ユニットのイントラ予測サンプルを生成するために適用されたイントラ予測方向を示す。
ACTが1つのCUに対して有効化されるとき、ACTは、色空間変換を行うために、3つ全ての成分の残差にアクセスする必要がある。しかし、前述のように、VVC設計は、各CUが常に3つの成分の情報を含むことを保証することができない。本開示のいくつかの実施形態において、CUが3つ全ての成分の情報を含まないとき、ACTは無効化されるべきである。
まず、個別木(「双対木」としても知られている)区分構造が適用されるとき、1つのCTU内の輝度サンプルおよび彩度サンプルは、別個の区分構造に基づいて、CUに区分される。その結果、輝度区分木内のCUは、輝度成分の符号化情報のみを含み、彩度区分木内のCUは、2つの彩度成分の符号化情報のみを含む。単一木区分構造と個別木区分構造との間の切換えは、様々なレベル、例えばシーケンス・レベル、ピクチャ・レベル、スライスレベル、および符号化ユニット・グループ・レベルなどで行われる。したがって、1つの領域に個別木が適用されていることが見出されたとき、ACTは、領域内の全てのCU(輝度CUおよび彩度CUの両方)が無効化されると推測し、ACTフラグを信号伝送せず、代わりにACTフラグは0であると推測される。
第2に、ISPモードが有効化されるとき、TU区分は輝度サンプルにのみ適用され、彩度サンプルは符号化されるが、複数のTUにさらに分割されない。Nが1つのイントラCUに対するISP下位区分(すなわち、TU)の数であると仮定すると、現在のISP設計に従って、最後のTUのみが、輝度成分および彩度成分の両方を含み、最初のN-lのISPのTUは輝度成分のみから構成される。本開示の一実施形態によれば、ACTはISPモード下で無効化される。ISPモードに対してACTを無効化するための2つの方法がある。第1の方法では、ISPモードの構文を信号伝送する前に、ACT有効化/無効化フラグ(すなわち、cu_act_enabled_flag)を信号伝送することが提案される。そのような場合、フラグcu_act_enabled_flagが1に等しいとき、ISPモードはビットストリーム内で信号伝送されないが、常に0であると推測される(すなわち、オフに切り換えられる)。第2の方法では、ISPモードの信号伝送を使用して、ACTフラグの信号伝送をバイパスすることが提案される。具体的には、この方法では、フラグcu_act_enabled_flagの前に、ISPモードが信号伝送される。ISPモードが選択されたとき、フラグcu_act_enabled_flagは信号伝送されず、0であると推測される。そうでない場合(ISPモードが選択されない)、フラグcu_act_enabled_flagが信号伝送されて、CUの残差符号化のための色空間を適応的に選択する。
輝度区分構造と彩度区分構造とが整合しないCUに対してACTを無効化することに加えて、本開示において、ACTが適用されたCUに対してLMCSを無効化することも提案される。一実施形態において、1つのCUがその残差を符号化するためにYCgCoの色空間を選択したとき(すなわち、ACTが1である)、輝度マッピングおよび彩度残差スケーリングの両方を無効化することが提案される。別の実施形態において、ACTが1つのCUに対して有効化されたとき、彩度残差スケーリングのみを無効化することが提案され、輝度マッピングは依然として、出力輝度サンプルのダイナミックレンジを調整するために適用され得る。最後の実施形態において、その残差を符号化するためにACTを適用するCUに対して、輝度マッピングおよび彩度残差スケーリングの両方を有効化することが提案される。
双対木区分構造によりACT信号伝送を無効化するために、ビデオデコーダは、ビデオデータ内の符号化ユニットが単一木区分によって符号化されているか、それとも双対木区分によって符号化されているかを示す情報を、ビットストリームから得る。
符号化ユニットが単一木区分を使用して符号化され、各符号化ユニットが輝度成分および彩度成分の両方を含む場合、ビデオデコーダは、ビデオデータから第2の構文要素(例えば、cu_act_enabled_flag)を受信し、第1の構文要素の値は、各符号化ユニットに対して逆適応色空間変換(ACT)を実行するか否かを示す。
他方では、符号化ユニットが双対木区分を使用して符号化され、双対木区分の輝度区分木内の符号化ユニットが、符号化ユニットの輝度成分に関係する符号化情報のみを含み、双対木区分の彩度区分木内の符号化ユニットが、符号化ユニットの彩度成分に関係する符号化情報のみを含む場合、ビデオデコーダは、第2の構文要素に0の値を割り当てる。
ビデオデコーダは次いで、第2の構文要素に従って、符号化木ユニット内の各符号化ユニットに対して逆ACTを実行するか否かを決定する。
いくつかの実施形態において、第2の構文要素に従って、符号化木ユニット内の各符号化ユニットに対して逆ACTを実行するか否かを決定することは、第2の構文要素が0以外の値を有するとの決定に従って、各符号化ユニットに対して逆ACTを実行することと、第2の構文要素が0の値を有するとの決定に従って、各符号化ユニットに対する逆ACTの実行を取りやめることとを含む。
いくつかの実施形態において、ACT信号伝送によりISPモードを無効化するために、ビデオデコーダはまず、符号化ユニットに対応するビデオデータをビットストリームから受信する。次に、ビデオデコーダは、第1の構文要素(例えば、cu_act_enabled_flag)をビデオデータから受信し、第1の構文要素は、符号化ユニットがACTを使用して符号化されているかどうかを示す。第1の構文要素が0の値を有する場合、ビデオデコーダは、第2の構文要素をビデオデータから受信し、第2の構文要素は、符号化ユニットがISPモードを使用して符号化されているかどうかを示す。第1の構文要素が0以外の値を有する場合、ビデオデコーダは、第2の構文要素に0の値を割り当てて、符号化ユニットがISPモードを使用して符号化されていないことを示す。ビデオデコーダは次いで、第2の構文要素に従って、ISPモードを使用してビデオデータから符号化ユニットを再構成するか否かを決定する。現在のVVCでは、ISPモードが有効化されるとき、TU区分は輝度サンプルにのみ適用され、彩度サンプルは符号化されるが、複数のTUにさらに分割されない。本開示の一実施形態によれば、彩度平面ではテキスチャ情報が豊富にあるため、4:4:4ビデオにおける彩度符号化のためにISPモードを有効化することも提案される。この実施形態に基づいて、異なる方法が使用されてよい。1つの方法では、1つの追加のISPインデックスが信号伝送され、2つの彩度成分によって共有される。別の方法では、2つの追加のISPインデックスを別個に、一方はCb/Bで、他方はCr/Rで信号伝送することが提案される。第3の方法では、2つの彩度成分のISP予測に対して輝度成分に使用されたISPインデックスを再使用することが提案される。
行列加重イントラ予測(MIP)方法は、イントラ予測技法である。幅Wおよび高さHの矩形ブロックのサンプルを予測するために、MIPは、ブロックの左にH個の再構成された近隣境界サンプルからなる1本の線、およびブロックの上にW個の再構成された近隣境界サンプルからなる1本の線を、入力として取る。再構成されたサンプルが利用可能でない場合、それらは従来のイントラ予測と同様に生成される。予測信号の生成は、図10に示すように、平均化、行列ベクトル乗算、および線形補間という3つのステップに基づいて行われる。
現在のVVCでは、MIPモードは、輝度成分に対してのみ有効化される。彩度成分に対してISPモードを有効化するのと同じ理由により、一実施形態において、444ビデオの彩度成分に対してMIPを有効化することが提案される。2つの信号伝送方法が適用され得る。第1の方法では、2つのMIPモードを別個に信号伝送し、一方を輝度成分に使用し、他方を2つの彩度成分に使用することが提案される。第2の方法では、輝度成分および彩度成分によって共有される1つの単一のMIPモードのみを信号伝送することが提案される。
4:4:4の彩度形式の彩度成分に対してMIPを有効化するために、ビデオデコーダは、符号化ユニットに対応するビデオデータをビットストリームから受信し、符号化ユニットは、イントラ予測モードで符号化され、符号化ユニットは、2つの彩度成分および1つの輝度成分を含み、彩度成分および輝度成分は、同じ分解能を有する。次に、ビデオデコーダは、符号化ユニットの輝度成分がMIPツールを使用して符号化されていることを示す第1の構文要素(例えば、intra_mip_flag)を、ビデオデータから受信する。第1の構文要素が、符号化ユニットの輝度成分がMIPツールを使用して符号化されていることを示す0以外の値を有する場合、ビデオデコーダは、符号化ユニットの輝度成分に適用されたMIPモードを示す第2の構文要素(例えば、intra_mip_mode)を、ビデオデータから受信し、符号化ユニットの輝度成分のMIPモードを符号化ユニットの2つの彩度成分に適用することによって、符号化ユニットの2つの彩度成分を再構成する。以下の表は、VVCでACTを使用してビデオデータを復号するための構文設計仕様を示す。
まず、ACTが有効化されているか、それともシーケンス・レベルにないかを示すために、1つの追加の構文要素、例えばsps_act_enabled_flagが、シーケンスパラメータセット(SPS)に追加される。いくつかの実施形態において、輝度成分および彩度成分が同じ分解能を有するビデオコンテンツに色空間変換が適用される場合、ACTが4:4:4の彩度形式に対してのみ有効化され得るように、1つのビットストリーム準拠要件が追加される必要がある。表1は、修正されたSPS構文表を示し、上記の構文が追加されている。
フラグsps_act_enabled_flagが1に等しいことは、適応色空間変換が有効化されていることを示す。フラグsps_act_enabled_flagが0に等しいことは、適応色空間変換が無効化されていることを示し、このSPSを参照するCUに対してフラグcu_act_enabled_flagは信号伝送されず、0であると推測される。ChromaArrayTypeが3に等しくないとき、sps_act_enabled_flagの値が0に等しいことが、ビットストリーム準拠の要件である。
フラグcu_act_enabled_flagが1に等しいことは、符号化ユニットの残差がYCgCoの色空間で符号化されていることを示す。フラグcu_act_enabled_flagが0に等しいことは、符号化ユニットの残差が元の色空間で符号化されていることを示す。フラグcu_act_enabled_flagが存在しない場合、これは0に等しいと推測される。
1つまたは複数の例において、説明されている機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせにおいて実装されてよい。ソフトウェアにおいて実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体に格納されまたはそれを介して伝送され、ハードウェアベースの処理ユニットによって実行されてよい。コンピュータ可読媒体は、データ記憶媒体などの有形媒体、または、例えば通信プロトコルに従って、1つの場所から別の場所へのコンピュータプログラムの転送を促進する任意の媒体を含む通信媒体に対応する、コンピュータ可読記憶媒体を含んでよい。このように、コンピュータ可読媒体は一般に、(1)非一時的な有形のコンピュータ可読記憶媒体または(2)信号または搬送波などの通信媒体に対応してよい。データ記憶媒体は、本出願において説明されている実装の実装のための命令、コードおよび/またはデータ構造を取得するために1つまたは複数のコンピュータまたは1つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であってよい。コンピュータプログラム製品は、コンピュータ可読媒体を含んでよい。
本明細書の実装の説明において用いられる用語は、特定の実装を説明することのみを目的としたものであり、請求項の範囲を限定することは意図されていない。実装の説明および添付の請求項において用いられる場合、単数形の「a」、「an」および「the」は、別途文脈による明示のない限り、複数形も含むことが意図されている。また、本明細書において用いられる用語「および/または」は、関連付けられた列挙されている項目のうちの1つまたは複数の任意のかつ全ての可能な組み合わせを参照および包含することが理解されよう。さらに、本明細書において用いられる場合の用語「含む(comprise)」および/または「含む(comprising)」は、記載される特徴、要素、および/または構成要素の存在を規定するが、1つまたは複数の他の特徴、要素、構成要素、および/またはそれらの群の存在または追加を排除するものではないことが理解されよう。
また、様々な要素を説明するために第1、第2等の用語が本明細書において用いられる場合があるが、これらの要素はこれらの用語によって限定されるべきでないことが理解されよう。これらの用語は、1つの要素を別の要素と区別するためにのみ用いられる。例えば、実装の範囲から逸脱しない限りにおいて、第1の電極が第2の電極と称されることも可能であり、同様に第2の電極が第1の電極と称されることも可能である。第1の電極および第2の電極は、両方が電極であるが、これらは同じ電極ではない。
本出願の説明は、例示および説明の目的で提示されており、網羅的である、または開示されている形態の発明に限定されることは意図されていない。多くの修正、変形、および代替的実装が、前述の説明および関連する図面において提示される教示の利益を得る当業者には明らかであろう。実施形態は、本発明の原理、実際の応用を最も良く明らかにし、他の当業者が様々な実装について本発明を理解し、想定される特定の用途に好適なように様々な修正を伴って根本的な原理および様々な実装を最も良く利用することを可能とするために、選定および説明されたものである。したがって、請求項の範囲は、開示されている実装の具体例に限定されるべきでなく、修正および他の実装が添付の請求項の範囲内に含まれるよう意図されていることが、理解されるべきである。