RTSP服务器源码实战：C语言实现协议状态机与RTP打包

简介这是一份RTSP服务器C语言实现源码及配套分析资料适合网络编程初学者、流媒体开发者以及希望深入理解RTSP协议原理的工程师。资源共包含414个文件以167个C源码文件、45个头文件为主辅以Makefile、编译生成的库文件与目标文件等整体约1.26MB结构紧凑便于对照学习协议实现与工程组织。目前已有1059人浏览学习。资料完整梳理了RTSP基础、会话管理、请求处理、RTP/RTCP传输及多线程同步等关键模块配合源码注释可帮助读者掌握服务器初始化、DESCRIBE/SETUP/PLAY等请求流程并理解SDP生成与状态机管理思路适合作为网络服务开发的实战参考。 接触过音视频传输的朋友应该对RTSP不陌生。这个协议从诞生到现在一直是IP摄像头、流媒体服务器、安防平台这些领域的事实标准。我之前因为项目需要在嵌入式板子上用C语言从头写过一版RTSP服务器也仔细读过live555、GStreamer里rtspbin的实现思路这里把源码层面的关键设计、协议状态机的处理、还有那些文档里不会写的坑一次性讲清楚。这篇文章适合正在看RTSP相关源码的人也适合准备自己动手实现一个轻量级RTSP服务的开发者。1. RTSP协议核心源码落地前必须搞懂的三个概念RTSPReal Time Streaming Protocol本身并不传输媒体数据它更像是一个“流媒体会话的遥控器”。源码里所有逻辑归根结底都围绕三个概念展开URL会话管理、状态机流转、SDP媒体协商。不管你读的是live555还是自己写的代码这三个点贯穿始终。1.1 URL定位与会话管理RTSP的请求行长这样DESCRIBE rtsp://192.168.1.10:554/live/ch01 RTSP/1.0。这个URL不是随便写的它在源码里会被解析成两部分服务器IP和端口以及媒体路径。比如/live/ch01可能对应一个H.264摄像头通道也可能对应一个本地文件。在C语言实现里常见做法是用一个结构体维护会话列表。参考live555的ServerMediaSession它本质是一个双向链表节点字段大概有sessionId服务端生成的唯一标识客户端后续请求都带着它媒体路径streamName对应URL里的路径部分传输模式TCP还是UDP单播还是组播SDP描述指针等DESCRIBE请求来了直接序列化返回引用计数多个客户端看同一路流时基础流对象会被共享源码里比较关键的是sessionId的生成策略。并发高的时候递增数字很容易撞车我一般用时间戳加随机数拼一个十六进制字符串再加一个全局自增序列做保底这样既不会重复也方便日志里排查是哪一路会话。live555里用的是随机数加地址组合效果类似。1.2 状态机每个请求都在推动状态流转RTSP的状态机看起来简单但源码里容易写得特别散因为每个方法OPTIONS、DESCRIBE、SETUP、PLAY等都在改状态。最核心的流转路径是初始化客户端发OPTIONS探路服务器回支持哪些方法DESCRIBE服务器返回SDP描述媒体格式、编码、端口信息SETUP指定传输方式TCP/UDP服务器分配RTP/RTCP端口建立传输通道PLAY开始推流服务器按帧率往客户端发RTP包PAUSE/TEARDOWN暂停或终止会话释放资源源码实现时我习惯用一个枚举状态变量每次方法处理完直接更新状态比如typedef enum { RTSP_STATE_INIT, RTSP_STATE_READY, RTSP_STATE_PLAYING, RTSP_STATE_PAUSING } RtspState;SETUP成功后才能PLAYPLAY状态下再收到SETUP要考虑返回455 Method Not Valid In This State这是RFC 2326里明确规定的。很多新手写的代码没做状态校验顺序乱了也不报错结果客户端表现时好时坏其实就是状态机没管住。1.3 SDP媒体能力的“简历”SDPSession Description Protocol是RTSP和媒体之间的一座桥。服务器支持什么编码、什么分辨率、什么采样率全都在SDP里写明白。DESCRIBE请求的响应体就是一段文本SDP客户端解析它来决定怎么解码、怎么渲染。C源码里SDP通常不是运行时动态生成的而是根据媒体源信息拼出来的。常见字段包括v0版本o 会话标识s 会话名称cIN IP4 192.168.1.10连接信息多播场景必填t0 0活动时间mvideo 0 RTP/AVP 96视频轨道端口0表示跟随SETUP协商artpmap:96 H264/90000编码格式和时钟频率afmtp:96 packetization-mode1H.264打包参数acontrol:trackID1该轨道的控制URL一个容易被忽略的细节是acontrol字段。如果客户端发来的SETUP是rtsp://ip/live/ch01/trackID1服务器要能从URL里解析出trackID再映射到具体的媒体子会话。C语言里用strstr或者sscanf提取即可但要注意边界避免读到越界内存。2. 源码框架拆解目录结构与线程模型设计拿到一份RTSP服务器源码第一件事不是读代码是看目录结构和线程模型。这决定了整个项目的复杂度走向也直接关系到你后续加功能的时候是游刃有余还是焦头烂额。2.1 一个可维护的目录结构长什么样我参考过一个轻量级RTSP服务器的开源项目它的目录划分很清晰直接抄过来就很顺手rtsp_server/ ├── include/ // 公共头文件协议定义、数据结构 │ ├── rtsp.h // RTSP请求/响应的核心结构体定义 │ ├── rtsp_server.h // 服务器主接口 │ └── rtp.h // RTP打包相关接口 ├── src/ │ ├── rtsp.c // 请求解析、方法分发、状态机 │ ├── rtp_h264.c // H.264负载打包、时间戳处理 │ ├── sdp.c // SDP构建 │ ├── session.c // 会话管理 │ └── main.c // 启动入口 ├── Makefile └── README.md如果你读的源码把请求解析、SDP生成、RTP打包全部塞进一个几千行的rtsp.c里那后期维护会非常痛苦。我的习惯是每个源文件只专注一件事头文件里只暴露必要的接口内部实现全用static函数隐藏起来。这样别人读你的代码或者你自己一个月后回来看都不至于一脸懵。2.2 线程模型单线程还是多线程RTSP服务器的并发模型基本两类每连接一线程简单来一个客户端创建一个线程会话结束就回收单线程事件循环用select/poll/epoll管理所有socket非阻塞处理我之前在嵌入式平台上用过一个线程池模型思路是主线程负责accept然后把连接描述符丢进一个队列工作线程从队列取任务。这样避免了高频创建销毁线程的开销也能控制最大并发数。实际测试下来在不支持epoll的老式Linux内核上用poll加线程池也能轻松支撑二三十路并发对大多数安防场景完全够用。RTP推流这部分我建议单独一个线程去干不要和RTSP控制请求混在一起。因为RTP是定时发送高频操作如果和控制请求共享线程一个慢客户端或者网络抖动可能导致后续所有请求都堵住。分离之后控制会话和媒体发送互不干扰。源码里通常是一个会话对应一个RTP发送缓冲区和独立线程或者多个会话共用一个发送线程通过定时器轮询就绪的帧。2.3 socket初始化源码里你一定会遇到的几组调用服务器启动的第一步就是创建监听socket。代码看起来差不多但有几个参数值得留意int listen_fd socket(AF_INET, SOCK_STREAM, 0); int reuse 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, reuse, sizeof(reuse)); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(server_port); bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)); listen(listen_fd, 64);SO_REUSEADDR这个选项是必须的。否则服务重启时上一次还没完全释放的四元组会导致bind失败报Address already in use排查起来很坑。mei错就是那种你明明kill了进程端口还是被占用的诡异问题。需要I/O多路复用的时候用epoll还是select取决于平台。Linux下优先epoll没有的话退回到select。C源码里这一层最好封装一下做一个事件驱动的统一接口底层用宏区分平台这样代码跨平台迁移的时候不用改上层逻辑。3. 核心模块的实现细节与关键代码解读这一步是源码分析的重头戏。很多初学者看RTSP源码会卡在RTP打包这一块觉得位操作太多、晦涩难懂。实际上RTP打包是有规律可循的理解了一路打包的逻辑其他编码格式只需要改负载类型和分片策略。3.1 解析RTSP请求字符串处理要稳准狠RTSP请求是文本协议按行分隔。第一行是请求行C源码里解析的过程其实就是按\r\n切分然后按空格拆出方法、URL、版本号。我见过最稳妥的实现是用循环加指针移动的方式逐字符扫描内存而不是依赖strtok因为strtok会修改原字符串而且不可重入。解析的伪代码思路// 读取一行的数据不含换行符存入line // 用sscanf(line, %s %s %s, method, url, version) 提取三要素 // 然后循环读取Header按冒号分割key和value // 直到遇到空行整个Header解析结束 // 如果有Body继续按Content-Length读取关键点是Content-Length很多RTSP请求尤其ANNOUNCE或者带SDP的请求会带body如果只按行读漏了body会导致请求不完整。读取时要注意处理粘包一个TCP包可能包含多个RTSP请求用正则或者循环把数据全读完才能走下一个。Header解析完后C源码里通常用一个函数指针表来分发方法typedef int (*rtsp_handler)(RtspContext *ctx); static const struct { const char *method; rtsp_handler handler; } handlers[] { {OPTIONS, handle_options}, {DESCRIBE, handle_describe}, {SETUP, handle_setup}, {PLAY, handle_play}, {PAUSE, handle_pause}, {TEARDOWN, handle_teardown}, {GET_PARAMETER, handle_get_parameter}, };查表分发的好处是加新方法只需要注册一个函数不需要改一大串if else。源码的可维护性就是这么一点点抠出来的。3.2 SETUP处理与RTP端口分配SETUP是RTSP交互中最核心的一步。客户端会发来类似这样的请求头Transport: RTP/AVP;unicast;client_port6970-6971这表示客户端期望用UDP方式接收RTP接收端口是6970RTCP端口是6971。服务器需要解析出这条Transport然后做两件事第一决策传输模式。如果服务器支持UDP就直接用客户端指定的端口往目标IP发RTP包。如果不支持UDP或者网络环境不允许比如经过NAT就要200响应里返回Transport: RTP/AVP;unicast;client_port6970-6971;server_port8000-8001告知服务器对应的RTP和RTCP端口。第二如果有多个track比如一个视频轨一个音频轨每个track需要独立SETUP。服务器这边要为每个track分配独立的RTP会话session id相同但track id不同端口对各自独立。这块在C代码里有一个隐蔽bug的高发点socket的创建时机。很多新手会在SETUP阶段才去创建RTP sockets这没问题但要考虑失败的情况。如果UDP端口绑定失败整个SETUP应该返回错误响应而不是让客户端以为成功了然后收不到包。我习惯把socket创建和绑定的结果作为SETUP成功的前置条件任何一个失败直接返回500 Internal Server Error。3.3 RTP打包时间戳和序列号是灵魂RTP头有12字节固定部分其中两个字段至关重要sequence number和timestamp。sequence number每个RTP包加1用于检测丢包和乱序timestamp由采样时钟驱动用于接收端正确播放节奏对H.264来说timestamp的递增单位是90000。为什么是90000因为RTP对视频的默认时钟频率是90kHz一秒钟有90000个时钟周期。假设视频帧率是25fps那每帧的时间戳增量就是90000 / 25 3600。这个计算一定要准确否则客户端播放会出现快放、慢放或者音画不同步。看一段标准的时间戳递增代码uint32_t rtp_timestamp 0; uint32_t ts_increment 90000 / fps; // 例如 90000/25 3600 while (frames_remain) { // 读取一帧H.264数据 // 打包成一个或多个RTP包 rtp_timestamp ts_increment; }如果视频源是VFR可变帧率就不能简单按固定增量算要基于解码时间戳PTS/DTS来换算。C源码里一般会传一个pts值进来rtp_timestamp pts * 90000 / 1000000其中pts单位是微秒。3.4 H.264分包NALU太大怎么塞进MTU一帧H.264的裸数据可能几百KB但RTP包最大也就是以太网MTU减掉IP头和UDP头之后的大小约1400字节。所以源码里必须做分片。H.264 RTP打包有三种模式单NALU模式NALU小于MTU直接加12字节RTP头然后填NALU内容FU-A分片NALU太大拆成多个分片每个分片用FU indicator和FU header标记STAP-A聚合多个小的NALU合到一个RTP包里源码里最常实现的是FU-A分片。分片的逻辑可以用下面这个流程概括。NALU的第一个字节包含三部分NRI前三位、Type后五位。对于H.264type取值1-23是普通NALU24-27是聚合包和分片包的标志28就是FU-A。处理FU-A时要生成两个新的字节FU indicator (NALU头的高3位保留) | 28表示这是分片FU header 1起始位S 0结束位E NALU type的低5位起始分片的FU header的S位置1结束分片的E位置1中间的S和E都为0。C代码里一个简单的分片循环长这样int fu_payload_size 1400 - 2 - 12; // RTP头12字节 FU indicator/FU header 2字节 uint8_t *rtp_payload rtp_packet RTP_HEADER_LEN; rtp_payload[0] (nalu[0] 0xE0) | 28; // FU indicator rtp_payload[1] nalu[0] 0x1F; // FU header先不加S/E int offset 1; while (remaining fu_payload_size) { rtp_payload[1] ~0x80; // 清除S位 rtp_payload[1] ~0x40; // 清除E位 if (offset 1) rtp_payload[1] | 0x80; // 第一个分片S位置1 memcpy(rtp_payload 2, nalu offset, fu_payload_size); // 填充RTP头发送 offset fu_payload_size; remaining - fu_payload_size; } // 最后一个分片 rtp_payload[1] | 0x40; // E位置1 memcpy(rtp_payload 2, nalu offset, remaining);这个位运算的逻辑不复杂但极其容易写错。我的经验是先把FU header的值打印出来对照Wireshark看一遍确认S和E位是否正确再做大批量数据传输测试。否则调试的时候丢包断流排查到怀疑人生。3.5 会话资源释放源码里最容易泄漏的地方C语言项目逃不开的话题就是资源管理。RTSP服务器的会话生命周期里涉及到的资源包括socket fd、RTP打包缓冲区、UDP端口、文件句柄如果读文件推流、线程句柄。很多源码会在TEARDOWN时只关闭socket忘了释放RTP发送缓冲区和端口。更隐蔽的是客户端直接断网服务器迟迟收不到TEARDOWN会话就一直挂着。所以源码里必须有一个超时机制比如最近一次RTSP请求超过60秒则自动清理会话。我一般在会话结构体里维护一个last_active时间戳每次收到合法请求就更新启动一个后台清理线程定时扫描。4. 内存与性能优化C语言实现里的几个关键取舍服务端如果跑在嵌入式设备上CPU和内存都有严格限制RTSP服务器的源码质量直接决定它能不能扛住实际压力。这块我踩过不少坑也做过很多性能调优挑几个最有价值的点分享。4.1 零拷贝地使用发送缓冲区一次RTP发送过程中数据从H.264裸数据到最终发送的完整RTP包中间会经过多次内存拷贝。每拷贝一次就浪费一次带宽和CPU。优化思路是在栈上分配一个固定的发送缓冲区把RTP头先填好然后把NALU的分片直接拷贝到缓冲区对应位置一次sendto搞定。不需要额外malloc也减少了内存碎片。示例代码uint8_t send_buf[1500]; uint8_t *rtp_header send_buf; // 填充RTP头 rtp_header[0] 0x80; // version 2 rtp_header[1] 0x60 | (payload_type 0x7F); // marker PT rtp_header[2] (seq 8) 0xFF; rtp_header[3] seq 0xFF; // ... uint8_t *payload send_buf RTP_HEADER_LEN; payload[0] fu_indicator; payload[1] fu_header; memcpy(payload 2, nalu_data offset, payload_len); sendto(rtp_sock, send_buf, RTP_HEADER_LEN payload_len, 0, (struct sockaddr *)client_addr, sock_len);这个方案实测在低端ARM板子上CPU占用率比每包malloc低三成以上。而且send_buf在栈上分配不会产生堆碎片长时间运行更稳定。4.2 环形缓冲区平滑B帧突发流量视频编码器输出不是均匀的一个GOP里关键帧I帧可能瞬间产生几十KB的数据而普通P帧只有几KB。如果网络发送速度跟不上就需要一个缓冲区把数据先存起来慢慢发。我常用的方案是环形缓冲区ring buffer。发送线程往里写RTP发送线程从里面取读写指针加锁或者用原子操作控制。缓冲区大小按最大关键帧的两到三倍预留保证峰值不丢帧。C源码实现可以把缓冲区设计成定长数组加读写索引避免频繁malloc导致性能抖动。需要注意的地方是环形缓冲满的时候策略怎么定。丢弃新帧还是丢弃旧帧RTSP推流场景我倾向于丢弃还未发送的旧帧因为视频流对实时性要求高发迟了的帧到了客户端也来不及解码渲染不如直接丢掉客户端顶多卡一下解码器能自己恢复。4.3 多路复用的高并发策略多路摄像头接入时RTSP服务器要同时管理多个会话每个会话有自己的socket和RTP状态。最早我写的版本是每会话一个线程接到4路8路没问题但到16路以上线程切换开销就很明显了。后来改成基于epoll的事件循环主循环统一管理所有RTSP控制socket的可读事件再按会话ID分发到对应的处理函数。RTP发送这块保留一个独立的发送线程池负责所有会话的媒体数据发送。实测下来16路并发CPU占用比纯线程模型低了将近40%。如果你的源码还不支持epoll调试的时候建议先用poll因为poll跨平台性更好逻辑也清晰。先把功能跑通再考虑性能优化。5. 实际调试中踩过的坑与排查技巧实录源码写出来只是第一步调试才是最头大的环节。我把自己这些年搞RTSP调试压箱底的经验总结了一部分这些都是用时间堆出来的教训。5.1 Wireshark是RTSP调试第一工具无论你多熟悉源码网络层面的问题必须靠抓包工具来定位。Wireshark对RTSP和RTP都有专门的协议解析器能直接展示请求响应、RTP序号、时间戳和SSRC信息。抓包的时候过滤条件可以用rtsp || rtp或者只看某个IP和端口的流量。排查SDP解析问题的快捷办法用Wireshark跟踪TCP流然后导出DESCRIBE的响应body对照RFC里的SDP规范逐行检查。很多时候就是缺了一个acontrol客户端就找不到trackIDSETUP直接失败。5.2 RTP包序号跳变和客户端卡顿RTP sequence number应该每个包1如果有人为重传或者其他逻辑改了计数客户端接收端检测到跳变会认为丢包触发丢包重传逻辑然后造成更大的混乱。我之前遇到过一个问题H.264的FU-A分片里分片的sequence正确但一个NALU内部中间漏发了一个分片Wireshark里看着序号是连续的其实数据不连续客户端解码出来花屏。排查思路很简单抓一个完整GOP的包统计每个NALU的分片数量再用工具重构原始H.264流用ffplay或Elecard流分析工具看是否有解码错误。一旦定位到漏发基本就是memcpy的偏移量算错了回到源码里检查offset维护逻辑。5.3 时间戳不同步导致音画不一致音视频双轨的RTSP服务器最容易翻车的就是音视频时间戳基准不一致。视频的timestamp基准和音频的timestamp基准是不同的时钟。RFC里建议都用90kHz但实际摄像头音频采样率是8k或16k换算方式不同很容易出现偏差。我调试过的摄像机源码里视频时间戳用的是PTS乘以90k倍率音频用的却是采样率直接当频率填进去了。结果就是音频比视频快或者慢播放久了声音和画面完全对不上。解决方法是明确一个全局时间基准比如以微秒为单位视频和音频都从这个基准换算各自的时间戳增量。源码实现里用统一的timebase转换函数保证两边算法一致问题自然消失。5.4 客户端直接断网导致的端口泄漏手机App端测试的人经常直接杀进程这时服务器收不到TEARDOWN如果代码里没有心跳超时机制会话就一直挂着UDP端口一直被占用。积累多了资源耗尽新客户端连不上。我的做法是给每个会话加一个最近活跃时间戳每次收到RTP/RTSP控制包都更新。然后在一个周期任务里检查所有会话超过30秒没有活跃的自动清理并关闭对应socket。别小看这个机制它直接决定服务器能不能7x24小时稳定运行。5.5 C语言RTSP源码日常问题速查现象可能原因排查动作服务启动报Address already in use未设置SO_REUSEADDR检查setsockoptDESCRIBE请求返回但客户端拿不到SDPContent-Length不对或响应头缺空行Wireshark跟踪TCP流检查body能SETUP不能PLAY状态机未正确流转或方法分发表缺失日志输出当前状态和目标状态RTP包发出去客户端收不到端口不匹配或服务器地址写错抓包确认UDP目标端口画面花屏或顿挫FU-A分片S/E位错误或时间戳跳变用Wireshark导出RTP负载分析序列高并发CPU飙高每包malloc频繁或线程切换过多改用栈上缓冲区/事件循环模型程序崩溃在rtp打包逻辑指针越界或偏移计算错误开启AddressSanitizer编译测试6. 从源码到可商用还需要考虑的几个扩展方向看RTSP服务器的C源码如果只是想看懂某个项目或者应付课设前面五节已经够用。但如果是想在真实项目里落地商用还有几个点值得继续深入。6.1 认证机制不能只靠举例简化的RTSP服务器源码经常把认证省了全部请求都放行。实际产品里至少要支持RFC 2069定义的Basic认证和RFC 2617的Digest认证。Digest认证的C实现复杂一点要处理随机数、MD5哈希、qop策略这些但安全性比Basic高很多不会明文传密码。如果源码里有认证钩子建议优先把Digest做上。6.2 并发扩展的消息队列高并发场景下解码线程、RTSP控制线程、RTP发送线程之间需要消息通信。简单的共享内存加锁容易在复杂的时序关系里出问题。我见过一个性能不错的源码实现所有线程之间通过无锁环形队列通信生产者只管写消费者只管读用内存屏障保证可见性。这样在四核ARM处理器上跑八路流消息延迟可以稳定控制在毫秒级。6.3 转发与录像并存很多RTSP服务器的源码只做了实时转发没有本地存储。但是真实项目里“边推流边录像”是刚需。实现录像功能时最简单的方式是加一个订阅者机制在RTP打包完成的同时把数据投递给录像模块录像模块按GOP边界切分保存为MP4或裸H.264。C语言实现里可以用回调函数实现这个钩子业务方只需要注册一个on_rtp_packet函数就能在不改动主流程的情况下接入录像、转码、AI分析等能力。最后再补充一个我的个人习惯不管读谁的RTSP服务器源码我会先在本地编译跑通再看代码结构再用Wireshark对照协议特征抓包验证一遍最后再修改代码做压力测试。这套流程走下来源码里藏的各种细节基本都能被你挖得清清楚楚。如果你也有自己的调试心得或者踩过什么有意思的坑欢迎交流。本文还有配套的精品资源点击获取