论文翻译1-PARSEC-Streaming 360-Degree Videos Using Super-Resolution

论文翻译-Streaming 360-Degree Videos Using Super-Resolution（2020infocom)

使用超高分辨率流式传输360度视频

关键词：360◦视频，ABR流，超分辨率
摘要：360°视频为用户提供了身临其境的体验，但与常规视频相比，流媒体传输需要更多带宽。最新的360°视频流系统使用视口预测来减少带宽需求，这涉及预测用户将观看视频的哪一部分，并仅获取该内容。但是，视口预测容易出错，导致用户体验质量（QoE）变差。我们设计了PARSEC，这是一种360度视频流系统，可以减少带宽需求，同时提高视频质量。 PARSEC权衡带宽以进行其他客户端计算以实现其目标。 PARSEC使用基于超分辨率的方法，其中视频在服务器上得到了显着压缩，客户端运行深度学习模型以将视频增强到更高的质量。 PARSEC解决了与为360°视频流使用超分辨率相关的一系列挑战：大型深度学习模型，缓慢的推理速度以及增强视频质量的差异。为此，PAR-SEC在较短的视频片段上训练小型微模型，然后将传统的视频编码与超分辨率技术结合起来以克服挑战。我们在真实的WiFi网络，FCC发布的宽带网络跟踪以及4G / LTE网络跟踪中评估PARSEC。 PARSEC在降低带宽需求的同时，大大优于最新的360°视频流系统。

1. introduction

  360° 视频流通过将全景内容投影到虚拟显示器上，带来身临其境的体验。 它在商业流媒体平台上的受欢迎程度正在上升。 360° 视频的主要挑战在于，由于其全景性质，它们需要比普通视频多 8 倍的内容下载，才能获得相同的感知质量[11]。 最近的工作表明，带宽需求可以通过 viewport1 自适应流来减少，其中要下载的内容仅限于用户预测的视口 [32]、[41]、[42]。 360° 视频在时间上被划分为片段以启用流式传输，每个片段在空间上被划分为视频块以启用视口自适应。
  不幸的是，准确的视口预测很困难； 最先进的视口自适应系统的准确度仅为 ≈ 58 - 80%，即使仅提前 1 秒进行预测，并且在更长的持续时间内逐渐降低 [15]、[32]。 为了对抗不完美的预测，超出预测视口额外的内容需要获取以避免在查看时丢失视口的部分 [32]（tile丢失）。 这只解决了部分问题，因为这些额外的内容也会消耗网络带宽
  我们描述了一种不同的方法来流式传输 360° 视频以更好地适应：用网络带宽来换取客户端计算能力。 我们设计了 PARSEC（带神经编码的 PAnoRamic StrEaming）——一种通过网络获取低分辨率 360° 视频内容并利用基于深度神经网络 (DNN) 的超分辨率最新进展在客户端重建高分辨率内容的系统 [14]、[24]。 虽然总体思路是有前途的，但这种方法存在一些挑战，所有这些挑战都源于 360° 视频的大尺寸。 首先，大部分 360°内容是在移动设备上消费的。 尽管当前一代移动设备提高了计算能力，但运行 DNN 模型以从低分辨率输入重建高质量 360° 视频的速度非常慢 [22]。 其次，DNN 模型很大，需要相当大的网络带宽 [45]，这违背了最初的动机。 最后，由于模型必须对整个视频进行泛化，因此重建视频的质量存在很大差异。 使用类似神经技术 [18]、[45] 的相关工作不会面临任何这些问题，因为它们是为相当小的常规视频而设计的。
  PARSEC 利用了两个非常适合 360° 视频的想法。首先，PARSEC 在视频的小片段上训练超分辨率 DNN 模型（§III）。 使用这些小型微模型会带来三个好处：i) 更快的推理速度，ii) 通过基于用户当前的视口动态生成任何图块来解决视口预测的不准确性，iii) 网络上的模型传输现在是高效的，并且可以 为每个片段流式传输，与开始时为整个视频流式传输单个大型模型不同。其次，PARSEC 使用神经感知自适应比特率 (ABR) 算法 (§IV) 汇集计算和网络资源。 对于空间划分给定视频片段的tiles子集，PARSEC 使用 DNN 模型在本地生成高分辨率tile。 对于剩余的切片子集，PARSEC 会根据可用网络带宽从服务器以高分辨率流式传输切片。 根据预测的视口、可用带宽和可用计算资源，ABR 算法确定在本地生成哪些图块以及从服务器获取哪些图块。 PARSEC 将此问题表述为整数线性规划并使用贪心算法解决它。 最后，PARSEC 将神经 ABR 技术与视口预测相结合，并通过动态更新预测来重新安排图块生成。
  我们在 GPAC [21] 之上实现了 PARSEC，这是一个多媒体库，为 DASH 格式的视频编码、渲染和图块打包提供 API。 我们使用 Keras [4] 和 Tensorflow [10] 框架在 Python 中开发 DNN 模型。 我们使用 360° 视频数据集 [25] 评估 PARSEC，该数据集具有 50 个用户在观看 10 个视频时头部运动的痕迹。 我们将性能与三种替代方法进行比较 - Flare [32] 和 Fan 等人 [15] 为 360° 视频而设计，以及 NAS [45] 为 360° 视频而设计。
   PARSEC 在所有实验中都优于所有三种替代方法 . 在视频体验质量 (QoE) 方面，PARSEC 的性能优于最先进的 360° 视频流系统 Flare [32]，比公开可用的宽带网络和 4G/LTE 轨迹高出 37-48%。 PARSEC 还将真实 WiFi 网络实验的 QoE 提高了 17-28%。 当网络真的很差（1 Mbps）时，PARSEC 的相对性能甚至更好，比替代方案高 1.8 倍。 最后，我们强调，当网络不是瓶颈时，PARSEC 使用的带宽比 Flare 少 43%，这在多个用户访问同一网络时更有希望（§V）

2. BACKGROUND, RELATED WORK AND OVERVIEW

A. 360° 视频流

  360° 视频是同时记录多个摄像机方向的球形视频。 录制的内容被投影到平面上 [1]、[2]、[49]，然后使用传统的视频编码技术（例如 HEVC [48]）和 DASH [36] 等协议进行流式传输。 我们假设了一个等距柱状投影 [1]，就像在相关工作[15][30][32][43]中通常使用那样。
ABR 流媒体：对于流媒体，视频首先跨时间分段，然后每个片段以多种不同的比特率/质量级别进行编码并存储在服务器中。 每个视频片段可用的不同质量级别在从服务器发送到客户端的清单文件中捕获。 客户端（或有时是服务器）运行自适应比特率 (ABR) 算法 [45] 以根据可用网络带宽确定流媒体的比特率。
视口自适应 360° 视频流：360° 视频需要下载 8 倍于相同质量的常规视频的内容，因此显着增加了带宽要求 [11]。 为了解决这个问题，最近的研究使用视口预测 [15]、[30]、[32]、[43]。 360° 视频的每个片段，在投影到 2D 平面后，在空间上被分割成tiles。 只有用户预测视口中的图块才会流式传输到客户端。 视口自适应流系统根据与预测视口指定要获取哪些图块，然后使用 ABR 算法来确定要用于这些图块的比特率。 最近的研究，如 [15]、[30]、[32]、[43]，都遵循类似的架构

B. PARSEC 的动机

  PARSEC 通过利用客户端设备上未充分利用的计算能力克服了视口预测精度低的限制，如下所述。
限制 – 视口预测的准确性较差：显然，完美的视口预测可以使 360° 视频在带宽使用方面与普通视频一样高效，同时体验质量相同。 然而，实际上这种预测的准确性很差。 这并不奇怪，因为预测视口与预测全景场景中用户未来的视觉注意力是一样的——这是计算机视觉中的一个具有挑战性的问题 [20]、[29]。 例如，最先进的视口预测 [15]、[32] 的准确度约为 58-80%，可以提前一秒预测用户视口。 进一步提前的预测表现出更差的准确性。 为了适应由于视口预测不佳而导致“tile miss”的可能性，一些自适应 360°流媒体系统 [17]、[32] 以较低的分辨率获取额外的tiles（例如，预测视口附近的tiles）。 这些非视口图块现在与视口图块一起争夺带宽。 这在用户实际查看的内容的分辨率和tile未命中（这将导致停顿）的可能性之间进行权衡。 这会影响体验质量。 我们的评估（§V）证明了这个问题。 虽然视口预测很重要，但目前可用的计算机视觉技术仍然不足
机会——客户端计算能力未得到充分利用：如今的移动设备拥有多核高速 CPU 和各种协处理器，特别是功能相当强大的 GPU，可以加速各种符合 SIMD 范式的计算。 NPU（神经处理单元）将很快在移动平台上可用 [9]
  因此，一个有前途的方向是利用未充分利用的计算能力来使用神经编码来提高视频内容的质量 [18]、[45]。 在这里，视频被缩小并显着压缩到非常低的分辨率，然后经过适当训练的 DNN 模型重建视频的高分辨率版本。 这将部分负担从网络转移到客户端设备上的处理器。 我们探索了不同的近期深度学习技术，例如生成对抗网络 (GAN) [16]、自动编码器 [33] 和超分辨率 [24]，并发现超分辨率是在流媒体视频环境中最合适的方法 推理和模型复杂性（见 §III）

C. PARSEC 概述和目标

   PARSEC 的目标是在带宽受限和视口预测不完善的情况下提高 360° 视频的 QoE。 关键思想是 1) 利用客户端设备中未使用的计算能力来重建视频内容，2) 在下载什么内容和重构什么内容之间达到最佳平衡。 重建部分使用基于深度学习的超分辨率方法，能够从缩小版本中重建内容。 我们表明，通过利用 GPU 等客户端协处理器，PARSEC 可以显着降低网络带宽压力，克服视口预测精度低的问题，并提高 QoE。 有两个关键创新。
使用微模型（§III）：在常规视频 [18]、[45] 中使用的超分辨率的直接应用在 360° 情况下效果不佳，因为神经网络模型尺寸非常大且推理速度变慢（每秒可以重建的帧数）。 在 PARSEC 中，我们探索了微模型（非常小的模型）的使用，即 i) 一次对小视频片段长度进行建模，ii) 一次为片段重建一个图块，而不是整个全景场景。 这改善了下载时间和推理率。 这种逐块方法还允许从非常低分辨率的输入（我们称之为超低分辨率或 ULR 块）进行升级的灵活性，同时仍保持模型大小合理。 在我们的评估中，我们实现了 64 倍的升级（§III-C）
神经感知 ABR 算法（§IV）：即使使用微模型提高了推理率，本地生成图块的速度也不足以支持高质量的视频流。 因此，PARSEC 利用网络和计算资源来流式传输 360° 视频。 PARSEC 选择从服务器获取哪些切片，以及在本地生成哪些切片。 PARSEC 的神经感知 ABR 算法考虑了本地生成的tile质量的差异，以及网络和计算能力。 PARSEC 将其调度算法合并到视口自适应 ABR 框架中。 最后，PARSEC 能够在客户端设备上动态重新安排图块生成，以响应用户视口的变化。 由于 PARSEC 可以将图块压缩为超低分辨率 (ULR)，因此对于每个视频段，PARSEC 会下载所有 ULR 图块。 以上两者的结合使得 tile 未命中相对不常见（在 §V 中得到验证）。

3.STREAMING 360◦ VIDEOS USING SUPER-RESOLUTION

   超分辨率从同一场景的一张或多张低分辨率图像中创建或恢复高分辨率图像 [24], [31]。 它已被用于监视 [50]、医学成像 [35]、[39]，最近还用于视频流 [45].在这里，视频应用程序已经使用传统技术编码/压缩视频以减少带宽需求。 超分辨率通过提供一个训练有素的 DNN 模型，让客户使用该模型从非常低分辨率的输入中“推断”出原始高分辨率内容，从而显着地进一步推进了这一总体思路 [24]。 推理利用了客户端可用的 GPU 能力

A. 360° 与常规视频

   虽然超分辨率确实很有前景，但需要谨慎的设计决策才能使其有效工作。 这里的关键挑战是 360° 视频的大空间内容。 由于视口预测的准确性较低，需要对整个 360° 视频进行训练，以便可以根据用户的视口在客户端重建任何图块。 结果是训练来重建 360° 视频的模型 1) 大，造成从服务器传输到客户端的额外负担，以及 2) 具有较慢的推理速度，可能会导致播放速度的实时要求。 试图保持模型复杂度较低会导致视频质量下降。
   为了说明这一点，我们使用§V 中描述的实验设置运行了一系列微基准测试。 我们训练了一个类似于 NAS [45] 的 DNN 模型，这是一项最近的视频流研究，它对常规视频使用超分辨率，并为整个视频训练单个模型。 使用 1 分钟的视频长度进行训练，目标 PSNR 为 30dB。3 图 1a 显示了视频分辨率对 Galaxy S10 手机的模型大小和推理率的影响。 从图中可以看出：1) 4K 和 8K 视频等高分辨率内容的推理速度非常慢（低于 2 fps），2）这些高分辨率的模型尺寸非常高。 图 1b 通过显示不同视频片段持续时间的训练如何影响性能指标来补充此分析。 对于较长的视频片段，推理率逐渐变差，对于 1 分钟长的视频，推理率低于 2 fps。 即使对于最小的视频长度（1 秒），它也达不到（< 10 fps）。 此外，模型大小随着视频长度超过某个点（5 秒）而超线性增加
   显然，对常规视频效果很好的超分辨率技术的简单使用对 360° 视频无效。 然而，360° 视频提供了独特的优化机会。 首先，超分辨率可以单独用于tile而不是整个全景场景，并且只能生成可能在视口中的tiles，从而节省推理的计算负担4。 此外，并非所有tiles’都在视口中。 需要生成视口； 有些可以使用传统的自适应流技术下载。 我们将在§IV 中探讨后一个方面

B. 超分辨率的微模型

   PARSEC 针对非常短的视频长度训练模型, 我们称它们为微型模型。 在上一个章节我们已经表明，针对较短的视频长度训练模型在推理率和模型大小方面都是有效的。 此外，微模型在分段级别进行训练，以便可以根据用户的当前视口动态放大单个图块。 这对于 360° 视频尤其重要，因为用户只能看到场景的一部分，而这部分无法提前准确预测。 权衡是客户端下载了大量的小（微）模型，但每个微模型只针对一个短视频片段进行训练。 定期下载小模型比在视频流开始时下载一个大模型更有效。 我们现在描述如何在 PARSEC 中构建模型。

超分辨率架构：我们的超分辨率模型架构如图 2 所示。我们使用类似于 [24]、[45] 的深度卷积神经网络 (CNN) 来捕获视频中的高级特征。 我们根据视频片段的长度和生成的视频所需的质量来改变网络层的数量。 每个卷积层后跟一个 LeakyRelu 激活函数 [26]，以及用于更快学习的批量归一化 [19]。 神经网络首先从低层像素中提取高层特征，并使用非线性映射函数来学习原始缺失的内容细节。 最后，网络使用反卷积层直接从低分辨率映射高分辨率，无需图像插值。 超分辨率的更多细节可以在 [24]、[31]、[45] 中找到。
模型训练：每个模型针对一个视频片段进行训练。 首先，原始视频被分成时间段（例如，1-2 秒）并在空间上平铺（例如，192×192 像素）。 然后每块tile缩小（例如，24×24 像素）并使用标准 H.265 编码器进行压缩，从而产生 ULR 图块。 然后对每个 ULR tile 进行解码，并将其作为输入馈送到神经网络，以使用地面实况 tile 重建原始高分辨率。 在训练时，我们使用 PSNR 指标 [47] 作为损失函数来直接优化 PSNR 质量。 当从 ULR 切片映射到高分辨率时，我们手动微调层数和过滤器大小以达到所需的中值质量。 我们凭经验确定所有设计选择的最佳值，例如tile尺寸、缩小的程度和段的长度（如§V 中所述）

C. 超分辨率与 HEVC 编码的优势

   了解超分辨率方法中重建视频的质量及其带宽使用情况非常重要。 我们比较了超分辨率方法中生成的视频与多比特率下的标准 HEVC 编码的 PSNR（图 3（a））以及相应的网络实际需求（以字节为单位）（图 3（b））。 显然，超分辨率方法在质量方面比 1 Mbps 视频更好，同时节省了大约 7 倍的带宽（中值）。 在第 90 个百分位处，节省更为显着。 这全面展示了超分辨率方法在流式传输 360° 视频方面的潜力。

4.NEURAL-AWARE ABR ALGORITHM

   PARSEC 的自适应比特率 (ABR) 算法探索了可用网络和客户端计算能力之间的权衡。 与使用网络作为唯一资源的现有 360° 视频流解决方案相比，PARSEC 对其 ABR 使用混合方法：1) 它使用可用的网络容量从服务器流式传输tiles的子集； 2）它决定要获取的图块的比特率（质量）； 3) 它还利用客户端设备的可用计算能力使用超分辨率技术“生成”不同的图块子集。 后一步骤从服务器获取 ULR 图块以及必要的 DNN 微模型（§III）。
   图 4 显示了 PARSEC 的系统架构。 编码的视频和 ULR 图块存储在服务器中。 客户端使用“神经感知”的 ABR 算法来决定获取或生成哪些图块，即了解两种方法之间的权衡。 决策还将用户的视口概率分布和可用网络与计算能力作为输入。 目标是优化整体视频体验质量 (QoE)。

A. 体验质量建模

   360° 视频在时间上分为多个segment，在空间上分为 N 个tiles。 ABR 算法逐段运行，并从服务器选择要获取的一组tiles，并选择另一组需要在client端生成的tiles。 为了生成tiles，需要从服务器下载所有图块的 ULR representation和 DNN 微模型。 需要注意的是，并非所有图块都需要获取或生成
视口预测：视口预测算法使用 1) 视频数据的离线分析和 2) 用户（在线）头部跟踪轨迹来预测用户视口，算法考虑当前segment播放时间。 文献 [15]、[23]、[32]、[34] 中对此类算法的兴趣越来越大。 他们从本质上分析视频以发现可能吸引观众注意力的场景的显著特征。 这通过头部跟踪（捕获过去的视口）进行增强，以估计用户将来可能会看到的场景部分。 这样的估计通常作为包含 360°场景的所有tiles i 的概率分布 pi 生成。
   我们遵循机器学习方法来预测视口。 该方法是最近工作 [15] 的更精细版本。 我们预测的输入是视频的saliency [13] 和运动 [44] 图（离线提取）与在线头部运动数据相结合。
视频体验质量 (QoE):视频 QoE 的特征在于播放期间实际观看的场景部分的质量。 此质量受播放期间显示的视频分辨率的影响。 它还受到丢失视频数据（例如，丢失片段或图块）的影响，这通常会导致播放器停顿。 PARSEC 中的 QoE 公式遵循视频流文献 [30]、[32]、[46] 中采用的传统方法，但 PARSEC 必须考虑生成的tiles质量与下载的tiles质量。
  我们按行优先顺序从 1 到 N 对段中的各个图块进行编号。 令 ri,D, ri,G 和 ri,M 表示二元决策变量，如果第 i 个切片被（未）下载、（未）生成和（未）丢失，则这些变量被设置为 1（0）。 可以下载不同质量级别的tie，我们用 qi,D 表示。 此处的质量等级 q 是视频比特率 R 的函数，表示播放期间的观看质量。 这可以通过多种方式建模 [27][46] 例如直接使用比特率，即 q® = R 或将其用作可能速率 R 表的索引。我们采用后一种方法（也在 [32] 中使用）和模型质量水平 作为整数 0, . . . , k, 数字越大表示质量越高。 质量 0 表示没有播放或丢失数据。 最后，请注意，对于给定的tile，生成的tile qi,G 的质量是恒定的，但在tile之间可能会有所不同。
  我们将一个segment 的预期播放质量E(Q) 建模为各个tiles的预期质量之和：

  每当丢失tile时，就会损失质量。 我们将这个 tile Miss E(M) 表示为

  由于查看的图块质量的变化，也存在质量损失。 这可能是由于跨不同段和跨同一段的所有图块的质量发生了变化。 我们利用分段中tiles质量的标准偏差 Vs

我们利用不同segment中tile质量 (Q) 值的预期变化：

其中 Qt−1 表示前一个图块的质量。 请注意，Qt-1 是一个已知量（不是期望值），因为可以记录前一段中的实际决策和经验。 因此，整体体验质量 (QoE) 给出

其中 β 和 ξ 代表 QoE 的每个组成部分的不同权重。 我们使用类似于Oboe [12] 的技术自动调整 β 和 ξ。 我们的目标是最大化等式 (5) 中的 QoE，同时确保我们获得可行的解决方案。
约束：以下约束确保解决方案的可行性。 只有tile被下载时，下载质量才能为正，即

此外，每个tile都必须下载、生成或丢失，即，

最后，所有的生成和下载都必须在播放前（Pt 是播放前的时间）完成一段时间 δ。 令 d(qi,D) ​​表示以质量 qi,D 获取tile i 所需的时间。 类似地，设 d(qi,G) 是生成tile i 所需的时间。 那么，这个约束表示为：

它们分别代表网络容量和计算容量约束。

B. 优化 QoE

  我们现在的目标是最大化等式 5 中 ABR 算法所考虑的segment的 QoE，受等式 6-8 中的约束。 虽然它被制定为 ILP，但我们使用快速、贪婪的启发式 (§IV-C) 来解决优化问题。 QoE（方程 5）在一组约束条件下最大化。 等式 6 和 7 中显示的前两个约束确保如果一个图块被下载或生成，它会被分配一个正质量级别。 等式 8 中显示的最后两个约束是容量约束，确保必须在播放之前完成段的下载和生成。 这些约束表明准备tile的时间（来自生成和网络下载）不应晚于播放时间 (Pt)，为各种计算工作保留了增量 (δ) 时间，例如解码下载的tile和 拼接tile以使场景准备好观看。 这些约束需要估计可用的网络带宽和可用的计算能力。 稍后会详细介绍这些内容。
  这种优化服务于 ABR 控制的目的。 它依赖于带宽估计（约束 8）。 虽然可以采用多种机制，但我们使用类似于 MPC [46] 的技术，其中可用带宽是使用过去观察到的吞吐量的调和平均预测器来估计的。 估计的吞吐量用于根据tile的质量水平来估计tile的下载时间。 计算能力估计相对容易，因为客户端设备通常不是共享资源，并且具有明确定义的固定能力。
   正如在 §III 中所观察到的，这些生成的tile的质量可能会有很大差异。 因此，仅根据tile概率选择图块可能会生成质量较差的图块。 为了解决这个问题，我们扩展了 DASH 支持的清单文件的结构。 由于服务器可以离线生成tile，我们计算生成的每个tile的质量并将质量信息编码到清单文件中。 这类似于在清单文件中对tile的不同represetation 进行编码，除了这里每个生成的tile具有固定的质量。 我们在 ABR 算法中使用此质量信息，同时为网络和计算调度tile。
   该算法在一个segment开始播放之前运行，以确定下一个片段将如何下载和生成。 此外，在当前segment的开头下载下一段的 ULR tile和微模型。 由于视口预测能力有限，速率自适应算法应该经常运行（即需要选择small segment）。 因此计算应该很快（几毫秒）。 由于问题是 NP-Hard 问题，因此使用优化求解器并不能保证在如此有限的时间内得到解决方案。 我们在评估中使用快速、贪婪的启发式方法，如下所述

C. Greedy Heuristic

  我们的贪心启发法利用了这样一个事实，即提高 tile 的质量需要额外的网络带宽或计算能力，因此必须根据 tile 的视口概率小心地完成，并确保满足（8）中定义的约束 . 为简洁起见，我们仅在下面提供高级文本描述。 该算法首先将所有tile的质量级别设置为零（表示它们既不会被下载也不会生成）。 然后，该算法将具有最高概率的图块的质量级别提高 1（即下一个可能的质量）。 这可能使用计算或下载，具体取决于当前的质量级别。 在下一步中，我们检查提高同一tile或具有次高概率的tile的质量水平是否会导致更高的 QoE 值。 我们选择提供更高价值的选项。 通过这种方式，我们不断选择更好的选项，直到达到（8）中的约束或 QoE 无法再进一步提高。
  该算法的时间复杂度为 O(N2k)，其中 k 是可用质量的数量（为简洁起见省略了分析）。 在后面报道的实际实验中，对于 200 个tiles和 5 个质量级别，启发式运行不到 2 毫秒。

D. tile生成的重新调度

  如前所述，视口预测通常不够准确。 虽然我们的视口预测在更长的时间范围内优于 Flare [32]，但这仍然不够（3 秒内只有 62% 的准确率）。 PARSEC 能够通过重新计算正在播放的当前片段中未来帧的tile的视口概率来解决这个问题。 这提供了更高的准确度，因为现在时间范围更短了。 新信息用于重新调度tile生成，这大大降低了tile未命中率。

5.EVALUATION

  我们实现了 360° 视频流系统，如图 4 所示，并评估了移动客户端平台上的多种方法。 下面我们介绍测试平台、我们的方法和实验结果

A. Testbed

客户端和服务器实现：客户端视频播放器是基于开源自适应流媒体视频播放器 MP4Client [7] ,用 C 语言实现的。 我们使用 Google Pixel2 作为客户端（Adreno 540 GPU）展示结果。 为了概括结果，我们还评估了另外 5 个设备（图9）。我们使用 Node.JS 使用符合 MPEG-DASH 的 HTTP 自适应流媒体 [36] 在服务器上托管内容。 服务器使用 NodeJS 托管在 Linux 桌面上。
视频分割：我们使用 GPAC 的 MP4Box 工具将视频在空间上分割成segment，然后在时间上分割成tile。 我们使用 kvazaar [6]，一种基于 HEVC 的实现 [38] 来编码视频。 总的来说，准备 DASH 片段的分步过程是 1) 使用 kvazaar 对视频进行编码，2) 使用 MP4Box 在空间上划分视频，3) 将 DASH 格式的视频打包成具有多种representations的tiled segments，以及 4) 生成 清单文件。
离线处理：为了训练 DNN 微模型，我们使用 Python 中的 Keras [4] 和 Tensorflow [10] 以及 Nvidia GTX 1070 GPU。 对于每个视频，我们为片段中的每个图块获取 ULR 图块，并为每个片段获取一个模型。 每个视频（即所有微模型）的训练时间约为 20 分钟。 除了学习 DNN 模型外，视频还通过 DASH 标准 [36] 为传统 ABR 流进行离线处理。 离线处理完成后，DASH 段、微模型和 ULR 切片将存储在服务器中。 从服务器的角度来看，这些额外的模型和 ULR tiles被简单地视为新内容； 它将根据请求流式传输到客户端。 结果是没有服务器端修改，我们可以使用标准的 MPEG-DASH 服务器。
  我们在四种不同的网络条件下评估 PARSEC，并将其与四种最先进的替代方案进行比较。 我们首先描述我们的实验方法

B. 网络设置

通过 WiFi 进行端到端实验：我们在两个不同的位置托管视频服务器：Loc1 距离客户端大约 20 毫秒 RTT，而 Loc2 距离客户端 40 毫秒 RTT。 我们选择这些位置作为 CDN 的代理。 客户端托管在我们的实验室中。 我们使用具有 802.11ac 链接速度的 Aruba WiFi AP。 我们根据不同的流媒体算法将视频从服务器流式传输到客户端。 我们不限制速度。
真实网络轨迹：我们从两个流行来源收集真实网络轨迹——FCC 发布的宽带数据集 [8] 和根特大学的 4G/LTE 网络测量结果 [5]。 我们过滤跟踪以具有 1 Mbps 的最小带宽来启动视频流。 过滤后，FCC 数据集的平均带宽为 8.2 Mbps，标准差为 3.6 Mbps，比利时数据集的平均带宽为 19.3 Mbps，标准差为 6.1 Mbps。
合成轨迹：最后，我们在合成网络条件下进行了一小部分实验，以在较差（例如 1 Mbps）与良好（例如 20 Mbps）网络条件下对 PARSEC 进行压力测试。 我们使用 Mahimahi [28] 来模拟网络条件

C. 实验方法

我们将 PARSEC 与以下替代方案进行比较：
• 仅 VP：仅 VP [15] 使用视口预测来减少获取 360° 视频所需的带宽。 它只取预测特定于视口的tile并遭受频繁的tile未命中。
• Flare：Flare [32] 是最先进的 360° 视频流系统，它将视口预测与 ABR 算法相结合。 Flare 会抢先获取一些非视口图块，以弥补视口预测的低准确度。
• NAS-regular：NAS [45] 设计用于常规视频流并利用超分辨率。 因为 NAS 不是为 360° 视频流而设计的，它不使用视口预测并获取片段中的所有图块。 我们称之为 NAS-regular。
• NAS-360：为了公平比较，我们还试验了一个适用于 360° 视频流的 NAS 版本。 我们将此方案称为 NAS-360。 NAS-360 使用我们的视口预测来仅获取特定于视口的图块。 这实质上意味着 NAS-360 是具有 NAS 的单一模型推理而不是我们的微模型推理的 PARSEC。
  为了公平评估，我们对所有使用视口预测的替代方案使用相同的视口预测算法（在 §IV 中描述）。 我们验证了我们的视口预测技术提供了比 Flare [32] 中描述的准确度高 26% 的中值准确度(1s
window)。
  其他常规视频流技术包括 BOLA [37] 和 Pensieve [27]，与 PARSEC 相比，360°视频流的性能要差得多（因为它们与视口无关）。 我们省略了这些比较.
360° 视频数据集：我们在评估中使用最常用的 360° 视频头部运动数据集 [25]。 该数据集包含总共 500 条轨迹，包含 10 个视频，每个视频有 50 个用户观看。 每个轨迹包含每个帧的用户头部位置（偏航、俯仰和滚动）。 使用原始头部运动数据，我们导出视口和视口特定的图块。 视频通常长约 1 分钟。 在默认情况下，我们将每个视频在时间上分成 1 秒的segment。 每个视频都使用 4K 质量 (3840×1920) 的等矩形投影进行编码和投影。 对于 ABR，我们以 5 种不同的质量级别对视频进行转码——1 Mbps、5 Mbps、10 Mbps、15 Mbps 和 20 Mbps。
性能指标：我们使用三个指标来衡量性能——(i) 质量水平（如 §IV-A 中所定义），(2) 未命中率——由用户头部运动确定的用户视口中不可用的图块比例， (3) QoE，如等式 5 中所定义。我们以标准化形式呈现 QoE 而不是尽可能地最大化 QoE。 在一些使用多个网络轨迹的评估中（例如，图 5），每个段的 QoE 在所有轨迹上取平均值（平均 QoE 或归一化平均 QoE，视情况而定）。
参数选择：评估性能涉及几个参数。 通过实证分析，我们选择以下设计决策。 我们使用 192x192 的tile大小来实现有效的视口适应，同时最小化跨tiles压缩开销。 我们将图块缩小到 24x24，以避免极端的质量损失和大型模型。 我们的目标是至少达到 30dB PSNR，这是一个最小值推断时可感知的质量。 我们试验了 1-3 秒的段持续时间，因为超过 3 秒预测准确度非常低

D. 性能结果

宽带网络轨迹下的性能：图 5(a)-© 显示了四种备选方案在 FCC 发布的真实宽带轨迹下的性能。 与最先进的 360° 流媒体协议 Flare 相比，PARSEC 在平均质量水平和标准化平均 QoE 方面将性能提高了 61% 和 48%。 PARSEC 同时利用客户端的计算和网络资源，而 Flare [32] 仅使用网络资源来获取视频图块。

  PARSEC 在 QoE 方面的表现也比 NAS-360 高出 42%。 回想一下，NAS-360 是 NAS [45] 的一个版本，我们通过视口预测适应了 360° 流传输（这是一个保守的估计，因为我们消除了 NAS-360 的模型下载）。 在 NAS-360 的情况下，较大的模型尺寸导致推理率较差，并且在设备上每秒只能生成几个tile。 NAS-regular 的性能更差，因为它与视口无关（即引入所有图块）并且推理率很低。 请注意， NAS-regular 没有遗漏，因为它获取所有图块，但质量较低。 VP 仅流式传输特定于视口的图块，因此由于视口预测不准确而出现高未命中率，并且通常性能最差
4G/LTE 网络轨迹下的性能：图 5 (d)-(f) 显示了 PARSEC 的性能以及 4G/LTE 比利时网络轨迹的四种替代方案。 在 4G/LTE 网络轨迹下，与最先进的系统 Flare [32] 相比，PARSEC 将性能提高了 30% 和 37% 的平均质量水平和归一化的平均 QoE。
  与 4G/LTE 网络轨迹相比，FCC 的宽带网络在容量方面受到更多限制。 因此，与 4G/LTE 网络相比，PARSEC 在宽带网络上的优势更高。 所有其他方法也有类似的趋势。

WiFi 上的端到端实验：我们比较了四种替代方案的性能，用于高度配置的 WiFi 网络设置，没有限制。 这些是端到端的实验，其中视频托管在两个服务器位置 Loc1 和 Loc2。 图 6a 显示了归一化平均 QoE。 与网络跟踪实验类似，PARSEC 优于四种替代方案。 与 Flare 相比，PARSEC 在 Loc1 和 Loc2 中分别将平均 QoE 提高了 17% 和 28%。 Loc1 更靠近具有较低 RTT 的客户端。 这使得网络性能更好，从而导致整体改进较低。
  我们还研究了带宽利用率。 PARSEC 的标准化带宽使用率分别比 NAS-regular 和 Flare 低 68% 和 43%（图 6b）。 NAS-regular 与视口无关并流式传输所有图块。 如果用户的视口发生变化，Flare 会流式传输一些非视口图块以补偿未命中。 PARSEC 具有最低的带宽使用率，因为它仔细选择要以高分辨率下载哪些图块以及在客户端生成哪些图块。 NAS-360 在 QoE 和带宽使用方面的表现略好于 Flare，因为某些tile将在客户端得到增强。

不同的网络条件：我们还评估了客户端和服务器在同一个 VLAN 中且网络容量较高的理想网络场景下的四种方案。 PARSEC 在 QoE 方面的表现类似于 NAS-regular。 然而，与 NAS-regular 和 Flare 相比，PARSEC 分别需要少 2.3 倍和 1.8 倍的带宽（为简洁起见，此处未显示）。 这是因为，当没有网络限制时，NAS-regular 将从服务器上高质量地获取所有tile。
  PARSEC 专门设计用于在带宽不足时正常工作。 为了对 PARSEC 进行压力测试，我们比较了 PARSEC 和 Flare 在三种合成网络场景下的性能——1 Mbps、10 Mbps 和 20 Mbps 平均吞吐量。 我们只与 Flare 进行比较，因为它是最先进的端到端视口自适应系统。 图 7 显示了这些吞吐率下 PARSEC 与 Flare 的 QoE 比率。 PARSEC 在较差的网络下看到了更多的好处。 在 20 Mbps、10 Mbps 和 1 Mbps 下，PARSEC 的性能分别比 Flare 高 1.3 倍、1.5 倍和 1.8 倍
流式传输更长的视频片段 :我们评估 PARSEC 以确定支持更长的视频片段的好处。 我们使用持续时间为 1s、2s 和 3s 的片段，分别对应于 1s、2s 和 3s 的预测窗口 (pw)。 超过 3 秒，视口预测精度不可接受。 这些实验是在从比利时收集的 4G/LTE 轨迹上进行的。 同样，我们只与 Flare 进行比较，因为它是最先进的视口自适应 360° 视频流系统。 图 8 显示了三个不同分段持续时间的标准化平均 QoE 和网络使用情况。 关键的一点是，PARSEC 可以将 QoE 提高 1.7 倍，同时与 Flare 相比，在 3 秒的分段持续时间内将网络使用率降低 47%。 此外，由于在更长的时间内利用冗余，更长的段具有更好的压缩效率。 QoE 和带宽使用率均大幅提升1s 到 3s 段。 我们发现动态重新调度对 3s 段起着至关重要的作用，因为视口预测准确度很差（小于 65%），这对 Flare 的影响比 PARSEC 更不利。

计算能力的影响：我们通过试验六种不同的设备来评估 PARSEC 在不同计算能力下的性能（图 9）。 我们特别包括高端桌面级 GPU，因为我们预计未来的智能手机将拥有如此强大的 GPU。 Nvidia Titan XP 是使用的性能最高的 GPU，而 Galaxy S7（Adreno 530 GPU）是最弱的。 图 9 显示，随着我们将计算能力从 Galaxy S7 增加到 Titan XP，归一化质量水平和 QoE 分别增加了 31% 和 44%。 90% 的未命中率也降低了 7%。 关键在于 PARSEC 在使用更快的 GPU 时表现更好。
  最后要注意的是，PARSEC 确实有额外的能量开销——在我们的评估中，与其他流媒体方法相比（使用 Snapdragon Profiler [3] 测量）之间变化 12-22%。 由于额外的 GPU 使用，这是意料之中的。 我们预计移动平台低功耗 GPU 技术的进步将解决这个问题。

6.CONCLUSIONS

  我们已经描述了 PARSEC，这是一个智能地结合网络和计算资源以流式传输高质量 360° 视频的系统。 PARSEC 利用超分辨率技术，包括在服务器压缩视频，然后在客户端运行深度学习推理以将视频增强为高分辨率。 由于深度学习模型对于 360° 视频可能很大，因此 PARSEC 在短视频片段上使用微模型来减少模型大小和推理时间。 PARSEC 然后将超分辨率技术与传统视频编码技术智能结合，使系统可以通过结合网络和计算资源来发挥两者的优势。 PARSEC 在各种网络条件下都优于最先进的 360° 视频流系统。

CODE