#!/usr/local/bin/php 【Next-Zero】『GPGPU と NLE/「TMPGEnc と GTX285」』
 
 


楽天市場



B&H



Amazon.co.jp



・ ・ ・

 >>Grass Valley
 >>Adobe
 >>SONY
 >>Panasonic
 >>Manfrotto

 >>楽天市場
 >>ビデオ近畿
 >>SYSTEM5
 >>kakaku.com

【Next零 ;Key Contents】


reTMCD



Eye-One Display2
レンタル



非公式データバンク
EDIUS Bench



HVR-S270J
関連レポート


【Note; Affiliate】




サウンドハウス




Article offer cooperation


* * *
ACC*Software Leading...


Hosting Management by


* * *

BBS7.COM
MENURNDNEXT


<<< GPUfx と GTX285


〜 GPGPU と NLE/「TMPGEnc と GTX285」 〜


(提出日:09/09/15)



■TMPGEnc と GTX285

 GPGPUの利用が、映像処理の分野で大きく花開くことになった切っ掛けは、ペガシス社の“TMPGEnc 4.0 XPress”の対応であると言われている。
 TMPGEnc 4.0 XPress は、リリース発表の 2008年8月に GPGPUの一つである“CUDA テクノロジ”をテスト実装。
 ※http://tmpgenc.pegasys-inc.com/ja/press/08_0825.html
 その後の正式実装を経て、現在に至る。
 ※http://tmpgenc.pegasys-inc.com/ja/press/08_081030.html



<TMPGEnc 4.0 XPress>



 さて、TMPGEnc 4.0 XPress では、GPGPUの機能をフィルタ処理に限定して使用している(MPEG-1/2ではデコード処理もサポート)。
 将来的には、エンコードもサポートしていくという事であるが、早期実装とユーザの体感効果としては、フィルタ処理への適用が最適と開発陣は判断したようだ。

 その後、SpursEngine系のエンコードボードの登場によって、TMPGEnc 4.0 XPressでは、動画エンコードもCPU性能に頼らず、高速で行うことが可能になった。
 TMPGEnc 4.0 XPress の GPGPU機能と SpursEngine を組み合わせれば CPUに深く依存せず、高速処理が実現するのである。

* * *



 話を、TMPGEnc 4.0 XPress の GPGPUに戻そう。
 早速、GPGPUの効果を確認するために、テストエンコードを行ってみた。


 テスト条件を以下に示す。

 ・素材ファイル:Divx形式 720x480(16:9) 29.97fps 1500kbps 10分00秒
    ↓
 ・出力ファイル:Divx形式 720x480(16:9) 29.97fps 1500kbps 10分00秒


 以上の様にした。

 出力は全て 2pass エンコードで行う。

 このエンコードプロジェクトに対して、フィルタを適用する。
 適用したフィルタは、
 ・常にインターレース解除を行う:適応補間
 ・ノイズ除去:最大範囲(最低速)/時間軸:広い(低速)



 上記の設定で、GPUを使用しないCPUのみの時と、CPUとGPUを併用した場合とでエンコードテストを行った。


 以上の結果のように、GPGPUを活用することで処理時間が短くなったことを確認できた。
 さらに、この時の CPU:GPU の使用比率を観てみると約4:6 となっており、CPUのみとGPU併用時での CPU使用率の整合性が確認出来る。


 さて、それでは GPGPU適用で、フィルタに掛かる処理はどれほど高速化されたのだろうか?
 このテスト素材にフィルタ処理を施さずにエンコードすることで、GPGPUの効率が見えてくるはずだ。


 このように、フィルタ処理をしない場合であれば、720x480/10分00秒 のファイルを 6分半以下でエンコードする。
 フィルタを施すことで、CPUパワーだけなら大凡2.6倍の時間が必要となるのだが、GPUの力を借りれば 2倍強の時間で処理が出来たことになる。
 効率化という点では 20%程の改善である。

 この結果は、適用するフィルタや、CPUスペックなどによっても大きく左右される。
 ノイズ除去やインターレース解除以外の、シャープネスフィルタや色調補正フィルタでは、さらに効果が出てくるようである。


 余談だが、今回テストで選択した Divxコーデックでは、CPU使用率がエンコードに於いてはあまり上がらず、ハードウェアスペックに見合うだけの仕事が出来ていない。
 色々考えられる対策はしたのだが、向上はみられなかった。
 日頃のエンコード作業時は、TMPGEnc 4.0 XPress のバッチエンコードツールを利用して 4つほどのファイルを同時変換処理することで、CPU資源を有効に活用している。


■まとめ

 今回 GXT285を導入して、GPGPUの世界に少し触れてみたのだが、まだまだ仰天するような GPGPUのパワーは体験出来ていない気持ちである。

 確かに、EDIUS Pro 5 の GPUfx では覿面の効果を出したし、TMPGEnc 4.0 XPress のフィルタ処理にも一定の高速化をもたらした……。
 しかし、実験環境の SEREN-Va の CPU が Core i7 920(@3.06GHz)という事もあって、CPUの威力も、なかなかどうして侮れない。

 CPUパワーで太刀打ちが出来ないな……と実感したのは、SpursEngineを搭載した FIRECODER Blu のテストである。
 >>>『 FIRECODER Blu レポート』
 こちらは、H.264のエンコード時間に対CPU比で4倍〜9倍の圧倒的な差をつけて実行した。
 これには、凄いとしか言えなかった。
 しかしながら、GPGPUの現状の成果は、数十パーセントの改善に留まっている。

 やはりここは、エンコード/デコードの分野で、その真価を発揮していく事が必要だろう。
 そのために、NVIDIAなら CUAD、AMDなら ATI Stream という開発言語環境があるのだ。

 映像の世界では、ますます高解像度の映像処理が増えていく。
 現在は、日常的にフルHDを上限に扱うことが多いが、RED ONE に代表されるような 4Kクラスの動画も珍しい物で無くなっていくに違いないのだ。
 加えて、施されるエフェクトや映像処理もより一層品質の高いものが求められ、それ相反する要求として、ハイコストパフォーマンスな制作環境が必要とされるだろう。

 その際にクリエータの救世主となるのが、目の前に残されている膨大なGPUリソースだ。
 GPGPUの活用は、漸く始まったばかりであるが、各社各ソフトでさらなる最適化と進化を遂げていくことを、切に望む。


<左から、FIRECODER Blu/GTX285/Core i7 と並ぶ。>


 
 




<<< GPUfx と GTX285



△このページのTOPへ戻る