用于提供媒体服务的方法和装置

技术领域

本公开大体上涉及提供媒体服务，且更明确地说，涉及一种用于支持用于虚拟现实(VR)、增强现实(AR)或混合现实(MR)服务中的至少一者的新媒体格式的方法和装置。

背景技术

第五代(5G)移动通信技术定义了宽频带，使得高传输速率和新服务是可能的，并且不仅可以在诸如3.5GHz的“Sub 6GHz”频带中实现，而且可以在被称为毫米波的“Above6GHz”频带中实现，其包括28GHz和39GHz。此外，已经考虑在太赫兹频带(例如，95GHz至3THz频带)中实现第六代(6G)移动通信技术(被称为超5G系统)，以便实现比5G移动通信技术快50倍的传输速率和5G移动通信技术的十分之一的超低延迟。

在5G移动通信技术发展的初期，为了支持服务并满足与增强型移动宽带(eMBB)、超可靠低等待时间通信(URLLC)和海量机器类型通信(mMTC)有关的性能要求，已经进行了：关于波束成形和海量多输入多输出(MIMO)的标准化，以减轻无线电波路径损耗和增加毫米波中的无线电波传输距离；支持用于有效地利用毫米波资源和时隙格式的动态操作的参数集(例如，操作多个子载波间隔)；支持多波束传输和宽带的初始接入技术；带宽部分(BWP)的定义和操作；新的信道编码方法，诸如用于大量数据传输的低密度奇偶校验(LDPC)码和用于控制信息的高度可靠传输的极性码；L2预处理；以及网络切片，用于提供专用于特定服务的专用网络。

目前，就5G移动通信技术所支持的服务而言，正在进行关于初始5G移动通信技术的改进和性能增强的讨论，并且已经进行了关于诸如以下技术的物理层标准化：车辆对所有人(V2X)技术，用于基于关于车辆所传输的车辆的位置和状态的信息来帮助自主车辆的驾驶确定，并提高用户的便利性；新的无线电未许可(NR-U)，旨在使系统操作符合未许可频带中的各种规章相关要求；NR用户设备(UE)功率节省；非地面网络(NTN)，其是UE卫星直接通信，用于在与地面网络的通信不可用的区域中提供覆盖；以及定位。

此外，正在进行关于诸如以下技术的空中接口体系结构/协议中的标准化：工业物联网(IIoT)，用于通过与其他行业互通和融合来支持新服务的技术；集成接入和回程(IAB)，通过以集成方式支持无线回程链路和接入链路来提供节点用于网络服务区域扩展；包括条件切换和双活动协议栈(DAPS)切换的移动性增强；以及两步随机接入，用于简化随机接入过程(针对NR的两步随机接入信道RACH)。在系统架构/服务中关于5G基线架构(.ge.g，基于服务的架构或基于服务的接口)也在进行着标准化，以组合网络功能虚拟化(NFV)和软件定义的网络(SDN)技术，以及用于基于UE位置接收服务的移动边缘计算(MEC)。

由于5G移动通信系统是商业化的，连接的设备(其数量成指数地增加)将连接到通信网络，并且因此预期5G移动通信系统的增强的功能和性能以及连接的设备的集成操作将是必需的。为此，关于以下技术的新研究被提上日程：扩展现实(XR)，用于有效地支持AR、VR、MR等；通过利用人工智能(AI)和机器学习(ML)的5G性能改进和复杂度降低；AI服务支持；元服务支持；以及无人机通信。

此外，5G移动通信系统的发展将不仅作为用于发展以下技术的基础：新波形，用于提供6G移动通信技术的太赫兹频带中的覆盖；多天线传输技术，例如全维MIMO(FD-MIMO)、阵列天线和大规模天线；基于超材料的透镜和天线，用于改善太赫兹频带信号的覆盖；使用轨道角动量(OAM)的高维空间复用技术；以及可重构智能表面(RIS)，也将作为发展以下技术的基础：全双工技术，用于提高6G移动通信技术的频率效率并改善系统网络；基于AI的通信技术，用于从设计阶段利用卫星和AI并内化端到端AI支持功能来实现系统优化；以及下一代分布式计算技术，用于利用超高性能通信和计算资源实现复杂度超过UE运行能力极限的服务。

VR、AR和MR中的一大挑战是需要支持用于这种服务的新媒体格式。

发明内容

[技术问题]

需要用于支持多个AR或VR对象媒体数据的流传输的过程，或用于支持包含多个媒体数据分量的媒体数据的适配流传输(包括分量级适配流传输)的过程。

[技术方案]

本公开涉及用于支持较高数据传输速率的5G或6G通信系统。根据实施例，该方法包括基于从AR/MR应用获得的URL信息从服务器接收SD，处理SD，基于处理的SD为场景的媒体对象配置至少一个媒体缓冲器流水线，以及为媒体对象的分量建立传输会话。

附图说明

从以下结合附图的描述中，本公开的某些实施例的上述和其它方面、特征和优点将变得更加明显，其中：

图1是示出传统视频流服务的服务过程的流程图；

图2是示出根据实施例的以SD作为服务入口点的VR/AR/MR服务的服务过程的流程图；

图3是示出图2所示的“处理SD”步骤的图；

图4是描述由节点表示描述的典型SD的图；

图5是示出根据实施例的AR/MR媒体播放器内的实体的典型结构的图，该AR/MR媒体播放器支持使用SD的媒体的回放；

图6是示出根据实施例的AR/MR媒体播放器内的实体的架构的图，该AR/MR媒体播放器支持使用SD的媒体的回放；

图7是示出根据实施例的以SD作为服务入口点的VR/AR/MR服务的服务过程的流程图；

图8是示出图7中所示的“处理SD”步骤的图；

图9是示出根据实施例的以场景清单作为服务入口点的VR/AR/MR服务的服务过程的流程图；

图10是示出图9所示的“处理场景清单”步骤的图；

图11是示出根据实施例的以场景清单作为服务入口点的VR/AR/MR服务的服务过程的流程图；

图12是示出图11所示的“处理场景清单”步骤的图；以及

图13是根据实施例的实体的框图。

具体实施方式

[最佳模式]

本公开的一个方面是提供用于AR服务流和入口点的方法和装置。由于因特网和网络条件的带宽可用性不一致，传统的二维(2D)视频流服务可以使用适配机制来流传输，以便将预先调整(适配)的媒体内容传递到当前网络条件。

本公开的另一方面是提供用于VR/AR/MR媒体流传输过程的多个实施例。除了场景描述(SD)流传输之外，这样的实施例还支持下面描述的体积媒体流传输。

本公开的另一方面是提供支持使用这些过程在不同级别(SD、清单、媒体流水线)上适配这些媒体服务的实施例。提供可用于SD(glTF项)选择、(场景)清单选择和流水线适配选择的不同上下文标准。

根据实施例，提供了一种由客户端执行的方法。基于从AR/MR应用获得的统一资源定位符(URL)信息从服务器接收SD；处理SD；基于处理后的SD为场景的媒体对象配置至少一个媒体缓冲流水线；为媒体对象的分量建立传输会话。

根据实施例，提供了一种由基站执行的方法。基于与AR/MR应用相关的URL信息向客户端发送SD；与客户端建立用于场景的媒体对象的分量的传输会话，其中，用于对象的媒体缓冲器流水线在客户端基于SD被配置。

根据实施例，提供了一种客户端。客户端包括收发器；以及处理器，其与收发器联接并且被配置为：基于从AR/MR应用获得的URL信息从服务器接收SD，处理SD，基于所处理的SD为场景的媒体对象配置至少一个媒体缓冲器流水线，以及为媒体对象的分量建立传输会话。

根据实施例，提供了一种服务器。服务器包括收发器；以及处理器，其与收发器联接并且被配置为：基于与AR/MR应用相关的URL信息向客户端发送SD；以及与客户端建立用于场景的媒体对象的分量的传输会话，其中用于对象的媒体缓冲器流水线在客户端基于SD被配置。

[发明模式]

在整个公开中，表述“a、b或c中的至少一个”表示仅a、仅b、仅c、a和b两者、a和c两者、b和c两者、所有的a、b和c，或其变体。在整个说明书中，层(或层装置)也可以被称为实体。在下文中，将参考附图详细描述本公开的操作原理。在以下描述中，不详细描述众所周知的功能或配置，因为其将用不必要的细节来模糊本公开。

本说明书中使用的术语是考虑本公开中使用的功能来定义的，并且可以根据用户或运营商的意图或通常使用的方法来改变。因此，基于本说明书的整个描述理解术语的定义。

出于相同的原因，在附图中，一些元件可能被夸大、省略或粗略地示出。此外，每个元件的大小不精确地对应于每个元件的实际大小。在每个附图中，相同或对应的元件用相同的附图标记表示。

通过参考以下实施例的详细描述和本公开的附图，可以更容易地理解本公开的优点和特征以及实现本公开的方法。然而，本公开可以以许多不同的形式来体现，并且不应被解释为限于本文所述的实施例。相反，提供本公开的这些实施例以便本公开将是彻底和完整的，并且将本公开的概念完全传达给本领域普通技术人员。因此，本公开的范围由所附权利要求限定。在整个说明书中，相同的附图标记表示相同的元件。应当理解，流程图中的块或块的组合可以由计算机程序指令来执行。因为这些计算机程序指令可以被加载到通用计算机、专用计算机或另一可编程数据处理装置的处理器中，所以由计算机或另一可编程数据处理装置的处理器执行的指令创建用于执行流程图块中描述的功能的单元。

计算机程序指令可以存储在计算机可用或计算机可读存储器中，所述计算机可用或计算机可读存储器能够指导计算机或另一可编程数据处理装置以特定方式实现功能，并且因此存储在计算机可用或计算机可读存储器中的指令也能够产生包含用于执行流程图块(一个或多个)中描述的功能的指令单元的制品。计算机程序指令还可以被加载到计算机或其它可编程数据处理设备中，并且因此，当在计算机或者其它可编程数据处理设备中执行一系列操作时，用于通过生成计算机执行的处理来操作计算机或其它可编程数据处理设备的指令可以提供用于执行流程图块(一个或多个)中描述的功能的操作。

此外，每个块可以表示包括用于执行指定逻辑功能的一个或多个可执行指令的模块、段或代码的一部分。还要注意，在一些替换实现中，块中提到的功能可以无序地发生。例如，两个连续的块也可以根据与其对应的功能同时执行或以相反的顺序执行。

如本文所使用的，术语“单元”可以指软件元件或硬件元件，诸如现场可编程门阵列(FPGA)或专用集成电路(ASIC)，并且执行特定的功能。然而，术语“单元”不限于软件或硬件。“单元”可以形成在可寻址存储介质中，或者可以形成为操作一个或多个处理器。因此，例如，术语“单元”可以包括元件(例如，软件元件、面向对象的软件元件、类元件和任务元件)，进程，函数，属性，过程，子例程，程序代码段，驱动器，固件，微代码，电路，数据，数据库，数据结构，表，阵列或变量。

由元件和“单元”提供的功能可以被组合成较小数量的元件和“单元”，或者可以被划分成额外的元件和“单元”。此外，元件和“单元”可以被实现为在设备或安全多媒体卡中再现一个或多个中央处理单元(CPU)。此外，在本公开的实施例中，“单元”可以包括至少一个处理器。

在本公开的以下描述中，不详细描述公知的功能或配置，因为它们将用不必要的细节模糊本公开。

在整个说明书中，用于提供媒体服务的功能或装置或服务器也可以被称为实体。

多媒体的最新进展包括对多媒体的捕获，这种多媒体(格式)的存储，这种多媒体的压缩(编解码器等)以及以可以向用户提供更沉浸的多媒体体验的新设备的形式呈现这种多媒体的研究和开发。随着对视频的较高分辨率(即8K分辨率)的追求，以及这种8K视频在具有诸如高动态范围(HDR)的沉浸技术的更大的电视(TV)显示器上的显示，大量多媒体消费的焦点已经转移到使用诸如移动智能电话和平板电脑的便携式设备的更加个性化的体验。沉浸式多媒体的另一个趋向分支是VR和AR。这种VR和AR多媒体通常要求用户佩戴相应的VR或AR头戴式耳机或眼镜(例如AR眼镜)，其中用户的视觉被虚拟世界包围，或者其中用户的视觉和环境被多媒体增强，所述多媒体可以或可以不被定位到他/她的环境中，使得它们看起来是真实世界环境的一部分。

VR、AR和MR中的一个大挑战是需要支持用于这种服务的新媒体格式。传统的2D视频不足以提供诸如VR、AR和MR之类的沉浸式服务。这样，诸如网格、点云和其它基于对象的媒体格式的体积媒体(格式)是必需的，以便提供六个自由度(6DoF)的沉浸式媒体体验。这种体积媒体可以是计算机生成的(例如，类似于图形)，或者可以通过不同的相机技术和配置(例如，布置成使得可以创建真实体积点云的多个相机)从真实对象/人捕获。传统2D视频通常由单个媒体比特流(例如，高效视频编码(HEVC)比特流或高级视频编码(AVC)比特流)组成，所述媒体位在解码和再现之前经由解码器缓冲器流水线被馈送到解码器中。然而，对于体积媒体，取决于所使用的格式，一个体积媒体对象可能需要多个媒体(或元数据)分量比特流，在将所述多个媒体(或元数据)分量比特流处理成一个可呈现媒体对象之前，将所述多个媒体(或元数据)分量比特流馈送到不同媒体缓冲器流水线中。这种示例是基于MPEG视频的点云压缩(V-PCC)内容，其包括多个分量，例如补丁信息、占用信息、几何信息、纹理(属性)信息和其它元数据信息。

与传统的2D视频服务不同，除了这些单独的体积媒体之外，存在多个体积媒体对象一起创建整个VR/AR/MR体验的许多场景。在这种情况下，需要能够将不同的体积媒体对象胶合并组成在一起的描述格式。这种描述格式是SD。SD描述了其中放置用户和体积媒体(对象)两者的场景。一旦构成场景，用户的视图就可以根据他/她的设备的姿势(位置和方向)来呈现(作为2D帧，通过截头锥体剔除)。

总之：

与2D视频相比，VR/AR/MR体积媒体具有新的特性，即：

体积媒体对象可以由需要多个流水线的多个比特流组成

VR/AR/MR服务可以包括需要SD的多个体积媒体对象

关于这种VR/AR/MR服务与5G相关的特性，由于体积媒体的固有3D特性，以及由于VR/AR/MR服务的用户可用的6个自由度(vs.2D视频的1个DoF)，流传输体积媒体需要巨大的带宽。

图1是示出从3GPP TS26.5015GMSAv16.6.1图5.2-2取得的传统视频流服务的服务过程的流程图。

图中的详细过程也在3GPP TS26.5015GMSA v16.6.1图5.2-2中详细描述。

通常，与媒体服务入口点相关的步骤：

5)一旦开始媒体回放，媒体应用将清单的URL提供给媒体播放器。

6)媒体播放器在步骤5中指定的URL处为清单建立传输会话。

7)媒体播放器使用步骤5中指定的URL，通过步骤6中的传输会话，向应用服务请求清单(DASH媒体呈现描述(MPD))。

9)一旦媒体播放器接收到DASH MPD，它就处理MPD以便选择服务会话所需的必要适配参数和媒体数据(这包括识别媒体数据的所有可能适配的位置，以及选择用于流传输的相关适配)。

12)媒体播放器然后根据在步骤9的处理中选择的从MPD指定的适配参数和媒体来配置回放流水线。

使用与图1中相同的过程，通过在由图1中的媒体播放器请求和接收的清单内包括作为选项的媒体数据，可以从组件AR对象传送媒体数据。然而，该过程不支持多个AR对象媒体数据的流传输，或包含多个媒体数据分量的媒体数据的适配流传输(包括分量级适配流传输)。

图2是示出根据实施例的用于具有SD(例如，glTF项、JSON文档)作为服务入口点的VR/AR/MR服务的服务过程的流程图，其中SD还直接包含用于服务媒体对象和/或流水线的可能的适配信息。

这里，当与图1比较时，媒体应用和媒体应用提供者分别由AR/MR应用和AR/MR应用提供者代替。这种命名不是限制性的，并且支持VR/AR/MR服务的媒体应用/媒体应用提供者也是可能的。此外，入口点使用SD而不是DASH MPD。可以使用的典型SD是glTF文件或项目，如图4所示。图4描述了由节点表示描述的典型SD。该SD是glTF项，具有支持MPEG媒体的扩展节点。该图基于用于MPEG媒体的ISO/IEC 23090-14SD。

通常，与媒体服务入口点相关的步骤与图1中的步骤不同：

5)一旦开始媒体回放，媒体应用将SD的URL提供给媒体播放器。该URL指向SD(glTF项)。

6)媒体播放器在步骤5中指定的URL处为SD建立传输会话。

7)媒体播放器使用在步骤5中指定的URL并且通过步骤6中的传输会话向应用服务请求SD(glTF项)。

9)一旦媒体播放器接收到SD(glTF项)，它就处理SD以便选择场景所需的必要媒体数据，包括适配参数。

12)然后，媒体播放器根据从SD指定的媒体格式如由媒体播放器从步骤9的处理中选择的那样来配置多个媒体缓冲器流水线。

13)媒体播放器可以为内容指定多个传输会话，例如为每个媒体缓冲器流水线指定单独的传输会话，如图6所示。取决于服务，某些传输会话还可以支持以多个媒体流水线为目标的复用媒体数据。

图3是说明图2中所示的“处理SD”步骤的图。

媒体播放器可以被进一步定义为媒体访问功能和呈现引擎组件。

在该实施例中，处理SD(glTF项)的过程可以被描述为：

9a)呈现引擎根据来自SD的合成信息以及用户(或AR设备)的姿势和姿势信息(其包括其位置和方向，并且还可以考虑设备的处理能力，例如深度范围、显示范围等)来确定场景的合成需要哪些媒体对象。

9b)对于在9a中由呈现引擎识别的媒体对象，媒体访问功能根据SD中的信息识别需要哪些媒体格式和媒体分量。

9c)对于在9b中识别的每个所需的媒体分量，识别和处理每个媒体分量的获取数据(这包括识别媒体分量数据的所有可能的适配的位置，以及选择用于流传输的相关适配)，该获取数据可以以针对每个媒体分量或分量组的清单(例如DASH MPD)的形式存在。

在步骤12中，媒体访问功能根据所识别和所需要的媒体分量的数量来配置媒体播放器中的媒体缓冲器流水线(在媒体访问功能和呈现引擎之间)，如图6所示。

图5是示出基于ISO/IEC 23090-14的支持使用SD回放媒体的AR/MR媒体播放器内的实体的典型结构的图。

glTF(SD)呈现引擎呈现来自相应的媒体缓冲器的单独的媒体，同时媒体访问功能建立和配置将相应的媒体分量馈送到呈现引擎缓冲器的必要媒体(缓冲器)流水线。

还支持MPEG媒体(如在ISO/IEC 23090-14中)的典型SD(glTF项)包含关于可用的不同媒体对象的信息，以及对应于可用的媒体对象的不同媒体分量(在适用的情况下，取决于所使用的媒体格式)。它也包括场景中不同媒体对象的基本合成信息。根据用户姿势，一旦媒体播放器识别出在用户姿势下创建和呈现场景所需的媒体对象，媒体访问功能将为媒体/媒体分量配置必要的流水线，并将它们链接到获取实际媒体数据的相应媒体客户端(这些媒体客户端可以是多个媒体客户端，这取决于正被获取的媒体分量的媒体格式)。

图6是示出支持使用SD回放媒体的AR/MR媒体播放器内的实体的架构的图。图6示出了与图5相同的体系结构，但是突出了如本公开所述的(媒体)缓冲器流水线的圆顶。

图7是示出根据本公开的另一实施例的以SD(例如，glTF项、JSON文档)作为服务入口点的VR/AR/MR服务的服务过程的流程图，其中SD包含指向后续清单的指针(例如，URL)，所述后续清单包含支持不同级别(例如，媒体(缓冲器)流水线、对象级别适配等)的适配的适配信息。

这里，当与图2比较时，媒体播放器首先接收的SD不包含获取实际媒体数据(或媒体分量数据)所需的获取数据。这样，为了获取与所需媒体(分量)数据相关的清单，需要进一步的过程(步骤11到14)。

通常，在本实施例中，与媒体服务入口点有关的步骤：

5)一旦开始媒体回放，媒体应用将SD的URL提供给媒体播放器。该URL指向SD(glTF项)。

6)媒体播放器在步骤5中指定的URL处为SD建立传输会话。

7)媒体播放器使用在步骤5中指定的URL并且通过步骤6中的传输会话向应用服务请求SD(glTF项)。

9)一旦媒体播放器接收到SD(glTF项)，它就处理SD以便选择场景所需的必需媒体(分量)数据。

11)媒体播放器建立一个或多个传输会话，用于传递在步骤9中选择的所选媒体(分量)数据所需的清单。或者，媒体播放器可以使用在步骤6中建立的传输会话来请求清单。

12)媒体播放器使用SD中的相应信息(例如清单的URL，清单可以是DASH MPD的形式或类似的形式)来请求媒体(分量)数据的清单。

14)一旦媒体播放器接收到清单(例如，DASH MPD)，它就处理清单以便选择服务会话所需的必要适配参数和媒体(分量)数据。

17)然后，媒体播放器根据从SD指定的媒体格式并且如由媒体播放器从步骤9的处理中选择的那样来配置多个媒体缓冲器流水线。

18)媒体播放器可以为内容指定多个传输会话，例如为每个媒体缓冲器流水线指定单独的传输会话，如图6所示。取决于服务，某些传输会话还可以支持以多个媒体流水线为目标的复用媒体数据。

图8是说明图7中所示的“处理SD”步骤的图。媒体播放器可以被进一步定义为媒体访问功能和呈现引擎组件。在该实施例中，处理SD(glTF项)的过程可以被描述为：9a)呈现引擎根据来自SD的合成信息以及用户(或AR设备)的姿势和姿势信息(包括其位置和方向，并且还可以考虑设备的处理能力，例如，深度范围、显示范围等)来确定场景的合成需要哪些媒体对象。

9b)对于在9a中由呈现引擎识别的媒体对象，媒体访问功能根据SD中的信息识别需要哪些媒体格式和媒体分量。

9c)对于在9b中识别的每个所需的媒体分量，识别出指向媒体分量的位置的清单的位置(例如，URL)。

14)一旦接收到所需媒体分量的清单，媒体访问功能就处理这些清单，以便选择服务会话所需的必要适配参数和媒体(分量)数据(这包括识别媒体分量数据的所有可能适配的位置，以及选择用于流传输的相关适配)。

在步骤17中，媒体访问功能根据所识别和所需要的媒体分量的数量来配置媒体播放器中的媒体缓冲器流水线(在媒体访问功能和呈现引擎之间)，如图6所示。

图9是示出根据另一实施例的以场景清单(其可以包含多个glTF项以及附加选择标准元数据)作为服务入口点的VR/AR/MR服务的服务过程的流程图，其中场景清单包含SD，并且其中场景清单或SD包含用于直接获取服务媒体对象和/或流水线的可能的适配信息。

该场景清单还可以包含可以用作选择在场景清单中指定的媒体数据或媒体分量的选择标准的上下文信息。

场景清单上下文元数据用于基于上下文的选择

场景清单内的这些数据可以包括：

·可以获取特定glTF项或媒体数据并将其显示给用户的真实世界位置(例如，GPS坐标或范围)。

°例如，当她/他在房间A中时，为用户获取一组媒体数据，并且

当她/他在不同的房间B中时，为用户获取一组不同的媒体数据。

•对可以获取特定glTF项或媒体数据并将其显示给用户的位置的限制。

·例如，当用户处于特定位置或环境/区域时，不能获取和观看一组媒体数据。

·可选择的独立glTF项或媒体数据组的列表，其可以在一个或多个特定的真实世界位置处被获取和显示给用户。

ο例如，用户选择两个或多个媒体数据组的选项，每组对应于当她/他在相同的环境(例如房间)中时分别的体验。

·基于用户和对象增强位置(内容注册位置/表面)之间的距离的，对能够被获取并显示给用户的glTF项/媒体数据的距离限制。

ο例如，在埃菲尔塔的近处，可以获取与挂在塔上的广告相对应的媒体数据，而在埃菲尔塔的远处，可以获取与围绕埃菲尔塔的飞行对象相对应的不同媒体数据。

·资源能力元数据，其指示获取和呈现glTF项或媒体数据所必需的近似资源。

ο例如，一组glTF项/媒体数据可以以低处理功率/低电池消耗设备(模式或设置)为目标，而另一组glTF项/媒体数据可以以高处理功率设备(模式或设置)为目标。这两组内容可以包含或可以不包含相同的媒体内容-如果它们包含相同的内容，则它们可以包含指向对相同内容的不同适配的指针(URL)，例如分辨率、点数、细节级别、纹理细节等的差异。

通常，在本实施例中，与媒体服务入口点有关的步骤：

5)一旦开始媒体回放，媒体应用将场景清单的URL提供给媒体播放器。该URL指向场景清单，该场景清单可以包含多个SD(多个glTF项)，以及与SD和/或SD内的媒体数据相关的相应上下文元数据。

6)媒体播放器在步骤5中指定的URL处为场景清单建立传输会话。

7)媒体播放器使用在步骤5中指定的URL通过步骤6中的传输会话向应用服务请求场景清单。

9)一旦媒体播放器接收到场景清单，它就处理该场景清单来选择必要的媒体数据(考虑到场景所需要的上下文元数据，并且还包括适配参数)。

12)然后，媒体播放器根据从场景清单中指定的并且由媒体播放器从步骤9的处理中选择的SD和媒体格式来配置多个媒体缓冲器流水线。

13)媒体播放器可以为内容指定多个传输会话，例如为每个媒体缓冲器流水线指定单独的传输会话，如图6所示。取决于服务，某些传输会话还可以支持以多个媒体流水线为目标的复用媒体数据。

图10是说明图9中所示的“处理场景清单”步骤的图。

媒体播放器可以被进一步定义为媒体访问功能和呈现引擎组件。在该实施例中，处理场景清单(其可以包含多个SD(glTF项)以及上下文元数据和媒体对象)的过程可以被描述为：

9a)呈现引擎基于也在场景清单内携带的上下文元数据来选择场景清单内的SD(glTF项)和/或媒体对象。用于选择的这些上下文中的一些还可以考虑用户设备特性，诸如设备位置、距特定位置(例如，增强位置)的设备距离、设备资源/处理能力、或其它标准(与以上定义的场景清单上下文元数据相关或不相关)。

9b)一旦在步骤9a中选择了呈现清单内的SD/媒体对象，则呈现引擎根据来自SD的合成信息以及用户(或AR设备)的姿势和姿势信息(包括设备的位置和方向，并且还可以考虑设备的处理能力，例如深度范围、显示范围等)来确定场景的合成需要哪些媒体对象。

9c)对于在9b中由呈现引擎识别的媒体对象，媒体访问功能根据SD/场景清单中的信息来识别需要哪些媒体格式和媒体分量。

9d)对于在9b中识别的每个所需的媒体分量，识别和处理每个媒体分量的获取数据(这包括识别媒体分量数据的所有可能的适配的位置，以及选择用于流传输的相关适配)，该获取数据可以以针对每个媒体分量或分量组的清单(例如DASH MPD)的形式存在。

在步骤12中，媒体访问功能根据所识别和所要求的媒体分量的数量来配置媒体播放器中的媒体缓冲器流水线(在媒体访问功能和呈现引擎之间)，如图6所示。

图11是示出根据另一个实施例的具有以服务入口点的场景清单(其可以包含多个glTF项，以及附加的选择标准元数据)的VR/AR/MR服务的服务过程的流程图，其中所述场景清单包含SD，并且其中所述一个或多个场景清单仅包含指向后续清单的指针(例如，URL)，所述后续清单包含支持不同级别适配(例如，媒体(缓冲器)流水线级适配、对象级适配等)的适配信息。

该场景清单还可以包含上下文信息元数据，该上下文信息元数据可以用作选择在场景清单中指定的媒体数据或媒体分量的选择标准，如在图9的描述中所描述的。

这里，当与图9比较时，首先由媒体播放器接收的场景清单不包含获取实际媒体数据(或媒体分量数据)所需的获取数据(无论是直接在场景清单内部，还是在场景清单内部的SD内部)。这样，为了获取与所需媒体(分量)数据相关的清单，需要进一步的过程(步骤11到14)。

通常，在本实施例中，与媒体服务入口点有关的步骤：

5)一旦开始媒体回放，媒体应用将场景清单的URL提供给媒体播放器。该URL指向场景清单，该场景清单可以包含多个SD(多个glTF项)，以及与SD和/或SD内的媒体数据相关的相应上下文元数据。

6)媒体播放器在步骤5中指定的URL处为场景清单建立传输会话。

7)媒体播放器使用在步骤5中指定的URL通过步骤6中的传输会话向应用服务请求场景清单。

9)一旦媒体播放器接收到场景清单，它就处理场景清单，以便考虑上下文元数据来选择场景所需的必要的SD和媒体数据。

11)媒体播放器建立一个或多个传输会话，用于传递在步骤9中选择的所选媒体(分量)数据所需的清单。或者，媒体播放器可以使用在步骤6中建立的传输会话来请求清单。

12)媒体播放器使用SD中的相应信息(例如清单的URL，其可以是DASH MPD的形式或类似的形式)来请求媒体(分量)数据的清单。

14)一旦媒体播放器接收到清单(例如，DASH MPD)，它就处理清单以便选择服务会话所需的必要适配参数和媒体(分量)数据。

17)然后，媒体播放器根据从SD指定且由媒体播放器从步骤9的处理中选择的媒体格式来配置多个媒体缓冲器流水线。

18)媒体播放器可以为内容指定多个传输会话，例如为每个媒体缓冲器流水线指定单独的传输会话，如图6所示。取决于服务，某些传输会话还可以支持以多个媒体流水线为目标的复用媒体数据。

图12是示出图11中所示的“处理场景清单”步骤的图。媒体播放器可以被进一步定义为媒体访问功能和呈现引擎组件。在该实施例中，处理SD(glTF项)的过程可以被描述为：

9a)呈现引擎基于也在场景清单内携带的上下文元数据来选择场景清单内的SD(glTF项)和/或媒体对象。用于选择的这些上下文中的一些还可以考虑用户设备特性，例如设备位置、距特定位置(例如，增强位置)的设备距离、设备资源/处理能力、或其它标准(与以上定义的场景清单上下文元数据相关或不相关)。

9b)一旦在步骤9a中选择了呈现清单内的SD/媒体对象，则呈现引擎根据来自SD的合成信息以及用户(或AR设备)的姿势和姿势信息(包括其位置和方向，并且还可以考虑设备的处理能力，例如，深度范围、显示范围等)来确定场景的合成需要哪些媒体对象。

9c)对于在9b中由呈现引擎识别的媒体对象，媒体访问功能根据SD/场景清单中的信息来识别需要哪些媒体格式和媒体分量。

9d)对于在9b中识别的每个所需的媒体分量，识别出指向媒体分量的位置的清单的位置(例如，URL)。

14)一旦接收到所需媒体分量的清单，媒体访问功能就处理这些清单，以便选择服务会话所需的必要适配参数和媒体(分量)数据(这包括识别媒体分量数据的所有可能适配的位置，以及选择用于流传输的相关适配)。

在步骤17中，媒体访问功能根据所识别和所要求的媒体分量的数量来配置媒体播放器中的媒体缓冲器流水线(在媒体访问功能和呈现引擎之间)，如图6所示。

在本公开中，媒体缓冲器流水线可以承载：

·媒体数据，例如视频、音频、3D网格等。

·媒体数据分量，例如压缩点云分量(几何结构、纹理、补丁信息、占用率)

·元数据(与媒体相关或不相关)

·具有或不具有时间依赖性的任何其它相关数据

图13是根据实施例的实体的框图。

图13的实体1300可以执行AR/MR应用、媒体播放器、媒体会话处理程序、应用功能、应用服务器和AR/MR应用提供者之一的上述操作。

参照图13，实体1300可以包括收发器1310、处理器1320和存储器1330。然而，实体1300的元件不限于此。例如，实体1300可以包括比上述更多(例如，存储器)或更少的元件

收发器1310可以向另一个实体发送信号或从另一个实体接收信号。该信号可以包括SD和媒体段。此外，收发器1310可以在有线信道或无线信道上接收信号，并将该信号输出到处理器1320，或者在有线信道或无线信道上发送从处理器1320输出的信号。

处理器1320可以控制用于实体1300的一系列过程以根据本公开的实施例进行操作。处理器1320可以包括控制器或一个或多个处理器。

存储器1330可以存储实体1300的操作所需的程序和数据。此外，存储器1330可以存储包括在由实体1300获得的信号中的SD和媒体段。存储器1330可以包括存储介质，例如只读存储器(ROM)、随机存取存储器(RAM)、硬盘、光盘ROM(CD-ROM)和数字多功能盘(DVD)、或存储介质的组合。

根据实施例，启用了包括以下特征的流传输VR/AR/MR媒体服务：

-支持体积媒体；

-支持SD；

支持VR/AR/MR媒体选择，包括基于不同上下文的多个选择标准；以及

-支持不同级别媒体适配，包括SD、体积媒体对象、媒体(分量)流水线、媒体缓冲器流水线。

根据本公开的权利要求或说明书中描述的本公开的各种实施例的方法可以用硬件、软件或硬件和软件的组合来实现。

当在软件中实现时，可以提供存储一个或多个程序(软件模块)的计算机可读存储介质。存储在计算机可读存储介质中的一个或多个程序被配置为由电子设备中的一个或多个处理器执行。所述一个或多个程序可以包括指令，所述指令使电子设备执行根据本公开的权利要求书或说明书中描述的本公开的各种实施例的方法。

程序(软件模块、软件)可以存储在RAM、包括闪存的非易失性存储器、ROM、电可擦除可编程ROM(EEPROM)、磁盘存储设备、CD-ROM、DVD或其它类型的光存储设备和/或磁带盒中。或者，可以将程序存储在存储器中，该存储器包括它们中的一些或全部的组合。可以有多个存储器。

该程序还可以存储在可以通过包括因特网、内联网、局域网(LAN)、广域网(WAN)、存储区域网(SAN)或其组合的通信网络访问的可附接存储设备中。存储设备可以通过外部端口连接到执行本公开的各种实施例的设备。此外，通信网络中的单独存储设备可以连接到执行本公开的各种实施例的设备。

在本公开的各种实施方案中，组件以单数或复数形式表示。然而，应当理解，单数或复数表示是根据为便于解释而呈现的情形适当地选择的，并且本公开不限于单数或复数形式的组件。此外，以复数形式表达的组件也可以暗示单数形式，反之亦然。

虽然已经参考本公开的各种实施例示出和描述了本公开，但是本领域技术人员将理解，在不脱离由所附权利要求及其等同物限定的本公开的精神和范围的情况下，可以在形式和细节上进行各种改变。