简介
自适应比特率（ABR）算法在流媒体中被用来根据观众的网络条件实时调整视频或音频流的质量。ABR 流媒体的目标是通过根据观众可用带宽调整流的比特率，提供流畅的播放体验。
随着 VR 头戴设备的普及，360°视频流媒体正快速发展，也意味着需要更高的比特率，因此，使用高效的流媒体算法就变得很关键。而且 360° 视频流媒体的 ABR 算法甚至可以比常规 ABR 更进一步，因为视频质量可以根据用户所看到的视窗动态调整，传输更高质量的内容。这涉及提前预测用户的头部和凝视动作，以建立一个可以适应带宽变化的缓冲区。
现有的针对 360° 视频流媒体所做的工作提出了改进 QoE 或带宽利用率的新方法，但往往难以进行公平的比较，因为模拟它们的代码并未全部公开。近年来已经出现了几种工具，以提高该领域的可复现性。其中一种是由 Spiteri 的团队发布的作为 Sabre（一个用于 ABR 算法的开源模拟环境）的扩展的 Sabre360。虽然 Sabre360 可以用来比较 ABR 算法，但它有一些缺点：(i)它不会出现卡顿，而是播放“空白块”，(ii)它基于一个只支持一种 tile 布局（4x4 tiles）的“视图”系统构建，(iii)质量分配的 ABR 优化是在每个块下载之间进行的，并且为每个片段的每个块发出了单独的请求，这很难实现。
本文在很大程度上借鉴了 Sabre360 的想法，提供了 SMART360，一个 360° 流媒体模拟环境，旨在解决现有方案在比较运动预测和 ABR 策略方面可能存在的不足。
本文的贡献如下：
- 提供一个基于现有解决方案的基础上的、配备了大规模的数据集和基准算法的新的模拟器，并解释了代码结构和逻辑；
- 提供了预处理流程，以增加透明度并使用户能够轻松创建模拟器的新输入配置；
- 详细解释了如何使用 SMART360 来比较现有的和新的运动预测以及 ABR 策略，并展示了可用于评估算法的指标和可视化示例。
数据预处理
模拟器输入
SMART360 模拟器的所有输入数据都存储在 config/ 目录中，采用与 Sabre360 相同的JSON格式。SMART360-simulator/config/ 目录中提供的数据分为两种类型：真实数据和合成数据。真实数据从多个公共数据集中提取；合成数据包含了具有恒定带宽和统一大小的 360° 视频的简单网络 trace 示例。
网络 trace
网络 trace 描述了不同情况下的可用带宽和延迟随时间的变化，可以进行带宽高度可变的逼真模拟。在真实输入数据中提供的网络 trace 来自 van der Hooft 等人发表的 4G/LTE 数据集，该数据集由比利时根特市多个路线上的 40 个带宽测量 trace 组成。
注意，为了使 ABR 算法之间的比较具有相关性，需要在算法能够适应网络限制的情况下进行，因为不管网络带宽远大于或远小于视频速率，ABR 算法用处都不大。为了进行 ABR 算法之间的相关比较，作者提供了一个 Jupyter 笔记本，将网络 trace 相对于视频比特率进行缩放，如图 1 所示。
图 1 网络 trace 缩放原理
用户头部运动轨迹
用户头部运动轨迹描述了用户观看 360° 视频时头部方向的坐标随时间变化的情况，用以计算用户在视频的哪段时间内看到哪些图块。本文使用来自 94 个 360° 视频的 3518 个头部运动轨迹数据。采用 5Hz 的采样率，并使用三维笛卡尔坐标系，将头部面朝的方向表示为单位球上的一个点。本文提供了一个 Python 脚本，可以将这些 trace 数据从原始的 CSV 格式转换为类似于 Sabre360 中使用的 JSON 格式。
视频清单
视频清单描述了要通过网络流式传输的视频文件。在 360° 切分视频的情况下，清单描述了切分布局和不同质量级别的编码，SMART360 模拟器使用视频清单来获取每个下载图块的大小。本文提供了简化的 JSON 视频清单，包含上文提到的 94 个视频。
预处理流程
预处理流程基于 TOUCAN-preprocessing（一个基于 Java 的命令行应用程序，可以使用 FFmpeg 和 MP4Box 将普通的 360° 视频转换为 DASH-SRD 描述的视频），为了简化原始流程、更新编码参数并适应本文任务需求，本文对其进行了一些更改，流程如图 2 所示。
图2 360SMART 视频预处理流程
视频分块和重编码
首先，使用 FFmpeg 的裁剪滤镜将 MP4 视频切分为图块。由于裁剪视频需要重新编码，本文选择在切分过程中以不同质量级别重新编码视频图块。切分布局和质量级别可以在每个视频的 XML 文件中指定。
使用 libx265 对视频进行重编码，使用HEVC压缩标准。不同的质量级别是通过不同的恒定率因子（CRFs）来实现的。CRF 比恒定比特率（CBR）和恒定量化参数（CQP）更适用，是综合考虑了速率稳定性、效率和编码时间后得出的最佳方案。
DASH 打包
视频被裁剪成所需的 tile 布局并以适当的质量级别重编码后，再使用 MP4Box 来获得符合 DASH-SRD 标准的视频片段。片段持续时间也可在上述提到的 XML 文件中指定。此步骤的输出文件是 MP4 轨道和每个视频的 XML 清单，对应可以在网络中流式传输的文件。
JSON 文件生成
本文提供一个 Python 脚本用于构建可以被模拟器使用的 JSON 清单，具体做法读取先前生成的文件，仅保留对模拟有关的信息，并将其放入 JSON 视频清单中。
模拟器架构
SMART360 模拟器的架构基于 Sabre360 模拟器的架构，但有一些重要的改变，旨在纠正简介中提到的缺点。
- 引入实际的卡顿事件，而不是播放空白图块来暂停视频播放；
- 重新设定坐标系统并修改头戴显示器模型，以支持任何矩形 tile 布局；
- 重新设计模拟器和 ABR 逻辑，能够提前规划多个图块和片段的质量分配。
图3 SMART360 模拟器的 UML 类结构
文件和对象结构
图 3 中呈现了简化的类结构，图中标红的类，包括 BandwidthEstimator、TiledABR 和 Viewport-Predictor，可以很容易地扩展以实现新的算法。
Session
session.py 文件包含 Session 和 SessionInfo 类。Session 类是包含了所有模拟所需对象的主要类。Session::run 函数是模拟器的入口，并在算法 1 中进行了描述。SessionInfo 类主要用于访问信息和对象，如缓冲区、日志文件或视窗预测器等。
Buffer buffer.py 文件包含 TiledBuffer 类。该类以二维 NumPy 数组的形式保存缓冲区，大小为 B×T，其中 B 是缓冲区大小（以片段数量表示），T 是视频中 tile 的数量。该类还提供了用于更新缓冲区的函数。
Headset
headset.py 文件包含 HeadsetModel 和 HeadsetConfig 类。这些类包含关于头戴设备的配置（ tile 布局，视场大小）的信息，并提供函数来计算在给定用户头部坐标的情况下哪些 tile 是可见的。与大多数现有工具不同，对 tile 的计算考虑了由全景投影产生的失真。
User
user.py 文件包含 UserModel 类。该类处理用户头部运动的轨迹，并用于获取头部运动坐标的更新。
Network
network.py 文件包含 NetworkModel 类。这个类处理网络 trace，并提供来根据网络 trace 中的带宽和延迟信息下载 tile 的函数。
Bitrate adaptation
br_adaptation.py 文件包含 TiledABR 抽象类及其子类。这个类负责决定下载哪个片段的哪些 tile 以及下载质量和顺序。本文提供了三种没有缓冲区替换的简单 ABR 策略：
- TrivialABR 尝试以最低质量下载所有 tile ，并尽快填充缓冲区。
- MaxStallABR 用于实验目的，用于计算用户可能的最大卡顿比率，在只有在视窗中缺失 tile 并导致卡顿时下载。
- BaselineABR 中包含一些基于速率和缓冲区的元素。
Viewport prediction
vp_prediction.py 文件包含 ViewportPredictor 抽象类及其子类。这个类用于对用户头部移动及视窗进行预测。本文提供了两种基本的视窗预测器以及一个基于深度学习的预测器的实现：
- NoPredictor 对所有 tile 给出相等的概率。
- StaticPredictor 假设用户不会移动，并给予视窗内的 tile 更高的概率。
- DVMSPredictor 使用 Guimard 等人的 DVMS 深度学习模型进行预测。
Bandwidth estimation
bw_estimation.py 文件包含 BandwidthEstimator 抽象类及其 EWMA 子类。这个类可以用来估计未来网络的带宽和延迟，对于 ABR 规划非常有用。EWMA 子类根据指数加权移动平均模型进行延迟和带宽估计，与 dash.js 参考播放器中的函数类似，但以简化的方式实现。
Logging
logging.py 文件包含 LogFile 类。这个类提供了将模拟信息和测量结果添加到记录列表的函数，然后在模拟结束时将其写入 JSON 日志文件。
Notebooks
network_traces_scaling.ipynb 用于将网络 trace 相对于视频比特率进行缩放。output_metrics.ipynb 则给出了 SMART360 输出指标的可能可视化示例。
模拟逻辑
图4 算法1
图5 算法2
在算法 1 的第 3 行和第 9 行，以及算法 2 的第 1 行出现的三个 ABR 函数是 TiledABR 抽象类的三个函数，必须由子类实现，这些函数返回下载计划，记为 skd。下载计划是一个有序列表，每个元素都包含 s（段号）、t（tile 号）和 q（质量级别）。在启动和卡顿的情况下（算法 1 的第 3 行和算法 2 的第 11 行），必须在视频播放恢复之前下载完整的计划。在常规 ABR 决策函数的情况下（算法 1 的第9行），元素按照计划中给定的顺序在 ∆DL 秒内下载。
在算法 1 的第 5 行和算法 2 的第 13 行和第 17 行，“下载”意味着使用具有适当延迟和带宽的 NetworkModel 类，并将下载的 tile 放入缓冲区。
算法 2 详细解释了模拟器中最复杂的函数之一 Session::play_and_download 的逻辑。该函数允许同时进行视频播放和 tile下载，同时确保 NetworkModel 和 UserModel 保持同步。这种方法比 Sabre360 带来了两个改进之处：
- ABR 算法每隔 ∆DL 秒计划和发出下载一组 tile 的请求，这比 Sabre360 中非常频繁的 ABR 优化和请求更加真实。
- 可以发生卡顿，并且可以测量卡顿时间，这也比 Sabre360 中的不卡顿但显示空白 tile 更加真实。本文选择在 SMART360 中只有当用户应该看到的 tile不在缓冲区中时才发生卡顿事件，这意味着如果缓冲区中缺少 tile 但不在用户的视野范围内，视频不会停止。
使用SMART360进行运动预测器和 ABR 算法的比较
该部分将解释研究人员如何使用 SMART360 模拟环境来实施新的 ABR 策略和 360° 视频流媒体的运动预测算法，并进行比较。
在SMART360中实现ABR策略
要实施新的 ABR 策略，只需创建 TiledABR 的一个新的子类，并实现三种函数，其中每个都返回一个下载计划，包含由 s 表示的段号、t 表示的 tile 号和 q 表示的质量级别。除了函数参数，ABR 类还可以访问其他信息，如缓冲区内容、视频清单或视窗预测器。
- startup_dl_schedule() 函数在模拟开始时调用。它必须返回一个在视频播放开始之前要下载的计划。
- decide_dl_schedule(bwest, ∆DL) 是主要的 ABR 决策函数。它每隔 ∆DL 秒调用一次，并根据估计的带宽决定在接下来的 ∆DL 秒内要下载的计划。
- stall_dl_schedule(Tmiss inд) 在发生卡顿事件时调用。在这期间，当视频卡顿时，缺失 tile 列表（位于用户视野内）将作为参数传递，并且该函数必须返回一个下载计划。只有当所有缺失的 tile 和计划中的所有内容都被下载完毕时，视频才能恢复播放。
在SMART360中实施运动预测器
SMART360 还允许实现头部运动预测算法，并以视窗预测器的形式在 ABR 算法中使用。要实现一个新的运动预测器，只需创建一个继承自ViewportPredictor抽象类的子类，并实现其中两个函数：
- predict_tiles(s) 函数需要由子类实现。参数 s 对应于我们想要进行预测的段号。该函数返回一个长度为 T 的列表，其中每个元素对应每个 tile 的评分。较高的评分意味着在段 s 期间出现在用户视窗中的可能性较高。
- update_coord(coord) 函数可选实现。它允许使用新的头部坐标更新运动预测器，以便进行预测。
SMART360 输出指标
如图6-图 10 所示，SMART360 给出了许多与 QoE 相关的可视化度量，以及一些与网络相关的度量。
图6
图 6 比较了在所有观看了该视频的用户中，使用两个不同的视窗预测器观看一个视频时的平均视觉质量，质量级别从1到5，可以看到 StaticPredictor 比 NoPredictor 提供了更高的平均可见质量。
图7
图 7 比较了在所有观看了该视频的用户中，使用两个不同的视窗预测器观看一个视频时的平均视觉质量与视频时间的关系。从该图可以更明显地看出，StaticPredictor 比 NoPredictor 提供了更高的平均可见质量。
图8
图 8 比较了在使用两个不同的视窗预测器观看同一个视频时，总卡顿时间与视频时间的关系。可以明显看到，StaticPredictor 比 NoPredictor 卡顿时间更短。
图9
图 9 比较了使用两个不同的视窗预测器观看同一个视频时，在用户的视窗中已下载好的 tile 的平均质量与“下载偏移量”的关系，下载偏移量为 -6 意味着在播放之前 tile 已经下载好了 6 秒钟。显然 StaticPredictor 提供的平均可见质量比 NoPredictor 更高，无论缓冲级别如何。
图10
图 10 比较了使用两个不同的视窗预测器观看同一个视频时的“命中率”的分布。命中率是出现在用户视窗中的比特数与下载的总比特数的比值，可以看作是带宽效率的体现。可以看到，StaticPredictor 比 NoPredictor 更高效，并且浪费的带宽更少。
总结
SMART360 成功解决了现有解决方案的不足之处，能够真实地模拟 360° 流媒体系统并高效地比较 ABR 策略以及头部运动预测算法。
可能的改进包括但不限于：考虑每个 tile 实际在视窗中的百分比，以更准确地衡量可见质量，而不是无论 tile 实际在视窗中的比例如何，都将其视为在视窗内；使视窗预测器能够利用比过去的头部坐标更多的信息，例如视频显著性地图；在模拟期间发生事件时，使用多个线程和线程之间的通信，而不是使用Session::play_and_download 函数的单块结构。
