OBS video quality roundup

[manikyath]

notes before i get started:

1. the videos embedded below arent made to any kind of standard, it's literally just the output of OBS tossed on youtube. i dont have the skill or budget to do any better, or to fake results.

2. there's boops and bops in the videos here and there since i didnt bother turning off notifications for things, consider it a more realistic scenario there was stuff running in the background

3. yes, i know one of the videos is lacking audio, i dont care, audio is not the topic at hand.

4. no, i'm not claiming to be anywhere near a "porfeshunel stremr" but i seem to be one of the rare finds on the forum that know these settings actually matter...

5. as a standard/measuring stick here: sevadus (who should be known by the community by now) streams at 900p 60fps, at 3500kbps.

6. i know none of these recordings look anywhere near good, they're meant to show the flaws in recording methods, not their capabilities.

7. for the love of god check the videos for longer than 20 seconds, the first scene in heaven benchmark is an encoding nightmare.

 

so... that out the way, lets get started with my reasons and methods:

i got a bit fed up with people around the forum (purposely not naming names, if you think something is aimed to you, good for you ) claiming the settings dont matter, or claim superiority of one method over another seemingly without even doing any testing on the topic.

 

which brings me to the main reason and methods: i do this testing to show an example how to prove a point, and to have something to refer to when calling people idiots in the future.

the methods are pretty simple: i standardized to two randomly picked bitrates, and went trough a roundup of several settings at the two bitrates, across h264 cpu encoding, intel quicksync, and nvidia's nvenc.

my bitrates of choice were 2500kbps, because that should be more than plenty for 720p 30FPS (which was the resolution and framerate of choice. note the 5th note at the top)

and offcourse 1000kbps because that's my favourite bitrate to torture test streaming setups with  when a setup is done right it should be "#goodenough" for 720p30 in all but the most intense scenarios like the first scene of heaven which is just terrible in general

brings us to the final part: my scenario of choice was heaven benchmark, because it is made to be consistent, and because no settings were changed between runs, it's basicly a repeat of the exact same "piece of gameplay" for the eyes of OBS.

 

my scene in OBS is nothing but a window capture for heaven benchmark.

 

brings us to the first comparison i want to get out the way quickly, the very low end of h264 i'd like to call "oh boy it matters".

both these tests were only done at 2500kbps for the sake of my eyes, and yours. both these tests had next to no difference in cpu usage, but a pretty significant change in output quality. videos will be compared in "pairs" to make it not just a bunch of videos, and have at least some form of structure.

this is also the point i will refer to when people say the settings dont matter.

(if someone knows a way to put videos side by side on the forum, please PM me )

 

-------------------

brings us to the next pair: h264 with fast and slow settings. i should mention both past examples were about 20% cpu usage, fast is ~40-50% usage on a 4790k, with slow coming in at a rather painful 50-80% usage. (which is why prefer to recommend a two pc setup for livestreamers that want to toss some serious dough) at this point the main differences are less grain, and things like UI text catching up quicker instead of staying garbled for a while. (you'll see this point return later...)

-------------------

now, you may say "oh, but those both look very good already, why would you do effort to have more?" well.. because this is 720p30, and there's this australian livestreamer that used to have 1080p30 somewhat manageable on 900kbps, which is exactly what we're aiming at now: 720p30, at 1000kbps, because i dont have a watercooled 4770k at my disposal.

we repeat the fast and slow presets, to have one consistency to the last pair. an especially interesting scene here is that while it's a shitshow to have pretty much anything move at 1000kbps, the slow preset manages to make the spikes on the dragon stand out more than fast manages. as well as the first scene being slightly less of a horror show, for as much as anything can be not painful at 1000kbps.

---------------

brings us to the true shitshow, and the reason i finally decided to put this effort in: quicksync.

TLDR: quicksync is only good because every desktop intel processor has an igpu, and you're most likely not using it for anything else. (not that you should use it here...)

quicksync was tested with default settings at both 2500kbps, and 1000kbps (people who are extremely sensitive to pixelation, please look away)

something to look for here is that according to intel, walls appareantly move  a positive note however is that the 2500kbps test went trough the dragon scenes quite smoothly compared to the lower h264 tests, albeit being extremely blurry in the background. intel's move seems to be focussing more resources on what's actually important, sometimes with rather hilareous results.

quick note: the 1000kbps test stutters often, that's not my setup, that's quicksync being a disaster. i'd tell you the scene number, but basicly nothing is readable in the specific scene

----------------

finally the last pair of benchmarks: nvenc, which wasnt as horrible as i expected to be honest.

scene 6, 9, and 10 deserve great mentions for the 2500kbps test, because they are basicly spotless.

however, the 1000kbps test shows nvenc's fault: it is one thing and one thing only, if there's too much to process compared to the bitrate available, it just dunks out overall, with scene 9 showing really well how when nvenc dunks out, it's all over the thing you're looking at, as much as its all over the background, with no way of "upgrading" your setup to get rid of the issue. (which is what the cpu h264 people do with their 6-core stream PCs )

-------------

which brings us to the conclusion:

intel quicksync has its strengths, but if you're not on an extreme budget where h264 is just not gonna happen, and somehow still have plenty of bandwidth.. it's a bust.

nvenc is honestly impressive, but only in very specific (high-bitrate) situations, the moment you try to push more data trough a lower bitrate, it just dunks out, with nothing to be done, even your fancy titan XP will not help you out here.

 

h264... is basicly a "brute force" way of attacking the problem, nothing like quicksync focussing on what it thinks is important, not the optimization of nvenc where it honestly wasnt an impact on performance (i had heaven vsnynced, with some scenes using as little as 60% gpu load, others as much as 90%, with nvenc not impeding on game performance. +1 to nvididerp.)

but the great advantage of h264 is the flexibility of the situation: fast is the "ideal" preset IMO. below fast you have diminishing returns on quality (with ultrafast-veryfast not being a performance difference, but night and day quality difference) and beyond fast you get diminishing returns on efficiency as you're basicly "brute forcing" your way into more quality. but if you have the cpu horses to strap to it anyways, go right ahead and squeeze out that little extra.

[Spork829]

These are very interesting! NVENC has always been the way to go for me, because I never stream at lower than 2000 kbps so it always has enough bandwidth to do its job. h264 performance was interesting as well. I always keep mine on veryfast, but fast does seem more ideal (however I'm using x264, don't actually know what the different between that and h264 are). Having never tried it out myself, I really thought Quick Sync was better than that! I'm really surprised at just how poorly that performs, even up at 2500kbps. Thank you for doing this.

[manikyath]

4 minutes ago, Spork829 said:

These are very interesting! NVENC has always been the way to go for me, because I never stream at lower than 2000 kbps so it always has enough bandwidth to do its job. h264 performance was interesting as well. I always keep mine on veryfast, but fast does seem more ideal (however I'm using x264, don't actually know what the different between that and h264 are). Having never tried it out myself, I really thought Quick Sync was better than that! I'm really surprised at just how poorly that performs, even up at 2500kbps. Thank you for doing this.

x264 is the name of an opensource h264 encoder (AKA the oone used in OBS most likely) i should probably change that in the OP to be more accurate to what naming should be.

 

not that i really care to have this be very professional

[Spork829]

2 minutes ago, manikyath said:

x264 is the name of an opensource h264 encoder (AKA the oone used in OBS most likely) i should probably change that in the OP to be more accurate to what naming should be.

 

not that i really care to have this be very professional

Ah okay, never knew that.