简介这是一份基于Linux平台的RTSP流媒体下载客户端C语言实现面向具备基础C语言和网络编程知识、希望深入了解RTSP/RTP协议的开发者。程序通过RTSP信令与指定服务器如live555完成会话协商随后接收RTP数据包并逐包解析提取媒体负载重组为TS格式文件最终产物可交由VLC播放器播放验证完整演示了从收流到落盘的全链路实现。压缩包仅5KB共4个文件含3个C源文件与1个头文件代码量适中结构清晰覆盖了RTSP客户端状态机、RTP解析逻辑和文件写入等核心模块方便读者对照学习或在此基础上扩展功能。由于包体极小十分适合作为教学示例或项目起步模板。目前已有203人学习使用对于想快速掌握RTSP客户端编写思路、或需要参考实际可运行代码的初学者和中级开发者具有很好的借鉴价值。1. 从一个TS流下载任务说起Linux下RTSP客户端到底在解什么拿到一个rtsp://地址想把它后面的多媒体文件下载到本地很多人第一反应是ffmpeg -i一把梭。但对于只装了一块网卡、没有图形界面的嵌入式 Linux 设备或者需要在下载过程中按帧粒度处理 RTP 数据的场景ffmpeg反而是最笨的选择——它把 RTP 解包、去抖动、时间戳重映射全部封装死了你根本看不到媒体流里发生了什么。这份资源里给的是另一个思路一个用 C 语言手写的 RTSP 客户端核心文件只有rtspclient_v1.0.c、rtsp.h、rtsp.c和testrtsp.c。它做两件事先用 RTSP 信令跟服务器协商媒体格式然后被动接收 RTP 数据包去掉 12 字节的 RTP 头把净荷按顺序写进文件。只要服务器是 live555 这类标准实现写出来的文件就是 VLC 能直接播的 TS 流。适合谁正在折腾 RTSP 协议本身、想搞懂 SDP 会话描述和 RTP 封装关系的人或者是在交叉编译环境里需要一个无依赖下载器的人。2. RTSP 信令与 RTP 解包live555 之外的 C 实现核心2.1 RTSP 状态机OPTIONS 到 PLAY 的四步握手RTSP 会话看起来复杂实际必要信令就四条链OPTIONS发现能力DESCRIBE拿 SDPSETUP建立传输通道PLAY触发数据流。这个客户端里没有像 live555 那样把状态机做成一整套类继承体系而是用一个RtspClient结构体保存会话状态每个信令函数只做一次 socket 收发和响应解析。int rtsp_send_request(int fd, const char *method, const char *url, const char *session, const char *extra) { char buf[1024]; snprintf(buf, sizeof(buf), %s %s RTSP/1.0\r\nCSeq: %d\r\n, method, url, cseq_counter); if (session) snprintf(buf strlen(buf), sizeof(buf) - strlen(buf), Session: %s\r\n, session); if (extra) snprintf(buf strlen(buf), sizeof(buf) - strlen(buf), %s\r\n, extra); strcat(buf, \r\n); return send(fd, buf, strlen(buf), 0); }这段代码把 RTSP 请求拼装逻辑收敛到一个函数里。CSeq每个请求递增是服务器做请求响应对齐的关键漏掉它会直接导致PAUSE或TEARDOWN时服务器返回 500。Session头只在SETUP之后存在所以外部调用时从响应里解析出来再回传。extra参数用来塞Transport、Range这类非固定字段。2.2 SDP 解析从 DESCRIBE 响应里抠出 TS 载荷类型DESCRIBE 响应体是 SDP 文本最关键的是m行媒体描述和artpmap动态载荷类型映射。对 MPEG-TS 来说通常看到的是artpmap:33 MP2T/90000也就是说 RTP 载荷类型 33 代表 MPEG-TS时钟频率 90000 Hz。有些服务器会用 96 或其他动态值所以不能硬编码。// 从 SDP 中解析 rtpmap找到 MP2T 对应的 payload type int sdp_find_ts_payload(const char *sdp) { const char *p sdp; while ((p strstr(p, artpmap:)) ! NULL) { int pt; char encoding[32] {0}; if (sscanf(p, artpmap:%d %31s, pt, encoding) 2) { if (strncmp(encoding, MP2T, 4) 0) { return pt; } } p 9; } return -1; }这里用strstr循环扫描每一处artpmap:而不是逐行拆分因为 SDP 的行尾可能是\r\n、\n或\r逐行处理要额外容错。sscanf直接抽取载荷类型和编码名匹配到MP2T就返回。拿到这个值后接收线程才能判断哪些 RTP 包属于媒体流哪些是 FEC 或冗余信道。2.3 传输模式选型为什么选 UDP 而不选 TCPlive555 服务器默认支持Transport: RTP/AVP/UDP客户端需要指定客户端端口对。这个实现里用了两个连续的 UDP 端口偶数放 RTP奇数放 RTCP。注意 RTCP 端口不一定要真的去收但服务器会往它发 Sender Report如果不 bind 对应端口服务器可能出现setsockopt(IP_ADD_MEMBERSHIP)之外的异常行为。表四种 Transport 模式对比模式端口协商适用场景此客户端RTP/AVP/UDP客户端指定端口对局域网低延迟支持RTP/AVP/TCP复用 RTSP 连接防火墙穿透未实现RTP/AVP/UDP multicast服务器指定多播组多人直播未实现RTP/AVP/TCP interleaved信令与数据混流代理穿透未实现纯 UDP 模式下数据包到达时间不保证有序所以接收线程要做两件事丢弃乱序包对 TS 文件下载可以接受以及处理 RTP 时间戳回绕。90000 Hz 时钟下32 位时间戳约 13.25 小时回绕一次短文件不用管长文件必须在写入时做 unwrap否则超过 2^32 后时间戳突然变小程序会误判为新的一帧。3. rtspclient_v1.0.c 代码拆解完整下载流程实现3.1 主流程从 URL 解析到文件落盘的七步整个客户端的主函数逻辑比 many 论文题更直白解析 URL、连接 TCP 信令、发 DESCRIBE、解析 SDP、SETUP、PLAY、循环 recvfrom 保存文件。关键在第七步的接收循环里要用select做超时检测避免服务器不发数据时程序永久阻塞。// 接收循环读取 UDP 数据过滤非目标 payload type写入文件 while (1) { fd_set rset; FD_ZERO(rset); FD_SET(rtp_sock, rset); struct timeval tv {5, 0}; // 5 秒等待 int ret select(rtp_sock 1, rset, NULL, NULL, tv); if (ret 0) break; // 超时退出 struct sockaddr_in from; socklen_t fromlen sizeof(from); int n recvfrom(rtp_sock, buf, sizeof(buf), 0, (struct sockaddr *)from, fromlen); if (n 12) continue; unsigned int pt buf[1] 0x7F; if (pt ! ts_payload_type) continue; uint16_t seq (buf[2] 8) | buf[3]; // 简化不考虑乱序直接接在文件末尾 fwrite(buf 12, 1, n - 12, outfile); }select的超时设了 5 秒这是「下载器」而不是「播放器」的特性——播放器需要盯着时间戳播放下载器只要在连续 5 秒没有新包时认为流结束即可。buf[1] 0x7F去掉 RTP 头的 M 标记位和扩展位取出 payload type第 3 字节第 4 字节是序号这里只做示意严格实现需记录上一序号以检测丢包。fwrite(buf 12, 1, n - 12, outfile)跳过 RTP 固定头注意如果 RTP 头里有 CSRC 或扩展头X 位置位偏移就不止 12 字节从第 0 字节解析buf[0] 0x0F得到 CSRC 个数判断buf[4] 4是否置位扩展头。3.2 SETUP 请求里的端口绑定细节信令 socket 和媒体 socket 必须是两个独立的 fd。rtsp.c里rtsp_setup函数负责创建 UDP 端口对并组装 Transport 头int rtsp_setup(int rtsp_fd, const char *url, const char *session, int rtp_port, int rtcp_port) { char transport[128]; snprintf(transport, sizeof(transport), Transport: RTP/AVP/UDP;unicast;client_port%d-%d, rtp_port, rtcp_port); char resp[4096]; rtsp_send_request(rtsp_fd, SETUP, url, session, transport); // 忽略后续实现重点是从响应中提取 Server 和 Session }client_port是客户端自己的端口服务器会往这些端口推流。端口绑定有个常见坑如果系统有防火墙策略随机选端口可能被挡最好在配置里允许指定端口范围。另外recvfrom要 bind 到正确的本地 IP不能 bindINADDR_ANY否则多网卡机器上服务器回包可能从另一个 IP 进来导致收不到。3.3 PLAY 与 Range 参数分段下载的起点PLAY请求可以带Range: npt0.000-表示从开头播到结束。如果想做分段续传改这个头就行。但 live555 对Range的处理依赖于底层 media source 是否支持 seekTS 文件源的seekable标志位通常为 true所以可以按秒区间下载。char range[64]; snprintf(range, sizeof(range), Range: npt%.3f-%.3f, start, end); rtsp_send_request(rtsp_fd, PLAY, url, session, range);这里用%.3f精确到毫秒npt 时间基是秒。如果服务器返回454 Session Not Found八成是Session头没回传或者CSeq不连续。把每次请求的CSeq和响应里的CSeq打日志能快速定位。4. 播放器兼容与 live555 服务器联调从 VLC 验证到服务器配置4.1 快速搭一个 live555 测试服务器手上没有现成 RTSP 服务器时用 live555 自带工具 30 秒就能起一个。前提是机器上有源码并编译了testOnDemandRTSPServer下面以 Ubuntu 为例# 编译 live555缺省安装到 /usr/local ./genMakefiles linux make -j4 cd testProgs # 启动服务器媒体文件放在当前目录 ./testOnDemandRTSPServer 8554 # 默认 URL 形如 rtsp://localhost:8554/文件名运行后可以用vlc rtsp://localhost:8554/test.ts验证服务器本身是否工作。注意testOnDemandRTSPServer默认对 TS 文件使用MPEG2TransportStreamFromESS它把 TS 文件完整封装为 MPEG2TS RTP payload正好匹配客户端里的MP2T解析逻辑。如果用别的文件格式比如 MP4它会走H264VideoRTPSink之类的封装那么 RTP 负载就不是完整的 TS 包这个客户端的fwrite直接落盘写出的文件大概率不能播。表live555 常见媒体源与 RTP payload 对应关系媒体类型live555 Sink 类RTP payload type本客户端能否直接落盘MPEG-TS (.ts)MPEG2TransportStreamFramer33 (MP2T)能H.264 (.mp4/.h264)H264VideoRTPSink96 (动态)不能需解 RTP 分片MPEG-4 AudioMPEG4GenericRTPSink96 (动态)不能MPEG PS (.mpg)MPEG1or2VideoRTPSink32 (MP2T?)可能打散4.2 VLC 验证下载文件完整性的三板斧下载完成后直接用 VLC 打开有时不行原因可能是文件本身没写完或 TS 结束不完整。我的验证顺序是先看文件大小是否接近源文件然后ffprobe看时长最后 VLC 打开跳转到中段播放。ffprobe -v error -show_format -show_streams output.ts | grep -E duration|codec_name如果duration是 N/A大概率文件从中间被截断或者 RTP 包序号跳跃太严重。更严格的做法是抓原始服务器的文件大小做对比因为 TS 流是恒定速率码率固定文件大小除以码率可以反推实际时长和Range请求的区间长度对不上就有问题。4.3 联调时最容易忽略的 SSRC 校验RTP 包第 8 到 12 字节是 SSRC同步源标识符同一个 RTSP 会话中所有 RTP 包的 SSRC 必须一致。如果在接收端打日志发现 SSRC 中途改变通常是 live555 发了RTCP BYE后重新开了新的 RTP 会话这时候客户端如果没有处理 RTCP 的逻辑就会持续收新流但文件里出现大量垃圾数据。一个粗鲁但有效的做法记录第一个包的 SSRC后续包 SSRC 不一致就断开重连。代码里只需在接收循环加几行uint32_t ssrc (buf[8] 24) | (buf[9] 16) | (buf[10] 8) | buf[11]; if (first_ssrc 0) first_ssrc ssrc; else if (ssrc ! first_ssrc) { printf(SSRC changed, abort\n); break; }这个校验对直播流尤其重要因为服务器可能做负载均衡切换不同物理机出来的 SSRC 不同。文件下载场景里 SSRC 变化通常意味着服务器异常直接退出比硬写垃圾文件更合理。5. 从 rtsp.c 到 testrtsp.c 的进阶技巧抓包对比与四个典型坑5.1 用 tcpdump 对比信令与数据的时序把网络抓包和程序日志对照着看能发现一般调试发现不了的问题。比如抓包时重点看SETUP响应里的Transport头服务器返回的实际端口可能和你请求的不同如果服务器回server_port10000-10001而你绑定的是 20000-20001那么数据会从 10000 进来。客户端必须使用响应里server_port字段的值来构造过滤规则。tcpdump -i eth0 -nn -vv -A tcp port 8554 or udp portrange 20000-20001-vv会打印 RTSP 响应文本-A把 TCP 内容以 ASCII 显示。实际操作中我通常先信令转储再媒体转储分两次抓因为 UDP 数据量极大混在一起 filter 太粗暴。观察到SETUP响应后 200ms 内服务器才开始发 RTP说明服务器做了资源预分配如果延迟超过 1 秒检查服务器日志是否在等待 RTCP 的 RR。5.2 四个典型坑与对策第一个坑recvfrom每次都返回 1436 字节这不是 bug。RTP over UDP 的 MTU 限制常见 MTU 1500 减去 IP 头 20、UDP 头 8payload 最多 1472RTP 头占 12所以净荷约 1436TS 包本身 188 字节所以每 7-8 个 RTP 包就能凑一个完整的 TS 包但这里直接连接存储而不拼包靠播放器自身处理 TS 包边界也能播因为 TS 包有 sync byte 0x47播放器可以自行对齐。第二个坑服务器在 PLAY 后立即发送 UDP 数据而客户端还没来得及进入recvfrom循环导致前面的包丢失。对策是 PLAY 请求发出后不要做任何耗时的文件打开或日志准备直接进入接收循环。第三个坑fwrite缓冲问题。默认 stdio 缓冲是 4KB退出前没fflush或fclose最后几百字节没落盘。这个坑看起来低级但多线程环境里文件句柄共享时很容易被忽略。第四个坑时间戳回绕导致播放器快进失效。下载的文件本身没问题但 VLC 播放进度条拖动不准确。解决方式是记录第一个 RTP 时间戳后续包写入时不改文件内容而是在文件名里记录起始和结束 npt 时间需要精确裁剪时用 ffmpeg 重新 mux 一次。严格的做法是让下载器输出完整原始 TS所以这里的取舍是时间戳回绕不处理也能播放处理反而要破坏原始流因此留给播放器纠错是正解。5.3 一个 20 行脚本来验证下载速度与丢包率直接改rtspclient_v1.0.c太麻烦可以用一个辅助脚本配合tcpdump统计丢包率。核心思路是统计收到的 RTP 包序号缺的序号就是丢包。sudo tcpdump -i eth0 udp and port 20000-20001 -tt -l | awk {print $NF} | \ awk BEGIN{last-1; lost0; total0} { seq strtonum($0); total; if (last ! -1 seq ! last1 seq last) { lost seq - last - 1; } last seq; if (seq last) { printf 回绕或乱序\n; } } END { printf 总包数:%d 丢包数:%d 丢包率:%.2f%%\n, total, lost, lost*100/total }这个脚本用tcpdump -tt -l输出每包时间戳和 IP 长度awk取最后一列拿到的其实是包长度而非序号实际用时需要先抓包到 pcap 再用 tshark 过滤。思路说明白RTP 序号是判断网络健康度的唯一可靠指标。如果你想在客户端程序内做这个统计在接收循环里维护一个last_seq发现seq ! last_seq 1且序号差值在合理范围内就记录丢包数这个数值能直接决定下载出的文件是否有局部花屏。本文还有配套的精品资源点击获取