从 RTSP/RTMP 到 WHIP、WHEP 与 SRT：实时音视频协议越多，为什么机会反而越清晰？

​做实时音视频很多年以后，我们越来越明显地感受到一件事情：这个行业并没有像很多人曾经预测的那样，最终被某一种协议统一。

RTSP 没有因为 RTMP 的普及而消失，RTMP 没有因为 WebRTC 出现而退出市场，WebRTC 也没有替代所有低延迟传输方案。现在又出现了 SRT、WHIP、WHEP、WebTransport、Media over QUIC（MoQ）等新的技术路线。协议看起来越来越多，技术栈似乎也越来越复杂。

但真正把这些协议做过一遍之后，我们的感受反而发生了变化：这未必意味着实时音视频行业越来越混乱，而更可能意味着这个行业正在从“寻找一种万能协议”，走向更加清晰的协议分工。

对长期做实时音视频底层技术的人来说，这并不一定是坏消息。

恰恰相反，当设备、网络、浏览器、云平台、机器人、无人机、工业视觉等场景越来越复杂时，单一协议越来越难解决所有问题。谁能够真正理解不同协议背后的取舍，谁就更容易理解下一阶段的市场需要什么。

一、只有真正把这些协议做出来，才能理解它们为什么会同时存在

早期做 RTSP/RTMP 播放和推流时，我们很容易按照协议划分产品：RTSP 用于摄像机和监控设备，RTMP 用于直播推流，播放器负责把流拉下来并解码显示。

后来随着应用场景扩展，这种简单分类开始不够用了。

一个机器人项目可能既需要局域网 RTSP，又需要通过 4G/5G 跨公网回传；一个工业系统可能既需要 Native 客户端多路低延迟播放，又希望浏览器能够直接观看；一个移动采集端可能要把摄像头视频直接送入 WebRTC 平台；而远距离视频回传又会遇到公网抖动和随机丢包。

这也是我们做完 SRT 推送和 SRT 播放之后感受很深的一点。SRT并不是简单换一个 URL 的“新协议播放器”，它背后代表的是另一种网络设计思路：允许给传输保留一定的时间窗口，用重传和缓冲去换取复杂公网环境下更稳定的媒体连续性。SRT 官方的 TSBPD 机制本身就会引入一个可控制的接收延迟，使数据有机会抵抗网络抖动并完成必要的恢复。

而真正完成 WHIP 推流、WHEP 播放，再拿它们和 RTSP、RTMP、SRT 放在一起测试时，又会发现另外一种完全不同的体验：WebRTC 原来并不一定只能隐藏在一套复杂的 RTC 系统内部，它也正在变成一种可以通过标准接口接入的实时媒体能力。

这可能才是这一轮协议变化最值得关注的地方。

二、WHIP 的意义，不只是“又多了一种 WebRTC 推流方式”

WHIP 已经在 2025 年正式成为 RFC 9725，它定义了一种基于 HTTP 的简单方式，用于把 WebRTC 内容送入流媒体服务或者 CDN。

如果只看协议流程，WHIP 并没有重新发明 WebRTC。底层依然是我们熟悉的 ICE、DTLS、SRTP、RTP/RTCP 等体系。

它真正重要的变化发生在上面一层。

过去 WebRTC 最大的问题之一，是不同平台几乎都有自己的信令。一个平台使用 WebSocket，一个平台使用 HTTP API，还有平台把房间、用户、鉴权、SDP 交换全部封装进自己的私有协议。

这意味着即使大家底层都叫 WebRTC，系统之间也未必能够直接互通。

WHIP开始试图解决这个问题：

Camera / Screen / Encoder
            │
            │
          WHIP
            │
            ▼
   Realtime Media Service

看起来只是多了一个标准化 HTTP 接口，但从直播行业来看，它很重要。

因为过去 RTMP 能够形成庞大生态，很大程度上并不是因为它永远拥有最先进的传输机制，而是因为它形成了一个清楚的边界：

编码器负责推，服务器负责收。

WHIP正在尝试把这种简单关系带到 WebRTC 世界。

因此，WHIP真正值得关注的并不是“延迟能做到多少毫秒”，而是 WebRTC 正在拥有一个越来越通用的 Ingest 接口。

三、WHEP可能让播放侧发生更大的变化

如果说 WHIP 是把实时视频“送进去”，那么 WHEP 解决的就是怎样标准地“拿出来”。

截至 2026 年 8 月，WHEP 已经更新到 draft-ietf-wish-whep-04。IETF 对它的定位很明确：让 WebRTC Viewer 可以通过简单 HTTP 协议从流媒体服务、CDN 或 WebRTC Transmission Network 获取内容。

它带来的影响可能比推流端更广，因为通常一个视频源对应的播放器数量远多于推流端。

尤其值得关注的是浏览器。

过去做行业视频系统，经常需要面对一个非常现实的问题：设备输出 RTSP 或 RTMP，但浏览器并不能天然直接播放，于是中间必须增加协议转换、JavaScript 播放方案或者 Native 客户端。

WHEP提供了另一种可能：

RTSP / RTMP / Other Source
            │
            ▼
      Media Service
            │
           WHEP
            │
      ┌─────┼─────┐
      ▼     ▼     ▼
   Browser Browser Browser

因此，当我们真正实现并测试 WHEP 以后，一个感受会非常明显：

浏览器低延迟播放正在越来越像一种基础能力，而不是少数 RTC 平台的专属能力。

这也意味着未来专业 Native 播放器需要体现的价值会更加深入。仅仅“把视频播出来”正在逐渐变得不够，真正具有行业价值的会越来越偏向多实例、硬件解码、H.265、录像、截图、原始音视频数据、AI 对接、Unity3D/工业软件融合以及长时间稳定运行等深层媒体能力。

这并不是播放器市场消失，而是播放器的价值边界正在往更专业的位置移动。

四、SRT让我们重新理解“低延迟”这三个字

过去谈低延迟，行业里非常容易只比较一个数字：100ms、200ms、500ms，似乎数字越小协议越先进。

真正做过复杂网络测试以后，会发现这其实过于简单。

如果局域网不丢包、RTT 很低，直接 UDP 的传输延迟当然可以非常低。但真实项目面对的是移动网络、跨地域公网、Wi-Fi 干扰、5G 波动、随机丢包和网络抖动。

此时问题变成了：

当网络开始变差以后，延迟还能不能控制住？视频还能不能连续？

SRT给出的答案非常有工程味道：不是幻想网络永远不丢包，而是通过 ARQ、接收延迟窗口以及相关控制机制，在一定时间范围内尝试恢复数据。SRT同时提供了非常丰富的 socket 统计能力，可以在发送端和接收端观察链路运行状态。

这让我们对低延迟的理解从单一指标变成了至少三个指标：

Latency + Reliability + Continuity。

延迟、可靠性和画面连续性必须一起看。

尤其是在机器人、无人机、移动采集、远程巡检等场景中，“偶尔最低 80ms”未必比“持续稳定在某个可接受延迟区间”更有价值。

这也是 SRT 与 WHIP/WHEP 可以同时存在的重要原因。它们本来就在解决不同的问题。

五、WHIP/WHEP 与 SRT 越成熟，协议之间的边界反而越清楚

把这些协议真正放到一起看，会发现并不存在一个简单的“谁淘汰谁”。

RTSP非常适合大量摄像机、NVR、工业设备和局域网视频源；RTMP拥有非常深的直播生产和推流生态；SRT擅长复杂公网条件下的可靠媒体传输；WHIP/WHEP则正在把 WebRTC 的低延迟能力和标准化媒体入口连接起来。

可以简单理解为：

这里最值得思考的一点是：

协议越多，反而越证明实时音视频市场已经足够复杂，没有任何一种协议能够解决所有问题。

这对长期积累底层音视频能力的厂商并不一定是挑战，反而可能形成新的机会。

因为真正的行业客户最终不会为了使用一个协议而做项目，他们只关心自己的问题有没有解决：摄像机怎么接进来？跨公网怎么传？弱网怎么办？浏览器能不能看？Native 客户端能不能多路播放？能不能录像？能不能拿到视频帧做 AI？机器人操控时延迟和稳定性如何？

协议只是这些问题下面的一层实现。

六、WebTransport值得关注，但它和 WHIP/WHEP 不是一个层面的东西

随着 QUIC/HTTP/3 发展，WebTransport 又开始频繁出现在实时音视频讨论中。

WebTransport 最吸引人的地方，是它可以向 Web 应用提供多条数据流、可靠传输以及 Datagram 等更灵活的通信能力。W3C 正在继续推进 WebTransport API 标准化，2026 年工作组已经就进入 Candidate Recommendation Snapshot 达成发布共识。

但 WebTransport 和 WHIP/WHEP 其实并不应该直接比较。

WHIP/WHEP 背后是完整的 WebRTC 实时媒体体系，而 WebTransport更像一个现代传输工具箱：

         WebTransport
              │
       ┌──────┴──────┐
       │             │
    Streams       Datagram
       │             │
       └──────┬──────┘
              │
           HTTP/3
              │
             QUIC

视频怎么封装、关键帧怎么表达、音视频如何同步、什么时候重传、什么时候丢弃、拥塞后如何降低码率，这些并不是 WebTransport 本身替应用解决的问题。

所以从实时音视频行业看，WebTransport真正有价值的地方并不是“出现了一个新的播放器协议”。

更重要的问题是：

QUIC/WebTransport 上面最终会生长出什么样的实时媒体协议？

这自然把视线引向 MoQ。

七、MoQ的出现说明实时媒体仍然远没有走到技术终点

Media over QUIC（MoQ）可能是接下来几年实时媒体领域最值得观察的标准化工作之一。当前 IETF MoQ 工作组仍在持续推进 MOQT，目标是利用 QUIC/WebTransport 构建基于发布/订阅和 Relay 的媒体传输体系。

它和传统 RTP/SRT 一个很有意思的区别，是越来越强调媒体“对象”的概念，而不是把所有事情都停留在 Packet 层面。

对于实时视频来说，这种思想很有价值。一个已经错过播放时间的数据包，即便最终可靠送达，也可能已经失去价值；而关键帧或者新的媒体对象显然应该拥有更高优先级。

于是下一代媒体网络开始思考：

重要而且还来得及的数据
        ↓
      优先传

已经过时的数据
        ↓
      可以放弃

这与传统“所有数据都应该尽量可靠到达”的网络思想存在明显区别。

它并不意味着 MoQ 一定会迅速替代 WebRTC、SRT 或 RTSP，但至少说明一个事实：

实时媒体的传输模型本身仍然在持续演进。

这个行业远没有进入“协议已经定型，剩下只是做应用”的阶段。

八、做过的协议越多，越容易发现真正有价值的是协议背后的共同能力

从 RTSP、RTMP 到 SRT，再到 WHIP/WHEP，真正深入实现以后会发现，虽然协议不同，最终绕不开的问题其实高度一致。

都是在处理：

• 采集；
• 编码；
• 时间戳；
• 音视频同步；
• 网络抖动；
• 丢包；
• 缓冲；
• 关键帧；
• 解码；
• 渲染；
• 录像；
• 异常恢复；
• 网络状态；
• 资源占用。

协议只是把这些问题重新组合。

例如 RTSP 播放长期积累下来的低延迟缓冲经验，并不会因为换成 WHEP 就完全没有价值；RTMP 推流中积累的采集编码和外部音视频输入能力，同样可以迁移到 WHIP；做 SRT 时建立的弱网指标意识，又会帮助理解 WebRTC 中 RTT、Jitter、Packet Loss、NACK 等数据到底意味着什么。

因此，协议数量增加到一定程度以后，会出现一个很有意思的变化：

新协议带来的不再只是开发成本，也开始产生技术复利。

做过一种协议，可能只是一个模块。

真正理解过多种协议以后，看到的开始是整个实时媒体系统。

九、市场真正变化的，是客户越来越不愿意被某一种协议绑住

过去客户可能会直接提出：“我要一个 RTSP 播放器。”

今天越来越多项目的问题变成：

“现场设备是 RTSP，但总部希望浏览器低延迟看。”

“机器人跨公网回传，用什么协议更稳？”

“我们平台提供 WHIP 地址，移动端能不能直接推？”

“服务器提供 WHEP，Native 客户端能不能播放？”

“SRT 在一定丢包率下为什么还这么流畅？”

这类问题背后其实透露出了一个明显趋势：

客户真正购买的已经越来越不是某个协议，而是解决实时媒体链路问题的能力。

这对已经长期积累 RTSP/RTMP 播放、推流、转发、录像、轻量级媒体服务，再逐渐接触 SRT、WHIP/WHEP 等不同技术体系的产品来说，是一个非常值得重视的市场变化。

因为协议越分化，客户自己解决全部问题的成本反而越高。

设备厂商很难同时深入 WebRTC、SRT、RTSP；

机器人厂商也不应该把大量研发资源消耗在各种音视频协议细节上；

工业软件开发者真正关心的是画面、数据和业务，而不是 ICE、SRTP、ARQ 或 QUIC。

专业实时音视频技术存在的价值，反而因此更加清晰。

十、AI编程越强，底层音视频能力的价值反而要重新理解

这两年还有一个无法忽略的变化，就是 AI 编程正在大幅降低普通应用开发的门槛。

写一个 HTTP 服务、做一个管理后台、调用一个播放器、搭一个简单媒体服务器，越来越容易。

但实际测试 SRT、WHIP/WHEP 后会发现，真正困难的问题并没有因此消失。

为什么同样是 H.264，在不同设备上表现不同？

为什么丢包 5% 有的链路仍然很流畅，有的马上花屏？

为什么同一个 WHEP 地址，两个播放器的实际体验并不完全一样？

为什么码率、GOP、RTT、Jitter 和 Packet Loss 组合以后，会形成完全不同的端到端延迟？

这些问题不是写出几千行代码就自动解决的。

它们依赖的是长期工程实践形成的判断。

这也让我们越来越相信：未来应用层代码可能越来越便宜，但真正经过大量设备、网络和场景验证的实时媒体底层能力，反而会变得更加稀缺。

十一、协议越来越多，对长期做实时音视频的人反而可能是更好的时代

如果从十年前看今天，可能会觉得实时音视频行业变得太复杂了。

RTSP、RTMP、GB28181、SRT、WebRTC、WHIP、WHEP、QUIC、WebTransport、MoQ……

但换一个角度看，这恰恰说明实时视频正在进入越来越多行业。

过去主要是直播和视频会议，现在则出现机器人、无人机、数字孪生、工业巡检、远程操控、智慧交通、车载视频、AI视觉和各种边缘设备。

不同场景需要不同的网络模型，自然会产生不同的协议。

所以我们现在看这些协议，心态已经和过去不太一样。

不是看到一个协议，就担心：

“它会不会替代我们以前做的东西？”

而是开始考虑：

它解决了什么以前没有解决好的问题？

RTSP让设备视频容易接入；

RTMP推动了互联网直播；

SRT解决复杂公网中的可靠实时传输；

WHIP让 WebRTC 推流拥有更标准的入口；

WHEP让 WebRTC 播放逐渐摆脱私有信令；

WebTransport把 QUIC 的现代传输能力带到 Web；

MoQ则开始探索下一代基于 QUIC 的媒体分发模型。

当这些东西同时发展时，对真正理解音视频底层的人而言，并不是路越来越窄，而是路正在越来越多。

结语：真正的机会，往往来自已经做过足够多的“旧东西”

做实时音视频时间越长，越容易理解一个看似矛盾的现象：

新协议不断出现，但旧协议并没有消失。

原因并不复杂。协议背后不是技术潮流，而是真实存在的设备、网络和业务场景。

数以亿计的摄像机仍然需要 RTSP；成熟直播生产体系仍然离不开 RTMP；复杂公网推动了 SRT；WebRTC 的产业化又催生了 WHIP/WHEP；而 QUIC、WebTransport 和 MoQ 则代表着行业仍然在寻找更适合下一代互联网的实时媒体模型。

因此我们现在看 WHIP、WHEP、SRT、WebTransport 和 MoQ，已经不太会把它们理解成一次简单的“新旧协议替代”。

更像是一幅逐渐展开的实时媒体版图：

              实时音视频

                   │
       ┌───────────┼───────────┐
       │           │           │
    设备接入      公网传输     实时网络
       │           │           │
   RTSP/RTMP      SRT      WHIP / WHEP
                               │
                               ▼
                    QUIC / WebTransport
                               │
                              MoQ

谁最终成为主流，并不需要现在急着下结论。

真正重要的是，当行业开始从单一协议走向多协议并存时，长期积累下来的播放器、推流、编解码、弱网、渲染、录像、转发和跨平台能力，并不会因为某个新协议出现而失效。

它们反而成为理解下一种协议最快的起点。

过去做过的每一个模块，看起来是在解决当时的问题；当积累足够多以后，它们开始共同构成理解整个实时音视频市场的坐标系。

而这也许正是这一轮 WHIP、WHEP、SRT、WebTransport 与 MoQ 快速演进，带给 SmartMediaKit 最大的启发：

协议一直在变，场景一直在扩展，但市场始终需要有人把复杂的实时音视频问题真正解决掉。

只要这个需求还存在，行业的发展越快，新的机会就越多。

​