※0.3.0（不安定版）はマルチパスの挙動に不具合があります。実験目的以外ではお奨めしません。作者氏は情報を募集されています。
　※本記事の目的は人 柱の増殖です。
　※基本的にMEncoderでの経験を元にしており、挙動の異なる点が有り得ます。

x264Encoder 0.3.0

設定

＼	Memo	MEncoder -x264encoptsの相当オプションと手許常用値
CODEC_FLAG	補 助的なオプショ ン群
FLAG_LOOP_FILTER	デブロックフィルタ。切 らないのが基本。 MPEG系で発生不可避のブロックノイズ対策を映像データに埋め込む。 再生ソフトのデブロックフィルタ類はこの機能と競合する可能性有り。	(no)deblock 必ず使用（deblockでオン、nodeblockでオフ、以下同じ）
FLAG_PSNR	ログにPSNRを表示。高いほど画質が良い。 同一素材の設定を試行錯誤する際に使う。値自体は無意味。比較に使うべきもの。 詳細は「SSIMとPSNRとは」参照のこと。 ※どこに出て来 るのか不詳。	(no)psnr 必ず使用。あまり参考にしない。
CODEC_FLAG2	補 助的なオプショ ン群２
FLAG2_BPYRAMID	要・ max_b_frames=2以上 Bフレームを参照フレームに使う。Bを使うなら推奨。Bのbit節約になる。	(no)b_pyramid 必ず使用。
FLAG2_WPRED	要・max_b_frames=1以上 適応重み付け予測。Bを使うなら推奨。Bのbit節約になる。	(no)weight_b 必ず使用。
FLAG2_MIXED_REFS	要・refs=1以上 複合参照。マクロブロックパーティション単位で独自の参照先を選べるようにする。全体の bit節約。	(no)mixed_refs 必ず使用。
FLAG2_8X8DCT	High Profile専用 8x8DCT変換。	(no)8x8dct 必ず使用。
FLAG2_FASTPSKIP	早い段階でPフレームのskip検出をする。 使った方が地味に速いが、x264最大の弱点「闇階調でフレーム単位でぱたぱたと動くブロックノイズ」が出がち。	(no)fast_pskip 必ずnofast_pskip使用。
FLAG2_AUD	※不詳	不詳
FLAG2_BRDO	要・me_subpel_q...=6以上 Bフレームのレート歪み最適化。Bのbit節約。Bを使うなら推奨。	(no)brdo 必ず使用。
Box1	基 幹オプション
me_method	速度と画 質への影響・大 モーションベクトルのサーチ方式の指定。推奨はhexかumh。 速い順でdia、hex、umh、esa。 遅い方が画質が良いが、esaの画質向上は速度低下と引き合わない。 ※EPZSの内容不詳。x264cliには存在しない。 ffmpeg固有名？学術用語？	me=umh
coder_type	サイズと画質への影響・大 符号記述方式の選択。CABAC大推奨。 CAVLC：iPod/Apple TVはこちらでなければならないと思われる。適応的可変長符号化 CABAC：15%程度の符号量節約。素のQTPlayerでも再生できる。負荷はエンコード・デコードともに増える。適応的二進数算術符号化 ※ これ自体は画質と関係ない。同じ文章を仮名だけで書くか漢字まじりで書くかといったカンジ のもの。しか し、節約した分のbitは肝心の映像に回る。単独で15%も節約できるオプションは他に無い。 ※学術用語っぽい VLC： 可変長符号化ーバリアブル・レングス・コーディング AC：算術符号化ーアリズメティック・コーディング CA：適応的ーコンテキスト・アダプティブ	(no)cabac 必ず使用。
directpred	Bを使うなら推奨。Bのbit節約になる。 一口にBといってもAVCでは細かい種類がある。directはBのモーションベクトルをまじめに書き込まず「隣と同じ」とだけ書き込んでおくType。 まじめに数値を書くよりbitを節約でき、計算時間も早い。ここでは「どっちの隣か」を指定する。 disabled：無し、まじめに 計算して書き込む。画質も速度も最悪。 spatial：空間軸、mencoderの経験上、autoでもほとんどコレになる。最速。 temporal：時間軸、アニメでゴーストが出るという人も居る。これも最速。 auto：空間軸と時間軸を必要に応じて使い分ける。画質は最上、速度は中間。	direct_pred=auto 必ず使用。
trellis	適応的量子化の一種。理屈不詳。 Disabled：非使用 Only final：最終エンコードでのみ使用 All：全モード決定で使用。(低速、要・me_subpel_q...=6以上) ※メリハリをつけて（適応的）画質を劣化させる（量子化）手法のひ とつ、くらいに理解してます。 trellisは使わないほうが画質が良いケースもあるとする人もいます。	trellis 必ず使用。
Worker Thereads	速度向上・大 Single/Dual/Quad ス レッド数の指定。 ※x264ライブラリでは1-16。 実際には指定値x1.5を使う。分散するほど画質は劣化するが、主観的にも数値的にも事実上無視して良い。速度向上メリットのほうが大きい。	threads 1st=2 2nd=16 上記の理 由
Faster FirstPass	速度向上・大 Disabled/Turbo1/Turbo2 2 パスモードの 1st passで重いオプションを切り、高速化する。 me_method, refs, me_subpel_q...の指定値を無視。独自値を使う。 画質的なデメリットは目で見てもまずバレない範囲とされる。 元はMEncoder独自のプリセット設定を解析、 移植したものなので、他にもあるかもしれない。特にpartitions。挙動に違いがある可能性有り。 ※threadsの分散方式が変わる前の内容なので過信は禁物ですが、一応MEncoderのturboに関わる注意点⇒「x264コデックでのエンコード」内、「主に速度と品質に関わるオプション 」のframerefの項。	turbo=1 2パスの1stのみ。 必ず使用。
Box2	１ パス専用オプ ション
crf	1パスで済ませたい人用の「なんちゃって固定量子 化」。 bitrateも指定すると「できるだけ尊重」してくれる。 2パスでは無意味。 ※x264ライブラリでは範囲1-51。指定量子化値を中心にしたABR。 QT では量子化値は「圧縮プログラム/品質」スライドバーか？ パス数は「最高品質(複数回実行)」で自動決定か？	crf 非使用。2パスしかやらない。 （3パスもやらない）
b_frame_strategy	不詳 b_bias（Bの挿入性向）？ (no)b_adapt（適応的B挿入のオンオフ切り替え）？
Box3	基 幹オプション 　～先にここを決め、残りはそれとの関連で決めましょう～
refs	速度と画質への影 響・大 複数参照（任意距離参照） 推奨値3程度。実用上限6程度。 増やすほど圧縮効率が良い。但し、そのぶん時間はうなぎのぼりで効果も逓減。	frameref=4 1stはturboが勝手に下げる
me_subpel_q...	速度と画質への影響・大 動き予測全般の算出方式を選択。範囲1-7。デフォルト5。推奨6以上。手許常用7。 可能な限り高く。5以上でないと効果を発揮でき ないオプションがあるから。	subq=7 1stはturboが勝手に下げる
me_range	速度と画質への影響・大 要・ me_method=umhまたはesa。 umhまたはesaで使える動き捜索の範囲指定。 実用範囲16-32。デフォルト16	me_range 1stは16 2ndは32
max_b_frames	画質への影響・第２位⇒参考 Bフレームの最大連続枚数。推奨3程度。 いくつに指定しようがBに適さないフレームがあったら自動でI/Pにしてくれる。 b_biasを弄らない限り、Bが3連続するようなケースはまず少ない。	bframes=3
sc_threshold	画 質への影響・第１位⇒参考 Iフレーム挿入性向。デフォルト40 ほとんどの実写は40でイイ感じ。アニメは上げるべき。 ※x264はIフレームの挿入位置をしくじるとかなり痛い。多すぎても少なすぎてもかなり痛い。 　アニメや、非常に短い間隔でシーンカットがあるものは、MEncoderではkeyint_minを下げないとIフレームが適正位置にうまく入らない。 　ffmpeg にもx264専用の-keyint_minがあるが、QuickTimeも独自にキーフレーム挿入アルゴリズムを持っている。	scenecut 実写40 白黒高め（色情報を信頼できない） アニメ65以上、かつkeyint_minを1以下に。
qcompress	下手に弄 らない。 低くするとビットレートの変動幅が低くなる。=画質の変動幅が大きくなる。 高くするとquantizerの変動幅が低くなる。=画質の変動幅が小さくなる。 ※基本的にAVCやVC-1は単純にビットレートを上げるよりも、全体平均ビットレートを低く抑えてbit 配分にメリハリをつけるほうが「画質が良い」と、プロも言っておられる。qcompressは上げても下げてもメリハリが失 せるという、画質的には難しい存 在。ストリーミングでは重宝か。 　x264ライブラリのオプションとしては比較的古株だが、よりダイレクトにビットレートの変動幅を弄るratetolや、quantizerの変動幅を弄るqp_stepのほうがなにかと効果が解りやすく便利。ファイル全体に渡るbit配分をいじるオプションもいくつかあるが、それに手を出すのはちょっ、、、レート配分を時系列でグラフ 化？。	qcomp デフォルトのまま。
noise reduction	ノイズリダクション MEncoderでは有用範囲は100-1000としている。 ※ 実際のエンコード工程に入る前に実行されるので、規格互換性の心配無用。	nr 手許ではhqdn3dを常用。
Console log
log info
log debug
log stats
nclc and ganma	QuickTime 固有の要素。
No nclc info	調査 中	対応無し
Add gamma 2.2	「Apple製品しか使わな い」ならオン。 「Win/linuxでもできるだけ同じ色で見たい」ならオフ。	対応無し
Native fps	素材に応 じて指定。

素材：MPEG-2 PS（MPEGStreamclipでカット、Convert to MPEG with MP2 Audio）
機材：PowerMac G5(2Ghzx2)、Mac OSX 10.4.8、QT7.1.4は様子見。
概要：
　QTPPro 7.1.3とMPEGStreamclip 1.8が中心。15秒程度の実写CM、一分半のアニメOP、24分のアニメ番組、それぞれ数件。
　他はたまたまHDにあったので。一分半のアニメOP一件のみテスト。
　隙を見てランダムにやったものなので信頼性はイマイチ、設定間違いの可能性もあります。

フロントエンド	1pass	2pass	インタレ解除		.mov	.mp4	特記事項
			固有	環境設定のpp=l5
QuickTime Player Pro 7.1.3	OK	素材により失敗(＊)	効かない	効かない	OK	不可	＊log statsによるとq=1000などの有り得ない数値が出る。そこで異常終了している感じ。
MPEGStreamclip 1.8	OK	失敗(＊)	OK	効かない	OK	OK	＊2ndは最後まで進行している印象。 音声同時書き出し可、FAACより音は良い。
JES_Deinterlacer_v2.7.3	OK	未テスト	OK	未テスト	OK	不可
Diva 1.0	OK	Automatic 2-passがグレイアウト	OK	未テスト	OK	不可	2004頃のソフトがそのまま使える方が驚き。

　各項目の成否に特化したので画質は気にしていません。
　1パスcrfは安定しています。特にバッチ処理が効き、かつQT上でaacエンコもできるMPEGStreamclipはポイント高いっす。

　x264Encoderのインタレ解除がMPEG-2 PS素材に効かない件。

　 当家固有の現象かもしれないです。Onyx使ってるくらいで、結構システム壊れてる筈だし。

症状１：MPEG- 2 PS

MyComet G3さんより。太字オレ

---

あ れ、インタレ解除効きませんか？
・PreProcのレベルをMaxにしてあるでしょうか。
・QT 書き出しの際、 「ムービー設定」の「サイズ」で、「ソースビデオをデインターレース処理」のチェックを外してあるでしょうか。

うー む。手元のDV-lpcm.movだと100%きちんとpp=l5効くのですが・・・

1. QuickTime Player Pro 7.1.3
2. 「システム環境設定/x264Encoder」：l5 またはmdにチェック。PreProcのレベルはMax。
3. 「QTPPro/書き出し/ムービーから QuickTimeムービー/オプション/サ イズ/ソースビデオをデインターレース処理」のチェックを外す。
4. 1パス。crf抜き。他は適当に高速 設定。fpsは「現在のサイズ」および「NTSC(29.970)」。
5. ← 素材とpp=l5（画質は超適当）。

DEBUG: lavcEncoder: [lavcEncoder_PrepareToCompressFrames]
ERROR: thePrefPPName is invalid.
INFO : lavcEncoder: thePrefPPName: (null) thePrefPPLevel: 6
INFO : lavcEncoder: frame_rate: 29.970
DEBUG: lavcEncoder: codec context flags= 0x0000008800
DEBUG: lavcEncoder: [lavcEncoder_EncodeFrame] (1, 0, 3003, 90000)
INFO : lavcEncoder: {width/height}: {640/480} ; time_base {num/den}: {1001/30000}
INFO : lavcEncoder: bit_rate: 1048576 ; {qmin/qmax/qscale/crf}: {14/51/0.00/0.00}
INFO : lavcEncoder: gop_size: 12 ; max_b_frames: 1 ; qcomp: 0.60 ; sc_threshold: 60
INFO : lavcEncoder: thread_count: 4 ; add_nclc: OFF ; add_gamma: OFF
[h264 @ 0x144d1dc]using mv_range_thread = 56
[h264 @ 0x144d1dc]using SAR=1/1
[h264 @ 0x144d1dc]using cpu capabilities Altivec 

中略

ERROR: thePrefPPName is invalid.
ERROR: thePrefPPName is invalid.
ERROR: thePrefPPName is invalid.
ERROR: thePrefPPName is invalid.

6. MPEG-2 PSからMPEGStreamclipで作ったm2v+aiff.movも同様でした。

DEBUG: lavcEncoder: [lavcEncoder_PrepareToCompressFrames]
ERROR: thePrefPPName is invalid.
INFO : lavcEncoder: thePrefPPName: (null) thePrefPPLevel: 6
INFO : lavcEncoder: frame_rate: 29.970
DEBUG: lavcEncoder: codec context flags= 0x0000000800
DEBUG: lavcEncoder: [lavcEncoder_EncodeFrame] (1, 0, 3007, 90000)
INFO : lavcEncoder: {width/height}: {640/480} ; time_base {num/den}: {1001/30000}
INFO : lavcEncoder: bit_rate: 1048576 ; {qmin/qmax/qscale/crf}: {10/51/0.00/24.00}
INFO : lavcEncoder: gop_size: 12 ; max_b_frames: 1 ; qcomp: 0.60 ; sc_threshold: 40
INFO : lavcEncoder: thread_count: 4 ; add_nclc: OFF ; add_gamma: OFF
[h264 @ 0x43051dc]using mv_range_thread = 56
[h264 @ 0x43051dc]using SAR=1/1
[h264 @ 0x43051dc]using cpu capabilities Altivec 

症 状２：MPEG2-PSでないもの

試しに、ソースが MPEG2-PSでないもの（2~3秒のクリップ）をつくってみて
どうなるか試していただけませんでしょうか。

　 すいませんがCaptyTVしか素材が無いんで、これをQTPproで書き出しし たところ、

1. DV/DVCPRO-NTSC.mov（スキャンモード：インターレース）
2. DVCPRO50-NTSC.mov （スキャンモード：インターレース）
3. ← リニアにブレンドしやがりました（これわこれでw）。

メモ

も しかしたら、MPEG2-PSのサポートに問題があるのかもしれません。　

　2ch では特に出てない様子なので、「手許のファイル/システムがおかしい」可能性が一番高いと思ってます。
　次に「QTPPro+ MPEG2 再生コンポの仕様」を疑ってます。

１） QTPPro+MPEG2再生 コンポのみ、インターレース・non-awareな可能性。
　デコードはするもののインターレース ド・フラグを潰したデータを吐くなど。
　手許では、CaptyTV→MPEGStreamclip(convert to mpeg with MP2 audio)→MPEG-2 PS.mpegに、QTPProの「ソースビデオをデインターレース処理」が効いた記憶がありません。もともとこのコンポはプロ向けのドラフト・エンコー ド・ブラウザとして売られているものですし、4GB制限もそのままです。

1. ← m2v+aiff.mov を「ソースビデオをデインターレース処理」付きで Apple-H.264へ書き出し。

２） DVはたしかインターレースドがデフォルト。
　特に家庭用DVカムコーダはiMovie→iDVDと 直結するんで、DVは確実にインターレース・awareだと思ったのですが、勝手にインタレ解除しました。
　これはQTPPro内部 にMPEG-2起点の映像編集・加工を阻害するナニカがある事を示唆しています。

３） MPEG Streamclip、JES、Divaのインタレ解除は全て動作する。
　特にJESは UIで見る限りはインターレース・awareのようです。フロントエンド側では対処法が存在するようです。

　この記事の目的：同じpp系と言っても実装次第で効果に違いがあるかもしれ ない。Web上の情報を漁るときは注意して下さい。

　常用システムで x264Encoderが正常に作動しない為、メンテナンス用のクリーンなシステム（QT7.1.4）で使ってみました。MEncoderは常用システム でないと動かないのでそっちで。ツッコミ歓迎です。

　素材はポッ キーチョコレートCM「ダンスダンス篇」（30秒）。を、CaptyTVで録画したもの。
　 ストリーミングを見てもらえれば解ると思いますが、モブシーン＋ダンス＋パンとゆう地獄のハイモーション＆ハイディテイルです。
　た だし、今回の目的はインタレ解除性能を見る事なので、スクリーンショットの部分は「よくありそうな普通の動き」を選びました。
　な お、予算が潤沢なCMの場合、24fpsのフィルムカメラで撮影する事があるようですが、これは普通のTVカメラのようです。
　ま た、画質比較は今回の目的とはずれますが、この素材は1000フレームを切るので2パスでは統計ファイルの精度が充分になりません。1pass crfか、3以上のpassが必要です（今回使ったものはカットしたCMそのままとってあるだけなんで２分ほどあります）。

実 験

　スクリーンショットは目で見てだいたいこの辺だろうとアタリをつけたもので、正確なフレーム番号とかは解りません。
　x264 の設定を揃えて居ないので色味や質感は大幅に異なります。目的はインタレ解除の比較のみで す。

	Original （MPEG 2 PS）
x264Encoder	l5	md	QTDeint	md/l5
1pass crf (37～49MB)
MEncoder	pp=l5	pp=md	pp=lb	yadif=2,pp=l5
2pass 1024kbps (16.5MB)

pp=l5
　x264Encoder とMEncoderの差が大きい。
　lowpass5の意味は不詳ですが、弱っちい（5タップの低域通過フィルタを使った）リニアブ レンドと理解しています。
　MEncoderでは解除漏れは無く、ボケのやや少ないlbという感じで、一時期、NTSCの実写はこれ 一本でした。
pp=md
　差がない。
　median deinterlacerの意味は不詳ですが、前後フレームを「間をとった値で埋める」と理解しています。
　解除漏れや動くものの二 重化が無く、色味やディテイルのボケも少ない事からpp系の中ではもっともバランスの良いオールラウンダーだと思います。
　MEncoder のGUIラッパー（ffmpegX, D-Vision 3）も、これを採用しています。
　デメリットは動くものの輪郭部分のジャギ が目立つこと。上記では肩口や袖口に出ています。これはまばたきや台詞を言うときの唇にも出ますから、大事なシーンで興冷めと感じる人もいるでしょう。ア ニメでは描線がぶつぶつになる事が多いです。
　解除漏れが無いって書きましたけど、ウルサイ事いうと向かって右奥の生徒の後頭部、解 除漏れしてますね。
pp=lbと QTDeint
　以前、MyCometG3さんがpp=lbをQTの「ソースビデオをデインターレー ス処理」相当としておられたので同列にしてみましたが、大幅な差があります。
　MEncodeのpp系の中では色ボケ、輪郭ボケが最 も激しく、動くものも二重化しています。その代わり、インタレ縞は根絶できます。
　リニアブレンドの名の通り、前後フレームを一律に 混ぜると理解しています。
　一応、設定は大丈夫だと思うのですが。

　DEBUG: lavcEncoder: thePrefPPName: md thePrefPPLevel: 0

yadif=2,pp=l5
　MEncoder のみ。現在の手許常用。NTSC実写向け。
　yadifはフィールドのパターンを検出してなんらかの賢い計算をするようです。
　 単独でインタレ縞はほぼ充分に取れ、二重化もしませんが、地味なジャギが残ります。どうも「動く直線」に弱いらしく、サッカーのゴールポストとか、上の図 でいうと、背景の机が動いているか、カメラがパンまたはズームしていると、そこにジャギが出るハズです。完璧な直線でなくても、まゆげや唇など「どっち かっつうと直線」なものでもジャギる事があります。こうした部分をpp=l5を後付けでかけて潰しています（肩口や袖口のジャギ参 照）。
　l5の前後フレームを一律に混ぜるという性質上、色ボケや特に衣類の 質感はどうしても落ちますが、二重化はもちろん、ジャギはかなり落とせます。趣味的に色や質感よりは落語家の些細な顔の動きのほうが重要なので。
　 本来はpp=l5ではなくmcdeintを使うのがベストですが、x264そのものより遅い（インタレ解除のためだけにSnowの 動き補償を使う）ので、常用は困難です。
　似た効果を狙ってx264Encoderでpp=md、l5の順でかけて見ましたが、md 単独とあまり差が出ませんでした。

まとめ

　動機は、MyCometG3さんがpp=l5 等を解除漏れが『残る』と書いていたのが長らく疑問だったからです。
　MEncoderの経験上、pp系デインターレーサは「まずイ ンタレ縞根絶！他はどうでも！！」というスタンスのオプションと感じていたので。
　実験の結果、どうやら同じpp系といっても実装に よっては効果に差がありそうです。ffmpegやVLCでも違うのかもしれません。

　もとよりインタレ解除はコ デックの仕事ではありませんから、これを以てx264Encoderの性能を云々するのは間違いです。
　x264Encoderでは 他のフロントエンドのインタレ解除が使えますし、特にJESやMPEG Streamclipではバッチ処理もできます。QTにx264が来た以上、今後とも使い道は広がると期待できます。

　x264Encoderの設定を、MEncoderの常用設定とできるだけ揃えて比較してみた。主な設定は2pass,1024kbps, B-Frame=3。
　x264Encoder はMPEG streamclip経由で使用した。
　素材は実写の舞台中継『サクラ大戦歌謡ショウ「新・愛ゆえに」』。なんていうんだろう、歌謡ショウ？ミュージカル？まぁ宝塚みたいなもの。

　※緑がbetter

＼	項目	x264Encoder	MEncoder
1st	総フレーム数	350643	350643
	I枚数(I比率)	3047(0.87%)	1922(0.55%)
	AVG QP(I)	20.60	18.34
	AVG QP(P)	22.65	19.70
	AVG QP(B)	24.20	21.92
	sec	21801(6:3.21)	24084(6:41.24)
	fps	16.08	14.56
	SSIM	0.9785959	0.9928862
2nd
	AVG QP(I)	20.38	18.45
	AVG QP(P)	22.23	19.90
	AVG QP(B)	23.66	21.45
	sec	53102(14:45.2)	54198(15:3.18)
	fps	6.60	6.47
	SSIM	0.9793542	0.9929289

１. x264Encoderの方が高速。

　MEncoderで使ったx264オプションやビデオフィルタに違いはあるが、取り立てて重い部類のものでは無いと思う。MEncoderの21時間44分42秒に対しx264Encoderは20時間48分23秒と、トータルで56分程度の差がついた。GUI付き、ビルド済みの配布物でありながらこの速度は素晴らしい。ソースコード同梱なので、手許でビルドすればさらに速くなるかもしれない。

２.MEncoderの方が高画質。

　ただし、x264Encoderの画質は、おそらく多くの人が充分な画質と看做すと思う。
　手許ではSSIM=0.98以上、AVG QP(P)=20以下を一応の目標にしているが、主観的には少し低い（x264EncoderのSSIMはあと0.0007）からといってそうそう気になるものではないし、AVG QP(P)=22というのはffmpegXが固定QPではこれ以上下げない方が良いとしている値だ。

　原因としてはインタレ解除やスケーリングの性能差、自分がx264Encoderのデノイズに不慣れな事、細かいx264オプションの違いが考えられるが、最も目立つのはI枚数。

　手許の録画傾向およびMEncoderの経験上、I比率0.87%は実写としては比較的高い。アクション映画か、あまり手間のかかってないアニメ並みだ。確かに舞台中継は映像がダレないようにカット切り替えを多用するものだが、のべつまくなしにそれが続くというものでもなく、舞台全体を見渡すカットも結構長い。全体的なカット数は一般的な映画と大差ない範囲に収まっている印象がある（たぶん映像のプロの人が本能的にそうするのだと思う）。直近10件の落語を除く実写のI比率は平均0.62%。『マトリックス・レボリューションズ』の1.45%（これは『ゼーガペイン』を超えている）と『2004US_アレキサンダー』の0.84%を除外すると0.49%になる。

　MovieVideoChartで見ると、MPEG streamclipのx264Encoderの最大GOP間隔は5秒のようだ。

　MEncoderのGOP関連設定は、keyint=300:keyint_min=30:scenecut=40とデフォルトかつ定石の値（keyint=300は最大10秒@30fps）だが、MPEG streamclip・x264Encoderともに、x264Encoderにはkeyint、keyint_minに相当する指定項目が無く、設定を合わせる事が出来なかった。この部分はフロントエンドに任せていると思われる。MPEGStreamClipのヘルプによるとAppleの推奨キーフレーム間隔は5秒単位なので1.8でそれに合わせたとある。これがI枚数の違いを生み、bitを費消し、全体のQPを押し上げている。もしもここを弄る事ができれば、x264Encoderでコンスタントに1024kbpsでSSIM=0.98を狙う事ができるだろう。

 

３.その他の違い。

• MPEGStreamClipのインタレ解除は概ねpp=md相当。
  　地味にジャギが出る。画質差と言う点ではこれが一番目立つ。
• 音はMPEGStreamclipの方が良い。
  　FAACよりQuickTime AACの方が優秀。同じ128kbpsでもぜんぜん違う。最善はnero AACらしいが、Macでは動作しないようだ。
• GUIの方が楽。
  　当たり前だが習得も入手もMEncoderやffmpegより遥かに楽だし、MPEGStreamclipではバッチリストが使える。

4. 設定

　MEncoder(x264 core:54 svn-623M)

===MENCODER_PASS1===
 $ mencoder サクラ大戦歌謡ショウ「新・愛ゆえに」.mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=300:keyint_min=30:scenecut=40:qp_min=10:qp_max=51:qp_step=4:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cabac:nofast_pskip:dct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=1:threads=2:8x8dct:turbo=1 -passlogfile サクラ大戦歌謡ショウ「新・愛ゆえに」.264.log -vf yadif=2,pp=l5,crop=720:480:0:0,scale=640:480:::4,hqdn3d=4:3:6,harddup -sws 9 -ofps 30000/1001 -of rawvideo -o /dev/null
 ===MENCODER_PASS2===
 $ mencoder サクラ大戦歌謡ショウ「新・愛ゆえに」.mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=300:keyint_min=30:scenecut=40:qp_min=10:qp_max=51:qp_step=4:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cabac:nofast_pskip:dct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=2:threads=16:me=umh:me_range=32:subq=7:frameref=4:mixed_refs:8x8dct:partitions=all:trellis=2:brdo:bime:cqm=jvt:direct_pred=auto -passlogfile サクラ大戦歌謡ショウ「新・愛ゆえに」.264.log -vf yadif=2,pp=l5,crop=720:480:0:0,scale=640:480:::4,hqdn3d=4:3:6,harddup -sws 9 -ofps 30000/1001 -of rawvideo -o サクラ大戦歌謡ショウ「新・愛ゆえに」.264

　MPEGStreamclip1.8+ x264Encoder0.5.1

５. 余談：

　ゲキテイを途中で切るなぁああっ！！

　MPEG-2 PS（MP2音声）のTV録画からH.264/AVC High Profile映像+AAC音声の.mp4ファイルを作る方法。

使うもの

1. x264Encoder 0.5.2：QuickTime系フロントエンド （QuickTime Player Proなど）でx264エンコードを可能にするQuickTimeコンポーネント。
2. avc1Decoder 0.6.4：x264で生成したHigh Profile映像をQuickTime系Player（iTunesなど）でデコードするQuickTimeコンポーネント。
3. MPEG Streamclip 1.8：これがあればQuickTime Player Proはまず不要。
• ※MPEG-2 PS素材の場合、QuickTime Player Pro（有償）+ Apple MPEG-2再生コンポーネント（有償）には以下の制限がある。 MPEG Streamclipがあれば、買うのはMPEG-2再生コンポーネントだけで済む。Proキーもあればあったで楽しいですけど。
1. 映像と音声の同時書き出しが 出来ない。
2. 4GBより大きいMPEG-2 ファイルを読み込めない。

1. システム環境設定

　システム環境設定の「x264Encoder」でPre-Prosess levelをゼロにします。ここではインタレ解除をMPEG Streamclipで行う為です。

• 

2. MPEGStreamClipの設定

　MPEG Streamclipに素材ファイルを読み込み、Fileメニューから「Export to MPEG-4」を選ぶと、次のようなウィンドウが開きます。

	◆2 パスの場合 Multipassにチェック B フレームを使うならB-framesにチェック（使う方が縮む） 望みのファイルサイズになるようLimit Data Rateを入力。 音声は好みで。 地上波アナログなら Frame Sizeは640x480（4:3）にします。 Frame Rateは素材から読み取るので空欄で29.97fpsになります。 ※逆テレシネはありません。 Better Downscalingは多少画質が良くなりますが、やや遅くなります。 Deinterlace Videoにチェックを入れます（インタレ解除）。 他は取りあえず弄らなくて良いです。
	◆1pass crfの場合 Multipassをオフ。 B フレームを使うならB-framesにチェック Limit Data Rateは触らない方が画質は良いです。 ※入れると1000や2000では画質が良く無い事が多いようです。 Compression スライダでおおまかな画質が決まります。

3. x264Encoderの設定

　「Options...」 を推すとx264Encoderの細かい設定ができます。

◆2 パスの場合 図は実用的な範囲で最も時間のかかる=画質の良い設定例です。 avc1Decoder 0.6.4抜き、つまり素のQuickTime系で再生するには： FLAG_2_BPYRAMID(3) FLAG_2_8x8DCT の チェックを外します。 これまでApple-H.264を使っていた人は： nclc and gammaの二項目 　を使った方が色の違和感が少ないでしょう。 ア ニメの場合： sc_thresholdを65 程度まで上げた方が良いようです。 Bフレームを使わない場合、以下は効きません： FLAG_2_BPYRAMID(3) FLAG_2_WPRED FLAG_2_BRDO max_b_frames b_frame_strategy bidir_refine 速 度を上げるのに最も効果が高いのは： refs me_subpel_q... me_range 　 を下げる事です。どれも画質への影響も大きいので、 　デフォルト値以下にはしないのが得策です。 弄 らない方が良いもの： FLAG_2_FASTPSKIP や や速くなりますが闇階調ブロックノイズが出ます。 me_method UMH は劇的に遅くなる割に効果が薄いです。 qcompress 上 げても下げても2パスの意味が薄れます。 b_frame_strategy B を使うなら切らない。

◆1pass crfの場合 crfに チェックを入れます。

4. x264Encoderの設 定項目詳細

＼	Memo	MEncoder -x264encoptsの相当オプションと手許常用値
Box3	基 幹オプション1 　～最初にここを決め、残りはそれとの関連で決めましょう～
refs	速度と画質への影 響・大 複数参照 推奨値3程度。実用上限6程度。 増やすほど圧縮効率が良い。但し、そのぶん時間はうなぎのぼりで効果も漸減してゆく。	frameref=4 1stはturboが勝手に下げる
me_subpel_q...	速度と画質への影響・大 動き予測全般の算出方式を選択。範囲1-7。デフォルト5。推奨6以上。 5以上でないと効果を発揮でき ないオプションがある。	subq=7 1stはturboが勝手に下げる
me_range	速度と画質への影響・大 要・ me_method=umhまたはesa。 umhまたはesaで使える動き捜索の範囲指定。 実用範囲16-32。デフォルト16。	me_range 1stは16 2ndは32
max_b_frames	画質への影響・第２位⇒参考 Bフレームの最大連続枚数。推奨3程度。 いくつに指定しようがBに適さないフレームがあったら自動でI/Pにしてくれる。 Bが3連続するようなケースはまずない。	bframes=3
sc_threshold	画 質への影響・第１位⇒参考 Iフレーム挿入性向。デフォルト40 ほとんどの実写は40でOK。アニメは上げるべき。	scenecut 実写：40 白黒：65 アニメ：65 （かつkeyint_minを1以下）
qcompress	下手に弄 らない。 低くするとビットレートの変動幅が低くなる。=画質の変動幅が大きくなる。 高くするとquantizerの変動幅が低くなる。=画質の変動幅が小さくなる。 ※実写では0.7程度まで上げると画質が良いと言う資料もあるが、基本的に全体 平均ビットレートを低く抑えてbit 配分にメリハリをつけるほうが「画質が良い」。 　qcompressは上げても下げてもメリハリが失 せるという2Passでは画質的に難しい存 在。	qcomp デフォルトのまま。 むしろratetolや、qp_stepで ビットレートやquantizerの メリハリを強化。
noise reduction	ノイズリダクション MEncoderでは有用範囲は100-1000としている。	nr 手許ではhqdn3dを常用。
Box1	基幹オプション2
me_method	速度と画 質への影響・大 モーションベクトルのサーチ方式の指定。推奨はhexかumh。 速い順でumh、esa。 遅い方が画質が良いが、esaの画質向上は速度低下と引き合わない。 ※EPZSの内容不詳。x264cliには存在しない。	me=umh
coder_type	サイズと画質への影響・大 符号記述方式の選択。CABAC大推奨。 CAVLC：適応的可変長符号化 CABAC：15%程度の符号量節約。素のQTPlayerでも再生できる。負荷はエンコード・デコードともに増える。適応的二進数算術符号化 ※単独で15%も節約できるオプションは他に無い。	(no)cabac 必ず使用。
directpred	Bのbit節約になる。Bを使うなら推奨。 一口にBといってもAVCでは細かい種類がある。directはBのモーションベクトルをまじめに書き込まず「隣と同じ」とだけ書き込んでおくType。 まじめに数値を書くよりbitを節約でき、計算時間も早い。ここでは「どっちの隣か」を指定する。 disabled：無し、まじめに 計算して書き込む。画質も速度も最悪。 spatial：空間軸、mencoderの経験上、autoでもほとんどコレになる。最速。 temporal：時間軸、アニメでゴーストが出るという人も居る。これも最速。 auto：空間軸と時間軸を必要に応じて使い分ける。画質は最上、速度は中間。	direct_pred=auto 必ず使用。
trellis	適応的量子化の一種。理屈不詳。 Disabled：非使用 Only final：最終エンコードでのみ使用 All：全モード決定で使用。(低速、要・me_subpel_q...=6以上) ※使わないほうが画質が良いケースもあるとする人もいます。	trellis 必ず使用。
Worker Thereads	速度向上・大 Single/Dual/Quad ス レッド数の指定。 ※分散するほど画質は劣化するが、主観的にも数値的にも事実上無視して良い。	threads 1st=2 2nd=16 上記の理 由
Faster FirstPass	Faster FirstPass 速度向上・大 Disabled/Turbo1/Turbo2 2 パスモードの 1st passで重いオプションを切り、高速化する。 me_method, refs, me_subpel_q...の指定値を無視。独自値を使う。 画質的なデメリットは目で見てもまずバレない範囲とされる。	turbo=1 2パスの1stのみ。 必ず使用。
Box2
crf	1パスで済ませたい人用の「なんちゃって固定量子 化」。 2パスでは無意味。	crf 非使用。2パスしかやらない。 （3パスもやらない）
b_frame_strategy	適応的B挿入のオンオフ。 Bに適さない映像があったときに、勝手にPを使ってくれる。 切ると規則的にmax_b_framesで指定した枚数のBが入る。	b_adapt
cmp(chroma_me)	動き予測に色彩情報も参考にする。 白黒映画でも色彩情報は入っているので切らない方が良い。	chroma_me
partp4x4	細かいマクロブロックを使う。 粉雪とか桜吹雪とか落語家の顔の皺とかアナログ電波ノイズとか、をキレイに残したい場合に使う。bitrateも上げた方が良い感じ。	partitions
bidir_refine	Bフレームの動き予測精度向上。	bime
use 3rd pass	1000フレーム以下の短い素材で効果があるとされる。 ※短い素材はApple-H.264のマルチパス（パス数自動）に任せてしまうのも手。	pass=3
CODEC_FLAG2	補 助的なオプショ ン群
FLAG2_BPYRAMID(3)	Apple-H.264非互換 avc1Decoder 0.6.4が無いと再生できなくなる。 要・ max_b_frames=2以上 Bフレームを参照フレームに使う。Bのbit節約になる。	(no)b_pyramid 必ず使用。
FLAG2_WPRED	要・max_b_frames=1以上 適応重み付け予測。Bのbit節約になる。	(no)weight_b 必ず使用。
FLAG2_MIXED_REFS	要・refs=1以上 複合参照。マクロブロックパーティション単位で独自の参照先を選べるようにする。全体のbit節約。	(no)mixed_refs 必ず使用。
FLAG2_8X8DCT	High Profile専用 avc1Decoder 0.6.4が無いと再生できなくなる。 8x8DCT変換。 使うとほとんど8x8サイズブロックだらけになる。x264はHigh profileに重心がある。	(no)8x8dct 必ず使用。
FLAG2_FASTPSKIP	早い段階でPフレームのskip検出をする。 使った方が地味に速いが、x264最大の弱点「闇階調でフレーム単位でぱたぱたと動くブロックノイズ」が出がち。	(no)fast_pskip 必ずnofast_pskip使用。
FLAG2_AUD	mpeg-TSコンテナに入れる際に必要なものらしい。	不詳
FLAG2_BRDO	要・me_subpel_q...=6以上 Bフレームのレート歪み最適化。Bのbit節約。	(no)brdo 必ず使用。
CODEC_FLAG	補 助的なオプショ ン群
FLAG_LOOP_FILTER	デブロックフィルタ。切 らないのが基本。 MPEG系で発生不可避のブロックノイズ対策を映像データに埋め込む。 再生ソフトのデブロックフィルタ類はこの機能と競合する可能性有り。	(no)deblock 必ず使用
FLAG_PSNR	コンソールログにPSNRを表示。高いほど画質が良い。 値自体は無意味で、 同一素材の設定を試行錯誤する際に使う。 詳細は「SSIMとPSNRとは」参照のこと。	(no)psnr 必ず使用。
Console log
log info	コンソールログに様々な情報を表示。
log debug	コンソールログにデバッグ情報を表示。
log stats	コンソールログに2passの統計情報を表示。
nclc and ganma	QuickTime 固有の要素。
No nclc info	地味に色合いが変わる。特に互換性の問題は無い。	対応無し
Add gamma 2.2	※作者氏の記事参照。	対応無し
Native fps	素材に応 じて指定。