SRT (Secure Reliable Transport)

What it is

SRT (Secure Reliable Transport) is an open-source streaming protocol. Originally developed by Haivision and released as open source in 2017, when Haivision and Wowza founded the SRT Alliance, it is now widely supported in professional encoders and decoders, OBS, FFmpeg, VLC and commercial broadcast gear. The design point is "deliver low-latency video reliably over the public internet" — networks where packet loss is normal, jitter is unpredictable, and TCP-based protocols either stall or drop frames.

What SRT does that other transports don't

• Forward error correction and ARQ. Lost packets are either reconstructed from FEC redundancy or selectively retransmitted within a tight latency budget. RTMP relies on TCP retransmission alone, with no FEC and no latency bound, so a lossy link stalls the stream instead.
• Tunable latency target. The sender and receiver negotiate a target end-to-end latency (typically 120 ms to 2 seconds). The protocol then trades recovery effort against that budget. Operators tune this per link.
• AES-128 / AES-256 encryption. Built into the transport, no separate VPN required. For paid contribution feeds and any cross-organisation transport, this matters.
• Firewall traversal. SRT runs over UDP with simple NAT-friendly modes (caller / listener / rendezvous). Crosses corporate firewalls more reliably than the older RTMP / RTSP options.

Where SRT fits in a video-wall context

On-prem video walls inside a single facility do not need SRT — local NDI, IPMX, RTSP or KVM are the right tools at that tier. SRT becomes relevant in three specific situations:

• Remote sources over the public internet. A wall in the head-office NOC ingesting a stream from a remote operations site, or a corporate event venue pulling a contribution feed from an off-site studio. SRT is the standard transport for this.
• Wall-to-wall federation across facilities. Two control rooms sharing a subset of sources between them. SRT carries the cross-facility feeds; each wall renders local + remote together.
• Broadcast contribution into an on-prem wall. Live sports / news control rooms pulling field-of-play feeds via SRT before the in-house production fabric takes over.

Common pitfalls

• Latency budget set too tight. 120 ms over a flaky link means SRT can't recover and you see drops. The right starting point for public-internet links is 500 ms; tune down only when the link metrics support it.
• Encryption key management. AES-256 is cheap to enable and free, but if the keys live in screenshots in Slack threads the encryption is theatre. Treat SRT keys like SSH keys.

Related terms

• NDI (Network Device Interface)
• NDI HX
• AV over IP
• IPMX