Short answer: RTSP is often the camera or controlled-session side of a workflow, while RTMP is commonly the encoder publishing side. They can occur in one system, but switching one for the other changes the source, receiver and delivery contract.
RTMP vs RTSP: the operating model
| Boundary | RTSP | RTMP |
|---|---|---|
| Typical source | A device or media server exposing an RTSP-controlled session | Encoder or production software publishing a programme feed |
| Control model | RTSP defines session-control methods; media is commonly carried with RTP | RTMP carries a persistent publishing session to its receiving endpoint |
| Transport | RTSP is session control; the device and receiver decide the RTSP/RTP carriage options | RTMP uses TCP; the ingest endpoint defines URL and credentials |
| Receiver | A client, recorder or gateway that supports the camera/session path | A platform or ingest server that accepts the publishing contract |
| Browser delivery | Requires a separately configured browser-delivery path in normal web workflows | Also requires a separately configured browser-delivery path |
The protocol roles above follow IETF RTSP, RTP, and the RTMP specification.
Choose from the source outward
An encoder sends a programme to ingest
When a platform assigns an RTMP URL and key, inspect the actual encoder profile—video/audio codec, profile, resolution, frame rate and keyframe cadence—before the first event.
Use the target's RTMP details when a platform or RTMP Server assigns a publish URL and key. Verify that the encoder's codec, frame rate, audio layout and bitrate match the target before an event. The incoming RTMP feed is an ingest boundary; playback, recording and restreaming remain deliberate downstream choices.
A recorder or gateway pulls a camera
Read the exact device documentation for RTSP URL form, authentication, and TCP/UDP RTP option, then test that route in the intended recorder or gateway. Confirm its supported video/audio profile. A reachable RTSP control URL does not establish that every downstream recorder or browser accepts the associated media stream.
Viewers need browser playback
Neither RTSP nor RTMP is a native modern-browser playback answer. Choose a configured web output such as HLS or WebRTC based on audience behaviour, player requirements and network conditions, then test the viewer endpoint rather than the source URL.
Keep transport and codec tests separate
A URL can connect while the receiver rejects media or renders no picture. Log protocol/transport settings separately from video codec, profile, resolution, frame rate and audio codec. This distinction makes it much easier to isolate a camera issue from a transcoding or player issue.
A short validation runbook
Choose RTSP when the selected device and recorder agree on an RTSP-controlled session. Choose RTMP when the selected publishing receiver has assigned the ingest URL/key. A camera may offer both, and either can be the wrong choice if the next receiver does not accept its complete transport and media contract.
- Write down the source type: camera session or programme publisher.
- Confirm the receiver's protocol, URL/authentication and allowed codecs.
- Test source connection and media separately.
- Test the actual recording, restream or browser output that follows it.
- Keep a known-good source profile for rollback.
Where Callaba fits
Callaba's RTMP Server is for configured RTMP publishing and receiver access. In a camera workflow, check the RTSP route in the recorder or routing documentation before designing the output path. When the feed needs conversion, use live video transcoding after confirming the selected input and output contracts.
