Doc /
menc-feat-x264
14.5. x264コデックでのエンコード †
x264はH.264/AVC video streamをエンコードするためのフリーライブラリです。エンコードをする前にMEncoderのセットアップが必要です。
＊セットアップ方法：
14.5.1. x264のエンコードオプション †
MPlayer's man pageのx264 sectionを読む事から始めて下さい。このセクションは補助です。ここでは多くの人が興味を持つと思われるオプションのヒントを書いていきます。man pageのほうが簡潔なのですが、徹底的でもあります。また、技術的な詳細が書かれている事もあります。
14.5.1.1. イントロダクション †
このガイドではオプションを2種類のカテゴリに分類しています。:
- 主に速度と品質のトレードオフに関わるオプション
- 個人的な好みや特別な目的に有益かもしれないオプション
最終的には、あなたの目的にとって最善のオプションを決められるのはあなただけです。
最初のカテゴリでの選択は簡単。速度差に見合った画質が得られるかを判断するだけです。
第二のカテゴリでは、選択は非常に主観的なもので、考慮すべきポイントも増えます。
注意して欲しい事は、"個人的な好みや特別な目的に有益かもしれないオプション"の中にも速度や品質に大きな影響があるものも含まれていますが、必ずしも有益とは限らないという点です。"個人的な好み" オプションの中には、使った方が良く見えるという人と、悪くなるという人の両方が居るようなものすらあります。
先へ進む前に、このガイドではグローバルPSNRという品質の測定基準だけを使う事をお断りしておきます。PSNRの簡単な説明は、Wikipediaを見て下さい。Global PSNR はx264encoptsのpsnrオプションを使った時に出てくるPSNR値の最後のものです。このガイド内でPSNRに言及する場合、同一ビットレートでエンコードした場合のPSNRと考えて下さい。
＊WikipediaのPSNR（英語）：http://en.wikipedia.org/wiki/PSNR
このガイドのほぼ全ては、2パスを想定して書かれています。オプションを比較する際に2パスを使う理由は大きく行って2つあります。第一に、多くの場合、2パスではPSNRが約1db向上します。この差は大きいです。第二に、1パスエンコードでの画質比較は、混乱を招き易い。：エンコードの度にビットレートが大きく変化する事があるからです。その結果、画質の変化がオプションを弄ったせいなのか、ビットレートが変わったせいなのか判断しにくいという事になってしまいます。
14.5.1.2. 主に速度と品質に関わるオプション †
- frameref:
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が下がる事は無い、くらいの事しか言えません。品質向上はやっとこさ計測できるくらいで、目で見て感じる事も難しいでしょう。
（＊At such high frameref values, the only really good thing that can be said is that increasing it even further will almost certainly never harm PSNR, but the additional quality benefits are barely even measurable, let alone perceptible.＊）
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以上にします。こうしたケースはライブアクション映像では極めて稀でしょうが、ビデオゲームのキャプチャでは時折ある事です。
- partitions=all:このオプションは予測マクロブロックの中で、サブパーティション、8x4, 4x8, 4x4を使う物です（デフォルトで使うものに追加）。ほぼ一貫して10%-15%の速度低下になります。動きの少ない素材に使うのはほとんど意味が有りません。しかしながら、動きの多い素材、なかでも小さな動く物体が大量にある素材では約0.1dbのゲインが期待できます。
- b_pyramid: B-frameを2以上にする場合はこのオプションも使った方が良いようです。man pageにある通り、速度低下抜きで若干の画質向上が得られます。2005/03/05よりも古いlibavcodecベースのデコーダは、これを使った映像を読めない点に注意して下さい。
14.5.1.3. 様々な好みに関わるオプション †
- 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にそれぞれこんなのを追加して試してみてください。
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（以上の）パスが有効なケースがいくつかありますが、上級者向けなのでここでは省きます。
- qcomp:
qcompは一定量のビットを"コストのかかる"動きの多いシーンと、"コストの安い"動きの少ないシーンの間でやりとりするものです。
極端な例をあげると、qcomp=0で真のconstant（＊固定＊）ビットレートになります。一般的には、これで動きの多いシーンは酷い物になります。一方、動きの少ないシーンはたぶん完璧でしょう。そして無駄にビットを喰っているハズです。必要なビットレートの何倍も。
反対の極端例。qcomp=1 はほとんどconstant quantization (QP)（＊画質固定、一定画質など＊）です。
Constant QPでは、画質が悪いということはありません。しかし多くの人は、非常に"コストのかかる"シーンでもっとビットレートを節約して（動きの多い場面では画質劣化はあまり目に留まりませんから）、その分を、画質向上しやすいシーンに回すほうが合理的だと考えています。
qcomp のデフォルトは 0.6 です。これは多くの人の好みよりは若干低いようで、0.7-0.8 を使う人も多いです。
- keyint:
keyintはシーク（＊早送りや巻き戻し＊）のやり易さと符号化効率の取引です。他の目的はありません。デフォルトのkeyintは250にセットされています。25fps素材では、これで10秒精度のシークができるようになります。5秒精度のシークが重要と考えるなら、keyint=125。ビットレートあたりの品質は僅かに落ちます。品質だけが重要でシークのやり易さを問題にしないなら、もっと大きな値にできます（値を大きくすればするほど、効果は漸減します。無視できるほど小さく、あるいは0にもなり得ます。）それでも、ビデオストリームにシーンチェンジがある限り、そこがシークポイントになります。
- deblockalpha, deblockbeta: このトピックはやや議論の分かれるところがあります。
H.264規格にはシンプルなデブロック手段があります。これはI-blockに適用されるQPに基づいて、あらかじめ決められた強さと閾値に基づいてフィルタをかけるものです。デフォルトではQPの高いブロックには強いフィルタがかけられ、QPの低いブロックはデブロックされません。規格で決められているプリセットの強度は慎重に決められたもので、どんな素材をエンコードしても非常に良いPSNRがでる公算が非常に高いものです。deblockalphaとdeblockbetaは、このプリセットのデブロック閾値を調節する為の物です。
多くの人はデブロックフィルタの強さを大幅に弱めるのが良いと考えているようです(例えば-3とか)。
しかしながら、これは決して、と言っても良い程、良い考えとは言えません。そしてほとんどの場合、こうした調節をしている人はデフォルトのデブロックの理屈を理解していないようです。
まず、in-loop デブロックフィルタを知る上で最も大切な事は、デフォルトの閾値はほとんど常に、最適なPSNRをもたらすという事です。
PSNRが最適にならないケースは稀です。従って望ましいオフセットはプラスマイナス1。それ以上はほぼ確実にPSNRの低下になります。フィルタを強くすると、ディテイルの汚れ*1が増え、弱めると目に見えるブロックノイズが増えます。
空間軸の複雑さが少ない素材（例えばディテイルやノイズが少ない）でデブロック閾値を下げるのは、マズいと断言します。こうした素材で発生するアーティファクト*2の封じ込めにかけては、in-loop フィルタは素晴らしい仕事をします。他方、空間軸の複雑さが多い素材でも、アーティファクトは目につきません。なぜなら、リンギングがディテイルやノイズのように見える傾向があるからです。
人間の視覚認識はディテイルの損失には敏感ですが、間違ってノイズが描きだされても簡単には認識できません。*3これは、人間にとっての主観的な品質ということでは、ノイズとディテイルは、ある程度互換性があると言う事です。deblockingフィルタを弱める事は、リンギング・アーティファクトを増やす事になります。ですが、人間の目はこれをディテイルと誤認識します。
しかし、これもデブロックフィルタの強度を弱める理由にはなりません。一般的に、ポストプロセッシングでもっと良い品質のノイズを得られるからです。もし、あなたのH.264エンコードがブラーや、スメア（＊smeared：擦って不鮮明にする＊）が多すぎたら、再生時に-vf noiseを試してみて下さい。マイルドなアーティファクトなら -vf noise=8a:4a でほぼ封じ込めることができます。これでデブロッキングフィルタをあれこれするより、ほぼ確実に、良く見えるでしょう。
14.5.2. エンコード設定例 †
以下は、ビットレートが同じ場合の速度と画質のトレードオフに関わる設定の例です。
素材映像は720x448 @30000/1001 fps , ターゲットビットレートは900kbps、マシンはAMD-64 3400+（2400 Mhz）の64 bitモードです。それぞれの設定で計測したエンコード速度(frames per seconds)と"very high quality"に対するPSNR の低下分 (dB)も書いてあります。素材、マシン、それから開発の進捗で結果は全然変わる事もあるので、その点はご承知ください。
