# Haivision SRT: the open source transport protocol for sub-second live video

> SRT is an MPL-2.0 licensed transport protocol implemented in C++ for low-latency live video and bulk data over unreliable networks. This review covers what it does, how the ARQ and FEC mechanisms work, how to build it from source, and where it stops being the right tool.

**Haivision/srt** — Secure, Reliable, Transport

- Repository: https://github.com/Haivision/srt
- Website: https://www.srtalliance.org
- Stars: 3,608 · Forks: 943
- Language: C++
- License: MPL-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/haivision-srt

## What SRT solves, and who ends up using it

TCP retransmits lost packets and backs off when the network congests, which is fine for a file transfer and fatal for a live camera feed. UDP does the opposite: it drops packets and keeps going, leaving holes in the picture. SRT sits between the two. Its own description calls it a transport protocol for sub-second latency live video and audio streaming, as well as generic bulk data transfer, and the three letters stand for Secure, Reliable, Transport.

The people who reach for it are the ones moving contribution feeds: a camera or encoder at a stadium, a satellite hop, a hotel network, feeding a broadcast facility or a distribution endpoint. The README frames it as part of a video stream workflow that delivers the best quality and lowest latency video at all times. Because SRT operates at the network transport level as a wrapper around your content, it does not care which codec or container you put inside it. That payload-agnostic design is why it shows up in encoders, decoders, gateways and players from many vendors rather than in one product line.

It is not a media framework. There is no transcoding, no session description, no player UI in the library itself. You get a socket-like API, a set of tuning parameters, and the sample applications in the repository to show how they fit together.

## ARQ, FEC and bonding: the mechanism underneath

The primary recovery method is Automatic Repeat reQuest. The README describes it plainly: when a receiver detects that a packet is missing it sends an alert to the sender requesting retransmission of this missing packet. That is a feedback loop, so it costs one round trip per repair, which is why the latency you configure has to be at least as large as the time it takes to notice a loss and get the replacement back. SRT maintains a constant end-to-end latency rather than letting a buffer grow, so the trade is explicit: you choose a latency budget, and the protocol spends it on recovery.

Forward Error Correction is the second mechanism, and the README is careful about when it helps. FEC is exposed through a packet filter API introduced in SRT 1.4, which allows custom processing on packets at the sender before they are sent and at the receiver once they arrive. The FEC plugin that ships as the first example of that API has three modes: ARQ only, FEC only, and FEC plus ARQ, where retransmission covers what FEC fails to recover. The README notes FEC can offer slightly lower latency than ARQ in certain use cases, which is a narrower claim than vendors usually make. FEC buys recovery with added overhead on every packet, so it is a poor fit when bandwidth is the scarce resource rather than round-trip time.

Connection bonding is the third piece, documented separately in docs/features/bonding-quick-start.md. The README describes it as adding stream protection and hitless failover, which in practice means carrying a stream across more than one network path so that losing one path does not lose the feed. Encryption is handled by AES at 128, 192 or 256 bits, protecting the payload end to end. Rendezvous mode is the connection setup trick for the firewall problem: the handshake supports outbound connections without opening a permanent exterior port, which keeps the stream inside existing LAN security policy.

## Building Haivision SRT from source and sending a first stream

The repository is a CMake project. CMakeLists.txt sits at the top level, and the README points to a Build Instructions section rather than shipping binaries, so the path in is to clone the repository with its submodules and configure it. The repository has a .gitmodules file and a submodules directory, so a plain clone without submodule initialisation is the first thing that goes wrong.

```bash
git clone --recursive https://github.com/Haivision/srt.git
cd srt
./configure
make
```

The configure script at the top level wraps the CMake configuration, and make builds the library plus the applications in apps/. The project also publishes packages through distribution channels: the README carries badges for Ubuntu, Fedora, Debian, Homebrew, Vcpkg and ConanCenter, so on those platforms you can install a packaged build instead of compiling. If you are consuming SRT from C++ rather than running the tools, the CMakeLists.txt and cmake_object_lib_support.c files are what you link against.

Once built, the sample applications are the fastest way to see traffic move. The examples directory holds sendmsg.cpp, recvmsg.cpp, sendfile.cpp, recvfile.cpp and recvlive.cpp, and apps/ contains the srt-live-transmit and srt-ffplay tooling referenced by the repository (the top level also carries an srt-ffplay entry). The C API examples are the ones to read if you are writing a binding: test-c-client.c and test-c-server.c are a matched pair, and test-c-client-bonding.c and test-c-server-bonding.c show the bonding variant. The non-blocking client in examples/example-client-nonblock.c is the reference for integrating SRT into an event loop rather than blocking on a call.

A minimal C client follows the shape of test-c-client.c: create the socket, set the connection options, connect, then send. What you should see when a receiver is listening is a connected socket and packets arriving; if the handshake fails, the error surfaces at connect time rather than silently at send time.

## Where SRT is the wrong choice

SRT is a point-to-point transport. The README describes it as applied to contribution and distribution endpoints, and nothing in the repository suggests a built-in fan-out mechanism. If you need one ingest to serve thousands of viewers, SRT is the link from the source to your origin, not the delivery layer to the audience. Reaching for it as a CDN replacement is a category error.

The second limitation is that recovery costs latency. ARQ needs a round trip, and the README's claim of constant end-to-end latency only holds if you configured a latency budget large enough for that round trip on the actual path. On a satellite link or a long intercontinental hop, the round trip alone can exceed what a sub-second target allows, and FEC's overhead starts competing with the bandwidth you have. The README's own wording, that FEC can offer slightly lower latency than ARQ in certain use cases, should be read as a conditional, not a default.

The third is operational. Rendezvous mode exists because firewalls are a real obstacle, but the README frames it as a way to avoid opening permanent exterior ports, not as a guarantee that any two endpoints will connect. If both sides sit behind symmetric NAT without a rendezvous point, the handshake is the thing that fails. And because SRT is a library that many products embed, two endpoints that both say SRT may still disagree on version or on the parameters each side exposes. Version skew between an encoder and a receiver is a common source of handshake failures, and the release history in this repository moves quickly: v1.5.5 in April 2026, v1.5.6 in July 2026, v1.5.7 in August 2026.

## SRT against RIST and plain RTMP

The closest comparison is RIST, the Reliable Internet Stream Transport specification from the Video Services Forum. Both target the same problem, contribution over lossy links, and both use retransmission with a receiver feedback channel. The difference is governance and packaging: SRT is a single open source implementation under MPL-2.0 with a published Internet Draft, while RIST is a specification with multiple vendor implementations behind it. If you need to pick an implementation from several suppliers and hold them to a common spec, RIST's structure is the argument in its favour. If you want one codebase you can read, patch and build today, SRT is the shorter path.

Against RTMP the difference is starker. RTMP runs over TCP, so it inherits head-of-line blocking: one lost segment stalls everything behind it until the retransmission arrives. That is tolerable when you are willing to buffer several seconds, which is why RTMP survives in ingest to platforms that add their own latency. It is not tolerable when the requirement is sub-second. SRT's use of UDP with its own recovery layer is precisely the design choice that removes that stall.

Against plain UDP with no recovery, SRT adds the retransmission machinery, the encryption and the congestion adaptation. The cost is that both ends must speak SRT. A receiver that only understands raw RTP will not accept an SRT stream.

## Licence, releases and what upgrading costs

SRT is licensed under MPL-2.0, the Mozilla Public License version 2.0, and the LICENSE file sits at the repository root. MPL-2.0 is file-level copyleft: modifications to files already covered by the licence must be made available under the same licence, while larger works that combine SRT with other code can generally be distributed under other terms. That is a materially different obligation from a permissive licence, and it matters most if you patch srtcore/ or haicrypt/ and ship the result. This is a description of the licence text, not legal advice; get your own review before shipping a modified build.

The release cadence is the practical cost. Three releases landed between April and August 2026, and the last push to the default branch was on 2026-09-16. If you vendor a build, you are signing up to track that cadence, because a protocol implementation is only useful when both ends interoperate and fixes to the handshake or to loss recovery land in new versions. The cheap option is to consume SRT through a distribution package (the README links Ubuntu, Fedora, Debian, Homebrew, Vcpkg and ConanCenter) and let the package manager carry the upgrade. The expensive option is a vendored build with local patches, which turns every upstream release into a rebase.

Documentation lives in docs/, with feature pages such as docs/features/packet-filtering-and-fec.md and docs/features/bonding-quick-start.md. The README does not document a rollback procedure for a version upgrade, so plan for that yourself: pin the version, keep the previous build, and test the handshake between your actual endpoints before moving production traffic.

## Conclusion

Adopt SRT when you are moving a live contribution feed across a network you do not control and you can afford a latency budget large enough for a retransmission round trip; the sample applications in examples/ and apps/ let you verify that on your own path before committing. Do not adopt it as a distribution layer to many viewers, and do not expect it to fix a link where the round trip alone exceeds your latency target. Before rollout, confirm that both endpoints speak a compatible SRT version, since the project shipped v1.5.5, v1.5.6 and v1.5.7 between April and August 2026, and test the handshake through your actual firewall configuration rather than assuming rendezvous mode will traverse it.

## FAQ

### What is the SRT streaming protocol?

Secure Reliable Transport is a transport protocol for sub-second latency live video and audio, and for generic bulk data transfer. It runs over UDP and adds its own recovery layer, AES encryption and adaptation to changing network conditions, so it does not inherit TCP's head-of-line blocking.

### Can VLC receive SRT?

This repository does not cover VLC's support for SRT. It does ship an srt-ffplay entry at the top level and a recvlive.cpp example, which are the receiving tools documented in this project.

### Is Haivision SRT open source, and under what licence?

Yes. The code is on GitHub under MPL-2.0, the Mozilla Public License version 2.0, with the LICENSE file at the repository root. It is also published as an Internet Draft.

### How do I install Haivision SRT?

Clone the repository with its submodules, then run ./configure followed by make, since the project is a CMake build with a top-level configure wrapper. The README also links packages for Ubuntu, Fedora, Debian, Homebrew, Vcpkg and ConanCenter.

### How does SRT recover lost packets?

Its primary method is Automatic Repeat reQuest: the receiver detects a missing packet and asks the sender to retransmit it. Forward Error Correction, exposed through the packet filter API introduced in SRT 1.4, is an alternative that can offer slightly lower latency in certain use cases.

## Sources

- [Haivision/srt on GitHub](https://github.com/Haivision/srt)
- [License: MPL-2.0](https://github.com/Haivision/srt/blob/master/LICENSE)
- [Project website](https://www.srtalliance.org)
- [README](https://github.com/Haivision/srt/blob/master/README.md)
- [Releases](https://github.com/Haivision/srt/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/haivision-srt