環境・条件
テスト用の環境はこんな感じ。前の環境からソフトウェアやドライバのバージョンをアップデートしている。
| x264
x265 | nvenc
(1060) | nvenc
(2070) | qsv
(HSW) | qsv
(KBL) | qsv
(ICL) | >vce
(Vega) |
| CPU | i9 7980xe | i3
4170 | i7
7700K | i5
1035G7 | R3
3200G |
| GPU | - | GTX
1060 | RTX
2070 | HDG
4400 | HDG
630 | Iris
Plus | Vega8 |
| ドライバ | 442.19 | 5058 | 7870 | 7641 | 20.2.1 |
| OS | Win10 x64 |
使用ソフトx264 r2988 x64
x265 3.3+2 x64
NVEncC 4.68 x64
QSVEncC 3.33 x64
VCEEncC 5.04 x64
入力sample_movie_1080p.mpg
MPEG2 1920x1080 29.97fps 5203frame
使用コマンドQSVEnc/NVEncについては、おそらく画質が一番高くなるであろうオプションを試した。x264/x265はきりがないのでpresetをそのまま使用している。
なお、x264/x265では、今回入れてない--tune ssimを入れてssimに最適化したエンコをすることでさらにssim的には改善の余地があることに注意。
x264 medium--crf <x>
x264 veryslow--crf <x> --preset veryslow
x265 medium--crf <x>
x265 veryslow--crf <x> --preset veryslow
x265 medium 10bit--crf <x> --input-depth 10 --output-depth 10
x265 veryslow 10bit--crf <x> --input-depth 10 --output-depth 10 --preset veryslow
nvenc H.264--vbrhq 0 --vbr-quality <x> --preset quality --weightp --bref-mode each --lookahead 32 --level 5.2
nvenc HEVC--vbrhq 0 --vbr-quality <x> --preset quality --weightp --bref-mode each --lookahead 32 -c hevc --level 6
nvenc HEVC 10bit--vbrhq 0 --vbr-quality <x> --preset quality --weightp --bref-mode each --lookahead 32 -c hevc --level 6 --output-depth 10
nvenc HEVC + Bframes--vbrhq 0 --vbr-quality <x> --preset quality --weightp --bref-mode each --lookahead 32 -c hevc --level 6 -b 3
nvenc HEVC 10bit + Bframes--vbrhq 0 --vbr-quality <x> --preset quality --weightp --bref-mode each --lookahead 32 -c hevc --level 6 --output-depth 10 -b 3
qsv H.264--la-icq <x> --la-depth 60 -u 1
qsv HEVC--icq <x> -u 1 -c hevc
qsv HEVC 10bit--icq <x> -u 1 -c hevc --profile main10 --output-depth 10
vce H.264--cqp <x>:<x>+2:<x>+5 -u slow
--vbr <x> -u slow
vce HEVC--cqp <x>:<x>+2:> -u slow -c hevc
--vbr <x> -u slow -c hevc
結果
縦軸SSIM:Allが高いほど画質がよく、横軸ビットレートが小さいほど圧縮できているので、左上にいればいるほど良いことになる。
全データ (クリックで拡大)
まあ、正直線が多すぎてよくわかんない…。まあ、この数のデータとるの大変だったのが伝われば…というグラフ。
で、少しずつ見ていく。
まず、CPUエンコの比較。なお、--tune ssimを入れてないので、さらにssim的には改善の余地があることに注意。
特に低ビットレートではx265のほうが優位。ただまあ、もちろんその分エンコ時間がかかる。
やはりSSIM比較では10bitは明確に優位。正直もう8bitでバンディングとか気になるなら、HEVCの10bit使っとけばいいのではと思う。
本題のQSVの世代別比較。
HSW…Haswell
KBL…Kabylakeだが、CoffelakeもCometlakeも同じ。
ICL…Icelake
IcelakeのH.264はKabylakeのH.264とほぼ重なっている。つまり、IcelakeではH.264については手が入っていないみたい。
一方、HEVCは圧倒的だ…！もうなんか全く違うものが入っているとしか思えない。Kabylakeが2017年に登場してから3年もたっているとはいえ、大きな飛躍だと思う。(正直なんか間違ったんじゃないかと測りなおしたりした)
Icelakeでのpreset fast/normal/slowの比較。(さっきのグラフはslow)
HEVCのほうは、normalとslowの差がやや大きめ。H.264のほうはfastとnormalの差が大きめ。
一応ドライバ更新とかもしたので、NVENCのほうも再確認。てはいえ、前回(2018.11)とほぼ変わっていない。やはりBフレームが入ったHEVCは強い。
QSV(Icelake)、NVENC(Turing)、VCE(Navi)の比較。
TuringのNVENCはKabylakeのQSVを超えるなかなかのものだったが、Icelakeはそれをもう一度ひっくり返した感じ。まあ、QSVのHEVCエンコードはNVENCのように爆速という感じではなくそれなりに時間がかかるし、QSVの実装はエンコード用の専用回路(ASIC)とGPUの演算器の併用方式なのに対して、NVENCとVCEは専用回路(ASIC)のみでの実装なので、QSVのほうが画質面では有利というのはあると思う。
VCEはまあ…。固定品質系のレート制御がない時点でこの比較は不利なのだが、それにしても…。うーん。
最後にx264/x265とQSV(Icelake)の比較。
うーん、びっくりだ。もちろんx265で"--ssim"等のオプションを入れれば、x265のssimは上がるはず、というのを割り引いてもなかなかの結果だと思う(そもそもこんなに近くなると思ってなかったので、わざわざ普通やらない--tune ssimをx265エンコ時に入れるという発想がなかった)
というわけでざっくり画質比較をしてみた。なかなか出てこなかったIntel 10nmのCPU/GPUだけど、そのぶん(?)しっかり進化してKabylake世代からは大きく飛躍していた。いわゆるHWエンコとしてはなかなかの高画質(高圧縮)になっていると思う。
一方で、i5 1035G7に搭載されている64EUをぶん回しても、1080pのHEVC 10bitエンコ速度は50fps弱という感じで、エンコードがそこまで速いわけではない。なので、i5 1035G1とかのよりEU数が少ないGPUだともしかすると速度がもっと落ちてしまうかもしれない。
