SRTLA vs SRT vs RTMP: Which Protocol Is Best for IRL Streaming?

For IRL streaming, SRT is usually a better fit than RTMP, and SRTLA is the best option when you can send over several connections at once. RTMP is still needed because streaming platforms expect it, but it belongs on the stable last leg between a server and the platform, not on a mobile network.

This guide explains how the three protocols work, how they behave on cellular connections and how to set the SRT latency properly.

What is RTMP?

RTMP (Real-Time Messaging Protocol) was specified by Adobe and published as an open specification in 2009. It is designed to run over a reliable transport such as TCP, which guarantees that all messages arrive in order (RTMP specification). The IETF draft for SRT calls RTMP the de facto standard for contribution over the public internet, which is why practically every encoder, app and platform speaks it.

The weak spot comes from the same design. Because RTMP relies on TCP, it only delivers acceptable reliability over connections with a low round-trip time, and TCP congestion control keeps it from using the full bandwidth of a connection. That is a poor match for a phone that moves between cell towers.

Classic RTMP also has codec limits: it supports only two audio channels and a restricted set of codecs, with no HEVC, VP9 or AV1. The Enhanced RTMP specification adds these codecs, and YouTube now lists H.264, H.265 and AV1 for RTMP(S). Both your software and the platform have to support it, though. RTMPS is RTMP inside an encrypted SSL connection, and YouTube recommends it for exactly that reason.

What is SRT?

SRT (Secure Reliable Transport) is an open source protocol that is developed in Haivision's public GitHub repository and described in an IETF Internet-Draft. It runs on UDP and adds the reliability that UDP lacks on its own. The primary method is ARQ (Automatic Repeat reQuest): when the receiver notices a missing packet, it asks the sender to send that packet again. The protocol also supports Forward Error Correction and its own connection bonding.

Three properties matter for IRL streaming:

• Latency buffer: The receiver holds every packet for a configured time before it passes it on. This window gives lost packets time to be retransmitted and reproduces the original timing of the stream. Packets that arrive too late can be dropped, so the delay stays constant instead of growing.
• Encryption: SRT supports AES encryption with 128, 192 or 256 bit keys.
• Codec independence: SRT is payload agnostic. It transports any codec, resolution or frame rate, including HEVC.

The trade-off is built in. The buffer adds delay on purpose, so you have to pick a latency value that fits your network (more on that below).

What is SRTLA?

SRTLA is an SRT transport proxy with link aggregation. It originates from the BELABOX project and transports SRT traffic over multiple network links for more capacity and redundancy. Traffic is balanced dynamically depending on the network conditions, and the intended use is bonding mobile modems for live streaming.

SRTLA does not replace SRT. It sits between the SRT sender and receiver: your device sends the SRT stream out over, for example, two SIM cards or one SIM plus Wi-Fi, and a receiver that understands SRTLA puts the packets back together and hands them on as a normal SRT stream. Three practical consequences follow:

• You need an SRTLA-capable sender. The free iOS app Moblin, for instance, can use one cellular, one Wi-Fi and several Ethernet connections at the same time. IRL Pro and BELABOX devices offer SRTLA bonding too.
• You need an SRTLA receiver. A streaming platform or a plain SRT listener cannot do this, so a server with SRTLA input has to sit in between.
• It needs tuning. Packets arrive out of order over different links. The README therefore requires receiver options such as lossmaxttl and a suitable latency.

RTMP vs SRT vs SRTLA at a glance

Why platforms want RTMP and why a server sits in between

The encoder documentation of the big platforms still revolves around RTMP. YouTube lists RTMP/RTMPS as the encoder protocol (HLS is the alternative), and Twitch's developer documentation describes sending the stream into Twitch via RTMP. SRT and SRTLA are therefore not something you can point at a platform directly in most cases.

A server solves this and adds a second benefit. The chain looks like this:

1. Your phone or encoder sends SRT or SRTLA (or RTMP) to a server.
2. Your streaming software, such as OBS Studio, pulls the stream from that server.
3. OBS sends the finished stream to the platform via RTMP(S) over a stable connection.

The weak mobile leg uses the more tolerant protocol, and the platform receives the protocol it expects over a connection that is not moving. If the mobile signal drops briefly, OBS keeps streaming to the platform, so the stream does not end for your viewers. Both your encoder and OBS connect outbound to the server, so you do not need to open ports on your router.

That is what our IRL Endpoint Server does for you with OBS on your own PC. It accepts RTMP, SRT and SRTLA as input. If you do not have a streaming PC, the IRL Broadcasting Server runs OBS Studio in the cloud and takes the same three inputs. For the bigger picture of an IRL setup, see our IRL streaming guide.

How to set the SRT latency

SRT latency is not the total delay between camera and viewer. In the Haivision documentation, it describes only the delay introduced by sending over the network. Encoding, decoding, OBS and the platform come on top. What the setting really defines is the extra time the receiver waits to compensate for late packets and for retransmissions.

The OBS knowledge base gives a rule of thumb for the most important option:

• The default is 120 ms.
• The value should be at least 2.5 times the round-trip time between encoder and server in milliseconds.
• In an FFmpeg-style URL, which OBS uses, the unit is microseconds. A latency of 1 second is written as latency=1000000.

Example: if a ping to your server shows a round-trip time of 80 ms, the rule gives a minimum of 200 ms, so you would enter srt://SERVER:PORT?latency=200000. Use the exact address and port from your customer portal. In OBS, such options can be appended to the SRT URL of a Media Source or of a custom stream destination.

For streams to our servers, we recommend a latency of 2 seconds. Depending on the app, you enter it as 2000 (milliseconds) or 2000000 (microseconds). Most apps have a separate field for it. If yours does not, append it to the SRT URL, for example srt://<server>:<port>?streamid=publish:publish/<streamkey>&latency=2000. A lower value is possible, but we deliberately recommend 2 seconds in favor of stability.

A few things to keep in mind:

• Units differ. The SRT library and the SRTLA README use milliseconds, while FFmpeg-style URLs use microseconds. Check which unit your app expects before you type a value.
• Both sides negotiate. According to the SRT draft, the latency of a connection is the maximum of the values proposed by sender and receiver. Lowering it on one side does not help if the other side asks for more.
• Mobile and bonded streams need headroom. The rule above is a minimum, not a recommendation. A larger window means more time for retransmission and reordering, but also more delay. The SRTLA README, for example, uses latency=2000 (ms) together with lossmaxttl in its sample receiver setup.
• Change one thing at a time and test while moving, not only at your desk.

Server location and latency

Because the minimum SRT latency scales with the round-trip time, distance matters. A server closer to you has a shorter round-trip time, so you can run a smaller latency window or get the same stability with less delay. The same logic applies to the last leg: Twitch, for example, recommends ingest endpoints based on the network path to your device.

We offer server locations in the USA, Europe, Asia and South America. With the IRL Endpoint Server, you can choose between them on the standard plan and switch at any time in the customer portal, which helps when you travel. On the Dedicated plan, we set up an endpoint for you, by default at the location closest to your billing address.

Which protocol should you use?

• One connection, modern app: use SRT, and set the latency based on your round-trip time.
• Two or more connections: use SRTLA, if your app supports it and your server accepts it.
• App or camera that only does RTMP: use RTMP. It works, but it is less tolerant of weak networks.
• HEVC: SRT is codec independent. Check that your whole chain, from encoder to OBS to the platform, supports it. Set the keyframe interval in your encoder to 2 seconds, and with HEVC on Apple devices, disable B-frames if your app offers the option.

FAQ

Is SRT better than RTMP for IRL streaming?

For the mobile leg, usually yes. SRT runs on UDP and retransmits lost packets inside a configurable latency window, while RTMP relies on TCP and only stays reliable over connections with a low round-trip time. RTMP remains the common choice for the connection from a server or OBS to the platform.

What is the difference between SRT and SRTLA?

SRT is the transport protocol for one connection. SRTLA transports SRT traffic over several network links at once, for example two SIM cards, to add capacity and redundancy. SRTLA needs an SRTLA-capable app and a receiver that understands it.

Can I stream SRT directly to Twitch or YouTube?

The encoder documentation of both platforms centers on RTMP(S), with HLS as an alternative on YouTube. If you want to use SRT or SRTLA on the mobile leg, put a server and OBS between your device and the platform.

What latency should I set for SRT?

For streams to our servers, we recommend 2 seconds, entered as 2000 (milliseconds) or 2000000 (microseconds), depending on the app. A lower value is possible, but 2 seconds is a deliberate choice in favor of stability. As a general rule, the OBS knowledge base says at least 2.5 times the round-trip time to your server, with a default of 120 ms. Mobile networks and bonded connections usually need more headroom, at the price of more delay.

Does the IRL Endpoint Server support all three protocols?

Yes. The IRL Endpoint Server and the IRL Broadcasting Server accept RTMP, SRT and SRTLA as input.