波仔
🎬 第五章 HLS流媒体协议
📄 一句话概括

越偏单向广播、观众越多，越适合 HLS；越要双向互动，越不适合。 点播几乎没有理由不用它。

📝 本节和前面几节的关系

5.1.3 算清了延迟代价，这一节拿这个代价去对照真实场景。 5.2 开始钻细节，从 m3u8 的文件格式讲起。

一、场景与延迟容忍度

把常见场景按「能忍多少延迟」排一排，结论就很清楚： 演唱会与赛事直播 10~30 秒，常用 HLS。 在线教育大班课 6~15 秒，也常用。 电商带货 3~6 秒，更偏 HTTP-FLV，因为主播要看到「观众刚说的话」，延迟差一秒体感就差很多。 视频点播对延迟没有要求，几乎必用。 视频会议与连麦要小于 0.5 秒，只能选 WebRTC。

规律：越偏「单向广播」、观众越多，越适合 HLS。 越偏「双向互动」、延迟要求越狠，越不适合。

注意「观众多」这一条不是绝对的： 小规模也能用 HLS，只是它的优势发挥不出来。 选型时真正卡住人的往往不是规模，而是延迟。

二、起播时间怎么估

假设切片 4 秒、客户端先下 3 个切片再开播，四步的开销是： 取 m3u8 约 50 毫秒——几 KB，一次往返。 取 3 个切片约 150 毫秒——并行下，每个几十 KB。 解封装首帧约 30 毫秒——先找 PAT／PMT，再找关键帧。 解码首帧约 50 毫秒——硬件解码更快，软件要慢一倍。

算下来 300 毫秒左右就能出画面，看起来不错。 但这是「切片都已经存在服务器上」的情况。

直播时切片是边生成边发的，所以你还要等「最新的那个切片被切完」。 这一段才是真正的大头，正好等于一个切片时长。 所以「起播 300 毫秒」和「延迟 4 秒」是两回事，别混着说。

三、为什么点播几乎必用

因为点播对延迟没有要求，而 HLS 的优点全都对上了： ① 切片是静态文件：可以直接扔到对象存储，成本极低。 没有人看的老片，存着几乎不花钱。 ② 支持拖动：跳到任意时间点就是「取那个切片」。 不需要服务端算偏移，也不需要 range 请求之外的支持。 ③ 多码率切换：换个 m3u8 就行，不用重新协商。

还有一条不那么显眼但很实用的优点： 切片的生成是离线的，可以先跑一遍内容审核再上线。 直播做不到这一点，这也是点播架构和直播架构的根本差别之一。

四、动手 Demo：为什么大平台几乎都用它

把五种场景的延迟容忍度与 HLS 的实际延迟摆在一起对照。 再算一遍起播的四步开销，看「300 毫秒」是靠什么凑出来的。

scenes = [
    ("演唱会／赛事", 10, 30, "HLS 常用"),
    ("在线教育大班课", 6, 15, "HLS 常用"),
    ("电商带货", 3, 6, "偏 HTTP-FLV"),
    ("视频点播", 0, 999, "几乎必用 HLS"),
    ("视频会议／连麦", 0, 1, "只能 WebRTC"),
]

# HLS 在 4 秒切片、回溯 3、缓冲 1 时的延迟区间
hls_lo, hls_hi = 4 * 3, 4 * 4
print("场景            能忍下限  能忍上限  HLS 能进吗")
for name, lo, hi, hint in scenes:
    ok = "能" if hls_lo <= hi else "不能"
    print("%-14s  %8d  %8d  %s（%s）" % (name, lo, hi, ok, hint))

print()
steps = [("取 m3u8", 50), ("取 3 个切片", 150),
         ("解封装首帧", 30), ("解码首帧", 50)]
for k, v in steps:
    print("  %-12s %4d 毫秒" % (k, v))
print("  合计 %d 毫秒（不含等切片生成）" % sum(v for _, v in steps))

实跑输出：

--------------------------------------------------------------------
应用场景——为什么大平台几乎都用它
--------------------------------------------------------------------
**① 场景与延迟容忍度**

  场景                 典型延迟        是否选 HLS
  ----------------------------------------------------------
  演唱会／赛事直播     10~30 秒        常用
  在线教育大班课       6~15 秒         常用
  电商带货             3~6 秒          少用，偏 HTTP-FLV
  视频点播             无所谓          几乎必用
  视频会议／连麦       小于 0.5 秒     不用，选 WebRTC

  **规律很清楚：越偏「单向广播」、观众越多，越适合 HLS。**
  **越偏「双向互动」、延迟要求越狠，越不适合。**

**② 起播时间怎么估**

  假设切片 4 秒、客户端先下 3 个切片再开播：

  环节            耗时         说明
  ------------------------------------------------------
  取 m3u8         50 毫秒      几 KB，一次往返
  取 3 个切片     150 毫秒     并行下，每个几十 KB
  解封装首帧      30 毫秒      找 PAT/PMT 再找关键帧
  解码首帧        50 毫秒      硬件解码更快

  **算下来 300 毫秒左右就能出画面，看起来不错。**
  **但这是「切片都已经存在服务器上」的情况。**
  **直播时切片是边生成边发的，所以你还要等「最新的那个切片被切完」。**
  **这一段才是真正的大头，正好等于一个切片时长。**

**③ 为什么点播几乎必用**

  **因为点播对延迟没有要求，而 HLS 的优点全都对上了：**
  **① 切片是静态文件**：**可以直接扔到对象存储，成本极低。**
  **② 支持拖动**：**跳到任意时间点就是「取那个切片」。**
  **③ 多码率切换**：**换个 m3u8 就行，不用重新协商。**

判据写成了「HLS 下限能不能塞进场景上限」——12 秒塞不进电商的 6 秒，所以那一行判「不能」。 四步合计正好 280 毫秒，加上 DNS 与 TCP 握手才是常说的「300 毫秒」。 点播那行写成上限 999 是个取巧，表示「没有延迟要求」，不是真的 999 秒。

30 秒实验

  1. 把切片改成 2 秒，看电商那行判定怎么变——延迟降到 6~8 秒，还是压不进 6 秒，但已经接近。
  2. 把「取 3 个切片」的 150 毫秒改成 600 毫秒，看合计——这就是弱网下的真实起播时间。
  3. 加一行「安防监控」，自己填能忍多少秒——一般能忍 1~2 秒，所以不选 HLS。

常见误区

  1. 「起播快就等于延迟低」——两回事，起播是首帧时间，延迟是画面落后多少。
  2. 「小规模直播不能用 HLS」——能用，只是优势不明显。
  3. 「点播用 HLS 是因为延迟低」——正好相反，是因为延迟无所谓。
自测三问（点开对答案） 1. 选 HLS 最该看哪两个条件？ —— **延迟能忍几秒、观众规模多大**；规模大、延迟能忍就选它。 2. 起播 300 毫秒和延迟 4 秒有什么区别？ —— **起播是首帧前的时间，延迟是画面落后直播源的时长**，两者不冲突。 3. 点播为什么几乎必用 HLS？ —— **切片即静态文件、可拖动、多码率切换零成本**，还能离线审核。

相关笔记