CN114503599A - 使用gltf2场景描述中的扩展来支持视频和音频数据 - Google Patents

使用gltf2场景描述中的扩展来支持视频和音频数据 Download PDF

Info

Publication number
CN114503599A
CN114503599A CN202080066427.5A CN202080066427A CN114503599A CN 114503599 A CN114503599 A CN 114503599A CN 202080066427 A CN202080066427 A CN 202080066427A CN 114503599 A CN114503599 A CN 114503599A
Authority
CN
China
Prior art keywords
data
video
audio
timed media
gltf2
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202080066427.5A
Other languages
English (en)
Other versions
CN114503599B (zh
Inventor
I·布阿齐齐
T·施托克哈默
N·G·彼得斯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of CN114503599A publication Critical patent/CN114503599A/zh
Application granted granted Critical
Publication of CN114503599B publication Critical patent/CN114503599B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8547—Content authoring involving timestamps for synchronizing content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2368—Multiplexing of audio and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440218—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by transcoding between formats or standards, e.g. from MPEG-2 to MPEG-4
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8146—Monomedia components thereof involving graphical data, e.g. 3D object, 2D graphics
    • H04N21/8153—Monomedia components thereof involving graphical data, e.g. 3D object, 2D graphics comprising still images, e.g. texture, background image
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Graphics (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

一种用于访问媒体数据的示例性设备包括被配置为存储媒体数据的存储器；以及以电路实现的一个或多个处理器，所述一个或多个处理器被配置为：接收包括定时媒体对象的GL传输格式2.0(glTF2)比特流的场景描述；使用所述场景描述来确定该定时媒体对象在呈现环境中的位置；获取定时媒体对象针对当前呈现时间的当前定时媒体数据；以及根据定时媒体对象在当前呈现时间处的位置，呈现当前定时媒体数据。

Description

使用GLTF2场景描述中的扩展来支持视频和音频数据
本申请要求享受2020年9月30日提交的美国临时申请No.17/038,754和2019年10月1日提交的美国临时申请No.62/909,095的权益，故以引用方式将以上申请中的每一申请的全部内容并入本文。
技术领域
本公开内容涉及经编码的视频数据的存储和传输。
背景技术
数字视频能力可以并入到各种各样的设备中，其包括数字电视、数字直接广播系统、无线广播系统、个人数字助理(PDA)、膝上型计算机或桌面型计算机、数码相机、数字记录装置、数字媒体播放器、视频游戏设备、视频游戏控制台、蜂窝或卫星无线电话、视频电话会议设备等等。数字视频设备实现视频压缩技术，例如，由MPEG-2、MPEG-4、ITU-T H.263或ITU-T H.264/MPEG-4、第10部分所规定的标准、高级视频编码(AVC)、ITU-T H.265(也称为高效率视频编码(HEVC))、以及这些标准的扩展里所描述的那些技术，以更高效地发送和接收数字视频信息。
视频压缩技术执行空间预测和/或时间预测以减少或者消除视频序列中固有的冗余。对于基于块的视频编码，可以将视频帧或片段划分为宏块。还可以对每个宏块进行进一步划分。使用相对于相邻宏块的空间预测，对帧内编码(I)帧或片段中的宏块进行编码。帧间编码(P或B)帧或片段中的宏块可以使用相对于同一帧或片段中的相邻宏块的空间预测，或者使用相对于其它参考帧的时间预测。
在对视频数据进行编码之后，可以对视频数据进行打包以进行传输或存储。可以将视频数据组装成符合多种标准中的任何一种的视频文件，比如国际标准化组织(ISO)的基本媒体文件格式及其扩展(例如，AVC)。
发明内容
通常，本公开内容描述了用于扩展GL传输格式2.0(glTF2)以用于支持音频和视频的技术以及其它技术。通常，使用glTF2来描述静态场景，即所呈现的媒体数据不变的场景。场景数据可以描述呈现环境，即用户可以例如使用虚拟现实(VR)头戴式耳机或计算设备来导航的三维空间。根据本公开内容的技术，可以对glTF2进行修改以描述定时的(例如，动态的)媒体对象(如，音频和视频数据)。例如，根据这些技术的glTF2场景可以描述在三维空间中用于显示视频的屏幕的位置、或者在三维空间中用于播放音频数据的扬声器的位置。以这种方式，设备可以在正确的位置呈现当前定时媒体数据，使得用户能够观看/聆听该媒体，就好像该媒体是从三维空间中的相应位置呈现的一样。
在一个例子中，一种用于访问媒体数据的设备，所述设备包括被配置为存储媒体数据的存储器；以及以电路实现的一个或多个处理器，所述一个或多个处理器被配置为：接收包括定时媒体对象的GL传输格式2.0(glTF2)比特流的场景描述；使用所述场景描述来确定所述定时媒体对象在呈现环境中的位置；获取所述定时媒体对象针对当前呈现时间的当前定时媒体数据；以及根据所述定时媒体对象在所述当前呈现时间处的所述位置，呈现所述当前定时媒体数据。
在另一个例子中，一种其上存储有指令的计算机可读存储介质，当所述指令被执行时，使处理器执行以下操作：接收包括定时媒体对象的GL传输格式2.0(glTF2)比特流的场景描述；使用所述场景描述来确定所述定时媒体对象在呈现环境中的位置；获取所述定时媒体对象针对当前呈现时间的当前定时媒体数据；以及根据所述定时媒体对象在所述当前呈现时间处的所述位置，呈现所述当前定时媒体数据。
在一个例子中，一种用于访问媒体数据的设备包括：用于接收包括定时媒体对象的GL传输格式2.0(glTF2)比特流的场景描述的单元；用于使用所述场景描述来确定所述定时媒体对象在呈现环境中的位置的单元；用于获取所述定时媒体对象针对当前呈现时间的当前定时媒体数据的单元；以及用于根据所述定时媒体对象在所述当前呈现时间处的所述位置，呈现所述当前定时媒体数据的单元。
在附图和下面的说明书中阐述了一个或多个例子的细节。根据说明书、附图以及权利要求书，其它特征、目的和优点将变得清晰明了。
附图说明
图1是示出一种示例性系统的框图，该示例性系统实现了用于通过网络来流传输媒体数据的技术。
图2是更详细地示出获取单元的示例性组件集合的框图。
图3是示出示例性多媒体内容的元素的概念图。
图4是示出示例性视频文件的元素的框图，其中该视频文件可以对应于表示的片段。
图5是根据本公开内容的技术，示出示例性扩展glTF2模式的概念图。
图6是根据本公开内容的技术，示出示例性循环缓冲区的概念图。
图7是根据本公开内容的技术，示出在视频源节点(被实现为解码的图像缓冲区)与媒体源之间的示例性连接的概念图。
图8是根据本公开内容的技术，示出访问媒体数据的示例性方法的流程图。
具体实施方式
GL传输格式2.0(glTF2)已被确定为一种场景描述候选格式，可以满足MPEG-1(运动图像专家组-浸入式)和6DoF(六自由度)应用的需求。例如，在github.com/KhronosGroup/glTF/tree/master/specification/2.0#specifying-extensions可获得的Khronos Group的GL传输格式(glTF)版本2.0中，描述了glTF2。然而，本公开内容分析了常规glTF2可能缺少的几个特征以及可以改进glTF2以提供这些缺失特征的技术。
通常，glTF2用于描述静态场景。也就是说，使用glTF2呈现的媒体数据是固定不变的。使用本公开内容的技术，glTF2可以用于描述包括动态媒体数据(例如，音频和视频数据)的场景。例如，三维渲染场景可以包括呈现视频数据的对象(例如，显示屏或其它对象)。同样，三维渲染场景可以包括位于三维渲染场景中的扬声器处的音频对象。
本公开内容的技术可以解决使用glTF2来支持定时媒体数据的各种要求。一个要求是，场景描述应当支持音频、视频和由MPEG标准化的其它媒体格式。常规的glTF2通常不支持音频或视频媒体格式。但是，常规的glTF2支持几种静止图像格式。
另一个要求是，场景描述应当支持定义，以指示子图和对象在其时间、空间和逻辑关系方面如何关联。常规的glTF2中部分支持该要求，因为除动画外，假定场景图的所有节点在时间0处是活动的，并且常规glTF2中没有场景更新的概念。
另一个要求是，场景描述应当支持场景中的对象和属性之间的同步。在常规的glTF2中，仅通过动画支持此功能。
另一个要求是，场景描述应当支持空间和时间随机访问。常规的glTF2不支持对场景的时间随机访问，这是因为在常规的glTF2中没有场景时间轴的概念或更新能力，也没有对定时媒体的内在支持。
另一个要求是，场景描述应当支持节点和属性，以实现声能传播和物理运动学操作的自然规律。在常规的glTF2中，不存在对材料和节点的声学特性的支持。
另一个要求是，场景描述应当支持用于渲染环境声学行为(例如，混响、遮挡和方向性)的参数模型。常规的glTF2不支持场景中的音频。
另一个要求是，应当可以更新场景描述中的整个场景图、子图或节点。常规的glTF2没有场景更新机制。
另一个要求是，在时间上随机访问之后，应该有可能正确地显现6DoF呈现。常规的glTF2既不支持时序模型，也不支持随着时间的场景更新，因此，每一个glTF2都被视为时间上的随机访问点。
另一个要求是，应当可以执行定时的场景描述更新。常规的glTF2没有场景更新机制。
另一个要求是，应当可以将场景描述更新与对应的场景描述相关联。常规的glTF2没有场景更新机制。
另一个要求是，应该可以访问本地存储或通过网络存储的定时和非定时的2D和3D媒体(网格、点云、音频元素等)。常规的glTF2支持用于从本地文件系统或通过网络来提取其内容的缓冲区和图像。但是，不支持定时媒体。
另一个要求是，应当可以根据期望的细节程度来获取媒体。在常规glTF2中通常可以通过对常规glTF2场景进行预处理，来获取不同细节程度的几何结构和纹理。常规的glTF2场景本身不支持这些操作。
另一个要求是，应当可以在时间和空间上部分地获取和访问引用的媒体。常规的glTF2引用，缺少任何属性来指示所引用媒体中的时间或空间点。
另一个要求是，音频元素应当与其对应的视觉元素一致地呈现(如果存在这样的视觉元素)。常规的glTF2不支持音频。
另一个要求是，音频元素应当与其对应的视觉元素一致地呈现(如果存在这样的视觉元素)。常规的glTF2不支持音频节点。
另一个要求是，该规范应当使用户和场景的音频和视频能够同步。常规的glTF2不支持来自场景或来自用户的音频。
另一个要求是，应当可以发现和配置本地捕获模态。常规的glTF2本身不支持本地模态，但是OpenXR提供了应用程序编程接口(API)来实现它。
另一个要求是，应当可以基于本地捕获模态的可用性来调整呈现。常规的glTF2本身不支持本地模态，但是OpenXR提供了API来实现它。
另一个要求是，应当可以引用使用不同捕获模态在本地捕获的媒体对象。常规的glTF2本身不支持本地模态，但是OpenXR提供了API来实现它。
另一个要求是，应当可以通过可用的致动器来提供反馈。常规的glTF2本身不支持本地模态，但是OpenXR提供了API来实现它。
总的来说，本公开内容描述了可以用于扩展glTF2，以实现例如如上所述的MPEG-1和/或6DoF的各种要求中的任何一个或全部的技术。可以单独地或者以任何组合方式，来应用下面更详细讨论的任何或所有技术。
本公开内容的技术可以应用于符合根据ISO基本媒体文件格式、可伸缩视频编码(SVC)文件格式、高级视频编码(AVC)文件格式、第三代合作伙伴计划(3GPP)文件格式和/或多视图视频编码(MVC)文件格式、或其它类似的视频文件格式中的任何一种进行封装的视频数据的视频文件。
在HTTP流传输中，常用的操作包括HEAD、GET和部分GET。HEAD操作获取与给定的统一资源定位符(URL)或统一资源名称(URN)相关联的文件的报头，而无需获取与该URL或URN相关联的有效载荷。GET操作获取与给定的URL或URN相关联的整个文件。部分GET操作接收字节范围作为输入参数，并获取文件的连续的数个字节，其中，该字节数对应于接收到的字节范围。因此，可以提供电影片段以用于HTTP流传输，这是因为部分GET操作可以获得一个或多个单独的电影片段。在电影片段中，可能存在不同轨道的一些轨道片段。在HTTP流传输中，媒体呈现可以是客户端可访问的结构化数据集合。客户端可以请求并下载媒体数据信息，以向用户呈现流服务。
在使用HTTP流来流传输3GPP数据的例子中，可能有针对多媒体内容的视频和/或音频数据的多个表示。如下面所解释的，不同的表示可以对应于不同的编码特性(例如，视频编码标准的不同简档或级别)、不同的编码标准或编码标准的扩展(例如，多视图和/或可伸缩扩展)或不同的比特率。可以在媒体呈现描述(MPD)数据结构中来定义这些表示的清单。媒体呈现可以对应于HTTP流客户端设备可访问的结构化数据集合。HTTP流客户端设备可以请求并下载媒体数据信息，以向客户端设备的用户呈现流传输服务。可以在MPD数据结构中描述媒体呈现，该MPD数据结构可以包括MPD的更新。
媒体呈现可以包含一个或多个时段的序列。每个时段都可以延长到下一个时段开始，或者直到媒体呈现结束为止(在最后一个时段的情况下)。每个时段可以包含针对相同媒体内容的一个或多个表示。表示可以是音频、视频、定时文本或其它此类数据的众多替代编码版本之一。这些表示可以通过编码类型(例如，根据视频数据的比特率、分辨率和/或编解码器以及音频数据的比特率、语言和/或编解码器)而不同。术语表示可以用于指代与多媒体内容的特定时段相对应并且以特定方式进行编码的经编码的音频或视频数据的一部分。
可以将特定时段的表示分配给由MPD中的属性指示的组，该组指示这些表示所属的适配集。通常认为同一适配集中的表示是彼此的替代者，这是因为客户端设备可以在这些表示之间动态且无缝地切换(例如，用于执行带宽自适应)。例如，可以将特定时段的视频数据的每个表示分配给相同的适配集，从而可以选择这些表示中的任何表示进行解码，以呈现相应时段的多媒体内容的媒体数据(例如，视频数据或音频数据)。在一些例子中，一个时段内的媒体内容可以通过来自组0的一个表示(如果存在的话)或者来自每个非零组的至多一个表示的组合来表示。可以相对于一个时段的开始时间，来表达该时段的每个表示的时序数据。
一个表示可以包括一个或多个片段。每个表示可以包括一个初始化片段，或者一个表示的每个片段可以是自初始化的。当存在初始化片段时，初始化片段可以包含用于访问该表示的初始化信息。通常，该初始化片段不包含媒体数据。一个片段可以通过标识符(例如，统一资源定位符(URL)、统一资源名称(URN)或统一资源标识符(URI))来唯一地引用。MPD可以提供每个片段的标识符。在一些例子中，MPD还可以以范围属性的形式来提供字节范围，该范围可以对应于通过URL、URN或URI可访问的文件内的片段的数据。
可以选择不同的表示，以便基本上同时地获取不同类型的媒体数据。例如，客户端设备可以选择音频表示、视频表示和定时文本表示，以从中获取片段。在一些例子中，客户端设备可以选择特定的适配集来执行带宽适配。也就是说，客户端设备可以选择包括视频表示的适配集、包括音频表示的适配集和/或包括定时文本的适配集。替代地，客户端设备可以为某些类型的媒体(例如，视频)选择适配集，并且直接为其它类型的媒体(例如，音频和/或定时文本)选择表示。
图1是示出示例系统10的框图，该示例系统10实现用于通过网络来流传输媒体数据的技术。在该例子中，系统10包括内容准备设备20、服务器设备60和客户端设备40。通过可以包括互联网的网络74，来通信地耦合客户端设备40和服务器设备60。在一些例子中，内容准备设备20和服务器设备60也可以通过网络74或另一个网络耦合，或者可以直接通信地耦合。在一些例子中，内容准备设备20和服务器设备60可以包括相同的设备。
在图1的例子中，内容准备设备20包括音频源22和视频源24。例如，音频源22可以包括麦克风，该麦克风产生表示要由音频编码器26编码的捕获的音频数据的电信号。替代地，音频源22可以包括存储介质，其存储了先前记录的音频数据、音频数据生成器(例如，计算机合成器)或任何其它音频数据源。视频源24可以包括：产生要由视频编码器28编码的视频数据的摄像机、用先前记录的视频数据编码的存储介质、诸如计算机图形源之类的视频数据生成单元或者任何其它视频数据源。在所有例子中，内容准备设备20不一定通信地耦合到服务器设备60，而是可以将多媒体内容存储到由服务器设备60读取的单独介质中。
原始音频和视频数据可以包括模拟或数字数据。可以在音频编码器26和/或视频编码器28对模拟数据进行编码之前先对其进行数字化。音频源22可以在讲话参与者正在讲话时从讲话参与者获得音频数据，并且视频源24可以同时获得讲话参与者的视频数据。在其它例子中，音频源22可以包括包含存储的音频数据的计算机可读存储介质，并且视频源24可以包括包含存储的视频数据的计算机可读存储介质。以这种方式，本公开内容中描述的技术可以应用于直播的、流式的、实时的音频和视频数据，或者应用于存档的、预记录的音频和视频数据。
与视频帧相对应的音频帧通常是包含音频数据的音频帧，该音频数据是与视频源24捕获(或生成)视频数据同时地由音频源22捕获(或生成)的，其中该视频数据包含在视频帧内。例如，当讲话参与者通常通过讲话产生音频数据时，音频源22捕获音频数据，而视频源24同时捕获讲话参与者的视频数据(即，在音频源22捕获音频数据的同时)。因此，音频帧可以在时间上对应于一个或多个特定视频帧。因此，与视频帧相对应的音频帧通常对应于以下情况：音频数据和视频数据是被同时地捕获的，并且针对此音频帧和视频帧分别包括被同时捕获的音频数据和视频数据。
在一些例子中，音频编码器26可以在每个编码的音频帧中编码时间戳，该时间戳表示记录该编码的音频帧的音频数据的时间，并且类似地，视频编码器28可以在每个编码的视频中编码时间戳，其中该时间戳表示记录编码的视频帧的视频数据的时间。在这样的例子中，音频帧与视频帧相对应可以包括：包括时间戳的音频帧和包括相同时间戳的视频帧。内容准备设备20可以包括内部时钟，音频编码器26和/或视频编码器28可以根据该内部时钟生成时间戳，或者音频源22和视频源24可以使用内部时钟将音频和视频数据分别与时间戳相关联。
在一些例子中，音频源22可以将与记录音频数据的时间相对应的数据发送到音频编码器26，并且视频源24可以将与记录视频数据的时间相对应的数据发送到视频编码器28。在一些例子中，音频编码器26可以在编码的音频数据中编码序列标识符，以指示编码的音频数据的相对时间顺序，但是不必指示记录该音频数据的绝对时间，并且类似地，视频编码器28也可以使用序列标识符来指示编码的视频数据的相对时间顺序。类似地，在一些例子中，序列标识符可以被映射，或者以其它方式与时间戳相关联。
音频编码器26通常产生编码的音频数据流，而视频编码器28产生编码的视频数据流。每个单独的数据流(无论是音频还是视频)都可以称为基本流。基本流是一个表示的单个数字编码(可能是压缩的)的组成部分。例如，表示的编码的视频或音频部分可以是一个基本流。在将基本流封装在视频文件内之前，可以将其转换为打包基本流(PES)。在同一表示中，流ID可以用于将属于一个基本流的PES包与另一个基本流进行区分。基本流的基本数据单元是打包基本流(PES)分组。因此，编码的视频数据通常对应于基本视频流。类似地，音频数据对应于一个或多个相应的基本流。
许多视频编码标准(例如，ITU-T H.264/AVC和即将推出的高效视频编码(HEVC)标准)定义了无错误比特流的语法、语义和解码过程，其中任何一个都符合某个简档或级别。视频编码标准通常不指定编码器，但编码器的任务是确保生成的比特流符合解码器的标准。在视频编码标准的上下文中，“简档”对应于算法、特征或工具和适用于它们的约束的一个子集。例如，如H.264标准所定义的，“简档”是H.264标准所指定的整个比特流语法的一个子集。“级别”对应于解码器资源消耗的限制(例如，解码器存储器和计算)，这与图像的分辨率、比特率和块处理率有关。可以用profile_idc(简档指示符)值来发信号通知简档，而可以用level_idc(级别指示符)值来发信号通知级别。
例如，H.264标准认识到，在给定简档的语法所施加的范围内，仍然可能根据比特流中的语法元素所取的值(例如，解码图像的指定大小)，而对编码器和解码器的性能具有很大不同的需求。H.264标准进一步认识到，在许多应用中，实现能够处理特定简档中语法的所有假设用途的解码器既不实用也不经济。因此，H.264标准将“级别”定义为施加在比特流中语法元素的值上的一组指定约束。这些约束可以是对值的简单限制。替代地，这些约束可以采用对值的算术组合(例如，图像宽度乘以图像高度乘以每秒解码的图像数量)进行约束的形式。H.264标准进一步规定，各个实现可以为每个支持的简档支持不同的级别。
符合简档的解码器通常支持简档中定义的所有特征。例如，作为一种编码特征，H.264/AVC的基线简档中不支持B图像编码，而H.264/AVC的其它简档中则支持B图像编码。符合级别的解码器应当能够对不需要超出该级别中定义的限制的资源的任何比特流进行解码。简档和级别的定义可以有助于解释性。例如，在视频传输期间，可以为整个传输会话协商并同意一对简档和级别定义。具体而言，在H.264/AVC中，级别可以定义对以下各项的限制：需要进行处理的宏块的数量、解码图像缓冲区(DPB)大小、编码图像缓冲区(CPB)大小、垂直运动矢量范围、每两个连续MB的运动矢量的最大数量、以及B块是否可以具有小于8x8像素的子宏块分区。以这种方式，解码器可以判断该解码器是否能够正确地解码比特流。
在图1的例子中，内容准备设备20的封装单元30从视频编码器28接收包括编码的视频数据的基本流，并且从音频编码器26接收包括编码的音频数据的基本流。在一些例子中，视频编码器28和音频编码器26可以各自包括用于从编码的数据形成PES分组的打包器。在其它例子中，视频编码器28和音频编码器26可以分别与用于从编码的数据形成PES分组的各个打包器接口。在其它例子中，封装单元30可以包括：用于从编码的音频和视频数据形成PES分组的打包器。
视频编码器28可以以各种方式，对多媒体内容的视频数据进行编码，以便以各种比特率并且利用各种特性(例如，像素分辨率、帧速率、对各种编码标准的一致性、对用于各种编码标准的各种简档和/或简档的级别的一致性、具有一个或多个视图的表示(例如，用于二维或三维播放)或其它此类特性)，来产生多媒体内容的不同表示。如本公开内容中所使用的，表示可以包括音频数据、视频数据、文本数据(例如，用于隐藏式字幕)或其它这样的数据之一。该表示可以包括诸如音频基本流或视频基本流之类的基本流。每个PES分组可以包括用于识别该PES分组所属的基本流的stream_id。封装单元30负责将基本流组装成各种表示的视频文件(例如，片段)。
封装单元30从音频编码器26和视频编码器28接收用于表示的基本流的PES分组，并且从PES分组形成对应的网络抽象层(NAL)单元。可以将编码的视频片段组织为NAL单元，这些NAL单元提供了“网络友好型”视频表示，其处理诸如视频电话、存储、广播或流媒体等等之类的应用。可以将NAL单元分类为视频编码层(VCL)NAL单元和非VCL NAL单元。VCL单元可以包含核心压缩引擎，并且可以包括块、宏块和/或条带级别数据。其它NAL单元可以是非VCL NAL单元。在一些例子中，一个时间实例中的编码图像(其通常呈现为主要编码图像)可以包含在访问单元中，该访问单元可以包括一个或多个NAL单元。
非VCL NAL单元尤其可以包括参数集NAL单元和SEI NAL单元。参数集可以包含序列级别报头信息(在序列参数集(SPS)中)和不经常变化的图像级别报头信息(在图像参数集(PPS中))。使用参数集(例如，PPS和SPS)，不需要为每个序列或图像重复不经常更改的信息；因此，可以提高编码效率。此外，参数集的使用可以实现重要报头信息的带外传输，从而避免了对于用于差错恢复的冗余传输的需求。在带外传输示例中，可以在与其它NAL单元(例如，SEI NAL单元)不同的信道上发送参数集NAL单元。
补充增强信息(SEI)可以包含从VCL NAL单元中解码编码的图像采样所不必须的信息，但其可以有助于与解码、显示、差错恢复和其它目的有关的过程。SEI消息可以包含在非VCL NAL单元中。SEI消息是一些标准规范的规范部分，因此对于符合标准的解码器实现而言，并非总是必需的。SEI消息可以是序列级别SEI消息或图像级别SEI消息。SEI消息中可以包含一些序列级别信息，例如，SVC示例中的可伸缩信息SEI消息和MVC中的视图可扩展信息SEI消息。这些示例性SEI消息可以传送关于例如操作点的提取和操作点的特性的信息。另外，封装单元30可以形成清单文件，例如，描述表示的特性的媒体呈现描述符(MPD)。封装单元30可以根据可扩展标记语言(XML)来格式化MPD。
封装单元30可以将用于多媒体内容的一个或多个表示的数据连同清单文件(例如，MPD)提供给输出接口32。输出接口32可以包括网络接口或者用于写入存储介质的接口，例如通用串行总线(USB)接口、CD或DVD写入器或刻录机、针对磁性或闪存存储介质的接口、或者用于存储或传输媒体数据的其它接口。封装单元30可以将多媒体内容的每个表示的数据提供给输出接口32，输出接口32可以经由网络传输或存储介质，将数据发送给服务器设备60。在图1的例子中，服务器设备60包括存储各种多媒体内容64的存储介质62，每个多媒体内容包括各自的清单文件66和一个或多个表示68A-68N(表示68)。在一些例子中，输出接口32还可以将数据直接发送到网络74。
在一些例子中，可以将表示68分离成适配集。即，表示68的各个子集可以包括相应的共同特性集，例如编解码器、简档和级别、分辨率、视图数、片段的文件格式、可以识别将要与要进行解码和呈现(例如，通过扬声器)的表示和/或音频数据一起显示的语言或文本的其它特性的文本类型信息、可以针对适配集中的表示来描述场景的摄像机角度或真实世界摄像机视角的摄像机角度信息、描述内容对于特定观众的适用性的评级信息等等。
清单文件66可以包括指示与特定适配集相对应的表示68的子集以及适配集的共同特性的数据。清单文件66还可以包括代表适配集的各个表示的各个特性(例如，比特率)的数据。以这种方式，适配集可以提供简化的网络带宽适配。可以使用清单文件66的适配集元素的子元素，来指示适配集中的表示。
内容准备设备20可以准备GL传输格式2.0(glTF2)比特流，其包括一个或多个定时媒体对象(例如，音频和视频对象)。具体而言，内容准备设备20(例如，其封装单元30)可以为glTF2比特流准备glTF2场景描述，该glTF2场景描述指示定时媒体对象在呈现环境中的存在性、该定时媒体对象在呈现环境(例如，用户可以在例如虚拟现实、视频游戏或其它渲染的虚拟环境中导航的三维空间)中的位置。定时媒体对象还可以与呈现时间相关联，使得客户端设备40可以在针对定时媒体对象的当前时间处呈现该定时媒体对象。例如，内容准备设备20可以现场捕获音频和视频数据，并将现场捕获的音频和视频数据实时地流传输到客户端设备40。场景描述数据可以指示定时媒体对象存储在服务器设备60上或者相对于客户端设备40的另一远程设备上，或者定时媒体对象包括在glTF2比特流中或者以其它方式已经存在于客户端设备40上。
因此，客户端设备40可以获取包括场景描述的glTF2比特流，该场景描述包括用于描述定时媒体对象的数据，例如，能够从中获取定时媒体对象的位置、定时媒体对象在呈现环境中的位置、以及定时媒体对象的呈现时间。以这种方式，客户端设备40可以获取定时媒体对象用于当前呈现时间的当前定时媒体数据，并且在呈现环境中的适当位置处和当前回放时间处呈现定时媒体数据。
客户端设备40可以被配置为实例化其存储器(图1中没有示出)中的循环缓冲区。音频解码器46和视频解码器48可以将音频或视频数据的帧存储到循环缓冲区，并且音频输出42和视频输出44可以从循环缓冲区中提取帧。例如，音频输出42、视频输出44、音频解码器46和视频解码器48可以将读指针和写指针维持在循环缓冲区中，其中音频解码器46和视频解码器48可以将解码的帧存储在写指针处，然后使写指针前进，而音频输出42和视频输出44可以在读指针处提取解码的帧，并且然后使读指针前进。此外，客户端设备40可以防止读指针超过写指针，并且防止写指针反超读指针，以防止缓冲区上溢和下溢。
服务器设备60包括请求处理单元70和网络接口72。在一些例子中，服务器设备60可以包括多个网络接口。此外，可以在内容传送网络的其它设备(例如，路由器、网桥、代理设备、交换机或其它设备)上，实现服务器设备60的任何或所有特征。在一些例子中，内容传送网络的中间设备可以缓存多媒体内容64的数据，并且包括基本上与服务器设备60的组件一致的组件。通常，网络接口72被配置为经由网络74来发送和接收数据。
请求处理单元70被配置为从诸如客户端设备40之类的客户端设备接收对存储介质62的数据的网络请求。例如，请求处理单元70可以实现超文本传输协议(HTTP)版本1.1，如在IETF网络工作组R.Fielding等人于1999年6月在RFC 2616的“Hypertext TransferProtocol–HTTP/1.1”中所描述的。也就是说，请求处理单元70可以被配置为接收HTTP GET或部分GET请求，并提供响应于这些请求的多媒体内容64的数据。这些请求可以例如使用表示68之一的片段的URL，来指定该片段。在一些例子中，这些请求还可以指定片段的一个或多个字节范围，从而包括部分GET请求。请求处理单元70可以进一步被配置为服务HTTPHEAD请求，以提供表示68之一的片段的报头数据。在任何情况下，请求处理单元70可以被配置为处理这些请求，以将被请求的数据提供给请求设备(例如，客户端设备40)。
另外地或替代地，请求处理单元70可以被配置为经由诸如eMBMS之类的广播或多播协议来传送媒体数据。内容准备设备20可以以与所描述的基本相同的方式来创建DASH片段和/或子片段，但是服务器设备60可以使用eMBMS或另一广播或多播网络传输协议来传送这些片段或子片段。例如，请求处理单元70可以被配置为从客户端设备40接收多播组加入请求。也就是说，服务器设备60可以向与特定媒体内容(例如，直播事件的广播)相关联的包括客户端设备40的客户端设备通告与多播组相关联的互联网协议(IP)地址。转而，客户端设备40可以提交加入该多播组的请求。可以贯穿网络74(例如，组成网络74的路由器)来传播该请求，从而使得路由器将发往与该多播组相关联的IP地址的业务定向到订阅的客户端设备(例如，客户端设备40)。
如图1的例子中所示，多媒体内容64包括清单文件66，清单文件66可以对应于媒体呈现描述(MPD)。清单文件66可以包含对不同的替代表示68(例如，具有不同质量的视频服务)的描述，并且该描述可以包括例如表示68的编解码器信息、简档值、级别值、比特率和其它描述性特性。客户端设备40可以获取媒体呈现的MPD，以确定如何访问表示68的片段。
具体而言，获取单元52可以获取客户端设备40的配置数据(没有示出)，以确定视频解码器48的解码能力和视频输出44的渲染能力。该配置数据还可以包括以下各项中的任何一个或全部：由客户端设备40的用户选择的语言偏好、与由客户端设备40的用户设置的深度偏好相对应的一个或多个相机视角、和/或由客户端设备40的用户选择的评级偏好。例如，获取单元52可以包括：被配置为提交HTTP GET和部分GET请求的Web浏览器或媒体客户端。获取单元52可以对应于由客户端设备40的一个或多个处理器或处理单元(没有示出)执行的软件指令。在一些例子中，关于获取单元52描述的功能的全部或部分可以利用硬件来实现，或者利用硬件、软件和/或固件的组合来实现，其中可以提供必要的硬件来执行用于软件或固件的指令。
获取单元52可以将客户端设备40的解码和渲染能力与清单文件66的信息所指示的表示68的特性进行比较。获取单元52可以最初获取清单文件66的至少一部分，以确定表示68的特性。例如，获取单元52可以请求清单文件66的一部分，该部分描述了一个或多个适配集的特性。获取单元52可以选择表示68中具有能够由客户端设备40的编码和渲染能力满足的特性的子集(例如，一适配集)。然后，获取单元52可以确定用于该适配集中的表示的比特率，确定当前可用的网络带宽量，并从这些表示之一中获取具有网络带宽可满足的比特率的片段。
通常，较高比特率表示可以产生较高质量的视频回放，而较低比特率表示可以在可用网络带宽减小时，提供足够质量的视频回放。因此，当可用的网络带宽相对较高时，获取单元52可以从相对较高比特率表示中获取数据，而当可用的网络带宽较低时，获取单元52可以从相对较低比特率表示中获取数据。以这种方式，客户端设备40可以在网络74上流传输多媒体数据，同时还适应于网络74的变化的网络带宽可用性。
另外地或替代地，获取单元52可以被配置为根据诸如eMBMS或IP多播之类的广播或多播网络协议来接收数据。在这样的例子中，获取单元52可以提交加入与特定媒体内容相关联的多播网络组的请求。在加入多播组之后，获取单元52可以接收多播组的数据，而无需向服务器设备60或内容准备设备20发出进一步的请求。当不再需要多播组的数据时(例如，用于停止播放或者将信道更改为其它多播组)，获取单元52可以提交离开多播组的请求。
网络接口54可以接收所选的表示的片段的数据，并将其提供给获取单元52，获取单元52转而可以将这些片段提供给解封装单元50。解封装单元50可以将视频文件的元素解封装为组成的PES流，对PES流进行解包以获取编码的数据，并将编码的数据发送给音频解码器46或视频解码器48(具体取决于编码的数据是音频流还是视频流的一部分，例如，如该流的PES分组报头所指示的)。音频解码器46对编码的音频数据进行解码，并将解码后的音频数据发送给音频输出42，而视频解码器48对编码的视频数据进行解码，并将解码后的视频数据(其可能包括流的多个视图)发送到视频输出44。
视频编码器28、视频解码器48、音频编码器26、音频解码器46、封装单元30、获取单元52和解封装单元50均可以实现为各种适当的处理电路中的任何一个(根据适用性)，例如一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、离散逻辑电路、软件、硬件、固件或者其任意组合。视频编码器28和视频解码器48中的每一个可以包括在一个或多个编码器或解码器中，这些编码器或解码器中的任一个可以集成为组合的视频编码器/解码器(CODEC)的一部分。同样，音频编码器26和音频解码器46中的每一个可以包括在一个或多个编码器或解码器中，这些编码器或解码器中的任一个可以集成为组合的CODEC的一部分。包括视频编码器28、视频解码器48、音频编码器26、音频解码器46、封装单元30、获取单元52和/或解封装单元50的装置可以包括集成电路、微处理器和/或无线通信设备(例如，蜂窝电话)。
客户端设备40、服务器设备60和/或内容准备设备20可以被配置为根据本公开内容的技术进行操作。为了举例起见，本公开内容相对于客户端设备40和服务器设备60描述了这些技术。但是，应当理解的是，并非(或者除了)服务器设备60，内容准备设备20可以被配置为执行这些技术。
封装单元30可以形成NAL单元，该NAL单元包括标识该NAL单元所属的节目的报头以及有效载荷(例如，音频数据、视频数据、或者描述与NAL单位对应的传输或节目流的数据)。例如，在H.264/AVC中，NAL单元包括1字节的报头和大小可变的有效载荷。在其有效载荷中包括视频数据的NAL单元可以包括各种粒度级别的视频数据。例如，NAL单元可以包括视频数据的块、多个块、视频数据的切片、或者视频数据的整个图像。封装单元30可以以基本流的PES分组的形式，从视频编码器28接收编码的视频数据。封装单元30可以将每个基本流与对应的节目相关联。
封装单元30还可以从多个NAL单元组装访问单元。通常，访问单元可以包括一个或多个NAL单元，用于呈现视频数据的帧、以及与该帧相对应的音频数据(当该音频数据可用时)。访问单元通常包括用于一个输出时间实例的所有NAL单元，例如，用于一个时间实例的所有音频和视频数据。例如，如果每个视图的帧速率均为每秒20帧(fps)，则每个时间实例可以对应于0.05秒的时间间隔。在该时间间隔期间，可以同时地呈现同一访问单元(同一时间实例)的所有视图的特定帧。在一个例子中，访问单元可以在一个时间实例中包括编码的图像，其可以呈现为主要编码图像。
因此，访问单元可以包括公共时间实例的所有音频和视频帧，例如，对应于时间X的所有视图。本公开内容还将特定视图的编码图像称为“视图分量”。也就是说，视图分量可以包括在特定时间处用于特定视图的编码图像(或帧)。因此，可以将访问单元定义为包括公共时间实例的所有视图分量。访问单元的解码顺序不必与输出或显示顺序相同。
媒体呈现可以包括媒体呈现描述(MPD)，其可以包含对不同替代表示的描述(例如，具有不同质量的视频服务)，并且该描述可以包括例如编解码器信息、简档值和级别值。MPD是清单文件(例如，清单文件66)的一个例子。客户端设备40可以获取媒体呈现的MPD，以确定如何访问各个呈现的电影片段。电影片段可以位于视频文件的电影片段盒(moof box)中。
清单文件66(其可以包括例如MPD)可以通告表示68的片段的可用性。也就是说，MPD可以包括指示表示68之一的第一片段变得可用的挂钟时间的信息、以及指示表示68中的片段的持续时间的信息。以这种方式，客户端设备40的获取单元52可以基于开始时间以及在特定片段之前的片段的持续时间，来确定每个片段何时可用。
在封装单元30已经基于接收到的数据将NAL单元和/或访问单元组装成视频文件之后，封装单元30将视频文件传递到输出接口32以进行输出。在一些例子中，封装单元30可以在本地存储视频文件，或者通过输出接口32将视频文件发送到远程服务器，而不是将视频文件直接发送到客户端设备40。输出接口32可以包括例如发射机、收发器、用于将数据写入计算机可读介质的设备(例如，光驱、磁介质驱动器(如，软盘驱动器)、通用串行总线(USB)端口、网络接口或其它输出接口)。输出接口32将视频文件输出到计算机可读介质，例如，传输信号、磁性介质、光学介质、存储器、闪存驱动器或其它计算机可读介质。
网络接口54可以经由网络74接收NAL单元或访问单元，并且经由获取单元52将NAL单元或访问单元提供给解封装单元50。解封装单元50可以将视频文件的元素解封装为组成的PES流，对PES流进行解包以获取编码的数据，然后将编码的数据发送到音频解码器46或视频解码器48(根据编码的数据是音频流还是视频流的一部分，例如，如由流的PES分组报头所指示的)。音频解码器46对编码的音频数据进行解码，并将解码的音频数据发送到音频输出42，而视频解码器48对编码的视频数据进行解码，并将解码后的视频数据(其可以包括流的多个视图)发送到视频输出44。
图2是更详细地示出图1的获取单元52的示例性组件集的框图。在该例子中，获取单元52包括eMBMS中间件单元100、DASH客户端110和媒体应用112。
在该例子中，eMBMS中间件单元100还包括eMBMS接收单元106、高速缓存104和代理服务器单元102。在该例子中，eMBMS接收单元106被配置为经由eMBMS接收数据，例如根据单向传输文件传送(FLUTE)，在T.Paila等人于2012年11月在网络工作组RFC 6726的“FLUTE-File Delivery over Unidirectional Transport”中描述了FLUTE，可从tools.ietf.org/html/rfc6726处获得该文献。也就是说，eMBMS接收单元106可以经由广播从例如服务器设备60来接收文件，该服务器设备60可以充当为广播/多播服务中心(BM-SC)。
当eMBMS中间件单元100接收到文件的数据时，eMBMS中间件单元可以将接收到的数据存储在高速缓存104中。高速缓存104可以包括计算机可读存储介质，例如闪存、硬盘、RAM或任何其它适当的存储介质。
代理服务器单元102可以充当为DASH客户端110的服务器。例如，代理服务器单元102可以向DASH客户端110提供MPD文件或其它清单文件。代理服务器单元102可以在MPD文件中通告片段的可用性时间、以及可从中获取这些片段的超链接。这些超链接可以包括与客户端设备40相对应的本地主机地址前缀(例如，对于IPv4的127.0.0.1)。以这种方式，DASH客户端110可以使用HTTP GET或部分GET请求，从代理服务器单元102请求片段。例如，对于从链接http://127.0.0.1/rep1/seg3可获得的片段，DASH客户端110可以构造HTTPGET请求，该HTTP GET请求包括针对http://127.0.0.1/rep1/seg3的请求，并向代理服务器单元102提交该请求。代理服务器单元102可以从高速缓存104中获取所请求的数据，并且响应于这些请求而将数据提供给DASH客户端110。
图3是示出示例性多媒体内容120的元素的概念图。多媒体内容120可以对应于多媒体内容64(图1)或者存储在存储介质62中的另一多媒体内容。在图3的例子中，多媒体内容120包括媒体呈现描述(MPD)122和多个表示124A-124N(表示124)。表示124A包括可选的报头数据126和片段128A-128N(片段128)，而表示124N包括可选的报头数据130和片段132A-132N(片段132)。为了方便起见，使用字母N来指定每个表示124中的最后一个电影片段。在一些例子中，表示124之间可能存在不同数量的电影片段。
MPD 122可以包括与表示124分离的数据结构。MPD 122可以对应于图1的清单文件66。同样，表示124可以对应于图1的表示68。通常，MPD 122可以包括通常描述表示124的诸如以下各项的特性的数据：编码和渲染特性、适配集、MPD 122所对应的简档、文本类型信息、摄像机角度信息、评级信息、特技模式信息(例如，指示包括时间子序列的表示的信息)、和/或用于获取远程时段的信息(例如，用于在播放期间将目标广告插入媒体内容中的信息)。
在存在报头数据126时，报头数据126可以描述片段128的特性，例如，随机访问点(RAP，也称为流访问点(SAP))的时间位置、哪些片段128包括随机访问点、到片段128内的随机访问点的字节偏移、片段128的统一资源定位符(URL)、或者片段128的其它方面。在存在报头数据130时，报头数据130可以描述片段132的相似特性。另外地或替代地，这些特性可以完全包含在MPD 122中。
片段128、132包括一个或多个编码的视频采样，每个采样可以包括视频数据的帧或切片。片段128的每个编码视频采样可以具有相似的特性，例如，高度、宽度和带宽要求。可以通过MPD 122的数据来描述这样的特性，虽然在图3的例子中没有示出这样的数据。MPD122可以包括由3GPP规范描述的特性，另外还包括本公开内容中描述的任何或所有的用信号通知的信息。
片段128、132中的每一个可以与唯一的统一资源定位符(URL)相关联。因此，可以使用诸如DASH之类的流网络协议来独立地获取片段128、132中的每一个。以这种方式，诸如客户端设备40之类的目的地设备可以使用HTTP GET请求来获取片段128或132。在一些例子中，客户端设备40可以使用HTTP部分GET请求来获取片段128或132的特定字节范围。
图4是说明示例性视频文件150的元素的框图，其中视频文件150可以对应于表示的片段(例如，图3的片段128、132之一)。片段128、132中的每一个可以包括基本符合图4的例子中所示的数据布置的数据。视频文件150可以说是对片段进行封装。如上所述，根据ISO基础媒体文件格式及其扩展的视频文件将数据存储在称为“盒”的一系列对象中。在图4的例子中，视频文件150包括文件类型(FTYP)盒152、电影(MOOV)盒154、片段索引(sidx)盒162、电影片段(MOOF)盒164和电影片段随机访问(MFRA)盒166。虽然图4表示了视频文件的例子，但是应当理解的是，其它媒体文件可以根据ISO基本媒体文件格式及其扩展，包括与视频文件150的数据类似地构造的其它类型的媒体数据(例如，音频数据、定时文本数据等等)。
文件类型(FTYP)盒152通常描述视频文件150的文件类型。文件类型盒152可以包括用于标识描述视频文件150的最佳用途的规范的数据。文件类型盒152可以替代地放置在MOOV盒154、电影片段盒164和/或MFRA盒166之前。
在一些例子中，诸如视频文件150之类的片段可以在FTYP盒152之前包括MPD更新盒(没有示出)。MPD更新盒可以包括用于指示与包括视频文件150的表示相对应的MPD要进行更新的信息，连同用于更新MPD的信息。例如，MPD更新盒可以提供要用于更新MPD的资源的URI或URL。再举一个例子，MPD更新盒可以包括用于更新MPD的数据。在一些例子中，MPD更新盒可以紧随视频文件150的片段类型(STYP)盒(没有示出)，其中，STYP盒可以定义用于视频文件150的片段类型。
在图4的例子中，MOOV盒154包括电影报头(MVHD)盒156、轨道(TRAK)盒158和一个或多个电影扩展(MVEX)盒160。通常，MVHD盒156可以描述视频文件150的一般特性。例如，MVHD盒156可以包括用于描述视频文件150被最初创建的时间、视频文件150被最后修改的时间、视频文件150的时间标度、视频文件150的播放持续时间的数据、或者通常描述视频文件150的其它数据。
TRAK盒158可以包括用于视频文件150的轨道的数据。TRAK盒158可以包括描述与TRAK盒158相对应的轨道的特性的轨道报头(TKHD)盒。在一些例子中，TRAK盒158可以包括编码的视频图像，而在其它例子中，轨道的编码的视频图像可以包含在电影片段164中，其可以通过TRAK盒158和/或sidx盒162的数据来引用。
在一些例子中，视频文件150可以包括一个以上的轨道。因此，MOOV盒154可以包括与视频文件150中的轨道数量相等数量的TRAK盒。TRAK盒158可以描述视频文件150的对应轨道的特性。例如，TRAK盒158可以描述对应轨道的时间和/或空间信息。当封装单元30(图3)在诸如视频文件150之类的视频文件中包括参数集轨道时，类似于MOOV盒154的TRAK盒158的TRAK盒可以描述参数集轨道的特性。封装单元30可以发信号通知在描述参数集轨道的TRAK盒内的参数集轨道中存在序列级别的SEI消息。
MVEX盒160可以描述对应的电影片段164的特性，例如，以发信号通知视频文件150除了包括在MOOV盒154内的视频数据之外，还包括电影片段164(如果有的话)。在流传输视频数据的上下文中，编码的视频图像可以包含在电影片段164中，而不是包含在MOOV盒154中。因此，所有编码的视频采样都可以包含在电影片段164中，而不是包含在MOOV盒154中。
MOOV盒154可以包括与视频文件150中的电影片段164的数量相等数量的MVEX框160。每个MVEX盒160可以描述电影片段164中的相应片段的特性。例如，每个MVEX盒可以包括电影扩展报头(MEHD)盒，该盒描述了电影片段164中相应片段的时间长度。
如上所述，封装单元30可以将序列数据集存储在不包括实际编码的视频数据的视频采样中。视频采样通常可以对应于访问单元，该访问单元是在特定时间实例处的编码的图像的表示。在AVC的上下文中，编码的图像包括一个或多个VCL NAL单元，其包含用于构造访问单元和其它相关联的非VCL NAL单元的所有像素的信息(例如，SEI消息)。因此，封装单元30可以在电影片段164之一中包括序列数据集，该序列数据集可以包括序列级别SEI消息。封装单元30还可以将序列数据集和/或序列级SEI消息的存在，发信号通知为是存在于对应于电影片段164之一的MVEX盒160之一内的电影片段164之一中。
SIDX盒162是视频文件150的可选元素。也就是说，符合3GPP文件格式或其它此类文件格式的视频文件不一定包括SIDX盒162。根据3GPP文件格式的例子，可以使用SIDX盒来识别片段(例如，视频文件150内包含的片段)的子片段。3GPP文件格式将子片段定义为：“一个或多个连续的电影片段盒的自包含集合，具有相应的媒体数据盒，并且，包含由电影片段盒引用的数据的媒体数据盒必须在该电影片段盒之后，并在包含有关同一轨道的信息的下一个电影片段盒之前”。3GPP文件格式还指示SIDX盒“包含对于该盒所记录的(子)片段的子片段的引用序列。所引用的子片段在显示时间上是连续的。同样，由片段索引盒所引用的字节在片段内始终是连续的。所引用的大小给出所引用的材料中的字节数的计数”。
SIDX盒162通常提供表示视频文件150中包括的片段的一个或多个子片段的信息。例如，此类信息可以包括子片段开始和/或结束的回放时间、用于子片段的字节偏移、这些子片段是否包括(例如，从头开始)流访问点(SAP)、SAP的类型(例如，SAP是否是即时解码器刷新(IDR)图像、干净随机访问(CRA)图像、断开链接访问(BLA)图像等等)、SAP在子片段中的位置(根据播放时间和/或字节偏移)等等。
电影片段164可以包括一个或多个编码的视频图像。在一些例子中，电影片段164可以包括一个或多个图像组(GOP)，每个图像组可以包括多个编码的视频图像(例如，帧或图像)。另外，如上所述，在一些例子中，电影片段164可以包括序列数据集。电影片段164中的每一个可以包括电影片段报头盒(MFHD，图4中没有示出)。MFHD盒可以描述相应的电影片段的特性，例如电影片段的序列号。可以按序列号的顺序，将电影片段164包含在视频文件150中。
MFRA盒166可以描述视频文件150的电影片段164内的随机访问点。这可以帮助执行特技模式，例如对于视频文件150封装的片段内的特定时间位置(即，回放时间)执行搜索。在一些例子中，MFRA盒166通常是可选的，并且不需要包括在视频文件中。同样，客户端设备(例如，客户端设备40)不一定需要引用MFRA盒166才能正确解码和显示视频文件150的视频数据。MFRA盒166可以包括与视频文件150的轨道数相同数量的轨道片段随机访问(TFRA)盒(没有示出)，或者在一些例子中，包括与视频文件150的媒体轨道(例如，非提示轨道)的数量相同数量的TFRA盒。
在一些例子中，电影片段164可以包括一个或多个流访问点(SAP)，例如IDR图像。同样，MFRA盒166可以提供SAP的视频文件150内的位置的指示。因此，可以通过视频文件150的SAP形成视频文件150的时间子序列。时间子序列还可以包括其它图像，例如依赖于SAP的P帧和/或B帧。可以将时间子序列的帧和/或切片布置在片段内，使得可以适当地解码依赖于子序列的其它帧/切片的时间子序列的帧/切片。例如，在数据的分层布置中，用于其它数据的预测的数据也可以包括在时间子序列中。
常规的glTF2定义了一种扩展机制(“指定扩展”)，该扩展机制允许使用新功能来扩展基本格式。任何glTF2对象都可以具有可选的extensions(扩展)属性，该属性列出由该对象使用的扩展。根据glTF2，必须在顶级extensionsUsed数组对象中列出在glTF2场景中使用的所有扩展。同样，根据glTF2，用于正确地渲染场景所需的扩展也必须列在extensionsRequired数组中。
为了在glTF2中支持基于视频的纹理，(例如，由内容准备设备20、服务器设备60和/或客户端设备40执行的)本公开内容的技术可以使用glTF2的定义的扩展，其类似于HTML的<video>元素及其媒体源扩展。具体而言，这些技术包括使用纹理元素来定义新的MotionPictureTexture对象。该元素可以引用新的源类型，该类型将允许在本地或远程地访问2D视频元素。源应当允许对压缩的2D视频进行解码，将输出的亮度和色度(YUV)转换为图形处理单元(GPU)支持的纹理格式，并且凭借具有必要的同步信息的bufferView使其可用。该扩展可以表示为“MPEG_texture_video”，其可以包含在asset(资产)的extensionsUsed和extensionsRequired中，如下所示：
Figure BDA0003557809640000181
Figure BDA0003557809640000191
如果纹理包含扩展属性，并且扩展属性定义其MPEG_texture_video属性，则客户端设备40可以从MPEG压缩的视频流中提取纹理。同样，服务器设备60和/或内容准备设备20可以提供MPEG_texture_video属性和包括纹理的比特流。在这种情况下，不需要存在源属性。
图5是示出根据本公开内容的技术的示例性扩展glTF2模式220的概念图。在该例子中，glTF2模式220包括纹理元素200，该纹理元素200包括timed_accessor元素202、转换元素204和video_source元素206。Timed_accessor元素202是对先前访问器的修改，其允许轮流通过一组buffer_view元素208A-208N(buffer_view元素208)(基于它们的时间戳)，以访问相应的纹理。
每个buffer_view元素208对应于缓冲区元素210，其中缓冲区元素210表示用于存储媒体数据(例如，音频或视频数据)的帧的缓冲区。缓冲区可以操作为预定数量的纹理帧的循环缓冲区，如上面和下面例如参照图6更详细地讨论的。当新的纹理帧被插入到循环缓冲区中时，客户端设备40可以使用新的纹理帧替换具有最早时间戳的纹理帧。
每个buffer_view元素208可以对应于一个纹理帧。纹理帧可以以无符号INT值的VEC2(2D矢量)开始。第一值可以提供与该帧的呈现时间戳相对应的32位时间戳，第二值可以提供图像编号。
Video_source元素206可以提供访问视频源的必要信息。以针对于HTML-5视频元素定义的类似方式，这可以包括URL(指向本地或远程视频资源的URL，例如，对应于高速缓存104(图2)中的数据的客户端设备40的本地主机地址、或者对应于服务器设备60或内容准备设备20(图1)的地址)、视频资源或流的MIME类型、以及时间访问和映射信息。
在各个例子中，源可以是以下之一：
·视频源，由视频MIME类型指示，并封装到例如由MP4/ISO BMFF轨道提供的定时轨道中。这同样可以适用于音频源。
·包含例如视频轨道和音频轨道的多路复用源。
·由URL指示的DASH媒体呈现。DASH媒体呈现可以包含单个源对象，但可以有多个变体以允许选择(例如，基于编解码器或分辨率)以及用于动态速率自适应(通常是不同的比特率)。这分别通过多个适配集和/或多个表示来说明。在类似的会话中，对象可以指向音频源。如ISO/IEC 23009-1第4版，修订本1的WD中所定义的，可以使用遵从用于CMAF内容的DASH简档的通用媒体访问格式(CMAF)来提供该源。
·具有多种媒体类型的DASH媒体呈现，例如，用于同步的音频/视频呈现。同样，内容可以符合用于CMAF内容的DASH简档。
如果例如MIME类型指示DASH流会话，则可以通过DASH播放器进行媒体获取。可以使用时间访问信息来提供到所引用的视频流的偏移。可以使用时间映射信息在媒体流的内部时序和将在glTF2中使用的时间线之间建立映射。
客户端设备40可以通过将媒体片段添加到媒体URL以指定要播放的确切部分来对URL进行修改。为了添加媒体片段，客户端设备40可以简单地将#t＝[start_time][,end_time]添加到媒体URL。元素可以包含以下属性中的一个或多个属性以指定回放中的特性，例如，如下的HTML-5视频元素：
-自动播放：告诉播放器只要其能够就立即开始播放。
-海报：提供要在视频加载之前显示的图像。
-控件*：显示缺省的视频控件(播放、暂停等)。
-循环：告诉播放器自动循环视频。
-静音：将视频中的音频静音。
转换节点可以用于将解码的视频输出色彩空间和空间打包转换为GPU友好的色彩空间格式。将转换函数提供为GLSL函数实现，其可以从片段着色器调用以提取正确的纹理坐标。该操作可以包括：将视频解码器输出缩放为2次幂纹理。
下面的例子演示了上面讨论的扩展：
Figure BDA0003557809640000201
Figure BDA0003557809640000211
Figure BDA0003557809640000221
视频元素可以允许与媒体进行交互，其能够由执行环境以动态方式来使用。示例包括以下各项，同样类似于HTML-5视频元素：
-当前时间：获取或设置当前播放位置(以秒为单位)。
-音量：获取或设置视频的当前音量。
-静音：获取或设置静音状态。
-播放速率：获取或设置播放速率，其中1是正常向前速度。
可以类似于视频元素来定义控件和事件，以暂停、播放或获取其它通知。同样，作为示例，HTML-5视频元素过程可以充当起始点。
在对以上视频元素的扩展中，可以将媒体源API定义为允许脚本化以生成用于回放的媒体流的元素。这种动态方法可以允许流的生成，以促进各种用例，例如自适应流传输和时移直播流，而无需DASH播放器，并且还允许回放中的额外灵活性。这种动态回放不仅可以允许对网络状况做出反应，还可以允许依赖于检视区的流传输方法，其中基于当前检视区来流传输对象。
图6是根据本公开内容的技术，来示出示例性循环缓冲区240的概念图。在该例子中，循环缓冲区240包括空数据234A、234B(其可以对应于循环缓冲区240中的不包括可用媒体数据的部分)、以及包括相应的报头230A-230D和有效载荷232A-232D的经解码的媒体帧。虽然在该例子中示出了四个帧，但是通常，循环缓冲区240可以根据分配给循环缓冲区240的存储器量和帧的大小，来存储任意数量的帧。
客户端设备40还可以维护读指针236和写指针238。通常，读指针236标识要读取的下一媒体帧(在这种情况下，该帧包括报头230A和有效载荷232A)的起点，而写指针238代表能够在其处写后续帧的循环缓冲区240的一部分。如上所述，客户端设备40可以以下面的方式来管理循环缓冲区240：读指针236不超过写指针238，并且还防止写指针238反超读指针236，以避免缓冲区上溢和下溢。
在该例子中，客户端设备40可以基于要存储的帧的数量、每个帧的尺寸、以及该帧的每个纹理影像元件(texel)的采样格式，为循环缓冲区240分配存储器。可以使用多个帧来互换缓冲区，并确保对缓冲区的平滑访问。客户端设备40的访问器可以维护读指针236和写指针238二者，如图所示。在读指针236处读取帧以进行显现。来自媒体解码器的新的输入帧被插入到写指针238处。客户端设备40可以将读指针236的值和写指针238的值存储为到缓冲区的偏移。
客户端设备40的渲染器可以确保时间戳(write_pointer)>时间戳(read_pointer)。当使用新的解码的视频帧覆盖缓冲区中的帧时，渲染器可以确保将read_pointer移到时间戳最旧的帧。这可能会导致帧丢失，但是将确保不执行对缓冲区中的同一帧的并发访问。
图7是根据本公开内容的技术，示出在视频源节点(被实现为解码的图像缓冲区280)与媒体源元素250之间的示例性连接的概念图。视频源节点被实现为连接到媒体源的解码的图像缓冲区。留给媒体应用程序来选择适当的轨道进行解码，以馈送到视频纹理缓冲区中。
在图7的例子中，media_source元素250包括source_buffers 252A-252C(source_buffers 252)。可以针对多个相应的轨道缓冲区(例如，track_buffers 256A、256B(track_buffers 256))，从source_buffers 252中提取数据。诸如视频解码器258(其可以对应于图1的客户端设备40的视频解码器48)之类的媒体解码器可以从与轨道缓冲区之一(例如，track_buffer 256A)相对应的轨道缓冲区中提取编码的媒体数据。然后，视频解码器258可以对编码的媒体数据进行解码，并将解码的媒体数据存储到解码的图像缓冲区260。转而，解码的图像缓冲区260可以将解码的视频数据输出到循环缓冲区240。解码的图像缓冲区260和循环缓冲区240可以形成图1的客户端设备40的一个或多个硬件存储设备的一部分，例如随机存取存储器(RAM)。
MPEG还定义了6DoF音频编码器输入格式，以解决对6DoF场景音频的MPEG-I要求。常规的glTF2不提供对音频场景的任何支持。为了解决这个空白，本公开内容描述了新的节点类型和新的材料扩展，例如，其可以由内容准备设备20、服务器设备60和客户端设备40使用。当处理glTF2场景图时，客户端设备40可以执行音频准备步骤以将glTF2场景转换成用于音频的音频编码器输入格式。可以定义一个名为“AcousticMaterial”的材料的新子节点。这个新的子元素对应于音频编码器输入格式中的“AcousticMaterial”元素。音频源可以被定义为Mesh基元的子属性节点。客户端设备40可以从本地文件(例如，图2的高速缓存104)或通过网络(例如，从内容准备设备20和/或服务器设备60)获取音频内容。每个音频源都可以描述对提供该源的音频数据的流的访问。所有与音频相关的元素都可以通过“MPEG_audio”扩展名称空间来确定范围。
类似于用于HTML文档的Javascript，客户端设备40可以支持活动处理以便更新glTF2场景描述。这允许以异步方式(基于诸如交互性或服务器事件之类的事件)以及与媒体源同步的方式，来更新描述对象模型。在后一种情况下，可以定义为Web资源跟踪模型定义的模型，其中使用与ISO/IEC 29001-15一致的ISO BMFF跟踪格式来为其更新定时。
图8是根据本公开内容的技术，示出访问媒体数据的示例方法的流程图。关于图1的客户端设备40的例子，来描述图8的方法。但是，其它设备可以被配置为执行本公开内容的这些或其它技术。
最初，客户端设备40可以接收针对GL传输格式2.0(glTF2)比特流的场景描述(300)。客户端设备40可以处理场景描述，并确定场景描述的定时媒体对象(302)。例如，该场景描述可以包括根据图5的glTF2模式220的数据，例如，其包括描述多个buffer_view元素的timed_accessor元素，其中每一个buffer_view元素可以对应于相应的媒体帧(例如，音频或视频帧)。
客户端设备40还可以根据场景描述，来确定呈现环境(304)。例如，客户端设备40可以确定要在三维空间中显示的虚拟对象的位置，例如墙壁、地板、天花板、门和其它对象(例如，桌子、椅子等等)。此外，客户端设备40可以根据场景描述，确定定时媒体对象在呈现环境的三维空间中的位置(306)。
然后，客户端设备40可以获取定时媒体对象的当前媒体数据(308)。例如，客户端设备40可能先前已经接收到定时的媒体数据，并且将该定时的媒体数据高速缓存到缓存104中(图2)。替代地，定时的媒体数据可以从诸如服务器设备60(图1)之类的分开的源来获得。Video_source元素206(图5)可以描述视频数据的源，例如指定本地主机地址(指示客户端设备40)或服务器设备60的地址的URL。
然后，客户端设备40可以在呈现环境的所指示的位置处，呈现当前媒体数据(310)。例如，客户端设备40可以从高速缓存104读取编码的视频数据，对编码的视频数据进行解码，将解码后的视频数据写入诸如循环缓冲区240之类的循环缓冲区，并且从循环缓冲区中获取先前解码的视频数据以进行呈现。然后，客户端设备40可以例如经由音频输出42或视频输出44之一来输出媒体数据。
以这种方式，图8的方法表示可由客户端设备40执行的方法的示例，其包括：接收包括定时媒体对象的GL传输格式2.0(glTF2)比特流的场景描述；使用该场景描述，来确定定时媒体对象在呈现环境中的位置；获取定时媒体对象在当前呈现时间的当前定时媒体数据；以及根据定时媒体对象在当前呈现时间处的位置，呈现当前定时媒体数据。
例如，由内容准备设备20、服务器设备60和/或客户端设备40执行的本公开内容的技术可以解决上面讨论的各种要求。例如：
关于场景描述应当支持音频、视频和由MPEG标准化的其它媒体格式的要求：通过上述扩展，glTF2将支持音频和视频格式。
关于场景描述应当支持定义，以指示子图和对象在其时间、空间和逻辑关系方面是如何相关的要求：通过添加场景更新，glTF2能够实现这一点。
关于场景描述应当支持场景中的对象和属性之间的同步的要求：通过使用利用Web资源轨道的时序模型来应用上述更新，从而支持同步。
关于场景描述应当支持空间和时间随机访问的要求：通过上述更新，可以在特定时间处访问场景。
关于场景描述应当支持节点和属性以便实现声能传播和物理运动学操作的自然定律的要求：通过上述音频扩展，可以解决该问题。
关于场景描述应当支持用于在渲染环境声学行为(例如，混响、遮挡和指向性)中使用的参数模型的要求：通过上述音频扩展，可以解决该问题。
关于应当可以在场景描述中更新整个场景图、子图或节点的要求：通过如上所述添加场景更新，可以解决该问题。
关于应当可以在时间上随机访问之后正确地显现6DoF呈现的要求：通过添加场景更新和如在Web资源轨道中定义并在上面讨论的模型，支持这些特征。
关于应当可以执行定时场景描述更新的要求：通过如上所述添加场景更新，可以解决该问题。
关于应当可以将场景描述更新与对应的场景描述相关联的要求：通过如上所述添加场景更新，可以解决该问题。
关于应当可以访问本地存储的定时和非定时2D和3D媒体(网格、点云、音频元素等)或通过网络对其进行访问的要求：通过上面建议的更新，添加该功能。
关于应当可以根据期望的细节水平来获取媒体的要求：如上所述，使用定时媒体的动态加载的流传输支持这一点。
关于应当可以在时间和空间上部分地获取和访问所引用的媒体的要求：如上所述，使用定时媒体的动态加载的流传输支持这一点。
关于音频元素应当与其对应的视觉元素一致地呈现的要求(如果存在这种视觉元素的话)：通过以上讨论的音频扩展，可以解决该问题。
关于音频元素应当与其对应的视觉元素一致地呈现的要求(如果存在这种视觉元素的话)：通过以上讨论的音频扩展，可以解决该问题。
关于规范应当使用户和场景的音频和视频能够同步的要求：通过以上讨论的音频扩展，可以解决该问题。
关于应当可以发现和配置本地捕获模态的要求：通过使用以上讨论的基线模型，可以实现能力发现。
关于应当可以基于本地捕获模态的可用性来调整呈现的要求：常规的glTF2本身不支持本地模态，但是OpenXR提供了API来实现它。
关于应当可以引用使用不同捕获模态在本地捕获的媒体对象的要求。常规的glTF2本身不支持本地模态，但是OpenXR提供了API来实现它。
关于应当可以通过可用的致动器来提供反馈的要求。常规的glTF2本身不支持本地模态，但是OpenXR提供了API来实现它。
在以下示例中总结了本公开内容的某些技术：
示例1：一种访问媒体数据的方法，该方法包括：接收引用视频对象的GL传输格式2.0(glTF2)比特流的纹理元素；以及使用所述纹理元素的数据来访问所述视频对象。
示例2：根据示例1所述的方法，其中，所述纹理元素指示所述视频对象被存储在远程设备上。
示例3：根据示例2所述的方法，其中，所述纹理元素定义所述视频对象的统一资源定位符(URL)。
示例4：根据示例1所述的方法，其中，所述纹理元素指示所述视频对象是本地存储的。
示例5：根据示例4所述的方法，其中，所述纹理元素定义所述视频对象的统一资源定位符(URL)。
示例6：根据示例1-5中的任何一项所述的方法，还包括：对所述视频对象的编码的视频数据进行解码以产生解码的YUV数据；将所述解码的YUV数据转换为由本地图形处理单元(GPU)支持的纹理格式；以及通过具有同步信息的bufferView元素，使所述纹理格式的数据可用。
示例7：根据示例1-6中的任何一项所述的方法，还包括：以extensionsUsed元素和extensionsRequired元素的方式来处理针对glTF2的MPEG_texture_video扩展。
示例8：根据示例1-7中的任何一项所述的方法，还包括：将所述视频对象的纹理帧存储到循环缓冲区中。
示例9：根据示例8所述的方法，其中，所述纹理帧中的每一个纹理帧与bufferView元素相关联。
示例10：根据示例8和9中的任何一项所述的方法，其中，所述纹理帧中的每一个纹理帧都以无符号整数值的对应2D矢量开始，所述2D矢量包括与所述纹理帧的呈现时间戳相对应的32位时间戳和所述纹理帧的图像编号值。
示例11：根据示例8-10中的任何一项所述的方法，还包括：维持到所述循环缓冲区中的读指针和到所述循环缓冲区中的写指针；以及防止所述读指针超过所述写指针。
示例12：根据示例1-11中的任何一项所述的方法，还包括：确定所述视频对象的URL、所述视频对象的MIME类型以及所述视频对象的时间访问和映射信息。
示例13：根据示例1-12中的任何一项所述的方法，其中，访问包括从源中访问所述视频对象。
示例14：根据示例13所述的方法，其中，所述源包括以下各项中的至少一项：由视频MIME类型指示并封装到定时轨道中的视频源、包含视频轨道和音频轨道的多路复用源、由URL指示的DASH媒体呈现、或者具有多种媒体类型的DASH媒体呈现。
示例15：根据示例1-14中的任何一项所述的方法，其中，访问包括：使用指定URL的HTTP GET请求来访问所述视频对象，该方法还包括：将自动播放属性、海报属性、控件*属性、循环属性或静音属性中的至少一项附加到所述HTTP GET请求中的所述URL。
示例16：根据示例1-15中的任何一项所述的方法，还包括：将所述g1TF2比特流的数据转换为音频编码器输入格式。
示例17：根据示例16所述的方法，还包括：以所述音频编码器输入格式来处理AcousticMaterial元素。
示例18：根据示例16和17中的任何一项所述的方法，还包括：确定与网格基元的子属性节点相对应的音频源。
示例19：根据示例16-18中的任何一项所述的方法，还包括：访问所述gt1TF2的编码的音频数据。
示例20：根据示例19所述的方法，其中，访问所述编码的音频数据包括：从远程网络设备获取所述编码的音频数据。
示例21：根据示例19所述的方法，其中，访问所述编码的音频数据包括：从本地高速缓存中获取所述编码的音频数据。
示例22：根据示例1-21中的任何一项所述的方法，还包括：使用活动处理，来更新所述glTF2比特流的glTF2场景描述。
示例23：根据示例22所述的方法，还包括：以异步方式来更新描述对象模型。
示例24：根据示例22和23中的任何一项所述的方法，还包括：以与媒体源同步的方式来更新描述对象模型。
示例25：一种用于访问媒体数据的设备，所述设备包括用于执行示例1–24中的任何一项的方法的一个或多个单元。
示例26：根据示例25所述的设备，其中，所述一个或多个单元包括用于存储媒体数据的存储器和以电路实现的一个或多个处理器。
示例27：根据示例25所述的设备，其中，所述设备包括集成电路、微处理器或无线通信设备中的至少一项。
示例28：一种用于获取媒体数据的设备，所述设备包括：用于接收引用视频对象的GL传输格式2.0(glTF2)比特流的纹理元素的单元；以及用于使用所述纹理元素的数据访问所述视频对象的单元。
示例29：一种其上存储有指令的计算机可读存储介质，当所述指令被执行时，使处理器执行示例1-24中的任何一项所述的方法。
在一个或多个例子中，所描述的功能可以利用硬件、软件、固件或者其任意组合来实现。当利用软件实现时，可以将这些功能存储在计算机可读介质上，或者作为计算机可读介质上的一个或多个指令或代码进行传输，并由基于硬件的处理单元来执行。计算机可读介质可以包括计算机可读存储介质，计算机可读存储介质对应于诸如数据存储介质之类的有形介质或通信介质，其中通信介质包括有助于例如根据通信协议，将计算机程序从一个地方传送到另一个地方的任何介质。用此方式，计算机可读介质通常可以对应于：(1)是非临时性的有形计算机可读存储介质；或者(2)诸如信号或载波波形之类的通信介质。数据存储介质可以是能够由一个或多个计算机或者一个或多个处理器进行存取以获取用于实现本公开内容中描述的技术的指令、代码和/或数据结构的任何可用介质。计算机程序产品可以包括计算机可读介质。
举例而言，但非做出限制，这种计算机可读存储介质可以包括RAM、ROM、EEPROM、CD-ROM或者其它光盘存储器、磁盘存储器或其它磁存储设备、闪存或者能够用于存储具有指令或数据结构形式的期望的程序代码并能够由计算机进行存取的任何其它介质。此外，可以将任何连接适当地称作计算机可读介质。举例而言，如果指令是使用同轴电缆、光纤光缆、双绞线、数字用户线路(DSL)或者诸如红外线、无线和微波之类的无线技术，从网站、服务器或其它远程源传输的，那么所述同轴电缆、光纤光缆、双绞线、DSL或者诸如红外线、无线和微波之类的无线技术包括在介质的定义中。但是，应当理解的是，计算机可读存储介质和数据存储介质并不包括连接、载波波形、信号或者其它临时介质，而是针对于非临时的有形存储介质。如本文所使用的，磁盘和光盘包括压缩光盘CD、激光盘、光盘、数字通用光盘(DVD)、软盘和蓝光盘，其中磁盘通常磁性地复制数据，而光盘则用激光来光学地复制数据。上述的组合也应当包括在计算机可读介质的范围之内。
指令可以由诸如一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程逻辑阵列(FPGA)之类的一个或多个处理器或者其它等同的集成或分立逻辑电路来执行。因此，如本文所使用的，术语“处理器”可以指代前述的结构或者适合于实现本文所描述的技术的任何其它结构中的任何一种。此外，在一些方面，本文所描述的功能可以被提供在被配置用于编码和解码的专用硬件和/或软件模块中，或者被并入到组合的编解码器中。此外，这些技术可以在一个或多个电路或逻辑元件中完全实现。
可以使用多种多样的设备或装置来实现本公开内容的技术，这些设备或装置包括无线手持装置、集成电路(IC)或者一组IC(例如，芯片集)。本公开内容中描述了各种组件、模块或单元，以强调被配置为执行所公开的技术的设备的功能方面，但不一定需要由不同的硬件单元来实现。相反，如上所述，各个单元可以组合在编解码器硬件单元中，或者通过协作的硬件单元集合(其包括如上所述的一个或多个处理器)结合适当的软件和/或固件来提供。
描述了各个示例。这些和其它示例落入所附权利要求书的保护范围之内。

Claims (30)

1.一种用于访问媒体数据的设备，所述设备包括：
被配置为存储媒体数据的存储器；以及
以电路实现的一个或多个处理器，所述一个或多个处理器被配置为：
接收包括定时媒体对象的GL传输格式2.0(glTF2)比特流的场景描述；
使用所述场景描述来确定所述定时媒体对象在呈现环境中的位置；
获取所述定时媒体对象针对当前呈现时间的当前定时媒体数据；以及
根据所述定时媒体对象在所述当前呈现时间处的所述位置，呈现所述当前定时媒体数据。
2.根据权利要求1所述的设备，其中，所述定时媒体对象包括视频对象，并且其中，所述一个或多个处理器还被配置为将所述视频对象的纹理帧存储到循环缓冲区。
3.根据权利要求2所述的设备，其中，所述纹理帧中的每一个纹理帧与bufferView元素相关联。
4.根据权利要求2所述的设备，其中，所述纹理帧中的每一个纹理帧以无符号整数值的对应2D矢量开始，所述无符号整数值的对应2D矢量包括与所述纹理帧的呈现时间戳相对应的32位时间戳和所述纹理帧的图像编号值。
5.根据权利要求2所述的设备，其中，所述一个或多个处理器还被配置为：
维持到所述循环缓冲区中的读指针和到所述循环缓冲区中的写指针；以及
防止所述读指针超过所述写指针。
6.根据权利要求1所述的设备，其中，所述场景描述包括指示所述定时媒体对象被存储在远程设备上的数据，并且其中，所述一个或多个处理器被配置为从所述远程设备获取所述当前定时媒体数据。
7.根据权利要求6所述的设备，其中，所述场景描述的所述数据定义了所述定时媒体对象的并与所述远程设备相对应的统一资源定位符(URL)。
8.根据权利要求1所述的设备，其中，所述场景描述包括指示所述定时媒体对象被本地存储的数据，并且其中，所述一个或多个处理器被配置为从所述存储器中获取所述当前定时媒体数据。
9.根据权利要求8所述的设备，其中，所述场景描述包括：定义所述定时媒体对象的并与所述设备的本地主机地址相对应的统一资源定位符(URL)的数据。
10.根据权利要求1所述的设备，其中，所述定时媒体对象包括视频对象，并且其中，所述一个或多个处理器被配置为：
对所述视频对象的编码的视频数据进行解码，以产生解码的YUV数据；
将所述解码的YUV数据转换为由本地图形处理单元(GPU)支持的纹理格式；以及
通过具有同步信息的bufferView元素，使具有所述纹理格式的数据可用。
11.根据权利要求1所述的设备，其中，所述一个或多个处理器还被配置为以extensionsUsed元素和extensionsRequired元素的方式来处理对于glTF2的MPEG_texture_video扩展。
12.根据权利要求1所述的设备，其中，所述一个或多个处理器还被配置为确定所述定时媒体对象的URL、所述定时媒体对象的MIME类型、以及所述定时媒体对象的时间访问和映射信息。
13.根据权利要求1所述的设备，其中，所述一个或多个处理器被配置为从以下各项中的至少一项访问所述定时媒体对象：由视频MIME类型指示的并封装到定时轨道中的视频源、包含视频轨道和音频轨道的多路复用源、由URL指示的DASH媒体呈现、或者具有多种媒体类型的DASH媒体呈现。
14.根据权利要求1所述的设备，其中，所述一个或多个处理器被配置为使用指定URL的HTTP GET请求来访问所述定时媒体对象，并且将自动播放属性、海报属性、控件*属性、循环属性或静音属性中的至少一项附加到所述HTTP GET请求中的所述URL。
15.根据权利要求1所述的设备，其中，所述定时媒体对象包括音频对象，并且其中，所述一个或多个处理器还被配置为将所述音频对象的数据转换为音频编码器输入格式。
16.根据权利要求15所述的设备，其中，所述一个或多个处理器还被配置为以所述音频编码器输入格式来处理AcousticMaterial元素。
17.根据权利要求15所述的设备，其中，所述一个或多个处理器还被配置为确定与网格基元的子属性节点相对应的音频源。
18.根据权利要求15所述的设备，其中，所述一个或多个处理器还被配置为访问所述音频对象的编码的音频数据。
19.根据权利要求1所述的设备，其中，所述一个或多个处理器还被配置为使用活动处理，来更新所述glTF2比特流的glTF2场景描述。
20.根据权利要求19所述的设备，其中，所述一个或多个处理器还被配置为以异步方式来更新描述对象模型。
21.根据权利要求1所述的设备，其中，所述一个或多个处理器还被配置为以与媒体源同步的方式来更新描述对象模型。
22.一种其上存储有指令的计算机可读存储介质，当所述指令被执行时，使处理器执行以下操作：
接收包括定时媒体对象的GL传输格式2.0(glTF2)比特流的场景描述；
使用所述场景描述来确定所述定时媒体对象在呈现环境中的位置；
获取所述定时媒体对象针对当前呈现时间的当前定时媒体数据；以及
根据所述定时媒体对象在所述当前呈现时间处的所述位置，呈现所述当前定时媒体数据。
23.根据权利要求22所述的计算机可读存储介质，其中，所述定时媒体对象包括视频对象，所述计算机可读存储介质还包括：使所述处理器将所述视频对象的纹理帧存储到循环缓冲区的指令。
24.根据权利要求23所述的计算机可读存储介质，其中，所述纹理帧中的每一个纹理帧与bufferView元素相关联。
25.根据权利要求23所述的计算机可读存储介质，其中，所述纹理帧中的每一个纹理帧以无符号整数值的对应2D矢量开始，所述无符号整数值的对应2D矢量包括与所述纹理帧的呈现时间戳相对应的32位时间戳和所述纹理帧的图像编号值。
26.根据权利要求23所述的计算机可读存储介质，还包括使所述处理器执行以下操作的指令：
维持到所述循环缓冲区中的读指针和到所述循环缓冲区中的写指针；以及
防止所述读指针超过所述写指针。
27.根据权利要求22所述的计算机可读存储介质，其中，所述定时媒体对象包括视频对象，所述计算机可读存储介质还包括使所述处理器执行以下操作的指令：
对所述视频对象的编码的视频数据进行解码，以产生解码的YUV数据；
将所述解码的YUV数据转换为由本地图形处理单元(GPU)支持的纹理格式；以及
通过具有同步信息的bufferView元素，使具有所述纹理格式的数据可用。
28.根据权利要求22所述的计算机可读存储介质，还包括：用于使所述处理器将所述glTF2比特流的数据转换为音频编码器输入格式的指令。
29.根据权利要求22所述的计算机可读存储介质，还包括：用于使所述处理器使用活动处理，来更新所述glTF2比特流的glTF2场景描述的指令。
30.一种用于访问媒体数据的设备，所述设备包括：
用于接收包括定时媒体对象的GL传输格式2.0(glTF2)比特流的场景描述的单元；
用于使用所述场景描述来确定所述定时媒体对象在呈现环境中的位置的单元；
用于获取所述定时媒体对象针对当前呈现时间的当前定时媒体数据的单元；以及
用于根据所述定时媒体对象在所述当前呈现时间处的所述位置，呈现所述当前定时媒体数据的单元。
CN202080066427.5A 2019-10-01 2020-10-01 使用gltf2场景描述中的扩展来支持视频和音频数据 Active CN114503599B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201962909095P 2019-10-01 2019-10-01
US62/909,095 2019-10-01
US17/038,754 US11405699B2 (en) 2019-10-01 2020-09-30 Using GLTF2 extensions to support video and audio data
US17/038,754 2020-09-30
PCT/US2020/053793 WO2021067593A1 (en) 2019-10-01 2020-10-01 Use of extensions in gltf2 scene description to support video and audio data

Publications (2)

Publication Number Publication Date
CN114503599A true CN114503599A (zh) 2022-05-13
CN114503599B CN114503599B (zh) 2024-06-28

Family

ID=

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115170708A (zh) * 2022-07-11 2022-10-11 上海哔哩哔哩科技有限公司 3d图像实现方法及系统
CN115170707A (zh) * 2022-07-11 2022-10-11 上海哔哩哔哩科技有限公司 基于应用程序框架的3d图像实现系统及方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160191931A1 (en) * 2014-12-31 2016-06-30 Nokia Technologies Oy Apparatus, a method and a computer program for video coding and decoding
US20160277769A1 (en) * 2015-03-16 2016-09-22 Microsoft Technology Licensing, Llc Standard-guided video decoding performance enhancements
CN108985471A (zh) * 2018-07-30 2018-12-11 刘玉龙 基于3d轻量化模型的航空器管理系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160191931A1 (en) * 2014-12-31 2016-06-30 Nokia Technologies Oy Apparatus, a method and a computer program for video coding and decoding
US20160277769A1 (en) * 2015-03-16 2016-09-22 Microsoft Technology Licensing, Llc Standard-guided video decoding performance enhancements
CN108985471A (zh) * 2018-07-30 2018-12-11 刘玉龙 基于3d轻量化模型的航空器管理系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
IMED BOUAZIZI: "Requirements on Integration of Scene Description in MPEG-I", 《MPEG126》 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115170708A (zh) * 2022-07-11 2022-10-11 上海哔哩哔哩科技有限公司 3d图像实现方法及系统
CN115170707A (zh) * 2022-07-11 2022-10-11 上海哔哩哔哩科技有限公司 基于应用程序框架的3d图像实现系统及方法

Also Published As

Publication number Publication date
TW202127899A (zh) 2021-07-16
US20210099773A1 (en) 2021-04-01
EP4038895A1 (en) 2022-08-10
US11405699B2 (en) 2022-08-02
WO2021067593A1 (en) 2021-04-08

Similar Documents

Publication Publication Date Title
CN110431850B (zh) 在使用mime类型参数的网络视频流式传输中发信重要视频信息
US11405699B2 (en) Using GLTF2 extensions to support video and audio data
JP7027518B2 (ja) メディアコンテンツのためのリージョンワイズパッキング、コンテンツカバレッジ、およびシグナリングフレームパッキング
CN109076229B (zh) 在图片中最感兴趣的区域
CN109076238B (zh) 通过http在动态自适应流式传输中用信号传送虚拟现实视频
JP6342457B2 (ja) コード化ビデオデータのネットワークストリーミング
CN110089122B (zh) 用于检索媒体数据的方法、媒体装置及计算机可读存储媒体
JP5866359B2 (ja) ネットワークストリーミングされるビデオデータについての属性をシグナリングすること
CN111149368A (zh) 用于浸入式媒体数据的内容来源描述
CN110832872B (zh) 使用用于文件格式方框的通用描述符处理媒体数据
US10567734B2 (en) Processing omnidirectional media with dynamic region-wise packing
CN112771876A (zh) 媒体数据的网络流式传输的初始化集合
CN114930862A (zh) 用于流式媒体数据的多解码器接口
KR102654999B1 (ko) 강화된 영역별 패킹 및 뷰포트 독립적 hevc 미디어 프로파일
CN110870323B (zh) 使用全向媒体格式处理媒体数据
CN114503599B (zh) 使用gltf2场景描述中的扩展来支持视频和音频数据
US20220335694A1 (en) Anchoring a scene description to a user environment for streaming immersive media content
JP2024511948A (ja) Ｈｅｉｆフォーマットされた画像をリアルタイムトランスポートプロトコル上でトランスポートすること

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant