トップ過去ログこのサイトについて
1292106

脱サル

[PC&Digital] at 2009/06/27 01:18:45. / コメント(0)
 ついにイーモバイルのS11HTからApple(あえてSBMと言わない^^;)のiPhone 3GSにMNPしてきました。(実は勢い余ってMacBook Proを買いそうになったのは秘密)

 とりあえず連絡先を何とかしてスマートに移行しないと…

Core i7+GeForce+HDRECS

[PC&Digital] at 2009/05/02 01:04:00. / コメント(0)
 以前Core i7購入時のエントリでも書きましたが、長らくCore i7(X58チップセット)+GeForce+HDRECSの組み合わせでOS起動時にハングする問題ですが、NVIDIAが提供している最新版ドライバで解消されたようです。
 WHQL Driver 182.50、並びにベータ版 185.81で正常動作を確認しています。

Z-Driveもどき

[PC&Digital] at 2009/03/12 00:50:51. / コメント(2)
 せっかくなのでやってみました(馬鹿)
※真面目にマネをしない方が良いと思います…
  
<構成>
 PhotoFast G-Monster-V2 256GB×4
 HighPoint RocketRAID 3510

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

[PC&Digital] at 2009/01/04 21:38:58. / コメント(0)
 前回のエントリ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
ソースの解像度:1920x1080(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へ書き込んでいます。


▼ ケース1:出力解像度を640x360 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話分時間が空く、ということになります(^^;

▼ ケース2:出力解像度を1920x1080 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の測定ロジックによるところだと思いますし、アクセス方法はアプリケーション毎に違いますから、難しいところではないかと思います。

▼ ケース3:出力解像度を640x360 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)であれば、ほとんど同じ時間で 1920x1080 59.94p、音声 256kbps Stereo、クォンタイザQ2 の処理が完了しているあたり、技術の進歩は凄いなあ、と痛感しました。
---
2009/01/05 6:47追記:
 Core2Quad Q6600のエンコード時間ですが、映像クロップフィルタと音声ノーマライズフィルタが追加されており、全く同じ設定ではありませんでした…申し訳ありません。
---

▼ SSDをICH10RのRAID0でなく単体で使用した場合はどうか

 左からケース1、ケース2、ケース3、オマケの1920x1080 59.94p Q2 の順です。
   
 SD画質のQ4というかなり限定された構成(ケース1)では、23分19秒(98.9%)とやっと100%切りを達成。ICH10RはソフトウェアRAIDなので、この処理にかかるCPU負荷が、SSDのRAID0化で向上した速度よりもエンコードに影響を与えた、という結果になりました。
 それ以外もケース2が36分07秒、ケース3で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では、結果が変わってくる可能性がある。

 以上、多分全く参考にならないレビューをお届けしました^^;

PhotoFast G-Monster-V2

[PC&Digital] at 2009/01/04 01:06:16. / コメント(0)
 最初タイトルに「~を試す」と付けたら、某Watchみたいな見出しになったので却下。
 というわけでPhotoFastの赤SSDことG-Monster-V2を2台購入してみましたので、早速色々テストをしてみました。

 マザーはMSIのECLIPSE SLIで、RAIDも試したいという魂胆からDriveBooster(JMicron 322)のSATAコネクタに接続、ベンチマークを取ってみました。
 …あれ?Readで140MB/s?
 じゃあRAID0にしてみたらいいのか?と…
 まったく変わらない結果にがくり。
 これはオンボードRAIDコントローラではやっぱりしょんぼりな結果にしかならんのか、と思いつつ、上田新聞blog版を見てみると、ICH10Rで200MB/s越えの結果が。
 で、早速現在ICH10Rに接続されているHDDをJMicron 322側(※このコントローラ側からでもブートできる上に、仮にこのコントローラの転送速度が最大140MB/s程度だったとしても、HDDなので十分)につなぎ替え、逆にICH10RへSSDを接続してみると…
 
 ほぼ期待通りの値、READで209MB/s、WRITEで163MB/sとなりました。
 では気を取り直してRAID0(ライトバックキャッシュOFF)にしてみます。
 
 Sequential READは268MB/sになりましたが、Sequential WRITEは133MB/sと低下、逆にRandom READ/WRITE 512KBはそれぞれ237MB/s、85MB/sと上昇。またHDTuneのBurst Rateは低下、という妙な結果となってしまいました。
 これでも十分早いし…と思ってはいましたが、やはり納得できなかったためGoogle先生に聞いてみたところ、ストライプサイズを小さくすると良い(ICH10Rのデフォルトは128K)らしいとの情報が。

 早速ストライプサイズを4Kにして論理ボリュームを作成してテストをしてみます。
 
 IntelのSSDでRAID0を組んだケースには遠く及びませんが、容量は2台構成のRAID0で3倍程度で、価格差は現時点で約+2万ですから十分とも言えます。
 逆に言うと、単体で512GBになれば、容量以外ではほとんどRAIDにする意味が無いかもしれない、という点ではなかなか面白いかもしれません。(もっとも、まともなハードウェアRAIDカードを付ければ結果は違うのかもしれませんが、残念なことにそこまで投資できませんでした。そもそもICH10RであってもIntel SSD RAID0で470MB/sくらい出せるので、キャッシュ以上の速度向上はあまり見込めないのではないか、と思ったためです)

 HDDと比べると圧倒的な速度となりましたので、次回はこれがエンコード速度に影響を与えるのか、チェックしてみようかと思います。

---
2009/01/04 15:13追記
 Google先生に聞いてみたところ、inDEXさんがAreca ARC-1680ix-12というハードウェアRAIDカード(10万以上する高級RAIDカード)で試される予定であるというエントリーを見つけました。ちょっと期待。

Core i7-920

[PC&Digital] at 2008/12/22 00:31:38. / コメント(0)
 様々な誘惑に負けてしまいました…
画像は左から購入物品、Windowsエクスペリエンス、H.264エンコード中のCPU-ZとCoreTemp
 ということで主たる使用用途であるところのエンコード比較をば。
 幸いなことに前回FIRECODER bluのベンチマークで使用した素材がありますので、これを使用してみました。ただし諸般の事情により、全く同じOSではないのでご注意ください。
 なお使用したエンコードソフトウェアは前回同様、TMPGEnc 4.6.3.268です。

■元データ情報(前回と同じものです)
 1440x1080iのHDVテープをEDIUS 5でキャプチャした、Canopus HQ CodecのAVIファイル(※SS|EX Vol.4で撮影していた動画です)をエンコードしてみます。

映像コーデック:Canopus HQ Codec(オンライン-標準)
音声コーデック:非圧縮WAVE 44.1kHz
ファイルサイズ:3,093,904,724 バイト(2.88GB)
クリップの長さ:4分30秒

■Core2Quad Q6600(定格動作)でのエンコード
<エンコード環境>
M/B : ASUS P5B-E
Memory : DDR2-800 1GB×4(ただしMemory Remapにより2GBしか使用していません)
OS : Windows Vista Service Pack 1

H.264へのエンコード時間(前回のデータより):17分51秒
DivXへのエンコード時間(前回のデータより):28分20秒
※DivXへのエンコードは、TMPGEnc内蔵のエンコーダを使用しています。

■Corei7 920(定格動作)でのエンコード
<エンコード環境>
M/B : MSI ECLIPSE SLI
Memory : DDR3-1066 1GB×3
OS : Windows Vista Service Pack 2β

H.264へのエンコード時間:11分27秒(Q6600比:64%)
DivXへのエンコード時間:16分54秒(Q6600比:60%)
※DivXへのエンコードは、DivX 6.8.5製品版のエンコーダを使用しています。

 実写動画なので、DivXにするメリットはあまりなかったりもするのですが一応比較してみました。Q6600での比較で6割程度になっているあたり、かなり速度が向上していることが見受けられます。もっともこれくらいであれば、圧倒的にSpursEngineのほうが早い(SpursEngineでは最長で3分29秒)ということも、面白いデータなのではないかなと思います。
 ここで何故エンコーダがTMPGEnc内蔵なのとそうでないのが分かれているのか、ということをご説明しますと、何故かTMPGEnc内蔵DivXエンコーダで、同じソース画像を食わせると、エンコードの最後でアプリケーションエラーとなり、正確なデータが取れないからで、やむなくこのような方法になってしまいました…

■オマケ
 ところである意味本編になりかねない、ソースが24分程度のアニメ動画についても比較してみました。
 コーデックは同じくCanopus HQ Codecで、クリップの長さだけが異なります。また出力フォーマットは1920x1080ではなく、640x360のSD画質にしてみました。

Q6600でのDivXエンコード時間(Q4):41分41秒
i7-920でのDivXエンコード時間(Q4):32分35秒(78%)
※これはともに内蔵エンコーダを使用

 興味深いのは、このときCPU負荷率が(1スレッドを除いて)30%程度であったところで、ハードディスクがボトルネックになっている可能性があることです。この辺りはもう少しなんかやってみるかもしれません(笑)

■まとめ
 エンコード目的でDivXなどのソフトウェアエンコードを行う場合は、Core i7を使わない手はないような気がします。もっとも、手頃なマザーの登場とメモリの値段が下落しているとはいえ、7~8万円かかるあたりはまだまだかなあ、と思ったりもします。普段使いだったらAMD 780G+TDP45WのAthlon X2で十分ですし、コストパフォーマンスは最高ですからね。
 ところで気になっていた騒音と発熱についてなのですが、CPUファンであるASUS Triton81を100%フル稼働させると(轟音ではないにせよ)なかなかの騒音となります。ただ、回転速度を50%くらいに落とすと静かになりますし、そのときの温度は室温20度くらいで38度程度、H.264でのエンコード時は60度程度ですので、思ったほど熱くも五月蠅くもない感じでした。

 ただ、うちの環境だけなのかもしれませんが、NVIDIAのCUDA対応ドライバをインストールすると、何故か次から二度とOSが立ち上がらなくなる(起動直後にハングする)現象に悩まされています。もっとも「前回正常起動時の構成」で起動できるので問題はなく、また幸い使用しているのがGeForce 8800GT(G92コア)なので、古いバージョンのドライバを使用することで解決しているのですが、原因がさっぱり分からず… 今使用している8800GT固有の問題であると根拠なく判断して、GTX260の新コアをつっこんでしまおうか、なんてエンドレスな状態になっています(笑)

2008.12.28追記:
 結局9800GTX+にしてみましたが、やはり同様の事象が発生しています。色々検証してみた結果、どうもCore i7+GeForce(Release 177以上)+HDRECSの組み合わせがいけないようで… トムカノユーザーフォーラムでも書いた(同名のH/Nが使用されていたので、適当に思いついた名前になってます^^;)のですが、年明けにもユーザーサポートに投げてみようかと思います。
 ちなみに9800GTX+の場合、Guru3DでForceware 175.70をダウンロードしてインストールすることで回避できます。GTX260/280は177以上しか無いようなので、もしかしたら駄目かもしれません。

FIRECODER bluベンチマーク

[PC&Digital] at 2008/12/06 03:06:28. / コメント(0)
 ここ最近はベンチマークばっかりのような気がしますが、まあそんなもんなんでしょうね…
 というわけでThomon-Canopus(旧Canopus)製SpursEngine搭載H.264エンコーダ、FIRECODER blu(http://www.thomson-canopus.jp/catalog/firecoder_blu/firecoder_blu_index.php)のベンチマークを取ってみましたので、遅まきながらだらだらと。

■元データ情報
 1440x1080iのHDVテープをEDIUS 5でキャプチャした、Canopus HQ CodecのAVIファイル(※SS|EX Vol.4で撮影していた動画です)をエンコードしてみます。

映像コーデック:Canopus HQ Codec(オンライン-標準)
音声コーデック:非圧縮WAVE 44.1kHz
ファイルサイズ:3,093,904,724 バイト(2.88GB)
クリップの長さ:4分30秒

■テストケース

<ケース1:FIRECODER bluでH.264変換>
Blu-ray出力時の解像度変換:1920x1080
1920x1080時の画質設定:最高品質

<ケース2:TMPGEnc 4.6.3.268でH.264変換>
 素材はすでにEDIUS 5で編集済みということで、TMPGEnc側でのカット編集やフィルタ設定は、デフォルトで入ってしまうインターレース解除と映像リサイズを除き実施/追加していません。
 またコーデックの設定は、FIRECODER使用時とある程度条件を合わせるために以下のようにしています。

・映像設定
 プロファイル:Main
 レベル:自動(4.1以下)
 フレームレート:29.97fps(インターレース)
 レート調整モード:1パス 可変ビットレート
 それ以外はデフォルト
・音声設定
 エンコーダ種別:AACエンコーダ
 サンプリング周波数:48000 Hz
 ビットレート:384kbps(※CBRには出来ないのでVBRになります)
 それ以外はデフォルト

<ケース3:参考情報 TMPGEnc 4.6.3.268でDivXへ変換>
 TMPGEnc上で出来る設定はほとんどありませんが、最高品質設定でクォンタイザを4に設定しています。
 CPUはCore2Quad Q6600(2.4GHz)、CUDAはフィルタを使用していないので、自動でOFFとなりました。

■エンコード結果

<ケース1:FIRECODER bluでH.264変換>
・エンコード品質=画質優先
 エンコード時間:3分29秒
 ファイルサイズ:652,615,680 バイト(622MB)
 平均ビットレート:18Mbps
・エンコード品質=標準画質
 エンコード時間:3分21秒
 ファイルサイズ:442,312,704 バイト(421MB)
 平均ビットレート:12Mbps
・エンコード品質=容量優先
 エンコード時間:3分18秒
 ファイルサイズ:244,131,840 バイト(232MB)
 平均ビットレート:6Mbps
※音声はどの設定でも48kHz/384Kbps/CBRで固定

 実際に見比べてみますと、元々のソースはHDV(MPEG-2 1440x1080 1080i 29.97fps 25Mbps)となっているわけですが、そもそもの素材が比較的暗所で撮影されているためか、そこまで大きな映像の破綻はありませんでした。とはいっても、標準画質と容量優先では、ある程度差が分かるという印象です。
 処理時間が微妙に違うのは、単にHDDへの書き込みが多いためなのでしょう。

<ケース2:TMPGEnc 4.6.3.268でH.264変換>
エンコード時間:17分51秒
ファイルサイズ:345,272,196 バイト(329MB)

 当たり前ではありますが、ソフトウェアエンコードには非常に分が悪いテストとなりました。
 ところでTMPGEncでエンコードしたH.264動画は、なぜかMedia Player Classicでは綺麗に再生できないんですよね… 音声がVBRだと駄目、とかあるかもしれませんね。

※2008/12/06 18:06追記※
 そういえば画質について触れていませんでしたが、Nero 8のShowTimeで確認するかぎり、FIRECODERの標準画質とそれほど大きな差はないような印象です。あくまでソースが自分自身で撮影した動画をそのまま使用しただけなので、おそらく編集でテロップとか出したりすると、明確な差が現れるようになるのではないか、と思われます。

<ケース3:参考情報 TMPGEnc 4.6.3.268でDivXへ変換>
エンコード時間:28分20秒
ファイルサイズ:609,738,286 バイト(581MB)

 当然ではありますがもっとも遅く、また容量も比較的大きくなりました。元々DivXの場合、ビットレートがかなり激しく上下するので、実写動画だとかなり容量が大きくなる傾向があります。
 逆にアニメーションなど、DivXが得意とするジャンルでは、(エンコード速度は置いておいて)ファイルサイズはH.264の半分程度になったりします。

■まとめ
 結局は映像素材とコーデックを使い分けるべき、という当たり前の結果になってしまいました(笑) こりゃやっぱりCore i7導入するしかないのかな…なんて^^;
 でもなんだかんだいって、このエンコード速度はかなりやみつきになりそうです。

※2008/12/06 18:06追記※
 重要なことを書きそびれていますが、あくまで現時点では、「EDIUS 5で取り込んで編集してH.264へエンコードする」という、比較的狭い使用用途に限って、かなり役に立つボードなのではないかなと思います。それ以外は正直まだまだじゃないかなと。
 いかんせんまだ全然使い込まれていないボードですので、今後のソフトウェア展開次第では面白いことになるのではないでしょうか。
«Prev || 1 | 2 | 3 | 4 | 5 | 6 | 7 || Next»

ナビゲーションバー