2005年12月21日

ケロロ軍曹#89_ギロロ 七つの顔の男だぜ/冬樹 盛り上がれ!オカルト大会(1216)

【概要】threadsは分散する程速くなり、画質(圧縮効率)が落ちる。というのを試してみた。
【タグ】[threads][MEncoder][x264]
機 材:
Power Mac G5 (2Ghz dual), memory 1GB

設 定:
(1stのみ)
下記 "threads=<1-4>"を変更。2ndパスは"turbo=1"削除、"pass=2"に変更。
なお、ffmpegXのデフォルトは"threads=2"。
mencoder Keroro1216.mpeg \
-nosound \
-ovc x264 -x264encopts \
threads=2:me=3:bitrate=1078:qp_min=10:qp_max=51:i4x4:4x4mv:frameref=5:mixed_refs:subq=6:brdo:trellis=2:\
keyint=230:scenecut=30:cabac:deblock:nob_adapt:bframes=1:psnr:turbo=1:pass=1
-passlogfile Keroro1216.264.log \
-vf pullup,softskip,crop=704:464:8:8,scale=640:480,hqdn3d=4:3:6,pp=l5,harddup \
-sws 10 -ofps 24.000 -of rawvideo -o Keroro1216.264
結果:(最善は太字)
threads= 1 2 4 差 (4 - 2)
PASS1
経過時間 速い程良い 1:53.28 1:18.7 1:17.7 -1
Vbitrate(kbit/s) 指定値は1079 1090.750 1091.638 1093.456 1.818
PSNR:Global(db) 高いほど高画質 46.001 45.968 45.917 -0.771
Avg QP(I) 低い程高画質 16.28 16.34 16.46 0.12
PASS2
経過時間 速い程良い 4:52.11 2:54.9 2:45.11 -9.79
Vbitrate(kbit/s) 指定値は1079 1078.113 1079.075 1081.015 1.94
PSNR:Global(db) 高いほど高画質 47.119 47.093 47.051 -0.042
Avg QP(I) 低い程高画質 16.67 16.69 16.79 0.1
特記事項 QT7 で映像が
出ない。
問 題無し 問 題無し
分散数が増える程、以下の事が言えそうだ。
  • プラス項目
    • ◎:速度向上:threads=4 でも僅かに向上。CPUの空回りが減ると思われる。
  • マイナス項目
    • ×:ビットレート指定を守りきれない:上限に厳しい機器でもそう五月蝿くはないと思う が。
    • ×:Avg QP(I)は上がる:16は無駄に低いらしい。ffmpegX作者は20で充分と。
    • ×:PSNRが下がる:PSNRはよくわからない。ここからそれっぽい文章を拾ってみる
      • ・0.2-0.5 dB向上します。これは通常は充分に目で見て解る違いが出ます。
        ・0.15dB程度は向上し、速度低下は5-10%です。これは良い取引に思えます。
        ・0.25dB程度、これは目で見て解る違いです。
        ・0.02dbはやっとこさ計測できるくらいで、目で見て感じる事も難しいでしょう。
        ・だいたいPSNR低下は0.1db以下に収まります。目で見てわかるレベルではありません。
      • 「0.1以下の差は目で見ても解らない。0.2の差は解る。」く らいで良さそうだ。となると画質的にはtreads=1が最善だが、QTで絵が出ねぇのはなんでだ^^;(10月半ば以降、全てのTVキャプチャを x254に移行しているが、これは2回目。手許では稀なケース。基本的にVLCで見るので問題ないが。)
VLC0.8.4aで見比べてみたが、自分の視覚では違い が解らなかった。

まとめ:
24分のアニメで4時間ちょい。DualCPUの threads=4で、0.042dbの画質低下と引き換えに得られる時間短縮は10秒。
自分の視覚では画質差は解らない。
とことん速度を追うならthread=4を使うべきだろうが、DualCPUではthreads=2が妥当なところだろう。
  1. シングルCPU機では、threads=2(ffmpegXのデフォルト)は、速度向上も画質低下も同程度に留まると思われる。
  2. 逆に、Quad CPUではthreads=4で劇的に速度向上しそう。
  3. x86では、シングルCPUでも多段パイプライン(ハイパースレッディング)に期待できるかも。
(余談)Apple-H.264の印象
自分の理解では、AVC/H.264規格の性格は「取るに 足りないオプションを山のように積み上げ て全体のPSNR向上を図るもの」だ。
x264はそれを忠実にDVDバックアップ目的に合う範囲で追っている。
Apple-H.264はアクティビティモニタで見る限り、7〜8スレッドに分散する。各パスは高速だがパス数は3〜5程度に見える。
「取るに足りないオプションを無視。素材分析を山のように繰り返して全体のPSNR向上を図る」。
しんくでぃふぁれんと。 シンプルで、失敗が少なそうなアプローチだ。パテント料も抑えられる(Appleは動画エンコードのパテントを持たない)。
代償としてCPUのアタマ数が必要になる。
このチューニングが妥当な領域は、ネットワークエンコードが使えるハイビジョン製作のプロ/ハイアマチュアではないか。
その領域では、スレッド上限4のx264は速度面で太刀打ちできないだろう。
しかしTVキャプチャでは牛刀の印象がある。ましてiPodの320x240,cabacもBフレームも無いBaselineにおいておや。
Apple-H.264でパス数指定ができればそこそこの画質が実用的な速度で得られそうな気がするが、そうなるとiTMSの売り上げに響くのであらふ。
ま、商売だから当然なんだけど。宣伝を額面通り受け取る義理はねぇのす。
posted by ばる at 22:28| Comment(0) | TrackBack(0) | 圧縮日記264 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

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

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

コメント: [必須入力]

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


※画像の中の文字を半角で入力してください。
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/10911853
※言及リンクのないトラックバックは受信されません。

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

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