SRT is a transport protocol for moving live video and audio between compatible endpoints over an IP network. It can recover some lost packets, manage jitter and encrypt media payloads, but it cannot make an inadequate connection unlimited or guarantee uninterrupted video.
Its value depends on the path, the endpoints and the latency budget you choose. If you are considering SRT for a contribution link, the practical question is not whether it is reliable in the abstract, but whether its recovery mechanisms have enough time and bandwidth to suit your workflow.
What SRT Is and Where It Fits
Secure Reliable Transport, usually shortened to SRT, sits between media-processing endpoints. One endpoint sends an encoded video and audio stream, and another receives it for production, distribution, recording or onward delivery. SRT is responsible for transporting the stream across the network; it is not a video codec and it is not a complete production platform.
That distinction matters. A camera, encoder or software application still has to create the media. A decoder, production system or streaming platform still has to receive and use it. SRT connects those parts and adds transport behaviour intended for unpredictable IP networks.
The Haivision SRT project on GitHub describes the protocol as providing error recovery, latency management and encryption for live media transport. The same project identifies Automatic Repeat reQuest, or ARQ, as its primary loss-recovery method. SRT also supports Forward Error Correction and connection bonding, but those are design choices rather than features that every stream automatically uses.
A simple example is a remote event. An encoder at the venue sends an SRT stream to a compatible receiver at a production location. The receiver can request missing packets, hold arriving packets in an appropriate buffer and decrypt the media payload if both ends have been configured to use encryption. The production team then works with the recovered feed.
SRT is therefore best understood as a set of transport mechanisms. It improves the chances of delivering a usable feed across a changing network, while leaving you responsible for selecting suitable equipment, settings and network capacity.
Why SRT Uses UDP
SRT uses UDP as its underlying network transport rather than relying on TCP to deliver the media. UDP does not provide TCP’s built-in ordered, reliable delivery of every packet. That sounds like a weakness, but it gives a media transport more control over how loss, delay and recovery are handled.
Live video has a deadline. A packet that arrives after the decoder has moved past the relevant moment may be less useful than a packet that is recovered quickly, or than a later packet that keeps the stream moving. A transport designed specifically for live media can make decisions around timing instead of leaving all delivery behaviour to a general-purpose reliable connection.
SRT adds its own delivery logic above UDP. It tracks packets, observes the exchange between the endpoints and lets the receiver report missing data. The sender can then retransmit selected packets when the configured timing allows it. This is different from treating UDP as an unmonitored stream of unrelated datagrams.
UDP does not remove the need for a healthy path. The connection still needs enough available bandwidth for the encoded stream, protocol overhead and retransmitted data. Congestion, queueing, routing changes, radio interference or a failing local network can still create loss and delay. SRT can respond to those conditions, but it cannot create capacity that the path does not have.
There is also a practical endpoint requirement. Both sides need to understand SRT and agree on the relevant connection details. An ordinary UDP receiver is not automatically an SRT receiver, and a device that advertises SRT support may expose only a particular subset of settings. Confirm compatibility before choosing a workflow.
How Retransmission Recovers Lost Packets
The central SRT recovery cycle is straightforward. The sender transmits numbered packets. The receiver notices when a packet is missing from the sequence and sends a request for that packet. If the sender still has the data and there is enough time in the configured latency window, it retransmits the packet.
This is ARQ: Automatic Repeat reQuest. It is not a promise that every lost packet will always be recovered. A request may arrive too late, the sender may no longer retain the packet, the path may remain impaired, or there may not be enough latency budget before the media must be played.
The trade-off is easiest to see with a live interview. If a small burst of packets is lost but the receiver has time to wait, retransmission may prevent visible or audible damage. If the same loss occurs while the receiver is operating with an extremely tight delay target, waiting for a round trip may be impossible. The feed may then continue with a gap, concealment or another behaviour determined by the decoder and production system.
Retransmission also consumes bandwidth. The original stream continues while missing data is sent again, so the path needs some headroom above the normal encoded bitrate. A connection that is already running at its practical limit may become less stable when recovery traffic is added.
SRT documentation also refers to FEC, or Forward Error Correction. FEC sends additional information that can help reconstruct lost data without waiting for an individual retransmission. It can be useful when the path or use case makes waiting undesirable, but it adds overhead and is not automatically the right choice. The endpoint documentation and the expected loss pattern should determine whether FEC belongs in the design.
Connection bonding is another capability identified by the SRT project. It can be relevant where a workflow combines paths or needs additional redundancy, but it should not be treated as an automatic property of every SRT connection. You need endpoints and network arrangements that support the intended mode.
For testing, inspect more than whether the stream eventually connects. Check what happens during a brief loss event, whether the receiver reports recovery, how much delay accumulates and whether the stream remains within the production’s tolerance. A quiet test on a clean network cannot establish how the link will behave during congestion.
Jitter Handling and Latency Budgets
Network packets do not necessarily arrive at evenly spaced intervals. Some may be delayed in queues, while others arrive promptly. This variation is jitter. If the receiver immediately passed every packet to the decoder as it arrived, the media could stutter even when the average bandwidth looked sufficient.
SRT manages this problem with timing and buffering. The receiver can hold packets briefly so that late packets have an opportunity to arrive in sequence. That same holding period gives ARQ retransmissions time to return. The result is a more usable stream when the network has moderate variation, but it also adds delay.
This is why low latency is conditional. The SRT documentation describes SRT as a low-latency live transport protocol, but that does not establish one universal delay for every workflow. End-to-end delay also includes encoding, decoding, buffering, routing and processing in the systems around SRT.
Think in terms of a latency budget rather than a single setting. First decide how much delay the production can tolerate. A remote contribution for a recorded programme may tolerate more delay than a two-way interview where the presenter must respond naturally. Then account for the network’s round-trip behaviour, expected jitter, encoding pipeline and downstream buffers.
A larger SRT latency setting generally gives retransmitted packets more time to arrive before playback reaches the affected point. That can improve recovery opportunities on a variable path, but it makes the feed less immediate. A smaller setting reduces delay while leaving less time for a request and retransmission cycle.
There is no honest universal setting to copy into every encoder. The right value depends on the path and the use case. Test from the actual venue or network, not only from an office connection, and repeat the test at the times when congestion is most likely.
When you evaluate the result, watch for both kinds of failure. A stream may look clean but be too delayed for live interaction. It may also respond quickly but show loss when the network varies. Reliability and immediacy pull in different directions because recovery requires time.
What AES Payload Encryption Protects
SRT can use AES encryption to protect the payload of the media stream between configured endpoints. In practical terms, this is intended to prevent an unauthorised party observing the transported video and audio as it crosses the network, provided encryption is enabled and the endpoint settings are correctly matched.
The Haivision SRT product overview describes SRT encryption as part of contribution and distribution workflows. Treat that as payload protection, not as a complete security boundary around your broadcast operation.
SRT encryption does not automatically secure the encoder computer, receiver, production workstation, cloud account or local network. It does not protect a stream key that has been pasted into an exposed document, and it does not replace operating-system updates, access controls or careful handling of credentials.
Passphrases and encryption settings need a process. Decide who may configure each endpoint, store the required values in an appropriate password manager or secret store, and avoid sharing them through public chat or unprotected documents. Check whether both endpoints support the same encryption mode and passphrase requirements before putting the link into production.
You should also separate SRT security from YouTube account security. If your workflow eventually sends the received feed to YouTube, the YouTube stream key remains a credential for that destination. Our guide on how to revoke a leaked YouTube stream key explains the response if that key is exposed.
Encryption can protect media in transit while the file, encoder or receiver remains accessible to someone who should not have access. Review the whole path, including who can log into the endpoints and who can change the stream destination.
Endpoint Compatibility and Network Requirements
Before buying hardware or changing a production workflow, make a list of the actual endpoints. Identify the sender, receiver, encoder, decoder, production software and final distribution system. Then verify SRT support for each connection where you expect to use it.
The project provides an open-source library and sample applications, including srt-live-transmit. Haivision also documents SRT support on its Makito X Series encoders and decoders. These examples show the range of implementation options, from software endpoints to dedicated hardware, but they do not mean that every device or application supports every SRT feature.
Check the following points with the current endpoint documentation:
| Question | Why it matters |
|---|---|
| Do both ends support SRT? | A sender and receiver must speak the same transport protocol. |
| Which connection mode is available? | The endpoint’s supported mode affects how the link is initiated and exposed through firewalls or network address translation. |
| Are the latency and encryption settings compatible? | Mismatched settings can prevent connection or produce an unsuitable feed. |
| Is the path open in the required direction? | Firewalls, routers and managed networks may block the traffic or prevent one endpoint reaching the other. |
| Is there bandwidth headroom? | The stream needs capacity for normal media, overhead and possible recovery traffic. |
| Does the software or hardware expose the required features? | SRT support alone does not confirm FEC, bonding, monitoring or the controls you need. |
Do not confuse an SRT connection with permission to reach the final platform. If the receiver is forwarding media to YouTube, you still need a working YouTube live setup and the correct channel permissions. For a separate channel workflow, see how to enable YouTube Live streaming after changing channel settings.
Firewall and routing work should be tested from the real network. A venue may restrict inbound traffic, a mobile connection may change its address, and a corporate network may apply policies that are not visible from a home test. Document which endpoint initiates the connection and what network changes are needed before the event.
Monitoring should cover the whole chain. Record whether the SRT session is connected, whether packets are being lost or recovered, how much delay is present and whether the receiver is delivering usable media. A green connection indicator alone does not prove that the decoded output is clean.
If your eventual destination is an always-on YouTube channel, transport is only one part of the design. You may also need to consider the source material, broadcast continuity and platform rules. Our guide to streaming pre-recorded video to YouTube Live from a cloud server covers a different workflow, but it illustrates why the transport link should be assessed as part of the complete chain rather than in isolation.
When SRT Is a Good Fit
SRT is a sensible candidate when you need to move live media between known, compatible endpoints across a network whose delay and packet delivery may vary. A remote contribution link, venue-to-studio feed or controlled distribution path can benefit from having recovery, jitter handling and payload encryption in the transport layer.
It is particularly worth considering when a plain unprotected transport does not provide enough control, but a highly specialised contribution system is not appropriate for the workflow. Software-based SRT may suit a team that already has compatible production tools. Dedicated SRT hardware may suit a team that needs a purpose-built encoder and decoder, provided the equipment fits the budget and operational requirements.
SRT is less suitable when one or both endpoints cannot support it, when the path has no practical bandwidth headroom, or when the production cannot tolerate the delay needed for recovery. It is also not a substitute for solving a failing local network, an overloaded encoder or an unsuitable source bitrate.
Ask these questions before committing:
- What happens to the feed when packets are lost for a short period?
- How much delay can presenters, operators and viewers tolerate?
- Is the expected path stable enough for retransmission traffic?
- Would FEC or path redundancy be useful, and do the chosen endpoints support it?
- Who will configure and protect the encryption passphrase?
- Can the team monitor the connection and act when the feed degrades?
- Is software sufficient, or does the workflow require dedicated encoder and decoder hardware?
For a small devotional channel, study station or local news loop, SRT may be unnecessary if the source and destination are in the same reliable environment and the platform’s own ingest method is sufficient. For a contribution feed crossing a variable network, it may be worth testing because its mechanisms address specific transport problems. The test should use the actual endpoints, path and operating conditions.
If the goal is simply to turn an uploaded file into a continuous YouTube broadcast without leaving a computer running overnight, a transport protocol may be solving the wrong problem. StreamNeo removes that particular operational burden by letting you upload the file, add the YouTube stream key and leave the broadcast running without your computer switched on. That is a different use case from carrying a live contribution feed between production endpoints.
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
Does SRT guarantee uninterrupted video?
No. SRT can request retransmission and manage jitter when the endpoints and network provide enough time and capacity. Severe loss, insufficient bandwidth, incompatible settings or too little latency budget can still interrupt or degrade the feed.
Is SRT a codec?
No. SRT is a transport protocol. Your encoder still creates the video and audio using a codec, while the SRT endpoints carry that media across the IP network.
Does SRT provide zero-latency streaming?
No. SRT manages latency rather than removing it. Buffering and retransmission need time, and total delay also comes from encoding, decoding, routing and downstream systems.
Does SRT encryption secure the whole broadcast workflow?
No. AES can protect the media payload between configured SRT endpoints, but it does not secure endpoint computers, credentials, production accounts or the final platform. Protect passphrases and stream keys separately, and review access across the complete workflow.