CN107431810A - 用于图像编码和解码的装置、方法和计算机程序 - Google Patents
用于图像编码和解码的装置、方法和计算机程序 Download PDFInfo
- Publication number
- CN107431810A CN107431810A CN201680019302.0A CN201680019302A CN107431810A CN 107431810 A CN107431810 A CN 107431810A CN 201680019302 A CN201680019302 A CN 201680019302A CN 107431810 A CN107431810 A CN 107431810A
- Authority
- CN
- China
- Prior art keywords
- image
- file
- picture
- derivation
- description
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
- H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/06—Message adaptation to terminal or network requirements
- H04L51/063—Content adaptation, e.g. replacement of unsuitable content
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
- H04L51/10—Multimedia information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
- H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
- H04N21/23614—Multiplexing of additional data and video streams
Abstract
一种方法,包括:接收第一文件的第一描述,所述第一描述包括被包含在所述第一文件中或由所述第一文件参考的至少派生图像的属性;基于所述派生图像的所述属性,判定是否获得所述派生图像;以及响应于判定获得所述派生图像,获得包括所述派生图像的所述第一文件。
Description
技术领域
本发明涉及一种用于图像编码和解码的装置、方法和计算机程序。
背景技术
ISO基础媒体文件格式(ISOBMFF)指定诸如音频、视频、以及电传文本之类的定时媒体的存储和传输的通用结构。最近,已启动扩展ISOBMFF能力的工作,以便实现静态图像以及图像序列的处理。为了实现图像序列的存储和传输,已在ISO/IEC 23008-12(也被称为MPEG-H部分12)中定义图像文件格式(Image File Format),该定义基于ISO基础媒体文件格式。
在其它属性中,图像文件格式支持派生图像(derived image)。当一个项包括对另一个项的“dimg”项参考时,该项是派生图像。通过对指定输入图像执行指定操作(例如旋转)来获得派生图像。为了获得派生图像而执行的操作由项的item_type来标识。用作到派生图像的输入的图像项可以是编码图像,或者它们可以是其它派生图像项。
多用途因特网邮件扩展(MIME)是电子邮件协议的扩展,其使得可以在因特网上发送和接收不同种类的数据文件,例如视频和音频、图像、软件等。因特网媒体类型是因特网上用于指示文件包含的数据的类型的标识符。此类因特网媒体类型也可以被称为内容类型。存在能够包含不同媒体格式的数个MIME类型/子类型组合。发送实体可以在媒体传输开始时将内容类型信息包括在MIME标头中。接收实体因此可能需要检查此类媒体内容的细节,以便判定在给定一组可用编解码器的情况下,是否可以呈现特定元素。在没有此处描述的参数的情况下,必须检查每个媒体元素以便确定呈现内容所需的编解码器或其它特性。
图像文件格式指定两种MIME类型,一种用于图像和图像集合,并且另一种用于图像序列。针对这些MIME类型指定编解码器参数的格式。但是,该规范缺少对派生图像的考虑,这可能导致各种问题,例如播放器消耗时间来评估它在执行操作之前是否能够组成派生图像。
发明内容
现在为了至少缓解以上问题,在此提供一种用于评估组成派生图像的能力的方法。
一种根据第一方面的方法包括
接收第一文件的第一描述,所述第一描述包括被包含在所述第一文件中或由所述第一文件参考的至少派生图像的属性;
基于所述派生图像的所述属性,判定是否获得所述派生图像;以及
响应于判定获得所述派生图像,获得包括所述派生图像的所述第一文件。
根据一个实施例,所述方法进一步包括:
接收第二文件的第二描述,所述第二描述包括如由所述派生图像表示的对应图像内容的表示;以及
基于所述派生图像的所述属性和所述第二描述,判定是获得所述第一文件还是所述第二文件。
根据一个实施例,所述第一描述包括MIME类型。
根据一个实施例,诸如所述MIME类型的所述第一描述包括用于至少一个派生图像的以下信息片段中的一者或多者:
-用于所述至少一个派生图像的指令集的第一标识;
-用于所述至少一个派生图像的编码输入图像的编解码器和编解码器简档的第二标识;
-指示构造所述至少一个派生图像所需的资源的资源计数。
根据一个实施例,所述方法进一步包括:
从所述第一文件解析指示组成派生图片的所需资源的至少一个值;以及
基于至少一个值,判定是否能够组成所述派生图片。
第二方面涉及一种装置,包括
至少一个处理器和至少一个存储器,所述至少一个存储器在其上存储有代码,当由所述至少一个处理器执行时,所述代码导致所述装置至少执行
接收第一文件的第一描述,所述第一描述包括被包含在所述第一文件中或由所述第一文件参考的至少派生图像的属性;
基于所述派生图像的所述属性,判定是否获得所述派生图像;以及
响应于判定获得所述派生图像,获得包括所述派生图像的所述第一文件。
根据第三方面,提供一种方法,包括:
获得一个或多个输入图像;
确定要针对至少一个输入执行以便获得派生图像的至少一个操作;以及
将第一文件的第一描述包括在媒体内容描述中,所述第一描述包括被包含在所述第一文件中或由所述第一文件参考的至少所述派生图像的属性。
根据一个实施例,所述方法进一步包括
包括第二文件的第二描述,所述第二描述包括如由所述派生图像表示的对应图像内容的表示。
根据一个实施例,所述第一描述包括多用途因特网邮件扩展(MIME)类型。
根据一个实施例,诸如所述MIME类型的所述第一描述包括用于至少一个派生图像的以下信息片段中的一者或多者:
-用于所述至少一个派生图像的指令集的第一标识;
-用于所述至少一个派生图像的编码输入图像的编解码器和编解码器简档的第二标识;
-指示构造所述至少一个派生图像所需的资源的资源计数。
根据一个实施例,所述方法进一步包括:
将表示派生图像的数据结构包括在所述第一文件中,以及
将指示组成派生图片的所需资源的至少一个值包括在所述第一文件中。
根据一个实施例,指示所需资源的所述值包括以下项中的一者或多者:
-大于或等于在组成所述派生图片的任何阶段所需的最大像素、样本和/或字节计数的值;
-大于或等于组成所述派生图片所需的任何图片所需的最大像素、样本和/或字节计数的值,其中组成所述派生图片所需的所述图片包括用于组成所述派生图片的中间操作的输出图片;
-用于标识能够在组成所述派生图片中使用的操作类型集的标识符,而未被包括在所述操作类型集中的操作类型不在组成所述派生图片中使用。
第四方面涉及一种装置,包括
至少一个处理器和至少一个存储器,所述至少一个存储器在其上存储有代码,当由所述至少一个处理器执行时,所述代码导致所述装置至少执行
获得一个或多个输入图像;
确定要针对至少一个输入执行以便获得派生图像的至少一个操作;以及
将第一文件的第一描述包括在媒体内容描述中,所述第一描述包括被包含在所述第一文件中或由所述第一文件参考的至少所述派生图像的属性。
附图说明
为了更好地理解本发明,现在将通过示例的方式参考附图,这些附图是:
图1示意性地示出采用本发明实施例的电子设备;
图2示意性地示出适合于采用本发明实施例的用户设备;
图3进一步示意性地示出使用无线和有线网络连接而连接的采用本发明实施例的电子设备;
图4示意性地示出适合于实现本发明实施例的编码器;
图5示出ISOBMFF盒结构的一个示例;
图6示出根据本发明的一个实施例的媒体播放器的操作的流程图;
图7示出根据本发明的一个实施例的文件创建器的操作的流程图;以及
图8示出适合于实现本发明实施例的解码器的示意图。
具体实施方式
下面进一步详细地描述用于启动视点切换的合适装置和可能机制。在这点上,首先参考图1和2,其中图1示出根据一个示例实施例的视频编码系统的框图,其作为示例性装置或电子设备50的示意框图,示例性装置或电子设备50可以结合根据本发明的一个实施例的编解码器。图2示出根据一个示例实施例的装置的布局。接下来将说明图1和2的元件。
电子设备50可以例如是无线通信系统的移动终端或用户设备。但是,将认识到,本发明的实施例可以在可能需要对视频图像进行编码和解码或者对视频图像进行编码或解码的任何电子设备或装置内实现。
装置50可以包括外壳30,其用于纳入和保护设备。装置50可以进一步包括液晶显示屏形式的显示器32。在本发明的其它实施例中,显示器可以是适合于显示图像或视频的任何合适的显示技术。装置50可以进一步包括小键盘34。在本发明的其它实施例中,可以采用任何合适的数据或用户接口机制。例如,用户接口可以作为触敏显示器的一部分被实现为虚拟键盘或数据输入系统。
所述装置可以包括麦克风36或任何合适的音频输入,该音频输入可以是数字或模拟信号输入。装置50可以进一步包括音频输出设备,在本发明的实施例中,该音频输出设备可以是以下任一者:耳机38、扬声器、或者模拟音频或数字音频输出连接。装置50还可以包括电池40(或者在本发明的其它实施例中,设备可以由诸如太阳能电池、燃料电池或发条发电机之类的任何合适的移动能源设备供电)。所述装置可以进一步包括摄像机42,其能够记录或捕获图像和/或视频。装置50可以进一步包括红外端口,其用于与其它设备进行短距离视线通信。在其它实施例中,装置50可以进一步包括任何合适的短距离通信解决方案,例如蓝牙无线连接或USB/火线有线连接。
装置50可以包括用于控制装置50的控制器56或处理器。控制器56可以连接到存储器58,在本发明的实施例中,存储器58可以存储图像和音频数据形式的数据和/或还可以存储指令以便在控制器56上实现。控制器56可以进一步连接到编解码器电路54,其适合于执行音频和/或视频数据的编码和解码或者有助于由控制器执行的编码和解码。
装置50可以进一步包括读卡器48和智能卡46,例如UICC和UICC读取器,其用于提供用户信息并且适合于提供认证信息以便在网络处对用户进行认证和授权。
装置50可以包括无线电接口电路52,其连接到控制器并且适合于生成无线通信信号,例如以便与蜂窝通信网络、无线通信系统或无线局域网通信。装置50可以进一步包括天线44,其连接到无线电接口电路52,以便将在无线电接口电路52处生成的射频信号发送到其它装置(多个)并且从其它装置(多个)接收射频信号。
装置50可以包括摄像机,其能够记录或检测单独帧,然后将这些帧传递到编解码器54或控制器以便处理。在发送和/或存储之前,所述装置可以从另一个设备接收视频图像数据以便处理。装置50还可以以无线方式或者通过有线连接来接收图像以便编码/解码。
关于图3,示出其中可以使用本发明实施例的系统的一个示例。系统10包括多个通信设备,它们可以通过一个或多个网络通信。系统10可以包括有线或无线网络的任何组合,这些网络包括但不限于无线蜂窝电话网络(例如GSM、UMTS、CDMA网络等)、例如由任何IEEE802.x标准定义的无线局域网(WLAN)、蓝牙个人区域网络、以太局域网、令牌环局域网、广域网、以及因特网。
系统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以及任何类似的无线通信技术。参与实现本发明各种实施例的通信设备可以使用各种介质通信,这些介质包括但不限于无线电、红外线、激光、电缆连接、以及任何合适的连接。
在电信和数据网络中,信道可以指物理信道或逻辑信道。物理信道可以指诸如导线之类的物理传输介质,而逻辑信道可以指多路复用介质(其能够传送数个逻辑信道)上的逻辑连接。信道可以用于将信息信号(例如位流)从一个或数个发送方(或发送机)传送到一个或数个接收方。
实时传输协议(RTP)广泛用于诸如音频和视频之类的定时媒体的实时传输。RTP可以在用户数据报协议(UDP)之上工作,UDP又可以在网际协议(IP)之上工作。RTP在因特网工程任务组(IETF)请求注释(RFC)3550中指定,IETF RFC 3550可从www.ietf.org/rfc/rfc3550.txt获得。在RTP传输中,媒体数据被封装到RTP分组中。通常,每个媒体类型或媒体编码格式具有专用的RTP有效负载格式。
RTP会话是与RTP通信的一组参与者之间的关联。它是组通信信道,其可以潜在承载多个RTP流。RTP流是包括媒体数据的RTP分组流。RTP流由属于特定RTP会话的SSRC来标识。SSRC指同步源或同步源标识符,该标识符是RTP分组标头中的32位SSRC字段。同步源的特征在于,来自同步源的所有分组形成相同定时和序列号空间的一部分,因此接收方可以按照同步源对分组进行分组以便重放。同步源的示例包括从诸如麦克风或摄像机之类的信号源导出的分组流的发送方、或者RTP混合器。每个RTP流由在RTP会话内唯一的SSRC标识。RTP流可以被视为逻辑信道。
MPEG-2传输流(TS)(其在ISO/IEC 13818-1中或者相当于在ITU-T建议书H.222.0中指定)是用于在多路复用流中承载音频、视频和其它媒体以及节目元数据或其它元数据的格式。分组标识符(PID)用于标识TS内的基本流(又被称为分组化基本流)。因此,MPEG-2TS内的逻辑信道可以被视为对应于特定PID值。
视频编解码器由编码器和解码器组成,编码器将输入视频转换为适合于存储/传输的压缩后表示,解码器可以将压缩后视频表示解压缩回可查看形式。视频编码器和/或视频解码器还可以彼此分离,即,不需要形成编解码器。通常,编码器丢弃原始视频序列中的某些信息,以便以更紧凑的形式(即,以较低位速率)表示视频。视频编码器可以用于对如随后定义的图像序列进行编码,并且视频解码器可以用于对编码图像序列进行解码。视频编码器或视频编码器的帧内编码部分或图像编码器可以用于对图像进行编码,并且视频解码器或视频解码器的帧内解码部分或图像解码器可以用于对编码图像进行解码。
典型的混合视频编码器(例如ITU-T H.263和H.264的许多编码器实现)以两个阶段对视频信息进行编码。首先,例如通过运动补偿手段(发现并且指示密切对应于正在被编码的块的先前编码的视频帧之一中的区域)或者通过空间手段(以指定方式使用要被编码的块周围的像素值),预测某一图片区域(或“块”)中的像素值。其次,对预测误差(即,预测像素块与原始像素块之间的差异)进行编码。这通常通过以下操作完成:使用指定变换(例如离散余弦变换(DCT)或其变型)变换像素值的差异,量化系数并且对量化后的系数进行熵编码。通过改变量化过程的保真度,编码器可以控制像素表示的准确性(图片质量)与得到的编码视频表示的大小(文件大小或传输位速率)之间的平衡。
帧间预测(inter prediction,也可以被称为时间预测、运动补偿、或者运动补偿预测)减少时间冗余性。在帧间预测中,预测源是先前解码的图片。帧内预测(intraprediction)利用以下事实:同一图片内的相邻像素可能相关。可以在空间或变换域中执行帧内预测,即,可以预测样本值或变换系数。通常在不应用帧间预测的帧内编码中利用帧内预测。
编码程序的一个结果是一组编码参数,例如运动向量和量化后的变换系数。可以更有效地对许多参数进行熵编码,前提是首先从空间或时间相邻的参数预测这些参数。例如,可以从空间相邻的运动向量预测运动向量,并且仅对相对于运动向量预测器的差异进行编码。编码参数预测和帧内预测可以被统称为图片内预测。
图4示出适合于采用本发明实施例的视频编码器的框图。图4呈现用于两个层的编码器,但将认识到,呈现的编码器可以类似地简化为仅对一个层进行编码或者扩展为对两个以上的层进行编码。图4示出视频编码器的一个实施例,该视频编码器包括用于基础层的第一编码器部分500和用于增强层的第二编码器部分502。第一编码器部分500和第二编码器部分502的每一个可以包括用于对传入图片进行编码的类似元件。编码器部分500、502可以包括像素预测器302、402、预测误差编码器303、403以及预测误差解码器304、404。图4还将像素预测器302、402的实施例示为包括帧间预测器306、406、帧内预测器308、408、模式选择器310、410、滤波器316、416、以及参考帧存储器318、418。第一编码器部分500的像素预测器302接收300视频流的基础层图像,这些基础层图像要在帧间预测器306(其确定图像与运动补偿参考帧318之间的差异)和帧内预测器308(其仅基于当前帧或图片的已经处理的部分来确定图像块预测)处进行编码。将帧间预测器和帧内预测器两者的输出传递到模式选择器310。帧内预测器308可以具有多于一种的帧内预测模式。因此,每种模式可以执行帧内预测并将预测信号提供给模式选择器310。模式选择器310还接收基础层图片300的副本。相应地,第二编码器部分502的像素预测器402接收400视频流的增强层图像,这些增强层图像要在帧间预测器406(其确定图像与运动补偿参考帧418之间的差异)和帧内预测器408(其仅基于当前帧或图片的已经处理的部分来确定图像块预测)两者处进行编码。将帧间预测器和帧内预测器两者的输出传递到模式选择器410。帧内预测器408可以具有多于一种的帧内预测模式。因此,每种模式可以执行帧内预测并将预测信号提供给模式选择器410。模式选择器410还接收增强层图片400的副本。
取决于选择哪种编码模式对当前块进行编码,将帧间预测器306、406的输出、或者可选帧内预测器模式之一的输出、或者模式选择器内的表面编码器的输出被传递到模式选择器310、410的输出。将模式选择器的输出传递到第一求和设备321、421。第一求和设备可以从基础层图片300/增强层图片400中减去像素预测器302、402的输出以便产生第一预测误差信号320、420,第一预测误差信号320、420被输入到预测误差编码器303、403。
像素预测器302、402进一步从初步重构器339、439接收图像块的预测表示312、412与预测误差解码器304、404的输出338、438的组合。可以将初步重构图像314、414传递到帧内预测器308、408和滤波器316、416。接收初步表示的滤波器316、416可以对初步表示进行滤波并且输出最终重构图像340、440,最终重构图像340、440可以被保存在参考帧存储器318、418中。参考帧存储器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)。
第1版高效率视频编码(H.265/HEVC,又被称为HEVC)标准由VCEG和MPEG的联合协作组-视频编码(JCT-VC)开发。该标准由两个父标准化组织发布,并且被称为ITU-T建议书H.265和ISO/IEC国际标准23008-2,也被称为MPEG-H部分2高效率视频编码(HEVC)。第2版H.265/HEVC包括可伸缩、多视图和保真度范围扩展,它们可以分别缩写为SHVC、MV-HEVC和REXT。第2版H.265/HEVC被预发布为ITU-T建议书H.265(2014年10月),并且可能在2015年被发布为第2版ISO/IEC23008-2。存在目前正在进行的标准化项目以便进一步开发H.265/HEVC扩展,包括三维和屏幕内容编码扩展,它们可以分别缩写为3D-HEVC和SCC。
SHVC、MV-HEVC和3D-HEVC使用在第2版HEVC标准的附录F中指定的通用基础规范。该通用基础例如包括高级句法和语义,例如指定位流层的某些特性(例如层间依赖性);以及解码过程,例如参考图片列表结构,其包括用于多层位流的层间参考图片和图片顺序计数导出。附录F还可以用于HEVC的潜在后续多层扩展。将理解,尽管可以在下面参考特定扩展(例如SHVC和/或MV-HEVC)描述视频编码器、视频解码器、编码方法、解码方法、位流结构和/或实施例,它们通常也适用于HEVC的任何多层扩展,并且甚至更普遍地适用于任何多层视频编码方案。
在本小节中描述H.264/AVC和HEVC的某些关键定义、位流和编码结构、以及概念,作为其中可以实现各实施例的视频编码器、解码器、编码方法、解码方法、以及位流结构的一个示例。H.264/AVC的某些关键定义、位流和编码结构、以及概念与HEVC中相同—因此,下面共同描述它们。本发明的各个方面并不限于H.264/AVC或HEVC,而是针对一个可能的基础提供描述,在该基础之上可以部分或完整地实现本发明。
与许多较早的视频编码标准相似地,在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中,图片可以是帧或字段。帧包括亮度样本的矩阵,并且可能包括对应的色度样本。字段是帧的备用样本行集,并且当源信号交错时,字段可以用作编码器输入。色度样本阵列可能不存在(并且因此可能使用单色采样),或者当与亮度样本阵列相比时,色度样本阵列可能被二次采样。色度格式可以总结如下:
-在单色采样中,只有一个采样阵列,其名义上可以被视为亮度阵列。
-在4:2:0采样中,两个色度阵列的每一个具有亮度阵列的一半高度和一半宽度。
-在4:2:2采样中,两个色度阵列的每一个具有亮度阵列的相同高度和一半宽度。
-在4:4:4采样中,当没有使用单独颜色平面时,两个色度阵列的每一个具有与亮度阵列相同的高度和宽度。
在H.264/AVC和HEVC中,可以将样本阵列作为单独颜色平面编码到位流中,并且分别从位流对单独编码的颜色平面进行解码。当使用单独颜色平面时,它们的每一个作为具有单色采样的图片(由编码器和/或解码器)单独处理。
分区可以被定义为将集合分成子集,以使得集合的每个元素在仅一个子集中。
在H.264/AVC中,宏块是16×16亮度样本块和对应色度样本块。例如,在4:2:0采样模式中,宏块的每个色度分量包含一个8×8色度样本块。在H.264/AVC中,将图片划分为一个或多个分片(slice)组,并且分片组包含一个或多个分片。在H.264/AVC中,分片包括在特定分片组内的光栅扫描中连续排序的整数个宏块。
当描述HEVC编码和/或解码的操作时,可以使用下面术语。编码块可以被定义为某一值N的N×N样本块,以使得将编码树块分成编码块是分区。编码树块(CTB)可以被定义为某一值N的N×N样本块,以使得将分量分成编码树块是分区。编码树单元(CTU)可以被定义为亮度样本的编码树块、具有三个样本阵列的图片的色度样本的两个对应编码树块、或者单色图片或者使用三个单独颜色平面和句法结构(其用于对样本进行编码)进行编码的图片的样本的编码树块。编码单元(CU)可以被定义为亮度样本的编码块、具有三个样本阵列的图片的色度样本的两个对应编码块、或者单色图片或者使用三个单独颜色平面和句法结构(其用于对样本进行编码)进行编码的图片的样本的编码块。
在某些视频编解码器(例如高效率视频编码(HEVC)编解码器)中,将视频图片分成覆盖图片区域的编码单元(CU)。CU由一个或多个预测单元(PU)和一个或多个变换单元(TU)组成,PU针对CU内的样本定义预测过程,TU针对该CU内的样本定义预测误差编码过程。通常,CU由方形样本块组成,该样本块具有可从预定义的可能CU大小集中选择的大小。具有最大允许大小的CU可以被称为LCU(最大编码单元)或编码树单元(CTU),并且视频图片被分成非重叠LCU。可以例如通过递归地划分LCU和得到的CU,将LCU进一步分成更小CU的组合。每个产生的CU通常具有与其关联的至少一个PU和至少一个TU。可以将每个PU和TU进一步分成更小的PU和TU,以便分别增加预测和预测误差编码过程的粒度。每个PU具有与其关联的预测信息,该预测信息定义要针对该PU内的像素应用什么类型的预测(例如用于帧间预测PU的运动向量信息和用于帧内预测PU的帧内预测方向性信息)。
每个TU可以与以下信息关联:该信息描述用于该TU内的样本的预测误差解码过程(例如包括DCT系数信息)。通常在CU级别用信号通知是否针对每个CU应用预测误差编码。如果没有与CU关联的预测误差残余,则可以认为该CU没有TU。通常在位流中用信号通知将图像分成CU以及将CU分成PU和TU,从而允许解码器重新产生这些单元的预期结构。
在HEVC中,可以将图片划分为图块(tile),这些图块是矩形并且包含整数个LCU。在HEVC中,划分为图块将形成矩形网格,其中图块的高度和宽度不同于彼此,最多相差一个LCU。在HEVC中,分片被定义为在同一访问单元内,包含在一个独立分片段以及在下一个独立分片段(如果有)之前的所有后续相关分片段(如果有)中的整数个编码树单元。在HEVC中,分片段被定义为在图块扫描中连续排序并且包含在单个NAL单元中的整数个编码树单元。将每个图片分成分片段是分区。在HEVC中,独立分片段被定义为这样的分片段:不从前一个分片段的值推断该分片段的分片段标头的句法元素的值,并且相关分片段被定义为这样的分片段:以解码顺序,从前一个独立分片段的值推断该分片段的分片段标头的某些句法元素的值。在HEVC中,分片标头被定义为作为当前分片段或者作为在当前相关分片段之前的独立分片段的独立分片段的分片段标头,并且分片段标头被定义为包含有关在该分片段中表示的第一或所有编码树单元的数据元素的编码分片段的一部分。如果未使用图块,则以图块内或图片内的LCU的光栅扫描顺序扫描CU。在LCU内,CU具有特定的扫描顺序。
解码器通过应用类似于编码器的预测手段重构输出视频,以便形成像素块的预测表示(使用由编码器产生的并且以压缩表示存储的运动或空间信息)和预测误差解码(预测误差编码的逆操作,其恢复空间像素域中的量化预测误差信号)。在应用预测和预测误差解码手段之后,解码器计算预测和预测误差信号(像素值)的总和以便形成输出视频帧。解码器(和编码器)还可以应用额外滤波手段以便改进输出视频的质量,然后传递输出视频以便显示和/或存储输出视频作为视频序列中即将到来的帧的预测参考。
滤波可以例如包括以下一个或多个:解块、样本自适应偏移(SAO)和/或自适应环路滤波(ALF)。H.264/AVC包括解块,而HEVC包括解块和SAO两者。
在典型的视频编解码器中,使用与每个运动补偿图像块(例如预测单元)关联的运动向量指示运动信息。这些运动向量的每一个表示要编码(在编码器侧)或解码(在解码器侧)的图片中的图像块与先前一个编码或解码图片中的预测源块的位移。为了有效地表示运动向量,通常相对于块特定的预测运动向量有区别地对这些运动向量进行编码。在典型的视频编解码器中,以预定义方式(例如计算相邻块的编码或解码运动向量的中值)产生预测运动向量。产生运动向量预测的另一种方式是从时间参考图片中的相邻块和/或协同定位块生成候选预测列表,并且用信号通知选择的候选者作为运动向量预测器。除了预测运动向量值之外,还可以预测哪个(哪些)参考图片用于运动补偿预测,并且可以例如通过先前编码/解码的图片的参考索引表示该预测信息。通常从时间参考图片中的相邻块和/或协同定位块预测参考索引。此外,典型的高效率视频编解码器采用额外运动信息编码/解码机制,通常被称为合并/合并模式,其中在没有任何修改/纠正的情况下预测和使用所有运动字段信息,该信息包括每个可用参考图片列表的运动向量和对应的参考图片索引。同样,使用时间参考图片中的相邻块和/或协同定位块的运动字段信息执行预测运动字段信息,并且在填充可用相邻/协同定位块的运动字段信息的一系列运动字段候选列表中用信号通知使用的运动字段信息。
典型的视频编解码器能够使用单预测和双预测,在单预测中针对被编码(解码)的块使用单个预测块,在双预测中组合两个预测块以便形成被编码(解码)的块的预测。某些视频编解码器实现加权预测,其中在添加残余信息之前对预测块的样本值进行加权。例如,可以应用乘法加权因子和加法偏移。在通过某些视频编解码器实现的显式加权预测中,加权因子和偏移可以例如在每个可允许的参考图片索引的分片标头中进行编码。在通过某些视频编解码器实现的隐式加权预测中,加权因子和/或偏移不进行编码,而是例如基于参考图片的相对图片顺序计数(POC)距离被导出。
在典型的视频编解码器中,首先使用变换核(如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中加入仿真预防字节。原始字节序列有效负载(RBSP)可以被定义为这样的句法结构:其包含封装在NAL单元中的整数个字节。RBSP为空或者具有数据位串的形式,该数据位串包含句法元素后跟RBSP停止位并且后跟零个或更多个等于0的后续位。
NAL单元由标头和有效负载组成。在H.264/AVC和HEVC中,NAL单元标头指示NAL单元的类型。
H.264/AVC NAL单元标头包括2位nal_ref_idc句法元素,该句法元素当等于0时,指示包含在NAL单元中的编码分片是非参考图片的一部分,并且当大于0时,指示包含在NAL单元中的编码分片是参考图片的一部分。SVC和MVC NAL单元的标头可以额外地包含与可伸缩性和多视图层次结构相关的各种指示。在HEVC中,两字节NAL单元标头用于所有指定的NAL单元类型。NAL单元标头包含一个保留位、一个六位NAL单元类型指示、一个用于时间级别的三位nuh_temporal_id_plus1指示(可能需要大于或等于1)以及一个六位nuh_layer_id句法元素。temporal_id_plus1句法元素可以被视为NAL单元的时间标识符,并且可以按照以下方式导出基于0的TemporalId变量:TemporalId=temporal_id_plus1-1。等于0的TemporalId对应于最低时间级别。为了避免涉及两个NAL单元标头字节的起始代码仿真,需要temporal_id_plus1的值为非0。通过以下操作产生的位流仍保持一致:不包括具有大于或等于选定值的TemporalId的所有VCL NAL单元,并且包括所有其它VCL NAL单元。因此,具有等于TID的TemporalId的图片不使用具有大于TID的TemporalId的任何图片作为帧间预测参考。子层或时间子层可以被定义为时间可伸缩位流的时间可伸缩层,其由具有TemporalId变量的特定值的VCL NAL单元和关联的非VCL NAL单元组成。nuh_layer_id可以被理解为可伸缩性层标识符。
NAL单元可以被分类为视频编码层(VCL)NAL单元和非VCL NAL单元。VCL NAL单元通常是编码分片NAL单元。在H.264/AVC中,编码分片NAL单元包含表示一个或多个编码宏块的句法元素,每个编码宏块对应于未压缩图片中的样本块。在HEVC中,VCL NAL单元包含表示一个或多个CU的句法元素。
在H.264/AVC中,编码分片NAL单元可以被指示为瞬时解码刷新(IDR)图片中的编码分片或非IDR图片中的编码分片。
在HEVC中,编码分片NAL单元可以被指示为以下类型之一:
在HEVC中,可以按照以下方式定义图片类型的缩写:尾随(TRAIL)图片、时间子层访问(TSA)、逐步时间子层访问(STSA)、随机访问可解码前导(RADL)图片、随机访问跳过前导(RASL)图片、断开链接访问(BLA)图片、瞬时解码刷新(IDR)图片、清洁随机访问(CRA)图片。
随机访问点(RAP)图片也可以被称为内部随机访问点(IRAP)图片,其是这样的图片:其中每个分片或分片段具有在16到23的范围(包括边界)内的nal_unit_type。独立层中的IRAP图片仅包含帧内编码的分片。属于nuh_layer_id值为currLayerId的预测层的IRAP图片可以包含P、B和I分片,不能使用来自nuh_layer_id等于currLayerId的其它图片的帧间预测,并且可以使用来自其直接参考层的层间预测。在当前版本的HEVC中,IRAP图片可以是BLA图片、CRA图片或IDR图片。包含基础层的位流中的第一图片是基础层处的IRAP图片。如果必要参数集在需要被激活时可用,则可以对独立层处的IRAP图片和以解码顺序在独立层处的所有后续非RASL图片进行正确解码,而无需执行以解码顺序在IRAP图片之前的任何图片的解码过程。当必要参数集在需要被激活的情况下可用时,并且当nuh_layer_id等于currLayerId的层的每个直接参考层的解码已被初始化时(即,当针对与nuh_layer_id等于currLayerId的层的直接参考层的所有nuh_layer_id值相等的refLayerId,LayerInitializedFlag[refLayerId]等于1时),可以对属于nuh_layer_id值为currLayerId的预测层的IRAP图片和以解码顺序的nuh_layer_id等于currLayerId的所有后续非RASL图片进行正确解码,而无需执行以解码顺序在IRAP图片之前的nuh_layer_id等于currLayerId的任何图片的解码过程。位流中可能具有这样的图片:其仅包含不是IRAP图片的帧内编码的分片。
在HEVC中,CRA图片可以是位流中以解码顺序的第一图片,或者可以在位流中稍后出现。HEVC中的CRA图片允许所谓的前导图片,这些前导图片以解码顺序在CRA图片之后但以输出顺序在CRA图片之前。某些前导图片(所谓的RASL图片)可以使用在CRA图片之前解码的图片作为参考。如果在CRA图片处执行随机访问,则以解码和输出顺序在CRA图片之后的图片是可解码的,并且因此实现洁净随机访问,类似于IDR图片的洁净随机访问功能。
CRA图片可以具有关联的RADL或RASL图片。当CRA图片是位流中以解码顺序的第一图片时,CRA图片是以解码顺序的编码视频序列的第一图片,并且任何关联的RASL图片未由解码器输出而且可能不可解码,因为它们可能包含对位流中不存在的图片的参考。
前导图片是以输出顺序在关联的RAP图片之前的图片。关联的RAP图片是以解码顺序的前一个RAP图片(如果存在)。前导图片是RADL图片或RASL图片。
所有RASL图片是关联的BLA或CRA图片的前导图片。当关联的RAP图片是BLA图片或者是位流中的第一编码图片时,RASL图片未被输出并且可能未被正确解码,因为RASL图片可能包含对位流中不存在的图片的参考。但是,如果已从RASL图片的关联RAP图片之前的RAP图片开始解码,则能够对RASL图片进行正确解码。RASL图片未被用作非RASL图片的解码过程的参考图片。当存在时,所有RASL图片以解码顺序在同一关联的RAP图片的所有尾随图片之前。在某些HEVC标准草案中,RASL图片被称为“标记为丢弃(TFD)”图片。
所有RADL图片都是前导图片。RADL图片未被用作相同关联的RAP图片的尾随图片的解码过程的参考图片。当存在时,所有RADL图片以解码顺序在同一关联的RAP图片的所有尾随图片之前。RADL图片未参考以解码顺序在关联的RAP图片之前的任何图片,并且因此当从关联的RAP图片开始解码时,能够对RADL图片进行正确解码。在某些HEVC标准草案中,RADL图片被称为“可解码前导图片(DLP)”。
当从CRA图片开始的位流的一部分被包括在另一个位流中时,与该CRA图片关联的RASL图片可能不可正确解码,因为它们的某些参考图片可能不存在于组合后的位流中。为使这种分片操作简单,可以改变CRA图片的NAL单元类型以便指示它是BLA图片。与BLA图片关联的RASL图片可能不可正确解码,因此不会被输出/显示。此外,与BLA图片关联的RASL图片可以从解码中省略。
BLA图片可以是位流中以解码顺序的第一图片,或者可以在位流中稍后出现。每个BLA图片开始新的编码视频序列,并且对解码过程具有与IDR图片类似的影响。但是,BLA图片包含指定非空参考图片集的句法元素。当BLA图片具有等于BLA_W_LP的nal_unit_type时,它可能具有关联的RASL图片,这些RASL图片未由解码器输出并且可能不可解码,因为它们可能包含对位流中不存在的图片的参考。当BLA图片具有等于BLA_W_LP的nal_unit_type时,它还可能具有关联的RADL图片,这些RADL图片被指定为待解码。当BLA图片具有等于BLA_W_DLP的nal_unit_type时,它没有关联的RASL图片但可能具有关联的RADL图片,这些RADL图片被指定为待解码。当BLA图片具有等于BLA_N_LP的nal_unit_type时,它没有任何关联的前导图片。
nal_unit_type等于IDR_N_LP的IDR图片没有存在于位流中的关联前导图片。nal_unit_type等于IDR_W_LP的IDR图片没有存在于位流中的关联RASL图片,但可能在位流中具有关联的RADL图片。
当nal_unit_type的值等于TRAIL_N、TSA_N、STSA_N、RADL_N、RASL_N、RSV_VCL_N10、RSV_VCL_N12或RSV_VCL_N14时,解码图像未被用作同一时间子层的任何其它图片的参考。即,在HEVC中,当nal_unit_type的值等于TRAIL_N、TSA_N、STSA_N、RADL_N、RASL_N、RSV_VCL_N10、RSV_VCL_N12或RSV_VCL_N14时,解码图片未被包括在具有相同TemporalId值的任何图片的RefPicSetStCurrBefore、RefPicSetStCurrAfter和RefPicSetLtCurr的任何一个中。nal_unit_type等于TRAIL_N、TSA_N、STSA_N、RADL_N、RASL_N、RSV_VCL_N10、RSV_VCL_N12或RSV_VCL_N14的编码图片可以被丢弃,而不影响具有相同TemporalId值的其它图片的可解码性。
尾随图片可以被定义为以输出顺序在关联的RAP图片之后的图片。作为尾随图片的任何图片都没有等于RADL_N、RADL_R、RASL_N或RASL_R的nal_unit_type。作为前导图片的任何图片可以被限制为以解码顺序在与同一RAP图片关联的所有尾随图片之前。在位流中不存在这样的RASL图片:这些图片与nal_unit_type等于BLA_W_DLP或BLA_N_LP的BLA图片关联。在位流中不存在这样的RADL图片:这些图片与nal_unit_type等于BLA_N_LP的BLA图片关联,或者与nal_unit_type等于IDR_N_LP的IDR图片关联。与CRA或BLA图片关联的任何RASL图片可以被限制为以输出顺序在与CRA或BLA图片关联的任何RADL图片之前。与CRA图片关联的任何RASL图片可以被限制为以输出顺序在任何其它RAP图片(它们以解码顺序在该CRA图片之前)之后。
在HEVC中,具有两种图片类型,即TSA和STSA图片类型,它们可以用于指示时间子层切换点。如果已在TSA或STSA图片之前(不包括这两个图片)对TemporalId一直到N的时间子层进行解码,并且TSA或STSA图片具有等于N+1的TemporalId,则TSA或STSA图片使能TemporalId等于N+1的所有后续图片(以解码顺序)的解码。TSA图片类型可以对TSA图片本身和以解码顺序在该TSA图片之后的同一子层中的所有图片施加限制。不允许这些图片使用来自以解码顺序在TSA图片之前的同一子层中的任何图片的帧间预测。TSA定义可以进一步对以解码顺序在TSA图片之后的较高子层中的图片施加限制。不允许这些图片参考以解码顺序在TSA图片之前的图片,前提是该图片属于与TSA图片相同或更高的子层。TSA图片具有大于0的TemporalId。STSA类似于TSA图片,但不对以解码顺序在STSA图片之后的较高子层中的图片施加限制,并且因此仅允许向上切换到STSA图片所在的子层。
非VCL NAL单元可以例如是以下类型之一:序列参数集、图片参数集、补充增强信息(SEI)NAL单元、访问单元分隔符、序列NAL单元的结尾、位流NAL单元的结尾、或者填充符数据NAL单元。重构解码图片可能需要参数集,而许多其它非VCL NAL单元对于重构解码样本值不是必需的。
通过编码视频序列保持不变的参数可以被包括在序列参数集中。除了解码过程可能需要的参数之外,序列参数集可以可选地包含视频可用性信息(VUI),该信息包括可以对于缓冲、图像输出定时、呈现、以及资源预留而言重要的参数。在H.264/AVC中指定三个NAL单元来承载序列参数集:包含序列中H.264/AVC VCL NAL单元的所有数据的序列参数集NAL单元、包含辅助编码图片的数据的序列参数集扩展NAL单元、以及MVC和SVC VCL NAL单元的子集序列参数集。在HEVC中,序列参数集RBSP包括可以由以下各项参考的参数:一个或多个图片参数集RBSP、或者包含缓冲周期SEI消息的一个或多个SEI NAL单元。图片参数集包含可能在数个编码图片中不变的参数。图片参数集RBSP可以包括可以由一个或多个编码图片的编码分片NAL单元参考的参数。
在HEVC中,视频参数集(VPS)可以被定义为这样的句法结构:其包含应用于0个或更多个完整编码视频序列的句法元素,这些编码视频序列如由在某一句法元素(其由在每个分片段标头中发现的句法元素参考的PPS中发现)参考的SPS中发现的句法元素的内容确定。
视频参数集RBSP可以包括能够由一个或多个序列参数集RBSP参考的参数。
可以按照以下方式描述视频参数集(VPS)、序列参数集(SPS)以及图片参数集(PPS)之间的关系和层次结构。在参数集层次结构中以及在可伸缩性和/或3D视频的上下文中,VPS比SPS高一个级别。VPS可以包括这样的参数:它们通用于整个编码视频序列中跨所有(可伸缩性或视图)层的所有分片。SPS包括这样的参数:它们通用于整个编码视频序列中特定(可伸缩性或视图)层中的所有分片,并且可以由多个(可伸缩性或视图)层共享。PPS包括这样的参数:它们通用于特定层表示(一个访问单元中的一个可伸缩性或视图层的表示)中的所有分片,并且可能由多个层表示中的所有分片共享。
VPS可以提供有关位流中的层的依赖关系的信息,以及适用于整个编码视频序列中跨所有(可伸缩性或视图)层的所有分片的许多其它信息。VPS可以被视为包括两个部分,即基础VPS和VPS扩展,其中VPS扩展可以可选地存在。在HEVC中,基础VPS可以被视为包括没有vps_extension()句法结构的video_parameter_set_rbsp()句法结构。video_parameter_set_rbsp()句法结构已经主要针对HEVC版本1指定,并且包括可以用于基础层解码的句法元素。在HEVC中,VPS扩展可以被视为包括vps_extension()句法结构。vps_extension()句法结构主要针对多层扩展在HEVC版本2中指定,并且包括可以用于对一个或多个非基础层进行解码的句法元素,例如指示层依赖关系的句法元素。
H.264/AVC和HEVC句法允许参数集的许多实例,并且使用唯一标识符标识每个实例。为了限制参数集需要的内存使用,参数集标识符的值范围已被限制。在H.264/AVC和HEVC中,每个分片标头包括用于对包含分片的图片进行解码的活动图片参数集的标识符,并且每个图片参数集包含活动序列参数集的标识符。因此,图片和序列参数集的传输不必与分片的传输准确同步。而是,在活动序列和图片参数集被参考之前的任意时刻接收它们便已足够,这允许使用比用于分片数据的协议更可靠的传输机制来“带外”传输参数集。例如,参数集可以作为参数被包括在实时传输协议(RTP)会话的会话描述中。如果带内传输参数集,则可以重复它们以便改进误差鲁棒性。
此外或备选地,带外传输、信令或存储可以用于容忍传输误差之外的其它目的,例如易于访问或会话协商。例如,符合ISO基础媒体文件格式的文件中的轨道的样本条目可以包括参数集,而位流中的编码数据被存储在文件的其它位置或另一个文件中。短语“沿着位流”(例如沿着位流指示)可以在权利要求和所述实施例中用于以带外数据被与位流关联的方式来参考带外传输、信令或存储。短语“沿着位流进行解码”等可以指对与位流关联的所参考带外数据(其可以从带外传输、信令或存储获得)进行解码。
可以通过参考激活参数集,该参考来自分片或者来自另一个活动参数集,或者在某些情况下,来自诸如缓冲周期SEI消息之类的另一个句法结构。
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单元关联。
编码图片是图片的编码表示。H.264/AVC中的编码图片包括对该图片进行解码需要的VCL NAL单元。在H.264/AVC中,编码图片可以是主要编码图片或冗余编码图片。主要编码图片用于有效位流的解码过程,而冗余编码图片是冗余表示,仅当主要编码图片不能成功被解码时才应对该冗余表示进行解码。在HEVC中,未指定冗余编码图片。
在H.264/AVC中,访问单元(AU)包括主要编码图片和与其关联的那些NAL单元。在H.264/AVC中,按照以下方式限制NAL单元在访问单元内的出现顺序。可选访问单元分隔符NAL单元可以指示访问单元的开始。它后跟0个或更多个SEI NAL单元。接下来出现主要编码图片的编码分片。在H.264/AVC中,主要编码图片的编码分片可以后跟0个或更多个冗余编码图片的编码分片。冗余编码图片是图片或图片一部分的编码表示。如果例如由于传输损失或者物理存储介质损坏,解码器未接收到主要编码图片,则可以对冗余编码图片进行解码。
在H.264/AVC中,访问单元还可以包括辅助编码图片,它是补充主要编码图片的图片,并且可以例如用于显示过程。辅助编码图片可以例如被用作指定解码图片中样本的透明度级别的阿尔法通道或阿尔法平面。阿尔法通道或平面可以用于分层组成或呈现系统,其中输出图片通过在彼此之上叠加至少部分透明的图片而形成。辅助编码图片具有与单色冗余编码图片相同的句法和语义限制。在H.264/AVC中,辅助编码图片包含与主要编码图片相同数量的宏块。
在HEVC中,编码图片可以被定义为图片的编码表示,所述编码表示包含该图片的所有编码树单元。在HEVC中,访问单元(AU)可以被定义为NAL单元集,这些NAL单元根据指定的分类规则彼此关联,以解码顺序连续,并且最多包含一个具有任何特定nuh_layer_id值的图片。除了包含编码图片的VCL NAL单元之外,访问单元还可以包含非VCL NAL单元。
可能需要编码图片在访问单元内以某一顺序出现。例如,在同一访问单元中,可能需要nuh_layer_id等于nuhLayerIdA的编码图片以解码顺序在nuh_layer_id大于nuhLayerIdA的所有编码图片之前。
在HEVC中,图片单元可以被定义为包含编码图片的所有VCL NAL单元及其关联的非VCL NAL单元的NAL单元集。非VCL NAL单元的关联VCL NAL单元可以被定义为某些类型非VCL NAL单元以解码顺序的非VCL NAL单元的前一个VCL NAL单元、以及其它类型非VCL NAL单元以解码顺序的非VCL NAL单元的下一个VCL NAL单元。VCL NAL单元的关联非VCL NAL单元可以被定义为这样的非VCL NAL单元:对于其而言,VCL NAL单元是关联的VCL NAL单元。例如,在HEVC中,关联的VCL NAL单元可以被定义为nal_unit_type等于EOS_NUT、EOB_NUT、FD_NUT或SUFFIX_SEI_NUT、或者在RSV_NVCL45..RSV_NVCL47或UNSPEC56..UNSPEC63范围内的非VCL NAL单元以解码顺序的前一个VCL NAL单元;或者,以其他方式是以解码顺序的下一个VCL NAL单元。
位流可以被定义为NAL单元流或字节流形式的位序列,其形成包括一个或多个编码视频序列的编码图片和关联数据的表示。在同一逻辑信道中(例如在同一文件中或者在同一通信协议连接中),第一位流可以后跟第二位流。基本流(在视频编码的上下文中)可以被定义为一个或多个位流的序列。第一位流的结尾可以由特定NAL单元指示,该特定NAL单元可以被称为位流结尾(EOB)NAL单元并且是位流的最后一个NAL单元。在HEVC及其当前草案扩展中,需要EOB NAL单元以使nuh_layer_id等于0。
在H.264/AVC中,编码视频序列被定义为以解码顺序的连续访问单元序列,其从IDR访问单元(包括该访问单元)到下一个IDR访问单元(不包括该访问单元)或者到位流结尾(以较早出现者为准)。
在HEVC中,编码视频序列(CVS)可以例如被定义为以解码顺序由以下各项组成的访问单元序列:NoRaslOutputFlag等于1的IRAP访问单元,后跟不是NoRaslOutputFlag等于1的IRAP访问单元的0个或更多个访问单元,包括所有后续访问单元直到但不包括作为NoRaslOutputFlag等于1的IRAP访问单元的任何后续访问单元。IRAP访问单元可以被定义为其中基础层图片是IRAP图片的访问单元。对于每个IDR图片、每个BLA图片,NoRaslOutputFlag的值等于1,并且每个IRAP图片(其是位流中的该特定层中以解码顺序的第一个图片)是以解码顺序在具有相同nuh_layer_id值的序列NAL单元的结尾之后的第一个IRAP图片。在多层HEVC中,对于每个IRAP图片,当其nuh_layer_id如此以使得LayerInitializedFlag[nuh_layer_id]等于0并且LayerInitializedFlag[refLayerId]等于1(对于等于IdDirectRefLayer[nuh_layer_id][j]的所有refLayerId值)时,NoRaslOutputFlag的值等于1,其中j的范围是0到NumDirectRefLayers[nuh_layer_id]–1(包括这两个值)。否则,NoRaslOutputFlag的值等于HandleCraAsBlaFlag。NoRaslOutputFlag等于1具有以下影响:与针对其设置NoRaslOutputFlag的IRAP图片关联的RASL图片不由解码器输出。可以采取某种手段以便从外部实体(例如播放器或接收器,其可以控制解码器)向解码器提供HandleCraAsBlaFlag的值。HandleCraAsBlaFlag可以例如由播放器设置为1,该播放器寻址到位流中的新位置,或者调谐到广播中并且开始解码,然后从CRA图片开始解码。对于CRA图片,当HandleCraAsBlaFlag等于1时,CRA图片被处理和解码,犹如它是BLA图片。
在HEVC中,当特定NAL单元(其可以被称为序列结尾(EOS)NAL单元)出现在位流中并且nuh_layer_id等于0时,编码视频序列可以额外地或备选地(符合上面规范)被指定为结束。
在HEVC中,编码视频序列组(CVSG)可以例如被定义为以解码顺序的一个或多个连续CVS,这些连续CVS共同由以下各项组成:激活尚未活动的VPS RBSP firstVpsRbsp的IRAP访问单元,后跟以解码顺序的所有后续访问单元(针对这些访问单元,firstVpsRbsp是活动VPS RBSP),直到位流结尾或者直到但不包括激活不同于firstVpsRbsp的VPS RBSP的访问单元(以解码顺序的较早者为准)。
图片结构(SOP)可以被定义为以解码顺序连续的一个或多个编码图片,其中以解码顺序的第一编码图片是最低时间子层处的参考图片,并且可能除了以解码顺序的第一编码图片之外的编码图片都不是RAP图片。前一个SOP中的所有图片以解码顺序在当前SOP中的所有图片之前,并且下一个SOP中的所有图片以解码顺序在当前SOP中的所有图片之后。SOP可以表示分层和重复的帧间预测结构。术语图片组(GOP)有时可以与术语SOP互换使用,并且具有与SOP的语义相同的语义。
H.264/AVC和HEVC的位流句法指示特定图片是否是用于任何其它图片的帧间预测的参考图片。在H.264/AVC和HEVC中,任何编码类型(I、P、B)的图片都能够是参考图片或非参考图片。
统一资源标识符(URI)可以被定义为用于标识资源名称的字符串。此类标识使能使用特定协议通过网络与资源的表示进行交互。通过指定用于URI的具体句法和关联协议的方案来定义URI。统一资源定位符(URL)和统一资源名称(URN)是URI的多种形式。URL可以被定义为这样的URI:其标识Web资源,并且指定操作或获得资源的表示、指定其主要访问机制和网络位置的手段。URN可以被定义为在特定命名空间中通过名称标识资源的URI。URN可以用于标识资源而不暗示其位置或如何访问它。
ISO/IEC国际标准23009-1指定HTTP动态自适应流(DASH)。下面描述MPEG-DASH的某些概念、格式和操作作为其中可以实现实施例的视频流系统的一个示例。本发明的各方面并不限于MPEG-DASH,而是针对一个可能的基础提供描述,在该基础之上可以部分或完整实现本发明。
在HTTP动态自适应流(DASH)中,多媒体内容可以被捕获和存储在HTTP服务器上,并且可以使用HTTP被传送。内容可以以两个部分存储在服务器上:媒体呈现描述(MPD),其描述可用内容清单、其各种替代物、其URL地址和其它特性;以及段,其包含单个或多个文件中的块形式的实际多媒体位流。为了播放内容,DASH客户机可以例如通过使用HTTP、电子邮件、拇指驱动器、广播或其它传输方法来获得MPD。通过解析MPD,DASH客户机可以知晓程序定时、媒体内容可用性、媒体类型、分辨率、最小和最大带宽、以及存在多媒体分量、可访问特性和所需数字权限管理(DRM)、网络上的媒体分量位置以及其它内容特性的各种编码替代物。使用该信息,DASH客户机可以选择适当的编码替代物,并且通过使用例如HTTP GET请求取回段来开始流化内容。在适当缓冲以考虑网络吞吐量变化之后,客户机可以继续取回后续段并且还监视网络带宽波动。客户机可以通过取回不同替代物(具有较低或较高位速率)的段以便维护适当缓冲区来决定如何适应可用带宽。
媒体呈现描述(MPD)可以针对客户机提供信息以便建立HTTP动态自适应流。MPD可以包含描述媒体呈现的信息,例如每个段的HTTP统一资源定位符(URL)以便发出GET段请求。在DASH中,可以使用分层数据模型构造媒体呈现,如图6中所示。媒体呈现可以包括具有一个或多个周期的序列,每个周期可以包含一个或多个组,每个组可以包含一个或多个适应集,每个适应集可以包含一个或多个表示,并且每个表示可以包括一个或多个段。表示是媒体内容或其子集的替代选择之一,其通常由于编码选择(例如由于位速率、分辨率、语言、编解码器等)而有所不同。段可以包含媒体数据的某一持续时间、以及用于对包括的媒体内容进行解码和呈现的元数据。段可以由统一资源指示符(URI)标识,并且可以通过HTTP GET请求进行请求。段可以被定义为这样的数据单元:其与由MPD指定的HTTP-URL关联,并且可选地与由MPD指定的字节范围关联。
类似于MPEG-DASH的流系统例如包括HTTP实时流(又称为HLS),其在IETF因特网草案draft-pantos-http-live-streaming-13(和同一因特网草案的其它版本)中指定。作为对应于MPD的清单格式,HLS使用扩展后的M3U格式。M3U是用于多媒体播放列表的文件格式,最初针对音频文件而开发。M3U播放列表是由单独行组成的文本文件,并且每个行是URI、为空或者以指示标记或注释的字符“#”开始。URI行标识媒体段或播放列表文件。标记以#EXT开始。HLS规范指定多个标记,这些标记可以被视为键-值对。标记的值部分可以包括属性列表,其是属性-值对的逗号分隔列表,其中属性-值对可以被视为具有句法AttributeName=AttributeValue。因此,HLS M3U8文件的标记可以被视为类似于MPD或XML中的元素,并且HLS M3U8文件的属性可以被视为类似于MPD或XML中的属性。HLS中的媒体段根据MPEG-2传输流进行格式化,并且包含单个MPEG-2程序。每个媒体段被建议以程序关联表(PAT)和程序映射表(PMT)开始。
容器文件可以包含内容,例如媒体数据、以及与内容相关的元数据。容器文件可以用于标识不同数据类型并且使这些数据类型交错。多媒体容器文件可以例如包含音频、视频和图像。多媒体容器文件可以用作多媒体内容产生、操纵、传输和消耗链中使用的元素。在编码格式(也被称为基本流格式或位流格式)与容器文件格式之间可能存在实质性差异。编码格式可以涉及将内容信息编码到位流中的特定编码或压缩算法的动作。容器文件格式(其也可以被称为媒体文件格式)可以指定用于组织所生成的一个或多个位流的句法和语义,以使得其可以例如被访问以便本地解码和重放、作为文件传输或流化,它们全部使用多种存储和传输架构。此外,文件格式可以促进媒体的交换和编辑、以及将接收的实时流记录到文件。
可用的媒体文件格式标准包括ISO基础媒体文件格式(ISO/IEC14496-12,其可以缩写为ISOBMFF)以及从ISOBMFF派生的标准,例如MPEG-4文件格式(ISO/IEC 14496-14,也被称为MP4格式)、用于NAL单元结构化视频的文件格式(ISO/IEC 14496-15)以及3GPP文件格式(3GPP TS 26.244,也被称为3GP格式)。ISO/IEC 14496-15指定H.264/AVC和/或HEVC和/或其扩展的位流在ISOBMFF兼容文件中的存储。提及的文件格式(包括ISO文件格式本身)以及从ISOBMFF派生的其它文件格式可以被称为ISO文件格式族。
下面描述ISOBMFF的某些概念、结构和规范作为容器文件格式(基于其可以实现各实施例)的一个示例。本发明的各个方面并不限于ISOBMFF,而是针对一个可能的基础提供描述,在该基础之上可以部分或完整实现本发明。
ISO基础媒体文件格式中的基本构件块被称为盒(box)。每个盒具有标头和有效负载。盒标头指示盒的类型和盒的大小(以字节为单位)。盒可以包含其它盒,并且ISO文件格式指定在某一类型的盒内允许哪些盒类型。此外,在每个文件中某些盒的存在可能是强制的,而其它盒的存在可能是可选的。此外,对于某些盒类型,可以允许文件中存在多于一个盒。因此,ISO基础媒体文件格式可以被视为指定盒的分层结构。
根据ISO文件格式族,文件包括被封装到盒中的媒体数据和元数据。每个盒可以由四字符代码(4CC,四CC)标识。四字符代码可以互换地由32位无符号整数表示(通过假设字符到8位值的某一转换、某一位字节顺序、以及某一字节的字节顺序)。标头可以提供有关盒的类型和大小的信息。在图5中示出ISOBMFF盒结构的一个示例包含层次结构。
根据ISO文件格式族,文件可以包括媒体数据和元数据,它们可以被包含在单独盒中。在一个示例实施例中,可以在媒体数据(mdat)盒中提供媒体数据,并且可以使用电影(moov)盒包含元数据。在某些情况下,为了使文件可操作,必须存在mdat和moov盒两者。电影(moov)盒可以包括一个或多个轨道,并且每个轨道可以驻留在一个对应的轨道(trak)盒中。每个轨道的数据可以被视为是逻辑通道。每个轨道与处理机关联,该处理机由四字符代码标识、指定轨道类型。视频、音频、以及图像序列轨道可以被统称为媒体轨道,并且它们包含基本媒体流。其它轨道类型包括提示轨道和定时元数据轨道。轨道包括样本,例如音频或视频帧。媒体轨道指根据媒体压缩格式(以及其到ISO基础媒体文件格式的封装)格式化的样本(其也可以被称为媒体样本)。提示轨道指提示样本,其包含用于构造分组以便通过指示的通信协议传输的简明手册说明(cookbook instruction)。简明手册说明可以包括分组标头构造的指导,并且可以包括分组有效负载构造。在分组有效负载构造中,可以参考驻留在其它轨道或项中的数据。因此,例如,驻留在其它轨道或项中的数据可以通过参考指示,该参考关于特定轨道或项中的哪个数据块被指示在分组构造过程中被复制到分组中。定时元数据轨道可以指描述被参考媒体和/或提示样本的样本。为了呈现一种媒体类型,可以选择一个媒体轨道。轨道的样本可以隐式地与样本编号关联,这些样本编号可以例如以指示的样本解码顺序递增1。轨道中的第一个样本可以与样本编号1关联。
可以按照以下方式描述根据ISO基础媒体文件格式的简化文件结构的一个示例。文件可以包括“moov”盒和“mdat”盒,并且“moov”盒可以包括分别对应于视频和音频的一个或多个轨道。
根据ISO基础媒体文件格式而格式化的许多文件以文件类型盒(也被称为ftyp盒)开始。ftyp盒包含标记文件的品牌的信息。ftyp盒包括一个主要品牌指示和兼容品牌列表。主要品牌标识要用于解析文件的最合适的文件格式规范。兼容品牌指示文件符合哪些文件格式规范和/或一致性点。文件可以符合多个规范。应该列出指示与这些规范的兼容性的所有品牌,以使得仅了解兼容品牌子集的读者可以获得文件能够被解析的指示。兼容品牌还可以针对特定文件格式规范的文件解析器提供权限,以便处理在ftyp盒中包含相同的特定文件格式品牌的文件。文件播放器可以检查文件的ftyp盒是否包括其支持的品牌,并且仅当文件播放器支持的任何文件格式规范在兼容品牌中被列出时,才可以解析和播放该文件。
符合ISOBMFF的文件可以在元盒(四CC:“meta”)中包含任何非定时对象,这些非定时对象被称为项、元项或元数据项。尽管元盒的名称指元数据,但项通常可以包含元数据或媒体数据。元盒可以驻留在文件的顶层、在电影盒(四CC:“moov”)内、以及在轨道盒(四CC:“trak”)内,但在文件级别、电影级别或轨道级别的每一个处最多可以出现一个元盒。元盒可能需要包含“hdlr”盒,“hdlr”盒指示“meta”盒内容的结构或格式。元盒可以列出和表征能够被参考的任何数量的项,并且它们的每一个可以与文件名称关联,而且通过是整数值的项标识符(item_id)使用文件唯一地标识。元数据项可以例如存储在元盒的“idat”盒中或者“mdat”盒中或者驻留在单独文件中。如果元数据位于文件外部,则其位置可以由DataInformationBox(四CC:“dinf”)声明。在元数据使用XML句法被格式化并且需要直接存储在MetaBox中的特定情况下,元数据可以被封装到XMLBox(四CC:“xml”)或BinaryXMLBox(四cc:“bxml”)中。项可以被存储为连续字节范围,或者它可以被存储在数个区段(extent)中,每个区段是连续字节范围。换言之,项可以被分段存储到区段中,例如以便使能交错。区段是资源字节的连续子集;资源可以通过串接区段而形成。
为了在层次结构的任何级别(文件、电影或轨道)支持多于一个元盒,可以使用元盒容器盒(“meco”)作为一种ISO基础媒体文件格式。元盒容器盒可以在层次结构的任何级别(文件、电影或轨道)承载任何数量的附加元盒。这可以允许例如相同元数据被呈现在两个不同的替代元数据系统中。元盒关系盒(“mere”)可以使能描述不同元盒如何彼此相关,例如它们是否包含完全相同的元数据(但使用不同方案描述),或者一个元盒是否表示另一个元盒的超集。
ISO基础媒体文件格式并不限制呈现要被包含在一个文件中。因此,呈现可以被包括在数个文件中。作为一个示例,一个文件可以包括整个呈现的元数据,并且从而可以包括所有媒体数据以使呈现自包含(self-contained)。其它文件(如果被使用)可能不需要被格式化为ISO基础媒体文件格式、可以用于包括媒体数据,并且还可以包括未使用的媒体数据或其它信息。ISO基础媒体文件格式仅涉及呈现文件的结构。媒体数据文件的格式可以仅受到ISO基础媒体文件格式或其派生格式的约束,因为媒体文件中的媒体数据如ISO基础媒体文件格式或其派生格式中指定的那样被格式化。
可以通过数据参考实现参考外部文件的能力。在某些示例中,包括在每个轨道中的样本描述“stsd”盒可以提供样本条目列表,每个样本条目提供有关使用的编码类型的详细信息、以及该编码需要的任何初始化信息。大块(chunk)的所有样本和轨道片段的所有样本可以使用相同的样本条目。大块可以被定义为一个轨道的连续样本集。数据参考“dref”盒(也包括在每个轨道中)可以定义统一资源定位符(URL)、统一资源名称(URN)和/或包含元数据的文件的自参考的索引列表。样本条目可以指向数据参考盒的一个索引,从而指示包含相应大块或轨道片段的样本的文件。
当将内容记录到ISO文件时,可以使用电影片段,以便如果发生记录应用崩溃、存储空间用完或某个其它事件,则避免丢失数据。如果没有电影片段,则可能发生数据丢失,因为文件格式通常可能需要将所有元数据(例如,电影盒)写入文件的一个连续区域中。此外,当记录文件时,可能没有足够量的存储空间(例如,RAM)来缓冲可用存储装置大小的电影盒,并且当电影关闭时重新计算电影盒的内容可能太慢。此外,电影片段可以使用常规ISO文件解析器实现文件的同时记录和重放。最后,与具有相同媒体内容但在没有电影片段的情况下结构化的文件相比,当使用电影片段并且初始电影盒较小时,循序式下载(例如,文件的同时接收和重放)可能需要较小的初始缓冲持续时间。
电影片段特性可以使能将元数据(其通常将驻留在电影盒中)分成多个片段。每个片段可以对应于轨道的某一时间段。换言之,电影片段特性可以使文件元数据和媒体数据能够交错。因此,可以限制电影盒的大小并且实现上述用例。
在某些示例中,电影片段的媒体样本可能照常驻留在mdat盒中,前提是它们与moov盒在同一文件中。但是,对于电影片段的元数据,可以提供moof盒。moof盒可以包括先前已在moov盒中的某一重放持续时间的信息。moov盒仍然可以独立地表示有效电影,但此外,它可以包括指示同一文件中随后是电影片段的mvex盒。电影片段可以及时扩展与moov盒关联的呈现。
在电影片段内,可以具有一组轨道片段,每个轨道包括0个到多个片段。轨道片段又可以包括0个到多个轨道路线(track run),每个文档是该轨道的样本的连续路线。在这些结构内,许多字段是可选的并且可以是默认的。可以包括在moof盒中的元数据可以被限限于可包括在moov盒中的元数据的子集,并且在某些情况下可以以不同的方式进行编码。可以从ISO基础媒体文件格式规范中找到关于可以被包括在moof盒中的盒的细节。
可以基于分组准则,将ISO基础媒体文件格式及其派生物(例如AVC文件格式和SVC文件格式)中的样本分组定义为分配轨道中的每个样本以便成为一个样本组的成员。样本分组中的样本组并不限于是连续样本,并且可能包含非相邻样本。因为轨道中的样本可能具有多于一个样本分组,每个样本分组具有类型字段以便指示分组类型。样本分组可以由两个链接的数据结构表示:(1)SampleToGroup盒(sbgp盒)表示将样本分配给样本组;以及(2)SampleGroupDescription盒(sgpd盒)包含每个样本组的样本组条目,其描述组的属性。基于不同的分组准则,可以存在SampleToGroup和SampleGroupDescription盒的多个实例。这些实例通过用于指示分组类型的类型字段来区分。
样本组盒(SampleGroupDescription盒和SampleToGroup盒)驻留在样本表(stbl)盒内,该盒包含在电影(moov)盒内的媒体信息(minf)、媒体(mdia)和轨道(trak)盒中(按照该顺序)。允许SampleToGroup盒驻留在电影片段中。因此,样本分组可以逐片段完成。
可以针对特定内容类型指定URL片段标识符(其也可以被称为URL形式),以便访问由URL的基础部分(没有片段标识符)指示的资源的一部分(例如文件)。URL片段标识符可以例如通过URL内的井号(“#”)字符来标识。对于ISOBMFF,可以指定URL片段“#X”指track_ID等于X的轨道,“#item_ID=”和“#item_name=”指文件级别元盒(多个),“#/item_ID=”和“#/item_name=”指电影盒中的元盒(多个),并且“#track_ID=X/item_ID=”和“#track_ID=X/item_name=”指track_ID等于X的轨道中的元盒,包括可能在电影片段中找到的元盒。
Matroska文件格式能够(但不限于)将任何视频、音频、图片、或者副标题轨道存储在一个文件中。Matroska可以用作派生文件格式(例如WebM)的基础格式。Matroska使用可扩展二进制元语言(EBML)作为基础。EBML指定由XML原理启发的二进制和八位字节(字节)对齐格式。EBML本身是二进制标记技术的广义描述。Matroska文件由构成EBML“文档”的元素组成。元素引入元素ID、元素大小的描述符、以及二进制数据本身。元素可以被嵌套。Matroska的段元素是其它顶级(级别1)元素的容器。Matroska文件可以包括一个段(但不限于由一个段组成)。Matroska文件中的多媒体数据被组织在集群(或集群元素)中,每个集群通常包含几秒钟的多媒体数据。集群包括BlockGroup元素,BlockGroup元素又包括块元素(Block Element)。提示元素(Cue Element)包括元数据,元数据可以有助于随机访问或搜索,并且可以包括用于搜索点的文件指针或相应时间戳。
图像序列(其也可以被称为图像突发(image burst))可以使用各种手段获得,或者可以用于各种目的,包括但不限于以下一者或多者:
-图像序列可以表示例如使用突发摄影等顺序捕获的图片。
-图像序列可以表示焦点堆栈、曝光堆栈等,其中摄像机可以被视为
保持大致静止,并且捕获参数在图像序列的图片之间有所不同。
-图像序列可以表示全景图,其中摄像机已被摇摄(或类似操作),
并且在摄像机移动期间已拍摄在时间和/或平移上大约相等距离的
图片。
-图像序列可以表示动画或动态照片。动态照片可以被定义为其中发
生微小和重复移动的静态图片。
图像序列可以被压缩为使用空间预测手段编码的静态图片序列、或者使用空间和时间预测手段编码的帧间图片序列。传统上通过将序列表示为一系列独立编码的帧内图片,实现具有随机访问和支持编辑个体图片的图像序列。这些格式包括例如Motion JPEG、动画GIF和H.264的帧内简档。
如果图像序列被表示为一系列静态图片,则编码效率通常较差,并且高分辨率序列的文件大小要求可以变得很高。在序列被编码为具有时间预测的视频的情况下,存在对于序列需如何被解码、它可如何被重放的严格限制以及当用户想要编辑序列中的某些图像时的问题。
MPEG-H图像文件格式(ISO/IEC 23008-12)是ISO基础媒体文件格式(ISOBMFF)的派生规范。在撰写本专利申请时,ISO/IEC 23008-12是草案标准,并且因此需要理解,该标准的名称和/或昵称因此可能在该标准的最终版本中变化。已考虑诸如ISO图像文件格式(ISOIFF)和MPEG图像文件格式之类的名称。在标准规范本身内(或者另外当上下文清楚时),名称“图像文件格式”可以用于指ISO/IEC 23008-12。
下面描述MPEG-H图像文件格式的某些概念、结构和规范作为容器文件格式的一个示例,基于此可以实现各实施例。本发明的各方面并不限于MPEG-H图像文件格式,而是针对一个可能的基础提供描述,在该基础之上可以部分或完整地实现本发明。
在ISO/IEC 23008-12中定义的格式使能使用高效率视频编码(HEVC)或任何其它图像或视频编解码器编码的图像的互换、编辑和显示、以及与这些图像关联的元数据的传送。图像文件格式基于在ISO基础媒体文件格式中定义的工具,以便定义单个图像、图像集合和图像序列的可互操作存储格式。图像文件格式包括结构品牌和基于HEVC的品牌,结构品牌不限制用于对存储在文件中的图像进行编码的编解码器,基于HEVC的品牌需要针对编码图像使用HEVC。
图像文件格式支持使用HEVC视频编码器对静态图像进行编码,以便通过可选地在播放器和/或解码器处使用的定时,覆盖单个图像和独立编码的图像集合的存储、以及图像序列的存储,并且其中图像可以依赖于其它图像。
符合图像文件格式的文件可以包括静态图像和图像序列两者,从而使能构造单个文件以便满足各种需要(例如用于打印的单个图像,以及用于合成该图像的图像突发的记录)。一般而言,静态图像支持用于以下情况:例如当既不需要定时也不需要帧间图片编码依赖性时。如果需要来自可用于轨道的ISO基础媒体文件格式的定时或其它工具(例如简单动画图像),或者已使用帧间图片编码依赖性对图片进行编码,则可以使用存储为轨道的图像序列。
图像文件格式(类似于ISOBMFF)使用面向对象的机制,其中每个对象被称为盒。所有媒体数据及其相关元数据被封装到盒中。每个盒由四字符代码(4CC)标识并且以标头开始,该标头通知盒的类型和大小。
根据MPEG-H图像文件格式,静态图像被存储为项。可能需要包含编码图像的图像项被独立编码,并且在其解码中不依赖于任何其它项。
在MPEG-H图像文件格式的上下文中,以下盒可以包含在根级别“meta”盒内,并且可以如下所述被使用。在MPEG-H图像文件格式中,“meta”盒的处理机盒的处理机值是“pict”。通过数据信息(“dinf”)盒解析包含编码媒体数据的资源(无论是在同一文件内,还是在由统一资源标识符标识的外部文件中),而项位置(“iloc”)盒存储被参考文件内每个项的位置和大小。项参考(“iref”)盒记录使用类型参考的项之间的关系。如果在项集合中具有一个在某种程度上被视为与其它项相比最重要的项,则由主项(“pitm”)盒表示该项。除了在此提及的盒之外,“meta”盒还灵活地包括可能是描述项必需的其它盒。
如果给出通过使用“meta”盒方法存储的集合图像,则有时必须限定图像之间的某些关系。这些关系的示例包括指示集合的封面图像、针对集合中的部分或全部图像提供缩略图像、以及将集合中的部分或全部图像与辅助图像(例如阿尔法平面)关联。图像集合中的封面图像使用“pitm”盒指示。分别使用具有类型“thmb”或“auxl”的项参考将缩略图像或辅助图像链接到主图像项。
图像文件格式支持派生图像。当一个项包括对另一个项的“dimg”项参考时,该项是派生图像。通过对指定输入图像执行诸如旋转之类的指定操作(又称为图像操作),获得派生图像。为了获得派生图像而执行的操作由项的item_type标识。用作到派生图像的输入的图像项可以是例如项目类型为“hvc1”的编码图像,或者它们可以是其它派生图像项。
图像文件格式规范包括清洁光圈(即,修剪)操作(item_type等于“clap”)、用于多个90度旋转的旋转操作(item_type等于“irot”)、以及图像叠加操作(item_type等于“iovl”)的规范。图像叠加“iovl”派生图像在较大画布内以给定分层顺序定位一个或多个输入图像。
图像文件格式的派生图像特性是可扩展的,以使得外部规范以及图像文件格式本身的更高版本能够指定新操作。
可以例如在MPEG-H图像文件格式或类似文件格式的上下文中使用以下定义。编码图像可以被定义为图像的编码表示。派生图像可以被定义为这样的图像:其通过对所指示图像的所指示操作在文件中表示,并且可以通过对所指示图像执行所指示操作来获得。取决于使用术语图像的上下文,图像可以被定义为编码图像、派生图像、或者具有不同颜色分量的一个或多个像素阵列。图像集合可以被定义为根据MPEG-H图像文件格式(或类似文件格式)存储为单个文件的项的图像集。辅助图像可以被定义为这样的图像:其可能不打算被显示,但提供补充相应主图像的补充信息,例如透明度数据。封面图像可以被定义为这样的图像:其表示图像集合或图像序列,并且当针对图像集合或图像序列的优选显示方法没有其它信息可用时应该被显示。预计算的派生图像可以被定义为已从一个或多个其它图像派生的编码图像。主图像可以被定义为这样的图像:其存储为项并且不是辅助图像或缩略图像。缩略图像可以被定义为主图像的较小分辨率表示。
图像序列可以被定义为这样的图像序列:其可以与建议定时关联,并且其中图像可以被帧间预测。在MPEG-H图像文件格式中,根据ISOBMFF的轨道机制存储图像序列。如果图像之间具有编码依赖性或者图像的重放被定时,则使用图像序列轨道。图像序列轨道中的定时可以被定义为针对播放器的建议。为了区分图像序列与运动视频,已在MPEG-H图像文件格式中引入新的处理机类型“pict”。
MPEG-H图像文件格式包括将HEVC编码的静态图像和图像序列封装(通过包含和/或通过参考)到符合MPEG-H图像文件格式的文件中的规范。可以指定将使用其它编码格式编码的图像和图像序列封装到符合MPEG-H图像文件格式的文件中。
多用途因特网邮件扩展(MIME)是电子邮件协议的扩展,其使得可以在因特网上发送和接收不同类型的数据文件,例如视频和音频、图像、软件等。因特网媒体类型是因特网上用于指示文件包含的数据类型的标识符。此类因特网媒体类型也可以被称为内容类型。存在可以包含不同媒体格式的数个MIME类型/子类型组合。内容类型信息可以由发送实体在媒体传输开始时包括在MIME标头中。接收实体因此可能需要检查此类媒体内容的细节,以便判定如果给出可用的编解码器集,则是否能够呈现特定元素。特别是当终端系统具有有限的资源,或者到终端系统的连接具有有限的带宽时,单独从内容类型知道是否能够呈现内容可以有所帮助。
RFC 6381指定两个参数“codecs”和“profiles”,它们与各种MIME类型或类型/子类型组合一起使用,以便允许由包含在整体容器格式内的媒体格式或者整体容器格式的简档(多个)采用的编解码器的明确规范。
通过使用被指示呈现包含的媒体的特定编解码器标记内容,接收系统可以判定终端系统是否支持编解码器,并且如果不支持,则可以采取适当的动作(例如拒绝内容、发送情况通知、将内容转码为支持的类型、取回和安装需要的编解码器、进一步检查以便判定是否足以支持所指示编解码器的子集等)。
对于从ISOBMFF派生的文件格式,根据后面描述的正则表达式句法,在RFC 6381中指定的编解码器参数可以被视为具有以下结构:ListItem1(,ListItemN)*。
同样,在RFC 6381中指定的profiles参数可以向接收方提供内容符合的规范的整体指示。这是容器格式及其内容与某一规范的兼容性的指示。接收方可以通过检查以便查看其支持哪些声明的简档以及它们意味着什么,计算出其能够处理和呈现内容的程度。
MIME的最初动机之一是能够标识消息部分的特定媒体类型。但是,由于各种因素,并非始终可以从查看MIME类型和子类型来知道在主体部分中包含哪些特定媒体格式,或者为了呈现内容而指示哪些编解码器。
具有数种媒体类型/子类型(当前已注册或已部署且注册未决),它们包含从集合中选择的编解码器。在没有此处描述的参数的情况下,必须检查每个媒体元素以便确定呈现内容需要的编解码器或其它特性。
图像文件格式指定两种MIME类型,一种用于图像和图像集合,并且另一种用于图像序列。针对这些MIME类型指定编解码器参数的格式。例如,根据RFC 6381的编解码器参数的通用句法中的每个ListItem可以被视为在图像文件格式中按照以下方式格式化:
(trak.HandlerType|item).SampleEntryType.ProfileTierLevel(其中|指示非此即彼关系)。编解码器字符串包括标识符“trak”或“item”以便区分包括在文件中的轨道和项。为了支持图像序列轨道与视频轨道之间的区分,在编解码器字符串中包括处理机类型HandlerType。对于基于AVC和HEVC的编解码器,包括样本条目类型SampleEntryType(或等效项类型)和简档层级别信息ProfileTierLevel的字符串与ISO/IEC 14496-15中指定的相同。
例如,ProfileTierLevel对于HEVC被指定如下:ProfileTierLevel的元素是一系列值,例如来自HEVC解码器配置记录,以句点字符(“.”)分隔。在所有数字编码中,前导0可以被省略。ProfileTierLevel包括以下元素:
-general_profile_space,其被编码为无字符(general_profile_space==0),或者针对general_profile_space 1、2、3编码为“A”、“B”“C”,后跟被编码为十进制数的general_profile_idc;
-general_profile_compatibility_flags,其以十六进制编码(前导0可以被省略);
-general_tier_flag,其被编码为“L”(general_tier_flag==0)或“H”(general_tier_flag==1),后跟general_level_idc,其被编码为十进制数;
-约束标志的6个字节中的每一个,从包含general_progressive_source_flag的字节开始,每个字节被编码为十六进制数,并且每个字节的编码以句点分隔;为0的尾随字节可以被省略。
但是,图像文件格式的编解码器参数的规范缺少对派生图像的考虑。
这可能导致各种问题,并且在此使用以下HTML 5.1代码片段的一个示例示出其中某些问题。存在同一图像的两个编码表示,第一个文件preferred_image.hevc和第二个文件fallback_img.jpg。文件preferred_image.hevc符合图像文件格式,并且具有派生图像作为其主要项。因此,当前草案ISO/IEC 23008-12没有完全指定编解码器MIME参数。文件preferred_img.hevc是Web浏览器将下载的优选图像(例如,由于其与相应JPEG图像相比的较小大小),前提是该图像的解码被支持。但是,由于缺少上面列出的信息,Web浏览器将不能断定其是否能够处理preferred_img.hevc并且将下载文件fallback_img.jpg。根本不支持图像或者不支持任一格式的浏览器将下载使用alt属性指示的回退描述文本(fallbackdescriptive text)。
当图像播放器(例如,在浏览器中)想要播放派生图像的表示时,需要使用在派生图像的表示中记录的操作从原始图像(多个)组成派生图像。播放器可能需要评估它在执行操作本身之前是否能够组成派生图像,因为否则播放器可能无法组成派生图像,并且只是浪费时间(在下载和处理中)和计算资源。评估播放器是否具有组成派生图像的所有需要的资源可能包括以下一个或多个挑战:
-播放器需要评估其是否能够执行在派生图像表示中使用的所有类型的操作。
-播放器需要评估其是否能够对用作构造派生图像的输入图像的编码图像进行解码。这可以涉及:
○判定是否支持编解码器(例如HEVC)和编码简档(例如主简档)。还可选地判定是否支持输入图像的层和级别。
○评估播放器是否具有执行操作所需的可用存储资源。
因此,需要一种用于评估播放器是否能够组成派生图像的简化方法。
现在为了至少缓解上面的问题,以下提供一种用于评估组成派生图像的能力的方法。
在图6中公开的评估方法中,播放器接收(600)第一文件的第一描述,所述第一描述包括被包含在所述第一文件中或由所述第一文件参考的至少派生图像的属性。所述播放器基于所述派生图像的所述属性,判定(602)是否获得所述派生图像,并且响应于判定获得所述派生图像,获得(604)包括所述派生图像的所述第一文件。
根据一个实施例,播放器可以进一步接收(606)第二文件的第二描述,所述第二描述包括如由所述派生图像表示的对应图像内容的表示;以及基于所述派生图像的所述属性和所述第二描述,判定(608)是获得所述第一文件还是所述第二文件。然后播放器获得所述第一文件或所述第二文件(610)。
因此,播放器可以判定派生图像的重构是否可能。因此,如果文件中的派生图像不能由接收方、Web浏览器等的播放器重构,则可以使用指示的属性避免不必要的文件下载。根据一个实施例,可以存在具有相同可用内容的多个替代图像文件,并且播放器可以基于所述描述来选择所述替代图像文件的哪个图像文件被下载和重构。
根据一个实施例,所述第一描述包括MIME类型。
根据一个实施例,诸如MIME类型之类的所述第一描述包括用于至少一个派生图像的以下信息片段中的一者或多者:
-用于所述至少一个派生图像的指令集的第一标识,这可以例如包括指令集的标识列表,例如包括指定在文件的派生图像中使用的指令集的URI列表的第一可选MIME参数、以及特定于至少一个派生图像的索引,该索引指向指令的标识列表的列表元素;
-用于所述至少一个派生图像的编码输入图像的编解码器和编解码器简档的第二标识,其中所述标识可以被包含在第二可选MIME参数中,第二可选MIME参数可以例如被称为编解码器参数;
-指示构造所述至少一个派生图像所需的资源的资源计数,例如用于构造所述至少一个派生图像的任何单个图像操作的输入和输出图像需要的累积像素数。
用于派生图像的指令集可以被定义为派生图像类型集或图像操作类型集。当可以使用由特定指令集定义的操作来构造派生图像时,该指令集可以被视为用于该派生图像。
第一可选MIME参数可以例如被称为dimg-instr-set,并且其可以定义一个或多个指令集,这些指令集用于特定派生图像以及直接或间接用作特定派生图像的输入的任何派生图像。例如,在ISO/IEC 23008-12中指定的图像操作(清洁光圈、旋转、以及叠加)可以被视为指令集。
编解码器MIME参数可以定义用于编码图像的编解码器(例如HEVC)和简档(例如主简档),这些编码图像直接或间接用作特定派生图像的输入。还可以包括层和级别,但并非绝对必要,因为通常在个体图像的解码中不涉及实时处理要求。
可以使用累积像素数(在最大样本阵列中)表征图像需要的存储资源(而诸如位深度和色度格式之类的其它因素可以从编解码器简档和派生图像指令集中得出)。因为特定派生图像或任何直接或间接输入图像可能需要数个输入图像,所以提供图像的累积像素计数。这有助于确保直接或间接用作特定派生图像的输入的所有中间图像能够被保持在播放器的内存限制内。
接下来,公开与MIME类型的实现相关的各种实施例,其中使用正则表达式句法,其中采用斜体的关键字被视为通过使用其值替换它们来解析的变量,()指示一个或多个字符的字符串,*指示将包含在前面括号内的字符串包括0次或更多次,?指示将包含在前面括号内的字符串包括0或1次,并且同样包括字母数字字符。需要理解,能够使用正则表达式句法之外的其它句法规则和/或用于指示至少一个派生图像的第一标识、第二标识、以及资源计数中的一者或多者的句法的其它变型来形成类似的实施例。
符合图像文件格式的文件的编解码器参数具有以下结构:
ListItem1(,ListItemN)*
其中当SampleEntryType指示编码格式时,每个ListItem被提议具有以下结构:
(trak.HandlerType|item).SampleEntryType.ProfileTierLevel
根据一个实施例,做出符合图像文件格式的文件/资源的MIME类型的以下附加规范:
指定dimg-instr-set可选MIME参数以便包含:
<uri1>(<uriN>)*
其中每个uriN是URI,并且每个uriN被包含在尖括号中。如果dimg-instr-set不存在但由编解码器参数参考,则dimg-instr-set被推断由仅具有预定义默认值的uri1组成,例如值urn:mpeg:isoiff:2015,其可以例如参考在图像文件格式中指定的派生图像的指令集或项类型。
例如,可以指定URI urn:mpeg:isoiff:2015以便指示由清洁光圈、旋转、以及叠加操作组成的派生图像指令集。在另一个示例中,可以指定URI urn:mpeg:isoiff:2015:baseline以便指示由清洁光圈和旋转派生图像组成的派生图像指令集,并且可以指定URIurn:mpeg:isoiff:2015:extended以便指示由清洁光圈、旋转、以及叠加派生图像组成的派生图像指令集。
根据一个实施例,做出图像文件格式的MIME类型的编解码器参数句法中的ListItem的以下规范:对于派生图像,在ListItem的句法中使用等于dimg的SampleEntryType,并且ListItem具有以下结构:
dimg(.InstrIdx(.PixelCount.CodecInfo)?)?
其中
InstrIdx指示标识用于派生图像的指令集的URI uriL的索引L。如果InstrIdx不存在,则InstrIdx被推断等于1;
PixelCount是十进制正整数,其指示用于构造派生图像的任何单个图像操作的输入和输出图像需要的最大像素数;
CodecInfo具有以下结构:
NumCodedImg.(ItemType.ProfileTierLevel)*,其中NumCodedImg是可能具有ItemType.ProfileTierLevel对的不同值的正整数个编码输入图像,并且ItemType.ProfileTierLevel对的数量等于NumCodedImg。ItemType是作为派生图像的输入的编码图像的四字符项类型,并且ProfileTierLevel是简档级别信息,如针对RFC 6381中ISO基础媒体文件格式命名空间的编解码器参数所指定的。对于基于AVC和HEVC的编解码器,在ISO/IEC 14496-15中指定ProfileTierLevel的格式。
CodecInfo被选择为ListItem的最后一部分,以使得其可以从结尾被截断。例如,大多数时候,整个HEVC ProfileTierLevel字符串包含不需要包括的尾随0。
本实施例的句法示例包括以下内容:
内容类型:image/mpeg-h;codecs=item.dimg
图像文件,其中该文件的主要项是使用在图像文件格式中指定的指令集的派生图像。
内容类型:image/mpeg-h;codecs=item.dimg.1。
2995200.hvc1.A1.80.L93.B0
图像文件,其中该文件的主要项是使用在图像文件格式中指定的指令集并且需要存储最多两个图像(一个大小为1920x1080,并且另一个大小为1280x720)的派生图像,并且需要在主层3.1级别对一个渐进、非帧分组的HEVC主简档图像进行解码。
根据一个实施例,做出图像文件格式的MIME类型的编解码器参数句法中的ListItem的以下规范:对于派生图像,将在ListItem的句法中使用等于dimg的SampleEntryType,并且ListItem具有以下结构:
dimg(.InstrIdx(.WidthHeight(.CodecInfo)?)?)?
其中
InstrIdx指示标识用于派生图像的指令集的URI uriL的索引L。如果InstrIdx不存在,则InstrIdx被推断等于1;
WidthHeight具有以下结构:NumImg.(WidthImgN.HeightImgN)*,其中NumImg是十进制正整数,其指示需要最大内存量的单个图像操作所需的图像数量,并且WidthImgN.HeightImgN对的数量等于NumImg。WidthImgN和HeightImgN是十进制正整数,它们分别指示该特定单个图像操作需要的解码或派生图像的宽度和高度;
CodecInfo具有以下结构:
NumCodedImg.(ItemType.ProfileTierLevel)*,其中NumCodedImg是可能具有ItemType.ProfileTierLevel对的不同值的正整数个编码输入图像,并且ItemType.ProfileTierLevel对的数量等于NumCodedImg。ItemType是作为派生图像的输入的编码图像的四字符项类型,并且ProfileTierLevel是简档级别信息,如针对RFC 6381中ISO基础媒体文件格式命名空间的编解码器参数所指定的。对于基于AVC和HEVC的编解码器,在ISO/IEC 14496-15中指定ProfileTierLevel的格式。
可以通过HTML 5.1中的图像文件选择的一个示例进一步示出上面某些实施例,其中使用以下句法:
在该示例中,存在同一图像的两个编码表示,第一个文件preferred_image.hevc和第二个文件fallback_img.jpg。文件preferred_image.hevc符合图像文件格式,并且具有派生图像作为其主要项。构造派生图像需要在图像文件格式中指定的指令集。构造派生图像需要的累积像素计数为2*1280*720,这可以指示例如旋转1280x720像素的解码图像以便形成派生图像。此外,派生图像需要在主层3.1级别对一个渐进、非帧分组的HEVC主简档图像进行解码。Web浏览器将下载preferred_img.hevc,前提是它具有构造所述派生图像的能力和资源。否则,Web浏览器将下载文件fallback_img.jpg或回退描述文本,如前所述。
媒体内容描述可以被定义为媒体内容的任何描述的术语,包括但不限于MIME类型(可能包括MIME类型的可选参数);包括描述嵌入式媒体内容的元素的HTML页面等,例如如上所述的HTML 5.1的图片元素;流内容的清单,例如如上所述的MPEG-DASH的MPD或HLS的扩展M3U格式;以及根据会话描述协议(SDP)的描述,该协议可以例如用于建立RTP会话。
在图7中示出文件创建器的操作。其中,文件创建器获得(700)一个或多个输入图像,并且确定(702)要针对至少一个输入执行以便获得派生图像的至少一个操作。文件创建器将第一文件的第一描述包括(704)到媒体内容描述中,所述第一描述包括被包含在所述第一文件中或由所述第一文件参考的至少所述派生图像的属性。
同样,文件创建器还可以包括第二文件的第二描述,所述第二描述包括如由所述派生图像表示的对应图像内容的表示。
在上述某些实施例中,已给出指示构造派生图像需要的资源的资源计数的示例。但是,根据一个实施例,任何资源计数(例如上面指定的PixelCount或上面指定的WidthHeight)可以被其它类型(多种)的资源计数替换或额外地补充。下面针对文件创建器提供关于资源计数的示例实施例,并且在文件内指示资源计数;但是,需要理解,可以同样针对其它实体(例如内容提供器)描述实施例,和/或不在文件内指示资源计数而是使用文件描述指示资源计数,或者除了在文件内指示资源计数以外还使用文件描述指示资源计数。
根据一个实施例,除了或者代替在图像文件的描述中包括派生图像的属性,图像文件创建器可以将表示派生图片的数据结构包括到图像文件中,并且将指示组成派生图片的所需资源的至少一个值包括到图像文件中。
在一个实施例中,在类型中包括MIME类型,MIME类型具有指示组成文件中至少一个派生图像的所需资源的可选参数。前面已使用其它实施例描述用于指示所需资源的可选MIME参数的示例。例如,可以使用文件级别盒传送MIME类型字符串。在另一个示例中,轨道(“trak”盒)和/或项元数据可以附加有其MIME类型的相应部分。编解码器参数的ListItem可以包含在“trak”盒层次结构内的盒中。可以例如通过附加项信息盒或引入新盒,针对“meta”盒内的一个或多个项包括编解码器参数的ListItem。
指示所需资源的值可以包括但不限于以下一者或多者:
-大于或等于在组成所述派生图片的任何阶段所需的最大像素、样本和/或字节计数的值;
-大于或等于组成所述派生图片所需的任何图片所需的最大像素、样本和/或字节计数的值,其中组成所述派生图片所需的所述图片包括用于组成所述派生图片的中间操作的输出图片;
-用于标识能够在组成所述派生图片中使用的操作类型集的标识符,而未被包括在所述操作类型集中的操作类型不在组成所述派生图片中使用。
根据一个实施例,文件创建器可以使用以下一个或多个步骤操作:
-文件创建器指示在文件中组成派生图像的图像操作的顺序。
-对于每个图像操作(用于组成派生图像),文件创建器确定该图像操作或任何后续图像操作需要哪些输入图片和哪些中间图片(由先前图像操作产生)。文件创建器确定在存储器中存储或保留这些所需图片需要的某种资源类型的累积资源计数。资源类型可以例如是像素数、样本数、或者字节数。
-文件创建器选择所有图像操作(用于组成派生图像)的累积资源计数的最大值。在文件中包括等于或大于最大值的值作为组成派生图像的所需资源的指示值。
根据一个实施例,文件创建器可以使用以下一个或多个步骤操作:
文件创建器以名义处理顺序对图像操作Operation[i](对于0到图像操作数NumOperations减去1(包括该值)的范围内的i的每个值)进行排序,以使得可以以i的升序处理图像操作Operation[i],并且Operation[j]将不依赖于任何操作Operation[i],以使得i>j。文件创建器例如通过在派生图像的数据结构中以i的升序包括图像操作Operation[i],指示文件中的图像操作的顺序。注意,可能以名义处理顺序之外的顺序处理图像操作,但使用名义顺序导出资源计数。
假设输入图像InputImage[j]是针对0到输入图像数NumInputImages减去1(包括该值)的范围内的j的所有值而“在外部”提供给图像操作的输入图像(即,并非由图像操作创建)。
假设中间图像IntermediateImage[i][j]是针对0到输出操作Operation[i]的输出图像数NumOperOutputImages[i]减去1(包括该值)的范围内的j的所有值的图像操作Operation[i]的输出。
针对0到输出图像数NumOperOutputImages[i]-1(包括该值)的范围内的j的所有值,对于0到NumOperations-1(包括该值)的范围内的i的每个值,可以分别针对每个中间图像IntermediateImage[i][j]导出资源计数IntermediateImageResourceCount[i][j]。
同样,可以针对0到NumInputImages–1(包括该值)的范围内的j的每个值,导出资源计数InputImageResourceCount[j]。
假设图像的活动图片集ActiveSet[i]包括以下图像:
输入图像InputImage[m],针对0到NumInputImages-1(包括该值)的范围内的m的任何值,以使得针对i到NumOperations–1(包括该值)的范围内的k的任何值,InputImage[m]用作到任何图像操作Operation[k]的输入。
中间图像IntermediateImage[m][n],针对0到i–1(包括该值)的范围内的m的任何值,并且针对0到NumOperOutputImages[m]–1(包括该值)的范围内的n的任何值,以使得针对i到NumOperations–1(包括该值)的范围内的k的任何值,IntermediateImage[m][n]用作到任何图像操作Operation[k]的输入。
中间图像IntermediateImage[i][j],针对0到NumOperOutputImages[i]–1(包括该值)的范围内的n的任何值。
针对0到NumOperations–1(包括该值)的范围内的i,可以针对每个活动图片集ActiveSet[i]导出资源计数ActiveSetResourceCount[i],作为活动图片集ActiveSet[i]中的图片的资源计数总和。
针对0到NumOperations–1(包括该值)的范围内的i,可以将最大累积资源计数MaxCumulativeResourceCount设置为等于ActiveSetResourceCount[i]的最大值。
根据一个实施例,可以将最大个体资源计数MaxResourceCount设置为等于InputImageResourceCount[k]的最大值(针对0到NumInputImages–1(包括该值)的范围内的k的任何值)、或者设置为等于IntermediateImageResourceCount[i][j]的最大值(针对0到NumOperations–1(包括该值)的范围内的i的任何值,并且针对0到输出图像数NumOperOutputImages[i]–1(包括该值)的范围内的j的任何值)。在一个备选实施例中,针对0到NumOperations–1(包括该值)的范围内的i的任何值,并且针对0到输出图像数NumOperOutputImages[i]–1(包括该值)的范围内的j的任何值,可以将最大个体资源计数MaxResourceCount设置为等于IntermediateImageResourceCount[i][j]的最大值。
根据一个实施例,文件创建器可以设置以下至少一者
-第一值,其指示所需资源要大于或等于MaxCumulativeResourceCount。
-第二值,其指示所需资源要大于或等于MaxResourceCount。
可以存在一种或多种类型的资源类型,可以针对这些资源类型提供指示所需资源的值。下面给出针对不同资源类型导出资源计数ResourceCount的某些非限制性示例,其中ResourceCount可以从单个图像导出(并且因此可以有效地为InputImageResourceCount[]或IntermediateImageResourceCount[][]之一),或者从图像集导出(并且因此可以有效地为ActiveSetResourceCount[])。
-像素数,即,图像或图像集的所有样本阵列中最高样本计数的样本阵列中的样本数。
-像素数,即,图像或图像集的所有样本阵列中的样本数。
-存储单元数,例如存储图像或图像集需要的字节数。可以相对于样本阵列布置来指示存储单元数,样本阵列布置可以沿着文件中所需存储单元的值被预定义或指示。样本阵列布置可以是但不限于以下之一:
○样本存储在不同字节中。如果样本的位深度不是8的倍数,则假设样本占用下一较高整数个字节。例如,如果样本的位深度为10,则假设样本占用2个字节。注意,不同颜色分量的位深度可能不同。例如,亮度分量可以具有10位的位深度,而色度分量可以具有8位的位深度。
○将不同颜色分量的并置样本打包为整数个字节。例如,如果样本的位深度为10并且色度格式为4:4:4,则假设每个并置Y、U和V样本集分配被打包成4个字节的30个位。
根据一个实施例,文件创建器可以设置以下至少一者
-第一值集,其指示所需资源要大于或等于MaxCumulativeResourceCount,其中集合中的每个元素对应于不同资源类型。可以例如在文件格式标准中预定义元素类型,或者可以在文件中指示元素类型。
-第二值,其指示所需资源要大于或等于MaxResourceCount,其中集合中的每个元素对应于不同资源类型。可以例如在文件格式标准中预定义元素类型,或者可以在文件中指示元素类型。
下面针对文件播放器提供关于资源计数的示例实施例,并且从文件解析资源计数;但是,需要理解,可以同样针对其它实体(例如Web浏览器)描述实施例,和/或从文件描述解析资源计数。
根据一个实施例,除了或者代替从图像文件的描述解析派生图像的属性,图像文件播放器从图像文件解析指示组成派生图片的所需资源的至少一个值;以及基于至少一个值,判定其是否能够组成派生图片。
根据一个实施例,文件播放器可以执行以下一个或多个步骤:
-文件播放器从文件解析指示组成派生图像的所需资源的至少一个值。
-文件播放器基于所述至少一个值,判定其是否能够组成所述派生图像。
如果文件播放器判定其能够组成所述派生图像,则文件播放器从所述文件解析表示所述派生图像的数据结构,所述数据结构定义至少一个操作的有向非循环图;以及文件播放器通过执行至少一个操作的有向非循环图来组成所述派生图像。
此外,文件播放器可以执行以下步骤:
-文件播放器从所述文件解析图像操作的执行顺序以便组成所述派生图像。
-当以执行顺序逐图像操作执行所述图像操作时,针对每个图像操作:
○文件播放器基于至少一个操作的输入和输出以及执行顺序,确定以执行顺序的后续操作需要哪些图片。
○文件播放器释放资源以便存储以执行顺序的后续操作中不再需要的图片(例如,解除存储器的分配以便存储图片)。
除了上面实施例之外,还可以执行补充实施例,此类实施例涉及就地(in-place)图像操作。根据一个实施例,可以在资源计数中考虑就地图像操作。就地图像操作可以被定义为这样的图像操作:其中相同的存储器可以用于操作的输入图像(多个)和操作的输出图像(多个)。可以认为,在就地图像操作中,处理一个或多个输入图像的非重叠输入窗口(例如像素或像素块)以便产生一个或多个输出图像的相应窗口的输出。因此,一旦产生某个输出窗口的像素(在工作存储器中),输入窗口中的相应像素便能够由输出窗口的像素替换。由输出窗口的像素覆写的像素不会影响以处理顺序的后续窗口的处理。例如,色调映射图像操作可以是就地图像操作。
可以例如在文件格式标准中定义一组预定义就地图像操作。
备选地或此外,文件创建器可以在文件中指示图像操作是否被视为就地图像操作。
当导出资源计数时,文件创建器可以以资源计数的导出仅考虑单个图像以便表示图像操作的输入图像和相应输出图像的方式,处理就地图像操作。更一般地说,如果图像操作具有多个输入和输出,则文件创建器可以以以资源计数的导出仅考虑单个图像以便表示每对输入图像和相应输出图像的方式,处理就地图像操作。在某些实施例中,仅当图像操作的输入图像未被用作以执行顺序的任何后续图像操作的输入图像时,文件创建器才将图像操作视为就地图像操作。
当图像操作被指示(在文件中)或预定义为就地图像操作时,文件播放器可以相应地将图像操作执行为就地操作。在某些实施例中,仅当图像操作的输入图像未被用作以执行顺序的任何后续图像操作的输入图像时,文件播放器才将图像操作视为就地图像操作。
图8示出适合于采用本发明实施例的视频解码器的框图。图8示出双层解码器的结构,但将认识到,同样可以在单层解码器中采用解码操作。
视频解码器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初步重构和滤波后的基础视图图像。
在此,解码器应该被解释为涵盖任何能够执行解码操作的操作单元,例如播放器、接收器、网关、多路复用器和/或解码器。
在上文中,已针对MIME类型和可选MIME参数描述了某些实施例。需要理解,代替或者除了可选MIME参数,可以例如在XML描述(例如MPEG-DASH的MPD或其它媒体内容描述)内使用诸如属性之类的其它信令。
在上文中,已针对ISOBMFF描述了某些实施例。需要理解,同样可以使用任何其它文件格式(例如Matroska)、与ISOBMFF中类似的能力和/或结构来实现各实施例。
在上文中,已针对播放器描述了某些实施例。需要理解,可以互换使用其它术语,例如读取器、解析器、用户代理或客户机。需要理解,播放器可以是但不需要是独立应用。播放器可以例如嵌入Web浏览器中。
在上文中,已针对播放器描述了某些实施例。需要理解,当图像或图像文件未被播放或显示,但为了其它目的而被检索时,同样可以实现各实施例。在一个实施例中,代理高速缓存接收第一文件的第一描述,所述第一描述包括被包含在所述第一文件中或由所述第一文件参考的至少派生图像的属性。所述代理高速缓存基于所述派生图像的所述属性、以及关于一个或多个客户机的能力的知识,判定是否获得所述派生图像,并且响应于判定获得所述派生图像,获得包括所述派生图像的所述第一文件。根据一个实施例,所述代理高速缓存可以进一步接收第二文件的第二描述,所述第二描述包括如由所述派生图像表示的对应图像内容的表示;以及基于所述派生图像的所述属性和第二描述以及关于一个或多个客户机的能力的知识,判定是获得所述第一文件还是所述第二文件。然后播放器获得所述第一文件或所述第二文件。
在上文中,已针对文件创建器描述了某些实施例。需要理解,可以互换使用其它术语,例如写入器、文件生成器、或者内容提供器。需要理解,创建器可以是但不需要是独立应用。创建器可以例如使用脚本例如嵌入Web服务器中。
在上文中,其中已参考编码器描述了示例实施例,需要理解,得到的位流和解码器可以在它们中具有对应元素。同样,其中已参考解码器描述了示例实施例,需要理解,编码器可以具有用于生成要由解码器解码的位流的结构和/或计算机程序。
上面描述的本发明实施例就单独的编码器和解码器装置而言描述了编解码器,以便有助于理解涉及的过程。但是,将认识到,所述装置、结构和操作可以被实现为单个编码器-解码器装置/结构/操作。此外,编码器和解码器可以共享部分或全部通用元件。
尽管上面示例描述了在电子设备内的编解码器内操作的本发明实施例,但将认识到,权利要求中限定的本发明可以被实现为任何视频编解码器的一部分。因此,例如,本发明实施例可以在视频编解码器中实现,该视频编解码器可以通过固定或有线通信路径实现视频编码。
因此,用户设备可以包括例如在上面的本发明实施例中描述的视频编解码器。将认识到,术语用户设备旨在涵盖任何合适类型的无线用户设备,例如移动电话、便携式数据处理设备或便携式Web浏览器。
此外,公共陆地移动网络(PLMN)的元件还可以包括如上所述的视频编解码器。
一般而言,本发明的各种实施例可以以硬件或专用电路、软件、逻辑或其任何组合来实现。例如,某些方面可以以硬件实现,而其它方面可以以可由控制器、微处理器或其它计算设备执行的固件或软件实现,然而本发明并不限于此。尽管本发明的各个方面可以作为框图、流程图或者使用某个其它图形表示而被示出和描述,但可以理解,作为非限制性示例,在此描述的这些方框、装置、系统、技术或方法可以以硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其它计算设备或其某种组合来实现。
本发明的实施例可以由计算机软件(例如在处理器实体中,其可由移动设备的数据处理器执行)、或硬件、或软件和硬件的组合来实现。此外,在这点上,应该注意,图中的逻辑流程的任何方框可以表示程序步骤、或互连逻辑电路、块和功能、或程序步骤以及逻辑电路、块和功能的组合。软件可以存储在以下各项上:诸如存储芯片之类的物理介质,或者在处理器中实现的存储块,诸如硬盘或软盘之类的磁介质,以及诸如DVD及其数据变型、CD之类的光介质。
存储器可以具有适合于本地技术环境的任何类型,并且可以使用任何合适的数据存储技术实现,例如基于半导体的存储设备、磁存储设备和系统、光存储设备和系统、固定存储器以及可移动存储器。数据处理器可以具有适合于本地技术环境的任何类型,并且作为非限制性示例,可以包括以下一个或多个:通用计算机、专用计算机、微处理器、数字信号处理器(DSP)以及基于多核处理器架构的处理器。
本发明的实施例可以在诸如集成电路模块之类的各种组件中实现。集成电路的设计是高度自动化的过程。可以使用复杂并且强大的软件工具,将逻辑级别设计转换为可以在半导体衬底上蚀刻和形成的半导体电路设计。
程序(例如,由位于加利福尼亚州山景城的Synopsys,Inc.以及位于加利福尼亚州圣何塞的Cadence Design提供的程序)使用完善的设计规则以及预先存储的设计模块库,自动路由导体并且在半导体芯片上定位组件。在完成半导体电路设计之后,可以将标准化电子格式(例如,Opus、GDSII等)的结果设计传输到半导体制造设施或“工厂”以便制造。
通过示例性和非限制性示例提供上面的描述,即本发明的示例性实施例的全面和信息性的描述。但是,当结合附图和所附权利要求阅读时,鉴于上面的描述,许多修改和变化对于相关技术领域的技术人员来说变得显而易见。但是,对本发明教导的所有这些和类似的修改仍落入本发明的范围内。
Claims (20)
1.一种方法,包括:
接收第一文件的第一描述,所述第一描述包括被包含在所述第一文件中或由所述第一文件参考的至少派生图像的属性;
基于所述派生图像的所述属性,判定是否获得所述派生图像;以及
响应于判定获得所述派生图像,获得包括所述派生图像的所述第一文件。
2.根据权利要求1所述的方法,进一步包括:
接收第二文件的第二描述,所述第二描述包括如由所述派生图像表示的对应图像内容的表示;以及
基于所述派生图像的所述属性和所述第二描述,判定是获得所述第一文件还是所述第二文件。
3.根据权利要求1所述的方法,其中所述第一描述包括多用途因特网邮件扩展(MIME)类型。
4.根据权利要求1所述的方法,其中诸如所述MIME类型的所述第一描述包括用于至少一个派生图像的以下信息片段中的一者或多者:
-用于所述至少一个派生图像的指令集的第一标识;
-用于所述至少一个派生图像的编码输入图像的编解码器和编解码器简档的第二标识;
-指示构造所述至少一个派生图像所需的资源的资源计数。
5.根据权利要求1所述的方法,进一步包括:
从所述第一文件解析指示组成派生图片的所需资源的至少一个值;以及
基于至少一个值,判定是否能够组成所述派生图片。
6.一种装置,包括:
至少一个处理器和至少一个存储器,所述至少一个存储器在其上存储有代码,当由所述至少一个处理器执行时,所述代码导致所述装置至少执行
接收第一文件的第一描述,所述第一描述包括被包含在所述第一文件中或由所述第一文件参考的至少派生图像的属性;
基于所述派生图像的所述属性,判定是否获得所述派生图像;以及
响应于判定获得所述派生图像,获得包括所述派生图像的所述第一文件。
7.根据权利要求6所述的装置,进一步包括导致所述装置至少执行以下操作的代码:
接收第二文件的第二描述,所述第二描述包括如由所述派生图像表示的对应图像内容的表示;以及
基于所述派生图像的所述属性和所述第二描述,判定是获得所述第一文件还是所述第二文件。
8.根据权利要求6所述的装置,其中所述第一描述包括多用途因特网邮件扩展(MIME)类型。
9.根据权利要求6所述的装置,其中诸如所述MIME类型的所述第一描述包括用于至少一个派生图像的以下信息片段中的一者或多者:
-用于所述至少一个派生图像的指令集的第一标识;
-用于所述至少一个派生图像的编码输入图像的编解码器和编解码器简档的第二标识;
-指示构造所述至少一个派生图像所需的资源的资源计数。
10.一种计算机可读存储介质,其上存储有代码以供装置使用,当由处理器执行时,所述代码导致所述装置执行:
接收第一文件的第一描述,所述第一描述包括被包含在所述第一文件中或由所述第一文件参考的至少派生图像的属性;
基于所述派生图像的所述属性,判定是否获得所述派生图像;以及
响应于判定获得所述派生图像,获得包括所述派生图像的所述第一文件。
11.一种方法,包括:
获得一个或多个输入图像;
确定要针对至少一个输入执行以便获得派生图像的至少一个操作;以及
将第一文件的第一描述包括在媒体内容描述中,所述第一描述包括被包含在所述第一文件中或由所述第一文件参考的至少所述派生图像的属性。
12.根据权利要求11所述的方法,进一步包括
包括第二文件的第二描述,所述第二描述包括如由所述派生图像表示的对应图像内容的表示。
13.根据权利要求11所述的方法,其中所述第一描述包括多用途因特网邮件扩展(MIME)类型。
14.根据权利要求11所述的方法,其中诸如所述MIME类型的所述第一描述包括用于至少一个派生图像的以下信息片段中的一者或多者:
-用于所述至少一个派生图像的指令集的第一标识;
-用于所述至少一个派生图像的编码输入图像的编解码器和编解码器简档的第二标识;
-指示构造所述至少一个派生图像所需的资源的资源计数。
15.根据权利要求11所述的方法,进一步包括:
将表示派生图像的数据结构包括在所述第一文件中,以及
将指示组成派生图片的所需资源的至少一个值包括在所述第一文件中。
16.根据权利要求15所述的方法,其中指示所需资源的所述值包括以下项中的一者或多者:
-大于或等于在组成所述派生图片的任何阶段所需的最大像素、样本和/或字节计数的值;
-大于或等于组成所述派生图片所需的任何图片所需的最大像素、样本和/或字节计数的值,其中组成所述派生图片所需的所述图片包括用于组成所述派生图片的中间操作的输出图片;
-用于标识能够在组成所述派生图片中使用的操作类型集的标识符,而未被包括在所述操作类型集中的操作类型不在组成所述派生图片中使用。
17.一种装置,包括
至少一个处理器和至少一个存储器,所述至少一个存储器在其上存储有代码,当由所述至少一个处理器执行时,所述代码导致所述装置至少执行
获得一个或多个输入图像;
确定要针对至少一个输入执行以便获得派生图像的至少一个操作;以及
将第一文件的第一描述包括在媒体内容描述中,所述第一描述包括被包含在所述第一文件中或由所述第一文件参考的至少所述派生图像的属性。
18.根据权利要求17所述的装置,进一步包括导致所述装置至少执行以下操作的代码:
包括第二文件的第二描述,所述第二描述包括如由所述派生图像表示的对应图像内容的表示。
19.根据权利要求17所述的装置,其中诸如多用途因特网邮件扩展(MIME)类型的所述第一描述包括用于至少一个派生图像的以下信息片段中的一者或多者:
-用于所述至少一个派生图像的指令集的第一标识;
-用于所述至少一个派生图像的编码输入图像的编解码器和编解码器简档的第二标识;
-指示构造所述至少一个派生图像所需的资源的资源计数。
20.一种计算机可读存储介质,其上存储有代码以供装置使用,当由处理器执行时,所述代码导致所述装置执行:
获得一个或多个输入图像;
确定要针对至少一个输入执行以便获得派生图像的至少一个操作;以及
将第一文件的第一描述包括在媒体内容描述中,所述第一描述包括被包含在所述第一文件中或由所述第一文件参考的至少所述派生图像的属性。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/617,266 US10291561B2 (en) | 2015-02-09 | 2015-02-09 | Apparatus, a method and a computer program for image coding and decoding |
US14/617,266 | 2015-02-09 | ||
PCT/FI2016/050063 WO2016128612A1 (en) | 2015-02-09 | 2016-02-02 | An apparatus, a method and a computer program for image coding and decoding |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107431810A true CN107431810A (zh) | 2017-12-01 |
CN107431810B CN107431810B (zh) | 2020-06-05 |
Family
ID=56567195
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201680019302.0A Active CN107431810B (zh) | 2015-02-09 | 2016-02-02 | 用于图像编码和解码的装置、方法和计算机程序 |
Country Status (7)
Country | Link |
---|---|
US (1) | US10291561B2 (zh) |
EP (1) | EP3257244B1 (zh) |
JP (1) | JP6649404B2 (zh) |
KR (1) | KR101949071B1 (zh) |
CN (1) | CN107431810B (zh) |
WO (1) | WO2016128612A1 (zh) |
ZA (1) | ZA201705953B (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108876882A (zh) * | 2018-06-26 | 2018-11-23 | 史艳艳 | 一种画面非循环的gif文件播放方法及系统 |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2016015009A (ja) * | 2014-07-02 | 2016-01-28 | ソニー株式会社 | 情報処理システム、情報処理端末、および情報処理方法 |
US20160277767A1 (en) * | 2015-03-16 | 2016-09-22 | Thomson Licensing | Methods, systems and apparatus for determining prediction adjustment factors |
GB2538997A (en) * | 2015-06-03 | 2016-12-07 | Nokia Technologies Oy | A method, an apparatus, a computer program for video coding |
US10681107B2 (en) * | 2015-06-16 | 2020-06-09 | Apple Inc. | Adaptive video content for cellular communication |
US10951874B2 (en) * | 2016-09-02 | 2021-03-16 | Mediatek Inc. | Incremental quality delivery and compositing processing |
US10652553B2 (en) * | 2016-12-07 | 2020-05-12 | Qualcomm Incorporated | Systems and methods of signaling of regions of interest |
GB2560921B (en) | 2017-03-27 | 2020-04-08 | Canon Kk | Method and apparatus for encoding media data comprising generated content |
US10924822B2 (en) * | 2017-04-04 | 2021-02-16 | Qualcomm Incorporated | Segment types as delimiters and addressable resource identifiers |
US10560726B2 (en) * | 2017-07-26 | 2020-02-11 | CodeShop BV | System and method for delivery and caching of personalized media streaming content |
CN110545456B (zh) * | 2018-05-29 | 2022-04-01 | 北京字节跳动网络技术有限公司 | 媒体文件的同步播放方法、装置及存储介质 |
EP3854105A4 (en) | 2018-09-20 | 2022-06-22 | Nokia Technologies Oy | ARTIFICIAL INTELLIGENCE APPARATUS AND METHOD |
JP7303625B2 (ja) * | 2018-12-18 | 2023-07-05 | キヤノン株式会社 | 画像ファイル生成装置、画像ファイル生成方法、及びプログラム |
GB2585052B (en) * | 2019-06-26 | 2023-07-26 | Canon Kk | Method and apparatus for encapsulating panorama images in a file |
EP3992916A4 (en) * | 2019-07-01 | 2023-06-21 | Canon Kabushiki Kaisha | DEVICE, METHOD AND PROGRAM FOR GENERATION OF IMAGE FILES |
US11172232B2 (en) * | 2019-09-06 | 2021-11-09 | Sharp Kabushiki Kaisha | Systems and methods for signaling level information in video coding |
US11722751B2 (en) | 2020-01-07 | 2023-08-08 | Nokia Technologies Oy | Method, an apparatus and a computer program product for video encoding and video decoding |
US11683529B2 (en) * | 2020-09-17 | 2023-06-20 | Lemon Inc. | Operational point sample group in coded video |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1812583A (zh) * | 2005-09-22 | 2006-08-02 | 上海广电(集团)有限公司中央研究院 | 块组编码结构及基于该结构的自适应分阶段预测编码方法 |
CN1939060A (zh) * | 2004-02-10 | 2007-03-28 | 汤姆逊许可公司 | 采用avc文件格式对先进视频编码(avc)参数集的存储 |
US20140314148A1 (en) * | 2013-04-17 | 2014-10-23 | Nokia Corporation | Apparatus, a method and a computer program for video coding and decoding |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2004235739A (ja) | 2003-01-28 | 2004-08-19 | Sony Corp | 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム |
US8949737B2 (en) * | 2009-10-28 | 2015-02-03 | Red Hat, Inc. | Centralized application package distribution |
KR101404251B1 (ko) | 2010-09-10 | 2014-06-09 | 한국전자통신연구원 | 컨텐츠의 부가서비스 정보를 보조 단말기에 표시하는 시스템 및 방법 |
JP5569830B2 (ja) | 2011-03-25 | 2014-08-13 | 日本電気株式会社 | 映像処理システム、映像処理方法、映像処理装置及びその制御方法と制御プログラム |
-
2015
- 2015-02-09 US US14/617,266 patent/US10291561B2/en active Active
-
2016
- 2016-02-02 CN CN201680019302.0A patent/CN107431810B/zh active Active
- 2016-02-02 WO PCT/FI2016/050063 patent/WO2016128612A1/en active Application Filing
- 2016-02-02 EP EP16748774.3A patent/EP3257244B1/en active Active
- 2016-02-02 KR KR1020177025156A patent/KR101949071B1/ko active IP Right Grant
- 2016-02-02 JP JP2017559922A patent/JP6649404B2/ja active Active
-
2017
- 2017-09-01 ZA ZA2017/05953A patent/ZA201705953B/en unknown
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1939060A (zh) * | 2004-02-10 | 2007-03-28 | 汤姆逊许可公司 | 采用avc文件格式对先进视频编码(avc)参数集的存储 |
CN1812583A (zh) * | 2005-09-22 | 2006-08-02 | 上海广电(集团)有限公司中央研究院 | 块组编码结构及基于该结构的自适应分阶段预测编码方法 |
US20140314148A1 (en) * | 2013-04-17 | 2014-10-23 | Nokia Corporation | Apparatus, a method and a computer program for video coding and decoding |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108876882A (zh) * | 2018-06-26 | 2018-11-23 | 史艳艳 | 一种画面非循环的gif文件播放方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
EP3257244A4 (en) | 2018-10-17 |
WO2016128612A1 (en) | 2016-08-18 |
US10291561B2 (en) | 2019-05-14 |
EP3257244A1 (en) | 2017-12-20 |
ZA201705953B (en) | 2019-09-25 |
CN107431810B (zh) | 2020-06-05 |
KR101949071B1 (ko) | 2019-02-15 |
EP3257244B1 (en) | 2022-07-27 |
US20160234144A1 (en) | 2016-08-11 |
KR20170116089A (ko) | 2017-10-18 |
JP6649404B2 (ja) | 2020-02-19 |
JP2018510595A (ja) | 2018-04-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
RU2746934C9 (ru) | Межуровневое предсказание для масштабируемого кодирования и декодирования видеоинформации | |
CN107431810A (zh) | 用于图像编码和解码的装置、方法和计算机程序 | |
KR102089457B1 (ko) | 비디오 코딩 및 디코딩을 위한 장치, 방법 및 컴퓨터 프로그램 | |
CN112673638B (zh) | 处理媒体数据的方法和装置 | |
US9800893B2 (en) | Apparatus, a method and a computer program for video coding and decoding | |
JP6417039B2 (ja) | 画像シーケンスのコーディングおよびデコーディングのための装置、方法およびコンピュータ・プログラム | |
KR20220087577A (ko) | 비디오 코딩 및 디코딩을 위한 장치, 방법 및 컴퓨터 프로그램 | |
CN109155861A (zh) | 用于编码媒体内容的方法和装置以及计算机程序 | |
CN107113476A (zh) | 用于视频流的方法、装置以及计算机可读存储介质 | |
EP3566458B1 (en) | Improved restricted scheme design for video | |
WO2017140946A1 (en) | An apparatus, a method and a computer program for video coding and decoding | |
CN114270868A (zh) | 用于在视频编码中处理随机访问图片的装置、方法和计算机程序 | |
EP4266690A1 (en) | An apparatus, a method and a computer program for video coding and decoding | |
WO2023203423A1 (en) | Method and apparatus for encoding, decoding, or displaying picture-in-picture | |
CN117296326A (zh) | 用于视频编码和视频解码的方法、装置和计算机程序产品 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |