Some time ago I had posted an Quick Sync encoding test but that was done using just one 4k sample and only via VAAPI; today I am posting a more complete quality test, done using VAAPI and QSV, via
ffmpeg and
Hand Brake,
Test system: i3 7100, 8GB DDR4 2400, 32GB Optane SSD used as swap; Ubuntu 18.10 with all the updates; latest ffmpeg and Hand Brake built from source with VAAPI and QSV support enabled for ffmpeg and QSV enabled for Hand Brake.
Test Sources, the 1080p 8bit y4m variants of the files found here:
http://ultravideo.cs.tut.fi/#testsequences
All samples were inputted into Shot Cut and exported as a single Huffy 6.9GB encoded test file.
Command Lines and encoding times:
time ffmpeg -i Source2.mkv -c:v libx264 X264.mp4
3m35.979s
time ffmpeg -vaapi_device /dev/dri/renderD128 -i Source2.mkv -vf 'format=nv12,hwupload' -c:v h264_vaapi -rc_mode 4 -g 250 -bf 4 -refs 4 -quality 1 -qp 23 -coder 1 "VAAPI H264 ICQ QP23.mp4"
1m34.046s
time ffmpeg -vaapi_device /dev/dri/renderD128 -i Source2.mkv -vf 'format=nv12,hwupload' -c:v hevc_vaapi -rc_mode 4 -g 250 -bf 4 -refs 4 -quality 1 -qp 23 -coder 1 "VAAPI H265 ICQ QP23.mp4"
2m16.838s
time ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -i Source2.mkv -vf hwupload=extra_hw_frames=64,format=qsv -c:v h264_qsv -preset 1 -rdo 1 -trellis 3 -look_ahead 1 -look_ahead_depth 40 -extbrc 1 -adaptive_i 1 -adaptive_b 1 -b_strategy 1 -bf 4 -refs 4 -g 250 -b:v 6.2M "QSV H264.mp4"
0m55.478s
time ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -i Source2.mkv -vf hwupload=extra_hw_frames=64,format=qsv -c:v h264_qsv -preset 1 -rdo 1 -trellis 3 -global_quality 30 -look_ahead 1 -look_ahead_depth 40 -adaptive_i 1 -adaptive_b 1 -b_strategy 1 -bf 4 -refs 4 -g 250 "QSV H264 ICQ.mp4"
1m2.936s
time ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -i Source2.mkv -vf hwupload=extra_hw_frames=64,format=qsv -c:v h264_qsv -preset 1 -rdo 1 -global_quality 23 -adaptive_i 1 -adaptive_b 1 -b_strategy 1 -bf 4 -refs 4 -g 250 "QSV HEVC ICQ.mp4"
0m55.463s
time ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -i Source2.mkv -vf hwupload=extra_hw_frames=64,format=qsv -c:v h264_qsv -preset 1 -rdo 1 -extbrc 1 -adaptive_i 1 -adaptive_b 1 -b_strategy 1 -bf 4 -refs 4 -g 250 -b:v 6.2M "QSV HEVC.mp4"
0m56.009s
time ffmpeg -i Source2.mkv -c:v libx265 -preset ultrafast -b:v 6.2M "X265 UF.mp4"
2m35.253s
time ffmpeg -i Source2.mkv -c:v libx265 X265.mp4
6m26.189s
Some thoughts: Quick Sync should not be judged by pure encoding speed, but rather effective throughput. Due to AMD's aggressive pricing, it's hard to make an argument that Quick Sync is the best option for pure encoding speed. If I recall correctly, I bought the i3 7100 for just over $100, a Ryzen 5 1600 (which I also own) has dropped to $80, the 8C/16T 1700X is $150, AMD is rumored to be ready to release a 6C/12T APU for $100 and an 8C/16T APU for under $200. At these prices, it's understandable that one would not be too keen to pay $115 for a Core i3 8100, which replaced the i3 7100 I used for testing.
What Quick Sync offers is low power usage and the ability to encode 5 streams simultaneously at the highest quality setting (TU1) on even a low end cpu, something software based solutions can't match.
Personally, I would wait for Ice Lake before taking the plunge, Kaby Lake quality, as you guys can see, is pretty good, Coffee Lake is supposed to be even better and reports are that Intel is overhauling HEVC encoding, with even higher quality, for Ice Lake.
On top of that is the fact that in 2020 we should start seeing Intel's dGPU hit the shelves, with presumably more advanced hardware encoder, which I am guessing will probably be based on the SVT encoders I have mentioned previously.
Be that as it may, if you have a Kaby Lake or Coffee Lake cpu already, or even Sky Lake, it behooves you to give Quick Sync a look at.