Push live RTMP stream with FFmpeg to YouTube, Twitch, or custom origins

When to use this

You push RTMP for live streaming to platform-managed destinations (YouTube Live, Twitch, Facebook Live, LinkedIn Live), custom RTMP origins (Wowza, your own nginx-rtmp), or distribution to multi-platform fanout services (Restream, StreamYard). RTMP is the legacy live ingest protocol — TCP-based, broad compatibility, but lossy on packet drops. The encoder configuration matters: settings tuned for VOD produce visible artifacts and buffer underruns when streamed live.

Command variants

ffmpeg -re -i input.mp4 \
  -c:v libx264 -preset veryfast -tune zerolatency -b:v 3500k -maxrate 3500k -bufsize 7000k \
  -c:a aac -b:a 128k \
  -f flv \
  rtmp://a.rtmp.youtube.com/live2/STREAM-KEY

ffmpeg -f avfoundation -framerate 30 -video_size 1280x720 -i "0:0" \
  -c:v libx264 -preset veryfast -tune zerolatency -b:v 3500k -maxrate 3500k -bufsize 7000k -g 60 \
  -c:a aac -b:a 128k -ar 44100 \
  -f flv \
  rtmp://live.twitch.tv/app/STREAM-KEY

ffmpeg -re -i input.mp4 \
  -c:v libx264 -preset veryfast -tune zerolatency -b:v 3500k -maxrate 3500k -bufsize 7000k \
  -c:a aac -b:a 128k \
  -f tee "[f=flv]rtmp://youtube/live2/KEY1|[f=flv]rtmp://twitch/app/KEY2"

What each parameter does

• -re

  Read input at native framerate. Required for streaming file content; without it, FFmpeg sends as fast as decode allows, breaking RTMP delivery timing.

• -tune zerolatency

  Disables b-frames and lookahead. Required for live: without it, FFmpeg buffers ~20+ frames before emitting, adding 700ms of encoder latency.

• -b:v / -maxrate / -bufsize

  Constant-bitrate-like encoding. Live streams need predictable bitrate; CRF mode produces variable bitrate that breaks RTMP delivery. Set bufsize = 2× maxrate.

• -g 60

  Keyframe every 60 frames (2s at 30fps). Aligns with HLS segment boundaries on the destination side.

• -f flv

  FLV container format. RTMP's native container — required for RTMP destinations.

What this outputs

A live RTMP stream pushed to the destination. Quality depends on encoder settings and network bandwidth. Typical bitrates: 720p30 = 2-3.5 Mbps, 1080p30 = 3-6 Mbps, 1080p60 = 5-9 Mbps.

Pitfalls

1. Forgetting -re when streaming file content: FFmpeg pushes faster than real-time, breaking RTMP delivery timing. The destination receives bursts and players buffer/stall.
2. Forgetting -tune zerolatency: encoder buffers 20+ frames adding 700ms of latency. Visible to viewers, especially on platforms with chat interaction.
3. CRF mode breaks RTMP: variable bitrate confuses delivery. Always use -b:v + -maxrate + -bufsize for live streams.
4. GOP not aligned with destination expectations: YouTube/Twitch expect 2-second keyframe intervals (-g 60 at 30fps). Wrong values produce visible artifacts on rendition switches.
5. No reconnection logic: if RTMP connection drops, FFmpeg exits. For production reliability, wrap FFmpeg in a process manager (systemd, supervisord, K8s pod with restartPolicy) that respawns on exit.
6. RTMP destination requires specific SSL handling: rtmps:// for encrypted (most modern platforms), rtmp:// for plaintext. Wrong scheme = connection refused.

At production scale

RTMP streaming is encoder-bound and constant-throughput. A single live stream consumes one encoder unit (one CPU core for libx264 veryfast at 720p, less for NVENC). Scaling to N streams = N encoder pools. For production live operations, run FFmpeg in containers managed by K8s with HPA on pod count; each pod handles one stream. The live ingest + low-latency packaging architecture covers the production-grade alternative.

MpegFlow models RTMP push as a dedicated DAG stage — different streams can have different destinations, retry logic, and encoder settings. The audit log records bytes-per-second pushed, connection status, and reconnection events.

• FFmpeg
• rtmp
• live
• streaming
• tooling

• Architecture
  Live Ingest Low Latency Packaging
• Recipe
  Multi Output Encoding