FFmpeg RTMP Streaming: Publish, Reconnect & Verify | Callaba

FFmpeg can publish a file, device or live input to an RTMP server, but a command that stays running is only half the workflow. The input must be paced correctly, selected tracks must fit the RTMP/FLV destination contract, the publish URL and stream identity must be protected, and the receiving server must prove bitrate and decode. Decide between stream copy and transcoding from evidence, not habit.

An RTMP publish crosses source, encode, session and receiver gates

Confirm the local build and RTMP protocol support

Run ffmpeg -version, ffmpeg -protocols and the relevant muxer help on the publishing host. The official FFmpeg protocol documentation describes native RTMP, RTMPS and related variants. Package builds and external libraries can change available behavior.

Freeze the version with the service definition. A successful laptop test is not evidence for a minimal container that lacks the same encoder, TLS trust store or protocol build options.

Publish a compatible file at real-time pace

ffmpeg -re -i input.mp4 \
  -map 0:v:0 -map 0:a? -c copy \
  -f flv "$RTMP_OUTPUT"

-re paces a file input near its native rate so it behaves like a live contribution instead of sending as fast as possible. Do not use it blindly for an already live source. The copy path is valid only when the destination and FLV muxer accept the input codecs and timing.

Keep the full output URL and stream secret outside shared command text. A runbook can show a redacted host, application and safe source alias while the service injects the actual value through its protected configuration.

Transcode when the server contract requires new media

ffmpeg -i "$LIVE_INPUT" \
  -map 0:v:0 -map 0:a? \
  -c:v libx264 -preset veryfast -pix_fmt yuv420p -g 60 \
  -c:a aac -f flv "$RTMP_OUTPUT"

This is a shape, not a universal production preset. Frame rate determines whether -g 60 represents the intended keyframe interval; bitrate, profile, resolution and audio settings must come from the receiving contract. Measure quality and encode speed on representative content.

If the source already supplies acceptable H.264 and AAC, stream copy may be preferable. If only audio is incompatible, copy video and transcode audio. State the choice per track so a later operator can explain resource use and quality changes.

RTMPS protects the publish hop when correctly validated

FFmpeg documents RTMPS as RTMP over a secure SSL/TLS connection. Confirm that the receiving endpoint supports it, validate hostname and certificate trust, and maintain certificate expiry monitoring. Do not weaken verification to make a test pass.

RTMPS protects the connection between this publisher and server. A downstream restream, recording or viewer has its own transport and access policy. Never turn one protected ingest hop into an unsupported end-to-end encryption claim.

Reconnect policy must avoid duplicates and restart storms

FFmpeg protocol options and source demuxers expose different timeout and reconnect controls. Select only options supported by the exact build and input. Wrap the process with bounded backoff, an attempt ceiling and clear exit evidence. Authentication denial should not trigger an aggressive loop.

Decide what happens if the old connection remains half-open when a replacement publisher starts. The RTMP server's stream-key policy should reject or deterministically replace duplicates according to the event runbook, and operators should see which peer is active.

Read server telemetry before declaring success

The FFmpeg progress line reports local frame, speed and muxing behavior. It cannot prove the server accepted the intended stream identity or that a downstream consumer decodes it. Use RTMP Server statistics to verify the active connection and current bitrate, then inspect the selected consumer.

Short-lived history is useful for immediate diagnosis but is not a durable monitoring archive. Export safe measurements when incident retention requires it, avoiding publication secrets and unnecessary peer data.

Commission publisher and receiver together

1. Freeze the endpoint contract. Record RTMP or RTMPS, port, application, stream identity and access owner without copying secrets.
2. Probe the input. Verify tracks, codecs, timestamps and whether the source already runs in real time.
3. Choose copy or transcode. Validate FLV and server compatibility per track.
4. Publish a bounded test. Compare FFmpeg progress with Callaba connection and bitrate evidence.
5. Exercise failures. Use a denied key, receiver restart, network interruption and duplicate publisher under controlled conditions.
6. Verify the consumer. Connect the feed through Restream, Recording or Web Player and test that separate output.