FFmpeg av_init_packet详解：AVPacket内存模型与引用计数避坑指南

前几天群里有个人贴了一段解码代码，问为什么偶现段错误。代码里就是定义一个AVPacket pkt，没有初始化，直接丢给av_read_frame。很多人第一反应说“加个av_init_packet试试”，结果真就好了。但问题远没结束——后来他又在后面手动给pkt.data赋了个指针，程序跑起来不是double free就是内存泄漏。这件事是我一直想写一篇av_init_packet详解的原因：FFmpeg里几乎所有音视频开发教程都会让你在用到AVPacket前先av_init_packet，但很少有人把这行代码背后的内存模型、引用计数机制、以及它为什么不建议在新代码里继续用讲清楚。这篇文章不打算贴一堆官方文档，只讲我实际写代码、查崩溃、看源码总结出来的干货。读完你至少能避开一半以上跟AVPacket生命周期相关的崩溃和泄漏。

1. av_init_packet为什么存在：先处理栈上AVPacket的“垃圾状态”

在C语言里玩FFmpeg，绕不开AVPacket这个结构体。它对应一条音视频数据包：可能是解码后的一帧输出，可能是压缩后的一段流数据，也可能是封装层读出来的一包原始数据。很多初学者上来就写：

AVPacket pkt; av_read_frame(ifmt_ctx, &pkt);

这样写在新旧版本FFmpeg里都是雷。AVPacket pkt只是声明一个栈上变量，C语言不会帮你把内存清零，所以pkt.buf、pkt.data、pkt.size这些字段都是未知垃圾值。av_read_frame底层会做av_packet_unref(pkt)来清理传入的包，而av_packet_unref看到pkt->buf是个野指针，会直接尝试对随机地址做引用计数释放——这基本等于自杀。运气差就是段错误，运气“好”就变成某个偏僻字段被改掉，隔几秒才崩。

av_init_packet就是为解决这种不确定性而生的。它的职责专一明确：把一个AVPacket变量恢复成“未持有任何资源、所有字段都有确定值”的出厂状态。你可以把它看作是AVPacket的构造函数。注意，它不会分配任何内存，也不会做任何引用计数操作，它只负责“摆平”结构体本身的字段。

这就要解释为什么av_packet_alloc能成为官方推荐方案。av_packet_alloc分配一个AVPacket并初始化它，帮你把“声明变量”和“初始化变量”两步合成一步，而且返回的是堆上指针，方便跨函数传递。但理解av_init_packet仍然有价值：老教程、老项目、某些嵌入式代码里你还得跟它打交道，如果不懂它的初始化边界，很容易把它当成万能的清理函数来用，反而埋雷。

1.1 不初始化直接用的现场还原

我们先看一个具体崩溃现场。代码类似这样：

AVPacket pkt; if (av_read_frame(ifmt_ctx, &pkt) >= 0) { process_packet(&pkt); av_packet_unref(&pkt); // 这里炸了 }

实际表现是double free或者invalid pointer，GDB回溯栈通常在av_buffer_unref附近。原因就是pkt栈上垃圾值里的buf正好指向了一块“看起来像AVBufferRef”的内存地址，av_buffer_unref就勇敢地去把那个地址的引用计数减一，发现不匹配，直接abort。更隐蔽的一种情况是pkt->buf刚好是NULL，但pkt->data是个野指针，av_read_frame内部在没有清理干净的情况下往野地址写数据，让你感觉是“随机崩溃”。

在老版本FFmpeg里，av_read_frame文档明确写着：传入的AVPacket必须已经通过av_init_packet初始化。原因就是它内部对传入包先做清理，如果包是垃圾状态，清理就变成对垃圾地址的操作。新版av_read_frame虽然对分配好的packet有额外保护，但官方示例几乎清一色改成av_packet_alloc，本质还是同一个逻辑：先有干净状态，再往里面填数据。

1.2 av_init_packet给每个字段的出厂设置

av_init_packet的源码在不同版本略有差异，但骨架基本是这样：

void av_init_packet(AVPacket *pkt) { pkt->pts = AV_NOPTS_VALUE; // 没有时间戳 pkt->dts = AV_NOPTS_VALUE; pkt->pos = -1; pkt->duration = 0; pkt->flags = 0; pkt->stream_index = 0; pkt->data = NULL; pkt->size = 0; pkt->side_data = NULL; pkt->side_data_elems = 0; pkt->buf = NULL; // 新版本还包含： pkt->time_base = (AVRational){0, 1}; pkt->opaque = NULL; pkt->opaque_ref = NULL; }

这些字段的作用后面会细讲，这里先明确几个关键点：

• pts/dts被设为AV_NOPTS_VALUE，这是一个int64_t的特殊值（INT64_MIN），表示“没有时间戳”，而不是0。因为0在时间基里可能是合法值，用INT64_MIN才能区分“无效”和“第0个时间刻度”。
• pos设为-1，表示“不知道在文件里的字节位置”。
• data、size、buf全部归零，意味着这个包不持有任何媒体数据缓冲区。
• side_data和side_data_elems归零，意味着没有附加元数据。

一句话总结：调用av_init_packet之后，你得到一个干净的、空的、可以安全传给解复用器或解码器的AVPacket。它不等于av_new_packet，后者还会额外分配一块数据缓冲区。

2. 从空包到有数据的包：data、size、buf三者怎么配合

av_init_packet只管清空，不管填充。你拿到一个干净包后，最常见的操作是从文件读包或从编码器取包，这些场景FFmpeg内部会帮你在pkt->buf上挂引用。但如果你要手动构造一个AVPacket，问题就来了：从空包到有数据的包，到底要改哪几个字段？

先看三个最关键成员：

• uint8_t *data：指向媒体数据起始地址。解码器、编码器、复用器和滤镜都靠这个指针读数据。
• int size：data指向的有效数据长度，单位是字节。
• AVBufferRef *buf：引用计数容器。buf管理一块内存的所有权，data通常指向buf->data。

三者关系是：data和size描述“这段数据在哪里、有多长”，buf决定“这段内存归谁管、什么时候释放”。如果你只设置了data和size，让buf保持NULL，FFmpeg的引用计数体系就会认为这个包不拥有内存，最后av_packet_unref不会碰你的data。在某些一次性处理场景下这可能“能跑”，但一旦包被跨线程传递、多次引用、或者被解码器持有，就必然出现没人释放或重复释放的乱局。

2.1 理解空包、新包和已分配包的区别

av_init_packet(pkt)之后是空包：buf == NULL && data == NULL && size == 0。空包是“状态干净，但没有数据”。

如果你需要一块指定大小的缓冲区，正确做法是：

AVPacket pkt; av_init_packet(&pkt); av_new_packet(&pkt, 4096);

av_new_packet内部会先做一次av_init_packet语义，然后分配4096字节的buffer并挂到pkt->buf上，同时把pkt->data指向buf->data。这时包是“已分配包”：数据区定了，但里面是垃圾内容，你可以往里写一帧H264、一帧PCM或任何封装数据。

还有一种情况是你已经有一段buffer，想“托管”给AVPacket，可以使用：

AVPacket pkt; av_init_packet(&pkt); uint8_t *my_data = av_malloc(4096); memcpy(my_data, raw, 2024); int ret = av_packet_from_data(&pkt, my_data, 2024);

av_packet_from_data会创建一个AVBufferRef来接管my_data。从此以后，你不再手动av_free这块内存，而是通过av_packet_unref(&pkt)来释放。这正是很多旧代码容易写错的地方：直接pkt.data = av_malloc(...)然后送进解码器，解码器消费完就av_packet_unref，结果内存迟迟不释放，因为pkt.buf还是NULL，引用计数机制根本不认识这块内存。

2.2 为什么buf才是生命周期管理的主角

buf是AVBufferRef结构体的指针，里面保存了底层引用计数。当多个AVPacket共享同一份媒体数据时，它们复制的是AVBufferRef指针，而不是拷贝整块内存。调用av_packet_ref时，新的包通过av_buffer_ref让引用计数加一；调用av_packet_unref时，av_buffer_unref让引用计数减一。只有当计数归零，底层内存才会真正释放。

这个设计决定了：一个包是否“拥有”数据，不是看data指针，而是看buf。av_init_packet把buf置NULL，等于告诉FFmpeg“这个包目前没有数据所有权”。后续所有API都围绕这个约定工作。

因此我强烈建议：只要你的代码里出现了“给pkt.data手动赋地址”的操作，就要警惕。除非你能保证该地址的生命周期一定长于包，并且不会经过av_packet_unref，否则请通过av_packet_alloc/av_packet_from_data/av_new_packet来建立正确的buf关系。这些API是FFmpeg给你的工具箱，不是摆设。

2.3 清空一个包的正确做法不是av_init_packet

很多开发者的习惯是：用完一个包，再av_init_packet一下准备下次用。这在包未持有任何资源时没问题，但如果包已经带着buf和引用计数，这样做的结果是：你把pkt->buf直接改成NULL，原来那个引用没有经过av_buffer_unref的减一操作，等于“放生”了一块内存，次数多了就是内存泄漏；更糟的是，如果别的包还持有同一个AVBufferRef，你只是丢掉这个包自己的一份引用，到别人的包应该释放时，计数可能不准确。

正确的清空操作是av_packet_unref，它会把buf、side_data、opaque_ref等所有内部资源按引用计数规则逐一释放，然后让包回到类似av_init_packet的初态。这才是“重置包”的完整语义。

3. 解码、编码、传包：av_init_packet在不同场景的正确姿势

前面都是理论，这节给实际用法。不同FFmpeg版本对AVPacket生命周期的要求不一样，但理解av_init_packet可以帮助你平滑过渡。

3.1 老式解码循环为什么要求手动初始化

在FFmpeg 4.0以前，官方示例里很常见的模式：

AVPacket pkt; av_init_packet(&pkt); while (av_read_frame(ifmt_ctx, &pkt) >= 0) { avcodec_send_packet(dec_ctx, &pkt); // 取出解码结果... av_packet_unref(&pkt); }

av_init_packet(&pkt)必须在每次循环开始前调用吗？不一定。第一次循环前调用一次，后续每次av_packet_unref会把包重置回初始状态，所以循环里不需要再av_init_packet。但如果你在循环内对包做了浅拷贝，或者在某个分支提前返回了，下一次循环时包的状态可能是旧的，那就必须重新初始化。

老版本av_read_frame对传入包的依赖更强：它可能直接在一个未初始化的AVPacket上填充data和size，而不会先清理原有buf。所以大家约定俗成地先av_init_packet。新版本里av_read_frame内部会先av_packet_unref(pkt)再做实际读取，这意味着传入包如果完全没初始化，反而会在这一步崩溃。这也是为什么我鼓励新代码直接用av_packet_alloc，而不是手动栈上变量加av_init_packet；前者能保证包永远是“已分配且已初始化”的状态。

3.2 新工程推荐的生命周期主线

新代码建议这样写：

AVPacket *pkt = av_packet_alloc(); if (!pkt) return -1; while (av_read_frame(ifmt_ctx, pkt) >= 0) { if (pkt->stream_index == video_stream_index) { avcodec_send_packet(dec_ctx, pkt); while (avcodec_receive_frame(dec_ctx, frame) >= 0) { // 处理帧 } } av_packet_unref(pkt); } av_packet_free(&pkt);

av_packet_alloc做了两件事：从堆上分配AVPacket结构体空间，然后完成与av_init_packet等价的初始化。av_packet_unref(pkt)负责用完释放内部资源，同时把包带回初始空状态。av_packet_free(&pkt)在最后释放结构体本身。

使用这个模式后，你基本不再需要手动调用av_init_packet，因为av_packet_alloc已经把初始化做完了。但如果你看到老代码里的av_init_packet，不要觉得它错得离谱，它只是在老API环境下的标准操作。

3.3 编码输出侧的坑：receive_packet不给你免罪符

编码侧更容易踩坑。avcodec_receive_packet会把输出包写到传入的AVPacket里，但它同样要求这个包处于干净状态。最典型的错法：

AVPacket pkt; // 没有av_init_packet，也没有av_packet_alloc if (avcodec_receive_packet(enc_ctx, &pkt) == 0) { fwrite(pkt.data, 1, pkt.size, out); av_packet_unref(&pkt); // 崩溃 }

avcodec_receive_packet内部会先对传入包执行清理，来保证写数据时没有旧引用干扰。所以传入包不干净就会在清理阶段崩溃。正确写法是：

int ret = avcodec_receive_packet(enc_ctx, pkt); if (ret == 0) { // 立即消费pkt.data，或者av_packet_ref一份给别处用 ... av_packet_unref(pkt); }

这里有个容易被忽略的细节：avcodec_receive_packet成功拿到的pkt里，数据是挂在引用计数buffer上的。如果你只是把pkt这个指针变量本身存到队列里，等循环下一轮av_packet_unref之后，队列里那个指针指向的缓冲区已经释放了。所以跨函数、跨线程传递时，要么提前av_packet_ref一份新的引用，要么用av_packet_move_ref把所有权搬走。这与av_init_packet的“只清字段”完全是两码事。

4. 我排查过的几个“灵异崩溃”：AVPacket生命周期误用实录

下面分享几个我实际遇到、或者帮人排过的崩溃，都是围绕av_init_packet和AVPacket生命周期。

4.1 浅拷贝后av_init_packet，引用计数直接断裂

某次一个转码服务偶发崩溃，排查后发现代码里是这样的：

AVPacket src, dst; av_init_packet(&src); av_read_frame(ifmt_ctx, &src); // src.buf非空 dst = src; // 浅拷贝，src.buf和dst.buf指向同一个AVBufferRef av_init_packet(&dst); // 错误！dst.buf被置NULL

问题在于：dst = src只是拷贝了指针。src.buf和dst.buf本来指向同一个引用计数对象，二者共享一份数据。如果只是想复制包，应该用av_packet_ref(&dst, &src)，它会创建新的引用并让计数加一。而av_init_packet(&dst)把这个引用凭空扔掉，后继src使用时计数已经对不上，最后释放就会出问题。

更微妙的是，有些库函数内部可能对传入的AVPacket做了一次av_init_packet，如果你同时在外层也做了一次浅拷贝，多个字段就会被覆盖。排查这种问题，最直接的方式是在av_init_packet处打断点，看它到底作用在哪个包上，以及这个包的buf是否为空。

4.2 自己malloc给data，却没走av_packet_from_data

我见过很多从老C++代码迁移过来的工程，还在用这种写法：

AVPacket pkt; av_init_packet(&pkt); pkt.data = (uint8_t*)malloc(1024); pkt.size = 1024; // 不设置pkt.buf avcodec_send_packet(dec_ctx, &pkt); ... av_packet_unref(&pkt);

第一眼看上去逻辑没问题：初始化了，有数据，用完了释放。但实际运行是：内存持续增长，或者某些怪异行为。原因就是pkt.buf == NULL，av_packet_unref不检查data是否由malloc分配，它只负责释放buf指向的AVBuffer。所以1024字节永远不会释放。这也回答了很多人“为什么我调了av_init_packet还泄漏”的疑问。

正确的托管方式前面已经写过：av_packet_from_data会为你的指针建立AVBufferRef。当然，你也可以分配内存后用av_buffer_create手动包装，但较少用。我建议一律用av_packet_from_data，它能处理data == NULL && size == 0的边界情况，并保证buf不会被误设。

4.3 对非空包再次av_init_packet，旧buffer被“放生”

还有一种模式也很常见：在循环里每次读取前都调用一次av_init_packet，就像这样：

AVPacket pkt; while (av_read_frame(ifmt_ctx, &pkt) >= 0) { ... av_init_packet(&pkt); // 以为在“为下一次读包做准备” }

这同样有问题。第一次av_read_frame后，pkt.buf已经持有引用。第二次循环开头再av_init_packet时，它把buf强行置NULL，旧引用没有释放，造成泄漏。这个泄漏不会立刻暴露，但跑一夜转码任务后内存占用可能翻几倍。

更安全的是在每轮循环结尾调用av_packet_unref(&pkt)，它会释放旧buf并把包重置为空状态。这样下一轮循环开头的包就是干净的，无需再手动av_init_packet。顺便说一句，av_packet_unref之后的AVPacket状态和av_init_packet后的状态几乎一致，所以它才是更完整的“重置+释放”函数。

4.4 时间戳字段的手工初始化：不要只盯着data

最后补充一个常见问题：有人只用av_init_packet初始化结构体，然后自己填data和size，却忘记填pts、dts、duration。结果编码出来的流时间戳全部变成AV_NOPTS_VALUE，播放器要么快进要么卡死。av_init_packet只是把字段设为默认值，不是帮你生成正确的时间戳。你需要在业务代码里根据实际帧率、采集时间或解码顺序来赋值。这个坑不属于崩溃，但属于“看起来正常、实际没法用”。

5. av_init_packet还该不该用：我的取舍与替代方案

FFmpeg 4.0之后，av_init_packet被官方标记为deprecated（弃用），新代码推荐用av_packet_alloc与av_packet_unref的组合。但现实世界不是一纸公告就能瞬间切换的，很多老库、嵌入式平台、第三方封装还在大量使用它。我的建议是：读懂它，但尽量不依赖它。

5.1 我在哪些场景仍然会手动av_init_packet

第一种场景是嵌入式或低内存环境。你不想每次都在堆上av_packet_alloc一个对象，而是希望把AVPacket作为某个大结构体的字段直接嵌入：

typedef struct { AVPacket pkt; // 其他业务字段 } MyQueueNode;

这种场景AVPacket不是独立的堆对象，无法用av_packet_alloc管理，只能手动初始化。在节点入池时调用av_init_packet(&node->pkt)，配合av_packet_unref维护生命周期，这是完全合理的用法。

第二种场景是“临时包”。有时候你只是想搭一个临时包给滤镜或复用器，例如把一个已经持有数据的buffer包装成包送出去，但又不想引入堆分配：

AVPacket tmp; av_init_packet(&tmp); av_packet_from_data(&tmp, data, size); // 用完unref即可

这种情况下，栈上AVPacket加av_init_packet是最轻量的选择。注意，av_packet_from_data要求传入的包已经初始化，这里av_init_packet正是为了满足这个前提。

第三种场景是兼容老代码。项目里大量使用FFmpeg 3.x接口，且编码器回调要求传入已完成av_init_packet的包，你没有动力全面重构。这时只要把“初始化、引用、释放”的边界搞清楚，继续使用也没有原则性问题，只是编译时会有弃用警告，未来切版本要预留时间。

5.2 av_packet_move_ref：比拷贝+unref更高效的所有权转移

如果你需要把已经持有的包转交给另一个包，av_packet_move_ref(pkt, src)是最安全的方式。它把src的所有buffer指针整体搬给pkt，然后把src清空。整个过程中引用计数不需要增减，避免了av_packet_ref加av_packet_unref的两次操作。

对比一下三种常见操作：

av_init_packet在这个演进里的位置是：它作为“结构体重置”的基础操作，被av_packet_alloc、av_packet_unref间接使用。所以你仍然可以把它理解为AVPacket生命周期的基石，只是在新代码里它不再站在前台。

5.3 给新人的生命周期主线

如果你刚接触FFmpeg，我建议直接把下面这条主线背下来，不要被老教程带偏：

• 创建：AVPacket *pkt = av_packet_alloc();
• 塞数据：交给av_read_frame或avcodec_receive_packet，它们会用内部buf填充
• 拷贝/转移：需要保留包时用av_packet_ref或av_packet_move_ref
• 释放/重置：每轮循环结束调用av_packet_unref(pkt)
• 最后销毁：退出时av_packet_free(&pkt)

在这条主线里，av_init_packet只是隐藏在底层的初始化器。你明白它的存在，但不一定需要亲手调它。真正上手调它的时候，往往是写自定义数据源、包管理器、或者嵌入式队列，那时这篇详解里讲的“buf/data/size必须配套”“浅拷贝即引用共享”“清空不等于释放”这些认知，才是你排查问题的底气。