To make their software compatible with all streaming services, software editors offer a default streaming/output configuration which is actually the lowest common denominator, and for such very low quality
Encoding is like sex: faster is not better. Actually the slowest you encode and transmit, the better quality you gonna 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, 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 own comfort (less transcoding complexity for them means less cost)
Use a different computer for streaming and for operations (for a DJ or a video game player for example)
Your streaming computer must be dedicated to that, for the time of your live stream and/or recording. More than that, you better quit all other applications as they use your CPU and GPU, and that can lead to artifacts in your video output. If you can not, make sure to 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
Powerful CPU and/or hardware-encoding capture card as 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 encoder, set 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, then you better use GPU/hardware encoder, see below. Set 6 for keyframe interval in seconds. Set profile to High (this one is the most demanding on your CPU). 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 CPU settings described above. Hardware encoder are usually preconfigured on medium preset, which means that you will have lower quality than x264 slow or slower presets. But it can greatly 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 you PC, such as GPU, NVENC, Intel Quicksync, Apple VT H264 Hardware encoder, etc) for encoder. Set 6 for keyframe interval in seconds. Set profile to High (this one is the most demanding on your GPU). Tick the B frames checkbox. See below for resolutions and bitrates
Wired network, check upload speed and variability in speedtests, not download speed and peak bandwidth
Don't use WiFi, unless you really have to. And if so, please use latest generations like WiFi 6x which provide better bandwidth, better reliability, better handling of streaming. If you don't care about latency, Both OBS and Xplit provide some settings to reduce the variability of your connection to your streaming service with stream delay (which of course increase delay between streaming and viewing). 6s is a good start, but reduce it if you are on fiber (or don't use it at all if uour connection is very reliable between your PC and your streaming service), and maybe increase it on 4G. Finally check if your streaming services offer 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, as it makes their operations easier. If your service has no such requirement, go for ABR. If not, just follow the recommendations of the service.
1080p is 225% the number of pixels of 720p. So if you consider 1080p, you might think about 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 services recmmendations if that's a no-go. 60 fps is the standard nowadays, so unless you cannot provide 60 fps source or have enough resources to stream at 60 fps (that's not the most demanding setting), you better stick to it.
Recording, why is it important ?
Live transmission protocols provoke network packet losses. You might not know what it is, but you know what's the consequence: video freezing, parts of the picture with defaults, audio drops and other inconvenience. This is inherent to transmission with RTMP protocol. The only reason you wouldn't want to record locally is that your live stream is not worth being watched later. In the event of your live stream being available as replay (catchup) or available in some VOD catalogue or TV channel scheduling (eg: 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 most universal one. If you follow our guidelines above, you can keep as an encoder “use stream encoder” in OBS. 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 choosing 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 (especially free) services provide support for 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) which will degrade quality:
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 sotware (OBS, XSplit, or directly from the browser)
- Publisher can submit his local recording after live stream for high quality rebroadcasting