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

阅读数:66 2019 年 10 月 8 日 15:57

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

第二部分:编码、打包和 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/

欲了解 AWS 的更多信息,请访问【AWS 技术专区】

评论

发布