To make their software compatible with all streaming services, software editors offer a default streaming/output configuration with the lowest common denominator, and for such shallow quality.
Encoding is like sex: faster is not better. The slowest you encode and transmit, the better quality you will get, as you provide more room for the encoder to “ look ahead,” meaning it can look at what's coming before encoding to optimize encoding. You should care about latency only if interaction matters more than video quality. Nobody knows streaming is late when there is no real-time interaction except for the broadcaster.
Available resources (CPU/GPU), slow encoding, long keyframe period, and network buffer are way more important than resolution and bitrate, which are usually only the settings you are recommended to change by streaming services for their comfort (less transcoding complexity for them means less cost)
Use a different computer for streaming and operations (for a DJ or a video game player, for example) whenever you can
Your streaming computer must be dedicated to that for the time of your live stream and recording. More than that, you better quit all other applications as they use your CPU and GPU, leading to artifacts in your video output. If you can not, streamline operations on your single device, so your other application doesn't affect too much CPU/GPU. Consider GPU transcoding below if you have multiple applications open on your streaming desktop or a HARDWARE video capture device.
Powerful CPU and/or hardware-encoding capture card as a source?
The main parameter to change if you have a powerful CPU computer or device is to choose CPU x264 encoding as it provides the most finetuning for quality. In OBS > output, set output mode to advanced. Set x264 for the encoder, fixed CPU usage preset to slower. If your CPU is not powerful enough, you might choose slow. If your CPU is not powerful enough (check your CPU usage while transcoding, it should never be over 90%) to transcode with slow mode; you better use GPU/hardware encoder, see below. Set 6 to 10s for keyframe interval in seconds; set profile to High (this one is the most demanding on your CPU); select the b-frames checkbox if available (depending on your GPU);. See below for resolutions and bitrates.
Weak CPU but strong GPU or a single PC for operation and streaming?
Make sure your CPU is not strong enough, as you will always get better quality with the CPU settings described above. The hardware encoder is usually preconfigured on a medium preset, which means you will have lower quality than x264 slow or slower presets. But it can significantly improve your operations if your PC is not used for streaming only.
In OBS > output, set output mode to advanced. Set hardware (this can be different values according to your PC, such as GPU, NVENC, Intel Quicksync, Apple VT H264 Hardware encoder, etc.) for the encoder. Set 6 to 10s for keyframe interval in seconds. Set profile to High (this one is the most demanding on your GPU). Tick the B frames checkbox or set the maximum number of b-frames to 4 if available (depending on your GPU). See below for resolutions and bitrates.
Wired network, check UPLOAD speed and variability in speed tests, not download speed and peak bandwidth.
Don't use WiFi unless you have to. And if so, please use the latest generations like WiFi 6x which provides better bandwidth, reliability, and better handling of streaming. If you don't care about latency, both OBS and Xplit give some settings to reduce the variability of your connection to your streaming service with stream delay (which increases the delay between streaming and viewing). 6s is a good start, but reduce it if you are on fiber (or don't use it if your connection is very reliable between your PC and your streaming service), and maybe increase it on 4G or ADSL up to 10s. Finally, check if your streaming services offer a region-specific publishing URL (RTMP URL), and choose the closest one (by geography or by latency if you know how to ping a domain name)
Resolution, bitrates, and framerates: interoperability vs. quality
The most efficient rate control is ABR, as it provides more bits when required by video beyond the bitrate you set. Unfortunately, most streaming services require either CBR or VBR, making their operations more straightforward. If your service has no such requirement, go for ABR. If not, and if your upload bandwidth is inferior to 8 Mbps, please set it to VBR with a bitrate of 80% of your upload bandwidth and a maximum bitrate of 95% of your upload bandwidth.
1080p is 225% the number of pixels of 720p. So if you consider 1080p, you might think that less is more, as bitrate has to be more than doubled to keep the same video quality. So if you have limited upload bandwidth, you might want to stick to 720p 4 Mbps rather than 1080p 6 Mbps, for example. 8 Mbps is a good value for most use cases if setting 1080p resolution. If your service recommends a lower maximum and is strict about it, test the settings described here, and lower them to the service’s recommendations if that's a no-go. 60 fps is the standard nowadays, so unless you cannot provide a 60 fps source or have enough resources to stream at 60 fps (that's not the most demanding setting, it's just adding a few % to your CPU/GPU usage), you better stick to it.
Youtube HLS - the new best standard for YouTube
Recent versions of OBS introduced many new streaming services that you can get through the “Show all...” selection. Here you're going to find the new YouTube HLS output that few people know. What is it? HLS is a standard introduced by Apple more than a decade ago and is now widely used to transmit every single frame of any streaming video to ensure the playback can be as good as standard TV broadcasts or Netflix. By using HLS, you make sure none of your transmission will get lost on the network between your computer and YouTube. This is a HUGE improvement over RTMP(S) as it was reserved for professionals such as (my)DJing TV until 2021.
Recording, why is it important?
Live transmission protocols provoke network packet losses (if you don't use HLS). You might not know what it is, but you know the consequence: video freezing, parts of the picture with defaults, audio drops, and other inconveniences. This is inherent to transmission with RTMP(S) protocol. You wouldn’t want to record locally because your live stream is not worth being watched later. In the event of your live stream being available as a replay (catchup) or available in some VOD catalog or TV channel scheduling (e.g., promotion in bars and music venues with DJing TV) at a later date, you better record it so you can use this version, without default for these purposes. It's good practice to save locally. Set mp4 as a recording format as this is the universal one. If you follow our guidelines above, you can keep “use stream encoder” in OBS as an encoder. If you have enough power on your computer, you can choose ABR as rate control and record at a higher bitrate (15 Mbps for 1080p, 25 Mbps for 4k) by selecting the same other settings as for your live streaming for everything else (see above)
What if latency does matter?
If latency matters, forget everything about quality, and you shouldn't use RTMP protocol but rather WebRTC or SRT. Unfortunately, very few (mainly free) services support these technologies AND large audiences right now (this can be circumvented with services such as Streamyard or Restream). Except that, if latency matters and you still need to use RTMP output, please apply those settings (x264 CPU encoder only) that will degrade quality but also decrease end-to-end delays:
Profile: baseline (main for Youtube)
Keyframe interval: 1
CPU usage: ultrafast (fast for Youtube)
x264 options: bframes=0 scenecut=0
How about DJing.com streaming services?
- DJing.com streaming services are made with top quality in mind for publishers and viewers. They provide unmatched video quality for standard streaming viewers as it doesn't forbid any of the recommendations above
- WebRTC (and soon SRT) subsecond streaming is available for interaction, with up to 500 Kbps audio streaming (with compatible streaming software)
- Both can be run at once from the very same software (OBS, XSplit, or directly from the browser)
- Publisher can submit his local recording after live stream for high quality rebroadcasting