Answers:
这取决于所使用的编解码器,ffmpeg版本和您的CPU内核数。有时,每个核心只是一个线程。有时它更复杂,例如:
对于libx264,它是内核x 1.5(用于框架线程)和内核x 1(用于切片线程)。
截至2014年,它使用的是最佳数字。
您可以通过检查top
ffmpeg的不同选项来检查CPU负载(Linux:,Windows:任务管理器),从而在多核计算机上进行验证:
-threads 0
(最佳);
-threads 1
(单线程);
-threads 2
(2个线程,例如Intel Core 2 Duo);
无(默认,也是最佳)。
2015 edit:在12核CPU上,top
无论给定多少数字,某些ffmpeg命令都使Linux 最多显示200%cpu(仅2核)-threads
。因此,默认值在“达到此ffmpeg二进制文件可以获得的最佳性能”的意义上仍可能是最佳的,但在“充分利用我的leet CPU”的意义上则不是最佳的。
其中一些答案有些陈旧,我只想补充一点,我的Ryzen 5 2600X系统的6个内核/ 12个线程的ffmpeg 4.1
编码libx264
都已最大化,而没有任何-thread
参数。
-vcodec libx264 -profile:v high444 -refs 14 -preset ultrafast -crf 18 -tune fastdecode
所以要隔离一些变量。添加-threads 12
没有效果。
我正在使用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
有趣的部分是CPU负载(htop
用于观察)。
不使用任何-threads
选项时,速度将高达130fps,并且负载会以低负载级别分布在所有内核上。
使用1个线程就可以做到这一点,以100%的速度加载一个内核。使用其他任何东西都会导致另一种分散负载情况。
如您所见,还有一点是收益递减,因此您必须为特定计算机调整-threads选项。具体来说,对于我的设置,使用-threads 6(在12核计算机上)在转换视频(以不同的比特率将h264转换为x264以强制转换)时可获得最佳的FPS,实际上返回值减少了我投入的更多线程它。
这也可能是内存问题-仅分配给VM 1GB。我可能会对其进行调整,看看是否有任何改变。尽管如此-它的确显示了使用该-threads
选项可以提高性能,因此可以在特定计算机上的不同级别上进行一些测试,以找到设置的最佳位置。
假设您启用了线程,它将分配1.5倍的内核数。
-x264-params sliced-threads=1
。或通过使用-tune zerolatency
。