rigayaの日記兼メモ帳

ご存知かもだけど、Intel Media SDKというのはソフトウェアエンコ時はlibmfxsw**.dll(**は32または64)、ハードウェアエンコ時(QSV使用時)はlibmfxhw**.dllを使って(というかそれがGPU EUとQSVを使用して)エンコードしている。そして、libmfxhw**.dllというのはIntelのグラフィックスドライバに同梱されている。

そんで、ふと、思った。

SDK 2012用のlibmfxsw**.dllはある。Media SDK 2012に一緒に入ってるから。

で、libmfxhw**.dllは？

この子がないとハードウェアエンコできないんだけど。ソフトエンコならx264でしょ…

今日(2012.01.29)確認したIntelのドライバの最新版は相変わらず2509で、とてもSDK 2012対応とは思えない。

で、これを見つけてしまった。

HW acceleration for API 1.3 is only available on next generation Intel platform that is scheduled to be released early next year. The 1.3 API and Media SDK 2012 (formerly 3.0) is aligned with this platform launch. So in essence, when platform launches, there will also be a corresponding graphics driver available that exposes HW acceleration via 1.3 API.　(Intel Software Network - Intel Media SDK の Threadより)

ようするに、4月に出ると言われてるIvyBridgeが出たら、SDK 2012用のlibmfxhw**.dllを(ドライバと)一緒に出すよ、ということ。(※4月にIvyというのもどっかで聞きかじった情報です。あんま当てにしないでね。)

なんと…4月まで待てということか…

え～と、SandyBridgeでも大丈夫なんかな…もしかしてIvyじゃなきゃダメとか、そんなこと…ないよね…? いや、Ivyじゃなきゃダメって読めるんだけど…。


ちなみにIntelの資料を読む限りMedia SDK 2012での更新は、

・高速化・高画質化。(ほう…)
・AVBRモードの追加。より柔軟な1pass VBRみたいな感じ?
・リサイズとインタレ解除の高品質化・低速化
・細かいフラグの調整ができるらしい(よくわからん)


ついでに、IvyBridgeについて。全部どっかで見たというだけの情報で、当てにしないで欲しいけど、

・22nmに移行でTDPがMax 77Wに。どうでもいいけど、高クロック95Wとか6コア95Wとか作ろうよ。エンコには速さが重要なんだよ?

・CPUはちょっと強くなるぐらい。AVX2は入らない。

・GPUが強くなる。ほう。QSVは???

ということらしい。…K付買ってオーバークロックしろということですね、わかります。


ともかくQSVEncはのんびり作っていって4月にはMedia SDK 2012に対応できてる…という感じで行こうと思う。dllがどこまで対応しているかチェックして分岐させたりしようかな、とかも考えている。

・設定メモの色をWinXPでも見やすいよう調整。

どういうことかって言うと、
Win7だと特に問題なかったんだけど、(上 1.27、下 1.28)


XPだとメモが見えなかったので(上 1.27)、色を調整した。(下 1.28)




・ログウィンドウの大きさを保存できるようにした。

ログウィンドウ右クリックから保存を有効化できる。「このウィンドウのサイズを保存」

デフォルトの大きさだと、現在なにをエンコ中なのか見えないことがあって、


こんな感じで、大きくしたい。


で、このウィンドウの大きさを保存して、次以降も反映させようというもの。

「このウィンドウのサイズを保存」のチェックを外すと次回以降デフォルトに戻る。

---

ダウンロード>>

x264guiExの導入>

---

要iniファイル更新(iniファイルバージョン1→2)
すんません。


別スレッドでフレーム読み込み & 読み込みバッファの追加

以前読み込みを別スレッドで処理(部分並列化)しようとしたときは、作りが雑だったので余分にメモリコピーが発生して逆に遅くなってしまった。なのでその時は部分並列化はあきらめたのだが(メモリコピーも遅いということを実感した)、今回は要らないメモリコピーが発生しないような別スレッド処理を考えた。これでちょっぴり高速化すると思う。(少なくとも遅くはならないはず)

フレーム読み込みバッファ機能は、この別スレッド処理の効率をあげるためのもの。設定できるバッファサイズは1～16フレーム。QSVEncでは読み込みバッファサイズ(タブ3枚目)で、QSVEncCでは--input-bufで大きさを指定できる。

あまり多すぎると逆に遅くなるので注意。(キャッシュサイズとの関連だと思う)

うちの環境(Core i5 2500)だとこんな感じ。
エンコ速度 適切なバッファサイズ
～50fps 　　　 1～2
～100fps　　　 2～3
～200fps　　　 3～6
それ以上　　　 4～8

QSV使用時にバッファサイズをあんまり大きくするとGPUメモリを確保できなくなってこけるので注意。

別スレッドで読み込みと読み込みバッファはエンコ速度が速ければ速いほど効果があるはず。逆にfullHDのエンコードなどではあまり効果はない。


x264guiEx v1.11～v1.26の追加機能の取り込みとバグ修正の反映

x264guiExで更新したところを地道にコピペ改変で反映した。

・相対パスを使用できるようにした。
・ツールチップヘルプの抑制(その他の設定から)
・「このウィンドウを最小化で開始」が一回しか効力を発揮せず、解除されてしまう問題を修正。
・視覚効果をオフにできるようにした。
・プロファイルにメモを残せるようにした。プロファイルの右側に表示。ダブルクリックで変更できる。
・QSVEnc.iniが存在しない、あるいは古い時にエラーメッセージの前に例外が発生する問題を解決。
・Apple系に対応したmp4/chapterをmp4boxを用いても出力できるようにした。
・その他の設定にログウィンドウ関連の設定(「透過」と「最小化で開始」)を追加。
・設定ファイルのサイズが異なっても、Aviutl側のプロファイルに保存された設定も読めるようにした。
・チャプターファイルの自動削除をオンオフできるようにした。その他の設定から。
・チャプターファイルが存在しない場合でもとりあえずmuxを成功させるようにした。
・エンコ中でないとき、Escキーでログウィンドウを閉じるようにした。
・エンコ後バッチファイル実行を追加。
・設定画面でEscキーのオンオフ設定を追加。
・muxエラー対策。mux時チェックを根本的に改善。


QSVEncCにx64版を追加。
わずかに速い…かもしれない。基本たいして変わらない。まあx64ビルドもできるよ、ということ。

不要なメモリ解放->再確保を防止。

---

iniファイルの不備により設定画面が出ないのをv2で解消しました。すみません。
QSVEnc ダウンロード>>

---

その他

エンコード結果の画面が真っ黒になるとかの場合、QSVとmp4boxの相性の悪さが原因なことが多いです。pop氏のビルドしてくださっているmp4boxを使用してみてください。

QSVでインタレ保持エンコができないのは相変わらずです。ほんとは出力時にmp4に突っ込むと解決するらしいのだが(商用ソフトはそうしてますよね)、そんな技術力はない。

Intel Media SDK 2012 が出てる。これも試してみてそのうち組み込もうかなと。これでインタレの問題解決するといいなあ…

環境
Win7 x64
Aviutl 0.99k
x264guiEx 1.26
Core i5 2500 (4C/4T, L3=6MB, ～AVX) 3800MHz
RAM 4GB, DDR3-1333, Dual Channnel

素材
H.264 High Profile
1920x1080p 23.976fps
2154frames (1m 30s)
ましろ色シンフォニー OPを1920x1080に拡大してエンコードしたもの
lsmashinputで読み込み

x264
x264.nlの64bit版
r2120/r2146の8bit

x264 オプション
ちょい重め。
--crf 20 --ipratio 1.5 --qpstep 12 --qcomp 0.75 --no-mbtree --rc-lookahead 60 --vbv-bufsize -1 --vbv-maxrate -1 --aq-strength 0.4 --psy-rd 1:0.2 --keyint 240 --min-keyint 4 --b-adapt 2 --me umh --subme 10 --merange 32 --direct auto --ref 4 --no-fast-pskip --no-dct-decimate --trellis 2 --colormatrix auto --colorprim auto --transfer auto

Aviutlのフィルタはなし
4回同じエンコードを行い、その最速値を結果として採用

比較
--no-asm アセンブラコードを使用しない
--asm MMX2/SSE2Fast/SSE3/SSSE3/SSE4.1/SSE4.2/AVX

x264のログ表示
--no-asm
using cpu capabilities: none!

--asm MMX2
using cpu capabilities: MMX2

--asm SSE2Fast
using cpu capabilities: MMX2 SSE2Fast

--asm SSE3
using cpu capabilities: MMX2 SSE2

--asm SSSE3
using cpu capabilities: MMX2 SSE2Fast SSSE3

--asm SSE4.1
using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1

--asm SSE4.2
using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2

--asm AVX
using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX

SSE3命令は使われていないのかな。まあ整数演算に効きそうな命令ないよね。

結果


こうしてみるとやっぱr2120→r2146でだいぶ速くなったねえ…

さて、予想通りSSE2はないと厳しいわけだけど、その後SSSE3、SSE4.1、意外とAVXとかも少しづつ速度を押し上げてる。

PhenomIIx6とかであんま速度が出ないらしいけど、やっぱSSSE3あたりがないのも関係してるんだろうなあ…

環境とかは前回と同じにそろえた。

共通環境
Win7 x64
Aviutl 0.99j2
x264guiEx 1.21
(今最新のものではないけど、環境を合わせるため)

環境1 (Xeon)
Xeon W3680 (6C/12T, L3=12MB, ～SSE4.2) 3875MHz
RAM 18GB, DDR3-1333, Tripple Channel

環境2 (Sandy)
Core i5 2500 (4C/4T, L3=6MB, ～AVX) 3800MHz
RAM 4GB, DDR3-1333, Dual Channnel

素材
H.264 High Profile
1920x1080p 23.976fps
2154frames (1m 30s)
ましろ色シンフォニー OPを1920x1080に拡大してエンコードしたもの
lsmashinput(POPさんビルド,r29)で読み込み(今最新のものではないけど、環境を合わせるため)

x264
x264.nlの64bit版
r1804/r1900/r1995/r2019/r2057/r2085/r2106/r2120/r2145の各8bit/10bit版
※r1804/r1900/r2019は8bit only

x264 オプション
ちょい重め。
--crf 20 --ipratio 1.5 --qpstep 12 --qcomp 0.75 --no-mbtree --rc-lookahead 60 --vbv-bufsize -1 --vbv-maxrate -1 --aq-strength 0.4 --psy-rd 1:0.2 --keyint 240 --min-keyint 4 --b-adapt 2 --me umh --subme 10 --merange 32 --direct auto --ref 4 --no-fast-pskip --no-dct-decimate --trellis 2 --colormatrix auto --colorprim auto --transfer auto
※10bit時は--input-depth 10を追加

Aviutlのフィルタはなし
5回同じエンコードを行い、その最速値を結果として採用


結果


対r2120比


さらに速くなってる…。
特にSandy環境でやたら伸びてる。

今回はCABACとかtrellisとかの辺りの高速化らしいので、そのへんの比重がより重い設定ならもっと高速化すると思う。(この測定は動き探索系が重いアホな設定にしているので、その辺の比重が高くなってしまっている。)