直播体育赛事令人兴奋。 尤其是在关键时刻,比如一个射门无处可胜的时候。 对于负责提供流畅，实时行动的技术团队来说，这些时刻也会令人兴奋。 直播体育流媒体必须平衡多项技术考虑因素和权衡因素，平均比现场直播比赛晚30秒左右。 为什么要延迟？
虽然内容交付网络至关重要，但它们无法减少视频工作流其他部分造成的延迟。 例如，当图像转换为信号时，从摄取的那一刻起就会增加延迟。 然后，原始信号必须转换为压缩格式，并传输到视频处理中心，通常在场外，通常在云端，这可能会受到可用带宽和基础设施的影响。 接下来是针对各种设备和带宽对内容进行转码和打包。 最后,在流媒体播放时,广告可能会动态地插入流媒体,就在它通过互联网的最后一英里移动到观众的设备之前。 在此，播放器缓冲区将解码，解压缩并渲染最终的视频片段。 这是团队的制胜目标和内容交付网络之间的许多步骤。 它们可能会累积起来，尤其是当数百万观众同时发生这种情况时。 例如,超级碗直播流的延迟平均为28到47秒。
减少延迟已成为流媒体服务提供商的重点。 对于与瞬间投注相关的体育赛事，如赛马，延迟流会使远程参与者处于不利地位。 来自观众和新闻播报员的实时推文可以破坏粉丝在电视和直播流媒体上观看的精彩时刻。 随着越来越多的观众在观看直播体育赛事时使用第二个屏幕，缩短直播时间已成为保持竞争力和提供出色观看体验的重要要求。
减少延迟是Edgecast (现为Edgio)关注的一个领域。 这项工作涉及研究和实施每个处理步骤的增量改进以及交付直播流所涉及的其他因素。 在这篇文章中，我们将了解延迟减少的一个特定方面涉及的内容–我们的内容交付网络如何处理日益流行的低延迟策略(即缩小网段大小)导致的请求量增加。
为了缩短直播时间，流媒体服务提供商开始采用更短的HLS或DASH段持续时间。 这可以显著减少延迟，但也有一些权衡因素，例如增加开销和增加重新缓冲的风险。 这些权衡是否值得，完全取决于与其他QoE考虑因素相比，对延迟的优先级。 如上所述，在某些情况下，低延迟是头等大事，而在其他情况下，当前延迟级别可能可以接受，以交付个性化广告，4K编程或允许编辑直播内容。
段大小在延迟中的作用
流视频行业长期以来一直使用自适应比特率(ABR)技术，将流分解为多个单独的视频片段或数据块。 每个片段具有相同的持续时间或大小，但以不同的视频质量级别或比特率进行编码，因此流可以在请求新片段时适应观众的可用带宽。 两种主要ABR协议,苹果的HLS和MPEG-DASH,都提供调整段大小的控制。
片段大小在延迟方面起着重要作用，因为播放器必须先下载预设数量的片段，然后才能开始播放直播流。 这样，客户端视频播放器就可以缓冲足够的视频，以确保流畅的视频播放，而不会在网络拥塞时重新缓冲。 然而，这也使流从一开始就落后于现场直播。 通常，iOS设备和Web浏览器上的嵌入式视频播放器会在开始播放之前缓冲三个视频段。 如果一个片段长度为四秒,并且玩家必须缓冲三个片段才能开始播放,则客户端已经落后于直播12秒。 DASH协议允许清单文件指定需要缓冲的文件数量，从而提供了一定的灵活性。 然而,许多Dash播放器和设备尚未实现此功能。
缩短延迟上线的时间
由于缓冲三个段是事实上的标准，因此缩短生存时间的最常用技术是缩小每个段的大小或持续时间。 在下面的示例中，通过将片段大小从四秒缩短到两秒，直播时间缩短到仅六秒，这是四秒片段的一半。
较小的段会导致重新缓冲
当使用较小的网段时，视频工作流必须响应更快，以提供无缓冲的实时视频流体验。 这是由于两个因素造成的：
首先，通过缩小片段大小，存储固定数量片段的播放器现在存储的视频更少。 由于较短的网段大小意味着更多文件，因此您的视频工作流以及最重要的是，内容交付网络必须在给定的流媒体持续时间内处理和交付两倍于播放器的文件请求。 由于在网络拥塞期间播放器中缓冲的视频较少，因此拥塞更有可能导致重新缓冲。 玩家现在对拥塞更加敏感,即使在较小的拥塞事件中也是如此。
其次，正如我们在最近的一篇科技文章”优化CDN进行直播流媒体”中所解释的那样，在直播体育赛事开始或接近最后几分钟时，观众人数激增的现象很常见。 随着文件请求数量的增加，CDN需要在相同的时间内容纳更多的文件请求。 此任务由自适应比特率参数指定的各种设备类型和连接速度组成。
为了说明文件音量的增加，图2显示了以不同长度段传送的16秒视频段。 对于四秒分段，只需四个文件即可交付16秒分段。 但是，当我们迁移到两秒钟的分段时，我们需要八个单独的文件，这是需要通过CDN处理的文件数量的两倍。
通过热归档提高分段交付性能
我们创建了一个名为”热归档”的功能，以应对多个实时观众同时加入流媒体的所谓”快闪拥挤”现象。 此功能是指将流行的网段或”热文件”快速复制到POP (入网点)中的其他服务器上，以便随着需求的快速增长，将其交付给观众。
通过将负载分散到多个服务器，热归档可以防止任何一台服务器在文件请求突然达到峰值时不堪重负。 当服务器过载(类似于拒绝服务攻击)时，服务器对文件请求的响应速度会很慢，这可能导致客户端播放器重新缓冲。 通过快速识别和复制热文件，单个服务器过载的风险大大降低。 现在可以在不增加延迟的情况下满足需求的突然变化。
图3显示了热归档(图3.b)如何通过防止服务器过载来提高性能。 没有热归档(图3.a)，数据段的所有流量都将转到服务器1 (S1)。 随着观众需求高峰，额外的流量将流向S1，使其超过100个用户容量。 由于S1在高峰期为200名观众提供服务，情况继续恶化。 相反，热归档(图3.b)通过将文件复制到两台服务器(S1加S2)并将文件请求重新路由到新可用的服务器来处理这一额外的负载。
更快的热文件识别
我们最近将热文件移动到多个服务器的时间缩短了一秒钟，从而增强了热归档功能。 我们通过更改Hot文件在Pop中的识别方式来缩短反应时间。 我们使用一个中央流程来汇总文件请求和字节计数以进行分析。 以前，数据是从每台服务器上的Web服务器进程中提取的。 虽然这种方法工作正常，但我们发现速度较慢的Web服务器可能会减慢热文件数据的汇总速度。 为了解决这一问题，服务器现在每秒将请求和字节计数写入光盘。 因此，当中央进程提取数据时，它不必等待Web服务器进程，因为数据已写入固态磁盘。 仅此更改就足以适应大多数实时事件的负载。
图3.c显示了现场活动快速反应时间的关键重要性，该图提供了有关热备案流程如何招募额外资源的深入见解。 在图3.c所示的示例中，当S1服务器超出其100个用户的容量时，文件会在达到容量时迅速移至S2。 这使系统能够迅速有效地容纳所有200名用户，并充分利用可用服务器的全部容量。
在多个端口上进行热归档
对于非常受欢迎的赛事，例如职业足球季后赛或大型国际足球比赛，流量激增可能非常显著。 满足这种需求水平还需要更改文件段的复制方式以增加服务器容量。 以前，内容交付网络仅限于将网段复制到每个服务器的一个端口。 但现在，我们可以将文件复制到每台服务器中的多个端口。 这大大增加了每台服务器的吞吐量，因此每个pop可以处理更多的请求，从而比以前大得多的实时事件。
在我们的系统中，负载平衡由高速缓存阵列路由协议(CARP)散列处理。 对于常规内容，我们的方法是跨多个服务器复制文件，我们使用CARP哈希从每台服务器中选择一个端口。 我们这样做是为了防止将重复请求发送到源服务器并限制进程间通信。
当文件变得足够热时，CARP开始为每个服务器选择多个端口以支持更多请求。 这种方法适用于热文件，因为它们只占服务器提供的唯一文件的一小部分。 打开的端口数量取决于对热文件的需求。 这种方法增加了每台服务器提供的数据量以及可用于处理这些请求的CPU功率。
结论
随着流媒体服务提供商缩小视频片段的大小以提供更低延迟的直播流，Edgio的平台热归档功能可帮助内容交付网络管理不断增长的视频文件请求，尤其是在受众规模因热门体育赛事而不断增长的情况下。
