It's been a while since the last time I posted a QSV test and today I have something a bit different. As anyone that has been around the video encoding game knows, one of the common responses offered to a person that asks about hardware encoders is "x264+ultrafast+i7 is both faster and higher quality than" <insert hardware encoder here>.
Well, I'm here to prove that this is not true, at least not completely. With the test system I used, i3 7100 (2C/4T), 8GB DDR4-2400, 32GB Optane SSD for swap, separate SSD's for read/write, x264+ultrafast was a tiny bit faster than qsv+quality setting in Handbrake, built from source on Manjaro Mate, with all the updates. This speed advantage held for all 4k test encodes I did, typically 2-3fps faster. Quality wise however, QSV HEVC easily beat x264+ultrafast. Adding 10bit to the mix, greatly increased the quality of the encodes in both their cases.
I have run hundreds of test encodes, using source files from various sources, here are some test encodes.
Some notes, I have read that Netflix uses 15MB/s for their 4k offerings, frankly they must be using some crazy filtering and industrial strength encoders because in my test 15MB/s is barely watchable with the Netflix samples available on Xiph Derf's, in fact setting x264 to use the defaults CRF23 and medium preset results in about 29MB/s, so the claimed 15MB/s is about half what x264 "thinks" should be used with the default settings.
More considerations, if you are using Y4M or similar sources, it behooves you to get the fastest read drive you can, because I/O is a massive bottleneck when working with these types of sources. Similarly, if you are using jpeg2000 muxed in a MXF or ProRes Lossless, you need the fastest cpu you can afford with QSV because decoding is a huge bottleneck and QSV does not have hardware decode acceleration for these formats. QSV also has a maximum resolution support of 4k DCI, so if you plan on using an AVC source that's bigger than 4k, then you are still decoding on the cpu.
Further, since Handbrake does not support hardware filtering or decoding at all, no matter what resolution the source is, if you use HB, then the decoding is done on the cpu, so again, buy the fastest cpu you can afford or use ffmpeg directly which supports hardware decoding and filtering via QSV.
Hope someone finds these tests useful.
+ Reply to Thread
Results 1 to 8 of 8
So x264+ultrafast 10bit is worse that QSV HEVC 10bit?
So it requires a GPU HEVC encoder to beat the x264 AVC encoder in its least-efforts settings. Fine. I can afford more efforts, though. No need for a top-speed scenario for me, personally.
At least, thanks for your efforts to narrow this topic further.
Get your act together.
I believe this is the link, though I can't verify it at the moment because of my firm's firewall. Just type Xiph Derf into google and you will see the sources. These are provided by Net Flix themselves in Y4M format, not previously compressed, as test samples, I would think tat most members of this forum were aware of their existence.
Before you comment, get your act together, this is a valid test, Net Flix has made available nearly 500GB of test sources, and I ran multiple test encodes with all of them, x264 was used as the reference encoder because that's the one most people recommend for archival and the 15MB/s bit ratewas used because that's what Net Flix supposedly uses for their 4k content, I do not know this for a fact since I do not have a Net Flix account but that is what I have seen reported.
The artifacts that you see are not in the source, they are the result of x264+ultrafast poor encoding at that bit rate, all test encodes were done using 2 pass (except for the CRF, obviously) and the QSV are not the highest quality possible because Handbrakes "quality" setting for QSV chooses TU2, not TU1 (this is confirmed by diving into the code).
At 30MB/s and medium, x264's speed tanks, making QSV much faster and with QSV you can encode 5 stream simultaneously at full speed, at the highest quality setting, assuming you have the necessary I/O bandwidth, decoding speed and ram (Handbrake on Manjaro uses between 3-4 GB of ram per encode for 4k).
The main benefit of QSV, other than the fact that with 10 BIT HEVC it's basically untouchable in terms of quality per speed, is the fact that you use less power than a pure software encoder and in theory at least, a casual video enthusiast that needs to encode content on a semi-regular basis, can do so cheaper than having to spend big bucks on a high end cpu and cooling solution.
Or if someone has a laptop with a Skylake or better, they can put it to work encoding video while freeing up their main system.
I doubt that many people with ultra lowend CPU (2C/4T) will be using software encoder with 4k footage anyway. People doing video editing/compression will most likely use cheap Ryzen 1700 (8C/16T) for that. x264 + medium preset on that CPU is reasonable fast.
I've not looked at the videos but should point out that HEVC has a simple large block advantage. With HEVC supporting up to 64x64 blocks vs 16x16 for H.264. Which is why H264 is naturally disadvantaged above 1080p.