RTMP ingest field guide
Use RTMP where encoders already speak it—and design the rest of the path deliberately
RTMP remains a common way to publish live video from OBS Studio, hardware encoders, cameras and mobile applications into a media server. It is an ingest protocol, not a complete viewing architecture: the server accepts the publisher, identifies the stream, then routes, records, transcodes or packages it for its actual destination.
The publish URL has two jobs
Find the server application
The host, port and application path tell the encoder which RTMP service should accept the session. Traditional RTMP commonly uses TCP port 1935; RTMPS adds TLS and typically runs on a TLS-enabled endpoint.
Identify the stream
The stream key or final path component distinguishes one publisher from another. Treat it as access material. A public or reused key can let an unintended publisher replace the expected feed.
rtmps://ingest.example.com/livestream-key-issued-for-this-publisherApplications expose these values differently. OBS commonly separates Server and Stream Key. Some encoders ask for one combined URL. Confirm the expected format instead of pasting the same string into both fields.
A connected publisher is the start of the test
Verify the signal at the server and at a decoded output. Connection state alone cannot prove that frames are healthy, audio is present or the selected codec is usable downstream.
- Bitrate
- Should be present and plausible for the encoder profile.
- Video
- Check resolution, frame rate, codec and visible motion.
- Audio
- Confirm track presence, level and lip-sync.
- Publisher
- Confirm the expected peer address, region and assigned stream key.
- Reconnect
- Stop the encoder, observe the offline state and prove a clean return.
RTMP ingest does not mean RTMP playback
| Path | Good fit | Important trade-off |
|---|---|---|
| RTMP / RTMPS | Publishing from widely supported encoders and applications. | Browser playback normally requires repackaging to HLS or another supported format. |
| SRT | Contribution across lossy or variable networks with retransmission controls. | Both peers must support SRT and agree on mode, latency and security settings. |
| HLS | Scalable browser and device playback through HTTP delivery. | Segmented delivery introduces more latency than the contribution link. |
| WebRTC | Interactive browser sessions that require very low delay. | Session and connectivity design are more involved than a one-way publish URL. |
A normal workflow can accept RTMP from an encoder, monitor and record the source, then publish HLS for viewers. Protocol conversion is a server job; do not force the camera or contribution encoder to solve every delivery requirement.
Where Callaba fits
Callaba RTMP Server can issue controlled publisher and receiver connections, display live bitrate, peer address and region, and expose connection state in the UI. Guest RTMP lets approved publishers or receivers create their own connection with an assigned stream key. The same input can then be monitored in Multiview, recorded, routed or sent into a wider production flow.
Use the RTMP server guide when you are selecting and configuring the server product. Stay on this page for protocol behavior, encoder compatibility and ingest troubleshooting. For resilient contribution over difficult networks, compare the role with SRT.
Accept the publisher, prove the media, then choose each output
A dependable RTMP workflow is observable from the publisher through the decoded destination. Begin with one controlled key and one known output before adding more publishers, platforms or automation.
