2006年03月18日

L.F. Info-Station Access Terminalさんの設定を読んでみる。

【概要】x264-Rev.468の設定例が公開されていた。
【リンク】2006/03/18 -- x264 H.264/AVC Video Codec Rev.469( L.F. Info-Station Access Terminal)
昨 日見つけたブログでRev.468の設定例が公開されていた。すばらだぬしい。

Win界でいくつか配 布されているビルド済み品をお使いのようだ。vfw: yesとあるからAVI/VfWインフラ上のソフトではGUIで設定できるのだろう。

肝心の設定、基本はデフォルト設定のままとあるが、これ、ハイ・プロファイル(FRExt)に見える。
即ち、現状Mac OS XではVLC/MPlayerでなければ再生できない。
やはりx264の「デファクト」はハイ・プロファイルになるのだろうか。
Win版QTの出来はMac版WMP並みの様子なので、素でMP4サポートの無いWinではMediaPlayerClassicで再生と言う事になるの だろう。

とりあえず、設定部分をコピペさせてもらってMEncoder -x264encoptsのメモを付加。
MEncoderのwikiがここんとこ調子悪いのでリンクは貼れない。

/*/

・Bitrate

Multipass(2th Passまで使用) Target Bitrate 2048
MPlayer -MLでは1300で大半の映画は十分とする人を見かけた。Doom9のVoteで最多は700〜900(概ね映画の1CD化)。
日本語のブログでは、もう一件、2048で2パスを常用されている方がおられ る。
手許では1024固定。Xvidでもそうだったので比較しやすいから。

・Rate Control

キーフレーム品質上昇率(%) 50
ip_factor =<value>:I-P間のquantizer換算係数(デフォ1.4)か?1.5で同じになりそう。
Bフレーム品質減少率(%) 30
pb_factor =<value>:P-B間のquantizer換算係数(デフォ1.3)か?これは同じだな。
ビットレート変動率(%) 100
ratetol=<0.1-100.0> (ABR or two pass):平均ビットレートにおける変動幅の許容値。(特定の単位は無い)か?
デフォ1.0だから同じ。
最小1/4画素精度補正 10
対応不詳、 x264cliのどれかも不明。
最大1/4画素精度補正 51
対応不詳、 x264cliのどれかも不明。
最大1/4画素精度補正回数 4
対応不詳、 x264cliのどれかも不明。

*subq=<1-6>: subpel精製品質の調整。か?常用5。

シーン変更閾値 40
scenecut =40。デフォ値。シーンチェンジ検出精度。すなわちIの挿入性向。
キーフレームの最小間隔 3
keyint_min =<1-keyint/2>。デフォ25。IDR(キーフレーム)の最小間隔。H.264/AVCIにはキーフレームになら ないIがある。
frameref=<1-16>(符号化ツール"multiple reference frame")が使える為。
画質の為にはキーフレームよりscenecutを増やすほうが符号化効率が良い。keyint系はよりシークに特化した印象。
キーフレームの最大間隔 300
keyint =<value>。デフォ300。IDRの最大間隔。

・MBs&Frames

8x8 離散コサイン変換
(no) 8x8dct。High profile。Main profileでは4x4dctのみ。Xvid等では素で使っていた8x8dctが無い事が、MainがなかなかMPEG2に勝てない状況を生み、 FRExt誕生の端緒となったようだ。
PフレームにMB単位の動き補償を行う
(no)8x8mv?
BフレームにMB単位の動き補償を行う
(no)b8x8mv?
PフレームにサブMB単位の動き補償を行う
(no)4x4mv?
8x8 イントラ動き補償
i8x8? ならば要8x8dct
4x4 イントラ動き補償
i4x4?

x264cli とMEncoderではマクロブロック・パーティション分析の分類が異なり、上にあげた相当オプションには疑問が残る。
x264cli は、-A, --analyse <string>。["p8x8,b8x8,i8x8,i4x4"]
MEncoder は、(no)4x4mv、(no)8x8mv、(no)b8x8mv、(no)i4x4、(no)i8x8
x264よりもMEncoderに即した分類にも見えるが、、、。

mvはおそらく「モーションベクトル」で、ベクトルを使うのは「動き補償」のハズだ。

Bフレームの最大連続数 2
bframes=2
偏り 0
b_bias =<-100-100>?。デフォ0。b_adaptの決断力=bの挿入性向。
フレー ムを参照する
b_pyramid?。 Bを参照フレームに使う。QT非互換。プロファイル不詳。
双方向予測(ME)
(no) bime?
適応型
(no) b_adapt?。Bが不適切なシーンで使用を控える。手許ではPが連続するシーンが発生する。weght_bよ り優先的に適用される傾向があり、併用する意味があまり無い印象。
インター予測符号化
対応不詳、 x264cliのどれかも不明。
Bフレーム動き予測モード Spatial
direct_pred =<0-3>。1:空間軸(default)、2:時間軸、3:AUTO。
アニメは空間軸が良。時間軸だとゴーストが出るとされる。時間軸が向く素材もある。
3はこの点を解決&速度低下、とmanにはある。手許の速度低下は微々たるものだが画質向上は見ても解らないレベル(自分には)。
なお、ffmpegX0.0.9v版は3を選べない。

・More...

ブロック分割の精度 6b (RDO on B-frames)
brdo
動き予測タイプ Exhaustive Search
me=& lt;1-4>。4=Exhaustive。MEncoder Documentでは実用上3を推奨。手許でも4と3の速度差は激しい。
強度 16
me_range =<4-64>:meで使う動き捜索範囲か?デフォ16。
me=4:
me_range=64で24分のアニメ が1パス80時間を超えた(PowerMacG5 2GHz)。
彩度動き予測(ME)
(no) chroma_me:サブピクセル動きサーチで彩度情報も参照。デフォon。
白黒映画でも見やすさの為に彩色してあるが、一律に塗ってあるのであんま意味ない。
最大参照フレーム数 1
frameref =<1-16>:P/Bフレームが参照する自分より前にあるフレームの数。デフォ1。
規格上の符号化ツール名「multiple reference frame」。手許の常用は1st=1,2nd=4。
アスペクト比率 16:9
x264cli の"--sar width:height  "?
手許では横幅640に縮小してしまう。mencoder -sws 9(Lanczos)。
ログモード Error
log =<-1-3>:スクリーンに表示するログ情報量の調整。デフォ0(エラーのみ)。
コマンドラインツールではターミナルに吐くメッセージの細かさを調節するものだが、vfwでどう表示されるかは不明。
CPUスレッド数 1
threads =<1-4>。手許では2。CPU/コア数より多くしても僅かに速度メリット有り。CPU使用率が地味に上がる。空回りが地 味に減るようだ。
映像ストリームを「スライス」なるものに分割するので画質とbitrate指定値にややデメリットがある。

識別拡張子 H264
H.264/AVC Raw Video Stream。.m4vの事もあるらしい。
AppleがiTMSで使う.m4vは実体が.mp4の独自用法。Doom9では”間違った”使 い方としている。
CABAC
(no) cabac。
格子処理
trellis =<0-2>。rate-distortion最適化のquantization(量子化)
0はオフ、1は最終エンコードのみ。2はモード決定の 全段階で使用。常用は1。
ノイズ低減フィルタ 0
nr =<0-100000>。デフォ0。
手許ではmencoder -vf hqdn3dを使うが、これより速いらしい。mencoder documentには適正範囲100-1000とあるが、素材次第だろう。

/*/

感想
とりあえず年頭に
Win界でQT非互換・MPEG4 AVC規格適合の.mp4ファイル作成が加速する。」 と予想したが、MeGUIはデフォでメインを吐くようなのでまだなのかなと思っていた。x264vfwのデフォは既にHigh profileに移行したのだろうか。
posted by ばる at 22:58| Comment(0) | TrackBack(0) | その他 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス: [必須入力]

ホームページアドレス: [必須入力]

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。