简介：RTSP客户端源码包基于C语言实现，面向需要学习RTSP协议或开发流媒体客户端的工程师，可帮助理解客户端如何与服务器交互、控制实时流的播放、暂停与停止。代码涵盖了RTSP会话与会话ID管理、OPTIONS/DESCRIBE/SETUP/PLAY等核心方法、SDP信息解析以及RTP/RTCP传输配合机制，并附Makefile提供简洁构建方式，便于快速验证和二次开发。压缩包共7个文件，包括3个C源文件、3个头文件和1个构建脚本，整体仅19KB，结构精简；头文件声明接口与数据结构，C文件实现具体控制逻辑，Makefile负责自动化编译，适合有C语言基础、希望深入网络流媒体协议栈的开发者阅读。目前已有919人学习，对于想要掌握RTSP客户端设计思路的工程师，可以对照源码研究连接初始化、控制请求与状态码处理、网络中断恢复策略及基于SSL/TLS的安全传输细节，是一份轻量但能覆盖主要RTSP交互环节的实用样本。
1. RTSPClient是什么：一坨能跑的拉流代码，为什么值得自己造
RTSPClient是live555里专门负责拉流的C++类，几乎所有用RTSP协议取流的开源方案底层都绕不过它。监控项目里常见的海康摄像头取流、小米摄像头取流，控制面走的都是同一套协议：客户端发OPTIONS/DESCRIBE/SETUP/PLAY四步握手，服务器把H264/H265码流通过RTP包推回来，RTSPClient就是把这四步握手和RTP接收封装好的现成实现。它解决的实际问题很直接：后端要接YOLO做目标检测、App要缓存录像、网页要转HLS，在这些下游动作之前，你得先有一个稳定拉流的客户端。这篇笔记会把live555编译、rtsp测试流验证、摄像头主码流子码流选择，以及断流花屏的排错顺序一次讲完。适合刚接触流媒体拉流、被摄像头私有SDK折腾过的开发者。
2. 先搞懂rtsp拉流协议：四步握手后，RTSPClient帮你接管了什么
2.1 RTSP协议的四步握手：OPTIONS/DESCRIBE/SETUP/PLAY
RTSP控制报文走TCP，默认端口554，报文格式和HTTP很像：请求行、若干头字段、空行、可选消息体。一次完整的播放会话固定是四步，少一步设备就直接给你4xx。
第一步OPTIONS，客户端问服务器支持哪些方法；第二步DESCRIBE带Accept头要SDP描述，SDP里写着流有几路、什么编码、RTP负载类型和端口号；第三步SETUP是真正的协商环节，客户端要告诉服务器自己从哪个端口收RTP包，服务器返回一个Session ID；第四步PLAY一发，RTP流就开始往客户端推了。底层的RTCP负责汇报收包统计和维持会话心跳，这部分默认被很多人忽略。
用openRTSP加-V参数，能直接看到这四步的原始报文：
C->S: OPTIONS rtsp://192.168.1.64:554/Streaming/Channels/101 RTSP/1.0 C->S: CSeq: 2 C->S: User-Agent: Lavf58.76.100 S->C: RTSP/1.0 200 OK S->C: CSeq: 2 S->C: Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER注意请求里有个CSeq字段，它是序号，每发一条请求都要递增，服务器响应里原样带回，客户端要对得上。自己拼socket写拉流工具时最容易漏的就是CSeq和Session这两个头——漏了或者对不上，海康这类设备直接回500，而且响应里不会告诉你到底是哪一个字段出错，排查起来全靠抓包比对。
2.2 为什么自己拼socket容易翻车，RTSPClient把黑匣子打开了
自己写RTSP握手最脏的三件事，我列一下，你照着做一遍就知道为什么我不推荐从零搞。
第一是摘要认证。现代摄像头默认开Digest认证，不是Basic那种直接base64，而是服务器先发一个nonce，客户端用MD5把用户名、密码、nonce、URI拼起来做哈希。拼错一个字段就是401，帧率一波动nonce还会换，你得跟着重算。第二是RTP端口协商。SDP里视频和音频各占一个m=行，SETUP阶段每个subsession会分别协商端口，用UDP拉流时端口选不好，很多摄像头直接把包丢到错误端口。第三是RTCP心跳。播放期间客户端要周期性回RTCP RR报文，不回的情况下，一部分NVR会在拉流几分钟后静默断开连接，外表看就是断流，但没有任何报错。
这三件事，RTSPClient正好都替你处理了。live555的RTSPClient把四步握手实现成了内部状态机，SDP解析交给自带库，RTP接收排序交给MediaSession和MediaSink，你真正需要写的只有帧到达后的回调。我见过有人不引入live555、用libcurl自己拼RTSP，两星期后回来改，问了下就是栽在摘要认证和RTCP心跳上。
2.3 RTSPClient和RTMP/HTTP-FLV的边界：拉流协议不能一套吃遍天
同样做流媒体，直播场景大量用RTMP而不是RTSP，原因在传输层。RTSP的媒体数据用RTP承载，RTP是实时传输协议，只保证次序不保证可靠，丢包了就丢，画面表现为花屏或卡帧。监控行业接受这个，因为摄像头要的是低延迟持续观看，而不是每一帧都必须完美。RTMP走TCP，丢包重传，延迟通常在1到3秒，适合直播推流，但不适合监控。
这里有一个选型经验：下游如果是AI分析，比如把监控视频拉流rtsp yolo做目标检测，RTSP的低延迟就非常友好；下游如果是网页播放，RTSPClient拉下来的流多半还要再封装成HTTP-FLV或HLS，层级一多延迟就上来了。所以动手前先想清楚终点是显示器、算法还是浏览器，再决定协议栈，能省掉后面一大半的折腾。
3. 上手跑通rtsp测试流：编译live555与最小拉流命令
3.1 编译RTSPClient依赖的live555：五分钟拿到openRTSP
live555是RTSPClient的宿主库，它自带一个叫openRTSP的命令行客户端，本质上就是对RTSPClient类的完整封装。先把它编译出来，后面写自己的客户端时可以直接对照它的行为。
# 去 live555.com 的 Download 页拿最新源码包，解压后进入目录 tar -xzf live555-latest.tar.gz cd live # 生成 Makefile 并编译，linux 环境用 Generic 配置基本不会出错 ./genMakefiles linux make -j$(nproc)编译时间通常在一两分钟以内。产物里有几个可执行文件，openRTSP在testProgs目录下。这里说明两个参数：genMakefiles后面的platform参数决定编译器还是交叉编译器，纯Linux桌面用linux；make的-j参数是并行核心数，不要大于CPU物理核心数，否则内存小一点的机器会卡死。如果编译过程中报“cannot find -lstdc++”，说明没装g++基础包，Ubuntu上执行apt install build-essential就能解决。
编译完成后，不要急着跑公网测试流，建议先在本机用gstreamer拉一路无障碍源。gstreamer自带rtsp服务器示例，一条命令就能起一个本地流：
# 用 gstreamer 在 8554 端口起一路测试视频 ./test-launch "( videotestsrc ! x264enc ! rtph264pay name=pay0 pt=96 )"终端会打印rtsp://127.0.0.1:8554/test，这就是你的本地rtsp测试流。用本地gstreamer服务器验证客户端逻辑，比依赖公网流稳定得多，也不会把生产摄像头的带宽占掉。
3.2 连接rtsp测试流：openRTSP参数逐项说明
先拿openRTSP连本地流，验证编译产物可用：
# -t 表示走 TCP 传输，-d 5 表示只收 5 秒，输出重定向到文件 ./testProgs/openRTSP -t -d 5 rtsp://127.0.0.1:8554/test > test.h264这里的三个参数在生产环境几乎天天用到。-t强制RTP over RTSP，把RTP数据并到TCP的RTSP连接里传，解决跨网NAT下UDP收不到包的问题，代价是延迟略高；-d 5限制接收时长，做连通性测试时防止进程一直不退；>重定向把H264裸流落盘。如果服务器是UDP优先，不加-t时openRTSP会自动选UDP，你可以对比两种方式下的丢包率和延迟差异。
命令跑完没有任何报错，并且test.h264文件有大小，说明拉流链路通了。用ffprobe确认一下流的真实参数：
ffprobe test.h264输出里能看到H.264、yuv420p、分辨率、帧率这些关键信息。这一步的意义在于确认SDP解析结果：如果文件里只有几十KB且ffprobe报“buffer underflow”，多半是接收时丢帧严重，这时要把-t以外的UDP缓冲参数调大再看。
3.3 读SDP：H264 profile和分辨率的出处
openRTSP加-V参数会在stderr打详细信息，其中有一段是DESCRIBE响应里的SDP，长得像这样：
v=0 o=- 1682977332 1 IN IP4 127.0.0.1 s=Session streamed by "liveMedia" m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 a=control:track1 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1重点是m=video这一行，后面跟着的0表示端口尚未协商，RTP/AVP告诉客户端用RTP承载，96是负载类型编号；a=rtpmap:96 H264/90000说明负载类型96对应H264编码，90000是RTP时间戳采样率；a=fmtp里如果出现sprop-parameter-sets，说明SPS/PPS直接写在了SDP里，后面收帧要用它初始化解码器；packetization-mode=1则指H264按非交错模式打包，每个RTP包一个NALU为主。
这些值不是给你看的。写RTSPClient的帧处理逻辑时，需要从SDP解析出编码类型、负载类型、时间戳频率，然后才能正确地把RTP负载还原成NAL单元。live555的MediaSession::initWithSDP会把这些字段解析到MediaSubsession里，你直接用subsession->rtpPayloadFormat()和subsession->videoWidth()这类接口就能拿到。很多新手在这步手写SDP解析，一个漏了分号就可能把整个会话带偏，用库的解析接口会省心很多。
4. 接摄像头实战：海康rtsp取流地址与主码流子码流怎么选
4.1 海康和大华摄像头rtsp取流地址的拼法
不同品牌的取流地址格式不同，但核心结构都一样：协议头加认证信息加设备ip，后面跟流通道路径。海康最典型，主码流和子码流用数字通道区分：
| 品牌 | 取流地址格式 | 说明 |
|---|---|---|
| 海康 | rtsp://用户名:密码@IP:554/Streaming/Channels/101 | 101主码流，102子码流 |
| 海康 | rtsp://用户名:密码@IP:554/Streaming/Channels/201 | 201第二通道主码流 |
| 大华 | rtsp://用户名:密码@IP:554/cam/realmonitor?channel=1&subtype=0 | subtype=0主码流，1子码流 |
| 小米 | rtsp://用户名:密码@IP:554/stream1 | 需在客户端开启RTSP功能 |
海康、大华的地址在官方文档和工程资料里都能查到，小米摄像头不是所有固件都有RTSP功能，开了以后地址格式各版本有差异，建议去路由器后台看设备ip再结合App里的固件说明确认。
这里要提醒两点：第一，URL里的用户名密码建议用urlencode编码，密码里只要出现@、?、&这类字符，不编码的话地址解析就会错乱；第二，很多摄像头默认不开RTSP，需要先在Web管理页面把“启用RTSP”打开，否则端口探测是通的，DESCRIBE却一直超时。
4.2 主码流和子码流：分辨率、码率、延迟怎么权衡
主码流是摄像头的主输出，分辨率高、码率高，目的是给本地录像或大屏显示提供高质量画面。子码流是次输出，分辨率低、码率低，主要给手机预览、多路轮巡这类低带宽场景。工程上最常见的错误是无论什么需求都拉主码流，结果一个200万像素的H264主码流动辄4到8Mbps，十个摄像头同时拉就占满了交换机带宽。
拉流前先问自己要干什么。如果下游是YOLO检测，目标框只需要能分辨人车级别，子码流720P一般就够，码率只有主码流的四分之一，GPU解码开销也小得多。如果下游要人脸识别，子码流画面细节不足，必须用主码流。如果你既要检测又要预览，标准做法是同一路摄像头同时拉两路：一路主码流给录像，一路子码流给检测，而不是反复切换同一路会话。
因为RTSP是时分复用协议，同一路播放会话不能同时给两个消费者，多进程各拉各的流才是工程常态。
4.3 把RTSPClient的帧喂给YOLO：常见桥接方案
live555的RTSPClient回调拿到的不是YUV或RGB帧，而是H264/H265的NAL单元，必须经过解码才能给YOLO用。最常见的落地架构是三层：RTSPClient拉流、ffmpeg或硬件解码器解出YUV、检测线程推理。帧到达回调一般长这样：
// DummySink::afterGettingFrame 是 RTSPClient 每收到一帧的入口 void afterGettingFrame(unsigned frameSize, unsigned numTruncatedBytes, struct timeval presentationTime, unsigned durationInMicroseconds) { // fReceiveBuffer 里是一个完整的 NALU，先把帧序号和时间戳记下来 naluSeq = rtpInfo->seqNum; timestamp = presentationTime; // 交给解码器解出 YUV，再转 RGB 送进环形队列给检测线程消费 int w = decoder->decode(fReceiveBuffer, frameSize, yuvBuffer); frameQueue.push(yuvBuffer, w); }回调里不能做同步推理，否则RTSPClient收包的循环会被卡住，UDP缓冲区一满就开始丢RTP包。常见做法是回调里只解析NALU并丢进一个有界环形队列，YOLO检测线程从队列里取帧做前处理、推理、后处理。队列深度建议控制在5到10帧：太浅会丢关键帧导致检测漏报，太深则画面延迟直线上升。
做完检测还要把结果叠加回画面时，注意RTSP拉流的帧时间戳不能直接当系统时间用，摄像头的时间戳是基于开机时间的，要换算成unix时间再做同步。这里我吃过亏：直接把RTP时间和系统时钟对齐，结果画面时间戳比实际时间慢了一个多小时，排查了半天发现是时区转换没做。
5. RTSPClient避坑指南：断流、花屏和OOM的排查顺序
5.1 现象：握手上去了，但一直收不到帧
现象：openRTSP或自己的客户端已经发出PLAY并收到200 OK，但afterGettingFrame一直不被调用，网络抓包能看到服务器在推RTP包，就是到不了应用层。
原因：最常见的是SETUP阶段传输方式协商失败。live555默认尝试UDP传输，但在NAT后面或者防火墙只放开TCP 554端口的场景，UDP回包根本到不了客户端。服务器视角是PKT已经发出，客户端视角是包永远没来。另一种情况是RTSPClient的CSeq在摘要认证重试后被重置，导致服务器认为序列号乱序，丢弃PLAY请求。
解决：优先强制走TCP隧道，即RTP over RTSP。openRTSP加-t，自定义客户端则要在SETUP阶段把RTP端口设为0，让服务器把RTP数据并到RTSP的TCP连接里用interleaved=0-1发送。这样单端口就能拉流，NAT和防火墙问题一起解决，代价是延迟比UDP模式高约20到50毫秒，一般场景可以接受。
5.2 现象：画面花屏和块状马赛克
现象：画面能出来，但不断出现大块色块，特别是画面剧烈变化时更明显，偶尔还会卡在上一个关键帧的残影上。
原因：RTP包在传输中丢失。UDP模式下丢包率高是常态，带宽不足、交换机缓冲小、Wi-Fi干扰都可能触发。丢包后解码器拿残破的P帧硬解，产生马赛克；如果丢的是关键帧，画面直接碎到下一个关键帧到来前都缓不过来。
解决：第一选择还是切TCP拉流，TCP不会丢包，只会推高延迟。如果必须用UDP（比如对延迟极其敏感的场合），要在RTSPClient的RTP接收侧检测序列号跳跃：RTP头里的sequence number每包加一，如果发现下一包序号跳了，说明丢包了，正确的策略是丢弃整个GOP，等下一个关键帧再恢复解码，而不是把缺块的P帧送进去解码。
5.3 现象：内存暴涨和延迟越拉越大
现象：程序刚启动时画面秒开，跑10分钟后延迟累加到几秒，同时内存占用直线上升，最后被系统杀掉。这在安卓端缓存rtsp流的场景特别常见。
原因：把RTSPClient收到的每一帧都先塞进无界队列，消费端解码或推理速度跟不上RTP到达速度，队列越积越长。这是典型的“生产大于消费”问题：网络输入速率是摄像头决定的，消费速率是CPU/GPU决定的，二者不匹配时无界缓冲就是内存炸弹。
解决：给缓冲加上限，满了就丢最旧的帧，保新鲜度而不是保完整。简单实现就是在回调里检查队列长度，超过阈值直接pop掉最早一帧再push新帧。这个策略对检测场景尤其重要：检测看的是“现在”的画面，迟到的帧没有任何价值，只会让延迟滚雪球。
5.4 现象：断网后重连失败，只能重启App
现象：Wi-Fi断开又恢复后，程序的RTSPClient一直卡在“连接中”状态，超时、重试、再超时循环几轮后彻底没反应，只能杀掉进程重启。
原因：断网的瞬间，RTSPClient所在的socket停在CLOSE_WAIT或TIME_WAIT，如果重连前没有释放旧的RTSPClient实例和它的RTP会话，内核里的文件描述符会一直累积。连续重试几次后fd耗尽，新连接连socket都创建不出来。
解决：重连前先做完整的teardown。先调teardownMediaSession发送TEARDOWN报文，再删除MediaSession和RTSPClient实例，设置socket为SO_REUSEADDR，最后等待1到2秒让内核清理TIME_WAIT，再发起下一次连接。如果设备地址变了（DHCP重分配），重连前还要重新解析IP，直接用旧IP连必然超时。
6. 进阶：RTSPClient抗造调优的最后三招
6.1 指数退避重连
直接写死固定间隔重连不靠谱：5秒一次，断网10分钟就得重试120次，日志刷屏，服务器还可能把频繁连接的IP封掉。我的习惯是初始1秒、每次翻倍、上限30秒，加一点随机抖动防抖：
int delay = 1; while (!connected) { if (tryConnect()) break; sleep(delay + random(0, 3)); delay = min(delay * 2, 30); }关键不是算法，而是重连成功后要把delay重置为1，不然每次断流都要等30秒恢复，人早就骂了。
6.2 缓冲水位与丢帧策略
很多人在“卡顿”和“延迟”之间作低价取舍，其实可以两个都要。给帧队列设高低水位：低于低水位正常入队；高于高水位时丢弃非关键帧，只保I帧；但水位的判定要基于解码时间而不是队列帧数。
6.3 倍速回放与最后的验证习惯
RTSP的PLAY请求可以用Scale头控制播放速度，海康NVR回放时快进4倍，拿到的就是这个机制。RTSPClient发PLAY时带上Scale: 4.0，服务器会按四倍速度推流，但不同设备对倍速支持的区间不同，超范围会直接拒播。验证客户端稳定性的最实用习惯不是看日志，而是抓包统计RTP序号连续率，连续一小时丢包率低于0.1%且无断流，这个客户端才算真正抗造。
这一路写下来，我最大的教训是：RTSPClient本身很稳，出问题的地方几乎都在上游网络和下游消费。先抓包，再调参数，别一上来就改代码。希望帮到你。
本文还有配套的精品资源，点击获取
