GOP関連をおろそかにしたx264はXvidにも劣る。　ageha was here

2007/11/15を以て当ブログは更新を停止しました。記事は全てこのままですが、基本的に内容はOut of dateとお考え下さい。

ホーム > ごみ箱　-x264encopts > GOP関連をおろそかにしたx264はXvidにも劣る。

GOP関連をおろそかにしたx264はXvidにも劣る。

１. Iが多いほど空間軸画質が良い。しかし、Iは巨大だ。

x264 [info]: slice I:  490 Avg QP:19.21 size: 24682 PSNR Mean Y:47.78 U:49.86 V:51.00 Avg:48.38 Global:47.57
x264 [info]: slice P:15350 Avg QP:21.01 size:  8706 PSNR Mean Y:45.88 U:48.60 V:49.90 Avg:46.69 Global:45.88
x264 [info]: slice B:18195 Avg QP:21.47 size:  1979 PSNR Mean Y:45.94 U:48.79 V:50.08 Avg:46.77 Global:45.96

ピンクが枚数。黄色がデータサイズ。枚数では1.4%に過ぎないI/IDRだが、平均サイズはむちゃむちゃデカイ。そう！アイは惜しみなく奪うのだ！（どーん）。

　もしこれで画質に不満がある場合、P/B関連のオプションでちまちま悩むより、無駄なI/IDRの存在を疑うほうが手っ取り早い。そのぶん浮いたbit をP/Bに回せば全体的な画質向上が期待できる。画質が充分ならP/B関連の重たいオプションを切って速度を取るなり、bitrateを下げるなり、いろいろと戦術の幅が広がる。

　空間軸画質向上の第一歩は不必要なI/IDRの排除。そう！アイはあり過ぎても問題なのだ！（いろいろとね！）。

２. GOP関連をおろそかにしたx264はXvidにも劣る。

シーンチェンジの最初はIDR、少なくともIフレームである事が望ましい。
　I/IDRが正しく場面転換の位置に入っていないと、後続のP/Bフレームが "全然別の場面との差分" で構成されてしまう。このようなP/Bフレームは、正しい位置に置かれたI/IDRを参照するP/Bより画質が悪い。そのくせ、サイズはIフレーム並みにデカイ。のみならず、巨大サイズのP/Bには x264のbitrate制御機能が容赦なく適用QP値を上げるので画質は一層悪化する。それをまた後続のP/Bが参照するものだから…、という具合に画質劣化は時間軸に沿って連鎖的に波及してゆく。さらにその影響はマルチプル・レファレンス（frameref / -r, --ref / refs）の効果で結構遠くまで及び、さらにさらにskip/directマクロブロックにより意外な箇所にまで波及しさらにさらにさらに b_pyramid でBを参照化してた日には、、、てな感じの連鎖反応がGOPリセット（IDR最小間隔）まで続く。被害は連鎖的であり幾何級数的であり予測不能かつ壊滅的大打撃！大打撃！！大打撃！！！見ろフレームがゴミのよーだ。
　フツーの設定だと最大1秒間。ちゃんと見てると結構長いよ～。

　いやわかんなくていーですこんなん。

　ひらたく言うと、I/IDR設定ミスの影響は「風が吹けば桶屋が儲かる」。
　正確かつ必要最低限のI/IDRはx264の第一歩。

　真面目な話Apple-H.264にはこの問題が無い。それどころかGOP設定をおろそかにしたx264はXvidにも劣る。あえて言おう。カスであると！（得意げ）

３. x264の場合、I/IDR調整のアプローチは２種類ある。

場面転換点へのIDRの挿入：最小/最大間隔を数値指定。挿入位置（場面転換検出）は指定範囲内で自動 ⇒ keyint系
追加的なIの挿入："映像が大きく変化するが、場面転換というほどでも無い箇所"の検出感度を指定。検出感度は上記と連動。 ⇒ scencut

ほんとうは全ての場面転換に手動で「ここに I/IDR入れてね」とマーカーを打つのがベストだと思うんだけど思ってみただけですすいません。だから上の二つを調整して、I/IDRが多すぎず少なすぎず、ちょうど良い案配にかつ適切な位置に入るような値を見つけてやる必要がある。デフォルト値は実写ではそう悪く無い。アニメではガタガタ。逆にアニメ用に追い込んだ設定だと実写がぐずぐず。
　アニメ汎用と実写汎用、少なくともこの２種類のGOP設定セットを持っておきたい。

NOTE:
　ちょっと注意したいのがIとIDRの関係だ。マルチプル・レファレンスの都合上、H.264のシーク単位はIDRで、Iは無理。extra I-frames（追加的な）などと書いてあったりする。keyint系オプションはシーク単位以上の意味は無いよと書いてあるケースもある。
　XvidではIがシーク単位と画質の基盤を兼ねていたが、 H.264では機能が半分だけ分離していてちょっと混乱する。

余談１：

　GOP関連を重視するについてはもうひとつ理由がある。こちらはとても感覚的なものだ。
　MEncoder -x264encoptsの先頭はbitrate、qp、crf、pass、turbo、と続く。ユーザーの関心のある順で、という意図を感じる。基礎概念も順に読んでいけばざっくり把握できるようになっている。例えばqp（旧称qp_consant）の説明で、自分は他のなによりも先にXvid QP2=AVC QP18と覚えた。
　x264cliの--longhelpは実質的に--keyint、--min-keyint、--scenecutで始まる。想定ユーザー層が違う。 QPの換算式も無い。もしもx264cliがライブラリの動作実験用フロントエンドであるのなら、そんなのは"ソース読め"だ。しかしそうであっても、いやだからこそ、後から参加するプログラマに読むべき順番を指し示す『もくじ』が要る。それはテスターやプログラマが最も呼び出し易い位置にあるべきで、かつ、符号化理論の根から枝葉に落ちてゆく順であるべきだ。
　おそらく--longhelpの書き手はそうしたもくじ以上である事もそれ以下である事も意図していない。そーささやくのよ、あたしのゴーストが。

余談２：

　理屈はまぁ、2.の前半で解ったような気になっているものの、所詮は文系。ハラゴナレがどうもいまひとつ。

『改訂版 H.264/AVC 教科書』ixページ。
　しかし、我々が用いた技術は、はるかに洗練され手の込んだものになっていて、時にベースとなっている設計原理の単純さを見失うほどです。もとのH.261 標準文書が仕様のすべてを表して25ページ以下であったのに対し、今回の新標準はその10倍以上の長さであり、技術的内容の密度も高くなっています。その様子は、折り紙作品に似ています。単純な基本コンセプトを幾層にも重ねることにより、新たな高度の造形に至っていて、これは注目に値する成果だと確信しています。

　そこで紙を一枚だして鶴なぞ折って見る。自分でもどうかとは思うが大した手間でなし、規格制定会議のエラい人がいってんだからそう外れたもんでもあるまいよ。だいいちいまさら引き返せるかってんだい…出来た。出来を決めるのは、最初の三角折り。奇麗に、ぴちっと、慎重に。ここをミスると誤差が連鎖的に波及して、最終的な出来がへげへげになる。最初のズレをほっぽらかして途中で帳尻あわせようったってそうは問屋がおろさねぇ。やり直したほうが早い。あらそっくり。げぇじんさんは例えがウマいねぇ。