1. 从单线程卡顿说起为什么拉流必须上多线程做过音视频拉流的朋友大概率都经历过这样的场景单线程跑一个拉流任务本地测试稳如老狗一旦并发路数上去或者网络稍微抖一抖画面就开始卡顿、延迟越堆越高甚至直接断流。更让人头疼的是主线程被拉流的阻塞读操作死死占住界面刷新、状态上报、日志写入全部跟着遭殃。这不是代码写得烂而是单线程模型在处理持续输入 实时处理这类任务时天然存在结构性瓶颈。FFmpeg 本身提供了相当成熟的网络拉流能力avformat_open_input打开流、av_read_frame循环读包这套流程几乎每个做音视频的人都写过。但问题恰恰出在av_read_frame这个调用上——它是一个同步阻塞操作网络好的时候几十毫秒返回一次网络差的时候可能卡住几百毫秒甚至更久。如果整个程序只有一条线程在跑这个循环那么在这段阻塞时间里程序什么都做不了。这就是为什么多线程拉流不是一个炫技选项而是工程落地的刚需。所谓多线程拉流核心思路并不复杂把读数据和处理数据这两件事拆到不同的线程里让它们各司其职、互不阻塞。读线程只管从网络把包读进来塞进一个缓冲区处理线程从缓冲区取包做解码、渲染、转发或者落盘。中间用一个线程安全的队列衔接再配合条件变量做唤醒和等待。听起来简单但真正写好、写稳里面有不少门道。这篇文章面向的是已经会用 FFmpeg 做基础拉流、但被并发和卡顿问题困扰的开发者。我会从线程模型设计讲起把队列实现、线程生命周期管理、断流重连、资源释放这些关键环节逐一拆开配上可直接参考的代码骨架和参数说明。如果你正在做多路拉流、直播转发、录制或者监控类项目这篇内容应该能帮你少走不少弯路。需要说明的是文中涉及的线程数量、缓冲区大小等参数都是基于常见工程实践给出的经验值实际项目里还需要结合你的硬件和网络情况做压测调整。2. 拉流线程模型怎么设计才不踩坑2.1 三种常见线程模型的取舍在动手写代码之前先把线程模型想清楚比上来就敲键盘重要得多。我见过不少项目一开始图省事用最简单的模型结果后期越改越乱最后推倒重来。常见的拉流线程模型大致有三种各有适用场景。第一种是单线程阻塞模型也就是主线程直接跑av_read_frame循环。这种模型代码最简单适合单路、对实时性要求不高的场景比如本地文件转码。但它的致命伤是阻塞期间无法响应任何其他事件一旦网络卡顿整个程序就像死了一样。多路并发时基本不可用。第二种是读线程 处理线程的双线程模型。读线程负责av_read_frame把读到的 AVPacket 放进队列处理线程从队列取包做后续处理。这是最经典也最实用的模型绝大多数多路拉流项目都建立在这个基础上。它的好处是职责清晰读线程永远不被处理逻辑拖慢处理线程也不会因为网络抖动而饿死。第三种是读线程 解码线程 渲染/输出线程的多级流水线模型。这种模型把解码也独立出来适合对延迟极其敏感、或者解码耗时较长的场景比如 4K 高码率视频。但线程越多同步和资源管理的复杂度就越高出 bug 的概率也越大。我的建议是除非有明确的性能瓶颈证明双线程不够用否则优先选双线程模型。多级流水线带来的收益往往抵不过它增加的维护成本。下面这张表可以帮你快速判断模型线程数适用场景主要风险单线程阻塞1单路、离线处理卡顿、无法响应事件双线程2多路并发、直播转发队列积压、内存增长多级流水线3高码率、低延迟同步复杂、调试困难2.2 读线程的职责边界要划清楚读线程的职责应该尽可能单一只做从网络读取数据包这一件事。很多新手容易犯的错误是在读线程里顺手做了解码、格式转换甚至写文件结果读线程被这些耗时操作拖住网络缓冲区很快被填满丢包随之而来。读线程的标准流程是这样的打开输入上下文、找到流信息、进入循环调用av_read_frame、把包投递到队列、检查退出标志。整个过程里除了必要的错误判断和重连逻辑不应该有任何耗时操作。投递到队列这个动作本身要足够快如果队列满了要有明确的策略——是丢弃旧包、阻塞等待还是直接退出这取决于你的业务需求。这里有个容易被忽略的细节av_read_frame返回的 AVPacket 需要做引用计数管理。如果你直接把包指针塞进队列读线程下一轮循环可能会复用这块内存导致处理线程读到脏数据。正确做法是用av_packet_ref增加引用计数或者用av_packet_move_ref转移所有权。我一般推荐后者因为转移所有权后读线程不需要再关心这个包语义更清晰。2.3 处理线程不能拖后腿处理线程从队列取包做解码、渲染、转发等操作。它的核心要求是消费速度要跟得上生产速度否则队列会持续积压内存不断上涨最终 OOM。如果处理逻辑确实很慢比如要做复杂的图像处理那就需要考虑多级流水线或者对包做丢弃策略。处理线程取包的逻辑通常是加锁、判断队列是否为空、为空则等待条件变量、不为空则取出一个包、解锁、处理。这里有个经典陷阱——条件变量的等待必须放在 while 循环里而不是 if 判断。因为条件变量可能被虚假唤醒用 if 的话唤醒后发现队列还是空的就会取到空指针。这个坑我踩过不止一次排查起来还挺费劲。另外处理线程在处理完一个包后要记得调用av_packet_unref释放包占用的内存。AVPacket 内部可能持有引用计数的缓冲区不释放的话内存会持续泄漏。这个释放动作要放在处理逻辑之后确保包已经用完。3. 线程安全队列的实现细节与内存管理3.1 队列的数据结构选型队列是连接读线程和处理线程的桥梁它的实现质量直接决定了整个拉流模块的稳定性。最基础的做法是用一个std::queue配合互斥锁和条件变量这在大多数场景下已经够用。但如果你的项目对性能要求极高可以考虑无锁队列不过无锁队列的调试难度会陡增我一般不建议在业务代码里轻易上。用std::queue实现时有几个关键点要注意。首先是锁的粒度投递和取出都要加同一把互斥锁保证队列操作的原子性。其次是条件变量的使用读线程投递后要notify_one唤醒处理线程处理线程取出后如果队列从满变不满也要通知读线程。最后是队列容量必须设一个上限否则网络快、处理慢的时候队列会无限增长。队列容量的设置是个经验活。太小了容易丢包太大了内存占用高且延迟大。我的经验是按每秒包数和可接受延迟来估算。比如视频流每秒 30 帧每帧可能对应几个包如果希望最大延迟不超过 1 秒那队列容量设在几百个包的量级比较合适。当然这还要看包的平均大小如果单个包很大容量就得相应调小。3.2 包的内存管理不能马虎AVPacket 的内存管理是拉流代码里最容易出问题的地方。FFmpeg 的 AVPacket 有两种状态一种是自己持有数据缓冲区另一种是引用别人的缓冲区。用av_packet_ref会增加引用计数用av_packet_unref会减少引用计数当计数归零时缓冲区才真正释放。在多线程场景下包的生命周期跨越了两个线程管理起来要格外小心。我的做法是读线程用av_packet_alloc分配一个包av_read_frame填充数据然后用av_packet_move_ref把数据转移到队列里的包对象上。这样读线程的包变成空包可以继续下一轮读取而队列里的包独立持有数据。处理线程取到包后处理完调用av_packet_unref释放。这里有个细节值得强调av_packet_move_ref之后源包会被重置为空包但它的结构体内存还在可以复用。所以读线程不需要每轮都重新分配包用一个包对象循环使用即可这样能减少内存分配开销。但要注意如果队列里已经有包在等待处理读线程就不能复用同一个包对象了因为数据已经被转移走了。所以实际做法是每轮读取前分配新包或者维护一个包对象池。3.3 退出与清理的时机把握线程退出和资源清理是最容易出 bug 的环节尤其是在程序异常退出或者需要动态停止某路拉流的时候。核心原则是先通知退出再唤醒等待最后 join 线程。具体来说需要维护一个原子布尔变量作为退出标志。读线程在每次循环开始时检查这个标志如果为真就跳出循环。但读线程可能正阻塞在av_read_frame上这时候光设标志没用还得想办法打断阻塞。FFmpeg 提供了avformat_close_input和中断回调两种方式前者会关闭输入上下文后者通过AVIOInterruptCB在阻塞时定期检查是否需要中断。我推荐用中断回调因为它更可控不会导致资源状态混乱。处理线程可能正阻塞在条件变量上等待所以设置退出标志后要调用notify_all唤醒它。处理线程被唤醒后检查退出标志如果为真就跳出循环。最后主线程调用join等待两个线程真正结束再释放队列、包、输入上下文等资源。顺序不能乱否则可能出现线程还在访问已释放资源的情况。4. 断流重连与异常处理让拉流真正稳下来4.1 网络抖动下的重连策略网络拉流最怕的就是断流而断流在实际网络环境里几乎是必然事件。一个健壮的拉流模块必须能自动检测断流并重连而不是直接崩溃或者卡死。断流的检测主要靠av_read_frame的返回值如果返回 AVERROR_EOF 或者负数错误码就说明流出了问题。重连策略的核心是退避。不能一断流就立刻重连那样在网络持续不可用时会疯狂重试既浪费资源又可能被服务端限流。常见的做法是指数退避第一次断流等 1 秒重连失败等 2 秒再失败等 4 秒直到一个上限比如 30 秒。重连成功后退避时间重置。重连时要注意资源的清理和重建。输入上下文需要关闭再重新打开因为断流后的上下文状态可能已经不可用。但队列里的包可以保留这样重连后处理线程还能继续消费之前积压的数据避免画面出现空洞。当然如果积压太多也可以选择清空队列这取决于业务对实时性和连续性的权衡。4.2 超时设置是稳定性的关键FFmpeg 默认的超时时间可能很长网络卡住时av_read_frame可能阻塞几十秒都不返回。这在多路拉流场景下是灾难性的因为一路卡住可能拖垮整个程序的响应。所以必须显式设置超时参数。设置超时主要有两个途径。一是通过AVDictionary设置timeout或者rw_timeout选项单位是微秒。比如设置 5 秒超时就是 5000000。二是通过AVIOInterruptCB回调在回调里检查是否超时返回 1 表示中断。我一般两个都用字典选项设置基础超时中断回调做更精细的控制比如结合退出标志一起判断。超时时间设多少合适这要看你的业务容忍度。直播场景一般 3 到 5 秒比较合适太短了容易误判正常抖动为断流太长了卡顿感明显。点播或者录制场景可以放宽到 10 秒甚至更长。设置完超时后一定要实测网络异常情况下的表现确保能按预期触发重连。4.3 错误码的分类处理av_read_frame返回的错误码有好几种不能一概而论都当断流处理。AVERROR_EOF 表示流正常结束比如点播文件读完这时候不需要重连直接结束即可。AVERROR(EAGAIN) 表示暂时没有数据通常出现在非阻塞模式下这时候应该继续读而不是重连。其他负数错误码比如网络错误、协议错误才需要触发重连。把错误码分类处理能避免很多误重连。我见过有的代码只要返回值小于零就重连结果点播文件读完也去重连陷入死循环。正确的做法是维护一个错误处理函数根据错误码决定是继续、重连还是退出。这个函数最好把错误码转成可读的字符串方便日志排查FFmpeg 提供了av_strerror来做这件事。5. 多路并发下的资源控制与性能调优5.1 线程数量与系统资源的平衡多路拉流意味着多组线程每路至少两个线程。如果拉 50 路那就是 100 个线程。线程本身的开销不算大但每个线程的栈空间默认可能是 8MB100 个线程就是 800MB 虚拟内存这在资源受限的设备上可能吃不消。所以要根据实际硬件调整线程栈大小一般 1MB 到 2MB 足够拉流线程使用。除了线程栈还要考虑文件描述符的限制。每个网络连接占用一个 fd多路拉流会快速消耗 fd 数量。在 Linux 上要检查ulimit -n的值必要时调大。另外FFmpeg 内部可能还会创建一些辅助线程用于解码这些也要算进总线程数里。我的经验是在普通服务器上单进程拉 100 路左右是比较稳妥的再往上就要考虑多进程或者分布式了。当然这取决于码率和处理复杂度高码率 4K 流可能 20 路就到瓶颈了。压测是确定上限的唯一可靠方法别凭感觉拍脑袋。5.2 缓冲区大小的调优缓冲区包括网络接收缓冲和队列缓冲两部分。网络接收缓冲可以通过AVDictionary的buffer_size选项设置默认值可能偏小在高延迟高带宽场景下容易丢包。适当调大能提升稳定性但也会增加内存占用和延迟。队列缓冲的大小前面提过这里补充一点队列里存的是包包的大小差异很大。关键帧包可能几百 KB普通包可能几 KB。所以按包个数设容量不够精确更好的做法是按总字节数设上限。比如限制队列最多缓存 10MB 数据超过就触发丢弃策略。这样无论包大小如何内存占用都是可控的。丢弃策略也要想清楚。直播场景通常丢旧包保新包因为旧数据已经没意义了录制场景则不能丢宁可阻塞读线程也不能丢数据。所以队列的满处理策略应该做成可配置的根据业务场景选择。5.3 用日志和监控定位性能瓶颈多路拉流出问题时光看现象很难定位原因必须靠日志和监控数据。我习惯在每个关键节点打日志读线程读包速率、队列当前深度、处理线程处理速率、重连次数、错误码分布。这些数据能快速告诉你瓶颈在哪。如果发现队列深度持续上涨说明处理跟不上读要么优化处理逻辑要么增加处理线程。如果读包速率上不去可能是网络带宽不够或者超时设置太短导致频繁重连。如果重连次数异常高要检查网络质量和超时参数。把这些指标做成实时监控面板运维起来会轻松很多。日志本身也要注意性能高频打日志会拖慢线程。我的做法是采样打点比如每 100 个包打一次或者用环形缓冲区暂存日志由独立线程异步写入。这样既保留了排查能力又不影响主流程性能。6. 一套可复用的拉流线程骨架6.1 核心结构体与初始化把前面的设计整合起来可以抽象出一套可复用的拉流线程骨架。核心结构体包含输入上下文、队列、线程句柄、退出标志、超时配置等成员。初始化时完成网络初始化、分配队列、设置超时参数然后启动读线程和处理线程。struct StreamContext { AVFormatContext* fmt_ctx nullptr; PacketQueue queue; std::thread read_thread; std::thread process_thread; std::atomicbool abort_request{false}; int64_t open_timeout_us 5000000; int64_t read_timeout_us 5000000; std::string url; };初始化函数里用avformat_open_input打开流用avformat_find_stream_info获取流信息然后创建两个线程。注意打开流之前要设置好超时字典否则打开阶段就可能卡死。6.2 读线程与处理线程的实现要点读线程的主循环里先检查退出标志再调用av_read_frame。返回成功就投递包返回错误就分类处理。投递包时如果队列满根据策略决定丢弃还是等待。循环结束后清理输入上下文。处理线程的主循环里从队列取包取到就处理处理完释放包。队列空就等待条件变量被唤醒后先检查退出标志。处理逻辑根据业务不同而不同可能是解码、转发或者写文件。两个线程的退出都要响应 abort_request并且要保证退出时队列里的包被正确释放避免内存泄漏。这部分代码虽然不复杂但细节多建议封装成独立的类把线程管理和资源生命周期都管起来。6.3 实测中的几个意外情况实际跑起来后有几个情况是我一开始没预料到的。第一个是重连后时间戳跳变断流重连后新流的时间戳可能从零开始或者跳到一个很大的值导致处理端计算延迟时出现负数或者巨大值。解决办法是记录断流前的时间戳重连后做偏移校正。第二个是队列积压导致的重连延迟断流时队列里可能还有大量包处理线程还在慢慢消费这时候读线程已经在重连了新旧数据混在一起。我的处理是断流时给队列打一个标记处理线程遇到标记就清空队列避免新旧数据混淆。第三个是频繁重连导致的日志爆炸网络持续不好时重连日志会刷屏。后来我加了日志限流同一路流一分钟内最多打几条重连日志既保留了信息又不至于淹没其他日志。7. 我在多线程拉流上踩过的那些坑第一个坑是条件变量用 if 判断。前面提过虚假唤醒会导致取到空包程序崩溃。这个 bug 偶发很难复现我花了大半天才定位到。后来养成习惯条件变量等待一律用 while。第二个坑是包引用计数没处理好。早期代码直接把av_read_frame的包指针塞进队列结果处理线程读到的数据时对时错。原因是读线程下一轮读取时覆盖了同一块内存。改成av_packet_move_ref后问题消失。这个坑的教训是跨线程传递数据一定要明确所有权。第三个坑是退出时线程还在访问已释放资源。有一次程序退出时偶发崩溃查了半天发现是主线程先释放了队列而处理线程还在从队列取包。后来改成先设退出标志、再唤醒、再 join最后才释放资源问题解决。资源释放的顺序在多线程程序里是生死攸关的事。第四个坑是超时设置不当导致误重连。一开始超时设了 1 秒结果网络稍微抖一下就重连画面频繁中断。后来调到 5 秒配合指数退避稳定性明显提升。超时参数一定要结合实际网络环境调没有万能值。第五个坑是线程栈溢出。在处理线程里做了一些递归调用加上默认栈空间偶尔会栈溢出崩溃。后来把处理逻辑改成迭代实现并把线程栈调到 2MB问题解决。多线程程序里栈空间是有限资源递归要慎用。这些坑说到底都指向同一个道理多线程拉流的难点不在 FFmpeg API 本身而在并发控制和资源生命周期管理。把这两件事想清楚、做扎实拉流模块的稳定性就有了基本保障。至于具体的参数调优那是在稳定基础上的锦上添花可以慢慢打磨。
1. 从单线程卡顿说起为什么拉流必须上多线程做过音视频拉流的朋友大概率都经历过这样的场景单线程跑一个拉流任务本地测试稳如老狗一旦并发路数上去或者网络稍微抖一抖画面就开始卡顿、延迟越堆越高甚至直接断流。更让人头疼的是主线程被拉流的阻塞读操作死死占住界面刷新、状态上报、日志写入全部跟着遭殃。这不是代码写得烂而是单线程模型在处理持续输入 实时处理这类任务时天然存在结构性瓶颈。FFmpeg 本身提供了相当成熟的网络拉流能力avformat_open_input打开流、av_read_frame循环读包这套流程几乎每个做音视频的人都写过。但问题恰恰出在av_read_frame这个调用上——它是一个同步阻塞操作网络好的时候几十毫秒返回一次网络差的时候可能卡住几百毫秒甚至更久。如果整个程序只有一条线程在跑这个循环那么在这段阻塞时间里程序什么都做不了。这就是为什么多线程拉流不是一个炫技选项而是工程落地的刚需。所谓多线程拉流核心思路并不复杂把读数据和处理数据这两件事拆到不同的线程里让它们各司其职、互不阻塞。读线程只管从网络把包读进来塞进一个缓冲区处理线程从缓冲区取包做解码、渲染、转发或者落盘。中间用一个线程安全的队列衔接再配合条件变量做唤醒和等待。听起来简单但真正写好、写稳里面有不少门道。这篇文章面向的是已经会用 FFmpeg 做基础拉流、但被并发和卡顿问题困扰的开发者。我会从线程模型设计讲起把队列实现、线程生命周期管理、断流重连、资源释放这些关键环节逐一拆开配上可直接参考的代码骨架和参数说明。如果你正在做多路拉流、直播转发、录制或者监控类项目这篇内容应该能帮你少走不少弯路。需要说明的是文中涉及的线程数量、缓冲区大小等参数都是基于常见工程实践给出的经验值实际项目里还需要结合你的硬件和网络情况做压测调整。2. 拉流线程模型怎么设计才不踩坑2.1 三种常见线程模型的取舍在动手写代码之前先把线程模型想清楚比上来就敲键盘重要得多。我见过不少项目一开始图省事用最简单的模型结果后期越改越乱最后推倒重来。常见的拉流线程模型大致有三种各有适用场景。第一种是单线程阻塞模型也就是主线程直接跑av_read_frame循环。这种模型代码最简单适合单路、对实时性要求不高的场景比如本地文件转码。但它的致命伤是阻塞期间无法响应任何其他事件一旦网络卡顿整个程序就像死了一样。多路并发时基本不可用。第二种是读线程 处理线程的双线程模型。读线程负责av_read_frame把读到的 AVPacket 放进队列处理线程从队列取包做后续处理。这是最经典也最实用的模型绝大多数多路拉流项目都建立在这个基础上。它的好处是职责清晰读线程永远不被处理逻辑拖慢处理线程也不会因为网络抖动而饿死。第三种是读线程 解码线程 渲染/输出线程的多级流水线模型。这种模型把解码也独立出来适合对延迟极其敏感、或者解码耗时较长的场景比如 4K 高码率视频。但线程越多同步和资源管理的复杂度就越高出 bug 的概率也越大。我的建议是除非有明确的性能瓶颈证明双线程不够用否则优先选双线程模型。多级流水线带来的收益往往抵不过它增加的维护成本。下面这张表可以帮你快速判断模型线程数适用场景主要风险单线程阻塞1单路、离线处理卡顿、无法响应事件双线程2多路并发、直播转发队列积压、内存增长多级流水线3高码率、低延迟同步复杂、调试困难2.2 读线程的职责边界要划清楚读线程的职责应该尽可能单一只做从网络读取数据包这一件事。很多新手容易犯的错误是在读线程里顺手做了解码、格式转换甚至写文件结果读线程被这些耗时操作拖住网络缓冲区很快被填满丢包随之而来。读线程的标准流程是这样的打开输入上下文、找到流信息、进入循环调用av_read_frame、把包投递到队列、检查退出标志。整个过程里除了必要的错误判断和重连逻辑不应该有任何耗时操作。投递到队列这个动作本身要足够快如果队列满了要有明确的策略——是丢弃旧包、阻塞等待还是直接退出这取决于你的业务需求。这里有个容易被忽略的细节av_read_frame返回的 AVPacket 需要做引用计数管理。如果你直接把包指针塞进队列读线程下一轮循环可能会复用这块内存导致处理线程读到脏数据。正确做法是用av_packet_ref增加引用计数或者用av_packet_move_ref转移所有权。我一般推荐后者因为转移所有权后读线程不需要再关心这个包语义更清晰。2.3 处理线程不能拖后腿处理线程从队列取包做解码、渲染、转发等操作。它的核心要求是消费速度要跟得上生产速度否则队列会持续积压内存不断上涨最终 OOM。如果处理逻辑确实很慢比如要做复杂的图像处理那就需要考虑多级流水线或者对包做丢弃策略。处理线程取包的逻辑通常是加锁、判断队列是否为空、为空则等待条件变量、不为空则取出一个包、解锁、处理。这里有个经典陷阱——条件变量的等待必须放在 while 循环里而不是 if 判断。因为条件变量可能被虚假唤醒用 if 的话唤醒后发现队列还是空的就会取到空指针。这个坑我踩过不止一次排查起来还挺费劲。另外处理线程在处理完一个包后要记得调用av_packet_unref释放包占用的内存。AVPacket 内部可能持有引用计数的缓冲区不释放的话内存会持续泄漏。这个释放动作要放在处理逻辑之后确保包已经用完。3. 线程安全队列的实现细节与内存管理3.1 队列的数据结构选型队列是连接读线程和处理线程的桥梁它的实现质量直接决定了整个拉流模块的稳定性。最基础的做法是用一个std::queue配合互斥锁和条件变量这在大多数场景下已经够用。但如果你的项目对性能要求极高可以考虑无锁队列不过无锁队列的调试难度会陡增我一般不建议在业务代码里轻易上。用std::queue实现时有几个关键点要注意。首先是锁的粒度投递和取出都要加同一把互斥锁保证队列操作的原子性。其次是条件变量的使用读线程投递后要notify_one唤醒处理线程处理线程取出后如果队列从满变不满也要通知读线程。最后是队列容量必须设一个上限否则网络快、处理慢的时候队列会无限增长。队列容量的设置是个经验活。太小了容易丢包太大了内存占用高且延迟大。我的经验是按每秒包数和可接受延迟来估算。比如视频流每秒 30 帧每帧可能对应几个包如果希望最大延迟不超过 1 秒那队列容量设在几百个包的量级比较合适。当然这还要看包的平均大小如果单个包很大容量就得相应调小。3.2 包的内存管理不能马虎AVPacket 的内存管理是拉流代码里最容易出问题的地方。FFmpeg 的 AVPacket 有两种状态一种是自己持有数据缓冲区另一种是引用别人的缓冲区。用av_packet_ref会增加引用计数用av_packet_unref会减少引用计数当计数归零时缓冲区才真正释放。在多线程场景下包的生命周期跨越了两个线程管理起来要格外小心。我的做法是读线程用av_packet_alloc分配一个包av_read_frame填充数据然后用av_packet_move_ref把数据转移到队列里的包对象上。这样读线程的包变成空包可以继续下一轮读取而队列里的包独立持有数据。处理线程取到包后处理完调用av_packet_unref释放。这里有个细节值得强调av_packet_move_ref之后源包会被重置为空包但它的结构体内存还在可以复用。所以读线程不需要每轮都重新分配包用一个包对象循环使用即可这样能减少内存分配开销。但要注意如果队列里已经有包在等待处理读线程就不能复用同一个包对象了因为数据已经被转移走了。所以实际做法是每轮读取前分配新包或者维护一个包对象池。3.3 退出与清理的时机把握线程退出和资源清理是最容易出 bug 的环节尤其是在程序异常退出或者需要动态停止某路拉流的时候。核心原则是先通知退出再唤醒等待最后 join 线程。具体来说需要维护一个原子布尔变量作为退出标志。读线程在每次循环开始时检查这个标志如果为真就跳出循环。但读线程可能正阻塞在av_read_frame上这时候光设标志没用还得想办法打断阻塞。FFmpeg 提供了avformat_close_input和中断回调两种方式前者会关闭输入上下文后者通过AVIOInterruptCB在阻塞时定期检查是否需要中断。我推荐用中断回调因为它更可控不会导致资源状态混乱。处理线程可能正阻塞在条件变量上等待所以设置退出标志后要调用notify_all唤醒它。处理线程被唤醒后检查退出标志如果为真就跳出循环。最后主线程调用join等待两个线程真正结束再释放队列、包、输入上下文等资源。顺序不能乱否则可能出现线程还在访问已释放资源的情况。4. 断流重连与异常处理让拉流真正稳下来4.1 网络抖动下的重连策略网络拉流最怕的就是断流而断流在实际网络环境里几乎是必然事件。一个健壮的拉流模块必须能自动检测断流并重连而不是直接崩溃或者卡死。断流的检测主要靠av_read_frame的返回值如果返回 AVERROR_EOF 或者负数错误码就说明流出了问题。重连策略的核心是退避。不能一断流就立刻重连那样在网络持续不可用时会疯狂重试既浪费资源又可能被服务端限流。常见的做法是指数退避第一次断流等 1 秒重连失败等 2 秒再失败等 4 秒直到一个上限比如 30 秒。重连成功后退避时间重置。重连时要注意资源的清理和重建。输入上下文需要关闭再重新打开因为断流后的上下文状态可能已经不可用。但队列里的包可以保留这样重连后处理线程还能继续消费之前积压的数据避免画面出现空洞。当然如果积压太多也可以选择清空队列这取决于业务对实时性和连续性的权衡。4.2 超时设置是稳定性的关键FFmpeg 默认的超时时间可能很长网络卡住时av_read_frame可能阻塞几十秒都不返回。这在多路拉流场景下是灾难性的因为一路卡住可能拖垮整个程序的响应。所以必须显式设置超时参数。设置超时主要有两个途径。一是通过AVDictionary设置timeout或者rw_timeout选项单位是微秒。比如设置 5 秒超时就是 5000000。二是通过AVIOInterruptCB回调在回调里检查是否超时返回 1 表示中断。我一般两个都用字典选项设置基础超时中断回调做更精细的控制比如结合退出标志一起判断。超时时间设多少合适这要看你的业务容忍度。直播场景一般 3 到 5 秒比较合适太短了容易误判正常抖动为断流太长了卡顿感明显。点播或者录制场景可以放宽到 10 秒甚至更长。设置完超时后一定要实测网络异常情况下的表现确保能按预期触发重连。4.3 错误码的分类处理av_read_frame返回的错误码有好几种不能一概而论都当断流处理。AVERROR_EOF 表示流正常结束比如点播文件读完这时候不需要重连直接结束即可。AVERROR(EAGAIN) 表示暂时没有数据通常出现在非阻塞模式下这时候应该继续读而不是重连。其他负数错误码比如网络错误、协议错误才需要触发重连。把错误码分类处理能避免很多误重连。我见过有的代码只要返回值小于零就重连结果点播文件读完也去重连陷入死循环。正确的做法是维护一个错误处理函数根据错误码决定是继续、重连还是退出。这个函数最好把错误码转成可读的字符串方便日志排查FFmpeg 提供了av_strerror来做这件事。5. 多路并发下的资源控制与性能调优5.1 线程数量与系统资源的平衡多路拉流意味着多组线程每路至少两个线程。如果拉 50 路那就是 100 个线程。线程本身的开销不算大但每个线程的栈空间默认可能是 8MB100 个线程就是 800MB 虚拟内存这在资源受限的设备上可能吃不消。所以要根据实际硬件调整线程栈大小一般 1MB 到 2MB 足够拉流线程使用。除了线程栈还要考虑文件描述符的限制。每个网络连接占用一个 fd多路拉流会快速消耗 fd 数量。在 Linux 上要检查ulimit -n的值必要时调大。另外FFmpeg 内部可能还会创建一些辅助线程用于解码这些也要算进总线程数里。我的经验是在普通服务器上单进程拉 100 路左右是比较稳妥的再往上就要考虑多进程或者分布式了。当然这取决于码率和处理复杂度高码率 4K 流可能 20 路就到瓶颈了。压测是确定上限的唯一可靠方法别凭感觉拍脑袋。5.2 缓冲区大小的调优缓冲区包括网络接收缓冲和队列缓冲两部分。网络接收缓冲可以通过AVDictionary的buffer_size选项设置默认值可能偏小在高延迟高带宽场景下容易丢包。适当调大能提升稳定性但也会增加内存占用和延迟。队列缓冲的大小前面提过这里补充一点队列里存的是包包的大小差异很大。关键帧包可能几百 KB普通包可能几 KB。所以按包个数设容量不够精确更好的做法是按总字节数设上限。比如限制队列最多缓存 10MB 数据超过就触发丢弃策略。这样无论包大小如何内存占用都是可控的。丢弃策略也要想清楚。直播场景通常丢旧包保新包因为旧数据已经没意义了录制场景则不能丢宁可阻塞读线程也不能丢数据。所以队列的满处理策略应该做成可配置的根据业务场景选择。5.3 用日志和监控定位性能瓶颈多路拉流出问题时光看现象很难定位原因必须靠日志和监控数据。我习惯在每个关键节点打日志读线程读包速率、队列当前深度、处理线程处理速率、重连次数、错误码分布。这些数据能快速告诉你瓶颈在哪。如果发现队列深度持续上涨说明处理跟不上读要么优化处理逻辑要么增加处理线程。如果读包速率上不去可能是网络带宽不够或者超时设置太短导致频繁重连。如果重连次数异常高要检查网络质量和超时参数。把这些指标做成实时监控面板运维起来会轻松很多。日志本身也要注意性能高频打日志会拖慢线程。我的做法是采样打点比如每 100 个包打一次或者用环形缓冲区暂存日志由独立线程异步写入。这样既保留了排查能力又不影响主流程性能。6. 一套可复用的拉流线程骨架6.1 核心结构体与初始化把前面的设计整合起来可以抽象出一套可复用的拉流线程骨架。核心结构体包含输入上下文、队列、线程句柄、退出标志、超时配置等成员。初始化时完成网络初始化、分配队列、设置超时参数然后启动读线程和处理线程。struct StreamContext { AVFormatContext* fmt_ctx nullptr; PacketQueue queue; std::thread read_thread; std::thread process_thread; std::atomicbool abort_request{false}; int64_t open_timeout_us 5000000; int64_t read_timeout_us 5000000; std::string url; };初始化函数里用avformat_open_input打开流用avformat_find_stream_info获取流信息然后创建两个线程。注意打开流之前要设置好超时字典否则打开阶段就可能卡死。6.2 读线程与处理线程的实现要点读线程的主循环里先检查退出标志再调用av_read_frame。返回成功就投递包返回错误就分类处理。投递包时如果队列满根据策略决定丢弃还是等待。循环结束后清理输入上下文。处理线程的主循环里从队列取包取到就处理处理完释放包。队列空就等待条件变量被唤醒后先检查退出标志。处理逻辑根据业务不同而不同可能是解码、转发或者写文件。两个线程的退出都要响应 abort_request并且要保证退出时队列里的包被正确释放避免内存泄漏。这部分代码虽然不复杂但细节多建议封装成独立的类把线程管理和资源生命周期都管起来。6.3 实测中的几个意外情况实际跑起来后有几个情况是我一开始没预料到的。第一个是重连后时间戳跳变断流重连后新流的时间戳可能从零开始或者跳到一个很大的值导致处理端计算延迟时出现负数或者巨大值。解决办法是记录断流前的时间戳重连后做偏移校正。第二个是队列积压导致的重连延迟断流时队列里可能还有大量包处理线程还在慢慢消费这时候读线程已经在重连了新旧数据混在一起。我的处理是断流时给队列打一个标记处理线程遇到标记就清空队列避免新旧数据混淆。第三个是频繁重连导致的日志爆炸网络持续不好时重连日志会刷屏。后来我加了日志限流同一路流一分钟内最多打几条重连日志既保留了信息又不至于淹没其他日志。7. 我在多线程拉流上踩过的那些坑第一个坑是条件变量用 if 判断。前面提过虚假唤醒会导致取到空包程序崩溃。这个 bug 偶发很难复现我花了大半天才定位到。后来养成习惯条件变量等待一律用 while。第二个坑是包引用计数没处理好。早期代码直接把av_read_frame的包指针塞进队列结果处理线程读到的数据时对时错。原因是读线程下一轮读取时覆盖了同一块内存。改成av_packet_move_ref后问题消失。这个坑的教训是跨线程传递数据一定要明确所有权。第三个坑是退出时线程还在访问已释放资源。有一次程序退出时偶发崩溃查了半天发现是主线程先释放了队列而处理线程还在从队列取包。后来改成先设退出标志、再唤醒、再 join最后才释放资源问题解决。资源释放的顺序在多线程程序里是生死攸关的事。第四个坑是超时设置不当导致误重连。一开始超时设了 1 秒结果网络稍微抖一下就重连画面频繁中断。后来调到 5 秒配合指数退避稳定性明显提升。超时参数一定要结合实际网络环境调没有万能值。第五个坑是线程栈溢出。在处理线程里做了一些递归调用加上默认栈空间偶尔会栈溢出崩溃。后来把处理逻辑改成迭代实现并把线程栈调到 2MB问题解决。多线程程序里栈空间是有限资源递归要慎用。这些坑说到底都指向同一个道理多线程拉流的难点不在 FFmpeg API 本身而在并发控制和资源生命周期管理。把这两件事想清楚、做扎实拉流模块的稳定性就有了基本保障。至于具体的参数调优那是在稳定基础上的锦上添花可以慢慢打磨。
