我正在使用 MEncoder 将大量 jpg 图片组合成延时视频。我有两个主要文件夹，每个文件夹大约有 10 个子文件夹，为了自动化我正在运行的过程：
find . -type d -name img -exec sh -c '(cd {} && /Volumes/SAMSUNG/PedestrianBehaviour/BreakableBonds/jpg2avi.sh t*)' ';'
其中 jpg2avi 是 MEncoder 的设置。
mencoder 'mf://t00*.jpg' -mf fps=10 -o raw.avi -ovc lavc -lavcopts vcodec=mpeg4:vhq:vbitrate=2000 -o out.avi
为了并行化它，我在 BreakableBonds 和 UnBreakableBonds 两个文件夹中启动了这个命令。然而，每个过程只使用大约 27%，所以总共略高于 50%。有什么办法可以加速这个吗？这样每个过程大约占50%。（我知道每个进程的 50% 是不可能的。）
根据您使用的视频编解码器（x264 是一个不错的选择），一个编码应该能够使多个 CPU 内核饱和。我通常直接使用 ffmpeg，因为 mencoder 设计时有一些类似 AVI 的假设。
请参阅ffmpeg 的 wiki 页面了解如何执行此操作。
同样，我强烈推荐 mkv 或 mp4 容器中的 h.264，而不是 avi 容器中的任何内容。avi 中的 h.264 是一种 hack，avi 的常用编解码器是 divx (h.263)。h.264 是向前迈出的一大步。
h.264 用于视频就像 mp3 用于音频一样：第一个足够好的编解码器，它的出现恰逢 CPU 变得足够快以实时处理它，并且磁盘和网络能够处理产生好的文件大小质量。将它与ffmpeg 一起用作 libx264 的前端。
h.265（和 vp9）都是比 h.264 更好的编解码器（在压缩效率方面），但支持的范围要小得多，并且需要更多的 CPU 时间。如果要使用它们，请使用 ffmpeg 作为 libx265 或 libvpx 的前端。x265 正在大力开发，因此它可能会有所改进，但几个月前，考虑到相同的编码 CPU 时间，x265 在每比特率的质量上并没有超过 x264。给定更多的CPU 时间，x265 可以做得很好，并且以比 x264 低得多的比特率进行漂亮的编码。
所有这 3 个编解码器都是多线程的，即使在快速设置下也可以使 4 个内核饱和。在更高的设置下（每个块花费更多的 CPU 时间），我猜你至少可以饱和 16 个内核。我不确定，但我认为您可以在 HD x265 编码上有效地利用 64 个内核，甚至更多内核。
在快速设置和高比特率下，gzip 风格的熵编码最后阶段（即 x264 的 CABAC）限制了您可以保持忙碌的 CPU 数量。这是一项串行任务，因此整个编码的速度只有一个 CPU 可以压缩最终比特流的速度。