回放和实时点播走的是同一套 INVITE，
SDP 里只有一个字面量不同：s= 从 Play 变成 Playback。
但回放多了一整套播放控制：暂停、拖动、倍速——而倍速是要花带宽的。
上一节拿到了「哪段时间有录像」，这一节才是「把它播出来」。 回放是国标里最容易被低估的流程：它看着像点播，实际复杂在「进度」上。 Demo 只差一个字段，但那个字段决定了设备给你实时流还是录像。
一、只差一个字面量
s=Play 是实时，s=Playback 是回放，s=Download 是下载。
设备靠这一个字段判断「你要什么」。
这个设计有个明显的好处：同一套信令、同一套媒体通道，只换一个词。
代价是「很容易写错」——写成 Play 去要录像，设备可能真的给你实时流，而且不报错。
所以抓包时先看 s= 那行，这是回放排障的第一步，比看什么都有用。
回放的请求里还要带一段时间：「从几点播到几点」。
这段时间必须落在检索返回的区间里，否则设备会拒——因为它那里确实没有这段录像。
二、播放控制在 RTSP 里
国标把回放的播放控制交给了 RTSP 的那套方法：
PAUSE 暂停、PLAY 继续、PLAY 带新 Range 就是拖动。
暂停的时候流并不停：设备只是不发了，会话还挂着。
所以「暂停很久」会占用一路会话资源，这一点要注意。
拖动是最容易出问题的一步：平台发一个新的 Range，设备要从那个时刻的最近 I 帧开始发。
如果设备不支持「从任意时刻起播」，就只能从段首开始，用户会觉得「拖了没反应」。
所以验收时要专门测一次「拖到中间」，而且要在录像段的正中间拖，
不在段边界拖——那里拖对了不代表中间也对。
三、倍速是要花带宽的
倍速播放不是「解码器播快点」，是设备按更快的节奏发流。 所以 4 倍速就要 4 倍的带宽。 按一路 4 Mbps 算：2 倍速要 8 Mbps，4 倍速要 16 Mbps。 这解释了一个常见现象——很多设备只支持 2 倍速，不是不想做，是网卡不够。 反过来，慢放（0.5 倍速）不省带宽，因为设备还是按原码率发，只是发得慢， 总流量不变、时间拉长。 这一条在写播放器时很重要：不能假设「慢放就省流量」，带宽预算要按最快的那一档算。
四、动手 Demo：回放和点播，差在哪几个字段
把两份 SDP 的关键三行摆出来对比，看哪个字段不同。 再算倍速播放的带宽账。
live = ["s=Play", "m=video 6000 RTP/AVP 96", "a=sendonly"]
back = ["s=Playback", "m=video 6000 RTP/AVP 96", "a=sendonly"]
for a, b in zip(live, back):
print(a, b, "不同" if a != b else "相同")
base = 4096
for sp in (2, 4):
print(sp, "倍速", base * sp, "kbps",
"一小时录像", 60 // sp, "分钟放完")
实跑输出：
--------------------------------------------------------------------
回放和点播，差在哪几个字段
--------------------------------------------------------------------
**回放和实时点播走的是同一套 INVITE**，
**SDP 里只有一个字面量不同：`s=` 从 `Play` 变成 `Playback`。**
**但回放的请求里还要多带一段时间**——**「从几点播到几点」，这是点播不需要的。**
字段 点播 回放 是否相同
-------------------------------------------------------------------------------------
**`s=`** `s=Play` `s=Playback` **不同**
**`m=`** `m=video 6000 RTP/AVP 96` `m=video 6000 RTP/AVP 96` **相同**
**`a=`** `a=sendonly` `a=sendonly` **相同**
**只有 `s=` 不同**——**设备靠它判断「你要实时流还是录像」。**
**这是个很容易写错的地方**：**写成 `Play` 去要录像，设备可能真的给你实时流。**
**回放多出来的能力是「播放控制」**：
动作 国标做法 说明
-----------------------------------------------------------------------------
**暂停** **RTSP `PAUSE`** **流不断，只是停下来**
**继续** **RTSP `PLAY`** **带 `Range` 指定从哪继续**
**拖动** **RTSP `PLAY` 带新 `Range`** **最常用，也最容易错**
**倍速** **RTSP `PLAY` 带 `Scale`** **2 倍速就是码率翻倍**
**第四行值得算一下**：
2 倍速 = 8192 kbps，一小时录像 30 分钟放完
4 倍速 = 16384 kbps，一小时录像 15 分钟放完
**倍速播放不是「解码器播快点」**，**是设备按更快的节奏发流**——**所以 4 倍速要 16 Mbps 带宽。**
**这就是为什么很多设备只支持 2 倍速：不是不想做，是网卡不够。**
**拖动（SEEK）是最容易出问题的一步**：
**平台发一个新的 `Range`，设备要从那个时刻的最近 I 帧开始发。**
**如果设备不支持「从任意时刻起播」，就只能从段首开始，用户会觉得「拖了没反应」。**
**所以验收时要专门测一次「拖到中间」。**
三行里只有 s= 不同，m= 的端口格式和 a= 的收发方向完全一样。
这是国标设计得比较聪明的一处：回放复用点播的整条通道。
所以「回放播不出来」这件事，九成不是通道问题，而是 s= 写错、或者时间段落在检索结果之外。
倍速那两行说明一件事：2 倍速 8 Mbps、4 倍速 16 Mbps。
如果一路 4 Mbps 的流在千兆网里跑没问题，那四路同时 4 倍速回放就要 64 Mbps——
这个数在设计回放并发时必须算进去。
所以「同时几个人回放」不是一个产品问题，是一个带宽问题：十个人各开 2 倍速，就是八十兆。
30 秒实验
- 算一下：4 倍速回放一路 4 Mbps 的录像，要多少带宽？（16 Mbps）
- 想一下：为什么「拖到中间」比「拖到段首」更能测出问题？
- 想一下：慢放会不会省带宽？（不会）
常见误区
- 以为「回放和点播是两套流程」。 同一套 INVITE，只差
s=一个字面量。 - 以为「倍速是播放器自己加速」。 是设备按更快节奏发流，带宽跟着涨。
- 以为「暂停就不占资源」。 会话还挂着，设备侧资源没释放。
自测三问（点开对答案）
1. 回放和点播在 SDP 里差哪个字段？ —— **`s=`，从 `Play` 变成 `Playback`**。 2. 拖动是怎么实现的？ —— **RTSP 的 `PLAY` 带一个新的 `Range`**，**设备从该时刻最近的 I 帧开始发。** 3. 为什么慢放不省带宽？ —— **设备仍按原码率发，只是发得慢**，总流量不变。下一节讲下载：同一段录像，「边下边看」和「先存下来」差多少时间。
- ☐ （本节完，下一节 10.08.09 历史视音频文件下载）