OMAF4CLOUD：启用标准的360°视频创建服务

本文为媒矿工厂编译的技术文章

原标题：OMAF4CLOUD: STANDARDS-ENABLED 360° VIDEO CREATION AS A SERVICE

原作者：Yu You, Ari Hourunranta, Emre Aksu Nokia Technologies, Finland

翻译整理：施志强

摘要

近些年媒体服务不断的发展把未来指向了全向视频和AR，这也使新服务的处理变得越来越复杂。这篇帖子将介绍OMAF和MPEG，并展示将传统的360°视频转换为OMAF兼容格式后继续通过NBMP的工作流程原型，来演示完整的端到端交互式媒体服务以向未来用户提供身临其境的虚拟现实体验。附上之前的一篇相关帖子的链接。

介绍

Omnidirectional MediA Format (OMAF) 全向媒体格式是由Moving Picture Expert Group (MPEG) 运动图像专家组所打造的360度媒体内容标准。OMAF为全向内容具定义了3个级别的自由度 (3DOF)，例如360°视频，图像，音频和定时文本。并且将与视口无关的360°视频转换为符合OMAF的内容仅需要文件格式和传输协议级别的修改（例如，基于MP4和DASH的分段流）。媒体处理的不断发展使其涉及到更多由不同供应商提供的任务和服务。为了简化此类部署，MPEG还定义了网络中媒体处理实体间的交接。Network-based Meida Processing (NBMP) 基于网络的媒体处理，旨在提高媒体处理效率，更快更便宜的部署可互相操作的媒体处理功能，以及通过利用公共，私有或混合云服务来提供大规模部署的能力（如虚拟现实内容拼接，打包和自适应流式传输）。

基于网络的媒体处理

Multi-Acess Edge Computing （MEC）多访问边缘计算和5G为新服务平台提供了更多的可能。借助灵活的Software Define Networking（SDN）软件定义网络，微服务和无服务架构通过类似容器般的部署，使服务可以轻松快速地部署在云中。同时，媒体处理已经发展到使用高级算法来进行实时媒体转换和内容合成。并且随着云计算的发展，MEC将流量和服务的计算从集中式云移至网络边缘并更靠近客户，从而减少了延迟，并减少了对实时或实时媒体处理的高带宽需求。

视频处理是计算资源密集的过程，基于网络的解决方案在计算资源方面更具可扩展性。碎片化是多媒体服务中用到多个云和网络服务提供商来传输给客户的问题。基于网络的媒体处理（NBMP）该标准已作为ISO / IEC 23090第8部分进行开发，用于解决诸如碎片之类的问题，并提供了在云平台上媒体处理的标准。NBMP格式可摄取和输出针对媒体处理功能的定时元数据和辅助信息，以实现虚拟现实的空间内容拼接，或定制媒体的内容合成。另一功能是NBMP的传递，该传递通过网络中的即时转换来减少传递阶段的网络冗余。这将帮助计算机图形和自然内容结合在一起以至增强Augmented Reality（AR）。

图1显示了NBMP体系结构，其中包含针对特定用例的注释。NBMP定义了标准的Application Programming Interface (API) 和格式，例如功能模板和Workflow Description Document (WDD) 工作流描述文档，以高效地分配处理功能并改善云方案中的操作移植性。控制平面中有一组RESTful API的功能有如工作流管理器，它构建处理工作流并将功能（即任务）链接在一起。工作流管理器根据标准定义的出入口提供实际数据平面的确定性并将数据流量带到任务中。功能可由低级到成熟的编码器（例如VR拼接器和图像放大器）不等。

当然现在还存有其他的工作流或流程图语言。从业务流程（例如BPMN）到特定语言（例如Apache Airflow for Python），再到基础架构级别的虚拟机管理（例如Kubernetes 和OpenStack的Mistral）。NBMP WDD位于BPMN和Airflow之间，并将媒体处理功能的输入和输出端口连接到directed acyclic graph （DAG）有向非循环图中。NBMP工作流代表这功能之间的数据流，而不是功能之间的逻辑依赖性。

我们通过诺基亚贝尔实验室开发的World Wide Stream（WWS）流处理平台来了解NBMP工作流程。它使用适当的设置将NBMP WDD编译为JSON格式的最优化的任务描述。优化的部署涉及到系统级别的问题，例如部署和操作的资源成本，计算资源或数据存储的容量限制，或非功能性服务要求，例如延迟，流质量和可靠性。借助底层的事件代理和多媒体流媒体服务器，工作流管理器可以在运行时将实际的源流动态绑定到任务（功能实例）。为了处理不同类型的流，RabbitMQ事件代理通过Adcanced Message Queuing Protocol (AMQP) 高级消息队列协议传输结构化流。对于不透明的媒体位流，一个媒体服务器用于接受套接字连接的原始YUV流。

图1:参考架构

符合OMAF的视频和叠加组成

MPEG-DASH是基于ISO Base Media File Format（ISOBMFF） 基本媒体文件格的流标准。MPEG-DASH基于媒体轨道，每个封装在随机可访问的ISOBMFF段中。支持自适应比特率的DASH流需要以几种不同比特率来对视频进行编码，因此通常同时使用多个视频编码器。我们的OMAF将与VR相关的元数据添加到ISOBMFF和DASH清单中，从而使播放器能够识别360°视频。

OMAF HEVC“视口相关”的基础提高了视频编码的要求，因为它用不同的质量和分辨率对前景（视口）和背景进行编码。视口自适应操作通过将重点集中在用户正在观看的区域上，减少360°视频所需的带宽。由于用户可以自由转动头部并更改活动视口，因此要求系统必须能够快速做出反应，以把不同区域的视频切换到高质量。

Region Wise Mixed Resolution (RWMR) 区域混合分辨率方案，使用HEVC Motion Constrained Tile Sets (MCTS) 运动约束图块集对视频进行编码。其中，视频图片被分为独立的矩形图块，从而可以将图块用作于子图，并在解码器中灵活地将它们混合。6K等矩形方案使用四种不同的视频分辨率：垂直中心区域的分辨率为6K和3K，极地区域的分辨率为3K和1.5K。图2展示了一张合并的图块网格。极砖或者边缘始终处于较低的分辨率，因此，玩家可以根据一个观看方向来组合如图3所示的砖。

OMAF指定使用提取器磁道来帮助将子图片合并为单个MCTS位流。因此，播放器仅需要遵循提取器轨道的指令，即可从包含MCTS的轨道中获得可解码的比特流。

图2:适用于有效6K方案的图块网格

图3：播放器中的图块合成示例

系统描述

NBMP系统原型建立在名为World Wide Stream (WWS) 的通用流处理平台之上。WWS可以在联机或脱机模式下对分散的源和接收器间提取，处理和传递大量数据跟媒体流。图4显示了OMAF案例映射到当前NBMP体系结构块。绿色块是OMAF特定的组件，是面向用户的界面。用户通过这两个组件与整个系统进行交互，其余部分用户看不见。

图4:系统构建块

用户首先从OMAF Web设计器（前端）开始，然后通过后端的Node.JS Server将传统的360°电影上传和存储。在这阶段之后、，用户可以以直观的方式编辑覆盖的位置和相对的深度。设计人员利用Three.JS库来进行可视化。设计完成后，实际处理将在NBMP系统中进行。Node.JS服务器输出NBMP工作流描述文档（WDD），然后在接收NBMP的结果。此外，由于媒体处理通常需要相对较长的时间来完成，我们安装了User Interface (UI) 用户界面仪表板来接收和监视系统中工作流程的状态。

OMAF工作流程的实现

前端具有网络用户界面来指定视频转码设置（例如ABR比特率和切片方案并添加叠加和视点定义），一旦用户准备好应用设置，Node.JS服务器也就是REST API便会根据用户选择来选要设置的处理功能来创建工作流描述文档（WDD）。它还将用户的输入转换为工作流程以及详细的编解码器，文件格式和/或DASH创建参数。然后，Node.JS服务器将WDD进一步提交给NBMP工作流程管理器，以启动实际的工作流程。Node.JS和NBMP系统可以位于不同的位置，例如云中的节点。

图5显示了OMAF第2版本内容创建的一种典型设置，其还具备有多个覆盖的选项。它具有用于高分辨率图块的3个ABR变体，以及两个在中心和极地区域具有不同设置的3K变体。OMAF Creator 负责处理从完整图片到基于图块的子图片的视频比特流处理，并生成提取器轨道。它还创建DASH / ISOBMFF段，插入特定于OMAF的元数据并创建定时的元数据，例如用于初始观看方向轨迹和叠加。与视频解码和编码相比，由OMAF Creator 负责的操作对资源的需求很少，因此从负载平衡的角度来看，单个Creater是问题。

图5:带有覆盖的OMAD有效6K视口相关DASH生成的典型设置

NBMP WD的信息生成需要输入6K视频和单个或多个叠加源。Node.JS服务器充当NBMP源，以生成或更新NBMP WDD文件（多个工作流），然后在通过REST Workflow API发送到工作流程管理器。在WDD中，Processing Descriptor处理描述符定义了处理功能和代表工作流图的ConnectionMap对象（请参见图6）。所有功能信息都可以从NBMP功能存储库中找到。API也会通过该存储库来检查包含实行的NBMP功能描述。NBMP任务（功能实例）作为容器重新安排运行，并轻松地重新部署到不同的云主机。工作流的状态是根据目前数据存储的状态。如果需要进行较小的更新（例如更改叠加层的位置），只要不故意中断工作流，工作流被设计为允许使用临时缓存来加快处理速度。

图6:部署了一个工作流程图

在工作流程结束时，Node.JS服务器会在这个时候充当NBMP接收器，并在工作流程产生任何输出数据时通知OMAF，例如，最终准备情况的元数据或DASH MPD。该工作流程不是将视频内容传输到NBMP Sink，而是设计为将轻量级元数据生成到Node.JS服务器也就是Sink里。众所周知，这种设计需要额外的共享存储支持，对于低延迟至关重要的实时用例并不是理想的选择。考虑到转码的总成本，我们选择此设计是因为其简单性和可扩展性。

图6中的XZip操作是系统提供的内置功能，用于将两个或多个输入流组合为一个输出。每当其所有输入流都产生并发出至少一个输出信号时（例如图6中的五个输入），该函数就会同步多个输入并发出一个输出。

OMAF Player不需要紧密集成到管道中。他们只需要知道DASH清单的URL就可以开始播放。但是，用有效的内容创建需要预览选项。我们分两步实施了它。首先，Web用户界面可以在覆盖图编辑阶段播放360°视频，从而使用户轻松的看覆盖图的放置位置。这是通过使用Three.JS库实现的。但是，由于当前HTML5视频播放器尚不支持OMAF播放，因此最终内容的预览是通过Android或Windows平台上的Nokia OMAF Player提供的。此外，使播放器的集成模式可以连接到Node.JS服务器并侦听NBMP工作流程中可用的新内容上的指示事件。

总结

我们将传统的360°视频转换为OMAF兼容格式后继续通过NBMP的工作流程原型。在撰写本文时，NBMP作为标准已在开发中。NBMP将尽可能地遵守当前定义的标准，从而允许将许多现有工具和内容重新用于基于网络的媒体处理。此外，引入VR覆盖的OMAF v2标准也在开发中。我们的实施没有充分利用NBMP标准，例如，以下功能：状态跟踪报告，云资源管理要求和具有自动扩展的编排功能。下一步，我们计划进行一些实验，并专注于指标，例如可用性和可伸缩性，可靠性和弹性。