第一部分：定义和测量延迟

直播视频流式传输为何存在延迟问题？每当内容分发时间紧张时，无论是体育运动、比赛、新闻等电视内容，还是电子竞技、博彩等纯 OTT 内容，延迟的代价都很高。延迟造成的等待会使悬念丧失，而且等待会让您成为娱乐和实时信息世界的“二等公民”。很明显的一个例子是观看足球比赛：您的邻居在传统电视上观看比赛，他最喜欢的球队（通常也是您最喜欢的球队）每次进球时，您都能隔着墙听见他大声欢呼，而您却不得不等待 25 秒甚至 30 秒，才能通过 OTT 服务看到同样的进球场景。这类似于在您就要听到最喜欢的歌唱比赛公布结果时，却被通过同一流媒体渠道关注的 Twitter 或 Facebook 源剧透了一样，令人沮丧至极。这些社交源通常是用户在自己的电视上观看节目时产生的，因此您的相对延迟通常会降至 15 到 20 秒，但与电视直播的速度相比，仍然相差甚远。

除了广播延迟和社交网络竞争之外，内容提供商希望最大限度地降低直播视频流延迟还有其他原因。他们基于 Flash 的旧应用程序采用 RTMP 流，延迟性能较好，但由于 Flash 在 Web 浏览器中确实已经逐渐被弃用，导致 CDN 不得不放弃使用 RTMP 进行分发，因此内容提供商需要改用适合 HTML5 的流式传输技术，如 HLS 和 DASH，或最新推出的 CMAF。其他内容提供商希望开发具有交互功能的个人广播服务，在这种情形下视频信号存在 30 秒延迟是无法接受的。此外，那些想要开发同步的第二屏幕、社交观看或博彩应用程序的用户需要更精细地控制流式传输延迟。

在延迟方面，通常会有三个类别，具有高范围和低范围。它们与广播延迟并不完全匹配，广播延迟介于 3 秒到 12 秒之间，具体取决于传输方式（线缆/IPTV/DTT/卫星）和每个分发网络拓扑的具体情况。平均 6 秒的广播延迟在该领域非常常见，这意味着 OTT 的可接受的延迟应介于“更低延迟”类别的低范围或“低延迟”类别的高范围之间。接近 5 秒的延迟可最大限度提高与广播和社交网络源竞争的机会。此外，根据 OTT 编码器在内容准备工作流程中的位置，如果编码器位于链的下游，就需要提高延迟降低目标。

术语	高（秒）	低（秒）
更低延迟	18	6
低延迟	6	2
超低延迟	2	0.2

对于基于 HTTP 的流式传输，延迟主要取决于媒体分段的长度：如果媒体分段长 6 秒，则意味着您的播放器将比它请求第一个媒体分段时的实际绝对时间晚至少 6 秒。而许多播放器在实际开始播放之前会将其他媒体分段先下载到其缓冲区，这会自动增加第一个解码视频帧的时间。当然，还有其他因素会产生延迟，比如视频编码管道的持续时间、提取和打包操作的持续时间、网络传播延迟以及 CDN 缓冲区（如果有的话）。但在大多数情况下，播放器延迟在总延迟中占比最大。事实上，大多数播放器通常会使用保守的启发式算法并缓冲三个或更多分段。

使用 Microsoft Smooth Streaming 时，通常的分段长度是 2 秒，最终导致在 Silverlight 播放器中通常延迟 10 秒左右。使用 DASH 时，情况几乎是一样的。大多数播放器可以支持 2 秒分段，但延迟结果会有不同。但使用 HLS 时的情况则完全不同：直到 2016 年中期，Apple 的建议是使用 10 秒的分段，这使得包括 Apple 专属播放器在内的大多数 HLS 播放器的延迟都在 30 秒左右。2016 年 8 月，Apple 的技术说明 TN2224 载明：“我们过去建议使用 10 秒的目标持续时间。我们不希望您突然遇到需对所有内容进行重新分段的情况。但我们确实相信，未来 6 秒会是更好的方案。” 每分段减少 4 秒，那么 12 秒的延迟就会从屏幕上消失。大多数情况下，即使 iOS 播放器可以使用更小的分段长度，内容制作商也会遵循 Apple 的建议，因为他们不想冒任何风险在 AppStore 中验证自己的 iOS 应用程序。但最近的三个变化改变了 iOS11 上 Safari Mobile 的规则：启用了实时 HLS 流的自动启动功能；对小分段持续时间的支持得到显著改善；现在还支持 FairPlay DRM。这意味着，内容制造商并非一定要在 iOS 上使用编译后的应用程序，可以通过短的媒体分段减少实时延迟，同时使用工作室认可的 DRM 分发受保护的流。

有些人可能会提出异议，认为短媒体分段会给 CDN 和播放器带来高负载，但多年来，Microsoft Smooth Streaming 利用 2 秒分段一直就是这种情况。为了缩短广播的延迟间隔，接下来要将分段缩短至 1 秒，这实际上也不会产生主要瓶颈问题。当然，它将请求数量乘以 2，所有 HTTP 开销都根据标头和 TCP 连接计算，但是 CDN（尤其是如果它像 Amazon CloudFront 一样支持边缘的 HTTP 2.0 和 HTTP 1.1 源时）以及通过光纤、4G、LTE、DOCSIS 3.1 FD 和其他最先进的连接技术从更高的带宽和最后一英里连接中受益的现代播放器都可以相当容易地对其进行管理。实验表明，现在许多播放器都支持 1 秒和 2 秒的短分段，因此提供了许多降低延迟的新方案。最后，在 HLS 和 DASH 中，对于跨链的编码器、打包程序和源服务来说，短分段通常不是问题。

除了仍然强制执行 6 秒分段持续时间的 AppStore 要求之外，内容制作商可以灵活地在所有平台上的各种播放器中试验 1 秒或 2 秒媒体分段，实现相同甚至更短的广播延迟。

在宏观层面上，为了将您的流式传输解决方案归入“低延迟”类别，需要执行以下主要操作：

优化您的视频编码管道
根据您的要求选择适当的分段持续时间
构建适当的架构
优化（或替换）视频播放器
我们来看看如何将 AWS Elemental 视频解决方案与当今可用的开源或商业播放器结合使用来实现这一点。

如何衡量延迟

延迟优化过程的第一步是要知道链中每个部分在总延迟中的占比，这样无论在工作流程中处于编码、打包还是播放阶段，我们都可以明确优化的优先级。首先从测量端到端延迟开始。

测量端到端延迟的最简单方法是使用运行 Clapperboard 应用程序的平板电脑，使用连接到编码器的相机拍摄，将流发布到您的源，然后通过 CDN 传送到播放器。将播放器放在运行 Clapperboard 的平板电脑旁边，拍下两个屏幕的图片，减去每个屏幕上的时间码，这样就可以获得延迟时间。然后这样多操作几次，以确保它准确地表示传输过程的延迟。

或者，您也可以将 AWS Elemental Live 编码器与一个循环文件源一起使用，将编码器时间（通过使用 NTP 参考的编码器）烧录为视频上的覆盖图，并将烧录的时间码与浏览器窗口中的时间服务（如 time.is）进行比较。您需要添加捕获延迟，通常在 400 毫秒左右。

捕获延迟

您可以在视频编码参数的预处理器部分激活 AWS Elemental Live 上的时间码烧录，您需要为编码梯形图中的每个比特率激活它。

您需要验证是否要在低延迟模式下设置编码器。在 AWS Elemental Live 中，这意味着需要在“Input”（输入）参数的“Additional Global Configuration”（其他全局配置）部分中选择“Low Latency Mode”（低延迟模式）复选框。

接下来，设置一个 UDP/TS 编码事件，在 TS 输出部分设置一个 500 毫秒的缓冲区，并将笔记本电脑 IP 设为目的地。

在笔记本电脑上，使用 :network-caching=200 选项打开 VLC 上的网络流（本例中为 rtp://192.168.10.62:5011）以使用 200 毫秒网络缓冲区。通过比较烧录的时间码与 Clapperboard 时间码，您将能够通过 VLC 窗口的快照计算捕获延迟。

如果您的平板电脑不允许您将其与 NTP 同步，那么您可以通过 iOS 上的“Emerald Time”等应用程序确定与 NTP 相比平板电脑的时间漂移为多少。在本例中，时间漂移是 +0.023 秒，这意味着 Clapperboard 时间实际上是 25:00.86 而不是 25:00.88。烧录的时间码是 25:01:06（最后两位是帧号），可以在百分之一秒内转换为 25:01.25（因为我们的编码是 24fps）。因此，我们的捕获延迟是 (25:01.25 – 25:00.86 ) = 0.39 秒。公式为：捕获延迟 = 刻录时间码（以秒为单位）–（Clapperboard 时间码 + NTP 漂移）。

编码延迟
使用此 UDP/TS 编码事件，我们还可以计算视频编码管道产生的延迟。我们的示例使用以下编码参数，以便针对高要求的场景产生符合广播要求的质量，同时在诱导延迟方面提出一个可接受的折衷方案。

本例中，我们的平板电脑时间为 13:27:19.32，VLC 时间为 13:27:16.75。

编码管道延迟使用以下公式计算：（平板电脑时间 – VLC 时间）–（捕获延迟 + VLC 缓冲 + RTP 缓冲），即 (19.32-16.75) – (0.39 + 0.20 + 0.50) = 1.48 秒

提取延迟
现在我们知道了捕获延迟和编码管道延迟，我们来计算一下提取延迟。“提取延迟”包括打包提取格式所需的时间，以及将其提取到未对提取流应用打包的源所需的时间，这可能是带有直通过滤器的 AWS Elemental Delta，也可能是 AWS Elemental MediaStore。我们这里使用 HLS，将 1 秒的分段推送到 AWS Elemental MediaStore。

使用 shell，我们可以监视源上 HLS 子播放列表的更改：

$ while sleep 0.01; do curl https://container.mediastore.eu-west-1.amazonaws.com/livehls/index_730.m3u8 && date +"%Y-%m-%d %H:%M:%S,%3N"; done

这会在 shell 输出中首次引用分段“index_73020180223T154954_02190.ts”时返回结果：

#EXTM3U
[…]
index_73020180223T154954_02190.ts
2018-02-23 15:49:55,515

然后我们下载分段 “index_73020180223T154954_02190.ts”来验证它携带的时间码：16:49:53:37 (UTC+1)。当前日期和分段时间码之间的差异是 55.51 – 53.37 = 2.14 秒。如果去掉编码延迟和捕获延迟，就可以分离打包 HLS 分段并将其推送到源所需的时间。公式为提取延迟 =（当前日期 – 分段时间码）–（捕获延迟 + 编码延迟）。对于 AWS Elemental MediaStore，我们计算得出 0.27 秒。对于 AWS Elemental Delta，相同的计算得出 0.55 秒。

重新打包延迟
通过对 AWS Elemental Delta 和 AWS Elemental MediaPackage 应用相同的方法，并添加先前计算的提取延迟，我们可以计算重新打包提取流所需的时间。公式为
重新打包延迟 =（当前日期 – 分段时间码）–（捕获延迟 + 编码延迟 + 提取延迟）
对于 AWS ElementalMediaPackage（假设提取延迟与 AWS element Delta 相同，因为没有简单测量方法），从 HLS 1 秒提取输出 HLS 1 秒段，重新打包延迟为 (57.34 – 54.58) – (0.39 + 1.48 + 0.55) = 0.34 秒。对于 AWS Elemental Delta，为 (26.41 –23.86) – (0.39 + 1.48 + 0.55) = 0.41 秒。

分发延迟
相同的方法可以应用于分发，即从源到 CDN 边缘的传输。在源执行重新打包的情况下，分发延迟 =（当前日期 – 分段时间码）–（捕获延迟 + 编码延迟 + 提取延迟 + 重新打包延迟）当源执行直通流式传输时，分发延迟 =（当前日期 – 分段时间码）–（捕获延迟 + 编码延迟 + 提取延迟）。可以通过在源端添加 Amazon CloudFront 分配，并使用与提取延迟计算相同的命令行来测量分发延迟。对于 AWS Elemental MediaStore，我们得到的结果是 (52.71 – 50.40) – (0.39 + 1.48 + 0.27) = 0.17 秒。对于同一区域的所有源类型，此延迟是相同的。

客户端延迟
在这个类别中，我们可以发现两个取决于客户端的延迟因素：最后一英里延迟（与网络带宽相关）和播放器延迟（与内容缓冲区相关）。最后一英里延迟从光纤连接的几毫秒到最慢的移动连接的几秒不等。内容下载持续时间直接影响延迟，因为它延迟到 T+x 秒，此时时间码 T 可用于在客户端进行缓冲和播放。如果与分段长度相比此延迟太长，则播放器将无法构建足够的缓冲区，并且它会切换至编码梯形图中较低的比特率，直到在比特率、网络条件和构建其内容缓冲区的能力之间找到合适的折中解决方案为止。如果即使是最低的比特率也不允许构建足够的缓冲区，那么它将不断播放、停止和重新缓冲，因为内容无法足够快地下载。一旦内容下载持续时间开始上升到段持续时间的 50%，那么播放器的缓冲区就会陷入不利状况。理想情况下，应该保持在 25% 以下。播放器延迟是播放器缓冲策略（播放器可能需要缓冲 X 个分段，或者特定的最小内容持续时间）与播放头定位策略合并产生的结果。

测量客户端延迟的方式是：客户端延迟 = 端到端延迟 –（捕获延迟 + 编码延迟 + 提取延迟 + 重新打包延迟 + 分发延迟）。通过从整个客户端延迟中减去媒体分段的平均传输时间（即最后一英里延迟），可以得出播放器延迟。最后一英里延迟值需要根据至少 20 个分段请求进行计算。这将包括客户端可以生成的实际数据传输时间和等待时间。例如，创建段请求时，给定子域的所有允许的套接字当前都会打开。

下面是使用 AWS Elemental Live 和 AWS Elemental MediaStore 生成的 HLS 1 秒分段的示例分解，随 Amazon CloudFront 一起分发给标准 hls.js 0.8.9 播放器：

延迟类型	秒数	影响
捕获	0.39	7.58%
编码	1.48	28.79%
提取	0.27	5.25%
重新打包	无数据	无数据
分发	0.17	3.33%
最后一英里	0.28	5.44%
播放器	2.55	49.61%
端到端延迟	5.14	100%

正如我们所看到的，大部分的延迟是在编码和播放步骤产生的，这也是最需要改进的部分。但这并不意味着没有办法优化其他步骤，只不过即使优化，产生的影响也微乎其微。当输出媒体分段持续时间增加时，播放器和最后一英里延迟通常会增加，而其他步骤则保持稳定。

在本系列的第二部分，我们将研究可应用于优化工作流程中每个步骤的方案。

————

第一部分：如何借助当前的自适应比特率技术降低广播延迟 – 定义和测量延迟（本博文）

第二部分：如何借助当前的自适应比特率技术降低广播延迟 – 编码、打包和 CDN 分发的优化建议

第三部分：如何借助当前的自适应比特率技术降低广播延迟 – 视频播放器优化建议

第四部分：如何借助当前的自适应比特率技术降低广播延迟 – 参考架构和测试结果

作者介绍：

Nicolas Weil
Nicolas Weil 是 AWS Elemental 的高级解决方案架构师。

本文转载自AWS技术博客。

原文链接：
https://amazonaws-china.com/cn/blogs/china/compete-broadcast-latency-bitrate-tech1/

创作场景

第一部分：如何借助当前的自适应比特率技术降低广播延迟