17、多媒体流低延迟传输技术解析

多媒体流低延迟传输技术解析

1. FDN 与 CDN 对比

1.1 F-FDN 方法介绍

• Deterministic F-FDN ：由中央云和 FDN 联盟组成。每个 FDN 可进行缓存和按需处理，联盟还允许从相邻 FDN 流式传输缓存片段。该方法仅基于预期传输和处理时间做出流式传输决策，忽略了 F-FDN 环境中的随机性质，可展示忽略系统不确定性对整体流式传输 QoE 的影响。
• Robust F-FDN ：与 Deterministic F-FDN 不同，它考虑了 F-FDN 平台通信和计算中的随机性质。更明智的决策制定有望使更多流式传输任务按时完成，从而提供更强大的流式传输服务，不受观众地理位置的影响。

1.2 流传输方法评估

1.2.1 实验设置

• 使用 MSC 平台进行仿真研究，模拟三个基于 Amazon GPU（g2.2xlarge）VM 的工作 VM 进行视频处理。
• 系统中使用三个 FDN 和一个中央云服务器，流式传输请求到达其中一个 FDN，测量该 FDN 的性能指标，另外两个 FDN 作为邻居缓存部分视频片段。
• 生成不同的视频流请求工作负载轨迹，使用一组包含不同长度和内容类型的基准视频创建工作负载，每个视频片段有相关的处理时间。
• 为确保结果的准确性和消除不确定性，生成 30 个不同的工作负载轨迹，每个轨迹模拟 3 分钟的视频流请求到达，每个流式传输请求的到达时间在时间段内均匀采样。
• 跟踪错过截止时间的片段数量，以指示系统的鲁棒性。同时考虑带宽使用，设置本地 FDN 到观众和相邻 FDN 的有限带宽值，每个节点有相关的延迟值，平均带宽设置为 1 Gbps。

1.2.2 确定 FDN 合适的缓存大小

• 目的是找到 FDN 内需要缓存的视频内容的最小百分比，以维持观众的高 QoE。
• 增加每个 FDN 中缓存的片段百分比，测量错过截止时间的视频片段百分比。
• 结果表明，随着缓存片段百分比的增加，所有方法的截止时间错过率显著下降，从约 53% 降至约 2%。当总缓存视频内容为 0% 时，F-CDN 与其他三个系统有显著差异，其他方法能显著降低截止时间错过率。随着缓存视频内容水平的增加，从相邻 FDN 流式传输视频片段的好处明显，如在 30% 缓存时，Deterministic F-FDN 比 I-FDN 的截止时间错过率降低 2.3%，在 90% 缓存时降低 2.7%。
• 基于实验观察和分析，后续实验中 FDN 系统采用 30% 的缓存水平，认为该水平在缓存大小和流式传输 QoE 之间提供了可持续的权衡。

缓存百分比	F-CDN 截止时间错过率	I-FDN 截止时间错过率	Deterministic F-FDN 截止时间错过率	Robust F-FDN 截止时间错过率
0%	高	相对低	相对低	相对低
30%	-	-	比 I-FDN 低 2.3%	-
90%	-	-	比 I-FDN 低 2.7%	-

1.2.3 分析过载订阅的影响

• 目标是研究 F-FDN 平台在增加工作负载强度（过载订阅）时的鲁棒性，并与其他方法进行比较。
• 在相同时间间隔内将到达的视频片段数量从 3000 变化到 4500（增量为 500），测量错过截止时间的片段百分比。
• FDN 方法缓存 30% 的视频片段，CDN 方法缓存 75% 的视频片段，中央云存储所有视频内容。
• 结果显示，随着到达请求数量的增加，错过截止时间的片段百分比也增加。CDN 方法比中央云方法平均少错过 54% 的截止时间，I-FDN 比 CDN 平均有 17% 的截止时间错过率改善，Deterministic F-FDN 比 I-FDN 平均少错过 34% 的截止时间，Robust F-FDN 比 Deterministic F-FDN 平均好 28%。

graph LR
    A[中央云] -->|流式传输| B[CDN]
    A -->|流式传输| C[I-FDN]
    A -->|流式传输| D[Deterministic F-FDN]
    A -->|流式传输| E[Robust F-FDN]
    B -->|流式传输| F[观众]
    C -->|流式传输| F
    D -->|流式传输| F
    E -->|流式传输| F
    C -->|按需处理| G[本地处理]
    D -->|按需处理| G
    E -->|按需处理| G
    D -->|从相邻 FDN 流式传输| H[相邻 FDN]
    E -->|从相邻 FDN 流式传输| H

1.2.4 分析网络延迟的影响

• 目的是评估所探索方法对观众地理位置的鲁棒性，特别是在偏远地区，边缘网络质量通常波动且高度不确定。
• 稳定增加观众与 FDN 之间以及 FDN 之间的网络延迟不确定性，评估 CDN、I-FDN、Deterministic F-FDN 和 Robust F-FDN 方法的性能。
• 结果表明，随着网络延迟的增加，所有方法的截止时间错过率都增加，但 CDN 的截止时间错过率增加速度比其他方法更快。I-FDN 比 CDN 表现更好，因为它可以对未缓存的片段进行按需处理，减少对中央云的依赖。随着网络延迟的增加，I-FDN 与 Deterministic F-FDN 以及 Robust F-FDN 之间的截止时间错过率差异减小，这表明系统具有适应性。总体而言，Robust F-FDN 性能优于其他方法，但在测试的最高网络延迟（4000 ms）时，与 Deterministic F-FDN 的差异不那么明显。

2. 流媒体协议

2.1 传统流媒体协议

• 渐进式下载 ：早期观众需等待整个内容下载完成才能开始观看，延迟显著。
• RTMP ：Adobe 引入的流媒体服务器，将视频分割成较小的块，玩家下载一个块后即可开始播放，低延迟和播放灵活性使其在一段时间内成为流行的流媒体协议。但它需要专用的流媒体服务器，且由于端口号与流行的 HTTP 不同，连接可能被防火墙阻止。

2.2 自适应比特率流媒体（ABR）协议

• 常见协议 ：包括 Apple 的 HLS、MPEG 组的 DASH 和 Microsoft 的 Smooth。这些协议基于 HTTP，解决了防火墙配置问题，直接使用 Web 服务器，而不是单独的专用流媒体服务器。
• 特点 ：采用 RTMP 方法将多媒体内容分割成段，每个段可以小到一个图片组（GOP）。但小的段大小会导致更高的 HTTP 请求流量，从而可能导致更高的延迟，因此段大小应综合考虑各方面因素进行选择，HLS 协议建议段大小为 10s，DASH 建议为 6s。
• 延迟问题 ：典型的 ABR 协议与原始渐进式下载相比可显著降低流媒体延迟，但延迟仍可达约 30s，对于直播用例不可接受。

2.3 低延迟 ABR 协议

• LLHLS 和 CMAF ：将多媒体段进一步分割成更小的块，可小到几帧，使用块传输编码技术对帧进行编码和传输。但这些协议需要流播放器端的支持，播放器收到小块后即可开始播放，无需等待整个段下载完成，可将流媒体延迟降低到 5s 以下。
• WebRTC ：基于 UDP 传输协议，可实现仅 1s 延迟的视频内容流式传输，广泛应用于视频会议或其他点对点应用。

协议名称	延迟	特点
渐进式下载	显著	需等待整个内容下载完成
RTMP	低	需专用服务器，可能被防火墙阻止
HLS	约 30s	基于 HTTP，段大小建议 10s
DASH	约 30s	基于 HTTP，段大小建议 6s
LLHLS	小于 5s	分割成小块，需播放器支持
CMAF	小于 5s	分割成小块，需播放器支持
WebRTC	1s	基于 UDP，用于点对点应用

graph LR
    A[原始视频] -->|分割| B[ABR 段]
    B -->|进一步分割| C[低延迟小块]
    C -->|传输| D[播放器]
    A -->|渐进式下载| E[播放器]
    A -->|RTMP 分割| F[小块]
    F -->|传输| D

3. 低延迟流媒体实践案例

3.1 CMAF 超低延迟流媒体方法

• Akamai 的方法 ：Akamai 的 Will 提出了一种使用 CMAF 进行分块传输编码的超低延迟流媒体方法。为了考虑传输效率和成本，视频和音频轨道通常被分割成段（如 10s）或片段（如 2s）。较大的视频段意味着需要更少的段请求，但也会导致高延迟。使用 CMAF 时，视频和音频片段可以进一步分割成多个更小的块，块大小可以小到一帧，并且第一个块包含即时解码器刷新（IDR）帧。
• 解决带宽浪费问题 ：较小的视频块通常意味着更多的请求，会导致更高的带宽浪费。为了解决这个问题，低延迟 CMAF 采用了两种技术：分块传输编码（CTE）和超文本传输协议（HTTP/1.1）推送。
• CTE 降低延迟 ：通常，一个段只有在其中的所有帧都转码完成后才会生成，然后缓存到边缘 CDN，供播放器下载。这会根据段大小产生较大的延迟。而播放器通常需要缓冲几个段（如 30s）才能开始播放，这又增加了视频可观看前的延迟。使用 CTE 时，转码器只要准备好较小的块（可以小到一帧）就会生成它们。只要播放器收到这些块，就可以开始解码和播放，而无需等待整个段下载完成，从而将延迟降低到 500ms 以下。
• HTTP/1.1 推送 ：CTE 的一个主要问题是较小块的请求数量增加。HTTP/1.1 推送机制解决了这个问题。使用该机制，播放器只需要为一个段发送一个请求，CDN 会在块准备好后将属于该请求段的所有块推送给播放器，从而降低了带宽和延迟。

技术	作用
分块传输编码（CTE）	降低视频播放延迟至 500ms 以下
HTTP/1.1 推送	减少请求数量，降低带宽和延迟

graph LR
    A[视频源] -->|转码| B[CMAF 段]
    B -->|分割| C[小块]
    C -->|CTE 编码| D[传输]
    D -->|HTTP/1.1 推送| E[播放器]

3.2 Twitch 的低延迟直播流交付

• 自定义 HLS 规范 ：Twitch 采用了类似的方法进行低延迟直播流交付。John 自定义了 HLS 规范，使用特殊标签（如 #EXT - X - PREFETCH）来请求尚未准备好的段。连接会保持活跃，只要段内的任何块准备好，就会推送给播放器。Twitch 的 HLS 清单不显示块，看起来像带有一些自定义标签的普通 HLS 清单。

3.3 Apple 的 LL - HLS

• 实现低延迟方式 ：Apple 没有将类似的技巧纳入 HLS 规范，而是推出了自己的 LL - HLS。为了实现低延迟，LL - HLS 建议将视频分割成更小的部分，每个部分的 URL 会显示在清单中。为了避免高请求率，Apple 采用了 HTTP2 推送机制。除了将部分推送给播放器，服务器还需要在每个部分后更新清单，并在视频部分之前推送最新的清单。
• 优缺点 ：LL - HLS 的优点是知道哪个部分有 IDR，因此播放器切换版本更快。但它也有更多的瓶颈，例如由于额外的清单交付导致带宽浪费，以及需要 CDN 提供商支持 HTTP2 推送等。

平台	实现方式	优点	缺点
Twitch	自定义 HLS 规范，使用特殊标签请求未准备好的段	连接保持活跃，实时推送块	-
Apple（LL - HLS）	分割视频成小部分，采用 HTTP2 推送，更新清单	知道 IDR 位置，切换版本快	带宽浪费，需 CDN 支持 HTTP2 推送

4. 总结

本文主要探讨了多媒体流低延迟传输的相关技术。在 FDN 与 CDN 的对比中，F - FDN 方法展现出了更好的性能，尤其是 Robust F - FDN 考虑了系统中的随机性质，能在不同工作负载和网络条件下提供更强大的流式传输服务。通过对缓存大小、过载订阅和网络延迟的实验分析，确定了合适的缓存水平，并证明了 F - FDN 平台在提高流式传输性能方面的优势。

在流媒体协议方面，从传统的渐进式下载和 RTMP 协议，到自适应比特率流媒体（ABR）协议，再到低延迟 ABR 协议，流媒体协议不断发展以降低延迟。其中，WebRTC 实现了最低的 1s 延迟，而 CMAF、LLHLS 等协议也能将延迟降低到 5s 以下。

在实践案例中，CMAF、Twitch 的自定义 HLS 和 Apple 的 LL - HLS 等方法都在努力实现低延迟流媒体，同时也面临着不同的挑战，如带宽浪费、服务器支持等问题。未来，随着技术的不断发展，多媒体流低延迟传输技术有望进一步优化，为用户带来更好的观看体验。