延迟方法(延迟的基本概念和测量方法)

在较高的层面上延迟方法，以下方式可以减少延迟：

怎样测量延迟

延迟优化过程的第一步是知道传输链中的每个部分在总延迟中的占比，这可以让我们知道优化的优先级。 首先从测量端到端延迟(measuring the end-to-end latency)开始。下面以AWS的部分产品作为示例演示如何测量延迟。

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

图1. 测量端到端延迟

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

捕获延迟(capture latency)

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

图2. AWS Elemental Live添加时间码

需要验证是否在低延迟模式下设置编码器。在AWS Elemental Live中，在Input参数的“Additional Global Configuration”部分中选择“Low Latency Mode”复选框。

图3. 设置缓冲区大小和目标IP

接下来，在TS输出部分设置一个带有500 ms缓冲区的UDP / TS编码事件，并将笔记本电脑IP作为目标。在笔记本电脑上，使用：network-caching = 200选项打开VLC上的网络流（在此示例中为rtp：//192.168.10.62：5011），以使用200 ms的网络缓冲区。通过比较烧录的时间码和clapperboard时间码， 将能够从VLC窗口的快照计算捕获延迟。

图4. 计算捕获延迟

如果平板电脑不允许将其与NTP同步，那么IOS上的某些应用程序（例如“Emerald Time”）可以得到平板电脑的时间漂移与NTP相比的程度。在我们的例子中，时间漂移是+ 0.023s，意味着clapperboard时间实际上是25：00.86而不是25：00.88。烧录的时间码是25:01:06（最后两位是帧号），也就是25：01.25（因为我们以24fps编码）。因此，我们的捕获延迟（25：01.25 - 25：00.86）= 0.39秒。 公式为：捕获延迟=以秒为单位的Burnt Timecode - （Clapperboard时间码+ NTP漂移）。

编码延迟(encoding latency)

通过此UDP / TS编码事件，我们还可以计算视频编码管道生成的延迟。我们的示例使用以下编码参数，以便满足一些高要求的场景。

图5. 示例事件的视频编码参数

在我们的例子中，我们的平板电脑时间为13：27：19.32，VLC时间为13：27：16.75。

图6. 编码管道传输的结果

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

获取延迟(ingest latency)

现在我们知道了捕获延迟和编码管道的延迟，接下来是获取延迟。“获取延迟”包括打包摄取格式并将其摄取到origin端所需的时间。在这里，我们使用HLS将1秒的切片推送到AWS Elemental MediaStore。使用shell，我们可以监视origin上HLS子播放列表的更改：

Powershell：

$ while sleep 0.01; do curl && date +"%Y-%m-%d %H:%M:%S,%3N";

done

当在shell输出中首次引用切片时，返回该切片。然后我们玩法攻略介绍切片以验证它携带的时间码：16：49：53：37（UTC + 1）。当前日期和切片时间码之间的差异是55.51 - 53.37 = 2.14秒。如果我们去除编码延迟和捕获延迟，我们会隔离打包HLS切片并将其推送到origin端所需的时间。公式为摄取延迟=（当前日期 – 切片时间码） - （捕获延迟+编码延迟）。对于AWS Elemental MediaStore，我们得到0.27秒。对于AWS Elemental Delta，相同的计算得出0.55秒。

再打包延迟(repackaging latency)

通过对AWS Elemental Delta和AWS Elemental MediaPackage应用相同的方法，并添加先前计算的获取延迟，我们可以计算再打包摄取流所需的时间。 公式是再打包延迟=（当前日期 – 切片时间码） - （捕获延迟+编码延迟+摄取延迟）

对于ElementalMediaPackage（假设摄取延迟与AWS Elemental Delta相同，因为没有简单的方法可以测量它）HLS从摄取到输出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秒。

传输延迟(delivery latency)

相同的方法可以应用于交付 - 即从origin到CDN edge的传输。在origin端进行再包装的情况下，传输延迟=（当前日期 – 切片时间码）-（捕获延迟+编码延迟+获取延迟+再包装延迟）。当origin端通过流式传输时，传输延迟=（当前日期 – 切片时间码）-（捕获延迟+编码延迟+摄取延迟）。 可以通过在origin端添加Amazon CloudFront分配并使用与摄取延迟计算相同的命令行来测量传输延迟。对于AWS Elemental MediaStore，我们有（52.71 - 50.40）-（0.39 + 1.48 + 0.27），这是0.17秒。对于同一区域中的所有origin端类型，此延迟是相同的。

客户端延迟(client latency)

在此类别中，我们可以找到两个受客户端影响的延迟因素：最后一英里延迟（与网络带宽相关）和播放器延迟（与内容缓冲区相关）。最后一英里的延迟范围从光纤连接上的几毫秒到最慢的移动连接上的几秒。内容玩法攻略介绍持续时间直接影响延迟，因为它延迟到T + x秒，此时时间码T可用于在客户端缓冲和播放。如果此延迟与切片长度相比太大，则播放器将无法构建足够的缓冲区延迟方法，并且它将导致播放器切换到较低的比特率，直到在比特率，网络之间找到合适的折衷点。如果即使是最低的比特率也不允许构建足够的缓冲区，那么它将不断播放，停止和再缓存，因为内容无法足够快地玩法攻略介绍。一旦内容玩法攻略介绍持续时间开始上升到切片大小的50％，它就会从缓冲区角度将播放器带到危险区域。理想情况下，它应该保持在25％以下。

可以测量客户端延迟的方式是客户端延迟=端到端延迟 -（捕获延迟+编码延迟+摄取延迟+重新打包延迟+传输延迟）。可以通过从总体客户端延迟中减去媒体切片的平均传输时间（也称为最后一英里延迟）来计算播放器延迟。

以下是使用AWS Elemental Live和AWS Elemental MediaStore生成的HLS 1秒切片的示例细分，随Amazon CloudFront一起提供给标准的hls.js 0.8.9播放器：

表2. 传输中的各阶段所占延迟比例