RTMP and RTMPS
Publish from OBS or any encoder over RTMP or RTMPS, with the address, the stream key and what is carried.
RTMP is the protocol every encoder has. Use it when your encoder has no SRT. The ingest takes the stream, repackages the H.264 without re-encoding it, and sends it to the relays. RTMPS is the same session inside TLS.
RTMP runs over TCP, so a lost packet stalls everything behind it until it is resent, and the encoder's own output buffer adds to the delay. SRT is the better choice when you have it (OBS and SRT).
The address
The stream must list rtmp (or rtmps) in its ingest; the default is
["rtmp", "srt"]. POST /v1/streams answers publish.rtmp once, with the
stream key in it:
"publish": {
"stream_key": "stk_...",
"rtmp": "rtmp://ingest.nearglass.com:1935/live/stk_...",
"rtmp_server": "rtmp://ingest.nearglass.com:1935/live"
}publish.rtmp_server (and srt_server for SRT) is the address without the
key, and GET /v1/streams/{id} keeps answering it after the key is gone.
An encoder wants it in two parts:
| Field | Value |
|---|---|
| Server (URL) | rtmp://ingest.nearglass.com:1935/live |
| Stream key | stk_... |
The key is the last part of the path. The application name (live) is not
checked. A wrong key is refused when the encoder starts to publish, not when
it connects, so an encoder can show "connected" and then drop.
RTMPS. Create the stream with "ingest":["rtmps"], or ["rtmp", "rtmps"] for both, and send to the same address with rtmps:// and the
RTMPS port. A key only works on the protocols its stream lists: a stream
that lists only rtmp refuses the same key on RTMPS, and the other way
round. Plain RTMP sends the stream key unencrypted: prefer RTMPS on a
network you do not control. Plain RTMP sent to the RTMPS port gets no
session.
Settings
The picture rules are the same as for SRT: H.264, keyframe interval 1 s (2 s at most), no B-frames, CBR. See the table. RTMP carries H.264 only: HEVC and AV1 over Enhanced RTMP are not taken.
Sound: AAC-LC, the default of OBS and most encoders, is carried (the ingest turns it into Opus). Opus in Enhanced RTMP (v2) is taken too, but no encoder has been tested sending it. ffmpeg's FLV output cannot carry Opus, so use AAC there. More in Audio.
OBS
Settings, Stream: Service "Custom...", Server rtmp://ingest.nearglass.com:1935/live,
Stream Key stk_.... Settings, Output, Output Mode "Advanced", Streaming:
Rate Control "CBR", Keyframe Interval "1", and Tune "zerolatency" (x264) or
B-Frames 0 (NVENC). Press Start Streaming.
Other encoders
Any encoder with a custom RTMP target takes the same two fields. For ffmpeg, see ffmpeg. For hardware encoders and vMix, the same picture rules apply.
When it does not work
| Symptom | Likely cause |
|---|---|
| Connects, then drops at "publish" | a wrong stream key, or a key whose stream does not list rtmp (or rtmps) |
| Refused while another encoder is live | one encoder per stream: the second is refused until the first has been silent for 5 s |
| Connected, but the player waits at "Connecting..." | the key was rotated or the stream deleted, or the video is not H.264 |
| Joining takes several seconds | the keyframe interval is long: set it to 1 s |
| Picture, but no sound | the encoder sends HE-AAC, more than two channels, MP3 or AC-3 (Audio) |
| Stutters under load | RTMP stalls on loss: lower the bitrate, or move to SRT |