简介一份专注RTSP服务器实现的C语言源码包面向具备一定Socket编程基础的流媒体开发者、网络服务开发者及C语言进阶读者可帮助系统理解RTSP协议在服务端的完整落地与代码组织方式。资源共414个文件以167个C源码、45个头文件作为阅读主体另含15个Makefile构建脚本、15个静态库以及编译产生的目标文件等整包仅1.26MB目录结构清晰便于按模块定位初始化、请求处理、媒体传输等逻辑。包内实现覆盖服务器初始化、RTSP请求处理DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN、SDP生成与响应、RTP/RTCP媒体数据封装与发送、会话状态机管理、多线程并发处理、锁与条件变量同步、错误处理与网络异常应对等关键部分从rtsp.a、rtp.a、rtcp.a、eventloop.a等静态库划分可快速把握各模块职责并附Makefile和调试提示支持从协议原理、状态迁移到并发同步、二次开发的完整学习。已有1059人学习下载适合希望在RTSP与并发网络服务方向深入实践并提升C代码阅读能力的开发者参考。1. 为什么我选择啃一份C写的RTSP Server源码干流媒体这行的人早晚得跟RTSP打交道。尤其是做安防监控、嵌入式设备接入、视频网关这类项目的海康大华的摄像头、各种网络摄像机对外输出的基本上都是RTSP流。你手里如果有一套自己的RTSP Server源码就相当于掌握了一个能跟市面上绝大多数设备对话的底层工具。我最初接触RTSP Server是想给一套嵌入式设备加一个本地预览功能。设备端只有一路H.264编码后的裸流需要把它变成一个局域网内可以访问的URL让PC端播放器或者手机App能直接拉流。当时第一个念头是用现成的库openRTSP、live555这些确实能跑但问题也很明显裁剪起来费劲想加个自定义的鉴权逻辑得在上千行C里找钩子更重要的是我对RTSP协议本身的理解一直是“会用但说不清里面的机制”。后来拿到了一份C语言实现的rtsp_server源码干脆从底层过了一遍整体通透了很多。这篇内容不打算做那种逐行注释式的讲解而是按照我阅读和二次开发这份源码时的思路来拆先搞清楚一个RTSP Server要在网络上做哪些事再对照源码看它怎么用C语言把这件事办成的最后说一下实际开发中容易踩的坑以及我在里面做的几处改造。适合谁看打算深入RTSP协议的嵌入式开发者、做音视频服务的后端人员以及那些正在纠结“要不要自己写RTSP Server”的朋友。如果只是调个接口就完事的应用层开发这篇对你来说可能偏底层了。2. 拿到源码先别急着看代码先摸清楚RTSP Server的网络本质很多人在源码面前一头雾水原因不是代码难而是脑子里没有一张“RTSP Server到底在网络上做了哪几件事”的地图。我建议你先放下代码画出这样一条链路客户端(播放器/VLC/FFmpeg) ↓ RTSP信令(TCP 554端口) RTSP Server ├── 解析请求OPTIONS、DESCRIBE、SETUP、PLAY ├── 回响应描述会话能力、传输参数 └── 推送流RTP/RTCP(UDP或TCP)2.1 RTSP协议本身是个“遥控器”不是“水管”RTSP和RTP/RTCP的分工最容易混淆。RTSPReal Time Streaming Protocol的本质是控制协议——它负责协商要播放什么、用什么格式、走什么传输通道、开始播还是暂停播。而真正的视频数据是RTP包在送。你可以把RTSP想象成电视遥控器RTP才是电视信号本身。这个区分特别重要。因为看源码的时候你会发现RTSP相关的代码都在处理字符串、状态机、连接管理这些“非音视频”的逻辑而RTP打包模块才是在切实际的H.264帧。如果大脑里没有一个清晰的分工图你很容易被信令那部分代码带跑偏忘了Server真正的主业是“把一帧帧视频数据按时发出去”。2.2 一份RTSP Server源码的骨架会话、连接、媒体通道抛开协议细节单看C语言的程序结构RTSP Server要管理的东西就三类TCP连接与客户端会话每个客户端连上来要给它维护一个会话ID、状态init → ready → playing、请求序列号等。媒体通道一路视频流对应多个音频或视频流每个流需要一个独立的RTP端口对或TCP复用通道。数据源编码器输出的裸码流可能来自硬件编码器、文件、或另一个网络流。我拿到这份源码后发现它虽然只有几千行但这三块是齐全的。它的目录结构大概是rtsp_server/ ├── main.c # 主循环socket监听 ├── rtsp_parse.c # RTSP请求解析 ├── rtsp_response.c # 响应生成 ├── rtsp_session.c # 会话状态管理 ├── rtp_pack.c # RTP打包H.264 ├── media_source.c # 媒体源抽象层 └── Makefile这份结构非常典型读完它再去啃live555那种巨型库接受度高很多。2.3 先从main.c开始看Server的生命周期读C项目的源码我永远建议从main函数切入。main里面往往藏着这个程序的“生命周期模型”int main(int argc, char **argv) { // 1. 初始化配置 // 2. 绑定端口创建监听socket // 3. 进入主循环 // - accept新连接 // - 用select/poll处理已有连接的可读事件 // - 调用rtsp_handle_request() return 0; }这份源码用的是比较传统的select模型。为什么选择select而不是epoll原因很简单——目标平台可能是低配的嵌入式板子select足够应对少量并发监控场景下同时预览的客户端通常不超过四五个而且移植性极好别小看这点在嵌入式里扯上epoll反而绑手绑脚。3. RTSP交互背后的C语言核心逻辑状态机与字符串协议解析RTSP在协议层面上就是一个“文本协议”——所有信令请求都是ASCII字符串格式类似HTTP。这也决定了服务端处理请求的C代码本质上是在做“读一行字符串 → 解析方法 → 按状态机跳转 → 组装响应”。3.1 请求解析C字符串函数顺手但得小心这份源码里对RTSP请求的解析就是一套精简的字符串解析流程// 伪代码反映解析思路 rtsp_request_t req; parse_rtsp_line(buffer, req.method, req.url, req.version); while (parse_header_line(buffer, key, value)) { if (strcasecmp(key, CSeq) 0) { req.cseq atoi(value); } else if (strcasecmp(key, Session) 0) { strncpy(req.session_id, value, sizeof(req.session_id) - 1); } }C语言没有现成的HTTP解析库加持所以你会看到大量的strstr、strtok、sscanf、strcasecmp调用。读这种代码的时候我一直提醒自己这里的核心不是字符串函数本身而是对RTSP字段的理解。比如CSeq是客户端用来匹配请求和响应的序号这个字段在多人拉流调试时特别关键——响应里的CSeq必须和请求一致否则客户端会直接丢弃响应。实际用的时候strtok这类函数要特别当心线程安全和可重入问题。源码里有些地方用strtok_r这是正确的做法如果看到裸的strtok在后续改造时要替换掉。3.2 回响应的组装逻辑SDP是RTSP世界里最容易被小看的文本看完请求解析再看响应生成。RTSP Server最复杂的响应不是PLAY/PAUSE这些控制类响应而是DESCRIBE阶段返回的SDP文本。SDPSession Description Protocol是文本描述里面要标明流有几路、编码格式是什么、参数是多少、时钟频率是多少等。播放器就是靠这份SDP来决定后续怎么解码、怎么播放。我这份源码里的SDP组装代码大致长这样void sdp_generate(char *sdp, int size, media_source_t *src) { int n snprintf(sdp, size, v0\r\n o- %ld %ld IN IP4 %s\r\n s%s\r\n cIN IP4 0.0.0.0\r\n t0 0\r\n mvideo %d RTP/AVP 96\r\n artpmap:96 H264/90000\r\n afmtp:96 packetization-mode1;profile-level-id%X\r\n, timestamp, timestamp, local_ip, src-session_name, rtp_port, profile_level_id); }那段H264/90000是H.264在RTP传输时的时钟频率90kHz不是视频帧率——很多人第一次接触会误以为这是帧率其实它的意思是时间戳每秒增长90000个刻度。profile-level-id是从SPS里取出来的播放器靠它知道码流的档次和级别级。这个字段如果不填或填错VLC能放但一些严格的播放器会拒绝播放。3.3 状态机RTSP Server比HTTP Server多出来的复杂点HTTP是“请求-响应”一把梭RTSP则必须带状态。客户端必须先DESCRIBE再SETUP最后才能PLAY——顺序错了服务端要回454Session Not Found或者其他错误码。这份源码用了一个极简的状态字段来做这件事typedef enum { RTSP_STATE_INIT 0, RTSP_STATE_READY, RTSP_STATE_PLAYING } rtsp_state_t;每次处理请求之前先根据当前状态做一个合法性校验。例如只有在READY状态才能接受PLAY请求只有在PLAYING状态下PAUSE和TEARDOWN才有意义。这段代码是RTSP Server的灵魂之一。我在改造的时候给它的状态机加了一个TIME_WAIT态作用是客户端崩溃后服务端能及时清理RTP发送线程。如果不加TCP连接已经断了RTP发送线程还傻乎乎地在往socket上写数据最终导致“僵尸客户端”占着带宽和内存不释放。4. RTP打包源码解析让H.264裸流变成能过网络的NALU流RTSP Server真正发力的是RTP打包这块。很多网上流传的代码库里信令部分都写得头头是道一进RTP打包就露馅——打包逻辑混乱、时间戳处理粗糙、H.264的分包没有按RFC 3984来。这份源码在RTP打包上做得比较规矩值得细说。4.1 H.264码流结构不懂NALU就完全看不懂RTP打包代码读RTP打包代码前提是先理解H.264裸流的组织方式。H.264码流由一个个NALUNetwork Abstraction Layer Unit组成每个NALU以起始码00 00 00 01或00 00 01开头。常见的NALU类型包括NALU头字节低5位类型作用1非IDR片普通视频帧切片5IDR片关键帧解码器从这里开始解6SEI辅助增强信息7SPS序列参数集8PPS图像参数集RTP打包要做的事情就是把这些NALU按照某种约定塞进RTP包。这份源码里RTP打包的主要流程是// 从输入缓冲区分割出NALU这里通过扫描起始码实现 static int find_nalu_start(uint8_t *buf, int len, int *nalu_size) { // 搜索 00 00 00 01 或 00 00 01 } // 将NALU打包为RTP包 static int rtp_pack_nalu(rtp_session_t *session, uint8_t *nalu, int nalu_len) { if (nalu_len MAX_RTP_PAYLOAD) { // 单包模式 rtp_send_single(session, nalu, nalu_len); } else { // FU-A分片模式 rtp_send_fragment(session, nalu, nalu_len); } }4.2 大小判断单包模式与FU-A分片模式每个RTP包的最大负载长度一般是1400字节左右因为底层MTU通常是1500减去IP头20字节和UDP头8字节再留点余量。当NALU超过这个长度时就必须用FU-A分片——把一个NALU拆成多个RTP包发送。我这份源码里的分片逻辑比较直白但很稳static void rtp_send_fragment(rtp_session_t *session, uint8_t *nalu, int nalu_len) { // NALU头 FU指示 uint8_t fu_indicator (nalu[0] 0xE0) | 28; // 28表示FU-A // FU头当前分片序号信息 uint8_t fu_header nalu[0] 0x1F; int offset 1; // 跳过NALU头 int remaining nalu_len - 1; int seq session-rtp_seq; while (remaining 0) { int this_len remaining MAX_RTP_PAYLOAD ? MAX_RTP_PAYLOAD : remaining; uint8_t pkt[MAX_RTP_PAYLOAD 2]; pkt[0] fu_indicator; pkt[1] fu_header; if (remaining nalu_len - 1) pkt[1] | 0x80; // Start位 if (this_len remaining) pkt[1] | 0x40; // End位 memcpy(pkt 2, nalu offset, this_len); rtp_send_packet(session, pkt, this_len 2, seq); offset this_len; remaining - this_len; } }这段代码的细节很关键。FU-A的Start和End位不是可有可无的解码器要靠它来判断分片边界。如果Start/End置位出错接收端的解码器会花屏甚至无法显示。我看过很多改版源码问题就出在this_len remaining的条件写成了this_len remaining看似差不多实际上在边界处理上会产生一个多余的零长度分片浪费流量还容易触发解码器bug。4.3 时间戳与序列号RTP传输的“心跳线”RTP包里两个最重要的字段是序列号sequence number和时间戳timestamp序列号每发送一个RTP包加1接收端靠它检测丢包、重排序。时间戳代表该包在当前码流中的播放时刻。这份源码把时间戳设计为session-rtp_timestamp (90000 / fps);意思是每个视频帧的时间戳按固定帧率递增。这个做法在恒定帧率场景下完全够用但如果是可变帧率就要使用编码器返回的pts。我在接入硬件编码器的时候不用这份源码里“按帧率推算”的逻辑而是直接从编码器的输出结构中取pts转换// 硬编码器一般给的是微秒或毫秒单位 uint32_t rtp_ts (uint32_t)(pts_us * 90); // 微秒转90kHz90kHz时间戳的换算原理是每秒有90000个时间戳单位1微秒对应0.09个单位。这么做的好处是时间戳严格跟着视频源走切片播放时音画同步不会乱。如果你发现VLC拉流播放很久之后画面正常但有微小的口型不对或快进感十有八九是时间戳推算和实际码流不一致。4.4 发送线程与缓冲区为什么一有延迟就锁死读取源码时你会发现RTP打包并不发生在信令处理线程里而是有一个独立的发送线程在跑static void *rtp_send_thread(void *arg) { while (!session-exit_flag) { // 从环形缓冲区取帧 frame_t *frame ring_buffer_pop(session-rb); if (frame) { // 拆NALU并打包发送 rtp_pack_frame(session, frame); } else { // 缓冲区空短暂休眠 usleep(2000); } } }从这里面你能看出一个典型的设计矛盾发送线程和信令线程共享同一个会话需要加锁但加锁又可能造成延迟和锁竞争。这份源码的做法是用环形缓冲区做生产消费解耦——视频源线程往缓冲区写RTP发送线程从缓冲区读两级之间没有信号量阻塞而是采用“空则轮询”的简单策略。这个设计我在实际测试中发现一个问题当缓冲区深度设置太大时画面延迟会肉眼可见地拉大。在局域网内测试时延迟1秒可能感觉不明显但做实时交互类的项目远程控制、在线驾驶就完全不同了。我把这份源码的环形缓冲区深度从默认的60帧调到了8帧之后延迟降到了接近200毫秒以内代价是在网络抖动时会丢帧但这个资源充足的情况下可以接受——监控场景看丢几帧比看半秒延迟要好得多。5. 坑与教训我在这份RTSP Server源码上踩过的坎源码读完了改造也做完了但过程中踩的坑比看懂的代码还多。挑几个有代表性的说希望后来者少走弯路。5.1 第一坑TCP连接断开后没有及时清理会话第一版改造时我只把注意力放在信令处理上忽略了TCP连接断开事件。后来测试发现鼠标点VLC的停止按钮服务端半天反应不过来再重新拉流时直接失败。排查下来的原因很简单RTSP的TEARDOWN请求在某些情况下不会发客户端直接断开TCP连接了。服务端没有监听socket的EOF事件导致对应的session和RTP发送线程永久存活。修复方案如下在select循环里检测recv返回0或ECONNRESET错误码立即销毁对应session。给session加上最后活跃时间在master线程中周期性清理超时会话超时阈值设为60秒。5.2 第二坑多路摄像头画面跳帧花屏最后定位到SPS/PPS没有周期性插入做IPC接入时画面花屏或跳帧的情况经常出现。我第一反应是RTP打包问题反复查FU-A分片都没找出问题。后来用Wireshark对比了VLC播放器和FFmpeg拉流时的SPS/PPS出现情况发现是SPS/PPS只在视频编码器输出的关键帧前携带一次而某些播放器在开始播放时如果没抓到这个起始时刻就会一直等待SPS/PPS导致画面出不来。修复方法是在RTSP Server内部维护一个SPS/PPS缓存每5秒或每遇到关键帧时先主动发一组包含SPS/PPS的RTP包再发IDR帧。这是H.264 RTP打包领域的经典做法很多开源Server也是这么干的。5.3 第三坑多线程共享一个全局rtp_seq莫名其妙丢包改造多路并发时发现一个低概率但很难缠的bug两路视频同时推流时偶尔出现某一路播放器收到乱序包。用gdb挂上后发现两个会话的rtp_seq和rtp_timestamp在内存中发生互相覆盖。原因是我在全局定义了一个rtp_session_t结构体而不是在每个媒体通道里各自维护一个。C语言里这类错误的排查往往不是靠眼睛看而是靠-fsanitizeaddress或者valgrind或者更简单粗暴地看结构体归属是否清晰——凡是多个实体的属性一律放进各自的实例别偷懒用全局变量。6. 我在这份源码上做的几处二次开发改造看完和踩完坑之后剩下的就是实际动手改代码。这里说几处我觉得比较有代表性的改动供同样在做RTSP Server二次开发的朋友参考。6.1 加入基本的鉴权机制原生源码完全没有鉴权概念拉到流就直接发。这在内网问题不大但如果在稍微大一点的网络环境里裸奔的RTSP端口很容易被扫描抓取。我参照RTSP RFC 2326里的基本认证加了一个简单的用户名密码校验客户端在OPTIONS或DESCRIBE请求中带上Authorization: Basic base64(user:pass)服务端解码后比对不对就回401并附带WWW-Authenticate: Basic realmrtsp。这个改造涉及的文件不多核心改动就两处请求解析里提取Authorization头响应处理里加401分支。做这种“网络协议字段级”的改动最能体会到原文案解析里字符串处理的功力。6.2 输出结构化日志替代printf原始的源码打印日志全靠printf格式杂乱线上定位问题极不方便。我把它重构成了三层日志体系LOG_ERR打印错误信息输出到stderr。LOG_WARN异常但不致命的信息如某个客户端非正常断开。LOG_INFO关键环节状态如“session created”、“RTP send thread started”、“client 192.168.1.5 PLAY request accepted”。结构化日志看起来是小事但在跑真实设备的时候价值巨大。比如排查“某个摄像头连上来就看不了”这种问题有了基于会话ID的关键日志可以一眼看出是在DESCRIBE阶段、SETUP阶段还是数据推送阶段出问题不用开着GDB一步步断点。6.3 对H.265的扩展原版只支持H.264。现在很多新摄像头已经能输出H.265码流RTSP Server如果不跟上就只能转码成本太高。改造要点是SDP里新增一个H265的rtpmap描述mvideo 0 RTP/AVP 98 artpmap:98 H265/90000RTP打包处H.265的NAL单元头结构和H.264不同需要按RFC 7798来处理。H.265的NALU头是2字节在分片的时候要处理的偏移和类型字段位置相应变化。这个改动比想象中简单但要特别注意H.265的VPS、SPS、PPS三种参数集都要在关键帧前发送这是H.264时代没有的新坑。改完后再通过Wireshark对比正常H.265 RTP流确认分片格式没问题。7. 从源码阅读到独立实现的路线参考很多朋友读完一份源码后最大的困惑是“读懂了但让我自己写还是写不出来”。这个问题我自己也经历过很多次。RTSP Server源码读完之后我建议你有条件的话按下面这个顺序试着独立写一版最小的RTSP Server先写通信令只用socket 字符串解析把OPTIONS、DESCRIBE、SETUP、PLAY四个方法的交互跑通用VLC能拉到一条测试视频。再接裸码流从文件里读H.264裸流可以直接找一段MP4解封装出的H264文件做RTP打包并发送。最后做多会话把单会话改造成多会话管理处理资源释放的问题。再进阶加音频、加RTCP SR报告用于音画同步和流量统计、加鉴权、加H.265。这样的顺序每一步的难度跨度都不大而且每一步完成之后都能用VLC或者FFmpeg实测验证。我自己是从第三步开始才真正“吃透”这份源码的因为多会话并发会逼着你把session生命周期、内存所有权这些底层问题想清楚。如果你正打算在自己的项目里引入或改造一个RTSP Server我的建议是不要急着复制大段代码先把sdp_generate、rtp_pack_nalu、session状态机这三个文件吃透它们基本决定了一个RTSP Server的可用性。然后再根据你的具体场景慢慢补鉴权、补并发控制、补日志。C语言写的RTSP Server代码量不大但网络编程、协议理解、并发模型、内存管理这些问题一个都躲不掉。折腾通了你的底层功底会上一个明显的台阶。本文还有配套的精品资源点击获取