流媒体协议实战：老协议仍是基本功，新协议协同才可靠

最近在做一套流媒体接入网关客户需求非常典型无人机要 GB28181 回传园区摄像头要 RTSP 拉流还有一拨人非要在浏览器里低延迟看画面。与此同时社区里讨论最热的是 WHIP、WHEP 和 MoQ 这些新协议。热搜归热搜真正落到项目里我发现大部分时间还是花在 RTSP、RTMP、GB28181 上。这篇文章聊聊我的真实感受拥抱新协议没问题但老协议的基本功才是流媒体工程师最该做扎实的地方。很多人觉得新协议出来后老协议就该退场了。实际做项目时完全不是这么回事。我给自己也算了一笔账这个网关从拿到需求到能跑通端到端真正让项目卡壳的全是老协议的兼容性细节而新协议反而在标准化之后接入起来轻松得多。所以我想把这些经验写出来尤其适合正在做视频平台、安防接入、无人机直播这类项目的朋友参考。1. 新协议到底新在哪先把 WHIP、WHEP、MoQ 说清楚1.1 WHIP/WHEPWebRTC 的标准化接插件先说 WHIP全称 WebRTC-HTTP Ingestion ProtocolRFC 97282025 年初正式发布。它解决的是 WebRTC 推流接入不统一的问题。以前你想让浏览器或者 OBS 往自己的流媒体服务器推 WebRTC 流得自己定义一套信令交换流程协议里只说用 SDP 协商但怎么交换、交换完怎么办完全百花齐放。WHIP 把这件事收敛成了HTTP POST 一个 SDP Offer服务器回 200 OK 带 Answer后面就按 WebRTC 的 ICE 和 DTLS 流程走。就这么简单但正因为简单它成了事实标准。WHEP 是 RFC 9729和 WHIP 对称解决拉流侧的问题。浏览器请求一个 WHEP 地址先 HTTP 拿 SDP然后建立 WebRTC 会话接收媒体。这个模型对前端开发极度友好一个 fetch 请求就完成了接入剩下的交给播放器。我在项目里实测下来WHIP/WHEP 最大的价值在于接插件化。服务端只要实现了这两个协议前端和 OBS 之类的工具就能开箱即用不用再纠结私有信令的兼容问题。但要注意WHIP/WHEP 只标准化了接入方式媒体分发层面还是要靠 SFU 或者网关去打通它本身不负责把流推到千家万户。1.2 MoQ换一个传输底座搞直播MoQ 是 Media over QUIC 的缩写IETF 正在推进的草案目前还没转正但热度已经很高。它的核心是抛弃 TCP 或者 UDPRTCP 这套老组合直接在 QUIC 上传输媒体对象。QUIC 是 HTTP/3 的底层协议有 0-RTT 连接、多路复用、单条流丢包不影响其他流这些特性所以 MoQ 在低延迟分发上天生有优势。为什么业界关注 MoQ因为现有直播分发的痛点非常明确。RTMP/HTTP-FLV 走 TCP遇到丢包会重传延迟和卡顿容易被放大WebRTC 虽然低延迟但每个连接都是独立会话在大规模分发场景下 SFU 压力很大而且 WebRTC 的缓存、录制、转码支持并没有标准化。MoQ 想做的是媒体也能像数据一样缓存和分发CDN 节点可以缓存媒体对象用户从最近的节点拉流延迟能控制在亚秒级又不像 WebRTC 那样重。不过我这里得说句实在话MoQ 目前生产环境落地还少客户端库成熟度也不够我接触的大多数项目还在观望。但它的传输理念是对的尤其是面向大规模直播分发很可能是下一个阶段的主流方向。1.3 新协议的边界什么场景下暂时靠不住这部分是我踩过坑之后才想明白的。WHIP/WHEP 好归好但它依赖 WebRTC 那一整套 ICE/DTLS/SRTP 体系对网络环境有要求。我在一个客户的园区网络里调试UDP 被限制得厉害ICE 候选选不通结果还是切回 RTSP over TCP 才稳定。这类问题在政企网络、专网环境里非常常见不是你代码写得对就能绕过去的。MoQ 的问题在于生态。它现在还在草案阶段规范变来变去我用过几个早期实现API 差异很大根本不敢直接上生产。另外 MoQ 解决的是分发环节但源的接入、设备的兼容、历史录像的调度它一概不管。也就是说新协议更像大脑和新血管但四肢仍然需要老协议去接。一句话总结新协议的价值它们在接入标准化和传输效率上做了重要突破但并没有覆盖流媒体全链路。这就引出了今天的核心问题——老协议为什么还丢不掉。2. 为什么老协议依然是生产环境的压舱石2.1 海量摄像头和无人机GB28181、RTSP 是设备的出厂语言先说硬件侧。全球范围内的 IP 摄像机、NVR、执法记录仪出厂支持的协议主要是 RTSP 和 GB28181这不是厂商不想升级而是整个安防行业过去十几年的存量太大了。一个中型园区可能有几百路摄像头换设备周期是按年算的。你不可能为了用 WebRTC 把所有摄像头都换一遍。GB28181 更是特殊在公共安全视频监控领域是硬性要求平台侧必须能接入国标设备。热词里提到的大疆经纬 M300 RTK、M200 系列、御 Mavic 2 行业版这些无人机本身就内置 GB28181 能力。我做过一个应急指挥项目无人机起飞后直接把画面通过 GB28181 推到指挥中心平台再从平台转发到大屏和手机端整个过程根本不需要在飞机上装额外软件。RTSP 的情况类似海康、大华这些设备的取流地址几乎成了行业暗号。海康是rtsp://user:passip:554/Streaming/Channels/101大华是rtsp://user:passip:554/cam/realmonitor?channel1subtype0只要做安防接入这些格式必须烂熟于心。安卓端想缓存 RTSP 流Media3/ExoPlayer 可以直接播但要做录像、做本地缓存很多还是靠 RTSP 转 HLS 再缓存走的还是老协议管线。2.2 RTMP 的推流统治力从 OBS 到 ESP32再看 RTMP。它虽然是 Adobe 时代的老协议但直播推流端的地位至今没有被真正撼动。OBS 默认推流协议是 RTMP 还是 RTMPS我在多个直播平台配置里看RTMP 依然是主流底座。演唱会直播、游戏直播、电商直播大量源站接收的都是 RTMP 流因为编码器、采集端的支持最成熟。还有一个更极端的例子ESP32 推 RTMP。我在业余项目里用 ESP32-S3 OV2640 摄像头做网络摄像头跑 RTMP 推流非常稳定内存占用和 CPU 开销都在可接受范围。为什么不用 WebRTCESP32 的性能跑 DTLS/SRTP 那套太重了WebRTC 的 ICE 协商在这么弱的芯片上也容易出问题。RTMP 基于 TCP逻辑简单推流几百 Kbps 的低分辨率视频完全够用几十块钱的硬件成本就能搞定一个会说话的摄像头。这种场景下RTMP 不是妥协是最合适的选择。2.3 调试、排障、可观测性的成熟度差着量级这一点是我最想强调的。新协议的调试链路太长了拉个 WebRTC 流要去看 SDP、ICE candidate、DTLS 握手、SRTP 密钥协商任何一个环节出问题报错信息都晦涩难懂。但 RTSP、RTMP、GB28181 不一样几十年的沉淀下来工具链非常完备。ffprobe一条命令就能看 RTSP 流完整信息ffplay直接播放Wireshark 对 RTP/RTCP、SIP、RTMP chunk 流的解析非常成熟过滤器一抓一个准GB28181 的 SIP 信令可以通过抓包软件直接看到 REGISTER、INVITE、MESSAGE 的交互过程。我在现场排查问题的时候大多是靠 ffprobe 和 Wireshark 先定位到老协议这一侧反而 WHIP/WHEP 出了问题经常要同时看服务端日志、WebRTC 统计、ICE 网络状态排查链路长很多。这也是老协议在工程上不可替代的隐性价值。3. 新老协议不是替代关系是协同关系3.1 我常用的混合接入架构在实际项目里我几乎从不做只支持新协议或者只支持老协议的方案。我常用的架构是统一接入 协议网关 多态输出。接入层把各种来源的流汇聚进来摄像头走 RTSP、国标平台走 GB28181、网页/APP 推流走 WHIP/RTMP。汇聚之后内部统一成一种中间格式再按需输出给不同终端浏览器用 WHEP、移动端用 HLS 或 HTTP-FLV、传统播放器用 RTSP。这样做的好处是终端侧不用关心源是什么。你的前端只需要 WHEP 的播放地址至于后面是无人机、海康摄像头还是手机推流网关层全部处理掉。我管这个叫翻译层它让新协议和老协议各司其职。3.2 协议转换到底在转什么很多人以为协议转换是把 RTSP 文件转成 WebRTC 文件这是误区。流媒体协议转换本质上分两层封装层转换和编码层转换。封装层转换最常见。RTSP 和 WebRTC 的媒体面其实都是 RTP但 RTSP 是裸 RTPWebRTC 是 SRTP加密的 RTP。GB28181 更特殊它的 RTP 里装的是 PS 封装MPEG2-PS得先把 PS 解出来还原成 H.264/H.265 的 Access Unit再按 WebRTC 的 RTP 负载格式重新封装。这个过程不需要转码CPU 开销很低是网关首选方案。编码层转换就费资源了。比如 GB28181 设备推了 H.265但浏览器 WebRTC 解码支持参差不齐这时候就得转码成 H.264。我一个项目中用 NVIDIA 硬编码器做这个转换单路 1080p 的转码延迟能压在几十毫秒但 CPU 转码就非常吃力。所以设计协议网关时一定要先算好哪些链路只需要转封装哪些链路必须转码。3.3 一个完整接入链路无人机 GB28181 → WHEP 浏览器播放我举一个自己实际做过的链路帮助你把上面这些串起来。前端是无人机通过 GB28181 往平台注册并推流。平台侧收到 SIP INVITE 后会回带 SDP 的 200 OK协商媒体端口无人机随后用 RTP 把 PS 封装好的 H.264 视频推到平台媒体服务器。媒体服务器收到后解 PS 封装得到 H.264 裸流再交给转封装模块按 WebRTC 的格式重新打包同时把加密所需的 SRTP 参数与 WHEP 会话关联起来。用户浏览器打开页面通过 WHEP 发起请求拿到 SDP Answer握手成功后即可低延迟播放无人机画面。整个过程里无人机侧只认识 GB28181浏览器侧只认识 WHEP中间的一切翻译工作都由网关完成。这个链路跑通之后客户非常满意因为前端开发不用懂任何 GB28181 的细节只需要一个 WHEP 的 URL 就行。但反过来说如果没有网关对 GB28181 的深度支持这个需求根本做不出来。所以新协议和老协议从来都是协作关系不是二选一。4. 实操把老协议跑通、跑稳的关键细节4.1 十分钟搭好 RTSP/RTMP 测试环境如果你刚接触这块我建议直接上 mediamtx原来叫 rtsp-simple-server。它是单个二进制文件支持 RTSP、RTMP、WebRTC、SRT 等多种协议非常适合本地测试和学习。下载解压后改个配置就能跑默认端口 8554 给 RTSP、1935 给 RTMP。我常用的测试方法是这样。先用ffmpeg把一个本地视频文件循环推给 mediamtx 的 RTMP 端口ffmpeg -re -stream_loop -1 -i test.mp4 -c:v libx264 -preset veryfast \ -tune zerolatency -c:a aac -f flv rtmp://localhost:1935/live/test推上去之后用 VLC 打开rtsp://localhost:8554/test就能直接播放。这个链路跑通了说明 RTMP 推流、RTSP 拉流、服务器转封装都正常后续再往上叠 GB28181 和 WHIP/WHEP 就有底气了。想用 GStreamer 搭 RTSP 服务器做更深入的测试可以用gst-rtsp-server做开发也可以直接用命令行起一个简单的测试源gst-launch-1.0 videotestsrc patternball ! video/x-raw,width1280,height720 ! \ x264enc tunezerolatency ! rtph264pay namepay0 pt96 ! rtspclientsink \ locationrtsp://localhost:8554/gst当然这个命令里rtspclientsink需要你安装对应的插件实际直接用 mediamtx 会更省心。我建议你先把手上的工具跑熟再去啃协议细节。4.2 摄像头 RTSP 取流地址与参数详解RTSP 取流最常踩的坑就是地址格式。海康的地址规则是rtsp://用户名:密码IP:554/Streaming/Channels/101注意最后一个1011 表示通道 101 表示主码流02 就是子码流。网上流传的很多海康取流地址写的是ch01_sub那是老版本的支持。大华是rtsp://用户名:密码IP:554/cam/realmonitor?channel1subtype0subtype0 主码流subtype1 子码流。用户权限问题也经常遇到。很多摄像头默认禁用了 RTSP 鉴权或者只允许管理员取流。现场排查时先用 VLC 打开地址试一下如果是 401 Unauthorized优先检查账号密码和摄像头网络→集成协议里的 RTSP 鉴权设置。还有一个细节是 RTSP 的 TCP/UDP 模式。默认大多数播放器会用 UDP 传输 RTP但在跨网段、防火墙严格的场景下UDP 经常被丢包或者直接禁止。这时候可以强制走 TCP在 ffplay 里加一个参数ffplay -rtsp_transport tcp -i rtsp://user:passip:554/Streaming/Channels/101服务端收到 SETUP 消息中的 TCP 请求后会把 RTP 包交错封装在 RTSP 的 TCP 连接里传过来。这个参数在项目联调里几乎天天用建议直接记住。4.3 RTMP 推流服务器搭建与推流参数选择RTMP 推流服务器我推荐 SRS开源、活跃度高一条 Docker 命令就能拉起来docker run --rm -p 1935:1935 -p 1985:1985 -p 8080:8080 \ registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5SRS 默认配置就能接收 RTMP 推流地址是rtmp://localhost:1935/live/livestream。如果你只想快速验证 pushSRS 官方还有公网测试地址rtmp://demo.ossrs.net/live/livestream不过公网地址受网络环境影响我建议还是本地搭一个实测。推流参数选择直接影响延迟和画质。如果你做的是低延迟场景记得加-tune zerolatency关掉 B 帧关键帧间隔设短一点2 秒以内。以 OBS 推流为例码率控制用 CBR 或 VBR 都可以但关键帧间隔务必设小否则播放端首屏等待时间会很难看。RTMP 默认的 buffering 时间也比较大服务器端如果开了 GOP cache延迟会额外增加 0.5~1 秒。做低延迟直播建议关掉 GOP cache或者用 SRS 的低延迟配置模板。聊到 ESP32 推 RTMP我的经验是用 ESP32-S3 OV2640帧率 15fps、分辨率 VGA、H.264 硬编码推 800Kbps 到本地 SRS 完全稳定。要特别注意 ESP32 的 OV2640 输出的是 JPEG做 H.264 编码要么用芯片的 JPEG 流先软编要么选支持直接输出 H.264 的摄像头模组否则 CPU 会扛不住。4.4 GB28181 接入与语音对讲的注意点GB28181 是 SIP RTP PS 封装的组合接入流程比 RTSP 复杂。设备上电后会向平台的 SIP 服务器发送 REGISTER 请求平台收到后回复 401 带认证设备带上认证信息再 REGISTER 一次注册成功。之后设备周期性发心跳平台通过目录查询拿到设备列表。拉流的核心是 INVITE 流程。平台向设备发 INVITESDP 里描述你要接收的媒体类型、编码格式、接收端口。设备回 200 OK 之后就开始往平台的媒体端口推 RTP/PS 流。这个流程里最容易出的问题是 NAT。设备在公网平台在内网设备回的 SDP 里带的媒体地址可能是内网地址双方 RTCP 和 RTP 都到不了。解决方法是平台侧配置公网映射或者设备侧支持在国标配置里设置本机 IP为公网地址。语音对讲是 GB28181 接入里比较高级的功能。我们做过一个项目指挥中心要和现场摄像机对话。这时候平台先给设备发一个双向的 INVITESDP 里同时协商上行和下行音频流。音频编码通常用 G.711A、G.711U 或 G.722设备只支持其中一种平台必须有对应的转码能力。真正跑起来之后对讲延迟一般控制在 500ms 以内才算可用如果延迟过大优先检查是否经过了额外的转码链路以及音频的 jitter buffer 是否设置得过大。5. 常见问题与排查技巧实录5.1 高频问题速查表下面是我在多个项目里遇到的高频问题整理成速查表方便你对照排查。问题现象可能原因排查方法RTSP 拉流 401账号密码/权限不对或鉴权方式不匹配检查摄像头集成协议设置看是否启用了 RTSP 鉴权RTSP 有画面但很卡网络丢包UDP 被限制强制-rtsp_transport tcp对比测试海康只出子码流不出主码流地址里的通道编号写错确认/Streaming/Channels/101和102分别对应主/子码流RTMP 推流延迟越来越大服务器开启了 GOP cache 或播放缓冲过大关闭 GOP cache调低播放端 buffer 时长GB28181 注册成功但拉不到流NAT 导致 RTP 端口不通在设备/平台两侧核对媒体端口映射抓包看 RTP 是否到达GB28181 语音对讲只有单边声音双向流协商失败或音频编码不匹配看 SDP 里 audio 方向和编码类型确保两端一致WHIP 推流偶发黑屏首帧关键帧未及时到达设置推流端关键帧间隔为 1~2 秒确认服务端没有丢弃关键帧WHEP 播放几分钟后花屏UDP 丢包导致 RTP 序列空洞查看 WebRTC 统计考虑切到具备丢包重传的 SFU 或走 TCP 候选这个表不可能覆盖所有情况但排查思路是一致的先确定是信令问题还是媒体问题再看是网络问题还是编码问题。分而治之能省下大量时间。5.2 排查链路与工具我的排查习惯遵循一个固定链路。第一步确认源端是否有流比如摄像头是否在出流用 VLC 或 ffplay 直接打开源地址测试第二步看协议交互是否正常Wireshark 抓包RTSP 就看 OPTIONS/DESCRIBE/SETUP/PLAY 的响应码GB28181 就看 SIP 的 REGISTER 和 INVITE 事务第三步看媒体传输RTP 包是否到达目标端口负载类型和时间戳是否正确。工具方面ffprobe 是我最常用的侦察兵。一条命令能看到编码格式、分辨率、帧率、SPS/PPS 等关键信息ffprobe -v error -show_streams -show_format rtmp://localhost:1935/live/testWireshark 用于协议细节我习惯在过滤器里直接写rtsp || rtp || rtcp或者在 GB28181 场景写sip || ps。如果怀疑是 RTP 丢包可以加一个统计列专门看 RTP sequence number 是否有跳变。Android 端缓存 RTSP 流这种需求如果只是本地播放直接 Media3 就能搞定要是为了断网离线看我一般建议服务端把 RTSP 转 HLS客户端走 HLS 缓存体感会稳很多。5.3 我在项目里总结的三条经验第一老协议的新兼容层投入产出比最高。RTSP 的 TCP 模式、GB28181 的 NAT 兼容、RTMP 的低延迟调参这些“边缘细节”看似不起眼但都是客户现场的高频问题。把这一层做好项目的稳定性会有一个质的提升。第二新协议要选对场景上。WHIP/WHEP 适合浏览器端低延迟互动MoQ 未来适合大规模分发但别指望它们解决设备接入和存量兼容。我在项目里的原则是能用老协议稳住的不乱上新新协议能带来明显体验提升的果断用但要留好降级回老协议的开关。第三协议网关的价值被低估了。很多时候客户说我要 WebRTC实际诉求只是浏览器里低延迟看监控。你不需要把整个系统推翻成 WebRTC只需要在媒体服务器前面加一层网关把 RTSP/GB28181 翻译成 WHEP 即可。这样既满足了体验又把改动控制到最小。说回我自己现在每次拿到流媒体项目我还是会从 RTSP、RTMP、GB28181 的接入稳固性入手把底子打牢再考虑加 WHIP、WHEP 和 MoQ 这些新成员。这不是守旧是因为我知道真正让系统撑住业务、撑住现场复杂环境的往往不是最热门的协议而是那些最扎实的基本功。