刚入行做视频或者流媒体的同学最近十有八九会被几个新词绕晕WHIP、WHEP还有 MoQ。WHIP 是 WebRTC 的推流入口协议WHEP 是 WebRTC 的拉流出口协议MoQ 则是把 QUIC 用在媒体分发上的一整套思路三者都长着一张“未来可期”的脸也确实解决了不少浏览器端高延迟、弱网抗丢包的老问题。可我在一线干了这么多年流媒体真实的生产环境从来都不是“新协议替换旧协议”这么简单。到今天我手上维护的几套系统里RTSP、RTMP、GB28181 这些“老伙计”仍然牢牢占着摄像头取流、直播推流、国标平台接入的核心位置想把它拆掉业务立刻停摆。所以这篇东西特别务实聊清楚新协议到底好在哪更要聊清楚为什么老协议还死不了以及新旧两代协议怎么在同一个系统里共存。1. 新协议的价值WHIP、WHEP、MoQ 解决了哪些老问题1.1 把 WebRTC 从“接口难用”变成“随手调用的协议”WebRTC 本身出现得很早P2P、SRTP、ICE、DTLS 这些能力早就成熟了但开发者一直没把它当成可以随便调的普通协议。原因很现实WebRTC 的协商流程太长需要自己管理 SDP、ICE candidate还要自建信令服务器。以前在 Web 端做一套自定义 WebSocket 信令后期生产环境里埋过太多雷。WHIP 的思路就是把这些复杂度包起来客户端只需要向一个 HTTP 端点发送 POST 请求请求体里带上 SDP服务端返回 201同时携带 ICE 信息一个新的 WebRTC 推流会话就建立好了。WHEP 则是对称的拉流侧播放器向 HTTP 端点发 GET 请求拿到 SDP 后直接建立 WebRTC 连接音视频流就进来了。这个设计最大的好处是服务端可以像部署 RTMP 一样简单地部署 WebRTC不用再自研信令服务也不需要在浏览器端集成一堆复杂的 JS 库。延迟可以做到几百毫秒级别抗丢包能力来自 WebRTC 底层的 NACK、FEC 和拥塞控制。这确实是 RTMPHLS 那条老链路做不到的。我实际测过用 WHIP 推到本地 SRS再用 WHEP 在 Chrome 里拉回来端到端延迟可以稳定在 300ms 左右弱网下画面仍然比较平滑。这个体感用老协议组合很难给到。1.2 MoQ把 QUIC 的传输效率搬到大规模分发上MoQMedia over QUIC是 IETF 正在推进的标准它直接基于 QUIC 做媒体分发。QUIC 在 TCP 的基础上解决了队头阻塞问题又在 UDP 上给了用户空间协议的灵活性MoQ 利用这些特性设计了一套可以分发音频、视频、元数据的对象模型。直播场景下MoQ 的典型价值是让 CDN 边缘节点之间用低延迟、高吞吐的方式互相转发甚至还能支持类似观众互相转发的 Mesh 分发。如果说 WHIP/WHEP 解决的是接入和播放的最后一公里MoQ 想解决的则是分发链路本身。目前开源社区已经有 moq-rs、moq-js、mofed 等项目在做原型浏览器端的支持也在逐步推进。但必须说清楚MoQ 到现在还没有一个完全稳定的正式 RFC很多实现还在演进之中。生产环境直接拿它做核心链路的团队要有和标准一起变的心态。我的建议是可以投入精力研究但别急着把核心业务压在它上面。1.3 新协议能解决什么又不能解决什么我没有否定新协议的意思实事求是地说WHIP 让我把 WebRTC 推流接入的时间从一两天压缩到半天WHEP 让播放器的接入变得非常规整MoQ 对大规模、低延迟分发的前景也很诱人。但在真实工程环境里我看到的更普遍的画面是摄像头还是旧款平台还是基于旧协议攒出来的业务要求的是兼容、稳定、可运维而不是“把协议换成新的”。协议选型永远要回答一个问题线上存量设备能不能平滑迁过去如果不能那新旧协议就要并存很久。下面几张表格你能更直观看到各协议的角色差异。协议角色定位延迟表现浏览器原生支持常见场景RTSP设备侧控制媒体中低不支持安防取流、NVR接入RTMP直播推流中不支持主播推流、直播平台GB28181国标信令媒体中不支持安防平台、无人机接入WHIPWebRTC推流极低支持低延迟推流WHEPWebRTC拉流极低支持低延迟播放MoQ媒体分发低实验支持大规模低延迟分发2. RTSP为什么摄像头和安防系统还是离不开它2.1 海康、大华取流地址是怎么拼出来的前阵子看到“海康威视摄像头RTSP地址”还在热搜里说明很多人的第一件事不是搞新协议而是从摄像头里把视频流拉出来。海康威视的取流 URL 一般长这样rtsp://admin:yourpassword192.168.1.64:554/Streaming/Channels/101大华的 URL 则通常是rtsp://admin:yourpassword192.168.1.64:554/cam/realmonitor?channel1subtype0这两个格式本身没多深奥但细节很磨人。不同固件版本可能带不带认证参数子码流用 subtype0 还是 102跨网段时防火墙要不要放行 554 和 RTP 动态端口这些问题我几乎每次接新项目都会遇到一遍。没有对这类 URL 的肌肉记忆你就没法在摄像头选型之初把取流方案定下来。做汇聚平台的时候甚至要专门维护一张“不同品牌设备取流地址模板表”否则每次都是边查文档边联调极度消耗时间。2.2 GStreamer 的 RTSP 服务器和测试流做底层开发的同学更应该关注 GStreamer。GStreamer 自带 gst-rtsp-server 这个库用它可以快速起一个测试用的 RTSP 服务器随时验证 RTSP 接入流程。比如用 gst-launch 起一路测试画面gst-launch-1.0 videotestsrc ! x264enc ! rtph264pay namepay0 pt96 ! rtspclientsink locationrtsp://127.0.0.1:8554/test再用 rtspsrc 拉回来做后续处理gst-launch-1.0 rtspsrc locationrtsp://127.0.0.1:8554/test ! rtph264depay ! avdec_h264 ! autovideosink这里要提醒大家一个常见坑RTSP 是控制协议真正传输画面的是 RTP而 RTP 使用动态端口范围。在 NAT 和防火墙环境下如果媒体端口没放行就会出现“RTSP 握手成功、画面黑屏”的经典症状。先确认本地网络能完整拉到流再去排查应用层逻辑效率会高很多。有一次我帮同事排障他始终怀疑是解码器的问题结果抓包一看RTP 包全被防火墙丢了根本到不了解码器。2.3 “拉流”是安防场景的默认姿势安防网络的典型拓扑是 IPC/NVR 做服务端平台或客户端主动去拉取视频流。这和直播场景里推流为主的模式完全不同。即使 WebRTC 已经能提供低延迟播放也不可能让每一台老摄像头都立刻学会 WHIP。很多摄像头固件压根不支持 WebRTC但一定支持 RTSP 或 SDK。业务交付的时候用 RTSP 兼容所有存量设备是最稳妥的选择。如果把“拉流”和“推流”搞混架构上会很难受。比如在 WebRTC 场景里大家总想让摄像头主动推流到服务器但老摄像头的固件逻辑就是“等你来拉”。这时候正确的做法是在服务器侧做一次 RTSP 拉流转 WebRTC 的封装把“主动拉取”变成“被动等待播放器连接”而不是硬逼摄像头改行为。2.4 安卓端缓存 RTSP 流移动场景里的现实需求还有一个热搜词是“安卓缓存RTSP流”。移动端直接解码 RTSP 流很麻烦常见的做法是用 VLC 内核、ijkplayer 之类的库做软解或者把 RTSP 转成 HLS/MP4 后缓存在本地。所谓缓存更多是为了解决弱网下的卡顿。实测下来单纯把 RTSP 转成 TS 分段文件再配合本地缓存播放能比直接硬解流畅很多但代价是延迟变高。如何在缓存和实时性之间取舍是每一套移动端视频方案的必修课。我的建议是移动端观看实时监控时优先做“边下边播”和“按需预取”不要一次性把整段缓存下来。比如只预取当前 GOP 的前几个关键帧画面就能快速出来同时不会因为缓存堆积让延迟越来越大。这个细节看着小但实际体验差别非常大。3. RTMP直播推流里绕不开的老大哥3.1 为什么平台还留着一套 RTMP 推流如果你打开任何一个直播平台的后台上传指引大概率还能看到 RTMP 推流地址。原因无他生态和兼容性太稳了。OBS 默认支持 RTMPFFmpeg 一条命令就能推流传统 CDN 分发链路对 RTMP 的支持也最成熟。虽然 HLS 在播放侧几乎统治了移动端但推流侧大家还是习惯把信号送到 RTMP ingest server然后在服务端转封装成 HLS、WebRTC 或者其他格式下发给播放器。我自己搭过很多次 RTMP 推流服务器最省事的组合是 SRS 或者 nginx-rtmp-module。SRS 在直播场景里更顺手它自带 HTTP-FLV、HLS、WebRTC 转发能力从 RTMP 接收之后可以直接转出多种播放协议。这让“RTMP 推流、WebRTC 播放”成了很多低延迟应用的标准路径推流侧沿用最普及的 RTMP播放侧用 WHEP 或兼容 WebRTC 的播放器协议平滑过渡业务又快又稳。3.2 自己搭一个可用的 RTMP 测试环境建议你本地起一套 SRS别老是拿公网测试地址打架。核心步骤大概是用 Docker 起 SRS 服务映射好 1935RTMP、1985HTTP API、8080HTTP 服务等端口。用 FFmpeg 推一路测试画面ffmpeg -re -f lavfi -i testsrcduration300:size1280x720:rate30 \ -c:v libx264 -preset veryfast -tune zerolatency -g 30 \ -c:a aac -f flv rtmp://127.0.0.1/live/test用 FFplay 或 VLC 拉流验证ffplay rtmp://127.0.0.1/live/test这套环境可以用来测试客户端、转封装逻辑甚至做简单压力测试。注意推流时的-g 30表示 GOP 设为 30 帧也就是 1 秒一个关键帧对低延迟很有帮助。把-tune zerolatency加上能明显减少首屏等待时间。3.3 实测可用的 RTMP 测试地址长什么样网上常有人搜“rtmp测试地址”有时也会看到类似rtmp://camlive.iqilu.com/live/streamdelivery1这样的公网测试流。这种地址只能当临时连通性测试用因为来源可能随时失效时延和可用性都不是你能控制的。真正要稳定测试还是建议自己起一套 SRS或者用 FFmpeg 本地反复推拉。公网测试流的价值只在于验证“你的网络能不能出去”靠它做产品验证基本等于给自己埋坑。3.4 从 RTMP 到 WHIP迁移路上要注意什么如果团队打算把推流侧从 RTMP 迁到 WHIP我的建议是不要一次性删掉 RTMP。保留一个统一的 ingest 网关同时接收 RTMP 和 WHIP后端再统一按内部流格式处理。这样老推流工具不用改新推流工具也能陆续接进来。而且要特别注意码率控制、GOP 设置、音视频同步这些通用问题换了协议并不会自动解决过去弱网推流不稳的毛病。码率控制这方面RTMP 时代很多推流端喜欢用 CBR恒定码率到 WebRTC 场景下反而要更依赖拥塞控制允许码率动态变化。如果团队习惯了 CBR 的老思路接到 WHIP 上容易把带宽占满造成卡顿。理解各家协议在码率控制上的差异比单纯换个推流端口重要得多。4. GB28181国标平台的硬骨头也是很多项目的入场券4.1 搞清楚 GB28181 到底在做什么GB28181 的正式名称是《公共安全视频监控联网系统信息传输、交换、控制技术要求》。坦白讲对非安防出身的开发来说这个国标的体验是痛苦的信令走 SIP媒体走 RTP还要处理设备注册、目录查询、实时预览、录像回放、云台控制、语音对讲等一系列流程。但做安防平台、视频汇聚、执法记录仪和无人机接入你基本绕不开它。经典的 GB28181 流程一定要形成肌肉记忆设备向 SIP 服务器注册服务器下发目录查询设备返回通道信息用户想查看某路视频就通过 INVITE 请求向设备要 SDP然后设备把 RTP 媒体流推到指定端口。不少人把 GB28181 想成“RTSP 的国标版”方向就错了它是一整套信令加媒体的联合流程。国标平台里的“域”“设备 ID”“通道 ID”这些概念也跟普通流媒体系统很不一样刚上手时容易晕。4.2 语音对讲GB28181 里最容易踩坑的能力热搜里有条“gb28181语音对讲”说明这个功能问的人很多。语音对讲就是平台向设备发起双向音频会话设备把采集到的声音通过 RTP 传给平台平台也能把音频下发给设备。看协议文档不复杂但实际联调时编码格式、采样率、打包间隔稍有不对声音就是不出来或者单向无声。我建议调试时先把音频格式固定到 G.711A/PCMA、8000Hz、单声道、20ms 一包等链路通了再做更高阶的音频编码。还有一个经常被忽略的细节语音对讲和实时视频是两个独立的会话端口也不一样。很多设备对同时支持视频和音频会话的数量有限制平台侧要设计好会话管理否则对讲一开视频就断或者反过来。这类问题抓包能看出来但提前设计好会话容量比事后排障痛快得多。4.3 大疆哪些机型支持 GB28181实测意味着什么做无人机视频接入时会看到“支持 GB28181 的大疆机型主要包括经纬 M300 RTK、M200 系列、御 Mavic 2 行业版”这类说法。这意味着这些无人机可以直接把视频画面注册进国标平台而不是靠第三方推流盒子转发。无人机场景最大的特点是移动、链路不稳定、经常需要临时起降GB28181 在这样的场景下要能稳定跑起来底层的注册重连、RTP 端口协商和流媒体转发都得做扎实。我在项目里实测过无人机通过 GB28181 接入后画面延迟整体可控但断线重连是一个重点问题。无人机飞到信号弱的地方链路容易闪断如果注册和重连机制写得不好画面会长时间黑屏。理想的状态是信令层能快速重注册媒体层能自动重新协商端口用户端感觉到的只是短暂卡顿而不是一直加载转圈。这个体验差别在应急项目里就是“能用”和“不能用”的差别。4.4 GB28181 客户端怎么选自研还是用开源自研 GB28181 客户端并不轻松信令侧要处理 SIP 会话媒体侧要有 RTP 接收和转发能力还要兼容不同设备厂商的“私有口味”。如果只是开发联调可以用开源方案快速搭一套信令服务和流媒体服务社区里常见的 WVP-GB28181-Pro 就是一个不错的参考。如果要在生产环境大规模接入建议找商用方案或者把开源方案吃透后再做二次开发。我的经验是永远不要在项目截止前一周才第一次打开 GB28181 的开源代码去研究。国标项目联调周期通常比预想的长因为每家的设备多多少少都有点偏差。提前把信令流程、媒体端口分配、心跳超时这些逻辑理清楚联调时才能从容应对。5. 新旧并存的架构才更接近真实生产5.1 统一网关让 RTSP、RTMP、GB28181 和 WebRTC 一起工作我目前比较推荐的做法是做一个“协议网关层”。这一层负责把所有输入协议统一转成内部媒体流再按需输出成目标协议。简单说就是对摄像头/NVR优先 RTSP 取流接不进来的走 GB28181 注册。对推流端保留 RTMP同时开放 WHIP 入口。对播放端优先 WebRTC/WHEP兼容 HLS 做备用。需要第三方系统对接时再输出 RTSP、RTMP 或 GB28181 给下游。这样做的好处是底层设备迭代不影响上层业务上层业务也不会因为某个设备不支持新协议而瘫痪。缺点是一开始要多写一点胶水代码但这个成本放到长期运营里非常值。5.2 一种经过验证的落地方案拿一个具体项目举例有一批海康摄像头一个 GB28181 的指挥平台还有一堆浏览器观看端。我们当时的落地链路是摄像头通过 RTSP 拉流用自研服务转成 WebRTC 流浏览器用 WHEP 直接播放。同时把同一路流转成 RTMP推给传统指挥平台保证老平台也能看到画面。部分没有 RTSP 可用的设备则通过 GB28181 注册进平台再由平台统一转发。系统上线后播放延迟从原来 HLS 的 5-8 秒降到 1 秒内老平台完全不受影响两边并行非常稳。这个案例说明新老协议不是对立关系而是互补关系。网关层一开始比较简陋只是做个转封装后来逐渐加了录制、截图、告警等能力反而成了整个视频中台的核心。5.3 参数调优延迟、缓存与 GOP 的关键经验GOP 设置低延迟播放侧建议把 GOP 控制在 1-2 秒左右比如 30 帧码流设 gop30丢包恢复更快但太小的 GOP 会增加码率需要平衡。缓存策略RTSP 拉流转 WebRTC 时不要让 GStreamer 或 FFmpeg 的缓存堆积过大超过 200-300ms 就和低延迟目标冲突。端口与 NATRTP 动态端口、DTLS/SRTP 端口都要在防火墙上明确放行否则会出现各种诡异的“能握手不能出流”。音视频同步转封装时注意时间戳不要依赖系统时钟统一用流内时间戳做同步。这些参数看着零碎但几乎每个线上问题最终都能落到这几项上。有一次系统出现播放延迟越来越大的问题排查了半天最后发现是转封装进程里缓存设置过大导致积压越来越多。把缓存调小之后延迟立刻恢复正常。6. 我踩过的坑和你大概率也会踩的坑6.1 几个“看起来没问题但生产上崩过”的现场先说一个最典型的RTSP 握手成功、画面黑屏。排查下来十有八九是 RTP 动态端口没放行。记住放行 TCP/UDP 554 不等于放行 RTP 端口。如果你看到 SDP 里协商了一大段动态端口而防火墙策略只开了 554那画面大概率出不来。再说一个RTMP 推流到 CDN 延迟越拉越大。原因通常是推流端编码器 B 帧开得太大、GOP 太长导致边缘节点缓存越来越多。把 B 帧关掉、GOP 调小一点立刻改善。用 FFmpeg 推流时-bf 0是关 B 帧很多同学容易忽略。GB28181 的坑也很多。设备注册成功但目录查询不到大概率是域或设备 ID 对不上语音对讲没声音先查编码格式和 RTP 负载类型。类似的问题文档写得再细不实测一遍你永远不知道厂商是否真的按标准来。6.2 一套可以反复使用的排查工具ffprobe/ffplay看协议流是否可拉、可放。gst-launch-1.0快速搭流水线验证编解码和转封装。tshark/ Wireshark抓包看 SIP、RTP、RTMP 握手定位问题。SRS本地起一套 RTMP/WHIP 服务验证推拉流。WVP-GB28181-Pro本地起一套 GB28181 信令平台联调设备。其实大多数流媒体诡异问题根因都出在网络端口、时间戳、编码参数这三者上。先确认这三样再去怀疑协议实现能省下很多时间。我见过太多人一碰到黑屏就怀疑解码器结果抓包一看全是网络问题。6.3 给后来者的实际操作建议我的个人经验是接到一个视频项目时先做协议盘点。现有的摄像头、NVR、无人机分别支持哪些协议播放端是浏览器还是 App对延迟有多高要求是否需要和国标平台互通。把这些列出来后你会发现大多数场景根本用不上“非此即彼”的争论。建议团队里至少留两个能在五分钟内写出 RTSP 取流、RTMP 推流、GB28181 注册的人而不是所有人都在研究 WHIP。新协议确实香但存量业务的稳定交付靠的还是你对老协议的细节理解足够深。最后再分享一个小技巧无论是测试 WHIP、WHEP还是调 RTSP/RTMP始终在本地搭一套可控的测试环境。前阵子我帮同事定位一个问题就是因为拿公网测试地址做验证链路里的中转和缓存都不可控排查了一天没结果后来拉回本地在同一个网段里用 SRS 起服务、用 ffprobe 验证半小时就找到问题了。流媒体这东西眼见为实能本地复现的问题就不会是玄学。