通过 5G 网络提供沉浸式 360° 视频 | RTC @scale 2024

5G 和边缘计算正在为沉浸式媒体如 360° 视频等带来新的用户体验。这些内容是实时创建的，同时也使用了上行和下行链路。在本次演讲中，我们展示了使用英特尔 Open WebRTC Toolkit（OWT）和英特尔边缘平台的 360° 沉浸式媒体解决方案。该解决方案由多个摄像头的媒体捕获、远程控制以及通过 5G 网络分发的组成。我们还提供了性能评估，显示了在带宽和延迟方面的收益。

来源：RTC @scale 2024
演讲题目：Delivering Immersive 360 Degree Video Over 5G Networks
主讲人：Gang Shen
视频地址：https://atscaleconference.com/videos/delivering-immersive-360-degree-video-over-5g-networks/
内容整理：李雨航

引言

沉浸式媒体在当今互联网和技术网络上被广泛的使用，例如元宇宙、AR、VR 和云游戏等。而由于带宽和延迟的限制，在公共网络，尤其是 5G 无线网络上传输和广播沉浸式媒体是一个公认的挑战。我将以 360° 视频为例来分析目前的技术栈瓶颈，并展示我们的团队在该方面所做的工作。

为了在网络上成功传输沉浸式媒体，我们需要多个领域的技术，这些技术从上到下大致可分为三层：

媒体处理 对媒体内容进行压缩，将媒体内容组织成可以通过现有网络传输和访问的数据结构。现在已经有了能够压缩沉浸式媒体（例如 360° 视频）的编解码器，如 MPEG-4、ADM 等。
媒体传输 与其它类型的数据一样，今天大多数视频内容通过基于 TCP 或 HTTP 的传输协议来传输。但是 HTTP 和 TCP 的拥塞控制和包重传策略对于沉浸式媒体来说开销过大，因为在沉浸式媒体中并非所有内容都同等重要。
网络基础设施 这是网络传输的最底层。众所周知对于 2D 视频，将 CDN 部署在网络拓扑中的哪个位置对于传输延迟来说是很重要的，而边缘服务器因为其更接近用户，故而可以大大降低交互时延

接下来，我们将从上到下来构建 360° 视频广播的整体解决方案。

背景

媒体处理

360° 视频

360° 视频实际上是 VR 的简化版本，如图 1 所示，用户的视角是从球体的中心向外看，它支持三个自由度，头戴 HMD 的用户可以上下、左右摆动或是左右旋转头部，但不能在虚拟空间中移动。

如图 2 所示，360° 视频的每一帧都被投影到一个 2D 矩形以进行编码。如图 3 所示，由于用户观看的内容仅在视口之内，因此依赖视口的传输方案（viewport-dependent streaming）可以节省很多带宽，为了支持依赖视口的传输，编解码器需要完成：1）Tiling 将完整画面划分为更小的部分（tile），以及 2）Packing 使用高分辨率编码落在视口内的 tile，使用低分辨率编码全景内容。

你可以在 MPEG-Ⅰ OMAF 中找到更多关于 360° 视频的信息。

视口切换的挑战

如图 4 所示，有了编解码器所做的两步处理，就可以根据任何新的视口来快速完成 tile 的编码，但是视口切换带来的还有另外一项挑战，就是在帧间编码时引入的时间上的依赖性。

如图 5 所示，最初视口（深蓝色）落在帧的中心位置，而视口切换发生在第 2 和第 3 个 P 帧之间，此时落在新视口（橙色）内的 tile 在接收端将无法被解码，在这种情况下，我们只能依赖低分辨率背景直到下一个 I 帧到来。

因此，在依赖视口的传输中，我们会评估 MTHQ（Motion-to-High-Quality）延迟，因为一般的 MTP（Motion-to-Photon）延迟已经能够被低分辨率背景所满足。

媒体传输

图 6 展示的是在服务器与客户端之间不断地进行视口信息和视口内容的交换，WebRTC 客户端不断地将视口信息发送给 WebRTC 服务器，服务器根据给定的视口信息将视口内 tile 以高分辨率编码，并将全景背景以低分辨率编码，并将两者打包为一帧发回客户端

网络基础设施

要将整套程序部署在某个网络基础设施上，需要考虑以下因素：1）如果将程序部署在云端（数据中心），单向延迟约为 100 毫秒，那么对 360° 视频来说一次完整的交换就需要 200 毫秒。2）如果部署在 on-prem 网络上，我们确实获得了更好的延迟，但在应用的大规模部署方面会很困难。

为权衡以上两点，我们考虑将应用部署在边缘云上，并且这样做也可以从 5G 的服务质量中受益

方法

系统架构

将以上内容整合到一起，我们提出了这套“端到端的基于 WebRTC 的 8K 360° 视频广播解决方案”，如图 8 所示。

在该方案中，我们将媒体函数分为三类：媒体获取函数、媒体分发函数和媒体控制函数：

媒体获取函数：负责处理多个相机的输入并进行 360° 视频的拼接和编码；
媒体分发函数：负责根据各客户端的反馈进行视口打包和交换；
媒体控制函数：为不同的设备（例如相机和接收设备）提供信令和编排，该函数可部署在公共网络上。

其中的媒体获取与媒体分发将会与 5G UPF（User Plan Function，用户规划函数）配合使用。

DEMO

在下面展示的 Demo 中，我们架设了两台 360° 相机进行全景视频拍摄，采用三台 Android 手机作为接收器。我们将一台 360° 相机放在一个远端实验室内进行拍摄（图 9），服务器机房内为 5G 核心以及我们前面提到的三个媒体函数（图 10），在接收端的三部手机中，右边两部接收第一个相机的拍摄内容，左边一部手机与第二个相机用于端到端时延测试（图 11、12），以及一个 5G 信号发射器用以支持无线通信（图 13）。

结果分析

在以上设备上运行我们的系统，得到了很好的结果，如图 14 所示。其中屏幕到屏幕延迟（glass-to-glass lalency）达到 1.3 秒，而相比之下基于 http 的方案通常需要超过 5 秒的时间。在整个过程中，媒体处理阶段大约花费了 0.9 秒，因此我们可以通过硬件加速来达到更低的延迟。

如图 15 所示，MTHQ 延迟是我们测量的第二类延迟，大约为 200 毫秒，也好于 HLS/DASH 等其它基于 http 的 CDN 方案。通过延迟明细表我们可以看到视频处理阶段的延迟仍然是最大的瓶颈，由 GOP 结构引起的延迟大约占据交互总延迟的 40%，为了减少 MTHQ 延迟，我们已经有了新的解决方案：