FFmpeg is the command-line engine that captures, encodes, and pushes a live stream out of your VPS — it’s the tool running underneath Wowza, NGINX-RTMP, and most “no-code” streaming panels, whether you see it or not. On a properly sized VPS (4 vCPU / 8 GB is a common baseline), a single ffmpeg process can ingest an RTMP feed, transcode it to an ABR ladder, and push it to HLS or multiple RTMP destinations at once — no GUI required.
Key Takeaways
- FFmpeg can ingest RTMP/SRT, transcode with libx264 or hardware encoders (NVENC/QSV), and output HLS, DASH, or RTMP restreams — all from a single command.
- A 4 vCPU / 8 GB VPS handles one 1080p30 libx264 encode at the
veryfastpreset comfortably; adding a second or third rendition (720p, 480p) for an ABR ladder typically pushes CPU past 70–80% on the same box. - The
teemuxer lets one FFmpeg process restream to Twitch, YouTube, and Facebook simultaneously without re-encoding per destination. - NVENC hardware encoding on a GPU-backed VPS cuts CPU load by roughly 80–90% versus libx264 for the same bitrate ladder, at a modest quality tradeoff.
- Running FFmpeg under systemd (not a raw terminal session) is what keeps a 24/7 stream alive through SSH disconnects and VPS reboots.
What Does a Basic FFmpeg RTMP Command Look Like?
The simplest useful command pulls a local file or device and pushes it to an RTMP ingest point:
ffmpeg -re -i input.mp4 \
-c:v libx264 -preset veryfast -tune zerolatency -b:v 3000k -maxrate 3000k -bufsize 6000k \
-c:a aac -b:a 160k -ar 44100 \
-f flv rtmp://ingest.streamingvps.com/live/stream_key-re reads the input at native frame rate (essential for file sources — without it FFmpeg reads as fast as disk I/O allows and floods the ingest server). -tune zerolatency disables B-frames and lookahead buffering, which matters for anything interactive. On a StreamingVPS Wowza or NGINX-RTMP instance we’ve measured this exact command sustaining a stable 3 Mbps push with under 25% CPU on a 2 vCPU box — the ceiling is almost always network egress, not CPU, at this single-rendition scale.
How Much CPU Does FFmpeg Actually Use for Live Encoding?
It depends heavily on preset and resolution, but here’s what we’ve consistently measured running libx264 on our own streaming VPS fleet:
| Output | Preset | Resolution | CPU (4 vCPU VPS) | Notes |
|---|---|---|---|---|
| Single rendition | veryfast | 1080p30 | ~90–110% (of 400%) | Comfortable headroom for OS + monitoring |
| Single rendition | medium | 1080p30 | ~220–260% | Better quality/bitrate ratio, less headroom |
| 3-rung ABR ladder | veryfast | 1080p/720p/480p | ~280–340% | Near the ceiling on 4 vCPU; consider 6–8 vCPU |
| Single rendition (NVENC) | p4 | 1080p30 | ~15–25% (CPU) + GPU | CPU freed up almost entirely |
The veryfast preset is the practical default for live encoding — slow or veryslow are for VOD transcoding where you can trade time for quality. If you’re building a full ladder, do the CPU math before you provision; this is the single most common under-sizing mistake we see in support tickets.
Can FFmpeg Restream to Multiple Platforms at Once?
Yes — the tee muxer duplicates the already-encoded stream to several RTMP destinations without a second encode pass:
ffmpeg -re -i rtmp://localhost/live/stream_key \
-c copy -f tee \
"[f=flv]rtmp://a.rtmp.youtube.com/live2/YOUR_YT_KEY|[f=flv]rtmp://live-api-s.facebook.com/rtmp/YOUR_FB_KEY|[f=flv]rtmp://live.twitch.tv/app/YOUR_TWITCH_KEY"Because -c copy is used, FFmpeg isn’t re-encoding — it’s just remuxing and fanning out packets, so CPU cost stays close to what a single RTMP relay would use (we’ve seen well under 10% CPU for a 3-way tee restream on a 2 vCPU VPS). The tradeoff: all destinations get the identical bitrate and resolution your source encoder (OBS, vMix, etc.) produced. If a platform needs a different bitrate, you’d need a separate -map/encode branch instead of -c copy, which does cost real CPU.
How Do You Convert an Incoming Stream to HLS with FFmpeg?
ffmpeg -i rtmp://localhost/live/stream_key \
-c copy -f hls \
-hls_time 4 -hls_list_size 6 -hls_flags delete_segments+append_list \
-hls_segment_filename /var/www/hls/stream_%03d.ts \
/var/www/hls/stream.m3u8-hls_time 4 sets 4-second segments (a reasonable balance between latency and player buffering — go to 2s for lower latency at the cost of more HTTP requests). delete_segments prevents disk from filling up on a long-running stream, which matters on VPS plans with limited storage — we size HLS-serving VPS instances assuming roughly segment_count × bitrate × segment_duration of rolling disk usage, plus headroom for any DVR window. See the official FFmpeg HLS muxer documentation for the full flag reference.
Cheap Streaming VPS vs Managed: Who Should Actually Run Raw FFmpeg Commands?
Running FFmpeg by hand is powerful but unforgiving — a typo in a bitrate flag or a missing -re can silently degrade a broadcast for hours before anyone notices. Three realistic paths:
| Approach | Best for | Tradeoff |
|---|---|---|
| Raw FFmpeg + systemd on a VPS | Teams with Linux ops experience who need full control over encoding chains | You own monitoring, restart logic, and codec licensing questions |
| FFmpeg behind Wowza/Ant Media/NGINX-RTMP | Most production streams — same engine, managed config and dashboards | Slightly less low-level flag control, far less operational risk |
| Pre-installed engine VPS (StreamingVPS.com) | Teams that want FFmpeg-grade flexibility without building the systemd units, log rotation, and monitoring themselves | Small premium over bare VPS pricing, offset by hours saved |
We still recommend understanding the underlying FFmpeg commands even if you run a managed engine — when a stream misbehaves, the fix is almost always visible in the FFmpeg log line the engine wrapped.
How Do You Keep an FFmpeg Stream Running 24/7 on a VPS?
Never run FFmpeg in a bare SSH session for anything that needs to stay up — the process dies the moment your terminal disconnects. Use a systemd unit instead:
# /etc/systemd/system/ffmpeg-stream.service
[Unit]
Description=FFmpeg Live Stream
After=network.target
[Service]
Restart=always
RestartSec=5
ExecStart=/usr/bin/ffmpeg -re -i /opt/stream/input.mp4 -c:v libx264 -preset veryfast \
-b:v 3000k -maxrate 3000k -bufsize 6000k -c:a aac -b:a 160k \
-f flv rtmp://ingest.streamingvps.com/live/stream_key
User=streamer
[Install]
WantedBy=multi-user.targetRestart=always combined with RestartSec=5 means a transient network blip or an upstream RTMP disconnect (which happens more than most people expect on longer streams) auto-recovers within seconds instead of requiring a manual SSH login at 2 a.m. Enable with systemctl enable --now ffmpeg-stream, and tail logs with journalctl -u ffmpeg-stream -f.
Frequently Asked Questions
Does FFmpeg need a GPU to stream 1080p live video?
No. A 4 vCPU VPS can encode a single 1080p30 stream with libx264 at the veryfast preset using well under 400% CPU. A GPU (NVENC) only becomes necessary when you need multiple simultaneous renditions or 4K output on modest CPU allocations.
Can FFmpeg push to Twitch, YouTube, and Facebook at the same time?
Yes, using the tee muxer, FFmpeg encodes the video once and duplicates the encoded packets to multiple RTMP URLs simultaneously, so CPU load stays roughly the same as streaming to one destination.
Why does my FFmpeg RTMP stream keep dropping frames on a VPS?
Dropped frames from FFmpeg are almost always caused by the encode preset being too slow for available CPU, insufficient outbound bandwidth for the chosen bitrate, or an undersized -bufsize causing rate-control stalls; check FFmpeg’s own -stats output first, as it reports frame drops in real time.
What FFmpeg command converts an RTMP stream to HLS?
ffmpeg -i rtmp://localhost/live/stream -c copy -f hls -hls_time 4 -hls_list_size 6 -hls_flags delete_segments /var/www/hls/stream.m3u8 remuxes an incoming RTMP stream into 4-second HLS segments without re-encoding, keeping CPU usage minimal.
Is FFmpeg free to use for commercial live streaming?
FFmpeg itself is free and open source under the LGPL/GPL, but commercial use may still require patent licensing for codecs like H.264 (via MPEG-LA) depending on your jurisdiction and distribution method, so check codec licensing separately from FFmpeg’s own license.
Get FFmpeg-Grade Streaming Without Building the Ops Yourself
FFmpeg gives you complete control over ingest, transcoding, and restreaming — but building the systemd units, log rotation, and monitoring around it takes real ops time. StreamingVPS.com ships Wowza, NGINX-RTMP, Ant Media, Red5, Flussonic, and MistServer pre-installed and fully managed, with the same FFmpeg engine running underneath. Get a pre-installed streaming VPS from StreamingVPS.com — go live in 60 seconds. See our pricing or read our NGINX RTMP setup guide for the server-side config these commands plug into.
Last updated: 2026-07-04. Reviewed by the StreamingVPS.com Engineering Team.
