Basic Concepts

Quality = bandwidth * compression

It’s a sordid state of affairs to see how many people on the internet don’t get this, so let’s get it out of the way straight up.

The video on your screen is a collection of data displayed as pixels a certain number of times for a time. If you’re resolution is 1080p, colour is 10-bit and a frame rate of 25 then:

(10-bit x 3 colour channels) @ 1920×1080 @ 25 fps = 185 MiB/s, or 667 GiB/h.

185MiB/s as the bitrate unit in OBS is 1,515,520 kb/s which is well beyond what our ISPs provide these days.

In order to put a “moving screen”, “motion picture” or let’s just call it “video” into a file it needs to be reasonably packaged. This is where compression comes in.

Take this sentence:
“Jason Stefanac is a seriously good looking gentleman. Ask yourself this, did he or did he not attract numerous women to him over the weekend?”

This is an example of “Lossless Compression”:
“BOSL is a seriously good looking g¢. Ask yourself this, did he or did he not attract n╝ w¢ to him over the wø?”
The standard/format for this compression will state that:

• BOSL = Jason Stefanac
• g¢ = gentleman
• n╝ = numerous
• w¢ = women
• wø = weekend

Any decoder which supports this format can turn the compressed phrase into the original without exception. If they can’t, then they do not support the format. This is what happens when you write an essay and save it as a Zip file. Any Zip decompressor can take it and show you the original.

This is an example of “Lossy Compression”:
“BoslBe1HawtManC’monDidYaCHowManySxsHeGotOnWkend?”

The codec for this compression will state many rules on how to compress and decompress, but ultimately, if you pretend the codec is a teenager on Facebook, you can get the message from the compressed version but never be sure that you have the original.

Now note this, you can GUESS how to decipher the compressed message, but you CAN NEVER get the original back. It is now gone forever. If you were to decompress the short version to a long version, then compress it again, the new short version will be slightly different again, and each time you compress and decompress the message, you will lose something, until eventually it becomes static or “white noise”.

Basically, lossy compression will remove SOME quality from the original, while lossless does not. Each time you compress/convert/recode with lossy compression you are losing more and more quality. This important fact will come into play later.

So, say you have persons A and B. A has a bitrate of 120 kb/s and can compress a video to half it’s original, while person B has a bitrate of only 80 kb/s but can compress a video to one third of it’s original.
Person A’s quality = 120kb/s divided by ½ = 240kb/s effective decompressed video.
Person B’s quality = 80kb/s divided by 1/3rd = 240kb/s effective decompressed video.

Even though person B has slower bandwidth, they are still fitting the same quality into it by using a stronger method of compression.

The moral of the story is, better compression fits more quality into the bandwidth.

Here’s a look at some quality benchmarking some guy did. You can see screenshots of the results from a link in his post: https://obsproject.com/forum/threads/obs-benchmarking-1080p-60fps-cpu-vs-nvenc-vs-quick-sync.15963/

He’s testing what has been known for a while now, that using your CPU to power x264 encoding gives you the best quality for bandwidth, while offloading to NVENC or Quick Sync will free up some CPU if you need it, however because they don’t compress as effectively as the CPU, there is a drop in quality.

The trick is finding the sweet spot. Encoders today are capable of H264 compression at such a powerful setting that the resultant 1080p video is encoded at a rate less than 1FPS. Meaning a 30FPS video that goes for one minute, would take over half an hour to encode. This is fine if you’re working with small clips and saving them to your HDD or uploading to YouTube. However for streaming this will not help you. You need to be able to encode as fast as you want the viewer to watch live. Looking at the table in the link above, you can see some of the quality settings caused “stuttering” and you’ll notice that the CPU usage for those was pretty maxed out. It means that the program had to drop some frames from the video so that the CPU had time to keep up with the encoding. The sweet spot is where your hardware is using as much power as it can to encode the video, without actually causing lag in the game or needing to drop frames. The most encoding power you can get, means the most quality goes into whatever bandwidth you’re putting out.

Regarding saving your recordings and possibly uploading them to YouTube later, in principle here, we don’t have bandwidth restrictions. It’s possible that you do however have Hard Disk restrictions, but if you have a dedicated HDD for recording that won’t be a problem. HotS gameplay lossless in 1080p @ 30fps uses about 10-20 MiB/s and if you up that to 60fps you’ll see double that, which isn’t too bad.

So considering this, we should record lossless. This means that you are actually capturing the original footage, so that it will be played back identical to how it happened on the screen. There’s more to consider, if you want to edit the videos, don’t encode them first, use the lossless versions. Also, encode to a YouTube supported format so that YT won’t transcode yet again. Worst case scenario is this:
1 – Record original footage in lossy H264 (NVENC, QS or x264 preset) <- 1 encode.
2 – Transcode to save space <- Now 2 encodes.
3 – Edit and splice together clips, then export video <- 3 encodes.
4 – Upload to YouTube and they encode to their format <- 4 encodes in total.

Remember that each time this happens, you lose a bit of quality. A great recording can look kinda crappy by the time all this happens. What I do is:
1 – Record original footage lossless. <- 0 encodes.
2 – Merge videos together with AVIDemux <- 0 encodes.
3 – Encode result with Handbrake top settings in YT compatible format <- 1 encode.
4 – Upload to YouTube, doesn’t get processed because it’s already compatible <- Still only 1 encode.

So that’s how planning ahead affects quality. Another thing to consider when providing video content is the data rate. A large data rate means that the files will take up more space on your disk, and also, that the viewer will have to download more to watch your video. In most cases, people wont have issues with this. However some viewers have terrible internet, while others have periods where their housemates or family have a Netflix party or something, possibly limiting the data rate to their own computer. If your video could be 100MB or 50MB at the same quality, then the 50MB option is undoubtedly better, because the viewer needs less buffering to play it. Also, YouTube might downscale their resolution from 1080p to 720p (half the quality) to accommodate the viewer’s bottleneck, meaning the viewer doesn’t get to see the best possible picture just because there was too much data for their internet at the time!