- 2.1.1OBS V23 - 19th February 2019
- 4.2How it works
- 4.4What to expect
- 5.3Conclusions for x264
- 6.3Conclusions for x265
- 7.3Conclusions for QuickSync
- 8NVENC part 1
- 8.3Special note for NVENC Part 1
- 8.4Conclusions for NVENC Part 1
- 8.4.2Decisions decisions...
- 8.4.3Final thoughts on Maxwell and Pascal H.264 AVC
- 9NVENC Part 2
- 9.3Conclusions for NVENC Part 2
- 9.3.1H.264 AVC and live streaming
- 9.3.2H.265 HEVC and offline encoding
- 10.3Conclusions for VP9
- 11.3Conclusions for AV1
- 12Final thoughts
Update 4th march 2019 – See this post for some additional data on QuickSync. There’s a “veryslow” preset that wasn’t tested in this article that I have tested since. If you would like more, please comment below.
In 2011 Intel released QuickSync, a hardware transcoder chipset built directly into Sandy Bridge CPUs and found in consumer units ever since. Because software encoding could be quite slow, Intel gave us the ability to do it considerably faster. The quality sacrifice was huge, so it isn’t great for archiving. However, for real-time communication and playback it saved a lot of CPU usage and power consumption.
These days QuickSync can also encode into H.265 and accelerate VP9. Unfortunately the only way I have achieved hardware accelerated VP9 encoding is through VAAPI on Linux. Custom VAAPI encoding is beyond the scope of this article and is better left to professionals and hardcore enthusiasts. QuickSync Version 5 on Skylake was the first to implement H.265/HEVC encoding. Version 6 supports 10-bit HEVC encoding and is accessible in Handbrake and FFMPEG.
The good news really is all about the convenience. H.264 AVC and H.265 HEVC encoding is easy as pie with QuickSync. Since it’s built into so many CPUs, it’s available to most people by enabling the integrated graphics in their BIOS.
I’m testing with QuickSync Version 6 on Coffee Lake with a stock 8086k. 2019 should see the release of QuickSync Version 7 on Ice Lake and Tiger Lake. Ice Lake is planning a massive increase to it’s graphics processing capability over Coffee Lake. QSV Version 7 has confirmed its HEVC encoder will be an all-new and improved design. However, none was available for me at the time of testing.
Things to note for QuickSync:
- QSV in H.264 always beats Kepler NVENC and x264 Fast, Faster and VeryFast.
- At 4Mbps QSV H.264 is worse than x264 Medium and Slow, as well as Maxwell and Pascal NVENC. But at 6Mbps and 8Mbps QuickSync wins.
- During bandwidth starvation at 4Mbps, QSV HEVC/H.265 beats Turing NVENC AVC/H.264. But at 6 and 8 Mbps Turing AVC/H.264 wins.
- During bandwidth abundance at 8Mbps, QSV’s own AVC/H.264 beats the HEVC/H.265 version.
- The above two points show that QuickSync’s HEVC/H.265 implementation manages well during bandwidth starvation. However it is limited by it’s hardware and can’t keep up the compression advantage during bandwidth abundance.
Conclusions for QuickSync
QuickSync’s H.264 encoding at high bitrates performs better than the NVENC implementation in Kepler, Maxwell and Pascal. For recording footage in real-time to hard disk for editing later, this is the way to go. Turing is the only hardware encoder that beats QuickSync H.264 during bandwidth abundance.
If you have a fantastic CPU and very limited bandwidth, x264 is better than QuickSync H.264/AVC.
There is currently no reason to use QuickSync H.265/HEVC encoding if you have another hardware or software option available. The Ice Lake and Tiger Lake version promises to change this, but it remains to be seen.