线上一个拉流程序又“冻”住了。现象很典型日志停在一个时间点进程还活着CPU几乎为零gdb挂上去一看主线程整整齐齐卡在av_read_frame里。这个函数我在不同项目里遇到过至少五六次每一次的根因都不太一样有的隔着十万八千里。团队里新来的同学接手这类问题第一反应就是“把超时调大”结果改了也没用反而把问题拖得更隐蔽。今天把这套排查思路完整写一遍先讲清楚av_read_frame为什么会阻塞再给一套能落到实际工程里的定位方法和解决方案覆盖网络流超时、中断回调失效、探测阶段卡顿这些最常见的坑。无论你做直播、播放器、安防视频接入还是嵌入式摄像头采集只要在用FFmpeg的demux接口这篇文章都值得存一份。1. 为什么av_read_frame会卡住先搞清楚这个函数的底层行为1.1 它本质上是一个同步拉取数据的函数av_read_frame是FFmpeg解复用层的核心读包函数。它的职责是从输入源读取数据解析成一个个AVPacket返回给调用者。注意“读取”和“解析”是同步的也就是说你调用它它就得从底下把数据拿回来拿不到就一直在那里等。内部调用链大致是这样av_read_frame - read_frame_internal - ff_read_packet - s-iformat-read_packet - avio_read - retry_transfer_wrapper - read/recv/recvfrom越往后越接近系统调用。retry_transfer_wrapper这一层尤其关键它是一个循环不断尝试读写直到拿到数据或确认出错。对网络流来说这个循环里最常见的状态就是“内核没有数据可读”于是read/recvfrom一直阻塞。这里有个很形象的类比av_read_frame像你拿杯子在水龙头下接水水龙头网络流那边没水你就一直举着杯子站着。文件流通常不会有这个问题因为文件读到尾部会立刻告诉你EOF但网络流不一样它没有“句号”只有“下一段数据什么时候到”。所以本地文件场景下av_read_frame几乎不会因为“没数据”而长时间卡住除非是磁盘IO挂起或者读的是FIFO、设备节点这类特殊文件。1.2 阻塞和慢读是两个世界里的问题很多人把所有av_read_frame耗时长的问题都叫“阻塞”但这其实会把定位方向带偏。我习惯把它们分成两类慢读函数最后还是返回了只是耗时很长。比如一个packet读了1秒或者10秒。这种通常是网络带宽不足、服务器下发慢、底层缓冲区太小。阻塞函数长时间不返回从数百毫秒到几分钟甚至永不返回。这种通常和超时失效、连接半开、探测阶段卡住、或别的线程持锁有关。排查时我有一个习惯先围绕av_read_frame加一圈带毫秒时间戳的日志连续打几百次把耗时分布拉出来看。如果99%的调用都在1毫秒内返回只有某几次突然卡了10秒那大概率是网络抖动加TCP重传如果每次都精确卡在同一个时间长度比如整整5秒、30秒那基本可以肯定是某个超时参数在起作用只是你没有把它设对。这类分布数据在定位时比堆栈还管用。拿一次堆栈只能看到一个瞬间拿几百次耗时记录才能看到规律。所以遇到卡顿先别急着改代码先把“证据链”拉出来。1.3 卡在av_read_frame不一定是它自己的错播放链路里av_read_frame通常是解复用线程demux thread的循环主体。一个典型的播放器会拆成多个线程demux线程负责读包video线程负责解码渲染audio线程负责解码播放。demux线程卡住下游会因为没有新数据而逐渐耗尽缓冲画面先冻住然后音频也跟着断。但如果你的程序把av_read_frame放在了和UI、业务逻辑同一个线程那问题就升级了不仅仅画面卡整个程序界面都失去响应看起来就像“死机”。这类情况我建议先不纠结av_read_frame本身而是确认调用线程模型对不对。线程模型错了后面所有优化都是白搭。还有一种“伪卡死”堆栈显示卡在av_read_frame但实际是整个进程被某个全局锁卡住其他线程也全部堵在那里。遇到这种只看主线程堆栈会误判必须thread apply all bt把全部线程的堆栈拉出来一起看。我就遇到过类似情况实际是系统里某个不相关的初始化服务比如有些人项目里碰到的dbus初始化失败在拖住进程和FFmpeg毫无关系。先怀疑锁再看IO这是排查卡死问题的通用顺序。2. 从一次真实的卡死现场看完整定位链路2.1 第一步gdb堆栈瞬间定位“卡点”拿到卡死现场第一件事是挂gdbgdb -p pid (gdb) thread apply all bt如果看到类似这样的堆栈#0 0x00007f... in recvfromplt () #1 ... in ff_network_wait_fd_timeout #2 ... in retry_transfer_wrapper #3 ... in ff_network_recvfrom #4 ... in tcp_read #5 ... in avio_read #6 ... in ff_read_packet #7 ... in av_read_frame基本能确认程序卡在TCP socket的recvfrom上等待网络数据。这里提个细节ff_network_wait_fd_timeout这个名字说明FFmpeg已经进入了带超时的读等待逻辑但超时可能设得很大或者某个协议路径绕过了超时检查。如果堆栈显示卡在read()而不是recvfrom就要看fd关联的是文件、管道还是设备节点。用lsof -p pid看一眼fd会有意外收获——我见过卡在FIFO上的也见过卡在/dev/设备节点上的处理方式完全不同。2.2 第二步strace确认系统调用层面的状态gdb定位到函数级别之后用strace看系统调用的实时状态strace -p pid -t -T实测中常见的输出有两种一直停在recvfrom(3, ..., 60, 0)没有任何返回socket是阻塞模式内核在等对端数据。这种场景下即使你的FFmpeg代码里设了中断回调回调也无法执行因为用户态根本轮不到。recvfrom每隔几秒返回一次EAGAIN但av_read_frame依然长时间不返回说明有某种循环让它“反复尝试”可能是应用层重试逻辑也可能是RTCP反馈机制。看到第一种输出修复方向就很明确给socket设置接收超时或使用非阻塞模式让底层IO能够“快速失败”。看到第二种输出则要去检查RTSP/UDP的会话逻辑或者上层自己写的重试循环。辅助命令里ss -tp也很有用看对应TCP连接状态。如果连接处于ESTABLISHED但持续收不到数据可能是对端半开如果连接已经不在了说明TCP断开但应用层没感知到这时候光调TCP参数不够还要考虑应用层心跳。2.3 第三步自定义AVIO回调“钉死”数据来源如果你的输入不是标准文件或网络URL而是通过自定义AVIOContext读取比如读数据库、读云端对象存储、甚至从消息队列消费那上面所有网络层分析都不适用。这时候最有效的手段是在你自己的read回调里加日志static int read_cb(void *opaque, uint8_t *buf, int buf_size) { uint64_t t0 av_gettime_relative(); int n do_read_from_backend(opaque, buf, buf_size); // 自定义读取 uint64_t t1 av_gettime_relative(); av_log(NULL, AV_LOG_INFO, read_cb n%d cost% PRIu64 us\n, n, t1 - t0); return n; }我之前一个项目数据源是对象存储直读线上偶发卡顿日志显示av_read_frame调用耗时高达20秒。如果不是在read回调里打了时间戳谁都不会想到问题出在后端存储的一次低频GC停顿上——FFmpeg只是忠实地等待你的回调返回。这类问题的根源不在FFmpeg但表现在av_read_frame定位时要敢于把怀疑范围扩大。另外一个技巧日志不要只打一次要在“开始读”“读到部分数据”“最终返回”三个节点都打时间戳这样能看出是一次性读不到还是读了一半又等下一半。我见过一个案例回调每次都能读到前半段数据但在读后半段时后端超时导致每一次av_read_frame都稳定卡1.5秒从外部时间戳完全看不出来只有回调内部的三段日志才揭示了真相。3. 最常见的坑网络流超时设了但根本没生效3.1 timeout、stimeout、rw_timeout到底有什么区别这是配置av_read_frame网络行为时最混乱的一环。三个选项看起来都是超时作用位置完全不同我直接给一张表选项生效层级适用协议单位timeoutAVFormatContext的协议层控制协议交互HTTP、TCP部分场景微秒stimeoutRTSP demuxer专用控制底层socketRTSP over TCP/UDP微秒rw_timeoutAVIOContext读写层兜底IO读写HTTP、TCP等通用IO微秒一句话总结timeout管“协议交互”的超时stimeout专管RTSP的socketrw_timeout是兜底的读写超时。实际工程里我建议三者都设成同一个值。比如目标超时5秒就统一传5000000。这里必须强调单位。rw_timeout和timeout的单位都是微秒不是毫秒。我见过不下三次的bug开发者把5000当成5秒传进去实际只是5毫秒结果网络稍一抖动就误判超时程序疯狂重连。5毫秒和5秒差了整整1000倍这个细节能在线上坑掉一整个晚上。3.2 设置位置必须在avformat_open_input之前这三个选项通过AVDictionary传给avformat_open_input连接建立之后你再设置是无效的。正确姿势AVDictionary* opts NULL; av_dict_set(opts, stimeout, 5000000, 0); // RTSP av_dict_set(opts, rw_timeout, 5000000, 0); // 通用读写 av_dict_set(opts, timeout, 5000000, 0); // 协议层 int ret avformat_open_input(fmt_ctx, url, NULL, opts); av_dict_free(opts); if (ret 0) { // 打开失败处理 }有人会问我直接在命令行里用ffplay就能正常退出为什么代码里就不行因为命令行你把-stimeout 5000000 -rw_timeout 5000000传进去了代码里忘了传。这种事情最容易发生在从demo改代码的过程中——demo用文件名就能跑换成网络URL后没有同步补上超时选项。还有一点要注意avformat_open_input成功之后fmt_ctx内部可能已经创建了多个AVIOContext比如RTSP的控制连接和数据连接这些连接的超时参数在打开那一刻就定了。所以不要指望在open之后通过av_opt_set动态修改能全部生效最稳妥的做法就是open之前全部塞进opts。3.3 TCP和UDP在超时行为上的巨大差异同样是RTSP底层走TCP和走UDPav_read_frame的等待行为差别很大。RTSP over TCPSYN、重传、接收都由内核TCP协议栈处理对端断开后重传超时可能很长默认十几秒甚至更久。设置SO_RCVTIMEO可以限制接收等待但connect阶段的阻塞光靠rw_timeout不一定能解决需要配合非阻塞connect或者协议层的timeout参数。RTSP over UDP视频数据走RTP/UDPUDP没有重传对端断流时socket上就是“没有数据可读”如果你不设置接收超时av_read_frame会永久等下去。UDP流还涉及RTCP包如果RTCP持续到达但RTP不到了FFmpeg可能认为连接还活着因为RTCP被当作“心跳”。这类问题光靠socket超时不够还要结合RTP序号连续性做应用层判断。考虑到安防设备普遍用RTSP over TCP我建议默认场景直接设stimeout和rw_timeout。如果为了低延迟改成UDP就必须额外做RTP超时检测否则“画面停在最后一帧、日志毫无报错”会成为你线上最头疼的问题。我见过一些项目摄像头端断了网线客户端要等一两分钟才发现异常就是因为UDPRTCP“假活”这个组合在作祟。4. 最隐蔽的坑中断回调在底层阻塞面前等于没设4.1 AVIOInterruptCB的正确打开方式除了超时FFmpeg还提供了中断回调机制用于主动打断长时间等待。基本用法是给AVFormatContext的interrupt_callback赋值static int interrupt_cb(void *opaque) { PlayerCtx *ctx (PlayerCtx*)opaque; return atomic_load(ctx-quit_flag) ? 1 : 0; } PlayerCtx ctx {0}; ctx.fmt_ctx-interrupt_callback.callback interrupt_cb; ctx.fmt_ctx-interrupt_callback.opaque ctx;在打开输入时FFmpeg会把这个回调复制到底层AVIOContext后续avio_read在等待数据时一旦IO返回EAGAIN或EINTR就会调用回调。回调返回1读操作立即以AVERROR_EXIT结束av_read_frame也就回来了。这个机制在“用户点退出”的场景里非常实用不用等超时立刻打断。我在播放器项目里就是靠它实现“点击停止窗口立即关闭”用户体验好很多。4.2 为什么我会说它在底层阻塞面前等于没设这里有个关键机制很多人没搞明白中断回调是在retry_transfer_wrapper的循环里被调用的。这个循环能跑的前提是底层IO会“按时返回”。如果socket是纯阻塞的recvfrom会一直挂在系统调用里用户态代码根本没有机会执行回调自然也就不会被调用。也就是说中断回调不是用来兜底“底层阻塞”的它只能兜底“底层可以快速失败”的情况。想让中断回调真正起作用必须先保证底层socket不是纯阻塞的。FFmpeg的TCP/UDP协议实现在设置了超时选项时会自动切换为非阻塞/设置超时但如果你完全没有设置任何超时参数部分场景下它会以阻塞方式打开于是回调形同虚设。这里关系应该是底层IO快速返回EAGAIN - FFmpeg检查中断回调 - 回调返回1则立即退出回调返回0则继续等待所以超时参数和中断回调不是二选一而是协作关系。只配中断回调、不配超时是新手最常见的误区只配超时、不配中断回调则会导致用户主动退出时最多要等一个超时周期。4.3 回调里切忌做重活中断回调虽然看起来像普通函数但它运行在FFmpeg内部IO循环里必须遵守两条铁律不能阻塞不能做耗时的互斥锁、网络请求、磁盘IO不能调用任何FFmpeg的API防止重入和状态错乱。我在上个项目里就踩过坑回调里写了一个printf用于调试结果在极高日志量下printf本身的fd锁和IO拖慢了整个读取循环反而把延迟放大。后来改成原子变量内存记录只在需要时dump立刻恢复正常。另一个经验回调里判断退出标志时用C11的atomic类型或者volatile都可以但要保证跨线程可见。不要用普通int裸变量否则可能在编译器优化下不生效。C代码里用std::atomicbool就够。还要注意回调返回1之后avformat_close_input还是要正常调用的否则资源泄漏。5. 探测阶段也会阻塞avformat_open_input不是你想的那样5.1 probesize与analyzeduration两个参数要会调很多人的认知里avformat_open_input只是“建立连接”但实际上它内部还有一个探测过程读一段数据来判断封装格式。这个探测阶段一样会阻塞在IO上。之后avformat_find_stream_info还会进一步分析流信息也可能长时间等待。默认情况下probesize是5000000字节约5MBanalyzeduration默认0表示不过限。这带来两个问题一是刚打开一个实时流时如果服务器不按预期吐数据探测可能长时间等不到足够数据二是对实时流来说5MB的探测数据可能对应几秒甚至几十秒的珍贵画面全被浪费在探测上了。实际工程里我建议这两项都主动设置fmt_ctx-probesize 500000; // 500KB够识别大部分格式了 fmt_ctx-analyzeduration 3000000; // 3秒分析上限单位微秒 avformat_find_stream_info(fmt_ctx, NULL);注意analyzeduration的单位是微秒和AV_TIME_BASE一致。probesize设置太小时某些封装格式识别不出来会表现为avformat_find_stream_info失败或流信息不全。所以不要为了快而设到几KB一般256KB到1MB之间是安全区间。5.2 RTSP/RTMP连接握手阶段的另类卡顿RTSP打开过程中有OPTIONS、DESCRIBE、SETUP等多次请求RTMP也有自己的握手流程。这些协议层的等待不一定都走通用avio的rw_timeout路径如果服务器在这几个阶段不回包等待时间可能主要受底层socket影响。所以你看到的现象可能是avformat_open_input卡住几分钟最后超时返回或者干脆一直卡在那里。排查这类问题用ffprobe加debug日志是最直接的ffprobe -v debug -rtsp_transport tcp rtsp://...日志会明确显示它卡在哪个阶段是在等待DESCRIBE响应还是SETUP之后等RTP包。看到具体阶段再决定是改服务器还是改客户端参数。之前有个项目摄像头固件版本有bugDESCRIBE响应要等40秒才返回客户端看起来就是avformat_open_input卡死。用ffprobe一看就明白了然后跟设备厂商提工单几分钟就定位清楚。5.3 自定义AVIO里的“另一类阻塞”最容易被漏掉当你给AVFormatContext指定了自定义AVIOContext时FFmpeg的格式探测也会通过你的回调来读数据所以探测阶段是否卡住完全取决于你的read回调快不快。有些开发者设计的read回调内部是同步等待数据结果程序启动阶段就卡住了运行很久才会发现。这里有一个很实用的技巧在自定义read回调里维护一个“最近读取时间戳”。如果格式探测期间read回调超过某阈值不执行就认为数据源挂掉了立即触发整体退出。把这个机制放在回调内部比在外面包超时的思路更可靠因为外面无法干涉内核态的等待但你自己的回调完全可控。顺带提一句自定义AVIOContext的seek回调同样容易被忽略。如果你的数据源支持随机访问但seek回调里执行了同步网络请求seek同样会卡。很多格式解析在探测阶段会频繁seekseek一旦阻塞av_read_frame的表现和读阻塞一模一样。所以在设计自定义AVIO时read和seek两个回调都要实现超时保护。6. 一套可以复用的工程方案超时、心跳与重连6.1 线程模型先理顺再谈配置不管你的业务是播放器还是安防接入我都建议遵循一个模型专职demux线程 有界packet队列 监控线程。demux线程的职责只有一个循环调用av_read_frame把返回的packet放入队列。它不做解码、不做渲染、不做重连判断以外的逻辑。主线程或业务线程通过原子变量控制退出标志通过中断回调让demux线程及时从阻塞中苏醒。队列大小要有限制否则网络正常时demux线程读得太快内存被packet占满。当队列满时demux线程要停下来等消费者这会造成“背压”是正常的不是bug。要注意的是不能因为背压就把demux线程做成了“有数据才读”因为实时流需要持续读取否则服务器那边会丢帧。6.2 代码骨架把超时和中断回调配合起来下面是我在实际项目里使用的简化骨架。核心思路是底层超时保证av_read_frame最多等N秒中断回调保证用户退出时能立即打断上层再用一个“读包deadline”判断是否需要重连。typedef struct { AVFormatContext *fmt_ctx; atomic_int quit_flag; atomic_int need_reconnect; int64_t last_recv; } PlayerCtx; static int interrupt_cb(void *opaque) { PlayerCtx *ctx (PlayerCtx*)opaque; return atomic_load(ctx-quit_flag) ? 1 : 0; } static int open_stream(PlayerCtx *ctx, const char *url) { AVDictionary *opts NULL; av_dict_set(opts, stimeout, 5000000, 0); av_dict_set(opts, rw_timeout, 5000000, 0); av_dict_set(opts, timeout, 5000000, 0); ctx-fmt_ctx avformat_alloc_context(); ctx-fmt_ctx-interrupt_callback.callback interrupt_cb; ctx-fmt_ctx-interrupt_callback.opaque ctx; int ret avformat_open_input(ctx-fmt_ctx, url, NULL, opts); av_dict_free(opts); if (ret 0) return ret; ctx-fmt_ctx-probesize 500000; ctx-fmt_ctx-analyzeduration 3000000; ret avformat_find_stream_info(ctx-fmt_ctx, NULL); return ret; } static void *demux_thread(void *arg) { PlayerCtx *ctx (PlayerCtx*)arg; int64_t last_recv av_gettime_relative(); while (!atomic_load(ctx-quit_flag)) { AVPacket *pkt av_packet_alloc(); int ret av_read_frame(ctx-fmt_ctx, pkt); if (ret AVERROR_EXIT || ret AVERROR_EOF) { av_packet_free(pkt); if (ret AVERROR_EXIT) break; atomic_store(ctx-need_reconnect, 1); break; } if (ret 0) { av_packet_free(pkt); atomic_store(ctx-need_reconnect, 1); break; } last_recv av_gettime_relative(); // 将pkt交给有界队列... 此处省略 // 心跳监控超过10秒没有读到数据主动重连 if (last_recv - ctx-last_recv 10 * AV_TIME_BASE) { atomic_store(ctx-need_reconnect, 1); break; } } if (atomic_load(ctx-need_reconnect)) { // 重连处理先close再open_stream } return NULL; }这段代码不是完整的生产实现但框架是对的。注意几点第一av_read_frame的返回值必须逐个处理AVERROR_EXIT、AVERROR_EOF、普通错误、正常拿到packet四类情况分支要清晰第二重连前必须调用avformat_close_input销毁旧context不能复用之前的状态第三如果底层超时设置有效av_read_frame最坏会阻塞5秒就返回加上上层心跳判断整体延迟可预期。6.3 这些细节不处理方案等于白做最后列几个我在真实项目里反复踩过的坑供大家自查重连不要“拼命重试”。摄像头和流媒体服务器对频繁连接是有限制的TCP连接释放也需要时间。建议指数退避第一次隔1秒第二次隔2秒最多隔10到15秒。不然会出现“客户端疯狂重连服务器还没释放旧session导致永远连不上”的循环。多路流共用一个全局退出标志是危险设计。某一路流退出会中断所有流的av_read_frame导致其他路一起重连。每一路context都要有自己的opaque和退出标志。avformat_close_input之后如果还持有从context里拿到的AVStream指针这些指针立即失效。不要在重连时继续用旧指针。如果你在Windows上用MinGW编译的FFmpeg网络超时行为的底层实现和Linux有细微差异。比如Windows的socket错误码和ECONNRESET处理不完全一致。线上一定要分平台验证超时参数的实际效果。设置了rw_timeout之后某些情况下虽然av_read_frame返回了但返回的是EAGAIN而非AVERROR_EOF。EAGAIN表示“暂时没有数据”不是错误要区分处理。对实时流来说连续多次EAGAIN才是重连的信号偶发一次EAGAIN可能只是网络抖动。最后说一点整体感受。av_read_frame阻塞这个问题绝大多数情况下不是FFmpeg本身有bug而是超时、中断、线程模型之间没有配合好。先把底层socket超时打开再挂上中断回调再保证调用线程独立最后用日志验证耗时分布——顺序不能反。定位之前不要急着改参数先抓堆栈、看系统调用、拉耗时数据让现场说话。按照这个顺序走90%的“卡死”问题都能在半小时内定位到根因。 
长河君 · 2026/10/4 6:55:56 · 阅读 1.2k FFmpeg av_read_frame卡死排查：超时设置、中断回调与线程模型的工程实践
线上一个拉流程序又“冻”住了。现象很典型日志停在一个时间点进程还活着CPU几乎为零gdb挂上去一看主线程整整齐齐卡在av_read_frame里。这个函数我在不同项目里遇到过至少五六次每一次的根因都不太一样有的隔着十万八千里。团队里新来的同学接手这类问题第一反应就是“把超时调大”结果改了也没用反而把问题拖得更隐蔽。今天把这套排查思路完整写一遍先讲清楚av_read_frame为什么会阻塞再给一套能落到实际工程里的定位方法和解决方案覆盖网络流超时、中断回调失效、探测阶段卡顿这些最常见的坑。无论你做直播、播放器、安防视频接入还是嵌入式摄像头采集只要在用FFmpeg的demux接口这篇文章都值得存一份。1. 为什么av_read_frame会卡住先搞清楚这个函数的底层行为1.1 它本质上是一个同步拉取数据的函数av_read_frame是FFmpeg解复用层的核心读包函数。它的职责是从输入源读取数据解析成一个个AVPacket返回给调用者。注意“读取”和“解析”是同步的也就是说你调用它它就得从底下把数据拿回来拿不到就一直在那里等。内部调用链大致是这样av_read_frame - read_frame_internal - ff_read_packet - s-iformat-read_packet - avio_read - retry_transfer_wrapper - read/recv/recvfrom越往后越接近系统调用。retry_transfer_wrapper这一层尤其关键它是一个循环不断尝试读写直到拿到数据或确认出错。对网络流来说这个循环里最常见的状态就是“内核没有数据可读”于是read/recvfrom一直阻塞。这里有个很形象的类比av_read_frame像你拿杯子在水龙头下接水水龙头网络流那边没水你就一直举着杯子站着。文件流通常不会有这个问题因为文件读到尾部会立刻告诉你EOF但网络流不一样它没有“句号”只有“下一段数据什么时候到”。所以本地文件场景下av_read_frame几乎不会因为“没数据”而长时间卡住除非是磁盘IO挂起或者读的是FIFO、设备节点这类特殊文件。1.2 阻塞和慢读是两个世界里的问题很多人把所有av_read_frame耗时长的问题都叫“阻塞”但这其实会把定位方向带偏。我习惯把它们分成两类慢读函数最后还是返回了只是耗时很长。比如一个packet读了1秒或者10秒。这种通常是网络带宽不足、服务器下发慢、底层缓冲区太小。阻塞函数长时间不返回从数百毫秒到几分钟甚至永不返回。这种通常和超时失效、连接半开、探测阶段卡住、或别的线程持锁有关。排查时我有一个习惯先围绕av_read_frame加一圈带毫秒时间戳的日志连续打几百次把耗时分布拉出来看。如果99%的调用都在1毫秒内返回只有某几次突然卡了10秒那大概率是网络抖动加TCP重传如果每次都精确卡在同一个时间长度比如整整5秒、30秒那基本可以肯定是某个超时参数在起作用只是你没有把它设对。这类分布数据在定位时比堆栈还管用。拿一次堆栈只能看到一个瞬间拿几百次耗时记录才能看到规律。所以遇到卡顿先别急着改代码先把“证据链”拉出来。1.3 卡在av_read_frame不一定是它自己的错播放链路里av_read_frame通常是解复用线程demux thread的循环主体。一个典型的播放器会拆成多个线程demux线程负责读包video线程负责解码渲染audio线程负责解码播放。demux线程卡住下游会因为没有新数据而逐渐耗尽缓冲画面先冻住然后音频也跟着断。但如果你的程序把av_read_frame放在了和UI、业务逻辑同一个线程那问题就升级了不仅仅画面卡整个程序界面都失去响应看起来就像“死机”。这类情况我建议先不纠结av_read_frame本身而是确认调用线程模型对不对。线程模型错了后面所有优化都是白搭。还有一种“伪卡死”堆栈显示卡在av_read_frame但实际是整个进程被某个全局锁卡住其他线程也全部堵在那里。遇到这种只看主线程堆栈会误判必须thread apply all bt把全部线程的堆栈拉出来一起看。我就遇到过类似情况实际是系统里某个不相关的初始化服务比如有些人项目里碰到的dbus初始化失败在拖住进程和FFmpeg毫无关系。先怀疑锁再看IO这是排查卡死问题的通用顺序。2. 从一次真实的卡死现场看完整定位链路2.1 第一步gdb堆栈瞬间定位“卡点”拿到卡死现场第一件事是挂gdbgdb -p pid (gdb) thread apply all bt如果看到类似这样的堆栈#0 0x00007f... in recvfromplt () #1 ... in ff_network_wait_fd_timeout #2 ... in retry_transfer_wrapper #3 ... in ff_network_recvfrom #4 ... in tcp_read #5 ... in avio_read #6 ... in ff_read_packet #7 ... in av_read_frame基本能确认程序卡在TCP socket的recvfrom上等待网络数据。这里提个细节ff_network_wait_fd_timeout这个名字说明FFmpeg已经进入了带超时的读等待逻辑但超时可能设得很大或者某个协议路径绕过了超时检查。如果堆栈显示卡在read()而不是recvfrom就要看fd关联的是文件、管道还是设备节点。用lsof -p pid看一眼fd会有意外收获——我见过卡在FIFO上的也见过卡在/dev/设备节点上的处理方式完全不同。2.2 第二步strace确认系统调用层面的状态gdb定位到函数级别之后用strace看系统调用的实时状态strace -p pid -t -T实测中常见的输出有两种一直停在recvfrom(3, ..., 60, 0)没有任何返回socket是阻塞模式内核在等对端数据。这种场景下即使你的FFmpeg代码里设了中断回调回调也无法执行因为用户态根本轮不到。recvfrom每隔几秒返回一次EAGAIN但av_read_frame依然长时间不返回说明有某种循环让它“反复尝试”可能是应用层重试逻辑也可能是RTCP反馈机制。看到第一种输出修复方向就很明确给socket设置接收超时或使用非阻塞模式让底层IO能够“快速失败”。看到第二种输出则要去检查RTSP/UDP的会话逻辑或者上层自己写的重试循环。辅助命令里ss -tp也很有用看对应TCP连接状态。如果连接处于ESTABLISHED但持续收不到数据可能是对端半开如果连接已经不在了说明TCP断开但应用层没感知到这时候光调TCP参数不够还要考虑应用层心跳。2.3 第三步自定义AVIO回调“钉死”数据来源如果你的输入不是标准文件或网络URL而是通过自定义AVIOContext读取比如读数据库、读云端对象存储、甚至从消息队列消费那上面所有网络层分析都不适用。这时候最有效的手段是在你自己的read回调里加日志static int read_cb(void *opaque, uint8_t *buf, int buf_size) { uint64_t t0 av_gettime_relative(); int n do_read_from_backend(opaque, buf, buf_size); // 自定义读取 uint64_t t1 av_gettime_relative(); av_log(NULL, AV_LOG_INFO, read_cb n%d cost% PRIu64 us\n, n, t1 - t0); return n; }我之前一个项目数据源是对象存储直读线上偶发卡顿日志显示av_read_frame调用耗时高达20秒。如果不是在read回调里打了时间戳谁都不会想到问题出在后端存储的一次低频GC停顿上——FFmpeg只是忠实地等待你的回调返回。这类问题的根源不在FFmpeg但表现在av_read_frame定位时要敢于把怀疑范围扩大。另外一个技巧日志不要只打一次要在“开始读”“读到部分数据”“最终返回”三个节点都打时间戳这样能看出是一次性读不到还是读了一半又等下一半。我见过一个案例回调每次都能读到前半段数据但在读后半段时后端超时导致每一次av_read_frame都稳定卡1.5秒从外部时间戳完全看不出来只有回调内部的三段日志才揭示了真相。3. 最常见的坑网络流超时设了但根本没生效3.1 timeout、stimeout、rw_timeout到底有什么区别这是配置av_read_frame网络行为时最混乱的一环。三个选项看起来都是超时作用位置完全不同我直接给一张表选项生效层级适用协议单位timeoutAVFormatContext的协议层控制协议交互HTTP、TCP部分场景微秒stimeoutRTSP demuxer专用控制底层socketRTSP over TCP/UDP微秒rw_timeoutAVIOContext读写层兜底IO读写HTTP、TCP等通用IO微秒一句话总结timeout管“协议交互”的超时stimeout专管RTSP的socketrw_timeout是兜底的读写超时。实际工程里我建议三者都设成同一个值。比如目标超时5秒就统一传5000000。这里必须强调单位。rw_timeout和timeout的单位都是微秒不是毫秒。我见过不下三次的bug开发者把5000当成5秒传进去实际只是5毫秒结果网络稍一抖动就误判超时程序疯狂重连。5毫秒和5秒差了整整1000倍这个细节能在线上坑掉一整个晚上。3.2 设置位置必须在avformat_open_input之前这三个选项通过AVDictionary传给avformat_open_input连接建立之后你再设置是无效的。正确姿势AVDictionary* opts NULL; av_dict_set(opts, stimeout, 5000000, 0); // RTSP av_dict_set(opts, rw_timeout, 5000000, 0); // 通用读写 av_dict_set(opts, timeout, 5000000, 0); // 协议层 int ret avformat_open_input(fmt_ctx, url, NULL, opts); av_dict_free(opts); if (ret 0) { // 打开失败处理 }有人会问我直接在命令行里用ffplay就能正常退出为什么代码里就不行因为命令行你把-stimeout 5000000 -rw_timeout 5000000传进去了代码里忘了传。这种事情最容易发生在从demo改代码的过程中——demo用文件名就能跑换成网络URL后没有同步补上超时选项。还有一点要注意avformat_open_input成功之后fmt_ctx内部可能已经创建了多个AVIOContext比如RTSP的控制连接和数据连接这些连接的超时参数在打开那一刻就定了。所以不要指望在open之后通过av_opt_set动态修改能全部生效最稳妥的做法就是open之前全部塞进opts。3.3 TCP和UDP在超时行为上的巨大差异同样是RTSP底层走TCP和走UDPav_read_frame的等待行为差别很大。RTSP over TCPSYN、重传、接收都由内核TCP协议栈处理对端断开后重传超时可能很长默认十几秒甚至更久。设置SO_RCVTIMEO可以限制接收等待但connect阶段的阻塞光靠rw_timeout不一定能解决需要配合非阻塞connect或者协议层的timeout参数。RTSP over UDP视频数据走RTP/UDPUDP没有重传对端断流时socket上就是“没有数据可读”如果你不设置接收超时av_read_frame会永久等下去。UDP流还涉及RTCP包如果RTCP持续到达但RTP不到了FFmpeg可能认为连接还活着因为RTCP被当作“心跳”。这类问题光靠socket超时不够还要结合RTP序号连续性做应用层判断。考虑到安防设备普遍用RTSP over TCP我建议默认场景直接设stimeout和rw_timeout。如果为了低延迟改成UDP就必须额外做RTP超时检测否则“画面停在最后一帧、日志毫无报错”会成为你线上最头疼的问题。我见过一些项目摄像头端断了网线客户端要等一两分钟才发现异常就是因为UDPRTCP“假活”这个组合在作祟。4. 最隐蔽的坑中断回调在底层阻塞面前等于没设4.1 AVIOInterruptCB的正确打开方式除了超时FFmpeg还提供了中断回调机制用于主动打断长时间等待。基本用法是给AVFormatContext的interrupt_callback赋值static int interrupt_cb(void *opaque) { PlayerCtx *ctx (PlayerCtx*)opaque; return atomic_load(ctx-quit_flag) ? 1 : 0; } PlayerCtx ctx {0}; ctx.fmt_ctx-interrupt_callback.callback interrupt_cb; ctx.fmt_ctx-interrupt_callback.opaque ctx;在打开输入时FFmpeg会把这个回调复制到底层AVIOContext后续avio_read在等待数据时一旦IO返回EAGAIN或EINTR就会调用回调。回调返回1读操作立即以AVERROR_EXIT结束av_read_frame也就回来了。这个机制在“用户点退出”的场景里非常实用不用等超时立刻打断。我在播放器项目里就是靠它实现“点击停止窗口立即关闭”用户体验好很多。4.2 为什么我会说它在底层阻塞面前等于没设这里有个关键机制很多人没搞明白中断回调是在retry_transfer_wrapper的循环里被调用的。这个循环能跑的前提是底层IO会“按时返回”。如果socket是纯阻塞的recvfrom会一直挂在系统调用里用户态代码根本没有机会执行回调自然也就不会被调用。也就是说中断回调不是用来兜底“底层阻塞”的它只能兜底“底层可以快速失败”的情况。想让中断回调真正起作用必须先保证底层socket不是纯阻塞的。FFmpeg的TCP/UDP协议实现在设置了超时选项时会自动切换为非阻塞/设置超时但如果你完全没有设置任何超时参数部分场景下它会以阻塞方式打开于是回调形同虚设。这里关系应该是底层IO快速返回EAGAIN - FFmpeg检查中断回调 - 回调返回1则立即退出回调返回0则继续等待所以超时参数和中断回调不是二选一而是协作关系。只配中断回调、不配超时是新手最常见的误区只配超时、不配中断回调则会导致用户主动退出时最多要等一个超时周期。4.3 回调里切忌做重活中断回调虽然看起来像普通函数但它运行在FFmpeg内部IO循环里必须遵守两条铁律不能阻塞不能做耗时的互斥锁、网络请求、磁盘IO不能调用任何FFmpeg的API防止重入和状态错乱。我在上个项目里就踩过坑回调里写了一个printf用于调试结果在极高日志量下printf本身的fd锁和IO拖慢了整个读取循环反而把延迟放大。后来改成原子变量内存记录只在需要时dump立刻恢复正常。另一个经验回调里判断退出标志时用C11的atomic类型或者volatile都可以但要保证跨线程可见。不要用普通int裸变量否则可能在编译器优化下不生效。C代码里用std::atomicbool就够。还要注意回调返回1之后avformat_close_input还是要正常调用的否则资源泄漏。5. 探测阶段也会阻塞avformat_open_input不是你想的那样5.1 probesize与analyzeduration两个参数要会调很多人的认知里avformat_open_input只是“建立连接”但实际上它内部还有一个探测过程读一段数据来判断封装格式。这个探测阶段一样会阻塞在IO上。之后avformat_find_stream_info还会进一步分析流信息也可能长时间等待。默认情况下probesize是5000000字节约5MBanalyzeduration默认0表示不过限。这带来两个问题一是刚打开一个实时流时如果服务器不按预期吐数据探测可能长时间等不到足够数据二是对实时流来说5MB的探测数据可能对应几秒甚至几十秒的珍贵画面全被浪费在探测上了。实际工程里我建议这两项都主动设置fmt_ctx-probesize 500000; // 500KB够识别大部分格式了 fmt_ctx-analyzeduration 3000000; // 3秒分析上限单位微秒 avformat_find_stream_info(fmt_ctx, NULL);注意analyzeduration的单位是微秒和AV_TIME_BASE一致。probesize设置太小时某些封装格式识别不出来会表现为avformat_find_stream_info失败或流信息不全。所以不要为了快而设到几KB一般256KB到1MB之间是安全区间。5.2 RTSP/RTMP连接握手阶段的另类卡顿RTSP打开过程中有OPTIONS、DESCRIBE、SETUP等多次请求RTMP也有自己的握手流程。这些协议层的等待不一定都走通用avio的rw_timeout路径如果服务器在这几个阶段不回包等待时间可能主要受底层socket影响。所以你看到的现象可能是avformat_open_input卡住几分钟最后超时返回或者干脆一直卡在那里。排查这类问题用ffprobe加debug日志是最直接的ffprobe -v debug -rtsp_transport tcp rtsp://...日志会明确显示它卡在哪个阶段是在等待DESCRIBE响应还是SETUP之后等RTP包。看到具体阶段再决定是改服务器还是改客户端参数。之前有个项目摄像头固件版本有bugDESCRIBE响应要等40秒才返回客户端看起来就是avformat_open_input卡死。用ffprobe一看就明白了然后跟设备厂商提工单几分钟就定位清楚。5.3 自定义AVIO里的“另一类阻塞”最容易被漏掉当你给AVFormatContext指定了自定义AVIOContext时FFmpeg的格式探测也会通过你的回调来读数据所以探测阶段是否卡住完全取决于你的read回调快不快。有些开发者设计的read回调内部是同步等待数据结果程序启动阶段就卡住了运行很久才会发现。这里有一个很实用的技巧在自定义read回调里维护一个“最近读取时间戳”。如果格式探测期间read回调超过某阈值不执行就认为数据源挂掉了立即触发整体退出。把这个机制放在回调内部比在外面包超时的思路更可靠因为外面无法干涉内核态的等待但你自己的回调完全可控。顺带提一句自定义AVIOContext的seek回调同样容易被忽略。如果你的数据源支持随机访问但seek回调里执行了同步网络请求seek同样会卡。很多格式解析在探测阶段会频繁seekseek一旦阻塞av_read_frame的表现和读阻塞一模一样。所以在设计自定义AVIO时read和seek两个回调都要实现超时保护。6. 一套可以复用的工程方案超时、心跳与重连6.1 线程模型先理顺再谈配置不管你的业务是播放器还是安防接入我都建议遵循一个模型专职demux线程 有界packet队列 监控线程。demux线程的职责只有一个循环调用av_read_frame把返回的packet放入队列。它不做解码、不做渲染、不做重连判断以外的逻辑。主线程或业务线程通过原子变量控制退出标志通过中断回调让demux线程及时从阻塞中苏醒。队列大小要有限制否则网络正常时demux线程读得太快内存被packet占满。当队列满时demux线程要停下来等消费者这会造成“背压”是正常的不是bug。要注意的是不能因为背压就把demux线程做成了“有数据才读”因为实时流需要持续读取否则服务器那边会丢帧。6.2 代码骨架把超时和中断回调配合起来下面是我在实际项目里使用的简化骨架。核心思路是底层超时保证av_read_frame最多等N秒中断回调保证用户退出时能立即打断上层再用一个“读包deadline”判断是否需要重连。typedef struct { AVFormatContext *fmt_ctx; atomic_int quit_flag; atomic_int need_reconnect; int64_t last_recv; } PlayerCtx; static int interrupt_cb(void *opaque) { PlayerCtx *ctx (PlayerCtx*)opaque; return atomic_load(ctx-quit_flag) ? 1 : 0; } static int open_stream(PlayerCtx *ctx, const char *url) { AVDictionary *opts NULL; av_dict_set(opts, stimeout, 5000000, 0); av_dict_set(opts, rw_timeout, 5000000, 0); av_dict_set(opts, timeout, 5000000, 0); ctx-fmt_ctx avformat_alloc_context(); ctx-fmt_ctx-interrupt_callback.callback interrupt_cb; ctx-fmt_ctx-interrupt_callback.opaque ctx; int ret avformat_open_input(ctx-fmt_ctx, url, NULL, opts); av_dict_free(opts); if (ret 0) return ret; ctx-fmt_ctx-probesize 500000; ctx-fmt_ctx-analyzeduration 3000000; ret avformat_find_stream_info(ctx-fmt_ctx, NULL); return ret; } static void *demux_thread(void *arg) { PlayerCtx *ctx (PlayerCtx*)arg; int64_t last_recv av_gettime_relative(); while (!atomic_load(ctx-quit_flag)) { AVPacket *pkt av_packet_alloc(); int ret av_read_frame(ctx-fmt_ctx, pkt); if (ret AVERROR_EXIT || ret AVERROR_EOF) { av_packet_free(pkt); if (ret AVERROR_EXIT) break; atomic_store(ctx-need_reconnect, 1); break; } if (ret 0) { av_packet_free(pkt); atomic_store(ctx-need_reconnect, 1); break; } last_recv av_gettime_relative(); // 将pkt交给有界队列... 此处省略 // 心跳监控超过10秒没有读到数据主动重连 if (last_recv - ctx-last_recv 10 * AV_TIME_BASE) { atomic_store(ctx-need_reconnect, 1); break; } } if (atomic_load(ctx-need_reconnect)) { // 重连处理先close再open_stream } return NULL; }这段代码不是完整的生产实现但框架是对的。注意几点第一av_read_frame的返回值必须逐个处理AVERROR_EXIT、AVERROR_EOF、普通错误、正常拿到packet四类情况分支要清晰第二重连前必须调用avformat_close_input销毁旧context不能复用之前的状态第三如果底层超时设置有效av_read_frame最坏会阻塞5秒就返回加上上层心跳判断整体延迟可预期。6.3 这些细节不处理方案等于白做最后列几个我在真实项目里反复踩过的坑供大家自查重连不要“拼命重试”。摄像头和流媒体服务器对频繁连接是有限制的TCP连接释放也需要时间。建议指数退避第一次隔1秒第二次隔2秒最多隔10到15秒。不然会出现“客户端疯狂重连服务器还没释放旧session导致永远连不上”的循环。多路流共用一个全局退出标志是危险设计。某一路流退出会中断所有流的av_read_frame导致其他路一起重连。每一路context都要有自己的opaque和退出标志。avformat_close_input之后如果还持有从context里拿到的AVStream指针这些指针立即失效。不要在重连时继续用旧指针。如果你在Windows上用MinGW编译的FFmpeg网络超时行为的底层实现和Linux有细微差异。比如Windows的socket错误码和ECONNRESET处理不完全一致。线上一定要分平台验证超时参数的实际效果。设置了rw_timeout之后某些情况下虽然av_read_frame返回了但返回的是EAGAIN而非AVERROR_EOF。EAGAIN表示“暂时没有数据”不是错误要区分处理。对实时流来说连续多次EAGAIN才是重连的信号偶发一次EAGAIN可能只是网络抖动。最后说一点整体感受。av_read_frame阻塞这个问题绝大多数情况下不是FFmpeg本身有bug而是超时、中断、线程模型之间没有配合好。先把底层socket超时打开再挂上中断回调再保证调用线程独立最后用日志验证耗时分布——顺序不能反。定位之前不要急着改参数先抓堆栈、看系统调用、拉耗时数据让现场说话。按照这个顺序走90%的“卡死”问题都能在半小时内定位到根因。