简介在Visual Studio 2005环境下构建FFmpeg常会遇到工程配置复杂、依赖库难以理顺的问题。这份工程资源以FFmpeg 0.6版本为基础面向需要将FFmpeg移植到Windows老版本IDE的开发者覆盖libavcodec、libavformat、libavfilter、libavutil等核心模块的集成要点适合正在维护旧项目、学习传统多媒体框架或研究音视频编解码底层的读者。压缩包为rar格式整体约30.52MB文件明细暂未在页面标注内容围绕VS2005工程的目录组织、编译选项、链接依赖和外部库配置展开重点涉及源代码获取、工程创建、包含路径与库路径设置、静态库引入以及第三方依赖处理等环节便于按步骤对照搭建。目前已有176人学习下载。借助该工程读者可以理清在Windows下使用VS2005编译FFmpeg的完整路径同时掌握Intel C Compiler与VS2005配合时的兼容性检查、优化级别选择、调试信息生成等操作要点减少自行摸索的时间成本还能从工程结构中学到老版本FFmpeg与VS2005协作时的常见坑点与应对思路。需注意该版本较旧实际项目开发中建议结合FFmpeg新版本特性与社区最新资料使用。1. 为什么现在还要在VS2005里折腾FFmpeg先说个扎心的事实Visual Studio 2005是2005年底发布的产品FFmpeg的官方构建版本早就不提供VS2005能直接用的二进制包了。如果你是被迫打开这个老工程大概率是下面三种情况之一要么是产线上某台工控机还跑着Win XP Embedded要么是某个老旧桌面软件积累了大量业务代码没法脱离VS2005升级要么是甲方运维合同里明确写了系统稳定运行N年不动基础环境。我当初接手的就是第二种一个基于MFC的本地视频处理工具客户要求新增视频转码能力公司又死活不肯升级IDE于是只能在VS2005的工程里强行集成FFmpeg。这个组合确实是老古董配新需求的典型场景。FFmpeg本身是纯C库理论上只要编译成对应架构的静态库或导入库任何能编C的编译器都能链接。但VS2005的C编译器是VC8.0它和后来VS2015的C运行时CRT在符号处理、结构体对齐、内联函数模型上有不少差异直接拿新版MinGW编出来的FFmpeg库去链接会撞上一堆莫名其妙的LNK错误。所以这篇文章的核心就是梳理清楚在VS2005工程里接FFmpeg从库的获取、工程属性配置、代码适配到运行时部署每一步最稳的走法是什么。适合看这篇内容的读者有两类。一类是像我这样被迫维护老工程的倒霉蛋需要在VS2005里加视频能力另一类是好奇老工具链怎么与现代开源库共存的技术人员。我会尽量把每个为什么这么做都讲透因为老工程踩坑的根源基本都是环境差异而不是代码逻辑问题。2. 物料准备搞到一份能和VC8.0和睦相处的FFmpeg库2.1 首选方案自己用MinGW编译静态库在VS2005下使用FFmpeg业界公认最省心的方式是获取MinGW编译出的静态库版本。为什么是MinGW而不是VS官方编译版因为FFmpeg官方此前很长时间只提供MinGW和MSYS环境下的编译脚本而社区维护的VS兼容版往往是基于某个特定版本打了补丁的。MinGW本质上是Windows上的GCC工具链它编出来的静态库.a虽然不能直接被VS链接但可以借助lib.exe转换成VS能识别的.lib格式或者直接让VS链接器吃.a文件。具体步骤是以MSYS2环境为例比较成熟安装MSYS2进入MSYS2 Shell安装编译依赖pacman -S mingw-w64-x86_64-toolchain mingw-w64-x86_64-yasm下载FFmpeg源码建议选4.4.x以前的版本新版代码里C99特性用得多GCC编译没事但对老VC的兼容性更差执行configure重点参数如下./configure --enable-static --disable-shared --disable-everything \ --enable-decoderh264 --enable-decoderhevc --enable-decoderaac \ --enable-encodermpeg4 --enable-encoderaac \ --enable-demuxermov --enable-demuxerflv --enable-muxermp4 \ --enable-protocolfile \ --disable-programs --disable-doc --disable-avdevice \ --archx86 --target-osmingw32 --enable-cross-compile--disable-everything然后按需开功能能极大缩短编译时间也能让最终的库小很多。如果工程还需要支持rtsp拉流记得加--enable-demuxerrtsp --enable-protocoltcp --enable-network。编译完成后在libavcodec、libavformat、libavutil等目录下会生成.a文件。注意此时不要直接拿到VS里去用先用MSYS里的gcc编一个MinGW下的测试程序确认库本身工作正常。这样后续VS链接出问题时能缩小排查范围。2.2 备选方案直接下载老版本的预编译二进制如果你不想趟编译这趟浑水也可以从网上找老版本FFmpeg比如3.x时代的dev包里面通常会带lib、include和bin三件套。但强烈建议确认这个dev包是哪个编译器产的如果它的导入库是给MinGW或MSVC2015用的在VS2005里依旧会翻车。我实测过一种勉强能用的办法下载FFmpeg 3.4 win32 static版本它自带lib目录下的一堆.a文件VS2005链接器其实可以直接认.a只是需要在附加依赖项里手动写全路径。不过3.4版本的接口比较老比如av_register_all()还得手动调用新版4.x里已经删掉了。如果你只是做简单的格式转换3.4足够但如果要处理H.265、HDR这类新特性就得回到方案2.1自己编新版。2.3 头文件与库文件的目录规划拿到库之后建议在工程目录下建成这样vendor/ ffmpeg/ include/ libavcodec/ libavformat/ libavutil/ libswscale/ lib/ libavcodec.a libavformat.a libavutil.a libswscale.a把第三方依赖收敛到项目自己的目录里好处是换机器时整个工程拷走就能编不用在每台开发机上配一堆全局环境变量。这一点对老项目尤其重要——VS2005本来就难伺候全局依赖越多越容易出幺蛾子。3. VS2005工程的配置清单改完这几处就能通过编译3.1 设置包含目录和库目录右键项目属性进入配置属性 - C/C - 常规 - 附加包含目录填入$(ProjectDir)vendor\ffmpeg\include然后在链接器 - 常规 - 附加库目录填入$(ProjectDir)vendor\ffmpeg\lib这两步是基础中的基础。需要注意VS2005对中文路径的支持很糟糕如果工程路径里有中文头文件解析经常报一些莫名其妙的C1083错误。把整个工程放到纯英文路径下可以省掉一半的排查时间。3.2 运行库模式必须统一/MT还是/MD要想清楚VS2005的C/C - 代码生成 - 运行库有四个选项多线程(/MT)、多线程调试(/MTd)、多线程DLL(/MD)、多线程调试DLL(/MDd)。FFmpeg的MinGW静态库默认是按静态CRT编的即类似/MT如果你在VS工程里选了/MD链接时会出现大量unresolved external symbol __imp__xxxx或者_beginthreadex相关的错误。我的建议是Debug和Release统一用/MT和/MTd。因为这个工程最终要分发给没有装VC运行库的Windows XP机器静态链接CRT能少一个运行时依赖。代价是生成的可执行文件体积会大一点但对老机器来说这点体积换稳定性是划算的。3.3 链接器附加依赖项与忽略特定库在链接器 - 输入 - 附加依赖项里填libavformat.a libavcodec.a libavutil.a libswscale.a如果MinGW编出来的库还依赖了libmingw32.a、libgcc.a这类GCC运行时库记得也把它们的路径加到附加库目录并逐一添加依赖。我遇到过一种情况链接时报unresolved external symbol ___mingw_va_copy这是因为库在编译时用了GCC的变长参数实现但VC这边没有对应符号。解法是下载一个MinGW的libmingwex.a放到vendor目录后一并链接。另外VS2005默认会链接libcmt.lib(或libcmtd.lib)如果版本符号冲突可以试试在忽略特定默认库里填libcmt.lib强制使用MinGW的CRT。不过这个操作风险较大非必要不推荐。3.4 预处理器的坑_WIN32_WINNT 和 WIN32_LEAN_AND_MEANFFmpeg的头文件某些分支会检查_WIN32_WINNT来确认Windows API版本。VS2005的默认SDK版本较老直接包含avformat.h时可能因为_WIN32_WINNT没有定义或值太小导致inet_pton、getaddrinfo这类函数声明缺失。在预处理器定义里加上WIN32;_WINDOWS;_WIN32_WINNT0x0501;WIN32_LEAN_AND_MEAN0x0501对应Windows XPVS2005在XP上跑天经地义。若你要在Win7以上的系统部署改成0x0601也行但老IDE配新SDK兼容性反而不好保持XP级别兼容最稳妥。3.5 符号冲突与重定义错误MSVC和GCC在结构体打包方式上有一个经典差异默认对齐字节数不同。如果遇到warning C4099或是error C2371这类重定义错误检查一下FFmpeg头文件里有没有#pragma pack指令。老版本FFmpeg的avcodec.h里对某些结构体用过#pragma pack(push, 4)这本来是为了跨平台但在VS2005下可能和工程里其他头文件的全局pack设置冲突。我在实际项目里碰到过AVCodecContext字段偏移量对不上的问题处理方式是确保在包含FFmpeg头文件之前不要设置自定义的#pragma pack。4. 代码适配老IDE编译器的三个隐藏门槛4.1 inttypes.h缺失需要手动补兼容层FFmpeg的头文件大量使用inttypes.h而VS2005的CRT虽然提供了stdint.h但缺inttypes.h且stdint.h里的类型定义也不是完全符合C99。编译时avformat.h里一堆PRId64宏解析失败就是这个问题。最省事的方案是在vendor/ffmpeg/include目录下新建一个inttypes.h内容类似#ifndef _INTTYPES_H_VS2005_ #define _INTTYPES_H_VS2005_ #include stdint.h #define PRId64 I64d #define PRIi64 I64i #define PRIu64 I64u #define PRIx64 I64x // 按需补充其他宏 #endif然后在包含FFmpeg头文件之前确保这个目录在附加包含目录里排在前面就能覆盖掉系统自带的定义。4.2 C编译模式下变量声明必须放在块开头VS2005的C编译器默认对C89支持比较完整而C99的部分特性只支持了一点点。FFmpeg的示例代码大多是按C99或C11写的比如在for循环里声明变量for (int i 0; i nb_streams; i) { ... }这段代码在GCC下没问题在VS2005的.c文件里会直接报C2143语法错误。解决办法有两个把源文件扩展名改成.cpp让MSVC用C编译器来编译——C模式对声明位置的限制宽松很多或者老老实实把变量声明提到函数开头int i; for (i 0; i nb_streams; i) { ... }我建议优先改后缀为.cpp。FFmpeg的纯C接口在C编译器下基本是兼容的除了个别从void*到AVFormatContext*的隐式转换需要加强制转换其他问题不大。4.3 snprintf系列函数的行为差异VS2005的snprintf不是标准C99的snprintf它的函数名实际上是_snprintf而且行为有坑当目标缓冲区不够大时不会保证字符串以\0结尾返回值也不是需要的长度而是负值。FFmpeg内部函数自己实现了snprintf的兼容层libavutil里有av_strlcpy之类的工具但如果你在自己的代码里直接调用snprintf拼参数写文件路径、构造URL时出问题很常见。稳妥做法是包装一层int safe_sprintf(char* buf, size_t size, const char* fmt, ...) { va_list args; va_start(args, fmt); int len _vsnprintf(buf, size, fmt, args); va_end(args); if (len 0 || (size_t)len size) { buf[size - 1] \0; return -1; } return len; }别纠结这种代码不够优雅在老工具链里活着比优雅重要。4.4 已废弃API的兼容写法FFmpeg 3.x时代的API里av_register_all()和avcodec_register_all()还需要手动调用。到了4.x版本这两个函数已经被内部注册机制替代声明还在但调用与否都不影响。为了兼容性和避免出现deprecated警告刷屏建议用版本宏做条件编译#if LIBAVFORMAT_VERSION_INT AV_VERSION_INT(58, 0, 100) av_register_all(); #endif类似地AVStream::codec字段在4.x里被移除了只能通过avcodec_parameters_to_context()来获取解码器上下文。如果你的FFmpeg版本是3.x用旧写法没问题但代码尽量接受新写法这样以后升级库时不至于重写。5. 实际链接中的报错案例五条最常见的LNK坑人经验5.1 LNK2005: _sprintf 已经在 libc.lib 中定义这个报错出现在MinGW静态库和VC运行库同时提供相同CRT函数的时候。根本原因是GCC编译FFmpeg时把一些CRT函数内联进了目标文件而VC链接器又试图从libc.lib中再解析一次。处理方案在链接器 - 输入 - 忽略特定默认库里填libc.lib让VC不再尝试从它的CRT里拉取重复符号。注意如果你用了/MT模式有时还要一并忽略libcmt.lib具体看报错信息提示。5.2 LNK2019: unresolved external symbol _main 或 _WinMain16这是典型的入口点不对问题说明你当前工程类型是控制台程序但FFmpeg库或某些静态库引用里带了main入口。如果VS2005工程是Win32项目窗口程序检查项目设置的链接器 - 系统 - 子系统是否设置成了窗口(/SUBSYSTEM:WINDOWS)。如果还是报查看你是不是误把某个MinGW的启动文件比如crt0.o也链接进来了。5.3 LNK1112: 模块计算机类型x86与目标计算机类型x64冲突看起来低级但在VS2005里很容易犯FFmpeg库是32位的但工程编译目标被设成了x64。VS2005的x64编译支持刚起步默认的Win32平台经常被误以为是任意CPU。无论如何一定要在解决方案平台里明确选Win32并且确认FFmpeg库是对应的32位版本。5.4 LNK4099: 未找到 PDB 或 DBG 文件这不是致命错误可以忽略但如果你在调试时想进入FFmpeg内部函数就会发现没有PDB简直寸步难行。MV了事把编译FFmpeg时的--enable-debug3打开或者干脆用Release版库继续开发等需要深入排查时再单独编一版带调试符号的。5.5 LNK2001: unresolved external symbol _avformat_open_input如果报错只是个别FFmpeg函数解析不到而其他函数正常优先检查是不是库文件没有完整链接。libavformat.a里包含所有格式相关函数如果该文件没被加入附加依赖项就会出现这种零散缺失。另外链接顺序在VS里虽然不像GCC那样严格但建议把依赖库放在被依赖库前面。6. 最小可用的转码示例跑通一次完整流程配好工程后先用一个极简例程验证库和链接是否正常。下面的代码读取一个MP4文件取第一路视频流逐帧缩放并保存为原始YUV文件顺便验证解码器和swscale。extern C { #include libavformat/avformat.h #include libavcodec/avcodec.h #include libswscale/swscale.h #include libavutil/imgutils.h } void decode_to_yuv(const char* inFile, const char* outFile) { av_register_all(); AVFormatContext* fmtCtx NULL; if (avformat_open_input(fmtCtx, inFile, NULL, NULL) ! 0) { return; // open failed } if (avformat_find_stream_info(fmtCtx, NULL) 0) { avformat_close_input(fmtCtx); return; } int videoStreamIdx -1; for (unsigned int i 0; i fmtCtx-nb_streams; i) { if (fmtCtx-streams[i]-codecpar-codec_type AVMEDIA_TYPE_VIDEO) { videoStreamIdx i; break; } } if (videoStreamIdx 0) { avformat_close_input(fmtCtx); return; } AVCodecParameters* codecPar fmtCtx-streams[videoStreamIdx]-codecpar; AVCodec* decoder avcodec_find_decoder(codecPar-codec_id); AVCodecContext* decCtx avcodec_alloc_context3(decoder); avcodec_parameters_to_context(decCtx, codecPar); if (avcodec_open2(decCtx, decoder, NULL) 0) { avcodec_free_context(decCtx); avformat_close_input(fmtCtx); return; } SwsContext* swsCtx sws_getContext( decCtx-width, decCtx-height, decCtx-pix_fmt, decCtx-width, decCtx-height, AV_PIX_FMT_YUV420P, SWS_BILINEAR, NULL, NULL, NULL); FILE* out fopen(outFile, wb); AVPacket pkt; av_init_packet(pkt); pkt.data NULL; pkt.size 0; AVFrame* frame av_frame_alloc(); AVFrame* yuvFrame av_frame_alloc(); uint8_t* yuvBuf (uint8_t*)av_malloc( av_image_get_buffer_size(AV_PIX_FMT_YUV420P, decCtx-width, decCtx-height, 1)); av_image_fill_arrays(yuvFrame-data, yuvFrame-linesize, yuvBuf, AV_PIX_FMT_YUV420P, decCtx-width, decCtx-height, 1); while (av_read_frame(fmtCtx, pkt) 0) { if (pkt.stream_index videoStreamIdx) { int ret avcodec_send_packet(decCtx, pkt); if (ret 0) { while (avcodec_receive_frame(decCtx, frame) 0) { sws_scale(swsCtx, frame-data, frame-linesize, 0, decCtx-height, yuvFrame-data, yuvFrame-linesize); fwrite(yuvFrame-data[0], 1, decCtx-width * decCtx-height, out); fwrite(yuvFrame-data[1], 1, decCtx-width * decCtx-height / 4, out); fwrite(yuvFrame-data[2], 1, decCtx-width * decCtx-height / 4, out); } } } av_packet_unref(pkt); } fclose(out); av_free(yuvBuf); av_frame_free(yuvFrame); av_frame_free(frame); sws_freeContext(swsCtx); avcodec_free_context(decCtx); avformat_close_input(fmtCtx); }这里有几个VS2005下特别容易踩的点av_register_all()这段在4.x里可以不要但3.x必须有建议留着并加版本宏保护avcodec_send_packet/avcodec_receive_frame这套是新版解码接口3.1以上版本都有。如果你用的是老库比如2.x会没有这两个函数那就得退回老式的avcodec_decode_video2写法for (unsigned int i 0; ...)中的变量在循环内声明C模式下没问题C模式下要提到函数开头。跑完这个例子后如果输出YUV文件和ffplay播放结果一致说明库和工程配置基本没问题。接下来再把缩放、编码、封装这些模块逐步加进来每加一块就编译一次别一口气写完再调试老工具链的报错信息不友好增量开发能少受不少罪。7. 部署时的运行环境老系统上DLL怎么放如果你的库是按2.1方案编的静态库那部署时只需要交付一个exe省心。但按2.2方案用的动态库DLL就得认真处理运行时依赖。老Windows系统上最常见的FFmpeg相关问题是avcodec-58.dll这类DLL缺失或者DLL内依赖的C运行时版本比目标系统高。解决办法是在exe同目录建一个bin子目录把DLL都放进去然后程序启动时用SetDllDirectory或SetCurrentDirectory指定DLL搜索路径。不要指望把它们丢进System32一方面权限和污染问题另一方面在Win XP Embedded这种精简系统上路径就不好使。另一种做法是直接用静态库这也是我最终选择的方向——少一个DLL就少一类坑。另外如果你的VS2005程序用/MD编译部署目标机器需要VC2005运行库msvcp80.dll、msvcr80.dll。XP时代这是标配但精简版Win XP Embedded上还真不一定装。用/MT静态链接CRT后这一层也可以免掉。8. 老工程还能撑多久关于VS2005与FFmpeg的个人体会整套弄完我最大的感悟是VS2005这代工具链和现代开源代码之间的鸿沟不是靠技术技巧能完全填平的更多时候是和解——库版本选老一点代码风格迁就编译器一点部署目标降低一点就能换来稳定的运行环境。如果你还有一点点升级空间我的建议是先把VS2005工程迁移到VS2015或VS2017代码结构不需要大改FFmpeg直接用预编译的新版dev包整个复杂度会下降一大截。但确实有些项目因为各种原因动不了那么上面这套配置方案至少能让你在这个老破小工程里把FFmpeg跑起来。最后分享一个我踩过的大坑排查了整整两天的链接错误最后发现是因为工程目录下有个旧版的avcodec.h被IDE自动包含优先级盖过了vendor目录里的新头文件。这种问题在VS2005的标准包含路径和项目附加包含路径打架时很容易出现。如果遇到诡异的警告或链接错误先打开C/C的命令行选项卡看看实际的/I包含顺序这比盲目改依赖项效率高得多。本文还有配套的精品资源点击获取