使用FFmpeg循环推流YouTube时CPU占用过高、6小时断流求助

结合你的1核vCPU/3GB内存VPS配置和给出的推流命令，我帮你梳理下问题根源和优化方案：

一、CPU占用飙升的核心原因&优化 #

你的命令里用了-preset veryfast，这个预设在1核vCPU上长时间跑其实还是有压力的，再加上可能的不必要格式转换、关键帧间隔设置，慢慢就把CPU拉满，最终导致系统因为负载过高杀掉FFmpeg进程，或者进程自身崩溃。

这里给几个立竿见影的优化：

• 降级编码预设：把-preset veryfast改成-preset superfast甚至-preset ultrafast。这两个预设的编码速度更快，CPU占用能降10%-20%，牺牲的画质微乎其微——YouTube自身的转码压缩会掩盖这点差异，观众基本看不出来。
• 移除冗余滤镜：先检查原视频是不是已经是yuv420p格式，执行这条命令：

  ffprobe -v error -select_streams v:0 -show_entries stream=pix_fmt -of default=noprint_wrappers=1:nokey=1 video.mp4
  

  如果输出是yuv420p，直接删掉命令里的-vf "format=yuv420p"，省掉格式转换的CPU消耗。
• 调整关键帧间隔：你当前设的-g 60（对应30fps视频是2秒一个关键帧），可以改成-g 90（3秒一个关键帧），减少关键帧编码的CPU开销，同时完全符合YouTube的推流要求。

二、解决长时间循环推流的稳定性问题 #

无限循环推流时，FFmpeg偶尔会出现微小的内存泄漏，在1核小内存VPS上跑6小时后，内存占用加上CPU负载就会触发中断。这里有两个方案：

方案1：用外部脚本循环替代FFmpeg内置循环 #

写一个简单的bash脚本，每次推流中断后自动重启FFmpeg，避免内存堆积：

#!/bin/bash
# 赋予执行权限：chmod +x stream_loop.sh
while true; do
  echo "启动推流..."
  taskset -c 0 ffmpeg -re -i video.mp4 -vcodec libx264 -preset superfast -maxrate 2500k -bufsize 3368k -g 90 -acodec libmp3lame -q:a 4 -ar 44100 -f flv -max_muxing_queue_size 400 rtmp://a.rtmp.youtube.com/live2/xxxxxxxxx
  echo "推流中断，10秒后重启..."
  sleep 10
done

脚本里的taskset -c 0是把FFmpeg绑定到唯一的vCPU上，减少系统调度带来的额外负载，进一步降低CPU占用。

方案2：优化FFmpeg循环参数（如果不想用脚本） #

如果坚持用-stream_loop -1，可以加上-reset_timestamps 1参数，让每次循环都重置时间戳，避免时间戳累积导致的潜在问题：

taskset -c 0 ffmpeg -re -stream_loop -1 -reset_timestamps 1 -i video.mp4 -vcodec libx264 -preset superfast -maxrate 2500k -bufsize 3368k -g 90 -acodec libmp3lame -q:a 4 -ar 44100 -f flv -max_muxing_queue_size 400 rtmp://a.rtmp.youtube.com/live2/xxxxxxxxx

三、其他细节优化 #

• 移除冗余分辨率参数：如果原视频已经是1280x720，删掉-s 1280x720，省掉缩放的CPU消耗。用ffprobe video.mp4查看原视频分辨率。
• 优化音频编码：把-b:a 198k改成-q:a 4，这是MP3的VBR模式，音质和192k CBR差不多，但编码效率更高，CPU占用更低。

验证效果 #

优化后先跑1-2小时观察CPU占用，正常情况下应该能稳定在60%-70%左右，不会再飙升到90%，这样就能支撑长时间循环推流了。

内容的提问来源于stack exchange，提问作者Sergio santa