简介供 Linux 网络编程开发者和音视频流传输学习者使用的客户端源码实现了实时流传输协议RTSP控制与实时传输协议RTP数据接收功能可解决获取实时视频流并进行播放控制的问题适用于视频监控、流媒体播放等场景。资源共 4 个文件包含 3 个 C 源文件和 1 个头文件压缩包仅 5KB文件划分明确分别对应客户端主逻辑、协议底层解析与功能测试便于快速定位和阅读代码。目前已有 953 人学习适合具备 C 语言和套接字编程基础的中级学习者。代码完整演示了建立会话、请求媒体描述、协商传输参数等 RTSP 命令交互流程能够依据会话描述协议SDP信息完成端口协商与媒体流接收附带的测试用例可验证客户端功能是否正确并展示了 TCP/UDP 连接管理、消息解析、RTP 数据接收及常见错误处理等典型思路有助于深入理解协议协作机制同时为自行扩展或调试类似客户端提供可参考的代码骨架。1. Linux 下做 RTSPClient 到底图什么先跑通取流再谈看得懂在一台 Linux 服务器上同时拉取十几路摄像头做实时分析最先翻车的通常不是模型而是 RTSPClient 这条取流链路。RTSP 是摄像头对外提供视频流的默认协议但客户端要做的远不止打开一个rtsp://地址它得完成 DESCRIBE、SETUP、PLAY 三步控制握手解析 SDP 拿到编码参数再把 RTP 包里的 H.264/H.265 分片拼回完整帧。这个标题把 Linux 和 RTSPClient 绑在一起面向的正是做监控拉流、视频分析、嵌入式采集的从业者。读完这篇你能分清 live555、FFmpeg、GStreamer 三条路线各自的边界照着命令在 Linux 上跑通最小拉流也知道主码流不出画面、断流重连这类坑到底出在哪一环。2. 三条路线的边界live555、FFmpeg、GStreamer 怎么选2.1 RTSP 不是传输协议RTP 才是先把协议栈理顺RTSP 默认走 554 端口控制报文用 TCP媒体报文走 RTP/UDP。它长得像 HTTP但语义是控制一个正在进行的媒体会话OPTIONS 探测能力DESCRIBE 要 SDP 描述SETUP 协商传输参数PLAY 开始推流TEARDOWN 结束。SETUP 阶段要指定 Transport 头常见的是RTP/AVP;unicast;client_port5000-5001也可以协商成RTP/AVP/TCP让 RTP 包复用在控制连接上。SDP 里mvideo一行标出 RTP payload typeafmtp一行带出 H.264 的 SPS/PPS。RTSPClient 的全部工作就是把这个控制会话扶上路再把媒体数据接下来交给解码器。很多人在 Linux 上拉流卡住是因为把 RTSP 当成一条视频流其实它是三层东西RTSP 管会话、RTP 管媒体数据、RTCP 管丢包统计和时钟同步。摄像头说我发流了那是 RTSP 层真正的 H.264 字节在 RTP 包里画面卡不卡、丢包率高不高要去看 RTCP 的 Receiver Report。选型之前把这层理清后面对着日志才不会一头雾水。2.2 live555 的 RTSPClient协议控制最细代价是自己拼帧live555 是一套 C 的流媒体库RTSPClient是它的核心类OpenRTSP 是官方参考程序。它的工作方式很嵌入式依赖于TaskScheduler事件循环你发一个命令、注册一个回调事件触发时回调被调用再在回调里推下一个命令。用它可以精确控制每一处细节自定义 RTSP 头、选择 UDP 还是 TCP 交叠传输、拿到原始 RTP 包自己重组、甚至自己拼私有扩展。代价是它把所有脏活都留给客户端。MediaSession只帮你解析 SDP 和建立MediaSubsessionRTP 包拆完以后H.264 的 FuA 分片要不要合并、SPS/PPS 从哪取、时间戳怎么对齐全得自己来。如果你的目标是把 RTSPClient 嵌进自研的采集程序、要精细控制重传和缓存策略live555 是主流选择如果只是想把流拉下来分析优先别选它开发成本不在一个量级。2.3 FFmpeg 的 avformat 拉流开箱即用适合喂给分析程序FFmpeg 把 RTSP 客户端整个藏进了avformat层。你只需要avformat_open_input指定rtsp://地址内部会替你完成 DESCRIBE、SETUP、PLAY收到的 RTP 包会自动重组成 AVPacket甚至可以直接解码成 AVFrame。命令行一句话就能验证摄像头通不通配合ffprobe能直接看到编码格式、分辨率、SPS/PPS 这类关键信息。它在协议控制粒度上不如 live555但你做监控分析、转封装、喂 YOLO 时根本不需要那层控制权。FFmpeg 也是把 RTSP 流重新封装成其他格式最顺手的工具比如直接把拉到的 H.264 存成 MP4。对绝大多数 Linux 场景第一选择不是自己写客户端而是先拿 FFmpeg 把链路验证通再决定要不要下沉到 live555。2.4 GStreamer 的 rtspsrc流水线里拉流调试靠 GST_DEBUGGStreamer 把 RTSP 拉流封装成一个rtspsrc元件用流水线的思维串联拉流、解码、显示或转推。一条gst-launch-1.0 rtspsrc location... ! decodebin ! autovideosink就能把摄像头画面推到本地窗口调试时设置GST_DEBUGrtspsrc:5能看到完整的 RTSP 报文交互。它和 FFmpeg 的区别在于GStreamer 更强调元件复用和实时流水线适合做视频会议、实时转播这类需要把多路流拼接、混流、预览的场景。三者的选择逻辑不复杂要精细控制 RTP 层、嵌进自研 C 程序选 live555要把流快速变成文件或帧选 FFmpeg要在流水线里做实时处理选 GStreamer。我自己做监控分析项目时验证阶段用 FFmpeg正式采集端如果摄像头数量多、需要私有协议扩展再落到 live555。对比维度live555 RTSPClientFFmpeg avformatGStreamer rtspsrc上手成本高需理解事件循环与回调低命令行即可验证中需理解流水线RTP 层控制完全可控封装内部部分可控输出形态原始 RTP 重组包AVPacket / AVFrameGstBuffer适合场景自研采集端、私有扩展、嵌入式快速拉流、转码、喂分析实时流水线、多路预览调试方式env 日志与回调返回值命令行 ffprobeGST_DEBUG 日志3. 用 FFmpeg 在 Linux 上跑通最小拉流命令、参数与主/子码流3.1 一条命令验证摄像头取流先在 Linux 上做最小验证。拿一台海康摄像头举例常见取流地址形如rtsp://admin:password192.168.1.64:554/h264/ch1/main/av_stream主码流是高清 H.264/H.265子码流是小分辨率。下面的命令把 RTSP 流以 TCP 方式拉下来不做转码直接存成 MP4ffmpeg -rtsp_transport tcp \ -stimeout 5000000 \ -i rtsp://admin:password192.168.1.64:554/h264/ch1/main/av_stream \ -an -c:v copy -f mp4 -y capture.mp4-rtsp_transport tcp强制走 RTP over TCP避免 UDP 在跨网段时丢包导致画面花掉-stimeout 5000000是 socket 超时单位是微秒即 5 秒没收到数据就报错退出避免程序挂死-an丢弃音频-c:v copy直接复制 H.264 码流不做重编码属于无损验证。这条命令跑通说明网络、摄像头账号、取流路径都没问题。跑不通时优先看报错尾部常见的是Connection timed out网络不通和401 Unauthorized账号或取流地址权限不对。验证通过后就可以进入分析模式。很多人第一次拉流就要求解码出图像其实先做-c:v copy更稳它把故障边界压缩在取流本身一旦涉及解码问题可能来自摄像头编码参数而不是路由。顺序应该是先验证能取到码流再验证能解码出画面。3.2 TCP 还是 UDP断流现场的第一个分岔口RTSP 默认媒体走 UDP很多摄像头出厂也是优先 UDP。UDP 的优势是延迟低、没有 TCP 的拥塞控制问题是一旦网络有抖动或跨三层路由RTP 包静默丢失画面会出现马赛克、卡顿严重时 RTCP 长时间收不到包客户端主动断连。用-rtsp_transport udp显式指定 UDP 拉流时可以加一个-buffer_size 2048把内核 socket 接收缓冲加大对抗网络抖动ffmpeg -rtsp_transport udp -buffer_size 2048 \ -i rtsp://admin:password192.168.1.64:554/h264/ch1/main/av_stream \ -frames:v 100 -f null --frames:v 100只拉 100 帧就退出适合快速验证-f null丢弃输出只看处理过程有没有报错。如果同一摄像头在 UDP 模式下间歇性花屏、换 TCP 后稳定基本可以判定是网络丢包而非摄像头故障。实网项目中我一般直接要求 TCP监控分析的实时性要求没那么极端TCP 的重传机制能把画面完整性保住代价是延迟略增。跨公网拉流更要用 TCPUDP 穿透和丢包会耗掉大量排查时间。3.3 用 ffprobe 看 SDP主码流与子码流的真实差异摄像头地址里main和sub代表主码流和子码流很多项目的坑都埋在它俩的差异上。主码流分辨率高、码率大、常是 H.265子码流小分辨率、低码率、可能是 H.264。先用 ffprobe 把实际参数摸清楚ffprobe -v error \ -rtsp_transport tcp \ -show_streams -select_streams v:0 \ -show_entries streamcodec_name,width,height,profile,bit_rate \ -of json \ rtsp://admin:password192.168.1.64:554/h264/ch1/main/av_stream输出的 JSON 里codec_name如果是hevc说明主码流是 H.265下游处理链必须带 H.265 解码器width和height告诉你真实分辨率profile能看到High还是Main。做 YOLO 这类推理任务时我一般建议先拉子码流分辨率低、帧率足够、解码开销小识别精度损失有限但吞吐提升明显。主码流留给需要高清取证的回放链路。SDP 里afmtp带的sprop-parameter-sets是 H.264 的 SPS/PPS 的 base64 编码它决定了解码器能不能正确起步。用 ffprobe 看不到完整 SDP想看原始交换报文可以加-loglevel debugffprobe -v debug -rtsp_transport tcp -i rtsp://... 21 | grep -i sprop\|fmtp这条命令把 DESScribe 响应里的 SDP 内容打到日志里排查花屏、解码器起不来时非常管用。记住ffprobe 是你理解摄像头真实行为的黑匣子钥匙比看摄像头网页配置页更可靠。参数作用建议值-rtsp_transport指定传输协议跨网段用tcp局域网可试udp-stimeoutsocket 数据超时微秒50000005 秒-max_delay最大缓存延迟微秒5000000.5 秒-fflags nobuffer关闭输入缓冲低延迟场景开启-flags low_delay降低解码延迟实时分析开启-buffer_size内核 socket 接收缓冲UDP 时调大到 2048-fflags nobuffer和-flags low_delay是实时分析的两个常用开关。前者让 FFmpeg 不要攒一堆数据再输出后者让解码器优先输出低延迟帧。代价是解码效率略降但对实时推理来说延迟比吞吐更值钱。4. 用 live555 的 RTSPClient 自己写 Linux 拉流端从握手到拼帧4.1 RTSPClient 的四个回调点DESCRIBE 到 PLAY 的推进live555 的RTSPClient是事件驱动的它的执行节奏是发一个命令、注册回调、事件循环转起来、服务器响应后调回调。一个标准会话有四个推进点sendDescribeCommand拿到 SDP 后解析出MediaSession对每个要拉的MediaSubsession发sendSetupCommand全部 Setup 成功后发sendPlayCommand最后收 RTP 包的阶段持续运行直到收到 TEARDOWN 或错误回调。每一步的resultCode非零都意味着该去查env-getResultMsg()这是 live555 最主要的排错入口。这四个回调点也是 RTSPClient 最容易写错的地方在回调里直接发起下一个命令没问题但绝不能阻塞在回调里做耗时的解码初始化。事件循环是单线程的你在回调里睡 100 毫秒整个客户端的 RTCP 处理就停摆摄像头端可能因此判定你死了。正确的写法是回调里只做轻量状态推进重活丢给独立线程。4.2 最小实现骨架SDP 解析与媒体会话建立下面的骨架按 live555 公开 API 的常见用法写出核心是把 DESCRIBE 的响应交给MediaSession::createNew再逐个 Setup#include liveMedia.hh #include BasicUsageEnvironment.hh static void describeDone(RTSPClient* client, int resultCode, char* sdp) { if (resultCode ! 0) { UsageEnvironment env client-envir(); env DESCRIBE failed: client-getResponseCode() \n; return; } MediaSession* session MediaSession::createNew(client-envir(), sdp); if (session nullptr) { /* SDP 解析失败 */ return; } MediaSubsessionIterator iter(*session); MediaSubsession* sub; while ((sub iter.next()) ! nullptr) { if (sub-codecName nullptr) continue; // Setup 回调里会再检查是否可播放 sub-sink nullptr; client-sendSetupCommand(*sub, setupDone, False, False); } } static void setupDone(RTSPClient* client, MediaSubsession* sub, int resultCode) { if (resultCode ! 0) return; // 这里建议用 MediaSink::createNew 创建 sink再 startPlaying client-sendPlayCommand(*sub-parentSession, playDone); } int main(int argc, char** argv) { TaskScheduler* scheduler BasicTaskScheduler::createNew(); UsageEnvironment* env BasicUsageEnvironment::createNew(*scheduler); RTSPClient* client RTSPClient::createNew(*env, argv[1], MyRtspClient); client-sendDescribeCommand(describeDone); env-taskScheduler().doEventLoop(); return 0; }这段代码是简化主线但把 live555 的流程讲清楚了RTSPClient::createNew的参数依次是环境、RTSP 地址、会话名sendDescribeCommand只发一个 DESCRIBE回调里拿到的sdp字符串是纯文本可以直接打印出来人工核对MediaSubsessionIterator遍历 SDP 里所有媒体段每个sub都是一路可拉取的流。注意sendSetupCommand的最后两个布尔参数分别表示是否要 UDP 多播和是否流用 TCP 交叠摄像头场景固定传False, False即可TCP 交叠模式下 RTP 包会通过同一个 socket 发来需要额外解析$开头的交叠帧头比默认 UDP 模式复杂一截。4.3 拿到 RTP 包之后H.264 FuA 分片重组RTP 包不是一包一帧H.264 的 NAL 单元大时会被拆成多个 RTP 包这叫 FuA 分片。RTP header 后面第一个字节是 Fu indicator前三位是 F 和 NRI后五位 type28 表示这是分片第二个字节是 Fu headerS 位标记分片开始、E 位标记结束、R 位保留、后五位是真实 NAL type。重组逻辑就是遇到S1开一个新缓冲区中间分片依次追加E1时把缓冲区完整交出去。IDR 帧的关键参数 SPS/PPS 不在 RTP 包里而在 SDP 的sprop-parameter-sets里base64 解码后得到两个 NAL需要拼接在关键帧前面一起送给解码器。void onRtpPacket(unsigned char* data, size_t len, uint32_t rtpTs) { unsigned char* payload data 12; // 跳过 RTP header unsigned char fuHeader payload[1]; bool startFlag (fuHeader 0x80) ! 0; bool endFlag (fuHeader 0x40) ! 0; if (startFlag) { // 开始新帧把 Fu indicator 还原成原始 NAL header unsigned char nalHeader (payload[0] 0xE0) | (fuHeader 0x1F); frameBuf.clear(); frameBuf.push_back(nalHeader); } if (!startFlag !endFlag) { frameBuf.insert(frameBuf.end(), payload 2, payload len); } if (endFlag) { // 完整帧交给解码器或写入文件 deliverFrame(frameBuf.data(), frameBuf.size(), rtpTs); } }这段代码是重组核心。data 12跳过标准的 12 字节 RTP 头前提是没有 CSRC 扩展payload[0]是 Fu indicator它保留了 NRI 位payload[1]的 S/E 位决定分片首尾。常见错误是直接把payload 2当作一帧交给解码器那会把一个 NAL 拆成多个无效分片解码器必然报错。还有一个坑是单包 NAL小于 MTU 的 NAL 不经过分片type直接是 1~23 而不是 28代码里必须区分 FuA28和单包两种情况很多自研客户端在这里花屏排查了很久。5. 避坑排查Linux 下 RTSP 客户端最常见的五类翻车现场5.1 现象DESCRIBE 成功、PLAY 也返回了但解码器一直不出画面原因大概率是主码流编码格式和下游解码器不匹配。海康主码流默认可能是 H.265而你的 FFmpeg 没带 libx265 或 GPU 解码器日志里能看到hevc字样却解不出来另一种可能是有 B 帧导致解码延迟拉高前几百帧全是参考帧画面迟迟不出现。解决先ffprobe -show_streams -select_streams v:0看codec_name到底是h264还是hevc再决定是否换子码流地址。如果是 B 帧问题在解码参数里关掉 B 帧或加-flags low_delay。我的经验是分析链路优先选子码流 H.264它比主码流省掉一半以上的解码压力。5.2 现象拉流能跑几十秒然后卡住不动过一会报超时退出原因多数是 UDP 传输丢包被 RTCP 检测到客户端等不到连续媒体数据触发-stimeout断开少数情况是摄像头端 RTSP 会话有超时阈值客户端没发 keep-alive 的 OPTIONS 请求被服务端主动踢掉。解决媒体传输强制-rtsp_transport tcp这一步能解决八成断流。同时增加应用层保活每 30 秒发一个 OPTIONS 请求live555 里用sendOptionsCommandFFmpeg 命令行里用-timeout或外部脚本定时重连。不要指望摄像头端宽容生产环境的重连逻辑必须自己做。5.3 现象用 live555 自研客户端拉流花屏、起不来ffprobe 却正常原因大概率是 SPS/PPS 没处理好。自己拼 H.264 时解码器需要 SPS/PPS 才能初始化而这两个 NAL 通过 RTSP 的 SDP 里sprop-parameter-sets传不是跟着每一帧走。RTP 路上只有 IDR 帧开头的关键信息漏掉 SPS/PPS解码器永远无法起步。解决解析 SDP 时把sprop-parameter-sets取出来base64 解码成两个 NAL在收到第一个 IDR 之前先喂给解码器。调试时用ffprobe -v debug打印完整 SDP确认这两个参数是否在。这个坑是自研 RTSPClient 的第一大坑没有之一。5.4 现象想对摄像头做倍速回放、倒放发 PLAY 带Range参数摄像头不理会原因RTSP 标准的Range只支持按时间定位倍速和倒放不是标准能力。海康等厂商用私有扩展实现比如在 URL 里加?speed2或自定义 RTSP 头且只在特定固件、特定码流类型下生效。拿标准 PLAY 去调私有功能服务器返回455 Method Not Valid很正常。解决先查厂商 SDK 或抓包看它们自己的播放器发了什么。自己实现时可以走按需拉流 本地倍速的路线正常拉流存文件或内存倍速播放交给本地播放器这比去协商摄像头私有扩展可靠得多。所有依赖私有扩展的写法都要做兼容开关固件升级可能直接废掉。5.5 现象从单路拉流扩展到 8 路、16 路内存和 CPU 一起飙升甚至 OOM原因每个 RTSPClient 会话都持有独立的 RTP 重组缓冲、socket 缓冲和 SPS/PPS 缓存而如果每路又各起一个 FFmpeg 进程来做解码内存是成倍叠加的。常见误用是一路摄像头一个进程拉起全套 FFmpeg 解码16 路就是 16 份解码器内存自然爆。解决做采集层和解码层分离。采集层只做-c:v copy的码流落地或缓冲解码用共享的硬件解码器或线程池。对 live555所有会话共用一个TaskScheduler事件循环不要每路单独建线程循环事件驱动模型本身就是为高并发设计的。先用-frames:v 100验证单路资源占用再按比例估算多路上限不要等 OOM 了才去优化。6. 实战技巧把 RTSPClient 拉到的流直接喂给 YOLO 做目标检测6.1 用 FFmpeg 管道把 H.264 解码成 rawvideo 抛给 Python验证模型前最痛的一步是把摄像头流变成 numpy 数组。常见做法是 FFmpeg 把 RTSP 流解码成 BGR 裸流通过标准输出管道喂给 Python避免中间落盘。先用-c:v copy验证取流这一步改为完整解码ffmpeg -rtsp_transport tcp \ -i rtsp://admin:password192.168.1.64:554/h264/ch1/sub/av_stream \ -vf scale640:640 -pix_fmt bgr24 -f rawvideo - \ python3 detect.pyPython 端按帧大小从 stdin 读取import sys import numpy as np width, height 640, 640 frame_bytes width * height * 3 # bgr24 while True: buf sys.stdin.buffer.read(frame_bytes) if len(buf) frame_bytes: break img np.frombuffer(buf, dtypenp.uint8).reshape(height, width, 3) # 这里交给 YOLO 模型推理 # detect(img)管道模式的关键是字节对齐-vf scale640:640把分辨率固定-pix_fmt bgr24规定每像素 3 字节Python 端才能按固定大小切割。-f rawvideo不携带任何封装头是纯视频帧速度最快但也是最容易踩读一半就 break的写法务必判断len(buf)。如果模型推理速度跟不上拉流帧率可以用-r 5限制输出帧率避免管道积压导致延迟滚雪球。6.2 验证端到端延迟的一个小办法拉流到推理的真实延迟可以从 RTP 时间戳和本机收到帧的时间差估算。RTSP 的 RTP 时间戳基于摄像头时钟拿它与系统当前时间对齐并不精确更实用的是秒表法把手机秒表界面放在摄像头前屏幕上显示推理结果框对比秒表实际读数与画面帧里秒表读数的差值。这个差值就是端到端延迟包括取流、解码、推理、显示的全部开销。目标检测场景子码流 TCP 关闭 B 帧通常能把端到端延迟压到一秒以内够用就行不必追求极致的毫秒级。我做过一个 12 路摄像头的人流量统计项目最初用 UDP 拉主码流训练好的 YOLO 模型在花屏和断流面前毫无用处。后来把所有拉流统一改成子码流、TCP 传输、超时自动重启编码层用硬件解码模型才稳定跑起来。调试 RTSPClient 时养成一个习惯每次改动只动一个变量要么换协议、要么换码流、要么换解码器别同时调三个。希望你少走我踩过的这些坑。本文还有配套的精品资源点击获取