简介面向流媒体协议学习与音视频客户端开发者的C实战源码聚焦RTSP/RTP客户端在Linux与Windows双平台下的编译与运行可用于理解会话协商、媒体传输与播放控制的完整链路适合具备一定网络编程基础的中高级开发者对照研读。压缩包共32个文件、约189KB以cpp与h源文件为主体辅以vcxproj工程与sln解决方案、makefile及mk构建脚本并附一份RTSP客户端源码分析doc文档便于按模块梳理代码结构。资源已实现OPTIONS、DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN等RTSP方法并基于live555服务器完成测试验证读者可据此掌握请求响应流程、套接字封装与线程同步等关键实现思路。目前已有2324人学习下载配套分析文档与双平台工程配置能显著降低阅读与调试门槛。1. 一份能直接编译的 C RTSP/RTP 客户端解决的是“协议看懂了但代码跑不通”做流媒体接入的同行大概都有过这种体验RFC 2326 和 RFC 3550 翻了三遍SDP 字段能背下来OPTIONS、DESCRIBE、SETUP、PLAY 的时序图也画得出来可真让自己从零写一个能拉 H.264 裸流的 C 客户端卡点全在协议之外——socket 收包粘包、RTP 时间戳换算、FU-A 分片重组、跨平台 socket 头文件差异随便一个都能耗掉两天。这份 C RTSP/RTP 流媒体客户端源码价值就在于把这条链路完整跑通了RTSP 信令交互、SDP 解析、RTP 收包与解包、H.264 分片重组、跨 Linux 与 Windows 的 socket 封装都在里面。适合两类人一是要快速给项目接一路 IPC 或 NVR 视频流的后端工程师二是想拿一份可调试代码对照协议学习的嵌入式方向开发者。下面按“它怎么组织、怎么编、怎么改参数、哪里会翻车”的顺序拆。2. RTSP 信令与 RTP 收包源码里两条并行的线程模型2.1 为什么是“信令同步 收流异步”的双线程结构RTSP 本质是一个文本协议的控制通道走 TCP默认 554 端口RTP 是媒体数据通道通常走 UDP。这两者的节奏完全不同RTSP 是请求-应答式的一问一答时序严格RTP 是持续推送的一秒几十到上百个包不能阻塞。源码里把这两件事拆成两个线程主线程负责 RTSP 状态机推进收流线程独立跑recvfrom循环中间用一个共享的会话结构体传递 SSRC、payload type、时间戳基准这些参数。这个结构的好处是排错边界清晰。信令出问题看主线程的请求应答日志花屏、卡顿、丢帧看收流线程的包统计。如果硬塞进单线程用select轮询一旦某个 RTSP 应答慢半拍收流缓冲区就会堆积表现出来就是“能连上但画面一顿一顿”这种玄学问题最难查。常见做法是在会话结构体里放一个原子标志位主线程 PLAY 成功后置位收流线程看到标志才开始往上层抛帧避免 SETUP 阶段收到脏包。源码里这个标志叫streaming_类型是std::atomicbool跨线程读写不用加锁。2.2 RTSP 状态机的四个必过关卡一个最小可用的 RTSP 客户端信令侧必须走完 OPTIONS → DESCRIBE → SETUP → PLAY 四步少一步服务端就可能拒绝。源码里对应四个函数我按调用顺序说明关键参数。// rtsp_client.cpp 节选信令主流程 bool RtspClient::open(const std::string url) { // 1. OPTIONS探测服务端支持的方法Public 头里会列出 SETUP/PLAY 等 if (!sendOptions(url)) return false; // 2. DESCRIBE拿 SDPAccept 头指定只收 SDP std::string sdp; if (!sendDescribe(url, sdp)) return false; // 3. 解析 SDP取出 video 轨道的 control 地址、payload type、编码格式 if (!parseSdp(sdp)) return false; // 4. SETUPTransport 头声明客户端 RTP/RTCP 端口通常 RTP 偶数、RTCP 奇数 if (!sendSetup()) return false; // 5. PLAYRange 头写 npt0.000- 表示从头播 if (!sendPlay()) return false; streaming_ true; // 通知收流线程可以开始抛帧 return true; }逻辑说明sendOptions里要拼CSeq递增序号每个请求的 CSeq 必须唯一且递增服务端靠它匹配应答重复或跳号会导致应答错位。sendDescribe的应答体就是 SDP 文本注意 Content-Length 头决定读多少字节不能靠“读到空行”判断结束因为 SDP 里本身有空行。parseSdp要抓mvideo那一行的 payload type再找对应的artpmap确认编码是 H264 还是 H265这一步决定了后面 RTP 解包的策略。sendSetup的 Transport 头格式是RTP/AVP;unicast;client_port8000-8001端口对必须成对且偶数开头服务端会在应答里回server_port收流线程要按这个端口发 RTCP RR。参数上最容易改错的是 CSeq 的起始值和 Transport 的端口范围。CSeq 从 1 开始即可但如果你在同一个 TCP 连接上复用多个会话CSeq 要全局递增不能每个会话各自从 1 数。端口建议用 8000 以上避开系统保留段且要检查是否被占用源码里用bind的返回值判断失败就换下一对端口重试。2.3 RTP 收包循环与 H.264 分片重组收流线程的核心是一个recvfrom循环收到 UDP 包后先剥 RTP 头固定 12 字节有 CSRC 时更长再按 payload type 判断是不是视频包最后交给 H.264 重组器。// rtp_receiver.cpp 节选收包与分片判断 void RtpReceiver::loop() { uint8_t buf[2048]; while (running_) { int n recvfrom(sock_, buf, sizeof(buf), 0, nullptr, nullptr); if (n 12) continue; // 小于固定头长度丢弃 RtpHeader hdr parseRtpHeader(buf); // 解析 seq、timestamp、marker、pt const uint8_t* payload buf hdr.header_len; int payload_len n - hdr.header_len; if (hdr.payload_type ! video_pt_) continue; // 非视频包如 RTCP跳过 uint8_t nal_type payload[0] 0x1F; if (nal_type 1 nal_type 23) { // 单 NAL 单元直接输出 onFrame(payload, payload_len, hdr.timestamp); } else if (nal_type 28) { // FU-A 分片首字节后是 FU headerS/E 位标识起止 handleFuA(payload, payload_len, hdr); } } }逻辑说明RTP 头的marker位标识一帧的最后一个包重组器靠它判断一帧是否收齐。timestamp是 90kHz 时钟同一帧内所有分片的 timestamp 相同跨帧才变化用它做帧边界校验比 marker 更稳因为有些服务端 marker 置位不规范。FU-A 分片的处理是重点payload 第一个字节是 FU indicator高 3 位是 NAL 类型 28第二个字节是 FU header最高位 S 表示起始分片次高位 E 表示结束分片低 5 位才是真正的 NAL 类型。重组时要把 FU indicator 和 FU header 拼回原始 NAL 头即(indicator 0xE0) | (fu_header 0x1F)这一步写错就是花屏或解码器直接报错。参数上video_pt_必须和 SDP 里artpmap的 payload type 一致常见 H.264 是 96但不同厂商设备可能用 97、98硬编码 96 是新手翻车高发点。缓冲区 2048 字节对大多数场景够用但 MTU 1500 下单个 RTP 包不会超过 1500留余量即可。3. 跨 Linux 与 Windows 编译socket 封装的三个差异点3.1 头文件与初始化WSAStartup 不能漏Linux 下 socket 就是文件描述符#include sys/socket.h直接能用Windows 下要#include winsock2.h且必须先调WSAStartup初始化 Winsock 库否则所有 socket 调用返回INVALID_SOCKET。源码里用条件编译把这块包起来。// platform_socket.h 节选跨平台 socket 初始化 #ifdef _WIN32 #include winsock2.h #include ws2tcpip.h #pragma comment(lib, ws2_32.lib) using socket_t SOCKET; #define CLOSE_SOCKET closesocket #else #include sys/socket.h #include netinet/in.h #include unistd.h using socket_t int; #define CLOSE_SOCKET close #endif inline bool initSocketLib() { #ifdef _WIN32 WSADATA wsa; return WSAStartup(MAKEWORD(2, 2), wsa) 0; // 请求 2.2 版本 #else return true; // Linux 无需初始化 #endif }逻辑说明MAKEWORD(2, 2)请求 Winsock 2.2这是目前最通用的版本请求低版本会缺一些函数。socket_t用类型别名统一避免在业务代码里到处写#ifdef。关闭 socket 也要走宏Windows 的closesocket和 Linux 的close不能混用混了在 Windows 上会泄漏句柄跑久了就“连不上新流”。参数上WSAStartup的返回值必须检查非 0 说明初始化失败常见原因是系统缺少对应版本的 Winsock 组件。另外 Windows 下recvfrom的超时要用setsockopt设SO_RCVTIMEO参数是DWORD毫秒Linux 下是struct timeval秒微秒。源码里封装了一个setRecvTimeout函数内部按平台分支调用方传毫秒数即可。3.2 编译命令与依赖两套构建脚本源码目录里通常带CMakeLists.txtLinux 和 Windows 都能用但 Windows 下建议用 MSVC 或 MinGW 分别验证因为winsock2.h和windows.h的包含顺序有坑——windows.h会带入旧版winsock.h和winsock2.h冲突报一堆重定义错误。解决办法是在包含windows.h之前先#define WIN32_LEAN_AND_MEAN或者干脆不包含windows.h。# Linux 构建 mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j4 # WindowsMinGW构建 mkdir build cd build cmake .. -G MinGW Makefiles -DCMAKE_BUILD_TYPERelease mingw32-make -j4逻辑说明CMAKE_BUILD_TYPERelease开优化收流循环对性能敏感Debug 版在低配机器上可能丢包。-j4按核数调整源码文件不多4 线程足够。Windows 下如果链接报undefined reference to WSAStartup说明没链ws2_32CMake 里要加target_link_libraries(rtsp_client ws2_32)。参数上CMake 的CMAKE_CXX_STANDARD建议设 11 以上源码里用了std::atomic和std::threadC98 编不过。如果目标机器是老系统注意std::thread在部分旧 MinGW 上需要额外链pthreadLinux 下也要在 CMake 里find_package(Threads REQUIRED)。3.3 运行验证先看信令日志再看帧统计编出来之后别急着接播放器先跑源码自带的日志模式确认四步信令都返回 200。源码里RtspClient有个setVerbose(true)开关打开后每个请求和应答的头部都会打到 stdout。信令通了再看收流线程的统计收包数、丢包数按 seq 跳变估算、重组成功帧数。这三个数正常增长才说明链路真正通了。// main.cpp 节选最小验证入口 int main(int argc, char** argv) { if (!initSocketLib()) return -1; RtspClient client; client.setVerbose(true); // 打开信令日志 if (!client.open(rtsp://127.0.0.1:554/live/test)) { return -2; // 信令失败 } std::this_thread::sleep_for(std::chrono::seconds(10)); // 收 10 秒 auto stat client.getStat(); printf(recv%llu lost%llu frames%llu\n, stat.packets, stat.lost, stat.frames); return 0; }逻辑说明open返回 false 时日志里能看到是哪一步的应答码不对404 是 URL 路径错401 是要鉴权454 是会话不存在。收 10 秒足够看出统计趋势lost持续增长说明网络或缓冲区有问题frames为 0 但packets在涨多半是 payload type 没对上或 FU-A 重组逻辑有 bug。参数上测试 URL 换成你自己的设备地址路径部分因设备而异常见是/live/ch0或/Streaming/Channels/101。如果设备要 Digest 鉴权源码里sendDescribe之后要处理 401 应答按WWW-Authenticate头算 MD5 再重发这块源码有预留接口但默认没开需要自己补。4. 避坑清单五个让客户端“能连上但不出画面”的典型问题4.1 现象信令全 200但 frames 一直是 0原因SDP 里mvideo的 payload type 和代码里video_pt_不一致收流线程把所有包都当非视频包跳过了。不同厂商设备 H.264 常用 96但也有用 97 甚至 100 的硬编码必翻车。解决parseSdp里把artpmap:pt H264/90000的 pt 解析出来赋给video_pt_不要写死。解析时注意rtpmap行可能有多条音频、视频各一条要按m行的顺序对应不能抓第一条就用。4.2 现象画面能出但每隔几秒花一下原因FU-A 重组时丢了中间分片重组器没做超时清理把残缺帧当完整帧抛给解码器。UDP 本身不保证顺序和到达丢包是常态。解决重组器里给每一帧记一个起始时间超过 200ms 还没收到 E 位分片就丢弃整帧并计数。同时按 RTP seq 检测跳变跳变超过阈值说明中间丢了包当前帧直接作废。源码里handleFuA有frame_start_ts_成员补一个超时判断即可。4.3 现象Windows 下编译报 winsock 重定义原因某个头文件间接包含了windows.h它带入旧版winsock.h和winsock2.h冲突。解决在项目最顶层的公共头里第一行#define WIN32_LEAN_AND_MEAN再包含winsock2.h。如果还有冲突检查是否有第三方头在winsock2.h之前包含了windows.h调整包含顺序。4.4 现象Linux 下跑几分钟后 bind 失败换端口也没用原因socket 关闭后进入 TIME_WAIT 状态端口被占着快速重连时bind返回EADDRINUSE。解决setsockopt设SO_REUSEADDR在bind之前调用。注意这个选项只解决 TIME_WAIT 复用不解决端口真被别的进程占用的情况后者要靠netstat或ss查。4.5 现象收流线程 CPU 占用 100%原因recvfrom是阻塞调用但如果 socket 设了非阻塞又没数据会忙等空转。或者收流循环里每收一个包就printf一次IO 拖垮性能。解决保持阻塞模式用SO_RCVTIMEO设 500ms 超时超时返回就检查running_标志决定是否退出不要用非阻塞轮询。日志改成计数汇总每 100 帧打一次别逐包打。5. 进阶用 RTCP RR 反推网络质量把“卡了”变成可量化指标基础版跑通之后真正拉开差距的是对链路质量的感知。RTP 只负责推数据网络好不好它不管RTCP 的 Receiver Report 才是客户端的“黑匣子”里面带着丢包率、累计丢包数、抖动jitter和最高序列号服务端靠这些做拥塞判断我们自己也能拿来定位问题。源码里 RTCP 部分默认只发不收我一般会补一个 RR 解析把关键字段抽出来打日志。RR 包结构是固定的头 8 字节版本、包类型 201、长度、SSRC后面每个 report block 24 字节字段依次是 SSRC、丢包率8 位定点实际值除以 256、累计丢包24 位、最高 seq、jitter、LSR、DLSR。// rtcp_parser.cpp 节选解析 RR 的 report block void parseRr(const uint8_t* buf, int len) { if (len 8 || (buf[1] ! 201)) return; // 只处理 RR int rc buf[0] 0x1F; // report count const uint8_t* p buf 8; for (int i 0; i rc (p - buf) 24 len; i, p 24) { uint32_t ssrc readU32(p); uint8_t frac p[4]; // 丢包率除以 256 uint32_t cum readU24(p 5); // 累计丢包 uint32_t jit readU32(p 12); // 抖动单位 1/90000 秒 printf(ssrc%u loss%.2f%% cum%u jitter%.1fms\n, ssrc, frac * 100.0 / 256.0, cum, jit * 1000.0 / 90000.0); } }逻辑说明frac是最近一个报告周期的丢包率cum是会话开始以来的累计丢包两者结合看趋势——frac高但cum涨得慢说明是瞬时拥塞cum持续涨说明链路长期有问题。jitter单位是 1/90000 秒换算成毫秒除以 90超过 30ms 基本就能感觉到卡顿。LSR和DLSR用来算 RTT需要结合自己发出去的 SR 时间戳基础版可以先不看。参数上RR 的发送周期建议 5 秒一次太频繁浪费带宽太稀疏看不出趋势。发送目标端口是 SETUP 应答里server_port的奇数端口RTCP 端口别发到偶数端口去。如果服务端不回 RR检查 Transport 头里有没有声明rtcp有些设备要求显式写RTP/AVP;unicast;client_port8000-8001才认。我自己的习惯是任何一路新接入的流先跑 30 秒看 RR 的frac和jitter曲线平稳了再接业务逻辑。有一次现场反馈“画面偶尔卡”日志里 frames 正常最后就是靠 RR 的 jitter 从 5ms 飙到 80ms 定位到交换机端口协商问题——这种问题光看应用层日志永远查不出来。从那以后我每次接新流都强制走一遍 RR 统计哪怕业务不需要也留个排查入口。希望这份源码和上面的拆解能帮你少走几天弯路。本文还有配套的精品资源点击获取