Swipe Alone: 短视频服务的测量研究

这篇文章主要介绍了对短视频服务的相关研究，通过调研 4 种流行的短视频服务研究他们的编码变体、感知视频质量、预加载策略及数据消耗与视频质量之间的相关性。

短视频是社交媒体中被广泛应用的一种交流形式，最早在 TikTok 中流行，其后被许多社交软件中广泛使用。相比于长视频，短视频在时长上通常只有几十秒到几秒，所使用的拍摄方式也通常是智能手机的竖屏模式。在实际应用中允许用户通过上下滑动切换视频，在切换到下一个视频的过程中，因为有后台的预加载，视频不会出现卡顿和延迟现象，这一设计启发我们去研究短视频系统。在本次研究中，我们研究了 4 个目前流行的短视频服务：TikTok、Facebook Watch、 Instagram Reels和YouTube Shorts。

在具体的研究对象上，我们关注以下几个方面：

服务设计调研
- 每个服务提供的编码变体的统计分析
- 感知视频质量分析
预加载
- 了解所用预加载策略的特征
- 例如，视频数量、时长和每次加载的视频大小
数据消耗和QoE评估
- 在不同带宽场景下调查数据消耗与视频质量之间的相关性

服务设计调研

编码特征

首先，我将介绍服务设计方面的调研，具体来讲就是编码特征和视频质量分析。围绕编码特征的基本问题，例如将视频变体分类为分辨率级别和相应的比特率。我们通过 selenium 抓取视频 url 自动提取元数据。提取的元数据包括分辨率级别和实际分辨率尺寸以及每个视频的比特率。

这里是一个例子，元数据包含基本视频信息，如时长、视频 ID。而编码格式方面，每个视频可能被编码为不同的 codec（例如 AVC 和 VP9）。每种格式可能包含不同的分辨率级别，例如 360P 和 720P。即使在相同的分辨率标签下，实际分辨率尺寸也可能不同。例如这里，在标签 360P 下，它可以包含不同的分辨率尺寸 410×540、360×640。当我们尝试比较每项服务的视频质量时，这将带来困难。幸运的是，即使分辨率标签相同，有不同的比特率可以帮助我们区分它们。

为了展示分类面临的挑战，让我们以服务 1 为例。在服务1中，元数据仅提供分辨率为720P，而事实上，有许多分辨率尺寸，例如720×1080，710×980等。

潜在原因与原始视频有关，对于短视频业务，原始视频来自用户手机，而不是专业设备。因为他们有不同的 codecs，为了进行一个公平的比较，图中展示的结果仅使用 AVC 的编码方式。图片中展示了四种服务在 360P 和 720P 分辨率下的比特率分布，结果表明 360P 的比特率分布相比 720P 的更窄，这表明视频的感知质量也会相应降低。由于比特率不适用于感知视频质量比较，下面我们将计算不同分辨率标签的 VMAF 分数。

视频质量分析

要在分辨率和尺寸各异的前提下有效比较视频服务的感知质量，我们自己拍摄了多组不同运动模式（包括前景运动和背景运动模式）的视频作为用户视频，将拍摄的所有视频上传到几个短视频服务器后下载所有分辨率下的视频。然后计算原视频和下载得到的视频的 VMAF 分数以测量视频质量。

图中展示了四种服务的比特率对应VMAF分数的结果图，VMAF 分数从 0-100，100 分表示当前视频变体相比于原视频没有损失。服务 1 对每个视频仅有一个变体，我们可以看到低速运动的视频相比于高速运动的视频有更高的分数；服务 2 的结果可以看到比特率和视频感知质量相关，维持高质量视频需要高的比特率；当我们比较服务 2 和 3，两种服务都能在高速运动下维持高视频质量，注意到服务3在比特率和服务质量上做了一个折衷；服务4的视频质量最差，可供选择的分辨率数量也较很少。

预加载原则

首先我们要知道预加载原则是什么，并搞清楚它在不同的短视频服务中具体是如何运作的。我们将网络连接断开来确定有多少个视频被预加载了，同时我们使用 packs tracing 来确定预加载数据的大小。

图中是一个示例，首先在网络连接条件下播放视频 1，然后断开网络滑动屏幕，在无网络条件下该服务可以播放视频 2、3、4 的部分画面，视频 5、6 及之后的视频没有被预加载，同时记录了能播放的三个视频的时长，可以发现视频不是被完整加载。当我们播放视频 1 的时候视频 2、3、4 的一部分在后台被准备好来应对潜在的网络延迟问题。我们可以将预加载时的视频分为三部分，即图中的正在播放的内容、预加载内容和未加载内容，本次研究关注预加载内容。

图片左侧以短视频服务 1 为例，当用户正在浏览视频1的时候，服务 1 预加载了后面三个视频的一部分，用户继续浏览视频 2 时相应的视频 3、4、5 会被预加载。图片右侧展示了本次研究的4种服务的预加载策略，不同于服务 1，服务 2、3、4 使用的是基于时间的方式，他们为每个视频创建了预定义的持续时间,并且他们的预加载视频和正在播放的视频并行加载。

图中表格展示了四种服务预加载的相关数据，在数量方面，服务 2 仅预加载一个视频，其他三种服务预加载多个视频，最高的是服务 4，为 22 个视频进行预加载；在每个视频的预加载大小方面，仅预加载一个视频的服务 2 每次可以预加载几乎整个视频。我们进一步研究了 iOS 和 Android 系统中的表现，发现不同的操作系统也影响了服务设计。蓝框中的基于大小的预加载策略和红框中基于时间的加载策略的不同也会成为一个值得关注的重点。

数据消耗和QoE评估

在这一部分，我们将研究网络状况对服务质量的影响以及数据消耗的需求。具体来讲，我们关注不同带宽下每个服务会造成多少数据消耗，也关注带宽和数据消耗对服务质量的影响。

我们预设了服务器环境通过 Emnet 控制带宽，每次在给定的视频序列下测试一个服务，实验包括四个场景，包括两个带宽不同的 4 客户端 Wi-Fi 场景和两个蜂窝网络场景来测试 Data Saver 模式对数据消耗和质量的影响：

Wi-Fi 4Mbps（4 clients）
Wi-Fi 20Mbps（4 clients）
Cellular network Data Saver ON（1 client）
Cellular network Data Saver OFF（1 client）

在 Wi-Fi 场景下，我们研究了 VMAF 数值和数据消耗累积量的关系，如图所示，在带宽为 6Mbps 时，所有的服务都限制下载的数据量在一个较低的水平，在带宽为 20Mbps 时，更多的数据被下载相应的 VMAF 数值也提升了。我们关注数据消耗总量和服务质量之间的平衡，其中服务 1、3 在高带宽条件下数据量增大了 30%～40%，服务质量提升了 35%，服务 4 数据量增大了 100%，服务质量提升了 40%，服务 1 数据量增大了 5%，服务质量提升了 10%,这一服务并不会因为带宽增大而显著提升质量。我们认为服务 1、3 在数据量和服务质量上所做的平衡更好。

在蜂窝网络场景下，我们也研究 VMAF 数值和数据消耗累积量的关系，Data Saver 模式有效的减少了数据总量，各服务数据减少量平均值为 15%，当然相应的服务质量也会降低 15%～25%。值得注意的是服务 2 在 ata Saver 模式下数据量减少 15% 导致了服务质量下降了 30%，这一结果看起来比较激进，但也是数据量和服务质量合理的平衡。