VR 眼镜的出现和快速发展使赛博朋克和未来世界不再遥远。通过手柄与音视频图片的互动，人们在娱乐和健身时可以体验到全面超越现有音视频的身临其境体验。在体验云游戏、大型全景活动互动等应用时，要想保持这种身临其境的身临其境体验，还需要超高清、高帧率的全景视频源、强大的传输带宽和超低头延迟（MTP）。
因为视频源 VR 眼镜独有的 FOV（Field of View，视场角，VR 反映视野广度的重要指标之一，4K 全景视频在 VR 眼镜看起来只相当于 540P，所以 8K 分辨率视频的分发只是超高清画质体验的入门级需求。此外，一些游戏、体育赛事等内容的视频对帧率也有很高的要求 120fps 只有这样，才能有更好的体验；在传输方面，我们应该实现这一点「富媒体」超低延迟传输是一个巨大的挑战，带宽需要实现 150Mbps 以上。
VR 近两年眼镜 VR 一体机技术发展迅速， All-in-one 设计脱离了外部设备的连接束缚，即开即用，受到市场的广泛欢迎，并逐渐被取代 VR 头显之势。然而，便携式的优点必然会影响其在解码、渲染和带宽处理方面的性能 8K@120fps / 150Mbps 任务需要特殊处理。
当前行业使用的一些解决方案在视频质量/帧率/延时/带宽等各方面做了取舍，导致最终用户体验不太理想：要么是无法忍受的图像质量（低画质），或者是低帧率带来的眩晕（低帧率），又或是无法忍受的延时（高延时），以及巨额的带宽成本（最后一公里全景下发）等，如行业所用「直播转码」 「CDN 分发链路」方案一方面延迟较高，不能适用于一些互动场景；另一方面，由于云中的转码，会对图像质量造成一定的损害，也会影响用户的身临其境体验。
利用 RTC 传输这类「富媒体」到 VR 一体机能更好地解决高画质、低延迟的问题，但也面临着一些困难。
利用 RTC 传输这类「富媒体」到 VR 一体机能更好地解决高画质、低延迟的问题，但也面临着一些困难。
1.1 8K 和 120 fps 难以兼得上面提到的，在 VR 场景中，视频内容如云游戏、大型展览、赛事等，「高分辨率」和「高帧率」缺一不可。然而，我们发现，无论如何， GPU 还是 VR 一体机芯片的编解码能力不能兼顾「8K」和「120 fps」性能体验。我们使用了 gpu-z 工具和 Nsight 工具分析了 Nvidia Tesla 硬件的编码能力，分析发现，当视频源达到 8K 分辨率时，单张 Nvidia Tesla 最高只能支持 8K@60fps，而且存在性能波动，单个显卡的性能一般稳定 8K@50fps。
以下是测试数据：从解码能力来看，目前市场主流 VR 一体机(价格1500-2000元)基本选择 高通 XR2 芯片，芯片声称的解码能力是 8K@60fps 或 4k@120fps，实测后发现，8K@60fps 也是上限值，实际上很难稳定 8K@60fps。
以下是测试数据：因此，支持编解码的性能 8K@120fps 最大的瓶颈。
1.2 全解码方案导致带宽性能不足传输 8K@120fps 需要全景视频 150Mbps 目前，带宽 5G 宽带下载网速不能满足这种传输条件，渗透率不高。
以下是2021年三大运营商下行速度中值数据：
数据来源：2021年全国网络速度及质量报告
从合理性的角度来看，VR 由于视角问题，观看端不需要同时解码整个场景的图片内容。全解码方案浪费了大部分代码流带宽占用，导致下行带宽大，它给最后一公里带来了巨大的压力，不利于互联网的分布。1.3 延迟头动容易引起眩晕MTP（Motion To Photons）是 VR 眼镜的另一个重要指标是从头到显示相应图片的时间，MTP 延迟过大容易引起眩晕。目前公认的是，当 MTP 时延低于 20ms 晕动症的发生可以大大减少。
2. 火山引擎 RTC 做了什么
2.1 总体介绍
为解决上述问题，火山引擎 RTC 引入了 FoV 方案是让接收端只接收视角区域内的高清码流，解决编解码性能和带宽不足的问题。此外，我们同时传输高清 tile 码流和低清全景背景码流，避免视角切换引起的黑屏。此外，我们同时传输高清 tile 码流和低清全景背景码流，避免快速头动导致视角切换引起的黑屏。低清背景最终可以通过火山引擎覆盖全球实时音视频网络边缘节点来实现 MTP < 20ms，高清 FoV 流 MTP < 100ms。如图所示，首先，编码端将一路走来 8K 视频分为几个 tile（在 HEVC图像从水平和垂直方向分为几个矩形区域，称为这些矩形区域 tile，每个 tile 可以独立编码解码)，对每一个， tile 单独使用自研编码器编码；同时编码一个 2K 的全景图，它可以在接收端覆盖底部，而不会引入更大的代码率增加，导致解码端性能无法跟上；然后，在媒体服务器侧，上行通过一个 ssrc 同时接收高清 tile 流动和低清背景流，包括下行高清 tile 流量按用户视角过滤转发，下行低清背景流不过滤直接转发；最后，接收端按照 HEVC tile 标准，将所有 tile 将原始大小的编码视频按照图像的位置合并，解码，上屏。
下面详细介绍火山引擎 RTC FoV 实现和优化方案。
2.2 实现和优化编码2.2.1 多 GPU 分布式编码
因为上面提到的单张 Nvidia Tesla 不具备 8K@120fps 的编码能力，所以需要通过多 GPU 并行编码实现。火山引擎 RTC 多用于编码侧 Nvidia Tesla 并行显卡，将 8K 视频被切割成几个 tile，用几个编码器编码，然后通过 RTP 包装并发送到网络。这里需要注意的是不是所有的显卡都能创建多个硬编码器，个人消费级显卡对于编码器的个数是有限制的，Nvidia 官网可查询显卡。
2.2.2 码率控制下行可访问代码率的准确性 VR 一体机的数量很重要，但在测试中，我们发现编码器的编码率控制有时不准确，单纯调整编码器的编码参数并不能解决这个问题。因此，有必要定期监控硬编码器内编码器的实际编码率。监控频率设置为 10s，如果实际编码低于预期编码率，则统一提高所有编码器的编码率，否则将降低粒度 10%。增加码率监控后，可以稳定码率为预设码率。
2.2.3 调整编码器的复杂性默认情况下，编码器的复杂性是在创建编码器时确认的，中间不能动态修改，因此会出现以下问题：
编码器在计算资源过剩时不能充分利用编码器。如果编码器的利用率很低，可以提高编码器的编码复杂性，从而提高图像质量。编码器可能会受到整个系统性能的影响。如果降低系统时钟频率，会影响编码器的性能。如果此时能降低编码器的复杂性，从而保证整个视频流程会提高整体体验。
编码器的复杂性可以通过 preset 划分，不同的 preset 表示不同的复杂性(对于 preset 详细说明可参考 Nvidia 我们的实测数据如下：通过测试数据，我们发现 preset p1 和 p4 两个性能临界，可动态调整 preset 提高编码的复杂性，进而提高编码的画质（preset 动态设置不耗时，不会导致图片卡住)。因此，我们将默认设置当前的设置 preset 调整为 p4，如果 p4 如果性能不能保证实时性，则返回 p1。
2.3 解码的实现与优化2.3.1 按 FoV 视频从视角发送
一些直播场景已经开始使用 FoV 但目前还没有计划 RTC 厂商来按视频从视角发送内容。
2.3 实现和优化解码
2.3.1 按 FoV 视频从视角发送一些直播场景已经开始使用 FoV 但目前还没有计划 RTC 厂商来按视频从视角发送内容。
为什么不用 SVC 或 Simulcast 发视频？SVC 和 Simulcast 视频全画幅只能接收和解码，会造成带宽增加或画质损失。火山发动机 FoV 在方案中，高清视频流根据视角场异步发布和渲染，低清视频流全面发布，不仅可以节省带宽，而且不降低图像质量，而且可以避免因视角快速切换和高清视频传输太晚而看不到图像。2.3.2 投影方法的选择
自古以来，球面与平面之间的图像映射问题就一直困扰着地图测绘员。今天，随着 VR 随着全景视频的发展，的发展。VR 全景视频需要传输，涉及带宽占用和图像质量损坏， 不同的投影方法会对画质和码率产生很大的影响。
引用自：https://leohope.com/2019/07/15/VR-mapping/
我们使用了 EAC 相对于简单直观的投影方法， ERP 投影，EAC 投影比 ERP 投影节省了 25% 的面积，接收端降低约 15% 数据接收更有利于视频编码器的画质优化。
下图两组照片中，上图为 ERP 像素为投影 7680x3840 ；下图为 EAC 像素仅为投影 5760x3840。2.3.3 从姿态信息计算的视角 tile
定义正前方是零点向量，视角边界是 tile 向量，零点向量和 tile 向量夹角小于 X° 范围内的 tile，都在视角范围内 tile。如上图所示，粉色 黄色是全景视频，分为几个 640x640 黄色区域是根据向量夹角计算的视角范围 tile，然后接收端向 RTC 边缘媒体服务器务器请求 tile。2.3.4 合成
接收端按照 HEVC tile 标准，一切 tile 根据图像的位置合并成原始大小的编码视频；同时，将 2K 放大低清流，放大高清流 FoV 流在渲染前粘贴相应的坐标位置。如上图所示，橙色部分为低清流，放大成 8K；绿色部分为高清 FoV 流，原始 8K。
假如头动慢，VR 头部显示器是高清视野范围，因此不会影响实际体验；如果头部运动速度快，则不可避免地会在视野内看到一些低清图像。此时，播放器将根据头部运动范围重新要求高清 FoV 码流，此时会有短时间看到低清图像，等到高清 FoV 范围码流下发后，图片将恢复高清 8K 效果。
2.4 头部延迟优化
2.4.1 头动延时
头动延时 = 最后一公里网络rtt GOP/2 jitter_buffer 解码 上屏2.4.2 视场角预测下图描述了视角预测的过程，即，用户当前 FoV -> 转头 -> 控制信令(携带预测结果) -> RTC 边缘媒体服务器 -> 下发新的 tile -> 更新 FoV 内容。
业内有一些成熟的视角预测方案。当用户头部旋转时，可以根据旋转加速度预测未来旋转的角度位置，甚至可以根据用户的动作预测旋转角度和方向，然后根据预测提取相应的数据，从而达到良好的预测和减少延迟效果。业内有一些成熟的视角预测方案。当用户头部旋转时，可以根据旋转加速度预测未来旋转的角度位置，甚至可以根据用户的动作预测旋转角度和方向，然后根据预测提取相应的数据，从而达到良好的预测和减少延迟效果。{ x}
