我正在使用 FFMPEG 将一些视频合并为一个视频。由于某种原因，它运行得非常慢，几乎不使用任何计算能力（见下图）。我不是重新编译视频。（请参阅下文了解正在运行的脚本。）通常它运行得非常快。事实上，一开始它的速度超过 1000 fps。现在它下降到 50 左右。
重要的是，我同时运行三个会话。也就是说，我复制了bin文件夹（其中包含可执行文件）的三个副本，并分别运行每个副本。不过请注意，三个实例总计约为 140fps显著地比单个实例给出的 1200 多个更糟糕！
有什么方法可以让它充分利用处理能力？我正在使用 Windows 10。
这三个问题看起来相关。
答案1
假设您在旋转磁盘上运行这些转换，您很可能会将 CPU 绑定的作业变成磁盘绑定的作业。
转换过程包括三个任务：
- 从磁盘读取原始文件
- 对数据进行一些计算
- 将结果文件写入磁盘
旋转磁盘擅长顺序读取或写入，但在随机 IO 方面表现极其糟糕 - 因此即使是单个转换也会受到 1. 和 3 之间的并发性的阻碍。这意味着从一个物理磁盘到另一个物理磁盘的转换可能比从一个磁盘到自身的转换更快。
如果现在将此并发性乘以三，则很可能会遇到这样的情况：磁盘的寻道和等待旋转时间远远超过实际读取时间 - 这很容易导致吞吐量下降几个数量级：磁盘的顺序读取速度可以达到 100MB/s 以上，但随机读取速度却不到 1 MB/s，这种情况并不少见。
通常看到的模式是初始性能非常快，而写入缓冲在 RAM 中，但是当缓存已满并且写入确实需要到达磁盘时，就会出现悬崖。
建议： - 首先摆脱旋转生锈 - 现在是 2020 年。 - 如果这不可行，则尝试通过使用不同的磁盘进行读写来限制 IO 并发性。最好的方法可能是创建一个 RAM 磁盘作为目标设备（广播行业通常如此）。事实上，由于 RAM 非常便宜，将 RAM 磁盘转换为 RAM 磁盘可能是一个好主意。 - 仔细选择并发转换作业的数量，以找到 IO 饱和度和 CPU/GPU 饱和度之间的最佳平衡点。