COMP5416 Week 08 多媒体网络讲课总结

Posted on In , Word count in article: 5.7k Reading time ≈ 21 mins.
COMP5416 Week 07–08 多媒体网络详解（讲义跨两周）。三类多媒体应用、音频采样量化与视频码率计算、空间/时间编码与 MPEG、流式存储视频的连续播放约束与客户端缓冲 Q(t) 递推、UDP / HTTP / DASH 三种流媒体方式、CDN 的 DNS 重定向与节点选择、Netflix 案例、VoIP 的时延要求与固定/自适应播放时延（EWMA 估计 d_i、v_i）、FEC / 低质量冗余流 / 交织三种丢包恢复、RTP 首部字段与时间戳计算；文末附 W8 TCP lab（滑动窗口序号空间、Reno 拥塞窗口图）的完整解答。

COMP5416 Week 08 讲课总结：Multimedia

课程：COMP5416/COMP4416 — Advanced Network Technologies，Semester 2 2026 讲师：Professor Vincent Gramoli 来源：讲义 W7-Multimedia.pdf（53 页，Canvas 标注 "Weeks 7 and 8 - Multimedia Lecture Slides"，文件放在 Week 8 文件夹）+ tutorial W8-TCP-lab.pdf / W8-TCP-lab-solution.pdf。本周没有转录稿。 教材：Kurose & Ross 9th ed. —— 讲义末页写的是 "Chapter 3 … Sections 2.5"（印刷混乱），实际对应第 2.6 节（视频流与 CDN）以及旧版教材的多媒体网络一章。

本周覆盖：多媒体概述 → 流式存储视频（缓冲、UDP/HTTP/DASH、CDN、Netflix）→ VoIP（播放时延、丢包恢复）→ RTP。 讲义大纲 p2 列了 "RTP/SIP"，但 SIP 实际放在 Week 10 讲义开头，见 Week 10。

Week 7 的实验（socket 编程）和期中反馈另见 Week 07 总结。 本周的 tutorial 练的是 Week 06 TCP（tutorial 比讲课晚），解答放在本文第八部分。

第一部分：多媒体基础

一、三类多媒体应用（讲义 p4）

类型 特点 例子
流式存储音视频 可以边下边播（不必下载完整文件）；存在服务器上，所以能以快于播放的速度传输（意味着客户端要缓存） YouTube、Netflix、Hulu
会话式 IP 语音/视频 人与人交互，对时延容忍度很低 Skype
流式直播音视频 实时产生 体育赛事直播

三者对时延的要求递增：存储视频可以缓冲好几秒；直播允许几秒延迟；会话式要求 < 150 ms 级别。

二、音频的数字化（讲义 p5）

步骤 说明
采样 模拟信号按固定速率采样：电话 8000 次/秒；Spotify 音乐 44100 次/秒
量化 每个样本四舍五入到有限个值，例如 个值
编码 每个量化值用比特表示，256 个值需要 8 bit
量化误差 原始模拟值与量化值之差

码率 = 采样率 × 每样本比特数：

电话：这就是语音的

三、视频的码率（讲义 p6–7）

视频 = 以恒定速率显示的图像序列（如 24 帧/秒）；每帧是像素阵列（如 480×640）；每像素 RGB 三色，每色 8 bit。

太大了！

所以必须编码压缩：利用图像内部和图像之间的冗余减少比特数。

编码类型 原理 讲义例子
空间编码（帧内） 一行 N 个相同颜色像素，不发 N 个值，只发「颜色值 + 重复次数 N」 类似游程编码
时间编码（帧间） 不发完整的第 帧，只发它与第 帧的差异 运动补偿
标准 用途 码率
MPEG-1 CD-ROM 1.5 Mbps
MPEG-2 DVD 3–6 Mbps
MPEG-4 常用于 Internet < 1 Mbps

码率分类：CBR（恒定码率） 和 VBR（可变码率）。讲义后面的缓冲模型都假设 CBR 播放。

第二部分：流式存储视频

四、流的基本过程与挑战（讲义 p9–10）

视频录制（如 30 帧/秒）→ 发送 → 经网络时延 → 接收 → 播放。流式：客户端在播前面的同时，服务器还在发后面的。

挑战：

挑战 说明
连续播放约束 一旦开始播放，播放时序必须与原始时序一致
网络时延可变（jitter） 所以需要客户端缓冲来满足播放要求
客户端交互 暂停、快进、跳转
丢包与重传 视频分组可能丢失、被重传

五、客户端缓冲与播放时延（讲义 p11–13）

客户端缓冲 + 播放时延：补偿网络附加的时延和时延抖动。

情况 后果
播放时延太小 某个分组在该播放时还没到 → 缓冲下溢（buffer underflow），无法按时播放
增大播放时延 下溢更少
权衡 初始播放时延越大越稳，但用户要等越久才能开始看

六、缓冲的数学模型（讲义 p14–16）

符号： - ：可变的填充速率（网络送来的速率） - ：恒定播放速率（CBR） - ：缓冲填充量；：缓冲大小 - ：开始播放的时刻

过程： 1. 开始前先填缓冲，直到 2. 开始播放 3. 之后 随 变化而变化， 保持恒定

递推式：

就是缓冲下溢。

平均填充速率 与播放速率 的关系（必考结论）

条件 结果
缓冲最终会被抽空 → 视频卡住，直到缓冲重新填满
缓冲不会空，前提是初始播放时延足够大，能吸收 的波动

小算例（自己构造）

单位/秒， ， 依次为 2, 2, 1, 0, 3, 2（ ）。比较两种开播时刻：

1 2 3 4 5 6
， 2 4 5 3 4 4
， 2 2 1 0（下溢） 1 1
  • ： ， ， （ 仍只填充）， ， ， —— 全程没有下溢。
  • ： ， ， ， → 下溢，视频卡顿。

同样的网络、同样的 ，只是晚开播 2 秒，就避免了卡顿 —— 这就是「增大播放时延减少下溢」。

递推式边界（ 是否含等号）讲义写的是含等号，做题时照讲义用即可。

七、三种流媒体传输方式（讲义 p17–21）

UDP 流

要点 说明
发送速率 服务器以适合客户的速率发送，通常发送速率 = 编码速率 = 恒定
拥塞 发送速率可以无视拥塞程度
播放时延 短（2–5 秒），用于消除网络抖动
差错恢复 应用层做，时间允许才做
协议 RTP（讲义写 RFC 2326，那其实是 RTSP；RTP 是 RFC 3550，讲义 p46 也写了 3550）
缺点 UDP 可能过不了防火墙

HTTP 流

要点 说明
获取方式 HTTP GET 取多媒体文件
发送速率 TCP 下能达到的最大速率
填充速率 因 TCP 拥塞控制和重传（按序交付）而波动
播放时延 更大，用来平滑 TCP 交付速率
优点 HTTP/TCP 更容易穿过防火墙
新趋势 YouTube 在 HTTP/3 下也使用 QUIC（见 Week 12）

数据路径：视频文件 → TCP 发送缓冲 → 网络 → TCP 接收缓冲 → 应用播放缓冲 → 播放。

DASH：Dynamic, Adaptive Streaming over HTTP

端 做什么
服务器 把视频切成多个块（chunk）；每块以多种码率编码存储；manifest 文件给出各块的 URL
客户端 周期性测量服务器到客户端的带宽；查 manifest，一次请求一块；选当前带宽能承受的最高码率；不同时间可选不同码率

「智能在客户端」—— 客户端决定三件事：

决定 目的
何时请求块 避免缓冲饥饿（starvation）
请求什么码率 带宽多时要高质量
向哪里请求 选「近」的或可用带宽高的 URL 服务器

八、CDN（讲义 p22–25）

挑战：如何把（从数百万视频中选出的）内容同时流给数十万用户？

方案 问题 / 做法
方案 1：单个超大服务器 单点故障；网络拥塞点；到远处客户路径长；同一视频的多个副本挤在出口链路上 → 不可扩展
方案 2：CDN 在地理上分布的多个站点存储/服务视频的多个副本

CDN 访问流程（讲义 p24：Bob 看 netcinema 的视频）

步 动作
0 视频预先存进 CDN（KingCDN.com/NetC6y&B23V）
1 Bob 从 netcinema.com 网页拿到视频 URL http://netcinema.com/6Y7B23V
2 Bob 的本地 DNS 解析该 URL
3 netcinema 的权威 DNS 不返回 IP，而是返回一个 KingCDN 的 URL（CNAME 式重定向）
4–5 本地 DNS 再去问 KingCDN 的权威 DNS，它返回「最佳」KingCDN 服务器的 IP
6 Bob 向该 KingCDN 服务器请求视频，经 HTTP 流式传输

核心技巧：用 DNS 做重定向。内容提供商把「解析权」交给 CDN，CDN 的 DNS 根据请求来源挑节点。（与 Week 04 DNS 的权威服务器概念直接相关。）

节点选择策略（讲义 p25）

策略 说明
地理上最近 最简单
时延最短 / 跳数最少 CDN 节点定期 ping 接入 ISP，把结果报告给 CDN DNS
让客户端决定 给客户一个 CDN 服务器列表，客户 ping 后自己挑最好的 —— Netflix 的做法

九、Netflix 案例（讲义 p26–27）

  • 2011 年占美国下行流量的 30%
  • 自己几乎没有基础设施，用第三方服务：
    • 自有：注册、计费服务器
    • Amazon 云：生成电影的多个编码版本；把版本上传到 CDN；托管 Netflix 网页
    • 三家 CDN：Akamai、Limelight、Level-3

流程：① Bob 管理账户 → ② 浏览选视频 → ③ 返回 manifest 文件 → ④ DASH 流式播放。

（讲义描述的是 2011 年左右的架构；如今 Netflix 已改用自建的 Open Connect CDN，考试按讲义答即可。）

第三部分：Voice over IP

十、VoIP 的要求（讲义 p29）

要求 值
端到端时延 < 150 ms：好；> 400 ms：差（包含应用层播放时延和网络时延）
会话初始化 被叫怎么公布 IP、端口、编码算法？（→ SIP，Week 10）
增值服务 呼叫转移、筛选、录音
紧急服务 911 / 000

十一、VoIP 流量特征（讲义 p30）

  • 说话者音频：讲话段（talk spurt）与静默期交替
  • 讲话时 64 kbps；只在讲话时产生块
  • 每 20 ms 一块： 字节
  • 每块加应用层首部，块 + 首部封装进 UDP 或 TCP 段
  • 讲话期间每 20 ms 往 socket 里写一个段

十二、两种「丢失」（讲义 p31）

类型 原因
网络丢失 IP 数据报因拥塞（路由器缓冲溢出）丢失
时延丢失 数据报到得太晚，赶不上播放 —— 对接收方来说等于丢了
  • 典型最大可容忍时延：400 ms
  • 丢包容忍度：取决于语音编码和丢包隐藏技术，1% 到 10% 的丢包率可以容忍

十三、固定播放时延（讲义 p33–34）

接收方尝试在每块「生成后恰好 q 毫秒」播放它：时间戳为 的块在 播放； 之后才到的块 = 丢失。

优点 缺点
大 丢包少 交互差
小 交互体验好 丢包多

讲义 p34 的图：第一个分组 时刻收到，播放计划 1 从 开始（ 较小）→ 有分组赶不上；播放计划 2 从 开始（ 较大）→ 全部赶上。

十四、自适应播放时延（讲义 p35–40）

目标：低播放时延 + 低迟到丢失率。 方法：估计网络时延，在每个讲话段开始时调整播放时延；静默期被压缩或拉长（人耳察觉不到）。

时延估计（EWMA，和 TCP 估 RTT 一样）：

  • ：第 个分组后的时延估计；：小常数，如 0.01
  • ：接收时刻；：发送时间戳； ：第 个分组的实测时延

时延偏差估计：

讲话段第一个分组的播放时刻：

每收到一个分组都更新，但只在讲话段开始时使用；同一讲话段内不调整（讲义 p38：「Within same talk spurt, no adjustment; adjustment is made in the next spurt」）。 后续分组按与第一个分组的相对时间偏移播放。

与 TCP 超时公式对照：TCP 是 ，这里是 —— 同一个「均值 + K 倍偏差」思想。

小算例

， ms， ms，新分组 ms：

若这是讲话段第一个分组、 ：播放时刻 ms。

怎么判断「讲话段的第一个分组」（讲义 p39–40）

情况 判断规则
无丢包 相邻时间戳之差 > 20 ms ⇒ 新讲话段开始
可能丢包 时间戳之差 > 20 ms 且序号连续（无空缺）⇒ 新讲话段开始

讲义 p40 的例子：时间戳 0, 20, 40, 100, 120。 - 无丢包时：40 → 100 差 60 ms，序号连续 → 100 是新讲话段第一个。 - 若序号是 1, 3, 4, 5（时间戳 0, 40, 100, 120）：0 → 40 差 40 ms 但序号跳了（2 丢了），所以这只是丢包，不是新讲话段；40 → 100 差 60 ms 且序号 3→4 连续 → 新讲话段。

为什么要看序号：只看时间戳会把「丢了一个包」误判为「静默」。

十五、丢包恢复（讲义 p41–44）

挑战：可容忍时延很小，每个 ACK/NAK 需要约一个 RTT，来不及重传 → 前向纠错（FEC）：发足够的冗余位，不用重传就能恢复。

方案 1：简单 XOR FEC

  • 每 个块生成一个冗余块：
  • 发 个块，带宽增加
  • 个块中最多丢 1 个时能重建全部 个原始块
  • 若 丢了：

讲义例子（逐位）： （ ）：

代价： 越大带宽开销越小，但要等收齐 个块才能恢复 → 播放时延更大；且一组里丢 2 个就救不回来。

方案 2：捎带低质量流

  • 把低分辨率的音频流作为冗余信息一起发
  • 例：正常流 64 kbps，冗余流 13 kbps
  • 实现上通常是第 个分组携带第 块的低质量版本：丢了一个，就用下一个分组里的低质版本顶上

方案 3：交织（interleaving）

  • 把每个 20 ms 音频块切成更小单元（如 4 个 5 ms 单元）
  • 每个分组装的是来自不同块的小单元
  • 丢一个分组时，每个原始块仍保有大部分内容

讲义 p44 的对比：

不交织 交织
丢一个分组 = 整个单词丢失 丢一个分组 = 每个单词缺一个音节，主观感受可接受
优点 缺点
交织 无冗余开销 时延性能更差（要等几个分组凑齐才能重组）

三种方案对比

方案 带宽开销 额外时延 恢复质量
XOR FEC 等一组 完全恢复（最多丢 1）
低质量冗余流 冗余流码率（如 13/64） 一个分组 降质恢复
交织 0 较大 隐藏（缺小片段）

第四部分：RTP

十六、RTP 是什么（讲义 p46–49）

要点 说明
作用 规定承载音视频数据的分组结构（RFC 3550）
提供 载荷类型标识、分组序号、时间戳
运行位置 端系统
封装 RTP 分组封装在 UDP 段里
互操作 两个 VoIP 应用都用 RTP，就可能互通

RTP 在 UDP 之上扩展了：端口号、IP 地址（已有）+ 载荷类型、序号、时间戳（新增）。

RTP 与 QoS（讲义 p49，易错）： - RTP 不提供任何保证及时交付或其他 QoS 的机制 - RTP 封装只在端系统可见，中间路由器看不到 - 路由器提供尽力而为服务，不会为 RTP 分组特殊处理

RTP 例子（讲义 p48）

发送 64 kbps PCM μ-law 语音：采样 8000 次/秒、8 bit/样本；每 20 ms 收集 160 字节为一块；音频块 + RTP 首部 = RTP 分组，封装进 UDP 段。

  • RTP 首部指明每个分组的音视频编码类型 → 发送方可在会话中途更换编码
  • RTP 首部还包含序号、时间戳

十七、RTP 首部字段（讲义 p50–52）

┌──────────────┬────────────────┬────────────┬──────────────────┬───────────────┐
│ payload type │ sequence number│ time stamp │ SSRC (sync src)  │ misc fields   │
│   (7 bits)   │   (16 bits)    │ (32 bits)  │   (32 bits)      │               │
└──────────────┴────────────────┴────────────┴──────────────────┴───────────────┘
字段 位数 作用
payload type 7 当前使用的编码类型；中途换编码就通过这个字段告知接收方
sequence # 16 每发一个 RTP 分组加 1；检测丢包、恢复顺序
timestamp 32 该分组第一个字节的采样时刻
SSRC 32 标识 RTP 流的来源；同一会话中每个流的 SSRC 不同

常见 payload type（讲义列表）：

值 编码 速率
0 PCM μ-law 64 kbps
3 GSM 13 kbps
7 LPC 2.4 kbps
26 Motion JPEG —
31 H.261 —
33 MPEG2 video —

时间戳的计算（必会）

  • 音频：时间戳时钟每个采样周期加 1，8 kHz 采样 → 每 125 μs 加 1
  • 每块 20 ms，含 个样本 → 每个 RTP 分组时间戳加 160
  • 源静默时，时间戳时钟仍按恒定速率继续走

讲义 p51 的例子：时间戳 、 、 —— 从 到 差 320，说明中间跳过了 2 个块（ ms 静默或丢失）；而图中 到 共 ms。

序号 + 时间戳一起用就能判断新讲话段（讲义 p52）： - 时间戳跳了、序号也跳了 → 丢包 - 时间戳跳了、序号连续 → 静默后新讲话段开始

这和第十四节「判断讲话段第一个分组」的规则是同一回事。

第五部分：W8 Tutorial —— TCP（Lab 7 Transport）

这份 tutorial 练的是 Week 06 TCP（tutorial 比讲课慢）。以下题目与官方答案（Tutor's version）逐题核对过。

Exercise 1：滑动窗口与序号空间

图 1（即 Kurose 教材 SR 困境图）：序号空间 {0, 1, 2, 3}，窗口大小 3。 - (a) 无问题：pkt0–2 正常到达并被确认，接收窗口移到 {3, 0, 1}，发送方之后发的 pkt0 是新分组 → 正确接受。 - (b) 出问题：pkt0–2 到达，但 3 个 ACK 全丢了；发送方超时重传旧 pkt0；接收窗口此时是 {3, 0, 1}，把旧 pkt0 当作新分组接受了！

接收方在 (a) 和 (b) 里看到的完全一样（「indistinguishable scenario」）—— 它看不见幕布另一侧发生了什么。

问题 官方答案 解释
例中有几个不同序号 ？ 4 个：0, 1, 2, 3 —
最多能流水线发几个未确认消息？ 3 个 窗口大小是 3
序号无穷多时，发送窗口里能否出现比接收窗口更大的序号？ 不能 发送窗口要右移到某序号，必须先收到它的 ACK；而 ACK 是接收方发的，说明该序号已经在接收窗口里了
序号无穷时，两窗口合起来最多覆盖多少个连续序号？何时发生？ 6 个 接收方已收到 3 个消息（窗口右移 3），但发送方一个 ACK 都没收到（窗口没动）
一般情况窗口为 个 同上
避免图 1 问题的最大发送窗口 2
一般关系 序号空间至少是窗口的 2 倍

⚠️ 关于 GBN 的说明：题目问「对每个协议」，官方答案统一给了 2。严格来说图 1 的困境是 SR 的（接收窗口大小也是 ）； GBN 的接收窗口大小为 1，只需 ，所以序号空间 4 时 GBN 窗口最大可到 3（见 Week 05 第二十七节的序号空间表）。 按官方答案「 → 2」作答对两种协议都安全；如果考题明确只问 GBN，答 。

Exercise 2：TCP Reno 拥塞窗口图

图 2 的数据（从图读出，单位：段）：

轮次 1 2 3 4 5 6 7 8 … 16 17 18 … 22 23 24 25 26
cwnd 1 2 4 8 16 32 33 34 … 42 21 22 … 26 1 2 4 8
# 问题 官方答案 判断依据
1 慢启动区间 [1, 6] 和 [23, 26] cwnd 每轮翻倍
2 拥塞避免区间 [6, 16] 和 [17, 22] cwnd 每轮 +1
3 第 16 轮后丢包靠什么检测？ 3 个重复 ACK cwnd 42 → 21（减半），若是超时会降到 1
4 第 22 轮后？ 超时 cwnd 26 → 1
5 第 1 轮的初始 ssthresh 32 慢启动在 32 停止、转入线性增长
6 第 18 轮的 ssthresh 21 第 16 轮丢包时 cwnd = 42，ssthresh = 42/2
7 第 24 轮的 ssthresh 13 第 17 轮 cwnd = 21，到第 22 轮 = 21 + (22 − 17) = 26；超时 → ssthresh = 26/2
8 第 70 个段在哪一轮发？ 第 7 轮 累计：轮 1 发段 1；轮 2 发 2–3；轮 3 发 4–7；轮 4 发 8–15；轮 5 发 16–31；轮 6 发 32–63；轮 7（cwnd = 33）发 64–96
9 第 26 轮后 3 个重复 ACK，ssthresh = ? 4 当时 cwnd = 8，ssthresh = 8/2

第 8 题的通用算法：慢启动阶段第 轮结束时累计发送 个段； ，所以第 70 个落在第 7 轮；但第 7 轮已进入拥塞避免，cwnd = 33（不是 64），发的是第 64–96 个段。

⚠️ 第 9 题的题面差异：学生版问的是「cwnd 和 ssthresh 的值」，Tutor's version 只问并只答了 ssthresh = 4。 按讲义 p49 的 Reno FSM，3 个重复 ACK 后 cwnd = ssthresh + 3 = 7（进入快速恢复），收到新 ACK 后回落到 cwnd = ssthresh = 4； 按做题常用的简化模型（直接减半），cwnd = 4。考试作答时写清楚用的是哪个模型。

第 5 题的细节：严格说 cwnd 从 16 翻倍到 32 时已触及 ssthresh，所以第 6 轮的 32 是慢启动的最后一步；第 7 轮开始 +1。官方把第 6 轮同时算进两个区间（[1,6] 和 [6,16]），是取了「转折点」。

第六部分：本周考点速记

数字

项 值
电话采样率 / CD-like 音乐采样率 8000 / 44100 次/秒
44100 × 8 bit 352,800 bps
未压缩 480×640×24fps 视频 ≈ 177 Mbps
MPEG-1 / MPEG-2 / MPEG-4 1.5 / 3–6 / < 1 Mbps
UDP 流播放时延 2–5 秒
VoIP 时延：好 / 差 < 150 ms / > 400 ms
VoIP 每块 20 ms，160 字节
可容忍丢包率 1%–10%
RTP 首部字段位数 PT 7、序号 16、时间戳 32、SSRC 32
8 kHz 下时间戳每分组增量 160

易错点

  1. 缓冲必然被抽空； 还需要足够的初始时延。
  2. DASH 的智能在客户端，服务器只存块和 manifest。
  3. CDN 靠 DNS 重定向，内容提供商的权威 DNS 返回的是 CDN 的名字。
  4. Netflix（讲义版本）让客户端自己 ping 挑 CDN 节点。
  5. 时延丢失也是丢失 —— 到得太晚等于没到。
  6. 自适应播放时延只在讲话段开始时调整，段内不调。
  7. 判断新讲话段要同时看时间戳和序号。
  8. XOR FEC 一组只能救 1 个；交织无冗余但时延大。
  9. RTP 不提供 QoS，路由器看不到 RTP 首部。
  10. RTP 跑在 UDP 之上，属于应用层库提供的「类传输层」接口。