ffmpeg 编码器流问题

Question

我正在尝试在 linux 上构建 ffmpeg 编码器。我从定制服务器开始，配备 16 GB RAM 的双 1366 2.6 Ghz Xeon CPU(6 核)和 Ubuntu 16.04 最小安装。使用 h264 和 aac 构建 ffmpeg。我正在使用实时源 OTA channel 并使用以下参数对其进行编码/流式传输

-vcodec libx264 -preset superfast -crf 25 -x264opts keyint=60:min-keyint=60:scenecut=-1 -bufsize 7000k -b:v 6000k -maxrate 6300k -muxrate 6000k -s 1920x1080 -format yuv420p -g 60 -sn -c:a aac -b:a 384k -ar 44100

而且我能够使用 mpegts 成功地 udp 输出。我的问题从第 5 个流开始。服务器可以处理四个流，一旦我引入第 5 个流，我就开始在输出中看到打嗝。使用 top 查看我的 cpu 使用率，我仍然看到只有 65% 到 75% 的使用率，偶尔会有 80% 的命中率。内存使用情况在可接受的参数范围内。所以我想知道要么 top 没有给我准确的 cpu 使用率，要么 ffmpeg 有什么不对劲的地方。服务器在 1 Gbps 网络上针对 udp 输入/输出进行了隔离。

我决定提高 CPU 功率并安装了两个 3.5 Ghz CPU(6 核)，认为这可能是 CPU 时钟。令我惊讶的是，结果并没有什么不同。所以现在我想知道当我以 1080p 处理时是否有一些内置限制。如果我将分辨率更改为 720p，它可以处理 8 个流，但 720 是 Not Acceptable 。
我的目标是每台服务器 10 个 1080p 流。
所以我的问题是
1. 如果我使用四核主板并将 cpu 数量增加到 4(6 或 8 个核心)，我会得到 10 个 1080p 流吗？每台机器使用 ffmpeg 是否有任何理论上的最大值？
2. 核心更重要还是时钟更重要？
3. 对我的选项有任何改进建议。我尝试过超快预设，但输出质量 Not Acceptable 。

提前致谢

Answer 1

你真的排除了CPU吗？确保检查每个单独的核心是如何运行的。如果没有核心达到 100%，那么您最有可能的候选者是带宽:要么您的主板无法处理所有来回传输的数据，要么您的内存。用更快的版本交换内存是一个简单的测试，应该会给你答案。