x264はH.264/AVC video streamをエンコードするためのフリーなライブラリです。エンコードを始める前に、MEncoderをセットアップしてください。
14.5.1. x264のエンコードオプション
まず最初に MPlayer の man page にある x264セクション を読んで下さい。以下の情報はその補助で、多くの人が関心を持つと思われるオプションのヒントが書いてあります。 man page はもっと簡潔ですが、徹底的でもあり技術的な詳細に及ぶ事もあります。
14.5.1.1. イントロダクション
このガイドではオプションを二つのカテゴリに分けます。
結局のところ、自分の目的にベストなオプションを決められるのは自分だけなのですが、１の分類のオプションを決めるのは簡単です。速 度低下に見合った画質向上が得られるどうか。それだけです。２の分類のオプションを決めるのは、条件がより主観的になり、またより多くの要素も絡んできま す。この分類のオプションの中にも速度や画質に大きく影響するものがあるのですが、そのオプションの主目的はそこでは無い事に注意して下さい。２の分類の オプションには、画質が良くなるという意見と悪くなるという意見の両方が存在するものすらあります。
先に進む前に、このガイドで使う唯一の画質指標「global PSNR」について。PSNRの詳細な説明は wikipedia (en) のPSNR を見て下さい。global PSNRはエンコード終了後にターミナルの末尾に出て来る数値で、オプションでpsnr計算をさせた時に出るものです。以後PSNRに言及している場合 は、常に同一ビットレートでの比較と考えて下さい。
このガイドのほぼ全文が、two pass を前提に書かれています。オプション比較において two pass エンコードを行う理由は主に二つ。第一は、 two pass はPSNRが1dBほど高くなる事。これは大きな違いです。第二は、one pass エンコードでオプションの影響を比べるのは混乱しがちな事です。エンコードの度にビットレートが大きく変わる事が多いので、画質が良くなったのがオプションを弄ったせいなのか、それともビットレートが変わったせいなのか、見極めが難しい事があるからです。
14.5.1.2. Options which primarily affect speed and quality
＊順番調整用＊subq:速度と画質を取引するオプションの中では、一般的に subq と frameref が最も重要です。速度であれ画質であれ調整したいと思ったらこの二つを最初に弄りましょう。速度については、この二つは非常に密接な関係を持っています。
過去の実験では、デフォルト設定（frameref=1:subq=5）は frameref=1:subq=1 よりも35%ほど時間がかかります。 frameref=6 なら時間は60%以上かかります。subqがPSNRに与える影響は、参照フレーム数に関わらず非常にコンスタントなようです。一般的に subq=5 のPSNRは subq=1 より0.2-0.5 dB高くなりますが、これは充分に目で見て解る違いです。
subq=6 は妥当なコスト（低速化）でよりよい画質をもたらします。通常、subq=5 より global PSNR が 0.1-0.4 dB 向上し、速度は 25%-100% 低下します。subqの他のレベルとは異なり subq=6 はあまり frameref や me の値の影響を受けませんが、主に Bフレーム数の影響を受けます。一般的な使い方では、subq=6 は複雑で動きの多い場面では速度と画質の両方に大きな影響が出るが、動きの少ない場面では大した影響が無い事を意味します。なお、bframes は常に0以外にするのがお奨めです。
subq=7 は最も遅く、最も高画質になるモードです。一般にglobal PSNR は subq=6 より 0.01-0.05 dB 向上し、速度低下は 15%-33% くらいです。この取引は非常に分が悪いので時間を気にせずbit単位で節約したいのでも無い限り使う必要はないでしょう。
framerefのデフォルトは1ですが、妥当な理由があるわけではありません。
・frameref=2にしただけでもPSNRは約0.15db向上し、5-15%の速度低下があります。これは良い取引だと思います。
・frameref=3ではPSNR向上は約0.25db（frameref=1に対して）、これは目で見て解る違いです。速度低下は約15%（これも frameref=1に対して）。残念ながら、ここから効果は急速に減少していきます。
・frameref=6のPSNRはframeref=3に対してたった0.05-0.1 dBくらいしか向上しません。一方、速度低下は約15%追加です。
・frameref=6より上となると画質向上は非常に僅かです（とはいえ素材次第で全く異なる事に注意して下さい）。一般論としては、frameref=12のPSNRはframeref=6に対してたった0.02dB、速度低下は約15-20%追加です。こうした大きなframeref指定について言えそうな事は「PSNRが下がる事はまず確実に無い、画質向上は計測できるギリギリで、目で見てわかるかどうか」くらいです。
ノート：
CABACオフの場合、不必要にframerefを高くすると符号化効率が落ちる可能性があり、実際、通常は落ちます。
CABACオンの場合（デフォルト）、いまのところframerefを「高くしすぎる」心配はしなくて良いようですが今後の開発の進捗で変わる可能性があります。
速度を考えて妥協するなら、subqとframerefを 1stパス では低く抑えて 2nd で上げるという手があります。一般的に最終的な画質低下は無視できる範囲におさまります。PSNRにして0.1dB 以下。これは目で見て解るには小さ過ぎます。しかし、1st と 2nd で frameref を変えると、フレームタイプの決定に影響が出る事があります。例外的なケースのようではありますが、確実を期すなら、素材映像にスクリーン全体を覆うフラッシング・パターンや、Iフレームが入りそうな非常に長いシーンの繰り返しが無いかを確認し、1stパスのframerefをフラッシュサイクルや繰り返しが入るくらいに大きくして下さい。例えば、3フレームに渡るフラッシュ有りとナシの繰り返しがあったら、1stパスのframerefを3以上に。実写素材では非常に稀なケースだと思いますが、ビデオゲームのキャプチャではよくあります。
me: このオプションは動き予測に使うサーチ方式の選択で、速度と画質の取引に直結します。
me=diaはデフォルトより数パーセント速いだけで、global PSNRの低下は0.1dB以下。
me=hex（デフォルト）はまずまず妥当な取引です。
me=umhの速度低下は frameref に依存しますが、global PSNRの向上は0.1dBをやや切るくらい。
frameref が12のように高いと速度低下はデフォルトの40% くらいになります。 frameref=3 では 25%-30%くらいの低下。
me=esa は徹底的なサーチを行いますが、実用には遅過ぎます。
partitions=all: このオプションは予測されたマクロブロックの中のサブパーティションサイズに、8x4, 4x8, 4x4 を加えるものです。コンスタントに 10%-15% の速度低下があります。ローモーション素材ではまず無意味ですが、一部のハイモーション素材、特に細かい動く物体が大量にある場面では 0.1dB 程度のPSNRゲインが期待できます。
＊まるも製作所さんはp4x4を非推奨としている事に注意。
bframes: 他のコデックでのエンコードに慣れている人なら、Bフレームは良い事ばかりでは無いと考えているかもしれません。H.264ではこの常識は異なります。Bフレームには様々なあたらしい技術とブロックタイプが導入されました。多くの場合、単純なB選択アルゴリズムでさえ目覚ましいPSNRの向上をもたらします。また面白い事に、通常はBを使うと2ndパスがやや高速化します。またシングルパスエンコードも適応的B挿入を切れば高速化が望めます。
適応的B挿入を切った場合（nob_adapt）、bframesの設定は1以下が最適です。さもないとハイモーション・シーンで苦しむ事になるでしょう。適応的B挿入を使う場合（b_adapt、デフォルト）はbframesの数を増やしても安心です。圧縮効率の悪くなる場面ではコデックがBの使用を控えます。x264が3~4以上のBフレームを連続させることは稀ですから、それ以上を指定してもあまり効果はありません。
b_adapt: このオプションは（デフォルトでenabled）あまり効果の無い場面でBの使用を控えるもので、判断精度も速度もそこそこ妥当です。間引き具合の調整にはb_biasを使います。適応的B挿入の速度低下は今のところ慎ましいものですが、画質向上もそれなりです。通常は害はありませんが、このオプションは1stパスの速度とフレームタイプ決定にしか影響がない事に注意して下さい。b_adapt と b_biasは後続パスにはなんの影響もありません。
b_pyramid: Bフレームを2以上にしているならこのオプションも使うと良いでしょう。man page にあるとおり、速度低下抜きで若干の画質向上が得られます。概ね2005年３月以前のlibavcodecベース・デコーダではデコード出来ない事に注意して下さい。
weight_b: 一般的なケースではこのオプションのメリットは大きくありません。しかしクロスフェードや黒フェードアウトの場面では、適応重み付け予測はビットレートを非常に節約してくれます。MPEG-4 ASPで黒フェードアウトの場面をキレイに符号化するにはコストの高いIフレームを連続させる必要がありましたが、Bフレームの適応重み付け予測は、少なくともその内のいくつかをずっとコストの低いBフレームにする事ができます。特に特別な判断をするわけではないので、エンコードにかかる時間は最小限です。また、デコード負荷も変わりません。
残念な事に、現在の適応的B挿入が使うアルゴリズムはフェード場面でのB使用を控える傾向がとても強いです。これが変わるまではフェードの影響が大きそうなクリップでは -x264encoptsに nob_adapt を入れておく方が良い事もあるでしょう。
threads: マルチCPUで平行処理をするもの。マニュアルでスレッド数を指定する事もできますが、threads=auto でCPU数に応じて分散数を自動的に決めさせる方が良いでしょう。マルチプロセッサではリニアに速度が向上する（コア一個に付き約94%）ので絶対使った方が良いです。画質劣化は僅かなものです（デュアルコアで約 0.005dB 、クアッドコアなら約 0.01dB ）。
14.5.1.3. 個人の好みや特定の要望に関わるオプション
原文：14.5.1.3. Options pertaining to miscellaneous preferences
＊順番調整用＊
本ガイドの冒頭で2パスの常用を推奨しましたが、それが不適当なケースも存在します。例えば、TVキャプチャをリアルタイムでエンコードしているような場合は、1パスしか使えません。また当然ですが1パスは2パスよりはやいです。各パスを同一設定で走らせれば、ちょうど倍の時間がかかります。
それでも２パスにはメリットがあります。
第一に、シングルパスのレートコントロールは人間の印象にそぐうものではありません。重要な絵とそうでないものの区別を付けられないので、妥当な判断ができない事が多いです。例えば２分のビデオがあるとします。前半１分は非常に動きが多く、キレイに圧縮するなら 2500kbps は必要な場面、それに続く一分はローモーション場面で 300kbps で充分だったとしましょう。
これは普通に考えれば 1400kbps で充分なはずですがシングルパスの場合、前半には非常に高い量子化が掛かかって、堪え難く、妥当とも言い難いほどブロックノイズにまみれます。後半は非常に低い量子化が掛かかります。見た目はパーフェクトでしょうが、その為に費消されるビットレートはまったく妥当とは言えないものです。
さらに、両場面の境目という難しい問題があります。ローモーション場面の冒頭数秒間ではレートコントロールが前場面のようなハイモーションが来ると思っているままですから、非常に高い量子化が掛かかります。
こうした「誤認区間」は相当に目障りで、ビットレートも必要な300kbpsに達する事がありません。シングルパスエンコードの欠点を補う方法はいろいろありますが、そうした手段はビットレート予測の誤差が増える傾向があります。
シングルパスに比べると、マルチパスのレートコントロールは大きなメリットがあります。
1st パスで集めた統計ファイルを使って、qp設定値がいくつでも、各フレームに与えるべきコスト（bit）を妥当な精度で予測できます。これにより、（コストの高い）ハイモーション場面と（コストの安い）ローモーション場面の間のビット配分を、より合理的に行う事ができます。このビット配分方針を調整するには、後述の qcomp を読んで下さい。
なお、2パスに２倍の時間を掛けなくても可能です。1stパスのオプションを弄って高速、かつ低画質化する事ができます。調整するオプションを選べば1stは非常に速くなります。サイズ予測の精度が落ちるので最終的な2ndパスの画質はやや落ちますが、通常は目で見て解るほどではありません。
一例を上げると：
1st subq=1:frameref=1
2nd subq=6:frameref=15:partitions=all:me=umh x264では任意のパス数を使う事ができます。最初のパスに pass=1 を指定し、次のパスに pass=3 を指定します。このパスでは最初の統計ファイルの読み込みと、独自の統計ファイルの書き出しを同時に行います。さらにこの後に続くパスでは、アップデートされた統計ファイルを使って、指定したQPの範囲で各フレームに与えるべきコスト（bit）をより高精度に予測できます。
実用上、全体的な画質向上はほとんどゼロか、2ndより global PSNRが落ちます。一般的に3パスが役に立つのは、2passではビットレート予測が巧くいかない場合か、場面転換が汚く見える場合です。これは非常に短いクリップでありがちなようです。他にも3（以上の）パスが役立つ特殊なケースがいくつかあるのですが、ここでは深入りしません。
qcomp: qcompは一定量のビットを“コストのかかる“動きの多いシーンと、“コストの安い“動きの少ないシーンの間でやりとりするものです。極端な例をあげると、qcomp=0 で真の固定ビットレートになります。一般的にはこれは、動きの多いシーンが酷い物になる一方、動きの少ないシーンはたぶん完璧になります。しかし必要なビットレートの何倍も無駄にビットを喰っているハズです。反対の極端例。qcomp=1 はほとんどconstant quantization (QP)です。Constant QPでは、画質が悪いということはありません。しかし多くの人は、非常に“コストのかかる“シーンでもっとビットレートを節約して（動きの多い場面では画質劣化はあまり目に留まりませんから）、その分を、画質向上しやすいシーンに回すほうが合理的だと考えています。
qcomp のデフォルトは 0.6 です。これは多くの人の好みよりは若干低いようで、0.7-0.8 を使う人も多いです。
keyint: keyintはシーク（＊早送りや巻き戻し＊）のやり易さと符号化効率の取引です。他の目的はありません。デフォルトの keyintは250にセットされています。25fps素材では、これで10秒以下の精度でシークできるようになります。5秒精度のシークが重要と考えるなら、keyint=125。ビットレートあたりの品質は僅かに落ちます。重要なのは画質だけで、シークなど気にしないなら、もっと大きな値にできます（値を大きくすればするほど、効果は漸減します。無視できるほど小さく、あるいは0にもなり得ます。）それでも、ビデオストリームにシーンチェンジがある限り、そこがシークポイントになります。
deblock: このトピックはやや議論のあるところだと思います。
H.264規格の定義するデブロッキング手段は、各I-ブロックのQPに応じてプリセットした強度と閾値を使うシンプルなものです。デフォルトでは、QPの高いブロックは強く、低いブロックは全くデブロックしません。H.264規格が定めたプリセット強度は良くできており、どんな素材でも良いPSNRが出る確率が高いです。deblockオプションは、このプリセットの閾値をイジるものです。
多くの人がデブロック強度を大幅に下げるのが良いと考えているようです（-3とか）。しかしこれは全くと言ってよいほど良い考えではありません。多くの場合、デフォルトでの動作原理を解っていないように見えます。
第一に、そして最も重要な事は、デフォルトの閾値はほとんどの場合で最適なPSNRになると言う事です。最適にならないレアケースでも、望ましい調整範囲は +-1。これを超えてデブロッキング・パラメータを弄ると、先ず確実にPSNRが下がります。高くするとディテイルにスミアノイズ（擦ったような汚れ）が増え、弱めればブロックノイズが目に見えるようになります。
ディテイルやノイズが少ない（空間軸の複雑さが少ない）素材の場合デブロックの閾値を下げるのは確実にマズいです。むしろこうした素材ではデブロック・フィルタは非常に巧くアーティファクトを封じ込めます。 空間軸の複雑さが多い素材でも、アーティファクトはあまり目立ちません。これはリンギングノイズはディテイルやノイズに見える傾向がある為です。人間の視覚はディテイルが無くなる事には敏感ですが、間違ったノイズが描き出されても簡単には気が付きません。これは「画質」という点ではノイズとディテイルにはなにがしかの互換性があると言う事です。デブロック強度を下げるとリンギング・アーティファクトが増える傾向がありますが、人間の目はこれを「ディテイル」と誤認して気が付きません。
しかし、これもデブロック強度を弱める理由にはなりません。一般的にもっと良いノイズがポストプロセスで得られるからです。もし出力結果にブラーやスミアが多かったら、MPlayerの再生で'-vf noise' を使って見て下さい。-vf noise=8a:4aで一般的でマイルドなアーティファクトは封じ込められます。デブロッキングフィルタをあれこれ弄るよりキレイに見える事はほぼ確実だと思います。
以下は、ビットレートが同じ場合の設定例です。"速度と画質に関わるオプション" のみ。
素材映像は720x448 @30000/1001 fps , ビットレートは900kbps、マシンはAMD-64 3400+（2400 Mhz）の64 bitモードです。それぞれの設定で計測したエンコード速度（frames per seconds）と“very high quality“ に対するPSNR の低下分（dB）も書いてあります。素材、マシン、それから開発の進捗で結果は全く変わる事もあります。
| Description | Encoding options | speed (in fps) |
Relative PSNR loss (in dB) |
|---|---|---|---|
| Very high quality | subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b | 6fps | 0dB |
| high quality | subq=5:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b | 13fps | -0.89dB |
| Fast | subq=4:bframes=2:b_pyramid:weight_b | 17fps | -1.48dB |
14.7. Using MEncoder to create QuickTime-compatible files
＊順番調整用＊
QuickTime 互換ファイルが必要なケースは以下の通り
QuickTime 7 はH.264 映像と AAC 音声をサポートしていますが、それをAVIに入れたモノはサポートしていません。しかし、映像を音声をMEncoderでエンコードして、 mp4creator（ MPEG4IPの一部）などの別のソフトでMP4コンテナに詰め直す事ができます。
QuickTime の H.264 サポートは限定的なものです。ですから先進的なオプションはいくつか切る必要があります。サポート外のオプションを使ってエンコードした場合、QuickTime ベースのプレイヤは白紙フレームを表示するだけです。
ここからは、買って来たばかりの『ナルニア物語』のDVD（リージョンコード1、つまりNTSC）をリップすると仮定します。以下のコマンド例をPALに使う場合、-ofps 24000/1001は削除、またcropとscaleの値は若干変える必要がありますが、あとはそのまま使えます。
mplayer dvd://1 で再生し、 How to deal with telecine and interlacing in NTSC DVDs の内容に従ったところ、映像内容は 24000/1001 fps のプログレッシブである事が解りました。これは、pullupなどの逆テレシネや、yadifのようなインタレ解除をしなくて良いという事です。
次にやる事は、このセクションに従って上下の黒帯をクロップする事です。
実に残念な事ですが、QuickTime7 は 1 以外の SAR を持つMPEG-4 映像をサポートしていません。ですから映像を正方形ピクセルに拡大か縮小する必要があります。拡大はディスク容量を大量に喰い、縮小はいくばくかのディテイルが消えます。どちらにせよ非常に問題なのですが、QuickTime7で再生したいなら仕方がありません。
MEncoderで縮小するには -vf scale=-10:-1 、拡大は -vf scale=-1:-10。これでクロップアウトした高さに合わせて幅をスケーリングし、直近の16の倍数に丸めます。クロップはスケーリングの前に行うのを忘れないで下さい。
-vf crop=720:352:0:62,scale=-10:-1＊訳注："-1"にした方のサイズに合わせて、"-10"にした方を拡大 or 縮小。 SAR=1/1にはならないが、それなりに近い値になる。
AVI以外のコンテナに入れる場合、必ず-vf チェイン末尾に harddup を加える必要があります。というのは、複製フレームが発生しても、必ず映像データに書き込まれるとは限らないからです。 harddup 抜きの場合、MEncoderは複製フレームの存在を映像ストリームにマーキングするだけです。これは再生ソフトに同じフレームを表示し続けるよう指示するマークです。残念な事に、この “ソフト・デュプリケーション” は remux で失われてしまいますから、徐々に映像と音声の同期がずれてゆく事になります。
最終的な-vfチェインは以下のようになります。
-vf crop=720:352:0:62,scale=-10:-1,harddupここで説明されている通り、適正なビットレートは常に素材の技術的プロパティと、個人の好みに依ります。ここで扱う映画は、大量のアクションシーンとまた大量のディテイルを含みますが、H.264はXviDなど他のMPEG-4よりはうんと低いビットレートで済みます。実験の結果、このガイドの著者は900kbpsで非常に画質が良いと判断しました。容量を稼ぐ為に減らすのも、更なる画質向上を求めて増やすのも、自由です。
画質を気にするなら、もちろんtwo-passを行うべきです。1st パスに turbo を使うと少し時間を節約できます。これでsubqとframerefが1になります。また容量を少し節約する為に、 ss を使うのも良いでしょう。これで最初の数秒をカットできます。この素材では32秒ぶんのクレジットとロゴが入っていました。bframesは0か1。その他のオプションは Encoding with the x264 codec と man pageを見て下さい。
mencoder dvd://1 -o /dev/null -ss 32 -ovc x264
-x264encopts pass=1:turbo:bitrate=900:bframes=1:
me=umh:partitions=all:trellis=1:qp_step=4:qcomp=0.7:direct_pred=auto:keyint=300
-vf crop=720:352:0:62,scale=-10:-1,harddup
-oac faac -faacopts br=192:mpeg=4:object=2 -channels 2 -srate 48000
-ofps 24000/1001マルチプロセッサを持っているなら、threads=autoを忘れないように。x264のマルチスレッドモードで圧縮時間が劇的に短縮します。
2ndパスは、 pass=2 指定を除いて同じ。
mencoder dvd://1 -o narnia.avi -ss 32 -ovc x264
-x264encopts pass=2:turbo:bitrate=900:frameref=5:bframes=1:
me=umh:partitions=all:trellis=1:qp_step=4:qcomp=0.7:direct_pred=auto:keyint=300
-vf crop=720:352:0:62,scale=-10:-1,harddup
-oac faac -faacopts br=192:mpeg=4:object=2 -channels 2 -srate 48000
-ofps 24000/1001こうしてできたAVIはMPlayerでは完璧に再生できますが、H.264-in-AVIをサポートしていないQuickTime では無理です。ここからMP4 コンテナにremuxする必要があります。
