简介：这是一套面向 32 位 Windows 平台的 FFmpeg 4.2.1 共享库版本，适合需要在多媒体程序或脚本中调用音视频编解码能力的开发者，也适合希望掌握 FFmpeg 命令行处理的进阶用户。压缩包共 52 个文件，约 22.8 MB，主要包含 3 个可执行命令行工具、8 个核心 DLL 动态链接库，以及一批 HTML 文档、ffpreset 预设、样式表和说明文本，整体结构清晰，便于快速定位所需模块。共享库版本的优势在于 DLL 可被多个程序复用，配合 lib、include 目录，开发者能直接链接编码、解码、封装、滤镜等模块，实现格式转换、转码、流处理、音视频编辑等任务；内置 HTML 文档覆盖命令行用法、滤镜、设备、协议、格式等主题，可作为离线学习手册；预设文件则能帮助快速套用常见编码参数。目前已有 704 人学习下载，对需要在 Windows 32 位环境中处理多媒体的使用者来说，是一份省去自行编译、开箱即用的实用资源。
1. 为什么我最后还是留了 ffmpeg-4.2.1-win32-shared：32 位视频处理的现实选择
做 Windows 桌面端视频处理的开发者，迟早会在 shared 和 static 两个发行版之间纠结一次。ffmpeg-4.2.1-win32-shared 这个包解决的不是“能不能跑 ffmpeg”的问题，而是“怎么在自己程序里优雅地调 ffmpeg”的问题——它把 ffmpeg.exe、ffprobe.exe 和一堆 DLL 一起给你，头文件、库导入库都在，适合用 C/C++ 或 C# 通过 P/Invoke 做二次开发。我最早在某个图像处理 Demo 里图省事直接调 exe 命令行，结果被参数解析和进程通信磨掉两天时间，后来换 shared 版本做进程内调用，逻辑瞬间清爽。
这个版本选 4.2.1 而不是追新版，是因为它在 API 稳定性和功能完整性之间卡得刚好：h264、hevc、aac 这些主流编解码都齐，滤镜系统也成熟，对老项目的兼容性比 5.x、6.x 好得多。适合三类人：一类是维护老代码库的，一类是做 32 位插件需要在老系统上跑的，还有一类是想搞懂 ffmpeg 库调用但不想碰源码编译的。注意它只带 Win32 库，x64 项目用不上，这点后面详细说。
2. 解码 shared 版的结构：DLL、头文件和那 14 个库的职责
2.1 解压后先认清这四类文件
拿到 ffmpeg-4.2.1-win32-shared.zip 后，第一件事不是急着写代码，而是把目录结构摸清楚。这个包解压后大概分成四个部分：bin 目录下的 ffmpeg.exe 和 ffprobe.exe 是命令行工具；bin 目录下那一堆 DLL 是真正的核心；include 目录里是 C 头文件；lib 目录里是编译链接时要用的 .a 导入库文件。如果只装过 static 版，第一次看到 .a 文件可能犯迷糊——在 Windows 上 MinGW 工具链用的就是这种格式。
bin 目录里那十几个 DLL 不能随便删，它们存在依赖关系。avcodec 负责编解码，avformat 管封装和解封装，avfilter 做滤镜处理，avutil 是基础工具库，swscale 做像素格式转换，swresample 做音频重采样。我见过有人为了“精简”只拷了 avcodec.dll 和 avformat.dll，结果程序跑起来直接报缺少 avutil.dll——因为 avformat 内部依赖 avutil 的基础函数。
还有个细节：DLL 里有版本号后缀，比如 avcodec-58.dll。这是 ffmpeg 的 ABI 版本管理方式，大版本号不同说明接口不兼容，不能拿 5.x 的 avcodec-59 直接替换 4.2.1 的 avcodec-58。排错时如果发现“找不到入口点”这类错误，先检查是不是 DLL 混用了。
2.2 配置开发环境：MinGW 下链接和运行时加载
安装 MinGW-w64 后需要把 include 目录加进头文件路径。在命令行编译时用-I参数指定，如果用 Code::Blocks 这类 IDE 就在项目设置里加。链接阶段比较关键，需要把 lib 目录下对应的 .a 文件逐个加进链接参数：
gcc -o video_tool.exe main.c -I/path/to/ffmpeg-4.2.1-win32-shared/include -L/path/to/ffmpeg-4.2.1-win32-shared/lib -lavformat -lavcodec -lavutil -lswscale-lavformat等参数会按顺序链接对应的导入库，生成的可执行文件在启动时会去加载同目录下的 DLL。这里要特别注意 DLL 的搜索路径问题：Windows 默认按“可执行文件所在目录 → 系统目录 → PATH 环境变量”的顺序找 DLL，所以把 ffmpeg 的 DLL 和你的 exe 放同一目录最稳，省去配置 PATH 的麻烦。若 DLL 没找到，程序就报 0xc000007b 之类的错误。
2.3 动态加载还是静态链接：两种路线的取舍
很多人以为有 .a 文件就必须静态链接，其实这是误解。MinGW 的 .a 文件在 Win32 shared 包里是“导入库”，作用是告诉链接器这个符号在哪个 DLL 里，程序运行时照样动态加载 DLL。这样做的好处是：如果 ffmpeg 更新了一个小版本，只需要替换 DLL 文件，不需要重新编译你的程序。
另一种方式是运行时动态加载，即调用 LoadLibrary 和 GetProcAddress。这种方式更灵活，程序启动时按需加载，甚至可以做到“检测到系统里有 ffmpeg 就用，没有就不用”，但麻烦的是要手写一堆函数指针声明。我的习惯是：如果只是自己内部工具，用导入库就够了，省时间；如果要分发给别人用，会加一层动态加载判断，并给用户提示缺哪个 DLL。
3. 上手实战：用 shared 库实现视频抽帧和推流
3.1 从零写一个抽帧程序：核心流程与关键结构体
用 shared 库做视频处理有一个绕不开的 API 流程：打开输入 → 查找流信息 → 分配解码上下文 → 循环读包解码 → 转格式 → 存帧。这个流程不管是抽帧还是转码都适用。先看一个最小可运行的抽帧示例，从视频里每隔一秒抽一帧存成 JPEG：
#include <stdio.h> #include <libavformat/avformat.h> #include <libavcodec/avcodec.h> #include <libswscale/swscale.h> int extract_frames(const char *input_path) { AVFormatContext *fmt_ctx = NULL; // 打开输入文件并读取头信息 if (avformat_open_input(&fmt_ctx, input_path, NULL, NULL) < 0) { fprintf(stderr, "无法打开输入文件\n"); return -1; } // 查找流信息，填充各个流的相关参数 if (avformat_find_stream_info(fmt_ctx, NULL) < 0) { fprintf(stderr, "无法找到流信息\n"); return -1; } // 找到第一个视频流 int video_stream_idx = -1; for (unsigned int i = 0; i < fmt_ctx->nb_streams; i++) { if (fmt_ctx->streams[i]->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) { video_stream_idx = i; break; } } if (video_stream_idx == -1) { fprintf(stderr, "未找到视频流\n"); return -1; } // 根据编码参数找到对应的解码器 AVCodecParameters *codec_params = fmt_ctx->streams[video_stream_idx]->codecpar; const AVCodec *decoder = avcodec_find_decoder(codec_params->codec_id); if (!decoder) { fprintf(stderr, "不支持的编码格式\n"); return -1; } // 创建解码上下文并复制参数 AVCodecContext *codec_ctx = avcodec_alloc_context3(decoder); avcodec_parameters_to_context(codec_ctx, codec_params); // 打开解码器 if (avcodec_open2(codec_ctx, decoder, NULL) < 0) { fprintf(stderr, "无法打开解码器\n"); return -1; } // 分配帧和包对象 AVFrame *frame = av_frame_alloc(); AVPacket *packet = av_packet_alloc(); // 用 swscale 做像素格式转换，这里把解码出的帧转成 JPEG 编码器需要的格式 struct SwsContext *sws_ctx = sws_getContext( codec_ctx->width, codec_ctx->height, codec_ctx->pix_fmt, codec_ctx->width, codec_ctx->height, AV_PIX_FMT_YUVJ420P, SWS_BILINEAR, NULL, NULL, NULL); int frame_count = 0; // 循环读取数据包，交给解码器处理 while (av_read_frame(fmt_ctx, packet) >= 0) { if (packet->stream_index == video_stream_idx) { // 把压缩数据包发送给解码器 if (avcodec_send_packet(codec_ctx, packet) == 0) { // 从解码器接收解码后的图像帧 while (avcodec_receive_frame(codec_ctx, frame) == 0) { // 每隔 30 帧（假设 30fps 视频）保存一帧 if (frame_count % 30 == 0) { save_frame_as_jpeg(frame, sws_ctx, codec_ctx->width, codec_ctx->height, frame_count); } frame_count++; } } } // 每个包用完要清空，避免内存累积 av_packet_unref(packet); } // 清理所有资源，顺序不能乱 sws_freeContext(sws_ctx); av_frame_free(&frame); av_packet_free(&packet); avcodec_free_context(&codec_ctx); avformat_close_input(&fmt_ctx); return 0; }这段代码的逻辑不复杂：avformat_open_input打开文件后，avformat_find_stream_info会探测流信息；找到视频流后用codecpar里的编码 ID 找解码器；然后avcodec_send_packet和avcodec_receive_frame是一对配套调用，前者喂压缩数据，后者拿解码结果。每次av_read_frame拿到的AVPacket必须调用av_packet_unref释放引用，否则循环读几百帧内存就爆了。
SWS_BILINEAR是缩放算法参数，只用做格式转换、不改尺寸时选哪个算法影响不大，但如果要做缩略图，SWS_LANCZOS在缩小场景下画质更好。save_frame_as_jpeg是我封装的函数，用avcodec_encode_image或直接调sws_scale转成 RGB 再用 libjpeg 写文件，这里不展开。
3.2 封装推流代码：把裸流打包成 RTMP 的关键参数
抽帧是解码方向，推流就要走编码和封装流程。用 shared 版做 RTMP 推流，需要先把原始帧编码成 H.264，再用avformat_write_header写封装头。先看初始化部分的代码：
// 创建输出上下文，URL 以 rtmp:// 开头 AVFormatContext *out_ctx = NULL; avformat_alloc_output_context2(&out_ctx, NULL, "flv", "rtmp://127.0.0.1/live/stream"); if (!out_ctx) { fprintf(stderr, "无法创建输出上下文\n"); return -1; } // 查找 H.264 编码器 const AVCodec *encoder = avcodec_find_encoder_by_name("libx264"); if (!encoder) { fprintf(stderr, "libx264 编码器不可用，编译时需启用 --enable-libx264\n"); return -1; } // 配置编码参数，关键是码率和 GOP 大小 AVCodecContext *enc_ctx = avcodec_alloc_context3(encoder); enc_ctx->width = 1280; enc_ctx->height = 720; enc_ctx->time_base = (AVRational){1, 30}; enc_ctx->framerate = (AVRational){30, 1}; enc_ctx->pix_fmt = AV_PIX_FMT_YUV420P; enc_ctx->bit_rate = 2000000; // GOP 设置为帧率的两倍，即每 2 秒一个关键帧 enc_ctx->gop_size = 60; enc_ctx->max_b_frames = 2;这里有个容易忽略的点：time_base和framerate容易搞混。time_base是用来表示时间戳的单位，{1, 30}表示每个 tick 是 1/30 秒；framerate表示帧率。在avcodec_open2后还需要再创建一个AVStream到输出上下文里，并把编码器参数复制过去。推流时的 PTS/DTS 计算也很关键，如果原始帧率是 30fps，那么第 N 帧的 PTS 应当是N * (1/30)，单位是秒，换算成输出时间基要乘上{1, 30}的倒数。
GOP 大小直接影响直播延迟：gop_size设太大会让关键帧间隔太长，用户加入直播时要等很久才能出画面；设太小又浪费带宽。我一般给直播推流设帧率的两倍到四倍，点播可以适当加大。max_b_frames设为 2 能在画质和延迟之间平衡，B 帧过多会显著增加解码延迟。
3.3 推流的主循环：音视频同步的雏形
主循环的逻辑和抽帧类似，但多了编码和写入步骤：
while (av_read_frame(fmt_ctx, packet) >= 0) { if (packet->stream_index == video_stream_idx) { avcodec_send_packet(dec_ctx, packet); while (avcodec_receive_frame(dec_ctx, frame) == 0) { // 设置显示时间戳，单位是编码器的时间基 frame->pts = frame_count++; // 发送到编码器 avcodec_send_frame(enc_ctx, frame); AVPacket *enc_pkt = av_packet_alloc(); while (avcodec_receive_packet(enc_ctx, enc_pkt) == 0) { // 重新计算时间戳到输出时间基 av_packet_rescale_ts(enc_pkt, enc_ctx->time_base, out_stream->time_base); enc_pkt->stream_index = out_stream->index; // 写入输出文件或推流服务器 av_interleaved_write_frame(out_ctx, enc_pkt); } av_packet_free(&enc_pkt); } } } // 推流结束前必须写尾 av_write_trailer(out_ctx);av_packet_rescale_ts是音视频同步的关键函数，它把编码器的时间基换算成输出流的时间基，如果不做这一步，播放器看到的时长就是乱的。av_interleaved_write_frame内部会排队和排序包，保证写入顺序的正确性。结束前调用av_write_trailer是必须的，它负责写 FLV 的结束标记。如果程序崩溃没走到这一步，推流端录制的文件可能会无法播放。
4. 避坑指南：DLL 加载失败、API 变更和 32/64 位混用
4.1 坑一：程序启动直接报 0xc000007b，原因其实是架构位宽不匹配
现象：把 DLL 和 exe 放同一目录了，程序还是闪退，事件查看器显示异常代码 0xc000007b。分析：这个错误八成是 32/64 位混用造成。shared 包是 win32 的，你的程序也得是 32 位编译，用 MinGW-w64 时注意别默认编出 x64 程序。解决：编译时加-m32强制输出 32 位，确保编译器、链接器、DLL 三者位数一致。如果项目必须 64 位，就得去找 x64 版 ffmpeg，不能混用。
4.2 坑二：找不到入口点 avcodec_get_name，原因却是 DLL 版本不一致
现象：链接顺利通过，exe 也生成了，但双击运行提示找不到avcodec_get_name入口点。分析：你系统 PATH 里可能有另一个 ffmpeg 的 DLL，程序没加载同目录的 DLL 反而加载了 PATH 里那个旧版。解决：用 Dependency Walker 或 Process Explorer 查看实际加载的 DLL 路径；或者在程序里用SetDllDirectory强制优先加载指定目录。
4.3 坑三：av_register_all 编译直接报错，原因是在 4.x 版本中它被移除了
现象：从网上抄了一段旧代码，第一行就调av_register_all()，编译器提示隐式声明。分析：ffmpeg 4.0 之后这个函数已经不需要了，注册是自动完成的，4.2.1 里彻底移除。解决：删掉这行，新版代码不需要手动注册，如果看老教程，记得这一行可以直接忽略。反过来，如果你代码是给 3.x 写的，那得保留。
4.4 坑四：avcodec_send_packet 返回 EAGAIN，原因是编码器内部缓冲满了
现象：调用avcodec_send_packet返回负值，查 errno 发现是 EAGAIN。分析：解码器还没把上一帧输出完，内部队列塞满了。解决：不要在avcodec_send_packet返回非零时立刻报错，应当先循环取帧释放空间，然后再重试发送。规范的写法是 send 之后马上循环 receive，直到返回 EAGAIN 或 EOF，再处理下一个包。
4.5 坑五：推流声音对不上画面，原因在时间基换算被跳过
现象：视频越推越卡，或者画面和声音逐渐错开。分析：av_packet_rescale_ts没写或者写错参数，流的时间戳和容器要求不一致。解决：严格按“编码器时间基 → 输出流时间基”做换算，如果音频和视频来自不同输入，先分别换算到共同的时间基准（通常是微秒或毫秒）再交给av_interleaved_write_frame。
5. 进阶实践：用 shared 库配合滤镜实现画质增强和硬件加速
5.1 滤镜链的使用：scale 和 unsharp 的组合玩法
ffmpeg 的滤镜框架在库调用里同样可用。通过avfilter_graph系列 API 可以构建滤镜链，比如先缩放再锐化：
// 配置滤镜图，输入像素格式为 yuv420p，输出保持同格式 char filter_desc[256]; snprintf(filter_desc, sizeof(filter_desc), "scale=1920:1080,unsharp=5:5:1.0:5:5:0.0"); // 创建滤镜图 AVFilterGraph *graph = avfilter_graph_alloc(); // 创建输入和输出 pad，需要指定名称方便后续连接 const AVFilter *buffer_src = avfilter_get_by_name("buffer"); const AVFilter *buffer_sink = avfilter_get_by_name("buffersink"); AVFilterContext *src_ctx = NULL; AVFilterContext *sink_ctx = NULL; // 输入参数要描述清楚视频的尺寸、格式和时间基 char args[512]; snprintf(args, sizeof(args), "video_size=1280x720:pix_fmt=yuv420p:time_base=1/30:pixel_aspect=1/1"); avfilter_graph_create_filter(&src_ctx, buffer_src, "in", args, NULL, graph); avfilter_graph_create_filter(&sink_ctx, buffer_sink, "out", NULL, NULL, graph); // 解析滤镜描述字符串并连接到图上 AVFilterInOut *outputs = avfilter_inout_alloc(); AVFilterInOut *inputs = avfilter_inout_alloc(); outputs->name = av_strdup("in"); outputs->filter_ctx = src_ctx; outputs->pad_idx = 0; outputs->next = NULL; inputs->name = av_strdup("out"); inputs->filter_ctx = sink_ctx; inputs->pad_idx = 0; inputs->next = NULL; // 关键调用：把字符串解析成实际的执行链 avfilter_graph_parse_ptr(graph, filter_desc, &inputs, &outputs, NULL); avfilter_graph_config(graph, NULL);这段代码最大的坑是：avfilter_graph_parse_ptr解析完成后，AVFilterInOut结构体需要手动释放，但filter_ctx和pad_idx会从 graph 里带出来复用。另外滤镜描述字符串里如果包含逗号，必须用反斜杠转义，比如scale=800:-1,unsharp里的逗号是分隔不同滤镜的；滤镜内部参数的分隔符是冒号。
unsharp=5:5:1.0:5:5:0.0这组参数的含义要解释清楚：前两个数字是亮度锐化的矩阵尺寸，5:5表示 5x5 的卷积核；1.0是锐化强度，数值越大效果越明显，但超过 1.5 容易出现白边；后两个5:5是色度锐化的矩阵尺寸，最后的0.0是色度锐化强度。我一般会把亮度强度控制在 0.8 到 1.2 之间，太强的锐化在低码率下会产生大量噪点，反而影响压缩效率。
5.2 延迟优化：降低首屏时间的三个参数
直播或实时处理场景中，延迟是硬指标。ffmpeg 库调用里有几个参数直接影响延迟：一是av_opt_set设置编码器的preset为ultrafast，编码速度越快，引入的缓冲延迟越小；二是把tune设为zerolatency，这个参数会对编码器做特殊优化，禁用一些引入延迟的功能；三是考虑用-probesize和-analyzeduration控制输入探测时间，默认探测几十帧会增加启动延迟。
av_opt_set(enc_ctx->priv_data, "preset", "ultrafast", 0); av_opt_set(enc_ctx->priv_data, "tune", "zerolatency", 0); // 关闭 B 帧也能降低延迟，代价是压缩率下降 enc_ctx->max_b_frames = 0;zerolatency对 libx264 来说会强制关闭 lookahead 和部分 B 帧优化，画面质量会有轻微下降。如果是局域网内做视频通话或监控推流，这个取舍完全值得；如果要上传平台，还是用medium预设和filmtune 保画质。关键是要理解这几个参数的联动效果，不能只看字面意思。
5.3 硬件加速判断：你的场景值不值得踩这个坑
4.2.1 在 Windows 上支持 DXVA2 和 QSV 硬解，但库调用做硬解的复杂度比命令行高一个量级。命令行里一句-hwaccel dxva2的事，在代码里需要手动处理AVHWFramesContext，还要在解码器打开后用avcodec_get_hw_frames_parameters申请硬件帧池。我只建议一种场景上硬解：就是处理 4K 或更高分辨率的视频，CPU 软解明显吃力时。720p 和 1080p 的视频，i5 级别的 CPU 用软解完全够用，没必要增加这一层复杂度。
硬解还有一个伴随问题：解码出来的帧是 GPU 显存里的AVFrame，如果你要做滤镜处理或抽帧，得先av_hwframe_transfer_data拷回内存。这个拷贝操作本身有开销，处理小分辨率视频时可能比软解还慢。所以我的经验是：能用软解就用软解，实在不行再上硬解，并且要提前验证你的显卡驱动在目标机器上能跑通 DXVA2。
写在最后：从命令行到库调用的习惯转变
用了这几年 shared 版 ffmpeg，最大的收获不是会调几个 API，而是形成了一套自己的验证流程。每次拿到一个新的 ffmpeg 版本包，我都会先跑一遍ffmpeg -version看编译选项是否包含需要的编解码器，再写一个最小程序链接测试库调用，最后才动手写真正复杂的功能。这套流程帮我过滤掉了至少一半的“库有问题”假象，因为多数情况其实是你自己的编译参数或 DLL 路径没配对。
另一个深刻教训是：ffmpeg 的 API 每个大版本都在变，你的代码必须跟着版本迭代。4.2.1 里能用的函数，到了 5.x 可能就标了 deprecated，到 6.x 直接删掉。我给自己定了一个规矩：每次升级 ffmpeg 版本时，先跑一遍官方的 API 变更说明文档，用工具静态扫描代码里废弃函数的调用点，全部改完再编译。
说起来，这个包我目前还在用。一方面是因为手头的项目全部基于 4.2.1 的 API 写的，替换成本不小；另一方面，4.2.1 在 Windows 32 位平台上的表现足够稳定，比追新版本少了很多奇奇怪怪的问题。如果你也在维护老项目或者刚开始研究 ffmpeg 库调用，直接从 4.2.1 shared 版入手是个不错的起点——别一上来就折腾编译源码那套，先能用起来，再想优化的事。希望这些经验对你有帮助。
如果你打算下载这个ffmpeg-4.2.1-win32-shared.zip开始动手，记得三个关键点：确认你的编译工具链能产出 32 位程序，把所有 DLL 放在 exe 同目录下，以及先从抽帧这类简单功能练手而非直接上推流。遇到我说的那些坑，对照排查基本都能解决。
本文还有配套的精品资源，点击获取
