IIRC both x264 and nvenc have multiple profiles for the tradeoff between quality and computing power.

For your comparison, are assuming that the objective is best quality, e.g. that you'd accept 10x the computation even if it gave only a 2% quality improvement?

(I can see how this could make sense, if you're encoding a file once and it will be viewed many times. But I could imagine other situations, e.g. where most files are viewed once or never, and only a few files are very popular.)

Having profiles doesn't really change the fact that even Ampere generation encoding block at slowest profile won't come close to visual quality at same output bitrate to x264s slow+ profiles (and we're not even touching on H.265/AV1 here).

> For your comparison, are assuming that the objective is best quality, e.g. that you'd accept 10x the computation even if it gave only a 2% quality improvement?

The difference is more like 150% encoding time for half the filesize at same SSIM - depending on configuration and video type of course. And that ignores the fact that a server machine with 64-core Threadripper or equivalent can handle parallel encoding of many more videos at massively lower dollar cost than using nvenc. Especially at current GPU prices and GPU power consumption.

There's a reason why all online services are encoding in software (usually with x264 & co.) for mainstream most used profiles (that is, SD/HD, many also for 4K).

It just doesn't make sense from product quality, user experience or financial perspective. It only makes sense if you never check the results of your production.

I agree with your statement mostly. However I think if we're dealing with 1080p displays, hardware-accelerated transcoding produces acceptable video quality for non-4k+ watching. That's just my 2 cents.

Can you explain your point there though? It won't change the fact that you could deliver the same visual quality at significantly reduced bandiwdth cost FOR YOU and for the user. You're making user experience worse (e.g. on less stable 4G/5G links and limited connections), paying more for your egress bandwidth for what? Using an expensive GPU block (with most of its cores idling) to encode slightly faster than a cheaper CPU core will do?

It just doesn't make sense to save a few minutes of encoding time (a one time operation) when that costs you and users money every single time that file is streamed.

> Using an expensive GPU block (with most of its cores idling) to encode slightly faster than a cheaper CPU core will do?

Slightly faster? Sir, I do think you are mistaken.

There are other variables go that into it such as choosing between constant or variable bitrates & variable or constant frame rate, and profiles obviously. There's a crapload of other directives that you can tweak as well.

I see what you mean though, you're right if you have CPU with lot of cores/threads/horsepower then you should use that instead of hardware-accel transcoding. I don't.

I found this recently too - encoding my video using either AMD or Nvidia hardware encoding resulted in poor quality. But what's the reason for this?

Probably because they're optimized for low-latency.

Anyway, by hardware encoders people typically mean dedicated hardware.

In short - on the CPU the encoders spend more time looking for similarities between frames and have access to more frames of history to find repetitions. Finding similarities is where all the compression comes from.

The hardware encoders are designed to be fast (at least realtime), small (in component count) and power efficient so they usually don't have the ability to do extensive searches for similarities in frames to really squeeze out the best compression. Pretty much all of them are also largely fixed in supported operations during encode so you can't really implement better algorithms with software updates on them.

Making them better would mean growing their (sillicon) size which would make the graphics cards more expensive to produce and take space away from actual GPU cores. Most customers don't buy a GeForce for its video encoder. And once you'd grow them enough, you'd get something similar to a CPU anyway.

And this is how we get back full circle - even enterprise "encoder-in-a-box" providers have lately gone from boxes with ASICs in them to essentially seling proprietary servers with normal CPUs and proprietary OS on them. With the current prices of 64-core+ CPUs, it just doesn't make much sense to design ASICs and HW encoding blocks for these types of encodes.

Realtime encoding is, of course, another game.