RTMP, RTMPS, SRT, WHIP: an honest guide to ingest protocols
7cubit Team
More in Engineering
Ingest is the connection from your encoder to ApexStream. Pick the wrong protocol for the situation and you can spend more time debugging a handshake than preparing the show. Pick the simple one that fits your network and plan, and the wire disappears into the background.
ApexStream supports RTMP, RTMPS, SRT, and WHIP. They overlap, but they solve different problems. Here is the useful distinction: compatibility, encryption, recovery from a rough network, or browser-native publishing.
RTMP: the compatibility choice
RTMP is still the protocol most encoders know. OBS, Streamlabs, vMix, and hardware encoders generally present the same setup: an ingest URL and a stream key. That makes RTMP a good default when your connection is stable and you want the fewest new variables.
RTMP's tradeoff is age. Plain RTMP does not encrypt the stream on the wire, and it does not provide the recovery behavior associated with SRT. It is still a useful production choice because the tools and media paths around it are well understood.
RTMP is available on Free, Hobby, Creator, Scale, and Enterprise. If you are unsure which protocol to use, start here or use RTMPS if your encoder supports it.
RTMPS: RTMP with encryption
RTMPS wraps RTMP in TLS. The encoder workflow stays familiar while the connection is encrypted. ApexStream includes RTMPS on Free and Hobby, so an entry-tier stream does not have to use plain text simply because the account is small.
RTMPS does not change the destination's latency and does not add packet recovery by itself. Its job is narrower: keep the RTMP-style session encrypted. That is often the right default when the path is stable.
SRT: for measured loss and jitter
SRT is designed for contribution paths where packet loss and jitter are part of the problem. It can recover missing packets and provides encryption options, which makes it useful for venue Wi-Fi, bonded cellular, or a long link that you have already seen damage an RTMP feed.
On ApexStream, SRT is available on Creator and above. Free and Hobby use RTMP or RTMPS. SRT paths also have their own startup behavior; the recording path can wait for the internal bridge to become readable before it attaches.
Use SRT because your measured network needs recovery, not because it sounds newer. If RTMPS holds a full show without trouble, changing protocols may add complexity without adding value.
WHIP: browser-oriented ingest
WHIP is an HTTP-based WebRTC ingest path. Web Studio uses WHIP to publish the composited canvas and master audio into the studio media edge, after which the relay sends the program to your destinations.
Creator and above can also use WHIP as an encoder ingest option. It brings WebRTC's congestion handling and ICE-based connectivity to the ingest side. It does not guarantee that a platform's viewer latency will be lower; the destination still controls much of that experience.
If you are already in Web Studio, WHIP is simply part of the browser workflow. If you are using OBS, it is an optional path for a reason—not every stable RTMP session needs to be replaced.
The plan split
Protocol choice also affects how you troubleshoot. With RTMP or RTMPS, start by checking the full server URL and stream key. With SRT, look at the contribution path and its loss or jitter rather than assuming the destination is at fault. With WHIP, browser permissions and network negotiation are part of the path. Changing protocol without identifying the failure can make the original problem harder to isolate.
- Free and Hobby: RTMP and RTMPS
- Creator, Scale, and Enterprise: RTMP, RTMPS, SRT, and WHIP
The ingest auth check applies the protocol gate before the source-quality check. Bitrate and resolution still have to fit the plan, and destination counts remain separate: Free 2, Hobby 3, Creator 5, Scale 8, Enterprise 50.
A simple selection rule
- Stable wired connection and broad encoder compatibility: RTMPS.
- Stable connection but an older tool that only behaves with RTMP: RTMP.
- Measured loss, jitter, or a difficult contribution link: SRT on Creator+.
- Web Studio or a browser-native media graph: WHIP.
The best ingest protocol is the least interesting one that survives your actual network for the whole show.
Start with the protocol your plan and encoder support. Change it when the network gives you a concrete reason, not because a feature list made one option sound fashionable.
Whatever you choose, keep the source-quality limits in view. The protocol does not raise the plan's bitrate or resolution allowance, and it does not change how the relay applies destination rules after ingest. A more advanced wire is not a substitute for a source profile that fits the account.
Protocol at a glance
| Protocol | Best fit | ApexStream availability |
|---|---|---|
| RTMP | Broad encoder compatibility on a stable path | Free and above |
| RTMPS | The familiar RTMP workflow with an encrypted connection | Free and above |
| SRT | Measured packet loss, jitter, or difficult contribution links | Creator and above |
| WHIP | Browser-native or WebRTC-oriented ingest | Creator and above; Web Studio uses it |