在FFmpeg的开发实践中，内存泄漏是最高频的问题之一。不少开发者以为调用了av_free就万事大吉，结果用Valgrind一测，依旧满屏的definitely lost。问题的根源在于FFmpeg的结构体大多是复合资源容器，av_free只负责释放指针本身指向的那块内存，并不会递归释放结构体内部持有的其他资源。理解这一点，是解决FFmpeg内存泄漏的第一步。
av_free到底释放了什么
av_free的底层实现本质上就是对free的一层封装，它做的事情非常单纯：把你传给它的指针所指向的内存块还给系统。它不做任何检查、不做任何递归、也不会处理结构体内部的成员指针。这意味着，如果你对一个内部还持有缓冲区的结构体只调用av_free，那么内部缓冲区的内存就永远丢失了。
与av_free相比，av_freep是更安全的选择。它接收二级指针，释放内存之后还会把原指针置为NULL，可以有效避免悬垂指针被二次释放的问题。官方文档也明确建议，在释放动态分配的内存时优先使用av_freep。来看一个典型对比：
// 方式一：存在悬垂指针风险 av_free(pkt->data); pkt->data = NULL; // 需要手动置空 // 方式二：推荐写法，释放并自动置空 av_freep(&pkt->data);
另外要注意，av_free并不能替代FFmpeg提供的专用释放函数。比如AVFrame内部可能持有引用计数的缓冲区，直接av_free(frame)不仅无法释放内部缓冲区，还可能破坏引用计数机制，造成更严重的后果。正确做法是先调用av_frame_unref(frame)清理引用，再决定是否释放结构体本身。
正确区分专用释放函数与通用释放函数
FFmpeg为每类核心结构体都提供了配套的释放函数，它们与av_free的关系是分工而非替代。理解这套分工，比死记硬背函数名重要得多。核心原则是：谁分配的内存，就用谁的接口去释放。
- AVFormatContext：使用
avformat_close_input关闭输入上下文，它会顺带释放内部缓冲。如果上下文是自己通过avformat_alloc_context创建的，则用avformat_free_context释放。 - AVCodecContext：使用
avcodec_free_context释放，它会处理编解码器内部的所有私有数据。 - AVFrame：使用
av_frame_free释放，其内部会先调用av_frame_unref减少引用计数。 - AVPacket：使用
av_packet_free释放，旧的av_free_packet接口已在新版本中被废弃。 - SWR / SWS上下文：分别使用
swr_free和sws_freeContext释放。
一个完整的解封装与解码流程的资源清理示例如下，注意释放顺序与置空写法：
void cleanup(AVFormatContext *fmt_ctx,
AVCodecContext *dec_ctx,
AVFrame *frame,
AVPacket *pkt)
{
// 顺序很关键：先释放最内层的资源
av_frame_free(&frame); // 释放帧并置空指针
av_packet_free(&pkt); // 释放包并置空指针
avcodec_free_context(&dec_ctx); // 释放解码器上下文
avformat_close_input(&fmt_ctx); // 关闭输入并置空指针
}这里有个容易踩的坑：如果解码过程中发生了错误就提前return，而清理代码只写在函数末尾，中间任何一处提前返回都会造成泄漏。解决办法是采用goto cleanup的经典C语言模式，或者把所有资源打包进一个上下文结构体，统一提供destroy函数。FFmpeg源码示例程序几乎都采用goto模式，这不是编码风格落后，而是对错误处理路径的务实处理。
排查与预防内存泄漏的实践方法
当怀疑存在泄漏时，Valgrind是Linux下最直接的排查工具。运行valgrind --leak-check=full --track-origins=yes ./your_app后，重点观察调用栈中出现的FFmpeg分配函数，例如av_malloc、av_buffer_alloc等，通过调用栈就能反推出是哪一步分配的内存没有被对应的接口释放。需要注意的是，某些FFmpeg内部的全局缓存会被Valgrind标记为still reachable，这类输出通常不代表真正的泄漏。
在Windows平台上，可以用Visual Studio自带的诊断工具或Dr. Memory代替。另外FFmpeg自身提供av_log_set_callback，可以注册日志回调来观察资源分配与释放的行为，配合AV_LOG_TRACE级别能拿到相当详细的信息。
预防层面，建议在项目初期就约定几条规范：第一，禁止对FFmpeg结构体直接调用av_free，必须使用对应的专用释放函数；第二，所有指针在释放后立即通过av_freep或二级指针形式的free函数置空；第三，为每类资源编写配对的open与close函数，保证分配与释放的对称性。下面是一个推荐的资源上下文模板：
typedef struct MediaContext {
AVFormatContext *fmt_ctx;
AVCodecContext *dec_ctx;
AVFrame *frame;
AVPacket *pkt;
} MediaContext;
int media_open(MediaContext *mc, const char *url)
{
memset(mc, 0, sizeof(*mc));
// ... 打开流、找到解码器、分配frame和packet
return 0;
}
void media_close(MediaContext *mc)
{
av_frame_free(&mc->frame);
av_packet_free(&mc->pkt);
avcodec_free_context(&mc->dec_ctx);
avformat_close_input(&mc->fmt_ctx);
// memset保证即使重复调用也不会二次释放
memset(mc, 0, sizeof(*mc));
}这套模板的好处是对重复调用天然免疫：因为所有指针在释放后都会被置空，media_close即使被调用两次也不会崩溃。配合统一的生命周期管理，绝大多数FFmpeg内存泄漏问题都能在编码阶段就被消除，而不是等到线上服务内存涨爆之后才回头排查。
FFmpeg内存管理av_free内存泄漏排查修改时间：2026-09-05 00:50:31