SRT vs RTMP: The First-Mile Protocol War

For the last fifteen years, RTMP (Real-Time Messaging Protocol) was the absolute gold standard for sending live video to platforms like Twitch, YouTube, and Facebook. Initially developed by Macromedia (later Adobe) for Flash player, RMTP is ubiquitous. But today, broadcast engineers rely heavily on SRT (Secure Reliable Transport) for remote point-to-point contribution. Why?

The Problem with TCP-based RTMP

RTMP runs on TCP (Transmission Control Protocol). TCP is designed to guarantee that every single packet arrives in the exact order it was sent. If a packet drops over a bad hotel WiFi connection, TCP halts the entire stream data flow until the receiver sends a requested ACK, and the sender re-transmits the dropped packet.

This is great for downloading a PDF file (where a missing byte corrupts the file), but it is terrible for live video. When TCP halts the stream to recover a packet, the video buffers, latency spikes exponentially, and eventually the connection times out. You get the dreaded spinning wheel.

The SRT Solution (UDP + ARQ)

SRT was developed by Haivision to solve this exact problem. SRT runs on UDP (User Datagram Protocol). UDP sends data as fast as possible in a continuous spray and doesn't care if it arrives or in what order. Left alone, UDP video looks like corrupted, pixelated garbage.

But SRT adds a wrapper around UDP called ARQ (Automatic Repeat reQuest) coupled with an intentional, fixed latency buffer.

• The Buffer: The sender and receiver agree on a buffer time (e.g., 120ms). The receiver holds the video for exactly 120ms before displaying it.
• The Fix: If a packet drops during transit, the receiver uses a secondary backchannel to instantly shout "I dropped packet #402! Send it again!" Since there is a 120ms buffer, there is enough time for the sender to resend packet #402, and for it to be inserted into its proper place before the 120ms timer expires and the frame needs to be shown on screen.

If the packet doesn't arrive in time, SRT simply drops the frame and moves on, causing a momentary visual glitch rather than causing the entire stream to buffer indefinitely. This guarantees a fixed, mathematically stable latency.

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. Usually the OB van in the field.
• Listener: The side that waits for a connection. Usually the studio or cloud production server. Requires a firewall port-forward (default UDP 6000).
• Rendezvous: A specialized mode where both sides attempt to "punch through" the firewall simultaneously – perfect for when neither side has access to router settings.