低延迟体育中的内容感知播放

2022-04-11 19:11:21 浏览数 (1)

来源：DEMUXED 2021 主讲人：Ali C.Begen, PhD 内容整理：尹文沛 主讲人主要介绍了在直播体育的场景下，他们提出的内容感知速率控制算法，以避免直播重要时刻的卡顿。

简介

今天我们将谈论最近的一个低延迟直播的作品。一个有趣的事实是，在 1969 年，一个来自月球表面的直播被数亿人观看，他们的延迟大约是 3 秒，50 年后，超级碗也有数百万的流媒体播放，但在这种情况下延迟超过 45 秒。然而，在过去几年中，低延迟在实施和标准化方面取得了很多进展，因此我们的处境要比几年前好得多。低延迟的主要驱动因素之一就是现场体育赛事。

我们正在经历流媒体提供商签署价值数十亿美元的合同，以获得全球足球篮球等热门赛事的流媒体版权。他们如果想要赚回这笔钱，就必须给观众提供超级视频体验——高清甚至 4K 分辨率，高帧率高动态范围，多声道音频，在优质体育流媒体中都有很高的需求。但是，影响观众体验的最重要因素之一其实是视频播放的流畅程度。由于 IP 网络的不确定性，有时卡顿是不可避免的。而且由于我们使用非常小的缓冲区进行低延迟直播，卡顿更长时间、更频繁的概率会因此变高。

图1 梅西主场点球

我们看到图 1 ，梅西主场点球，数百万人观看直播，但是突然视频卡住了，是进球还是守门员守住了？几秒钟后，视频继续播放，这会很烦人，尤其是和朋友一起看比赛的时候。

自适应播放技术概述

低延迟体育节目是低延迟直播的主要驱动力。在提供优质的低延迟实时流媒体服务这方面，我们开发了一些实用的技术，比如说自适应播放——通过改变每秒播放的帧数来减慢播放速度，并对音频和字幕做同样的事情。如果我们即将用完播放缓冲区中的媒体，这种减速将为我们提供额外的时间来获取更多数据，可以避免视频完全卡住。例如，如果我们在三秒内播放两秒的内容，这意味着它慢了 50%，我们将在三秒的过程中创建一个额外的一秒缓冲区。但是，你可以想象，除非我们还采取一些反制措施将延迟降低到初始值或目标值，否则我们无法继续这样做。现在，要做到这一点，我们需要在短时间内提高播放速度，并且只有在播放缓冲区中有额外数据时才能这样做。

这种自适应播放的想法被 IP 语音应用采用，在那个时候，它确实带来了音频质量的最大改进。现在，让我们看看如何实时调整播放速度。

图2 播放速度控制伪代码

如图 2 所示，这是我们的 LOL 低延迟算法。这是我们在一年前为这个主题的巨大资助挑战而开发的。它已经是第四版官方分支的一部分。从代码中可以看出，我们首先检查了当前缓冲区与最低安全缓冲区级别相比的情况。如果缓冲区非常低，我们不需要进一步检查，也不关心当前的延迟是多少，我们会立即放慢速度，因为存在迫在眉睫的停顿风险。速度降低的量取决于缓冲区有多低。另一方面，如果缓冲区正常，这意味着它至少与最小安全阈值一样高，那么我们检查当前延迟与目标延迟的比较情况。然后，基于此，如有必要，我们需要调整播放速度。

这里有几个例子。所以，我们在这段代码中有一些可配置的参数。本例中安全缓冲阈值为半秒，目标延迟为 1.5 秒，播放速度允许正负 30% 的变化，所以，我们可以减慢 30%，也可以加快 30%。在场景一中，缓冲水平为 0.3 秒，因此低于安全缓冲值。所以，在那种情况下，我们只需要放慢速度，我们不关心延迟是多少，我们只需要放慢速度。在场景二中，缓冲区处于最小安全缓冲区阈值，所以没关系，但是我们当前的延迟比目标值低一点，所以我们可以冒险播放，但也可以在这里放慢一点，建立一个更大的缓冲区，这将给我们更多的保护。而在第三种情况下，缓冲区为 0.7 秒，因此它高于我们的最低要求，但延迟也高于当前值，所以在这种情况下，我们需要稍微加快播放速度，以便我们能够赶上现场直播。

图3 自适应播放的参数

如图 4 所示，在底部，我们有混合方法，即 LoL 。中间是 DASH-GS 默认算法实现，然后在顶部是另一种播放速度控制。在底部，如您所见，LoL 正在检查缓冲区级别和延迟级别，因此，当带宽显著下降时，显然视频会无法避免地停止。但是一旦带宽恢复，我们就可以继续流式传输，并且我们最好尽快将延迟降低到目标值。在这种情况下，我们可以看到，停顿持续时间被限制为小于三秒。

在第二种情况下，在中间的情节中，我们只关注当前的延迟，而这正是 DASH:GS 今天所做的。如果当前延迟增加，您将提高播放速度，并尝试赶上实时边缘。显然，在这种情况下，我们会遇到更多的停顿，因为我们并没有真正检查缓冲区。但是我们确实可以很好地控制目标延迟。在最后一个示例中，在顶部，相同的算法，但现在我们只关注缓冲区条件。因此，在这种情况下，与中间场景相比，我们的停顿更少，我们对延迟的控制也更少。所以，总的来说，看看所有这些情形，我们知道做一个混合播放速度控制是要走的路。现在，这真的是我们能做的最好的事情吗？这就是我们在这项研究中试图回答的问题。

图4 3 种不同策略

现在，当缓冲区几乎耗尽时，我们真的别无选择，我们需要放慢速度，以便我们能够从这个短暂的时间中恢复，而不会出现任何停滞。但是，如果我们可以提前更好地计划事情，我们可能会选择更合适的地方来调整播放速度。如果速度变化很细微，没有人会注意到，但在低延迟下，细微的速度变化很少。它们在短时间内并没有真正为我们提供太多收益。换句话说，我们大部分时间都需要快速而积极的反应，而这种播放速度的变化可能很容易被观众注意到，或者看得见仔细选择何时改变播放速度以及改变多少。

我们有一个解决方案称之为内容感知播放速度控制(Content-Aware Playback Speed Control)。简而言之，它被缩写成 CAPSC。

内容感知播放速度控制

内容感知播放速度控制 (CAPSC) 建立在 dash.js 中已实现的 LoL 算法之上。LoL 算法提供了两个主要组件：用于速率适应的自适应比特率 (ABR) 规则和播放速度控制器。在本研究中，我们不接触前一个组件，而是按原样使用它。由于不依赖 ABR 规则，CAPSC 也可以与 dash.js 中的任何其他 ABR 规则一起使用。

图5 使用 CAPSC 进行低延迟直播的不同端到端工作流。红色部分表示新的（或修改的）元素。

图 5a 展示了用于实时流媒体的典型端到端工作流程。在此图中，红色部分表示启用 CAPSC 的新（或修改）元素。元数据将有关直播内容的某些信息实时传送到流媒体客户端，以便客户端可以以内容感知的方式控制播放速度。在图 5a 中，元数据是在内容准备阶段生成的，作为编码/打包过程的一部分。这是一种选择，但也存在其他方式。例如，在体育赛事中，可以实时处理现场比赛数据或现场评论以进行元数据提取，如图 1b 所示。虽然元数据是稀疏数据，因此不需要大量带宽，但及时将其交付给客户端很重要。它可以使用 mp4 atom 在带内传递，也可以使用定时元数据轨道、WebSocket、服务器发送事件 (SSE)或 DASH 事件在带外传递。

请注意，虽然 CAPSC 可以在短期内改变播放速度，但在低延迟直播中，长期平均播放速度不能快于 1 倍。此外，长期平均播放速度也不能低于 1 倍，因为这意味着客户端已经远远落后于实时边缘并且不能再保持低延迟。

CAPSC 的实现

与 dash.js 集成

CAPSC 实现基于 dash.js v3.2.2。算法 1 是来自 LoL 的播放速度控制器的扩展版本，其符号列表如表 1 所示。每个播放进度步骤都会运行此逻辑以在当前条件下选择新的播放速度。CAPSC 首先检查当前缓冲区级别是否小于给定阈值 (

B_{low}

)。如果是这样，CAPSC 会选择较慢的播放速度。如果当前缓冲区级别不是非常低，CAPSC 检查当前延迟和目标延迟之间的差异，并选择 1x 或更高的值作为播放速度。请注意，除非有理由修改播放速度，否则客户端会尽可能长时间地保持 1x 速度。

播放速度的下限和上限由

D_{max}

参数确定：CAPSC 必须在

[1-D_{max},1 D_{max}]x

区间内选择播放速度。在这里，我们使用一个参数来对称地设置上下播放速度界限。然而，在算法 1 中支持非对称边界很简单，尽管确定最佳边界需要一些调整。

图6 关键的信息

图7 CAPSC 算法流程

在我们的 CAPSC 实现中，元数据由一个数字（用

gamma

表示）组成，表示每个块的事件密度。这个密度是块的内容重要性度量，或者换句话说，它不适合播放得更快或更慢。密度值的范围从 0 到 1，其中 0 表示块不重要（即，它适合更快或更慢的播放），1 表示块很重要（即，它应该以 1x 播放）。使用事件密度允许 CAPSC 在算法 1 中选择更合适的播放速度（第 12 行）。在我们的设置中，密度使用 SSE 流式传输到客户端。

性能评估

我们的测试设置使用以下工具：

  1. 带有 CAPSC 的自定义 dash.js 用作流式客户端。
  2. FFmpeg 用于编码和打包。
  3. DASH 低延迟网络服务器用于提供媒体服务。
  4. Java - Spring Boot 用作元数据服务器。
  5. React 用于测试页面。
  6. Puppeteer 用于测试自动化。
  7. Google Chrome (v90.0.4430) 用于浏览和网络模拟。

对于我们的实验，我们从巴塞罗那足球俱乐部的官方网站 YouTube 下载了完整的足球比赛。然后我们删除了音轨并将视频切成了几个五分钟的序列。对于本文中提出的结果，我们使用了其中两个序列。我们将这些已经编码的测试序列输入 FFmpeg（使用“-re”标志）以生成实时源。由于我们对速率适应不感兴趣，我们只为每个视频生成了一个表示。每个表示具有 500 Kbps 的编码比特率、30 fps 的帧速率、10 秒的片段持续时间和一帧的块。我们在实验中使用的其他设置如下：

  1. 自适应播放算法：默认、LoL 和 CAPSC。
  2. 带宽配置文件：Twitch 和 LTE。
  3. 目标延迟：3秒。
B_{low}

: 一秒。

D_{max}

: 0.3。

图 8 显示了两个测试序列的事件密度，其中白色表示最低（0，例如，用于静态场景），黑色表示最高（1，例如，用于点球或进球）密度。由于我们无法访问该特定足球视频的官方游戏元数据，因此这些密度是使用目视检查手动生成的。由于我们在本文中的目标是展示 CAPSC 的工作原理，我们认为手动生成密度是可以接受的，并且不会对结果产生任何影响。

图8 Test-1 (a) 和 Test-2 (b) 序列的事件密度

在图 9 中，我们比较了 Default (a)、LoL (b) 和 CAPSC (c) 算法的延迟、缓冲区占用率和播放速度性能。对于 Test-1 和 Test-2 序列，我们分别关注 150 和 230 秒以及 275 和 300 秒之间的间隔，其中图 8 中的事件密度也被覆盖。请注意，当缓冲区占用率降至零时，播放停止，这也由播放速度为零表示。图 9a 显示，当延迟增加时，默认算法会加快播放速度。但是，缓冲区随后会完全耗尽，从而导致多个停顿。LoL 算法（图 3b）通过根据需要减慢播放速度在一定程度上解决了这个问题，尽管由于长期糟糕的网络条件，一些停顿仍然不可避免。

图9 默认情况下，LoL 和 CAPSC 在 Test-1 和 Test-2 序列上进行的测试

我们观察到，当事件密度为 0 时，LoL 和 CAPSC 算法的行为相似。这是意料之中的，因为 CAPSC 是 LoL 的扩展版本，并且事件密度为 0 表示内容可以更快或更慢地播放而观众不会注意到它。但是，要查看它们的差异，我们需要关注高事件密度间隔。例如，Test-1 序列的 205 到 209 秒的间隔（图 4a）表明，默认和 LoL 算法选择最大播放速度（即 1.3x），因为实时延迟高于目标值，而 CAPSC 算法选择的播放速度仍然高于但接近 1x。另一方面，图 4b 放大了 Test-2 序列的 284 到 288 秒的间隔，我们观察到了一个有趣的结果。在这里，由于前三秒发生了多次停顿，实时延迟上升了，因此，只要缓冲区有足够的数据，LoL 算法就会选择高于 1x 的播放速度。但随后，缓冲区再次耗尽，LoL 算法减慢了播放速度。这个循环持续几秒钟。另一方面，CAPSC 将播放速度保持在接近 1x 的水平，避免了在内容的这一重要部分期间播放速度的快速变化。然而，这是以更长的追赶时间为代价的，如图 10a 和图 10b 所示。

图10 Test-1 (a) 和 Test-2 (b) 序列的播放速度。

在实验中，与默认算法相比，LoL 和 CAPSC 算法都实现了更少的停顿和更短的总停顿持续时间，尽管 CAPSC 的总停顿持续时间略长于 LoL 。在平均播放速度方面，LoL 和 CAPSC 的差异可以忽略不计，而 CAPSC 的整个实验的播放速度标准差明显低于其他两个。对于具有较高事件密度的部分，默认和 LoL 算法的偏差差异进一步增加。

最后附上 CAPSC demo 链接: http://streaming.university/demo/mmsys21-capsc/

附上演讲视频：

http://mpvideo.qpic.cn/0b2ej4aaoaaax4acrtbpl5rfat6da5hqabya.f10002.mp4?dis_k=f80d35c9f28f27d1e6669fb5b4143c1d&dis_t=1649675439&vid=wxv_2309675059701186565&format_id=10002&support_redirect=0&mmversion=false

数据分析 编程算法 云直播 javascript

0 人点赞