TMPGEnc Video Mastering Works 5 日本語版(グラフ82)

2011年1月11日、編集部追記:
Intel Media SDK 2.0を利用したエンコードについて、本稿の内容ではハードウェア・エンコードを適切に検証できておらず、本来の性能が発揮できていなかったため、改めて以下の再検証記事を掲載しました。
【レビュー】"Sandy Bridge"追加検証 - TMPGEnc Video Mastering Works 5のHW処理を改めて試す
http://journal.mycom.co.jp/articles/2011/01/11/sandybridge/

こちらは2010年12月22日に発表されたばかりの新製品で、しかもまだ発売は今年1月12日という状況なので、今回は同社サイトで公開されている体験版を使っての評価である。

さて、このTMPGEnc Video Mastering Works 5であるが、残念ながらAVXには今のところ未対応である(Photo56)。ところがIntel Media SDKには対応しており、同社のサイトによれば効果がありそうな数字が掲載されている。もともとIntel Media SDKは以前から公開されており、最新版のIntel Media SDK 2.0ではSandy BridgeのGPUに含まれるMedia Processing Unitに対応が表明されているが、TMPGEnc Video Mastering Works 5はこのMedia SDK 2.0を利用しており、なのでSandy Bridgeではこれを使うことで高速化が可能、という話である(Photo57)。

Photo56: この通り、AVXへの対応は含まれて居ない。もっとも現状のAVX Interger命令の性能を見る限り、あえてAVXに対応する必要性もなさそうだが。将来、更に高精度なMV取得とかを目指して内部を浮動小数点演算で実装するとかいう時には効果があるかもしれない。

Photo57: ちなみにMedia SDKに対応するのはH.264のエンコード時のみ。

ということで結果はグラフ82に示す通りだが、「あれ?」という結果に終わった。今回はi7-2600Kのみでテストを行ったのだが、Intel Media SDKを使うと性能がガタ落ちする。

実はこれは、もう少し解説が必要だ。TMPGEnc Video Mastering Works 5は内部をずいぶん改良したようで、映像ソースが1本の場合であっても、MPEG2(Photo58)とH.264(Photo59)、どちらの場合でも8つのCPUをフルに使い切っている事がわかる。ところがIntel Media SDKを使う設定にすると、CBR(Photo60)、VBR(Photo61)のどちらでも、CPU負荷率が非常に低い。要するに処理のほとんどをGPU側で行っており、CPUは遊びまくるという状況だ。これはVBR/CBRでエンコード速度がほとんど変わっていないことからも推察される。このGPUのMedia Processing Unitの性能を敢えてCPU能力に換算すれば、CBRの場合でCPUコアの2.3倍、VBRの場合でCPUコアの4.5倍程度の処理性能を持っている計算となる。

Photo58: MPEG-2のエンコード。ご覧の通りCPU利用率は95%～100%の間を推移している。

Photo59: H.264のエンコード。こちらも(MPEG-2よりはややばらつきがあるが)高い利用率を維持している。

Photo60: CBRの場合、実質的なCPU利用率は13%前後。

Photo61: VBRにすると若干増えるが、それでも15%前後。

先のPegasysの図版が嘘とはいえない(入力ソースのフォーマットも異なるし、環境もだいぶ違うし、オプションもいろいろ異なる様だ)が、だからといってMedia Processing Unitを使えば速くなる、というものではないことは確認できた。たぶんこの機能はノートなど熱的に苦しいため、コア数を増やしたり動作周波数をあげたりしにくいケースでは有用に思えるが、Core i7-2600Kで使う場合は素直にCPUを使ってエンコードしたほうが良さそうである。