做音视频开发这几年，我越来越觉得：想真正弄懂播放器，与其去啃一大堆框架代码，不如从零开始用 FFmpeg 把播放流程串一遍。这个标题里写的“基于FFmpeg4.1的视频播放器的极简实现”，就是我当时学习笔记的第四篇，核心目标只有一个——用最少的代码，把视频文件从打开、解码到显示这一整条链路跑通。今天把整个实现思路、关键 API 用法、踩过的坑重新整理一遍，给正准备入门音视频的朋友一份可以照着抄的作业。
1. 设计思路：拆开播放器这个“黑盒”
1.1 极简播放器到底简到什么程度
很多人第一次接触播放器，看到的是一个能拖进度条、能切音轨、能调整字幕的复杂软件，下意识会觉得这东西高不可攀。但极简实现的意义，恰恰是帮你把播放器“去魅”——用最朴素的逻辑把它还原成一个数据流搬运过程。
我当时给自己定的边界很简单：输入一个本地视频文件，能出画面，能出声（或者至少能出画面），不做暂停、拖动、倍速，不做滤镜特效，不处理字幕，不搞复杂的音视频同步算法，最多再加一个退出按键。所有代码加起来，主文件控制在两百行上下。这个范围足够覆盖播放器最核心的骨架，又不会让初学者被大量细节淹没。
这个极简版本把“播放器”拆成了四件事：读文件、解封装、解码、渲染。对应到 FFmpeg 的术语就是：AVFormatContext 负责解封装，AVCodecContext 负责解码，SwsContext/SDL 负责画面转换和显示。理解了这四个模块怎么协作，后面再学任何播放器框架，都能快速定位它处理的是哪一个环节。
1.2 为什么选 FFmpeg 4.1 和 SDL2 组合
标题里特意写了 FFmpeg 4.1，因为这是一个很有代表性的版本：它处于旧 API 向新 API 过渡的稳定期。4.0 之前很多教程里还在用av_register_all()，而 4.1 开始旧 API 已经慢慢被清理，成了很多教程默认的教学版本。选这个版本，既能避开远古写法，又不会遇到太新的接口变动，学习资料也容易对齐。
渲染端选了 SDL2，理由更实际：它足够简单，跨平台，而且和 FFmpeg 配合得非常自然。SDL 里SDL_UpdateTexture可以直接接收解码器输出的 YUV 数据，省去了格式转换的麻烦。如果自己写渲染，光是 YUV 到 RGB 的转换就得处理一堆边界条件。
注意：FFmpeg 4.x 之后，解封装和解码都统一走
AVFormatContext/AVCodecContext，不再像老版本那样在AVStream里直接挂 codec 指针。如果你翻到特别老的博客，看到avcodec_decode_video2这类函数，心里要有数——那是上一个时代的写法了。
1.3 整个播放流程的数据流：从文件路径到屏幕像素
极简播放器的数据流，可以画成一条直线，中间没有分支：
文件路径 -> AVFormatContext (解封装得到AVPacket) -> AVCodecContext (解码得到AVFrame) -> SwsContext/SDL纹理 (得到可显示像素) -> 屏幕窗口这条链路里有两个容易被忽略的“换乘站”。第一个是 AVPacket 到 AVFrame：包是压缩后的编码数据，帧是解码后的原始像素数据，两者类型完全不同。第二个是 AVFrame 到屏幕：解码器输出的通常是 YUV420P，而屏幕窗口需要的是能被 SDL 直接拷进去的纹理，中间要做一次格式对齐。
很多人写播放器卡住，就是因为没分清楚这几个结构的定位，把 AVPacket 当 AVFrame 用，或者没注意linesize就盲目地把帧数据拷贝到纹理里，结果画面出现奇怪的花纹。后面实操章节我会专门讲这个。
2. 核心 API 拆解：每个函数背后在做什么
2.1 打开文件与探测流信息：avformat_open_input 的双重身份
第一步是打开文件，代码很简洁：
AVFormatContext *fmt_ctx = NULL; int ret = avformat_open_input(&fmt_ctx, filename, NULL, NULL); if (ret < 0) { // 错误处理 } ret = avformat_find_stream_info(fmt_ctx, NULL);很多人以为avformat_open_input只是“打开文件”，其实它干了两件事：打开文件，然后通过文件头猜出封装格式。FFmpeg 内部会逐个探测解复用器，这也是它能自动识别 MP4、MKV、FLV、TS 的原因。第二个参数给 NULL，代表让 FFmpeg 自己猜；如果你明确知道格式，也可以传入指定值，但绝大多数场景没这个必要。
真正花时间的其实是avformat_find_stream_info。这个函数会读取一小段数据，分析流信息，把每个流的编码类型、分辨率、帧率、时长等信息填进AVStream。它读的数据量受probesize和analyzeduration控制，默认值对本地文件足够。如果是网络流卡住，通常要调这两个参数，否则可能等很久。极简版本里直接用默认值就好。
2.2 解码器上下文：codecpar 到 AVCodecContext 的正确姿势
找到视频流之后，要拿到流的编码参数，并创建解码器上下文：
int video_stream_index = av_find_best_stream(fmt_ctx, AVMEDIA_TYPE_VIDEO, -1, -1, NULL, 0); AVStream *video_stream = fmt_ctx->streams[video_stream_index]; AVCodecParameters *codecpar = video_stream->codecpar; const AVCodec *decoder = avcodec_find_decoder(codecpar->codec_id); AVCodecContext *codec_ctx = avcodec_alloc_context3(decoder); avcodec_parameters_to_context(codec_ctx, codecpar); avcodec_open2(codec_ctx, decoder, NULL);这里有一个非常关键的细节：AVStream结构体里已经没有直接可用的codec字段了，必须通过AVCodecParameters中转。codecpar负责描述编码参数，codec_ctx负责实际解码状态，二者通过avcodec_parameters_to_context关联。
参数里有几个字段特别容易踩坑。codec_id决定找哪个解码器，少数文件会标注成AV_CODEC_ID_NONE，导致avcodec_find_decoder返回 NULL。extradata对 H.264/H.265 这种需要 SPS/PPS 的编码很关键，拷贝参数时一定不能丢。codec_tag偶尔会干扰解码器选择，如果遇到解码失败，可以先把它忽略试试。
2.3 帧读取与解码：send/receive 模型的正确用法
FFmpeg 3.x 之后统一推荐avcodec_send_packet+avcodec_receive_frame这套接口，4.1 已经完全弃用了旧的avcodec_decode_video2。新接口的好处是把“喂数据”和“取数据”分开，更贴近现代编解码器的缓冲模型。
AVPacket *pkt = av_packet_alloc(); AVFrame *frame = av_frame_alloc(); while (av_read_frame(fmt_ctx, pkt) >= 0) { if (pkt->stream_index == video_stream_index) { int ret = avcodec_send_packet(codec_ctx, pkt); if (ret == 0) { while (avcodec_receive_frame(codec_ctx, frame) == 0) { // 拿到一帧解码后的数据，可以渲染了 render_frame(frame); } } } av_packet_unref(pkt); } // 解码器刷尾 avcodec_send_packet(codec_ctx, NULL); while (avcodec_receive_frame(codec_ctx, frame) == 0) { render_frame(frame); }这段代码有几个容易忽略的地方。第一，av_read_frame返回的是 AVPacket，它不一定只包含视频，音频、字幕也会混在里面，所以要用stream_index做过滤。第二，avcodec_send_packet成功不代表立刻有帧输出，必须配合avcodec_receive_frame循环取，直到它返回AVERROR(EAGAIN)表示数据还不够解码一帧。
第三点是很多人不知道的：当文件读到结尾，解码器内部可能还残留着若干帧（尤其是 B 帧较多的视频）。这时候必须调用avcodec_send_packet(codec_ctx, NULL)发送空包，触发 flush，然后再循环取帧，否则视频会少掉最后几帧。
2.4 时间基换算：pts 到底怎么对齐
AVPacket 和 AVFrame 里都有一个pts字段，但这东西不是秒，不是毫秒，而是一个“计数单位”。要换算成真正的时间，必须依赖流的时间基time_base。
double time_sec = av_q2d(video_stream->time_base) * frame->pts;时间基的本质就是一个分数，av_q2d 把AVRational转成浮点数。比如time_base = {1, 1000}，说明一个单位等于千分之一秒，此时 pts = 33000 就代表第 33 秒。不同封装格式时间基千差万别，MP4 常见1/1000、1/90000，MKV 常出现1/1000，TS 流是1/90000。
如果你直接拿两个不同流的 pts 相减，或者拿它跟系统秒表对比，十有八九算出来的速度是错的。这就是播放过快/过慢问题最常见的根源。极简版本里，同步算法全靠这个换算打底，换算对了，后面才谈得上控制节奏。
2.5 像素格式与 linesize：解码器输出的原始数据长什么样
解码器输出的 AVFrame 数据，对新手来说是重灾区。视频解码通常输出 YUV420P（在 FFmpeg 里对应AV_PIX_FMT_YUV420P），包含 Y、U、V 三个平面。Y 平面存亮度，U/V 平面存色度，U/V 的分辨率只有 Y 的一半。
如果你从 AVFrame 的data[0]、data[1]、data[2]里取数据，直接拿去组装 RGB 像素，通常会得到一张颜色错乱甚至撕裂的图。原因之一是linesize：视频帧每一行的实际字节数往往大于逻辑宽度，因为内存要对齐。所以拷贝数据时必须按linesize一行一行处理，不能把 Y 平面当成“宽度 x 高度”的连续内存块。
这就是为什么极简播放器里，我们选择把 SDL 纹理直接建成 IYUV 格式，用SDL_UpdateTexture把三个平面的指针和 pitch 传进去。SDL 自己认识 YUV420P 的布局，不需要你手动转 RGB，省掉一大半麻烦。只有当目标格式不是 YUV 时才需要引入sws_scale。
3. 实操实现：敲出一个能跑的极简播放器
3.1 工程准备：头文件、链接库和项目结构
先准备一个最小工程目录：
minimal_player/ ├── main.c └── Makefile (或者直接手敲gcc命令)main.c里需要的头文件如下：
#include <stdio.h> #include <libavformat/avformat.h> #include <libavcodec/avcodec.h> #include <libavutil/imgutils.h> #include <SDL.h>编译时链接的库取决于你的系统。类 Linux 系统通常是：
gcc -o player main.c $(pkg-config --cflags --libs libavformat libavcodec libavutil libswscale sdl2)如果你手动安装的 FFmpeg，头文件在/usr/local/include，库在/usr/local/lib，编译命令要补上-I和-L，并且记得加-lm。这一步很多人卡在头文件找不到，先确认一下 FFmpeg 装到了哪里，别一上来就抱怨代码有问题。
3.2 核心代码骨架：打开、解码、渲染一条龙
我会把核心流程按顺序贴出来，注释尽量写明白。为了保持“极简”，只保留视频部分。
#include <stdio.h> #include <libavformat/avformat.h> #include <libavcodec/avcodec.h> #include <libavutil/imgutils.h> #include <SDL.h> int main(int argc, char *argv[]) { if (argc < 2) { fprintf(stderr, "usage: %s <video file>\n", argv[0]); return 1; } const char *filename = argv[1]; // 1. 打开文件并探测流信息 AVFormatContext *fmt_ctx = NULL; if (avformat_open_input(&fmt_ctx, filename, NULL, NULL) < 0) { fprintf(stderr, "cannot open file\n"); return 1; } if (avformat_find_stream_info(fmt_ctx, NULL) < 0) { fprintf(stderr, "cannot find stream info\n"); return 1; } // 2. 找到视频流 int video_stream_idx = av_find_best_stream(fmt_ctx, AVMEDIA_TYPE_VIDEO, -1, -1, NULL, 0); if (video_stream_idx < 0) { fprintf(stderr, "no video stream\n"); return 1; } AVStream *video_stream = fmt_ctx->streams[video_stream_idx]; // 3. 创建解码器 const AVCodec *decoder = avcodec_find_decoder(video_stream->codecpar->codec_id); if (!decoder) { fprintf(stderr, "unsupported codec\n"); return 1; } AVCodecContext *codec_ctx = avcodec_alloc_context3(decoder); avcodec_parameters_to_context(codec_ctx, video_stream->codecpar); if (avcodec_open2(codec_ctx, decoder, NULL) < 0) { fprintf(stderr, "cannot open codec\n"); return 1; } // 4. SDL 初始化 if (SDL_Init(SDL_INIT_VIDEO) < 0) { fprintf(stderr, "SDL init failed: %s\n", SDL_GetError()); return 1; } int width = codec_ctx->width; int height = codec_ctx->height; SDL_Window *win = SDL_CreateWindow("minimal player", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, width, height, SDL_WINDOW_OPENGL); SDL_Renderer *renderer = SDL_CreateRenderer(win, -1, 0); SDL_Texture *texture = SDL_CreateTexture(renderer, SDL_PIXELFORMAT_IYUV, SDL_TEXTUREACCESS_STREAMING, width, height); // 5. 解码循环 AVPacket *pkt = av_packet_alloc(); AVFrame *frame = av_frame_alloc(); SDL_Event event; while (av_read_frame(fmt_ctx, pkt) >= 0) { SDL_PollEvent(&event); if (event.type == SDL_QUIT) break; if (pkt->stream_index == video_stream_idx) { if (avcodec_send_packet(codec_ctx, pkt) == 0) { while (avcodec_receive_frame(codec_ctx, frame) == 0) { // 用 AVFrame 的 YUV 数据更新纹理 SDL_UpdateTexture(texture, NULL, frame->data[0], frame->linesize[0]); // 注意：这里只传了 Y 平面，完整的视频需要三个平面。 SDL_RenderClear(renderer); SDL_RenderCopy(renderer, texture, NULL, NULL); SDL_RenderPresent(renderer); } } } av_packet_unref(pkt); } // 6. 释放资源 av_frame_free(&frame); av_packet_free(&pkt); avcodec_free_context(&codec_ctx); avformat_close_input(&fmt_ctx); SDL_DestroyTexture(texture); SDL_DestroyRenderer(renderer); SDL_DestroyWindow(win); SDL_Quit(); return 0; }注意上面代码里我用注释标了一处“只传了 Y 平面”，这个是刻意留的：极简初版可以先跑出形状，但颜色大概率不对，因为你只给了 SDL 亮度数据。完整写法是把三个平面都传进去，我会在下一节专门讲。
3.3 渲染细节：三平面纹理的正确喂法
SDL 的SDL_PIXELFORMAT_IYUV纹理对应 YUV420P 布局，更新纹理时不能只传frame->data[0]和frame->linesize[0]。完整写法要一起更新 U/V 平面：
SDL_UpdateYUVTexture(texture, NULL, frame->data[0], frame->linesize[0], frame->data[1], frame->linesize[1], frame->data[2], frame->linesize[2]);这里用了专门的SDL_UpdateYUVTexture，比SDL_UpdateTexture更直白，三个平面各传各的指针和 pitch。pitch就是 AVFrame 的linesize，一定要注意：它不等于 width。否则当 linesize 比 width 大时，画面会被横向拉伸或者出现斜向条纹。
渲染时的几个小细节也要留意。SDL_CreateRenderer的第二个参数传 -1 表示自动选择驱动，如果渲染异常可以显式指定软件渲染（比如SDL_RENDERER_SOFTWARE）来排障。每次SDL_RenderPresent之前调SDL_RenderClear，不然上一帧的残留可能让画面发花。窗口尺寸我直接用了视频原始宽高，如果你的视频特别大，可以先等比缩放，极简版本不做也没关系。
这个阶段你会看到画面一帧帧地闪，速度完全不受控制，可能快到飞起，也可能慢得像幻灯片。这是因为解码循环里没有任何休眠和同步逻辑，CPU 能解多快就播多快。这是极简实现的必然状态，下一节我们把节奏补上。
3.4 音视频同步的最简策略：先让画面按 pts 走
真正的播放器同步算法很复杂，但极简版本只需要一个朴素思路：按视频帧自己的时间戳来控制显示节奏。算出当前帧的展示时间，再跟一个“播放启动时刻”比对，决定要不要等。
double fps_avg = video_stream->avg_frame_rate.num / (double)video_stream->avg_frame_rate.den; double delay = 1.0 / fps_avg; // 在解码循环里拿到 frame 后 double pts_sec = av_q2d(video_stream->time_base) * frame->pts; static double last_pts = 0; static double start_time = -1; if (start_time < 0) { start_time = av_gettime_relative() / 1000000.0 - pts_sec; } double wall_clock = av_gettime_relative() / 1000000.0; double elapsed = wall_clock - start_time; if (pts_sec > elapsed) { double sleep_time = (pts_sec - elapsed) * 1000; SDL_Delay((Uint32)sleep_time); }这段逻辑的意思很直白：记录第一帧播放的时刻，之后每帧期待时间和当前系统时间对齐，如果算早了就睡一会儿。这个方案有个天然缺陷——它完全依赖视频流的 pts，一旦视频流本身有 B 帧导致解码顺序和显示顺序不一致，画面就会轻微抖动。但作为学习笔记阶段，先把“速度”搞对，再纠结“平滑”，是我当时的策略。
提示：
av_gettime_relative()返回的是微秒数，记得除以 1000000 转成秒。很多人直接把微秒当毫秒用，导致睡眠时间长了 1000 倍，画面卡成 PPT。
3.5 编译与运行：能出画面就算成功
编译命令按 3.1 节执行，如果一切正常，运行：
./player /path/to/sample.mp4看到窗口弹出并播放出画面，恭喜你，最小播放器闭环已经打通。这时候可以拿不同的视频测试，比如 H.264 编码的 MP4、MPEG-2 的 TS 文件、VP8 的 WebM，看看 FFmpeg 的解码器加载逻辑是怎么自动匹配的。
这个初版播放器有个明显问题：音频被完全忽略了，所以有声音的视频会静音；同时画面速度不稳定。别急着骂它“不能用”——它本来就是给你看骨架的。下一章就来处理那些真正会逼疯人的 bug。
4. 现场调试：常见问题与排查记录
4.1 黑屏无反应：先查 SDL，再查解码
黑屏有两种情况：窗口都没弹出来，或窗口弹出来了但一直是黑的。第一种先看 SDL_Init 和 SDL_CreateWindow 的返回值，打印SDL_GetError()基本能定位；GG环境下还要注意有没有打开显示服务器的权限。第二种黑屏，通常查三点：avcodec_receive_frame有没有走到渲染分支，SDL_RenderPresent之后有没有SDL_Delay，以及是不是帧的数据量太大但纹理没更新。
我调试时习惯在每次SDL_RenderPresent后打一行日志，确认帧确实解出来了。如果日志在刷但屏幕还是黑的，重点看纹理格式是否匹配。SDL_PIXELFORMAT_IYUV必须配 YUV420P 数据，如果你把 RGB 数据硬塞进来，SDL 不会报错，只会画给你看一张黑屏或绿屏。
4.2 花屏、绿屏、颜色偏色：八成是 linesize 或平面数不对
花屏最常见的原因，就是我把上一节提到的“只传 Y 平面”写进了第一版。U/V 平面缺失，画面色彩信息为 0，整个画面会泛绿。这种问题不会报错，全靠肉眼观察，新手很容易懵。
还有一种情况是画面里出现斜向的“台阶”状条纹，这是 linesize 不匹配的典型症状。某些编码器会在每行末尾补几个填充字节，让行长度对齐到 16 或 32 字节。你如果按 width 去拷贝，每行都会错位，越往下越乱。解决方式只有一个：一切拷贝和填充都使用frame->linesize[i]，不要自己猜测内存布局。
如果你在极简版本里强行用sws_scale转 RGB，请检查目标 frame 的 linesize 可别只分配了 width*height 就完事。常见报错是dst buffer is too small，这几乎是每个用 sws 的人都会遇到的坑。
4.3 播放速度不对：pts、time_base 和 sleep 精度
播放速度过快，十有八九是没做同步，CPU 解多快放多快；播放速度过慢，先检查是不是用错了time_base，把stream->time_base和codecctx->time_base混淆了。后者在解码后含义不同，混用会导致 pts 换算出来离谱的数字。
还有SDL_Delay的精度问题。SDL_Delay只能保证“最少睡这么多毫秒”，实际休眠时间可能更长，尤其在高负载环境。所以如果你严格按“下一帧应该出现的时间”去 sleep，画面会越来越慢，因为每次都多睡了一点。改进思路是记录上一帧的实际偏差，微调下一次睡眠时间；极简版本里可以先忽略，但心里要有数，不要对着现象怀疑是解码解错了。
4.4 avformat_find_stream_info 卡住 / av_read_frame 报错
本地小文件一般不会卡，但某些高码率或远端文件可能让你在avformat_find_stream_info上等好久。官方参数是：
fmt_ctx->probesize = 32 * 1024; // 探测数据量上限 fmt_ctx->max_analyze_duration = 5 * AV_TIME_BASE; // 分析时长上限调小这两个值可以加快探测，但可能让部分流的参数识别不准。极简版本建议先不动，等以后做网络流播放再处理。
av_read_frame返回AVERROR_EOF表示正常读到结尾；返回其他负值才是真正的读取错误。我的一个经验是：不要只检查返回值是否小于 0 就直接退出，建议打印一下错误码。用av_strerror转换错误码能省很多查错时间。
4.5 内存泄漏与资源释放：播放器的隐形地雷
FFmpeg 的 API 设计里，分配和释放通常是成对出现的。avformat_open_input对应avformat_close_input，avcodec_alloc_context3对应avcodec_free_context，av_packet_alloc对应av_packet_free，av_frame_alloc对应av_frame_free。
容易遗漏的是循环里的av_packet_unref。av_read_frame每次都会往 pkt 里塞数据，如果你不解引用，旧的 buffer 不会释放，视频长跑几分钟内存就可能涨几十 MB。很多人抱怨 FFmpeg 写播放器内存泄漏，检查下来十有八九是这里出了问题。
我写 demo 时习惯每跑完一轮都在循环末尾av_packet_unref(pkt)，养成肌肉记忆。后续如果加了音频流，还有更多销毁顺序要考虑，比如先关 SDL 再释放音频设备，顺序反了可能崩溃。
5. 从极简到可用：后续我能怎么扩展
5.1 音频解码与输出：从只有画面到有声有色
极简版本把音频砍了，但作为音视频学习笔记，必须说一说加音频的思路。音频链路和视频几乎对称：av_find_best_stream找到音频流，avcodec_find_decoder+avcodec_open2打开音频解码器，解码出的AVFrame不是 YUV 而是 PCM 数据，交给 SDL 的音频设备播放。
SDL 音频最简单的方式是回调模式。你设置好SDL_AudioSpec，指定采样率、声道数、采样格式，然后注册一个回调函数。解码线程把 PCM 数据塞进一个缓冲区，SDL 每次需要数据时回调里取；如果没有数据可给，就静音填充。这一步是整个播放器从“视频播放器”走向“音视频播放器”的关键跨越，同步算法也要从“只跟视频 pts 对齐”改成“视频跟音频时钟对齐”。
5.2 从单线程到双线程：解码和渲染必须分开
极简版本的单线程模型里，解码、渲染、SDL 事件处理全挤在一个 while 循环里。这有两个问题：一是渲染慢帧时会拖累解码，解码慢时也会阻塞事件响应；二是没有缓冲，网络抖动会导致画面一卡一卡。
工程上真正的播放器都采用双线程甚至三线程模型：一个线程专门av_read_frame+ 解码，把解出来的 AVFrame 放进队列；另一个线程从队列取帧渲染，同时处理 SDL 事件。队列只做数据传递，不做同步，同步由时间戳控制。这样代码结构复杂一些，但播放流畅度和稳定性提升非常明显。
5.3 控制功能：暂停、seek、进度条
暂停的原理是停住渲染线程，然后停止消费帧队列；seek 则要调av_seek_frame或者avformat_seek_file，按秒或按帧定位，并清空解码器和帧队列，防止 seek 后瞬间突出一堆旧帧。seek 是播放器里坑最多的模块，因为不同封装格式的 seek 粒度差异很大，还牵扯到关键帧位置。建议等单线程版本稳定运行后，再一步步加。
这些扩展方向，正好对应了我整个音视频学习笔记的后续内容。每次回头重读这段代码，都觉得它像一张地图：FFmpeg 的功能模块纷繁复杂，但只要抓住了这条最小链路，其他所有能力无非是在这条链路的某一个节点上做加法。
6. 个人实操的一点体会
如果让我给刚开始学 FFmpeg 的人总结一句话，那就是：别一头扎进源码，先用最小实现把流程跑通，再回头理解每个函数为什么存在。这个“基于FFmpeg4.1的极简播放器”项目让我第一次真正理解了封装、解码、渲染的边界，也让我在后来的工作中看到任何视频播放问题，都能第一时间判断它出在哪个环节。代码里留下的那些坑——三条纹理、linesize、pts 换算、flush 空包——恰恰是最值钱的经验。
如果你也打算做这个练习，建议准备几个不同编码和封装格式的测试文件，H.264 MP4、VP9 WebM、MPEG-2 TS 各放一个。播放器用同一个代码跑这三种文件，观察 FFmpeg 如何自动完成不同的解复用和解码路径。这个过程比任何博客教程都直观。我至今保留着当时那个只有两百行的 main.c，偶尔翻出来重构一版，都能从简单的代码里看出新的理解。
