エンコードで使うマクロブロック・タイプを選択。
種類はできるだけ沢山使う方がx264の判断が賢くなる。例えば、ディテイルがちょびっとしかないモーションブロックには16x16が適している一方、ディテイルの精細なブロックには4x4が適している。つまり基本的にこのオプションはマクロブロックの効率的な符号化をもたらすという事だ。このオプションの有用度はサブペル動き予測の方式に依存する。p4x4 を使うには p8x8が、i8x8 を使うには --8x8dctが必要。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#rate-control
--analyseThis sets the macroblock types that will be available when encoding. It is better to have more if not all of these modes enabled so as to allow the encoder to make a better decision when encoding, for instance large blocks of motion with little detail can be assigned 16x16 macroblocks, and fine detail can go right down to 4x4. It basically amounts to more efficient coding of macroblocks. The usefulness of some of these modes is dependant on the subpixel motion estimation used. p4x4 requires p8x8. i8x8 requires --8x8dct.
ダイレクトマクロブロックで使う動き予測方式の選択。
temporal（＊時間軸＊）が一般的にはベター。動き予測に後続するPフレームを使うからだ。
spatial（＊空間軸＊）は周辺マクロブロックとそのモーションを使う。
noneは最も画質が悪いだけでなく速度まで落ちる。
autoは自動で temporal/spatial 予測を使い分ける。遅いがベストチョイス。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#rate-control
--direct--direct defines the motion predicition used for direct macroblocks. Temporal is usually the better choice since it uses the following P-frame for motion prediction, as opposed to spatial which relies on surrounding macroblocks and their motion. Selecting none will of course give lower quality, and surprisingly, lower speed. Auto is the automatic selection of temporal and/or spatial prediction. It is a slower mode, but it allows it to make the best choice and alternate between modes, as opposed to using one or the other.
http://www.marumo.ne.jp/db2007_7.htm#3
・・--interlaced を使っている場合は spatial または noneのみ。＊リクツでは弄る必要がなさそうだが、なるPさんの意見ではメリットを感じるケースがあるようだ。
＊デフォルトの-1はlevel指定と連動する模様。
まるも製作所さんによると、x264 のデフォルトは level>=3 なら 1 にして、level<3 なら 0 という扱いなので、普通に720x480@29.97 程度 (level=3 相当) の動画をエンコードしている場合ならば、1（8x8）で動いている筈。との事。0（4x4）を有効にするにはデメリットの大きな--partitions p4x4が必要になる。
http://www.marumo.ne.jp/db2007_7.htm#4
http://www.geocities.jp/encmemo5whf6jvag8/index2.html#06-02
・これ使うと、動きが変わる。どう変わるかですが。 B スライスの双方向予測時に、重み付き予測 (weighted prediction)
を行う。--bframes 2 以上の場合に意味を持つ。
通常、Bは前後のPから予測生成されるが、--weightb抜きでは前後のPを単純平均するのに対し、--weightbでは前後のPに相対距離に応じ
た重みをつける。近いヤツは重視して遠いのはそれなりに。
以上、まるも製作所さんの日記（2007/07/04（木）x264 [11] --weightb）およびZero 1氏の説明を合体。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#analysis
Bフレームの重み付け予測は、Bフレームと前方および後続Pフレームの相対距離を勘定に入れる特殊なモード。通常は単純平均を使う。
これは通常はBフレームが入ると見た目が悪い場所にBフレームが入らない事を意味する（例えば動き予測の精度がうまく出ないとか）。このモードが効果を発
揮するには1枚以上のBフレームが必要。
--weightb
Usage: --weightb (default=off)
Weighted B Frame prediciton is a special mode that takes into account the distance of a B-frame, relative to the previous and next P-frames when making decisions, as opposed to simply averaging like it normally would. This means that the use of B-frames is restricted in places where they would normally look bad (ie, if it's too hard to predict the motion accurately). This mode requires more than 1 B-frame to become effective.
http://www.geocities.jp/encmemo5whf6jvag8/index2.html#06-02
・-w 圧縮時間が、モリモリ増える素敵なオプション。Bフレームの出来が上がる。まるも製作所さんでは「B=2以上の場合に意味を持つ」としているが、 Zero1さん、Man-MEncoder共に条件はB=1以上としている。また覚書・なるPさんの「Bフレームの出来が上がる」はB=1時の感想の公算 が高い。これは複数参照が2以上であればB=1でも有効な事を示唆していると思われる。
整数ピクセルの動き予測方式を選択。選択肢は：
dia ダイヤモンドサーチ、半径 1 (高速)
hex 六角形サーチ、半径 2 (デフォルト)
umh 不等複数六角形サーチ
esa 徹底サーチ (低速)
推奨はhexかumh。umh, esaではサーチ半径も指定できる。--merangeを参照。
・09/15/07: [676]： implement multithreaded me=esa ← me=esaのマルチスレッド化
http://aflux.deltaanime.net/Zero1/MP4/x264.html#analysis
--me
Usage: --me <string> (default=hex) [dia, hex, umh, esa]
This sets the Integer pixel motion estimation method. The options are as follows:
dia: diamond search, radius 1 (fast)
hex: hexagonal search, radius 2
umh: uneven multi-hexagon search
esa: exhaustive search (slow)
It is recommended to use hex or umh. umh and esa also have an additional parameter that controls the search radius, see --merange.
--me umh / esa のサーチ範囲を指定。適正値は16か32とされている。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#analysis
--merangeThis is simply the setting for the radius of the umh and esa motion estimation modes. 16 and 32 are thought to be good values.
http://www.geocities.jp/encmemo5whf6jvag8/index2.html#06-02
・この整数値を増やすと、動きが格段に良くなる。＊不詳
＊不詳
サブピクセル精度の動き予測方式の選択。速度と画質の取引に関わるオプションのなかでメジャーなものの一つ。--subme 6 & 7 ではRate Distortion Optimisation (RDO, レート歪最適化)も使う。CPU速度が充分なら推奨はこの二つだが、厳しい場合は5。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#analysis
--submeSets the sub pixel motion estimation algorithm.This is one of the speed vs quality settings. --subme 6 & 7 also introduce Rate Distortion Optimisation (RDO). --subme 6 or 7 is recommended if you have the CPU speed, if not use 5.
BフレームにRDO（Rate Distortion Optimisation、レート歪最適化）を使う。XviDにおけるVHQ B-frameに相当。要--subme 6以上。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#analysis
--b-rdo--b-rdo is Rate Distortion Optimisation for B-frames. The equivalent to this would be VHQ B-frames in XviD. Requires --subme 6 or higher.
基本的に RDO は多少画質劣化が増えても発生符号量が少ないものを選ぶ処理。
画質よりも発生符号量を重視したい B スライスでこそ価値のある処理かもしれない。
一方、 RDO 無効時より精度の高い distortion 評価ができるようになって画質が上がるという側面もある。
--subme 6/7 で I/P スライスでは RDO が有効になるものの、B スライスでは RDOは無効にされた(--subme 5と同じ処理が実行される) ままとなる。RDO を B スライスで有効にするオプションが --b-rdoになる。
＊動きの多寡で効果が違うようだ。また適応的B挿入の可否でも変わって来ると思う。なお手許ではRDOと書いてあったら無条件に使います。XviDのVHQによる刷り込み。
各8x8 または 16x8 motion partitionが、独自に参照フレームを選べるようにする。このオプション抜きの場合、マクロブロック全体が同一の参照フレームを使う。明白に圧縮効率があがり速度が落ちる。またデコードに必要なRAMが増える（しかし参照フレームが大量にあっても～＊以下不明＊～）。
参照フレームが1以上必要。--ref 1など。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#analysis
--mixed-refsAllows each 8x8/16 macroblock partition to choose it's own reference frame as opposed to the whole macroblock using the same reference. This obviously results in improved efficiency at the cost of encoding speed. Decoder wise it will increase the RAM requirement (but the level of videos you will be creating won't require extorionate amounts even with a large amount of reference frames). This mode requires more than one reference frame, ie --ref 1
extorionateの意味不明：「しかし参照フレームが大量にあってもlevel指定を変える必要は無い」？
彩度情報の動き予測を使わない。彩度情報の動き予測（＊Chroma ME＊）はサブピクセル精度の動き予測で使われるもので基本的には使うべき。彩度情報の動き予測を使うにはこのオプションを使わず、--subme 5以上にする事。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#analysis
--no-chroma-meDisables chroma motion estimation. Chroma ME is performed during the subpixel motion estimation search and should ideally be left enabled. For chroma ME to be enabled, this switch must not be used, and --subme must be 5 or higher.
双方向動き予測のジョイント・リファイン。Bフレームの２つのモーションベクトルを最適化する。速度は低下し、圧縮効率が上がる。デコーダへの影響はない。従ってこれも "安心して使える画質向上オプション" の一つと言える。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#analysis
--bime--bime is the switch to enable joint bidirectional motion estimation refinement. It will optimise both motion vectors in B-frames. It will help increase the quality at the cost of encode time, and will have no effect on the decoder, so this is another one of those "free quality upgrades".
＊QT7.2（07/07/上旬）が対応したとの情報有り。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#analysis
--8x8dctAdaptive spatial transform size. This will allow the encoder to choose from 8x8 dct in addition to 4x4dct. This must be enabled to use the i8x8 macroblock type as mentioned in --analyse. Note: Using this feature makes the stream fall into the High Profile category, so make sure decoders and player support High Profile, or at least this feature.
Trellis は RDO（Rate Distortion Optimisation、レート歪最適化）だ。これは常にRate Distortionが最適になるような計算をする。特定領域の画質を劣化させて、画質劣化がより目立ちそうな領域へbitを振り向ける。微調整と考えて良い。
--trellis 1はマクロブロックの最終エンコード時のみtrellisを使う。
--trellis 2は全てのモード決定時に使うので、よりbitを節約する事になり、ターゲットbitrateあたりの画質が僅かに向上する。
前提条件としてCABACが必要なので、CAVLCでは使えない。CAVLCを使うには--no-cabacが必要だ。CABACはデフォルトで適用され、CAVLCに対して概ね10%ほどbitrateを節約できるがややデコード負荷が上がる。
＊ --deadzone-intra/interに優先する。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#analysis
--trellisTrellis is RDO, Rate Distortion Optimisation. It attempts to always make an optimal decision for Rate Distortion, and it lowers quality in some areas which will free up bits that can be used in more noticable areas if it considers the loss to be worth it. Think of it as fine tuning. --trellis 1 enables trellis on the final encode of a Macroblock, whereas --trellis 2 is enabled on all mode decisions, and therefore stands to save more bits which when using a target bitrate can lead to slightly higher quality. It requires CABAC, so it will not work with CAVLC. To use CAVLC instead of CABAC, --no-cabac must be specified. CABAC is enabled by default and gives you approximately 10% bitrate saving over CAVLC, but requires a little more CPU power to decode.
＊このオプションを指定すると「量子化の丸め制御を RD が最適になるように MB単位で自動的に決定する」という処理が有効になる。また --deadzone-intra/inter オプションは無視されるようになる。
＊--deadzone-intra/inter オプションは、丸め方法を四捨五入と切り捨ての間で 32 段階 (0 を指定すれば四捨五入になり、32 を指定すれば切り捨てになる) で調整するためのもの。
＊デコーダには依存しないので、プロファイル/レベルと無関係に何時でも指定することができる。
＊問題は単純な丸めオフセットを設定するだけの --deadzone-intra/inter と比べると（＊エンコードの＊）処理が非常に重くなってしまう事。
・-t CABACのサーチにオプションをつける感じ。
ループフィルタを排除するよりCABACを排除したほうが、実は軽くなる。
だが、画質がh.264規格っぽくなくなる。
逆に、-tオプション加えると、容量辺りの絵が良くなる。 が、エンコもデコードも重くなる。
x264はPフレームのスキップ判定（マクロブロックタイプ・スキップ）を早い段階で行うが、それを切る。
速度が低下する代わりに青色の領域（空など）でブロックノイズが減る。
他の青階調ブロックノイズ対策としてはHaaliの作った適応的量子化機能（＊）があるので、もし--no-fast-pskipでうまくいかなかったらそちらを使おう。
＊Win, Sharktooth版固有の--aq-strength, --aq-sensitivityの事と思われる。公式SVNには存在しない。http://agehatype0.blog50.fc2.com/blog-entry-156.htmlを参照。
http://aflux.deltaanime.net/Zero1/MP4/x264.html#analysis
--no-fast-pskipNo fast P-skip will disable early skip detection on P-frames. At the cost of encoding time, this should help reduce or eliminating blocking in blue areas (such as skies). The Adaptive Quantisation feature by Haali was designed as a workaround for blocking in blue areas, so if --no-fast-pskip doesn't help much, you should try Adaptive Quantisation.
低レート (高 QP) で平坦な場所にノイズが乗ることがあるのを防ぐために追加されたオプションということになっている。ただ、実際にはどんなノイズが出るのか知らない人も多いと思うので実例を、、、と言う事で実例のflvが見れる。
＊青空の前を小枝がパンしてゆく映像だが、枝の末端がちぎれたりくっついたりしている。青背景に茶色の枝（輝度が全然違う）でこういう事が起きると言う事は、もっと輝度差の少ない部分、闇階調のグラデーション等は相当厳しくなるはずだ。
・はやい段階で、Pフレームを省略させないフラグ。
高圧縮させるために、Pフレームを積極的に省略していました。
それを防ぐオプション。
画質がちょっち上がります。が、容量は少し太る。
Pフレームの係数切り捨てを切る。
との事。合わせてこちらも参考に → 2007/06/27（水） H.264 エンコーダでの DCT 係数間引き処理：http://www.marumo.ne.jp/db2007_6.htm#27
雨のシーンで、雨が消えないようになる感じの効果が出ると思います。
漏れ的に、オススメオプション。
Wiener フィルタを使ったDCTドメインのノイズリダクション。AVISynthの相当品より高速で、実用範囲は100-200。
H.264規格に存在しないが素材の圧縮工程に入る前に適用するので、再生機器やデコーダの機能とは関係なく使える（たんにAVISynthでフィルタをかけるようなもの）。
＊訳注：AVISynthの相当品
http://aflux.deltaanime.net/Zero1/MP4/x264.html#analysis
--nr--nr is DCT domain noise reduction using a Wiener filter. This should be faster than an equivalent AVISynth filter. Useful values are 100-200. It is applied to the source before compression, and isn't a part of the H.264 standard, so it doesn't increase playback requirements or need any additional decoder functionality (it's just filtering, similar to what you could do in AVISynth).
・--nr defaultでは、使われない。
mplayerのソレやAvisynthのHQDN3Dと似てる効果が得られる。
100～1000程度が使える数値かと思われ。
HQDN3Dもそう重くないので、x264のNRを使う理由はコレといってない。
また、逆もいえる。x264の--nrは圧縮時間に響かなく、軽い。使わない理由も無い。
＊コレより先に--deadzone-intraを弄るべき。なので次の項を参照。
＊--trellis指定の際は無視される（まるも製作所：2007/07/07（土） x264 [12] --trellis：http://www.marumo.ne.jp/db2007_7.htm#7）
--deadzone（intra/interとも、以下同） は高ビットレートでディテイルのレベルを上げる。具体的にはノイズやフィルムグレインなど。「些細な」情報をどのくらいまで切り捨てるかを指定するもの で、そこで節約したbitをもっと重要な部分に振り向ける。低いほどオリジナルの情報を残そうとするが、レート不足の際は全体を強く圧縮することになる。
高くすると見た目はクリーン・スムース・デイティルが減る。
低くすると見た目はノイジー・クッキリ・デイティルがきっちり。
Deadzoneはqpあたりの画質（quality-per-qp）に影響する。理想的なデブロック強度は画質に依るべきだが現実のデブロック 強度 （H.264規格に従ってx264が実装しているもの）はqpに依拠している。したがってもしquality-per-qp（＊Deadzone調整でこ れが変る＊）を調整すれば、デブロック設定も弄るべきケースが出て来るだろう。しかし、デブロックの調整単位は非常に粗い。もしdeadzone設定を全 て0にしたとしても（推奨しない）、デブロックの下げ幅は1程度が相応だ。逆にdeadzone設定を全て32にしたなら、デブロック調整は1上げる程度 が見合っていると思う。
ビットレートと適切なDeadzoneの間には特段の関係が無い。Deadzoneはrate-distorion最適化の値で決まるので、画質 変化は 全てサイコビジュアル（人間の視覚特性）によるものだ。具体的な推奨値を上げられるほどテストされていない。
また、--trellis指定の際は無視される。理論上はlambdaを改造すればtrellisと両立できるが実装はまだだ。
＊基本的に高bitrate高画質を意図 したオプションだが、デノイズに使えるかも知れない。手許の地アナでは稀に一律に酷いノイズが載る事があるので。
--deadzone to increase detail level at high bitrates. Noises, filmgrain another misc. details
Just to give people a bit more of an idea of what deadzone does; Deadzone determines how much "insignificant" information is droped. Higher values of deadzone help avoid artifacts by eliminating useless information at lower bitrates, and freeing up the bitrate that information would have used - to keep more important information with better quality. Lower values preserve more of the original source information, but to reach a given bitrate that information will have to be compressed more then if a higher value of deadzone was used.
Higher values of deadzone will give a cleaner, smoother, less detailed look, while lower values will give a noisier, crisper, higher detail look, similar to older mpeg varients.
Edit: updated the description of deadzones effect, after
preliminary
testing 6 seems to have about the same detail preservation as Xvid.
Theoretically, the deadzone switches could apply to trellis too by modifying lambda, but that hasn't been implemented yet.
Deadzone affects the quality-per-qp. Optimal (absolute) deblocking strength depends on quality. Actual deblocking strength (as defined by the standard and set by x264 options) is relative to qp, not relative to quality. So if you change quality-per-qp, then you might want to modify the deblocking setting.
However, the units of the deblocking setting a pretty coarse. So even if you set deadzone all the way down to 0 (not recommended), the compensating change would be to reduce deblock by at most 1 (compared to whatever deblocking you were previously using with the default deadzone).
Conversely, if you increase deadzone all the way up to 32, I expect the optimal deblock setting to change by at most +1.
There is no particular relationship between bitrate and optimal deadzone. Deadzone is already specified relative to the rate-distorion optimal value, so any changes are psychovisual, and not well enough tested yet to give a definitive recommendation.
＊x264 の --deadzone-intra / --deadzone-inter オプションは、量 子化の際に 1 未満になる数字を、どうやって丸めるかという基準を設定するためのものだ。最小値の 0 を設定した場合は、量子化後のレベル基準で 0.5 以上を 1 へと切り上げ、0.5 未満を 0 へ切り下げる 4 捨 5 入の処理になり、最大値の 32 を設定した場合は 1 に満たないものはすべて 0 に切り捨てる処理になる。
＊trellisは「量子化の丸め制御を RD が最適になるように MB 単位で自動的に決定する」という処理が有効になる。また --deadzone-intra/inter オプションは無視されるようになる。
--deadzone-intraを減らすと、質が上がる感じを受けた。…ただし、容量は莫迦増える。
CQMはカスタム量子化マトリクス（Custom Quantisation Matrix）。
量子化マトリクスは格子状にならんだ数字（＊数学で言う行列＊）で、個々の数字をquantum（＊量子/量子化マトリクスの値＊）として扱う。この個々
の数字が元の映像データをどのくらい破棄するかを決める。個々の数字が大きなマトリクスは映像がソフトになり、小さなマトリクスは映像のディテイル保持率
があがる。x264のデフォルトは "flat 16"
マトリクスを使う。これは全ての数字が16で埋まっているもので、デコードの際に特別な扱いが不要なものだ（＊Main
Profile以下＊）。カスタム量子化マトリクスはHigh
Profileの機能で、実際にはデコード負荷は増えも減りもしないのだが、デコーダ側のサポートが必要となる。XviDのカスタム量子化マトリクスを覚
えている人もあるだろう。大半のケースでデフォルトのH.263量子化で充分だったが[*1]、x264でもflat
16で充分な場合が多いと思われる。しかし中には高周波領域に高い係数が入ったマトリクスを使いたい事があるかもしれない。細かいディテイルがややスムー
スになり圧縮しやすくなる（＊ノイズなどの細かい部分を潰せる＊）。
--cqmはデフォルトのflatマトリクスか、jvtマトリクスの選択。
flatマトリクスは数字が全て16で埋まっているもので、jvtマトリクスはH.264規格の技術的な作業に当ったJoint Video
Teamが作ったものだ。このコマンドは外部ファイルを用意する必要が無いので使い易い。
＊手許ではXviDのMPEG量子化マトリクスはブロックノイズが激減した記憶がある。
CQM is the abbreviation for Custom Quantisation Matrix (or Matrices). A quantisation matrix is made up from a grid of numbers and each one is referred to as a quantum. It is these numbers that define how image data is discarded. A grid with large quantums will produce a softer image, and a grid with lower quantums will retain more detail. x264 by default uses a "flat 16" matrix, which is simply a matrix with all quantums set at 16 and does not require any special decoding. In contrast to this, custom quantisation matrices are a high profile feature and require special decoding support, though the actual decoding of them should require no more or no less resources. You might remember custom matrices from XviD, for most cases the default H.263 quantisation type worked fine, and in the case of x264, flat 16 is probably fine most of the time. In some cases you might want to use a matrix with a lot of high quantums in the high frequency co-efficient areas so that fine details become smoothed slightly and easier to compress.
There are numerous ways to define what CQM you want to use, here are the options available:
--cqm <string> (Presets=jvt, flat)This allows you to select the flat matrix (which is default) or the included JVT matrix (the matrix produced by the Joint Video Team, who is a joint partner in H.264). This is fairly simple to use and the matrices are included in the x264 executable so no external files are required.
■まるも製作所
・2007/06/22（金） H.264 での量子化処理とか量子化行列とか：http://www.marumo.ne.jp/db2007_6.htm#22
■覚書（なるPさん）http://www.geocities.jp/encmemo5whf6jvag8/index2.html#06-02
・cqm アナライズさせるのに使うマトリクスの指定。
x264内には、flatとjvtの2つのプリセットが入っている。
default値は、flatで全部16で埋まってるマトリクスを使っている。
全ての--cqm系オプションに優先。
カスタム量子化マトリクスを使うならおそらくこのオプションが最も実用的で、マトリクスを外部ファイルから読み込むものだ。読み込むファイルはJM（リ
ファレンス・エンコーダ）互換形式でなければならない。マトリクスファイルはDoom9で入手できる。
This option is probably the more practical of the rest when wanting to use a custom matrix. This will allow you to load an external matrix file. The file must be JM compatible (JM is the reference encoder). You can find a collection of external matrix files here at doom9.
全ての4x4量子化マトリクスの指定。
カンマで区切った16個の整数。実験には良いがコマンドがやたらと長くなる。特に他の量子化マトリクスも使う場合は厳しいだろう。
Sets all 4x4 quantisation matrices. The input must be a comma seperated list of 16 integers. This might be good for experimenting but your command line could quickly become very long, especially when defining other quantisation matrices as well.
全ての8x8量子化マトリクスの指定。カンマで区切った16個の整数。
As before, but this sets all the 8x8 quantisation matrices. This must be a comma seperated list of 64 integers.
輝度と彩度の量子化マトリクス。
Allows you to set luma and chroma quantisation matrices.
個々のカスタム量子化マトリクスの指定
Allows you to set the individual quantisation matrices.