ageha was here

◀PREV PTOP
◀ GOP関連をおろそかにしたx264はXvidにも劣る。 表紙 人気記事 06/11▶
Download Day - Japanese

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

記事番号:144

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

△ETOP | ▲PTOP



理 由へGo!

Frame-type_GOP関連オプション

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

I, --keyint <integer> keyint=<value>

■まとめ:240 or 300
 一般的には出力fpsの10倍(10秒ぶん)。
 ここは一般的な値を入れておくのがベスト。なぜならx264内部がそれを想定したチューニングになってる公算が高いからだ。このオプションの第一目標は あくまでシークポイントの作成。画質に関係なくもないが本来の目標では無い。これをいくら大きくしてもシーンチェンジがあるかぎりI/IDRは自動的に入 る 。逆に小さくすればI/IDR挿入が過剰になるリスクがある。これはP/Bに回るbitを減らし総合的な画質劣化を呼ぶ。わざわざ ここを弄る人は少ないから設定を比べにくくなるのも痛い。

 し かしもし、シークなど無用!断然画質追求あるのみだ!という場合は無限大を試してみよう(30分素材なら6000とか)。少な くとも数値的にはそれで「望み得る最善画質」に近づける。あとは他のGOP関連オプションを弄って必要最低限のI/IDRを場面転換点だけに間違う事 無く正確に 突っ込む手を探してさまようがいいわ。
 深入りしたくなければ一般的な値を。

■参考
覚書(要約)
240 or 300
GOP単位関係はデフォルトではなく自分仕様に変更した方が、いいかと考えられる。
手許
240 or 300
MeGUI2.0 Help(ContextHelp v0.2 06/01/22
keyint name="Maximum Key Frame Interval"
推奨250
default250
Group of Pictures(GOP)の最大長を指定。GOP は他のGOP中のフレームを参照できない。また、シークやランダムアクセスをする上で必要なもの。
GOPサイズは符号化効率を優先してエンコ過程で動的に算出されるものだがmaximum GOPを指定してやればシークのやり易さを維持することができる。
man MEncoder
IDRフレームの最大間隔[250]
大きい値の方がbitが節約できるので品質が向上するが、シークの精密さと引き換えになる。
MPEG-1/2/4とは違って、 H.264はkeyintを大きくしてもDCT driftで苦しむ事が無い。
(*DCT driftの意味不明*)
zero1(svn408)
Usage: --keyint <integer> (default=250)
最大GOP値の指定。
新しくIDRが入るとそこから新しいGOPが始まるが、その前に存在しても良い(*IDR以外の*)フレームの最大 枚数を指定する。
 Xvidで言う "Maximum I-frame Interval"に相当するだろう。
 一般的にはシークを重視して10秒分のフレーム数にする人が多いようだ。
 25fpsのPALなら --keyint 250、23.976fpsのNTSCなら、まぁちょっと丸めて--keyint 240(*1)。
 新しいGOPは、--keyintの指定値を超えていない限り、通常はシーンチェンジからスタートする。
 だからこのオプションが作動するのは場面転換の無い長回しや映像に大きな変化があった場合だけだ(アニメではほと んど無いと言って良い)。
MEncoder Doc
: keyintはシークのやり易さと符号化効率の取引です。他の目的はありません。デフォルトのkeyintは250にセットされ ています。25fps素材では、これで10秒精度のシークができるようになります。5秒精度のシークが重要と考えるなら、keyint=125。ビット レートあたりの品質は僅かに落ちます。品質だけが重要でシークのやり易さを問題にしないなら、もっと大きな値にできます(値を大きくすればするほど、効果 は漸減します。無視できるほど小さく、あるいは0にもなり得ます。)それでも、ビデオストリームにシーンチェンジがある限り、そこがシークポイントになり ます。

-i, --min-keyint <integer> keyint_min=<1-keyint/2> ※式の意味不明、入力値は整数

■まとめ:素材映像に応じて調整
 絶対安全策は0か1。ドラクエでいう「がんがんいこう ぜ」。
 このオプションを0にすると言う事は、必要なら連続したIDRフレームを作っても良いよという事(最小GOP単位の制限をはずす)。だから非常に短い間 隔でぽんぽん場面が切り替わる映像、例えばアニメのオープニング・コマーシャル・画面全体を覆う光の明滅(禁止だけど)などで、x264が「あ、ここ にI/IDR入れたいな」と思った時に制限がかからない。これだけでも結構ブロックノイズ削減効果がある。実際にはx264はなかなか賢く、手許の実験で は連続IDRは できなかった。充分な実験とは言えないが、0や1が複数参照(frameref, --ref)の手足を縛る心配はあまりしなくて良いと思う。一般的にアニメはこれでも足りないから次のscenecutも上げて行こう。

 しかしながら。実写ではたくさん入れれば良いというものでは無い。例えば落語。場 面 転換など無いから「がんがんいこうぜ」ではキモノの質感などにうまくbitが回らない(常用は640x480,1024kbps)。アクションシーンなん か無いだけになおさら目立つ。「x264の実写はイ マイチ」と言う意見の中にはアニメ向け設定を実写に使っているケースもあるのじゃないだろうか?アニメだってのほほ〜んとした場面が多いもの、例えば『僕 等がいた』 では無駄 なI/IDRを削ってもっと小さくできるハズだ。

 ようするに、このオプションは次のscenecutとセットで試行錯誤を要する。
 少なくとも実写全般向けとアニメ向けの2セット。現実的には自分の録画傾向に合わせたクリップを用意して実験すると良いだろう。一分程度のもので傾向は 充分に掴める。下記の参考値を土台に適正値を求めてさまようが いいわ。
 この事は、必要です。

■参考
覚書(要約)
アニメ:1 or 8
前項参照。
※ffdshowの機能を使った視覚化実験の結果、上記に落ち着いた模様。
※8の根拠不詳。3コマ撮り?
手許
アニメ:0 or 1
実写:24 or 30
特にアニメで24/30は禁物。ブロックノイズでApple-H.264どころかxvidにも劣り得る。
これは0 or 1と下記のscenecut調整でほぼ根絶できている。
その後、MovieVideoChartとx264 1st passのログを用いて実験:
このオプションだけでもIDRは増えるが効果は微弱で、scenecutの方が影響大。0 や 1は複数参照に影響してbitが無駄になるのではと思ったが、I/IDRが連続するケースは無かった。素材はケロロ軍曹のオープニング(なんでもかんでも やりましょう♪)比較的厳しいほうだと思う。
だから、0 や 1でも複数参照(frameref, --ref)の手足を縛る心配はあまり無さそうだ。
MeGUI2.0 Help(ContextHelp v0.2 06/01/22
min-keyint name="Minimum Key Frame Interval"
推奨25
default25
Group of Pictures(GOP)の最小サイズを指定。GOP は他のGOP中のフレームを参照できない。また、シークやランダムアクセスをする上で必要なもの。GOP sizeは、効率的に符号化するためにエンコード過程で動的に算出される。しかしながら、minimum GOPの指定はハイモーションシーンの圧縮の助け(*help improve compression*)となる。
man MEncoder
IDRフレームの最小間隔を指定(default: 25)。
この最小間隔の中にシーンチェンジが含まれた場合、Iフレームは生成するものの新しいGOPを生成しない。
H.264では、Iフレームはclosed GOPの区切りとは限らない。
なぜなら、Pフレームを直前より前のフレームを基に予測しても良いからだ (framerefも参照)。この為に、Iフレームは必ずしもシーク可能では無くなった。
IDRフレームは、後続のPフレームに、自分より前にある全フレームを参照禁止にする。
zero1(svn408)
Usage: --min-keyint <integer> (default=25)
 最小GOP値の指定。
 新しいIDRを挿入して新しいGOPを開始する前に存在しても良いフレームの最小枚数を指定する。
  --min-keyint指定数の間にシーンチェンジがあった場合、場面転換の開始フレームは単にIフレームとなるだけで、新しいGOPを開始しない。
MEncoder Doc
前項参照

--scenecut <integer> scenecut=<-1-100>

■まとめ:素材映像に応じて調整
 絶対安全策は無い。残念ながら。
 さらに感覚的な話でもうしわけないが、デフォルト値40は実写向けオールラウンダーな印象がある。上げすぎない方が良い。
 このオプションはkeyint_min(--min-keyint)より遥かに応答性が高く、ピーキーだ。弄った時の効果が目で解り易いので頼りがちだ が、そのぶんI/IDR過剰にも陥り易い。実際にはここでもx264はなかなか賢く、場面転換の無い落語ではそうそう増えない。むしろ下げてもいいくらい だ。
 アニメではデフォルト40じゃまるで足りないのでぐんと上げて行こう。

 なお、下記ではscenecutが挿入するものを「追加的なIフレーム」と呼ぶケースが多い。これはGOPの単位となるIDRでは無く、Xvidで GOPの単位だったIフレームとも異なるという意味だ。で、ありながら、実験ではこれを上げると「追加的なI」よりIDRが増えた。てゆうか他の設定で 「追加的なI」だったものが IDRに化けた。内部でframeref(--ref)設定値なども参照して調整しているかもしれない。

 このオプションは上記のkeyint_min (--min-keyint)とセットで試行錯誤を要する。
 少なくとも実写全般向けとアニメ向けの2セット。この事は、必要です。

■参考
覚書(要約)
アニメ:最低60は欲しい。
アニメOP:75程度
--scenecutは、数が大きければ、キーフレームを積極的に入れるようになる。逆に、減らすとキーフレームを 入れないようになる。
defaultではキーフレーム挿入が、少し控え目ってことですね。
手許
手許では
アニメ:一律55
実写:一律40(デフォ)

Xvidの経験則が通用しないオプション。
追加的なIフレームだけでなく、IDRも増える。
自分の素材傾向に応じて要テスト。
MeGUI2.0 Help(ContextHelp v0.2 06/01/22
scenecut name="Scene Change Sensitivity"
推奨40
default40

場面転換の検出精度の調整。シーンチェンジ・ディテクションは場面転換の際にIフレームを挿入し、見た目を向上させる。
man MEncoder
 追加的なIフレーム挿入を決断する際の積極性(default:40)。
scenecutの値が低いと、このコデックはしばしばkeyint間隔よりも大きな間隔でIフレームを入れてしまう。
scenecutの値が適切なら Iフレームはもっと良い位置に挿入される。
大きすぎる値を使うとIフレームを必要以上に入れてしまい、bitが無駄になる。

-1 は自動シーンカット検出を無効にする。従ってIフレームは、たとえ場面転換があろうとも、keyint frame間隔毎にしか挿入されない。これはオススメできない。なぜなら、この場合に場面転換地点で生成されるPフレームはIフレーム同然にサイズが大き くなるのでビットレートの無駄だし、その上"keyint counter"にもリセットがかからないからだ。
zero1(svn408)
Usage: --scenecut <integer> (default=40) [1 - 100]
 追加的なIフレームを挿入する際の閾値。
 高い値にすると必要以上にIフレームを挿入する傾向が高まる(言い換えるとbitが無駄になる)。例えば、映像中に相当な変化があるが場面転換と判断す るほどでは無いような場合だ。
 低い値にするとIフレームはあまり使わず、最終的には--keyint値に頼って最適なIフレーム挿入をしない傾向になる。例えば、Iフレームの代わり に非常に巨大なPフレームが入るとか(Pのデコードには先行するI/Pのデコードが必須だ)。
MEncoder Doc
上記参照。


■参考記事

  1. I/IDR フレームとは
  2. GOP 関連をおろそかにしたx264はXvidにも劣る

△ETOP | ▲PTOP

▶コメント(-4)

  1. MASA.H: DCT drift, 2006年12月02日(土), URL

    DCT driftとはおそらく浮動小数点でDCT(離散コサイン変換)をやる都合上どうしても出てしまう誤差の蓄積による画像の破綻かと。
    MPEG系ではこれをIフレームでリセットしているのでkeyint=Iフレームの間隔であったMPEG-1/2/4と違ってkeyint=IDRフレームの間隔であるH.264は影響を受けにくいということでしょう。

    ただH.264はそもそも浮動小数点でDCTを行わず、整数行列で計算していた気がするので浮動小数点を使わないことのほうが因子としては大きいかもしれません。

  2. ageha: コサインとか行列とか聞くと高校で20点だったのを思い出します。, 2006年12月02日(土), URL

    コメント有り難うございます。

    >H.264はそもそも浮動小数点でDCTを行わず、整数行列で計算していた気がする

    こちらのように思えます。

    1)H.264/AVC規格概要:2.1.2. 変換と量子化
    H.264/AVCは、基本的に主要な空間軸変換に整数逆変換ベースを使う最初のビデオ規格だ。理想的な三角関数を使った逆変換方程式の定義は、実装ごとに許容誤差が異なる。一般的にエンコードに使われるその先の変換も整数変換だ。整数を使うメリットは、正確な整数逆変換を使うとMPEG-2やMPEG-4 part 2とは事なりエンコーダとデコーダの間でミスマッチが出ないと言う事だ。
    http://agehatype0.blog50.fc2.com/blog-entry-83.html

    2)man mencoder keyint
     H.264 does not suffer from DCT drift with large values of keyint.
     これはdriftの完全排除と訳し得る。

    3)複数参照の都合上、蓄積誤差リセットはIDR-IDR間隔でしかできないハズです。
     ので、IDR-I間隔<IDR-IDR間隔になります。
     かつ、実装/設定次第でIDR-IDR>旧規格のI-Iになりうる。
     ゆえに、浮動小数点だと蓄積誤差はMPEG-1/2/4並かそれ以上になり得る。

    しかしDCTそのものは理解できていません。
    そういえば追試は14点でしたが…。

  3. MASA.H: , 2006年12月03日(日), URL

    DCT(離散コサイン変換)とはフーリエ変換の一種で特徴は離散空間で定義されていることと結果得られる級数の係数がすべて実数であることです。
    フーリエ変換とは与えられた関数をフーリエ級数(三角関数の和)にすることです。これにより与えられた関数を定常波の重ねあわせで表現できます。係数をすべて保持すれば逆変換を行うともとの関数になります。

    画像の場合は低周波領域に特徴成分が入りやすいのでそれを利用して量子化を行って情報量を削減させます。これに用いられる係数を表したのが量子マトリクスです。

  4. ageha: 有り難うございます, 2006年12月04日(月), URL

    本で読むとすごく長いので助かります。

コメントの投稿
管理者にだけ表示を許可する

▶トラバ(-0)

トラックバックURL
http://agehatype0.blog50.fc2.com/tb.php/144-46c309cd

    ▲PTOP

    ◀ GOP関連をおろそかにしたx264はXvidにも劣る。 表紙 人気記事 06/11▶

    Most Viewd:(070101-071031)

    1. じだいおくれの地デジのはなし
    2. 牛乳有害説
    3. MeGUI ガイド_x264の設定
    4. MP4 faq
    5. tag:H.264/AVC
    6. 続・あたらしい著作権のはなし
    7. Xbox360、PS3、AppleTVの対応動画
    8. cat: 動画全般
    9. tag:MPEG-4
    10. 縦横(アスペクト)比
    11. Apple TV改造 - Xvid
    12. MP4Boxの主要コマンド
    13. MPEG-4の基礎 5 - ISO14496-10(ビデオ) - AVC
    14. cat:MPEG-4全般
    15. cat:-x264encopts
    16. ffmpeg コマンドその1(らけった版)
    17. tag:MeGUI
    18. tag:x264(r600)コマンド対応
    19. date:20070801
    20. PSPファームウェア3.30
    21. tag:mp4box

    ▶ Index

    表紙
    全記事一覧
    ここについて
    人気記事
    x264関連
    ageha更新終了の辞

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

    ▶ カテゴリー

    ▶ タグ検索

    ▶ Archive R

    FC2Ad

    FC2ブログ 一戸建て

    ▶ 管理/なかのひと

    ▶ StyleKeeper

    ▶ StyleChanger

    public my share