FFmpeg 4.3 win32 GPL shared：老Windows环境下最稳的转码工具

简介：这是作者基于FFmpeg 4.3.1源码（2021年1月19日拉取）自行编译的Win32平台SDK开发包，面向需要在32位Windows环境下进行音视频处理或二次开发的C/C++开发者。由于官方长期未提供Win32预编译库，这份资源直接解决了找库难、自编译环境配置复杂的问题。整个压缩包共191个文件，体积约27.32MB，核心内容涵盖126个头文件、30个HTML说明文档、8个DLL动态库、8个LIB导入库、8个DEF导出定义文件、8个MinGW风格.a静态库以及3个可执行工具，既可用于运行时部署也可用于链接开发。相比许多仅有可执行文件的FFmpeg版本，这里完整保留了API头文件与链接库，可直接创建Win32工程并调用libavcodec、libavformat等模块，省去自行编译的繁琐步骤。该资源目前已有852人下载学习，对于受困于Win32平台FFmpeg集成难题的开发者来说，是一份实用且少见的现成SDK。 说实话，第一次看到ffmpeg-4.3-win32-gpl-shared-20210119.zip.zip这个文件名的时候，我愣了一下——怎么会有两个.zip？但这几年用下来，我反而觉得这个“重复后缀”的压缩包，是很多老 Windows 环境下最靠谱的 FFmpeg 版本之一。今天想围绕这个包好好聊一下：FFmpeg 4.3 这个版本号意味着什么，win32、GPL、shared 这些参数到底影响什么，以及在实际使用中踩过哪些坑、有哪些可以直接照抄的命令。

如果你手头是 Win7 32 位老机器、需要把一个 FFmpeg 集成进 32 位程序，或者想找一个带 libx264 的稳定版本，这篇文章应该对你有用。就算你用的不是这个具体构建版本，里面的排查思路和命令技巧也基本是通用的。

1. 先看懂文件名：ffmpeg-4.3-win32-gpl-shared 到底在说什么

很多新手拿到压缩包第一件事就是解压，然后发现里面是一堆 DLL 文件，顿时不知道该点哪一个。其实文件名已经把最重要的信息都写清楚了：软件名、版本号、目标平台、许可证类型、链接方式，以及构建日期。

1.1 版本号 4.3 的特殊位置

FFmpeg 的版本迭代节奏不算快，每个大版本之间通常会隔半年到一年。4.3 版本发布于 2020 年中，属于 4.x 系列里比较成熟的一代。它既不像 4.0 那样刚切换到新的avformat接口时有一堆兼容性问题，也不像后来 5.x、6.x 那样改动太大，很多老项目不敢轻易升级。

从功能上看，4.3 已经支持了比较完整的 AV1 解码（dav1d），对 HLS、DASH 的封装也做了不少优化，-c copy这种流拷贝模式下处理 M4S、TS 分片的能力很稳。最关键是，这个版本里很多常见编码器（libx264、libmp3lame）的行为已经和现在差别不大了，网上绝大多数教程、博客、封装库也都是基于 4.x 写的，照抄命令基本不会翻车。

文件名后的20210119是构建日期，也就是 2021 年 1 月 19 日打的包。这并不代表它只能用到那天，而是说明这个二进制是针对当时最新的 4.3 分支修复代码编译出来的。至于zip.zip，多半是下载站或网盘自动给文件加了.zip后缀，解压一次后里面还有一个压缩包，再解压一次才会看到完整目录，不用太担心。

1.2 win32、GPL、shared 三个关键参数

这几个字段直接决定了这个包能不能在你的机器上跑，以及你能用它编码什么格式。我用一个表格总结一下：

我见过很多人在 64 位机器上装了这个 32 位版本，发现能正常跑ffmpeg -version，就误以为 win32 没影响。真正要注意的是：如果你要编写 64 位程序并调用 FFmpeg，这个包的 include 和 lib 是 32 位的，链接时会报错。反过来，如果写的是 32 位程序，用它倒是正好。

GPL 和 LGPL 的区别也很实际。LGPL 构建通常不带 libx264、libx265 这类 GPL 编码器，好处是动态链接时可能不强制开源你的主程序；但如果你只想老老实实转码，GPL 版本开箱即用，能直接-c:v libx264，不用再折腾 x264 的 extern 库。这个包就是 GPL 版本，所以编码 H.264 是没问题的。

至于 shared 和 static，网上有人喜欢 static 单文件版，扔哪都能跑。但 shared 版把 FFmpeg 拆成一堆 DLL，比如avcodec-58.dll、avformat-58.dll、swscale-5.dll等，好处是如果你只用到某个库，可以少带文件；坏处是 DLL 缺失或版本冲突时会报错。后面我会专门讲这些坑。

2. 安装部署与验证：别把压缩包下载完就以为会用了

这个版本不像 Insta 安装包，解压完还要手动配路径。我第一次用的时候以为 bin 目录里那个ffmpeg.exe双击就能用，结果弹了个黑窗口瞬间闪退，后来才意识到是缺 DLL。

2.1 解压后你应该看到的目录结构

把zip.zip处理干净后，最终解压出的目录一般是这样的：

ffmpeg-4.3-win32-gpl-shared ├── bin │ ├── ffmpeg.exe │ ├── ffprobe.exe │ ├── avcodec-58.dll │ ├── avformat-58.dll │ ├── avutil-56.dll │ ├── swresample-3.dll │ ├── swscale-5.dll │ ├── libgcc_s_dw2-1.dll │ ├── libstdc++-6.dll │ └── libwinpthread-1.dll ├── include │ ├── libavcodec │ ├── libavformat │ ├── libavutil │ └── ... ├── lib │ ├── avcodec.lib │ ├── avformat.lib │ └── ... └── presets ├── libx264-veryfast.ffpreset └── ...

bin是命令工具和运行时 DLL 所在地，日常用ffmpeg.exe；include和lib是给开发者看和链接用的，如果你用 C/C++ 调用 FFmpeg API，这两个目录必须配置到工程里；presets里是一些预设文件，命令行工具会自动识别。

2.2 配置环境变量和快速验证

我习惯把整个目录放到一个纯英文路径下，比如C:\ffmpeg-4.3-win32-gpl-shared，然后手动把C:\ffmpeg-4.3-win32-gpl-shared\bin加入系统 PATH。

验证是否成功，别直接双击 ffmpeg.exe，那东西没参数会直接打印帮助然后退出。正确方法是打开 cmd 或 PowerShell，输入：

ffmpeg -version

如果能看到类似ffmpeg version 4.3.x的输出，并且没有弹窗报缺少 DLL，说明配置成功了。再进一步检查编码器：

ffmpeg -encoders | findstr /i "264"

如果输出里有libx264，就说明 GPL 版的核心编码器就位了。这一步很重要，因为有些精简版 FFmpeg 是没有 libx264 的。

2.3 集成到 32 位程序时的特殊注意事项

如果你和我一样，是为了给旧项目集成语音转码功能才用这个版本，那配置方式就不只是加 PATH 这么简单了。用 Visual Studio 或 CLion 项目时，需要把include目录加进头文件搜索路径，把lib目录加进库文件路径，然后记得在调用 FFmpeg API 前用extern "C"包裹头文件，否则 C++ 链接会报一堆莫名其妙的 unresolved external symbol。

运行程序时，光把avcodec.dll复制到 exe 旁边还不够。我的经验是：直接把 bin 里的所有 DLL 都复制到 exe 输出目录，别想着省空间。因为 FFmpeg 的这些 DLL 之间有依赖关系，比如avformat.dll依赖avcodec.dll和avutil.dll，少一个都不行。

3. 基于 4.3 的实战命令：从转码到修复，一次说透

FFmpeg 命令网上千千万，但很多帖子根本不告诉你为什么这么写。我挑几个这个版本最常用、且我自己验证过没问题的场景，把参数逻辑也说清楚。

3.1 最常用的格式转换和压缩

把手机拍的一段 MOV 转成更小、更通用的 MP4，命令是这样的：

ffmpeg -i input.mov -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k output.mp4

这里的-crf 23是画质控制参数，数值越小画质越高，一般 18 到 28 之间是常用区间。23 是默认值，在不追求极致画质时能获得不错的压缩比。-preset medium控制编码速度和体积的平衡：用ultrafast会快很多，但体积会变大；用slow则更慢更小。日常处理，我推荐medium。

-c:a aac -b:a 128k是音频部分，转成 AAC 编码，码率 128k，在普通视频里完全够用。

如果想无损抽取视频流和音频流，不做任何重编码，那就用流拷贝：

ffmpeg -i input.mkv -c copy output.mp4

-c copy的意思是直接复制音视频流，速度快到起飞，缺点是封装格式如果不支持原流编码就会失败。这个版本对 MP4/MKV 之间的兼容性已经处理得很好了。

3.2 M4S 转 MP4、录屏与裁剪片尾

很多视频客户端会缓存 M4S 格式的分片，想转成 MP4 时，网上最常见的问题是这两个文件一个是纯视频流，一个是纯音频流。我实测可用的命令：

ffmpeg -i video.m4s -i audio.m4s -c copy output.mp4

注意，这里要把video.m4s放前面，audio.m4s放后面，FFmpeg 会默认用第一个输入文件的视频流和第二个输入文件的音频流。如果反了也没关系，可以在命令里加-map 0:v:0 -map 1:a:0指定。

Windows 下录屏也经常用到这个版本。最省事的命令：

ffmpeg -f gdigrab -i desktop -c:v libx264 -preset ultrafast -crf 28 output.mkv

gdigrab是 Windows 下的桌面抓取输入设备，-i desktop抓全屏，-preset ultrafast是为了降低延迟和 CPU 占用。如果想录某个窗口，把desktop换成窗口标题，比如-i "窗口标题"。

精准裁掉片尾是另一个高频需求。比如视频总时长 10 分钟，你想把第 9 分钟之后的内容去掉，只保留前面 9 分钟：

ffmpeg -i input.mp4 -t 540 -c copy cut.mp4

-t 540表示保留前 540 秒（9 分钟）。-c copy在这里很重要，因为裁剪头部尾部的流拷贝几乎无损，速度快。如果要从第 3 分钟开始裁到第 6 分钟，可以这样：

ffmpeg -ss 180 -to 360 -i input.mp4 -c copy cut.mp4

但这里要提醒：在-i前面放-ss是快速定位时间点，在-i后面放-ss是精确逐帧定位，两者在某些版本里帧精确度不一样。4.3 版本我建议用-ss放-i前面，速度快的代价是起始帧可能不是关键帧开头，但日常够用。

3.3 修复破损 AVI 和提取音频

碰到 AVI 文件播放到一半就卡住，或者有“文件损坏”的报错，不一定要放弃。先用-err_detect ignore_err让 FFmpeg 忽略错误继续读取：

ffmpeg -err_detect ignore_err -i broken.avi -c:v libx264 -c:a aac fixed.mp4

大部分情况下，破损的只是 AVI 容器里的某些索引块，重编码成 MP4 就能正常播放。如果转出来还是有问题，再用-fflags +genpts重新生成时间戳。

提取音频是我用得最多的功能。比如把视频里的音轨转成 MP3：

ffmpeg -i input.mp4 -vn -c:a libmp3lame -q:a 2 audio.mp3

-vn表示丢弃视频流，-q:a 2是 MP3 质量等级，数值越小音质越好，2 就是很不错的品质。这个命令同样适用于从 M4S 里提取音频，只要把输入文件改成audio.m4s就行。

4. 常见报错与排查技巧实录

用这个版本两年多，我前前后后遇到过不少问题，挑几个典型场景，直接给你排查思路和解决方案。

4.1 提示缺少 DLL 或“应用程序无法正常启动”

这种情况多数是运行环境缺了 FFmpeg 依赖的运行时库。我在 32 位 Win7 上见过最典型的报错是缺少libwinpthread-1.dll或libgcc_s_dw2-1.dll。这两个文件其实就在 bin 目录里，出现这种报错的原因通常是：你从其他目录执行 ffmpeg.exe，而那个目录没有这些 DLL，系统 PATH 又没设置 bin 目录。

解决办法很简单：把 bin 目录加进 PATH，或者把所有 DLL 和 ffmpeg.exe 放到同一个目录。不建议从网上单独下载这些 DLL 然后塞进 System32，一是容易下到恶意文件，二是不同编译器的运行时可能不兼容。

4.2 error while loading shared libraries 之类的链接问题

很多刚接触 FFmpeg 开发的人会在 Linux 上遇到类似error while loading shared libraries: libavcodec.so.58: cannot open shared object file的报错，Windows 上的表现则是对应 DLL 找不到或版本不匹配。这个包是 win32 shared 版，本身就依赖一堆 DLL，如果你在开发环境里手动指定了另一个版本的 FFmpeg，就很容易出现“无法定位程序输入点”的崩溃。

我的建议是：只保留一套 FFmpeg 的 bin 目录，在工程配置里明确写死 include 和 lib 路径，不要用默认的 PATH 搜索顺序。如果同时装了多个版本，程序运行时可以通过全路径加载 DLL，或者直接用静态版避免麻烦。

4.3 编码器不可用：Unknown encoder 'libx264'

遇到这个报错，十有八九是用错了版本。如果你下载的是 LGPL 版或者某些精简版，它们是故意不集成 libx264 的，因为 x264 是 GPL 许可。这时候就要用标题里这种带gpl标识的版本。注意，即使你用的是 GPL 版，如果命令里写的是-c:v libx264，但没写-c:a aac，某些场景下也会因为默认音频编码器缺失而失败，所以最好把音频编码器也显式指定。

补充一点：如果同一台机器上装了 FFmpeg static 版和这个 shared 版，PATH 里靠前的那个会被优先调用，容易造成你说的“我明明下的是 GPL 版，结果编码器还是提示没有”的错觉。用ffmpeg -version时注意看编译配置里是否包含--enable-gpl和--enable-libx264。

4.4 在 CLion、Visual Studio 或 Qt 里调用 FFmpeg 的易错点

用 CLion 导入 FFmpeg 的人不少，我也在那边踩过几次坑。核心有两个：一是把头文件和库文件路径加对；二是在 CMakeLists 里不要漏掉link_directories和target_link_libraries。比如：

include_directories(C:/ffmpeg-4.3-win32-gpl-shared/include) link_directories(C:/ffmpeg-4.3-win32-gpl-shared/lib) target_link_libraries(myApp avcodec avformat avutil)

编译链接都过了，运行时却报找不到 DLL，那就把 bin 目录下的 DLL 复制到 exe 旁边，或者把 bin 目录加入 PATH。很多 64 位开发环境顺手把项目平台切到了 x64，但链接的却是 32 位库，也会出现奇奇怪怪的错误。解决方法是把项目平台改成 Win32。

5. 关于“老版本”和“新版本”，我的几点实际体会

有人可能会问：都 2025 年了，还在用 4.3 是不是太落伍了？我理解这种想法，但实际工作中，老版本往往不是“过时”，而是“稳定”。

我手头有好几台客户的工控机还停在 Windows 7 32 位系统，那些机器配置不高，跑不了太新的程序。FFmpeg 5.x、6.x 虽然功能更强，但是对系统路径、DLL 依赖的要求也在变，不是每个环境都能无障碍升级。对我来说，ffmpeg-4.3-win32-gpl-shared就是一个“兜底”版本：用它转码、提取音轨、修损坏文件，从来没有让我失望过。

另外，老版本也有好处：网上一些较老的项目代码和编译脚本，比如基于 4.3 封装的ffmpeg-muxer、SDK示例，升级到新版本后经常因为 API 变更而编译失败。如果你只想快速跑通业务，而不是深入维护 FFmpeg 源码，那不如锁定一个稳定版本，把精力花在业务逻辑上。

最后再分享一个小技巧：如果你也把这个包长期留着，建议下载后先计算一下文件哈希值，记录下来放在一个README.txt里。这样以后从老备份里翻出来时，能确认文件没有被损坏，也能避免下到被二次打包过的假版本。我就因为没留哈希，有一次装到一半发现 ffmpeg.exe 被某“卫士”软件查杀，折腾了半天才意识到是下载源的问题。对于这种实践性强、又到处能用的工具包，留一份校验信息比什么都靠谱。

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