NEXT | PAGE-SELECT | PREV

x264 ベンチマーク (その3: -meオプション編) 1/2


このエントリーをはてなブックマークに追加


x264_fire_400.jpg

x264ベンチマーク 第三弾。
x264には-meオプションがありますが、そのオプションの指定方法によって、どのくらいCPUリソースを食うか調べてみました。

目的

x264のヘルプの--meオプションの項目は下のようになってます。
C:>x264.exe --longhelp
・・・・(略)・・・・・
--me <string>         Integer pixel motion estimation method ["hex"]
         - dia: diamond search, radius 1 (fast) 
         - hex: hexagonal search, radius 2 
         - umh: uneven multi-hexagon search 
         - esa: exhaustive search
         - tesa: hadamard exhaustive search (slow) 
・・・・(略)・・・・・

dia, hex, umh, esa,tesaの5種類が選べ、diaにはfast、tesaにはslowと書かれています。
slowとあるからには、CPUをバカ食いすると思われます。またCPUを使う分だけ圧縮率なども高くなると思われます(もちろんビットレートが同じなら高画質になると同義)





ソースは以前のx264マルチスレッドベンチマークと同じ動画です。動画1は、720p(1280x720)、60fps、合計7941framesで約2分12秒です。
システム環境も前回と同じです。
使ったx264は、http://x264.nl/からダウンロードしたr930に変更してます。 利用したコマンド引数は、前回と同じですが、今回の目的のために--meオプションとスレッド数は各々変更してます。

C:> x264_ken859.exe --bitrate 710 --bframes 16 --ref 5 --no-deblock --partitions p8x8,b8x8,p4x4,i4x4 --8x8dct --keyint300 --min-keyint 1 --mixed-refs --no-fast-pskip --trellis 1 --progress --me XXX --merange 64 --qpstep 10 --subme 7 --b-pyramid --b-rdo --direct auto --bime --thread-input --no-dct-decimate --no-ssim --no-psnr --no-fast-pskip --stats x264.log --threads N --pass 2 --output nmpb01.mp4 nmpb01.avs



60fpsの結果

60fpsの結果ですが方法も前回と同じです。画像の解像度はAvisynth側で1280x720 -> 512x288に設定してます。


20080813-x264-me-1-1.png
20080813-x264-me-1-2

●60fps シングルスレッド(1p)時の比較
ヘルプに書いてあるとおり、dia < hex < umh < esa < tesaの順でCPUリソースを消費します。
中でも明らかに、esa, tesaのCPU時間が長いです。シングルスレッドでは、tesaはdiaの10倍以上時間がかかっていることが分かります。

●60fps マルチスレッド時の比較
前回の結果と同様に、どのオプションを指定しても6スレッドを超えると性能がサチュッてきます。
diaの場合:3スレッド以降性能向上がありません。
hexの場合:3スレッド以降性能向上がありません。
umh,esa,tesa:6スレッドまでは性能向上があります。
dia,hex,umhは、スレッド数を多くしたときのサチュッた性能はほぼ同じになります
スレッドがautoの時に、diaとesaの比較では約4.2倍、diaとtesaの比較では約6.0倍の性能差があります。



30fpsの結果

60fpsの結果ですが方法についても前回と同じです。画像の解像度はAvisynth側で1280x720 -> 512x288設定してます。




20080813-x264-me-1-3
20080813-x264-me-1-4

●30fps シングルスレッド(1p)時の比較
ヘルプに書いてあるとおり、dia < hex < umh < esa < tesaの順でCPUリソースを消費します。
中でも明らかに、esa, tesaのCPU時間が長いです。シングルスレッドでは、tesaはdiaの10倍以上時間がかかっていることが分かります。

●30fps マルチスレッド時の比較
前回の結果と同様に、どのオプションを指定しても6スレッドを超えると性能がサチュッてきます。
diaの場合:2スレッド以降性能向上がありません。
hexの場合:2スレッド以降性能向上がありません。
umhの場合:4スレッド以降性能向上がありません。
esa,tesa:6スレッドまでは性能向上があります。
dia,hex,umhは、スレッド数を多くしたときのサチュッた性能はほぼ同じになります
スレッドがautoの時に、diaとesaの比較では3.0倍、diaとtesaの比較では約4.4倍の性能差があります。

(考察関連は次回に続く・・・)



(いきなり余談:一昨日、NVIDIAがCUDA用のデモソフトウエアを公開しましたね。そのなかに、H.264エンコード(badaboom Media Converter: Beta)も含まれています。
よっしゃ! と思い家でCUDA使ったH.264ベンチマーク取ろうと思ったのですが、考えるまでもなく私の家のPC環境にはCUDA2.0対応のグラボがないのです。当然測定できませんでした。あれば絶対やりたかったのですが・・・・。)




カテゴリ【知ったか検証―携帯(911SH), iPod 動画変換の検証】
『関連記事』



Amazon:アスク ビデオカードZOTAC 9600GT 512MB DDR3 PCIE ZT-96TES3P-FSP
20080816-GeForce9800.jpg


このエントリーをはてなブックマークに追加





このカテゴリの最新記事一覧


| ―携帯, iPod, PSP 動画変換 | 01時28分 | comments:0 | trackbacks:0 | TOP↑















非公開コメント

http://kenknown.blog42.fc2.com/tb.php/98-872302dd

≪ NEXT | PAGE-SELECT | PREV ≫