FFmpeg RTSP Streaming: Probe, Relay & Record | Callaba
More live video workflow notes and product updates.
FFmpeg can inspect, receive, record, remux or transcode an RTSP source, but each command should have one declared output contract. The RTSP URL identifies a controlled presentation; FFmpeg negotiates its RTP transport and decodes or copies the selected tracks. Start with a probe, choose UDP or interleaved TCP deliberately, and transcode only when the destination cannot accept the source media.
One FFmpeg process crosses four testable boundaries
Callaba often removes the need for a separate FFmpeg relay
Callaba Multiview opens RTSP directly for monitoring, Recording accepts RTSP URL inputs, and Restream converts an RTSP input only when another protocol or media transformation is required. Callaba does not currently document an arbitrary FFmpeg shell or support for installing custom FFmpeg builds and flags inside a media job.
| Goal | Use the simplest path | Boundary |
|---|---|---|
| See whether RTSP decodes | Probe locally or add the approved URL directly to Callaba Multiview | No relay is required only to create a confidence view |
| Capture files | Use FFmpeg for a controlled external tool or Callaba Recording for a managed lifecycle | File format, close and retention still need acceptance evidence |
| Deliver another protocol | Use an explicit FFmpeg output or Callaba Restream when conversion is the actual job | Destination acceptance is separate from a running process |
The adjacent improvement is an exportable RTSP diagnostic that records safe transport, track and timestamp facts and suggests the equivalent managed Callaba workflow. Existing direct input and conversion features should not be hidden behind a requirement to run FFmpeg first.
Confirm the exact FFmpeg build before copying a command
Run ffmpeg -version and ffmpeg -protocols on the intended host. Protocol, demuxer, codec and hardware support depend on how that build was compiled. A command tested against another package or container may expose different options.
The official FFmpeg RTSP documentation describes the RTSP demuxer and muxer, lower transports and flags. Treat that versioned documentation and the local -h demuxer=rtsp output as authoritative for available options.
Probe over the transport the production path will use
ffprobe -v error -rtsp_transport tcp \
-show_format -show_streams "$RTSP_INPUT"This example asks for interleaved TCP and prints format and stream facts. Supply credentials through an approved protected mechanism; do not paste them into a shared shell history. Record codecs, profiles, dimensions, frame rate, audio layout and start-time behavior.
Repeat with UDP only when the server and network support it. A TCP success does not prove UDP reachability, and a UDP failure does not prove the RTSP resource is invalid. Keep the selected transport in the runbook.
Map tracks and copy only compatible media
ffmpeg -rtsp_transport tcp -i "$RTSP_INPUT" \
-map 0:v:0 -map 0:a? -c copy \
-t 60 -f matroska rtsp-check.mkvThe optional audio map avoids failing solely because a source has no audio. Stream copy preserves encoded packets and reduces compute. Matroska is only an example controlled sample container; choose the production container from codec, timestamp and consumer requirements.
Probe the resulting file. If it opens but seeking, duration or timestamps are wrong, the command has not passed acceptance. Keep short samples free of sensitive content and remove them under the test-data policy.
Transcode only the tracks that fail the destination contract
A relay to an RTMP destination commonly needs FLV-compatible H.264 video and AAC audio. Copying an unsupported camera codec into -f flv will fail or produce an unusable result. When a new encode is required, state the codec, profile, dimensions, frame rate, GOP, bitrate and audio layout rather than relying on defaults.
Measure encode speed under representative motion. A process running below real time accumulates delay until a buffer or receiver fails. The Live Video Transcoding product page is the Callaba capability handoff when managed media changes are required.
Set timeouts and recovery from the service objective
A process that waits forever can look alive after the source disappears. A process that exits on one delayed packet can create a restart storm. Use the supported FFmpeg I/O timeout options for the exact build and wrap restarts with bounded backoff, health evidence and a maximum failure policy.
Decide whether reconnection opens a new output segment, overwrites a file or rejoins a live destination. Preserve the reason for exit and source state. Never restart so quickly that authentication failures become an accidental password attack.
Example: the camera opens in one test, but the relay receives no frames
A desktop check used RTSP interleaved over TCP, while the service command negotiated UDP on a network that blocks the media ports. The first comparison is FFmpeg's selected lower transport and RTSP SETUP result beside packet capture on the relay host. If forcing supported TCP produces frames, the root cause is the RTP transport boundary—not the output codec merely because the relay wrote zero bytes.
Verify the output at its receiving boundary
For a file, inspect closed duration, tracks, timestamps and representative decode. For RTMP, confirm that the server sees the intended publisher identity, bitrate and tracks. For SRT, verify connection mode, payload and recovery telemetry. A successful FFmpeg log line proves only what that process observed.
Callaba's Restream API exposes managed process statistics, but its documentation also separates process activity from destination acceptance. Apply the same rule to an external FFmpeg service.
Commission the command, not just the syntax
- Freeze build and source. Record FFmpeg version, supported options and a redacted source identity.
- Probe transport and tracks. Test the actual deployment network and save safe format evidence.
- Capture one minute. Validate copy compatibility before adding a live destination.
- Add only required transformations. Measure real-time speed, quality and resource headroom.
- Interrupt the input and output. Observe timeouts, exit, backoff, duplicate publishing and recovery.
- Compare the managed path. Use Multiview, Recording or Restream when it removes an unnecessary custom relay.
FFmpeg RTSP FAQ
Should FFmpeg use TCP or UDP for RTSP?
Use the transport supported by the server and production network. UDP and interleaved TCP fail differently, so test both relevant modes instead of assuming one universal choice.
Can FFmpeg copy an RTSP stream without transcoding?
Yes when the selected output accepts the source codecs, track layout and timing. Probe the result; stream copy does not repair incompatibility or damaged timestamps.
Why does FFmpeg connect but show no frames?
The RTSP control session may be healthy while RTP media is blocked, misrouted or unsupported. Inspect negotiated transport, packet arrival and decoder evidence separately.
Must FFmpeg run before an RTSP source enters Callaba?
No. Multiview, Recording and Restream already accept supported RTSP inputs for their documented jobs. Add FFmpeg only for a specific external transformation or tool requirement.