Comparison of x264, NVENC, Quicksync, VCE

K

kaloc

Member
Quick sync B-frames workaround
Based on what chummy said here I tried a few tests of my own and b-frames do have an effect when set too high. There is currently no way to change them in the obs gui ( as it is hard-coded to 7 in obs-qsv11.c ), so rather than recompile the entire project for one plugin we can do the next best thing, hex edit.

Manual method
Open obs-qsv11.dll in your preferred hex editor and search for this hex value
Code: 
32bit dll -- B807000000668947268B
64bit dll -- B8070000006689472A48

Once located, simply change the 07 at the beginning of the pattern to your desired number of b-frames.

64bit example : set b-frames to 2
B8070000006689472A48 -- > B8020000006689472A48

Then save your changes and replace the original dll with your modified one.

Alternate method
1. Download the windows version of swiss file knife ( current version is sfk186.exe ) and rename it to sfk.exe
2. Copy obs-qsv11.dll ( from obs plugin folder ) and the sfk.exe into their own folder
3. Open a command prompt to this new folder
4. Copy and paste this command into any text editor and make changes if needed ( 2 b-frames in the examples below )
Change the 02 at the beginning of the second pattern ( B8020000006689472A48 ) to the number of b-frames you want.
Code: 
32bit dll
sfk replace obs-qsv11.dll -binary /B807000000668947268B/B802000000668947268B/ -yes

64bit dll
sfk replace obs-qsv11.dll -binary /B8070000006689472A48/B8020000006689472A48/ -yes
5. Paste the command into the command prompt and run it. The text output will say "1 files checked, 1 changed." if successful and the dll is now ready to use.
6. Replace the original dll ( in plugin folder ) with your modified one.
 
Last edited:
Suslik V

Suslik V

Active Member
So, where is new 2 B-frames files for Quick Sync, to compare them to 7?

By the way, when I google for "hex editor", I got HxD application as top result and never heard before about sfk.
 
K

kaloc

Member
Suslik V said:
So, where is new 2 B-frames files for Quick Sync, to compare them to 7?

By the way, when I google for "hex editor", I got HxD application as top result and never heard before about sfk.
Click to expand...

I'm sure someone will post samples with different b-frame settings. My intention is to simply put the information out there for anyone to use. As for hex editors, yes HxD is one of the most popular ones, but sfk is just a command line tool I found that fit the requirements ( a freeware program to search and replace text / binary ).
 
Last edited:
Kenshin9977

Kenshin9977

New Member
That thread is a great reference.
Is it possible for it to be updated ?
  • Preset slower, veryslow and placebo aren't tested.
  • VCE isn't in the current chart within the first post
  • VCE doesn't have any test for bitrate above 3500 kbps
  • VCE doesn't have any test for framerate above 60 fps
  • I don't see why Ivy Bridge and Skylake are the only two QSV Gen mentionned. Everything post Ivy Bridge is superior to Ivy Bridge. It would be more helpful to have somthing like "QSV_Ivy_Bridge" and "QSV_Post_Ivy_Bridge"
  • Some kind of mark relative to the other would be helpful. For instance the first spot is attributed to x264 slow 3500Kbps but is it twice better or 5% better ? FFmpeg is saying it's more like 5-10% better but again it's a useful information to have and that isn't specified.
  • The first post says that HW encoder have 0 impact on games but it's not true. While they reduce significantly the load on the CPU OBS still uses some ressources from your system thus impacting the game you're playing. An interesting solution Linus used for CPU encoding is to set a VM with OBS in it and fetch the sources from the host machine via NDI. Obviously HW encoders won't work within a VM.
And one question, why why are you comparing different NVENC Gen, aren't they all equall in term of h264 compression quality ?
 
Last edited:
koala

koala

Active Member
Well, it's simply I don't have access to any other hardware. At that time, I upgraded my PC and had all the technology without AMD. The AMD recordings were provided by @Xaymar, who made the amd-vce encoder in OBS. I already added bitrate 6000 in the video table later, and I think 60 fps as well, when I saw that this got popular.
  • My PC is still a i7-6700k with GTX 1070, so I cannot do any analysis with 7th or 8th gen Quicksync.
  • Presets slower than slow aren't practical for live streaming or live recording. At least, the i7-6700k isn't capable of encoding this reliably in real time, so I cannot do this.
  • I did not weight the analysis outcome, because I cannot tell how significant others might perceive differences. I simply ordered the results by mathematical comparison and sorting of the mse (mean square error) compared to the uncompressed original. But this isn't telling all the truth, because in high motion scenes worse quality isn't perceived as such by the human eye.
  • You are probably citing the sentence "[placebo preset] helps at most ~1% in terms of quality, compared to the veryslow preset at the cost of a much higher encoding time. It's diminishing returns: veryslow helps about 3% compared to the slower preset, slower helps about 5% compared to the slow preset, and slow helps about 5-10% compared to the medium preset."
    If you can tell me, how the writer determines what is 1% quality difference, 3 % quality difference or 5-10% quality difference, I can probably do the same with my comparison tables, but you probably cannot. He probably means the file size: placebo produces 1% smaller files than veryslow, and veryslow 3% smaller than slower, and slower 5% smaller than slow - and everything still the same quality.
    But this isn't how streaming works: we always produce the same file size (it's the equivalence of bitrate) and get the more quality the better the compression. But how good this "more" is, nobody can really tell, at least not I. Getting 5% more information into a video isn't 5% better visual quality in your perception. For this, I attached the table with all of the videos to let you compare yourself.
  • I compared different NVENC gen, because I had two different at my disposal and I was curious if there were any differences. There were. Not big, but there were differences.
tl;dr:
There will be no more comparisons by me in the foreseeable future, because my current PC will not be replaced soon, and I don't intend to buy any AMD card as well. If there is someone who wants to add the missing amd videos, go ahead. The raw video sources are linked in the thread as well as the methodology how to produce the videos to get a reproducible result.

Adding more factors into the comparison tables make them incomprehensible. I tried to add the most common and most realistic data, but not everything there is. I already filtered results. On disk, I did much more encoding, for example I also did comparisons for constant quality recording (for local recording, not for streaming), but this is totally information overflow. Nobody can draw more information out of this than there is already publicly available.

I think I busted the "hardware encoders are always bad and meh in comparison to x264" myth at least for nvenc, and if that's the only outcome of my comparison, I'm happy with that, because that enables prospective streamers to choose an appropriate encoder without prejudice.

ps. the only thing I'm considering to add is the nvenc-hevc encoding, because this is really a quantum leap in terms of file size (up to 50% less) or, if used for streaming, up to 50% more space for the information). But since this encoder isn't largely supported by the usual streaming services, this isn't of any practical use. I tried nvenc-hevc for local recording but found the result more grainy than nvenc-h264 encoding, so I didn't continue to use hevc. This might change with the next nvenc hardware generation in Turing, currently expected Q4 or end of 2018.
 
Last edited:
A

Agamemnus

Member
koala said:
tl;dr:
There will be no more comparisons by me in the foreseeable future, because my current PC will not be replaced soon, and I don't intend to buy any AMD card as well. If there is someone who wants to add the missing amd videos, go ahead. The raw video sources are linked in the thread as well as the methodology how to produce the videos to get a reproducible result.

Adding more factors into the comparison tables make them incomprehensible. I tried to add the most common and most realistic data, but not everything there is. I already filtered results. On disk, I did much more encoding, for example I also did comparisons for constant quality recording (for local recording, not for streaming), but this is totally information overflow. Nobody can draw more information out of this than there is already publicly available.

I think I busted the "hardware encoders are always bad and meh in comparison to x264" myth at least for nvenc, and if that's the only outcome of my comparison, I'm happy with that, because that enables prospective streamers to choose an appropriate encoder without prejudice.

ps. the only thing I'm considering to add is the nvenc-hevc encoding, because this is really a quantum leap in terms of file size (up to 50% less) or, if used for streaming, up to 50% more space for the information). But since this encoder isn't largely supported by the usual streaming services, this isn't of any practical use. I tried nvenc-hevc for local recording but found the result more grainy than nvenc-h264 encoding, so I didn't continue to use hevc. This might change with the next nvenc hardware generation in Turing, currently expected Q4 or end of 2018.
Click to expand...

Heya mate, I have results for Coffee Lake QuickSync (which is V6, same as Kaby and Whiskey) and all NVENC versions except for V2 (first Maxwell) and the Volta (if there is such a thing). Also the HEVC versions, and non-live VP9 & AV1. You're welcome to use them for whatever you like in guides or whatever, just pls link to original.

https://unrealaussies.com/tech/nvenc-x264-quicksync-qsv-vp9-av1/
 
A

Agamemnus

Member
Luckily it's all in 2560x1440 which doesn't trigger that bug. But that's just by luck, thanks for the heads up, I didn't know about it.
 
S

Shad0wZ

New Member
I was testing my machine for other purposes and decided to do a bitrate for bitrate comparison for 1080p60 with imposed twitch.tv bitrate limits for NVENC and x264. Somehow the sound got out of sync for the x264 encoder but for all intends and purposes it'll do I guess, the slight delay shouldn't matter.

https://www.youtube.com/watch?v=QsaC5x0nfgA
 
Last edited:
T

TryHD

Member
Shad0wZ said:
I was testing my machine for other purposes and decided to do a bitrate for bitrate comparison for 1080p60 with imposed twitch.tv bitrate limits for NVENC and x264.
https://www.youtube.com/watch?v=QsaC5x0nfgA
Click to expand...
Youtube makes this test pointless for everybody else because it does reencode everything, you should upload it to zippyshare or some other OCH that doesn't reencode your stuff, also you should not put the source files in a Video editor and encode every thing again.
So to have a usefull comparision for somebody here, upload both source videos to a OCH.
Thank you
 
A

Agamemnus

Member
@TryHD is right, if you run the videos through an editor, it usually changes them, then YouTube changes them again. Although it may look like a viewer can tell the difference, and they can, it's actually an incorrect difference. Some people magnify the video to just look at a particular spot, like the crosshair or something that is key in a game, and although this helps, it's not a cure.

I recommend VMAF to measure the video quality compared to the original. VMAF is what Netflix uses to compare codecs and bitrates. They have a financial interest in getting this right, and getting it automated. You can get it with FFMPEG if you build it in Linux.
 
Xaymar

Xaymar

Active Member
I have been working on updated comparisons between x264 and nvenc, however using a different raw source video that the one provided here. They should be done processing in about 2 or 3 days, at which point I can start going through the actual data given by VMAF (it's a slow process even with 16 cores working on the problem). These comparisons are done through ffmpeg instead of obs studio, in order to compare actual quality instead of possible human error.

The video I am using as input can be found on YouTube here or downloaded via torrent/magnet (it's 130GB big). If you're interested in the source file, please message me so I can send you the magnet link for it. The footage itself consists of foliage, depth of field effects, and volumetric fog. There are no particles in the scene yet.
 
Suslik V

Suslik V

Active Member
Xaymar said:
...These comparisons are done through ffmpeg instead of obs studio, in order to compare actual quality instead of possible human error...
Click to expand...
joylessly words @Xaymar . Who cares about the possibilities if it is impossible to reach any of them? It's like: We found asteroid full of iron, but you need rocket to fly in a round trip several times to bring it all back to the Earth.
 
Xaymar

Xaymar

Active Member
Suslik V said:
joylessly words @Xaymar . Who cares about the possibilities if it is impossible to reach any of them? It's like: We found asteroid full of iron, but you need rocket to fly in a round trip several times to bring it all back to the Earth.
Click to expand...

You can reach the same results, just because the activation method is different it doesn't change the truth given enough samples of encoding. All this does is take away the human error factor that is controlling just when the recording starts and instead always starts it on the same frame. It will be applicable to real world scenarios that have similar content as the example video. The alternative is to do the same capture several thousand times, calculate VMAF and everything else for them, then figure out which ones are extremes and which ones aren't, and do the usual data analysis necessary when it comes to human or random problems.

Encoding quality doesn't change for the entire session just because you hit the recording button .2 seconds later. If it did, you'd see guides that have autohotkey scripts to click the button at just that exact moment.
 
Xaymar

Xaymar

Active Member
TryHD said:
One problem i see here is that the movement is very slow and steady, atleast for what i stream this is far from reality, maybe you could use this file for your tests too? http://144.76.236.14/for_all_my_friend_lossless.h264
Thank you
Click to expand...

I have another raw video that I'm working on with fast motion and particles that covers a more widespread area (similar to Apex, which is basically covering a lot of encoding areas). Unfortunately VMAF is currently using a lot of CPU time so I don't have the resources to render it to raw file yet. :)
 
T

Toasty27

New Member
@Xaymar I'm interested in the results from VMAF, and I'm willing to help where possible. I've got a server with dual Xeon E5-2430's and 96GB of RAM if you need more cores munching on the data. ISP is 100/100 uncapped fiber so transferring large files won't be a problem.
 
Last edited:
Xaymar

Xaymar

Active Member
Toasty27 said:
@Xaymar I'm interested in the results from VMAF, and I'm willing to help where possible. I've got a server with dual Xeon E5-2430's and 96GB of RAM if you need more cores munching on the data. ISP is 100/100 uncapped fiber so transferring large files won't be a problem.
Click to expand...

That'd be great, VMAF is insanely slow and doesn't scale well with more cores, so ~96 Cores would allow comparing around 24 files in parallel. The first batch went through now, just writing the tool to parse the json files now and upload the results into a database.
 
Xaymar

Xaymar

Active Member
And the results are in for the ue4-cabininthewoods file, with some surprising results. Remember that this is a comparison of a downsampled 3840x2160 source, encoding at 1920x1080 and 1280x720, then upsampled back to the original resolution as required by VMAF. We'll take a look at 1920x1080 first, then move on to 1280x720.

VMAF 1920x1080
  1. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$32 63.647%
  2. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$32 63.645%
  3. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$1 63.464%
  4. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$8 63.463%
  5. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$16 63.458%
  6. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$32 63.458%
  7. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$2 63.456%
  8. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$32 63.451%
  9. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$4 63.450%
  10. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$0 63.422%
  11. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$0 63.422%
  12. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$0 63.390%
  13. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$0 63.376%
  14. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$1 61.866%
  15. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$1 61.786%
VMAF considers nvenc H264 to be equal or better to x264 slow and medium, which is very surprising. I was expecting x264 to dominate the field like it did before, but it seems Nvidia has done some serious work on their encoder. However, in a frame by frame comparison, the issues with nvenc are clear as day: dark areas, distant small objects; and x264 only has trouble with the volumetric fog.

The top nvenc result was with the following settings: CBR High Quality, Two Pass, B-Ref Mode None, Spatial AQ, Temporal AQ, Rate-Control Look-Ahead 32 Frames. Just slightly below that is the same without Two Pass, and slightly below that is Two Pass with 1 Frame Look-Ahead (which beat 8 Frame Look-Ahead by a small margin).

SSIM 1920x1080
  1. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$0 94.123
  2. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$32$psy$0 94.119
  3. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$0 94.117
  4. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$1 94.077
  5. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$medium$nr$0$psy$0 94.076
  6. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$medium$nr$32$psy$0 94.076
  7. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$32$psy$1 94.076
  8. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$1 94.076
  9. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$medium$nr$16$psy$0 94.074
  10. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$medium$nr$0$psy$1 94.050
  11. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$fast$nr$0$psy$0 94.050
  12. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$medium$nr$16$psy$1 94.048
  13. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$fast$nr$16$psy$0 94.047
  14. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$medium$nr$32$psy$1 94.047
  15. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$fast$nr$32$psy$0 94.046
  16. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$32 94.033
And with SSIM the field completely switches around. SSIM considers fast preset to be better than nvenc H264, as it likely sees the mess nvenc makes with dark areas and distant small details and isn't based on a constantly changing model that has to be re-trained.

One important thing that we can already see is that x264's noise_reduction option causes quality to drop significantly, and both VMAF and SSIM notice this quality reduction. Furthermore, psychovisual optimizations cause a lower SSIM score, but a higher VMAF score - so unless you aim for a high SSIM score, you should leave it enabled.

PSNR 1920x1080
  1. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$0 27.558
  2. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$0 27.558
  3. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$32 27.556
  4. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$32 27.556
  5. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$0 27.554
  6. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$0 27.554
  7. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$2 27.554
  8. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$8 27.554
  9. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$16 27.554
  10. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$32 27.553
  11. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$4 27.553
  12. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$1 27.553
  13. ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$32 27.553
  14. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$0 27.527
  15. ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$0 27.524
PSNR for the most part seems to mirror what VMAF saw, ranking nvenc above x264 slow again. As expected it considers psychovisual optimizations to be worse than those without them, and also ranks noise_reduction lower. But unexpectedly, it considers the files without Two-Pass and Look-Ahead to be slightly better than those with it.

Next up is 1280x720, which has results closer to what we'd expect and is a more realistic test for most streamers. Again we will compare the top 15 VMAF, SSIM and PSNR files.

VMAF 1280x720
  1. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$1 62.543
  2. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$1 62.453
  3. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$32 62.445
  4. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$32 62.445
  5. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$0 62.361
  6. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$0 62.361
  7. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$32 62.343
  8. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$32 62.343
  9. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$32$psy$1 62.321
  10. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$0 62.288
  11. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$0 62.200
  12. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$0 62.200
  13. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$0 62.180
  14. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$32$psy$0 62.105
  15. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$0$psy$1 61.853
The first unexpected thing is that most of these scores are in the same range as the higher 1920x1080 resolution, which means that a lower overall resolution managed to get very close if not better than a higher resolution encode to the same input signal. A lower resolution combined with a higher bitrate could result in a better quality, at 6mbit.

For the most part this is what we'd expect from x264: it's dominating by a significant margin of ~0.1%, providing ever so slightly better quality than nvenc. Right after that is the noise_reduction tests, which are obviously worse. And then we reach nvenc H264, which in a surprising twist compared to 1920x1080 performed better with B-Ref-Mode Half and no Two Pass. The rest of the list is as expected with faster x264 presets being worse than the slower one.

SSIM 1280x720
  1. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$32$psy$0 94.321
  2. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$0 94.320
  3. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$0 94.320
  4. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$1 94.302
  5. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$1 94.301
  6. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$32$psy$1 94.299
  7. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$16$psy$0 94.293
  8. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$0$psy$0 94.293
  9. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$32$psy$0 94.292
  10. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$16$psy$1 94.274
  11. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$0$psy$1 94.274
  12. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$fast$nr$0$psy$0 94.273
  13. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$fast$nr$16$psy$0 94.272
  14. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$32$psy$1 94.272
  15. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$fast$nr$32$psy$0 94.271
  16. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$fast$nr$0$psy$1 94.250
  17. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$fast$nr$16$psy$1 94.250
  18. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$fast$nr$32$psy$1 94.248
  19. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$32 94.212
Like before x264 dominates the top spots, and also like before, SSIM considers psychovisual optimizations to look worse. Unlike before however, B-Ref-Mode Half (2) is again winning without Two Pass for nvenc H264 by a small margin.

PSNR 1280x720
  1. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$0 27.540
  2. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$0 27.539
  3. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$32$psy$0 27.539
  4. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$0 27.534
  5. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$0 27.534
  6. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$32 27.534
  7. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$32 27.534
  8. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$1 27.529
  9. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$32 27.528
  10. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$32 27.528
  11. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$0 27.528
  12. ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$0 27.528
  13. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$1 27.528
  14. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$0$psy$0 27.527
  15. ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$16$psy$0 27.526
And this time PSNR considers x264 slow to be better than nvenc, and also considers noise_reduction to just be bad. Same as before, Two-Pass and Look-ahead are considered bad, and B-Ref-Mode Half is again winning.

So what do we do with this Information?
If your stream is not similar to the input used for this, then the results are pretty much useless to you for now. The input file mimics a slow camera going through a forest, with extreme fog and some extreme depth of field and strong color contrast. Most gaming streams aren't like this, and the closest you could get would likely be a real life stream going through a park or art streams.

If your stream is like that, then you will actually benefit from Turing/RTX nvenc at its best current setting at virtually no cost (except for the GPU), or can just stick with x264 medium or slow. This is a surprising turnaround from the last time I ran these test on Pascal, where x264 veryfast and up dominated the field in PSNR, SSIM and VMAF.

Update: All encoded files are now available to watch here: https://cdn.xaymar.com/ves/
 
Last edited:
You must log in or register to reply here.
Top