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

第二部分：编码、打包和 CDN 分发的优化建议

在本系列博文的第一篇文章中，我们讨论了 OTT 流式传输的延迟问题，以及如何测量不同工作流步骤在端到端延迟方面的影响。接下来我们从编码、打包和 CDN 分发步骤开始，一起探讨可行的优化措施。通过更改文中提及的参数，您将能够为观众准备一场经过出色优化的低延迟现场直播。

编码

我们已经大体了解了如何通过使用“Low Latency Mode”输入参数借助 AWS Elemental Live 来优化拍摄延迟。请注意，此参数可能导致在输入时间戳不连续时丢失更多的音频数据包。虽然可能导致丢帧，但是也可以通过“Input Buffer Size”参数将输入阶段的缓冲帧数降至最低。

在视频编码部分，有几个参数可能会影响延迟：

• Lookahead：将该参数设置为“Low”会减少延迟，但也会降低高要求场景的输出质量。 不过，低 Lookahead 主要适用于没有或很少有场景变化的情况。

• GOP 参数：建议使用时长为 1 秒的封闭式 GOP，之后可根据需要以 2 秒分段重新打包。没有 B 帧的低 GOP 通常会降低视频质量。

• B 帧：因为编码引擎将预测下一个 P 帧来构建 B 帧，因此在 GOP 中使用的 B 帧越多，对每个添加的 B 帧，编码延迟增加数帧的概率就越高。不使用 B 帧有可能消除这种延迟影响，但是需要提高编码比特率，才能维持与使用 B 帧时相同的质量水平。

• 时间自适应量化：关闭该参数将减少数帧的延迟。其他适应量化选项不会影响延迟。

• 编码器缓冲区大小：默认值是视频比特率的两倍，会在解码器上产生 2 秒的延迟。如果设置为 1 倍比特率，则会产生 1 秒延迟，并会对视频质量产生轻微影响。对于要求很高的低延迟目标，可以将缓冲区大小设置为比特率的一半，这会导致半个 GOP（0.5 秒）的延迟。当然，对视频质量的影响也会更大；在 0.5 倍比特率下，对视频质量的影响将更为严重。

• 视频预处理器：如果需要影像解交错处理器，则应选择“低延迟”插值算法。

• 在 AWS Elemental MediaLive 中，在“Stream Setting”（流设置）>“Stream Setting”（帧速率）部分，除了未显示的最后一个通过渐进式扫描类型的设置之外，还提供了相同的设置。在编码阶梯方面，建议在阶梯的下端添加一个轻量级的流，这样在网络环境不佳的情况下，尽管分段大小会比通常短一些，但是移动设备将仍然能够访问流。

打包

几乎对所有播放器而言，分段时长都会对延迟产生机械影响。时长为 1 秒的分段，延迟可能达到 5 秒。对于时长为 2 秒的分段，这种情况几乎不会发生，除非对播放器设置进行严格的优化，否则延迟会在 7 到 10 秒之间。1 秒分段将自动生成较小的播放器缓冲，因此，除非播放器提供特定机制来快速克服空缓冲区，否则播放会话的稳定性会较差。

针对您的需求选择合适的分段大小至关重要。如果您并非一定需要将延迟控制在 7 秒以内，那么请使用 2 秒（而非 1 秒）分段，它足够将延迟控制在 7 秒到 10 秒之间。为您的播放器应用 2 秒片段，还将为您带来如下好处：

将 GOP 长度从 1 秒提高到 2 秒，可在恒定比特率下提高编码质量。

由于 2 秒分段减少了对源存储和打包运算的压力，因此能在您的源站上使用 2 秒分段进行摄取（如果使用 HLS 作为摄取格式）。

索引时长（DVR 可用时长）也会影响延迟。有些播放器在播放列表/清单中显示一个 1 小时 DVR 可用时长时，需要比在播放列表/清单中只显示最后 3 个分段时缓冲更多内容。

使用 AWS Elemental Live 时，因为需要比平时更快地纠正网络传输错误，因此您需要降低发布 HLS/DASH 的重试间隔。将 2 秒分段设置为 1 秒，将 1 秒分段设置为 0 秒。

CDN 分发

通过更改 CDN 配置减少延迟的方法较少。Amazon CloudFront 不会沿链添加人工缓冲区。如果您将其他 CDN 与 AWS Elemental 源站服务结合使用，您可能会发现 CDN 架构特意生成了一个 CDN 内部缓冲区。如果可能，在这种情况下，请联系 CDN 专业服务部，在您的分发配置中禁用该缓冲区。

对于 HLS 播放列表和 DASH 清单，如果播放器支持此类压缩，则应检查 CDN 配置是否允许提供 gzip 格式的列表或清单。在 HLS 或 DASH/SegmentTimeline 中使用较长的 DVR 可用时长，将简化加载操作。

由于处于低延迟模式的播放器与实时边缘时间相比，其请求更加迫切，因此他们可能会提前请求分段，从而导致在边缘出现 404 错误。每个 CDN 都有一个唯一的默认 TTL 值用于缓存这些 404 错误，通常这个值对低延迟流不适用，因此需要对其进行调整。您可以在配置面板的“Error Page”（错误页面）部分将 Amazon CloudFront 分发设置为 1 秒。

与低延迟无关，但对于您的工作流同样非常重要：您需要将“源站”入站标头加入白名单，以便您的 CDN 将其转发到源站，因为它是所有由您的源站返回的下游 CORS 策略的关键触发器。对于 Amazon CloudFront，您可以在配置面板的“Behaviors”（行为）部分进行设置。

最后，如果在 CDN 端设置了 HLS 播放列表或 DASH 清单的 TTL，则应验证它们是否短于或等于 HLS 分段间隔或 DASH 清单更新间隔。

在下一篇博文中，我们将研究哪些优化选项可以应用于视频播放器。

————

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

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

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

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

作者介绍：

Nicolas Weil

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

本文转载自 AWS 技术博客。

原文链接：

https://amazonaws-china.com/cn/blogs/china/compete-broadcast-latency-bitrate-tech2/