rigayaの日記兼メモ帳 x265、速くなった? (2016.12)

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でも、だいぶ高速化され、そこそこ使用できるようになってきてよかったと思う。

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

スポンサーサイト

2016-12-22(20:51) :
x265 :
コメント 13 :
トラックバック 0

このページのトップへ

前の記事 « ホーム » 次の記事

トラックバック

この記事にトラックバックする(FC2ブログユーザー)

このページのトップへ

コメントの投稿

測定ありがとうございます
2.0以降の開発は速度よりも画質の向上に力を入れていたのでしょうか

2016-12-23(01:55) :
URL :
編集

Re: タイトルなし

うーん、どうなんでしょう。どちらかというと、機能追加が多かった記憶がありますが…。

2016-12-23(22:41) :
rigaya URL :
編集

実エンコード時間

いつも最新のpgo版を使わせていただいています。
鋼の錬金術師 #40「傷痕」23分52秒を2.1+55でエンコードした時にかかった時間が28分14秒、71では20分7.5秒でエンコード終了しました。ファイル容量200,918KB。使用状況は以下の設定です。rigayaさんのように高品質な設定ではありません。自分の見た目で許容範囲内にあれば良しと割り切っています。

: x265guiEx 3.75 / Windows 10 (x64) / Intel Core i7-3770K @ 3.50GHz [TB: 4.40GHz] (4C/8T)
: converting YUY2 -> i420p, using SSE2 AVX
: x265 options...
--input-csp i420 --preset faster --tune zerolatency --crf 25 --rc-lookahead 15 --psy-rd 1 --psy-rdoq 1 --scenecut 40
--keyint 240 --bframes 4 --b-adapt 1 --b-pyramid --me dia --ref 1 --colormatrix smpte240m --colorprim film --transfer
smpte240m --qg-size 64 --frame-threads 0 --cutree --frames 34332 --input-res 1920x1080 --fps 2997/125 -o
: 1920x1080 fps 2997/125 i420p8 unknown frame count
: HEVC encoder version 2.1+71-e8152da7aa0e
: build info [Windows][MSVC 1900][64 bit] 8bit+10bit
: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
: Main profile, Level-4 (Main tier)
: Thread pool created using 8 threads
: Slices : 1
: frame threads / pool features : 3 / wpp(17 rows)
: Coding QT: max CU size, min CU size : 64 / 8
: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
: ME / range / subpel / merge : dia / 57 / 2 / 2
: Keyframe min / max / scenecut / bias: 23 / 240 / 40 / 5.00
: Lookahead / bframes / badapt : 15 / 4 / 1
: b-pyramid / weightp / weightb : 1 / 1 / 0
: References / ref-limit cu / depth : 1 / on / on
: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 64 / 1
: Rate Control / qCompress : CRF-25.0 / 0.60
: tools: rd=2 psy-rd=1.00 early-skip rskip signhide tmvp fast-intra
: tools: strong-intra-smoothing lslices=6 deblock sao
: frame I: 433, Avg QP:22.13 kb/s: 5812.07
: frame P: 12171, Avg QP:24.00 kb/s: 1814.67
: frame B: 21728, Avg QP:30.60 kb/s: 173.67
: Weighted P-Frames: Y:2.7% UV:1.7%
: consecutive B-frames: 41.8% 16.5% 3.9% 3.0% 34.8%

encoded 34332 frames in 1171.16s (29.31 fps), 826.53 kb/s, Avg QP:28.15
: CPU使用率: Aviutl: 25.46% / x265: 67.83%
: x265エンコード時間 : 0時間19分31.3秒
: NeroAacEnc で音声エンコードを行います。 AAC-LC ビットレート指定, 320kbps
: L-SMASH muxer (r1417) でmuxを行います。映像: on, 音声: on, tc:off, chap:off, 拡張モード:なし
: 総エンコード時間 : 0時間20分 7.5秒

実写の映画は品質を高めにしていますが、それでもcrf 22です。
ハリー・ポッターと死の秘宝ＰＡＲＴ１　2時間26分を2.1+70でエンコードした時の時間が3時間43分10秒、71では3時間36分35秒、約7分短くなりました。ファイル容量1,644,903KB。使用状況は以下の設定です。
: x265guiEx 3.75 / Windows 10 (x64) / Intel Core i7-3770K @ 3.50GHz [TB: 4.40GHz] (4C/8T)
: converting YUY2 -> i420p, using SSE2 AVX
: x265 options...
--input-csp i420 --preset fast --crf 22 --psy-rd 1 --psy-rdoq 1 --keyint 300 --b-adapt 2 --me dia --subme 3 --ref 1
--colormatrix smpte240m --colorprim film --transfer smpte240m --qg-size 64 --frames 262838 --input-res 1920x1080 --fps
2997/100 -o
: 1920x1080 fps 2997/100 i420p8 unknown frame count

: HEVC encoder version 2.1+71-e8152da7aa0e
: build info [Windows][MSVC 1900][64 bit] 8bit+10bit
: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
: Main profile, Level-4 (Main tier)
: Thread pool created using 8 threads
: Slices : 1
: frame threads / pool features : 3 / wpp(17 rows)
: Coding QT: max CU size, min CU size : 64 / 8
: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
: ME / range / subpel / merge : dia / 57 / 3 / 2
: Keyframe min / max / scenecut / bias: 29 / 300 / 40 / 5.00
: Lookahead / bframes / badapt : 15 / 4 / 2
: b-pyramid / weightp / weightb : 1 / 1 / 0
: References / ref-limit cu / depth : 1 / on / on
: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 64 / 1
: Rate Control / qCompress : CRF-22.0 / 0.60
: tools: rd=2 psy-rd=1.00 rskip signhide tmvp fast-intra
: tools: strong-intra-smoothing lslices=6 deblock sao
: frame I: 1840, Avg QP:19.89 kb/s: 8546.52
: frame P: 56525, Avg QP:22.64 kb/s: 3240.63
: frame B: 204473, Avg QP:26.84 kb/s: 628.88
: Weighted P-Frames: Y:3.0% UV:1.4%
: consecutive B-frames: 6.1% 2.9% 5.0% 6.5% 79.5%

encoded 262838 frames in 12735.18s (20.64 fps), 1245.98 kb/s, Avg QP:25.88
: CPU使用率: Aviutl: 16.97% / x265: 73.24%
: x265エンコード時間 : 3時間32分16.1秒
: NeroAacEnc で音声エンコードを行います。 AAC-LC ビットレート指定, 320kbps
: L-SMASH muxer (r1417) でmuxを行います。映像: on, 音声: on, tc:off, chap:off, 拡張モード:なし
: 総エンコード時間 : 3時間36分35.0秒

H264には変換速度は見劣りしますが、自分の目で見た画質に対する許容範囲内の設定ができれば、既に実用レベルにあると感じています。実際私はこの設定でH265に移行しました。それも、rigayaさんのこのブログのおかげです。
ありがとうございます。これからも、pgo版よろしくお願いします。

2016-12-24(09:33) :
jin URL :
編集

Re: 実エンコード時間

x265はやろうと思えば際限なく重くできますが、おっしゃるようにある程度割り切って、medium～slow前後ならそこそこの速度が出るようになってきていると思います。今後も定期的に更新していく予定です。

2016-12-24(21:38) :
rigaya URL :
編集

re: 実エンコード時間

ナカーマ
私はほぼ全ての海外連続ドラマをmedumのcrf 22.5でエンコードするようになりました。
でも使ってるのがナローPCで2時間とか平気でかかるので映画は態度保留中なのですが、sandyのi7なら20fps超えるんですね。羨ましいです。

2016-12-25(00:50) :
URL :
編集

RE:re: 実エンコード時間

速度UPにつながる設定は反面画質を落としますが、画面を2つ並べて比較しないと判別できないものは割り切って設定を落とすことで考えています。
出力色深度は8bitで十分ですし、出力色フォーマットもi420で十分です。細かいところでは、色空間のcolormatrixも自動を止めてsmpte240mを指定、colorprimはfilmを指定、transferはcolormatrixと同じsmpte240mを指定することで、すべて自動に設定していた時より処理速度が上がります。
私はシングルパス-品質基準VBRしか使いませんが、元ソースの色彩、動きの激しさで変換効率が変わります。同じ４５分ドラマで変化の少ないものは１時間１５分目安でエンコード出来ますが、中国歴史ドラマの極彩色で画面の動きの激しい物はエンコードに１時間３０分を超え出来上がりのサイズも倍になります。
crf 22だと、動きが激しくても画像の崩れが気になりません。気になったときは、元ソースの画像が既にボケています。1年以上前のx265.exeでの設定なので、バージョンUPした今の状態は当時に比べ画質が向上しています。(判断材料は、同じアニメの同一回をエンコードした場合、完成サイズが少し大きくなっているからです)なので、crf22.5で、仮面ライダー(アクションシーンで画像の崩れの判断がしやすい)をエンコードしてみたいと思います。アニメはcrf25に割り切りましたので、22→22.5が見た目に差が出るのか、変換時間とサイズがどう変わるか、実測結果を報告します。

私もrigayaさんと同じ自作PCなので、設定を変えている時に自作の盲点に気が付きました。メーカー製のPCでマザーボードの電圧設定を変えられない人は無関係の話になります。
クロックアップしてAviUtlのバッヂ処理中にHWMonitorでCPUの各コア使用率を見ると、８コア９０％以上もちろん最高は全て１００％ですが、UCの変動値を見るとおよそ95％前後の平均値になっています。
殻割していないので4.4GHzで現在運用していますが、4.2GHzで電圧を十分かけていた時は、ほぼ各コア使用率が１００％に貼りついていました。なので、4.2GHz→4.4GHzでのエンコード時間はほとんど変化なしです。
以前どなたかの記事でAviUtlを2つ起動させると約１．５倍の処理が出来た。という内容を拝見しましたが、私の場合は1つでCPUの８コアを95％使用していたので、2つ起動すると2つ目は十数時間かかって、1つ目も少し遅くなったので、CPUの使用率が１００％を超えることはあり得ない、という単純な事実を確認しました。
何が言いたいかと言えば、今のAviUtlの変換速度はPCの能力上限に近いのかは、CPUの使用率を確認しないとはっきりしないということです。自作PCの場合単純に電圧を上げてやることで改善します。それにより上昇する温度とバランスを考える必要がありますが。
電圧を変えられない場合は、環境設定で優先度を上げればよいのかもしれません。私の場合は、Normalで95％(瞬間的には98％～100％)の使用率なので、優先度を上げると他の動きが悪くなるだけで、実行速度は変わりませんでしたが、使用率に余裕がある場合は効果があるかもしれません。
AviUtlは結構大変なアプリで、マザーボードの電圧設定がおかしいとx265の変換中にパラメーター異常を起し、処理が中断します。正常な場合バッチ処理で丸一日エンコードしても問題は発生しません。私の場合、マザーボードの設定を変更した場合、丸一日連続エンコードに失敗しない事が設定完了の目安になっています。

2016-12-25(15:59) :
jin URL :
編集

ショッキングな事実が判明

仮面ライダーキバ #33「スーパーソニック・闘いのサガ」(1920x1080)　のエンコード結果

CRF-22.0
encoded 42107 frames in 2318.59s (18.16 fps), 2174.23 kb/s, Avg QP:25.90
: CPU使用率: Aviutl: 14.51% / x265: 78.60%
: x265エンコード時間 : 0時間38分38.7秒
: NeroAacEnc で音声エンコードを行います。 AAC-LC ビットレート指定, 320kbps
: L-SMASH muxer (r1417) でmuxを行います。映像: on, 音声: on, tc:off, chap:off, 拡張モード:なし
: 総エンコード時間 : 0時間39分48.6秒
ファイル容量 428,317KB

CRF-22.5
encoded 42107 frames in 2456.95s (17.14 fps), 1981.86 kb/s, Avg QP:26.70
: CPU使用率: Aviutl: 14.75% / x265: 74.40%
: x265エンコード時間 : 0時間40分57.1秒
: NeroAacEnc で音声エンコードを行います。 AAC-LC ビットレート指定, 320kbps
: L-SMASH muxer (r1417) でmuxを行います。映像: on, 音声: on, tc:off, chap:off, 拡張モード:なし
: 総エンコード時間 : 0時間42分 7.2秒
ファイル容量　395,325KB

品質を22.0→22.5へ0.5落とすと、ファイル容量は小さくなりますが、エンコード時間は余分にかかる。という意外な結果となりました。
原因として考えられるのは、標準プロファイルで設定されている品質22と23は最適化が行われており、作業効率が他の設定より高い、あるいは整数の設定で最適化されている、ということだと思われます。
私の設定で、速度　fast、動き予測のアルゴリズムをDiamond Search(高速)、最大動き領域統合数　2、量子化ブロックサイズ64、先行探索フレーム数　15、参照距離　1、最大連続Bフレーム数　4、重み付きBフレーム　チェック外す、という当たりが標準の高品質プロファイルから速度重視に振った変更点です。
この設定が22.0と22.5の変換速度の逆転につながっているのかも知れません。ちなみに、現在21.0で変換中ですが、さすがにこれは47分ほどかかりそうです。23分25秒のエンコードに8分プラスの47分と出来上がりの画質の向上、ファイルサイズの増加をどう判断するかがポイントですが、私の場合はやはりCRF-22.0に落ち着きそうです。
ちなみに22.0と22.5の画質の差は９０％以上気になりません。画面の乱れはありませんが、所々で色の偏移というか微妙なボヤケを感じる程度です。これも、ファイルサイズの減少を選ぶか、画質にこだわるか、その人の判断になりそうな気がします。ただ、エンコード時間まで加味すると、現時点ではCRF-22.0を選択します。

2016-12-25(18:18) :
jin URL :
編集

No title

詳細な情報と検証ありがとうございます。

私の場合は高画質である必要のない放送大学やNHKドキュメンタリーを小さくするためにx265を使い始めて、そこから利用範囲を広げての22.5という落としどころでした（放送大学は22.8、ドラマ系は22.5、超お気に入りドラマにはまだx264を使ってた）。

最近（ver. 2.1に入ってから）は超お気に入りのテレビドラマシリーズでも使い始めてもうちょい下げたほうが・・と思いつつそれで増えるファイルサイズを嫌って22.5のまま使っているところでしたが詳細なレビューを読んで、crf 22.0を使わない手はないような気がしてきたので次からcrf22で運用してみようと思います。

それと色空間の直接指定による速度差など一切、考えたこともありませんでした。
まったく視点の異なる意見でとても参考になります。

それにしてもcrf 22.0のほうが早いとはなんという盲点・・。

2016-12-25(22:34) :
URL :
編集

CRF-21.0の変換結果

encoded 42107 frames in 2616.42s (16.09 fps), 2574.71 kb/s, Avg QP:24.77
: CPU使用率: Aviutl: 13.72% / x265: 73.05%
: x265エンコード時間 : 0時間43分36.6秒
: NeroAacEnc で音声エンコードを行います。 AAC-LC ビットレート指定, 320kbps
: L-SMASH muxer (r1417) でmuxを行います。映像: on, 音声: on, tc:off, chap:off, 拡張モード:なし
: 総エンコード時間 : 0時間45分 4.7秒
ファイルサイズ 497,001KB
思ったより時間はかからず、サイズの増加もそれなりの結果のような気がします。
特別に愛着のあるファイルを保存する場合は、これもありかな、という結果のように思われます。品質に不満はありませんが、22との違いは見比べないとわからない。画面が鮮やかになっている気がします。という、こだわりを持ちたい場合の設定です。逆に、普通の保存用は22で十分という認識を改めて感じた次第です。
もっとも、私の設定が品質は高めにして変換速度を重視した結果、あまり差が見えにくい、ということも有るとは思います。

2016-12-25(23:17) :
jin URL :
編集

AviUtlのスレッド使用率を高める方法

実は知り合いがx265の変換で、1～4FPSしか出ていないというので確認できたことですが、8スレッドの使用率が80％～90％しか使われていませんでした。
原因はAviUtlのシステム設定で、「画像処理のスレッド数」を0=自動設定　にして、「個別のCPUを割り当てる」のチェックを入れていないことでした。
まず、AviUtlは4スレッドの動作が上限で、それ以上スレッド数を増やしても速度は変わりません。さらに個別のCPUを割り当てることをしていないため、4コア8スレッド全てを使用していたことになります。
4スレッドを指定して、更に個別のCPUを割り当てることで、無駄な2コア、4スレッドを解放し、x265.exeの使用率を上げてやることで、80～90までしか上がらなかった8スレッドの使用率が最低97まで上昇し、同じ設定のまま4FPS→8FPSに上昇しました。
AviUtlのシステム設定で間違った設定をされている方は、4スレッド指定の個別CPUを割り当てるだけでかなりの速度改善につながるはずです。
蛇足ながら、私の使っている設定に変えたところ、12FPSまで上がったとのことです。

2016-12-27(02:16) :
jin URL :
編集

勘違い

x265の出力設定で、色空間の考え方が間違っていました。
transferで数の少ないsmpte240mを指定した方が処理は早いだろうと単純に考えていましたが、元ファイルの設定を変えない方が、２４分３８秒のアニメで１分２０秒ほど早くエンコードが終わります。
ハイビジョン規格のbt709をcolormatrixとtransferに指定する方が、smpte240mを指定するより作業量が少なくなるようです。
colormatrix　smpte240m、 transfer smpte240mの場合が31:24:09
colormatrix　bt709、 transfer smpte240mの場合が30:57:02
colormatrix　bt709、 transfer bt709の場合が30:02:06
colormatrix　bt709、 transfer bt2020-10の場合が31:00:04
colormatrix　bt709、 transfer smpte st 2084の場合が30:12:07
不思議なことに、transferにHDR規格のsmpte st 2084を持ってきても、10秒の違いしかありません。色数の少ない240mよりst 2084の方が45秒早いという意外な結果です。
元ファイルがSD規格のbt601だったら違った結果が出たのではないかと思います。
いずれにしても、4K放送になった場合はsmpte st 2084を選べばよいということはなんとなく分かりました。

2016-12-28(22:14) :
jin URL :
編集

preset fastとfasterの速度差

勘違いで書いた数値はpreset fastでエンコードした時間です。アニメのCRF-25.0をfast変換した場合、色空間colormatrix　bt709、transfer bt709、tune zerolatencyを使ったときに、24分38秒のアニメが30分2秒06で完成し、サイズが247,210KBと最も小さく出来上がりました。
ところで、私は通常アニメの場合CRF-25.0、preset fasterで変換していますので、それで試したところ23分43秒03と25％ほど早くなり、出来上がりサイズは263,869KBと7パーセントほど増加しました。
時間の減少とサイズの増加をどのように考えるかで、選択肢は変わると思います。
また、HEVC encoder version 2.2+11で変換した結果は、version 2.1+71に対して時間は5％遅くなり、容量は1％増加しました。2.1も70から急に速くなった印象がありますので、2.1+55あたりの速さのような気がします。

2016-12-29(08:59) :
jin URL :
編集

ver 2.2+22

HEVC encoder version 2.1+71が2.1の最速でしたが、2.2は+22で5％ばかり 2.1+71より速くなりました。
サイズは、0.02%ばかり増えるようですが、予想より早く前バージョンより速くなったので、今後の更新が楽しみです。

2017-01-09(08:33) :
jin URL :
編集

このページのトップへ

« 前の記事ホーム次の記事 »

このページのトップへ