简介面向 Windows 平台开发者的 FFmpeg 4.4.1 静态库编译包可直接集成到 Visual Studio 2015 工程中同时提供 32 位与 64 位两套静态库文件适合需要发布独立可执行程序、省去动态库部署环节的音视频编解码开发场景也适合需要在本地快速验证编码格式与封装能力的工程技术人员。压缩包共 140 个文件其中 125 个头文件覆盖常用音视频接口14 个 lib 静态库用于最终链接另有 1 份文本说明静态编译时需额外附加的依赖项整体大小约 28.78 MB目录结构清晰方便查找所需文件。该版本为最新编译且已验证可用能够省去自行构建 FFmpeg 的繁琐流程帮助开发者把更多时间放在滤镜调用、格式封装和播放控制等实际功能上。目前已有 457 人学习下载适合正在搭建本地 FFmpeg 环境或准备在 Windows 下分发免安装程序的开发者。1. 在 VS2015 里自编译 ffmpeg 静态库一个能长期复用的交付方案做 Windows 桌面音视频播放器或者转码工具的人大概率都有过这样的经历从网上下载的 ffmpeg 二进制要么缺 dll要么版本和头文件对不上想调一个 API 还要对着错误的符号猜半天。与其到处找别人编好的包不如自己用 vs2015 编译一套 x86/x64 的静态库(.lib)——把 avcodec、avformat、avutil、swscale 这些库全部静态链进自己的 exe运行目录干净换机器也不会因为缺 ffmpeg 运行时而翻车。这个方案适合手里有 VS2015 开发环境、想把音视频编解码能力内嵌到自有产品里的工程师过程不复杂但有几个决定成败的细节下文一章一章拆开说。2. 静态库(.lib)构建前要懂的 4 件事选型、工具链、汇编与 configureffmpeg 从来不是一个库而是一组库解封装靠 avformat编解码靠 avcodec公共工具和数据结构在 avutil像素格式转换靠 swscale音频重采样靠 swresample。按标题“音视频/编解码”的诉求静态库方案要把这一整套全部编进去。动手之前先把四个问题想明白后面能省下大量返工时间。2.1 静态库还是动态库你的播放器到底需要哪种 .libffmpeg 在 Windows 下的产物分两类共享库dll 加导入库和静态库。很多人误以为带 .lib 的都是静态库其实共享库也会生成一个很小的导入库 .lib里面只有函数跳转表真正的代码在 dll 里。标题里写的静态库(.lib)指的是把目标代码直接打包进 .lib 文件链接时整体进 exe。对比项静态库(.lib)动态库(dll)部署一个 exe 搞定不用带 ffmpeg 运行库需要附带多个 dll版本一换就全乱体积库代码全部进 exe体积大dll 独立exe 小升级重新编译整个软件替换 dll 即可热更新ABI 稳定性头文件与库打包在一起编译期锁死头文件与 dll 分开发布接口容易错位自己做播放器、转码 SDK 交付给客户我会直接选静态库。理由是版本可控ffmpeg 的 API 每个版本都有潜在不兼容动态 dll 方案里最怕的就是客户机器上被其他软件覆盖了同名 dll。静态库把所有代码链死进 exe运行阶段不会再出现装错版本这种“黑匣子”问题。2.2 为什么选 VS2015 原生工具链而不是 MinGW 的 .aWindows 下编译 ffmpeg 最常见的两条路线是 MSYS2/MinGW 和 MSVC 原生。MinGW 编出来的库后缀是 .aVS 的 link.exe 根本认不了即便强行用工具把 .a 转成 .lib也会遇到 name mangling 不一致、函数调用约定不匹配、结构体对齐方式不同等一串连锁问题。所以标题明确了 vs2015 环境就走 MSVC 原生路线configure 时指定 --toolchainmsvc编译器用 cl链接用 link归档用 lib全程 VC 工具链。ffmpeg 对 MSVC 的支持不是最近才有的老分支上已经打磨得很稳。VS2015 自带的是 MSVC 19.0 编译器C 语言标准支持停留在 C99 部分补齐的水平配 ffmpeg 4.x 系列非常顺越新的 ffmpeg 分支对编译器版本要求越高不是不能用而是容易在晦涩的语法检查上报错为了一个播放器去换整个 IDE 不划算。2.3 nasm 不是可选项x86/x64 汇编优化决定了编码速度ffmpeg 的解码、编码、像素缩放、音频重采样里有大量 SIMD 汇编实现这些汇编会被编进静态库运行时不依赖任何外部 dll。x86 和 x64 各自有一整套针对指令集优化的函数比如 H.264 解码的运动补偿、HEVC 的 IDCT、swscale 的 RGB 转换。汇编实现的性能比纯 C 的 fallback 高出一个量级关掉汇编优化后最直观的后果就是本地 1080p 视频解码都能把 CPU 吃满。ffmpeg 4.x 默认用 nasm 作为 x86 汇编器configure 里对应开关是 --enable-x86asm再早一点的分支用的是 yasm。无论哪种构建机里必须有一个能工作的 nasm并且要能被 configure 找到。这个点不是“可选项”它直接决定你做出来的音视频编解码库是成品还是半成品。2.4 configure 核心参数逐项拆解toolchain、static、arch、asmconfigure 是整个构建流程真正的大脑常见的参数就这几组组合起来含义很清楚。参数取值举例作用--toolchainmsvc让构建系统把 cc 映射到 cl、ld 映射到 link、ar 映射到 lib--archx86 / x86_64指定目标架构x86 是 32 位x86_64 是 64 位--enable-static无生成静态库--disable-shared无禁止生成 dll和 --enable-static 成对出现--enable-x86asm无启用 nasm 汇编优化--disable-programs无不生成 ffmpeg.exe、ffprobe.exe只留库--prefix绝对路径make install 时头文件和库的安装目录注意一个容易忽略的点ffmpeg 的 configure 默认会把内置的解码器、编码器、解封装、封装、滤镜全部选中。也就是说按上面的参数编出来的静态库本身已经覆盖了标题里“音视频/编解码”的绝大多数场景不需要再单独拉 libx264 之类的外部依赖。真正要精打细算做裁剪的人反而容易踩坑这个留在第 5 章展开。3. 环境准备VS2015、nasm、源码与 GNU make理论部分落到两根线了一条是 MSVC 原生编译 ffmpeg 的选型理由一条是 configure 参数组的含义。从这一章开始动手。前提是一台已经安装 VS2015 的 Windows 机器下面每一步都给出验证命令跑不过就停下来查。3.1 VS2015 组件勾选与命令行入口x86 和 x64 从哪里进安装 VS2015 时关键是不要只装 IDE要保证“Visual C”组件和配套的 Windows SDK 被选中。很多人安装时图省事只选了默认功能结果没有 cl.exe后面 configure 第一步直接失败。安装完成后不需要打开 IDE构建走的是命令行。开始菜单里会出现两个关键入口名字类似“VS2015 x86 Native Tools Command Prompt”和“VS2015 x64 Native Tools Command Prompt”。前者默认输出 32 位程序后者默认输出 64 位程序。标题要的是 x86/x64 两套静态库所以两个入口都会用到。打开后先验证编译器可用cl正常会输出一长串编译器版本信息说明 VC 环境已经就绪。如果提示“cl 不是内部或外部命令”基本可以判定是组件没装全回去重装并勾选 VC 工具集。这一步看着简单却是后续所有命令能跑起来的地基。3.2 安装 nasm 并加入 PATHnasm 是 4.x 分支唯一的汇编器。去 nasm 官网下载 Windows 安装包建议选择 64 位版本它同时支持输出 32 位和 64 位目标文件一套汇编器管两个架构。安装路径默认在 C:\Program Files\NASM安装完成后把该目录追加到系统 PATH或者至少在当前命令行窗口里手动加一下。set PATHC:\Program Files\NASM;%PATH% nasm -vnasm -v能输出版本号就算过了。configure 在检查汇编器时直接依赖 PATH找不到的话会静默关闭 x86asm 优化最难受的是它不报错只是构建出来的库性能很差。所以这一步宁可用大白话验证三遍也别跳过。3.3 拉取 ffmpeg 源码版本别追新目录别带空格源码可以从官方 Git 仓库拉取也可以直接下载指定版本的 tar.xz 压缩包。考虑到 VS2015 的编译器比较老我一般固定到 4.4 分支比如 n4.4.4 这个 tag。ffmpeg 5.x 之后的源码对标准 C 语法要求更高VS2015 硬编也能出库但会遇到各种极其晦涩的编译报错排查起来性价比太低。做音视频编解码库不是追新框架“能反复构建出稳定产物”比“版本最新”重要得多。源码解压后建议放在无空格的路径比如 D:\ffmpeg-src\而不是 Program Files 下。ffmpeg 构建要经过 MSYS2 的 sh 解释器路径带空格时configure 里的相对路径拼接会时好时坏属于典型的玄学问题。随后建两个输出目录采用 out-of-tree 构建一份源码共用于 x86 和 x64mkdir D:\ffmpeg-build\build-x86 mkdir D:\ffmpeg-build\build-x64这两个目录分别保存两套构建中间产物互不干扰。编完 x86 再编 x64 时不用清缓存这是 ffmpeg 支持的标准构建方式。4. 一次跑通 x86/x64 两套静态库完整命令与参数环境齐了进入正题。这一步的命令我在多台机器上跑过按顺序执行基本不会出错。核心思路是VS2015 命令行负责提供 cl 和 linkMSYS2 只提供 make 和 shnasm 负责汇编configure 把三者串起来。4.1 用 VS2015 命令行 MSYS2 的 make 组合构建环境ffmpeg 的构建系统是 POSIX shell 脚本加 GNU MakefileVS2015 自带的 nmake 读不了这种 Makefile所以还需要一个 MSYS2。装完 MSYS2 后打开其 shell安装构建要用的两个小工具pacman -S make diffutilsdiffutils 里的 cmp/diff 命令会在 configure 阶段处理源码文件比较不装的话也会在奇怪的地方失败。装完后回到 VS2015 的 Native Tools 命令行把 MSYS2 追加到 PATH 末尾set PATHC:\Program Files\NASM;%PATH%;C:\msys64\usr\bin这条命令的 PATH 顺序有讲究。MSYS2 的 usr\bin 里也有一个 link.exe那是 GNU coreutils 的硬链接工具和 VC 的链接器同名。如果把它放在 VS 的 link.exe 前面make 调用 link 时就可能被顶替报出一堆完全看不懂的错误。把 MSYS2 追加到末尾cl 和 link 还是优先用 VC 的make 和 sh 又都能被找到。验证一下三个工具都在位cl make -v | findstr GNU nasm -vcl 有版本输出make 显示 GNU Makenasm 显示版本号环境就绪。注意这一步做的是 x86 构建时就用“x86 Native Tools Command Prompt”做 x64 构建时换“x64 Native Tools Command Prompt”。4.2 x86 静态库configure、make、install 一条龙下面是一份完整的 x86 构建脚本建议直接存成 build-x86.bat 再运行比手动敲命令稳。echo off setlocal set PATHC:\Program Files\NASM;%PATH%;C:\msys64\usr\bin cd /d D:\ffmpeg-build\build-x86 sh ../../ffmpeg-src/ffmpeg-4.4.4/configure ^ --toolchainmsvc --archx86 ^ --enable-static --disable-shared ^ --enable-x86asm ^ --disable-programs --disable-doc --disable-debug ^ --prefixD:\ffmpeg-build\ffmpeg-x86 if errorlevel 1 exit /b 1 make -j8 if errorlevel 1 exit /b 1 make install echo build-x86 done逐段说明cd 进入构建输出目录sh 后面跟的是源码目录下的 configure 脚本路径因为 build-x86 在 D:\ffmpeg-build 下面源码在 D:\ffmpeg-src 下面所以用 ../../ffmpeg-src/ffmpeg-4.4.4/configure 相对路径。--toolchainmsvc 指定 MSVC 编译器--archx86 指定 32 位目标。--enable-static 和 --disable-shared 是这整套配置的核心保证只产出 .lib 不产出 dll。--enable-x86asm 明确开启汇编优化--disable-programs 省去编译 ffmpeg.exe、ffprobe.exe 的时间--disable-doc 跳过文档--disable-debug 去掉调试符号让库体积更小。--prefix 是安装目录make install 会把头文件复制到 D:\ffmpeg-build\ffmpeg-x86\include把静态库复制到 D:\ffmpeg-build\ffmpeg-x86\lib。make -j8 用 8 线程并行编译机器配置低可以改成 make -j4。这里不传 -MT 或 -MD因为 VS2015 下默认按动态 CRT 编运行时库一致性的问题留到第 5 章讲。整个脚本执行完看到 echo 的 done 就说明 x86 静态库构建成功。4.3 x64 静态库只有 arch 与输出目录不同x64 构建几乎一模一样只是把命令行入口换成“VS2015 x64 Native Tools Command Prompt”然后改三个地方构建目录、arch 参数、prefix。保存一份 build-x64.batecho off setlocal set PATHC:\Program Files\NASM;%PATH%;C:\msys64\usr\bin cd /d D:\ffmpeg-build\build-x64 sh ../../ffmpeg-src/ffmpeg-4.4.4/configure ^ --toolchainmsvc --archx86_64 ^ --enable-static --disable-shared ^ --enable-x86asm ^ --disable-programs --disable-doc --disable-debug ^ --prefixD:\ffmpeg-build\ffmpeg-x64 if errorlevel 1 exit /b 1 make -j8 if errorlevel 1 exit /b 1 make install echo build-x64 done注意 configure 对 64 位架构的写法是 --archx86_64不是 x64。其他参数保持一致。x86 和 x64 两套库是完全独立的文件分别落在 ffmpeg-x86 和 ffmpeg-x64 两个目录不能互换使用。有人尝试只编一套 x64 然后给 32 位程序用运行阶段会出各种莫名其妙的崩溃属于最经典的自找麻烦。4.4 构建成功的判断标准头文件、.lib 与日志脚本跑完不要急着写代码先确认产物结构。以 x86 为例检查安装目录dir D:\ffmpeg-build\ffmpeg-x86\lib dir D:\ffmpeg-build\ffmpeg-x86\includelib 目录下应该能看到 avcodec.lib、avformat.lib、avutil.lib、swscale.lib、swresample.lib、avfilter.lib、avdevice.lib 这些核心静态库include 目录下应该有 libavcodec、libavformat、libavutil 等头文件目录。如果只有一两个库说明 configure 参数没生效回去看执行 configure 时的输出日志。configure 结束时屏幕上会打印一长串 enabled 列表。重点找这几行toolchain 显示 msvc、static 显示 yes、shared 显示 no、x86asm 显示 yes。x86asm 一旦显示 no即使构建成功编解码性能也大概率不达标回到第 3.2 节检查 nasm 的 PATH。另外窗口里任何 “ERROR:” 开头的行都要先解决再继续别抱着“可能能过”的侥幸心理往下跑。5. 链接与使用的坑外部符号、CRT、nasm 与解码器库编出来只是第一步。真正开始链接进自己的播放器工程时坑才一个接一个浮出来。下面 5 个问题按出现频率排序每一条都按现象、原因、解决的顺序写都是实际踩过的。5.1 一堆“无法解析的外部符号”补上系统库就安静了现象把 avcodec.lib、avformat.lib 加进工程后链接报出一大片 unresolved external symbol有些函数名看着像 avcodec 内部符号有些则是从没见过的系统 API。原因ffmpeg 在 Windows 下的静态库依赖若干系统库但 MSVC 的 .lib 不会自动传递这些依赖需要你在工程里显式追加。缺的核心库是 ws2_32.lib这是 Winsock网络拉流、推流、音视频封装里大量用到还有 secur32.lib 和 bcrypt.lib 负责加密和随机数strmiids.lib 是 DirectShow 相关接口的 GUID 符号avdevice 里常用。解决在 VS 工程属性页里找到“链接器→输入→附加依赖项”一次性追加ws2_32.lib secur32.lib bcrypt.lib strmiids.lib ole32.lib user32.lib把这一组全加上多补无害。这一步做完绝大多数外部符号错误直接消失。如果还有个别未定义符号多半是调用了 avdevice 里的 Windows 设备接口再加一个 dxguid.lib 就能覆盖。5.2 工程编译通过但运行崩溃/MT 与 /MD 的 CRT 冲突现象静态库链接非常顺利exe 也生成成功但跑起来后在 avformat_open_input 或解码初始化附近崩溃错误表现不稳定有时候是断言框有时候直接访问违例。原因VS2015 工程默认把“运行时库”设为 /MD也就是动态链接到通用 CRT而我前面给的 configure 命令没有显式指定ffmpeg 静态库在 MSVC 工具链下默认也是 /MD理论上应该一致。但很多开发拿到的 ffmpeg 构建脚本会自带 --extra-cflags-MT如果你的工程是 /MD两者混用时两个 CRT 各有一份堆、errno、FILE 状态代码跨边界分配和释放内存就会出问题。解决保证 ffmpeg 静态库和主工程用同一套运行时库。想要发布时 exe 不依赖 vc_redist就在 configure 时加 --extra-cflags-MT工程里也把“运行时库”选成“多线程(/MT)”追求调试方便就两边都用 /MD。关键是“两边统一”单边改动都是白费。5.3 configure 报告 x86asm not found 或汇编没生效现象configure 执行完日志里 x86asm 显示 no或者没注意继续构建最后编出来的库播放高清视频掉帧严重。原因nasm 不在 PATH或者安装的是非常老的版本。configure 对 nasm 的检测是静默的找不到就放弃汇编优化不会中断构建。很多人第一次编 ffmpeg 就是在这里无声地拿到一个性能残废的库。解决先跑 nasm -v 确认命令存在。确认存在后重新执行 configure不需要删掉 build 目录configure 会重新检测。还不行就在 configure 命令行末尾显式指定--x86asmexenasm这个参数让 configure 直接使用名为 nasm 的可执行文件。构建完成后再次回看日志x86asm 必须显示 yes 才算真正生效。5.4 编出来的库解不了 H.265是不是动过裁剪开关现象代码里调用 avcodec_find_decoder(AV_CODEC_ID_HEVC) 返回空指针或者 avcodec_open2 返回一个负数错误码典型的错误码是 -1094995529即 AV 错误里的 decoder not found。原因configure 命令里加了 --disable-everything 或者只放行了一部分 --enable-decoder...把 hevc 解码器裁掉了。内置的 H.264、HEVC 解码器不依赖 libx264、libx265它们就在 avcodec 里只要不主动裁剪默认都会编进静态库。解决没有特殊体积需求就不要加任何 disable 解码器的参数保持默认全量编入。如果确实为了裁剪体积要明确补回所需模块--enable-decoderh264,hevc,mpeg4 --enable-parserh264,hevc --enable-demuxermov,flv,mp4,mkv注意裁剪是连锁的只开解码器不开 parser很多封装格式照样跑不起来。另外libx264/libx265 是编码器H.264/H.265 解码不需要它们“只做播放器”的情况下这些东西完全可以不编。5.5 x86 和 x64 的 .lib 混用链接器无提示、运行时出错现象Win32 工程配了 x64 的 avcodec.lib链接阶段有时会提示 machine type 冲突更多时候是直接通过、运行即崩崩溃位置毫无规律。原因VS 的工程配置默认 Debug/Release 是按平台分开的但“附加依赖项”里的 .lib 文件路径经常被手改成固定的某个目录导致 32 位工程链接到 64 位库。解决在工程里分别配两份库目录Win32 平台指向 ffmpeg-x86\libx64 平台指向 ffmpeg-x64\lib。验证库的架构用 dumpbindumpbin /headers D:\ffmpeg-build\ffmpeg-x64\lib\avcodec.lib | findstr /i machine输出会显示 machine (x64) 或 machine (x86)。这是唯一的权威判断标准不要依赖文件名。两套库并存时养成“先看 machine 再进工程”的习惯能少走很多弯路。6. 用最小 C 工程验证 .lib 能链接能跑6.1 30 行代码验证解码器与解封装都正常库文件确认完整、架构确认无误后不要急着写业务代码先用一个最小工程把“能不能链接、能不能打开文件、能不能找到解码器”三个问题验证掉。新建一个空 C 控制台工程包含目录指向对应架构的 include库目录指向 lib附加依赖项填 avformat.lib、avcodec.lib、avutil.lib 以及第 5.1 节那组系统库。extern C { #include libavformat/avformat.h #include libavcodec/avcodec.h } #include cstdio int main(int argc, char** argv) { if (argc 2) { printf(usage: probe media-file\n); return 2; } av_log_set_level(AV_LOG_ERROR); AVFormatContext* fmt nullptr; if (avformat_open_input(fmt, argv[1], nullptr, nullptr) 0) { printf(open failed\n); return 1; } if (avformat_find_stream_info(fmt, nullptr) 0) { printf(find stream info failed\n); avformat_close_input(fmt); return 1; } printf(format: %s, streams: %u\n, fmt-iformat-name, (unsigned)fmt-nb_streams); for (unsigned i 0; i fmt-nb_streams; i) { const AVCodec* codec avcodec_find_decoder( fmt-streams[i]-codecpar-codec_id); printf( stream %u: %s, codec %s\n, i, avcodec_get_name(fmt-streams[i]-codecpar-codec_id), codec ? codec-name : no-decoder); } avformat_close_input(fmt); return 0; }这段代码做的事是打开一个媒体文件打印封装格式名称然后逐条流打印编码类型和解码器名称。如果 avcodec_find_decoder 返回空就会显示 no-decoder说明库里的解码器被裁剪过回到第 5.4 节检查 configure 参数。整个验证工程能跑通静态库的链接问题基本就全部解决了。我自己的习惯是把第 4 章的两个 bat 脚本和这个 probe 工程固定保存下来换机器或者升级 ffmpeg 分支时只改路径和版本号重新执行一遍就能拿到两套可用的 x86/x64 静态库。这套流程跑顺之后我再也没碰过网上那些来路不明的“已编译 ffmpeg 包”。希望帮到你。本文还有配套的精品资源点击获取