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