Live555多路RTSP转发实战：从摄像头H.264拉到稳定会话管理

简介基于Live555的多摄像头RTSP转发服务器源码面向流媒体开发者解决从多路IP摄像头拉取视频流并统一转发给多个客户端的问题。资源共192个文件包体686KB含175个hh头文件与6个cpp源文件另有4个a静态库及cJSON、txt等辅助文件方便链接和二次开发。目前已有1739人学习下载。源码封装了RTSP服务器、H264媒体子会话与工作线程等核心模块分别负责请求分发、H264流处理与多线程调度并用cJSON解析摄像头配置。研读这些模块可掌握Live555中DESCRIBE、SETUP、PLAY等流程实现理解如何并发管理多路视频流为监控、会议等场景提供可复用代码基础。1. Live555 做多路 RTSP 转发先弄懂为什么它天生适合摄像头手头有个项目某园区需要同时采集多路摄像头画面并统一转发成可供拉流的 RTSP 地址。等真正动手时才发现自己写 RTP 分片、会话管理和连接保活很麻烦——尤其摄像头本身输出的是 H.264 裸流你得处理 SPS/PPS、时间戳和丢包重传稍不留神就出花屏。Live555 是一套非常成熟的 RTSP 服务器框架它把「把摄像头数据变成 Rtsp 服务器可访问的资源」这件事压缩到了会话挂载与帧投喂两个动作。这篇文章把从多路摄像头采集到转发成一个可复现 demo 的过程完整拆开并给出我实际踩过的坑。适合需要快速搭监控转发服务的开发者。2. 会话模型与选型三层对象结构决定你不需要自己造调度2.1 RTSP 不负责拉流Live555 的角色是会话管理加 RTP 打包先讲清楚一个很多人误解的点RTSP 协议本身不承载媒体数据它只管建立会话、播放、暂停、拆卸。真正的媒体流量是 RTP跑在 UDP 或 TCP 上而 Live555 做的就是把「会话控制」和「RTP 打包」缝在一起。你去看它的源码结构就能感受到分工RTSPServer负责解析 RTSP 请求ServerMediaSession描述一路可播放的媒体资源ServerMediaSubsession负责具体的媒体子会话底层的RTPSink把帧拆成 RTP 包发到网络上。这个分层决定了你不用自己写「收到 PLAY 命令后就往 socket 写字节」这种逻辑只要把数据源挂到链路上剩下的是 Live555 的活。常见认知错误是把 Live555 当「转发器」以为开个端口然后把摄像头的字节流原样搬运。实际上它期望的是结构化媒体帧你得按它的FramedSource抽象把一帧一帧喂进去。半只脚踩进来的人往往死在这一步因为字节流和帧流之间还有一层 H.264 裸流解析要处理。2.2 三层对象模型与每路摄像头一个 MediaSession 的关键决策在 Live555 里一个可点播的 RTSP 资源对应一个ServerMediaSession会话里可以挂多个ServerMediaSubsession比如一路视频加一路音频。对多摄像头场景最直接的落地方式就是第 0 路、第 1 路、第 2 路……每路一个ServerMediaSession每个会话里挂一个 H.264 视频子会话URL 分别是rtsp://ip:554/live/0、live/1、live/2。这里有一个关键选型子会话类型用OnDemandServerMediaSubsession还是普通子会话。OnDemand 的意思是「有客户端来 SETUP 才启动数据源」没有客户端时源对象不创建、采集线程也可以完全停掉。对摄像头资源紧张的场景这个模式明显更省但它要求你自己实现「按需创建源」不是 new 一下就完事。注意 Live555 的会话管理是引用计数的。当最后一个客户端断开时OnDemand 子会话会把自己的StreamSource销毁。如果你把采集线程的生命周期和这个源对象绑在一起就会遇到后面要讲的断线重连问题。2.3 为什么不用一个 Session 里塞多个子会话有一种偷懒的思路只建一个ServerMediaSession把几路摄像头都挂成它的子会话一个端口、一个会话名搞定所有路。从协议角度这不是不可能RTSP 会话本来就可以包含多路 track但代价很大多路视频 track 共享同一个 RTP 端口分配逻辑客户端对每个 track 都要单独 SETUP而且某一帧数据在某个 sink 上阻塞会拖慢整个会话的事件循环一路摄像头掉线会让整个会话的 SETUP 失败其他路跟着遭殃。我在多摄像头项目里的做法是每路一个ServerMediaSession它们共用同一个RTSPServer实例、同一个 RTSP 端口靠不同的 URL path 区分。这样一路挂了最多影响那一路其他路的会话照常播放排查问题也简单——你只需要盯着那一路的日志。// 伪代码一个 ServerMediaSession 挂一路 H.264 视频子会话 RTSPServer* rtspServer RTSPServer::createNew(env, 554, NULL); ServerMediaSession* sms ServerMediaSession::createNew(env, live/0, // session name决定 URL 为 rtsp://ip:554/live/0 Camera0 Description, session streamed by Live555, True /* TTL */); sms-addSubsession(H264VideoFileServerMediaSubsession::createNew(env, vid, False)); rtspServer-addServerMediaSession(sms);解释一下两个参数createNew里554是 RTSP 默认端口被占用就换8554session name会直接拼进 URL叫live/0就能用/live/0访问。addSubsession的第二个参数vid是 track id客户端 SETUP 时会用到一般不用管。最后一行把会话注册进服务器Live555 内部会自动维护会话表和 URL 映射。资源里如果提供的是完整可运行的工程通常还会有一个addServerMediaSession的对称删除接口用来处理动态删流。2.4 选型边界什么时候别用 Live555Live555 不是万能的。它默认是单线程事件循环所有 socket 事件都在一个 loop 里处理H.264 以外的编码器支持得很零散JPEG 要自己拼 RTP 包H.265 需要额外补代码对鉴权、录制、转码这些需求基本是空白。单路 1080p、4 Mbps 码率时Live555 单线程处理毫无压力。四路叠加时 CPU 开销也不高真正瓶颈在网卡带宽和交换机。但如果你要面对的是几十路并发点播、需要细粒度权限控制、要能在多台机器间做负载均衡就别硬用 Live555 往上堆换个成熟的流媒体服务器更合适。Live555 适合的场景很清晰嵌入式板子、内网监控、摄像头数量 48 路、点播方数量有限的场景它的轻量就是最大优势。3. 多摄像头接入从 V4L2 到 H.264 帧打包的完整链路3.1 数据来源拆解采集、编码、打包是三段独立的活摄像头接入分三种情况网络摄像头直接 RTSP 拉流、USB/UVC 本地接入、板载 V4L2 设备接入。这个项目场景下最常见的是 V4L2 设备。V4L2 采集到的是 YUYV 或 MJPEG 原始格式Live555 不认原始 YUV需要先编码成 H.264 基本流。这三段必须分开采集线程负责阻塞读帧编码器负责把 YUV 转成 H.264 NAL 单元Live555 侧只做「投喂」。不要在采集线程里直接调 Live555 的接口也不要在 Live555 的回调里做编码否则你会陷入两边的时序问题。我一般会拆成三个类V4L2Capture、H264Encoder、LiveSourceAdapter各自维护自己的状态中间用队列交接。编码器选择上有两条路硬件编码走 V4L2 的VIDIOC_S_FMT输出 H.264或者用 x264/FFmpeg 软件编码。硬件编码省 CPU但帧率控制往往没那么准软件编码稳但 4 路 1080p 的软件 x264 会把嵌入式板子的 CPU 直接拉满。建议先看板子硬编码能力不行再降分辨率换软件编码。3.2 把摄像头帧喂给 Live555重写 FramedSource 的正确姿势Live555 的源对象都是从FramedSource派生的。关键方法是doGetNextFrame()它是一个拉模型的回调——当 RTP Sink 需要新数据时会顺着链路上溯触发它。你在里面做的动作是把一帧 H.264 数据拷贝进fTo缓冲区设置fFrameSize然后调用afterGetting(this)通知上层帧已经填充完毕。// 继承 FramedSource把摄像头 H.264 帧交给 Live555 #include FramedSource.hh class CameraSource : public FramedSource { public: CameraSource(UsageEnvironment env, unsigned char* h264Data, size_t size) : FramedSource(env), fData(h264Data), fSize(size) {} protected: virtual void doGetNextFrame() { if (fSize fMaxSize) { fNumTruncatedBytes fSize - fMaxSize; fSize fMaxSize; } memcpy(fTo, fData, fSize); fFrameSize fSize; afterGetting(this); // 通知上层 RTP sink 帧已就绪 } private: unsigned char* fData; size_t fSize; };三个字段是 Live555 帧投喂的关键fMaxSize表示这次最多能拷多少字节fTo是目标缓冲区fFrameSize是实际填充的字节数。如果fSize超过了fMaxSizeLive555 会截断帧并在fNumTruncatedBytes里记录截断量解码端随后会因帧不完整而花屏。多路摄像头每一路都要有独立的CameraSource实例不要共享因为 Live555 的帧缓冲状态是跟着源对象走的。真正要留意的是doGetNextFrame()里的阻塞行为。如果你的摄像头读取是阻塞的不要在doGetNextFrame()里去等数据否则整个事件循环会卡住其他路的 RTSP 请求全部排队。正确姿势是采集和编码在独立线程跑把编码后的帧放进队列doGetNextFrame()只做队列取数据的动作。3.3 关键帧处理SPS/PPS 要在会话建立时就位H.264 解码需要先拿到 SPS 和 PPS否则画面永远是黑屏。Live555 的H264VideoStreamFramer会在新客户端连接时把最近一次收到的 SPS/PPS 和关键帧一并送出去前提是它见过这些 NAL 单元。这里有个隐蔽的坑如果摄像头上电后第一帧恰好不是 IDRLive555 可能一直没见过 SPS/PPS新客户端连上来就只能等下一个关键帧。有些摄像头 I 帧间隔设得很大比如 2 秒一个就会造成切流后黑屏 12 秒。我的做法是编码器启动时先把x264_encoder_headers输出的 SPS/PPS 存下来在createNewStreamSource里通过H264VideoStreamFramer::setParameters主动喂给 framer。这样无论摄像头什么时候出关键帧新客户端都能立刻正常解码。注意这个注入应该在编码器侧做不要在 Live555 的源里硬拼否则时间戳会混乱。3.4 URL 映射从设备配置到 live/ 索引别写死在代码里多路摄像头接入时最忌讳把设备路径、分辨率、码率写死在代码里。我习惯用一个配置数组索引就是 URL 里的数字运行时从环境变量或配置文件读取struct CameraConfig { int index; // URL 里的编号 std::string device; // /dev/video0 int width, height; // 640x480 int fps; // 25 int bitrate; // 2000 kbps }; void setupMultipleSessions(UsageEnvironment env, RTSPServer* server, std::vectorCameraConfig cfgs) { for (auto cfg : cfgs) { std::string name live/ std::to_string(cfg.index); ServerMediaSession* sms ServerMediaSession::createNew( env, name.c_str(), cfg.device.c_str(), streaming, True); sms-addSubsession( H264VideoFileServerMediaSubsession::createNew(env, vid, False)); server-addServerMediaSession(sms); } }这样加一路摄像头就只改配置文件不用重新编译。注意fps这个参数不只是给客户端看的Live555 用它计算 RTP 时间戳增量。如果你的摄像头实际帧率忽高忽低时间戳就会漂移播放端会出现画面越走越快的诡异现象。解决办法是编码器侧强制固定帧率——x264 里关闭场景切换的 VFR 输出或者用fps25的恒定时基。4. 转发实现与线程模型把每路摄像头挂成独立 RTSP 资源4.1 事件循环是单线程黑洞先理解 doEventLoop 的调度逻辑Live555 服务端启动后必须进入env-taskScheduler().doEventLoop()这是一个不返回的死循环。它内部用一个 select() 轮询所有 socket 事件处理 RTSP 请求、RTP 定时发送、RTCP 反馈等所有事情。这个设计的直接后果是任何一路的任何阻塞操作都会卡住全服务器。我见过有人把摄像头的阻塞 read 直接丢进doGetNextFrame()结果第二路一卡第一路的 RTSP 控制请求也全排队。正确分层是采集和编码在独立线程跑用环形缓冲或队列把 H.264 帧送进 Live555事件循环只管「取帧、打包、发送」这些 Quick 操作。4.2 四路以内别给自己找多线程的麻烦很多初学者会想每个摄像头起一个UsageEnvironment各路各跑各的事件循环。这个思路在「独立」上有优势但坑在资源管理某一路摄像头异常断开时对应 env 的事件循环可能挂死在 select 等待上需要 watchdog 去重启反而连坐其他路。我实测过四路以内都放同一个 env 事件循环CPU 几乎没差别。Live555 的事件循环本身是高并发设计几十个 socket 的轮询开销极小。只有当路数到十几路、且有大量客户端并发点播时才值得考虑分 env 隔离故障域。所以这个项目的合理起步姿势一个UsageEnvironment一个RTSPServer多路会话共享同一个事件循环。4.3 从 CameraSource 到 RTPSink中间件 H264VideoStreamFramer 的职责边界Live555 对 H.264 的处理链路是FramedSource产出原始 H.264 基本流H264VideoStreamFramer负责切割 NAL 单元、识别 SPS/PPS/IDR、修正时间戳最后由H264VideoRTPSink按 RFC 3984 把 NAL 单元分成一个个 RTP 包。很多人在自己实现完FramedSource后直接把它挂到H264VideoRTPSink上结果画面极其不稳定原因就是漏了 framer 这一层。裸 H.264 流里可能一个帧里带多个 NAL 单元也可能一个 NAL 跨两个帧framer 帮你做了缓冲和切分。// 会话创建时的完整链路段落基于资源中的实现整理 FramedSource* source new CameraSource(env, cameraFrame, frameSize); H264VideoStreamFramer* framer H264VideoStreamFramer::createNew(env, source); H264VideoRTPSink* rtpSink H264VideoRTPSink::createNew(env, rtpGroupsock, 96); // 96 是动态 RTP payload type serverSubsession-setRTP(rtpSink, framer);96这个数字是 RTP payload type 的动态范围起始值VLC 和 FFmpeg 默认都认识 96 作为 H.264。如果你用别的数字客户端要手动指定所以常规做法就是 96。rtpGroupsock如果不是组播场景IP 填 0.0.0.0 即可TTL 参数用默认值。关键提示CameraSource里喂给 framer 的必须是 Annex B 格式的 H.264 基本流也就是 NAL 单元以 00 00 00 01 起始码分隔。如果你拿到的是 AVCC 格式带长度前缀的比如从 MP4 解出来的要先把长度前缀转回起始码否则 framer 会解析失败。4.4 RTP 时间戳与帧率对齐的隐藏门道Live555 的 RTP 时间戳基准是 90000 Hz25fps 的话每帧增量 3600。这个计算是 framer 内部自动完成的但前提是它知道帧率。你需要在你自己的源类里实现framerate()虚函数或者通过FramedSource::getFrameRate()暴露真实帧率。实际场景里最常翻车的是摄像头标称 30fps实际跑在 25fps或者高分辨率下编码时间超过帧间隔导致实际输出帧率比设置值低。如果 framer 用 30fps 的增量去推、但实际帧间隔是 40ms时间戳就会累积漂移录像文件会出现倍速播放。我的做法是设置帧率之前先用ffprobe或v4l2-ctl --get-parm实测真实输出帧率然后让编码器输出恒定帧率比如通过 x264 的fps参数强制 CFR再把这个值告诉 Live555 源。这一项直接决定录像时长准不准属于交付前必须校验的点。4.5 背压处理队列满就丢旧帧别去阻塞采集线程采集线程的产出速度和网络发送速度经常不一致典型场景是编码器输出 30fps而网络只能跑 15fps 的带宽。此时如果队列无限增长内存会越吃越高延迟越来越大最后整个系统卡死。正确做法是队列带最大长度限制满的时候覆盖最旧的帧而不是阻塞写入。摄像头数据是实时流延迟 2 秒的画面没有保留价值。我在代码里用环形缓冲区读指针在写指针追上时直接丢弃旧帧并在日志里打一个drop frame计数。这个计数器非常有用——它能告诉你瓶颈在采集、编码还是网络。5. 避坑与排查多路转发最常翻车的五个现场还原5.1 第一路流畅第二路开始花屏或长时间缓冲现象两路 1080p 摄像头接入后单独看任何一路都流畅两路同时播放时第二路间歇性花屏有时候干脆缓冲转圈。原因所有 RTP 都从同一个 socket 出去Socket 发送缓冲不够时Live555 会丢弃来不及发的包。多数情况下不是 CPU 不够而是 UDP 缓冲区溢出。解决创建 RTP groupsock 后用increaseSendBufferTo(env, rtpSock, 4*1024*1024)把发送缓冲调到 4MB。同时把每路码率控制在 4 Mbps 以内1080p 下用 24 Mbps 的画质损失肉眼几乎看不出。改完后看丢包率这种情况基本一次解决。5.2 黑屏偶尔闪一帧fMaxSize 太小帧被截断现象VLC 连上后黑屏偶尔闪出半帧画面日志里有truncated计数。原因FramedSource的fMaxSize默认值是 65536 字节而 H.264 的高码率 P 帧很容易超过 60KB关键帧更大。帧被截断后解码器收到的是残帧直接丢弃。解决在doGetNextFrame()里把fMaxSize调大到 1MB或者从 framer 的maxFrameSize()动态回传。我在某 2K 摄像头上实际把fMaxSize调到 2MB 才完全稳定。注意这不是越大越好太大了内存占用高4 路就要几十 MB按最大预期帧尺寸乘 1.5 倍就够。5.3 客户端断开后重连画面一直黑现象RTSP 播放正常客户端断开后再次连接画面一直黑但服务端进程还活着。原因OnDemand 模式下客户端断开后 Live555 会销毁子会话的源对象。如果你在CameraSource析构里没有做完整的采集线程清理或者第二次重建会话时摄像头设备句柄还在旧状态采集线程就没真正重新跑起来。解决在createNewStreamSource里每次重新初始化采集器打开设备、启动编码、注册帧队列不要在全局保留一个复用的旧源。Live555 给了你「每次按需创建」的钩子你一定要配合它而不是对抗它。排查时可以用 strace 看第二次连接时有没有打开/dev/video0没打开就是源对象没走重建逻辑。5.4 跑一天后 CPU 飙到 100%日志不动现象服务器刚启动一切正常运行 8 小时以上后 CPU 突然满负载所有 RTSP 请求失去响应。原因某路摄像头驱动异常退出或者客户端断开后 socket 处于半开状态select()会把这个 fd 视为「可读」但读操作返回Resource temporarily unavailable事件循环进入忙等待空转烧 CPU。解决对每路源设置心跳探活。用TaskScheduler::scheduleDelayedTask周期性检查 RTP 发送的帧计数如果连续超过 10 秒没有新帧发出就主动关闭该会话并重新创建源。我在代码里把这个任务设成 5 秒一次实际使用中能在摄像头拔线后 15 秒内自动恢复不会拖垮整个服务器。5.5 录像文件时长不对播放器倍速现象录下来的 TS 文件时长只有真实播放时长的一半播放时画面快进。原因CameraSource设置的帧率和实际输出帧率不一致。如果 framer 认为帧率是 50fps实际只有 25fpsRTP 时间戳增量就比真实时钟快一倍容器里的时长就跟着错。解决检查framerate()返回值、编码器实际输出帧率、以及与 NTP 对齐的 RTP 时间戳。排查时抓 RTP 包看相邻两包的 RTP timestamp 差25fps 下应该是 3600如果大于 3600 就是帧率设置偏高小于就是偏低。这个问题不要去调 sink源头在数据源。5.6 VLC 连接被 405 拒绝HTTP 隧道问题现象VLC 打开rtsp://ip:554/live/0在 SETUP 阶段报connection timeout或收到 405 Method Not Allowed。原因某些 VLC 版本或系统配置会优先尝试 RTSP over HTTP 隧道向 554 端口发 HTTP 包装的 RTSP 请求。Live555 默认不处理这种隧道握手。解决两个选择要么在编译时启用 RTSP over HTTP 支持宏这样 Live555 会解析 HTTP 包装的请求要么在防火墙/播放端强制纯 RTSP。内网场景我一般不改这个直接在 VLC 里用--rtsp-tcp强制走 TCP 方式播放还顺带解决了 UDP 丢包问题。如果必须兼容 HTTP 隧道才去开宏重编。6. 进阶验证从能跑到可交付用 VLC 实测多路转发与带宽量化多路转发做出来不算完交付前我会走一遍固定验证流程这里给出一份我实际使用的自测清单照着做能筛掉大部分隐藏问题。先做单路验证VLC 打开rtsp://192.168.1.10:554/live/0观察三个指标画面是否 5 秒内出图、拖动时间条能否快速定位、断开重连是否 3 秒内恢复。如果单路都不过别往下测多路。再做多路交叉验证同时打开live/0和live/1各自独立播放 30 分钟期间手动断开其中一路再重连确认不影响另一路。然后测网络故障模拟拔掉一路网线服务端应在 15 秒内重新拉流恢复不拖垮其他会话。最后做带宽量化每路码率除以 8 乘以 1.2 就是单路理论带宽占用。四路 2 Mbps 就是约 1 MB/s内网千兆完全没压力但如果跑在无线或有瓶颈的交换机上这组数字先算清楚再上线别等客户现场翻车。验证项自测清单验证项预期结果失败时检查哪里单路 VLC 拉流出图5 秒内出图无花屏fMaxSize、SPS/PPS 注入多路同时播放互不影响任意一路断开重连他路不受影响会话独立性、事件循环阻塞摄像头断电自动恢复15 秒内重新出帧心跳探活任务、重连逻辑RTP 时间戳一致性相邻 RTP 包时间戳差稳定在帧率对应的数值framerate 设置、编码器 CFR录像时长准确录 10 分钟播放时长 10 分钟时间戳漂移、客户端播放器对齐这套清单看着朴素但每一条背后都是真实教训。我印象最深的是某次交付前临时换了一款摄像头型号SPS/PPS 时序和旧款不一样直接导致客户演示时黑屏。从那以后我每次新接一个摄像头型号都会强制先做 30 分钟的单路播放验证确认 SPS/PPS 正常、帧率稳定再往上叠加多路。这个习惯帮我挡住了至少三次交付事故也让我在团队里落下了「慢但稳」的名声。希望这套流程和踩坑记录帮你也少走一段弯路。本文还有配套的精品资源点击获取