【タグ】[threads][MEncoder][x264]
機 材:
Power Mac G5 (2Ghz dual),
memory 1GB
設 定:(1stのみ)
下記
"threads=<1-4>"を変更。2ndパスは"turbo=1"削除、"pass=2"に変更。
なお、ffmpegXのデフォルトは"threads=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が妥当なところだろう。
(余談)Apple-H.264の印象:
自分の視覚では画質差は解らない。
とことん速度を追うならthread=4を使うべきだろうが、DualCPUではthreads=2が妥当なところだろう。
- シングルCPU機では、threads=2(ffmpegXのデフォルト)は、速度向上も画質低下も同程度に留まると思われる。
- 逆に、Quad CPUではthreads=4で劇的に速度向上しそう。
- x86では、シングルCPUでも多段パイプライン(ハイパースレッディング)に期待できるかも。
自分の理解では、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の売り上げに響くのであらふ。
ま、商売だから当然なんだけど。宣伝を額面通り受け取る義理はねぇのす。
x264はそれを忠実にDVDバックアップ目的に合う範囲で追っている。
Apple-H.264はアクティビティモニタで見る限り、7〜8スレッドに分散する。各パスは高速だがパス数は3〜5程度に見える。
「取るに足りないオプションを無視。素材分析を山のように繰り返して全体のPSNR向上を図る」。
しんくでぃふぁれんと。 シンプルで、失敗が少なそうなアプローチだ。パテント料も抑えられる(Appleは動画エンコードのパテントを持たない)。
代償としてCPUのアタマ数が必要になる。
このチューニングが妥当な領域は、ネットワークエンコードが使えるハイビジョン製作のプロ/ハイアマチュアではないか。
その領域では、スレッド上限4のx264は速度面で太刀打ちできないだろう。
しかしTVキャプチャでは牛刀の印象がある。ましてiPodの320x240,cabacもBフレームも無いBaselineにおいておや。
Apple-H.264でパス数指定ができればそこそこの画質が実用的な速度で得られそうな気がするが、そうなるとiTMSの売り上げに響くのであらふ。
ま、商売だから当然なんだけど。宣伝を額面通り受け取る義理はねぇのす。