録画人間の末路 -

人は記録をしながらじゃないと生きていけない

新SpursEngine H.264エンコーダ 実験プログラム、テスト

2010-05-14 23:42:09 | FIRECODER Blu/SpursEngine
SCEIがアメリカの軍や大学などの研究施設に打撃を与えかねない状況らしいですね。

「PS3でLinux」無効化で、PS3スーパーコンピュータ計画はどうなる?

まぁ先日のこの改定によってSCEIにとっての顧客はPS3を買う人間や機関ではなく、ソフトを開発するソフトメーカーだけであることをはっきりとさせているわけですし。まして最近になってようやく利ざやが出るようになったほど歩留まりの悪かったPS3の本体を大量購入する機関なんて、どうでもいい存在なわけですから無視するとは思うんですが・・・。ひょっとしたら、日本企業らしくアメリカに対してはLinuxインストール機能を復活させるとか、軍や大学には特別ファームウェアを提供するとかするかも知れませんね。


先日からLalfさんによる"SpursEngine H.264エンコーダ 実験プログラム"がバージョンアップされ、公開されています。これはAviUtlを使ってSpursEngineでの出力を行うものですが、他のSpursengine対応ソフトと違い、キーフレーム出力を丁寧に行っているという特徴があります。先日より量子マトリクスの調整に対応したバージョン0.05が作られましたが、その代わりに出力が以前よりも遅くなってしまう欠点がありました。それを補うため、CPUのマルチコアに対応することで速度を上げるように改良された0.06がいます。具体的にどの程度速度があがるかどうか、試してみましょう。なお、AviUtlは0.99i6を使用、フィルタ・リサイズ・インターレース解除等は一切行わない設定としました。動画の長さは1分30秒、ウチでよく使うアレ。

CPU:PhenomIIx3 720BE(今回は定格速度)
メモリ:8GB(有効3.5GB)DDR3-1333
マザー:AMD890GX
GPU:GeForce9800GT
OS:Vista32bit
Spurs:PxVC1100
と、いつもの環境。

0.05-4分21秒
0.06-3分08秒

0.05と比べると、ウチの3コアでも7割程度の速度で終わってしまいます。こうなると、なにかx6が欲しくなってしまいます。なお、おまけとして他の環境でも速度を比較

TMPGEncXPress+Spurs
49秒
同じAviUtl+x264(動き予測アルゴリズム 1)
7分14秒
同じAviUtl+x264(動き予測アルゴリズム 5)
9分11秒

うーん、さすがに何もしてないTMPGでのSpurs出力は速いですね。それでも、x264出力よりはグンと速いですが。本当はキーフレーム出力の処理とかは、SpursEngineに搭載されているSPEとかで処理して欲しいものですが、そういう風にドライバやSDKが作られている様子がないですね。ボチボチ改良版のドライバとかを用意して欲しいものです。

さて、次は画質チェック。こっちが本命でしょう。なお、AviUtlの出力は、テンプレで用意されているフラットにビットレートを2000Kbpsで出力したもの。ただし、サイズはほぼ3500Kbps相当になるため、TMPGEncでは3500Kbpsになるように調整しました。ほぼファイルサイズは一緒です。

gooのファイルサイズの都合でリサイズされていますが、最初リサイズなしでH.264/AVCで出力したものをあとで画像加工ソフトで出力したものです。

TMPGEnc+SPursEngine


AviUtl;SpursEngine


どうですか! この差・・・。大して変わらん? 実際にはもっと差があるのですけど、過去の例と箇所を合わせたら比較的差のないところになてしまったのですよ。

なので、次はもっと差の出るところを。SpursEngineの弱点である、急激なシーンチェンジによる画面崩れの象徴的部分で。

TMPGEnc


AviUtl


これははっきり分かるでしょ! 同じSpursEngineで出力しているとは思えない差があります。ただ、フラット化は実写ではむしろ画質の艶をなくす原因にもなるのでそっちでは使っていないのですが、それでもアニメほどではないにしろ、シーンチェンジの恩恵は小さくなく、ブロックノイズが出にくくなります。
完成度、かなり高まってきています。そろそろ"実験"の文字を外してもいいんじゃないかな~と思うのですが、どんなもんでしょ。SCEIの方針によってつぶされたCodecSys Personalの穴埋めとしては、わたしには最適です。

コメント (6)    この記事についてブログを書く
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする
« 正当な評価を受けられない東... | トップ | あやしい? DM626 HDMI Vide... »

6 コメント

コメント日が  古い順  |   新しい順
Unknown (Lalf)
2010-05-15 19:20:42
今のところ、一番時間がかかってるのは、エンコード本体ではなく、
AVIUtlから画像を取り出すところです。これが大半を占めます。
私がマルチスレッド化して高速化したのは、
・AVIUtlから画像を取り出して、SprusEngineに渡すところ
・SpursEngineからデータを受け取ってファイルに記録するところ
の2つに分けただけです。なので、CPUコアが増えてもあまり高速化しないかも。

私にとっては今でも実験プログラムなのです。
これらは次のプログラムを開発するための足がかりなので。
返信する
Unknown (くん)
2010-05-15 20:24:25
Spursの癖というか、仕方ないところではありますが、
中途半端なビットレートだとうまくレートコントロールできないので、
比較的大き目の量子化行列(例えばDCはJVTx2、ACはJVTx4)で圧縮の下限を作り、
かつ十分に高レートでエンコードさせる方針でテストしています。
今のところ圧縮率も高く画質も安定していて満足しています。

ただまれに画面が乱れる箇所が出てしまいます・・・。
返信する
Unknown (くん)
2010-05-15 23:21:33
VBR40Mbpsで、flat32とかflat48ぐらいにしてしまうのが、
バランスよいかなーと言う結論になりそうです。
ただ頭の数フレームはやはりSpursの仕様なのか必ずQPを上げるようで・・・。
頭に必ず黒を入れて編集するか、頭だけ量子化行列を小さな値にしないとうまくいかないのかもしれませんね。
返信する
Unknown (krmmk3)
2010-05-15 23:45:07
>Lalfさん
こっちでまとめて。
簡単に作られたと言っても、技術のないわたしから見ればすごいことです。実際、SDKが配布されてはいても、需要に応える開発をされているのはLalfさんお一人ですし。
変更の内容を見ると、コアをx6に増やしてもこれ以上速度のアップは難しそうですね。AviUtlは便利ですけど、出力速度には難があるのでしょうか。それでも、わたしの目から見ると十分実用レベルですね。どうもありがとうございます。
返信する
Unknown (emanon)
2010-05-16 00:00:06
 早くなるものですね自分で組めるのは楽しいのだろうな 覚える気力が欲しいw

…、でも 何だろこの満たされない感じなんか最近物欲湧かないのは困った
返信する
Unknown (くん)
2010-05-16 17:51:21
軽くまとめてみました。
GOP構造に違いとかありますが大きな差ではないです。

http://geocities.yahoo.co.jp/gl/flash3kyuu/view/20100516
返信する

コメントを投稿

FIRECODER Blu/SpursEngine」カテゴリの最新記事