多视点多用户音频用户体验的制作方法

1.各种示例实施例通常涉及音频渲染，并且更具体地涉及沉浸式音频内容信令和渲染。


背景技术：

2.沉浸式音频和/或视觉内容通常允许用户以与用户的方位和/或位置一致的方式体验内容。例如，沉浸式音频内容可以允许用户以与用户的旋转运动(例如，俯仰、偏航和翻滚)一致的方式来体验音频。这种沉浸式音频通常称为3dof(三个自由度)内容。针对翻滚、俯仰和偏航具有完全自由度而针对平移运动自由度却有限的沉浸式内容，通常被称为3dof+。自由视点音频(也可以称为6dof)通常允许用户在音频(或通常是视听或媒介现实)空间中来回移动并以正确对应于其在该音频空间的位置和方向的方式体验音频空间。沉浸式音频和视频内容通常具有例如在媒介内容环境中的位置和/或对齐这样的属性来允许这样做。
3.运动图像专家组(mpeg)目前正在对名为mpeg
‑
i的沉浸式媒体技术进行标准化，其中包括用于各种虚拟现实(vr)、增强现实(ar)和/或混合现实(mr)用例的方法。另外，第三代合作伙伴计划(3gpp)正在研究沉浸式视听服务以实现标准化，例如用于vr(例如3dof)内容传递的多视点流式传输。
附图说明
4.现在将参考附图描述一些示例实施例。
5.图1是其中可以实践各种示例实施例的一种可能的且非限制性的示例性装置的框图；
6.图2表示根据一些示例实施例的视听体验文件的多视点内容空间200；
7.图3示出了多视点内容文件的多用户内容消耗的示例；
8.图4是根据一些示例实施例的高级过程流程图；
9.图5表示根据一些示例实施例的视听体验文件的多视点内容空间；
10.图6a和图6b示出了根据一些示例实施例的多视点文件的不同切换实现方式；以及
11.图7是根据各种示例实施例的逻辑流程图，并且示出了示例性方法的操作、具体化在计算机可读存储器上的计算机程序指令的执行结果、由以硬件实现的逻辑执行的功能、和/或用于执行根据示例性实施例的功能的互连的模块。
具体实施方式
12.在说明书和/或附图中可以找到的下列缩写定义如下：
13.定义如下：
14.3dof
ꢀꢀꢀ
3自由度(头部旋转)
15.3dof+
ꢀꢀ
具有附加的有限平移运动的3dof(例如，头部运动)
16.6dof
ꢀꢀꢀ
6个自由度(头部旋转和平移运动)
17.3gpp
ꢀꢀꢀ
第三代合作伙伴计划
18.ar
ꢀꢀꢀꢀꢀ
增强现实
19.daw
ꢀꢀꢀꢀ
数字音频工作站
20.disev
ꢀꢀ
中断事件
21.disevr 中断事件响应
22.mpeg
ꢀꢀꢀ
运动图像专家组
23.mr
ꢀꢀꢀꢀꢀ
混合现实
24.vr
ꢀꢀꢀꢀꢀ
虚拟现实
25.本文的各种示例性实施例描述了用于控制多视点全向内容中的音频的技术。在描述了其中可以使用示例性实施例的系统之后，呈现了这些技术的附加描述。
26.在图1中示出了装置100
‑
1，其包括通过一个或多个总线112互连的一个或多个处理器101，一个或多个存储器104。一个或多个总线112可以是地址、数据或控制总线，并且可以包括任何互联机构，例如主板或集成电路上的一系列线路、光纤或其他光通信设备等。一个或多个存储器104包括计算机程序代码106。装置100
‑
1可以包括现实模块，所述现实模块包括可以以多种方式实现的部件108
‑
1和/或108
‑
2中的一个或两个。所述现实模块可以在硬件中被实现为现实模块108
‑
2，诸如被实现为一个或多个处理器101的一部分。现实模块108
‑
2还可以被实现为集成电路或通过诸如可编程门阵列的其他硬件来实现。在另一示例中，现实模块可以被实现为现实模块108
‑
2，其被实现为计算机程序代码106并且由一个或多个处理器101执行。例如，一个或多个存储器104和计算机程序代码106可被配置为与一个或多个处理器101一起使装置100
‑
1执行本文所描述的一个或多个操作。
27.一个或多个计算机可读存储器104可以是适合于本地技术环境的任何类型，并且可以使用任何合适的数据存储技术来实现，例如基于半导体的存储设备、闪存、磁存储设备和系统、光存储设备和系统、固定存储器和可移动存储器。计算机可读存储器104可以是用于执行存储功能的模块。作为非限制性示例，处理器101可以是适合本地技术环境的任何类型，并且可以包括通用计算机、专用计算机、微处理器、数字信号处理器(dsp)和基于多核处理器体系结构的处理器中的一个或多个。处理器101可以是用于执行功能——诸如控制装置100
‑
1和本文所述的其他功能——的模块。
28.在一些实施例中，装置100
‑
1可以包括一个或多个输入110和/或输出112。输入110可以包括用于向计算机系统提供用户输入的任何公知设备，例如鼠标、键盘、触摸板、相机、触摸屏和/或换能器。输入110还可以包括用于将信息输入到装置100
‑
1中的任何其他合适的设备，例如另一个设备。
29.在一些实施例中，装置100
‑
1可以包括一个或多个输入110和/或输出112。输入110可以包括用于向计算机系统提供用户输入的任何公知设备，例如鼠标、键盘、触摸板、相机、触摸屏和/或换能器。输入端110还可以包括用于将信息输入到装置100
‑
1中的任何其他合适的设备，例如gps接收器、传感器和/或其他计算设备。传感器可以是陀螺仪传感器、压力传感器、地磁传感器、光传感器、气压计、霍尔传感器等。输出112可以包括例如一个或多个公知的显示器(诸如投影仪显示器、近眼显示器、vr头戴式受话器显示器等)、扬声器以及向另一设备传送信息的通信输出。如图1所示，另一设备可以是装置100
‑
2，其可以与针对装置
100
‑
1所示类似地实现。
30.输入110/输出112可以包括用于有线和/或无线通信(例如wifi，蓝牙，蜂窝，nfc，以太网和/等)的接收器和/或发送器，其可以用于例如在装置100
‑
1和100
‑
2之间的通信。在一些实施例中，一个或多个输入110和/或一个或多个输出112中的每一个可以整体地、物理地或无线地连接到装置100
‑
1。
31.通常，装置100
‑
1的各种实施例可以包括但不限于诸如智能电话、平板电脑、个人数字助理(pda)之类的蜂窝电话，诸如台式机和便携式计算机之类的计算机、游戏设备、vr头戴式受话器/护目镜/眼镜、音乐存储和播放设备、平板电脑以及结合了这些功能的便携式设备或终端。
32.在一些示例实施例中，如下面更详细地描述的，装置100
‑
1可以对应于用于通过内容创建工具来创建沉浸式媒体内容的系统、用于渲染沉浸式媒体内容的系统和/或用于将沉浸式媒体内容传递给另一设备的系统。
33.因此，已经为各种示例性实施例的实施引入了一种合适但非限制性的技术上下文，现在将更加具体地描述示例性实施例。
34.如以下更详细描述的，本文所述的一些方面可以在内容创建——内容交付——内容消费过程的各个部分中实现。例如，一些方面旨在改进用于ar/mr/vr内容创建的音频软件的工具(例如，用于定义标志、规则的工具，其与音频波形内容一起作为元数据传递)；内容创建工具可以包括但不限于软件(例如用于数字音频工作站的软件)或能够为多视点媒体内容进行音频创作的插件。
35.一些方面涉及媒体文件格式和元数据描述(例如，诸如mpeg
‑
1标准)。例如，元数据可以定义本地用户音频呈现何时由于中断事件而被修以及所述修改是如何完成的(中断事件响应)。
36.一些方面涉及ar/mr/vr设备或诸如ar耳机设备或应用中的音频内容渲染引擎，例如增强现实耳机设备、移动客户端或音频渲染器。音频渲染器可以是符合相关标准(例如，mpeg
‑
1)的音频渲染器。这些方面可以包括例如元数据的读取、音频流的选择以及基于元数据的渲染的修改。音频内容呈现引擎可以在设备上和/或设备上的软件产品上实现，例如，用于ar内容消费的移动设备或vr内容消费设备。
37.这样，各种示例实施例通过允许音频渲染更加一致(例如，相对于内容的故事情节而言)，同时允许终端用户更多自由(例如增加内容消费体验的个性化)，来增强多用户音频体验支持并改善了内容创建者对沉浸式ar/mr/vr体验的控制。
38.各种示例实施例涉及沉浸式音频媒体的渲染(在纯音频或视听环境中)以及与控制该渲染有关的信令。本文所述的各种特征可以由相关标准定义，诸如mpeg
‑
1音频(阶段1a、1b或2阶段)规范和/或3gpp规范。
39.为了便于理解，本文中的描述有时使用背景音乐作为示例音频，但是，本文中所描述的各种示例实施例同样适用于任何其他音频类型。
40.本文中通常使用术语“音频空间”来指代由具有至少两个不同收听点的媒体内容文件定义的三维空间，从而使得用户可以在不同收听点之间切换和/或移动。切换可以涉及空间、时间或某些其他上下文方面(例如，故事元素或由内容创建者定义的规则集)。因此，应当理解，用户可能能够经由用户输入在音频空间中的至少两个收听点之间移动和/或切
换，依赖于服务或内容的方面可以触发在至少两个不同收听点之间的切换，并且/或者切换可能涉及任何其他上下文方面(例如故事元素、内容创建者设置的规则，等等)。
[0041]“空间音频”通常是指这样的音频，其中用户感知到具有适当方向性和环境属性的声音。
[0042]
如本文所使用的，“消费”媒体内容的用户可以包括收听媒体内容、观看媒体内容、与媒体内容交互等。
[0043]
本文通常使用术语“视点”来描述多视点内容(例如3dof、3dof+或6dof内容)中的视觉视点和/或音频视点。作为非限制性示例，视点可以是3dof内容的收听点，其中整个完整的音频场景可以包括多个离散的收听点。作为另一个非限制性示例，视点可以对应于3dof+内容，其中在上面针对3dof内容描述的收听点附近存在有限的翻译可能性。
[0044]“音频对象”的非限制性示例包括具有空间位置的音频源、基于声道的床、表示为一阶全景声/更高阶全景声(foa/hoa)的基于场景的音频、捕获的音频场景的元数据辅助空间音频(masa)表示、或在用户正在体验的媒体内容的上下文中具有与其相关联的元数据的任何音频。
[0045]
在3d空间中，总共有六个自由度(dof)定义了用户可以在该空间中移动的方式。此运动通常分为两类：旋转和平移运动，每个运动都包含三个自由度。旋转运动足以实现简单的vr体验，用户可以转动头部(俯仰，偏航和翻滚)以从静态点或沿自动移动的轨迹来体验空间。平移运动意味着用户还可以更改渲染的位置，即用户可以根据自己的意愿沿x，y和z轴移动。自由视点的ar/vr体验允许旋转和平移运动二者。通常使用术语3dof、3dof+和6dof谈论各种自由度和相关体验。3dof+介于3dof和6dof之间。它允许一些受限的用户移动，例如，可以考虑实施受限的6dof，其中用户正在坐下，但可以将头部朝各个方向倾斜，内容渲染被相应地影响。
[0046]
音频和视频内容通常具有属性，例如在媒介内容环境中的位置和对齐等。该信息允许相对于用户的位置和旋转来渲染内容，使得用户将仿佛在那里那样地体验该内容。除了剧情性音频内容(在渲染时考虑用户的位置/旋转)之外，通常还使用非剧情性音频，至少无论用户的头部是否旋转，它都保持固定。这样的音频内容可以具有方向等，但是这些方向相对于用户是固定的。例如对于背景音乐、旁白评论、某些类型的对话等，这样的内容渲染是有用的。然而，在一些实施例中，非剧情性音频可以仅在6dof内容的某个区域中再现，例如使得超出某个(视点)区域的用户移动可能会开始衰减非剧情性音频，直到其级别达到零为止。
[0047]
多视点媒体内容的技术实现方式通常使得媒体文件包括与媒介的内容环境中的多个“隔离但相关”的视点(或收听点)相关的多个流。例如，每个视点可以是自包含的，但可以通过元数据集互连，该元数据集可以例如在内容制作或脚本编写期间定义(即，应用了内容创建者控制或艺术意图的内容创建过程)。
[0048]
现在参考图2，该图表示根据一些示例实施例的视听体验文件的多视点内容空间200。在该示例中，用户具有在多视点内容文件中具有标记为1
‑
4的四个可能的收听/观看点(也可以称为收听/观看区域)。用户可以首先在第一视点(此处也称为收听点)上消费内容，然后可以在不中断总体体验的情况下“移动”或“传送”到其他视点。在图2中，每个环形观看区域的中心部分对应于例如3dof(+)最佳点，而较暗的区域对应于“可漫游”区域(3dof+或
受限的6dof)。用户可以自由选择在这些视点或场景之间进行任何切换的顺序和定时(在6dof受限制的情况下)。在图2的中间的虚线区域204表示内容中的“障碍”。例如，障碍物可以是墙、山和/或类似物。这样的障碍可以至少限制视线，但也可能限制至少一些音频内容的可听性。在图2中，不同的音频源被表示为星形符号。在虚线区域顶部显示的至少部分音频源(例如音频源202
‑
1)对于场景文件中的所有方向/视点都是可听见的，而其他音频源对于有限数量的视点是可听见的。例如，音频源202
‑
2可以仅对于视点4是可听的，而音频源202
‑
3可以仅对于视点3和4是可听的。
[0049]
除了“自然”边界(例如，墙和山)之外，内容中还可以存在其他类型的边界，例如，多视点内容文件可能包括“虚拟房间”或由“虚拟房间”组成，这些“虚拟房间”至少限制了一些音频内容穿过其“虚拟墙”的可听性。还应注意，虚拟内容文件中的视点可能彼此相距甚远，甚至可能代表不同的时间点或例如交互式故事的不同“路径”。在另外的示例中，虚拟内容文件中的视点可以对应于客户等级级别，其中例如向“白金级别”客户提供比“黄金级别”或“白银级别”客户更丰富或不同的内容或内容部分。另一方面，虚拟内容文件中视点之间的切换可能以非常不同的频率发生。例如，用户可能希望从场景周围的各种可用视图中快速查看特定场景，并在场景之间不断地来回切换，而在大多数服务中不太可能这样，例如，即使是长时间的内容消费期间将多次升级的用户也不太可能这样。
[0050]
考虑到上述情况，在用户不能连续“可漫游”通过整个内容的媒体内容文件中针对每个视点具有不同的音频内容(例如基于对象的音频)通常是有利的。例如，不受限制的6dof内容可以被视为连续“可漫游的”。注意，在这种情况下，从第一视点切换到第二视点可能中断音频渲染和呈现。如果不进行任何平滑处理(例如，使用淡入淡出效果)，则这种中断会使用户感到非常烦恼(因为可能会听到点击声和弹出的声)。因此，在任何这样的应用中，期望在切换时音频的至少一些平滑。但是，通常还有从先前内容到当前内容的中断。
[0051]
例如，在非剧情性音频内容的上下文中，还需要考虑视点之间的切换行为。例如，内容创建者可能希望：即使用户切换到新视点，即使新视点与另一段不同的背景音乐相关联，第一段背景音乐也继续播放。例如，将第一段背景音乐继续(具有相同或不同的声音水平)直到一定时间量，直到音乐或整个内容中发生某个事件，和/或类似情况，可能会有所帮助。例如，对于其他类型的非剧情性音频，例如叙述者的评论或其他类型的剧情性对话或其他剧情性音频，这也可能是正确的。
[0052]
在某些情况下，不同的视点可能会以不同段的背景音乐为特色。通常，这些情况不会按照内容创建者的预期方式来处理，并且即使在应用某些类型的平滑处理时，在视点之间切换时也会使用户分心。例如，当用户在第一视点与第二视点之间进行切换时，即使在某些情况(潜在地，内容创建者指定的情况)下在这些切换过程中理想情况下应保持第一背景音乐，也可能导致从第一背景音乐切换到第二背景音乐。此外，在至少两个视点之间来回切换的用户可能会受到例如在不断变化的背景音乐的困扰。
[0053]
还参照图3，该图示出了多视点内容文件的多用户内容消费的示例。在此示例中，内容文件具有标记为1
‑
3的三个可能的收听/观看点(也可以称为收听/观看区域)。每个收听/视点1、2、3与不同位置处的不同音频源相关联，分别由圆形、星形和三角形表示。此外，每个视点都以单独的背景音乐(即背景音乐1
‑
3)为特色。背景音乐1
‑
3可以例如涉及各个视点的方面和艺术意图。两个用户，即用户1和用户2，分别“位于”收听/观点1和3。在诸如图2
所示的示例中，当用户在视点之间切换时，通常不能保持多视点音频体验的连续性。与此问题相关的是，用于这种格式的内容创作工具不能为用户行为的随机性提供合适的内容创建者控制。
[0054]
在考虑多用户用例时，应该有可能将每个实例视为分开的单用户用例，这样可以在一定程度上改善用户体验。但是，这种方法无法解决至少两个用户之间和/或媒体内容之间的交互。这样的交互对于体验的连续性可能是非常重要的，特别是当用户能够彼此通信并因此彼此共享例如他们对内容体验及其细节的看法或想法。在这种情况下，内容创建者应控制渲染行为，以便至少两个用户共享相似的体验。
[0055]
在多用户使用情况下，用户可以彼此独立地更改其观点。这意味着共享某个视点的用户不一定共享相同的视点历史。例如，一个用户进入当前视点的先前视点可能与另一用户不同。这样，在多用户的情况下，用户可能会在共享相同视点的同时听到不同的音频(由于其个人体验的连续性)，这可能会导致潜在的混乱或令人讨厌的用户体验，因为处于同一视点的用户希望他们听到的音频是相同的或至少非常相似。例如：
[0056]
1.共享相同视点但听到不同音频的用户可能会通过通信音频信道相互通信，如果他们在通信过程中听到来自其他人的背景音乐/音频与他们的明显不同，他们可能会感到困惑。
[0057]
2.共享相同视点但听到不同音频的用户可能通过通信音频信道(或通过其他社交互动方式)相互通信，并且如果其中一位用户提及他听到的音频，但该音频至少明显不在其他用户的内容中，则其他用户会感到困惑。
[0058]
3.共享相同视点但听到不同音频的用户可能会因不同的音频而采取不同的行动(例如，来自先前视点的响亮背景音乐掩盖了当前视点固有的某些音频，从而为当前视点的操作提供了指导)。同样，如果其他用户的行为对他们可见(或可以观察到的)并且看起来与他们的个人经历不一致，则会使用户感到困惑。
[0059]
4.共享相同观点但听到不同的音频的用户可能会以不同的方式回忆他们的体验。如果在消费环节之后讨论或重温该体验，这可能会导致不一致性和混乱。
[0060]
对于用户之间的交互，应使视点中多个用户共享的音频与共同的体验相关，并且不应保持彼此完全独立。否则，如以上示例中所述，共享相同观点(并且彼此交互)的用户将感到困惑或烦恼。各种示例实施例提供对在共享视点处实现共同体验和提供具有来自较早访问的视点的连续性的个性化体验之间的平衡的控制。
[0061]
本文描述的各种特征与这样的情况有关，其中多个用户在共同的交互式内容消费中在多视点内容文件的视点之间切换。在这种情况下，可以为每个用户创建中断事件，其中：第二用户的切换基于与第二用户过去的内容消费有关的至少一个规则来修改新/当前视点中的第二用户的音频渲染，并且使第一用户知道第二用户的音频渲染的所述修改(因为这是常见的交互式内容消费，并且可以假定这种改变可能与第一个用户有关)。本文描述的各种示例实施例提供了当这种中断事件发生时音频如何被渲染和呈现给用户的适当且有效的控制。注意，根据内容的交互性程度，对于除了视点切换之外的其他动作，也可以观察到中断事件。例如，如果中断事件已经触发了被认为是公共音频场景的一部分并且因此第二用户可听见的声音，则可以在同一视点内观察到中断事件。在支持6dof自由移动的内容的情况下，中断事件可能会作为常规内容消费的一部分发生。
[0062]
在一些示例中，由中断事件触发的至少一个声音可以是来自用户或用户设备中的至少一个或与之相关联的声音。它可能是作为6dof场景的一部分的声音，也可能例如通过增强成为6dof场景的一部分。还应理解，用户设备通常是移动设备，包括但不限于头戴式显示器(hmd)设备、ar面罩或眼镜、vr头盔、耳机(通常实现头部跟踪)或移动电话。
[0063]
在一些示例中，当用户从第一收听和/或视点切换到第二收听和/或视点时，可以提供允许基于元数据的至少一个音频的“持续音频渲染”的信令。特别地，在默认情况下，音频不需要在第二收听/视点处是预期的、可用的或可听的。但是，基于信令，所述音频的回放仍然可以在第二收听和/或视点继续播放。例如，当用户从第一收听点切换到第二收听点或跳转到第二收听点时，其中两个收听点都包括背景音乐项，则在切换/跳转之后可以至少部分地保持第一背景音乐项的回放，而不是使用第二收听和/或视点的背景音乐项。
[0064]
某些功能还超越了在切换到当前视点时从先前视点保持播放音频的功能，并且使得内容创建者可以基于一个或多个过去的操作，例如不同用户和/或内容之间的交互，来修改当前视点音频场景。这改善了例如由于至少一个用户的视点切换而导致的包括音频修改的多视点内容的公共内容消费。例如，可以发信号通知基于第二用户的动作的多视点内容的故事情节的改变，以便修改第一用户的相关音频渲染。在此示例中，第一用户和第二用户以允许改进的社交互动的方式独立消费相同的内容。
[0065]
根据一个示例实施例，提供了用于根据第二用户的视点的变化来向第一用户发信号通知音频渲染中的期望改变的技术，其中至少两个用户通常消费交互式多视点3dof/3dof+/6dof内容。当前视点的音频渲染的变化可以包括以下一项或多项：添加至少一个音频；至少一个音频的替换；至少一个音频的修改；以及增强一个或多个音频。
[0066]
在各种示例中，针对当前视点的音频渲染中的变化可以是时间变化的(例如，其可以具有可以以信号单独通知的持续时间)和/或空间变化的(例如，至少第一用户的位置(或旋转)可能会按照以信号单独通知的方式影响该变化。
[0067]
大体而言，所述技术还适用于基于音频的中断事件(disev)和音频的中断事件响应(disevr)的非切换情况和/或单用户情况。针对多视点内容(例如，音频和/或媒体文件)的术语“中断事件”和“中断事件响应”可以定义如下：
[0068]
中断事件(disev)：从用户的角度来看，音频环境受引入以下至少一项的影响：
[0069]
·
至少其他一个观点的音频部分，以及
[0070]
·
至少一个其他视点的音频渲染参数部分，
[0071]
该引入是由于以下至少一项：
[0072]
·
至少有一个先前的视点；
[0073]
·
基于至少一个先前视点的度量或规则。(例如，背景音乐轨道可以从先前的视点延续到当前的视点，这对于可能从具有不同的背景轨道持续规则的第三视点到达当前的视点的另一个用户可能是不同的)；
[0074]
·
在当前视点或至少在一个先前视点中的用户操作(例如，第一用户对在先前视点中可听到的闹钟静音，如果该闹钟没有静音，则在当前视点中也可以听到。这种差异对于没有提前静音闹钟的第二用户来说是明显的)；和
[0075]
·
当前视点中的用户状态(例如，与过去的用户操作有关)。
[0076]
多用户情况下的disev：在至少两个用户参与共同的交互式内容消费的情况下，为
以下切换情况定义了中断事件：
[0077]
·
第二用户切换视点会影响第一用户视点处的音频环境，并且
[0078]
·
根据第一用户的状态或操作来影响切换视点的第二用户的音频环境；
[0079]
以及以下非切换情况，其中：
[0080]
·
至少两个视点中的至少一个可以是共同的视点。例如，在虚拟空间中处于第一视点的第一用户可以打开客厅中的电视，因此虚拟空间(例如厨房)的第二视点中的第二用户能够在第二视点听到电视中的音频。
[0081]
干扰事件响应(“disevr”)：基于观察到的disev，渲染由(元数据)信令指定的修改。换句话说，与中断事件(disev)有关的元数据控制音频对象的渲染，包括基于/在disev期间/之中/之后/由于disev维持其渲染。在多用户使用情况下，音频对象可以被引入给消费不同视点音频的另一用户，或者可以替换地，可以对已经呈现给用户的至少一个音频执行修改。
[0082]
在一些示例实施例中，可以使用另一种指示(例如，诸如音调之类的音频指示)，并且因此为内容创建者提供工具以指定第一用户的过去或当前音频体验如何影响第二用户的音频呈现。这对于多用户使用情况特别有用。
[0083]
还应注意，在一些示例实施例中，事件可能由于用户的动作而发生，该动作导致针对用户的另一视点处的音频改变。例如，用户可以在视点1处按下按钮，从而导致玩具火车在视点2附近启动。默认情况下用户1在视点2不会听到玩具火车的哨声，但是由于按下了按钮，视点2处的音频渲染已更改。在这种情况下，中断事件是用户1按下按钮。
[0084]
一些示例实施例扩展了针对6dof内容的3dof增强音频的控制。这种用例的一个示例是具有用于通信音频的低延迟路径的6dof音频渲染器，(例如mpeg
‑
i 6dof音频渲染器音频渲染器)。在这些实施例中，由于与第二音频(3dof增强音频)有关的属性而被修改的第一音频(6dof音频内容)是与第二音频不同的文件/流的一部分。此外，至少两个用户可以消费不同的内容。用户之间的交互在这里可以限于通信音频。
[0085]
元数据实施方式
[0086]
一些示例实施例涉及所传输的音频流(对象、项目)的选择和渲染。在这样的示例中，音频流可以包括一个或多个音频对象的音频波形以及元数据(或信令)。例如，元数据可以与(编码的)音频波形一起传输。元数据可用于以与内容创建者的意图或服务或应用或内容体验设计一致的方式来渲染音频对象。
[0087]
例如，元数据可以与第一音频对象(例如，例如在第一收听点处的第一音频对象)相关联，从而使得元数据描述当切换到第二收听点时如何处理该第一音频对象，或如何处理基于disev/在disev期间/之中/之后/由于disev的音频对象。元数据可以与第一音频对象和至少第二音频对象(例如来自第二收听点的音频对象)相关联，在这种情况下，元数据描述了如何处理第一音频对象，以及这如何关联或影响对至少一个第二音频对象的处理。在这种情况下，当前/第一音频对象是用户正在切换离开的场景的一部分，并且至少上一个其他音频对象可以是用户切换到的场景的一部分。元数据也可能只与第二个音频对象相关联，在这种情况下，系统将“向后看”音频对象，而不是像上述实现中那样“向前看”。
[0088]
在一个示例实施例中，元数据被提供给不同的“感知区域”，并且当消费例如3dof/3dof+/6dof媒体内容时，元数据用于根据用户的视点变化来发信号通知音频的变化。例如，
在6dof的情况下的多视点可以包括切换穿过重叠或不重叠的感知区域(例如，从房间1到房间2)，其中每个感知区域可以被描述为包括多个viewpointaudioitems(视点音频项)的viewpointcollection(视点集合)。根据视点的变化情况，内容创建者可以规定viewpointaudioitems是否应该立即切换还是保持更长的时间。在一些实施例中，该信息可以由切换设备渲染器确定或在流中作为元数据以信号通知。因此，在一些示例中，不同的音频对象集合可以与不同的音频或感知“区域”相关联，其中在不同的收听点/视点之间的切换进行在不同的音频区域之间切换。例如，第一音频对象集合可以与第一音频区域相关联，而第二音频对象集合可以与第二音频区域相关联，从而使得在第一和第二收听点/视点之间的切换导致在第一音频区/第二音频区之间的切换。
[0089]
在某些情况下，第一音频对象集合和第二音频对象集合可以部分重叠(例如，与同一音频波形关联的音频对象)。重叠的音频对象可以各自具有渲染属性(例如，音频级别)，其中渲染属性的值可以相似或不同。该值在某种意义上可以是相似的，即当在收听/观看点之间切换时，渲染属性的值的差异通常对于用户是不可察觉的。在这种情况下，可以提供一个选项，以忽略在收听点之间切换时与处理音频对象有关的信令。该指示可以由内容创建者设置，例如，以减少复杂性或存储器消耗。如果此类内容正被发送，则也可能不会将此类信令发送到渲染器。在渲染属性值的差异是可以感知的情况下，则可以提供信令(例如元数据)，该信令描述了在不同收听点之间的切换期间和/或之后如何处理重叠的音频对象的至少渲染属性。可能发生这种情况的示例通常涉及虚拟内容文件中特定的视点对，包括至少两个视点，但通常是多个视点。
[0090]
应当理解，本文描述的信令(例如，元数据)可以与一个或多个音频对象的一个或多个单独的属性、一个或多个音频对象，一个或多个收听点/观点和/或一个或多个音频区域相关联，因此在不同的收听点/视点之间切换时允许极大的灵活性和音频控制。
[0091]
在一些示例实施例中，当在切换到当前收听点/视点期间和/或之后继续回放来自先前收听点/视点的音频对象时，渲染器可以将该音频对象视为当前视点的一部分，持续至少在当前视点处继续回放音频对象的时间量。例如，当音频对象的回放继续时，音频对象可以被添加到第二收听点的音频对象的列表。在另一示例中，与来自先前视点/收听点的音频对象相关联的信令可以指示：如果在当前的视点/收听点处音频对象仍然在回放，则在一个或多个进一步的切换期间和/或之后该音频对象的回放将继续。如果进行了从当前收听点到下一视点/收听点的另一次切换(其可以包括切换回前一视点/收听点)，则可以相应地处理音频对象。以这种方式，实施例允许自适应地处理来自第一次收听的音频对象通过多个收听点/视点之间的多个切换。
[0092]
下面的表1描述了根据示例实施例的用于viewpointcollection的元数据。在这个示例中，使用了音频场景的基于对象的音频类型表示，但是，应当理解，其他表示也可能用于音频对象。
[0093][0094][0095]
表1
[0096]
上面的“disruption event parameters(中断事件参数)”列表可能包括例如以下一项或多项：
[0097]
·
delayedswitchpersist：在具有持久回放的切换期间用于执行到所连接的音频对象或元素的延迟切换的参数列表。
[0098]
·
switchdelaypersist：布尔型，其中该参数的值被设置以指示是否在给定时间(例如，由switchdelaypersisttime媒体时间参数定义)之后，将先前的视点的音频对象或元素的持久回放切换到所连接项目的回放。
[0099]
·
switchdelaypersisttime：时间参数，该参数的值被设置为相对于切换时间的媒体呈现开始时间。该时间定义在视点切换之后何时开始回放(例如淡入淡出)。可替换地，例如，回放最晚在例如由于音频波形用尽因此音频对象或元素的持续回放结束(类似地允许例如淡入淡出)，以先到者为准。
[0100]
·
switchafterpersist：布尔型，其中该参数的值被设置以指示音频先前视点的对象或元素的持续回放是否会覆盖所连接项目的回放直到其持续回放结束。此后，所连接音频对象或元素的回放被允许。
[0101]
·
switchoffpersist：布尔型，其中该参数的值被设置以指示先前视点的音频对象或元素的持久回放是否会覆盖所连接项目的回放。
[0102]
在一些示例中，中断事件响应(例如，由于中断事件导致的音频变化)可以根据受影响的音频元素的寿命或属性而持续。因此，可能会发生中断事件，其中只有音频场景中的附加源或修改后的变化源被传递到受影响的视点。
[0103]
注意，以上的元数据关键字、类型和描述仅是示例，并不旨在进行限制。例如，表1中描述的一些元数据可以是可选的，可以使用元数据关键字的不同名称，等等。
[0104]
渲染器实施方式
[0105]
音频内容渲染引擎通常对应于将呈现给用户的音频波形放在一起的软件。该呈现可以通过耳机或使用扬声器设置进行。音频内容渲染引擎可以例如在通用处理器或专用硬件上运行。
[0106]
现在参照图4，该图示出了根据示例实施例的高级过程流程图。例如，该过程可以在本地用户的音频内容呈现引擎中实现。
[0107]
在步骤s10，用户打开媒体文件，其中该媒体文件包括至少两个视点。可以在媒体文件被打开的同时执行步骤s15
‑
50。在步骤s15，获得当前视点并且更新视点信息。在一些示例中，可以基于用户输入来获得视点，例如用户提供输入以选择开始视点。或者，可以预先确定起始视点，诸如从媒体文件中读取或由ar用户跟踪系统给出。在步骤s20，在当前视点中获得用户位置和取向。在步骤s25，根据当前视点中确定的用户位置和取向获得音频流。在步骤s30，从远程用户获得附加的音频流和/或音频修改参数。在步骤s35，根据来自远程用户的附加音频流和/或音频修改参数，针对在当前视点中的用户位置和取向来修改在s25获得的音频流。在s40，将修改的音频流渲染并呈现给用户。在步骤s45，针对当前视点音频更新本地用户参数。在s50，如果在当前视点中存在远程用户，则针对当前用户视点更新公共视点参数。然后处理流程返回到步骤s15。
[0108]
虽然没有包括在图4，应当理解，本地用户的动作可以类似地影响远程用户。本地用户是指运行当前渲染实例的用户。远程用户是指在多用户内容消费中与本地用户连接的任何用户。因此，对于每个用户(本地用户)，其他用户因此是远程用户。与远程用户的连接可以与内容消费并行地建立。因此，在本地用户开始回放时不需要建立连接。例如，用户2可以“加入”由用户1开始并为用户1进行的多用户内容消费。
[0109]
还应注意，可以以不严格遵循用户的位置和/或取向的方式来修改音频流的渲染，但是也使用来自音频对象的元数据的附加信息(例如基于来自表1中的disruption event parameters(中断事件参数)的指令)。作为用户和音频对象之间的交互的非限制性示例，可以根据在6dof场景中的用户位置/取向来渲染特定的音频对象，直到用户达到距音频对象1
米的距离的限制，在该点，所述音频对象变得越来越非剧情性，并且进一步“黏附”用户，直到用户“逃脱”到默认音频对象位置的至少5米的距离。用户交互还可以涉及在交互式系统中的非常直接的交互，例如用户抓握、抬起或以其他方式触摸也是音频对象或与之相关的对象。
[0110]
现在参照图5，该图表示了多视点3dof+体验文件中两个用户之间的交互。在图5所示的例子中，假设每个视点包括至少一组音频源。另外，每个视点可以例如以分开的背景音乐为特色，该背景音乐可以与该视点的方面和艺术意图相关。此外，用户1和用户2可以例如经由低延迟通信编解码器接口彼此连接。用户或他们的化身可能彼此可见，也可能彼此不可见。用户彼此之间(在通信链接之外)可能有进一步交互，也可能没有进一步交互。尽管在图5的例子中仅示出了两个用户，但是这并不意图是限制性的，因为这里描述的特征适用于两个以上的用户。
[0111]
在图5中，第一个用户(“用户1”)启动了一个体验vr的应用并打开文件。如502所示，向用户1呈现第一视点a，其可以是例如该内容的默认起始视点或由用户1选择。第二用户(“用户2”)类似地打开该文件，连接到第一用户1，并选择503第一视点b。可替换地，当然，如果视点a是默认起点，则用户2也可以从a开始。在此示例中，用户1在视点a停留更长的时间，而用户2从视点b切换到视点a，如505所示，然后从视点a切换到视点c，如507所示。可替换地，用户2可以例如从视点b切换到视点c，而没有看到视点a，如511所示。最终，两个用户都切换到公共视点d，如504、509所示。
[0112]
由于多视点3dof+媒体文件的四个视点可以处于相同时间(例如，作为相同故事情节的一部分，以及以不同焦点推进故事/内容的单个视点)，因此可以理解，内容创建者可能希望将两个或更多个视点视为：完全独立、连接/“镜像”，或采用动态方式。动态方式可以是例如在视点a和视点b之间的关系，其可以取决于整个呈现或其一部分或至少一个用户动作的时间实例。用户动作可以例如与用户在内容中所做的事情，在特定视点上花费的时间量、视点切换的顺序等相关。从用户体验的角度来看，当有多个用户可以相互指示(例如，通过通信链接进行讨论)有关某个观点的信息时，情况就变得更加复杂，其中至少一个用户以前从未访问过、见过、遇到过和/或类似的观点。在这些情况下，可以提供以下选项，这些选项提供不同程度的指定内容创建者控制，这些选项将参考图5进行描述。
[0113]
选项1：可以提供多视点文件的简单切换实现，其中用户1和用户2在视点d中消费相同的内容。对于该实施方式，体验不考虑用户自己先前消费的内容，也不考虑至少第二用户的先前消费的内容。对于此技术，存在1)来自用户自身以前的体验不连续性的体验，以及2)至少一个第二用户的体验不连续性。
[0114]
选项2：根据另一个选项，每个用户都可以根据自己以前的内容消费来修改自己的用户体验。因此，例如，用户1可以继续在视点d中听到来自视点a的至少一个音频，作为对视点d的默认部分的至少一个音频的附加或替代。使用此技术允许从用户自己先前的体验连续的体验，但是仍然存在与至少一个第二个用户的不连续性。
[0115]
选项3：根据另一种技术，每个用户都可以根据自己先前的内容消耗和至少一个其他用户的内容消耗来修改自己的用户体验。因此，用户1可以例如在视点d中接收来自(用户1还没有访问过的)视点c的至少一个相关音频。该音频还可以与用户自己以前在视点a中的体验有关。这是基于用户2已经切换到公共视点d并且已经访问了视点c来选择的(因此使该
视点及其内容与共同体验相关)。在一些实施例中，与视点a有关的视点c的音频可能需要，例如，用于一起消费了视点a的至少两个用户(即，可能已经执行了公共视点参数更新)。这项技术既可以使用户自己以前的体验保持连续性，又可以使至少一个第二用户的体验保持连续性。在某些示例中，该技术可以应用于6dof连续漫游情况，在这种情况下，相互交互的用户过去的内容消费也可能不同。
[0116]
考虑针对选项3的以下示例，在用户1和用户2至少部分地一起观看的多视点故事情节中有两个角色john和jack。约翰和杰克在视点b相遇，只有用户2有体验。随后，john和jack在观点a上展开激烈的争论，用户1和用户2都体验到这一点。然后，在观点c中，jack制定了一个情节以寻求对john的报复，在此期间，在背景中播放了威胁性音乐。用户1没有访问或体验视点c。因此，如果用户1只是在消费内容并访问视点d，则用户1可能会认为jack出了点问题，但不会特别了解该情节，并且在视点d处可能听不到来自视点c的威胁性音乐。另一方面，用户2访问了视点c，因此知道了杰克的情节。此外，视点c的威胁性音乐的某些元素可用于为用户2修改视点d处的音频。例如，上面的选项3还允许以类似于为用户2修改音频的方式修改在视点d处用户1的音频，例如通过包括威胁性音乐的一些相同元素。例如，这可能使用户谈论音乐的变化，从而使一起消费的内容成为更有意义的体验。
[0117]
组合多个音频渲染
[0118]
图6a和6b示出了根据一些示例实施例的用于增强音频的示例框架。图6a的框架示出了来自基线音频解码器602的用于6dof媒体内容或多视点沉浸式音频内容的主要(或基线)音频流。主音频流由来自与例如附加服务有关的增强音频(解码器)604的增强音频流来增强。在图6a的示例中，主音频渲染器606
‑
1支持基线和增强音频流。在该示例中，主音频渲染器606
‑
1可以被配置为执行本文所述的一个或多个操作。音频的渲染被传递到音频输出607。
[0119]
如图6b示出了类似于图6a的示例框架。但也支持具有主音频渲染器606
‑
1不支持的格式的音频流。在该示例中，假定来自主音频渲染器606
‑
2不支持来自增强音频(解码器)604的增强音频流。主音频渲染器606
‑
2包括将不支持的音频流传递给外部渲染器610的接口608。来自主音频渲染器606
‑
2的音频渲染和音频渲染传递给渲染混合器612，后者混合音频并将混合的音频提供给音频输出607。或者，渲染混合器612可以在主音频渲染器606
‑
2内部实现。在此示例中，主音频渲染器606
‑
2和外部渲染器610可以被配置为执行本文所述的一个或多个操作。
[0120]
相关地，可以使用公共元数据基于第二音频(增强)来控制主音频(6dof)的呈现。但是，应注意的是，尽管内容创建者可以控制第一音频，但是通常对增强音频的控制是有限的或者没有控制，例如，用户生成的内容(例如实时移动设备捕获)可以是增强音频，因此，在某些示例中，可能不存在直接链接两个音频流的表1的完整元数据。因此，元数据还可以包括可以基于高级音频类型或角色元数据应用的一般规则，或者在未知增强音频的角色的情况下仅应用于增强音频的规则。在其他实施例中，服务可以基于音频增强的接收者消费的多视点音频来提供用于增强音频的音频元数据。
[0121]
例如，如图4中描述的过程也适用于与主音频的增强有关的这些附加使用情况，其中可以跳过步骤s50，因为至少两个用户消费不同的内容文件，因此通常从不在多视点内容的相同视点。
[0122]
图7是用于控制多视点全方位内容中的音频的逻辑流程图。该图进一步示出了根据示例性实施例的一种或多种示例性方法的操作，在计算机可读存储器上体现的计算机程序指令的执行结果，由在硬件中实现的逻辑执行的功能和/或用于执行功能的互连模块。例如，现实模块108
‑
1和/或108
‑
2可以包括图1中的多个块。参照图7，其中每个包括的块是用于执行块中的功能的互连模块。图7中的块被假设由装置100
‑
1执行，例如，至少部分地在现实模块108
‑
1和/或108
‑
2的控制下。
[0123]
根据示例实施例(可以称为示例1)，提供了一种方法，包括：如块700所示，接收包括多个视点的空间媒体内容文件；如块702所示，从所述多个视点中确定用于消费所述空间媒体内容文件的第一用户的第一视点；如块704所示，接收影响用于所述第一用户的所述第一视点的音频渲染的指示，其中所述指示与消费所述空间媒体内容文件的至少一个第二用户的一个或多个动作相关联；以及如块706所示，响应于接收所述指示，基于以下至少一项来控制用于所述第一用户的所述第一视点的音频渲染：所述第一用户的位置和/或取向，以及所述第二用户的所述一个或多个动作。
[0124]
另一个实施例的示例(可以称为示例2)是如示例1中所述的方法，其中，接收所述指示是基于以下之一：当所述至少一个第二用户存在于所述第一视点处时，所述第一用户进入所述第一视点；以及当所述第一用户存在于所述第一视点处时，所述至少一个第二用户进入所述第一视点。
[0125]
另一实施例的示例(可以称为示例3)是如示例1
‑
2中任何一个所述的方法，其中所述至少一个第二用户的所述一个或多个动作包括以下至少一个：在切换到所述第一视点之前，所述至少一个第二用户存在于多个视点中的所述一个或多个其他视点处；在切换到所述第一视点之前，所述至少一个第二用户访问所述多个视点中的所述一个或多个其他视点的顺序；在切换到所述第一视点之前，在所述多个视点中的所述一个或多个其他视点处花费的时间；所述至少一个第二用户与所述空间媒体内容文件的多个视点中的所述一个或多个视点中的虚拟对象和/或虚拟角色的用户交互；以及由所述至少一个第二用户在多个视点中的一个或多个感知的空间媒体内容文件中一个或多个事件的发生，其中所述一个或多个事件不是由第一用户感知。
[0126]
另一个实施例的示例(可以称为示例4)是如示例1
‑
3中任何一个所述的方法，其中控制用于所述第一用户的所述第一视点的音频渲染包括：基于与一个或多个第一音频对象相关联的信令，修改与所述第一视点相关联的所述一个或多个第一音频对象的渲染。
[0127]
另一个实施例的示例(可以称为示例5)是如示例1
‑
4中任何一个所述的方法，其中控制用于所述第一用户的所述第一视点的音频渲染包括：基于与一个或多个第二音频对象相关联的信令来渲染一个或多个第二音频对象，其中所述一个或多个第二音频对象与在切换到所述第一视点之前由所述至少一个第二用户先前访问的至少一个或多个其他视点相关联。
[0128]
另一实施例的一个示例(可以称为示例6)是如示例4
‑
5中的任何一个所述的方法，其中与所述一个或多个第一音频对象和/或所述一个或多个第二音频对象相关联的信令指示一个或多个条件，所述一个或多个条件涉及是否要渲染与信令相关联的音频对象，以及如何渲染与信令相关联的音频对象。
[0129]
另一个实施例的一个示例(可以称为示例7)是如示例1
‑
6中任何一个示例所述的
方法，还包括向所述第一用户呈现所述音频渲染。
[0130]
另一个实施例(可以称为示例8)是如示例1所述的方法，其中所接收的指示是事件的指示，其中该事件可以是破坏性事件。
[0131]
在示例实施例(可以称为示例9)中，提供了一种装置，包括：用于接收包括多个视点的空间媒体内容文件的模块；用于从多个视点确定用于消费所述空间媒体内容文件的第一用户的第一视点的模块；用于接收影响用于所述第一用户的第一视点的音频渲染的指示的模块，其中所述指示与消费所述空间媒体内容文件的至少一个第二用户的一个或多个动作相关联；用于响应于接收所述指示，基于以下至少一项来控制用于所述第一用户的所述第一视点的音频渲染的模块：所述第一用户的位置和/或取向，以及所述第二用户的所述一个或多个动作。
[0132]
另一个实施例的示例(可以称为示例10)是如示例9中所述的装置，还包括用于执行如示例2
‑
8中的任何一个所述的方法的模块。
[0133]
另一个实施例的示例(可以称为示例11)是一种计算机可读介质，包括用于使装置至少执行以下操作的程序指令：接收包括多个视点的空间媒体内容文件；从多个视点确定用于消费所述空间媒体内容文件的第一用户的第一视点；接收影响用于所述第一用户的第一视点的音频渲染的指示，其中，所述指示与消费所述空间媒体内容文件的至少一个第二用户的一个或多个动作相关联；响应于接收所述指示，基于以下至少一项来控制用于所述第一用户的所述第一视点的音频渲染：所述第一用户的位置和/或取向，以及所述第二用户的所述一个或多个动作。
[0134]
另一个实施例的一个示例(可以称为示例12)是示例11中的计算机可读介质，其中所述程序指令还使所述装置执行如示例2
‑
8中任何一个所述的方法。
[0135]
在示例实施例(可以称为示例13)中，提供了一种装置，包括：至少一个处理器；以及包括计算机程序代码的至少一个非暂时性存储器，所述至少一个存储器和所述计算机程序代码被配置为与所述至少一个处理器一起使所述装置执行操作，所述操作包括：接收包括多个视点的空间媒体内容文件；从多个视点确定用于消费所述空间媒体内容文件的第一用户的第一视点；接收影响用于所述第一用户的第一视点的音频渲染的指示，其中，所述指示与消费所述空间媒体内容文件的至少一个第二用户的一个或多个动作相关联；以及响应于接收所述指示，基于以下至少一项来控制用于所述第一用户的所述第一视点的音频渲染：所述第一用户的位置和/或取向，以及所述第二用户的所述一个或多个动作。
[0136]
另一个实施例的示例(可以称为示例14)是如示例13中所述的装置，其中，该装置被进一步致使执行如示例2
‑
8中的任何一个所述的方法。
[0137]
在不以任何方式限制下面出现的权利要求的范围、解释或应用的情况下，本文公开的一个或多个示例实施例的技术效果是允许多个用户通过一组不同的视点观看沉浸式内容，并因此对所述多视点媒体内容/文件渲染/呈现提供改进的音频场景控制。这与传统内容不同，传统内容中两个用户仅需要及时同步才能拥有共同的内容消费体验。本文公开的一个或多个示例实施例的另一技术效果是，通过使得能够在例如考虑到用户的内容和视点选择以及其他用户的动作的主题段落内部和之间实现平滑/自然过渡，为最终用户提供响应个人使用场景的更连贯和沉浸式的用户体验。本文公开的一个或多个示例实施例的另一技术效果是，基于新颖的元数据信令和相关联的处理，使得一个媒体文件能够基于由共
享内容消费中的多个用户中的至少一个用户触发的破坏性事件来实现不同的个性化内容体验。个性化内容体验可以是，例如，用户感觉他们先前已经看过和做过的事直接与他们当前的体验直接相关。用户可以通过例如经由时间和/或空间上的不同路径消费内容两次来验证这一点。高级的个性化体验不仅考虑了第一用户的存在和动作，而且还考虑了在体验共同内容消费时至少第二用户的存在和动作。通过这种方式，到达共同视点的两个用户可能会一起体验到比他们自己独自体验到的更多的东西。本文公开的一个或多个示例实施例的另一技术效果是将在这样的多用户内容消费中使用的至少两个媒体文件中的体验进行组合。
[0138]
本文中的实施例可以用软件(由一个或多个处理器执行)、硬件(例如，专用集成电路)或软件和硬件的组合来实现。在示例实施例中，软件(例如，应用逻辑、指令集)被保持在各种常规计算机可读介质中的任何一种上。在本文的上下文中，“计算机可读介质”可以是可以包含、存储、通信、传播或传输指令的任何介质或装置，所述指令由指令执行系统、装置或设备(例如计算机，例如在图1中描述和描绘的计算机的一个例子)使用或与其结合使用。计算机可读介质可以包括计算机可读存储介质(例如，存储器104或其他设备)，该计算机可读存储介质可以是可以包含、存储和/或传输指令以供指令系统、装置或装备(例如计算机)使用或与其结合使用的任何介质或装置。计算机可读存储介质不包括传播信号。
[0139]
如果需要，可以以不同的顺序和/或彼此同时地执行本文讨论的不同功能。此外，如果需要，上述功能中的一个或多个可以是可选的或可以被组合。
[0140]
尽管在独立权利要求中阐述了本发明的各个方面，但是本发明的其他方面包括来自所描述的实施例和/或从属权利要求的特征与独立权利要求的特征的其他组合，而不仅是权利要求中明确阐述的组合。
[0141]
在此还应注意，尽管以上阐述了本发明的示例实施例，但是这些描述不应以限制性的意义来理解。而是，在不脱离所附权利要求书所限定的本发明的范围的情况下，可以进行多种变型和修改。