[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

CN113170238B - 用于视频编码和解码的装置、方法和计算机程序 - Google Patents

用于视频编码和解码的装置、方法和计算机程序 Download PDF

Info

Publication number
CN113170238B
CN113170238B CN201980074367.9A CN201980074367A CN113170238B CN 113170238 B CN113170238 B CN 113170238B CN 201980074367 A CN201980074367 A CN 201980074367A CN 113170238 B CN113170238 B CN 113170238B
Authority
CN
China
Prior art keywords
track
slice segment
picture
sample
tracks
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.)
Active
Application number
CN201980074367.9A
Other languages
English (en)
Other versions
CN113170238A (zh
Inventor
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 CN113170238A publication Critical patent/CN113170238A/zh
Application granted granted Critical
Publication of CN113170238B publication Critical patent/CN113170238B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/70Media network packetisation
    • 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
    • H04N21/85406Content authoring involving a specific file format, e.g. MP4 format
    • 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/167Position within a video image, e.g. region of interest [ROI]
    • 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/17Methods 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 an image region, e.g. an object
    • H04N19/174Methods 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 an image region, e.g. an object the region being a slice, e.g. a line of blocks or a group of blocks
    • 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/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/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81Monomedia components thereof
    • H04N21/816Monomedia components thereof involving special video data, e.g 3D video
    • 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/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106Processing image signals
    • H04N13/172Processing image signals image signals comprising non-image signal components, e.g. headers or format information
    • H04N13/178Metadata, e.g. disparity information

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Abstract

一种方法包括:在容器文件中写入包括切片分段报头的第一部分的至少一个第一条目;在容器文件中指示针对样本应用了至少一个第一条目中的哪个条目;以及在没有切片分段报头的第一部分的情况下制作样本。

Description

用于视频编码和解码的装置、方法和计算机程序
技术领域
本发明涉及用于视频编码和解码的装置、方法和计算机程序。
背景技术
最近,各种多媒体流应用、尤其是360度视频或虚拟现实(VR)应用的开发取得了长足的进步。在视口自适应流传输中,旨在降低比特率,例如使得主视口(即,当前观看取向(orientation))将以最佳质量/分辨率被传输,而其余360度视频以较低质量/分辨率被传输。当观看取向改变时,例如,当用户在利用头戴式显示器(HMD)观看内容时转动头时,需要流传输内容的另一版本,以匹配新观看取向。
有几种备选方案来传递视口相关全向视频。例如,可以将其作为具有运动约束图块集(motion-constrained tile sets,MCTS)的等分辨率高效视频编码(HEVC)比特流进行传递。因此,使用运动受限图块集以相同分辨率但不同质量和比特率对相同全向源内容的若干HEVC比特流进行编码。
360°视频的基于图块的视口相关传递涉及大量图块或子图片轨道(track),每个轨道包含独立切片分段的切片分段报头。例如,可以以立方图投影(cube map projection)格式使用产生为96个图块或子图片轨道的96个图块。类似地,期望为了实现适应观看位置和/或观看定位的点云或体积视频流,将使用大量图块或子图片轨道,每个轨道包含一组补丁。
独立切片分段报头的长度有所不同,但通常至少为4个字节。图块轨道的切片分段报头可能更大。因此,由切片分段报头引起的开销比特率很大。
发明内容
现在,为了至少减轻上述问题,本文中介绍一种增强的编码方法。
根据第一方面的一种方法包括:在容器文件中写入包括切片分段报头的第一部分的至少一个第一条目;在容器文件中指示针对样本应用了至少一个第一条目中的哪个条目;以及在没有切片分段报头的第一部分的情况下制作(author)样本。
根据第二方面的一种装置包括:用于在容器文件中写入包括切片分段报头的第一部分的至少一个第一条目的部件;用于在容器文件中指示针对样本应用了至少一个第一条目中的哪个条目的部件;以及在没有切片分段报头的第一部分的情况下制作样本的部件。
根据一个实施例,该装置还包括用于在容器文件中写入包括切片分段报头的第二部分的集合的至少一个第二条目的部件,其中第二部分包括与第一部分不同的语法元素;用于在容器文件中指示针对样本应用了至少一个第二条目中的哪个条目的部件;以及用于在没有切片分段报头的第二部分的集合的情况下制作样本的部件。
根据一个实施例,该装置还包括:用于在容器文件中写入具有样本的切片分段数据轨道的部件,该切片分段数据轨道包括切片分段数据而没有切片分段报头;用于在没有切片分段数据的情况下制作样本的部件;以及用于在容器文件中指示针对样本的切片分段数据驻留在切片分段数据轨道中的部件。
根据一个实施例,关于样本的切片分段数据驻留在切片分段数据轨道中的指示包括以下之一:
-对切片分段数据轨道的特定类型的轨道参考
-对包括切片分段数据轨道的轨道组的特定类型的轨道参考。
根据一个实施例,切片分段数据轨道的样本结构包括一个或多个切片分段NAL单元状结构,该结构包括以下中的一项或多项:
-对第一条目列表中的条目和/或第二条目列表中的条目的隐式
参考
-对切片分段数据轨道中的相关联的样本的隐式参考。
根据一个实施例,至少一个第一条目和/或至少一个第二条目包括以下结构之一:
-样本组描述框
-MovieBox和/或(多个)MovieFragmentBox中包含的框
-样本到组框
-SampleTableBox和/或(多个)TrackFragmentBox中包含的框。
根据一个实施例,该装置还包括用于将独立切片分段的每个序列封装为被指示为属于同一轨道组的图块轨道的部件;以及用于创建图块基本轨道(tile base track)的部件,其中图块基本轨道的每个样本包括一个或多个编码图片,该个或多个编码图片包括或被推断为包括N个独立切片分段,其中N在图块基本轨道之间可以不同,并且其中图块基本轨道包括关于轨道组应用于每个切片分段的指示。
根据第三方面的一种方法包括:从容器文件中解析包括切片分段报头的第一部分的至少一个第一条目;从容器文件中解析针对样本应用了至少一个第一条目中的哪个条目;以及根据第一至少一个条目中的所应用的条目和切片分段数据来重构样本的切片分段。
根据第四方面的一种装置包括:用于从容器文件中解析包括切片分段报头的第一部分的至少一个第一条目的部件;用于从容器文件中解析针对样本应用了至少一个第一条目中哪个条目的部件;以及用于根据第一至少一个条目中的所应用的条目和切片分段数据来重构样本的切片分段的部件。
根据一个实施例,该装置还包括用于从容器文件中解析包括切片分段报头的第二部分的集合的至少一个第二条目的部件,其中第二部分包括与第一部分不同的语法元素;用于从容器文件中解析针对样本应用了至少一个第二条目中哪个条目的部件;以及用于根据至少一个第二条目中的所应用的条目来重构切片分段的部件。
根据一个实施例,该装置还包括:用于从容器文件中解析针对样本的切片分段数据驻留在具有样本的切片分段数据轨道中的指示的部件,切片分段数据轨道包括切片分段数据而没有切片分段报头;用于从容器文件中读取切片分段数据轨道的时间对准样本的部件;以及用于基于时间对准样本中承载的切片分段数据来重构切片分段的部件。
根据一个实施例,该装置还包括:用于从容器文件中解析具有合适的解码能力要求的图块基本轨道的部件;用于推断切片分段数据轨道包含的独立切片分段的数目的部件;参考从轨道组中选择至少覆盖视口的一个或多个图块轨道的部件;以及用于根据原始字节序列有效载荷(RBSP)的重构过程来重构编码图片的部件。
另外的方面涉及其上存储有代码的装置和计算机可读存储介质,该代码被布置为执行以上方法和与之有关的一个或多个实施例。
附图说明
为了更好地理解本发明,现在将通过示例的方式参考附图,在附图中:
图1示意性地示出了采用本发明的实施例的电子设备;
图2示意性地示出了适合于采用本发明的实施例的用户设备;
图3进一步示意性地示出了使用无线和有线网络连接而连接的采用本发明的实施例的电子设备;
图4示意性地示出了适合于实现本发明的实施例的编码器;
图5示出了MPEG全向媒体格式(OMAF)概念的示例;
图6a和图6b示出了将360度视频内容打包成2D打包的图片以进行编码的两种备选方法;
图7示出了形成单视场等角全景图片的过程;
图8示出了OMAF坐标系的示例;
图9示出了将球形图片转换为打包的2D图片的示例;
图10示出了多分辨率图块合并的示例方案;
图11示出了根据本发明的实施例的编码/写入方法的流程图;
图12示出了根据本发明的实施例的容器文件中的映射的示例;
图13示出了根据本发明的实施例的容器文件结构的示例;
图14示出了根据本发明的实施例的容器文件结构的另一示例;
图15示出了根据本发明的实施例的解码/解析方法的流程图;
图16示出了根据本发明的实施例的用于后期绑定的容器文件结构的示例;
图17示出了适合于实现本发明的实施例的解码器的示意图;以及
图18示出了可以在其内实现各种实施例的示例多媒体通信系统的示意图。
具体实施方式
下面进一步详细描述用于视口自适应流传输的合适的装置和可能的机制。在这点上,首先参考图1和图2,其中图1示出了根据示例实施例的视频编码系统的框图,作为示例性装置或电子设备50的示意性框图,该示例性装置或电子设备50可以包含有根据本发明的实施例的编解码器。图2示出了根据示例实施例的装置的布局。接下来将说明图1和图2的元素。
电子设备50例如可以是无线通信系统的移动终端或用户设备。然而,应当理解,本发明的实施例可以在可能需要编码和解码或编码或解码视频图像的任何电子设备或装置内实现。
装置50可以包括用于包含和保护设备的壳体30。装置50还可以包括以液晶显示器形式的显示器32。在本发明的其他实施例中,显示器可以是适合于显示图像或视频的任何合适的显示技术。装置50还可以包括小键盘34。在本发明的其他实施例中,可以采用任何合适的数据或用户接口机制。例如,用户接口可以被实现为虚拟键盘或数据输入系统,作为触敏显示器的一部分。
该装置可以包括麦克风36、或可以是数字或模拟信号输入的任何合适的音频输入。装置50还可以包括音频输出设备,在本发明的实施例中,该音频输出设备可以是听筒38、扬声器、或模拟音频或数字音频输出连接中的任何一种。装置50还可以包括电池(或者在本发明的其他实施例中,该设备可以由任何合适的移动能量设备(诸如太阳能电池、燃料电池或发条发电机)供电)。该装置还可以包括能够记录或捕获图像和/或视频的相机。装置50还可以包括用于与其他设备的短距离视线通信的红外端口。在其他实施例中,装置50还可以包括任何合适的短距离通信解决方案,诸如蓝牙无线连接或USB/火线有线连接。
装置50可以包括用于控制装置50的控制器56、处理器或处理器电路系统。控制器56可以连接到存储器58,在本发明的实施例中,存储器58可以存储图像和音频数据形式的数据,和/或还可以存储用于在控制器56上的实现的指令。控制器56还可以连接到编解码器电路系统54,该编解码器电路系统54适合于执行音频和/或视频数据的编码和解码或者辅助由控制器执行的编码和解码。
装置50还可以包括读卡器48和智能卡46,例如用于提供用户信息并且适合于提供用于网络处用户的认证和授权的认证信息的UICC和UICC读卡器。
装置50可以包括无线接口电路系统52,该无线接口电路系统52连接到控制器并且适合于生成例如用于与蜂窝通信网络、无线通信系统或无线局域网进行通信的无线通信信号。装置50还可以包括连接到无线电接口电路系统52的天线44,该天线44用于将在无线电接口电路系统52处生成的射频信号传输给(多个)其他装置并且从(多个)其他装置接收射频信号。
装置50可以包括能够记录或检测个体帧的相机,这些帧然后被传递给编解码器54或控制器以进行处理。该装置可以在传输和/或存储之前从另一设备接收视频图像数据以进行处理。装置50还可以无线地或通过有线连接来接收图像以进行编码/解码。上述装置50的结构元件表示用于执行对应功能的部件的示例。
关于图3,示出了可以在其中利用本发明的实施例的系统的示例。系统10包括可以通过一个或多个网络进行通信的多个通信设备。系统10可以包括有线或无线网络的任何组合,包括但不限于无线蜂窝电话网络(诸如GSM、UMTS、CDMA网络等)、无线局域网(WLAN)(诸如由IEEE 802.x标准中的任何一个定义)、蓝牙个域网、以太网局域网、令牌环局域网、广域网和互联网。
系统10可以包括适合于实现本发明的实施例的有线和无线通信设备和/或装置50。
例如,图3所示的系统示出了移动电话网络11、和互联网28的表示。与互联网28的连接可以包括但不限于长距离无线连接、短距离无线连接、和各种有线连接,包括但不限于电话线、电缆线、电源线和类似的通信路径。
系统10中所示的示例通信设备可以包括但不限于电子设备或装置50、个人数字助理(PDA)和移动电话14的组合、PDA 16、集成的消息传递设备(IMD)18、台式计算机20、笔记本计算机22。当由移动的个人携带时,装置50可以是静止的或移动的。装置50还可以位于运输工具中,包括但不限于汽车、卡车、出租车、公共汽车、火车、轮船、飞机、自行车、摩托车或任何类似的合适的运输工具。
实施例也可以在以下各项中实现:可以具有/可以不具有显示器或无线能力的机顶盒(即,数字电视接收器);具有硬件或软件或编码器/解码器实现的组合的平板电脑或(笔记本)个人计算机(PC);各种操作系统;以及提供基于硬件/软件的编码的芯片组、处理器、DSP和/或嵌入式系统。
一些或其他装置可以发送和接收呼叫和消息,并且通过到基站24的无线连接25与服务提供商通信。基站24可以连接到网络服务器26,该网络服务器26允许移动电话网络11与互联网28之间的通信。该系统可以包括附加的通信设备和各种类型的通信设备。
通信设备可以使用各种传输技术进行通信,包括但不限于码分多址(CDMA)、全球移动通信系统(GSM)、通用移动电信系统(UMTS)、时分多址(TDMA)、频分多址(FDMA)、传输控制协议互联网协议(TCP-IP)、短消息服务(SMS)、多媒体消息服务(MMS)、电子邮件、即时消息服务(IMS)、蓝牙、IEEE 802.11和任何类似无线通信技术。本发明的各种实施例的实现所涉及的通信设备可以使用各种介质进行通信,包括但不限于无线电、红外、激光、电缆连接以及任何合适的连接。
在电信和数据网络中,信道可以指代物理信道或逻辑信道。物理信道可以指代诸如导线等物理传输介质,而逻辑信道可以指代能够传送若干逻辑信道的复用介质上的逻辑连接。信道可以用于从一个或若干发送器(或传输器)向一个或若干接收器传送信息信号,例如比特流。
在ISO/IEC 13818-1中或等效地在ITU-T建议H.222.0中规定的MPEG-2传输流(TS)是一种用于在多路复用流中承载音频、视频和其他媒体以及程序元数据或其他元数据的格式。分组标识符(PID)用于标识TS内的基本流(也称为打包的基本流)。因此,MPEG-2TS内的逻辑信道可以被认为对应于特定PID值。
可用媒体文件格式标准包括ISO基本媒体文件格式(ISO/IEC 14496-12,其可以缩写为ISOBMFF)和NAL单元结构化视频的文件格式(ISO/IEC 14496-15),该格式源自ISOBMFF。
下面将ISOBMFF的一些概念、结构和规范描述为容器文件格式的示例,基于此可以实施实施例。本发明的各方面不限于ISOBMFF,而是针对一种可能基础给出了描述,在此基础上可以部分或完全实现本发明。
ISO基本媒体文件格式的基本构造块称为框。每个框具有报头和有效载荷。框报头以字节为单位指示框的类型和框的大小。框可以将其他框包围起来(enclose),并且ISO文件格式指定在某种类型的框内允许哪些框类型。此外,每个文件中某些框的出现可以是强制性的,而其他框的存在可以是可选的。此外,对于某些类型的框,可以允许文件中存在一个以上的框。因此,可以考虑使用ISO基本媒体文件格式来指定框的层次结构。
根据ISO文件格式系列,文件包括封装成框的媒体数据和元数据。每个框由四个字符代码(4CC)标识并且以报头开头,该报头通知框的类型和大小。
在符合ISO基本媒体文件格式的文件中,媒体数据可以在媒体数据'mdat'框中提供,并且影片(movie)'moov'框可以用于包围元数据。在某些情况下,为了使文件可操作,可能需要同时存在'mdat'和'moov'框。影片'moov'框可以包括一个或多个轨道,并且每个轨道可以驻留在一个对应轨道'trak'框中。轨道可以是多种类型之一,包括媒体轨道,该媒体轨道是指根据媒体压缩格式(及其到ISO基本媒体文件格式的封装)而格式化的样本。
可以使用影片片段,例如,在将内容记录到ISO文件时,例如,以便避免在记录应用崩溃、存储器空间不足或发生其他事件的情况下丢失数据。在没有影片片段的情况下,可能会发生数据丢失,因为文件格式可能要求将所有元数据(例如,影片框)写入文件的一个连续区域中。此外,当记录文件时,可能没有足够量的存储器空间(例如,随机存取存储器RAM)来为可用存储的大小缓冲影片框,并且在关闭影片时重新计算影片框的内容可能太慢。此外,影片片段可以使得能够使用常规ISO文件解析器同时记录和播放文件。此外,渐进式下载可能需要较短的初始缓冲持续时间,例如,在使用影片片段时同时接收和播放文件,并且与具有相同媒体内容但被结构化而没有影片片段的文件相比,初始影片框更小。
影片片段特征可以使得能够将原本可能驻留在影片框中的元数据拆分为多片(pieces)。每片可以对应于轨道的特定时间段。换言之,影片片段特征可以使得能够交织文件元数据和媒体数据。因此,影片框的大小可能受到限制,并且可以实现上述使用情况。
在某些示例中,如果影片片段的媒体样本与moov框位于同一文件中,则它们可以驻留在mdat框中。但是,对于影片片段的元数据,可以提供moof框。moof框可以包括先前已经在moov框中的播放时间的一定持续时间的信息。moov框仍然可以自己表示有效影片,但除此之外,它还可以包括mvex框,以指示影片片段将在同一文件中跟随。影片片段可以及时扩展与moov框关联的演示。
在影片片段内可以存在一组轨道片段,每个轨道包括从零到多个的任何位置。轨道片段又可以包括从零到多个轨道运行(runs)的任何位置,每个文档是该轨道的样本的连续运行。在这些结构内,很多字段是可选的并且可以是默认的。可以被包括在moof框中的元数据可以限于可以被包括在moov框中的元数据的子集,并且在某些情况下可以以不同方式编码。有关可以被包括在moof框中的框的详细信息可以从ISO基本媒体文件格式规范中找到。独立影片片段可以定义为包括按照文件顺序连续的moof框和mdat框,并且其中mdat框包含影片片段的样本(moof框为其提供元数据)并且不包含任何其他影片片段的样本(即,任何其他moof框)。
轨道参考机制可以用于将轨道彼此关联。TrackReferenceBox包括(多个)框,每个框提供从包含轨道到一组其他轨道的参考。这些参考通过(多个)包含的框的框类型(即,框的四字符代码)被标记。语法可以指定如下:
track_ID可以被指定为提供被参考轨道的轨道标识符或被参考轨道组的track_group_id值的整数数组。track_IDs[i]的每个值(其中i是track_IDs[]数组的有效索引)是整数,其提供从包含轨道到track_ID等于track_IDs[i]的轨道或到track_group_id等于track_IDs[i]并且TrackGroupTypeBox的标志字段的特定位(例如,最低有效位)等于1的轨道组的参考。当参考track_group_id值时,除非在特定轨道参考类型的语义中另有说明,否则轨道参考分别应用于被参考轨道组的每个轨道。可能不允许出现值0。
轨道分组机制使得能够指示轨道组,其中每个组共享特定特性或者组内的轨道具有特定关系。TrackGroupBox可以被包含在TrackBox中。TrackGroupBox包含从TrackGroupTypeBox中导出(derive)的零个或多个框。特定特性或关系由被包含框的框类型指示。被包含框包括标识符,该标识符可以用于推断属于同一轨道组的轨道。在TrackGroupBox内包含被包含框的相同类型并且在这些被包含框内具有相同标识符值的轨道属于同一轨道组。
ISO基本媒体文件格式包含可以与特定样本相关联的定时元数据的三种机制:样本组、定时元数据轨道和样本辅助信息。所导出的规范可以通过这三种机制中的一种或多种来提供类似功能。
ISO基本媒体文件格式及其导出格式(诸如AVC文件格式和SVC文件格式)的样本分组可以基于分组标准而被定义为轨道中的每个样本作为一个样本组的成员的分配。样本分组中的样本组不限于作为连续样本,还可以包含不相邻样本。由于轨道中的样本可以有一个以上的样本分组,因此每个样本分组可以具有类型字段以指示分组的类型。样本分组可以由两个链接的数据结构表示:(1)SampleToGroupBox(sbgp框)表示样本到样本组的分配;以及(2)SampleGroupDescriptionBox(sgpd框)包含每个样本组的样本组条目,该样本组条目描述该组的属性。基于不同分组条件,可以存在SampleToGroupBox和SampleGroupDescriptionBox的多个实例。这些可以通过用于指示分组类型的类型字段来区分。SampleToGroupBox可以包括例如可以用于指示分组的子类型的grouping_type_parameter字段。
对ISO基本媒体文件格式标准的修订草案解释了紧凑的示例到组映射,如下所示:
框类型:'csgp'
容器:SampleTableBox或TrackFragmentBox
必填:否
数量:零或更多。
紧凑的样本到组框提供了一种更为紧凑的方式来表示从样本到组的映射,尤其是在存在重复图案(pattern)以及特定类型的样本组很少的情况下。
该设计使用级联图案的向量,每个级联图案由映射数组使用一次,该映射数组将样本的运行与该模式的重复相关联。这一点通过下面的示例进行说明。在下面,每个字母表示不同样本组描述索引值(可能为0)。
如果一个轨道具有以下关联,从第一样本开始:
a b c b a b c b a b c x x a b c b a b d b
则这些关联可以由以下各项表示:
当sample_count[i]等于pattern_length[i]时,不重复该图案。
当sample_count[i]大于pattern_length[i]时,第i图案的sample_group_description_index值将被重复使用以映射sample_count[i]值。sample_count[i]不一定是pattern_length[i]的倍数;循环可以在图案的中间终止。
当针对在1到pattern_count(包括性的)的范围内的所有i值的sample_count[i]值的总和小于总样本数时,阅读器应当将没有显式组关联的样本与在SampleDescriptionGroupBox中定义的默认组(如果有)相关联,否则不与任何组相关联。
sample_count[i]值的总数大于由包含的TrackBox或TrackFragmentBox描述的实际样本的总数是一个错误,并且读取器行为将是不确定的。
语法:
语义:
version是整数,其指定该框的版本,当前为0。
grouping_type是整数,其标识样本分组的类型(即,用于构成样本组的标准),并且将其链接到分组类型的值相同的样本组描述表。对于轨道,应当存在grouping_type(和grouping_type_parameter(如果使用))的值相同的'csgp'或'sbgp'的最多一次出现。
grouping_type_parameter是分组的子类型的指示。
index_msb_indicates_fragment_local_description是标志,当该框出现在'trak'框内时,该标志必须为零;但当该框出现在'traf'框内时,该标志可以为0或1。当它为1时,指示每个sample_group_description_index的最高有效位(MSB)不形成索引号的一部分,而是指示要在其中找到组描述的'sgpd'框:如果MSB为0,则索引从'trak'框的'sgpd'框中标识组描述;如果MSB为1,则索引从'traf'框的'sgpd'框中标识组描述。
field_size是整数,其指定sample_group_description_index值数组中的条目的大小(以位为单位);它应当取值为3、7、15或31,分别表示字段大小为4、8、16、32。如果使用字段大小4,则每个字节包含两个值:entry[i]<<4+entry[i+1];如果大小未填充整数字节,则最后的字节用零填充。
pattern_count指示其后的图案数组中的相关联的图案的长度。所包括的sample_count值的总和表示映射样本数。
pattern_length[i]对应于sample_group_description_index[j]值的第二数组内的图案。pattern_length[i]的每个实例应当大于0。
sample_count[i]指定使用第i图案的样本数。sample_count[i]应当大于零,并且sample_count[i]应当大于或等于pattern_length[i]。
sample_group_description_index[j][k]是整数,其给出描述该组中的样本的样本组条目的索引。索引的范围是1到SampleGroupDescriptionBox中的样本组条目数(包括性的),或者取值0以指示该样本不是该类型的任何组的成员。
在说明书和实施例中,当提及样本到组框或SampleToGroupBox时,等效地可以使用紧凑的样本到组框等。
子样本可以被定义为样本的字节的连续范围。关于子样本的信息可以在可以被包含在SampleTableBox和/或TrackFragmentBox中的(多个)SubSampleInformationBox中给出。子样本的特定定义可以针对给定编码系统和/或针对编码系统的给定封装格式(例如,特定样本条目类型),和/或可以使用包含(多个)SubSampleInformationBox的标志字段进一步指定。例如,HEVC的标志字段的值可以指示由SubSampleInformationBox寻址的子样本是NAL单元、解码单元、图块、编码树单元行、切片或编码图片。当同一容器框中存在一个以上的SubSampleInformationBox时,可能需要标志的值在每个SubSampleInformationBoxes中不同。SubSampleInformationBox的语法可以指定如下:
SubSampleInformationBox的语法元素的语义可以指定如下:version是整数,其指定该框的版本。entry_count是整数,其给出下表中的条目数。sample_delta是整数,其指示具有子样本结构的样本。它被编码为期望样本号与在上一条目中指示的样本号之间在解码顺序上的差异。如果当前条目是轨道中的第一条目,则该值指示具有子样本信息的第一样本的样本号,即,该值是样本号与零(0)之间的差异。如果当前条目是轨道片段中具有先前非空轨道片段的第一条目,则该值指示具有子样本信息的第一样本的样本号与先前轨道片段中的最后样本的样本号之间的差异。如果当前条目是没有任何先前轨道片段的轨道片段中的第一条目,则该值指示具有子样本信息的第一样本的样本号,即,该值是样本号与零之间(0)的差异。这指示,描述轨道或轨道片段中的第一样本的第一条目的sample_delta始终为1。subsample_count是整数,其指定当前样本的子样本数。如果没有子样本结构,则该字段取值为0。subsample_size是整数,其以字节为单位指定当前子样本的大小。subsample_priority是整数,其指定每个子样本的降级优先级。subsample_priority的值越高指示子样本对解码质量更重要并且对解码质量影响更大。“disableable”等于0表示当前样本的解码需要子样本,而等于1表示当前样本的解码不需要子样本,但是子样本可以用于增强,例如,子样本包括补充增强信息(SEI)消息。codec_specific_parameters由使用中的编解码器和/或其封装格式(例如,样本条目类型)定义。如果没有这样的定义,则该字段设置为0。
Matroska文件格式能够(但不限于)将视频、音频、图片或字幕轨道中的任何一个存储在一个文件中。Matroska可以用作导出文件格式(诸如WebM)的基础格式。Matroska使用可伸缩二进制元语言(EBML)作为基础。EBML指定了受XML原理启发的二进制和八位字节(字节)对准格式。EBML本身是二进制标记技术的概括描述。Matroska文件包括构成EBML“文档”的元素。元素包含有元素ID、元素大小的描述符和二进制数据本身。元素可以嵌套。Matroska的分段元素是其他顶级(第1级)元素的容器。Matroska文件可以包括(但不限于包括)一个分段。Matroska文件中的多媒体数据按群集(或群集元素)被组织,每个群集通常包含几秒钟的多媒体数据。群集包括BlockGroup元素,而BlockGroup元素又包括块元素。提示元素包括可以辅助随机访问或查找的元数据,并且可以包括用于查找点的文件指针或相应时间戳。
视频编解码器包括将输入视频转换为适合于存储/传输的压缩表示形式的编码器和可以将压缩视频表示形式解压缩回可见形式的解码器。视频编码器和/或视频解码器也可以彼此分离,即,不需要形成编解码器。通常,编码器会丢弃原始视频序列中的某些信息,以便以更紧凑的形式(即,较低比特率)表示视频。
典型的混合视频编码器(例如,ITU-T H.263和H.264的很多编码器实现)分两个阶段对视频信息进行编码。首先,例如通过运动补偿装置(在先前编码视频帧之一中查找和指示与编码块紧密对应的区域)或通过空间装置(以指定方式使用要编码的块周围的像素值)来预测某个图片区域(或“块”)中的像素值。其次,对预测误差(即,预测像素块与原始像素块之间的差异)进行编码。通常,这是通过以下方式来完成的:使用指定变换(例如,离散余弦变换(DCT)或其变体)变换像素值的差异,量化系数,并且对量化系数进行熵编码。通过改变量化过程的保真度,编码器可以控制像素表示的准确性(图像质量)与所得到的编码视频表示的大小(文件大小或传输比特率)之间的平衡。
在时间预测中,预测源是先前解码的图片(又称为参考图片)。在块内复制(IBC;又称为块内复制预测)中,可以类似于时间预测来应用预测,但是参考图片是当前图片,并且在预测过程中仅可以参考先前解码的样本。可以类似于时间预测来应用层间或视图间预测,但是参考图片分别是来自另一可伸缩层或来自另一视图的解码图片。在一些情况下,帧间预测(inter prediction)可以仅指代时间预测,而在其他情况下,帧间预测可以统称为时间预测、以及块内复制、层间预测和视图间预测中的任何一个,只要它们是用与时间预测相同或相似的的过程执行的。帧间预测或时间预测有时可称为运动补偿或运动补偿预测。
帧间预测(也可以称为时间预测、运动补偿或运动补偿预测)减少了时间冗余。在帧间预测中,预测源是先前解码的图片。帧内预测(intra prediction)利用同一图片内的相邻像素很可能相关的这一事实。帧内预测可以在空间或变换域中执行,即,可以预测样本值或变换系数。通常在不应用帧间预测的帧内编码中利用帧内预测。
编码过程的一个结果是一组编码参数,诸如运动向量和量化的变换系数。如果首先根据空间或时间上相邻的参数来预测很多参数,则可以更有效地对该参数进行熵编码。例如,可以从空间上相邻的运动向量来预测运动向量,并且可以仅编码相对于运动向量预测值的差异。编码参数的预测和帧内预测可以统称为图片内预测。
图4示出了适合于采用本发明的实施例的视频编码器的框图。图4给出了用于两个层的编码器,但是应当理解,所给出的编码器可以类似地扩展以编码多于两层。图4示出了视频编码器的实施例,该视频编码器包括用于基本层的第一编码器部分500和用于增强层的第二编码器部分502。第一编码器部分500和第二编码器部分502中的每个可以包括用于对输入图片进行编码的类似元件。编码器部分500、502可以包括像素预测器302、402、预测误差编码器303、403和预测误差解码器304、404。图4还示出了像素预测器302、402的实施例,该像素预测器302、402包括帧间预测器(Pinter)306、406、帧内预测器(Pintra)308、408、模式选择器310、410、滤波器316、416和参考帧存储器318、418。第一编码器部分500的像素预测器302接收要在帧间预测器306(确定图像与运动补偿参考帧318之间的差异)和帧内预测器308(仅基于当前帧或图片的已经处理的部分来确定图像块的预测)两者处进行编码的视频流的300个基本层图片。帧间预测器和帧内预测器两者的输出被传递给模式选择器310。帧内预测器308可以具有一个以上的帧内预测模式。因此,每个模式可以执行帧内预测并且将预测信号提供给模式选择器310。模式选择器310还接收基本层图片300的副本。相应地,第二编码器部分502的像素预测器402接收要在帧间预测器406(确定图像与运动补偿参考帧418之间的差异)和帧内预测器408(仅基于当前帧或图片的已经处理的部分来确定图像块的预测)两者处进行编码的视频流的400个增强层图像。帧间预测器和帧内预测器两者的输出被传递给模式选择器410。帧内预测器408可以具有一个以上的帧内预测模式。因此,每个模式可以执行帧内预测并且将预测信号提供给模式选择器410。模式选择器410还接收增强层图片400的副本。
取决于选择哪种编码模式来编码当前块,帧间预测器306、406的输出或者可选帧内预测器模式之一的输出或者模式选择器内的表面编码器的输出被传递给模式选择器310、410的输出。模式选择器的输出被传递给第一求和设备321、421。第一求和设备可以从基本层图片300/增强层图片400中减去像素预测器302、402的输出以产生被输入到预测误差编码器303、403的第一预测误差信号320、420。
像素预测器302、402还从初步重构器339、439接收图像块312,412的预测表示与预测误差解码器304、404的输出338、438的组合。初步重构图像314、414可以被传递给帧内预测器308、408和滤波器316、416。接收初步表示的滤波器316、416可以对初步表示进行滤波并且输出可以保存在参考帧存储器318、418中的最终重构图像340、440。参考帧存储器318可以连接到帧间预测器306,以用作在帧间预测操作中与将来的基本层图片300进行比较的参考图像。在根据一些实施例将基本层选择并且指示为用于增强层的层间样本预测和/或层间运动信息预测的源的情况下,参考帧存储器318也可以连接到帧间预测器406,以用作在帧间预测操作中与将来的增强层图片400进行比较的参考图像。此外,参考帧存储器418可以连接到帧间预测器406,以用作在帧间预测操作中与将来的增强层图片400进行比较的参考图像。
根据一些实施例,来自第一编码器部分500的滤波器316的滤波参数可以被提供给第二编码器部分502,条件是基本层被选择并且被指示为用于预测增强层的滤波参数的源。
预测误差编码器303、403包括变换单元342、442和量化器344、444。变换单元342、442将第一预测误差信号320、420变换到变换域。该变换例如是DCT变换。量化器344、444对变换域信号(例如,DCT系数)进行量化以形成量化系数。
预测误差解码器304、404接收预测误差编码器303、403的输出,并且执行预测误差编码器303、403的相反过程,以产生解码的预测误差信号338、438,该解码的预测误差信号338、438当在第二求和设备339、439处与图像块312、412的预测表示组合时产生初步重构图像314、414。预测误差解码器可以被认为包括去量化器361、461和逆变换单元363、463,该去量化器361、461对量化系数值(例如,DCT系数)进行去量化以重构变换信号,该逆变换单元363、463对重构的变换信号执行逆变换,其中逆变换单元363、463的输出包含(多个)重构块。预测误差解码器还可以包括可以根据进一步的解码信息和滤波参数来对(多个)重构块进行滤波的块滤波器。
熵编码器330、430接收预测误差编码器303、403的输出,并且可以对信号执行适当的熵编码/可变长度编码,以提供误差检测和校正能力。熵编码器330、430的输出可以例如通过多路复用器508被插入到比特流中。
H.264/AVC标准是由国际电信联盟(ITU-T)的电信标准化部门的视频编码专家组(VCEG)和国际标准化组织(ISO)/国际电工委员会(IEC)的运动图像专家组(MPEG)的联合视频组(JVT)开发的。H.264/AVC标准是由这两个母标准化组织共同发布的,并且被称为ITU-T建议H.264和ISO/IEC国际标准14496-10,也称为MPEG-4第10部分高级视频编码(AVC)。H.264/AVC标准有多个版本,在规范中集成了新的扩展或特征。这些扩展包括可伸缩视频编码(SVC)和多视图视频编码(MVC)。
高效视频编码(H.265/HEVC,又称为HEVC)标准的版本1是由VCEG和MPEG的视频编码联合协作小组(JCT-VC)开发的。该标准由这两个母标准化组织共同发布,并且被称为ITU-T建议H.265和ISO/IEC国际标准23008-2,也称为MPEG-H第2部分高效视频编码(HEVC)。H.265/HEVC的更高版本包括可伸缩多视图保真度范围扩展、三维和屏幕内容编码扩展,其可以分别缩写为SHVC、MV-HEVC、REXT、3D-HEVC和SCC。
SHVC、MV-HEVC和3D-HEVC使用通用基础规范,该规范在HEVC标准的版本2的附件F中指定。这个共同的基础包括例如高级语法和语义,例如,指定比特流的各层的某些特性(诸如层间依存关系)以及解码过程(诸如参考图片列表构造,包括多层比特流的层间参考图片和图片顺序计数推导)。附件F也可以用于HEVC的潜在后续多层扩展中。应当理解,即使下面参考诸如SHVC和/或MV-HEVC等特定扩展来描述视频编码器、视频解码器、编码方法、解码方法、比特流结构和/或实施例,但是它们通常可以应用于HEVC的任何多层扩展,甚至更普遍地可以应用于任何多层视频编码方案。
通用视频编码(VVC、H.266或H.266/VVC)标准的标准化已经在ITU-T和MPEG的联合视频专家组(JVET)中开始。
本节描述H.264/AVC和HEVC的一些关键定义、比特流和编码结构以及概念作为视频编码器、解码器、编码方法、解码方法和比特流结构的示例,其中可以实施实施例。H.264/AVC的一些关键定义、比特流和编码结构以及概念与HEVC中的相同,因此下面将对其进行共同描述。本发明的各方面不限于H.264/AVC或HEVC,而是给出了一种可能的基础的描述,在此基础上可以部分或完全实现本发明。下面在H.264/AVC或HEVC的上下文中描述的很多方面可以应用于VVC,并且因此,本发明的各方面可以应用于VVC。
与很多早期的视频编码标准类似,在H.264/AVC和HEVC中指定了比特流语法和语义以及无错误比特流的解码过程。没有指定编码过程,但是编码器必须生成一致的比特流。可以使用假定参考解码器(HRD)验证比特流和解码器的一致性。这些标准包含有助于解决传输错误和丢失的编码工具,但是在编码中使用该工具是可选的,并且尚未为错误的比特流指定解码过程。
H.264/AVC或HEVC编码器的输入和H.264/AVC或HEVC解码器的输出的相应基本单位是图片。被提供作为编码器的输入的图片也可以称为源图片,并且通过解码器解码的图片可以称为解码图片。
源图片和解码图片分别由一个或多个样本数组组成,诸如以下样本数组集之一:
-仅亮度(Y)(单色)。
-亮度和两个色度(YCbCr或YCgCo)。
-绿色、蓝色和红色(GBR,也称为RGB)。
-表示其他未指定单色或三刺激颜色采样的数组(例如,YZX,
也称为XYZ)。
在下文中,这些数组可以称为亮度(或L或Y)和色度,其中两个色度数组可以称为Cb和Cr;而不管实际使用的颜色表示方法是什么。实际使用的颜色表示方法可以例如在编码比特流中例如使用H.264/AVC和/或HEVC的视频可用性信息(VUI)语法来指示。组件可以定义为三个样本数组(亮度和两个色度)中的数组或三个样本数组之一的单个样本,或者定义为构成单色格式图片的数组或数组的单个样本。
在H.264/AVC和HEVC中,图片可以是帧或场(field)。帧包括亮度样本以及可能的对应色度样本的矩阵。场是帧的一组交替样本行,并且当源信号被隔行扫描时可以用作编码器输入。与亮度样本数组相比,色度样本数组可以不存在(因此可以使用单色采样),或者色度样本数组可以被二次采样。色度格式可以总结如下:
-在单色采样中,只有一个样本数组,其名义上可以被认为是亮度数组。
-在4:2:0采样中,两个色度数组中的每个具有亮度数组的一半高度和一半宽度。
-在4:2:2采样中,两个色度数组中的每个具有亮度数组的相同高度和一半宽度。
-在没有使用单独颜色平面的4:4:4采样中,两个色度数组中的每个具有与亮度数组相同的高度和宽度。
在H.264/AVC和HEVC中,可以将样本数组作为单独颜色平面编码到比特流中,并且分别从比特流中解码单独编码的颜色平面。当使用单独颜色平面时,每个颜色平面(由编码器和/或解码器)分别作为具有单色采样的图片进行处理。
分区(partitioning)可以被定义为将集合划分为子集使得集合的每个元素恰好在子集之一中。
当描述HEVC编码和/或解码操作时,可以使用以下术语。编码块可以被定义为针对N的某个值的N×N样本块,使得将编码树块划分为编码块是分区。编码树块(CTB)可以被定义为针对N的某个值的N×N样本块,使得将分量划分为编码树块是分区。编码树单元(CTU)可以被定义为亮度样本的编码树块、具有三个样本数组的图片的色度样本的两个对应编码树块、或者单色图片或使用三个单独颜色平面和用于对样本进行编码的语法结构进行编码的图片的样本的编码树块。编码单元(CU)可以被定义为亮度样本的编码块、具有三个样本数组的图片的色度样本的两个对应编码块、或者单色图片或使用三个单独颜色平面和用于对样本进行编码的语法结构进行编码的图片的样本的编码块。具有最大允许大小的CU可以被命名为LCU(最大编码单元)或编码树单元(CTU),并且视频图片被划分为非重叠LCU。
CU包括定义用于CU内的样本的预测过程的一个或多个预测单元(PU)和定义用于上述CU中的样本的预测误差编码过程的一个或多个变换单元(TU)。通常,CU由正方形样本块组成,样本块的大小可以从预定义的一组可能的CU大小中选择。每个PU和TU还可以分成较小的PU和TU,以分别增加预测和预测误差编码过程的粒度。每个PU具有与其相关联的预测信息,该预测信息定义将对该PU内的像素应用哪种预测(例如,用于帧间预测的PU的运动向量信息和用于帧内预测的PU的帧内预测方向性信息)。
每个TU可以与描述用于上述TU内的样本的预测误差解码过程的信息(包括例如DCT系数信息)相关联。通常在CU级别用信号通知是否对每个CU应用预测误差编码。在不存在与CU相关联的预测误差残差的情况下,可以认为没有针对上述CU的TU。通常在比特流中用信号通知将图像划分为CU以及将CU划分为PU和TU,从而使解码器能够再现这些单元的预期结构。
在HEVC中,可以将图片分区为图块,该图块是矩形的并且包含整数个LCU。在HEVC中,对图块的分区形成规则网格,其中图块的高度和宽度彼此之间最多相差一个LCU。在HEVC中,切片被定义为一个独立切片分段和同一访问单元中的下一独立切片分段(如果有)之前的所有后续从属切片分段(如果有)中包含的整数个编码树单元。在HEVC中,切片分段被定义为在图块扫描中连续排序并且被包含在单个NAL单元中的整数个编码树单元。将每个图片划分为切片分段是分区。在HEVC中,独立切片分段被定义为不能从先前切片分段的值中推断出其切片分段报头的语法元素的值的切片分段,并且从属切片分段被定义为可以从按照解码顺序的先前独立切片分段的值中推断出其切片分段报头的某些语法元素的值的切片分段。在HEVC中,切片报头被定义为作为当前切片分段或作为当前从属切片分段之前的独立切片分段的独立切片分段的切片分段报头,并且切片分段报头被定义为包含与切片分段中表示的第一或所有编码树单元有关的数据元素的编码切片分段的一部分。如果未使用图块,则以图块内或图片内的LCU的光栅扫描顺序来扫描CU。在LCU中,CU具有特定扫描顺序。
HEVC中的切片分段层RBSP具有以下语法:
slice_segment_header()的语法如下所示:
本文中,first_slice_segment_in_pic_flag和slice_segment_address取决于图片内的切片分段的定位,而其他语法元素的值在同一编码图片的所有独立切片分段中很多次不变。
运动受限图块集(MCTS)使得帧间预测过程在编码中受到限制,从而在运动受限图块集之外的样本值以及使用运动受限图块集之外的一个或多个样本值而导出的在分数样本定位处的样本值都没有被用于运动受限图块集内的任何样本的帧间预测。另外,MCTS的编码被约束以使得不从MCTS之外的块来导出运动向量候选。这可以通过以下方式来实现:关闭HEVC的时间运动向量预测,或者禁止编码器使用TMVP候选或在合并或AMVP候选列表中紧在MCTS的右图块边界的左侧的PU(但MCTS右下角的最后PU除外)的TMVP候选之后的任何运动向量预测候选。通常,MCTS可以被定义为独立于MCTS之外的任何样本值和编码数据(诸如运动向量)的图块集。在某些情况下,可能需要MCTS才能形成矩形区域。应当理解,取决于上下文,MCTS可以指代图片内的图块集或图片序列中的相应图块集。相应图块集可以但通常不是必须在图片序列中并置。
注意,帧间预测中使用的样本位置可以通过编码和/或解码过程而饱和,使得否则将在图片之外的位置饱和以指向图片的对应边界样本。因此,如果图块边界也是图片边界,则在某些使用情况下,编码器可以允许运动向量有效地越过该边界,或者允许运动向量有效地引起分数样本插值,该分数样本插值将参考该边界之外的位置,因为样本位置被饱和到边界上。在其他使用情况下,具体地,如果可以将编码图块从其中图块位于与图片边界相邻的定位的比特流中提取到其中图块位于与图片边界不相邻的定位的另一比特流中,则与任何MCTS边界类似,编码器可以将运动向量约束在图片边界上。
HEVC的时间运动受限图块集SEI消息可以用于指示比特流中运动受限图块集的存在。
需要理解,即使关于MCTS描述了一些示例和实施例,也可以利用独立可解码的时空单元的其他相似概念来类似地实现它们。而且,可以类似于上述MCTS来指定这种时空单元的运动约束。这样的时空单元的示例包括但不限于运动受限切片和运动受限图片。运动受限切片使得帧间预测过程在编码方面受限制,使得在运动受限切片之外的语法或导出变量、在运动受限切片之外的样本值、以及使用在运动受限切片之外的一个或多个样本值而导出的在分数样本定位处的样本值都没有用于运动受限切片内的任何样本的帧间预测。运动受限图片使得帧间预测过程在编码方面受到限制,使得在没有特别考虑图片边界的情况下的在运动受限图片之外的语法或导出变量、在没有特别考虑图片边界的情况下的在运动受限图片之外的样本值、以及在没有特别考虑图片边界的情况下的使用在运动受限图片之外的一个或多个样本值而导出的在分数样本定位处的样本值都没有用于运动受限图片内的任何样本的帧间预测。图片边界的这种特殊考虑例如可以是坐标的饱和应当在图片边界内并且推断在图片边界之外的块或运动向量应当在预测过程中不可用。当在单个时刻或单个图片的上下文中使用短语时空单元时,可以将其视为空间单元,它对应于编码图片的某个子集,并且在解码时对应于解码图片区域的某个子集。
解码器通过应用类似于编码器的预测方法来重构输出视频,以形成像素块的预测表示(使用由编码器创建并且以压缩表示而存储的运动或空间信息)并且进行预测误差解码(预测误差编码的逆操作,在空间像素域中恢复量化的预测误差信号)。在应用预测和预测误差解码手段之后,解码器对预测和预测误差信号(像素值)求和以形成输出视频帧。解码器(和编码器)还可以应用其他过滤手段,以提高输出视频的质量,然后再将其传递以显示和/或存储为视频序列中即将到来的帧的预测参考。
例如,滤波可以包括以下中的一个或多个:解块、样本自适应偏移(SAO)和/或自适应环路滤波(ALF)。H.264/AVC包括解块,而HEVC包括解块和SAO。
在典型的视频编解码器中,运动信息利用与每个运动补偿图像块相关联的运动向量(诸如预测单元)来指示。这些运动向量中的每个表示待编码(在编码器侧)或解码(在解码器侧)的图片中的图像块和先前编码或解码的图片之一中的预测源块的位移。为了有效地表示运动向量,通常相对于块特定预测运动向量来对它们进行差分编码。在典型的视频编解码器中,以预定义方式创建预测的运动向量,例如,计算相邻块的编码或解码运动向量的中值。创建运动向量预测的另一种方法是根据时间参考图片中的相邻块和/或并置块生成候选预测列表,并且用信号通知所选择的候选作为运动向量预测器。除了预测运动向量值,还可以预测哪个(些)参考图片用于运动补偿预测,并且该预测信息可以例如由先前编码/解码的图片的参考索引来表示。参考索引通常根据时间参考图片中的相邻块和/或并置块来预测。此外,典型的高效视频编解码器采用附加运动信息编码/解码机制,通常称为合并模式,其中所有运动场信息(包括运动向量和每个可用参考图片列表的对应参考图片索引)被预测并且在没有任何修改/校正的情况下使用。类似地,使用时间参考图片中的相邻块和/或并置块的运动场信息来预测运动场信息,并且在填充有可用相邻/并置块的运动场信息的运动场候选列表中用信号通知所使用的运动场信息。
在典型的视频编解码器中,运动补偿后的预测残差首先通过变换内核(如,DCT)进行变换,然后进行编码。这样做的原因是,残差之间通常仍然存在一些相关性,并且在很多情况下变换可以帮助减少这种相关性并且提供更有效的编码。
典型的视频编码器利用拉格朗日成本函数来找到最佳编码模式,例如块和相关联的运动向量的期望编码模式。这种成本函数使用加权因子λ将由于有损编码方法而导致的(精确或估计)图像失真与表示图像区域中的像素值所需要的信息(精确或估计)联系在一起:
C=D+λR, (1)
其中C是要最小化的拉格朗日成本,D是在考虑到模式和运动向量的情况下的图像失真(例如,均方误差),R是表示在解码器中重构图像块所需要的数据所需要的位数(包括用于表示候选运动向量的数据量)。
视频编码标准和规范可以允许编码器将编码图片划分为编码切片等。图片内预测通常跨切片边界被禁用。因此,可以将切片视为将编码图片拆分为独立可解码片段的方法。在H.264/AVC和HEVC中,图片内预测可以跨切片边界被禁用。因此,可以将切片视为将编码图片拆分为独立可解码的片段的方法,因此通常将切片视为传输的基本单位。在很多情况下,编码器可以在比特流中指示哪些类型的图片内预测跨切片边界被关闭,并且解码器操作例如在推断哪些预测源可用时会将该信息考虑在内。例如,如果相邻CU驻留在不同切片中,则来自相邻CU的样本可被认为不可用于帧内预测。
H.264/AVC或HEVC编码器的输出和H.264/AVC或HEVC解码器的输入的基本单元分别是网络抽象层(NAL)单元。为了在面向分组的网络上传输或存储到结构化文件中,可以将NAL单元封装成分组或类似结构。H.264/AVC和HEVC中已经为不提供帧结构的传输或存储环境指定了字节流格式。该字节流格式通过在每个NAL单元前面附加起始代码来将NAL单元彼此分离。为了避免错误检测NAL单元边界,编码器运行面向字节的起始代码仿真防止算法,如果否则会出现起始代码,该算法会将仿真防止字节添加到NAL单元有效载荷中。为了使得面向分组的系统与面向流的系统之间能够直接进行网关操作,无论字节流格式是否在使用中,始终可以执行起始代码仿真防止。NAL单元可以被定义为一种语法结构,该语法结构包含要遵循的数据类型的指示以及包含该数据的RBSP形式的字节,该字节在必要时与仿真防止字节散布。原始字节序列有效载荷(RBSP)可以被定义为一种包含封装在NAL单元中的整数个字节的语法结构。RBSP为空或者具有数据位字符串的形式,该数据位字符串包含语法元素,其后是RBSP停止位,然后是零个或多个等于0的后续位。
NAL单元包括报头和有效载荷。在H.264/AVC和HEVC中,NAL单元报头指示NAL单元的类型。
在HEVC中,两字节的NAL单元报头用于所有指定NAL单元类型。NAL单元报头包含一个保留位、六位NAL单元类型指示、用于时间级别的三位nuh_temporal_id_plus1指示(可能需要大于或等于1)和六位nuh_layer_id语法元素。temporal_id_plus1语法元素可以被视为NAL单元的时间标识符,并且基于零的TemporalId变量可以如下导出:TemporalId=temporal_id_plus1-1。缩写TID可以与TemporalId变量互换使用。TemporalId等于0对应最低时间级别。为了避免涉及两个NAL单元报头字节的起始代码仿真,temporal_id_plus1的值必须为非零值。通过排除TemporalId大于或等于选定值的所有VCL NAL单元并且包括所有其他VCL NAL单元而创建的比特流保持一致。因此,TemporalId等于tid_value的图片不使用TemporalId大于tid_value的任何图片作为帧间预测参考。子层或时间子层可以定义为时间可伸缩比特流的时间可伸缩层(或时间层TL),其包括TemporalId变量具有特定值的VCL NAL单元和相关联的非VCL NAL单元。nuh_layer_id可以理解为可伸缩性层标识符。
NAL单元可以分类为视频编码层(VCL)NAL单元和非VCL NAL单元。VCL NAL单元通常是编码切片NAL单元。在HEVC中,VCL NAL单元包含表示一个或多个CU的语法元素。
在HEVC中,图片类型的缩写可以定义如下:拖尾(TRAIL)图片、时间子层访问(TSA)、逐步时间子层访问(STSA)、随机访问可解码前导(RADL)图片、随机访问跳过前导(RASL)图片、链接断开访问(BLA)图片、即时解码刷新(IDR)图片、空闲随机访问(CRA)图片。
随机接入点(RAP)图片(在独立层中也可以称为帧内随机接入点(IRAP)图片)仅包含帧内编码切片。属于预测层的IRAP图片可以包含P、B和I切片,不能使用来自同一预测层中的其他图片的帧间预测,并且可以使用来自其直接参考层的层间预测。在HEVC的当前版本中,IRAP图片可以是BLA图片、CRA图片或IDR图片。包含基本层的比特流中的第一图片是基本层的IRAP图片。只要必要的参数集在需要激活时可用,就可以正确解码独立层处的IRAP图片和独立层处按照解码顺序的所有后续非RASL图片,而无需执行对按照解码顺序在IRAP图片之前的任何图片的解码过程。当必要的参数集在需要激活时可用时,并且当预测层的每个直接参考层的解码已经被初始化时,可以正确地解码属于预测层的IRAP图片以及同一预测层内按照解码顺序的所有后续非RASL图片,而无需执行按照解码顺序在IRAP图片之前的同一预测层的任何图片的解码过程。比特流中可以存在图片仅包含不是IRAP图片的帧内编码切片。
非VCL NAL单元可以是例如以下类型之一:序列参数集、图片参数集、补充增强信息(SEI)NAL单元、访问单元定界符、序列NAL单元的结束、比特流NAL单元的结束或填充数据NAL单元。重构解码图片可能需要参数集,而重构解码样本值不需要很多其他非VCL NAL单元。
在编码视频序列中保持不变的参数可以被包括在序列参数集中。除了解码过程可能需要的参数,序列参数集还可以可选地包含视频可用性信息(VUI),该VUI包括对缓冲、图片输出时序、渲染和资源保留很重要的参数。在HEVC中,序列参数集RBSP包括可以由一个或多个图片参数集RBSP或包含缓冲时段SEI消息的一个或多个SEI NAL单元参考的参数。图片参数集包含在若干编码图片中可能保持不变的这样的参数。图片参数集RBSP可以包括可以由一个或多个编码图片的编码切片NAL单元参考的参数。
在HEVC中,视频参数集(VPS)可以定义为一种语法结构,该语法结构包含应用于零个或多个完整编码视频序列的语法元素,该编码视频序列由在SPS中找到的语法元素的内容确定,该语法元素由在每个切片分段报头中找到的语法元素所参考的在PPS中找到的语法元素所参考。
视频参数集RBSP可以包括可以由一个或多个序列参数集RBSP参考的参数。
视频参数集(VPS)、序列参数集(SPS)和图片参数集(PPS)之间的关系和层次结构可以描述如下。VPS在参数集层次结构中以及可伸缩性和/或3D视频的上下文中驻留在SPS之上一级。VPS可以包括整个编码视频序列中的所有(可伸缩性或视图)层的所有切片通用的参数。SPS包括整个编码视频序列中的特定(可伸缩性或视图)层中的所有切片通用的参数,并且可以由多个(可伸缩性或视图)层共享。PPS包括特定层表示(一个访问单元中的一个可伸缩性或视图层的表示)中的所有切片通用的参数,并且可能由多个层表示中的所有切片共享。
VPS可以提供关于比特流中的层的依赖性关系的信息、以及应用于整个编码视频序列中的所有(可伸缩性或视图)层的所有切片的很多其他信息。VPS可以被认为包括两个部分:基本VPS和VPS扩展,其中VPS扩展可以可选地存在。
带外传输、信令或存储可以另外地或备选地用于除容忍传输错误之外的其他目的,诸如访问或会话协商的简便性。例如,符合ISO基本媒体文件格式的文件中的轨道的样本条目可以包括参数集,而比特流中的编码数据则存储在文件中的其他位置或另一文件中。沿比特流的短语(例如,沿比特流指示)可以在权利要求和所描述的实施例中用于以带外数据与比特流相关联的方式指代带外传输、信令或存储。沿比特流等的短语解码可以指代对与比特流相关联的所参考的带外数据(可以从带外传输、信令或存储获取)进行解码。
SEI NAL单元可以包含一个或多个SEI消息,这些消息对于输出图片的解码不是必需的,但是可以帮助进行相关处理,诸如图片输出时序、渲染、错误检测、错误隐藏和资源保留。在H.264/AVC和HEVC中指定了若干SEI消息,并且用户数据SEI消息使得组织和公司可以指定SEI消息以供自己使用。H.264/AVC和HEVC包含指定SEI消息的语法和语义,但未定义用于在接收方中处理消息的过程。因此,编码器在创建SEI消息时需要遵循H.264/AVC标准或HEVC标准,并且不需要分别符合H.264/AVC标准或HEVC标准的解码器即可处理SEI消息以实现输出顺序一致性。在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单元相关联。
编码图片是图片的编码表示。
在HEVC中,编码图片可以被定义为包含图片的所有编码树单元的图片的编码表示。在HEVC中,访问单元(AU)可以被定义为根据指定分类规则而彼此相关联的按照解码顺序是连续的并且包含nuh_layer_id为任何特定值的至多一个图片的NAL单元的集合。除了包含编码图片的VCL NAL单元,访问单元还可以包含非VCL NAL单元。上述指定分类规则可以例如将具有相同输出时间的图片或图片输出计数值关联到同一访问单元中。
比特流可以被定义为形成形成一个或多个编码视频序列的编码图片和相关数据的表示的为NAL单元流或字节流形式的比特序列。在同一逻辑信道中,诸如在同一文件中或在通信协议的同一连接中,第一比特流之后可以是第二比特流。基本流(在视频编码的上下文中)可以定义为一个或多个比特流的序列。第一比特流的结束可以由特定NAL单元指示,该特定NAL单元可以称为比特流(EOB)NAL单元的结束并且是比特流的最后NAL单元。在HEVC及其当前扩展草案中,要求EOB NAL单元的nuh_layer_id等于0。
编码视频序列可以被定义为独立可解码的按照解码顺序的这样的编码图片序列,然后是另一编码视频序列或比特流的结束或序列NAL单元的结束。
在HEVC中,当特定NAL单元(可以称为序列(EOS)NAL单元的结束)出现在比特流中并且其nuh_layer_id等于0时,可以另外地或备选地(根据上述说明)指定编码视频序列以结束。
图片组(GOP)及其特性可以定义如下。不管是否解码了任何先前图片,都可以对GOP进行解码。开放GOP是这样的一组图片,其中当解码从开放GOP的初始帧内图片开始时,按照输出顺序在初始帧内图片之前的图片可能无法正确解码。换言之,开放GOP的图片可以参考(在帧间预测中)属于先前GOP的图片。HEVC解码器可以识别开始开放GOP的帧内图片,因为特定NAL单元类型(CRA NAL单元类型)可以用于其编码切片。封闭GOP是这样的一组图片,其中当解码从封闭GOP的初始帧内图片开始时,所有图片都可以被正确解码。换言之,封闭GOP中没有图片参考先前GOP中的任何图片。在H.264/AVC和HEVC中,封闭GOP可以从IDR图片开始。在HEVC中,封闭GOP也可以从BLA_W_RADL或BLA_N_LP图片开始。与封闭GOP编码结构相比,开放GOP编码结构在压缩方面可能更有效率,这是因为参考图片的选择具有更大的灵活性。
可以在编码器和/或解码器中使用解码图片缓冲区(DPB)。缓冲解码图片有两个原因:用于在帧间预测中进行参考以及用于将解码图片重新排序为输出顺序。由于H.264/AVC和HEVC为参考图片标记和输出重新排序提供了很大的灵活性,因此用于参考图片缓存和输出图片缓存的单独缓冲区可能会浪费存储器资源。因此,DPB可以包括用于参考图片和输出重新排序的统一的解码图片缓冲过程。当解码图片不再用作参考并且不需要用于输出时,可以将其从DPB中删除。
可伸缩视频编码可以指代一种编码结构,其中一个比特流可以包含内容的多个表示,例如以不同比特率、分辨率或帧速率。在这些情况下,接收器可以根据其特性(例如,与显示设备最匹配的分辨率)提取期望表示。备选地,服务器或网络元件可以根据例如接收器的网络特性或处理能力来提取要被传输给接收器的比特流的各部分。可以通过仅对可伸缩比特流的某些部分进行解码来产生有意义的解码表示。可伸缩比特流通常包括提供可用的最低质量视频的“基本层”和在与较低层一起接收和解码时增强视频质量的一个或多个增强层。为了提高增强层的编码效率,该层的编码表示通常取决于较低层。例如,增强层的运动和模式信息可以从较低层来预测。类似地,较低层的像素数据可以用于创建增强层的预测。
在一些可伸缩视频编码方案中,视频信号可以被编码为基本层和一个或多个增强层。增强层可以增强例如时间分辨率(即,帧速率)、空间分辨率,或者仅增强由另一层或其一部分表示的视频内容的质量。每一层及其所有从属层都是例如一定空间分辨率、时间分辨率和质量水平的视频信号的一种表示。在本文档中,我们将可伸缩层及其所有相关层称为“可伸缩层表示”。可以提取和解码与可伸缩层表示相对应的可伸缩比特流的部分,以便以一定保真度产生原始信号的表示。
可伸缩性模式或可伸缩性维度可以包括但不限于以下各项:
-质量可伸缩性:基本层图片的编码质量低于增强层图片,例如,这可以在基本层中使用比增强层中更大的量化参数值(即,用于变换系数量化的量化步长更大)来实现。如下所述,质量可伸缩性可以进一步分类为细粒度可伸缩性(FGS)、中等粒度可伸缩性(MGS)和/或粗粒度可伸缩性(CGS)。
-空间可伸缩性:基本层图片的编码分辨率低于增强层图片(即,样本数更少)。空间可伸缩性和质量可伸缩性、尤其是其粗粒度可伸缩性类型有时可以被视为相同类型的可伸缩性。
-视图可伸缩性,也可以称为多视图编码。基本层表示第一视图,而增强层表示第二视图。视图可以定义为表示一个相机或视点的图片序列。可以认为,在立体或两视图视频中,为左眼呈现一个视频序列或视图,而为右眼呈现平行视图。
-深度可伸缩性,也可以称为深度增强编码。比特流的一个或一些层可以表示(多个)纹理视图(texture view),而其他一个或多个层可以表示(多个)深度视图。
应当理解,很多可伸缩性类型可以被组合并且一起应用。
术语层可以在任何类型的可伸缩性的上下文中使用,包括视图可伸缩性和深度增强。增强层可以指代任何类型的增强,诸如SNR、空间、多视图和/或深度增强。基本层可以指代任何类型的基本视频序列,诸如基本视图、用于SNR/空间可伸缩性的基本层、或用于深度增强的视频编码的纹理基本视图。
发送方、网关、客户端或另一实体可以选择可伸缩视频比特流的传输层和/或子层。术语“层提取”、“层的提取”或“层向下切换”可以指代传输的层数少于发送方、网关、客户端或另一实体接收的比特流中可用的层数。层向上切换可以指代与发送方、网关、客户端或另一实体在进行层向上切换之前所传输的相比传输另外的(多个)层,即,重新开始其传输在层向下切换中被更早停止的一个或多个层的传输。与层向下切换和/或向上切换类似,发送方、网关、客户端或另一实体可以执行时间子层的向下和/或向上切换。发送方、网关、客户端或另一实体也可以执行层和子层向下切换和/或向上切换。层和子层向下切换和/或向上切换可以在同一访问单元等中进行(即,实际上同时),或者可以在不同访问单元等中进行(即,实际上在不同时间)。
用于质量可伸缩性(也称为信噪比或SNR)和/或空间可伸缩性的可伸缩视频编码器可以如下实现。对于基本层,可以使用常规的不可伸缩视频编码器和解码器。基本层的重构/解码图片被包括在用于增强层的参考图片缓冲区和/或参考图片列表中。在空间可伸缩性的情况下,可以在将重构的/解码的基本层图片插入增强层图片的参考图片列表中之前对其进行上采样。可以将基本层解码图片插入到(多个)参考图片列表中,以与增强层的解码参考图片类似地对增强层图片进行编码/解码。因此,编码器可以选择基本层参考图片作为帧间预测参考,并且通过编码比特流中的参考图片索引来指示其使用。解码器从比特流(例如,从参考图片索引)中解码出基本层图片被用作增强层的帧间预测参考。当解码的基本层图片被用作增强层的预测参考时,其被称为层间参考图片。
尽管上一段描述了包括具有增强层和基本层的两个可伸缩层的可伸缩视频编解码器,但是可以将描述概括为具有两个以上层的可伸缩层次结构中的任何两个层。在这种情况下,第二增强层可以在编码和/或解码过程中依赖于第一增强层,并且因此第一增强层可以被视为用于第二增强层的编码和/或解码的基本层。此外,需要理解,在参考图片缓冲区或增强层的参考图片列表中可以存在来自一个以上层的层间参考图片,并且这些层间参考图片中的每个都可以被认为驻留在用于编码和/或解码的增强层的基本层或参考层中。此外,需要理解,作为参考层图片上采样的备选或补充,可以进行其他类型的层间处理。例如,参考层图片的样本的比特深度可以被转换为增强层的比特深度,和/或样本值可以经历从参考层的颜色空间到增强层的颜色空间的映射。
可伸缩视频编码和/或解码方案可以使用多循环编码和/或解码,其特征可以如下。在编码/解码中,可以重构/解码基本层图片以用作在同一层内按照编码/解码顺序的后续图片的运动补偿参考图片,或者用作层间(或视图间或组件间)预测的参考。重构/解码的基本层图片可以存储在DPB中。增强层图片同样可以被重构/解码,以用作在同一层内按照编码/解码顺序的后续图片的运动补偿参考图片,或者用作更高增强层(如果有)的层间(或视图间或组件间)预测的参考。除了重构/解码的样本值,基础/参考层的语法元素值或从基础/参考层的语法元素值中导出的变量可以用于层间/组件间/视图间预测。
层间预测可以被定义为以依赖于来自与当前图片的层(正在编码或解码)不同的层的参考图片的数据元素(例如,样本值或运动向量)的方式进行的预测。存在很多类型的层间预测,并且其可以在可伸缩视频编码器/解码器中应用。层间预测的可用类型可以例如取决于用于对比特流或比特流内的特定层进行编码的编码简档,或者在解码时取决于比特流或比特流内的特定层被指示应当符合的编码简档。备选地或另外地,层间预测的可用类型可以取决于正在使用的可伸缩性的类型或可伸缩编解码器或视频编码标准修正案(例如,SHVC、MV-HEVC或3D-HEVC)的类型。
直接参考层可以被定义为可以用于该层是其直接参考层的另一层的层间预测的层。直接预测层可以被定义为另一层是其直接参考层的层。间接参考层可以被定义为不是第二层的直接参考层而是第三层的直接参考层的层,该第三层是第二层的直接参考层或第二层的直接参考层的间接参考层,该层是针对其的间接参考层。间接预测层可以被定义为另一层是其间接参考层的层。独立层可以被定义为不具有直接参考层的层。换言之,不使用层间预测来预测独立层。非基本层可以被定义为除了基本层之外的任何其他层,并且基本层可以被定义为比特流中的最低层。独立非基本层可以被定义为既是独立层又是非基本层的层。
类似于MVC,在MV-HEVC中,视图间参考图片可以被包括在正在编码或解码的当前图片的(多个)参考图片列表中。SHVC使用多循环解码操作(与H.264/AVC的SVC扩展不同)。SHVC可以被认为使用基于参考索引的方法,即,层间参考图片可以被包括在正在编码或解码的当前图片的一个或多个参考图片列表中(如上所述)。
对于增强层编码,可以在SHVC、MV-HEVC等中使用HEVC基本层的概念和编码工具。然而,在参考层中采用已经编码的数据(包括重构的图像样本和运动参数,又称为运动信息)来有效地编码增强层的附加层间预测工具可以集成到SHVC、MV-HEVC和/或相似的编解码器中。
组成图片可以被定义为包围编码(解码)图片的与整个输入图片的表示相对应的部分。除了组成图片,包围编码(解码)图片可以包括其他数据,诸如另一组成图片。
帧打包可以被定义为包括将一个以上的输入图片(可以称为(输入)组成帧或组成图片)布置到输出图片中。通常,帧打包不限于组成帧的任何特定类型,或者组成帧不必彼此具有特定关系。在很多情况下,帧打包用于将立体视频剪辑的组成帧布置成单个图片序列。该布置可以包括将输入图片放置在输出图片内的空间上不重叠的区域中。例如,在并排布置中,两个输入图片被放置在彼此水平相邻的输出图片内。该布置还可以包括将一个或多个输入图片分区为两个或更多个组成帧分区,并且将组成帧分区放置在输出图片内的空间上不重叠的区域中。输出图片或帧打包输出图片序列可以例如通过视频编码器被编码为比特流。比特流可以例如通过视频解码器被解码。解码器或解码之后的后处理操作可以例如从(多个)解码图片中提取解码的组成帧例如以用于显示。
术语360度视频或虚拟现实(VR)视频可以互换使用。它们通常可以指代如下视频内容:该视频内容提供如此大的视场以至于能够在典型的显示布置中在单个时间点显示视频的仅一部分。例如,可以在头戴式显示器(HMD)上观看VR视频,该头戴式显示器可以能够显示例如大约100度的视场。可以基于HMD的取向来选择要显示的VR视频内容的空间子集。在另一示例中,假定典型的平板观看环境,其中例如可以显示高达40度的视场。当在这样的显示器上显示宽FOV内容(例如,鱼眼)时,可以优选地显示空间子集而不是整个图片。
下面参考图5描述MPEG全向媒体格式(OMAF)。真实世界视听场景(A)由音频传感器以及一组相机或具有多个镜头和传感器的相机设备捕获。该获取产生一组数字图像/视频(Bi)和音频(Ba)信号。相机/镜头通常覆盖相机组或相机设备的中心点周围的所有方向,因此称为360度视频。
可以使用很多不同的麦克风配置来捕获音频并且将其存储为几种不同内容格式,包括基于信道的信号、静态或动态(即,移动通过3D场景)对象信号、以及基于场景的信号(例如,高阶环境立体混合声)。基于信道的信号通常符合CICP中定义的扬声器布局之一。在全向媒体应用中,将渲染的沉浸式音频程序的扬声器布局信号进行二进制处理,以经由耳机进行呈现。
同一时刻的图像(Bi)被拼接、投影并且映射到打包图片(D)上。
对于单眼360度视频,一个时刻的输入图像被拼接以生成表示一个视图的投影图片。单眼内容的图像拼接、投影和逐区域打包过程的分解在图6a中示出,并且在下面描述。输入图像(Bi)被拼接并且投影到三维投影结构上,该三维投影结构可以是例如单位球体。投影结构可以被认为包括一个或多个表面,诸如(多个)平面或其(多个)部分。投影结构可以被定义为由一个或多个表面构成的三维结构,所捕获的VR图像/视频内容在该表面上被投影,并且可以从该表面形成相应投影图片。投影结构上的图像数据还被布置在二维投影图片(C)上。术语投影可以定义为用于将一组输入图像投影到投影帧上的过程。投影图片可以存在一组预定义表示格式,包括例如等角投影(ERP)格式和立方图投影(CMP)格式。可以认为投影图片覆盖了整个球体。
然后,可选地,应用逐区域打包以将投影图片映射到打包图片上。如果未应用逐区域打包,则打包图片与投影图片相同,并且该图片被提供作为图像/视频编码的输入。否则,通过指示打包图片中每个区域的位置、形状和大小来将投影图片的区域映射到打包图片(D)上,并且提供打包图片(D)作为图像/视频编码的输入。术语逐区域打包可以定义为用于将投影图片映射到打包图片的过程。术语打包图片可以定义为由投影图片的逐区域打包而产生的图片。
在立体360度视频的情况下,一个时刻的输入图像被拼接以生成表示两个视图的投影图片,每个眼睛一个视图。如下面关于图6b所述,两个视图可以被映射到同一打包图片上,并且可以由传统2D视频编码器来编码。备选地,可以将投影图片的每个视图映射到其自己的打包图片,在这种情况下,图像拼接、投影和逐区域打包类似于上面关于图6a所述。左视图或右视图的打包图片序列可以独立编码,或者在使用多视图视频编码器时,可以根据另一视图来预测。
立体内容的图像拼接、投影和逐区域打包过程的分解(其中两个视图映射到同一打包图片上)在图6b示出,并且描述如下。输入图像(Bi)被拼接并且被投影到两个三维投影结构上,每个眼睛一个三维投影结构。每个投影结构上的图像数据还被布置到覆盖整个球体的二维投影图片上(CL表示左眼,CR表示右眼)。应用帧打包以将左视图图片和右视图图片打包到同一投影图片上。然后,可选地,应用逐区域打包以将投影图片打包到打包图片上,并且提供打包图片(D)作为图像/视频编码的输入。如果未应用逐区域打包,则打包图片与投影图片相同,并且该图片被提供作为图像/视频编码的输入。
可以针对相同的源图像多次执行图像拼接、投影和逐区域打包的过程,以创建相同内容的不同版本,例如针对投影结构的不同取向。类似地,可以从相同的投影图片多次执行逐区域打包过程,以创建一个以上的要编码的打包图片序列。
360度全景内容(即,图像和视频)水平地覆盖成像设备的捕获定位周围的整个360度视场。垂直视场可以有所不同,并且可以是例如180度。水平地覆盖360度视场并且垂直地覆盖180度视场的全景图像可以通过球体来表示,该球体可以被映射到可以垂直切割以形成2D图片的包围圆柱体(这种类型的投影称为等矩形投影)。形成单视场等距全景图片的过程在图7中示出。将一组输入图像(诸如相机阵列或具有多个镜头和传感器的相机设备的鱼眼镜头图像)拼接到球面图像上。球面图像进一步被投影到圆柱体上(没有顶面和底面)。圆柱体被展开以形成二维投影帧。在实践中,可以合并所呈现的一个或多个步骤。例如,输入图像可以直接投影到圆柱体上,而无需中间投影到球体上。等矩形全景的投影结构可以被认为是包括单个表面的圆柱体。
通常,可以将360度内容映射到不同类型的实体几何结构上,诸如多面体(即,包含平坦多边形面、直边和尖角或顶点(例如,立方体或金字塔)的三维实体)、圆柱体(通过将球面图像投影到圆柱体上,如上所述,利用等角矩形投影)、圆柱体(直接,而不先投影到球体上)、圆锥体等,然后展开为二维图像平面。
在某些情况下,具有360度水平视场但小于180度垂直视场的全景内容可以被视为全景投影的特殊情况,其中球体的极地区域没有映射到二维图像平面上。在某些情况下,全景图像可以具有小于360度的水平视场和高达180度的垂直视场,而其他情况下则具有全景投影格式的特性。
逐区域打包信息可以被编码为比特流中或沿比特流的元数据。例如,打包信息可以包括从预定义或指示的源格式到打包帧格式(例如,从投影图片到打包图片)的逐区域映射,如前所述。
接下来将描述矩形逐区域打包元数据:对于每个区域,元数据定义投影图片中的矩形、打包图片中的相应矩形、以及可选的旋转90度、180度或270度的变换、和/或水平和/或垂直镜像。矩形可以例如由左上角和右下角的位置指示。映射可以包括重采样。由于在投影和打包图片中相应矩形的大小可以不同,因此该机制可以推断逐区域重采样。
除其他外,逐区域打包为以下使用情况提供信令:
-通过对不同区域的采样进行密集化以实现整个球体上的更好均匀性来实现视口无关投影的附加压缩。例如,对ERP的顶部和底部进行过采样,并且可以应用逐区域打包以对它们进行水平下采样。
-以自适应方式布置基于平面的投影格式的各面,诸如立方体贴图投影。
-生成使用视口无关投影格式的视口相关比特流。例如,ERP的各区域或CMP的各面可以具有不同采样密度,并且下层投影结构可以具有不同取向。
-指示由提取器轨道表示的打包图片的区域。当提取器轨道从不同分辨率的比特流中收集图块时,这是必需的。
OMAF允许省略图像拼接、投影和逐区域打包,并且以其捕获格式对图像/视频数据进行编码。在这种情况下,图像D被认为与图像Bi相同,并且每个时刻的有限数目的鱼眼图像被编码。
对于音频,不需要拼接过程,因为捕获信号天生就具有沉浸性和全向性。
拼接图像(D)被编码为编码图片(Ei)或编码视频比特流(Ev)。捕获音频(Ba)被编码为音频比特流(Ea)。然后,根据特定媒体容器文件格式,将编码图像、视频和/或音频组合成用于文件播放的媒体文件(F)或者用于流传输的初始化分段和媒体分段的序列(Fs)。在本说明书中,媒体容器文件格式是ISO基本媒体文件格式。文件封装器还将元数据包括到文件或分段中,诸如投影和逐区域打包信息,该信息有助于渲染解码的打包图片。
文件中的元数据可以包括:
-投影图片的投影格式,
-鱼眼镜头视频参数,
-被打包图片覆盖的球形表面的面积,
-与投影图片相对应的投影结构相对于全局坐标轴的取向,
-逐区域打包信息,以及
-逐区域质量排名(可选)。
使用传递机制将分片段Fs传递给播放器。
文件封装器输出的文件(F)与文件解封装器输入的文件(F')相同。文件解封装器处理文件(F')或接收分段(F's)并且提取编码比特流(E'a、E'v和/或E'i)并且解析元数据。然后,音频、视频和/或图像被解码为解码信号(B'a用于音频,D'用于图像/视频)。基于当前观看取向或视口以及投影、球面覆盖范围、投影结构取向和从文件中解析的逐区域打包元数据,将解码的打包图片(D')投影到头戴式显示器或任何其他显示设备的屏幕上。同样地,根据当前观看取向,例如通过耳机渲染解码音频(B'a)。当前观看取向由头部跟踪以及可能还由眼睛跟踪功能确定。除了被渲染器用来渲染解码视频和音频信号的适当部分,当前观看取向还可以用于视频和音频解码器进行解码优化。
上述过程适用于实时和按需使用情况两者。
人眼无法查看整个360度空间,但仅限于最大水平和垂直FoV(HHFoV、HVFoV)。同样,HMD设备具有技术限制,只能在水平和垂直取向(DHFoV、DVFoV)上查看整个360度空间的子集。
在任何时间点,由应用在HMD上渲染的视频都会渲染360度视频的一部分。该部分在此定义为视口。视口是在经由渲染显示器而显示的全向视频中表示的360世界上的窗口。视口可以备选地定义为适合于显示和由用户观看的全向图像或视频的区域。
取决于应用,视口大小可以对应于HMD的视场或者可以具有较小大小。为了清楚起见,我们将用户在任何给定时间点所看到的360度空间的一部分定义为主视口。
OMAF的坐标系统包括单位球体和三个坐标轴,即,X(前后)轴、Y(左右)和Z(垂直向上)轴,其中这三个轴在球体的中心相交。球体上一点的位置由一对球形坐标方位角(φ)和高程(θ)标识。图8指定了球面坐标方位角(φ)和高程(θ)与X、Y和Z坐标轴的关系。
观看取向可以被定义为表征用户正在消费视听内容的取向(如果是图片或视频,则表征视口的取向)的方位角、仰角和倾斜角的三元组。
图9示出了可以在内容制作中使用的从球形图片到打包图片的转换以及可以在OMAF播放器中使用的从打包图片到要渲染的球形图片的对应转换。本节中的示例针对出现在投影全向视频轨道中的打包图片进行了描述。可以针对图像项得出类似的描述。
内容制作可以包括以下有序步骤:
-如a)所示,拼接作为输入而提供的源图像,以按照全局坐标轴在单位球体上生成球形图片。
-然后,如b)所示,相对于全局坐标轴旋转单位球体。从局部坐标轴转换为全局坐标轴的旋转量由在RotationBox中指示的旋转角度指定。单位球体的局部坐标轴是已经旋转的坐标系的轴。没有RotationBox指示局部坐标轴与全局坐标轴相同。
-然后,如c)所示,将旋转后的单位球体上的球形图片转换为二维投影图片,例如使用等角矩形投影。当应用立体内容的空间打包时,将两个视图的两个球形图片转换为两个组成图片,然后应用帧打包以将两个组成图片打包为一个投影图片。
-可以应用矩形逐区域打包以从投影图片中获取打包图片。打包的一个示例在c)和d)中描述。c)中的虚线矩形表示投影图片上的投影区域,d)中的相应区域表示对应打包区域。在该示例中,投影区域1和3被水平下采样,而投影区域2保持其原始分辨率。
CoverageInformationBox可以用于指示内容覆盖范围,即,打包图片覆盖了球体的哪个部分。
为了将诸如在d)中的打包图片的样本位置映射到a)中所示的渲染中使用的单位球体,OMAF播放器可以执行以下有序步骤:
-通过从视频轨道或图像项目中解码图片,获取诸如d)中的打包图片。
-如果需要,将打包图片的色度样本数组上采样到打包图片的亮度样本数组的分辨率,并且还可以执行颜色空间转换。
-如果指示逐区域打包,则将打包图片的样本位置转换为诸如c)中的相应投影图片的样本位置。否则,投影图片与打包图片相同。
-如果指示了投影图片的空间帧打包,则将投影图片的样本位置转换为投影图片的相应组成图片的样本位置。否则,投影图片的组成图像与投影图片相同。
-将投影图片的组成图像的样本位置转换为相对于局部坐标轴的球坐标,如针对所使用的全向投影格式而指定的。所得到的样本位置对应于b)中所述的球形图片。
-如果指示旋转,则将相对于局部坐标轴的球坐标转换为相对于全局坐标轴的球坐标。否则,全局坐标轴与局部坐标轴相同。
为了用信号通知图块或子图片轨道等的元数据,可以使用任何已知方法。例如,对于360°视频的每个图块或子图片轨道,可以存在逐区域打包框和/或逐二维或球形区域质量排名框。在另一示例中,可以针对体积视频的每个图块或子图片轨道存在元数据。
在视频或图像比特流中或沿视频或图像比特流可以存在逐区域质量排名元数据。质量排名区域的质量排名值可以相对于同一比特流或同一轨道的其他质量排名区域或者其他轨道的质量排名区域。例如,逐区域质量排名元数据可以通过使用SphereRegionQualityRankingBox或2DRegionQualityRankingBox(它们被指定为MPEG全向媒体格式的一部分)来指示。SphereRegionQualityRankingBox为球体区域(即,在球域上定义的区域)提供质量排名值,而2DRegionQualityRankingBox为解码图片上的矩形区域(以及可能的覆盖未被任何矩形区域覆盖的所有区域的剩余区域)提供质量排名值。质量排名值指示质量排名区域的相对质量顺序。当质量排名区域A的非零质量排名值小于质量排名区域B时,质量排名区域A的质量高于质量排名区域B。当质量排名值为非零时,整个指示的质量排名区域内的图片质量可以定义为大致恒定。通常,质量排名球体或2D区域的边界可以与打包区域的边界或逐区域打包元数据中指定的投影区域的边界匹配或不匹配。
在ISO/IEC 14496-15中为H.264/AVC和HEVC而指定的提取器可以实现可以通过参考来提取NAL单元数据的轨道的紧凑形式。提取器是NAL单元状结构。NAL单元状结构可以被指定为像任何NAL单元一样包括NAL单元报头和NAL单元有效载荷,但是在NAL单元状结构中,可能不会遵循防止起始代码仿真的要求(这是NAL单元所必需的)。对于HEVC,提取器包含一个或多个构造器。样本构造器通过参考来从另一轨道的样本中提取NAL单元数据。内联构造器包括NAL单元数据。当提取器由需要它的文件读取器处理时,提取器在逻辑上被替换为按其出现顺序解析所包含的构造器时所产生的字节。可能不允许嵌套提取,例如由样本构造器参考的字节不应当包含提取器;提取器不应当直接或间接参考另一提取器。提取器可以包含一个或多个构造器以用于借助于'scal'类型的轨道参考从当前轨道或链接到该提取器所驻留的轨道的另一轨道中提取数据。
解析的提取器的字节为以下中的一项:
a)一个完整NAL单元;注意,在参考聚合器时,将同时复制所包括和参考的字节
b)不止一个完整NAL单元
在这两种情况下,解析的提取器的字节均以有效长度字段和NAL单元报头开头。
样本构造器的字节仅从通过所指示的'scal'轨道参考所参考的轨道中的单个标识样本中复制。对准是关于解码时间的,即,仅使用采样时间表,然后是样本数的计数偏移。提取器是媒体级别概念,因此在考虑任何编辑列表之前将其应用于目标轨道。(但是,通常希望两个轨道中的编辑列表相同)。
可以使用以下语法:
语义可以定义如下:
-NALUnitHeader():HEVC NAL单元的前两个字节。特定nal_unit_type值表示提取器,例如nal_unit_type等于49。
-builder_type指定所使用的构造器。
-EndOfNALUnit()是一个函数,当在该提取器中有更多数据时,该函数将返回0(假);否则返回1(true)。
示例构造器(SampleConstructor)可以具有以下语法:
track_ref_index标识从其中提取数据的源轨道。track_ref_index是类型为'scal'的轨道参考的索引。第一轨道参考具有索引值1;值0被保留。
从其中提取数据的该轨道中的样本在媒体解码时间线中在时间上对准或最接近地在前,即仅使用采样时间表,通过由sample_offset指定的偏移对样本进行调节,样本包含提取器。sample_offset给出链接轨道中样本的相对索引,该索引将用作信息源。样本0(零)是与包含提取器的样本的解码时间相比具有相同或最接近的在前解码时间的样本;样本1(一)是下一样本,样本-1(负1)是上一样本,以此类推。
data_offset:要复制的参考样本中的第一字节的偏移。如果提取从该样本中的数据的第一字节开始,则偏移取值为0。
data_length:要复制的字节数。
内联构造器的语法可以指定如下:
length:在该字段之后的InlineConstructor所属的字节数。
inline_data:在解析内联构造器时要返回的数据字节。
在ISO/IEC 14496-15中指定的图块轨道使得能够存储一个或多个时间运动受限图块集作为轨道。当图块轨道包含HEVC基本层的图块时,将使用样本条目类型'hvt1'。当图块轨道包含非基本层的图块时,将使用样本条目类型'lht1'。图块轨道的样本由一个或多个完整切片分段中的一个或多个完整图块组成。图块轨道独立于包括与该图块轨道在同一层的VCL NAL单元的任何其他图块轨道。图块轨道具有对图块基本轨道的'tbas'轨道参考。图块基本轨道不包括VCL NAL单元。图块基本轨道使用对图块轨道的'sabt'轨道参考来指示图块排序。可以通过按照轨道参考的顺序从由'sabt'轨道参考指示的轨道的时间对准样本中收集编码数据来重构与图块基本轨道中的样本相对应的HEVC编码图片。因此,可以理解,图块基本轨道包括通过参考被参考的图块轨道的编码视频数据。
子图片可以被定义为表示原始视频内容的空间子集的图片,其在内容产生侧在视频编码之前已经被划分为空间子集。子图片比特流可以被定义为表示原始视频内容的空间子集的比特流,其在内容产生侧在视频编码之前已经被划分为空间子集。子图片轨道可以被定义为与源自同一原始视频内容的(多个)其他轨道具有空间关系并且表示子图片比特流的轨道。子图片轨道符合常规轨道格式,诸如在ISO/IEC 14496-15中为HEVC而定义的'hvc1'或'hev1'。在用于生成子图片轨道的方法中,源图片序列在编码之前被划分为子图片序列。然后将子图片序列与其他子图片序列独立编码为单层比特流,诸如HEVC主简档比特流。编码的单层比特流被封装到子图片轨道中。子图片轨道的比特流可以用运动受限图片进行编码,如稍后定义。在用于生成子图片轨道的另一种方法中,将源图片序列通过运动受限图块集编码为比特流,从该比特流中提取MCTS序列,然后通过将MCTS序列转换为一致的比特流来生成子图片轨道,例如通过切片报头修改和将所生成的比特流封装到轨道中。以这种方式生成的子图片轨道包括运动受限图片。
收集器轨道可以被定义为从其他轨道隐式或显式地提取MCTS或子图片的轨道。当由文件读取器解析时,收集器轨道可以表示符合视频编解码器规范(诸如HEVC或H.266/VVC)的比特流。收集器轨道可以例如提取MCTS或子图片以形成编码图片序列,其中MCTS或子图片被布置成网格。例如,当收集器轨道提取两个MCTS或子图片时,它们可以布置成MCTS或子图片的2×1网格。图块基本轨道可以被视为收集器轨道,并且从其他轨道提取MCTS或子图片的提取器轨道可以被视为收集器轨道。收集器轨道也可以称为收集轨道。作为用于提取到收集器轨道的源的轨道可以称为收集项目轨道。
为避免创建过多的提取器轨道(例如,避免为高分辨率和低分辨率图块的每个组合创建提取器轨道),可以使用以下描述的机制对作为提取的备选的轨道进行分组。同样,为了使得相同图块基本轨道能够用于表示相同内容的不同比特率版本的并置图块轨道,可以使用以下机制。
文件写入器在文件中指示轨道组(例如,称为'alte'轨道组)包含要用作提取源的备选的轨道。
'alte'组的标识符可以从与轨道的标识符相同编号的空间获取。换言之,可能要求'alte'组的标识符不同于所有轨道标识符值。因此,'alte'轨道组标识符可以在常规使用轨道标识符的地方使用。具体地,'alte'轨道组标识符可以用作指示提取源的轨道参考。
由该框组成的轨道组的成员是要用作提取源的备选。track_group_type等于'alte'的轨道组的成员可以用作'scal'或'sabt'轨道参考的源。reference_type等于track_ref_4cc的TrackReferenceTypeBox可以列出(多个)'alte'轨道组的(多个)track_group_id值,该'alte'轨道组除了或代替轨道ID值还包含同一alte_track_ref_4cc值。例如,除了或代替个体轨道,提取器轨道还可以通过'scal'轨道参考而指向'alte'轨道组。'alte'轨道组中的任何单个轨道都是合适的提取源。用于提取的源轨道可以在切换到的轨道具有类型1或2的同步样本或SAP样本的定位进行改变。
统一资源标识符(URI)可以定义为用于标识资源名称的字符串。这样的标识使得能够使用特定协议通过网络与资源的表示进行交互。URI是通过一种方案来定义的,该方案指定了URI的具体语法和相关协议。统一资源定位符(URL)和统一资源名称(URN)是URI的形式。URL可以定义为URI,该URI标识网络资源并且指定对资源进行操作或获取资源表示、指定其主访问机制和网络位置两者的方式。URN可以定义为通过特定名称空间中的名称来标识资源的URI。URN可以用于标识资源,而不暗示其位置或访问方式。
很多视频通信或传输系统、传输机制和多媒体容器文件格式提供了将诸如不同轨道或会话的单独逻辑信道的编码数据彼此关联的手段。例如,存在用于将同一访问单元的编码数据关联在一起的机制。例如,可以以容器文件格式或传输机制提供解码或输出时间,并且可以认为具有相同解码或输出时间的编码数据形成访问单元。
最近,超文本传输协议(HTTP)已经被广泛用于诸如在视频流应用中通过互联网传递实时多媒体内容。与使用用户数据报协议(UDP)的实时传输协议(RTP)不同,HTTP易于配置并且通常被允许穿越防火墙和网络地址转换器(NAT),这使其对于多媒体流应用具有吸引力。
已经启动了几种用于HTTP上的自适应流传输的商业解决方案,诸如Smooth Streaming、Adaptive HTTP Live Streaming和DynamicStreaming,并且已经执行了标准化项目。自适应HTTP流(AHS)最初是在第三代合作伙伴计划(3GPP)分组交换流(PSS)服务的版本9(3GPP TS 26.234Release 9:“Transparent end-to-end packet-switched streaming service(PSS);protocols and codecs”)中进行标准化的。MPEG将3GPP AHS版本9作为MPEG DASH标准(ISO/IEC 23009-1:“Dynamic adaptivestreaming over HTTP(DASH)-Part 1:Media presentation description and segmentformats,”International Standard,2nd Edition,,2014)的起点。3GPP继续致力于与MPEG通信的自适应HTTP流传输,并且发布了3GP-DASH(Dynamic Adaptive Streaming overHTTP;3GPP TS26.247:“Transparent end-to-end packet-switched streaming Service(PSS);Progressive download and dynamic adaptive Streaming over HTTP(3GP-DASH)。MPEGDASH和3GP-DASH在技术上彼此接近,因此可以统称为DASH。类似于MPEG-DASH的流传输系统包括例如在IETF RFC 8216中指定的HTTP实时流(又称为HLS)。为了对上述自适应流传输系统(所有这些提供视频流传输系统的示例)(其中可以实施实施例)进行详细描述,参考上述标准文档。本发明的各方面不限于上面的标准文档,相反,该描述被给出以作为可以部分或完全实现本发明的一种可能的基础。
在DASH中,多媒体内容可以存储在HTTP服务器上,并且可以使用HTTP进行传递。内容可以分两部分存储在服务器上:媒体演示描述(MPD),它描述可用内容的清单、其各种备选、其URL地址和其他特性;以及分段,其以单个或多个文件的形式包含块形式的实际多媒体比特流。MDP为客户端提供必要的信息,以通过HTTP建立动态自适应流。MPD包含描述媒体演示的信息,诸如每个分段的HTTP统一资源定位符(URL),以进行GET分段请求。为了播放内容,DASH客户端可以例如通过使用HTTP、电子邮件、拇指驱动器、广播或其他传输方式获取MPD。通过解析MPD,DASH客户端可以了解程序时序、媒体内容可用性、媒体类型、分辨率、最小和最大带宽、以及多媒体组件的各种编码备选的存在、可访问性特征和所需要的数字版权管理(DRM)、网络上的媒体组件位置以及其他内容特性。使用该信息,DASH客户端可以选择适当的编码备选,并且通过使用例如HTTP GET请求提取分段来开始流传输内容。在进行适当的缓冲以允许网络吞吐量变化之后,客户端可以继续提取后续分段,并且监测网络带宽波动。客户端可以决定如何通过提取不同备选(具有较低或较高比特率)的分段以维持足够的缓冲区来适应可用带宽。
在DASH的上下文中,可以使用以下定义:媒体内容组件或媒体组件可以定义为具有可以个体编码为媒体流的所分配的媒体组件类型的媒体内容的一个连续组件。媒体内容可以被定义为一个媒体内容时段或一系列连续的媒体内容时段。媒体内容组件类型可以被定义为诸如音频、视频或文本等媒体内容的单一类型。媒体流可以被定义为媒体内容组件的编码版本。
在DASH中,分层数据模型用于构造媒体表示,如下所示。媒体演示包括一个或多个时段的序列,每个时段包含一个或多个组,每个组包含一个或多个自适应集,每个自适应集包含一个或多个演示,每个演示包含一个或多个分段。组可以定义为预期不会同时出现的自适应集的集合。自适应集可以被定义为一个或几个媒体内容组件的一组可互换编码版本。演示是媒体内容或其子集的备选选择之一,其典型地因编码选择而不同,例如,在比特率、分辨率、语言、编解码器等方面。分段包含某些持续时间的媒体数据、以及用于解码和呈现所包括的媒体内容的元数据。分段由URI标识,并且通常可以由HTTP GET请求来请求。分段可以定义为与HTTP-URL和由MPD指定的字节范围(可选)相关联的数据单元。
初始化分段可以被定义为包含元数据的分段,该元数据是呈现封装在媒体分段中的媒体流所必需的。在基于ISOBMFF的分段格式中,初始化分段可以包括影片框('moov'),该'moov'可能不包括任何样本的元数据,即,在'moof'框中提供样本的任何元数据。
媒体分段包含用于以正常速度播放的某个持续时间的媒体数据,这种持续时间称为媒体分段持续时间或分段持续时间。内容生产者或服务提供者可以根据服务的期望特性来选择分段持续时间。例如,可以在实时服务中使用相对较短的分段持续时间,以实现较短的端到端等待时间。原因是,分段持续时间通常是由DASH客户端感知的端到端延迟的下限,因为分段是生成DASH的媒体数据的离散单位。内容生成通常以使得整个媒体数据分段可用于服务器的方式完成。此外,很多客户端实现使用分段作为GET请求的单位。因此,在现场服务的典型布置中,只有当媒体分段的整个持续时间可用并且被编码和封装到分段中时,DASH客户端才可以请求分段。对于按需服务,可以使用选择分段持续时间的不同策略。
分段可以被进一步划分为子分段,例如,以便分多个部分来下载分段。可能需要分段包含完整的访问单元。子分段可以通过分段索引框进行索引,该框包含用于映射每个子分段的演示时间范围和字节范围的信息。分段索引框还可以通过用信号通知其持续时间和字节偏移来描述分段中的子分段和流访问点。DASH客户端可以使用从(多个)分段索引框获取的信息来使用字节范围HTTP请求针对特定子分段发出HTTP GET请求。如果使用相对较长的分段持续时间,则可以使用子分段来保持HTTP响应的大小合理和灵活以实现比特率自适应。分段的索引信息可以放在该分段的开头的单个框中,也可以散布在该分段的很多索引框中。不同的传播方法是可能的,诸如分层、菊花链和混合。这种技术可以避免在分段的开头添加大框,因此可以防止可能的初始下载延迟。
如上所述,DASH和其他类似的流传输系统为多媒体流应用提供了协议和/或格式。为了降低VR视频的流传输比特率的最新流传输趋势可以称为视口相关传递,其可以解释如下:覆盖主要视口(即,当前视图取向)的360度视频内容的子集以最佳质量/分辨率进行传输,而其余360度视频则以较低质量/分辨率进行传输。
视口自适应流传输可以通过基于图块的编码和流传输方法来实现。在这些方法中,对360度内容进行编码并且使其可用从而可以选择性地流传输来自不同编码的视口。
在视口特定编码/打包中,将360度图像内容打包到同一帧中,并且着重于(例如,更大的空间区域)主视口。为不同主视口取向和/或FOV创建内容的多个版本。视口特定编码/打包可以通过非对称投影(也称为视口相关投影)来实现,其中视口区域以最高采样密度进行编码,而360场景的其余部分以采样密度从视口到非视口区域逐渐降低的方式进行投影。重新投影的非视口区域被打包到与视口区域相同的图像平面中。在逐区域混合质量方法中,视口区域以最高图片质量进行编码,而其他区域以较低质量进行编码。在逐区域混合分辨率方法中,应用视口无关投影,并且在编码之前对投影的2D图片进行逐区域重采样使得视口源自最高2D分辨率,而其他区域源自较低2D分辨率。
在基于图块的视口相关流传输方法中,将投影图片分区为多个图块,这些图块被编码为运动受限图块集(MCTS)。基于图块的视口自适应流传输方案可以分类如下:
-逐区域混合质量(RWMQ)360°视频:使用MCTS在相同的图块网格上对内容的若干版本进行编码,每个版本具有不同比特率和图片质量。播放器基于MCTS来选择接收哪个版本,以便覆盖视口的MCTS的质量高于其他接收MCTS的质量。
-视口+360°视频:接收完整低分辨率全向图片的MCTS和覆盖视口的高分辨率图块。
-逐区域混合分辨率(RWMR)360°视频:图块以多个分辨率进行编码。播放器选择覆盖视口的高分辨率图块和其余区域的低分辨率图块的组合。
注意,无论使用客户端驱动的比特流重写还是提取器驱动的子图片合并,都可以应用所有这些方法。此外,在所有这些方法中,图块(或其保护带)可以以在预处理或编码中选择的量进行重叠。
已经提出了一种用于减少分辨率视口相关传送或播放中的提取器轨道的数目的方法。可以使用图10所示的多分辨率图块合并的示例方案来说明该方法。
编码比特流作为图块或子图片轨道存储在文件中。指示了作为提取备选的一组图块或子图片轨道。在一个提取备选组中,图块或子图片轨道不必表示相同的打包区域,而在以像素为单位的宽度和高度方面具有相同大小。轨道组标识符必须不同于所有轨道标识符。在示例情况下,生成了两个提取备选组,第一提取备选组包括来自高分辨率比特流的1280×1280图块,第二提取备选组包括来自两个低分辨率比特流的1280×640图块。
在文件中创建提取器轨道。提取器被设置为参考提取备选轨道组,而不是个体图块或子图片轨道。在该示例中,一个样本包括六个提取器,在此标记为a至f。提取器a到d从包括1280×1280图块或子图片轨道的提取备选轨道组中提取。提取器e和f从包括1280×640图块或子图片轨道的提取备选轨道组中提取。
不是将逐区域打包信息存储在提取器轨道中,而是将逐区域打包信息拆分为两片,其中第一片不包括打包区域位置并且存储在图块或子图片轨道中,第二片增加打包区域位置并且存储在提取器轨道中。
指示了全向视频预选,每个预选定义图块或子图片轨道的组合。每个预选指示从哪个(哪些)个体子图片或图块轨道中提取数据。例如,可以指示预选的特性,例如,包括(比其他区域)更高的分辨率的球体区域及其有效分辨率(根据其起源的投影图片的宽度和高度)。
通常,对于每个不同组合都需要提取器轨道,以选择高分辨率或高质量图块。在该方法中,需要单个提取器轨道,其中用于选择高分辨率或高质量图块的每个不同组合仅需要全向预选框,因此避免了管理大量提取器轨道的复杂性。
然而,360°视频的基于图块的视口相关传送涉及大量图块或子图片轨道,每个图块或子图片轨道包含用于独立切片分段的切片分段报头。例如,可以以立方图投影格式使用产生96个图块或子图片轨道的96个图块。类似地,期望为了实现适应观看定位和/或观看取向的点云或体积视频流,将使用大量图块或子图片轨道,每个图块或子图片轨道包含一组补丁。
独立切片分段报头的长度变化,但是通常至少为4个字节,当使用96个图块(每个图块是独立切片分段)时,在60Hz图像速率下产生约184kbps。切片分段报头可以更大,尤其是对于切片轨道,因为切片包含除按照光栅扫描顺序的图片的第一切片以外的所有其他切片的slice_segment_address语法元素。因此,由切片分段报头引起的比特率很大。
在MPEG M43397中已经提出,用信号通知切片分段报头的长度以简化切片分段报头重写过程,该过程用于视口相关360°视频流的后期绑定。例如,可以将NAL单元状结构用于这种信令。这种方法的开销包括指示NAL单元状结构的长度(可配置大小,通常为两个字节)、NAL单元报头(两个字节)和切片分段报头长度(一个字节)。因此,典型的开销是每个切片分段报头5个字节,对应于96图块60Hz内容的大约230kbps。
后期绑定又需要至少部分解析和重写切片分段报头。这样的解析/重写特定于HEVC语法,并且需要解决参数集的激活和相关性。早期绑定可以定义为在客户端中的作者驱动或作者提示的图块或子图片选择和/或合并过程。在OMAF中,早期绑定可以通过提取器轨道来实现,提取器轨道有助于图块选择并且提供用于将图块合并到要解码的比特流的指令。后期绑定可以定义为在客户端中的客户端导出的图块或子图片选择和合并。图块或子图片合并可以被视为用于组合编码图块或子图片而无需重写(多个)切片分段有效载荷的过程。
用于视口相关流传输的OMAF媒体简档基于提取器。通常,每个子图片轨道和每个时刻使用一个提取器,每个提取器通常具有大约15个字节的开销,对应于96图块60Hz内容的大约691kbps。
现在引入一种用于内容制作的改进方法以至少减轻上述问题。
如图11所示,根据一个方面的方法包括在容器文件中写入(1100)包括切片分段报头的第一部分的至少一个第一条目;在容器文件中指示(1102)针对样本应用了至少一个第一条目中的哪个条目;以及在没有切片分段报头的第一部分的情况下制作(1104)样本。
因此,切片分段报头的(多个)部分作为可参考条目被包括在容器文件中,并且通过参考被包括在用于编码图片的样本数据中。在该方法中,在编码图片的所有(独立)切片分段中保持不变的切片分段报头的第一部分作为可参考条目被包括在第一条目列表中。提供指示每个样本与第一条目列表中的指示的索引的关联的映射,并且在不包括第一部分的情况下制作样本。
根据该方法的映射可以通过图12的示例来说明,其中切片分段报头的第一部分在前两个样本(即,包括(多个)切片分段的编码图片)中保持不变。因此,不是制作具有包含切片分段报头的第一部分的切片分段的两个样本,而是向容器文件提供元数据,该元数据指示每个样本与第一条目列表中的指示的索引的关联。由于映射,可以制作样本,而无需包括切片分段报头的第一部分。
由此,可以避免由切片分段报头、切片分段报头长度的信令和提取器引起的比特率开销。可以为视口相关360°视频流保存几百千比特/秒或甚至超过一兆比特/秒。
根据一个实施例,该方法还包括:在容器文件中写入包括切片分段报头的第二部分的集合的至少一个第二条目,其中第二部分包括与第一部分不同的语法元素;在容器文件中指示针对样本应用了至少一个第二条目中的哪个条目;以及在没有切片分段报头的第二部分的集合的情况下制作样本。
本文中,切片分段报头的第二部分作为可参考条目被包括在第二条目列表中,其中第二部分包括可以取决于切片分段在图片内的位置的语法元素,并且第二部分的数目可以等于图片中的(独立)切片分段的数目。提供指示每个样本与第二条目列表中的指示的索引的关联的映射,并且制作样本而不包括第二部分。
根据实施例的映射可以通过图13的示例来图示,其中切片分段报头的第二部分在多个样本中保持不变。图13示出,切片分段报头的第一部分涉及与切片分段报头的第二部分不同的语法元素。在该非限制性示例中,第一部分是指切片分段报头的拖尾部分,第二部分是指切片分段报头的起始部分。然而,可以类似于第一部分来执行到元数据的映射,从而使得能够制作样本而无需包括切片分段报头的第二部分。
根据一个实施例,该方法还包括:在容器文件中写入具有样本的切片分段数据轨道,该切片分段数据轨道包括切片分段数据而没有切片分段报头;在没有切片分段数据的情况下制作样本;以及在容器文件中指示针对样本的切片分段数据驻留在切片分段数据轨道中。切片分段数据轨道可以被定义为其样本包括切片分段数据并且不包括切片分段报头的轨道。已经参考术语子图片轨道或图块轨道描述了一些实施例。需要理解,同样可以参考术语切片分段数据轨道而不是术语子图片轨道或图块轨道来实现实施例。
因此,如图14所示,切片分段数据被包括在一个或多个切片分段数据轨道的样本中,而没有切片分段报头。跨一个或多个编码视频序列具有相同位置和大小的一系列切片分段的切片分段数据可以被包括在单个切片分段数据轨道中。例如通过轨道参考指示,切片分段数据通过参考被包括到编码图片(可以与图块基本轨道中的样本相对应)中。
图14还示出了使用以上任何方面的轨道的样本结构的示例。样本结构可以包括一个或多个切片分段NAL单元状结构。切片分段NAL单元状结构可以隐式地参考第一条目列表中的条目和/或第二条目列表中的条目(用于表示切片分段报头的部分),并且可以隐式地参考切片分段数据轨道中的相关联的样本(用于表示切片分段数据)。
根据一个实施例,容器文件可以符合ISO基本媒体文件格式。
根据一个实施例,至少一个第一条目和/或至少一个第二条目可以是(但不限于)以下结构之一:
-样本组描述框(即,SampleGroupDescriptionBox),或者样本组描述框中的一个或多个样本组描述条目。
-可以被包含在例如MovieBox和/或(多个)MovieFragmentBox中的新框,或者该新框中的(多个)语法结构或(多个)元素。
-定时元数据轨道,或者为定时元数据轨道而定义的元数据,诸如定时元数据轨道的示例条目中的框。
-样本辅助信息(用于一个或多个样本)。
-SubSampleInformationBox中的codec_specific_parameters。可以指定标志字段的新值以指示子样本以切片分段NAL单元状结构开始或被视为切片分段NAL单元状结构。codec_specific_parameters可以例如包含切片分段报头的初始部分,例如,具有5位长度字段(指示初始切片分段报头部分中的位数)和最多27位切片分段报头。在一个实施例中,当子样本被视为切片分段NAL单元状结构时,其可以使用VCL NAL单元的原始nal_unit_type,即,子样本信息指示需要通过包括初始切片分段报头部分来重构NAL单元。
根据一个实施例,切片分段报头的第一部分可以包括在编码图片的独立切片分段的所有切片报头中保持相同的语法元素。
根据一个实施例,关于至少一个第一条目中的哪个条目和/或针对样本应用了至少一个第二条目中的哪个条目的指示可以是(但不限于)以下之一:
-当同一条目应用于整个部分(例如,整个轨道片段)时,可以提供默认条目索引,例如在SampleGroupDescriptionBox中,因此应用于未映射到任何条目的所有样本
-样本到组框(即,SampleToGroupBox)等(诸如CompactSampleToGroupBox)
-可以包含在例如SampleTableBox和/或(多个)TrackFragmentBox中的新框。
-例如提供与媒体样本具有相同的解码时间或合成时间来与媒体样本相关联的定时元数据轨道的样本。样本可以例如提供至少一个第一条目中哪个的条目应用的第一索引和/或至少一个第二条目中哪个的条目应用的第二索引,其中(多个)索引可以例如参考定时元数据轨道的样本条目中列出至少一个第一条目和/或至少一个第二条目的框。
-当相同的样本辅助信息应用于多个媒体样本时,包含至少一个第一条目和/或至少一个第二条目的相同字节范围可以被指示为一个以上的样本的样本辅助信息。
-SubSampleInformationBox
根据一个实施例,关于样本的切片分段数据驻留在切片分段数据轨道中的指示可以是(但不限于)以下之一:
-对切片分段数据轨道的特定类型的轨道参考(例如,具有特定reference_type值的TrackReferenceTypeBox)(例如,在TrackReferenceTypeBox中由其track_ID指示)
-对包括切片分段数据轨道的轨道组的特定类型的轨道参考。
根据一个实施例,包括切片分段报头的第一部分的至少一个第一条目被包括在特定类型的样本组描述框中,并且样本到组框被包括在容器文件中,以指示每个样本至少一个第一条目中的哪个条目应用。样本组可以例如被称为共享切片分段报头('sssh')样本组。'sssh'的每个样本组描述条目可以定义为包含切片分段报头的拖尾部分,该拖尾部分可以在单个轨道的多个样本中或跨时间对准的样本被共享。拖尾部分可以从slice_reserved_flag[i](如果有)开始,或者从slice_type开始。下面通过另一实施例来呈现共享切片分段报头的样本组描述条目的语法和语义的示例。
根据一个实施例,包括在切片分段报头的第二部分的集合的至少一个第二条目被包括在特定类型的样本组描述框中,其中第二部分包括与第一部分不同的语法元素,并且样本到组框被包括在容器文件中,以指示每个样本至少第二第一条目中的哪个条目应用。样本组可以例如被称为初始切片分段报头部分('issh')样本组。'issh'的每个样本组描述条目可以定义为包含图片的切片分段报头的初始部分,通常直到slice_segment_address(包括性的)。很多时候,只有很少的样本组描述条目就足够了(例如,每个图片类型一个样本组描述条目),并且可以有效地压缩样本分组,例如,使用紧凑的样本到组框等。下面通过另一实施例来呈现初始切片分段报头部分的样本组描述条目的语法和语义的示例。
根据一个实施例,在容器文件中指示至少一个第一条目中的哪个条目和/或针对样本应用了至少一个第二条目中的哪个条目包括在样本中包括切片分段NAL单元状结构。切片分段NAL单元状结构的切片分段报头可以从至少一个第一条目中的指示条目和/或至少一个第二条目中的指示条目中来解析。例如,样本可以与初始切片分段报头部分和共享切片分段报头样本组的样本组描述条目相关联,并且可以重构切片分段报头。下面通过另一实施例来呈现切片分段NAL单元状结构的语法和语义的示例。在一个实施例中,切片分段NAL单元状结构包含切片分段数据(可以包括HEVC中的slice_segment_data()和后续rbsp_slice_segment_trailing_bits()语法结构)。
根据一个实施例,该方法还包括在容器文件中写入具有样本的切片分段数据轨道,该切片分段数据轨道包括切片分段数据而没有切片分段报头。切片分段数据轨道可以使用特定样本条目类型,诸如但不限于'hvt2'。该方法还包括在没有切片分段数据的情况下制作媒体轨道的样本。该方法还包括在容器文件中指示针对样本的切片分段数据驻留在切片分段数据轨道中。在一个实施例中,该指示(样本的切片分段数据驻留在切片分段数据轨道中)是通过将具有空有效载荷的切片分段NAL单元状结构包括到样本中来执行的。在一个实施例中,该指示是通过指示样本大小为零来执行的。在一个实施例中,该指示是通过在切片分段NAL单元状结构中包括特定语法元素值来执行的。该指示还可以包括在媒体轨道与切片分段数据轨道之间(例如,从媒体轨道到切片分段数据轨道)的轨道参考或与之伴随。
根据一个实施例,该方法包括制作共享样本组轨道,该共享样本组轨道可以被定义为不包含样本表或TrackRunBox并且因此不包含样本的轨道。共享样本组轨道仅用作样本组描述条目和样本到组映射的容器。共享切片分段报头样本组被包括在共享样本组轨道中,并且由切片分段数据轨道参考。
根据一个实施例,以下设计可以用于在子图片或图块轨道之间共享切片分段报头的公共部分。这种设计能够在同一轨道的多个样本之间以及在若干轨道的时间对准样本之间共享切片分段报头的公共部分。需要理解,该实施例的个体要素可以使用不同机制来实现,并且框名和四字符代码是示例性的,并且可以同样地使用其他框名和四字符代码。所有选项中的技术成分包括以下内容:
1.初始切片分段报头部分('issh')样本组:每个样本组描述条目均包含图片的切片分段报头的初始部分,通常直到slice_segment_address(包括性的)。很多时候,只有很少的样本组描述条目就足够了(例如,每个图片类型一个样本组描述条目),并且可以有效地压缩样本分组。
2.共享切片分段报头('sssh')样本组:每个样本组描述条目包含切片分段报头的拖尾部分,该拖尾部分可以在单个轨道的多个样本中或跨时间对准的样本被共享。拖尾部分通常从slice_reserved_flag[i](如果有)开始,或者从slice_type开始。
3.切片分段的NAL单元状结构包括独立切片分段的slice_segment_layer_rbsp()语法结构和所包含的slice_segment_layer_rbsp()的NAL单元报头的片段。完整slice_segment_layer_rbsp()或相应VCL NAL单元可以从切片分段的NAL单元状结构中重构。切片分段NAL单元状结构包含以下片段:
-通过参考'issh'样本组:切片分段报头的初始部分;
-通过参考'sssh'样本组:切片分段报头的拖尾部分;
-本地或通过参考'hvt2'图块轨道:slice_segment_data()和后续rbsp_slice_segment_trailing_bits()
4.'hvc3'和'hev3'样本条目类型允许样本中存在切片分段NAL单元状结构,并且需要在解析器中对其进行处理。'hvc3'/'hev3'轨道用作图块基本轨道,包括通过参考而来自'hvt2'轨道的样本的切片分段数据,该样本仅包含切片分段数据(没有切片分段报头或NAL单元报头)。当样本大小为0时,将样本重构为好像仅包含切片分段NAL单元状结构一样,包括通过参考而来自'hvt2'轨道的切片分段数据。
5.'hvt2'图块轨道(类似于'hvt1'图块轨道,但区别在于样本格式)包括独立切片分段的语法元素slice_segment_data()和rbsp_slice_segment_trailing_bits()的一个且仅一个实例。
可以使用以下语法:
初始切片分段报头样本组
语法
语义:
orig_nal_unit_type是切片分段的VCL NAL单元的NAL单元类型。
num_ssh_minus1加1指定映射样本中的切片分段报头数。
num_bits_issh_minus1[i]加1指定第i切片分段报头的初始部分中的位数。
issh_bit[i][j]指定第i切片分段报头的slice_segment_header()的第j位。
共享切片分段报头样本组
语法
语义:
sssh_num_bits指定切片分段报头的共享部分中的位数。
sssh_bit[i]指定切片分段报头的共享部分的第i位。
切片分段NAL单元状结构
切片分段NAL单元状结构包括独立切片分段的slice_segment_layer_rbsp()语法结构。完整slice_segment_layer_rbsp()或相应VCL NAL单元可以从切片分段NAL单元状结构中重构。
当不存在slice_segment_trailing_part[i]语法元素时(即,当NumBytesSSTrailingPart等于0时),轨道应当包含对'hvt2'类型的轨道的类型'sabt'的相应轨道参考。
语法
语义:
NALUnitHeader():ISO/IEC 23008-2NAL单元的前两个字节。
nal_unit_type对于ISO/IEC 23008-2视频应当设置为50。forbidden_zero_bit必须按照ISO/IEC 23008-2的规定进行设置。其他字段(nuh_layer_id和nuh_temporal_id_plus1)应当如针对切片分段的VCL NAL单元而设置的那样来设置。
slice_segment_trailing_part[i]指定slice_segment_layer_rbsp()拖尾部分中的第i字节。
从切片分段NAL单元状结构重构VCL NAL单元
在一个实施例中,文件解析可以包括用于从切片分段NAL单元状结构重构VCL NAL单元的以下操作。首先,由切片分段报头和切片分段数据形成RBSP,其中切片分段报头由所指示的初始切片分段报头部分、所指示的共享切片分段报头部分和字节对准(在需要时)形成,并且切片分段数据本机提供或通过参考来提供。VCL NAL单元由所提供的和/或推断出的NAL单元报头(例如,nal_unit_type)和RBSP形成,并且可以涉及插入起始代码仿真阻止字节(除非通过其他方式确保不出现起始代码仿真)。参考以上实施例,可以使用以下详细过程。给定sshIdx(其是样本中按照出现顺序的切片分段NAL单元状结构的基于零的索引),则通过以下有序步骤来重构与样本中第sshIdx切片分段NAL单元状结构相对应的slice_segment_layer_rbsp()语法结构
1.RSBP最初为空。
2.从映射到样本的'issh'样本组描述条目,向RSBP中包括bitIdx从0到num_bits_issh_minus1[sshIdx](包括性的)的issh_bit[sshIdx][bitIdx]。
3.从映射到样本的'sssh'样本组描述条目,向RBSP附加bitIdx从0到sssh_num_bits-1的sssh_bit[bitIdx](包括性的)。
4.按照HEVC的规定,向RBSP附加byte_alignment()。
5.如果NumBytesSSTrailingPart大于0,则向RBSP附加数组slice_segment_trailing_part[]。否则,向RBSP附加类型为'sabt'的第(sshIdx+1)轨道参考的时间对准样本。
通过以下有序步骤,从重构的slice_segment_layer_rbsp()语法结构中重构VCLNAL单元:
1.VCL NAL单元最初为空。
2.通过从映射到样本的'issh'样本组描述条目中将nal_unit_type替换为orig_nal_unit_type,从NAL单元状结构的NALUnitHeader()构造NAL单元报头,并且将其包括到VCL NAL单元中。
3.按照HEVC条款7.3.1.1的规定,向VCL NAL单元重复附加RBSP的字节或emulation_prevention_three_byte语法元素。
根据另一实施例,可以定义样本组并且将其用于指示切片分段报头长度。使用样本组的结果是样本数据本身保持不变。因此,用于创建样本组的制作过程非常简单,尤其是当切片分段长度数据附加到现有ISOBMFF文件时。
根据用于在同一轨道的多个样本之间共享切片分段报头的公共部分的又一实施例,切片分段报头的公共部分可以在子图片或图块轨道之间共享。由于子图片或图块轨道的重复切片分段报头引起的比特率开销相当大,因此共享切片分段报头的公共部分会显著减少开销。在这样的设计中,切片分段报头的长度也变得明确暴露,因此可以在切片分段报头重写中使用快捷方式。
如本文中公开的,关于在同一轨道的多个样本之间共享切片分段报头的公共部分的所有实施例使得能够避免由切片分段报头、切片分段报头长度的信令和提取器引起的比特率开销。此外,它们使得能够推断切片分段报头长度,以便于轻松地重写切片分段报头。它们还使得能够通过指令来进行图块合并,同时实现关于合并哪些图块或子图片轨道的客户端驱动的选择,从而避免HEVC语法特定切片报头重写过程。
本发明的另一方面涉及解析器或客户端的操作。如图15所示,该操作可以包括从容器文件中解析(1500)包括切片分段报头的第一部分的至少一个第一条目;从容器文件中解析(1502)针对样本应用了至少一个第一条目中的哪个条目;以及根据第一至少一个条目中的所应用的条目和切片分段数据来重构(1504)样本的切片分段。
根据一个实施例,该方法还包括从容器文件中解析包括切片分段报头的第二部分的集合的至少一个第二条目,其中第二部分包括与第一部分不同的语法元素;从容器文件中解析针对样本应用了至少一个第二条目中哪个的条目;以及还根据至少一个第二条目中的所应用的条目来重构切片分段。
根据一个实施例,该方法还包括从容器文件中解析样本的切片分段数据驻留在具有样本的切片样本数据轨道中,该切片分段数据轨道包括切片分段数据而没有切片分段报头;从容器文件中读取切片分段数据轨道的时间对准样本;以及基于时间对准样本中承载的切片分段数据来重构切片分段。
根据一个实施例,为了启用HEVC特定后期绑定机制,编码优选地被配置为导致具有相同宽度W和相同高度H的独立切片分段。注意,W不必等于H。可以认为该实施例结合了早期和晚期绑定方法;图块或子图片选择可以是客户端驱动的,而图块或子图片的合并是根据内容作者的指示来执行的。因此,客户端操作不需要包含切片分段报头解析和重写,而只能通过遵循由内容作者给出的指令来实现。该指令可以包括如其他实施例中所述的切片分段NAL单元状结构。
本文中,可以使用导致根据图16的文件结构的写入器操作。在写入器中,每个独立切片分段的序列被封装为图块轨道(例如,类型为'hvt2')。切片轨道的样本仅包含切片分段数据,即,排除了切片分段报头。图块轨道被指示为属于同一轨道组(例如,类型为'alte'),该轨道组可以被视为如先前所讨论的提取备选组。('hvc3'或'hev3'类型的)图块基本轨道被创建,并且图块基本轨道的每个样本包含或被推断为包含N个切片分段NAL单元状结构。图块基本轨道产生具有N个独立切片分段的编码图片,其中值N在图块基本轨道之间可以不同。可以创建若干图块基本轨道,例如对于每个设想的解码能力。在任何实施例中,由文件解析器或播放器在轨道组(例如,类型为'alte')中选择的任何轨道被指示为适合于获取切片分段NAL单元状结构的切片分段数据的源,其任何实施例在以下段落中描述。
在一个实施例中,图块基本轨道包含对轨道组(例如,类型为'alte')的轨道参考(例如,类型为'sabt')的列表,从而指示解析器可以从该轨道组中选择任何轨道作为每个独立切片分段的切片分段数据的源。TrackReferenceTypeBox被允许多次包含相同ID值(参考轨道组)。TrackReferenceTypeBox中的第m ID值(例如,类型为'sabt')与样本的第m NAL单元状结构相关联。
在另一实施例中,定义了可以包含相同轨道的若干轨道组,并且不允许TrackReferenceTypeBox多次包含相同ID值。图块基本轨道包含轨道参考列表(例如,类型为'sabt'),每个轨道参考指向不同轨道组(例如,类型为'alte')。但是,轨道组可以包含相同轨道(例如,类型为'hvt2')。TrackReferenceTypeBox中的第m ID值(例如,类型为'sabt')与样本的第m NAL单元状结构相关联。
在另一实施例中,特定轨道参考类型(例如,类型为'altt')被用于指示相同ID值被用于解析所有切片分段NAL单元状结构,但是当ID值参考轨道组时,每次可以在轨道组中以不同方式选择轨道。在这种情况下,图块基本轨道包括TrackReferenceTypeBox(例如,类型为'altt'),该TrackReferenceTypeBox包含一个ID值,该ID值参考轨道组。
在另一实施例中,特定轨道参考类型(例如,类型为'altt')用于指示TrackReferenceTypeBox中的ID值在解析切片分段NAL单元状结构时循环使用。如果在TrackReferenceTypeBox中列出了若干ID,则它们被循环分配给切片分段NAL单元状结构。
在另一实施例中,可以索引(隐式地)特定轨道参考类型(例如,类型为'altt')的每个列出的ID,并且样本组可以提供切片分段NAL单元状结构到轨道参考的ID的索引的映射。这样,不必在TrackReferenceTypeBox中重复相同值的ID,并且可以使用指向具有不同切片分段报头大小(例如,不同图块大小)的轨道或轨道组的ID。包含索引(在其样本组描述条目中)的样本组可以与初始切片分段报头部分样本组等分离或相同。下面给出扩展初始切片分段报头部分样本组的样本组描述条目的示例。第i切片分段的切片分段数据是从由TrackReferenceTypeBox(例如,类型为'altt')的track_ref_index-th ID值(在track_IDs[]中)标识的轨道中获取的。如果ID值指向轨道组(例如,类型为'alte'),则可以选择轨道组中的任何轨道作为用于获取切片分段数据的源。可以定义,当切片分段数据被固有地包括在切片分段NAL单元状结构中时,track_ref_index是基于1的索引,并且可以使用等于0的track_ref_index。样本组描述条目的其他语法元素可以如先前实施例中所述的那样定义。
在一个实施例中,当样本大小被指示为零时,推断出图块基本轨道的样本('hvc3'或'hev3')包含N个切片分段NAL单元状结构。当图块基本轨道中的样本大小为0时,如以上任何实施例中所描述的,可能需要使用轨道参考来指示用于获取用于所推断的切片分段NAL单元状结构的切片分段数据的合适源。当图块基本轨道中的样本大小为0时,通过重复调用VCL NAL单元的重构过程来重构与样本相对应的比特流,就好像该样本包含很多带有空有效载荷的切片分段NAL单元状结构一样,其中数目(N)可以被确定为等于TrackReferenceTypeBox中的ID值的数目(在一些实施例中)或映射到样本的初始切片分段报头条目的列表条目的数目,例如num_ssh_minus1+1(在某些实施例中)。
参考提取备选轨道组的'hvc3'或'hev3'图块基本轨道可以不包含逐区域打包信息(例如,RegionWisePackingBox),因为打包区域的映射可以取决于客户端对在提取备选轨道组中被标记为备选的轨道的选择。提取备选轨道组中包括的图块或子图片轨道(例如,'hvt2'轨道等)可以包含逐区域打包信息(例如,RegionWisePackingBox),该逐区域打包信息可以用于确定解码图片中的样本位置的语义。换言之,'hvc3'或'hev3'图块基本轨道的解码图片的逐区域打包格式由从所参考的提取备选轨道组中选择的图块或子图片轨道(等)的样本条目内的RegionWisePackingBox的实例的集合来表示。
关于后期绑定的播放器操作,播放器选择具有合适解码能力要求的图块基本轨道。播放器推断出轨道的样本包含多少个独立切片分段。播放器(从轨道组中)选择覆盖视口(以及视口周围的空白)并且比其他选定图块轨道具有更高分辨率和/或质量的图块轨道。例如,逐区域质量排名信息可以用于推断哪些图块轨道适合覆盖视口以及哪些图块轨道适合于非视口区域。播放器遵循RBSP(和NAL单元,如果需要)的重构过程以重构编码图片。
图17示出了适合于采用本发明的实施例的视频解码器的框图。图20描绘了两层解码器的结构,但是应当理解,解码操作可以类似地用于单层解码器中。
视频解码器550包括用于基本层的第一解码器部分552和用于预测层的第二解码器部分554。框556示出了多路分解器用于将有关基本层图片的信息传送给第一解码器部分552并且将有关预测层图片的信息传送给第二解码器部分554。附图标记P'n表示图像块的预测表示。附图标记D'n表示重构的预测误差信号。框704、804示出了初步重构图像(I'n)。附图标记R'n表示最终重构图像。框703、803示出了逆变换(T-1)。框702、802示出了逆量化(Q-1)。框701、801示出了熵解码(E-1)。框705、805示出了参考帧存储器(RFM)。框706、806示出了预测(P)(帧间预测或帧内预测)。框707、807示出了滤波(F)。框708、808可以用于将解码的预测误差信息与预测的基本层/预测层图像组合以获取初步重构图像(I'n)。初步重构和滤波的基本层图像可以从第一解码器部分552输出709,并且初步重构和滤波的基本层图像可以从第一解码器部分554输出809。
本文中,解码器应当被解释为覆盖能够执行解码操作的任何操作单元,诸如播放器、接收器、网关、解复用器和/或解码器。
图18是可以在其中实现各种实施例的示例多媒体通信系统的图形表示。数据源1510提供模拟、未压缩数字或压缩数字格式或这些格式的任何组合的源信号。编码器1520可以包括预处理或与预处理相结合,诸如数据格式转换和/或源信号的滤波。编码器1520将源信号编码为编码的媒体比特流。应当注意,要解码的比特流可以从实际上位于任何类型的网络内的远程设备直接或间接地接收。另外,比特流可以从本地硬件或软件接收。编码器1520可以能够编码一种以上的媒体类型,诸如音频和视频,或者可能需要一种以上的编码器1520来编码源信号的不同媒体类型。编码器1520还可以获取合成产生的输入,诸如图形和文本,或者它可以能够产生合成媒体的编码比特流。在下文中,仅考虑对一种媒体类型的一个编码媒体比特流的处理以简化描述。但是,应当注意,通常,实时广播服务包括若干流(通常至少一个音频、视频和文本子图块流)。还应当注意,该系统可以包括很多编码器,但是在附图中仅示出了一个编码器1520以简化描述,而不缺乏一般性。应当进一步理解,尽管本文中包含的文本和示例可以具体地描述编码过程,但是本领域技术人员将理解,相同的概念和原理也应用于对应解码过程,反之亦然。
编码媒体比特流可以被传送到存储装置1530。存储装置1530可以包括任何类型的大容量存储器以存储编码媒体比特流。存储装置1530中的编码媒体比特流的格式可以是基本的自包含比特流格式,或者一个或多个编码媒体比特流可以被封装到容器文件中,或者编码媒体比特流可以被封装成适合于DASH(或类似流传输系统)的分段格式并且存储为分段序列。如果一个或多个媒体比特流被封装在容器文件中,则可以使用文件生成器(图中未示出)将一个或多个媒体比特流存储在文件中并且创建文件格式元数据,该元数据也可以存储在文件中。编码器1520或存储装置1530可以包括文件生成器,或者文件生成器可操作地附接到编码器1520或存储装置1530。一些系统“实时”运行,即省略存储并且直接从编码器1520向发送器1540传输编码的媒体比特流。然后,根据需要,可以将编码的媒体比特流传输到发送器1540(也称为服务器)。在传输中使用的格式可以是基本的自包含比特流格式、分组流格式、适合于DASH(或类似的流传输系统)的分段格式,或者一个或多个编码媒体比特流可以被封装到容器文件中。编码器1520、存储装置1530和服务器1540可以驻留在同一物理设备中,或者可以被包括在单独的设备中。编码器1520和服务器1540可以对实时实时内容进行操作,在这种情况下,编码的媒体比特流通常不被永久地存储,而是在内容编码器1520和/或服务器1540中被缓冲一小段时间以消除处理延迟、传输延迟和编码媒体比特率的变化。
服务器1540使用通信协议栈发送编码的媒体比特流。协议栈可以包括但不限于实时传输协议(RTP)、用户数据报协议(UDP)、超文本传输协议(HTTP)、传输控制协议(TCP)和互联网协议(IP)中的一种或多种。当通信协议栈是面向分组的时,服务器1540将编码的媒体比特流封装为分组。例如,当使用RTP时,服务器1540根据RTP有效载荷格式将编码的媒体比特流封装成RTP分组。通常,每种媒体类型都有专用RTP有效载荷格式。再次应当注意,系统可以包含一个以上的服务器1540,但是为简单起见,以下描述仅考虑一个服务器1540。
如果媒体内容被封装在用于存储装置1530或用于将数据输入到发送器1540的容器文件中,则发送器1540可以包括或可操作地附接到“发送文件解析器”(图中未示出)。特别地,如果没有这样传输容器文件,而是封装所包含的编码的媒体比特流中的至少一个以通过通信协议进行传输,则发送文件解析器将定位要通过通信协议传送的编码媒体比特流的适当部分。发送文件解析器还可以帮助为通信协议创建正确的格式,诸如分组报头和有效载荷。多媒体容器文件可以包含封装指令,诸如ISOBMFF中的提示轨道,该封装指令用于在通信协议上封装所包含的媒体比特流中的至少一个。
服务器1540可以通过或可以不通过通信网络连接到网关1550,该通信网络例如可以是CDN、互联网和/或一个或多个接入网的组合。网关也可以或备选地称为中间盒。对于DASH,网关可以是(CDN的)边缘服务器或网络代理。注意,该系统通常可以包括任何数目的网关等,但是为了简单起见,下面的描述仅考虑一个网关1550。网关1550可以执行不同类型的功能,诸如根据一个通信协议栈到另一通信协议栈的分组流的转换、数据流的合并和分支、以及根据下行链路和/或接收器功能的数据流操纵,诸如根据主要下行链路网络条件来控制转发流的比特率。在各种实施例中,网关1550可以是服务器实体。
该系统包括一个或多个接收器1560,该接收器1560通常能够接收所传输的信号,将其解调和解封装为编码媒体比特流。编码媒体比特流可以被传送到记录存储装置1570。记录存储装置1570可以包括任何类型的大容量存储器以存储编码的媒体比特流。记录存储装置1570可以备选地或另外地包括计算存储器,诸如随机存取存储器。记录存储装置1570中的编码媒体比特流的格式可以是基本的自包含比特流格式,或者一个或多个编码媒体比特流可以被封装到容器文件中。如果存在彼此关联的多个编码的媒体比特流,诸如音频流和视频流,则通常使用容器文件,并且接收器1560包括或附接到容器文件生成器,该容器文件生成器从输入流产生容器文件。一些系统“实时”运行,即,省略记录存储装置1570,并且将编码的媒体比特流从接收器1560直接传输到解码器1580。在一些系统中,仅记录的流的最近部分(例如,所记录的流的最近的10分钟摘录)被保持在记录存储装置1570中,同时从记录存储装置1570中丢弃任何较早的记录数据。
编码媒体比特流可以从记录存储装置1570传输到解码器1580。如果有很多编码媒体比特流(诸如音频流和视频流)彼此关联并且封装到容器文件中或者单个媒体比特流被封装在容器文件中,例如为了更容易访问,则使用文件解析器(图中未示出)从容器文件中解封装每个编码媒体比特流。记录存储装置1570或解码器1580可以包括文件解析器,或者文件解析器附接到记录存储装置1570或解码器1580。还应当注意,该系统可以包括很多解码器,但是这里仅讨论一个解码器1570以简化描述而又不失一般性
编码的媒体比特流可以由解码器1570进一步处理,该解码器1570的输出是一个或多个未压缩的媒体流。最终,渲染器1590可以例如利用扬声器或显示器来再现未压缩的媒体流。接收器1560、记录存储装置1570、解码器1570和渲染器1590可以驻留在同一物理设备中,或者可以被包括在单独的设备中。
发送器1540和/或网关1550可以被配置为在不同表示之间执行切换,例如,以用于360度视频内容的不同视口之间的切换、视图切换、比特率适配和/或快速启动,和/或发送器1540和/或网关1550可以被配置为选择所传输的(多个)表示。可以出于多种原因而在不同表示之间进行切换,诸如响应于接收器1560的请求或在其上传送比特流的网络的主要条件(诸如吞吐量)。换言之,接收器1560可以发起表示之间的切换。来自接收器的请求可以是例如来自与先前不同的表示的分段或子分段的请求、对所传输的可伸缩性层和/或子层的改变的请求、或与前一渲染设备相比具有不同能力的渲染设备的改变。对分段的请求可以是HTTP GET请求。对分段的请求可以是具有字节范围的HTTP GET请求。另外地或备选地,例如可以使用比特率调节或比特率适配来在流服务中提供所谓的快速启动,其中在开始或随机访问流之后,所传输的流的比特率低于信道比特率,以便立即开始播放并且达到允许偶尔出现的分组延迟和/或重传的缓冲区占用水平。比特率适配可以包括以各种顺序发生的多个表示或层向上切换以及表示或层向下切换操作。
解码器1580可以被配置为在不同表示之间执行切换,例如,以用于360度视频内容的不同视口之间的切换、视图切换、比特率适配和/或快速启动、和/或解码器1580可以被配置为选择所传输的(多个)表示。可以出于多种原因而在不同表示之间进行切换,诸如以实现更快的解码操作或使所传输的比特流(例如,在比特率方面)适应在其上传送比特流的网络的主要条件(诸如吞吐量)。例如,如果包括解码器1580的设备是多任务的并且为了解码视频比特流以外的其他目的而使用计算资源,则可能需要更快的解码操作。在另一示例中,当以比正常播放速度更快的速度播放内容时(例如,比传统的实时播放速度快两倍或三倍),可能需要更快的解码操作。
以上,已经关于容器文件描述了一些实施例。应当理解,实施例同样适用于文件以外的其他类型的容器。例如,实施例适用于传输中使用的分段,诸如MPEG-DASH中定义的分段。同样地,实施例适用于一组分段,诸如在MPEG-DASH中定义的跟随有一个或多个媒体分片的初始化分片的序列。
在上文中,已经关于切片分段NAL单元状结构描述了一些实施例。需要理解,当对第一条目列表、第二条目列表和/或切片分段数据参考是通过其他手段进行时,实施例同样适用。例如,当编码图片仅包含VCL NAL单元时,相应样本可以为空并且样本可以指定为包含N个切片分段,其中N等于第二条目列表中的相关条目中的第二部分的数目和/或对切片分段数据轨道的轨道参考(例如,类型为'sabt')的数目。可以类似于其他实施例所描述的那样重构编码图片。
在上文中,已经关于HEVC及其语法结构描述了一些实施例。应当理解,实施例同样适用于具有类似概念的其他编解码器。即使已经关于切片分段和切片分段报头描述了实施例,但是它们同样适用于具有报头的任何其他类型的图片分区。
在上文中,已经参考术语图块轨道和图块基本轨道描述了一些实施例。需要理解,实施例适用于其他类似的概念和术语。例如,实施例适用于子图片轨道或切片分段数据轨道,其中参考图块轨道。在另一示例中,实施例适用于收集器轨道,其中参考图块基本轨道。
在上文中,已经关于ISOBMFF描述了一些实施例,例如。当涉及到分段格式时需要理解,实施例可以用具有与ISOBMFF中相似的能力和/或结构的诸如Matroska等任何其他文件格式来类似地实现。
在上文中,已经参考文件写入或制作描述了示例实施例,需要理解,所得到的容器文件和文件解析可以在其中具有对应元素。同样,在已经参考文件解析描述了示例实施例的情况下,需要理解,文件写入器可以具有用于生成要由文件解析器解析的容器文件的结构和/或计算机程序。
在上文中,已经参考编码器描述了示例实施例,需要理解,所得到的比特流和解码器可以在其中具有对应元素。同样,在已经参考解码器描述了示例实施例的情况下,需要理解,编码器可以具有用于生成要由解码器解码的比特流的结构和/或计算机程序。
上面描述的本发明的实施例就分离的编码器和解码器装置来描述编解码器,以帮助理解所涉及的过程。然而,将意识到,该装置、结构和操作可以被实现为单个编码器解码器装置/结构/操作。此外,编码器和解码器可能共享某些或所有公共元素。
尽管以上示例描述了在电子设备内的编解码器内操作的本发明的实施例,但是应当理解,根据权利要求中所限定的本发明可以被实现为任何视频编解码器的一部分。因此,例如,本发明的实施例可以在视频编解码器中实现,该视频编解码器可以在固定或有线通信路径上实现视频编码。
因此,用户设备可以包括诸如在以上本发明的实施例中描述的视频编解码器。应当理解,术语“用户设备”旨在涵盖任何合适类型的无线用户设备,诸如移动电话、便携式数据处理设备或便携式网络浏览器。
此外,公共陆地移动网络(PLMN)的元件也可以包括如上所述的视频编解码器。
通常,本发明的各种实施例可以以硬件或专用电路、软件、逻辑或其任何组合来实现。例如,一些方面可以以硬件来实现,而其他方面可以以可以由控制器、微处理器或其他计算设备执行的固件或软件来实现,但是本发明不限于此。尽管本发明的各个方面可以被图示和描述为框图、流程图或使用一些其他图形表示,但是众所周知,作为非限制性示例,本文中描述的这些框、装置、系统、技术或方法可以以硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其他计算设备或其某种组合来实现。
本发明的实施例可以通过由移动设备的数据处理器可执行的计算机软件来实现,诸如在处理器实体中,或者通过硬件来实现,或者通过软件和硬件的组合来实现。另外,在这一点上,应当注意,如图中的逻辑流程的任何框可以表示程序步骤、或者互连的逻辑电路、框和功能、或者程序步骤和逻辑电路、框和功能的组合。软件可以存储在诸如存储器芯片或在处理器内实现的存储块等物理介质、诸如硬盘或软盘等磁性介质、以及诸如DVD及其数据变体、CD等光学介质上。
存储器可以是适合于本地技术环境的任何类型,并且可以使用任何适当的数据存储技术来实现,诸如基于半导体的存储设备、磁存储设备和系统、光学存储设备和系统、固定存储器和可移动存储器。数据处理器可以是适合本地技术环境的任何类型,并且作为非限制性示例,可以包括通用计算机、专用计算机、微处理器、数字信号处理器(DSP)和基于多核处理器架构的处理器中的一种或多种。
本发明的实施例可以在诸如集成电路模块等各种组件中实践。集成电路的设计总体上是高度自动化的过程。复杂且功能强大的软件工具可以用于将逻辑级设计转换为准备好在半导体衬底上蚀刻和形成的半导体电路设计。
诸如由加利福尼亚州山景城的Synopsys,Inc.和加利福尼亚州圣何塞的CadenceDesign提供的程序可以使用完善的设计规则以及预先存储的设计模块库自动对导体进行布线并且在半导体芯片上定位组件。一旦半导体电路的设计完成,就可以将标准化电子格式(例如,Opus、GDSII等)的所得到的设计传送到半导体制造设施或“工厂”以进行制造。
以上描述通过示例性和非限制性示例的方式提供了对本发明的示例性实施例的完整且信息丰富的描述。然而,当结合附图和所附权利要求书阅读时,鉴于前面的描述,各种修改和变体对于相关领域的技术人员而言将变得很清楚。然而,本发明的教导的所有这些和类似的修改仍将落入本发明的范围内。

Claims (14)

1.一种处理视频的方法,包括:
在容器文件中将具有样本的视频数据的一个或多个切片分段数据轨道封装为图块轨道,所述一个或多个切片分段数据轨道包括切片分段数据而没有切片分段报头,其中所述切片分段数据包括多个独立切片分段;
在所述容器文件中指示多个切片分段数据轨道属于同一轨道组;
在所述容器文件中写入一个或多个图块基本轨道,其中所述图块基本轨道的每个样本包含或被推断为包含一个或多个切片分段网络抽象层NAL单元状结构,所述切片分段网络抽象层NAL单元状结构包括NAL单元报头和NAL单元有效载荷,所述一个或多个图块基本轨道包含对至少一个轨道组的轨道参考的列表,其中所述同一轨道组中的所述多个切片分段数据轨道中的轨道是用于提取的备选。
2.根据权利要求1所述的方法,其中所述指示被包括在定义轨道参考的类型的框中,其中所述框多次包括对所述轨道组的相同参考值,其中所述相同参考值的序号与所述NAL单元状结构的对应序号相关联。
3.根据权利要求1所述的方法,还包括:
定义多个轨道组;以及
将所述指示包括在定义轨道参考的类型的框中,其中所述框最多一次包括对所述多个轨道组中的每个轨道组的相同参考值。
4.根据权利要求2或3所述的方法,还包括:
通过所述轨道参考的所述类型来指示所述相同参考值被用于解析所有切片分段NAL单元状结构,其中当所述参考值参考轨道组时,所述轨道组中的所述轨道是每次能够以不同方式来选择的。
5.根据权利要求2或3所述的方法,还包括:
通过所述轨道参考的所述类型来指示定义所述轨道参考的所述类型的所述框中的参考值在解析所有切片分段NAL单元状结构时被循环使用。
6.根据权利要求2或3所述的方法,还包括:
针对特定轨道参考类型对每个参考值进行索引;以及
在样本组中将切片分段NAL单元状结构映射到所述轨道参考的参考值的索引。
7.一种用于处理视频的装置,包括部件,所述部件用于:
在容器文件中将具有样本的视频数据的一个或多个切片分段数据轨道封装为图块轨道,所述一个或多个切片分段数据轨道包括切片分段数据而没有切片分段报头,其中所述切片分段数据包括多个独立切片分段;
在所述容器文件中指示多个切片分段数据轨道属于同一轨道组;
在所述容器文件中写入一个或多个图块基本轨道,其中所述图块基本轨道的每个样本包含或被推断为包含一个或多个切片分段网络抽象层NAL单元状结构,所述切片分段网络抽象层NAL单元状结构包括NAL单元报头和NAL单元有效载荷,所述一个或多个图块基本轨道包含对至少一个轨道组的轨道参考的列表,其中所述同一轨道组中的所述多个切片分段数据轨道中的轨道是用于提取的备选。
8.根据权利要求7所述的装置,其中所述指示被布置为被包括在定义轨道参考的类型的框中,其中所述框多次包括对所述轨道组的相同参考值,其中所述相同参考值的序号与所述NAL单元状结构的对应序号相关联。
9.根据权利要求7所述的装置,还包括以下部件,所述部件用于:
定义多个轨道组;以及
将所述指示包括在定义轨道参考的类型的框中,其中所述框最多一次包括对所述多个轨道组中的每个轨道组的相同参考值。
10.根据权利要求8或9所述的装置,还包括以下部件,所述部件用于:
通过所述轨道参考的所述类型来指示所述相同参考值被用于解析所有切片分段NAL单元状结构,其中当所述参考值参考轨道组时,所述轨道组中的所述轨道是每次能够以不同方式来选择的。
11.根据权利要求8或9所述的装置,还包括以下部件,所述部件用于:
通过所述轨道参考的所述类型来指示定义所述轨道参考的所述类型的所述框中的参考值在解析所有切片分段NAL单元状结构时被循环使用。
12.根据权利要求8或9所述的装置,还包括以下部件,所述部件用于:
针对特定轨道参考类型对每个参考值进行索引;以及
在样本组中将切片分段NAL单元状结构映射到所述轨道参考的参考值的索引。
13.一种解析容器文件的方法,包括:
从容器文件中解析关于具有样本的视频数据的一个或多个切片分段数据轨道的指示,所述一个或多个切片分段数据轨道包括切片分段数据而没有切片分段报头并且被封装为图块轨道,其中所述切片分段数据包括多个独立切片分段;
从所述容器文件中解析多个切片分段数据轨道属于同一轨道组的指示;
从所述容器文件中读取一个或多个图块基本轨道,其中所述图块基本轨道的每个样本包含或被推断为包含一个或多个切片分段网络抽象层NAL单元状结构,所述切片分段网络抽象层NAL单元状结构包括NAL单元报头和NAL单元有效载荷,所述一个或多个图块基本轨道包含对至少一个轨道组的轨道参考的列表,其中所述同一轨道组中的所述多个切片分段数据轨道中的轨道是用于提取的备选;以及
基于解码能力要求来选择所述图块基本轨道中的一个图块基本轨道以用于重构。
14.一种用于解析容器文件的装置,包括部件,所述部件用于:
从容器文件中解析关于具有样本的视频数据的一个或多个切片分段数据轨道的指示,所述一个或多个切片分段数据轨道包括切片分段数据而没有切片分段报头并且被封装为图块轨道,其中所述切片分段数据包括多个独立切片分段;
从所述容器文件中解析多个切片分段数据轨道属于同一轨道组的指示;
从所述容器文件中读取一个或多个图块基本轨道,其中所述图块基本轨道的每个样本包含或被推断为包含一个或多个切片分段网络抽象层NAL单元状结构,所述切片分段网络抽象层NAL单元状结构包括NAL单元报头和NAL单元有效载荷,所述一个或多个图块基本轨道包含对至少一个轨道组的轨道参考的列表,其中所述同一轨道组中的所述多个切片分段数据轨道中的轨道是用于提取的备选;以及
基于解码能力要求来选择所述图块基本轨道中的一个图块基本轨道以用于重构。
CN201980074367.9A 2018-09-12 2019-09-05 用于视频编码和解码的装置、方法和计算机程序 Active CN113170238B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FI20185759 2018-09-12
FI20185759 2018-09-12
PCT/FI2019/050637 WO2020053477A2 (en) 2018-09-12 2019-09-05 An apparatus, a method and a computer program for video coding and decoding

Publications (2)

Publication Number Publication Date
CN113170238A CN113170238A (zh) 2021-07-23
CN113170238B true CN113170238B (zh) 2023-08-01

Family

ID=69778212

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980074367.9A Active CN113170238B (zh) 2018-09-12 2019-09-05 用于视频编码和解码的装置、方法和计算机程序

Country Status (4)

Country Link
US (1) US12041108B2 (zh)
EP (1) EP3850863A4 (zh)
CN (1) CN113170238B (zh)
WO (1) WO2020053477A2 (zh)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2554877B (en) * 2016-10-10 2021-03-31 Canon Kk Methods, devices, and computer programs for improving rendering display during streaming of timed media data
US11457231B2 (en) * 2019-03-15 2022-09-27 Mediatek Singapore Pte. Ltd. Methods and apparatus for signaling spatial relationships for point cloud multimedia data tracks
US11245926B2 (en) * 2019-03-19 2022-02-08 Mediatek Singapore Pte. Ltd. Methods and apparatus for track derivation for immersive media data tracks
US11368717B2 (en) * 2019-09-16 2022-06-21 Tencent America LLC Method and apparatus for point cloud compression
US11716488B2 (en) * 2019-09-20 2023-08-01 Qualcomm Incorporated Subpicture signaling in high-level syntax for video coding
CN114586361A (zh) * 2019-09-23 2022-06-03 瑞典爱立信有限公司 具有子图片片位置导出的片段位置信令
GB2587364B (en) * 2019-09-24 2023-11-15 Canon Kk Method, device, and computer program for encapsulating media data into a media file
US11399188B2 (en) * 2020-01-01 2022-07-26 Tencent America LLC Method for mixed NAL unit type support in a coded picture
WO2021205061A1 (en) 2020-04-07 2021-10-14 Nokia Technologies Oy An apparatus, a method and a computer program for video coding and decoding
US20230103016A1 (en) * 2020-04-11 2023-03-30 Lg Electronics Inc. Point cloud data transmission device, point cloud data transmission method, point cloud data reception device, and point cloud data reception method
JPWO2021251141A1 (zh) * 2020-06-09 2021-12-16
WO2022059495A1 (ja) * 2020-09-15 2022-03-24 ソニーグループ株式会社 情報処理装置および方法
EP3972278A1 (en) * 2020-09-17 2022-03-23 Lemon Inc. Subpicture tracks in coded video
US20220086387A1 (en) * 2020-09-17 2022-03-17 Lemon Inc. Subpicture entity groups in video coding
WO2022074295A1 (en) * 2020-10-07 2022-04-14 Nokia Technologies Oy A coded picture with mixed vcl nal unit type
US20220201308A1 (en) * 2020-12-18 2022-06-23 Lg Electronics Inc. Media file processing method and device therefor
CN115243053B (zh) * 2021-04-22 2024-04-16 腾讯科技(深圳)有限公司 点云编解码方法及相关设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007080500A1 (en) * 2006-01-11 2007-07-19 Nokia Corporation Extensions to rich media container format for use by mobile broadcast/multicast streaming servers
WO2014111547A1 (en) * 2013-01-18 2014-07-24 Canon Kabushiki Kaisha Method, device, and computer program for encapsulating partitioned timed media data
FI20165114A (fi) * 2016-02-17 2017-08-18 Nokia Technologies Oy Laitteisto, menetelmä ja tietokoneohjelma videokoodausta ja videokoodauksen purkua varten

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7542435B2 (en) * 2004-05-12 2009-06-02 Nokia Corporation Buffer level signaling for rate adaptation in multimedia streaming
RU2492585C2 (ru) * 2008-07-16 2013-09-10 Нокиа Корпорейшн Способ и устройство для группирования треков и подмножеств треков
US8976871B2 (en) * 2009-09-16 2015-03-10 Qualcomm Incorporated Media extractor tracks for file format track selection
WO2014170547A1 (en) * 2013-04-17 2014-10-23 Nokia Corporation An apparatus, a method and a computer program for video coding and decoding
GB2516825B (en) 2013-07-23 2015-11-25 Canon Kk Method, device, and computer program for encapsulating partitioned timed media data using a generic signaling for coding dependencies
WO2015051497A1 (en) 2013-10-08 2015-04-16 Mediatek Singapore Pte. Ltd. Compatible slice segment header
US9621919B2 (en) * 2013-10-23 2017-04-11 Qualcomm Incorporated Multi-layer video file format designs
GB2550912B (en) 2016-05-27 2019-09-04 Canon Kk Method, device and computer program for encapsulating and parsing timed media data
WO2018083378A1 (en) 2016-11-01 2018-05-11 Nokia Technologies Oy An apparatus, a method and a computer program for video coding and decoding
FI20166017A (fi) 2016-12-22 2018-06-23 Nokia Technologies Oy Laitteisto, menetelmä ja tietokoneohjelma videokoodausta ja videokoodauksen purkua varten
EP3349467B1 (en) 2017-01-10 2019-09-04 Nokia Technologies Oy An apparatus, a method and a computer program for video coding and decoding
WO2018146376A1 (en) 2017-02-13 2018-08-16 Nokia Technologies Oy An apparatus, a method and a computer program for video coding and decoding
EP3422724B1 (en) 2017-06-26 2024-05-01 Nokia Technologies Oy An apparatus, a method and a computer program for omnidirectional video
WO2019002662A1 (en) 2017-06-26 2019-01-03 Nokia Technologies Oy APPARATUS, METHOD AND COMPUTER PROGRAM FOR OMNIDIRECTIONAL VIDEO
US11082719B2 (en) * 2017-07-03 2021-08-03 Nokia Technologies Oy Apparatus, a method and a computer program for omnidirectional video
GB2575288B (en) 2018-07-04 2022-05-25 Canon Kk Method and apparatus for encapsulating images or sequences of images with proprietary information in a file

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007080500A1 (en) * 2006-01-11 2007-07-19 Nokia Corporation Extensions to rich media container format for use by mobile broadcast/multicast streaming servers
WO2014111547A1 (en) * 2013-01-18 2014-07-24 Canon Kabushiki Kaisha Method, device, and computer program for encapsulating partitioned timed media data
FI20165114A (fi) * 2016-02-17 2017-08-18 Nokia Technologies Oy Laitteisto, menetelmä ja tietokoneohjelma videokoodausta ja videokoodauksen purkua varten

Also Published As

Publication number Publication date
EP3850863A2 (en) 2021-07-21
WO2020053477A2 (en) 2020-03-19
CN113170238A (zh) 2021-07-23
EP3850863A4 (en) 2022-06-08
US12041108B2 (en) 2024-07-16
US20210194946A1 (en) 2021-06-24
WO2020053477A3 (en) 2020-04-23

Similar Documents

Publication Publication Date Title
CN113170238B (zh) 用于视频编码和解码的装置、方法和计算机程序
CN111543060B (zh) 用于视频编码和解码的装置、方法和计算机程序
US20240267560A1 (en) Apparatus, A Method And A Computer Program For Video Coding And Decoding
CN110870302B (zh) 用于全向视频的装置、方法和计算机程序
US10893256B2 (en) Apparatus, a method and a computer program for omnidirectional video
EP3818716A1 (en) An apparatus, a method and a computer program for video coding and decoding
CN115211131B (zh) 用于全向视频的装置、方法及计算机程序
JP7238155B2 (ja) ビデオコーディングおよびデコーディングのための装置、方法、およびコンピュータプログラム
WO2020201632A1 (en) An apparatus, a method and a computer program for omnidirectional video
WO2019073113A1 (en) APPARATUS, METHOD AND COMPUTER PROGRAM FOR VIDEO ENCODING AND DECODING
WO2019038473A1 (en) APPARATUS, METHOD AND COMPUTER PROGRAM FOR OMNIDIRECTIONAL VIDEO

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
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40055642

Country of ref document: HK

GR01 Patent grant
GR01 Patent grant