Measurement of a Large-Scale Short-Video Service Over Mobile and Wireless Networks

1 INTRODUCTION

由于这些短视频服务中的大多数是最近才引入的，它们的服务特性和用户行为还远未被很好地理解。因此，获得对这些短视频服务的更全面的理解，以使它们的服务提供更进一步，具有实际意义。

我们与中国一家主要的短视频服务提供商合作，让我们能够直接访问应用级日志数据，包括外部测量无法访问的流和网络性能日志。仅在我们研究的提供商的移动和无线 (即 Wi- Fi) 领域，这项服务的日视频浏览量就超过了 10 亿次。我们的数据集涵盖超过 220 亿次视频播放请求，超过 1 亿个不同的视频文件，由超过 5000 台服务器为来自中国 35 个省份和 13 个 ISP 的用户提供服务。我们分析了该服务的三个关键方面:(a) 视频内容特征；（b）网络分析；以及 (c) 视频流分析 (参见表 1)。

我们的结果揭示了短视频和传统视频共享平台之间的显着差异[4-17]。这些发现将对各个层面的系统诊断产生影响，从视频推荐算法、流媒体协议到视频缓存策略。该服务的规模还使我们能够对中国各地的移动和无线网络服务进行间接网络性能测量，正如该服务所经历的那样，纳入了端到端数据路径上所有组件的影响。网络类型（3G、4G、5G 和 Wi-Fi）、地理位置（按省份）和每次视频下载中使用的 ISP 都是已知的（但已匿名），从而可以从多个角度分析网络性能。这些结果为大规模互联网应用程序所体验的移动和无线网络的实际性能提供了罕见的见解。

3 DATASETS

3.1 Data Collection

我们获得了大规模商业短视频服务的客户端访问日志。这些数据对应于该服务的一个域名，该服务通过 Wi-Fi 或移动数据网络，向在 An- droid 和 iOS 平台上使用该服务的移动应用程序的用户提供短视频内容。该服务为其网络存在有单独的服务器，不包括在本次研究中。

访问日志按如下方式生成。当用户播放视频时，会触发视频播放事件，从而创建新的日志条目。在用户完成视频播放之后 (例如，返回到菜单或切换到另一个视频)，客户端应用将收集完成的播放事件的信息，然后将其上传到日志服务器。

该服务不采用自适应比特率流，如 MPEG-DASH[31]，但流视频使用的专业协议。它将每个视频分成大约 1mb 大小的片段，以便在播放期间通过持久 HTTP 连接[33]传递给客户端。客户端使用单独的 HTTP 请求请求每个段，在日志中生成一个下载事件 (例如，下载大小，传输时间等)。由于流量大，产生的日志量大，提供商随机选择上传的 20%的访问日志进行存储。本研究的访问日志都是在 2020 年收集的 (表 3)。表 2 总结了可以直接获得或从日志中计算的主要指标。请注意，日志的确切月份没有公开，但这四个数据集从#1 到#4 临时排序，横跨 5 个月。为了保护用户的隐私，所有的日志数据都是匿名的，每个字段，即{客户端 IP}，{服务器 IP}，{文件名}，{省}，和{ISP }替换为他们各自的单向哈希值，然后传输给我们进行分析。

3.2 General Properties

本节介绍了数据集的一些一般属性。我们主要从视频请求层面分析数据，因为数据集不包含可识别个人用户的信息。请注意，通过 (哈希) 客户端 IP 推断用户可能也不准确，因为用户的 IP 可能会随时间而变化 (例如，当在 Wi- Fi 和移动网络之间切换时)，ISP 通常会为其用户分配私有 IP，然后用户通过网络地址转换 (NAT) 设备访问互联网[32]。我们首先在表 5 中按请求测量客户端网络类型的分布。超过 80%的请求来自 Wi-Fi 用户。其余的由三代移动网络分担，4G 占了大部分需求。这一结果表明，该服务的用户体验是由 Wi-Fi 主导的，或者更具体地说，该服务的性能基于 Wi-Fi (第 5 节)。值得注意的是，尽管 5G 部署仍处于早期阶段，但我们已经可以看到四个数据集的稳步增长，例如，从数据集#1 的< 0.01%增长到数据集#4 的 0.52%(占所有移动访问的 2.7%)。同时，随着运营商逐步淘汰 3G 服务，3G 请求也逐渐减少，5 个月后达到与 5G 相同的比例。

在地理上，图。1 显示了中国所有 35 个省份的请求分布。前三名的省份占所有请求的 30%。图2 绘制了请求在用户 ISP 之间的分配。前三大 ISP 占所有请求的 93%以上。总体而言，上述结果表明，该数据集涵盖了有关网络类型、ISP 和地理位置的广泛请求。

4 VIDEO CONTENT CHARACTERISTICS

在本节中，我们将分析服务的视频内容特征。这些特性将有助于设计和优化 CDN 基础设施[6]和计算策略[4]、5、6、9]，甚至是对等（P2P）内容分发策略[4]、6、9]。表 3 总结了所有四个数据集的关键视频内容特征。除非另有说明，否则，数据集#4 将用于生成本文其余部分中所呈现的结果，因为它是最大和最新的数据集。

4.1 Video Length and Bitrate

该服务支持两种类型的视频上传:任意长度的预录视频或以三种预设视频长度 (分别用 L1、L2 和 13 秒表示) 之一的实时录制的直播视频。在后一种情况下，手机应用程序会在预设时间结束后停止录制。所有四个数据集中的视频长度中值约为 22 秒，明显短于传统的视频共享服务 (YouTube 为 210 秒[5-6，12])。图 3 绘出了视频长度分布。我们可以在 L1、L2 和 L3 观察到三个峰值，它们对应于视频应用的实时视频上传模式中的三个预设视频长度。这表明用户正在积极使用该功能。

尽管自适应视频流被广泛采用，但包括本服务在内的大多数短视频服务目前都不采用自适应比特率流来动态地调整流频流中的视频比特率。相反，该服务的视频编码的平均比特率约为 930 kbps。我们在第 7.2 节中通过重新检查当前 ABR 算法在应用于短视频流时的潜在性能来探索这一观察结果的可能原因。

4.2 Video Request and Upload Pattern

接下来，我们研究一天中不同时间的视频请求到达模式。图 4 在数据集#3 中绘出了两天内每小时的请求比率。数据显示了请求模式中明显的时间变化，这在两天中是一致的。比如高峰时段是 21: 00-22:00，午夜后请求率迅速下降，02: 00-04:00 达到最低。第二天的请求比第一天多 19.6%，可能是因为第二天是星期六。有趣的是，虽然第一天是工作日，但在办公时间仍然有大量的请求。例如，星期五 09:00 到 17:00 之间收到的请求的比例是 36.39%，而星期六是 41.35%。我们推测非常短的视频长度允许用户甚至在工作时观看，例如，在短暂休息时。请求到达的时间变化的一个影响是对服务提供商的容量确定。为了提供良好的用户体验，服务提供商必须部署足够的资源 (即服务器和网络带宽) 来应对高峰需求。这意味着一些资源将在一天的剩余时间里闲置。

例如，假设服务根据周六数据集中的峰值需求提供资源，那么两天的平均资源利用率仅为 31%，而最低利用率在 03:00-04:00 仅为 4.4%。实际上，利用率可能会更低，因为大多数（如果不是全部）服务提供商都会保留额外的资源，作为应对需求激增的安全边际。图 4 中的测量结果确实提供了证据，表明视频请求中的时间变化是可以预测的。通过利用这一点，提供商可以调整资源分配，以适应不断变化的需求，从而降低成本，并可能提高性能。这是一个值得进一步研究的课题。

接下来，我们将注意力转向图 5 中使用相同数据集#3 的视频上传模式。就数量而言，视频下载与视频上传的比例约为 80:1。同样，上传率显示出两天内一致的每日时间变化。然而，上传模式存在一些显著差异。与视频请求不同，视频请求在深夜呈现高峰需求，上传模式在 12:00 至 14:00 和 19:00 至 21:00 呈现两个高峰。这两个时段与午餐和晚餐时间重合，这可能是上传率较高的原因之一。

4.3 Video Popularity

zip-f定律

视频流行度是一个重要的指标，因为它影响许多服务设计，如预取、缓存[34]、推荐、广告插入等。之前的工作[9]测量了几个月的 YouTube 视频受欢迎程度，结果显示视频受欢迎程度通常遵循帕累托法则，即一小部分视频占大部分观看量。流行度与视频排名的关系通常可以进一步用幂律分布来建模。然而，张等人[23-24]最近的一项研究表明，由于视频流行程度的快速发展，Zipf 定律可能不适用于短视频服务

为了验证这一点，我们分析了数据集#4中视频的受欢迎程度。帕累托法则仍然适用——10%的视频对应了大约90%的请求。接下来，我们测试视频受欢迎程度是否仍然可以用幂律分布建模，更具体地说，齐夫定律[35]:

图6将数据集#4中的经验视频流行度与最佳拟合Zipf模型进行了比较。我们使用决定系数，也称为R2值[36]，来衡量模型拟合的优度，其中R^2=1表示完美拟合，R^2=0与平均预测器相同。最佳拟合Zipf模型的R^2值仅为0.5，表明后者确实不是视频流行度分布的良好近似值。

具体来说，高排名 (受欢迎的) 视频比 Zipf 模型预测的受欢迎程度低。这可能是由于用户生成内容的“最多取一次”属性[9]，其中大多数视频只被用户观看一次 (或者在非常受欢迎的视频的情况下观看几次)。

相比之下，例如，YouTube 上的流行音乐视频可能会被同一用户长时间反复观看。即使是最具病毒式传播的短视频也会很快被新的短视频盖过，这是短视频服务的固有特性之一。在视频等级谱的另一端，我们观察到尾部的截断，即它们的访问计数比 Zipf 模型预测的低得多。这一观察结果与之前的工作[5，9，20]一致，Cha 等人[9]认为截尾是由内容过滤引起的。短视频服务都有推荐系统，倾向于推荐更受欢迎的视频，认为不受欢迎的视频很难被发现。

生命周期

接下来，我们研究视频流行度随着视频年龄的演变[22] -定义为从视频上传到播放请求的时间，以分析视频在其生命周期中的流行度演变。图 7 绘出了在两个时标 (小时和天) 上，数据集#4 中的视频请求比率与视频年龄的关系。在这两个时间段，随着视频的老化，视频的受欢迎程度迅速下降。例如，30%的请求是当天上传的视频，90%的请求是 30 天内上传的视频。相比之下，Zhang 等人[20]之前对 Vine 的一项研究发现，50%的请求是十天内的视频，而我们的数据集中的这一比例要高得多，为 70%。这种快速的流行度衰减会影响缓存策略的性能，例如，通过在基于最频繁使用的度量的策略中引起缓存污染[39]。

数据集#4中所有请求的视频年龄中位数仅为104小时。在逐小时图中，请求比率在视频年龄上以24小时为周期呈现波状变化。这是视频请求(图4)和上传(图5)在一天中不同时间变化的结果。

相比之下，逐日图表现出明显的幂律趋势，可以近似为

，其中x是视频年龄(天)，f(x)是比值，c = 1和β = -1.28是幂律系数。幂律模型表明分布具有长尾。例如，虽然大多数视频的视频年龄都很短，但有一小部分视频(确切地说是1.69%)的视频年龄确实超过了180天。

上述分析揭示了将 Zipf 分布应用于视频流行度模型的一个微妙但重要的参数，即时间尺度。图 6 中的受欢迎度分布是根据第四天的所有视频请求计算得出的，这段时间跨度为 9 天。然而，由于视频流行性在短短几个小时后迅速衰减，这违背了齐普夫定律的假设，即在研究期间，流行性分布是稳定的。

为了验证这一假设，我们在表 6 中计算了四个不同时间尺度（从 216 小时到 5 分钟）的最佳拟合 Zipf 模型。很明显，随着时间尺度的缩短，Zipf 模型的准确性显著提高。在 5 分钟的时间尺度上，最佳拟合 Zipf 模型的 R2 值为 91.79%，表明拟合良好。这表明，先前在短视频服务中观察到的非 Zipf 行为[23-24]可能是由于时间尺度的选择。更重要的是，视频流行在短时间范围内回归 Zipf 模型的发现为利用它进行系统优化（如视频复制、缓存和预取）开辟了一条新途径。

一天中的上传时间

接下来，我们调查视频的上传时间是否与其最终的流行程度相关。我们将数据集#4 中的视频按照一天中的上传时间分成 24 组，然后在图 8 中绘制每个视频的平均重复次数。

我们观察到，在一天的不同时间上传的视频的流行程度存在显著差异。例如，在 17:00-18:00 上传的视频平均收到 24 次播放，而在 22:00-23:00 上传的视频只有 11 次播放。我们推测这可能是由两种相互关联的现象引起的。一方面，由于视频的老化速度很快，大多数请求都是在上传后的前几个小时内生成的（见图 7），17:00-18:00 期间上传的视频可能会从随后的高峰请求时间（见图 4）中受益，从而获得更多的浏览量。另一方面，这一现象可能被商业视频制作者利用，他们安排视频上传，以从请求浪潮的高潮中获得最多的观看。这些上传者也倾向于制作更受欢迎的视频，从而进一步扭曲了受欢迎的数字。更深入地了解这些现象将对内容和资源管理产生深远影响，因此需要进一步调查。

视频长度

最后，我们在图 9 中研究了视频长度对视频受欢迎程度的影响。视频长度分布呈凹形，视频长度在 60 ~ 180 秒之间的受欢迎程度较高。结果清楚地展示了短视频服务的固有性质——即使长视频可以上传，它们也不太可能受欢迎，因为它们不太适合预期的用例 (例如，在办公室快速观看)。

更令人惊讶的是，在三个预设的视频长度 (L1、L2 和 L3) 上，视频直播上传的受欢迎程度明显低于相邻的视频。我们推测通常有两种类型的视频。休闲视频是指用户在动作瞬间通过预设视频长度的直播方式进行直播的视频;商业视频是指预先录制、编辑后再上传的视频，不限制视频长度。商业视频明显优化了流行度，从而导致了观测到的异常。这一发现可能是优化资源管理的低挂果实，例如，通过分配较低的优先级缓存视频上传使用现场模式而不是预先录制模式。上述分析揭示了各种因素与视频最终受欢迎程度之间的许多有趣的相关性。这种相关性可以用来预测新上传视频的受欢迎程度——这是视频推荐、内容管理、资源分配等方面的重要信息。在传统流媒体服务的背景下研究了人气预测，例如 Li et al.[39]和 Goian et al.[41]的作品。然而，鉴于短视频服务的特点存在显著差异，这些先前的作品可能无法直接转化为短视频服务。我们希望这项工作的发现将为这一领域的进一步研究铺平道路。

5 NETWORK ANALYTICS

这些数据集涵盖了35个省份，13个不同的isp，以及5000多个服务器ip。因此，研究结果为在全国范围内调查网络特征提供了难得的机会。表3总结了四个数据集的关键网络统计信息。

5.1 Connection Time

我们首先考虑连接时间 ($$D_{RTT}$$)——定义为客户端建立到服务器的 TCP 连接的时间。由于 TCP 在连接建立过程中采用三次握手，连接时间反映了客户端和服务器之间的端到端往返时间 (RTT)，加上两端主机的处理时间。由于服务使用持久 HTTP，只有第一个 HTTP 事务需要建立连接，除非延长的空闲时间导致服务器超时持久连接。因此，由于持久的 HTTP，超过 90%的视频播放的连接时间为零。图 10 绘制了数据集#4 的连接时间分布，排除了零情况。我们观察到连接时间相对较短，平均/中位数为 58.96/22 ms。这是因为该服务的客户端和服务器都位于中国境内，从而避免了跨大陆连接。作为比较，Langley 等人[38]研究了 tcp 连接到谷歌服务器的 RTT，发现 20%和 10%的 RTT 长于 150 毫秒和 300 毫秒。相比之下，在数据集#4 中，只有 5.5%和 2.97%的连接时间超过 150 ms 和 300 ms。

连接时间分布可以用对数正态模型近似表示:

其中 x 为连接时间，(x) 为概率，s、loc、scale 为模型参数。由于客户端与服务器之间的连接时间主要由 RTT 组成，因此 (3) 中的模型可用于模拟生成随机 RTT 值，也可用于数学模型进行分析。下面，我们分析了各种因素与连接时间的相关性。

网络类型

直观地说，RTT and 连接时间取决于网络。我们按网络类型 {3G、4G、5G、wi-fi} 对数据集进行了分离，并在图 11 中绘制了它们各自的分布。有两个值得注意的观察。

首先，从 3g 到 4g 和 5g 移动网络的连接时间通常会缩短，平均/me dian 值分别为 151/51 ms，95/44 ms 和 86/42 ms。改善的连接时间直接转化为更好的用户体验，尤其是在短视频服务中，短的启动延迟远比传统的流服务重要。

其次，wi-fi 的平均/中值连接时间仅为 49/18 毫秒，甚至比 5g 网络都要短得多。这可能归因于 5g 的早期部署，人们预计 5g 会随着时间的推移而改善。尽管如此，这确实表明，除了减少移动数据消耗之外，只要有可用，就将智能手机从移动数据切换到 wi-fi 也将提高应用程序性能。

一天中的时间

我们首先调查一下在图 12 中，在一天中的不同小时上的不同网络类型。正如预期的那样，大多数请求都通过 4g 和 wi-fi 提供服务。有趣的是 4g 和 wi-fi 曲线，它们的形状几乎是彼此的镜像。这显示了 wi-fi 卸载的影响，移动用户广泛采用 wi-fi 卸载来减少他们的移动数据使用。尽管如此，尽管有所不同，但即使在晚上或午夜 (大多数用户可能在家 (并且可以使用 Wi- Fi))，4g 请求的比率也没有下降到接近零。我们假设某些用户可能已经订阅了具有无限数据的移动计划，因此无需卸载到 wi-fi。然而，我们之前的连接时间分析 (以及 5.2 的吞吐量分析) 确实表明，即使移动数据使用不是一个因素，切换到 wi-fi 仍然可能会提高应用性能。

接下来，我们分析了图 13 中 4G 和 Wi-Fi 的连接时间随时间的变化。3G 和 5G 由于其非常小的请求比率而被省略。我们观察到，4G 在其平均连接时间（绿色三角形）上表现出比 Wi-Fi 更显著的时间变化（4G:{62 至 114}毫秒，而 Wi-Fi：{51 至 63}毫秒）。我们推测，这种差异是由于 Wi-Fi 通常具有更高的带宽，从而缩短了流量持续时间，并可以适应更高的使用突发。4G 的前两个高峰出现在午餐时间（12:00）和晚餐时间（18:00），可能是因为用户在办公室/家外，没有稳定的 Wi-Fi 接入，从而使移动网络紧张。

总的来说，上述分析表明，连接时间和 RTT 在不同因素（如网络类型和一天中的时间）之间会有很大的差异。特别是，尽管服务器和客户端都位于中国，但在许多情况下，平均连接时间仍可能超过 100 毫秒。这对于传输层（即 TCP）优化非常重要，因为长的网络延迟会严重降低传输协议性能，尤其是在高带宽网络中[44]。

5.2 Throughput

该服务将视频划分为 1 MB 段，客户端通过单独的 HTTP 事务下载每个片段。每个分段下载都会生成一个日志条目，其中记录了下载大小（由 $B{DS}$ 表示），定义为成功传输到客户端的字节数。除了片段大小外，日志还记录了传输时间$D{TT}$，定义为下载视频片段的时间。

知道下载大小和传输时间后，就可以计算传输视频片段的吞吐量。鉴于该服务的规模和覆盖范围，这为间接衡量大国的端到端网络吞吐量性能提供了难得的机会。我们注意到，计算出的吞吐量将包含端到端路径中的所有内容，包括路径带宽限制、TCP 的动态（即流量和拥塞控制、丢失恢复）、竞争流的影响（共享基站或 Wi-Fi AP）以及移动设备和服务器的处理限制。

换句话说，数据测量了服务所经历并由客户端记录的端到端吞吐量。可用的原始带宽可能更高，尤其是在 5G 和 Wi-Fi 上，但记录的吞吐量反映了服务实际可以利用的吞吐量。对可实现的吞吐量和原始带宽之间的差距的进一步调查将揭示潜在的瓶颈，并为性能优化铺平道路（例如，传输瓶颈[44]）。

我们计算了每个视频会话的平均吞吐量，用TP表示，通过对所有的段传输进行平均，如下所示

请注意，由于服务使用持久HTTP，只有前几个段请求将受制于TCP慢启动[44]，这取决于可用带宽。或者，如果用户空闲的时间超过了HTTP保持连接超时时间，那么TCP连接也需要重新建立一个新的慢启动阶段。尽管如此，由于超过90%的段下载记录了零连接时间，TCP慢启动的影响相对较小。

我们在图14中绘制了每个流的总体吞吐量分布，它可以用对数正态模型来近似。下面，我们进一步分析了各因素与吞吐量的相关性。

网络类型

我们首先根据网络类型划分数据集，并在图 15 中绘出它们各自的分布。不出所料，吞吐量一般从 3G，4G，5G，最后到 Wi-Fi，平均吞吐量最高。我们注意到，在提高网络类型时，平均吞吐量的增加比预期的要小一些。

例如，虽然 4G 通常可以提供比 3G 高得多的原始带宽，但观察到的平均吞吐量仅增加了 21.4%，从 11.48 Mbps (3G) 增加到 13.94 Mbps (4G)。然而，4G 表现出的低吞吐量情况要少得多，与 3G 下的 9.7%相比，只有 5.3%的吞吐量低于 1 Mbps (略高于 930 Kbps 的视频比特率)。

类似地，从 4G 迁移到 5G 导致吞吐量增加 27.5%，从 13.94 Mbps (4G) 增加到 17.78 Mbps (5G)，这低于 5G 可能提供的吞吐量 (例如，5G 最高可达 1.8 Gbps[40])。这可能是由于研究时 5G 部署的早期阶段 (例如，只有 0.52%的连接是 5G)，因此覆盖范围可能有限，导致平均吞吐量低于 5G 可能实现的吞吐量。

另一方面，Wi-Fi 以 34.1 Mbps 的速度提供最高的平均吞吐量，优于当前的 5G。低吞吐量情况 (< 1 Mbps) 的比例在 Wi-Fi 中为 1.35%，在 5G 中为 4.15%。除了 Wi- Fi 通常更高的带宽之外，它更短的连接时间和 RTT 也有助于 TCP 实现更高的吞吐量。

一天中的时间

接下来，我们考虑图 16 中 4g 和 wi-fi 连接与一天的时间的相关性。与连接时间 (第 5.1 节) 中的观察结果相似，Wi- Fi 全天显示出更稳定的吞吐量，从 26 Mbps (20:00 21:00) 到 37 Mbps (05:00 06:00)。相比之下，4g 的范围从 12 Mbps (18:00-19:00) 到 24 Mbps (21:00-22:00)。

值得注意的是，4g 的高峰时段集中在午餐和晚餐时间，用户更有可能在办公室/家庭 wi-fi 覆盖范围之外。4g 和 wi-fi 的吞吐量变化也接近彼此的镜像，表明了它们的互补性。

我们对四个数据集的进一步分析发现了一个经常被忽略的因素，该因素也可能显着影响网络和服务性能-移动网络速率限制。我们在第 7.1 节中对此发现进行了更详细的讨论。

5.3 Throughput-Connection Time Correlation

影响吞吐量性能的一个关键因素是TCP本身，因为它用于在服务中传输视频数据。一般情况下，TCP吞吐量与链路带宽、RTT和丢包率相关。由于连接时间与RTT密切相关，我们在图17中研究了其与平均吞吐量性能的相关性。很明显，连接时间和吞吐量之间确实存在很强的相关性。此外，连接时间与平均/中位数吞吐量之间的关系可以用幂律模型来近似(见附录II)。

我们注意到，当连接时间小于5 ms时，幂律模型的准确性显著下降。目前还不清楚为什么非常短的连接时间会低于预期的吞吐量。要进一步研究这种反直觉的现象，还需要做更多的工作。

另一方面，它们的相关性表明，可以利用初始连接时间来预测连接的吞吐量。这对于带宽敏感的应用程序非常有用。例如，预测的吞吐量可用于在非自适应流媒体平台中选择流媒体会话的视频比特率，或在自适应流媒体平台中选择初始比特率。同样，需要做更多的工作来探索这一发现在不同互联网应用程序中的潜在应用。

6 VIDEO STREAMING ANALYTICS

数据集中的应用程序层日志提供了关于流会话的各种性能指标的罕见细节。应用程序日志记录了许多对服务至关重要的流分析，而不是从网络分析中推断或估计流性能[7,41]。下面，我们首先分析两个关键的流指标——启动延迟和播放再缓冲。然后我们分析反映用户粘性的观看统计数据(游戏时间和播放百分比)，试图量化流媒体指标的影响。

6.1 Startup Delay

启动延迟(或启动时间)是指从用户点击视频到开始播放视频的时间。它是商业流媒体服务的关键性能指标之一，因为它直接影响用户体验[26]。

图18绘制了启动延迟分布及其对数正态近似。启动延迟非常短，平均/中位数为445/284毫秒。相比之下，Finamore et al.[12]测量了YouTube上的启动延迟，并在他们的一个数据集中发现超过30%的启动延迟超过1秒。相比之下，在服务的所有四个数据集中，只有不到3%的流启动延迟超过1秒。这些数据反映了短视频服务的根本不同的kpi，其中启动延迟是最重要的指标之一。回想起来，该服务选择适度的视频比特率(~930 Kbps)和小段大小(~ 1 MB)都是为了缩短启动延迟性能而故意设计的选择，这对短视频流媒体至关重要。

我们注意到，有一小部分(0.01%~0.14%)的零启动延迟情况(参见表3中视频本地重放缓存命中率的最后一行)。这种情况发生在同一客户端使用本地缓存的视频数据再次播放同一视频时。非常低的缓存命中率证实了短视频业务最多取一次的特性，如4.3节所述。因此，与流媒体音乐服务不同，在客户端进行本地缓存不太可能在短视频服务中显著降低服务器负载。

6.2 Playback Rebuffering

在视频播放期间，如果客户端耗尽视频数据以维持连续播放，则可能发生重新缓冲。总体再缓冲率(RRB)，定义为至少有一个再缓冲事件的播放比例，在服务中相当低，为0.94%。这可能是由于保守的视频比特率选择(参考第4.2节)。下面，我们将重点讨论带有一个或多个重新缓冲事件的流会话。

图19显示了再缓冲计数的分布，定义为视频播放中再缓冲事件的数量。我们观察到，大多数(76%)的播放只遇到一个再缓冲事件。考虑到视频长度一般较短，这并不奇怪。另一种测量重新缓冲的方法是播放暂停的持续时间（重新缓冲持续时间），如图20所示。结果表明，当再缓冲发生时，再缓冲时间可以相对较长，例如23%的再缓冲持续时间≥5s。考虑到视频片段的大小只有1mb，这表明重新缓冲可能是由异常恶劣的网络条件引起的，例如，暂时失去移动/Wi-Fi连接，然后需要相当长的时间才能恢复。

6.3 Viewing Statistics and User Engagement

观看统计数据衡量播放本身的指标，例如视频播放时间和播放百分比。这些对服务提供商来说是至关重要的统计数据，因为它们反映了用户的体验(也称为用户粘性)。

服务提供商很少发布这些数据，因为它们是专有的商业信息。此外，只有应用程序本身可以直接度量这些统计数据，因此从外部度量它们是困难的(如果不是不可能的话)。

视频播放时间/播放百分比

第一个指标是视频播放时间——从视频播放开始的时间到用户终止播放的时间。由于短视频服务的时长较短，经常会循环播放视频，导致播放时间超过视频长度。此外，它还包括播放暂停时所花费的时间(由于切换到其他应用程序或接听来电而显式或隐式地暂停)以及重新缓冲时间(如果有的话)。

图21为视频播放时间分布图。正如预期的那样，播放时间很短，平均/中位数为27.92/12秒。四个数据集的视频播放时间分布都可以用幂律模型近似，说明之前对视频播放时间的高斯分布假设(如[19])可能不适用于实际的短视频业务。据我们所知，这是关于短视频服务播放时间分布的第一个已知结果。

我们观察到相当大比例的回放(31%)的播放时间少于3秒。这可以归因于用户的浏览行为[42-43]，即用户发现视频开始的几秒钟无趣，会终止视频，切换到下一个视频。这可能会导致大量的数据浪费，因为下载的其余视频数据将被丢弃[19,44]。

与平均视频长度(例如，数据集#4中的40秒)相比，平均播放时间甚至更短(例如，27.92秒)。这意味着相当一部分视频没有被完全观看。这可以用播放百分比来量化，用$R{PB}$表示——定义为播放时间$D{PB}$与视频长度$D_{VL}$的比率:

图22显示了播放百分比的分布。有两点值得注意。首先，由于循环播放、重新缓冲和用户中断，播放百分比可能超过100%。事实上，30.92%的回放超过了视频的长度。其次，在100%左右有一个显著的峰值。接近100%时的增长可以归因于用户意识到视频接近尾声，并提前切换到另一个视频。相比之下，100%后的峰值可能是由于循环播放功能，即在视频结束后重复播放视频。注意到重复，用户然后终止并切换到另一个视频，导致播放百分比略大于100%。

图22中的第一个峰值表明，用户倾向于在播放过程的早期判断视频是否有趣，如果不感兴趣，则会迅速终止并切换。然而，很明显，早期的决定并不总是正确的。作为一个思想实验，假设用户将花费视频长度的前10%来判断视频是否有趣。如果用户对视频很感兴趣，那么用户至少会播放90%的视频。否则用户将终止并提前切换。使用图22中的数据，这意味着决策正确率为36%。对这些数据的进一步分析可以为内容推荐、视频数据预取、缓存等带来有趣的方向。

接下来，我们将进一步分析播放百分比与其他四个指标之间的相关性。

回放再缓冲——除了启动延迟，服务中另一个重要的KPI是回放再缓冲。为了排除内容本身的影响，我们通过将同一视频的流媒体会话与不同数量的再缓冲事件进行比较，将其分为三组:(i)没有再缓冲;(ii)一次再缓冲;以及(iii)多个再缓冲。表7总结了受欢迎程度最高的N=100…，100000个视频的播放百分比。

这个表非常有意思，卡一次之后，用户就不在乎了

据我们所知，这是已知的第一个量化播放再缓冲对短视频服务用户粘性影响的结果。对于传统的视频服务，Dobrian et al.[26]进行了一项测量研究，发现对于60分钟的视频，再缓冲持续时间增加1%可以使播放百分比降低1.6%至4.8%。由于度量不同，我们无法进行直接的定量比较。

尽管如此，该服务的结果确实表明用户对重新缓冲非常敏感。因此，需要更多的工作来将新的量化结果纳入更适合短视频服务的新QoE指标的设计中。

视频流行度

接下来，我们调查视频流行度和播放百分比之间的相关性。直观地说，人们会认为这两者是正相关的。图23所示的实际结果更为复杂。具体来说，播放百分比确实随着视频的受欢迎程度而增加，但只有在$10^{2.5}$次观看时才趋于稳定。这表明，即使是热门视频，相当一部分用户仍然可能只观看视频的一部分，然后再转向下一个视频.

一天中的时间

另一个有趣的角度是时段对观看统计数据的影响。图24和图25绘制了一天中每小时的平均播放时间和播放百分比。在19:00和24:00之间，这两个指标都有显著的增长。

这表明用户不仅在这些时间里观看更多的视频，而且他们观看视频的时间也更长，可能是因为这些时间是他们的休闲时间。

视频长度

直观地，人们会期望播放时间随着视频长度的增加而增加。的确，如图26所示，平均播放时间确实随着视频长度的增加而增加。然而，平均播放时间呈现出不同的轨迹。它的增长趋势在大约90秒之后趋于平稳，然后在较长的视频长度(例如超过130秒)时开始略有下降。

对这种差异的一种可能的解释如下。

短视频服务用户的耐心通常很低，即他们倾向于终止并切换到另一个视频，除非他们从一开始就发现内容很吸引人。因此，对于不太吸引人的内容(例如，下半部分)，用户只会看这么长时间，然后就会切换到另一个视频。因此，中位数播放时间的平台，即25秒左右，代表用户的耐心阈值。

这对于内容制作者来说很重要，因为这意味着视频必须能够在前25秒内吸引观众的注意力，否则用户可能会跳过。从图27的播放百分比结果中可以得出类似的观察结果，在视频长度超过25秒左右时，回放百分比的中位数急剧下降。

图26和27中另一个值得注意的观察结果是，在预设视频长度L1、L2和L3时，两个指标都出现了下降。这一结果与第4.3节图9中视频流行度与视频长度图的结果一致，图9显示，实时视频上传的流行度明显低于预先录制的视频上传。

在表8中，我们通过比较实时视频上传(视频长度为L1、L2和L3)与预先录制的视频上传(视频长度为预设长度加1秒)的观看统计数据，进一步量化了其影响。很明显，实时视频上传明显不受欢迎，预设长度较长的视频上传更受欢迎。L1、L2和L3三个预设时长的平均访问次数仅为预记录时长的40%、23%和8%。这一惊人的发现可能会对短视频服务的内容推荐、资源分配以及更根本的用户界面设计产生深远的影响。

7 DISCUSSIONS AND EXPLORATIONS

在本节中，我们整合了前面分析中的一些关键发现，并讨论了它们更广泛的影响及其潜在应用。

7.1 Mobile Network Rate-limiting

通过对四个数据集的网络分析分析，一个重要的发现是移动网络限速的扩展及其对网络和服务性能的潜在影响。第一个线索来自于吞吐量模型在数据集之间的不一致性。

在5.2节中，所有四种网络类型的吞吐量分布可以用对数正态模型近似。然而，当我们将其应用于数据集#3时，我们发现了一些异常，如图28所示。数据集#3中4G和5G网络的分布明显比模型预测的低吞吐量情况要多。

进一步调查表明，这可能是由移动运营商[45]的费率限制政策造成的。大多数运营商提供的数据SIM卡都有数据配额(例如5gb)，供全速或高速上网。一旦配额用完，运营商将把用户可用的最大带宽限制为更低的数据速率(例如，1mbps或更低)。这是无限数据(可用但非常昂贵)和固定数据配额(更便宜，但一旦配额用尽就非常不方便)之间的折衷。最重要的是，中国大多数数据SIM计划采用按日历月计费的会计周期。

换句话说，用户之间的费率限制的影响是同步的，并且会随着日历月的结束而增加。这解释了数据集#3中的异常，因为这些数据是在本月16日至17日之间捕获的，而不是数据集#4中的2日至10日。进一步分析，我们在表9中计算了低通量(<1 Mbps)的请求从数据集#4每月的三个特定的天。我们只使用数据集#4的数据，因为它涵盖了更广泛的天数范围，而且它们都是在同一个月内捕获的，从而最大限度地减少了潜在混杂因素(如网络基础设施的改进)的影响。

表9中的结果显示，低吞吐量比率随着时间的推移而显著增加。作为对照，我们计算了Wi-Fi的相同比率，但没有显示出这种增长趋势。另一个值得注意的发现是，限制速率的措施很早就开始生效了——到10日，这一比率已经增加了2.6倍。回想起来，也许这是意料之中的，因为我们的样本是针对短视频用户的，因为视频流本质上是数据密集型的。

移动网络速率限制可能对服务性能产生重大影响。例如，我们在表10中比较了4G和Wi-Fi请求在这三天内的再缓冲率。4G的再缓冲率从2日的1.37%上升到10日的2.21%，而对照Wi-Fi的再缓冲率则没有这种趋势。更糟糕的是，如果限制速率低于服务的视频比特率，服务将无法通过移动网络使用。

上述发现可能只是冰山一角，因为费率限制的影响远远超出了短视频服务。这是一个未知的领域，考虑到移动网络中速率限制的广泛部署，更彻底地了解其特征、影响和检测可能会导致改进各级移动服务的设计。

7.2 Exploring ABR for Short Video Streaming

鉴于自适应流媒体已经广泛部署在许多其他流媒体服务中，这就引出了一个问题，为什么短视频服务还没有采用它们。

下面通过经典算法实现进行探索。

表11总结了模拟设置。我们保留了ABR算法的原始设置，除了视频长度，现在的范围从8到156秒。我们注意到，原模拟器[46]在计算QoE时没有计算启动延迟。这可能不适合评估短视频服务，因为启动延迟是关键kpi之一。

因此，我们采用了两个版本的QoE指标，

测量视频质量、再缓冲和质量变化。

结合启动延迟惩罚

我们的目标是探讨视频长度和启动延迟惩罚对ABR算法的影响，因为这是当前流媒体服务和短视频服务之间的两个关键区别。首先使用图29中的QoEnorm1评估了ABR算法的QoE性能与视频长度之间的关系。在同一幅图中，我们还绘制了从动态规划[46]获得的离线最佳QoE(假设完全知道未来带宽)。有两个重要的观察结果。

首先，可以看出视频长度对三种ABR算法的QoE性能有显著影响。具体来说，它们的QoE会随着视频长度的缩短而降低。当视频长度低于40 s左右时，退化加速。请注意，我们假设视频总是在模拟器中完全播放，因此视频长度更接近于实际的视频播放时间。在该服务中，只有23.35%的流媒体会话的播放时间超过40 s，这意味着当前的ABR算法在大多数情况下可能会在性能下降的情况下运行。

其次，即使是离线最优，在短视频长度下也表现出类似的性能下降。导致性能下降的一个原因是第一个视频段的初始比特率选择，默认是第二个比特率版本(750 Kbps)。虽然这种选择在视频长度较长的传统流媒体服务中可能无关紧要，但随着视频长度的缩短，它对短视频流的影响会迅速增加。例如，对于一个20-s的视频，初始段(4 s)已经占整个视频的20%。虽然当带宽允许时，ABR算法随后会提高比特率，但比特率阶梯上升也会导致比特率变化惩罚(即(6)中的第三项)，这抵消了视频质量的提高。在传统的流媒体中，由于视频长度通常较长，在比特率收敛时，ABR算法仍然可以获得优势。相比之下，在短视频流中，ABR算法甚至可能没有足够的时间收敛，更不用说从优化的比特率选择中获益了。

接下来，我们在图30中探索启动延迟惩罚的影响，图中绘制了四种方案的QoEnorm2与视频长度的关系。启动延迟的惩罚进一步降低了QoE性能，以至于在小于56秒的视频中变为负值。显然，结果取决于启动延迟惩罚的加权系数的选择——在本探索性研究中，我们将其设置为与卡顿惩罚的加权系数相同(表11)

上述探索性实验的结果显然不是结语，而是展示了当前ABR算法应用于短视频流时潜在的性能限制。短视频长度和启动延迟带来的巨大性能影响要求我们不仅在ABR算法的设计上要有新的思考，而且在短视频业务QoE函数的制定上也要有新的思考。

8 SUMMARY AND FUTURE WORK

该测量研究中的大量数据分析为研究大规模短视频业务的特征和行为提供了新的见解。测量结果中的大部分可以用著名的数学分布进行建模，可以很好地应用于短视频业务的研究中，既可以作为提高模拟器逼真度的输入，也可以作为系统模型的基础进行性能分析和优化。除了正文中介绍的模型之外，读者还可以在附录中找到其他模型。

此外，测量结果还揭示了短视频服务的许多特征，这些特征与传统的流媒体服务明显不同。例如，游戏的迅速流行演变;在很短的时间尺度上符合Zipf定律;受欢迎程度、上传时间和视频长度之间有很强的相关性;预先录制的视频和实时上传的视频在流行程度上的惊人差异;连接时间与吞吐量之间的相关性;移动网络限速的影响;极短的用户耐心;等等。

这些发现中的许多都指向了设计和优化短视频服务内容交付的新方法，考虑到短视频服务的覆盖范围和规模在短短几年内的增长，这是未来研究的重要课题。此外，第7.2节的探索性实验清楚地展示了当前ABR算法应用于短视频业务的局限性，这不仅需要在设计上进行新的思考，也需要在对短视频业务的评估上进行新的思考。