Live Streaming (RTMP)

The RTMP push

YouTube Live, Twitch, Restream, and most streaming services accept RTMP push. The pattern: encode to H.264 + AAC, target a stable bitrate (CBR or near-CBR), push to rtmp://server/path/streamkey.

Why CBR matters here

Live viewers can't 'wait' for a higher-bitrate frame. The buffer is short and the server expects a steady byte rate. CBR with a small bufsize keeps the encoder predictable.

Code

Live to YouTube·bash

# Capture a video file as a 'live' source and push to YouTube Live
# Get your stream key from YouTube Studio → Go Live → Stream Key
STREAM_KEY="xxxx-xxxx-xxxx-xxxx"

ffmpeg -re -i in.mp4 \
  -c:v libx264 -preset veryfast -b:v 4500k -maxrate 4500k -bufsize 9000k \
  -g 60 -keyint_min 60 -sc_threshold 0 \
  -pix_fmt yuv420p \
  -c:a aac -b:a 128k -ar 44100 \
  -f flv \
  "rtmp://a.rtmp.youtube.com/live2/$STREAM_KEY"

# -re = read input at native frame rate (mandatory when pushing files
# as if they were live — without it, FFmpeg uploads as fast as possible
# and gets disconnected for buffer overflow)

Live screen capture push·bash

# Apple Silicon — push the screen + system audio as a live RTMP stream
ffmpeg \
  -f avfoundation -framerate 30 -capture_cursor 1 -i "1:0" \
  -c:v h264_videotoolbox -b:v 5000k -maxrate 5000k -bufsize 5000k \
  -pix_fmt yuv420p -g 60 \
  -c:a aac -b:a 128k -ar 44100 \
  -f flv "rtmp://a.rtmp.youtube.com/live2/$STREAM_KEY"

# Linux equivalent uses x11grab + pulse:
# ffmpeg -f x11grab -framerate 30 -i :0.0 -f pulse -i default ...

Exercise

Set up a private YouTube Live stream and use FFmpeg to push a local video file (the -re trick) to it for 60 seconds. Watch the YouTube Studio stream health monitor — bitrate stable? No buffer warnings? Then experiment with -bufsize values 1×, 2×, 4× of bitrate and observe how viewer-side stalls change on a flaky network.

The RTMP push

Why CBR matters here

Code

External links

Exercise

Progress

Comments 0