Can NVENC beat x264+slow preset?

[sophisticles]

YES!!!

The test:

https://media.xiph.org/video/derf/

I downloaded crowd run, ducks take off, in to tree, old town cross and park joy, the 2160p50 version of each loaded them into Shotcut on Manjaro with all the updates, added them to the timeline and exported them as a single file.

I encoded these 5 files into a single 2160p50 @ 25 mb/s using x264 2 pass slow preset and nvenc avc slow preset.

Attached are the encoded clips, the x264 clip took 9min 48secs to encode, and the nvenc took 3min 35sec to encode.

Happy Memorial Day.

[Cumberiron]

YES!!!

The test:

https://media.xiph.org/video/derf/

I downloaded crowd run, ducks take off, in to tree, old town cross and park joy, the 2160p50 version of each loaded them into Shotcut on Manjaro with all the updates, added them to the timeline and exported them as a single file.

I encoded these 5 files into a single 2160p50 @ 25 mb/s using x264 2 pass slow preset and nvenc avc slow preset.

Attached are the encoded clips, the x264 clip took 9min 48secs to encode, and the nvenc took 3min 35sec to encode.

Happy Memorial Day.

Hi!

What type of Nvidia card did you use? And wjy did you use H264 for UHD resolution content?

[jagabo]

sophisticles is obsessed with show the "inferiority" of x264.

[Mr_khyron]

sophisticles is obsessed with show the "inferiority" of x264.

And he is still failing to show how inferior x264 is
from his own files
look at the water and/or the ducks
NVENC is so inferior

[jagabo]

Not to mention the NVENC video has the wrong levels and crushed brights and darks.

[sophisticles]

Not to mention the NVENC video has the wrong levels and crushed brights and darks.

I was wondering who would notice that.

I cheated, I've been playing around with various filters to see what combination of filters coupled with nvenc would result in a visually more pleasant encode than x264+slow.

For the nvenc file, I used the levels filter and set the input to 16-235 and the output to 0-255, to my eyes the effect is superior to a straight encode.

My experience has been that the encoder used is the least important part of a high quality encode, it starts with the quality of the source, how crisp, and clear it is and then the filters used, how it's graded, etc and finally the encoder.

I have always said that the right combination of filters + a fast gpu encoder will beat any straight encode done with any software based encoder.

I feel I have provided sufficient evidence of that.

[KarMa]

I was wondering who would notice that.

Should be pretty obvious with a standard video player if you are not expecting out of range content.

For the nvenc file, I used the levels filter and set the input to 16-235 and the output to 0-255, to my eyes the effect is superior to a straight encode.

I honestly thought this was just a mistake on your part when first looking at the samples but now I don't really understand the logic of intentionally putting one of the encodings out of TV range, when the source is YUV TV Range to start with. And then there's the fact that x264 has no problem encoding videos that are out of range. This just creates new banding along with decoding problems when just about everything is going to expect TV Range (crushing the whites and blacks).

My experience has been that the encoder used is the least important part of a high quality encode,

Yet all you have is encoder info in the title along with my knowledge of your backlog of QS/NVENC/x264/x265 threads.

I have always said that the right combination of filters + a fast gpu encoder will beat any straight encode done with any software based encoder.
I feel I have provided sufficient evidence of that.

This is a first that I'm hearing this but I guess it's good to know where your goal posts are. I usually operate under the assumption that we are simply comparing encoders unless openly stated otherwise. At best, putting in range content out of range isn't going to do anything on decoders expecting it, and at worst it gives a crushing effect that you seem to like but is far from the originally intended video.

[sophisticles]

sophisticles is obsessed with show the "inferiority" of x264.

If I'm "obsessed" with anything it's with Intel's excellent SVT family of encoders. I consider these the future of encoders in general and in fact the x265 project has incorporated SVT-HEVC into their framework:

https://x265.readthedocs.io/en/default/svthevc.html

I think the handwriting is on the wall.

[jagabo]

Of course x264 is now, or soon will be, outdated if you don't need h.264/AVC encoding. The contention was always that x264 was the best h.264 encoder. Not that no newer generation encoders would ever surpass it.

[sophisticles]

Of course x264 is now, or soon will be, outdated if you don't need h.264/AVC encoding. The contention was always that x264 was the best h.264 encoder. Not that no newer generation encoders would ever surpass it.

And I still contend that x264 was the most over-hyped, over-rated avc encoder ever. Apple's H264 was considered the worst encoder available and yet some of the nicest encodes I have ever seen used the Apple encoder.

As I have said countless times, the encoder used was the least important part of the equation, not the most.

[stonesfan99]

What are you trying to prove? NVENC and hardware-based encoding in general is just faster. It does not produce higher quality. NVENC is great for me for producing H265-encoded video because x265 is so ungodly slow.