Recommended thresholds

The thresholds decide when it switches your scene. Too high and it takes you off shot at every traffic light; too low and your audience watches a frozen stream before it reacts.

The stock values

A freshly created server arrives like this:

Setting	Value	What it does
Low bitrate	900 kbps	Below this, it jumps to your low-bitrate scene
High RTT	1500 ms	Above this latency, it also jumps to the low-bitrate one
No signal	450 kbps	Below this, it jumps to your offline scene
Retries	5	Bad checks in a row before it moves anything

They fit a stream of around 3 Mbps, which is what comes out of a phone on the street with a conservative setup. If that’s what you stream at, don’t touch anything.

If you stream at more

The thresholds go with your bitrate, not with your plan’s cap. The stock ratio — low bitrate at a third of what you stream, offline at half of that — holds up well:

You stream at…	Low bitrate	Offline	High RTT
3,000 kbps	900 kbps	450 kbps	1500 ms
6,000 kbps	1,800 kbps	900 kbps	1500 ms
9,000 kbps	2,700 kbps	1,350 kbps	1500 ms

It’s a starting point, not gospel: the only numbers that come from Enhanced IRL are the stock ones. Adjust with what you see in your own streams.

Measure before you decide

Look at the Bitrate the dashboard shows on a normal stream of yours, walking where you usually walk. That’s your real bitrate, and it’s usually lower than the one you set in the encoder. Work out your thresholds from that number.

Each threshold, one by one

Low bitrate. The one you’ll touch most. If it switches scene constantly and the picture looked perfectly fine, lower it. If you stay on the normal scene with the picture a block of pixels, raise it.

High RTT. It’s latency, not throughput: it doesn’t depend on how much you stream at, so 1500 ms works for all three cases in the table. It’s there to catch the network that’s still sending data but with a huge delay — typical of a saturated cell. If you stream with high latency on purpose (bonding with a lot of buffer), raise it before you write it off as broken.

Offline. Put it clearly below the low-bitrate one: it’s the “this isn’t a stream any more, it’s a photo”. If you leave it at 0, it only fires when the bitrate hits exactly zero, and you’re late: with the feed dying at 100 kbps your audience is still watching the main scene frozen.

Retries. Only adjustable on the Cloud OBS, between 1 and 20. More retries = fewer false switches, but it takes longer to react. Fewer = it reacts fast and jumps at any bump. If you’re in a car or on a bike, raise them; if you’re walking somewhere with stable coverage, the stock 5 is fine.

The mistake that hurts most

The scenes have to exist with the exact name

You can have perfect thresholds: if the assigned scene doesn’t exist in OBS with that exact name, there’s nowhere to switch to and nothing happens. It happens the moment you rename a scene, delete it or change your stream key’s name. After you touch names in OBS, go back to the tab, check the three scenes and save.

How to check it in 2 minutes

1. Start streaming with your usual setup.
2. Kill your phone’s data or take the encoder somewhere with no coverage.
3. You should see: the low bitrate scene first, the offline scene after.
4. Bring the signal back. It has to return to the normal scene on its own.
5. If it takes too long to react, lower the retries or raise the low-bitrate threshold. If it jumps for no reason, the other way round.

Next step

• How it works — what gets watched and in what order.
• Setting it up on a Cloud OBS · Setting it up on your OBS — where these numbers get touched.
• Unstable bitrate — if the problem is the feed, not the threshold.