HEVC Complexity and Implementation Analysis日本語訳
HEVCの複雑さ(計算量)と実装の分析
アブストラクト - 映像圧縮技術の発展は、ソフトウェアとハードウェアで利用できる処理能力の絶え間ない増加によって動かされてきた。新しいHEVC映像符号化の標準は、H.264/AVCのハイプロファイルに比較して符号化効率で2倍にすること、同じ映像品質を半分のビットレートで送信することを目指す。この論文では、標準化の過程で考えられた複雑さに関連した側面を述べる。さらに参照ソフトウェアのプロファイリングと最適化されたソフトウェアは、HEVCがその前の規格よりも複雑であるかもしれない、そして単純であるかもしれないという指標を与える。全体としてHEVCデコーダの複雑さは、H.264/AVCデコーダの複雑さと明らかに異なるということはなく、現在のハードウェア上でソフトウェアでHEVCデコードを行うことをとても現実的にする。HEVCエンコーダは、H.264/AVCエンコーダよりも数倍複雑であると予期され、将来数年での研究の主題である。
この論文は、新しいHEVC標準における複雑さと実装の問題の概略を与える。HEVCプロジェクトは、Joint Collaborate Team on Video Coding (JCT-VC)により運営され、ITU-TとISO/IECの共同の労作である。HEVCテストモデル (HM)と呼ばれる参照ソフトウェアは、ドラフトの標準とともに開発されている。これを書いている時点では、HMの現バージョンは、8.0であり、これはHEVCテキスト仕様ドラフト 8に対応する [1]。読者は、ドラフトのHEVC標準に関してある程度の知識があると仮定しており、その概略は [2]で見つけられる。
複雑さの評価は、それ自身複雑な話題であり、この論文の1つの目的は、複雑さの概念が考慮されたHEVC設計のいくつかの見方を注目することである。これは節IIの話題である。
この論文の2つめの目的は、現在のHEVCのソフトウェア実装のプロファイリングの結果のデータを提供し、議論することである。節IIIとIVは、HMエンコーダとデコーダで得られた結果を示す。節Vは、デコーダの最適化された実装を議論する。
HEVCは、H.264/AVC [3]のような以前の映像符号化標準の基本的なハイブリッド符号化の体系を保持する。重要な違いは、マクロブロックの代わりに符号化木単位 (CTU)に基づく、より適応的な四分木の利用である。原理的には、四分木の符号化構造は、「ブロック」と「単位(ユニット)」により述べられる。ブロックは、標本の配列とそれのサイズを定義し、一方、単位(ユニット)は一つの輝度と対応する色差のブロックをこれらを符号化するために必要なシンタックスと一緒にカプセル化する。その結果、CTUは、符号化木ブロック (CTB)と符号化データとさらなる区分を指定するシンタックスを含む。この区分は、符号化ブロック (CB)を持つ符号化単位 (CU)葉に帰着する。それぞれのCUは、予測の目的のためにいわゆる予測単位 (PU)と予測の目的のためにいわゆる予測単位 (PU)と変換のためのいわゆる変換単位 (TU)のエンティティを含む。同様に、それぞれのCBは予測ブロック (PB)と変換ブロック (TB)へ分割される。この可変サイズ、適応的アプローチは、いくつかのHEVCアプリケーションに対するターゲット解像度である4k2kのようなより大きな解像度へ特に適している。典型的なCBとTBの四分木構造は、図1で与えられる。CBをどのようにPBへ分割するかを述べる分割モード全ては、図2で表現される。四分木はz-scan順に利用することで深さ優先の方法で簡単に横断することができるために、四分木構造のデコード処理は、追加負荷の多くではない。インター符号化のCUに対する分割モードは、非正方形PUを特色とする。これら非正方形サポートは、デコーダへz-scanとラスタースキャン順の間の複数の変換という、追加のロジックを要求する。エンコーダ側では、レート歪みの観点で最適分割を推定する単純な枝刈りアルゴリズムが存在する [4], [5]。
この節の以下では、HEVCの様々なツールを解説し、HEVCの仕様の開発で考えてきた複雑さの面をレビューする(適切な個所ではH.264/AVCを参照として利用する)。
HEVCのイントラ予測は、H.264/AVCにかなり似ている。サンプルは隣接ブロックの再構成サンプルから予測される。命名法はプラナー(平面的)とアンギュラー(角度的)と多少変化したが(H.264/AVCのプレーンとディレクショナルモードにそれぞれ対応する)、モードの分類は、同一のままである: DC、平面、水平/垂直; 大きな変更点は、より大きなブロックサイズの導入からきており、35モードの1つを使うイントラ予測は、32x32サンプルまでのサイズのブロックへ行われるかもしれない。最小のブロックサイズは、4x4でH.264/AVCから変化せず、イントラ予測の逐次的な性質のために依然として複雑さのボトルネックは残る。
HEVCでは、DC、水平と垂直モードに対して、追加の後処理が定義され、その場所で行および/または列が境界にわたり連続性を保つためにフィルタリングされる。これら3つのモードはそもそももっとも単純であるために、この追加は、最悪の場合の計算量にインパクトを持つとは予期されない。
プラナーモードの場合では、予測のサンプル値を簡単に増加的に計算することが可能であるため、生成する式を考えるのは、複雑さを決定するのにはおそらく適切ではない。H.264/AVCのプレーンモードに対しては、1回の16ビット加算、1回の16ビットシフト、1回の8ビット範囲へのクリップがサンプル毎に要求される。HEVCのプラナーモードに対しては、これは3回の16ビット加算と1階の16ビットシフトになる。したがいこれら2つのモードは同様の計算量を持つと予期される。
HEVCのアンギュラーモードは、乗算が必要とされるため、H.264/AVCのディレクショナルモードよりも複雑である。それぞれの予測のサンプルは、((32 - w) * x_{i} + w * x_{i+1} + 16) >> 5として計算され、ここでx_{i}は参照のサンプル、wは重み係数である。予測の行もしくは列にわたり重み係数は、SIMD実装を容易にするよう一定値が保たれる。単一の関数が、33予測方向のすべてをカバーするために使うことが可能であり、したがってこの機能を実装するために必要なコードは削減される。
H.264/AVCのように、参照サンプルは、予測の前に平滑化することができる。予測モードによってより選択的に適用できるが、その平滑化処理は同じものである。
エンコードの観点から、予測モードの数の増加 (HEVCで35に対し、H.264/AVCで9)は、合理的な検索の計算量を保つ良いモード選択のヒューリスティクスが必要となるだろう。
HEVCでのインター予測、もしくは動き補償は、概念上はとても単純であるが、H.264/AVCと比較してある程度のオーバーヘッドを伴う。輝度小数画素のための分離型の8タップフィルタの利用は、メモリバンド幅の増加と動き補償に必要な積和演算の数の増加をもたらす。フィルタ係数は、ハードウェアコストを最小化するために7ビットの符号付き数の範囲に制限される。ソフトウェアではNxNブロックの動き補償は、画素毎に8+56/N回の8ビット積和演算と画素毎に8回の16ビット積和演算からなる。色差の少数画素位置の対しては、輝度のフィルタ係数に対するものと同じ制約を持つ分離型の4タップフィルタが適用される。これは、色差少数画素位置に対してバイリニア補間が使われるH.264/AVCに比較して、メモリバンド幅と演算数を増加させる。
実装コストが高くなる別の領域は、特に双予測での、中間記憶バッファである。実際、H.264/AVCでは1個の8ビットのバッファと1個の16ビットバッファが必要とされる量であるのに対して、2個の16ビットバッファがデータを保持するために必要とされる。HEVCの実装では、これらのバッファは、必ずしも最大64x64 PBサイズを反映するように増加させる必要はない。大きいブロックの動き補償は、メモリ要求および演算の数との間の所望のトレードオフを達成する小さなブロックへ分解され、処理することができる。
以下翻訳中・・・
