ffmpeg 默认使用多少线程?

Edw*_*ale 77 ffmpeg

我看到-threads <count>ffmpeg中有一个命令行选项。这个选项的默认值是多少?

Cam*_*une 46

截至 2014 年,它使用最佳数字。

您可以在多核计算机上通过检查 CPU 负载(Linux:top、Windows:任务管理器)和 ffmpeg 的不同选项来验证这一点:

  • -threads 0 (最佳);

  • -threads 1 (单线程);

  • -threads 2 (例如 Intel Core 2 Duo 的 2 个线程);

  • 无(默认值,也是最佳值)。

2015 年编辑:在 12 核 CPU 上,top无论给-threads. 因此,在“与这个 ffmpeg 二进制文件一样好”的意义上,默认值可能仍然是最佳的,但在“充分利用我的 leet CPU”的意义上却不是最佳的。

  • 请注意,这似乎仅适用于编码,不适用于一般处理。如果它实际上没有产生输出帧,那么它就不会并行化。例如,如果您从 02:00 开始去抖动,那么您只能从 02:00 开始获得并行性,但是直到 02:00 的所有内容仍然需要串行处理。 (2认同)

mOl*_*ind 35

这取决于使用的编解码器、ffmpeg 版本和您的 CPU 核心数。有时它只是每个内核一个线程。有时它更复杂,例如:

使用 libx264,它是用于框架线程的内核 x 1.5 和用于切片线程的内核 x 1。

  • 不要依赖它。无论如何,我在 Linux 上的 ffmpeg 0.7.8 默认使用 1 个线程。 (7认同)
  • 谢谢。您有 ffmpeg 支持的一些标准编解码器的默认值参考吗? (3认同)

Mat*_*r58 14

其中一些答案有点陈旧,我想补充一点,我的ffmpeg 4.1, 编码libx264,我的 Ryzen 5 2600X 系统的所有 6 个内核/12 个线程都已达到最大值,没有任何-thread争论。

  • 我有 1800X,我观察到它的 16 个线程的利用率不到 20%,但我也使用了一些可选参数:`-vcodec libx264 -profile:v high444 -refs 14 -preset ultrafast -crf 18 -tune fastdecode` 所以这是一些需要隔离的变量。添加`-threads 12` 没有效果。 (2认同)

cwe*_*ske 10

2015 年,在带有 ffmpeg 0.8.10-6 的 Ubuntu 14.04 上,它在 4 核系统上使用了 1 个核。 htop显示了这一点;只使用了一个核心,我获得了 16 fps 的全高清视频转换率。

使用-threads 4使我所有的 CPU 内核都达到 100%,我的转换率为 47 fps。

我使用了以下命令:

$ ffmpeg -i foo.mp4 -y -target pal-dvd -aspect 16:9 dvd-out.mpg
Run Code Online (Sandbox Code Playgroud)


小智 7

我正在玩转换 CentOS 6.5 VM(Ryzen 1700 8c/16t - vm 分配了 16 个内核中的 12 个)。对 480p 电影的实验得出以下结论:

线程选项/转换率(fps @ 60 秒)

(none/default)/130fps
-threads 1/70fps
-threads 2/120fps
-threads 4/185fps
-threads 6/228fps
-threads 8/204fps
-threads 10/181fps
Run Code Online (Sandbox Code Playgroud)

有趣的部分是 CPU 负载(htop用来观看它)。在 130fps 范围内
不使用任何-threads选项,负载以低负载水平分布在所有内核上。
使用 1 个线程正是如此,以 100% 加载一个核心。使用其他任何东西都会导致另一种传播负载情况。

如您所见,还有一个收益递减点,因此您必须为您的特定机器调整 -threads 选项。特别是对于我的设置,使用 -threads 6(在 12 核机器上)在转换视频(从 h264 到 x264 以不同的比特率强制转换)时获得了最佳 FPS,并且返回实际上减少了我投入的更多线程它。

这也可能是内存问题 - 它只分配给 VM 1GB。我可能会调整它,看看是否会改变任何东西。尽管如此 - 它确实表明使用该-threads选项可以提高性能,因此在不同级别的特定机器上运行一些测试以找到您的设置最佳位置。