简介：本资源是一套专为Windows平台开发者准备的librtmp静态库编译工程，面向使用Visual Studio 2017进行音视频流媒体开发的中高级程序员，解决在Win10环境下难以直接编译librtmp源码、依赖库缺失或链接失败等常见问题。压缩包共238个文件，涵盖163个头文件（.h）与7个核心C源文件（如rtmp.c、amf.c、parseurl.c），完整包含openssl-1.0.1c和zlib-1.2.8依赖库、预配置的vs2017工程（librtmp.sln）、以及编译所需的.cnf配置、.vcxproj项目文件和调试符号（.pdb/.ipch），总大小49.12MB，结构清晰、开箱即用。已有637人学习下载，用户可直接加载解决方案一键编译生成librtmp.lib，无需自行配置OpenSSL与zlib路径，大幅降低RTMP协议集成门槛，并可深入研读源码逻辑、调试日志输出（log.c）及SWF哈希处理（hashswf.c）等关键模块。
1. vs2017编译librtmp.lib：不是“点一下就完事”的黑匣子，而是Win10环境下绕不开的RTMP底层链路补全方案
你有没有遇到过这种场景：用C++写一个推流客户端，调用ffmpeg的avformat_open_input失败，报错Unknown input format: 'rtmp'；或者自己手撸socket发RTMP握手包，结果在connect()之后卡死在send()——不是网络问题，是Windows下缺了真正能跑通的librtmp静态库。vs2017编译librtmp.lib这个资源，就是为这类问题准备的“最后一块拼图”：它不是封装好的DLL或NuGet包，而是一份带完整依赖树、可直连VS2017工程、经Win10实测通过的源码级构建产物。它包含openssl-1.0.2u、zlib-1.2.11两个关键引用库的预编译头文件与lib，以及librtmp原始源码（含patched的win32兼容层），所有路径、宏定义、运行时库（/MT）均已对齐vs2017默认配置。适合正在做音视频采集推流、自研RTMP协议栈、或需要脱离ffmpeg独立控制RTMP连接生命周期的C++开发者。如果你还在用别人编译好的librtmp.dll、或者靠MinGW交叉编译凑合，那这份资源能帮你把整个RTMP链路从“玄学调通”拉回“可控调试”。
2. 编译前必须理清的三件事：为什么非得是vs2017 + Win10 + 静态lib？
2.1 为什么不是vs2019/vs2022？——ABI兼容性不是选择题，是硬约束
vs2017使用的MSVC v141工具集（_MSC_VER=1916）与Win10 SDK 10.0.17763.0深度绑定，而librtmp中大量使用#ifdef _WIN32分支下的WSAStartup、ioctlsocket等Winsock 2 API，其结构体定义（如struct sockaddr_in6）在vs2019+的SDK中存在字段偏移变化。某次我尝试用vs2019重编译同一份源码，链接时出现unresolved external symbol __imp__getaddrinfo@16——不是函数没实现，是vs2019默认启用/D_WIN32_WINNT=0x0A00，导致getaddrinfo被映射到ws2_32.dll新导出表，而librtmp源码里仍按旧版ws2_32.lib链接。vs2017则天然匹配_WIN32_WINNT=0x0601（Win7），Win10向下兼容无压力。
2.2 为什么必须带openssl和zlib？——RTMP协议栈的“呼吸器官”不能缺
librtmp本身不处理TLS/SSL加密和FLV头压缩，但实际生产环境99%的RTMP URL都是rtmps://或带?token=参数的加密流。源码中RTMP_Connect0函数内部会调用SSL_library_init()，若缺失openssl.lib，链接器直接报LNK2019: unresolved external symbol SSL_library_init；而zlib用于解压服务器返回的@setDataFrame中的AMF0压缩数据（比如Flash播放器发送的元数据）。本资源包内deps\openssl\lib\openssl.lib是vs2017 x64静态编译版（/MT），deps\zlib\lib\zlibstatic.lib同样为/MT模式，二者与librtmp.lib的C运行时完全一致——这是避免LNK2005: _malloc already defined的核心前提。
2.3 为什么坚持静态lib（.lib）而非DLL？——调试时堆栈不跳转，才是真可控
动态链接librtmp.dll时，一旦RTMP_Read内部触发select()超时，VS调试器会直接跳出源码视图，进入ntdll.dll!NtWaitForSingleObject黑盒；而静态链接后，所有符号（包括openssl的SSL_read、zlib的inflate）全部展开，你能在rtmp.c第1892行nBytes = SSL_read(r->m_pSSL, ...)处设断点，逐行看SSL握手状态机流转。更重要的是，静态库允许你修改#define RTMP_DEBUG宏，打开RTMP_LogPrintf日志，日志输出直接打到VS输出窗口，无需额外配置DLL调试符号路径。
提示：本资源不提供CMakeLists.txt或vcpkg集成方案。它面向的是需要将librtmp嵌入现有MFC/Qt/C++ CLI项目的工程师，而非从零构建新项目。若你用CMake，需手动在
target_link_libraries中添加librtmp.lib及ws2_32.lib ssl.lib crypto.lib zlibstatic.lib，并确保include_directories指向deps\openssl\include和deps\zlib\include。
3. 五步完成编译：从解压到生成librtmp.lib的完整流水线
3.1 解压与目录结构确认：别让路径空格毁掉整个编译
下载解压后，你会看到如下结构：
vs2017_librtmp/ ├── librtmp/ # librtmp原始源码（含win32补丁） ├── deps/ │ ├── openssl/ # openssl-1.0.2u头文件+lib（/MT） │ └── zlib/ # zlib-1.2.11头文件+lib（/MT） ├── build_vs2017/ # vs2017工程文件夹 │ └── librtmp.sln # 已配置好所有依赖路径的解决方案 └── README.md关键动作：将整个vs2017_librtmp文件夹放在无中文、无空格、路径长度<120字符的位置（例如D:\dev\librtmp_vs2017）。曾有同事放在C:\Users\张三\Downloads\下，编译时cl.exe报错fatal error C1083: Cannot open source file: 'D:\Users\...': No such file or directory——不是文件不存在，是Windows命令行对UTF-8路径解析失败。
3.2 打开解决方案并校验平台工具集
双击build_vs2017\librtmp.sln，用vs2017打开（不要用vs2019+兼容模式打开）。右键解决方案 →属性→常规→ 确认平台工具集为Visual Studio 2017 (v141)，Windows SDK版本为10.0.17763.0。若显示Inherit from parent or project defaults，点击下拉箭头手动选中。这一步漏掉，后续所有编译都会因SDK头文件不匹配而失败。
3.3 修改项目属性：三处必须改的配置项
右键librtmp项目 →属性→ 进入配置属性页，按顺序修改：
C/C++ → 常规 → 附加包含目录
填入：
$(ProjectDir)..\deps\openssl\include;$(ProjectDir)..\deps\zlib\include;$(ProjectDir)..说明：
$(ProjectDir)..\指向librtmp/目录，其中log.h等头文件在此；..\deps\是openssl/zlib头文件根目录。注意路径间用分号隔开，末尾不加反斜杠。
链接器 → 常规 → 附加库目录
填入：
$(ProjectDir)..\deps\openssl\lib;$(ProjectDir)..\deps\zlib\lib说明：此处只填路径，不填具体lib名。lib名在下一步指定。
链接器 → 输入 → 附加依赖项
填入：
ws2_32.lib ssl.lib crypto.lib zlibstatic.lib说明：顺序不能乱！
ws2_32.lib必须在最前（librtmp依赖Winsock），ssl.lib和crypto.lib是openssl的两个lib（openssl-1.0.2u已拆分），zlibstatic.lib是zlib静态库。若漏掉crypto.lib，链接时会报LNK2019: unresolved external symbol RSA_new。
3.4 编译前最后检查：预处理器定义与运行时库
仍在此项目属性页，进入C/C++ → 预处理器 → 预处理器定义，确认包含以下宏（已预置）：
WIN32;_WINDOWS;_CRT_SECURE_NO_WARNINGS;OPENSSL_NO_KRB5;ZLIB_WINAPI说明：
_CRT_SECURE_NO_WARNINGS关闭安全函数警告（避免strcpy报错）；OPENSSL_NO_KRB5禁用Kerberos（librtmp不用）；ZLIB_WINAPI启用Windows API风格zlib调用（与zlibstatic.lib匹配）。
再进入C/C++ → 代码生成 → 运行时库，确认为多线程(/MT)（不是/MD！）。这是与deps\openssl\lib\openssl.lib和deps\zlib\lib\zlibstatic.lib保持一致的关键——若选/MD，链接时会出现LNK2038: mismatch detected for 'RuntimeLibrary'。
3.5 执行编译并验证输出
点击菜单栏生成 → 重新生成解决方案。正常情况下，输出窗口应显示：
1>------ 已启动重新生成: 项目: librtmp, 配置: Release Win32 ------ 1> rtmp.c 1> log.c 1> parseurl.c 1> Generating Code... 1> librtmp.vcxproj -> D:\dev\librtmp_vs2017\build_vs2017\Release\librtmp.lib编译成功后，在build_vs2017\Release\目录下会生成librtmp.lib（约380KB）和librtmp.pdb（调试符号）。用dumpbin /exports librtmp.lib可验证导出函数：
dumpbin /exports librtmp.lib | findstr "RTMP_"应看到RTMP_Alloc,RTMP_Init,RTMP_SetupURL,RTMP_Connect,RTMP_Read等核心函数——说明符号导出正常，不是空壳lib。
4. 避坑指南：那些让你编译失败三次才找到原因的典型问题
4.1 现象：LNK2019: unresolved external symbol _getaddrinfo@16
原因：getaddrinfo是Winsock2函数，但项目未链接ws2_32.lib，或链接顺序错误（ws2_32.lib不在附加依赖项最前面）。
解决：回到链接器 → 输入 → 附加依赖项，确认ws2_32.lib是第一个，且没有拼写错误（注意是ws2_32.lib，不是wsock32.lib）。
4.2 现象：error C2065: 'INT_MAX' : undeclared identifier
原因：librtmp/rtmp.h中引用了<limits.h>，但vs2017默认不自动包含该头文件，且deps\openssl\include\openssl\ossl_typ.h中#define OPENSSL_NO_INTTYPES_H导致类型定义缺失。
解决：在librtmp项目属性 →C/C++ → 预处理器 → 预处理器定义中，追加_CRT_SECURE_NO_WARNINGS;WIN32;_WINDOWS;OPENSSL_NO_KRB5;ZLIB_WINAPI;_USE_32BIT_TIME_T（注意新增_USE_32BIT_TIME_T），并在C/C++ → 常规 → 附加包含目录最前面加上$(VC_IncludePath)（让编译器优先找VS自带头文件）。
4.3 现象：LNK2005: _malloc already defined in libucrt.lib(malloc.obj)
原因：deps\openssl\lib\openssl.lib和deps\zlib\lib\zlibstatic.lib是用/MT编译的，但你的项目属性中运行时库误设为/MD（动态链接CRT），导致CRT库冲突。
解决：严格检查C/C++ → 代码生成 → 运行时库是否为多线程(/MT)。若已设对但仍报错，右键项目 →清理，再重新生成——有时旧obj文件残留会触发此错误。
4.4 现象：RTMP_Connect返回0，但RTMP_GetError(r)返回-1，无日志输出
原因：未初始化Winsock，或RTMP_LogSetLevel(RTMP_LOGDEBUG)未在RTMP_Alloc前调用。
解决：在调用librtmp任何函数前，插入：
// 初始化Winsock WSADATA wsaData; WSAStartup(MAKEWORD(2, 2), &wsaData); // 设置日志级别（必须在RTMP_Alloc前） RTMP_LogSetLevel(RTMP_LOGDEBUG); RTMP_LogSetOutput(stderr); // 输出到控制台4.5 现象：编译通过，但运行时报0xC0000005: Access violation reading location 0x00000000
原因：RTMP *r = RTMP_Alloc();后未调用RTMP_Init(r)，直接RTMP_SetupURL(r, "rtmp://...")，导致r->m_sb.sb_socket为0，connect()时访问空指针。
解决：强制遵循librtmp初始化四步曲：
RTMP *r = RTMP_Alloc(); RTMP_Init(r); // 必须！ RTMP_SetupURL(r, "rtmp://example.com/live/stream"); RTMP_EnableWrite(r); // 推流必需5. 在你的项目中调用librtmp.lib：从链接到推流的最小可行验证
5.1 新建测试工程并配置依赖
新建一个Win32控制台应用（空项目），在项目属性 → 配置属性中设置：
C/C++ → 常规 → 附加包含目录：D:\dev\librtmp_vs2017\librtmp;D:\dev\librtmp_vs2017\deps\openssl\include;D:\dev\librtmp_vs2017\deps\zlib\include链接器 → 常规 → 附加库目录：D:\dev\librtmp_vs2017\build_vs2017\Release;D:\dev\librtmp_vs2017\deps\openssl\lib;D:\dev\librtmp_vs2017\deps\zlib\lib链接器 → 输入 → 附加依赖项：librtmp.lib ws2_32.lib ssl.lib crypto.lib zlibstatic.lib
注意：路径必须与你解压的实际位置一致。建议用绝对路径，避免相对路径在不同配置下失效。
5.2 编写最小推流验证代码
创建main.cpp，内容如下（仅12行核心逻辑，无异常处理）：
#include <stdio.h> #include <stdlib.h> #include "librtmp/rtmp.h" int main() { // 1. 初始化Winsock WSADATA wsaData; WSAStartup(MAKEWORD(2, 2), &wsaData); // 2. 创建并初始化RTMP对象 RTMP *r = RTMP_Alloc(); RTMP_Init(r); // 3. 设置RTMP URL（替换为你自己的推流地址） RTMP_SetupURL(r, "rtmp://127.0.0.1:1935/live/test"); // 4. 启用写入（推流必需） RTMP_EnableWrite(r); // 5. 连接 if (!RTMP_Connect(r, NULL)) { printf("Connect failed!\n"); return -1; } printf("Connected successfully!\n"); // 6. 发送发布命令（关键！否则服务器拒绝推流） if (!RTMP_ConnectStream(r, 0)) { printf("Stream connect failed!\n"); return -1; } printf("Stream published!\n"); RTMP_Close(r); RTMP_Free(r); WSACleanup(); return 0; }5.3 编译并运行验证
点击生成 → 生成解决方案，若无错误，运行生成的exe。预期输出：
Connected successfully! Stream published!此时，用VLC打开rtmp://127.0.0.1:1935/live/test应能看到黑屏（因未发送视频帧），但连接已建立——证明librtmp.lib已成功集成。
提示：若连接失败，请打开
RTMP_LogSetLevel(RTMP_LOGDEBUG)并重定向日志到文件，观察握手过程哪一步卡住。常见于防火墙拦截1935端口，或Nginx-rtmp模块未正确配置application live { }。
6. 进阶技巧：如何用这个librtmp.lib做真正的音视频推流？
6.1 构建FLV封装器：把原始H.264/AVC帧塞进RTMP流
librtmp不处理编码，只负责传输。要推流，你得自己构造FLV格式的onMetaData、AVC sequence header和AVC NALU。核心是RTMP_Write函数：
// 假设frame_data是H.264的SPS+PPS+NALU，frame_len是总长度 // flv_tag_header[11] = {0x09, 0x00,0x00,0x00,0x01, 0x00,0x00,0x00,0x00, 0x00,0x00}; // FLV video tag头 uint8_t flv_tag_header[11] = {0}; flv_tag_header[0] = 0x09; // video tag flv_tag_header[4] = (frame_len >> 16) & 0xFF; // data size flv_tag_header[5] = (frame_len >> 8) & 0xFF; flv_tag_header[6] = frame_len & 0xFF; flv_tag_header[10] = 0x01; // AVC NALU // 写入tag头 RTMP_Write(r, flv_tag_header, 11); // 写入时间戳（毫秒） uint32_t timestamp = htonl(0); // 时间戳 RTMP_Write(r, (char*)×tamp, 3); // 只写低3字节 // 写入NALU数据 RTMP_Write(r, (char*)frame_data, frame_len);关键点：
RTMP_Write第二个参数是char*，第三个是int字节数。flv_tag_header必须严格按FLV规范构造，否则播放器无法解析。SPS/PPS需在首帧前发送一次，后续帧只发NALU。
6.2 处理RTMP重连：当网络抖动时不让推流中断
librtmp原生不支持自动重连，需手动实现。核心逻辑是捕获RTMP_IsConnected(r) == FALSE，然后重建连接：
while (is_running) { if (!RTMP_IsConnected(r)) { printf("Connection lost, reconnecting...\n"); RTMP_Close(r); RTMP_Free(r); r = RTMP_Alloc(); RTMP_Init(r); RTMP_SetupURL(r, url); RTMP_EnableWrite(r); if (RTMP_Connect(r, NULL) && RTMP_ConnectStream(r, 0)) { printf("Reconnected!\n"); } else { Sleep(1000); // 重试间隔 continue; } } // 正常推流逻辑... }血泪经验：
RTMP_ConnectStream(r, 0)必须在每次重连后调用，否则服务器认为未发布流，拒绝接收数据。Sleep(1000)防止高频重连打爆服务器。
6.3 调试技巧：用Wireshark抓包验证RTMP握手是否合规
当推流失败又无日志时，用Wireshark过滤tcp.port==1935，观察三次握手后是否出现connect、createStream、publishAMF0消息。正常流程应为：
- Client → Server：
connect（含app="live"） - Server → Client：
_result（含streamId=1） - Client → Server：
createStream - Server → Client：
_result（含streamId=2） - Client → Server：
publish streamName="test"
若卡在第2步，说明RTMP_SetupURL参数错误（如app名不匹配Nginx配置）；若卡在第4步，说明RTMP_ConnectStream未调用。
从那以后我每次集成librtmp.lib，都强制走一遍dumpbin /exports验证符号、用RTMP_LogSetLevel(RTMP_LOGDEBUG)开日志、用Wireshark抓包三件套——少一次，就可能多花半天在“为什么连不上”上兜圈子。希望帮到你。
本文还有配套的精品资源，点击获取
