Why SRT keeps the picture together
SRT holds the picture together by giving lost packets a second chance. When the receiving end notices a gap, it tells the sender, and the sender resends just that packet. The protocol calls this Automatic Repeat reQuest, ARQ for short. Every packet waits in a small buffer at the receiving end, so a resent packet can slot back into place before it is due to play.
That waiting time is what SRT calls latency. It counts only the trip across the network, not your camera, encoder or player. Because the delay is fixed, the stream comes out with the same rhythm it went in with, and a packet that still has not arrived when its moment comes is skipped, so the delay never creeps upward during a long show.
How much delay should you allow?
Allow three to four times the round-trip time between your encoder and the server; that is what the SRT specification recommends. Out of the box SRT uses 120 ms, which is plenty for a nearby, wired connection and too little for a mobile link on another continent.
- Find your round trip: run a test connection and read the RTT figure SRT reports (
msRTT). - Multiply it by four. A 50 ms round trip gives 200 ms; a 150 ms one gives 600 ms.
- On Wi-Fi, 4G or 5G add margin, because the round trip on those links swings widely.
- During rehearsal, watch the dropped-packet count. If it climbs, raise the delay a step.
Both ends can ask for a delay, and the connection uses the larger of the two. Your viewers sit that much further behind live, so set it as long as the line needs and no longer.
Who dials whom
One side waits for connections (the listener) and the other side dials it (the caller); that choice is separate from which way the video travels. When you send to a server with a fixed address, the server listens and your encoder calls. That is the easy arrangement, because only the server needs a port open, and your encoder can move from venue to venue without anyone touching a firewall.
There is a third mode, rendezvous, where both ends dial each other at the same moment. It is meant for two fixed sites that both sit behind firewalls and only ever talk to each other.
Locking the stream with a passphrase
Give both ends the same passphrase, between 10 and 80 characters, and SRT encrypts the video with AES. Leave it blank and the stream travels in the clear. You can choose the key strength with the pbkeylen setting: 16 for AES-128, 24 for AES-192, 32 for AES-256. If nobody sets it, SRT uses AES-128.
By default a wrong passphrase is turned away when the encoder tries to connect. That is what you want: a clear refusal in the encoder's log instead of a connection that looks fine and carries nothing anyone can watch.
Is SRT better than RTMP?
Over long or lossy connections, usually yes. RTMP travels over TCP, and the SRT specification points out that TCP-based protocols only stay reliable on connections with short round trips. SRT runs over UDP and does its own recovery within the delay you set.
| Your situation | What to send |
|---|---|
| Studio on a wired line near the ingest city | RTMP is fine and every encoder has it |
| Venue Wi-Fi, a shared stadium uplink, a hotspot | SRT, with a delay sized to the round trip |
| Encoder on another continent | SRT with a longer delay |
| HEVC or another codec your RTMP setup cannot carry | SRT: it does not care what codec it carries |
Keeping your own SRT server
Running the server yourself means choosing a port, opening it for UDP in the firewall (and forwarding it if the server sits behind a router), building the SRT tools, and keeping an eye on the link. The project's sample tool, srt-live-transmit, is the quickest way to try a link end to end; its documentation calls it a testing tool and a sample application, and points people building a product to the SRT library itself. This smoke test from the documentation turns a local UDP feed into an SRT listener on port 4201 that you can then open in VLC or ffplay:
srt-live-transmit udp://:1234 srt://:4201 -v
ffplay srt://127.0.0.1:4201For a server that stays up for real broadcasts, you would run streaming software that speaks SRT on hardware that is yours alone. If that is the job, a dedicated streaming server gives you the whole box and an unmetered port, with the streaming software you prefer.
Or send SRT straight to your channel
If what you really want is the show on air, not a server to look after, our video streaming hosting takes SRT on Starter, Pro and Platinum. Each channel gets its own SRT port and passphrase, and the dashboard prints them ready to paste into your encoder. The free plan accepts RTMP and WebRTC instead.
- Open a channel on Starter or above.
- Copy the SRT address, port and passphrase from the channel's dashboard into your encoder.
- Set the delay from your round trip, as above, and go live.
- Check the Live tab: it shows that your encoder is connected, from where, and what it is sending.
Your stream enters at the nearest of our five cities and is carried to your channel, then reaches viewers from the city closest to them over the video CDN. For a single big night, a conference or a concert, see live event streaming; on Platinum, event mode is part of the plan.
Questions people ask
- Do I need my own server to stream over SRT?
- No. A hosted live channel on Starter or above gives you an SRT port and passphrase of your own, and the servers are ours to run. You need a server of your own only if you want to control the SRT side yourself, for example to relay between your own sites.
- My encoder will not connect. What should I check first?
- Check the passphrase first: it must match exactly, and a mismatch is refused outright. Then check the address and port, and that your encoder is set to caller mode. On your own server, make sure the UDP port is open and forwarded.
- Will SRT add delay for my viewers?
- It adds the delay you choose, usually a few hundred milliseconds on a long link, in return for a picture that holds together. The formats players use to reach a large audience usually add more delay than that, so on most links SRT is the smaller part of the wait.
- Which encoders can send SRT?
- Many software and hardware encoders can, but not all, so check yours. If yours only speaks RTMP, every plan accepts RTMP, and on a good wired line you will rarely miss SRT.