1、为什么还要聊多线程？
早期网络编程很多是基于多进程或多线程的，后来event loop方式普及了，再后来协程更受推崇。多线程编程仿佛是个老旧过时的技术，一点都不酷。
但是，单纯的event loop/协程（不使用多线程多进程）无法发挥多核CPU的能力。音视频处理数据量大，是典型的CPU密集型任务，把多线程技术用好，才能降低延迟，增加吞吐量，提升机器利用率，降本增效😃。
软件解码器编码器需要缜密的多线程设计，编解码速度很大程度上取决于多线程设计的好坏。设计粗陋，CPU闲着不干活或者空转。FFmpeg H.265解码存在比较大的多线程设计缺陷，AV1解码器dav1d绝佳的性能一定程度来自它重新设计的多线程处理模式。
本文根据Anton Khirnov在VDD（VideoLan Developer Day）上分享整理而成。
2、FFmpeg cmd是什么？
无须多言，FFmpeg cmd是FFmpeg项目内置的一个命令行工具，是在libavformat、libavcodec、libavfilter之上实现的。很多人学习FFmpeg是从学习FFmpeg命令行使用开始的。
FFmpeg项目起初很小（2000年），FFmpeg命令行只有约700行代码，功能简单：编码YUV视频帧，编码PCM音频帧，封装。
2001年发展成了如下的样子：
之后的发展速度如下：
FFmpeg cmd代码体量增加了，架构上不堪重负，在一个帐篷的基础上扩展成了摩天大楼。成就斐然，大家惊异于FFmpeg cmd的功能，但是到处有隐藏逻辑，处处有惊喜（惊吓），后续发展困难。
典型的转码处理流程如下：
3、FFmpeg cmd多线程重构
重构的目标Anton列了三条，概括来说只有两个：增加项目的可维护性；提高FFmpeg cmd的性能（主要是吞吐量）。注意在说吞吐量时，有个附带条件：right condition。一般的应用到计算量很大的应用，多线程提升明显。但是超简单的场景，多线程额外开销可能超过收益（这种场景并不常见，往往是人为制造的）。
Anton从2021年尾开始，总共有700多个commit，几乎改到了ffmpeg cmd的每一行代码，总体进度如下：
已发布的FFmpeg 6.1版本已经包含了部分工作，预计下个版本7.0最终完成多线程重构。
Anton列了一些未来潜在的发展方向
如何支持脚本化不是难题，但不知脚本化可以用来实现什么功能，读者可以大胆想象。
作者：quink
来源：Fun With FFmpeg
原文：https://mp.weixin.qq.com/s/1ygoMJU6KsleFZNLSfFprw
版权声明：本文内容转自互联网，本文观点仅代表作者本人。本站仅提供信息存储空间服务，所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至1393616908@qq.com 举报，一经查实，本站将立刻删除。
