Skip to main content
RTMP and SRT handle network instability differently. Both deliver high-quality streams under good conditions, but their behavior diverges under packet loss, jitter, and bandwidth constraints.

​
RTMP/SRT on public Internet

​
RTMP behavior (TCP-based)

RTMP uses TCP for transport. TCP guarantees in-order, lossless delivery through unlimited retransmissions, sliding windows and backpressure. When the network is unstable:
  • Lost packets are retransmitted automatically by TCP
  • The sender slows down and buffers more data
  • Delay grows silently as TCP tries to recover
  • Output at the receiver remains continuous
This creates the appearance of a “smooth” and stable stream even if the network is congested or lossy. The tradeoff is unpredictable, often very large latency spikes (several seconds or more), which are hidden from the user. If packets are delayed long enough, transcoding experiences problems or stops entirely.

​
SRT behavior (UDP-based)

SRT implements reliability using UDP plus selective retransmissions. Unlike TCP, SRT enforces a strict latency window (e.g., 500–3000 ms). Packets must arrive within this time, otherwise they are dropped. When the network is unstable:
  • Retransmissions may arrive too late
  • Jitter bursts may exceed the buffer window
  • Packets that miss the latency budget are discarded
  • Decoders receive incomplete GOPs and break
SRT prioritizes stable and predictable latency. It exposes real network limitations instead of masking them with unlimited buffering. SRT manages packets independently and continues sending data for transcoding even with dropped packets — the broadcast may show brief visual glitches, but it does not stop and the frame rate remains stable.
SRT offers more capabilities than RTMP, but requires precise configuration to match the network conditions. If SRT proves difficult to configure, RTMP is a reliable fallback.

​
Limited outgoing bandwidth

Uplink bandwidth can become a limiting factor when several high-bitrate streams are sent simultaneously from one server to the Gcore transcoder and compete for the same outgoing connection. When multiple simultaneous live streams compete for the same uplink:
  • RTMP (TCP) slows down each stream, increases buffering, and eventually inflates latency to keep all streams alive.
  • SRT (UDP) does not introduce backpressure; it continues sending packets at encoder rate. If uplink bandwidth is insufficient, packets are dropped or retransmitted too late.
SRT is more sensitive to bandwidth ceilings and upstream congestion unless its latency/buffer settings are tuned for the actual network conditions.

​
Encoder frame buffer

Most H.264/H.265 encoders introduce internal delay by using lookahead, B-frames, and scenecut analysis, which buffer and reorder frames before they are sent. This encoder-side buffering (often 1.3–1.5 seconds) adds to total end-to-end ingest latency and reduces the budget available to the rest of the pipeline. For SRT, keep encoder buffering low and configure the SRT latency window to account for the expected network RTT, jitter, and retransmission time — otherwise the combined delay pushes packets past their deadline. The -tune zerolatency flag (or equivalent encoder parameters) disables lookahead, B-frames, and frame reordering to minimize encoder-side delay. The zerolatency encoder tuning section in the SRT article covers encoder frame buffering and frame reordering in depth.

​
Protocol comparison

If RTMP capabilities are sufficient, continue using it — its TCP-based algorithm handles most network issues. Switch to SRT when lower latency or codec flexibility is required. In scenarios where RTMP works correctly but SRT shows visual glitches or intermittent disconnects, the root cause is usually that the default SRT latency (commonly 500–1200 ms) is smaller than the combined encoder frame preparation time, network path RTT, jitter bursts, and loss-recovery time. The retransmission window is then insufficient: packets arrive after the deadline, are marked late, and get dropped, which leads to broken GOPs and transcoder instability. Increasing the SRT latency to ~2000 ms expands the correction window and allows late packets to arrive in time, smoothing jitter and restoring a stable, predictable ingest stream. Protocol-specific configuration is covered in the RTMP and SRT articles.

​
Demo RTMP/SRT comparison

This video demonstrates RTMP and SRT behavior with different settings under unstable internet conditions. SRT requires parameter tuning — the default latency is often insufficient for real-world network jitter and encoder buffering.
OBS SRT settings used in the video:
  • Stream URL: &latency=2000 is added
  • Output > Encoder Settings:
    • Keyframe Interval: 1sec
    • CPU Usage Preset: veryfast
    • Profile: baseline
    • Tune: zerolatency
    • x264 Options: rc-lookahead=0:bframes=0:scenecut=0