波仔
🎬 第七章 流媒体开源库简介
📄 一句话概括

同一路流，不同浏览器能给的播放能力完全不同。 Safari 原生支持 HLS，其余都靠 hls.js。

📝 本节和前面几节的关系

7.7.3 讲完了音频，这一节回到「谁能播什么」这个现实问题。 7.7.5 与 7.7.6 拆 API 层面的细节。

一、三种播放能力

① HLS 原生支持：只有 Safari 与移动端 Safari 有，其它都没有。 ② MSE 播 FLV：Chrome、Edge、Firefox 都支持，Safari 不支持。 ③ WebRTC：全平台原生支持，这是它最大的优势。

所以「网页里播直播」的最省事组合是： HLS 加 hls.js 兜底绝大多数场景， 要低延迟就上 WebRTC，但得多一套信令与 TURN 服务器。

HTTP-FLV 在网页里其实很尴尬： 它必须依赖 MSE，而 MSE 在移动端 Safari 上限制很多。 所以它更适合「PC 端加客户端」的组合。

二、为什么 Safari 是特例

因为 HLS 是苹果提出来的。 它在 iOS 上把 HLS 做成了系统级能力， 所以 Safari 不用任何库就能播 m3u8。

反过来，Safari 对 MSE 的支持一直很保守： 桌面版支持、移动版限制多。 所以 flv.js 在 iPhone 上基本不能用—— 这不是库的问题，是底层不给这个能力。

一个现实结论： 面向 iPhone 用户的直播，HLS 是唯一稳妥的选择。 要更低延迟，只能用 WebRTC，不能指望 HTTP-FLV。

三、选型时该问哪三个问题

① 观众主要在什么设备上？ 有 iPhone 就必须支持 HLS，这一条能直接定方向。 ② 能忍多少延迟？ 十几秒能忍就 HLS，一两秒就要 WebRTC 或 HTTP-FLV。 ③ 规模多大？ 上万人在线就该优先考虑能被 CDN 缓存的方案。

三个问题里第 ① 条最硬，因为它不由你决定。 第 ② 条可以谈（业务能不能接受延迟）。 第 ③ 条可以花钱解决（多买带宽、多建边缘）。

四、动手 Demo：浏览器支持——能力矩阵决定你选什么协议

把五种浏览器对三项能力的支持列成矩阵。 再由矩阵推出「面向 iPhone 只能选 HLS」这个结论。

caps = {
    "Chrome": (0, 1, 1), "Edge": (0, 1, 1), "Firefox": (0, 1, 1),
    "Safari": (1, 0, 1), "移动端 Safari": (1, 0, 1),
}
print("浏览器          HLS原生  MSE播FLV  WebRTC")
for b, (h, m, w) in caps.items():
    print("%-15s %5s %8s %7s"
          % (b, "是" if h else "否", "是" if m else "否", "是" if w else "否"))

print()
hls = sum(1 for v in caps.values() if v[0])
mse = sum(1 for v in caps.values() if v[1])
rtc = sum(1 for v in caps.values() if v[2])
n = len(caps)
print("HLS 原生 %d/%d，MSE 播 FLV %d/%d，WebRTC %d/%d"
      % (hls, n, mse, n, rtc, n))

实跑输出：

--------------------------------------------------------------------
浏览器支持——能力矩阵决定你选什么协议
--------------------------------------------------------------------
**① 三种播放能力**

  浏览器            HLS 原生     MSE 播 FLV     WebRTC
  --------------------------------------------------------
  Chrome            否           是             是
  Edge              否           是             是
  Firefox           否           是             是
  Safari            是           否             是
  移动端 Safari     是           否             是

**② 这张表怎么用**

  **① 只有 Safari 原生支持 HLS，其它浏览器要靠 hls.js。**
  **② HTTP-FLV 全平台都不原生支持，必须靠 flv.js 走 MSE。**
  **③ WebRTC 全是原生，这是它最大的优势。**

  **所以「网页里播直播」的最省事组合是：**
  **HLS 加 hls.js 兜底绝大多数场景，**
  **要低延迟就上 WebRTC，但得多一套信令与 TURN 服务器。**

  **HTTP-FLV 在网页里其实很尴尬：**
  **它必须依赖 MSE，而 MSE 在移动端 Safari 上限制很多。**
  **所以它更适合「PC 端 + 客户端」的组合。**

HLS 原生只有 2/5，但它的覆盖面靠 hls.js 补足了。 MSE 播 FLV 是 3/5，缺的正是 Safari 两个版本。 WebRTC 是 5/5，这是它唯一的「全平台」优势。

30 秒实验

  1. 加一行「IE11」，看三项能力——全否，这就是为什么老系统只能用 Flash 或 HLS。
  2. 把「移动端 Safari」的 MSE 改成 1，看结论变不变——即使改成支持，实际限制还是很多（比如不能后台播）。
  3. 统计「至少支持一种」的浏览器数，看是不是全部——是，说明任何浏览器都能播，只是要选对协议。

常见误区

  1. 「所有浏览器都原生支持 HLS」——只有 Safari。
  2. 「flv.js 在 iPhone 上能用」——移动版 Safari 的 MSE 限制太多。
  3. 「WebRTC 兼容性最差」——正好相反，它是全平台原生。
自测三问（点开对答案） 1. 哪种浏览器原生支持 HLS？ —— **Safari 与移动端 Safari**，因为 HLS 就是苹果提出的。 2. iPhone 上要低延迟只能选什么？ —— **WebRTC**；HTTP-FLV 在移动版 Safari 上靠不住。 3. 选型先问哪三个问题？ —— **观众设备、能忍多少延迟、规模多大。**

相关笔记