概説
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~3。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を使う事は滅多にありませんから、それ以上の値を指定しても効果は薄いです。
■ まとめ: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ならそうあるべき)は存外に少な い。 本来は映像内容に応じて調整すべきものだろうが、これに手を出すには以下の条件が必要だ。 1) Bに適さない映像とはどのようなものかを知る事。 2)エンコード後の映像でどのコマが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 *QT7非互換 *
■ まとめ:使わない場合は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ベースのデコーダは、これを使った 映像を読めない点に注意して下さい。
スポンサーサイト
mencoderでもrawで出力すればdelay frameは入らないのでは?