概説
比較的効果が高いが議論にもなり易いオプションが固まっている。再生環境や
CPUパワーに応じて選択すべき。特に
frameref (-r. --ref)は
subq (-m,
--subme)と並んで最も速度と画質への影響が大きい（遅いほど圧縮効率が良い）。参考元はどれもそれぞれの推奨値があるが、ここは特に自分のCPU
と忍耐力に相談する必要がある。
Frame-type_その
他のオプション
x264cli MEncoder
-x264encopts
--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を使う人が多い模様。
■
参考
覚書 （要約）・-
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以上にします。こうしたケースはラ
イブアクション映像では極めて稀でしょうが、ビデオゲームのキャプチャでは時折ある事です。
■
まとめ：
別名ループフィルタ、インループフィルタ、インラインデブ
ロック、などなど。
覚書 （要約）・デブロックフィ
ルタを、使わなくします。 --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 未記載
スポンサーサイト
