ageha was here

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

ホーム > x264(r600)コマンド対応

TAG：x264-r600コマンド対応について

TAG:x264-r600コマンド対応について

本タグを持つエントリは、MEncoder -x264encoptsの06/10月改訂を受けてMPlayer and MEncoder on MacOSXの改訂作業の一環として行うものです。目標はMEncoder -x264encoptsの見直しです。内容は正確とは限らず、予告無く追記、削除する可能性があります。

　ひらたく言うと、自分の設定を一から見直すついでに人様からコメントを貰おうというコンタンです。

A. 本タグを持つエントリは以下のコマンド対応表です。

x264 --longhelp（core:54 svn-600M）
man mencoder 内、-x264encopts（dev-SVN-r20806）

B. 各コマンド解説に以下の内容を試訳・併記してあります。

Encoding H.264 using the x264 Command Line Interface（Zero1氏によるアニメ向けx264cliコマンド解説、svn408ベース）
MEncoder Document内、Encoding with the x264 codec（試訳アリ）
MeGUI2.0 Help試訳（ContextHelp v0.2 06/01/22）

C. 設定例として、以下の内容を併記します。

手許の常用値（地アナMPEG2キャプチャ。アニメ、落語、映画共用）
アニメエンコで役に立つかもしれない覚書（地アナhuffyuvキャプチャ?。アニメ）

　 C.2の書き手さんには無断で内容を一部転記してますが、平にご海容賜りたい。もしも覚書充実のお役に立てば幸いであります。 winに特化した部分は自分には手が出ませんし、手許ではx264cli自体使ってないですから。

スポンサーサイト

[ 2006/11/26 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(2)

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倍以上の長さであり、技術的内容の密度も高くなっています。その様子は、折り紙作品に似ています。単純な基本コンセプトを幾層にも重ねることにより、新たな高度の造形に至っていて、これは注目に値する成果だと確信しています。

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

■参考記事

[ 2006/11/30 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(0)

1.1. Frame-type_GOP関連

理由へGo！

Frame-type_GOP関連オプション

x264cli (rev600準拠)	MEncoder -x264encopts (dev-SVN-r20806準拠)

I, --keyint <integer>

keyint=<value>

■まとめ：240 or 300

　一般的には出力fpsの10倍（10秒ぶん）。
　ここは一般的な値を入れておくのがベスト。なぜならx264内部がそれを想定したチューニングになってる公算が高いからだ。このオプションの第一目標はあくまでシークポイントの作成。画質に関係なくもないが本来の目標では無い。これをいくら大きくしてもシーンチェンジがあるかぎりI/IDRは自動的に入る。逆に小さくすればI/IDR挿入が過剰になるリスクがある。これはP/Bに回るbitを減らし総合的な画質劣化を呼ぶ。わざわざここを弄る人は少ないから設定を比べにくくなるのも痛い。

　しかしもし、シークなど無用！断然画質追求あるのみだ！という場合は無限大を試してみよう（30分素材なら6000とか）。少なくとも数値的にはそれで「望み得る最善画質」に近づける。あとは他のGOP関連オプションを弄って必要最低限のI/IDRを場面転換点だけに間違う事無く正確に突っ込む手を探してさまようがいいわ。
　深入りしたくなければ一般的な値を。

■参考

覚書（要約）: 240 or 300; GOP単位関係はデフォルトではなく自分仕様に変更した方が、いいかと考えられる。

手許: 240 or 300

MeGUI2.0 Help（ContextHelp v0.2 06/01/22）: keyint name="Maximum Key Frame Interval"; 推奨250; default250; Group of Pictures(GOP)の最大長を指定。GOP は他のGOP中のフレームを参照できない。また、シークやランダムアクセスをする上で必要なもの。; GOPサイズは符号化効率を優先してエンコ過程で動的に算出されるものだがmaximum GOPを指定してやればシークのやり易さを維持することができる。

man MEncoder: IDRフレームの最大間隔[250]; 大きい値の方がbitが節約できるので品質が向上するが、シークの精密さと引き換えになる。; MPEG-1/2/4とは違って、 H.264はkeyintを大きくしてもDCT driftで苦しむ事が無い。; （＊DCT driftの意味不明＊）

zero1(svn408): Usage: --keyint <integer> (default=250); 最大GOP値の指定。; 新しくIDRが入るとそこから新しいGOPが始まるが、その前に存在しても良い（＊IDR以外の＊）フレームの最大枚数を指定する。; 　Xvidで言う "Maximum I-frame Interval"に相当するだろう。; 　一般的にはシークを重視して10秒分のフレーム数にする人が多いようだ。; 　25fpsのPALなら --keyint 250、23.976fpsのNTSCなら、まぁちょっと丸めて--keyint 240(*1)。; 　新しいGOPは、--keyintの指定値を超えていない限り、通常はシーンチェンジからスタートする。; 　だからこのオプションが作動するのは場面転換の無い長回しや映像に大きな変化があった場合だけだ（アニメではほとんど無いと言って良い）。

MEncoder Doc: : keyintはシークのやり易さと符号化効率の取引です。他の目的はありません。デフォルトのkeyintは250にセットされています。25fps素材では、これで10秒精度のシークができるようになります。5秒精度のシークが重要と考えるなら、keyint=125。ビットレートあたりの品質は僅かに落ちます。品質だけが重要でシークのやり易さを問題にしないなら、もっと大きな値にできます（値を大きくすればするほど、効果は漸減します。無視できるほど小さく、あるいは0にもなり得ます。）それでも、ビデオストリームにシーンチェンジがある限り、そこがシークポイントになります。

-i, --min-keyint <integer>

keyint_min=<1-keyint/2>　※式の意味不明、入力値は整数

■まとめ：素材映像に応じて調整

　絶対安全策は0か1。ドラクエでいう「がんがんいこうぜ」。
　このオプションを0にすると言う事は、必要なら連続したIDRフレームを作っても良いよという事（最小GOP単位の制限をはずす）。だから非常に短い間隔でぽんぽん場面が切り替わる映像、例えばアニメのオープニング・コマーシャル・画面全体を覆う光の明滅（禁止だけど）などで、x264が「あ、ここにI/IDR入れたいな」と思った時に制限がかからない。これだけでも結構ブロックノイズ削減効果がある。実際にはx264はなかなか賢く、手許の実験では連続IDRはできなかった。充分な実験とは言えないが、0や1が複数参照（frameref, --ref）の手足を縛る心配はあまりしなくて良いと思う。一般的にアニメはこれでも足りないから次のscenecutも上げて行こう。

　しかしながら。実写ではたくさん入れれば良いというものでは無い。例えば落語。場面転換など無いから「がんがんいこうぜ」ではキモノの質感などにうまくbitが回らない（常用は640x480,1024kbps）。アクションシーンなんか無いだけになおさら目立つ。「x264の実写はイマイチ」と言う意見の中にはアニメ向け設定を実写に使っているケースもあるのじゃないだろうか？アニメだってのほほ～んとした場面が多いもの、例えば『僕等がいた』では無駄なI/IDRを削ってもっと小さくできるハズだ。

　ようするに、このオプションは次のscenecutとセットで試行錯誤を要する。
　少なくとも実写全般向けとアニメ向けの２セット。現実的には自分の録画傾向に合わせたクリップを用意して実験すると良いだろう。一分程度のもので傾向は充分に掴める。下記の参考値を土台に適正値を求めてさまようがいいわ。
　この事は、必要です。

■参考

覚書（要約）: アニメ：1 or 8; 前項参照。; ※ffdshowの機能を使った視覚化実験の結果、上記に落ち着いた模様。; ※8の根拠不詳。3コマ撮り？

手許: アニメ：0 or 1
実写：24 or 30; 特にアニメで24/30は禁物。ブロックノイズでApple-H.264どころかxvidにも劣り得る。
これは0 or 1と下記のscenecut調整でほぼ根絶できている。; その後、MovieVideoChartとx264 1st passのログを用いて実験：
このオプションだけでもIDRは増えるが効果は微弱で、scenecutの方が影響大。0 や 1は複数参照に影響してbitが無駄になるのではと思ったが、I/IDRが連続するケースは無かった。素材はケロロ軍曹のオープニング（なんでもかんでもやりましょう♪）比較的厳しいほうだと思う。; だから、0 や 1でも複数参照（frameref, --ref）の手足を縛る心配はあまり無さそうだ。

MeGUI2.0 Help（ContextHelp v0.2 06/01/22）: min-keyint name="Minimum Key Frame Interval"; 推奨25
default25
Group of Pictures(GOP)の最小サイズを指定。GOP は他のGOP中のフレームを参照できない。また、シークやランダムアクセスをする上で必要なもの。GOP sizeは、効率的に符号化するためにエンコード過程で動的に算出される。しかしながら、minimum GOPの指定はハイモーションシーンの圧縮の助け（＊help improve compression＊）となる。

man MEncoder: IDRフレームの最小間隔を指定(default: 25)。; この最小間隔の中にシーンチェンジが含まれた場合、Iフレームは生成するものの新しいGOPを生成しない。; H.264では、Iフレームはclosed GOPの区切りとは限らない。; なぜなら、Pフレームを直前より前のフレームを基に予測しても良いからだ (framerefも参照)。この為に、Iフレームは必ずしもシーク可能では無くなった。; IDRフレームは、後続のPフレームに、自分より前にある全フレームを参照禁止にする。

zero1(svn408): Usage: --min-keyint <integer> (default=25)
　最小GOP値の指定。
　新しいIDRを挿入して新しいGOPを開始する前に存在しても良いフレームの最小枚数を指定する。
　 --min-keyint指定数の間にシーンチェンジがあった場合、場面転換の開始フレームは単にIフレームとなるだけで、新しいGOPを開始しない。

MEncoder Doc: 前項参照

--scenecut <integer>

scenecut=<-1-100>

■まとめ：素材映像に応じて調整

　絶対安全策は無い。残念ながら。
　さらに感覚的な話でもうしわけないが、デフォルト値40は実写向けオールラウンダーな印象がある。上げすぎない方が良い。
　このオプションはkeyint_min（--min-keyint）より遥かに応答性が高く、ピーキーだ。弄った時の効果が目で解り易いので頼りがちだが、そのぶんI/IDR過剰にも陥り易い。実際にはここでもx264はなかなか賢く、場面転換の無い落語ではそうそう増えない。むしろ下げてもいいくらいだ。
　アニメではデフォルト40じゃまるで足りないのでぐんと上げて行こう。

　なお、下記ではscenecutが挿入するものを「追加的なIフレーム」と呼ぶケースが多い。これはGOPの単位となるIDRでは無く、Xvidで GOPの単位だったIフレームとも異なるという意味だ。で、ありながら、実験ではこれを上げると「追加的なI」よりIDRが増えた。てゆうか他の設定で「追加的なI」だったものが IDRに化けた。内部でframeref（--ref）設定値なども参照して調整しているかもしれない。

　このオプションは上記のkeyint_min (--min-keyint)とセットで試行錯誤を要する。
　少なくとも実写全般向けとアニメ向けの２セット。この事は、必要です。

■参考

覚書（要約）: アニメ：最低60は欲しい。
アニメOP：75程度; --scenecutは、数が大きければ、キーフレームを積極的に入れるようになる。逆に、減らすとキーフレームを入れないようになる。
defaultではキーフレーム挿入が、少し控え目ってことですね。

手許: 手許では
アニメ：一律55
実写：一律40(デフォ); Xvidの経験則が通用しないオプション。
追加的なIフレームだけでなく、IDRも増える。
自分の素材傾向に応じて要テスト。

MeGUI2.0 Help（ContextHelp v0.2 06/01/22）: scenecut name="Scene Change Sensitivity"; 推奨40
default40

場面転換の検出精度の調整。シーンチェンジ・ディテクションは場面転換の際にIフレームを挿入し、見た目を向上させる。

man MEncoder: 　追加的なIフレーム挿入を決断する際の積極性(default:40)。
scenecutの値が低いと、このコデックはしばしばkeyint間隔よりも大きな間隔でIフレームを入れてしまう。
scenecutの値が適切なら Iフレームはもっと良い位置に挿入される。
大きすぎる値を使うとIフレームを必要以上に入れてしまい、bitが無駄になる。

-1 は自動シーンカット検出を無効にする。従ってIフレームは、たとえ場面転換があろうとも、keyint frame間隔毎にしか挿入されない。これはオススメできない。なぜなら、この場合に場面転換地点で生成されるPフレームはIフレーム同然にサイズが大きくなるのでビットレートの無駄だし、その上"keyint counter"にもリセットがかからないからだ。

zero1(svn408): Usage: --scenecut <integer> (default=40) [1 - 100]
　追加的なIフレームを挿入する際の閾値。
　高い値にすると必要以上にIフレームを挿入する傾向が高まる（言い換えるとbitが無駄になる）。例えば、映像中に相当な変化があるが場面転換と判断するほどでは無いような場合だ。
　低い値にするとIフレームはあまり使わず、最終的には--keyint値に頼って最適なIフレーム挿入をしない傾向になる。例えば、Iフレームの代わりに非常に巨大なPフレームが入るとか（Pのデコードには先行するI/Pのデコードが必須だ）。

MEncoder Doc: 上記参照。

■参考記事

[ 2006/11/30 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(4)

1.2. Frame- type_Bフレーム関連

概説

MEncoder Document：x264コデックでのエンコード

　他のコデックでのエンコードに慣れている人の中には、B-frameは必ずしも有益とは限らない事をご存知の方もあるでしょう。H.264ではこの常識は異なります。 B-frameで使える新しい技術とブロックタイプができました。一般的に、単純なB-frame選択アルゴリズムでさえ、目覚ましいPSNRゲインが得られます。また面白い事に…

　Bフレームを2以上にすると適応的Bフレーム（b_adapt）、Bフレームの参照化（b_pyramid）、bime、brdo、weight_bなどの活躍余地が増え、全体的な圧縮効率が向上します。順序としては、まずBフレームに適さないコマをb_adaptが選り分け、残ったBの中にb_pyramidが参照関係を構築する、そして基幹部のB生成工程にbime、brdo、weight_bが取り付いて無駄なbitを削りとる。この連携がx264の花。ゴミのようなオプションを山のように積み上げるH.264/AVCの本領です。それぞれの効果は相関関係にあるので「こうすれば良い」とは書きにくく肚に落とすのはちとホネですが、把握する価値はあります。

　最大Bフレーム数が1以下のApple-H.264は、この連携効果を発揮できません。練達の騎兵師団に下馬を命じて拠点防衛に回すようなものであり、High Profile非対応などよりはるかに問題です。

　ただし、少なくとも MEncoderでは若干のデメリットがあるようです（decoding delay）。

Frame-type_B フレーム関連オプション

x264cli (rev600準拠)	MEncoder -x264encopts (dev-SVN-r20806準拠)

-b, --bframes <integer>

bframes=<0-16>

■ まとめ：2～３。1にするなら後述の適応的Bフレームを切る事。

　デメリットはB使用で映像冒頭に指定値に応じた数の delay frameが入る事（手許欄参照）。
　VfW系ではこれをDropできるフロントエンドが存在するようだ。
　AviSynth to x264cliルートは不詳ではdelay frame問題は発生しない（コメント欄参照）。

　なお、規格上は双予測（Bi- Predictive、前後問わず2 枚を参照）だが、x264は双方向予測（Bi-directional Predictive、前後各1枚を参照）の模様。根拠は各文書の用語がBi-directionalで統一されている事。

■参考

覚書（要約）: 常用値不詳

手許: 常用3; B使用で冒頭に指定値に応じた数のdelay frameが入る（参考）
QTPlayer では再生のみOK（B使用、Main Profileで作成の場合）。
ただし開始点からのシークで問題が出る。一旦再生スタートして delay frameを過ぎればシーク可。QTインフラ上での再加工（音声貼付けなど）は一切不可となる。部分的に規格外のVideo Streamと思われる（VFRのできるコンテナでnull frame受け付ける意味無いから）。

これはMEncoder/ffmpegを使う限り不可避。esperanceは内部的にdelay frameをドロップする。virtualdub(mod)はXvid.avi時代からドロップしていた模様。x264cli不詳ではこの問題はない。

MP4box に渡す前に正確に発見、除去する手段が欲しいところ。

デフォルト=0の意味は、そのへん理解して使ってという意図、VfWベースのフロントエンドに対するフールプルーフ、Baselineへの配慮、などが考えられる。

反面、B関連の向上はH.264の目玉の一つ。
手許では1年程Bフレームは1～3で作っているが、実用上delay frameと思しきa/v desyncは知覚できていない。可能性としてはフレッド・アステアのミュージカル映画など、A/V Syncが死活的に重要な素材で問題があり得る。

bit を有効に使いたければ使うべき。

MeGUI2.0 Help（ContextHelp v0.2 06/01/01）: bframes name="Maximum B-frames"; 推奨2～3
default0

双方向予測フレームは高圧縮。前フレームからの変化か、後フレームとの差しか保存しないから。Bフレームは一般的にIやPよりも画質が悪いが、全体の符合化効率が向上するのでビデオ全体の画質は向上する。一般的には2か3で、ベストな画質と目覚ましい圧縮効率になる。

（＊双方向予測フレーム=Bi-directional Predictive Frames＊）

man MEncoder: IとPフレーム間でのBフレームの最大連続数。(default: 0)

zero1(svn408): Usage: --bframes <integer> (default=0) [0 - 16]; I とPフレームの間でのBフレームの最大連続数を調整する。
Xvidや他のMPEGエンコーダでBフレームには慣れている人は多いと思う。
Xvid でこれに相当するオプションは"Max consecutive B-VOPs"。
Bフレームは符号化効率の観点からは非常に良いものだが、たくさん使う程デコード負荷が上がる事を心に留めておく事。

MEncoder Doc: 　他のコデックでのエンコードに慣れている人の中には、B-frameは必ずしも有益とは限らない事をご存知でしょう。H.264ではこの常識は異なります。B-frameで使える新しい技術とブロックタイプができました。一般的に、単純なB-frame選択アルゴリズムでさえ、目覚ましいPSNRゲインが得られます。また面白い事に、B-frameを使うと通常2ndパスが若干高速化し、adaptive B-frame decisionを切った場合はシングルパスも高速化する事があります。

　adaptive B-frame decision がオフの場合(nob_adapt)、一般的な最適値はbframes=1以下です。他の場合動きの多いシーンで画質劣化が起きます。adaptive B-frame decision がオンの場合は(default)、もっと大きな値を使っても安全です。圧縮を妨害しそうなシーンでエンコーダが B-frame の使用を控えます。エンコーダが3や4以上の B-frameを使う事は滅多にありませんから、それ以上の値を指定しても効果は薄いです。

--no-b-adapt

(no)b_adapt

■ まとめ：Bフレーム2以上ならオン。1なら特に理由が無い限りオフにすべき。

　Bフレームに適さないコマを発見し、フレームタイプをPにする（IにするかどうかはGOP 関連設定で決まるのだと思う）。
　フレームタイプは1stで決まるので2ndやNthパスでは指定しても意味が無い。
　印象としては非常に強力で、IPPPやIBPP連発。IBBBはかなり少ない。フェードだらけなど weight_bのメリットが高そうな素材では切った方が良いケースもあり得る。マニアックにいくなら次の b_biasでこの強度を調節できる。

■参考

覚書（要約）記載無し	手許常時使用
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） no-b-adapt name="Adaptive B-frames" 推奨：Enabled default： Enabled B フレーム挿入の際に定数ではなく、x264に挿入枚数を必要に応じて決めさせる。 Bフレームが不適当な箇所で Bの連続数が減る。	man MEncoder bframes=< 0-16>で指定された最大Bフレーム数の範囲で、いつ、どれだけの数のBフレームを使うか自動的に決断する。オフの場合、前述のbframes=<0-16>(デフォルトで0)の最大Bフレーム数を使用する。
zero1(svn408) Usage: --no-b-adapt (default=on) 　このオプションは適応的Bフレーム挿入をオンにするもので、一般的にはお奨めできない。このオプションを使うと（デフォルトはenable。--no-b-adaptで切る）x264がどこにどれだけのBフレームを使うか自動で決める。（＊最大？＊）何枚使うかは上記の--bframesで決まる。（＊:Zero1氏の記述根拠不明。下記とも矛盾。未推敲箇所と思われ。＊）	MEncoder Doc : Note: defaultでオン。　このオプションを使うと、エンコーダはまずまず合理的な速度で、B-frameの効果の薄いシーンのB- frame数を減らす計算をします。b_biasを使って、間引く程度を調節できます。adaptive B-frameの速度低下は目下のところは慎ましいものです。しかし望み得る画質向上の程度も同様です。まぁ、通常は害はありません。1stパスの速度とフレームタイプの決定にしか影響しない事に注意して下さい。b_adapt と b_bias は後続のパスにはなんの影響もありません。

--b-bias <integer>

b_bias=<-100-100>

■ まとめ：素材映像に応じて調整 or 弄らない

適応的Bフレームの強度調整。
デフォルト値の印象は非常に強力で、Bフレーム3でもIPPPが頻発する。IBPPやIBBPも多く、IBBBP（Bフレーム3ならそうあるべき）は存外に少ない。
本来は映像内容に応じて調整すべきものだろうが、これに手を出すには以下の条件が必要だ。
１） Bに適さない映像とはどのようなものかを知る事。
２）エンコード後の映像でどのコマがBかを正確に発見し、その画質を確認する手段（WinならMPCで正確なフレーム番号に飛べるようだ）。

■ 参考

覚書（要約）言及未発見	手許常用0(default) default の場合、 Bフレーム=3でも結構0～2連続が多い。これは最大Bフレーム数を16などとしても安全だと言う事だ。それで削れるbitは文字通り片手で数えられるレベルと思うけど。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） b-bias name="B-frame Bias" 推奨：0 default： 0 プラスの値でBフレームの使用傾向が強まる。マイナスは使用を控える。"Maximum B-frames" の設定値は超えない。	man MEncoder b_adapt の「決断力」の強さを設定する。高い程沢山のBフレームを使う。 (default: 0).
zero1(svn408) Usage: --b-bias <integer> (default=0) [-100 - 100] 　適応的B フレームの挿入に影響。高いほど、指定された最大値までの範囲で、Bフレームを沢山使う。低い値では減る。　Xvid でのB-VOP sensitivityに相当。　-100から+100までのスライダがあると思えば良いだろう。-方向がB を減らし、+方向がBを沢山使う。　推奨値はデフォルトの0のまま（スクリプトに書かないのと一緒）。というのはB使用を強制すると画質が悪くなる事があるからだ。特に暗い領域やフレームで多い。	MEncoder Doc 言及無し

--b-pyramid

(no)b_pyramid　＊QT７非互換＊

■ まとめ：使わない場合はBフレームを1に。使用にはBフレーム数2以上が必要。

　Bフレームを参照フレームにすることで、Bが連続した場合の画質劣化を抑止。参照といっても参照（≒依存）関係は連続するBの内部に限られる。
　x264 のb_pyramid には内部的に複数参照に似たdepthという概念があり、最大で2。これはオプションでは弄れない。
　一応デメリットもあるので気にされる方は下記を読み比べて欲しい。

■ 参考

覚書（要約）言及未発見	手許常用オン。デフォルト不詳。Profile 不詳。 QT7非互換だが、Doom9氏の言う"Main対応と言うには不可解な制限"の一つか？これが無ければB推奨値は1。 b_pyramid には複数参照類似のdepthという概念があり、x264では2。これはオプションでは弄れない。従って最大 Bフレーム数は3が有効と思われ。 MEncoder・ x264cliを問わずデコーディング・ディレイが発生するようだが、実写・アニメとも知覚できた事がないので手当していない。Bフレームを使った場合の delay frameと合わせ3フレームはずれてる筈なんだが… なお、教科書などを読むと規格上はBを参照するPがあり得るようにも読めるが、ちょっとメリットを考えにくい。x264の実装で妥当と思われる。C読めないけど。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） b-pyramid name="B-frame Pyramid" 推奨：使用 default：非使用 B フレームに他のBフレームの参照フレームになる事を許可する。2以上のBフレームを使っている場合、符号化効率の向上になる。	man MEncoder Bフレームを参照フレーム～他のフレームが予測に使う～に使うことを許可する。例えば、連続したBフレームが3個あるとしよう I0 B1 B2 B3 P4 b_pyramidオプション抜きの場合、 BフレームはMPEG-1/2/4と同じパターンに従う。つまりこれらは I0 P4 B1 B2 B3 の順番で符号化され、全てのBフレームは I0 とP4 をベースに予測される。 b_pyramidオプション有りの場合、これらは I0 P4 B2 B1 B3 の順番で符号化される。B2は上記と同じだが、B1は I0 と B2 を、B3 は B2 と P4 をベースに予測される。この結果、速度低下抜きで圧縮率が僅かに向上する。しかしながら、このオプションはまだ実験段階だ。チューニングは未熟で必ずしも効果があるとは限らない。オプションの bframes=<0-16>は2以上でなければならない。デメリット：デコーディング・ディレイが2フレームになる。
zero1(svn408) Usage: --b-pyramid (default=off) 　Bフレームの一部を参照フレームに使う。　符号化効率の向上が望める。というのは、Bをもとに他のフレームを予測できるからだ。2以上のBフレームが必要で、2フレームぶんのデコーダ・ラグが生じ得る。デフォルトでは適用されず、コマンドラインに--b-pyramidを付加する必要がある。	MEncoder Doc : B-frameを2以上にする場合はこのオプションも使った方が良いようです。man pageにある通り、速度低下抜きで若干の画質向上が得られます。2005/03/05よりも古いlibavcodecベースのデコーダは、これを使った映像を読めない点に注意して下さい。

[ 2006/12/04 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(4)

1.3. Frame-type_その他

概説

　比較的効果が高いが議論にもなり易いオプションが固まっている。再生環境や CPUパワーに応じて選択すべき。特にframeref(-r. --ref)はsubq(-m, --subme)と並んで最も速度と画質への影響が大きい（遅いほど圧縮効率が良い）。参考元はどれもそれぞれの推奨値があるが、ここは特に自分のCPU と忍耐力に相談する必要がある。

Frame-type_その他のオプション

x264cli (rev600準拠)	MEncoder -x264encopts (dev-SVN-r20806準拠)

--no-cabac

(no)cabac（＊Baseline非互換＊）

■ まとめ：

　デフォルト：MEncoderはオン、x264cliはオフ。両者のスタンスの違いに注意。
　無劣化でbitrate10～15%削減。この工程はロスレスなのが魅力。
　重いと言う事なのでシングルG4、センプロン、セレロンでの再生となるとちょっと苦しいかも知れない。CABACが使えるのはMain Profile以上なのでiPodやPSP向けも要注意だ。

■ 参考

覚書（要約）（＊以下 trellisの記載から＊）ループフィルタを排除するよりCABAC を排除したほうが、実は軽くなる。だが、画質がh.264規格っぽくなくなる。 default では、 0 で使われていない。	手許 default=on、常用オン。 Doom9 ではApple-H.264はエンコで使っていないとしているが、確認手段不明。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） no-cabac name="Encode CABAC" 推奨：使用 default：使用 CAVACはビデオストリームのsyntax elementsをロスレスっぽく(＊losslessly＊)圧縮する賢いテクニック。映像内容に応じたelementsの蓋然性を使う。エンコード/ デコード共にCPU負荷が増える。dissableの場合はCAVLC (Context Adaptive Variable Length Encoding) を使う。CPU 負荷は少ないが圧縮効率は落ちる。	man MEncoder 　CABAC (Context-Adaptive Binary Arithmetic Coding)の使用 (default: on)。エンコード、デコードとも多少遅くなるが、ビットレートは 10～15%下がる。デコードの速度を求めるので無い限り、オフにしない方が良い。
zero1(svn408) Usage: --no-cabac (default=on) 　CABAC (Context-Adaptive Binary Arithmetic Coding) はエントロピー符号化。　マクロブロック情報およびそのヘッダ、テクスチャ、モーションベクトルを、情報ロス無しでより小さく符号化する。ビットレートにして約10%、アニメではもっと節約できる。　エンコード・デコードの負荷は増えるものの、画質劣化抜きでの10%減は目覚ましい進歩だ。	MEncoder Doc （＊frameref の注釈から＊） Note: CABACがオフの時にframerefを不必要に高い値に設定すると、符号化効率が落ちる可能性があり、通常、実際に落ちます。CABAC がオン(default)の場合、framerefを「高くしすぎる」心配はしなくても良いようです。将来的には、最適化によってこうした可能性は取り除かれるでしょう。

-r, --ref <integer>

frameref=<1-16>

■ まとめ：

3を使う人が多い模様。
規格上は multiple reference、複数参照と言われるが、不等距離参照とか自由距離参照とか適応参照とか…のほうが肚に落ちる。
直前よりももっと前のフレームを参照できるようにするもの。
値が大きいほど速度低下が激しく、効果も減って行く。時間軸予測の動き補償に効くものなので、実際の効果は映像内容に大きく左右される。
理屈の上ではkeyint最小値を下げすぎると影響を受け得るが、手許の実験ではあまり心配する必要は無さそう。

■ 参考

覚書（要約）・- r　Pフレーム・Bフレームの参照フレーム数距離。　参照するフレームが増えればP・Bフレームの出来は良くなるかも。ただし、圧縮時間が増える。　連続するBフレーム数を増やしたときは、この値も増やした方が、いいのかもしれない。　アニメは、コレ増やすと、絵の斬れが良くなる。3ぐらいを試してみたらどうだろうか。	手許常用4 ※1stでturbo= 1を常用しているので、要検証。 4は少し奢っている。最初は下記Docにバカ正直に6としていたが、だんだんダルくなって減らして来た（PowerMac G5、2Ghzx2）。手許では1stは一律にturboを使うが、リミテッドアニメに拘るなら1stも最低で3以上（３コマ撮り）にすべきだろう。放送は見込めないがオリジナルの鉄腕アトムなどではもっと増やしてもいい。ディズニーなどのフルアニメ（1コマ撮り）は動きに関しては実写同様に扱うべき。初めて理屈を見たときはJVTはアニオタの群れかと思ったが、実写でも効果があるようだ。 Doom9 コデックコンテスト2005の"時間のかかりすぎない設定"では4か3。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） ref name="Reference Frames" 推奨：1-5 default： 1 P/B フレームの参照フレームは通常「直前」だが、もっと前のフレームを参照フレームにするほうが符号化効率が良い事がある。その際の最大数。多くするほどエンコードは遅くなる。最大は16だが画質向上の程度は5を境に逓減してゆく。	man MEncoder P/B フレームは予測の際に自分より前のフレームを参照フレームに使う。H.264/AVCでは直前よりも前のフレームを参照フレームに使う事ができる。このオプションはその際、最大でどのくらい前のフレームを参照フレームとして使えるかを指定するもの(default: 1)。アニメには効果的だが、実写では6程度を境に効果が急激に低下する。デコードの速度には影響しないが、必要メモリ量が増える。デコーダによっては最大15までしか受け付けない。
zero1(svn408) Usage: --ref <integer> (default=1) [1 - 16] 参照フレームの数の指定。新しいP/Bの予測を、デコード済みフレームを遡って行う。範囲は最大で指定枚数ぶん。高い値ほど効率があがる。原理的にアニメに非常に効果的だ。というのはキャラクタが喋る時に、口だけが似たような動きを繰り返し、他の部分は変化しないような絵、とか、風になびく髪のように、同じ動きがループするような場面がよくあるから。	MEncoder Doc : frameref のデフォルトは1に設定されていますが、これはそれが妥当だからというわけではありません。framerefを2にしただけでもPSNRは0.15dB程度は向上し、速度低下は5-10%です。これは良い取引に思えます。frameref=3では、PSNRの向上はframeref=1に比べて 0.25dB程度、これは目で見て解る違いです。速度低下は15％程度。残念ながら、ここから効果は急減していきます（＊Unfortunately, diminishing returns set in rapidly.＊）frameref=6のframeref=3に対するゲインは僅か0.05-0.1 dB程度で、速度低下は15%です。frameref =6以上では、品質向上は通常、極めて僅かです（もちろん素材次第である事に留意して下さい）。典型的なケースでは、frameref=12のグローバルPSNRのゲインは、frameref=6より0.02db上がる程度、速度低下は15-20%。　ここまで高いframeref値になると、それ以上にしてもPSNRが下がる事は無い、くらいの事しか言えません。品質向上はやっとこさ計測できるくらいで、目で見て感じる事も難しいでしょう。　 Note: CABAC がオフの時に framerefを不必要に高い値に設定すると、符号化効率が落ちる可能性があり、通常、実際に落ちます。CABAC がオン(default)の場合、framerefを「高くしすぎる」心配はしなくても良いようです。将来的には、最適化によってこうした可能性は取り除かれるでしょう。　　速度を気にするなら、合理的な妥協案は 1stパスでは低いsubq と framerefを使い、2ndでそれらを上げる事です。一般的にはこれで最終的な品質に出る悪影響は無視できるほどのものです。：だいたいPSNR低下は0.1db以下に収まります。目で見てわかるレベルではありません。しかしながら、frameref値の変更は、時にフレームタイプの決定に影響を与えます。ごく稀な事ではありますが、慎重にいくなら素材映像に、I-frameを強制するようなフルスクリーンのフラッシュパターンの繰り返し（＊fullscreen repetitive flashing patterns.ポケモンのパカパカ？＊）やvery large temporary occlusion（＊非常に大きな時間軸の閉塞？＊）がないか確認して下さい。そして、1stパスのframerefをフラッシュのサイクルや閉塞の持続時間以上になるように調整します。例えば、3フレームに渡って2つの画像の間を行き来するようなシーンがあったら、1stパスのframerefを3以上にします。こうしたケースはライブアクション映像では極めて稀でしょうが、ビデオゲームのキャプチャでは時折ある事です。

--no-deblock

(no)deblock

■ まとめ：

別名ループフィルタ、インループフィルタ、インラインデブロック、などなど。
MPEG系で不可避のブロックノイズ対策をコデックの内部に埋め込んでしまおうと言うもの。詳細次項。

■ 参考

覚書（要約）・デブロックフィルタを、使わなくします。　--nfが、--no-deblockと名称変えました。　このオプションを使うと、デブロックフィルタを使用しないようにします。　デブロックフィルタ使ってると、細部が潰れるので気になるときがある。　そういう時は、コレ使ってデブロックフィルタ切ったほうがいいかもしれない。	手許常用on、詳細は次項参照
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） nf name="Deblocking (in loop) Filter" 推奨：Disabled default： Disabled MPEG-4 AVC は映像を移動データの矩形(＊おそらくマクロブロックのこと＊)で定義する。in loop deblocking filter はこの矩形のエッジを検出してスムーシングをかける。In loop deblocking はMPEG-4 AVCの通常の動作で、disableにすべきではない。	man MEncoder デブロックフィルタの使用(default: on)。品質向上に比べて時間低下は極めて僅か。なのでオフはオススメしません。
zero1(svn408) Usage: --nf (default=on) インループ・デブロッキングの停止。詳細は次項参照	MEncoder Doc 次項参照

-f, --deblock <alpha:beta>

deblock=<-6-6>,<-6-6>

■ まとめ：

賛否両論。デブロックを切ったり、強度を下げるならそのぶんbitrateを上げないとブロックノイズが出そう。くらいしか言えない。

■ 参考

覚書（要約）（＊前項から＊）　デブロックフィルタ使ってると、細部が潰れるので気になるときがある。　そういう時は、コレ使ってデブロックフィルタ切ったほうがいいかもしれない。	手許常用0,0（デフォルトまま）インループ・フィルタ、インライン・デブロック、などなど様々な名前があるが、コデックの中にデブロック・フィルタを取り込んだもの。ブロックノイズはMPEG系の宿命で、気にならなくてもJPEG同様に必ずあるもの。Xvidなど向けに再生時にデブロックフィルタをかける再生ソフトでは機能がバッティングする模様。　手許では切らず弄らず、下記Docの紫部分を根拠にI/IDR枚数を必要最小限に抑え込むアプローチを取っている。自分の理解が正しければ、これでI/IDRのQP値が地味に下がり、デブロックの起動回数を地味に減らせる筈だ。　アニメに関して。覚書では細部の潰れが気になる際には切るべきかもとあるが、Sharktooth氏の"アニメは3:3"というのは50%に及ぶ強化であり、妖精現実さんも"悔しいがアニメは奇麗"の根拠の一つにこのインライン・デブロックを挙げている。覚書氏は2000kbps 程度を常用されているようなので、ここが意見の差の原因かもしれない。そろそろx264のbpp表がどこかに出て来てもよさそうだが…。手許では1024kbps固定、電器屋さんの話では地アナの電波状態も悪い一帯らしいので、細部が地味に潰れると聞くとつい「使えるか？」と考えてしまう。　なお、Apple-H.264ではデブロックを切れず、弄れない。 bitrateを下げてゆくと、薄いガラス越しに見たような->薄い水槽越しに見たような->水刷毛で叩いてますか？->印象派の油絵。という感じで段階的に画質が変化する。これが"スミア"と思われる。画像全体がパンしてるようなとこを640x480、400kbpsくらいで油絵が見れるかと。効き始めは劣化というより「クリアパネル液晶を買った覚えはないですが？」というカンジ。意地でもブロックはお見せしませんチューン。画質"破綻"と言えるほどのものを作る手段は他に見当たらず、時間さえガマンすれば簡単にXvidを圧倒できそう。このあたりのさじ加減は流石に巧い。なんでProキーって有償なんだろう？　 Doom9 コデックコンテスト2005-メインラウンド（Matrix3）では-1:-1。決勝ラウンド（プライベート・ライアンとスチームボーイ）はデフォルト。これはx264開発者が提案した設定。Doom9氏はMatrixでフィルムグレインが結構ちゃんと残ると言っている。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） filter name="Deblocking (in loop) Filter Strength" Recommended： 0:0 Default： 0:0 Deblocking Threshold（＊スレショルド=閾値＊）はブロック検出精度の調整。Deblocking Strength はデブロックをかける強度の調整。デフォルトでデブロッキングとディテイル保持のバランスは周到なものになる。調整範囲は-6 から 6 が良いだろう(低くするとデブロッキングは減る。マイナスはNegative values do not indicate the deblocking effect is reversed)。高くしすぎるとディテルとテクスチャのロス、またはスミアに繋がる。低くしすぎるとブロッキーになる。一般的にはプラスにするなら両方ともプラスに指定するのが望ましい。すなわち、デブロッキングを強くするならthresholdもプラスにするとデブロックされるデータが増える。	man MEncoder 旧称： deblockalpha=<-6-6> 、deblockbeta=<-6-6> 第一のパラメータは AlphaC0 (default: 0)。これはH.264のイン-ループ・デブロッキング・フィルタの閾値。まず、このパラメータの値に従ってデブロックを使うか否かを決める。次に、このパラメータはフィルタを適用するエッジ部分の差の閾値に影響する。プラスの値にする事でブロックノイズが減るが、スミアが増える。第二のパラメータはBeta (default: 0)。これはディテイルの閾値に影響する。非常にディテイルの細かいブロックにはフィルタを掛けない。というのはこのフィルタが使うスムージングはブロックノイズよりも目立つからだ。このフィルタはデフォルト値でほとんど常に最良の結果になるので、そのまま弄らないか微調整にとどめるのがベストだ。しかし素材になんとかしたいほどのブロックノイズやノイズがあるなら、少し強めにしても良いだろう。　（※スミア：こすりつけたような汚れ）
zero1(svn408) Usage: --filter <alpha:beta> (default=0:0) [-6:-6 - 6:6] 　通常、インループ・デブロッキングは圧縮効率、ひいては画質を向上になる。効果が気に入らない時は単に値を下げると良い。　このオプションのねらいは、Xvidのハイモーション箇所で見られたようなブロックノイズのスムーシングだ。　AlphaC0 は強度、Betaは閾値。デフォルトの0:0は最適値として考えられたものだが、Sharktoothによればアニメは3:3が良いとの事。　短いクリップをいくつか用意して実験すると良いだろう。	MEncoder Doc （＊deblockalphaとdeblockbetaは旧称、またPSNRしか考慮していない事に注意＊） : このトピックはやや議論の分かれるところがあります。 H.264 規格にはシンプルなデブロック手段があります。これはI-blockに適用されるQPに基づいて、あらかじめ決められた強さと閾値に基づいてフィルタをかけるものです。デフォルトではQPの高いブロックには強いフィルタがかけられ、 QPの低いブロックはデブロックされません。規格で決められているプリセットの強度は慎重に決められたもので、どんな素材をエンコードしても非常に良いPSNRがでる公算が非常に高いものです。deblockalphaとdeblockbetaは、このプリセットのデブロック閾値を調節する為の物です。多くの人はデブロックフィルタの強さを大幅に弱めるのが良いと考えているようです (例えば-3とか)。しかしながら、これは決して、と言っても良い程、良い考えとは言えません。そしてほとんどの場合、こうした調節をしている人はデフォルトのデブロックの理屈を理解していないようです。まず、in-loop デブロックフィルタを知る上で最も大切な事は、デフォルトの閾値はほとんど常に、最適なPSNRをもたらすという事です。 PSNR が最適にならないケースは稀です。従って望ましいオフセットはプラスマイナス1。それ以上はほぼ確実にPSNRの低下になります。フィルタを強くすると、ディテイルの汚れが増え、弱めると目に見えるブロックノイズが増えます。空間軸の複雑さが少ない素材（例えばディテイルやノイズが少ない）でデブロック閾値を下げるのは、マズいと断言します。こうした素材で発生するアーティファクト（＊意訳すると副作用＊）の封じ込めにかけては、in-loop フィルタは素晴らしい仕事をします。他方、空間軸の複雑さが多い素材でも、アーティファクトは目につきません。なぜなら、リンギングがディテイルやノイズのように見える傾向があるからです。人間の視覚認識はディテイルの損失には敏感ですが、間違ってノイズが描きだされても簡単には認識できません。これは、人間にとっての主観的な品質ということでは、ノイズとディテイルは、ある程度互換性があると言う事です。deblockingフィルタを弱める事は、リンギング・アーティファクトを増やす事になります。ですが、人間の目はこれをディテイルと誤認識します。しかし、これもデブロックフィルタの強度を弱める理由にはなりません。一般的に、ポストプロセッシングでもっと良い品質のノイズを得られるからです。もし、あなたのH.264エンコードがブラーや、スミア（＊smeared：擦って不鮮明にする＊）が多すぎたら、再生時に-vf noiseを試してみて下さい。マイルドなアーティファクトなら -vf noise=8a:4a でほぼ封じ込めることができます。これでデブロッキングフィルタをあれこれするより、ほぼ確実に、良く見えるでしょう。

--interlaced

(no)interlaced

■ まとめ：

B フレーム関連に問題あり。

■ 参考

覚書（要約）・インタレレース保持エンコード。rev570から実装。　ただし。今は、Bフレームの扱いに制限がある。　--direct ではspatial, temporal, auto、 --me ではesaが使えない。　例えば、--direct none --me hex と、する必要がある。　Bフレームでのオプションの話なので、Bフレームを使用しない場合は、問題ない。　観るときは、ffdshowのソフトウェアデインタレースを使用すれば、見れる。　この実装時よりも新しい ffdshowならば、x264インタレ保持に対応されている。　ffdshowは、新しいものを使用しよう。　残念ながらハードウェアデインタレースでは、まだ観れないみたいだ。orz 　これからの更新に、期待ageだ	手許未試用 rev570（06/10/01）で実装。 Mac ではVLC 0.8.6-test1以降が対応としている。ハードウェアデインターレースはMacでは期待し難い。　 me=esa は実用範囲外（常用umh）だが、direct_pred=autoは手許では譲れない線なので現状、手を出しにくい。　 MEncoderのインタレ解除はどれもfps混在に弱いので、完成すれば完全にWinと等価なビデオストリームを生成し得る。かもしんない。　他方、インタレ保持サポートは開発者メーリングリストでパンドラの箱呼ばわりされたり、まるも製作所でも苦労されている様子が伺えるなど、非常にたいへんなんだろうなぁという印象がある。気長に待ちたい。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01）未記載	man MEncoder 映像をインターレースドとして扱う
zero1(svn408) 未記載	MEncoder Doc 未記載

[ 2006/12/05 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(0)

2. Ratecontrol options:

概説

　ここではなによりもまず1パスか2パスかマルチパスの選択を迫られる事になる。
　速度を取るなら1パスだが、技術的な理由でXvidのように固定QP3なら画質もサイズもまずまずといった目安が無い。そういう事を言うのが無意味だと言うのではなく、それがネットの向こう側で通用する確率は非常に低いという事。とはいえ需要は大きく「固定QP風味」のcrfが用意されている。これでかなりXvidの固定QPに近い使い勝手になる。bitrateも指定してやるとそれもなるたけ尊重してくれるので便利だ。ただし、1パスでの画質比較は混乱の素だ。エンコードの度にビットレートが大きく変化するので、画質変化の原因がオプション調整のせいなのか、ビットレートが変わったせいなのか判断のしようが無い。
　ひらたく言うと、1パスエンコは一期一会だ。Net上の情報はアテにできない。
　2パスを使う事で、相当程度のbitの有効利用と、画質や設定比較が可能となる。
　3パス以上は概ね1000フレーム以下の短いクリップに効く。他にも効果のある非常に特殊なケースというものがあるようだが詳細は不詳。
　H.264/AVCのパスは重ねれば重ねる程、bit使用効率が向上する性質（主にモーションベクトルの算出精度、マクロブロックタイプの最適化）を持つ。Apple-H.264はここにチューニングの軸足を置いたようだ。x264でも同じ手は使えるが、はっきりと知覚し得る画質向上は10パス単位（覚書、なるP氏）。オープンソースの性質から言ってもチューニングはカジュアル・エンコード向けの「時間のかかりすぎない」用法に軸足がありそうだ。
　なお、PPC Macで3以上のpassを重ねるならApple-H.264の方が速く済むケースがあり得る。x264であれこれ悩むよりは楽な上に画質で問題が出る事も少ない。

Ratecontrolオプション

x264cli (rev600準拠)	MEncoder -x264encopts (dev-SVN-r20806準拠)

-q, --qp<integer>　[26]

qp=<0-51>　[26]（＊未試用＊）

■まとめ：

ASP QP=2 は概ね H.264 のQP=18。対数計算のできる人はH264QP = 12 + 6*log2(ASP QP)。
0でロスレス。事実上ロスレス専用なので、固定画質1パスならこれではなく後述のcrfを使おう。

■参考

覚書（要約）・Q値設定。defaultは、26。　設定整数値を小さくすると、ビットレートが上がる。0は、losslessだ。　default値のQ値には少し不満が出る。　過去のコーダ同様少しビットレートを増やす程度に変更すると納得いくかも。　画質と容量とを、自分の用途にあわせて煮詰め、Q値を設定したい。　30より大きい数字は、劣化具合がカナリ強くなる傾向になる。	手許未試用の理由 2パスしかやらないから。 MEncoder の旧称qp_constantからも1pass CQ（Constant Quantizer、固定量子化）ではあるが、いわゆる画質固定1パス派にはcrfの方が評判が高く、2passモードの1stとしても推奨されていない。事実上ロスレス専用か。　目標画質 2pass などでAVG QP(p)が18を切れば、数値的にはXvidでは実現できない画質と言える。　 logarithmic scale Xvidのquantizer（量子化、画質劣化度）は2が画質上限で、3,4,5,,,と整数しかなかったのが、0(ロスレス)を上限に少数が使えるようなもの、くらいでいいと思う。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） qp name="Constant Quantizer" Recommended： 26 Default： 26 Encode in Constant Quantizer Mode (0 = lossless)	man MEncoder ＊旧称qp_constant＊実用的範囲20～40 (default: 26)。 Pフレームに適用する量子化値の指定。IフレームとBフレームに適用する量子化値はこの値を元にip_factor と pb_factorが少しずらして決める。低い数値ほど素材画質に忠実で、ビットレートが高くなる。0でロスレス。 H.264 の量子化はMPEG-1/2/4とは異なる事に注意。H.264の量子化パラメータ (QP)は対数尺を用いる。換算すると概ねH264QP = 12 + 6*log2(MPEGQP)。例えば、MPEGのQP=2 は概ね H.264 の QP=18となる。
zero1(svn408) Usage: --qp <integer> (default=26) [1 - 51] (0 = Lossless) P フレームの量子化値を固定。IフレームとBフレームに適用する量子化値はこの値を元に--ipratio と --pbratioのQP係数から計算される。 Xvid同様、量子化値が低いほど画質が良いが、注意すべき事がある。 x264のQP2はXvidのQP2と同じではない。 Xvid のQP2に等しいx264のQPは18だ。これはH.264が対数尺（logarithmic scale）を使う事に拠る。同程度のQPを求める換算式はQP AVC qp = 12 + 6*log2(ASP qp)。 x264 では量子化値を0にするとロスレスもできる。	MEncoder Doc 記載無し（2パス前提の為）

-B, --bitrate <integer>

bitrate=<value>（＊常用1024＊）

■まとめ：

　適正bitrateというのは昔から素材と感性次第。一応bpp早見表を用意したので参考にして頂きたい。

■ 参考

覚書（要約） 704x480で1600～2500 といった数値が見える。 bpp概算で"まずまずだがブロックノイズが見える（0.2）"～"無意味。むしろ解像度を上げるべし（0.3）"の範囲と思われる。手許（ageha）とは大幅にスタンスが異なる事に注意。特に画質に対する主観評価で違いが出て来ると思う。覚書（なるP氏）の方が画質に厳しい筈だ。ここまでbitrateに差があると、細部の設定方針も大幅に差があるハズ。	手許横幅640、1024固定。 bpp概算で"低画質(0.15)"～"まずまずだがブロックノイズが見える (0.2)"の範囲。覚書（なるP氏）とは大幅にスタンスが異なる事に注意。特に画質に対する主観評価で違いが出て来ると思う。自分の方が画質に甘い筈だ。ここまでbitrateに差があると、細部の設定方針も大幅に差があるハズ。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） bitrate name="Bit Rate" Recommended： N/A Default： N/A Set bit rate per second (kbps)	man MEncoder 平均ビットレートの指定。単位kbit/sec(default: off)。ローカルビットレートは変動するため、非常に短いムービーでは指定値とかけ離れた値になる事がある(ratetol参照)。このオプションと vbv_maxrateを同時に使うと固定ビットレートになるが、画質は著しく劣化する。　＊ローカルビットレートビットレート配分を計算する際の単位となる区間の模様。平均化区間というコトバも散見される。1パスでも使う。つまり少なくともx264には、固定ビットレートエンコードや固定quantizerエンコードを想定していない。できない事はないが、全体的なオプションの構成やデフォルト値がそういう作りになっていない。
zero1(svn408) Usage: --bitrate <integer> (default=off) 平均ビットレートの指定。単位Kbps(kilobits per second)。特定のファイルサイズにおさめたければ、推奨方式は2パスだ。特定ファイルサイズと画質が両立できる。1分程度より短いクリップでは3パスが有効な事もある。 x264 の --bitrate は本質的にABR（平均bitrate）でもしCBR（固定bitrate）を使わなければならないなら（ストリー民具以外にCBRのメリットはほぼ無いが）、--vbv-maxrateも弄る必要がある。	MEncoder Doc -

--crf <float>

crf=<1-50> （＊1pass ABR用＊）

■まとめ：

「固定QP風味」エンコード。Xvidなどにあった1パス VBRをやるにはコレが便利。
実際には素材を短い区間に区切ってその中でABRを行う模様。

■参考

覚書（要約）記載無し	手許１パス向け qp（旧称qp_constant）より実用的。 bitrate指定もできる。指定通りのbitrateにはならないが、まぁ、頑張る。 crf=25,bitrate 指定抜きで1173kbpsだったものに700kbpsを指定すると815kbpsになる。とりあえずcrf使っときゃ1パスで容量可変＆そこそこの画質になる。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） Recommended： 26 Default： 26 Quality Based VBR (nominal QP)	man MEncoder 固定画質モードのenable。値は画質を指定するもので、概ねQPに近い。ビットレートベースのモード同様、各フレームごとに複雑さに応じて異なるQPを使う。
zero1(svn408) Usage: --crf <integer> (default=off) [1 - 51] 固定レート係数。名目上（＊nominal＊）のQPに基づく1パスVBRモード。	MEncoder Doc 記載無し

--vbv-maxrate <integer>　[0]

vbv_maxrate=<value> (ABR or two pass)　[disabled]（＊未試用＊）

■まとめ：

一般的には弄るべきではないようだ。

■参考

覚書（要約）記載無し	手許 x264は1パスでも平均化区間を使ったABR。その区間内での最大ビットレートと思われる。平均化区間や VBVについては次項。 2パスでも使うようだが影響不明。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） vbv-maxrate name="VBV Maximum Bit rate" Recommended： 0 Default： 0 ローカルビットレートの最大値。	man MEncoder ローカルビットレートの最大値。単位はkbits/second(default: disabled)。
zero1(svn408) 記載無し	MEncoder Doc 記載無し

--vbv-bufsize <integer>　[0]

vbv_bufsize=<value> (ABR or two pass)　[none]（＊未試用＊）

■まとめ：

一般的には弄るべきではないようだ。

■参考

覚書（要約）記載無し	手許平均化区間 x264 は1passでもストリームを平均化区間に分割してABRを行う。ローカルビットレートとは、この平均化区間内のビットレートと思われる。　 VBV Video Buffer Verifier、ビデオバッファ検証器。 H.264/AVC規格はデコードの規格なので仮想参照デコーダ（HRD,Hypothetical Reference Decoder）というバーチャルなデコーダモデルがある。これを破綻させないようなデータを吐くコデックを作りなさいねという事。 VBV はこのHRDの中の一部分。 …という印象を受けた。（教科書185p）
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） vbv-bufsize name="VBV Buffer Size" Recommended： 0 Default： 0 Size of VBV buffer	man MEncoder vbv_maxrate で使う平均化区間。単位kbits。 vbv_maxrateを使うときは必ず指定する事。(default: none)
zero1(svn408) 記載無し	MEncoder Doc 記載無し

--vbv-init <float>　[0.9]

vbv_init=<0.0-1.0> (ABR or two pass)　[0.9]（＊未試用＊）

■まとめ：

一般的には弄るべきではないようだ。

■参考

覚書（要約）記載無し	手許前項参照
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） vbv-init name="VBV Initial Size" Recommended： 0.9 Default： 0.9 Initial VBV buffer occupancy(＊占有/占有期間＊)	man MEncoder イニシャルバッファ占有率。vbv_bufsizeの係数。 (default:0.9)
zero1(svn408) 記載無し	MEncoder Doc 記載無し

--qpmin <integer>　[10]

qp_min=<1-51> (ABR or two pass)　[10]（＊常用10＊）

■まとめ：

一般的には弄らない。画質にこだわるなら下げる。
量子化工程はブロックノイズの発生源なのでデフォルトのチューニングは最も入念に行われているものの一つ。
しかし、闇階調のブロックノイズなどをどうしても消せない場合は、bitrateを上げると同時にこれも下げるのも良いだろう。
素材に応じたカスタム量子化マトリクスを使いこなす場合は、また別の方針が必要と思われる。

■参考

覚書（要約）・--qpmin,--qpmaxは、-q,-Bよりも優先。指定しない方が、融通は利く。しかし、マックス値を制限させた方が、画質は安定傾向になる。 max値を無理が無いように、美味く設定したい。　 --qp 26がdefault値だ。エンコする作品で加減具合が変わるのはもちろんですが、Xvidと同じで使うマトリクスで大幅に感覚が変わります。　 2pass 以上で書き出されるI・P・Bそれぞれが使ったQ値のアベレージ値に慣れてから、Q値を使う感じがいいと思います。　 Doom9 によると、使えそうな数値は--qpmin ～ --qpmax＝10 ～ 30ぐらいだそうな。マトリクスがflatならば、その通りだと思います。自分の適正値を探しましょう。	手許 quantizer 辞書的には量子化。フツーの人的には「画質劣化度」でも良いかと。 MPEG-1/2/4、JPEGが使う。原理的にブロックノイズ不可避。　 "--qpmin,--qpmax は、-q,-Bよりも優先"について　-q, --qpはMEncoder側の旧称qp_constantからCQエンコード専用と思われます。　bitrate 指定値よりもqp_min、qp_maxが優先するというのは、経験がありません。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） qpmin name="Minimum Quantizer" Recommended： 10 Default： 10 Quantizer最大値の指定。ビットの無駄になる圧縮不足フレームの出力を抑止	man MEncoder quantizer の最小値。10-30が適正範囲のようだ。 (default:10)。
zero1(svn408) Usage: --qpmin <integer> (default=10) [1 - 51] x264が使う量子化値の最小値を指定。より低いquantizerを使っても大して見た目が変わらないような箇所でbitの浪費を抑える。 Xvid で最小量子化値を2にしていたのと似ているが、H.264の量子化スケーリングの違いを忘れないように。	MEncoder Doc

--qpmax <integer>　[51]

qp_max=<1-51> (ABR or two pass)　[51]（＊常用51＊）

■まとめ：

■参考

覚書（要約） 48,43,38 など指定しない方が融通が利くがmaxを制限した方が画質が安定傾向として細かく調整している。　（＊おそらく一個一個の作品にこだわってエンコしてらっさる模様。＊）	手許 51固定 (default) 自分も覚書(なるP氏)同様の考えから一時期maxを制限していたが、弄るに値する程の差を知覚できなかった。手許の常用bitrateは1024固定だが、このレベルではmaxキャップは実際上無視されるケースが多いようだ。　多彩な設定値を試している事から、覚書の人のほうが自分よりこだわり度が高く、知覚も鋭そうです。　　ただし現実的には、このへんは視力や色覚や感性以上に、モニタサイズが占める割合も大きいと考えます。全画面表示ならピクセル数の多いモニタほど、プレイヤやOS が使う拡大縮小アルゴリズムを考慮する必要が出てきます。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） qpmax name="Maximum Quantizer" Recommended： 51 Default： 51 Quantizer最小値の指定。画質の悪い過圧縮フレームの出力を抑止。	man MEncoder quantizer の最大値 (default: 51)
zero1(svn408) Usage: --qpmax<integer> (default=51) [1 - 51] x264が使う量子化値の最大値を指定。量子化の激しいフレームがあったら低くすると良い。一般的にはx264のレートコントロールは非常に優秀で、キチガイじみた量子化値を使う事はあまりない。	MEncoder Doc 記載なし

--qpstep <integer>　[4]

qp_step=<1-50> (ABR or two pass)　[4]（＊常用4＊）

■まとめ：

　隣接フレーム間でのQPの変動幅、最大値。
　一般論では隣接フレーム間で大幅にQPが変動すると目にうざい。
　MEncoderは当初デフォ2だったが、いつ頃からか4になった。参考元全てが4で揃ったのでデフォルト値にはそれなりの汎用性があるだろう。ただし、万能ではなく、特に覚書（なるP氏）はアニメで8を常用しているようだ。

■参考

覚書（要約）常用8の模様・適用Q値の変化できる、Q値幅。　明るいシーン　→　暗いシーン　などで、大幅なビットレート変化を行ってほしいのであれば増やす。個人的にdefault値4は小さいと考えます。　急激にクォリティが変わると、不自然さが出やすいのかも知れませんが、クォリティが必要ない時に急激に落とすことが可能です。シーンチェンジがはっきりしているアニメならば、急激な変化が出来たほうが便利かも｡	手許 24分アニメにしては毎週ずいぶんIが多い素材、特に短いカットをぽんぽん多用するような、例えばゼーガペインはスパン！と割り込むカット切り替えが気持ちよいのだけれど、そこで前のカットのqpに引きずられるとあれれな事がままあった。当然、後続のP/Bはカット先頭のQP(I)に準拠するのでそのカットはまるまるあれれなままだ。　悩んでいるうちにあれれなまま終わってしまったのだが、そうか、こっちを増やすのだったのか。うん…忘れるなこの痛み。　オープニングやCMは終始動きまくりなケースが多いので、適正値の発見は実験に適した素材を探す事から始める必要がある。　理屈上、これを増やした方が良いのは爆発などの一過性のコマよりも「ハイモーション＆ハイディテイル　⇔　ローモーション＆ローディテイル」の場面転換と思われる。こうした演出はアニメに限らず映像にリズム感を持たせたり、ストーリーの区切り目を強調したい場合に多用されるハズだ。例えば闇階調のゴテゴテした場面だらけの映画でラストだけスカッと青空とか。はいそこで『ブレードランナー』と思った人！例えばそういう、記憶に残るくらいインパクトのある箇所に注意。あとパートカラー（一部白黒、一部総天然色）とか。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） qpstep name="Maximum Quantizer Steps" Recommended： 4 Default： 4 連続したフレームの間でのquantizerの変動幅。画質の急激な変化を抑止。	man MEncoder フレーム間でquantizerが増加/減少し得る範囲の最大値。 (default: 4) （＊以前は default：2だった時期もある＊）
zero1(svn408) Usage: --qpstep <integer> (default=4) [1 - 50] フレーム間で quantizerは変動するが、この値はその変動範囲の最大値を指定する。理論上、値を大きくすると、フレーム間での quantizerの変動幅が大きくなり、短時間のうちに次々に画質が変わる。	MEncoder Doc 記載なし

--ratetol <float>　[1.0]

ratetol=<0.1-100.0> (ABR or two pass)　[1.0]（＊常用4＊）

■まとめ：規格適合性に要注意か？

ABRや2パスでのビットレート変動幅。大きいほど乱高下。
1.0より大きいとファイルサイズが目標値より大きくなり得る。最終ファイルサイズが地味に揃わなくなる。
1.0より小さいとファイルサイズが目標値よりより小さくなり得る。

　2 パスとはいえ、bitrate指定値を使い切らなくても良い場面というのはあり、またそれじゃ全然足りない場面もある。そこをやりくりするのが2パスなのだが、闇雲にあの場面は100kbps、この場面は8000kbpsにしときゃ良いとは限らない。そのへんを「ほどほどに加減」するオプション。
　例えばストリーミングではきっちりどの瞬間も500kbpsでないと困る。ハードウェア再生機でもデコーダバッファメモリには限りがあるし、内部帯域も上限無しとは行かない。

　デフォルト1も手許常用4も規格適合性は不詳。levelによりなにかあるとは思う。規格上は仮想デコーダモデルというものがあり、それを破綻させないようにエンコードしなければならないようだ。
　そのへん全部ぶっとばして画質最優先なら、100。

■参考

覚書（要約）記載無し	手許常用4 番組ごとに地味にサイズが変わる。約25分,2pass, 1024kbpsだとプラマイ5MB程度。光ディスクにキッチリ無駄無く収めたい場合はここは1にしてqpstepなどで調整すべきだろう。 4の根拠はMeGUI Help、およびDoom9 コデックコンテスト2005（3例全て4）。　　しかしながら、全てをぶっとばして100にしたいケースというのもままある。例えば、TV版Zガンダムのオープニング冒頭8秒間。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） ratetol name="Average Bit rate Variance (%)" Recommended： 1.0 to 4.0 Default： 1.0 時間軸に沿ってビットレートがどのように変動し得るかの指定。低い値はビットレート変化を押さえる。映像のストリーミング品質を向上し、コデックが複雑な場面に対応する能力を減らす。高い値はビットレート変化を増やす。複雑な場面への対応能力を向上し、ビデオのストリーミングでの信頼性を減らす。 0% に指定すると、CBRになる。100% では場面の複雑さに応じて激しくビットレートが変化する (完璧な CQP または "quantizer curve compression")。	man MEncoder 平均ビットレートにおける変動幅の許容値。特定の単位は無い。 (default: 1.0)
zero1(svn408) Usage: --ratetol <float> (default=1.0) [0.1 - 100.0] 平均ビットレートにおいてbitrateが逸脱できる範囲（＊allowed deviation、制御偏差？＊）を指定。 1.0より大きくするとファイルサイズが目標値より大きくなり得る。 1.0より小さくすると目標値より小さくなり得る。	MEncoder Doc 記載無し

--ipratio <float>　[1.40]

ip_factor=<value>　[1.4]（＊未試用＊）

■まとめ：素材に応じて調整

zero1氏の記述参照

■参考

覚書（要約）記載なし	手許 Zero1氏の記述はアニメオープニングの他に、CMや、音楽PV、映画の予告編などにも当てはまると思う。つまり、短時間の内に強いインパクトを与える事を狙った映像。一般的に動きもカットも多い。 b_adapt はこうした素材をB使用に適さないフレームと看做してBを控えてPを連発するようだ。I/P/Bの種別は1st passのログに出るのでMacでも掴める。ちょっと大変なので手許ではいちいち弄っていない。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） ipratio name="I-P Quantizer Factor" Recommended： 1.4 Default： 1.4 Iフレーム-Pフレーム間のquantizer換算係数	man MEncoder I-P フレーム間のquantizer換算係数(default: 1.4)
zero1(svn408) Usage: --ipratio <float> (default=1.40) I-Pフレーム間の quantizer換算係数を指定。 1.00でPフレームのquantizerがIと同じになるが、これはお奨め出来ない。bitを無駄にするに等しいからだ。もしあなたのAMV（アニメ(・ミュージック)・ビデオ）がBフレームを生成する傾向が弱ければ、1.40以上を試しても良いだろう。これはPフレームの画質を落とす（程度は--ipratioの値に依る）。しかし、全体的な画質が平均化される。画質がころころ変わったり、ハイモーション・エリアでブロックが出るよりは良いだろう。	MEncoder Doc 記載なし

--pbratio <float>　[1.30]

pb_factor=<value>　[1.3]（＊未試用＊）

■まとめ：素材に応じて調整

zero1氏の記述参照

■参考

覚書（要約）記載なし	手許特に無し。 zero1氏はbrdoを使うなら1.3以上にしても良いのではとしている。しかし手許ではbrdoで浮いた分のbitを少しでも全体的な適用QPを下げる方に回したいのでここは弄っていない。効果のほどは未詳。　なお、自分はXvidのVHQが効果が高かった経験から、RDOと書いてあったら無条件に常用するクセがある。規格上にRDOは無いとBond氏は書いているが、最初に実装したのはJMだとも書いている。ので、盲信。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） pbratio name="P-B Quantizer Factor" Recommended： 1.3 Default： 1.3 Advanced： Pフレーム-Bフレーム間のquantizer換算係数	man MEncoder Pフレーム-Bフレーム間のquantizer換算係数(default: 1.3)。
zero1(svn408) Usage: --pbratio <float> (default=1.30) Pフレーム-Bフレーム間の quantizer換算係数を指定。ここでも、1.00でPフレームのquantizerがBと同じになる。だから-- ipratio も1.00ならI, P, Bのquantizerが全て同じになる。一般的にはBフレームはPフレームよりも圧縮して良い。だから1.3より大きくしたい人もあるだろう。特に--brdo (BフレームのVHQ)を使っている場合は。 I, P, Bのデータはエンコード完了後にコンソールに表示される（＊枚数や平均サイズなど＊）。	MEncoder Doc 記載なし

--chroma-qp-offset <integer>　[0]

chroma_qp_offset=<-12-12>　[0]（＊未試用＊）

■まとめ：弄らない。or 素材に応じて調整。

　輝度と彩度で適用QPに差をつける。実用範囲-2～2。人間の視覚は輝度には敏感だが彩度（色の変化）には鈍感なので、彩度はぐっと省略しても良い。ただし、DVDやTVはもともとこの原理を応用して彩度を間引いてあるから、それをさらに省略してもともと情報量の多い輝度に回しても違いは微妙なものだろう。闇階調や明階調が重要な素材では試す価値がある。端的には白黒映画。
　High Profileになりかつ煩瑣にはなるが、カスタムマトリクスでより緻密な調整ができる。

■参考

覚書（要約）・色部分 (chroma U・V)を輝度部分(LUMA)とQの差を発生させて、エンコする事ができる。　基本的には、差を用意したいのであれば、マトリクス側で行えば用が足りる。　マトリクスをLUMA・CHROMA間で差を用意していないのであれば、このオプションを使ってもいいかもしれない。	手許経験上、白黒映画は最大の敵。特に闇階調に弱いx264は手許の設定では使いものにならない。白黒は完全なグレイスケールでは無く、若干着色されているかフィルムの色がのっているようだが、青系の単色であり、ここにあまり低いQPを使う必要は無いように思う。カスタムマトリクスはJVT以外まったく経験が無いが、これで済むなら済ませたいところ。要検証。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） chroma-qp-offset name="Chroma and Luma Qunatizer Offset"Recommended： 0 Default： 0 彩度情報と輝度情報に異なるquantizer を使う	man MEncoder 彩度情報と輝度情報に異なる量子化値（quantizer）を使う。実用範囲は-2から2。 (default: 0).
zero1(svn408) Usage: --chroma-qp-offset <integer> (default=0) [-12 - 12] 彩度情報と輝度情報に異なる量子化値を使う。これはちょっと面白い。というのは人間の目は彩度変化よりも輝度変化に敏感だという視覚認識のしくみを逆手にとるものだからだ。反面、彩度情報はYV12（＊DVDやテレビが使うYUV4:2:0＊）ではもともと間引かれているので、僅かな輝度画質向上の為に、大量の彩度画質を犠牲にする事になる。	MEncoder Doc 記載無し

-p, --pass <1|2|3>

pass=<1-3> （＊常用2パス＊）

■まとめ：

1パスエンコードでこのオプションを指定する必要はありません。これはマルチパスエンコードの1stパスです。でも害もないです。
マルチパスモードの起動。
pass=1(--pass 1)：エンコードと統計ファイルの作成。
pass=3(--pass 3)：エンコードと統計ファイルのリファイン。要、作成済み統計ファイル。好きな回数だけ繰り返せる。
pass=2(--pass 2)：統計ファイルに基づく最終エンコード。要統計ファイル。
※いずれの段階でも出力ファイルはできる。統計ファイルだけ欲しければ "-o dev/null"。winでは"-o NUL:"（いずれもmencoder）。

3パスが有効なケースは1000フレーム以下の短いもの。他、特殊なケース（不詳）。
なお、PPC Macで3以上のpassを重ねるなら、設定によってはApple-H.264の方が速く済むケースもあり得る。

■参考

覚書（要約）・3の命令が、 statsファイルに上書きする。2の命令はしない。　すなわち2passならば、1→2 　3pass 以上ならば、1→3→3→…→3→ 2　と、実行させる。　50passぐらいまでは、+ 10pass増えるごとに画質が全く違うモノになる。　そこから100passぐらいでは、+20passごとで、変わる感じ。　主に、輪郭などの鮮明さで、差が出てくる。	手許パス数 NTT研究所でも数十パスで1080pを1.8Mビット/秒にできるとしている。 Apple-H.264 パス数指定不能。フロントエンド次第の模様。QTPlayer Proは5程度。 raw2qt264で強制的に2パスでやるとたかが落語で豪快なブロックノイズが出た。動き補償、なかんずくモーションベクトル・サーチ精度に問題か。　現状では、土台のショボさを多段パスで隠蔽したものに過ぎず、なによりあまりにも遅い。心情的には"最先端技術"は誇大広告と言いたいほどだが、4Core x 2クラスが一般的になってくるとasmプログラミングに頼らずとも相当の高速化を果たす公算が高い。設定の簡便さ、狙っても画質破綻を引き起こせない安定性を考えるとx264のアドヴァンテージは必ずしも大きく無い。特に画質に文句を付けている意見は見た事が無く、Bond氏も"rather good"としている。画質に関しては一度はApple-H.264を試して頂きたい。Mac/Win問わずMPEG Streamclipで試せる。　自分の見立てでは、普及度の面でXvidとQT互換H.264、そしてflvの後塵を拝しているx264は、中期的（2～3年）にはむしろ瀬戸際にある。2007年中の進化速度が天王山だろう。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） pass name="Multipass Mode" Recommended： Enabled Default： Disabled マルチパス・レートコントロールをenable	man MEncoder 2または 3パスモードの指定。最適なビットレート配分と全体の画質向上の為には、2か3パスエンコードを推奨。　1 1st パス　2 2nd パス (または2パスエンコード) 　3 Nth パス (3pass エンコードの 2nd と 3rd パス) 理屈と使い方： 1st pass(pass=1) 映像の統計を取ってファイルに書き込む。 CPU負荷の高いオプションは使わなくて良いが、デフォルトでonのものは使う事。 2nd pass(pass=2) stats(＊統計＊)ファイルを読み込み、これを基にビットレート配分をコントロールする。 3pass モードでの2nd("pass=3"。誤字ではない) 上記の両方を行う。最初に統計を読み込み、上書きする。CPU負荷の高いオプションを除き全てのエンコードオプションが使える。 3rd pass(pass=3) 2nd passと同じだが、2nd passの統計を使用する。CPU負荷の高いオプションを含めて、全てのエンコードオプションが使える。 1st pass はABRでも固定quantizerでも良いが、quantizerを推測する必要がないので、ABRの方が望ましい。後続のパスはビットレートを指定するABRでなければならない。
zero1(svn408) Usage: --pass <1\|2\|3> マルチパスモードの起動。 1st と2ndについてはXvidで慣れている人も多いだろう。 "nth pass"というものが増えた。これは、1stパスで統計情報を採り、次の2回目にnth passを走らせるというものだ。結果が気に入らなかったり、ファイルサイズがオーバーしたりしたら、2回目のパスをもう一度実行できる。するとnth passはpass 3を実行する。　 Nth passは一回ごとに統計情報をアップデートしてゆく。 2nd passは単に最終パスを実行するだけで統計をアップデートしない。　 --pass 1 Pass 1は映像分析と統計ファイルの書き出し。 Xvidにおける"2 pass - First pass"だ。デフォルトではmuxできるファイルを書き出す。このパスで bitrateを指定すると1 pass ABRとなる。 --qp 18などを指定すると、概ねXviDの full quality first pass mode同等の見た目のファイルができる。一般的には、この段階で bitrateを指定した方が、2nd 、nth passの結果が良い。 --pass 2 Pass 2はfirst passで得た複雑度の統計に基づいてレートコントロール関係の判断を下し、出力を生成する。Xvidの"2 pass - Second pass"といっしょだ。統計情報の上書きはしない。一般的に2 passはより良い画質とより小さなファイルサイズをもたらす。常時推奨。動作の視覚化は下記参照のこと。 (Pass 1) --pass 1 = 最初の統計収集 (Pass 2) --pass 2 = Pass 1 の統計を使って出力 --pass 3 --pass 3はいくぶん特別だ。これは２回目や３回目のパスという意味では無い。というのは何回でも無限に繰り返せるから。画質が無限に向上するわけでは無いので10パスはちょっと待てという感じ。現実的なメリットがあるのは、 1000フレーム程度より短い素材だけだ。こうした素材ではbitrate配分を最適化する時間が足りない（＊where it doesn't have much time to average the bitrate properly＊）。基本的に--pass 3は--pass 1 と --pass 2の作業を同時に行うが、最初の統計ファイルを作るにはpass 1が必要だ。 --pass 3は、単純に統計ファイルを読んで出力するだけでなく、統計ファイルもアップデートする。従って、nth pass modeを使った3 pass encodeではpass 2よりも精度の高い統計情報が使える事になる。このへんは視覚化すると理解しやすい。ここでpass 2を走らせるとpass 1の統計情報よりリファインされたものが使える。 (Pass 1) --pass 1 = 最初の統計収集 (Pass 2) --pass 3 = Pass 1 の統計を使って出力 + 統計情報のアップデート (Pass 3) --pass 3 = Pass 2 の統計を使って出力 + 統計情報のアップデート	MEncoder Doc Two pass encoding: 先に、常に2パスを推奨すると書きましたが、これが当てはまらないケースというのもあります。例えば、TVキャプチャのリアルタイムエンコードではシングルパスしか手が有りません。また、当たり前ですが1パスは2パスより速いです。両方のパスで全く同じオプションを使った場合、２パスエンコードはほぼぴったり２倍遅い事になります。　しかし、それでも2パスを使うべき理由。第一に、シングルパスのレートコントロールは心理的なものではありません(＊人の目で見てどうかというほどの意味＊)。さらに、映像全体を見る事が出来ない為に、しばしば妥当とはいえない選択をする事が有ります。例えば、２分のビデオがあったとしましょう。最初の半分は非常に動きの多い60秒のシーンで、奇麗にエンコードするには、その部分だけで2500kbps 必要だったとします。その直後には300kbpsで充分なシーンが60秒続くとします。このような場合、セオリーでは1400kbpsで充分ですが、シングルパスは２つの"ミス"をおかします。まず、どちらの部分にも1400kbpsを使おうとする事です。前半の60秒は過剰にquantize（＊量子化＊）され、ブロックノイズは受け入れ難い程になります。これは妥当とは言えません。後半の60秒では過剰にquantize（＊量子化＊）が控えられ、画質は完璧になりますが、それにかかるビットレートコストを考えると、まったく妥当とは言えません。２つのシーンの変わり目で起きる問題は、さらに厄介です。動きの少ない後半60秒のうち、最初の数秒はとんでもなく過剰にquantize （＊量子化＊）されます。というのは、レートコントロールはまだ前半の60秒で必要だったレベルの圧縮を続けてしまうからです。この動きの少ないシーンに発生したquantize（＊量子化＊）過剰の"エラー区間"は目障りで、実際、奇麗な映像に必要な300kbpsを下回ります。こうしたシングルパスの落とし穴を回避する手段はありますが、ビットレートの予測間違いを増やすという傾向があります。　レートコントロールにおける複数パスのアドバンテージはシングルパスよりも遥かに高いです。１stパスで記録した統計を使って、どんなquantizer設定でも、エンコーダは充分正確に各フレームに必要な"コスト"（ビット）を予測する事が出来ます。これにより、ずっと合理的にビットを動きの多いシーンと少ないシーンに配分することができます。この配分方針を調節するには、下記のqcompを見て下さい。　さらに、２パスに１パスの２倍の時間をかける必要はありません。1stパスのオプションを調節して、速度を上げ、画質を落とす事ができます。うまく調節できれば、1stは非常に速く済むでしょう。この場合、サイズ予測の精度が落ちますから、2ndの品質は僅かに落ちます。しかし、通常、違いは目で見て解るレベルにはなりません。例えば、1stと2ndにそれぞれこんなのを追加して試してみてください。　（＊06年10月改訂前のオプション名＊） subq=1:frameref=1 subq=6:frameref=15:4x4mv:me=3 　 Three pass encoding? x264 では後続パスの数を自由に指定できます。 1stパスにpass=1を使い、後続パスでpass=3を使った場合、後続パスは前のパスの統計の読み込みと、新たな統計ファイルの書き出しの両方を実行します。さらにその次のパスは指定されたquantizerの範囲でのフレームサイズをずっと正確に予測できる事になります。実際上は、これによる全体的な品質向上はほとんどゼロです。ひょっとすると3rdパスのグローバルPSNRは2ndよりさがる事もあります。一般的な3パスの使い方は、2パスではビットレート予測が巧くいかなかったり、場面転換が汚く見えたりした場合に使うというものです。こうした事は非常に短いクリップで起きる傾向があるようです。　他にも3（以上の）パスが有効なケースがいくつかありますが、上級者向けなのでここでは省きます。

--stats <string>　["x264_2pass.log"]

-passlogfile <filename>（＊常用2パスにつき常用＊）

■まとめ：

特に無し

■参考

覚書（要約）特に無し	手許特に無し
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） stats name="Statistics File Name" Recommended： x264_2pass.log Default： x264_2pass.log 2 pass ログファイル名	man MEncoder 2pass モードで1stパスの情報をデフォルトのdivx2pass.logではなく、<filename>にダンプ。（＊ -x264encoptsでは無く、GENERAL ENCODING OPTIONS。読んでみると地味に不安になるが、x264専用アプリではないので＊）
zero1(svn408) Usage: --stats <string> (default="x264_2pass.log") マルチパスエンコードで使うログファイルの場所と名前を指定。各パスは全て同じログファイルを参照するようにしないと正しく動作しない。	MEncoder Doc 特に無し

--rceq <string>

対応不詳

■まとめ：

Ratecontrol equation ["blurCplx^(1-qComp)"]
レートコントロールの計算式のようだが意味不明。後述のcplxblurとqcomp の関係式のようではある。開発者のチューニングテスト用か？

■参考

覚書（要約）記載無し	手許 mencoderには相当するオプションが無く、弄れない。完成後の.mp4をHexEditで開くとこの式は入っている。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） rceq name="Rate Control Equation" Rate Control 方程式（＊Rate Control Equation＊） Recommended：blurCplx^(1-qComp) Default： blurCplx^(1-qComp)	man MEncoder 対応不詳
zero1(svn408) 記載無し	MEncoder Doc 記載無し

--qcomp <float>　[0.60]

qcomp=<0-1> (ABR or two pass)　[0.6]（＊常用0.6(default)＊）

■まとめ：弄らない or 動体視力に応じて調整

0.0 でCBR（固定bitrate）
1.0 で CQP（固定量子化）※完全なものではなく、ほとんど等価、といったレベルのようだ。
空間軸画質（一時停止したときの奇麗さ）を重視するなら1.0に近づける方が良い。
よりマニアックにはx264cliで--rceqより複雑な式を自分で組めばいいのかと思いますが思ってみただけですすいません。
qp_step(--qpstep)との関係不詳。

■参考

覚書（要約）記載無し	手許【参考】Doom9 コデックコンテスト2005では一切弄っていない。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） qcomp name="Quantizer Curve Compression" Recommended： 0.60 Default： 0.60 QP curve compression: 0.0 = CBR, 1.0 = CQP	man MEncoder quantizer の圧縮。低い数値にするとビットレートの変動幅が低くなる。=画質の変動幅が大きくなる。高い数値にするとquantizerの変動幅が低くなる。=画質の変動幅が小さくなる。 (default: 0.6)。
zero1(svn408) Usage: --qcomp <float> (default=0.60) [0.00 - 1.00] QP curve compression（＊曲線圧縮？＊）低くするほどconstant bitrateに近づく。0.00 でCBR。高くするほどconstant QP に近づく。(＊1.00 でCQP。＊）推奨値はデフォルトの 0.6。特にアニメで0.00 のCBRは絶対に避けるべきだ。レートコントロールの手足を縛り、動きやディテイルの少ない箇所でbitを節約して、動きやディテイルの多い箇所に振り向ける事ができなくなる。	MEncoder Doc : qcompは一定量のビットを"コストのかかる"動きの多いシーンと、"コストの安い"動きの少ないシーンの間でやりとりするものです。極端な例をあげると、qcomp=0で真のconstant（＊固定＊）ビットレートになります。一般的には、これで動きの多いシーンは酷い物になります。一方、動きの少ないシーンはたぶん完璧でしょう。そして必要なビットレートの何倍も無駄にビットを喰っているハズです。反対の極端例。qcomp= 1 はほとんどconstant quantization (QP)（＊画質固定、一定画質など＊）です。 Constant QPでは、画質が悪いということはありません。しかし多くの人は、非常に"コストのかかる"シーンでもっとビットレートを節約して（動きの多い場面では画質劣化はあまり目に留まりませんから）、その分を、画質向上しやすいシーンに回すほうが合理的だと考えています。 qcomp のデフォルトは 0.6 です。これは多くの人の好みよりは若干低いようで、0.7-0.8 を使う人も多いです。

--cplxblur <float>　[20.0]

cplx_blur=<0-999> (two pass only)　[20]（＊未試用＊）

■まとめ：不詳

■ 参考

覚書（要約）記載無し	手許類似オプション ip_factor、pb_factor、qcomp、qp_step などとの違いはstatsを参照する事。特にqp_stepが隣接フレーム間の変動幅であるのに対し、cplx_blurは "Temporal blur"という若干曖昧めな語で説明されている。ちょっと広い範囲を見て口を出す中間管理職みたいな？。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） cplxblur name="Quantizer Fluctuation Reduction (Before)" Recommended： 20.0 Default： 20.0 QPのバラツキを抑止 (curve compressionの前に適用)	man MEncoder curve compression（＊曲線圧縮？＊）の前に、予測されたフレームの複雑さに時間軸ぼかし（＊blur＊）をかける(default:& nbsp; 20)。低い数値にすると必要に応じてquantizer値は急激に変化する。高い数値はなだらかな変化しか許さない。 cplx_blurはIフレームが後続のPフレームに近い画質になる事を保証する。複雑なフレームと単純なフレームが交互にあっても～例えばfpsの低いアニメーションなど～、ころころとquantizerを変えてビットを無駄にしない。
zero1(svn408) Usage: --cplxblur <float> (default=20.0) [0 - 999] --cplxblur は予測されたフレームの複雑さに時間軸のスムーシングをかけるもので、curve compressionの前に、時間軸上でQPがあまりころころ変わらないようにするものだ。この値を低くすると時間軸上のQPの変動幅が大きくなる。高くするとQPの変動幅がなだらかになる。このオプションはtwo passとnth pass モードでしか使えない。統計ファイルを使うからだ。意味が分からなければdefaultの 20.0のままにしておく事。	MEncoder Doc 記載無し

--qblur <float>　[0.5]

qblur=<0-99> (two pass only)　[0.5]（＊未試用＊）

■まとめ：不詳

■ 参考

覚書（要約）記載なし	手許これも"Temporal blur"。cplx_blurとの違いは：１） curve compressionの前か後か。　・curve compressionの意味不詳２）ぼかす対象　・これは「量子化値」。cplx_blurは「予測されたフレームの複雑さ」
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） qblur name="Quantizer Fluctuation Reduction (After)" Recommended： 0.5 Default： 0.5 QPのバラツキを抑止 (curve compressionの後に適用)	man MEncoder curve compressionの後に、フレームの複雑さを見積もって量子化パラメータに時間軸ぼかしをかける (default: 0.5)。低い数値にすると、必要に応じてquantizer値は急激に変化する。高い数値はなだらかな変化しか許さない。 cplx_blur も参照。
zero1(svn408) Usage: ---qblur <float> (default=0.5) [0 - 99] --cplxblur 同様。違いは時間軸ぼかしをquantisation paramater (QP)にかける事。ここでも、値を低くすると時間軸上のQPの変動幅が大きくなる。高くするとQPの変動幅がなだらかになる。これも一般的には弄る必要は無いが、ここには実験に意味を見いだす人があるだろう。（＊原文はある掲示版の常連を対象にしている＊）	MEncoder Doc 記載なし

--zones <zone0>/<zone1>/...

zones=<zone0>/<zone1>[/...]]（＊未試用＊）

■まとめ：素材に応じて調整

特定範囲のレートコントロール調整。bitrateかqpで指定。映画の冒頭や末尾のタイトルロールなどで使うようだ。

■参考

覚書（要約） --qpmin,--qpmaxは、--zonesや-q・-Bで指定した数値よりも優先されます。	手許特に無し
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） zones name="Define Zones" Recommended： Disabled Default： Disabled 映像のビットレート配分を部分的に調節	man MEncoder 特定部分(エンディングやクレジットなど)を指定した画質調節。指定書式は以下の通り。　 <start-frame>,<end-frame>,<option> 　上記の<option>では以下が指定できる。　q=<0-51> 　　quantizer 　b=<0.01-100.0> 　　ビットレート乗数　 NOTE: ここで指定したquantizer値は厳格に強制されるわけではない。レートコントロールの計画段階に影響するだけで、オーバーフロウ補償や qp_min/qp_maxの適用対象から外れる事は無い。
zero1(svn408) Usage: --zones <zone0>/<zone1>/... (default=off) [b=0.01 - 100.0, q=0 - 51] Zonesを使うと映像の特定箇所でbitrateかquantizerの指定値を乗っ取る事ができます。指定書式は以下の通り　Start frame, End frame, Option 上記のOptionはq=<integer> (forced QP) または b=<float> (bitrate multiplier)を指定します。 zone指定を続けて書く際は前に "/" を書きます。例：　 --zones 200,900,b=0.50/1000,1200,b=2.0 　これでフレーム番号200-900までは指定した平均bitrateのおおむね半分に、1000-1200までは指定した平均bitrateの倍となります。	MEncoder Doc 記載無し

--qpfile <string>

対応不詳

■まとめ：

x264cliの記述は"Force frametypes and QPs"。
恐らくI/P/Bの種別と適用QPを強制するもので、様々な映像に使って適正フレームタイプやQP値を検証する目的のオプションと思われる。

■参考

覚書（要約）記載無し	手許特に無し
MeGUI2.0 Help（ContextHelp v0.2 06/01/01）記載無し	man MEncoder 対応不詳
zero1(svn408) 記載無し	MEncoder Doc 記載なし

[ 2006/12/08 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(0)

3.1. Analysis options_カスタム量子化マトリクス以外

概説

　徐々に複雑なオプションが増えて来るが、基本的にはまずProfileを選択し、次にsubq（-m, --subme）の値を決めると良いだろう。
　特にsubqははframeref(-r, --ref)と並んで最も符号化効率の向上と速度低下が激しいが、最低5や6以上にしないと効かないオプションが多いので、CPUの許す限り高く設定しておきたい。
　そこから先はほとんど微調整。「ゴミのようなオプションを山のように積み上げて高圧縮を実現」して行く事になる。

Analysisオプション

x264cli (rev600準拠)	MEncoder -x264encopts (dev-SVN-r20806 準拠)

-A, --partitions <string>　[?]

partitions=<list>　[p8x8,b8x8,i8x8,i4x4]（＊常用デフォルト＊）

■ まとめ：Main Profileならi8x8を切る（8x8dctも切る）。他は素材に応じて調整。

（default: p8x8,b8x8,i8x8,i4x4）

list	適用タイプ	備考	BP	MP	HP
p8x8	p16x8, p8x16, p8x8		?	可	可
p4x4	p8x4, p4x8, p4x4	p4x4推奨はsubq >= 5、かつ、低解像度の場合のみ。	?	?	可
b8x8	b16x8, b8x16, b8x8.		?	可	可
i8x8	i8x8	8x8dctと一緒に使わないと無意味。	不可	不可	可
i4x4	i4x4	（＊微細なディテイルに効く＊）	?	可	可
all	上記全て有効		不可	不可	可
none	上記全て無効		可	可	可

Main Profileではサブマクロブロック・パーティション8x8が使えない。これはASPでは使えたもの。従ってMPは細部のディテイルがXvidに劣り得る。それならいっそ素材に応じてメリットの増減が激しいi4x4も切って、ここでは速度を取るのもアリだ。あとはframeref（--ref）なりパスを一個増やすなりしたほうが、全体的な画質向上効果が高いだろう。

High Profileでは、画質最優先なら全部使う。手許では4x4系は潰しが効かないと考えて一部切っている。

■参考

覚書（要約）: ・-A　圧縮に使うサーチするマトリクスの種類を指定します。
　p4x4は、p8x8の補完に使われる。単品では使えない。
　また、i8x8は、8x8dctフラグを立てないと使えない。
　つまり、最小構成はi4x4,p8x8になる。覚えておいていいだろう。

手許: 手許ではp4x4は切っている（てゆうか見直したらデフォでやんの）。; man とDocの記述では常用のsubq=7では非推奨であり、640x480は低解像度には入らないだろう。また、"一貫して10%-15%の速度低下で0.1dbのPSNR向上"は悪くは無いが、"小さな動く物体が大量にある素材"でしか効かないとなると、frameref（--ref）を一個増やした方が潰しが効く。; さらにx86なら3パスでもApple-H.264のマルチパスより早いハズだ。このへんのスタンスについて『動画エンコードのアプローチ』を参照頂きたい。; 　; 規格上のマクロブロック・サイズ; H.264/AVC規格のマクロブロックは一辺が16,8,4の組み合わせとなる。16x16,16x8,16x4,8x8,8x4,4x4。; さらにそれぞれ I/P/B/Skip/Directなどの種別がある。; 16x16以外のサイズはマクロブロック・パーティションとかサブマクロブロックなどと呼ばれ、16x16の標準マクロブロックの内側の区分。したがって、16倍数以外でのクロップはASP同様に問題があるようだ（少なくともMEncoderは警告を出す）。; SkipとDirectはマクロブロック・タイプIでは使われない。; 　; Main Profile; Main Profileではサブマクロブロック・パーティションx8系が使えない。これはASPでは使えたもの。従ってMPは細部のディテイルが Xvidに劣り得る。他方、x4系は使えるので（使わなくても良いが）、MPは中間サイズのディテイルはXvidに劣り得るくせにもっと微細なディテイルは優れ得るという、なにがしたいのかよくわからないプロファイルだ。deblockがあるからいいじゃんという事なのか、単に制定を急いだためか（そういう文言は時折見られる）。

MeGUI2.0 Help（ContextHelp v0.2 06/01/01）: name="Macroblock Analysis Sizes"
Recommended：All (High Profile)
Default： p8x8,b8x8,i8x8,i4x4

マクロブロック・サーチサイズを増やす。符号化効率は向上するが速度は下がる。
注意： i8x8はHigh Profileになる。またAdaptive 8x8 DCTを指定していないと適用されない。

man MEncoder

オプショナルなマクロブロック・タイプの指定

（default: p8x8,b8x8,i8x8,i4x4）。

list	適用タイプ	備考
p8x8	p16x8, p8x16, p8x8
p4x4	p8x4, p4x8, p4x4	p4x4推奨はsubq >= 5、かつ、低解像度の場合のみ。
b8x8	b16x8, b8x16, b8x8.
i8x8	i8x8	8x8dctと一緒に使わないと無意味。（＊High Profile＊）
i4x4	i4x4	（＊微細なディテイルに効く＊）
all	上記全て有効	（＊High Profile＊）
none	上記全て無効

このオプションの指定に関わらず、p16x16, b16x16, i16x16 は常に有効。
基本的な考え方としては、あるピクチャの中の特定箇所を一番ウマく扱えるタイプとサイズを見つけるためのもの。例えば、画面全体に渡るパンには 16x16が最適な一方、小さな動く物体にはもっと小さなブロックを使うほうが良い。

zero1(svn408): Usage: --analyse <string> (default=p8x8,b8x8,i8x8,i4x4) [p8x8, p4x4, b8x8, i8x8, i4x4, none, all]
　; 　エンコードの過程で使えるマクロブロックタイプの指定。できるだけ全部使った方が良い。例えばディテイルの少ない大きなブロックの動きには16x16マクロブロックが適している一方、細密なディテイルには4x4が適している。使えるマクロブロックタイプが多いほど符号化効率が上がる。; 　マクロブロックタイプの中には、サブピクセル（＊サブペルとも＊）動き予測の方式に影響を受けるものがある。p4x4を使うにはp8x8が、i8x8は- -8x8dctが必要だ。

MEncoder Doc: partitions=all:; このオプションは予測マクロブロックの中で、サブパーティション、8x4, 4x8, 4x4を使う物です（デフォルトで使うものに追加）。ほぼ一貫して10%-15%の速度低下になります。動きの少ない素材に使うのはほとんど意味が有りません。しかしながら、動きの多い素材、なかでも小さな動く物体が大量にある素材では約0.1dbのゲインが期待できます。

--direct <string>　["spatial"]

direct_pred=<name> 　[spatial]（＊常用auto＊）

■ まとめ：実用上はautoかspatialの二択。

Bフレーム中のダイレクトマクロブロックで使われる動き予測の方式。
　none：ダイレクトマクロブロック禁止。なぜかspatial・temporalより遅い。
　spatial：モーションベクトルを周辺マクロブロックとその動きから推計。
　temporal：モーションベクトルを後続のPフレームから補間。
　auto：spatialとtemporalの適応的選択。遅い。マルチパスで効果向上。

　一般的にはauto。auto登場前は、アニメでノイズが気になるとしてspatial固定を使う人もあった（理屈の上では動きの少ない場面で微妙なゴーストが出るハズ）。ただし、b_adaptを使った場合、マクロブロックタイプ・ダイレクトとなるBは必ずしも多く無い。速度を重視するなら spatialでも充分だろう。

■参考

覚書（要約）　ダイレクトモーションベクタープロダクションモード。　Bフレームのベクトルのサーチの仕方。2パスは、autoがお勧め。　spatial は、動いてるときに使う方式。　temporalは、動きが少ないときに使う方式。　autoは、上の二つを場面によって判別し、適応させる方式。　それぞれ、特性に合わせて。	手許 Doom9 コデックコンテスト2005（この時点ではAuto無し）では決勝の2例(エンコードがより困難な素材)でspatialを使っている。　【映画】　x264 [info]: direct mvs spatial:84.5% temporal:15.5% 【アニメ】x264 [info]: direct mvs spatial:93.4% temporal:6.6% 【落語】　x264 [info]: direct mvs spatial:90.4% temporal:9.6% 　直近の例ではざっとこんなもんだが、そもそも手許の設定（bframes=3: b_adapt）ではダイレクトB自体がさして多く無い。【映画】　x264 [info]: direct: 2.6% 【アニメ】x264 [info]: direct: 2.8% 【落語】　x264 [info]: direct: 3.3%
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） direct name="B-frame Mode" Recommended： temporal Default： temporal B フレーム用のモーションベクトルの供給方式。 Spatial(空間軸) は同一フレーム内部の隣接ブロックを使う。より高いPSNRが得られる Temporal（時間軸）は隣接フレームを使う。より良い画質が得られるとされている。【注意】この時点ではAutoの記載無し。デフォルトも rev600と異なる。	man MEncoder default =spatial(旧1) Bフレーム中のダイレクトマクロブロックで使われる動き予測の方式を決める。 none(旧0) 無し：ダイレクトマクロブロックを使わない。 spatial(旧1) 空間軸: モーションベクトルを近接ブロックから推定。(default) temporal(旧2) 時間軸: モーションベクトルを後続のPフレームから補間。 auto(旧3) 自動: コデックが各フレーム毎に空間軸と時間軸を決定。空間軸予測と時間軸予測は速度もPSNRも概ね同じ。どちらが適しているかは映像内容によって異なる。 Autoの方が僅かに良いが、遅い。マルチパスで使うと最も効果が高い。 direct_pred =noneは速度も遅く、品質も低い。
zero1(svn408) Usage: --direct <string> (default=temporal) [none, spatial, temporal, auto] ダイレクト・マクロブロックで使う動き予測方式の指定。一般的にはtemporal（＊時間軸＊）がベターだ。というのは後続Pフレームを使って動き予測をするから。他方、spatial（＊空間軸＊）は周辺マクロブロックとその動きに依存する。もちろん、noneで画質は最低になる。そして驚くべき事に速度も低下する。Autoはtemporal and/or spatialの自動選択だ。遅くなるが、ベスト。	MEncoder Doc 記載無し

--direct-8x8 <-1|0|1>　[-1]

対応不詳

■ まとめ：不詳
　x264cliの説明からするとlevel指定に応じたプリセットか。効果は下記参照。

Direct prediction size [-1]
    - 0: 4x4
    - 1: 8x8
    - -1: smallest possible according to level

■参考

覚書（要約）覚書（なるP氏）はカスタムマトリクスの経験から以下のように推測している。多分動きが変わる。 4x4ならば激しい動きに強く、 8x8ならば、画面パンやキャラ引きに対して画質が柔軟になるでしょう。自動の場合は、コレまで通り。値を適応しやすい方のマトリクスのを利用して、決定すると思われる。	手許 direct_pred(--direct)のすぐ後にある事から「Bフレーム中のダイレクトマクロブロックの動き予測で使われるサイズ」と思われる（手許ではx264cli --longhelpは新参プログラマにソースを読む順番を示す「もくじ」と考え、順番を「情報」と捉える傾向があります。詳細はこの記事の余談１）。　　 Doom9 Explanation for new switches in x264（06/10月上旬）　 #4 IgorC --direct-8x8 HD-DVDとの互換性向上用。 #6 Sirber --direct-8x8 で画質は変わるの？ただの互換性フラグ？ #8 akupenguin（x264 author）これまでは、 Level指定を破る事になってもオフにできる時には常にオフだった（オフのほうが画質が良いという仮説に基づく）。テストの結果、どちらでも計測可能な画質向上は無い事が解ったので規格に適合するよう修正した。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01）記載無し	man MEncoder 対応不詳
zero1(svn408) 記載無し	MEncoder Doc 対応不詳

-w, --weightb　[不詳]

(no)weight_b　[不詳]　（＊常用オン、要bframes=1以上＊）

■ まとめ：効果不詳

参考元の意見がバラバラで、まとめようが無い。少なくとも画質的に有害ではなさそう。

■参考

覚書（要約）圧縮時間が、モリモリ増える素敵なオプション。Bフレームの出来が上がる。どのぐらい上がるかは、トライandエラーを繰り返して、確かめてください。	手許【参考】Doom9 コデックコンテスト2005では3例全てに使用。＊常用理由は「なんとなく」。切った事が無いので効果不詳。＊MEncoder Docの記述ではb_adaptと競合して効果を発揮できないとしているが、この原文はMeGUI helpやZero1氏の記述よりも古いと記憶。＊東芝レビュー2003/07「次世代動画像符号化方式"MPEG-4　AVC/H.264"」に簡単な説明がある。確かここには暗転や明転フェード・ディゾルブに応じて別の算定方式を使う必要があるとする PDFもあったハズだが、一応記憶で書くと… 適応重み補間予測は暗転や明転、つまり輝度以外に変化の無いシークエンスに効く。これ抜きの場合はbitコストの高いI/Pを連続させる必要があった。但し、暗転と明転、フェードやディゾルブなどで別の判断方式を作ってやる必要が有る。 weight_bがこれをどう実装しているのかは判断材料がない。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） weightb name="B-frame Weighted Prediction" Recommended： Enabled Default： Disabled Bフレームにおけるブライトネスの重み付けを行う。フェードと、カラーグラデーション（空など）に効果。	man MEncoder Bフレームに適応重み補間予測方式を使う。このオプション抜きの場合、双方向予測されたマクロブロックは前後の参照フレームを等価に扱う。このオプション有りの場合、参照フレームに対するBフレームの時間軸上の位置に応じて、前後の参照フレームのどっちかを重要視する。 bframes > 1でないと効かない。
zero1(svn408) （＊訳文精度劣悪に付き原文併記＊） 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. 　 Bフレームの適応重み補間予測は特別なモードだ。決断に当たって（＊なんの？＊）、前後のPフレームとBフレームの距離を勘定に入れるもの。通常の平均方式では、B使用は画質劣化に直結する（例えば、動きの精密な予測が困難なような場合）。このモードが効果を発揮するにはBが1枚以上必要だ。	MEncoder Doc : 一般的なケースでは、このオプションはあまり効果がありません。しかし、クロスフェードや暗転フェードのシーンでは、なかなかビットレートを節約してくれます。MPEG-4 ASPでは、暗転フェードを奇麗に符号化するにはビットコストの高いI-frameを連続させる必要がありました。B-frameにweighted predictionを使うと、こうした場面を、少なくともその一部は、ずっと小さなB-frameに置き換える事ができます。新たな計算手順が発生しない為、時間コストは僅かです。また、一部の人たちの予想とは異なり、デコード時のCPU負荷にも大した影響がありません。ほとんど同じです。　残念な事に、現在のadaptive B-frame decisionアルゴリズムにはフェード中のB-frameの使用を控える傾向が非常に強いです。これが変わるまでは、フェードの影響が大きそうな素材では、nob_adaptをx264encoptsに入れておくのが良いアイデアかもしれません。

--me <string>　[hex]

me=<name> 　[hex]（＊常用umh＊）

■ まとめ：CPUパワーに応じてhexかumh

　速度低下はframeref（-r, --ref）との相関関係に有るが、実用範囲はumh以下が妥当なようだ。

■参考

覚書（要約）設定例は--me esaが多い。	手許常用umh。 me=4(esa)とme_range=64でトラウマになった。【参考】 me=4:me_range=64、2passで24分のアニメに122.5時間（PowerMacG5 2Ghz Dual）実感としてはメリットが無い。パスを重ねる方がよさそうだ。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） me name="Motion Estimation Mode" Recommended： hexagonal Default： hexagonal Advanced：モーションベクトルのサーチ方式の指定。・Diamond search radius 1 (fastest), ・hexagonal search radius 2 (fast), ・uneven multi-hexagon search (slow) ・exhaustive search (slowest)	man MEncoder （＊06 年10月改訂後＊）フルピクセルの動き補償アルゴリズム選択。 dia：ダイヤモンドサーチ、半径 1 (高速) hex：六角形サーチ、半径 2 (デフォルト) umh：不等複数六角形サーチ esa：徹底サーチ (超低速、umhより全く良くなるところが無い)
zero1(svn408) Usage: --me <string> (default=hex) [dia, hex, umh, esa] 整数ピクセル動き予測の方式を指定。オプションは以下の通り： dia：ダイヤモンドサーチ（高速） hex：六角形サーチ、半径2 umh：不等マルチ六角形サーチ esa徹底的なサーチ（低速）お奨めはhexかumh。umhとesaではサーチ半径を調整する--merangeが使える。	MEncoder Doc : このオプションはモーション推算サーチ方式の選択です。この設定値の変更は品質と速度のトレードオフに直結します。me=diaはデフォルトよりほんの数 %速いだけです。グローバルPSNRの低下は0.1dB以下。デフォルトのme=hexは速度と品質の妥当な取引です。me=umhのグローバルPSNR ゲインは0.1dBをやや下回り、速度低下の程度はframerefに依ります。高いframeref、例えば12とか、ではme=umhの速度はme= hexより約40％低下。frameref=3では速度低下は25%-30%に落ちます。　 me=esa は徹底的なサーチで、これは実際に使うには遅すぎます。

--merange <integer>　[16]

me_range=<4-64>　[16]（＊常用16、要me=umh以上＊）

■ まとめ：一般的には16、こだわるなら32
　
■参考

覚書（要約）・この整数値を増やすと、動きが格段に良くなる。　ただ、エンコ時間は、莫迦に増える。　動きが悪くならないように勤め、-- merangeの適正値をdefault値付近になるようにエンコしよう。　━━━その勤め方だが、具体的にはマトリクスの作り方を失敗しないようにする。	手許常用16。 me=4(esa)とme_range=64でトラウマになった。【参考】 me=4:me_range=64、2passで24分のアニメに122.5時間（PowerMacG5 2Ghz Dual）実感としてはメリットが無い。パスを重ねる方がよさそうだ。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） merange name="Maximum Motion Vector Range" Recommended： 16 to 32 Default： 16 Advanced：モーションベクトル捜索範囲の最大値。	man MEncoder 徹底的にサーチ(me=esa)と不等複数六角形サーチ(me=umh)の動き捜索半径。
zero1(svn408) Usage: --merange <integer> (default=16) [4 - 64] umh とesa動き予測モードの捜索半径。16と32が良いとされている。	MEncoder Doc 記載なし

-m, --subme <integer>　[5]

subq=<1-7> 　[5]（＊常用7＊）

■ まとめ：可能な限り大きく。最低5、できれば6。

速度低下は大きいが画質面での利得は最も大きいものの一つ。 5や6以上を要求するオプションも多い。

■参考

覚書（要約）設定例は6が多い。	手許 RDOの意味は不明ながら無条件に使うクセがある為。7。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01）（＊7 登場以前と記憶＊） subme name="Subpixel Refinement" Recommended： 5 to 6 Default： 5 動き予測(motion estimation)の決断方式。低い値は高速で、正確さに劣る。高い値は低速で、画質で勝る。注意：BフレームのRDO(b-rdo)を使うには RDO Subpixel Refinementが必要。	man MEncoder subpel 精製品質の調整。このパラメータは動き予測の過程で、品質と速度のトレードオフを取り扱う。 subq=5 はsubq=1よりも最大で10% 圧縮できる。　・1：最速：全てのマクロブロックタイプに対してフルピクセル精度で動き予測を行った後、ベストのタイプを選択し、そのタイプの動きを、高速な1/4ピクセル精度の動き予測に精製する。・2：1に同じ。ただし、若干低速なフルピクセルサーチと若干低速な1/4ピクセル精度の動き予測精製を使う。・3：全てのマクロブロックタイプに対して1/2ピクセル精度で動き予測を行った後、ベストの形式を選択し、1/4ピクセル精度の動き予測に精製する。・4：全てのマクロブロック形式に対して高速な1/4ピクセル精度で動き予測を行った後、ベストの形式を選択し、1/4ピクセル精度の動き予測に精製する。・5：デフォルト：ベストのマクロブロック形式を選択する前に、全てのマクロブロック形式に対して最高品質の1/4ピクセル精度で動き予測を行う。・6： I、Pフレームのマクロブロックタイプにrate-distortion[1]最適化を行う。・7：ベスト：モーションベクトルとイントラモードに rate-distortion[1]最適化を行うここまでに於いて、"all candidates"(すべての候補)とは、必ずしも全てのマクロブロックタイプを試すとは限らない:4x4,4x8,8x4は、8x8が16x16よりも良い結果だった場合にのみ試行される。 ※注[1]：rate-distortionの意味不明。Bフレームにも使うにはbrdoを指定。Doom9/MPEG4-AVC情報の"RDO"も参照。 ※ 注[2]：速度と品質への影響大。Doc/x264コデックでのエンコードも参照。
zero1(svn408) Usage: --subme <integer> (default=5) [1 - 7] サブピクセル動き予測に使うアルゴリズムの指定。速度と品質の取引をするオプションの一つ。--subme 6 と 7はRDO(Rate Distortion Optimisation)も使う。CPUパワーが充分なら6か7推奨。それ以外は5。	MEncoder Doc （＊06 年10月改定前＊） : 速度と品質をトーレードオフにするオプションの中では、これまでのところ subq とframeref （後述）が一般的に最も重要です。速度であれ品質であれ、調節したいと思うなら、この二つを最初に弄るべきです。速度面においては、frameref と subq は極めて強い相互関係にあります。これまでの実験結果では、reference frameが1の時、subq=5 (default) はsubq=1よりも約 35% 時間がかかります。reference frameが6の時、時間増は 60%以上に達します。subqがPSNRに与える影響は、reference frameの数とは全く無関係なようです。一般的に、subq=5のグローバルPSNRはsubq=1よりも0.2-0.5 dB向上します。これは通常は充分に目で見て解る違いが出ます。 subq=6は最低速で最高品質のモードです。 subq=5と比較してグローバルPSNRは0.1-0.4 dB向上し、速度は25%-100%低下します。subq=6は他の数値とは違って、frameref と meの設定値にあまり影響を受けません。その代わり、subq=6の効果は主としてB-frameの数に拠ります。一般的な使用方法では、これはsubq =6は複雑な、動きの多いシーンでは速度と品質に与える影響が大きいが、動きの少ないシーンでは大して効果的でない事を意味します。注意：B-frame は常に0以外の値に設定する事を推奨します（bframesの項参照）。

--b-rdo　[?]（＊要--subme 6以上＊）

(no)brdo　[?]（＊常用オン、要 subq=6以上＊）

■ まとめ：Bを使う場合は使用

速度低下の程度は不詳。CPU次第か。

■参考

覚書（要約）エンコードスピードにそうひびかない。	手許 XvidのVHQの効果が高かった経験からRDOとあったら無条件に使います。切らない。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） b-rdo name="RDO for B-frames" Recommended： Enabled Default： Disabled Bフレームの動き予測(motion estimation)向上。速度低下。注意：RDO Subpixel Refinementが必要	man MEncoder Bフレームのマクロブロックタイプにレート歪み最適化（rate-distortion optimization）を使う。subq>=6が必要。
zero1(svn408) Usage: --b-rdo (default=off) BフレームのRDO(Rate Distortion Optimisation)。XvidのVHQ B-frameに相当。要--subme 6 以上	MEncoder Doc 記載無し

--mixed-refs　[off?]（＊要--ref 1以上＊）

(no)mixed_refs 　[?]（＊常用オン、要frameref=1以上＊）

■ まとめ：

当初、8x8/16x8サブマクロブロックでなければ効かないという事なので、HP以外では無意味と考えましたが、コメント欄に動き補償のブロックサイズとDCTのブロックサイズは無関係とのご意見を頂きました。
Profileに拠らず使える可能性があります。

■参考

覚書（要約）記載なし。常用の模様。	手許常用。闇階調でぱたぱたとフレーム単位で動くブロックノイズが気になったら切った方が良いケースもあり得るか。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） mixed-refs name="Mixed References" Recommended： Enabled Default： Disabled パーティションベースで参照 (references)を決める。	man MEncoder 各8x8 または 16x8 motion partitionが、独自に参照フレームを選べるようにする。このオプション抜きの場合、マクロブロック全体（＊a whole macroblock＊）が同一の参照フレームを使わなければならない。要frameref>1。
zero1(svn408) Usage: --mixed-refs (default=off) 各8x8/16 マクロブロック・パーティションが独自に参照フレームを選択できるようにするもの。このオプション抜きの場合、マクロブロック全体（＊the whole macroblock＊）が同一の参照フレームを使う。これは明らかに速度を犠牲にして符号化効率の向上を得るものだ。デコーダに必要なRAMが増える（ただし生成されるビデオのレベルは参照フレームが多くても無理なRAM消費をすることはないだろう）。要--ref 1以上。	MEncoder Doc 記載なし。

--no-chroma-me　[?]（＊要-- subme 5以上＊）

(no)chroma_me 　[on]（＊常用、要subq=5以上＊）

■ まとめ：

　素材がグレイスケールでも無い限り、特に切る必要は無いだろう。白黒映画でも大抵はフィルムの色がのっているものだし、見やすさのためか青系の色が加えてあるような事もある。

■参考

覚書（要約）記載なし	手許常用
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） no-chroma-me name="Chroma Motion Estimation" Recommended： Enabled Default： Enabled 動き予測（Motion Estimation）の算出にビデオのカラーコンポーネントも計算に含める。画質向上。	man MEncoder サブピクセル動きサーチで彩度情報も参照する。 subq>=5が必要。
zero1(svn408) Usage: --no-chroma-me (default=off) 彩度動き予測の停止。彩度動き予測（＊Chroma ME＊）はサブピクセル動き予測サーチの工程で行われる。理想的にはdisableにすべきではない。従ってこのスイッチを使うべきではない。要-- subme 5以上。	MEncoder Doc 記載なし

--bime　[off]

(no)bime 　 [?]（＊常用、要bframes=1以上＊）

■ まとめ：Bを使うならon
　
■参考

覚書（要約）常用の模様	手許常用。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） bime name="Bi-Directional Motion Estimation" Recommended： Enabled Default： Disabled Jointly optimize both MVs in B-frames	man MEncoder 双方向（＊予測＊）マクロブロックで使われる2つのモーションベクトルを、フォワードおよびバックワードサーチの結果を再利用せず、精密化。 B フレームが無いと効果が無い。
zero1(svn408) Usage: --bime (default=off) ジョイント双方向動き予測精密化を使う。Bフレームの両方向のモーションベクトルを最適化する。エンコード時間と引き換えに画質向上になる。デコーダへの影響は無いので、これも「代償抜きの画質向上」の一つと言える。	MEncoder Doc 記載なし

-8, --8x8dct　[off]

(no)8x8dct 　 [?]　（＊常用on、HP、QT7非互換）

■ まとめ：x264ユーザで切っている人を見かけない。

詳細はpartitions（-A, --partitions）参照。

■参考

覚書（要約） i8x8は、8x8dctフラグを立てないと使えない。	手許 Doom9 コデックコンテスト2005では3例全てに使用。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） i8x8dct name="Adaptive 8x8 DCT" Recommended： Enabled Default： Disabled Basic： Adaptive spatial transform size 8x8 tranform適用の自動判定をenable。（＊Enables the intelligent adaptive use of 8x8 tranform＊）	man MEncoder 適応的空間軸変換のサイズ。：マクロブロックを4x4と8x8 DCTの２種類から選択可能にする。また、i8x8マクロブロックタイプも許可する。このオプション抜きの場合、4x4 DCTしか使わない。
zero1(svn408) Usage: --8x8dct (default=off) 適応的空間軸変換のサイズ（＊Adaptive spatial transform size＊）。4x4dctに加え、8x8dctが使えるようになる。--analyse（＊現-A, --partitions＊）の項で述べたように、i8x8マクロブロックタイプを使う為に必須。 Note: これを使うとストリームはHigh Profileになる。デコーダやプレイヤのHPサポート、少なくともこの機能のサポートをを確認する事。	MEncoder Doc 記載なし

-t, --trellis <integer>　[0]

trellis=<0-2> 　[0]（＊常用2、要subq=6以上、CABAC＊）

■ まとめ：微調整なので重ければ切っても可。

■ 参考

覚書（要約） CABACのサーチにオプションをつける感じ。ループフィルタを排除するよりCABACを排除したほうが、実は軽くなる。だが、画質がh.264規格っぽくなくなる。逆に、-t, --trellisオプション加えると、容量辺りの絵が良くなる。が、エンコもデコードも重くなる。	手許 trellis=格子。手許ではRDOとあったら無条件に使い、切らない。検証もしない。盲信。 Doom9 コデックコンテスト2005では3例全てに1を使用。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） trellis name="Trellis Quantization" Recommended： Final MB Default： Disabled Trellis RD quantization. (Requires CABAC). 0 = Disabled 1 = Enabled on Final MB 2 = Always Enabled (slower)	man MEncoder レート歪み最適化(RDO)の量子化（quantization） 0　非使用(default) 1　最終エンコードでのみ使用 2　全モード決定で使用。(低速、要subq>=6)
zero1(svn408) Usage: --trellis <integer> (default=off) [0 - 2] Trellis は RDO（Rate Distortion Optimisation）だ。これは常にRate Distortionが最適になるような計算をする。特定領域の画質を劣化させて、画質劣化がより目立ちそうな領域へbitを振り向ける。微調整と考えて良い。 --trellis 1はマクロブロックの最終エンコード時のみtrellisを使う。 --trellis 2は全てのモード決定時に使うので、よりbitを節約する事になり、ターゲットbitrateあたりの画質が僅かに向上する。前提条件として、CABACが必要なので、CAVLCでは使えない。CAVLCを使うには--no-cabacが必要だ。CABACはデフォルトで適用され、CAVLCに対して概ね10%ほどbitrateを節約できるがややデコード負荷が上がる。	MEncoder Doc 記載なし

--no-fast-pskip　[off]

(no)fast_pskip 　[on(fast_pskip)]（＊常用off(nofast_pskip)＊）

■ まとめ：不詳

　Zero1氏は「青色のエリア」に効果が限られるとしているように読めるが、man MEncoderは「ディテイルの無いエリア」としているように読める。手許では闇階調のマクロブロック緩和に若干の効果を感じられなくも無い、といった程度。

■参考

覚書（要約）はやい段階で、P フレームを省略させないフラグ。高圧縮させるために、Pフレームを積極的に省略していました。それを防ぐオプション。画質がちょっち上がります。が、容量は少し太る。	手許・Doom9 コデックコンテスト2005で闇階調のブロックノイズが問題になった直後に登場。・上記問題の特徴は、"フレームごとにぱたぱたと変わる"事。・マクロブロックタイプの一つである"Skip"と複数参照の複合汚染と推測。以上から闇階調のマクロブロック対策と推測。効果は& hellip;うーん。無いとは言わないが、手許のBPPではバッチリとは言えない。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） no-fast-pskip name="Fast P-frame Skip" Recommended： Enabled (ブロックノイズ発生時のみ) Default： Disabled P-フレームにおける速い段階でのSKIP detectionをオミット。fast P-SKIPでブロックが出がちの際に画質向上。このチェックボックスをenableにするとearly SKIPがオフになり、速度が遅くなる。（＊Disables early SKIP detection on P-frames improving quality where fast P-SKIP tends to block. Enabling this checkbox will disable early SKIP (slow).＊）	man MEncoder Pフレームにおける速い段階でのスキップ検出。デフォルトはenable（＊fast_pskip＊）。通常は（＊画質低下等の＊）ペナルティ無しで速度向上。ただし、ディテイルの無いエリア、例えば空など、にアーティファクトが出る事がある。
zero1(svn408) Usage: --no-fast-pskip (default=off) No fast P-skipはPフレームにおける早い段階でのSkip検出を不可とする。これによりエンコード時間と引き換えに空などの青いエリアのブロックノイズを緩和し得る。Haaliの適応的量子化機能はこの青いエリアのブロックノイズ対策なので--no-fast-pskipはあまり助けにならない。適応的量子化（＊Adaptive Quantisation.＊）を試すべきだろう。（＊Haaliが何をするものか管理人（ageha）は知りません妖精現実さんで名前は見るけど＊）	MEncoder Doc 記載無し

--no-dct-decimate　[off]

(no)dct_decimate 　[dct_decimate]　（＊常用nodct_decimate＊）

■ まとめ：bitrateが高ければon。以外はdct_dacimateするべきか

■ 参考

覚書（要約） Pフレームで絵が崩れるのを防ぐ。rev503で追加された。高圧縮のためにPフレームの画質が低下していたのを防ぐ。雨のシーンで、雨が消えないようになる感じの効果が出ると思います。オススメ（＊Changeset 503：06/04/19＊）	手許横幅640固定、1024kbpsでは切る（デフォルト）べきかも知れない。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01）記載無し	man MEncoder Pフレーム中の僅かな係数しか含まないDCTブロックを除去する（デフォルトはenabled）。若干のディテイル除去になるので、その分のビットを他のフレームに回せる。全体としては、主観的な画質向上が期待できる。アニメ以外の素材を高ビットレートで圧縮する場合は、disableにして可能な限りディテイルを残したいと思うかもしれない。
zero1(svn408) 記載無し	MEncoder Doc 記載無し

--nr <integer>　[0]

nr=<0-100000> 　[0]（＊未試用＊）

■ まとめ：

ノイズリダクション。圧縮工程前に行われるものなので MEncoderやAviSynthで出来るものと同じ。未試用につき性能不詳。多少軽そう。

■参考

覚書（要約） defaultでは、使われない。 mplayerのソレやAvisynthのHQDN3Dと似た効果が得られる。 100～ 1000程度が使える数値かと思われ。 HQDN3Dもそう重くないが--nrは軽い。	手許 rev 398にて追加。　 mencoder のhqdn3dでは空間軸輝度、空間軸彩度、時間軸に分割した調整ができる（ただしnrより重いとある）。　なお、x264cli開発者の一部にはVfWインフラの制約を逃れる為、取り込める機能はcliに取り込みたい希望があるようだ。例えばVFRエンコーディングなど。"VfWインフラ" にはそれを参考に作られたmencoder等も含む。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01）記載無し	man MEncoder ノイズリダクション。0でdisable（デフォルト）。有用な範囲は一般的なコンテンツでは100-1000だが、非常にノイジーな素材ではもう少し大きくしたい人もあるだろう。速度への影響は少ないので、目的によってはビデオフィルタでdenoise3dやhqdn3dを使うよりこちらが望ましい。
zero1(svn408) Usage: --nr <integer> (default=0) [0 - 1000] -- nrはWiener filterを使ったDCTドメインにおけるノイズリダクション。AVISynth filterの同等品よりも早い。有用な範囲は100-200。素材に対する実際の圧縮工程に入る前に適用されるもので、H.264規格には無い。従って再生上の要求が増えたり、デコーダに特定の機能が必要だったりする事はない（AVISynthでできるのと同様のただのフィルタだ）。　（＊"DCT domain noise reduction using a Wiener filter"の意味不詳。ウィーン人のフィルタ？＊）	MEncoder Doc 記載無し

[ 2006/12/10 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(4)

3.2. Analysis options_deadzone関連

概説

　2006/10月前半に追加された比較的新しいオプション。詳細不詳。

Doom9 Explanation for new switches in x264
#4 IgorC

--deadzone：高bitrate でディテイルレベル向上。ノイズ、フィルムグレイン、など。
#10 AlexW（x264 contributor）

IgorC が言ったように、--deadzoneは中～高bitrate領域での精細なディテイルやフィルムグレインを向上させる。
まず--deadzone-intra の調整から始めるのをお奨めする。違いの大半はここで発生するみたいだから。--deadzone-intra のデフォルト値は11だが、いくぶん0に近い方がややディテイルが残るようだ。CQMと一緒に使うとなお良いハズ。
#23 akupenguin（x264 author）

理論上、lambdaを改造すればtrellisにもdeadzoneが使える。でも実装はまだ。
#10 AlexW（x264 contributor）

まだちゃんとテストしてないが、速度低下は最小限のハズだ。
#27 akupenguin（x264 author）

Deadzoneはquality-per-qp （*1）に影響する。理想的なデブロック強度はqualityに依るが、現実のデブロック強度（規格上の定義によるもの、およびx264オプションで指定するもの）はQPと相関関係にある。qualityでは無い。
だからもしquality-per-qpを調節すれば、デブロックの設定も変えたいケースがあるだろう。しかしながら、デブロック設定の単位は極めて粗いので、deadzoneを最低値の0まで下げた場合でも（推奨しない）、対応するデブロック補正はせいぜい-1に止めるべきだろう（default deadzoneの時に使っていたデブロック強度に対して-1）。反対にdeadzoneを最大値の32まで上げるなら、適切なデブロックはせいぜい+ 1。
　
適切なdeadzoneとbitrateとの間に特定の関係は無い。Deadzoneは常にrate- distorion optimal value（*2）と相関関係にあるので、いかなる変化もサイコビジュアル（*3）なもので、まだ断定的な推奨値を書けるほどテストされていない。

　上記スレには高bitrateってどのくらいなのだという議論もあるが、もともと一概には言いにくい上に、SDとHDが入り交じる現在ではさらにやっかいだ。H.264/AVCに対応したBPP表が必要と思われる。

*1） quality-per-qp：どうやら主観画質/QPのようだ。PSNR/QPやSSIM/QPといった感じではない。
*2） RDO、なんの？QP全体に股がるRDOあったっけ？
*3）人間の視覚認識のしくみを逆手にとったもの

総務省　情報通信審議会情報通信技術分科会（第４２回）資料４２−１−２　ＣＳデジタル放送高度化委員会報告　本体（ 6P）
3.2 量子化
直交変換された信号を量子化して情報量を削減するが、H.264 | MPEG-4 AVC では、小さい成分を強制的に0に丸める領域(デッド・ゾーン)のない量子化処理をインター予測においても行っている。

　デッドゾーンがあるんだかないんだかよくわかりませんが、とりあえずデッドゾーンというのは細かいディテイルを端折る処理のようです。インターにおいてもっていうんだからイントラにもあるのでしょうね。たぶん。

Analysisオプション _deadzone関連

x264cli (rev600準拠)	MEncoder -x264encopts (dev-SVN-r20806 準拠)

--deadzone-inter <int>　[21]

deadzone_inter=< 0-32> 　[21]（＊未試用＊）

■ まとめ：不詳、次項参照

Set the size of the inter luma quantization deadzone [21]
インター（フレーム間）輝度量子化のデッドゾーンのサイズ指定。

trellis とバッティングの可能性有り？

■参考

覚書（要約）次項参照	手許次項参照
MeGUI2.0 Help（ContextHelp v0.2 06/01/01）記載無し	man MEncoder Set the size of the inter luma quantization deadzone for non- trellis quantization (default: 21). 　非trellis 量子化における、インター（フレーム間）輝度量子化のデッドゾーンのサイズ指定(default: 21)。
zero1(svn408) 記載無し	MEncoder Doc 記載無し

--deadzone-intra <int>　[11]

deadzone_intra=< 0-32>　[11]（＊未試用＊）

■ まとめ：不詳

Set the size of the intra luma quantization deadzone [11]
Deadzones should be in the range 0 - 32.
イントラ（フレーム内）輝度量子化のデッドゾーンのサイズ指定(default: 11)。範囲0-32。

trellisとバッティングの可能性有り？

■参考

覚書（要約）・デッドゾーンなインター・イントラLUMAのQ値ってなんだろうね。　━━━うーん、多分。デッドゾーンって、フレームスキップしてるときの事 …かな。　フレームスキップは、P・Bフレームで起こる。intraは、P・Bフレーム向けなマトリクスだ。　つまり。フレームスキップが起こっている場所を、スキップ数減らさないで質を上げるには、　この数値を減らす必要が出てくる …だろうと考えられる。　逆に。さらに、ビットレートケチるなら、数値を大きくする。　　試した所、想像した感じの効果が得られた。　アニメでのBフレームは、ほとんどがスキップされる対象なので、　- -deadzone-intraを減らすと、質が上がる感じを受けた。…ただし、容量は莫迦増える。　逆に、数値を増やすと、Bフレーム時の動きが皆無的になり、カクつくシーンが発生する。　増やす用途で得をするようには、どうも思えない。　B フレームスキップを擬似的に無しにする為に、　--deadzone-intra の数値を減らして使うのが、このオプションの意味なのかもしれない。	手許　覚書（なるP氏）の検証結果は冒頭、AlexW（x264 contributor）の発言と整合する。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01）記載無し	man MEncoder Set the size of the intra luma quantization deadzone for non- trellis quantization (default: 11). 　非trellis 量子化における、イントラ（フレーム内）輝度量子化のデッドゾーンのサイズ指定(default: 11)。
zero1(svn408) 記載無し	MEncoder Doc 記載無し

[ 2006/12/10 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(0)

3.3. Analysis options_カスタム量子化マトリクス関連

概説

　この項はx264cliとMEncoderで大幅に分類方針が異なる為、体裁が異なります。内容は覚書（要約）、zero1(svn408)、man MEncoderのミックスです。

Encoding H.264 using the x264 Command Line Interface：CQMの前フリから
　CQMとは、Custom Quantisation Matrix (または Matrices、カスタム量子化マトリクス)の省略形です。量子化マトリクスは格子状に配置された数字（＊数列、行列＊）からなり、それぞれの数字は quantum（＊量子＊）と呼ばれます。これは、これらの数字がどのくらい画像を劣化させるかを決めるという事です。
　大きなquantumで構成された数列ほど映像をソフトにします。小さなquantumで構成された数列ほどディテイルが残ります。x264のデフォルトは、"flat 16" マトリクスです。全てのquantumは16で、特別なデコードは一切必要ありません。これとは別に、カスタム量子化マトリクス機能はHigh Profileの機能で、実際のデコードに必要なリソースは全く変わらないにも関わらず、デコーダ側にそれ専用のサポートが必要になります(*1)。
　Xvidのカスタムマトリクスでは、ほとんどデフォルトのH.263量子化形式で問題はありませんでした(*2)。x264でも flat 16で多くのケースで問題はないと思わますが、中には、高周波係数領域（＊high frequency co-efficient area＊）を大きなquantumで埋めたマトリクスで精細なディテイルを僅かにぼかし、圧縮しやすくしたい事があるかもしれません。

　理想的なCQMを定義するためには様々な方法があります。利用可能なオプションは以下の通り：

*1）他にもMain Profileは規格制定を急いだフシがあり、積み残しが多い印象がある。
*2）手許では、Xvidの quant_type=mpegは、闇階調ブロックノイズの削減に段違いの効果があった。

Analysis オプション _カスタム量子化マトリクス関連

x264cli			MEncoder -x264encopts	メモ（＊常用jvt 、HP、QT7非互換＊）
--cqm <string> デフォルトのflatマトリクスか内蔵のJVTマトリクスを選択する（JVTマトリクスはH.264規格策定のパートナーであるJoint Video Teamが作った）。マトリクスはx264.exeに内蔵されているのでCQMの使い方としては全く簡単だ。外部ファイル要らないから。			cqm=<flat\|jvt\|<filename>> 事前に定義済みのカスタム量子化(quantization)マトリクスか、JMフォーマットのマトリクスファイルを使う。　flat 　　事前に定義済みのflat 16 matrixを使う (default)。　jvt 　　事前に定義済みの JVT matrixを使う。　<filename> 　　JMフォーマットのmatrixファイルを使う NOTE: Windows のCMD.EXEユーザは、全てのCQMリストを使おうとする場合、コマンドラインの構文解析で問題が起こり得る。これはコマンドラインに最大長制限があるため。そうした場合、リストをJMフォーマットCQMファイルに入れて上記の設定でロードする事を推奨。	なんとなくJVT常用。 Xvidでquant_type=mpegに変えた時はうわなにこれスゲェって感じだったが、そこまでの違いは感じなかった。それでも闇階調の"フレームごとにぱたぱたと変わる"ブロックノイズ削減に若干の効果がある。外部ファイル下記にいくつか公開されている。 Doom9： collection of available AVC custom quant matrices Bond 氏によるとJVTはcomparable to the "mpeg" matrix of mpeg-4 aspとの事。ならば横幅640以上ではせめてJVTはマストだと思う。外部ファイルの作成 MeGUIは "MEncoder GUI" だが、ffmpegXと同様、様々なツールが詰まっているようだ。こうしたエンコード・スイートにはマトリクスエディタが付属している事がある。 MEncoder 本体の機能にカスタムマトリクスエディタは見当たらないので、テキストエディタか。
--cqmfile <string> カスタムマトリクスを使いたければ、このオプションが他よりは実用的だろう。このオプションで外部マトリクスファイルを読み込める。読み込めるのはJM互換形式（JMはレファレンスエンコーダ）。Doom9に外部マトリクスのリストがある。他の全ての--cqm関連オプションに優先。
--cqm4 <list> 全ての4x4量子化マトリクスの指定。入力はカンマ区切りの16個の整数でなければならない。このオプションは実験には良いかもしれないが、コマンドラインがひどく長くなる。特に他の量子化マトリクスも指定するなら尚更だ。	--cqm4i 輝度と彩度	--cqm4iy 個別設定	cqm4iy=<list> (also see cqm) 4x4イントラ輝度。コンマ区切り整数16個、各数値の範囲は1-255。
	--cqm4i 輝度と彩度	--cqm4ic 個別設定	cqm4ic=<list> (also see cqm) 4x4イントラ彩度。コンマ区切り整数16個、各数値の範囲は1-255。
	--cqm4p 輝度と彩度	--cqm4py 個別設定	cqm4py=<list> (also see cqm) 4x4インター輝度。コンマ区切り整数16個、各数値の範囲は1-255。
	--cqm4p 輝度と彩度	--cqm4pc 個別設定	cqm4pc=<list> (also see cqm) 4x4インター彩度。コンマ区切り整数16個、各数値の範囲は1-255。
--cqm8 <list> 全ての8x8 量子化マトリクスの指定。入力はカンマ区切りの64個の整数でなければならない。ほか、前項に同じ。	--cqm8i 輝度と彩度	-	cqm8iy=<list> (also see cqm) 8x8イントラ輝度。コンマ区切り整数64個、各数値の範囲は1-255。
	--cqm8i 輝度と彩度	-	-	cqm8ic がないのは入力がYUV4:2:0限定だから？
	--cqm8p 輝度と彩度	-	cqm8py=<list> (also see cqm) 8x8インター輝度。コンマ区切り整数16個、各数値の範囲は1-255。
	--cqm8p 輝度と彩度	-	-	cqm8pc がないのは入力がYUV4:2:0限定だから？

　自分でカスタムマトリクスを作ろうという人は、『アニメエンコで役に立つかもしれない覚書」の06-03E　カスタムマトリクスにて解説されています。

余談：

いまさらアレなんだけどぶっちゃけx264って使い物になんねぇと思う事があります。闇階調のブロックノイズを目にする事がXvidに比べて多過ぎ。これを解決する手法が素材種別に応じたカスタムマトリクスを探して使い分ける他に無いのなら、それは退化です。
　それでなくとも実際のアプリケーション（利用用途）がXvidとほぼ競合する以上「画質が良い」だけでは死亡フラグ確定。JPEG2000とかSACDとかD-VHSとかDATとか。開発初期段階にあるものに実用上の文句を言っても仕方がありませんが、ポテンシャルが高いだけに惜しい。Xvidよりキレイに、Apple-H.264より速くできる事は確かですが、やれる事多すぎて却って使い勝手が悪い事も確か。進化の袋小路な印象もあります。

　・・・という感じなので、当面手許ではcqm=jvt固定、オプションでなんとかする方向で行きますが、白黒映画だけはカスタム量子化に手を出すかもしれません。

[ 2006/12/11 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(0)

3.4. Analysis options_マクロブロック単位QP変更（Sharktooth版固有）

概説

x264のレートコントロールの性質概要
　H.264 はマクロブロック単位でQPを変える事ができるが、x264では採用していない。QPはフレーム単位だ。1フレーム内部の全マクロブロックに単一のQP値を使う。
　
　※ 画質的にはマクロブロック単位 QPのほうが有利と思われる。例えば画面右半分が静止画像、左半分が激しく動く場面など。この差はHDTVで効いて来ると思う。反面、実装は地獄じゃろうねぇ。

　上記はソースコード内の付属文書。Encoding H.264 using the x264 Command Line Interface（Zero1氏）にこれと矛盾する妙なオプションがあった。どうもマクロブロック単位QP変更を前提にしたオプションに見えたのだが、手許では見た記憶が無くtracで検索しても過去に存在した形跡も無い。覚書（なるP氏）の掲示版にて当該オプションに覚えが有る人がいないか聞いてみたところ、、、、

　どうも Sharktooth 版のみ、マクロブロック単位QP変更ができるらしい。
　muken氏によると、

Sharktooth氏(Doom9's forum)のビルドでは、rev602でエラーを吐かない（オプション指定を認識したというだけで実装を確認したわけではない）
bob0r氏(Jarod), celtic_druid氏, clef氏(icl版), seraphy氏, Sylphide氏(Lunatilia)のビルドではこのオプションを指定するとunknown option
http://mirror05.x264.nl/Sharktooth/から<dir>のx264に入り、 docsとpatchesを取得できる。

との事です。Zero1氏の記述によるとあまり大規模なものではなく、大きな青いエリアにブロックノイズが出たら弄れとしています。

Analysis オプション：Sharktooth版固有の機能

x264cli (rev600準拠)	MEncoder -x264encopts (dev-SVN-r20806 準拠)

--aq-strength　[0.0]

対応無し　[]

■ まとめ：

特に無し

■ 参考

覚書（要約）記載無し	手許 Haaliが何/誰なのか自分は知らないです。タマに妖精現実さんとこで見るけど。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01）記載無し	man MEncoder 記載無し
zero1(svn408) Usage: --aq-strength <float> (default=0.0) 適応的量子化の設定の一つ。適応的量子化は特定フレームの内の一部に異なった量子化値を使えるようにするもの。通常はフレーム全体が同一の量子化値を使う。Xvidでは明るい部分や暗い部分を高圧縮にしてより目立つ部分にbitを回す事ができたが（＊サイコビジュアル・エンハンスメント＊）、それに相当する。適応的量子化はx264ではやや挙動が異なる。というのは大きな青いエリアでブロックが出るという問題に対処する為にHaaliが追加したものだからだ。 x264 の適応的量子化は暗いエリアや青いエリアに回すbitを増やしてこれらのブロックノイズを緩和するものだ。この設定は、QP per Macroblockの調整。 0.0で適応的量子化オフ。 1.1 はかなり強いとされる。他の部分が問題無いにも関わらず、青いエリアがブロッキーだった時に調整するのがお奨めの使い方だ。	MEncoder Doc 記載無し

--aq-sensitivity　[15.0]

対応無し　[]

■ まとめ：

特に無し

■参考

覚書（要約）記載無し	手許特に無し
MeGUI2.0 Help（ContextHelp v0.2 06/01/01）記載無し	man MEncoder 記載無し
zero1(svn408) Usage: --aq-sensitivity <float> (default=15.0) --aq-strengthと一緒に使う。--aq-strengthが0.0か、未指定の時はなんの動作もしない（デフォルトはdisableだから）。このオプションでは適応的量子化の際の "flatness"閾値を指定する。5でほとんど全てのブロックに適応的量子化をかける。22でフラットなブロックだけに適用。ここでフラットなブロックとは、単色か、ほとんどディテイルの無いブロックを指す。	MEncoder Doc 記載無し

[ 2006/12/11 00:30 ] ごみ箱　-x264encopts | TB(0) | CM(1)

4. Video Usability Info (Annex E):

概説

Video Usability Info (Annex E):

	The VUI settings are not used by the encoder but are merely suggestions to

	the playback equipment. See doc/vui.txt for details. Use at your own risk.

"VUI 設定はエンコーダが使うものではなく、再生設備に対する付加情報に過ぎない。詳細はdoc/vui.txt参照。自己責任で使う事。"
doc/vui.txtを試訳してみたところ、やはりデコーダ向けの参考情報で生成データをどうこうするものではない。使いこなすにはTVやカラープロファイルなどの"しくみ"に精通している必要がありそうだ。
　例えばこれらを使って暗部のブロックノイズが潰せたとしても、原理的には暗部のブロックノイズをモニタの輝度調整で潰すに近い。効果は視聴環境（部屋の明るさ、TVに出す場合は画質プリセットの選択）により大きく変わる。これらはそうした微調整の自動化で、視聴環境（デコーダ、再生機器、モニタの種別）のサポート次第だ。
　x264cliがこれらをサポートする理由は、規格にあるからという事もあろうが、特に北米ではTV出力する据え置き型Divx/MP4プレイヤが盛んな事もあるだろう。

　手許ではこれらの設定に頼らず、生成データのレベルでなんとかする方向（てゆうかMEncoderの対応オプション探してないだけとも言う）。

　man MEncoder、MEncoder Doc、MeGUI2.0 Help（ContextHelp v0.2 06/01/01）には記載未発見。

Video Usability Info (Annex E)オプション

x264cli (rev600準拠)	MEncoder -x264encopts (dev-SVN-r20806 準拠)

--overscan <string>　[undef]

対応不詳

■ まとめ：

Specify crop overscan setting ["undef"]
- undef, show, crop

■ 参考

VUI Guide: これは何？
一般的に"オーバースキャン"という用語は映像の内、情報を含まないが、特定の解像度やアスペクト比を維持するために付加された領域の全てを表します。従って「レターボックス化」された映像には上下に"オーバースキャン"が付いています。
しかし、このオプションが扱う"オーバースキャン"は意味が異なります。またアナログ信号をデジタル化する過程で付加される"オーバースキャン"でもありません。
ここで言う"オーバースキャン"とは、ディスプレイ上で映像の一部分だけを表示させるという意味です。"どの一部分"なのかはディスプレイに拠ります。
　
使い方
ディスプレイがオーバースキャン・プロセスを使う際に映像のどの部分が表示されるか、私には正確なところが解りませんので、ここで方法や例示を書くことができません。
"overscan=show"が安全であろうかと思います。というのはこれは常に映像全体を表示する信号だからです。
"overscan =crop"は影響が確実に解っている場合にのみ使って下さい。
またデフォルトの"undefined"も使って大丈夫です。
　; このオプションは使った方がよいですか？
正確に理解している場合に限って、はい。
一般的な意味での"オーバースキャン"がある映像ストリームには使わないで下さい。その場合はエンコード前に黒帯をクロップして高ビットレート/高画質を狙って下さい。さらにH.264規格には"overscan=show"の設定が優先されるとありますが、"overscan=crop"の設定は無視される事があり得る、ともあります。実際、多くの再生機器（※equipment、ソフトも含むか？）ではこの設定を無視して映像全体を表示します。

手許: 『改訂版H.264/AVC教科書』の索引に「クロッピング処理」なる記述があった。デコード後、画面に表示する前に出力する画像の形態に合わせて上下左右の画素を切り出す処理、との事。

同書p183に以下の文言有り。"例えばHDTVの場合、走査線の数は1080本です。これに対してH.264/AVCでは垂直、水平方向とも16画素の倍数でないと符号化できません（1080本は16の倍数ではない）。例えば、1088本（16の倍数）を符号化した場合、8ラインを捨てて表示する必要がありますが、この場合、クロッピング処理によって、ビットストリーム中でどの上下8ラインを捨てるのかを明示的に指定する事ができます。"

特にインタレ保持をテレビに出す場合、対象機器のデコーダの性能によっては、考慮しても良さそうだ。

zero1(svn408): Usage: --overscan <string> (default=undef) [undef, show, crop]; 　編集ガイドや再生ガイドにも書いてありますが（＊x264以外のガイドもたくさんある＊）、TVは映像を全部表示しているわけではありません。10～ 20%ばかりはロス（＊表示されない領域＊）があります。これはブラウン管（＊tube＊）を有効活用するために、スクリーンにブランクスペースが出ないようにするためです。; 　NTSCの走査線は525ラインありますが、そのうち実際の映像を含んでいるのは大体 486ラインです。もしoverscanがなかったら、TVは525ラインを全部表示するでしょう。これはつまり、上下に黒帯が出ると言う事です。映像の両サイドにも普通はブランクデータがあります。実データの横幅が704-711"pixels"のDVDでは一般的に、横幅を720ピクセルにするべく黒帯が付加されます（これがMPEG-2の横幅が16の倍数でなければならない理由です）。; 　さてそれでは、映像データにoverscanがなかったらどうなるでしょうか？事実上Cropされたかのように表示されます（overscanのために、データはあっても表示されない）。ここが--overscanオプションの使い道です。; 　"--overscan show"でズームアウトして映像全体表示。; 　"--overscan crop"で通常通り端っこを切り落として表示。; 　この設定はハードウェア側の対応が必要です（ソフトの場合も必要ですが、どのみちPCモニタにoverscanはありません）。この機能を実装していない再生機器の場合、--overscan設定は無視。なにを設定していようとcrop表示になります。

--videoformat <string>　[undef]

対応不詳

■ まとめ：

Specify video format ["undef"]
- component, pal, ntsc, secam, mac, undef

■ 参考

VUI Guide: これは何？; 純粋に参考的な（※informative）設定。デジタル化される前のアナログ映像のタイプを示す。; 　; 使い方; NTSCやPALなど、好みの値を入れるだけ。; MPEG2 からトランスコードする場合、素材のm2vビットストリームの中にこの値が見つかるかもしれない。（詳細は ITU-T Rec. H262 / ISO/IEC 13818-2参照。）; 　; このオプションは使った方がよいですか？; これは完全にあなた次第です。; この設定が何かに影響を及ぼすと言う事は考えられません。私は純粋な付加情報に過ぎないと考えています。

手許: 地アナTVキャプチャなので入れるとすればntsc。

zero1(svn408): Usage: --videoformat <string> (default=undef) [component, pal, ntsc, secam, mac, undef]; ただの参考情報の（※ informative）設定。ファイルに付けるメタデータに似ている。ソースの種類を指定できる。ただの付加情報なので再生にもエンコードにも全く影響しない。

--fullrange <string>　[off]

対応不詳

■ まとめ：

Specify full range samples setting ["off"]
- off, on

■ 参考

VUI Guide: これは何？
アナログ映像のデジタル化に関わるもう一つの遺物。
アナログ映像をデジタル化する際、輝度と彩度のレベルがそれぞれ16..235 と 16..240の範囲に制限されます。
通常、再生機器（※ equipment、ソフトも含むか？）は全てのデジタル化されたサンプルがこの範囲内にあると想定しています。
しかしながら、大半のDVDでは輝度も彩度も0..255のフルレンジを使っています。
こうしたDVDをそのような再生機器にかけた場合、オーバーサチュレーションが起きる可能性があります。
これを避ける為にはレンジ補正が必要となります。
使い方
素材がデジタル化されたアナログビデオ/TV放送なら、取り込み時にレンジが限定されている可能性が非常に高いです。
限定されている事が確実なら、--fullrangeはoffのままで安全です。
確実でない場合や、オーバーサチュレーション抜きで再生できているか確認したい場合は、onにしてみましょう。
x264のデフォルトはoff である事に注意して下さい。これは"安全"ではありません。
このオプションは使った方がよいですか？
はい。
しかし、このオプションを理解できるデコーダ/メディアプレイヤはごく少数です。

手許: 地アナMPEG2キャプチャでどうなってるか不明。念のためCMカットの段階でレンジ変換してやるべきかも知れない。; --fullrange onにするとTVに持って行っても大丈夫そうではある。

zero1(svn408): Usage: --fullrange <string> (default=off) [on, off]; これもTVを主眼とする設定。TVは輝度レンジ16-235、彩度レンジ16-240を想定している。これはTVで見る限りは大丈夫だが、PCモニタでは黒がダークグレイに、白はライトグレイになってしまう。PCモニタで見る場合は、AVISynthでレベルを調整しても良い。こうした事を知らなくても、素材映像が16-235にならないような調整をしている場合もある（例えば、pure black, pure white, or pure saturated coloursを使っている場合）。; これに加え、DVDの中には0-255のフルレンジを使ったものもある。ならばTVで0-255のフルレンジを使っても問題は無いのではないかという気もするが、これは規格上正しく無い。オーバーサチュレーションが起きる。; "--fullrange on"は再生時のレンジ補正（0-255 to 16-235）。これでTVに映しても大丈夫（H.264デコード対応プレイヤの場合）。; PC モニタは0-255（以上）を表示できるので、ソフトウェアプレイヤはこの設定を無視する傾向にある。レンジ補正無し、そのまま0-255で出力。だから onでどちらで表示しても問題無い。; "--fullrange off"を使っても平気なのは素材映像のレンジが16-235の時だけです。

--colorprim <string>　[undef]

対応不詳

■ まとめ：

Specify color primaries ["undef"]
- undef, bt709, bt470m, bt470bg
smpte170m, smpte240m, film

■ 参考

覚書（要約）次項参照	手許次項参照
VUI Guide 次項参照
zero1(svn408) 記載無し

--transfer <string>　[undef]

対応不詳

■ まとめ：

Specify transfer characteristics ["undef"]
- undef, bt709, bt470m, bt470bg, linear,
log100, log316, smpte170m, smpte240m

■ 参考

覚書（要約）詳細不詳だが、カラーマトリクスは、コレを使ってますよと、宣言するのに--transferを使う。　使うと暗部のブロックノイズが軽減される傾向。　 ------------------------------------------------------------- Rec709 (bt709)　　→　720p(PAL型HDTV風味?)的なカラーマトリクス smpte240　　　　　 →　1080i(NTSC型HDTV風味?)的なカラーマトリクス Rec601(bt601)　　& amp; amp; rarr;　480i,480p的なカラーマトリクス smpte170　　　　　→　コンポジットNTSC (SDTV)的なカラーマトリクス Rec470(bt470)　　→　PAL(SDTV)的なカラーマトリクス　　 ∴Rec709≒smpte240m　,　Rec601≒smpte170　…厳密には違うので悪しからず。 ------------------------------------------------------------- bt709, smpte240m, smpte170m。この三つから選ぶといい印象。	手許闇階調ブロックノイズは生成データのレベルでなんとかしたい。
VUI Guide 5. Color Primaries, Transfer Characteristics, Matrix Coefficients これは何？映像マニア（※videophile）の設定。平均的なユーザにとって必要なものでは、ぜんぜんないです。　全てのモニタが全ての色を同じように表示するわけではありません。同じ映像を別モデルのモニタ２個で見比べるとどちらか片方が"青っぽく"、もう片方は"緑っぽく"見える事でしょう。結論から言うと、モニタはモデル毎に異なったカラープロファイルを持っています。これは全てのモニタで映像がだいたい同じに見えるように色を補正するためのものです。プリンタやフィルム/ビデオ・デジタイザなども同様です。デジタイザ機器のカラープロファイルが解っていれば、デジタイザ機器を使っていようがいまいがデコード後のh264ストリームの色やガンマを補正する事が出来ます。　使い方自分のデジタイザ機器の特性を見つける事ができれば（see the equipment documentation or make reference measurements）、概ね見合った特性をH264 Annex Eの特性リストから探してx264に渡す事ができます。または、デフォルト (unspecified)のままほっとくか。 MPEG2 からトランスコードの場合、m2v bitstreamの中にこのオプションのための値が書いてあるかもしれません。（詳細はITU-T Rec. H262 / ISO/IEC 13818-2参照）　このオプションは使った方がよいですか？自分が何をしているかキッチリ理解している場合に限って、はい。このオプションを使うのは悪い考えではありませんが、デフォルトの設定は間違ったものよりマシです。残念な事に私はcolor/gamma/color matrix補正に対応したデコーダ/メディアプレイヤを、それを試みようとするものさえ、見た事がありません。
zero1(svn408) 記載無し

--colormatrix <string>　[undef]

対応不詳

■ まとめ：

Specify color matrix setting ["undef"]
- undef, bt709, fcc, bt470bg
smpte170m, smpte240m, GBR, YCgCo

■ 参考

覚書（要約）: 前項参照

手許: 前項参照

VUI Guide: 前項参照

zero1(svn408): 記載無し

--chromaloc <integer>　[0]

対応不詳

■ まとめ：

Specify chroma sample location (0 to 5) [0]

■ 参考

VUI Guide: 6. Chroma Sample Location
これは何？
映像マニア（※videophile）の設定。平均的なユーザは違いに気付く事さえないでしょう。
人間の視覚の弱点（※色彩認識力は輝度のそれに比べて弱い）を利用して彩度サンプルを間引く事をサブサンプリングと言います。
特にx264では、2x2輝度サンプルブロックに対応する彩度サンプルは一個だけです。
こうしたサブサンプリングを行う方式には様々なものがありますが、結果はどれも輝度サンプル値に対する彩度サンプル値の相対位置を出すものです。彩度サンプル・ロケーションはサブサンプリングプロセスを逆回転させる時（※再生時）に効果が出ます。即ち、彩度サンプルの数が増やされるわけです。多くの場合、これはカラースペース変換の際に行われます。この工程が正確でないと、多くの場合、彩度の値が輝度サンプルに対して1ピクセルずれた位置に現れます。または奇妙なボケ。; 　; 使い方
x264 はサブサンプリング済みの入力フレームしか受け付けないので、サブサンプリング能力を持たない。従って彩度サンプル・ロケーションの方式は自分で設定する必要がある。
　適切に4:2:0サブサンプルされたMPEG1のトランスコードで、カラースペース変換を一切行わない場合、オプション指定値は1。
　適切に4:2:0サブサンプルされたMPEG2のトランスコードで、カラースペース変換を一切行わない場合、オプション指定値は0。
　適切に4:2:0サブサンプルされたMPEG4のトランスコードで、カラースペース変換を一切行わない場合、オプション指定値は0。
　カラースペース変換を自力で行う場合、これは簡単な事では無い。
　サブサンプリングのフィルタ・カーネルが一方向の( 0.5, 0.5 ) の場合、その方向の彩度サンプリング・ロケーションは２個の輝度サンプルの間になる。
　サブサンプリングのフィルタ・カーネルが一方向の ( 0.25, 0.5, 0.25 ) の場合、その方向の彩度サンプリング・ロケーションは輝度サンプルうち一つと同じになる。
　H264 Annex E には彩度サンプル・ロケーションをx264に渡せる0～5の形式に"トランスフォーム"する方法を示す図が入っている。
　
このオプションは使った方がよいですか？
完全主義者でなければ気にしないで下さい。メディアプレイヤはこの設定を無視して固有の（固定の）彩度サンプル・ロケーションを使います。

手許

zero1(svn408): Usage: --chromaloc <integer> (default=0) [0 - 5]
彩度のアップサンプリングに関わる極めて技術的な設定。例えばカラースペース変換や再生など。正しく使う事ができればクロマシフトやブラーを緩和できる（ほとんどの場合、ズレは1ピクセルくらいなので目立たないが）。; もし素材映像を編集してあれば、その段階でカラースペース変換は終わっている（ほとんどの編集ソフトはRGBを使う）だからこの設定は必要すらない（さらに平均的な人はその違いにすら気付かない）。カラースペース変換を経ていない直エンコでない限り、この設定の使用はお奨めはしません。; しかしながら万全を期す為に大まかな指針を書いて置きます：; 素材がMPEG-1 (4:2:0) かつ direct transcode (no colourspace conversion)の場合、1を指定。
素材がMPEG-2 (4:2:0) かつ direct transcode (no colourspace conversion)の場合、0を指定。
素材が MPEG-4 (4:2:0) かつ direct transcode (no colourspace conversion)の場合、0を指定。

[ 2006/12/12 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(0)

| ホーム |
Page Top↑

Index

・表紙
・全記事一覧
・ここについて
・人気記事
・x264関連
・ageha更新終了の辞

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

-G-

-A-

タグ検索

カテゴリー

Script by 絵板のマナー講座
and 毒吐きネットマナーPlus

Archive R

2013 09 (1)
2008 02 (1)
2007 11 (11)
2007 10 (12)
2007 09 (6)
2007 08 (212)
2007 07 (2)
2007 06 (8)
2007 05 (16)
2007 04 (22)
2007 03 (23)
2007 02 (17)
2007 01 (20)
2006 12 (24)
2006 11 (41)
2006 10 (39)
2006 09 (22)
2006 08 (17)
2006 07 (4)
2000 02 (1)

管理/なかのひと

StyleKeeper

StyleChanger

覚書（要約）記載無し	手許常時使用
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） no-b-adapt name="Adaptive B-frames" 推奨：Enabled default： Enabled B フレーム挿入の際に定数ではなく、x264に挿入枚数を必要に応じて決めさせる。 Bフレームが不適当な箇所で Bの連続数が減る。	man MEncoder bframes=< 0-16>で指定された最大Bフレーム数の範囲で、いつ、どれだけの数のBフレームを使うか自動的に決断する。オフの場合、前述のbframes=<0-16>(デフォルトで0)の最大Bフレーム数を使用する。
zero1(svn408) Usage: --no-b-adapt (default=on) 　このオプションは適応的Bフレーム挿入をオンにするもので、一般的にはお奨めできない。このオプションを使うと（デフォルトはenable。--no-b-adaptで切る）x264がどこにどれだけのBフレームを使うか自動で決める。（＊最大？＊）何枚使うかは上記の--bframesで決まる。（＊:Zero1氏の記述根拠不明。下記とも矛盾。未推敲箇所と思われ。＊）	MEncoder Doc : Note: defaultでオン。　このオプションを使うと、エンコーダはまずまず合理的な速度で、B-frameの効果の薄いシーンのB- frame数を減らす計算をします。b_biasを使って、間引く程度を調節できます。adaptive B-frameの速度低下は目下のところは慎ましいものです。しかし望み得る画質向上の程度も同様です。まぁ、通常は害はありません。1stパスの速度とフレームタイプの決定にしか影響しない事に注意して下さい。b_adapt と b_bias は後続のパスにはなんの影響もありません。

覚書（要約）（＊前項から＊）　デブロックフィルタ使ってると、細部が潰れるので気になるときがある。　そういう時は、コレ使ってデブロックフィルタ切ったほうがいいかもしれない。	手許常用0,0（デフォルトまま）インループ・フィルタ、インライン・デブロック、などなど様々な名前があるが、コデックの中にデブロック・フィルタを取り込んだもの。ブロックノイズはMPEG系の宿命で、気にならなくてもJPEG同様に必ずあるもの。Xvidなど向けに再生時にデブロックフィルタをかける再生ソフトでは機能がバッティングする模様。　手許では切らず弄らず、下記Docの紫部分を根拠にI/IDR枚数を必要最小限に抑え込むアプローチを取っている。自分の理解が正しければ、これでI/IDRのQP値が地味に下がり、デブロックの起動回数を地味に減らせる筈だ。　アニメに関して。覚書では細部の潰れが気になる際には切るべきかもとあるが、Sharktooth氏の"アニメは3:3"というのは50%に及ぶ強化であり、妖精現実さんも"悔しいがアニメは奇麗"の根拠の一つにこのインライン・デブロックを挙げている。覚書氏は2000kbps 程度を常用されているようなので、ここが意見の差の原因かもしれない。そろそろx264のbpp表がどこかに出て来てもよさそうだが…。手許では1024kbps固定、電器屋さんの話では地アナの電波状態も悪い一帯らしいので、細部が地味に潰れると聞くとつい「使えるか？」と考えてしまう。　なお、Apple-H.264ではデブロックを切れず、弄れない。 bitrateを下げてゆくと、薄いガラス越しに見たような->薄い水槽越しに見たような->水刷毛で叩いてますか？->印象派の油絵。という感じで段階的に画質が変化する。これが"スミア"と思われる。画像全体がパンしてるようなとこを640x480、400kbpsくらいで油絵が見れるかと。効き始めは劣化というより「クリアパネル液晶を買った覚えはないですが？」というカンジ。意地でもブロックはお見せしませんチューン。画質"破綻"と言えるほどのものを作る手段は他に見当たらず、時間さえガマンすれば簡単にXvidを圧倒できそう。このあたりのさじ加減は流石に巧い。なんでProキーって有償なんだろう？　 Doom9 コデックコンテスト2005-メインラウンド（Matrix3）では-1:-1。決勝ラウンド（プライベート・ライアンとスチームボーイ）はデフォルト。これはx264開発者が提案した設定。Doom9氏はMatrixでフィルムグレインが結構ちゃんと残ると言っている。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） filter name="Deblocking (in loop) Filter Strength" Recommended： 0:0 Default： 0:0 Deblocking Threshold（＊スレショルド=閾値＊）はブロック検出精度の調整。Deblocking Strength はデブロックをかける強度の調整。デフォルトでデブロッキングとディテイル保持のバランスは周到なものになる。調整範囲は-6 から 6 が良いだろう(低くするとデブロッキングは減る。マイナスはNegative values do not indicate the deblocking effect is reversed)。高くしすぎるとディテルとテクスチャのロス、またはスミアに繋がる。低くしすぎるとブロッキーになる。一般的にはプラスにするなら両方ともプラスに指定するのが望ましい。すなわち、デブロッキングを強くするならthresholdもプラスにするとデブロックされるデータが増える。	man MEncoder 旧称： deblockalpha=<-6-6> 、deblockbeta=<-6-6> 第一のパラメータは AlphaC0 (default: 0)。これはH.264のイン-ループ・デブロッキング・フィルタの閾値。まず、このパラメータの値に従ってデブロックを使うか否かを決める。次に、このパラメータはフィルタを適用するエッジ部分の差の閾値に影響する。プラスの値にする事でブロックノイズが減るが、スミアが増える。第二のパラメータはBeta (default: 0)。これはディテイルの閾値に影響する。非常にディテイルの細かいブロックにはフィルタを掛けない。というのはこのフィルタが使うスムージングはブロックノイズよりも目立つからだ。このフィルタはデフォルト値でほとんど常に最良の結果になるので、そのまま弄らないか微調整にとどめるのがベストだ。しかし素材になんとかしたいほどのブロックノイズやノイズがあるなら、少し強めにしても良いだろう。　（※スミア：こすりつけたような汚れ）
zero1(svn408) Usage: --filter <alpha:beta> (default=0:0) [-6:-6 - 6:6] 　通常、インループ・デブロッキングは圧縮効率、ひいては画質を向上になる。効果が気に入らない時は単に値を下げると良い。　このオプションのねらいは、Xvidのハイモーション箇所で見られたようなブロックノイズのスムーシングだ。　AlphaC0 は強度、Betaは閾値。デフォルトの0:0は最適値として考えられたものだが、Sharktoothによればアニメは3:3が良いとの事。　短いクリップをいくつか用意して実験すると良いだろう。	MEncoder Doc （＊deblockalphaとdeblockbetaは旧称、またPSNRしか考慮していない事に注意＊） : このトピックはやや議論の分かれるところがあります。 H.264 規格にはシンプルなデブロック手段があります。これはI-blockに適用されるQPに基づいて、あらかじめ決められた強さと閾値に基づいてフィルタをかけるものです。デフォルトではQPの高いブロックには強いフィルタがかけられ、 QPの低いブロックはデブロックされません。規格で決められているプリセットの強度は慎重に決められたもので、どんな素材をエンコードしても非常に良いPSNRがでる公算が非常に高いものです。deblockalphaとdeblockbetaは、このプリセットのデブロック閾値を調節する為の物です。多くの人はデブロックフィルタの強さを大幅に弱めるのが良いと考えているようです (例えば-3とか)。しかしながら、これは決して、と言っても良い程、良い考えとは言えません。そしてほとんどの場合、こうした調節をしている人はデフォルトのデブロックの理屈を理解していないようです。まず、in-loop デブロックフィルタを知る上で最も大切な事は、デフォルトの閾値はほとんど常に、最適なPSNRをもたらすという事です。 PSNR が最適にならないケースは稀です。従って望ましいオフセットはプラスマイナス1。それ以上はほぼ確実にPSNRの低下になります。フィルタを強くすると、ディテイルの汚れが増え、弱めると目に見えるブロックノイズが増えます。空間軸の複雑さが少ない素材（例えばディテイルやノイズが少ない）でデブロック閾値を下げるのは、マズいと断言します。こうした素材で発生するアーティファクト（＊意訳すると副作用＊）の封じ込めにかけては、in-loop フィルタは素晴らしい仕事をします。他方、空間軸の複雑さが多い素材でも、アーティファクトは目につきません。なぜなら、リンギングがディテイルやノイズのように見える傾向があるからです。人間の視覚認識はディテイルの損失には敏感ですが、間違ってノイズが描きだされても簡単には認識できません。これは、人間にとっての主観的な品質ということでは、ノイズとディテイルは、ある程度互換性があると言う事です。deblockingフィルタを弱める事は、リンギング・アーティファクトを増やす事になります。ですが、人間の目はこれをディテイルと誤認識します。しかし、これもデブロックフィルタの強度を弱める理由にはなりません。一般的に、ポストプロセッシングでもっと良い品質のノイズを得られるからです。もし、あなたのH.264エンコードがブラーや、スミア（＊smeared：擦って不鮮明にする＊）が多すぎたら、再生時に-vf noiseを試してみて下さい。マイルドなアーティファクトなら -vf noise=8a:4a でほぼ封じ込めることができます。これでデブロッキングフィルタをあれこれするより、ほぼ確実に、良く見えるでしょう。

覚書（要約） 704x480で1600～2500 といった数値が見える。 bpp概算で"まずまずだがブロックノイズが見える（0.2）"～"無意味。むしろ解像度を上げるべし（0.3）"の範囲と思われる。手許（ageha）とは大幅にスタンスが異なる事に注意。特に画質に対する主観評価で違いが出て来ると思う。覚書（なるP氏）の方が画質に厳しい筈だ。ここまでbitrateに差があると、細部の設定方針も大幅に差があるハズ。	手許横幅640、1024固定。 bpp概算で"低画質(0.15)"～"まずまずだがブロックノイズが見える (0.2)"の範囲。覚書（なるP氏）とは大幅にスタンスが異なる事に注意。特に画質に対する主観評価で違いが出て来ると思う。自分の方が画質に甘い筈だ。ここまでbitrateに差があると、細部の設定方針も大幅に差があるハズ。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） bitrate name="Bit Rate" Recommended： N/A Default： N/A Set bit rate per second (kbps)	man MEncoder 平均ビットレートの指定。単位kbit/sec(default: off)。ローカルビットレートは変動するため、非常に短いムービーでは指定値とかけ離れた値になる事がある(ratetol参照)。このオプションと vbv_maxrateを同時に使うと固定ビットレートになるが、画質は著しく劣化する。　＊ローカルビットレートビットレート配分を計算する際の単位となる区間の模様。平均化区間というコトバも散見される。1パスでも使う。つまり少なくともx264には、固定ビットレートエンコードや固定quantizerエンコードを想定していない。できない事はないが、全体的なオプションの構成やデフォルト値がそういう作りになっていない。
zero1(svn408) Usage: --bitrate <integer> (default=off) 平均ビットレートの指定。単位Kbps(kilobits per second)。特定のファイルサイズにおさめたければ、推奨方式は2パスだ。特定ファイルサイズと画質が両立できる。1分程度より短いクリップでは3パスが有効な事もある。 x264 の --bitrate は本質的にABR（平均bitrate）でもしCBR（固定bitrate）を使わなければならないなら（ストリー民具以外にCBRのメリットはほぼ無いが）、--vbv-maxrateも弄る必要がある。	MEncoder Doc -

覚書（要約）・3の命令が、 statsファイルに上書きする。2の命令はしない。　すなわち2passならば、1→2 　3pass 以上ならば、1→3→3→…→3→ 2　と、実行させる。　50passぐらいまでは、+ 10pass増えるごとに画質が全く違うモノになる。　そこから100passぐらいでは、+20passごとで、変わる感じ。　主に、輪郭などの鮮明さで、差が出てくる。	手許パス数 NTT研究所でも数十パスで1080pを1.8Mビット/秒にできるとしている。 Apple-H.264 パス数指定不能。フロントエンド次第の模様。QTPlayer Proは5程度。 raw2qt264で強制的に2パスでやるとたかが落語で豪快なブロックノイズが出た。動き補償、なかんずくモーションベクトル・サーチ精度に問題か。　現状では、土台のショボさを多段パスで隠蔽したものに過ぎず、なによりあまりにも遅い。心情的には"最先端技術"は誇大広告と言いたいほどだが、4Core x 2クラスが一般的になってくるとasmプログラミングに頼らずとも相当の高速化を果たす公算が高い。設定の簡便さ、狙っても画質破綻を引き起こせない安定性を考えるとx264のアドヴァンテージは必ずしも大きく無い。特に画質に文句を付けている意見は見た事が無く、Bond氏も"rather good"としている。画質に関しては一度はApple-H.264を試して頂きたい。Mac/Win問わずMPEG Streamclipで試せる。　自分の見立てでは、普及度の面でXvidとQT互換H.264、そしてflvの後塵を拝しているx264は、中期的（2～3年）にはむしろ瀬戸際にある。2007年中の進化速度が天王山だろう。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） pass name="Multipass Mode" Recommended： Enabled Default： Disabled マルチパス・レートコントロールをenable	man MEncoder 2または 3パスモードの指定。最適なビットレート配分と全体の画質向上の為には、2か3パスエンコードを推奨。　1 1st パス　2 2nd パス (または2パスエンコード) 　3 Nth パス (3pass エンコードの 2nd と 3rd パス) 理屈と使い方： 1st pass(pass=1) 映像の統計を取ってファイルに書き込む。 CPU負荷の高いオプションは使わなくて良いが、デフォルトでonのものは使う事。 2nd pass(pass=2) stats(＊統計＊)ファイルを読み込み、これを基にビットレート配分をコントロールする。 3pass モードでの2nd("pass=3"。誤字ではない) 上記の両方を行う。最初に統計を読み込み、上書きする。CPU負荷の高いオプションを除き全てのエンコードオプションが使える。 3rd pass(pass=3) 2nd passと同じだが、2nd passの統計を使用する。CPU負荷の高いオプションを含めて、全てのエンコードオプションが使える。 1st pass はABRでも固定quantizerでも良いが、quantizerを推測する必要がないので、ABRの方が望ましい。後続のパスはビットレートを指定するABRでなければならない。
zero1(svn408) Usage: --pass <1\|2\|3> マルチパスモードの起動。 1st と2ndについてはXvidで慣れている人も多いだろう。 "nth pass"というものが増えた。これは、1stパスで統計情報を採り、次の2回目にnth passを走らせるというものだ。結果が気に入らなかったり、ファイルサイズがオーバーしたりしたら、2回目のパスをもう一度実行できる。するとnth passはpass 3を実行する。　 Nth passは一回ごとに統計情報をアップデートしてゆく。 2nd passは単に最終パスを実行するだけで統計をアップデートしない。　 --pass 1 Pass 1は映像分析と統計ファイルの書き出し。 Xvidにおける"2 pass - First pass"だ。デフォルトではmuxできるファイルを書き出す。このパスで bitrateを指定すると1 pass ABRとなる。 --qp 18などを指定すると、概ねXviDの full quality first pass mode同等の見た目のファイルができる。一般的には、この段階で bitrateを指定した方が、2nd 、nth passの結果が良い。 --pass 2 Pass 2はfirst passで得た複雑度の統計に基づいてレートコントロール関係の判断を下し、出力を生成する。Xvidの"2 pass - Second pass"といっしょだ。統計情報の上書きはしない。一般的に2 passはより良い画質とより小さなファイルサイズをもたらす。常時推奨。動作の視覚化は下記参照のこと。 (Pass 1) --pass 1 = 最初の統計収集 (Pass 2) --pass 2 = Pass 1 の統計を使って出力 --pass 3 --pass 3はいくぶん特別だ。これは２回目や３回目のパスという意味では無い。というのは何回でも無限に繰り返せるから。画質が無限に向上するわけでは無いので10パスはちょっと待てという感じ。現実的なメリットがあるのは、 1000フレーム程度より短い素材だけだ。こうした素材ではbitrate配分を最適化する時間が足りない（＊where it doesn't have much time to average the bitrate properly＊）。基本的に--pass 3は--pass 1 と --pass 2の作業を同時に行うが、最初の統計ファイルを作るにはpass 1が必要だ。 --pass 3は、単純に統計ファイルを読んで出力するだけでなく、統計ファイルもアップデートする。従って、nth pass modeを使った3 pass encodeではpass 2よりも精度の高い統計情報が使える事になる。このへんは視覚化すると理解しやすい。ここでpass 2を走らせるとpass 1の統計情報よりリファインされたものが使える。 (Pass 1) --pass 1 = 最初の統計収集 (Pass 2) --pass 3 = Pass 1 の統計を使って出力 + 統計情報のアップデート (Pass 3) --pass 3 = Pass 2 の統計を使って出力 + 統計情報のアップデート	MEncoder Doc Two pass encoding: 先に、常に2パスを推奨すると書きましたが、これが当てはまらないケースというのもあります。例えば、TVキャプチャのリアルタイムエンコードではシングルパスしか手が有りません。また、当たり前ですが1パスは2パスより速いです。両方のパスで全く同じオプションを使った場合、２パスエンコードはほぼぴったり２倍遅い事になります。　しかし、それでも2パスを使うべき理由。第一に、シングルパスのレートコントロールは心理的なものではありません(＊人の目で見てどうかというほどの意味＊)。さらに、映像全体を見る事が出来ない為に、しばしば妥当とはいえない選択をする事が有ります。例えば、２分のビデオがあったとしましょう。最初の半分は非常に動きの多い60秒のシーンで、奇麗にエンコードするには、その部分だけで2500kbps 必要だったとします。その直後には300kbpsで充分なシーンが60秒続くとします。このような場合、セオリーでは1400kbpsで充分ですが、シングルパスは２つの"ミス"をおかします。まず、どちらの部分にも1400kbpsを使おうとする事です。前半の60秒は過剰にquantize（＊量子化＊）され、ブロックノイズは受け入れ難い程になります。これは妥当とは言えません。後半の60秒では過剰にquantize（＊量子化＊）が控えられ、画質は完璧になりますが、それにかかるビットレートコストを考えると、まったく妥当とは言えません。２つのシーンの変わり目で起きる問題は、さらに厄介です。動きの少ない後半60秒のうち、最初の数秒はとんでもなく過剰にquantize （＊量子化＊）されます。というのは、レートコントロールはまだ前半の60秒で必要だったレベルの圧縮を続けてしまうからです。この動きの少ないシーンに発生したquantize（＊量子化＊）過剰の"エラー区間"は目障りで、実際、奇麗な映像に必要な300kbpsを下回ります。こうしたシングルパスの落とし穴を回避する手段はありますが、ビットレートの予測間違いを増やすという傾向があります。　レートコントロールにおける複数パスのアドバンテージはシングルパスよりも遥かに高いです。１stパスで記録した統計を使って、どんなquantizer設定でも、エンコーダは充分正確に各フレームに必要な"コスト"（ビット）を予測する事が出来ます。これにより、ずっと合理的にビットを動きの多いシーンと少ないシーンに配分することができます。この配分方針を調節するには、下記のqcompを見て下さい。　さらに、２パスに１パスの２倍の時間をかける必要はありません。1stパスのオプションを調節して、速度を上げ、画質を落とす事ができます。うまく調節できれば、1stは非常に速く済むでしょう。この場合、サイズ予測の精度が落ちますから、2ndの品質は僅かに落ちます。しかし、通常、違いは目で見て解るレベルにはなりません。例えば、1stと2ndにそれぞれこんなのを追加して試してみてください。　（＊06年10月改訂前のオプション名＊） subq=1:frameref=1 subq=6:frameref=15:4x4mv:me=3 　 Three pass encoding? x264 では後続パスの数を自由に指定できます。 1stパスにpass=1を使い、後続パスでpass=3を使った場合、後続パスは前のパスの統計の読み込みと、新たな統計ファイルの書き出しの両方を実行します。さらにその次のパスは指定されたquantizerの範囲でのフレームサイズをずっと正確に予測できる事になります。実際上は、これによる全体的な品質向上はほとんどゼロです。ひょっとすると3rdパスのグローバルPSNRは2ndよりさがる事もあります。一般的な3パスの使い方は、2パスではビットレート予測が巧くいかなかったり、場面転換が汚く見えたりした場合に使うというものです。こうした事は非常に短いクリップで起きる傾向があるようです。　他にも3（以上の）パスが有効なケースがいくつかありますが、上級者向けなのでここでは省きます。

覚書（要約）記載無し	手許【参考】Doom9 コデックコンテスト2005では一切弄っていない。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） qcomp name="Quantizer Curve Compression" Recommended： 0.60 Default： 0.60 QP curve compression: 0.0 = CBR, 1.0 = CQP	man MEncoder quantizer の圧縮。低い数値にするとビットレートの変動幅が低くなる。=画質の変動幅が大きくなる。高い数値にするとquantizerの変動幅が低くなる。=画質の変動幅が小さくなる。 (default: 0.6)。
zero1(svn408) Usage: --qcomp <float> (default=0.60) [0.00 - 1.00] QP curve compression（＊曲線圧縮？＊）低くするほどconstant bitrateに近づく。0.00 でCBR。高くするほどconstant QP に近づく。(＊1.00 でCQP。＊）推奨値はデフォルトの 0.6。特にアニメで0.00 のCBRは絶対に避けるべきだ。レートコントロールの手足を縛り、動きやディテイルの少ない箇所でbitを節約して、動きやディテイルの多い箇所に振り向ける事ができなくなる。	MEncoder Doc : qcompは一定量のビットを"コストのかかる"動きの多いシーンと、"コストの安い"動きの少ないシーンの間でやりとりするものです。極端な例をあげると、qcomp=0で真のconstant（＊固定＊）ビットレートになります。一般的には、これで動きの多いシーンは酷い物になります。一方、動きの少ないシーンはたぶん完璧でしょう。そして必要なビットレートの何倍も無駄にビットを喰っているハズです。反対の極端例。qcomp= 1 はほとんどconstant quantization (QP)（＊画質固定、一定画質など＊）です。 Constant QPでは、画質が悪いということはありません。しかし多くの人は、非常に"コストのかかる"シーンでもっとビットレートを節約して（動きの多い場面では画質劣化はあまり目に留まりませんから）、その分を、画質向上しやすいシーンに回すほうが合理的だと考えています。 qcomp のデフォルトは 0.6 です。これは多くの人の好みよりは若干低いようで、0.7-0.8 を使う人も多いです。

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

TAG:x264-r600コマンド対応について

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

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

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

余談１：

余談２：

■参考記事

Frame-type_GOP関連オプション

■参考記事

概説

Frame-type_B フレーム関連オプション

概説

Frame-type_その 他のオプション

概説

Ratecontrolオプション

概説

Analysisオプション

概説

Analysisオプション _deadzone関連

概説

Analysis オプション _カスタム量子化マトリクス関連

余 談：

概説

Analysis オプション：Sharktooth版固有の機能

概説

Video Usability Info (Annex E)オプション

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

Frame-type_その他のオプション

余談：