简介这是一份面向嵌入式或网络开发者的RTSP客户端小型C工程核心价值在于用C代码演示实时流传输协议客户端如何与服务器建立会话、发送播放暂停停止等控制指令并通过实时传输协议与实时传输控制协议完成媒体数据的接收与反馈。压缩包共7个文件含3个头文件、3个C源文件和1个Makefile分别承担接口声明、RTSP/RTP/RTCP实现和项目编译便于在Linux环境快速构建。整个包仅19KB结构紧凑适合刚接触流媒体协议的开发者对照源码理解请求响应流程也可作为调试RTSP服务器的轻量级客户端。已有919人学习或下载说明其在RTSP入门和二次开发中具备参考价值。通过运行和修改这些测试例程可以直观看到DESCRIBE、SETUP、PLAY等请求的触发顺序并掌握SDP解析、时间戳同步、会话ID维护等容易出错的细节这些积累对理解监控、直播场景中的交互逻辑以及后续扩展鉴权、加密或移植到实际项目都很有帮助。1. 拿到这份 rtspclient 源码时我的第一反应是又要造轮子但翻完 RTSPClient.c 才发现它把 RTSP 客户端最关键的几条链路——OPTIONS/DESCRIBE/SETUP/PLAY 信令、RTP 收包、RTCP 回执——全部用纯 C 实现了压缩包里是 RTSPClient.c/h、rtp.c/h、rtcp.c/h 和一份 Makefile没有第三方依赖编出来就能当联调用的测试客户端。它适合拿 IP 摄像头或 RTSP 服务器做联调测试的开发也适合刚接触 RTSP 协议、想从源码看懂一次完整会话的初学者。我读这份代码花了一个晚上最大的感受是文件虽少但控制面和媒体面拆得比很多商业 SDK 还干净而且踩坑点全藏在那些不起眼的小字段里。接下来我按源码结构拆一遍把怎么跑、怎么改、哪里容易翻车都讲清楚。2. 项目结构与技术栈纯 C 实现Makefile 一键出二进制2.1 源码包文件清单五个源文件对应三层职责压缩包解开之后文件很少一眼能看完RTSPClient.c/h、rtp.c/h、rtcp.c/h外加一个 Makefile 和一个名为 rtspclient 的入口条目。这个入口就是测试例程的“壳”它调用 RTSPClient 暴露的接口把一次完整会话串起来Makefile 编出来的同名可执行文件就是它的产物。文件职责RTSPClient.h / RTSPClient.cRTSP 信令层TCP 连接、OPTIONS/DESCRIBE/SETUP/PLAY/PAUSE/TEARDOWN 构造与响应解析rtp.h / rtp.c媒体接收层RTP 头解析、序号连续性检查、时间戳与抖动处理rtcp.h / rtcp.c传输控制层组包发送 RTCP Receiver Report给服务器反馈丢包与抖动统计Makefile编译脚本产出 rtspclient 二进制rtspclient测试例程入口 / 编译产物用 URL 参数发起一次 RTSP 会话这个分层是照着协议来的RTSP 在 TCP 上走请求响应RTP/RTCP 在 UDP 上走媒体流控制面和媒体面互不干扰。读代码会发现RTSPClient.c 里几乎不碰 RTP 细节rtp.c/rtcp.c 里也基本不管信令职责分得很干净。这意味着后面想加认证、换传输模式只需要动对应的那一层不用把整个文件推倒重来。2.2 控制面与媒体面分离传输通道怎么建RTSP 默认跑在 TCP 554 端口控制命令都在这个连接上发是一问一答的模式靠 CSeq 对齐请求与响应。媒体数据则跑在 UDP 上客户端在 SETUP 阶段把自己绑定的本地端口写进 Transport 头服务器之后就往这两个端口推 RTP 和 RTCP。两个平面为什么必须分开因为 RTP 是持续到达的流不能跟着 RTSP 的请求响应节奏走而 RTSP 的暂停、停止、断连又需要一条独立于媒体流的控制通道。所以整个客户端的时间线是先建立 RTSP TCP 连接再做本地 UDP 端口绑定然后 SETUP 告诉服务器往哪推流最后 PLAY 之后主循环收 RTP、周期发 RTCP。文件虽然少但这个控制面/媒体面的划分和主流 RTSP 客户端的做法是一致的。这块理解到位了第 4 章看 rtp.c 和 rtcp.c 就不会绕。2.3 编译与运行形态Makefile 写得非常朴素适合直接改来用CC gcc CFLAGS -Wall -g -O2 TARGET rtspclient OBJS RTSPClient.o rtp.o rtcp.o all: $(TARGET) $(TARGET): $(OBJS) $(CC) $(CFLAGS) -o $ $(OBJS) -lpthread RTSPClient.o: RTSPClient.c RTSPClient.h rtp.h rtcp.h rtp.o: rtp.c rtp.h rtcp.o: rtcp.c rtcp.h clean: rm -f $(OBJS) $(TARGET)注意这里有个细节链接时带了-lpthread说明测试入口或 RTSPClient 里起了线程常见做法是单独开一个线程定时发 RTCP RR避免和主收包循环互相阻塞。CFLAGS 里-g是方便带符号调试的-O2是发布用本地联调想保留完整变量信息就手动去掉-O2。编译产物用法大致是./rtspclient rtsp://服务器IP:554/stream1入口先解析 URL连 TCP 554随后按 OPTIONS → DESCRIBE → SETUP → PLAY 的顺序走一遍再进收包循环。入口里一般会有参数控制只跑某个方法这就是测试例程的价值每个步骤都能单独验证不像播放器把信令全部封装成黑匣子。3. RTSPClient.c 核心拆解信令请求、响应解析与 Session 状态机3.1 请求构造CSeq、User-Agent 与可选头RTSP 请求的骨架很简单方法加 URL 加协议版本再加一串头。但这个项目里把它收敛成了一个统一出口函数所有对外接口都走它维护起来非常省事。/* RTSPClient.c —— 所有 RTSP 请求的统一出口 */ static int rtsp_send_request(rtsp_client_t *c, const char *method, const char *uri, const char *extra) { char req[1024]; int len; len snprintf(req, sizeof(req), %s %s RTSP/1.0\r\n CSeq: %u\r\n User-Agent: rtspclient/1.0\r\n Session: %s\r\n %s \r\n, method, uri, c-cseq, c-session_id[0] ? c-session_id : , extra ? extra : ); if (send(c-sockfd, req, len, 0) 0) { perror(send); return -1; } return len; }关键参数有三个。CSeq是请求序号同一个 TCP 连接上必须逐次递增服务器靠它对齐响应重复使用或乱序会导致响应错位。Session头只在 SETUP 成功拿到 Session ID 之后才填之前填空字符串如果在没建立会话的请求里乱带 Session 值服务器会直接回 454 Session Not Found。extra是个可选的原始头字符串SETUP 时往里塞 TransportPLAY 时往里塞 Range 和 Scale。这个函数还体现了一个工程习惯把公共头集中到一处协议升级只改这里。比如要加 Authorization 认证头在 snprintf 里插入一行即可不用每个方法各改一遍。3.2 响应解析状态码分支与 Session ID 提取有请求就有响应。RTSP 响应状态行是RTSP/1.0 200 OK这种格式后面跟若干 header空行结束。这套源码的解析写法很典型先读状态行拿状态码再逐行扫 header把 Session 值掏出来。/* 读取状态行并顺手抽走 Session 字段 */ static int rtsp_read_status(rtsp_client_t *c, int *code, char *session_out, int session_len) { char line[256]; if (rtsp_read_line(c, line, sizeof(line)) 0) return -1; sscanf(line, RTSP/1.0 %d, code); /* 继续读到空行结束找到 Session 就交给上层 */ while (rtsp_read_line(c, line, sizeof(line)) 0) { if (strncmp(line, Session:, 8) 0) { strncpy(session_out, line 8, session_len); /* 真实工程里这里不要 break要把 header 区读干净 */ break; } } return 0; }这里有个小坑找到 Session 就 break会把剩余 header 留在 TCP 缓冲区里。一次请求响应之间 header 不多看起来没事但假如服务器在同一个响应里带了 Content-Length 和主体DESCRIBE 返回的 SDP 就是这种中断读取会导致后续解析错位。我一般会改写成完整读到空行再决定要不要继续读 body。这算是测试例程和正式库之间最典型的一处差距二次开发时第一件事就是把这里补严。状态码分支方面源码对 200 直接往下走401 提示需要认证4xx 打日志后返回具体错误码。调试时最需要盯的是 454 和 461前者代表会话没建立或 Session 值错后者代表 Transport 头不合法原因基本都落在第 5 章的避坑清单里。3.3 完整会话OPTIONS → DESCRIBE → SETUP → PLAY把这一层串起来一次 RTSP 会话的标准流程长这样rtsp_open(c, rtsp://192.168.1.64:554/stream1); /* TCP 连 554 */ rtsp_options(c, url); /* 看服务器支持哪些方法 */ rtsp_describe(c, url, sdp); /* 拿 SDP解析出 track 与编码 */ rtp_bind(rtp, rtcp_port); /* 绑定本地 UDP 端口 */ rtsp_setup(c, track_url, transport); /* 传 Transport拿 Session ID */ rtsp_play(c, url); /* 服务器开始推 RTP */ rtp_loop(c); /* 收 RTP 周期发 RTCP RR */ rtsp_pause(c, url); rtsp_teardown(c, url);DESCRIBE 返回的 SDP 是最需要解析的一块内容m行决定媒体类型和端口acontrol:决定每个 track 的 URLartpmap:决定 payload type 和时钟频率。测试入口的做法是先整体存下 SDP然后用字符串查找把 control 抠出来拼 track URL。这个解析是信令环节里最容易写糙的地方遇到摄像头厂商在 control 里用相对 URL 而不是绝对 URL 时尤其容易翻车——拿相对路径去请求 track服务器回 404 属于常规操作。4. RTP/RTCP 媒体链路rtp.c 收包逻辑与 rtcp.c 回执计算4.1 rtp.c12 字节头解析与序号回绕处理SETUP 和 PLAY 成功之后服务器开始往客户端绑定的 UDP 端口推 RTP 包。rtp.c 的核心是先解析固定 12 字节头再做序号和载荷类型检查。typedef struct { uint32_t ssrc; /* 第一个包定下来之后校验是否一致 */ uint16_t max_seq; /* 当前收到的最大序号 */ uint32_t last_ts; /* 上一个 RTP 时间戳算抖动用 */ } rtp_rx_t; int rtp_parse_header(const uint8_t *pkt, int len, rtp_packet_t *p) { if (len 12) return -1; p-ptype pkt[1] 0x7f; /* 低 7 位是 payload type */ p-seq (pkt[2] 8) | pkt[3]; p-timestamp (pkt[4] 24) | (pkt[5] 16) | (pkt[6] 8) | pkt[7]; p-ssrc (pkt[8] 24) | (pkt[9] 16) | (pkt[10] 8) | pkt[11]; return 0; }头里最值得做文章的是序号。RTP 序号是 16 位无符号数回绕很快65535 就归零直接比较大小判断丢包会误判。合格的做法是把 16 位序号扩展成 24 或 32 位再比较当新序号比 max_seq 小一大截且差值不超过回绕窗口比如 32767就认为发生了回绕把高位加一。丢包、乱序的统计都在这层做后面 RTCP 的丢包率数据就是从这来的。时间戳这边同样有坑。视频流 RTP 时间戳通常按 90kHz 时钟走不是毫秒也不是帧号算播放进度、算抖动都必须按 90kHz 折算。rtp.c 里存 last_ts 就是为抖动准备的——RTP 抖动本质是到达间隔和发送间隔的差这个统计值会直接进 RTCP RR。只看不用的读者可能觉得这段多余但服务器侧的质量监控就是靠这些数字填错等于对端看到一堆乱码统计。4.2 rtcp.cReceiver Report 的 LSR/DLSR 计算RTCP 里客户端主要干一件事周期发 Receiver ReportPT201反馈丢包率、累积丢包、扩展序号、抖动和 RTT 相关时间戳。很多初级实现把包组好就发结果服务器侧 RTT 算出来是负值或几百秒问题基本都出在 LSR 和 DLSR 两个字段上。/* 组装 RTCP RR返回包长度 */ int rtcp_build_rr(uint8_t *buf, const rtcp_rr_ctx_t *ctx) { rtcp_rr_t *rr (rtcp_rr_t *)(buf 4); uint16_t len 6; /* 8 字节头 24 字节 RR 块按 4 字节单位 */ buf[0] 0x80; /* V2无 padding无 extension */ buf[1] 201; /* PT201: Receiver Report */ buf[2] (len 8) 0xff; buf[3] len 0xff; rr-ssrc ctx-our_ssrc; rr-fraction_lost ctx-fraction_lost; rr-cum_lost ctx-cum_lost; rr-ext_high_seq ctx-ext_high_seq; rr-jitter ctx-jitter; rr-lsr ctx-lsr; rr-dlsr ctx-dlsr; return 28; }两个字段的口诀LSR 是“收到服务器 SR 那一刻从包体里抄下来的 NTP 时间戳中段 32 位”DLSR 是“从收到那个 SR 到现在经过了多少个 1/65536 秒”。服务器侧算 RTT 用的是(当前时间 - LSR) - DLSR任何一个填错RTT 就不是正的。收到 SR 的解析代码里NTP 时间戳占 8 字节前 4 字节是秒、后 4 字节是小数位中间 32 位就是前 4 字节的低 16 位拼后 4 字节的高 16 位不少实现栽在取错位子上。字段含义常见错误fraction_lost上一区间丢包率0~255拿累计值直接塞没算区间差ext_high_seq扩展后的最高序号直接塞 16 位序号回绕后失真jitter到达抖动时间戳单位用毫秒当 90kHz 单位lsr最近一次 SR 的 NTP 中段 32 位抄错位或直接填 0dlsr距该 SR 的延迟1/65536 秒单位算错RTT 为负RTCP 发送周期一般跟着会话走5 秒一次是比较常见的保守值。这层做好服务器的质量监控面板才会显示正常曲线否则就是客户端这边收流收得好好的服务器那边却觉得你早就断线了。5. 避坑指南这套测试例程在真实服务器上最容易翻车的 4 个点5.1 recv 阻塞卡死PLAY 之后程序像失去响应现象PLAY 请求发出去日志停在 send 那一行程序半天不动连中断都不太灵。原因主循环里 recv 用的是阻塞 socket没有设超时。服务器从收到 PLAY 到开始推流中间可能隔几秒甚至更久鉴权、拉源、转码都在这一步发生客户端在等 UDP 数据时被永远堵住。解决给 socket 设 SO_RCVTIMEO超时 3 到 5 秒收不到 RTP 就走一次 RTCP 或信令心跳确认会话还活着。或者更稳妥一点主循环用 select/poll 带超时等到数据就 recv等不到就干别的。不少人把这个问题归为“玄学”其实抓一下包就能看到服务器根本还没发包纯粹是收包姿势不对。5.2 461 Unsupported TransportTransport 头缺端口参数现象DESCRIBE 成功SETUP 失败服务器回 461 Unsupported Transport。原因SETUP 请求里的 Transport 头只写了RTP/AVP/UDP;unicast没带 client_port或者端口号和本地实际绑定端口对不上。服务器不知道往哪推流直接拒绝。解决先 bind 本地 UDP 端口再把真实端口拼进 Transport 头Transport: RTP/AVP/UDP;unicast;client_port5004-5005。RTP 和 RTCP 是成对的相邻端口偶数给 RTP、奇数给 RTCP 是默认惯例别乱配。改完后 SETUP 响应里会返回服务器选中的 server_port这两个值要记下来打日志后面抓包过滤就靠它们。5.3 服务器开始乱回状态码CSeq 与 Session 管理不当现象前几个请求一切正常连发几次后服务器开始回 400或者响应和方法对不上号。原因CSeq 重复用了或者第一次 SETUP 之后取到的 Session 没保存后续 PLAY/PAUSE 请求带了空 Session 甚至乱填。每个 TCP 连接上的 RTSP 请求是串行一问一答CSeq 必须全局递增Session 必须从响应里解析出来并回填到后续请求头。解决把 CSeq 作为连接级计数发一个加一绝不重用Session 只在 SETUP 响应后填充一次之后所有请求都带上。排查时先在日志里把每一对的请求 CSeq 和响应 CSeq 打出来一眼就能看出谁错位。这块做好了就能避免那种“看着像网络问题实际是状态没管理好”的假故障。5.4 服务器侧丢包率 100%RTCP RR 里的时间戳回算错误现象RTP 收得飞起抓包里报文也正常但服务器管理页显示的丢包率是 100%RTT 是负数或几百秒。原因RTCP RR 里的 ext_high_seq 没做 16 位回绕扩展或者 LSR 取错了位。服务器算出来的“最高序号”比实际小一大截自然认为中间全丢了。解决把 RTP 序号扩展成 32 位再算 ext_high_seqLSR 严格从服务器发来的 SR 包里抄 NTP 中段 32 位DLSR 用 1/65536 秒为单位换算。改完可以用抓包工具对比服务器 SR 的 NTP 和你 RR 里的 LSR 应该能对上RR 里的 DLSR 和 RTT 都在合理范围内几十毫秒级。这一段算法不难错了极难排查属于典型的“看着是小字段逼疯调试人”的问题。6. 二次开发方案把 rtspclient 改成回调式测试框架6.1 三个值得下手的改造点第一把 rtp_loop 里的收包循环改成回调注册。现在的写法是收一个包就在本地打一行日志联调够用但想喂解码器或统计模块就得改主循环。注册一个on_rtp_packet(seq, ts, ptype, payload, len)回调之后主循环只负责收包和调用回调业务逻辑全部外置这是从“测试例程”走向“可复用客户端”最关键的一步。第二补 Digest 认证。不少摄像头在 DESCRIBE 时直接回 401响应头带WWW-Authenticate: Digest ...。改造点在 3.1 的 rtsp_send_request 里加一个 Authorization 注入收到 401 后用用户名、密码、nonce 计算摘要CSeq 加一重新发一遍请求。注意重放时 CSeq 必须递增否则服务器会把重放当成乱序请求处理。第三支持 TCP interleaved 模式。部分网络环境 UDP 被防火墙挡死需要把 Transport 头改成RTP/AVP/TCP;interleaved0-1让 RTP/RTCP 通过 RTSP 连接里的通道复用传输。这个改动会牵动 rtp.c 的收包来源和 RTSP 连接的读逻辑等于把控制面和媒体面重新合到一起改完整个客户端的适用面会大一圈。6.2 验证改动改完别急着上真机。先在本机起一个 RTSP 服务用抓包工具确认信令顺序是 OPTIONS → DESCRIBE → SETUP → PLAY再看 RTP 有没有按顺序到达。然后人为断流或重启服务验证超时重连路径——这是测试例程最薄弱的地方也是最值得补强的地方。我自己的习惯是每次改完都强制走一遍“正常会话 → 中途断流 → 重启服务 → 再次拉起”四步确认日志里没有错位的 CSeq 和异常的 RTCP 时间戳。这套动作帮我挡掉了不少低级回归希望帮到你。本文还有配套的精品资源点击获取