空间音频增强和再现

摘要

一种装置，包括用于执行以下操作的部件：获得包括至少一个音频信号的至少一个空间音频信号(300)，其中至少一个空间音频信号定义至少部分地构成媒体内容的音频场景；基于至少一个空间音频信号来渲染音频场景；获得至少一个增强音频信号(302)；将至少一个增强音频信号变换成至少两个音频对象；基于至少两个音频对象来增强音频场景。

说明书

技术领域

本申请涉及用于空间声音增强和再现的装置和方法，但并不排他地涉及用于音频编码器和解码器内空间声音增强和再现的装置和方法。

背景技术

沉浸式音频编解码器正被实现，以支持范围从低比特率操作到透明性的大量操作点。这种编解码器的示例是沉浸式语音和音频服务(IVAS)编解码器，其被设计为适合于在诸如3GPP 4G/5G网络之类的通信网络上使用，包括在诸如例如用于虚拟现实(VR)的沉浸式语音和音频之类的沉浸式服务中使用。该音频编解码器被预期处理语音、音乐和通用音频的编码、解码和渲染。此外还被预期支持基于通道的音频和基于场景的音频输入，包括关于声场和声源的空间信息。编解码器还被预期以低延迟进行操作，以使能会话服务并在各种传输条件下支持高差错鲁棒性。

此外，参数空间音频处理是音频信号处理的一个领域，其中使用一组参数来描述声音的空间方面。例如，在从麦克风阵列进行参数化空间音频捕获时，从麦克风阵列信号估计一组参数是一种典型且有效的选择，该组参数诸如是频带中声音的方向、以及频带中被捕获声音的定向与非定向部分的比率。众所周知，这些参数很好地描述了在麦克风阵列的位置处的被捕获声音的感知空间特性。这些参数可以相应地在空间声音的合成中使用，以用于双耳式耳机、扬声器、或诸如全景环绕声(Ambisonics)之类的其他格式。

沉浸式媒体技术目前正由MPEG进行标准化，被命名为MPEG-I。这些技术包括用于各种虚拟现实(VR)、增强现实(AR)或混合现实(MR)用例的方法。MPEG-I被分为三个阶段：阶段1a、阶段1b和阶段2。这些阶段的特征在于如何考虑3D空间中所谓的自由度。阶段1a和阶段1b考虑3DoF和3DoF+用例，然后阶段2将至少允许显著无限制的6DoF。

增强现实(AR)/虚拟现实(VR)/混合现实(MR)应用的示例是音频(或音频-视觉)环境沉浸，其中实现6自由度(6DoF)内容渲染。

然而，在诸如MPEG-H 3D Audio之类的顶级常规沉浸式编解码器上需要附加的6DoF技术。

发明内容

根据第一方面，提供了一种装置，其包括用于执行以下操作的部件：获得包括至少一个音频信号的至少一个空间音频信号，其中至少一个空间音频信号定义至少部分地构成媒体内容的音频场景；基于至少一个空间音频信号来渲染音频场景；获得至少一个增强音频信号；将至少一个增强音频信号变换成至少两个音频对象；基于至少两个音频对象来增强音频场景。

用于将至少一个增强音频信号变换成至少两个音频对象的部件可以进一步用于生成与至少两个音频对象相关联的至少一个控制准则，其中用于基于至少两个音频对象来增强音频场景的部件可以进一步用于基于与至少两个音频对象相关联的至少一个控制准则来增强音频场景。

用于基于与至少两个音频对象相关联的至少一个控制准则来增强音频场景的部件可以进一步用于以下中的至少一个：定义至少两个音频对象之间允许的最大距离；定义相对于与用户的距离的至少两个音频对象之间允许的最大距离；定义相对于用户的旋转；定义音频对象星座的旋转；定义用户是否被准许位于至少两个音频对象之间；以及定义音频对象星座配置。

所述部件可以进一步用于获得与至少一个音频信号相关联的至少一个增强控制参数，其中用于基于至少两个音频对象来增强音频场景的部件可以进一步用于基于至少两个音频对象和至少一个增强控制参数来增强音频场景。

用于获得包括至少一个音频信号的至少一个空间音频信号的部件可以用于从第一比特流中解码至少一个空间音频信号和至少一个空间参数。

第一比特流可以是MPEG-1音频比特流。

用于获得与至少一个音频信号相关联的至少一个增强控制参数的部件可以进一步用于从第一比特流中解码与至少一个音频信号相关联的至少一个增强控制参数。

用于获得至少一个增强音频信号的部件可以进一步用于从第二比特流中解码至少一个增强音频信号。

第二比特流可以是低延迟路径比特流。

用于获得至少一个增强音频信号的部件可以用于获得以下中的至少一个：至少一个用户语音音频信号；在用户位置处捕获的至少一个环境部分；从一组音频对象中选择的用于增强至少一个空间音频信号的至少两个音频对象。

根据第二方面，提供了一种方法，其包括：获得包括至少一个音频信号的至少一个空间音频信号，其中至少一个空间音频信号定义至少部分地构成媒体内容的音频场景；基于至少一个空间音频信号来渲染音频场景；获得至少一个增强音频信号；将至少一个增强音频信号变换成至少两个音频对象；基于至少两个音频对象来增强音频场景。

将至少一个增强音频信号变换成至少两个音频对象可以进一步包括生成与至少两个音频对象相关联的至少一个控制准则，其中基于至少两个音频对象来增强音频场景可以进一步包括基于与至少两个音频对象相关联的至少一个控制准则来增强音频场景。

基于与至少两个音频对象相关联的至少一个控制准则来增强音频场景可以进一步包括以下中的至少一个：定义至少两个音频对象之间允许的最大距离；定义相对于与用户的距离的至少两个音频对象之间允许的最大距离；定义相对于用户的旋转；定义音频对象星座的旋转；定义用户是否被准许位于至少两个音频对象之间；以及定义音频对象星座配置。

所述方法还可以包括获得与至少一个音频信号相关联的至少一个增强控制参数，其中基于至少两个音频对象来增强音频场景可以进一步包括基于至少两个音频对象和至少一个增强控制参数来增强音频场景。

获得包括至少一个音频信号的至少一个空间音频信号可以进一步包括从第一比特流中解码至少一个空间音频信号和至少一个空间参数。

第一比特流可以是MPEG-I音频比特流。

获得与至少一个音频信号相关联的至少一个增强控制参数可以进一步包括从第一比特流中解码与至少一个音频信号相关联的至少一个增强控制参数。

获得至少一个增强音频信号可以进一步包括从第二比特流中解码至少一个增强音频信号。

第二比特流可以是低延迟路径比特流。

获得至少一个增强音频信号可以进一步包括获得以下中的至少一个：至少一个用户语音音频信号；在用户位置处捕获的至少一个环境部分；从一组音频对象中选择的用于增强至少一个空间音频信号的至少两个音频对象。

根据第三方面，提供了一种装置，其包括：至少一个处理器和包括计算机程序代码的至少一个存储器，该至少一个存储器和计算机程序代码被配置为与至少一个处理器一起使该装置至少：获得包括至少一个音频信号的至少一个空间音频信号，其中至少一个空间音频信号定义至少部分地构成媒体内容的音频场景；基于至少一个空间音频信号来渲染音频场景；获得至少一个增强音频信号；将至少一个增强音频信号变换成至少两个音频对象；基于至少两个音频对象来增强音频场景。

被使得将至少一个增强音频信号变换成至少两个音频对象的装置可以进一步被使得生成与至少两个音频对象相关联的至少一个控制准则，其中被使得基于至少两个音频对象来增强音频场景的装置可以进一步被使得基于与至少两个音频对象相关联的至少一个控制准则来增强音频场景。

被使得基于与至少两个音频对象相关联的至少一个控制准则来增强音频场景的装置可以进一步被使得执行以下中的至少一个：定义至少两个音频对象之间允许的最大距离；定义相对于与用户的距离的至少两个音频对象之间允许的最大距离；定义相对于用户的旋转；定义音频对象星座的旋转；定义用户是否被准许位于至少两个音频对象之间；以及定义音频对象星座配置。

所述装置可以进一步被使得获得与至少一个音频信号相关联的至少一个增强控制参数，其中被使得基于至少两个音频对象来增强音频场景的装置可以进一步被使得基于至少两个音频对象和至少一个增强控制参数来增强音频场景。

被使得获得包括至少一个音频信号的至少一个空间音频信号的装置可以进一步被使得从第一比特流中解码至少一个空间音频信号和至少一个空间参数。

第一比特流可以是MPEG-1音频比特流。

被使得获取与所述至少一个音频信号相关联的至少一个增强控制参数的装置可以进一步被使得从所述第一比特流中解码与所述至少一个音频信号相关联的所述至少一个增强控制参数。

被使得获得至少一个增强音频信号的装置可以进一步被使得从第二比特流中解码至少一个增强音频信号。

第二比特流可以是低延迟路径比特流。

被使得获得至少一个增强音频信号的装置可以进一步被使得获得以下中的至少一个：至少一个用户语音音频信号；在用户位置处捕获的至少一个环境部分；从一组音频对象中选择的用于增强至少一个空间音频信号的至少两个音频对象。

根据第四方面，提供了一种包括指令的计算机程序[或包括程序指令的计算机可读介质]，这些指令用于使装置至少执行以下操作：获得包括至少一个音频信号的至少一个空间音频信号，其中至少一个空间音频信号定义至少部分地构成媒体内容的音频场景；基于至少一个空间音频信号来渲染音频场景；获得至少一个增强音频信号；将至少一个增强音频信号变换成至少两个音频对象；基于至少两个音频对象来增强音频场景。

根据第五方面，提供了一种包括程序指令的非暂时性计算机可读介质，这些程序指令用于使装置至少执行以下操作：获得包括至少一个音频信号的至少一个空间音频信号，其中至少一个空间音频信号定义至少部分地构成媒体内容的音频场景；基于至少一个空间音频信号来渲染音频场景；获得至少一个增强音频信号；将至少一个增强音频信号变换成至少两个音频对象；基于至少两个音频对象来增强音频场景。

根据第六方面，提供了一种装置，其包括：获得电路，被配置为获得包括至少一个音频信号的至少一个空间音频信号，其中至少一个空间音频信号定义至少部分地构成媒体内容的音频场景；渲染电路，被配置为基于至少一个空间音频信号来渲染音频场景；获得电路进一步被配置为获得至少一个增强音频信号；变换电路，被配置为将至少一个增强音频信号变换成至少两个音频对象；以及增强电路，被配置为基于至少两个音频对象来增强音频场景。

根据第七方面，提供了一种包括程序指令的计算机可读介质，这些程序指令用于使装置执行如上所述的方法。

一种装置，包括用于执行如上所述的方法的动作的部件。

一种装置，被配置为执行如上所述的方法的动作。

一种计算机程序，包括用于使计算机执行如上所述的方法的程序指令。

一种在介质上存储的计算机程序产品，可以使装置执行如本文所描述的方法。

一种电子装置，可以包括如本文所描述的装置。

一种芯片组，可以包括如本文所描述的装置。

本申请的实施例旨在解决与现有技术相关联的问题。

附图说明

为了更好地理解本申请，现在将通过示例的方式参考附图，其中：

图1示意性地示出适于实现一些实施例的装置的系统；

图2示出根据一些实施例的如图1中所示的系统的操作的流程图；

图3示意性地示出如图1中所示的适于实现一些实施例的示例性合成处理器装置；

图4示出根据一些实施例的如图3中所示的合成处理器装置的操作的流程图；

图5示出根据一些其他实施例的如图3中所示的合成处理器装置的操作的流程图；

图6示意性地示出根据一些实施例的从参数化表示到替代表示的“完美变换”的效果的示例；

图7示意性地示出根据一些实施例的在示例性增强场景上对6DoF媒体内容的3DoF对象增强的示例；

图8a和图8b示意性地示出根据一些实施例的在示例性增强场景上在没有和具有依赖性的情况下对6DoF媒体内容的3DoF对象增强的示例；

图9a至图9c示意性地示出根据一些实施例的在示例性增强场景中对6DoF媒体内容的增强控制的效果的示例；

图10a至图10d示意性地示出根据一些实施例的在示例性增强场景中用于对6DoF媒体内容的增强控制的用户接口和用例示例；

图11示意性地示出适于实现所示装置的示例性设备。

具体实施方式

下面进一步详细描述用于提供沉浸式媒体内容的空间增强设置和信令的有效控制的合适装置和可能的机制。

根据当前提出的架构，MPEG-1 6DoF音频渲染器能够解码和渲染已编码的MPEG-H3D音频核心编码信号。该渲染器还能够在6DoF场景中渲染低延迟路径通信音频信号，该低延迟路径通信音频信号已经例如通过使用外部解码器而在MPEG-I系统外部被解码，并以合适的格式(例如与MPEG-H 3D Audio能力对应的格式)被提供给渲染器。

当前提出的架构没有提供用于解码或渲染参数化沉浸式音频的能力，这种参数化沉浸式音频已被证明是用于在实现不规则麦克风阵列配置的实际移动设备上进行多麦克风捕获的最佳可用格式。在许多用例中，此类音频输入对于沉浸式音频增强非常有用。

如果渲染器不支持采用原生格式(native format)的沉浸式输入，则需要将低延迟路径音频变换成与6DoF渲染器兼容的格式。这种变换通常会导致质量损失，还可能会损害“低延迟”方面。因此，可以使用外部渲染器来渲染此附加媒体，该附加媒体例如可以与渲染的6DoF内容混合。

当针对渲染器实现公共接口时，可以通过在空间上有意义的方式将诸如沉浸式MPEG-1I 6DoF音频内容和3GPP EVS音频之类的至少两个沉浸式媒体流与附加的空间位置元数据或3GPP IVAS空间音频进行组合。使用公共接口例如可以允许通过另一音频流来增强6DoF音频内容。可以在6DoF场景/环境中某一或多个位置处渲染增强内容。

本文中进一步详细讨论的实施例尝试即使在不支持原生格式的情况下，也以最小的感知质量损失来将3DoF沉浸式低延迟音频流提供给6DoF渲染器。

此外，这些实施例尝试在将音频格式变换成非原生格式之后维持与增强的6DoF渲染中3DoF声音场景或声源有关的依赖性(dependency)。因此，这些实施例尝试允许在被变换的3DoF增强音频的6DoF放置中具有与6DoF原始音频格式所允许的相同自由度，以便充分利用6DoF渲染器的能力和功能(诸如但不限于用户接口(UI)控制，其例如可以允许替换场景中的音频对象)。

因此，本文所讨论的概念涉及至少两个沉浸式音频分量之间的空间依赖性的信令，其中至少两个沉浸式音频分量在经由音频格式变换解码(或通过直接解码)成非原生音频格式而形成。信令可以至少用于维持被增强到6DoF媒体内容上的3DoF音频场景(的至少一部分)的正确声像。在一些实施例中，空间依赖性可以是编码器的输入信号的一部分(基于分析或例如由内容创建工具输入来提供)。在一些其他实施例中，空间依赖性可被导出为编码的一部分。在一些其他实施例中，空间依赖性可被导出为解码的一部分。附加地，在一些实施例中，空间依赖性可被导出为格式变换的一部分。

在一些诸如上述前两种情况的实施例中，在一些实施例中需要此信息被分开发送。

在一些实施例中，执行作为3DoF或6DoF元数据的一部分的空间依赖性元数据的信令。这例如在以下情况下可以是有用的：如果用户A正在消费第一6DoF内容且用户B正在消费第二6DoF内容，并且用户B希望与用户A通信(使用沉浸式音频)。用户B的通信例如可以包括来自其内容场景的音频对象，其可具有空间依赖性，该空间依赖性需要被发送给用户A以进行正确的渲染。

因此，本文所讨论的实施例遵循将参数化(或任何其他)沉浸式音频内容变换成至少两个音频对象(具有可选的其他分量，诸如至少一个一阶Ambisonic(FOA)流，例如用于携带至少一个环境部分)。基于对象的表示提供了例如单独的声源的6DoF放置的自由度。然而，如果在变换中任何重要的依赖性被丢失，则此自由度也可能会破坏声音图像。

因此，根据一些实施例，至少两个音频对象与至少一个音频-对象依赖性元数据相关联，以允许根据沉浸式音频分量之间的依赖性来进行增强控制。在一些实施例中，此依赖性元数据被提供给6DoF音频渲染器，进而，该6DoF音频渲染器例如可以在依赖性元数据所允许的条件下将至少两个音频对象放置在6DoF内容中。这可保持3DoF音频内容的质量尽可能高，同时仍允许大多数实际3DoF增强音频信号在6DoF场景的音频放置中的很大自由度。

在一些实施例中，依赖性元数据可以包括以下控制信息中的至少一个：

ο至少两个音频对象之间允许的最大距离；

ο相对于与用户的距离的至少两个音频对象之间允许的最大距离；

ο相对于用户的旋转；以及

ο音频对象星座的旋转。

此外，在一些实施例中，依赖性元数据还可以包括非常具体的规则，例如：

ο在至少两个音频对象之间获取的用户许可；

ο音频对象星座配置(例如，对象A必须始终在左侧，对象B在中间，对象C在右侧)，这可与控制信息“相对于用户的旋转”和/或“音频对象星座的旋转”相关。

在一些实施例中，可以经由可视用户接口(UI)向用户指示仅音频依赖性。这种UI的一个示例是相关音频对象的可视化之间的视觉“橡皮筋(rubber-band)”效果。

关于图1，示出了用于实现本申请的实施例的示例性装置和系统。系统171被示出为具有内容产生“分析”部分121和内容消费“合成”部分131。“分析”部分121是从接收合适的输入(多通道扬声器、麦克风阵列、Ambisonics)音频信号100到对可被发送或存储104的元数据和传输信号102进行编码的部分。“合成”部分131是从已编码的元数据和传输信号104的解码到音频信号的增强和所生成的信号的呈现(例如，经由耳机107以合适的双耳形式106呈现，耳机107还配备有合适的头部跟踪传感器，这些头部跟踪传感器可以向合成部分信令通知内容消费者用户的位置和/或定向)的部分。

因此，在一些实施例中，系统171和“分析”部分121的输入是音频信号100。这些音频信号可以是合适的输入多通道扬声器音频信号、麦克风阵列音频信号、或Ambisonic音频信号。在一些实施例中，“分析”部分121仅仅是用于获得包括传输音频信号和元数据的合适的数据流的部件或其他手段。

输入音频信号100可以被传递给转换器101。转换器101可被配置为接收输入音频信号，并生成用于发送或存储104的合适的数据流102。数据流102可以包括可被进一步编码的合适的传输信号。

数据流102还可以包括与输入音频信号相关联(并因此与传输信号相关联)的元数据。元数据例如可以包括旨在表征输入音频信号的声场的空间音频参数。在一些实施例中，元数据还可以与传输音频信号一起被编码。转换器101例如可以是计算机(运行被存储在存储器和至少一个处理器上的合适的软件)，或者可替代地是利用例如FPGA或ASIC的专用设备。

此外，在一些实施例中，数据流102包括可被编码为附加元数据的至少一个控制输入。

在合成侧131，所接收或所获取的数据(流)可以被输入到合成处理器105。合成处理器105可被配置为将数据(流)解复用成(已编码的)传输和元数据。进而，合成处理器105可以对任何已编码的流进行解码以便获得传输信号和元数据。

进而，合成处理器105可被配置为接收传输信号和元数据，并基于传输信号和元数据来创建合适的多通道音频信号输出106(其可以是任何合适的输出格式，诸如双耳、多通道扬声器或Ambisonics信号，具体取决于用例)。在一些利用扬声器再现的实施例中，实际物理声场被再现(使用扬声器107)，具有期望的感知特性。在其他实施例中，声场的再现可以被理解为是指通过除了在空间中再现实际物理声场之外的其他方式来再现声场的感知特性。例如，可以使用本文所描述的双耳再现方法在耳机上再现声场的期望感知特性。在另一示例中，声场的感知特性可以被再现为Ambisonic输出信号，并且这些Ambisonic信号可以用Ambisonic解码方法来再现，以提供例如具有期望感知特性的双耳输出。

在一些实施例中，输出设备，例如耳机，可以配备有合适的头部跟踪器，或者更一般地，被配置为向合成处理器105提供位置和/或定向信息的用户位置和/或定向传感器。

此外，在一些实施例中，合成侧被配置为接收音频(增强)源110音频信号112，用于增强所生成的多通道音频信号输出。在这样的实施例中，合成处理器105被配置为接收增强源110音频信号112，并且被配置为采用由控制元数据控制的方式来增强输出信号，如本文中进一步详细描述的。

在一些实施例中，合成处理器105可以是计算机(运行被存储在存储器和至少一个处理器上的合适的软件)，或者可替代地是利用例如FPGA或ASIC的专用设备。

关于图2，示出了图1中所示的概述的示例性流程图。

首先，系统(分析部分)被配置为可选地接收输入音频信号或合适的多通道输入，如图2中由步骤201所示。

进而，系统(分析部分)被配置为生成传输信号通道或传输信号(例如，基于多通道输入音频信号的下混合/选择/波束成形)和与6DoF场景相关的空间元数据，如图2中由步骤203所示。

附加地，系统(分析部分)可选地被配置为生成增强控制信息，如图2中由步骤205所示。在一些实施例中，这可以是基于授权用户的控制信号。

进而，系统被配置为(可选地)对传输信号、空间元数据和控制信息进行编码以用于存储/发送，如图2中由步骤207所示。

此后，系统可以存储/发送传输信号、空间元数据和控制信息，如图2中由步骤209所示。

系统可以获取/接收传输信号、空间元数据和控制信息，如图2中由步骤211所示。

进而，系统被配置为提取传输信号、空间元数据和控制信息，如图2中由步骤213所示。

此外，系统可被配置为获取/接收至少一个增强音频信号(可选地，与至少一个增强音频信号相关联的元数据)，如图2中由步骤221所示。

系统(合成部分)被配置为基于所提取的音频信号和空间元数据、至少一个增强音频信号(和元数据)、以及增强控制信息来合成输出空间音频信号(如先前所讨论的，其可以是任何合适的输出格式，例如双耳、多通道扬声器或Ambisonics信号，具体取决于用例)，如图2中由步骤225所示。

关于图3，示出了根据一些实施例的示例性合成处理器。在一些实施例中，合成处理器包括核心部分，其被配置为接收沉浸式内容流300(在图3中由MPEG-1音频比特流示出)。沉浸式内容流300可以包括传输音频信号、空间元数据和增强控制信息(在一些实施例中，该增强控制信息可被视为另一元数据类型)。合成处理器可以包括核心部分、增强部分以及受控渲染器部分。

核心部分可以包括核心解码器301，其被配置为接收沉浸式内容流400，并输出适于发送到音频渲染器311的合适的音频流304，例如，已解码的传输音频流。

此外，核心部分可以包括核心元数据和增强控制信息(M和ACI)解码器303，其被配置为接收沉浸式内容流300，并输出要被发送到音频渲染器311和增强控制器(Aug.Controller)313的合适的空间元数据和增强控制信息流306。

增强部分可以包括增强(A)解码器305。增强解码器305可被配置为接收包括要被增强到渲染中的音频信号的音频增强流，并将已解码的音频信号308输出到音频渲染器311。增强部分还可以包括元数据解码器，其被配置为从诸如空间元数据310之类的指示增强音频信号的空间定位的期望或优选位置(或者可替代地和附加地，非允许空间定位或增强信号类型)的音频增强输入元数据中解码，与增强音频相关联的空间元数据可以被传递给增强控制器313和音频渲染器311。

受控渲染器部分可以包括增强控制器313。增强控制器可被配置为接收增强控制信息，并基于该信息来控制音频渲染。例如，在一些实施例中，增强控制信息定义了受控区域以及与这些区域中的增强相关联的控制级别或等级(及其行为)。

受控渲染器部分还可以包括音频渲染器311，其被配置为从核心部分接收已解码的沉浸式音频信号和空间元数据，从增强部分接收增强音频信号和增强元数据，并基于音频输入和增强控制器313的输出来生成受控的渲染。在一些实施例中，音频渲染器311包括被配置为根据用户的位置和旋转来渲染6DoF音频内容的任何合适的基线6DoF解码器/渲染器(例如，MPEG-1 6DoF渲染器)。在一些实施例中，被增强的音频内容可以是3DoF/3DoF+内容，并且音频渲染器311包括合适的3DoF/3DoF+内容解码器/渲染器。它可以并行地基于内容消费者用户和任何受控区域的“位置”从增强控制器接收指示或信号。这可以至少部分地用于确定音频增强是否被允许开始。例如，如果当前内容不允许增强但是增强被推送，则传入呼叫可被阻止或6DoF内容渲染被暂停(根据用户设置)。可替代地和附加地，当传入流可用并且系统确定如何渲染它时，增强控制被使用。

关于图4，示出了根据一些实施例的具有受控增强的渲染操作的示例性流程图。在这些实施例中，沉浸式增强音频与6DoF内容并行地被解码。沉浸式增强音频流的音频表示或解码输出例如可能不适合于6DoF渲染器(例如，它可能不被用于6DoF渲染器的标准或技术所支持)。因此，音频被直接解码，或者可替代地在解码之后被变换成兼容表示。例如，在一些实施例中，兼容表示可以包括至少两个音频对象(可选地，环境信号，例如一阶环境信号)。在一些实施例中，为了在3DoF增强音频的基于对象的表示中维持最佳声音场景表示的依赖性部分，至少一个音频-对象依赖性元数据被创建和添加以用于控制增强渲染。

沉浸式内容(空间或6DoF内容)音频和相关联的元数据可以从所接收/获取的媒体文件/流中解码，如图4中由步骤401所示。

在一些实施例中，可以获得增强音频(和相关联的空间元数据)，如图4中由步骤400所示。

在一些实施例中，如图4中由步骤400所示的增强音频(和相关联的空间元数据)的获得可以被划分成以下操作。

对沉浸式内容、增强音频进行解码，如图4中由步骤402所示。

进而，已解码的增强音频被变换成至少两个音频对象(此外，在一些实施例中，附加的环境信号)，如图4中由步骤404所示。

附加地，至少一个音频对象依赖性被添加为元数据以用于增强控制的目的，如图4中由步骤406所示。

用户位置和旋转控制可被配置为进一步获得内容消费者用户位置和旋转以用于6DoF渲染操作，如图4中由步骤403所示。

在已生成基本的6DoF渲染之后，基于至少两个音频对象和音频-对象依赖性元数据对该渲染进行增强，如图4中由步骤405所示。

进而，可以基于内容消费者用户的位置和旋转来将增强的渲染呈现给内容消费者用户，如图4中由步骤407所示。

关于图5，示出了根据一些其他实施例的具有受控增强的渲染操作的另一示例性流程图。与图4中所示的方法的不同之处在于，在该示例中，6DoF增强控制元数据(例如，由MPEG-I 6DoF内容元数据所提供)是可用的。该元数据可对增强音频信号有影响。在一些实施例中，如所示出的，可以基于6DoF增强控制元数据在渲染之前对增强音频进行修改(例如，可以丢弃某些类型的内容流等)。然而，此处的修改也考虑了音频-对象依赖性元数据。换句话说，在一些实施例中，任何破坏依赖性的修改都是不被允许的。

沉浸式内容(空间或6DoF内容)音频和相关联的元数据可以从所接收/获取的媒体文件/流中解码，如图5中由步骤401所示。

在一些实施例中，可以获得增强音频(和相关联的空间元数据)，如图5中由步骤400所示。

在一些实施例中，如图5中由步骤400所示的增强音频(和相关联的空间元数据)的获得可以被划分成以下操作。

对沉浸式内容、增强音频进行解码，如图5中由步骤402所示。

进而，已解码的增强音频被变换成至少两个音频对象(此外，在一些实施例中，附加的环境信号)，如图5中由步骤404所示。

附加地，至少一个音频对象依赖性被添加为元数据以用于增强控制的目的，如图5中由步骤406所示。

作为获得增强音频和元数据操作的一部分，在已获得至少两个音频对象(此外，在一些实施例中，附加的环境信号)和音频对象依赖性之后，可以(例如，从沉浸式内容文件/流中)获得(6DoF)增强控制信息(元数据)，如图5中由步骤508所示。

在一些实施例中，基于音频对象依赖性和所获得的增强控制信息来对所获得的至少两个音频对象(此外，在一些实施例中，附加的环境信号)进行修改，如图5中由步骤510所示。

用户位置和旋转控制可被配置为进一步获得内容消费者用户位置和旋转以用于6DoF渲染操作，如图5中由步骤403所示。

在已生成基本的6DoF渲染之后，基于至少两个音频对象和音频-对象依赖性元数据(基于所获得的增强控制信息和音频对象依赖性而进一步被修改)来对该渲染进行增强，如图5中由步骤511所示。

进而，可以基于内容消费者用户的位置和旋转来将增强的渲染呈现给内容消费者用户，如图5中由步骤513所示。

如上述方法所示，可以基于音频场或声音的任何“定向”分量变换成音频对象和音频场的非定向分量变换成合适的“环境”信号(诸如FOA或基于通道的音频信号)的分离，将任意3DoF音频流(例如，来自3GPP IVAS编解码器的参数化表示)变换成另一表示。

这在图6中示出。例如，图6的左侧601示出了包括具有定向分量605和非定向分量603的音频场的示例性参数化3DoF内容。

图6还示出了同一3DoF内容的被变换的对象和FOA版本611。FOA613是原始音频场的非定向分量603的感知变换，而对象615和617是原始音频场的定向分量605的感知变换。如果这种变换接近完美，则这将通常允许例如以良好的感知质量在6DoF场景中进行完全自由度的音频对象放置。这在附图的右侧被示出，此时对象615和617移动分开且分别被示出为对象625和627，并且FOA 613被移除。

在采用实际信号的系统中，可以改进对象的分离。例如，两个相对彼此靠近的声源将可能会在空间分析(空间参数)中产生一些泄漏，并因此，每个基于空间分析而生成的对象包括与正被变换的声源相关联的能量、以及与另一声源相关联的音频能量的至少一部分。当至少两个音频对象从参数化表示被分离时，它们之间可出现进一步的泄漏。因此，如果完全自由度的放置被应用，并且用户例如可以在两个音频对象之间行走，则在第二音频对象的方向上可存在第一音频源的一些“幻觉”声音(主要是第二音频源)，在第一音频对象的方向可存在一些第二音频源的“幻觉”声音(主要是第一音频源)。本文所描述的实施例尝试通过使用本文所描述的限制控制来减少用户的困惑并产生更好的用户体验。

在一些实施例中，音频-对象依赖性元数据可以描述属于6DoF内容的至少两个音频对象之间的依赖性。例如，社交虚拟现实(VR)应用可以允许用户的6DoF环境的通信和/或增强、以及对第二用户正在消费的第二不同的6DoF内容的体验。这例如可以是用户A和B消费两个单独的6DoF内容(如前所述)以及他们之间的通信/增强。

在这样的用例中，第二用户可以选择该用户正在体验的内容的一部分(例如，与至少一个音频对象有关)，以与第二用户的语音输入一起发送给第一用户。在这种情况下，音频-对象依赖性可以描述对应于用户的语音的音频对象与作为场景的一部分的至少一个音频对象之间的依赖性。可替代地，依赖性可以是属于所述场景的至少两个音频对象之间的依赖性。例如，依赖性可以是这样的：如果用户B希望将音频对象(例如，音频对象J)发送给用户A，则另一音频对象(例如，音频对象K)在空间上被用音频对象J标记(换句话说，定义了该音频对象与另一音频对象之间的空间依赖性)。由于第一用户的内容是不同的内容，因此需要此类依赖性信息。因此，例如，第一用户的渲染应用没有其他必需的信息来维持与增强的对象及其在第一用户的6DoF环境中的渲染相关的一致用户体验。

然而，应理解，当两个用户同时消费相同的6DoF内容时，服务或应用可不需要与音频-对象依赖性相关的附加信令。这是因为在默认情况下，对于参加社交VR体验的两个用户而言，内容(诸如音频对象)和整体环境理解(诸如场景图或其他场景描述)是相同的。

图7示出了用户体验6DoF媒体内容以及与6DoF内容一起被渲染的各种类型的3DoF增强(诸如图6中所示)的图示。因此，例如，图7示出了6DoF媒体内容700中的用户705，其中用户在环境内相对于音频源703而定位并且看到虚拟对象701。

附加地，用户被示出为位于6DoF媒体内容中的左下方图像上，其中该6DoF媒体内容通过由定向分量715和非定向分量711所表示的示例性参数化3DoF内容来增强。

用户被示出为位于6DoF媒体内容的中下方图像上，其中该6DoF媒体内容通过同一3DoF内容的被变换的对象725、727和FOA 729版本来增强。

用户被示出为位于右下方图像上，其中对象725和727移动分开，且分别被示出为对象735和737，并且FOA部分被移除(或未使用)。

图8a和图8b还示出了根据一些实施例的当用户在增强音频对象附近时且当用户体验6DoF内容时如何实现没有依赖性(图8a)和具有依赖性(图8b)的两个3DoF增强音频对象的说明性示例。

因此，图8a示出了环境800，其中存在增强6DoF环境的增强的3DoF音频对象，但是没有与3DoF增强对象相关联的依赖性。6DoF环境包括位于用户801周围的音频对象(例如较浅阴影圆圈804)和视觉对象(例如较深阴影圆圈802)。在此环境内放置了(没有依赖性的)3DoF音频对象。在诸如图8a中所示的一些情况下，用户可以将他们自己定位在对象803与对象805之间，这可以使用户体验到如上文所描述的效果。然而，如果根据各种实施例的依赖性元数据允许用户在对象之间移动(即，没有针对音频对象而信令通知的对应的限制)，则位于在对象之间的感知被允许。

图8b进一步示出了环境810，其中存在增强6DoF环境的增强的3DoF音频对象，但是具有与3DoF增强音频对象相关联的依赖性。6DoF环境以与图8a相同的方式包括音频对象和视觉对象，但是在此环境内放置了(具有依赖性的)3DoF音频对象。该依赖性例如可以是如下所述的依赖性：阻止用户位于音频对象813与音频对象815之间，并且例如重新定位或放置一个或另一个音频对象813，以使得即使用户尝试将他们自己定位在对象之间也无法实现此目的。

在一些情况下，就其不考虑用户位置(除了方向和距离渲染之外)的意义上而言，3DoF增强本质上可以是“永久的”或“固定的”。例如，用户可能够行走通过增强的音频，使得3DoF音频在6DoF内容中被放置的位置不会基于用户移动而改变。在其他情况下，增强的音频可以至少以某些方式对用户移动做出反应或支持其他交互。

图9a、图9b和图9c示出了可如何至少基于到参考位置的用户距离来渲染靠近3DoF增强音频(其包括具有至少一个依赖性参数元数据的两个音频对象)的用户。

图9a和图9c反映了旋转951的开始和结束。图9a示出了6DoF视觉(深圆圈)对象和音频(浅圆圈)对象以及位于第一位置的用户801。3DoF音频对象903和905还可以与可“迫使”3DoF音频对象彼此靠近的依赖性参数或准则(元数据)相关联。

如由旋转951的结束所示，图9c示出了其中音频对象对923和925根据用户位置来旋转，以使得音频对象如同在原始3DoF音频内容中一样面向用户。

图9b和图9c反映了相对距离修改953的开始和结束，其中当用户例如超出一定阈值距离时，至少两个音频对象913和915可以被允许在彼此的相对距离处进行渲染。然而，当用户靠近931(具有依赖性信息的)至少两个音频对象中的至少一个音频对象时，至少两个音频对象之间的距离减小。

在一些实施例中，基于用户距离的6DoF媒体内容渲染中3DoF增强音频的音频对象的空间位置修改可以使用任何合适的方法来实现。因此，与依赖性元数据相关的至少一个方面可以被插入作为至少两个音频对象中的至少一个音频对象的音频交互元数据。这可以包括基于有效距离或类似距离的参数定义。

在一些实施例中，音频-对象依赖性信息可以是3DoF内容比特流(或单独的元数据流)的一部分。因此，与3DoF内容一起发送或作为3DoF内容的一部分发送的依赖性信息可以在图4a和图4b中的步骤“解码沉浸式增强音频”期间解码，因此，在3DoF内容格式变换处理期间不需要进行单独的分析。

在一些实施例中，UI可以允许由终端用户对将音频对象放置到6DoF场景中进行放置控制。UI可以指示至少两个音频对象之间的依赖性，以使用户知道至少第一音频对象的放置控制可如何影响至少第二音频对象的放置和/或定向，或者可替代地和附加地，以使用户知道可如何单独地禁止至少第一音频对象的放置控制，以及至少两个音频对象需要一起或作为一个单元进行控制。

这种UI的一个示例是音频对象的可视化之间的视觉rubber-band效果。这在图10a、图10b、图10c和图10d中被示出。

例如，图10a示出了用于正在消费6DoF媒体内容(诸如MPEG-1VR内容)以及视觉对象(被示出为树)和音频对象1003和1005的第一用户的用户接口。在该示例中，由于第二用户(John)向第一用户发出3GPP IVAS呼叫，因此该用户接收到增强请求1001。

图10b示出了接受呼叫的效果(例如，与增强请求1001进行交互)，其中从John的IVAS MASA参数化声音场景音频流而变换的3DoF音频对象1011和1013被放置到6DoF渲染中。

图10c示出了与用户接口的进一步交互，其中用户对放置不满意，并且希望通过与对象1011和1013进行交互1025、1027以将它们进一步分开放置并放置在位置1021和1023处来拓宽立体图像。

然而，在该示例中，音频格式变换过程检测到在两个音频对象之间存在声音-场景依赖性。它插入了与音频对象相关联的依赖性控制参数或准则(作为元数据)。基于依赖性控制参数，第一用户的6DoF渲染器检测到对用户尝试将对象放置在位置1021和1023处的限制，并“拒绝(bounce)”或以其他方式将音频对象1031和1033的视觉表示放置到针对两个音频对象而被允许的最宽的可能设置。在一些实施例中，最宽的可能设置可以是基于与第一用户的相对距离。以这种方式，音频呈现保持在高感知质量水平。

关于图11，示出了可以用作分析或合成设备的示例性电子设备。该设备可以是任何合适的电子设备或装置。例如，在一些实施例中，设备1900是移动设备、用户设备、平板计算机、计算机、音频播放装置等。

在一些实施例中，设备1900包括至少一个处理器或中央处理单元1907。处理器1907可以被配置为执行诸如本文所描述的方法的各种程序代码。

在一些实施例中，设备1900包括存储器1911。在一些实施例中，至少一个处理器1907被耦合到存储器1911。存储器1911可以是任何合适的存储部件。在一些实施例中，存储器1911包括用于存储可在处理器1907上实现的程序代码的程序代码部分。此外，在一些实施例中，存储器1911还可以包括用于存储数据(例如，根据本文所描述的实施例的已被处理或将要处理的数据)的存储数据部分。无论何时只要需要，处理器1907就可经由存储器-处理器耦合来获取存储在程序代码部分中的实现程序代码和存储在存储数据部分中的数据。

在一些实施例中，设备1900包括用户接口1905。在一些实施例中，用户接口1905可被耦合到处理器1907。在一些实施例中，处理器1907可以控制用户接口1905的操作并从用户接口1905接收输入。在一些实施例中，用户接口1905可使得用户能够例如经由键盘将命令输入到设备1900。在一些实施例中，用户接口1905可使得用户能够从设备1900获得信息。例如，用户接口1905可以包括被配置为将信息从设备1900显示给用户的显示器。在一些实施例中，用户接口1905可以包括触摸屏或触摸界面，其能够使得信息被输入到设备1900并且还向设备1900的用户显示信息。

在一些实施例中，设备1900包括输入/输出端口1909。在一些实施例中，输入/输出端口1909包括收发机。在这种实施例中，收发机可被耦合到处理器1907并且被配置为使得能够例如经由无线通信网络与其他装置或电子设备进行通信。在一些实施例中，收发机或任何合适的收发机或发射机和/或接收机部件可被配置为经由有线或有线耦合与其他电子设备或装置通信。

收发机可以通过任何合适的已知通信协议与其他装置通信。例如，在一些实施例中，收发机或收发机部件可以使用合适的通用移动电信系统(UMTS)协议、诸如例如IEEE802.X的无线局域网(WLAN)协议、诸如蓝牙的合适的短距离射频通信协议、或者红外数据通信路径(IRDA)。

收发机输入/输出端口1909可被配置为接收扬声器信号，并且在一些实施例中通过使用执行合适的代码的处理器1907来确定如本文所描述的参数。此外，设备可生成合适的传输信号和参数输出以发送到合成设备。

在一些实施例中，设备1900可以被用作合成设备的至少一部分。这样，输入/输出端口1909可被配置为接收传输信号，并且在一些实施例中接收如本文所描述的在捕获设备或处理设备处确定的参数，以及通过使用执行合适的代码的处理器1907来生成合适的音频信号格式输出。输入/输出端口1909可被耦合到任何合适的音频输出，例如被耦合到多通道扬声器系统和/或耳机或类似物。

通常，本发明的各种实施例可以采用硬件或专用电路、软件、逻辑或其任何组合来实现。例如，一些方面可以采用硬件实现，而其他方面可以采用可由控制器、微处理器或其他计算设备执行的固件或软件实现，但是本发明不限于此。虽然本发明的各个方面可被示出并描述为框图、流程图或使用一些其他图示表示来示出或描述，但是应当充分理解，本文所描述的这些框、装置、系统、技术或方法可以作为非限制性的示例采用硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其他计算设备、或其一些组合来实现。

本发明的实施例可由计算机软件、或由硬件、或由软件和硬件的组合来实现，计算机软件是移动设备的数据处理器可执行的，诸如在处理器实体中。此外，在此方面，应当注意附图中的逻辑流程的任何框都可表示程序步骤、或互连的逻辑电路、块和功能、或程序步骤和逻辑电路、块和功能的组合。软件可存储在物理介质上，诸如存储器芯片、或在处理器内实现的存储器块、诸如硬盘或软盘的磁介质、以及诸如DVD及其数据变体、CD的光学介质。

存储器可以是适合于本地技术环境的任何类型，并且可使用任何合适的数据存储技术来实现，诸如基于半导体的存储器设备、磁存储器设备和系统、光存储器设备和系统、固定存储器、以及可移动存储器。数据处理器可以是适合于本地技术环境的任何类型，并且作为非限制性示例可包括通用计算机、专用计算机、微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、门级电路、以及基于多核处理器架构的处理器中的一个或多个。

本发明的实施例可在诸如集成电路模块的各种组件中实践。集成电路的设计基本上是高度自动化的过程。复杂且功能强大的软件工具可用于将逻辑级设计转换成准备在半导体衬底上蚀刻和形成的半导体电路设计。

程序，诸如由加利福尼亚州山景城的Synopsys公司和加利福尼亚州圣何塞的Cadence Design公司所提供的那些程序，可以使用完善的设计规则以及预先存储的设计模块库在半导体芯片上自动布线导体和定位元件。一旦完成了对半导体电路的设计，就可以将采用标准化电子格式(例如，Opus、GDSII等)的设计结果传送到半导体制造设备或“fab”以进行制造。

前面的描述已经通过示例性和非限制性示例提供了对本发明的示例性实施例的完整且信息丰富的描述。然而，当结合附图和所附权利要求进行阅读时，鉴于前面的描述，各种修改和调整对于相关领域技术人员而言将变得显而易见。然而，对本发明的教导的所有这些和类似的修改仍将落入所附权利要求中限定的本发明的范围内。