※2007/8/3で抽出すると全件を1ページに読み込みます。
x264cliの --longhelp はプログラマさん向けのもくじで、符号化理論の根から枝葉に向けて落ちて行く構成になっているようです。しかし、詳細はソース嫁というカンジで、これだけではなにがどういうケースで役に立つかは解りにくいと思います。
Zero 1氏がまとまったガイドを用意されているので訳してみました。
原文は Encoding H.264 using the x264 Command Line
Interface
ですが、rev.400番台のsharktooth版のままのようで、一部古い記述が残っており、また実際とは挙動が異なる部分もあるかと思います。訳文には可能な限り手を入れましたが、自分はマカーでめんこでらーなので保証の限りではありません。x264cliユーザの方は、下記も合わせてお読み下さい。
＊オプション名、デフォルト値、指定範囲は以下に準拠しています。
$ x264 --longhelp
x264 core:55 svn-663
Syntax: x264 [options] -o outfile infile [widthxheight]
Infile can be raw YUV 4:2:0 (in which case resolution is required),
or YUV4MPEG 4:2:0 (*.y4m),
or AVI or Avisynth if compiled with AVIS support (no).
Outfile type is selected by filename
.264 -> Raw bytestream
.mkv -> Matroska
.mp4 -> MP4 if compiled with GPAC support (no)
List all options
全てのオプションを表示
最大GOP（Group Of Pictures）サイズ。新しいIDRが強制挿入され、次のGOPが始まる前に連続するフレーム数の上限を指定する。XviDの "Maximum I-frame Interval" に相当するだろう。経験的に10秒分のフレーム数を指定してシーク単位にする人が多い。PAL @ 25 fps なら --keyint 250、NTSC @ 23.976 fps ならちょっと丸めて --keyint 240だ。一般的にGOPは--keyintの指定値を超えない限りは場面転換で始まる。だからこのスイッチを弄る価値があるのは、映像に場面転換や大き な変化が無いなが～い素材だけだ（AMVではそういうのはまず無い）。
＊AMV：アニメ・ミュージック・ビデオ。全体的にこのガイドアニメ寄り。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#frame-type-options
--keyint
Usage: --keyint <integer> (default=250)
This is the maximum GOP (Group Of Pictures) value. It controls the maximum number of frames allowed before a new IDR frame is forced and starts a new GOP. The equivalent to this that you would find in XviD would be "Maximum I-frame Interval". As a rule of thumb people tend to set this at 10 seconds worth of frames to aid seeking. For PAL @ 25 fps it would be --keyint 250, or for NTSC @ 23.976 fps we would just round up and use --keyint 240. A new GOP will usually begin at a scene change, unless the --keyint value is exceeded, so this only really applies for sources with long durations without a scene change or significant change in the image (which will almost never happen in an AMV).
Minimum GOP size
範囲：
最小GOP（Group Of Pictures）サイズ。新しいIDRが強制挿入され、次のGOPが始まる前に連続するフレーム数の下限を指定する。--min-keyintの値より短い間隔で場面転換があったら、x264は場面転換をIフレームとしてエンコードし、新しいGOPを開始しない。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#frame-type-options
--min-keyint
Usage: --min-keyint <integer> (default=25)
This is the minimum GOP (Group Of Pictures) value. This specifies the minimum number of frames allowed before a new IDR frame and GOP is forced. If a scene change happens within the --min-keyint value, it will simply code the first frame of the scene change as an I frame and prevent it from starting a new GOP.
2007/07/15（日） x264 [15] --b-rdoより
--min-keyint 15 # x264 内部で 8=(15+1)/2 に丸められるので意味がない＊MEncoderのkeyint_min=<1-keyint/2>ってそういう意味だったのか！
How aggressively to insert extra I-frames
範囲：1 - 100
追加的なIフレームを挿入する際の閾値。高くするとたくさん入るが、不必要に入ってbitが無駄になるかもしれない。例えば場面転換と 言うほどでもない画面の変化など。低くするとIの挿入頻度が減るが、やりすぎると --keyint 指定値への依存度が上がって適正箇所にIが入らない。例えば場面転換に非常に大きいPフレームが入るなど（Pは先行するIかPが無いとデコードできない）。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#frame-type-options
--scenecut
Usage: --scenecut <integer> (default=40) [1 - 100]
Scenecut is the threshold for inserting extra I-frames. Setting a high value will cause it to use I-frames where they perhaps aren't needed (and in turn waste bits), for example a considerable change in the image, but not significant enough to be considered a scene change. Setting the value lower will use fewer I-frames and will rely more on the --keyint value which may end up in non optimal placement of I-frames, for instance you might get a very large P-frame at scene change instead of an I-frame (and P-frames require previous I or P frames to be decoded).
・漏れ自身が勝手に思うに、アニメOPで適当にキーフレームぶち込まれるには、
--scenecut 75ぐらいかなと、感じている。
アニメ作業するなら少なくとも、60ぐらいを使ってもいい気がする。…(3)
default値である40だと、少々足りないということだ。
Faster, less precise scenecut detection.
Required and implied by multi-threading.
高速だがやや不正確な場面転換検出。
マルチスレッドの際に必要となり、使用される。
＊自動で切り替わるようにも読める。MEncoderには存在しない。
--threads が 1 よりも大きい場合は pre_scenecut が有効になって（＊以下略＊）とある。特に意識する必要はなさそう。
Number of B-frames between I and P
範囲：0-16
適正範囲：3~4、--no-b-adapt使用時は0か1
I・Pフレームの間に入るBフレームの最大連続数。
Xvidや他のMPEGエンコーダでBフレームには慣れている人は多いと思う。Xvid でこれに相当するオプションは"Max consecutive B-VOPs"。Bフレームは非常に符号化効率が良いが、たくさん使う程デコード負荷が上がる事に注意。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#frame-type-options
--bframes
Usage: --bframes <integer> (default=0) [0 - 16]
This simply controls the maximum number of consecutive B-frames between I and P frames. You will be familliar with B-frames from using XviD (and perhaps other MPEG encoders). The same option in XviD is reffered to as "Max consecutive B-VOPs". While B-frames are very nice from a coding efficiency point of view, bear in mind that the more get used, the higher the decoding requirements will be.
このオプションは適応的Bフレーム挿入をdisableにするもの。一般的にはオフはお奨めできない。デフォルトではx264がどこにどれだけのBフレームを使うか自動で決める。最大で何枚使うかは--bframesで決まる。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#frame-type-options
--no-b-adapt
Usage: --no-b-adapt (default=on)
This option disables adaptive B-frame decision and is generally not recommended. When not disabled (it's enabled by default and --no-b-adapt turns it off) this allows the encoder to automatically decide where B-frames will be used and how many. How many B-frames adaptive B-frame decision will use is defined by --bframes as above.
Influences how often B-frames are used
範囲： -100 - 100
適正範囲：0 (def)
適応的Bフレームの挿入に影響。高いほどBフレームを沢山使う。上限は--bframesで指定した値。低いほどたくさん間引く。Xvid でのB-VOP sensitivityに相当。-100から+100までのスライダがあると思えば良いだろう。-方向がBを減らし、+方向がBを沢山使う。推奨はデフォルトの0（またはスクリプトに書かない）。というのはB使用を強制すると画質が悪くなる事があるからだ。特に暗い領域やフレームで多い。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#frame-type-options
--b-bias
Usage: --b-bias <integer> (default=0) [-100 - 100]
--b-bias affects adaptive B-frame decision. A higher number will result in using more B-frames up to the specified maximum and the lower number will use less B-frames. There is a similar option to this in XviD called B-VOP sensitivity. You can visualise this as a slider, with -100 at the left with a label "Use less B-frames" and 100 on the right labelled "Use more B-frames". It is recommended to leave --b-bias at 0 (or simply leave it out from your script) since forcing B-frames can be sub-optimal, particularly with trouble sources like dark areas or flames.
Keep some B-frames as references
範囲：-
一部のBフレームを参照フレームに使えるようにする。他のフレームがBを参照できるようになるので符号化効率があがる。2枚以上のBフレームが必要で、デコーダー・ラグが2になる事がある。この機能はデフォルトではオフ。コマンドラインに --b-pyramid と追加すると使えるようになる。
＊Decoding Delayについて
http://aflux.deltaanime.net/Zero1/MP4/x264.html#frame-type-options
--b-pyramid
Usage: --b-pyramid (default=off)
This allows the encoder to use some B-frames as references. This should help increase efficiency since other frames can now be predicted using B-frames. This feature requires 2 or more B-frames, and may cause a 2 frame decoder lag.
Disable CABAC
CABACはエントロピー符号化で、マクロブロック情報を扱うもの。
マクロブロックのヘッダ、テクスチャ、モーションベクトルといった情報をロスレスにビットストリームに圧縮する。ビットレートにして約10%の削減が可能で、アニメではもっと期待出来る。そのかわりエンコード・デコードとも負荷が増えるが、画質に影響しない事を考えると10%はとても魅力的だ。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#frame-type-options
--no-cabac
Usage: --no-cabac (default=on)
CABAC (Context-Adaptive Binary Arithmetic Coding) is an entropy encoder. What it does is take the macroblock information, their headers, textures, motion vectors and compresses it to the bitstream losslessly. CABAC can save approximately 10% on bitrate, and possibly more for anime. The downside is that it increases encoding and decoding requirements, however a 10% bitrate reduction is a significant advantage considering it doesn't degrade quality.
Number of reference frames
範囲：1 - 16
参照フレームの数を指定。
これにより、P/Bフレームの予測に使う参照フレームを、デコード済みフレームをさかのぼって選べるようになる（指定した枚数まで）。
高くすると一定ポイントまで圧縮効率があがる。これは原理的にアニメに非常に効果的だ。というのは、キャラクタが喋る時に口だけが同じような動きを繰り返してあとは変化しない場面、とか、風になびく髪のように同じ動きがループするような場面はよくあるから。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#frame-type-options
--ref
Usage: --ref <integer> (default=1) [1 - 16]
This is for setting the number of reference frames. It allows new P and B frames to be predicted by using a previously decoded frames (up to the number specified in --ref). Setting a higher value will increase efficiency up to a point. Naturally this is a very beneficial feature for anime since you often get many similar frames say for when a character is speaking and only the mouth is changing, or for loops where something is repeated like hair swaying in the wind.
http://www.marumo.ne.jp/db2007_7.htm#10
H.264 では、MPEG-1/2/4 までとは異なり、動き補償 (予測) の際に複数の参照フレームを利用することができる。x264 の --ref オプションでは、何枚のフレームを参照するかを指定するためのもの。
複数参照フレームが最も効果を発揮するのはフラッシュが多用されている映像。次に効果が出るのは背景の上で物体が動いてるような場合。直前フレームにはボールがあったけど、現在のフレームでは背景だけになっている部分。専門用語でこーゆーのを uncovered background (覆いがはずれた背景) とか呼ぶのだけど、これは複数参照フレームでさらに前のフレームを参照してしまえばよく似た部分が見つかる。
規格上、参照フレームはMB全体の他に8x8 サブブロック単位で別々の参照フレームを見ることもできる。--mixed-refs はその切り替えオプション。
フラッシュのシーンだけ救えれば十分だという場合は --mixed-refs を指定する必要はないだろうけど、uncovered backgroud を救いたい場合は --mixed-refs を指定した方がよいはず。MB の一部だけに差し掛かる物体の場合は 8x8 単位で別々の参照フレームを使えた方がより効率の良い符号化ができるはずなので。
まるも製作所：2007/07/15（日） x264 [15] --b-rdoより
--ref 1 # 参照フレームは 1 枚に制限 (マルチレフ無効)
インループ・デブロッキングのオフ。-f, --deblockの項参照。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#frame-type-options
--nf
Usage: --nf (default=on)
Disables inloop deblocking. Read --filter below for more information
デブロックフィルタ使ってると、細部が潰れるので気になるときがある。
そういう時は、コレ使ってデブロックフィルタ切ったほうがいいかもしれない。
通常、インループ・デブロッキングは圧縮効率、ひいては画質の向上になる。効果が気に入らない時は単に値を下げると良い。このオプションのねらいは、Xvidのハイモーション箇所で見られたようなブロックノイズのスムーシングだ。AlphaC0 は強度、Betaは閾値。デフォルトの0:0は最適値として考えられたものだが、Sharktoothによればアニメは3:3が良いとの事。短いクリップをいくつか用意して実験すると良いだろう。
＊参考：まるも製作所さんの日記『07/07/31（火） H.264/AVC のデブロックフィルタ詳細』
http://aflux.deltaanime.net/Zero1/MP4/x264.html#frame-type-options
--filter
Usage: --filter <alpha:beta> (default=0:0) [-6:-6 - 6:6]
The inloop deblocking usually improves compressability and therefore quality. If you do not like the effect simply turn it down. What it tends to do is smooth an image as opposed to letting it block in high motion areas like you may have seen in XviD. The AlphaC0 parameter controls the strength, and Beta controls the threshold. The default value of 0:0 is thought to be optimal, although Sharktooth has suggested to me that anime would look good at 3:3. Experiment on short varied clips and see what works for you.
＊x264はインターレースにMBAFFを使う。PicAFFは無い。
＊インタレ保持
Pフレームの量子化値を固定。I/Bフレームの量子化値は --ipratio と --pbratio の指定値を元にここから計算される。XviDでは量子化値が低いほど画質が良かったが、XviDのQP2はx264のQP18に相当するので注意が必要だ。これはH.264規格が対数尺（＊logarithmic scale＊）を使っているから。概算の換算式は、QP AVC qp = 12 + 6*log2(ASP qp)。0でロスレスになる。
＊1パス画質固定エンコードにはCRFの方が向いている。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#rate-control
--qp
Usage: --qp <integer> (default=26) [1 - 51] (0 = Lossless)
This sets a constant P-frame quantizer. The quantizer for I and B-frames are then calculated by the QP factor set in --ipratio and --pbratio. As with XviD, the lower the quantizer, the higher the quality, but this one of the features that I warned you about. QP 2 in x264 is NOT like QP 2 in XviD, in fact the equivalent to XviD's QP 2 in x264, is QP 18. This is owing to H.264 using a logarithmic scale. The formula to find the approximate equivalent QP is as follows: QP AVC qp = 12 + 6*log2(ASP qp). x264 is also capable of lossless encoding, to enable this mode set the QP to 0.
・default値のQ値には少し不満が出る。
過去のコーダ同様に、少しビットレートを増やす程度に変更すると、納得いくかもしれない。
画質と容量とを、自分の用途にあわせて煮詰め、Q値を設定したい。
30より大きい数字は、劣化具合がカナリ強くなる傾向になる。気をつけよう。
平均ビットレートで使うビットレートの指定。単位はキロビット/second ( kbps )。
特定のファイルサイズに収めたければ2パスを推奨。画質と特定のファイルサイズを両立できる。概ね1分以下の短いクリップでは3パスが有効かもしれない。x264の--bitrateは本質的にABR（平均ビットレート）だ。ストリーミング以外にCBR（固定ビットレート）を使う理由はあまり無いが、使う場合は--vbv-maxrateも調整すること。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#rate-control
--bitrate
Usage: --bitrate <integer> (default=off)
Allows you to specify an average bitrate in kilobits per second (Kbps). If you are trying to meet a filesize, it is recommended you use 2 pass encoding, this will increase quality as well as help you meet the target bitrate. For short clips around 1 minute or less, a third pass may be beneficial. x264's --bitrate is inherently ABR, if you must use CBR (there are few goods reasons for this other than streaming) then you will need to change the --vbv-maxrate accordingly.
Constant Rate Factor。名目上のQPに基づく1パス ABR。
＊Zero1氏原文では整数指定だが、今回元にしたrev. 663では<float>、少数。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#rate-control
--crf
Usage: --crf <integer> (default=off) [1 - 51]
Constant Rate Factor. This is a one pass VBR mode based on a nominal QP.
保存用で普通に1passQ値エンコさせるなら、こちらを使ったほうが、感じいい気がします。
ローカルビットレートの最大値。単位はkbits/second。
CBRモードを起動して、VBVバッファサイズを指定する(kbit)
VBVバッファ占有率の初期値。
x264が使う最小quantizerの指定。
高いquantizerを使ってもあまり見た目が変わらない場面でbitの浪費を抑える。XviDで最小quantizerを２にするようなものだが、H.264との量子化スケーリングの違いを忘れない事。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#rate-control
--qpminSimply sets the minimum quantizer that x264 is allowed to use. This will prevent bit squandering where using a higher quantizer makes little or no visual difference. This is similar to using XviD in as much that you used to cap the minimum quantizers at 2, but do bear in mind the differences in quantization with H.264.
・--qpmin,--qpmaxで設定された可能な範囲で、--bitrateを実現させようとエンコする。
だから。指定しない方が、融通は利く。
しかし、マックス値を制限させた方が、画質は安定傾向になる。
max値を無理が無いように、美味く設定したい
x264が使う最大quantizerの指定。
quantizerが自分の好みより高くなるフレームがあったらこれでキャップをかけることができる。一般的にx264のレートコントロールはとても優秀で、キチガイじみて高い/低い量子化値を使う事はあまりない。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#rate-control
--qpmax
Usage: --qpmax<integer> (default=51) [1 - 51]
Sets the maximum quantizer that x264 is allowed to use. You can cap this if you find that some frames are being quantized too high for your liking. In general the ratecontrol of x264 is very good and won't tend to use insanely high or low quants.
隣接フレーム間におけるquantizerの変動幅を調整。理論上、大きくするとquantizerの変動幅が大きくなり、短い間隔で画質がおおきく変動する。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#rate-control
--qpstep
Usage: --qpstep <integer> (default=4) [1 - 50]
This controls the maximum amount by which the quantizer may change between frames. Setting a large value will in theory allow the quantizer to fluctuate more between frames, in turn producing a large variation in quality in a short time.
・適用Q値の変化できる、Q値幅。
明るいシーン → 暗いシーン となったときなどで、ビットレート変化を
大幅に行ってほしいのであれば、この数値を増やしておく。
漏れ個人が考えるに、このdefault値4って、小さいなと考えます。
＊なるPさんはアニメで8程度を使っている模様。
Allowed variance of average bitrate
範囲：0.1-100.0
ABRにおけるビットレートの逸脱許容範囲。1.0より大きくするとファイルサイズが目標より大きくなる事がある。同様に1.0より小さくすると目標より小さくなる事がある。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#rate-control
--ratetol
Usage: --ratetol <float> (default=1.0) [0.1 - 100.0]
Defines the allowed deviation in the average bitrate. Setting it higher than 1.0 may result in files larger than your target, and likewise setting it less than 1.0 may result in undersized files.
I-Pフレーム間のquantizer換算係数。
1.00でPとIに同じquantizerを使う。これは推奨しない。bitの無駄に等しいからだ。素材のAMV（＊アニメ・ミュージック・ビデオ＊）があまりBフレームを生成しないようだったら1.40より高くしても良いだろう。Pフレームの画質を落とす事になるが（その程度は--ipratioの指定値による）、その代わりハイ・モーション・エリアなどで画質のバラツキやブロックノイズが減り、安定する。
＊ハイ・モーション・エリア：動きの多い部分。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#rate-control
--ipratio
Usage: --ipratio <float> (default=1.40)
Defines the quantizer factor between I and P frames. Setting this to 1.00 will mean that P frames will get the same quantizer as I frames which is not recommended because it amounts to wasting bits. You could try setting this above 1.40 if you find your AMV isn't making much use of B-frames, this should decrease the quality of the P-frames (how much is dependant on the --ipratio) but in turn result in a more consistant quality, as opposed to it fluctuating and blocking in high motion areas etc.
I-Pフレーム間のquantizer換算係数。
ここでも、1.00でPとBに同じquantizerを使う。--ipratioも1.00なら I, P, Bが全て同じ量子化値を使う。一般的にBフレームはPフレームよりもっと高い量子化値を使っても良いので、ここは1.30より高くしたいケースもあるだろう。特に--brdo (VHQ for B-frames)を使っている場合とか。I, P, Bフレームをどのくらい使ったかはエンコード終了後、コンソールに表示される。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#rate-control
--pbratio
Usage: --pbratio <float> (default=1.30)
Sets the quantizer factor between P and B frames. Again, setting to 1.00 will cause B frames to be quantized the same amount as P frames, and therefore is --ipratio is set at 1.00, I, P and B-frames will all be quantized equally. In general you can compress B frames even more than P frames, so you might want to try values higher than 1.30, particularly if you enable --brdo (VHQ for B-frames). I, P and B-frame usage is printed in the console when the encode is complete.