FFmpeg vs2015静态库完全指南：视频解码告别DLL依赖

简介：面向在 Visual Studio 2015 中从事音视频编解码开发的工程师，这份资源提供 FFmpeg n4.4.1（版本号 N104926-gc8b5f2848d）对应的 x86/x64 静态编译产物，最终程序无需携带 avcodec.dll 等一批动态库，部署更简洁。与官方动态库方案相比，集成时需要额外附加一些系统级依赖，包内附带的 txt 已逐项列出这些依赖，可有效避免链接阶段报错。压缩包共 140 个文件，包括 125 个头文件、14 个 .lib 静态库和 1 份依赖说明，头文件覆盖解码、封装、滤镜等常用模块，整体约 28.78MB，便于直接引入 VS2015 工程。该版本基于 n4.4.1 源码最新编译，作者标注已测试可用，目前已有 457 人学习下载。使用这份静态库，可快速搭建音视频解码、转码、滤镜处理等能力，省去自行用 MSYS2/MinGW 交叉编译的繁琐流程，适合需要产出独立 exe 或对运行环境有精简要求的 C/C++ 项目。

1. ffmpeg vs2015 静态库：一套 lib 搞定视频解码，不用再抱着一堆 dll 到处跑

做 Windows 桌面音视频工具的人，基本都受过 ffmpeg 动态库的折磨：开发机调试好好的，换一台干净机器就报“找不到 avcodec.dll”，要么把十几个 dll 跟 exe 放一起，要么去系统目录里折腾 VC 运行库。这个 vs2015 编译的 ffmpeg 静态库版本，对应 n4.4.1（版本号 N104926-gc8b5f2848d），把 avcodec、avformat、avfilter 这些核心模块全部编成了 .lib，链接完直接产出一个独立的 exe，连 ffmpeg 的 dll 都不用带。适合两类人：一类是被动态库依赖搞烦了的 Windows 桌面开发者，另一类是需要在 VS2015 工程里做视频解码、转码、推流，但不想自己从源码折腾编译的人。下面把库的构成、接入方式、链接参数和最容易翻车的几个点一次说清楚。

2. 拆开看静态库的构成：头文件、lib 文件与附加依赖项

2.1 头文件清单说明：这份库里到底给了什么

压缩包里的头文件列表很明确：avcodec.h、avformat.h、avfilter.h、pixfmt.h、opt.h、avio.h、frame.h、hwcontext.h、packet.h、mem.h。这不是随便挑的十个头文件，而是按“解码一条视频流”这条主线配齐的最小集合。

avcodec.h 是编解码器核心，打开解码器、喂压缩数据、拿原始帧都靠它；avformat.h 负责封装格式，也就是读 mp4、flv、mkv 这些容器；avfilter.h 给的是滤镜链的接口，做缩放、格式转换会用到；pixfmt.h 定义像素格式枚举，比如 AV_PIX_FMT_YUV420P；frame.h 和 packet.h 对应解码前后的数据结构——AVFrame 存解码后的图像，AVPacket 存编码后的压缩数据；avio.h 是自定义 IO 回调，做内存输入或者从网络流读取时要用；hwcontext.h 是硬件解码上下文，如果打算接 QSV、DXVA2 或者 CUDA，这个头文件是入口；opt.h 和 mem.h 是基础工具层，设置参数和内存管理用的。

一个容易忽略的点：这个头文件集合里没有 libavutil 的完整展开。avutil 是 ffmpeg 的基础库，很多结构体定义和工具函数都在里面。如果你后续要从 DLL 版的 ffmpeg 迁移代码过来，看到头文件变少了不用慌，静态库的构建方式决定了它会把所有依赖静态地揉进 lib 里，而不是像动态库那样按模块拆头文件。实际编译时，编译器需要的头文件路径就是解压目录下的 include 文件夹，把这十个头文件当成必须存在的核心集即可，缺了再按编译报错去找。

2.2 链接依赖项详解：动态库不用带，但系统库你得手动加

摘要里特别标注了一句话：“相对于使用官方的动态库，需要额外附加一些依赖项，已写入 txt 一并放入压缩包中了”。这句话很多人扫一眼就过了，实际链接时十个里有八个在这里翻车。

动态库方案下，你只需要在工程里配置 avcodec.lib 等导入库，运行时由系统加载 avcodec.dll。静态库方案完全不同：ffmpeg 的 lib 文件会把所有模块代码编进你的 exe，但这些代码内部还引用了 Windows 系统层面的 API——比如网络相关的 ws2_32.lib、系统配置相关的 user32.lib、多线程相关的 pthread 模拟层等。压缩包里的 txt 文件列的就是这一串附加依赖项，常见的有这些：

不同版本和编译配置下，这份清单略有差异。建议直接打开 txt 把里面的内容复制到 VS 的“链接器 → 输入 → 附加依赖项”里，不要自己凭记忆删减。有一种常见的错误做法是只加 avcodec.lib、avformat.lib、avutil.lib 三个核心库，结果链接器报几百个 unresolved external symbol，然后开始怀疑库是不是坏了——其实只是 ws2_32 没加。

2.3 x86 与 x64 两套库的应用场景选择

压缩包里同时提供了 x86 和 x64 两套静态库，这是有意为之，不是简单复制两份。选择哪套，取决于你的目标程序运行在什么环境下，而不是开发机是什么系统。

x86 静态库适用于以下场景：目标机器是 32 位 Windows 或 64 位系统但程序必须跑在 WOW64 兼容层里的；或者你的程序需要注入到 32 位宿主进程，比如老版本的 CAD 插件、Office 插件、屏幕录制工具里挂的采集模块。x64 则是常规选择，内存寻址空间大，解码高分辨率视频时性能上限更高。

需要特别强调：VS 工程的“平台”设置必须和 lib 的架构一致。一个典型的低级错误是，工程配置的是 Win32 平台，却把 x64 文件夹里的 lib 路径写进去，链接器直接报“module machine type 'x64' conflicts with target machine type 'x86'”。这个错误非常好认，但架不住每次换机器、换工程都会有人再犯一次。我一般会在工程属性页的“链接器 → 命令行”里加一句注释提醒自己当前选的是哪套库，或者在 lib 路径里直接带 x86/x64 子目录名，让路径自己说话。

另外一个容易忽略的细节：x86 静态链接出来的 exe，在 64 位系统上跑没问题，但进程是 32 位的，任务管理器里能看到“*32”标记。如果你的程序要加载大文件、处理 4K 视频，建议直接用 x64 版本，别在 32 位寻址空间里抠内存。

3. 接入 VS2015 工程：附加依赖项、预处理与第一个解码 Demo

3.1 工程配置三板斧：头文件、库目录、依赖项一次设对

新建一个空的 Win32 控制台程序（或 Win32 项目），然后把三处配置写对，项目就能编过。先说第一处：C/C++ → 常规 → 附加包含目录，填入静态库解压目录下的 include 路径。这一步是为了让编译器找到 avcodec.h、avformat.h 这些头文件。

第二处是链接器 → 常规 → 附加库目录，填 lib 文件所在路径。这里我建议直接填到具体的 x86 或 x64 子目录，而不是填上级目录，省得后面搞混。然后在链接器 → 输入 → 附加依赖项里，填入压缩包 txt 文件里列出的所有 lib 文件名，包括 ffmpeg 自身的库和系统依赖库。顺序上有一个潜在问题：如果 ffmpeg 的 lib 之间互相依赖，通常不会卡顺序，因为 VS 的链接器会多次扫描；但系统库建议放在 ffmpeg 库的后面，这样解析符号时更顺畅。

第三处是 C/C++ → 预处理器 → 预处理器定义。这条很多人不知道：使用 ffmpeg 静态库时，需要定义_CRT_SECURE_NO_WARNINGS，否则 VS2015 会在编译时对 fopen、strcpy 这些函数报一堆 deprecation 警告，虽然不影响编译结果，但几百条警告飘在输出窗口里，会盖掉真正有价值的提示。此外还要确认没有定义_WINDLL，因为这个宏会让编译器按动态库模式处理导入导出。

配置完成后，做个最快验证——输出 ffmpeg 的版本号和编译配置信息，确认库能正常链接：

extern "C" { #include "libavcodec/avcodec.h" #include "libavformat/avformat.h" } #include <stdio.h> int main() { // 打印版本号：这里返回的是库内部的版本整型值，不能用 printf("%s") 直接打 printf("FFmpeg version: %u.%u.%u\n", LIBAVCODEC_VERSION_MAJOR, LIBAVCODEC_VERSION_MINOR, LIBAVCODEC_VERSION_MICRO); // 打印编译配置信息，能看到是否启用了硬编解码、协议、滤镜等 av_log_set_level(AV_LOG_INFO); av_log(NULL, AV_LOG_INFO, "Configuration: %s\n", avcodec_configuration()); // 注册所有编解码器、封装格式、协议 // 静态库模式下这一步必须做，动态库 + Windows 下通常也需要显式调用 avformat_network_init(); return 0; }

这段代码的逻辑分三层：第一层打印版本宏，确认头文件和 lib 是配套的——如果头文件是 n5.x 的，lib 是 n4.x 的，这里会明显对不上；第二层调用 avcodec_configuration()，这是一个编译期写死的字符串，能看到启用的功能列表；第三层 avformat_network_init() 初始化网络模块，如果你只是本地读文件，这行可有可无，但留着无害。注意最外层的extern "C"，因为 ffmpeg 是 C 库，C++ 工程里不包这一层，链接阶段会报“无法解析的外部符号”，这是新手最常见的 C++ 调 C 库的坑。

3.2 真实解码流程：从打开文件到拿到 YUV 帧的完整代码

版本验证通过后，跑一个真正能解码的例程。下面这段代码实现的功能是：打开一个视频文件，找到视频流，打开解码器，逐帧读取并解码，把每帧的宽高和像素格式打印出来，最后释放资源。这段代码里我对每一步的返回值都做了检查，别看繁琐，解码流程里大部分诡异 bug 都源于对返回值的想当然。

extern "C" { #include "libavformat/avformat.h" #include "libavcodec/avcodec.h" #include "libavutil/pixfmt.h" } #include <stdio.h> int main(int argc, char* argv[]) { if (argc < 2) { printf("usage: %s <input.mp4>\n", argv[0]); return -1; } // 1. 打开输入文件，解析封装格式 AVFormatContext* fmt_ctx = nullptr; int ret = avformat_open_input(&fmt_ctx, argv[1], nullptr, nullptr); if (ret < 0) { char errbuf[128] = {0}; // av_strerror 把负数错误码转成可读字符串，比看数字强一百倍 av_strerror(ret, errbuf, sizeof(errbuf)); printf("avformat_open_input failed: %s\n", errbuf); return -1; } // 2. 读取流信息，拿到媒体流元数据 ret = avformat_find_stream_info(fmt_ctx, nullptr); if (ret < 0) { printf("avformat_find_stream_info failed\n"); avformat_close_input(&fmt_ctx); return -1; } // 3. 找到视频流索引 int video_stream_idx = -1; for (unsigned int i = 0; i < fmt_ctx->nb_streams; i++) { // 遍历所有流，只找 AVMEDIA_TYPE_VIDEO 类型的 if (fmt_ctx->streams[i]->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) { video_stream_idx = static_cast<int>(i); break; } } if (video_stream_idx == -1) { printf("no video stream found\n"); avformat_close_input(&fmt_ctx); return -1; } // 4. 根据 codecpar 里的编码器 ID 查找解码器 AVCodecParameters* codecpar = fmt_ctx->streams[video_stream_idx]->codecpar; const AVCodec* decoder = avcodec_find_decoder(codecpar->codec_id); if (!decoder) { printf("unsupported codec: %d\n", codecpar->codec_id); avformat_close_input(&fmt_ctx); return -1; } // 5. 创建解码器上下文并绑定参数 AVCodecContext* codec_ctx = avcodec_alloc_context3(decoder); if (!codec_ctx) { printf("avcodec_alloc_context3 failed\n"); avformat_close_input(&fmt_ctx); return -1; } // 用 codecpar 填充 codec_ctx，这一步替代了旧版的 avcodec_copy_context ret = avcodec_parameters_to_context(codec_ctx, codecpar); if (ret < 0) { printf("avcodec_parameters_to_context failed\n"); avcodec_free_context(&codec_ctx); avformat_close_input(&fmt_ctx); return -1; } // 6. 打开解码器 ret = avcodec_open2(codec_ctx, decoder, nullptr); if (ret < 0) { char errbuf[128] = {0}; av_strerror(ret, errbuf, sizeof(errbuf)); printf("avcodec_open2 failed: %s\n", errbuf); avcodec_free_context(&codec_ctx); avformat_close_input(&fmt_ctx); return -1; } printf("decoder: %s, resolution: %dx%d, pixfmt: %d\n", decoder->name, codec_ctx->width, codec_ctx->height, codec_ctx->pix_fmt); // 7. 分配帧和包对象，开始解码循环 AVFrame* frame = av_frame_alloc(); AVPacket* pkt = av_packet_alloc(); int frame_count = 0; while (av_read_frame(fmt_ctx, pkt) >= 0) { // 只处理视频流，音频流直接跳过并释放包 if (pkt->stream_index == video_stream_idx) { // 把压缩数据喂给解码器，ret == 0 表示成功送入 ret = avcodec_send_packet(codec_ctx, pkt); if (ret == 0) { // 循环取出所有已解码的帧，send 一次可能对应 receive 多次 while (avcodec_receive_frame(codec_ctx, frame) == 0) { printf("frame %d: %dx%d, pts=%lld\n", frame_count++, frame->width, frame->height, static_cast<long long>(frame->pts)); // 正常做处理的地方：比如 sws_scale 转 RGB、保存 YUV 等 } } } // 必须 release，否则 AVPacket 内部缓冲会持续累积 av_packet_unref(pkt); } // 8. 收尾：发送 flush 包让解码器吐出剩余帧 avcodec_send_packet(codec_ctx, nullptr); while (avcodec_receive_frame(codec_ctx, frame) == 0) { printf("flush frame %d\n", frame_count++); } // 9. 释放所有资源，顺序和分配顺序相反 av_packet_free(&pkt); av_frame_free(&frame); avcodec_free_context(&codec_ctx); avformat_close_input(&fmt_ctx); printf("total frames: %d\n", frame_count); return 0; }

这段代码是 n4.4.1 的标准解码范式，核心在于 send_packet/receive_frame 这套新 API，替代了旧版的 avcodec_decode_video2。有两个参数细节值得注意：一是avcodec_send_packet传入nullptr可以对解码器做 flush，让解码器把缓冲在内部的重排帧（B 帧）吐出来，如果不做这一步，文件末尾的几帧会丢失；二是av_packet_unref必须每轮循环都调用，否则同一个 AVPacket 会持有旧数据的内存引用，跑几百帧后内存涨到几百 MB，这是新手最容易忽略的内存泄漏源。这里用的是codecpar而非旧版的stream->codec，因为在 FFmpeg 4.x 之后，codec字段被标记为私有，直接访问会得到编译警告甚至错误。静态库模式下代码逻辑无差别，不需要为静态库改代码，但要确保pix_fmt的枚举值和头文件定义一致——如果手头有其他版本 ffmpeg 的头文件混入，这个值可能错位。

编译链接命令也可以直接用命令行验证，不一定要打开 VS 界面：

cl /EHsc /I include /c decode_demo.cpp link decode_demo.obj /OUT:decode_demo.exe ^ lib\x64\avcodec.lib lib\x64\avformat.lib lib\x64\avutil.lib ^ lib\x64\swscale.lib lib\x64\swresample.lib ^ ws2_32.lib user32.lib bcrypt.lib secur32.lib winmm.lib

这里/EHsc是启用 C++ 异常处理，虽然这段代码没用异常，但后续扩展大概率会用到；/I include指定头文件路径；链接时把核心库和系统库都列出来。swscale.lib和swresample.lib压缩包里也有对应实现，分别负责像素格式转换和音频重采样，解码播放场景基本都要用到，所以直接加上。

4. 避坑记录：静态链接 ffmpeg 最常见的五个翻车现场

4.1 链接报错 LNK2005：libc.lib 冲突

现象：链接时出现LNK2005 _printf already defined in libc.lib(printf.obj)之类的大量重复符号错误，有时还会伴随LNK1169 找到一个或多个多重定义的符号。

原因：这是 ffmpeg 静态库使用了不同版本的 CRT（C 运行时库）导致的。VS2015 默认的 CRT 链接模式有/MT（静态链接）和/MD（动态链接）两种，如果编译 ffmpeg 时用的是/MD，而你的工程用的是/MT，链接器会尝试同时引入两个版本的 CRT 实现，符号自然就冲突了。

解决：打开工程属性 → C/C++ → 代码生成 → 运行时库，把选项改成和 ffmpeg 编译时一致的模式。一般静态库的发布说明里会写清楚用的哪种，如果没写，先试/MD，不行再换/MT。改完后重新生成，错误基本消失。这个问题我从 VS2013 时代就见过，和版本无关，是 CRT 选型不一致的经典症状。

4.2 运行时报 0xc000007b：程序启动即崩

现象：exe 编译链接都成功，双击运行时直接弹“应用程序无法正常启动 0xc000007b”，没有任何日志。控制台程序在 VS 里按 F5 也可能弹出同样的错误。

原因：这个错误码在 Windows 下几乎可以断定是架构不匹配或 DLL 加载失败。静态库方案下 DLL 不是 ffmpeg 的，而是系统或第三方运行库的。最常见的情况是：工程是 x64 平台，但链接了 x86 的 lib；或者反过来，把 Debug 和 Release 的配置搞混了。

解决：先去工程属性页确认“平台”是 x64 还是 Win32，然后去“链接器 → 命令行”看实际传给 link.exe 的库路径，确认路径里是 x64 目录下的 lib。再用 dumpbin 工具验证 exe 的机器类型：dumpbin /headers decode_demo.exe，输出里会出现machine (x64)或machine (x86)，和 lib 的架构做比对。这不是玄学，就是指向性最强的检查序列。

4.3 无法解析的外部符号 __imp_XXX

现象：链接阶段报几百条unresolved external symbol __imp_avcodec_open2或__imp_av_read_frame，格式是__imp_前缀加 ffmpeg 函数名。

原因：看到__imp_前缀就能判断，这是 MSVC 为动态库导入函数生成的修饰名。编译器认为这个函数是__declspec(dllimport)导出的，会额外生成一层间接调用。静态库里的函数没有这种修饰名，两者对不上。根本原因是代码里（或某个头文件里）声明了__declspec(dllimport)标记，常见于从动态库方案迁移过来的工程，忘却删掉#define FF_API_DLLIMPORT之类的宏。

解决：检查头文件里是否有#define avcodec_open2 avcodec_open2这种映射宏，有的话删掉；再查工程里是否定义了_DLL或AVCODEC_DLL。如果是从网上找的 demo 代码，搜一下是否有__declspec(dllimport)，全部清掉。干净的方式是在包含 ffmpeg 头文件之前，加一行#define FF_API_OLD_BSF 0之类的兼容性开关，但这只对部分版本有效，最可靠的还是直接清理代码里的 dllimport 声明。

4.4 内存持续增长：解码 500 帧后占用 300 MB

现象：解码循环能跑，帧率正常，但内存占用线性增长，跑几分钟后程序明显卡顿。

原因：AVPacket 内部的 buffer 引用没有释放。很多人只写了av_packet_alloc()一次，循环里每次都往同一个 pkt 塞新数据，但忘了av_packet_unref(pkt)。ffmpeg 的av_read_frame内部会给 pkt 分配新的缓冲，如果上一帧的 buffer 还挂着引用，新分配就会叠加而不是复用。同样的道理适用于 AVFrame：av_frame_unref(frame)也要在每帧处理完后调用，否则 frame 内部的数据缓冲会越积越多。

解决：在av_read_frame成功之后立刻av_packet_unref(pkt)，无论这个包是否被解码器消费。对于 AVFrame，在avcodec_receive_frame返回AVERROR(EAGAIN)或AVERROR_EOF时，也要调用av_frame_unref(frame)清理。一个更稳妥的写法是每次循环开头都av_packet_unref(pkt)，保证上轮残留不影响本轮。这种内存问题用任务管理器盯到 300 MB 就能确认，不用上内存分析器。

4.5 avcodec_parameters_to_context 后 width 和 height 为 0

现象：按上面 demo 步骤执行，avcodec_open2正常，但codec_ctx->width和height打印出来是 0，解码出来的帧也全黑或全灰。

原因：avcodec_parameters_to_context只复制了编码参数，但不一定能把所有上下文字段填满。在 n4.4.1 里，AVCodecParameters不带width、height之外的扩展字段（比如显式地存 SAR、颜色空间），部分容器格式下这些值需要从AVFormatContext的流信息里单独取。更常见的原因是：调用avformat_find_stream_info之前就执行了参数复制，此时codecpar里的字段还没有被解析填充完整。

解决：确保avformat_find_stream_info先执行，再取codecpar。如果 width 还是 0，手动从fmt_ctx->streams[idx]->codecpar->width赋值给codec_ctx->width，虽然这是补丁式做法，但确实有效。真正要查的是avformat_find_stream_info的返回值，小于 0 说明文件读取不完整或格式识别失败，尽早暴露比硬撑到解码阶段更好。

5. 项目实战选型：静态库、动态库与全静态编译的边界在哪里

5.1 静态库方案的两个真实短板

静态库不是银弹，它有两个短板必须在项目规划前想清楚。第一是 exe 体积显著膨胀：ffmpeg 的 lib 全部链接进来后，Release 版 exe 体积通常在 15～30 MB 之间（取决于裁剪了多少模块）。对安装包体积敏感的产品，这个体积可能成为问题，要么换动态库方案，要么用编译选项裁剪不需要的协议和编解码器。第二是安全补丁的更新成本：如果 ffmpeg 爆出高危漏洞（历史上确实有过），动态库方案只需要替换一个 dll，静态库方案要重新编译整个工程并重新发布 exe。

5.2 什么时候别用静态库：动态库仍是更优解的场景

插件架构的应用场景不要用静态库。如果你写的是 Photoshop 插件、浏览器插件、或者需要被多个进程动态加载的模块，静态链接会导致同一个 exe 里嵌入多份 ffmpeg 代码，内存浪费且符号冲突风险极高。其次，涉及 GPL 合规的要注意：ffmpeg 的某些编译选项会引入 GPL 授权的代码（比如 libx264），静态链接意味着你的 exe 整体可能被认定为衍生作品，需要开源。如果产品是闭源商业软件，这既是法律问题，也是实际的发布风险。

5.3 轻量裁剪与后续替换建议

如果你决定用这套静态库做正式项目，建议按功能裁剪 lib。压缩包里附带的 lib 是全功能版本，链接后体积偏大。一个常见的裁剪思路是：只链接avcodec.lib、avformat.lib、avutil.lib和你实际用到的解码器对应的 lib，然后通过avcodec_register_all系列函数只注册需要的那几个解码器。n4.4.1 里注册函数是avcodec_register_all()，如果只想注册 H.264 解码器，可以手动调用avcodec_register(&ff_h264_decoder)，这样做的前提是你的工程里引用了特定的符号。但这种裁剪有一个隐蔽的坑：链接器不会把未被引用的 lib 代码拉进来，但ff_h264_decoder是全局符号，需要显式声明来“强制引用”，否则链接器依然不会包含它。

新版本 ffmpeg 的 API 有变动时，这套 n4.4.1 库对应的代码同样适用大部分旧代码，但要注意：avcodec_register_all在 n5.0 之后会废弃。如果你的团队后续要升级到 n5.x，建议尽早把代码改为走av_codec_iterate的迭代方式，而不是依赖注册表函数。

6. 验证静态库版本与部署独立 exe 的最终检查单

拿到压缩包后，做一套标准验证流程，确认这套库在你的环境里是可用且稳定的。第一件事是先做“头文件与库匹配验证”：在工程里打印LIBAVCODEC_VERSION_MAJOR、LIBAVFORMAT_VERSION_MAJOR等宏，与 n4.4.1 的标准版本号比对。n4.4.1 对应的 avcodec 主版本是 58，avformat 是 58；如果打出来是 57 或 59，说明头文件和 lib 不是同一版本来源，整个项目要推倒重查。

第二件事是验证静态链接的彻底性：链接完成后，用dumpbin /dependents decode_demo.exe查看 exe 的导入表。理想情况下只能看到 kernel32.dll、user32.dll、ws2_32.dll 这些系统库，绝不能出现 avcodec.dll、avformat.dll 这类第三方动态库。如果导入表里有 ffmpeg 相关 dll，说明你真的链接错了库，或者把静态库和动态库混用了。

第三件事是在一台干净的 Windows 虚拟机或未安装 VS 的机器上跑一下 exe。这是“独立 exe”的最终验收标准。开发机上跑得通不算数，因为开发机已经装了 VS 的调试运行库，掩盖了潜在的 CRT 依赖问题。把 exe 放进 U 盘，插到一台纯 Windows 10 系统上，双击能跑出解码结果才算真正的独立可部署。

最后一件事是写一个自动验证脚本。我一般习惯用一条批处理命令连续跑三个测试视频，一个 1080p H.264、一个 4K HEVC、一个音频与视频混合的 MKV，输出帧数对比上次跑的结果，做回归验证。这样的意义在于：当你改了工程配置、切了 Debug/Release 模式或换了目录之后，跑一遍脚本，帧数和宽高对得上，比肉眼盯着画面靠谱得多。

那次我接手一个项目，link 阶段又是 LNK2005，又是 0xc000007b，从下午折腾到凌晨。后来养成的习惯是：第一次进工程先把运行时库和附加依赖项截图存档，改任何配置前先对照存档再动手，从那以后基本没再翻过车。希望帮到你。

本文还有配套的精品资源，点击获取