残念。

Intel Media SDK 2012をQSVEncに組み込もうとちょこちょこやっていた…が、

残念な問題にぶつかった、そんな話。

わりと愚痴ばっかりになります。

続きを読む

続きを閉じる

ご存知かもだけど、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がどこまで対応しているかチェックして分岐させたりしようかな、とかも考えている。

x264guiEx 1.28

設定画面とか、ログ表示関連をちょいと調整。

続きを読む

続きを閉じる

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

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


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




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

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

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


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


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

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

---

ダウンロード>>

x264guiExの導入>

---

x264guiEx 1.27

・YC48出力時に色空間変換を行う機能を削除。

Aviutl 0.99k2からAviutl側の色変換がYC48出力時にも反映されるようになり、x264guiEx側でのYC48 BT.601->BT.709変換は不要になった。x264guiEx側にこの設定があると、紛らわしいということで削除。

なので、特に10bit出力をする場合、今後はAviutl 0.99k2以降でお願いします。まあ、普通最新版にしていると思うので問題ないですよね…?


・muxを行っていない場合に「エンコ後バッチ処理」に失敗するのを修正。

スレのほうで指摘していただいたこと。


・音声エンコで単純なWAV出力に対応した。

wav出力 -> x264_L-SMASH内蔵音声エンコをしてみるというのがあったので、バッチファイルの指定とかせずにwav出力できるようにしてみた。


・エンコ後バッチ処理のバッチファイル指定欄のドラッグドロップ対応。

・x264guiEx.iniのoggenc2コマンドラインを修正。強制的に44.1kHzになってしまっていた。

・その他細かいコードの調整。なんとなくいじっただけで特に意味はない。

---

ダウンロード>>

x264guiExの導入>

---

x264afs r2146+643

要望があったので。

lavfとかffmsはなしの簡易ビルド。
まあ、これ使う時ってavs入力だからいらないと思うのですが、どうでしょう。
これだとneroaacencで作った音声をインポートできないことに気がついたのでlavf+ffmsありのr2146+643も上げておきます。

---

ダウンロード>>

---

Aviutl 0.99k2 とYC48色空間

スレのほうに書こうとしたら規制に阻まれているうちに、書いてくださった方がいました。
どうもありがとうございます。

一応こちらにも書いておくと、

Aviutl 0.99k2からYC48出力時もBT.601->BT.709変換がかかるようになりました。なのでx264guiEx側でのYC48 BT.601->BT.709変換は要らないです。

よって、0.99k2使用でAviutlの色空間をきちんと設定していれば、guiExの拡張タブ「YC48出力」の設定は「無変換」でお願いします。

※いずれにせよ、影響があるのは10bit出力時とi444出力時のみで、8bit i420/i422時には影響はありません。

もう紛らわしいんで、なんかもったいないけど設定項目自体消すべきかな…

ちょっぴり速くなった、ような… QSVEnc 0.03

QSVEncを久しぶりに更新。
いろいろ更新。

設定画面が出ないのをv2で解消しました。

続きを読む

続きを閉じる

要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 が出てる。これも試してみてそのうち組み込もうかなと。これでインタレの問題解決するといいなあ…

x264guiEx 1.26

細かい修正。

・ログ自動保存先の設定を行う部分で、.NET のOpenFileDialog/SaveFileDialogで(マネージドコード側の)カレントディレクトリが勝手に変更されるXP環境 + .NETのバグを回避できていなかったのを修正。

・YC48色変換式の係数を検証しなおした。ほとんど変わらないが、より正しく。

・typoの修正。

---

ダウンロード>>

x264guiExの導入>

---

x264 r2146 と拡張命令

x264はCPUの拡張命令を使うことで、どんどん速くなっている。

--asmオプションを使うことで、x264が使用する拡張命令を選択することができるので、どのレベルの拡張命令が効くのかを試してみた。

続きを読む

続きを閉じる

環境
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あたりがないのも関係してるんだろうなあ…

x264guiEx 1.25

コマンド入力欄の改行に対応した。

---

ダウンロード>>

x264guiExの導入>

---

x264 r2145 はもっと速い …がバグっているらしい

注意
たくあん様にコメントで教えていただいたのですが、x264 r2145はバグっている、ようなので使用しないほうがよいでしょう。
→ r2146で修正されています。
どうも絵が崩れるらしいのですが、夏目友人帳とか普通にエンコードしてしまったがどうしよ。見た限り問題ないんだけど、気持ち悪いからエンコードかけ直すか…

このベンチマーク結果は参考としておいておきます。

たくあん様、教えてくださってありがとうございます。

x264 r2120、なんか速くね?の続き。

x264 r2145でも相当高速化されたようなので再びベンチマーク。

続きを読む

続きを閉じる

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

共通環境
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とかの辺りの高速化らしいので、そのへんの比重がより重い設定ならもっと高速化すると思う。(この測定は動き探索系が重いアホな設定にしているので、その辺の比重が高くなってしまっている。)