ageha was here

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

ホーム > I/IDR

GOP関連をおろそかにしたx264はXvidにも劣る。

１. Iが多いほど空間軸画質が良い。しかし、Iは巨大だ。

x264 [info]: slice I:  490 Avg QP:19.21 size: 24682 PSNR Mean Y:47.78 U:49.86 V:51.00 Avg:48.38 Global:47.57
x264 [info]: slice P:15350 Avg QP:21.01 size:  8706 PSNR Mean Y:45.88 U:48.60 V:49.90 Avg:46.69 Global:45.88
x264 [info]: slice B:18195 Avg QP:21.47 size:  1979 PSNR Mean Y:45.94 U:48.79 V:50.08 Avg:46.77 Global:45.96

ピンクが枚数。黄色がデータサイズ。枚数では1.4%に過ぎないI/IDRだが、平均サイズはむちゃむちゃデカイ。そう！アイは惜しみなく奪うのだ！（どーん）。

　もしこれで画質に不満がある場合、P/B関連のオプションでちまちま悩むより、無駄なI/IDRの存在を疑うほうが手っ取り早い。そのぶん浮いたbit をP/Bに回せば全体的な画質向上が期待できる。画質が充分ならP/B関連の重たいオプションを切って速度を取るなり、bitrateを下げるなり、いろいろと戦術の幅が広がる。

　空間軸画質向上の第一歩は不必要なI/IDRの排除。そう！アイはあり過ぎても問題なのだ！（いろいろとね！）。

２. GOP関連をおろそかにしたx264はXvidにも劣る。

シーンチェンジの最初はIDR、少なくともIフレームである事が望ましい。
　I/IDRが正しく場面転換の位置に入っていないと、後続のP/Bフレームが "全然別の場面との差分" で構成されてしまう。このようなP/Bフレームは、正しい位置に置かれたI/IDRを参照するP/Bより画質が悪い。そのくせ、サイズはIフレーム並みにデカイ。のみならず、巨大サイズのP/Bには x264のbitrate制御機能が容赦なく適用QP値を上げるので画質は一層悪化する。それをまた後続のP/Bが参照するものだから…、という具合に画質劣化は時間軸に沿って連鎖的に波及してゆく。さらにその影響はマルチプル・レファレンス（frameref / -r, --ref / refs）の効果で結構遠くまで及び、さらにさらにskip/directマクロブロックにより意外な箇所にまで波及しさらにさらにさらに b_pyramid でBを参照化してた日には、、、てな感じの連鎖反応がGOPリセット（IDR最小間隔）まで続く。被害は連鎖的であり幾何級数的であり予測不能かつ壊滅的大打撃！大打撃！！大打撃！！！見ろフレームがゴミのよーだ。
　フツーの設定だと最大1秒間。ちゃんと見てると結構長いよ～。

　いやわかんなくていーですこんなん。

　ひらたく言うと、I/IDR設定ミスの影響は「風が吹けば桶屋が儲かる」。
　正確かつ必要最低限のI/IDRはx264の第一歩。

　真面目な話Apple-H.264にはこの問題が無い。それどころかGOP設定をおろそかにしたx264はXvidにも劣る。あえて言おう。カスであると！（得意げ）

３. x264の場合、I/IDR調整のアプローチは２種類ある。

場面転換点へのIDRの挿入：最小/最大間隔を数値指定。挿入位置（場面転換検出）は指定範囲内で自動 ⇒ keyint系
追加的なIの挿入："映像が大きく変化するが、場面転換というほどでも無い箇所"の検出感度を指定。検出感度は上記と連動。 ⇒ scencut

ほんとうは全ての場面転換に手動で「ここに I/IDR入れてね」とマーカーを打つのがベストだと思うんだけど思ってみただけですすいません。だから上の二つを調整して、I/IDRが多すぎず少なすぎず、ちょうど良い案配にかつ適切な位置に入るような値を見つけてやる必要がある。デフォルト値は実写ではそう悪く無い。アニメではガタガタ。逆にアニメ用に追い込んだ設定だと実写がぐずぐず。
　アニメ汎用と実写汎用、少なくともこの２種類のGOP設定セットを持っておきたい。

NOTE:
　ちょっと注意したいのがIとIDRの関係だ。マルチプル・レファレンスの都合上、H.264のシーク単位はIDRで、Iは無理。extra I-frames（追加的な）などと書いてあったりする。keyint系オプションはシーク単位以上の意味は無いよと書いてあるケースもある。
　XvidではIがシーク単位と画質の基盤を兼ねていたが、 H.264では機能が半分だけ分離していてちょっと混乱する。

余談１：

　GOP関連を重視するについてはもうひとつ理由がある。こちらはとても感覚的なものだ。
　MEncoder -x264encoptsの先頭はbitrate、qp、crf、pass、turbo、と続く。ユーザーの関心のある順で、という意図を感じる。基礎概念も順に読んでいけばざっくり把握できるようになっている。例えばqp（旧称qp_consant）の説明で、自分は他のなによりも先にXvid QP2=AVC QP18と覚えた。
　x264cliの--longhelpは実質的に--keyint、--min-keyint、--scenecutで始まる。想定ユーザー層が違う。 QPの換算式も無い。もしもx264cliがライブラリの動作実験用フロントエンドであるのなら、そんなのは"ソース読め"だ。しかしそうであっても、いやだからこそ、後から参加するプログラマに読むべき順番を指し示す『もくじ』が要る。それはテスターやプログラマが最も呼び出し易い位置にあるべきで、かつ、符号化理論の根から枝葉に落ちてゆく順であるべきだ。
　おそらく--longhelpの書き手はそうしたもくじ以上である事もそれ以下である事も意図していない。そーささやくのよ、あたしのゴーストが。

余談２：

　理屈はまぁ、2.の前半で解ったような気になっているものの、所詮は文系。ハラゴナレがどうもいまひとつ。

『改訂版 H.264/AVC 教科書』ixページ。
　しかし、我々が用いた技術は、はるかに洗練され手の込んだものになっていて、時にベースとなっている設計原理の単純さを見失うほどです。もとのH.261 標準文書が仕様のすべてを表して25ページ以下であったのに対し、今回の新標準はその10倍以上の長さであり、技術的内容の密度も高くなっています。その様子は、折り紙作品に似ています。単純な基本コンセプトを幾層にも重ねることにより、新たな高度の造形に至っていて、これは注目に値する成果だと確信しています。

　そこで紙を一枚だして鶴なぞ折って見る。自分でもどうかとは思うが大した手間でなし、規格制定会議のエラい人がいってんだからそう外れたもんでもあるまいよ。だいいちいまさら引き返せるかってんだい…出来た。出来を決めるのは、最初の三角折り。奇麗に、ぴちっと、慎重に。ここをミスると誤差が連鎖的に波及して、最終的な出来がへげへげになる。最初のズレをほっぽらかして途中で帳尻あわせようったってそうは問屋がおろさねぇ。やり直したほうが早い。あらそっくり。げぇじんさんは例えがウマいねぇ。

■参考記事

スポンサーサイト

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

1.1. Frame-type_GOP関連

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

■参考

覚書（要約）: アニメ：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)とセットで試行錯誤を要する。
　少なくとも実写全般向けとアニメ向けの２セット。この事は、必要です。

■参考

覚書（要約）: アニメ：最低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: 上記参照。

■参考記事

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

x264_TEST_Frame type_01_GOP関連

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)

天元突破グレンラガン_01_お前のドリルで天を突け！！

x264 [info]: slice I:576

　ざっと3秒に一枚。
　手許で一番多かったのはゼーガペインの毎週480～520、I比率1.1x%といったところだが、

23.976fps_アニメ（63件）	SSIM	I比率
平均	0.9908766	1.0%
天元突破グレンラガン_01_お前のドリルで天を突け！！	0.9897144	1.3%

　と言う事で見てみたらまーポンポンとカットのあることあること。
　数値・主観とも画質に文句は無いが、MovieVideoChartで見るとIDRの挿入点に疑問を感じる部分があった。
　うわ、そのシーンカット見つけますか賢いねぇというところもあり、なんでそこにIDRを入れないのだ君わという箇所もありで、判断基準が一貫していない。
　GOP関連設定はkeyint=240:keyint_min=1:scenecut=65。

そのシーンカット見つけますか賢いねぇ	なんでそこにIDRを入れないのだ君わ	メモ
		ズームではなくすぱっと切り替わるのでカットと言えばカット。
		どちらも上と同じ"カット" だが、良く解らない。
		さらに解らない。輝度？複数参照？
		さらにさらに解らない。入れるならここは 1224だろう。
		光のつぶつぶが画面を覆うシークエンスの中にはもっとカットがあるが IDRはこの一枚だけだった。これは仕方がないだろう。
		これは明らかに不正確だと思う。
		左に入って右に入らないのはなぜなんですくわッ。

　理由は

thread分散でscenecut検出が地味に不正確になる。但し速度的なメリットのほうが大きい。
1stと2ndでframerefの値を変えると、これもscenecut検出に影響が出る。但しturbo=1を使う以上避けられない（turboの内容を解析して同等設定の1stを使うとPSNR/SSIMともに落ちる）。

　などが考えられます。

　いずれにせよ通常視聴では全く気になりませんでしたし、オープニング約1800枚に入ったIDR56枚のうち、おかしいなと思ったのは上記4箇所だけなので、気にするのはかなり偏執的だと思った。
　でも地味に不可解だと思った。
　あと「ぐれんがらん」じゃないんだと思った。

 天元突破グレンラガン_01_お前のドリルで天を突け！！.mpeg
===MENCODER_PASS1===
$ mencoder 天元突破グレンラガン_01_お前のドリルで天を突け！！.mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=1:scenecut=65:qp_min=10:qp_max=51:qp_step=8:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=1:threads=2:8x8dct:turbo=1 -passlogfile 天元突破グレンラガン_01_お前のドリルで天を突け！！.264.log -vf pullup,softskip,pp=l5,crop=704:352:4:64,scale=640:352:::3,hqdn3d=4:3:6,harddup -sws 9 -zoom -ofps 24000/1001 -of rawvideo -o /dev/null
 
x264 [info]: using SAR=44/45
x264 [info]: using cpu capabilities 
x264 [info]: slice I:576   Avg QP:18.12  size: 20862  PSNR Mean Y:48.01 U:51.06 V:51.36 Avg:48.76 Global:47.43
x264 [info]: slice P:22732 Avg QP:19.51  size:  6951  PSNR Mean Y:46.27 U:49.68 V:50.31 Avg:47.12 Global:45.78
x264 [info]: slice B:12884 Avg QP:21.58  size:  2070  PSNR Mean Y:45.72 U:49.36 V:49.99 Avg:46.64 Global:45.45
x264 [info]: mb I  I16..4: 24.8% 29.7% 45.5%
x264 [info]: mb P  I16..4: 10.4%  9.5%  5.7%  P16..4: 57.6%  7.0%  2.5%  0.0%  0.0%    skip: 7.5%
x264 [info]: mb B  I16..4:  0.5%  1.2%  0.9%  B16..8: 17.6%  0.0%  0.0%  direct: 9.8%  skip:70.0%
x264 [info]: final ratefactor: 20.26
x264 [info]: 8x8 transform  intra:37.0%  inter:23.4%
x264 [info]: direct mvs  spatial:98.7%  temporal:1.3%
x264 [info]: SSIM Mean Y:0.9883897
x264 [info]: PSNR Mean Y:46.101 U:49.584 V:50.211 Avg:46.977 Global:45.677 kb/s:1042.41
 
Video stream: 1042.511 kbit/s  (130313 B/s)  size: 196715275 bytes  1509.550 secs  45242 frames
SEC ; 1815
TIME; 0:30.15
 
===MENCODER_PASS2===
04/05 03:32.16
$ mencoder 天元突破グレンラガン_01_お前のドリルで天を突け！！.mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=1:scenecut=65:qp_min=10:qp_max=51:qp_step=8:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=2:threads=16:me=umh:me_range=32:subq=7:frameref=4:mixed_refs:8x8dct:partitions=all:trellis=2:brdo:bime -passlogfile 天元突破グレンラガン_01_お前のドリルで天を突け！！.264.log -vf pullup,softskip,pp=l5,crop=704:352:4:64,scale=640:352:::3,hqdn3d=4:3:6,harddup -sws 9 -zoom -ofps 24000/1001 -of rawvideo -o 天元突破グレンラガン_01_お前のドリルで天を突け！！.264
 
x264 [info]: using SAR=44/45
x264 [info]: using cpu capabilities 
x264 [info]: slice I:576   Avg QP:17.62  size: 19584  PSNR Mean Y:48.64 U:51.21 V:51.51 Avg:49.31 Global:48.46
x264 [info]: slice P:22732 Avg QP:18.50  size:  6659  PSNR Mean Y:46.96 U:49.87 V:50.48 Avg:47.74 Global:47.12
x264 [info]: slice B:12884 Avg QP:19.81  size:  2379  PSNR Mean Y:46.65 U:49.72 V:50.33 Avg:47.48 Global:46.84
x264 [info]: mb I  I16..4:  6.4% 77.3% 16.3%
x264 [info]: mb P  I16..4:  0.6%  8.7%  1.5%  P16..4: 61.6% 10.2%  5.1%  0.3%  0.1%    skip:11.9%
x264 [info]: mb B  I16..4:  0.0%  0.4%  0.1%  B16..8: 27.4%  1.8%  4.1%  direct: 3.4%  skip:62.8%
x264 [info]: 8x8 transform  intra:79.4%  inter:62.1%
x264 [info]: direct mvs  spatial:91.2%  temporal:8.8%
x264 [info]: ref P  79.4% 10.8%  6.4%  3.4%
x264 [info]: ref B  74.0% 14.3%  6.8%  4.9%
x264 [info]: SSIM Mean Y:0.9897144
x264 [info]: PSNR Mean Y:46.875 U:49.842 V:50.445 Avg:47.672 Global:47.038 kb/s:1024.49
 
Video stream: 1024.598 kbit/s  (128074 B/s)  size: 193335118 bytes  1509.550 secs  45242 frames
SEC ; 6291
TIME; 1:44.51

[ 2007/04/09 00:00 ] 動画　圧縮日記264 | TB(0) | CM(0)

| ホーム |
Page Top↑

Index

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

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

-G-

-A-

タグ検索

カテゴリー

Script by 絵板のマナー講座
and 毒吐きネットマナーPlus

Archive R

2013 09 (1)
2008 02 (1)
2007 11 (11)
2007 10 (12)
2007 09 (6)
2007 08 (212)
2007 07 (2)
2007 06 (8)
2007 05 (16)
2007 04 (22)
2007 03 (23)
2007 02 (17)
2007 01 (20)
2006 12 (24)
2006 11 (41)
2006 10 (39)
2006 09 (22)
2006 08 (17)
2006 07 (4)
2000 02 (1)

管理/なかのひと

StyleKeeper

StyleChanger

そのシーンカット見つけますか賢いねぇ	なんでそこにIDRを入れないのだ君わ	メモ
		ズームではなくすぱっと切り替わるのでカットと言えばカット。
		どちらも上と同じ"カット" だが、良く解らない。
		さらに解らない。輝度？複数参照？
		さらにさらに解らない。入れるならここは 1224だろう。
		光のつぶつぶが画面を覆うシークエンスの中にはもっとカットがあるが IDRはこの一枚だけだった。これは仕方がないだろう。
		これは明らかに不正確だと思う。
		左に入って右に入らないのはなぜなんですくわッ。

ageha was here

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

GOP関連をおろそかにしたx264はXvidにも劣る。

１. Iが多いほど空 間軸画質が良い。しかし、Iは巨大だ。

２. GOP関連をおろそかにしたx264はXvidにも劣る。

３. x264の場合、I/IDR調整のアプローチは２種類ある。

余談１：

余談２：

■参考記事

1.1. Frame-type_GOP関連

Frame-type_GOP関連オプション

■参考記事

x264_TEST_Frame type_01_GOP関連

x264_TEST_Frame_type_01_GOP関連

目的

方法

素 材

MEncoder設定

結 果

ま とめ

天元突破グレンラガン_01_お前のドリルで天を突け！！

１. Iが多いほど空間軸画質が良い。しかし、Iは巨大だ。

素材

結果

まとめ