Most live-streaming tools make 24/7 YouTube streaming sound easy — until you read the pricing page.
Recently, I wanted to run a continuous 24/7 livestream to YouTube. The challenge?
Most SaaS streaming platforms either:
• charge monthly fees
• limit long-running streams
• or only allow full features on paid plans
Since I already operate my own VPS, I decided to engineer a fully self-hosted solution using FFmpeg — stable enough to run indefinitely.
Challenge
The stream worked at first, but YouTube repeatedly showed:
• “Not receiving enough video”
• “No data”
• Buffering warnings
Which meant the stream wasn’t stable, and viewers experienced freezes.
It looked like a network problem — but it wasn’t.
Root Cause
On the VPS, FFmpeg was using ~98–100% CPU constantly.
At 100% CPU:
So the problem was simple:
The stream was CPU-bound, not bandwidth-bound.
Technical Fix
The goal was to keep CPU safely below ~60%.
I tuned FFmpeg as follows:
Use a faster preset
-preset superfast
Apply predictable bitrate control
-b:v 2000k
-maxrate 2000k
-bufsize 4000k
Keyframe interval for 30fps
-g 60
-keyint_min 60
Scale when needed
-vf scale=1280:-2
Final Working Command (Simplified)
ffmpeg -re -stream_loop -1 -i video.mp4 \
-vf scale=1280:-2 \
-c:v libx264 -preset superfast -profile:v high \
-b:v 2000k -maxrate 2000k -bufsize 4000k \
-g 60 -keyint_min 60 -r 30 -pix_fmt yuv420p \
-c:a aac -b:a 128k -ar 44100 \
-f flv rtmp://a.rtmp.youtube.com/live2/STREAM_KEY
CPU dropped to ~50–60%, and the stream stabilized to Excellent Health.
Key Takeaways
• CPU load directly affects live-streaming stability
• Stable bitrate > chasing maximum resolution
• VPS-based streaming requires margin and monitoring
• FFmpeg tuning matters in production
Why I Built This
I wanted a reliable 24/7 stream without SaaS cost limitations, and since I already maintain servers, building it myself made sense — and it turned into a great engineering exercise across streaming, DevOps, and system reliability.
More...
Recently, I wanted to run a continuous 24/7 livestream to YouTube. The challenge?
Most SaaS streaming platforms either:
• charge monthly fees
• limit long-running streams
• or only allow full features on paid plans
Since I already operate my own VPS, I decided to engineer a fully self-hosted solution using FFmpeg — stable enough to run indefinitely.
Challenge
The stream worked at first, but YouTube repeatedly showed:
• “Not receiving enough video”
• “No data”
• Buffering warnings
Which meant the stream wasn’t stable, and viewers experienced freezes.
It looked like a network problem — but it wasn’t.
Root Cause
On the VPS, FFmpeg was using ~98–100% CPU constantly.
At 100% CPU:
- encoding slows
- timestamps drift
- bitrate becomes unstable
- sometimes YouTube receives 0 kbps
So the problem was simple:
The stream was CPU-bound, not bandwidth-bound.
Technical Fix
The goal was to keep CPU safely below ~60%.
I tuned FFmpeg as follows:
Use a faster preset
-preset superfast
Apply predictable bitrate control
-b:v 2000k
-maxrate 2000k
-bufsize 4000k
Keyframe interval for 30fps
-g 60
-keyint_min 60
Scale when needed
-vf scale=1280:-2
Final Working Command (Simplified)
ffmpeg -re -stream_loop -1 -i video.mp4 \
-vf scale=1280:-2 \
-c:v libx264 -preset superfast -profile:v high \
-b:v 2000k -maxrate 2000k -bufsize 4000k \
-g 60 -keyint_min 60 -r 30 -pix_fmt yuv420p \
-c:a aac -b:a 128k -ar 44100 \
-f flv rtmp://a.rtmp.youtube.com/live2/STREAM_KEY
CPU dropped to ~50–60%, and the stream stabilized to Excellent Health.
Key Takeaways
• CPU load directly affects live-streaming stability
• Stable bitrate > chasing maximum resolution
• VPS-based streaming requires margin and monitoring
• FFmpeg tuning matters in production
Why I Built This
I wanted a reliable 24/7 stream without SaaS cost limitations, and since I already maintain servers, building it myself made sense — and it turned into a great engineering exercise across streaming, DevOps, and system reliability.
More...