【问题标题】:finding bottleneck. Ffmpeg does not utilize 800% on 4core\8threads CPU. Why?发现瓶颈。 Ffmpeg 在 4core\8threads CPU 上没有使用 800%。为什么?
【发布时间】:2014-10-22 10:22:35
【问题描述】:

我正在尝试在 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%。

有什么方法可以加快编码速度? 实际瓶颈在哪里?

【问题讨论】:

  • 你设置线程数吗?这么少的信息很难说。我打赌IO。如果你并行运行,会发生什么?
  • 是的。我也试过 -thread 0; -threads auto 和 -threads 8,但 ffmpeg 不在乎。什么都没发生,但现在在生产服务器上是个问题。

标签: video encoding ffmpeg


【解决方案1】:

答案编辑:

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

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

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

旧帖:

您在输入或输出中使用的某些编解码器算法可能不够并行。您使用的输入文件是什么?当您使用 libx264 编码文件作为输入时,此问题是否仍然存在?

【讨论】:

  • 这个答案应该是评论(但也许你没有足够的声望点?)。
  • 在输入中我有 h264 (High Profile) yuv420p, 1920x1080, 2001 kb/s, 50 fps, 在 MP4 容器中
  • @user3652819 如果您的 ffmpeg 编译版本支持 pthread,则 -threads 选项应该可以工作。如果 ffmpeg 即使您使用 -threads 也无法使用您的 CPU 能力,则意味着某些编码或解码算法的并行性不够。让我解释一下这个并行化问题:用独轮车搬运沙子是一项完全可并行化的工作。您可以随心所欲地使用手推车。让一些人上车并不是一项可并行化的工作。人们必须一一进入。我正在运行更多实例来处理更多文件以使用我的空闲 CPU 能力。
  • @LordNeckbeard 对不起。我没有 50 个代表可以发表评论。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-01-03
  • 2012-01-12
  • 1970-01-01
  • 2018-07-21
  • 1970-01-01
  • 2011-05-10
相关资源
最近更新 更多