Quick Answer
SRT is usually the better fit for contribution over unpredictable links because it is built around controlled recovery and an intentional latency buffer. RTMP is still common for platform ingest, but the right choice depends on whether the job is contribution, delivery, or browser/platform compatibility.
The Problem with TCP-based RTMP
RTMP runs on TCP (Transmission Control Protocol), which presents an ordered reliable byte stream to the application. When data is lost, retransmission and in-order delivery can hold later data behind the missing portion. How visible that becomes depends on the sender, receiver, buffers, RTT, and loss pattern.
That ordered recovery can add delay or stall media delivery when loss and RTT vary. RTMP can still be the correct choice for a platform ingest workflow; it is simply a different tradeoff from an SRT contribution link.
The SRT Solution (UDP + ARQ)
SRT runs over UDP (User Datagram Protocol) and adds sequencing, timing, and loss-recovery behavior suited to live media. UDP alone does not provide ordered, reliable delivery; the application protocol decides how missing or late packets are handled.
SRT uses ARQ (Automatic Repeat reQuest) with a configured latency window.
- The latency window: Configured latency creates time in which a missing packet may be retransmitted. End-to-end latency also includes encoding, decoding, queues, and application behavior.
- Recovery: The receiver can request missing packets. Recovery succeeds only if the retransmission arrives before it is too late for playout.
If recovery cannot complete inside the configured timing constraints, the receiver or decoder must continue without all expected data. The visible result depends on packetization, codec recovery, decoder concealment, and which packets were lost; it is not always a single dropped frame. SRT gives the operator a more explicit latency/recovery tradeoff, but the result still depends on RTT variation, loss, and buffer settings.
Caller, Listener, and Rendezvous
One common hurdle for engineers switching to SRT is Firewall Traversal. Unlike RTMP, which always pushes to a server, SRT lets you choose which end initiates the connection:
- Caller: The side that initiates the connection. This can be either endpoint, according to the network design.
- Listener: The side that waits for a connection on the configured UDP port. Its firewall and NAT path must permit the intended traffic; there is no universal port that every deployment must use.
- Rendezvous: A specialised mode where both sides initiate the connection. It can help in some NAT/firewall topologies, but must be tested against the actual network policy.
The linked calculator uses four times measured RTT as a visible planning default, with a small RTT floor. This is not an SRT protocol rule. Test RTT variation, burst loss, encoder delay, and the exact endpoints before choosing a final setting.
Common Mistakes
- Treating RTMP ingest and SRT contribution like the same workflow.
- Using RTT alone as the final latency setting without testing jitter and loss.
- Assuming lower latency is always better if packet recovery margin disappears.
- Ignoring firewall mode when setting up caller, listener, or rendezvous.
Related Tools & Next Step
Use the SRT latency calculator to size the buffer, and use the OBS & vMix Streaming Planner when the transport decision is part of a wider streaming setup.