x265、速くなった? (2016.12)

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

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

環境



PC環境
OSWin 10 x64
CPUi7 6700K
Core4.3GHz
UnCore4.1GHz
M/BASUS Z170M PLUS
RAMDDR4-2933, 2ch
16-18-18-38-2
RAM Size16GB
GPU-


使用したソフトウェアのバージョン
バージョン備考
Aviutl1.00
x265guiEx3.61x265 1.7+2以前用
3.75x265 1.7+448以降用
x2651.1+882014/6/16
1.2+452014/7/11
1.3+182014/8/23
1.4+32014/11/1
1.5+122015/2/15
1.6+642015/4/4
1.7+22015/5/19
1.7+4482015/8/25
1.8+22015/10/8
1.9+32016/1/29
1.9+1252016/4/10
2.0+22016/7/15
2.1+102016/9/28
2.1+712016/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でも、だいぶ高速化され、そこそこ使用できるようになってきてよかったと思う。

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


スポンサーサイト

コメントの投稿

非公開コメント

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

Re: タイトルなし

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

実エンコード時間

いつも最新の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です。
ハリー・ポッターと死の秘宝 PART1 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版よろしくお願いします。

Re: 実エンコード時間

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

re: 実エンコード時間

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

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

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

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

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

仮面ライダーキバ #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の画質の差は90%以上気になりません。画面の乱れはありませんが、所々で色の偏移というか微妙なボヤケを感じる程度です。これも、ファイルサイズの減少を選ぶか、画質にこだわるか、その人の判断になりそうな気がします。ただ、エンコード時間まで加味すると、現時点ではCRF-22.0を選択します。

No title

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

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

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

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

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

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で十分という認識を改めて感じた次第です。
もっとも、私の設定が品質は高めにして変換速度を重視した結果、あまり差が見えにくい、ということも有るとは思います。

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まで上がったとのことです。

勘違い

x265の出力設定で、色空間の考え方が間違っていました。
transferで数の少ないsmpte240mを指定した方が処理は早いだろうと単純に考えていましたが、元ファイルの設定を変えない方が、24分38秒のアニメで1分20秒ほど早くエンコードが終わります。
ハイビジョン規格の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を選べばよいということはなんとなく分かりました。

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あたりの速さのような気がします。

ver 2.2+22

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

rigaya

Author:rigaya
アニメとか見たり、エンコードしたり。
連絡先(@を半角にしてください!)
rigaya34589@live.jp
github

最新記事
最新コメント
カテゴリ
月別アーカイブ
カウンター
検索フォーム
いろいろ
公開中のAviutlプラグインとかのダウンロード

○Aviutlプラグイン
x264guiEx 2.xx (ミラー)
- x264を使用したH264出力
- x264guiExの導入>
- x264.exeはこちら>

x265guiEx (ミラー)
- x265を使用したH.265/HEVC出力
- x265.exeはこちら>

QSVEnc + QSVEncC (ミラー)
- QuickSyncVideoによるH264出力
- QSVEncCはコマンドライン版
- QSVEncC 導入/使用方法>
- QSVEncCオプション一覧>

NVEnc + NVEncC (ミラー)
- NVIDIAのNVEncによるH264出力
- NVEncCオプション一覧>

VCEEnc + VCEEncC (ミラー)
- AMDのVCEによるH.264出力

ffmpegOut (ミラー)
- ffmpeg/avconvを使用した出力

自動フィールドシフト (ミラー)
- SSE2~AVX2による高速化版
- オリジナル: aji様

エッジレベル調整MT (ミラー)
- エッジレベル調整の並列化/高速化
- SSE2~AVX対応
- オリジナル: まじぽか太郎様

バンディング低減MT (ミラー)
- SSE2~AVX2による高速化版
- オリジナル: まじぽか太郎様

PMD_MT (ミラー)
- SSE2~FMA3による高速化版
- オリジナル: スレ48≫989氏

透過性ロゴ (ミラー)
- SSE2~FMA3によるSIMD版
- オリジナル: MakKi氏

AviutlColor (ミラー)
- BT.2020nc向け色変換プラグイン
- BT.709/BT.601向けも同梱

○その他
x264afs (ミラー)
- x264のafs対応版

aui_indexer (ミラー使い方>)
- lsmashinput.aui/m2v.auiの
 インデックス事前・一括生成

auc_export (ミラー使い方>)
- Aviutl Controlの
 エクスポートプラグイン版
 エクスポートをコマンドから

aup_reseter (ミラー)
- aupプロジェクトファイルの
 終了フラグを一括リセット

CheckBitrate (ミラー, 使い方, ソース)
- ビットレート分布の分析(HEVC対応)

チャプター変換 (ミラー使い方>)
- nero/appleチャプター形式変換

エッジレベル調整 (avisynth)
- Avisynth用エッジレベル調整

メモリ・キャッシュ速度測定
- スレッド数を変えて測定

○ビルドしたものとか
L-SMASH (ミラー)
x264 (ミラー)
x265 (ミラー)

○その他
サンプル動画
その他

○読みもの (ミラー)
Aviutl/x264guiExの色変換
動画関連ダウンロードリンク集
簡易インストーラの概要

○更新停止・公開終了
改造版x264gui
x264guiEx 0.xx
RSSリンクの表示
リンク
QRコード
QR