★ FEATURED ARTICLE 1. 从一次花屏事故说起为什么解码环节的缓存管理值得单独拎出来讲视频解码这件事表面上看就是把压缩数据喂给解码器然后拿到一帧画面。但真正在生产环境里跑过转码、推流、播放器内核或者视频分析流水线的人都知道解码环节的缓存管理才是最容易出问题的地方。我最早接触这块是在一个视频处理项目里当时遇到一个非常典型的现象本地播放某个文件完全正常但一旦接入实时数据流做解码画面就会间歇性花屏偶尔还伴随解码器报错。排查了很久最后发现问题出在数据从缓存区取出、再写入另一个缓存区的过程中边界处理没做对。这个标题FFmpeg从缓存区获取数据再写入缓存区----视频解码说的其实就是解码流水线里最核心的一环数据在进入解码器之前需要从某个缓冲区读取压缩数据经过整理后再写入解码器需要的缓冲区结构然后才能交给解码 API 处理。听起来像是简单的内存拷贝但实际操作中涉及 AVPacket 的构造、引用计数、缓冲区对齐、数据分片、时间戳传递等一系列细节。任何一个环节处理不当轻则画面异常重则内存泄漏或者程序崩溃。这篇文章适合几类人看一是正在用 FFmpeg 做播放器或者转码工具需要自己管理数据流的开发者二是在做视频分析、AI 推理前处理需要把网络流或者文件流解码成帧的工程师三是对底层数据处理感兴趣想搞清楚为什么不能直接把数据丢给解码器的技术爱好者。我会从实际场景出发把数据从缓存区到解码器的完整链路拆开讲包括每一步的设计理由、常见坑点、以及我自己踩过的那些教训。需要提前说明的是FFmpeg 的解码 API 在不同版本之间有一些变化比如avcodec_decode_video2在新版本里已经被标记为过时推荐使用avcodec_send_packet和avcodec_receive_frame这套新接口。但无论 API 怎么变数据从缓存区取出再写入解码器缓冲区这个核心逻辑是不变的。我会以当前主流的接口为主来讲同时在必要的地方说明新旧接口的差异。2. 解码前数据到底经历了什么从原始缓存到 AVPacket 的完整链路2.1 为什么不能直接把缓存区指针丢给解码器很多人第一次写解码代码的时候会有一个直觉我手里已经有一块内存里面存着从文件或者网络读来的压缩数据那我直接把这个指针传给解码函数不就行了吗理论上好像可以但实际不行。原因有几个层面。第一解码器需要的数据格式不是裸的内存块。FFmpeg 的解码接口接收的是AVPacket结构体这个结构体里除了数据指针和长度之外还包含时间戳PTS/DTS、流索引、标志位等元信息。如果你只传一个裸指针解码器就不知道这帧数据对应的时间点是什么也无法正确处理 B 帧的显示顺序。第二解码器可能需要对数据进行预处理或者对齐。某些硬件解码器要求输入数据按照特定的边界对齐或者要求数据前面带有特定的头信息。FFmpeg 在内部会做这些处理但前提是数据是通过 AVPacket 传进去的。第三引用计数和内存生命周期管理。AVPacket 支持引用计数机制这意味着你可以让多个 AVPacket 共享同一块底层数据而不需要每次都做深拷贝。如果你直接传裸指针就需要自己管理内存的释放时机很容易出现 use-after-free 或者内存泄漏。所以从缓存区到解码器之间必须有一个包装的过程。这个过程的核心就是把原始数据整理成 AVPacket然后通过解码 API 送进去。2.2 从缓存区读取数据时的分片问题实际场景中你手里的缓存区往往不是刚好一帧一帧对齐的。比如从网络收到的数据流可能一次收到多个帧的数据也可能一帧数据分了好几次才收全。这时候就需要一个分片和重组的逻辑。我通常的做法是维护一个环形缓冲区或者动态数组把收到的数据先追加进去然后根据 FFmpeg 的av_parser_parse2来切分帧。这个 parser 的作用就是根据码流格式比如 H.264 的 NAL 单元边界来判断一帧数据从哪里开始、到哪里结束。只有切分出一帧完整的数据之后才会构造 AVPacket 送给解码器。这里有一个很容易踩的坑parser 的输出不一定每次都能给你一帧完整数据。有时候你喂进去一批数据parser 告诉你我还需要更多数据这时候就不能急着构造 AVPacket。我见过有人在 parser 返回 0 的时候仍然强行构造一个空包送进解码器结果就是解码器报错或者输出花屏。正确的做法是循环调用 parser直到它消耗完所有输入数据并且只在 parser 输出有效帧数据的时候才构造 AVPacket。下面是一个简化的逻辑示意while (data_remaining 0) { int consumed av_parser_parse2(parser, codec_ctx, pkt_data, pkt_size, input_ptr, input_size, AV_NOPTS_VALUE, AV_NOPTS_VALUE, 0); if (pkt_size 0) { // 构造 AVPacket 并送入解码器 AVPacket *pkt av_packet_alloc(); av_packet_from_data(pkt, pkt_data, pkt_size); // 设置时间戳等元信息 // 送入解码器 } input_ptr consumed; input_size - consumed; }这段代码看起来简单但实际写的时候要注意av_packet_from_data会接管数据的所有权如果你后面还要复用这块内存就需要用av_packet_make_refcounted或者手动做拷贝。2.3 AVPacket 的构造引用计数还是深拷贝构造 AVPacket 的时候有两种方式一种是引用计数一种是深拷贝。这两种方式的选择直接影响性能和内存占用。引用计数的做法是让 AVPacket 直接指向你缓存区里的数据但不拥有这块内存。你需要自己保证在 AVPacket 被释放之前底层数据不会被修改或释放。这种方式的好处是零拷贝性能高适合高吞吐场景。坏处是生命周期管理复杂一旦出错就是难查的内存问题。深拷贝的做法是把数据复制到 AVPacket 自己的缓冲区里这样 AVPacket 完全拥有数据你原来的缓存区可以立即复用。好处是安全、简单坏处是多了一次内存拷贝在高分辨率高帧率场景下开销不可忽略。我的经验是如果是实时流处理优先考虑引用计数如果是离线转码或者对延迟不敏感的场景深拷贝更省心。FFmpeg 提供了av_packet_ref和av_packet_make_refcounted等函数来帮助管理这些逻辑但用的时候要仔细看文档因为不同版本的行为有差异。还有一个细节AVPacket 的data指针和buf字段是两回事。data指向实际的数据起始位置buf是引用计数的缓冲区管理结构。当你用av_packet_from_data的时候FFmpeg 会为你创建一个buf但前提是数据是用av_malloc分配的。如果你用的是自己的内存分配器就需要自己构造AVBufferRef。3. 把数据写入解码器缓冲区新旧接口的差异与选择逻辑3.1 旧接口 avcodec_decode_video2 的工作方式在比较老的 FFmpeg 版本里解码是通过avcodec_decode_video2这个函数完成的。它的签名大致是这样的int avcodec_decode_video2(AVCodecContext *avctx, AVFrame *picture, int *got_picture_ptr, const AVPacket *avpkt);这个函数的工作方式是你给它一个 AVPacket它尝试解码出一帧图像放到 AVFrame 里并通过got_picture_ptr告诉你是否成功解出一帧。如果数据不够它可能返回 0 并且got_picture_ptr为 0表示需要更多数据。这个接口的问题在于它把发送数据和接收帧两个动作耦合在一起了。你调用一次它可能消耗了 packet 的一部分数据也可能消耗了全部还可能一帧都没解出来。这种不确定性让上层逻辑很难写尤其是在处理 B 帧或者需要精确控制缓冲区的时候。另外这个接口不支持多线程解码的某些模式也不方便和硬件解码器配合。所以在新项目中我基本不再使用这个接口。3.2 新接口 send/receive 模型的设计哲学新接口把解码拆成了两个独立的步骤avcodec_send_packet把压缩数据送入解码器内部的缓冲区。avcodec_receive_frame从解码器内部取出解码后的帧。这种设计的好处是职责清晰。发送端只管送数据接收端只管取帧。解码器内部会维护自己的缓冲区你不需要关心它什么时候需要更多数据只需要按照 API 的返回值来判断下一步动作。具体来说avcodec_send_packet的返回值有几种情况返回值含义下一步动作0发送成功可以继续发送下一个 packet或者开始接收帧AVERROR(EAGAIN)解码器缓冲区满了必须先调用 receive_frame 取走一些帧AVERROR_EOF解码器已关闭不能再发送数据其他负值发送失败检查 packet 是否有效avcodec_receive_frame的返回值返回值含义下一步动作0成功取出一帧处理这一帧然后可以继续取AVERROR(EAGAIN)当前没有可输出的帧需要发送更多数据AVERROR_EOF所有帧已取完解码结束其他负值接收失败检查解码器状态这个模型的核心在于解码器内部有自己的缓冲区你不需要自己管理解码器需要多少数据这个问题。你只需要按照返回值来驱动循环就行了。3.3 发送 packet 时最容易忽略的返回值处理我见过很多代码在处理avcodec_send_packet返回值的时候只判断了 0 和非 0然后非 0 就报错退出。这是不对的。AVERROR(EAGAIN)不是一个错误而是一个信号告诉你解码器暂时吃不下更多数据了你得先取走一些帧。正确的处理逻辑应该是这样的int ret avcodec_send_packet(codec_ctx, pkt); if (ret AVERROR(EAGAIN)) { // 解码器缓冲区满先取帧 while (1) { ret avcodec_receive_frame(codec_ctx, frame); if (ret AVERROR(EAGAIN) || ret AVERROR_EOF) { break; } // 处理取出的帧 } // 然后再尝试发送 ret avcodec_send_packet(codec_ctx, pkt); } if (ret 0) { // 真正的错误 }这个循环逻辑看起来简单但实际写的时候很容易漏掉取完帧之后要重新发送这一步。我就在一个项目里因为漏了这一步导致某些关键帧被丢弃画面出现周期性卡顿。还有一个细节当你发送一个空 packetdata 为 NULLsize 为 0的时候表示告诉解码器没有更多数据了这时候解码器会进入 flush 模式把内部缓存的帧全部输出。这个机制在文件解码结束的时候特别有用因为有些帧可能还留在解码器内部没有输出。4. 解码器内部缓冲区满了怎么办EAGAIN 的处理与帧输出节奏4.1 解码器为什么会有内部缓冲区很多人会问我都已经把数据送进去了为什么解码器不立刻给我帧为什么还会有缓冲区满这种情况原因在于视频编码的帧间依赖。现代视频编码H.264、H.265、AV1 等大量使用 B 帧和参考帧机制。一个 B 帧的解码可能依赖于它前面的帧和后面的帧。所以解码器在收到一个 packet 之后不一定能立刻输出对应的帧它可能需要等待后续数据才能完成解码。另外解码器内部通常有一个帧重排序缓冲区。因为编码顺序和显示顺序可能不一致B 帧的存在解码器需要缓存若干帧然后按照正确的显示顺序输出。这个缓冲区的大小取决于编码参数通常是 2 到 16 帧不等。所以当你连续发送多个 packet 而一直没有调用 receive_frame 的时候解码器内部的缓冲区就会逐渐填满。一旦满了send_packet 就会返回 EAGAIN提醒你该取帧了。4.2 一个健壮的解码循环应该长什么样基于上面的分析一个健壮的解码循环应该同时处理发送和接收两个方向。我通常会把逻辑封装成一个函数输入是压缩数据输出是解码后的帧列表。核心循环如下// 发送阶段 int send_ret avcodec_send_packet(codec_ctx, pkt); if (send_ret 0 send_ret ! AVERROR(EAGAIN)) { // 处理错误 return send_ret; } // 接收阶段尽可能多地取帧 while (1) { int recv_ret avcodec_receive_frame(codec_ctx, frame); if (recv_ret AVERROR(EAGAIN)) { // 当前没有更多帧需要更多数据 break; } if (recv_ret AVERROR_EOF) { // 解码结束 break; } if (recv_ret 0) { // 处理错误 break; } // 成功取出一帧处理它 process_frame(frame); av_frame_unref(frame); }这个循环的关键在于每次发送 packet 之后都要尽可能地把解码器里已经准备好的帧全部取出来。不要等到下一次发送的时候才取因为那样可能导致解码器缓冲区溢出。4.3 帧输出节奏与时间戳的对应关系取出来的帧它的 PTS显示时间戳不一定和刚才发送的 packet 的 PTS 对应。因为 B 帧的存在输出顺序和输入顺序可能不同。这时候就需要依赖 AVFrame 里的pts字段来做同步。我遇到过一个典型问题在做一个视频播放器的时候画面总是比音频快或者慢半拍。排查后发现是因为我在取帧之后没有正确使用帧的 PTS 来做同步而是用了 packet 的 PTS。这两者在有 B 帧的情况下是不一样的。正确的做法是以 AVFrame 的 pts 为准来做音视频同步。如果你需要把帧按照显示顺序排列可以使用av_frame_get_best_effort_timestamp来获取一个尽量准确的时间戳。另外解码器输出的帧的pts可能是AV_NOPTS_VALUE这时候就需要根据帧率来推算。我通常会在解码器初始化之后根据codec_ctx-time_base和codec_ctx-framerate来建立一个时间戳推算逻辑作为兜底方案。5. 那些年我踩过的缓存区管理坑从内存泄漏到花屏的完整排查链路5.1 坑一av_packet_from_data 之后重复释放这是我最开始用 FFmpeg 的时候踩的坑。当时我的逻辑是从缓存区读数据用av_packet_from_data构造 AVPacket送进解码器然后手动av_packet_free释放。同时我还在外面释放了原始缓存区。结果就是 double free程序随机崩溃。原因在于av_packet_from_data会接管数据的所有权。当你调用av_packet_free的时候它会释放底层数据。如果你在外面又释放了一次就是双重释放。正确的做法是要么让 AVPacket 接管数据你不要再碰原始指针要么用av_packet_make_refcounted做一次拷贝让 AVPacket 拥有自己的副本。我后来统一改成了后者虽然多了一次拷贝但逻辑简单不容易出错。5.2 坑二parser 输出不完整帧导致解码器报错前面提到过 parser 的问题这里展开说一下。av_parser_parse2的输出pkt_size可能为 0这时候表示 parser 还在等待更多数据来组成一帧。如果你在pkt_size为 0 的时候仍然构造 AVPacket 送进解码器解码器会收到一个空包或者不完整的数据包结果就是报错或者输出花屏。我当时的排查过程是这样的先确认输入数据本身是完整的然后用日志打印每次 parser 的输入输出大小发现有些调用返回了 0。进一步检查发现是因为我在循环里没有正确处理consumed和input_size的关系导致有些数据被重复喂给 parser。修复方法很简单在循环里严格根据 parser 的返回值来推进输入指针并且在pkt_size 0的时候才构造 AVPacket。另外在文件结束的时候要调用一次 parser 的 flush 操作传入 NULL 数据把内部缓存的数据吐出来。5.3 坑三解码器 flush 不彻底导致尾帧丢失文件解码到最后的时候解码器内部可能还有几帧没有输出。这时候需要发送一个空 packet 来触发 flush。我见过有人在文件读完之后直接关闭解码器结果最后几帧就丢了。正确的做法是在输入数据全部发送完毕之后发送一个空 packetdata 为 NULLsize 为 0然后循环调用 receive_frame 直到返回 AVERROR_EOF。这样能保证所有缓存的帧都被取出来。这个坑在短视频场景下特别明显因为短视频的帧数少丢几帧可能就意味着丢了很大一部分内容。我后来养成了一个习惯不管什么场景解码结束的时候一定要做一次完整的 flush。5.4 坑四多线程解码时的缓冲区竞争FFmpeg 支持多线程解码可以通过设置codec_ctx-thread_count来开启。多线程能显著提升解码速度但也引入了缓冲区竞争的问题。我遇到过一次诡异的现象单线程解码完全正常开了多线程之后偶尔会出现花屏。排查后发现是因为我在多个线程里共享了同一个 AVPacket 或者 AVFrame而没有做同步。FFmpeg 的多线程解码内部有自己的同步机制但前提是你每个线程使用独立的 packet 和 frame。解决方案是每个解码线程使用独立的 AVPacket 和 AVFrame不要跨线程共享。如果确实需要共享数据用引用计数或者加锁来保护。6. 性能与稳定性的平衡缓冲区大小、对齐与内存分配策略6.1 缓冲区大小的选择依据缓冲区设多大这个问题没有标准答案但有几个参考因素。对于实时流缓冲区大小应该至少能容纳 2 到 3 帧的数据这样在网络抖动的时候不会立刻断流。对于 1080p 的 H.264 视频一帧压缩数据通常在 50KB 到 500KB 之间所以缓冲区至少设 1MB 比较稳妥。对于 4K 视频建议设到 4MB 以上。但缓冲区也不是越大越好。太大的缓冲区会增加内存占用而且在实时场景下会引入额外的延迟。我通常的做法是根据码率和网络状况动态调整缓冲区大小初始设一个保守值然后根据实际运行情况微调。6.2 内存对齐对解码性能的影响FFmpeg 的很多内部操作尤其是 SIMD 优化要求数据按照特定边界对齐。通常要求 32 字节或者 64 字节对齐。如果你传给解码器的数据没有对齐FFmpeg 可能会走非优化路径性能会下降。所以在分配缓存区的时候我建议使用av_malloc而不是标准的malloc因为av_malloc会自动做对齐处理。如果你必须用malloc那就要手动做对齐比如分配的时候多分配一些空间然后调整指针到对齐边界。6.3 引用计数与深拷贝的实测对比我在一个 1080p 60fps 的转码项目里做过对比测试。使用引用计数零拷贝的时候CPU 占用大约比深拷贝低 15% 到 20%。但在稳定性方面深拷贝明显更省心因为不需要担心生命周期问题。我的建议是如果你的团队对 FFmpeg 的内存模型非常熟悉可以用引用计数来榨取性能如果团队经验一般或者项目对稳定性要求极高深拷贝是更稳妥的选择。毕竟一次内存拷贝的开销在现代 CPU 上对于大多数场景来说是可以接受的。7. 写在最后一些个人体会解码这件事API 文档能告诉你怎么调用函数但不会告诉你什么时候会出问题。我这些年最大的体会是缓存区管理的问题往往不是出在不会用 API而是出在对数据流没有清晰的模型。你得清楚每一块内存在谁手里、什么时候被释放、谁拥有所有权。一旦这个模型清晰了大部分坑都能提前避开。另外日志真的很重要。我在解码流程的关键节点都会打日志parser 输入多少字节、输出多少字节、send_packet 返回值是什么、receive_frame 取到了几帧。这些日志在排查问题的时候能帮你快速定位是哪个环节出了偏差。最后分享一个小技巧如果你不确定解码器当前的状态可以在发送 packet 之前先调用一次avcodec_receive_frame把已经准备好的帧先取出来。这样能避免解码器缓冲区堆积也能让 send_packet 的成功率更高。这个习惯我保持了很多年实测下来很稳。
阅读完成 · 觉得有帮助？
