FFmpeg to Recast

Before you start

In Recast for Business, open Stream Inputs and choose + Stream Input. Pick RTMP or SRT — the choice is fixed once the input is created.

Recast then shows the values your encoder needs. Copy them from there rather than retyping them:

RTMP STREAM URL — SRT STREAM URL
STREAM KEY — STREAM ID
SRT input shows: PASSPHRASE

Note that an SRT input labels its credential STREAM ID, not Stream Key. It is the same value, under the name SRT uses for it.

Then confirm all three of these, or your stream will be refused:

The stream input exists and you have its credentials
The stream input is attached to a video
That video is not a draft

A new stream input is switched off. Recast switches it on only when it is attached to a live, non-draft video.

Check your build

ffmpeg -version ffmpeg -protocols | grep -E 'rtmps?|srt'

You need rtmp and rtmps for the RTMP path, and srt for the SRT path. SRT requires FFmpeg built with libsrt; many distribution packages omit it. If srt is missing, install a full build rather than trying to work around it.

Settings for Recast

Great — Resolution: 1080p · FPS: 30 · Video bitrate: 5000 kbps
Good — Resolution: 720p · FPS: 30 · Video bitrate: 3500 kbps
Works — Resolution: 480p · FPS: 30 · Video bitrate: 1000 kbps

Video codec — H.264
Profile — Main
Rate control — CBR
Keyframe interval — 2 seconds
Audio codec — AAC-LC
Audio bitrate — 128 kbps
Audio sample rate — 48 kHz
Audio channels — Stereo

Use no more than 50% of your measured upload bandwidth.

The diagnostic test stream

This sends a generated test pattern and a 1 kHz tone. It needs no camera, no capture card and no media file, so it isolates the network and the Recast configuration completely.

RTMP:

ffmpeg -re \ -f lavfi -i "testsrc2=size=1280x720:rate=30" \ -f lavfi -i "sine=frequency=1000:sample_rate=48000" \ -c:v libx264 -preset veryfast -profile:v main -pix_fmt yuv420p \ -b:v 3500k -maxrate 3500k -bufsize 7000k \ -g 60 -keyint_min 60 -sc_threshold 0 \ -c:a aac -b:a 128k -ar 48000 -ac 2 \ -f flv "rtmps://global-live.mux.com:443/app/YOUR_STREAM_KEY"

If that appears in Recast, everything outside your production encoder is working. If it does not, the fault is upstream of the encoder and the troubleshooting section below applies.

RTMP setup

Which URL? Recast displays rtmp://global-live.mux.com:5222/app as your RTMP STREAM URL, and that works. This guide uses rtmps:// on port 443 instead: it is the same Mux ingest wrapped in TLS, so your stream key is not sent in clear text, and port 443 passes through restrictive venue networks that block port 5222. Use whichever your encoder supports.

Streaming a file:

ffmpeg -re -i input.mp4 \ -c:v libx264 -preset veryfast -profile:v main -pix_fmt yuv420p \ -b:v 5000k -maxrate 5000k -bufsize 10000k \ -g 60 -keyint_min 60 -sc_threshold 0 \ -c:a aac -b:a 128k -ar 48000 -ac 2 \ -f flv "rtmps://global-live.mux.com:443/app/YOUR_STREAM_KEY"

Note the URL shape: the stream key is the last path segment, appended after /app/. This is different from every GUI encoder in this set, where the server and the key are separate fields.

-re — Read the input at its native rate. Without it, FFmpeg sends a file as fast as it can and Mux rejects the stream. Omit it for live capture devices.
-b:v -maxrate -bufsize — Set all three, with bufsize at twice the bitrate, to get true CBR
-g 60 -keyint_min 60 — A 2-second keyframe interval at 30 fps. Use 50 at 25 fps.
-sc_threshold 0 — Stops FFmpeg inserting extra keyframes on scene changes, which breaks a fixed GOP
-pix_fmt yuv420p — Mux requires 4:2:0. Some sources default to 4:2:2 and the stream is rejected.
-ar 48000 — Mux expects 48 kHz

For plain RTMP, use rtmp://global-live.mux.com:5222/app/YOUR_STREAM_KEY.

SRT setup

ffmpeg -re -i input.mp4 \ -c:v libx264 -preset veryfast -profile:v main -pix_fmt yuv420p \ -b:v 5000k -maxrate 5000k -bufsize 10000k \ -g 60 -keyint_min 60 -sc_threshold 0 \ -c:a aac -b:a 128k -ar 48000 -ac 2 \ -f mpegts \ "srt://global-live.mux.com:6001?streamid=YOUR_STREAM_KEY&passphrase=YOUR_SRT_PASSPHRASE&pbkeylen=16&latency=500000"

Three things differ from the RTMP command:

-f mpegts, not -f flv. SRT carries an MPEG transport stream.
The stream key is streamid=, a query parameter, not a path segment.
latency is in microseconds. 500000 is 500 milliseconds. This catches

almost everyone: entering 500 asks for half a millisecond of buffer, and the stream collapses immediately.

pbkeylen=16 selects the 128-bit key that Mux requires. Do not change it.

Always quote the whole URL. Unquoted, your shell will interpret & as a background operator and the command will fail in a confusing way.

Confirm you're live

FFmpeg prints a continuous status line:

frame= 1234 fps= 30 q=25.0 size= 12345kB time=00:00:41.13 bitrate=3500.2kbits/s speed=1.00x

Read three things:

fps should match your target. Lower means the machine cannot keep up.
speed should sit at 1.00x. Below that, FFmpeg is falling behind real

time and the stream will drift and eventually fail.

bitrate should be near your configured value.

Then open the video in Recast and allow 20 to 30 seconds — standard latency means that delay is expected.

Stop cleanly with q, not Ctrl-C, so the stream ends tidily.

Known quirks

-re with live devices. Use -re for files only. With a live capture device, the device already paces the stream and -re will make it drift.

Add -loglevel warning for a quieter run once you have it working, or -loglevel debug when diagnosing a handshake failure — the SRT errors in particular are far more informative at debug level.

Looping a file for a soak test:

ffmpeg -re -stream_loop -1 -i input.mp4 ...

Useful for confirming a venue connection holds up over an hour before the day.

Do not chase low latency. Recast streams run at standard latency (20–30 seconds) by design. Reducing -g will not change what viewers see.

One protocol per stream input. A Recast stream input is created as either RTMP or SRT and cannot be switched afterwards.

Troubleshooting

FFmpeg runs, but Recast shows nothing

Check the stream input is attached to a video and that the video is not a draft. FFmpeg will keep sending happily while Recast rejects the stream.

Then wait a full 30 seconds before concluding anything.

`Connection refused` or `Server returned 403`

Stream input not attached to a live, non-draft video
Wrong stream key — check it is the last path segment for RTMP, or the streamid parameter for SRT
Protocol mismatch — an SRT Recast input will not accept RTMP
Unquoted URL — the shell ate everything after the first &

SRT: `Connection timed out` or immediate disconnect

latency in milliseconds instead of microseconds — it must be 500000
pbkeylen missing or not 16
Passphrase wrong — re-copy it from Recast
UDP 6001 blocked — very common on venue and corporate networks. Test with the RTMP command; if that works and SRT does not, this is why.

`speed` below 1.00x

Your machine cannot encode in real time. Use a faster preset (-preset superfast or ultrafast), drop a tier, or use a hardware encoder — h264_videotoolbox on macOS, h264_nvenc with NVIDIA, h264_qsv with Intel.

Stream drops repeatedly

Usually bandwidth. Halve -b:v, -maxrate and -bufsize and see whether it stabilises.

You have 30 minutes to reconnect before Recast treats the stream as ended.

Audio missing

Check -ar 48000 is present, and that the audio codec is aac. Also confirm your input actually has an audio track:

ffprobe -hide_banner input.mp4

`Invalid pixel format` or the stream is rejected without explanation

Add -pix_fmt yuv420p. Sources in 4:2:2 or 10-bit are rejected, and the error is rarely clear about it.

Getting help

Include the full command with the stream key redacted, your FFmpeg version, and the output from the last 20 lines of the run. Add -loglevel debug for SRT handshake failures.

More detail: Recast live ingest reference

Sources

‍