简介本资源面向需要在 Windows 10 与 VS2017 环境下使用 RTMP 协议的 C/C 开发者提供可直接编译的 librtmp.lib 静态库工程解决自行编译时依赖库难找、配置繁琐的问题。压缩包共 238 个文件约 49.12MB以 163 个 h 头文件、28 个 dll 动态库、8 个 lib 库文件及 7 个 c 源文件为主另含 sln 解决方案、vcxproj 工程与编译日志等目录按 lib、librtmp、openssl-1.0.1c、zlib-1.2.8、vs2017 分层组织依赖关系一目了然。已有 637 人学习下载。读者可直接打开 librtmp.sln 编译出 librtmp.lib省去 OpenSSL 与 zlib 的交叉编译环节同时获得完整源码与引用库便于二次开发、调试与集成到推流播放项目中是 RTMP 客户端开发与流媒体学习的实用参考。1. 为什么 2024 年还在折腾 librtmp.libVS2017 编译这件事的真实门槛如果你手头有一个老项目需要在 Windows 上做 RTMP 推流或者维护一套安防、直播、录播类的 C 客户端那你大概率绕不开 librtmp。它不是什么新东西但胜在轻、稳、依赖少很多工业现场的设备端程序至今还在用它。问题在于网上能搜到的 librtmp 编译教程十篇里有八篇是 MinGW 或者 Linux 下的剩下两篇 VS 的还停留在 VS2010 时代照着做不是缺头文件就是链接报错。这个标题真正要解决的事情很具体在 Visual Studio 2017 环境下把 librtmp 编译成.lib静态库同时把 zlib 和 OpenSSL 这两个引用库一起配好最后能直接在自己的工程里#include加链接就能用。它适合两类人一类是接手了老代码、必须用 VS2017 工具链的维护型工程师另一类是想在 Windows 上做 RTMP 推流、又不想引入 FFmpeg 这种大块头的开发者。我自己的血泪经验是librtmp 的编译难点从来不在 librtmp 本身而在它的两个依赖zlib 和 OpenSSL。VS2017 的 MSVC 工具链对 C99 的支持、对ssize_t这类 POSIX 类型的处理都会让直接拿 Linux 源码来编的人翻车。所以这篇东西的重点是把「引用库 源代码 编译配置」这条链路讲透而不是只丢一个.sln给你。2. 编译前必须搞清楚的依赖关系与目录规划2.1 librtmp 到底依赖了什么为什么不能只编它一个librtmp 的源码结构其实很清晰核心就是rtmp.c、log.c、parseurl.c、hashswf.c这几个文件。但它默认会用到两个外部能力一个是压缩一个是加密。压缩对应 zlib用来处理 RTMP 握手阶段的 HMAC 和部分数据压缩加密对应 OpenSSL用来做 RTMPE 的握手和 DH 密钥交换。如果你只做普通 RTMP 推流理论上可以关掉这两个依赖但实际项目里几乎没人这么干因为一旦服务端要求 RTMPE 或者你后续要加鉴权没有 OpenSSL 就得推倒重来。所以我的建议是一步到位把 zlib 和 OpenSSL 都编成静态库再让 librtmp 去链接它们。这里有个选型上的坑OpenSSL 版本不要选太新的。VS2017 的 MSVC 版本是 19.1xOpenSSL 1.1.1 系列是最后一个对老工具链友好的长期支持版本3.x 系列在 VS2017 下编译 Perl 配置脚本容易出问题。我一般会锁定 OpenSSL 1.1.1w 这个版本zlib 用 1.2.13这两个组合在 VS2017 下验证过很多次稳定。2.2 目录结构怎么摆决定了你后面少踩多少坑很多人编译失败不是代码问题是目录太乱导致 include 路径和 lib 路径对不上。我习惯在磁盘上建一个干净的根目录比如D:\rtmp_build下面按依赖层级分开放D:\rtmp_build\ ├── zlib-1.2.13\ # zlib 源码 │ ├── build_vs2017\ # zlib 的 VS 工程输出 ├── openssl-1.1.1w\ # OpenSSL 源码 │ ├── build_vs2017\ # OpenSSL 编译输出 ├── librtmp\ # librtmp 源码 │ ├── src\ # rtmp.c 等源文件 │ ├── include\ # rtmp.h 等头文件 │ └── build_vs2017\ # librtmp 的 VS 工程 └── output\ # 最终统一存放 .lib 和 .h ├── include\ └── lib\这样摆的好处是后面在 VS2017 里配附加包含目录和附加库目录时路径是固定的不会因为某个库换了位置就全盘重来。output目录是最终交付物别人拿到这个目录就能直接集成不用再关心你中间怎么编的。提示路径里不要带中文和空格VS2017 的 MSBuild 在某些情况下对空格路径处理有问题尤其是自定义生成步骤里调用 Perl 或 NASM 的时候。3. 用 VS2017 编译 zlib 和 OpenSSL 引用库的完整命令3.1 zlib 1.2.13 在 VS2017 下的编译步骤zlib 官方源码包里自带了一个win32目录里面有Makefile.msc但那个是给 nmake 用的在 VS2017 下直接跑容易因为 SDK 版本问题报错。更稳的做法是用 CMake 生成 VS2017 工程然后命令行编译。先确认你装了 CMake并且cmake --version能看到 3.10 以上。然后在D:\rtmp_build\zlib-1.2.13下打开 VS2017 的 x64 本机工具命令提示符执行mkdir build_vs2017 cd build_vs2017 cmake -G Visual Studio 15 2017 Win64 -DCMAKE_INSTALL_PREFIXD:/rtmp_build/output .. cmake --build . --config Release --target INSTALL这三条命令的逻辑是第一条用 VS2017 的 64 位生成器创建工程同时指定安装前缀到output目录第二条执行 Release 编译并把头文件和zlib.lib安装到output。编译完成后你会在D:\rtmp_build\output\include下看到zlib.h和zconf.h在D:\rtmp_build\output\lib下看到zlib.lib。参数上唯一需要留意的是CMAKE_INSTALL_PREFIX它决定了后面 librtmp 去哪里找 zlib。如果你只想编 32 位把Win64去掉生成器换成Visual Studio 15 2017就行但要注意后面所有库的位数必须一致混用 32 位和 64 位是链接报错的重灾区。3.2 OpenSSL 1.1.1w 的 Perl 配置与 nmake 编译OpenSSL 在 Windows 下的编译依赖 Perl 和 NASM。Perl 我推荐用 Strawberry Perl装完之后perl -v能输出版本号NASM 装完后要把它的目录加到系统 PATH否则 OpenSSL 的汇编优化模块编不过。进入D:\rtmp_build\openssl-1.1.1w用 VS2017 x64 本机工具命令提示符执行perl Configure VC-WIN64A no-shared no-tests --prefixD:\rtmp_build\output --openssldirD:\rtmp_build\output\ssl nmake nmake installVC-WIN64A是告诉 OpenSSL 用 VS 的 64 位汇编器no-shared是关键它让 OpenSSL 只生成静态库libssl.lib和libcrypto.lib不生成 DLL这样后面 librtmp 链接进去就是纯静态的部署时不用带一堆 dllno-tests是跳过测试程序编译能省不少时间。--prefix和--openssldir都指向output这样nmake install之后头文件会进output\include库文件会进output\lib。如果你在这一步遇到nasm not found检查 PATH如果遇到cl.exe not found说明你没在 VS2017 的命令行环境里执行重新从开始菜单打开「x64 本机工具命令提示符」。3.3 验证引用库是否可用一个最小链接测试在正式编 librtmp 之前我习惯先写一个几行的测试程序确认 zlib 和 OpenSSL 的静态库能被 VS2017 正常链接。新建一个空的控制台工程把output\include加到附加包含目录output\lib加到附加库目录然后在附加依赖项里填zlib.lib;libssl.lib;libcrypto.lib;ws2_32.lib;crypt32.lib;。#include zlib.h #include openssl/ssl.h #include iostream int main() { std::cout zlib version: zlibVersion() std::endl; std::cout openssl version: OpenSSL_version(OPENSSL_VERSION) std::endl; return 0; }这段代码能编过并且运行输出两个版本号说明引用库的路径、位数、运行时库配置都对上了。如果报LNK2019未解析的外部符号九成是位数不匹配或者附加依赖项漏了ws2_32.lib。这一步看起来多余但它能帮你把引用库的问题和 librtmp 的问题隔离开后面排错会轻松很多。4. 把 librtmp 源码编成 librtmp.lib 的工程配置4.1 源码文件清单与 VS2017 工程创建librtmp 的源码通常散落在src和include两个目录里。你需要加入编译的文件其实不多核心是这几个文件作用是否必须rtmp.cRTMP 协议主实现必须log.c日志输出必须parseurl.cURL 解析必须hashswf.cSWF 校验哈希推流到某些服务端时必须handshake.c握手扩展视服务端要求在 VS2017 里新建一个「静态库」工程把上述.c文件添加进去头文件目录指向 librtmp 的include。然后右键工程属性把配置类型确认为「静态库 (.lib)」目标文件名改成librtmp。这里有个细节librtmp 的源码里会#include zlib.h和#include openssl/ssl.h所以附加包含目录里必须同时有output\include和 librtmp 自己的include。顺序上把output\include放在前面避免源码目录里有同名头文件造成冲突。4.2 预处理宏与运行时库的关键设置librtmp 在 Windows 下编译必须定义几个宏否则会报一堆类型未定义或者函数找不到。在「C/C → 预处理器 → 预处理器定义」里加上_CRT_SECURE_NO_WARNINGS WIN32 _WINDOWS NO_CRYPTO等一下NO_CRYPTO这个宏要特别说明。如果你确定不需要 RTMPE 加密加上它可以少链接 OpenSSL编译会简单很多。但如果你后面要用 RTMPE这个宏绝对不能加否则rtmp.c里跟加密相关的代码会被条件编译掉运行时握手直接失败。我一般是不加NO_CRYPTO老老实实把 OpenSSL 链进去避免以后返工。运行时库的设置也容易翻车。VS2017 默认新建静态库工程用的是「多线程 DLL (/MD)」但如果你希望最终交付一个不依赖 VC 运行时的独立库应该改成「多线程 (/MT)」。注意这个设置必须和 zlib、OpenSSL 的运行时库设置一致。前面用 CMake 编 zlib 时默认也是/MD如果你要改/MTzlib 和 OpenSSL 都得重新编一遍否则链接时会报RuntimeLibrary不匹配的 LNK2038 错误。4.3 链接引用库并生成 librtmp.lib在静态库工程的「链接器 → 输入 → 附加依赖项」里填入zlib.lib libssl.lib libcrypto.lib ws2_32.lib crypt32.lib同时在「链接器 → 常规 → 附加库目录」里加上D:\rtmp_build\output\lib。然后直接生成解决方案如果前面 zlib 和 OpenSSL 都编对了这一步应该能顺利产出librtmp.lib。生成之后我建议做一个「安装」动作把librtmp.lib复制到output\lib把rtmp.h、log.h等头文件复制到output\include。这样output目录就是一个完整的 SDK别人拿到之后只需要配一个包含目录和一个库目录就能用。注意如果你在链接阶段看到unresolved external symbol __imp_SSL_CTX_new这类带__imp_前缀的符号说明你链接的是 OpenSSL 的导入库而不是静态库。检查output\lib下是不是混进了libssl.lib的 DLL 版本或者no-shared没生效。5. 编译 librtmp 时最容易翻车的几个地方5.1 现象报ssize_t未定义一堆红字原因ssize_t是 POSIX 类型MSVC 默认不提供。librtmp 源码里有些地方直接用了它在 Linux 下没问题在 VS 下就炸。解决在rtmp.h或者工程的预处理器里加一个类型定义。最稳妥的做法是在包含 librtmp 头文件之前自己补一个#ifdef _MSC_VER #include basetsd.h typedef SSIZE_T ssize_t; #endif或者直接在 VS 工程里加预处理器宏_SSIZE_T_DEFINED然后确保basetsd.h被包含。我一般选前者因为改工程宏有时候会被其他头文件的包含顺序干扰。5.2 现象链接时报LNK2038说 RuntimeLibrary 不匹配原因zlib、OpenSSL、librtmp 三个工程的运行时库设置不一致。有的是/MD有的是/MT链接器检测到冲突就拒绝生成。解决统一改成/MT或者统一/MD。如果你要交付独立库选/MT如果你只是自己项目内部用/MD也行但部署时要带 VC 运行时。改的时候三个库都要重新编译不能只改一个。5.3 现象编译通过但运行时RTMP_Connect返回失败日志显示握手错误原因大概率是 OpenSSL 的加密部分没链进去或者NO_CRYPTO宏被误加了。也有可能是 OpenSSL 版本和 librtmp 源码不兼容比如用了 OpenSSL 3.x 的 API而 librtmp 里还是 1.1.1 的调用方式。解决先确认NO_CRYPTO没定义再确认链接的是libssl.lib和libcrypto.lib而不是 DLL 导入库。如果还不行抓包看握手阶段服务端返回的具体错误码RTMPE 握手失败通常是 DH 参数不匹配换 OpenSSL 1.1.1w 基本能解决。5.4 现象32 位工程链接 64 位库报LNK1112模块计算机类型冲突原因zlib 或 OpenSSL 编的是 64 位但 librtmp 工程建的是 32 位或者反过来。解决统一位数。检查方法是在 VS 里看工程属性「平台」是 Win32 还是 x64然后确认output\lib下的.lib是用哪个位数编的。可以用dumpbin /headers zlib.lib | findstr machine来看x64 会显示machine (x64)x86 显示machine (x86)。5.5 现象nmake install之后output\include里没有openssl目录原因OpenSSL 的--openssldir和--prefix设置不对或者nmake install中途报错但被忽略了。解决重新执行nmake install并且把输出完整看一遍。正常情况下output\include\openssl下应该有几十个头文件。如果没有检查--prefix路径是否可写以及 Perl 配置阶段有没有报 warning。6. 交付一个可直接集成的 librtmp SDK目录规范与验证技巧编完不是终点能让人直接拿去用才是。我习惯在output目录里再补一个librtmp_sdk文件夹结构如下librtmp_sdk\ ├── include\ │ ├── rtmp.h │ ├── log.h │ ├── zlib.h │ ├── zconf.h │ └── openssl\ # 整个 openssl 头文件目录 ├── lib\ │ ├── librtmp.lib │ ├── zlib.lib │ ├── libssl.lib │ └── libcrypto.lib └── README.txt # 写清楚 VS2017 集成时的附加依赖项README.txt里我一般只写三行关键信息附加包含目录填include附加库目录填lib附加依赖项填librtmp.lib;zlib.lib;libssl.lib;libcrypto.lib;ws2_32.lib;crypt32.lib;。这样别人拿到之后五分钟就能在自己的工程里跑起来。验证 SDK 是否完整我有个偷懒但有效的办法新建一个空的 VS2017 控制台工程只加一个main.cpp里面调用RTMP_Init和RTMP_SetupURL然后链接这个 SDK。如果编过并且运行不崩说明头文件和库文件都是齐的。这个测试不需要真的连服务器只是验证编译链接链路。#include rtmp.h #include iostream int main() { RTMP* rtmp RTMP_Alloc(); if (!rtmp) { std::cerr RTMP_Alloc failed std::endl; return -1; } RTMP_Init(rtmp); std::cout librtmp init ok std::endl; RTMP_Free(rtmp); return 0; }这段代码能编过并输出librtmp init ok就说明你的librtmp.lib是真正可用的不是那种编出来但符号不全的半成品。最后说一个我自己的习惯每次编完这套东西我会把output目录整个打包文件名带上日期和 VS 版本比如librtmp_vs2017_x64_202406.zip。下次再遇到需要这个库的项目直接解压配路径不用重新走一遍编译流程。这个习惯帮我省过至少两次通宵排错的时间希望帮到你。本文还有配套的精品资源点击获取
VS2017 编译 librtmp 静态库：zlib 与 OpenSSL 依赖配置实战
简介本资源面向需要在 Windows 10 与 VS2017 环境下使用 RTMP 协议的 C/C 开发者提供可直接编译的 librtmp.lib 静态库工程解决自行编译时依赖库难找、配置繁琐的问题。压缩包共 238 个文件约 49.12MB以 163 个 h 头文件、28 个 dll 动态库、8 个 lib 库文件及 7 个 c 源文件为主另含 sln 解决方案、vcxproj 工程与编译日志等目录按 lib、librtmp、openssl-1.0.1c、zlib-1.2.8、vs2017 分层组织依赖关系一目了然。已有 637 人学习下载。读者可直接打开 librtmp.sln 编译出 librtmp.lib省去 OpenSSL 与 zlib 的交叉编译环节同时获得完整源码与引用库便于二次开发、调试与集成到推流播放项目中是 RTMP 客户端开发与流媒体学习的实用参考。1. 为什么 2024 年还在折腾 librtmp.libVS2017 编译这件事的真实门槛如果你手头有一个老项目需要在 Windows 上做 RTMP 推流或者维护一套安防、直播、录播类的 C 客户端那你大概率绕不开 librtmp。它不是什么新东西但胜在轻、稳、依赖少很多工业现场的设备端程序至今还在用它。问题在于网上能搜到的 librtmp 编译教程十篇里有八篇是 MinGW 或者 Linux 下的剩下两篇 VS 的还停留在 VS2010 时代照着做不是缺头文件就是链接报错。这个标题真正要解决的事情很具体在 Visual Studio 2017 环境下把 librtmp 编译成.lib静态库同时把 zlib 和 OpenSSL 这两个引用库一起配好最后能直接在自己的工程里#include加链接就能用。它适合两类人一类是接手了老代码、必须用 VS2017 工具链的维护型工程师另一类是想在 Windows 上做 RTMP 推流、又不想引入 FFmpeg 这种大块头的开发者。我自己的血泪经验是librtmp 的编译难点从来不在 librtmp 本身而在它的两个依赖zlib 和 OpenSSL。VS2017 的 MSVC 工具链对 C99 的支持、对ssize_t这类 POSIX 类型的处理都会让直接拿 Linux 源码来编的人翻车。所以这篇东西的重点是把「引用库 源代码 编译配置」这条链路讲透而不是只丢一个.sln给你。2. 编译前必须搞清楚的依赖关系与目录规划2.1 librtmp 到底依赖了什么为什么不能只编它一个librtmp 的源码结构其实很清晰核心就是rtmp.c、log.c、parseurl.c、hashswf.c这几个文件。但它默认会用到两个外部能力一个是压缩一个是加密。压缩对应 zlib用来处理 RTMP 握手阶段的 HMAC 和部分数据压缩加密对应 OpenSSL用来做 RTMPE 的握手和 DH 密钥交换。如果你只做普通 RTMP 推流理论上可以关掉这两个依赖但实际项目里几乎没人这么干因为一旦服务端要求 RTMPE 或者你后续要加鉴权没有 OpenSSL 就得推倒重来。所以我的建议是一步到位把 zlib 和 OpenSSL 都编成静态库再让 librtmp 去链接它们。这里有个选型上的坑OpenSSL 版本不要选太新的。VS2017 的 MSVC 版本是 19.1xOpenSSL 1.1.1 系列是最后一个对老工具链友好的长期支持版本3.x 系列在 VS2017 下编译 Perl 配置脚本容易出问题。我一般会锁定 OpenSSL 1.1.1w 这个版本zlib 用 1.2.13这两个组合在 VS2017 下验证过很多次稳定。2.2 目录结构怎么摆决定了你后面少踩多少坑很多人编译失败不是代码问题是目录太乱导致 include 路径和 lib 路径对不上。我习惯在磁盘上建一个干净的根目录比如D:\rtmp_build下面按依赖层级分开放D:\rtmp_build\ ├── zlib-1.2.13\ # zlib 源码 │ ├── build_vs2017\ # zlib 的 VS 工程输出 ├── openssl-1.1.1w\ # OpenSSL 源码 │ ├── build_vs2017\ # OpenSSL 编译输出 ├── librtmp\ # librtmp 源码 │ ├── src\ # rtmp.c 等源文件 │ ├── include\ # rtmp.h 等头文件 │ └── build_vs2017\ # librtmp 的 VS 工程 └── output\ # 最终统一存放 .lib 和 .h ├── include\ └── lib\这样摆的好处是后面在 VS2017 里配附加包含目录和附加库目录时路径是固定的不会因为某个库换了位置就全盘重来。output目录是最终交付物别人拿到这个目录就能直接集成不用再关心你中间怎么编的。提示路径里不要带中文和空格VS2017 的 MSBuild 在某些情况下对空格路径处理有问题尤其是自定义生成步骤里调用 Perl 或 NASM 的时候。3. 用 VS2017 编译 zlib 和 OpenSSL 引用库的完整命令3.1 zlib 1.2.13 在 VS2017 下的编译步骤zlib 官方源码包里自带了一个win32目录里面有Makefile.msc但那个是给 nmake 用的在 VS2017 下直接跑容易因为 SDK 版本问题报错。更稳的做法是用 CMake 生成 VS2017 工程然后命令行编译。先确认你装了 CMake并且cmake --version能看到 3.10 以上。然后在D:\rtmp_build\zlib-1.2.13下打开 VS2017 的 x64 本机工具命令提示符执行mkdir build_vs2017 cd build_vs2017 cmake -G Visual Studio 15 2017 Win64 -DCMAKE_INSTALL_PREFIXD:/rtmp_build/output .. cmake --build . --config Release --target INSTALL这三条命令的逻辑是第一条用 VS2017 的 64 位生成器创建工程同时指定安装前缀到output目录第二条执行 Release 编译并把头文件和zlib.lib安装到output。编译完成后你会在D:\rtmp_build\output\include下看到zlib.h和zconf.h在D:\rtmp_build\output\lib下看到zlib.lib。参数上唯一需要留意的是CMAKE_INSTALL_PREFIX它决定了后面 librtmp 去哪里找 zlib。如果你只想编 32 位把Win64去掉生成器换成Visual Studio 15 2017就行但要注意后面所有库的位数必须一致混用 32 位和 64 位是链接报错的重灾区。3.2 OpenSSL 1.1.1w 的 Perl 配置与 nmake 编译OpenSSL 在 Windows 下的编译依赖 Perl 和 NASM。Perl 我推荐用 Strawberry Perl装完之后perl -v能输出版本号NASM 装完后要把它的目录加到系统 PATH否则 OpenSSL 的汇编优化模块编不过。进入D:\rtmp_build\openssl-1.1.1w用 VS2017 x64 本机工具命令提示符执行perl Configure VC-WIN64A no-shared no-tests --prefixD:\rtmp_build\output --openssldirD:\rtmp_build\output\ssl nmake nmake installVC-WIN64A是告诉 OpenSSL 用 VS 的 64 位汇编器no-shared是关键它让 OpenSSL 只生成静态库libssl.lib和libcrypto.lib不生成 DLL这样后面 librtmp 链接进去就是纯静态的部署时不用带一堆 dllno-tests是跳过测试程序编译能省不少时间。--prefix和--openssldir都指向output这样nmake install之后头文件会进output\include库文件会进output\lib。如果你在这一步遇到nasm not found检查 PATH如果遇到cl.exe not found说明你没在 VS2017 的命令行环境里执行重新从开始菜单打开「x64 本机工具命令提示符」。3.3 验证引用库是否可用一个最小链接测试在正式编 librtmp 之前我习惯先写一个几行的测试程序确认 zlib 和 OpenSSL 的静态库能被 VS2017 正常链接。新建一个空的控制台工程把output\include加到附加包含目录output\lib加到附加库目录然后在附加依赖项里填zlib.lib;libssl.lib;libcrypto.lib;ws2_32.lib;crypt32.lib;。#include zlib.h #include openssl/ssl.h #include iostream int main() { std::cout zlib version: zlibVersion() std::endl; std::cout openssl version: OpenSSL_version(OPENSSL_VERSION) std::endl; return 0; }这段代码能编过并且运行输出两个版本号说明引用库的路径、位数、运行时库配置都对上了。如果报LNK2019未解析的外部符号九成是位数不匹配或者附加依赖项漏了ws2_32.lib。这一步看起来多余但它能帮你把引用库的问题和 librtmp 的问题隔离开后面排错会轻松很多。4. 把 librtmp 源码编成 librtmp.lib 的工程配置4.1 源码文件清单与 VS2017 工程创建librtmp 的源码通常散落在src和include两个目录里。你需要加入编译的文件其实不多核心是这几个文件作用是否必须rtmp.cRTMP 协议主实现必须log.c日志输出必须parseurl.cURL 解析必须hashswf.cSWF 校验哈希推流到某些服务端时必须handshake.c握手扩展视服务端要求在 VS2017 里新建一个「静态库」工程把上述.c文件添加进去头文件目录指向 librtmp 的include。然后右键工程属性把配置类型确认为「静态库 (.lib)」目标文件名改成librtmp。这里有个细节librtmp 的源码里会#include zlib.h和#include openssl/ssl.h所以附加包含目录里必须同时有output\include和 librtmp 自己的include。顺序上把output\include放在前面避免源码目录里有同名头文件造成冲突。4.2 预处理宏与运行时库的关键设置librtmp 在 Windows 下编译必须定义几个宏否则会报一堆类型未定义或者函数找不到。在「C/C → 预处理器 → 预处理器定义」里加上_CRT_SECURE_NO_WARNINGS WIN32 _WINDOWS NO_CRYPTO等一下NO_CRYPTO这个宏要特别说明。如果你确定不需要 RTMPE 加密加上它可以少链接 OpenSSL编译会简单很多。但如果你后面要用 RTMPE这个宏绝对不能加否则rtmp.c里跟加密相关的代码会被条件编译掉运行时握手直接失败。我一般是不加NO_CRYPTO老老实实把 OpenSSL 链进去避免以后返工。运行时库的设置也容易翻车。VS2017 默认新建静态库工程用的是「多线程 DLL (/MD)」但如果你希望最终交付一个不依赖 VC 运行时的独立库应该改成「多线程 (/MT)」。注意这个设置必须和 zlib、OpenSSL 的运行时库设置一致。前面用 CMake 编 zlib 时默认也是/MD如果你要改/MTzlib 和 OpenSSL 都得重新编一遍否则链接时会报RuntimeLibrary不匹配的 LNK2038 错误。4.3 链接引用库并生成 librtmp.lib在静态库工程的「链接器 → 输入 → 附加依赖项」里填入zlib.lib libssl.lib libcrypto.lib ws2_32.lib crypt32.lib同时在「链接器 → 常规 → 附加库目录」里加上D:\rtmp_build\output\lib。然后直接生成解决方案如果前面 zlib 和 OpenSSL 都编对了这一步应该能顺利产出librtmp.lib。生成之后我建议做一个「安装」动作把librtmp.lib复制到output\lib把rtmp.h、log.h等头文件复制到output\include。这样output目录就是一个完整的 SDK别人拿到之后只需要配一个包含目录和一个库目录就能用。注意如果你在链接阶段看到unresolved external symbol __imp_SSL_CTX_new这类带__imp_前缀的符号说明你链接的是 OpenSSL 的导入库而不是静态库。检查output\lib下是不是混进了libssl.lib的 DLL 版本或者no-shared没生效。5. 编译 librtmp 时最容易翻车的几个地方5.1 现象报ssize_t未定义一堆红字原因ssize_t是 POSIX 类型MSVC 默认不提供。librtmp 源码里有些地方直接用了它在 Linux 下没问题在 VS 下就炸。解决在rtmp.h或者工程的预处理器里加一个类型定义。最稳妥的做法是在包含 librtmp 头文件之前自己补一个#ifdef _MSC_VER #include basetsd.h typedef SSIZE_T ssize_t; #endif或者直接在 VS 工程里加预处理器宏_SSIZE_T_DEFINED然后确保basetsd.h被包含。我一般选前者因为改工程宏有时候会被其他头文件的包含顺序干扰。5.2 现象链接时报LNK2038说 RuntimeLibrary 不匹配原因zlib、OpenSSL、librtmp 三个工程的运行时库设置不一致。有的是/MD有的是/MT链接器检测到冲突就拒绝生成。解决统一改成/MT或者统一/MD。如果你要交付独立库选/MT如果你只是自己项目内部用/MD也行但部署时要带 VC 运行时。改的时候三个库都要重新编译不能只改一个。5.3 现象编译通过但运行时RTMP_Connect返回失败日志显示握手错误原因大概率是 OpenSSL 的加密部分没链进去或者NO_CRYPTO宏被误加了。也有可能是 OpenSSL 版本和 librtmp 源码不兼容比如用了 OpenSSL 3.x 的 API而 librtmp 里还是 1.1.1 的调用方式。解决先确认NO_CRYPTO没定义再确认链接的是libssl.lib和libcrypto.lib而不是 DLL 导入库。如果还不行抓包看握手阶段服务端返回的具体错误码RTMPE 握手失败通常是 DH 参数不匹配换 OpenSSL 1.1.1w 基本能解决。5.4 现象32 位工程链接 64 位库报LNK1112模块计算机类型冲突原因zlib 或 OpenSSL 编的是 64 位但 librtmp 工程建的是 32 位或者反过来。解决统一位数。检查方法是在 VS 里看工程属性「平台」是 Win32 还是 x64然后确认output\lib下的.lib是用哪个位数编的。可以用dumpbin /headers zlib.lib | findstr machine来看x64 会显示machine (x64)x86 显示machine (x86)。5.5 现象nmake install之后output\include里没有openssl目录原因OpenSSL 的--openssldir和--prefix设置不对或者nmake install中途报错但被忽略了。解决重新执行nmake install并且把输出完整看一遍。正常情况下output\include\openssl下应该有几十个头文件。如果没有检查--prefix路径是否可写以及 Perl 配置阶段有没有报 warning。6. 交付一个可直接集成的 librtmp SDK目录规范与验证技巧编完不是终点能让人直接拿去用才是。我习惯在output目录里再补一个librtmp_sdk文件夹结构如下librtmp_sdk\ ├── include\ │ ├── rtmp.h │ ├── log.h │ ├── zlib.h │ ├── zconf.h │ └── openssl\ # 整个 openssl 头文件目录 ├── lib\ │ ├── librtmp.lib │ ├── zlib.lib │ ├── libssl.lib │ └── libcrypto.lib └── README.txt # 写清楚 VS2017 集成时的附加依赖项README.txt里我一般只写三行关键信息附加包含目录填include附加库目录填lib附加依赖项填librtmp.lib;zlib.lib;libssl.lib;libcrypto.lib;ws2_32.lib;crypt32.lib;。这样别人拿到之后五分钟就能在自己的工程里跑起来。验证 SDK 是否完整我有个偷懒但有效的办法新建一个空的 VS2017 控制台工程只加一个main.cpp里面调用RTMP_Init和RTMP_SetupURL然后链接这个 SDK。如果编过并且运行不崩说明头文件和库文件都是齐的。这个测试不需要真的连服务器只是验证编译链接链路。#include rtmp.h #include iostream int main() { RTMP* rtmp RTMP_Alloc(); if (!rtmp) { std::cerr RTMP_Alloc failed std::endl; return -1; } RTMP_Init(rtmp); std::cout librtmp init ok std::endl; RTMP_Free(rtmp); return 0; }这段代码能编过并输出librtmp init ok就说明你的librtmp.lib是真正可用的不是那种编出来但符号不全的半成品。最后说一个我自己的习惯每次编完这套东西我会把output目录整个打包文件名带上日期和 VS 版本比如librtmp_vs2017_x64_202406.zip。下次再遇到需要这个库的项目直接解压配路径不用重新走一遍编译流程。这个习惯帮我省过至少两次通宵排错的时间希望帮到你。本文还有配套的精品资源点击获取
