video - 发现瓶颈。 Ffmpeg 在 4core\8threads CPU 上没有使用 800%。为什么？

Question

我正在尝试在 E3-1245 V2 3.40GHz CPU、32 GB RAM、2TB 7200RPM 磁盘(带软 Raid 1)debian 6 服务器上编码视频(使用 x264 编解码器)

E3-1245 V2 有 4 核/8 线程，但 ffmpeg 不能使用全部 800%，每个实例使用大约 200%。

我阅读了许多其他线程，人们总是说“以并行模式运行几个 ffmpeg 进程”

但实际上一个 ffmpeg 实例的瓶颈在哪里？ CPU 总线/RAM 频率。速度 ？？

exec ("/usr/bin/ffmpeg -i " . $fullpath . ' -pass 1 -passlogfile    
/var/www/scripts/twopass2.log -refs 1 -threads 0 -vcodec libx264 -bsf h264_mp4toannexb 
-s 1280x720 -aspect 16:9 -r 24 -g 48 -keyint_min 48 -sc_threshold 0 -x264opts 
"keyint=48:min-keyint=48:scenecut=0:stats=/var/www/scripts/stats2.log" -b:v 2300k -bf 0 
-profile:v baseline  -mixed-refs 0 -level 30 -maxrate 80M -bufsize 80M  -acodec aac -
async 1 -pix_fmt yuv420p -f mpegts  -strict -2 -ar 44100 -b:a 128k -map 0 -dn -sn -y 
/dev/null');

exec ("/usr/bin/ffmpeg -i " . $fullpath . ' -pass 2 -passlogfile 
/var/www/scripts/twopass2.log -refs 1 -threads 0 -vcodec libx264 -bsf h264_mp4toannexb 
-s 1280x720 -aspect 16:9 -r 24 -g 48 -keyint_min 48 -sc_threshold 0 -x264opts 
"keyint=48:min-keyint=48:scenecut=0:stats=/var/www/scripts/stats2.log" -b:v 2300k -bf 0 
-profile:v baseline  -mixed-refs 0 -level 30 -maxrate 80M -bufsize 80M  -acodec aac -
async 1 -pix_fmt yuv420p -f mpegts  -strict -2 -ar 44100 -b:a 128k -map 0 -dn -sn -
 flags  -global_header -f segment -segment_format mpegts -segment_time 10  -
segment_list /dev/null -y ' . $idpath . '2/%5d.ts');

我认为存在解复用问题，但不确定。

我也尝试过这样的事情:

mkfifo pipe.y4m
ffmpeg -i input.mp4 -f yuv4mpegpipe -y pipe.y4m
and run
x264 -o dvd1.264 pipe.y4m

CPU 利用率稍微好一点(大约 150% ffmpeg 和 350% - x264)，但这根本不是 800%。

有什么方法可以加快编码速度？
而瓶颈究竟在哪里？

Answer 1

答案编辑:

@user3652819 如果您的 ffmpeg 构建使用 pthread 支持编译， -threads 选项应该可以工作。如果即使您使用 -threads ffmpeg 也无法使用您的 CPU 能力，这意味着某些编码或解码算法的并行性不够。让我解释一下这个并行化问题:

用独轮车搬运沙子是一项完全可并行化的工作。您可以随心所欲地使用手推车。让一些人上车并不是一项可并行化的工作。人们必须一一进入。

我通常会运行更多 ffmpeg 实例来处理更多文件以使用我的空闲 CPU 能力。

旧帖:

Some of the codec's algorithm you are using in input or output may not parallelizable enough. What are the input files you are using? Is this problem persists when you use a libx264 encoded file as input?