SRT Ingest: How to Set Up a Streaming Server

SRT (Secure Reliable Transport) is an open-source protocol for sending live video over unreliable networks such as the public internet. It runs over UDP, recovers lost packets by retransmission within a latency window you set, and can encrypt the stream with a passphrase. An SRT ingest setup has two sides: an encoder that sends the stream and a server that receives it and passes it on for recording, transcoding or playback. This guide covers configuring both sides and confirming that the stream arrives intact.

Before you start

First decide where the receiving side runs. A self-hosted server is software you install on your own machine or virtual server. A hosted ingest is an endpoint supplied by a streaming platform or cloud service. Both use the same protocol, but with a hosted service the provider sets the address, port, stream identifier and allowed codecs. Use the values from your provider's documentation rather than guessing them.

• An encoder with SRT output. OBS Studio has supported SRT since version 27. FFmpeg supports it only if it was built with libsrt, which you can confirm by checking that srt appears in the output of ffmpeg -protocols. Many hardware encoders also support SRT.
• A receiving server that accepts SRT, either self-hosted (for example MediaMTX, SRS or a server built on the libsrt tools) or a hosted ingest endpoint.
• A reachable UDP port on the receiving side. SRT does not use TCP, so firewall and router rules must allow UDP traffic on the chosen port.
• Agreed connection parameters: connection mode, latency, an optional passphrase and, if the server requires one, a stream ID.
• A video format the server accepts. SRT ingest normally carries an MPEG-TS stream, and servers differ in which video and audio codecs they pass through.

Step-by-step instructions

The steps below describe a typical setup in which the server waits for connections and the encoder connects to it. Exact option names vary between programs, so take the precise spelling from each tool's documentation.

• 1. Choose the connection mode. SRT has three: listener (waits for incoming connections), caller (initiates the connection) and rendezvous (both sides connect to each other at the same time). For ingest, the server is usually the listener and the encoder is the caller. Two listeners or two callers will never connect.
• 2. Configure the server. Set the UDP port it listens on and decide whether to require a passphrase. If the server hosts several streams, set the stream ID rule it uses to tell publishers from readers. For example, MediaMTX and SRS each read the stream ID in their own documented format. Start the server and confirm in its log that it is listening on the expected port.
• 3. Open the port. On the server host, allow inbound UDP on the SRT port in the operating system firewall and any cloud security group. If the server sits behind a home or office router, forward that UDP port to the server's local address.
• 4. Set the latency. Latency is the buffer SRT uses to retransmit lost packets. Higher values tolerate worse networks but add delay. A common starting point is several times the round-trip time between encoder and server. Both sides negotiate latency and the higher value applies. Check the unit your tool expects: most interfaces use milliseconds, but FFmpeg's srt latency option is in microseconds.
• 5. Set encryption if needed. Enter the same passphrase on both sides. libsrt accepts passphrases of 10 to 79 characters. You can also choose the key length (16, 24 or 32 bytes) where the tool offers it. If one side has a passphrase and the other does not, the connection is rejected.
• 6. Configure the encoder. In OBS Studio, use a custom streaming server or a recording output with an SRT address as the destination. In FFmpeg, set the output format to mpegts with an SRT destination. The address combines the srt scheme, the server's host and port, and query parameters such as mode, latency, passphrase and streamid. Prefer constant bitrate and a regular keyframe interval so the server and downstream players can join the stream cleanly.
• 7. Start streaming and watch the server log for an accepted connection or a publish event on the expected stream ID.
• 8. Keep the setup reversible. Save the original server configuration file before editing it, change one parameter at a time, and note which firewall rules you added so you can remove them later.

Version differences matter. Older OBS releases have no SRT output, and FFmpeg builds without libsrt do not recognize the srt protocol at all. Server projects also change their configuration keys and stream ID conventions between releases. Check the documentation for the version you actually installed, not an older guide.

Check the output

• Confirm the connection on the server side. The log should show the encoder connecting and the stream being published under the expected identifier.
• Pull the stream back with a second SRT client in caller mode, using the server's read stream ID if it needs one. Then play it or inspect it with ffprobe (built with libsrt) to confirm the container, codecs, resolution and frame rate match what the encoder sends.
• If the server repackages the stream for playback, for example to HLS or WebRTC, open that output as well. Problems can appear after ingest even when SRT itself is healthy.
• Read the SRT statistics if your encoder or server exposes them. Rising counts of lost, retransmitted or dropped packets, or a round-trip time close to the configured latency, mean the latency window is too small for the network.
• Remember that SRT moves packets reliably but does not fix the content. Encoder overload, the wrong codec or a bitrate above the available upload bandwidth will still produce a poor stream.

Common problems and next steps

Connection times out or never establishes: check that the server is actually listening, that the encoder is in caller mode against a listener, and that UDP (not just TCP) is allowed on the port along the whole path. Some corporate or public networks block outbound UDP. In that case, test from another network or ask the network administrator.

Connection is rejected right away: the cause is usually a passphrase mismatch, a passphrase outside the allowed length, or a stream ID the server does not accept. Compare the stream ID format with the server's documentation, including any prefix it uses to tell publishing from reading.

Stream connects but stutters, freezes or shows artifacts: first raise the latency on both sides. Then lower the encoder bitrate if it is close to your upload capacity. Retransmissions need extra bandwidth on top of the video bitrate, and some tools let you limit or reserve this overhead. Also confirm that the latency was entered in the correct unit.

Both ends are behind NAT and neither can accept inbound connections: use rendezvous mode with matching ports on both sides, or put the listener on a host with a public, reachable UDP port. A small relay server on a public host is often the simpler choice.

Server accepts the stream but playback fails: the ingest codec or container may not be supported by the server's output path. Check which video and audio codecs the server passes through to each playback format, and adjust the encoder settings to match.