一、先说清「流」和「文件」的区别

文件是一件完整的东西：有开头、有结尾、有明确的大小。 流是一段还在路上的东西：不知道什么时候完，也不知道会不会断。

这个区别看着抽象，落到代码上非常具体：

最后一行最容易踩坑：读文件读到 EOF 就是结束； 读流读到「暂时没数据」，不代表结束，可能三秒后又来了。 把流当文件读的程序，会在第一次网络抖动时就以为播完了。

二、三种做法，差别在「什么时候开始解」

同一个 MP4，有三种播法，起播时间和体验完全不同。

渐进式下载是中间态：它也用 HTTP，也是一个普通文件，但只要播放器支持「边下边解」就能提前开始。 它的命门在 moov——MP4 的索引块放在文件尾时，不下载完整个文件就找不到每帧的偏移，只能干等。

真流式和前两个的根本区别是「没有文件」：服务端边采边编边发，客户端边收边解边画， 中间任何一环都没有「完整的片子」这个概念。 监控就是这一类——摄像头不会先把一小时录像准备好再给你。

三、缓冲是个两难，不是越大越好

缓冲的作用是拿「延迟」换「抗抖动」。 缓冲越长越不容易卡，但也越迟钝——换台、拖进度、对讲，全都变慢。

两个场景的目标正好相反：

监控这一行有个硬指标叫「端到端延迟」：从镜头前有人走过，到屏幕上看见他，中间隔多久。 这个数在行业里通常要求 300 毫秒以内，超过一秒就影响判断。 所以监控用的缓冲普遍只有一两帧，宁可偶尔卡一下也不攒。

四、为什么 RTSP 要拆成两个协议

RTSP 只管「说话」，RTP 只管「送货」。 这两件事的节奏差了几个数量级：信令一秒几条，媒体一秒几十上百个包。

硬把它们塞进一个协议会很难受： 信令要可靠（丢一条 SETUP 就播不了），所以要 TCP； 媒体要快（晚到的帧没用），所以宁可丢也不等，用 UDP。

分开之后各司其职：RTSP 跑在 TCP 上保证不丢，RTP 跑在 UDP 上保证不慢。 代价是两边要互相对账——这就是 RTCP 的活：报告丢了多少、抖成什么样，让发送端能调整。

这一拆，就是本章三个小节的全部内容：1.2 到 1.5 讲 RTSP，1.6 讲 RTP，1.7 讲 RTCP。

五、监控这个场景的特殊性

监控和「看视频」是两件不同的事，虽然都用 RTSP。

这几条差异直接决定了技术选型： 路数多，所以必须能批量管理——这是 ONVIF 存在的理由（第七章）； 常年不断，所以心跳与重连必须做扎实——这是 D08 那个坑； 画面不动，所以编码器要能压得极低——这是 H.264 的长 GOP 与智能编码。

看懂这张表，就知道这本书为什么这么排：前四章打底（协议、播放、采集、编码），第五章拼成系统， 后六章讲怎么管起来。

六、动手 Demo：一小时的视频要搬多少字节

这段先把「码率 → 容量 → 起播时间」这条账算一遍，再看缓冲长度能扛多久的抖动。 所有数字都是代码算的，没有一个手填。

# 一小时的容量：码率 × 3600 秒 ÷ 8
for name, mbps in ((u"1080p", 4.0), (u"4K", 16.0)):
    one_min = mbps * 60 / 8.0            # MB
    T([name, u"%.1f Mbps" % mbps,
       u"%.1f MB" % one_min,
       u"%.2f GB" % (one_min * 60 / 1024)], [0, 0, 0, 0])

# 起播等待：整片下完 vs 缓冲三秒（带宽按 20 Mbps）
size_mb = 4.0 * 3600 / 8.0              # 1080p 一小时
print(size_mb * 8 / 20.0)                # 下载完要等多少秒

# 缓冲能扛几次断流：缓冲秒数 ÷ 单次断流时长
print(3 * 1000 // 200)                   # 3 秒缓冲扛 200 毫秒断流

实跑输出：

--------------------------------------------------------------------
一小时的视频要搬多少字节
--------------------------------------------------------------------
**流媒体先是一笔带宽账，然后才是协议问题。**
  算不清这笔账，就选不出协议：4 Mbps 的流走公网，和走一根百兆内网，是完全两个世界。

  画质             码率          一分钟       一小时      一天
  --------------------------------------------------------------------
  标清 480p        1.0 Mbps      7.5 MB       0.44 GB     10.5 GB
  高清 720p        2.5 Mbps      18.8 MB      1.10 GB     26.4 GB
  全高清 1080p     4.0 Mbps      30.0 MB      1.76 GB     42.2 GB
  超清 4K          16.0 Mbps     120.0 MB     7.03 GB     168.8 GB

**1080p 看一小时，搬的是 1800 MB，也就是 1.76 GB。**

**这笔账怎么决定「能不能边下边播」：**

  做法                     要等多久起播     算出来的数
  -------------------------------------------------------------------
  下载完再播               整片下完         720 秒（12.0 分钟）
  边下边播，缓冲 3 秒      3 秒             只要 1.5 MB 就能起播
  边下边播，缓冲 10 秒     10 秒            只要 5.0 MB 就能起播
  边下边播，缓冲 30 秒     30 秒            只要 15.0 MB 就能起播

  带宽按 20 Mbps 算。
  **同一片源，一个等 720 秒，一个等 3 秒**——差的就是「要不要 moov／要不要整片」这件事。

**缓冲能扛多久的抖动，也是算得出来的：**

  缓冲      能扛断流     断一次 200 毫秒，能扛几次
  ----------------------------------------------------
  1 秒      1 秒         5 次
  3 秒      3 秒         15 次
  10 秒     10 秒        50 次

  **缓冲不是越大越好**：它换抗抖动能力，代价是换台和拖进度条的延迟。
  直播要的是「延迟小」，点播要的是「不卡」，两个目标在缓冲长度上正好相反。

第一张表里「一天」那一列很吓人：1080p 连存一天是四十多 GB， 一台 NVR 挂八路就是三百多 GB 一天。 这就是监控必须用「长 GOP + 低码率」的根本原因——不是编码器不想给高画质，是硬盘算不过来。

第二段那个「下载完要等 704 秒」是本节的核心数：同样一段片子，一个等将近十二分钟，一个等三秒。 差的不是网络，是「什么时候允许开始解码」这条策略。

第三段别只看结果：缓冲三秒能扛十五次 200 毫秒的断流，听着很稳， 但这是「断流总时长短于缓冲」的前提下。 真要连续断五秒，多长的缓冲都没用——那是断线，不是抖动。

30 秒实验

1. 找一段你手机拍的视频，看它的码率，算一小时要占多少 GB。
2. 用「整片大小 ÷ 你的带宽」算出下载后播要等多久，再和缓冲三秒对比。
3. 把 200 毫秒换成 2 秒，重算一次缓冲能扛几次——体会「抖动」和「断线」的界线在哪。

常见误区

1. 以为流媒体就是「视频放在网上」。 放网上只是能下载，流媒体的关键是「不等整片」，这需要协议、 缓冲、丢包处理一整套。
2. 以为缓冲越大越稳。 缓冲换的是抗抖动能力，代价是延迟； 监控场景下延迟是硬指标，缓冲只能给一两帧。
3. 以为 RTSP 会传输视频数据。 RTSP 只传信令，画面数据全在 RTP 里——把这两件事混一起， 看抓包就永远看不懂。

下一节进 RTSP 的门：先把这个协议是什么、URL 怎么拼、支持哪些方法说清楚。

• ☐ （本节完，下一节 01.02.01 RTSP支持）

相关笔记

• RTSP支持
• 🎬 流媒体直播原理及应用 · 30 课
• 🎬 音视频原理及应用 · 26 课
• 📹 视频监控与国标 · 索引