x265 2.7+336 AVX512対応の効果

x265がついにAVX512に対応し、速度の出るビルドもできるようになったので、AVX512の効果がどのくらいか、確認してみた。

x265公式には、4K HDRで15%みたいな話があったりするけど、1080pだとだいたい～10%ぐらい?

続きを読む

続きを閉じる

---

AVX512の使用法

---

AVX512を使用するには、--asm avx512をつける必要があるので、x265guiExではコマンド入力欄に"--asm avx512"をいれておくと、AVX512が使われる。

x265 [info]: HEVC encoder version 2.7+336-07defe235cde
x265 [info]: build info [Windows][GCC 7.3.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 AVX512
x265 [info]: Main 10 profile, Level-4 (Main tier)

--asm avx512をつけないと、AVX512が使えるCPUであっても、AVX512は使用されない。

x265 [info]: HEVC encoder version 2.7+336-07defe235cde
x265 [info]: build info [Windows][GCC 7.3.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-4 (Main tier)

---

AVX512最適化の効果

---

実験環境
i9 7980XE (18C/36T, 4GHz、AVX offsetなし)
電源設定: 高パフォーマンス

Aviutl 1.00
x265guiEx 3.67v2
x265 3.6+336 (fprofiled あり版 と なし版)

x265オプション
--crf 21 --preset <各種プリセット> [--output-depth 10] [--asm avx512]

※ --asm avx512をつけるとAVX512が使われ、つけなければ使われない。

ソース
sample_movie_1080p.mpg (1920x1080, 29.97fps, 5203frame, 2分53秒)

結果


だいたい5～10%といったところで、高速化しているものの、AVX2の20～30%のように非常に大きな効果というわけでもないみたい。

まあ、Intelから出ている資料では、1080pだと10%弱にとどまっているので、それにマッチする結果だと思う。この資料では、カーネル単位で高速化率を見たグラフがあるけど、カーネル単位で見ても平均30%前後、ほとんど速くなっていないものもあるので、まあ過度な期待は禁物、ということかもしれない。

また、今回はCPUを4.0GHz固定として、AVX2/AVX512 Offsetも切っているけど、AVX512 Offsetが大きめだったりすると、もしかすると効果がより弱くなってしまうかもしれない(まあ、冷却が十分ならAVX512 Offsetを有効にしなければよいだけだが)。

x265 ビルド msys2 gcc版 (AVX512対応)

これまでは、x265はVisual Studioでビルドしていたのだけど、AVX512対応版をビルドしようとするとなぜかうまくいかないため、gccでビルドすることにした。

2018/4/14 19:43にx265 2.7+336をここで紹介するgccでプロファイルによる最適化を実施した実行ファイルに差し替えました。

続きを読む

続きを閉じる

---

準備

---

msys2を使うと、非常に簡単にgccによるビルド環境が作れるので、それで。

そのほか、mercurial(hg)とcmakeをインストールしておく。

msys2
cmake
mercurial

---

msys2を最新へ。

まず、msys2のインストールフォルダにあるmsys2.exeを起動して、コアとパッケージシステムを更新。

pacman -Syu

一度、msys2.exeを再起動した後、残りを更新する。

pacman -Su

gccビルド環境と、そのほかx265のビルドに必要なものをインストール。

pacman -S base-devel
pacman -S mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain
pacman -S nasm

一度msys2を終了する。

msys2のインストールフォルダには、
・msys2.exe
・mingw32.exe
・mingw64.exe
があるのだけど、32bit向けのコンパイルをしたい場合にはmingw32.exe、64bit向けのコンパイルをしたい場合にはmingw64.exeを起動すれば、自動的にそれ向けに環境が整備されて、あとは普通に gcc とかをたたけばよい。

このあたり、msys2はわかりやすくて非常に良い感じ。

あとは、プロファイル用の入力ファイルをy4m形式で作成しておく。

ffmpegでy4mを作る場合、
ffmpeg.exe -y -i <ソース動画> -an -pix_fmt yuv420p -f yuv4mpegpipe -frame 30 <出力.y4m>
とかで作れば良いと思う。

---

ビルド

---

msys2環境向けに、x265実行ファイルを作成するためのスクリプトを作ったので参考にしていただければ。
build_x265.sh

スクリプトの上のほうにある、

#cmake.exeのある場所
CMAKE_DIR="/C/Program Files/CMake/bin"
#hg.exeのある場所
HG_DIR="/C/Program Files/Mercurial"
#プロファイル用のソース
Y4M_PATH=$HOME/sakura_op_cut.y4m

を自分の環境にあったものに変更してから、実行すれば、

$HOME/build_x265/{x86, x64}/x265/build/msys/8bit

以下に x265.exe が作成される。(multilibバイナリでも8bitのフォルダの下に作成される)

このスクリプトは32bit/64bit両対応で、mingw32.exeのシェルで実行すればx86(32bit)版が、mingw64.exeのシェルで実行すればx64(64bit)版がビルドできる。

x86版(32bit向け)は普通の8bitのみの実行ファイルだが、x64版(64bit向け)はgccのプロファイル付き最適化を使用したmultilib(8bit+10bit+12bit)の実行ファイルができる。

flto(プログラム全体の最適化)もやってみたのだけど、うまくいかない(リンクでこける…)のであきらめ。

---

fprofiled(プロファイルによる最適化)の効果

---

実験環境
i9 7980XE (18C/36T, 4GHz、AVX offsetなし)
電源設定: 高パフォーマンス

Aviutl 1.00
x265guiEx 3.67v2
x265 3.6+336 (fprofiled あり版 と なし版)

x265オプション
--crf 21 --preset <各種プリセット> [--output-depth 10] --asm avx512

ソース
sample_movie_1080p.mpg (1920x1080, 29.97fps, 5203frame, 2分53秒)



fprofiledの最適化は、gccでもきちんと効果があるみたいで、3～5%ほど改善している。

---

x265 2.7+336 (AVX512対応版)

ついにx265がAVX512に対応したということで早速使ってみた。

なんかVC++ 2017でコンパイルした実行ファイルでAVX512を使おうとすると落ちる…。

とりあえず、よくわからんので、gccでビルドしたものをあげました。(x64のみ) AVX512がちゃんと動きます。

コマンド入力欄に --asm avx512 とすると、AVX512が有効になります。

gccビルドは、いまのところ暫定処置なので「pgo版」となっているものも通常版と変わりありません。
2018/4/14 19:43にx265 2.7+336をここで紹介するgccでプロファイルによる最適化を実施した実行ファイルに差し替えました。

x265ビルド VC2017版

なんか要望があったのでVC2017でのビルド方法。とはいっても、ほとんど何も変わらないのだが…。

以下のスクリプトで8bit/10bit multilibのx265をPGOビルドできる。

続きを読む

続きを閉じる

---

準備

---

Visual Studio Community 2017
CMake (Win32 Installer をダウンロード)
Mercurial (MSI installer かInno Setup installerのどちらかを)
nasm
適当なy4mファイル (ffmpegとかで自分で作るか、このあたりから適当に bus_cif.y4mとかで)

ffmpegでy4mを作る場合、
ffmpeg.exe -y -i <ソース動画> -an -pix_fmt yuv420p -f yuv4mpegpipe -frame 120 <出力.y4m>
とかで作れば良いと思う。

とりあえず、上記をすべてインストールする。cmake/hg/nasmにはパスを通しておき、コマンドプロンプトで

cmake
hg
nasm

が反応あるかどうかを確認する。

---

ビルド実行

---

md <x265をビルドするフォルダ>
cd /d <x265をビルドするフォルダ>
 
set TEST_MOVIE=<y4mファイルへのパス>
 
rem x265のソースをダウンロード
hg clone https://bitbucket.org/multicoreware/x265
 
rem PGOを有効
set LTCG_OPTION=PGInstrument
rem 無効にする場合はこちら
rem set LTCG_OPTION=true
  
rem ここではx64ビルド
md x265\build\vc15-x86_64
cd x265\build\vc15-x86_64
set CMAKE_VS_TYPE=Visual Studio 15 2017 Win64
set ARCH_VC=x64
  
rem x86ビルド用
rem md x265\build\vc15-x86
rem cd x265\build\vc15-x86
rem set CMAKE_VS_TYPE=Visual Studio 15 2017
rem set ARCH_VC=Win32
  
rem コンパイルオプション
rem PGOビルドには、/GLが必要
rem その他のオプションは適当 (必要ないかもしれない)
set VC_OPTIONS=/GL /MP /MT /Ox /Ob2 /Oi /Ot /Oy /GT /GF /Gy /fp:fast /D NDEBUG
  
rem PGOは/LTCG (リンク時コード生成) の一種なので
rem /INCREMENTAL:NOとしないとリンク中に警告が表示される
rem /LARGEADDRESSAWAREはx86ビルド用 (x64では単に無視される)
set VC_LINKER_EXE_OPTIONS=/INCREMENTAL:NO /LARGEADDRESSAWARE /OPT:REF /OPT:ICF
set VC_LINKER_MODULE_OPTIONS=/INCREMENTAL:NO
set VC_LINKER_SHARED_OPTIONS=/INCREMENTAL:NO
      
rem VC2017の環境設定を呼ぶ
call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat"
call "%VS150COMNTOOLS%\..\..\VC\Auxiliary\Build\vcvarsall.bat" %ARCH_VC%
 
mkdir 10bit
mkdir 8bit
 
rem 10bit用のライブラリをビルド
cd "10bit"
cmake -D STATIC_LINK_CRT:BOOL=ON ^
 -D ENABLE_SHARED:BOOL=OFF ^
 -D CMAKE_CXX_FLAGS_RELEASE:STRING="%VC_OPTIONS%" ^
 -D CMAKE_C_FLAGS_RELEASE:STRING="%VC_OPTIONS%" ^
 -D CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING="%VC_LINKER_EXE_OPTIONS%" ^
 -D CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING="%VC_LINKER_MODULE_OPTIONS%" ^
 -D HIGH_BIT_DEPTH:BOOL=ON ^
 -D EXPORT_C_API:BOOL=OFF ^
 -D ENABLE_CLI:BOOL=OFF ^
 -G "%CMAKE_VS_TYPE%" ..\..\..\source
 
pause
 
MSBuild /property:Configuration="Release";WholeProgramOptimization=%LTCG_OPTION% x265.sln
copy /y Release\x265-static.lib ..\8bit\x265-static-main10.lib
 
rem 8bit用のライブラリをビルド
cd "..\8bit"
cmake -D STATIC_LINK_CRT:BOOL=ON ^
    -D ENABLE_SHARED:BOOL=OFF ^
    -D CMAKE_CXX_FLAGS_RELEASE:STRING="%VC_OPTIONS%" ^
    -D CMAKE_C_FLAGS_RELEASE:STRING="%VC_OPTIONS%" ^
    -D CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING="%VC_LINKER_EXE_OPTIONS%" ^
    -D CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING="%VC_LINKER_MODULE_OPTIONS%" ^
    -D EXTRA_LIB:STRING="x265-static-main10.lib" ^
    -D LINKED_10BIT:BOOL=ON ^
    -G "%CMAKE_VS_TYPE%" ..\..\..\source
  
rem 情報収集用の実行ファイルを作成 (PGInstrument)
MSBuild /p:Configuration=Release;WholeProgramOptimization=%LTCG_OPTION% x265.sln
 
rem PGOビルドをしない場合はこれで終了
if "%LTCG_OPTION%" == "true" goto FINISH
  
rem 情報収集用にx265を実行(8bit)
release\x265.exe --crf 23 --preset medium -o nul "%TEST_MOVIE%"
release\x265.exe --crf 23 --preset slow --amp --weightb -o nul "%TEST_MOVIE%"
 
rem 情報収集用にx265を実行(10bit)
release\x265.exe --crf 23 --input-depth 8 --output-depth 10 --preset medium -o nul "%TEST_MOVIE%"
release\x265.exe --crf 23 --input-depth 8 --output-depth 10 --preset slow --amp --weightb -o nul "%TEST_MOVIE%"
  
rem 作成されたプロファイルをもとに
rem 最適化された実行ファイルを作成 (PGOptimize)
MSBuild /p:Configuration=Release;WholeProgramOptimization=PGOptimize x265.sln
 
:FINISH
rem これで終了
rem 8bit\release\x265.exeが最適化された実行ファイル

これで終わり。

x265、速くなった? (2016.12)

もう年末なので、x265の速度をチェックしてみた。

今年はどのくらい高速化されただろうか?

続きを読む

続きを閉じる

---

環境

---

PC環境

OS	Win 10 x64
CPU	i7 6700K
Core	4.3GHz
UnCore	4.1GHz
M/B	ASUS Z170M PLUS
RAM	DDR4-2933, 2ch
	16-18-18-38-2
RAM Size	16GB
GPU	-

使用したソフトウェアのバージョン

	バージョン	備考
Aviutl	1.00
x265guiEx	3.61	x265 1.7+2以前用
	3.75	x265 1.7+448以降用
x265	1.1+88	2014/6/16
	1.2+45	2014/7/11
	1.3+18	2014/8/23
	1.4+3	2014/11/1
	1.5+12	2015/2/15
	1.6+64	2015/4/4
	1.7+2	2015/5/19
	1.7+448	2015/8/25
	1.8+2	2015/10/8
	1.9+3	2016/1/29
	1.9+125	2016/4/10
	2.0+2	2016/7/15
	2.1+10	2016/9/28
	2.1+71	2016/12/21

入力
3月のライオン ED をx264guiEx + afsでエンコードしたもの
H.264/AVC 1920x1080p 23.976fps 9.5Mbps 1分30秒 2157frame

x265 オプション
--crf 21
--preset fast, medium, slow, slower

計測
一発勝負

---

結果 (ビットレート)

---

まあ、なんか昔は10bitがやたら膨らむ、という問題があった。

---

これだとわかりにくいで、少し拡大すると、



今年は、同じ設定だとやや膨れるようだ。

---

結果 (エンコード速度)

---

全体としては、こんな感じ。1.9あたりで大きく高速化したものの、その後やや遅くなっている。

---

下のほうがわかりにくいので、拡大すると…

---

1.8+2 (2015/10)の時の速度を1として、計算しなおすと…



特に重めのプリセットについて、大きな高速化が達成できていることがわかる。

---

終わりに

---

x265の更新頻度は、次第に緩やかになってきていて、今年は以前程は更新されなかったように思うが、もうやり尽くした感じなのだろうか?

まあでも、slowやslowerでも、だいぶ高速化され、そこそこ使用できるようになってきてよかったと思う。

圧縮率は十分良いと思うので、来年もさらなる高速化に期待したい。

---

x265、速くなった? (2015.12)

久しぶりにx265の速度をチェックしてみた。

今年はどのくらい高速化されただろうか?

続きを読む

続きを閉じる

---

環境

---

PC環境

OS	Win 8.1 x64
CPU	i7 6700K
Core	4.3GHz
UnCore	4.0GHz
M/B	Asrock Z170 Extreme5
RAM	DDR4-3200, 2ch
	16-18-18-38-2
RAM Size	16GB
GPU	-

使用したソフトウェアのバージョン

	バージョン	備考
Aviutl	1.00
x265guiEx	3.61	x265 1.7+2以前用
	3.65	x265 1.7+448以降用
x265	1.1+88	2014/6/16
	1.2+45	2014/7/11
	1.3+18	2014/8/23
	1.4+3	2014/11/1
	1.5+12	2015/2/15
	1.6+64	2015/4/4
	1.7+2	2015/5/19
	1.7+448	2015/8/25
	1.8+2	2015/10/8
	1.8+167	2015/12/12

入力
うたわれるもの 偽りの仮面 OP をx264guiEx + afsでエンコードしたもの
H.264/AVC 1920x1080p 23.976fps 10.9Mbps 1分30秒 2180frame

x265 オプション
--crf 21
(1.4+3以降) --pmode
--preset fast, medium, slow, slower

計測
一発勝負

---

結果 (ビットレート)

---

まあ、なんか昔は10bitがやたら膨らむ、という問題があった。

---

これだとわかりにくいで、少し拡大すると、



同じcrf値でも結構上下している。おおまかには容量は縮む方向にあるようだ。

---

結果 (エンコード速度)

---

全体としては、こんな感じ。順調に高速化している。

---

下のほうがわかりにくいので、拡大すると…

---

1.5+2 (2015/2)の時の速度を1として、計算しなおすと…



1.5+2からでも、おおむね30～40%、最大で50%の高速化を達成していることが分かる。

---

終わりに

---

slowerを入れたせいで、このベンチマークの全データを取るのに計18時間以上かかってしまった…。全部で80点あるし。

まあそれはさておき、今年もだいぶ高速化されたことが分かる。特に遅かった10bitエンコードもだいぶ速くなってきていて、うれしい限り。

x265はslowとかslowerにするとものすごく遅くなるのだけど、結構圧縮率も向上するので、そのあたりがもうちょっと速くなってくれると嬉しいのだが…。

画質は、個人的な使用用途がfullHDのアニメ1話を10bit crf=21で300MB、あわよくば200MB (ビットレートでいうと1Mbpsとか)にすることなので、うまくごまかせていてよいと思う。(とりあえず目立って悪いところはない)

---

x265 ビルド ～ PGO & multilib

以前コメントいただいたように、最近のx265では、1つの実行ファイルに8bit/10bit/12bitを含めることができるようになっていて、わざわざexeファイルを分ける必要はない。(multilibバイナリ)

そこで、x265をmultilibとしてビルドしつつ、懲りずにVisula StudioでPGOビルドした。

…ちょうどはいろいろ便利そうなVisula Studio 2015が出た時期にあれなんだけれど、Visual Studio 2013で記事は書いてしまった。

※追記 2015.07.28
現在LTCGあるいはPGOでビルドすると、12bitの出力がおかしくなる問題があるようです。そのため、記事中から12bitのビルドを削除し、8bit + 10bitのみの記述に変更しました。

続きを読む

続きを閉じる

---

ビルドの準備

---

Visual Studio Community 2013
CMake (Win32 Installer をダウンロード)
Mercurial (MSI installer かInno Setup installerのどちらかを)
yasm
適当なy4mファイル (ffmpegとかで自分で作るか、このあたりから適当に bus_cif.y4mとかで)

ffmpegでy4mを作る場合、
ffmpeg.exe -y -i <ソース動画> -an -pix_fmt yuv420p -f yuv4mpegpipe -frame 240 <出力.y4m>
とかで作れば良いと思う。

---

1. インストーラに従ってVisual Studio Community 2013をインストール。ダウンロード・インストール方法はこちら。

2. インストーラに従ってMericurialをインストール。環境変数を設定してもらうのを忘れないようにする。



3. インストーラに従ってCMakeをインストール。環境変数を設定してもらうのを忘れないようにする。



4.ダウンロードしたyasmをパスの通じているところへ配置する。さっきCMakeのbinにパスを通しているので、Cmake\binに放り込んだ。




5. ひとまず、コマンドプロンプトで、
がそれぞれ反応があるか確かめる。

これで準備は完了。

---

ビルド実行

---

これで終わり。

---

効果確認

---

環境
Win 8.1 x64
Core i7 5960X (8C/16T, L3=20MB)
Core 4.4GHz / Cache 3.8GHz
DDR4-2666, 4ch, 32GB
Aviutl 1.00
lwinput r785
x265guiEx 3.62(仮) (VS2015対応、mutlilib対応版)…週末公開予定

ソース
Charlotte OP を一度x265 + x264guiEx + afsでエンコードしたもの。
1920x1080p 23.976fps 約1分30秒

x265.exe 1.7+357 x64 8bit/10bit
・PGOビルド
・普通のLTCGビルド

x265 オプション
--preset slow --crf 21 --pmode --amp --weightb

---

結果

	LTCG	PGO	高速化率
8bit	4.28 fps	4.38 fps	+2.3%
10bit	2.41 fps	2.48 fps	+2.9%

8bit / 普通のLTCGビルド (4.28 fps)


8bit / PGOビルド (4.38 fps)


10bit / 普通のLTCGビルド (2.41 fps)


10bit / PGOビルド (2.48 fps)


わずかだが、少し速い。

まあただ、重いところはアセンブラで高速化されているのだろうし、効果は限定的だと思う。

---

x265 ビルド ～ Visual Studio PGOビルド

コメントで教えていただき、昨日書いたように、Visual Studio Community 2013が公開され、Professional相当の機能が使えるようになった。これによってPGO (Profile Guided Optimization, プロファイリングによる最適化) ビルドができるようになった。

そこで、PGOビルドなx265を作ってみた。PGOビルドはGUIからやると割と面倒なので、あまり好きじゃないけどコマンドベースで。

普通のビルドに比べて2～3%高速。やる価値あるかというと、少なくとも「やって損はない」かな、と。

※2015.06.01 更新 - 最適化オプションを調整。

続きを読む

続きを閉じる

---

PGOビルド

---

通常のコンパイラの最適化は、コンパイル時にコードを解析して最適化をかける。PGO (プロファイリングによる最適化) は、それに加えて、実際にプログラムを実行した時の情報を使ってさらなる最適化を加える。gccだと、-fprofiledかな?

実際の手順は、

1. 情報収集用の実行ファイルをまずコンパイル。

2. 1で作成した実行ファイルで実際にプログラムを走らせ、情報を収集。exeを実行すると同じフォルダにpgcファイルができる(これが収集した情報)。

3. 2で収集した情報をもとにさらに最適化。

行われる最適化は、

・より的確なインライン展開の判断。

・レジスタ割り当ての最適化。

・最適な/Og ←→ /Os 切り替え。

・関数レイアウトの最適化。測定した関数の呼び出し傾向をもとに、呼び出される関数を呼び出し元の近くに配置し、(命令)キャッシュ効率を向上させる。

・使用頻度の低い部分の分離。これもキャッシュ効率の向上につながる。

・プログラム実行中、どちらがtrueになりやすいかという情報に基づいて、条件分岐の最適化。

などなど。

---

ビルドの準備

---

Visual Studio Community 2013
CMake (Win32 Installer をダウンロード)
Mercurial (MSI installer かInno Setup installerのどちらかを)
yasm
適当なy4mファイル (ffmpegとかで自分で作るか、このあたりから適当に bus_cif.y4mとかで)

ffmpegでy4mを作る場合、
ffmpeg.exe -y -i <ソース動画> -an -pix_fmt yuv420p -f yuv4mpegpipe -frame 240 <出力.y4m>
とかで作れば良いと思う。

---

1. インストーラに従ってVisual Studio Community 2013をインストール。ダウンロード・インストール方法はこちら。

2. インストーラに従ってMericurialをインストール。環境変数を設定してもらうのを忘れないようにする。



3. インストーラに従ってCMakeをインストール。環境変数を設定してもらうのを忘れないようにする。



4.ダウンロードしたyasmをパスの通じているところへ配置する。さっきCMakeのbinにパスを通しているので、Cmake\binに放り込んだ。




5. ひとまず、コマンドプロンプトで、
がそれぞれ反応があるか確かめる。

これで準備は完了。

---

ビルド実行

---

これで終わり。

---

効果は?

---

環境
Win 8.1 x64
Core i7 5960X (8C/16T, L3=20MB)
Core 4.4GHz / Cache 3.8GHz
DDR4-2666, 4ch, 32GB
Aviutl 1.00
lwinput r726
x265guiEx 3.48v2

ソース
グリザイアの果実 (アニメ) OP を一度x264 (crf=18) + x264guiEx + afsでエンコードしたもの。
1920x1080p 23.976fps H.264/AVC 2155frames 8483kbps

x265.exe 1.4+62 x64 8bit
・PGOビルド
・普通のLTCGビルド
実行ファイルはこちら。

x265 オプション
--preset medium --crf 21
--preset slow --crf 21 --pmode

---

結果

	LTCG	PGO	高速化率
medium	26.86 fps	27.63 fps	+2.9%
slow + pmode	9.82 fps	10.07 fps	+2.5%

普通のLTCGビルド (9.87 fps)


PGOビルド (10.07fps)


わずかだが、確かに速い。

---

とまあ、こんな感じで、たしかに効果はあるけど、すごい効果があるわけでもない。でも速いならそれに越したことはなく、やって損はない、という感じ。

これもVisual Studio Community 2013が公開されたからできることなので、ありがたいことだと思う。

---

x265、速くなった? (2014.11)

x265もだいぶ速くなってきたかな?、というわけで再びテスト。



最近のx265の重要な更新は、
・AVX2最適化
・pmode(とpme)
の追加。

pmodeはCU(ブロック)単位で並列処理して、並列度を上げて、マルチコアCPUをより有効に使う。圧縮率に影響なく(あるいはやや向上させながら)、CPU使用率を引き上げるらしい。なんかすごい。

pmodeとAVX2最適化によって、さらに速度が向上したはずなので、そのあたりがどのくらいのものかを測定。

続きを読む

続きを閉じる

---

環境と条件

---

環境
Win 8.1 x64
Core i7 5960X (8C/16T, L3=20MB)
Core 4.4GHz / Cache 4.0GHz
DDR4-2666, 4ch, 32GB
Aviutl 1.00
lwinput r726
x265guiEx 3.47(仮)

ソース
グリザイアの果実 (アニメ) OP を一度x264 (crf=18) + x264guiEx + afsでエンコードしたもの。
1920x1080p 23.976fps H.264/AVC 2155frames 8483kbps

x265.exe x64 8bit
0.8+3　(2014.03.05)
1.0+4　(2014.05.03)
1.1+88 (2014.06.16)
1.2+45 (2014.07.11)
1.3+18 (2014.08.23)
1.4+3 　(2014.11.03)

x265オプション
--preset <medium or slow> --crf 21 --tune ssim --ssim [ --pmode ] [ --asm avx ]

x265の--preset medium と　--preset slow それぞれについて試した。あと、1.4+3では--pmodeありとなしでそれぞれ測定。

測定
一発勝負
計測データ

---

ビットレートとSSIM

---

まずはpreset mediumの時とslowの時それぞれのビットレートとSSIM。

SSIMは画質のだいたいの目安で値が大きいほうが高画質。

ビットレートとSSIM


preset mediumよりslowのほうが当然SSIMもよく、ビットレートも小さい。

1.0 と 1.1の間に大きな差があって、もう覚えてないけどプリセット自体が変わったんだろうなと思う。あと、--pmodeをつけると、少しSSIMが向上し、ごくわずかに容量が膨らんでいる。

---

エンコード速度とCPU使用率

---

次に本題の
・エンコード速度(fps, 棒グラフ, 左軸)
・CPU使用率(%, 折れ線, 右軸)
のグラフ。

まずはpreset mediumについて。AVX2ありとAVXまでの時をそれぞれ測った。

結果 (medium)


バージョンを追うごとに少しづつ速くなっている。特に1.4ではAVX2使用によって明らかに速い(10%弱)。x265 1.4+3のAVX2の速度は24fpsを超えていて、x265は確かに重いけど、5960Xを使えばfullHDの24fpsを等倍でエンコードできるみたい。

--pmodeによってCPU使用率を70%台から80%台へ上がるけど、逆に速度は下がっている(画質は少し上がってるけど)。--pmodeが効果が大きいのは、--rd 3～4で--rectがオンのときということなので、そんなに効率が良くないのかな? (preset mediumでは--rdは3だけど--rectはオフなため)

---

次にpreset slowについて。AVX2ありとAVXまでの時をそれぞれ測った。

結果 (slow)


プリセットslowも同様にどんどん高速化している。mediumほどではなけど、1.4+3でAVX2が効いているのがわかる(3%程度)。

slowでは、--pmodeによってCPU使用率は大きく上がって、70%台から90%台になった。これによって、pmodeをつけたほうが速くなっている。slowでは--rd 4 --rectなので、pmodeが大きな効果を発揮できるんだろう。

---

以前速度を測定した時はx265 0.6とかだったので、そのころと比べるとかなり速くなってるし、2passエンコードやpsyが追加されてきて次第に機能面でも整ってきている。

pmodeによりマルチコアをより有効に使えるようになり、AVX2への最適化も進んだ。x265はx264よりも大きブロックサイズを扱うので、AVX2がより効果があるかもしれない。

今後もコードの整理やAVX2最適化によって高速化していくことに期待したい。

---

x265、速くなった? (2013年末)

以前x265を触ってからしばらく経ち、x265もだいぶ更新された。

crfやAQのような極めて重要な機能が追加されたほか、高速化も相当行われた。

そうしたなか、いくらなんでも「画質すごいけど、720pで1fpsしかでない」などと書いたまま放置しておくのはさすがにどうかと思った。そこで、現時点でpresetによってどのくらいの速度が出るのか確認した。

※今回はソースにもともとノイズが多く、よくわからないので画質については比較しません。

続きを読む

続きを閉じる

---

環境
Win7 x64
Core i7 4770K @ 4.1GHz
DDR3-2600, 2ch, 16GB
Aviutl 1.00
x265guiEx 3.15β
※x264エンコ時にはx265guiExのx264モードを使用

x264.exe rev2377 x64 (8bit) POP氏ビルド
x264.exe rev2377 x64 (10bit) たくあん氏ビルド
x265.exe 0.6+232 x64 (8bit) x265.cc VC12ビルド

ソース
1920x1080p 23.976fps のんのんびより OP 2155フレーム (1分30秒)

測定
いつも通り一発勝負

オプション設定
--crf 20 --preset <各プリセット>

非常にシンプルにcrf20の時の各プリセットでエンコードして、そのビットレートとエンコード速度を比較。placeboは勘弁して下さい。

---

まずはビットレートの確認から。


概ね4000～5000kbps…とおもいきや、x265のfast～veryslowが壮絶に高圧縮に。これはAQ + CUTreeがオンになるためだと思われるけど、さすがにここまで容量が変わると画質も相当変わってきている(ビットレートが落ちたぶん、画質も悪化している)。同じcrfならある程度は似た画質になってほしいなと思うけど、この辺りまだ調整中なのかな、と。(結構頻繁にプリセットの内容も変わるので)

---

次にエンコード速度。


「遅すぎる」「速度の桁が違う」という状況から、大きく改善。

とりあえず今回は1920x1080pに対してveryslowでも1fps出ている。(オプションも違うので単純に比較はできないけど、前回は激重設定で1280x720に対して1fpsだった)

ざっと見ると
x264 8bit veryslow = x265 medium
x264 10bit veryslow = x265 slow
ぐらい。

とりあえずslowにするとfullHDで4.6fps…このぐらいなら大丈夫ですよね? え…だめ?

---

画質は比較しないといったけど、一応感想だけ。

x265のmediumでは、ややのっぺりとしたり、動きの多いところで輪郭周りが汚かったりしたものの、致命的な破綻はなく、fullHDに対して1.4Mbps程度なのに健闘していると感じた。

---

x265はまだまだ開発段階だし、HEVCのコンテナへの格納も定まっていないということのようなので、実用段階ではない。

ただ、着実に機能の追加と高速化が図られているので、前の記事にコメントいただいたように、来年もその更新に期待したい。

---