Recommended Bitrate, Resolution, and Encoder Settings by Upload Speed

The order most people pick settings in is backwards. They choose 1080p60 because it looks good on paper, then wonder why the stream drops frames every few minutes. The setting that actually constrains everything else is your real, measured upload speed — not the number your ISP advertises, which is almost always a download figure.

Run an actual speed test (fast.com is a fine one) right before you configure anything, on the same network and at the same time of day you’ll be streaming. Then work forward from that number to a resolution and bitrate, not the other way around.

The rule of thumb — the same one OBS’s own setup guidance uses — is that your upload speed should be roughly 1.5x your total stream bitrate (video plus audio). Streaming at exactly your measured max leaves zero margin for network jitter, other traffic on the connection, or protocol overhead, and the first dropped packet becomes a dropped frame.

These are the same base numbers behind CastFork’s bitrate calculator — a band, not one precise number, because the right value within it depends on your content (fast motion needs more bitrate than a static talking-head shot at the same resolution).

Those numbers are H.264 baseline. If your encoder supports H.265 (HEVC) or AV1, you can reach similar visual quality at a lower bitrate — the calculator uses conservative real-time-encode estimates of roughly 40% smaller for H.265 and 50% smaller for AV1, below the higher savings sometimes quoted for slower offline encodes, since live encoding trades some efficiency for speed. H.264 remains the safest default for compatibility: it’s what every destination platform and encoder accepts without question. H.265/AV1 are worth it mainly when your upload speed is the tight constraint and your encoder/hardware genuinely supports them well.

15 Mbps upload, H.264: Your safe total bitrate ceiling (upload ÷ 1.5) is about 10,000 kbps. That comfortably covers 1080p30 at the recommended 4,500 kbps + 128 kbps audio, with real headroom left over — this is a "safe" verdict, not a "tight" one.

8 Mbps upload, H.264: Ceiling is about 5,300 kbps. 1080p30 at 4,500 kbps + audio lands right at the edge — workable but tight, with no real margin. Dropping to 720p30 at 2,500 kbps instead leaves comfortable headroom and is usually the better call than fighting for every last pixel of resolution.

5 Mbps upload, H.265: Ceiling is about 3,300 kbps. 720p30 in H.264 terms recommends 2,500 kbps; at H.265’s roughly 40% saving that’s about 1,500 kbps of video, comfortably inside the ceiling — a resolution that would be tight in H.264 becomes safe once the codec is more efficient.

If you have to compromise, resolution is usually the safer thing to give up first. 720p60 tends to read as smoother and more watchable than 1080p30 for anything with real motion — gameplay, sports, a live demo — because motion smoothness is what a low framerate visibly breaks, while a slightly softer image at 720p is much less noticeable to most viewers on a phone or a laptop screen. The exception is content that’s mostly static — a talking-head interview, a slide-based presentation — where resolution matters more than framerate and 1080p30 is the better trade.

A software encoder like x264 also has a speed/quality preset (from "ultrafast" to "veryslow" in OBS). A slower preset squeezes more visual quality out of the same bitrate, at the cost of more CPU work per frame — push it too far past what your processor can keep up with in real time, and you get encoding-side dropped frames that have nothing to do with your network at all. If you’re already running other demanding software, a faster preset with a slightly higher bitrate is usually more reliable than a slow preset your CPU can’t sustain.

A calculator can tell you what your connection can sustain on paper. It can’t tell you whether your wifi is shared with three other devices streaming video at the same time, or whether your ISP throttles upload during peak hours. If you’re getting drops despite settings that should work, that’s the next place to look — see the article on reading stream health and dropped frames for how to tell a settings problem from a network problem. Multistreaming destinations don’t multiply this math, either: CastFork relays one encoded feed to every enabled destination on multistreaming, from a single upload, and Studio’s browser-based production uses the same audio spec this article assumes.