IBC2023 | 使用客户端和网络数据的 360° 视图优化虚拟现实体验

用户1324186

发布于 2024-03-07 18:04:29

1120

发布于 2024-03-07 18:04:29

来源：IBC2023 题目：OPTIMIZING THE VIRTUAL REALITY EXPERIENCE USING A 360o VIEW OF CLIENT AND NETWORK DATA 作者：S. Mishra, E. Widner1, R. Hadar, B. Stevenson 原文链接： https://www.ibc.org/technical-papers/ibc2023-tech-papers-optimizing-the-virtual-reality-experience-using-a-360-view-of-client-and-network-data/10275.article 内容整理：李雨航虚拟现实（VR）和扩展现实（XR）正在推动优质娱乐和体育内容的深度沉浸式体验。大多数情况下，数据直接流式传输到头戴式设备，要求底层网络提供至少 25Mbps、50Mbps 的恒定吞吐量以支持 UHD 4K、UHD 8K。然而，如今的网络已经拥塞且高度不稳定，无法满足这些更苛刻的视频要求。尽管当今的网络在有线和移动 5G 网络上都存在容量过剩，但交付路径上的可用容量可能无法在用户之间公平共享，并且还会随着时间的推移而发生巨大变化，从而阻碍平稳、高吞吐量的交付。

引言

虚拟现实和混合现实开始推动包括体育内容在内的优质娱乐的深度沉浸式体验。这些新格式通过将丰富的 360° 和 VR 内容直接流式传输到头戴式设备，从而使人获得身临其境的体验，解锁了人们消费内容的更多方式。

新冠疫情也在其中起到了推动作用，因为体育和娱乐开始从一种现实中的社交活动逐渐转移至虚拟世界。而联盟和场馆开始尝试以更身临其境的方式吸引观众，无论是在家中还是在现场。尽管方法和技术在过去几年中一直在发展，但现在仍然未满足观众期望更多的参与、互动的愿望。

VR 面临的挑战

这种变化凸显了网络运营商面临的一个重要挑战。网络中的可用容量，尤其是最后一公里内的可用容量，在用户之间没有公平地共享，并且可能会随着时间的推移而发生巨大变化，因此对用户体验和高比特率内容的交付产生了巨大影响。

即使有了足够的容量，仅凭这一点也并不能解决丢包和延迟问题。而即使是“传统的”基于HTTP的视频点播，也经常受到相同的缓冲、视频启动时间慢和分辨率低的问题，原因是网络上的数据传输路径不足。对于VR/XR等低延迟应用来说，这些问题更加严重，因为这些应用所需的关键运动到光子（motion-to-photon）时间受到丢包、延迟和抖动的严重影响，因此对消费者体验的损害更大。

本文认为，解决路径拥塞、丢包/延迟和吞吐量抖动问题需要

1）增强对 VR/XR 内容交付行为的可见性，尤其是在最后一公里网络中
2）根据 VR/XR 的具体要求以及与不同用户相关的当前网络条件定制拥塞控制。

动机

流媒体视频技术联盟、沉浸式视频工作组的成员在疫情期间参与了多个 VR 和 MR 部署，发现将 VR 内容交付扩展到家家户户是很困难的。

不管是固定接入网络还是固定无线接入网络上的消费者，即使使用过剩的带宽（在某些情况下接近 1 Gb /s），他们仍然会遇到慢启动、停滞和重缓冲问题，即使有播放器提供的深度客户端分析，这些问题也极难诊断。原因就是交付VR内容所需的大量比特率，这些比特率对最后一公里网络中的额外丢包、拥塞和延迟产生很大影响。

沉浸式视频工作组看到了通过完成概念验证（Proof of Concept，POC）来帮助解决这些问题的机会，该验证将识别边缘缓存和用户设备之间的视频管道中的潜在瓶颈，交付内容包括一组经验测试数据、对这些数据的分析以及一组最佳实践和建议，以供正在考虑推出 VR 服务的内容所有者和网络运营商使用。

随着 POC 的进展，人们很快发现，虽然 NPAW（Nice People at Work）播放器插件提供了丰富的数据来量化每个用户的体验质量（QoE），例如平均码率、重缓冲率、开始时间等，但需要额外的数据来确定这些指标受到负面影响的原因，而这些数据需要从网络收集。

本研究提出了一种通过实时网络分析来增强客户端播放器分析的新方法。不仅可以及时识别与用户体验相关的特定问题，还可以将这些问题与插入滞后或抖动的特定网络条件相关联。我们还提出了解决这些问题的机制，方法是为 VR/XR 服务和网络定制拥塞控制逻辑。

概念验证

方法

沉浸式视频工作组定义了整体概念验证方法，就是将 NPAW 播放器插件收集的 HTTP 会话的数据，与 CompiraCloud 监控产品收集的网络数据混合在一起。Compira 产品提供最后一公里网络的视图，并以一秒的粒度收集与 TCP 连接上的往返时间、吞吐量、丢包等相关的信息。

表1 POC 中捕获的客户端和网络端 KPI 示例

如表 1 所示，POC 的目标是收集一个聚合数据集，其中各部分的总和能够确定用户会话受到负面影响的实例的根本原因。数据速率的下降或重新缓冲配给的增加可以与网络条件的实时变化直接相关，从而更深入地了解在提供 VR 体验时面临的问题。

实现

图1 POC 架构

具体实施和数据收集非常简单，网络数据是从部署在 Verizon 网络中的边缘缓存中收集的，并上传到在公共云中运行的 CompiraCloud 实例。同样，NPAW（Youbora 客户端）被嵌入到 VO 播放器（Viaccess-Orca）中，VO 播放器被集成到 Meta 的 Oculus Quest 2 头戴设备上运行，以收集客户端分析，然后上传到相应的 NPAW 云。然后，在后端合并两个数据集，以生成与给定时间的网络条件相比的整体用户体验的 360° 视图。

图2 网络端数据收集实例

部署包括部署 CompiraEdge，它由轻量级代理（Thin Agent，TA）和拥塞控制（CC）机制组成。CC 和 TA 模块都安装在边缘节点上。TA 负责从 CC 元素收集与性能相关的统计信息并将其转发给 CompiraCloud。

概念验证 – 第 1 阶段测试（校准）

第一步需要在 Verizon 网络中安装 CompiraEdge （CE）。运行了一组初始测试，以验证 CE 是否正常工作，以及是否从网络获取了相关数据。这是使用 UHD 4K VOD 内容完成的。

为确保 CE 按预期执行，将收集的数据与从设备客户端获取的指标进行比较。一个关键的考虑因素是，指标是在设备上的 HTTP/会话级别获取的，而 CE 结果是在 TCP/连接级别测量的。正如预期的那样，每种方法的基础指标都是不同的，但是，在客户端上测量的比特率和响应时间可以与来自 CE 的吞吐量和平均 RTT 相关联，以验证测试环境。这是在正式的第一阶段分析之前进行的基本端到端健全性测试。

表2 POC 第 1 阶段数据校准

CE 在流会话期间的 180 秒窗口开始对收集的数据进行进一步分析，以便为所有后续测试用例建立基线，这产生了一些有趣的结果。

假设网络本身具有低拥塞和 RTT 条件，但很明显，一些数据包表现出较高的往返时间，导致整体平均吞吐量为 8.1 毫秒。

每个会话的最初几秒钟都表现出积极的网络利用率，因为客户端试图填充播放器缓冲区。吞吐量达到 261Mbps 的峰值，同时在视频的前 20 秒下载约 600Mb 的数据。即使使用单个流会话，网络也会变得拥塞，导致丢包高达 2.2%。在此初始突发之后，每 4-5 秒请求一次分段，需要 144Mbps，这减轻了该会话的大部分丢包。

根据这些发现，可以确定，即使在最佳网络上超过 300Mbps 的单个流会话也会导致拥塞，主要是因为初始播放器缓冲区被填满，从而导致丢包和往返时间增加。这为在最佳网络场景中测试VR内容提供了一组初始假设。

概念验证 - 第 2 阶段测试（具有 UHD 4K/8K SBR 和 ABR 内容）

表3 POC 第 2 阶段测试集

第 2 阶段涉及从 VR 内容中收集详细的指标。测试了 4K 和 8K 单比特率和自适应比特率，并使用 CE 从网络和使用客户端分析从播放器收集和比较数据，结果如表 3 所示。

表 3 展示了测试类型，包括客户端直接从缓存（DtoN）播放 4K 和自适应比特率（ABR）和单比特率（SBR）的内容。

结果总体上符合预期，并且与第一阶段获得的基线结果一致。在 CE 和客户端上测量时，平均吞吐量相似，并且在会话期间没有发生拒绝，尽管也发生了一些丢包，主要是针对 SBR 内容流，但数据确实显示了一些异常情况，因此需要更深入地研究遥测数据。

空闲时间百分比反映了发送一个片段所需的时间百分比，在 4K 的情况下，一个片段的传输时间为 ~33%（62%-66% 空闲），而对于 8K 片段，每隔一段发送一次（46%-48% 空闲）。这表示缓存发送 8K 片段需要 1 秒以上。另一个意外的结果是 ABR 的平均 RTT 更高，但总体而言，在某些数据包传输上存在某些最大 RTT 峰值，超过 100 毫秒。