What is SRT, and Why It Beats RTMP on the Public Internet

SRT in one sentence

SRT (Secure Reliable Transport) is an open source protocol for reliable low-latency transport over unreliable networks, originally developed and open sourced by Haivision.

It sits at the transport layer and does not care which codec you use: H.264, H.265 or even baseband-compressed streams can travel inside SRT. Codec choice and transport choice are separate decisions.

SRT versus RTMP

Attribute	RTMP	SRT
Underlying transport	TCP	UDP with ARQ retransmission
Behaviour under loss	Queues and retransmits, so latency accumulates (head-of-line blocking)	Selective retransmission that does not block later data
Jitter tolerance	Weak	Strong; the latency buffer buys recovery time
Latency	Low on a clean LAN, unstable once it hits the internet	Configurable and more predictable across networks
Encryption	RTMPS (TLS)	Built-in AES scrambling
Platform support	Almost every live platform accepts it	YouTube and others accept SRT input; many platforms still only take RTMP

Put simply: RTMP works; SRT works on bad networks too. On a clean link they are close. On a poor one the difference shows.

Four mechanisms that make SRT work

• ARQ retransmission: the receiver notices missing packets and asks for them again, so the picture stays together.
• Latency buffer: a deliberate buffer that gives retransmitted data time to arrive. This is the most important parameter in SRT.
• AES encryption: 128 or 256 bit, so contribution over the internet does not need a VPN.
• Decoupled from encoding: changing transport does not mean changing devices.

How to set latency (starting points)

This is where most installations go wrong: set it too low and retransmission cannot keep up, so the picture breaks anyway; set it too high and you simply add delay. Start at two to four times the link RTT.

Link type	Starting latency	Notes
Metro private line or LAN	40-80 ms	Stable enough to trade buffer for latency
Domestic long-haul internet	100-200 ms	The most common range
International internet	300-600 ms	High RTT; the buffer has to be generous
4G / 5G mobile contribution	200-400 ms	Take the upper end and keep bandwidth headroom

All of these are starting points and must be measured: run at the starting value, watch loss and artefacts, then reduce step by step to the lowest value that stays stable.

Three misconceptions

• "SRT saves bandwidth" — it does not. Retransmission consumes extra bandwidth. If upstream is short, SRT cannot help; lower the bitrate.
• "With SRT it never drops" — SRT solves network problems. Crashes, overheating and power faults are still yours to handle.
• "SRT is always lower latency" — SRT aims for stability, not minimum delay. For true zero-latency, use uncompressed optical transport on a LAN.

When to use RTMP and when to use SRT

Scenario	Recommendation
Pushing to platforms that only accept RTMP	RTMP / RTMPS
Field contribution back to a facility or cloud production	SRT
Long distance, cross-region or international	SRT
4G / 5G contribution and temporary links	SRT
Zero latency inside one building	Uncompressed optical transport, not either of these

Real projects usually mix the two: SRT back to the facility, then RTMP or RTMPS out to each platform. Multi-stream encoders can push to different destinations with different protocols at the same time.

How our equipment supports it

Depending on model, our encoders support RTMP / RTMPS / SRT / HLS / TS / RTSP / RTP / UDP / ONVIF, for example the ZY-EH1401 4K encoder and the ZY-EH1304 4-channel encoder.

If your platform only accepts RTMP but the field link is only usable with SRT, deploy an encoder and decoder pair: SRT across the difficult segment, standard streams at the far end.