multithreading FFmpeg 中用于最快转换为 h264 的线程计数选项？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/7379980/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Thread count option in FFmpeg for FASTEST conversion to h264?
提问by S B
I need to maximize speedwhile converting videos using FFmpeg to h264
我需要在使用 FFmpeg 将视频转换为 h264 时最大限度地提高速度
- Any input formatof source videos
- User's machine can have any number of cores
- Power and memory consumption are non-issues
- 任何输入格式的源视频
- 用户的机器可以有任意数量的内核
- 功耗和内存消耗不是问题
Of course, there are a whole bunch of options that can be tweaked but this question is particularly about choosing the best -thread <count>option. I am trying to find an ideal thread count as a function of
当然，有很多选项可以调整，但这个问题特别是关于选择最佳-thread <count>选项。我试图找到一个理想的线程数作为
- no. of cores
- input video format
- h264-friendly values maybe?
- anything else missed above?
- 不。核心数
- 输入视频格式
- 可能是 h264 友好的值？
- 上面还有什么遗漏的吗？
I am aware the default -thread 0follows one-thread-per-core approach which is supposed to be optimal. But I am not sure if this is time or space-optimized. Also, on certain testcases, I've seen more threads (say 4 threads on my dual core test machine) finishes quicker than the default.
我知道默认-thread 0遵循每核一个线程的方法，这应该是最佳的。但我不确定这是时间优化还是空间优化。此外，在某些测试用例中，我看到更多线程（比如我的双核测试机上的 4 个线程）比默认值完成得更快。
Any other direction, say configure options w.r.t. threads, worth pursuing?
任何其他方向，比如配置选项wrt线程，值得追求吗？
回答by d33pika
I have found that threadsdo not do a good job of utilizing all the cores, the hyper-threads do not get used at all. One solution I could come up with is to run a 3 to 4 ffmpeg processes in parallel, See: https://superuser.com/questions/538164/how-many-instances-of-ffmpeg-commands-can-i-run-in-parallel/547340#547340This approach ends up using all the cores fully and is faster than the single input, multiple outputs in a single command option.
我发现threads没有很好地利用所有内核，根本没有使用超线程。我能想到的一种解决方案是并行运行 3 到 4 个 ffmpeg 进程，请参阅：https: //superuser.com/questions/538164/how-many-instances-of-ffmpeg-commands-can-i-run -in-parallel/547340#547340这种方法最终会完全使用所有内核，并且比单个命令选项中的单个输入、多个输出更快。
回答by Areeb Soo Yasir
I have experimented thoroughly with threads 0, 6, 12, 24 and it doesn't make a difference in frame rate, overall processing time or CPU utilization. Note my system has 12 physical cores too. Generally it seems to do a good job of using your processing power without specifying threads where my 12 cores are basically 98-99% utilized for the duration while watching top/system monitor.
我已经对线程 0、6、12、24 进行了彻底的试验，它对帧速率、整体处理时间或 CPU 利用率没有影响。请注意，我的系统也有 12 个物理内核。通常，在不指定线程的情况下，它似乎可以很好地使用您的处理能力，而在观看顶部/系统监视器时，我的 12 个内核在这段时间内的利用率基本上为 98-99%。
I wish there was a magic bullet but for now there is no other way to speed things up as ffmpeg is currently optimized very well in my opinion. The only alternative is simply to get more computing power or to do distributed processing.
我希望有一个灵丹妙药，但目前没有其他方法可以加快速度，因为我认为 ffmpeg 目前已得到很好的优化。唯一的选择就是简单地获得更多的计算能力或进行分布式处理。
*Note all my tests were using ffmpeg version 3.3.1
*注意我所有的测试都使用 ffmpeg 3.3.1 版
回答by jesup
If your 'dual-core' has hyperthreading, then 2x cores would probably be correct. There's unlikely to be gain going beyond the number of virtual cores (inc. hyperthreading), but perhaps due to internal issues in FFmpeg it might be true.
如果您的“双核”具有超线程，那么 2x 核可能是正确的。除了虚拟内核的数量（包括超线程）之外，不太可能获得收益，但也许由于 FFmpeg 的内部问题，这可能是真的。
