ageha was here

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

ホーム > アーカイブ－ 2006年12月

x264_TEST_Frame_type_01_GOP関連

目的

　keyint_min, scenecutの設定に対する応答性を調べる。

方法

　以下のツールをを使ってみた。
　なお、『アニメエンコで役に立つかもしれない覚書』ではffdshowでIPBの種別を視覚化している。ffplayに相当機能があるかもしれない。VLCには見当たらず。

１. MovieVideoChart 1.0.1

MyCometG3 さんに解説あり。

要Apple Developer Connectionアカウント（無料）。
Apple-H.264の制限を受けるため、Main profileでの作成が必要。
赤丸のついたフレームがGOPの開始点、つまりH.264/AVCではIDRフレームしか読み取れない。
フレーム番号のカウントは1から。

２. MEncoderの2passログ

コンソールで2passログを開き、フィルタで絞り込む。

MovieVideoChartで発見できないIフレームの数と位置を見る。
大文字（I）がIDR、小文字（i）がIフレーム。
フレーム番号のカウントは0から。MovieVideoChart とはいっこずれる。
総数はMEncoderがターミナルに" x264 [info]: slice I:24 "などと出す。

素材

　ケロロ軍曹のオープニング。なんでもかんでもやりましょお♪ってヤツ。
　選定理由なし。テストはずっとコレでやってるだけ。
　よく考えるとCGエフェクトあり（時間軸fps混在）、NTSC字幕あり（空間軸fps混在）、デジタル合成あり（時間軸＋空間軸fps混在）。

MEncoder設定

　MEncoder dev-SVN-r20806-4.0.1、x264 rev600。
　出力fps30、インタレ解除pp=l5。これは前後コマを混ぜてインタレ縞を潰すので左図のような「画像混濁コマ」ができる。
　クロップ無し、640x480、 1024kbps、frameref=4、Bフレーム無し、Main profile（理由前述）。ほか手許常用値。

　最初にkeyint=300:keyint_min=30:scenecut=40（標準的な設定）で作成してレファレンスとする。
　設定内容はPASS1,2とも完全に同じ。フレームタイプの決定は1stで全て決まり、挿入位置は変化しない。
　本来の目的に絞るなら1stだけで良いが、1stだけでは主観画質の比較が困難。
　主観画質は今回の目的ではないが、感性が引っ張られるのを避けたかった。

===MENCODER_PASS1===
/usr/local/bin/mencoder /Users/ageha06/Movies/TEST/scenecuttest/KERO_OP_01_min30sc40.mpeg -nosound -ovc x264 -x264encopts threads=2:bitrate=1024:bframes=0:nob_adapt:noweight_b:nob_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:cqm=flat:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=1:me=umh:subq=7:frameref=4:mixed_refs:no8x8dct:partitions=p8x8,b8x8,i4x4:trellis=2:brdo:bime -passlogfile /Users/ageha06/Movies/TEST/scenecuttest/KERO_OP_01_min30sc40.264.log -vf 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===
/usr/local/bin/mencoder /Users/ageha06/Movies/TEST/scenecuttest/KERO_OP_01_min30sc40.mpeg -nosound -ovc x264 -x264encopts threads=2:bitrate=1024:bframes=0:nob_adapt:noweight_b:nob_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:cqm=flat:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=2:me=umh:subq=7:frameref=4:mixed_refs:no8x8dct:partitions=p8x8,b8x8,i4x4:trellis=2:brdo:bime -passlogfile /Users/ageha06/Movies/TEST/scenecuttest/KERO_OP_01_min30sc40.264.log -vf pp=l5,crop=720:480:0:0,scale=640:480:::4,hqdn3d=4:3:6,harddup -sws 9 -ofps 30000/1001 -of rawvideo -o /Users/ageha06/Movies/TEST/scenecuttest/KERO_OP_01_min30sc40.264

結果

	設定（太字が変更点）			I枚数			画質（最良/最悪）
NO.	keyint	keyint_min	scenecut	sliceI	sliceP	I/P比	AVGQP(P)	PSNR(*2)	SSIM
01_min30sc40（標準的設定）	300	30	40	18	3138	0.57%	30.58	38.936	0.9698
scenecutのみ調整
02_min30sc75	300	30	75	24	3132	0.77%	30.61	38.908	0.9697
03_min30sc100	300	30	100	30	3126	0.96%	30.67	38.892	0.9696
keyint_minのみ調整
04_min15sc40	300	15	40	20	3136	0.64%	30.60	38.923	0.9698
05_min0sc40	300	0	40	21	3135	0.67%	30.60	38.927	0.9698
両方極端に
06_min0sc100	300	0	100	34	3122	1.09%	30.68	38.900	0.9696
07_nokeysc100（IDR排除*1）	6000	6000	100	13	3143	0.41%	30.57	38.923	0.9698
08_min300sc100	300	300	100	19	3137	0.61%	30.60	38.919	0.9697

*1）事実上の無限大で先頭以外のIDRは排除され、すべてIとなった。 VLCで10secシークするとスゲェブロック。
*2）PSNRは通常、0.2違えば目で見て解る、0.1の差は解らないと言う。従って、画質差は全然解りませんでしたw。

まとめ

数値的画質

ベストは01_標準的設定。07_IDR排除がそれに次ぐ。といってもPSNRは大差ない。
ワーストは keyint_min =100系。
実写では標準的設定からあまり乖離しないほうが良いと思われる。

keyint_minの応答性は低い。これを弄ってもI/IDRはたいして増えない。
scenecutの応答性は高い。 I/IDR を増やすならこれ。但し、この素材で増えたのはIDRのみで、他の設定でIだった箇所までIDRに化けた。

従ってscenecutはIDR 挿入性向にも影響。
となると、keyint_min=<16はframeref（-r,-- ref）指定値との整合性に要注意。但しこの素材ではそんな接近したキーフレームは無かった。

pp =lbの画像混濁コマはIDRになりがち。

これもframeref（-r,--ref）の効果を減じかねない。直後のPフレームのbit量を押し上げている箇所があった。正確なインタレ解除は重要。

スポンサーサイト

[ 2006/12/02 00:00 ] MEncoder　メモ | TB(0) | CM(0)

概説

MEncoder Document：x264コデックでのエンコード

　他のコデックでのエンコードに慣れている人の中には、B-frameは必ずしも有益とは限らない事をご存知の方もあるでしょう。H.264ではこの常識は異なります。 B-frameで使える新しい技術とブロックタイプができました。一般的に、単純なB-frame選択アルゴリズムでさえ、目覚ましいPSNRゲインが得られます。また面白い事に…

　Bフレームを2以上にすると適応的Bフレーム（b_adapt）、Bフレームの参照化（b_pyramid）、bime、brdo、weight_bなどの活躍余地が増え、全体的な圧縮効率が向上します。順序としては、まずBフレームに適さないコマをb_adaptが選り分け、残ったBの中にb_pyramidが参照関係を構築する、そして基幹部のB生成工程にbime、brdo、weight_bが取り付いて無駄なbitを削りとる。この連携がx264の花。ゴミのようなオプションを山のように積み上げるH.264/AVCの本領です。それぞれの効果は相関関係にあるので「こうすれば良い」とは書きにくく肚に落とすのはちとホネですが、把握する価値はあります。

　最大Bフレーム数が1以下のApple-H.264は、この連携効果を発揮できません。練達の騎兵師団に下馬を命じて拠点防衛に回すようなものであり、High Profile非対応などよりはるかに問題です。

　ただし、少なくとも MEncoderでは若干のデメリットがあるようです（decoding delay）。

Frame-type_B フレーム関連オプション

x264cli (rev600準拠)	MEncoder -x264encopts (dev-SVN-r20806準拠)

-b, --bframes <integer>

bframes=<0-16>

■ まとめ：2～３。1にするなら後述の適応的Bフレームを切る事。

　デメリットはB使用で映像冒頭に指定値に応じた数の delay frameが入る事（手許欄参照）。
　VfW系ではこれをDropできるフロントエンドが存在するようだ。
　AviSynth to x264cliルートは不詳ではdelay frame問題は発生しない（コメント欄参照）。

　なお、規格上は双予測（Bi- Predictive、前後問わず2 枚を参照）だが、x264は双方向予測（Bi-directional Predictive、前後各1枚を参照）の模様。根拠は各文書の用語がBi-directionalで統一されている事。

■参考

覚書（要約）: 常用値不詳

手許: 常用3; B使用で冒頭に指定値に応じた数のdelay frameが入る（参考）
QTPlayer では再生のみOK（B使用、Main Profileで作成の場合）。
ただし開始点からのシークで問題が出る。一旦再生スタートして delay frameを過ぎればシーク可。QTインフラ上での再加工（音声貼付けなど）は一切不可となる。部分的に規格外のVideo Streamと思われる（VFRのできるコンテナでnull frame受け付ける意味無いから）。

これはMEncoder/ffmpegを使う限り不可避。esperanceは内部的にdelay frameをドロップする。virtualdub(mod)はXvid.avi時代からドロップしていた模様。x264cli不詳ではこの問題はない。

MP4box に渡す前に正確に発見、除去する手段が欲しいところ。

デフォルト=0の意味は、そのへん理解して使ってという意図、VfWベースのフロントエンドに対するフールプルーフ、Baselineへの配慮、などが考えられる。

反面、B関連の向上はH.264の目玉の一つ。
手許では1年程Bフレームは1～3で作っているが、実用上delay frameと思しきa/v desyncは知覚できていない。可能性としてはフレッド・アステアのミュージカル映画など、A/V Syncが死活的に重要な素材で問題があり得る。

bit を有効に使いたければ使うべき。

MeGUI2.0 Help（ContextHelp v0.2 06/01/01）: bframes name="Maximum B-frames"; 推奨2～3
default0

双方向予測フレームは高圧縮。前フレームからの変化か、後フレームとの差しか保存しないから。Bフレームは一般的にIやPよりも画質が悪いが、全体の符合化効率が向上するのでビデオ全体の画質は向上する。一般的には2か3で、ベストな画質と目覚ましい圧縮効率になる。

（＊双方向予測フレーム=Bi-directional Predictive Frames＊）

man MEncoder: IとPフレーム間でのBフレームの最大連続数。(default: 0)

zero1(svn408): Usage: --bframes <integer> (default=0) [0 - 16]; I とPフレームの間でのBフレームの最大連続数を調整する。
Xvidや他のMPEGエンコーダでBフレームには慣れている人は多いと思う。
Xvid でこれに相当するオプションは"Max consecutive B-VOPs"。
Bフレームは符号化効率の観点からは非常に良いものだが、たくさん使う程デコード負荷が上がる事を心に留めておく事。

MEncoder Doc: 　他のコデックでのエンコードに慣れている人の中には、B-frameは必ずしも有益とは限らない事をご存知でしょう。H.264ではこの常識は異なります。B-frameで使える新しい技術とブロックタイプができました。一般的に、単純なB-frame選択アルゴリズムでさえ、目覚ましいPSNRゲインが得られます。また面白い事に、B-frameを使うと通常2ndパスが若干高速化し、adaptive B-frame decisionを切った場合はシングルパスも高速化する事があります。

　adaptive B-frame decision がオフの場合(nob_adapt)、一般的な最適値はbframes=1以下です。他の場合動きの多いシーンで画質劣化が起きます。adaptive B-frame decision がオンの場合は(default)、もっと大きな値を使っても安全です。圧縮を妨害しそうなシーンでエンコーダが B-frame の使用を控えます。エンコーダが3や4以上の B-frameを使う事は滅多にありませんから、それ以上の値を指定しても効果は薄いです。

--no-b-adapt

(no)b_adapt

■ まとめ：Bフレーム2以上ならオン。1なら特に理由が無い限りオフにすべき。

　Bフレームに適さないコマを発見し、フレームタイプをPにする（IにするかどうかはGOP 関連設定で決まるのだと思う）。
　フレームタイプは1stで決まるので2ndやNthパスでは指定しても意味が無い。
　印象としては非常に強力で、IPPPやIBPP連発。IBBBはかなり少ない。フェードだらけなど weight_bのメリットが高そうな素材では切った方が良いケースもあり得る。マニアックにいくなら次の b_biasでこの強度を調節できる。

■参考

覚書（要約）記載無し	手許常時使用
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） no-b-adapt name="Adaptive B-frames" 推奨：Enabled default： Enabled B フレーム挿入の際に定数ではなく、x264に挿入枚数を必要に応じて決めさせる。 Bフレームが不適当な箇所で Bの連続数が減る。	man MEncoder bframes=< 0-16>で指定された最大Bフレーム数の範囲で、いつ、どれだけの数のBフレームを使うか自動的に決断する。オフの場合、前述のbframes=<0-16>(デフォルトで0)の最大Bフレーム数を使用する。
zero1(svn408) Usage: --no-b-adapt (default=on) 　このオプションは適応的Bフレーム挿入をオンにするもので、一般的にはお奨めできない。このオプションを使うと（デフォルトはenable。--no-b-adaptで切る）x264がどこにどれだけのBフレームを使うか自動で決める。（＊最大？＊）何枚使うかは上記の--bframesで決まる。（＊:Zero1氏の記述根拠不明。下記とも矛盾。未推敲箇所と思われ。＊）	MEncoder Doc : Note: defaultでオン。　このオプションを使うと、エンコーダはまずまず合理的な速度で、B-frameの効果の薄いシーンのB- frame数を減らす計算をします。b_biasを使って、間引く程度を調節できます。adaptive B-frameの速度低下は目下のところは慎ましいものです。しかし望み得る画質向上の程度も同様です。まぁ、通常は害はありません。1stパスの速度とフレームタイプの決定にしか影響しない事に注意して下さい。b_adapt と b_bias は後続のパスにはなんの影響もありません。

--b-bias <integer>

b_bias=<-100-100>

■ まとめ：素材映像に応じて調整 or 弄らない

適応的Bフレームの強度調整。
デフォルト値の印象は非常に強力で、Bフレーム3でもIPPPが頻発する。IBPPやIBBPも多く、IBBBP（Bフレーム3ならそうあるべき）は存外に少ない。
本来は映像内容に応じて調整すべきものだろうが、これに手を出すには以下の条件が必要だ。
１） Bに適さない映像とはどのようなものかを知る事。
２）エンコード後の映像でどのコマがBかを正確に発見し、その画質を確認する手段（WinならMPCで正確なフレーム番号に飛べるようだ）。

■ 参考

覚書（要約）言及未発見	手許常用0(default) default の場合、 Bフレーム=3でも結構0～2連続が多い。これは最大Bフレーム数を16などとしても安全だと言う事だ。それで削れるbitは文字通り片手で数えられるレベルと思うけど。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） b-bias name="B-frame Bias" 推奨：0 default： 0 プラスの値でBフレームの使用傾向が強まる。マイナスは使用を控える。"Maximum B-frames" の設定値は超えない。	man MEncoder b_adapt の「決断力」の強さを設定する。高い程沢山のBフレームを使う。 (default: 0).
zero1(svn408) Usage: --b-bias <integer> (default=0) [-100 - 100] 　適応的B フレームの挿入に影響。高いほど、指定された最大値までの範囲で、Bフレームを沢山使う。低い値では減る。　Xvid でのB-VOP sensitivityに相当。　-100から+100までのスライダがあると思えば良いだろう。-方向がB を減らし、+方向がBを沢山使う。　推奨値はデフォルトの0のまま（スクリプトに書かないのと一緒）。というのはB使用を強制すると画質が悪くなる事があるからだ。特に暗い領域やフレームで多い。	MEncoder Doc 言及無し

--b-pyramid

(no)b_pyramid　＊QT７非互換＊

■ まとめ：使わない場合はBフレームを1に。使用にはBフレーム数2以上が必要。

　Bフレームを参照フレームにすることで、Bが連続した場合の画質劣化を抑止。参照といっても参照（≒依存）関係は連続するBの内部に限られる。
　x264 のb_pyramid には内部的に複数参照に似たdepthという概念があり、最大で2。これはオプションでは弄れない。
　一応デメリットもあるので気にされる方は下記を読み比べて欲しい。

■ 参考

覚書（要約）言及未発見	手許常用オン。デフォルト不詳。Profile 不詳。 QT7非互換だが、Doom9氏の言う"Main対応と言うには不可解な制限"の一つか？これが無ければB推奨値は1。 b_pyramid には複数参照類似のdepthという概念があり、x264では2。これはオプションでは弄れない。従って最大 Bフレーム数は3が有効と思われ。 MEncoder・ x264cliを問わずデコーディング・ディレイが発生するようだが、実写・アニメとも知覚できた事がないので手当していない。Bフレームを使った場合の delay frameと合わせ3フレームはずれてる筈なんだが… なお、教科書などを読むと規格上はBを参照するPがあり得るようにも読めるが、ちょっとメリットを考えにくい。x264の実装で妥当と思われる。C読めないけど。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） b-pyramid name="B-frame Pyramid" 推奨：使用 default：非使用 B フレームに他のBフレームの参照フレームになる事を許可する。2以上のBフレームを使っている場合、符号化効率の向上になる。	man MEncoder Bフレームを参照フレーム～他のフレームが予測に使う～に使うことを許可する。例えば、連続したBフレームが3個あるとしよう I0 B1 B2 B3 P4 b_pyramidオプション抜きの場合、 BフレームはMPEG-1/2/4と同じパターンに従う。つまりこれらは I0 P4 B1 B2 B3 の順番で符号化され、全てのBフレームは I0 とP4 をベースに予測される。 b_pyramidオプション有りの場合、これらは I0 P4 B2 B1 B3 の順番で符号化される。B2は上記と同じだが、B1は I0 と B2 を、B3 は B2 と P4 をベースに予測される。この結果、速度低下抜きで圧縮率が僅かに向上する。しかしながら、このオプションはまだ実験段階だ。チューニングは未熟で必ずしも効果があるとは限らない。オプションの bframes=<0-16>は2以上でなければならない。デメリット：デコーディング・ディレイが2フレームになる。
zero1(svn408) Usage: --b-pyramid (default=off) 　Bフレームの一部を参照フレームに使う。　符号化効率の向上が望める。というのは、Bをもとに他のフレームを予測できるからだ。2以上のBフレームが必要で、2フレームぶんのデコーダ・ラグが生じ得る。デフォルトでは適用されず、コマンドラインに--b-pyramidを付加する必要がある。	MEncoder Doc : B-frameを2以上にする場合はこのオプションも使った方が良いようです。man pageにある通り、速度低下抜きで若干の画質向上が得られます。2005/03/05よりも古いlibavcodecベースのデコーダは、これを使った映像を読めない点に注意して下さい。

[ 2006/12/04 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(4)

1.3. Frame-type_その他

概説

　比較的効果が高いが議論にもなり易いオプションが固まっている。再生環境や CPUパワーに応じて選択すべき。特にframeref(-r. --ref)はsubq(-m, --subme)と並んで最も速度と画質への影響が大きい（遅いほど圧縮効率が良い）。参考元はどれもそれぞれの推奨値があるが、ここは特に自分のCPU と忍耐力に相談する必要がある。

Frame-type_その他のオプション

x264cli (rev600準拠)	MEncoder -x264encopts (dev-SVN-r20806準拠)

--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を使う人が多い模様。
規格上は multiple reference、複数参照と言われるが、不等距離参照とか自由距離参照とか適応参照とか…のほうが肚に落ちる。
直前よりももっと前のフレームを参照できるようにするもの。
値が大きいほど速度低下が激しく、効果も減って行く。時間軸予測の動き補償に効くものなので、実際の効果は映像内容に大きく左右される。
理屈の上ではkeyint最小値を下げすぎると影響を受け得るが、手許の実験ではあまり心配する必要は無さそう。

■ 参考

覚書（要約）・- 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以上にします。こうしたケースはライブアクション映像では極めて稀でしょうが、ビデオゲームのキャプチャでは時折ある事です。

--no-deblock

(no)deblock

■ まとめ：

別名ループフィルタ、インループフィルタ、インラインデブロック、などなど。
MPEG系で不可避のブロックノイズ対策をコデックの内部に埋め込んでしまおうと言うもの。詳細次項。

■ 参考

覚書（要約）・デブロックフィルタを、使わなくします。　--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 未記載

[ 2006/12/05 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(0)

問おう。スポーツとはなにか？

「ゲームもスポーツ」種目採用　来年のアジア室内大会（asahi.com）
2006 年12月05日15時55分

　アジア・オリンピック評議会（ＯＣＡ）が、サッカー、バスケットボール、自動車レースの三つの家庭用ゲームを「Ｅスポーツ」として、第２回アジア室内大会（０７年、マカオ）で新採用する。「戦略で頭脳を使い、指先を動かす、れっきとしたスポーツだ」と、ドーハで開催中のアジア大会を利用してＰＲしている。

　「Ｅスポーツ」は今年４月の理事会で採用が決まり、「暴力、性的なシーンがなく、人気がある」などの基準から三つを選んだ。アジア室内大会はフットサル、競泳の短水路などを行う。０５年バンコク大会が第１回と歴史が浅く「従来のスポーツの概念にとらわれない」としている。そうした考えに加え、若者に浸透しているなどの理由で家庭用ゲームを採用したという。

　サッカーの「ウイニングイレブン」などソフトも決まっており、選手は各種目、各国・地域から最大１人とする。

　「ゲーム大国の日本が金メダル本命。韓国が対抗」というのが組織委の見立て。ただ、日本オリンピック委員会（ＪＯＣ）は「そもそもスポーツと言えるのか。選手を派遣してと言われても、国内統括団体もない状態でどうするのか」と戸惑っている。

　私はこのJOC担当者に問いたい。そもそも、スポーツとはなにか？

　太陽の下とか、健全とか、そーゆー人によりイメージの変わり得る情緒的形容詞、禁止。
　わかるでしょとか、常識的にとか、そーゆー思考力がかわいそうな答え、禁止。
　自分のコトバで、タマシイの血の輝きの宿るコトバを聞かせて頂きたい。

　賭けてもいい。こいつは何も言えない。それは、「スポーツ」の事などなにも知らないと言う事だ。

　コナミのみなさん、おめでとう！！

　自動車レースはなんだ自動車レースは、どこにあるんだ種目のリストは。ねぇなぁ…、ナムコ政治力ねぇからなぁ…。

　第２回アジア室内大会公式サイト

[ 2006/12/05 00:00 ] ゲームのミカタ | TB(0) | CM(0)

LINK：Linux用アニメ自動録画システム、 foltia

tracはあるわSVNはあるわインスコマニュアルはあるわでそらもースンゴイ事になっている。
linuxの方は是非お試し頂きたい。

ドライバが無いんでMacでは動かないのだとか。ま、それはともかく。
公開おめでとうございます。

[ 2006/12/08 00:00 ] 動画　動画全般 | TB(0) | CM(0)

2. Ratecontrol options:

概説

　ここではなによりもまず1パスか2パスかマルチパスの選択を迫られる事になる。
　速度を取るなら1パスだが、技術的な理由でXvidのように固定QP3なら画質もサイズもまずまずといった目安が無い。そういう事を言うのが無意味だと言うのではなく、それがネットの向こう側で通用する確率は非常に低いという事。とはいえ需要は大きく「固定QP風味」のcrfが用意されている。これでかなりXvidの固定QPに近い使い勝手になる。bitrateも指定してやるとそれもなるたけ尊重してくれるので便利だ。ただし、1パスでの画質比較は混乱の素だ。エンコードの度にビットレートが大きく変化するので、画質変化の原因がオプション調整のせいなのか、ビットレートが変わったせいなのか判断のしようが無い。
　ひらたく言うと、1パスエンコは一期一会だ。Net上の情報はアテにできない。
　2パスを使う事で、相当程度のbitの有効利用と、画質や設定比較が可能となる。
　3パス以上は概ね1000フレーム以下の短いクリップに効く。他にも効果のある非常に特殊なケースというものがあるようだが詳細は不詳。
　H.264/AVCのパスは重ねれば重ねる程、bit使用効率が向上する性質（主にモーションベクトルの算出精度、マクロブロックタイプの最適化）を持つ。Apple-H.264はここにチューニングの軸足を置いたようだ。x264でも同じ手は使えるが、はっきりと知覚し得る画質向上は10パス単位（覚書、なるP氏）。オープンソースの性質から言ってもチューニングはカジュアル・エンコード向けの「時間のかかりすぎない」用法に軸足がありそうだ。
　なお、PPC Macで3以上のpassを重ねるならApple-H.264の方が速く済むケースがあり得る。x264であれこれ悩むよりは楽な上に画質で問題が出る事も少ない。

Ratecontrolオプション

x264cli (rev600準拠)	MEncoder -x264encopts (dev-SVN-r20806準拠)

-q, --qp<integer>　[26]

qp=<0-51>　[26]（＊未試用＊）

■まとめ：

ASP QP=2 は概ね H.264 のQP=18。対数計算のできる人はH264QP = 12 + 6*log2(ASP QP)。
0でロスレス。事実上ロスレス専用なので、固定画質1パスならこれではなく後述のcrfを使おう。

■参考

覚書（要約）・Q値設定。defaultは、26。　設定整数値を小さくすると、ビットレートが上がる。0は、losslessだ。　default値のQ値には少し不満が出る。　過去のコーダ同様少しビットレートを増やす程度に変更すると納得いくかも。　画質と容量とを、自分の用途にあわせて煮詰め、Q値を設定したい。　30より大きい数字は、劣化具合がカナリ強くなる傾向になる。	手許未試用の理由 2パスしかやらないから。 MEncoder の旧称qp_constantからも1pass CQ（Constant Quantizer、固定量子化）ではあるが、いわゆる画質固定1パス派にはcrfの方が評判が高く、2passモードの1stとしても推奨されていない。事実上ロスレス専用か。　目標画質 2pass などでAVG QP(p)が18を切れば、数値的にはXvidでは実現できない画質と言える。　 logarithmic scale Xvidのquantizer（量子化、画質劣化度）は2が画質上限で、3,4,5,,,と整数しかなかったのが、0(ロスレス)を上限に少数が使えるようなもの、くらいでいいと思う。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） qp name="Constant Quantizer" Recommended： 26 Default： 26 Encode in Constant Quantizer Mode (0 = lossless)	man MEncoder ＊旧称qp_constant＊実用的範囲20～40 (default: 26)。 Pフレームに適用する量子化値の指定。IフレームとBフレームに適用する量子化値はこの値を元にip_factor と pb_factorが少しずらして決める。低い数値ほど素材画質に忠実で、ビットレートが高くなる。0でロスレス。 H.264 の量子化はMPEG-1/2/4とは異なる事に注意。H.264の量子化パラメータ (QP)は対数尺を用いる。換算すると概ねH264QP = 12 + 6*log2(MPEGQP)。例えば、MPEGのQP=2 は概ね H.264 の QP=18となる。
zero1(svn408) Usage: --qp <integer> (default=26) [1 - 51] (0 = Lossless) P フレームの量子化値を固定。IフレームとBフレームに適用する量子化値はこの値を元に--ipratio と --pbratioのQP係数から計算される。 Xvid同様、量子化値が低いほど画質が良いが、注意すべき事がある。 x264のQP2はXvidのQP2と同じではない。 Xvid のQP2に等しいx264のQPは18だ。これはH.264が対数尺（logarithmic scale）を使う事に拠る。同程度のQPを求める換算式はQP AVC qp = 12 + 6*log2(ASP qp)。 x264 では量子化値を0にするとロスレスもできる。	MEncoder Doc 記載無し（2パス前提の為）

-B, --bitrate <integer>

bitrate=<value>（＊常用1024＊）

■まとめ：

　適正bitrateというのは昔から素材と感性次第。一応bpp早見表を用意したので参考にして頂きたい。

■ 参考

覚書（要約） 704x480で1600～2500 といった数値が見える。 bpp概算で"まずまずだがブロックノイズが見える（0.2）"～"無意味。むしろ解像度を上げるべし（0.3）"の範囲と思われる。手許（ageha）とは大幅にスタンスが異なる事に注意。特に画質に対する主観評価で違いが出て来ると思う。覚書（なるP氏）の方が画質に厳しい筈だ。ここまでbitrateに差があると、細部の設定方針も大幅に差があるハズ。	手許横幅640、1024固定。 bpp概算で"低画質(0.15)"～"まずまずだがブロックノイズが見える (0.2)"の範囲。覚書（なるP氏）とは大幅にスタンスが異なる事に注意。特に画質に対する主観評価で違いが出て来ると思う。自分の方が画質に甘い筈だ。ここまでbitrateに差があると、細部の設定方針も大幅に差があるハズ。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） bitrate name="Bit Rate" Recommended： N/A Default： N/A Set bit rate per second (kbps)	man MEncoder 平均ビットレートの指定。単位kbit/sec(default: off)。ローカルビットレートは変動するため、非常に短いムービーでは指定値とかけ離れた値になる事がある(ratetol参照)。このオプションと vbv_maxrateを同時に使うと固定ビットレートになるが、画質は著しく劣化する。　＊ローカルビットレートビットレート配分を計算する際の単位となる区間の模様。平均化区間というコトバも散見される。1パスでも使う。つまり少なくともx264には、固定ビットレートエンコードや固定quantizerエンコードを想定していない。できない事はないが、全体的なオプションの構成やデフォルト値がそういう作りになっていない。
zero1(svn408) Usage: --bitrate <integer> (default=off) 平均ビットレートの指定。単位Kbps(kilobits per second)。特定のファイルサイズにおさめたければ、推奨方式は2パスだ。特定ファイルサイズと画質が両立できる。1分程度より短いクリップでは3パスが有効な事もある。 x264 の --bitrate は本質的にABR（平均bitrate）でもしCBR（固定bitrate）を使わなければならないなら（ストリー民具以外にCBRのメリットはほぼ無いが）、--vbv-maxrateも弄る必要がある。	MEncoder Doc -

--crf <float>

crf=<1-50> （＊1pass ABR用＊）

■まとめ：

「固定QP風味」エンコード。Xvidなどにあった1パス VBRをやるにはコレが便利。
実際には素材を短い区間に区切ってその中でABRを行う模様。

■参考

覚書（要約）記載無し	手許１パス向け qp（旧称qp_constant）より実用的。 bitrate指定もできる。指定通りのbitrateにはならないが、まぁ、頑張る。 crf=25,bitrate 指定抜きで1173kbpsだったものに700kbpsを指定すると815kbpsになる。とりあえずcrf使っときゃ1パスで容量可変＆そこそこの画質になる。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） Recommended： 26 Default： 26 Quality Based VBR (nominal QP)	man MEncoder 固定画質モードのenable。値は画質を指定するもので、概ねQPに近い。ビットレートベースのモード同様、各フレームごとに複雑さに応じて異なるQPを使う。
zero1(svn408) Usage: --crf <integer> (default=off) [1 - 51] 固定レート係数。名目上（＊nominal＊）のQPに基づく1パスVBRモード。	MEncoder Doc 記載無し

--vbv-maxrate <integer>　[0]

vbv_maxrate=<value> (ABR or two pass)　[disabled]（＊未試用＊）

■まとめ：

一般的には弄るべきではないようだ。

■参考

覚書（要約）記載無し	手許 x264は1パスでも平均化区間を使ったABR。その区間内での最大ビットレートと思われる。平均化区間や VBVについては次項。 2パスでも使うようだが影響不明。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） vbv-maxrate name="VBV Maximum Bit rate" Recommended： 0 Default： 0 ローカルビットレートの最大値。	man MEncoder ローカルビットレートの最大値。単位はkbits/second(default: disabled)。
zero1(svn408) 記載無し	MEncoder Doc 記載無し

--vbv-bufsize <integer>　[0]

vbv_bufsize=<value> (ABR or two pass)　[none]（＊未試用＊）

■まとめ：

一般的には弄るべきではないようだ。

■参考

覚書（要約）記載無し	手許平均化区間 x264 は1passでもストリームを平均化区間に分割してABRを行う。ローカルビットレートとは、この平均化区間内のビットレートと思われる。　 VBV Video Buffer Verifier、ビデオバッファ検証器。 H.264/AVC規格はデコードの規格なので仮想参照デコーダ（HRD,Hypothetical Reference Decoder）というバーチャルなデコーダモデルがある。これを破綻させないようなデータを吐くコデックを作りなさいねという事。 VBV はこのHRDの中の一部分。 …という印象を受けた。（教科書185p）
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） vbv-bufsize name="VBV Buffer Size" Recommended： 0 Default： 0 Size of VBV buffer	man MEncoder vbv_maxrate で使う平均化区間。単位kbits。 vbv_maxrateを使うときは必ず指定する事。(default: none)
zero1(svn408) 記載無し	MEncoder Doc 記載無し

--vbv-init <float>　[0.9]

vbv_init=<0.0-1.0> (ABR or two pass)　[0.9]（＊未試用＊）

■まとめ：

一般的には弄るべきではないようだ。

■参考

覚書（要約）記載無し	手許前項参照
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） vbv-init name="VBV Initial Size" Recommended： 0.9 Default： 0.9 Initial VBV buffer occupancy(＊占有/占有期間＊)	man MEncoder イニシャルバッファ占有率。vbv_bufsizeの係数。 (default:0.9)
zero1(svn408) 記載無し	MEncoder Doc 記載無し

--qpmin <integer>　[10]

qp_min=<1-51> (ABR or two pass)　[10]（＊常用10＊）

■まとめ：

一般的には弄らない。画質にこだわるなら下げる。
量子化工程はブロックノイズの発生源なのでデフォルトのチューニングは最も入念に行われているものの一つ。
しかし、闇階調のブロックノイズなどをどうしても消せない場合は、bitrateを上げると同時にこれも下げるのも良いだろう。
素材に応じたカスタム量子化マトリクスを使いこなす場合は、また別の方針が必要と思われる。

■参考

覚書（要約）・--qpmin,--qpmaxは、-q,-Bよりも優先。指定しない方が、融通は利く。しかし、マックス値を制限させた方が、画質は安定傾向になる。 max値を無理が無いように、美味く設定したい。　 --qp 26がdefault値だ。エンコする作品で加減具合が変わるのはもちろんですが、Xvidと同じで使うマトリクスで大幅に感覚が変わります。　 2pass 以上で書き出されるI・P・Bそれぞれが使ったQ値のアベレージ値に慣れてから、Q値を使う感じがいいと思います。　 Doom9 によると、使えそうな数値は--qpmin ～ --qpmax＝10 ～ 30ぐらいだそうな。マトリクスがflatならば、その通りだと思います。自分の適正値を探しましょう。	手許 quantizer 辞書的には量子化。フツーの人的には「画質劣化度」でも良いかと。 MPEG-1/2/4、JPEGが使う。原理的にブロックノイズ不可避。　 "--qpmin,--qpmax は、-q,-Bよりも優先"について　-q, --qpはMEncoder側の旧称qp_constantからCQエンコード専用と思われます。　bitrate 指定値よりもqp_min、qp_maxが優先するというのは、経験がありません。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） qpmin name="Minimum Quantizer" Recommended： 10 Default： 10 Quantizer最大値の指定。ビットの無駄になる圧縮不足フレームの出力を抑止	man MEncoder quantizer の最小値。10-30が適正範囲のようだ。 (default:10)。
zero1(svn408) Usage: --qpmin <integer> (default=10) [1 - 51] x264が使う量子化値の最小値を指定。より低いquantizerを使っても大して見た目が変わらないような箇所でbitの浪費を抑える。 Xvid で最小量子化値を2にしていたのと似ているが、H.264の量子化スケーリングの違いを忘れないように。	MEncoder Doc

--qpmax <integer>　[51]

qp_max=<1-51> (ABR or two pass)　[51]（＊常用51＊）

■まとめ：

■参考

覚書（要約） 48,43,38 など指定しない方が融通が利くがmaxを制限した方が画質が安定傾向として細かく調整している。　（＊おそらく一個一個の作品にこだわってエンコしてらっさる模様。＊）	手許 51固定 (default) 自分も覚書(なるP氏)同様の考えから一時期maxを制限していたが、弄るに値する程の差を知覚できなかった。手許の常用bitrateは1024固定だが、このレベルではmaxキャップは実際上無視されるケースが多いようだ。　多彩な設定値を試している事から、覚書の人のほうが自分よりこだわり度が高く、知覚も鋭そうです。　　ただし現実的には、このへんは視力や色覚や感性以上に、モニタサイズが占める割合も大きいと考えます。全画面表示ならピクセル数の多いモニタほど、プレイヤやOS が使う拡大縮小アルゴリズムを考慮する必要が出てきます。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） qpmax name="Maximum Quantizer" Recommended： 51 Default： 51 Quantizer最小値の指定。画質の悪い過圧縮フレームの出力を抑止。	man MEncoder quantizer の最大値 (default: 51)
zero1(svn408) Usage: --qpmax<integer> (default=51) [1 - 51] x264が使う量子化値の最大値を指定。量子化の激しいフレームがあったら低くすると良い。一般的にはx264のレートコントロールは非常に優秀で、キチガイじみた量子化値を使う事はあまりない。	MEncoder Doc 記載なし

--qpstep <integer>　[4]

qp_step=<1-50> (ABR or two pass)　[4]（＊常用4＊）

■まとめ：

　隣接フレーム間でのQPの変動幅、最大値。
　一般論では隣接フレーム間で大幅にQPが変動すると目にうざい。
　MEncoderは当初デフォ2だったが、いつ頃からか4になった。参考元全てが4で揃ったのでデフォルト値にはそれなりの汎用性があるだろう。ただし、万能ではなく、特に覚書（なるP氏）はアニメで8を常用しているようだ。

■参考

覚書（要約）常用8の模様・適用Q値の変化できる、Q値幅。　明るいシーン　→　暗いシーン　などで、大幅なビットレート変化を行ってほしいのであれば増やす。個人的にdefault値4は小さいと考えます。　急激にクォリティが変わると、不自然さが出やすいのかも知れませんが、クォリティが必要ない時に急激に落とすことが可能です。シーンチェンジがはっきりしているアニメならば、急激な変化が出来たほうが便利かも｡	手許 24分アニメにしては毎週ずいぶんIが多い素材、特に短いカットをぽんぽん多用するような、例えばゼーガペインはスパン！と割り込むカット切り替えが気持ちよいのだけれど、そこで前のカットのqpに引きずられるとあれれな事がままあった。当然、後続のP/Bはカット先頭のQP(I)に準拠するのでそのカットはまるまるあれれなままだ。　悩んでいるうちにあれれなまま終わってしまったのだが、そうか、こっちを増やすのだったのか。うん…忘れるなこの痛み。　オープニングやCMは終始動きまくりなケースが多いので、適正値の発見は実験に適した素材を探す事から始める必要がある。　理屈上、これを増やした方が良いのは爆発などの一過性のコマよりも「ハイモーション＆ハイディテイル　⇔　ローモーション＆ローディテイル」の場面転換と思われる。こうした演出はアニメに限らず映像にリズム感を持たせたり、ストーリーの区切り目を強調したい場合に多用されるハズだ。例えば闇階調のゴテゴテした場面だらけの映画でラストだけスカッと青空とか。はいそこで『ブレードランナー』と思った人！例えばそういう、記憶に残るくらいインパクトのある箇所に注意。あとパートカラー（一部白黒、一部総天然色）とか。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） qpstep name="Maximum Quantizer Steps" Recommended： 4 Default： 4 連続したフレームの間でのquantizerの変動幅。画質の急激な変化を抑止。	man MEncoder フレーム間でquantizerが増加/減少し得る範囲の最大値。 (default: 4) （＊以前は default：2だった時期もある＊）
zero1(svn408) Usage: --qpstep <integer> (default=4) [1 - 50] フレーム間で quantizerは変動するが、この値はその変動範囲の最大値を指定する。理論上、値を大きくすると、フレーム間での quantizerの変動幅が大きくなり、短時間のうちに次々に画質が変わる。	MEncoder Doc 記載なし

--ratetol <float>　[1.0]

ratetol=<0.1-100.0> (ABR or two pass)　[1.0]（＊常用4＊）

■まとめ：規格適合性に要注意か？

ABRや2パスでのビットレート変動幅。大きいほど乱高下。
1.0より大きいとファイルサイズが目標値より大きくなり得る。最終ファイルサイズが地味に揃わなくなる。
1.0より小さいとファイルサイズが目標値よりより小さくなり得る。

　2 パスとはいえ、bitrate指定値を使い切らなくても良い場面というのはあり、またそれじゃ全然足りない場面もある。そこをやりくりするのが2パスなのだが、闇雲にあの場面は100kbps、この場面は8000kbpsにしときゃ良いとは限らない。そのへんを「ほどほどに加減」するオプション。
　例えばストリーミングではきっちりどの瞬間も500kbpsでないと困る。ハードウェア再生機でもデコーダバッファメモリには限りがあるし、内部帯域も上限無しとは行かない。

　デフォルト1も手許常用4も規格適合性は不詳。levelによりなにかあるとは思う。規格上は仮想デコーダモデルというものがあり、それを破綻させないようにエンコードしなければならないようだ。
　そのへん全部ぶっとばして画質最優先なら、100。

■参考

覚書（要約）記載無し	手許常用4 番組ごとに地味にサイズが変わる。約25分,2pass, 1024kbpsだとプラマイ5MB程度。光ディスクにキッチリ無駄無く収めたい場合はここは1にしてqpstepなどで調整すべきだろう。 4の根拠はMeGUI Help、およびDoom9 コデックコンテスト2005（3例全て4）。　　しかしながら、全てをぶっとばして100にしたいケースというのもままある。例えば、TV版Zガンダムのオープニング冒頭8秒間。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） ratetol name="Average Bit rate Variance (%)" Recommended： 1.0 to 4.0 Default： 1.0 時間軸に沿ってビットレートがどのように変動し得るかの指定。低い値はビットレート変化を押さえる。映像のストリーミング品質を向上し、コデックが複雑な場面に対応する能力を減らす。高い値はビットレート変化を増やす。複雑な場面への対応能力を向上し、ビデオのストリーミングでの信頼性を減らす。 0% に指定すると、CBRになる。100% では場面の複雑さに応じて激しくビットレートが変化する (完璧な CQP または "quantizer curve compression")。	man MEncoder 平均ビットレートにおける変動幅の許容値。特定の単位は無い。 (default: 1.0)
zero1(svn408) Usage: --ratetol <float> (default=1.0) [0.1 - 100.0] 平均ビットレートにおいてbitrateが逸脱できる範囲（＊allowed deviation、制御偏差？＊）を指定。 1.0より大きくするとファイルサイズが目標値より大きくなり得る。 1.0より小さくすると目標値より小さくなり得る。	MEncoder Doc 記載無し

--ipratio <float>　[1.40]

ip_factor=<value>　[1.4]（＊未試用＊）

■まとめ：素材に応じて調整

zero1氏の記述参照

■参考

覚書（要約）記載なし	手許 Zero1氏の記述はアニメオープニングの他に、CMや、音楽PV、映画の予告編などにも当てはまると思う。つまり、短時間の内に強いインパクトを与える事を狙った映像。一般的に動きもカットも多い。 b_adapt はこうした素材をB使用に適さないフレームと看做してBを控えてPを連発するようだ。I/P/Bの種別は1st passのログに出るのでMacでも掴める。ちょっと大変なので手許ではいちいち弄っていない。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） ipratio name="I-P Quantizer Factor" Recommended： 1.4 Default： 1.4 Iフレーム-Pフレーム間のquantizer換算係数	man MEncoder I-P フレーム間のquantizer換算係数(default: 1.4)
zero1(svn408) Usage: --ipratio <float> (default=1.40) I-Pフレーム間の quantizer換算係数を指定。 1.00でPフレームのquantizerがIと同じになるが、これはお奨め出来ない。bitを無駄にするに等しいからだ。もしあなたのAMV（アニメ(・ミュージック)・ビデオ）がBフレームを生成する傾向が弱ければ、1.40以上を試しても良いだろう。これはPフレームの画質を落とす（程度は--ipratioの値に依る）。しかし、全体的な画質が平均化される。画質がころころ変わったり、ハイモーション・エリアでブロックが出るよりは良いだろう。	MEncoder Doc 記載なし

--pbratio <float>　[1.30]

pb_factor=<value>　[1.3]（＊未試用＊）

■まとめ：素材に応じて調整

zero1氏の記述参照

■参考

覚書（要約）記載なし	手許特に無し。 zero1氏はbrdoを使うなら1.3以上にしても良いのではとしている。しかし手許ではbrdoで浮いた分のbitを少しでも全体的な適用QPを下げる方に回したいのでここは弄っていない。効果のほどは未詳。　なお、自分はXvidのVHQが効果が高かった経験から、RDOと書いてあったら無条件に常用するクセがある。規格上にRDOは無いとBond氏は書いているが、最初に実装したのはJMだとも書いている。ので、盲信。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） pbratio name="P-B Quantizer Factor" Recommended： 1.3 Default： 1.3 Advanced： Pフレーム-Bフレーム間のquantizer換算係数	man MEncoder Pフレーム-Bフレーム間のquantizer換算係数(default: 1.3)。
zero1(svn408) Usage: --pbratio <float> (default=1.30) Pフレーム-Bフレーム間の quantizer換算係数を指定。ここでも、1.00でPフレームのquantizerがBと同じになる。だから-- ipratio も1.00ならI, P, Bのquantizerが全て同じになる。一般的にはBフレームはPフレームよりも圧縮して良い。だから1.3より大きくしたい人もあるだろう。特に--brdo (BフレームのVHQ)を使っている場合は。 I, P, Bのデータはエンコード完了後にコンソールに表示される（＊枚数や平均サイズなど＊）。	MEncoder Doc 記載なし

--chroma-qp-offset <integer>　[0]

chroma_qp_offset=<-12-12>　[0]（＊未試用＊）

■まとめ：弄らない。or 素材に応じて調整。

　輝度と彩度で適用QPに差をつける。実用範囲-2～2。人間の視覚は輝度には敏感だが彩度（色の変化）には鈍感なので、彩度はぐっと省略しても良い。ただし、DVDやTVはもともとこの原理を応用して彩度を間引いてあるから、それをさらに省略してもともと情報量の多い輝度に回しても違いは微妙なものだろう。闇階調や明階調が重要な素材では試す価値がある。端的には白黒映画。
　High Profileになりかつ煩瑣にはなるが、カスタムマトリクスでより緻密な調整ができる。

■参考

覚書（要約）・色部分 (chroma U・V)を輝度部分(LUMA)とQの差を発生させて、エンコする事ができる。　基本的には、差を用意したいのであれば、マトリクス側で行えば用が足りる。　マトリクスをLUMA・CHROMA間で差を用意していないのであれば、このオプションを使ってもいいかもしれない。	手許経験上、白黒映画は最大の敵。特に闇階調に弱いx264は手許の設定では使いものにならない。白黒は完全なグレイスケールでは無く、若干着色されているかフィルムの色がのっているようだが、青系の単色であり、ここにあまり低いQPを使う必要は無いように思う。カスタムマトリクスはJVT以外まったく経験が無いが、これで済むなら済ませたいところ。要検証。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） chroma-qp-offset name="Chroma and Luma Qunatizer Offset"Recommended： 0 Default： 0 彩度情報と輝度情報に異なるquantizer を使う	man MEncoder 彩度情報と輝度情報に異なる量子化値（quantizer）を使う。実用範囲は-2から2。 (default: 0).
zero1(svn408) Usage: --chroma-qp-offset <integer> (default=0) [-12 - 12] 彩度情報と輝度情報に異なる量子化値を使う。これはちょっと面白い。というのは人間の目は彩度変化よりも輝度変化に敏感だという視覚認識のしくみを逆手にとるものだからだ。反面、彩度情報はYV12（＊DVDやテレビが使うYUV4:2:0＊）ではもともと間引かれているので、僅かな輝度画質向上の為に、大量の彩度画質を犠牲にする事になる。	MEncoder Doc 記載無し

-p, --pass <1|2|3>

pass=<1-3> （＊常用2パス＊）

■まとめ：

1パスエンコードでこのオプションを指定する必要はありません。これはマルチパスエンコードの1stパスです。でも害もないです。
マルチパスモードの起動。
pass=1(--pass 1)：エンコードと統計ファイルの作成。
pass=3(--pass 3)：エンコードと統計ファイルのリファイン。要、作成済み統計ファイル。好きな回数だけ繰り返せる。
pass=2(--pass 2)：統計ファイルに基づく最終エンコード。要統計ファイル。
※いずれの段階でも出力ファイルはできる。統計ファイルだけ欲しければ "-o dev/null"。winでは"-o NUL:"（いずれもmencoder）。

3パスが有効なケースは1000フレーム以下の短いもの。他、特殊なケース（不詳）。
なお、PPC Macで3以上のpassを重ねるなら、設定によってはApple-H.264の方が速く済むケースもあり得る。

■参考

覚書（要約）・3の命令が、 statsファイルに上書きする。2の命令はしない。　すなわち2passならば、1→2 　3pass 以上ならば、1→3→3→…→3→ 2　と、実行させる。　50passぐらいまでは、+ 10pass増えるごとに画質が全く違うモノになる。　そこから100passぐらいでは、+20passごとで、変わる感じ。　主に、輪郭などの鮮明さで、差が出てくる。	手許パス数 NTT研究所でも数十パスで1080pを1.8Mビット/秒にできるとしている。 Apple-H.264 パス数指定不能。フロントエンド次第の模様。QTPlayer Proは5程度。 raw2qt264で強制的に2パスでやるとたかが落語で豪快なブロックノイズが出た。動き補償、なかんずくモーションベクトル・サーチ精度に問題か。　現状では、土台のショボさを多段パスで隠蔽したものに過ぎず、なによりあまりにも遅い。心情的には"最先端技術"は誇大広告と言いたいほどだが、4Core x 2クラスが一般的になってくるとasmプログラミングに頼らずとも相当の高速化を果たす公算が高い。設定の簡便さ、狙っても画質破綻を引き起こせない安定性を考えるとx264のアドヴァンテージは必ずしも大きく無い。特に画質に文句を付けている意見は見た事が無く、Bond氏も"rather good"としている。画質に関しては一度はApple-H.264を試して頂きたい。Mac/Win問わずMPEG Streamclipで試せる。　自分の見立てでは、普及度の面でXvidとQT互換H.264、そしてflvの後塵を拝しているx264は、中期的（2～3年）にはむしろ瀬戸際にある。2007年中の進化速度が天王山だろう。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） pass name="Multipass Mode" Recommended： Enabled Default： Disabled マルチパス・レートコントロールをenable	man MEncoder 2または 3パスモードの指定。最適なビットレート配分と全体の画質向上の為には、2か3パスエンコードを推奨。　1 1st パス　2 2nd パス (または2パスエンコード) 　3 Nth パス (3pass エンコードの 2nd と 3rd パス) 理屈と使い方： 1st pass(pass=1) 映像の統計を取ってファイルに書き込む。 CPU負荷の高いオプションは使わなくて良いが、デフォルトでonのものは使う事。 2nd pass(pass=2) stats(＊統計＊)ファイルを読み込み、これを基にビットレート配分をコントロールする。 3pass モードでの2nd("pass=3"。誤字ではない) 上記の両方を行う。最初に統計を読み込み、上書きする。CPU負荷の高いオプションを除き全てのエンコードオプションが使える。 3rd pass(pass=3) 2nd passと同じだが、2nd passの統計を使用する。CPU負荷の高いオプションを含めて、全てのエンコードオプションが使える。 1st pass はABRでも固定quantizerでも良いが、quantizerを推測する必要がないので、ABRの方が望ましい。後続のパスはビットレートを指定するABRでなければならない。
zero1(svn408) Usage: --pass <1\|2\|3> マルチパスモードの起動。 1st と2ndについてはXvidで慣れている人も多いだろう。 "nth pass"というものが増えた。これは、1stパスで統計情報を採り、次の2回目にnth passを走らせるというものだ。結果が気に入らなかったり、ファイルサイズがオーバーしたりしたら、2回目のパスをもう一度実行できる。するとnth passはpass 3を実行する。　 Nth passは一回ごとに統計情報をアップデートしてゆく。 2nd passは単に最終パスを実行するだけで統計をアップデートしない。　 --pass 1 Pass 1は映像分析と統計ファイルの書き出し。 Xvidにおける"2 pass - First pass"だ。デフォルトではmuxできるファイルを書き出す。このパスで bitrateを指定すると1 pass ABRとなる。 --qp 18などを指定すると、概ねXviDの full quality first pass mode同等の見た目のファイルができる。一般的には、この段階で bitrateを指定した方が、2nd 、nth passの結果が良い。 --pass 2 Pass 2はfirst passで得た複雑度の統計に基づいてレートコントロール関係の判断を下し、出力を生成する。Xvidの"2 pass - Second pass"といっしょだ。統計情報の上書きはしない。一般的に2 passはより良い画質とより小さなファイルサイズをもたらす。常時推奨。動作の視覚化は下記参照のこと。 (Pass 1) --pass 1 = 最初の統計収集 (Pass 2) --pass 2 = Pass 1 の統計を使って出力 --pass 3 --pass 3はいくぶん特別だ。これは２回目や３回目のパスという意味では無い。というのは何回でも無限に繰り返せるから。画質が無限に向上するわけでは無いので10パスはちょっと待てという感じ。現実的なメリットがあるのは、 1000フレーム程度より短い素材だけだ。こうした素材ではbitrate配分を最適化する時間が足りない（＊where it doesn't have much time to average the bitrate properly＊）。基本的に--pass 3は--pass 1 と --pass 2の作業を同時に行うが、最初の統計ファイルを作るにはpass 1が必要だ。 --pass 3は、単純に統計ファイルを読んで出力するだけでなく、統計ファイルもアップデートする。従って、nth pass modeを使った3 pass encodeではpass 2よりも精度の高い統計情報が使える事になる。このへんは視覚化すると理解しやすい。ここでpass 2を走らせるとpass 1の統計情報よりリファインされたものが使える。 (Pass 1) --pass 1 = 最初の統計収集 (Pass 2) --pass 3 = Pass 1 の統計を使って出力 + 統計情報のアップデート (Pass 3) --pass 3 = Pass 2 の統計を使って出力 + 統計情報のアップデート	MEncoder Doc 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にそれぞれこんなのを追加して試してみてください。　（＊06年10月改訂前のオプション名＊） 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（以上の）パスが有効なケースがいくつかありますが、上級者向けなのでここでは省きます。

--stats <string>　["x264_2pass.log"]

-passlogfile <filename>（＊常用2パスにつき常用＊）

■まとめ：

特に無し

■参考

覚書（要約）特に無し	手許特に無し
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） stats name="Statistics File Name" Recommended： x264_2pass.log Default： x264_2pass.log 2 pass ログファイル名	man MEncoder 2pass モードで1stパスの情報をデフォルトのdivx2pass.logではなく、<filename>にダンプ。（＊ -x264encoptsでは無く、GENERAL ENCODING OPTIONS。読んでみると地味に不安になるが、x264専用アプリではないので＊）
zero1(svn408) Usage: --stats <string> (default="x264_2pass.log") マルチパスエンコードで使うログファイルの場所と名前を指定。各パスは全て同じログファイルを参照するようにしないと正しく動作しない。	MEncoder Doc 特に無し

--rceq <string>

対応不詳

■まとめ：

Ratecontrol equation ["blurCplx^(1-qComp)"]
レートコントロールの計算式のようだが意味不明。後述のcplxblurとqcomp の関係式のようではある。開発者のチューニングテスト用か？

■参考

覚書（要約）記載無し	手許 mencoderには相当するオプションが無く、弄れない。完成後の.mp4をHexEditで開くとこの式は入っている。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） rceq name="Rate Control Equation" Rate Control 方程式（＊Rate Control Equation＊） Recommended：blurCplx^(1-qComp) Default： blurCplx^(1-qComp)	man MEncoder 対応不詳
zero1(svn408) 記載無し	MEncoder Doc 記載無し

--qcomp <float>　[0.60]

qcomp=<0-1> (ABR or two pass)　[0.6]（＊常用0.6(default)＊）

■まとめ：弄らない or 動体視力に応じて調整

0.0 でCBR（固定bitrate）
1.0 で CQP（固定量子化）※完全なものではなく、ほとんど等価、といったレベルのようだ。
空間軸画質（一時停止したときの奇麗さ）を重視するなら1.0に近づける方が良い。
よりマニアックにはx264cliで--rceqより複雑な式を自分で組めばいいのかと思いますが思ってみただけですすいません。
qp_step(--qpstep)との関係不詳。

■参考

覚書（要約）記載無し	手許【参考】Doom9 コデックコンテスト2005では一切弄っていない。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） qcomp name="Quantizer Curve Compression" Recommended： 0.60 Default： 0.60 QP curve compression: 0.0 = CBR, 1.0 = CQP	man MEncoder quantizer の圧縮。低い数値にするとビットレートの変動幅が低くなる。=画質の変動幅が大きくなる。高い数値にするとquantizerの変動幅が低くなる。=画質の変動幅が小さくなる。 (default: 0.6)。
zero1(svn408) Usage: --qcomp <float> (default=0.60) [0.00 - 1.00] QP curve compression（＊曲線圧縮？＊）低くするほどconstant bitrateに近づく。0.00 でCBR。高くするほどconstant QP に近づく。(＊1.00 でCQP。＊）推奨値はデフォルトの 0.6。特にアニメで0.00 のCBRは絶対に避けるべきだ。レートコントロールの手足を縛り、動きやディテイルの少ない箇所でbitを節約して、動きやディテイルの多い箇所に振り向ける事ができなくなる。	MEncoder Doc : qcompは一定量のビットを"コストのかかる"動きの多いシーンと、"コストの安い"動きの少ないシーンの間でやりとりするものです。極端な例をあげると、qcomp=0で真のconstant（＊固定＊）ビットレートになります。一般的には、これで動きの多いシーンは酷い物になります。一方、動きの少ないシーンはたぶん完璧でしょう。そして必要なビットレートの何倍も無駄にビットを喰っているハズです。反対の極端例。qcomp= 1 はほとんどconstant quantization (QP)（＊画質固定、一定画質など＊）です。 Constant QPでは、画質が悪いということはありません。しかし多くの人は、非常に"コストのかかる"シーンでもっとビットレートを節約して（動きの多い場面では画質劣化はあまり目に留まりませんから）、その分を、画質向上しやすいシーンに回すほうが合理的だと考えています。 qcomp のデフォルトは 0.6 です。これは多くの人の好みよりは若干低いようで、0.7-0.8 を使う人も多いです。

--cplxblur <float>　[20.0]

cplx_blur=<0-999> (two pass only)　[20]（＊未試用＊）

■まとめ：不詳

■ 参考

覚書（要約）記載無し	手許類似オプション ip_factor、pb_factor、qcomp、qp_step などとの違いはstatsを参照する事。特にqp_stepが隣接フレーム間の変動幅であるのに対し、cplx_blurは "Temporal blur"という若干曖昧めな語で説明されている。ちょっと広い範囲を見て口を出す中間管理職みたいな？。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） cplxblur name="Quantizer Fluctuation Reduction (Before)" Recommended： 20.0 Default： 20.0 QPのバラツキを抑止 (curve compressionの前に適用)	man MEncoder curve compression（＊曲線圧縮？＊）の前に、予測されたフレームの複雑さに時間軸ぼかし（＊blur＊）をかける(default:& nbsp; 20)。低い数値にすると必要に応じてquantizer値は急激に変化する。高い数値はなだらかな変化しか許さない。 cplx_blurはIフレームが後続のPフレームに近い画質になる事を保証する。複雑なフレームと単純なフレームが交互にあっても～例えばfpsの低いアニメーションなど～、ころころとquantizerを変えてビットを無駄にしない。
zero1(svn408) Usage: --cplxblur <float> (default=20.0) [0 - 999] --cplxblur は予測されたフレームの複雑さに時間軸のスムーシングをかけるもので、curve compressionの前に、時間軸上でQPがあまりころころ変わらないようにするものだ。この値を低くすると時間軸上のQPの変動幅が大きくなる。高くするとQPの変動幅がなだらかになる。このオプションはtwo passとnth pass モードでしか使えない。統計ファイルを使うからだ。意味が分からなければdefaultの 20.0のままにしておく事。	MEncoder Doc 記載無し

--qblur <float>　[0.5]

qblur=<0-99> (two pass only)　[0.5]（＊未試用＊）

■まとめ：不詳

■ 参考

覚書（要約）記載なし	手許これも"Temporal blur"。cplx_blurとの違いは：１） curve compressionの前か後か。　・curve compressionの意味不詳２）ぼかす対象　・これは「量子化値」。cplx_blurは「予測されたフレームの複雑さ」
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） qblur name="Quantizer Fluctuation Reduction (After)" Recommended： 0.5 Default： 0.5 QPのバラツキを抑止 (curve compressionの後に適用)	man MEncoder curve compressionの後に、フレームの複雑さを見積もって量子化パラメータに時間軸ぼかしをかける (default: 0.5)。低い数値にすると、必要に応じてquantizer値は急激に変化する。高い数値はなだらかな変化しか許さない。 cplx_blur も参照。
zero1(svn408) Usage: ---qblur <float> (default=0.5) [0 - 99] --cplxblur 同様。違いは時間軸ぼかしをquantisation paramater (QP)にかける事。ここでも、値を低くすると時間軸上のQPの変動幅が大きくなる。高くするとQPの変動幅がなだらかになる。これも一般的には弄る必要は無いが、ここには実験に意味を見いだす人があるだろう。（＊原文はある掲示版の常連を対象にしている＊）	MEncoder Doc 記載なし

--zones <zone0>/<zone1>/...

zones=<zone0>/<zone1>[/...]]（＊未試用＊）

■まとめ：素材に応じて調整

特定範囲のレートコントロール調整。bitrateかqpで指定。映画の冒頭や末尾のタイトルロールなどで使うようだ。

■参考

覚書（要約） --qpmin,--qpmaxは、--zonesや-q・-Bで指定した数値よりも優先されます。	手許特に無し
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） zones name="Define Zones" Recommended： Disabled Default： Disabled 映像のビットレート配分を部分的に調節	man MEncoder 特定部分(エンディングやクレジットなど)を指定した画質調節。指定書式は以下の通り。　 <start-frame>,<end-frame>,<option> 　上記の<option>では以下が指定できる。　q=<0-51> 　　quantizer 　b=<0.01-100.0> 　　ビットレート乗数　 NOTE: ここで指定したquantizer値は厳格に強制されるわけではない。レートコントロールの計画段階に影響するだけで、オーバーフロウ補償や qp_min/qp_maxの適用対象から外れる事は無い。
zero1(svn408) Usage: --zones <zone0>/<zone1>/... (default=off) [b=0.01 - 100.0, q=0 - 51] Zonesを使うと映像の特定箇所でbitrateかquantizerの指定値を乗っ取る事ができます。指定書式は以下の通り　Start frame, End frame, Option 上記のOptionはq=<integer> (forced QP) または b=<float> (bitrate multiplier)を指定します。 zone指定を続けて書く際は前に "/" を書きます。例：　 --zones 200,900,b=0.50/1000,1200,b=2.0 　これでフレーム番号200-900までは指定した平均bitrateのおおむね半分に、1000-1200までは指定した平均bitrateの倍となります。	MEncoder Doc 記載無し

--qpfile <string>

対応不詳

■まとめ：

x264cliの記述は"Force frametypes and QPs"。
恐らくI/P/Bの種別と適用QPを強制するもので、様々な映像に使って適正フレームタイプやQP値を検証する目的のオプションと思われる。

■参考

覚書（要約）記載無し	手許特に無し
MeGUI2.0 Help（ContextHelp v0.2 06/01/01）記載無し	man MEncoder 対応不詳
zero1(svn408) 記載無し	MEncoder Doc 記載なし

[ 2006/12/08 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(0)

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)

3.2. Analysis options_deadzone関連

概説

　2006/10月前半に追加された比較的新しいオプション。詳細不詳。

Doom9 Explanation for new switches in x264
#4 IgorC

--deadzone：高bitrate でディテイルレベル向上。ノイズ、フィルムグレイン、など。
#10 AlexW（x264 contributor）

IgorC が言ったように、--deadzoneは中～高bitrate領域での精細なディテイルやフィルムグレインを向上させる。
まず--deadzone-intra の調整から始めるのをお奨めする。違いの大半はここで発生するみたいだから。--deadzone-intra のデフォルト値は11だが、いくぶん0に近い方がややディテイルが残るようだ。CQMと一緒に使うとなお良いハズ。
#23 akupenguin（x264 author）

理論上、lambdaを改造すればtrellisにもdeadzoneが使える。でも実装はまだ。
#10 AlexW（x264 contributor）

まだちゃんとテストしてないが、速度低下は最小限のハズだ。
#27 akupenguin（x264 author）

Deadzoneはquality-per-qp （*1）に影響する。理想的なデブロック強度はqualityに依るが、現実のデブロック強度（規格上の定義によるもの、およびx264オプションで指定するもの）はQPと相関関係にある。qualityでは無い。
だからもしquality-per-qpを調節すれば、デブロックの設定も変えたいケースがあるだろう。しかしながら、デブロック設定の単位は極めて粗いので、deadzoneを最低値の0まで下げた場合でも（推奨しない）、対応するデブロック補正はせいぜい-1に止めるべきだろう（default deadzoneの時に使っていたデブロック強度に対して-1）。反対にdeadzoneを最大値の32まで上げるなら、適切なデブロックはせいぜい+ 1。
　
適切なdeadzoneとbitrateとの間に特定の関係は無い。Deadzoneは常にrate- distorion optimal value（*2）と相関関係にあるので、いかなる変化もサイコビジュアル（*3）なもので、まだ断定的な推奨値を書けるほどテストされていない。

　上記スレには高bitrateってどのくらいなのだという議論もあるが、もともと一概には言いにくい上に、SDとHDが入り交じる現在ではさらにやっかいだ。H.264/AVCに対応したBPP表が必要と思われる。

*1） quality-per-qp：どうやら主観画質/QPのようだ。PSNR/QPやSSIM/QPといった感じではない。
*2） RDO、なんの？QP全体に股がるRDOあったっけ？
*3）人間の視覚認識のしくみを逆手にとったもの

総務省　情報通信審議会情報通信技術分科会（第４２回）資料４２−１−２　ＣＳデジタル放送高度化委員会報告　本体（ 6P）
3.2 量子化
直交変換された信号を量子化して情報量を削減するが、H.264 | MPEG-4 AVC では、小さい成分を強制的に0に丸める領域(デッド・ゾーン)のない量子化処理をインター予測においても行っている。

　デッドゾーンがあるんだかないんだかよくわかりませんが、とりあえずデッドゾーンというのは細かいディテイルを端折る処理のようです。インターにおいてもっていうんだからイントラにもあるのでしょうね。たぶん。

Analysisオプション _deadzone関連

x264cli (rev600準拠)	MEncoder -x264encopts (dev-SVN-r20806 準拠)

--deadzone-inter <int>　[21]

deadzone_inter=< 0-32> 　[21]（＊未試用＊）

■ まとめ：不詳、次項参照

Set the size of the inter luma quantization deadzone [21]
インター（フレーム間）輝度量子化のデッドゾーンのサイズ指定。

trellis とバッティングの可能性有り？

■参考

覚書（要約）次項参照	手許次項参照
MeGUI2.0 Help（ContextHelp v0.2 06/01/01）記載無し	man MEncoder Set the size of the inter luma quantization deadzone for non- trellis quantization (default: 21). 　非trellis 量子化における、インター（フレーム間）輝度量子化のデッドゾーンのサイズ指定(default: 21)。
zero1(svn408) 記載無し	MEncoder Doc 記載無し

--deadzone-intra <int>　[11]

deadzone_intra=< 0-32>　[11]（＊未試用＊）

■ まとめ：不詳

Set the size of the intra luma quantization deadzone [11]
Deadzones should be in the range 0 - 32.
イントラ（フレーム内）輝度量子化のデッドゾーンのサイズ指定(default: 11)。範囲0-32。

trellisとバッティングの可能性有り？

■参考

覚書（要約）・デッドゾーンなインター・イントラLUMAのQ値ってなんだろうね。　━━━うーん、多分。デッドゾーンって、フレームスキップしてるときの事 …かな。　フレームスキップは、P・Bフレームで起こる。intraは、P・Bフレーム向けなマトリクスだ。　つまり。フレームスキップが起こっている場所を、スキップ数減らさないで質を上げるには、　この数値を減らす必要が出てくる …だろうと考えられる。　逆に。さらに、ビットレートケチるなら、数値を大きくする。　　試した所、想像した感じの効果が得られた。　アニメでのBフレームは、ほとんどがスキップされる対象なので、　- -deadzone-intraを減らすと、質が上がる感じを受けた。…ただし、容量は莫迦増える。　逆に、数値を増やすと、Bフレーム時の動きが皆無的になり、カクつくシーンが発生する。　増やす用途で得をするようには、どうも思えない。　B フレームスキップを擬似的に無しにする為に、　--deadzone-intra の数値を減らして使うのが、このオプションの意味なのかもしれない。	手許　覚書（なるP氏）の検証結果は冒頭、AlexW（x264 contributor）の発言と整合する。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01）記載無し	man MEncoder Set the size of the intra luma quantization deadzone for non- trellis quantization (default: 11). 　非trellis 量子化における、イントラ（フレーム内）輝度量子化のデッドゾーンのサイズ指定(default: 11)。
zero1(svn408) 記載無し	MEncoder Doc 記載無し

[ 2006/12/10 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(0)

Avidemux2.3

【知った場所】Doom9.org
【入　手　先】Avidemux

　Linuxの MPEGStreamclipのようなもの。GUIで動画編集、各種エンコード、各種コンテナ書き出し、音声変換同時。
　Mac OSXではX11（システムディスクに入ってる）がインストールしてあれば動く。とりあえずゴテゴテとオプションを付けてx264+mp2.mp4を作って見たところ、VLC/MPLayer(cli)ともクラッシュした。

　と、いう段階で書くのもアレだが。
　x264 のコマンドはほぼ網羅している。主要なところではdirect_pred（--direct）にautoが無いくらいだろうか。デフォルト設定はギンギンのHigh Profile。書き出し形式にmp4もあり、インタレ解除やデノイズ、色調整なども効果を確認しながらできるようで、プリセットとして保存できる。フィルタの数はMEncoderほど多くは無いが、MEncoderだって全部が全部有用なわけでなし。主要なものは移植されている。独自フィルタの中にはPAL専用ながらフィールドシフトインタレ解除もある。

　なによりGUI。
　

　Enlightenment 入れてるからちょっとアレだけどこれでもTiger。通常のx11との違いはウィンドウ枠だけのハズだ。

Doom9： 12/7のNews
Avidemux 2.3 - 代替コンテナ等が扱えるVirtualdub。MOV, MP4コンテナ内のDVコンテントをサポート。概ね最新版のx264をを内蔵しており、いくつかのバグが修正された。

以下太字オレ

Avidemuxのサイト：2006-12-02: 2.3 Final
2.3 Finalを公開しました。

修正済みバグリスト：
Fixed make install for po directory
Fixed Ffv1rec
Fix for multiple gthread_init call (aakef)
Better audio dithering (Mihail+Josh Green)
Support for DV in .mov/.mp4
Resample crash fix when upsampling (a nasty one).
PCM in .mov/.mp4 sample size fix
Fix for MP4/MOV files containing .url field
Added smartcopy from cli or from javascript
x264のmp4出力でBフレームの参照化を使うとバグがあったのを修正。
For non Linux users:
preview2/MacOsX の新しいスナップショットが出来た。Preview 2cだ。Kuisathaveratの修正によりより多くのMacOsX versionで動くようになった。ありがとうKuisathaverat！

For win32 users：
アップデートすべきなのはzipファイルだけだ。最初に2.3.0 zip fileをインストールして次にその中身をx264_update fileで上書きして欲しい。

svn版 x264にアップデートしても大丈夫。avidemuxのx264はコンパチだ。しかしwin32 versionではgtkに基づく制限があるから注意して欲しい。非ascii characterのdirectory/filenameを使うと問題が有る。

version2.3はまだ続く。2.4でも同じコアを使っているので、そこからのバグフィクスを使えるからだ。

2.4 は2.3と同じだが、ユーザーインタフェイスが３種類ある。GTK, 無し（x11不要のcliモード）、そしてQT4だ。cli版は既に使う事が出来る（＊useable、有用だ。かも＊）。GTKは2.3と変わらない。しかしQT4版は、まぁ、初期段階だ。
（＊以下不詳＊）I hope jakub will stand the way QT does layout compared to GTK, which is not brilliant at the moment (and yes, designer is less efficient than glade).

おそらくはこれが今年最後のバージョンになるだろう。

　コマンドラインでも使える筈なので、プリプロセスをこいつに任せてmkfifoでx264cliに繋ぐ、とかできっかもしんねぇ。去年もそんな事言ってたような気がするけども。

[ 2006/12/10 00:30 ] 動画　動画全般 | TB(0) | CM(0)

3.3. Analysis options_カスタム量子化マトリクス関連

概説

　この項はx264cliとMEncoderで大幅に分類方針が異なる為、体裁が異なります。内容は覚書（要約）、zero1(svn408)、man MEncoderのミックスです。

Encoding H.264 using the x264 Command Line Interface：CQMの前フリから
　CQMとは、Custom Quantisation Matrix (または Matrices、カスタム量子化マトリクス)の省略形です。量子化マトリクスは格子状に配置された数字（＊数列、行列＊）からなり、それぞれの数字は quantum（＊量子＊）と呼ばれます。これは、これらの数字がどのくらい画像を劣化させるかを決めるという事です。
　大きなquantumで構成された数列ほど映像をソフトにします。小さなquantumで構成された数列ほどディテイルが残ります。x264のデフォルトは、"flat 16" マトリクスです。全てのquantumは16で、特別なデコードは一切必要ありません。これとは別に、カスタム量子化マトリクス機能はHigh Profileの機能で、実際のデコードに必要なリソースは全く変わらないにも関わらず、デコーダ側にそれ専用のサポートが必要になります(*1)。
　Xvidのカスタムマトリクスでは、ほとんどデフォルトのH.263量子化形式で問題はありませんでした(*2)。x264でも flat 16で多くのケースで問題はないと思わますが、中には、高周波係数領域（＊high frequency co-efficient area＊）を大きなquantumで埋めたマトリクスで精細なディテイルを僅かにぼかし、圧縮しやすくしたい事があるかもしれません。

　理想的なCQMを定義するためには様々な方法があります。利用可能なオプションは以下の通り：

*1）他にもMain Profileは規格制定を急いだフシがあり、積み残しが多い印象がある。
*2）手許では、Xvidの quant_type=mpegは、闇階調ブロックノイズの削減に段違いの効果があった。

Analysis オプション _カスタム量子化マトリクス関連

x264cli			MEncoder -x264encopts	メモ（＊常用jvt 、HP、QT7非互換＊）
--cqm <string> デフォルトのflatマトリクスか内蔵のJVTマトリクスを選択する（JVTマトリクスはH.264規格策定のパートナーであるJoint Video Teamが作った）。マトリクスはx264.exeに内蔵されているのでCQMの使い方としては全く簡単だ。外部ファイル要らないから。			cqm=<flat\|jvt\|<filename>> 事前に定義済みのカスタム量子化(quantization)マトリクスか、JMフォーマットのマトリクスファイルを使う。　flat 　　事前に定義済みのflat 16 matrixを使う (default)。　jvt 　　事前に定義済みの JVT matrixを使う。　<filename> 　　JMフォーマットのmatrixファイルを使う NOTE: Windows のCMD.EXEユーザは、全てのCQMリストを使おうとする場合、コマンドラインの構文解析で問題が起こり得る。これはコマンドラインに最大長制限があるため。そうした場合、リストをJMフォーマットCQMファイルに入れて上記の設定でロードする事を推奨。	なんとなくJVT常用。 Xvidでquant_type=mpegに変えた時はうわなにこれスゲェって感じだったが、そこまでの違いは感じなかった。それでも闇階調の"フレームごとにぱたぱたと変わる"ブロックノイズ削減に若干の効果がある。外部ファイル下記にいくつか公開されている。 Doom9： collection of available AVC custom quant matrices Bond 氏によるとJVTはcomparable to the "mpeg" matrix of mpeg-4 aspとの事。ならば横幅640以上ではせめてJVTはマストだと思う。外部ファイルの作成 MeGUIは "MEncoder GUI" だが、ffmpegXと同様、様々なツールが詰まっているようだ。こうしたエンコード・スイートにはマトリクスエディタが付属している事がある。 MEncoder 本体の機能にカスタムマトリクスエディタは見当たらないので、テキストエディタか。
--cqmfile <string> カスタムマトリクスを使いたければ、このオプションが他よりは実用的だろう。このオプションで外部マトリクスファイルを読み込める。読み込めるのはJM互換形式（JMはレファレンスエンコーダ）。Doom9に外部マトリクスのリストがある。他の全ての--cqm関連オプションに優先。
--cqm4 <list> 全ての4x4量子化マトリクスの指定。入力はカンマ区切りの16個の整数でなければならない。このオプションは実験には良いかもしれないが、コマンドラインがひどく長くなる。特に他の量子化マトリクスも指定するなら尚更だ。	--cqm4i 輝度と彩度	--cqm4iy 個別設定	cqm4iy=<list> (also see cqm) 4x4イントラ輝度。コンマ区切り整数16個、各数値の範囲は1-255。
	--cqm4i 輝度と彩度	--cqm4ic 個別設定	cqm4ic=<list> (also see cqm) 4x4イントラ彩度。コンマ区切り整数16個、各数値の範囲は1-255。
	--cqm4p 輝度と彩度	--cqm4py 個別設定	cqm4py=<list> (also see cqm) 4x4インター輝度。コンマ区切り整数16個、各数値の範囲は1-255。
	--cqm4p 輝度と彩度	--cqm4pc 個別設定	cqm4pc=<list> (also see cqm) 4x4インター彩度。コンマ区切り整数16個、各数値の範囲は1-255。
--cqm8 <list> 全ての8x8 量子化マトリクスの指定。入力はカンマ区切りの64個の整数でなければならない。ほか、前項に同じ。	--cqm8i 輝度と彩度	-	cqm8iy=<list> (also see cqm) 8x8イントラ輝度。コンマ区切り整数64個、各数値の範囲は1-255。
	--cqm8i 輝度と彩度	-	-	cqm8ic がないのは入力がYUV4:2:0限定だから？
	--cqm8p 輝度と彩度	-	cqm8py=<list> (also see cqm) 8x8インター輝度。コンマ区切り整数16個、各数値の範囲は1-255。
	--cqm8p 輝度と彩度	-	-	cqm8pc がないのは入力がYUV4:2:0限定だから？

　自分でカスタムマトリクスを作ろうという人は、『アニメエンコで役に立つかもしれない覚書」の06-03E　カスタムマトリクスにて解説されています。

余談：

いまさらアレなんだけどぶっちゃけx264って使い物になんねぇと思う事があります。闇階調のブロックノイズを目にする事がXvidに比べて多過ぎ。これを解決する手法が素材種別に応じたカスタムマトリクスを探して使い分ける他に無いのなら、それは退化です。
　それでなくとも実際のアプリケーション（利用用途）がXvidとほぼ競合する以上「画質が良い」だけでは死亡フラグ確定。JPEG2000とかSACDとかD-VHSとかDATとか。開発初期段階にあるものに実用上の文句を言っても仕方がありませんが、ポテンシャルが高いだけに惜しい。Xvidよりキレイに、Apple-H.264より速くできる事は確かですが、やれる事多すぎて却って使い勝手が悪い事も確か。進化の袋小路な印象もあります。

　・・・という感じなので、当面手許ではcqm=jvt固定、オプションでなんとかする方向で行きますが、白黒映画だけはカスタム量子化に手を出すかもしれません。

[ 2006/12/11 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(0)

3.4. Analysis options_マクロブロック単位QP変更（Sharktooth版固有）

概説

x264のレートコントロールの性質概要
　H.264 はマクロブロック単位でQPを変える事ができるが、x264では採用していない。QPはフレーム単位だ。1フレーム内部の全マクロブロックに単一のQP値を使う。
　
　※ 画質的にはマクロブロック単位 QPのほうが有利と思われる。例えば画面右半分が静止画像、左半分が激しく動く場面など。この差はHDTVで効いて来ると思う。反面、実装は地獄じゃろうねぇ。

　上記はソースコード内の付属文書。Encoding H.264 using the x264 Command Line Interface（Zero1氏）にこれと矛盾する妙なオプションがあった。どうもマクロブロック単位QP変更を前提にしたオプションに見えたのだが、手許では見た記憶が無くtracで検索しても過去に存在した形跡も無い。覚書（なるP氏）の掲示版にて当該オプションに覚えが有る人がいないか聞いてみたところ、、、、

　どうも Sharktooth 版のみ、マクロブロック単位QP変更ができるらしい。
　muken氏によると、

Sharktooth氏(Doom9's forum)のビルドでは、rev602でエラーを吐かない（オプション指定を認識したというだけで実装を確認したわけではない）
bob0r氏(Jarod), celtic_druid氏, clef氏(icl版), seraphy氏, Sylphide氏(Lunatilia)のビルドではこのオプションを指定するとunknown option
http://mirror05.x264.nl/Sharktooth/から<dir>のx264に入り、 docsとpatchesを取得できる。

との事です。Zero1氏の記述によるとあまり大規模なものではなく、大きな青いエリアにブロックノイズが出たら弄れとしています。

Analysis オプション：Sharktooth版固有の機能

x264cli (rev600準拠)	MEncoder -x264encopts (dev-SVN-r20806 準拠)

--aq-strength　[0.0]

対応無し　[]

■ まとめ：

特に無し

■ 参考

覚書（要約）記載無し	手許 Haaliが何/誰なのか自分は知らないです。タマに妖精現実さんとこで見るけど。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01）記載無し	man MEncoder 記載無し
zero1(svn408) Usage: --aq-strength <float> (default=0.0) 適応的量子化の設定の一つ。適応的量子化は特定フレームの内の一部に異なった量子化値を使えるようにするもの。通常はフレーム全体が同一の量子化値を使う。Xvidでは明るい部分や暗い部分を高圧縮にしてより目立つ部分にbitを回す事ができたが（＊サイコビジュアル・エンハンスメント＊）、それに相当する。適応的量子化はx264ではやや挙動が異なる。というのは大きな青いエリアでブロックが出るという問題に対処する為にHaaliが追加したものだからだ。 x264 の適応的量子化は暗いエリアや青いエリアに回すbitを増やしてこれらのブロックノイズを緩和するものだ。この設定は、QP per Macroblockの調整。 0.0で適応的量子化オフ。 1.1 はかなり強いとされる。他の部分が問題無いにも関わらず、青いエリアがブロッキーだった時に調整するのがお奨めの使い方だ。	MEncoder Doc 記載無し

--aq-sensitivity　[15.0]

対応無し　[]

■ まとめ：

特に無し

■参考

覚書（要約）記載無し	手許特に無し
MeGUI2.0 Help（ContextHelp v0.2 06/01/01）記載無し	man MEncoder 記載無し
zero1(svn408) Usage: --aq-sensitivity <float> (default=15.0) --aq-strengthと一緒に使う。--aq-strengthが0.0か、未指定の時はなんの動作もしない（デフォルトはdisableだから）。このオプションでは適応的量子化の際の "flatness"閾値を指定する。5でほとんど全てのブロックに適応的量子化をかける。22でフラットなブロックだけに適用。ここでフラットなブロックとは、単色か、ほとんどディテイルの無いブロックを指す。	MEncoder Doc 記載無し

[ 2006/12/11 00:30 ] ごみ箱　-x264encopts | TB(0) | CM(1)

4. Video Usability Info (Annex E):

概説

Video Usability Info (Annex E):

	The VUI settings are not used by the encoder but are merely suggestions to

	the playback equipment. See doc/vui.txt for details. Use at your own risk.

"VUI 設定はエンコーダが使うものではなく、再生設備に対する付加情報に過ぎない。詳細はdoc/vui.txt参照。自己責任で使う事。"
doc/vui.txtを試訳してみたところ、やはりデコーダ向けの参考情報で生成データをどうこうするものではない。使いこなすにはTVやカラープロファイルなどの"しくみ"に精通している必要がありそうだ。
　例えばこれらを使って暗部のブロックノイズが潰せたとしても、原理的には暗部のブロックノイズをモニタの輝度調整で潰すに近い。効果は視聴環境（部屋の明るさ、TVに出す場合は画質プリセットの選択）により大きく変わる。これらはそうした微調整の自動化で、視聴環境（デコーダ、再生機器、モニタの種別）のサポート次第だ。
　x264cliがこれらをサポートする理由は、規格にあるからという事もあろうが、特に北米ではTV出力する据え置き型Divx/MP4プレイヤが盛んな事もあるだろう。

　手許ではこれらの設定に頼らず、生成データのレベルでなんとかする方向（てゆうかMEncoderの対応オプション探してないだけとも言う）。

　man MEncoder、MEncoder Doc、MeGUI2.0 Help（ContextHelp v0.2 06/01/01）には記載未発見。

Video Usability Info (Annex E)オプション

x264cli (rev600準拠)	MEncoder -x264encopts (dev-SVN-r20806 準拠)

--overscan <string>　[undef]

対応不詳

■ まとめ：

Specify crop overscan setting ["undef"]
- undef, show, crop

■ 参考

VUI Guide: これは何？
一般的に"オーバースキャン"という用語は映像の内、情報を含まないが、特定の解像度やアスペクト比を維持するために付加された領域の全てを表します。従って「レターボックス化」された映像には上下に"オーバースキャン"が付いています。
しかし、このオプションが扱う"オーバースキャン"は意味が異なります。またアナログ信号をデジタル化する過程で付加される"オーバースキャン"でもありません。
ここで言う"オーバースキャン"とは、ディスプレイ上で映像の一部分だけを表示させるという意味です。"どの一部分"なのかはディスプレイに拠ります。
　
使い方
ディスプレイがオーバースキャン・プロセスを使う際に映像のどの部分が表示されるか、私には正確なところが解りませんので、ここで方法や例示を書くことができません。
"overscan=show"が安全であろうかと思います。というのはこれは常に映像全体を表示する信号だからです。
"overscan =crop"は影響が確実に解っている場合にのみ使って下さい。
またデフォルトの"undefined"も使って大丈夫です。
　; このオプションは使った方がよいですか？
正確に理解している場合に限って、はい。
一般的な意味での"オーバースキャン"がある映像ストリームには使わないで下さい。その場合はエンコード前に黒帯をクロップして高ビットレート/高画質を狙って下さい。さらにH.264規格には"overscan=show"の設定が優先されるとありますが、"overscan=crop"の設定は無視される事があり得る、ともあります。実際、多くの再生機器（※equipment、ソフトも含むか？）ではこの設定を無視して映像全体を表示します。

手許: 『改訂版H.264/AVC教科書』の索引に「クロッピング処理」なる記述があった。デコード後、画面に表示する前に出力する画像の形態に合わせて上下左右の画素を切り出す処理、との事。

同書p183に以下の文言有り。"例えばHDTVの場合、走査線の数は1080本です。これに対してH.264/AVCでは垂直、水平方向とも16画素の倍数でないと符号化できません（1080本は16の倍数ではない）。例えば、1088本（16の倍数）を符号化した場合、8ラインを捨てて表示する必要がありますが、この場合、クロッピング処理によって、ビットストリーム中でどの上下8ラインを捨てるのかを明示的に指定する事ができます。"

特にインタレ保持をテレビに出す場合、対象機器のデコーダの性能によっては、考慮しても良さそうだ。

zero1(svn408): Usage: --overscan <string> (default=undef) [undef, show, crop]; 　編集ガイドや再生ガイドにも書いてありますが（＊x264以外のガイドもたくさんある＊）、TVは映像を全部表示しているわけではありません。10～ 20%ばかりはロス（＊表示されない領域＊）があります。これはブラウン管（＊tube＊）を有効活用するために、スクリーンにブランクスペースが出ないようにするためです。; 　NTSCの走査線は525ラインありますが、そのうち実際の映像を含んでいるのは大体 486ラインです。もしoverscanがなかったら、TVは525ラインを全部表示するでしょう。これはつまり、上下に黒帯が出ると言う事です。映像の両サイドにも普通はブランクデータがあります。実データの横幅が704-711"pixels"のDVDでは一般的に、横幅を720ピクセルにするべく黒帯が付加されます（これがMPEG-2の横幅が16の倍数でなければならない理由です）。; 　さてそれでは、映像データにoverscanがなかったらどうなるでしょうか？事実上Cropされたかのように表示されます（overscanのために、データはあっても表示されない）。ここが--overscanオプションの使い道です。; 　"--overscan show"でズームアウトして映像全体表示。; 　"--overscan crop"で通常通り端っこを切り落として表示。; 　この設定はハードウェア側の対応が必要です（ソフトの場合も必要ですが、どのみちPCモニタにoverscanはありません）。この機能を実装していない再生機器の場合、--overscan設定は無視。なにを設定していようとcrop表示になります。

--videoformat <string>　[undef]

対応不詳

■ まとめ：

Specify video format ["undef"]
- component, pal, ntsc, secam, mac, undef

■ 参考

VUI Guide: これは何？; 純粋に参考的な（※informative）設定。デジタル化される前のアナログ映像のタイプを示す。; 　; 使い方; NTSCやPALなど、好みの値を入れるだけ。; MPEG2 からトランスコードする場合、素材のm2vビットストリームの中にこの値が見つかるかもしれない。（詳細は ITU-T Rec. H262 / ISO/IEC 13818-2参照。）; 　; このオプションは使った方がよいですか？; これは完全にあなた次第です。; この設定が何かに影響を及ぼすと言う事は考えられません。私は純粋な付加情報に過ぎないと考えています。

手許: 地アナTVキャプチャなので入れるとすればntsc。

zero1(svn408): Usage: --videoformat <string> (default=undef) [component, pal, ntsc, secam, mac, undef]; ただの参考情報の（※ informative）設定。ファイルに付けるメタデータに似ている。ソースの種類を指定できる。ただの付加情報なので再生にもエンコードにも全く影響しない。

--fullrange <string>　[off]

対応不詳

■ まとめ：

Specify full range samples setting ["off"]
- off, on

■ 参考

VUI Guide: これは何？
アナログ映像のデジタル化に関わるもう一つの遺物。
アナログ映像をデジタル化する際、輝度と彩度のレベルがそれぞれ16..235 と 16..240の範囲に制限されます。
通常、再生機器（※ equipment、ソフトも含むか？）は全てのデジタル化されたサンプルがこの範囲内にあると想定しています。
しかしながら、大半のDVDでは輝度も彩度も0..255のフルレンジを使っています。
こうしたDVDをそのような再生機器にかけた場合、オーバーサチュレーションが起きる可能性があります。
これを避ける為にはレンジ補正が必要となります。
使い方
素材がデジタル化されたアナログビデオ/TV放送なら、取り込み時にレンジが限定されている可能性が非常に高いです。
限定されている事が確実なら、--fullrangeはoffのままで安全です。
確実でない場合や、オーバーサチュレーション抜きで再生できているか確認したい場合は、onにしてみましょう。
x264のデフォルトはoff である事に注意して下さい。これは"安全"ではありません。
このオプションは使った方がよいですか？
はい。
しかし、このオプションを理解できるデコーダ/メディアプレイヤはごく少数です。

手許: 地アナMPEG2キャプチャでどうなってるか不明。念のためCMカットの段階でレンジ変換してやるべきかも知れない。; --fullrange onにするとTVに持って行っても大丈夫そうではある。

zero1(svn408): Usage: --fullrange <string> (default=off) [on, off]; これもTVを主眼とする設定。TVは輝度レンジ16-235、彩度レンジ16-240を想定している。これはTVで見る限りは大丈夫だが、PCモニタでは黒がダークグレイに、白はライトグレイになってしまう。PCモニタで見る場合は、AVISynthでレベルを調整しても良い。こうした事を知らなくても、素材映像が16-235にならないような調整をしている場合もある（例えば、pure black, pure white, or pure saturated coloursを使っている場合）。; これに加え、DVDの中には0-255のフルレンジを使ったものもある。ならばTVで0-255のフルレンジを使っても問題は無いのではないかという気もするが、これは規格上正しく無い。オーバーサチュレーションが起きる。; "--fullrange on"は再生時のレンジ補正（0-255 to 16-235）。これでTVに映しても大丈夫（H.264デコード対応プレイヤの場合）。; PC モニタは0-255（以上）を表示できるので、ソフトウェアプレイヤはこの設定を無視する傾向にある。レンジ補正無し、そのまま0-255で出力。だから onでどちらで表示しても問題無い。; "--fullrange off"を使っても平気なのは素材映像のレンジが16-235の時だけです。

--colorprim <string>　[undef]

対応不詳

■ まとめ：

Specify color primaries ["undef"]
- undef, bt709, bt470m, bt470bg
smpte170m, smpte240m, film

■ 参考

覚書（要約）次項参照	手許次項参照
VUI Guide 次項参照
zero1(svn408) 記載無し

--transfer <string>　[undef]

対応不詳

■ まとめ：

Specify transfer characteristics ["undef"]
- undef, bt709, bt470m, bt470bg, linear,
log100, log316, smpte170m, smpte240m

■ 参考

覚書（要約）詳細不詳だが、カラーマトリクスは、コレを使ってますよと、宣言するのに--transferを使う。　使うと暗部のブロックノイズが軽減される傾向。　 ------------------------------------------------------------- Rec709 (bt709)　　→　720p(PAL型HDTV風味?)的なカラーマトリクス smpte240　　　　　 →　1080i(NTSC型HDTV風味?)的なカラーマトリクス Rec601(bt601)　　& amp; amp; rarr;　480i,480p的なカラーマトリクス smpte170　　　　　→　コンポジットNTSC (SDTV)的なカラーマトリクス Rec470(bt470)　　→　PAL(SDTV)的なカラーマトリクス　　 ∴Rec709≒smpte240m　,　Rec601≒smpte170　…厳密には違うので悪しからず。 ------------------------------------------------------------- bt709, smpte240m, smpte170m。この三つから選ぶといい印象。	手許闇階調ブロックノイズは生成データのレベルでなんとかしたい。
VUI Guide 5. Color Primaries, Transfer Characteristics, Matrix Coefficients これは何？映像マニア（※videophile）の設定。平均的なユーザにとって必要なものでは、ぜんぜんないです。　全てのモニタが全ての色を同じように表示するわけではありません。同じ映像を別モデルのモニタ２個で見比べるとどちらか片方が"青っぽく"、もう片方は"緑っぽく"見える事でしょう。結論から言うと、モニタはモデル毎に異なったカラープロファイルを持っています。これは全てのモニタで映像がだいたい同じに見えるように色を補正するためのものです。プリンタやフィルム/ビデオ・デジタイザなども同様です。デジタイザ機器のカラープロファイルが解っていれば、デジタイザ機器を使っていようがいまいがデコード後のh264ストリームの色やガンマを補正する事が出来ます。　使い方自分のデジタイザ機器の特性を見つける事ができれば（see the equipment documentation or make reference measurements）、概ね見合った特性をH264 Annex Eの特性リストから探してx264に渡す事ができます。または、デフォルト (unspecified)のままほっとくか。 MPEG2 からトランスコードの場合、m2v bitstreamの中にこのオプションのための値が書いてあるかもしれません。（詳細はITU-T Rec. H262 / ISO/IEC 13818-2参照）　このオプションは使った方がよいですか？自分が何をしているかキッチリ理解している場合に限って、はい。このオプションを使うのは悪い考えではありませんが、デフォルトの設定は間違ったものよりマシです。残念な事に私はcolor/gamma/color matrix補正に対応したデコーダ/メディアプレイヤを、それを試みようとするものさえ、見た事がありません。
zero1(svn408) 記載無し

--colormatrix <string>　[undef]

対応不詳

■ まとめ：

Specify color matrix setting ["undef"]
- undef, bt709, fcc, bt470bg
smpte170m, smpte240m, GBR, YCgCo

■ 参考

覚書（要約）: 前項参照

手許: 前項参照

VUI Guide: 前項参照

zero1(svn408): 記載無し

--chromaloc <integer>　[0]

対応不詳

■ まとめ：

Specify chroma sample location (0 to 5) [0]

■ 参考

VUI Guide: 6. Chroma Sample Location
これは何？
映像マニア（※videophile）の設定。平均的なユーザは違いに気付く事さえないでしょう。
人間の視覚の弱点（※色彩認識力は輝度のそれに比べて弱い）を利用して彩度サンプルを間引く事をサブサンプリングと言います。
特にx264では、2x2輝度サンプルブロックに対応する彩度サンプルは一個だけです。
こうしたサブサンプリングを行う方式には様々なものがありますが、結果はどれも輝度サンプル値に対する彩度サンプル値の相対位置を出すものです。彩度サンプル・ロケーションはサブサンプリングプロセスを逆回転させる時（※再生時）に効果が出ます。即ち、彩度サンプルの数が増やされるわけです。多くの場合、これはカラースペース変換の際に行われます。この工程が正確でないと、多くの場合、彩度の値が輝度サンプルに対して1ピクセルずれた位置に現れます。または奇妙なボケ。; 　; 使い方
x264 はサブサンプリング済みの入力フレームしか受け付けないので、サブサンプリング能力を持たない。従って彩度サンプル・ロケーションの方式は自分で設定する必要がある。
　適切に4:2:0サブサンプルされたMPEG1のトランスコードで、カラースペース変換を一切行わない場合、オプション指定値は1。
　適切に4:2:0サブサンプルされたMPEG2のトランスコードで、カラースペース変換を一切行わない場合、オプション指定値は0。
　適切に4:2:0サブサンプルされたMPEG4のトランスコードで、カラースペース変換を一切行わない場合、オプション指定値は0。
　カラースペース変換を自力で行う場合、これは簡単な事では無い。
　サブサンプリングのフィルタ・カーネルが一方向の( 0.5, 0.5 ) の場合、その方向の彩度サンプリング・ロケーションは２個の輝度サンプルの間になる。
　サブサンプリングのフィルタ・カーネルが一方向の ( 0.25, 0.5, 0.25 ) の場合、その方向の彩度サンプリング・ロケーションは輝度サンプルうち一つと同じになる。
　H264 Annex E には彩度サンプル・ロケーションをx264に渡せる0～5の形式に"トランスフォーム"する方法を示す図が入っている。
　
このオプションは使った方がよいですか？
完全主義者でなければ気にしないで下さい。メディアプレイヤはこの設定を無視して固有の（固定の）彩度サンプル・ロケーションを使います。

手許

zero1(svn408): Usage: --chromaloc <integer> (default=0) [0 - 5]
彩度のアップサンプリングに関わる極めて技術的な設定。例えばカラースペース変換や再生など。正しく使う事ができればクロマシフトやブラーを緩和できる（ほとんどの場合、ズレは1ピクセルくらいなので目立たないが）。; もし素材映像を編集してあれば、その段階でカラースペース変換は終わっている（ほとんどの編集ソフトはRGBを使う）だからこの設定は必要すらない（さらに平均的な人はその違いにすら気付かない）。カラースペース変換を経ていない直エンコでない限り、この設定の使用はお奨めはしません。; しかしながら万全を期す為に大まかな指針を書いて置きます：; 素材がMPEG-1 (4:2:0) かつ direct transcode (no colourspace conversion)の場合、1を指定。
素材がMPEG-2 (4:2:0) かつ direct transcode (no colourspace conversion)の場合、0を指定。
素材が MPEG-4 (4:2:0) かつ direct transcode (no colourspace conversion)の場合、0を指定。

[ 2006/12/12 00:00 ] ごみ箱　-x264encopts | TB(0) | CM(0)

H.264/AVC規格概要：プロファイル

プロファイル

　H.264/AVC には多数の符号化ツールがあるが、全てのアプリケーションで全てのツールが必要とされている訳ではない。例えば、洗練されたエラー耐性ツールはデータロスや破壊が非常に少ないネットワークでは重要ではない。全てのアプリケーションに全ツールのサポートを強制した場合、無駄に複雑なアプリケーションが出て来てしまうだろう。このため、符号化ツールのサブセットが定義された。これをプロファイルと呼ぶ。デコーダでサポートするサブセット（プロファイル）はどれか一つだけでも自由だし、複数や全てサポートしても自由だ。H.264/AVC最初の規格では、以下の三つのプロファイルが定義され、最新版でもそのまま残っている。：

Baseline (BP)
Extended (XP)
Main (MP)

　Baseline profile（BP）がサポートするのは I およびPスライス、一部の高度なエラー耐性ツール（FMO, ASO, RS）、そしてCAVLC。B、SP、SIスライス、インターレース符号化ツール、CABAC エントロピー符号化はサポートしない。Extended profile（XP）はBaselineのスーパーセットで、上記にB、SP、SIスライス、インターレース符号化ツール、そして、データパーティショニング（DP）によるエラー耐性の向上を加えたもの。CABACはサポート外。Main profile（MP）がサポートするのは I、P、Bスライス、、インターレース符号化ツール、CAVLCとCABAC。高度なエラー耐性ツール（FMO, ASO, RS, DP）やSP、SIスライスはサポート外。

　本稿執筆時点（＊2004/08月＊）では、 Baseline Profile はビデオ会議のプライマリ・チョイスのようだ。Main profileは、エンターテインメント品質のコンシューマー・アプリケーションで大きな関心を集めてきたが、勢いはFRExtの新しいHigh profileの登場により弱まりつつある。
　プロファイルは、想定する主な用途に対応して7種類あり、各々において使用するツールと処理範囲等を定めている。レべルは、取り扱う映像の画素数に対応して16種類が定められている。

FRExt 改正により、以下4のprofileが追加定義された:

High (HP)
High 10 (Hi10P)
High 4:2:2 (Hi422P)
High 4:4:4 (Hi444P)

　これら４つのプロファイルは、Main profileのデザインの上に構築され、共通するのは以下の４点；

適応的マクロブロック・レベルスイッチング。8x8と4x4変換ブロックサイズの自動選択が可能になった。

（＊Adaptive macroblock-level switching between 8x8 and 4x4 transform block size＊）

エンコーダが固有の人間の視覚認識ベースの量子化スケーリングマトリクス（カスタム量子化マトリクス）を使える。

（＊Encoder-specified perceptual-based quantization scaling matrices＊）

エンコーダは独自に各彩度コンポーネント（＊CbとCr＊）に独立した量子化パラメータを使える。

（＊Encoder -specified separate control of the quantization parameter for each chroma component＊）

　一般的な4:2:0 videoに加え、これらのプロファイルは全て、白黒符号化されたビデオシークエンスもサポートする。新プロファイル間の違いは主にサポートする色深度と色差信号(＊chroma＊) フォーマットだ。ただし、High 4:4:4 はさらに、residual（＊残りの＊） color transform と predictive（＊予測＊） lossless coding の機能を持つ。これは他のプロファイルには存在しない。詳細は以下。

プロファイル

Coding Tools	Baseline	Extended	Main	High	High 10	High 4:2:2	High 4:4:4
概要	双方向予測やインタレース映像への処理等を省いた基本的ツールで構成。伝送エラー耐性用ツールを含む。	Baselineを包含すると共に、より高画質・高度化のためのツールを追加。	標準的ツール群で構成される代表的なプロファイル。 FMO,ASO,RS(注7)を除くBaseline プロファイルを包含。	Mainを包含すると共に、HDTV映像等の高画質化用拡張(FRExt)ツール群を追加。	Highに10ビットサンプリング映像対応を追加。	High 10に4:2:2クロマフォーマット対応を追加。	High 4:2:2に12ビットサンプリング映像および4:4:4クロマフォーマット対応を追加。
主要用途	モバイル放送、ネット配信など	高度な配信など	放送、蓄積メディア、配信など	高画質放送、蓄積メディア、スタジオ(編集・蓄積)など	素材配信、スタジオ(編集・蓄積)など	素材配信、スタジオ(編集・蓄積)など	素材配信、スタジオ(編集・蓄積)など
スライス
I 、Pスライス	◯	◯	◯	◯	◯	◯	◯
B スライス		◯	◯	◯	◯	◯	◯
インターレース符号化 (PicAFF, MBAFF)		◯	◯	◯	◯	◯	◯
エントロピー符号化
CAVLC	◯	◯	◯	◯	◯	◯	◯
CABAC			◯	◯	◯	◯	◯
整数変換（DCT？）
8x8 または 4x4 の適応変換				◯	◯	◯	◯
量子化制御
カスタム量子化マトリクス				◯	◯	◯	◯
CbとCrの個別 QPコントロール				◯	◯	◯	◯
重み付け予測	-	◯	◯	◯	◯	◯	◯
色関係
モノクロ映像フォーマット				◯	◯	◯	◯
9 および10 Bit サンプル深度					◯	◯	◯
11 および12 Bit サンプル深度							◯
8 Bit サンプル深度	◯	◯	◯	◯	◯	◯	◯
4: 2:0クロマフォーマット	◯	◯	◯	◯	◯	◯	◯
4: 2:2クロマフォーマット							◯
4:4:4クロマフォーマット							◯
エラー耐性
高度なエラー耐性 (FMO, ASO, RS)	◯	◯		◯	◯	◯	◯
より高度なエラー耐性 (DP)		◯		◯	◯	◯	◯
SP、 SIスライス		◯		◯	◯	◯	◯
その他（不詳）
Residual Color Transform							◯
Predictive Lossless Coding							◯

　高位のプロファイルは下位プロファイルの機能を包含する。規格上も高位プロファイルに対応するものは下位プロファイルのビットストリームは全てデコード可能でなければならないとしている。

　High profileが短期間に極めて大きな関心を集めている理由は、実装上の複雑さがMain profileに比べて非常に小さく（ほとんど無い）、その一方で圧縮能力は主観的にも客観的にも向上（特にカスタム量子化マトリクスと適応的マクロブロック・レベルスイッチングによる）し、エンコーダ制御の自由度も増すためだ（CbとCrに独立した量子化パラメータを使える事による）。

【元ネタ１】

総務省情報通信審議会情報通信技術分科会（第４２回）情報源符号化部『H.264 | MPEG-4 AVC 規格の概要』
入手先：配布資料資料４２−１−２
pdf直リン：http://www.soumu.go.jp/joho_tsusin/policyreports/joho_tsusin/bunkakai/pdf/060720_3_1-2_sa2.pdf

【元ネタ２】

『Introduction paper to H.264/MPEG-4 AVC including the Fidelity Range Extension』
入手先：スウェーデン、 Luleå University of Technology、Dr. Peter Parne氏の講義ガイダンスの模様。
pdf直リン：http://media.csee.ltu.se/%7Epeppar/kurs/smd151/spie04-h264OverviewPaper.pdf

[ 2006/12/14 00:00 ] 動画　MPEG-4全般 | TB(0) | CM(0)

H.264/AVC規格概要：レベル

レべル

　 H.264/AVCでは16種類のレベルが定められている。　
　取り扱う映像の画素数とフレームレートに対応しているが、これはそれらが実際の製品開発で重要なCPUパワーとメモリサイズの制約への影響が最も大きい為だ。また、最大参照フレーム数と、最大ビットレートもレベルにより制限がある。
　"1b"のようなレベルはFRExt改正で追加されたもので、主に3Gワイヤレス環境の要請に応えるためのもの。
　FRExt profileはより忠実度の高いアプリケーションの為の定義なので、ビットレートの許容範囲も表１のように拡大した。この係数は表２の７番目の列（非 FRExtでの最大圧縮ビットレート (VCL用)）で使われるものだ。

　Note：規格上、Levelが規定する最大フレームサイズとは、pixel/frameの合計数だけだ。水平・垂直それぞれの最大サイズは、Sqrt （maximum frame size * 8）以下でなければならない事を除けば規格には無い。（＊8の倍数でも良い？＊）
　もし、ある特定のレベルで、ピクチャ・サイズが表のサイズより小さければ、それに応じて動き予測と動き補償にもっと大きな数のマルチプル・レファレンスピクチャ（＊複数参照＊）が使える（最大16）。同様に、それぞれのレベルで最大フレームレートを指定する代わりに最大サンプル（ピクセル）レートが、マクロブロック /secという用語で規定されている。従って、もしピクチャ・サイズが表２の一般的なサイズより小さい場合、フレームレートは表２にある値よりも大きくとり得る。最大は172fps。各レベル・解像度ごとに対応可能な最大fpsは表３を参照。

表１：Compressed Bit Rate Multipliers for FRExt Profiles (表２の第７列参照)

FRExt Profile	Bit Rate Multiplier
High	1.25
High 10	3
High 4:2:2	4
High 4:4:4	4

表２ H.264/AVCのレベル

レベル	最大フレームサイズ (MBs)	最大 MB処理レート (MB/s)	最大映像ビットレート (kbps)	一般的なピクチャサイズ	一般的なfps	非FRExt での最大圧縮ビットレート (VCL用)	一般的なピクチャサイズでの最大参照フレーム数	符号化ピクチャ	想定プロファイル（下記に限定されない）				備考
1	99	1485	64	QCIF	15	64 kbps	4	フレームMBのみ	BP	EP
1b	99	1485	128	QCIF	15	128 kbps	4
1.1	396	3000	192	CIF or QCIF	7.5 (CIF) / 30 (QCIF)	192 kbps	2 (CIF) / 9 (QCIF)
1.2	396	6000	384	CIF	15	384 kbps	6
1.3	396	11880	768	CIF	30	768 kbps	6
2	396	11880	2000	CIF	30	2 Mbps	6
2.1	792	19800	4000	HHR (480i or 576i)	30 / 25	4 Mbps	6	フレームまたはフィールド			MP
2.2	1620	20250	4000	SD	15	4 Mbps	5
3	1620	40500	10000	SD	30 / 25	10 Mbps	5					HP～
3.1	3600	108000	14000	1280x720p	30	14 Mbps	5
3.2	5120	216000	20000	1280x720p	60	20 Mbps	4
4	8192	245760	20000	HD Formats (720p or1080i)	60p / 30i	20 Mbps	4
4.1	8192	245760	50000	HD Formats (720p or1080i)	60p / 30i	50 Mbps	4
4.2	8704	522240	50000	1920x1080p	60p	50 Mbps	4	フレームMBのみ
5	22080	589824	135000	2kx1k	72	135 Mbps	5
5.1	36864	983040	240000	2kx1k or 4kx2k	120 / 30	240 Mbps	5						x264 デフォルト

表３：各映像サイズに対応可能なレべルと最大フレームレート(fps)

映像フォーマット	輝度の WxH	最大フレームサイズ（MBs）	1.0	1b	1.1	1.2	1.3	2	2.1	2.2	3	3.1	3.2	4	4.1	4.2	5	5.1
SQCIF	128×96	48	30.9	30.9	62.5	125.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0
QCIF	176×144	99	15.0	15.0	30.3	60.6	120.0	120.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0
QVGA	320×240	300			10.0	20	39.6	39.6	66.0	67.5	135.0	172.0	172.0	172.0	172.0	172.0	172.0	172.0
525 SIF	352×240	330			9.1	18.2	36.0	36.0	60.0	61.4	122.7	172.0	172.0	172.0	172.0	172.0	172.0	172.0
CIF	352×288	396			7.6	15.2	30.0	30.0	50.0	51.1	102.3	172.0	172.0	172.0	172.0	172.0	172.0	172.0
525 HHR	352×480	660							30.0	30.7	61.4	163.6	172.0	172.0	172.0	172.0	172.0	172.0
625 HHR	352×576	792							25.0	25.6	51.1	136.4	172.0	172.0	172.0	172.0	172.0	172.0
VGA	640×480	1200								16.9	33.8	90.0	172.0	172.0	172.0	172.0	172.0	172.0
525 4SIF	704×480	1320								15.3	30.7	81.8	163.6	172.0	172.0	172.0	172.0	172.0
525 SD	720×480	1350								15.0	30.0	80.0	160.0	172.0	172.0	172.0	172.0	172.0
4CIF	704×576	1584								12.8	25.6	68.2	136.4	155.2	155.2	172.0	172.0	172.0
625 SD	720×576	1620								12.5	25.0	66.7	133.3	151.7	151.7	172.0	172.0	172.0
SVGA	800×600	1900										56.8	113.7	129.3	129.3	172.0	172.0	172.0
XGA	1024×768	3072										35.2	70.3	80.0	80.0	170.0	172.0	172.0
720p HD	1280×720	3600										30.0	60.0	68.3	68.3	145.1	163.8	172.0
4VGA	1280×960	4800											45.0	51.2	51.2	108.8	122.9	172.0
SXGA	1280×1024	5120											42.2	48.0	48.0	102.0	115.2	172.0
525 16SIF	1408×960	5280												46.5	46.5	98.9	111.7	172.0
16CIF	1408×1152	6336												38.8	38.8	82.4	93.1	155.2
4SVGA	1600×1200	7500												32.8	32.8	69.6	78.6	131.1
1080 HD	1920×1088	8160												30.1	30.1	64.0	72.3	120.5
2Kx1K	2048×1024	8190												30.0	30.0	63.8	72.0	120.0
2Kx1080	2048×1080	8704														60.0	67.8	112.9
4XGA	2048×1536	12288															48.0	80.0
16VGA	2560×1920	19200															30.7	51.2
3616x1536 (2.35:1)	3616×1536	21696															27.2	45.3
3672x1536 (2.39:1)	3680×1536	22080															26.7	44.5
4Kx2K	4096×2048	32768																30.0
4096x2304 (16:9)	4096×2304	36804																26.7

【元ネタ１】

【元ネタ２】

[ 2006/12/14 22:42 ] 動画　MPEG-4全般 | TB(0) | CM(0)

avc1Decoder 0.5.0

【リリース場所】http://blog.so-net.ne.jp/MyCometG3/2006-12-15
【入手先】http://www003.upp.so-net.ne.jp/mycometg3/
【目次】

avc1Decoder 0.5.0

avc1Decoder 0.5.0

　libavcodec H.264 QuickTimeコンポーネント。MP4コンテナ対応。

1. PostProcess

　上記の通り手許では切っている。第一の理由はブロックノイズがあるなら発見したいから。第二の理由はApple-H.264ではエンコードでインラインデブロックを切れない事。第三の理由は H.264/AVCのインラインデブロック（in-loop filter）とliavcodecのppはバッティングの可能性がある事。

い）設定項目の意味

　MPlayer and MEncoder on MacOSX/Man/VIDEO FILTERS/ppの記述からPostProcessの設定内容はそれぞれ以下のようなものと推測。

de/default

デフォルトのppフィルタセット(hb:a,vb:a,dr:a)

hb/hdeblock：垂直方向のデブロックフィルタ
vb/vdeblock：水平方向のデブロックフィルタ
dr/dering：デリンギングフィルタ
:a 　共通子オプション。低速CPUで自動的に使用を停止。

fa/fast

高速な ppフィルタセット(h1:a,v1:a,dr:a)

h1/x1hdeblock：試験的な水平デブロック
v1/x1vdeblock：試験的な垂直デブロック

ハイクオリティの ppフィルタセット(ha:a:128:7,va:a,dr:a)

ha/hadeblock[:differ-ence[:flatness]]：精密な垂直デブロック
va/vadeblock[:differ-ence[:flatness]]：精密な水平デブロック
垂直と水平のデブロックはdifferenceとflatnessの値を共同使用する。このため、それぞれに別の値を指定できない。

PostProcess Level（スライドバー）

各フィルタの強度指定と思われ。例えばha/hadeblockの[:differ-ence[:flatness]]に入れる値など。

ろ）インラインデブロック（in-loop filter）とのバッティングの可能性

　使う際は以下のような見解がある事に注意すべきかと思う。

Doom9 2005 コデックコンテスト -- メイン、Playbackの項：How to Use ffmpegXメモ was here （2006年01月13日）
MPEG-4 ASPの再生ではデブロッキングを使った。
AVCにはビルトイン・デブロッカーがあるのでポストプロセスは使っていない（AVCを見る際にffdshowのポストプロセスをオンにすると非常に見た目が悪い。動作はするが、それは映像をぶち壊す方向に働く）。

　闇階調の多いアニメ（ゴーストハント）でVLCやMPlayer(cli)と見比べてみたが、ブロックが消えるというよりは、出る範囲が微妙に変わる。効果はavc1Decoderの方が良い場面も有り悪い場面も有り。いずれにせよ違いは極めて地味で、自分の視覚では非常に見た目が悪いというほどの事はなかった。ちょっとどっちがどうとは言い難い。あとやっぱ闇階調のブロックノイズはモニタの輝度・コントラスト、部屋の明るさで見え方がぜんぜん変わる。プロはモニタにフードとか付けるみたいなので、モニタ以外の光源を全部切り、輝度最強にしたら見付け易かった。かなり目にキタ（そんくらいにらめっこしないと違いがわからなかった）。あと幽霊のアップ怖かった。
　Doom9の情報もpp部分の拙訳も1年以上前のものだから、その後の改善で対策済みの可能性大。規格上に存在するin-loop filterにlibavcodecのポストプロセス・デブロックを重ねる意義は不詳だが、一般的なのだろうか。

は）再生時のインタレ解除の可能性

　実装未確認だが、"Use Custam setting"で、pp系統のインタレ解除が使える可能性がある。

2. nclc setting

colr-nclc：MyCometG3（2006/12/14）
mp4/mov ファイルで、avc1のImageDescription Extensionに"nclc"情報が埋め込まれていない（Apple H.264以外ほとんど全ての）データで、色変換の指定をするものだ。
／／
　一応、動いてる。
　でも、思ってたほど劇的に変わる訳ではないのだな。

　引用元にあるADCのリンク先を見ると、x264cliのVUI設定（--colorprim、--transfer、--colormatrix）で指定できるもののようだ。良く似た単語があるってだけだけど。Apple H.264以外のほとんど全てのデータで"nclc"情報が無いというのは、これらのデフォルトがいずれも[undef]なのと符合する。

　x264ソース付属文書ではこれらの設定項目を映像マニア（※videophile）の設定。平均的なユーザにとって必要なものでは、ぜんぜんないです。と言っている。同文書では残念な事に私は color/gamma/color matrix補正に対応したデコーダ/メディアプレイヤを、それを試みようとするものさえ、見た事がありません。とも言っている。

　どちらが良いと言う筋合いのものではないがハナシがこのへんの領域に入って来るとApple無敵。印刷とか写真とか映像とか色に五月蝿い業界で鳴らしてただけに。

3. ついちまちまと重箱の隅をつついてしまったが、メリットのほうが絶大。

　HPでもMovieVideoChartで細かい結果を視覚化できるし、Delay frame除去にQTCoffee（muxmovie）が使えるし、QuickTime Playerで再生時にインタレ解除できるかもしれないし、作ったMP4をiTunesで管理できるし。

　これ一個でなんかもう一気にいろんなことがスゲェことになりそうだ。

[ 2006/12/15 22:01 ] 他ツール　QuickTime | TB(0) | CM(0)

Delay_frame 除去実験その1　pullup、-ofps 24000/1001の場合

　MEncoderでBフレームを使うとムービー冒頭にDelay frameが入る。
　これはMEncoder 固有のバグであり、もちろん規格外であり、地味なA/V desyncを産む。
　MEncoder GUIとしてスタートしたMeGUIが、あんまMEncoderにチカラ入ってねぇように見えるのは、これの所為かもってくらい古くさいバグ。
　手許ではA/V desyncを知覚できない事から放置していたが、avc1Decoder の登場によりHigh Profileでもmuxmovieでの対策が可能になった。
　そこで、手許で作成したx264+faac.mp4からDelay frameを除去する実験。

使用ツール

い）手許でエンコードに使っているツールは以下の通り。

映像：MEncoder dev-SVN-r21181-4.0.1 (C)（x264 core:54 svn-602M）
音声：ffmpeg（ffmpegX内蔵版）
mux：MP4box（ffmpegX内蔵版）

※おおまかな設定はカテゴリ「圧縮日記264」を参照されたい。
ろ）Delay frame除去に使ったツールは以下の通り。

QuickTime Player Pro（￥3,400）
avc1Decoder（QuickTimeコンポーネント）
muxmovie（QTCoffeeに含まれるコマンドラインツール、非商用なら無償）
MovieVideoChart（映像分析）

pullup、-ofps 24000/1001の場合

1.1.現象

Bフレーム関連設定は、bframes=3:b_adapt:weight_b:b_pyramid
下図は MovieVideoChart 。

映像開始点が0.083秒ずれている。≒(1/24)*2なので、2フレームぶん、タイムスタンプが後方にずれている。
このタイムスタンプのずれ自体は問題では無い。後述するが、Apple-H.264でB付き.mp4を吐いた場合も同様だから。
問題はApple-H.264で作成した場合は最上段「Frames in Track」にも映像が出る事。
原因は、rawvideoの段階で冒頭にいわゆるDelay frame、ヘッダだけで実データが無いもの、が入っているからと思われる。そんなの規格外だし、そもそもMEncoder固有のバグだ（AviSynth to x264cliには無いらしい）。
これは一旦映像だけを抽出し、muxmovieで処理できる。

1.2.対策

１）mp4box -rawでrawvideo抽出。

$ mp4box -raw 1 ケロロ軍曹_061201.mp4

２）fpsを指定して映像のみ.mp4に。

$ mp4box -fps 23.976025 -add ケロロ軍曹1_track1.h264 -new ケロロ軍曹_061201_track1.h264.mp4

３）muxmovie -startAtで映像にスタートディレイを設定。-startAtは時刻指定なので近似値で良い。

$ muxmovie -startAt 00:00:00.09 -self-contained ケロロ軍曹_061201_track1.h264.mp4 -o out ケロロ軍曹_061201_track1.h264.mp4.mov

４）QuickTime Player Proで音声貼付け、.mp4へ書き出し。映音とも「そのまま」
　映像を全選択して「選択範囲に追加」。「選択範囲に調整して追加」のほうがデータ表示上のDurationは揃うが地味に音が濁るケースが有る。

1.3. 結果

下図の通り、QuickTime Player Pro/Apple-H.264で作成したものと表示が揃った。

最上段のFrames in Trackを正しく表示できる。 QuickTime Player Proの表示（林檎+Jのデータレート等）も正常表示。開始フレームのタイムスタンプが0.083のままな事に注意。	QuickTime Player Pro、Apple-H.264、30fpsで作成、フレーム並べ替え（bframes=1相当）有り。開始フレームのタイムスタンプが0.033（30fpsの1フレームぶん）な事に注意。

b_adaptの効果でB枚数は不規則。bframes=3にもかかわらずのっけからIPBP。 syncフラグがIDR。I/P/B/参照Bなどの区別は出ない。 rawvideoを経由しているせいか、droppableフラグも無し。少なくともQuickTimeインフラ上ではトリックプレイや低速CPUに弱い筈だ。	bframes=1、nob_adapt相当なのでBは規則的に入る。 syncフラグがIDR。Bにはdroppableなるフラグもついている。トリックプレイや低速CPUに強い筈だ。このへんの用語は映像コデック側の理屈よりなにかと「同期」を意識したものが多い。 Quick"Time"はやっぱ時間軸のインフラなのだろう。

1.4.疑問点

QuickTime Player Pro、Apple-H.264で作成した場合も1st Frameのタイムスタンプが0では無い。音声は、上記1.2.4）の段階で.movに素材から抽出したaiffを貼付け、QuickTime Player Proに任せるほうが安心かも知れない。

[ 2006/12/16 00:00 ] MEncoder　メモ | TB(1) | CM(0)

Delay_frame 除去実験その2　yadif=0、 -ofps 30000/1001の場合

　インタレ解除にyadif=0を使った場合、pullupのケースとはやや様子が異なる。というかyadifやばい。

yadif=0、-ofps 30000/1001の場合

1.1. 現象

Bフレーム関連設定は、bframes=3:b_adapt:weight_b:b_pyramid
下図は MovieVideoChart 。Apple-H.264で作成した場合は最上段「Frames in Track」にも映像が出る。
映像開始点が2フレームずれる。(1/30)*2≒0.066秒。
ここまではpullupのケースと同じだが、そこから2枚、緑のフレームが入る。真の映像開始点は0.133秒目。
緑のフレームはbitを消費している為、rawvideoの段階でDelay frame以外にヘッダと実データを持ったフレームが2枚入っている。

図１）緑フレームはIDRとP。３枚目がPとなっているため、カットできねぇだろこれわというカンジ。

図２）３枚目がsync（IDR）となっているケースもある。これはGOP単位編集できる可能性がある。

1.2.対策

図１のやばそうなほうで実験してみた。
１）mp4box -rawでrawvideo抽出。

$ mp4box -raw 1 kinshubanya_061203.mp4

２）fpsを指定して映像のみ.mp4に。

$ mp4box -fps 29.970030 -add kinshubanya_061203_track1.h264 -new kinshubanya_061203_track1.h264.mp4

３）muxmovie -startAtで映像にスタートディレイを設定。-startAtは時刻指定なので近似値で良い。

$ muxmovie -startAt 00:00:00.14 -self-contained kinshubanya_061203_track1.h264.mp4 -o out kinshubanya_061203.h264.mp4.mov

1.3.結果

人を不安にさせる表示だが、QuickTime Player Pro、VLC 0.8.6とも再生は平気。
QuickTime Player Proは白紙フレームを表示する事も、開始点で早回しを押すと末尾に飛ぶ事もなく、まぁ平気。
終点で白紙フレームを表示する事があるが、これは実データを２コマも飛ばしてるわけだし。
再生中にマウスで任意の点に飛ぶとしばらくの間カクカクになるなど全般にトリックプレイに弱い印象があるが、これは元のファイルをQuickTime Player Proで見る際も同様。
VLCは開いた直後に一瞬緑フレームを表示する事がある。

図1、2を見た後では、意外になんとかなるもんだという印象を持ったが、かなりやばめなファイルである事は確実。

Avidemuxにはより実験的なmcdeintが移植されていながら、yadifが移植されて無いので奇妙に思っていたが、こうゆうことですか。
手許のファイルを20個ほど MovieVideoChartで開いてみたが、yadif=0固有の現象のようだ。フィールドオーダーの分析でアタマ２枚喰ってしまうのだろうか。
30fpsで他に有用なインタレ解除となると、filmdintかpp系という事になるが、、、いっそインタレ保持かなぁ。

[ 2006/12/16 00:00 ] MEncoder　メモ | TB(0) | CM(0)

Changeset [601] - [611]

http://trac.videolan.org/x264/timelineからピックアップ。PowerPC関連中心。あとスレッド処理方式に変更が出てる。

Changeset 601（06/11/18）

Guillaume Poirierの AltiVec changesをマージ

Adds optimized quant and sub*dct8 routines
Faster sub*dct routines

デフォルト設定で最大8%の速度向上。

Changeset 604（06/11/27）

以下のAltivec実装を追加： add8x8_idct8, add16x16_idct8, sa8d_8x8 and sa8d_16x16
Note: 起こりうる aligned memory accessの利点を使わない。だからまだ改善の余地がある。

Changeset 607（06/12/16）

新しいスレッド方式。
各フレームをスライスに分割していたのを、複数参照フレームの併行処理に変更。
速度改善、スレッディングのビットレート・ペナルティ緩和。

副次効果：
フレームの再エンコードはもうできないので、スレッデッド・シーンカット検出はpre-me pass（＊動き予測の前のパス？＊）でやらなければならない。これは高速だが、精度は落ちる。
CPU数より多くのthread数を使っても良い。--threads=autoはcpus*1.5を使うようにアップデートされた。
他にレートコントロールのマイナーチェンジ。

新しいオプション： --pre-scenecut, --mvrange-thread, --non-deterministic

Encoding H.264 using the x264 Command Line InterfaceのZero 1氏から頂いたコメント。試訳。
　私があのガイドを書いてから x264にはいくつかの良い改善がありました。マルチスレッド（複数CPUでのエンコード）が高速化し、画質劣化が非常に少なくなったのは喜ばしい事です。極めてnegligable（＊意味不明＊）です。推奨。

■negligible {形} : 取るに足りない、極わずかな、無視してよい、無視し得る、無視できる

x264 core:54 svn-611Mの--longhelpから。いずれもMEncoder dev-SVN-r21629のmanに記載無し。

x264 core:54 svn-611M
Frame-type options:
--pre-scenecut	Faster, less precise scenecut detection.Required and implied by multi-threading. 高速だが正確性に劣るシーンカット検出。マルチスレッディングが必要。
Analysis:
--mvrange <integer>	Maximum motion vector length [-1 (auto)] モーションベクトルの最大長さ [-1 (auto)]
--mvrange-thread <int>	Minimum buffer between threads [-1 (auto)] スレッド間の最大バッファサイズ [-1 (auto)]
Input/Output:
--non-deterministic	Slightly improve quality of SMP, at the cost of repeatability repeatability （＊不詳＊）と引き換えに、SMP（Symmetric Multiple Processor、対称型マルチプロセッサ）の品質を若干向上。

余談：
　"各フレームをスライスに分割していたのを、複数参照フレームの併行処理に変更。"とは、分散の単位がGOP単位だったものが参照関係単位になったとでも思えばいいのだろうか。MEncoder側のturboの内容が変わるかもしれない。

070105 追記

x264 revision 610 - sliceless threading - what's new#9 (Doom9, akupenguin)
Short answer: you shouldn't need to use any of the new options.
--pre-scenecut might possibly be useful for fast 1pass single-threaded encodes, but is mostly just so I can compare the two scenecut algorithms without invoking the other threading stuff.

　端的に答えると：新しいオプションはどれも使う必要が無い。
　--pre-scenecutは fast 1pass single-threaded encodeで有用な可能性があるが、多くの場合大差ない。だから私は２種類のscenecutアルゴリズムを他のthreading要素を起動する事なく比べられるわけだ。

[ 2006/12/17 00:00 ] ごみ箱　未分類 | TB(0) | CM(1)

RE: Zero 1@061218

これはZero 1氏に頂いたコメントの返信です。長くなってしまったのでエントリにしました。
背景黄色はオリジナルのコメント、白が返信です。
This entry is RE: for this comment. I made it entry cause it is little bit long.
Yellow background is original comment, and white background is my reply.

	English	Japanese
Zero 1	Ah, Mac OSX. I don't have a Mac myself, but I can imagine the shortage of encoding programs, which is what makes what you do important. I also imagine that some people may have difficulty with some encoding programs, because as far as I know the majority of them (Virtualdub, XviD, x264, MP4box, AVISynth, LAME etc as far as Windows is concerned) are written in English only. I know how frustrating that can be from times I've tried to use Winny before. It's great that the guide was a help, and I appreciate you translating it (I hope most of what I said made sense!). If I had known someone who was able to translate (or was able to myself) I would probably have done it.	ああ、 Mac OSXなんだ。自分では持っていないけど、エンコード・プログラムが不足している事は想像できる。それが貴方のやっている事を貴重にしているんだ。それからエンコード・プログラムを使うのに苦労してる人たちがいるのも想像できる。というのは自分が知る限りの大半は（ Windowsに関する限り、Virtualdub, XviD, x264, MP4box, AVISynth, LAME などなど）英語で書かれているからだ。前にWinnyを試した時の経験から、それがどれほどストレスの溜まる事か解る。あのガイドが役に立って嬉しい。訳してくれて有難う（私の書いたものに意味が有るといいけど！）。もし知り合いに翻訳できる人が居たら（か、自分で訳せたら）自分でやったのだけど。
Ageha	I should apologize that I translated your guide without your permission. I'm Sorry. although I'm Mac User, and not using x264cli, but when you have plan to translate the guide to Japanese, feel free to use my translations of course (and of course if it worth^^;). ...By the way, sometimes I feel like Helen Keller. "WATER!!" but when I yell out, some people come to help. thanks a lot. Esperance :GUI x264.mp4 encoder Mac/Linux/Win. MyCometG3 :many useful tools for QuickTime, including avc1Decoder ! raw2qt264(English)：command line encoder using QuickTime H.264 codec for Mac OS X. Lunatilia@Wiki : not yet. but going to be a HD video editor for Win/Linux/Mac.	勝手に翻訳してしまってもうしわけない。自分はMac Userで、しかもx264cliを使っていないが、もし公式な翻訳計画があったら自分の翻訳を自由に使って下さって構いません（そしてもちろん、その価値があれば^^;）。　ところで私は時々ヘレン・ケラーのキモチになりますよ。わ～ら～。　しかしながら、助けてくれる人はいるものです。叫んでみるものです。 Esperance :GUI x264.mp4 エンコーダ Mac/Linux/Win. MyCometG3 :QuickTimeで有用なtoolが沢山ある。目玉は avc1Decoder ! raw2qt264(English)：command line encoder using QuickTime H.264 codec for Mac OS X. Lunatilia@Wiki : まだ完成していないが Win/Linux/Macで動くHD 映像編集ソフトになる予定。
Zero 1	One thing though, I find it funny how the guide has been found considering that I only released this beta version in an IRC channel of about 15 active people (there are usually around 50 people in the channel, but most of them never do anything). It's amazing how news and word of mouth travels. It makes you realise how amazing the internet is and how we take it for granted.	一つ面白いと思うのは、15人ばかりのアクティブメンバーしかいないIRCチャンネル向けのベータ版ガイドがどうして見つかったのか（いつも50人くらいは居るのだけれど大半はなにもしない）。ニュースと口コミの威力は凄いものだ。ネットの威力に感謝だ。
Ageha	I found link to the guide in 2ch, most famous / notorious and largest Forum's Forum in Japan. seems little bit unique in other nations. Contrary to AnimeMusicVideos.org, Doom9, and some others, 2ch does not have it's own thema. organizer says "from hacking to cooking", it has almost all kind of Forums. 2ch has directory like yahoo (Forum name / thread), for instance I found link to the guide in "DTV(DeskTop Video) / x264 rev7". All forums are under complete Anonymous system, most of people do not use even "pointer" such as "Zero 1", or "Ageha" (and I'm Anonymous too). So sometimes this cause social controverse. for instance, I think "Winny" could not be developed without 2ch. It was a big progress in japanese P2P technology, but also enhanced piracy and security problem. 2ch is a kind of chaos. Good point: almost all Japanese Forums are in here in one system. so you can find almost everything here. if you check here constantly, you can be Up-to-date. Bad point: it's system is so simple, every infomations are flat in timeline. you might feel it's a equivalent of IRC, actually some forums are dedicated for conversations. URL is here, but link to the guide is already gone... http://pc8.2ch.net/test/read.cgi/avi/1164192957/ 2ch is so large and contains a lot of informations, so some people consider that it is a database. but for me ( Helen Keller in Windows world;)), theres too much noise. each info's are very short and chopped into pieces, it's hard to findout reliability since there's no pointers. this is why I count on "Guide-Writer's Hard work. as you may have noticed, like here.	私は貴方のガイドへのリンクを2chで見つけました。2chというのは、日本のnetにおける、最も有名で/悪名高く、最も大きな、ForumのForumです。日本以外では少し特殊な存在のようです。AnimeMusicVideos.orgや Doom9とは異なり、2chには特定のテーマがありません。運営者は「ハッキングからクッキングまで」と言っており、事実上全てのForumです。 2chはyahooに似たディレクトリ構造の分類（Forum name / thread）を持っています。例えば私がガイドを見つけたのは、"DTV(DeskTop Video) / x264 rev7"。完全な匿名制で、"Ageha"や"Zero 1"のようなポインタすら、使う人は稀です（自分も名無しです）。したがって、社会的に問題とされる事もあります。例えばWinnyは、2chが無ければ存在しなかったと言えるでしょう。技術的には大きな進歩でしたが、著作権とセキュリティの問題を拡大しました。2chは一種のカオスです。　良い点は、事実上日本の全てのForumがここにあるので、ほとんど全ての情報がここにあります、監視し続けるとニュースを素早く取得できます。　悪い点はシステムが非常にシンプルで、全ての情報が時系列でフラットに流れて行く事です。ForumというよりIRCだと思うかも知れません。実際、 IRCのように会話を楽しむ人も居ます。 URLはここですが、ガイドへのリンクは既に流れています。 http://pc8.2ch.net/test/read.cgi/avi/1164192957/ 　2ch はあまりにも巨大で情報が豊富なため、非常に有益なデータベースと看做す人も居ます。しかし、自分のようなど素人が有用な情報を探すにはノイズ情報が多すぎると考えています。個々の発言は非常に短く、断片的で、信頼性をポインタで判断する事も困難です。これが、自分がguide-writerに関心を持つ理由です。　既にご存知かもしれませんが、こことか。
Zero 1	Still, the good thing about MP4 is interoperability, so at least Mac users can watch the videos I encode :)	それとやはり、MP4の良いところは互換性だ。少なくともMac Userは自分がエンコードしたものを見られるからね:)
Ageha	I agree. but interoperability seems not perfect. Apple has a lot to do with High profiles. and MP4box seems to have a lot to do for MP4 Headers, and for me, MEncoder must be rewritten to handle B-frames correctly^^;.	まったくです。しかしながら、互換性は完璧なのものでは無いようです。AppleはHigh plofileをなんとかしなければなりませんし、MP4boxはMP4ヘッダをなんとかする必要がありそうです。個人的には、MEncoderはBフレームを正しく扱えるように書き直して欲しいです^^;。
Zero 1	I don't know if you are familiar with, or use IRC at all, but if you want to, you can usually contact me at #AMV on irc.zirc.org (port 6667).	あなたがIRCに慣れているか、またはそもそも使っているか解らないのだけれど、もし望むなら、#AMV on irc.zirc.org (port 6667)で私にコンタクトできる。
Ageha	I do not use IRC at all, but I will try in my spare time. this may take time^^;	私はIRCを使っていませんが、試してみます。少し時間がかかります ^^;
Zero 1	So I take it that you capture MPEG-2 broadcasts and encode them to H.264 + AAC in MP4. However when you say capture, do you mean by connecting a satellite receiver to an analog capture card, or do you have a satellite card where you can dump the MPEG-2 as it's streamed? Here in England we get digital TV through an antenna, so what I do is dump the MPEG-2 transport stream and use a Windows program called Project X to demux the transport stream (I think Project X might be able to be compiled for Mac). The video quality here is so bad. It's usually 2 to 3mbps MPEG-2 for 544x576, 704x576 or 720x576 25fps video. Not only is the rate too low for good quality, but since a lot of TV programs are from America, we get crappy conversions. I believe they tend to IVTC the 29.97fps NTSC stream (to give 23.976), then speed it up! This changes the audio's pitch too... Then they upscale the video, or leave big black borders. It's really bad quality.	私は、あなたが MPEG-2 放送をキャプチャして H.264 + AAC in MP4にエンコードしていると理解した。しかしながらあなたの言う「キャプチャ」とは衛星放送のレシーバをアナログキャプチャカードに繋いでいるという意味だろうか、それともMPEG-2放送をそのままダンプできる衛星カードを持っているという意味だろうか。ここ英国では、digital TVはアンテナを経由している。従って私はMPEG-2 transport streamをダンプして、Project XというWindowsソフトを使ってTSをdemuxしている（Project X は Macでコンパイルできると思う）。映像の品質はこちらでは酷いものだ。一般的に、544x576, 704x576 または 720x576の 25fps （＊PAL＊）、MPEG-2 videoのビットレートは2から3Mbpsだ。画質の問題はbitrateが低過ぎるだけではない。TV番組はアメリカから来たものが多いから酷い変換を経由している。私は彼らは29.97fps NTSC streamを23.976fpsに逆テレシネ（＊IVTC＊）して、それから（＊PALの25.000fpsに＊）早回ししているに違いないと信じている！音声ピッチも変わってしまう、、、さらにそこから映像を拡大したり、大きな黒帯をそのまま放送したり、ほんとうに酷い画質だ。
Ageha	Here in Japan, Digital TV broadcasts are strictly protected by DRM. you have to send personal informations to even watch it (In my opinion, JAPAN is not North Korea :) . It's MPEG-2 TS @ 1080i (no 720p), fps is NTSC, up to 15Mbps or so. NOT enough. many people reports that they see block-noises. You can record TV shows to DRM-ready-Settopbox with harddisc. and MOVE - ONLY - ONCE to Special blank DVD disc. no copy, no back up, chance is only once, in case of error during MOVE, data will be lost. to see this DVD on windows, you need to buy DRM-ready softwares (no way for Mac^^;). usability is deteriorated. TV broadcasters seems too much precautious for P2P. some Windows users seems to use analog caputure cards. However, wide screen and noise-free is attractive, Digital TV and DRM-ready Settopboxes are Big Hit of the year. and analog TV broadcasts is due to end in 2011, there is a time. So, what I "capture" is ANALOG TV broadcasts, via MPEG-2 encoding box (there's only one choice on Mac). May be I could try MPlayer's TV grab options or something else, but the thing is drivers drivers drivers ;) My MPEG-2 encoding box can record TV Shows to Harddisc of my mac. max is 720x480@15Mbps(MPEG-2 PS), but usually I use 720x480@VBR9.5Mbps (max 15Mbps). with MPEG-1 Layer 2 audio. due to limitations of real-time MPEG-2 encoding, sometimes I see blocknoise in High-motions. and also analog noises. Hardware connections are like this: [antenna] - [MPEG-2 encoding box] - USB - [Mac(PowerPC )] and softwere chain to encode is: 0) Capty TV (for Recording MPEG-2 PS, bundle of encodingbox) 1) MPEGstreamclip(for CM edit, QuickTime-base) 2) MEncoder (for rawvideo.264. build from src, with x264. mpeg2 decoding seems to have some bug, can't drop delay-frames, can't handle PTS/DTS) 3) ffmpeg (for faac.mp4. from ffmpegX, little bit old one) 4) MP4box (mux. also from ffmpegX, little bit old one) Basic encoding settings are 640x480@1024kbps, 640x480 is from I only see those on Mac. 1024 is from that x264's main target bitrate seems around 1000kbps for VGA. I think my MP4's are not MP4 compliant. although VLC/MPlayer OSX/QuickTime Player 7 with avcDecoder 0.5.0 may decode them. MEncoder Document says never try PAL-DVD to NTSC fps conversion, they say just get original NTSC-DVD. so I think NTSC-PAL conversion is very hard work. I found some unique frames in 2006 worldcup football games in germany. may be that was a PAL-NTSC conversion. It was very strange. Sometimes they broadcast some BBC programs, next time I will try "capture".	日本のデジタル放送は強力なDRM保護がかかっています。単に視聴するためだけでも、個人情報の登録が必要です（私の意見では、日本と北朝鮮は別の国です）。放送形式はMPEG-2 TS @ 1080i(720pは有りません)、fpsは NTSC、最大で15Mbps程度。充分ではありません。多くの人がブロックノイズが見えると言っています。DRM対応のハードディスク付きセットトップボックスで番組録画ができます。そしてDRM対応のブランクDVDに一回だけ「ムーブ」できます。コピー不可、バックアップ不可。チャンスは一度きりで、「ムーブ」の途中でエラーが出たら、データは消滅します。そしてwindowsでそうしたDVDを見るには、DRM対応のソフトウェアが必要です（Mac では手が無い^^;）。使い勝手の退化です。放送事業者は過剰にP2Pを警戒しているようです。Windowsでこれらの番組を録画する人は、アナログキャプチャカードを使っているようです。しかしながら、ワイドスクリーンとアナログノイズが無い事は魅力的でデジタルTVとDRM対応ハードディスクレコーダは今年のヒット商品です。アナログTV放送は2011に終了する予定ですが、やや時間があります。　ですから、自分が「キャプチャ」しているのは、外付けのMPEG-2エンコーダ経由のアナログTV放送です（Macには一つだけ選択肢があります）。もしかしたらMPlayerのTV grab オプションなどが試せるかもしれないけど、問題はドライバ、ドライバ、ドライバ、です。　私のMPEG-2 encoding boxは、最大で720x480@15MbpsでMacのハードディスクに録画できますが、常用設定は720x480@9.5MbpsのVBR （max15Mbps）、音声はMPEG-1 Layer 2。リアルタイムエンコードの限界により、ブロックノイズが出る事があります。アナログノイズも不可避です。　ハードウェア接続は以下の通り：　　[antenna] - [MPEG-2 encoding box] - USB - [Mac(PowerPC )] 　エンコードに関わるソフトウェアは以下の通り：　0) Capty TV (MPEG-2 PS録画用、encoding boxのバンドル) 　1) MPEGstreamclip（CM 編集用、QuickTimeベース）　2) MEncoder （rawvideo.264書き出し用。ソースからx264と共にビルド。mpeg2デコードに問題ある模様、delay-frameドロップ不能、 PTS/DTS取り扱い不能）　3) ffmpeg （faac.mp4書き出し用。ffmpegXから抽出。やや古い）　4) MP4box （mux用。これもffmpegXから抽出。やや古い）　基本的な設定は 640x480@1024kbpsです。640x480 はMacでしか見ないので。1024 はx264のVGAにおけるメインターゲットビットレートが概ね1000kbps であるように見えるからです。手許で作ったMP4は、MP4規格準拠ではないと考えています。VLC/MPlayer/QuickTime Player + avcDecoder 0.5.0でデコードは可能ですが。　MEncoder DocumentはPAL-DVDをNTSC変換するくらいならオリジナルのNTSC-DVDを買えと言っていますから、たぶんNTSC-PAL変換は大変なのでしょう。ドイツの2006 ワールドカップサッカーで変わったフレームを見ました。あれがPAL-NTSC変換だったのかもしれません。非常に奇妙なフレームでした。日本でも時折 BBCの番組を放送するので、次に放送があったら録画してみます。
Zero 1	The other method I'm unsure about, I would have said they speed up the 29.97fps to 30fps and decimate to get 25fps, but a lot of the shows I've seen that seem to use this method are pure interlaced. It's horrible. Since it's so bad I just don't encode them. I mux the MPEG-2 video and MPEG-1 Layer 2 audio to MP4 using MP4box. Seeing as these files are spec compliant though, I suppose I could mux them to MPG or VOB and make a DVD.	もうひとつよくわからないメソッドがある。先に彼らは29.97fps を 30fpsに早回ししてそれから25fpsに落としていると書いたが、私がみた番組の中にはpure インターレースドがとても多い。滅茶苦茶だ。あまりに酷いので私はそれらをエンコードしない。そのままMPEG-2 video と MPEG-1 Layer 2 audio をMP4boxでMP4にmuxしてしまう。こうしたファイルは規格に適合しているようではあるがMPG か VOB にmuxして DVDにしてしまおうかとも思う。
Ageha	That sounds horrible to me too. they must be so busy ^^; Although I'm keeping away from optical discs (cause I'm confident about breaking or lost them). With MPEGstreamclip, may be you can mux them to MPG or VOB and make a DVD. its made in italy, and seems to made for EU people who wants to do that ( MPEG2-TS to VOB ). works on Windows too. but I'm sure you can find better one^^;	それは酷そうです。きっとすごく忙しいのでしょう^^; 私は光学ディスクに触らないようにしていますが（絶対割る。または失くす）。そうした番組はMPEGstreamclipでMPG やVOBにして、DVDにできるかもしれません。イタリア製で、まさにその目的( MPEG2-TS to VOB )を持ったEUの人向けのソフトのようです。Windows版もあります。もっとも他にもっと良い手があると思いますが^^;
Zero 1	Anyway, I also plan to write the MP4box guide and will write a short bit about encoding AAC in Nero CLI or iTunes (but the thing is trying to motivate myself to do it!) Merry Christmas to you also. See you later :)	まともかく、私はMP4box guideを書く計画を持っていて、AAC を Nero CLI か iTunesでエンコードする方法についても少し書く計画も持っている（問題はやる気だ！）。あなたにもメリークリスマス。またね :)
Ageha	FYI: 　This blog has a CATEGORY "MP4box" . although in Japanese. 　Also in in Japanese. I found a blog about How to make Variable Frame Rate .MP4. and he use Windows! 　　http://d.hatena.ne.jp/zmi/ See you!	FYI: 　このブログのMP4box情報はカテゴリ「MP4box」にあります。日本語ですが。　これも日本語ですが、Variable Frame Rate .MP4の作成については下記のブログが詳しいようです。Windowsの人だよ！。　　 http://d.hatena.ne.jp/zmi/ See you!

[ 2006/12/18 23:06 ] INBOX　未分類 | TB(0) | CM(2)

映画界の呼称

スクリーン・サイズの種類と縦横比（アスペクト比）：りおなのVIVA!WIDESCREENより作成。

名称	縦x横	備考
スタンダード	1×1.37	35mm写真フィルムとほぼ同じ。TVもこれに倣った。
不詳	1×1.2	ほぼ正方形。トーキーの音声をフィルム上に収録するため、ちょっと映像を削った。不評で消えた。
ヨーロッパ・ビスタ	1×1.66	フランス映画に多い。
アメリカン・ビスタ	1×1.85	シネマスコープを除くほとんどのアメリカ映画。日本、イギリス、イタリア映画にも多い。
マスキングビスタ	1×1.66～1×1.85	35mm（スタンダード・サイズ）フィルムでの撮影または上映時に上下にマスクをかける。純正のビスタビジョンと区別するため“ビスタサイズ”と言う。 1960年代のフィルムの品質向上で実用化。 1980年代のビデオ普及により、撮影はスタンダード、上映はマスキングビスタが主流となる。
シネマスコープ	1×2.35	基準は1×2.35だが、通常は 1×2以上のアスペクト比を「スコープ・サイズ」と呼ぶ。撮影は専用のアナモルフィック・レンズか、スーパー 35方式（マスキングビスタ的なもの）を使う。

　4: 3なら1.33だし、16:9は1.78だ。勘定が合わない。「なんですかこれわ？」という数字だらけ。恐るべし映画百年の歴史。
　これら多彩な縦横比をどうやってデジタルの世界に持って来るか。

　DVD（と言うかMPEG-2のMain Profile @ Main Level）の720x480はアスペクト比1.5。表の中のどれにも合わない。
　なぜこれを採用したかは知らないが、720x480の画素数は僅か34万5,600画素。恐らくは、規格制定当時、ご家庭で買える範囲のお値段で再生機を作るには35万画素を30fpsで動かす程度が限界と予想された、という事だろう。画素数とfpsがCPUパワーとバッファメモリ搭載量に直結するからだ（MPEG規格は半導体の価格動向予測も考慮して決める）。
　だから、まず画素数とfps。次に、どのアスペクト比の映画でも、720x480を有効に使いきる、仕組み。
　例えばデータ上の解像度（サンプル数）は720x480 で固定しておいて、表示上のアスペクトは別に指定してやる。など。これならどのアスペクト比の映画でも、720x480を無駄なく使いきれる。画質最優先ならどのアスペクトに対しても個別に最適な縦横のピクセル数を決めるべきだが、家庭用DVDプレイヤでそこまでカヴァーするのは無謀だったという事だろう。

DAR とPARとSAR

名称	種別	対応規格	根拠
DAR Display Aspect Ratio ディスプレイ・アスペクト・レシオ	画面表示のアスペクト比。	MPEG-1/2/4	MEncoder 　- mpegoptsのvaspect=<1 \| 4/3 \| 16/9 \| 221/100> 　-xvidencopts のaspect=<x/y \| f (float value)>
PAR Pixel Aspect Ratio ピクセル・アスペクト・レシオ	ピクセルのアスペクト比。	MPEG-4 ASP?	MEncoder 　-xvidencoptsのpar=<mode> 　DAR = PAR * (width/height)。
SAR Sample Aspect Ratio サンプル・アスペクト・レシオ	ピクセルのアスペクト比。	MPEG-4 AVC	x264cli 　Input/Output:の --sar ※ 規格上はVideo Usability Info (Annex E):だが、ここではcore:54 svn-611M --longhelpに従った。 MEncoder -x264encoptsには見当たらない。

　アスペクト比はスクリーン（画面全体）で指定するものと、ピクセル単位で指定するものの２種類がある。PARとSARは、規格上の呼び方が違うだけで同じものだろう。手許では実際に-xvidencoptsのpar=<mode>を使った事は無いが、modeには ntsc169 や pal43 などのプリセットを入れる。ここに ext と入れると、par_width=<1-255> や par_height=<1-255> で独自の縦横比を指定する事ができるようだ。恐らくは、これがSAR。

一般的な SAR:

x264cli のSARは「8:9」のような書式で指定するようだ。-xvidencoptsの書式で書くと、par_width:par_height に相当するだろう。
DAR= (par_width / par_height) * (width/height)

Encoding H.264 using the x264 Command Line Interface（Zero 1氏）の一般的な SAR表から作成。

素材解像度	DAR		SAR（PAR_W : PAR_H）
素材解像度	一般名（縦横比など）	少数表記（高さを1とした時の横幅）	PAR_W	PAR_H
720x480 (NTSC)	4:3	1.33	8	9
	16:9	1.77(*1)	32	27
	アメリカン・ビスタ(*2)	1.85	100	81
	シネスコ	2.35	69	44
704x480 (NTSC Crop)	4:3	1.33	10	11
	16:9	1.77(*1)	40	33
	アメリカン・ビスタ(*2)	1.85	125	99
	シネスコ	2.35	85	53
720x576 (PAL)	4:3	1.33	16	15
	16:9	1.77(*1)	64	45
	アメリカン・ビスタ(*2)	1.85	40	27
	シネスコ	2.35	32	17
704x576 (PAL Crop)	4:3	1.33	12	11
	16:9	1.77(*1)	16	11
	アメリカン・ビスタ(*2)	1.85	50	33
	シネスコ	2.35	102	53

*１） (PAR_W/PAR_H)*(width/height)で計算すると16:9は1.78になる。
*２）大半とは言いませんが、多くのワイドスクリーンDVDは、厳密には16：9ではなく、1.85:1 か 2.35:1 (シネスコープ)。これは、映像の中にクロップすべき黒帯が含まれていると言う事になります。MEncoder Documents/DVD映像を高画質なMPEG-4 ("DivX")にする方法より。従って16:9とは各種ビスタやシネスコを包含する汎用比と思われる。

　なお、『改訂版 H.264/AVC 教科書』を見ると、VUI（ビデオ表示パラメータ、309ページ）の項に、aspect_ratio_idc、sar_width、sar_height、というものがあった。aspect_ratio_idcはプリセット。0は定義無し、1は1:1、2は12:11、、、という具合。13まである。14～254 はreserved（将来の拡張用）。ここが255だったら、
sar_width、sar_heightの値からSARを計算する。とある。
　上の表の「一般的なSAR」は16通りある事から、x264cliの--sarオプションは、sar_width、 sar_heightを入力するものと思われる。

なぜx264にDARが無いのか。

DARがありゃ便利なのにと思うのだが、どうもH.264/AVC規格にも無いらしい。例えば、H.264/AVC規格概要：レベルにある以下の記述。

規格上、Levelが規定する最大フレームサイズとは、pixel/frameの合計数だけだ。水平・垂直それぞれの最大サイズは、Sqrt （maximum frame size * 8）以下でなければならない事を除けば規格には無い。

　もしもAVCのレベルにフレームの縦横は720x480といった規定が無く、制限は1フレームあたりのピクセル数だけで、かつ、ピクセルに縦横比情報を持たせる事ができるのなら、ヨーロッパ・ビスタだろうがアメリカン・ビスタだろうがマスキングビスタだろうがシネスコだろうがそれ以外の変形素材だろうが、オリジナルのフィルムから起こす場合に限っては、もうちょっとだけ、素材に忠実な解像度で作る事ができそうだ。それなら、MPEG-4 ASPの"PAR"の名称を変える必要性が納得できる。
　あと、4kシネマ（4,096×2,160ドット）とか2kシネマ（2,048×1,080ドット）とかも睨んでるのかもしれないなと思った。

AVIと QuickTimeとMPEG規格

MEncoderはAVIヘッダにアスペクトを書き込む事ができる。しかしそれをちゃんと解釈できるのはMPlayerくらいらしい。オプションにある通り、rawvideo.xvidにDARやPARを埋め込む事もできる。しかしこれも、AVIコンテナではちゃんと解釈できるのはMPlayerくらいらしい。DARやPARは.MP4コンテナが安全だろう。

　一方、QuickTimeはコンテナにはアスペクトヘッダを埋め込め、正しい解釈もできる筈だが、インフラ全般に渡って映像データと付加情報は分離すべし、という一貫した思想がある（オブジェクト指向）。これはかなり徹底したもので「アスペクト情報を持った映像ストリーム」に対応困難らしい。結果的に.MP4であっても、SAR指定の入ったH.264サポートをQuickTimeコンポーネントとして実装するのは難しいようだ（考察：SARとQT（My cometG3））。
　Appleが国際標準規格の推進をアピールするのは自由だが、Apple - h.264 だけが H.264/AVCであるかのような印象操作は不愉快だ。

　MPEG （Motion Pictures Expert Group）規格はその名の通り、動画に関する規格だ。.MP4はAppleの.movベース（Appleが唯一MPEGに提供しているパテント）とはいえ、発想は異なる。上位団体はISO（International Organization for Standardization、国際標準化機構）と仰々しいがなんのことは無い。JISだJIS。「2Bの鉛筆」とか「単３の乾電池」とか「M３のボルト」などと本質的な違いは無い。ISO-MPEGの仕事は「産業界における汎用的な実用性を持った規格を定める事」だ。ひらたく言えば妥協がお仕事。できるだけ高いレベルで。

　手許ではSARを使わずにスケーリングしてしまうが、過去に720x480のMPEG-2PS（TVキャプチャ）の黒帯を、16:9にするべくcropして、スケーリングを間違えて640x480でエンコードした事がある（ソルティレイ#01 オーロラの降る街）。

-vf pullup,softskip,crop=702:352:8:64,scale=640:480,hqdn3d=2:1:4,pp=l5,harddup

記録が残っていないがSARもPARも滅茶苦茶なハズだ。


QT Player + avcdecoder 0.5.1	VLC 0.8.6	MPlayer OSX 1.0 pre 8

　これを正しいアスペクトで表示できる方が狂っているのだが、なぜかこうなった。
　QT Playerは素直に640x480。VLCとMPlayer OSX 1.0は、縦480を軸に、横幅を852に拡大している。当時（2005/10月）はMain profileで作っていたので、素のQT7（Apple-H.264）でもこうだった。偶然に正しいSARにでもなったのだろうか。

　ところでこのファイルは「こんなこともあろうかと」取って置いたというわけでは無く、何気なくme=ext、me_range=64を試して122時間 34分49秒かかった後に、やり直す気力が残ってなかっただけです^^;。

余談：
　なにげなくISOのスペルを辞書でひいたらこういうものがあった。

ISO standard cup of tea : ISOで決められた「標準紅茶」。
ISO 0（砂糖を入れないミルク紅茶）。
ISO 2（砂糖を2スプーン入れたミルク紅茶）。

冗談かと思ったら、本物でした。ISOで規格書も売っている。紅茶好きの間では有名な話らしく「ISO 3103:1980」で検索するとちょっと大変な事になっている。イギリス人め！安倍政権はISO国際標準すし規格の策定に全力を注ぐべきだ。

[ 2006/12/20 01:00 ] 動画　動画全般 | TB(0) | CM(0)

snowとはなんぞや

　snowとは、H.264/AVC よりも先進的な原理を使う動画コデック。libavcodecの一つ。ffmpeg/mencoderで試用できる。例えばMEncoder -lavcoptsから使う場合は vcodec=snow。FFmpeg's experimental wavelet-based codecと説明されている。手許（PowerPC G5 2Ghz x2）ではエンコードも重いが、特にデコードで激しい重さを感じた。

特徴１： Wavelet
　MPEG -1/2/4は基本的にDCT（Discrete Cosine Transform、離散コサイン変換、離散とはとびとびの値の意）を使う。H.264/AVCも同様。それ以上は理解できていないが、圧縮符号化技術としては1980年代に実用的になったもので、基礎研究レベルでは90年代初頭からDWT（Discrete Wavelet Transform、離散ウェーブレット変換）なる手法が盛ん。と、立ち読みしたJPEG2000の規格書に書いてあった。

　JPEG2000 はMacでは標準で扱える。手許で扱う画像はwebの画像を拾うかせいぜいデジカメくらいだが、その程度では画質もファイルサイズもJPEGとそんなに違わない気がする。そのわりには取り扱いがはっきりと重い。Winでは別途コデックが必要らしく普及していない（『槻ノ木隆のBBっとWORDS その90「JPEGの特徴」』）。

特徴２： overlapped block motion compensation
　SNOWのもう一つの特徴はマクロブロックの切り方。正式な和名が解らないが、取りあえずオーバーラップド・ブロック・ベースの動き補償。
　MPEG 系がマクロブロックをピクセルが重複しないようぴっちり切り分けるのに対し、SNOWはマクロブロックの端っこが重なるように切り分ける。境界線上のピクセルは複数のマクロブロックに所属する事になる。例えばMEncoder -lavcoptsにはobmcというオプションがあり、 overlapped block motion compensation (H.263+)と説明されている。
　根本的にブロックノイズがほとんど出ないという利点があるが、端っこピクセルはブロックノイズが出る可能性があろうがなかろうが何度も処理される事になる。やはりこれも重そうだ。

　wavelet にせよOBMCにせよどちらも計算負荷が高いようだ。H.264/AVCの規格策定段階について述べた文章にはDCT以外の手法を採用するメリットは今のところはまだ無いという言い回しがあるし、OBMCで全てのマクロブロック境界を処理するよりは、インライン・デブロッカでブロックが出た箇所だけ潰すほうがなにかと安上がりに思える。このどちらもH.264/AVC規格には存在しない。SNOWはかなり深いレベルで AVCよりも先進的、または異質なコデックだ。

※なお、通信動画規格H.263の短期的改善を計ったのがH.263+。いわばザクとザクII。
これとは別チームで長期的改善を目指したのがH.26L。後のITU-T H.264、別名MPEG-4 AVCである。いわばドム。
だからまぁ、異質な新技術を突っ込んでるSNOWはさらにその先を目指す、、、いわばサイコミュ搭載試験型。お好きな方にはたまらないタイプ。
（一気にエルメスやジオングができるわけではない。途中でザクレロとかある。足なんて飾りですと言ったってそれが解らない人は足があるほうを好むわけだし。キュベレイまで７年くらいは、、、なにデンドロビウム？あれはオーパーツだっつうの）

OBMCについて（妖精現実- 2006年3月のメモからコピペ）

OBMCについて

具体的な実装の細部までは分かりませんが、概念的にはだいたいこういうことだそうです。

DivX、XviDなどの動画で、ビットレートが足らないときなど、もともとそんなものはないのに、マス目状の線が出てしまうのは、よく見かけると思います。ブロック単位に分割してから各ブロックを処理しているので、ブロックの中身をきめ細かにしてとなりのブロックと滑らかにつながるようにできるだけの情報量がないと、ブロックの境界の線が目立ってしまうわけです。

MPEG-1ではブロックのサイズが固定（のっぺりしていておおざっぱに切ればいいところも同じに切るし、複雑なところで繊細に処理してほしいところでも細かく切ってくれない）なのですが、新しいコーデックでは、ブロックサイズを都合に合わせて動的に変えたり、長方形にしたり…と、これはx264 （AVC）のユーザなら、設定の検索オプションのところで、いっぱい種類があるのをよくご存知と思います。

しかし、可変ブロックであっても、ブロック境界があることには変わりないので、効率は上がったとはいえ、原理的にブロックノイズが回避できているわけでは全然ないわけです。

AVCやWMVやRV10では、それを緩和するために、インループ・フィルターをかけています。特にRV10ではインループが明示的に設定できるので、気が付いた方も多いと思いますが、自分がエンコードした結果を自分で（エンコード中に）デコードしてみて、ブロックノイズの原因になる誤差が蓄積していないか確認し、必要に応じて補正をかけるわけです。 AviUtlなどのノイズフィルターなどは、コーデックに行く前にかけるプレフィルターですし、 ffdshowなどの後処理はコーデックから出てきたデコード結果を調整するものですが、インループは前でも後でもなくコーデック自体の中でかけているフィルターです。

しかし、このデブロッキングというのは、案外、実写とは相性が悪いです。ブロックノイズが出ない代わり、繊細なテクスチャー、人の肌のきめなどがツルンとしてしまいます。ただ、たいていのアニメでは、もともとツルンとしているので、この（本来は欠点の）性質がかえってランダムノイズを消して、良い感じになってくれます。実際、ソースのノイズがデブロッキングの副作用（副作用の副作用？）で勝手に消えてくれることさえあります。とはいえ、自分で発生させたブロック境界を消すための補正情報にレートを回すのは、巧妙ですが、本質的には無駄です。自分でノイズを作っておいて、それの消し方をコーディングするわけですので。最初からブロック境界がなければそういう二度手間にならず、自分で汚したものを直すのに必要な情報量を、本質的なテクスチャーに回すことができます。

で、SNOWが実装したOBMCですが、 OBMCは、本当はh263にも規格上はあったそうなのですが、実際には使われなかったようです。 GMC同様h264では規格から外されてしまいました。

名前のとおり、オーバーラップしたブロックの動き補償です。碁盤の目のようにきっちり切るのでなく、各ブロックが少しずつ（上下左右斜めの8方向とも）重なって定義されています。言い換えれば、古典的な切り方での境界付近のピクセルは、実は両側のブロックに属しているわけです。一般に、各ピクセルは4ブロック（実装によっては3ブロック）に同時に属し、それらの加重平均をとることで、区切りの線が目立たず「とろんと」滑らかになります。段差ができる原因が最初から回避されているわけです。段差を補正するインループ回路も確かに巧妙で効果的ですが、最初から段差ができないようなブロックを重ね合わせた取り方、というのは本質的に素晴らしい発想でしょう。ただ、一つのマクロの動きを何重にもコーディングして、デコードのときにも重ね合わせて平均をとるので、計算量（CPU負荷）の問題はありますが、まあ、少し未来にはハードが発達して何とかなるのではないでしょうか。

「波」の重なりで図形を表すウェーブレットも、そうした従来型のアーティファクトを克服するのに貢献するはずです。まあ、これも計算量が大変そうですが…。

開発者の方から説明してもらったことを生半可な理解で受け売りしているのでちょっと（かなり）間違ってるかもしれませんが、あの SNOWの「とろん」とした雰囲気と異様な美しさは、だいたいそんなような感じ…らしいです。そして、その計算がたいへんというのは、計算量が多くてもリニアの計算なので、 GPUでハード的に実装するのは原理的には簡単らしいです。そうすればCPU負荷も問題にならないはずです。

[ 2006/12/24 00:00 ] ごみ箱　未分類 | TB(0) | CM(0)

LINK: Lair Of The Multimedia Guru

Lair Of The Multimedia Guru
知った場所：MEncoder Documents / How to deal with telecine and interlacing within NTSC DVDs

　タイトルは、マルチメディア導師の隠家？どうもここがMichael's Niedermayerさんのブログであるらしい。ffmpeg、MPlayer、なかんずくSNOWのキーマン。てゆうかlibavcodecのキーマン。プログラミングのできない自分には何が書いてあるやらまるで理解出来ない。

　歯が立ちそうなのはこの記事くらい、、、と思ったけどやっぱ歯が立ちませんでした。

2006/06/09

Deinterlacing filters

　ここでは様々なインターレース解除フィルタの比較をしてみます。インターレースド素材は有名な foreman video（*1）からmplayerの phase=t および tinterlace=1 フィルタを使って作成しました。
　実験結果の映像はすべてmplayer -vo pnm と ppmtojpg --optimize --quality 90 で出力したものです。-vo jpegを使わなかったのはコンパイルしてなかったから。あと、-vo jpegは RGB 入力しか受け付けないから。ここではとくに使うメリットが無いです。
　インターレース解除フィルタの多くは2フィールド毎に合成して1フレームを出力するだけです。実際、常に偶数フィールドを選ぶものもあれば、常に奇数フィールドを選ぶものもあり、さらに奇数偶数の区別なく、常に1stフィールドを選ぶものありといった具合です。おかげで、この比較テストは期待したほど面白くはありませんでした。この問題から、フィルタの中には垂直反転した映像を流し込んでやる必要があるものがありました (pp=ci and kerndeint IIRC) 。さらにtomsmocompは -vf phase=b を使わなければ正確なフィールドに基づくフレームを出力できませんでした。そしてもちろん、top / bottom field first flag の指定ができるフィルタは正しく設定してあります。

＊以後、図は原文を参照。ここではmplayerのyadif、mcdeintに限る。

mplayer -vf yadif=1:1

1フィールドを1フレームで出力：ボトムフィールド1st
唇の端に僅かなジャギ。また左上、ジーメンスの文字がボロボロ。

mplayer -vf yadif=3:1

1フィールドを1フレームで出力・但し空間軸インターレースチェック抜き：ボトムフィールド1st
左上、ジーメンスの文字はキレイだが、指先がジャギジャギ。

mplayer -vf yadif=1:1,mcdeint=2:1:10

低速, 反復動き予測：おそらくボトムフィールド1st：qp
mcdeintのフィールドオーダーは、manには0か1とあるのみでどっちがどっちか書いてない。また自動検出も無い。
唇の端のジャギ緩和。また左上、ジーメンスの文字がやや復元。

mplayer -vf yadif=3:1,mcdeint=2:1:10

最もオリジナルに近いが、ジーメンスの文字がyadif=3:1 より劣化。

＊手許常用はyadif=0。Output 1 frame for each frame、フィールドオーダーはオート。特に落語で唇やまぶたのジャギが地味に目立つ。ズームも地味にジャギる。TV放送のフィールドオーダーはランダムに切り替わるようだから、手許ではこのコマンドそのままとは行かないが、yadif単体よりyadif,mcdeintのコンボの方が優秀なのか。

Comments

名前	コメント試訳	メモ
1.RC 06/06/11@ 9:21	静止画での比較は適切ではない。デインターレーサは動かしてみて動き回るエッジのジャギを見なければ正しい評価はできない。
2. mean 06/06/18@ 18:27	mcdeint に関しては、avcodec_close/free missing in the uninit part（＊不詳＊）があるかも知れない。
3.Michael 06/06/19@ 10:17	それはもう無い、たった今avcodec_close()を追加した
4. Sigdrak 06/06/19@ 17:01	Interesting results for yadif. What litterature have you checked on edge-directed interpolation that led you to this? Speaking of the implementation, I notice that there are such statements as: 1) if((y ^ parity) & 1) 2) uint8_t prev2= (tff ^ parity) ? prev : cur ; 3) uint8_t next2= (tff ^ parity) ? cur : next; inside of the loops. While I believe that nowadays CPU’s branch prediction will optimize it, couldn't it be made “cleaner”? (”patch welcome” is the reply I expect from you)	エッジを重点的に補間する手法？
5.Sigdrak 06/06/19@ 17:03	最適化の問題は気にしないで。既にテストしたでしょうから。恐らく register pressure （＊不詳＊）のほうが重要です。
6. Michael 06/06/19@ 23:55	edge-directed interpolation related litrature（＊重点的エッジ補間に関する文献？＊）は1年ほど何も読んでいない。随分前に少し読んだ。正確には覚えていないし、現在のyadif がやっている事がとの類似がどの程度かも知らない。しかし、一般的な補間ではないデインターレーシングに関する文献は、オンラインでフリーのものは１、２個しかないので（この事は確信してる）。いつもは他の文献を読んでいない。もしかしたらciteseerがなにか見つけているかもしれない、、、。 tomsmocomp もなにかのdirectional interpolation code を使っているようだ。知ったのはyadifを書いた後だったが、、、。そして、時間軸と空間軸のpredictors（＊予測子？＊）を混ぜるのは完全に自分のアイデアだ。最適化については、yadif と mcdeint はまだまだなのでパッチ歓迎。例えば、mmxでかなりの向上がある事は確実だ。 filter() も inline functionに変更できる（＊以下不詳＊）。 about optimizations, yadif and mcdeint are not really optimized and patches are always welcome, for example iam sure they could benefit alot from mmx filter() could also be changed to a inline function and called with “constant” tff and parity so that the compiler can optimize the related checks away while the source code would stay clean …	＊TomsMoComp：動き補償デインターレーサ。transcode、 AviSynthで使える。
7. compn 06/06/20@ 4:36	mplayer -vf lavcdeint が無いのはどうして？比較する価値が無い？dscaler deinterlace filterの事は知ってる？ http://dscaler.org/ あなたが libavfilter か libavmunge (as LAVF is taken by libavformat)を作るのはいつ？そして全プロジェクト(vlc, xine, mplayer, transcode, etc)のフィルタを統合してしまえば、みんな車輪の再発明を止めて、もっとスゴいフィルタに集中できるのに！	それが成立すればMac OSXはCore Video/QuickTimeに競合する「もうひとつの動画インフラ」を持つ事になる。プロダクションレベルならPhotoshopが必須だが、カジュアルユースならGimpで間に合う。
8. Michael 06/06/20@ 9:08	-vf lavcdeint は -vf pp=fd と同じだ。 dscaler については、linuxで簡単に使う手はあるだろうか？（qemuとかそういうのじゃなくて）。もし無いなら関心が無い。あればテストする、、、今のところ、libavfilterに取りかかるには私は怠惰すぎる/やる気がおきない。パッチは歓迎 :)。しかしながら、（＊以下不詳＊） its highly nontrivial if you want to allow all the speed related tricks like direct rendering and slices together with arbitrary filter graphs, and no 1 in = 1 out design.	不詳部分：例えばダイレクトレンダリングや自由なフィルタグラフのスライス、そして"非 1 in = 1 out デザイン"などの速度向上手法は非常に重要だ。 // 非VfW モデルはLinuxにも存在しない？
9. compn 06/06/20@ 14:22	dscalerはwindows only だと思う。でも誇大宣伝（＊過大評価？＊）が多いよ。
10. MuldeR 06/06/21@ 13:08	だれかmcdeintのしくみを説明してくれないか？自分の理解では、mcdeintより先にyadif=3を通さなきゃいけない。でもyadif=3の段階でフレームレート２倍のインタレ解除済みになる。であれば、その後でmcdeintを使う理由は何？既にインタレ解除済みの映像に対して mcdeintは何をするの？この時点でどんな向上があるの？どんな事でもいいです。教えて下さい。 mcdeintの情報はレアなので、、、
11. Michael 06/06/21@ 19:16	mcdeint は “missing” line を埋める為に動き予測と動き補償をやる。うまく動き予測をするには、元になる映像が要る。単純に奇数/偶数ラインを使う手も試したがうまくいかなかった。単純にフレームレートを倍増させるデインターレーサですら、mcdeintの後では向上が見られた。 mcdeint はオーバーラップド・ブロック・ベース（＊マクロブロック分割の際に、端っこをオーバーラップする。ブロックノイズ根絶手法＊）の動き予測と動き補償を使う。このコードはsnow codec（＊離散ウェーブレット変換、DWTを使う次世代コデック、H.264/AVCより重い＊）から持って来た。だから、snowに進展があれば自動的にmcdeintも進化する。 mcdeint=0 ：オーバーラップド・ブロック予測/補償を使わない。16×16 blockの 1/4 精度。 mcdeint= 1：8×8 blockサポートを追加、予測ゾーンサーチのダイヤモンド・サイズを拡大。 mcdeint=2 ：反復的オーバーラップド・ブロック・ベースの動き予測と動き補償 mcdeint=3 ：複数参照（＊multiple reference frames＊）を追加	笑った。x264より遅いわけだ。
12. MuldeR 06/06/21@ 20:18	お返事ありがとう！ mcdeintが“missing”ラインを埋めるというのは解った。でもyadif=3 の時点で既にmissingラインの無いフルフレームになる。mcdeintはどこを埋めるの？それとも奇数/偶数ラインを上書きする？それから、yadif=3,mcdeintはフレーム枚数を倍にする。だから（＊コマンドオプションの＊）フレームレートを手で修正しなきゃいけなくて、で、最終的にできあがりは２倍のfpsになる。mcdeintを使ってもTomsMoCompみたいにオリジナルのfpsを維持出来ないのかな？なにかオプションが要るのだろうか。 yadif=3,mcdeint,framestep=2.は、MEncoderでウマく動くみたいだ。でもCPUパワーがスゴく無駄になると思う（mcdeintが計算したフレームの半数をskipするから）。しかしながら、結果は面白い！唯一の問題はMPlayer では全く動作しないことだ。framestep=2があると映像がいったりきたりジャンプする（＊前後関係が変わる？＊）。
13. Michael 06/06/21@ 21:55	はい。上書きします。 mcdeintは前のデインターレースドフレーム（達）を動き予測/補償の参照フレームに使う。だからその計算をスキップはできない。そうしないと前のデインターレースドフレームが存在できないから。 mplayer -vf yadif,…,framestep=2 は動くようになった。
14.MuldeR 06/06/21@ 23:23	了解ちょうど長いエンコードが終わった。 mencoder -vf yadif=3,mcdeint=1,framestep=2 良い結果だ。僕のマシンでは凄く遅いが、、、動くようになった。とは最近直したと言う事？
15.MuldeR 06/06/25@ 16:52	最新のMPlayer build (2006-06-25)を試したら直ってなかった :-(
16. Michael 06/06/25@ 20:27	mplayer-svn r18781を。それが上のコメント時点での最新版
17.MuldeR 06/06/25@ 22:36	僕が使ったビルドはr18812だ。r18781で直ったのならそのままの筈だが、残念ながら直っていない、、、
18. Rich 06/08/02@ 8:00	MuldeR、インターレースド素材のオリジナル・フレームレートは倍の数だ。50とか60とか60000/1001とか。単に各フレームのライン数が半分なだけだ。フィールドをペアにして、一つのピクチャ上に交互配置してフレームレートを半減させるのは、それがコンピュータに保存されたときのやりかたで、オリジナルビデオの性質というものを考えると語弊がある。
19.JR 06/09/05 @ 12:26	yadif と mcdeint のコンボはmencoderで逆テレシネと同時にフィルタチェインに書いても使えるものだろうか（例えばNTSCからfilmへ[23.976 fps]）。 -vf yadif=3:1,mcdeint=2:1:10,framestep=2,filmdint=dint_thres=256,… -fps 30000/1001 -ofps 24000/1001 を試したが、結果は常に動きの早いシーンでのフレーム複製だった（dint_thres=256の効果でfilmdintはインタレ解除をしない。逆テレシネだけだ）。そして、私はこうした素材のどの- fpsを指定すれば良いのかまったく手がかりを持っていない。pullup, divtcなどの他の逆テレシネはまだ試していない。しかし結果が変わるかどうかあまり自信が無い、、、たすけて。
20. Justin 06/12/14@ 15:45	私は yadif=3:1,mcdeint=2:1:10,framestep=2 を試したが、ぴょこぴょことした不審な動きが出る（時折フレームの順番がおかしい）。使っているのはmencoder rc1だ。 -vf pullup,softskip,pp=lb も試したがこれは10～15倍も早いだけでなく、自分の見るところyadif,mcdeintの奇妙なダンスより良い（でもyadif,mcdent, framestepの苛つく動きを止める方法が見つかればまだ試すけど）。誰かmencoderのTomsMoComp相当のフィルタを知りませんか？たすけて。
21. Michael 06/12/14@ 17:39	もしもpullupなどの逆テレシネで “interlacing”アーティファクトが除去できたのなら、そのビデオはインターレースドではなくテレシネされたものだ。だからデインターレースの使用は可能でも、賢明でもない。もし -vf yadif=3:1 がうまくインターレースド・ビデオでうまくいかなければ -vf yadif=3:0 または -vf yadif=3を試して。 […] & gt;誰かmencoderのTomsMoComp相当のフィルタを知りませんか？ mencoderに TomsMoCompは無いです。transcodeを使って。	＊TomsMoComp：動き補償デインターレーサ。transcode、 AviSynthで使える。＊transcode：Linux、BSD、MacOSXで動くエンコーダ。コマンドライン、使い方はものすんごく簡単に見える。
22.Justin 06/12/15@ 13:50	素早い返事をありがとう。自分はキャプチャーカードからdumpしたNTSC-M 29.97 fps素材を使っている。場面がテレシネかインターレースドかは50/50のようだ。似たような事のあるはいないかい？自分は今、短いクリップで以下のような逆テレシネを試している。 -vf,pullup,softskip, etc そしてもしそれがjittery（＊神経過敏の＊）に見えたら、以下を試す。 yadif=3:1,mcdeint=2:1:10,framestep=2,filmdint=dint_thres=256 こちらのほうがかなり良い。どちらの場合でも出力は24000/1001 fps。というのは少しでも縮めたいのと、ほとんどの素材が23.97fpsに見えるからだ。これはアプローチとして正しいだろうか？

*1）動画圧縮の学術的な比較で良く見る映像。元々は2001年にMPEGが『この画像を圧縮してみな、MPEG-4 ASPよりスゴかったら採用してやらんこともないぞ？』と出したお題の一つ。Container Ship, News, Foreman, Tempete, Bus, Mobile Calender, Flower Garden、と言えば、そのスジの方は絵が浮かぶらしい。この7つのお題の圧縮大会で優勝したH.26LがH.264/AVC規格のひな形。なお、この実験の最大解像度は720x480、主観テスト（といっても統計的な精度補正を考えたもので、おいらがの感性では、などと言うのとはレベルが違う）の結果は、1MbpsのH.26Lは元画像と区別できない。512kbpsのH.26Lは1MbpsのMPEG-4と同等。手許の1024kbps固定は偶然だけども。ちなみにパテントリストには日本の大手家電がずらりと並んでいるので、2chには結構な情報が埋まっているハズだ。ドレがそうなのかってのはおいらには見極められんが。

[ 2006/12/25 00:00 ] 動画　動画全般 | TB(0) | CM(0)

mcdeint

　MEncoder で使えるインタレ解除としては間違いなく最高の部類。こうかはばつぐんだ。ただし、手許ではx264より遅く、実用には耐えない。
　インタレ解除のくせに8x8ブロックにqpelに複数参照まである。訳しながら笑ってしまった。ビグザムだビグザム。完成の暁には！（不吉）

▼説明

MEncoderマニュアルの説明
mcdeint=[mode[:parity[:qp]]]
動き補償デインターレーサ。
１フレームにつき１フィールドの入力が必要となるので、tfields=1 や yadif=1/3、または同等のものと一緒に使う必要がある。
<mode>
0: 高速
1: ミディアム
2: 低速, 反復動き予測
3: 超低速、複数参照フレームを２以上にしたのと同等。

<parity>
0 または1でどちらのフィールドを使うかを指定（note:自動検出はまだ無い！）

<qp>
高い値ほどモーションベクトルがスムースになるが、個々のベクトルは最適ではなくなる。

開発者、Michael's Niedermayerによる解説
mcdeint は “missing” line を埋める為に動き予測と動き補償をやる。
うまく動き予測をするには、元になる映像が要る。
単純に奇数/偶数ラインを使う手も試したがうまくいかなかった。単純にフレームレートを倍増させるデインターレーサですら、mcdeintの後では向上が見られた。

mcdeint はオーバーラップド・ブロック・ベースの動き予測と動き補償を使う。このコードはsnowのコードから持って来た。だから、snowに進展があれば自動的にmcdeintも進化する。

mcdeint=0 ：オーバーラップド・ブロック予測/補償を使わない。16×16 blockの 1/4精度。
mcdeint=1 ：8×8 blockサポートを追加、予測ゾーンサーチのダイヤモンド・サイズを拡大。
mcdeint=2 ：反復的オーバーラップド・ブロック・ベースの動き予測と動き補償
mcdeint=3 ：複数参照（＊multiple reference frames＊）を追加

Comment by Michael — June 21, 2006 @ 19:16

"missing" lineというのはこういう事だ。

　左は料理番組の冒頭でCGのタイトルが出るシーン。

　赤い球体が画面に侵入してくるが、図の通り縞がある。コマ送りで見ても縞の消える瞬間が無い。中華鍋を振る料理人の手も同様。どちらも1/60秒の間にこれだけ動いてると言う事だ。

　CG製作の時点でこうしたシマシマデータを作るわけが無いので（できなくは無いが無駄）、TV用に合成する段階で切り刻まれている。コックさんが「物理的にこういう手の人」だったという可能性も無くは無いが稀であろう。
　左図は59.95HzのTVカメラで撮ったインターレースド・フィールドを2枚、同時に表示している。

　もともとTVカメラの走査線は一本飛ばしで映像を捉える。空間軸画質を最初から大胆に間引いてあるのだ。パソコンの言い方で言うと、解像度が 720x480あったとしても、一枚のフィールド上の実データは720x240しか存在しない。もしも正確にフィールドだけを表示できるなら、ブラインド越しに見たような絵しかでてこないハズだ。これが上で言う"missing" lineの意味。

　インタレ解除の本質は「失われたデータの復元」ではなく「もともとこの世に存在しないデータのでっち上げ」。
　これに対して逆テレシネは「もともとのフィルム上にあったハズのデータだけを拾い集めてあとは捨てる」。
　ホントは別モノ。

　余談ながら、インターレースはもともとブラウン管の構造に則したしかけ。電子銃による管面走査機構のない機械に余分な機構を強いる。これは液晶、PDP、 SEDを問わない。高柳健次郎博士御存命なれば、地デジ規格は断然 1080p/720p@30fps以上を主張されたであろう。

▼基本的な使用例。

-vf yadif=3,mcdeint,framestep=2 -ofps [素材fps]

mcdeint が動き予測と動き補償をやるには元になる参照フレームが要る。そのときに、インターレ−スドを参照しても（現状では）うまく行かない。だから、mcdeintより先になんらかの「各フィールドをフレーム化するインタレ解除」をかけてやる必要がある。素材フレームレートを倍増するものなら何でも、実はインタレ解除でなくても効果があるが、開発者自身がyadifを使っているのでここではそれに倣う。
　yadif=1または3で1フィールド＝1フレーム（フレームレート２倍）となる。yadif=3は、空間軸のインターレース検出をスキップ。yadif=1はスキップしない。
　なお、ここではyadifのフィールドオーダ自動判定を使っている（デフォルトなので書かなくても、yadif=3:-1になる）。フィールドオーダの指定が素材と合わないと、後ろにあるべきフレームが前に来てしまうなど、出力フレームの時系列が前後する事があるようだ。これはTVキャプチャではフィールドオーダがランダムに切り替わるためらしい。やや古い経験になるが、手許でもfilmdint使用時、Bottom field first!というメッセージを見る事があった。経験上は30分番組で数十回程度。素材のフィールドオーダが確実に固定である場合は、yadif=x:1または 0でフィールドオーダを指定できる。
mcdeintは、yadif=3の出力結果を上書きする。この段階でもまだフレーム数は２倍。
mcdeintには（まだ）フィールドオーダーの自動判定が無いが、動作原理上、実装の優先度は低そうだ。
framestep=2は出力フレームを飛ばして2コマ置きにする。
例えば素材が30fpsならこれで倍増したフレームを半分捨てないと、出力フレーム数が 60fpsぶんになる。
従って、素材が30fpsなら-ofpsは30000/1001。

▼長所

　MEncoderで使えるインタレ解除フィルタの中では、抜群だ。

　理屈を読むとかなり無駄っぽい印象を受ける上にいーのかそれでという感じもあるが、フィールドを半分捨てるといってもフレーム内の大部分のデータは重複しているものだし、必要な部分は動き補償で（単純なブレンドなどでなく）出力されるフレームに加味されている。時間軸fps混在だの空間軸fps混在だのの厄介ごとを気にせず、とりあえず、オールラウンドに使っても相当の性能を発揮する。

　手許の実写は落語が多いので、細かい動きのジャギが気になりがちなのだけれど、yadif単独では地味に気になっていた唇の端っこのジャギやズーム時のちらつきなどが緩和した。

　なお、少なくとも動作原理上、pullupとの併用は無意味と考えられる。pullupは素材映像の中のテレシネパターンを頼りに元の film映像を復元するものだ。その後でyadif,mcdeintをかけると画質劣化のデメリットのほうが大きく、yadif,mcdeintの後ではテレシネパターンが残っていない。逆テレシネはテレシネ素材にしか効かず、逆テレシネが効くならインタレ解除は適切ではない。映画とアニメはpullup を軸にした方が良さげ。

▼短所

　桁違いに遅い。x264より重い。

　手許（Power PC G5, 2Ghzx2）では1分半のクリップに2時間以上。turbo使用の1stと、より重い2ndがきっちり1時間ずつと同じだったので、mcdeintが最大のボトルネック。CPU利用効率も激減していた。速度を計算すると0.0xfpsと文字通り桁違い。mcdeint を使うなら事前に中間生成物で吐くべきだろう。

　また、インタレ解除である以上は「もともとこの世に存在しないデータのでっち上げ」という限界があるのでpullupに比べれば印象はやはり落ちる。
　

▼現実的な妥協案

　MEncoder ユーザーメーリングリストでもyadif単独がいまのところ最も実用的なのではという意見が一般的なようだ。
　そこで、yadif=3でフィールドをフレーム化し、 framestep=2で半分捨てる手を軸に、間に挟む調整（前後フィールドから必要なデータを持って来る）にmcdeint以外のものを使う手はどうかと思った。例えば、

-vf yadif=3,pp=l5,framestep=2 -ofps [素材fps]

または、

-vf yadif=3,framestep=2,pp=l5 -ofps [素材fps]

　pp=l5に全フィールドを見させるなら前者。データの混合を実際に残るフレーム同士に限りたければ後者。
　なお、pp=l5を重用しているのはそれが最も優れているからというわけではないです。手許でビルドしたMEncoderではkerndeintやfilmdintがなんか動作が怪しいだけです。
　ちゃんと動作するなら、kerndeintのピンポイント縞除去や、filmdint=io=2997:2997にした上で、 dint_thresを調整した方が良いかも知れません（yadifの後ならテレシネパターンなど残っていないから、インタレ解除しか作動できないハズ）。

　気になる速度面ですが、やっぱ倍増しますなyadif単独にくらべると。-vfチェイン内だけとはいえ、書き出しフレーム数が倍増してるわけだし。一方面白い事にCPU利用効率がyadif単独の30fpsより上がりました。threads=4と一緒に使うとCPUメーターが天井に張り付きっぱなしの 185～195%になります。たぶんx264の処理速度といい感じにバランスするのでしょう。処理密度とか、命令粒度とかいうのかな。

[ 2006/12/28 00:00 ] MEncoder　-vf | TB(0) | CM(0)

覚書（要約）記載無し	手許常時使用
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） no-b-adapt name="Adaptive B-frames" 推奨：Enabled default： Enabled B フレーム挿入の際に定数ではなく、x264に挿入枚数を必要に応じて決めさせる。 Bフレームが不適当な箇所で Bの連続数が減る。	man MEncoder bframes=< 0-16>で指定された最大Bフレーム数の範囲で、いつ、どれだけの数のBフレームを使うか自動的に決断する。オフの場合、前述のbframes=<0-16>(デフォルトで0)の最大Bフレーム数を使用する。
zero1(svn408) Usage: --no-b-adapt (default=on) 　このオプションは適応的Bフレーム挿入をオンにするもので、一般的にはお奨めできない。このオプションを使うと（デフォルトはenable。--no-b-adaptで切る）x264がどこにどれだけのBフレームを使うか自動で決める。（＊最大？＊）何枚使うかは上記の--bframesで決まる。（＊:Zero1氏の記述根拠不明。下記とも矛盾。未推敲箇所と思われ。＊）	MEncoder Doc : Note: defaultでオン。　このオプションを使うと、エンコーダはまずまず合理的な速度で、B-frameの効果の薄いシーンのB- frame数を減らす計算をします。b_biasを使って、間引く程度を調節できます。adaptive B-frameの速度低下は目下のところは慎ましいものです。しかし望み得る画質向上の程度も同様です。まぁ、通常は害はありません。1stパスの速度とフレームタイプの決定にしか影響しない事に注意して下さい。b_adapt と b_bias は後続のパスにはなんの影響もありません。

覚書（要約）（＊前項から＊）　デブロックフィルタ使ってると、細部が潰れるので気になるときがある。　そういう時は、コレ使ってデブロックフィルタ切ったほうがいいかもしれない。	手許常用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 でほぼ封じ込めることができます。これでデブロッキングフィルタをあれこれするより、ほぼ確実に、良く見えるでしょう。

覚書（要約） 704x480で1600～2500 といった数値が見える。 bpp概算で"まずまずだがブロックノイズが見える（0.2）"～"無意味。むしろ解像度を上げるべし（0.3）"の範囲と思われる。手許（ageha）とは大幅にスタンスが異なる事に注意。特に画質に対する主観評価で違いが出て来ると思う。覚書（なるP氏）の方が画質に厳しい筈だ。ここまでbitrateに差があると、細部の設定方針も大幅に差があるハズ。	手許横幅640、1024固定。 bpp概算で"低画質(0.15)"～"まずまずだがブロックノイズが見える (0.2)"の範囲。覚書（なるP氏）とは大幅にスタンスが異なる事に注意。特に画質に対する主観評価で違いが出て来ると思う。自分の方が画質に甘い筈だ。ここまでbitrateに差があると、細部の設定方針も大幅に差があるハズ。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） bitrate name="Bit Rate" Recommended： N/A Default： N/A Set bit rate per second (kbps)	man MEncoder 平均ビットレートの指定。単位kbit/sec(default: off)。ローカルビットレートは変動するため、非常に短いムービーでは指定値とかけ離れた値になる事がある(ratetol参照)。このオプションと vbv_maxrateを同時に使うと固定ビットレートになるが、画質は著しく劣化する。　＊ローカルビットレートビットレート配分を計算する際の単位となる区間の模様。平均化区間というコトバも散見される。1パスでも使う。つまり少なくともx264には、固定ビットレートエンコードや固定quantizerエンコードを想定していない。できない事はないが、全体的なオプションの構成やデフォルト値がそういう作りになっていない。
zero1(svn408) Usage: --bitrate <integer> (default=off) 平均ビットレートの指定。単位Kbps(kilobits per second)。特定のファイルサイズにおさめたければ、推奨方式は2パスだ。特定ファイルサイズと画質が両立できる。1分程度より短いクリップでは3パスが有効な事もある。 x264 の --bitrate は本質的にABR（平均bitrate）でもしCBR（固定bitrate）を使わなければならないなら（ストリー民具以外にCBRのメリットはほぼ無いが）、--vbv-maxrateも弄る必要がある。	MEncoder Doc -

覚書（要約）・3の命令が、 statsファイルに上書きする。2の命令はしない。　すなわち2passならば、1→2 　3pass 以上ならば、1→3→3→…→3→ 2　と、実行させる。　50passぐらいまでは、+ 10pass増えるごとに画質が全く違うモノになる。　そこから100passぐらいでは、+20passごとで、変わる感じ。　主に、輪郭などの鮮明さで、差が出てくる。	手許パス数 NTT研究所でも数十パスで1080pを1.8Mビット/秒にできるとしている。 Apple-H.264 パス数指定不能。フロントエンド次第の模様。QTPlayer Proは5程度。 raw2qt264で強制的に2パスでやるとたかが落語で豪快なブロックノイズが出た。動き補償、なかんずくモーションベクトル・サーチ精度に問題か。　現状では、土台のショボさを多段パスで隠蔽したものに過ぎず、なによりあまりにも遅い。心情的には"最先端技術"は誇大広告と言いたいほどだが、4Core x 2クラスが一般的になってくるとasmプログラミングに頼らずとも相当の高速化を果たす公算が高い。設定の簡便さ、狙っても画質破綻を引き起こせない安定性を考えるとx264のアドヴァンテージは必ずしも大きく無い。特に画質に文句を付けている意見は見た事が無く、Bond氏も"rather good"としている。画質に関しては一度はApple-H.264を試して頂きたい。Mac/Win問わずMPEG Streamclipで試せる。　自分の見立てでは、普及度の面でXvidとQT互換H.264、そしてflvの後塵を拝しているx264は、中期的（2～3年）にはむしろ瀬戸際にある。2007年中の進化速度が天王山だろう。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） pass name="Multipass Mode" Recommended： Enabled Default： Disabled マルチパス・レートコントロールをenable	man MEncoder 2または 3パスモードの指定。最適なビットレート配分と全体の画質向上の為には、2か3パスエンコードを推奨。　1 1st パス　2 2nd パス (または2パスエンコード) 　3 Nth パス (3pass エンコードの 2nd と 3rd パス) 理屈と使い方： 1st pass(pass=1) 映像の統計を取ってファイルに書き込む。 CPU負荷の高いオプションは使わなくて良いが、デフォルトでonのものは使う事。 2nd pass(pass=2) stats(＊統計＊)ファイルを読み込み、これを基にビットレート配分をコントロールする。 3pass モードでの2nd("pass=3"。誤字ではない) 上記の両方を行う。最初に統計を読み込み、上書きする。CPU負荷の高いオプションを除き全てのエンコードオプションが使える。 3rd pass(pass=3) 2nd passと同じだが、2nd passの統計を使用する。CPU負荷の高いオプションを含めて、全てのエンコードオプションが使える。 1st pass はABRでも固定quantizerでも良いが、quantizerを推測する必要がないので、ABRの方が望ましい。後続のパスはビットレートを指定するABRでなければならない。
zero1(svn408) Usage: --pass <1\|2\|3> マルチパスモードの起動。 1st と2ndについてはXvidで慣れている人も多いだろう。 "nth pass"というものが増えた。これは、1stパスで統計情報を採り、次の2回目にnth passを走らせるというものだ。結果が気に入らなかったり、ファイルサイズがオーバーしたりしたら、2回目のパスをもう一度実行できる。するとnth passはpass 3を実行する。　 Nth passは一回ごとに統計情報をアップデートしてゆく。 2nd passは単に最終パスを実行するだけで統計をアップデートしない。　 --pass 1 Pass 1は映像分析と統計ファイルの書き出し。 Xvidにおける"2 pass - First pass"だ。デフォルトではmuxできるファイルを書き出す。このパスで bitrateを指定すると1 pass ABRとなる。 --qp 18などを指定すると、概ねXviDの full quality first pass mode同等の見た目のファイルができる。一般的には、この段階で bitrateを指定した方が、2nd 、nth passの結果が良い。 --pass 2 Pass 2はfirst passで得た複雑度の統計に基づいてレートコントロール関係の判断を下し、出力を生成する。Xvidの"2 pass - Second pass"といっしょだ。統計情報の上書きはしない。一般的に2 passはより良い画質とより小さなファイルサイズをもたらす。常時推奨。動作の視覚化は下記参照のこと。 (Pass 1) --pass 1 = 最初の統計収集 (Pass 2) --pass 2 = Pass 1 の統計を使って出力 --pass 3 --pass 3はいくぶん特別だ。これは２回目や３回目のパスという意味では無い。というのは何回でも無限に繰り返せるから。画質が無限に向上するわけでは無いので10パスはちょっと待てという感じ。現実的なメリットがあるのは、 1000フレーム程度より短い素材だけだ。こうした素材ではbitrate配分を最適化する時間が足りない（＊where it doesn't have much time to average the bitrate properly＊）。基本的に--pass 3は--pass 1 と --pass 2の作業を同時に行うが、最初の統計ファイルを作るにはpass 1が必要だ。 --pass 3は、単純に統計ファイルを読んで出力するだけでなく、統計ファイルもアップデートする。従って、nth pass modeを使った3 pass encodeではpass 2よりも精度の高い統計情報が使える事になる。このへんは視覚化すると理解しやすい。ここでpass 2を走らせるとpass 1の統計情報よりリファインされたものが使える。 (Pass 1) --pass 1 = 最初の統計収集 (Pass 2) --pass 3 = Pass 1 の統計を使って出力 + 統計情報のアップデート (Pass 3) --pass 3 = Pass 2 の統計を使って出力 + 統計情報のアップデート	MEncoder Doc 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にそれぞれこんなのを追加して試してみてください。　（＊06年10月改訂前のオプション名＊） 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（以上の）パスが有効なケースがいくつかありますが、上級者向けなのでここでは省きます。

覚書（要約）記載無し	手許【参考】Doom9 コデックコンテスト2005では一切弄っていない。
MeGUI2.0 Help（ContextHelp v0.2 06/01/01） qcomp name="Quantizer Curve Compression" Recommended： 0.60 Default： 0.60 QP curve compression: 0.0 = CBR, 1.0 = CQP	man MEncoder quantizer の圧縮。低い数値にするとビットレートの変動幅が低くなる。=画質の変動幅が大きくなる。高い数値にするとquantizerの変動幅が低くなる。=画質の変動幅が小さくなる。 (default: 0.6)。
zero1(svn408) Usage: --qcomp <float> (default=0.60) [0.00 - 1.00] QP curve compression（＊曲線圧縮？＊）低くするほどconstant bitrateに近づく。0.00 でCBR。高くするほどconstant QP に近づく。(＊1.00 でCQP。＊）推奨値はデフォルトの 0.6。特にアニメで0.00 のCBRは絶対に避けるべきだ。レートコントロールの手足を縛り、動きやディテイルの少ない箇所でbitを節約して、動きやディテイルの多い箇所に振り向ける事ができなくなる。	MEncoder Doc : qcompは一定量のビットを"コストのかかる"動きの多いシーンと、"コストの安い"動きの少ないシーンの間でやりとりするものです。極端な例をあげると、qcomp=0で真のconstant（＊固定＊）ビットレートになります。一般的には、これで動きの多いシーンは酷い物になります。一方、動きの少ないシーンはたぶん完璧でしょう。そして必要なビットレートの何倍も無駄にビットを喰っているハズです。反対の極端例。qcomp= 1 はほとんどconstant quantization (QP)（＊画質固定、一定画質など＊）です。 Constant QPでは、画質が悪いということはありません。しかし多くの人は、非常に"コストのかかる"シーンでもっとビットレートを節約して（動きの多い場面では画質劣化はあまり目に留まりませんから）、その分を、画質向上しやすいシーンに回すほうが合理的だと考えています。 qcomp のデフォルトは 0.6 です。これは多くの人の好みよりは若干低いようで、0.7-0.8 を使う人も多いです。

NO.	ページタイトル	メモ
1	Top
2	カテゴリ：Mencoder
3	カテゴリ：MPEG-4全般
4	カテゴリ：動画全般
5	tag:x264
6	tag:H.264/AVC
7	MPEG-4の基礎5 - ISO 14496-10(ビデオ) - AVC
8	MEncoderの代表的なインタレ解除フィルタ	tag:インタレ解除
9	Lanczos3、Lanczos4とはなんぞや
10	カテゴリ：-x264encopts	MEncoder -x264encoptsです。 x264cliな人は、tag:x264(r600)コマンド対応が少しは取っ付き易いかと。

	PPC	x86
12	75.82%	24.18%
11	78.86%	21.02%
10	73.60%	26.40%
09	91.56%	8.44%

	win	Mac	Linux
12	82.00%	14.23%	3.46%
11	76.34%	18.11%	4.89%
10	74.77%	21.32%	3.35%
09	64.88%	33.06%	1.76%

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

x264_TEST_Frame_type_01_GOP関連

目的

方法

素 材

MEncoder設定

結 果

ま とめ

概説

Frame-type_B フレーム関連オプション

概説

Frame-type_その 他のオプション

概説

Ratecontrolオプション

概説

Analysisオプション

概説

Analysisオプション _deadzone関連

概説

Analysis オプション _カスタム量子化マトリクス関連

余 談：

概説

Analysis オプション：Sharktooth版固有の機能

概説

Video Usability Info (Annex E)オプション

プロファイル

プロファ イル

レべル

表 １：Compressed Bit Rate Multipliers for FRExt Profiles (表２の第７列参照)

表 ２ H.264/AVCのレベル

表 ３：各映像サイズに対応可能なレべルと最大フレームレート(fps)

avc1Decoder 0.5.0

1. PostProcess

い） 設定項目の意味

ろ） インラインデブロック（in-loop filter）とのバッティングの可能性

は）再生時 のインタレ解除の可能性

2. nclc setting

3. ついちまちまと重箱の隅をつついてしまったが、メリットのほうが絶大。

使用ツール

pullup、-ofps 24000/1001の場合

1.1.現象

1.2.対策

1.3. 結果

1.4.疑問点

yadif=0、-ofps 30000/1001の場合

1.1. 現象

1.2.対策

1.3.結果

070105 追記

映 画界の呼称

DAR とPARとSAR

一般的な SAR:

なぜx264にDARが無いの か。

AVIと QuickTimeとMPEG規格

OBMCについて（妖精現実- 2006年3月のメモからコピペ）

Comments

素材

結果

まとめ

Frame-type_その他のオプション

余談：

プロファイル

表１：Compressed Bit Rate Multipliers for FRExt Profiles (表２の第７列参照)

表２ H.264/AVCのレベル

表３：各映像サイズに対応可能なレべルと最大フレームレート(fps)

い）設定項目の意味

ろ）インラインデブロック（in-loop filter）とのバッティングの可能性

は）再生時のインタレ解除の可能性

映画界の呼称

なぜx264にDARが無いのか。