Ronnie
2003-08-22 19:50:55 ( ID:qpydpl.0dhh )
[ 削除 / 引用して返信 ]
Xeon 3.06GHzのデュアルでPCを作ろうと思っているのですが、
TMPGEncを使用して、
huffyuv(YUY2 704*480)・音声PCMのaviファイルをmpeg2(704*480)・音声mp2に
2passVBRを使って圧縮する場合、特にフィルタを使わなければ
ソースの実時間内にmpeg圧縮を完了することはできるでしょうか?
ちなみに現在の環境(WinXP-Pro・P4 2.26GHz)では2passVBRを使うと
ソースの時間の4倍程度かかってしまいます。
(これでもP2・P3の時代と比べれば信じられないくらい速いのは分かっています。)
過去のスレッドを見てみると、デュアルでも単純に2倍の速さになるわけではない
らしいので、2passVBRで実時間内というのは厳しそうにも思えます。
まあ数年もすれば、ノイズフィルタを使って実時間のハンブン。なんて欲求も
でてくるんでしょうが、、、。
fay
2003-08-23 01:30:35 ( ID:rvwdyk8hxf. )
[ 削除 / 引用して返信 ]
3.06Gで試したわけではありませんが、2.4Gからの推測で言うと実時間内に圧縮できません。
Xeon3.06Gで論理4CPU用意しても、TMPGEnc Plusでは2CPUまでしか使用しません。
私の試した限りではP4-3.06G(HT-ON)で1パスに実時間の85〜90%程度かかります。これか
ら考えると、2パスで実時間の2倍程度掛かることを前提にP4-3.0Gを買うというのも手かも
知れません。(価格効果比というわけですが)。
あと、huffyuvの展開はかなりCPUパワーを消費しますので、速度を重視するなら不利といえ
ます。まあフィルタを掛けた状態で2パスすることを考えると雲泥の差がありますが。
Ronnie
2003-08-23 06:41:30 ( ID:qpydpl.0dhh )
[ 削除 / 引用して返信 ]
たしか、3.06GHzより3GHzのPentium4のほうがFSBの関係で若干速いんでしたよね?
ところで3GHzで実時間と同じというのは本当ですか?
先ほど次の設定(mpeg2 704*480-4:3 固定品質 逆3:2プルダウン 検索精度-標準
フィルタ無し)でエンコードしてみたのですが、P4-2.26GHzでソース時間の
2.5倍ほど掛かりました。huffyuvだからでしょうか。
それとも+740MHzとFSB800MHzとHTの効果がすごいってことでしょうか?
もしよかったらそのときの設定を教えていただけませんか?
まあ、速さにこだわるんだったら、TMPGEncに固執しないで他のエンコーダを
使えばいい話なんですが。
fay
2003-08-23 11:47:47 ( ID:rvwdyk8hxf. )
[ 削除 / 引用して返信 ]
TMPGEncでのエンコードで影響が大きいのは、HTの有無です。これがあれば、シングルCPUでも
大体30〜40%程度時間を短縮できます。クロックやFSBももちろん影響しますが、HTほどの効果
はないようです。
huffyuvについてですが、簡単なテストをしてみました。Xeon2.4GやP4-3.06Gは手元にある
PCではないので、自前のP4-2.4Gです。ソースはCMを92秒程度(720x480 2763frame)で、
これをIris(DVコーデック)とhuffyuvで保存してそれをMPEG-2(ウィザード設定CBR-8Mbps、
映像のみ)にエンコードしました。結果は以下のとおり。
Iris = 150秒(実時間比163%)
huffyuv = 228秒(実時間比247%)
非圧縮 = 208秒(実時間比226% ただしHDDがボトルネックでCPUが100%まで使われず)
huffyuvがどのくらい重いのか分かる結果だと言えます。TMPGEncではAVIに対してRGB24でア
クセスしているはずです。だからhuffyuvでYUY2保存していた場合、読み込み時にCodec内で
は圧縮展開と色空間変換が発生しているものと思われます。
上記のIrisでの結果を元に、P4-3.0GHzの速度をHTの効果35%、クロックアップ&FSBアップ
15%として換算すると、1パスで実時間は十分に切れると言うことが分かるかと思います。
もちろん、huffyuvとIrisとでは画質に差がありますので、結果が同じになるわけではありま
せん。このあたりはトレードオフということになるでしょう。
akira_cx
( Home )
2003-08-23 16:28:39 ( ID:6coxl57qy4k )
[ 削除 / 引用して返信 ]
3.06GHzではありませんが、Xeonなマシンが手元にありますので、テストしてみました。
環境は以下の通り
SuperMicro X5DAL-G
Xeon 2.4GHz(FSB533MHz)×2
DDR333 512MB×2(DDR266動作)
WindowsXP Professional SP1
90秒のCanopus MotionJPEGソース→MPEG2のエンコード(ウィザード設定CBR-8Mbps、映像のみ)を
CPUをON,OFFにしてエンコード時間を計ってみました。
左からCPU0,1,2,3のON(o),OFF(x)状態を示します。
oxxx(1CPU,HT OFF) 214秒 (実時間比237%)
oxox(1CPU,HT ON) 131秒 (実時間比145%)
ooxx(2CPU,HT OFF) 110秒 (実時間比122%)
同じ映像ファイルをDV(Iris)ソースに変換した物でも試してみました。
左からCPU0,1,2,3のON(o),OFF(x)状態を示します。
oxxx(1CPU,HT OFF) 176秒 (実時間比195%)
oxox(1CPU,HT ON) 117秒 (実時間比130%)
ooxx(2CPU,HT OFF) 91秒 (実時間比101%)
2.4GHzDualでほぼ実時間エンコードできましたので、
3.06GHzのDualであれば、実時間を切ることができることでしょう。
しかし、エンコードのみであれば、Dualでほぼ倍速、HTでも5割の高速化されるのですね・・
Ronnie
2003-08-23 16:55:38 ( ID:qpydpl.0dhh )
[ 削除 / 引用して返信 ]
fayさん、akira_cx さん、二人とも実験ご苦労さまです、とても参考になりました。
Xeon dualでも1passで実時間を切るかどうかの次元なんですね。
>TMPGEncではAVIに対してRGB24でアクセスしているはずです。
そうだったんですか、、知りませんでした。
だれでもそうだと思いますが、mpegに圧縮するためのソースはできるだけきれいな
ものが良いので、すでに圧縮されているDVは使おうとは思いません。
色もかなり間引かれてますし。
やはり、可逆圧縮のhuffyuvか無圧縮のaviってことになります。
2passで実時間はもう少し先の話になりそうですね。
TMPGEncの話ではありませんが、私はキャプチャーボードにSAA7130搭載のやつを
つかってますが、これはA/D変換をした時点でYUY2になっているので、
RGB24でキャプチャーすると余計なデータが付いて後々不具合が生じる、というのを
何かで見たおぼえがあるような気がします(違うボードだったかも)。
早い話がこのボードでRGB24で取り込んでも色空間的に
問題が有るか無いかを知りたいのです。
ご教授くださいませ。
fay
2003-08-24 21:19:47 ( ID:rvwdyk8hxf. )
[ 削除 / 引用して返信 ]
ソースをできるだけ綺麗にしたほうが良いというのは確かです。ソースの読み込みでは
ファイル読み込み時間と展開時間の2つがあるわけですが、huffyuvではそのどちらも
結構かかってしまいます。ファイルは大きくなってしまいますが、YUY2非圧縮で保存し
たほうがhuffyuvの時よりも早くなるかもしれません。
最近のキャプチャ機器ではYUY2でデータを出力するものが多いですね。これらの機器で
RGB24キャプチャをするのは結構厳しいんじゃないかと思います。色空間変換が必要で
すしデータ量も増えますので、コマ落ちする確率が格段に上がると思います。また、そ
うしたからといって、画質が良くなるとも思えません。
YUVとRGBの変換としては、RGB24からYUV系への変換は式が決まっていますが、逆はそう
でもありません(RGB→YUVの逆算をしているのが殆どかな?)。YC伸張するかストレート
のままかという話もあります。このあたりで問題のある処理をしている機器やソフトが
あるかもしれません。
TMPGEncはRGB24で読み込んでフィルタも全てRGB処理、エンコード直前でYUV420変換して
いるそうです。
Ronnie
2003-08-25 15:14:19 ( ID:qpydpl.0dhh )
[ 削除 / 引用して返信 ]
文面から分かると思いますが、私は初心者に毛が生えた程度の人間です。
TMPGEncはキャプチャされたYUV422のデータに空白のデータを入れて
YUV444(RGB24)として見立てるわけですよね?
mpegに圧縮する際、YUV444(実質YUV422)からさらにをYUV420に間引くわけですから、
色情報の劣化はかなり深刻ですよね?
解決する方法としてはTMPGEncがYUY2での展開をサポートするか
RGB24でキャプチャできるボードを探すか、なんですが、
各キャプチャボードのメーカーのHPにはそこまで詳しく解説されていません。
どうしたものか、といったところです。
たしかMTV系もA/D変換でYUV422だったと思いますが、あれらのハードエンコード部分も
YUV422に対してRGB24でアクセスしているんでしょうか。
私が言いたいのは、YUV4:2:2のデータに対して直通でmpegのYUV4:2:0に
間引くことができれば色の劣化は最小限にとどめられるんじゃないの?ってことです。
fay
2003-08-25 23:24:23 ( ID:rvwdyk8hxf. )
[ 削除 / 引用して返信 ]
> TMPGEncはキャプチャされたYUV422のデータに空白のデータを入れて
> YUV444(RGB24)として見立てるわけですよね?
> mpegに圧縮する際、YUV444(実質YUV422)からさらにをYUV420に間引くわけですから、
> 色情報の劣化はかなり深刻ですよね?
YUV422からRGB24への変換はコーデックが行うため、TMPGEncが何らかの処理をしている
わけではないでしょう(カノープスDVコーデックのみは別処理)。コーデックに対して
RGB24でデータを渡すように要求しているのです。
YUY2からRGB24への変換では、計算によって誤差は生じますが基本的に劣化は生じないと
考えられるでしょう。もちろん何度も何度も行えば誤差が目に見えるようになります。
しかし1回の変換による劣化が気になって仕方がないという人は、エンコード後の映像な
んか酷くて見てられないでしょう。
> 解決する方法としてはTMPGEncがYUY2での展開をサポートするか
> RGB24でキャプチャできるボードを探すか、なんですが、
TMPGEncがYUY2展開をサポートしても、他の部分が今と同じでは何の意味もないと思いま
す。RGB24への変換がコーデックで行われるかTMPGEncで行われるかの違いでしかありま
せん。TMPGEncでは内部処理をすべてRGB24で行うことによって不要な色空間変換が発生
しないようにしているので、YUY2のままでエンコーダへデータを渡すには、RGB24で行わ
れている処理をYUY2で作り直す必要があります。
もちろんYUY2で入力されるなら、そのままでエンコーダに渡すのが劣化の面ではよいで
しょうが、TMPGEncの基礎設計が行われた1997〜8年あたりにYUY2で全ての処理を行うと
いう発想はなかったと思います。またYUY2などのYUV系で入力できないコーデックはた
くさんありますが、RGB24で入力できないコーデックはまずありません。このあたりが
RGB24で統一されている一つの理由でしょう。
> たしかMTV系もA/D変換でYUV422だったと思いますが、あれらのハードエンコード部分も
> YUV422に対してRGB24でアクセスしているんでしょうか。
MTVはYUVのままでエンコードしているでしょう。RGB24で処理する理由はありません。
|