SSDでエンコード速度は向上するのか

　前回のエントリでPhotoFast G-Monster-V2をRAID0で投入してみましたが、いよいよ（個人的には）本編の、SSDでエンコード速度が向上するのかを試してみます。
　より実際に使用する例に近く、ということで、今回は24分程度のアニメ動画を用意し、DivXへのエンコードを試してみることにしました。何故今までと同じ（実写動画をH.264エンコード）ではないかというと、実写ソースならH.264にしたほうがよく見える→わざわざDivXを使用しなくとも、H.264を使用する→H.264ならどう頑張ってもFIRECODER-bluには勝てない、という理由からです（笑）
　さらに今回は、せっかくIntel Core i7を使用しているのだから、ということで、Intel Turbo Boostを有効にして計測してみました。
■ 元データ情報
映像コーデック：Canopus HQ Codec（オンライン－標準）
音声コーデック：非圧縮WAVE 48kHz
ソースの解像度：1920×1080（29.97i）
ファイルサイズ：11,146,128,668バイト（10.3GB）
クリップの長さ：23分34秒
■ エンコード環境
M/B : MSI ECLIPSE SLI
CPU : Intel Core i7-920
Memory : DDR3-1066 1GB×3
OS : Windows Vista Service Pack 2β
HDD : BUFFALO HD-QS2.0TSU2/R5（RAID5 / eSATAへ接続）
SSD : PhotoFast G-Monster-V2 ×2（RAID0 / ICH10Rへ接続）
エンコーダ : TMPGEnc 4.6.3.268 ＋ DivX 6.8.5製品版
TMPGEncのフィルタ : デフォルト設定
DivX Codecの設定 :
　レートコントロール＞「1パス-品質依存」
　コーデックパフォーマンス＞「最も優れた品質」＋「SSE4を使用可能」＋「エンハンスドマルチスレッド」
※出力解像度＆音声フォーマットとDivXのフィクスドクォンタイザは後述します。
※HDDでもSSDでも、入力元ファイル／出力先ファイルは同じドライブを使用しています。つまりHDDならHDDから読んでHDDへ書き、SSDならSSDから読んでSSDへ書き込んでいます。
▼ ケース１：出力解像度を640×360 29.97i（SD）、音声をmp3 192kbps Joint Stereo、クォンタイザをQ4にしたケース
　まずは単純にHDソースをSDソースに変換する例です。画像は左列がHDD（上段がTurbo Boostオン、下段がオフ）での結果、右列がSSD（こちらは両方ともTurbo Boostオンで、上段がストライプサイズ128K、下段が4K）での結果となっています。

　

　結果を並べると、31分14秒：27分46秒：26分00秒：25分46秒ですので、HDD/Turbo Boost無しを基準とするとそれぞれ 0分 0秒：－3分28秒：－5分14秒：－5分28秒、クリップの長さと比較した割合はそれぞれ 132.5％：117.8％：110.3％：109.3％ となり、予想通りの結果となりました。とはいえ（人によっては）たった1分46秒の差が6.5万（RAID0なら13万）、と考えると微妙とも言えますが、ここをプラス思考として考えるのなら、13話分まとめてバッチエンコードすると約1話分時間が空く、ということになります（＾＾；
▼ ケース２：出力解像度を1920×1080 29.97i（HD）、音声をmp3 192kbps Joint Stereo、クォンタイザをQ4にしたケース
　読み書きの量が多くなれば、当然差も広がってくるのではないかと考え、HDソースをHDソース（のDivX動画）に変換する例で比較してみます。画像の並びは先と同様、左列がHDD（上段がTurbo Boostオン、下段がオフ）での結果、右列がSSD（こちらは両方ともTurbo Boostオンで、上段がストライプサイズ128K、下段が4K）での結果となっています。

　

　順番に結果を並べますと、42分42秒：40分17秒：36分24秒：36分09秒、差はそれぞれ 0分 0秒：2分25秒：6分18秒：6分33秒、クリップ比ではそれぞれ 181.2％：170.9％：154.5％：153.4％となります。HDへの出力では4分程度の差が発生しているあたり、SSDの強さを遺憾なく発揮したというところではないでしょうか。
　逆にストライプサイズは、ベンチマークの数値ほど影響を与えていない結果になっているのも興味深いと思います。この辺りはCrystalDiskMarkやHD Tuneの測定ロジックによるところだと思いますし、アクセス方法はアプリケーション毎に違いますから、難しいところではないかと思います。
▼ ケース３：出力解像度を640×360 59.94p（SD）、音声をmp3 256kbps Stereo、クォンタイザをQ2にしたケース
　いわゆるインタレソースの2倍fps化というヤツです。最近はインタレ保持したままでも、再生側でデインターレース処理を行うことで綺麗に表示することが出来るようになっていますが、色々と考えるのが面倒くさいので（笑）ウチではこの設定を主に使用しています。なおこれはSSDのみで、ストライプサイズでの比較を行っています。

　結果は26分03秒 対 27分02秒 で、これはなんと逆にストライプサイズの大きい方が1分程度早い、という結果になりました。
　で、さらに同じ設定を Core2Quad Q6600＋HDD で実行してみたものはこちら。

　ソースの3倍弱となる、1時間04分03秒で処理が完了していました。Core i7（TurboBoost有り）＋SSD（ストライプサイズ4K）であれば、ほとんど同じ時間で 1920×1080 59.94p、音声 256kbps Stereo、クォンタイザQ2 のしているあたり、技術の進歩は凄いなあ、と痛感しました。
—
2009/01/05 6:47追記：
　Core2Quad Q6600のエンコード時間ですが、映像クロップフィルタと音声ノーマライズフィルタが追加されており、全く同じ設定ではありませんでした…申し訳ありません。
—
▼ SSDをICH10RのRAID0でなく単体で使用した場合はどうか
　左からケース１、ケース２、ケース３、オマケの1920×1080 59.94p Q2 の順です。

　　　

　SD画質のQ4というかなり限定された構成（ケース１）では、23分19秒（98.9％）とやっと100％切りを達成。ICH10RはソフトウェアRAIDなので、この処理にかかるCPU負荷が、SSDのRAID0化で向上した速度よりもエンコードに影響を与えた、という結果になりました。
　それ以外もケース２が36分07秒、ケース３で27分09秒、オマケで1時間03分08秒となり、いずれもICH10RでのRAID0より早いか、またはほぼ同じ時間となっています。つまり容量以外ではソフトウェアRAIDにする意味は何もない、ということになります。
　エンコードでプチフリーズ判定ができるのかどうかはわかりませんが、少なくとも読み書きを激しく行っているはずのエンコード処理において、目に見えて処理が停止するようなことは全くありませんでした。（もっともプチフリーズは、複数のI/Oが並列に発生しないと起こらないので、エンコード処理くらいでは該当しないかもしれません）
■ まとめ
– H.264へのエンコードは素直にハードウェアエンコーダを使用したほうがよい。（これは前から変わらず）
– ソフトウェアエンコードでIntelプラットフォームなら、Core i7＋Turbo Boostで使用するのをオススメ。（※AMDプラットフォームは、省電力のe系統しか触っていないのでよく分かりません^^;）
– PhotoFast G-Monster-V2使用では、HDDよりそれなりに早くなる。ただし価格に見合っているかどうかは各個人次第。
– PhotoFast G-Monster-V2＋ICH10RでのRAID0には、”エンコード速度”の観点に限った話ではうまみがほとんど無い。
– ただしまともなハードウェアRAIDコントローラでのRAID0では、結果が変わってくる可能性がある。
　以上、多分全く参考にならないレビューをお届けしました＾＾；