如果你维护过一个播放器，或者做过流媒体转码服务，大概率对avformat_close_input()这个函数不陌生。它是 FFmpeg 中负责关闭解封装上下文的入口，和avformat_open_input()正好是一对。打开输入好说，真正容易出问题的其实是关闭：资源没释放干净、句柄泄漏、重复关闭导致崩溃，这些我都在实际项目里遇到过。这篇文章不打算贴完整源码，而是把avformat_close_input()的实现思路、释放顺序、参数设计的巧妙之处，以及真正用起来会踩的坑都过一遍。无论你是刚接触 FFmpeg 的初学者，还是已经在做播放器和流媒体服务的开发者，这都能帮你在“收尾”这个环节少折腾几晚。1. 为什么需要单独拆解这个关闭函数1.1 解封装生命周期的最后一环一个典型的 FFmpeg 解封装流程大概是这样的：先avformat_open_input()打开文件或网络流，接着avformat_find_stream_info()探测流信息，然后不断调用av_read_frame()读取 packet，等数据读完了，或者用户主动中止，最后用avformat_close_input()收尾。前面几个函数大家都会用，也都有很多文章在讲，但收尾这一步经常被一笔带过。很多刚入门的同学甚至会认为，程序退出的时候操作系统自然会回收内存，不关也没关系。对于ffmpeg命令行工具这种一次性进程来说，影响确实不大，进程退出后 fd 和内存都会被内核回收。但如果你写的是一个常驻服务，比如流媒体转码网关、录像服务、长时间运行的播放器，或者需要反复切换片源的应用，情况就完全不同了。每次切换片源都泄漏几个 fd、几块内存，跑个几万次之后，服务基本就废了。我见过一个转码服务跑了两周后 fd 数涨到四万多，最后连新的 socket 都开不了，排查问题的时候才发现关闭逻辑根本没写对。avformat_close_input()就是负责把这个生命周期彻底结束掉的函数。它不仅仅是“关一个文件”那么简单，它要处理解复用器自身的状态、协议层的 IO、内部缓冲区、流信息、元数据等一系列资源。把这个函数吃透，你才能保证你的应用在长时间运行时依然稳定。1.2 它和 avformat_free_context 的分工很多人会问：有了avformat_free_context()为什么还需要avformat_close_input()？直接释放上下文不就行了？这两个函数的定位完全不同。avformat_free_context()是通用的资源释放函数，它的职责是把AVFormatContext这个容器里面所有动态分配的东西清掉：streams数组、metadata字典、chapters、programs、内部辅助结构等等。它不关心你当前打开的是什么格式，也不关心 IO 层是怎么建立的。avformat_close_input()高一层的封装，它知道自己当前使用的是哪个解复用器，所以它可以在释放容器之前，先调用该解复用器注册的read_close回调，做一些格式相关的清理工作，比如清理 RTSP 会话、释放 MPEG-TS 的 PSI 解析状态等等。然后它再决定如何处理AVIOContext，最后才调用avformat_free_context()把整个上下文释放掉。换句话说，avformat_close_input()是“懂得上下文当前状态”的高级关闭入口，而avformat_free_context()是“只管拆容器”的底层清理函数。正常工程代码里应该只调用前者，直接调后者反而容易漏掉格式层和 IO 层的资源回收。2. 源码实现逐步拆解2.1 参数设计：为什么必须传二级指针先看函数签名：void avformat_close_input(AVFormatContext **ps);注意这里用的是二级指针。为什么要这么设计？因为关闭函数要做一件很关键的事情：把调用者手里的指针直接置空。函数内部拿到*ps之后，完成释放，最后执行*ps = NULL。这样一来，调用者手里的变量就不会再指向一块已经被释放的内存了。这个设计的好处是防呆。你想想，如果不置空，调用者不小心在 close 之后又把fmt_ctx传给别的函数，或者把它当成参数再调一次 close，后果就是访问野指针，程序直接崩溃，而且崩溃的位置可能离出错点很远，排查起来特别头痛。举个生活中的类比：你交出一把钥匙给管理员，管理员不仅把锁换掉，还把你通讯录里记录的那行地址擦掉，防止你下次照着旧地址又跑过去敲门。C 语言里面“释放后及时置空”是防御性编程的黄金法则，而 FFmpeg 的avformat_close_input()在 API 层面就把这个法则强制落实了。而且这个置空操作配合函数开头对参数的保护检查，还能实现一个很实用的特性：重复调用安全。if (!ps || !*ps) return;如果你连续两次调用avformat_close_input(&fmt_ctx);，第二次进来时*ps已经是 NULL 了，函数啥也不干直接返回。这在错误处理和退出路径非常多的大型项目里很实用，不需要每次调 close 之前都小心翼翼地去判断指针状态。2.2 核心释放顺序：先解复用器，再 IO 层，最后容器我参考的是 FFmpeg 4.x 和 5.x 之间的实现，主干逻辑可以简化成下面的示意代码：void avformat_close_input(AVFormatContext **ps) { AVFormatContext *s = *ps; AVIOContext *pb = s->pb; if (s->iformat) { if (s->iformat->read_close) s->iformat->read_close(s); if (s->iformat->read_header) av_packet_free(&s->internal->parse_pkt); } if (pb && !(s->flags & AVFMT_FLAG_CUSTOM_IO)) avio_close(pb); avformat_free_context(s); *ps = NULL; }注意，不同版本的实现细节会有差异，比如新版 FFmpeg 已经把 IO 层关闭逻辑收拢到了ff_format_io_close()里统一处理，但整体释放顺序和承担的责任是没有变的。我建议你以自己实际使用的源码版本为准来核对，但理解了上面这个主干，后续看哪个版本都能很快对上。整个释放顺序非常讲究，它遵循了一个原则：先释放“更具体、更依赖外部状态”的东西，再释放“更通用、更底层”的东西。第一步调用read_close是在给解复用器一个“临终回调”的机会。每种格式的私有解析状态都在这里清理。比如 RTSP 解复用器的read_close会清理 RTSP 会话相关的资源；MPEG-TS 解复用器会释放 PSI 表解析时分配的各类结构；Matroska 解复用器会释放读取 SeekHead 等结构时的临时缓存。这些状态藏在AVFormatContext->priv_data里，avformat_free_context()虽然也会释放priv_data，但它不知道该格式内部还有没有动态分配的子对象，必须靠read_close来做深度清理。第二步关闭AVIOContext。此时解复用器已经完成自身的清理，不再需要 IO 层来读写数据，所以可以安全关闭文件描述符和网络连接。注意代码里对AVFMT_FLAG_CUSTOM_IO的判断，这个后面单独展开讲，因为它直接影响自定义 IO 场景下的资源归属问题。第三步才调用avformat_free_context()释放容器本身。到了这里，流信息、元数据、章节信息这些纯粹的数据结构就都被统一回收了。最后把指针置空，一个完整的生命周期才算真正结束。2.3 read_close 回调的作用与常见实现上面代码里最容易被忽略的就是read_close回调。我见过不少同学在读 FFmpeg 源码时会跳过这个字段，觉得它只是在文件末尾做了个空操作。其实不是。对于很多简单的文件格式，比如 RAW PCM、BMP 图像，read_close确实可能是空的，因为它们的私有数据没有需要深度释放的东西，avformat_free_context()释放priv_data就够了。但对于复杂格式，这个回调是必须的。以 MPEG-TS 为例，解复用器在解析 PAT、PMT、SDT 等 PSI 表时，会在MpegTSContext里面创建很多链表节点和缓存结构。如果只靠avformat_free_context()去释放整体内存，这些内部动态申请的结构就会泄漏。所以mpegts_close()必须自己遍历释放所有 PSI 相关的结构。再比如 RTSP 解复用器，read_close要做的事更多：它需要关闭底层 socket（如果用的是内置协议栈）、清理 RTSP 会话状态、释放收到的 SDP 解析结果。如果不调用这个回调，你关了一个 RTSP 流之后，那个 TCP 连接可能还悬在那，fd 数只会不断增加。所以，如果你准备自己封装一个 demuxer，或者需要分析某个格式的关闭行为，第一步就是去查它的read_close实现了什么。你才能真正理解一个格式在 close 时到底做了什么。3. 关闭过程中的隐藏细节与资源归属3.1 自定义 IO 场景下，谁负责关闭句柄这是工程中非常容易踩坑的一个点，值得单独拿出来讲。如果你用avformat_open_input()打开本地文件，FFmpeg 内部会替你自己创建并管理AVIOContext，底层的那个文件描述符也是 FFmpeg 打开的。这种情况下，avformat_close_input()调用avio_close()来关闭 IO 没有任何问题，职责清晰。但如果你是自己创建一个AVIOContext，通过AVFMT_FLAG_CUSTOM_IO标志把它塞给AVFormatContext，情况就不一样了。此时底层的数据源是你自己管理的，比如你可能用的是自己的内存缓冲、自己封装的一套私有网络协议、甚至是某个硬件的 DMA 缓冲区，FFmpeg 根本没有权限也不应该去关闭它。所以新版 FFmpeg 的关闭逻辑中，对自定义 IO 场景做了专门处理。如果设置了AVFMT_FLAG_CUSTOM_IO，关闭输入时不会调用avio_close()去关闭你的 IO 层，只会把AVFormatContext内部对AVIOContext的引用清空。真正的关闭动作由调用者自己完成。我见过一个很典型的错误：有人在自己的网络模块里创建了 socket，然后把它包装成自定义AVIOContext传给 FFmpeg 解析数据。程序退出时先调avformat_close_input()，这本身没问题，但他又在 close 之后手动去close(sockfd)关闭同一个 socket。在非自定义 IO 的默认场景里，这就相当于把同一个 fd 关了两遍，轻则 EBADF 报错，重则在 fd 被系统复用之后误关了另一个无关的连接。排查起来非常隐蔽，因为崩溃往往发生在完全不相干的地方。正确做法是确认自己设置了AVFMT_FLAG_CUSTOM_IO，然后在 close input 之后由自己负责关闭底层资源。职责边界从一开始就要划清楚。3.2 元数据与内部状态的隐性释放很多人在关闭输入后还有一个坏习惯：继续访问之前从上下文里拿到的指针。比如avformat_open_input()之后，你通过fmt_ctx->streams[i]->codecpar拿到了编码参数指针，保存下来用。然后调用了avformat_close_input(&fmt_ctx)，按理说这个上下文已经没了，你手里那个codecpar指针也已经失效了，但因为你把它存在别的地方，随手还会继续用，结果就是 use-after-free，崩溃只在某些特定输入下出现，特别难复现。FFmpeg 在 close 时并不会特意提醒你这些内部指针已经失效，它只知道这些内存该还回去了。metadata字典、streams数组、attached_pic、programs、chapters等内部数据结构都会在avformat_free_context()里统一释放。所以一个血泪经验是：如果你需要在 close 之后继续使用流信息或者元数据，必须在 close 之前把数据拷贝出来。比如用avcodec_parameters_to_context()把编码参数复制到自己的解码器上下文里，或者用av_dict_get()逐个提取你需要的元数据字段。永远不要把AVFormatContext内部的指针带到它的生命周期之外。3.3 interrupt_callback 与阻塞 IO 的时序问题还有一个经常被忽视的隐藏细节：avformat_close_input()本身是可能阻塞的。如果输入是一个网络流，而且底层 IO 正处于阻塞读状态，比如 TCP 连接已经断了，但超时时间还没到，那么你在另一个线程里调用avformat_close_input()时候，它可能不会立即返回，而是卡在读操作上，直到超时或者中断条件满足。正确做法是给AVFormatContext设置一个AVIOInterruptCB中断回调。在回调里维护一个退出标志。当你要关闭输入时，先把这个标志置位，让底层阻塞的 IO 立刻返回错误，然后再调用avformat_close_input()，这样关闭动作才能很快完成。static int interrupt_cb(void *ctx) { return *(volatile int *)ctx; } // 主线程退出流程 stop_flag = 1; // 让阻塞 IO 立刻返回 avformat_close_input(&fmt_ctx); // 此时不会卡住我在做过的一个网络播放器里，最初就是没处理中断回调，退出时界面卡住了一两秒没反应，用户体验很糟，而且偶尔在弱网环境下会卡十几秒。加了中断回调之后，关闭流程瞬间就完成了。这个经验在 RTSP、HTTP 这类网络流场景里尤其重要。4. 工程实践：正确的关闭姿势与避坑指南4.1 标准关闭代码示例先给出一个我比较推荐的关闭流程模板，可以直接参考着用。AVFormatContext *fmt_ctx = NULL; // 打开输入 if (avformat_open_input(&fmt_ctx, url, NULL, NULL) < 0) { // 处理错误 } // 让中断回调能够终止阻塞 IO AVIOInterruptCB int_cb = { .callback = interrupt_cb, .opaque = &stop_flag }; fmt_ctx->interrupt_callback = int_cb; // 正常读取数据... // 关闭输入：先通知中断，再执行关闭 stop_flag = 1; avformat_close_input(&fmt_ctx); // 到这里 fmt_ctx 已经被置为 NULL，后续可以安全地再次调用avformat_close_input()已经帮你在最后做了*ps = NULL，所以这里的代码实际上不用担心 double free。关键是那个stop_flag不能省略，尤其是在网络流场景下。顺便提醒一下，在打开输入之后要尽早设置interrupt_callback，最好是在调用avformat_open_input()之前就准备好，因为打开操作本身也可能因为网络问题长时间阻塞。有些网络源不可达时，open 阶段就可能卡住十几秒，如果你等到事后才加中断回调，根本解决不了问题。4.2 常见坑：手动释放后重复关闭有些同学会这样写：AVFormatContext *fmt_ctx = NULL; avformat_open_input(&fmt_ctx, url, NULL, NULL); // ... avformat_free_context(fmt_ctx); avformat_close_input(&fmt_ctx);先调了avformat_free_context()，再调avformat_close_input()，这在多数情况下会直接崩溃，因为avformat_close_input()内部会访问已经被释放的AVFormatContext去取s->pb和s->iformat。不要试图混合使用两种清理方式。要么只用avformat_close_input()做完整生命周期管理，要么你只负责创建上下文但从未打开任何输入，此时才可以直接avformat_free_context()清理。还有一个小建议：尽量把fmt_ctx的生命周期限制在单个函数或者明确的 owner 身上，不要在多个模块之间传来传去，否则你根本判断不了这个指针在哪个环节被释放过。4.3 常见坑：自定义 IO 句柄被双重关闭前面已经提到过自定义 IO 的问题，这里给一个具体的错误示例。int sockfd = socket(AF_INET, SOCK_STREAM, 0); AVIOContext *pb = avio_alloc_context(buffer, size, 0, &sockfd, read_packet, NULL, NULL); AVFormatContext *fmt_ctx = avformat_alloc_context(); fmt_ctx->pb = pb; fmt_ctx->flags |= AVFMT_FLAG_CUSTOM_IO; avformat_open_input(&fmt_ctx, NULL, NULL, NULL); // ... avformat_close_input(&fmt_ctx); close(sockfd); // 错误：如果 FFmpeg 不负责关闭，这里没问题；但如果内部已经关了，这里就是双关这里的问题在于，你不能凭感觉去猜 FFmpeg 是否关闭了你的AVIOContext。正确做法是查你自己使用的 FFmpeg 版本中avformat_close_input()的实现，或者干脆约定：只要设置了AVFMT_FLAG_CUSTOM_IO，就由你自己负责关闭pb和底层资源；没有设置这个标志，就完全不要碰。为了职责清晰，我一般会在关闭后立刻把局部变量sockfd置为 -1，防止后面误用。4.4 常见坑：多线程关闭的顺序播放器类应用最常见的崩溃，就是退出时主线程直接调avformat_close_input()，但解复用线程还阻塞在av_read_frame()上。两个线程同时访问同一个AVFormatContext，一个在读数据，一个在释放资源，崩溃概率极高。正确顺序应该是：先让解复用线程退出，或者通过中断回调让阻塞读返回。等待解复用线程彻底退出并 join。再关闭输入上下文。我在实际开发中踩过一次这个坑：退出时为了省事，直接在主线程里 close，结果回放界面退出后偶发崩溃，但记录播放日志时没有任何错误，后来用 core dump 一查，发现崩溃在av_read_frame()内部的函数里，而且是堆被破坏导致的。从此以后，我给自己定了一条规范：谁创建了解复用线程，谁负责退出和回收；avformat_close_input()永远在解复用线程退出之后执行，不跨线程直接调。5. 排查技巧：怎么判断关闭到底有没有生效5.1 用 fd 数量定位句柄泄漏代码逻辑对不对，不能靠感觉，得看实际证据。最方便的办法是观察 fd 数量变化。在 Linux 上可以用lsof或者直接数/proc/<pid>/fd下的条目数。ls /proc/<pid>/fd | wc -l写一个简单的测试程序：打开输入，读取一部分数据，然后关闭输入。连续循环 1000 次。如果每次循环结束时 fd 总数稳定，说明 IO 层没有泄漏。如果数字一路上涨，说明avformat_close_input()没有真正关闭底层的文件描述符。我通常还会配合strace看系统调用，确认每次关闭是否都触发了对应的close()系统调用。这个工具虽然是排查利器，但在生产环境里要小心被安全策略限制，开发环境里随便用。5.2 开启日志观察关闭顺序FFmpeg 自身的 log 系统很有用，调高日志级别到 debug，然后观察关闭时有没有输出相关日志。ffmpeg -v debug -i input.mp4 -f null - 2>&1 | grep -i close不过自定义的 demuxer 和自定义 IO 往往不会打日志，这时候就得自己在回调里打了。我在自己封装的数据源里会记录当前状态流转，关闭时打一条日志，再配合时间戳确认关闭路径有没有执行。实践下来这种方式比单纯用调试器更快，尤其适合服务端程序。5.3 用调试器确认关闭调用链如果遇到了特别诡异的问题，比如 close 之后某些回调还在被触发，我会直接在avformat_close_input()上下断点，然后用 bt 看是谁在调用它。很多时候能排查出“业务代码里某个第三方库偷偷帮你 close 了一次”这种神坑。(gdb) break avformat_close_input (gdb) run (gdb) bt如果发现关闭函数是在某个自定义模块的析构函数里被间接调用的，而业务代码不知道，那就解释得通了。这类问题靠读代码很难发现，因为析构函数的触发时机太隐蔽，必须靠调试器定位。5.4 常见错误速查表错误现象可能原因处理建议切换片源后 fd 数持续增长旧上下文未调用avformat_close_input()，或只调用了avformat_free_context()确认所有退出路径都经过唯一的关闭入口close 之后程序偶发崩溃use-after-free，业务代码还在访问已释放的fmt_ctx内部指针close 前拷贝需要的数据，close 后无条件检查指针是否已置空自定义 IO 时句柄被关闭两次未正确设置AVFMT_FLAG_CUSTOM_IO或职责不清明确关闭职责：FFmpeg 不负责自定义 IO，由业务自己关网络流关闭卡死底层 IO 阻塞在读写中，没有中断回调设置AVIOInterruptCB，先置退出标志再调 close两个线程同时 close 或同时读缺乏线程同步统一由解复用线程退出后，再执行关闭逻辑6. 源码之外的几点体会最后聊聊我在实际开发中折腾出来的几条经验。第一条，永远不要把avformat_close_input()简单理解成“释放内存的函数”。它更像是一个生命周期终结的仪式：解复用器在这个时间点清理内部状态，IO 层在这个时间点关闭连接，容器在这个时间点回收数据。你把它当成一个“黑盒”来调用，平时可能没事，但一旦遇到 fd 泄漏、崩溃、卡死，你就得回到这个黑盒内部去理解到底发生了什么。第二条，自定义 IO 场景下，务必自己把资源边界画清楚。很多初学者觉得 FFmpeg 的 IO 层设计很绕，其实核心就一句话：谁创建，谁负责。你用avio_alloc_context创建的AVIOContext，它的底层资源就是你的责任；你只是传入一个文件路径，那么整个 IO 生命周期都是 FFmpeg 的责任。把这句话记住，能少踩一半的 IO 相关坑。第三条，建议给项目里做一个统一的“关闭工具函数”。虽然avformat_close_input()已经很完善了，但业务层往往还需要在关闭前做一些额外的事，比如记录播放时长、通知业务系统资源释放、断开自己维护的其他连接。把这一套逻辑收拢到一个函数里，避免散落各处，排查问题时只要查一个入口就够了。我在某个播放器项目里就是这样：关闭前先通知中断回调，然后等待 demux 线程退出，再调avformat_close_input()，最后统一释放自己持有的其他资源。整套流程走下来，视频切换和退出的稳定性高了不少，没有再出现过句柄泄漏和野指针崩溃。如果你手头正好在排查类似的关闭问题，我建议先打开你自己的调用链，看看有没有哪个分支漏了avformat_close_input()。大多数资源泄漏问题，归根结底都是“有一个退出路径没走全”。把入口收拢、把职责分清、把中断回调配上，剩下的就交给时间验证吧。
如果你维护过一个播放器，或者做过流媒体转码服务，大概率对avformat_close_input()这个函数不陌生。它是 FFmpeg 中负责关闭解封装上下文的入口，和avformat_open_input()正好是一对。打开输入好说，真正容易出问题的其实是关闭：资源没释放干净、句柄泄漏、重复关闭导致崩溃，这些我都在实际项目里遇到过。这篇文章不打算贴完整源码，而是把avformat_close_input()的实现思路、释放顺序、参数设计的巧妙之处，以及真正用起来会踩的坑都过一遍。无论你是刚接触 FFmpeg 的初学者，还是已经在做播放器和流媒体服务的开发者，这都能帮你在“收尾”这个环节少折腾几晚。1. 为什么需要单独拆解这个关闭函数1.1 解封装生命周期的最后一环一个典型的 FFmpeg 解封装流程大概是这样的：先avformat_open_input()打开文件或网络流，接着avformat_find_stream_info()探测流信息，然后不断调用av_read_frame()读取 packet，等数据读完了，或者用户主动中止，最后用avformat_close_input()收尾。前面几个函数大家都会用，也都有很多文章在讲，但收尾这一步经常被一笔带过。很多刚入门的同学甚至会认为，程序退出的时候操作系统自然会回收内存，不关也没关系。对于ffmpeg命令行工具这种一次性进程来说，影响确实不大，进程退出后 fd 和内存都会被内核回收。但如果你写的是一个常驻服务，比如流媒体转码网关、录像服务、长时间运行的播放器，或者需要反复切换片源的应用，情况就完全不同了。每次切换片源都泄漏几个 fd、几块内存，跑个几万次之后，服务基本就废了。我见过一个转码服务跑了两周后 fd 数涨到四万多，最后连新的 socket 都开不了，排查问题的时候才发现关闭逻辑根本没写对。avformat_close_input()就是负责把这个生命周期彻底结束掉的函数。它不仅仅是“关一个文件”那么简单，它要处理解复用器自身的状态、协议层的 IO、内部缓冲区、流信息、元数据等一系列资源。把这个函数吃透，你才能保证你的应用在长时间运行时依然稳定。1.2 它和 avformat_free_context 的分工很多人会问：有了avformat_free_context()为什么还需要avformat_close_input()？直接释放上下文不就行了？这两个函数的定位完全不同。avformat_free_context()是通用的资源释放函数，它的职责是把AVFormatContext这个容器里面所有动态分配的东西清掉：streams数组、metadata字典、chapters、programs、内部辅助结构等等。它不关心你当前打开的是什么格式，也不关心 IO 层是怎么建立的。avformat_close_input()高一层的封装，它知道自己当前使用的是哪个解复用器，所以它可以在释放容器之前，先调用该解复用器注册的read_close回调，做一些格式相关的清理工作，比如清理 RTSP 会话、释放 MPEG-TS 的 PSI 解析状态等等。然后它再决定如何处理AVIOContext，最后才调用avformat_free_context()把整个上下文释放掉。换句话说，avformat_close_input()是“懂得上下文当前状态”的高级关闭入口，而avformat_free_context()是“只管拆容器”的底层清理函数。正常工程代码里应该只调用前者，直接调后者反而容易漏掉格式层和 IO 层的资源回收。2. 源码实现逐步拆解2.1 参数设计：为什么必须传二级指针先看函数签名：void avformat_close_input(AVFormatContext **ps);注意这里用的是二级指针。为什么要这么设计？因为关闭函数要做一件很关键的事情：把调用者手里的指针直接置空。函数内部拿到*ps之后，完成释放，最后执行*ps = NULL。这样一来，调用者手里的变量就不会再指向一块已经被释放的内存了。这个设计的好处是防呆。你想想，如果不置空，调用者不小心在 close 之后又把fmt_ctx传给别的函数，或者把它当成参数再调一次 close，后果就是访问野指针，程序直接崩溃，而且崩溃的位置可能离出错点很远，排查起来特别头痛。举个生活中的类比：你交出一把钥匙给管理员，管理员不仅把锁换掉，还把你通讯录里记录的那行地址擦掉，防止你下次照着旧地址又跑过去敲门。C 语言里面“释放后及时置空”是防御性编程的黄金法则，而 FFmpeg 的avformat_close_input()在 API 层面就把这个法则强制落实了。而且这个置空操作配合函数开头对参数的保护检查，还能实现一个很实用的特性：重复调用安全。if (!ps || !*ps) return;如果你连续两次调用avformat_close_input(&fmt_ctx);，第二次进来时*ps已经是 NULL 了，函数啥也不干直接返回。这在错误处理和退出路径非常多的大型项目里很实用，不需要每次调 close 之前都小心翼翼地去判断指针状态。2.2 核心释放顺序：先解复用器，再 IO 层，最后容器我参考的是 FFmpeg 4.x 和 5.x 之间的实现，主干逻辑可以简化成下面的示意代码：void avformat_close_input(AVFormatContext **ps) { AVFormatContext *s = *ps; AVIOContext *pb = s->pb; if (s->iformat) { if (s->iformat->read_close) s->iformat->read_close(s); if (s->iformat->read_header) av_packet_free(&s->internal->parse_pkt); } if (pb && !(s->flags & AVFMT_FLAG_CUSTOM_IO)) avio_close(pb); avformat_free_context(s); *ps = NULL; }注意，不同版本的实现细节会有差异，比如新版 FFmpeg 已经把 IO 层关闭逻辑收拢到了ff_format_io_close()里统一处理，但整体释放顺序和承担的责任是没有变的。我建议你以自己实际使用的源码版本为准来核对，但理解了上面这个主干，后续看哪个版本都能很快对上。整个释放顺序非常讲究，它遵循了一个原则：先释放“更具体、更依赖外部状态”的东西，再释放“更通用、更底层”的东西。第一步调用read_close是在给解复用器一个“临终回调”的机会。每种格式的私有解析状态都在这里清理。比如 RTSP 解复用器的read_close会清理 RTSP 会话相关的资源；MPEG-TS 解复用器会释放 PSI 表解析时分配的各类结构；Matroska 解复用器会释放读取 SeekHead 等结构时的临时缓存。这些状态藏在AVFormatContext->priv_data里，avformat_free_context()虽然也会释放priv_data，但它不知道该格式内部还有没有动态分配的子对象，必须靠read_close来做深度清理。第二步关闭AVIOContext。此时解复用器已经完成自身的清理，不再需要 IO 层来读写数据，所以可以安全关闭文件描述符和网络连接。注意代码里对AVFMT_FLAG_CUSTOM_IO的判断，这个后面单独展开讲，因为它直接影响自定义 IO 场景下的资源归属问题。第三步才调用avformat_free_context()释放容器本身。到了这里，流信息、元数据、章节信息这些纯粹的数据结构就都被统一回收了。最后把指针置空，一个完整的生命周期才算真正结束。2.3 read_close 回调的作用与常见实现上面代码里最容易被忽略的就是read_close回调。我见过不少同学在读 FFmpeg 源码时会跳过这个字段，觉得它只是在文件末尾做了个空操作。其实不是。对于很多简单的文件格式，比如 RAW PCM、BMP 图像，read_close确实可能是空的，因为它们的私有数据没有需要深度释放的东西，avformat_free_context()释放priv_data就够了。但对于复杂格式，这个回调是必须的。以 MPEG-TS 为例，解复用器在解析 PAT、PMT、SDT 等 PSI 表时，会在MpegTSContext里面创建很多链表节点和缓存结构。如果只靠avformat_free_context()去释放整体内存，这些内部动态申请的结构就会泄漏。所以mpegts_close()必须自己遍历释放所有 PSI 相关的结构。再比如 RTSP 解复用器，read_close要做的事更多：它需要关闭底层 socket（如果用的是内置协议栈）、清理 RTSP 会话状态、释放收到的 SDP 解析结果。如果不调用这个回调，你关了一个 RTSP 流之后，那个 TCP 连接可能还悬在那，fd 数只会不断增加。所以，如果你准备自己封装一个 demuxer，或者需要分析某个格式的关闭行为，第一步就是去查它的read_close实现了什么。你才能真正理解一个格式在 close 时到底做了什么。3. 关闭过程中的隐藏细节与资源归属3.1 自定义 IO 场景下，谁负责关闭句柄这是工程中非常容易踩坑的一个点，值得单独拿出来讲。如果你用avformat_open_input()打开本地文件，FFmpeg 内部会替你自己创建并管理AVIOContext，底层的那个文件描述符也是 FFmpeg 打开的。这种情况下，avformat_close_input()调用avio_close()来关闭 IO 没有任何问题，职责清晰。但如果你是自己创建一个AVIOContext，通过AVFMT_FLAG_CUSTOM_IO标志把它塞给AVFormatContext，情况就不一样了。此时底层的数据源是你自己管理的，比如你可能用的是自己的内存缓冲、自己封装的一套私有网络协议、甚至是某个硬件的 DMA 缓冲区，FFmpeg 根本没有权限也不应该去关闭它。所以新版 FFmpeg 的关闭逻辑中，对自定义 IO 场景做了专门处理。如果设置了AVFMT_FLAG_CUSTOM_IO，关闭输入时不会调用avio_close()去关闭你的 IO 层，只会把AVFormatContext内部对AVIOContext的引用清空。真正的关闭动作由调用者自己完成。我见过一个很典型的错误：有人在自己的网络模块里创建了 socket，然后把它包装成自定义AVIOContext传给 FFmpeg 解析数据。程序退出时先调avformat_close_input()，这本身没问题，但他又在 close 之后手动去close(sockfd)关闭同一个 socket。在非自定义 IO 的默认场景里，这就相当于把同一个 fd 关了两遍，轻则 EBADF 报错，重则在 fd 被系统复用之后误关了另一个无关的连接。排查起来非常隐蔽，因为崩溃往往发生在完全不相干的地方。正确做法是确认自己设置了AVFMT_FLAG_CUSTOM_IO，然后在 close input 之后由自己负责关闭底层资源。职责边界从一开始就要划清楚。3.2 元数据与内部状态的隐性释放很多人在关闭输入后还有一个坏习惯：继续访问之前从上下文里拿到的指针。比如avformat_open_input()之后，你通过fmt_ctx->streams[i]->codecpar拿到了编码参数指针，保存下来用。然后调用了avformat_close_input(&fmt_ctx)，按理说这个上下文已经没了，你手里那个codecpar指针也已经失效了，但因为你把它存在别的地方，随手还会继续用，结果就是 use-after-free，崩溃只在某些特定输入下出现，特别难复现。FFmpeg 在 close 时并不会特意提醒你这些内部指针已经失效，它只知道这些内存该还回去了。metadata字典、streams数组、attached_pic、programs、chapters等内部数据结构都会在avformat_free_context()里统一释放。所以一个血泪经验是：如果你需要在 close 之后继续使用流信息或者元数据，必须在 close 之前把数据拷贝出来。比如用avcodec_parameters_to_context()把编码参数复制到自己的解码器上下文里，或者用av_dict_get()逐个提取你需要的元数据字段。永远不要把AVFormatContext内部的指针带到它的生命周期之外。3.3 interrupt_callback 与阻塞 IO 的时序问题还有一个经常被忽视的隐藏细节：avformat_close_input()本身是可能阻塞的。如果输入是一个网络流，而且底层 IO 正处于阻塞读状态，比如 TCP 连接已经断了，但超时时间还没到，那么你在另一个线程里调用avformat_close_input()时候，它可能不会立即返回，而是卡在读操作上，直到超时或者中断条件满足。正确做法是给AVFormatContext设置一个AVIOInterruptCB中断回调。在回调里维护一个退出标志。当你要关闭输入时，先把这个标志置位，让底层阻塞的 IO 立刻返回错误，然后再调用avformat_close_input()，这样关闭动作才能很快完成。static int interrupt_cb(void *ctx) { return *(volatile int *)ctx; } // 主线程退出流程 stop_flag = 1; // 让阻塞 IO 立刻返回 avformat_close_input(&fmt_ctx); // 此时不会卡住我在做过的一个网络播放器里，最初就是没处理中断回调，退出时界面卡住了一两秒没反应，用户体验很糟，而且偶尔在弱网环境下会卡十几秒。加了中断回调之后，关闭流程瞬间就完成了。这个经验在 RTSP、HTTP 这类网络流场景里尤其重要。4. 工程实践：正确的关闭姿势与避坑指南4.1 标准关闭代码示例先给出一个我比较推荐的关闭流程模板，可以直接参考着用。AVFormatContext *fmt_ctx = NULL; // 打开输入 if (avformat_open_input(&fmt_ctx, url, NULL, NULL) < 0) { // 处理错误 } // 让中断回调能够终止阻塞 IO AVIOInterruptCB int_cb = { .callback = interrupt_cb, .opaque = &stop_flag }; fmt_ctx->interrupt_callback = int_cb; // 正常读取数据... // 关闭输入：先通知中断，再执行关闭 stop_flag = 1; avformat_close_input(&fmt_ctx); // 到这里 fmt_ctx 已经被置为 NULL，后续可以安全地再次调用avformat_close_input()已经帮你在最后做了*ps = NULL，所以这里的代码实际上不用担心 double free。关键是那个stop_flag不能省略，尤其是在网络流场景下。顺便提醒一下，在打开输入之后要尽早设置interrupt_callback，最好是在调用avformat_open_input()之前就准备好，因为打开操作本身也可能因为网络问题长时间阻塞。有些网络源不可达时，open 阶段就可能卡住十几秒，如果你等到事后才加中断回调，根本解决不了问题。4.2 常见坑：手动释放后重复关闭有些同学会这样写：AVFormatContext *fmt_ctx = NULL; avformat_open_input(&fmt_ctx, url, NULL, NULL); // ... avformat_free_context(fmt_ctx); avformat_close_input(&fmt_ctx);先调了avformat_free_context()，再调avformat_close_input()，这在多数情况下会直接崩溃，因为avformat_close_input()内部会访问已经被释放的AVFormatContext去取s->pb和s->iformat。不要试图混合使用两种清理方式。要么只用avformat_close_input()做完整生命周期管理，要么你只负责创建上下文但从未打开任何输入，此时才可以直接avformat_free_context()清理。还有一个小建议：尽量把fmt_ctx的生命周期限制在单个函数或者明确的 owner 身上，不要在多个模块之间传来传去，否则你根本判断不了这个指针在哪个环节被释放过。4.3 常见坑：自定义 IO 句柄被双重关闭前面已经提到过自定义 IO 的问题，这里给一个具体的错误示例。int sockfd = socket(AF_INET, SOCK_STREAM, 0); AVIOContext *pb = avio_alloc_context(buffer, size, 0, &sockfd, read_packet, NULL, NULL); AVFormatContext *fmt_ctx = avformat_alloc_context(); fmt_ctx->pb = pb; fmt_ctx->flags |= AVFMT_FLAG_CUSTOM_IO; avformat_open_input(&fmt_ctx, NULL, NULL, NULL); // ... avformat_close_input(&fmt_ctx); close(sockfd); // 错误：如果 FFmpeg 不负责关闭，这里没问题；但如果内部已经关了，这里就是双关这里的问题在于，你不能凭感觉去猜 FFmpeg 是否关闭了你的AVIOContext。正确做法是查你自己使用的 FFmpeg 版本中avformat_close_input()的实现，或者干脆约定：只要设置了AVFMT_FLAG_CUSTOM_IO，就由你自己负责关闭pb和底层资源；没有设置这个标志，就完全不要碰。为了职责清晰，我一般会在关闭后立刻把局部变量sockfd置为 -1，防止后面误用。4.4 常见坑：多线程关闭的顺序播放器类应用最常见的崩溃，就是退出时主线程直接调avformat_close_input()，但解复用线程还阻塞在av_read_frame()上。两个线程同时访问同一个AVFormatContext，一个在读数据，一个在释放资源，崩溃概率极高。正确顺序应该是：先让解复用线程退出，或者通过中断回调让阻塞读返回。等待解复用线程彻底退出并 join。再关闭输入上下文。我在实际开发中踩过一次这个坑：退出时为了省事，直接在主线程里 close，结果回放界面退出后偶发崩溃，但记录播放日志时没有任何错误，后来用 core dump 一查，发现崩溃在av_read_frame()内部的函数里，而且是堆被破坏导致的。从此以后，我给自己定了一条规范：谁创建了解复用线程，谁负责退出和回收；avformat_close_input()永远在解复用线程退出之后执行，不跨线程直接调。5. 排查技巧：怎么判断关闭到底有没有生效5.1 用 fd 数量定位句柄泄漏代码逻辑对不对，不能靠感觉，得看实际证据。最方便的办法是观察 fd 数量变化。在 Linux 上可以用lsof或者直接数/proc/<pid>/fd下的条目数。ls /proc/<pid>/fd | wc -l写一个简单的测试程序：打开输入，读取一部分数据，然后关闭输入。连续循环 1000 次。如果每次循环结束时 fd 总数稳定，说明 IO 层没有泄漏。如果数字一路上涨，说明avformat_close_input()没有真正关闭底层的文件描述符。我通常还会配合strace看系统调用，确认每次关闭是否都触发了对应的close()系统调用。这个工具虽然是排查利器，但在生产环境里要小心被安全策略限制，开发环境里随便用。5.2 开启日志观察关闭顺序FFmpeg 自身的 log 系统很有用，调高日志级别到 debug，然后观察关闭时有没有输出相关日志。ffmpeg -v debug -i input.mp4 -f null - 2>&1 | grep -i close不过自定义的 demuxer 和自定义 IO 往往不会打日志，这时候就得自己在回调里打了。我在自己封装的数据源里会记录当前状态流转，关闭时打一条日志，再配合时间戳确认关闭路径有没有执行。实践下来这种方式比单纯用调试器更快，尤其适合服务端程序。5.3 用调试器确认关闭调用链如果遇到了特别诡异的问题，比如 close 之后某些回调还在被触发，我会直接在avformat_close_input()上下断点，然后用 bt 看是谁在调用它。很多时候能排查出“业务代码里某个第三方库偷偷帮你 close 了一次”这种神坑。(gdb) break avformat_close_input (gdb) run (gdb) bt如果发现关闭函数是在某个自定义模块的析构函数里被间接调用的，而业务代码不知道，那就解释得通了。这类问题靠读代码很难发现，因为析构函数的触发时机太隐蔽，必须靠调试器定位。5.4 常见错误速查表错误现象可能原因处理建议切换片源后 fd 数持续增长旧上下文未调用avformat_close_input()，或只调用了avformat_free_context()确认所有退出路径都经过唯一的关闭入口close 之后程序偶发崩溃use-after-free，业务代码还在访问已释放的fmt_ctx内部指针close 前拷贝需要的数据，close 后无条件检查指针是否已置空自定义 IO 时句柄被关闭两次未正确设置AVFMT_FLAG_CUSTOM_IO或职责不清明确关闭职责：FFmpeg 不负责自定义 IO，由业务自己关网络流关闭卡死底层 IO 阻塞在读写中，没有中断回调设置AVIOInterruptCB，先置退出标志再调 close两个线程同时 close 或同时读缺乏线程同步统一由解复用线程退出后，再执行关闭逻辑6. 源码之外的几点体会最后聊聊我在实际开发中折腾出来的几条经验。第一条，永远不要把avformat_close_input()简单理解成“释放内存的函数”。它更像是一个生命周期终结的仪式：解复用器在这个时间点清理内部状态，IO 层在这个时间点关闭连接，容器在这个时间点回收数据。你把它当成一个“黑盒”来调用，平时可能没事，但一旦遇到 fd 泄漏、崩溃、卡死，你就得回到这个黑盒内部去理解到底发生了什么。第二条，自定义 IO 场景下，务必自己把资源边界画清楚。很多初学者觉得 FFmpeg 的 IO 层设计很绕，其实核心就一句话：谁创建，谁负责。你用avio_alloc_context创建的AVIOContext，它的底层资源就是你的责任；你只是传入一个文件路径，那么整个 IO 生命周期都是 FFmpeg 的责任。把这句话记住，能少踩一半的 IO 相关坑。第三条，建议给项目里做一个统一的“关闭工具函数”。虽然avformat_close_input()已经很完善了，但业务层往往还需要在关闭前做一些额外的事，比如记录播放时长、通知业务系统资源释放、断开自己维护的其他连接。把这一套逻辑收拢到一个函数里，避免散落各处，排查问题时只要查一个入口就够了。我在某个播放器项目里就是这样：关闭前先通知中断回调，然后等待 demux 线程退出，再调avformat_close_input()，最后统一释放自己持有的其他资源。整套流程走下来，视频切换和退出的稳定性高了不少，没有再出现过句柄泄漏和野指针崩溃。如果你手头正好在排查类似的关闭问题，我建议先打开你自己的调用链，看看有没有哪个分支漏了avformat_close_input()。大多数资源泄漏问题，归根结底都是“有一个退出路径没走全”。把入口收拢、把职责分清、把中断回调配上，剩下的就交给时间验证吧。