NEXT | PAGE-SELECT | PREV

スポンサーサイト


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


上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


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





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


| スポンサー広告 | --時--分 | comments(-) | trackbacks(-) | TOP↑

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


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


x264_fire_400.jpg

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

前回のx264 ベンチマーク (その3: -meオプション編) 1/2の続きです。

前回の結果の表とグラフを下に、考察というか少し思ったことと、今後の展開について述べさせて頂きます。






適当な考察

まず、esa、tesaがとても遅いということ。この動画ソースでは、オプションの違いで画質の差があまりでないようです。そのため、このオプションに意味があるかどうか疑問に思いますが、かなり変わるとの情報もあるようなので、動画ソースに依存するようです。
それにしても、オプションによってシングルスレッドでは10倍近い差がでるとは思いませんでした(tesaがやけに時間がかかるとは思ってましたが)。-meオプションを利用するときは、動画の質とエンコード時間の費用対効果を考えて指定しないといけなさそうです。

次にdia、hex、umhですが、マルチスレッド指定時での実行時間はどれも130-140秒が最速となってます。さすがにここまで揃うと、ボトルネックが130-140秒あたりに何かありそうです。
diaは、2スレッドでサチュってるのでもっとスレッド性能でてもいいような気がしますから。

考えられる理由としては、最初のAvisynthの解像度変更が一番あやしいです。次に入力ファイルの読み込み速度でしょうか。
これを確認するためには、前者は最初にエンコード後と同じ512x288の状態にしたソースを作り、Avisynthの負荷を減らす。後者の入力ファイルのread性能については、RAID0組むか、RAMディスクを利用するなどして確認できるかもしれません。

ただし、130-140秒あたりというのは、私が利用する上での実用的な限界速度でしょう。毎回毎回エンコードを速くするためだけに、RAMディスクに入力ファイルをコピーしたり、わざわざ中間ファイルとして512x288のファイルを作るとは思えませんから。
また非圧縮ファイルを利用するというのもありますが、その場合ディスクのread性能が今以上に必要になってくるので、x264の性能評価するという目的のために意味があるかは疑問です。

というわけで、今度はAvisynthの処理をできるだけなくした状態を作って検証ていければと思います。

  1. 720p(ソース) -> 720p(h.264) (こうすれば解像度変更の影響は逃れられる。)
  2. 720p(ソース)動画を一旦512x288に変更。それをx264でエンコード
  3. 720p(ソース)をRAMディスクに置いて実行

この3つが次に行った方が良いかなと思う検証。他にもあるかもしれませんが、思いついたらやりたいですね。

その他、今回の結果から色々言えることもあるかと思いますが、とりあえず今回の検証についての考察は終了です。




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

【関連項目】

改訂版 H.264/AVC 教科書 (インプレス標準教科書シリーズ)
角野 眞也 菊池 義浩 鈴木 輝彦
4844322044



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





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


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















非公開コメント

http://kenknown.blog42.fc2.com/tb.php/99-8be2130b

≪ NEXT | PAGE-SELECT | PREV ≫

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。