H5 直播 SDK 怎么选：ZEGO、阿里云、腾讯云在浏览器里的真实差异

H5 直播选型，先回答两个问题：主播是不是也在浏览器里开播，你能接受”低延迟”变成一个单独计费的增值项吗。这两个答案基本决定了选谁，剩下的才是延迟和价格。

本文中的版本、浏览器兼容性和接口均为 2026-10-30 快照，取自各家官方文档、npm 元数据；所有延迟数字都是厂商宣称，口径不同，不能直接横比。

1. H5 直播的三条硬约束，来自浏览器而不是厂商

原生 App 的对比文可以直接比参数表。浏览器不行，因为你能用的东西是被平台限死的。

第一，能解码的只有三条路。 原生 <video>（HLS/MP4）、MSE（HTTP-FLV、fMP4）、WebRTC。iOS 上 MSE 不可用，微信的 WKWebView 也没有——这意味着 iOS 微信里 FLV 方案直接出局，flv.js 也不行。这一条会淘汰掉一半”方案对比”里的推荐。

第二，WebRTC 强制 HTTPS。 getUserMedia 只在安全上下文里可用，RTS 拉流域名同样要求 HTTPS，否则起播失败或静默黑屏。本地调试可以用 localhost / 127.0.0.1，线上没有例外。

第三，自动播放受策略限制。 浏览器要求 muted 或用户手势。首帧黑屏、有画面没声音，八成不是 SDK 的问题，是没处理自动播放回调。

所以任何”我们支持 H5 直播”的说法，都要追问三个限定：哪个浏览器、哪个协议、什么编码。下面三节都按这个口径写。

2. 对比三家的产品结构

这是本文和多数横评最大的分歧点。三家在 H5 端不是同一类产品在比参数，而是三种结构。

2.1 ZEGO：RTC 原生，低延迟是默认值

ZEGO 的 Web SDK（npm 包 zego-express-engine-webrtc）本身就是 WebRTC 推拉流 SDK。createStream 采集、startPublishingStream 推流、startPlayingStream 拉流，一套接口同时覆盖”主播开播”和”观众观看”。

超低延迟（官方叫 L3）不需要换产品：拉流时把 resourceMode 设为 2 就走 L3，厂商宣称端到端 600–1000ms，需要联系技术支持开通。走 CDN 拉流则把 resourceMode 设为 1。

代价在 CDN 播放这一侧。ZEGO 的 CDN 播放靠一个独立的播放器插件 ZegoExpressPlayer，只能 <script> 引入，没有 npm 包，且只支持 HTTP-FLV，不支持 HLS。想在 Safari 上播 CDN 流，只能退回原生 <video> + m3u8。另外 CDN 转推地址只支持 rtmp，Web 端也拿不到转推状态回调。

一句话：ZEGO 的强项在推，弱项在 CDN 播。

2.2 阿里云：CDN 原生，低延迟是增值服务 RTS

阿里云视频直播的默认形态是 CDN：推流交给 OBS、移动端 SDK 或服务端，观众用 Aliplayer（npm aliyun-aliplayer，已内置 RTS 插件）播 HLS / FLV 地址。

要低延迟，得单独开通 RTS（超低延时直播）：推流和拉流是两个 SDK 包（aliyun-rts-sdk），推流包和拉流包的版本号甚至不对应，发版节奏也不同，地址协议头是 artc://。浏览器推流只有这一条路——阿里云没有”标准直播的网页推流”。

RTS 的编码限制要提前看清楚：视频 H.264、音频 Opus，不支持 B 帧、不支持 AAC。源流不满足就开 H5 自动转码（去 B 帧、AAC 转 Opus），转码另计费。延迟分两档：亚秒档厂商宣称 400–800ms，半秒档 200–400ms，半秒档需要 WHIP 推流 + 阿里云播放器，浏览器兼容范围更窄。

一句话：阿里云的强项在播，推流是 RTS 的附赠能力。

2.3 腾讯云：CDN 原生 + 快直播，一个播放器吃三种地址

腾讯云云直播同样是 CDN 原生，但播放器 TCPlayer 做得更”全能”：同一个实例可以喂 flv://、m3u8、webrtc:// 三种地址，快直播（LEB）就是其中的 WebRTC 通道，厂商宣称 300–1000ms（官方 FAQ 口径 <800ms）。

它最实用的一点是降级是内置的：浏览器不支持 WebRTC 时，传进去的 webrtc:// 地址会自动转成 HLS 播放；连接重试超限（状态码 -2004）、播放中解码失败（-2005）也会触发同样的降级。这一段逻辑腾讯替你写了，阿里云和 ZEGO 都要自己实现。

代价有三处：Web 推流基于 WebRTC 封装，音频是 Opus，要喂给标准直播播放就得转 AAC，产生转码费；WebRTC 只支持 H.264，源流含 B 帧会被自动转码去 B 帧（额外延迟 + 费用）；单个推流域名默认限制 1000 路并发推流，可工单提额，主播特别多的业务要提前确认。

一句话：腾讯的强项在省事。

2.4 结构对照

3. Web 端能力事实表

这张表能读出四件事。

推流能力是第一个分水岭。 三家都能在浏览器里推流，但入口完全不同：ZEGO 是主 SDK 的一个接口，阿里云是 RTS 的一部分，腾讯是 WebRTC 封装。如果”网页开播”是核心场景，阿里云的方案天然绑定了 RTS 的延迟档和编码限制——你不开 RTS，就没有浏览器推流。

拉流是第二个分水岭，方向反过来。 阿里云和腾讯的播放器覆盖 FLV/HLS/低延迟三档；ZEGO 的低延迟拉流很强，但 CDN 播放是短板——插件只支持 FLV，HLS 得自己用 <video> 播。只在 PC 上播没问题，一旦要覆盖 Safari 和 iOS 微信，就得写两套播放逻辑。

延迟数字不可横比。 “600–1000ms”和”<800ms”和”300ms–1s”不是同一套量法：有的算端到端，有的算播放器起播后稳定态，有的取的是网络 RTT 加缓冲。同一家厂商不同页面的数值也不一致。要比，只能在同一个测试环境里自己量。

并发限制是硬约束，不是宣传语。 腾讯单推流域名 1000 路，是能查到的明确数字；ZEGO 宣称的是千万级并发观看，那是 CDN 分发侧的能力，不是推流侧。这两者不要混为一谈，看的人多和开播的人多，是两种压力。

四、同一个”网页开播”，三家怎么写

ZEGO 的最小链路：

import { ZegoExpressEngine } from 'zego-express-engine-webrtc';

const zg = new ZegoExpressEngine(appID, server);
await zg.loginRoom(roomID, token, { userID, userName }, { userUpdate: true });

// 主播端
const localStream = await zg.createStream({ camera: { audio: true, video: true } });
await zg.startPublishingStream(streamID, localStream);

// 观众端：resourceMode = 2 走 L3，= 1 走 CDN
await zg.startPlayingStream(streamID, { resourceMode: 2 });

阿里云的最小链路（注意推流地址协议头是 artc://）：

const pusher = AliRTS.createClient();
const support = await pusher.checkPublishSupport(); // isH264EncodeSupported / isWebRTCSupported …

const localStream = await pusher.createStream({ audio: true, video: true, screen: false });
localStream.play(document.querySelector('#local'));
await pusher.publish('artc://push.example.com/live/stream1', localStream);

// 观众端
const player = AliRTS.createClient();
const remoteStream = await player.subscribe('artc://play.example.com/live/stream1');
remoteStream.play(document.querySelector('#remote'));

腾讯云播放侧最短：

const player = new TCPlayer('player', {
  sources: [{ src: 'webrtc://play.example.com/live/stream1' }],
  autoplay: true,
  live: true,
});
// 浏览器不支持 WebRTC 时，webrtc:// 会自动转为 HLS 播放，无需额外代码

三段的差异不在代码量，而在你依赖了几个产品：ZEGO 一套 SDK，阿里云要同时理解 RTS 推流包和拉流包，腾讯云要区分 TCPlayer（播放）和 Web 推流封装（开播）。

五、计费口径

三家的计费口径根本不同，直接比单价是错的。

比价时容易漏掉三项：

第一，转码。 低延迟链路和 CDN 兜底链路并存时，转码是必然项。阿里云 RTS 的 H5 自动转码、腾讯云 WebRTC 转 AAC，都不在流量费里。

第二，录制和截图。 直播业务几乎都会要回放，这项按输出时长另算，和观看量无关。

第三，资源包的抵扣边界。 阿里云的通用流量包不能抵扣 RTS 费用，得单独买 RTS 资源包；腾讯云的流量包可以抵扣快直播流量。同样的”买了 1TB 包”，实际覆盖范围完全不同。

一个可执行的折算方法：把观看时长 × 码率折成流量，和 ZEGO 的分钟计价放在同一量纲上比，再把转码、录制按实际用量加回去。不要拿两家的单价直接对除。

六、一天验证清单

功能和延迟都能在一天内测出来，前提是方法对。

浏览器矩阵（必测六项）：Windows Chrome、macOS Safari、Android Chrome、iOS Safari、微信浏览器。企业微信单独加一项，如果业务要覆盖。

延迟测量：用同一个时钟源。直播画面里放一个毫秒级时间码，手机拍屏对比本地时钟，或两端同时打开同一网页时钟。不要用”感觉”，也不要信控制台的统计字段。

弱网：DevTools 的 Network 限速只能模拟带宽和 RTT，模拟不了丢包和抖动。要测卡顿，用系统级弱网工具或代理。

必须记录的六个指标：首帧时间、稳定态延迟、卡顿率、重连次数、降级触发次数、实际产生的转码时长（对账单）。

并发验证：腾讯云要专门测单域名 1000 路推流上限是否够用；另外两家要测的是同一房间内的推流路数上限。

降级验证：手动禁用 WebRTC（或用不支持的环境），看是自动切协议、报错、还是黑屏。这一项最能看出厂商的实现质量。

七、看场景推荐

参考资料：
ZEGO《Web JS 超低延迟直播概述》
阿里云《Web RTS SDK 简介》
腾讯云《快直播和标准直播区别》