SRT runs over UDP, and many hotel, company and public Wi-Fi networks block or throttle outgoing UDP. Then your camera app does not connect to the studio, although the same setting worked at home.
The fastest way out is the mobile network: Wi-Fi off, mobile data on, or a hotspot from the phone. In the long run the only thing that helps is the network's operator opening the connection.
Why this happens
Most internet services run over TCP: web pages, e-mail, RTMP too. Guest networks are often set up so that only what is necessary gets through, and for many operators UDP to unknown ports is not part of that. Some networks block it completely, others let it through and throttle it heavily.
SRT needs UDP because it asks for lost packets again itself within a short time window. That makes it robust on bad links, but it requires UDP to get through at all.
How you recognize it
There are two pictures.
Blocked completely. The app reports that it gets no connection, or tries endlessly. In the studio the input says “Kein Signal” (no signal) on the “Eingänge” (inputs) tab. Browsing works quite normally all the while, which sends the search in the wrong direction.
Throttled. The connection comes about, but the picture stutters or breaks into blocks. In the link quality display on the “Eingänge” tab the numbers under “Repariert” (repaired) and “Verloren” (lost) rise, although the Wi-Fi itself looks strong.
The test in one minute
- Leave all settings of the app as they are.
- Switch off Wi-Fi on the device and send over mobile data.
- Look on the “Eingänge” tab whether the input jumps to “Verbunden” (connected).
If the picture arrives over mobile data, address, stream ID and codec are right, and the Wi-Fi is the cause. If it does not arrive over mobile data either, it is something else. Then No picture in the studio: the checklist helps.
Way out 1: mobile data or a hotspot
If a phone is sending, you take its mobile data. If a laptop or a hardware encoder is sending, you connect it to a phone's hotspot.
Mind the data volume. A stream uses roughly:
| Bitrate | Use per hour |
|---|---|
| 4 Mbit/s | about 1.8 GB |
| 6 Mbit/s | about 2.7 GB |
On shaky mobile data about 3 to 4 Mbit/s are a reasonable bitrate, on good 5G 6 Mbit/s. More on that in Encoder settings.
Only the source has to change networks. Every source sends to your studio by itself, and from the studio to Twitch or YouTube the stream goes out from our servers. So the upload to the platforms puts no additional load on your connection.
Way out 2: ask the network's operator
For an event you are planning to stream, asking the building's technicians or IT is worth it. What you need can be named exactly:
- outgoing connections over UDP,
- to the host and the port that are in your input's address.
The address has the form srt://<host>:<port>?streamid=<id> and is on the “Eingänge” tab. It normally stays the
same for every stream, so the rule only has to be set up once. Every input has its own address. If you use
several cameras on the same network, pass on the addresses of all inputs.
Ask early and test on site before it matters. A promise on the phone does not replace the test.
What does not help
- Changing to RTMP. Your studio accepts sources over SRT. RTMP is the protocol the studio sends to the platforms with, not the one for your cameras.
- Setting a passphrase. The studio accepts SRT without encryption; the field stays empty. It changes nothing about the block anyway.
- Raising the SRT latency. That helps against packet loss on a weak link, but not against a network that does not let UDP through at all.
- Bundling several mobile connections. The studio does not accept SRTLA bonding yet; it is planned. A plain SRT connection from the same apps works.
Before a trip
If you want to stream from a hotel or a trade fair, plan the mobile network in from the start: enough data volume, a fitting plan for trips abroad, and one test before the broadcast begins. If the Wi-Fi on site gets through after all, so much the better.