(57)【要約】  共有ビデオコンテンツの品質および量が増すのに従って、ビデオ符号化規格および技法が、電気通信および他のネットワークにわたる帯域幅消費を削減するように開発され、改善されている。帯域幅消費を削減するための1つの技法がイントラ予測であり、これは、ビデオフレーム内の空間的冗長性を利用する。各ビデオフレームはブロックにセグメント化されてよく、これらのブロックにイントラ予測が適用され得る。ただし、いくつかのブロックのイントラ予測は、他のブロックの完成(たとえば、再構築)に依拠する場合があり、これが並列処理を難しくさせ得る。複数のブロックのイントラ予測に関連付けられた効率およびスループットを向上させるための例示的な技法を提供する。
2017535142.tif 000002
【特許請求の範囲】
【請求項１】
イントラ予測を実施する方法であって、
ネイバー処理ユニットにおいて、第1の複数のネイバーピクセルを受信するステップと、
前記ネイバー処理ユニットによって、イントラ予測処理ユニットによるイントラ予測のための前記第1の複数のネイバーピクセルを準備するステップと、
前記イントラ予測処理ユニットによって、前記準備された第1の複数のネイバーピクセルを受信するステップと、
前記イントラ予測処理ユニットによって、第1の時間期間中に、前記準備された第1の複数のネイバーピクセルを使って、第1の複数のイントラ予測されたピクセルを有する第1のブロックを判断するステップと、
前記ネイバー処理ユニットによって、第2のブロックのイントラ予測のための第2の複数のネイバーピクセルを受信するステップと、
前記ネイバー処理ユニットによって、前記第1の時間期間の少なくとも一部の間に、イントラ予測のための前記第2の複数のネイバーピクセルを準備するステップと、
前記イントラ予測処理ユニットによって、前記第1の時間期間の直後の第2の時間期間中に、前記準備された第2の複数のネイバーピクセルを使って、第2の複数のイントラ予測されたピクセルを有する第2のブロックを判断するステップとを含み、
前記第1のブロック中の前記第1の複数のイントラ予測されたピクセルの少なくともいくつかは、前記第2のブロックを判断するために使われる前記第2の複数のネイバーピクセルの少なくともいくつかと一致する、方法。
【請求項２】
前記第2の時間期間は、実質的に前記第1の時間期間の直後である、請求項1に記載の方法。
【請求項３】
前記第1の複数のネイバーピクセルの前記準備は、前記第1の複数のネイバーピクセルをパディングし、フィルタリングすることを含む、請求項1に記載の方法。
【請求項４】
前記第1および第2のブロックは、両方とも共通イントラ予測モードに関連付けられた変換ブロックである、請求項1に記載の方法。
【請求項５】
前記イントラ予測処理ユニットはN個の処理エンジンを備え、各処理エンジンは、前記第1の時間期間の各サイクル中に異なるピクセルをイントラ予測する、請求項1に記載の方法。
【請求項６】
前記第1のブロックは、MピクセルかけるMピクセルのサイズを有し、前記イントラ予測処理ユニットが前記第1のブロックを判断する前記第1の時間期間は、約M*M/Nサイクルだけ続く、請求項5に記載の方法。
【請求項７】
前記第2の複数のネイバーセルの前記準備は、前記第1のブロックの前記判断が終了されてから約2M/Nサイクル後に始まる、請求項6に記載の方法。
【請求項８】
前記ネイバー処理ユニットは、1サイクルあたり2Nピクセルの読取り帯域幅を有するネイバーバッファから、前記第1および第2の複数のネイバーピクセルを受信する、請求項5に記載の方法。
【請求項９】
前記第1の複数のネイバーピクセルは4M+1個のピクセルを含む、請求項6に記載の方法。
【請求項１０】
前記第1のブロックの前記判断は、前記第1のブロックの残りを判断する前に、イントラ予測されたピクセルのクリティカルな行または列を判断することを含み、イントラ予測されたピクセルの前記クリティカルな行または列は、前記第2のブロックを判断するのに使われる前記第2の複数のネイバーピクセルの少なくともいくつかと対応する、請求項1に記載の方法。
【請求項１１】
イントラ予測を実施するためのプロセッサであって、
イントラ予測のための第1および第2の複数のネイバーピクセルを受信し、準備するように動作可能なネイバー処理ユニットと、
第1の時間期間中に、前記準備された第1の複数のネイバーピクセルを使って、第1の複数のイントラ予測されたピクセルを有する第1のブロックを判断するように動作可能なイントラ予測処理ユニットであって、第2の時間期間中に、前記準備された第2の複数のネイバーピクセルを使って、第2の複数のイントラ予測されたピクセルを有する第2のブロックを判断するようにさらに動作可能な、イントラ予測処理ユニットとを備え、
前記第1のブロック中の前記第1の複数のイントラ予測されたピクセルの少なくともいくつかは、前記第2のブロックを判断するために使われる前記第2の複数のネイバーピクセルの少なくともいくつかと一致し、
前記ネイバー処理ユニットは、前記第1の時間期間の少なくとも一部の間に、前記第2の複数のネイバーピクセルを準備するようにさらに動作可能である、プロセッサ。
【請求項１２】
前記第2の時間期間は、実質的に前記第1の時間期間の直後である、請求項11に記載のプロセッサ。
【請求項１３】
前記ネイバー処理ユニットは、前記第1の複数のネイバーピクセルをパディングし、フィルタリングするようにさらに動作可能である、請求項11に記載のプロセッサ。
【請求項１４】
前記第1および第2のブロックは、両方とも共通イントラ予測モードに関連付けられた変換ブロックである、請求項11に記載のプロセッサ。
【請求項１５】
前記イントラ予測処理ユニットはN個の処理エンジンを備え、各処理エンジンは、前記第1の時間期間の各サイクル中に異なるピクセルをイントラ予測するように動作可能である、請求項11に記載のプロセッサ。
【請求項１６】
前記第1のブロックは、MピクセルかけるMピクセルのサイズを有し、前記第1の時間期間は、約M*M/Nサイクルだけ続く、請求項15に記載のプロセッサ。
【請求項１７】
前記ネイバー処理ユニットは、前記イントラ予測処理ユニットが前記第1のブロックを判断し終えてから約2M/Nサイクル後に、前記第2の複数のネイバーセルを準備し始めるように動作可能である、請求項16に記載のプロセッサ。
【請求項１８】
前記第1および第2の複数のネイバーピクセルを記憶するように動作可能なネイバーバッファをさらに備え、前記ネイバーバッファは、1サイクルあたり2Nピクセルの読取り帯域幅を有する、請求項15に記載のプロセッサ。
【請求項１９】
前記第1の複数のネイバーピクセルは4M+1個のピクセルを含む、請求項16に記載のプロセッサ。
【請求項２０】
前記イントラ予測処理ユニットは、前記第1のブロックの残りを判断する前に、前記第1のブロック中のイントラ予測されたピクセルのクリティカルな行または列を判断するようにさらに動作可能であり、イントラ予測されたピクセルの前記クリティカルな行または列は、前記第2のブロックを判断するのに使われる前記第2の複数のネイバーピクセルの少なくともいくつかと対応する、請求項11に記載のプロセッサ。
【請求項２１】
ビデオデコーダであって、
イントラ予測を実施するように動作可能なイントラ予測モジュールであって、
イントラ予測のための第1および第2の複数のネイバーピクセルを受信し、準備するように動作可能なネイバー処理ユニットと、
第1の時間期間中に、前記準備された第1の複数のネイバーピクセルを使って、第1の複数のイントラ予測されたピクセルを有する第1のブロックを判断するように動作可能なイントラ予測処理ユニットであって、第2の時間期間中に、前記準備された第2の複数のネイバーピクセルを使って、第2の複数のイントラ予測されたピクセルを有する第2のブロックを判断するようにさらに動作可能である、イントラ予測処理ユニットとを備え、
前記ネイバー処理ユニットは、前記第1の時間期間の少なくとも一部の間に、前記第2の複数のネイバーピクセルを準備するようにさらに動作可能である、イントラ予測モジュールと、
第1の残差ブロックおよび第2の残差ブロックを与えるように動作可能な逆変換モジュールと、
第1の再構築ブロックを判断するために、前記第1のブロックを前記第1の残差ブロックと加えるように動作可能な加算器であって、第2の再構築ブロックを判断するために、前記第2のブロックを前記第2の残差ブロックと加えるようにさらに動作可能である、加算器とを備え、
前記第1の再構築ブロックは、前記第2のブロックを判断するために使われる前記第2の複数のネイバーピクセルの少なくともいくつかを含む、ビデオデコーダ。
【請求項２２】
前記第1および第2の再構築ブロックを、参照フレームの部分として記憶するように動作可能な参照フレームバッファをさらに備え、
前記参照フレームは、後に続く動き補償、イントラ予測、およびプレゼンテーションデバイスにおける表示のうちの少なくとも1つのために使われ得る、請求項21に記載のビデオデコーダ。
【請求項２３】
前記イントラ予測処理ユニットはN個の処理エンジンを備え、各処理エンジンは、前記第1の時間期間の各サイクル中に異なるピクセルをイントラ予測するように動作可能である、請求項21に記載のビデオデコーダ。
【請求項２４】
前記第1のブロックは、MピクセルかけるMピクセルのサイズを有し、前記第1の時間期間は、約M*M/Nサイクルだけ続く、請求項23に記載のビデオデコーダ。
【請求項２５】
前記第1および第2の複数のネイバーピクセルを記憶するように動作可能なネイバーバッファをさらに備え、前記ネイバーバッファは、1サイクルあたり2Nピクセルの読取り帯域幅を有する、請求項23に記載のビデオデコーダ。
【請求項２６】
前記ネイバーバッファは、16NのRAM幅を有するネイバーRAMを備える、請求項23に記載のビデオデコーダ。
【請求項２７】
前記第1の複数のネイバーピクセルは4M+1個のピクセルを含む、請求項24に記載のビデオデコーダ。
【請求項２８】
前記イントラ予測処理ユニットは、前記第1のブロックの残りを判断する前に、前記第1のブロック中のイントラ予測されたピクセルのクリティカルな行または列を判断するようにさらに動作可能であり、イントラ予測されたピクセルの前記クリティカルな行または列は、前記第2のブロックを判断するのに使われる前記第2の複数のネイバーピクセルの少なくともいくつかと対応する、請求項21に記載のビデオデコーダ。
【請求項２９】
前記逆変換モジュールは、前記クリティカルな行または列に対応する残差値を生成するようにさらに動作可能である、請求項28に記載のビデオデコーダ。
【請求項３０】
前記加算器は、前記第2の複数のネイバーピクセルの少なくともいくつかを生成するために、前記クリティカルな行または列を、前記対応する残差値と加えるようにさらに動作可能である、請求項29に記載のビデオデコーダ。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は概して、ビデオエンコーダおよびビデオデコーダにおけるイントラ予測に関し、より詳細には、パイプライン化技法を使うイントラ予測のハードウェア実装に関する。
【背景技術】
【０００２】
高効率ビデオコーディング(HEVC)において使われるようなビデオコーデックは、モバイルデバイス、スマートTV、および多くの他のビデオアプリケーションにおける使用のためにビデオを圧縮するための様々な技法を組み込む。1つのそのような技法がイントラ予測であり、これは、ビデオストリーミングに求められるファイルサイズおよび/または帯域幅を低減するのに、ビデオフレーム内の空間的冗長性を利用する。
【０００３】
ビデオフレームは概して、ピクセルのブロックにセグメント化され、所与のブロックはしばしば、その周りに接するブロックおよびピクセルと高度に相関する。したがって、ブロック内のピクセルは、すでに算出されているネイバーピクセルから補間され得る。依存の性質は、イントラ予測モードとして記憶することができる。イントラ予測モードが判断されると、補間されたピクセルと実際のピクセルとの間の差分(たとえば、残差)のみが符号化される必要がある。これらの残差は、離散コサイン変換(DCT)、量子化、およびエントロピーコーディングを含む後続の処理段階において符号化される。空間的冗長性を考慮に入れることによって、イントラ予測は全体的圧縮比を大きく増大させることができる。
【０００４】
HEVCでは、いくつかの参照フレーム(たとえば、イントラ符号化ピクチャ、すなわちIフレーム)は、(インター予測とは反対に)イントラ予測によって全体が符号化され、復号される。参照フレームは複数のコーディングユニット(CU)を含んでよく、各CUは、M×Mのサイズの変換ユニット(TU)に分割され得る。CUは、クロマまたはルーマ情報に関連付けられ得るコーディングブロック(CB)にさらに分割され得る。同様に、TUは変換ブロック(TB)に分割され得る。イントラ予測モードは計算上、TBレベルで適用され得る。
【０００５】
HEVC規格は、イントラ予測を実施するのに、4M+1個のネイバーピクセルが使われ得ると規定し、これらのネイバーピクセルはしたがって、所与のブロック(たとえば、TU)向けのイントラ予測が始まる前にパディングされ、フィルタリングされ、可能性としては他のやり方で調整されなければならない。ブロックのイントラ予測が完了された後、次のブロックのイントラ予測が始まる。2つのブロックは順次処理されてよく、というのは、第2のブロックのイントラ予測は概して、第1のブロックの、および/または他の前に算出されたブロックのイントラ予測から導出された再構築ピクセルに依存し得るからである。したがって、HEVC規格は本質的に、この段階において、各ブロックのある程度の順次処理を求めるが、これは、多くのどのビデオ規格にも当てはまる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】「HEVCワーキングドラフト7」
【非特許文献２】Bross他、「High Efficiency Video Coding (HEVC) Text Specification Draft 7」、ITU-T SG16 WP3およびISO/IEC JTC1/SC29/WG11のビデオコーディング共同研究部会(JCT-VC)、第9回会合:ジュネーブ、スイス、2012年4月27日〜2012年5月7日
【非特許文献３】http://phenix.int-evry.fr/jct/doc_end_user/documents/10_Stockholm/wg11/JCTVC-J1003-v8.zip
【非特許文献４】http://www.itu.int/rec/T-REC-H.265-201304-I
【非特許文献５】「HEVCワーキングドラフト(WD)8」
【発明の概要】
【課題を解決するための手段】
【０００７】
上述した順次処理の要件を仮定して、本開示は、連続ブロック(たとえば、コーディングユニット内の連続変換ユニット)のイントラ予測の間のレイテンシを低減することを目指す。第2のブロックのイントラ予測はしばしば、第1および第2のブロックの相対位置によっては、第1のブロックに関連付けられたすべての再構築ピクセルに依存するわけではなく、単一のクリティカルな行または列のみに依存することに留意されたい。各ブロックが、通常行われるようにラスター走査を使ってイントラ予測される場合、クリティカルな行または列は、第1のブロックの処理サイクルの最後に向かってのみイントラ予測される。クリティカルな行または列のピクセルの再構築、フィルタリング、パディング、および/または他の調整には、多くの処理サイクルがかかり得るので、第2のブロックのイントラ予測は遅延される。HEVCでは、各コーディングユニットは、最大で256個の変換ユニットを含む場合があり、したがってこれらの遅延は、直ちに全体的性能を低減させることになり得る。
【０００８】
提案するハードウェアアーキテクチャは、第1のブロック中のクリティカルな行および列のためのピクセル生成を優先させるように動作可能なイントラ予測処理ユニットを使用することができる。ネイバー処理ユニットは、クリティカルな行および列に対応する再構築ピクセルを受信することができ、第1のブロックのイントラ予測が完了される前に、第2のブロックのイントラ予測のためのネイバーピクセルをさらに準備する(たとえば、パディングし、フィルタリングする)ことができる。こうすることにより、イントラ予測処理ユニットは、ブロックの各々の間を素早く遷移することができる。ネイバー処理およびイントラ予測をインターリーブすることによって、連続ブロック(たとえば、コーディングユニット内の近接変換ユニット)のイントラ予測の間のレイテンシがなくされ、または低減される。
【０００９】
さらに、複数のイントラ予測エンジンが、所与のブロックを処理するために並行して動作することができる。イントラ予測エンジンの数(N)は、ネイバーピクセルを記憶するのに使われる、(たとえば、ネイバーRAMを備える)ネイバーバッファの読取り帯域幅(たとえば、1サイクルあたり2Nピクセル)に比例して変化し得る。概して、イントラ予測エンジンによって使われるメモリの最大読取りレートは、イントラ予測エンジンが再構築のために(および、たとえば、後続ブロックのイントラ予測のために)ピクセルを出力するレートと厳密に一致し得る。開示するシステムおよび方法はしたがって、読取り帯域幅に関連付けられた共通ボトルネックを管理するように変化し得る。
【００１０】
本開示の特徴、態様、および実施形態を、添付の図面とともに記載する。
【図面の簡単な説明】
【００１１】
【図１】本開示の原理による、パイプライン型イントラ予測のための技法を使用するように構成され得るビデオ符号化および復号システムの例を示すブロック図である。
【図２】開示する原理に従って実装することができるビデオエンコーダの例を示すブロック図である。
【図３】開示する原理に従って実装することができるビデオデコーダの例を示すブロック図である。
【図４】イントラ予測のための様々なモードを示す概略図である。
【図５】隣接ブロックへのブロックの依存を示す概略図である。
【図６】イントラ予測サブシステムを示すブロック図である。
【図７】イントラ予測のために選択されるコーディングブロックを示すブロック図である。
【図８】インターリーブ型イントラ予測技法を示すタイミング図である。
【発明を実施するための形態】
【００１２】
これらの例示的な図面および実施形態は、本出願から発行されるいずれかの請求項によって記載される主題の、書面による詳細な説明を与えるものである。これらの例示的な図面および実施形態は、いかなるそのような請求項の範囲も限定するのに使われるべきではない。
【００１３】
さらに、同様の参照番号は、便宜上、同様の構造を指すのに使われる場合があるが、様々な例示的実施形態の各々は、別個の変形形態であると見なされる場合がある。
【００１４】
図1は、本開示の原理による、パイプライン型イントラ予測のための技法を使用するように構成され得るビデオ符号化および復号システム10の例を示すブロック図を示す。図1に示すように、システム10は、符号化ビデオを、通信チャネル16を介して宛先デバイス14に送信するソースデバイス12を含む。符号化ビデオはまた、記憶媒体34またはファイルサーバ36上に記憶することができ、必要に応じて宛先デバイス14によってアクセスされ得る。ソースデバイス12および宛先デバイス14は、デスクトップコンピュータ、ノートブック(たとえば、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、電話ハンドセット(たとえば、スマートフォンや、他のパーソナル通信デバイス)、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、モバイルデバイスなどを含む、多種多様なデバイスのうちのいずれを含んでもよい。多くの場合、そのようなデバイスはワイヤレス通信、ワイヤード通信、または両方のために装備され得る。したがって、通信チャネル16は、符号化ビデオデータの送信に好適なワイヤレスチャネル(たとえば、Wi-Fi接続)、ワイヤードチャネル(たとえば、DSL、ケーブルモデム、イーサネット（登録商標）、USB)、またはワイヤレスチャネルとワイヤードチャネルの組合せを備え得る。
【００１５】
本開示の原理は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、(たとえばインターネットを介した)ストリーミングビデオ送信、データ記憶媒体に記憶するためのデジタルビデオの符号化、データ記憶媒体に記憶されたデジタルビデオの復号、および他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。
【００１６】
いくつかの実施形態では、デバイス12、14は、デバイス12、14の各々がビデオ符号化構成要素およびビデオ復号構成要素を含むように、実質的に対称的に動作し得る。したがって、システム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスト、およびビデオテレフォニーなどの適用例をサポートするために、一方向および双方向のビデオ送信の両方をサポートするように構成され得る。
【００１７】
図1に示す実施形態では、ソースデバイス12は、ビデオソース18、ビデオエンコーダ20、変調器/復調器(モデム)22、および送信機24を含む。ビデオソース18は、ビデオキャプチャデバイス(たとえば、ビデオカメラ)、以前にキャプチャされたビデオを含むビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するように動作可能なビデオフィードインターフェース、およびソースビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステムのどの組合せまたは個々の事例を含んでもよい。いくつかの実施形態は、ビデオソース18はビデオカメラであってよく、ソースデバイス12および宛先デバイス14は、カメラ付き携帯電話またはビデオ付き携帯電話を形成してもよい。ただし、本開示で説明する技法は、概してビデオコーディングに適用可能であり、ワイヤレスおよび/またはワイヤード適用例に適用され得る。
【００１８】
キャプチャされた、事前にキャプチャされた、またはコンピュータによって生成されたビデオは、ビデオエンコーダ20によって符号化されてもよい。符号化ビデオ情報は、ワイヤレス通信プロトコルなどの通信規格に従ってモデム22によって変調され、送信機24を介して宛先デバイス14に送信され得る。モデム22は、信号変調のために設計された様々なミキサ、フィルタ、増幅器、および他の構成要素を含み得る。送信機24は、増幅器、フィルタ、および1つまたは複数のアンテナを含む、データを送信するために設計された回路を含み得る。
【００１９】
ビデオエンコーダ20によって符号化された、キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータ生成されたビデオはまた、後で消費するために記憶媒体34またはファイルサーバ36に記憶され得る。記憶媒体34は、ブルーレイディスク、DVD、CD-ROM、フラッシュメモリ、または符号化ビデオを記憶するための他の好適なデジタル記憶媒体を含み得る。記憶媒体34に記憶された符号化ビデオは、次いで、復号および再生のために宛先デバイス14によってアクセスされ得る。
【００２０】
ファイルサーバ36は、符号化ビデオを記憶すること、およびその符号化ビデオを宛先デバイス14に送信することが可能な任意のタイプのサーバであり得る。例示的なファイルサーバとしては、(たとえば、ウェブサイトのための)ウェブサーバ、FTPサーバ、ネットワーク接続ストレージ(NAS)デバイス、ローカルディスクドライブ、または符号化ビデオデータを記憶し、その符号化ビデオデータを宛先デバイスに送信することが可能な任意の他のタイプのデバイスを含む。ファイルサーバ36からの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、または両方の組合せであってよい。ファイルサーバ36は、インターネット接続を含む任意の標準データ接続を介して宛先デバイス14によってアクセスされ得る。これは、ファイルサーバ上に記憶された符号化ビデオデータにアクセスするのに適した、ワイヤレスチャネル(たとえば、Wi-Fi接続)、ワイヤード接続(たとえば、DSL、ケーブルモデム、イーサネット（登録商標）、USB)、またはその両方の組合せを含み得る。
【００２１】
図1の例では、宛先デバイス14は、受信機26、モデム28、ビデオデコーダ30、およびディスプレイデバイス32を含む。受信機26はチャネル16を介して情報を受信し、モデム28はその情報を復調して、ビデオデコーダ30のための復調ビットストリームを生じる。チャネル16を介して通信される情報は、ビデオデータを復号する際にビデオデコーダ30が使用する、ビデオエンコーダ20によって生成された様々なシンタックス情報を含み得る。そのようなシンタックスはまた、記憶媒体34またはファイルサーバ36上に記憶された符号化ビデオデータとともに含まれ得る。ビデオエンコーダ20およびビデオデコーダ30の各々は、ビデオデータを符号化または復号することが可能なそれぞれのエンコーダ-デコーダ(コーデック)の一部を形成し得る。
【００２２】
ディスプレイデバイス32は、宛先デバイス14と一体化されてよく、またはその外部にあってよい。いくつかの例では、宛先デバイス14は、一体化されたディスプレイデバイスを含み、また、外部ディスプレイデバイスとインターフェースするように構成され得る。他の例では、宛先デバイス14はディスプレイデバイスであり得る。概して、ディスプレイデバイス32は、復号ビデオデータをユーザに表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのうちのいずれを備えてもよい。
【００２３】
図1に示す実施形態では、通信チャネル16は、無線周波数(RF)スペクトルまたは1つもしくは複数の物理伝送線路などの任意のワイヤレス通信媒体またはワイヤード通信媒体、あるいはワイヤレス媒体とワイヤード媒体の任意の組合せを備え得る。通信チャネル16は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはグローバルネットワーク(たとえば、インターネット)など、パケットベースネットワークの一部を形成し得る。通信チャネル16は、概して、ビデオデータをソースデバイス12から宛先デバイス14に、またはソースデバイス12と宛先デバイス14との間で双方向に送信するのに好適な任意の通信媒体、または様々な通信媒体の集合体を表す。通信チャネル16は、ソースデバイス12と宛先デバイス14との間の通信を可能にするのに有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。
【００２４】
高効率ビデオコーディング(HEVC)規格は、ITU-Tビデオコーディングエキスパートグループ(VCEG)およびISO/IECモーションピクチャエキスパートグループ(MPEG)のビデオコーディング共同研究部会(JCT-VC)によって開発中である。「HEVCワーキングドラフト7」と呼ばれる、HEVC規格の最新の草案が、2012年6月7日の時点で、http://phenix.it-sudparis.eu/jct/doc_end_user/documents/9_Geneva/wg11/JCTVC-I1003-v3からダウンロード可能である。HEVCワーキングドラフト7の完全な引用は、文書JCTVC-I1003、Bross他、「High Efficiency Video Coding (HEVC) Text Specification Draft 7」、ITU-T SG16 WP3およびISO/IEC JTC1/SC29/WG11のビデオコーディング共同研究部会(JCT-VC)、第9回会合:ジュネーブ、スイス、2012年4月27日〜2012年5月7日である。「HEVCワーキングドラフト(WD)8」と呼ばれる、HEVC規格のさらなる最新草案が、http://phenix.int-evry.fr/jct/doc_end_user/documents/10_Stockholm/wg11/JCTVC-J1003-v8.zipから入手可能である。承認済みHEVC仕様は、2013年4月の時点で、http://www.itu.int/rec/T-REC-H.265-201304-Iにおいて見ることができる。本段落に記載される参考文献の各々は、その全体が参照によって本明細書に組み込まれている。
【００２５】
HEVC規格は、ビデオフレームまたはピクチャが、最大コーディングユニット(LCU)のシーケンスに分割され得ると記載しており、LCUは、コーディングツリーユニット(CTU)とも呼ばれ得る。各CTUは、複数のコーディングツリーブロック(たとえば、1つのルーマCTBおよび2つのクロマCTB)を含み得る。各CTUは、4分木に従ってコーディングユニット(CU)にスプリットされてもよい。概して、4分木データ構造はCUごとに1つのノードを含み、ルートノードがCTUに対応する。たとえば、CTUの4分木は、(サブCUに関連付けられ得る)4つの子ノードにスプリットすることができ、これらの子ノードのうちの1つまたは複数はさらに、別の4つの子ノードにスプリットされる親ノードになり得る。リーフノードとも呼ばれる、4分木の、各最終的なスプリットされない子ノードは、リーフCUと一致し得る。概して、CUは、いくつかの非HEVC規格(たとえば、H.264規格)のマクロブロックと同様の目的を有し、違いはわずかである(たとえば、CUはサイズが変わり得る)。したがって、「CU」および「マクロブロック」という用語は、一般性をまったく失うことなく、本文書において互換的に使われ得る。
【００２６】
各CUは、コーディングノード、ならびにコーディングノードに関連付けられた1つまたは複数の予測ユニット(PU)および1つまたは複数の変換ユニット(TU)を含み得る。CUサイズは、コーディングノードのサイズに対応してよく、概して形状が正方形であり得る。たとえば、CUサイズは、8×8ピクセルから、最大サイズ(たとえば、64×64ピクセル)を有し得るCTUのサイズまで渡り得る。
【００２７】
本開示では、「M×M」および「MかけるM」は、それぞれ、水平方向および垂直方向の寸法に関するビデオブロックのピクセルの寸法(たとえば、16×16ピクセルまたは16かける16ピクセル)を指すために、交換可能に使用されてもよい。概して、16×16ブロックは水平方向に16個のピクセル(x=16)、および垂直方向に16個のピクセル(y=16)を有する。同様に、M×Mブロックは、一般に、水平方向にMピクセルを有し、垂直方向にMピクセルを有し、ここでMは非負整数値を表す。ブロック内のピクセルは、行および列に配列され得る。ブロック(たとえば、HEVCにおけるTU)用の共通サイズは、4×4、8×8、16×16、および32×32を含み得る。ただし、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要はない。たとえば、ブロックはM×Pピクセルを備えてよく、ここで、Pは必ずしもMに等しいとは限らない。
【００２８】
リーフCUに関連付けられたシンタックスデータは、1つまたは複数のTUへのリーフCUの区分を記述し得る。いくつかの例では、リーフCUに対応する残差サンプルは、「残差4分木」(RQT)として知られている4分木構造を使ってTUに下位分割することができ、ここで、RQTのリーフノードはTUに関連付けられる。すなわち、リーフCUは、リーフCUがどのようにTUに区分されるかを示す4分木を含み得る。RQT(たとえば、TU4分木)は、リーフCUに概して対応するルートノードを有することができ、CU4分木のルートノードは概して、LCUに対応し得る。したがって、1つまたは複数のTU4分木は、CU4分木内にネストされてよい。
【００２９】
スプリットされていない、RQTの子ノードは、リーフTUに関連付けられ得る。概して、本開示では、別段に明記されていない限り、リーフCUおよびリーフTUを指すのに、それぞれCUおよびTUという用語を使用する。
【００３０】
HEVC規格は、TU単位での変換を許可し、ここでTUサイズはCUの間で変わり得る。TUは、形状が正方形または非正方形(たとえば、矩形)であり得る。さらに、TUは通常、イントラ予測中の所与のCU内のPUと同じサイズであるか、またはそれらよりも小さいが、TUは、インター予測されたCUの対応するPUよりも大きくてよい。TUに関連付けられたピクセル差分値は、変換係数を生成するために変換されてよく、変換係数は量子化され得る。
【００３１】
CUに関連付けられたシンタックスデータは、1つまたは複数のPUへの、CUの区分を記述することもでき、ここでPUは、予測に関連したデータを含む。一般に、PUは、対応するCUの全部または一部に対応する空間エリアを表し、PUに対する参照サンプルを取り出すためのデータを含んでよい。利用可能なPU区分モードは、CUがスキップまたは直接モードで符号化されるのか、イントラ予測モード符号化されるのか、それともインター予測モードで符号化されるのかに応じて変わり得る。たとえば、CUは、イントラ予測モード符号化されると、CUと同じサイズを有する単一のPUまたは各々がCUのサイズの4分の1である4つの正方形PUと一致し得る。さらに、PUについてのデータ(たとえば、イントラ予測モードインジケータ)は、PUに対応する1つまたは複数のTUに該当し得るように、RQT中に含まれ得る。いくつかのシナリオでは、PUは形状が非正方形(たとえば、矩形)であり得る。
【００３２】
概して、イントラコーディング(たとえば、イントラ予測コーディング)の場合、CUに属するすべてのTUは、同じイントラ予測モードを共有する。つまり、CUは、イントラ予測コーディング用のPUと同じサイズであってよく、そうであることによって、CUのすべてのTUについての予測値を算出するための共通イントラ予測モードを有する。いくつかのシナリオでは、イントラ符号化CUは4つのPUに分割されてよく、CUは、少なくとも4つのTUに分割されてもよい。したがって、イントラ予測中、TUは、対応するPUよりもサイズが小さいか、または等しい。イントラコーディングの場合、ビデオエンコーダは、イントラ予測モードを使用して各TUの残差値を、TUに対応するCUの部分と元のブロックとの間の差分として算出し得る。
【００３３】
インター予測中、TUは、共通CU内のPUよりもサイズが大きく、小さく、または等しくてよい。したがって、TUは複数のPUに対応してよく、ここでTUは、対応するPUの各々よりも大きい。代替として、PUは複数のTUに対応してよく、ここでPUは、対応するTUの各々よりも大きい。ただし、PUもTUも、対応するCUよりも大きくない場合がある。
【００３４】
ビデオエンコーダ20およびビデオデコーダ30は、HEVC規格またはHEVC規格に対する拡張などのビデオ圧縮規格に従って動作すればよい。代替または追加として、ビデオエンコーダ20およびビデオデコーダ30は、代替的にMPEG-4、Part 10、アドバンストビデオコーディング(AVC)と呼ばれる国際電気通信連合電気通信標準化部門(ITU-T)H.264規格など、他のプロプライエタリ規格もしくは業界規格、またはそのような規格の拡張に従って動作し得る。他の例には、VP9、MPEG-2およびITU-T H.263があり得る。しかしながら、本開示の技法は、いかなる特定のコーディング規格または技法にも限定されない。
【００３５】
図1には示されていないが、いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は各々、オーディオエンコーダおよびオーディオデコーダと一体化されてもよく、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切な多重化および多重化解除モジュール、または他のハードウェアおよび/もしくはソフトウェアを含んでもよい。適用可能な場合、いくつかの実施形態では、多重化および多重化解除モジュールは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)のような他のプロトコルに準拠し得る。
【００３６】
ビデオコーダは、本開示に記載のように、ビデオエンコーダ、ビデオデコーダまたは両方を指し得る。ビデオエンコーダ20およびビデオデコーダ30は各々、1つもしくは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアまたはそれらの任意の組合せなど、様々な適切なコーダ回路のいずれかとして実装され得る。本技法が少なくとも部分的にソフトウェアで実装されるとき、デバイスは、ソフトウェアのための命令を適切な非一時的コンピュータ可読媒体に記憶し、本開示の技法を実施するために1つまたは複数のプロセッサを使用してハードウェアでその命令を実行し得る。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダ内に含まれてもよく、そのいずれかは、それぞれのデバイス内に、組み合わされたエンコーダ/デコーダ(コーデック)の一部として組み込まれてもよい。
【００３７】
ビデオエンコーダ20およびビデオデコーダ30の一方または両方が、イントラ予測プロセスを改善するための、本開示に記載する技法のいずれかまたはすべてを実装し得る。
【００３８】
図2は、本開示する原理に従って実装することができるビデオエンコーダ20の例を示すブロック図を示す。ビデオエンコーダ20は、向上したイントラ予測のための、開示する技法のいずれかまたはすべてを実施するように構成され得る。例示のために、ただし、向上したイントラ予測プロセスから恩恵を受け得る他のコーディング規格または方法に関して本開示を限定することなしに、ビデオエンコーダ20についてHEVCのコンテキストで説明する。
【００３９】
ビデオエンコーダ20は、ビデオフレーム内のコーディングユニット(CU)のイントラコーディングおよびインターコーディングを実施し得る。イントラコーディングは、所与のビデオフレーム内のビデオ中の空間冗長性を低減またはなくすために、空間予測に依拠する。インターコーディングは、ビデオシーケンスの現在のフレームと前にコーディングされたフレームとの間の時間的冗長性を低減またはなくすために時間的予測に依拠する。前にコーディングされたフレームは、ビデオシーケンス中で(たとえば、ピクチャグループ(GOP)内で)、現在のフレームの前および/または後であってよい。イントラモード(Iモード)は、いくつかの空間ベースのビデオ圧縮モードのいずれかを指し得る。単方向予測モード(Pモード)または双方向予測モード(Bモード)などのインターモードは、いくつかの時間ベースのビデオ圧縮モードのいずれかを指し得る。
【００４０】
図2に示すように、ビデオエンコーダ20は、符号化されるべきビデオフレーム内の現在のビデオブロックを受信する。図2の例では、ビデオエンコーダ20は、動き補償モジュール44、動き推定モジュール42、イントラ予測モジュール46、参照フレームバッファ64、加算器50、変換モジュール52、量子化モジュール54、およびエントロピー符号化モジュール56を含む。変換モジュール52は、1つまたは複数の変換ユニット(TU)を含む残差データのブロックに変換(たとえば、離散コサイン変換(DCT))を適用し、ここで各TUは、複数の変換ブロック(たとえば、1つのルーマTBおよび2つのクロマTB)を含み得る。ビデオブロック再構築のために、ビデオエンコーダ20は、逆量子化モジュール58、逆変換モジュール60、および加算器62も含む。ブロック境界をフィルタリングして、再構築ビデオからブロッキネスアーティファクトを除去するために、デブロッキングフィルタ(図示せず)が含まれてもよい。必要に応じて、デブロッキングフィルタは、一般に加算器62の出力をフィルタリングする。追加のフィルタ(ループ内またはループ後)がデブロッキングフィルタに加えて使用されてもよい。追加フィルタは、簡潔のために図示されていないが、インループフィルタリングのための加算器50の出力においてなど、ビデオエンコーダ20内の様々な場所において含まれてよい。
【００４１】
説明しやすいように、別個の機能的モジュールとして示されているが、ビデオエンコーダ20内の構成要素のうちの任意のものの構造および機能性は、互いと高度に統合されてよい。たとえば、いくつかの実施形態では、動き推定モジュール42は、動き補償モジュール44と高度に統合され得る。
【００４２】
符号化プロセス中に、ビデオエンコーダ20は、コーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは、複数のビデオブロック、たとえば、最大コーディングユニット(LCU)に分割され得る。動き推定モジュール42および動き補償モジュール44は、時間圧縮を行うために、参照フレームバッファ64に記憶された1つまたは複数の参照フレーム中の1つまたは複数のブロックに対する受信ビデオブロックのインター予測コーディングを実施する。イントラ予測モジュール46は、空間圧縮を行うために、コーディングされるべきブロックと同じフレームまたはスライス中の1つまたは複数の隣接ブロックに対する受信ビデオブロックのイントラ予測コーディングを実施し得る。イントラ予測モジュール46は、本文書において後で論じるように、開示する原理に従って改良され得る。
【００４３】
モード選択モジュール40は、各モードについてのレート歪み分析に基づいて、コーディングモードのうちの1つ(たとえば、イントラまたはインター)を選択し得る。この選択に基づいて、得られたイントラまたはインターコード化ブロックは、残差ブロックを表す残差データを生成するために加算器50に、および参照フレーム中で使用するための符号化ブロックを再構築するために加算器62に与えられ得る。モード選択モジュール40はまた、イントラ予測モードインジケータ、動きベクトル、区分情報、および他のそのようなシンタックス情報などのシンタックス要素をエントロピー符号化モジュール56に与え得る。いくつかのビデオフレームはIフレームとして指定され得、Iフレーム中のすべてのブロックはイントラ予測モードで符号化される。場合によっては、たとえば、動き推定モジュール42によって実施された動き探索によって得られたブロックの予測に満足できないとき、イントラ予測モジュール46は、PフレームまたはBフレーム中のブロックのイントラ予測符号化を実施し得る。
【００４４】
上述のように、動き推定モジュール42および動き補償モジュール44は、高度に統合されてもよいが、概念的な目的のために別々に示されている。動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、参照フレーム中の参照サンプルに対する、現在のフレーム中の予測ユニット(PU)の変位を指示することができ、ここでPUは、複数の予測ブロック(たとえば、1つのルーマPBおよび2つのクロマPB)を含み得る。参照サンプルは、ピクセル差分メトリックに関して、コーディングされるPUと厳密に合致することが認められるブロックであり得る。ピクセル差分メトリックは、絶対値差分和(SAD)、2乗差分和(SSD)、または他の差分メトリックを伴い得る。
【００４５】
動き推定モジュール42は、PUを参照フレームバッファ64に記憶された参照フレームの参照サンプルと比較することによってインターコード化フレームのPUの動きベクトルを算出する。いくつかの例では、ビデオエンコーダ20は、参照フレームバッファ64内に記憶された参照フレームのサブ整数ピクセル位置に関する値を算出し得る。たとえば、ビデオエンコーダ20は、参照フレームの4分の1ピクセル位置の値、8分の1ピクセル位置の値、または他の分数ピクセル位置の値を算出すればよい。したがって、動き推定モジュール42は、フルおよび分数ピクセル位置の両方に対する動き探索を実施し、分数ピクセル精度で動きベクトルを出力し得る。いくつかの実施形態では、動き探索は、動きを十分に表すことができるルーマPBを使えばよい。動き推定モジュール42は、エントロピー符号化モジュール56および動き補償モジュール44に、算出された動きベクトルを送信し得る。
【００４６】
動き補償モジュール44によって実施される動き補償は、動き補償モジュール42によって判断され得る動きベクトルに基づいて、PUについての値をフェッチまたは生成することを伴い得る。動き補償モジュール44は、現在のビデオブロックのPUについての動きベクトルを受信すると、参照フレームのうちの1つにおいて動きベクトルが指し示す対応するブロックの位置を特定することができる。加算器50は、以下で論じるように、コーディングされる現在のビデオブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ブロックを表す残差データを形成する。概して、動き推定モジュール42は、動きベクトルを算出するために、ルーマ成分に対する動き推定を実施し、動き補償モジュール44は、クロマ成分とルーマ成分の両方についての動きベクトルを使う。
【００４７】
イントラ予測モジュール46は、動き推定モジュール42および動き補償モジュール44によって実施されるインター予測の代替として、受信ブロックをイントラ予測符号化することができる。イントラ予測モジュール46は、隣接する、前にコーディングされたブロック、たとえば、ブロックについての左から右へ、上から下への符号化順序を仮定すると、現在ブロックの上、右上、左上、左、または左下のブロックに対して受信ブロック(たとえば、変換ブロック)を符号化し得る。イントラ予測モジュール46は、様々な異なるイントラ予測モードを有して構成され得る。たとえば、イントラ予測モジュール46は、符号化されているコーディングユニットのサイズに基づいて、一定数の方向性予測モード、たとえば、33個の方向性予測モードを有して構成され得る。イントラ予測モジュール46は、他のタイプの予測モード、たとえば、平面予測モードおよびDC予測モードを有して構成されてもよい。
【００４８】
イントラ予測モジュール46は、たとえば、様々なイントラ予測モードについて誤差値を算出し、最も低い誤差値または別のメトリックによる最も高いスコアを生じるモードを選択することによって、イントラ予測モードを選択することができる。モード選択は、PUレベルで行うことができる。方向性予測モードは、空間的に隣接するピクセル(「ネイバーピクセル」とも呼ばれる)の値を結合し、結合された値を関連PU中の1つまたは複数のピクセル位置に適用するための機能を含み得る。PU中のすべてのピクセル位置についての値が算出されると、イントラ予測モジュール46は、関連PUと符号化されるべき受信ブロックとの間のピクセル差分に基づいて、予測モードの誤差値を算出し得る。いくつかの実施形態では、イントラ予測モジュールは、どのモードが、最も低い誤差値または別のメトリックによる最も高いレーティングをもたらすか判断するために、すべてのイントラ予測モードをテストすればよい。いくつかの実施形態では、イントラ予測モジュール46は、許容可能な誤差値または別のメトリックによる十分なレーティングをもたらすイントラ予測モードが判断されるまで、イントラ予測モードをテストし続けてよい。利用可能イントラ予測モードのサブセットをテストすることによって、求められる処理レイテンシおよび処理帯域幅が低下し得る。
【００４９】
イントラ予測モジュール46は、代替または追加として、様々なイントラ予測モードをテストするときにレート歪み分析を使ってよく、各PUについて、(テストされたモードの中で)最良レート歪み特性を有するイントラ予測モードを選択すればよい。レート歪み分析は概して、符号化ブロックと対応する元の符号化されていないブロックとの間の歪み(たとえば、誤差)の量、ならびに符号化ブロックを生じるのに必要とされるビット数(および得られるビットレート)を判断する。イントラ予測モジュール46は、どのイントラ予測モードがブロックに関する最良のレート歪み値を示すのか判断するために、様々な符号化ブロックに関する歪みおよびビットレートから比を算出してもよい。イントラ予測モードを選択した後、イントラ予測モジュール46は、選択されたイントラ予測モードに関連付けられたPUを加算器50に送ればよい。選択されたイントラ予測モードのインジケータは、ビデオエンコーダ20によって符号化ビデオデータ出力に含められるために、エントロピー符号化モジュール56に送られてよい。
【００５０】
モード選択フェーズ中、イントラ予測モジュール46は、参照フレームバッファ64に記憶された情報を使って、残差ブロックの値をイントラ予測することができる。イントラ予測算出は、ブロックレベル(たとえば、一度に1つの変換ユニット(TU)または変換ブロック(TB))で起こってよく、ここでいくつかのTUは、対応するコーディングユニット(CU)、およびイントラ予測モードが計算される予測ユニット(PU)よりも小さくてよい。さらに、CU内の1つのTUのイントラ予測は、やはりCU内にある隣接TUのイントラ予測および再構築に依存し得る。開示する原理によると、イントラ予測エンジンは、イントラ予測中の連続ブロック(たとえば、TU)の、改善されたパイプライン化を可能にし得る。これらの原理については、本文書において後で論じる。
【００５１】
ビデオエンコーダ20は、符号化されている元のビデオブロックから、動き補償モジュール44またはイントラ予測モジュール46によって算出された予測データを減算することによって、残差ブロックを表す残差データを判断する。加算器50は、この減算演算を実施する1つまたは複数の構成要素を表す。残差ブロックは、ピクセル差分値の2次元の行列に対応し得る。残差ブロック中の値は、イントラ予測またはインター予測ブロック内およびコーディングされるべき元のブロック内のコロケートピクセルの値の間の差分(たとえば、誤差)に対応し得る。差分は、コーディングされるブロックのタイプに応じて、クロマ差分またはルーマ差分であり得る。
【００５２】
イントラ予測中、部分的にイントラ予測されたCUまたはPUのブロックサイズの(たとえば、TUサイズの)部分が、加算器50、変換モジュール52、量子化モジュール54、逆量子化モジュール58、逆変換モジュール60、加算器62、および参照フレームバッファ64を伝播し得る。したがって、第2のブロック(たとえば、TU)のイントラ予測は、第1および第2のブロックが共通CUまたはPUに関連付けられている場合であっても、すでに符号化されている第1のブロックに関連付けられた参照値を使用することができる。
【００５３】
変換モジュール52は残差データからTUを形成することができ、ここで各TUは、複数の変換ブロック(たとえば、1つのルーマTBおよび2つのクロマTB)を含み得る。変換モジュール52は、離散コサイン変換(DCT)、離散サイン変換(DST)、離散フーリエ変換(DFT)、アダマール変換、ウェーブレット変換、整数変換、サブバンド変換、または別のタイプの変換などの画像変換(たとえば、2次元の変換)をTUに適用し、変換係数を含むビデオブロックを生じる。TUに関連付けられた複数のTBは、同時に、または連続して計算され得る。
【００５４】
変換モジュール52は、得られた変換係数を量子化モジュール54に送ってよく、量子化モジュール54は次いで、変換係数を量子化すればよい。量子化は概して、変換係数が、離散値の縮小セットにコンバートされるプロセスを指し、このプロセスは、精度を犠牲にして、効率の増大(たとえば、より高い圧縮)をもたらす。量子化のレベルは、より高いエネルギー係数が、より低いエネルギー係数よりも少なく量子化されるように、適応的に判断すればよい。さらに、より低いエネルギー係数のいくつかは、量子化モジュール54によって量子化された後、「0」の値にセットされてよい。こうすることにより、以下で説明するように、エントロピー符号化から向上した圧縮が可能になり得る。
【００５５】
量子化に続いて、ビデオエンコーダ20は、変換係数を走査してよく、量子化された変換係数を有する2次元行列から1次元アレイを作成する。走査は、比較的高いエネルギーを有することが多い、より低い周波数係数を、アレイの前により近く置くように、およびより高い周波数係数を、アレイの後ろにより近く置くように設計され得る。いくつかの例では、ビデオエンコーダ20は、変換係数を走査するのに、あらかじめ定義された走査順序(たとえば、ジグザグ走査パターン)を使えばよい。他の例では、ビデオエンコーダ20は適応的走査を実施すればよく、選択された走査順序はデータストリーム中に符号化され得る。走査は、たとえば、エントロピー符号化モジュール56によって実施されてよい。
【００５６】
変換係数が走査されると、エントロピー符号化モジュール56は、コンテキスト適応型可変長コーディング(CAVLC)、確率間隔区分エントロピー(PIPE)コーディング、またはコンテキストベース適応2進算術コーディング(CABAC)などのエントロピーコーディングを係数に適用することができる。さらに、エントロピー符号化モジュール56は、動きベクトル(MV)情報、およびビデオデコーダにおいてビデオデータを復号する際に有用な様々なシンタックス要素のいずれかをも符号化することができる。これらのシンタックス要素は、ビデオデコーダによって、符号化ビデオデータを再構築するときに使われ得る。エントロピー符号化モジュール56によるエントロピー符号化の後、得られた符号化ビデオは、ビデオデコーダなどの別のデバイスに送信され得るか、または後で送信するかもしくは取り出すためにアーカイブされ得る。
【００５７】
逆量子化モジュール58および逆変換モジュール60は、ピクセルドメイン中の残差ブロックを再構築するために、たとえば、参照フレームバッファ64に記憶されている参照フレーム用の参照ブロックを作成するために、それぞれ、逆量子化および逆変換を適用する。モジュール58、60は、ビデオデコーダの部分をシミュレートするのに使うことができ、したがって、ビデオデコーダ中に存在する、対応するモジュールと実質的に同様であり得る。動き補償モジュール44は、加算器62とともに、参照フレームバッファ64のフレームのうちの1つの、予測ブロックに残差ブロックを加えることによって、参照ブロックを算出してもよい。動き補償モジュール44はまた、動き推定において使用されるサブ整数ピクセル値を算出するために、再構築された残差ブロックに1つまたは複数の補間フィルタを適用してもよい。加算器62は、参照フレームバッファ64内に記憶するための再構築ビデオブロックを生成するために、動き補償モジュール44によって生成された、動き補償された予測ブロックに、再構築された残差ブロックを加えてもよい。参照フレームバッファ64は、デコーダ中で受信される、実質的に同じビデオ情報を保持することができ、こうすることにより、ビデオエンコーダ20は、イントラ予測モードおよび動きベクトルが適用される間にデコーダによって見られるこの共通「状態」情報に基づいて、イントラ予測モードおよび動きベクトルを正確に符号化することが可能になる。
【００５８】
参照フレームバッファ64に記憶された再構築ビデオブロックは、別のビデオフレーム中のブロックをインターコーディングするために動き推定モジュール42および動き補償モジュール44によって参照ブロックとして使用され得る。追加または代替として、再構築ビデオブロックは、イントラ予測モジュール46によって、同じビデオフレーム中のブロックをイントラコーディングするのに使うことができる。いくつかのシナリオでは、特定の参照ブロックは、イントラ予測にもインター予測にも使うことができず、他の有用な参照ブロックを有する参照フレームの一部であるにすぎないことがある。
【００５９】
図3は、本開示する原理に従って実装することができるビデオデコーダ30の例を示すブロック図を示す。ビデオデコーダ30は、本開示の技法のうちのいずれかまたは全部を実施するように構成され得る。
【００６０】
図3の例では、ビデオデコーダ30は、エントロピー復号ユニット70、動き補償モジュール72、イントラ予測モジュール74、逆量子化モジュール76、逆変換モジュール78、参照フレームバッファ82、および加算器80を含む。ビデオデコーダ30は、いくつかの実施形態では、図2に記載したビデオエンコーダ20に関して説明した符号化パスとは概して逆の復号パスを実施し得る。
【００６１】
説明しやすいように、別個の機能的モジュールとして示されているが、ビデオデコーダ30内の構成要素のうちの任意のものの構造および機能性は、互いと高度に統合されてよい。たとえば、いくつかの実施形態では、エントロピー復号モジュール70は、逆量子化モジュール76と高度に統合され得る。
【００６２】
復号プロセス中に、ビデオデコーダ30は、ビデオエンコーダによって生成された、符号化ビデオスライスのビデオブロックと、関連するシンタックス要素とを表す、符号化ビデオビットストリームを受信する。ビットストリームは、ファイルサーバから、記憶媒体から、および図1に示すように、モデムを介してビデオエンコーダからなど、様々なソースから受信され得る。
【００６３】
エントロピー復号モジュール70は、ビットストリームを生成したビデオエンコーダのエントロピー符号化モジュールによって使われる走査順序をミラーリングする走査を使って(たとえば、逆ジグザグ走査パターン)、受信した値を走査することができる。追加または代替として、走査順序は、予測モード、ブロックサイズ、変換、または他の特性など、コード化ビデオの特性に基づいて、ビデオデコーダ30によって推論され得る。走査順序がどのように判断されたとしても、エントロピー復号モジュール70は、受信した1次元アレイを走査して2次元の行列にするのに、走査順序の逆を使ってよい。エントロピー復号モジュール70は次いで、符号化ビデオをエントロピー復号すればよく、これは、図2のエントロピー符号化モジュール56によって使われるプロセスの逆であるプロセスを伴い得る。
【００６４】
ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルにおける関連シンタックス要素を受信し得る。エントロピー復号モジュール70は、量子化された係数、動きベクトル、イントラ予測モードインジケータ、および他のシンタックス要素を抽出するために、ビットストリームをさらに分析し得る。動きベクトルは動き補償モジュール72によって受信されてよく、イントラ予測モードインジケータはイントラ予測モジュール74によって受信されてよい。
【００６５】
スライスがイントラコード化(I)スライスとしてコーディングされるとき、イントラ予測モジュール74は、イントラ予測モードインジケータと、現在のフレームまたはピクチャの以前に復号されたブロックからのデータとに基づいて、現在のビデオスライスのビデオブロックについての予測データを生成してもよい。このプロセスは、図4〜図5および付随する説明においてより詳しくカバーされる。
【００６６】
ビデオフレームが、インターコード化(たとえば、B、P、またはGPB)スライスとしてコーディングされているとき、動き補償モジュール72は、動きベクトルおよび他のシンタックス情報に基づいて、現在のビデオスライスのビデオブロックについての予測ユニット(PU)を生じ得る。PUは、参照ピクチャリストのうちの1つのリスト内の参照ピクチャのうちの1つから生成されてもよい。ビデオデコーダ30は、参照フレームバッファ82に記憶された参照ピクチャに基づいて、デフォルトの構築技術を使用して、参照フレームリスト(たとえば、HEVC規格によって定義されるリスト0およびリスト1)を構築してもよい。動き補償モジュール72は、動きベクトルおよび他のシンタックス情報を解析することによって、ビデオブロックについての予測情報を判断することができる。この予測情報は、復号される現在のビデオブロック用のPUを生成するのに使うことができる。たとえば、動き補償モジュール72は、予測モード(たとえば、イントラまたはインター)と、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)と、スライスの1つまたは複数の参照ピクチャリストための構築情報と、スライスの各インター符号化ビデオブロックのための動きベクトルと、スライスの各インターコード化ビデオブロックのためのインター予測ステータスと、現在のビデオスライス中のビデオブロックを復号するための他の情報とを決定することができる。
【００６７】
動き補償モジュール72はまた、補間フィルタに基づいて補間を実施してもよい。動き補償モジュール72は、参照ブロックのサブ整数ピクセルについての補間された値を算出するために、ビデオブロックを符号化したビデオエンコーダによって使われるものと同様の補間フィルタを使えばよい。いくつかの実施形態では、動き補償モジュール72は、受信したシンタックス要素からビットストリームを生成したビデオエンコーダによって使用された補間フィルタを判断し、この補間フィルタを使用して予測ブロックを生成してもよい。
【００６８】
逆量子化モジュール76は、ビットストリームの中で提供されエントロピー復号モジュール70によって復号された量子化変換係数を逆量子化(たとえば、量子化解除)する。逆量子化プロセスは、量子化の程度と、同様に、ある程度の量子化誤差は存在し得るが、元の変換係数を判断するのに適用することができる逆量子化の程度とを判断するために、ビデオスライス中の各ビデオブロックについて、ビデオデコーダ30によって算出された量子化パラメータ、すなわちQPYの使用を含み得る。
【００６９】
逆変換モジュール78は、ピクセルまたはピクセル差分ドメイン中で残差データを形成するために、逆変換(たとえば、逆DCT)を適用することができる。逆変換は、図2の変換モジュール52によって使われるものの逆であってよい。残差データは、復号される変換ユニット(TU)、したがって、変換ブロック(TB)と同じサイズを有する残差ブロック中で計算することができる。
【００７０】
動き補償モジュール72および/またはイントラ予測モジュール74がコーディングユニット(CU)の、ブロックサイズの(たとえば、TUサイズの)部分を生成した後、ビデオデコーダ30は、逆変換モジュール78からの残差ブロックを、動き補償モジュール72および/またはイントラ予測モジュール74によって生成された、対応するブロックサイズの予測データと加算することによって、復号ビデオブロックを形成する。加算器80は、この加算演算を実施し、結果を参照フレームバッファ82に記憶する1つの構成要素または複数の構成要素を表す。
【００７１】
イントラ予測中、加算器80は、各逆変換ブロックを、参照フレームバッファ82からの、対応するブロックと繰り返し加算してよく、ここで、対応するブロックは、逆変換ブロックと同じサイズであり、イントラ予測モードインジケータに少なくとも部分的に基づいて選択されてよい。したがって、参照フレームバッファに書き込まれる復号ブロックは、TUと一致し、同じサイズを有し得る。TUサイズの復号ブロックを繰り返し再構築し、参照フレームバッファ82に記憶することによって、参照フレームバッファ82において、完全な復号CUが判断され得る。
【００７２】
本開示の1つの目的は、イントラ予測処理がさらに並列化されるように、TUおよびCUサイズが異なるシナリオを最適化することである。
【００７３】
必要に応じて、ブロッキネスアーティファクトを除去することを目的として、復号ブロックをフィルタリングするためにデブロッキングフィルタが適用されてよい。ピクセル遷移を平滑化するか、またはさもなければビデオ品質を改善するために、(たとえば、コーディングループ内またはコーディングループ後の)他のループフィルタも使用され得る。次いで、所与のフレームまたはピクチャ中の復号ビデオブロックは、参照フレームバッファ82内に記憶される。参照フレームバッファ82は、後に続く動き補償および/またはイントラ予測に使うことができる、この、および他の参照フレームまたはピクチャを記憶することができる。参照フレームバッファ82は、復号ビデオを、ディスプレイデバイス上での表示のために記憶することもできる。
【００７４】
図4は、イントラ予測のための様々なモードを示す概略図を示す。具体的には、図4は、HEVCコーダ用に使うことができる35個のイントラ予測モードを示す。ただし、図4は、本開示を限定することなく、例示のために、向上したイントラ予測プロセスから恩恵を受け得る他のコーディング規格または方法に関してHEVCのコンテキストにあるが。
【００７５】
画像およびビデオフレームは概して、空間的に冗長なデータを含む。空間的冗長性は、所与のピクセルが概して、周辺ピクセルのうちの少なくとも1つと相関があり得ることを含意する。イントラ予測は、ブロック内のピクセルが、ネイバーピクセルに基づいて補間されることを可能にする。選択されたネイバーピクセルは、ブロック内での依存をなくすように、すでに算出されている他のブロック中に置かれてよく、そうすることによって、ブロック内の複数のピクセルの並列イントラ予測が促進される。たとえば、方向性モードを使うとき、ネイバーピクセルは、算出されるブロックの外にある、モード定義方向における最も近いピクセルとして選択されてよい。他のブロックからのピクセルを使うというこの概念について、図5において以下でさらに例示する。
【００７６】
図4に示すように、イントラ予測値は、イントラ予測モードに基づいて、ピクセル401について算出することができる。イントラ予測モードは、ビデオエンコーダにおいて予測ユニット単位で計算することができる。予測ユニットが、対応するコーディングユニットおよびそれと関連付けられたコーディングブロックと同じサイズであるとき、コーディングブロック内の各変換ブロックは、共通のイントラ予測モードを有し得る。イントラ予測モードインジケータは、他のビデオデータとともにビットストリーム中に符号化されてよく、そうすることによって、モードインジケータは、デコーダによって復号プロセス中に使うことができる。いくつかのコーディングユニット(たとえば、インターコーディングされているもの)は、対応するイントラ予測モードインジケータをもたない場合がある。
【００７７】
モード0は、平面コーディング技法のために使うことができ、ここでピクセル401は、HEVC規格によって定義される平面関数に従って算出される。モード1は、DCコーディング技法のために使うことができ、ここでピクセル401は、ネイバーピクセルの平均として算出される。モード2〜34は、方向性コーディング技法のために使うことができる。ここで、モード2〜34に関連付けられた矢印は、ピクセル401の値を判断するためのネイバーピクセルを見つけるための探索方向を示す。矢印が2つのネイバーピクセルの間を指し示す状況において、加重補間関数が、2つのネイバーピクセルの加重平均であり得る中間値を判断するのに使われ得る。
【００７８】
HEVCでは、イントラ予測方式は、ブロックを左から右に、次いで、上から下に(たとえば、英語の本を読むように)、または上から下に、次いで、左から右に(たとえば、いくつかの伝統的な東アジアの文章を読むように)算出することを伴うことが想定され得る。当業者によって理解されるように、ブロック算出順序を(たとえば、ブロックが右から左に、次いで下から上にイントラ予測されるように)回転させるか、または場合によっては変えることが可能であろう。それらのシナリオでは、方向性イントラ予測モードは、すでに算出されているブロックの使用をより促進するように変えられて(たとえば、回転されて)よい。
【００７９】
選択されたモードによっては、ブロック中のピクセルについてのイントラ予測は、1つまたは複数の他のブロック中のネイバーピクセルに依存し得る。たとえば、イントラ予測モード26が選択されると、ピクセル401を含むブロックのイントラ予測は、ブロックの上の隣接ブロックから最も下の行にあるピクセルに依存し得る。別の例では、イントラ予測モード10が選択されると、ピクセル401を含むブロックのイントラ予測は、ブロックの右の隣接ブロックの最右列にあるピクセルに依存し得る。これらの依存の結果、イントラ予測は、隣接ブロックに対して、並行して恣意的には適用されない場合がある。矢印によって示されるように、ネイバーピクセルを与える他のブロックは、イントラ予測が実施される現在のブロックの上、右上、左上、左、および左下にあり得る。
【００８０】
図5は、隣接ブロックへのブロック511の依存を示す概略図を示す。各ブロックは、たとえば、イントラ予測されるべき共通予測ユニット内にある変換ユニットを表し得る。ブロックは、図において、太い境界線によって分離されている。各ブロックは、4×4ピクセルのサイズを有し得る。たとえば、ブロック511は、「a」〜「p」と標示される16個のピクセルを含み得る。
【００８１】
ブロック500、501、502、510および520は、完全には示されていない。ブロック501は、その最下行において、ピクセル「A」、「B」、「C」、および「D」を含み、ブロック502は、その最下行において、ピクセル「E」、「F」、「G」、および「H」を含み、ブロック510は、その最右列において、ピクセル「I」、「J」、「K」、および「L」を含み、ブロック520は、その最右列において、ピクセル「M」、「N」、「O」、および「P」を含み、ブロック500は、その右下隅においてピクセル「R」を含む。
【００８２】
上述したように、HEVCなど、いくつかのビデオコーディング規格は、ブロック511内のピクセルのイントラ予測が、隣接ブロック500、501、502、510および520のうちの少なくとも1つの中のネイバーピクセルの再構築された値の少なくともいくつかに依存すると規定している。依存の性質は、イントラ予測モードによって特徴付けられる。たとえば、垂直イントラ予測モード(たとえば、HEVCにおけるモード26)が選択された場合、ブロック511中のピクセル「a」〜「p」のイントラ予測は、ブロック501中のピクセル「A」〜「D」の再構築された値に依拠し得る。再構築されたピクセルデータは、ブロック501のイントラ予測が完了した後で、または、最低でも、ピクセル「A」〜「D」のイントラ予測が完了した後で利用可能になり得る。したがって、ブロック511のイントラ予測は、いくつかのイントラ予測モードに対しては、ブロック501のイントラ予測が少なくとも部分的に完了された後で始まるように制限され得る。別の例では、水平イントラ予測モード(たとえば、HEVCにおけるモード10)が選択された場合、ブロック511のイントラ予測は、ブロック510中のピクセル「I」〜「L」の再構築された値に依拠し得る。別の例として、HEVCにおけるモード2などの対角イントラ予測モードが選択された場合、ブロック511のイントラ予測は、ブロック510および520中に置かれているピクセル「I」〜「P」に基づく算出を伴い得る。HEVCにおけるモード0(DCモード)など、いくつかのイントラ予測モードは、(利用可能な場合は)ブロック500、501、502、510および520の各々からの値を使用することさえもできる。
【００８３】
パイプライン型アーキテクチャでは、すべての利用可能イントラ予測モードがサポートされる必要がある場合があり、したがって、ブロック500、501、502、510および520の少なくとも部分的な再構築が、511のイントラ予測が始まる前は有益であり得る。以下で説明するように、コーディングブロックは、隣接ブロックのうちの1つ(たとえば、ブロック520)に対する依存をなくすように、イントラ予測モードに基づいて、選択的に回転または転置されてよい。
【００８４】
図6は、イントラ予測サブシステム600を示すブロック図を示す。サブシステム600は、イントラ予測モジュール610、逆変換モジュール620、参照フレームバッファ630、および加算器640を含む。サブシステム600は、ビデオエンコーダおよびビデオデコーダの中に組み込まれてよい。たとえば、サブシステム600が図2のビデオエンコーダ20の中に組み込まれる場合、イントラ予測モジュール610は図2のイントラ予測モジュール46を表すことができ、逆変換モジュール620は図2の逆変換モジュール60を表すことができ、参照フレームバッファ630は図2の参照フレームバッファ64を表すことができ、加算器640は図2の加算器62を表すことができる。
【００８５】
同様に、サブシステム600が図3のビデオデコーダ30の中に組み込まれる場合、イントラ予測モジュール610は図3のイントラ予測モジュール74を表すことができ、逆変換モジュール620は図3の逆変換モジュール78を表すことができ、参照フレームバッファ630は図3の参照フレームバッファ82を表すことができ、加算器640は図3の加算器80を表すことができる。サブシステム600のいくつかの構成要素(たとえば、参照フレームバッファ630)はさらに、他のサブシステムにおいて使われ得る。
【００８６】
サブシステム600は、所与のブロックのイントラ予測が、イントラ予測順序で直前のブロックに少なくとも部分的に依存し得る場合であっても、連続ブロックのイントラ予測を最適化するように設計されてよい。たとえば、各ブロックのイントラ予測は、図7にさらに詳しく示すように、クリティカルな行もしくはクリティカルな列のいずれかの、再構築ピクセルに依存する場合があり、または先行ブロック中のどの再構築ピクセルにも依存しない場合がある。
【００８７】
図6に戻ると、イントラ予測モジュール610は、ネイバーバッファ612、ネイバー処理ユニット614、およびイントラ予測処理ユニット616を備え得る。ネイバーバッファ612は、ネイバーRAM613とインターフェースするための論理および/または回路構成を使って、ネイバーピクセルを記憶し、取り出すことができる。ネイバーピクセルは、ブロックをイントラ予測するときに使うことができるピクセルを含み得る。HEVCのコンテキストでは、ブロックは、等しいか、またはより大きいサイズを有するコーディングユニット(および予測ユニット)に関連付けられ得る変換ユニットを表し得る。ピクセルは、イントラ予測されている最中のブロックのタイプに依存して、クロマおよび/またはルーマ値を含み得る。ここで、ブロックサイズはM×Mであってよく、Mは非負整数値である。Mについての例示的な値は、4、8、16、および32を含む。
【００８８】
ネイバーバッファ612に記憶されたピクセルは、イントラ予測処理ユニット616によってピクセルが受信される前に、フィルタリングされ、パディングされ、および可能性としては他のやり方で調整される必要があり得る。これらの調整アクションは、少なくとも部分的には、イントラ予測処理ユニット616による処理の準備においてネイバーバッファ612からピクセルを受信するネイバー処理ユニット614によって実施され得る。たとえば、ネイバー処理ユニット614は、イントラ予測処理ユニット616がM×Mブロックを処理するために、4M+1個のネイバーピクセルを準備すればよい。これらのネイバーピクセルは、たとえば、図5に示すネイバーピクセル「A」〜「R」を表し得る。
【００８９】
図6に戻ると、イントラ予測処理ユニット616は、処理エンジン617-1〜617-N(PE1〜PE Nとも標示される)を備えることができ、これらは、ビデオ符号化および/またはビデオ復号デバイス中のハードウェアとして実装されてよい。N個の処理エンジン617は各々、処理されるブロック内の異なるピクセルをイントラ予測するために、ネイバー処理ユニット614から受信された入力の共通セットに対して同時に作用し得る。処理エンジン617は各々、サイクル(たとえば、クロックサイクル)ごとに1つのピクセルを計算することが可能であってよく、各処理エンジン617は、ブロック内の異なるピクセルまたはピクセルのセットを算出することができる。したがって、イントラ予測エンジンは、1サイクルあたりN個のピクセルを計算することが可能であってよく、これらは加算器640によって受信され得る。
【００９０】
加算器640は、イントラ予測処理ユニット616によって出力される、N個のイントラ予測されたピクセルの各セットを、逆変換モジュール620によって算出されたN個の対応する残差値に加えればよく、そうすることによって、N個のピクセルを再構築する。再構築ピクセルは、参照フレームバッファ630に記憶され得る。いくつかの再構築ピクセルは、後続ブロックをイントラ予測するために使うことができ、これらの再構築ピクセルはさらに、ネイバーバッファ612に記憶され得る。いくつかの実施形態では、ネイバーバッファ612は、これらの再構築ピクセルを参照フレームバッファ630から読み取り、いくつかの実施形態では、加算器640は、これらの再構築ピクセルを、参照フレームバッファ630とネイバーバッファ612の両方に出力する。
【００９１】
処理エンジンの数、すなわちNは、ネイバーバッファ612のメモリ帯域幅に比例して変化し得る。たとえば、いくつかの実施形態では、ネイバーバッファの読取り帯域幅は、1サイクルあたり2Nピクセルであってよい。ただし、バッファ読取り帯域幅と処理エンジンの数の他の比が使われてもよい。さらに、ネイバーRAM613の形状は、読取り帯域幅および/または処理エンジンの数に関連し得る。たとえば、ネイバーRAM613は、192/N×16Nの形状およびサイズを有するように構成されてよく、ここで、RAM深度が192/Nであってよく、RAM幅が16Nであってよい。ネイバーバッファ612は、RAM613を含むように示されているが、他の適切なタイプのメモリが、追加または代替として使われてよい。
【００９２】
ブロック中のピクセルをイントラ予測するとき、イントラ予測処理ユニット616は、後続ブロック(たとえば、現在のブロックの直後のブロック)のイントラ予測に使われるピクセルを優先させてよい。これらのピクセルは、イントラ予測された後、ネイバーバッファ612に(ならびに参照フレームバッファ630に)再度記憶され得る再構築ピクセルを生成するために、加算器640において、対応する残差値と加算されてよい。再構築ピクセルは次いで、ネイバー処理ユニット614によって、イントラ予測処理ユニット616向けに、フィルタリングされ、パディングされ、可能性としては他のやり方で調整され得る。ピクセルを適切に優先させて、ネイバー処理ユニット614は、イントラ予測処理ユニット616が現在のブロックをイントラ予測し終える前に、次のブロックについての再構築された残差値を用意することができる。したがって、イントラ予測処理ユニット616は、次のブロックが現在のブロックに対する依存を有するとき、ならびに/または現在のブロックおよび次のブロックが共通コーディングユニット内にあるときであっても、現在のブロックが終了された直後に、次のブロックを処理し始めてよい。これは、従来の方法論に勝る大幅な改善である。
【００９３】
図7は、イントラ予測のために選択されるコーディングブロック700を示すブロック図を示す。コーディングブロック700は、複数の変換ブロック710-0、710-1、710-2、および710-3を有することができ、これらは概して、その順序で処理されてよい。非HEVCコンテキストでは、コーディングブロック700はマクロブロック700を指してよく、変換ブロック710-0、710-1、710-2、および710-3は、より全般的には、ブロック710-0、710-1、710-2、および710-3を指してよい。イントラ予測中、コーディングブロック700は、対応する変換ブロック710の各々によって共有される単一のイントラ予測モードを有し得る。ブロック710は、再構築中に参照フレームバッファが更新される単位であり得る。
【００９４】
いくつかのシナリオでは、変換ブロックは、対応するコーディングブロックと同じサイズであってよく、(たとえば、図7に示す)他のシナリオでは、変換ブロックは、関連付けられたコーディングブロック(それ自体が、単一の予測ブロックに関連付けられ得る)よりも小さくてよい。したがって、隣接変換ブロックのグループは、同じイントラ予測モードを有し得る。その結果、コーディングブロック内の変換ブロックは、イントラ予測中に、前の変換ブロックとの規則的依存パターンを有し得る。
【００９５】
ブロック依存の例として、水平イントラ予測モードまたはいくつかの対角イントラ予測モードが選択された場合、ブロック710-1(ブロック1としても標示される)のイントラ予測は、ブロック710-0(ブロック0としても標示される)のクリティカルな列720(たとえば、最右列)の再構築に依存し得る。同様に、いくつかの対角イントラ予測モードが選択された場合、ブロック710-2(ブロック2としても標示される)のイントラ予測は、ブロック710-1のクリティカルな行722(たとえば、最下行)の再構築に依存し得る。
【００９６】
クリティカルな列720は、イントラ予測中にブロック710-1が依存する、ブロック710-0の唯一の一部であり得る。他のネイバーピクセル(たとえば、ブロック710-1の上にあるもの)は、コーディングブロック700の上のコーディングブロックの完了した再構築の結果として、すでに再構築され、ネイバーバッファに記憶されていてよい。したがって、クリティカルな列720は、ブロック710-0のイントラ予測中に優先されてよい。クリティカルな列720についての再構築ピクセルが判断されると、ブロック710-1のイントラ予測のための準備(たとえば、フィルタリングおよびパディング)が始まり得る。この準備は、図8において以下で示すように、ブロック710-0のイントラ予測が依然として進行している間に起こり、完了してよい。したがって、ブロック710-1は、イントラ予測処理ユニットがブロック710-0を処理し終えた直後にイントラ予測されてよい。
【００９７】
同様に、クリティカルな行722は、イントラ予測中にブロック710-2が依存する、ブロック710-1の唯一の一部であり得る。他のネイバーピクセル(たとえば、ブロック710-2の左にあるもの)は、コーディングブロック700の左のコーディングブロックの完了した再構築の結果として、すでに再構築され、ネイバーバッファに記憶されていてよい。したがって、クリティカルな行722は、ブロック710-1のイントラ予測中に優先されてよく、ブロック710-2は、イントラ予測処理ユニットがブロック710-1を処理し終えた直後にイントラ予測されてよい。
【００９８】
クリティカルな行または列が優先されるとき、(図6に示す)N個の処理エンジンは各々、処理するべき異なるピクセルまたはピクセルのセットを選択することができる。M×Mブロック中の単一の行または列がM個のピクセルを有し得るので、単一のクリティカルな行または列をイントラ予測するのに、M/Nサイクルが必要とされ得る。これは実質的には、ネイバー処理ユニットが次のブロックについてのネイバーピクセルを準備するための十分な時間を与えることができる、ブロック全体を処理するのに必要とされ得るM*M/Nサイクル未満であり得る。
【００９９】
たとえば、4×4ブロックであるように示されているブロック710-0に対して働きかけている2つの処理エンジンがある場合、第1の処理エンジンは、第1のサイクル中に、列C3と行R0の交差にあるピクセルについてのイントラ予測値を算出することができる。この同じサイクル中、第2の処理エンジンは、列C3と行R1の交差にあるピクセルについてのイントラ予測値を算出することができる。以降のサイクルにおいて、第1および第2の処理エンジンは、それぞれ、列C3と行R2の交差にあるピクセルについての、および列C3と行R3の交差にあるピクセルについての値を補間し得る。したがって、2つのサイクルにおいて、クリティカルな列720のイントラ予測が完了され得る。クリティカルな列720は次いで、処理エンジンが残りの列を補間している間、次のブロック(たとえば、ブロック710-1)のイントラ予測のために再構築され、記憶され、準備されてよい。言い換えると、ネイバー処理ユニットによって実施されるネイバー処理は、イントラ予測処理ユニットによって実施されるイントラ予測とパイプライン化される。
【０１００】
概して、イントラ予測処理ユニットは、予測のためのピクセルを選択的および柔軟に選択することができる。たとえば、上で明示したように、イントラ予測処理ユニットは、イントラ予測されるべき次のブロック(たとえば、変換ブロック)の相対位置に少なくとも部分的に依存して、列または行に対して作用し得る。イントラ予測されるべき次のブロックが、現在のブロックの右にある場合、現在のブロックの最右列が優先され得る。最右列が処理された後、ブロックの残りは、列方向パターンで処理され得る。同様に、イントラ予測されるべき次のブロックが、現在のブロックの下または左下にある場合、現在のブロックの最下行が優先され得る。現在のブロックの残りは、行方向パターンで処理され得る。
【０１０１】
クリティカルな列および行の優先度付けは、ブロックの異なるイントラ予測順序に合わせて調節されてよい。さらに、いくつかの実施形態では、単一の列または行ではなく、複数の列または行が優先されてよい。たとえば、これは、ブロックのイントラ予測が最も近いおよび2番目に近い行または列の両方を使うときに起こり得る。
【０１０２】
イントラ予測されるブロックの左下にあるブロックからのピクセルをイントラ予測が使用し得ることが図4〜図5に示されてはいても、ブロック710-1は、ブロック710-2に対するいかなる依存も有するようには示されていないことに気付くことができよう。ただし、この依存が、ブロック710-1のイントラ予測を不必要に停止または遅延させることを防止するために、コーディングブロック700は、このタイプの依存が起きたときに回転または転置されてよい。これは、イントラ予測ベクトルを、完成した(または少なくとも部分的に完成した)ブロックに効果的にシフトさせ、そうすることによって、コーディングブロック内の連続変換ブロックの最適化された処理を促進する。
【０１０３】
図7は、4つの変換ブロックを有するコーディングブロックを示しているが、コーディングブロック内の変換ブロックの数は変わり得る。たとえば、コーディングブロックは、1、4、16、64、または256個の変換ブロックに関連付けられ得る。さらに、変換ブロックは、4×4のサイズを有するように示されているが、他のブロックサイズが選択されてよい。たとえば、HEVCでは、変換ブロックは、4×4、8×8、16×16、または32×32のサイズを有し得る。
【０１０４】
図8は、インターリーブ型イントラ予測技法を示すタイミング図を示す。具体的には、このタイミング図は、第1のブロック(ブロック0)のイントラ予測についての第1のタイムライン801、および第2のブロック(ブロック1)のイントラ予測についての第2のタイムライン802を示す。HEVCのコンテキストでは、これらのブロックは変換ブロックを表し得る。タイミング図は、図6に示すイントラ予測サブシステムの実施形態に関連付けられ、ブロックサイズはM×Mであると想定される。すべてのタイミングは、本質的に例示であり、処理遅延および他の要因によって変わり得る。
【０１０５】
時間810において、ネイバー処理ユニットは、第1のブロックのイントラ予測に使うことができるネイバーピクセルをフェッチし、または場合によっては受信し得る。上述したように、4M+1個のネイバーピクセルが、たとえば、ネイバーバッファから受信され得る。ここで、「1」は、別個のレジスタに記憶してもよい(かつ、タイミング算出のために割り引いて考えてもよい)隅(たとえば、左上隅)ピクセルを表す。ただし、隅ピクセルは、追加または代替として、ネイバーバッファに記憶することができる。バッファからの読取り帯域幅が1サイクルあたり2Nピクセルである場合、ネイバー処理ユニットがネイバーピクセルすべてを読み取るのに、約2M/Nサイクルかかり得る。このアクションは、時間820において完了され得る。
【０１０６】
ネイバーピクセルは、フェッチされた後、イントラ予測処理ユニットの準備のために、パディングされ、フィルタリングされ、かつ/または他のやり方で調整されてよい。これには、一定量のサイクル(たとえば、2つのサイクル)がかかる場合があり、時間830において完了され得る。
【０１０７】
時間830において、イントラ予測処理ユニットは、第1のブロックをイントラ予測し始めることができ、クリティカルな行または列から開始する。M×Mブロック中のクリティカルな行または列はM個のピクセルを有することができ、イントラ予測処理ユニットは、1サイクルあたりN個のピクセルを処理することが可能であり得る。したがって、約M/Nサイクルの後、クリティカルな行または列がイントラ予測され得る。イントラ予測された値は、ネイバーバッファに記憶される再構築ピクセルを作成するために、対応する残差値と加算されてよく、そうすることによって、時間840においてネイバー処理ユニットによって受信される用意が整う。
【０１０８】
時間840において、ネイバー処理ユニットは、第2のブロックのイントラ予測に使うことができる再構築ネイバーピクセルをフェッチし、または場合によっては受信し得る。上述したように、受信されたピクセルのいくつかは、第1のブロックのクリティカルな行または列と一致する場合があり、そうすることによって、ネイバー処理ユニットが第1のブロックについてのネイバーピクセルを準備し、イントラ予測処理ユニットに送った時間830と、ネイバー処理ユニットが第2のブロックについてのネイバーピクセルを受信し始める時間840との間の遅延を引き起こす。
【０１０９】
約2M/Nサイクルにわたって、ネイバー処理ユニットは、第2のブロックをイントラ予測するためのネイバーピクセルの各々を受信することができ、これは時間850において完了され得る。ネイバーピクセルをパディング、フィルタリング、および/または場合によっては調整するための一定量のサイクル(たとえば、2つのサイクル)の後、ネイバー処理ユニットは、イントラ予測処理ユニット向けのピクセルを準備し終えることができる。
【０１１０】
時間860において、イントラ予測処理ユニットは、第1のブロックを処理するのを完了することができ、第2のブロックを処理し始めることができる。言い換えると、ネイバー処理ユニットは、時間860において、第2のブロックについてのネイバーピクセルを用意できているので、第2のブロックは、第1のブロックの直後に処理され得る。いくつかの実施形態では、ネイバー処理ユニットは、時間860に先立って、第2のブロックについてのネイバーピクセルの準備(たとえばパディングおよびフィルタリング)を完了することができる。
【０１１１】
イントラ予測処理ユニットの視点から、第1のブロックは、時間830においてネイバー処理ユニットから受信され、時間860において終わる約M*M/Nサイクル中に処理される。第1のブロックが完全に処理されるとすぐに、イントラ予測処理ユニットは、ネイバー処理ユニットによって準備された、対応する4M+1個のネイバーピクセルを使って、第2のブロックを処理し始めることができる。約M*M/Nサイクルの別の時間期間の後、イントラ予測処理ユニットは、(時間870において)第2のブロックを処理するのを完了し、直ちに、ネイバー処理ユニットによってすでに準備されていてよい、対応する4M+1個のネイバーピクセルを使って第3のブロックを処理し始めることができる。
【０１１２】
ネイバー処理ユニットは、イントラ予測処理ユニットが依然として第1のブロックを処理している(たとえばイントラ予測している)間、第2のブロックについてのネイバーピクセルを処理する(たとえば、バッファから読み取り、パディングし、フィルタリングする)ことができることに気付くことができよう。このようにして、ネイバー処理ユニットは、イントラ予測処理ユニットとパイプライン化(およびインターリーブ)されてよく、これにより、イントラ予測モジュールおよびサブシステムの効率およびスループットが増大し得る。
【０１１３】
しばしば、パイプライン型アーキテクチャでは、定常データが非効率およびより低いスループットにつながり(または、それらを示し)得るので、最小時間期間の間、バッファ中にデータが残るべきである。各ブロックのための処理サイクルは約M*M/Nサイクルであり、したがって、これは、4M(または4M+1)個のネイバーピクセルの各セットがネイバーバッファに記憶され得る平均時間でもあり得ることに気付くことができよう。この、(従来の設計と比較して)短縮された記憶期間は、開示する原理に従って設計されたイントラ予測モジュールおよびサブシステムのために達成可能な増大スループットおよび効率を示す。
【０１１４】
繰り返しになるが、図8に示すアクションまたは期間のうちの任意のものについての正確なサイクル数は、例示にすぎず、処理および他の要因による遅延に依存して変わり得る。
【０１１５】
処理エンジンの数(N)およびネイバーバッファ読取り帯域幅(たとえば、1サイクルあたり2Nピクセル)は両方とも、異なる性能要件に従って変化し得る。下のTable 1(表1)は、開示する原理による様々な構成を示す。
【０１１６】
【表１】
2017535142.tif 000003
【０１１７】
Table 1(表1)に示す値は、28nm技術ノードを使って、400MHzで稼動するハードウェア設計に関して測定され、または場合によっては判断された。技術ノードおよび動作周波数は純粋に例示であり、他の技術ノードおよび/または動作周波数が使われてよい。
【０１１８】
表は、処理エンジン(PE)の数ならびにネイバーバッファ読取り帯域幅(および、たとえば、ネイバーRAM幅)が、より高い性能要件に順応するように増大し得ることを示し、性能要件は、サイクルカウントバジェットとして与えられる。たとえば、構成1は、たとえば、超高精細(UHD)解像度(3,840かける2,160ピクセル以上)を有するビデオを符号化および/または復号するように設計されたハイエンドコーディングデバイスにおいて選択され得る。構成2および3は中間レベルデバイス(たとえば、1080p)向けであってよく、構成4はローエンドデバイス(たとえば、720p)向けであってよい。
【０１１９】
開示する原理による様々な実施形態について記載したが、それらは単なる例として与えられたものにすぎず、限定的ではないことを理解されたい。したがって、本開示の広さおよび範囲は、上で記載した例示的な実施形態のいずれによっても限定されるべきではなく、本開示から発行される請求項およびそれらの等価物に従ってのみ定義されるべきである。さらに、上記利点および特徴は、記載する実施形態において与えられるが、上記利点のいずれかまたはすべてを遂行するプロセスおよび構造への、そのような発行請求項の適用を限定するものではない。
【０１２０】
本開示において使われる様々な用語は、本技術分野内での特殊な意味を有する。特定の用語が、そのような「専門用語」として解釈されるべきかどうかは、その用語が使われる文脈に依存する。「〜に接続された」、「〜と通信する」、「〜に関連付けられた」、または他の同様の用語は概して、通信および接続が、言及される要素の間で直接的であるか、または言及される要素の間で1つもしくは複数の媒介物を通す、両方の状況を含むように広く解釈されるべきである。これらおよび他の用語は、本開示において使われる文脈に照らして、および当業者がそれらの用語を、開示する文脈において理解するであろうように解釈されるべきである。上記定義は、開示する文脈に基づいてそれらの用語に授けられ得る他の意味を排除するものではない。
【０１２１】
「その時点で」、「直ちに」、「等価な」、「〜の間」、「完了した」、「同一の」などのような、比較、測定、およびタイミングの言葉は、「実質的にその時点で」、「実質的に直ちに」、「実質的に等価な」、「実質的に〜の間」、「実質的に完了した」、「実質的に同一の」などを意味するように理解されるべきであり、ここで「実質的に」は、そのような比較、測定、およびタイミングが、暗黙的または明確に述べられる所望の結果を遂行するのに実際的であることを意味する。
【０１２２】
「ブロック」という用語が使われる場合、この用語は、それが使われる文脈に依存して、最大コーディングユニット(LCU)、コーディングツリーブロック(CTB)、コーディングユニット(CU)、コーディングブロック(CB)、予測ユニット(PU)、予測ブロック(PB)、変換ユニット(TU)、変換ブロック(TB)、H.264/AVCによって定義されるサブブロック、および/または同様のデータ構造のうちのいずれをも指し得る。
【０１２３】
HEVCに関して様々な主題を記載しているが、本主題は、現時点で存在するもの、開発中のもの、およびこれから開発されるものを含む、他の規格にも適用可能であり得る。たとえば、「CU」および「CB」という用語が使われる場合、それらは、使われる文脈に依存して、H.264/AVC規格によって定義されるマクロブロックおよび/または他の符号化規格の同様のデータ構造も指し得る。同様に、「TU」および「TB」という用語が使われる場合、それらは、使われる文脈に依存して、H.264/AVC規格によって定義されるサブブロックおよび/または他の符号化規格の同様のデータ構造も指し得る。
【０１２４】
さらに、「ピクセル」という用語が使われる場合、ビデオフレームまたは画像内の、ルーマ値、クロマ値、またはクロマおよびルーマ値の組合せを指し得る。
【０１２５】
開示する原理は概して、波面並列処理(WPP)、ビデオスライス、およびビデオタイルを含む、並列性を達成するための多数の他の技法と両立可能である。
【０１２６】
さらに、本明細書におけるセクション表題は、37 C.F.R. 1.77の下での提案との一貫性のために、または場合によっては編成上の目印を与えるために与えられている。これらの表題は、本開示から発行され得るいずれかの請求項において説明される主題を限定するものでも、特徴付けるものでもない。具体的に、および例として、表題は「技術分野」を指すが、そのような請求項は、いわゆる技術分野を記載するために本表題の下で選ばれた文言によって限定されるべきでない。さらに、「背景技術」における技術の記述は、技術が、本開示における任意の主題に対する従来技術であるという容認として解釈されるべきでない。「発明の概要」も、発行された請求項において説明される主題の特徴付けと見なされるべきでない。さらに、本開示における、単数形での「発明」へのいかなる参照も、本開示には単一の新規な点しかないことを論じるのに使われるべきでない。本開示から発行される複数の請求項の限定に従って、複数の発明が説明されてよく、そのような請求項はそれに従って、そうすることによって保護される本発明、およびそれらの等価物を定義する。すべての事例において、そのような請求項の範囲は、本開示を鑑み、それら自体の利点において検討されるものとするが、本明細書において説明される表題によって制約されるべきでない。
【符号の説明】
【０１２７】
10  ビデオ符号化および復号システム、システム
12  ソースデバイス、デバイス
14  宛先デバイス、デバイス
16  通信チャネル、チャネル
18  ビデオソース
20  ビデオエンコーダ
22  変調器/復調器(モデム)
24  送信機
26  受信機
28  モデム
30  ビデオデコーダ
32  ディスプレイデバイス
34  記憶媒体
36  ファイルサーバ
40  モード選択モジュール
42  動き推定モジュール
44  動き補償モジュール
46  イントラ予測モジュール
50  加算器
52  変換モジュール
54  量子化モジュール
56  エントロピー符号化モジュール
58  逆量子化モジュール、モジュール
60  逆変換モジュール、モジュール
62  加算器
64  参照フレームバッファ
70  エントロピー復号モジュール
72  動き補償モジュール
74  イントラ予測モジュール
76  逆量子化モジュール
78  逆変換モジュール
80  加算器
82  参照フレームバッファ
600  イントラ予測サブシステム、サブシステム
610  イントラ予測モジュール
612  ネイバーバッファ
613  ネイバーRAM、RAM
614  ネイバー処理ユニット
616  イントラ予測処理ユニット
617  処理エンジン、PE
620  逆変換モジュール
630  参照フレームバッファ
640  加算器
【図１】
2017535142.tif 000004
【図２】
2017535142.tif 000005
【図３】
2017535142.tif 000006
【図４】
2017535142.tif 000007
【図５】
2017535142.tif 000008
【図６】
2017535142.tif 000009
【図７】
2017535142.tif 000010
【図８】
2017535142.tif 000011
【手続補正書】
【提出日】平成29年4月4日(2017.4.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
イントラ予測を実施する方法であって、
ネイバー処理ユニットにおいて、第1のブロックの第1の複数の隣接ピクセルを受信するステップと、
前記ネイバー処理ユニットによって、イントラ予測処理ユニットによるイントラ予測のための前記第1の複数の隣接ピクセルを準備するステップと、
前記イントラ予測処理ユニットによって、前記準備された第1の複数の隣接ピクセルを受信するステップと、
前記イントラ予測処理ユニットによって、第1の時間期間中に、前記準備された第1の複数の隣接ピクセルを使って、第1の複数のイントラ予測されたピクセルを有する前記第1のブロックの値を判断するステップと、
前記ネイバー処理ユニットによって、前記第1の時間期間の少なくとも一部の間に第2のブロックの第2の複数の隣接ピクセルを受信するステップであって、前記第2の複数の隣接ピクセルは、前記第1のブロック中の、前記第1の複数のイントラ予測されたピクセルの第1の部分を含む、ステップと、
前記第2の複数の隣接ピクセルが、前記第1のブロック中の前記第1の複数のイントラ予測されたピクセルの前記第1の部分とは別個の、前記第1のブロック中の前記第1の複数のイントラ予測されたピクセルの残りの部分の前記判断と並行して準備されるように、前記ネイバー処理ユニットによって、前記第1の時間期間の少なくとも一部の間にイントラ予測のための前記第2の複数の隣接ピクセルを準備するステップと、
前記イントラ予測処理ユニットによって、前記第1の時間期間の直後の第2の時間期間中に、前記準備された第2の複数の隣接ピクセルを使って、第2の複数のイントラ予測されたピクセルを有する前記第2のブロックの値を判断するステップとを含む方法。
【請求項２】
前記第2の時間期間は、実質的に前記第1の時間期間の直後である、請求項1に記載の方法。
【請求項３】
前記第1の複数の隣接ピクセルの前記準備は、前記第1の複数の隣接ピクセルをパディングし、フィルタリングすることを含む、請求項1に記載の方法。
【請求項４】
前記第1および第2のブロックは、両方とも共通イントラ予測モードに関連付けられた変換ブロックである、請求項1に記載の方法。
【請求項５】
前記イントラ予測処理ユニットはN個の処理エンジンを備え、各処理エンジンは、前記第1の時間期間の各サイクル中に異なるピクセルをイントラ予測する、請求項1に記載の方法。
【請求項６】
前記第1のブロックは、MピクセルかけるMピクセルのサイズを有し、前記イントラ予測処理ユニットが前記第1のブロックを判断する前記第1の時間期間は、約M*M/Nサイクルだけ続く、請求項5に記載の方法。
【請求項７】
前記第2の複数の隣接ピクセルの前記準備は、前記第1のブロック中の前記第1の複数のイントラ予測されたピクセルの前記第1の部分の値の前記判断が終了されてから約2M/Nサイクル後に始まる、請求項6に記載の方法。
【請求項８】
前記ネイバー処理ユニットは、1サイクルあたり2Nピクセルの読取り帯域幅を有するネイバーバッファから、前記第1および第2の複数の隣接ピクセルを受信する、請求項5に記載の方法。
【請求項９】
前記第1の複数の隣接ピクセルは4M+1個のピクセルを含む、請求項6に記載の方法。
【請求項１０】
前記第1のブロックの前記判断は、前記第1のブロックの残りを判断する前に、イントラ予測されたピクセルのクリティカルな行または列を判断することを含み、前記第2のブロックを判断するのに使われる前記第2の複数の隣接ピクセルは、イントラ予測されたピクセルの前記クリティカルな行または列を含む、請求項1に記載の方法。
【請求項１１】
イントラ予測を実施するためのプロセッサであって、
イントラ予測のための第1のブロックの第1の複数の隣接ピクセルおよび第2のブロックの第2の複数の隣接ピクセルを受信し、準備するように動作可能なネイバー処理ユニットと、
第1の時間期間中に、前記準備された第1の複数の隣接ピクセルを使って、第1の複数のイントラ予測されたピクセルを有する前記第1のブロックを判断するように動作可能なイントラ予測処理ユニットであって、第2の時間期間中に、前記準備された第2の複数の隣接ピクセルを使って、第2の複数のイントラ予測されたピクセルを有する前記第2のブロックを判断するようにさらに動作可能な、イントラ予測処理ユニットとを備え、
前記ネイバー処理ユニットは、前記第1の時間期間の少なくとも一部の間に前記第2の複数の隣接ピクセルを受信するようにさらに動作可能であり、前記第2の複数の隣接ピクセルは、前記第1のブロック中の、前記第1の複数のイントラ予測されたピクセルの第1の部分を含み、
前記ネイバー処理ユニットは、前記第2の複数の隣接ピクセルが、前記第1のブロック中の前記第1の複数のイントラ予測されたピクセルの前記第1の部分とは別個の、前記第1のブロック中の前記第1の複数のイントラ予測されたピクセルの残りの部分の前記判断と並行して準備されるように、前記第1の時間期間の少なくとも一部の間に、前記第2の複数の隣接ピクセルを準備するようにさらに動作可能である、プロセッサ。
【請求項１２】
前記第2の時間期間は、実質的に前記第1の時間期間の直後である、請求項11に記載のプロセッサ。
【請求項１３】
前記ネイバー処理ユニットは、前記第1の複数の隣接ピクセルをパディングし、フィルタリングするようにさらに動作可能である、請求項11に記載のプロセッサ。
【請求項１４】
前記第1および第2のブロックは、両方とも共通イントラ予測モードに関連付けられた変換ブロックである、請求項11に記載のプロセッサ。
【請求項１５】
前記イントラ予測処理ユニットはN個の処理エンジンを備え、各処理エンジンは、前記第1の時間期間の各サイクル中に異なるピクセルをイントラ予測するように動作可能である、請求項11に記載のプロセッサ。
【請求項１６】
前記第1のブロックは、MピクセルかけるMピクセルのサイズを有し、前記第1の時間期間は、約M*M/Nサイクルだけ続く、請求項15に記載のプロセッサ。
【請求項１７】
前記ネイバー処理ユニットは、前記イントラ予測処理ユニットが前記第1のブロック中の前記第1の複数のイントラ予測されたピクセルの前記第1の部分の値を判断し終えてから約2M/Nサイクル後に、前記第2の複数の隣接ピクセルを準備し始めるように動作可能である、請求項16に記載のプロセッサ。
【請求項１８】
前記第1および第2の複数の隣接ピクセルを記憶するように動作可能なネイバーバッファをさらに備え、前記ネイバーバッファは、1サイクルあたり2Nピクセルの読取り帯域幅を有する、請求項15に記載のプロセッサ。
【請求項１９】
前記第1の複数の隣接ピクセルは4M+1個のピクセルを含む、請求項16に記載のプロセッサ。
【請求項２０】
前記イントラ予測処理ユニットは、前記第1のブロックの残りを判断する前に、前記第1のブロック中のイントラ予測されたピクセルのクリティカルな行または列を判断するようにさらに動作可能であり、前記第2のブロックを判断するのに使われる前記第2の複数の隣接ピクセルは、イントラ予測されたピクセルの前記クリティカルな行または列を含む、請求項11に記載のプロセッサ。
【請求項２１】
ビデオデコーダであって、
イントラ予測を実施するように動作可能なイントラ予測モジュールであって、
イントラ予測のための第1のブロックの第1の複数の隣接ピクセルおよび第2のブロックの第2の複数の隣接ピクセルを受信し、準備するように動作可能なネイバー処理ユニットと、
第1の時間期間中に、前記準備された第1の複数の隣接ピクセルを使って、第1の複数のイントラ予測されたピクセルを有する前記第1のブロックを判断するように動作可能なイントラ予測処理ユニットであって、第2の時間期間中に、前記準備された第2の複数の隣接ピクセルを使って、第2の複数のイントラ予測されたピクセルを有する前記第2のブロックを判断するようにさらに動作可能である、イントラ予測処理ユニットとを備え、
前記ネイバー処理ユニットは、前記第1の時間期間の少なくとも一部の間に前記第2の複数の隣接ピクセルを受信するようにさらに動作可能であり、前記第2の複数の隣接ピクセルは、前記第1のブロック中の前記第1の複数のイントラ予測されたピクセルの第1の部分を含み、前記ネイバー処理ユニットは、前記第2の複数の隣接ピクセルが、前記第1のブロック中の前記第1の複数のイントラ予測されたピクセルの前記第1の部分とは別個の、前記第1のブロック中の前記第1の複数のイントラ予測されたピクセルの残りの部分の前記判断と並行して準備されるように、前記第1の時間期間の少なくとも一部の間に前記第2の複数の隣接ピクセルを準備するようにさらに動作可能である、イントラ予測モジュールと、
第1の残差ブロックおよび第2の残差ブロックを与えるように動作可能な逆変換モジュールと、
第1の再構築ブロックを判断するために、前記第1のブロックを前記第1の残差ブロックと加えるように動作可能な加算器であって、第2の再構築ブロックを判断するために、前記第2のブロックを前記第2の残差ブロックと加えるようにさらに動作可能である、加算器とを備え、
前記第2のブロックを判断するために使われる前記第2の複数の隣接ピクセルは前記第1の再構築ブロックを含む、ビデオデコーダ。
【請求項２２】
前記第1および第2の再構築ブロックを、参照フレームの部分として記憶するように動作可能な参照フレームバッファをさらに備え、
前記参照フレームは、後に続く動き補償、イントラ予測、およびプレゼンテーションデバイスにおける表示のうちの少なくとも1つのために使われ得る、請求項21に記載のビデオデコーダ。
【請求項２３】
前記イントラ予測処理ユニットはN個の処理エンジンを備え、各処理エンジンは、前記第1の時間期間の各サイクル中に異なるピクセルをイントラ予測するように動作可能である、請求項21に記載のビデオデコーダ。
【請求項２４】
前記第1のブロックは、MピクセルかけるMピクセルのサイズを有し、前記第1の時間期間は、約M*M/Nサイクルだけ続く、請求項23に記載のビデオデコーダ。
【請求項２５】
前記第1および第2の複数の隣接ピクセルを記憶するように動作可能なネイバーバッファをさらに備え、前記ネイバーバッファは、1サイクルあたり2Nピクセルの読取り帯域幅を有する、請求項23に記載のビデオデコーダ。
【請求項２６】
前記ネイバーバッファは、16NのRAM幅を有するネイバーRAMを備える、請求項23に記載のビデオデコーダ。
【請求項２７】
前記第1の複数の隣接ピクセルは4M+1個のピクセルを含む、請求項24に記載のビデオデコーダ。
【請求項２８】
前記イントラ予測処理ユニットは、前記第1のブロックの残りを判断する前に、前記第1のブロック中のイントラ予測されたピクセルのクリティカルな行または列を判断するようにさらに動作可能であり、前記第2のブロックを判断するのに使われる前記第2の複数の隣接ピクセルは、イントラ予測されたピクセルの前記クリティカルな行または列を含む、請求項21に記載のビデオデコーダ。
【請求項２９】
前記逆変換モジュールは、前記クリティカルな行または列に対応する残差値を生成するようにさらに動作可能である、請求項28に記載のビデオデコーダ。
【請求項３０】
前記加算器は、前記第2の複数の隣接ピクセルの少なくともいくつかを生成するために、前記クリティカルな行または列を、前記対応する残差値と加えるようにさらに動作可能である、請求項29に記載のビデオデコーダ。
【国際調査報告】
2017535142.tif 000012
2017535142.tif 000013
2017535142.tif 000014