14.5.1.2. Options which primarily affect speed and quality
＊順番調整用＊
subq:速度と画質を取引するオプションの中では、一般的に subq と frameref が最も重要です。速度であれ画質であれ調整したいと思ったらこの二つを最初に弄りましょう。速度については、この二つは非常に密接な関係を持っています。
過去の実験では、デフォルト設定（frameref=1:subq=5）は frameref=1:subq=1 よりも35%ほど時間がかかります。 frameref=6 なら時間は60%以上かかります。subqがPSNRに与える影響は、参照フレーム数に関わらず非常にコンスタントなようです。一般的に subq=5 のPSNRは subq=1 より0.2-0.5 dB高くなりますが、これは充分に目で見て解る違いです。
subq=6 は妥当なコスト（低速化）でよりよい画質をもたらします。通常、subq=5 より global PSNR が 0.1-0.4 dB 向上し、速度は 25%-100% 低下します。subqの他のレベルとは異なり subq=6 はあまり frameref や me の値の影響を受けませんが、主に Bフレーム数の影響を受けます。一般的な使い方では、subq=6 は複雑で動きの多い場面では速度と画質の両方に大きな影響が出るが、動きの少ない場面では大した影響が無い事を意味します。なお、bframes は常に0以外にするのがお奨めです。
subq=7 は最も遅く、最も高画質になるモードです。一般にglobal PSNR は subq=6 より 0.01-0.05 dB 向上し、速度低下は 15%-33% くらいです。この取引は非常に分が悪いので時間を気にせずbit単位で節約したいのでも無い限り使う必要はないでしょう。
framerefのデフォルトは1ですが、妥当な理由があるわけではありません。
・frameref=2にしただけでもPSNRは約0.15db向上し、5-15%の速度低下があります。これは良い取引だと思います。
・frameref=3ではPSNR向上は約0.25db（frameref=1に対して）、これは目で見て解る違いです。速度低下は約15%（これも frameref=1に対して）。残念ながら、ここから効果は急速に減少していきます。
・frameref=6のPSNRはframeref=3に対してたった0.05-0.1 dBくらいしか向上しません。一方、速度低下は約15%追加です。
・frameref=6より上となると画質向上は非常に僅かです（とはいえ素材次第で全く異なる事に注意して下さい）。一般論としては、frameref=12のPSNRはframeref=6に対してたった0.02dB、速度低下は約15-20%追加です。こうした大きなframeref指定について言えそうな事は「PSNRが下がる事はまず確実に無い、画質向上は計測できるギリギリで、目で見てわかるかどうか」くらいです。
ノート：
CABACオフの場合、不必要にframerefを高くすると符号化効率が落ちる可能性があり、実際、通常は落ちます。
CABACオンの場合（デフォルト）、いまのところframerefを「高くしすぎる」心配はしなくて良いようですが今後の開発の進捗で変わる可能性があります。
速度を考えて妥協するなら、subqとframerefを 1stパス では低く抑えて 2nd で上げるという手があります。一般的に最終的な画質低下は無視できる範囲におさまります。PSNRにして0.1dB 以下。これは目で見て解るには小さ過ぎます。しかし、1st と 2nd で frameref を変えると、フレームタイプの決定に影響が出る事があります。例外的なケースのようではありますが、確実を期すなら、素材映像にスクリーン全体を覆うフラッシング・パターンや、Iフレームが入りそうな非常に長いシーンの繰り返しが無いかを確認し、1stパスのframerefをフラッシュサイクルや繰り返しが入るくらいに大きくして下さい。例えば、3フレームに渡るフラッシュ有りとナシの繰り返しがあったら、1stパスのframerefを3以上に。実写素材では非常に稀なケースだと思いますが、ビデオゲームのキャプチャではよくあります。
me: このオプションは動き予測に使うサーチ方式の選択で、速度と画質の取引に直結します。
me=diaはデフォルトより数パーセント速いだけで、global PSNRの低下は0.1dB以下。
me=hex（デフォルト）はまずまず妥当な取引です。
me=umhの速度低下は frameref に依存しますが、global PSNRの向上は0.1dBをやや切るくらい。
frameref が12のように高いと速度低下はデフォルトの40% くらいになります。 frameref=3 では 25%-30%くらいの低下。
me=esa は徹底的なサーチを行いますが、実用には遅過ぎます。
partitions=all: このオプションは予測されたマクロブロックの中のサブパーティションサイズに、8x4, 4x8, 4x4 を加えるものです。コンスタントに 10%-15% の速度低下があります。ローモーション素材ではまず無意味ですが、一部のハイモーション素材、特に細かい動く物体が大量にある場面では 0.1dB 程度のPSNRゲインが期待できます。
＊まるも製作所さんはp4x4を非推奨としている事に注意。
bframes: 他のコデックでのエンコードに慣れている人なら、Bフレームは良い事ばかりでは無いと考えているかもしれません。H.264ではこの常識は異なります。Bフレームには様々なあたらしい技術とブロックタイプが導入されました。多くの場合、単純なB選択アルゴリズムでさえ目覚ましいPSNRの向上をもたらします。また面白い事に、通常はBを使うと2ndパスがやや高速化します。またシングルパスエンコードも適応的B挿入を切れば高速化が望めます。
適応的B挿入を切った場合（nob_adapt）、bframesの設定は1以下が最適です。さもないとハイモーション・シーンで苦しむ事になるでしょう。適応的B挿入を使う場合（b_adapt、デフォルト）はbframesの数を増やしても安心です。圧縮効率の悪くなる場面ではコデックがBの使用を控えます。x264が3~4以上のBフレームを連続させることは稀ですから、それ以上を指定してもあまり効果はありません。
b_adapt: このオプションは（デフォルトでenabled）あまり効果の無い場面でBの使用を控えるもので、判断精度も速度もそこそこ妥当です。間引き具合の調整にはb_biasを使います。適応的B挿入の速度低下は今のところ慎ましいものですが、画質向上もそれなりです。通常は害はありませんが、このオプションは1stパスの速度とフレームタイプ決定にしか影響がない事に注意して下さい。b_adapt と b_biasは後続パスにはなんの影響もありません。
b_pyramid: Bフレームを2以上にしているならこのオプションも使うと良いでしょう。man page にあるとおり、速度低下抜きで若干の画質向上が得られます。概ね2005年３月以前のlibavcodecベース・デコーダではデコード出来ない事に注意して下さい。
weight_b: 一般的なケースではこのオプションのメリットは大きくありません。しかしクロスフェードや黒フェードアウトの場面では、適応重み付け予測はビットレートを非常に節約してくれます。MPEG-4 ASPで黒フェードアウトの場面をキレイに符号化するにはコストの高いIフレームを連続させる必要がありましたが、Bフレームの適応重み付け予測は、少なくともその内のいくつかをずっとコストの低いBフレームにする事ができます。特に特別な判断をするわけではないので、エンコードにかかる時間は最小限です。また、デコード負荷も変わりません。
残念な事に、現在の適応的B挿入が使うアルゴリズムはフェード場面でのB使用を控える傾向がとても強いです。これが変わるまではフェードの影響が大きそうなクリップでは -x264encoptsに nob_adapt を入れておく方が良い事もあるでしょう。
threads: マルチCPUで平行処理をするもの。マニュアルでスレッド数を指定する事もできますが、threads=auto でCPU数に応じて分散数を自動的に決めさせる方が良いでしょう。マルチプロセッサではリニアに速度が向上する（コア一個に付き約94%）ので絶対使った方が良いです。画質劣化は僅かなものです（デュアルコアで約 0.005dB 、クアッドコアなら約 0.01dB ）。
