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

PS 面向存储、TS 面向传输，差别全在「定长」这一条上。 选型看传输环境可靠不可靠，不看哪个更新。

📝 本节和前面几节的关系

5.4.1 拆层、5.4.2 串流程，这一节把 PS 与 TS 的取舍钉死。 5.5 开始逐个字节拆 TS 的包结构。

一、核心差别只有三条

① 包长：TS 固定 188 字节，PS 变长。 这一条是根，后面两条都是它的推论。 ② 丢包容忍：TS 能靠同步字节找回边界，PS 丢一个就断。 ③ 典型用途：TS 用于广播、直播、HLS 切片；PS 用于 DVD 与本地文件。

「定长」这一条决定了一切： 定长才能「丢了一个包还能对齐」，而广播环境（尤其无线）本来就一定会丢。 所以数字电视、DVB、HLS 全都用 TS。

反过来看，定长也有代价： 每 188 字节固定 4 字节头，占比 2.1%，一分都省不掉。 而 PS 的 pack 头虽然大，但摊到几百 KB 上就微不足道了。 所以「省字节」这件事上，PS 其实更优。

二、为什么 HLS 选 TS 而不是 PS

三个理由，按重要性排： ① 切片是独立的传输单元：每个 .ts 文件都要能单独播， 所以开头必须重发 PAT／PMT。 TS 的表结构天生支持「随时插入声明」，PS 不支持。 ② 网络会丢包：HTTP 虽然可靠，但 CDN 环节都可能有损坏。 TS 的定长对齐让「局部损坏」不致于全片报废。 ③ 生态成熟：所有硬件解码器、所有播放器都认 TS， 换格式的成本极高。

第 ① 条其实最硬： HLS 的整个架构建立在「切片可独立解码」之上，而 PS 的设计前提是「从头到尾连续」，两者的假设是冲突的。

顺便提一句：HLS 也允许用 fMP4 代替 TS。 fMP4 靠 #EXT-X-MAP 指定初始化段，比 TS 省一点开销， 但兼容性不如 TS——老设备只认 TS。

三、一个常见误解

「TS 比 PS 先进」——不对，它们只是场景不同。 PS 在「不会丢的环境」里更省： 没有 188 定长的填充浪费，头部开销也更小。 所以 DVD 用 PS，蓝光也用 PS 的变种。

选型看的是「传输环境可靠不可靠」，不是「哪个更新」。 这个判断方式在工程上很通用： 先问「会不会丢」，再问「要不要随机访问」，最后才问「省不省字节」。

还有一个更常见的误解是「TS 就是 HLS 专用」。 不是——TS 比 HLS 早十几年， 它最早是数字电视广播（DVB）的传输格式， HLS 只是「借来用」而已。

四、动手 Demo：PS 与 TS 小结——存储用 PS，传输用 TS

把三条差别做成表，再逐条算「省字节」与「抗丢包」的取舍。 算完会发现 PS 更省，但 TS 能活下来。

rows = [("包长", "固定 188 字节", "变长"),
        ("丢包容忍", "能，靠同步字节找回", "不能，丢一个就断"),
        ("典型用途", "广播、直播、HLS", "DVD、本地文件")]
for a, b, c in rows:
    print("%-8s TS: %-18s PS: %s" % (a, b, c))

print()
# 同样 1 MB 有效载荷，两种封装的固定开销
data = 1024 * 1024
ts_pkts = (data + 183) // 184
ts_over = ts_pkts * 4
ps_over = (data // (64 * 1024) + 1) * 20   # 每 64 KB 一个 pack 头
print("1 MB 有效载荷：")
print("  TS 需要 %d 包、头开销 %d 字节（%.2f%%）"
      % (ts_pkts, ts_over, ts_over * 100.0 / data))
print("  PS 需要约 %d 个 pack 头、开销 %d 字节（%.3f%%）"
      % (ps_over // 20, ps_over, ps_over * 100.0 / data))
print("  结论：省字节 PS 赢，抗丢包 TS 赢")

实跑输出：

--------------------------------------------------------------------
PS 与 TS 小结——存储用 PS，传输用 TS
--------------------------------------------------------------------
**① 核心差别只有三条**

  项           TS                       PS
  ----------------------------------------------------------
  包长         固定 188 字节            变长
  丢包容忍     能，靠同步字节找回       不能，丢一个就断
  典型用途     广播、直播、HLS 切片     DVD、本地文件

  **「定长」这一条决定了一切：**
  **定长才能「丢了一个包还能对齐」**，**而广播环境（尤其无线）本来就一定会丢。**
  **所以数字电视、DVB、HLS 全都用 TS。**

**② 为什么 HLS 选 TS 而不是 PS**

  **三个理由，按重要性排：**
  **① 切片是独立的传输单元**：**每个 .ts 文件都要能单独播，所以开头必须重发 PAT／PMT。**
  **TS 的表结构天生支持「随时插入声明」，PS 不支持。**
  **② 网络会丢包**：**HTTP 虽然可靠，但 CDN 环节都可能有损坏。**
  **TS 的定长对齐让「局部损坏」不致于全片报废。**
  **③ 生态成熟**：**所有硬件解码器、所有播放器都认 TS，换格式的成本极高。**

**③ 一个常见误解**

  **「TS 比 PS 先进」——不对，它们只是场景不同。**
  **PS 在「不会丢的环境」里更省**：**没有 188 定长的填充浪费，头部开销也更小。**
  **所以 DVD 用 PS，蓝光也用 PS 的变种。**
  **选型看的是「传输环境可靠不可靠」，不是「哪个更新」。**

TS 头开销 2.17%，PS 只要 0.03%——差七十倍，但绝对量只有 22 KB 对 320 字节。 (data + 183) // 184 是向上取整的写法，少一个包就算错。 PS 每 64 KB 一个 pack 头是估值，真实值取决于编码器的打包粒度。

30 秒实验

  1. 把 data 改成 10 MB，看两种开销的百分比——不变，因为两者都是线性的比例。
  2. 把 PS 的 pack 粒度改成 4 KB，看 PS 开销——涨到 0.5%，已经接近 TS 了。
  3. 加一行「能随机访问吗」，自己填——TS 能靠 PAT／PMT 随时插入，PS 要从头扫，这就是 HLS 选 TS 的核心理由。

常见误区

  1. 「TS 更先进」——只是场景不同，PS 在可靠环境里更省。
  2. 「TS 是 HLS 发明的」——比 HLS 早十几年，源自数字电视广播。
  3. 「HLS 只能用 TS」——也能用 fMP4，但兼容性差一些。
自测三问（点开对答案） 1. PS 与 TS 的三条核心差别是什么？ —— **包长定不定、能不能容忍丢包、典型用途**；根因是定长。 2. HLS 为什么选 TS 的最硬理由？ —— **切片要能独立解码**，TS 支持随时插入 PAT／PMT，PS 不支持。 3. 省字节的角度谁更优？ —— **PS**，TS 的 2.17% 固定开销省不掉。

相关笔记