用于具有相关联的音频内容的对象的空间音频信号处理的制作方法

背景技术：

基于分组的通信系统允许设备的用户(例如，个人计算机)使用分组协议(例如，因特网协议(ip))通过计算机网络进行通信。基于分组的通信系统可以用于各种类型的通信事件。可以建立的通信事件包括语音通话、视频通话、即时消息传送、语音邮件、文件传输和其他。这些系统对用户是有益的，因为它们通常比固定线路或移动网络具有显著降较低的成本。远距离通信的情况可能尤其如此。要使用基于分组的系统，用户在其设备上安装并执行客户端软件。客户端软件提供基于分组的连接以及其他功能，如注册和认证。

通信系统允许设备的用户通过诸如因特网的计算机网络进行通信。可以建立的通信事件包括语音通话、视频通话、即时消息传送、语音邮件、文件传输和其他。利用视频通话，呼叫者可以观看视频图像。

技术实现要素：

提供本发明内容以便以简化的形式来引入在下面的具体实施方式中进一步描述的概念的选择。本发明内容不是要识别所要求保护的主题的关键特征或主要特征，也不是要用于限定所要求保护的主题的范围。所要求保护的主题也不限于解决所提到的缺点中的任何或所有缺点的实现方式。

本公开的实施例涉及用于具有相关联的音频数据内容的对象的空间音频信号处理。例如，共享场景中的具有相关联的音频数据内容的对象例如是在协作混合现实应用中被生成的。在协作混合现实应用中，参与者可以使对象在共享场景中可视化、将对象放置在共享场景中以及与共享场景中的对象进行交互。该共享场景通常表示参与者之一的周围空间，例如，场景可以包括来自于参与者之一的视点的视频图像。对象或虚拟对象可以“被放置”在场景中并且可以具有可以被参与者“看到”并且与参与者进行交互的视觉表示。此外，对象可以具有相关联的内容。例如，对象可以具有诸如音频、图像、视频或文本内容之类的相关联的内容。例如，参与者可以将视频播放器对象放置于共享场景中，并与其进行交互以开始针对所有要观看的参与者播放视频。然后，另一参与者可以与视频播放器对象进行交互以控制重播或改变视频播放器对象在场景中的位置。类似地，对象可以是接触式图像或是可以被显示给场景的参与者的类似物。该对象还可以与音频数据相关联。以这种方式，“音频”电话通话可以位于该场景内。类似地，视频会议会话参与者在场景中可以由具有来自参与者的相关联的视频和音频数据的对象来表示。

发明人已经认识到，用户可能不总会在视觉上感知场景内的这些对象的位置，并因此可能“丢失”对象相对于用户的位置/方向的位置。

根据本公开的第一方面，提供了一种用于生成场景的用户设备，该用户设备包括：对象确定器，其被配置为确定场景的对象，该对象与至少一个音频信号相关联；相对位置/方向确定器，其被配置为确定用户设备的用户与该对象之间的相对位置/方向；音频位置处理器，其被配置为基于相对位置/方向对至少一个音频信号进行空间音频信号处理以生成至少两个信道音频信号。

根据本公开的第二方面，提供了一种在用户设备处实现的用于生成场景的方法，该方法包括：确定该场景的对象，该对象与至少一个音频信号相关联；确定用户设备的用户与该对象之间的相对位置/方向；以及基于相对位置/方向对至少一个音频信号进行空间音频信号处理以生成至少两个信道音频信号。

根据本公开的第三方面，提供了一种计算机程序产品，该计算机程序产品被包含在非暂时性计算机可读介质上，并被配置为当在用户设备的处理器上执行以用于生成场景时实施以下操作：确定该场景的对象，该对象与至少一个音频信号相关联；确定用户设备的用户与该对象之间的相对位置/方向；以及基于相对位置/方向对至少一个音频信号进行空间音频信号处理以生成至少两个信道音频信号。

附图说明

为了更好地理解本公开内容并且示出如何可以实施本公开，现在将通过举例的方式参考以下附图，其中：

图1示出了通信系统的示意图；

图2示出了用户设备的示意图；

图3示出了作为可穿戴式头戴式耳机的用户设备的示意图；

图4a和图4b示出了用于组合的视频和表面再现(sr)数据的示例发射机和接收机流水线的示意图；

图5示出了用于具有相关联的音频数据内容的对象的空间音频信号处理的示例架构的示意图；

图6示出了用于具有相关联的音频数据内容的对象的空间音频信号处理的初始化过程的流程图；

图7示出了用于具有相关联的音频数据内容的对象的空间音频信号处理的示例过程的流程图；以及

图8a和图8b示出了用于在具有相关联的音频数据内容的对象的空间音频信号处理与音频源的常规音频表示之间进行切换的示例过程的流程图。

具体实施方式

仅通过示例来描述本公开的实施例。

图1示出了通信系统100，其包括与用户终端或设备102相关联的第一用户104(用户a)，以及与第二用户终端或设备108相关联的第二用户110(用户b)。用户设备102和108可以通过通信网络106在通信系统100中进行通信，从而允许用户104和110通过通信网络106彼此通信。通信网络106可以是具有在第一用户设备102和第二用户设备108之间提供通信信道的能力的任何适合的网络。例如，通信网络106可以是因特网或另一类型的网络，诸如高数据速率蜂窝或移动网络，例如，第三代(“3g”)移动网络。

注意，在可替代的实施例中，用户设备可以经由图1中未示出的附加中间网络连接到通信网络106。例如，如果用户设备102是移动设备，则它可以经由蜂窝或移动网络(图1中未示出)连接到通信网络106，所述蜂窝或移动网络例如gsm、umts、4g等网络。

用户设备102和104可以是任何适合的设备，并且可以例如是移动电话、个人数字助理(“pda”)、个人计算机(“pc”)(包括，例如，windows^tm、macos^tm和linux^tmpc)、平板计算机、游戏设备、可穿戴设备或能够连接到通信网络106的其他嵌入式设备。可穿戴设备可以包括可穿戴式头戴式耳机。

可以理解的是，用户设备中的一个或多个可以由单个设备提供。用户设备中的一个或多个可以由协作以提供用户设备或终端的两个或更多个设备提供。

用户设备102被布置为从用户a104接收信息以及向用户a104输出信息。

用户设备102执行由与通信系统100相关联的软件提供商提供的通信客户端应用112。通信客户端应用112是在用户设备102中的本地处理器上执行的软件程序。通信客户端应用112在用户设备102处执行所需的处理，以便用户设备102通过通信系统100发送和接收数据。在用户设备102处执行的通信客户端应用112可以被认证以通过数字证书的呈现在通信系统上进行通信(例如，以证明用户104是通信系统的真实订户，这在wo2005/009019中更详细地描述)。

第二用户设备108可以与用户设备102相同或不同。第二用户设备108在本地处理器上执行与在用户终端102上执行的通信客户端应用112相对应的通信客户端应用114。在第二用户设备108上的通信客户端应用114执行允许用户b110通过网络106进行通信所需的处理，其中，执行该处理的方式与在用户设备102上的通信客户端应用112执行允许用户a104通过网络106进行通信所需的处理的方式相同。用户设备102和用户设备108是通信系统中的端点。为了清楚，图1仅示出了两个用户(104和110)以及两个用户设备(102和108)，但是在通信系统100中可以包括更多的用户和用户设备，并且如本领域已知的，在通信系统100中可以包括更多的用户和用户设备，并且更多的用户和用户设备可以使用在相应的用户设备上执行的相应的通信客户端来通过通信系统100进行通信。

图2示出了在其上执行通信客户端应用以通过通信系统100进行通信的用户设备102的示意图。用户设备102包括中央处理单元(“cpu”)202，该cpu被连接到诸如屏幕或触摸屏之类的显示器204、诸如用户界面206的输入设备(例如，小键盘)、摄像机208和触摸屏204。

在一些实施例中，用户接口206可以是小键盘、键盘、鼠标、定向设备、触摸板或类似物。然而，用户接口206可以是任何适合的用户接口输入设备，例如，姿势或运动控制用户输入、头部跟踪或眼部跟踪用户输入。此外，在一些实施例中，用户界面206可以是被配置为确定用户到显示器204的接近度的“触碰”或“接近”检测输入。

在下面描述的实施例中，摄像机208可以是集成在用户设备102或经由有线或无线连接耦合到用户设备的常规网络摄像机。可替代地，摄像机208可以是诸如飞行时间或结构化光摄像机的深度感知摄像机。此外，摄像机208可以包括多个图像捕获元件。图像捕获元件可以位于不同的位置或者用不同的点或视图所指向，使得来自图像捕获元件的每个中的图像可以被处理或组合。例如，可以比较图像捕获元件图像，以便基于视差错误来确定距图像的深度或物距。此外，在一些示例中，图像可以被组合以产生具有比来自单个图像捕获元件图像可能更大的分辨率或更大的视角的图像。

可以将输出音频设备210(例如，扬声器、多个扬声器、头戴式耳机、耳塞)和输入音频设备212(例如，麦克风或多个麦克风)连接到cpu202。如图2所示，显示器204、用户接口206、摄像机208、输出音频设备210以及输入音频设备212可以被集成到用户设备102。在可替代的用户设备中，显示器204、用户接口206、摄像机208、输出音频设备210以及输入音频设备212中的一个或多个可以不被集成到用户设备102中并且可以经由相应的接口连接到cpu202。这种接口的一个示例是usb接口。

cpu202连接到网络接口224(例如，调制解调器)，以用于与通信网络106进行通信。网络接口224可以集成到用户设备102中，如图2所示。在可替代的用户设备中，网络接口224未被集成到用户设备102中。用户设备102还包括如本领域已知的用于存储数据的存储器226。该存储器226可以是诸如rom的永久存储器。可替代地，存储器226可以是诸如ram的暂时性存储器。

用户设备102安装有通信客户端应用112，其中通信客户端应用112存储在存储器226中并且被布置用于在cpu202上执行。图2还示出了在cpu202上执行的操作系统(“os”)214。在os214之上运行的是用于上述通信客户端应用112的软件栈216。软件栈示出了i/o层218、客户端引擎层220和客户端用户界面层(“ui”)222。每层负责特定功能。因为每层通常与两个其他层进行通信，所以它们被认为是被布置成栈的，如图2所示。操作系统214管理计算机的硬件资源并且处理经由网络接口224向通信网络106发送的和从通信网络106发送的数据。i/o层218包括音频和/或视频编解码器，其接收输入的编码的流并对它们进行解码，以便适当地输出到扬声器210和/或显示器204，并且其从麦克风212和/或摄像机208接收未编码的音频和/或视频数据，并且对该数据进行编码以作为流发送到通信系统100的其他最终用户设备。客户端引擎层220处理如上所述的voip系统的连接管理功能，例如，通过基于服务器或p2p(对等)地址查找和认证来建立通话或其他连接。客户端引擎也可以负责本文中未讨论的其他次要功能。客户端引擎220也与客户端用户界面层222进行通信。客户端引擎220可以被布置为控制客户端用户界面层222以经由显示在显示器204上的通信客户端应用112的用户界面向用户设备102的用户呈现信息，并且经由用户界面从用户设备102的用户接收信息。

也在os214之上运行的是另外的应用230。下面参考另外的应用230和作为单独的应用的通信客户端应用112来描述实施例，然而可以将以下更加详细描述的另外的应用230的功能并入到通信客户端应用112中。

在图3所示的一个实施例中，用户设备102是头戴式耳机或头戴式用户设备的形式。头戴式用户设备包括框架302，该框架302具有想要适合于穿戴者的鼻梁上的中央部分304以及想要适合于用户的耳朵上的左右支撑延伸部306、308。虽然支撑延伸部306、308基本上被示出为是直的，但是它们可以以弯曲的部分终止，以常规眼镜的方式更舒适地适合于耳朵上。

框架302支持标记为310l和310r的左光学组件和右光学组件，该光学组件可以是例如由玻璃或聚合物形成的波导。

中央部分304可以容纳cpu303、存储器328和网络接口324，如图2所述。此外，框架302可容纳微型显示器形式的光引擎和形式为凸透镜和准直透镜的成像光学器件。在一些实施例中，光引擎可以包括另外的处理器，或者采用cpu303来生成用于微型显示器的图像。微型显示器可以是任何类型的图像源的光，例如液晶显示器(lcd)、背光lcd、led矩阵阵列(无论是有组织的还是无组织的)和任何其他适合的显示器。显示器可以由激活显示器的各个像素的电路来驱动以生成图像。来自每个显示器的基本准直的光通过在每个组件上提供的相应的耦合接入区312l、312r输出或耦合到每个光学组件310l、310r。然后，耦合接入的光可以通过涉及在相应的中间(折叠)区域314l、314r中的光学组件的横向的衍射和tir(全内反射)的机制被引导，并且还向下进入相应的出射区域316l、316r，在出射区域316l、316r中耦合接入的光向用户的眼部出射。

光学组件310可以基本上是透明的，使得用户不仅可以查看来自光引擎的图像，而且还可以通过光学组件查看真实世界视图。

光学组件可以具有折射率n，其使得完全内部反射发生以沿着中间扩展区域314引导来自光引擎的光束，并向下朝向出射区域316。

头戴式耳机或头戴式设备形式的用户设备102还可以包括被配置为捕获佩戴头戴式耳机的用户的视场的至少一个摄像机。例如，图3所示的头戴式耳机包括立体摄像机318l和318r，立体摄像机318l和318r被配置为分别从用户的左眼和右眼捕获近似视图(或视场)。在一些实施例中，一个摄像机可以被配置为捕获适合的视频图像，并且另外的摄像机或范围感测传感器被配置为捕获或确定从用户到用户的环境中的对象的距离。

类似地，头戴式耳机形式的用户设备102可以包括安装在头戴式耳机的框架306上的多个麦克风。图3所示的示例分别示出了位于支撑延伸部或臂306和308的“前”端处的左麦克风322l和右麦克风322r。支撑延伸部或臂306和308还可以包括“左”和“右”通道扬声器、耳塞或其他音频输出换能器。例如，图3所示的头戴式耳机包括用作左和右声道输出扬声器的一对骨传导音频换能器320l和320r。

本文描述了关于混合现实(mr)应用的概念，然而在其他实施例中，相同的概念可以应用于任何单方或多方通信应用。混合现实应用例如可以涉及场景的共享，其中，包括摄像机的设备被配置为捕获图像或视频并且将该图像或该多个图像发送到其他设备。另外，可以通过对象的添加、删除和交互来扩充或注释该图像或视频。这些对象或虚拟对象可以被“放置”在图像场景内并且可以具有能够被参与者(包括场景所有者)“看见”并与之进行交互的视觉表示。对象不仅可以通过位置被定义还可以包括诸如对象类型和状态之类的其他属性。例如，对象可以具有诸如音频/图像/视频/文本内容之类的相关联的内容。例如，参与者可以尝试与场景所有者和/或其他参与者进行通信，并将音频/视频对象放置在共享场景内。然后，同一参与者可以捕获视频和音频数据并且将该视频和音频数据与对象相关联，以及将对象信息和音频/视频数据发送到共享场景中的参与者以用于所有参与者来观看/收听。在一些实施例中，场景所有者还可以在由用户设备生成的场景内定义对象并且将对象放置在该场景内而无需共享该场景。例如，用户设备的用户可以将具有相关联的音频或视频以及音频数据内容的对象放置在场景内，并且然后与该对象进行交互以使得相关联的音频或视频以及音频数据内容能够被呈现给用户。

对象的放置可以关于场景并且还可以关于场景的三维表示来进行。为了使得能够在远程设备上呈现或渲染对象的准确的放置，与该场景相关联的表面再现(sr)或网格数据可以被传递给共享场景的所有参与者。

关于图4a的用于用户设备的适合的发送(媒介栈)流水线架构的示例。在本文所描述的这样的实施例中，用户设备可以被配置为生成图像(视频数据)和表面再现(sr)或网格数据。

在所示的示例中，由(红-绿-蓝)rgb传感器/摄像机403来捕捉用于生成共享场景的图像。rgb传感器/摄像机403可以被配置为将捕获的rgb原始数据传递给适合的设备视频源405并且还将任何摄像机姿势/投影矩阵信息传递给适合的设备视频源405。

如图4a所示的示例架构还包括深度传感器/摄像机401，其被配置为捕获可以被传递给表面再现(sr)引擎和数据库402的深度信息。该sr引擎和数据库402可以被配置为接收深度信息并且根据已知的网格/sr方法生成sr原始数据。然后，该sr原始数据可以被传递给设备视频源405。

视频源405可以被配置为接收sr原始数据和rgb原始数据以及任何摄像机姿势/投影矩阵信息。此外，视频源405可以被配置为将sr原始数据输出到适合的sr信道编码器407，并且将依据原始帧和摄像机姿势/投影矩阵数据的视频图像数据输出到适合的h.264信道编码器409。在本文所描述的示例中，h.264信道编码器409是适合的视频编码器的示例。应当理解的是，在一些其他实施例中，所采用的视频编解码器是任何适合的编解码器。例如，编码器和解码器可以采用高效视频编码hevc实现。

sr信道编码器407可以被配置为接收sr原始数据并对sr原始数据进行编码以生成适合的编码的sr数据。然后，该sr信道编码器407可以被配置为将编码的sr数据传递给分组生成器。具体地，编码的数据可以被传递到sr分组创建器413。

h.264信道编码器409可以类似地被配置为接收原始图像/视频帧和摄像机姿势/投影矩阵数据，并且处理这些数据以生成编码的帧和sei(补充增强信息)消息数据。编码的帧和sei消息数据可以被传递到分组生成器411，并且具体地被传递到h.264分组创建器415。

与分组生成器411相关联的概念是控制视频和sr数据的分组以便数据的接收机能够产生可靠和有效的混合现实体验。

分组生成器411可以例如包括sr分组创建器413。sr分组创建器413可以被配置为生成可以被传递到分组类型敏感成形器419的sr片段分组。sr分组创建器413还可以被控制以用于重发反馈目的。在一些实施例中，使用nack方法进行重传反馈可能是不适合的，并因此可以实现ack方法。

因此，在一些实施例中，sr分组创建器413可被配置为将任何sr数据分组的引用保持在未决缓冲器中直至它们被发送。一旦分组被发送，然后可以将引用移动到未确认缓冲器。

在这样的实施例中，未确认缓冲器可以具有限制发射机和接收机之间的业务的窗口大小。

然后可以保持sr数据分组的引用直到接收机确认分组被接收到。

在一些实施例中，未确认的缓冲器窗口大小可以根据接收机缓冲器深度进行动态地调整。在一些实施例中，未确认的缓冲器窗口大小可以是静态值，例如，32。

在一些实施例中，sr分组创建器413可以被配置为当sr帧到达时持续发送来自未决缓冲器的sr数据分组，即使当时没有接收到的反馈消息(例如，包括acknowledgmentbitmap(确认比特映射)的消息)。实现持续发送方法表示不应该在接收机处发生饥饿。

反馈消息可以包括值(例如，acknowledgmentbitmap消息中的basesequence(基序列)的值)。增加的值意味着到达并且包含值-1(basesequence-1)的所有分组都已被接收机确认。

在一些实施例中，仅当存在足够带宽时，sr分组创建器413可以被配置为发送除了所学习的接收机缓冲器深度以外的数据分组。

在一些实施例中，发送速度可以由双路信道的rtt(往返时间)限制。例如，当未确认的缓冲器窗口大小是128个分组，并且rtt是200ms，并且mpu(应用于sr数据片段的最大分组单位(maximumpacketunit))是1000时，则最大发送速度可以被限制为128*1000*(1000/200)＝5000千字节/秒。

因此，在一些实施例中，未确认的缓冲器窗口大小以及(acknowledgmentbitmap)反馈消息的长度可以被调整以改变最大速率。

类似地，分组生成器411可以包括h.264分组创建器415。h.264分组创建器415可以被配置为生成适合的h.264分组片段并将这些分组片段传递到分组类型敏感成形器419。

分组生成器411还可以包括被配置为控制分组片段的生成和输出的带宽(bw)控制器417。bw控制器417可以负责在sr分组创建器413和h.264分组创建器415之间划分带宽分配。在一些实施例中，bw控制器417针对视频维持48kb/s的最小带宽。

在一些实施例中，bw控制器417可以被配置为在同时运行的每个并行信道之间初始地均匀地分配数据。例如，对于单个h.264信道和单个sr信道，数据划分可以以50/50开始。然而，bw控制器417可以被配置为在确定的时间段之后针对h.264和sr带宽要求确定或估计短期和长期平均。例如，用于h.264和sr带宽要求的短期和长期平均可以在2.5秒后被确定。

应该注意的是，在h.264/视频和sr带宽之间的这些值之间存在行为上的差异。对于视频，带宽值是被传递到h.264(视频)编码器409或应该由h.264(视频)编码器409遵守的分配。虽然sr带宽值可以是针对由sr信道使用的带宽的观察，并且媒体平台可以监视sr带宽值以确定如何调整sr编码器407内的细节级别的参数。

然后，分组敏感成形器419可以被配置为接收sr分组片段和h.264分组片段，并且生成传递到传送器421的适合的数据分组。分组敏感成形器419可以是感知h.264和sr数据分组的不同的实时要求的(网络业务)成形器。例如，成形器可以被实现为h.264和sr分组之间的轮询。

传送器421接收数据分组并且经由适合的输出流来输出这些数据分组。

关于图4b示出了被配置为接收图像(视频数据)以及表面再现(sr)或网格数据的用户设备的适合的接收流水线(媒体栈)架构。

用户设备可以包括传送器451，其被判定为接收视频流数据并且将该信息传递到接收机/分组汇编器。

分组汇编器可以包括sr分组汇编器453和h.264分组汇编器455。sr分组片段可以被传递到sr分组汇编器453以用于生成编码的sr数据分组。h.264分组汇编器455可以被配置为接收h.264分组片段并且生成编码的帧数据。

sr分组汇编器453可以被配置为生成适合的反馈消息(例如，acknowledgmentbitmap反馈消息)，其可以被发送到sr分组创建器以便控制sr数据的重传。当检测到内容开始事件时(例如，当检测到sr1_content_start_flag时)、或当检测到内容停止事件时(例如，当检测到sr1_content_stop_flag时)、或当检测到文件事件的结束时(例如，当检测到sr1_content_eof_flag时)，可以生成该反馈消息。另外，在一些实施例中，当新的sr分组到达sr分组汇编器453并且自先前的分组以来已经经过了预定的时间段(例如，250ms)时，生成反馈消息。在一些实施例中，针对每第7个(或其他确定的数量)接收的分组生成反馈消息。在一些实施例中，分组的确定的数量可以包括重传的分组。另外，在一些实施例中，反馈消息可以在指示最后接收的分组(basesequence)的反馈值由确定数量的(例如，7个)分组超过了之后被生成。在一些实施例中，当sr信道解码器457报告错误时，生成反馈消息。

如本文所描述的，sr分组创建器被配置为接收反馈消息(acknowledgmentbitmap)并且控制经缓冲的分组的重传。

然后，编码的sr数据分组可以被传递到sr信道解码器457以生成sr原始数据。

h.264信道解码器459可以被配置为接收来自h.264分组汇编器455的编码的帧并且输出适合的原始帧和摄像机姿势/投影矩阵数据。然后，sr原始数据、和原始帧以及摄像机姿势/投影矩阵数据可以被传递到视频接收器461。

视频接收器461可以被配置为将所接收的sr原始数据、和原始帧以及摄像机姿势/投影矩阵数据输出到任何适合的远程视频应用463或库以用于适合的3d场景渲染(在3d场景渲染器465处)和视频服务渲染(在视频表面渲染器467处)。

另外，经由传送器451所接收的关于对象或注释的任何数据可以被传递到适合的对象协议实体(例如，对象更新消息解码器)，并且可以被传递到适合的注释或对象渲染器。

如本文已经描述的，对象可以与音频数据或音频源相关联。例如，佩戴头戴式耳机的用户(场景所有者)可以创建包括视频数据和网格(或表面重建sr数据)的共享场景环境。诸如音频或视频呼入通话对象之类的对象可以被插入到该共享场景，所述对象可以被放置或固定在该共享场景内的位置处。

当对象在用户(场景所有者)的视野内时，可以以任何适合的方式向用户渲染音频信号使得对象的相对位置是可视的，并且因此对象的相对位置可以容易地被用户所确定。然而，当用户(场景所有者)移动或转动他们的头部并且该对象离开了用户的视野(离开了可视的共享场景)时，用户可能迷失方向以继续听到仿佛来自用户前方的位置的音频源。另外，一旦对象离开用户(场景所有者)的视野时，在不在用户周围搜索的情况下，用户可能难以找到该对象。场景所有者头部的这种(快速)搜索移动可以生成能够使共享场景的其他参与者或观察者迷失方向的视频图像。

如本文所描述的概念是能够对于对象相关联的音频信号执行空间音频信号处理，所执行的方式是音频信号呈现为来自于对象的大概位置。例如，这可以通过将适合的头部相关的传输函数(hrtf)应用到音频流水线中的音频信号以在被传递到声卡并且输出之前生成空间输出。在一些实施例中，当对象仅在可视的共享场景之外时，空间音频信号处理可以被应用到与对象相关联的音频信号。

在下面示例中，用户(或收听者)和对象(或音频源)之间的相对位置和/或方向可以大概或基本上由用户佩戴的用户设备和对象之间的相对位置和/或方向所限定。应当理解的是，在一些实施例中，用户(或收听者)和对象(或音频源)之间的相对位置和/或方向还可以被确定为在用户佩戴的用户设备和对象之间的相对位置和/或方向以及确定的位置和/或方向的误差或偏移(其反映了用户设备和用户的“听觉中心”之间的差异)。

关于图5示出了根据一些实施例的用于具有相关联的音频数据的对象的位置或空间处理的示例实体及应用。在该示例中，会话管理实体应用600被采用以接收或维持对象属性(例如，对象位置/方向)和/或其他属性(例如，对象类型和对象状态)。在一些实施例中，会话管理实体应用600可以被配置为将对象位置和/或方向输出到相对位置/方向确定器601。

如图5所示的示例进一步可以包括相对位置/方向确定器601。该相对位置/方向确定器601可以被配置为维持或接收来自于会话管理实体应用600的对象位置和/或方向信息。相对位置确定器601还可以被配置为接收诸如方向和/或位置之类的用户设备属性。相对位置确定器601还可以被配置为接收其他参数，例如，用户设备的视野以及确定的或估计的位置和/或方向误差或偏移信息。因此，在一些实施例中，相对位置确定器601可以被配置为生成定义用户设备(收听者)和对象(源)之间的空间关系的相对收听者-源位置/方向。在一些实施例中，空间关系可以基于或由从用户设备到对象的相对方位(方向)来定义，或者可以由用户设备与对象之间的相对方位(方向)和“距离”来定义。另外，在一些实施例中，相对位置确定器601可以被配置为确定收听者-源之间的相对位置/方向是否表示对象在用户设备摄像机的视野之内。换句话说，相对位置确定器600可以被配置为确定对象是否在当前可视或可观察的共享场景内。

然后，该信息可以被传递到音频位置处理器(或空间信号处理器)605。

在图5所示的示例中，进一步可以包括音频管理实体602。该音频管理实体602可以被配置为维持或存储音频处理参数。例如，音频管理实体可以存储指示所需的输出格式(例如，立体声、多信道、5.1信道输出)的初始化信息。另外，音频管理实体可以存储诸如初始化参数的信息，该初始化参数例如用于源和/或收听者的个性化的hrtf的指示性模式和混响设置。该音频管理实体602可以被配置为将这些参数输出到音频位置处理器605。

如图5所示的示例可以进一步包括音频输入缓冲器603。该音频输入缓冲器603可以被配置为接收音频帧并且在处理之前缓冲该音频帧。在本文所示的示例中，音频输入信号流中的信号是以48khz采样的16位浮点单信道pcm编码的音频信号。然而，应当理解的是，该音频输入可以是任何适合的音频输入格式。另外，应当理解的是，虽然为了简单起见在本文中示出并且描述的实施例是以单个对象和与该对象相关联的音频数据为特征，但是本方法和装置可以被配置为处理多个对象和音频信号。在这样的实施例中，音频信号中的每一个的输出可以被组合以生成组合的经处理的对象音频信号。

音频输入缓冲器603可以被判定为将输入音频信号传递到音频位置处理器605。如图5所示的示例进一步包括音频位置处理器605(或音频信号处理器或空间音频信号处理器)。在这种实施例中，音频位置处理器605可以被配置为接收来自于音频输入缓冲器603的输入音频信号、来自于相对位置/方向确定器601的相对位置/方向信息以及来自于音频管理实体602的配置数据。然后，音频位置处理器605可以生成适合的经处理的音频信号输出。例如，在一些实施例中，音频位置处理器可以被配置为使用相对位置/方向信息作为输入参数应用头部相关的传输函数(hrtf)以生成来自于单音频输入信道的多个音频输出信道。在本文所描述的示例中，音频位置处理器605可以生成以48khz采样的16位浮点立体声pcm音频信号传到音频输出缓冲器607。在本文所描述的示例中，音频位置处理器605使用hrtf以生成多信道音频输出信号。然而，任何适合的空间处理应用可以被采用以生成音频信号。例如，空间处理可以是幅度平移或单音频信号到输出信道的映射。

如图5所示的示例还包括音频输出607，其被配置为接收从音频位置处理器605、缓冲器输出的音频信号并且将音频输出到适合的音频输出实体，例如，在个人计算机或类似的数字-模拟转换实体内的声卡。

关于图6描述了与如图5所示的示例实现患者相关联的示例初始化处理的流程图700。例如，该初始化处理可以从设置初始源位置开始。该初始源位置可以是存储在音频管理实体602中的默认的对象位置。在一些示例中，初始源位置可以默认为(0,0,0)的初始坐标系。

在图6中由步骤s701示出了设置初始源位置的操作。

会话管理实体应用600还可以根据对象属性消息确定源位置。

在图6中由步骤s703示出了根据对象属性消息确定源位置的操作。

另外，该方法可以进一步设置用于源和/或收听者的初始方位性。默认的方位性可以是“全方位的”，换句话说，源和/或收听者不需要空间滤波并且不具有“偏爱的”方向。

在图6中由步骤s705示出了设置初始方位性的操作。

另外，该方法可以要求设置收听者的初始默认方向。收听者的方向的初始或默认设置可以是(0,0,0)的默认位置/方向。换句话说，源和收听者会被初始化为同地协作的。

在图6中由步骤s707示出了设置初始方向的操作。

另外，该方法可以进一步描述设置初始混响设置以用于处理。用于混响的默认设置可以是“关断”，因为没有混响将被施加到输入音频信号。

在图6中由步骤s709示出了设置初始混响设置的操作。

关于图7示出了关于如图5所示的装置描述的空间音频信号处理的示例操作的流程图800。

相对位置确定器可以被配置为更新用户设备，并且因此近似收听者(用户或场景所有者)的头部位置/方向。例如，该信息可以是从用户设备定位确定传感器或诸如数字罗盘或位置估算器之类的实体中接收的。

在图7中由步骤s801示出了更新收听者头部位置/方向的操作。

另外，相对位置确定器601可以被配置为更新源(对象)位置/方向。例如，该源位置/方向信息可以是从会话管理实体应用600和对象属性值接收的。

在图7中由步骤s803示出了更新源位置/方向的操作。

在相对位置确定器601的一些实施例中，相对位置确定器601可以被配置为确定收听者-源位置/方向。如本文所述，其可以被定义为从收听者到源的方向或作为方向和距离值。在一些实施例中，相对位置确定器可以进一步被配置为确定在音频信号的帧之间(或另一个确定的时间段之间)的相对收听者-源位置/方向中的变化。

在一些实施例中，相对位置确定器601可以进一步被配置为确定该变化是否小于确定的最小变化(例如，3°的旋转)。当该变化小于确定的最小变化时，则没有处理中的处理或变化会被执行。

另外，在一些实施例中，相对位置确定器601可以被配置为确定何时相对收听者-源位置/方向使得该源仍然在设备的用户的视野内，然后没有处理的进一步处理或变化会被执行并且操作循环返回到更新收听者和源位置/方向值。

在图7中由步骤s805示出了确定相对收听者-源位置/方向、确定相对收听者-源位置/方向变化以及确定该变化是否小于确定的最小变化(并且另外，相对收听者-源位置/方向是否仍然在视野内)的操作。

在一些实施例中，当变化大于确定的最小变化并且在一些实施例中，当相对收听者-源位置/方向值在用户设备的视野之外)时，则平滑的相对收听者-源位置/方向值被确定。在一些实施例中，该平滑的值可以由旧的和新的相对收听者-源位置/方向的线性插值来生成，并且该平滑的值可以被应用于音频数据的后续帧。类似地，平滑的值可以通过将适合的低通滤波器应用于相对收听者-源位置/方向值来生成。

在图7中由步骤s807示出了生成平滑的相对收听者-源位置/方向值的操作。

然后，平滑的相对收听者-源值可以被输出到音频位置处理器605。

在图7中由步骤s809示出了将平滑的相对收听者-源值输出到音频位置处理器的操作。

然后，音频位置处理器605可以接收音频输入信号并使用相对收听者-源值作为hrtf的输入参数应用适合的头部相关的传输函数处理以生成适合的音频信道输出。例如，音频位置处理器605可以根据单输入音频信道来生成立体音频信道。

使用头部相关的传输函数根据单音频信道来生成立体(多个)音频信道的过程是已知的方法并且不会在本文中进行任何进一步的详细描述。

在图7中由步骤s811示出了使用具有相对收听者-源值的hrtf来生成立体或多信道音频信号的操作。

应当理解的是，在一些设备中，处理对象和相关联的音频信号处理的客户端可以被切换到可以不需要空间音频信号处理的其他客户端。例如，用户设备的用户可以使用诸如本文所描述的对象在电话通话或会议通话之间切换到因特网浏览器客户端。应当理解的是，与浏览器客户端相关联的音频不应该需要被进行空间音频信号处理，因为这可以导致用户将他们的头部转动到音频信号处于混乱的方向。

因此，关于图8a和图8b进一步详细描述了在空间音频信号处理客户端与采用了图5所示的实体的其他客户端之间进行切换的示例。

在图8所示的示例流程图900中，空间音频信号处理客户端最初处于前景并且立体音频信道是基于确定的hrtf生成的。

在图8中由步骤s901示出了当客户端处于前景时，基于确定的hrtf生成立体音频信号的操作。

相对位置确定器601可以进一步被配置为确定客户端何时被移动到背景。

在图8中由步骤s903示出了确定客户端何时被移动到背景的操作。

在一些实施例中，相对位置确定器601可以被配置为实现从最后的已知的相对收听者-源位置/方向到默认的位置的平滑的转变。例如，这可以使用在最后的相对收听者-源位置/方向与默认的位置/方向之间的线性内插或低通滤波来实现。

在图8中由步骤s905示出了在最后的已知的相对收听者-源位置/方向与默认的相对收听者-源位置/方向之间实现平滑的转变的操作。

一旦已经执行了从最后的已知的相对收听者-源位置/方向到默认的相对收听者-源位置/方向的平滑的转变，则相对位置确定器601可以被配置为禁用空间或hrtf处理。

在图8中由步骤s907示出了禁用hrtf处理的操作。

关于图8b示出了其中空间处理适合的客户端从背景移动到前景的操作。流程图950示出了确定何时将客户端从背景移动到前景。

在图8b中由步骤s951示出了确定空间音频信号处理客户端正在移动到前景的操作。

另外，相对位置确定器601可以被配置为更新相对收听者-源位置/方向值。

在图8b中由步骤s953示出了更新相对收听者-源位置/方向值的操作。

另外，相对位置确定器601可以被配置为实现从默认的相对收听者-源位置/方向到更新的相对收听者-源位置/方向的平滑的转变。例如，这可以使用在一系列帧中的适合的线性内插或使用低通滤波操作来执行。

在图8b中由步骤s955示出了从默认的位置到更新的相对收听者-源位置/方向的平滑的转变的实现。

然后，音频位置处理器可以基于平滑的转变值来实现hrtf处理直到已经到达相对收听者-源位置/方向。

在图8b中由步骤s957示出了基于平滑的转变值来实现hrtf或空间音频处理并且然后继续相对收听者-源位置/方向处理的操作。

虽然已经参照由用户针对关于传入的直播视频的帧定位的对象进行的交互描述了实施例，但是本公开的实施例扩展到通过由计算机生成的图像的交互。

通常，本文所述的功能中的任何一个可以使用软件、固件、硬件(例如，固定的逻辑电路)、或这些实现的组合来实现。如本文使用的术语“控制器”、“功能”、“组件”和“应用”通常表示软件、固件、硬件或其组合。在软件实现的情况下，控制器、功能、组件或应用表示在处理器(例如，cpu或多个cpu)上执行时执行指定任务的程序代码。程序代码可以存储在一个或多个计算机可读存储器设备中。下面描述的技术的特征是平台无关的，这表示技术可以在具有各种处理器的各种商业计算平台上被实现。

例如，用户终端还可以包括使得用户终端的硬件执行操作的实体(例如，软件)，例如，处理器功能块等等。例如，用户终端可以包括计算机可读介质，其可以被配置为维持如下指令，所述指令使得用户终端并且更具体地使得用户终端的操作系统和相关联的硬件来执行操作。因此，该指令用于配置操作系统和相关联的硬件以执行操作，并且以这种方式引起操作系统和相关联的硬件的变换以执行功能。指令可以由计算机可读介质通过各种不同的配置提供给用户终端。

计算机可读介质的一种这样的配置是信号承载介质，并因此被配置为例如经由网络将指令(例如，作为载波)发送到计算设备。计算机可读介质也可以被配置为计算机可读存储介质，并因此不是信号承载介质。计算机可读存储介质的示例包括随机存取存储器(ram)、只读存储器(rom)、光盘、闪速存储器、硬盘存储器以及可以是使用磁性、光学和其他技术来存储指令和其他数据的其他存储器设备。

还提供了一种用于生成场景的用户设备，该用户设备包括：对象确定器，其被配置为确定所述场景的对象，所述对象与至少一个音频信号相关联；相对位置/方向确定器，其被配置为确定所述用户设备的用户与所述对象之间的相对位置/方向；以及音频位置处理器，其被配置为基于所述相对位置/方向对所述至少一个音频信号进行空间音频信号处理以生成至少两个信道音频信号。

所述音频位置处理器可以被配置为利用头部相关的传输函数对所述至少一个音频信号进行处理，其中所述相对位置/方向作为所述头部相关的传输函数的参数输入。

所述场景可以是通过通信网络与至少一个另外的用户设备进行通信的共享场景，并且其中，所述对象可以与所述至少一个另外的用户设备相关联，并且其中，所述至少一个音频信号可以是来自于所述至少一个另外的用户设备的发送的音频信号。

所述对象可以进一步与视频或图像相关联，并且所述用户设备可以进一步包括对象渲染器，所述对象渲染器被配置为在所述相对位置/方向处显示所述视频或图像。

所述相对位置/方向确定器可以被配置为执行以下操作：确定在确定的时间段内的所述相对位置/方向中的变化；确定所述相对位置/方向中的变化大于确定的阈值；以及生成平滑的相对位置/方向作为所述相对位置/方向。

所述相对位置/方向确定器可以被配置为执行以下操作：基于确定所述相对位置/方向在所述用户的视野外，来生成在所述用户的视野外的相对位置/方向作为所述相对位置/方向；以及另外维持当前的位置/方向作为所述相对位置/方向。

所述相对位置/方向确定器可以被配置为执行以下操作：确定所述相对位置/方向；确定在确定的时间段内的所述相对位置/方向中的变化；基于确定所述相对位置/方向是在所述用户的视野外以及确定所述相对位置/方向中的变化大于确定的阈值，来生成在所述用户的视野外的平滑的相对位置/方向作为所述相对位置/方向；以及另外维持当前的位置/方向作为所述相对位置/方向。

所述对象确定器可以被配置为确定至少一个另外的对象，所述对象与至少一个另外的音频信号相关联；并且其中，所述相对位置/方向确定器可以被配置为基于确定的相对位置/方向和默认的相对位置/方向来确定转变相对位置/方向；并且所述音频位置处理器可以被配置为基于所述转变相对位置/方向对所述至少一个音频信号进行空间音频信号处理以生成至少两个信道音频信号。

还提供了在用户设备处实现的用于生成场景的方法，所述方法包括：确定所述场景的对象，所述对象与至少一个音频信号相关联；确定在所述用户设备的用户与所述对象之间的相对位置/方向；以及基于所述相对位置/方向对所述至少一个音频信号进行空间音频信号处理以生成至少两个信道音频信号。

对所述至少一个音频信号进行空间音频信号处理可以包括利用头部相关的传输函数对所述至少一个音频信号进行处理，其中所述相对位置/方向作为所述头部相关的传输函数的参数输入。

所述场景可以是通过通信网络与至少一个另外的用户设备进行通信的共享场景，并且其中，所述对象可以与所述至少一个另外的用户设备相关联，并且其中，所述至少一个音频信号可以是来自于所述至少一个另外的用户设备发送的音频信号。

所述对象可以进一步与视频或图像相关联，并且所述方法可以进一步包括在所述相对位置/方向处显示所述视频或图像。

确定相对位置/方向可以包括：确定在确定的时间段内的所述相对位置/方向中的变化；确定所述相对位置/方向中的变化大于确定的阈值；以及生成平滑的相对位置/方向作为所述相对位置/方向。

确定相对位置/方向可以包括：基于确定所述相对位置/方向在所述用户的视野外，来生成在所述用户的视野外的相对位置/方向作为所述相对位置/方向；以及另外维持当前的位置/方向作为所述相对位置/方向。

确定相对位置/方向可以包括：确定所述相对位置/方向；确定在确定的时间段内的所述相对位置/方向中的变化；基于确定所述相对位置/方向在所述用户的视野外以及确定所述相对位置/方向中的变化大于确定的阈值，来生成在所述用户的视野外的平滑的相对位置/方向作为所述相对位置/方向；以及另外维持当前的位置/方向作为所述相对位置/方向。

所述方法可以进一步包括：确定至少一个另外的对象，所述对象与至少一个另外的音频信号相关联；基于所述确定的相对位置/方向和默认相对位置/方向，确定转变相对位置/方向；基于所述转变相对位置/方向对所述至少一个音频信号进行空间音频信号处理以来生成至少两个信道音频信号。

还提供了一种计算机程序产品，所述计算机程序产品被体现在非暂时性计算机可读介质上，并被配置为当在用户设备的处理器上执行以用于生成场景时实施以下操作：确定所述场景的对象，所述对象与至少一个音频信号相关联；确定所述用户设备的用户与所述对象之间的相对位置/方向；以及基于所述相对位置/方向对所述至少一个音频信号进行空间音频信号处理以生成至少两个信道音频信号。

尽管已经以结构特征和/或方法动作特有的语言对主题进行了描述，但是应当理解，所附权利要求中限定的主题不一定限于上述具体特征或动作。相反，上述具体特征和动作被公开为实现权利要求的示例形式。