hls延迟的原因(如何降低hls协议延迟)

苹果的HTTP实时流媒体(HLS)协议是当今视频传输的首选格式,尽管它并非没有缺点,即延迟。但是,流媒体人仍然对它趋之若鹜,因为它的可靠性和与无数设备的兼容性。随着对延迟问题的关注,苹果公司响应号召,开发了一个低延迟的扩展。低延迟HLS(LL-HLS)使HLS协议成为寻求更实时体验的流媒体人的可行解决方案。

在本文中,我们将探讨 HLS 延迟的原因以及如何降低hls协议延迟。

了解 HLS 协议

与其他流媒体协议一样,HLS 通过最后一英里交付将音频和视频媒体从媒体服务器传输到播放设备。HLS 将此媒体分解为一系列流媒体段,每个流媒体段都单独压缩并以一致的流形式发送以实现平稳传输。其他流媒体协议,如基于 HTTP 的动态自适应流媒体 ( MPEG-DASH ),工作方式类似。但是,使 HLS 与众不同的是其广泛的兼容性。 

这是因为 HLS 是由 Apple 开发的,这家公司因将其设备限制在专有技术而臭名昭著。因此,几乎任何设备都可以流式传输 HLS,但 Apple 设备 只能 流式传输 HLS。这样一来,HLS 的流行对于任何想要触及 Apple 播放设备的人来说都是必不可少的产物。

HLS 如何运作

通常,HLS 是混合RTMP 到 HLS工作流的后半部分  。原始媒体经过编码并通过 RTMP 发送到媒体服务器,在那里它被转码为 HLS 媒体段,也称为块。这些块可能包括用于自适应比特率 (ABR) 流式传输的多个比特率变体。 

典型的 RTMP 到 HLS 工作流程,其中实时流编码为 RTMP 并重新打包为 HLS,以便在各种设备上播放。

媒体服务器将这些块组织成一个播放列表或清单,然后根据该清单(HLS 使用 .m3u8 播放列表)文件剪切并重新组合视频块。这个过程称为预加载,可确保块以正确的顺序交付。它还允许媒体服务器根据 ABR 反馈准备块。换句话说,当它以特定的视频比特率将块发送到给定的播放设备时,它会持续接收有关该设备可用带宽的反馈。因此,它可以选择更高或更低比特率的后续块以确保最佳视频质量。 

通过使用 ABR 变体对媒体进行分块,HLS 可以通过高质量的流可靠地覆盖更广泛的受众。但是,该过程也会减慢流的速度,从而导致延迟。 

图形可视化:自适应比特率流

引入低延迟 HLS

Apple 的 LL-HLS 是在 HLS 协议首次发布十年后于 2019 年首次宣布的协议扩展。2020 年,Apple 将 LL-HLS 完全纳入更广泛的 HLS 标准。从那时起,对于那些喜欢 HLS 的可扩展性和适应性但不喜欢它的迟缓性的人来说,它一直是一个可行的选择,尽管仍在开发中。此协议扩展将 HLS 延迟从超过 45 秒减少到只有两到三秒,部分原因是获取视频片段并将它们进一步分解为部分片段以加快交付速度。

HLS 延迟的原因

出于与 HLS 出色的许多相同原因,它在交付速度方面拖累了它的治疗。HLS 延迟的来源包括 HLS 的 编码、转码、分发和默认播放缓冲区要求。 

使用 HLS 进行流式传输时,Apple 建议使用 6 秒的块大小(也称为片段持续时间)和一定数量的数据包来创建有意义的播放缓冲区。这导致大约 20 秒的玻璃到玻璃延迟。此外,当您引入 CDN 以实现更大的可扩展性时,您又注入了 15-30 秒的延迟,这样服务器就可以缓存传输中的内容——更不用说任何可能减慢流传输速度的最后一英里拥塞了。 

由于这些原因,当交互性或类似广播的速度很重要时,标准 HLS 不是一个可行的选择 。没有人愿意在“直播”播放中忍受高延迟。同样,较大的延迟会中断游戏流媒体和用户生成内容 (UGC) 应用程序(如 Facebook Live 或 Twitch)的双向性质。如今的消费者希望他们的内容能够尽快到达,而不管流媒体应用程序的真实性如何。 

调整 HLS 以实现低延迟

流式传输低延迟 Apple HLS 内容的一种选择是调整您的工作流程。思路如下:

  1. 减少 HLS 块大小。目前,在 HLS Cupertino 默认设置中,Apple 建议每个片段持续时间的长度至少为 6 秒。HLS 块只会在关键帧边界上创建,因此如果减小最小块大小,则需要确保它是关键帧间隔的倍数或调整关键帧间隔以适应。
  2. 增加块的数量。如果连接中断,可以存储块构建一个重要的缓冲区。默认值为 10,但对于减少延迟的流式传输,我们建议存储 50 秒的块。
  3. 修改播放列表块计数。HLS 播放列表中的项目数默认为三个,但对于延迟较低的场景,我们建议向播放器发送 12 秒的数据。这可以防止播放列表请求之间丢失块。
  4. 设置最小块数。您要调整的最后一件事是在播放开始之前必须接收多少块。我们建议传送至少 6 秒的块。

HLS的替代格式

幸运的是,有一些风险较低的替代方案可以加快速度:前面提到的 Apple 低延迟 HLS、 Web 实时通信 (WebRTC)和用于 DASH (LL-DASH) 的低延迟 CMAF。

Apple 低延迟 HLS(LL-HLS)

Apple 的低延迟 HLS 协议旨在大规模实现大约两秒的延迟,同时还为现有客户端提供向后兼容性。

用于 DASH 的低延迟 CMAF

MPEG-DASH 与 HLS 一样,是一种基于 HTTP 的自适应协议,可以分段流式传输并可以利用 ABR 流式传输。然而,与 HLS 不同的是,MPEG-DASH 不是专有的,并且与 Apple 缺乏关联,因此不太受广泛支持。 

DASH的低延迟通用媒体应用格式 (CMAF) 是 MPEG-DASH 的快速替代品。但是,它比协议扩展要复杂一些。CMAF 是一种更新的媒体格式,用于打包基于 HTTP 的媒体,旨在标准化流媒体并提高 HLS 和 DASH 之间的交叉兼容性。CMAF 减少块大小的标准化促进了更低的延迟。当 MPEG-DASH 使用 CMAF 标准进行媒体打包和交付时,您将获得用于 DASH 的低延迟 CMAF,也称为低延迟 MPEG-DASH。

WebRTC

WebRTC 向任何主要浏览器提供近乎即时的流媒体传输。该技术专为视频会议而设计,因此支持 低于 500 毫秒的延迟 ——无需第三方软件或插件。

HLS 备选方案比较图表

LL-HLS用于 DASH 的 LL-CMAFWebRTC
延迟时间大约 2 秒大约 2 秒毫秒级
可扩展性 高度可扩展 可扩展到有限的设备 可通过额外的基础设施进行扩展
兼容性 高度兼容 不适用于 Apple 设备与其他资源高度兼容
适应性ABR 流媒体选项ABR 流媒体选项WebRTC 联播和 SVC 选项

版权声明:本文内容转自互联网,本文观点仅代表作者本人。本站仅提供信息存储空间服务,所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至1393616908@qq.com 举报,一经查实,本站将立刻删除。

(0)

相关推荐

发表回复

登录后才能评论