これはなに？
x264 エンコードオプションにおける、自分的に調整する機会が多い項目についてまとめたものです。人に見せるというよりむしろ自分で見るために書いています。なんだかんだでブラウザは開きっぱなしになりがちなので、自分の blog というのはメモ置き場としてかなり便利です。文ちゃんもいるし。
それと「MMD Avi出力」なんかの検索ワードでこの blog に来てる人が結構いたりするのです。意外ですね。まあそういうわけもあって書きました。でも、ここの内容がどれだけ役に立つかというと……
上記検索ワードを調べるのに統計ページを見てみたら、どういうわけか今週アメリカからのページビューが50件ほどあるのに気付きました。一体なんなのよと思ったらリファラスパム（わかりやすい説明）とかいうものみたい？ 皆さんもご注意を。
なお、内容については一部を除いてニコニコwikiの拡張 x264 出力（GUI）Exの設定項目とその機能についてをとっても参考にしており、特に注釈のない引用（白い字の部分が引用です）は上記ページからのものです。というか上記ページからいちいち探すのが面倒なので抜粋してまとめつつ、現在製作中の動画のエンコ設定について考えようというのが実際の所。
上記ページ内容が最新情報かどうかは未確認なので本エントリの情報についても同様になります。x264 は開発速度がけっこう速いので、情報を見つけても最新バージョンで有効なものかどうかよくわかんなかったりするんですよね。
各項は、最初に使用頻度の高いパラメータ具体値とデフォルト値等を列挙し、その後にメモが続く形になります。
用語と前提
念のため用語の定義と前提条件について軽く。この項に限らず、明らかにこれ変じゃね？ってのがあったらご一報いただけると助かります。- 再生負荷 … 動画を見る側にとっての「重さ」
- エンコード時間/負荷 … 同一条件下でのエンコードに掛かる時間の多寡。って当然ですが。
- 画質 … 一定ビットレートでの動画の「綺麗さ」。 ≒圧縮率
単に「負荷」と言った場合は再生負荷とエンコード負荷両方が該当します。
ソース次第で最適値が変わるパラメータ（どれも大なり小なりそうなんですが）についての話で、「MMDだと～」みたいな事を言ってるときはカメラをぐるぐる動かしまくったMMD動画がソースの場合だと思ってください。私はそういうのしか今のところ作ったことがないので。
プリセット
--preset [medium/slow/slowerとか]投稿時は slower 一択。テストエンコでは slow を用いる場合あり。medium は参考。
- medium: デフォルト値まま
- slow: me umh, subme 8, ref 5, b-adapt 2, direct auto, rc-lookahead 50
- slower: me umh, subme 9, ref 8, b-adapt 2, direct auto, partitions all, trellis 2, rc-lookahead 60
マクロブロックタイプ指定
- --8x8dct --partitions "p8x8,b8x8,i8x8,i4x4"（デフォルト）
- --partitions all
8x8 離散コサイン変換(8x8dct)を使用すると High Profile になる。p4x4はp8x8をつけないと効かない。i8x8は8x8dctが無ければ効かない。
16x16のマクロブロックを、場面やフレームタイプに応じてさらに細かく分割できるようにしましょうというもの。
有効にすればするほど画質が良くなるが、エンコード・再生双方の負荷も上がる。
p4x4（x4, 4x8 and 8x4 Pフレーム動き補償）は負荷の割に画質に貢献しないという説がある。ただしこの説はかなり過去のもので、現在のバージョンにおいてはおそらくそれなりの効果がある。
SD ソースにおいては p4x4 を除外した 1.を用い、HD ソースにおいては 2.を用いる事が多い。
CABAC
デフォルトで on。--no-cabac で off画質貢献度は高いが、再生負荷もとても高い。
他のパラメータをガチガチに上げても CABAC さえ off にすれば再生負荷を抑えられるため、再生負荷を下げる必要がある場合にはまず CABAC の off を 検討する。HD では on が無難、なんだけど自作の咲夜さんがNostalogicを踊る動画では off にしてます。おかげで HD の割には軽いみたい？ 代わりにビットレートを最大限まで高くしてあるんでダウンロードに時間喰いますが。
動き予測アルゴリズム
--me "umh"デフォルト："hex"
7と9を使う場合は要--bframes 1以上。10(QP-RD)以上を使う場合は後述の--aq-modeを1か2、--trellisを2にする必要がある。
強力なものを選ぶほどエンコード時間が延び、画質が上がる。再生負荷には影響しないはずなので、それなりに重いものを選ぶべき。というか umh（Uneven Multi-Hexagon search）一択で良い。esa 以上になるとほぼ時間の無駄。
サブピクセル動き予測
--subme 9--subme 10
デフォルト： 7
数字が大きいほどエンコード時間が延び、画質が上がる。再生負荷には影響しないはず。
preset で指定されているのであえて指定しない事も。画質優先の場合は10。
動き検索範囲
--merange 16--merange 24
とか。
デフォルト： 16
動き探索につかわれる predictor(予測器)の距離。
--me dia/hex の場合は 4-16
--me umh 以上の場合は 4-64 まで指定できる。
数字が大きいほどエンコード時間が延び、画質が上がる。再生負荷には影響しないはず。
ただし大きすぎると誤検出のおそれがある。最適値はソース次第で、スタッフロールやパンなどでカックンカックンする場合は誤検出が起きてるのかも。
参照距離
--ref 6とか。
デフォルト：3
参照に使えるフレームの最大距離数。1-16
大きいほど画質が上がる可能性があるがエンコード時間が延びる。再生負荷も多分少し増えて、使用メモリが増大する。
最適値はソース次第。
MMDだとほぼ 5-6 ぐらいで頭打ち。preset のデフォルトか、6で良い。
タイトルやエンドクレジットなど、動きの少ない映像では高い ref が画質に貢献するので、そのての割合が多いソースでは高くすると良い。
flash player や視聴環境がどこまで対応しているか定かではないので、16とかバカっぽい値は避けるべき。
最大Bフレーム連続数
--bframes 5とか。
デフォルト： 3
そのまま。1-16
圧縮率は Bフレーム > Pフレーム > Iフレーム の順に高いので、Bフレームの割合は圧縮率に影響する。
最適値はソース次第。MMDだとほぼ 5-6 ぐらいで頭打ち。
大きいほど画質が上がる可能性があるがエンコード時間が延びる。再生負荷も多分少し増えて、使用メモリが増大する。
各フレームについてはこことかここ(IDR)、GOPと早送り/巻き戻しなどについてはここ。
DCT 係数の間引き処理
--no-dct-decimate で off。デフォルトは onまるも製作所さんによると
「DCT 係数の間引き処理」というのは (中略)、非常におーざっぱに説明すると、「量子化後の DCT 係数が小さくて少なければ、量子化で消えちゃったことにしちゃおーぜ」という内容のもの。
(中略)
実際この処理を実行しないよりもした方がひじょーに、ひっじょーに僅かながら RD 性能の改善があるのだけど、個人的には flat16 matrix を使っている時以外は、常にこのオプションを有効にして、間引き処理を無効にしておいた方が良いと思う。
とのこと。低ビットレート時を除いて off が良さそう。
念のために言えば、上記引用は古い情報である。おそらく、カスタムマトリクスが大いに有効だった頃の。現在のバージョンでは MB tree や VAQ なんかが頑張ってくれるので matrix は flat が一番と言われてる。ので「flat16 matrix を使っている時以外は」という条件に反するわけではあるが、それでも off が良いみたい。
スキップMB検出
--no-fast-pskip で off。デフォルトは onPフレームのスキップ判定（マクロブロックタイプ・スキップ）の on / off。
off にするとスキップせずに真面目に全部計算するので速度が低下する。それによって青色の領域（空など）でブロックノイズが減る。
ソース次第だが、青い領域があるようなら off が良い。
ビットレート変動量
--qcomp 0.70--qcomp 0.80
とか。
デフォルト：0.6
割り当てビットレートの変動許容量。
正直良くわかんないけど、数字が大きいほど量子化量(qp)の最大値と最小値の差が大きくなる事を許容する……のかなあと思います。
もちろんソース次第。
あまりがんばって調整しても大して影響ないと思う。
最大QP変動幅
--qpstep 20デフォルト：4
連続フレーム間における量子化値(qp)の最大変動幅。1-51
大きくすると、ビットレートの急激な変動を許可することになる。なので大きい方が圧縮率は上がるだろうが大きすぎると心理的画質は下がるかも。
もちろんソース次第。
あまりがんばって調整しても大して影響ないと思う。
あとがきというかむだ話
リンクがないとあいかわらず寒色一辺倒な blog です。これからの冬、やっていけるでしょうか。見てるだけで寒くなりそう。わざわざ x264cli でエンコしてるのは avs がそのまま使えるのと、パラメータをバッチファイルにしておけるから。なんだかんだで便利だと思います。バッチファイル。エンコの度に毎回つんでれんこの質問に答えるというのもめんどくさいというか、つんでれんこに avs を食わせるとマルチパスでコケるんで使いようがないんですね。でも今後は AviUtl 使って色調補正しようかなとか思っているのでその辺はどうなるか。
