Every so often a customer opens a ticket that reads the same way: "the stream keeps freezing whenever our field feed hits a bad uplink." Nine times out of ten they are pushing RTMP over a link that drops packets, and RTMP has no answer for that. This is the exact problem SRT was built to solve, and it is why we treat SRT ingest server hosting as a first-class use case rather than an afterthought. Below are our notes from the rack on when SRT beats RTMP, the latency you can realistically expect, and how we stand up an SRT gateway on a box that already has the software installed.
Why SRT ingest server hosting exists at all
RTMP rides on TCP. On a clean, low-loss path it is fine and it is everywhere. The moment your contribution link gets lossy — a bonded cellular uplink from a venue, a congested hotel connection, a satellite hop, a Wi-Fi bridge in a stadium — TCP's retransmit and congestion behaviour turns a 2% packet loss into visible stalls and growing buffer delay. SRT (Secure Reliable Transport) runs on UDP and adds its own selective retransmission with a fixed latency budget. Instead of stalling, it re-sends the packets it can inside a window you define and delivers a steady feed at the far end. That trade — a small, predictable latency buffer in exchange for surviving loss — is the whole reason SRT ingest exists, and it is why broadcasters standardised on it for contribution.
SRT vs RTMP: when to switch
We do not tell people to rip out RTMP for the sake of it. If your encoder sits in the same datacentre or on a wired symmetric line, RTMP is simpler and there is no reason to change. Switch to SRT when the first mile is unreliable or the geography is long. The table below is the rough decision matrix we hand customers.
| Situation | Use | Why |
|---|---|---|
| Wired, low-loss uplink, same region | RTMP/RTMPS | Simple, universally supported, no tuning |
| Bonded cellular / field contribution | SRT | Survives packet loss without stalling |
| Long-haul or intercontinental hop | SRT | Latency budget absorbs jitter and re-sends |
| Congested venue / hotel Wi-Fi | SRT | Fixed buffer beats TCP retransmit collapse |
| Browser-to-server, no native encoder | RTMP | SRT needs an SRT-capable sender |
The one honest caveat: SRT needs an SRT-capable encoder on the sending side. OBS, ffmpeg, vMix, Haivision and most hardware contribution encoders all speak it now, so this is rarely a blocker in a broadcast or pro workflow.
The latency numbers that actually matter
SRT latency is not a single number you look up — it is a budget you set. The sender and receiver agree on a latency value (the latency parameter, in milliseconds) that defines how long SRT will hold packets to allow retransmission. The rule of thumb we give customers is to set the buffer to roughly three to four times the measured round-trip time of the path. On a clean intra-EU link with a few milliseconds of RTT, a buffer in the low tens of milliseconds is plenty. On a lossy or long-haul path you might run 200ms to 2000ms — still a fraction of the multi-second buffers an HLS delivery leg would add downstream.
The point of SRT ingest is that the buffer is fixed and predictable. RTMP over a lossy link gives you a latency that drifts upward as buffers fill; SRT gives you a flat number you chose in advance. That predictability is why the ingest edge, not the delivery edge, is where SRT earns its keep. Where you land on the network path matters here — our two streaming POPs sit in Amsterdam and Frankfurt, close to the major European IXs, so the RTT from most EU contribution points is low and the buffer you need to set is small.
The gateway: MediaMTX and MistServer, pre-installed
An SRT ingest server is only useful if it also fans the feed out to whatever your viewers actually watch. That is the "gateway" job: take SRT in, hand HLS, LL-HLS or RTMP/RTMPS out. On our streaming VPS the two tools that do this — MediaMTX and MistServer — are already installed on the image, alongside OBS, Nginx-RTMP, Owncast and Restreamer. There is no compiling from source, no dependency chase. You point your encoder at the SRT listener and configure the outputs you want.
MediaMTX is our default recommendation for a lean SRT-to-HLS gateway — it is a single binary, it speaks SRT, RTMP, RTMPS, HLS and LL-HLS natively, and it is trivial to script. MistServer is the heavier option when you want per-protocol control, a management interface and more granular routing across many outputs. Both ship on the same box, so you can trial one, keep the other, and never touch a package manager. Because SRT, RTMP, RTMPS, HLS and LL-HLS are all supported natively, one box can ingest a broadcast contribution feed over SRT and simultaneously accept an RTMP push from a second source without any extra setup.
What the box underneath needs to be
Contribution feeds are bursty and unforgiving, so the ingest server itself has to have headroom. The streaming tier runs on 10 Gbps unmetered symmetric NVMe — the symmetric part matters because you are ingesting and fanning out at the same time, and an asymmetric line chokes the egress leg. Every streaming plan also carries our free 1 Tbps DDoS protection, which is not a vanity number: public SRT and RTMP listeners get scanned and hit, and you do not want your live contribution feed to be the thing that goes down under a volumetric attack. Tiers run from EUR9.99 up to EUR139.99 depending on how many outputs and how much transcode headroom you need. If you only need a lab box to prototype the gateway before going live, a general hourly VPS billed to the second is a cheap way to test the config first.
How Noded Can Help
We built the streaming product around exactly this workflow because our sibling network kept fielding the same "RTMP won't hold up" tickets. Our streaming VPS ships with MediaMTX and MistServer already installed, native SRT/RTMP/RTMPS/HLS/LL-HLS, 10 Gbps unmetered symmetric NVMe, and free 1 Tbps DDoS on every plan — deployed from our Amsterdam and Frankfurt POPs on our own AS60982 backbone, not a reseller's. You get root and KVM, so if you want to run a bespoke SRT config or add a bonding proxy, nothing is locked down. If you are weighing SRT ingest for a broadcast or event workflow, the streaming VPS page has the full tier list and the pre-installed toolchain. Median deploy is under a minute, so you can have a listener up and test a feed the same afternoon.
FAQ
Is SRT ingest better than RTMP for a contribution feed?
For an unstable or long-haul first mile, yes. SRT runs on UDP with its own retransmission and a fixed latency budget, so it survives packet loss that would stall RTMP over TCP. On a clean wired link in the same region, RTMP is simpler and there is no need to switch.
What latency should I set on an SRT ingest server?
SRT latency is a buffer you choose, not a fixed value. A common rule is to set it to roughly three to four times the path round-trip time — low tens of milliseconds on a clean intra-EU link, higher on lossy or long-haul paths. The value is predictable, which is the point.
Do I have to install MediaMTX or MistServer myself?
No. Both are pre-installed on our streaming VPS image, along with OBS, Nginx-RTMP, Owncast and Restreamer. You point your encoder at the SRT listener and configure the outputs — no compiling or dependency setup.
Can one server ingest SRT and output HLS at the same time?
Yes. That is the gateway job. MediaMTX or MistServer takes the SRT feed in and hands out HLS, LL-HLS or RTMP/RTMPS. All of those protocols are supported natively on the same box, so a single server can ingest a contribution feed and fan it out to viewers.
Where are the SRT ingest POPs located?
Our streaming POPs are in Amsterdam and Frankfurt, close to the major European internet exchanges on our own AS60982 backbone. That keeps round-trip time low from most EU contribution points, which means you can run a smaller SRT latency buffer.