这两天出的新闻。我搜索了一下，好像都没仔细说这个正在搞的多线程与编解码器的多线程有什么区别。
我在本机执行ffmpeg命令时，用htop查看cpu工作状态，会发现全部16个线程的cpu占用率都达到了90%，推测这个应该是编解码器本身支持多线程。所以我一直以为ffmpeg早就已经支持多线程。
而现在ffmpeg的搞的本身多线程支持，与我在htop中看到的多线程工作，对于用户来讲，到底有什么不同？
这一点我有点搞不清楚，有没有什么简单的解释，或者比喻也行。
fftools/ffmpeg: convert to a threaded architecture
Change the main loop and every component (demuxers, decoders, filters, encoders, muxers) to use the previously added transcode scheduler. Every instance of every such component was already running in a separate thread, but now they can actually run in parallel.
ffmpeg 的各个组件现在分别位于各自的线程中，并应该可以并行运行。
举例而言，ffmpeg 的 filter 组件不支持此前多线程。因此，如果你具有一个足够复杂的 filtergraph，它不能并行完成，这会限制编解码器得到输入的速度，因此可能会成为瓶颈。
正如邮件列表中所说：
“You should see significantly better CPU utilization/wallclock speedup on multicore systems whenever transcoding isn’t dominated by a a single component and the components aren’t themselves already multithreaded.”
然而，由于大部分普通用户的性能瓶颈在于编解码器（而现代的编解码器已经支持多线程），这不会为他们带来显著的性能改进。
感觉更像是从民用转向工业化支持~
其实对于用户来说没有什么可以感知的可见不同，看了一下似乎是ffmpeg架构上的多线程化了，重构提高吞吐量。