简介：面向需要在 Windows 10 与 VS2017 环境下使用 RTMP 推流能力的 C/C++ 开发者，这份资源提供了一套可直接编译的 librtmp.lib 静态库工程，省去自行移植与配置依赖的繁琐过程。压缩包共 238 个文件、约 49.12MB，以 163 个头文件为主，辅以 28 个 dll、8 个 lib 及少量 c 源文件与工程配置，涵盖 librtmp 主体、openssl-1.0.1c、zlib-1.2.8 等依赖模块，并附带 librtmp.sln 解决方案，目录按 lib、librtmp、vs2017 等分层组织，结构清晰便于定位。已有 640 人学习下载。读者可直接打开解决方案完成编译，获得可链接的库文件，同时借助随包源码理解 RTMP 协议实现与第三方库的集成方式，适合需要快速搭建推流基础环境或研究库编译流程的中高级开发者参考。
1. 在 Win10 + VS2017 里把 librtmp 编成能直接引用的静态库
手上有个做流媒体推流的小工具，底层要用 RTMP 协议，翻遍现成的 SDK 要么体积大得离谱，要么得连带拖一堆运行时依赖。最后决定自己编一份 librtmp 静态库，环境就是 Win10 加 VS2017。真正动手才发现，这库的源码是给 Unix 系工具链写的，直接扔进 VS 里编译，报错能刷满整个输出窗口。这份资源把编译好的.lib、配套头文件和完整源码一起打包，省掉了从零配工程那一步。它适合两类人：一类是想在 Windows 桌面程序里嵌 RTMP 推拉流、又不想引入重型框架的开发者；另一类是接手了老项目、发现工程里引用的 librtmp 版本对不上、需要自己重编一份的人。下面按「这库是什么 → 工程怎么搭 → 源码怎么改 → 坑在哪 → 怎么二次开发」的顺序拆。
2. 工程结构与编译链路：从源码目录到可引用的 .lib
2.1 先看清包里有什么
拿到压缩包，别急着双击.sln。先解压出来扫一眼目录，心里有个数再动手。典型的目录组织大致是这样：
librtmp-build/ ├── librtmp/ # 上游源码 │ ├── rtmp.c # 协议核心，握手/连接/收发都在这 │ ├── rtmppacket.c # RTMP 包封装与解析 │ ├── handshake.c # 握手流程 │ ├── hashswf.c # SWF 校验相关 │ ├── log.c # 日志输出 │ ├── amf.c # AMF0/AMF3 编解码 │ ├── parseurl.c # RTMP URL 解析 │ └── rtmp_sys.h # 平台适配头，Windows 下改动最多 ├── include/ │ ├── rtmp.h # 对外主头文件 │ ├── amf.h │ └── ... ├── deps/ # 依赖库（zlib / openssl 视配置而定） ├── vs2017/ │ └── librtmp.sln # 现成的 VS 工程 └── output/ ├── librtmp.lib # 编好的静态库 └── include/ # 可直接拷进业务工程的头文件关键点在于rtmp_sys.h。这个头文件是整份源码里平台差异最集中的地方，Unix 下的sys/socket.h、unistd.h、arpa/inet.h在 Windows 上全都不存在，得靠winsock2.h、ws2tcpip.h顶上。包里如果已经改好了这一层，编译成功率会高很多；如果拿到的是纯上游源码，这一块就是第一个要动刀的地方。
2.2 编译产物的两种形态：静态库和动态库
librtmp 编出来可以是.lib静态库，也可以是.dll加导入库。选哪种取决于你的业务工程怎么分发。静态库的好处是最终 exe 单文件就能跑，不用额外带 dll，适合小工具；坏处是每个引用它的工程都会把库代码链进去一份，多个模块同时用会重复。动态库则相反，升级库文件不用重编业务代码，但分发时得把 dll 放到 exe 同目录或系统路径下。
这份资源给的是静态库形态，也就是librtmp.lib。引用时业务工程需要做三件事：把头文件目录加进「附加包含目录」，把.lib所在目录加进「附加库目录」，再在「附加依赖项」里写上librtmp.lib。如果库依赖了 zlib 或 openssl，这些依赖库也得一并链上，顺序还有讲究——被依赖的放后面。
2.3 运行时库选项必须对齐
这是静态库最容易翻车的地方，也是新手最常忽略的。VS 的「C/C++ → 代码生成 → 运行时库」有四个选项：/MT、/MTd、/MD、/MDd。librtmp.lib 编译时用的是哪一档，业务工程就必须用同一档，否则链接阶段会报LNK2005 已经在 xxx.obj 中定义或者LNK2038 检测到 RuntimeLibrary 的不匹配。
血泪经验是：Debug 配置对应/MTd或/MDd，Release 对应/MT或/MD，带d的是调试版。如果包里只给了一份 Release 的.lib，那你的 Debug 工程链上去大概率出问题，要么切到 Release 调试，要么自己按 Debug 配置重编一份。判断方法很简单，链接报错里出现_ITERATOR_DEBUG_LEVEL或RuntimeLibrary字样，基本就是这一档没对齐。
2.4 用命令行验证库是否可用
工程配好之前，可以先写个最小程序验证库能不能链上、能不能调通。新建一个空的控制台工程，把下面这段贴进去：
// smoke_test.c —— 最小验证：初始化 + 版本号 + 清理 #include <stdio.h> #include "rtmp.h" // 来自 include 目录 int main(void) { RTMP *r = RTMP_Alloc(); // 分配一个 RTMP 上下文 if (r == NULL) { printf("RTMP_Alloc failed\n"); return -1; } RTMP_Init(r); // 初始化内部字段，含默认超时 printf("librtmp ready, ctx=%p\n", (void *)r); RTMP_Free(r); // 释放，避免泄漏 return 0; }这段代码只调了三个函数，但足以验证头文件路径、库路径、运行时库三件事是否都配对了。RTMP_Alloc内部会calloc一块上下文，RTMP_Init把协议版本、超时、缓冲区指针置成默认值，RTMP_Free负责回收。如果编译过但链接报unresolved external symbol RTMP_Alloc，说明.lib没链上或者架构不对（x86 的库链进了 x64 工程）；如果运行到RTMP_Alloc就崩，多半是运行时库不匹配导致的堆管理冲突。这一步跑通，后面接真实推流才有意义。
3. 核心源码拆解：握手、连接与包收发三段链路
3.1 握手流程：C0/C1/C2 与 S0/S1/S2 的往返
RTMP 连接建立的第一步是握手，源码在handshake.c。客户端发 C0（1 字节版本号）加 C1（1536 字节随机数加时间戳），服务端回 S0 加 S1，客户端再回 C2，服务端回 S2，握手完成。这段逻辑本身不复杂，但在 Windows 上要注意 socket 的阻塞行为差异。
// 握手核心片段（简化自 handshake.c，用于说明调用顺序） static int HandShake(RTMP *r, int FP9HandShake) { char clientbuf[RTMP_SIG_SIZE + 1]; // C0 + C1，共 1537 字节 char serversig[RTMP_SIG_SIZE]; // 收 S1 用 clientbuf[0] = 0x03; // C0：版本号，固定 3 // C1 前 4 字节是时间戳，后 4 字节填 0，其余为随机数 memset(clientbuf + 1, 0, 8); // ... 填充随机部分 ... if (!WriteN(r, clientbuf, RTMP_SIG_SIZE + 1)) // 发 C0+C1 return FALSE; if (ReadN(r, serversig, RTMP_SIG_SIZE) != RTMP_SIG_SIZE) // 收 S0+S1 return FALSE; // ... 校验并回 C2 ... return TRUE; }RTMP_SIG_SIZE是 1536，这个数字是协议写死的，改不得。WriteN和ReadN是库内部对 socket 收发的封装，保证「要么发满 N 字节，要么失败」，避免 TCP 粘包导致的半包问题。Windows 下send/recv的返回值语义和 Unix 一致，但错误码要用WSAGetLastError()取，不能看errno。这是移植时第一个容易漏的点。
3.2 连接建立：URL 解析与 RTMP_Connect
握手之后是连接，入口是RTMP_Connect。它内部先调RTMP_ParseURL把rtmp://host:port/app/playpath拆成协议、主机、端口、应用名、播放路径几段，再建 socket、解析 DNS、发起 TCP 连接，最后走握手和connect命令。
// 典型调用序列，业务代码里基本就是这个骨架 RTMP *r = RTMP_Alloc(); RTMP_Init(r); // 设置推流地址，内部会解析 host/port/app/playpath if (!RTMP_SetupURL(r, "rtmp://127.0.0.1:1935/live/stream1")) { // 地址格式错误，常见于漏了 app 段或端口写错 goto fail; } RTMP_EnableWrite(r); // 推流必须开，拉流不用 if (!RTMP_Connect(r, NULL)) { // 建 TCP + 握手 + connect 命令 goto fail; } if (!RTMP_ConnectStream(r, 0)) { // 创建流，0 表示从头发 goto fail; }RTMP_SetupURL里有个细节：如果 URL 里带了?查询串，会被当作 playpath 的一部分保留，某些服务端靠这个做鉴权。RTMP_EnableWrite决定后续是推还是拉，忘了调它去推流，会在RTMP_ConnectStream阶段被服务端拒绝。RTMP_Connect的第二个参数是RTMPPacket *，一般传NULL，只有需要自定义 connect 命令参数时才用。
3.3 包收发：RTMP_SendPacket 与读循环
连接建好后，推流就是不断构造RTMPPacket再发出去。音频包、视频包、元数据包各有不同的m_packetType和m_nChannel。
// 发送一个视频包的简化流程 RTMPPacket pkt; RTMPPacket_Alloc(&pkt, payload_len); // 分配包体缓冲 pkt.m_packetType = RTMP_PACKET_TYPE_VIDEO; // 0x09 pkt.m_nChannel = 0x04; // 视频常用通道 pkt.m_headerType = RTMP_PACKET_SIZE_LARGE; pkt.m_nTimeStamp = timestamp; // 毫秒时间戳，必须单调递增 pkt.m_nInfoField2 = r->m_stream_id; // 流 ID，ConnectStream 后才有值 memcpy(pkt.m_body, data, payload_len); pkt.m_nBodySize = payload_len; if (!RTMP_SendPacket(r, &pkt, TRUE)) { // TRUE 表示立即 flush // 发送失败，通常是连接已断 } RTMPPacket_Free(&pkt); // 释放包体，别漏m_nTimeStamp是推流里最玄学的一个字段。它必须是单调递增的毫秒数，服务端和播放器都靠它做音视频同步。如果时间戳回退或者跳变太大，播放端会花屏、卡顿甚至直接断开。常见做法是用一个起始时间点做基准，每次取GetTickCount64()减去基准值。RTMP_SendPacket的第三个参数控制是否立刻 flush，推流场景一般传TRUE，否则包会攒在缓冲区里延迟发出。
拉流侧则是循环调RTMP_ReadPacket加RTMP_IsConnected判断连接状态，读到包后按m_packetType分发处理。这个循环要放在独立线程里，主线程阻塞会拖垮整个界面。
4. 避坑与排查：Windows 下编译 librtmp 的五个高频问题
4.1 报 winsock 相关符号未定义
现象是链接阶段一堆unresolved external symbol __imp_socket、__imp_recv之类的错误。原因是工程没链ws2_32.lib。解决很简单，在「附加依赖项」里加上ws2_32.lib，或者在代码里#pragma comment(lib, "ws2_32.lib")。另外别忘了在程序启动时调一次WSAStartup(MAKEWORD(2,2), &wsaData)，否则所有 socket 调用都会返回WSANOTINITIALISED。
4.2 头文件里 sys/time.h 找不到
现象是编译阶段fatal error C1083: 无法打开包括文件: "sys/time.h"。这是 Unix 头文件，Windows 没有。原因在rtmp_sys.h的平台分支没走对。解决是确认该文件里#ifdef _WIN32分支生效，把sys/time.h、unistd.h这些替换成winsock2.h、ws2tcpip.h，时间相关用GetTickCount64()或timeGetTime()替代gettimeofday。如果包里给的源码已经改好，检查一下是不是你的工程没定义_WIN32宏（VS 默认会定义，但手写 Makefile 时容易漏）。
4.3 链接报 LNK2038 RuntimeLibrary 不匹配
现象是LNK2038: 检测到 "RuntimeLibrary" 的不匹配: 值 "MT_StaticRelease" 不匹配值 "MD_DynamicRelease"。原因就是 2.3 节说的运行时库档位不一致。解决是把业务工程的「代码生成 → 运行时库」改成和.lib编译时一致的那一档。判断.lib用的是哪档，可以看编译日志，或者干脆按自己工程的配置重编一份库，最省心。
4.4 推流几秒后断开，日志无明确错误
现象是连接成功、推流正常，但几秒到几十秒后RTMP_SendPacket开始返回失败。原因通常是时间戳不单调，或者发送速率超过服务端承受能力被踢。排查方法是把每次发送的m_nTimeStamp打日志，看有没有回退或跳变；同时检查是不是在循环里无节制地发，没有按帧率节流。解决是时间戳用单调时钟生成，发送侧加一个简单的节奏控制，别把缓冲区瞬间灌满。
4.5 Debug 下能跑，Release 下崩溃
现象是 Debug 配置一切正常，切到 Release 后程序在RTMP_Alloc或RTMP_Free附近崩溃。原因是 Debug 和 Release 用了不同的运行时库（一个/MTd一个/MT），而.lib只匹配了其中一种，导致堆的分配和释放跨了不同的堆管理器。解决是给 Debug 和 Release 各编一份对应的.lib，在工程里按配置分别引用，别图省事一份库走天下。
5. 二次开发：把静态库接进业务工程并做可控改造
真正把 librtmp 用起来，重点不在「能不能编过」，而在「接进业务后怎么管住它」。我一般会做三件事。第一件是封装一层薄薄的 C++ 接口，把RTMP*裸指针藏进 RAII 类里，构造时RTMP_Alloc加RTMP_Init，析构时RTMP_Free，这样业务代码里不会出现忘记释放导致的内存泄漏。第二件是把连接状态做成回调，RTMP_IsConnected轮询太被动，可以在发送失败时主动触发重连逻辑，重连间隔做指数退避，避免服务端刚重启就被一堆客户端打满。第三件是给日志加开关，log.c里的输出默认打到 stderr，业务里要重定向到自己的日志系统，否则控制台程序还好，带界面的程序根本看不到。
改造时有个验证方法很实用：本地起一个 RTMP 服务端，用 ffplay 拉流看画面，同时用 Wireshark 抓包看握手和包序列对不对。如果画面正常但抓包发现时间戳有回退，那就是生成逻辑的问题，早发现早改。另外，静态库升级时记得同步更新头文件，rtmp.h里的结构体布局变了而业务代码还用旧头文件，会出现字段错位这种极难排查的问题。
从那以后我每次接一个新的静态库进工程，都强制先跑一遍 2.4 节那个最小验证程序，确认头文件、库路径、运行时库三件事全对齐了再往下写业务代码，省下的调试时间远比这几分钟多。希望帮到你。
本文还有配套的精品资源，点击获取
