Dynamic bitrate and reconnecting

A stream keeps going through a slow or dropped connection: its bitrate follows what your upload can carry, and a lost connection is retried on its own. Both are always on, for every stream output, in every app.

Dynamic bitrate

When the connection cannot keep up (media waits in the send queue for more than a fifth of a second for half a second or longer), the stream’s bitrate steps down to what is actually getting through, at most halving in one step, so the backlog drains. A short burst, such as a keyframe, does not count.

Once the connection has been clean for 20 seconds, the bitrate steps back up by a tenth of the bitrate you set, one step at a time, and never above it. After a step down the app remembers what the connection carried and stops short of it for a while, rather than climbing straight back into the same congestion.

Reconnecting

If the connection drops, the stream reconnects on its own: the first retry comes after about a second, and each later one waits about twice as long, up to 30 seconds, until it is back or you stop it. The output row shows reconnecting meanwhile, and the stream starts again cleanly when it is back.

Watching it

Hover the summary at the right of the status bar: for the primary stream it shows the current target bitrate (tgt), how congested the connection is (cong) and the number of reconnects (rc); see The status bar readouts. An output’s hover card warns about a reconnect in the last minute (see Health: hover cards and the summary).