Home 技术文章 借助更快的CDN实现低延迟实时流媒体传输
Applications

借助更快的CDN实现低延迟实时流媒体传输

About The Author

Outline

观看体育直播是令人兴奋的。 特别是在关键时刻,例如当一个镜头走出无处赢得比赛. 对于负责提供流畅,实时行动的技术团队来说,这些时刻也是令人兴奋的。 直播体育流必须平衡几个技术考虑因素和权衡,平均比现场比赛落后约30秒。 为什么要拖延?

虽然 内容交付网络 至关重要,但它们无法减少视频工作流的其他部分造成的延迟。 例如,当图像转换为信号时,从摄取时刻开始添加延迟。 然后,原始信号必须转换成压缩格式并传输到视频处理中心,通常是在场外,通常是在云中,这可能会受到可用带宽和基础设施的影响。 接下来是对各种设备和带宽的内容进行转码和打包。 最后,随着流媒体的播放,广告可能会在流媒体通过Internet的最后一英里移动到观众的设备之前动态地插入到流媒体中。 在这里,播放器缓冲区解码,解压缩和渲染最终视频片段。 这是团队赢得比赛的目标和内容交付网络之间的许多步骤。 他们可以累加起来,尤其是当它必须发生在数百万观众同时. 例如,超级碗直播流的延迟平均为 28到47秒

降低延迟 已成为流媒体服务提供商的关注焦点。 对于与分秒游戏赌注相关的体育项目,如赛马,延迟的溪流会使偏远地区的参与者处于不利地位。 观众和新闻发布者在会场上发布的实时推文可以破坏粉丝在电视上观看和直播的激动人心的时刻。 随着越来越多的观众在观看直播体育赛事的同时使用第二个屏幕,减少直播时间已成为保持竞争力和提供出色观看体验的重要要求。

减少延迟是Edgecast (现在称为Edgio)的一个重点领域。 这项工作涉及研究和实施每个处理步骤的增量改进,以及交付实时流所涉及的其他因素。 在这篇文章中,我们将了解延迟减少的一个具体方面所涉及的内容,即我们的内容交付网络如何处理日益流行的低延迟策略(即减少分段大小)导致的请求量增加。

为了缩短直播时间,流媒体服务提供商开始采用更短的HLS或DASH数据段持续时间。 这可以显著降低延迟,但也有一些折衷,例如额外开销和增加的重新缓冲风险。 与其他QoE考虑因素相比,这些权衡是否值得完全取决于对延迟的优先级。 在某些情况下,如上所述,低延迟是最优先考虑的问题,而在其他情况下,当前延迟级别可能可以接受,以提供个性化广告,4K编程或允许编辑实时内容。

段大小在延迟中的作用

流媒体视频行业长期以来一直使用自适应比特率(ABR)技术,这些技术将流媒体分成许多单独的视频片段或块。 每个分段具有相同的持续时间或大小,但以不同的视频质量级别或比特率进行编码,以便流媒体可以在请求新分段时适应观众的可用带宽。 Apple的HLS和MPEG-DASH这两个主要的ABR协议都提供了用于调整分段大小的控件。

分段大小在延迟中起着重要作用,因为播放器必须先下载预设数量的分段,然后才能开始播放直播流。 这样做是为了使客户端视频播放器可以缓冲足够的视频,以确保在网络拥塞时流畅地播放视频,而无需重新缓冲。 然而,这也使流从一开始就落后现场. 通常,iOS设备和Web浏览器上的嵌入式视频播放器会在开始播放之前缓冲三个视频片段。 如果一段的长度为4秒,并且玩家必须先缓冲三段才能开始播放,那么客户端已经比直播晚了12秒。 DASH协议允许清单文件指定需要缓冲的文件量,从而提供了一定的灵活性。 尽管如此,许多仪表板播放器和设备尚未实现此功能。

缩短生命后的时间

由于缓冲三个段是事实上的标准,因此最常用的缩短实时时间的方法是缩小每个段的大小或持续时间。 在下面的示例中,通过将分段大小从四秒减少到两秒,实时后的时间将缩短到仅六秒-只有四秒分段的一半。

较小的数据段可能会导致重新缓冲

使用较小的分段大小时,视频工作流必须响应更快,才能提供无缓冲的实时视频流体验。 这是由两个因素造成的:

首先,通过减小片段大小,存储固定数量片段的播放器现在存储的视频更少。 由于较短的分段大小意味着更多文件,您的视频工作流以及最重要的是,内容交付网络必须在给定的流媒体持续时间内处理和交付两倍于播放器的文件请求。 由于在网络拥塞期间播放机中缓冲的视频较少,因此拥塞更有可能导致重新缓冲。 玩家现在对拥塞更加敏感,即使在较小的拥塞事件中也是如此。

其次,正如我们在最近的一篇技术文章”优化直播流媒体的CDN “中所解释的那样,在直播体育赛事中,当热门活动开始或接近最后几分钟时,观众人数激增是常见的现象。 随着文件请求数量的增加,CDN需要在相同的时间内容纳更多文件请求。 自适应比特率参数指定的各种设备类型和连接速度使此任务更加复杂。

为了说明文件容量的增加,图2显示了一个16秒的视频段,以不同长度的段提供。 对于四秒分段,只需四个文件即可交付16秒分段。 但是,当我们迁移到两秒段时,我们需要八个单独的文件–需要通过CDN处理的文件数量是CDN处理的文件数量的两倍。

通过热归档提高分段交付性能

我们创建了一个称为”热归档”的功能,以处理所谓的”闪光人群”现象,当许多直播观众同时加入一个流时。 此功能指的是在POP (入网点)内将流行的段或”热文件”快速复制到其他服务器,以便能够随着需求的快速增长而快速交付给观众。

通过将负载分散到多个服务器,热归档可防止任何一台服务器因文件请求突然激增而不堪重负。 当服务器过载时(类似于拒绝服务攻击),服务器对文件请求的响应速度将变慢,可能导致客户端播放器中的重新缓冲。 通过快速识别和复制热文件,单个服务器过载的风险要低得多。 现在可以在不增加延迟的情况下满足需求的突然变化。

图3显示了热归档(图3b)如何通过防止服务器过载来提高性能。 如果不进行热归档(图3a),段的所有流量都将转至服务器1 (S1)。 随着受众需求的激增,额外的流量会流向S1,使其超过100个用户的容量。 由于S1在高峰时段为200名观众提供服务,这种情况继续恶化。 相反,热归档(图3b)通过将文件复制到两个服务器(S1和S2)并将文件请求重新路由到新可用的服务器来处理这种额外的负载。

更快的热文件识别

我们最近通过将热文件移动到多个服务器的时间缩短一秒来增强热归档功能。 我们通过更改在弹出窗口中识别热文件的方式来缩短反应时间。 我们使用一个中央进程来聚合文件请求和字节计数以进行分析。 以前,数据是从每台服务器上的Web服务器进程中提取的。 虽然这种方法运行良好,但我们发现速度较慢的Web服务器可能会降低热文件数据的聚合速度。 为了解决此问题,服务器现在每秒将其请求和字节计数写入光盘。 因此,当中央进程提取数据时,它不必等待Web服务器进程,因为数据已写入固态磁盘。 仅此更改就足以适应大多数直播活动的负载。

图3c显示了对现场事件快速反应时间的关键重要性,它提供了有关热归档流程如何招聘额外资源的见解。 在图3c所示的示例中,当S1服务器超过其100个用户的容量时,文件会在达到容量时快速移至S2。 这使系统能够迅速有效地容纳所有200个用户,并充分利用可用服务器的全部容量。

在多个端口上进行热归档

对于极受欢迎的活动,如职业足球季后赛或主要的国际足球比赛,交通高峰和激增可能非常显著。 要满足这一需求水平,还需要更改文件段的复制方式,以增加服务器容量。 以前,内容交付网络仅限于将分段复制到每台服务器的一个端口。 但现在,我们可以将文件复制到每台服务器的多个端口。 这大大提高了每台服务器的吞吐量,因此每个POP可以处理更多的请求,从而处理比以前大得多的实时事件。

在我们的系统中,负载平衡由缓存阵列路由协议(CARP)哈希处理。 对于常规内容,我们的方法是跨多个服务器复制文件,我们使用CARP哈希从每台服务器选择一个端口。 这样做是为了防止向源服务器发送重复的请求,并限制进程间通信。

当文件变得足够热时,CARP开始为每台服务器选择多个端口以支持更多请求。 这种方法适用于热文件,因为它们只是服务器提供的唯一文件的一小部分。 打开的端口数取决于对热文件的需求。 这种方法增加了每台服务器的数据量和可用于处理这些请求的CPU功率。

结论

随着 流媒体服务 提供商减少视频片段的大小以提供更低的延迟直播流,Edgio的平台热归档功能可帮助内容交付网络管理不断增加的视频文件请求,尤其是当受众规模不断扩大以观看流行的体育赛事时。