x264Encoder対MEncoder　ageha was here

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

ホーム > 他ツール　QuickTime > x264Encoder対MEncoder

x264Encoder対MEncoder

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

　※緑がbetter

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

１. x264Encoderの方が高速。

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

２.MEncoderの方が高画質。

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

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

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

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

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

　などとマニアックに突き詰め始めると泥沼なので、画質的には最大キーフレーム間隔は短い方が安全だ。不満があればbitrateを増やせば済む。でも1500とか2000とか使うならxvidで充分なわけだしなぁ（ずぶずぶ）。あ、もしかして、Iが多いと動き予測や動き補償の計算負荷が低くなるんジャマイカ（ずぶずぶずぶ）。

３.その他の違い。

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

4. 設定

　MEncoder(x264 core:54 svn-623M)

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

下記との違いは、-sws 9(lanczos)、-vf yadif（インタレ解除）、-x264encoptsがkeyint=300（最大キーフレーム間隔）、keyint_min=30（最小キーフレーム間隔）、bime（Bフレームのモーションベクトル精度向上）、 cqm=jvt（x264内蔵のカスタム量子化マトリクス）、ratetol=4（bitrate値変動幅の許容値、デフォルトより拡大）、partitions=all（マクロブロック・パーティション、デフォルトより拡大）。

　MPEGStreamclip1.8+ x264Encoder0.5.1

全て切っている。
MPEGStreamClipのインタレ解除を使う為。

MPEGStreamclipのインタレ解除は動きのある部分のみボトムフィールドを処理する。
とヘルプにあったのでpp系より賢そうな印象を受けたので使って見た。

素のQuickTime Player（Apple-H.264）は、8x8DCT,FLAG2_BPYRAMIDを受け付けない。

５. 余談：

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

スポンサーサイト

[ 2007/03/20 00:00 ] 他ツール　QuickTime | TB(0) | CM(2)

> x264Encoderの最大GOP間隔は5秒のようだ
KeyIntMinはffmpegデフォルトのまま、KeyIntは250までうけつけます。30fpsだと８秒ちょっとですね。（x264Encoder.c:1985）
KeyFrame:Autoの時はMaxにするか、120くらいにするかとかのほうがいいでしょうか。この辺もうちょっときちんと作らないとだめですね。

[ 2007/03/21 10:40 ] [ 編集 ]

最大GOP間隔5秒はMPEGStreamclipの仕様でした。

>> x264Encoderの最大GOP間隔は5秒のようだ
　MPEGStreamclipの固有仕様っぽいので後ほど訂正します。

実験：QTPProの"キーフレーム"設定
　２分のCM, 1024kbps, x264Encoder 0.5.1, QTPPro 7.1.5, OSX 10.4.8
　■自動
　　INFO : lavcEncoder: - gop_size: 12 ; max_b_frames: 3 ; qcomp: 0.60 ; sc_threshold: 40
　　[h264 @ 0x6fb1dc]slice I:349 Avg QP:29.07 size: 12329

　■すべて
　　INFO : lavcEncoder: - gop_size: 0 ; max_b_frames: 0 ; qcomp: 0.60 ; sc_threshold: 40
　　[h264 @ 0x6fb1dc]slice I:3593 Avg QP:39.06 size: 4372

　■250
　　INFO : lavcEncoder: - gop_size: 250 ; max_b_frames: 3 ; qcomp: 0.60 ; sc_threshold: 40
　　[h264 @ 0x6fb1dc]slice I:51 Avg QP:27.94 size: 12586

　■300
　　INFO : lavcEncoder: - gop_size: 12 ; max_b_frames: 3 ; qcomp: 0.60 ; sc_threshold: 40
　　[h264 @ 0x6fb1dc]slice I:349 Avg QP:29.07 size: 12329

>KeyFrame:Autoの時はMaxにするか、120くらいにするかとかのほうがいいでしょうか。

　x264cli/MEncoderではfpsの10倍が一般的ですので、端的な要望としては：
　・BEST；KeyInt=99,9999くらいまで受付（120fpsで2時間ちょい）。
　・BETTER；KeyInt=300まで受付。

　fpsの10倍は特に根拠があるわけではなく、ASP以来の慣習が定着したものです。
　H.264では、最大GOPサイズを長くしても「画質」が悪化せず、逆に最大GOPサイズを短くして沢山キーフレームを入れると、それがbitを費消し、bitあたりの画質が落ちます（crfならサイズ増加）。最長GOP単位が決めるのは純粋にシーカビリティだけという特徴があります。
　x264cli/MEncoderではシーカビリティをASP同等に保った上で、x264の圧縮効率を画質向上/総bit量削減に使う設定例が多いです。

　しかしそれとは別に、KeyFrame:Autoの時はそのままでも良い気がします。圧縮効率でシーカビリティを買うという方向です。
　QTPの早送り・巻き戻し・マウスホイールをコロコロした時の追従性は、gop_size: 12とgop_size: 250でかなりの差がありました。特に巻き戻し。
　画質/bitの比較では不利ですし、VLC/MPlayerのUIでは活かせませんが、このへんの感覚的な操作感はQTPの持ち味ですし、VGAで2000程度のbitrateを許容できるなら、数値画質もそう悪くないはずです。

　イ・QTPProの"キーフレーム：自動"はおそらく映画向け。シーク間隔は最長0.5秒。画質/bitは低い。
　ロ・MPEGstreamclipはAppleの推奨に従って、シーク間隔は最長5秒・画質/bitはやや低。
　ハ・fps*10の場合、シーク間隔は最長10秒・画質/bitはやや良。
　ニ・keyint=素材フレーム数以上（場面転換以外のキーフレーム全排除）でシーク間隔は場面転換単位。画質/bitは最良。

　BESTでイ、ロ、ハ、ニ。BETTERでイ、ロ、ハ、がカバーできます。

参考：Man/CODEC固有オプション/-x264encopts
　http://www.wikihouse.com/htumenc/index.php?Man%2FCODEC%B8%C7%CD%AD%A5%AA%A5%D7%A5%B7%A5%E7%A5%F3%2F-x264encopts#s39c073e
keyint=<value>
　IDRフレームの最大間隔
　大きい値の方がbitが節約できるので品質が向上するが、シークの精密さと引き換えになる。
　MPEG-1/2/4とは違って、H.264はkeyintを大きくしてもDCT driftで苦しむ事が無い。
　（＊DCT計算を整数で行うので誤差蓄積が無い、デコーダ毎の計算精度による誤差が出ない、という事のようです＊）。
keyint_min=<1-keyint/2>
　IDRフレームの最小間隔を指定。
　この最小間隔の中にシーンチェンジが含まれた場合、エンコードはIフレームとして行うが、新しいGOPを開始しない。
　H.264では、Iフレームは必ずしもclosed GOPに束縛されない。
　なぜなら、Pフレームを直前より前のフレームを基に予測しても良いからだ (framerefも参照)。この為に、Iフレームは必ずしもシーク可能では無くなった。
　IDRフレームは、後続のPフレームに、自分より前にある全フレームを参照禁止にする。
scenecut=<-1-100>
　scenecutの値が低いと、このコデックはしばしばkeyint間隔よりも大きな間隔でIフレームを入れてしまう。
　scenecutの値が適切なら Iフレームはもっと良い位置に挿入される。
　大きすぎる値を使うとIフレームを必要以上に入れてしまい、bitが無駄になる。
　-1 は自動シーンカット検出を無効にする。従ってIフレームは、たとえ場面転換があろうとも、keyint frame間隔毎にしか挿入されない。これはオススメできない。なぜなら、この場合に場面転換地点で生成されるPフレームはIフレーム同然にサイズが大きくなるのでビットレートの無駄だし、その上"keyint counter"にもリセットがかからないからだ。
frameref=<1-16>
　P／Bフレームは予測の際に自分より前のフレームを参照フレームに使う。
　H264/AVCでは直前よりも前のフレームを参照フレームに使う事ができる。
　このオプションはその際、最大でどのくらい前のフレームを参照フレームとして使えるかを指定するもの。
　アニメには効果的だが、実写では6程度を境に効果が急激に低下する。
　デコードの速度には影響しないが、必要メモリ量が増える。
　デコーダによっては最大15までしか受け付けない。

[ 2007/03/22 20:59 ] [ 編集 ]

コメントの投稿