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

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

ホーム > ごみ箱　-x264encopts > 3.1. Analysis options_カスタム量子化マトリクス以外

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)

partitionsのp8x8,b8x8はMain Profileで使えるようです。
手許でオンにした物がQTで開けます。

[ 2006/12/10 14:58 ] [ 編集 ]

-A, --partitions / partitions、まとめのprofile対応部に追記しました。

有り難うございます。

[ 2006/12/10 19:45 ] [ 編集 ]

x264のソースを読んだわけではないのであまり自信をもって言えないのですが
--mixed-refsについて、動き補償のブロックサイズとDCTのブロックサイズは無関係なので
Baseline,Mainでも有効だと思われます。
H.264の仕様書を見る限り、
Highでなければ同一MBで複数フレームを参照できない、という制限はないように思われます。

[ 2006/12/10 19:58 ] [ 編集 ]

--mixed-refs / (no)mixed_refs の項、訂正しました。

有り難うございます。

>動き補償のブロックサイズとDCTのブロックサイズは無関係

DCT、やっぱ理解しないとダメぽいですね^^;

[ 2006/12/10 20:19 ] [ 編集 ]

コメントの投稿

トラックバック

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

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

覚書（要約）圧縮時間が、モリモリ増える素敵なオプション。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 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 は徹底的なサーチで、これは実際に使うには遅すぎます。

覚書（要約）はやい段階で、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 記載無し

覚書（要約） 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 記載無し

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

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

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

概説

Analysisオプション

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