SRT carries an already encoded live stream from one endpoint to another. It does not capture video or encode it; your camera, capture device, encoder or streaming application must prepare the media first.
A reliable SRT setup starts with the connection rather than the picture quality. Identify the sender and receiver, choose which side initiates the connection, set a starting latency, match encryption settings and confirm that the required UDP path is reachable before changing bitrate or codec settings.
What SRT does in a live workflow
Secure Reliable Transport, usually shortened to SRT, is an open-source transport protocol for live audio and video over IP networks. It carries a media payload between two endpoints while adapting to changing network conditions. The payload can use different codecs and resolutions, so SRT is not tied to one particular picture format.
That flexibility can cause confusion. SRT is not the part of the workflow that records a camera, turns raw frames into H.264, mixes several sources or publishes a finished broadcast to viewers. A typical chain looks like this:
camera or file source → encoder → SRT sender → network → SRT receiver → decoder or production system
The sender places encoded media into the SRT connection. The receiver takes packets from that connection and passes the resulting media to the next application. That next application still needs to understand the media format. SRT can transport a payload without making an incompatible codec compatible.
SRT can request retransmission of missing packets using ARQ. It also supports features such as forward error correction and connection bonding for appropriate deployments. These features give a workflow more ways to handle an imperfect network, but they do not make bandwidth unlimited or guarantee an uninterrupted stream. Packet loss, delay variation, endpoint configuration and the available path still matter.
This distinction is useful when diagnosing a live channel. If the receiver never connects, changing the video bitrate will not fix a blocked UDP port. If the connection works but the receiver cannot decode the payload, the problem may be the media format after SRT rather than the transport itself. If the picture breaks up only when the link becomes busy, network conditions and the chosen latency deserve attention.
For a recorded 24/7 YouTube channel, a different workflow may be simpler: StreamNeo removes the need to keep a personal computer sending the same uploaded file overnight by running the YouTube broadcast from the uploaded video after you provide the channel connection details.
Prepare an encoded media source
Before configuring SRT, prove that you have a live source capable of producing encoded media. This might be a camera connected to a software encoder, a frame-grabber feeding a hardware encoder, a network encoder receiving a source over UDP, or an application generating a live programme.
A generic capture card is not automatically an SRT encoder. It may only deliver uncompressed or locally encoded video to another application. If you are buying equipment, look for an SRT-capable hardware video encoder and check the manufacturer’s documentation for the exact codecs, resolutions, frame rates, network interfaces and SRT modes it supports. Also check whether encryption controls are available and whether the device works with the intended receiver.
The format decision belongs to the encoder and the receiver or decoder, not to SRT alone. Confirm that both ends agree on what will be inside the transport. A transport stream that arrives successfully can still fail at the next stage if the receiving software does not support its video, audio or container format.
Start by testing the source locally or within the encoder’s own preview. You should be able to see and hear the programme before adding a remote network path. The SRT application guidance recommends confirming that the video source works before routing it through a transport test such as srt-live-transmit. This separates source faults from connection faults.
For a devotional channel, that may mean confirming that the bhajan playlist produces continuous audio and video before sending it to a remote receiver. For a local news loop, check that the graphics remain visible and that the audio does not stop at the end of a clip. For a study channel, confirm that the screen capture remains active when the source application changes slides.
Keep a note of the source format and the encoder’s output settings. You will need those details when the receiver is configured. Do not begin by raising the bitrate to improve a picture that has not yet been shown to work locally. First establish a known-good source, then test the transport.
If your broader project is a continuous educational channel, the CAT preparation stream guide covers the source and content side of that type of workflow. SRT becomes relevant when that prepared media must cross a network to a separate receiving system.
Identify the sender and receiver
Write down the two endpoints before filling in any SRT settings. The sender is the application or device that transmits the encoded media. The receiver is the application or device that accepts the SRT connection and passes the media onwards for decoding, production or delivery.
The media direction and the connection direction are separate ideas. The sender of the video does not have to be the SRT caller. A sending endpoint can be configured as a caller or a listener, provided that the other endpoint uses the opposite role and the addresses and ports are arranged accordingly.
This matters because people often assume that “caller” means “video sender”. It does not. Caller describes which peer initiates the SRT handshake. Listener describes which peer waits for that handshake. The video can flow from the listener to the caller if the application supports that arrangement.
Record these details for both sides:
| Item | Sender | Receiver |
|---|---|---|
| Device or application | The encoder or streaming application | The decoder, production system or ingest application |
| Local address | The address used by the sender | The address on which the receiver can listen or bind |
| Remote address | The receiver’s reachable address | The sender’s target address, if the receiver calls |
| UDP port | The destination port used by the connection | The port the listener must bind and expose |
| Connection role | Caller, listener or rendezvous | The compatible opposite role |
| Media format | Encoded output being sent | Format accepted by the next stage |
| Encryption | Passphrase and key settings | Matching passphrase and key settings |
A simple diagram prevents many errors:
encoded source → sender → network address and UDP port → receiver → decoder or ingest
Then label who calls and who listens. If the receiver is in a data centre or another managed location, it may be easier for the local encoder to make an outbound connection. If the receiver is behind a router that you control, you may instead expose its listening port and have the sender call it.
Do not assume that the person who supplies the stream key, server address or ingest URL has already decided these SRT roles correctly. Confirm which endpoint owns the local port, which address is public, and whether a firewall or router sits between the Internet and the listener.
Choose a connection mode
SRT commonly uses caller, listener or rendezvous mode. The right choice depends on which side can receive an inbound connection and which side can make an outbound connection. It is a network decision, not a statement about which endpoint supplies the media.
Caller mode
In caller mode, one peer initiates a connection to the remote listener. The caller needs the listener’s address and UDP port. This is often practical when the caller can make outbound connections but is not directly reachable for inbound traffic.
For example, an encoder in a home or small office may call a receiver with a public address. The home router does not necessarily need to accept an unsolicited connection to the encoder, although its firewall still needs to permit the outbound traffic. The receiving side must be listening on the address and port the caller targets.
Listener mode
In listener mode, one peer binds to a local address and UDP port and waits for a caller. If that listener is behind a firewall or NAT router, the chosen UDP port may need to be allowed through the host firewall and forwarded by the router to the correct device.
The SRT project describes listener mode as a common choice at the receiving end because the receiver can be configured as the known destination for the sender. That is useful guidance for many public Internet workflows, not a rule that applies to every network. A listener still has to be reachable on the actual path.
Rendezvous mode
In rendezvous mode, both endpoints attempt to establish the connection at the same time. It can help with some firewall traversal arrangements, but both peers must use compatible addresses, ports and rendezvous settings. It does not guarantee traversal through every firewall or NAT device.
Use rendezvous because the network design requires it, not because it sounds like a general solution to reachability. If either endpoint is behind a restrictive network, the organisation’s firewall policy may still prevent the connection.
The SRT modes documentation explains the roles and address behaviour in more detail. When you consult it, map the terminology back to your own diagram rather than copying a mode from someone else’s example.
Set a defensible starting latency
SRT latency is the receiver’s buffering interval. The receiver holds packets for a period so that delayed packets can arrive and missing packets can be requested again before the media is passed to the application. This creates time for recovery, but it also adds delay to the programme.
Lower latency can make a conversation feel more responsive, but it leaves less time to absorb jitter and retransmit missing data. Higher latency gives the connection more room to handle delay variation, while increasing the distance between what happens at the source and what appears at the receiver. Neither setting is automatically best for a devotional loop, a news contribution or a live interview.
A practical starting method is to measure the round-trip time between the endpoints and begin with latency roughly three to four times that measured RTT. This is a testing recommendation from the SRT project, not a universal formula or a promise about end-to-end delay. The result should then be checked against live connection statistics and the actual variation of the path.
Do not confuse SRT latency with the total delay experienced by viewers. Capture, encoding, buffering in the receiving application, decoding, YouTube ingest and platform delivery can all add delay outside the SRT transport. A receiver may report a stable SRT connection while the final audience still sees a longer delay.
Wireless LAN, radio, LTE or 4G and 5G paths can have changing RTT. A setting that works during a quiet test may be too small when the network becomes busy. Watch whether RTT drifts and whether packets are being retransmitted. If the connection is unstable, test a larger latency before changing the picture settings, while remembering that more buffering does not repair a path with insufficient available bandwidth.
For a channel that mainly plays recorded lessons, the audience may accept more transport delay than a presenter taking questions. The guide to delay on a 24/7 YouTube lecture stream is useful for separating transport delay from the wider delay introduced by a platform workflow.
Match encryption settings
SRT supports encryption for the stream payload. Encryption is useful only when both endpoints are configured to communicate with compatible settings. Coordinate the passphrase and key-length or encryption options using the exact names and values supported by both applications.
Treat the passphrase as a credential. Do not paste it into a public support post, place it in a shared screenshot or reuse it casually across unrelated streams. Store it where the people responsible for the sender and receiver can retrieve it without exposing it to everyone who can view the channel’s general settings.
An enforced-encryption configuration can reject a connection when the peers use different passphrases. A connection failure after encryption is enabled therefore does not necessarily indicate a blocked port. Check the passphrase, encryption mode and key settings on both endpoints, then confirm that the application has actually loaded the new configuration.
If one side has encryption disabled and the other side requires it, the endpoints may not establish a connection. If both sides appear to connect but the receiver cannot process the payload, check the receiver’s logs and the supported encryption settings before assuming a codec problem.
Use the SRT API documentation and the documentation for your encoder or receiver when translating a setting from one application to another. Similar words can represent different controls, and a field called “passphrase” is not a reason to assume every related option is identical.
Check reachability before tuning picture quality
When an SRT connection does not establish, start with the path. Confirm the listener’s local bind address and UDP port, the public address used by the caller, the host firewall and any router or NAT forwarding. These must describe the same route to the same endpoint.
A common public Internet arrangement is a receiver listening on a chosen UDP port, with the router forwarding that port to the receiver’s private address. The host firewall must allow the traffic, and the caller must target the public address rather than an internal address that only works inside the local network. The exact rule depends on the router and operating system, so use their current official documentation rather than guessing.
Also check whether the listener is bound to the correct network interface. A device with Wi-Fi and Ethernet may have several local addresses. Binding to an address that is not reachable from the intended path can make a healthy application look unavailable. If a cloud or managed receiver supplies an address and port, confirm whether it expects caller mode, listener mode or a provider-specific arrangement.
Test in stages:
- Confirm that the encoded source works without SRT.
- Confirm that the sender is targeting the intended address and UDP port.
- Confirm that the receiver is listening or calling in the compatible mode.
- Check host firewall rules on both endpoints.
- Check router or NAT forwarding when the listener is inside a private network.
- Verify that encryption settings match.
- Watch connection statistics such as RTT and retransmission behaviour.
- Only then adjust media bitrate, resolution or codec settings.
The SRT application guide is useful for controlled transport tests. A test that sends a known source through the connection can show whether the transport is working before you add a production encoder or a platform ingest step.
Rendezvous may help in a network designed for that method, but it is not a substitute for checking firewall and NAT behaviour. If the path is blocked, increasing SRT latency or changing the video codec will not make the port reachable. Likewise, if the receiver connects but cannot decode, reachability has already passed and the investigation should move to payload compatibility.
Once the transport is stable, monitor it during the conditions in which the channel will actually run. An overnight local broadband test may not represent a daytime mobile link or a busy shared office network. Keep the sender and receiver logs available, note the time of any interruption and change one setting at a time.
For a 24/7 operation, transport testing is only part of continuity planning. You should also decide how you will notice a stopped source, what happens after a power cut and whether the source can resume without manual intervention. The article on moving an existing 24/7 stream off your own PC covers that operational question from a different angle.
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 encode video?
No. SRT transports an already encoded media payload between endpoints. A camera, capture device, encoder or streaming application must create the video and audio first, and the receiver must support the format that arrives.
Is the SRT caller always the video sender?
No. Caller means the endpoint that initiates the SRT connection, while sender describes the endpoint that supplies the media. A media sender can be a caller or a listener if the other endpoint uses the compatible opposite role.
What latency should I use first?
Measure the round-trip time between the endpoints and use latency roughly three to four times that RTT as a starting point, following the SRT project’s testing guidance. Then watch live statistics and retest when the link’s RTT varies. This is not a guaranteed optimum or a promise about the final delay seen by viewers.
What should I check when SRT will not connect?
Check the connection mode, local and remote addresses, UDP port, host firewall and router or NAT forwarding before changing picture quality. Then verify that encryption settings match on both endpoints and that the listener is reachable on the intended path.