Srt Latency Test
An SRT test checks a Secure Reliable Transport endpoint (an srt:// URL, usually with a streamid and sometimes a passphrase) — the low-latency, loss-tolerant protocol used for contribution feeds over the public internet. A passing result means our server negotiated the SRT handshake in the correct mode (caller/listener), the streamid was accepted, and we read valid media. SRT trades a little latency for resilience: it retransmits lost UDP packets within a latency budget, so it is the go-to for getting a clean feed across an unreliable network where RTMP would stutter.
Run the test
Paste your stream URL (or run the pre-filled example). StreamProbe probes it from our servers — reachability, codec, resolution, frame rate, and a live bitrate sample.
How to read your SRT results
Handshake & mode
SRT is connection-oriented over UDP. Both ends must agree on caller vs listener mode and (if set) the passphrase. A failed handshake with a reachable host almost always means a mode mismatch, a wrong/missing streamid, or an encryption passphrase mismatch — not a network outage.
Latency budget
The latency parameter (e.g. latency=200, in ms) is the retransmission window: SRT will re-request lost packets only within that budget. Too small on a lossy link and you get gaps; too large and you add needless delay. Measuring effective latency vs. your configured budget is exactly what the SRT latency test is for.
Bitrate stability
Because SRT recovers lost packets, a healthy SRT feed shows a steadier measured bitrate than raw UDP would — but persistent retransmission (visible as bitrate dips) signals real upstream loss that is eating into your latency budget. A flat bitrate at target is the goal.
Port & firewall
SRT runs over UDP (commonly 8890, or whatever the listener advertises). UDP is more often firewalled than TCP, so a timeout where TCP-based RTMP would connect frequently comes down to a closed UDP port rather than a dead origin.
Frequently asked questions
What is the streamid in an SRT URL?
The streamid is an application-level identifier the listener uses to route or authorize your connection — often encoding a publish/play intent and a resource name (e.g. streamid=publish/live). If the listener rejects the handshake on a reachable host, a wrong or missing streamid is the most common cause.
Why use SRT instead of RTMP?
SRT recovers lost packets within a configurable latency budget, so it holds up over lossy public-internet paths where RTMP (plain TCP) stalls or buffers. It also supports encryption and firewall-friendly caller/listener modes, which makes it popular for remote contribution feeds.
What latency should I set for SRT?
A common starting point is 3–4× the measured round-trip time, often 120–250 ms for regional links. Use the SRT latency test to confirm the effective latency against your configured budget, then tune: too low drops packets, too high adds avoidable delay.