# Comparison of x264, NVENC, Quicksync, VCE



## koala (Nov 7, 2016)

The question we all want to know is:

_What encoder and which encoder setting should I use for streaming/for recording?_

and:

_If I use a hardware encoder, does the quality suffer?_

There are so many configuration options and there is so many different hardware available, so this is _always very difficult to answer_.

So I made a autohotkey script and _created recordings of literally every combination of every encoder setting_. Then I compared the quality of the resulting videos to the original lossless recording. The first level of comparison was made with ffmpeg (method see down below).

This is the result for OBS simple settings for streaming. I did the tests on 2 machines:

- i5-3570k with GTX 670 (QSV_IvyBridge with NVENC_Kepler)
- i7-6700k with GTX 1070 (QSV_Skylake with NVENC_Pascal)
- [no AMD-VCE, since I don't own one.] see post #25 for a comparison that includes VCE

_Bitrates tested: 2000, 2500, 3500
Resolutions tested: 1280x720 (30 and 60 fps), 1920x1080 (30 fps)_

The report only includes the one preset that gives the best quality for each encoder. This was done to not clutter the report with settings one will not use anyway. However, I tested all presets (for example for NVENC such as: "Low-Latency", "Low-Latency High Performance").










Excel-Sheet

From this computer-generated rating with mainly the mse as criteria, *you may come to the conclusion that NVENC is on par with x264 preset=veryfast (the default in OBS), or even a bit better, but unfortunately it isn't*. At least for high motion scenes.

*Download the bitrate 2500 x264 and nvenc video and compare them with your eyes, and you will see more details in the second half of the video with x264 than with NVENC.* I was mislead by the mse numbers myself, but I cannot deny the x264 video definitely shows a bit more more detail in high motion parts. Low motion looks the same with both.

Still correct is the ordering of NVENC and Quicksync: NVENC provides better visual quality than Quicksync. Quicksync on Skylake is better than on IvyBridge, but NVENC is still a bit better than both.

So I _recommend the encoders in this order_:


if your computer is able to encode *x264 preset=veryfast or better* while running your game, use this. This will interfere with your game and your stream, if your CPU is not powerful enough. Only desktop i5 and i7 processors are probably able to encode better than veryfast while a CPU-demanding game is run in parallel.


if you have NVENC available, use *NVENC with preset=highquality*. This will not interfere with your game at all.


if you have Quicksync available, use *Quicksync with preset=balanced*. This will not interfere with your game at all.


*don't use x264 preset=superfast or ultrafast *for streaming, as they produce way worse output than even Quicksync.


rating:

x264 faster = 80/100
x264 veryfast = 75/100
nvenc highquality = 70/100
quicksync balanced = 60/100
x264 superfast = 40/100
x264 ultrafast = 30/100​
***​
You can download the encoded videos here and do a visual comparison yourself:

http://www.wombaz.de/uploads/2016/11/obs-codec-test/

A convenient table for visual comparison between codecs is in this post:
https://obsproject.com/forum/posts/252221

If you do extensive visual comparison, please don't watch the videos though the browser but do a "Save as" and download them to your disk. Then watch them with your media player locally.
In the directories included are "analyis2.txt" files, which contain the machine-generated ratings from every single test.

***​


Spoiler: The method



The method:

I created a 2 minute long reference video of my favorite game. 2560x1440p60 lossless recording with OBS (simple output mode->"Lossless Quality, Tremendously Large File Size"). The video includes 2 low motion scenes and 2 high motion scenes, each about the same length.

for the test of 1280x720p30 create a 1280x720p30 reference video by downscaling the original reference video to 1280x720p30 with ffmpeg. Output codec again lossless (video codec utvideo, same as OBS uses)

pick 2 reference frames, one from near the start of the video and one from near the end. Record the frame numbers.
in OBS, create a new scene with one vlc video source and add the 1280x720p30 reference video
In OBS, set base and output resolution to 1280x720 and frame rate to 30
now create a bunch of recordings of the reference video by permutating every output setting. A autohotkey script was used for this.
Perform the next steps with each video:

search for the 2 reference frames and record the frame numbers. This is done with ffmpeg and the psnr filter.

to see by how many frames the recorded video is shifted in relation to the reference video, get the difference between the frame numbers of the high motion reference frame. For example, if the reference frame is number 2400 in the reference video but 2420 in the recorded video, the recorded video is offset by 20 frames and any frame-by-frame comparison must start these 20 frames later.

compare the reference video and the recorded video and take the offset into account. "compare" means use the psnr filter of ffmpeg. Save the psnr statistics file. This way, each original frame is compared with its corresponding encoded frame and we determine the mse ("mean square error") of each frame. The lower the mse, the better the encoded frame. The better the mse of all frames of a video, the better is the quality of a video.
After processing of all videos:

now we have all mse comparisons. For each video, we have a list of the mse of all frames of this video.
To order our videos by quality, compare the mse list of each video with the mse list of each other video.

a comparison of 2 videos looks like this: for each pair of frames (one frame from video 1 and one frame from video 2), look which has lower mse. Count the frames which have lower mse. The video that has more frames with lower mse is declared "better" than the other video.

by using the this comparison method, it is possible to sort all videos by some sort of visual quality. It doesn't sort by average mse of each video but by answering the question: "which video has more frames that are better than the rest of the videos?"



***​
I also made recordings with advanced settings. But the analysis is extremely difficult to interpret, because videos with varying encoding quality (x264 with crf, Quicksync with icq) inherently score worse than videos with constant quality (CQP with hardware encoders), although they don't look worse to the eyes of a human being.

But even with bitrate-based streams, the comparison method can only be a rough estimate. The true judge can only be the human eye. For example, in another thread, I falsely claimed NVENC is better than x264, because the mse comparison said this (I apologize, @Harold). For quality-based recordings it is even more difficult - I am really lost here.

I would like to make a guide/resource from this, but how extensive should that be? It could be as short as "x264 > nvenc > quicksync" and as long as this post.


----------



## Beardedbob (Nov 7, 2016)

Streaming 720p @ 30Fps , 2000 bitrate, CBR, Software x264 encoder.
Record 1080p @ 60fps, CQP, Quliaty 20, High Q Profile, Nvenc encoder.

Note: if you have 2.2mb upwards upload on your internet you can increase the bitrate but twitch recommends 2000 as the sweet spot atm. If you want to stream 720p 60fps then you need a min of 2500  bitrate on high motion even then it could do with higher bitrate.


----------



## Wakky (Nov 7, 2016)

Nice work you did there even if neither MSE or PSNR can judge image quality/fidelity like our eye does.

I dont really see how you could make a guide out of this by if you do you should.

Btw did you try to really tune x264 with custom settings (me, merange, direct, etc)?



Beardedbob said:


> If you want to stream 720p 60fps then you need a min of 2500  bitrate on high motion even then it could do with higher bitrate.



No, no and no. Why people keep trying to stream 720p 60fps with under 4000+kbps? Where did that myth came from? You even said it yourselves; "high motion games".

Simply do the test, compare your stream at 720p 30fps and 720p 60fps for 2500kbps for both and watch how much damage you did to the image.

It's simple 720p 30fps need at least 2000 kbps to look good. You want to double the fps? Double that bitrate.


Edit: Forgot to finish before posting.


----------



## Beardedbob (Nov 7, 2016)

Wakky said:


> Nice work you did there even if neither MSE or PSNR can judge image quality/fidelity like our eye does.
> 
> 
> 
> ...



Yes, yes yes........4000+ lol, really Wakky, what are you after perfection? given 4000+ requires you to be a partner on twitch then this is going to be limited. if you must use the max bandwidth you can as a non streamer then use 3500 this will limit the users who can view it given they require 3.5mb download +.

720p 30fps at 2000 isn't flawlessm in fact no even close, its down to what you want to accept as the streamer / viewer along with what game you are playing.

The one thing that's certain is there is always a trade off whether its bandwidth, CPU or quality.


----------



## Wakky (Nov 7, 2016)

Yes I know 3500kbps is the limit for non partner but that doesnt change anything and what I say still true.

720p 60fps at 2500kbps for high motion game isn't an advice you can give that's all. It's incredible how you can say that and in your next answer you say "720p 30fps at 2000kbps isnt flawless". You were ok to go 720p 60fps 2500kbps one post before!

720p 60fps 4000kbps isn't perfection it's a minimum it makes a huge difference.

I strongly recommand you to check https://obsproject.com/forum/resources/twitch-and-youtube-settings-guide.169/ to understand how you have to chose your bitrate, resolution and fps. Your actual method if there is any isn't accurate if it can make you believe you can go 720p 60fps 2500kbps.

Yes it's all about trade of but you seems to ignore a lot of key points.


----------



## Beardedbob (Nov 7, 2016)

Wakky said:


> Yes I know 3500kbps is the limit for non partner but that doesnt change anything and what I say still true.
> 
> 720p 60fps at 2500kbps for high motion game isn't an advice you can give that's all. It's incredible how you can say that and in your next answer you say "720p 30fps at 2000kbps isnt flawless". You were ok to go 720p 60fps 2500kbps one post before!
> 
> ...



As i said the min you want to work with if you want to even start to look at 720@60fps is 2500 bitrate. No one said it was going to be prefect or even outstanding quality its a start for low motion video. As stated its a trade off, pushing the bitrate to 3500 is going to limit the audience.

Thanks for the article I've already read it, though i'm not sure you have as it doesn't state 4000+. If you are partnered and have the upload then why would you stick to 720p? you might as well go up to 1080p.

As for ignoring the key points, the only thing being ignored in your fantasy world is most streamers don't have unlimited bandwidth nor are they partnered to twitch. The general Joe blogs can't stream above 2000 either due to bandwidth, pc limitations or the viewers watching can't handle the buffer pain due to their poor DL.

If you can run at 3500 bitrate its assuming you don't burst over the 3500 limited for the twitch ingress, which at CRB 3500 happens all the time resulting in twitch blocking you. This therefore brings the bitrate down even further for non partners to somewhere around 3100 to 3200 bitrate available.


----------



## Wakky (Nov 7, 2016)

Like I said the min is way higher then that. 4000+kbps. At 2500kbps you have absolutely no reason to go higher then 720p 30fps except if you want to damage the render quality and why would anyone do that? 

Pushing the bitrate wont limit the audience since Twitch give transcoding with less then 10 viewers now. I admit it was true less then one month ago but it's not anymore. I usually tell people to go 2500kbps max until they got transcoding, now I dont have to since almost everyone got it.

The article said something like 5500kbps to start to have perfect fidelity. Under 4000kbps 720p 60fps is a mess and each time you will move it will be heavily blurry. This article was more to explain you how wrong you were when you advice 720p 60fps for 2500kbps.

Why 720p and not 1080p? For high motion games the answer is the 60 fps. Specially if you consider that a lot of people wont go fullscreen to keep the chat visible meaning their display resolution is often 720p. 

My fantasy world is the one of video stream and quality rendering sorry if you want to keep thinking it's a fantasy world but dont be surprised when you will realize how much damage you were or you are doing to your stream or you are doing to the stream of other and thats the worst part! Obviously you could ignore the truth but now you have no excuses, you cant give wrong advice to people anymore!
For your own stream it's your choice you can even completly fuck up the settings go 1080p 60fps for 2000kbps if you want to, its up to you but dont advice 720p 60fps 2500kbps for other please! Like never again! 
In my fantasy world we like quality and we know how to reach it almost no matter the bitrate and we dont advice bad settings. 

2500kbps? 720p 30fps for high motion games or 616p 45fps. Period.

Do you realize how many non partnered streamer use 3500kbps and won't never be block? Specially now with transcoding for almost everyone. Actually it's completely out of the subject. I don't care what are you reason to chose 1500kbps 2500kbps 3500kbps or whatever that wasnt the problem why the hell you deviate that much?


Now you clearly won't agree even with all the evidence of the world and you will probably go out of the subject more and more so let's stop this here and not pollute OP's thread anymore.


----------



## koala (Nov 7, 2016)

Should I add 4000 @60fps to the analysis and provide corresponding demo videos? I thought that this high a rate is not relevant for the majority of hobby streamers, so I skipped that.


----------



## Wakky (Nov 7, 2016)

I made a graph to know wich resolution and fps to chose depending on your bitrate there: http://imgur.com/noBGkeT

If you want to do some test for higher bitrate but yeah I believe it won't be usefull because of the 3500kbps cap for non partnered streamer. Who knows perhaps some partener will lurk around.


----------



## TryHD (Nov 7, 2016)

I find it funny how all go for that 2000 kbit/s for non partnered is max. I stream at 5000 kbit/s with 20-70 viewers as non partnered without transcoding from twitch just fine and nobody complains about lag.


----------



## Suslik V (Nov 7, 2016)

I compared the files 1280x720@30:

simple - stream - x264 bitrate=2000 preset=veryfast.mp4
simple - stream - NVENC_Pascal bitrate=2000 preset=highquality.mp4
simple - stream - NVENC_Kepler bitrate=2000 preset=highquality.mp4
simple - stream - QSV_Skylake bitrate=2000 preset=balanced.mp4
simple - stream - QSV_IvyBridge bitrate=2000 preset=balanced.mp4

IMHO, the rating (from best to worst) is:

*NVENC_Pascal* (2) _best_
*NVENC_Kepler* & *x264 *(3 & 1)
*QSV_IvyBridge *(4)
*QSV_Skylake *(5)

Why?

x264 & NVENC_Kepler - I didn't noticed any significant difference.
QSV_IvyBridge "feels" smoother at clouds movement (timeline from 00:00:47 to 00:01:00 - flying hero) than QSV_Skylake.


1280x720 because of my display resolution (fullscreen only 1:1 size for compare);
30 fps - because I watch most content in 30 fps 



Spoiler



hope original renderer will render 30fps lossless movie for compare, not 60 to 30 convert - for synthetic tests - just to be sure how quality differ if you play at 60 fps and stream it at 30 fps, instead of 30 fps play and 30 fps stream.



2000kbit/s - is still too much, but theoretically, without sound, it good enough for my inet connection.
x264 veryfast - because lower profiles has more impact on the system and rare in use (not all people have high-end CPUs :)
All rating based only on my own perception of the footage (no numbers or math), same player for all videos, in player - default video renderer, decoder is LAV Video Decoder: 0.68.1.31-git - no hw acceleration.


----------



## Suslik V (Nov 7, 2016)

And where is 1280x720@30 input lossless?
Maybe @Xaymar be able to record it for me at 2000kbit/s with AMD Encoder and then I'll be able to compare it visually too? At least, he has AMD card with VCE. Or I'll be wait when you'll find a friend with modern AMD card on board.


----------



## xKlokwerkz (Nov 7, 2016)

Quick question, is there a reason to not using the High Quality preset instead of Balanced on QS? As of now, I am currently streaming using 720p60fps QS HQ and seeing this made me wonder.


----------



## Xaymar (Nov 7, 2016)

Suslik V said:


> And where is 1280x720@30 input lossless?
> Maybe @Xaymar be able to record it for me at 2000kbit/s with AMD Encoder and then I'll be able to compare it visually too? At least, he has AMD card with VCE. Or I'll be wait when you'll find a friend with modern AMD card on board.



I currently have a card with broken CBR/VBR, I'm waiting for the AMD team to reply on what is causing it. I can test with a RX 4xx card once it arrives here.


----------



## Beardedbob (Nov 8, 2016)

TryHD said:


> I find it funny how all go for that 2000 kbit/s for non partnered is max. I stream at 5000 kbit/s with 20-70 viewers as non partnered without transcoding from twitch just fine and nobody complains about lag.



The max for non-partnered is 3500 not 2000. Twitch awhile back said that the best compromise for quality vs viewers was 2000 as it game reasonable quality but also allowed for lower bandwidth users to avoid buffering.


----------



## koala (Nov 8, 2016)

I am just uploading the 3 lossless master videos to the "lossless master" subdirectories in the corresponding directories, in case someone wants to make own recording tests. They are large, so they are probably ready this evening. Please, only download them if you really intend to test for yourself.

To reproduce my recording setting as closely as possible:

put the lossless master video on a ssd

in the video settings tab of OBS, set base and output resolution to the resolution of the lossless master video, and set the frame rate to the same frame rate as the lossless master video. Don't use the 60 fps video for recording tests of 30 fps and vice versa - only use the video with the corresponding fps and resolution.
create a vlc media source in OBS, set its Visibility Behaviour to: "Stop when not visible, restart when visible"
add the lossless master as only item to the playlist of the vlc media source
deactivate the vlc media source in the main window of OBS (click on the "eye") to make it not running
create a hotkey for the action "Show 'vlc media source'". I used CTRL-ALT-V. Set the same hotkey to "Hide 'vlc media sourc'"
create a hotkey for the action "Start recording". I used CTRL-ALT-` (that's the backtick char). Set the same hotkey for "stop recording"
in the stream settings of OBS, set Twitch as service. Leave the stream key empty, if you don't have a Twitch account. Although you will not actually stream to Twitch, this setting will set some encoder settings for the simple output method like keyframe interval.
Verify that if you start the vlc media source, the master video will start showing from the beginning and fill the entire canvas. If you stop it, the canvas must be empty. If you start it again, it must start from the beginning again, and if you stop it again, the canvas must be empty again.

Perform the recording this way:

set the desired recording settings in the output tab of OBS settings and close the settings window.

press the hotkey for showing the VLC media source (CTRL-ALT-V). This starts the video.

exactly one second later, press the hotkey for start recording (CTRL-ALT-`). This starts the recording.

wait 128 seconds
press the hotkey for stop recording or click "stop recording"
press the hotkey for hiding the VLC media source or click on the "eye" in the OBS GUI.

The 1 second delay between start of video and start of recording was made to prevent Windows-induced lags due to starting a bandwith-intensive file-reading situation. This way, caching and buffering can accomodate this.

I also upload the autohotkey script that automates the recordings, but beware: it's a monster. It requires 100% screen scaling of Windows (usually, the default for desktops). It defaults to the encoder capabilites of a i7-6700k with GTX 1070. If you try to record on a different hardware, you have to accommodate that in the SetGlobalConf function. The Quicksync options differ from iGPU to iGPU version.

If you try to record AMD-VCE, you must define the dialog element postions and drop-down list contents, otherwise the script will not know what and where to click. I can help with that and do it for you if you provide unscaled screenshots of the dialogs and contents of all AMD-VCE-related dropdown lists. Or an unscaled video where you click through all of these dialogs and settings, as this might be easier to create and upload than 10 screenshots. The size of the settings window must be 997x706 according to the "Active Window Info" app of Autohotkey. As far as I know, this is the OBS default. Or almost. Important is that you didn't mess with the width too much.


----------



## koala (Nov 8, 2016)

xKlokwerkz said:


> Quick question, is there a reason to not using the High Quality preset instead of Balanced on QS? As of now, I am currently streaming using 720p60fps QS HQ and seeing this made me wonder.


I did not see any difference in the videos and the automated comparison said "Balanced" will result in better quality than high quality for most bitrates. So I chose balanced as best setting. If you want to see the complete automated rating, look for the analysis2.txt files in the 3 subdirectories. There you see each setting combined. The difference is not significant, probably not visible at all, so if you feel you should use high quality instead of balanced, go for it.


----------



## Suslik V (Nov 8, 2016)

Anyway, please provide us with the recordings of High Quality preset Quick Sync (that I can compare it visually too, 2000kbit/s, 1280x720@30fps).


----------



## koala (Nov 8, 2016)

I uploaded the qsv_skylake versions of quality (and speed as well).


----------



## Suslik V (Nov 8, 2016)

I tested the last files,
...
6. simple - stream - QSV_Skylake bitrate=2000 preset=quality.mp4
7. simple - stream - QSV_Skylake bitrate=2000 preset=speed.mp4​Now the rating is the same as previous:

*NVENC_Pascal* (2) _best_
*NVENC_Kepler* & *x264 *(3 & 1)
*QSV_IvyBridge *(4)
*QSV_Skylake *(6 & 5)
About quality.
QSV Skylake Quality preset is better (image is clear) than Speed preset. Easy noticeable on camera move (hero landing, timeline from 00:01:03 to 00:01:18).
I didn't find difference between QSV Skylake Quality preset and Balanced preset from the footage. But it "feels" like a bit crisper image (and there, this is better) for Quality preset when camera moves around the hero (timeline from 00:00:29 to 00:00:33).
So, I can recommend Quality preset for QSV and  Skylake CPUs (and don't use Speed preset for 1280x720@30 2000kbit/s).

@koala Just to be clear, the results may depend on video adapter model as well as on driver version. So, please, post HD graphics driver version and NVIDIA driver version you made tests with.

Is Quick Sync _Quality_ preset available for IvyBridge CPUs?


----------



## BlockAboots (Nov 8, 2016)

Its a shame that NVENC cant compete with x264, as x264 uses a hell of a lot more CPU cycles and the NVENC. 

Speaking of which, what encoding method is best for NVENC?, VBR, CQP, or CBR??


----------



## Xaymar (Nov 8, 2016)

koala said:


> I also upload the autohotkey script that automates the recordings, but beware: it's a monster. It requires 100% screen scaling of Windows (usually, the default for desktops). It defaults to the encoder capabilites of a i7-6700k with GTX 1070. If you try to record on a different hardware, you have to accommodate that in the SetGlobalConf function. The Quicksync options differ from iGPU to iGPU version.
> 
> If you try to record AMD-VCE, you must define the dialog element postions and drop-down list contents, otherwise the script will not know what and where to click. I can help with that and do it for you if you provide unscaled screenshots of the dialogs and contents of all AMD-VCE-related dropdown lists. Or an unscaled video where you click through all of these dialogs and settings, as this might be easier to create and upload than 10 screenshots. The size of the settings window must be 997x706 according to the "Active Window Info" app of Autohotkey. As far as I know, this is the OBS default. Or almost. Important is that you didn't mess with the width too much.



I have no idea how to edit your scripts so I'm going to do things manually. Downloading the lossless files now (dear god that download speed), so hopefully I should have files for you in a bit.


----------



## Xaymar (Nov 8, 2016)

*Edit: For an odd reason, these files all have two audio streams and are below the target bitrate. Will reupload fixed one.*


1920x1080: Lossless file is missing, pls upload that one too.

I discovered a bug in the currently public version while testing these and used a fixed version instead. The overall quality per bit is pretty decent, definitely useable for streaming IMO.


----------



## koala (Nov 8, 2016)

Now all 3 lossless files are uploaded. My home upload bandwidth is not as fast as the bandwidth of my vps where the files are hosted ;-) The script is a simple ascii file - use your favorite text editor. It requires autohotkey. I will process your files with the automated rating @Xaymar, so we can see what the machine thinks about vce.


----------



## koala (Nov 8, 2016)

It seems that VCE does not really meet the quality of the other two hardware encoders. Here is the machine-generated rating. This time, I left every quality setting of the other encoders instead of removing the inferior ones, so you can see what the difference is.

Edit: removed current analysis. Will redo and republish the analysis when Xaymar uploads new videos.


----------



## Xaymar (Nov 9, 2016)

About what I expected, considering that there are quite some bugs left in the VCE firmware that need to be fixed first. I'm sure that with future driver upgrade we'll see AMDs encoding getting better and better, as the hardware is certainly capable of more.
My GPU (R9 285) for example is capable of encoding 1280x720 60 fps CBR 3500 Quality at 200 fps, so there is definitely room for improvement.


----------



## koala (Nov 9, 2016)

Firmware update and driver? Interesting. Until now I thought hardware encoder really means hardware that cannot be changed, only with a new chip design. @Suslik V also mentioned this for Quicksync and NVENC and asked for my versions.

My driver versions for Quicksync:
Intel Skylake: 21.20.16.4534
Intel IvyBridge: 10.18.10.4276
(both are what Windows 10 installs and updates automatically after the anniversary update and later. I did not install them manually)

Nvidia Kepler: 368.39
Nvidia Pascal: 369.09
(these I installed manually. The Kepler driver is older, because this is my previous PC that I don't update regularly any more - only what comes in automatically)




BlockAboots said:


> Speaking of which, what encoding method is best for NVENC?, VBR, CQP, or CBR??


It depends on what you want to do. For streaming, you have to use CBR. For recording, use CQP. I didn't publish recording comparisons, but if you use the "indistinguishable quality" or "high quality" setting of the simple output mode, you should be fine as they use CQP. For NVENC, "indistinguishable quality" is the same as CQP=16 (varies a bit with the output resolution) and "high quality" is CQP=23. Indistinguishable produces 2.6 times the file size of high. If you want something in the middle, use a cqp between 16..23. It's in the same quality range as x264, only larger files than x264.


----------



## Suslik V (Nov 9, 2016)

I tested the new AMD files,
...
8. VCE1412_1280x720x30_CBR2000_Quality.mkv
9. VCE1412_1280x720x30_CBR2000_Balanced.mkv
10. VCE1412_1280x720x30_CBR2000_Speed.mkv​​Now the rating is (almost the same as previous BUT NOT equal video used at compare, see comment below):

*NVENC_Pascal* (2) _best_
*NVENC_Kepler* & *x264 *(3 & 1)
*QSV_IvyBridge *(4)
*QSV_Skylake *(6 & 5)
*AMD_VCE1412* (10)
*AMD_VCE1412* (8 & 9)
Either AMD or @Xaymar who made this unbelievable "perfect" videos is f***ed up... Considering that informing AMD staff about this tests would be a good idea! How to sell items if the are fails so much? ^_^ Even worse, that this idea (VCE is shit for streaming) can spread across youtube very fast (due to current results and you'll be unable to make it any better soon).

SO, WHAT settings in OBS Studio and WHAT version of VLC you both had when you performed this test? Because, I see that @Xaymar 's videos are "darker"? Its absolutely clear that footage has different color setings (BT.601 vs BT.709 applied on encode). Please, upload test videos or images to OBS Studio from this link: https://obsproject.com/forum/resour...t-color-range-settings-guide-test-charts.442/
 (you can set OBS Studio to 709, partial to be sure that you have identical setups), and thus we can see how each encoder encodes color (what standard is used by default internal processing of the hw encoder itself). Then I will compare you both again.

If possible, post test videos of HW encoders with color charts (at least, 10sec for color + 10sec for range) as input, use png image. I can compare it visually.

In general, AMD VCE has visible temporal degradation (keyframes are visible to me, when they are appear in video ^_^), and only Speed preset has less noticeable degradation, that's why I placed it higher than Balanced and even Quality preset. Maybe this is internal processing, but I think that is possible to improve in the future (maybe driver update required, of course).


----------



## Xaymar (Nov 9, 2016)

Suslik V said:


> bla



Jesus dude, could you be a little more friendly? There is no need for this hostility.

Anyway, for some reason my recorded videos actually used ~700kbit less than I set them to. As for the "darker colors", set your media player to use the correct decoding method. I was not able to reproduce any color difference or brightness difference with my decoder set to automatically convert Partial and Full Range correctly.

I'll redo my recordings and post new links once done.


----------



## Suslik V (Nov 9, 2016)

I know that you can do the best. When things will be OK. I'll say to you: "Well done.".

Just upload test charts and make short recordings (1280x720 png image). As for x264, OBS Studio has full control over the colors. Not sure that you able to done this to the NVIDIA or AMD. You have encoded video in different standards and containers of the media files lack this info too. Probably, @Xaymar you are working with BT.709 and thus has true colors (even if it has a lot of blocking artifacts), I need to view test footage (charts) to confirm this.

Now I see, that comparison is not true. We need to improve the conditions.


----------



## Xaymar (Nov 9, 2016)

Fixed files, including 1920x1080x30 this time. Remember that these files are in partial range, even though it says full - no idea why that happens and I hope I can fix it in the future.

EDIT: Found the bug that caused it, redoing these.

@koala I really need to figure out your AHK script. Would it help if I sent you a screenshot of the simple and advanced UI? I have next to no knowledge about AHK scripting.

@Suslik V  AMF outputs Partial range files, so the encoded file looks more washed out than it should be. Normally this is automatically detected, but occasionally you need to set the player to convert from Partial to Full Range - like with the above files.[/USER]


----------



## koala (Nov 9, 2016)

Regarding full and limited range and color space: my recordings are all partial and 601, because that's the OBS default. As far as I read about that topic, a difference between full and partial is negligible for streaming purposes, even for standard recordings that you intend to postprocess and finally publish as video. Color space 709 can/should/may be used for resolutions bigger than 1920x1080. For comparison purposes, I tried to left as much at the defaults as I can.

@Xaymar Easiest for you would be if you record a video of yourself clicking through all AMD-specific options of the simple and advanced output mode. Then I can figure out the dialog element positions for you. Multiple Screenshots are very tedious to handle. Simply start OBS 2 times: the first does a display capture of your session at the native resolution of your desktop (very important: no scaling). The second OBS is the one you are clicking through the options. For advanced output mode, it may be required that you choose and click through all rate control options, because the UI could change every time and adjust input fields according to the active rate control option.

If you really intend to use that script, I will write a documentation with a workflow that describes how to do automated recordings, automated analysis and automated ratings.


----------



## Suslik V (Nov 9, 2016)

This "darker" I mentioned before is just brighter green and darker red. That points me to the different matrix (coefficients) was used when RGB becomes YUV and encoded (because my player simply decodes all HDs as BT.709 either it coded 709 or 601). Due to this transform, encoder has different data as input, thus you cannot compare footage you made. As far as I know, NVIDIA unable to encode NVENC as BT.709, can you proof other?

P.S. Also, some applications can make screens in different color space, because they can convert YUV to RGB.


----------



## Suslik V (Nov 9, 2016)

To make perform the color test @koala , @Xaymar , please follow this steps:

Download _OBSStudioNum1235_with_delay.zip_ (attached). Unzip.
Download _All_files_Color_space+range+subsampling_test_charts.7z_ (All charts in one 7z file, ~21,7 MB - this is from the https://obsproject.com/forum/resour...t-color-range-settings-guide-test-charts.442/ ). Unpack.
Set in OBS Studio:
Settings>Video>Base (Canvas) Resolution: 1280x720
Settings>Video>Output (Scaled) Resolution: 1280x720
Downscale Filter: Bilinear (Fastest, but blurry if scaling)
Settings>Advanced>YUV Color Space: 709
Settings>Advanced>YUV Color Range: Partial
Settings>Advanced>Color Format: NV12


Save all settings (by OK button)

Setup all settings you need to the encoder.
When encoder setup is ready, add two image sources to the OBS Studio scene.
Rename upper image source (first in the list of the _Sources_) to 'Range chart'.
As Image File choose: _1280x720_color_range_test_chart.png_ file (in source Properties).
By default, image starts from top left corner of the screen (position 0;0) do not change this.
Rename second image source (second in the list of the _Sources_) to 'Color chart'.
As Image File choose: _1280x720_chroma_subsampling_test_chart.png_ file (in source Properties)
By default, image starts from top left corner of the screen (position 0;0) do not change this.

Set in OBS Studio:
Settings>Hotkeys>Show 'Range chart' : Num5
Settings>Hotkeys>Hide 'Range chart' : Num2
Settings>Hotkeys>Start Recording : Num1
Settings>Hotkeys>Stop Recording : Num3

Save all settings (by OK button)

Click at the center of the OBS Studio Preview window (this defocuses _Sources_ list).
Run OBSStudioNum1235.exe (attached in zip).
Click at the center of the OBS Studio Preview window (this defocuses _Sources_ list).

Wait for 2+10+10+2=22 seconds. The ...recording start, 'Range chart' hides, recording stop, 'Range chart' shows... sequence complete. The OBSStudioNum1235.exe should disappear from the tray.
Upload recorded files on the forum (or give me a downloadable link to them to view the results).
The AutoHotkey script itself, in case of false positive antivirus warning for you (exe+ahk in .zip attached):

```
Sleep, 2000
Send, {Numpad1}
Sleep, 10000
Send, {Numpad2}
Sleep, 10000
Send, {Numpad3}
Sleep, 2000
Send, {Numpad5}
```



Spoiler: In case of events not triggered



In case of events not triggered, try to modify the script, see Numeric hotkeys not working on Windows OBS studio  about Up and Down time for keys.


----------



## Xaymar (Nov 9, 2016)

I figured out why the colors seemed off, obs doesn't actually respect what the plugin asks for in get_video_info. I made a bug report about that here.


----------



## koala (Nov 9, 2016)

It seems to me that information flow should be the other way round: the plugin should use what OBS asked it to use. If the plugin isn't able to conform, it should return an error and don't record anything. If the plugin/encoder is able to override user-defined settings, the resulting video can contain something the user didn't request, and the user don't even get a notice about this. This is bad.

Ideally, you shouldn't be able to configure something in OBS an encoder isn't actually able to do. For example, if the encoder isn't able to output color format i444, which is the case for Quicksync, you shouldn't be able to set both this color format AND choose Quicksync. Another example, if you try to use a resolution larger than 4096x4096 with NVENC, this will always fail, because the maximum supported resolution of NVENC is 4096x4096.

As alternative, the "start streaming" or "start recording" button should be inactive and a message should be visible that tells the user that the settings he requested cannot be used for that encoder.

But this is not what this thread was meant for.


----------



## Suslik V (Nov 9, 2016)

koala said:


> ...But this is not what this thread was meant for.


Maybe later I could post some BitrateViewer screens (with my thoughts about: constant "bitrate" and what it mean for NVENC, Quck Sync and software x264 from this MP4 test files; why analog TV, frequency and filler data important) or maybe not - CBR is so hard to understand and it was used in the tests of quality. For example, how you can transmit 2000kbit/s if Ethernet is 100Mbit/s itself? How this 100Mbit/s is limited? Maybe it is impossible to stream with this settings at all (CBR for Quck Sync vs CBR for NVENC) and at the same settings one site (provider/host) can accept this bitrate value and other unable - it require to lower your setting or you'll get the frame drop? If settings useless or not equal for compare than this thread goes to nowhere.

You need to say that you targeting the real applications (services) and emulate its work for this tests. Thus overall "quality" may differ from the quality numbers you calculate. The bitrate for CBR is the main restriction and you only assume that encoder controls the bitrate very precisely (and what if it fluctuates?). This is important for streaming. Maybe Service can average your bitrate for last 10 seconds (or for 0.5 sec - who knows) and drop few frames as overheated bandwidth.


----------



## koala (Nov 9, 2016)

Please don't make this an universal "what to consider for streaming" thread. This whole comparison is only to answer the question what the best encoder for a given situation probably is. Considering all other external circumstances are identical: bandwidth, application, stream viewers - which encoder should I choose?

For this question, I don't need to consider anything else besides the encoder. Network or bitrate fluctuation is irrelevant, because if it fluctuates with x264, it fluctuates with NVENC as well. If my upload speed is too narrow for 2500 for x264, it is too narrow for 2500 for NVENC as well. If x264 provides better quality than NVENC, then it does this regardless of network fluctuations and lost packets. So all these external conditions are irrelevant for these tests.

For comparison, you need an equal base for every encoding test and reproducible results. This is what I try to provide. But not an emulation of the whole internet. That you cannot stream with 2500 if your local bandwidth gives only 2000 is a natural law. That your stream looks awful if you lose 30% of your frames due to too low CPU performance is a natural law - I don't need to mention this in these comparisons. And as long as streaming services require CBR, I don't need to consider any other rate control mechanisms for streaming. CBR and the bitrate fluctuation within a given time frame is precisely defined by the h264 standard and well regarded by the Internet backbone providers - I don't need to look deeper into that. I assume all encoders adhere to the standard.


----------



## Xaymar (Nov 9, 2016)

*1280x720x30*
http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x30_2000_Quality.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x30_2000_Balanced.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x30_2000_Speed.mkv

http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x30_2500_Quality.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x30_2500_Balanced.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x30_2500_Speed.mkv

http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x30_3500_Quality.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x30_3500_Balanced.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x30_3500_Speed.mkv

*1280x720x60*
http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x60_2000_Quality.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x60_2000_Balanced.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x60_2000_Speed.mkv

http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x60_2500_Quality.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x60_2500_Balanced.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x60_2500_Speed.mkv

http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x60_3500_Quality.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x60_3500_Balanced.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1280x720x60_3500_Speed.mkv

*1920x1080x30*
http://cdn.xaymar.com/private/2016/11/VCE1414_1920x1080x30_2000_Quality.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1920x1080x30_2000_Balanced.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1920x1080x30_2000_Speed.mkv

http://cdn.xaymar.com/private/2016/11/VCE1414_1920x1080x30_2500_Quality.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1920x1080x30_2500_Balanced.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1920x1080x30_2500_Speed.mkv

http://cdn.xaymar.com/private/2016/11/VCE1414_1920x1080x30_3500_Quality.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1920x1080x30_3500_Balanced.mkv
http://cdn.xaymar.com/private/2016/11/VCE1414_1920x1080x30_3500_Speed.mkv

--

I fixed the color range and profile thing in these recordings. All of them use the correct color space now for the correct input (1280x720 uses .601, 1920x1080 uses .709 as defined by AMF docs).


----------



## Suslik V (Nov 9, 2016)

@Xaymar , can you make 1280x720@30 fps 2000 Partial range videos for me (Quality, Balanced and Speed)? Because, it is full range now and may consume bitrate for this additional bits encoding. Also, I don't know how topic starter can compare extracted frames of different ranges (they were in the base).


----------



## koala (Nov 9, 2016)

@Xaymar The color range is still full, not partial. Intended? MediaInfo says this, and ffprobe as well. This consumes a bit of bandwidth.

Media Player Classic and the "Movie & TV" app from Windows 10 cannot display the colors from your videos correctly. They both black out the darker parts, which means they process the footage as partial, while it is in fact full color range. Ffmpeg, on the other hand, correctly identifies and processes as full range, which you can see by the fact that if you export a frame as png with ffmpeg, the png has correct colors. The same frame displayed with the media players give wrong colors.
Your videos are definitely full range, otherwise the media players would not make the darker parts too dark. If your videos were partial and the media players process them as full, the darker parts would be too light instead of too dark.

The comparison and rating of my script is correct regardless the full range, because ffmpeg correctly takes the color range in account.


----------



## Xaymar (Nov 9, 2016)

koala said:


> @Xaymar The color range is still full, not partial. Intended? MediaInfo says this, and ffprobe as well. This consumes a bit of bandwidth.
> 
> ...
> 
> The comparison and rating of my script is correct regardless the full range, because ffmpeg correctly takes the color range in account.



MPC-HC, VLC and ffmpeg should have no problems with these files, only those that incorrectly read the h264 stream have issues. I can do them over with partial range if needed, but I'd like to see where these rank first.

Edit: Yes, Full Range is intended. It finally works this time as i fixed it in the plugin itself.


----------



## Suslik V (Nov 9, 2016)

I can confirm that qsv, nvidia and x264 videos are partial range, as I see.


----------



## koala (Nov 9, 2016)

Ok, here is the automated comparison including all 3 hardware encoders again. I left every quality setting of the other encoders instead of removing the inferior ones, so you can see what the difference is. AMD-vce is not yet at the quality of the other two hardware encoders.

Visual comparison: if you visually compare the videos near the low-motion reference frame, that is after the hero harvested the plant at the beginning of the video, you definitely see less detail of the snow around and behind him with vce than with all other encoders. And while he's running to the tent, you see the fog of compression artefacts around him with vce, while this fog is much less visible with the others.

1280x720 30 fps:



 

raw tab-delimited source file

1280x720 60 fps:


 

raw tab-delimited source file

1920x1080 30 fps:


 

raw tab-delimited source file


----------



## Suslik V (Nov 9, 2016)

@Xaymar , may it happen that _(height>=7*8*0) _was a typo from AMD staff and actual value is >=7*2*0p?
_______________________________________________________________



koala said:


> ...regardless the full range...


I always thought, that if information was lost - you cannot restore it.


----------



## Xaymar (Nov 9, 2016)

Suslik V said:


> @Xaymar , may it happen that _(height>=7*8*0) _was a typo from AMD staff and actual value is >=7*2*0p?
> _______________________________________________________________
> 
> I always thought, that if information was lost - you cannot restore it.



No, it actually didn't work. It would've been too CPU-intensive too, since it would do the coversion on CPU if I understood Jim in IRC correctly.


----------



## Xaymar (Nov 9, 2016)

Here are files with Partial range, both with and without B-Pictures to represent the full range of AMD hardware capable of encoding. One of them has the VBV Buffer Bug, but I'm not sure if it's decoding or encoding that has the bug - needless to say it will probably rank at the bottom, being the worst of them all.

*1280x720x30, without B-Pictures (VCE1, VCE3.4)*
1 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_2000_Quality_Partial_NoBPictures.mkv
2 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_2000_Balanced_Partial_NoBPictures.mkv
3 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_2500_Balanced_Partial.mkv

4 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_2500_Quality_Partial_NoBPictures.mkv
5 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_2500_Balanced_Partial_NoBPictures.mkv
6 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_2500_Speed_Partial_NoBBictures.mkv

7 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_3500_Quality_Partial_NoBPictures.mkv
8 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_3500_Balanced_Partial_NoBPictures.mkv
9 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_3500_Speed_Partial_NoBPictures.mkv

*1280x720x30, with B-Pictures (VCE2, VCE3)*
1 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_2000_Quality_Partial.mkv
2 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_2000_Balanced_Partial.mkv
3 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_2000_Speed_Partial.mkv

4 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_2500_Quality_Partial.mkv
5 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_2500_Balanced_Partial.mkv
6 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_2500_Speed_Partial.mkv

7 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_3500_Quality_Partial.mkv
8 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_3500_Balanced_Partial.mkv
9 http://cdn.xaymar.com/private/2016/11/VCE1415_1280x720x30_3500_Speed_Partial.mkv

I can provide these for 1280x720x60 and 1920x1080x30 too if needed. It just currently takes way to long to do these manually, it would be ideal if I somehow could tell OBS to only record x seconds using the commandline.


----------



## koala (Nov 10, 2016)

For that kind of doing the same recordings over and over again, I created the script ;)
Here is the rating list of your new videos, where the vce recordings appear.





raw tab-delimited source file


----------



## Suslik V (Nov 10, 2016)

OK. I replaced some AMD files from my tests, 1280x720@30 2000kbit/s, new list:

simple - stream - x264 bitrate=2000 preset=veryfast.mp4
simple - stream - NVENC_Pascal bitrate=2000 preset=highquality.mp4
simple - stream - NVENC_Kepler bitrate=2000 preset=highquality.mp4
simple - stream - QSV_Skylake bitrate=2000 preset=balanced.mp4
simple - stream - QSV_IvyBridge bitrate=2000 preset=balanced.mp4
simple - stream - QSV_Skylake bitrate=2000 preset=quality.mp4
simple - stream - QSV_Skylake bitrate=2000 preset=speed.mp4

VCE1415_1280x720x30_2000_Balanced_Partial.mkv

VCE1415_1280x720x30_2000_Balanced_Partial_NoBPictures.mkv

Now the rating is (almost the same as previous):

*NVENC_Pascal* (2) _best_
*NVENC_Kepler* & *x264 *(3 & 1)
*QSV_IvyBridge *(4)
*QSV_Skylake *(6 & 5)
*AMD_VCE1415_NoBPictures* (9)
*AMD_VCE1415* (8)
All tests results is by my own perception of the footage.
All previous comments are still true. Want to say a few words about AMD encoder (as it arrived last and from the second try).
*
First*, _AMD_VCE1415_NoBPictures (9)_ and _AMD_VCE1415 (8)_ files - results are much better, than first examples I saw (thanks to @Xaymar !!! Well done. Respect to all who helped and points you.). Less blocking, same range and color space. Result close to _simple - stream - QSV_Skylake bitrate=2000 preset=speed.mp4 (7)_ - I didn't place it in the chart table because Quality preset is better for Intel as it was mentioned by me earlier. But temporal artifacts (there I mean visible keyframes insertion - whole image just replaced with same picture but different quality) are make AMD videos out of the list in comparison to other hw based encoders at 1280x720@30 2000.

*Second*, Quality presets for AMD I excluded because of this dammit temporal degradation. When overall quality is better, this bad keyframes insertion completed in timeline makes video even worse than it was for Speed preset (maybe keyframes size or time are bad?). Speed preset has lower overall quality and thus this keyframes appearance are smoother, but still bad (well noticeable at timeline from _00:01:01_ to _00:01:18_, when hero "landing"). So, Speed preset excluded from the test.

*Third*, AMD and B-frames. As I see, there is two versions of recorded footage with B-Pictures (VCE2, VCE3) and without B-Pictures (VCE1, VCE3.4) - last marked as NoBPictures. And this videos differ in quality. And differ a lot!
All videos marked as NoBPictures are better to me than any with B-pictures. NoB-fames videos are less noisy and crisper. That's why I placed NoBPictures videos higher.
Again, Speed preset with B-frames has noticeable flickering at background (see timeline from _00:00:48_ to _00:01:17_, flying hero - clouds left to him, dark side of the portal-tower and ground where hero is landing) thus file excluded from the test.

*Fourth*, Balanced preset for AMD was chosen mainly because most "smooth" temporal quality degradation (there I mean visible keyframes insertion). It is still visible but I think it less noticeable. I may wrong in this part, but Quality preset make it visible even crisper (this is bad). Look at timeline from _00:00:32_ to _00:00:38_ after camera moves and hero "landing" - from _00:01:01_ to _00:01:18 -_ whole image "stutter" when new keyframe inserted, all videos affected.

*Fifth*, Few words to AMD staff. They don't hear this because this is different place ^_^ but now we can compare their engineer's work. Because, earlier it was invisible what they are working on and how good it is. Results are not so good... At least it works, but any other do it better. Height>=780 equal to HD by AMD is weird for me. I thought, 720p is HD. I thought, that more expensive cards are better in all (and they don't).

Conclusion.
NVIDIA Pascal is a king of low bitrate streaming *_*
That it. Nothing to add. Hope, things can change in the future (still, this is too expensive card).

BT.2020, UHDTV, 10-12bit, HEVC,  is far tomorrow. You are limited to use things available right now.


----------



## chummy (Nov 10, 2016)

B-frames have bad quality in high motion for all hardware encoders Quicksync, Nvenc too. Using many of them like OBS does for Quicksync(7bframes) without b-pyramid cause too much blocky artifacting. My Haswell Quicksync when using 0 b-frames in high motion give better quality. B-pyramid is a must to smooth out frames and avoid too much artifacting/blockiness. OBS-Studio using 7 b-frames is too much and without b-pyramid for Quicksync is the biggest culprit of worse quality.


----------



## sam686 (Nov 10, 2016)

Looking at the video through MediaInfo, there are a few differences.

Format Profile: x264 use High profile, but not for UltraFast. AMD VCE also use high profile. If you can get NVENC and QuickSync to use high profile, then they may compress better or improve compression quality. The only reason for limiting to main profile is for older mobile devices mostly for those that are limited to 720p 30fps will only support main or baseline profile.

Matrix Coefficients: NVENC have it set to BT.601, but others just have them undefined or not shown in Mediainfo. This may cause to wrong colors for ffmpeg as they default to bt.709 for 720p and higher when letting ffmpeg convert and output to RGB. ffmpeg allows overriding the decoder color matrix in video files. For x264, a custom option colormatrix=bt470bg or bt470m could be used, but not sure which one to use.

B-Frames: I checked the videos through ffmpeg visualizations. x264 use dynamic number of b-frames up to 3 in the default VeryFast and Medium, which can improve quality. Quicksync use 7 b-frames between p-frame and no dynamic b-frames? No wonder quality is not as good as to me it looks like video have a small motion flicker every 7 or 8 frames, especially the slow moving clouds in the sky at 35 seconds in the video. NVENC use 3, and AMD VCE use 4. None of the hardware encoder have dynamic b-frames. I would like to see QuickSync with 1 or 0 b-frames. EDIT: I was wrong on the number of bframes for both NVENC and AMD VCE.


----------



## koala (Nov 10, 2016)

I used the simple settings of OBS for the analysis, and here you cannot define anything else than the preset. You can give a user-defined option string, but I don't know what options the hardware encoders support. I assume, OBS defaults to main profile for maximum stream compatibility for devices. Perhaps streaming services also require main mode. Beyond that, Tests I conducted for quality-based rate control modes showed that a quality difference between main profile and high profile exist for some videos, but is very small. You will probably not notice it (much).

You can switch to advanced mode and define some more options. For Quicksync, there is only an "Async Depth" option available, from which I don't know what this does. Probably some kind of lookahead or parallel-processing of frames within the encoder.

If you give me explicit settings definitions, or a range of settings to try, I will happily produce as much test videos with that, advanced mode, if you like. But my own knowledge ends here. I tend to not wander too far away from the defaults. I prefer using settings that give 90% performance and runs on 90% of the machines instead of settings that give 100% performance but only work on 10% of the machines.


----------



## Xaymar (Nov 10, 2016)

sam686 said:


> ,,, AMD VCE use 4.



AMD VCE should be using 3, at least according to the log file and debug output.


----------



## sam686 (Nov 11, 2016)

Xaymar said:


> AMD VCE should be using 3, at least according to the log file and debug output.


 My bad, its hard to see the visualizations until I zoom in. It does look like NVENC uses 2 b-frames, or 1 less then AMD VCE.

Another problem was seeking was kindof slow in your MKV video files in both VLC and media player classic with ffdshow. This slow seek problem is gone after I pass it through ffmpeg to re-mux using one of the following command:

```
ffmpeg -i "VCE1415_1280x720x30_3500_Quality_Partial.mkv" -codec copy -movflags faststart "VCE1415_1280x720x30_3500_Quality_Partial_remux.mp4
ffmpeg -i "VCE1415_1280x720x30_3500_Quality_Partial.mkv" -codec copy "VCE1415_1280x720x30_3500_Quality_Partial_remux.mkv"
```


----------



## Xaymar (Nov 11, 2016)

Seeking issue is known, but there is not much I can do about it. It plays fine in MPC-HC and the timestamps are also correctly set from my end. DTS (Decode TimeStamp) is in the same order as the encoder outputs, PTS (Presentation TimeStamp) is in order that the frames come in. I don't know why VLC, WMP and some other players have so much trouble reading the timestamps properly.


----------



## koala (Nov 11, 2016)

I added a documentation and the test script itself here:
test script
documentation
Should be possible to make it work on other machines than my own. It would be much easier, if OBS were able to provide a scriptable interface so you can automate interaction with the GUI, but currently there isn't anything like this.


----------



## Suslik V (Nov 12, 2016)

Just want to add few words, about my viewing experience of AMD VCE videos.
I googled a bit and found term "keyframe pumping", usually it mentioned when quality has degradation in time and improves when IDR inserted. But sometimes it goes vise versa - this what I see in the AMD VCE videos. New IDR frame has lower quality than previous image sequence (maybe few macroblocks before it encoded at higher quality). IDR frame size (quality) probably restricted by max bitrate or so.


----------



## koala (Nov 13, 2016)

Table of bitrate/resolution/fps matrix for easy visual video comparison:

- Color Format: NV12 (OBS default)
- YUV Color Space: 601 (OBS default)
- YUV Color Range: Partial (OBS default)

*x264 "veryfast"*
--- 1280x720 1280x720 1920x1080 1920x1080
2000 30 fps | 60 fps | 30 fps | 60 fps
2500 30 fps | 60 fps | 30 fps | 60 fps
3500 30 fps | 60 fps | 30 fps | 60 fps
5000 30 fps | 60 fps | 30 fps | 60 fps
6000 30 fps | 60 fps | 30 fps | 60 fps



*nvenc "high quality"*
--- 1280x720 1280x720 1920x1080 1920x1080
2000 30 fps | 60 fps | 30 fps | 60 fps
2500 30 fps | 60 fps | 30 fps | 60 fps
3500 30 fps | 60 fps | 30 fps | 60 fps
5000 30 fps | 60 fps | 30 fps | 60 fps
6000 30 fps | 60 fps | 30 fps | 60 fps


*quicksync "quality"*
--- 1280x720 1280x720 1920x1080 1920x1080
2000 30 fps | 60 fps | 30 fps | 60 fps
2500 30 fps | 60 fps | 30 fps | 60 fps
3500 30 fps | 60 fps | 30 fps | 60 fps
5000 30 fps | 60 fps | 30 fps | 60 fps
6000 30 fps | 60 fps | 30 fps | 60 fps


*amd vce "high quality"*
Remark: all vce videos have YUV Color Space: 706, and the 1280x720x60 and 1920x1080x30 have YUV Color Range: full.
--- 1280x720 1280x720 1920x1080 1920x1080
2000 30 fps | 60 fps | 30 fps | 60 fps
2500 30 fps | 60 fps | 30 fps | 60 fps
3500 30 fps | 60 fps | 30 fps | 60 fps


----------



## Faleene (Nov 20, 2016)

Suslik V said:


> Just want to add few words, about my viewing experience of AMD VCE videos.
> I googled a bit and found term "keyframe pumping", usually it mentioned when quality has degradation in time and improves when IDR inserted. But sometimes it goes vise versa - this what I see in the AMD VCE videos. New IDR frame has lower quality than previous image sequence (maybe few macroblocks before it encoded at higher quality). IDR frame size (quality) probably restricted by max bitrate or so.



I've noticed this too. Especially visible at lower bitrate.  The feed basically pulses because the first IDR frame is just awful quality for whatever reason


----------



## koala (May 17, 2017)

Since I still find a continuous flow of downloads of the demo videos for comparison, I added 5000 and 6000 bitrate videos to the above comparison table.

According to Twitch, they now allow streams up to 6000, so this might be of some interest.


----------



## kaloc (Jun 11, 2017)

*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

```
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.

```
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.


----------



## Suslik V (Jun 11, 2017)

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.


----------



## kaloc (Jun 11, 2017)

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.



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 ).


----------



## Suslik V (Aug 22, 2017)

Also, there was an update to obs code: https://github.com/jp9000/obs-studio/commit/e230f77311b639ae1b9805aeec1ee9f392e1b4a1


----------



## Kenshin9977 (May 30, 2018)

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 ?


----------



## koala (May 30, 2018)

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.


----------



## Agamemnus (Feb 25, 2019)

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.
> ...



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/


----------



## Suslik V (Feb 25, 2019)

@Agamemnus by using high resolutions (above Full HD), make sure that you didn't fall into the obs bug: https://obsproject.com/mantis/view.php?id=624 , it less noticeable for default NV12 color format, but image that will be encoded, may change from card to card, from setup to setup (and no matter that you feeding to obs same source).


----------



## Agamemnus (Feb 25, 2019)

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.


----------



## Shad0wZ (Feb 28, 2019)

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


----------



## TryHD (Feb 28, 2019)

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


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


----------



## Agamemnus (Feb 28, 2019)

@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 (Feb 28, 2019)

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 (Feb 28, 2019)

Xaymar said:


> ...These comparisons are done through ffmpeg instead of obs studio, in order to compare actual quality instead of possible human error...


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 (Feb 28, 2019)

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.



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.


----------



## TryHD (Mar 1, 2019)

Xaymar said:


> The video I am using as input can be found on YouTube here


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


----------



## Xaymar (Mar 1, 2019)

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



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. :)


----------



## Toasty27 (Mar 10, 2019)

@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.


----------



## Xaymar (Mar 10, 2019)

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.



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 (Mar 11, 2019)

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*

ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$32 63.647%
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$32 63.645%
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$1 63.464%
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$8 63.463%
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$16 63.458%
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$32 63.458%
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$2 63.456%
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$32 63.451%
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$4 63.450%
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$0 63.422%
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$0 63.422%
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$0 63.390%
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$0 63.376%
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$1 61.866%
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*

ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$0 94.123
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$32$psy$0 94.119
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$0 94.117
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$1 94.077
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$medium$nr$0$psy$0 94.076
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$medium$nr$32$psy$0 94.076
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$32$psy$1 94.076
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$1 94.076
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$medium$nr$16$psy$0 94.074
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$medium$nr$0$psy$1 94.050
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$fast$nr$0$psy$0 94.050
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$medium$nr$16$psy$1 94.048
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$fast$nr$16$psy$0 94.047
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$medium$nr$32$psy$1 94.047
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$fast$nr$32$psy$0 94.046
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*

ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$0 27.558
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$0 27.558
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$32 27.556
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$32 27.556
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$0 27.554
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$0 27.554
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$2 27.554
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$8 27.554
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$16 27.554
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$32 27.553
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$4 27.553
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$1 27.553
ue4-cabininthewoods/60/1920x1080/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$32 27.553
ue4-cabininthewoods/60/1920x1080/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$0 27.527
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*

ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$1 62.543
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$1 62.453
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$32 62.445
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$32 62.445
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$0 62.361
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$0 62.361
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$32 62.343
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$32 62.343
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$32$psy$1 62.321
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$0 62.288
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$0 62.200
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$0 62.200
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$0 62.180
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$32$psy$0 62.105
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*

ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$32$psy$0 94.321
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$0 94.320
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$0 94.320
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$1 94.302
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$1 94.301
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$32$psy$1 94.299
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$16$psy$0 94.293
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$0$psy$0 94.293
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$32$psy$0 94.292
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$16$psy$1 94.274
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$0$psy$1 94.274
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$fast$nr$0$psy$0 94.273
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$fast$nr$16$psy$0 94.272
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$32$psy$1 94.272
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$fast$nr$32$psy$0 94.271
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$fast$nr$0$psy$1 94.250
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$fast$nr$16$psy$1 94.250
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$fast$nr$32$psy$1 94.248
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*

ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$0 27.540
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$0 27.539
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$32$psy$0 27.539
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$0 27.534
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$0 27.534
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$32 27.534
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$32 27.534
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$0$psy$1 27.529
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$32 27.528
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$32 27.528
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$0 27.528
ue4-cabininthewoods/60/1280x720/Partial/6000/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$0 27.528
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$slow$nr$16$psy$1 27.528
ue4-cabininthewoods/60/1280x720/Partial/6000/x264/$bf$-1$preset$medium$nr$0$psy$0 27.527
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/


----------



## Agamemnus (Mar 12, 2019)

That's spectacular stuff @Xaymar !!!


----------



## Toasty27 (Mar 12, 2019)

Interesting results. Just to clarify, is this with the NVENC engine on the 10-series cards, or the 20-series? Also, will you be posting results for the 2500kbps and 3500kbps encodes as well?


----------



## Xaymar (Mar 13, 2019)

Toasty27 said:


> Interesting results. Just to clarify, is this with the NVENC engine on the 10-series cards, or the 20-series? Also, will you be posting results for the 2500kbps and 3500kbps encodes as well?



These results are with the Turing series (20xx). My old tests with the Pascal series (10xx) are still available here, however I did not follow proper upscaling requirements for comparison in those and treated the results as "same resolution input, same resolution encode, same resolution output", which means that the scores aren't correct. I have a Laptop with a 1050 (not a M1050, an actual 1050) that I could use for retesting 10xx, but I don't think it'll be useful - back then it barely managed to beat veryfast, and it's likely to be the same now.

The remaining results are all in a database, I just have to make the API and website work.


----------



## Xaymar (May 11, 2019)

As asked, here are the results for 2.5mbit and 3.5mbit. One thing to note is that at those bitrates, many options have no effect as the compression hits a hard limit with this scene, and would need more bitrate to go with the frames. For example NVEncs Two-Pass either completely fails or reduces quality, which is the exact opposite of what we need. The list will only show VMAF scores, as I don't want to bother with PSNR and SSIM right now.

*3.5mbit 1080p*

ue4-cabininthewoods/60/1920x1080/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$32 55.832
ue4-cabininthewoods/60/1920x1080/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$32 55.811
ue4-cabininthewoods/60/1920x1080/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$0 55.52
ue4-cabininthewoods/60/1920x1080/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$0 55.52
ue4-cabininthewoods/60/1920x1080/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$4 55.059
ue4-cabininthewoods/60/1920x1080/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$32 55.059
ue4-cabininthewoods/60/1920x1080/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$16 55.059
ue4-cabininthewoods/60/1920x1080/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$32 55.059
ue4-cabininthewoods/60/1920x1080/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$1 55.052
ue4-cabininthewoods/60/1920x1080/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$8 55.021
ue4-cabininthewoods/60/1920x1080/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$2 55.02
ue4-cabininthewoods/60/1920x1080/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$0 54.983
ue4-cabininthewoods/60/1920x1080/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$0 54.983
ue4-cabininthewoods/60/1920x1080/Partial/3500/x264/$bf$-1$preset$slow$nr$0$psy$1 52.172
*2.5mbit 1080p*

ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$32 49.593
ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$32 49.593
ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$0 49.168
ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$0 49.168
ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$32 48.24
ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$32 48.24
ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$0 48.115
ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$0 48.115
ue4-cabininthewoods/60/1920x1080/Partial/2500/x264/$bf$-1$preset$slow$nr$0$psy$1 44.965
ue4-cabininthewoods/60/1920x1080/Partial/2500/x264/$bf$-1$preset$slow$nr$16$psy$1 44.825
*3.5mbit 720p*

ue4-cabininthewoods/60/1280x720/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$32 56.661
ue4-cabininthewoods/60/1280x720/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$32 56.661
ue4-cabininthewoods/60/1280x720/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$0 56.546
ue4-cabininthewoods/60/1280x720/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$0 56.546
ue4-cabininthewoods/60/1280x720/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$32 56.464
ue4-cabininthewoods/60/1280x720/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$32 56.464
ue4-cabininthewoods/60/1280x720/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$0 56.365
ue4-cabininthewoods/60/1280x720/Partial/3500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$0 56.365
ue4-cabininthewoods/60/1280x720/Partial/3500/x264/$bf$-1$preset$slow$nr$0$psy$1 55.908
ue4-cabininthewoods/60/1280x720/Partial/3500/x264/$bf$-1$preset$slow$nr$16$psy$1 55.826
*2.5mbit 720p*

ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$32 52.026
ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$32 52.026
ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$0$saq$1$taq$1$rcla$0 51.892
ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$0$saq$1$taq$1$rcla$0 51.892
ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$32 51.554
ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$32 51.554
ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$0$brm$2$saq$1$taq$1$rcla$0 51.445
ue4-cabininthewoods/60/1920x1080/Partial/2500/nve264/$bf$4$rc$cbr_hq$2p$1$brm$2$saq$1$taq$1$rcla$0 51.445
ue4-cabininthewoods/60/1920x1080/Partial/2500/x264/$bf$-1$preset$slow$nr$0$psy$1 50.672
ue4-cabininthewoods/60/1920x1080/Partial/2500/x264/$bf$-1$preset$slow$nr$16$psy$1 50.587
So with all of this data, something becomes clearer:

NVEnc ends up better in VMAF than x264 if the bitrate is less than the amount needed for x264 to create a clean compression. That means that NVEnc will do more drastic compression than x264 is willing to do in any profile.
However if the bitrate exceeds the necessary bitrate, x264 will jump ahead and dominate the field in VMAF. This can be seen in the original post, where x264 slow was at the top of 720p 6.0mbit.
NVEnc Two-Pass has zero impact on quality if the bitrate is too restrictive, and only takes away GPU time at that point. It might even cause lower quality, so watch out for that one.
I can't confirm or deny if setting B-Frames to 2 improves quality further. I know that B-Frame 1 is below x264, and B-Frame 4 is above x264 in bitrate restricted situations, so it really just comes down to how much GPU time you have available, and how much bitrate.


----------



## Xaymar (Jul 28, 2019)

I've finally gotten around to writing a web page for the encoding data, so you can now filter by file, resolution, framerate and bitrate! Also started comparing quality on additional files, and might include AMD Vega in a future update to the data: https://xaymar.com/ves/


----------



## koenigseggrs25 (Jun 26, 2020)

Ok, first of all, this is a lot to ask, but:

I'm running a Nvidia GTX 960M, with 8gb of RAM and a Intel i5-6300HQ, should I use NVENC H.264 or QSV H.264. Yes, my laptop is old, and I play CPU demanding games (eg. Forza Horizon 4), and was wondering for recording which one I should use, and which preset. (x264 is not an option, my computer will probably kill itself). I record at 30fps, downscaled to 720p. As well, what should my bitrate be?


----------

