SRT Streaming Guide
Set up SRT for broadcast-quality live contribution over the public internet — caller and listener mode, latency settings, firewall configuration, hardware encoders and troubleshooting.
In this guide
What Is SRT?
SRT (Secure Reliable Transport) is an open-source video transport protocol designed for live streaming over unreliable networks — including the public internet, 4G/5G cellular and satellite. Developed by Haivision and now maintained by the SRT Alliance, it has become the professional standard for broadcast contribution and live video delivery over IP.
SRT works by automatically retransmitting lost network packets within a configurable latency buffer. This means streams can survive significant packet loss without visible artefacts or disconnection — something that RTMP, the previous standard, cannot do. SRT also includes AES encryption and supports adaptive bitrate to handle variable network conditions.
For a detailed technical explanation, see What is SRT? This guide focuses on practical setup and configuration.
SRT vs RTMP vs NDI
SRT ✓ Recommended
- UDP with packet retransmission
- Survives 10–15% packet loss
- AES-128/256 encryption built-in
- Configurable latency (20ms–8s)
- For internet contribution
- Supported by all pro encoders
RTMP (Legacy)
- TCP — no retransmission
- Any packet loss = stream failure
- No encryption (RTMPS adds TLS)
- Higher latency on poor networks
- Still required by some platforms
- Use only where SRT unavailable
NDI (LAN only)
- UDP multicast / unicast
- Designed for local network
- ~125 Mbps per 1080p60 stream
- One-frame latency
- Not suited for internet use
- Use SRT to bridge NDI over WAN
💡 When to use each: Use SRT for any live video sent over the public internet or cellular networks. Use RTMP only where the destination platform does not accept SRT. Use NDI for local network production within a building or campus.
Caller vs Listener Mode — The Most Important Concept
SRT is a point-to-point protocol — one device initiates the connection and one waits for it. Getting this wrong is the most common reason SRT connections fail. Understanding Caller and Listener mode is essential before any SRT setup.
🎧 Listener Mode
The Listener opens a UDP port and waits for a Caller to connect. It does not initiate — it sits and listens.
- Must have the SRT port open on its firewall/router (inbound)
- Typically: the receiving server, cloud platform or decoder
- Must be running before the Caller attempts to connect
- Can accept connections from multiple Callers on the same port
📞 Caller Mode
The Caller dials out to the Listener's IP address and port. It initiates the connection.
- No inbound ports need to be open on the Caller side
- Typically: the encoder or camera at the source location
- Needs the Listener's IP address or hostname and port number
- Will retry automatically if the Listener is not yet available
Which device should be which?
In most broadcast contribution setups: the encoder at the source location is the Caller and the receiving server or decoder at the destination is the Listener. This is the cleanest setup — only the destination server needs a firewall port open, not the encoder location (which may be behind a hotel router, cellular NAT or venue firewall with no IT support).
Rendezvous mode
A third SRT mode — Rendezvous — allows both sides to simultaneously attempt to connect to each other. Useful when both endpoints are behind NAT and neither can open an inbound port. Both sides set their mode to Rendezvous and specify each other's IP address and the same port. This is more complex and less commonly used than Caller/Listener.
⚠️ Most common SRT mistake: Setting both devices to Caller or both to Listener. The connection will never establish. One must be Caller, one must be Listener. If your connection is failing with no error other than timeout, check this first.
SRT Latency Settings
SRT latency is a buffer that gives the protocol time to retransmit lost packets before they are needed for playback. Set it too low and packet loss causes visible artefacts. Set it too high and you add unnecessary delay. Both encoder and decoder must be set to the same latency value.
How to calculate the right latency
The rule of thumb: set SRT latency to 3–4× your measured network round-trip time (RTT). Measure RTT by pinging the destination IP from the encoder location before the event. Use the average ping value × 4 as your starting latency in milliseconds.
| Connection type | Typical RTT | Recommended SRT latency | Notes |
|---|---|---|---|
| Local network / LAN | <1 ms | 20–40 ms | Minimum practical latency |
| UK to UK (broadband) | 10–30 ms | 120–200 ms | Standard domestic broadband |
| UK to Europe | 20–50 ms | 200–300 ms | Continental contribution |
| UK to USA | 80–120 ms | 400–600 ms | Transatlantic production |
| 4G cellular | 30–80 ms | 300–500 ms | Higher jitter needs more buffer |
| 5G cellular | 10–30 ms | 150–300 ms | Better than 4G, still variable |
| Satellite (geo) | 500–700 ms | 2,000–4,000 ms | Geostationary satellite |
| Poor / congested network | Variable | 1,000–2,000 ms | Start high and reduce |
💡 Latency in OBS is in microseconds: OBS SRT parameters use microseconds, not milliseconds. 200ms = 200,000 microseconds. Hardware encoders typically use milliseconds. Do not confuse the two — a latency of 200 microseconds (not 200ms) is effectively zero and will cause constant artefacts.
Ports and Firewall Configuration
SRT uses UDP — not TCP. This is important: many firewall rules specify TCP or UDP separately. Opening TCP port 9998 does not open UDP port 9998. SRT requires UDP.
Default port
SRT has no single official default port. Common ports used in practice: 9998 (used by many hardware encoders), 4200 (OBS default), 7002 (Haivision default), 8989. You can use any available UDP port — just ensure both encoder and decoder use the same port number.
What needs to be open
- Listener side only: open the chosen UDP port inbound on the Listener's firewall and any NAT router
- Caller side: no inbound ports need to be opened — UDP outbound is typically allowed by default
- Cloud platforms: if using a cloud SRT server (AWS, Azure, Wowza, Akamai), the SRT port must be open in the security group / network ACL on the cloud instance
Common firewall issues
- Corporate firewalls often block unknown UDP ports — work with IT to open the specific UDP port used
- Hotel and venue Wi-Fi frequently blocks UDP — use cellular bonded connection as backup
- Windows Defender Firewall may block SRT on first connection — allow the encoder or OBS through the firewall when prompted
- Some ISPs perform UDP throttling — if connection fails consistently at venue, test with a mobile hotspot to isolate ISP vs firewall issues
Step-by-Step SRT Setup
-
1
Decide Caller and Listener
Typically: encoder at source = Caller. Receiving server or decoder = Listener. Write this down before touching any settings — mismatched modes are the number one SRT setup failure.
-
2
Choose your SRT port
Pick any unused UDP port — 9998 is a safe default. Check it is not already in use on the Listener device with
netstat -an | grep 9998. Note the port — you will need it on both sides. -
3
Open the port on the Listener firewall
On the Listener machine: open the chosen UDP port inbound. On Linux:
ufw allow 9998/udp. On Windows: Windows Defender Firewall → New Rule → Port → UDP → 9998 → Allow. If behind a router: add a port-forwarding rule for UDP 9998 to the Listener's local IP. -
4
Measure your network RTT
From the encoder location, ping the Listener's IP address:
ping [listener-ip]. Note the average RTT in milliseconds. Multiply by 4 — this is your starting SRT latency. For cellular connections, use a higher multiplier (5–6×) to account for jitter. -
5
Configure the Listener
In OBS (Listener): add a Media Source with URL
srt://0.0.0.0:9998?mode=listener&latency=200000(latency in microseconds). In a hardware decoder: set mode to Listener, port to 9998, latency to your calculated value. In Wowza or other SRT server: configure the SRT input with the port and latency settings. -
6
Configure the Caller (encoder)
In a hardware encoder web interface: set SRT mode to Caller, enter the Listener's public IP or hostname, set port to 9998, set latency to match the Listener. In OBS: Settings → Stream → Custom → enter SRT URL:
srt://[listener-ip]:9998?mode=caller&latency=200000. -
7
Enable encryption (recommended)
Set a passphrase of 10–79 characters on both encoder and decoder — identical on both sides. Choose AES-128 for standard security, AES-256 for high-security requirements. Encryption adds negligible CPU load and latency and is strongly recommended for any production stream, particularly medical, government or sensitive corporate content.
-
8
Start Listener first, then Caller
Always start the Listener before the Caller. The Caller will continually retry if the Listener is not available yet — most hardware encoders retry every few seconds automatically. Check the encoder's SRT status display for connection confirmation. Monitor RTT and packet loss statistics in the encoder web interface during the stream.
SRT Configuration in OBS Studio
OBS Studio 28 and later includes native SRT support without plugins. The configuration uses SRT URL parameters directly.
Streaming via SRT from OBS (Caller)
Settings → Stream → Service: Custom
- latency — in microseconds (200000 = 200ms)
- pbkeylen — encryption key length: 16 = AES-128, 32 = AES-256, 0 = none
- passphrase — encryption passphrase (10–79 characters, must match receiver)
- mode — caller or listener
Receiving SRT into OBS (Listener)
Sources → + → Media Source → uncheck Local File → URL:
Set Reconnect Delay to 1s and check Restart playback when source becomes active. OBS does not natively display SRT stream statistics — use the encoder's web interface to monitor packet loss and RTT.
OBS SRT to YouTube (via SRT-to-RTMP relay)
YouTube's SRT ingest URL is only available on verified channels. For accounts without SRT ingest: use a cloud relay server (AWS MediaLive, Wowza Cloud, SRT Live Server) that receives your OBS SRT stream and forwards to YouTube as RTMP. This is common for productions where the encoding PC is in a poor network location and SRT provides more reliable delivery than RTMP to the relay, which then has a reliable connection to YouTube.
Who Uses SRT and Why
Broadcast News
SRT has replaced satellite and ISDN for ENG contribution. Reporters send broadcast-quality live shots over 4G/5G using hardware encoders with bonded cellular.
Sports Production
Remote sports venues with poor fixed broadband use SRT over bonded cellular to contribution-encode match feeds back to production facilities at broadcast quality.
Houses of Worship
SRT handles variable venue broadband more reliably than RTMP. Critical for weekly services where a dropped stream is not acceptable.
Corporate Events
External venue internet is unreliable. SRT from a hardware encoder with 4G backup ensures corporate webcasts and town halls reach their audiences.
Live Events & Concerts
SRT contribution from venues to central production facilities for multi-camera productions where the production team is not on-site.
Medical & Telemedicine
SRT's AES encryption makes it suitable for transmitting sensitive clinical video for telemedicine, remote surgical observation and medical education streams.
Education
Remote lecture delivery and campus-to-campus contribution. SRT with encryption for sensitive educational content delivered reliably over campus WAN links.
Defence & Government
SRT AES-256 encryption for secure video contribution over classified or sensitive networks where content cannot be transmitted unencrypted.
Remote Production
REMI (Remote Integration Model) production uses SRT to send multiple camera feeds from a venue to a central production facility over the internet.
Recommended SRT Hardware
Standalone SRT encoders (no PC needed)
Ultra Encode HDMI
H.265 HDMI encoder with SRT, RTMP, HLS and NDI simultaneously. Stream to 4 destinations at once from one device. From £350 ex-VAT.
Ultra Encode SDI
H.265 3G-SDI encoder with SRT output. For broadcast cameras. Standalone — no PC. Streams SRT alongside RTMP and NDI. From £359 ex-VAT.
Encoders with SRT + 4G
Kiloview HDMI and SDI encoders with built-in SIM card slots and bonded cellular. SRT over 4G/5G for reliable location streaming. Full range available.
Pearl Encoders
Professional multi-input rack encoders with SRT, NDI and recording. For broadcast facility and permanent installation SRT contribution workflows.
SRT + NDI combined workflows
Pro Convert HDMI Plus
HDMI to NDI and SRT simultaneously. Camera on local NDI network and contributing via SRT to a remote facility — both at the same time. From £383 ex-VAT.
Pro Convert SDI Plus
SDI to NDI and SRT simultaneously. Integrate broadcast SDI cameras into NDI and contribute via SRT to remote production hubs. From £412 ex-VAT.
NDI Cameras with SRT
BirdDog PTZ cameras with built-in NDI and SRT output. Single camera for both local NDI production and internet SRT contribution.
Multi-camera SRT production
Director Plus
4K all-in-one with SRT output. Switch 4× HDMI 2.0 + 10 IP sources and stream the mixed output via SRT to broadcast facilities. From £1,460 ex-VAT.
YoloBox range
Portable streaming studios with SRT output. Switch multiple cameras and stream the production mix via SRT from an all-in-one handheld device.
SRT decoding (receive SRT into physical outputs)
Pro Convert NDI to HDMI
Receives SRT streams (alongside NDI) and outputs to HDMI. Decode remote SRT contributions to a physical display or production monitor. From £370 ex-VAT.
Pro Convert IP to AIO 4K
Decode SRT to simultaneous 4K HDMI, SDI and analogue. The most capable SRT decoder for broadcast facility integration. From £799 ex-VAT.
Troubleshooting SRT Issues
❌ SRT connection never establishes — timeout
Step 1 — Check Caller and Listener modes. Both devices on the same mode (both Caller or both Listener) will never connect. One must be each. Step 2 — Check the UDP port is open on the Listener. Use an online UDP port checker or test with nc -uv [listener-ip] 9998 from the Caller. Step 3 — Check the Listener is running before the Caller attempts to connect. Start the Listener first. Step 4 — Check for corporate firewall blocking UDP. Test with a mobile hotspot to isolate network vs configuration issues.
📺 SRT connects but video has blocky artefacts or freezes briefly
Packet loss is exceeding the retransmission capacity of the latency buffer. Increase the SRT latency setting on both encoder and decoder — try doubling the current value. If the problem persists, your encoded bitrate is too high for the available bandwidth. SRT needs approximately 25% bandwidth overhead above the encoded bitrate. Reduce encoded video bitrate by 20% and re-test. Check the encoder's SRT statistics for packet loss percentage — above 5% with adequate latency indicates a network path problem.
🔄 SRT stream connects and disconnects repeatedly
Most commonly caused by the network path failing and recovering — check for intermittent internet outages at the source location using a continuous ping to an external IP (8.8.8.8). If on cellular, check signal strength and consider bonded cellular. Also check whether the encoder's SRT retry timeout is too short — hardware encoders should retry automatically; configure retry interval in the encoder settings if disconnections coincide with network hiccups shorter than the retry window.
⏱ SRT stream has unexpectedly high latency
Total SRT delay = latency buffer setting + encoding delay + decoding delay. Check what latency is configured on both ends — if the encoder has 500ms and the decoder has 200ms, the connection negotiates the higher value. Reduce the latency setting on both devices to your calculated target (4× RTT). Also check that the production software receiving the stream (OBS, vMix) does not have an additional buffer delay — in OBS Media Source, reduce the buffering setting.
🔐 SRT encryption error — connection fails with passphrase
The passphrase or key length does not match between encoder and decoder. Check: (1) the passphrase is exactly identical on both ends — no leading or trailing spaces, no character substitution; (2) the key length (pbkeylen) is the same on both — 16 for AES-128, 32 for AES-256; (3) one end has encryption enabled and the other does not — both must be configured identically; (4) the passphrase meets the 10-character minimum length requirement.
📡 SRT works on broadband but fails on venue Wi-Fi or 4G
Venue Wi-Fi frequently blocks UDP traffic or uses aggressive packet inspection that disrupts SRT. Test with a mobile hotspot to confirm this is the cause. If SRT works on cellular but not venue Wi-Fi: try a different UDP port (some venues block known streaming ports); request IT open UDP on your specific port; use a hardware encoder with a built-in SIM card (Kiloview). For 4G with high packet loss, increase the SRT latency buffer — 4G packet loss is bursty and requires a larger retransmission window than fixed broadband.
SRT setup not working at a critical event?
Our technical team can diagnose SRT configuration issues remotely, advise on the right hardware for your network conditions, and recommend bonded cellular solutions for locations where broadband is unreliable.
Contact Technical SupportFrequently Asked Questions
What is the difference between SRT Caller and Listener mode?
Listener opens a UDP port and waits for a Caller to connect. Caller dials out to the Listener's IP address and port. One device must be each — two Callers or two Listeners will never connect. Typically: encoder at source = Caller; receiving server or decoder = Listener. Only the Listener needs a firewall port opened inbound.
What SRT latency should I use?
Set latency to 3–4× your measured network RTT (ping the destination and multiply the average by 4). Local network: 20–40ms. UK broadband: 120–200ms. Cellular 4G: 300–500ms. International: 400–1000ms. Both encoder and decoder must be set identically. Note: OBS uses microseconds — 200ms = 200,000 in OBS SRT URL parameters.
What port does SRT use?
SRT can use any UDP port — there is no fixed standard. Common ports: 9998 (many hardware encoders), 4200 (OBS default), 7002 (Haivision default). Only the Listener's firewall needs the UDP port opened inbound. Ensure both encoder and decoder use the same port number.
Why does my SRT stream show artefacts?
Packet loss is exceeding the SRT retransmission buffer. Fix: increase the SRT latency on both encoder and decoder. Also check your encoded bitrate is not too high for the available bandwidth — SRT needs 25% overhead above the video bitrate. Reduce bitrate if artefacts persist after increasing latency.
What is the difference between SRT and RTMP?
SRT is UDP-based with automatic packet retransmission — streams survive packet loss and network fluctuations. RTMP is TCP-based with no error correction — any packet loss causes the stream to fail. SRT includes AES encryption; RTMP does not. SRT is now the professional standard for live contribution over the internet. Use RTMP only where the destination platform does not support SRT.
Can I use SRT with OBS?
Yes — OBS 28 and later has native SRT support. For streaming (Caller): Settings → Stream → Custom → enter SRT URL with mode=caller and latency in microseconds. For receiving (Listener): add a Media Source with mode=listener SRT URL. OBS does not display SRT statistics natively — monitor packet loss via the encoder's web interface.
Does SRT work over 4G and 5G?
Yes — SRT is specifically designed for unreliable networks including cellular. Set a higher latency buffer (300–600ms for 4G, 150–300ms for 5G) to account for cellular jitter. For critical location streaming, use a hardware encoder with bonded cellular (multiple SIM cards combined) such as Kiloview encoders — this provides both higher total bandwidth and resilience against any single connection failing.
Does YouTube accept SRT?
YouTube supports SRT ingest on verified channels with Creator Studio access. In YouTube Studio → Go Live → Stream settings, look for the SRT URL. Not all accounts have SRT ingest enabled — if unavailable, use a relay server that accepts SRT and forwards to YouTube via RTMP. SRT direct ingest to YouTube gives better stream reliability on poor network connections compared to RTMP.
How much bandwidth does SRT use?
Total SRT bandwidth = encoded video bitrate + audio bitrate + approximately 25% protocol overhead for retransmission packets and SRT headers. A 6,000 kbps video + 128 kbps audio stream over SRT requires approximately 7,700–8,000 kbps total upload bandwidth. Size your connection accordingly — do not set SRT bitrate at 100% of your upload capacity.