编译/VR陀螺

Mike Swanson是一名技术专家，曾在微软工作了12年，离职后花费5年时间便携独立iOS应用，后来从2016年初开始，在西雅图的一家沉浸式视频初创公司（名为 Pixvana）持续工作了4年。如今苹果Vision Pro推出后重新激发了人们对视频格式的研究兴趣，为此Mike Swanson分享了他在沉浸式视频领域的经验以及对MV-HEVC自制视频在苹果Vision Pro的播放测试情况。

以下为VR陀螺基于Mike Swanson博客原文编译整理（第一人称视角），略有修改：

苹果发布Vision Pro之后，为用户提供了录制和播放空间（和沉浸式）视频的功能。Apple TV应用包含一系列制作精美的视频，让观众有机会与Alicia Keys一起坐在演播室、参观世界上最大的犀牛保护区，也许最令人惊叹的是跟随Faith Dickey在挪威上空3000英尺并穿越峡湾。这些视频以约180度的环绕式内容将观众包围，提供非常强烈的临场感。

图源：苹果

毫不夸张地说，如果处理得足够好，沉浸式视频会让您感觉自己被传送到了一个新地点。在传统的2D平面视频中您可能只是“看到”过某个地方，但通过沉浸式视频，则会有“去过那里”的身临其境感。希望您有机会尝试体验Vision Pro的沉浸式视频。

MLS杯季后赛（图源：苹果）

就苹果在该领域的背景来看，苹果早在2020年就收购了沉浸式视频领域极少数初创公司之一：NextVR。虽然我们（Pixvana）专注于预先录制、点播内容和工具，但NextVR专注于体育和音乐等现场活动的捕捉和流媒体传输。看起来苹果正计划通过MLS杯季后赛等活动延续NextVR的发展。

 关于空间视频和沉浸式视频的概念 

首先，让我们来了解一些术语。虽然我还没有看到任何苹果的官方定义，但根据我读到的内容，当苹果谈论空间视频（spatial video）时，他们指的是矩形的传统3D视频。空间视频能与视频一起存储额外的深度数据（对于字幕放置非常有用），但在大多数情况下，空间视频是同时包含左眼和右眼视图的视频。iPhone 15 Pro和Vision Pro可以录制这些视频，每个视频都使用各自的相机配置。

当苹果谈论沉浸式视频（immersive video）时，他们似乎指的是呈现观看者周围的非矩形视频；这实际上是描述体验的一个非常好的术语。此类视频通常由两个（或更多）传感器捕获，通常使用广角/鱼眼镜头。他们捕获的球形空间通常使用所谓的“等距柱状投影”映射到矩形视频帧（想想地球地图......也是一个扭曲以适应矩形的球形物体）。 苹果自己的沉浸式视频使用鱼眼投影进行映射，覆盖大约180度的视场角。

这里要提到另一个重要的术语，特别是在谈论立体视频时，会提到视频分辨率。对于传统的2D平面格式，会经常看到“4K视频”的说法。对于熟悉这个术语的人来说，4K通常意味着分辨率为3840×2160，宽高比为16:9。8K通常意味着7680×4320, 宽高比为16:9。请注意，“#K”数字仅来自水平分辨率(-ish)。

当谈到立体视频时，用于存储左眼和右眼视图的方法很重要。在传统的并排或上下排列的格式中，左眼和右眼图像都会被打包到一个视频帧中。所以，会遇到这样的问题：如果说4K并排排列的立体视频，是指帧的总宽度，那这意味着每只眼睛真的是“2K”吗？或者说单眼都是4K宽，这意味着实际的画面是8K宽？除非有人具体说明，否则很容易得出错误的结论。

图源：苹果

除此之外，苹果沉浸式视频被描述为“180度8K录制”。因为MV-HEVC格式不会将左右眼视图并排存储在单个图像中，所以视频工具报告的帧大小实际上是单眼的分辨率。那么，按苹果的意思，单眼都是8K宽吗?

不过，如果您在播放Apple Immersive视频时监控网络流量，您可以很容易地确定每个视频的最高质量版本，在1:1的宽高比下单眼的分辨率为4320x4320。乍一看，像是单眼4K，但请注意，视频帧的宽高比并不是16:9，而是以1:1的正方形帧呈现。

将一些不同的帧大小和布局进行比较（按比例）：

图源：Mike Swanson

还需要补充的是，苹果的沉浸式视频以每秒90帧的HDR10格式呈现，最高比特率约为50Mbps。这些帧以鱼眼投影格式存储。

苹果决定使用HEVC编解码器的多视图扩展，称为“MV-HEVC”（MultiView-HEVC）。这种格式使用高效HEVC编解码器对多个视图（每只眼睛一个视图）进行编码。早期版本的多视图技术已用于编码3D蓝光光盘。尽管MV-HEVC是多年前定义的，但它面临的一大挑战是，该格式几乎没有与其兼容的工具（包括ffmpeg软件）。

幸运的是，苹果在AVFoundation中提供了对MV-HEVC编码和解码的支持。ffmpeg、Adobe Premiere、DaVinci Resolve、Final Cut Pro等工具很可能后续会添加支持，但苹果确实提供了实用的解决方案。

 研究苹果空间视频和沉浸式视频的必要性 

我最初收到Vision Pro时，我尝试用Vision Pro播放我们旧版的Pixvana镜头画面。因此，我编写了一个便利的工具来拍摄视频，并使用MV-HEVC对其进行编码。由于缺乏详细的文档，这使得这比预期的更加困难。

当我尝试在Vision Pro文件和照片应用程序中播放正确编码的沉浸式（等距柱状投影）视频时，它们以标准直线空间视频形式播放。是的，它们具有3D深度，但它们显示在虚拟屏幕上，而不是像沉浸式视频那样环绕在我周围。在与沉浸式视频社区中的其他人交谈后，我们得出的结论是，苹果目前没有提供内置途径来播放用户创建的沉浸式视频。这一点令人惊讶。

为了解决这个限制问题，我构建了一个简单的MV-HEVC视频播放器来观看我制作的视频。当我终于在Vision Pro中看到它们时，效果非常好！社区中的其他人也在向我发送越来越大的视频文件。虽然我们还没有确定硬件和软件的确切限制，但我们确实一直在突破设备处理能力的极限，这期间学习到了很多知识。

 探究Vision Pro的播放能力极限 

作为权宜之计，我发布了编码工具的免费命令行macOS版本，我将其称为“Spatial”。下载页面和文档中有更多内容，但它可以采用平面、并排或上下排列的视频（或两个单独的视频文件）并将它们编码到单个MV-HEVC文件中，同时设置适当的元数据值用于播放。它还可以执行反向处理并从MV-HEVC源文件导出相同的平面视频文件。最后，它还有一些元数据检查和编辑命令。这期间我一直在收集用户反馈、修复错误和添加新功能。

图源：Mike Swanson

为了解决播放问题，我在GitHub上发布了一个空间视频播放器项目，该项目演示了如何读取新的空间元数据、生成正确的投影几何图形以及以立体声或单声道播放。我希望能为任何尝试制作视频播放应用程序的开发者和创作者带来帮助。更多文档信息分析可参考文末原文链接。

与空间和沉浸式视频相关的元数据部分结构（图源：Mike Swanson）

以下是Vision Pro和iPhone 15 Pro的元数据值（供参考）：

苹果Vision Pro

• 相机基线：63.76mm
• 水平视野：71.59度
• 水平视差调整：+0.0293
• 投影: 矩形

iPhone 15 Pro

• 相机基线：19.24mm
• 水平视野：63.4度
• 水平视差调整：+0.02
• 投影: 矩形

我每天都能收到很多用户发来的消息和文件，他们正尝试找出Vision Pro的播放能力极限，感兴趣的用户可以从苹果的4320×4320单眼90fps内容开始播放，然后继续升级。我个人已经实现播放高达每眼12K (11520×5760) 360度立体内容（尽管帧速率较低）。这夸张的数据吞吐量，说明了Vision Pro硬件能力的强大。

我的Vision Pro在尝试播放一些超大视频时曾多次崩溃和重置，显然还有一些问题需要解决。

在编码方面，对如此大的帧进行编码对引擎来说是个挑战。视频编码的工作原理是比较不同时间的帧，并存储像素之间的移动和差异，以节省带宽。为此，视频编码器不仅要在内存中保留多个帧，还要对它们进行比较。由于帧的大小很容易达到100MB或更大，因此硬件需要拥有大量内存。即使是我的M1 Ultra Mac Studio，在编码上述12K内容时也会变得非常吃力。

 苹果空间和沉浸式视频的编码 

苹果的空间和沉浸式视频使用MV-HEVC进行编码。虽然这种格式和扩展早在多年前就被定义为标准，但就我所知MV-HEVC并未被获得大范围实际使用。因此，支持这种格式的编码器非常少。截至目前，我所知道的编码器有以下几种：

• spatial：我自己开发的命令行工具，用于在苹果Silicon Mac上对MV-HEVC进行编码
• Spatialify：iPhone/iPad应用程序
• SpatialGen：在线编码解决方案
• QooCam EGO 空间视频和照片转换工具--专为Kandao相机用户设计，4月23日官方已推出Kandao XR (Vision Pro版)
• Dolby/Hybrik：专业在线编码
• Ateme TITAN：专业编码
• SpatialMediaKit：适用于Mac的开源GitHub项目
• MV-HEVC 参考软件：主要用于一致性测试的复杂参考软件

与我自己的空间工具一样，这些编码器中的许多都依赖于添加到苹果AVFoundation框架中的MV-HEVC支持，因此它们的使用方式会有些类似。

图源：苹果WWDC23

 MV-HEVC中Layer的引入 

如前所述，MV-HEVC是HEVC的一个扩展，该扩展的多视角特性旨在将同一内容的多个视角编码到一个比特流中。其中一个用途可能是在单个码流中传输一个事件（如足球比赛）的多个摄像机角度，或许允许用户在它们之间切换。另一种用途可能是编码左眼和右眼视图，以便立体播放（3D）。

为了传输多个视图，MV-HEVC为每个视图分配了不同的“Layers”（层）ID。在普通HEVC数据流中，只有一个所谓的主层，其ID为0，即“LayerID 0”。对于Apple的空间和沉浸式MV-HEVC内容来说，第二层通常ID为 1也会被编码，它代表同一内容的第二视角。请注意，虽然LayerID 0通常代表左眼视图，但这并不是固定的。

这种方案的一个好处是，用户可以在标准2D播放器上播放MV-HEVC内容，它会播放主要的第0层内容，而不会播放其他内容。但是，在支持MV-HEVC的播放器上播放时，每个分层视图都能呈现给对应的眼睛。所以我的空间工具允许用户选择将哪只眼睛的视图存储在纯2D播放器的主0层。有时（如在iPhone 15 Pro上），某一个摄像头的视图可能会比另一个摄像头的视图更好看。

所有视频编码器都会利用这样一点，即前一个视频帧看起来非常像后一个的视频帧。大部分带宽节省都取决于这一事实。这就是所谓的时间压缩（随时间而变化）或视图间压缩（在此意义上的视图只是另一个图像帧）。压缩视频中的大量数据也是由一帧引用另一帧（或多帧）的部分数据和运动矢量组成的，运动矢量描述了图像块移动的方向和距离。

现在，当我们在MV-HEVC编码视频中引入第2层（另一只眼睛的视角）时，会发生什么呢？除了一组标记为第1层的新帧外，这些第1层帧还可以参考第0层的帧。由于立体帧非常相似，毕竟两个捕捉画面通常相距65毫米或更少，因此存储第1层数据时效率非常高： “看起来与第0层几乎完全相同，只是略有改动......”而在第2层中带宽节省50%或更多是有可能的。

该图显示了一组以MV-HEVC编码的帧，箭头表示引用图像数据的流向。请注意，第0层不依赖于第1层中的任何内容，因此这一层可在标准2D HEVC视频播放器上播放。而第1层则依赖来自第0层和其他相邻第1层帧的数据。

图源：Fraunhofer

 苹果或采用不同的MV-HEVC工具对视频进行编码 

我对Vision Pro和iPhone 15 Pro录制的MV-HEVC输出非常熟悉，可以肯定这些输出是使用AVFoundation编码的。前文提到的其他一些工具的输出也使用了AVFoundation。然而，苹果用于其身临其境内容的数据流似乎是由其他东西编码的。或至少是一个全新的AVFoundation未来迭代版本？目前还不能定论。

通过监控网络，我已经了解到苹果的沉浸式内容是以10位HDR、4320×4320单眼分辨率、每秒90帧的速度编码的。他们的最佳流媒体版本约为50Mbps，帧格式为苹果鱼眼投影。之后将对此格式作进一步推理和分析。

那么，为什么我怀疑他们使用不同的MV-HEVC工具对视频进行编码呢？首先，我希望看到FourCC数据格式的编解码器类型是hvc1（如当前的苹果文档中所述），但在某些情况下，我还看到了qhvc编解码器类型。我从未见过这种HEVC编解码器类型，而且据我所知，AVFoundation目前使用hvc1标记所有MV-HEVC内容，如果有了解qhvc的人欢迎联系我。

回到正题，正如我在上一部分中解释的，MV-HEVC编码文件的第2层通过引用第0层中几乎相同的帧数据，有望实现约50%或更高的比特率节省效果。 但是，当我比较由Vision Pro、iPhone 15 Pro和当前版本的AVFoundation（包括我的空间工具）编码的文件时，两个层的大小几乎完全相同。另一方面，苹果的沉浸式内容显然使用了更先进的编码器，第二层只有第一层的45%左右。

下面的图表显示了三段不同的MV-HEVC视频，每段视频都显示了第0层（蓝色）和第1层（绿色）的帧数。每个条形图的高度代表该帧有效载荷的大小。由于每段视频的内容不同，该图表仅用于说明层与层之间有效载荷的差异。

图源：Mike Swanson

正如我们所知，对于成熟的编码器来说，我们希望绿条明显小于蓝条。对于Vision Pro和空间工具编码（两者都使用当前版本的AVFoundation）来说，条形图通常相似，在某些情况下，绿色条形图甚至高于蓝色条形图。仔细观察对比Apple Immersive数据，绿色的第1层帧有效载荷总是较小。

 现有编解码工具仍不够成熟 

这意味着使用现有的基于AVFoundation的工具，苹果优化后的50Mbps数据流可能需要接近70Mbps才能达到类似的质量。我的猜测是，AVFoundation中的MV-HEVC编码器本质上是对两个独立的HEVC流进行编码，然后将它们 “拼接 ”在一起（通过更新层ID和帧间引用），几乎就像它们彼此完全独立一样。这就解释了两个层之间显著的尺寸相似性，而作为一个初始版本，这似乎是一个合理的工程简化。这也符合苹果的说法，即iPhone 15 Pro的一分钟空间视频内容约为130MB，而一分钟普通视频为65MB，正好是一半。

图源：苹果

另一种可能是，在Vision Pro或iPhone 15 Pro中捕捉两个实时摄像机输入时，对层间引用进行编码的计算成本太高。这很有道理，但我希望非实时信号源能产生更高效的比特流。

目前还没有现成的工具能在更深的层次上处理MV-HEVC（即使是参考解码器也有问题）。我开始修改一些现有工具（甚至编写了自己的工具），但在做了大量工作后，我仍然没有找到答案。为了进一步提高压缩效率，我尝试将AVFoundation的多路编码添加到我的空间工具中。遗憾的是，目前的MV-HEVC编码器似乎不支持多路编码，即使支持也无法正常运作……

 写在最后 

自年初以来，我一直在深入研究MV-HEVC。我仍然认为这是一种非常适合沉浸式媒体的格式，但很明显，目前的编码器（至少是我遇到过的）还处于起步阶段。由于HEVC的多视角扩展在过去从未真正使用过，因此HEVC编码器在不支持多视角的情况下发展到成熟阶段。现在需要重新审视这些代码库，以添加对多输入流的支持、引入附加层以及速率控制等功能。

我们正处于一个过渡时期，现有的媒体编码工具需要更高的比特率，对比特流的控制能力也更弱。我们可以在Vision Pro的 “文件”和“照片”应用中对直角媒体进行编码播放，但苹果并没有为这些更具沉浸感的格式提供原生播放器支持。幸运的是，苹果的HLS工具集已经更新，可以处理空间和沉浸式媒体。

参考链接：

对苹果空间视频的理解（原文链接）——https://blog.mikeswanson.com/spatial-video/

对苹果空间视频编码的理解（原文链接）——https://blog.mikeswanson.com/encoding-spatial-video/

关于视频分辨率——https://typito.com/blog/video-resolutions/

关于视频宽高比——https://www.dacast.com/blog/video-aspect-ratio/

关于高效视频编码的多视图和3D扩展概述——https://ieeexplore.ieee.org/document/7258339

关于数字视频技术——https://github.com/leandromoreira/digital_video_introduction