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

第一部分：定义和测量延迟
 第二部分：编码、打包和 CDN 分发的优化建议
 第三部分：视频播放器优化建议（本博文）
第四部分：参考架构和测试结果

第三部分：视频播放器优化建议

在本系列博文上一篇文章中，我们讨论了可以在视频工作流程的编码、打包和 CDN 分发步骤中采用的合理优化建议。接下来我们了解下延迟改进中最重要的方面 – 视频播放器的参数。即使您已优化上游工作流程的参数，但如果视频播放器没有集成面向低延迟的机制，那么这些优化工作也可能没什么用。在本部分，我们将讨论关于开源视频播放器的优化建议，并将介绍 AWS Elemental 技术合作伙伴 castLabs 和 Accedo 提供的面向商用播放器的方法，他们非常愿意与我们一起讨论这个主题。

视频播放器优化建议

视频播放器的优化目的通常是为最终用户提供流畅的播放体验，也就是说优先考虑缓冲长度，而不是降低流延迟。但这并不意味着视频播放器完全没有启用低延迟的选项，而是在每个播放器的初始化设置中，这些选项默认情况下未启用。

下面列出了会阻止播放器提供最低流延迟的部分问题：

初始缓冲区大小：大多数播放器的设计原则是在触发流播放之前缓冲特定数量的分段、时间（秒）或兆字节 (MB)。使用 1 秒和 2 秒的分段时，如果播放器不缓冲三个以上的分段，播放效果通常较好且延迟时间不会超过 10 秒。但部分播放器的设计原则是，如果实时播放列表/清单呈现较长的 DVR 可用时长，则会缓冲特定时长。在这种情况下，即使您的分段长度为 1 秒，最终也会缓冲 30 至 40 秒，因而无法提供低延迟体验。因此，您应该检查播放器的默认缓冲策略。如果播放器版本过旧，则寻找方法来限定启动时的缓冲长度。通常情况下，将缓冲时间限定为 3 秒或 4 秒可以在延迟和播放稳定性之间实现合理的平衡。缓冲时间低于 3 秒可以显著改善延迟，但在播放会话期间会出现定期的重复缓冲情况，从而影响用户体验。
与实时边缘时间相比，播放器在实时播放时间线中的初始定位：对于大多数播放器来说，有了前一个参数，该参数就是多余的，但也并非总是如此。如果播放器利用其他设置强制播放指针以 x 个分段或延迟 x 秒（与流的实时边缘时间相比）开始播放，则在播放器设置中设置较短的启动缓冲持续时间可能无效。这是个补充设置，需要您之后进行自定义。
实时边缘时间粘性：即使播放器以预期延迟（与实时边缘时间相比）开始播放，但如果发生重新缓冲的情况，播放器也可能在重新缓冲之前的最后已知时间码处恢复播放。也就是说，如果播放器只需要 100 毫秒的时间进行重新缓冲，那么在重新缓冲阶段之后，您将自动延迟与实时边缘时间相同的时间。这是所有播放器通常默认会发生的情况，但是有些播放器提供了相关选项，用于在出现空缓冲区（音频或视频轨道的缓冲区变为零秒并且卡在零秒处）后重新加载播放列表/清单，或者及时向前播放并同时继续关注实时边缘时间。如果您看重的是在整个播放会话中保持尽可能低的延迟，而不是让最终用户在实时会话中浏览每一秒内容，那么如果您的播放器是开源的话，可以采用或添加这种选项。总之，如果您不希望延迟随着时间的推移而变化，那么播放器中拥有这一功能至关重要。
恢复不可用分段的能力：可能是某个特定的媒体分段根本不可用，或者与播放器的期望相比有一些延迟。在这种情况下，播放器会重新尝试多次加载分段，如果在所有重试尝试之后分段还是不可用，则播放器可能会暂停播放会话。在这种情况下，用户可能希望查找播放器选项来增加重试次数，或者切换到较低的比特率，或者跳过时间线中缺少的分段。

开源播放器

hls.js

这款适用于 MSE（媒体源扩展）环境的开源 HLS 播放器确实在其 config.js 初始化文件中公开了许多不同的参数。您应该试试减少它的一些参数：

maxBufferLength（默认值：30 秒）：这是播放器尝试缓冲的最大秒数
maxBufferSize（默认值：60 MB）：这是播放器尝试缓冲的最大内容大小 (MB)
maxStarvationDelay（默认值：4 秒）：这是重新缓冲的最大允许秒数。强制播放器切换到较低的比特率可以降低此参数的值，从而防止出现较长的重新缓冲阶段。
liveSyncDurationCount（默认值：3）：这是启动时最后引用的分段背后加载的分段数。此参数的值越低，播放器的播放时间就越接近实时边缘时间。

在 hls.js 0.9.1 版本之前，如果您需要使用低于 1 秒的播放列表重新加载间隔，那么可以降低以下 level-controller.js 行中硬编码 1000 的值：
reloadInterval = Math.max(1000, Math.round(reloadInterval));

dash.js

这款适用于 MSE 环境的开源 DASH 播放器提供了几种方法，用于设置与实时边缘时间相比的初始延迟。player.setLiveDelayFragmentCount（默认值：4）：允许指定实时边缘时间后面的分段数，而 player.setLiveDelay 以秒为单位对其进行指定。一个实时延迟播放器样本指明“如果请求的流关于分段范围以及源缓冲区开始解码所需的数据量，则最终获得的延迟是分段持续时间的函数值”。您可以自定义的其他方法参数如下：

player.setFragmentLoaderRetryInterval（默认值：1000 毫秒）：将失败的分段加载尝试间隔设为分段长度的三分之一
player.setFragmentLoaderRetryAttempts（默认值：3）：可以增加此参数的值以补偿以前的自定义值
player.setBandwidthSafetyFactor（默认值：0.9）：可以将该参数的值降低至 0.5 以强制执行更保守的吞吐量计算
player.setStableBufferTime（默认值：12 秒）：可以大幅降低该值以限制后启动/搜索缓冲区目标，并轻松实现更快的比特率切换
player.setBufferToKeep（默认值：20 秒）：可以大幅降低该值以限制源缓冲区长度并允许对缓冲的比特率变体进行更灵活的切换
player.setBufferTimeAtTopQuality（默认值：30 秒）：可以大幅降低该值以在播放最高质量视频时限制内部缓冲目标
player.setLowLatencyEnabled（默认值：false）：从 v.2.6.8 开始，可以将此参数设置为“true”，以便利用浏览器 Fetch API，而不是传统的 XHR 加载机制。该参数对于较长的 DVR 可用时长延迟很有效。

Exoplayer

这款适用于 Android 的开源播放器兼容多种流媒体格式，包括 HLS 和 DASH。采用 HLS 时，当播放列表引用的分段太少时，Exoplayer 会遇到一些困难。采用 DASH 时，默认情况下支持清单中列出的 recommendedPresentationDelay。您可以修改一些参数来优化低延迟体验：

您可以增加 HlsMediaSource 和 DashMediaSource 类中 DEFAULT_MIN_LOADABLE_RETRY_COUNT 的值（默认值：3），以便在发生 404 错误时允许针对分段进行更多重试
您可以减少 ChunkedTrackBlacklistUtil 类中 DEFAULT_TRACK_BLACKLIST_MS 的值（默认值：60000），以降低因连续发生 404 错误而将比特率变体列入黑名单的可能性
最后，您可以减少 DefaultLoadControl 类中以下默认缓冲值：DEFAULT_MAX_BUFFER_MS（默认值：3000）、DEFAULT_BUFFER_FOR_PLAYBACK_MS（默认值：2500）和 DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS（默认值：5000），以更准确地控制查找或重新缓冲之后播放会话启动时可以加载多少内容

Shaka 播放器

因为默认值相对比较保守，这款适用于 MSE 环境的开源 HLS 和 DASH 播放器提供了几个可以修改的参数选项，以实现更低的延迟：

streaming.bufferingGoal（默认值：10 秒）是播放器尝试缓冲的内容秒数，会影响加载的分段数
streaming.rebufferingGoal（默认值：2 秒）是播放器在开始播放之前需要缓冲的内容秒数。该参数适用于启动和重新缓冲阶段。如果 DASH manifest minBufferTime 大于该值，则会将其覆盖。
retryParameters.maxAttempts（默认值：2）是播放器停止播放之前指定分段的最大请求数
retryParameters.baseDelay（默认值：1000 毫秒）是重试之间的基本延迟
retryParameters.timeout（默认值：0，等于 never）是定义请求超时的延迟（以毫秒为单位）
retryParameters.backoffFactor （默认值：2）是应用于 baseDelay 的乘数，用于增加重试之间的延迟

所有 retryParameters 还可应用于清单。

商用播放器

免责声明：本博文中的内容和意见属于第三方作者，AWS 不对本博文的内容或准确性负责。
这些结果来自与本系列博文第 4 部分场景 4 匹配的参考架构进行的测试。

适合所有 castLabs 播放器的 Common-Configuration 和 Common-ABR

播放器开发工具包的 PRESTOplay 套件包含“Common-Configuration”框架。Common-Configuration 为各个播放器使用相同的 JSON 对象，因此当跨多个设备和平台构建播放应用程序时可以节省开发时间，并简化跨播放器执行的 A/B 测试流程。

PRESTOplay 开发工具包的独特功能允许：

在 castLabs 的所有 PRESTOplay 开发工具包中使用相同的设置
简化开发流程并且统一最终用户体验
“Common-ABR”：经过改进的启发式算法和缓冲，包括针对低延迟实时流式传输的独特优化
手动覆盖标准流类型的“安全要求”（例如，克服 HLS 的 3 个分段延迟），实现最佳的延迟

“Common-ABR”功能是对 Common-Configuration 的补充。Common-ABR 是 castLabs 的 PRESTOplay 产品的独特功能，可在所有播放器平台上采用相同的自适应比特率启发式/算法和缓冲逻辑。其中明确包含 iOS，其他播放器供应商只能通过采用标准 ABR 和缓冲逻辑的本机播放器来支持 iOS。castLabs 开发的 Common-ABR 具备独特功能，可实现严格控制的超低延迟，不仅远低于行业平均水平，而且超出当前流式传输协议的典型保证/标准。

我们能够实现低于 5 秒的延迟，并且确保播放器保持 +/-0.5 秒范围的精确度（前提是编码器生成的分段不超过 2 秒）。在最佳情况下，castLabs 的播放器可以通过 MPEG-DASH 格式的 1 秒分段实现 2.5 秒的延迟。

Common-Configuration 包括针对实时低延迟场景的播放器初始化设置。例如，下面的选项与低延迟播放相关，并且在我们的浏览器、Android 和 iOS 播放器技术中均相同。在我们未来支持的播放器平台中，同样如此。以下是 Common-Configuration 选项，在所有 PRESTOplay 播放器平台上均可使用，以启用独特的 Common-ABR 低延迟模式。

{
…
“lowLatencyMode”: true,
“suggestedPresentationDelayMs”: 0,
“lowLatencyCatchupMode”: “speedup|seek|none”,
“lowLatencyCatchupThresholdMs”: 3000,
“lowLatencyCatchupRate”: 1.1
...
}

启用“lowLatencyMode”之后，播放器将尝试紧跟实时边缘并尽可能贴近此边缘播放。如果未明确指定，则在低延迟模式下，与实时边缘的距离将设为 0。您可以使用“suggestedPresentationDelayMs”参数进一步调整该值。

动态实时边缘跟踪

当播放器落后于当前实时边缘时，您可以使用“lowLatencyCatchupMode”配置播放器的行为。当缓冲区数据不足，而播放器正在等待数据时，就会发生这种情况。如果该参数设为“none”，则播放器将不会提高播放速度，而只是按照当前的速度继续播放。如果设为“speedup”，则只要当前的播放位置比当前实时边缘落后“lowLatencyCatchupThresholdMs”毫秒以上，播放器就会提高播放速度。加速速率可以通过“lowLatencyCatchupRate”参数进行控制，而且当播放器再次靠近实时边缘时，该速率将被设为 1.0。如果该参数设为“seek”，则如果播放器的落后长度超过配置的阈值，播放器将跳转到实时边缘。

以下是使用 AWS Elemental 对流和 castLabs 播放器进行测试获得的结果（测试由 AWS Elemental 团队执行）：

播放器	3x1s HLS	3600x1s HLS	3x1s DASH	3600x1s DASH
castLabs 播放器（Web 版）			3.80s	4.31s
castLabs 播放器 (Android 6.0.1)	3.79s (TS)	4.96s (TS)	5.51s	5.57s

castLabs 是全球数字视频市场软件和云服务的先驱。
该公司提供的解决方案可轻松实现安全分发优质电影、电视和音频资源，从而提供高质量的视频体验。该公司提供众多应用程序和服务，旨在帮助企业通过大量消费者设备和平台提供受 DRM 保护的内容。castLabs 总部位于德国柏林和美国加利福尼亚州洛杉矶。网站：castlabs.com，Twitter：@castlabs，LinkedIn：www.linkedin.com/company/castlabs

castLabs 是全球数字视频市场软件和云服务的先驱。

该公司提供的解决方案可轻松实现安全分发优质电影、电视和音频资源，从而提供高质量的视频体验。该公司提供众多应用程序和服务，旨在帮助企业通过大量消费者设备和平台提供受 DRM 保护的内容。castLabs 总部位于德国柏林和美国加利福尼亚州洛杉矶。网站：castlabs.com，Twitter：@castlabs，LinkedIn：www.linkedin.com/company/castlabs

在 Accedo，我们的工作重点是为用户提供优质的视频体验。虽然我们没有提供自己的专有播放器，但我们已经深入研究视频和实时 Feed 流式传输的最佳实践。对于我们来说，这个问题既涉及流启动时间，也涉及克服延迟。

第一个参数将对用户体验产生直接影响，因为该准备阶段花费的时间越长，就会增加“延迟”感。而如果缓冲区不够大，无法交付可靠的 Feed，则第二个参数可能会影响用户。对于开发人员，我们建议考虑以下因素以优化流启动时间：

在启动流之前限制（尝试消除）同步调用（例如，并发检查），然后在流开始传输之后异步执行调用
预料到播放行为（例如，用户处于资源详细信息页面，可能会发出播放请求）时，预取许可证
预取权限并确定用户是否有权流式传输资源
使用 QoE 工具分析“与第一帧的间隔时间”以及启动失败的原因，以帮助调整设置，因为网络特征因地区而异

关于克服延迟的问题，可以在缓冲区大小和延迟之间实现平衡。如果我们不打算根据 Apple HLS 的指导原则确定分段大小，那么考虑更小的区块并了解诸如以下参数在减少延迟方面发挥的作用确实很有意义：启动及流式传输时媒体缓冲的持续时间；重新缓冲事件之后媒体缓冲的持续时间；缓冲区的上限。

iOS 测试

在 iOS 11.2.5 上运用 default-buffer-control=true 和 AVPlayer automaticallyWaitsToMinimizeStalling = true 执行的测试。

流描述	加载时间（直到 AVPlayerItem.status 为 readyToPlay）	克服延迟（秒）	开始播放时已下载的视频分段数	开始播放时已下载的分段数乘以分段长度（秒）
HLS 3 x 1 秒分段播放列表	1.1988	5.4	3	3
HLS 3600 x 1 秒分段播放列表	1.67	5.4	5	4.98
HLS 3 x 2 秒分段播放列表	1.568	8.4	2	3.98

Android 测试

在支持 Exoplayer 2.5.4 的 Android 7.0 上运用以下参数执行的测试：default-buffer-sizes-for playback-start=2.5s、default-buffer-sizes-after-rebuffer=5s、stream-download-buffe-minimum=15s、stream-download-buffe-maximum=30s

流描述	加载时间（直到播放器状态为 readyToPlay；秒范围 – 采用 5 个样本）	平均加载时间（直到状态为 readyToPlay）	克服延迟（秒）	开始播放时已下载的视频分段数
HLS 3 x 1 秒分段播放列表	0.918 – 2.143	1.5	5.4	3
HLS 3600 x 1 秒分段播放列表	1.263 – 2.664	1.8	5.4	3
HLS 3 x 2 秒分段播放列表	0.503 – 1.393	1.1	6.4	2
DASH 3600 x 1 秒分段播放列表	3.177 – 3.421	3.3	7.4	4

虽然这些测试突显了分段越小、延迟月底这一点，但我们也不能忘记流可靠性的重要性。在 Accedo，我们建议在由 AWS 提供支持的 Accedo One Cloud 平台中设置与缓冲区相关的参数，以便客户控制这些参数并找出最合适的值。每个服务部署（编码、打包、CDN、区域网络）的分发链都是唯一的，虽然任何服务启动时都应采用安全配置初始化，但我们的客户应该考虑根据其独特的技术链定制这些参数，以尽可能减少延迟。得益于名为 Optimize 的 A/B 测试服务，我们的客户将能够测试不同的配置并评估对用户体验（重新缓冲、播放保留时间等）的影响，从而引导他们确定自己的优化设置。

Accedo：适合所有渴望变革的视频服务提供商
Accedo 是值得信赖的视频体验转型先锋，改善了数亿视频消费者的体验。有关更多信息，请访问 www.accedo.tv，Twitter：@accedotv，Facebook：www.facebook.com/accedo.smarttv

在下一篇博文中，我们将讨论几种运用 AWS Elemental 产品和服务的解决方案架构，以及使用参考播放器测量端到端延迟而得出的相关测试结果。

————

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

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

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

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

亚马逊AWS官方博客