【文献】
          Xiaoyu Xiu 9710 Scranton Rd, #250 San Diego, CA 92121,Description of screen content coding technology proposal by InterDigital[online],  JCTVC-Q    JCTVC-Q0037,インターネット<URL:http://phenix.it-sudparis.eu/jct/doc_end_user/documents/17_Valencia/wg11/JCTVC-Q0037-v4.zip>,pp.5,6,9
        
      
    (58)【調査した分野】(Int.Cl.,DB名)
  前記パターンデータベースに前記第1のパターンを追加するステップは、前記パターンデータベース中の直近に使われたパターンであるパターンを表す、前記パターンデータベース中のロケーションに、前記第1のパターンを追加するステップを含む、請求項1に記載の方法。
  前記第1のパターンが前記パターンデータベース中にないと判断するステップは、前記パターンデータベース中の各パターンについて、(i)前記第1のパターンの少なくとも1つの構成要素と、前記パターンデータベース中の前記パターンとの間の差が第1の閾値を超えると判断するステップ、または(ii)前記第1のパターンの各成分と、前記データベース中の前記パターンの対応する成分との間の差の合計が第2の閾値を超えると判断するステップのうちの少なくとも1つを含む、請求項1に記載の方法。
  前記1つまたは複数の閾基準は、(i)前記第2のブロックが、同じスライス中にいかなる先行ブロックも有していないかどうか、(ii)前記第2のブロックが、同じスライス中のいかなる先行ブロックも有していない、連続するブロックのグループ中にあるかどうか、または(iii)前記パターンデータベースが満杯でないかどうか、のうちの1つを含む、請求項9に記載の方法。
  前記第1のパターンは損失ありでシグナリングされ、前記第1のパターンは、前記現在のブロックに関連付けられた量子化パラメータに基づく量だけ量子化され、前記量子化された第1のパターンは、前記第1のパターンがキャプチャされたソースビット深度よりも低いビット深度を有する、請求項1に記載の方法。
  前記プロセッサは、前記パターンデータベース中の直近に使われたパターンであるパターンを表す、前記パターンデータベース中のロケーションに、前記第1のパターンを追加するようにさらに構成される、請求項14に記載の装置。
  前記プロセッサは、前記パターンデータベース中の各パターンについて、(i)前記第1のパターンの少なくとも1つの構成要素と、前記パターンデータベース中の前記パターンとの間の差が第1の閾値を超えると判断し、または(ii)前記第1のパターンの各成分と、前記データベース中の前記パターンの対応する成分との間の差の合計が第2の閾値を超えると判断するようにさらに構成される、請求項14に記載の装置。
  前記1つまたは複数の閾基準は、(i)前記第2のブロックが、同じスライス中にいかなる先行ブロックも有していないかどうか、(ii)前記第2のブロックが、同じスライス中のいかなる先行ブロックも有していない、連続するブロックのグループ中にあるかどうか、または(iii)前記パターンデータベースが満杯でないかどうか、のうちの1つを含む、請求項22に記載の装置。
  前記プロセッサは、前記第1のパターンがキャプチャされたソースビット深度を使って無損失で、前記第1のパターンをシグナリングするようにさらに構成される、請求項14に記載の装置。
  前記プロセッサは、前記第1のパターンを損失ありでシグナリングするようにさらに構成され、前記第1のパターンは、前記現在のブロックに関連付けられた量子化パラメータに基づく量だけ量子化され、前記量子化された第1のパターンは、前記第1のパターンがキャプチャされたソースビット深度よりも低いビット深度を有する、請求項14に記載の装置。
  前記コードはさらに、前記装置に、前記パターンデータベース中の直近に使われたパターンであるパターンを表す、前記パターンデータベース中のロケーションに、前記第1のパターンを追加させる、請求項26に記載のコンピュータ可読記録媒体。
  前記パターンデータベース中の直近に使われたパターンであるパターンを表す、前記パターンデータベース中のロケーションに、前記第1のパターンを追加するための手段をさらに備える、請求項29に記載のビデオコーディングデバイス。
【発明を実施するための形態】
【0011】
  概して、本開示は、DSCなどのビデオ圧縮技法を改良する方法に関する。より詳細には、本開示は、起こり得る一致を求めてパターンデータベースを探索し、パターンデータベース中で一致が見つからないときはパターンデータベースを更新するためのシステムおよび方法に関する。
 
【0012】
  いくつかの実施形態は、DSC規格のコンテキストにおいて本明細書において説明されるが、本明細書で開示するシステムおよび方法は、どの適切なビデオコーディング規格にも適用可能であり得ることが当業者には諒解されよう。たとえば、本明細書で開示する実施形態は、国際電気通信連合(ITU)電気通信規格化部門(ITU-T)H.261、国際標準化機構/国際電気標準会議(ISO/IEC)Moving Picture Experts Group-1(MPEG 1)Visual、ITU-T H.262またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG 4 Visual、ITU-T H.264(ISO/IEC MPEG-4 AVCとしても知られる)、高効率ビデオコーディング(HEVC)という規格のうちの1つまたは複数、およびそのような規格へのいかなる拡張にも適用可能であり得る。また、本開示に記載する技法は、将来開発される規格の一部になる可能性がある。言い換えると、本開示に記載する技法は、以前開発されたビデオコーディング規格、現在開発中のビデオコーディング規格、および今度のビデオコーディング規格に適用可能であり得る。
 
【0013】
  将来のDSC規格のための提案されているアルゴリズムは、ビデオデータの各ブロックがエンコーダによって符号化され、同様に、デコーダによって復号され得るいくつかのコーディングモードを含む。いくつかの実装形態では、エンコーダおよびデコーダは、頻繁に使われるピクセル値のデータベースと、実際のピクセル値ではなく、シグナリングするのによりコストがかかり得る、(たとえば、エンコーダがシグナリングすることができ、デコーダが参照することができる)データベース索引(Database Index)とを維持することができる。ただし、そのような実装形態のうちのいくつかは、そのようなコーディングモードでブロックをコーディングする前に、ブロック中に含まれる各ピクセルがデータベース中に存在することを要求する場合がある。さらに、他の実装形態は、エンコーダ側ならびにデコーダ側におけるデータベースの探索を伴う、コストがかかるデータベース更新プロセスを必要とする場合がある。したがって、パターンデータベースを実装する改良された方法が所望される。
 
【0014】
  本開示では、パターンモードでブロックをコーディングする改良された方法について記載する。たとえば、この方法は、コーディングされている現在のブロック中の各ピクセルがデータベース中に存在することを必要としなくてよい。さらに、この方法は、現在のブロック中のピクセルと、データベース中に記憶されたピクセルとの間の完全な一致を必要としなくてよい。さらに、本開示による、パターンデータベースを更新するプロセスは、デコーダによるパターンデータベースの探索を必要としなくてよく、より簡素なハードウェア設計につながる。
 
【0015】
ビデオコーディング規格
  ビデオ画像、TV画像、静止画像またはビデオレコーダもしくはコンピュータによって生成された画像などのデジタル画像は、水平および垂直ライン中に配列されたピクセルまたはサンプルを含み得る。単一の画像中のピクセルの数は通常、数万である。各ピクセルは通常、ルミナンスおよびクロミナンス情報を含む。圧縮なしだと、画像エンコーダから画像デコーダへ伝えられるべき莫大な量の情報により、リアルタイムの画像送信が非現実的になる。送信されるべき情報の量を削減するために、JPEG、MPEGおよびH.263規格など、いくつかの異なる圧縮方法が開発されている。
 
【0016】
  ビデオコーディング規格は、ITU-T H.261、ISO/IEC MPEG-1 Visual、ITU-T H.262またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG-4 Visual、ITU-T H.264(ISO/IEC MPEG-4 AVCとしても知られる)、およびそのような規格の拡張を含むHEVCを含む。
 
【0017】
  さらに、ビデオコーディング規格、すなわちDSCが、VESAによって開発されている。DSC規格は、ビデオを、ディスプレイリンクを介した送信用に圧縮することができるビデオ圧縮規格である。ディスプレイの解像度が増大すると、ディスプレイを駆動するのに求められるビデオデータの帯域幅が対応して増大する。いくつかのディスプレイリンクは、そのような解像度向けのディスプレイにビデオデータすべてを送信するための帯域幅をもたない場合がある。したがって、DSC規格は、ディスプレイリンクを介した、相互動作可能な、視覚的に無損失な圧縮のための圧縮規格を規定する。
 
【0018】
  DSC規格は、H.264およびHEVCなど、他のビデオコーディング規格とは異なる。DSCは、フレーム内圧縮を含むが、フレーム間圧縮は含まず、これは、ビデオデータをコーディングする際に、DSC規格によって時間情報を使うことができないことを意味する。対照的に、他のビデオコーディング規格は、ビデオコーディング技法においてフレーム間圧縮を利用し得る。
 
【0019】
ビデオコーディングシステム
  新規のシステム、装置、および方法の種々の態様が、添付の図面を参照しながら以下にさらに十分に説明される。しかしながら、本開示は、多くの異なる形態で実施され得るものであり、本開示の全体を通して示される任意の特定の構造または機能に限定されるものと解釈されるべきでない。むしろ、これらの態様は、本開示が、完全で完璧となるように、および当業者に完全に本開示の範囲を伝えるように提供される。本明細書の教示に基づいて、本開示の範囲は、本開示の他の態様とは無関係に実装されるにせよ、本開示の他の態様と組み合わせて実装されるにせよ、本明細書で開示する新規のシステム、装置、および方法のいかなる態様をもカバーするものであることを、当業者なら諒解されたい。たとえば、本明細書に記載の任意の数の態様を使用して、装置が実装され得るか、または方法が実施され得る。さらに、本開示の範囲は、本明細書に記載の本開示の様々な態様に加えてまたはそれらの態様以外に、他の構造、機能性、または構造および機能性を使用して実施されるそのような装置または方法をカバーするものとする。本明細書で開示する任意の態様は、特許請求の範囲の1つまたは複数の要素により具現化され得ることが理解されるべきである。
 
【0020】
  特定の態様について本明細書で説明するが、これらの態様の多くの変形体および置換は本開示の範囲内に入る。好ましい態様のいくつかの利益および利点に言及するが、本開示の範囲は特定の利益、使用、または目的に限定されるものではない。むしろ、本開示の態様は、様々なワイヤレス技術、システム構成、ネットワーク、および送信プロトコルに広く適用可能であるものとし、そのうちのいくつかが例として図および好ましい態様についての以下の説明で示される。発明を実施するための形態および図面は、限定的なものではなく本開示を説明するものにすぎず、本開示の範囲は添付の特許請求の範囲およびその等価物によって規定される。
 
【0021】
  添付の図面は、例を示す。添付の図面において参照番号によって示される要素は、以下の説明において同様の参照番号によって示される要素に対応する。本開示において、順序を示す言葉(たとえば、「第1」、「第2」、「第3」など)で始まる名称を有する要素は、それらの要素が特定の順序を有することを必ずしも含意するわけではない。そうではなく、そのような順序を示す言葉は単に、同じまたは類似したタイプの異なる要素を指すのに使われる。
 
【0022】
  図1Aは、本開示で説明する態様による技法を利用し得る例示的なビデオコーディングシステム10を示すブロック図である。本明細書で使用し、記載する「ビデオコーダ」または「コーダ」という用語は、ビデオエンコーダとビデオデコーダの両方を総称的に指す。本開示では、「ビデオコーディング」または「コーディング」という用語は、ビデオ符号化およびビデオ復号を総称的に指す場合がある。ビデオエンコーダおよびビデオデコーダに加え、本出願に記載する態様は、トランスコーダ(たとえば、ビットストリームを復号し、別のビットストリームを再符号化することができるデバイス)およびミドルボックス(たとえば、ビットストリームを修正し、変換し、かつ/またはさもなければ操作することができるデバイス)など、他の関連デバイスに拡張され得る。
 
【0023】
  図1Aに示すように、ビデオコーディングシステム10は、宛先デバイス14によって後で復号されるべき符号化ビデオデータを生成するソースデバイス12を含む。
図1Aの例において、ソースデバイス12および宛先デバイス14は別個のデバイスを構成する。ただし、ソースデバイス12および宛先デバイス14は、
図1Bの例に示すように、同じデバイスの上にあるか、またはその一部であってよいことに留意されたい。
 
【0024】
  図1Aを再度参照すると、ソースデバイス12および宛先デバイス14はそれぞれ、デスクトップコンピュータ、ノートブック(たとえば、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲーム機、ビデオストリーミングデバイスなどを含む、様々なデバイスのいずれかを含み得る。様々な実施形態において、ソースデバイス12および宛先デバイス14は、ワイヤレス通信のために装備されてもよい。
 
【0025】
  宛先デバイス14は、リンク16を介して、復号されるべき符号化ビデオデータを受信し得る。リンク16は、ソースデバイス12から宛先デバイス14に符号化ビデオデータを移動することが可能な任意のタイプの媒体またはデバイスを備えてもよい。
図1Aの例では、リンク16は、ソースデバイス12がリアルタイムで宛先デバイス14に符号化ビデオデータを送信することを可能にする通信媒体を備えてもよい。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス14に送信されてもよい。通信媒体は、無線周波数(RF)スペクトルなどの任意のワイヤレスもしくはワイヤード通信媒体、または、1つもしくは複数の物理的伝送線を備えてもよい。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどの、パケットベースのネットワークの一部を形成してもよい。通信媒体は、ルータ、スイッチ、基地局、または、ソースデバイス12から宛先デバイス14への通信を容易にするために有用であってもよい任意の他の機器を含んでもよい。
 
【0026】
  図1Aの例では、ソースデバイス12は、ビデオソース18と、ビデオエンコーダ20と、出力インターフェース22とを含む。いくつかの場合には、出力インターフェース22は、変調器/復調器(モデム)および/または送信機を含んでもよい。ソースデバイス12において、ビデオソース18は、ビデオキャプチャデバイス、たとえば、ビデオカメラ、以前にキャプチャされたビデオを含むビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェース、および/もしくはソースビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステム、またはそのようなソースの組合せ、などのソースを含んでもよい。一例として、ビデオソース18がビデオカメラである場合、ソースデバイス12および宛先デバイス14は、
図1Bの例に示すように、いわゆる「カメラフォン」または「ビデオフォン」を形成し得る。しかしながら、本開示で説明する技術は、一般にビデオコーディングに適用可能であってもよく、ワイヤレス用途および/またはワイヤード用途に適用されてもよい。
 
【0027】
  キャプチャされた、事前にキャプチャされた、またはコンピュータによって生成されたビデオは、ビデオエンコーダ20によって符号化されてもよい。符号化ビデオデータは、ソースデバイス12の出力インターフェース22を介して宛先デバイス14に送信され得る。符号化ビデオデータは、さらに(または代替的に)、復号および/または再生のための宛先デバイス14または他のデバイスによる後のアクセスのために記憶デバイス31上に記憶され得る。
図1Aおよび
図1Bに示されるビデオエンコーダ20は、
図2Aに示されるビデオエンコーダ20または本明細書に記載する他のどのビデオエンコーダも含み得る。
 
【0028】
  図1Aの例では、宛先デバイス14は、入力インターフェース28と、ビデオデコーダ30と、ディスプレイデバイス32とを含む。いくつかの場合には、入力インターフェース28は、受信機および/またはモデムを含んでもよい。宛先デバイス14の入力インターフェース28は、リンク16を介して、および/または記憶デバイス31から、符号化ビデオデータを受信し得る。リンク16を介して通信され、または記憶デバイス31上に与えられた符号化ビデオデータは、ビデオデータを復号する際に、ビデオデコーダ30などのビデオデコーダが使用するための、ビデオエンコーダ20によって生成される様々なシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体上で送信された、記憶媒体上に記憶された、またはファイルサーバ上に記憶された符号化ビデオデータとともに含まれてもよい。
図1Aおよび
図1Bに示すビデオデコーダ30は、
図2Bに示すビデオデコーダ30または本明細書に記載する他のどのビデオデコーダも含み得る。
 
【0029】
  ディスプレイデバイス32は、宛先デバイス14と一体化されてよく、またはその外部にあってよい。いくつかの例では、宛先デバイス14は、集積ディスプレイデバイスを含み、また、外部ディスプレイデバイスとインターフェースするように構成され得る。他の例では、宛先デバイス14はディスプレイデバイスであり得る。一般に、ディスプレイデバイス32は、復号ビデオデータをユーザに表示し、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを含み得る。
 
【0030】
  関連態様において、
図1Bは、例示的ビデオコーディングシステム10'を示し、ここで、ソースデバイス12および宛先デバイス14は、デバイス11の上にあるか、またはその一部である。デバイス11は、「スマート」フォンなどの電話ハンドセットであってよい。デバイス11は、ソースデバイス12および宛先デバイス14と動作可能に通信するプロセッサ/コントローラデバイス13(随意で存在する)を含み得る。
図1Bのビデオコーディングシステム10'、およびその構成要素は、場合によっては、
図1Aのビデオコーディングシステム10、およびその構成要素と同様である。
 
【0031】
  ビデオエンコーダ20およびビデオデコーダ30は、DSCなどのビデオ圧縮規格に従って動作し得る。代替的に、ビデオエンコーダ20およびビデオデコーダ30は、代替的にMPEG-4, Part 10, AVC、HEVCと呼ばれるITU-T H.264規格など、他のプロプライエタリ規格もしくは業界規格、またはそのような規格の拡張に従って動作し得る。本開示の技術は、しかしながら、任意の特定のコーディング規格に限定されない。ビデオ圧縮規格の他の例は、MPEG-2とITU-T H.263とを含む。
 
【0032】
  図1Aおよび
図1Bの例には示されていないが、ビデオエンコーダ20およびビデオデコーダ30は各々、オーディオエンコーダおよびオーディオデコーダと一体化され得、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切なMUX-DEMUXユニット、または他のハードウェアおよびソフトウェアを含み得る。該当する場合、いくつかの例では、MUX-DEMUXユニットは、ITU H.223マルチプレクサプロトコル、または、ユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠してもよい。
 
【0033】
  ビデオエンコーダ20およびビデオデコーダ30は各々、1つもしくは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアまたはそれらの任意の組合せなど、様々な適切なエンコーダ回路のいずれかとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、ソフトウェアのための命令を好適な非一時的コンピュータ可読媒体に記憶し、本開示の技法を実施するために1つまたは複数のプロセッサを使用してハードウェアでその命令を実行し得る。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてもよく、これらのいずれもが、それぞれのデバイス内の複合エンコーダ/デコーダの一部として統合されてもよい。
 
【0034】
ビデオコーディングプロセス
  上で手短に言及したように、ビデオエンコーダ20はビデオデータを符号化する。ビデオデータは、1つまたは複数のピクチャを含み得る。ピクチャの各々は、ビデオの一部を形成する静止画像である。いくつかの事例では、ピクチャはビデオ「フレーム」と呼ばれ得る。ビデオエンコーダ20がビデオデータを符号化するとき、ビデオエンコーダ20はビットストリームを生成し得る。ビットストリームは、ビデオデータのコード化表現を形成するビットのシーケンスを含み得る。ビットストリームは、コード化ピクチャおよび関連データを含み得る。コード化ピクチャは、ピクチャのコード化表現である。
 
【0035】
  ビットストリームを生成するために、ビデオエンコーダ20は、ビデオデータ中の各ピクチャに対して符号化動作を実施し得る。ビデオエンコーダ20がピクチャに対して符号化動作を実施するとき、ビデオエンコーダ20は、一連のコード化ピクチャおよび関連データを生成し得る。関連データは、量子化パラメータ(QP)などのコーディングパラメータのセットを含み得る。コード化ピクチャを生成するために、ビデオエンコーダ20は、ピクチャを、等しいサイズのビデオブロックに区分すればよい。ビデオブロックは、サンプルの2次元アレイであり得る。コーディングパラメータは、ビデオデータのすべてのブロックについてコーディングオプション(たとえば、コーディングモード)を定義し得る。コーディングオプションは、所望のレート歪み特性を達成するために選択されてよい。
 
【0036】
  いくつかの例では、ビデオエンコーダ20は、ピクチャを複数のスライスに区分し得る。スライスの各々は、画像またはフレーム中の領域の残りからの情報なしで単独で復号することができる、画像(たとえば、フレーム)中の空間的に別個の領域を含み得る。各画像またはビデオフレームは、単一のスライス中で符号化することもでき、いくつかのスライス中で符号化することもできる。DSCにおいて、各スライスを符号化するために割り振られるターゲットビットは、実質的に固定であり得る。ピクチャに対して符号化動作を実施することの一部として、ビデオエンコーダ20は、ピクチャの各スライスに対して符号化動作を実施し得る。ビデオエンコーダ20がスライスに対して符号化動作を実施するとき、ビデオエンコーダ20は、スライスに関連した符号化データを生成することができる。スライスに関連した符号化データは、「コード化スライス」と呼ばれ得る。
 
【0037】
DSCビデオエンコーダ
  
図2Aは、本開示で説明する態様による技法を実装し得るビデオエンコーダ20の例を示すブロック図である。ビデオエンコーダ20は、本開示の技法のうちの一部または全部を実施するように構成され得る。いくつかの例では、本開示で説明する技法は、ビデオエンコーダ20の様々な構成要素の間で共有され得る。いくつかの例では、追加的または代替的に、プロセッサ(図示せず)が本開示で説明する技法のうちの一部または全部を実施するように構成され得る。
 
【0038】
  説明のために、本開示は、DSCコーディングのコンテキストにおいてビデオエンコーダ20を説明する。ただし、本開示の技法は他のコーディング規格または方法に適用可能であり得る。
 
【0039】
  図2Aの例において、ビデオエンコーダ20は複数の機能構成要素を含む。ビデオエンコーダ20の機能構成要素は、色空間コンバータ105、バッファ110、平坦度検出器115、レートコントローラ120、予測器、量子化器、および再構築器構成要素125、ラインバッファ130、索引付き色履歴135、エントロピーエンコーダ140、サブストリームマルチプレクサ145、ならびにレートバッファ150を含む。他の例では、ビデオエンコーダ20は、より多数の、より少数の、または異なる機能的構成要素を含み得る。
 
【0040】
  色空間コンバータ105は、入力色空間を、コーディング実装において使われる色空間にコンバートし得る。たとえば、例示的な一実施形態では、入力ビデオデータの色空間は、赤、緑、および青(RGB)色空間にあり、コーディングは、ルミナンスY、クロミナンス緑Cg、およびクロミナンス橙Co(YCgCo)色空間において実装される。色空間コンバージョンは、ビデオデータへのシフトおよび加算を含む方法によって実施することができる。他の色空間中の入力ビデオデータを処理することができ、他の色空間へのコンバージョンも実施することができることに留意されたい。
 
【0041】
  関連態様において、ビデオエンコーダ20は、バッファ110、ラインバッファ130、および/またはレートバッファ150を含み得る。たとえば、バッファ110は、ビデオエンコーダ20の他の部分によるその使用に先立って、色空間コンバートされたビデオデータを保持することができる。別の例では、ビデオデータはRGB色空間中に記憶することができ、色空間コンバートされたデータはより多くのビットを要し得るので、色空間コンバージョンは必要に応じて実施すればよい。
 
【0042】
  レートバッファ150は、レートコントローラ120に関連して下でより詳細に記載する、ビデオエンコーダ20内のレート制御機構の一部として機能し得る。各ブロックを符号化するのに費やされるビットは、ブロックの性質に基づいてかなり大幅に変わり得る。レートバッファ150は、圧縮ビデオにおけるレート変動を平滑化することができる。いくつかの実施形態では、バッファからビットが固定ビットレートで取り出される固定ビットレート(CBR)バッファモデルが利用される。CBRバッファモデルにおいて、ビデオエンコーダ20が、ビットストリームにあまりにも多くのビットを追加した場合、レートバッファ150はオーバーフローし得る。一方、ビデオエンコーダ20は、レートバッファ150のアンダーフローを防止するために、十分なビットを追加しなければならない。
 
【0043】
  ビデオデコーダ側において、ビットは、ビデオデコーダ30のレートバッファ155(下でさらに詳しく記載する
図2Bを参照)に固定ビットレートで追加することができ、ビデオデコーダ30は、各ブロックについて可変数のビットを削除してよい。適正な復号を確実にするために、ビデオデコーダ30のレートバッファ155は、圧縮ビットストリームの復号中に「アンダーフロー」も「オーバーフロー」もするべきでない。
 
【0044】
  いくつかの実施形態では、バッファフルネス(BF)は、バッファ中に現在あるビットの数を表す値BufferCurrentSizeと、レートバッファ150のサイズを表すBufferMaxSize、すなわち、任意の時点でレートバッファ150中に記憶することができるビットの最大数とに基づいて定義され得る。BFは、次のように算出され得る。
  BF=((BufferCurrentSize*100)/BufferMaxSize)
 
【0045】
  平坦度検出器115は、ビデオデータ中の複雑(すなわち、非平坦)エリアから、ビデオデータ中の平坦(すなわち、単純または均一)エリアへの変更を検出し得る。「複雑」および「平坦」という用語は、本明細書において、概して、ビデオエンコーダ20がビデオデータのそれぞれの領域を符号化するための難しさを指すのに使われる。したがって、本明細書において使われる複雑という用語は概して、ビデオデータの領域を、ビデオエンコーダ20が符号化するのが複雑なものとして記述し、たとえば、テクスチャ化ビデオデータ、高い空間周波数、および/または符号化するのには複雑な他の特徴を含み得る。本明細書において使われる平坦という用語は概して、ビデオデータの領域を、ビデオエンコーダ20が符号化するのに簡単なものとして記述し、たとえば、ビデオデータ中の平滑勾配、低い空間周波数、および/または符号化するのが簡単な他の特徴を含み得る。複雑領域と平坦領域との間の遷移は、ビデオエンコーダ20によって、符号化ビデオデータにおける量子化乱れを削減するのに使うことができる。具体的には、複雑領域から平坦領域への遷移が識別されると、レートコントローラ120ならびに予測器、量子化器、および再構築器構成要素125がそのような量子化乱れを削減することができる。
 
【0046】
  レートコントローラ120は、コーディングパラメータのセット、たとえば、QPを決定する。QPは、レートバッファ150がオーバーフローもアンダーフローもしないことを確実にするターゲットビットレートに対するピクチャ品質を最大限にするために、レートバッファ150のバッファフルネスおよびビデオデータの画像活動度に基づいて、レートコントローラ120によって調節することができる。レートコントローラ120は、最適レート歪み特性を達成するために、ビデオデータの各ブロック向けの特定のコーディングオプション(たとえば、特定のモード)も選択する。レートコントローラ120は、歪みがビットレート制約を満足するように、すなわち、全体的な実際の符号化レートがターゲットビットレート内に収まるように、再構築画像の歪みを最小限にする。
 
【0047】
  予測器、量子化器、および再構築器構成要素125は、ビデオエンコーダ20の少なくとも3つの符号化動作を実施することができる。予測器、量子化器、および再構築器構成要素125は、いくつかの異なるモードで予測を実施することができる。1つの例示的な予測モードが、中央値適応予測の修正バージョンである。中央値適応予測は、無損失JPEG規格(JPEG-LS)によって実装することができる。予測器、量子化器、および再構築器構成要素125によって実施することができる中央値適応予測の修正バージョンは、3つの連続するサンプル値の並列予測を可能にし得る。別の例示的予測モードはブロック予測である。ブロック予測において、サンプルは、前に再構築された上のラインのピクセルから、または同じライン上の左に向かって予測される。いくつかの実施形態では、ビデオエンコーダ20およびビデオデコーダ30は両方とも、再構築ピクセルに対して同一の探索を実施して、ブロック予測の使用を決定し得、したがって、どのビットも、ブロック予測モードで送られる必要はない。他の実施形態では、ビデオエンコーダ20は、ビデオデコーダ30が別個の探索を実施する必要がないように、探索を実施し、ビットストリーム中のブロック予測ベクトルをシグナリングすることができる。成分範囲の中間点を使ってサンプルが予測される中間点予測モードも実装されてよい。中間点予測モードは、ワーストケースサンプルにおいてさえも圧縮ビデオに求められるビットの数のバウンディングを可能にし得る。
図3〜
図6を参照して下でさらに論じるように、予測器、量子化器、および再構築器構成要素125は、
図3〜
図6に示す方法を実施することによって、ビデオデータのブロック(または他の任意の予測単位)を予測する(たとえば、符号化または復号する)ように構成されてよい。
 
【0048】
  予測器、量子化器、および再構築器構成要素125は、量子化も実施する。たとえば、量子化は、シフタを使って実装され得る2のべき乗量子化器により実施することができる。2のべき乗量子化器の代わりに、他の量子化技法が実装されてもよいことに留意されたい。予測器、量子化器、および再構築器構成要素125によって実施される量子化は、レートコントローラ120によって決定されるQPに基づき得る。最後に、予測器、量子化器、および再構築器構成要素125は、逆量子化残差を予測値に加算すること、および結果がサンプル値の有効範囲の外になることを確実にすることを含む再構築も実施する。
 
【0049】
  予測器、量子化器、および再構築器構成要素125によって実施される予測、量子化、および再構築のための、上で記載した例示的手法は例示にすぎないこと、ならびに他の手法が実装されてよいことに留意されたい。予測器、量子化器、および再構築器構成要素125は、予測、量子化、および/または再構築を実施するための下位構成要素を含み得ることにも留意されたい。予測、量子化、および/または再構築は、予測器、量子化器、および再構築器構成要素125の代わりに、いくつかの別個のエンコーダ構成要素によって実施されてよいことにさらに留意されたい。
 
【0050】
  ラインバッファ130は、予測器、量子化器、および再構築器構成要素125ならびに索引付き色履歴135が、バッファリングされたビデオデータを使うことができるように、予測器、量子化器、および再構築器構成要素125からの出力を保持する。索引付き色履歴135は、最近使われたピクセル値を記憶する。これらの最近使われたピクセル値は、専用シンタックスにより、ビデオエンコーダ20によって直接参照することができる。
 
【0051】
  エントロピーエンコーダ140は、予測器、量子化器、および再構築器構成要素125から受信された予測残差ならびに他のどのデータ(たとえば、予測器、量子化器、および再構築器構成要素125によって識別された索引)も、索引付き色履歴135と、平坦度検出器115によって識別された平坦度遷移とに基づいて符号化する。いくつかの例では、エントロピーエンコーダ140は、サブストリームエンコーダごとに、1クロックあたり3つのサンプルを符号化することができる。サブストリームマルチプレクサ145は、ヘッダなしパケット多重化方式に基づいてビットストリームを多重化することができる。こうすることにより、ビデオデコーダ30は、3つのエントロピーデコーダを並行して稼働させることができ、1クロックあたり3つのピクセルの復号を容易にする。サブストリームマルチプレクサ145は、ビデオデコーダ30によってパケットが効率的に復号され得るように、パケット順序を最適化することができる。1クロックあたり2のべき乗ピクセル(たとえば、2ピクセル/クロックまたは4ピクセル/クロック)の復号を容易にし得る、エントロピーコーディングのための異なる手法が実装されてよいことに留意されたい。
 
【0052】
DSCビデオデコーダ
  
図2Bは、本開示で説明する態様による技法を実装し得るビデオデコーダ30の例を示すブロック図である。ビデオデコーダ30は、本開示の技法のうちの一部または全部を実施するように構成され得る。いくつかの例では、本開示で説明する技法は、ビデオエンコーダ30の様々な構成要素の間で共有され得る。いくつかの例では、追加的または代替的に、プロセッサ(図示せず)が本開示で説明する技法のうちの一部または全部を実施するように構成され得る。
 
【0053】
  説明のために、本開示は、DSCコーディングのコンテキストにおいてビデオデコーダ30を説明する。ただし、本開示の技法は他のコーディング規格または方法に適用可能であり得る。
 
【0054】
  図2Bの例において、ビデオデコーダ30は複数の機能構成要素を含む。ビデオデコーダ30の機能構成要素は、レートバッファ155、サブストリームデマルチプレクサ160、エントロピーデコーダ165、レートコントローラ170、予測器、量子化器、および再構築器構成要素175、索引付き色履歴180、ラインバッファ185、ならびに色空間コンバータ190を含む。ビデオデコーダ30の図示する構成要素は、
図2Aのビデオエンコーダ20に関連して上述した対応する構成要素に類似している。したがって、ビデオデコーダ30の構成要素の各々は、上述したビデオエンコーダ20の対応する構成要素と同様に動作し得る。
 
【0055】
DSCにおけるスライス
  上述したように、スライスは概して、画像またはフレーム中の領域の残りからの情報を使わずに単独で復号することができる、画像またはフレーム中の空間的に別個の領域を指す。各画像またはビデオフレームは、単一のスライス中で符号化することもでき、画像またはビデオフレームは、いくつかのスライス中で符号化することもできる。DSCにおいて、各スライスを符号化するために割り振られるターゲットビットは、実質的に固定であり得る。
 
【0056】
パターンモード
  ビデオデータの単一のブロックはいくつかのピクセルを含んでよく、ビデオデータの各ブロックは、ブロックがコーディングされ得るいくつかの起こり得るコーディングモードを有する。そのようなコーディングモードのうちの1つが、パターンモードである。パターンモードにおいて、エンコーダおよびデコーダは、最近コーディングされたピクセル値のデータベース(たとえば、パターンデータベース)を維持することができる。ビデオデータのブロックを符号化するとき、エンコーダは、ブロック中に含まれる各パターン(たとえば、単一のピクセルのRGB値)がパターンデータベース中に存在すると判断し、ブロック中に含まれる実際のピクセル値ではなく、パターンデータベース中の一致パターン(すなわち、ブロック中に含まれるパターンと一致する、パターンデータベースのパターン)の索引をデコーダにシグナリングすることができる。パターンモードは、グラフィックスコンテンツを圧縮するために特に有用であってよく、というのは、そのようなコンテンツ(たとえば、デスクトップユーザインターフェースに関連したコンテンツ)は通常、同じであるたくさんのピクセル値(すなわち、冗長ピクセル値)を含むからである。
 
【0057】
  いくつかの実装形態では、パターンモードは、最近出現している、および空間的に隣接するピクセル値からなる永続データベースを利用することができ、このデータベースは、各パターンブロックについて更新される。符号化されるべき所与のブロックが、データベース中に含まれるそのピクセル値のほとんどを有するとき、優れたコーディング効率がもたらされる。この場合、ピクセル値自体を送信するよりもむしろ、データベース中に含まれる各ピクセル値に関連付けられた、データベース中の索引が送信されればよく、これにより、各ピクセル値がシグナリングされることを必要とする実装形態にまさる有意なビットレート節約を実現する。たとえば、パターンデータベースサイズが、32個の可能パターンエントリである場合、各ピクセルは、log
2(32)=5ビットの索引を使って符号化され得る。
 
【0058】
パターンモードの使用
  本開示のいくつかの実施形態では、パターンデータベースが、ブロック中に含まれる各パターンを含まない場合であっても、ビデオデータのブロックはパターンモードでコーディングすることができる。たとえば、現在のブロックが8つのパターンを有し、パターンのうちの5つだけがパターンデータベース中で見つかった場合、エンコーダは依然として、パターンモードでブロックをコーディングし、パターンデータベース中で見つかった5つのパターンについてのデータベース索引をシグナリングし、残りの3つのパターンの実際のピクセル値をシグナリングすることができる。いくつかのケースでは、パターンデータベース中で見つからない一意のパターンの数が閾値未満である場合、エンコーダは、パターンモードでブロックをコーディングしてよい。たとえば、ブロックが、パターンデータベース中で見つからないが同じピクセル値をすべてが有する8つのピクセルを含む場合、エンコーダは、単一のブロックについてパターンデータベースに追加することができる新規パターンの最大数が少なくとも1である場合、パターンモードでブロックをコーディングすることができる。パターンモードの使用は、フラグを使ってシグナリングする(すなわち、示す)ことができる。言い換えると、フラグは、パターンモードの有効化(または無効化)を示すのに使うことができる。
 
【0059】
  本開示のいくつかの実施形態では、現在のブロック中のパターンと、パターンデータベース中のパターンとの間の完全な一致(たとえば、同じRGB値を有する)が要求されるわけではない。差(または損失)の閾量は、QPなど、1つまたは複数のコーディングパラメータに基づき得る。たとえば、本開示のいくつかの実施形態では、パターンモードは、無損失設定または損失性設定のいずれにおいても使うことができる。損失性設定が選択された場合、パターンモードにおける損失の閾量は、コーデックの現在のQPに応じて計算され得る。損失の閾量は、現在のQPに正比例し得る。
 
【0060】
パターンモードでシグナリングされる情報
  本開示のいくつかの実施形態では、エンコーダは、1つまたは複数のデータをビットストリーム中で明示的にシグナリングし得る。そのようなデータは、(i)新規パターンの数、(ii)新規パターン値、および/または(iii)すでにパターンデータベース中にある、繰り返されるパターンのデータベース索引を含み得る。本開示のいくつかの実施形態では、(i)〜(iii)すべてが、(ビットストリーム中でシグナリングされる他の値に基づいて導出または判断されるよりもむしろ)ビットストリーム中で明示的にシグナリングされる。エンコーダにおいて行われる作業(たとえば、パターンデータベース中を探索する、現在のブロック中のどのパターンが新規であるか判断する、現在のブロック中のどのパターンがデータベース中に存在するか判断する、など)を最大限にすることよって、デコーダ複雑度が最小限にされ得る。これは、しばしばエンコーダのハードウェア能力がデコーダの能力にはるかにまさるので、重要である。上述したように、パターンモードは、無損失でも、損失ありでも使うことができる。無損失手法において、新規パターンは、その全体が、パターンのソースビット深度を使ってシグナリングされ得る。たとえば、RGB888データの場合、新規パターンは、24ビットを使ってデコーダにシグナリングされ得る。損失性手法において、新規パターンは、現在のQP値に基づく量だけ量子化され得る。たとえば、高いQPの場合、24よりも少ないビットが、デコーダに明示的にシグナリングされ得る。
 
【0061】
  本開示のいくつかの実施形態では、パターンデータベースを更新するプロセスは、デコーダ側でのデータベース中の探索を必要としない。このことは、簡素なハードウェア設計につながる。
 
【0062】
例示的パターンデータベース
  いくつかの実装形態では、パターンデータベースは、3つのフィールド、すなわち永続、ネイバー、および新規に区分することができる。永続部分は、エンコーダによって直近に使われたいくつかの一意のパターンを含み得る。ネイバー部分は、隣接ピクセルおよび/またはブロックのパターンを含み得る。新規部分は、新たに追加されたパターンを含み得る。たとえば、ブロックごとの新規パターンの最大数により、パターンモードブロックの最大レートが決まる。さらに、永続およびネイバーデータベース区分のサイズの間でトレードオフが行われてよい。ネイバーデータベースは、現在のブロックサイズに応じて設定されてよい。
 
【0063】
  各パターンモードブロックが符号化された後、新規および隣接パターン索引のセットが永続データベースに追加される。パターンモードの一実装形態において、永続データベースは先入れ先出し(FIFO)バッファであり得る。パターンモードの実装形態では、永続データベースにパターンを追加し直すとき、重複を削除することができる。パターンモードのより複雑な実装形態では、永続データベースは、直近に使われた(MRU)キャッシュ化戦略を使って充填することができる。
 
【0064】
  パターンデータベースのネイバー部分は、各ブロックについて更新されてよく(たとえば、各ブロックが処理された後)、(前の再構築ラインから取得された)現在のブロックの空間的ネイバーを含む。現在のブロックの左ネイバーは、全体的コーデック実装によっては、パターンデータベースに追加される場合も、されない場合もある。たとえば、ネイバーは、適正なパイプライン化を保証し、ハードウェア複雑度を低減させるために、削除される必要がある場合がある。
 
【0065】
  パターンデータベースの新規部分は、パターンデータベースに追加されている新規パターンを含む。上述したように、ある特定の数の新規パターンが、ブロックごとに許容される。パターンデータベースに追加される各エントリは、それに応じてデコーダがパターンデータベースをデコーダ側で更新することができるように、ビットストリーム中で明示的にシグナリングされてもよい。
 
【0066】
  本開示のいくつかの実施形態では、パターンデータベースのネイバー部分は、パターンデータベースが永続および新規部分(たとえば、それぞれ、永続パターンおよび新規パターンを含む)からなるように、削除され得る。たとえば、そのような実施形態は、総パターンデータベースサイズが小さく、隣接パターンを含めることによって、パターンデータベースの永続部分のサイズが一定の閾を超えて低下する(たとえば、効果的または有用であるには小さすぎる)場合、実装されてよい。さらに、本開示の他の実施形態では、パターンデータベースは単一の部分(たとえば、永続部分)を含む。そのような実施形態の例が、
図6を参照してより詳しく説明される。
 
【0067】
パターンデータベース中に記憶される例示的パターン
  本開示において、パターンデータベース中に記憶される実際の値は、パターンと呼ばれ、8ビットのソースコンテンツに対して、次のように定義することができる。
  PAT(R,G,B)=R+(G<<8)+(B<<16)
 
【0068】
  10ビットのコンテンツの場合、GおよびBに対するビットシフトは、それぞれ、10および20まで増大され得る。
 
【0069】
一致判断
  本開示のいくつかの実装形態では、符号化されるべき所与のピクセルについての一致を求めてパターンデータベースを探索するとき、小さいデルタが達成され得る。たとえば、符号化されるべき現在のピクセルが(R,G,B)であり、データベース中の特定のパターンが(R
p,G
p,B
p)である場合、エンコーダは、符号化されるべきピクセルおよびデータベースパターンが、2つの閾T
0およびT
1について以下の制約を満足する限り、現在のピクセルと、データベース中の特定のパターンとの間に一致があると判断してよく、ここでT
1≧T
0である。
  |R-R
p|<T
0
  |G-G
p|<T
0
  |B-B
p|<T
0
  |R-R
p|+|G-G
p|+|B-B
p|<T
1
 
【0070】
  本開示のいくつかの実施形態では、厳密な比較のための上記制約は、等式を含むように緩和されてよい。たとえば、制約|R-R
p|<T
0は、|R-R
p|≦T
0で置き換えられてよい。同じことが、他の制約について行われてよい。
 
【0071】
  提案されるアルゴリズムの一実施形態では、上の閾は、コーデックの現在のQPに応じて判断される。
  T
0=((QP-A)>>B)+C
  T
1=2・T
0
 
【0072】
  上式で、A、B、Cはすべて、実装中に調整されるべきパラメータである。本実施形態では、パターンモードにおいて許容される歪みは、コーデックの全体的QPに応答して徐々に増大する。
 
【0073】
パターンデータベースを探索するための例示的フローチャート
  
図3を参照して、パターンデータベースを探索するための例示的手順について記載する。
図3に示されるステップは、ビデオエンコーダ(たとえば、
図2Aのビデオエンコーダ20)、ビデオデコーダ(たとえば、
図2Bのビデオデコーダ30)、またはそれらの構成要素によって実施することができる。便宜上、方法300は、ビデオエンコーダ20、ビデオデコーダ30、または他の構成要素であってよいビデオコーダ(単にコーダとも呼ばれる)によって実施されるものとして記載される場合がある。
 
【0074】
  方法300は、ブロック302において始まる。ブロック302において、方法300において使われる様々なパラメータが初期化される。
図3に示すように、コーダは、現在のパターン301Bを求めてデータベース301Aを探索する。ブロック304において、コーダは、コーダがパターンデータベース301A中を調べ尽くし終えたかどうか判断する。コーダが、パターンデータベース301A中をコーダが調べ尽くし終えていないと判断した場合、コーダはブロック306に進み、ここでコーダは、現在のパターンと現在のデータベースエントリとの間の差を判断する。それ以外の場合、コーダはブロック314に進む。
 
【0075】
  ブロック308において、コーダは、現在のパターンと現在のデータベースエントリとの間の差が1つまたは複数の閾基準を満足するかどうか(たとえば、差が閾未満であり、これまでに見つかった最も小さい差分値未満でもあると)判断する。コーダが、1つまたは複数の閾基準が満足されると判断した場合、コーダはブロック310に進み、ここでコーダは、差を、これまでに最も低い差として指定する。それ以外の場合、コーダはブロック312に進み、ここでコーダは、パターンデータベース中の次のデータベースエントリに進み、ブロック304に戻る。
 
【0076】
  各データベースエントリがコーダによって処理された後、ブロック314において、コーダは、パターンデータベース中でコーダが一致を見つけたかどうか判断する。コーダが、パターンデータベース中でコーダが一致を見つけたと判断した場合、コーダはブロック316に進み、ここでコーダは、現在のパターン301Bについての一致の索引をシグナリングする(たとえば、コーダが、現在のパターン301Bを含む現在のブロックにパターンモードが使われるべきであると判断した場合)。それ以外の場合、コーダはブロック318および320に進み、ここでコーダは、新規パターン(たとえば、新規の一意のパターン)の数が閾値を超えたかどうか判断する。コーダが、新規パターンの数が閾値を超えていないと判断した場合、コーダはブロック322に進み、ここで現在のパターンは、(たとえば、現在のパターンをビットストリーム中でシグナリングするのに加え)データベースに追加される。それ以外の場合、コーダはブロック324に進み、ここでコーダは、現在のパターン301Bを含む現在のブロックをコーディングするのにパターンモードを使うことができないと判断する。
 
【0077】
  方法300において、
図3に示すブロックのうちの1つもしくは複数は取り除かれて(たとえば、実施されなくて)よく、および/または方法が実施される順序は入れ換えられてよい。いくつかの実施形態では、追加ブロックが方法300に追加されてよい。本開示の実施形態は、
図3に示す例にも、その例によっても限定されず、本開示の精神から逸脱することなく、他の変形形態が実装されてよい。
 
【0078】
パターンデータベースを更新するための例示的フローチャート
  
図4を参照して、パターンデータベースを更新するための例示的手順について記載する。
図4に示されるステップは、ビデオエンコーダ(たとえば、
図2Aのビデオエンコーダ20)、ビデオデコーダ(たとえば、
図2Bのビデオデコーダ30)、またはそれらの構成要素によって実施することができる。便宜上、方法400は、ビデオエンコーダ20、ビデオデコーダ30、または他の構成要素であってよいビデオコーダ(単にコーダとも呼ばれる)によって実施されるものとして記載される場合がある。
 
【0079】
  方法400はブロック402において始まり、ここで、方法400において使われる1つまたは複数のパラメータが初期化される。
図4に示すように、コーダは、現在のブロックの索引(たとえば、現在のブロック中の複数のパターンを含み得るcurBlockIndices401)の中を反復して、パターンデータベース415を、現在のブロックからのパターンで更新する。ブロック404において、コーダは、コーダが現在のブロック中のパターンすべてを調べ尽くし終えたかどうか判断する。コーダが、現在のブロック中のパターンすべてを調べ尽くし終えてはいないとコーダが判断した場合、コーダはブロック406に進み、ここでコーダは、現在のパターンがパターンデータベース中にあるかどうか判断する。現在のパターンがパターンデータベース中にないとコーダが判断した場合、コーダはブロック408に進み、ここで現在のパターンは、新規パターンとして一時ストレージに追加される。それ以外の場合、コーダはブロック410に進み、ここで現在のパターンは、既存のパターンとして一時ストレージに追加される。コーダは次いで、ブロック412に進み、ブロック404に戻って、現在のブロック中のパターンすべてを調べ尽くし終える。コーダが、現在のブロック中のパターンすべてを調べ尽くし終えた後、ブロック414において、ブロック408および410において一時ストレージに追加されたパターンが、パターンデータベース415の上位に追加される。
 
【0080】
  方法400において、
図4に示すブロックのうちの1つもしくは複数は取り除かれて(たとえば、実施されなくて)よく、および/または方法が実施される順序は入れ換えられてよい。いくつかの実施形態では、追加ブロックが方法400に追加されてよい。本開示の実施形態は、
図4に示す例にも、その例によっても限定されず、本開示の精神から逸脱することなく、他の変形形態が実装されてよい。
 
【0081】
パターンモードでブロックをコーディングするための例示的フローチャート
  
図5を参照して、パターンモードでブロックをコーディングするための例示的手順について記載する。
図5に示されるステップは、ビデオエンコーダ(たとえば、
図2Aのビデオエンコーダ20)、ビデオデコーダ(たとえば、
図2Bのビデオデコーダ30)、またはそれらの構成要素によって実施することができる。便宜上、方法500は、ビデオエンコーダ20、ビデオデコーダ30、または他の構成要素であってよいビデオコーダ(単にコーダとも呼ばれる)によって実施されるものとして記載される場合がある。
 
【0082】
  方法500は、ブロック501において始まる。ブロック505において、コーダは、ビデオデータの現在のブロック中の第1のパターンがパターンデータベース中にないと判断する。上述したように、データベースは複数のパターンを含み得る。ブロック510において、コーダは第1のパターンをパターンデータベースに追加する。データベースに追加された第1のパターンは、パターンデータベース中のどこに第1のパターンが位置するかを示すデータベース索引に関連付けられ得る。ブロック515において、コーダは、 (i)パターンデータベース中にないと判断された第1のパターンと、(ii)ビットストリーム中の第1のパターンに関連付けられたデータベース索引とをシグナリングすることに少なくとも部分的によって、パターンモードで現在のブロックをコーディングする。パターンデータベース中に存在するパターンについて、データベース索引のみがシグナリングされ得る。パターンの実際の値(たとえば、8ビットのRGB値が使われる場合、24ビット)ではなく既存のパターンのデータベース索引(たとえば、パターンデータベースが、32個のパターンエントリのサイズを有する場合、5ビットで表すことができる)をシグナリングすることによって、ビット節約を達成することができる。方法500は、ブロック520において終了する。
 
【0083】
  方法500において、
図5に示すブロックのうちの1つもしくは複数は取り除かれて(たとえば、実施されなくて)よく、および/または方法が実施される順序は入れ換えられてよい。いくつかの実施形態では、追加ブロックが方法500に追加されてよい。本開示の実施形態は、
図5に示す例にも、その例によっても限定されず、本開示の精神から逸脱することなく、他の変形形態が実装されてよい。
 
【0084】
パターンデータベースを更新するための例示的図
  
図6を参照して、パターンデータベースを更新するための例示的手順600について記載する。この例では、各ブロックは8つのピクセルからなる。黄色で強調表示されるパターンは、現在のブロック中の「新規パターン」と見なされる。橙色で強調表示されるパターンは、現在のブロックを求める探索中にデータベース中で見つかった「保持パターン」と見なされる。
図6に示すように、現在のスライス602は、パターンモードでコーディングされることを検討されているブロック0〜3を含む。ブロック0が処理される前、パターンデータベースは空である。たとえば、コーダが新規スライス内の最初のブロックを処理しているとき、パターンデータベースは空であり得る。この例の場合、ブロックあたりの新規パターンの最大数は、この例では4に固定されてよい。
 
【0085】
  ブロック0に対して、これはスライス中の最初のブロックなので、パターンデータベースは空としてスタートする。3つの一意のピクセル値がブロック0において観察される(パターンA、B、C)。新規パターンの数は、4という閾値未満なので、現在のブロックは、3つの新規パターンがビットストリームにシグナリングされるパターンモードを使ってコーディングすることができる。パターンモードが、レート制御アルゴリズムによって最良モードとして選択された場合、パターンデータベースは、パターンA、B、およびCを含むように更新される。
 
【0086】
  ブロック1は、3つの一意のパターンA、C、およびDを含む。パターンデータベースはパターンAおよびCをすでに含むので、パターンDのみが、パターンデータベースに(たとえば、パターンデータベースの上位に)追加される必要がある。新規パターンの数は1なので、ブロック1は、1つの新規パターンがビットストリームにシグナリングされるパターンモードを使ってコーディングすることができる。パターンモードが選択されると仮定すると、パターンデータベースは現時点で、パターンA、B、C、およびDを含む。
図6に示すように、パターンAおよびCはやはり最近使われたので、パターンAおよびCはパターンデータベースの上位に移動される。そうすることによって、直近に使われたパターンは可能な限りデータベース中に残存し、破棄されるパターンエントリは、最も過去に使われたものとなる。
 
【0087】
  ブロック2は、3つの一意のパターンA、B、およびEを含む。パターンAおよびBはパターンデータベース中に見られ、新規パターンEはパターンデータベースに追加される。同様に、直近に使われたパターン(たとえば、パターンA、B、およびE)はパターンデータベースの上位に置かれる。
 
【0088】
  ブロック3は8つの一意のパターンを有する。パターンデータベースは、一意のパターンEおよびBという2つを含むが、残りの6つのパターンはパターンデータベース中に見られない。6は、パターンデータベースに追加することができる新規パターンの最大数、この例では4、を超えるので、コーダは、
図6に示すように、ブロック3はパターンモードでコーディングすることができないと判断してよい。パターンモードは、レート制御アルゴリズムによって選択することができないので、パターンデータベースは、ブロック2の後のパターンデータベースと同一になる。
 
【0089】
  本開示のいくつかの実施形態では、所与のブロック向けにパターンモードが選択されない場合であっても、所与のブロック中の新規パターンがパターンデータベースに追加されてよい。たとえば、スライスのまさに最初のブロック中のパターンは、そのブロックがパターンモードでコーディング中でない場合であっても、パターンデータベースに追加されてよい。別の例では、スライスの最初のいくつかのブロック(たとえば、閾数のブロック)中のパターンは、そのようなブロックがパターンモードでコーディング中でない場合であっても、パターンデータベースに追加されてよい。さらに別の例では、パターンモードでコーディング中でない所与のブロック中のパターンは、パターンデータベースが満杯でない場合、パターンデータベースに追加されてよい(たとえば、少なくとも1つの新規パターンが、パターンデータベース中のどの既存のパターンも削除する必要なく、パターンデータベースに追加され得る)。
 
【0090】
エンコーダ用の例示的パターン更新プロセス
  
図7を参照して、エンコーダ側でパターンデータベースを更新するための例示的手順について記載する。この例では、パターンデータベース(D
prev)は最初、パターンA、D、C、X、およびYを含む。矢印702において、コーディングされるべき現在のブロック中のパターンA、B、C、D、E、およびFが、現在のデータベース(D
curr)に追加される。矢印704において、D
prev中にもある現在のブロック中のパターンが、新規データベースD
newにコピーされる。矢印706において、D
prev中にはない、現在のブロック中のパターンがD
newに追加される。現在のブロックがパターンモードで符号化される場合、現在のブロックにはない、D
prev中のパターンが、矢印708においてD
newに追加される。矢印710において、D
newは、次のブロック用のパターンデータベースD
prevになる。
 
【0091】
デコーダ用の例示的パターン更新プロセス
  
図8を参照して、デコーダ側でパターンデータベースを更新するための例示的手順について記載する。この例では、デコーダは最初、パターンデータベース、保持および非保持パターンについてのビットマップ、ならびに新規パターンへのアクセスを有する。矢印802において、保持パターンは、パターンデータベースから新規データベースD
newにコピーされる。矢印804において、非保持パターンは、パターンデータベースから一時データベースD
tempにコピーされる。矢印806において、ビットストリーム中でシグナリングされた新規パターンは、ビットストリームから取得され、D
newに追加される。矢印808において、パターン索引を復号した後、D
temp中のパターンがD
newに追加される。矢印810において、D
newは、次のブロック用のパターンデータベースD
prevになる。
 
【0092】
他のパターンデータベース技法
  本開示のいくつかの実施形態では、パターンモードが選択されてもされなくても、スライス中の最初のm個のブロックがパターンデータベースに追加されてよい。たとえば、最初のブロックが何らかの他のモードを使ってコーディングされた場合、再構築ピクセルがパターンデータベースに追加されてよい。この追加は、各スライスの開始においてパターンデータベースが空なので、いかなる衝突も引き起こさない。
 
【0093】
  本開示に記載するパターンモード技法は、1つのラインバッファまたは複数のラインバッファのいずれかをサポートするコーデック中で使うことができる。このことは、デフォルトのブロックサイズが1ライン(1-D)または複数のライン(2-D)のいずれでもよいことを意味する。いずれのケースでも、ブロック内のピクセルの各々は、同じ制約を受け得る(たとえば、各ピクセルは、パターンデータベース中の何らかのエントリと一致するべきであるか、または「新規パターン」の総数がブロックごとの最大許容以下でなければならないか、のいずれかである)。
 
【0094】
利点
  上述したように、本開示に記載するパターンモード技法は、一致を求めてデータベースを探索するとき、無損失で使うこともでき、ある程度の損失を許容することもできる。さらに、損失ありで使われる場合、受容される損失の量は、エンコーダの現在のQPに比例し得る。さらに、非対称的な設計が、パターン探索がエンコーダ側で実施されることを可能にし、デコーダの複雑度を低下させる。
 
【0095】
  パターンデータベースまたはその部分(たとえば、永続、ネイバー、および新規)の相対的サイズは、圧縮レート、ビット深度、ブロックサイズ、および他のコーデックパラメータに応じて、特定のコーデックについての性能を最適化するように調整することができる。たとえば、ブロックサイズとパターンデータベースサイズの特定の組合せが与えられると、データベースのネイバー部分は、永続パターン用により多くの余地を生み出すために排除されてよい。
 
【0096】
  さらに、本開示に記載するパターンモード技法により、ハードウェア複雑度が低くなり得る。パターン更新は、永続データベース中の探索にMRUを強制することを要求せずに実施することができる。そうではなく、データベースは、パターンモードブロックについて更新されるだけであり、新規および隣接パターンのみが、永続データベースに追加し直される。
 
【0097】
実施
  本開示の1つまたは複数の実施形態の実施は、パターンモードを使わずにコーディングするのが難しい場合があるコンテンツを調べることによって、最良に論証することができる。
図9および
図10は、それぞれ、パターンモードを用いて、および用いずに、コーディングされる例示的画像コンテンツを示す。図示されるすべての例は、固定レート4:1圧縮を使う。画像品質についての共通の客観的メトリックであるピーク信号対雑音比(PSNR)を使って、客観的品質が測定される。
 
【0098】
  本明細書に記載するコーデックのレート制御機構は、レートと歪みとの間のトレードオフに基づいて、各ブロック用の最良コーディングモードを選択するように設計され得る。したがって、
図10に示すコンテンツ中のブロックの大多数に対してパターンモードが選択されるということは、このタイプのコンテンツに対して優れたコーディング効率をパターンモードが提供することを示す。
 
【0099】
  パターンモードが無効にされた、
図9に示す画像コンテンツは、36.76dBのPSNRを有する。画像コンテンツは、上から下に、再構築画像、ブロックごとのモード選択マップ、および再構築画像のズームイン領域を含む。パターンモードが有効にされた、
図10に示す画像コンテンツは、44.14dBのPSNRを有する。画像コンテンツは、上から下に、再構築画像、ブロックごとのモード選択マップ、および再構築画像のズームイン領域を含む。
 
【0100】
他の検討事項
  本明細書で開示する情報および信号は、種々の異なる技術および技法のいずれかを使用して表すことができる。たとえば、上記の説明全体にわたって参照される場合があるデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場もしくは磁性粒子、光学場もしくは光学粒子、またはそれらの任意の組合せによって表すことができる。
 
【0101】
  本明細書において開示された実施形態に関して記載された様々な例示的な論理ブロック、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、またはその両方の組合せとして実装される場合がある。ハードウェアおよびソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、およびステップは、それらの機能性の点から一般的に上に説明されている。そのような機能性がハードウェアとして実装されるかソフトウェアとして実装されるかは、特定の適用例および全体的なシステムに課された設計制約に依存する。当業者は、説明された機能性を特定の適用例ごとに様々な方式で実装し得るが、そのような実装の決定は、本開示の範囲からの逸脱を引き起こすと解釈されるべきではない。
 
【0102】
  本明細書で説明した技法は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装することができる。そのような技法は、汎用コンピュータ、ワイヤレス通信デバイスハンドセット、またはワイヤレス通信デバイスハンドセットおよび他のデバイスにおける適用例を含む複数の用途を有する集積回路デバイスなどの、様々なデバイスのいずれかにおいて実装され得る。デバイスまたは構成要素として記載された任意の特徴は、集積論理デバイス内で一緒に、または個別であるが相互運用可能な論理デバイスとして別々に実装され得る。ソフトウェアに実装された場合、本技法は、実行されると、上記で説明された方法のうちの1つまたは複数を実施する命令を含むプログラムコードを備えるコンピュータ可読データ記憶媒体に少なくとも部分的によって、実現され得る。コンピュータ可読データ記憶媒体は、パッケージング材料を含むことがあるコンピュータプログラム製品の一部を形成し得る。コンピュータ可読媒体は、ランダムアクセスメモリ(RAM)、たとえば同期式ダイナミックランダムアクセスメモリ(SDRAM)、読取り専用メモリ(ROM)、不揮発性ランダムアクセスメモリ(NVRAM)、電気消去可能プログラマブル読取り専用メモリ(EEPROM)、FLASHメモリ、磁気または光学データ記憶媒体などのようなメモリまたはデータ記憶媒体を含み得る。本技法は、追加または代替として、伝搬信号または電波などの、命令またはデータ構造の形態でプログラムコードを搬送または伝達し、コンピュータによってアクセスされ、読み取られ、および/または実行され得るコンピュータ可読通信媒体に少なくとも部分的によって、実現され得る。
 
【0103】
  プログラムコードは、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価の集積論理回路もしくはディスクリート論理回路のような、1つまたは複数のプロセッサを含み得るプロセッサによって実行され得る。そのようなプロセッサは、本開示に記載された技法のいずれかを実施するように構成され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替実施形態では、プロセッサは、任意の従来型プロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成としても実装され得る。したがって、本明細書で使用する「プロセッサ」という用語は、本明細書で説明する技法の実装に適した、前述の構造、前述の構造または任意の他の構造もしくは装置の任意の組合せのうちの任意のものを指し得る。さらに、いくつかの態様では、本明細書に記載された機能は、符号化および復号のために構成された専用のソフトウェアもしくはハードウェア内に提供され得るか、または複合ビデオエンコーダ/デコーダ(コーデック)に組み込まれ得る。また、技法は、1つまたは複数の回路または論理要素で完全に実装されてよい。
 
【0104】
  本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置において実装され得る。開示する技法を実施するように構成されたデバイスの機能的態様を強調するために、様々な構成要素、またはユニットについて本開示で説明したが、これらの構成要素、またはユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。そうではなくて、上で説明されたように、様々なユニットは、コーデックハードウェアユニットの中で組み合わされてよく、または適切なソフトウェアおよび/もしくはファームウェアとともに、前述のような1つもしくは複数のプロセッサを含む、相互動作可能なハードウェアユニットの集合によって提供されてよい。
 
【0105】
  上記は、異なる様々な実施形態に関連して記載されているが、本開示の教示から逸脱することなく、ある実施形態からの特徴または要素が、他の実施形態と組み合わされてよい。ただし、それぞれの実施形態の間での特徴の組合せは、必ずしもそれらに限定されるとは限らない。本開示の様々な実施形態が説明されてきた。これらおよび他の実施形態は、以下の特許請求の範囲に含まれる。