2008年11月17日

KTAソフトウェアに関して

修正して、再喝。 こっそり覗かせていただいているタンタン的思考さんがKTAについて記事にしていたので私も一言。Beyond H.264 (H.265に取り込まれるかもしれない)の技術が盛り込まれているKTAソフトウェア、核の部分はJMで作ってあって(だからコードが汚い)、ほとんどJMと同じ感覚で使える。今回はその次世代符号化の要素技術候補で符号化効率の改善に大きく寄与している、「適応予測誤差符号化(APEC)」について述べたいと思う。 この技術は、他の技術に比べてかなりインパクトがある。手元の資料だと低解像度(低ビットレート)では平均して8%くらい、高解像度(高ビットレート)では平均して3%くらい符号化効率の改善が見られる。効果もインパクトがあるのだが、もっとインパクトがあるのはそのシンプルなアルゴリズム。具体的にどういったことをやっているかというと、今までイントラ/動き補償予測をした後にDCT・量子化(周波数領域符号化)をしていたのをそのまま量子化するモード(空間領域符号化)も追加してブロック毎に切り替える、というものだ。また、空間領域符号化では係数のスキャン順をジグザグじゃなくてLine by line scanというものを使っている。これはその行の最後までスキャンしたら次の行の先頭に戻るという、いわゆる順次スキャンである。 この方法で効果があるというのは、DCT(DCT-II)は1次AR過程でモデル化される自然画像に対して準最適な変換であるから、1次AR過程でモデル化できなそうな予測誤差に対してDCTをやっても効果が薄いということをあらわしている結果だと思う。これをやると結構な数のマクロブロックで空間領域符号化が選択される。エンコーダはモードが増えてモードを選択する手間が増えるが、デコーダ側ではDCTをやらなくなるから演算量も削減できて個人的にとても期待している技術だ。他の予測関連の技術の性能が向上したら将来は、基本は空間領域符号化で、予測でとりきれない相関があるマクロブロックだけ周波数領域符号化というアルゴリズムもあり得る。 「予測誤差に対してDCTは効果があるのか」という問題に関しては私自身も前から思っていたのだが、そこから「予測誤差に対して最適な変換はないのか」ばかり考えていて、「予測誤差をそのまま量子化する」という発想には至らなかった。なのでこの技術を見つけたときはすごい悔しかった。最近の情報では、NHK研究所が今までのDCT、検討中のAPECに替えて、DCT/DSTを提案しているようだ。しかし、復号側の処理が軽くなるAPECがやはり個人的には好きなので、H.265では是非採用して欲しい。
ラベル: 0 コメント

2008年9月18日

H.264 CAVLC

日本語の記事をあまり見かけないのでちょっと解説しておく。H.264/AVCといえばCABAC(コンテクスト適応算術符号化)が注目されがちだが、CAVLC(コンテクスト適応可変長符号化)もMPEG-1/2/4など今までの可変長符号(VLC)と大きく異なる。 MPEG-1/2はJPEGの可変長符号とほとんど同じで、DC係数は係数の値から決定するVLC、AC係数はゼロランと非ゼロの係数から決定する2次元VLCを用いている。MPEG-4ではそこに最後の非ゼロの係数かどうかも加えて3次元VLCとするらしいのだが、詳しく勉強していないのでよくわからない。H.264/AVCのCAVLCなのだが、実際に"コンテクスト適応"となっているのは最初の符号だけで中身はもっと複雑だ。以下にCAVLCの処理の概要を示す。


  1.  「ジグザグスキャン順で最後に続く絶対値が1の係数の数」、「非ゼロの係数の数」、「左と上の4x4ブロックの非ゼロの係数の数の平均(nC)」のコンテクスト適応VLC(3次元VLC)。各コンテクスト毎に「ジグザグスキャン順で最後に続く絶対値1の係数の数(trailing_ones)」と「非ゼロの係数の数(total_coeff)」の2次元VLCを符号化する。ここでいうコンテクストというのは「左と上の4x4ブロックの非ゼロの係数の数の平均(nC)」のことで、上の2次元にこのコンテクストを加えて3次元VLCと見ることもできる。 
  2. 「最後に続く絶対値が1の係数」の符号。「(スキャン順で)最後に続く絶対値が1の係数の符号」を符号化する。CAVLCにおける「最後に続く絶対値が1の係数」の数の最大値は3であるから、ここでは0～3bit書き込まれることになる。この連続する1の数が4以上のときはまだ検証していないのでここでは言及しない。
  3. 「係数のレベル」をプレフィックスとサフィックスに分けて符号化。「最後に続く絶対値1の係数の符号」を書き込んだ後にようやく係数のレベルを符号化する。係数のレベルの符号化は、負の値を奇数、正の値を偶数に変換してすべて非負の値にした後にプレフィックスとサフィックスに分けて符号化する。サフィックスの長さは「非ゼロの係数の数(total_coef)」と「ジグザグスキャン順で最後に続く絶対値1の係数の数(trailing_ones)」から初期値を求め、符号化対象係数ごとに算出する。最大値は6である。サフィックスの長さがわかれば非負値にした係数をその長さ分だけ右シフトすればプレフィックスも求めることができる。プレフィックスはユーナリー符号、サフィックスはそのままのビットが符号化される。
  4.  「非ゼロの係数の数」と「ゼロの係数の数」の2次元VLC 
  5. 「符号化対象の係数の前のすべての非ゼロの係数の数」と「符号化対象の係数の前に続くゼロラン」の2次元VLC。この符号は「非ゼロの係数の数(total_coef)」だけある。 


このように、今までのVLCと違ってH.264/AVCではかなり工夫がされている。ここでは、CAVLCということで、予測誤差をDCTと量子化した後の係数の符号化方法のみを示した。ブロックタイプ、予測モード/MV、デルタQP、CBPなどのブロックのパラメータの符号化は指数ゴロム符号化などがおこなわれる。効率がかなり良くなるCABACの陰に隠れがちだが、CABACの方は1ビット符号化(復号)毎に数回の演算が必要だから、演算速度は現在ではそれほど差が出ないかもしれないが、消費電力は結構差が出るかもしれない。ということで、ビットレートと画質が十分に出せれば、消費電力の観点からCABACオフにしてもいいかもしれない。 

CABACはブロックのパラメータをVLCにして係数もすべて0/1にして、各ビットをコンテクストに振り分けて、算術符号化(Range Coder)する。コンテクストはHigh Profileで460個もある。VLCと違って算術符号化はエントロピー(理論限界)に到達するし、符号化/復号で処理が対象的になるのが個人的に好きなのだが、H.264/AVCのコンテクストは多いように思う。コンテクストモデリングはOn2(WebM)のVP8がもう少しすっきりしているのかもしれない。まだ調査していないけど。また次世代では、処理速度が算術符号化に比較して符号化で3～5倍、復号で少なくとも2倍で、エントロピーの点でも算術符号化に迫る性能で、並列化にも適応できるV2V Codeなんてのも検討されているらしい。2値化とコンテクストモデリングはCABACと共通で2値算術符号化の部分だけ置き換える技術らしいがアルゴリズムの詳細はよくわからない。
ラベル: 0 コメント

2008年7月28日

iPhoneのカメラの画質

前の記事でiPhoneのカメラの解像度は1600x1200サイズ固定で設定の変更はできないと書きましたが, では中身でどのくらいの画質=量子化ステップサイズを設定しているのか気になったので調べてみました.

JPEGに関しては色々解析ソフトがありますが, Mac用の調べてインストールするのが面倒だったのでストリームを調べてコンソールに表示する簡単なものを作成. iPhoneで撮ったJPEGファイルにはJFIF(APP0マーカ)とEXIF(APP1マーカ)が入っていました. JFIFは当然か. EXIFも地理情報入れるからあるんでしょうね. EXIFの詳しい解析は面倒だったのですっ飛ばしてDQTマーカまで読み込み. まず, 輝度成分は以下のような量子化テーブルが入っていました. 

42333243
334444610
665561289
710141215151412
1413161823191617
2117131420272021
2324252625151928
3028253023252524
そして, 色差成分は以下のような量子化テーブルでした. 
444656116
611241614162424
2424242424242424
2424242424242424
2424242424242424
2424242424242424
2424242424242424
2424242424242424
JPEGで標準的に使われる量子化テーブルと比較してみると, 全体の量子化ステップサイズが1/4くらいずつ小さくなっています. 輝度成分のDC係数に限って言うと, 16が4に, つまり4bit(16段階)の量子化インデックスが6bit(64段階)の量子化インデックスに増えている(=量子化誤差が減る)ということになります. 

それで実際にどれだけ画質があがっているのかJPEGで標準的に使われている量子化テーブルと比較してみました. 使った画像は符号化でよく使われる標準画像Lenaです. DCT, 量子化, 逆量子化, 逆DCTを行い, PSNR(S/N比)を比較してみました. iPhoneの量子化テーブルが37.0553[dB], JPEGデファクト標準の量子化テーブルが30.2958[dB]. 結構いいですね. 

あと, その他の画像でもPSNRを見てみました. 

画像PSNR[dB]
lena37.0553
Peppers38.5674
Baboon34.6758
Sailbaot35.7387
Tiffany36.5317
平均すると37[dB]くらい. PSNR自体はMATLABのimwriteコマンド(というかlibjpeg)のQuarityで70を設定するのと同じくらいですが, 量子化ステップそれ自体はQuarityを90(PSNRにすると約40[dB])設定した物と同じくらいです. まだ, 可変長符号は調べていないので圧縮率の比較していないのですが, 量子化テーブルを見た感じじゃあんまり大したことなさそう. JPEGはそんなに詳しくないのでもっと専門家の意見を聞きたいですね. 

ラベル: 0 コメント

2008年4月16日

AVCHDとMPEG-2 TS

AVCHDがなぜ多重化にMPEG-2 TSを使っているのか疑問に思っていたのですが, 最近Blue-rayも多重化にMPEG-2 TSを使っているらしいことを知り, そのせいかなと思っています. ちゃんとBlue-rayの規格書等を読んだわけじゃないんで信憑性に欠けますが, まぁたぶんそういうことでしょう. というかBlue-rayもなぜ多重化にMPEG-2 TSを使ってるのでしょうか. メディア媒体に入ってるんだからMP4でいいじゃん, とか思ったのは僕だけじゃないと思います. ちなみにMPEG-2 TSのパケットサイズは188バイト固定. そのうちオプションをつけないとヘッダは4バイト. つまり, ビットストリーム184バイト(1472ビット)毎に4バイトのヘッダがつくってことですね. なんか無駄な感じがします. メディアに焼いて保管するときはMP4に変換して保存すれば結構容量を削れるかもしれませんね.
ラベル: 0 コメント