IRL Stream Keeps Dropping? How to Stay Live When Your Signal Fails
October 09, 2026 · 11 min read
Table of Contents
If your IRL stream keeps disconnecting, the reliable fix is to stop sending it straight to the platform. Send it to a server first, let OBS stream from there to Twitch, YouTube or another platform, and use automatic scene switching to show a fallback scene while your phone is offline.
Mobile networks are never fully predictable, so a drop will happen sooner or later. This guide explains what it does to a direct stream and which measures keep you live.
What happens when your IRL stream drops
When you stream directly from your phone or encoder to a platform, that one connection is the entire stream. If it breaks, the platform stops receiving video. Viewers see a frozen picture or an offline channel, and the broadcast ends. When your signal comes back, you start a new broadcast, and the viewers who left in the meantime have to find their way back. Your recording on the platform is split into several parts as well.
Platforms offer a little tolerance. Twitch, for example, has a feature called Disconnect Protection. It shows viewers a message for up to 90 seconds while you reconnect and keeps the recorded VOD continuous. If you do not reconnect within 90 seconds, the stream ends as normal. Twitch lists OBS Studio, Streamlabs OBS, XSplit, Twitch Studio and its mobile app as supported encoders and recommends a quick test with your own setup.
That helps with short blips. In a tunnel or dead zone, 90 seconds pass quickly, and other platforms may behave differently.
Why IRL streams disconnect
Most drops come from a handful of causes:
- Dead zones: tunnels, underpasses, thick walls, basements and rural stretches where the signal is weak or gone.
- Cell handovers: when you move by car, train or bike, your phone switches between cell towers. This can cause short interruptions or latency spikes.
- Overloaded cells at events: in a crowd, many phones share the same cell. Upload capacity for your stream shrinks even though the signal bars look fine.
- A bitrate that is too high: your stream bitrate has to stay below the upload speed you actually get, with some headroom. Mobile upload fluctuates, so a bitrate that works on the sofa can fail on the street.
- Battery and heat: a phone that encodes video in the sun can get hot and slow down. A drained battery ends the stream without warning.
What you can do on the sending side
Lower and adapt the bitrate
Choose a bitrate you can hold during a walk, not the maximum your phone allows. A stable 720p picture is better for your viewers than a 1080p stream that stalls. Many IRL apps also offer adaptive bitrate, which lowers the bitrate automatically when the network gets worse. The free iOS app Moblin, for example, lists adaptive bitrate for SRT(LA), RIST and RTMP.
Bond several connections
Bonding combines multiple connections, such as SIM cards from different carriers, into one stream. SRTLA is an open protocol for this: according to its GitHub project, it is an SRT transport proxy with link aggregation, intended for bonding mobile modems. Bonding helps most when your connections do not fail at the same time. If all of them sit in the same dead zone, it cannot help.
Use a protocol that tolerates packet loss
SRT (Secure Reliable Transport) is designed for unreliable networks. Its project page describes recovery from packet loss through retransmission requests and adaptation to changing network conditions. It improves quality on bad connections, but it cannot create bandwidth that is not there. For stable results, set the keyframe interval in your encoder to 2 seconds and the SRT latency to 2 seconds (depending on your hardware or software, entered as 2000 milliseconds or 2000000 microseconds). Lower values are possible, but 2 seconds favors stability.
| Measure | Helps against | Limit |
|---|---|---|
| Lower or adaptive bitrate | Congestion, weak signal | No help in a complete outage |
| Bonding (SRTLA) | One weak link, handovers | No help if all links share the same dead zone |
| SRT instead of plain RTMP | Packet loss, jitter | Cannot create bandwidth |
| Server plus OBS in between | Complete outages, split VODs | Needs a server and OBS |
The first three reduce how often your signal fails. The last one decides what your viewers see when it fails anyway.
The missing piece: a server and OBS between your phone and the platform
Instead of one fragile connection from your phone to the platform, you split the path in two. Your phone sends the stream to a server. OBS pulls the stream from that server and sends it to the platform over a stable connection. If your phone loses signal, the platform connection is not affected, because OBS keeps streaming. Viewers keep watching whatever scene OBS is showing at that moment.
There are two ways to run this:
- With the IRL Endpoint Server, OBS runs on your own computer, for example at home. Your encoder and OBS both connect outbound to the server, so you do not need to open ports or change router settings.
- With the IRL Broadcasting Server, a full OBS Studio runs in the cloud, so you do not need a powerful computer at home. You connect to it via Remote Desktop through the customer portal, and a web-based control panel lets you manage the stream, including from your phone's browser.
Both accept RTMP, SRT and SRTLA input and support streams up to 1080p at 60 fps.
Automatic scene switching: how it works
A server keeps the platform stream alive, but it does not tell your viewers what is going on. When the incoming video disappears, OBS shows a frozen frame or black unless something switches the scene. That is the job of automatic scene switching.
Automatic scene switching works with three scenes in OBS. On our servers, they are called Start, Live and Low:
- Start: a static image, maybe with music, shown while the server receives no signal.
- Live: your normal scene with the camera feed and overlays. It contains the source with the incoming stream.
- Low: shown while the bitrate is below the threshold, for example the same feed with a note such as "poor connection".
A small tool watches the bitrate of your incoming stream on the server. If the bitrate falls below the threshold, it switches OBS to Low. If no signal arrives at all, it switches to Start. When the stream is stable again, it switches back to Live.
Open-source example for your own setup: NOALBS
If you want to build the setup yourself, the best-known open-source tool for this is NOALBS (MIT license). It is an independent project: the tool on our servers, described further below, is our own development and is not compatible with NOALBS. According to the NOALBS documentation, it is a single executable for Windows, macOS and Linux that switches scenes in OBS based on the bitrate it reads from your ingest server's stats. It covers both a low bitrate and a complete disconnect, and it supports several ingest servers, such as Nginx, Node-Media-Server, SRT Live Server, BELABOX cloud and MediaMTX. It talks to OBS through OBS WebSocket 5.
The most important settings in its example configuration are:
| Setting | Meaning |
|---|---|
| switchingScenes | Names of your normal, low and offline scenes in OBS |
| triggers.low / triggers.offline | Bitrate thresholds in kbps for the low and offline scene |
| triggers.rtt / rttOffline | Optional latency thresholds in milliseconds for SRT |
| retryAttempts | Number of consecutive checks before switching. NOALBS checks once per second, so 5 means about 5 seconds |
| instantlySwitchOnRecover | Skips the waiting time when the bitrate recovers |
| offlineTimeout | Optional: stops the OBS stream after a set number of minutes in the offline scene |
NOALBS also offers optional chat commands for Twitch, so you or your moderators can switch scenes or change the low threshold from chat. It only switches while OBS is on one of the scenes from its configuration, so scenes like an intro are not overridden.
What our IRL servers include
Both of our IRL servers include automatic scene switching, so you do not have to build the setup yourself. It is our own development, not NOALBS, and it works with the three scenes described above: Start while the server receives no signal, Live for a stable stream and Low when the bitrate falls below the threshold. How it runs depends on the server:
- On the IRL Endpoint Server, you generate and download the tool in the customer portal. It runs on your own computer (Windows or macOS) alongside OBS Studio and needs the OBS WebSocket function, which is built into OBS since version 28. Enable it, connect the tool to OBS Studio following the included instructions and start it before you go live. It switches the scene when connection problems occur and switches back to Live once the connection is stable again. It works only with OBS Studio, not with vMix or Streamlabs OBS.
- On the IRL Broadcasting Server, scene switching runs on the server itself, with preconfigured scenes. The cloud server also has the scenes Break, End and Refresh. In the web control panel, you can switch to Break or End manually, and the automation then pauses until you switch back to Live.
Both servers also offer an optional Twitch chatbot if you provide a Twitch channel at checkout. It announces automatic scene changes in your chat. Viewers can query the current incoming bitrate with !bitrate, and your moderators can briefly reload the stream with !refresh. You and your moderators can also start, stop, update or switch scenes through chat commands.
The bitrate display is available as a browser source, so you can show the current incoming bitrate as an overlay in OBS.
Scene switching keeps your audience informed while your signal is down. It does not bring the signal back, so the measures above still matter.
How to choose your threshold
There is no universal value, because the right threshold depends on your hardware and your mobile network. By default, the scene switching on our IRL servers switches from Live to Low below 800 kbps. You can change this value, for example with the Twitch chat command !trigger 500. For comparison, the example configuration in the NOALBS documentation uses 500 kbps for low and 450 kbps for offline.
To find your own value, do a test walk with a bad connection. Note the bitrate where the picture starts to stutter, and set the threshold slightly above it. During the walk, also check that the scene does not flip back and forth between Live and Low.
Checklist before you go live
- Do a test walk along your route or in the venue at the time you will stream, using the bitrate you plan to use.
- Set a bitrate below your sustained upload speed with headroom, and enable adaptive bitrate if your app offers it.
- Use SRT or SRTLA instead of plain RTMP where your app supports it.
- Set the keyframe interval in your encoder to 2 seconds and the SRT latency to 2 seconds.
- If possible, use SIM cards from two different carriers or a bonding setup, and pick the server location closest to where you will stream.
- Create the scenes Start, Live and Low in OBS and name them exactly like that. If you use another tool, match the names in its configuration.
- If your OBS runs on a home computer, check that its connection can handle the incoming stream (download) and the outgoing stream to the platform (upload).
- Test the whole chain: switch off mobile data or enable airplane mode for 30 seconds, and watch whether the scene changes and switches back.
- Start with a full battery, carry a power bank, keep the phone ventilated and check that power-saving modes do not interfere with your streaming app.
- Enable platform protection such as Twitch Disconnect Protection as an extra layer, and brief your moderators on the chat commands.
For choosing hardware, apps and settings in the first place, our IRL streaming guide goes into more detail.
FAQ
Why does my IRL stream keep disconnecting?
The usual reasons are weak or missing signal, cell handovers while moving, overloaded cells at events, a bitrate above your real upload speed, and phones that overheat or run out of battery. A test walk with your planned settings shows which of these applies to you.
How long does platform disconnect protection last?
On Twitch, Disconnect Protection keeps your stream online with a message for up to 90 seconds. If you have not reconnected by then, the stream ends. A server with OBS in between does not have this limit, because the platform keeps receiving a continuous stream from OBS.
Do I still need bonding if I use a server?
They solve different problems. Bonding makes the connection from your phone to the server more reliable. The server with OBS makes sure the stream on the platform survives when that connection fails anyway. Together they give you the most protection.
At which bitrate should the scene switch to Low?
That depends on your hardware and your mobile network. On our IRL servers, the default is 800 kbps, and you can change it, for example with the Twitch chat command !trigger 500. Find your own value with a test walk instead of copying numbers from other setups: set the threshold slightly above the bitrate where the picture visibly starts to stutter.
Does automatic scene switching work with any streaming software?
The scene switching tool of our IRL Endpoint Server works only in combination with OBS Studio on Windows or macOS, not with vMix or Streamlabs OBS. NOALBS, a separate open-source tool, also works with OBS Studio through OBS WebSocket 5. Other software such as vMix can still receive the stream, but without automatic switching.