RTMP vs SRT vs SRTLA 2026: Which One Your Stream Needs

Short version:

One thing up front: the big platforms still expect RTMP or RTMPS from your encoder. YouTube's encoder settings page is written around RTMP/RTMPS and mentions HLS as the alternative, and the OBS wiki page on SRT says none of the main streaming services support SRT for ingest. Check your platform's current ingest options before you plan around SRT. In practice SRT and SRTLA carry your stream to a relay, and from there OBS or the relay sends RTMP to the platform.

---

RTMP: what it is and where it struggles

RTMP was developed by Macromedia, now part of Adobe, for streaming between Flash Player and the Flash Communication Server. Adobe published a specification for version 1.0 in December 2012. It runs over TCP, on port 1935 by default. RTMPS is the same protocol inside a TLS connection.

TCP delivers every byte in order. When a packet goes missing, the data behind it has to wait at the receiver until the lost packet has been sent again. On top of that, TCP's congestion control (RFC 5681) treats loss as a sign of congestion and slows the sender down. On a clean wired line you hardly notice any of this. On a link that loses packets regularly, such as busy WiFi or a mobile connection on the move, the sending rate keeps getting pushed down while your encoder keeps producing video at the same bitrate. OBS then starts reporting dropped frames, and on a bad enough link the connection drops.

RTMP is not standing still, by the way. Enhanced RTMP adds newer codecs such as HEVC and AV1 to the protocol, and YouTube recommends H.265 over RTMP(S) for HDR streams. What doesn't change is the TCP underneath.

SRT: UDP with retransmission and a fixed delay

SRT (Secure Reliable Transport) was developed by Haivision and released as open source in 2017. The library is on GitHub under the Mozilla Public License 2.0, and the protocol is described in an IETF Internet Draft.

SRT runs over UDP. When the receiver notices a missing packet, it asks the sender to send it again. The SRT README calls this ARQ (Automatic Repeat reQuest) and names it the primary recovery method. Forward error correction is available as an option.

The part that makes it work for live video is the latency setting. The receiver holds every packet for a fixed time before passing it on. Within that window, lost packets can be resent and slotted back into place. If a packet still hasn't arrived when its time is up, SRT drops it (the draft calls this too-late packet drop) and the stream carries on. On a poor connection that usually means a short glitch rather than a stall, and the delay stays the same instead of creeping up. The SRT README puts it as SRT "maintains a constant end-to-end latency".

The SRT settings that matter

Latency

The SRT library's default latency is 120 ms (socket options). The Internet Draft recommends 3 to 4 times the round-trip time (RTT) between sender and receiver. The OBS wiki says at least 2.5 times the RTT. Both sides propose a latency when they connect, and the higher of the two is used.

Measure the RTT to your relay with ping:

ping -c 20 your-relay-server
# look at the avg value in the "rtt min/avg/max/mdev" line

With an average of 50 ms, 3 to 4 times RTT gives 150 to 200 ms. That is fine for a stable wired line. If the numbers jump around, base your choice on the higher values. Mobile connections jump around a lot, which is why you go much higher there: belaUI, BELABOX's web interface, recommends 1500 to 2500 ms for bonded streams and warns that less increases glitching and lowers the bitrate you can sustain.

Watch the units. In the SRT library and in srt-live-transmit, latency is in milliseconds, so latency=2000 is two seconds. In FFmpeg's SRT options, and so in OBS, which uses FFmpeg for SRT, latency is in microseconds. Two seconds in OBS looks like this:

srt://your-relay-server:4000?latency=2000000

Overhead bandwidth (oheadbw)

Older guides describe oheadbw as a fixed 25% extra on top of your bitrate. That's not how it works. According to the SRT docs, oheadbw is the recovery bandwidth SRT may use above the input rate, in percent: 25 by default, 5 to 100 allowed. It only has an effect when maxbw is set to 0. The default maxbw is -1, which means no limit (1 Gbps in live mode), so with default settings oheadbw does nothing at all.

It's also a ceiling, not a cost. Resent packets only use bandwidth when packets actually get lost. If you do switch to maxbw=0, the docs recommend a fairly constant bitrate and warn against setting the overhead too low, because the stream will choke as soon as packet loss rises. For most setups the defaults are fine.

Encryption

SRT encrypts the payload with AES. You set a passphrase of at least 10 characters on both ends, and optionally pbkeylen 16, 24 or 32 for AES-128, AES-192 or AES-256. If the passphrases don't match, the connection is refused by default. In OBS it goes in the server URL:

srt://your-relay-server:4000?passphrase=YOUR_LONG_PASSPHRASE&pbkeylen=32

Leave the stream key field in OBS empty. The OBS wiki says it isn't used for SRT. Turning encryption on makes sense whenever your feed crosses networks you don't control, like public WiFi at an event.

Connection modes

SRT has three connection modes:

• Caller starts the connection to a listener. OBS is a caller by default.
• Listener waits for callers. This is what your relay server runs.
• Rendezvous is a one-to-one mode where both sides connect to each other at the same time.

In srt-live-transmit, srt://:4000 without a host means listener and srt://host:4000 means caller, unless you set mode= yourself. A srt-live-transmit listener only accepts the first caller and ignores later ones.

OBS can also receive SRT in a Media Source. If it pulls the stream from a server that listens, OBS is the caller, which is the default. If an encoder calls OBS directly, add mode=listener to the input URL. The OBS wiki also suggests setting the input format to mpegts.

SRTLA: bonding several connections

SRTLA is not a separate video protocol. It's a tool from BELABOX that carries SRT traffic over several network links at once. The srtla README says the traffic "is balanced dynamically, depending on the network conditions", and that the intended use is bonding mobile modems for live streaming. It tracks how many packets are in flight on each link and spreads new packets in proportion to what each link can take. The srtla tool itself applies no congestion control, so the encoder has to adapt its bitrate. BELABOX does that with its dynamic bitrate.

Backpack
  camera -> BELABOX encoder
              |-- modem 1 (network A)
              |-- modem 2 (network B)
              '-- modem 3 (network C)
                    |  SRTLA: packets spread over all working links
                    v
Relay: srtla_rec + SRT receiver
                    |  one SRT stream again
                    v
OBS -> RTMP -> Twitch / Kick / YouTube

The capacity of your modems adds up, and when one network drops out in a tunnel or a crowd, the others keep carrying the stream. That only works if the SIM cards are on different networks. The Netherlands has three mobile networks: KPN, VodafoneZiggo and Odido, according to the ACM. T-Mobile Netherlands became Odido in 2023, so those two are the same network. In other countries, check which network your provider actually uses.

Hardware

BELABOX runs on several boards with the Rockchip RK3588 chip and on the older Jetson Nano. On belabox.net/rk3588, the Radxa Rock 5B+ is the recommended board for new setups, with a list price of $99 for the 8GB version. BELABOX says 4GB is enough on any board. The Orange Pi 5 Plus is supported, but BELABOX prefers the Rock 5B+ and warns that mobile modems near the Orange Pi or its HDMI cable make HDMI capture fail. The Jetson Nano version is still maintained, although RK3588 is preferred for new builds. Raspberry Pi is not on the list.

For modems, the BELABOX wiki says any USB modem supported on Linux that shows up as a virtual Ethernet interface should work, and it lists the Huawei E3372 and E5576 as known to work. How long a power bank lasts depends on your board, modems and camera, so measure it during a test stream at home.

The receiving side

Every SRTLA stream needs a receiver. You have two options:

1. BELABOX cloud, from $10 per month according to belabox.net. It runs BELABOX's own relay software, with servers in the USA, EU, UK, Japan, Singapore, Australia, Brazil and South Africa.
2. Your own srtla_rec on a VPS. The README says plainly that this receiver "is unsupported, no longer under development and not suitable for production deployment." Fine for testing and hobby streams. For streams you earn money from, BELABOX cloud is the safer choice.

The receiver from the README looks like this. It builds with plain make, from BELABOX's own SRT fork and the srtla repository:

sudo apt install -y build-essential git tcl pkg-config cmake libssl-dev

git clone https://github.com/BELABOX/srt.git
(cd srt && ./configure && make)

git clone https://github.com/BELABOX/srtla.git
(cd srtla && make)

# Receiver, as in the README example
./srt/srt-live-transmit -st:yes "srt://127.0.0.1:5002?mode=listener&lossmaxttl=40&latency=2000" "srt://0.0.0.0:5001?mode=listener" &
./srtla/srtla_rec 5000 127.0.0.1 5002

srtla_rec takes exactly three arguments: the port it receives SRTLA on (5000 here) and the address and port of the SRT listener it forwards to. There is no configuration file. lossmaxttl is required according to the README, because it lets packets from different links arrive out of order without triggering resends straight away. srt-live-transmit only moves data between SRT, UDP, files and pipes, so it can't push RTMP to YouTube or Twitch. OBS pulls the stream from port 5001 instead.

The README also notes that this basic setup has no authentication or encryption. Our BELABOX relay guide turns it into a full setup: systemd services, MediaMTX in front with a password, the firewall rules and the belaUI settings.

SRT from OBS to a relay, RTMP to the platform

Not every SRT setup involves a backpack. If you stream from home over WiFi, or from a single mobile connection, you can send SRT from OBS to a VPS and let the VPS send RTMP to the platform. SRT then covers the unreliable part, and the RTMP leg runs from the VPS over the data center's wired network.

On the VPS, FFmpeg can listen for SRT and copy the stream to RTMP:

sudo apt install -y ffmpeg

# Check that this FFmpeg build includes SRT
ffmpeg -hide_banner -protocols | grep srt

sudo ufw allow 4000/udp

ffmpeg -i "srt://0.0.0.0:4000?mode=listener&latency=2000000" \
  -c copy -f flv "rtmp://a.rtmp.youtube.com/live2/YOUR_STREAM_KEY"

-c copy passes the video through unchanged, so keep OBS on H.264 video with AAC audio, which the big platforms' RTMP ingests accept. FFmpeg stops when OBS disconnects, so for regular use run it as a systemd service with Restart=always.

In OBS, go to Settings, Stream, choose Custom as the service and enter:

srt://YOUR_VPS_IP:4000?latency=2000000

Leave the stream key empty. SRT in OBS needs version 25.0 or newer.

When to use which

RTMP is the simple choice when you stream from a wired connection straight to a platform. Nothing extra to run, and every platform and encoder supports it.

SRT is worth it when the connection between you and the ingest point is the weak link: WiFi, a single mobile connection, a long distance to the server. It also fits when you send a feed to your own server or to a production team and want fixed latency and encryption. Because platforms rarely take SRT directly, you'll usually need a relay.

SRTLA is for IRL streaming with two or more modems. It needs a BELABOX encoder (or another SRTLA sender) and a receiver, either BELABOX cloud or your own.

Troubleshooting

The stream glitches or keeps reconnecting

Raise the SRT latency, and check the units: milliseconds in srt-live-transmit, microseconds in OBS and FFmpeg. Compare it with your RTT; below 3 to 4 times the RTT there's little room for resends. If OBS reports dropped frames, lower the bitrate. On BELABOX, stay within the 1500 to 2500 ms that belaUI recommends and lower the maximum bitrate first.

OBS can't connect to the relay

SRT uses UDP, so a TCP firewall rule does nothing. Open the port for UDP:

sudo ufw allow 4000/udp
sudo ufw status

Check that the listener is actually running, and remember that a srt-live-transmit listener only accepts one caller. If something else connected first, your connection won't get in.

Viewers still see a long delay

The SRT latency only covers the hop between your encoder and your relay. Everything the platform does after ingest (processing, distribution, the player's buffer) comes on top, and you control that only through the platform's own latency settings. For really low delay you need a player or server you run yourself.

What it costs

Most of the cost of an SRT or SRTLA setup is hardware and mobile data, and those vary by shop, country and provider. These are the parts with a fixed price, as checked on 28 September 2026:

The list prices exclude shipping and import costs. Our VPS plans are out of stock at the moment and expected back around the end of October 2026. An SRT relay for OBS at home needs nothing but the VPS. If OBS itself should run in a datacenter, for example to take in the relayed feed and add your scenes, our streaming VPS comes with OBS pre-installed.

Commercial bonding systems such as LiveU sell encoders, data plans and their own bonding service as a package. Their prices change often, so compare them on their own sites.

Where this leaves RTMP

For now RTMP is still the way into Twitch, Kick and YouTube, and Enhanced RTMP keeps it up to date with newer codecs. Where SRT earns its place is the stretch between you and your relay, and SRTLA takes over when one connection isn't enough. If you stream from a desk with a cable, plain RTMP is fine. Once you leave the house with your stream, SRT and SRTLA are worth the extra setup.

Further reading:

• BELABOX and SRTLA relay guide: your own SRTLA relay on a VPS, step by step
• Build your own IRL stream bag: the full BELABOX backpack build (Dutch version)
• Space-Node VPS plans: VPS-S from €5.50 per month in the Netherlands, back in stock around the end of October 2026

Sources (checked on 28 September 2026):

• SRT README and socket options: https://github.com/Haivision/srt
• SRT Internet Draft (latency, too-late packet drop): https://datatracker.ietf.org/doc/html/draft-sharabayko-srt-01
• FFmpeg SRT protocol options: https://ffmpeg.org/ffmpeg-protocols.html#srt
• OBS wiki, Streaming With SRT or RIST Protocols: https://github.com/obsproject/obs-studio/wiki/Streaming-With-SRT-or-RIST-Protocols
• srt-live-transmit documentation: https://github.com/Haivision/srt/blob/master/docs/apps/srt-live-transmit.md
• srtla README: https://github.com/BELABOX/srtla/blob/main/README.md
• BELABOX for RK3588: https://belabox.net/rk3588/
• YouTube encoder settings: https://support.google.com/youtube/answer/2853702
• TCP congestion control, RFC 5681: https://www.rfc-editor.org/rfc/rfc5681
• Enhanced RTMP specification: https://github.com/veovera/enhanced-rtmp
• ACM on the three Dutch mobile networks: https://www.acm.nl/nl/publicaties/gevolgen-van-de-afschakeling-van-2g-en-3g
• Odido on the T-Mobile rename: https://www.odido.nl/t-mobile-nederland-wordt-odido
• Background on the history of RTMP and SRT: https://en.wikipedia.org/wiki/Real-Time_Messaging_Protocol and https://en.wikipedia.org/wiki/Secure_Reliable_Transport

---

Legal Notice

Legal Notice & Disclaimer: This article constitutes an independent, factual comparative review and critical analysis for educational purposes only. Space-Node is not affiliated with, endorsed by, or sponsored by any hosting provider mentioned herein. All brand names, logos, and trademarks referenced are the registered intellectual property of their respective owners and are used solely for identification and factual reference.

Fair Use & Review Rights: This review is protected commentary, comparison, and criticism. It is based on publicly available information, official pages where available, published documentation, and general hosting engineering analysis. Where hands-on testing is not explicitly stated in the article, no private benchmark or internal infrastructure access is implied. This constitutes lawful comparative review and criticism protected under fair use doctrine.

Factual Accuracy: Specific plan claims are based on public information available at the time of writing. Specifications, pricing, and service features can change, so readers should verify current details on the provider's official website before purchasing. We make no false or defamatory statements; criticism is limited to documented facts, clearly labeled opinion, or general hosting guidance.

No Consumer Confusion: This article makes clear that Space-Node offers distinct, independently-developed hosting infrastructure. We explicitly differentiate our services, pricing, and technical specifications. No reader could reasonably be confused about service provider identity.

Right to Comparative Advertising: Space-Node reserves the right to publish factual comparative information about competing services. This is a recognized right in consumer protection law and advertising standards. Accurate comparative reviews cannot constitute trademark violation, defamation, or unfair competition.

Limitation of Liability: Space-Node makes no warranty regarding third-party services reviewed. Readers are responsible for verifying information independently before purchasing. Space-Node disclaims liability for third-party service changes, outages, or policy modifications.

Space-Node Services: For Space-Node's own managed hosting solutions, visit Minecraft hosting or VPS hosting.