企业官网建设流程全解析

在调试某个播放器Demo时，我第一次被avcodec_find_decoder返回的NULL卡住了。当时手上有一份本地录制的视频文件，封装、时长、音视频流全都能正常读出来，偏偏到了解码这一步直接断掉。后来翻源码、查注册表，才意识到这一个函数背后牵着一整套编解码器注册机制，而很多人对它的理解只停留在"传个codec_id进去，返回解码器指针出来"，一旦遇到异常就完全无从下手。

这篇文章就围绕avcodec_find_decoder展开，讲清楚它到底是怎么工作的：函数本身的签名与参数来源、FFmpeg 注册表的查找机制、返回NULL的常见边界、拿到AVCodec之后真正的解码循环，以及它在软解/硬解场景中扮演的角色。适合刚接触 FFmpeg 的开发者，也适合已经会调用接口但对内部机制一知半解、想系统排查解码问题的朋友。文章最后还会分享我在实际项目中踩过的三个坑，都是靠这一层理解才定位到根因的。

1. 为什么解码链路的第一道门是avcodec_find_decoder

1.1 从容器到像素帧的完整链路

在正式开始讲解函数之前，先明确它在整个 FFmpeg 解码链路中的位置。你可以把一次标准的本地视频播放流程拆成下面这几个阶段：

其中，第一步拿到的是封装层的信息，比如codec_id、extradata、宽高、采样率这些；第六步的输入是压缩后的AVPacket；第七步输出的是可以拿去渲染的AVFrame。而avcodec_find_decoder处在解封装和解码引擎之间，它的唯一职责是：根据codec_id找到一个能够处理该编码格式的解码器描述对象。

简单说，解封装层告诉你"这段数据是 H.264 编码的"，avcodec_find_decoder就从 FFmpeg 内部的解码器注册表中找到那个叫h264的AVCodec条目。如果没有这一步，后面avcodec_open2根本不知道应该初始化哪一段解码逻辑。

1.2 AVCodec不是解码器实例，而是"解码器简历"

有一个观点我每次都要强调：avcodec_find_decoder返回的AVCodec指针，并不是一个可用的解码器实例，它更像是一份"解码器简历"。简历上写明了这个解码器叫什么名字（name）、对应哪种编码格式（id）、是视频还是音频（type）、具备什么能力（capabilities）、支持哪些像素/采样格式（pix_fmts/sample_fmts）等等。

真正的解码状态、内部缓冲、线程配置都保存在AVCodecContext里。二者的关系可以类比成：

• AVCodec是身份证，描述"这个人是谁、有什么资质"；
• AVCodecContext是正在驾驶的车，记录"当前车速、油量、行驶路线"。

所以avcodec_find_decoder找到AVCodec之后，常规操作是立刻调用avcodec_alloc_context3(codec)分配一个AVCodecContext，再把文件里的参数搬运进去。两个结构不要混用——很多人把AVCodec当作"解码器对象"直接调函数，这是概念性的错误。

FFmpeg 之所以把静态描述和动态状态分开，是因为同一个解码器可以同时被多个线程使用：多个AVCodecContext可以共享同一个AVCodec描述，各自维护独立状态。这也是为什么注册表里的AVCodec可以被反复查找而不需要复制、不需要释放。

2. 函数签名与codec_id：一个参数决定成败

2.1 AV_CODEC_ID不是随便填的

先看函数原型：

const AVCodec *avcodec_find_decoder(enum AVCodecID id);

在较新的 FFmpeg 版本里，返回类型是const AVCodec *。它只接收一个参数：enum AVCodecID类型的编码格式 ID。注意，这个参数不是字符串，而是一个枚举值，定义在libavcodec/avcodec.h中。

常见的codec_id和对应解码器名称如下：

这个枚举值必须和实际编码数据匹配。如果传进去一个"看起来差不多"的 ID，比如把 H.264 数据当成AV_CODEC_ID_MPEG4，avcodec_find_decoder照样会返回一个非空指针，但后面的avcodec_open2或者解码阶段大概率会报错，出来的画面也往往是花屏或者直接EINVAL。

2.2 三种获取codec_id的典型路径

大部分场景下，codec_id不是你想当然填进去的，而是从数据源里读出来的。

第一种情况是有封装格式的文件，也就是最常见的mp4、mkv、flv、ts文件。拿到AVFormatContext之后，遍历streams，从每个AVStream的codecpar字段读取codec_id：

AVFormatContext *fmt_ctx = NULL; avformat_open_input(&fmt_ctx, filename, NULL, NULL); avformat_find_stream_info(fmt_ctx, NULL); for (int i = 0; i < fmt_ctx->nb_streams; i++) { AVStream *st = fmt_ctx->streams[i]; const AVCodec *dec = avcodec_find_decoder(st->codecpar->codec_id); // 在这里根据 st->codecpar->codec_type 区分音视频 }

有一个老旧 API 的坑必须提醒：早期 FFmpeg 里常见st->codec这种写法，现在这个字段已经不建议直接访问了，正确路径是st->codecpar。如果你在网上翻到旧教程还在用st->codec，请先检查版本，否则很可能编译报错或者读取到过时数据。

第二种情况是裸流，比如一段纯 H.264 的annexb格式数据。这时没有容器帮你写出codec_id，你自己必须知道这段数据是什么编码，直接指定：

const AVCodec *dec = avcodec_find_decoder(AV_CODEC_ID_H264);

第三种情况是某些私有封装或者自定义协议，内部存储了一个标志位，你需要按自己的映射规则推断出对应的codec_id。这种场景通常出现在硬件设备、录播系统等定制项目中。

2.3 传错ID的连锁反应

很多新手以为avcodec_find_decoder返回非空就万事大吉，其实这只是第一关。传错 ID 的后果往往是延迟爆发的：

• 如果 ID 对应某种完全不同的视频编码，返回的解码器大概率在avcodec_open2阶段就报错；
• 如果两种编码的codec_id相近但数据格式不同，可能在send_packet时返回EINVAL；
• 最隐蔽的情况是某些解码器比较宽容，初始化成功，但解码出来的帧是花屏、绿屏，查找阶段没有任何报错。

排查时一定要先确认你的codec_id来源是否正确，不要想当然。一个通用做法是：凡是播放本地文件或网络流，都走codecpar读取；只有自己处理裸流时，才手动指定 ID。

3. 注册表机制拆解：它如何在几十种解码器里找到目标

3.1 FFmpeg怎么把几十种解码器组织起来

avcodec_find_decoder内部做的事情，本质上是一次线性查找。FFmpeg 在库加载时（新版甚至不需要手动调用av_register_all）会把所有内置编解码器组织成一张注册表，函数则从这张表里逐个比对codec_id。

具体的遍历实现是通过av_codec_iterate完成的，每次返回注册表中的一个AVCodec。avcodec_find_decoder的伪逻辑可以理解为：

const AVCodec *dec = NULL; void *opaque = NULL; while ((dec = av_codec_iterate(&opaque))) { if (dec->id == id && /* 确认这是解码器而非编码器 */) { return dec; } } return NULL;

这里有一个细节：FFmpeg 的注册表把编码器、解码器放在同一个AVCodec结构体体系里。查找解码器时，除了比对id，还需要确认这个条目确实具备解码能力。在旧版本中，可以通过dec->decode回调函数是否存在来判断；在新版本中，解码实现被移到了内部结构，外部只需要关注函数行为即可。

为什么是线性查找而不是哈希表？因为在几乎所有实际场景中，注册表里的编解码器数量也就几十到一两百个，线性遍历的开销微乎其微。相比之下，维护一个复杂的索引结构反而不值得。所以avcodec_find_decoder的函数本身很轻，真正需要关注的是注册表里有没有你想要的条目。

3.2 编译裁剪：最容易被忽略的隐形杀手

注册表的内容不是一成不变的，它取决于 FFmpeg 编译时的配置。很多发行版、商用 SDK 为了减小体积，会裁剪掉大量用不到的编码器。举例来说，如果编译时的配置是：

./configure --disable-everything --enable-decoder=h264

那么注册表里可能就只剩 H.264 解码器，甚至连mp3、aac都没有。此时avcodec_find_decoder(AV_CODEC_ID_AAC)返回NULL是完全正常的。

遇到这种问题，自查顺序建议是这样：

1. 命令行执行ffmpeg -decoders，看这个库编译进解码器列表，里面有没有你需要的条目；
2. 执行ffmpeg -buildconf，确认编译选项是否有类似--disable-decoder=xxx的裁剪；
3. 如果确实没有，就需要换一个包含该解码器的动态库，或者重新编译 FFmpeg，打开对应选项。

这部分问题往往特别隐蔽：程序源代码完全正确，codec_id也传对了，但就是返回NULL。我见过不止一个项目在换了库版本之后突然解码失败，最后追根溯源都是编译配置变了。

3.3 自定义解码器如何进入查找表

有些场景 FFmpeg 内置的解码器满足不了需求，比如某个硬件厂商的私有视频编码格式。此时就需要把自己实现的解码器注册进这张表。在较老的 FFmpeg 版本里，可以调用avcodec_register动态注册一个自定义的AVCodec；但新版对内部结构做了不少调整，更推荐的做法是把自定义解码器写进 libavcodec 的源码目录，然后在allcodecs.c的codec_list中登记。

这已经超出了日常 API 使用的范畴，更像是在改 FFmpeg 本身。如果你的项目确实需要这样做，建议找一个已有的简单解码器源码作为模板，对照你所用 FFmpeg 版本的AVCodec结构体定义来实现。需要提醒的是，自定义解码器虽然注册表，但编码格式 ID 往往也要自己定义或者复用一个未使用的枚举值，否则codec_id同样对不上。

4. 返回值NULL与边界：排查清单比函数本身更重要

4.1 返回值为空时的定向排查

avcodec_find_decoder返回NULL，通常只有以下几类原因。把它们列出来逐一比对，排查效率会高很多：

我特别想强调第一类：codec_id传成AV_CODEC_ID_NONE。很多人在处理裸流时忘了给codecpar赋值，直接从空结构的codecpar里读codec_id，读出来就是个 0，自然找不到。打印一下这个值，问题一眼就清楚。

4.2 返回指针的生存期与线程安全

avcodec_find_decoder返回的指针指向注册表内部的对象，不需要释放。它既不是av_malloc分配的堆内存，也不是某个AVCodecContext的内部对象，而是库初始化时早就准备好的静态描述。强制执行av_free之类的操作反而可能导致崩溃。

线程安全方面，avcodec_find_decoder本身只做只读查找，可以放心在多线程环境中使用。但要注意的是，如果程序里某个线程在初始化过程中还依赖旧版av_register_all手动注册逻辑，不同线程之间可能出现初始化时序问题。新版 FFmpeg 已经自动初始化注册表，这种坑基本不存在了。

另一个容易被忽略的点：查找到的AVCodec指针可以在多个AVCodecContext之间共享。你完全可以对同一个AVCodec调用多次avcodec_alloc_context3，每个线程各拿一个上下文，互不干扰。

4.3 解码器能力标志：读懂capabilities

返回的解码器指针里有一个capabilities字段，是位掩码。虽然大多数情况下不用手动处理它，但它能帮你理解解码器的一些异常行为。常见的标志有：

• AV_CODEC_CAP_DELAY：解码器内部有帧缓冲。典型表现为 B 帧场景下，avcodec_receive_frame不会立刻返回所有帧，最后必须发送空包flush，把缓冲里的帧全部逼出来。
• AV_CODEC_CAP_DR1：解码器支持用户提供缓冲区。老版本中这个标志很重要，新版本的编码/解码循环不再强调。
• AV_CODEC_CAP_AVOID_PROBING：解码器不需要额外探测就可以直接使用，比如某些能自解析码流头的解码器。

当作一个背景知识来了解即可。真正排查问题时，如果你发现 H.264 或者 H.265 解码到了末尾还有几帧卡住出不来，十有八九就是DELAY标志在起作用，需要做flush处理。

5. 拿到AVCodec之后：完整解码循环的落地细节

5.1 参数搬运：avcodec_parameters_to_context

找到AVCodec只是第一步，接下来要把流参数从codecpar拷贝到AVCodecContext。这一步很多教程直接跳过，但实际项目中如果不做，解码器打开后可能因为缺少extradata、宽高、采样率等关键信息而失败。

推荐的复制方式是调用现成函数：

AVCodecContext *ctx = avcodec_alloc_context3(codec); if (!ctx) { // 处理分配失败 } AVStream *st = fmt_ctx->streams[stream_index]; int ret = avcodec_parameters_to_context(ctx, st->codecpar); if (ret < 0) { // 参数拷贝失败 }

avcodec_parameters_to_context会自动处理extradata、codec_type、width、height、sample_rate、channels、channel_layout等一整套字段。手动逐个赋值很容易漏掉某个关键项，尤其是extradata，那个字段携带的是 SPS/PPS 这类解码必需的信息，漏了之后解码器不是直接报错，而是悄悄启用一个默认值，最后输出花屏，极其难查。

拷贝完成之后，调用：

ret = avcodec_open2(ctx, codec, NULL); if (ret < 0) { char errbuf[AV_ERROR_MAX_STRING_SIZE] = {0}; av_strerror(ret, errbuf, sizeof(errbuf)); // 根据 errbuf 提示处理 }

这里第三个参数可以传入字典项来设置额外的解码选项，比如低延迟、跳过参考帧等，日常开发先传NULL即可。

5.2 send/receive模型：完整解码循环示例

从 FFmpeg 3.1 开始，官方推荐统一使用avcodec_send_packet和avcodec_receive_frame这套 send/receive 模型，旧的avcodec_decode_video2已经被废弃。新模型的核心思想是：把压缩包送入解码器，然后循环去取解码结果，直到取不到为止。

一个典型的裸流解码到 YUV420P 的简化示例：

#include <stdio.h> #include <stdlib.h> #include <libavcodec/avcodec.h> #include <libavutil/imgutils.h> int main(void) { FILE *fin = fopen("input.h264", "rb"); FILE *fout = fopen("output.yuv", "wb"); if (!fin || !fout) { return -1; } const AVCodec *codec = avcodec_find_decoder(AV_CODEC_ID_H264); if (!codec) { fprintf(stderr, "H.264 decoder not found\n"); return -1; } AVCodecContext *ctx = avcodec_alloc_context3(codec); if (!ctx) { return -1; } // 裸流场景下，如果码流里自带 SPS/PPS 且 format 是 annexb， // 多数情况下可以直接 open，否则需要从外部设置 ctx->extradata ctx->codec_id = AV_CODEC_ID_H264; ctx->pix_fmt = AV_PIX_FMT_YUV420P; // 让解码器尽量以 YUV420P 输出 if (avcodec_open2(ctx, codec, NULL) < 0) { fprintf(stderr, "open decoder failed\n"); return -1; } AVPacket *pkt = av_packet_alloc(); AVFrame *frame = av_frame_alloc(); uint8_t *buf = malloc(4096); size_t len = 0; while ((len = fread(buf, 1, 4096, fin)) > 0) { pkt->data = buf; pkt->size = (int)len; int ret = avcodec_send_packet(ctx, pkt); if (ret < 0) { fprintf(stderr, "send packet failed\n"); break; } while (ret >= 0) { ret = avcodec_receive_frame(ctx, frame); if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF) { break; } if (ret < 0) { fprintf(stderr, "receive frame failed\n"); break; } // 按 YUV420P 逐行写入，实际项目中通常用 av_image_copy_to_buffer for (int i = 0; i < frame->height; i++) { fwrite(frame->data[0] + i * frame->linesize[0], 1, frame->width, fout); } int half_w = frame->width / 2; int half_h = frame->height / 2; for (int i = 0; i < half_h; i++) { fwrite(frame->data[1] + i * frame->linesize[1], 1, half_w, fout); } for (int i = 0; i < half_h; i++) { fwrite(frame->data[2] + i * frame->linesize[2], 1, half_w, fout); } } } // flush：让解码器把缓冲中的剩余帧输出 avcodec_send_packet(ctx, NULL); while (avcodec_receive_frame(ctx, frame) >= 0) { // 处理最后几帧，这里省略写文件 } free(buf); av_frame_free(&frame); av_packet_free(&pkt); avcodec_free_context(&ctx); fclose(fin); fclose(fout); return 0; }

这段代码的核心逻辑有三层：

1. 送包：avcodec_send_packet接收压缩数据。如果返回AVERROR(EAGAIN)，说明解码器内部缓冲区满，必须先收帧；
2. 收帧：avcodec_receive_frame每次取出一帧。返回AVERROR(EAGAIN)表示需要继续送包，返回AVERROR_EOF表示所有帧已经取完；
3. flush：解码器存在延迟缓冲，特别是含有 B 帧的视频流，必须在码流结束后发送一个空包，循环接收剩余帧。

为什么这套模型设计成"送一个包、取多帧"？因为视频编码里有帧重排：一个 I 帧可能依赖后面的 P 帧在时间戳上的顺序，解码器内部需要等待多个包之后才能输出完整帧。旧的解码 API 是输入一个包立刻输出一帧，那个模型在处理 B 帧和线程解码时非常别扭。send/receive 本质上把调度权和内部缓冲交还给了解码器自己，对调用方更友好。

5.3 时间戳与引用计数

解码循环里还有两个细节值得单独拎出来说。

第一是时间戳管理。从容器里读到的AVPacket自带pts和dts，送到解码器之后，AVFrame里的pts会被保留下来。如果你的播放器要做音画同步，必须在解码后依赖帧的pts为准，而不是自己重算。如果源包的pts是空的，解出来的帧也会没有pts，这时候展示帧就可能跳动。

第二是引用计数。AVPacket、AVFrame都采用引用计数的内存管理方式。用完之后需要调用av_packet_unref或av_frame_unref来释放引用，而不是直接free。示例代码里因为是简单复用一个packet，每次循环前最好显式调用av_packet_unref(pkt)来清理内部可能持有的数据，避免内存泄漏和缓冲区越界。

6. 软解与硬解：avcodec系列函数在硬件加速中的角色

6.1 默认查到的多是软件解码器

一个常见的疑问是：avcodec_find_decoder能不能直接返回硬件解码器，比如 CUDA、VAAPI、MediaCodec？严格来说，FFmpeg 的注册表里软解和硬解都注册为AVCodec，但avcodec_find_decoder按codec_id查找时，通常匹配到的是默认的软件实现。你后续如果不做任何特殊处理，解码就会跑在 CPU 上。

现代播放器想走硬解，绝不是换个查表函数就能解决的，而是要理解 FFmpeg 的硬件加速上下文机制：AVCodecContext里有一个hw_device_ctx字段，挂上硬件设备之后，解码器内部才有机会使用对应的硬件接口。

6.2 通过hw_device_ctx启动硬解

基本流程可以分三步：

1. 创建硬件设备上下文，比如AV_HWDEVICE_TYPE_VAAPI；
2. 把这个上下文挂到AVCodecContext->hw_device_ctx；
3. 打开解码器，框架内部会根据解码器声明的硬件配置，自动选择硬解路径。

一个简化示例：

#include <libavutil/hwcontext.h> AVBufferRef *hw_device_ctx = NULL; int ret = av_hwdevice_ctx_create(&hw_device_ctx, AV_HWDEVICE_TYPE_VAAPI, NULL, NULL, 0); if (ret < 0) { // 创建 VAAPI 设备失败，可以回退到软解 } ctx->hw_device_ctx = av_buffer_ref(hw_device_ctx); if (avcodec_open2(ctx, codec, NULL) < 0) { // 硬解初始化失败，仍然需要回到软解路径 }

如果你想进一步确认当前解码器是否支持某类硬件，可以使用avcodec_get_hw_config遍历解码器声明的硬件配置：

const AVCodecHWConfig *hw_config = NULL; for (int i = 0; (hw_config = avcodec_get_hw_config(codec, i)) != NULL; i++) { if (hw_config->methods & AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX) { // 说明可以通过 hw_device_ctx 方式使用该硬件类型 // hw_config->device_type 可以进一步判断设备类型 } }

各平台常见的硬件设备类型如下：

这里不展开每种设备的具体配置，只是想强调一点：不要指望avcodec_find_decoder自己"返回"一个硬解解码器。硬解是通过hw_device_ctx在 open 阶段动态触发的。查找解码器的工作永远是同一个函数，区别在于你给上下文挂了多少辅助信息。

6.3 什么情况下需要avcodec_find_decoder_by_name

除了按codec_id查找，FFmpeg 还提供了一个按名字查找的函数：

const AVCodec *codec = avcodec_find_decoder_by_name("h264_cuvid");

从名字能看出来，这种查找是精确到具体实现实例的。当你明确知道目标平台上某个硬件解码器的名称时，可以用它直接拿到对应AVCodec。典型场景包括：

• 在 Android 上指定使用h264_mediacodec或hevc_mediacodec；
• 在 Linux 上指定使用h264_vaapi；
• 在 NVIDIA 环境指定使用h264_cuvid。

注意这里有个前提：你的 FFmpeg 库编译时确实启用了对应组件。查询方式和前面一样，用ffmpeg -decoders看列表，如果名字没出现，那avcodec_find_decoder_by_name必然返回NULL。

用by_name拿到的AVCodec，后续流程和普通解码器完全相同：分配上下文、拷贝参数、打开、send/receive。唯一不同的是，它不再依赖codec_id匹配，而是依赖你传入的名字字符串。这种写法更"硬"，换平台时必须手动处理平台差异，一般不建议作为默认策略。

7. 三个真实踩坑复盘：花屏、私有ID与性能误区

7.1 花屏的真凶：extradata没搬运

之前接到一个模拟项目的问题：本地视频文件能正常读到流信息，流信息里明确写着AV_CODEC_ID_H264，avcodec_find_decoder返回的指针也是非空，avcodec_open2也成功，但解码出来的画面从头到尾都是花屏。

排查过程走了一段弯路：先怀疑是码流本身损坏，然后用命令行工具去播放同一个文件，发现能正常显示。接着怀疑是像素格式转换问题，打印frame->width、frame->height、frame->format全都正常。最后把codecpar里的字段逐项和ctx里的字段对比，才发现extradata是空的。

问题就出在一个不严谨的初始化方式上：当时为了省事直接手动设置了ctx->codec_id、ctx->width、ctx->height，没有调用avcodec_parameters_to_context，而extradata正是 H.264 解码器解析 SPS/PPS 的关键数据源。缺失之后，解码器虽然没有直接报错，但各路参数全靠猜，画面自然全乱。

这件事让我养成了一个习惯：只要手上有AVCodecParameters，就不要手动赋值，直接用avcodec_parameters_to_context。它一次性覆盖所有字段，比手工实现更可靠。

7.2 私有编码ID查不到解码器

另一个项目里用到了一个非标准的私有视频编码格式，数据源来自某硬件设备。硬件的 SDK 文档写明编码 ID 是一个自定义枚举值。我在程序里直接调用：

const AVCodec *codec = avcodec_find_decoder(MY_CUSTOM_CODEC_ID);

结果返回NULL。当时第一反应是 ID 写错了，反复核对后发现 ID 没问题，那就是注册表里根本没有这个解码器。FFmpeg 默认只包含开源世界里常见的编码格式，自定义格式的解码器如果你不编译进去，运行时肯定是找不到的。

正确做法是把自己实现的解码器作为模块编进 libavcodec，并在codec_list里登记。这样avcodec_find_decoder才能在遍历注册表时看到它。如果你只是有一个解码库的动态库接口，想在不改 FFmpeg 源码的前提下接入，那就不能用这个函数，而是要在业务层做一个映射：自己维护一张"编码 ID 到解码函数"的散列表。这两种方案各有利弊，但不要以为 FFmpeg 能奇迹般地识别你的私有格式。

7.3 每个packet都重新查找解码器

还有一个性能上的反面教材。某次负责走查团队里的一个转码模块，发现avcodec_find_decoder被放在了while (av_read_frame(...))的循环体内部。也就是说，每读到一个包，就重新查一遍注册表、重新avcodec_alloc_context3、重新avcodec_open2，然后再发一个包、收一帧，紧接着把上下文释放掉。

这个写法最直接的问题是：反复创建和销毁AVCodecContext会带来不必要的内部缓冲分配与释放，CPU 占用凭空高出不少；而解码器查找这个动作本身虽然只是遍历几十个条目，开销不大，但没有必要执行上千次。

正确姿势是：

原则上，所有初始化性质的操作都应该放在解码开始之前完成，解码循环里只做送包和收帧两件事。这个基本的生命周期意识，能让你的模块扩展性、可维护性都上一个台阶。

我个人的体会是，avcodec_find_decoder这个函数本身简单得不能再简单，但它的地位特殊，处于"容器信息"和"解码引擎"之间的转换点。遇到解码类问题，别急着怀疑深层逻辑，先按这个顺序自查：codec_id对不对、编译配置够不够、extradata搬没搬全。这三关过了，大多数问题其实已经暴露出来了。如果还想继续深入，下一步可以研究avcodec_send_packet的EAGAIN语义、flush时机，以及AVFrame的引用计数细节，这套链路吃透了，FFmpeg 的解码部分基本就没什么秘密了。