SRT is a transport protocol for moving live audio and video between compatible endpoints over IP networks. It uses UDP and adds packet-loss recovery, jitter handling, a configurable latency buffer and optional encryption; it does not encode your video or remove limits in the network between the endpoints.
Use SRT when those recovery and control features address a real contribution link problem, especially across a variable public network. Before choosing it, check the endpoints, firewall path, available bandwidth and acceptable delay: its benefits depend on compatible configuration and room in the connection to do the recovery work.
What SRT Does
SRT stands for Secure Reliable Transport. It is an open-source transport protocol designed for live media, typically used to carry a stream from one site or system to another. “Reliable” describes mechanisms for handling some network problems; it is not a promise that every packet will arrive or that a stream will remain uninterrupted.
It helps to separate transport from the rest of a live workflow. A camera, file player or production application produces and encodes media. SRT moves that media to another compatible application or device. A separate downstream system may then record it, distribute it to viewers or send it to another platform. SRT alone does not encode a camera signal, create a viewer-facing website, or provide adaptive-bitrate playback.
For example, a small broadcaster might send a programme feed from a venue to a studio over an internet connection. The studio receives the SRT feed and uses its production system to record it or prepare a separate broadcast. That is different from asking SRT itself to create a public YouTube channel or deliver a finished stream to every viewer.
SRT is worth considering when a path is variable enough that packet recovery, jitter control or configured encryption would solve a specific problem. On a protected local network with little packet loss, a simpler transport may be sufficient. The right choice depends on the link and the destination workflow, rather than on a claim that one protocol is best in every case. The SRT project documentation and its deployment guide describe the protocol and practical setup considerations.
How SRT Moves Live Audio and Video
The source divides the media into packets and sends them to a destination using UDP. Alongside the media, the endpoints exchange control information about packet delivery and network conditions. UDP does not itself arrange retransmission in the way a reliable byte-stream protocol does, so SRT adds its own mechanisms to manage recovery and timing.
The receiving endpoint can identify missing packets and report them so the sender can retransmit. The receiver also uses a buffer to manage the timing of incoming media. That buffer gives a requested packet some time to arrive before the media is due for playback. If it arrives in time, the receiver may be able to present a more complete stream; if it arrives too late, the buffer window has been exceeded.
This explains why SRT can help on a lossy or jittery route without making the route itself better. It cannot create capacity where the connection is congested, restore a broken internet connection, or make incompatible endpoints communicate. Packets still need a usable path in both directions for the control and recovery exchanges.
The protocol also supports AES encryption when configured. Both endpoints must use compatible encryption settings and the same passphrase. FFmpeg’s SRT protocol documentation describes its passphrase option and specifies that, for FFmpeg, an enabled passphrase is 10 to 79 characters long. That is an FFmpeg-specific documented constraint, not a universal setting for every SRT product. Encryption can also use endpoint processing capacity, so test it in the actual workflow rather than assuming it has no operational cost.
SRT implementations may also offer additional recovery approaches. The Haivision project describes a packet-filter API and a Forward Error Correction (FEC) plugin with FEC-only, ARQ-only or combined modes. Do not assume FEC is active simply because a product supports SRT: it is an implementation capability that must be available and configured at the endpoints.
Packet Loss, Recovery and Jitter
SRT’s primary packet-recovery mechanism is Automatic Repeat reQuest, usually shortened to ARQ. In practical terms, the receiver detects a missing packet and asks the sender to transmit it again. The sender must still have the packet, the request must get back across the network, and the retransmission must reach the receiver in time to be useful.
That last condition is central. Recovery takes time and uses network capacity. If packets arrive late or out of order, the latency buffer can give SRT more time to put the media back into sequence. A larger recovery window can allow more retransmissions to arrive before playback, but it also adds transport delay. There is no setting that makes these trade-offs disappear.
Jitter means that packet arrival times vary. A buffer smooths some of that variation by holding packets rather than immediately passing each one on. If variation or loss exceeds what the configured window and available connection can accommodate, the receiver may still have late or missing media. You should treat an increase in latency as a chance to handle some late packets, not as a guarantee of complete recovery or steady quality.
A useful troubleshooting example is a feed that develops skipped frames during busy periods. First compare packet loss, retransmissions, round-trip time, bitrate and buffer behaviour at both endpoints. If the path is congested, reducing the video bitrate may help by reducing demand; if packets are arriving late but the connection has room, a larger latency setting may be worth testing. Increasing recovery bandwidth overhead is another possible adjustment where the implementation supports it, but it consumes more capacity and does not fix an undersized or unstable link.
Measure changes rather than making several at once. If you raise the latency window and reduce bitrate together, it becomes harder to tell which change helped. Keep a record of the observed conditions and the relevant settings, and compare results during the times the link is most likely to be stressed. The 24/7 music stream settings checklist is useful for thinking through the separate YouTube-side output settings; those settings do not replace SRT link tuning.
Caller, Listener and Rendezvous Roles
Caller and listener describe how endpoints establish a connection, not which one is the media source. In caller mode, one endpoint initiates the connection. In listener mode, the other endpoint waits for an incoming connection. A caller can be the sender or receiver of media, depending on the workflow, so do not infer the direction of the video from the mode name.
Rendezvous is a third connection mode in which both endpoints coordinate connection attempts. It can suit some network arrangements, but it does not automatically solve firewall, NAT or filtering issues. Whether it works depends on the endpoints and the network path available to them.
Before configuring the roles, decide which device or application can initiate a connection and which can accept one. Then establish the destination address and port, and check the network rules on both sides. SRT uses bidirectional UDP; a firewall that permits one direction but blocks the return traffic may prevent the control exchanges or recovery requests from working as expected.
NAT, port forwarding and filtering requirements depend on the topology. A destination behind a router may need an accessible port or a network rule, while a managed corporate network may restrict UDP traffic. Ask the network administrator to confirm the allowed path rather than assuming SRT will pass through because ordinary web browsing works. Where the endpoints are both behind restrictive networks, test rendezvous only if both implementations support it and the network rules allow the required traffic.
Write down the role, address, port and encryption settings for each endpoint. This simple handover note helps when one person configures the sender and someone else manages the receiver. It also prevents a common class of setup errors: each endpoint can be individually configured, yet disagree about which one should wait, which one should initiate, or which secret to use.
How Latency Is Managed
SRT latency is a configured recovery window, not a universal end-to-end delay figure. It is only one part of the time between a source producing a frame and a viewer seeing it. Encoding, other buffers, processing at the receiver and any downstream distribution all add their own delay.
The deployment guide explains that its described configuration uses the higher of the source and destination latency settings. That makes it important to inspect both endpoints: changing one value alone may not produce the behaviour you expect. Different products may expose or interpret settings differently, so confirm the implementation’s documentation and test the actual result.
Think of latency as a trade-off between responsiveness and recovery opportunity. If the production is interactive, a long delay may be unacceptable. If the feed is a one-way contribution link where a modest additional delay is tolerable, allowing more time for retransmissions may be useful. Neither case has a single correct setting without knowing the path’s round-trip time, loss, bitrate and buffer behaviour.
Available bandwidth matters as well. FFmpeg documents a recovery bandwidth overhead option with a default of 25 percent. That is the default for that FFmpeg option, not a general SRT default or a guarantee about the amount of additional traffic every SRT implementation will use. Check the tool you are running and monitor actual send and receive statistics instead of applying a number from another product’s documentation.
Start with the smallest acceptable delay for the workflow, then observe the connection under realistic conditions. If late or skipped packets recur, check whether the link can support the bitrate and recovery traffic before increasing the buffer. If delay becomes troublesome, reducing the buffer may make the stream more responsive but leave less time for packets to recover. Every adjustment exchanges something; keep the trade-off visible to whoever watches or operates the output.
When SRT Is a Good Fit
SRT is a strong candidate for contribution between locations across a public or otherwise variable IP connection, particularly when packet recovery, jitter control and encryption matter more than the minimum possible transport delay. Examples include sending a live event feed from a venue to a studio, aggregating feeds from several sources, or moving a stream into a recording or IPTV workflow. In each case, the receiving side must have an SRT-capable application, device or gateway.
It may be unnecessary on a stable, protected LAN or WAN where packet loss is limited and the existing transport meets the need. If a simple UDP path already works and there is little loss to recover from, SRT’s extra configuration and recovery traffic may add complexity without solving a real problem. Choose based on observed conditions and required behaviour, not on the protocol name alone.
SRT also occupies a different place in the workflow from viewer delivery protocols. It can carry a feed between production systems, while another system may prepare a stream for YouTube or deliver segmented HTTP playback. It should not be described as a universal replacement for HLS, RTMP or WebRTC: those technologies are used in different parts of live production and distribution.
For an always-on YouTube channel built from a recorded video, first decide whether you need an SRT contribution link at all. If your problem is simply keeping a prepared file live without leaving a computer running, that is a different task from transporting a live feed between two sites. A guide to looping a video with FFmpeg for YouTube Live covers a local workflow, while streaming recorded Hindi bhajans around the clock is more directly relevant to that channel format. SRT does not itself turn an uploaded file into a YouTube broadcast.
What to Check Before Deployment
Check the entire path before an event or an unattended run. Confirm that the source can send SRT and the destination can receive it, or that the relevant applications support the same workflow. Verify any required container, codec and media-format compatibility separately: transport support alone does not guarantee that a destination can decode the carried media.
Next confirm the network path. Identify caller, listener or rendezvous roles; agree on the address and port; and check that bidirectional UDP, firewall rules and any NAT or port-forwarding arrangements are in place. Do a test from the actual networks that will be used, since a setup that works on an office LAN may fail from a venue or mobile connection.
Set latency and bitrate with the workflow in mind. Measure or observe round-trip time, packet loss, retransmissions and buffer behaviour at both endpoints. Leave enough bandwidth for the media and any recovery traffic, while recognising that spare capacity on a speed test does not prove that a path will remain clear during a busy period. If the route is constrained, a lower media bitrate may be more useful than simply requesting more recovery traffic.
If enabling encryption, agree the passphrase securely and make sure both endpoints use matching options. Avoid putting secrets in shared screenshots or public configuration notes. Check whether encryption affects the processing capacity of either device, particularly if it is already near its limits with encoding or decoding.
Monitor stream state, bitrate, packet loss and retransmissions, round-trip time, latency, and send/receive buffers. Rising errors, repeated reconnections, frequent late packets or buffers that regularly reach the configured window are reasons to investigate capacity and configuration. Keep a record of the baseline and change one setting at a time. The practical guide to checking audio sync during a long ambient stream also illustrates why long-running streams need observation over time rather than a brief successful start test.
Finally, decide who will notice a problem and what they can do about it. For a contribution feed, that may mean a person at the receiving end can check statistics and contact the source operator. For an unattended channel, have a fallback plan that does not depend on assuming the protocol will recover from every fault. Rehearse a restart and a configuration correction before relying on the path for a live programme.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
What is SRT streaming?
SRT streaming means carrying live audio or video between compatible endpoints using the Secure Reliable Transport protocol. It uses UDP and adds mechanisms for packet-loss recovery, jitter handling, latency buffering and optional encryption. It is transport, not a complete encoding or viewer-distribution service.
What is the difference between SRT caller and listener?
A caller initiates the connection, while a listener waits for the incoming connection. Those names describe connection establishment, not whether the endpoint sends or receives the media. The network must still allow the required UDP traffic in both directions.
How much latency does SRT add?
There is no fixed figure that applies to every SRT stream. The configured latency window gives packets more or less time for recovery, while encoding, processing and downstream delivery add further delay. Measure the workflow and tune against observed round-trip time, loss and buffer behaviour.
Does SRT guarantee packet recovery or work through firewalls automatically?
No. Retransmission can help when the endpoints, buffer window and network path allow packets to arrive in time, but it cannot overcome a broken or inadequate connection. Firewall, NAT and port rules depend on the topology and must be checked for the actual deployment.