我的 macOS 机器上有 2 个独立的 ffmpeg 实例（10.14.2 Mojave 和 Intel Core i5-8259U 四核 CPU @ 2.30GHz，如果有帮助的话）：
1-使用 brew 安装（并与我的本地 dylib 链接）
2 - 从以下位置下载的静态构建Zeranoe 的 ffmpeg 构建
两者都是 v4.1。但是，当使用相同的命令选项、相同的系统负载和其他所有条件相同的情况下对同一文件 (OGG -> MP3) 进行转码时...实例 #1 比实例 #2 快大约 3 倍。我需要知道原因，因为我需要将静态 ffmpeg 构建与我的应用程序捆绑在一起，并且它需要达到最佳性能. 查看下面的命令输出：
ffmpeg 的更快实例（注意速度是 46.5 倍）：
$ ffmpeg -v quiet -stats -i ~/Reiki2.ogg -vn -sn ~/Reiki2.mp3
size= 26290kB time=00:28:02.54 bitrate= 128.0kbits/s speed=46.5x
较慢的 ffmpeg 实例（注意速度是 17.2 倍）
$ ./ffmpeg -v quiet -stats -i ~/Reiki2.ogg -vn -sn ./Reiki2.mp3
size= 26290kB time=00:28:02.54 bitrate= 128.0kbits/s speed=17.2x
为什么性能差异这么大？
如果我解决了这个问题，我就可以自己构建 ffmpeg，并以与我安装的更快的 ffmpeg（即 #1）相匹配的优化性能。
这是之前两个实例的配置方式吗？制作? 您是否认为某些重要的配置选项是造成性能上巨大差异的原因？
我迫切想知道这一点，因为我的应用程序依赖于 ffmpeg 的性能。我非常感谢任何见解。提前致谢！
实例 #1 (更快)配置如下：
ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)
configuration: --prefix=/usr/local/Cellar/ffmpeg/4.1 --enable-shared
--enable-pthreads --enable-version3 --enable-hardcoded-tables
--enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay
--enable-gpl --enable-libmp3lame --enable-libopus --enable-libsnappy
--enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264
--enable-libx265 --enable-libxvid --enable-lzma --enable-opencl
--enable-videotoolbox
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
实例 #2 (较慢)配置如下：
ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)
configuration: --enable-gpl --enable-version3 --enable-sdl2
--enable-fontconfig --enable-gnutls --enable-iconv --enable-libass
--enable-libbluray --enable-libfreetype --enable-libmp3lame
--enable-libopencore-amrnb --enable-libopencore-amrwb
--enable-libopenjpeg --enable-libopus --enable-libshine
--enable-libsnappy --enable-libsoxr --enable-libtheora
--enable-libtwolame --enable-libvpx --enable-libwavpack
--enable-libwebp --enable-libx264 --enable-libx265
--enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib
--enable-gmp --enable-libvidstab --enable-libvorbis
--enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex
--enable-libxvid --enable-libaom --enable-appkit
--enable-avfoundation --enable-coreimage --enable-audiotoolbox
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
- - - 更新： - - -
1 - 我尝试使用 --enable-nasm 自行构建 libmp3lame，然后使用构建的 lame 构建 ffmpeg。没有发现任何差异……仍然很慢。
2 - 我在一台更旧的 Mac 上运行了相同的转码测试，结果几乎相同（由于计算机速度较慢，因此结果有所缩小）。
也就是说 libmp3lame 肯定是问题所在！
因此，我决定，对于我的应用程序，我将使用一种变通方法 - 我将更倾向于将代码转换为 AAC 而不是 MP3。AAC 代码转换在我的所有 ffmpeg 实例上都快如闪电，并且我的应用程序很好地支持 AAC。我还将继续调查 libmp3lame 速度慢的问题，但目前，我的应用程序已解禁。
感谢大家的帮助！（特别感谢@Gyan 和@ llogan）
答案1
这可能是 LAME 的一个错误
我把这个问题告知了 Zeranoe 和 johnvansickle.com。John 说这个问题将在 12 月 20 日发布的 git 中得到修复。他说他编译了 lame，CFLAGS="-O3" CPPFLAGS="-DNDEBUG"结果速度提高了 3 倍。
注意 nasm
在我对 Arch Linux 进行的偷懒测试中，启用 nasm 似乎对 3.100 和 3.99.5 产生了显著的影响。
Zeranoe 和 John 都使用 编译了 lame --enable-nasm，因此他们构建的缓慢是由于前面提到的错误造成的。