X264 vs Intel QSV on Ubuntu Linux

[sophisticles]

Forward: I don't want anyone thinking that I disappeared from the other thread, even though technically I did. A number of things conspired to keep me away, not the least of which was I ended up going down a rabbit hole trying to get ffmpeg+qsv working on Linux. In the process, I ended up screwing up my Ubuntu 19 install, which wasn't that big a deal, I decided to try Manjaro. With Manjaro I was able to get ffmpeg+vaapi working, which I've done before so I ended up doing a bunch of test encodes, only to decide that I really wanted to get ffmpeg+qsv working, so I nuked that install and instead grabbed a copy of Ubuntu Mate 20.04 LTS, which I was planning on trying anyway.

After some trial and error, I grabbed the latest git for both ffmpeg and x264 and built both of them, after some more tinkering I found I had gotten ffmpeg+qsv working on Linux and I found a very interesting surprise. Starting with Kaby Lake, Quick Sync supported hardware VP8 and VP9 encoding, only on Linux and only via VAAPI. AfterI built the latest ffmpeg source I found that ffmpeg listed the following QSV encoders:

V..... h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264)
V..... hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc)
V..... mjpeg_qsv MJPEG (Intel Quick Sync Video acceleration) (codec mjpeg)
V..... mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video)
V..... vp9_qsv VP9 video (Intel Quick Sync Video acceleration) (codec vp9)

It seems Intel has expanded vp9 encoding to QSV, meaning we may see it on Windows soon and perhaps even Handbrake. Unfortunately I can't get vp9_qsv to work, because all the sample command line examples for vp9 encoding are for VAAPI, which uses a different syntax than QSV.

Additionally, there is an ongoing rate control issue related to ffmpeg, I know it's related to ffmpeg because using QSV via Handbrake does not result the same ignoring of bit rate settings. This only applies to H264, as HEVC rate control seems to be all over the place no matter what app I try it with and even settings things like max and min rate doesn't make it behave. I don't know how it is on Windows since I never tried.

A word about sources, how I prepared them and so on. I went here:

https://www.blackmagicdesign.com/products/blackmagicpocketcinemacamera/workflow

And downloaded all the files that are in ProRes format. ffmpeg, x264 and Handbrake were all built from the latest git, the 3840x1600 samples were cropped using Handbrake to 3840x1600 and the 6144x3456 were cropped and resized to 3840x1600, in both cases they were then exported as x264 lossless encodes. The reason for the resize is that Intel encoder supports a max of 4096x2160p60 for encoding, the latest ones support up to 5K decoding but not through HDMI.

Even though it galls me to set one encoder as the baseline, all x264 encodes were done using preset medium, profile high, CRF 24, and tune film; the Intel H264 encodes were done with ICQ (roughly analogous to CRF), macroblock based bit rate control (MBBRC, roughly analogous to mb-tree), trellis, RDO (rate distortion optimization) and I did multiple encodes using different ICQ values until I found the value that most closely reached the bit rate that CRF 24 used.

Notes:

A) I would not use CRF 24 for my own personal encodes. As much as I hate CRF, if I were to use it, I would use CRF 16 and then set a maxrate of whatever I wanted the upper limit to be.

B) There is some quality left on the table with the Intel encoder. For some odd reason I can't seem to get -extbrc (extended bit rate control) to work, which is odd because I have managed to get it to work in previous tries and it is one of the settings that I have found I can actually see the quality improvement.

C) It's a shame to see the Intel encoder hamstrung on Linux the way it is. Getting it to work via ffmpeg+qsv is very patience trying; on top of that the problems with rate control when using bit rate based encoding will turn off most users.

time ffmpeg -i "BMPCC_Real Estate.mkv" -c:v libx264 -pix_fmt yuv420p -preset medium -profile high -crf 24 -tune film -an "/media/XX/One TB NVMe/BMPCC_Real Estate.mkv" 5m20.683s

time ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -i "BMPCC_Real Estate.mkv" -vf hwupload=extra_hw_frames=64,format=qsv -c:v h264_qsv -preset veryslow -profile:v high -global_quality 24 -g 250 -bf 3 -refs 3 -rdo 1 -mbbrc 1 -trellis 3 -an "/media/XX/One TB NVMe/BMPCC_Real Estate.mkv QSV ICQ RDO MBBRC Trellis.mkv" 1m22.886s

time ffmpeg -i "BMPCC6K_Indie_Film.mkv" -c:v libx264 -pix_fmt yuv420p -preset medium -profile high -crf 24 -tune film -an "/media/XX/One TB NVMe/BMPCC6K_Indie_Film.mkv" 5m46.231s

time ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -i "BMPCC6K_Indie_Film.mkv" -vf hwupload=extra_hw_frames=64,format=qsv -c:v h264_qsv -preset veryslow -profile:v high -global_quality 26 -g 250 -bf 3 -refs 3 -rdo 1 -mbbrc 1 -trellis 3 -an "/media/XX/One TB NVMe/BMPCC6K_Indie_Film.mkv QSV ICQ RDO MBBRC Trellis.mkv" 0m50.420s

time ffmpeg -i "BMPCC6K_Mountain Bike.mkv" -c:v libx264 -pix_fmt yuv420p -preset medium -profile high -crf 24 -tune film -an "/media/XX/One TB NVMe/BMPCC6K_Mountain Bike.mkv" 7m32.407s

time ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -i "BMPCC6K_Mountain Bike.mkv" -vf hwupload=extra_hw_frames=64,format=qsv -c:v h264_qsv -preset veryslow -profile:v high -global_quality 24 -g 250 -bf 3 -refs 3 -rdo 1 -mbbrc 1 -trellis 3 -an "/media/XX/One TB NVMe/BMPCC6K_Mountain Bike.mkv QSV ICQ RDO MBBRC Trellis.mkv" 1m2.808s

time ffmpeg -i "BMPCC6K_Running Action.mkv" -c:v libx264 -pix_fmt yuv420p -preset medium -profile high -crf 24 -tune film -an "/media/XX/One TB NVMe/BMPCC6K_Running Action.mkv" 8m12.186s

time ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -i "BMPCC6K_Running Action.mkv" -vf hwupload=extra_hw_frames=64,format=qsv -c:v h264_qsv -preset veryslow -profile:v high -global_quality 24 -g 250 -bf 3 -refs 3 -rdo 1 -mbbrc 1 -trellis 3 -an "/media/XX/One TB NVMe/BMPCC6K_Running Action.mkv QSV ICQ RDO MBBRC Trellis.mkv 2m46.900s

There are 10 more samples available, 5 of each, I will upload if there is any interest. One last thing, I would like to keep the comments in this thread strictly about this test, if anyone wants to continue the discussion started in the other thread, I will return to that one and we can continue, but I'd like to have this one as clean as possible, so it can be used as a reference in case anyone happens to stumble upon this from google.

[hello_hello]

I'm guessing the average user ain't going to go through all that hassle to make another encoder work when they could just use x264.

Once again your obsession with UHD has you using resolutions the codecs you're comparing weren't designed for.

Once again you could have used 2 pass for x264 to match the bitrate of the other encodes, given 2 pass and CRF encode the video much the same way. At least the comparisons would have been between identical bitrates.

Once again you chose to use the medium speed preset for x264 when you could have used a slower preset, given the original discussion was about encoding quality, not speed. Hardware encoding is much faster. Nobody has ever argued about that. For some, the huge speed increase may be worth sacrificing a bit of quality for.

You keep saying you hate CRF, yet every time you make a ridiculous claim about it you ignore the replies. Where was it proven CRF is simply ABR encoding with QP shoe-horned in, or however you imagined that works?
I'm still wanting to know why it's okay for a 2 pass encode to decide how to distribute the bits for maximum visual quality, but not a CRF encode, when it's an accepted fact that CRF and 2 pass encoding, at exactly the same bitrate, using exactly the same encoder settings, will result in virtually identical encoding quality.

What it is about ICQ that allows you to accept it so easily when you acknowledged it's roughly analogous to CRF? In what way is ICQ better?

Anyway.... I only downloaded the running action encodes. These screenshots are only part of the frame so I wouldn't have to resize down due to your obsession with comparing codecs at resolutions they weren't designed for, yet you still managed to show x264 is better, at least where there's movement.

Where there's less movement, some differences could possibly be attributed more to encoding differences than quality as such, but any real test would include the source files in order to compare encoder "accuracy" where differences don't necessarily translate directly to visual quality.

If you'd prefer to answer any of the above questions in the other thread, I've already asked many of them there, so I'd be happy to delete them from this post when you do.

Hover over the thumbnails for a tooltip to show which screenshot was taken from which encode, or check the file names if you open them in a new tab.

Ed: Whoops I accidentally labelled the QSV encodes as QSC. In my defence, C and V are next to each other on the keyboard.

[KarMa]

Besides a general drop in details in bright areas, I'm repeatedly seeing a larger drop in quality in dark areas. The black intros look fine until the black slowly transitions to the start of the video. I don't even have a 4K monitor and can still see the quality drop.

Despite mostly buying AMD, I have two working Intel computers with QS. Just yesterday I used QS H.264 to record a RTL-SDR video on a i3 laptop, saving battery life in the process vs x264. Without QS I doubt my laptop would be able powerful enough to do both at the same time (software defined radio can be demanding). Did the video provide the best compression efficiency for H.264, no but it's still better than not getting the video at all. Same with hardware decoding on my AMD GPU, it can decode something like 500fps of 1080i video (nominal 12Mbit) which is amazing until it hit any minor error/corruption in the stream which causes the decoder to over react with worse artifacts and potentially needing to restart the player. While software decoding tends to encounter errors in streams with grace, better visual handling of errors, and no real need to restart the decoding process and it just tanks the error and keeps moving. Obviously software uses more power and cpu resources. I've not really seen anything that shakes up this normal dynamic.

[sophisticles]

I'm guessing the average user ain't going to go through all that hassle to make another encoder work when they could just use x264.

You are correct, that is my assessment also. Then again, considering that Linux has less than 1% of the desktop according to a recent STEAM survey, I doubt the average user would use Linux at all.

But even on Windows, you don't see applications that expose all of QSV's options and it's a major reason I have said time and again that it's almost as if Intel does not want QSV used on the desktop, which makes sense, as it has the potential to leach sales from higher core count more expensive cpu's they sell, if they released a cheap $100 cpu that can beat a $500+ cpu in video encoding.

Of course, it also seems that with AMD's continued dominance in the manufacturing and core count front, Intel with it's new cpu's has decided to leach sales from both of them.

Once again you're letting your obsession with UHD use resolutions for comparing codecs that weren't designed with UHD in mind.

You and I have something in common, neither one of us has any idea what you are talking about:

https://en.wikipedia.org/wiki/Advanced_Video_Coding

The AVC spec allows for up to 8K video, so...

Once again you chose to use the medium speed preset for x264 when you could have used a slower preset, given the original discussion was about encoding quality, not speed.

Once again you choose to ignore that I am actually cheating in x264's favor with the settings I used. X264 used to default to medium+crf 18+profile main, it was refactored a while ago and now defaults to fast+crf 23+profile main. Medium used to be the point at which x264 enable all the psy optimizations, fast used to be sub me 5, no aq, no psy, and hex; when the developer's refactored the presets they made fast use sub me 6, which is what the old medium used to use and medium now uses sub me 7, which is what the old slow used to use.

Further, profile high, according the developers turns on 8x8dct, which is said to have the single biggest impact of any setting for quality. It also allows the use of p8x8 partitions, which likewise have a significant impact on quality:

https://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping

You keep saying you hate CRF, yet every time you make a ridiculous claim about it you ignore the replies. Where was it proven CRF is simply ABR encoding with QP shoe-horned in, or however you imagined that works?

This was actually pointed out by Selur, the developer of Hybrid, in another thread. I was pointing out the absurdity of claiming that CRF uses the same algorithm as 2 pass, because by definition an algorithm is a sequence of steps you follow and if 2 pass is analyzing the video in the first pass, which is does and then using that log file to encode the second pass, there's no way that CRF is using the same algorithm, it just doesn't make sense. At some point Selr offered that back in the day, CRF was actually called either ABR or AVBR, don't remember which, at which point I went dumpster diving and found code that showed that CRf was really QP, that fluctuates. And i recall Selur saying something to the effect, "of course CRf depends on QP".

I'll see if I can dig up that old thread but in the meantime check this out:

https://slhck.info/video/2017/02/24/crf-guide.html

Constant Rate Factor is a little more sophisticated than that. It will compress different frames by different amounts, thus varying the QP as necessary to maintain a certain level of perceived quality. It does this by taking motion into account. A constant QP encode at QP=18 will stay at QP=18 regardless of the frame (there is some small offset for different frame types, but it is negligible here). Constant Rate Factor at CRF=18 will increase the QP to, say, 20, for high motion frames (compressing them more) and lower it down to 16 for low motion parts of the sequence. This will essentially change the bitrate allocation over time.

There you have it, CRF is nothing more than an "intelligent" QP, which in theory tries to guess how a content consumer will perceive quality by lowering QP where it thinks you are more likely to notice it and raising it where it thinks you won't notice it.

Of course, all the complaints that people have lodged against x264 over the years, such as it's behavior in dark areas, it's behavior with fast moving scenes, etc, all stem from this ridiculous algorithm. All the kludges that were developed to compensate for this ridiculous mode, such as mb-tree and psy-rd could have been avoided if they simply stuck with QP and called it a day. But they had to be cute, they had to be clever, they had to try and predict how the eyes of 7 billion different people on the face the planet would perceive quality and then they tried to model and use that prediction with a few lines of code.

And the lemmings fell for it.

2 pass and CRF encode the video the same way. CRF aims to provide a similar visual quality to an equivalent CQ encode using less bits. 2 pass does the same, but it has to aim for an average bitrate instead. I'm still wanting to know why it's okay for a 2 pass encode to decide how to distribute the bits for maximum visual quality, but not for a CRF encode, when it's a pretty much an accepted fact that CRF and 2 pass encoding at exactly the same bitrate, using exactly the same encoder settings, will result in virtually identical encoding quality.

I don't think that it's OK "for a 2 pass encode to decide how to distribute the bits for maximum visual quality", for the same reasons I don't think it's OK for CRF to try and do the same thing. I disagree with the basic premise behind x264's algorithms, that the developers can somehow predict how the human eye will perceive quality. One of the 2 main developers. one was a college kid in his freshman year that had no background in video, that taught himself about video compression before he even had a B.S. in Comp Sci had the arrogance to think he could predict how all human beings will perceive quality.

If it had been a team composed of a psychologist, ophthalmologist, bio-physicist, videographer and an experience programmer, I could take an algorithm they developed more seriously.

But some kid barely in his 20's, barely into an undergrad comp sci degree and that had no experience with video? The results speak for themselves. CRF is a hot mess.

What it is about ICQ that allows you to accept it so easily when you acknowledged it's roughly analogous to CRF? In what way is ICQ better?

It's not, I don't like anything that attempts to predict human perception. I am a firm believer in "beauty is in the eye of the beholder".

If I ask you who is the absolute most beautiful actress of all time, is there a right or wrong answer?

If I ask you which is the coolest car ever built, is there a right or wrong answer?

As a general principal, I do not like anything that tries to play tricks with a person's mind; I remember watching a documentary on the science of supermarkets and all the mind tricks they play on consumers. Floor plans are designed by engineers working with psychologists, in order to ensure you spend maximum time in the supermarket and colors and decor are chosen that is known to put people in the maximum spending mood. A common trick is in the way they price their items. A study was done that found that if 5 items in a supermarket were 50 cents cheaper than in another supermarket, then the entire supermarket was judged by the participants in the study to be cheaper than a competing supermarket. Those 5 items, milk, eggs, bacon, toilet paper and i forget the 5th, I think it was dish soap, if these 5 items were on sale, every person in the study picked that supermarket as the preferred place to shop, even if all the other items they were going to buy that day were more expensive than the other supermarket and they would choose to go to that supermarket first.

Similarly, in real estate, there are people that are called "stagers", their job is to "stage" a house or apartment for sale or lease. What they do is use known psychological tricks to make a house more appealing to a prospective customer. Some common tricks include painting the ceiling and wall opposite a door or entrance with a high quality paint while painting the wall adjacent to the door with a cheaper paint.

Similarly, it's been shown that if you simply remove any carpets and polish the wooden floor, a house is judged to be of higher quality and more desirable than if it has carpets. You can arrange the furniture to make a room look bigger and a common trick to put down a area rug, people have trouble judging size without a frame of reference, so by putting an are rug smaller than the room, it tricks the mind into believing the room and consequently the house is bigger than it actually is. They did a study, where prospective buyers were told ahead of time the square footage of the house they were to be shown and both house had similar layouts, if the house used the tricks outlined above, it was judged to be bigger and a better value, even though the buyers had the hard numbers in front ahead of time.

I don't like anything that tries to trick my perception, because ultimately it's just that, a trick.

I would much rather use QP and I am on record having said that I prefer to use QP being the same value for I, P and B frames.

Anyway.... I only downloaded the running action encodes. These screenshots are only part of the frame so I don't need to resize down due to your obsession with comparing codecs at resolutions they weren't designed for, yet you still managed to show x264 is better, at least where there's movement.

And you have an obsession with ignoring the official specs, again AVC can go all the way to 8K, but for you, I will d a bunch of 1080p and 720p tests.

Where there's less movement any differences could possibly be attributed more to encoding differences than quality as such, but any real test would include the source files in order to compare encoder "accuracy" where differences don't necessarily translate directly to visual quality.

And the day that video help allows the attaching of 3-5 GB files, I will be more than happy to include the source files. But I did tell you how I created them and you are free to reproduce the source files.

[hello_hello]

Once again you're letting your obsession with UHD use resolutions for comparing codecs that weren't designed with UHD in mind.

You and I have something in common, neither one of us has any idea what you are talking about:

https://en.wikipedia.org/wiki/Advanced_Video_Coding

The AVC spec allows for up to 8K video, so...

"Allows" and "designed for" aren't the same thing.

Once again you chose to use the medium speed preset for x264 when you could have used a slower preset, given the original discussion was about encoding quality, not speed.

Once again you choose to ignore that I am actually cheating in x264's favor with the settings I used. X264 used to default to medium+crf 18+profile main, it was refactored a while ago and now defaults to fast+crf 23+profile main. Medium used to be the point at which x264 enable all the psy optimizations, fast used to be sub me 5, no aq, no psy, and hex; when the developer's refactored the presets they made fast use sub me 6, which is what the old medium used to use and medium now uses sub me 7, which is what the old slow used to use.

I don't know what any of that has to do with it. What the presets may have been and how they've changed over time has nothing to do with the fact you could have used slower x264 settings because it was supposed to be a quality comparison.

The profile used probably changes according to resolution, if no profile is specified, and possibly even according to the specified speed preset, but I just ran 3 encodes at 688x540 with the fast preset, the slow preset, and without specifying a preset (medium) and the resulting encodes were all High Profile, Level 3.

This was actually pointed out by Selur, the developer of Hybrid, in another thread. I was pointing out the absurdity of claiming that CRF uses the same algorithm as 2 pass, because by definition an algorithm is a sequence of steps you follow and if 2 pass is analyzing the video in the first pass, which is does and then using that log file to encode the second pass, there's no way that CRF is using the same algorithm, it just doesn't make sense. At some point Selr offered that back in the day, CRF was actually called either ABR or AVBR, don't remember which, at which point I went dumpster diving and found code that showed that CRf was really QP, that fluctuates. And i recall Selur saying something to the effect, "of course CRf depends on QP".

Using that logic you could say the encoder uses a different algorithm for every encode, given no two videos are the same and therefore the sequence of steps would change.

There you have it, CRF is nothing more than an "intelligent" QP, which in theory tries to guess how a content consumer will perceive quality by lowering QP where it thinks you are more likely to notice it and raising it where it thinks you won't notice it.

I guess it works pretty well, given you're yet to produce a single encode from another encoder with the same visual quality at the same bitrate.

Of course, all the complaints that people have lodged against x264 over the years, such as it's behavior in dark areas, it's behavior with fast moving scenes, etc, all stem from this ridiculous algorithm. All the kludges that were developed to compensate for this ridiculous mode, such as mb-tree and psy-rd could have been avoided if they simply stuck with QP and called it a day. But they had to be cute, they had to be clever, they had to try and predict how the eyes of 7 billion different people on the face the planet would perceive quality and then they tried to model and use that prediction with a few lines of code.

And yet it does better than the encodes you uploaded in dark areas and fast moving scenes.
I've never had a much of a problem with either, as I always use fairly high quality CRF values. I've uploaded samples on the past to show you x264 encodes all the detail in dark, detailed scenes. The problem is when dark areas aren't detailed, and the result is blocks or banding in a fairly static scene, it tends be more noticeable than in lighter areas. A CQ encode wouldn't be any different. At the same bitrate as CRF, I'd be surprised if it wasn't worse.

I don't think that it's OK "for a 2 pass encode to decide how to distribute the bits for maximum visual quality", for the same reasons I don't think it's OK for CRF to try and do the same thing.

I guess at low bitrates, you'd prefer for the entire encode to look average, rather than reduce the quality where you're less likely to notice it and increase it where you can.

If it had been a team composed of a psychologist, ophthalmologist, bio-physicist, videographer and an experience programmer, I could take an algorithm they developed more seriously.

I would've thought it'd be more logical to base how seriously you take it on the encoding quality rather than personal feelings.

And you have an obsession with ignoring the official specs, again AVC can go all the way to 8K, but for you, I will d a bunch of 1080p and 720p tests.

Why bother? Do you imagine if you do the same thing often enough, you'll eventually get a different result?

[forart.it]

Hi everyone, I'm investigating how to "correctly" achieve 2-pass HEVC 10bit with FFMPEG @ QSV.

Can someone share commandline ?

Thanks in advance !

[sophisticles]

QSV does not support 2-pass encoding, no consumer hardware encoder does. NVENC has a "2pass" mode that tries to mimic some of the benefits of 2pass but it's 1pass and QSV has AVBR, average variable bitrate that some applications of the same benefits as 2pass.

WDV produces the best quality when used with CQP mode, with custom QPI values, but that can be a pain.

Try just using the minrate and maxrate switching and nothing else.

[emcodem]

IHMO, today for AVC encoding, whenever you think about 2-pass, it is kind of ridiculous to consider qsv or nvenc as you aim low bitrate and quality.
If you care and qualiy at low bitrate, you defintely encode with x264. QSV, NVENC and co are still designed for live streaming the current desktop, e.g. gaming.
All existing hardware accelerated encoding from CPU and the encoders on Graphics Cards are targeting only the live streaming market, so they exlude the "offline encoding" usecase by nature.
Besides that, if you care about quality and bandwidth, speedwise these days a 500$ CPU will always outperform a Graphics card's inbiult chip by about 2x factor. Not to mention that you will never get the Hardware encoders to deliver "extremely good quality at extremely low bitrates"

Even Using newest generation Volta NVENC chips, the encoding may occur "fast" to you but the resulting file is visibly a lot worse than if you would have encoded the same stuff using x264 (CPU only).

Sidenote: besides live streaming for gamers, GPU's are these days mostly used for "filtering" which is sometimes extremely useful but mostly also extremely hard to set up.

[sophisticles]

So many things wrong with what @emcodem said.

IHMO, today for AVC encoding, whenever you think about 2-pass, it is kind of ridiculous to consider qsv or nvenc as you aim low bitrate and quality.

It's ridiculous to use the words "low bitrate" and "quality" in the same sentence unless you mean "low quality".

There's an old saying that you can have it done fast, done cheap or done good, pick any 2.

I don't care what encoder you use, "low bitrate" and "good quality" do not go hand in hand.

If you care and quality at low bitrate, you definitely encode with x264. QSV, NVENC and co are still designed for live streaming the current desktop, e.g. gaming.

No, if you want the best quality at the lowest possible bitrate you use SVT-AV1.

All existing hardware accelerated encoding from CPU and the encoders on Graphics Cards are targeting only the live streaming market, so they exclude the "offline encoding" use case by nature.

Not true at all and this tells me you have never used a hardware based encoder. They specifically have an offline/archival mode.

Besides that, if you care about quality and bandwidth, speed wise these days a 500$ CPU will always outperform a Graphics card's inbuilt chip by about 2x factor. Not to mention that you will never get the Hardware encoders to deliver "extremely good quality at extremely low bitrates"

ROTFLMAO.

You will never get any encoder, hardware or software to deliver "extremely good quality at extremely low bitrates", unless you have cataracts.

Also, no $500 cpu is going to encode 2x faster than a video cards built in chip, not even close and in fact most chips will beat the $500 cpu by a considerable margin.

Furthermore, the price comparison is misleading, that $500 cpu is going to need a motherboard, ram, psu and a video card anyway, unless you used the igpu.

And the built in chip will use a lot less electricity.

Even Using newest generation Volta NVENC chips, the encoding may occur "fast" to you but the resulting file is visibly a lot worse than if you would have encoded the same stuff using x264 (CPU only).

Fell free to run a few tests and post a comparison.

Side note: besides live streaming for gamers, GPU's are these days mostly used for "filtering" which is sometimes extremely useful but mostly also extremely hard to set up.

There's nothing "extremely hard to set up" on the end users side for gpu filtering.

On the application side, I don't know how hard it is. ShotCut had gpu powered filters for a while, but the developer(s) first hid the option "due to stability issues", even though I never had a problem with them and then they seem to have removed them completely.

AviDemux supports some OpenGL filters and Vegas has gpu filters, from 16-bit int to 64-bit double accuracy.

Premiere, Resolve, Redcine, the also feature gpu powered filters.

[emcodem]

ROTFLMAO is not something you should ever write except maybe someone intended to make a joke. You might want to know that i ran lots of tests thats why i post my experience here But i drop off now because of the ROTFLMAO attitude.

[KarMa]

I don't care what encoder you use, "low bitrate" and "good quality" do not go hand in hand.

If you care and quality at low bitrate, you definitely encode with x264. QSV, NVENC and co are still designed for live streaming the current desktop, e.g. gaming.

No, if you want the best quality at the lowest possible bitrate you use SVT-AV1.

....

[sophisticles]

I don't care what encoder you use, "low bitrate" and "good quality" do not go hand in hand.

If you care and quality at low bitrate, you definitely encode with x264. QSV, NVENC and co are still designed for live streaming the current desktop, e.g. gaming.

No, if you want the best quality at the lowest possible bitrate you use SVT-AV1.

....

Is there a point you plan on making sometime in the near future?