CN114747219A - 用于存储和信令传送子样本条目描述的方法和装置 - Google Patents

用于存储和信令传送子样本条目描述的方法和装置 Download PDF

Info

Publication number
CN114747219A
CN114747219A CN202080083325.4A CN202080083325A CN114747219A CN 114747219 A CN114747219 A CN 114747219A CN 202080083325 A CN202080083325 A CN 202080083325A CN 114747219 A CN114747219 A CN 114747219A
Authority
CN
China
Prior art keywords
sub
sample
information
track
bitstream
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.)
Pending
Application number
CN202080083325.4A
Other languages
English (en)
Inventor
E·B·阿克苏
M·汉努克塞拉
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.)
Nokia Technologies Oy
Original Assignee
Nokia Technologies Oy
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 Nokia Technologies Oy filed Critical Nokia Technologies Oy
Publication of CN114747219A publication Critical patent/CN114747219A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/20Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using video object coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/115Selection of the code volume for a coding unit prior to coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/136Incoming video signal characteristics or properties
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/184Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being bits, e.g. of the compressed video stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling 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/2362Generation or processing of Service Information [SI]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85Assembly of content; Generation of multimedia applications
    • H04N21/854Content authoring

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

描述了用于信令传送和存储压缩点云的方法、装置和计算机程序产品。与样本序列内的子样本序列相关联的子样本条目可以指示子样本序列是否被单独封装在轨道中,而没有其他子样本或附加的报头数据。子样本条目类型可以在轨道级子样本描述框被索引。点云压缩编码比特流分量类型可以通过在轨道级子样本描述框的编解码器特定参数相关的字段中包括相应的点云单元报头信息来信令传送。子样本信息框可以指示用于相应的子样本的子样本条目索引。在这种信息框中的标志可以指示子样本描述条目索引的存在。描述索引框可以包含与子样本信息框在相同的容器中的子样本描述条目索引。轨道片段报头框可以包括应用于轨道片段的样本的子样本描述条目索引。

Description

用于存储和信令传送子样本条目描述的方法和装置
相关申请的交叉引用
本申请要求于2019年10月2日提交的美国临时专利申请No.62/909,259(题为“用于以ISOBMFF存储和信令传送子样本条目描述的方法和装置(Method and Apparatus forStorage and Signaling of Sub-Sample Entry Descriptions in ISOBMFF)”)的优先权和权益,针对所有目的,本申请的全部公开内容通过引用而全部并入本文中。
技术领域
示例实施例一般地涉及体积视频编码和解码。
背景技术
体积视频数据表示三维场景或对象,并且可以用作增强现实(AR)、虚拟现实(VR)和混合现实(MR)应用的输入。此类数据描述了几何形状(形状、大小、三维(3D)空间中的位置)和相应的属性(例如,颜色、不透明度、反射率等)、以及几何形状和属性在给定时间实例(如二维(2D)视频中的帧)的在时间上的变化。体积视频要么是从3D模型生成的(例如,计算机生成的图像(CGI)),要么是使用各种捕获方案(例如,多个相机、激光扫描、视频和专用深度传感器的组合等等)从现实世界场景中捕获的。用于这种体积数据的一种示例表示格式是点云。关于场景的时间信息可以被包含在个体捕获实例的形式中,例如,二维(2D)视频中的“帧”、或者其他机制,例如,作为时间的函数的对象的位置。
点云通常非常适于诸如捕获现实世界3D场景(其中拓扑不必是2D流形)之类的应用。然而,当重构的3D场景包含数千万甚至数亿个点时,标准点云的时间压缩性能很差。识别3D空间中运动补偿的对应关系是一个定义不明确的问题,因为几何形状和其他相应的属性可发生变化。例如,时间连续帧不必具有相同数量的点云。因此,动态3D场景的压缩效率很低。点的数量、其位置和其属性可以逐帧地变化。这种表示需要大量数据,其在存储和传输方面可花销昂贵。基于2D视频的体积数据(例如,多视图和深度)压缩方法具有更好的压缩效率,但很少覆盖全部场景。这些基于2D的方法仅提供有限的六自由度(6DOF)能力。因此,需要一种具有良好压缩效率和高自由度的方法。
一种具有良好压缩效率和高自由度两者的方法是将以压缩点云表示的体积模型投影到2D平面上。这种方法允许使用具有高效时间压缩的2D视频编码工具,而同时保持优于纯基于2D的方法的自由度。压缩点云包括对应于3D对象的纹理的编码视频比特流、对应于3D对象的几何形状的编码视频比特流、以及对应于在3D对象的合成期间必需的所有其他辅助信息的编码元数据比特流。然而,还没有用于这些流的定义明确、高效和标准化的存储和信令机制。
发明内容
根据示例实施例提供了用于在视频编码中信令传送和存储压缩点云的方法、装置和计算机程序产品。该方法、装置和计算机程序产品可以与多种视频格式结合使用。
在各种实施例中,子样本条目与样本序列内的子样本序列相关联。子样本条目的语义可意味着如果子样本序列被封装在其自己的轨道中,则在该轨道中不存在其他子样本或其他附加报头数据(诸如V-PCC单元报头),在该轨道中的样本序列将符合与子样本条目相同的样本条目。子样本条目类型可以在轨道级子样本描述框被索引,并且子样本信息框可以被扩展为指示针对每个子样本的子样本条目索引。子样本信息框可以被扩展为包括标识子样本描述条目索引的存在的版本或标志。可以形成子样本描述索引框,以用于将子样本描述条目索引与子样本信息框包含在相同的容器中。用于电影片段轨道的轨道片段报头框可以被扩展为包括应用于轨道片段的每个样本的一组子样本描述条目索引。可替代地,在轨道级的样本条目可以被扩展为对样本描述框中的子样本进行索引,并且子样本信息框可以引用在轨道级样本描述框的样本条目的索引。
在一些实施例中,一种方法可以包括:访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为一个或多个媒体轨道;形成轨道级子样本描述框,该轨道级子样本描述框包括用于相应的多个子样本的多个子样本条目类型;以及通过在该轨道级子样本描述框的编解码器特定参数相关的字段中包括相应的点云单元报头信息,指示一个或多个类型的点云压缩编码比特流分量。在一些实施例中,该方法可以进一步包括:扩展子样本信息框,以通过以下操作来指示子样本条目索引:在相关的子样本描述框中指示子样本条目的存在顺序,并进一步经由版本值或者在所述子样本信息框中设置标志来指示其存在。在一些实施例中,所述至少一个媒体轨道具有经由所述子样本条目索引而信令传送的打包类型。在一些实施例中,存储所述点云压缩编码比特流包括:访问属性信息比特流、几何形状信息比特流、占用信息比特流和补片(patch)信息比特流;检测该属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流遵循兼容的编码和定时结构;以及至少基于该兼容的编码和定时结构来构建并存储视频媒体轨道。在一些实施例中,所述点云压缩编码比特流包括至少一个属性信息比特流、至少一个几何形状信息比特流、至少一个占用信息比特流、以及至少一个补片信息比特流。在一些实施例中,该方法可以进一步包括:访问该属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流;将该属性信息码流存储在属性视频媒体轨道中;将该几何形状信息比特流存储在几何形状视频媒体轨道中;将该占用信息比特流存储在占用视频媒体轨道中;将该补片信息比特流存储在另一个编码媒体或元数据轨道中;以及在文件中构建并存储元数据,该元数据指示该属性视频媒体轨道、几何形状视频媒体轨道、占用视频媒体轨道和单独的编码媒体或元数据轨道的一个或多个分量的模式。在一些实施例中,该元数据是交错指示符元数据,其指示该属性视频媒体轨道、几何形状视频媒体轨道、占用视频媒体轨道和单独的编码媒体或元数据轨道的所述一个或多个分量的交错模式。在一些实施例中,针对其指示模式的所述一个或多个分量中的每一个可使用子样本信息框(SubSampleInformationBox)访问,所述SubSampleInformationBox针对所述一个或多个分量定义顺序和配置信息,所述SubSampleInformationBox被配置为指示所述模式。在一些实施例中,存储包括:以国际标准化组织基础媒体文件格式(ISOBMFF)存储不同的基于视频的点云压缩结构。
在一些实施例中,提供了一种装置,其包括至少一个处理器和包括用于一个或多个程序的计算机程序代码的至少一个存储器,该至少一个存储器和计算机程序代码被配置为与该至少一个处理器一起使该装置至少:访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为一个或多个媒体轨道;形成轨道级子样本描述框,该轨道级子样本描述框包括用于相应的多个子样本的多个子样本条目类型;以及通过在该轨道级子样本描述框的编解码器特定参数相关的字段中包括相应的点云单元报头信息,指示一个或多个类型的点云压缩编码比特流分量。在一些实施例中,该计算机程序代码、至少一个存储器和/或一个或多个处理器可以被配置为进一步使该装置至少:扩展子样本信息框,以通过以下操作来指示子样本条目索引:在相关的子样本描述框中指示子样本条目的存在顺序,并进一步经由版本值或者在所述子样本信息框中设置标志来指示其存在。在一些实施例中,所述至少一个媒体轨道具有经由所述子样本条目索引而信令传送的打包类型。在一些实施例中,该至少一个存储器和计算机程序代码进一步被配置为与该至少一个处理器一起使该装置至少:访问属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流;检测该属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流遵循兼容的编码和定时结构;以及至少基于该兼容的编码和定时结构来构建并存储视频媒体轨道。在一些实施例中,所述点云压缩编码比特流包括至少一个属性信息比特流、至少一个几何形状信息比特流、至少一个占用信息比特流、以及至少一个补片信息比特流。在一些实施例中,该至少一个存储器和计算机程序代码进一步被配置为与该至少一个处理器一起使该装置至少:访问该属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流;将该属性信息码流存储在属性视频媒体轨道中;将该几何形状信息比特流存储在几何形状视频媒体轨道中;将该占用信息比特流存储在占用视频媒体轨道中;将该补片信息比特流存储在另一个编码媒体或元数据轨道中;以及在文件中构建并存储元数据,该元数据指示该属性视频媒体轨道、几何形状视频媒体轨道、占用视频媒体轨道和单独的编码媒体或元数据轨道的一个或多个分量的模式。在一些实施例中,该元数据是交错指示符元数据,其指示该属性视频媒体轨道、几何形状视频媒体轨道、占用视频媒体轨道和单独的编码媒体或元数据轨道的所述一个或多个分量的交错模式。在一些实施例中,针对其指示模式的所述一个或多个分量中的每一个可使用SubSampleInformationBox访问,所述SubSampleInformationBox针对所述一个或多个分量定义顺序和配置信息,所述SubSampleInformationBox被配置为指示所述模式。在一些实施例中,存储包括:以国际标准化组织基础媒体文件格式(ISOBMFF)存储不同的基于视频的点云压缩结构。
在一些实施例中,提供了一种装置,其包括用于执行诸如本文所描述的方法的部件,诸如至少一个处理器和包括用于一个或多个程序的计算机程序代码的至少一个存储器。在一些实施例中,该装置可以包括用于访问点云压缩编码比特流的部件,其中,所述点云压缩编码比特流被配置以被存储为一个或多个媒体轨道;用于形成轨道级子样本描述框的部件,其中,该轨道级子样本描述框包括用于相应的多个子样本的多个子样本条目类型;以及用于通过在该轨道级子样本描述框的编解码器特定参数相关的字段中包括相应的点云单元报头信息来指示一个或多个类型的点云压缩编码比特流分量的部件。在一些实施例中,该装置可以进一步包括:用于扩展子样本信息框,以通过以下操作来指示子样本条目索引的部件:在相关的子样本描述框中指示子样本条目的存在顺序,并进一步经由版本值或者在所述子样本信息框中设置标志来指示其存在。在一些实施例中,所述至少一个媒体轨道具有经由所述子样本条目索引而信令传送的打包类型。在一些实施例中,该装置可以进一步包括:用于访问属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流的部件;用于检测该属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流遵循兼容的编码和定时结构的部件;以及用于至少基于该兼容的编码和定时结构来构建并存储视频媒体轨道的部件。在一些实施例中,所述点云压缩编码比特流包括至少一个属性信息比特流、至少一个几何形状信息比特流、至少一个占用信息比特流、以及至少一个补片信息比特流。在一些实施例中,该装置可以进一步包括:用于访问该属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流的部件;用于将该属性信息码流存储在属性视频媒体轨道中的部件;用于将该几何形状信息比特流存储在几何形状视频媒体轨道中的部件;用于将该占用信息比特流存储在占用视频媒体轨道中的部件;用于将该补片信息比特流存储在另一个编码媒体或元数据轨道中的部件;以及用于在文件中构建并存储元数据的部件,其中,该元数据指示该属性视频媒体轨道、几何形状视频媒体轨道、占用视频媒体轨道和单独的编码媒体或元数据轨道的一个或多个分量的模式。在一些实施例中,该元数据是交错指示符元数据,其指示该属性视频媒体轨道、几何形状视频媒体轨道、占用视频媒体轨道和单独的编码媒体或元数据轨道的所述一个或多个分量的交错模式。在一些实施例中,针对其指示模式的所述一个或多个分量中的每一个可使用SubSampleInformationBox访问,所述SubSampleInformationBox针对所述一个或多个分量定义顺序和配置信息,所述SubSampleInformationBox被配置为指示所述模式。在一些实施例中,存储包括:以国际标准化组织基础媒体文件格式(ISOBMFF)存储不同的基于视频的点云压缩结构。
在一些实施例中,提供了一种计算机程序产品,其包括其中存储有计算机可执行程序代码指令的至少一个非暂时性计算机可读存储介质,这些计算机可执行程序代码指令包括被配置为在执行时执行以下操作的程序代码指令:访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为一个或多个媒体轨道;形成轨道级子样本描述框,该轨道级子样本描述框包括用于相应的多个子样本的多个子样本条目类型;以及通过在该轨道级子样本描述框的编解码器特定参数相关的字段中包括相应的点云单元报头信息,指示一个或多个类型的点云压缩编码比特流分量。在一些实施例中,这些程序代码指令可以进一步被配置为在执行时:扩展子样本信息框,以通过以下操作来指示子样本条目索引:在相关的子样本描述框中指示子样本条目的存在顺序,并进一步经由版本值或者在所述子样本信息框中设置标志来指示其存在。在一些实施例中,所述至少一个媒体轨道具有经由所述子样本条目索引而信令传送的打包类型。在一些实施例中,这些计算机可执行程序代码指令可以进一步包括被配置为在执行时执行以下操作的程序代码指令:访问属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流;检测该属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流遵循兼容的编码和定时结构;以及至少基于该兼容的编码和定时结构来构建并存储视频媒体轨道。在一些实施例中,所述点云压缩编码比特流包括至少一个属性信息比特流、至少一个几何形状信息比特流、至少一个占用信息比特流、以及至少一个补片信息比特流。在一些实施例中,这些计算机可执行程序代码指令可以进一步包括被配置为在执行时执行以下操作的程序代码指令:访问该属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流;将该属性信息码流存储在属性视频媒体轨道中;将该几何形状信息比特流存储在几何形状视频媒体轨道中;将该占用信息比特流存储在占用视频媒体轨道中;将该补片信息比特流存储在另一个编码媒体或元数据轨道中;以及在文件中构建并存储元数据,该元数据指示该属性视频媒体轨道、几何形状视频媒体轨道、占用视频媒体轨道和单独的编码媒体或元数据轨道的一个或多个分量的模式。在一些实施例中,该元数据是交错指示符元数据,其指示该属性视频媒体轨道、几何形状视频媒体轨道、占用视频媒体轨道和单独的编码媒体或元数据轨道的所述一个或多个分量的交错模式。在一些实施例中,针对其指示模式的所述一个或多个分量中的每一个可使用SubSampleInformationBox访问,所述SubSampleInformationBox针对所述一个或多个分量定义顺序和配置信息,所述SubSampleInformationBox被配置为指示所述模式。在一些实施例中,存储包括:以国际标准化组织基础媒体文件格式(ISOBMFF)存储不同的基于视频的点云压缩结构。
在一些实施例中,一种方法可以包括:访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为一个或多个媒体轨道;定义多个子样本描述索引框,子样本描述索引框包括子样本描述条目索引,所述子样本描述索引框被存储在和与所述多个子样本描述索引框相关联的相应的多个子样本信息框相同的容器中;以及向所述多个子样本描述索引框的相应的子样本描述索引框和所述多个子样本信息框的相应的子样本信息框添加唯一标识符,所述唯一标识符可操作以标识与第一子样本信息框相关联的第一子样本描述索引框。
在一些实施例中,一种方法可以包括:访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为与电影片段的样本相关联的一个或多个媒体轨道;定义多个子样本描述索引框,子样本描述索引框包括子样本描述条目索引,所述子样本描述索引框被存储在和与所述多个子样本描述索引框相关联的相应的多个子样本信息框相同的容器中;以及扩展轨道片段报头框以包括应用于该电影片段的样本的一组所述子样本描述条目索引。
在一些实施例中,一种方法可以包括:访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为与电影片段的样本相关联的一个或多个媒体轨道;以及对所述一个或多个媒体轨道的样本描述框内的多个样本实体进行索引。
根据其他实施例,提供了用于解码根据本本所描述的任何实施例编码的任何点云视频的方法、装置、和/或计算机程序产品。
附图说明
已经如此概括地描述了本公开的某些示例实施例,下文将参考附图,这些附图未必按比例绘制,并且其中:
图1是可根据本公开的示例实施例而具体配置的装置的框图;
图2A和2B是根据本公开的示例实施例示出诸如由图1的装置执行的一组操作的图形表示;
图3示出根据本公开的示例实施例用于V-PCC的视频数据存储结构的示例;
图4是根据本公开的示例实施例示出诸如由图1的装置执行的一组操作的流程图;
图5是根据本公开的示例实施例示出诸如由图1的装置执行的一组操作的流程图;
图6是根据本公开的示例实施例示出诸如由图1的装置执行的一组操作的流程图;
图7是根据本公开的示例实施例示出诸如由图1的装置执行的一组操作的流程图。
具体实施方式
现在将在下文中参考附图更全面地描述一些实施例,在附图中示出了本发明的一些但并非全部的实施例。实际上,本发明的各种实施例可以以许多不同的形式体现并且不应被解释为限于本文中阐述的实施例;相反,提供这些实施例使得本公开将满足适用的法律要求。相同的附图标记始终指代相同的元件。如本文所使用的,术语“数据”、“内容”、“信息”及类似术语可以互换使用以指代能够根据本发明的实施例被发送、接收和/或存储的数据。因此,任何此类术语的使用都不应被视为限制本发明的实施例的精神和范围。
此外,如本文所使用的,术语“电路”是指:(a)仅硬件电路实现(例如,模拟和/或数字电路的实现);(b)电路和计算机程序产品的组合,该计算机程序产品包括存储在一个或多个计算机可读存储器上的软件和/或固件指令,其一起工作以使装置执行本文所描述的一个或多个功能;以及(c)电路,诸如微处理器或微处理器的一部分,其需要软件或固件来操作,即使该软件或固件在物理上不存在。“电路”的这一定义适用于在本文中该术语的所有使用,包括在任何权利要求中的使用。作为另一示例,如本文所使用的,术语“电路”还涵盖包括一个或多个处理器和/或其部分及其随附的软件和/或固件的实现。作为另一示例,本文所使用的术语“电路”还包括例如用于移动电话的基带集成电路或应用处理器集成电路,或者服务器、蜂窝网络设备、其他网络设备、和/或其他计算设备中的类似集成电路。
如本文中所定义的,“计算机可读存储介质”是指非暂时性物理存储介质(例如,易失性或非易失性存储设备),其可以与“计算机可读传输介质”不同,“计算机可读传输介质”是指电磁信号。
根据示例实施例,提供了用于在视频编码中信令传送和存储压缩点云的方法、装置和计算机程序产品。该方法、装置和计算机程序产品可以与多种视频格式结合使用,包括高效视频编码标准(HEVC或H.265/HEVC)、高级视频编码标准(AVC或H.264/AVC)、即将推出的多功能视频编码标准(VVC或H.266/VVC)、和/或各种视频和多媒体文件格式,包括国际标准化组织(ISO)基础媒体文件格式(ISO/IEC 14496-12,其可被缩写为如ISOBMFF)、运动图像专家组(MPEG)-4文件格式(ISO/IEC 14496-14,也被称为MP4格式)、用于NAL(网络抽象层)单元结构化视频的文件格式(ISO/IEC 14496-15)以及第三代合作伙伴计划(3GPP文件格式)(3GPP技术规范26.244,也被称为3GP格式)。ISOBMFF是用于派生所有上述文件格式的基础。结合HEVC描述了示例实施例,然而,本公开不限于HEVC,而是针对一个可能的基础而给出描述,在此基础上可以部分地或完全地实现本公开的示例实施例。
本公开的一些方面涉及容器文件格式,诸如国际标准化组织(ISO)基础媒体文件格式(ISO/IEC 14496-12,可被缩写为ISOBMFF)、运动图像专家组(MPEG)-4文件格式(ISO/IEC 14496-14,也被称为MP4格式)、用于NAL(网络抽象层)单元结构化视频的文件格式(ISO/IEC 14496-15)以及第三代合作伙伴计划(3GPP文件格式)(3GPP技术规范26.244,也被称为3GP格式)。结合ISOBMFF或其派生物描述了示例实施例,然而,本公开不限于ISOBMFF,而是针对一个可能的基础而给出描述,在此基础上可以部分地或完全地实现本公开的示例实施例。
分别用于H.264/高级视频编码(AVC)或HEVC编码器的输出和H.264/AVC或HEVC解码器的输入的基本单元(elementary unit)是网络抽象层(NAL)单元。为了在面向分组的网络上进行传输或者存储到结构化文件中,NAL单元可以被封装到分组或类似结构中。在ISO基础媒体文件格式(ISOBMFF)中,访问单元的NAL单元形成样本,其大小在文件格式元数据中提供。ISOBMFF例如可以封装V-PCC数据。例如,在本文所描述的一些实施例中,基于ISOBMFF的数据封装和信令机制可被用于封装MPEG V-PCC编码内容的V-PCC数据。
已经在H.264/AVC和HEVC中针对不提供成帧结构的传输或存储环境而规定了字节流格式。该字节流格式通过在每个NAL单元前面附加起始码来将NAL单元彼此分开。为了避免错误检测NAL单元边界,编码器运行面向字节的起始码仿真预防算法,如果出现起始码,则该算法向NAL单元有效载荷添加仿真预防字节。为了在面向分组和面向流的系统之间使能直接的网关操作,可以始终执行起始码仿真预防,而无论字节流格式是否在使用中。NAL单元可以被定义为如下语法结构:包含对要遵循的数据类型的指示和包含原始字节序列有效载荷(RBSP)形式的数据的字节,在必要时,其中分散有仿真预防字节。RBSP可以被定义为如下语法结构:包含被封装在NAL单元中的整数数量的字节。RBSP要么为空,要么具有数据比特串的形式,其中包含语法元素,接着是RBSP停止比特,然后是等于0的零个或多个后续比特。
NAL单元可以被分类成视频编码层(VCL)NAL单元和非VCL NAL单元。VCL NAL单元通常是编码切片NAL单元。
非VCL NAL单元例如可以是以下类型之一:序列参数集、图像参数集、补充增强信息(SEI)NAL单元、访问单元分隔符(delimiter)、序列NAL单元的结尾、比特流NAL单元的结尾、或填充数据NAL单元。重构解码图像可需要参数集,而许多其他非VCL NAL单元对于重构解码样本值并非必需的。
SEI NAL单元可以包含一个或多个SEI消息,这些SEI消息对于解码输出图像并非必需的,但可以帮助相关过程,诸如图像输出定时、渲染、错误检测、错误隐藏、以及资源保留。在H.264/AVC和HEVC中规定了若干SEI消息,并且用户数据SEI消息使组织和公司能够指定SEI消息供其自己使用。H.264/AVC和HEVC包含用于所规定的SEI消息的语法和语义,但没有定义用于在接收方中处理这些消息的过程。因此,编码器在创建SEI消息时需要遵循H.264/AVC标准或HEVC标准,而不需要分别符合H.264/AVC标准或HEVC标准的解码器来处理SEI消息以获得输出顺序一致性(output order conformance)。在H.264/AVC和HEVC中包括SEI消息的语法和语义的原因之一是允许不同的系统规范以相同的方式解释补充信息,从而实现互操作。预计系统规范可要求在编码端和解码端两者中都使用特定SEI消息,另外,可以规定用于在接收方中处理特定SEI消息的过程。
在HEVC中,存在两种类型的SEI NAL单元,即,后缀SEI NAL单元和前缀SEI NAL单元,它们具有彼此不同的nal_unit_type值。包含在后缀SEI NAL单元中的SEI消息与按解码顺序在该后缀SEI NAL单元前面的VCL NAL单元相关联。包含在前缀SEI NAL单元中的SEI消息与按解码顺序在该前缀SEI NAL单元后面的VCL NAL单元相关联。
视频编码规范可以包含用于将数据单元(例如,H.264/AVC或HEVC中的NAL单元)关联到访问单元的一组约束。这些约束可用于从NAL单元序列中推断出访问单元边界。例如,在HEVC标准中规定了以下内容:
-访问单元由一个nuh_layer_id等于0的编码图像、nuh_layer_id大于0的零个或多个视频编码层(VCL)NAL单元以及零个或多个非VCL NAL单元组成。
-令firstBlPicNalUnit是nuh_layer_id等于0的编码图像的第一VCL NAL单元。在firstBlPicNalUnit前面并在firstBlPicNalUnit前面的最后一个VCL NAL单元后面的任何随后的NAL单元中的第一个(如果有)规定了新的访问单元的起始:
οnuh_layer_id等于0的访问单元分隔符NAL单元(如果存在),
οnuh_layer_id等于0的视频参数集(VPS)NAL单元(如果存在),
οnuh_layer_id等于0的序列参数集(SPS)NAL单元(如果存在),
οnuh_layer_id等于0的图像参数集(PPS)NAL单元(如果存在),
οnuh_layer_id等于0的前缀补充增强信息(SEI)NAL单元(如果存在),
οnal_unit_type在RSV_NVCL41...RSV_NVCL44的范围内(其表示保留NAL单元)nuh_layer_id等于0的NAL单元(如果存在),
οnal_unit_type在UNSPEC48...UNSPEC55的范围内(其表示未规定NAL单元)nuh_layer_id等于0的NAL单元(如果存在)。
在firstBlPicNalUnit前面并在firstBlPicNalUnit前面的最后一个VCL NAL单元后面的第一NAL单元(如果有)只能是上面列出的NAL单元之一。
-当不存在上述在firstBlPicNalUnit前面并在firstBlPicNalUnit前面的最后一个VCL NAL后面的NAL单元(如果有)时,firstBlPicNalUnit开始新的访问单元。
帧打包可以被定义为包括将多于一个的输入图像(其可被称为(输入)构成帧(constituent frame))排列成输出图像。通常,帧打包不限于任何特定类型的构成帧,或者构成帧不需要彼此具有特定关系。在许多情况下,帧打包用于将立体视频剪辑的构成帧排列成单个图像序列。该排列(arranging)可以包括将输入图像放置在输出图像内的空间非重叠区域中。例如,在并排布置(side-by-side arrangement)中,两个输入图像被彼此水平相邻地放置在输出图像内。该排列还可以包括将一个或多个输入图像分割成两个或更多个构成帧部分(partitions),并将这些构成帧部分放置在输出图像内的空间非重叠区域中。输出图像或帧打包输出图像序列可以例如通过视频编码器被编码成比特流。该比特流可以例如由视频解码器进行解码。在解码之后,解码器或后处理操作可以从解码图像中提取解码构成帧,例如以用于显示。
ISO基础媒体文件格式中的基础构建块(building block)被称为框(box)。每个框具有报头和有效载荷。框报头指示框的类型并以字节为单位指示框的大小。框可以包括其他框,并且ISO文件格式规定在特定类型的框中允许哪些框类型。此外,在每个文件中一些框的存在可以是强制性的,而其他框的存在可以是可选的。此外,对于某些框类型,可以允许文件中存在多于一个的框。因此,ISO基础媒体文件格式可以被认为规定框的层级结构。
根据ISO基础媒体文件格式,文件包括被封装在框中的媒体数据和元数据。每个框由一个四字符码(4CC)标识,并以通知关于框的类型和大小的报头开始。
根据ISO基础媒体文件格式而格式化的许多文件以文件类型框(也被称为FileTypeBox或ftyp框)开始。ftyp框包含标记文件的类型(brands)的信息。ftyp框包括一个主要类型指示和以及兼容类型列表。主要类型标识用于解析文件的最合适的文件格式规范。兼容类型指示文件符合哪些文件格式规范和/或一致性点(conformance points)。一个文件可以符合多个规范。应当列出指示与这些规范的兼容性的所有类型,以便仅了解部分兼容类型的读者可以获得可解析文件的指示。兼容类型还准许特定文件格式规范的文件解析器处理在ftyp框中包含相同的特定文件格式类型的文件。文件播放器可以检查文件的ftyp框是否包括它支持的类型,并且仅在文件播放器所支持的任何文件格式规范被列出在兼容类型中时才可以解析并播放文件。
在符合ISO基础媒体文件格式的文件中,媒体数据可以在MediaDataBox('mdat')的一个或多个实例中提供,并且MovieBox('moov')可用于包括定时媒体的元数据。在某些情况下,为了使文件可操作,可要求'mdat'和'moov'框两者同时存在。'moov'框可以包括一个或多个轨道,并且每个轨道可以驻留在一个对应的TrackBox('trak')中。每个轨道与处理器(handler)相关联,由四字符码标识,规定轨道类型。视频、音频和图像序列轨道可以统称为媒体轨道,并且它们包含基本媒体流。其他轨道类型包括提示轨道和定时元数据轨道。
轨道包括样本,诸如音频或视频帧。对于视频轨道,媒体样本可以对应于编码图像或访问单元。媒体轨道是指根据媒体压缩格式(及其对ISO基础媒体文件格式的封装)而格式化的样本(其也可以被称为媒体样本)。提示轨道是指提示样本,其包含用于构建分组以通过所指示的的通信协议传输的说明(cookbook)指令。定时元数据轨道可以是指描述所引用的媒体和/或提示样本的样本。
'trak'框在其框层级中包括SampleTableBox(也被称为样本表或样本表框)。SampleTableBox包含SampleDescriptionBox,其提供关于所使用的编码类型的详细信息、以及编码所需的任何初始化信息。SampleDescriptionBox包含条目计数以及该条目计数指示的尽可能多的样本条目。样本条目的格式是轨道类型特定的,但从通用类(例如,VisualSampleEntry、AudioSampleEntry)派生。用于派生轨道类型特定样本条目格式的样本条目形式的类型由轨道的媒体处理器确定。
TrackTypeBox可以被包含在TrackBox中。TrackTypeBox的有效载荷与FileTypeBox的有效载荷具有相同的语法。TrackTypeBox实例的内容的应用可以与FileTypeBox内容的应用相同,如果文件的所有其他轨道都被移除并且只有包含此框的轨道仍保留在该文件中。
例如当将内容记录到ISO文件时,可以使用电影片段,例如以避免在记录应用崩溃、内存空间用完或某些其他事件发生时丢失数据。如果没有电影片段,可能会发生数据丢失,因为文件格式可要求将所有元数据(例如,电影框)写入文件的一个连续区域中。此外,在记录文件时,可能针对可用存储大小没有足够的内存空间量来缓冲电影框,并且在电影被关闭时重新计算电影框的内容可能太慢。此外,电影片段可以使能使用常规ISO文件解析器来同时记录并播放文件。此外,渐进式下载(例如,当使用电影片段的同时接收并播放文件)可能需要更短的初始缓冲持续时间,并且与具有相同的媒体内容但未构造有电影片段的文件相比,初始电影框更小。
电影片段(fragment)特征可以使能将否则可能驻留在电影框中的元数据划分成多个部分(pieces)。每个部分可以对应于某一时间段的轨道。换句话说,电影片段特征可以使能交错文件元数据和媒体数据。因此,电影框的大小可受到限制,并且实现上述用例。
在一些示例中,电影片段的媒体样本可以驻留在mdat框中。然而,对于电影片段的元数据,可以提供moof框。moof框可以包括先前已经在moov框中的某一播放时间的某一持续时间的信息。moov框本身仍然可以表示一个有效的电影,但另外,它可以包括指示电影片段将在相同文件中跟随的mvex框。电影片段可以扩展在时间上与moov框相关联的呈现。
在电影片段内可以存在一组轨道片段,其包括每轨道从零到多个轨道片段的任何位置。轨道片段进而可以包括从零到多个轨道运行的任何位置,每个轨道运行文件是该轨道的连续运行样本(并因此与块(chunks)类似)。在这些结构中,许多字段是可选的,并且可以是默认的。可在moof框中包括的元数据可被限制为可在moov框中包括的元数据的子集,并且在某些情况下可以被不同地编码。关于可在moof框中包括的框的详细信息可以从ISOBMFF规范中找到。
自包含电影片段可以被定义为由按照文件顺序是连续的moof框和mdat框组成,其中mdat框包含电影片段(moof框为其提供元数据)的样本,而不包含任何其他电影片段(即,任何其他moof框)的样本。媒体片段可以包括一个或多个自包含电影片段。媒体片段可被用于递送,诸如流传输,例如,采用基于超文本传输协议(HTTP)的MPEG动态自适应流传输(MPEG-DASH)。
轨道引用机制可用于将轨道彼此相关联。TrackReferenceBox包括框,每个框提供从包含轨道到一组其他轨道的引用。这些引用通过被包含框的框类型(例如,框的四字符码)来标记。ISO基础媒体文件格式包含三种用于可与特定样本相关联的定时元数据机制:样本组、定时元数据轨道、以及样本辅助信息。所派生的规范可以通过这三种机制中的一种或多种来提供类似的功能。
在TrackBox中包含的TrackGroupBox使能指示轨道组,其中,每个组共享特定特性或者组内的轨道具有特定关系。该框包含零个或多个框,并且特定特性或关系由被包含框的框类型指示。被包含框包括标识符,其可用于识别属于同一轨道组的轨道。包含TrackGroupBox中的相同类型的被包含框并在这些被包含框内具有相同标识符值的轨道属于同一轨道组。被包含框的语法可以通过TrackGroupTypeBox定义如下:
aligned(8)class TrackGroupTypeBox(unsigned int(32)track_group_type)extends FullBox(track_group_type,version=0,flags=0)
{
unsigned int(32)track_group_id;
//the remaining data may be specified
//for a particular track_group_type
}
ISO基础媒体文件格式(ISOBMFF)包含三种用于可与特定样本相关联的定时元数据的机制:样本组、定时元数据轨道、以及样本辅助信息。所派生的规范可以通过这三种机制中的一种或多种来提供类似的功能。
ISO基础媒体文件格式及其派生物(诸如AVC文件格式和可伸缩视频编码(SVC)文件格式)中的样本分组(sample grouping)可以被定义为基于分组准则而将轨道中的每个样本分配为一个样本组的成员。样本分组中的样本组不限于连续样本,还可以包含非相邻的样本。由于针对轨道中的样本可以存在多于一个的样本分组,因此每个样本分组可以具有用于指示分组类型的类型字段。样本分组可以由两个被链接的数据结构来表示:(1)SampleToGroupBox(sbgp框)表示样本到样本组的分配;以及(2)SampleGroupDescriptionBox(sgpd box)包含每个样本组的样本组条目,其描述组的特性。基于不同的分组准则,可以存在SampleToGroupBox和SampleGroupDescriptionBox的多个实例。这些实例可以通过用于指示分组类型的类型字段来区分。SampleToGroupBox可以包括grouping_type_parameter字段,该字段可用于例如指示分组的子类型。
每样本的辅助信息可以被存储在与样本数据本身相同的文件中的任何位置。对于自包含媒体文件,通常是在MediaDataBox或来自所派生的规范的框中。它被存储在(a)多个块(chunks)中,其中每块的样本数量以及块数量与原始样本数据的分块(chunking)相匹配,或者(b)单个块中,针对电影样本表(或电影片段)中的所有样本。单个块(或轨道运行)中包含的所有样本的样本辅助信息被连续地存储(类似于样本数据)。
当存在时,样本辅助信息被存储在和与其相关联的样本相同的文件中,因为它们共享相同的数据引用('dref')结构。然而,此数据可位于此文件中的任何位置,使用辅助信息偏移('saio')来指示该数据的位置。
已经针对ISOBMFF规定了受限视频('resv')样本条目和机制,以便处理文件作者在解码视觉轨道之后要求对播放器或渲染器的某些动作的情况。无法识别或无法处理所需动作的播放器将被停止解码或渲染受限视频轨道。'resv'样本条目机制适用于任何类型的视频编解码器。RestrictedSchemeInfoBox存在于'resv'轨道的样本条目中,并包括OriginalFormatBox、SchemeTypeBox和SchemeInformationBox。除非使用'resv'样本条目类型,否则原始样本条目类型将被包含在OriginalFormatBox中。SchemeTypeBox提供播放器需要哪种类型的处理来处理视频的指示。SchemeInformationBox包括所需处理的进一步的信息。方案类型可对SchemeInformationBox的内容提出要求。例如,在SchemeTypeBox中指示的立体视频方案指示解码帧何时包含形成立体对的两个空间打包构成帧的表示(帧打包)或者仅立体对的一个视图(在不同的轨道中的左视图和右视图)。StereoVideoBox可以被包含在SchemeInformationBox中以提供进一步的信息,例如,关于已使用哪种类型的帧打包布置(例如,并排(side-by-side)或上下(top-bottom))。
在一些实施例中,SchemeInformationBox可以包括V3CUnitHeaderBox。在一些实施例中,SchemeInformationBox可以具有数量为0或1的Multimap Video Box('mmvi')的框类型。在一些实施例中,'mmvi'可用于指示解码帧包含表示图(maps)的两个或更多个临时交错帧。在一些实施例中,在V3C数据的单个轨道封装的情况下,可以不存在'mmvi'框。在一些实施例中,当'mmvi'或MultiMapVideoBox存在时,它可以指示使用时间交错图打包布置。在一些实施例中,文件解析器可以隐式地将map_count_minus1+1个连续样本的合成时间设置为等于交错图打包布置中的样本组的第一样本的合成时间。在一些实施例中,当使用时间交错图打包布置时,由流访问点样本组指示的每个同步样本(sync sample)和SAP_type在1到3的范围内(包括端点)的每个SAP样本可以表示样本的迭代布置,按照合成时间顺序表示图0到map_count_minus1,直到但不包括由流访问点样本组指示的下一同步样本或SAP_type在1到3的范围内(包括端点)的下一SAP样本为止。
在一些实施例中,用于'mmvi'框的语法例如可以是:
Figure BDA0003671411680000191
在一些实施例中,map_count_minus1加1可以指示作为连续样本存在于轨道中的图的数量。
已经规定了若干类型的流访问点(SAP)。SAP Type 1对应于某些编码方案中已知的“封闭图像组(GOP)随机访问点”(其中按解码顺序的所有图像可以被正确解码,从而得到没有间隙的正确解码图像的连续时间序列),此外,解码顺序中的第一个图像也是呈现顺序中的第一个图像。SAP Type 2对应于某些编码方案中已知的“封闭GOP随机访问点”(其中按解码顺序的所有图像可以被正确解码,从而得到没有间隙的正确解码图像的连续时间序列),其中,解码顺序中的第一个图像可以不是呈现顺序中的第一个图像。SAP Type 3对应于某些编码方案中已知的“开放GOP随机访问点”,其中按解码顺序的一些图像可能无法被正确解码,并且呈现时间少于与SAP相关联的帧内编码图像。
如在ISOBMFF中规定的流访问点(SAP)样本组将样本识别为所指示的SAP类型。
同步样本可以被定义为对应于SAP Type 1或2的样本。同步样本可以被认为是开始新的独立样本序列的媒体样本;如果解码在同步样本开始,则该同步样本和解码顺序中的后续样本都可以被正确解码,并且所得到的解码样本组形成从具有最早合成时间的解码样本开始的媒体的正确呈现。同步样本可以用SyncSampleBox(对于那些元数据存在于TrackBox中的样本)指示,或者在针对轨道片段运行而指示或意指的样本标志中指示。
符合ISOBMFF的文件可以在meta框(fourCC:'meta',也可被称为MetaBox)中包含任何非定时对象,被称为项(item)、meta项、或元数据项。虽然meta框的名称是指元数据,但项通常可以包含元数据或媒体数据。meta框可以驻留文件的顶层、电影框(fourCC:'moov')内、以及轨道框(fourCC:'trak')内,但在每个文件级、电影级或轨道级可以出现最多一个meta框。meta框可需要包含'hdlr'框,以指示'meta'框内容的结构或格式。meta框可以列出并表征能够被引用的任意数量的项,并且每个项可以与文件名相关联,并可以由项标识符(item_id,其整数值)与文件唯一地被标识。元数据项例如可以被存储在meta框的'idat'框中、或者'mdat'框中、或者驻留在单独的文件中。如果元数据位于文件外部,则它的位置可以由DataInformationBox(fourCC:'dinf')声明。在元数据使用可扩展标记语言(XML)语法而格式化并需要被直接存储在MetaBox中的特定情况下,元数据可以被封装到XMLBox(fourCC:'xml')或BinaryXMLBox(fourcc:'bxml')中。项可以被存储为连续的字节范围,或者可以被存储在若干范围(extents)内,每个范围是连续的字节范围。换句话说,项可以被分段存储成范围(extents),例如以使能交错。范围是资源的字节的连续子集,并且资源可以通过连接多个范围来形成。
高效图像文件格式(HEIF)是由运动图像专家组(MPEG)开发的用于存储图像和图像序列的标准。除其他外,该标准促进了根据高效视频编码(HEVC)标准编码的数据的文件封装。HEIF包括在所使用的ISO基础媒体文件格式(ISOBMFF)之上构建的功能。
ISOBMFF结构和特征在很大程度上用于HEIF的设计。HEIF的基本设计包括将静止图像存储为项,而将图像序列存储为轨道。
在HEIF的上下文中,以下框可以被包含在根级'meta'框内并且可以如下所述地使用。在HEIF中,'meta'框的Handler框的处理器值是'pict'。包含编码媒体数据的资源(无论是在同一文件内,还是在由统一资源标识符标识的外部文件中)通过数据信息('dinf')框解析,而项位置('iloc')框存储所引用的文件中每个项的位置和大小。项引用(“iref”)框使用类型化引用来记录项之间的关系。如果项集合中的一项在某种程度上被认为与其他项相比最重要,则该项通过主要项('pitm')框来信令传送。除了在此提到的框之外,'meta'框还可以灵活地包括描述项所需的其他框。
任何数量的图像项可以被包括在同一文件中。给定使用'meta'框方法存储的图像集合,图像之间的某些关系可以是有资格的。这种关系的示例包括指示集合的封面图像,提供集合中的一些或所有图像的缩略图(thumbnail images),以及将集合中的一些或所有图像与诸如阿尔法平面之类的辅助图像相关联。使用'pitm'框来指示图像集合中的封面图像。缩略图或辅助图像分别使用'thmb'或'auxl'类型的项引用而被链接到主图像项。
ItemPropertiesBox使能任何项与一组有序的项特性相关联。项特性是小型数据记录。ItemPropertiesBox由两个部分组成:ItemPropertyContainerBox,其包含隐式索引的项特性列表;以及一个或多个ItemPropertyAssociationBox,其将项与项特性相关联。项特性被格式为框。
描述性项特性可以被定义为描述而不是变换关联项的项特性。变换性项特性可以被定义为变换图像项内容的重构表示的项特性。
实体可以被定义为轨道或项的统称。实体组是项的分组,也可以对轨道进行分组。当分组实体没有明确的依赖关系或定向引用关系时,可以使用实体组来代替项引用。实体组中的实体共享特定特性或者具有特定关系,如由分组类型所指示的。
实体组是项的分组,也可以对轨道进行分组。实体组中的实体共享特定特性或者具有特定关系,如由分组类型所指示的。
实体组在GroupsListBox中指示。在文件级MetaBox的GroupsListBox中指定的实体组是指轨道或文件级项。在电影级MetaBox的GroupsListBox中指定的实体组是指电影级项。在轨道级MetaBox的GroupsListBox中指定的实体组是指该轨道的轨道级项。
GroupsListBox包含EntityToGroupBox,每个指定一个实体组。EntityToGroupBox的语法可以被规定如下:
Figure BDA0003671411680000221
其中,当item_ID等于entity_id的项存在于包含GroupsListBox的层级(文件、电影或轨道)中时,entity_id被解析为项,或者,当track_ID等于entity_id的轨道存在并且GroupsListBox被包含在文件级中时,entity_id被解析为轨道。
按区域打包信息可以被编码为视频比特流中或沿视频比特流的元数据,例如,OMAF的RegionWisePackingBox中和/或HEVC或H.264/AVC的按区域打包SEI消息中。例如,打包信息可以包括从预定义或所指示的源格式到打包帧格式的按区域映射,例如,从投影图像到打包图像的映射,如前所述。
按区域打包例如可以是按矩形区域打包。接下来在将全向投影图像(例如,等矩形或立方图投影)的区域与打包图像的区域(例如,经受编码或解码)相关联的上下文中描述示例按矩形区域打包元数据:对于每个区域,元数据定义投影图像中的矩形,打包图像中的相应的矩形,以及旋转90、180或270度和/或水平和/或垂直镜像的可选变换。矩形例如可以由左上角和右下角的位置指示。映射可以包括重采样。由于投影和打包图像中相应的矩形的大小可不同,因此该机制意指按区域重采样。
多用途互联网邮件扩展(MIME)是电子邮件协议的扩展,其使得能够在互联网上发送和接收不同种类的数据文件,例如,视频和音频、图像、软件等。互联网媒体类型是用于在互联网上指示文件包含的数据的类型的标识符。这种互联网媒体类型也可被称为内容类型。存在可以包含不同媒体格式的若干MIME类型/子类型组合。内容类型信息可以在媒体传输开始时由发送实体包括在MIME报头中。因此,接收实体可需要检查这种媒体内容的细节以确定在给定一组可用的编解码器的情况下是否可以渲染特定元素。特别是当终端系统具有有限的资源,或者与终端系统的连接具有有限的带宽时,仅从内容类型知道是否可以渲染内容可以是有帮助的。
互联网工程任务组(IETF)征求意见(RFC)6381规定了两个参数即'编解码器(codecs)'和'配置文件(profiles)',它们与各种MIME类型或类型/子类型组合一起使用,以允许明确规定由包含在其中的媒体格式使用的编解码器,或者全部容器格式的配置文件。
通过在编解码器MIME参数中用被指示渲染所包含的媒体的特定编解码器标记内容,接收系统可以确定终端系统是否支持编解码器,如果不支持,则可以采取合适的动作(诸如拒绝内容,发送情况通知,将内容转码为所支持的类型,获取并安装所需的编解码器,进一步检查以确定是否它将足以支持所指示的编解码器的子集等)。
对于从ISOBMFF派生的文件格式,在RFC 6381中规定的编解码器参数是从由MIME类型描述的文件的轨道的样本条目类型派生的。
类似地,在RFC 6381中规定的配置文件参数可以向接收者提供内容符合的规范的总体指示。这是容器格式及其内容与某些规范的兼容性的指示。接收者可能够通过检查它支持哪些所声明的配置文件以及它们的含义而得出它可以处理并渲染内容的程度。对于从ISOBMFF派生的文件格式,配置文件MIME参数包含四字符码列表,这些四字符码在由MIME类型描述的文件的FileTypeBox中被指示为兼容类型。
无论视频比特流的文件格式如何,示例实施例的装置都可以由多种计算设备中的任何一种来提供,例如包括视频编码器、视频解码器、计算机工作站、服务器等,或者由各种移动计算设备中的任何一种来提供,诸如移动终端,例如,智能手机、平板计算机、视频游戏播放器等。
无论体现该装置的计算设备如何,示例实施例的装置10都包括如图1中所示的处理电路12、存储器14、通信接口16和可选的用户接口18,或者与它们相关联,或者以其他方式与它们通信。
处理电路12可以经由总线与存储器设备14通信,以在装置10的组件之间传递信息。存储器设备可以是非暂时性的,并且例如可以包括一个或多个易失性和/或非易失性存储器。换句话说,例如,存储器设备可以是电子存储设备(例如,计算机可读存储介质),其包括被配置为存储可由机器(例如,如处理电路之类的计算设备)获取的数据(例如,比特)的门。存储器设备可以被配置为存储信息、数据、内容、应用、指令等,以使得装置能够执行根据本公开的示例性实施例的各种功能。例如,存储器设备可以被配置为缓冲输入数据以由处理电路进行处理。附加地或可替代地,存储器设备可以被配置为存储由处理电路执行的指令。
在一些实施例中,装置10可以被体现在如上所述的各种计算设备中。然而,在一些实施例中,该装置可以被体现为芯片或芯片组。换句话说,该装置可以包括一个或多个物理封装(例如,芯片),其包括在结构配件(例如,基板)上的材料、组件和/或导线。该结构配件可以为在其上包括的组件电路提供物理强度、尺寸保护、和/或电相互作用的限制。因此,在一些情况下,该装置可以被配置为在单个芯片上实现本公开的实施例,或者将本公开的实施例实现为单个“芯片上系统”。由此,在一些情况下,芯片或芯片组可以构成用于执行用于提供本文所描述的功能的一个或多个操作的部件。
处理电路12可以采用多个不同的方式来体现。例如,处理电路可以被实现为一个或多个各种硬件处理部件,诸如协处理器、微处理器、控制器、数字信号处理器(DSP)、具有或不具有随附DSP的处理单元、或各种其他电路,包括集成电路,例如,ASIC(专用集成电路)、FPGA(现场可编程门阵列)、微控制器单元(MCU)、硬件加速器、专用计算机芯片等。如此,在一些实施例中,处理电路可以包括一个或多个被配置为独立地执行的处理核。多核处理电路可以在单个物理封装内实现多处理。附加地或可替代地,处理电路可以包括经由总线协作配置的一个或多个处理器,以实现独立的指令执行、流水线和/或多线程。
在示例性实施例中,处理电路12可以被配置为执行被存储在存储器设备14中或以其他方式可由处理电路访问的指令。可替代地或附加地,处理电路可以被配置为执行硬编码的功能。由此,无论是通过硬件或软件方法而配置还是通过其组合而配置,在相应地进行配置时,处理电路都可以表示能够执行根据本公开的实施例的操作的实体(例如,物理地体现在电路中)。因此,例如,当处理电路被体现为ASIC、FPGA等时,处理电路可以是用于进行本文所描述的操作的专门配置的硬件。可替代地,作为另一个示例,当处理电路被体现为指令的执行器时,这些指令可以具体地配置处理器以在执行这些指令时执行本文所描述的算法和/或操作。然而,在一些情况下,处理电路可以是特定设备(例如,图像或视频处理系统)的处理器,该特定设备被配置为通过处理电路的进一步配置通过用于执行本文所描述的算法和/或操作的指令来使用本发明的实施例。处理电路尤其可以包括时钟、算术逻辑单元(ALU)以及被配置为支持处理电路的操作的逻辑门。
通信接口16可以是诸如以硬件或硬件和软件的组合而体现的设备或电路之类的被配置为接收和/或发送数据(包括视频比特流)的任何部件。就此而言,通信接口例如可以包括天线(或多个天线)以及用于支持与无线通信网络的通信的支持硬件和/或软件。附加地或可替代地,通信接口可以包括用于与天线交互以经由天线的信号发送或处理经由天线接收的信号接收的电路。在一些环境中,通信接口可以可替代地或还支持有线通信。如此,例如,通信接口可以包括用于支持经由电缆、数字用户线路(DSL)、通用串行总线(USB)或其他机制进行通信的通信调制解调器和/或其他硬件/软件。
在一些实施例中,诸如在装置10被配置为对视频比特流进行编码的情形下,装置10可以可选地包括用户接口18,用户接口18继而可以与处理电路12进行通信,以向用户提供输出,诸如通过输出编码的视频比特流,以及在一些实施例中接收用户输入的指示。如此,用户接口可以包括显示器,以及在一些实施例中,还可以包括键盘、鼠标、操纵杆、触摸屏、触摸区域、软键、麦克风、扬声器、或其他输入/输出机制。可替代地或附加地,处理电路可以包括用户接口电路,其被配置为控制一个或多个用户接口单元的至少一些功能,该一个或多个用户接口单元诸如是显示器,以及在一些实施例中是扬声器、振铃器、和/或麦克风等。处理电路和/或包括处理电路的用户接口电路可以被配置为通过被存储在处理电路可访问的存储器(例如,存储器设备14等)上的计算机程序指令(例如,软件和/或固件)来控制一个或多个用户接口单元的一个或多个功能。
当描述HEVC时并且在某些示例实施例中,可以使用用于算术运算符、逻辑运算符、关系运算符、逐位运算符、赋值运算符和范围符号的通用符号(common notation),例如,如在HEVC中所指定的。此外,可以使用例如如在HEVC中所指定的通用数学函数,并且可以使用例如如在HEVC中所指定的运算符的通用顺序或优先权(precedence)和执行顺序(从左到右或从右到左)。
当描述使用HEVC的示例实施例时,仅语法结构的相关部分被包括在语法和语义的描述中。然而,其他实施例可以类似地以语法元素的不同顺序和名称来实现。
在描述示例实施例时,术语文件有时被用作语法结构的同义词或语法结构的实例。在其他上下文中,术语文件可被用于表示计算机文件,即,在存储中形成独立单元的资源。
当描述HEVC时并且在某些示例实施例中,可以如本文所描述地规定语法结构。用大括号包括的一组语句(statements)是复合语句,并且在功能上被视为单个语句。“while”结构指定条件是否为真的测试,如果为真,则指定重复评估语句(或复合语句),直到条件不再为真为止。“do...while”结构指定评估语句一次,然后是条件是否为真的测试,如果为真,则指定重复评估该语句,直到条件不再为真为止。“if...else”结构指定条件是否为真的测试,如果条件为真,则指定对主要语句的评估,否则,指定对替代语句的评估。如果不需要任何替代语句评估,则省略该结构的“else”部分和相关联的替代语句。“for”结构指定对初始语句的评估,然后是条件的测试,如果条件为真,则指定对主要语句的重复评估,然后是后续语句,直到条件不再为真为止。
体积视频数据表示三维场景或对象,并且可以用作AR、VR和MR应用的输入。这种数据描述了几何形状(3D空间中的形状、大小和位置)和相应的属性(例如,颜色、不透明度、反射率等),以及几何结构和属性在给定时间实例(如2D视频中的帧)的任何可能的在时间上的变化。立体视频或者从3D模型(即,CGI)生成,或者使用各种捕获解决方案(例如,多相机、激光扫描、视频和专用深度传感器的组合等)从现实世界场景中捕获。此外,CGI和现实世界数据的组合也是可能的。这种体积数据的典型表示格式是三角形网格、点云、或体素。关于场景的时间信息可以被包括在个体捕获实例的形式(即,2D视频中的“帧”)中,或者采用其他机制,例如,作为时间函数的对象的位置。
点云是一种体积内容的形式,已知其很差的压缩性能。MPEG一直致力于基于视频的点云压缩,其中,点云被投影到2D表面上并使用传统的视频编码工具来压缩。利用相关联的元数据,可以从2D视频中重构3D点云。
压缩点云包括对应于3D对象的属性(如空间属性、纹理、颜色、反射率、表面法线)的一个或多个编码视频比特流、对应于3D对象的几何形状的一个或多个编码视频比特流、描述2D表面占用的编码视频比特流、以及对应于在3D对象的合成期间必需的所有其他辅助信息的编码元数据比特流。然而,尚没有针对这些流的定义明确、高效且标准化的存储和信令机制。
因为体积视频表示3D场景(或对象),所以可以从任何视点观看这样的数据。因此,体积视频是用于任何AR、VR或MR应用的重要格式,尤其是用于提供6DOF观看能力。
计算资源的增加以及3D数据获取设备的进步已使能重构自然场景的高度详尽的体积视频表示。红外线、激光、飞行时间和结构光都是可以被用于构建3D视频数据的设备示例。3D数据的表示取决于如何使用3D数据。密集体素阵列已被用于表示体积医学数据。在3D图形中,多边形网格被广泛使用。另一方面,点云非常适于捕获诸如其中拓扑未必是2D流形的现实世界3D场景之类的应用。表示3D数据的另一种方法是将3D数据编码为一组纹理和深度图,就像多视图加深度的情况中那样。与在多视图加深度中使用的技术密切相关的是高度图(elevation maps)以及多级表面图(multi-level surface maps)的使用。
在密集点云或体素阵列中,重构3D场景可包含数千万甚至数亿个点。如果需要在计算实体之间存储或交换此类表示,则有效的压缩变得至关重要。标准体积视频表示格式(诸如点云、网格和体素)存在时间压缩性能差的问题。识别3D空间中运动补偿的对应关系是一个定义不明确的问题,因为几何形状和相应的属性两者都可发生变化。例如,时间连续“帧”未必具有相同数量的网格、点或体素。因此,动态3D场景的压缩效率很低。用于压缩体积数据的基于2D视频的方法(例如,多视图和深度)具有更好的压缩效率,但很少覆盖整个场景。因此,它们仅提供有限的6DOF能力。
由于上述两种方法的限制,因此开发了第三种方法。被表示为网格、点和/或体素的3D场景可以被投影到一个或多个几何结构上。这些几何结构被“展开”到2D平面上(每几何结构两个平面:一个用于纹理,一个用于深度),进而使用标准2D视频压缩技术对其进行编码。相关的投影几何信息与编码视频文件一起被发送到解码器。解码器对视频进行解码并执行逆投影,以任何期望的表示格式(未必是编码格式)重新生成3D场景。
将体积模型投影到2D平面上允许使用具有高效时间压缩的2D视频编码工具。因此,编码效率大大提高。使用几何投影而不是基于2D视频的方法(例如,多视图和深度)提供更好的场景(和/或对象)覆盖。因此,提高了6DOF能力。针对个体对象使用若干几何结构可以进一步提高场景的覆盖。此外,标准视频编码硬件可用于投影平面的实时压缩/解压缩。投影和逆投影步骤的复杂度相对较低。
图2A和2B分别提供了点云的压缩和解压缩过程的概述。如框202中所示,诸如图1的装置10之类的装置包括用于在接收输入点云帧之后的补片生成的部件,诸如处理电路12。补片生成过程旨在将点云分解成具有平滑边界的最少数量的补片,同时最小化重构误差。在MPEG文档点云编码测试模型类别2版本0.0(TMC2V0)中规定了一种补片生成的示例方式。该方法被描述如下。
首先,估计在每个点的法线。进而通过将每个点与以下六个定向平面之一相关联来获得点云的初始聚类,这些平面由其法线定义:
-(1.0,0.0,0.0),
-(0.0,1.0,0.0),
-(0.0,0.0,1.0),
-(-1.0,0.0,0.0),
-(0.0,-1.0,0.0),以及
-(0.0,0.0,-1.0)。
每个点与具有最接近法线的平面相关联(例如,最大化点法线和平面法线的点积)。进而,通过基于点的法线和点的最接近邻居的聚类索引迭代地更新与每个点相关联的聚类索引来细化初始聚类。最后的步骤包括通过应用被连接组件提取过程来提取补片。
如框204中所示,该装置包括诸如处理电路12之类的用于打包的部件。打包过程旨在将所提取的补片映射到2D网格上,同时尝试最小化未使用空间并保证网格的每个TxT(例如,16x16)块都与唯一的补片相关联。T是用户定义的参数,它被编码在比特流中并被发送到解码器。在TMC2v0中规定了一个示例打包策略。
在TMC2v0中规定的打包策略是一种简单的打包策略,它迭代地尝试将补片插入WxH网格中。W和H是用户定义的参数,它们对应于将被编码的几何/纹理图像的分辨率。补片位置是通过按栅格扫描顺序执行的穷举搜索来确定的。选择可以保证非重叠插入补片的第一位置,并且由补片覆盖的网格单元被标记为已使用。如果当前分辨率图像中没有空的空间可以容纳一个补片,则将网格的高度H暂时加倍并重新进行搜索。在此过程结束时,H被剪裁以适于所使用的网格单元。
如框206A和206B中所示,该装置包括诸如处理电路12之类的用于图像生成的部件。图像生成过程使用在打包过程期间计算的3D到2D映射以将点云的几何形状和纹理存储为图像。为了更好地处理多个点被投影到同一像素的情况,每个补片被投影到两个图像(被称为层)上。更准确地说,令H(u,v)是被投影到同一像素(u,v)的当前补片的一组点。第一层,也被称为近层,存储H(u,v)中具有最低深度D0的点。第二层,被称为远层,捕获H(u,v)中具有最高深度(在区间[D0,D0+Δ]内)的点,其中,Δ是描述表面厚度的用户定义的参数。在一些实施例中,所生成的视频可以具有WxH YUV420-8bit的几何视频和WxH YUV420-8bit的纹理。YUV是一种颜色编码系统,其中,Y代表亮度分量,UV代表两个色度分量。
如框208中所示,该装置包括诸如处理电路12之类的用于图像填充的部件。该装置被配置为填充几何和纹理图像。填充过程旨在将补片之间的空的空间充满,以生成适于视频压缩的分段平滑图像。在TMC2v0中提供了一种示例填充方式。在TMC2v0中的填充策略被规定如下:
·每个TxT(例如,16x16)像素的块都被独立地处理。
·如果块是空的(即,其所有像素都属于空的空间),则通过以栅格顺序复制前一TxT块的最后一行或最后一列来使该块的像素充满。
·如果块是满的(即,没有空像素),则什么也不做。
·如果块具有空像素和被充满像素两者,则空像素被迭代地用其非空邻居的平均值充满。
如框210中所示,该装置还包括诸如处理电路12之类的用于视频压缩的部件。该装置被配置为将所填充的纹理图像和所填充的几何图像压缩成几何视频和纹理视频。所生成的图像/层被存储为视频帧并使用视频编解码器进行压缩。所使用的一个示例视频编解码器是根据作为参数提供的HM16配置的HEVC测试模型16(HM16)视频编解码器。如框212中所示,该装置包括诸如处理电路12之类的用于辅助补片信息压缩的部件。可以针对每个补片编码以下元数据:
·投影平面的索引
ο用于平面(1.0,0.0,0.0)和(-1.0,0.0,0.0)的索引0
ο用于平面(0.0,1.0,0.0)和(0.0,-1.0,0.0)的索引1
ο用于平面(0.0,0.0,1.0)和(0.0,0.0,-1.0)的索引2
·2D边界框(u0,v0,u1,v1)
·依据深度δ0、切向偏移s0和双切向偏移r0表示的补片的3D位置(x0,y0,z0)。根据所选择的投影平面,(δ0,s0,r0)被计算如下:
ο索引0,δ0=x0、s0=z0、r0=y0
ο索引1,δ0=y0、s0=z0、r0=x0
ο索引2,δ0=z0、s0=x0、r0=y0
针对每个TxT块提供其相关联的补片索引的映射信息可以被编码如下:
·针对每个TxT块,令L是补片的索引的有序列表,以使得它们的2D边界框包含该块。该列表中的顺序与用于编码2D边界框的顺序相同。L被称为候选补片列表。
·补片之间的空的空间被视为补片并被分配特殊索引0,其被添加到所有块的候选补片列表中。
·令I是当前TxT块所属的补片的索引,并且令J是I在L中的位置。替代对索引I进行显式编码,而是对其位置J进行算术编码,这导致更好的压缩效率。
如框214中所示,该装置可以进一步包括诸如处理电路12之类的用于压缩占用图(occupancy map)的部件。如框216中所示,该装置进一步包括诸如处理电路12之类的用于将压缩几何视频、压缩纹理视频、压缩辅助补片信息和压缩占用图复用到点云压缩(PCC)编码比特流中的部件。压缩点云包括:对应于3D对象的纹理的编码视频比特流;对应于3D对象的几何形状的编码视频比特流;以及对应于在3D对象的合成期间必需的所有其他辅助信息的编码元数据比特流。这三个信息流被复用在一起,然后一起被使用,以便在给定时间实例对3D对象点云数据进行解码。图3提供了信息的图形示例。
复用表示是在比特流级,并且需要实现一些特征,诸如:1)按时间随机访问和这种随机访问的精确字节位置的计算;2)元数据在针对帧组被重复时的紧凑表示;3)文件存储机制和经由诸如ISOBMFF和MPEG-DASH之类的机制的递送;以及4)用于递送通道适配的视频和辅助数据流的替代表示(质量、分辨率、帧速率、比特率等)。
在与ISOBMFF相关的实施例中,可以定义类型(brand)以指示文件包含PCC编码比特流。类型的可能的四字符码可以是或包括但不限于'pccf'。类型可以被包含在FileTypeBox中和/或可以在信令传送中使用,诸如在可选的配置文件MIME参数的值中。类型可以存在于主要、次要或兼容类型列表中。在实施例中,如果存在轨道级类型存储机制,则类型可以存在于轨道级中,例如,在TrackTypeBox中。在实施例中,如果存在组级类型存储机制,则类型可以存在于组级中,例如,在对纹理、几何形状和PCC元数据轨道进行分组的EntityToGroupBox中。PCC元数据轨道的新媒体处理器类型可以被定义为'pcch'并被存储在PCC元数据轨道的MediaBox中的HandlerBox('hdlr')的handler_type字段中。如在ISOBMFF中定义的结构可以如下:
Figure BDA0003671411680000321
其中,handler_type定义PCC元数据轨道的媒体处理器类型。该字段可包含4字符码“pcch”。在上述语法结构以及其他示例语法结构中,可以指定语法元素以具有文件作者必须遵守的预定义值。例如,在上述语法结构中,需要文件编写者将语法元素pre_defined的值设置为0。类似地,函数的变量或输入参数(诸如上述语法中的版本)可具有预定义值。例如,在上述语法中,版本参数的值必须等于0。然而,这种预定义值的指定对于其他实施例可以不是必需的,并且某些实施例可以类似地用其他预定义值或在没有被指定给预定义值的语法元素、变量或输入参数的情况下实现。在一个实施例中,PCC全局比特流信息(诸如但不限于全局缩放、平移和旋转)可以被存储在单独的框/完整框中。这种框可以被称为PCCInfoBox,具有4字符码“pcci”。提供示例如下:
Figure BDA0003671411680000331
global_scaling和global_translation被定义为与每个全局轴x、y和z相匹配的独立值。global_rotation被表示为四元数(w,x,y,z)。使用四元数而不是欧拉角的益处在于四元数更意义明确,因为它们不依赖于欧拉旋转的顺序。此外,四元数不易受到“万向节锁定(gimbal locking)”的影响。利用global_scaling、global_translation和global_rotation,可以生成变换矩阵,以对空间中的点云数据进行任意变换。单独提供这些值而不是整体转换矩阵的益处在于开发者便易并且可以忽略变换的某些分量。number_of_layers指示总层数。
语法元素PCCIInfoBox可以存在于PCC元数据轨道的处理器框(Handler Box)中或PCC元数据轨道的媒体报头框(Media Header Box)中。这些框可以被扩展为新框,或者用新的完整框版本来扩展,或者用标志定义来扩展。为了包括PCCIInfoBox,这个新数据结构的示例实现可以如下:
Figure BDA0003671411680000341
或者
Figure BDA0003671411680000342
在上述第一个语法结构中,PCCInfoBox的存在以handler_type为“pcch”为条件。在上述第二个语法结构中,PCCInfoBox的存在以框报头的版本字段等于1为条件。在上述第三个语法结构中,PCCInfoBox的存在以框报头的标志字段具有等于1的特殊比特为条件。
在上述语法结构和其他示例语法结构中,“&”可以被定义为逐位“与”运算。当对(有符号的)整数参数进行操作时,逐位“与”运算对整数值的二进制补码表示进行操作。当对包含比特数少于另一个参数的二进制参数进行操作时,通过添加更多等于0的有效位来扩展更短的参数。
在另一个实施例中,PCCInfoBox内容可以被存储在PCC元数据样本条目中。可以定义新的样本条目类型“pcse”。示例可以如下:
Figure BDA0003671411680000351
在另一个实施例中,PCC比特流全局信息可以使用ItemInfoBox而被存储在文件/电影/轨道级Metabox中。包含PCC全局比特流信息的项可以使用其自己的MIME类型,诸如但不限于被存储在ItemInfoEntry()框的item_type字段中的'pcci'。此外,可以在MetaBox中包含的EntityToGroupBox()中定义新的实体分组。可以定义新的实体分组,诸如'pcgr'。PCC元数据轨道、视频和纹理媒体轨道以及相关的元数据项可以在所定义的'pcgr'分组内被分组在一起。示例可以被表示如下:纹理视频轨道id=1;几何视频轨道id=2;PCC元数据轨道id=3;PCC比特流全局信息被存储为item_id=101的元数据项。
可以用以下语法来定义新的实体分组:
Figure BDA0003671411680000352
grouping_type标识新的实体分组类型。可以针对实体分组定义新的grouping_type四字符码,诸如但不限于'pcgr'。group_id以数值形式表示组的标识符。num_entities_in_group表示组中实体的数量,其在本示例中被设置为4(纹理轨道、几何视频轨道、PCC元数据轨道以及被存储为元数据项的PCC比特流全局信息)。所列出的entity_id是实体的entity_id列表,其在本示例中为[1,2,3,101]。
在一个实施例中,这些实体的顺序可以是预定义的,诸如{纹理,几何形状,pcc元数据,pcc全局信息}。顺序可以是任何定义的顺序。在没有顺序定义的情况下,可以使用轨道的处理器类型和项类型来标识分组实体的类型。
在另一个实施例中,EntitytoGroupBox框可以被扩展以存储PCCInfoBox。语法可以如下:
Figure BDA0003671411680000361
在这种情况下,不需要定义项类型'pcci'以便存储PCC全局信息。
为了指示PCC轨道的分组关系,可以定义轨道分组。这种轨道分组信息可以被存储在每个相关媒体和定时元数据轨道或这种轨道的子集中。轨道分组可以使用轨道分组机制来定义如下:
Figure BDA0003671411680000362
可以针对PCC轨道分组定义新的track_group_type,诸如但不限于'pctg'。在另一个实施例中,PCC全局信息可以被嵌入到TrackGroupTypeBox中,如下:
Figure BDA0003671411680000371
具有相同的{track_group_type,track_group_id}对的媒体和时间元数据轨道可以属于同一PCC 3D表示。
在一些实施例中,作为上述轨道分组机制和/或实体分组机制的补充或替代,如框59中所示,轨道引用机制可用于指示PCC轨道关系。如框59中所示,该装置包括诸如处理电路12之类的用于通过使用轨道引用来将辅助定时元数据轨道与先前定义的轨道组相关联的部件。具有以下ISOBMFF定义语法的TrackReferenceBox可以被使用如下:
Figure BDA0003671411680000372
本文所描述的4字符码被列出为示例。任何一组所列出的轨道引用等都可以存在于存储PCC轨道的文件中。
-PCC纹理轨道可以用reference_type'pcct'来引用PCC元数据轨道。
-PCC几何形状轨道可以用reference_type'pccg'来引用PCC元数据轨道或PCC纹理轨道。
-PCC元数据轨道可以用reference_type'pccm'来引用PCC纹理和几何形状轨道。在这种情况下,纹理和几何形状轨道id两者可以在TrackReferenceBox中列出,具有PCC元数据轨道的类型'pccm'。
在一些替代实施例中,如果纹理或几何形状轨道由相同的PCC元数据轨道表示但在诸如比特率、分辨率、视频质量等之类的某些特性方面不同,则这些轨道可以引用多个元数据轨道。轨道替代也可以使用ISOBMFF提供的替代轨道机制来导出。例如,TrackHeaderBox的相同alternate_group值可用于表示具有不同特性的相同数据的轨道。
在一些替代实施例中,PCC元数据轨道可以具有指向纹理和几何视频轨道的两个不同轨道引用,诸如TrackReferenceTypeBox具有reference_type'pcct'以指向纹理视频轨道,TrackReferenceTypeBox具有reference_type'pccg'以指向几何视频轨道。
在另一个实施例中,视频和几何形状轨道可以被打包为单个视频帧。在这种情况下,被存储在视频轨道中的打包视频帧可以具有TrackReferenceTypeBox,其具有reference_type'pccp'以指向PCC元数据轨道,或者反之亦然(例如,PCC元数据轨道包含具有reference_type'pccp'的TrackReferemceTypeBox,并指向PCC打包视频轨道)。
在另一个实施例中,可以使用具有特定track_group_id的轨道分组类型(但不限于)'pctg'来对纹理和几何形状轨道进行分组。PCC的辅助元数据可以被存储为具有专用处理器类型(诸如但不限于'pccm')的定时元数据轨道,并通过使用'cdtg'轨道引用类型来引用track_group_id。这可以指示PCC辅助定时元数据同时描述了纹理和几何形状轨道。
在一些实施例中,PCC元数据轨道可以在以下方法中包含PCC辅助信息样本。在一个实施例中,每个PCC帧组(GOF)的第一样本可以包含GOF报头信息和对应于具有相同合成时间的纹理和几何形状样本的辅助元数据比特流。在另一个实施例中,这种样本可以被标记为“同步(sync)”样本,例如通过使用同步样本框(又名SyncSampleBox)。在这种情况下,可以在每个GOF边界进行随机访问。所有其他PCC元数据样本可以在其对应的纹理和几何形状轨道中包含几何形状样本的纹理的对应PCC辅助元数据。在另一个实施例中,每个PCC元数据样本可以在可存储GOF报头比特流的样本表框中具有对应的样本辅助信息。该辅助样本信息可以仅针对PCC元数据轨道的同步样本或PCC元数据轨道的每个样本来定义。在另一个实施例中,GOF报头信息可以被存储在PCC元数据轨道样本条目中。进而,每个GOF可以引用包含相关GOF报头比特流信息的样本条目索引。可能的数据结构可以如下:
Figure BDA0003671411680000391
GOFHeaderBox可以具有以下语法:
Figure BDA0003671411680000392
groupOfFramesSize指示当前帧组中的帧数。frameWidth指示几何或纹理图像的宽度。frameHeight指示几何/纹理图像的高度。occupancyResolution指示占用图分辨率。radiusToSmoothing指示检测用于平滑的邻居的半径。neighborCountSmoothing指示用于平滑的最大邻居数量。radius2BoundaryDetection指示边界点检测的半径。thresholdSmoothing指示平滑阈值。
在一些实施例中,可以定义单独的定时元数据轨道以存储GOF报头样本。在这种情况下,这样的元数据轨道具有单独的处理器类型(例如,'pcgh')和对PCC元数据轨道的轨道引用(例如,引用类型'pcgr')。如果存在这样的轨道并且使用轨道分组来对纹理、几何形状和元数据轨道进行分组,则这样的元数据轨道也可以在轨道分组中列出。
在一些实施例中,可以将属于GOF的元数据样本分组在一起以便形成样本组,并且其相关的GOF报头信息可以被存储在SampleGroupDescriptionBox中的SampleGroupDescriptionEntry中。一种示例语法是:
Figure BDA0003671411680000401
在一些实施例中,'pmsg'样本组等存在于包含动态PCC元数据的轨道中。在一些实施例中,'pmsg'样本组等存在于任何视频轨道(例如,纹理视频轨道或几何视频轨道)中。
在某些情况下,例如,当编码并流传输实时馈源时,需要在创建初始MovieBox之后在比特流中包含新的GOF报头。在这种情况下,可以在MovieFragmentBox中包括的SampleGroupDescriptionBox中引入新的GOF报头。需指出,在MovieFragmentBox中包括的SampleGroupDescriptionBox中引入GOF报头可用于但不限于实时馈源的编码和流传输。
PCCMetadata样本可以包含GOF报头信息、GOF辅助信息以及GOF占用图信息。在一些实施例中,GOF报头信息、GOF辅助信息以及GOF占用图信息被定义为它们在PCC类别2编码工作草案中的对应部分。在上面提供了GOF报头信息。示例GOF辅助信息包括以下内容:
Figure BDA0003671411680000402
Figure BDA0003671411680000411
Figure BDA0003671411680000421
在一些实施例中,为了适应在某一时刻只有一个单个视频解码器实例可用的情况,只有一个单个视频比特流被馈送到视频解码器。
在一些实施例中,可以利用空间帧打包方法将纹理和几何视频帧放入单个视频帧中。帧打包布置SEI消息或具有与帧打包布置SEI消息类似的内容的另一个SEI消息可用于在视频比特流级中信令传送这种打包。可以使用受限视频方案在文件格式级信令传送这种打包。
替代方案可以是执行按区域打包并创建“打包PCC帧”。这种方法可以使能诸如旋转、缩放等之类的不同几何变换将被应用于纹理和几何形状帧。可以在ISOBMFF中的SchemeInformationBox中定义并信令传送一种新型的“按区域打包”受限方案类型。
另一个替代方案可以是使用用于纹理和几何形状帧的时间交错机制,并确保帧的预测依赖关系仅来自相同类型的帧(例如,纹理或几何形状)。在另一个实施例中,可以放宽这种限制。这样的编码配置可以在具有新类型定义的媒体轨道的SchemeInformationBox中信令传送。用于这种交错帧的样本合成时间将是{纹理,几何形状}对的第二帧的合成时间。此外,可以定义指示符字段以信令传送第一视频帧的类型。
在另一个实施例中,具有相同类型的视频帧组可以是彼此连续的。在这种情况下,可以在相同类型的连续帧上信令传送样本合成时间,进而将其应用于按解码顺序与该帧组相邻的相同数量的帧(例如,N个纹理帧的样本定时被应用于接下来的N个几何形状帧,然后是N个纹理帧,依此类推)。可以定义新的时间打包类型指示符以信令传送这种交错方案。
在一些实施例中,装置可以包括诸如处理电路12之类的用于访问纹理信息比特流、几何形状信息比特流和辅助元数据比特流的部件。在一些实施例中,该装置可以包括诸如处理电路12之类的用于将纹理信息比特流和几何形状信息比特流打包到一个视频媒体轨道中的部件。在一些实施例中,该装置可以包括诸如处理电路12之类的用于将辅助元数据信息存储在定时元数据轨道中的部件。在一些实施例中,该装置可以包括诸如处理电路12、存储器14等之类的用于将视频媒体轨道和定时元数据轨道关联为一个组,以及用于将视频媒体轨道和时间元数据轨道存储为一个组的部件。
关于将纹理信息比特流和几何形状信息比特流打包到一个视频媒体轨道中,在一些实施例中,比特流中的纹理和几何视频帧可以在空间上被打包为单个视频帧。可以针对PCC编码打包纹理和几何视频帧来定义新的受限视频方案。这种方案可以通过在RestrictedSchemeInfoBox内的scheme_type 4字符码'ppvs'来标识。新的统一资源标识符(URI)可以被定义为scheme_uri,并且可以根据框标志而有条件地存在。进而,可以将打包PCC视频帧信息包含在相关视频轨道的SchemeInformationBox中。这种框可以被称为PCCPackedVideoBox,其4字符码为'ppvi'。这种框的示例可以如下:
Figure BDA0003671411680000431
以下框可以驻留在方案信息框(Scheme Information Box,'schi')内,并包含PCC打包视频特定信息:
Figure BDA0003671411680000432
被称为PCCSpatialPackingBox()的框可以定义纹理和几何形状补片如何在空间上被打包在视频帧中,例如:
aligned(8)class PCCSpatialPackingBox extends FullBox('rwpk',0,0){
PCCSpatialPackingStruct();
}
PCCSpatialPackingStruct()可以包含识别每个打包区域的类型、维度和空间位置所需的数据结构。这种框可以具有以下结构:
Figure BDA0003671411680000441
num_regions定义在该数据结构中定义了多少打包区域。proj_texture_picture_width定义输入视频纹理帧的宽度。proj_texture_picture_height定义输入视频纹理帧的高度。proj_geometry_picture_width定义输入几何纹理帧的宽度。proj_geometry_picture_height定义输入几何纹理帧的高度。packed_picture_width定义输出打包视频帧的宽度。packed_picture_height定义输出打包视频帧的高度。
region_type指示打包区域的类型。region_type=0可以指示该区域的源是纹理视频帧。region_type=1指示该区域的源是几何视频帧。
guard_band_flag指示区域(reason)是否具有保护带。pack_type指示按区域打包的类型。RectRegionPacking指定打包区域与投影区域之间的按区域打包。
在另一个实施例中,可以将诸如“正交投影”之类的新投影类型添加到如在MPEGOMAF规范中定义的ProjectionFormatBox中,其驻留在投影全向视频('podv')方案的ProjectedOmnivideoBox('povd')内。在这种情况下,PCCPackedVideoBox可以驻留在ProjectedOmnivideoBox内,并且它的存在可以通过将指示正交投影的Projection_type来信令传送。
在一些实施例中,纹理和几何视频帧在时间上交错以形成单个视频比特流。在这种情况下,可以定义视频预测方案,以使得纹理帧仅依赖于其他纹理帧并且几何形状帧也仅依赖于其他几何形状帧。帧速率可以加倍。后一帧的合成时间可用于指示时间交错帧的合成时间。在这种情况下,可以定义被称为PCCVideoBox的新框以指示时间打包信息。当schemeType可以被定义为'pcci'以指示时间交错PCC纹理和几何形状帧时,这种框可以驻留在SchemeInformationBox内。示例是:
Figure BDA0003671411680000451
packing_indication_type指示时间或空间打包的类型。示例打包类型及相关值是:
0:空间打包指示符。该值指示应用了空间打包方案,并且对纹理和几何PCC视频帧使用了上述空间打包机制。
1:时间交错,纹理帧优先
2:时间交错,几何形状帧优先
在时间交错和空间打包两者的用例中,可以应用辅助元数据轨道与纹理和几何轨道之间的轨道引用机制。在这种情况下,可被称为'pctg'的单个轨道引用类型可用于从PCC辅助元数据轨道到打包/交错PCC纹理和几何视频轨道/从打包/交错PCC纹理和几何视频轨道到PCC辅助元数据轨道。
在使用HEVC的一些实施例中,为了支持这种机制,可以定义如本文所描述的一些数据结构。
可以定义被称为PCCCPackedFrameProperty的描述性项特性。该特性可以包含如上面定义的PCCSpatialPackingBox()。进而,这种特性被链接到包含打包纹理和几何图像项的图像项。一种示例语法是:
Figure BDA0003671411680000461
被称为PCCAuxiliaryProperty('pcap')的描述性项特性可以被定义为包括PCC全局参数和GOF报头信息。一种示例语法是:
Figure BDA0003671411680000462
可以定义被称为PCC元数据项的新的项类型,以包含PCC辅助元数据信息,其在上述部分中被称为PCC辅助元数据样本。该项可以被定义为类型'pcca'。
如果没有定义打包,或者如果原始PCC编码几何和纹理图像也被存储在同一媒体文件中,则可以定义以下项特性:
ο可以定义被称为PCCTextureItemProperty('pcti')的描述性项特性,以指示PCC编码纹理图像项。进而可以将该特性链接到相关的图像项。
ο可以定义被称为PCCGeometryItemProperty('pcgi')的描述性项特性,以指示PCC编码几何图像项。进而可以将该特性链接到相关的图像项。
ο上述被称为PCCAuxiliaryProperty('pcap')的描述性项特性可用于存储全局报头和GOF报头信息。
ο可以使用实体分组机制来将上述PCC元数据项和具有相应的项纹理和几何形状项特性的两个图像项分组在一起,以指示它们创建了PCC编码3D表示。这样的实体分组可以在EntitytoGroupBox()中具有'pcce'类型,其中,可以列出纹理、几何图像和PCC辅助元数据项的所有相关item_id以指示组。
在另一个实施例中,PCCInfoBox、GoFHeaderBox和可选的PCC辅助元数据信息的内容可以在EntityToGroupBox(具有grouping_type='pcce')中列出,这种数据结构的示例如下:
Figure BDA0003671411680000471
在另一个实施例中,PCCInfoBox等被包括在grouping_type等于'pcce'(或指示PCC的一些其他四字符码)的EntityToGroupBox中,如上所述。GofHeaderBox等可以通过在其他实施例中描述的任何方式而被包括在文件中,例如将其包括在样本组描述条目中。类似地,PCC辅助元数据信息可以通过在其他实施例中描述的任何方式而被包括在文件中。
在另一个实施例中,PCC元数据的全部或部分可以被存储在并被信令传送为SEI消息,另外还作为视频比特流的一部分被携带。此类信息可以包含被映射到不同或单个SEI消息并与纹理和几何形状基本比特流一起发送的PCC辅助样本字段。在这种情况下,PCC辅助元数据SEI消息可以驻留在纹理或几何形状基本流之一中,并且不在这两者中重复。在该实施例中,可以不需要将PCC辅助信息或元数据信息存储为单独的特性或元数据图像项。
在另一个实施例中,可以定义新的NAL单元以包含PCC辅助元数据信息。这种NAL单元进而也可以以符合ISOBMFF的格式被存储,作为视频样本的一部分。同样,在这种情况下,这样的NAL单元可以被存储为纹理或几何视频轨道的一部分,或者被存储为打包或交错纹理和几何形状轨道的一部分。在该实施例中,可以不需要将PCC辅助信息或元数据信息存储为单独的特性或元数据图像项。
在另一个实施例中,包含PCC辅助元数据信息的NAL单元和视频NAL单元可以被组合成单个PCC流并被存储在PCC轨道中,其中,每个PCC样本由一个或多个纹理、几何形状和辅助信息NAL单元组成。在这种情况下,单个媒体轨道或图像项可以存在于PCC媒体文件中。
在一些实施例中,几何形状、纹理、占用图和动态的基于时间的元数据的子集可以遵循相同的编码结构。此外,几何形状、纹理、占用图和动态的基于时间的元数据可以遵循相同的定时结构。在这种情况下,可以使用单个轨道架构。复用器可能够复用比特流,以使得在某一时刻重构点云所需的几何形状、纹理、占用图和动态元数据的编码访问单元彼此相邻。访问单元集合的顺序因实现而异。进而,此复用比特流被封装到mdat框中。单个轨道可以将复用比特流的连续访问单元(几何形状、纹理、占用图和动态元数据)视为单个PCC媒体样本。可以使用专门针对PCC媒体样本而定制的子样本信息框来指示个体访问单元的大小。
在单个轨道设计的一些实施例中,视频和定时元数据访问单元可以是交错的。一个帧的编码几何形状、纹理和定时元数据依次跟随另一个帧的另一个几何形状、纹理和定时元数据。样本可以是编码几何形状、纹理、占用图和定时元数据,需要对其进行解码以在某一时刻呈现。个体样本的每个编码子部分的大小的指示可以在子样本信息框中信令传送或者被存储为样本辅助信息并通过样本辅助信息大小框进行引用。
在使用HEVC的一些实施例中,为了支持这种机制,可以定义如本文所描述的一些数据结构。
Figure BDA0003671411680000491
HEVCDecoderConfigurationRecord()可以如在ISO/IEC 14496-15:信息技术—视听对象的编码—第15部分:ISO基础媒体文件格式中网络抽象层(NAL)单元结构化视频的承载中所定义的。在另一个实施例中,可以一起使用不同的编解码器配置。例如,AVC和HEVC编解码器可用于不同的分量,进而一起被列出在PCCConfigurationBox中。
示例HEVCDecoderConfigurationRecord()是:
Figure BDA0003671411680000492
Figure BDA0003671411680000501
HEVCDecoderConfigurationRecord()包括在每个样本中使用的长度字段的大小,以指示其包含的NAL单元的长度以及参数集(如果被存储在样本条目中)。HEVCDecoderConfigurationRecord()是外部构造的(其大小必须由包含它的结构提供)。
general_profile_space、general_tier_flag、general_profile_idc、general_profile_compatibility_flags、general_constraint_indicator_flags、general_level_idc和min_spatial_segmentation_idc的值对在解码由此记录所描述的流时被激活的所有参数集(在本段的以下句子中被称为“所有参数集”)有效。具体而言,以下限制适用:
所有参数集中的general_profile_space的值可以相同。层(tier)指示general_tier_flag指示等于或大于在所有参数集中指示的最高层的层。配置文件指示general_profile_idc可以指示与该配置记录相关联的流符合的配置文件。
可以在HEVC解码器配置记录中提供有关色度格式和位深以及由HEVC视频基本流使用的其他重要格式信息的明确指示。如果存在,则在单个HEVC配置记录中,每种类型的此类信息在所有参数集中是相同的。如果两个序列在任何类型的此类信息中不同,则使用两个不同的HEVC配置记录。如果两个序列在其VUI信息中的颜色空间指示中不同,则也需要两个不同的配置记录。存在一组数组来承载初始化NAL单元。NAL单元类型仅限于指示SPS、PPS、VPS和SEINAL单元。
在一些实施例中,可以一起使用不同的编解码器配置。例如,AVC和HEVC编解码器可用于不同的分量,进而一起被列出在PCCConfigurationBox中。在实施例中,PCCConfigurationBox可以包含上述解码器的子集。进而,可以由PCCSampleEntry定义PCC样本,例如,如:
Figure BDA0003671411680000511
MPEG4BitRateBox信令传送比特率信息。
MPEG4ExtensionDescriptorsBox包括扩展描述符。
在一些实施例中,当特定轨道PCC媒体分量被存储在单独的轨道中时,可以应用先前描述的轨道分组和引用机制。
在一些实施例中,描绘了根据示例实施例的点云压缩编码比特流的存储。该实施例被应用于分段ISOBMFF文件的实例。每个PCC媒体分量被携带在单独的媒体轨道中。PCC媒体分量可以以任何特定的样本计数和顺序交错。最小粒度可以是一个接一个的PCC媒体分量的交错。在一些实施例中,示例交错样本的图形表示可以包括来自在mdat框内交错的不同轨道的纹理(T)、几何形状(G)、占用(O)、以及辅助(A)元数据样本。
在一些实施例中,装置包括诸如处理电路12之类的用于访问纹理信息比特流、几何形状信息比特流和辅助元数据比特流的部件。在一些实施例中,该装置包括诸如处理电路12之类的用于将纹理信息比特流存储在纹理视频媒体轨道中的构件。在一些实施例中,该装置包括诸如处理电路12之类的用于将几何形状信息比特流存储在几何视频媒体轨道中的部件。在一些实施例中,该装置包括诸如处理电路12之类的用于将辅助元数据信息比特流存储在定时元数据轨道中的部件。在一些实施例中,该装置包括诸如处理电路12、存储器14之类的用于构建和存储交错指示符元数据文件的部件,该交错指示符元数据文件指示用于纹理视频媒体轨道、几何视频媒体轨道和定时元数据轨道的一个或多个分量的交错模式。
示例moof框可以包括或被指示为:
Figure BDA0003671411680000521
新定义的InterleavedMediaIndicatorBox()可以使能信令传送以下特性:
-mdat框中的媒体交错模式,mdat框遵循与moof框中的'traf'框相同的顺序。所指示的traf框属于所列出的track_ID,并且可以彼此连续地被列出。
-trun框可以与示例tr_flags=0x001000相关联。这指示trun框中的sample_size字段基于由InterleavedMediaIndicatorBox()指示的交错模式来指示该轨道的被表示样本的样本大小,而不是不间断的连续样本运行。
示例InterleavedMediaIndicatorBox()是:
Figure BDA0003671411680000522
Figure BDA0003671411680000531
InterleavedMediaIndicatorBox可以存在于“moov”或“moof”中。如果它存在于“moov”中,则定义默认交错策略。use_default_interleaving在等于1时指示可以使用在“moov”框中定义的媒体交错模式。number_of_consecutive_samples指示同一轨道中有多少样本连续地存在。如果use_default_interleaving为1,则该字段取值0。否则,可存在大于0的值。track_id_count指示在数组中列出的track_ID的数量。track_ID是整数,提供了轨道标识符,其中针对该轨道标识符提供随机访问信息。
“trun”框可以如在ISOBMFF标准中所定义的:
Figure BDA0003671411680000532
轨道运行框(Track Run Box)的sample_composition_time_offset是媒体处理单元中的访问单元的呈现时间。该值从MPU的开始偏移。媒体处理单元的开始呈现时间由Composition信息规定。
在一些实施例中,可以使用其他方式来定义交错策略,诸如在带外或在预定义框中的文件中信令传送的预定义枚举或模式。在一些实施例中,如果使用单个轨道来携带PCC媒体数据,则可以使用SubSampleInformationBox来访问PCC媒体样本内的每个交错PCC分量。可以定义新的SampleGroupDescriptionBox以指示每个PCC分量的顺序和配置。
在已经参考编码器描述了示例实施例的一些实施例中,需要理解,所得到的比特流和解码器可以具有被配置为执行对应功能的对应元件。在一些实施例中,解码器可以包括诸如处理电路12之类的用于接收点云压缩编码比特流的部件,其中,该点云压缩编码比特流包括纹理信息比特流、几何形状信息比特流、以及辅助元数据比特流。在一些实施例中,解码器可以进一步包括诸如处理电路12之类的用于对点云压缩编码比特流进行解码的部件。
在已经参考语法和语义描述了示例实施例的一些实施例中,某些实施例同样涵盖根据语法和语义输出比特流部分的编码器。同样,某些实施例对应地涵盖根据语法和语义对比特流部分进行解码的解码器。
示例实施例根据单独的编码器和解码器装置描述了编解码器,以帮助理解所涉及的过程。然而,应当理解,装置、结构和操作可以被实现为单个编码器-解码器装置/结构/操作。此外,编码器和解码器可以共享一些或所有公共元件。
关于基于视频的点云压缩(V-PCC),V-PCC非常灵活,因此它在ISOBMFF中的封装可以以多种方式完成。根据实际限制(未必在该规范中描述),可以考虑在ISOBMFF中使用不同的结构元素。先前关于V-PCC内容封装的讨论一直围绕着实体分组或轨道分组的使用展开,其中V-PCC轨道与分量之间的关系在通用位置被描述,其中解码器可以很容易地理解应如何解码和渲染内容。这种方法的益处在于在解码端只需要很少的处理便可弄清如何播放文件。然而,这种系统级方法的主要缺点在于编辑方面的限制,其中当轨道改变时需要更新这种关系信令。
本文所公开的一些方法可以包括轨道分组、实体分组和轨道引用机制以描述V-PCC分量(元数据和视频分量)之间的关系,从而使能V-PCC内容的随机可访问性。
在一些实施例中,描述了一种用于在ISOBMFF中封装V-PCC数据(例如,内容)的方法,该方法通过最小化V-PCC轨道与V-PCC分量视频轨道之间的交叉引用量来提高编辑V-PCC内容的灵活性,同时保持重构符合V-PCC的比特流的能力。在一些实施例中,为了保持轻松的编辑能力,重复信息的量也受到限制,并且更多的重构责任被推送到解码器组件。在一些实施例中,诸如本文所描述的方法可以使添加新轨道或从文件(例如,ISOBMFF文件)中移除旧轨道变得简单。在一些实施例中,诸如关于V-PCC轨道的随机访问方面,此类方法产生随机访问结构,诸如文件结构、数据结构、轨道结构、信息结构等。在一些实施例中,这种随机访问结构可用于V-PCC内容并且可以促进或指示V-PCC轨道可以或应如何被处理以将其封装在ISOBMFF文件中。在一些实施例中,如果采用单个轨道方法,则该方法可以包括有关可如何使用子样本信息以及可如何将V-PCC比特流存储在媒体数据中的方法。
如本文所描述的,V-PCC序列参数集(SPS)是描述用于V-PCC呈现的整体配置的结构。SPS可以或应被存储在ISOBMFF容器的V-PCC-track SampleEntries或ampleGroupEntries中。
在一些实施例中,SPS结构可以包括表1中的任何或所有分量:
表1
Figure BDA0003671411680000551
Figure BDA0003671411680000561
Figure BDA0003671411680000571
在一些实施例中,V-PCC轨道可以是V-PCC封装的元数据轨道,其样本数据中包含补片数据组(PDG)。表2提供了PDG结构示例。
在许多情况下,SampleEntry更新旨在重置视频解码器。这种行为使得在V-PCC-track SampleEntries中存储序列参数集变得更加困难。在一些实施例中,诸如对于以ISOBMFF格式等进行V-PCC内容流传输,可不期望将序列参数集存储在SampleEntries中,而是可替代地考虑SampleGroups。然而,SampleGroups的使用假定每样本仅一个序列参数集可以是活动的。
表2
Figure BDA0003671411680000572
在一些实施例中,分量视频轨道可以包含点云重构所需的编码属性、几何形状、或占用视频比特流。在一些实施例中,视频分量轨道可以在其样本条目中或在其样本组描述条目中包含V-PCC单元报头。V-PCC单元报头结构可以提供序列参数集标识、层标识、属性标识以及其他相关信令,以便结合在V-PCC-track中存储的序列参数集数据来唯一地标识轨道的用途。
在一些实施例中,V-PCC比特流可以包括一组V-PCC单元。在一些实施例中,每个V-PCC单元可以具有V-PCC单元报头和V-PCC单元有效载荷。在一些实施例中,V-PCC单元报头描述了V-PCC单元类型。表3描述了至少一些所支持的V-PCC单元类型。
表3
Figure BDA0003671411680000581
在一些实施例中,属性视频数据V-PCC单元报头还可以指定属性类型及其索引,从而允许支持相同属性类型的多个实例。表4指定了所支持的V-PCC属性类型。
表4
Figure BDA0003671411680000582
Figure BDA0003671411680000591
在一些实施例中,占用、几何形状和属性视频数据单元有效载荷可以对应于视频数据单元(例如,HEVC NAL单元),这些视频数据单元可以由在对应的占用、几何形状和属性参数集V-PCC单元中指定的视频解码器来解码。
在一些实施例中,视频编码V-PCC分量轨道的样本可以具有扩展VisualSampleEntry结构,这些结构包含vpcc_unit_header()信息。一个示例数据结构可以如下:
Figure BDA0003671411680000592
格式(format)可以是AVC、HEVC或任何其他视频编码器特定视觉样本条目的有效VisualSampleEnty格式值。
在一些实施例中,vpcc_unit_header()的数据内容可以明确地被列出在数据结构中,诸如上文所描述的。在一些实施例中,此类信息可以是SPS_id、attribute_type、attribute_id、layer_id等。
在一些实施例中,vpcc_unit_header信息可以经由样本分组机制而被链接到V-PCC分量轨道样本。在一些实施例中,为此目的定义了特定类型的新样本组描述。在以下示例中,给出4CC码'vpcu'作为示例:
Figure BDA0003671411680000593
在一些实施例中,可以经由定义的样本分组机制将每个V-PCC轨道样本(其可以具有vpcc_unit_header()作为报头)链接到报头数据。在一些实施例中,vpcc_unit_header()的数据内容可以明确地被列出在数据结构中,诸如上文所描述的。在一些实施例中,此类信息可以包括SPS_id、attribute_type、attribute_id、layer_id等。
表5提供了vpcc_unit_header()的示例。
表5
Figure BDA0003671411680000601
Figure BDA0003671411680000611
现在参考信令传送轨道引用,在一些实施例中,轨道引用可用于将一个或多个V-PCC分量视频轨道链接到主vpcc轨道(vpcc-track)。在一些实施例中,视频分量轨道可以在TrackBox中包含引用类型为'auxl'并且track_ID与vpcc-track相匹配的TrackReferenceBox。可替代地,在一些实施例中,可以为vpcc-track定义新的reference_type,如'vpcc'。在其他实施例中,每个V-PCC分量轨道可以具有唯一的轨道引用类型。
在一些实施例中,轨道引用可以被定义为从vpcc-track到V-PCC分量视频轨道。诸如'pcca'、'pccg'和'pcco'之类的新的轨道引用类型可用于引用属性分量视频轨道、几何分量视频轨道以及占用分量视频轨道。vpcc-track可以引用V-PCC分量轨道的所有替代表示,但优选的方案可以是仅信令传送主要表示。可以从个体分量视频轨道的TrackHeaderBoxes内的alternative_group值建立替代轨道。
在一些实施例中,可以针对每个视频分量轨道或vpcc-track,使用TrackHeaderBox中的alternate_group指示符来信令传送替代轨道。如ISOBMFF规范中所描述的,包含替代表示的轨道可以共享相同的alternate_group值。在一些实施例中,应在任一时间仅播放或流传输替代组中的一个轨道,并且必须经由诸如比特率、编解码器、语言、分组大小等之类的属性与该组中的其他轨道区分开来。在一些实施例中,解码器/播放器可以确定或被使得确定应使用哪个表示。可以设置有关在替代组中使用不同轨道组合的限制,例如,在一些实施例中,可以或应在任何给定时间仅使用具有相同分辨率或帧速率的替代轨道。
在一些实施例中,除了传统的可区分属性之外,还可以引入V-PCC特定属性,诸如V-PCC层的单个流或多个流封装。例如,vpcc-track可以包含多个具有不同的层布局的序列参数集。在一些实施例中,每个视频分量轨道可以被链接到正确的序列参数集,因此,再次由播放器决定它应选择哪个表示。
在一些实施例中,使用这种结构的至少一个益处在于文件格式易于编辑,因为视频分量轨道仅包含对vpcc-track的引用(反之亦然)。因此,在一些实施例中,可以容易地添加和移除分量轨道。此外,所提议的方法可以包括重新使用若干V-PCC规范结构,这可以减少或最小化V-PCC内容的处理,同时将其封装到ISOBMFF中。根据一些实施例,有关在将V-PCC内容封装到ISOBMFF中时减少或最小化V-PCC内容的处理要求的折衷可以是或包括解析器将需要了解被封装在文件格式中的V-PCC结构。
现在参考信令传送轨道替代和推荐表示,在一些实施例中,可以通过使用TrackHeaderBox中的alternate_group值来信令传送轨道替代。然而,在一些实施例中,该机制不能提供关于替代分组的性质(即,比特率、纹理差异、分辨率、质量等)的信息。在一些实施例中,为了解决这个缺点,可以使用EntitytoGroupBox中的'altr'实体分组。在一些实施例中,为了信令传送替代方法,可以使用EntitytoGroupBox的标志。仅作为示例,在一些实施例中,24比特标志值中的每个比特可以指示替代原因。在一些实施例中,这些可以是比特率、分辨率、单个PCM或多个PCM轨道、不同的纹理、编码质量等。
在一些实施例中,由于表示中可以存在多个不同的替代,因此内容创建者可以信令传送推荐V-PCC表示。在一些实施例中,这可以通过在meta框内引入特定类型(例如,'vpcg')的EntitytoGroupBox并在替代中列出V-PCC轨道和所选择分量轨道来实现。在一些实施例中,对于不同的替代表示组,可以存在多个这样的列表。
关于VPCCGroupBox和VPCCDecoderConfigurationRecords的使用,在一些实施例中,可以定义VPCCGroupBox以对vpcc内容进行分组。在一些实施例中,VPCCGroupBox可以存在于SampleEntry或SampleGroupDescriptionEntry中或者驻留在VPCCDDecoderConfigurationRecord中。在一些实施例中,这种用于文件封装的方法相对简单,因为假定V-PCC内容仅使用单个序列参数集。在一些实施例中,这样的数据结构可以被链接到每个SPS数据结构并且在SPS被用于解码V-PCC帧时有效。在以下示例文件结构中,概述了一种方法,该方法使用VPCCGroupBox,以最少的重复和最大的灵活性在单个位置包含V-PCC内容的有意义的高级详细信息。在一些实施例中,引入VPCCGroupBox的至少一个益处可以是为解码器提供单个位置以检查V-PCC内容是如何构造的,以便决定如何解码并渲染它。在一些实施例中,诸如本文所描述的V-PCC结构的使用需要更少的文件格式规范本身的更新。然而,在一些实施例中,可需要解析器理解这些结构,即,解析VPCCGroupBox需要了解V-PCC结构。
Figure BDA0003671411680000631
在一些实施例中,track_reference_id可以在V-PCC轨道的'tref'框中指示被引用轨道的轨道引用的索引。在一些实施例中,track_id可以直接在该字段中使用。在一些实施例中,sps_frame_width和_sps_frame_height可用于信令传送整个呈现或表示的sps_frame_width和_sps_frame_height的最大值,例如,如果存在若干序列参数集。在一些实施例中,其他vpcc相关结构可以存在于VPCCGroupBox中。
在一些实施例中,如果预计序列参数集在呈现期间不发生改变,则封装结构是便易的,然而这不受规范的限制,因此,文件格式应允许存储多个序列参数集以用于呈现。在一些实施例中,因为轨道可以在不同时间引用不同的序列参数集,因此必须保持这样的引用的时间对齐。在一些实施例中,这使得在vpcc-track的VPCCGroupBox中存储分量视频轨道的vpcc_unit_header()信息变得不太可行。在一些实施例中,方法可以包括将vpcc_unit_header()信息存储在分量视频轨道本身中。为了维持定时信息,SampleGroups可用于存储分量视频轨道的vpcc_unit_headers(),诸如:
Figure BDA0003671411680000641
在一些实施例中,可存在VPCC轨道解码器配置记录,类似于基于NAL的视频编码数据的一些常规存储方法。
在V-PCC编码数据的当前工作草案中给出了这样的定义:
Figure BDA0003671411680000651
在一些实施例中,可以将诸如上述数据实体之类的数据实体封装在VPCCDDecoderConfigurationRecord或等效的数据结构中,如:
Figure BDA0003671411680000652
在一些实施例中,上面列出的字段添加到数据结构中可以使得文件解析器解析和信令传送此类信息变得更便易,而无需解析一个或多个sequence_parameter_set。
在一些实施例中,V-PCC轨道所引用的轨道可以在VPCCSampleEntry中列出,诸如:
Figure BDA0003671411680000661
在一些实施例中,track_reference_id可以在V-PCC轨道的'tref'框中指示被引用轨道的轨道引用的索引。在一些实施例中,track_id可以直接在该字段中使用。
因此,在一些实施例中,被引用轨道列表和可能的vpcc_unit_header()值可以在VPCCSampleEntry内被信令传送。这为文件解析器提供了一种便易的方式以通过仅解析V-PCC轨道来了解被引用轨道的性质。
现在参考VPCC内容的随机访问方面,每个V-PCC实体可以具有其自己的随机访问间隔。在一些实施例中,分量视频轨道可以使用良好建立的视频相关随机访问特征。从历史上看,vpcc-track的随机访问在计算上可以非常复杂且耗时。vpcc-track通常在其样本数据中包含补片数据组。在一些实施例中,每个vpcc样本可以包含用于单个vpcc帧的补片数据。在一些实施例中,补片序列数据可以被定义为patch_data_group_unit_payload列表,其中,有效载荷类型可以不同。一些补片数据组单元有效载荷包含信息,这些信息除了与其隐式链接的帧之外还被应用于后续的帧,因此并不是帧特定的。此类补片序列单元有效载荷至少包括类型0-5,如表6中所提供的。
表6
Figure BDA0003671411680000671
具有类型PDG-PTGLU的补片数据组单元有效载荷包含单个patch_tile_group_layer_unit(),其进而由patch_tile_group_header()和patch_tile_group_data_unit()对组成。patch_tile_group_header()包含字段ptgh_type,其为补片图块(tile)组数据单元中的补片数据指定编码类型1(帧内)或0(预测)。此信息可用于定义vpcc-track的同步样本。
在一个实施例中,非帧特定的补片数据组单元有效载荷可以从补片数据组流中提取,并被存储在vpcc-track样本组描述条目中。
Figure BDA0003671411680000672
Figure BDA0003671411680000681
在一些实施例中,patch_data_group_unit_payload()可以如ISO/IEC23090-5中所定义地构造,但限于仅包含补片数据组单元有效载荷,其具有如本文所定义的类型0-5。在一些实施例中,样本组描述条目中的所提取补片数据组单元有效载荷可以或应与它们最初从中提取的样本时间对齐,因此使用现有的SampleGroupDescriptionEntry映射来保持随机访问能力。作为这种提取的结果,patch_data_group()应只包含类型为PDG_PTGLU的patch_data_group_unit_payloads,这意味着同步样本可以被定义为样本,其中补片图块组层单元ptgh_type等于1(帧内)。在解码器侧的文件解析操作期间,如果两个后续样本属于不同的SampleGroup,则修改后续的样本以包括其所属的SampleGroupEntry中的patch_data_group()。
在另一个实施例中,patch_data_group()可以包含任何pdg_unit_types并且不需要对patch_data_group()进行操作。利用此方法,包含0到5之间(包括端点)的pdg_unit_types的patch_data_group()被原样复制到vpcc轨道的SampleGroupEntries中。
在解码器侧的文件解析操作期间,如果两个后续样本属于不同的SampleGroup,则修改后续的样本以包括其所属的SampleGroupEntry中的patch_data_group()。
在另一个实施例中,所有活动的非帧特定的补片数据组单元有效载荷可以或应在所有vpcc同步样本中被复制。在该实施例中,同步(或随机访问)样本被定义为不依赖于轨道中任何先前样本并包含所有相关信息以从时间对齐的2D分量视频样本重构点云的样本。这个定义更简单,但可需要针对每个同步样本复制类型为0-5的补片数据组单元有效载荷,从而稍微地增加比特流的大小,但避免了引入样本分组。
如果v-pcc分量轨道包含多个层,则可需要在视频轨道本身内信令传送该信息。一种这样的机制可以是在SchemeInformationBox中定义新的框以信令传送多个层的存在。可能的数据结构可以如下:
框名称:VPCCMultipleLayerIndicatior框
框类型:'vmli'
容器:SchemeInformationBox
强制性:是(当SchemeType为'pccv'时)
数量:1
VPCCMultipleLayerIndicator框用于指示视频轨道由具有相同属性的VPCC编码的多个层组成。这也意味着针对该V-PCC分量,SPS中的sps_multiple_layer_streams_present标志被设置为1。
Figure BDA0003671411680000691
在一些实施例中,number_of_layers指示作为V-PCC分量轨道中的帧而存在并临时打包的层的数量。它的值可以是sps_layer_count_minus1+1。
在一些实施例中,诸如当在当前数量的层中存在间隙时,零大小的样本可以被包括在样本表框中。
在一些实施例中,PackedContentInterpretationType可用于信令传送关于打包结构和类型的附加信息。作为示例,它可以指示彼此相继的时间打包帧采用预定义的层顺序(按层顺序升序或按层序降序)。
现在参考有关在同一轨道中存储层时的合成时间的说明,当视频分量轨道中存在时间交错的vpcc层时,需要说明样本的合成时间。考虑到ISOBMFF中不允许样本具有相同的合成时间,读者应将用于构成图像的合成时间隐式设置在0到layer_count_minus1之间(包括端点),以与用于最后一个构成图像的合成时间layer_count_minus1相一致。
现在参考V-PCC内容的单个轨道表示,在一些实施例中,期望将V-PCC编码比特流原样地存储在单个轨道中。潜在优势可以至少包括:
直接存储V-PCC编码比特流,而无需任何额外的报头处理;
利用ISOBMFF的时间和字节大小框架(即,样本定时和样本大小);以及
在V-PCC比特流中使能并指示随机访问位置。
在一些实施例中,为了指示V-PCC轨道是“自包含”媒体轨道,可以应用以下约束:
每个V-PCC访问单元可以包括仅按预定义或随机顺序的相关V-PCC分量的比特流数据,包括V-PCC单元报头和SPS。因此,将容易按合成时间顺序划分每个V-PCC帧。
V-PCC样本可以等同于V-PCC访问单元,其可以或可以不依赖于其他V-PCC样本以重构对应于V-PCC样本的相同合成时间戳的V-PCC帧。
随机访问或同步V-PCC样本是不依赖于任何其他V-PCC样本来解码内容的V-PCC样本。
SPS和单元报头数据结构在编码V-PCC比特流中被保持原样。
在一些实施例中,将V-PCC内容存储在单个轨道中的ISOBMFF文件可以使用特定类型(诸如'vpcs')的VolumetricSampleEntry。所有可能的sequence_parameter_set()可以在该样本条目中列出,以便V-PCC解码器可以解码。可能的数据结构可以如下:
Figure BDA0003671411680000701
其中,VPCCDecoderConfigurationRecord和VPCCConfigurationBox被定义如下:
Figure BDA0003671411680000702
Figure BDA0003671411680000711
在一些实施例中,V-PCC子样本可以被定义为由V-PCC单元报头和有效载荷组成的V-PCC分量。考虑到该定义,在ISOBMFF中定义的子样本信息框可以被更新如下:
Figure BDA0003671411680000721
其中,codec_specific_parameters可以指示映射到子样本的vpcc_unit的必要参数。可用于解释编解码器特定参数值的codec_specific_parameters的两种可能的语法在表7a和表7b中示出。
表7a
codec_specific_parameters值 描述
0 预留
1 补片组数据
2 占用
3 几何形状
4 属性
5,… 预留
表7b
Figure BDA0003671411680000731
在一些实施例中,所声明的参数类型可以在语法上与vpcc_unit_header()和ISO/IEC 23090-5中的相同。
其中,pcm_separate_video_data()如在ISO/IEC 23090-5中所定义的:
Figure BDA0003671411680000741
在另一个实施例中,vpcc_unit_header()可以被原样复制到coded_specific_parameters字段。在另一个实施例中,subsample_prority字段可以被设置为非默认值,以指示vpcc数据单元(作为子样本)的优先级。在这种情况下,如果解码器没有足够的解码器实例,那么它可能更愿意跳过解码此类数据单元。类似的逻辑也可以被应用于可丢弃参数。值0可以指示需要子样本来表示V-PCC样本。
通过使用子样本信息框,文件解析器可以提取每个V-PCC分量,解析其报头信息,进而进一步识别第二级信息,诸如attribute_id、layer_id等。
在一些实施例中,文件解析器可以解析codec_specific_parameters(),并且可以在解析vpcc_header_data()之前进一步获得pcc分量相关信息。这将为解析器提供足够的信息以将子样本数据推送到正确的解码器实例。
在一些实施例中,单独的数据结构可以被并入子样本信息框的新版本中,并且可以在该新数据结构中列出每个V-PCC特定信息。
在一些实施例中,补片数据组单元语法可以包括诸如表8中的描述符和术语。
表8
Figure BDA0003671411680000742
Figure BDA0003671411680000751
在一些实施例中,补片数据组单元可以包括有效载荷和元数据。在一些实施例中,用于补片数据组单元有效载荷的语法可以包括诸如表9中的描述符和术语。
表9
Figure BDA0003671411680000761
在一些实施例中,补片序列参数集语法可以包括诸如表10中的描述符和术语。
表10
Figure BDA0003671411680000762
Figure BDA0003671411680000771
在一些实施例中,补片帧报头语法可以包括诸如表12中的描述符和术语。
表12
Figure BDA0003671411680000772
Figure BDA0003671411680000781
Figure BDA0003671411680000791
在一些实施例中,可以添加pfh_address作为占位符(placeholder)。在一些实施例中,来自表12的报头结构可以被修改成patch_tile报头并且可以定义用于图块的附加结构。在图块式平铺结构中,可以执行在整个帧单元内分配具有2D(x,y)坐标的“补片图块地址”的过程。在一些实施例中,该报头可以仅对应于补片图块。在一些实施例中,对于一个帧可以存在多个图块。在一些实施例中,在这样的场景中,一些信息也可以被放置在帧报头中。
在一些实施例中,aps_attribute_codec_id[i]指示用于压缩具有索引i的属性视频数据的编解码器的标识符。aps_attribute_codec_id[i]可以或应在0到255的范围内,包括其间的所有值和范围。在一些实施例中,这样的值可以是预定义的或者可以由编解码器或另一此类组件来定义。
在一些实施例中,当存在时,aps_pcm_attribute_codec_id[i]指示当PCM编码点被编码在单独的视频流中时,用于压缩属性i的PCM编码点的属性视频数据的编解码器的标识符。aps_pcm_attribute_codec_id[i]可以或应在0到255的范围内,包括其间的所有值和范围。
在一些实施例中,aps_attribute_dimension_minus1[i]加1指示具有索引i的属性的总维度数量(即,通道数量)。aps_attribute_dimension_minus1[i]可以或应在0到255的范围内,包括其间的所有值和范围。
在一些实施例中,aps_attribute_dimension_partitions_minus1[i]加1指示索引为i的属性的属性通道应被分组在其中的划分组的数量。aps_attribute_dimension_partitions_minus1[i]可以或应在0到127的范围内,包括其间的所有值和范围。
在一些实施例中,aps_attribute_partition_channels_minus1[i][j]加1指示被分配给索引为i的属性的索引为j的维度划分组的通道数量。如果j<aps_attribute_dimension_partitions_minus1[i],则aps_attribute_partition_channels_minus1[i][j]可以或应在0到remainingDimensions–2的范围内,包括其间的所有值和范围。如果j=aps_attribute_dimension_partitions_minus1[i],则aps_attribute_partition_channels_minus1[i][j]被设置为等于remainingDimensions–1。
在一些实施例中,aps_attribute_params_enabled_flag[i]指示是否可以信令传送属性参数,例如,针对具有索引i的所有属性。aps_attribute_params_enabled_flag[i]等于1指示可以针对索引为i的属性来信令传送属性参数。aps_attribute_params_enabled_flag[i]等于0指示针对索引为i的属性,可以不或不应信令传送属性参数。
在一些实施例中,aps_attribute_patch_params_enabled_flag[i]指示针对具有索引i的所有属性是否可以信令传送属性补片参数。aps_attribute_patch_params_enabled_flag[i]等于1指示可以信令传送属性补片参数,例如,针对具有索引i的属性。aps_attribute_patch_params_enabled_flag[i]等于0指示可以不或不应信令传送属性补片参数,例如,针对具有索引i的属性。
在一些实施例中,可以根据本文所描述的任何方法来解码V-PCC帧。
在一些实施例中,这样的解码过程的输出可以是一组解码的视频帧或视频流,对应于点云序列的占用、几何形状和属性(如果可用)信息以及解码的补片序列数据信息,其中执行3D重构过程需要它们中的一些或全部。
在一些实施例中,解码过程的输出是解码的点云帧序列。点云帧由一组具有(x,y,z)坐标的点组成。可选地,在一些实施例中,点云帧还可以包含与每个点相关联的一组或多组属性。
在一些实施例中,可以规定解码过程,以使得符合所规定的配置文件、层和级别的所有解码器在针对符合该配置文件、层和级别的比特流而调用与该配置文件相关联的解码过程时将产生在数字上相同的输出。在一些实施例中,这样的解码过程可以产生与由本文所描述的过程产生的输出相同的输出(具有正确的输出顺序或输出定时,如所规定的)。出于尽力解码的目的,符合在给定层和级别的特定配置文件的解码器还可以解码符合不同的层、级别或配置文件的一些比特流,而不必使用产生与由本文所规定的过程产生的解码输出在数字上相同的解码输出的解码过程(无需声明符合其他配置文件、层和级别)。
在一些实施例中,解码过程操作如下:
VPCC比特流可以被解析并被解复用成若干子流,每个子流对应于不同的信息集。特别地,VPCC比特流被解复用成占用图、几何和属性(如果存在)视频子流,并且在补片序列子流中。进而,可以如在后续步骤中所规定地对这些子流进行解码。
可以调用占用图视频解码过程,其中对应于占用图信息的子流作为输入,解码的占用图视频帧作为输出。每个解码的占用图视频帧可以被表示为oFrame[y][x],其中,y和x分别是行和列索引。变量y可以在0到sps_frame_height-1的范围内(包括端点),变量x可以在0到sps_frame_width-1的范围内,包括其间的所有值和范围。
进而,可以调用几何视频解码过程。
对于比特流中的每个存在的属性视频子流,进而可以调用属性视频解码过程,诸如如果属性视频子流存在于比特流中。
进而,可以调用补片序列解码过程,其中对应于编码补片序列信息的子流作为输入,解码的补片序列信息作为输出。
可选地,对于每个点云帧,进而可以用数组sps_layer_absolute_coding_enabled_flag来调用点云帧的重构过程,其中对应于时实例i的所有解码的占用、几何和属性(如果存在)帧和解码的补片帧信息作为输入,点云帧中的解码点列表作为输出。
在一些实施例中,几何视频解码过程被执行如下:
如果sps_layer_count_minus1等于0,则使用几何视频比特流及其相关联的编解码器(由作为输入的gps_geometry_codec_id所指定的)来调用视频解码过程。此过程的输出是被解码和显示/输出的有序几何视频帧GeoFrame[layerIdx][orderIdx][compIdx][y][x]及其相关联的位深GeoBitdepth[layerIdx][orderIdx]、宽度GeoWidth[layerIdx][orderIdx]、以及高度GeoHeight[layerIdx][orderIdx],其中,layerIdx对应于层索引并等于0,orderIdx是解码几何帧的显示顺序索引,compIdx对应于颜色分量索引并等于0,y在0到GeoHeight[layerIdx][orderIdx]-1的范围内(包括端点),x是解码帧中的列索引,并在0到GeoWidth[layerIdx][orderIdx]-1的范围内,包括其间的所有值和范围。
否则,应用以下:
如果sps_multiple_layer_streams_present_flag等于0,则使用几何视频比特流及其相关联的编解码器(由作为输入的gps_geometry_codec_id所指定的)来调用视频解码过程。此过程的输出是被解码和显示/输出的有序中间几何视频帧tempGeoFrame[tempOrderIdx][compIdx][y][x]及其相关联的位深tempGeoBitdepth[tempOrderIdx]、宽度tempGeoWidth[tempOrderIdx]、以及高度tempGeoHeight[tempOrderIdx],其中,tempOrderIdx是所有解码几何帧的显示顺序索引,compIdx对应于颜色分量索引并等于0,y在0到tempGeoHeight[tempOrderIdx]-1的范围内(包括端点),x是解码帧中的列索引,并在0到tempGeoWidth[tempOrderIdx]-1的范围内,包括其间的所有值和范围。进而,针对每个层的按显示/输出顺序orderIdx的解码几何视频帧被导出如下:
Figure BDA0003671411680000831
否则(如果sps_multiple_layer_streams_present_flag等于1),则调用多个视频解码过程,每个使用具有与其相关联的不同的vpcc_layer_index的几何视频比特流及相关联的编解码器(由作为输入的gps_geometry_codec_id所指定的)。此过程的输出是被解码和显示/输出的有序中间几何视频帧tempGeoFrame[layerIdx][orderIdx][compIdx][y][x]及其相关联的位深tempGeoBitdepth[layerIdx][orderIdx]、宽度tempGeoWidth[layerIdx][orderIdx]、以及高度tempGeoHeight[layerIdx][orderIdx],其中,layerIdx对应于每个帧的层索引并在0到sps_layer_count_minus1的范围内(包括端点),orderIdx是针对每个层的解码几何帧的显示顺序索引,compIdx对应于颜色分量索引并等于0,y在0到tempGeoHeight[layerIdx][orderIdx]-1的范围内(包括端点),x是解码帧中的列索引,并在0到tempGeoWidth[layerIdx][orderIdx]-1的范围内,包括其间的所有值和范围。进而,针对每个层的按显示/输出顺序orderIdx的解码几何视频帧被导出如下:
Figure BDA0003671411680000841
在一些实施例中,属性解码过程可以被执行如下:
如果aps_attribute_count等于0,那么没有属性视频帧被解码,并且没有属性信息与最终的重构点云相关联。
否则(如果aps_attribute_count不等于0),应用以下:
如果sps_layer_count_minus1等于0,则调用aps_attribute_count个视频解码过程,每个利用与其相关联的不同的vpcc_attribute_index及相关联的编解码器(由作为输入的aps_attribute_codec_id[vpcc_attribute_index]所指定的)。此过程的输出是被解码和显示/输出的有序属性视频帧AttrFrame[attrIdx][layerIdx][orderIdx][compIdx][y][x]及其相关联的位深AttrBitdepth[attrIdx][layerIdx][orderIdx]、宽度AttrWidth[attrIdx][layerIdx][orderIdx]、以及高度AttrHeight[attrIdx][layerIdx][orderIdx]信息,其中,attrIdx对应于属性索引并在0到aps_attribute_count-1的范围内(包括端点),layerIdx对应于层索引并等于0,orderIdx是解码属性帧的显示顺序索引,compIdx对应于属性分量索引并在0到aps_attribute_dimension_minus1[attrIdx-1]的范围内,y在0到AttrHeight[attrIdx][layerIdx][orderIdx]-1的范围内(包括端点),x是解码帧中的列索引,并在0到AttrWidth[attrIdx][layerIdx][orderIdx]-1的范围内,包括其间的所有值和范围。
否则(sps_layer_count_minus1不等于0),应用以下:
如果sps_multiple_layer_streams_present_flag等于0,则调用aps_attribute_count个视频解码过程,每个利用与其相关联的不同的vpcc_attribute_index及相关联的编解码器(由作为输入的aps_attribute_codec_id[vpcc_attribute_index]所指定的)。此过程的输出是被解码和显示/输出的有序中间属性视频帧tempAttrFrame[attrIdx][tempOrderIdx][compIdx][y][x]及其相关联的位深tempAttrBitdepth[attrIdx][tempOrderIdx]、宽度tempAttrWidth[attrIdx][tempOrderIdx]、以及高度tempAttrHeight[attrIdx][tempOrderIdx]信息,其中,attrIdx对应于属性索引并在0到aps_attribute_count-1的范围内(包括端点),tempOrderIdx是所有解码属性帧的显示顺序索引,compIdx对应于属性分量索引并在0到aps_attribute_dimension_minus1[attrIdx-1]的范围内,y在0到tempAttrHeight[attrIdx][tempOrderIdx]-1的范围内(包括端点),x是解码帧中的列索引,并在0到tempAttrWidth[attrIdx][tempOrderIdx]-1的范围内,包括其间的所有值和范围。进而,针对每个层的按显示/输出顺序orderIdx的索引为attrIdx的属性的解码属性视频帧被导出如下:
Figure BDA0003671411680000861
否则(sps_multiple_layer_streams_present_flag等于1),调用多个视频解码过程,每个使用具有与其相关联的不同的vpcc_attribute_index和vpcc_layer_index的属性视频比特流及相关联的编解码器(由作为输入的aps_attribute_codec_id[vpcc_attribute_index]所指定的)。此过程的输出是被解码和显示/输出的有序属性视频帧AttrFrame[attrIdx][layerIdx][orderIdx][compIdx][y][x]及其相关联的位深AttrBitdepth[attrIdx][layerIdx][orderIdx]、宽度AttrWidth[attrIdx][layerIdx][orderIdx]、以及高度AttrHeight[attrIdx][layerIdx][orderIdx]信息,其中,attrIdx对应于属性索引并在0到aps_attribute_count-1的范围内,layerIdx对应于每个帧的层索引并在0到sps_layer_count_minus1的范围内(包括端点),orderIdx是针对每个层的解码属性帧的显示顺序索引,compIdx对应于属性分量索引并在0到aps_attribute_dimension_minus1[attrIdx-1]的范围内,y在0到AttrHeight[attrIdx][layerIdx][orderIdx]-1的范围内(包括端点),x是解码帧中的列索引,并在0到AttrWidth[attrIdx][layerIdx][orderIdx]-1的范围内,包括其间的所有值和范围。
现在参考用于补片序列解码的过程,此过程的输入是对应于VPCC比特流的补片序列数据单元的比特流。
在一些实施例中,此过程的输出是解码的补片帧,以及在补片序列数据单元中包含的任何相关联的几何形状和/或属性参数,根据它们对应的补片帧顺序计数以升序排序。
在一些实施例中,针对被解码的当前补片帧CurrPatchFrame,解码过程操作如下:
如本文所讨论的补片序列数据单元的解码,其可以具有当前补片帧的补片序列数据单元和相关联的参数集单元作为输入,被封装在这些补片序列数据单元内的解析语法结构作为输出。这样的解码可以通过从补片序列数据单元中提取语法结构然后解析该语法结构来执行。
此过程可以进一步包括导出与补片帧顺序计数相关的变量和函数。
在针对每个补片帧的解码过程开始时,可以调用诸如本文所描述的引用补片帧列表构建过程来导出引用补片帧列表RefPatchFrameList。
进而,可以调用诸如本文所描述的引用补片帧标记过程,其中,引用补片帧可以被标记为“未用于引用”或“用于长期引用”。
本文所描述的一些过程可以根据补片模式来规定补片解码过程,诸如以下过程:
·用于解码帧内编码补片的过程;
·用于解码帧间编码补片的过程;以及
·用于解码PCM编码补片的过程。
在一些实施例中,在当前补片帧已被解码之后,它可以被标记为“用于短期引用”。
现在参考用于补片序列数据单元解码的过程,这些过程的输入是当前补片帧的补片序列数据单元及其相关联的参数集单元,而此过程的输出是被封装在这些补片序列数据单元内的解析语法结构。在一些实施例中,针对每个补片序列数据单元的解码过程可以包括从补片序列数据单元中提取语法结构,并随后解析该语法结构。
现在参考用于补片帧报头解码的过程,其可以包括用于补片帧顺序计数推导的过程。在一些实施例中,可以执行用于补片帧顺序计数推导的过程,从而产生具有索引patchFrmIndex的当前补片帧的补片帧顺序计数PatchFrmOrderCntVal的输出。在一些实施例中,补片帧顺序计数可用于识别和排序补片帧,以及用于解码器一致性检查。在一些实施例中,每个编码补片帧与补片帧顺序计数变量(被标示为PatchFrmOrderCntVal)相关联。在一些实施例中,当引用补片帧缓冲区中没有可用的引用补片帧时,变量prevPatchFrmOrderCntLsb和prevPatchFrmOrderCntMsb被导出如下:
令prevPatchFrm为解码顺序中的先前补片帧,即,索引为patchFrmIndex-1的补片帧,
变量prevPatchFrmOrderCntLsb被设置为等于prevPatchFrm的补片帧顺序计数LSB值pfh_patch_frame_order_cnt_lsb[patchFrmIndex-1],
变量prevPatchFrmOrderCntMsb被设置为等于prevPatchFrm的PatchFrmOrderCntMsb,以及
当前补片帧的变量PatchFrmOrderCntMsb被导出如下:
如果在引用补片帧缓冲区中没有可用的引用补片帧,则将PatchFrmOrderCntMsb设置为等于0。
否则,PatchFrmOrderCntMsb被导出如下:
Figure BDA0003671411680000881
Figure BDA0003671411680000891
在一些实施例中,PatchFrmOrderCntVal可以被导出如下:PatchFrmOrderCntVal=PatchFrmOrderCntMsb+
pfh_patch_frame_order_cnt_lsb[patchFrmIndex]
在一些实施例中,PatchFrmOrderCntVal的值可以在-231到231-1的范围内,包括其间的所有值和范围。在一些实施例中,对于一个CPCS,任何两个编码补片帧的PatchFrmOrderCntVal值可以不或不应相同。
在一些实施例中,在解码过程期间的任何时刻,DPB中任何两个引用补片帧的PatchFrmOrderCntVal&(MaxLtPatchFrmOrderCntLsb-1)的值可以不或不应相同。
根据至少一个实施例,函数PatchFrmOrderCnt(pFrmX)被规定如下:
PatchFrmOrderCnt(pFrmX)=补片帧pFrmX的PatchFrmOrderCntVal
在一些实施例中,函数DiffPatchFrmOrderCnt(pFrmA,pFrmB)被规定如下:
DiffPatchFrmOrderCnt(pFrmA,pFrmB)=PatchFrmOrderCnt(pFrmA)–PicOrderCnt(pFrmB)
在一些实施例中,比特流可以不包含导致在解码过程中使用的DiffPatchFrmOrderCnt(pFrmA,pFrmB)的值不在-215到215-1的范围内(包括其间的所有值和范围)的数据。
例如,令X为当前补片帧并且Y和Z是同一CPCS中的两个其他补片帧,根据至少一些实施例,当DiffPatchFrmOrderCnt(X,Y)和D iffPatchFrmOrderCnt(X,Z)两者均为正或两者均为负时,Y和Z可以被视为在与X相同的输出顺序方向上。
现在参考用于引用补片帧列表构建的过程,可以在针对每个补片帧的解码过程开始时调用这样的过程。在一些实施例中,引用补片帧可以通过引用索引来寻址。引用索引是索引到引用补片帧列表的索引。当解码I补片帧时,在解码补片帧数据时不使用引用补片帧列表。当解码P补片帧时,在解码补片帧数据时使用单个引用补片帧列表RefPatchFrmList。
在一些实施例中,在针对每个补片帧的解码过程开始时,导出引用补片帧列表RefPatchFrmList。引用补片帧列表可以在标记引用补片帧或解码补片帧数据中使用。
根据一些实施例,引用补片帧列表RefPatchFrmList被构造如下:
Figure BDA0003671411680000901
RefPatchFrnList中的第一NumRefIdxActive条目可以被称为RefPatchFrmList中的活动条目,并且RefPatchFrmList中的其他条目可以被称为RefPatchFrmList中的非活动条目。
根据一些实施例,应用以下约束可以是比特流一致性的要求:
i)num_ref_entries[RlsIdx]不小于NumRefIdxActive;
ii)RefPatchFrmList中每个活动条目所引用的补片帧存在于DPFB中;
iii)RefPatchFrmList中每个条目所引用的补片帧不是当前补片帧;
iv)补片帧的RefPatchFrmList中的短期引用补片帧条目和长期引用补片帧条目不引用相同的补片帧;以及
v)RefPatchFrmList中不存在长期引用补片帧条目,对于RefPatchFrmList,当前补片帧的PatchFrmOrderCntVal与该条目所引用的补片帧的PatchFrmOrderCntVal之差大于或等于224。
在一些实施例中,令setOfRefPatchFrames为RefPatchFrmList中的所有条目所引用的唯一补片帧的集合,setOfRefPatchFrames中的补片帧的数量可以小于或等于psps_max_dec_patch_frame_buffering_minus1。
现在参考用于引用补片帧标记的过程,可以在解码补片帧报头和用于补片帧的引用补片帧列表构造的解码过程之后但在解码补片帧数据之前,每补片帧调用一次这样的过程。此过程可以导致DPFB中的一个或多个引用补片帧被标记为“未用于引用”或“用于长期引用”。
DPFB中的解码补片帧可以被标记为“未用于引用”、“用于短期引用”或“用于长期引用”,但在解码过程的操作期间的任何给定时刻,只有这三个中的一个。将这些标记中的一个分配给补片帧在适用时将隐式移除这些标记中的另一个。当补片帧被引用以被标记为“用于引用”时,可统称为补片帧被标记为“用于短期引用”或“用于长期引用”(但不是同时两者)。
短期引用补片帧由其PatchFrmOrderCntVal值标识。长期引用补片帧由其PatchFrmOrderCntVal值的Log2(MaxLtPatchFrmOrderCntLsb)最低有效位标识。
对于至少一些实施例,应用以下:
·对于RefPatchFrmList中的每个长期引用补片帧条目,当所引用的补片帧是短期引用补片帧时,该补片帧被标记为“用于长期引用”;以及
·DPFB中未被RefPatchFrmList中的任何条目引用的每个引用补片帧被标记为“未用于引用”。
现在参考用于解码补片单元的过程,诸如通用过程,这样的过程的输入可以包括当前补片帧索引frmIdx、当前补片索引p、以及当前补片模式pfdu_patch_mode[frmIdx][p]。
在一些实施例中,此过程的输出是与当前补片相关联的若干参数,包括其2D和对应的3D位置信息,诸如参数Patch2dShiftU[frmIdx][p]、Patch2dShiftV[frmIdx][p]、Patch2dSizeU[frmIdx][p]、Patch2dSizeV[frmIdx][p]、Patch3dShiftTangentAxis[frmIdx][p]、Patch3dShiftBiTangentAxis[frmIdx][p]、Patch3dShiftNormalAxis[frmIdx][p]、PatchNormalAxis[frmIdx][p]、PatchOrientationIndex[frmIdx][p]、PatchLod[frmIdx][p]、以及PatchProjectionMode[frmIdx][p]。
在一些实施例中,Patch2dShiftU[frmIdx][p]指定了当前补片的补片边界框大小的左上角的x坐标。Patch2dShiftU[frmIdx][p]的值可以在0到Min((2pfh _2d_shift_u_bit_count_minus1[frmIdx]+1–1)*PatchPackingBlockSize,sps_frame_width-1)的范围内,包括其间的所有值和范围。
在一些实施例中,Patch2dShiftV[frmIdx][p]指定了当前补片的补片边界框大小的左上角的y坐标。Patch2dShiftV[frmIdx][p]的值可以在0到Min((2pfh _2d_shift_v_bit_count_minus1[frmIdx]+1–1)*PatchPackingBlockSize,sps_frame_height-1)的范围内,包括其间的所有值和范围。
在一些实施例中,Patch2dSizeU[frmIdx][p]指定了当前补片的边界框的宽度。Patch2dSizeU[frmIdx][p]的值可以在0到(sps_frame_width–1)的范围内,包括其间的所有值和范围。
在一些实施例中,Patch2dSizeV[frmIdx][p]指定了当前补片的边界框的高度。Patch2dSizeV[frmIdx][p]的值可以在0到(sps_frame_height-1)的范围内,包括其间的所有值和范围。
在一些实施例中,Patch3dShiftTangentAxis[frmIdx][p]指定了沿着切线轴应用于当前补片中的重构补片点的偏移。Patch3dShiftTangentAxis[frmIdx][p]的值可以在0到Min(2pfh_3d_shift_tangent_axis_bit_count_minus1[frmIdx]+1,2gps_geometry_3d_coordinates_bitdepth_minus1+1-1)的范围内,包括其间的所有值和范围。
在一些实施例中,Patch3dShiftBiTangentAxis[frmIdx][p]指定了沿着双切线轴应用于当前补片中的重构补片点的偏移。Patch3dShiftBiTangentAxis[frmIdx][p]的值可以在0到Min(2pfh_3d_shift_bitangent_axis_bit_count_minus1[frmIdx]+1,2gps _geometry_3d_coordinates_bitdepth_minus1+1-1)的范围内,包括其间的所有值和范围。
在一些实施例中,Patch3dShiftNormalAxis[frmIdx][p]指定了沿着法线轴应用于当前补片中的重构补片点的偏移。Patch3dShiftNormalAxis[frmIdx][p]的值可以在0到Min(2pfh_3d_shift_normal_axis_bit_count_minus1[frmIdx]+1,2gps_geometry_3d_coordinates_bitdepth_minus1+1-1)的范围内,包括其间的所有值和范围。
在一些实施例中,PatchNormalAxis[frmIdx][p]是当前补片的投影平面的法线的索引。PatchNormalAxis[frmIdx][p]的值可以在0到2的范围内,包括其间的所有值和范围。
在一些实施例中,PatchOrientationIndex[frmIdx][p]指定了当前补片的补片定向索引。
在一些实施例中,PatchLod[frmIdx][p]指定了应用于当前补片的LOD缩放因子。当前补片的重构点3D位置可以在其从2D投影之后并在应用任何进一步的变换之前缩放2pdu_lod[frmIdx][p]
在一些实施例中,PatchProjectionMode[frmIdx][p]等于0可以指定当前补片将要被投影到哪个平面上。
在一些实施例中,如果pfdu_patch_mode[frmIdx][p]等于I_INTRA或P_INTRA,则可以使用用于解码帧内编码补片的过程,其中frmIdx和p作为此过程的输入并且此过程的输出被用作输出。
在一些实施例中,如果pfdu_patch_mode[frmIdx][p]等于P_INTER,则使用用于解码部分0中的帧间编码补片的过程,其中frmIdx和p作为此过程的输入并且此过程的输出被用作输出。
在一些实施例中,如果pfdu_patch_mode[frmIdx][p]等于I_PCM或P_PCM,则可以使用用于解码PCM编码补片的过程,其中frmIdx和p作为此过程的输入并且此过程的输出被用作输出。
现在参考用于解码以帧内模式编码的补片单元的过程,此过程的输入可以包括当前补片帧索引frmIdx和/或当前补片索引p。
在一些实施例中,给定补片数据单元中的解析元素,可以首先分配以下补片相关变量中的一个或多个:
Patch2dShiftU[frmIdx][p]=pdu_2d_shift_u[frmIdx][p]*PatchPackingBlockSize
Patch2dShiftV[frmIdx][p]=pdu_2d_shift_v[frmIdx][p]*PatchPackingBlockSize
Patch3dShiftTangentAxis[frmIdx][p]=pdu_3d_shift_tangent_axis[frmIdx][p]
Patch3dShiftBiTangentAxis[frmIdx][p]=pdu_3d_shift_bitangent_axis[frmIdx][p]
Patch3dShiftNormalAxis[frmIdx][p]=pdu_3d_shift_normal_axis[frmIdx][p]
PatchNormalAxis[frmIdx][p]=pdu_normal_axis[frmIdx][p]
PatchOrientationIndex[frmIdx][p]=pdu_orientation_index[frmIdx][p]
PatchLod[frmIdx][p]=pdu_lod[frmIdx][p]
PatchProjectionMode[frmIdx][p]=pdu_projection_mode[frmIdx][p]
Patch45degreeProjectionRotationAxis[frmIdx][p]=pdu_45degree_projection_rotation_axis[frmIdx][p]
在一些实施例中,进而可以导出变量Patch2dSizeU[frmIdx][p]和Patch2dSizeV[frmIdx][p],诸如以下所示:
如果p等于0,则:
Patch2dSizeU[frmIdx][p]=pdu_2d_delta_size_u[frmIdx][p]*PatchPackingBlockSize
Patch2dSizeV[frmIdx][p]=pdu_2d_delta_size_v[frmIdx][p]*PatchPackingBlockSize
否则,如果(p>0),则:
Patch2dSizeU[frmIdx][p]=Patch2dSizeU[frmIdx][p–1]+pdu_2d_delta_size_u[frmIdx][p]*PatchPackingBlockSize
Patch2dSizeV[frmIdx][p]=Patch2dSizeV[frmIdx][p–1]+pdu_2d_delta_size_v[frmIdx][p]*PatchPackingBlockSize
在一些实施例中,进而可以导出变量PatchTangentAxis[frmIdx][p]和PatchBiTangentAxis[frmIdx][p],诸如以下所示:
如果PatchNormalAxis[frmIdx][p]等于“零”,则PatchTangentAxis[frmIdx][p]被分配值2,并且PatchBiTangentAxis[frmIdx][p]被分配值1。
否则,如果PatchNormalAxis[frmIdx][p]等于1,则PatchTangentAxis[frmIdx][p]被分配值2,并且PatchBiTangentAxis[frmIdx][p]被分配值0。
否则(PatchNormalAxis[frmIdx][p]等于2),PatchTangentAxis[frmIdx][p]被分配值0,并且PatchBiTangentAxis[frmIdx][p]被分配值1。
信令子样本条目描述
诸如“基于视频的点云编解码器”(V-PCC)之类的现代多流编码器,包括多个独立编码的媒体和元数据流,诸如属性、几何形状、占用和补片数据流。V-PCC基本流由许多不同的视频编码和元数据流组成,这些流可具有不同的编码方案、编解码器、和/或配置。
如上文以及于2019年5月29日提交的美国临时专利申请No.62/853,903(以下简称为“'903临时专利”,其全部内容通过引用而并入本文中以用于所有目的)所描述的,整个基本流可以被存储在单个轨道中,而无需解复用到多个轨道。上文和'903临时专利中描述了用于在视频编码中信令传送和存储压缩点云的方法、装置和计算机程序产品。该方法、装置和计算机程序产品可以与多种视频格式结合使用。关于压缩点云的编码,该方法、装置和计算机程序产品访问点云压缩编码比特流,并存储该点云压缩编码比特流。点云压缩编码比特流包括一个或多个V-PCC参数集、视频编码属性比特流、视频编码占用和几何形状比特流、以及非视频编码补片数据比特流。纹理可以是属性之一并被编码为属性比特流。所有比特流可以被划分成更小的单元,其被称为V-PCC单元,具有特定的单元报头。关于压缩点云的解码,该方法、装置和计算机程序产品接收点云压缩编码比特流,并解码该点云压缩编码比特流。
此类V-PCC编码的基本流可以被存储为ISOBMFF文件中的多个轨道,或者被存储为单个轨道。当它们被存储为单个媒体轨道时,许多不同的编码器的访问单元以V-PCC规范定义的方式交错,并且它们被分组为“V-PCC访问单元”。一个或多个V-PCC访问单元对应于单个轨道表示的样本。
目前不可能在单个轨道V-PCC存储中信令传送所使用的底层视频编解码器,因为这种单个轨道的样本条目仅声明高级V-PCC配置。底层编解码器使用特定SEI消息来信令传送,或者通过解析必要的视频NAL单元(例如,视频特定的SPS)来理解。
这意味着视频解码器在V-PCC客户端接收并解析子样本之前无法被初始化,这是不希望的,至少因为许多设备在实际“下载”流之前想知道它们是否可以解码该流(例如,通过检查DASH MPD或初始化段并查看样本条目)。
在V-PCC中,V-PCC样本的子样本可以具有按任意顺序的子样本。因此,没有可用于预先假定子样本的顺序的模式。
在更一般的意义上,ISOBMFF不缺少对声明这样的复杂且现代媒体编码用例的支持,在这种用例中,轨道的“样本”由多个独立编码的(并且可不同的)媒体类型组成。
因此,本文提供了用于通过使用子样本并引入用于声明此类子样本的类型和代码参数的机制来声明此类信息的装置、系统、设备、计算机程序产品和方法的示例实施例。此外,本文描述了用于将多个单独编码的媒体类型有效地交错到ISOBMFF文件的单个轨道(和单个样本)中的方法、装置和计算机程序产品。这种方法提供了许多益处,例如,在V-PCC编码方案中,其中,基于视频的点云表示通常包括多个独立编码的媒体比特流。在这种情况下,本领域技术人员将有动机创建多轨道ISOBMFF文件,诸如上文所描述的。然而,存储整个基本流而不解复用到多个轨道通常更便易、更有效、更经济、计算复杂度更低等。在'903临时专利中描述了一种用于存储和信令传送压缩点云的方法,其中,整个基本流被存储在单个轨道中,而无需解复用到多个轨道。
然而,这种单个轨道方法可需要在单个轨道元数据级中声明子样本的类型,以便解码器可以正确地被初始化并且V-PCC解码器可以正常地工作以解码编码媒体的单个轨道。对于媒体轨道,此类声明通常在SampleTableBox内的样本条目中完成,并且它们仅涵盖单个媒体类型。换句话说,目前还没有用于声明不同的媒体类型(诸如两个独立编码的视频流)的方法。
本文描述了用于声明多个单独编码的媒体类型有效地交错到ISOBMFF文件中的单个轨道(和单个样本中)的途径、方法、系统、装置和计算机程序产品。提供了子样本条目,其可用于在单个媒体轨道中声明多个不同的媒体类型的子样本。
在各种实施例中,子样本条目与样本序列内的子样本序列相关联。子样本条目的语义可意味着如果子样本序列被封装在其自己的轨道中(没有其他子样本或其他附加的报头数据(诸如V-PCC单元报头)存在于该轨道中),则该轨道中的样本序列将符合与子样本条目相同的样本条目。
这可以以多种不同的方式完成:
选项(1):可以定义轨道级SubSampleDescriptionBox,在其中以索引的方式声明所有子样本条目类型(例如,类似于ISOBMFF中的样本条目)。SubSampleInformationBox可以被扩展以指示针对每个子样本的子样本条目索引。例如,SubSampleDescriptionBox可以被定义如下:
Sub-Sample Description框
定义
框类型:'ssdb'
容器:SampleTableBox
强制性:否
数量:刚好1个
Figure BDA0003671411680000981
Figure BDA0003671411680000991
SubSampleEntry抽象类可以用个体解码媒体比特流的实际SampleEntry()格式来实例化。例如,对于H.265视频编码样本,格式字段可以是ISO/IEC 14496-15中定义的样本条目类型之一('hvc1'、'hev1'、'hvcC'等),并且SubSampleEntry可以是如在ISO/IEC14496-15中定义的HEVCSampleEntry()。
data_reference_index可以被设置为0(“零”)以指示它不相关并且可以被省略。
entry_count可以被设置为在媒体样本的子样本中使用的样本条目的数量。例如,如果有三个媒体流被交错为访问单元,则可存在至少三个样本条目。例如,如果媒体流使用多个样本条目,则可存在三个以上的样本条目。
扩展SubSampleInformationBox
在一些实施例中,有必要指示哪个子样本描述条目指代子样本。这可以通过扩展SubSampleInformationBox来完成,如下:
Figure BDA0003671411680001001
其中,在两个不同的循环中使用相同的subsample_count值。这保证子样本和子样本描述的条目数量相同,并且它们一一匹配。
subsample_description_entry_index指示如在SubSampleDescriptionBox中列出的子样本描述条目的索引。
在其他实施例中,可以使用标志来信令传送子样本描述条目索引的存在。在这样的实施例中,可不使用版本,而是可以代替地使用某个标志值来信令传送子样本描述条目索引的存在。在一些实施例中,诸如上文提供的语法示例中,行“if(version==2)”例如可以被替换为“if(flags&1)”。
在其他实施例中,版本或标志的使用可以被省略并且可以直接插入以下数据结构:
Figure BDA0003671411680001011
在可以与上文所描述的其他实施例一起应用或独立于这些其他实施例而应用的另一个实施例中,提供了单个subsample_description_entry_index值集,并且该集合应用于容器框范围内的每个样本。该实施例至少在容器框是TrackFragmentBox时可以很有用。例如,可以使用以下语法:
Figure BDA0003671411680001012
在一些实施例中,上述结构是向后兼容的,因为旧解析器可以安全地忽略新数据结构。
在另一个实施例中,数据结构可以是非向后兼容的,诸如以下所示:
Figure BDA0003671411680001013
Figure BDA0003671411680001021
在一些实施例中,还可以使用标志代替版本,然而,该方法的可能缺点是它不向后兼容并且可破坏现有的旧解析器。
在另一个实施例中,SubSampleInformationBox的codec_specific_parameters字段可用于直接信令传送子样本描述索引。
选项(2):可以定义新框(SubSampleDescriptionIndexBox),其包含与SubSampleInformationBox位于同一容器内的子样本描述条目索引。在一些实施例中,该方法可要求在同一容器框中存在一个且仅一个SubSampleInformationBox。在一些实施例中,如果在同一容器框中存在多个SubSampleInformationBox,则需要可操作以将这些SubSampleDescriptionIndexBox与相应的SubSampleInformationBox相关联的进一步的部件,例如,通过在SubSampleInformationBox和SubSampleDescriptionIndexBox两者中添加标识符字段,并在标识符的值相等时将它们关联在一起。
SubSampleDescriptionIndexBox:
框类型:'ssdi'
容器:SampleTableBox或TrackFragmentBox
强制性:否
数量:零个或多个
Figure BDA0003671411680001031
其中,entry_count和subsample_count具有与SubSampleInformationBox中相同的值。
在替代语法中,样本运行一次被关联到一个给定的子样本描述条目索引。例如,可以使用以下语法:
Figure BDA0003671411680001032
Figure BDA0003671411680001041
其中,sample_run指定了刚好在其后的一组子样本描述条目索引应用于的样本的数量。
在具有替代语法的另一个实施例中,提供了单个subsample_description_entry_index值集,并且该集合应用于容器框范围内的每个样本。例如,在一些实施例中,该方法在容器框是TrackFragmentBox时可相对更有用。
选项(3):在一些实施例中,选项3可以针对电影片段而被应用,而选项2可以在容器是SampleTableBox时被应用。在一些实施例中,根据选项3,TrackFragmentHeaderBox可以被扩展以包含应用于轨道片段的每个样本的一组子样本描述条目索引。例如,在一些实施例中,可以使用以下语法。
Figure BDA0003671411680001042
选项(4):可以扩展轨道级样本条目的使用,以使得它们还可以索引子样本。例如,可以声明如文件所要求的样本条目的数量为SampleDescriptionBox中的SampleEntry()。可使能SubSampleInformationBox以引用在轨道的SampleDescriptionBox的SampleEntry()的索引。
选项(5):在分段的MP4文件中,电影片段的子样本可以被分组成子样本组描述。这些描述可驻留在SampleTableBox或TrackFragmentBox级的新框结构中。这样的子样本组描述可以经由子样本到组映射框而进一步被分配给子样本。
在选项1-5的各种实施例中,子样本条目与样本序列内的子样本序列相关联。子样本条目的语义可意味着如果子样本序列被封装在其自己的轨道中,而没有其他子样本或其他附加的报头数据(诸如V-PCC单元报头)存在于该轨道中,则该轨道中的样本序列将符合与子样本条目相同的样本条目。子样本条目类型可以在轨道极子样本描述框被索引,并且子样本信息框可以被扩展以指示针对每个子样本的子样本条目索引。子样本信息框可以被扩展以包括标识子样本描述条目索引的存在的版本或标志。可以形成子样本描述索引框,以用于将子样本描述条目索引与子样本信息框包含在同一容器中。用于电影片段轨道的轨道片段报头框可以被扩展以包括应用于轨道片段的每个样本的一组子样本描述条目索引。可替代地,在轨道级的样本条目可以被扩展以对样本描述框中的子样本进行索引,并且子样本信息框可以引用在轨道级样本描述框的样本条目的索引。
现在参考图4,提供了一种方法30,其包括在框31,访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为一个或多个媒体轨道。所示方法30进一步包括:在框32,形成轨道级子样本描述框,该轨道级子样本描述框包括用于相应的多个子样本的多个子样本条目类型。所示方法30进一步包括:在框33,通过在该轨道级子样本描述框的编解码器特定参数相关的字段中包括相应的点云单元报头信息,指示一个或多个类型的点云压缩编码比特流分量。在一些实施例中,方法30可以可选地进一步包括:在框34,扩展子样本信息框,以通过以下操作来指示子样本条目索引:在相关的子样本描述框中指示子样本条目的存在顺序,并进一步经由版本值或者在所述子样本信息框中设置标志来指示其存在。在一些实施例中,具有第一打包类型的所述至少一个媒体轨道和具有第二打包类型的至少一个其他媒体轨道中的至少一个,所述第一打包类型和所述第二打包类型经由所述子样本条目索引被信令传送。在一些实施例中,该方法可以进一步包括:访问属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流;检测该属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流遵循兼容的编码和定时结构;以及至少基于该兼容的编码和定时结构来构建并存储视频媒体轨道。在一些实施例中,所述点云压缩编码比特流包括至少一个属性信息比特流、至少一个几何形状信息比特流、至少一个占用信息比特流、以及至少一个补片信息比特流。在一些实施例中,该方法可以进一步包括:访问该属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流;将该属性信息码流存储在属性视频媒体轨道中;将该几何形状信息比特流存储在几何形状视频媒体轨道中;将该占用信息比特流存储在占用视频媒体轨道中;将该补片信息比特流存储在另一个编码媒体或元数据轨道中;以及在文件中构建并存储交错指示符元数据,该交错指示符元数据指示该属性视频媒体轨道、几何形状视频媒体轨道、占用视频媒体轨道和单独的编码媒体或元数据轨道的一个或多个分量的交错模式。在一些实施例中,针对其指示交错模式的所述一个或多个分量中的每一个可使用SubSampleInformationBox访问,所述SubSampleInformationBox针对所述一个或多个分量定义顺序和配置信息。在一些实施例中,存储包括:以国际标准化组织基础媒体文件格式(ISOBMFF)或任何其他对象结构化媒体文件格式存储不同的基于视频的点云压缩结构。
在一些实施例中,可以提供用于执行本文所描述的任何方法(诸如方法30)的装置。在一些实施例中,该装置可以包括诸如至少一个处理器和包括用于一个或多个程序的计算机程序代码的至少一个存储器之类的部件,该部件被配置为使该装置至少:访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为一个或多个媒体轨道;形成轨道级子样本描述框,该轨道级子样本描述框包括用于相应的多个子样本的多个子样本条目类型;以及通过在该轨道级子样本描述框的编解码器特定参数相关的字段中包括相应的点云单元报头信息,指示一个或多个类型的点云压缩编码比特流分量。在一些实施例中,该装置可以进一步包括用于使该装置执行以下操作的部件:扩展子样本信息框以通过指示版本值或者在所述子样本信息框内设置标志来指示子样本条目索引。
在一些实施例中,一种计算机程序产品包括其中存储有计算机可执行程序代码指令的至少一个非暂时性计算机可读存储介质,这些计算机可执行程序代码指令包括被配置为在执行时执行以下操作的程序代码指令:访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为一个或多个媒体轨道;形成轨道级子样本描述框,该轨道级子样本描述框包括用于相应的多个子样本的多个子样本条目类型;以及通过在该轨道级子样本描述框的编解码器特定参数相关的字段中包括相应的点云单元报头信息,指示一个或多个类型的点云压缩编码比特流分量。在一些实施例中,这些程序代码指令可以进一步被配置为在执行时:扩展子样本信息框,以通过指示版本值或者在所述子样本信息框中设置标志来指示子样本条目索引。
现在参考图5,方法40可以包括:在框41,访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为一个或多个媒体轨道。在一些实施例中,方法40可以进一步包括:在框42,定义多个子样本描述索引框,子样本描述索引框包括子样本描述条目索引,所述子样本描述索引框被存储在和与所述多个子样本描述索引框相关联的相应的多个子样本信息框相同的容器中。在一些实施例中,方法40进一步包括:在框43,向所述多个子样本描述索引框的相应的子样本描述索引框和所述多个子样本信息框的相应的子样本信息框添加唯一标识符,所述唯一标识符可操作以标识与第一子样本信息框相关联的第一子样本描述索引框。
现在参考图6,方法50可以包括:在框51,访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为与电影片段的样本相关联的一个或多个媒体轨道。在一些实施例中,方法50进一步包括:在框52,定义多个子样本描述索引框,子样本描述索引框包括子样本描述条目索引,所述子样本描述索引框被存储在和与所述多个子样本描述索引框相关联的相应的多个子样本信息框相同的容器中。方法50进一步包括:在框53,扩展轨道片段报头框以包括应用于该电影片段的样本的一组所述子样本描述条目索引。
现在参考图7,方法60可以包括:在61,访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为与电影片段的样本相关联的一个或多个媒体轨道。方法60进一步包括:在62,对所述一个或多个媒体轨道的样本描述框内的多个样本实体进行索引。
根据其他实施例,提供了用于解码根据本文所描述的任何实施例编码的任何点云视频的方法、装置、和/或计算机程序产品。
如上所述,图4-7包括根据某些示例性实施例的装置10、方法和计算机程序产品的流程图。将理解,这些流程图的每个框以及这些流程图中的框的组合可以通过各种方式来实现,诸如硬件、固件、处理器、电路、和/或与包括一个或多个计算机程序指令的软件的执行相关联的其他设备。例如,本文所描述的一个或多个过程可以由计算机程序指令来体现。就此而言,体现本文所描述的过程的计算机程序指令可以由采用本发明的实施例的装置的存储器设备14存储,并由该装置的处理电路12执行。将理解,任何这种计算机程序指令可以被加载到计算机或其他可编程装置(例如,硬件)上以产生机器,从而使得所得到的计算机或其他可编程装置实现在流程图框中指定的功能。这些计算机程序指令还可以被存储在计算机可读存储器中,其可以引导计算机或其他可编程装置以特定方式工作,从而使得被存储在计算机可读存储器中的指令产生制造品,而其执行实现了在流程图框中指定的功能。这些计算机程序指令还可以被加载到计算机或其他可编程装置上,以导致在计算机或其他可编程装置上执行一系列操作以产生计算机实现的过程,从而使得在计算机或其他可编程装置上执行的指令提供用于实现在流程图框中指定的功能的操作。
因此,在这些实例中定义了一种计算机程序产品,其中,计算机程序指令(诸如计算机可读程序代码部分)由至少一个非暂时性计算机可读存储介质存储,其中计算机程序指令(诸如计算机可读程序代码部分)被配置为在执行时执行本文所描述(诸如结合图4-7的流程图)的功能。在其他实施例中,计算机程序指令(诸如计算机可读程序代码部分)不需要由非暂时性计算机可读存储介质存储或以其他方式由非暂时性计算机可读存储介质来体现,而是可以由具有计算机程序指令(诸如计算机可读程序代码部分)的暂时性介质来体现,该计算机程序指令仍被配置为在执行时执行本文所描述的功能。
因此,流程图框支持用于执行指定功能的部件的组合,以及用于执行指定功能的操作的组合。还将理解,流程图的一个或多个框以及流程图中的框的组合可以由执行指定功能的基于专用硬件的计算机系统、或专用硬件和计算机指令的组合来实现。
在一些实施例中,如本文所描述的任何或所有术语、变量、值、构造、框架等可以被设置为此过程的输出。
在一些实施例中,可以修改或进一步扩增本文中的某些操作。此外,在一些实施例中,可以包括附加的可选操作,诸如由图4-7中的虚线框所表示的那些操作。对本文中的操作的修改、添加或扩增可以采用任何顺序和任何组合来执行。
受益于前述描述和相关联的附图中呈现的教导的本领域技术人员将会想到本文阐述的本发明的许多修改和其他实施例。因此,应当理解,本发明不限于所公开的具体实施例,并且那些修改和其他实施例旨在被包括在所附权利要求的范围内。此外,虽然前述描述和相关联的附图在元件和/或功能的某些示例性组合的上下文中描述了示例性实施例,但是应当理解,可以由替代实施例来提供元件和/或功能的不同组合,而不背离所附权利要求的范围。就此而言,例如,如可在一些所附权利要求中所阐述的,还可以构想与在本文明确描述的元件和/或功能的不同组合。虽然在本文中使用了特定术语,但是它们仅在一般和描述性意义上被使用,而不是出于限制的目的。

Claims (36)

1.一种方法,包括:
访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为一个或多个媒体轨道;
形成轨道级子样本描述框,所述轨道级子样本描述框包括用于相应的多个子样本的多个子样本条目类型;以及
通过在所述轨道级子样本描述框的编解码器特定参数相关的字段中包括相应的点云单元报头信息,指示一个或多个类型的点云压缩编码比特流分量。
2.根据权利要求1所述的方法,进一步包括:
扩展子样本信息框,以通过以下操作来指示子样本条目索引:在相关的子样本描述框中指示子样本条目的呈现顺序,并使用版本值或者通过在所述子样本信息框中设置标志来指示在所述子样本信息框中存在所述子样本条目索引。
3.根据权利要求1或2所述的方法,其中,存储所述点云压缩编码比特流包括:
访问属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流;
检测所述属性信息比特流、所述几何形状信息比特流、所述占用信息比特流和所述补片信息比特流遵循兼容的编码和定时结构;以及
至少基于所述兼容的编码和定时结构来构建并存储视频媒体轨道。
4.根据权利要求1-3中任一项所述的方法,其中,所述至少一个媒体轨道具有经由所述子样本信息框或所述子样本条目索引而信令传送的打包类型。
5.根据权利要求1-4中任一项所述的方法,其中,所述点云压缩编码比特流包括至少一个属性信息比特流、至少一个几何形状信息比特流、至少一个占用信息比特流、以及至少一个补片信息比特流。
6.根据权利要求5所述的方法,进一步包括:
访问所述属性信息比特流、所述几何形状信息比特流、所述占用信息比特流和所述补片信息比特流;
将所述属性信息码流存储在属性视频媒体轨道中;
将所述几何形状信息比特流存储在几何形状视频媒体轨道中;
将所述占用信息比特流存储在占用视频媒体轨道中;
将所述补片信息比特流存储在另一个编码媒体或元数据轨道中;以及
在文件中构建并存储元数据,所述元数据指示所述属性视频媒体轨道、所述几何形状视频媒体轨道、所述占用视频媒体轨道和所述单独的编码媒体或元数据轨道的一个或多个分量的模式。
7.根据权利要求6所述的方法,其中,所述元数据是交错指示符元数据,其指示所述属性视频媒体轨道、所述几何形状视频媒体轨道、所述占用视频媒体轨道和所述单独的编码媒体或元数据轨道的所述一个或多个分量的交错模式。
8.根据权利要求6所述的方法,其中,针对其指示所述模式的所述一个或多个分量中的每一个能够使用所述子样本信息框访问,所述子样本信息框定义所述呈现顺序和用于所述一个或多个分量的配置信息,所述子样本信息框被配置为指示所述模式。
9.根据权利要求6所述的方法,其中,存储包括:以国际标准化组织基础媒体文件格式(ISOBMFF)存储不同的基于视频的点云压缩结构。
10.一种装置,包括:
用于访问点云压缩编码比特流的部件,其中,所述点云压缩编码比特流被配置以被存储为一个或多个媒体轨道;
用于形成轨道级子样本描述框的部件,其中,所述轨道级子样本描述框包括用于相应的多个子样本的多个子样本条目类型;以及
用于通过在所述轨道级子样本描述框的编解码器特定参数相关的字段中包括相应的点云单元报头信息来指示一个或多个类型的点云压缩编码比特流分量的部件。
11.根据权利要求10所述的装置,进一步包括:
用于扩展子样本信息框以通过以下操作来指示子样本条目索引的部件:在相关的子样本描述框中指示子样本条目的呈现顺序,并使用版本值或者通过在所述子样本信息框中设置标志来指示在所述子样本信息框中存在所述子样本条目索引。
12.根据权利要求10或11所述的装置,进一步包括:
用于访问属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流的部件;
用于检测所述属性信息比特流、所述几何形状信息比特流、所述占用信息比特流和所述补片信息比特流遵循兼容的编码和定时结构的部件;以及
用于至少基于所述兼容的编码和定时结构来构建并存储视频媒体轨道的部件。
13.根据权利要求10-12中任一项所述的装置,其中,所述至少一个媒体轨道具有经由所述子样本信息框或所述子样本条目索引而信令传送的打包类型。
14.根据权利要求10-13中任一项所述的装置,其中,所述点云压缩编码比特流包括至少一个属性信息比特流、至少一个几何形状信息比特流、至少一个占用信息比特流、以及至少一个补片信息比特流。
15.根据权利要求10-14中任一项所述的装置,进一步包括:
用于访问所述属性信息比特流、所述几何形状信息比特流、所述占用信息比特流和所述补片信息比特流的部件;
用于将所述属性信息码流存储在属性视频媒体轨道中的部件;
用于将所述几何形状信息比特流存储在几何形状视频媒体轨道中的部件;
用于将所述占用信息比特流存储在占用视频媒体轨道中的部件;
用于将所述补片信息比特流存储在另一个编码媒体或元数据轨道中的部件;以及
用于在文件中构建并存储元数据的部件,其中,所述元数据指示所述属性视频媒体轨道、所述几何形状视频媒体轨道、所述占用视频媒体轨道和所述单独的编码媒体或元数据轨道的一个或多个分量的模式。
16.根据权利要求15所述的装置,其中,所述元数据是交错指示符元数据,其指示所述属性视频媒体轨道、所述几何形状视频媒体轨道、所述占用视频媒体轨道和所述单独的编码媒体或元数据轨道的所述一个或多个分量的交错模式。
17.根据权利要求15所述的装置,其中,针对其指示所述模式的所述一个或多个分量中的每一个能够使用所述子样本信息框访问,所述子样本信息框定义所述呈现顺序和用于所述一个或多个分量的配置信息,所述子样本信息框被配置为指示所述模式。
18.根据权利要求15所述的装置,其中,存储包括:以国际标准化组织基础媒体文件格式(ISOBMFF)存储不同的基于视频的点云压缩结构。
19.一种计算机程序产品,包括其中存储有计算机可执行程序代码指令的至少一个非暂时性计算机可读存储介质,所述计算机可执行程序代码指令包括被配置为在执行时执行以下操作的程序代码指令:
访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为一个或多个媒体轨道;
形成轨道级子样本描述框,所述轨道级子样本描述框包括用于相应的多个子样本的多个子样本条目类型;以及
通过在所述轨道级子样本描述框的编解码器特定参数相关的字段中包括相应的点云单元报头信息,指示一个或多个类型的点云压缩编码比特流分量。
20.根据权利要求19所述的计算机程序产品,其中,所述程序代码指令进一步被配置为在执行时:
扩展子样本信息框,以通过以下操作来指示子样本条目索引:在相关的子样本描述框中指示子样本条目的呈现顺序,并使用版本值或者通过在所述子样本信息框中设置标志来指示在所述子样本信息框中存在所述子样本条目索引。
21.根据权利要求19或20所述的计算机程序产品,其中,所述计算机可执行程序代码指令进一步包括被配置为在执行时执行以下操作的程序代码指令:
访问属性信息比特流、几何形状信息比特流、占用信息比特流和补片信息比特流;
检测所述属性信息比特流、所述几何形状信息比特流、所述占用信息比特流和所述补片信息比特流遵循兼容的编码和定时结构;以及
至少基于所述兼容的编码和定时结构来构建并存储视频媒体轨道。
22.根据权利要求19-21中任一项所述的计算机程序产品,其中,所述至少一个媒体轨道具有经由所述子样本条目索引而信令传送的打包类型。
23.根据权利要求19-22中任一项所述的计算机程序产品,其中,所述点云压缩编码比特流包括至少一个属性信息比特流、至少一个几何形状信息比特流、至少一个占用信息比特流、以及至少一个补片信息比特流补片。
24.根据权利要求23所述的计算机程序产品,其中,所述计算机可执行程序代码指令进一步包括被配置为在执行时执行以下操作的程序代码指令:
访问所述属性信息比特流、所述几何形状信息比特流、所述占用信息比特流和所述补片信息比特流;
将所述属性信息码流存储在属性视频媒体轨道中;
将所述几何形状信息比特流存储在几何形状视频媒体轨道中;
将所述占用信息比特流存储在占用视频媒体轨道中;
将所述补片信息比特流存储在另一个编码媒体或元数据轨道中;以及
在文件中构建并存储元数据,所述元数据指示所述属性视频媒体轨道、所述几何形状视频媒体轨道、所述占用视频媒体轨道和所述单独的编码媒体或元数据轨道的一个或多个分量的模式。
25.根据权利要求24所述的计算机程序产品,其中,所述元数据是交错指示符元数据,其指示所述属性视频媒体轨道、所述几何形状视频媒体轨道、所述占用视频媒体轨道和所述单独的编码媒体或元数据轨道的所述一个或多个分量的交错模式。
26.根据权利要求24所述的计算机程序产品,其中,针对其指示所述模式的所述一个或多个分量中的每一个能够使用所述子样本信息框访问,所述子样本信息框定义所述呈现顺序和用于所述一个或多个分量的配置信息,所述子样本信息框被配置为指示所述模式。
27.根据权利要求24所述的计算机程序产品,其中,存储包括:以国际标准化组织基础媒体文件格式(ISOBMFF)存储不同的基于视频的点云压缩结构。
28.一种方法,包括:
访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为一个或多个媒体轨道;
定义多个子样本描述索引框,所述子样本描述索引框包括子样本描述条目索引,所述子样本描述索引框被存储在和与所述多个子样本描述索引框相关联的相应的多个子样本信息框相同的容器中;以及
向所述多个子样本描述索引框的相应的子样本描述索引框和所述多个子样本信息框的相应的子样本信息框添加唯一标识符,所述唯一标识符可操作以标识与第一子样本信息框相关联的第一子样本描述索引框。
29.一种装置,包括:
用于访问点云压缩编码比特流的部件,其中,所述点云压缩编码比特流被配置以被存储为一个或多个媒体轨道;
用于定义多个子样本描述索引框的部件,其中,所述子样本描述索引框包括子样本描述条目索引,所述子样本描述索引框被存储在和与所述多个子样本描述索引框相关联的相应的多个子样本信息框相同的容器中;以及
用于向所述多个子样本描述索引框的相应的子样本描述索引框和所述多个子样本信息框的相应的子样本信息框添加唯一标识符的部件,其中,所述唯一标识符可操作以标识与第一子样本信息框相关联的第一子样本描述索引框。
30.一种计算机程序产品,包括其中存储有计算机可执行程序代码指令的至少一个非暂时性计算机可读存储介质,所述计算机可执行程序代码指令包括被配置为在执行时执行以下操作的程序代码指令:
访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为一个或多个媒体轨道;
定义多个子样本描述索引框,所述子样本描述索引框包括子样本描述条目索引,所述子样本描述索引框被存储在和与所述多个子样本描述索引框相关联的相应的多个子样本信息框相同的容器中;以及
向所述多个子样本描述索引框的相应的子样本描述索引框和所述多个子样本信息框的相应的子样本信息框添加唯一标识符,所述唯一标识符可操作以标识与第一子样本信息框相关联的第一子样本描述索引框。
31.一种方法,包括:
访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为与电影片段的样本相关联的一个或多个媒体轨道;
定义多个子样本描述索引框,所述子样本描述索引框包括子样本描述条目索引,所述子样本描述索引框被存储在和与所述多个子样本描述索引框相关联的相应的多个子样本信息框相同的容器中;以及
扩展轨道片段报头框以包括应用于所述电影片段的所述样本的一组所述子样本描述条目索引。
32.一种装置,包括:
用于访问点云压缩编码比特流的部件,其中,所述点云压缩编码比特流被配置以被存储为与电影片段的样本相关联的一个或多个媒体轨道;
用于定义多个子样本描述索引框的部件,其中,所述子样本描述索引框包括子样本描述条目索引,所述子样本描述索引框被存储在和与所述多个子样本描述索引框相关联的相应的多个子样本信息框相同的容器中;以及
用于扩展轨道片段报头框以包括应用于所述电影片段的所述样本的一组所述子样本描述条目索引的部件。
33.一种计算机程序产品,包括其中存储有计算机可执行程序代码指令的至少一个非暂时性计算机可读存储介质,所述计算机可执行程序代码指令包括被配置为在执行时执行以下操作的程序代码指令:
访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为与电影片段的样本相关联的一个或多个媒体轨道;
定义多个子样本描述索引框,所述子样本描述索引框包括子样本描述条目索引,所述子样本描述索引框被存储在和与所述多个子样本描述索引框相关联的相应的多个子样本信息框相同的容器中;以及
扩展轨道片段报头框以包括应用于所述电影片段的所述样本的一组所述子样本描述条目索引。
34.一种方法,包括:
访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为与电影片段的样本相关联的一个或多个媒体轨道;以及
对所述一个或多个媒体轨道的样本描述框内的多个样本实体进行索引。
35.一种装置,包括:
用于访问点云压缩编码比特流的部件,其中,所述点云压缩编码比特流被配置以被存储为与电影片段的样本相关联的一个或多个媒体轨道;以及
用于对所述一个或多个媒体轨道的样本描述框内的多个样本实体进行索引的部件。
36.一种计算机程序产品,包括其中存储有计算机可执行程序代码指令的至少一个非暂时性计算机可读存储介质,所述计算机可执行程序代码指令包括被配置为在执行时执行以下操作的程序代码指令:
访问点云压缩编码比特流,所述点云压缩编码比特流被配置以被存储为与电影片段的样本相关联的一个或多个媒体轨道;以及
对所述一个或多个媒体轨道的样本描述框内的多个样本实体进行索引。
CN202080083325.4A 2019-10-02 2020-10-02 用于存储和信令传送子样本条目描述的方法和装置 Pending CN114747219A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201962909259P 2019-10-02 2019-10-02
US62/909,259 2019-10-02
PCT/FI2020/050648 WO2021064293A1 (en) 2019-10-02 2020-10-02 Method and apparatus for storage and signaling of sub-sample entry descriptions

Publications (1)

Publication Number Publication Date
CN114747219A true CN114747219A (zh) 2022-07-12

Family

ID=75273675

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202080083325.4A Pending CN114747219A (zh) 2019-10-02 2020-10-02 用于存储和信令传送子样本条目描述的方法和装置

Country Status (4)

Country Link
US (1) US11595670B2 (zh)
EP (1) EP4038885A4 (zh)
CN (1) CN114747219A (zh)
WO (1) WO2021064293A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115834857A (zh) * 2022-11-24 2023-03-21 腾讯科技(深圳)有限公司 点云数据处理方法、装置、设备及存储介质
WO2024148751A1 (zh) * 2023-01-10 2024-07-18 海信视像科技股份有限公司 场景描述文件的生成方法及装置

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102519653B1 (ko) * 2018-01-20 2023-04-07 삼성전자주식회사 포인트 클라우드 압축 방법 및 장치
WO2020032136A1 (ja) * 2018-08-08 2020-02-13 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 三次元データ符号化方法、三次元データ復号方法、三次元データ符号化装置、及び三次元データ復号装置
JPWO2021065605A1 (zh) * 2019-10-01 2021-04-08
US11399188B2 (en) * 2020-01-01 2022-07-26 Tencent America LLC Method for mixed NAL unit type support in a coded picture
US11716474B2 (en) * 2020-01-02 2023-08-01 Samsung Electronics Co., Ltd. Storage of EVC decoder configuration information
KR102447796B1 (ko) * 2020-11-27 2022-09-27 한국전자기술연구원 V-pcc 부호화기를 위한 패치 세그먼트 고속 정제 장치 및 그 방법
GB2605965A (en) * 2021-04-16 2022-10-26 Canon Kk Methods and devices for improving storage and transmission of uncompressed data while using a standard format
WO2023144439A1 (en) * 2022-01-27 2023-08-03 Nokia Technologies Oy A method, an apparatus and a computer program product for video coding
GB2617359A (en) * 2022-04-05 2023-10-11 Canon Kk Method and apparatus for describing subsamples in a media file
GB2623523A (en) * 2022-10-17 2024-04-24 Canon Kk Method and apparatus describing subsamples in a media file
WO2023194179A1 (en) * 2022-04-05 2023-10-12 Canon Kabushiki Kaisha Method and apparatus for describing subsamples in a media file
GB2620585A (en) * 2022-07-11 2024-01-17 Canon Kk Method and apparatus for encapsulating media data in a media file
CN116744007A (zh) * 2022-04-22 2023-09-12 腾讯科技(深圳)有限公司 点云媒体的编解码方法及相关产品
CN114697631B (zh) * 2022-04-26 2023-03-21 腾讯科技(深圳)有限公司 沉浸媒体的处理方法、装置、设备及存储介质
GB2629152A (en) * 2023-04-17 2024-10-23 Canon Kk Method, device, and computer program for improving random access in point cloud data bit-stream

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040167925A1 (en) * 2003-02-21 2004-08-26 Visharam Mohammed Zubair Method and apparatus for supporting advanced coding formats in media files
CN106664446A (zh) * 2014-07-01 2017-05-10 佳能株式会社 用于封装hevc分层媒体数据的方法、设备和计算机程序
US20170347122A1 (en) * 2016-05-28 2017-11-30 Microsoft Technology Licensing, Llc Scalable point cloud compression with transform, and corresponding decompression
US20190080483A1 (en) * 2017-09-14 2019-03-14 Apple Inc. Point Cloud Compression
WO2019072795A1 (en) * 2017-10-12 2019-04-18 Canon Kabushiki Kaisha METHOD, DEVICE, AND COMPUTER PROGRAM FOR GENERATING TIMED PARTITIONED MULTIMEDIA DATA
WO2019135024A1 (en) * 2018-01-02 2019-07-11 Nokia Technologies Oy An apparatus, a method and a computer program for volumetric video
WO2019143486A1 (en) * 2018-01-19 2019-07-25 Interdigital Vc Holdings, Inc. A method and apparatus for encoding and decoding three-dimensional scenes in and from a data stream

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7613727B2 (en) * 2002-02-25 2009-11-03 Sont Corporation Method and apparatus for supporting advanced coding formats in media files
KR20040106414A (ko) 2002-04-29 2004-12-17 소니 일렉트로닉스 인코포레이티드 미디어 파일에서 진보된 코딩 포맷의 지원
US10897269B2 (en) * 2017-09-14 2021-01-19 Apple Inc. Hierarchical point cloud compression

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040167925A1 (en) * 2003-02-21 2004-08-26 Visharam Mohammed Zubair Method and apparatus for supporting advanced coding formats in media files
CN106664446A (zh) * 2014-07-01 2017-05-10 佳能株式会社 用于封装hevc分层媒体数据的方法、设备和计算机程序
US20170347122A1 (en) * 2016-05-28 2017-11-30 Microsoft Technology Licensing, Llc Scalable point cloud compression with transform, and corresponding decompression
US20190080483A1 (en) * 2017-09-14 2019-03-14 Apple Inc. Point Cloud Compression
WO2019072795A1 (en) * 2017-10-12 2019-04-18 Canon Kabushiki Kaisha METHOD, DEVICE, AND COMPUTER PROGRAM FOR GENERATING TIMED PARTITIONED MULTIMEDIA DATA
WO2019135024A1 (en) * 2018-01-02 2019-07-11 Nokia Technologies Oy An apparatus, a method and a computer program for volumetric video
WO2019143486A1 (en) * 2018-01-19 2019-07-25 Interdigital Vc Holdings, Inc. A method and apparatus for encoding and decoding three-dimensional scenes in and from a data stream

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
GOTHENBURG: "Text of ISO/IEC CD 23090-10 Carriage of PC Data", 《JOINT VIDEO EXPERTS TEAM (JVET) 》, 21 September 2019 (2019-09-21) *
曹成坤;张琮毅;汪国平;: "精度可控的字典全局相似性点云压缩", 计算机辅助设计与图形学学报, no. 06, 15 June 2019 (2019-06-15) *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115834857A (zh) * 2022-11-24 2023-03-21 腾讯科技(深圳)有限公司 点云数据处理方法、装置、设备及存储介质
CN115834857B (zh) * 2022-11-24 2024-03-19 腾讯科技(深圳)有限公司 点云数据处理方法、装置、设备及存储介质
WO2024148751A1 (zh) * 2023-01-10 2024-07-18 海信视像科技股份有限公司 场景描述文件的生成方法及装置

Also Published As

Publication number Publication date
EP4038885A1 (en) 2022-08-10
EP4038885A4 (en) 2023-07-19
US11595670B2 (en) 2023-02-28
WO2021064293A1 (en) 2021-04-08
US20210105492A1 (en) 2021-04-08

Similar Documents

Publication Publication Date Title
CN112019857B (zh) 用于压缩点云的存储和信号发送的方法和装置
US11595670B2 (en) Method and apparatus for storage and signaling of sub-sample entry descriptions
US11128898B2 (en) Method, device, and computer program for encapsulating scalable partitioned timed media data
EP3821608A1 (en) Method and apparatus for storage and signaling of compressed point clouds
KR102406887B1 (ko) 시간 설정형 미디어 데이터를 발생시키는 방법, 디바이스, 및 컴퓨터 프로그램
WO2020070379A1 (en) Method and apparatus for storage and signaling of compressed point clouds
CN109155875B (zh) 用于对定时媒体数据进行封装和解析的方法、装置和计算机程序
CN110800311B (zh) 用于传输媒体内容的方法、装置和计算机程序
US11638066B2 (en) Method, device and computer program for encapsulating media data into a media file
KR102655630B1 (ko) 3차원 비디오 컨텐츠를 포함하는 미디어 파일을 생성하는 방법 및 장치 및 3차원 비디오 컨텐츠를 재생하는 방법 및 장치
WO2020002122A1 (en) Method, device, and computer program for transmitting media content
KR20210016530A (ko) 미디어 콘텐츠 전송을 위한 방법, 디바이스, 및 컴퓨터 프로그램

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