JP6294482B2 - 先進的なスクリーンコンテンツコーディングソリューション - Google Patents

Description

本開示は一般的には、スクリーンコンテンツコーディングに向けられるものである。

スクリーンコンテンツコーディングは、従来の自然なビデオと比較されてのその独特な信号特性のために、ビデオ圧縮技術に対する新しい難題を課すものである。先進的なスクリーンコンテンツコーディングに対するいくつかの将来有望な技法、例えば、擬似ストリングマッチ、カラーパレットコーディング、およびイントラ動き補償またはイントラブロックコピーが存在すると思われる。

これらの技法の中で、擬似ストリングマッチは、無損失コーディングに対する最も高い利得を示すが、有意な複雑度オーバーヘッド、および有損失コーディングモードに関する困難を伴う。カラーパレットコーディングは、カメラで捕捉されたものでないコンテンツが通常、自然なビデオでの連続的なカラートーンよりむしろ、制限されるいくつかの独特なカラーを内包するという想定のもとに、スクリーンコンテンツに対して開発される。擬似ストリングマッチおよびカラーパレットコーディング方法が、大きな可能性を示したにもかかわらず、イントラ動き補償またはイントラブロックコピーが、スクリーンコンテンツコーディングに対する進行中のＨＥＶＣレンジ拡張（ＨＥＶＣ ＲＥｘｔ）の作業草案（ＷＤ）バージョン４および参照ソフトウェアに採用された。これは主に、動き推定および補償手法が広範囲にわたり数十年にわたって研究されてきたこと、ならびにその観念および実際上の実現形態が（特にハードウェアに対して）相当に容易であることの事実に起因する。

しかしながら、イントラブロックコピーのコーディング性能は、その固定されたブロック構造区分のために境界設定される。他方で何かイントラピクチャでの動き推定と同様なブロックマッチングを実施することはさらには、コンピューティングおよびメモリアクセスの両方に関して有意に符号化器複雑度を引き上げる。

本開示は、先進的なスクリーンコンテンツコーディングソリューションに向けられるものである。

１つの例示的な実施形態では、スクリーンコンテンツをビットストリームにコーディングするための方法は、スクリーンコンテンツのコーディングユニット（ＣＵ）についてのカラーパレットテーブルを選択する。ＣＵおよびカラーパレットテーブルに対して作成されるカラーパレットテーブルは、隣接のＣＵについて作成される。スクリーンコンテンツのコーディングユニット（ＣＵ）についてのインデックスを有するカラーインデックスマップは、選択されるカラーパレットテーブルを使用して作成される。選択されるカラーパレットテーブルおよびカラーインデックスマップは、複数のＣＵの各々について、ビットストリームに符号化／圧縮される。

本開示およびその利点のより完全な理解のために、ここでは、添付の図面とともに以下の説明が参照されるが、同様の数字は同様の対象を示している。
本開示の一例示的実施形態による、カラーパレットテーブルおよびインデックスマップモードまたはパレットモードを使用するスクリーンコンテンツ符号化ソリューションを例示する図である。 カラーパレットテーブルおよびインデックスマップモードまたはパレットモードに対するスクリーンコンテンツ復号ソリューションを例示する図である。 ＣＵのこのカラーパレットテーブルおよびインデックスマップモードまたはパレットモードに対するスクリーンコンテンツソリューションのプロセスまたは作業フローを例示する図である。 パックド（packed）モード（右）に対するプレーナ(planar)モード（左）での従来のＧ、Ｂ、Ｒを例示する図である。 隣接の再構築されたブロックを使用するカラーパレットテーブル再生成を例示する図である。 インデックスマップが実際の語のスクリーンコンテンツからパースされる（parsed）ことを例示する図である。 水平スキャニングの後の１−Ｄ探索に対するセグメントのまとまりを例示する図である。 Ｕ＿ＰＩＸＥＬモジュールを例示する図である。 Ｕ＿ＲＯＷモジュールを例示する図である。 Ｕ＿ＣＭＰモジュールを例示する図である。 Ｕ＿ＣＯＬモジュールを例示する図である。 Ｕ＿２Ｄ＿ＢＬＯＣＫモジュールを例示する図である。 例示したＣＵのインデックスマップ処理に対する水平および垂直スキャンの例示の図である。 ４：２：０クロマサンプリングフォーマットの例示の図である。 ４：４：４クロマサンプリングフォーマットの例示の図である。 ４：２０と４：４：４との間の補間を例示する図である。 上部／左ラインバッファによるインデックスマップ処理を例示する図である。 現在のＨＥＶＣに組み込まれる装置および方法／フローを例示する図である。 通信システムの一例を示す図である。 本開示による方法および教示を実現し得る例示的デバイスを示す図である。 本開示による方法および教示を実現し得る例示的デバイスを示す図である。

本開示では、高効率ビデオコーディング（ＨＥＶＣ）レンジ拡張（ＨＥＶＣバージョン２、またはＨＥＶＣ ＲＥｘｔなど）をしのぐ、先進的なスクリーンコンテンツコーディングソリューションが説明される。この新しいソリューションは、具体的にはスクリーンコンテンツをコーディングするために設計されるいくつかのアルゴリズムを含む。これらのアルゴリズムは、本明細書ではカラーパレットテーブルと称される、カラーパレットまたはカラーテーブルを使用する画素表現、カラーパレット圧縮、カラーインデックスマップ圧縮、ストリング探索、および残差圧縮を含む。この技術は、効率的なスクリーンコンテンツコーディングをサポートするために開発され、調和され、ＨＥＶＣレンジ拡張（ＲＥｘｔ）および後来ＨＥＶＣ拡張と統合され得る。しかし、この技術は、任意の既存のビデオ標準によって実現することができる。簡略化のために、ＨＥＶＣ ＲＥｘｔは下記説明の一例として使用され、ＨＥＶＣ ＲＥｘｔソフトウェアが、圧縮効率を説明および実証するために使用される。このソリューションは、性能を実証するために、ＨＥＶＣで、本明細書ではカラーパレットモードと定義される、カラーパレットテーブルおよびインデックスマップを使用することによる追加的なモードとして統合される。

本開示の概念および説明は図面で示される。図１は、メモリを含むプロセッサ１２を有する符号化器１０を示し、図２は、プロセッサ１６およびメモリを有する復号器１４を示し、それらの図は一体で、それぞれ、本開示によるカラーパレットモードに対する符号化および復号ソリューションの例示的な実施形態を例示する。示されるように、符号化器１０および復号器１４の各々は、プロセッサおよびメモリを備え、コーデックソリューションを形成する。コーデックソリューションは、新しいアルゴリズムまたは方法を実行する符号化器１０のプロセッサ１２を含み、それらのアルゴリズムまたは方法は、カラーパレットテーブルを作成するプロセス１、カラーまたは画素値を、カラーインデックスに対応して以前に導出されたカラーパレットテーブルを使用して分類するプロセス２、カラーパレットテーブルを符号化するプロセス３、カラーインデックスマップを符号化するプロセス４、残差を符号化するプロセス５、および新しいシンタックス要素を、圧縮されるビットストリームに書き込むプロセス６を含む。復号器１４のプロセッサ１６は、逆のステップを含む新しいアルゴリズムまたは方法を実行する。図３は、本開示によるスクリーンコンテンツソリューションのプロセスまたは作業フローを提供する。

基本的には、高効率カラーパレット圧縮方法（ＣＰＣ）が、各々のコーディングユニット（ＣＵ）上で実施される。コーディングユニットは、３つの成分（すなわち、ＲＧＢ、またはＹＵＶ、またはＸＹＺ）からなる画素の方形のブロックである、ＨＥＶＣおよびＨＥＶＣ ＲＥｘｔでの基本的な動作ユニットである。

各々のＣＵレベルにおいて、ＣＰＣ方法は、２つの主要なステップを含む。第１に、プロセッサ１２は、第１のステップでカラーパレットテーブルを導出または生成する。このテーブルは、後に続く符号化プロセスの効率を増大するために、ヒストグラム（すなわち、各々のカラー値の発生頻度）、またはその実際のカラー強度、または任意の方法によって順序付けされる。導出されるカラーパレットテーブルに基づいて、元のＣＵ内の各々の画素は、カラーパレットテーブル内部のそのカラーインデックスに変換される。本開示の寄与は、圧縮を使用するなどして、各々のＣＵのカラーパレットテーブルおよびカラーインデックスマップをストリームに効率的に符号化するための技術である。受信器側では、プロセッサ１６は、圧縮されたビットストリームをパースして、各々のＣＵについて、完全なカラーパレットテーブルおよびカラーインデックスマップを再構築し、次いでさらに、各々の位置での画素値を、カラーインデックスおよびカラーパレットテーブルを組み合わせることにより導出する。

本開示の例示的な例では、ＮｘＮの画素を伴うＣＵを想定する（ＨＥＶＣとの互換性のためには、Ｎ＝８、１６、３２、６４）。ＣＵは典型的には、３つのクロミナンス（クロマ）成分（すなわち、Ｇ、Ｂ、Ｒ、またはＹ、Ｃｂ、Ｃｒ、またはＸ、Ｙ Ｚ）を、異なるサンプリング比（すなわち、４：４：４、４：２：２、４：２：０）で内包する。簡略化のために、４：４：４のシーケンスが本開示で例示される。４：２：２および４：２：０ビデオのシーケンスに対しては、クロマアップサンプリングが、４：４：４シーケンスを得るために適用されるものであり、または、各々のカラー成分は独立して処理される。次いで、本開示で説明される同じ手順が適用される。４：０：０モノクロムビデオに対しては、これは、他の２つのプレーンを伴わない４：４：４の個々のプレーンとして扱われる。４：４：４に対するすべての方法は直接適用することができる。

パックドまたはプレーナ
この方法は、図１のブロックＣＴＵまたはＣＵについて示される。まず、ｅｎａｂｌｅ＿ｐａｃｋｅｄ＿ｃｏｍｐｏｎｅｎｔ＿ｆｌａｇと呼ばれるフラグは、各々のＣＵについて、現在のＣＵがパックド式を使用して処理されるか、それとも、従来のプレーナモード（すなわち、Ｇ、Ｂ、Ｒ、またはＹ、Ｕ、Ｖ成分は独立して処理される）を使用して処理されるかを示すために定義される。図４は、パックドモード（右）に対する、プレーナモード（左）での従来のＧ、Ｂ、Ｒを例示する。ＹＵＶ、または他のカラーフォーマットは、ＲＧＢコンテンツに対して例示されるのと同じように処理される。

パックドモードおよびプレーナモードの両方は、それ自体の利点および欠点を有する。例えば、プレーナモードは、Ｇ／Ｂ／ＲまたはＹ／Ｕ／Ｖに対して並列カラー成分処理をサポートする。しかし、それは、低いコーディング効率になる場合がある。パックドモードは、このＣＵについてのヘッダ情報（本開示でのカラーパレットテーブルおよびインデックスマップなど）を、異なるカラー成分の間で共有し得る。しかし、それは、並列性を破る場合がある。現在のＣＵがパックド式で符号化されるべきであるかどうかを判断するための容易な方途は、レート歪み（Ｒ−Ｄ）コストを測定することである。ｅｎａｂｌｅ＿ｐａｃｋｅｄ＿ｃｏｍｐｏｎｅｎｔ＿ｆｌａｇは、符号化モードを復号器に明示的にシグナリングするために使用される。

さらに、ＣＵレベルでｅｎａｂｌｅ＿ｐａｃｋｅｄ＿ｃｏｍｐｏｎｅｎｔ＿ｆｌａｇを低レベルハンドリングに対して定義するために、それは、スライスヘッダで、またはシーケンスレベル（例えば、シーケンスパラメータセットまたはピクチャパラメータセット）でも、スライスレベルまたはシーケンスレベルハンドリングを特定のアプリケーション要件に応じて可能とするために、複製することができる。

カラーパレットテーブルおよびインデックスマップ導出
図１に示されるように、プロセス１および３に対して、各々のＣＵについて、画素場所が横断され（transversed）、後続の処理に対するカラーパレットテーブルおよびインデックスマップが導出される。各々の個別のカラーは、後に続く符号化プロセスの効率を向上させるために、カラーパレットテーブル内で、そのヒストグラム（すなわち、発生の頻度）、またはその強度、または何らかの任意の方法のいずれかに応じて順序付けされる。例えば符号化プロセスが、差分パルスコード変調（ＤＰＣＭ）方法を使用して、隣接する画素間の差をコーディングする場合、最適なコーディング結果は、隣接する画素にカラーパレットテーブル内の隣接するカラーインデックスが割り当てられる場合に得られ得る。

カラーパレットテーブルを得た後で、各々の画素は、現在のＣＵのインデックスマップを形成するために、対応するカラーインデックスにマッピングされる。インデックスマップの処理は、後述のセクションで説明する。

従来のプレーナＣＵについて、各々のカラーまたはクロミナンス成分は、ここでは例としていくつかの名前を挙げるが、ｃｏｌｏｒＴａｂｌｅ＿Ｙ、ｃｏｌｏｒＴａｂｌｅ＿Ｕ、ｃｏｌｏｒＴａｂｌｅ＿Ｖ、またはｃｏｌｏｒＴａｂｌｅ＿Ｒ、ｃｏｌｏｒＴａｂｌｅ＿Ｇ、ｃｏｌｏｒＴａｂｌｅ＿Ｂなどの、その個々のカラーパレットテーブルを有する。一方、ＹＵＶでのＹ、またはＧＢＲでのＧなどの、主要な成分に対するカラーパレットテーブルが導出され、すべての成分に対して共有される場合がある。通常、この共有により、ＹまたはＧ以外の他のカラー成分は、その元の画素カラーに対して相対的なカラーパレットテーブルで共有されるものからの、いくらかのミスマッチを有することになる。残差エンジン（ＨＥＶＣ係数コーディング方法など）が、次いで、それらのミスマッチングされる残差を符号化するために適用される。他方でパックドＣＵについては、単一のカラーパレットテーブルがすべての成分の間で共有される。

擬似コードが、後に続くように、カラーパレットテーブルおよびインデックスマップ導出を例示するために提供される。

カラーパレットテーブル処理
図１のプロセス１に対して、カラーパレットテーブル処理は、カラーパレットテーブルのサイズ（すなわち、独特なカラーの総合的な数）、および各々のカラーそれ自体のプロセッサ１２符号化を必然的に含む。ビットの大部分は、カラーパレットテーブル内の各々のカラーの符号化により消費される。ゆえに、焦点は、カラー符号化（または、カラーパレットテーブル内の各々のエントリの符号化）に置かれる。

カラーパレットテーブル内のカラーを符号化するための最も平易な方法は、各々のカラーが独立してコーディングされるパルスコード変調（ＰＣＭ）スタイルアルゴリズムを使用することである。あるいは、連続するカラーに対する最近傍予測が適用されるものであり、次いで、ＤＰＣＭ（差分ＰＣＭ）スタイルである予測デルタが、デフォルトカラー強度よりもむしろ、符号化される。両方の方法は後に、複雑度コストとコーディング効率との間の相反関係に応じて、等確率モデル、または適応的なコンテキストモデルを使用してエントロピー符号化することができる。

ここで、隣接のカラーパレットテーブルマージと呼ばれる別の先進的な体系が開示され、ｃｏｌｏｒ＿ｔａｂｌｅ＿ｍｅｒｇｅ＿ｆｌａｇは、現在のＣＵがその左または上部ＣＵからのカラーパレットテーブルを使用するかどうかを示すために定義される。そうでない場合、現在のＣＵは、カラーパレットテーブルシグナリングを明示的に搬送することになる。マージングプロセスに対して、別のｃｏｌｏｒ＿ｔａｂｌｅ＿ｍｅｒｇｅ＿ｄｉｒｅｃｔｉｏｎが、上部ＣＵからの、または左ＣＵからの、いずれかのマージング方向を示す。当然ながら、候補は、現在の上部または左ＣＵより多く、例えば上部左、上部右、およびその他である。しかし、上部および左ＣＵは、本開示では観念を例示するために使用される。それらのいずれに対しても、各々の画素は、既存のカラーパレットテーブル内のエントリと比較され、ｄｅｒｉｖｅＩｄｘＭａｐ（）によって、最も少ない予測差を生むインデックスを割り当てられる（すなわち、画素はカラーパレットテーブル内の最も近いカラーを減算する）。予測差が非ゼロである場合について、すべてのこれらの残差は、ＨＥＶＣ ＲＥｘｔ残差エンジンを使用して符号化される。マージングプロセスを使用するか否かは、Ｒ−Ｄコストにより判断されることに留意されたい。

現在のＣＵをコーディングする際にマージングプロセスで使用されるための隣接のカラーパレットテーブルを生成するための、いくつかの方途が存在する。その実現形態に応じて、それらの１つは、符号化器および復号器の両方での更新を要し、他のものは、符号化器側プロセスのみのものである。

符号化器および復号器の両方での更新：この方法では、隣接物ＣＵのカラーパレットテーブルは、ＣＵ深度、サイズ、およびその他に関わらず、利用可能な再構築される画素を基に生成される。各々のＣＵについて再構築が、その隣接のＣＵについて同じサイズおよび同じ深度で検索される（カラー類似性がこの事例ではより高くなることを想定する）。例えば、現在のＣＵが、深度＝２を伴う１６ｘ１６である場合、その隣接のＣＵの区分がどうであれ（例えば、左ＣＵについての、深度＝３を伴う８ｘ８、および、上部ＣＵについての、深度＝１を伴う３２ｘ３２）、画素オフセット（＝１６）が、図５に示されるように、左１６ｘ１６ブロックを処理するために、現在のＣＵ起点から左に、および、上部１６ｘ１６ブロックに対して上部に位置決めされることになる。符号化器および復号器の両方が、このプロセスを維持すべきであることに留意されたい。

制約される符号化器のみのプロセス：この方法に対して、マージングプロセスは、現在のＣＵがその上部および／または左ＣＵと同じ、サイズおよび深度を共有するときに生じる。利用可能な隣接物のカラーパレットテーブルは、後続の動作のために現在のＣＵのカラーインデックスマップを導出するために使用される。例えば現在の１６ｘ１６ＣＵについて、その隣接の、すなわち上部または左のいずれかに置かれるＣＵが、カラーパレットテーブルおよびインデックス方法を使用して符号化される場合、そのカラーパレットテーブルは、Ｒ−Ｄコストを導出するために直接、現在のＣＵについて使用される。このマージコストは、現在のＣＵがそのカラーパレットテーブルを明示的に導出するという場合（および、ＨＥＶＣまたはＨＥＶＣ ＲＥｘｔ内に既存の他の従来のモード）と比較される。より少ないＲ−Ｄコストを導くものはどれでも、出力ビットストリームに書き込まれるための最終的なモードとして選定される。理解されるように、符号化器のみは、異なる、可能性のあるモードを実験／シミュレートすることを要される。復号器側では、ｃｏｌｏｒ＿ｔａｂｌｅ＿ｍｅｒｇｅ＿ｆｌａｇおよびｃｏｌｏｒ＿ｔａｂｌｅ＿ｍｅｒｇｅ＿ｄｉｒｅｃｔｉｏｎが、追加的な処理作業負荷を要することなく、マージ判断およびマージ方向を暗に意味する。

カラーインデックスマップ処理
図１のプロセス３に対して、カラーインデックスマップをコーディングすることに対して、ＲＵＮモード、ＲＵＮおよびＣＯＰＹ＿ＡＢＯＶＥ、ならびに、適応的な隣接物インデックス予測など、いくつかのソリューションが研究されてきた。この開示では、１Ｄストリングマッチング手法、およびその２Ｄ変形形態が、インデックスマップコーディングを符号化するために開示される。各々の位置において、それはそのマッチングされるポイントを見出し、マッチングされる距離、および、１Ｄストリングマッチに対する長さ、または、２Ｄストリングマッチに対する幅／高さを記録する。マッチングされない位置に対しては、そのインデックス強度、または、そのインデックス強度と予測されるインデックス強度との間のデルタ値が、直接符号化される。

ここで開示されるのは、カラーインデックスマップに対する平易な１Ｄ探索方法である。図６を参照すると、インデックスマップが、実語スクリーンコンテンツからパースされる。図７は、１−Ｄ探索の後のセグメントのまとまり（すなわち、このインデックスマップのまさに始まり）を示す。

この１−Ｄカラーインデックスベクトルのトップで、ストリングマッチが適用される。この１−Ｄストリングマッチの例が下記で与えられる。図７に示されるような１４などの、各々のインデックスマップの第１の位置に対して、バッファリングされる参照はまだ存在しないので、このまさに第１のインデックスは、「マッチングされない対」として扱われ、それは、−１および１を、その対応する距離および長さに与えられ、そのことは（ｄｉｓｔ，ｌｅｎ）＝（−１，１）と記される。第２のインデックス、再び別の「１４」に対して、それは、参照としてコーディングされる第１のインデックスであり、したがってｄｉｓｔ＝１である。第３の位置に別の「１４」が存在するので、（あらゆる収穫インデックスが、じかに後続のインデックスに対して、参照として役立たせられ得ることが与えられると）長さは２であり、すなわちｌｅｎ＝２である。前方の第４の位置に移ると、遭遇させられるのは、前に認められていない「１７」である。ゆえにそれは再び、マッチングされない対として符号化され、すなわち（ｄｉｓｔ，ｌｅｎ）＝（−１，１）である。マッチングされない対に対して、フラグは、符号化され（「ｄｉｓｔ＝＝−１」など）、（第１に現れた「１４」、「１７」、「６」、およびその他のように）インデックスの実値により後に続かれる。他方で、マッチングされる対に対して、フラグは、やはり符号化され（「ｄｉｓｔ！＝−１」など）、マッチングされるストリングの長さにより後に続かれる。

ここにあるのは、図７に示される、例示されるインデックスを使用する符号化手順に対する概要である。

ｄｉｓｔ＝−１、ｌｅｎ＝１、ｉｄｘ＝１４（マッチングされない）
ｄｉｓｔ＝１、ｌｅｎ＝２（マッチングされる）
ｄｉｓｔ＝−１、ｌｅｎ＝１、ｉｄｘ＝１７（マッチングされない）
ｄｉｓｔ＝１、ｌｅｎ＝３（マッチングされる）
ｄｉｓｔ＝−１、ｌｅｎ＝１、ｉｄｘ＝６（マッチングされない）
ｄｉｓｔ＝１、ｌｅｎ＝２５（マッチングされる）
ｄｉｓｔ＝３０、ｌｅｎ＝４（マッチングされる）／＊前に現れた「１７」に対して＊／
…

擬似コードは、このマッチングされる対導出に対して与えられるものであり、すなわち以下である。

後に続くステップは、２Ｄ探索変形形態が使用されるときになされる。

１．現在の画素および参照画素の場所を、開始ポイントとして識別する。

２．水平１Ｄストリングマッチを、現在の画素および参照画素の右方向に適用する。最大探索長さは、現在の水平行のエンドにより制約される。最大探索長さをｒｉｇｈｔ＿ｗｉｄｔｈとして記録する。

３．水平１Ｄストリングマッチを、現在の画素および参照画素の左方向に適用する。最大探索長さは、現在の水平行の始まりにより制約される。最大探索長さをｌｅｆｔ＿ｗｉｄｔｈとして記録する。

４．現在の画素および参照画素の下の画素を新しい現在の画素および参照画素として使用して、同じ１Ｄストリングマッチを次の行で実施する。

５．ｒｉｇｈｔ＿ｗｉｄｔｈ＝＝ｌｅｆｔ＿ｗｉｄｔｈ＝＝０まで停止する。

６．ここで、各々のｈｅｉｇｈｔ［ｎ］＝｛１，２，３…｝に対して、ｗｉｄｔｈ［ｎ］の対応するアレイ｛｛ｌｅｆｔ＿ｗｉｄｔｈ［１］，ｒｉｇｈｔ＿ｗｉｄｔｈ［１］｝，｛ｌｅｆｔ＿ｗｉｄｔｈ［２］，ｒｉｇｈｔ＿ｗｉｄｔｈ［２］｝，｛ｌｅｆｔ＿ｗｉｄｔｈ［３］，ｒｉｇｈｔ＿ｗｉｄｔｈ［３］｝…｝が存在する。

７．新しいｍｉｎ＿ｗｉｄｔｈアレイ｛｛ｌｗｉｄｔｈ［１］，ｒｗｉｄｔｈ［１］｝，｛ｌｗｉｄｔｈ［２］，ｒｗｉｄｔｈ［２］｝，｛ｌｗｉｄｔｈ［３］，ｒｗｉｄｔｈ［３］｝…｝を、各々のｈｅｉｇｈｔ［ｎ］に対して定義するものであり、ただしｌｗｉｄｔｈ［ｎ］＝ｍｉｎ（ｌｅｆｔ＿ｗｉｄｔｈ［１：ｎ−１］）、ｒｗｉｄｔｈ［ｎ］＝ｍｉｎ（ｒｉｇｈｔ＿ｗｉｄｔｈ［１：ｎ−ｌ］）である。

８．サイズアレイ｛ｓｉｚｅ［１］，ｓｉｚｅ［２］，ｓｉｚｅ［３］…｝がさらには定義され、ただしｓｉｚｅ［ｎ］＝ｈｅｉｇｈｔ［ｎ］ｘ（ｌｗｉｄｔｈ［ｎ］＋ｈｗｉｄｔｈ［ｎ］）である。

９．ｓｉｚｅ［ｎ］は、最大値をサイズアレイ内に保持し、２Ｄストリングマッチの幅および高さは、対応する｛ｌｗｉｄｔｈ［ｎ］，ｒｗｉｄｔｈ［ｎ］，ｈｅｉｇｈｔ［ｎ］｝を使用して選択されることを想定する。

１Ｄまたは２Ｄ探索の速度を最適化するための１つの方途は、ランニングハッシュ（running hash）を使用することである。４画素ランニングハッシュ構造が本開示で説明される。ランニングハッシュは、水平ハッシュアレイｒｕｎｎｉｎｇ＿ｈａｓｈ＿ｈ［］を生成するために、あらゆる画素に対して水平方向で算出される。別のランニングハッシュが、２Ｄハッシュアレイｒｕｎｎｉｎｇ＿ｈａｓｈ＿ｈｖ［］を生成するために、ｒｕｎｎｉｎｇ＿ｈａｓｈ＿ｈ［］のトップで算出される。この２Ｄハッシュアレイでの各々の値マッチは、４ｘ４ブロックマッチを表す。２Ｄマッチを実施するために、４ｘ４ものブロックマッチが、それらの隣接物との画素単位での比較を実施する前に見出されることになる。画素単位での比較は１〜３個の画素に制限されるので、探索速度は劇的に増大され得る。

上記説明から、各々の行のマッチングされる幅は互いに異なり、したがって各々の行は、別々に処理されなければならない。効率および低複雑度を達成するために、ハードウェア実現形態およびソフトウェア実現形態の両方で使用され得る、ブロックに基づくアルゴリズムが開示される。標準動き推定とほとんど同様に、このアルゴリズムは、１つの矩形ブロックを１回で処理する。

４ｘ４ブロックを例として取り扱う。この設計での基本的なユニットは、図８に示されるようにＵ＿ＰＩＸＥＬと呼ばれる。コーディングされた信号は、参照画像がすでに、以前のストリングマッチ動作から符号化されているかどうかを示すフラグである。随意には、入力信号Ｃｍｐ［ｎ−１］が「０」に強制されるものであり、そのことは、Ｕ＿ＰＩＸＥＬモジュールからの最後の「ＯＲ」ゲートの除去を可能とする。

第１のステップは、各々の行を並列に処理することである。矩形の１つの行内の各々の画素は、１つのＵ＿ＰＩＸＥＬブロックに割り当てられ、この処理ユニットはＵ＿ＲＯＷと呼ばれる。第１の行に対する処理ユニットの例が図９に示される。

４つのＵ＿ＲＯＷユニットは、図１０に示されるように、この４ｘ４ブロックを処理するために必要とされる。その出力は、ｃｍｐ［４］［４］のアレイである。

次のステップは、ｃｍｐアレイの各々の列を並列に処理することである。ｃｍｐアレイの列内の各々のｃｍｐは、図１１に示されるように、処理ユニットＵ＿ＣＯＬにより処理される。

４つのＵ＿ＣＯＬユニットが、この４ｘ４ブロックを処理するために必要とされる。その出力は、図１２に示されるように、ｒｗ［４］［４］のアレイである。

ｒｗ［ｎ］［０〜３］の各々の行内のゼロの数が、次いで計数され、４つの結果が、アレイｒ＿ｗｉｄｔｈ［ｎ］に記録される。ｒ＿ｗｉｄｔｈ［ｎ］は、ステップ＃７でのｒｗｉｄｔｈ［ｎ］に等しいことに留意されたい。ｌ＿ｗｉｄｔｈ［ｎ］が、同じように生成される。ステップ＃７でのｍｉｎ＿ｗｉｄｔｈアレイは、｛｛ｌ＿ｗｉｄｔｈ［１］，ｒ＿ｗｉｄｔｈ［１］｝，｛ｌ＿ｗｉｄｔｈ［２］，ｒ＿ｗｉｄｔｈ［２］｝，｛ｌ＿ｗｉｄｔｈ［３］，ｒ＿ｗｉｄｔｈ［３］｝…｝として得られる。

このハードウェアアーキテクチャは、任意の現代のＣＰＵ／ＤＳＰ／ＧＰＵの並列処理フレームワークに適合するように修正される。高速ソフトウェア実現形態のための単純化された擬似コードが、下記にリストされる。

各々のループ内にデータ依存性は存在せず、そのため、ループ展開、ＭＭＸ／ＳＳＥなどの従前のソフトウェア並列処理方法が、実行速度を増大するために適用される。

この方法はさらには、行の数が１に制限される場合、１Ｄ探索に適用し得る。固定長さに基づく１Ｄ探索の高速ソフトウェア実現形態のための単純化された擬似コードが、下記にリストされる。

１Ｄマッチおよび２Ｄマッチの両方が完了される後に、ｍａｘ（１ｄ長さ，２ｄ（幅ｘ高さ））が勝者として選定される。２Ｄマッチのｌｗｉｄｔｈが非ゼロである場合、先の１Ｄマッチの長さ（長さ＝長さ−ｌｗｉｄｔｈ）は、先の１Ｄマッチと現在の２Ｄマッチとの間の重なりを回避するために調整される必要がある。先の１Ｄマッチの長さが調整の後でゼロになる場合、それはマッチリストから除去される。

次の開始場所は、以前のマッチが１Ｄマッチである場合はｃｕｒｒｅｎｔ＿ｌｏｃａｔｉｏｎ＋長さを、または、以前のマッチが２Ｄマッチである場合はｃｕｒｒｅｎｔ＿ｌｏｃａｔｉｏｎ＋（ｌｗｉｄｔｈ＋ｒｗｉｄｔｈ）を使用して算出される。１Ｄマッチが実施されるとき、何らかのマッチングされることになる画素が、何らかの以前の２Ｄマッチ領域であり、その場所がすでに２Ｄマッチによりカバーされている領域内に在る場合、次の画素は、画素場所であり、それが以前のマッチによりコーディングされていない場所が見出されるまで、通してスキャンされることになる。

これらのマッチングされる対を得た後に、エントロピーエンジンがこれらのシンボルをバイナリストリームに変換するために適用される。ここで例示されるのは、等確率コンテキストモードを使用することの観念である。先進的な適応的なコンテキストモードが、より良好な圧縮効率のためにもまた適用される。

示されるのは、各々のマッチングされる対に対する符号化手順である。対応して、マッチングされる対に対する復号プロセスは、次のとおりである。

マッチングされない位置での画素のみが、ビットストリームに符号化されることに留意されたい。より正確なモードの統計を有するために、このＣＵ内のすべての画素を使用する代わりに、これらの画素およびそれらの隣接物のみをカラーパレットテーブル導出に対して使用する。

これらのインデックスまたはデルタ出力に対して、それらは普通、決まった符号化モードのもとでの制限される数の一意的な値を内包する。本開示は、第２のデルタパレットテーブルを導入して、この経験的知識を利用する。このデルタパレットテーブルは、すべてのリテラルデータがこのＣＵ内で得られる後で構築され得るものであり、それは、明示的にビットストリーム内でシグナリングされることになる。あるいはそれは、テーブルがビットストリーム内に含まれる必要がないように、適応的にコーディングプロセスの間に構築され得る。ｄｅｌｔａ＿ｃｏｌｏｒ＿ｔａｂｌｅ＿ａｄａｐｔｉｖｅ＿ｆｌａｇが、この選定のために定義される。

隣接のデルタカラーパレットテーブルマージと呼ばれる、別の先進的な体系が提供される。適応的なデルタパレット生成のために、符号化器は、トップまたは左ＣＵからのデルタパレットを初期開始ポイントとして使用することもできる。非適応的なパレット生成のために、符号化器はさらには、トップまたは左ＣＵからのデルタパレットを使用し、ＲＤコストをトップ、左、および現在のＣＵの間で比較する。

ｄｅｌｔａ＿ｃｏｌｏｒ＿ｔａｂｌｅ＿ｍｅｒｇｅ＿ｆｌａｇが、現在のＣＵがその左または上部ＣＵからのデルタカラーパレットテーブルを使用するかどうかを示すために定義される。現在のＣＵは、同じ時間にｄｅｌｔａ＿ｃｏｌｏｒ＿ｔａｂｌｅ＿ａｄａｐｔｉｖｅ＿ｆｌａｇ＝＝０およびｄｅｌｔａ＿ｃｏｌｏｒ＿ｔａｂｌｅ＿ｍｅｒｇｅ＿ｆｌａｇ＝＝０であるときにのみ、デルタカラーパレットテーブルシグナリングを明示的に搬送する。

マージングプロセスに対して、ｄｅｌｔａ＿ｃｏｌｏｒ＿ｔａｂｌｅ＿ｍｅｒｇｅ＿ｆｌａｇがアサートされる場合、別のｄｅｌｔａ＿ｃｏｌｏｒ＿ｔａｂｌｅ＿ｍｅｒｇｅ＿ｄｉｒｅｃｔｉｏｎが、マージ候補が上部ＣＵからであるか、それとも、さもなければ左ＣＵからであるかを示すために定義される。

適応的なデルタパレット生成のための符号化プロセスの例が、後に続くように示される。復号側では、復号器がリテラルデータを受信するときはいつも、それは、デルタパレットを逆のステップに基づいて再生成する。

１０．ｐａｌｅｔｔｅ＿ｔａｂｌｅ［］およびｐａｌｅｔｔｅ＿ｃｏｕｎｔ［］を定義する。

１１．ｐａｌｅｔｔｅ＿ｔａｂｌｅ（ｎ）＝ｎ（ｎ＝０…２５５）と初期化する、あるいはそれは、トップまたは左ＣＵからのｐａｌｅｔｔｅ＿ｔａｂｌｅ［］を初期値として使用する。

１２．ｐａｌｅｔｔｅ＿ｃｏｕｎｔ（ｎ）＝０（ｎ＝０…２５５）と初期化する、あるいはそれは、トップまたは左ＣＵからのｐａｌｅｔｔｅ＿ｃｏｕｎｔ［］を初期値として使用する。

１３．任意のデルタ値ｃ’に対して、
１）ｎを、ｐａｌｅｔｔｅ＿ｔａｂｌｅ（ｎ）＝＝デルタｃ’であるように位置決めする。

２）ｎを、デルタｃ’の新しいインデックスとして使用する。

３）＋＋ｐａｌｅｔｔｅ＿ｃｏｕｎｔ（ｎ）
４）ｐａｌｅｔｔｅ＿ｃｏｕｎｔ［］を、それが、下降する順序であるようにソートする。

５）ｐａｌｅｔｔｅ＿ｔａｂｌｅ［］を、それにしたがってソートする。

１４．現在のＬＣＵ内のすべてのデルタｃ’が処理されるまで、ステップ１に戻るように進む。

テキストおよびグラフィックスの両方を含む任意のブロックに対して、マスクフラグが、テキストセクションおよびグラフィックスセクションを分離するために使用される。テキストセクションは、上記で説明された方法により圧縮され、グラフィックスセクションは、別の圧縮方法により圧縮される。

マスクフラグによりカバーされる任意の画素の値は、テキストレイヤにより無損失にコーディングされているので、グラフィックスセクション内のこれらの画素は、「ドントケア画素」としてのものであることに留意されたい。グラフィックスセクションが圧縮されるとき、何らかの任意の値が、最適な圧縮効率を得るために、ドントケア画素に割り当てられる。

有損失部分はカラーパレットテーブル導出によりハンドリングされるので、インデックスマップは、無損失に圧縮されなければならない。これは、１Ｄまたは２Ｄストリングマッチを使用する効率的な処理を可能とする。本開示に対しては、１Ｄまたは２Ｄストリングマッチは現在のＬＣＵで制約されるが、探索窓は、現在のＬＣＵを越えて拡張となり得る。さらには、マッチングされる距離は、動きベクトルの対を使用して、水平および垂直方向で符号化される、すなわち、（ＭＶｙ＝ｍａｔｃｈｅｄ＿ｄｉｓｔａｎｃｅ／ｃｕＷｉｄｔｈ、ＭＶｙ＝ｍａｔｃｈｅｄ＿ｄｉｓｔａｎｃｅ−ｃｕＷｉｄｔｈ＊ＭＶｙ）であることに留意されたい。

画像が、異なる空間テクスチャ定位を局所的な領域で有することになれば、１Ｄ探索は、水平方向または垂直方向のいずれかで、ｃｏｌｏｒ＿ｉｄｘ＿ｍａｐ＿ｐｒｅｄ＿ｄｉｒｅｃｔｉｏｎインジケータを定義することにより可能とされる。最適なインデックススキャニング方向が、Ｒ−Ｄコストに基づいてなされる。図６は、まさに第１の位置から開始する、スキャニング方向を示す。さらに例示されるのは、図９での水平および垂直スキャニングパターンである。８ｘ８ＣＵを例として考える。ｄｅｒｉｖｅＭａｔｃｈＰａｉｒｓ（）、および、関連付けられるエントロピーコーディングステップが、水平スキャニングパターンおよび垂直スキャニングパターンの両方に対して２回実施される。次いで、最終的なスキャニング方向が、最も小さなＲＤコストによって選定される。

改善されたバイナリ化
図１３に示されるように、カラーパレットテーブル、およびカラーインデックスマップに対するマッチングされる情報の対が符号化される。それらは、固定された長さバイナリ化を使用して符号化される。あるいは、可変長さバイナリ化が使用される。

例えば、カラーパレットテーブル符号化に関して、テーブルは８つの異なるカラー値を有する。したがってそれは、８つの異なるインデックスをカラーインデックスマップ内に内包するのみである。固定された３つのビンを使用して、あらゆるインデックス値を等しく符号化する代わりに、１つのビットだけが、背景画素を表すために使用されるものであり、実例として０である。次いで残りの７つの画素値が、カラーインデックスを符号化するための１０００、１００１、１０１０、１０１１、１１００、１１０１、および１１１０などの、固定された長さコード語を使用する。これは、背景カラーは最も大きなパーセンタイルを占有するものであり、したがって、それに対する特別なコード語は総合的なビンを節約するという事実に基づく。このシナリオは、スクリーンコンテンツに対して普通に起こる。１６ｘ１６ＣＵを考えると、固定された３ビンバイナリ化に対して、それは３ｘ１６ｘ１６＝７６８個のビンを要する。さらには、０インデックスを、４０％を占有する背景カラーであるとし、一方、他のカラーは等しく分散される。この事例では、それは、２．８ｘ１６ｘ１６＜７６８個のビンを要するのみである。

現在のＣＵの区域内部のこの手法の制約実施であれば、マッチングされる対符号化に対して、ｍａｘ値が、そのバイナリ化を境界設定するために使用される。数学的には、マッチングされる距離および長さは、各々の事例では、６４ｘ６４＝４Ｋほどに長い。しかし、これは、連帯的に起こってはいないであろう。あらゆるマッチングされる位置に対して、マッチングされる距離は、現在の位置と、参照バッファ内のまさに第１の位置（例として、現在のＣＵ内の第１の位置など）との間の距離、実例としてＬにより境界設定される。したがって、この距離バイナリ化に対する最大ビンは、（固定された長さの代わりに）ｌｏｇ２（Ｌ）＋１であり、長さバイナリ化に対する最大ビンは、ｌｏｇ２（ｃｕＳｉｚｅ−Ｌ）＋１であり、ただしｃｕＳｉｚｅ＝ｃｕＷｉｄｔｈ＊ｃｕＨｅｉｇｈｔである。

カラーパレットテーブルおよびインデックスマップに加えて、残差コーディングが、異なるバイナリ化方法により有意に改善される。ＨＥＶＣ ＲＥｘｔおよびＨＥＶＣバージョンに関して、トランスフォーム係数は、残差大きさは予測、トランスフォーム、および量子化の後では小さいはずであるという想定での、可変長さコードを使用するバイナリ化である。しかし、トランスフォームスキップを導入した後に、特に、独特なカラーを伴うスクリーンコンテンツ上のトランスフォームスキップに対して普通は、より大きくランダムな値（「１」、「２」、「０」の相対的なより小さな値に近くない）を伴う残差が存在する。現在のＨＥＶＣ係数バイナリ化が使用される場合、それは、非常に長いコード語を生むことがわかる。あるいは、固定された長さバイナリ化を使用することが、カラーパレットテーブルおよびインデックスコーディングモードにより導かれる残差に対するコード長さを節約する。

混在したコンテンツに対する適応的なクロマサンプリング

以上では、ＨＥＶＣ／ＨＥＶＣ−ＲＥｘｔのフレームワークのもとでの高効率スクリーンコンテンツコーディングのための様々な技法を提供する。実際上は、純粋なスクリーンコンテンツ（テキスト、グラフィックスなど）、または純粋な自然なビデオに加えて、混在させられるコンテンツと呼ばれる、スクリーン素材、および、カメラで捕捉される自然なビデオの両方を内包するコンテンツも存在する。現在、混在するコンテンツは、４：４：４クロマサンプリングによって扱われる。しかしながら、そのような混在するコンテンツ内の、埋め込まれる、カメラで捕捉される自然なビデオ小部分に対して、４：２：０クロマサンプリングが、知覚的な無損失品質を提供するのに充分である。これは、ヒューマンビジョンシステムが、ルーマ成分からのものと比較されると、クロマ成分の空間変化に対して、より敏感でないという事実に起因する。ゆえに、サブサンプリングが典型的には、顕著なビットレート低減を達成する一方、同じ再構築される品質を維持するために、クロマ部分上で実施される（例えば、広く普及した４：２：０ビデオフォーマット）。

本開示は、ＣＵレベルで再帰的に定義およびシグナリングされる、新しいフラグ（すなわち、ｅｎａｂｌｅ＿ｃｈｒｏｍａ＿ｓｕｂｓａｍｐｌｉｎｇ）を提供する。各々のＣＵについて、符号化器は、それが４：２：０を使用してコーディングされているか、それとも４：４：４を使用してコーディングされているかを、レート−歪みコストによって決定する。

図１４Ａおよび図１４Ｂに示されるのは、４：２：０および４：４：４クロマサンプリングフォーマットである。

符号化器側では、各々のＣＵについて、入力が上記で示した４：４：４ソースであると想定して、レート−歪みコストが直接ｅｎａｂｌｅ＿ｃｈｒｏｍａ＿ｓｕｂｓａｍｐｌｉｎｇ＝０またはＦＡＬＳＥを伴う４：４：４符号化手順を使用して導出される。次いでプロセスは、４：４：４サンプルを４：２：０にサブサンプリングして、そのビット消費量を導出する。再構築される４：２：０フォーマットは、（ＳＳＥ／ＳＡＤを使用する）歪み測定のために、４：４：４フォーマットに戻るように補間される。ビット消費量とともに、レート−歪みコストが、ＣＵを４：２：０空間で符号化し、それを、ＣＵを４：４：４で符号化するときのコストと比較するときに導出される。より少ないレート−歪みコストを与える符号化はどれでも、最終的な符号化に対して選定されることになる。

図１５で例示されるのは、４：４：４から４：２：０への、およびその逆の補間プロセスである。普通はこのビデオカラーサンプリングフォーマット変換プロセスは、大きな数の補間フィルタを要する。

実現形態複雑度を低減するために、ＨＥＶＣ補間フィルタ（すなわち、ＤＣＴ−ＩＦ）が利用され得る。図１５に示されるように、「方形の箱」は元の４：４：４サンプルを表す。４：４：４から４：２：０へと、ハーフペル画素（「円」）が、ＤＣＴ−ＩＦを使用して、クロマ成分に対して垂直に補間される。さらに示されるのは、例示目的でのクォーターペル位置（「菱形」）である。灰色で暗くされた「円」が、４：２：０サンプルを形成するために選び出される。４：２：０から４：４：４への補間のために、プロセスは、クロマ成分内の灰色「円」によって開始し、ハーフペル位置が、すべての「円」を得るために水平に補間され、次いで「方形の箱」が、ＤＣＴ−ＩＦを使用して垂直に補間される。補間される「方形の箱」すべてが、再構築される４：４：４ソースを形成するために選定される。

符号化器制御

以前のセクションで考察されたように、開示されるのは、低レベル処理を制御するためのフラグである。実例としてｅｎａｂｌｅ＿ｐａｃｋｅｄ＿ｃｏｍｐｏｎｅｎｔ＿ｆｌａｇは、現在のＣＵが、処理を符号化するために、そのパックドフォーマットを使用するか、それとも、従来のプレーナフォーマットを使用するかを示すために使用される。パックドフォーマットを可能にすべきかどうかは、符号化器で算出されるＲ−Ｄコストに依存し得る。実際上の符号化器実現形態に対して、低複雑度ソリューションが、図３で示されるように、ＣＵのヒストグラムを分析し、判断のための最も良好なしきい値を見出すことにより達成される。

カラーパレットテーブルのサイズは、複雑度への直接の影響を有する。ｍａｘＣｏｌｏｒＮｕｍが、複雑度とコーディング効率との間の相反関係を制御するために導入される。最も平易な方途は、最も少ないＲ−Ｄコストを生むものを選定することである。

インデックスマップ符号化方向は、Ｒ−Ｄ最適化により、または、（ｓｏｂｅｌオペレータに基づく方向推定などの）局所的な空間定位を使用して決定される。

本開示は、処理をあらゆるＣＴＵ／ＣＵ内部で制限する。実際上は、この制約は緩和され得る。例えばカラーインデックスマップ処理に対して、その上部および左ＣＵからのラインバッファが、図１６に示されるように使用される。上部および左バッファによって探索は、コーディング効率をさらに改善するために拡張される。上部／左バッファが隣接のＣＵからの再構築される画素を使用して形成されれば、これらの画素（および、その対応するインデックス）は、現在のＣＵインデックスマップを処理する前に参照のために利用可能である。実例として、再順序付けの後で、現在のＣＵインデックスマップは、（１Ｄ提示として）１４、１４、１４、…１、２、１であり得る。ラインバッファ参照なしでは、第１の「１４」は、マッチングされない対としてコーディングされることになる。しかしながら、隣接のラインバッファによって、ストリングマッチが、下記で示されるように、まさに第１の画素で開始し得る（水平および垂直スキャニングパターンもまた示される）。

復号器シンタックス

後述する情報は、図２に示される復号器を説明するために使用される。本開示のシンタックスは、ＨＥＶＣ ＲＥｘｔの委員会草案と整合する。

７．３．５．８ コーディングユニットシンタックス：

図１７は、現在のＨＥＶＣに組み込まれる装置および方法／フローを例示する。

上記識別された方法／フローおよびデバイスは、ワイヤレス、またはワイヤード、またはそれらの組み合わせの通信ネットワークに組み込まれ、下記で、および下記図面で説明するものなどのデバイスで実現され得る。

図１８は、シグナリングを使用して、本開示による先進的なワイヤレス受信器をサポートする、例通信システム１００を例示する。一般的にシステム１００は、多重のワイヤレスユーザが、データおよび他のコンテンツを、送信および受信することを可能にする。システム１００は、符号分割多元接続（ＣＤＭＡ：code division multiple access）、時分割多元接続（ＴＤＭＡ：time division multiple access）、周波数分割多元接続（ＦＤＭＡ：frequency division multiple access）、直交ＦＤＭＡ（ＯＦＤＭＡ）、または単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ：single-carrier FDMA）などの、１または複数のチャネルアクセス方法を実現し得る。

この例では通信システム１００は、ユーザ機器（ＵＥ：user equipment）１１０ａ〜１１０ｃ、無線アクセスネットワーク（ＲＡＮ：radio access network）１２０ａ〜１２０ｂ、コアネットワーク１３０、公衆交換電話ネットワーク（ＰＳＴＮ：public switched telephone network）１４０、インターネット１５０、および、他のネットワーク１６０を含む。決まった数のこれらの構成要素または要素が図１８に示されるが、任意の数のこれらの構成要素または要素がシステム１００内に含まれる。

ＵＥ１１０ａ〜１１０ｃは、システム１００内で動作および／または通信するように構成される。例えばＵＥ１１０ａ〜１１０ｃは、ワイヤレス信号またはワイヤード信号を、送信および／または受信するように構成される。各々のＵＥ１１０ａ〜１１０ｃは、任意の適したエンドユーザデバイスを表し、ユーザ機器／デバイス（ＵＥ）、ワイヤレス送信／受信ユニット（ＷＴＲＵ：wireless transmit/receive unit）、移動局、固定された、もしくは移動の加入者ユニット、ページャ、セルラー電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、コンピュータ、タッチパッド、ワイヤレスセンサ、または消費者電子機器デバイスのようなデバイスを含み得る（または、それらのものと称され得る）。

ＲＡＮ１２０ａ〜１２０ｂはここでは、それぞれ基地局１７０ａ〜１７０ｂを含む。各々の基地局１７０ａ〜１７０ｂは、ＵＥ１１０ａ〜１１０ｃの１または複数とワイヤレスでインターフェイス接続して、コアネットワーク１３０、ＰＳＴＮ１４０、インターネット１５０、および／または他のネットワーク１６０へのアクセスを可能にするように構成される。例えば基地局１７０ａ〜１７０ｂは、基地トランシーバ局（ＢＴＳ）、ノード−Ｂ（ノードＢ）、進化型ノードＢ（ｅノードＢ）、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）もしくはワイヤレスルータ、または、ワイヤードもしくはワイヤレスネットワークを伴う、サーバ、ルータ、スイッチもしくは他の処理エンティティなどの、いくつかのよく知られているデバイスの１または複数を含み得る（または、それらであり得る）。

図１８に示される実施形態では、基地局１７０ａは、他の基地局、要素、および／またはデバイスを含み得る、ＲＡＮ１２０ａの部分を形成する。さらには、基地局１７０ｂは、他の基地局、要素、および／またはデバイスを含み得る、ＲＡＮ１２０ｂの部分を形成する。各々の基地局１７０ａ〜１７０ｂは、時には「セル」と称される、個別の地理的領域または区域内部で、ワイヤレス信号を送信および／または受信するように動作する。一部の実施形態では、多重のトランシーバを各々のセルに対して有する、多重入力多重出力（ＭＩＭＯ：multiple-input multiple-output）技術が用いられ得る。

基地局１７０ａ〜１７０ｂは、ＵＥ１１０ａ〜１１０ｃの１または複数と、１または複数のエアインターフェイス１９０を介して、ワイヤレス通信リンクを使用して通信する。エアインターフェイス１９０は、任意の適した無線アクセス技術を利用し得る。

システム１００は、上記で説明されたような体系を含む、多重チャネルアクセス機能を使用し得ることが企図される。個別の実施形態では、基地局およびＵＥは、ＬＴＥ、ＬＴＥ−Ａ、および／またはＬＴＥ−Ｂを実現する。当然ながら、他の多元接続体系およびワイヤレスプロトコルが利用され得る。

ＲＡＮ１２０ａ〜１２０ｂは、ＵＥ１１０ａ〜１１０ｃに、ボイス、データ、アプリケーション、ボイスオーバーインターネットプロトコル（ＶｏＩＰ）、または他のサービスを提供するために、コアネットワーク１３０との通信の状態にある。理解可能であるが、ＲＡＮ１２０ａ〜１２０ｂおよび／またはコアネットワーク１３０は、１または複数の他のＲＡＮ（示されない）との、直接または間接の通信の状態にあり得る。コアネットワーク１３０はさらには、他のネットワーク（ＰＳＴＮ１４０、インターネット１５０、および、他のネットワーク１６０など）に対するゲートウェイアクセスとして役立ち得る。追加で、ＵＥ１１０ａ〜１１０ｃの一部またはすべては、異なるワイヤレスネットワークと、異なるワイヤレスリンクを介して、異なるワイヤレス技術および／またはプロトコルを使用して通信するための機能を含み得る。

図１８は通信システムの１つの例を例示するが、様々な変化が図１８に対してなされ得る。例えば通信システム１００は、任意の数のＵＥ、基地局、ネットワーク、または、他の構成要素を、任意の適した構成で含み得るものであり、本明細書の図の任意のもので例示されるＥＰＣをさらに含み得る。

図１９Ａおよび１９Ｂは、本開示による方法および教示を実現し得る例デバイスを例示する。特に、図１９Ａは例ＵＥ１１０を例示し、図１９Ｂは例基地局１７０を例示する。これらの構成要素は、システム１００内で、または、任意の他の適したシステム内で使用され得る。

図１９Ａに示されるように、ＵＥ１１０は、少なくとも１つの処理ユニット２００を含む。処理ユニット２００は、ＵＥ１１０の様々な処理動作を実現する。例えば処理ユニット２００は、ＵＥ１１０がシステム１００内で動作することを可能にする、信号コーディング、データ処理、電力制御、入力／出力処理、または、任意の他の機能を実施し得る。処理ユニット２００はさらには、上記でより詳細に説明された方法および教示をサポートする。各々の処理ユニット２００は、１または複数の動作を実施するように構成される、任意の適した処理またはコンピューティングデバイスを含む。各々の処理ユニット２００は例えば、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、フィールドプログラマブルゲートアレイ、または特定用途向け集積回路を含み得る。

ＵＥ１１０はさらには、少なくとも１つのトランシーバ２０２を含む。トランシーバ２０２は、少なくとも１つのアンテナ２０４による送信のために、データまたは他のコンテンツを変調するように構成される。トランシーバ２０２はさらには、少なくとも１つのアンテナ２０４により受信される、データまたは他のコンテンツを復調するように構成される。各々のトランシーバ２０２は、ワイヤレス送信のための信号を生成する、および／または、ワイヤレスで受信される信号を処理するための、任意の適した構造を含む。各々のアンテナ２０４は、ワイヤレス信号を送信および／または受信するための、任意の適した構造を含む。１つまたは多重のトランシーバ２０２がＵＥ１１０内で使用され得るものであり、１つまたは多重のアンテナ２０４がＵＥ１１０内で使用され得る。単一の機能ユニットとして示されるが、トランシーバ２０２はさらには、少なくとも１つの送信器、および、少なくとも１つの別々の受信器を使用して実現される。

ＵＥ１１０は、１または複数の入力／出力デバイス２０６をさらに含む。入力／出力デバイス２０６は、ユーザとの対話を容易にする。各々の入力／出力デバイス２０６は、スピーカ、マイクロホン、キーパッド、キーボード、ディスプレイ、またはタッチスクリーンなどの、情報をユーザに提供する、または、情報をユーザから受信するための、任意の適した構造を含む。

さらに、ＵＥ１１０は、少なくとも１つのメモリ２０８を含む。メモリ２０８は、ＵＥ１１０により使用、生成、または収集される命令およびデータを記憶する。例えばメモリ２０８は、処理ユニット２００により実行されるソフトウェアまたはファームウェア命令、および、入来する信号での干渉を低減する、または消失させるために使用されるデータを記憶し得る。各々のメモリ２０８は、任意の適した揮発性および／または不揮発性記憶ならびに検索デバイスを含む。ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、ハードディスク、光学ディスク、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード、および類するものなどの、任意の適したタイプのメモリが使用され得る。

図１９Ｂに示されるように、基地局１７０は、少なくとも１つの処理ユニット２５０、少なくとも１つの送信器２５２、少なくとも１つの受信器２５４、１または複数のアンテナ２５６、および、少なくとも１つのメモリ２５８を含む。処理ユニット２５０は、信号コーディング、データ処理、電力制御、入力／出力処理、または、任意の他の機能などの、基地局１７０の様々な処理動作を実現する。処理ユニット２５０はさらには、上記でより詳細に説明された方法および教示をサポートすることができる。各々の処理ユニット２５０は、１または複数の動作を実施するように構成される、任意の適した処理またはコンピューティングデバイスを含む。各々の処理ユニット２５０は例えば、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、フィールドプログラマブルゲートアレイ、または特定用途向け集積回路を含み得る。

各々の送信器２５２は、１または複数のＵＥまたは他のデバイスへのワイヤレス送信のための信号を生成するための、任意の適した構造を含む。各々の受信器２５４は、１または複数のＵＥまたは他のデバイスからワイヤレスで受信される信号を処理するための、任意の適した構造を含む。別々の構成要素として示されるが、少なくとも１つの送信器２５２、および、少なくとも１つの受信器２５４は、トランシーバに組み合わせることができる。各々のアンテナ２５６は、ワイヤレス信号を送信および／または受信するための、任意の適した構造を含む。共通のアンテナ２５６はここでは、送信器２５２および受信器２５４の両方に結合されているように示されるが、１または複数のアンテナ２５６が送信器２５２に結合されるものであり、１または複数の別々のアンテナ２５６が受信器２５４に結合するようにしてもよい。各々のメモリ２５８は、任意の適した揮発性および／または不揮発性記憶ならびに検索デバイスを含む。

ＵＥ１１０および基地局１７０に関する追加的な詳細は、当業者に知られている。したがって、これらの詳細はここでは明瞭性のために省略される。

本特許文書の全体を通して使用する決まった語および句の定義を明らかにすることは有益であり得る。用語「含む」および「備える」、ならびにそれらの派生語は、制限を伴わない包含を意味する。用語「または」は包含的であり、および／または、を意味する。句「〜に関連付けられる」および「それに関連付けられる」、ならびにそれらの派生語は、〜の内部に含まれる、〜と相互接続する、内包する、〜の内部に内包される、〜に、もしくは、〜と接続する、〜に、もしくは、〜と結合する、〜と通信可能である、〜と協調する、インターリーブする、並置する、〜に近接する、〜に、もしくは、〜と結び付けられる、有する、〜の特質を有する、または類するものを含むことを意味する。

本開示は、決まった実施形態、および、一般的に関連付けられる方法を説明したが、これらの実施形態および方法の、改変および置き換えが、当業者には明白になるだあろう。したがって、例示的な実施形態の上記説明は、本開示を定義または制約しない。他の変化、置換、および改変がさらには、特許請求の範囲により定義されるような、本開示の趣旨および範囲から逸脱することなく可能である。

Claims (20)

1. スクリーンコンテンツをビットストリームにコーディングするための方法であって、
   スクリーンコンテンツのコーディングユニット（ＣＵ）についてのカラーパレットテーブルを選択するステップと、
   前記ＣＵについてのインデックスを有するカラーインデックスマップを、前記選択されたカラーパレットテーブルを使用して作成するステップと、
   前記選択されたカラーパレットテーブルおよび前記カラーインデックスマップを、前記ＣＵについて、ビットストリームに符号化するステップと
   を備え、
   前記カラーパレットテーブルは、隣接のＣＵから、画素ドメイン内の再構築されたＣＵを使用して導出される
   ことを特徴とする方法。
2. 前記方法は、プレーナカラーフォーマット、またはインターリーブされたカラーフォーマットを使用して処理されることを特徴とする請求項１に記載の方法。
3. 前記方法は、ＣＵレベル、スライスレベル、ピクチャレベル、またはシーケンスレベルの群から選択されたレベルで処理されることを特徴とする請求項２に記載の方法。
4. 前記隣接のＣＵのカラーパレットテーブルを、前記ＣＵの深度およびサイズに関わらず、利用可能な再構築された画素に基づいて生成するステップをさらに備えることを特徴とする請求項１に記載の方法。
5. 前記隣接のＣＵのカラーパレットテーブルを生成するステップであって、前記隣接のＣＵは、カラーパレットモードを使用して符号化される、生成するステップをさらに備えることを特徴とする請求項１に記載の方法。
6. 前記隣接のＣＵのカラーパレットテーブルは、カラーパレットモードを使用して符号化されることを特徴とする請求項１に記載の方法。
7. 前記カラーパレットテーブルは、復号器で画素ドメインで導出され、前記符号化されたビットストリームは、前記ＣＵについて、前記カラーパレットテーブルおよび前記カラーインデックスマップを再構築するためにパースされることを特徴とする請求項１に記載の方法。
8. 画素値は、前記ＣＵ内の各々の位置で、カラーインデックスおよびカラーパレットテーブルを組み合わせることにより導出されることを特徴とする請求項４に記載の方法。
9. 以前の導出されたカラーパレットテーブルに基づいて、前記ＣＵのカラーまたは画素値を、対応するインデックスに対して分類するステップをさらに備えることを特徴とする請求項１に記載の方法。
10. 前記カラーパレットテーブルは、ヒストグラムによって、生成および順序付けされることを特徴とする請求項１に記載の方法。
11. 前記ＣＵの各々の画素は、前記カラーパレットテーブル内部のカラーインデックスに変換されることを特徴とする請求項１に記載の方法。
12. フラグは、前記ＣＵについて、前記ＣＵがパックド式またはプレーナモードを使用して処理されるかを示すために定義されることを特徴とする請求項２に記載の方法。
13. 前記カラーパレットテーブルは、前記カラーパレットテーブルのサイズ、および前記カラーパレットテーブル内の各々のカラーを符号化することにより処理されることを特徴とする請求項１に記載の方法。
14. 前記ＣＵは、その左または上部ＣＵからの前記カラーパレットテーブルを使用することを示すフラグを生成するステップをさらに備えることを特徴とする請求項１に記載の方法。
15. 前記カラーインデックスマップは、１次元（１−Ｄ）ストリングマッチ、ハイブリッド１−Ｄストリングマッチ、および２次元（２−Ｄ）ストリングマッチを備える群から選択されたストリングマッチを使用して符号化され、
    前記ストリングマッチは、マッチングされる対を使用してシグナリングされることを特徴とする請求項１に記載の方法。
16. 前記ストリングマッチは、ランニングハッシュ方法を使用して実施されることを特徴とする請求項１５に記載の方法。
17. ２次元（２−Ｄ）ストリングマッチは、前記カラーインデックスマップに対して、前記ＣＵ内の現在の画素の場所および参照画素の場所を、開始ポイントとして識別することにより実施されることを特徴とする請求項１に記載の方法。
18. 前記ＣＵは、ダウンサンプリングされた４：２：０サンプリングフォーマットを使用して処理された４：４：４フォーマットを有することを特徴とする請求項１に記載の方法。
19. 前記ダウンサンプリングされたフォーマットは、ＣＵレベル、スライスレベル、ピクチャレベル、またはシーケンスレベルの群から選択されたレベルで処理されることを特徴とする請求項１８に記載の方法。
20. スクリーンコンテンツをビットストリームにコーディングするためのプロセッサであって、
    スクリーンコンテンツのコーディングユニット（ＣＵ）についてのカラーパレットテーブルを選択し、
    前記ＣＵについてのインデックスを有するカラーインデックスマップを、前記選択されたカラーパレットテーブルを使用して作成し、
    前記選択されたカラーパレットテーブルおよび前記カラーインデックスマップを、前記ＣＵについて、ビットストリームに符号化する
    ように構成され、
    前記カラーパレットテーブルは、隣接のＣＵから、画素ドメイン内の再構築されたＣＵを使用して導出される
    ことを特徴とするプロセッサ。

Images