摘要：
想要优化延迟，可Latency到底是多少？延迟始终是媒体内容传输的一个重要关注点，人们也在不断尝试用新的方法来优化延迟，本文参考AWS的一些新技术，介绍了延迟的定义，以及如何具体测量延迟，给出了延迟的量化概念。
延迟的基本概念定义
为什么延迟会成为直播的一个很大的问题？每当传输的内容对延迟敏感时，比如体育，游戏，新闻等电视内容，还是电子竞技，赌博等纯OTT内容，都不希望有延迟。延迟的等待时间导致没有观看比赛的悬念；等待让观众成为娱乐和实时信息领域的二等公民。比如观看足球比赛时：你的邻居在电视上观看这场比赛，而你的OTT服务只能提供给你相对邻居有25-30s延迟的直播比赛，这就导致你在听到邻居的庆祝喊叫后，才看到接下来的进球，这是令人沮丧的，这也类似于你最喜欢的歌唱比赛结果被同时在观看比赛的Twitter或Facebook 所传播，而后者一般延迟较低，进而导致你又提前知道结果。
除广播传输延迟和社交网络竞争之外，内容提供商最大限度地减少实时传输延迟还有其他的原因。以前使用RTMP流的Flash应用程序在延迟方面表现良好，但随着Flash在Web浏览器中渐渐被弃用，CDN在交付方面也将弃用RTMP，因此内容提供商需要切换到HTML5友好的流式传输技术，如HLS和DASH，或最近的CMAF。其他一些内容提供商希望开发具有交互功能的个人广播服务，并且在这种情形下一般视频信号30秒延迟无法接受。此外，那些想要开发同步第二屏幕，社交会议等应用程序的人需要在更精细级别上控制流式传输延迟。
在延迟方面，通常会有三个级别，有两个边界划分，高边界和低边界，表一列出了不同级别延迟的划分。广播传输延迟一般为3到12秒，具体取决于传输方式(有线/IPTV/DTT/卫星)和每个传送网络拓扑的结构等细节。经常出现6秒的广播延迟的平均值，这意味着OTT的平均延迟点位于“reduced latency”的低范围或“low latency”的高范围内。
表1. 不同级别的延迟划分
使用基于HTTP的流媒体，延迟主要取决于媒体切片(segment)的长度：如果媒体切片长度为6秒，则意味着播放器已经比其请求第一个切片的实际时间晚至少6秒。许多播放器在实际开始播放之前将其他媒体切片下载到其缓冲区，这将自动增加到第一个解码视频帧的时间。当然，还有其他因素会产生延迟，例如视频编码过程的持续时间，摄取和打包操作的持续时间，网络传播延迟以及CDN缓冲区的延迟时间（如果有的话）。但在大多数情况下，播放器占总体延迟的最大份额。实际上，大多数播放器通常会使用保守的启发式算法并缓冲三个切片或更多切片的时间长度。
使用Microsoft Smooth Streaming，通常的切片长度为2秒，通常在Silverlight播放器中以大约10秒的延迟。使用DASH，情况几乎是一样的。大多数播放器可以支持2秒切片，但在延迟方面会有不同。但是HLS的情况完全不同：直到2016年中期，Apple的建议是使用10秒的切片，最终大多数HLS播放器（包括Apple自己的播放器）的延迟时间约为30秒。 2016年8月，Apple的技术说明TN2224表示，“我们过去建议使用10秒的目标持续时间。我们是不希望 突然重新细分 的内容。但我们确实相信，未来，6秒会是更好的方案。”每切片减少4秒，那么12秒的延迟就会消失。大多数时候，内容制作者都会遵循Apple的建议，即使iOS播放器可以使用较小的切片长度，因为他们不想冒险在AppStore中验证他们的iOS应用程序。但最近的三次改进改变了iOS11上Safari Mobile的情况：启用了实时HLS流的自动启动功能; 对短的segment持续时间的支持得到显著改善; 现在还支持FairPlay DRM。这意味着，内容制作者并非一定需要在iOS上使用已发布的应用程序才能用短的segment来减少实时传输延迟，而可以通过DRM提供受保护的流。
有些人可能会考虑到短的媒体切片在CDN和播放器上引入很高的负载，但多年来，Microsoft Smooth Streaming利用2秒切片一直就是这种情况。为了解决广播传输中的延迟，下一步计划是减少到1秒的切片，这实际上不会产生难以解决的问题。因为它将请求数量乘以2，所有HTTP开销都根据headers和TCP连接而定，而且它可以通过CDN进行管理（特别是如果它支持edge端的HTTP 2.0和origin端的HTTP 1.1，如Amazon CloudFront ），并且现在的播放器通过光纤，4G，LTE，DOCSIS 3.1 FD以及其他最先进的连接技术，可以从更高带宽以及最后一英里连接中受益。实验也表明，许多播放器现在支持1秒和2秒的短切片，因此提供了许多新的选项以降低延迟。而且对于HLS和DASH中的编码器，打包器和origin服务，短的segment也通常不是问题。除了仍然要求6秒持续时间的AppStore之外，内容制作者可以灵活地在所有平台上的各种播放器中试验1或2秒的媒体切片，这样做一般会减少延迟。
在较高的层面上，以下方式可以减少延迟：
- 优化视频编码的传输管道
- 根据要求选择合适的segment持续时间
- 构建适当的架构
- 优化（或替换）视频播放器
怎样测量延迟
延迟优化过程的第一步是知道传输链中的每个部分在总延迟中的占比，这可以让我们知道优化的优先级。 首先从测量端到端延迟(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 https://container.mediastore.eu-west-1.amazonaws.com/livehls/index_730.m3u8 && 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. 传输中的各阶段所占延迟比例
正如表中所看到的，编码和播放阶段产生了大部分延迟，这是大部分改善延迟的所要关注的地方。 但这并不意味着没有办法优化其他步骤，但优化的影响相对较小。当输出切片的大小增加时，播放器和最后一英里延迟通常会增加而其他阶段的延迟几乎保持稳定。
参考资料
https://aws.amazon.com/cn/blogs/media/how-to-compete-with-broadcast-latency-using-current-adaptive-bitrate-technologies-part-1/
