2. Ratecontrol options:　ageha was here

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

ホーム > ごみ箱　-x264encopts > 2. Ratecontrol options:

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)

コメントの投稿

トラックバック

この記事のトラックバックURL
http://agehatype0.blog50.fc2.com/tb.php/152-6c349e4b

| ホーム |
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

覚書（要約） 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 を使う人も多いです。

覚書（要約）記載無し	手許類似オプション 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 記載無し

覚書（要約）記載なし	手許これも"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 記載なし

2. Ratecontrol options: ageha was here

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

2. Ratecontrol options:

概説

Ratecontrolオプション

2. Ratecontrol options:　ageha was here