CN107113476B - 用于视频流的方法、装置以及计算机可读存储介质 - Google Patents

用于视频流的方法、装置以及计算机可读存储介质 Download PDF

Info

Publication number
CN107113476B
CN107113476B CN201580073022.3A CN201580073022A CN107113476B CN 107113476 B CN107113476 B CN 107113476B CN 201580073022 A CN201580073022 A CN 201580073022A CN 107113476 B CN107113476 B CN 107113476B
Authority
CN
China
Prior art keywords
representation
segment
data units
view
picture
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
CN201580073022.3A
Other languages
English (en)
Other versions
CN107113476A (zh
Inventor
K·乌尔
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 CN107113476A publication Critical patent/CN107113476A/zh
Application granted granted Critical
Publication of CN107113476B publication Critical patent/CN107113476B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/21805—Source of audio or video content, e.g. local disk arrays enabling multiple viewpoints, e.g. using a plurality of cameras
    • 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/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
    • H04N21/23439—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 for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H04N21/4383—Accessing a communication channel
    • H04N21/4384—Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4621—Controlling the complexity of the content stream or additional data, e.g. lowering the resolution or bit-rate of the video stream for a mobile client with a small screen
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]

Abstract

一种方法，包括：由客户机请求来自服务器的视频内容分量的独立地编码的第一表示；接收并播放所述独立地编码的第一表示的第一组数据单元；请求第二表示的第二组数据单元，所述第二组数据单元在所述第一组数据单元的一个或多个被请求或被缓冲数据单元上被相依地编码；以及请求第三表示的第三组独立地编码的数据单元。

Description

用于视频流的方法、装置以及计算机可读存储介质
技术领域
本发明涉及用于视频编码和解码的装置、方法以及计算机程序。
背景技术
最近，超文本传输协议(HTTP)已广泛用于例如在视频流应用中通过因特网传送实时多媒体内容。不同于使用用户数据报协议(UDP)上的实时传输协议(RTP)，HTTP易于配置并且通常允许穿过防火墙和网络地址转换器(NAT)，这使其对多媒体流应用具有吸引力。
已推出用于HTTP自适应流的数种商业解决方案，例如
Figure BDA0001346634540000011
SmoothStreaming、
Figure BDA0001346634540000012
Adaptive HTTP Live Streaming和
Figure BDA0001346634540000013
DynamicStreaming，以及已执行标准化项目。DASH已证明是用于多媒体流应用的有前途的协议，特别是用于多视图编码的视频双向流。但是，流客户机通常维持相对大的缓冲区占用级别，以便避免由于吞吐量波动而导致的重放中断。对于MVC位流中的视点切换，这意味着将过量视图传输到客户机以便实现立即视点切换。
通过DASH的流ISOBMFF段中的原子单元是自包含的电影片段，其通常相对较大。DASH客户机通常接收至少一个完整的自包含电影片段，然后处理该片段，因此DASH客户机中的缓冲区占用级别通常为至少一个电影片段。
例如，如果对视点切换请求的反应缓慢，则自由视点流应用的体验质量可能明显劣化。当视点切换作为对头部和/或视线跟踪的响应发生时，这可能尤其如此。
因此，需要一种方法，其用于在使用DASH获得视图时执行低延时视点切换，但同时使传输的视频的比特率尽可能低，并且就计算和存储器要求而言使解码复杂度尽可能低。
发明内容
现在为了至少缓解上面的问题，在此引入一种用于启动视点切换的方法。
一种根据第一方面的方法包括
由客户机请求来自服务器的视频内容分量的独立地编码的第一表示；
接收并播放所述独立地编码的第一表示的第一组数据单元；
请求第二表示的第二组数据单元，所述第二组数据单元在所述第一组数据单元的一个或多个被请求或被缓冲数据单元上被相依地编码；以及
请求第三表示的第三组独立地编码的数据单元。
根据一个实施例，所述第一组数据单元包括多视图编码的位流的第一视图的段或子段，并且所述第二和第三组数据单元包括所述多视图编码的位流的第二视图的段或子段。
根据一个实施例，所述方法进一步包括：
确定所述第二组数据单元的第一段或子段，以使得所述第一段或子段对应于到所述第二组数据单元的所述第一段或子段被接收时为止所述第一组数据单元的已被下载或估计将被下载的段或子段。
根据一个实施例，所述方法进一步包括：
确定所述第二组数据单元的所述第一段或子段，以使得所述第一段或子段对应于所述第二组数据单元中的内部随机访问点(IRAP)图片。
根据一个实施例，所述方法进一步包括：
请求播放时间在所述第二组数据单元的段或子段之后的所述第三表示的段或子段。
根据一个实施例，所述方法进一步包括：
继续请求所述第一和所述第二表示的段或子段。
根据一个实施例，所述方法进一步包括：
请求所述第二组数据单元作为从所述第一组数据单元预测的视图间预测视图。
根据一个实施例，所述方法进一步包括：
请求所述第二组数据单元作为所述第一组数据单元的深度视图；以及
应用基于深度图像的呈现(DIBR)或前向视图合成以便生成所述第二表示。
根据一个实施例，所述第一表示包括所述视频内容分量的低比特率单层流，所述第二表示包括所述视频内容分量的所述低比特率流的增强可伸缩性层，并且所述第三表示包括所述视频内容分量的高比特率单层流。
根据一个实施例，所述方法进一步包括：
请求所述第二表示的所述第二组数据单元作为对接收用户请求或者所述客户机确定切换到所述视频内容分量的高分辨率表示的响应。
第二方面涉及一种装置，包括
至少一个处理器和至少一个存储器，所述至少一个存储器在其上存储有代码，当由所述至少一个处理器执行时，所述代码导致所述装置至少执行
请求来自服务器的视频内容分量的独立地编码的第一表示；
接收并播放所述独立地编码的第一表示的第一组数据单元；
请求第二表示的第二组数据单元，所述第二组数据单元在所述第一组数据单元的一个或多个被请求或被缓冲数据单元上被相依地编码；以及
请求第三表示的第三组独立地编码的数据单元。
第三方面涉及一种计算机可读存储介质，其上存储有代码以便由装置使用，当由处理器执行时，所述代码导致所述装置执行：
请求来自服务器的视频内容分量的独立地编码的第一表示；
接收并播放所述独立地编码的第一表示的第一组数据单元；
请求第二表示的第二组数据单元，所述第二组数据单元在所述第一组数据单元的一个或多个被请求或被缓冲数据单元上被相依地编码；以及
请求第三表示的第三组独立地编码的数据单元。
附图说明
为了更好地理解本发明，现在将通过实例的方式参考附图，这些附图是：
图1示意性地示出采用本发明实施例的电子设备；
图2示意性地示出适合于采用本发明实施例的用户设备；
图3进一步示意性地示出使用无线和有线网络连接而连接的采用本发明实施例的电子设备；
图4示意性地示出适合于实现本发明实施例的编码器；
图5示出用于自由视点导航的系统的一个实例；
图6示出在DASH中使用的分层数据模型的一个实例；
图7示出根据本发明实施例的流客户机的操作的流程图；
图8示出根据本发明实施例的客户机的一个实例操作；
图9示出根据本发明实施例的客户机的另一个实例操作；
图10示出适合于实现本发明实施例的解码器的示意图；以及
图11示出其中可以实现各种实施例的实例多媒体通信系统的示意图。
具体实施方式
下面进一步详细地描述用于启动视点切换的合适装置和可能机制。在这点上，首先参考图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，其允许移动电话网络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值。
可用的媒体文件格式标准包括ISO基础媒体文件格式(ISO/IEC 14496-12，其可以缩写为ISOBMFF)、MPEG-4文件格式(ISO/IEC 14496-14，也被称为MP4格式)、用于NAL单元结构化视频的文件格式(ISO/IEC 14496-15)以及3GPP文件格式(3GPP TS 26.244，也被称为3GP格式)。ISO文件格式是导出所有上述文件格式(不包括ISO文件格式本身)的基础。这些文件格式(包括ISO文件格式本身)通常被称为ISO文件格式族。
下面描述ISOBMFF的某些概念、结构和规范作为容器文件格式的一个实例，基于此可以实现各实施例。本发明的各个方面并不限于ISOBMFF，而是针对一个可能的基础提供描述，在该基础之上可以部分或全部实现本发明。
ISO基础媒体文件格式中的基本构件块被称为盒。每个盒具有标头和有效负载。盒标头指示盒的类型和盒的大小(以字节为单位)。盒可以包围其它盒，并且ISO文件格式指定在某一类型的盒内允许哪些盒类型。此外，在每个文件中某些盒的存在可能是强制的，而其它盒的存在可能是可选的。此外，对于某些盒类型，可以允许文件中存在多于一个的盒。因此，ISO基础媒体文件格式可以被视为指定盒的分层结构。
根据ISO文件格式族，文件包括被封装到盒中的媒体数据和元数据。每个盒由四字符代码(4CC)标识并且以标头开头，该标头通知盒的类型和大小。
在符合ISO基础媒体文件格式的文件中，可以在媒体数据“mdat”盒中提供媒体数据，并且可以使用电影“moov”盒包围元数据。在某些情况下，为了使文件可操作，可能需要存在“mdat”和“moov”盒两者。电影“moov”盒可以包括一个或多个轨道，并且每个轨道可以驻留在一个对应的轨道“trak”盒中。轨道可以是许多类型之一，包括媒体轨道，媒体轨道指根据媒体压缩格式(以及其到ISO基础媒体文件格式的封装)格式化的样本。轨道可以被视为逻辑信道。
例如当将内容记录到ISO文件时，可以使用电影片段，例如以便如果发生记录应用崩溃、存储空间用完或某个其它事件，则避免丢失数据。如果没有电影片段，则可能发生数据丢失，因为文件格式可能需要将所有元数据(例如，电影盒)写入文件的一个连续区域中。此外，当记录文件时，可能没有足够量的存储空间(例如，随机存取存储器RAM)来缓冲可用存储装置大小的电影盒，并且当电影关闭时重新计算电影盒的内容可能太慢。此外，电影片段可以使用常规ISO文件解析器实现文件的同时记录和重放。此外，与具有相同媒体内容但在没有电影片段的情况下结构化的文件相比，当使用电影片段并且初始电影盒较小时，循序式下载(例如，文件的同时接收和重放)可能需要较小的初始缓冲持续时间。
电影片段特性可以使能将元数据(其否则可能驻留在电影盒中)分成多个小片(piece)。每个小片可以对应于轨道的某一时间段。换言之，电影片段特性可以使文件元数据和媒体数据能够交错。因此，可以限制电影盒的大小并且实现上述用例。
在某些实例中，电影片段的媒体样本可能驻留在mdat盒中，前提是它们与moov盒在同一文件中。但是，对于电影片段的元数据，可以提供moof盒。moof盒可以包括先前已在moov盒中的某一重放持续时间的信息。moov盒仍然可以独立地表示有效电影，但此外，它可以包括mvex盒，mvex盒指示同一文件中之后是电影片段。电影片段可以及时扩展与moov盒关联的呈现。
在电影片段内，可以具有一组轨道片段，每个轨道包括从零到多个片段。轨道片段又可以包括从零到多个轨道路线(track run)，每个文档是该轨道的样本的连续路线。在这些结构内，许多字段是可选的并且可以取默认值。可以包括在moof盒中的元数据可以被限制为可以包括在moov盒中的元数据的子集，并且在某些情况下可以以不同的方式被编码。可以从ISO基础媒体文件格式规范中找到关于可以被包括在moof盒中的盒的细节。独立的电影片段可以被定义为由文件顺序连续的moof盒和mdat盒组成，并且其中mdat盒包含电影片段(moof盒针对其提供元数据)的样本，并且不包含任何其它电影片段(即，任何其它moof盒)的样本。
ISO基础媒体文件格式针对可以与特定样本关联的定时元数据包含三个机制：样本组、定时元数据轨道、以及样本辅助信息。导出规范可以提供与这三个机制中的一个或多个类似的功能。
可以基于编组标准，将ISO基础媒体文件格式及其派生物(例如AVC文件格式和SVC文件格式)中的样本编组定义为分配轨道中的每个样本以便成为一个样本组的成员。样本编组中的样本组并不限于是连续样本，并且可能包含非相邻样本。因为轨道中的样本可能具有多于一个样本编组，每个样本编组可能具有类型字段以便指示编组类型。样本编组可以由两个链接的数据结构表示：(1)SampleToGroup盒(sbgp盒)表示将样本分配给样本组；以及(2)SampleGroupDescription盒(sgpd盒)包含每个样本组的样本组条目，其描述该组的属性。基于不同的编组标准，可以具有SampleToGroup和SampleGroupDescription盒的多个实例。这些实例可以通过用于指示编组类型的类型字段来区分。
ISOBMFF包括所谓的级别机制以便指定文件的子集。级别遵循依赖性层次结构以使得映射到级别n的样本可以依赖于级别m的任何样本，其中m<＝n，并且不依赖于级别p的任何样本，其中p>n。例如，可以根据时间子层(例如，SVC或MVC的temporal_id或者HEVC的TemporalId)指定级别。可以在“电影扩展”(“mvex”)盒中包含的“级别分配”(“leva”)盒中公布级别。不能针对初始电影指定级别。当“级别分配”盒存在时，它适用于初始电影之后的所有电影片段。对于“级别分配”盒的上下文，一部分被定义为由一个或多个“电影片段”盒和关联的“媒体数据”盒组成，可能仅包括最后一个“媒体数据”盒的初始部分。在一部分内，每个级别的数据连续出现。一部分内的级别数据按级别值的升序出现。一部分中的所有数据将被分配给级别。“级别分配”盒提供从特性(例如可伸缩性层)到级别的映射。可以通过轨道、轨道内的子轨道、或者轨道的样本编组来指定特性。“级别分配”盒包括句法元素padding_flag。padding_flag等于1指示可以通过以下操作形成一致部分：串接一部分内的任何正整数个级别，并且通过零字节填充最后一个“媒体数据”盒，直到在最后一个“媒体数据”盒的标头中指示的完整大小。例如，可以在以下情况下将padding_flag设置等于1：每个部分包含同一视频位流的两个或更多AVC、SVC或MVC轨道，一部分的每个轨道的样本在“媒体数据”盒中是连续的并且采用解码顺序，并且第一AVC、SVC或MVC级别的样本包含提取器NAL单元以便包括来自同一部分的其它级别的视频编码NAL单元。
Matroska文件格式能够(但不限于)将视频、音频、图片、或者副标题轨道中的任一者存储在一个文件中。Matroska可以用作导出文件格式(例如WebM)的基础格式。Matroska使用可扩展二进制元语言(EBML)作为基础。EBML指定由XML原理启发的二进制和八位字节(字节)对齐格式。EBML本身是二进制标记技术的广义描述。Matroska文件由构成EBML“文档”的元素组成。元素包含元素ID、元素大小的描述符、以及二进制数据本身。元素可以被嵌套。Matroska的段元素是其它顶级(级别1)元素的容器。Matroska文件可以包括一个段(但不限于由一个段组成)。Matroska文件中的多媒体数据被组织在群集(或群集元素)中，每个群集通常包含几秒钟的多媒体数据。群集包括BlockGroup元素，其又包括块元素。提示元素包括元数据，其可以有助于随机访问或搜索，并且可以包括用于搜索点的文件指针或相应时间戳。
视频编解码器由编码器和解码器组成，编码器将输入视频转换成适合于存储/传输的压缩表示，解码器可以将压缩视频表示解压缩回可查看形式。视频编码器和/或视频解码器还可以彼此分离，即，不需要形成编解码器。通常，编码器丢弃原始视频序列中的某些信息，以便以更紧凑的形式(即，以较低比特率)表示视频。
典型的混合视频编码器(例如ITU-T H.263和H.264的许多编码器实现)以两个阶段对视频信息进行编码。首先，例如通过运动补偿手段(发现并且指示密切对应于正在被编码的块的先前编码的视频帧之一中的区域)或者通过空间手段(以指定方式使用要被编码的块周围的像素值)，预测某一图片区域(或“块”)中的像素值。其次，对预测误差(即，预测像素块与原始像素块之间的差)进行编码。这通常通过以下操作完成：使用指定变换(例如离散余弦变换(DCT)或其变型)转换像素值的差，量化系数并且对量化后的系数进行熵编码。通过改变量化过程的保真度，编码器能够控制像素表示的准确性(图片质量)与产生的编码视频表示的大小(文件大小或传输比特率)之间的平衡。
帧间预测(也可以被称为时间预测、运动补偿、或者运动补偿预测)减少时间冗余性。在帧间预测中，预测源是先前解码的图片。帧内预测使用以下事实：同一图片内的相邻像素很可能相关。可以在空间或变换域中执行帧内预测，即，可以预测样本值或变换系数。通常在不应用帧间预测的帧内编码中利用帧内预测。
编码过程的一个结果是一组编码参数，例如运动向量和量化变换系数。可以更有效地对许多参数进行熵编码，前提是首先从空间或时间相邻的参数预测这些参数。例如，可以从空间相邻的运动向量预测运动向量，并且仅可以对相对于运动向量预测器的差进行编码。编码参数预测和帧内预测可以被统称为图片内预测。
图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(10/2014)，并且可能在2015年被发布为第2版ISO/IEC 23008-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中，图片可以是帧或字段。帧包括亮度样本的矩阵，并且可能包括对应的色度样本。字段是帧的一组交替样本行，并且当源信号交错时，字段可以用作编码器输入。色度样本阵列可能不存在(并且因此可能使用单色采样)，或者当与亮度样本阵列相比时，色度样本阵列可能被二次采样(subsampled)。色度格式可以被总结如下：
-在单色采样中，只有一个样本阵列，其名义上可以被视为亮度阵列。
-在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中，分片被定义为在同一访问单元内，包含在一个独立分片段(slice segment)以及在下一个独立分片段(如果有)之前的所有后续相关分片段(如果有)中的整数个编码树单元。在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单元的时间标识符，并且可以按照以下方式导出基于零的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单元可以被指示为以下类型之一：
Figure BDA0001346634540000231
Figure BDA0001346634540000241
在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)可以被定义为这样的句法结构：其包含应用于零个或更多个完整编码视频序列的句法元素，这些编码视频序列如由在某一句法元素(其由在每个分片段标头中发现的句法元素参考的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单元可以指示访问单元的开始。它后面跟着零个或更多个SEI NAL单元。接下来出现主要编码图片的编码分片。在H.264/AVC中，主要编码图片的编码分片后面可以跟着零个或更多个冗余编码图片的编码分片。冗余编码图片是图片或图片一部分的编码表示。如果例如由于传输损耗或者物理存储介质损坏，解码器未接收主要编码图片，则可以对冗余编码图片进行解码。
在H.264/AVC中，访问单元还可以包括辅助编码图片，它是补充主要编码图片的图片，并且可以例如用于显示过程。辅助编码图片可以例如被用作阿尔法信道或阿尔法平面，其指定解码图片中的样本的透明度级别。阿尔法信道或平面可以用于分层组成或呈现系统，其中输出图片通过在彼此之上叠加至少部分透明的图片而形成。辅助编码图片具有与单色冗余编码图片相同的句法和语义限制。在H.264/AVC中，辅助编码图片包含的宏块的数量与主要编码图片相同。
在HEVC中，编码图片可以被定义为包含图片的所有编码树单元的图片编码表示。在HEVC中，访问单元(AU)可以被定义为一组NAL单元，这些NAL单元根据指定分类规则彼此关联、按解码顺序连续、以及最多包含一个具有任何特定nuh_layer_id值的图片。除了包含编码图片的VCL NAL单元之外，访问单元还可以包含非VCL NAL单元。
可以例如按照以下方式指定所述指定分类规则。位流中的第一访问单元从位流的第一NAL单元开始。当所有以下条件都为真时，VCL NAL单元是访问单元的第一VCL NAL单元：
-包含在VCL NAL单元中的分片是编码图片的第一切片，这在HEVC中相当于first_slice_segment_in_pic_flag等于1的条件。
-按解码顺序的前一个编码图片属于差异访问单元，这在HEVC多层扩展中对应于以下至少一个条件为真：
○按解码顺序的前一个图片属于与包含VCL NAL单元的图片不同的POC复位周期。
○针对VCL NAL单元导出的PicOrderCntVal不同于按解码顺序的前一个图片的PicOrderCntVal。
NAL单元中的第一个NAL单元开始访问单元，该第一个NAL单元由NAL单元规范允许以按解码顺序在访问单元的第一个VCL NAL单元firstVclNalUnitInAu之前出现在访问单元中，并且按解码顺序在前一个访问单元的最后一个VCL NAL单元之后。在HEVC中，以下任何NAL单元的第一个指定新访问单元的开始，该第一个NAL单元在第一个VCL NAL单元firstVclNalUnitInAu之前并且在firstVclNalUnitInAu之前的最后一个VCL NAL单元(如果有)之后：
-访问单元分隔符NAL单元(当存在时)
-VPS NAL单元(当存在时)
-SPS NAL单元(当存在时)
-PPS NAL单元(当存在时)
-前缀SEI NAL单元(当存在时)
-nal_unit_type在RSV_NVCL41..RSV_NVCL44范围内的NAL单元(当存在时)
-nal_unit_type在UNSPEC48..UNSPEC55范围内的NAL单元(当存在时)
当在firstVclNalUnitInAu之前并且在firstVclNalUnitInAu之前的最后一个VCLNAL单元(如果有)之后没有上面的NAL单元时，firstVclNalUnitInAu开始新的访问单元。
可能需要编码图片在访问单元内以某一顺序出现。例如，在同一访问单元中，可能需要nuh_layer_id等于nuhLayerIdA的编码图片按解码顺序在nuh_layer_id大于nuhLayerIdA的所有编码图片之前。
可能需要访问单元内的编码图片和非VCL NAL单元的顺序遵守某一约束，例如针对HEVC多层扩展指定的以下约束：
-当访问单元分隔符NAL单元存在时，它将是第一个NAL单元。任何访问单元中将最多具有一个访问单元分隔符NAL单元。
-当任何VPS NAL单元、SPS NAL单元、PPS NAL单元、前缀SEI NAL单元、nal_unit_type在范围RSV_NVCL41..RSV_NVCL44内的NAL单元、或者nal_unit_type在范围UNSPEC48..UNSPEC55内的NAL单元存在时，它们将不在访问单元的最后一个VCL NAL单元之后。
-nal_unit_type等于FD_NUT或SUFFIX_SEI_NUT或者在范围RSV_NVCL45..RSV_NVCL47或UNSPEC56..UNSPEC63内的NAL单元将不在访问单元的第一个VCL NAL单元之前。
-当具有nuh_layer_id nuhLayerId的序列NAL单元的结尾存在时，它将是访问单元中nuh_layer_id等于nuhLayerId的最后一个NAL单元，而不是位流NAL单元的结尾(当存在时)。
-当位流NAL单元的结尾存在时，它将是访问单元的最后一个NAL单元。
在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单元是关联的VCLNAL单元。例如，在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访问单元的零个或更多个访问单元，包括所有后续访问单元直到但不包括作为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)的图片可以是参考图片或非参考图片。
H.264/AVC指定用于解码参考图片标记的过程，以便控制解码器中的内存消耗。用于帧间预测的最大参考图片数量(被称为M)在序列参数集中确定。当对参考图片进行解码时，将其标记为“用于参考”。如果参考图片的解码导致多于M个图片被标记为“用于参考”，则将至少一个图片标记为“未用于参考”。两种类型的操作可用于解码参考图片标记：自适应内存控制和滑动窗口。基于图片选择用于解码参考图片标记的操作模式。自适应内存控制使能用显式信号通知哪些图片被标记为“未用于参考”，并且还可以将长期索引分配给短期参考图片。自适应内存控制可能需要在位流中存在内存管理控制操作(MMCO)参数。MMCO参数可以被包括在解码参考图片标记句法结构中。如果使用滑动窗口操作模式，并且M个图片被标记为“用于参考”，则将以下短期参考图片标记为“未用于参考”：它是被标记为“用于参考”的那些短期参考图片中的第一个解码图片。换言之，滑动窗口操作模式在短期参考图片中导致先进先出缓冲操作。
H.264/AVC中的内存管理控制操作中的一个操作导致所有参考图片(当前图片除外)都被标记为“未用于参考”。瞬时解码刷新(IDR)图片仅包含帧内编码分片，并且导致参考图片的类似的“重置”。
在HEVC中，不使用参考图片标记句法结构和相关解码过程，而是改为使用参考图片集(RPS)句法结构和解码过程以便实现类似目的。针对图片有效或活动的参考图片集包括被用作图片参考的所有参考图片、以及针对按解码顺序的任何后续图片被保持标记为“用于参考”的所有参考图片。参考图片集具有六个子集，即被称为RefPicSetStCurr0(又被称为RefPicSetStCurrBefore)、RefPicSetStCurr1(又被称为RefPicSetStCurrAfter)、RefPicSetStFoll0、RefPicSetStFoll1、RefPicSetLtCurr、以及RefPicSetLtFoll。RefPicSetStFoll0和RefPicSetStFoll1还可以被视为共同形成一个子集RefPicSetStFoll。六个子集的表示法如下。“Curr”指以下参考图片：它们被包括在当前图片的参考图片列表中，并且因此可以被用作当前图片的帧间预测参考。“Foll”指以下参考图片：它们未被包括在当前图片的参考图片列表中，但可以作为参考图片用于按解码顺序的后续图片。“St”指短期参考图片，它们通常可以通过其POC值的某一数量的最低有效位来标识。“Lt”指长期参考图片，它们被明确地标识，并且相对于当前图片的POC值差通常大于提及的某一数量的最低有效位可以表示的POC值差。“0”指POC值小于当前图片的POC值的那些参考图片。“1”指POC值大于当前图片的POC值的那些参考图片。RefPicSetStCurr0、RefPicSetStCurr1、RefPicSetStFoll0和RefPicSetStFoll1被统称为参考图片集的短期子集。RefPicSetLtCurr和RefPicSetLtFoll被统称为参考图片集的长期子集。
在HEVC中，参考图片集可以在序列参数集中指定，并且通过指向参考图片集的索引用于分片标头。参考图片集还可以在分片标头中指定。参考图片集可以被独立地编码，或者可以从另一个参考图片集被预测(被称为帧间RPS预测)。在两种类型的参考图片集编码中，另外针对每个参考图片发送标志(used_by_curr_pic_X_flag)，其指示参考图片用于由当前图片参考(包括在*Curr列表中)还是不由当前图片参考(包括在*Foll列表中)。将包括在由当前分片使用的参考图片集中的图片标记为“用于参考”，并且将未在由当前分片使用的参考图片集中的图片标记为“未用于参考”。如果当前图片是IDR图片，则RefPicSetStCurr0、RefPicSetStCurr1、RefPicSetStFoll0、RefPicSetStFoll1、RefPicSetLtCurr、以及RefPicSetLtFoll均被设置为空。
可以在编码器和/或解码器中使用解码图片缓冲区(DPB)。缓冲解码图像有两个原因：用于帧间预测中的参考、以及用于将解码图片重新排序为输出顺序。因为H.264/AVC和HEVC针对参考图片标记和输出重新排序提供很大的灵活性，所以用于参考图片缓冲和输出图片缓冲的单独缓冲区可能浪费内存资源。因此，DPB可以包括用于参考图片和输出重新排序的统一解码图片缓冲过程。当解码图片不再用作参考并且不需要用于输出时，可以从DPB中删除该解码图片。
在H.264/AVC和HEVC的许多编码模式中，使用指向参考图片列表的索引指示用于帧间预测的参考图片。可以使用可变长度编码对索引进行编码，这通常导致更小索引针对对应句法元素具有更短值。在H.264/AVC和HEVC中，针对每个双预测(B)分片生成两个参考图片列表(参考图片列表0和参考图片列表1)，并且针对每个帧间编码(P)分片形成一个参考图片列表(参考图片列表0)。
通常以两个步骤构造参考图片列表(例如参考图片列表0和参考图片列表1)：首先，生成初始参考图片列表。可以例如基于frame_num、POC、temporal_id(或TemporalId等)、或者有关预测层次结构(例如GOP结构)的信息或它们的任意组合，生成初始参考图片列表。其次，可以通过参考图片列表重新排序(RPLR)命令，对初始参考图片列表进行重新排序，这些命令也被称为参考图片列表修改句法结构，它们可以被包含在分片标头中。在H.264/AVC中，RPLR命令指示排序到相应参考图片列表的开头的图片。该第二步也可以被称为参考图片列表修改过程，并且RPLR命令可以被包括在参考图片列表修改句法结构中。如果使用参考图片集，则可以初始化参考图片列表0以便首先包含RefPicSetStCurr0，随后是RefPicSetStCurr1，随后是RefPicSetLtCurr。可以初始化参考图片列表1以便首先包含RefPicSetStCurr1、随后是RefPicSetStCurr0。在HEVC中，可以通过参考图片列表修改句法结构，修改初始参考图片列表，其中可以通过指向列表的条目索引，标识初始参考图片列表中的图片。换言之，在HEVC中，参考图片列表修改被编码成句法结构，其包括最终参考图片列表中的每个条目上的循环，其中每个循环条目是指向初始参考图片列表的固定长度编码索引，并且指示最终参考图片列表中按上升位置顺序的图片。
包括H.264/AVC和HEVC的许多编码标准可以具有解码过程以便导出指向参考图片列表的参考图片索引，该索引可以用于指示多个参考图片的哪一个用于特定块的帧间预测。在某些帧间编码模式下，参考图片索引可以由编码器编码到位流中，或者在某些其它帧间编码模式下，它可以例如使用相邻块(由编码器和解码器)导出。
为了在位流中有效地表示运动向量，运动向量可以相对于块特定的预测运动向量进行差分编码。在许多视频编解码器中，例如通过计算相邻块的编码或解码运动向量的中值，以预定义方式产生预测运动向量。用于产生运动向量预测的另一种方式(有时被称为高级运动向量预测(AMVP))是从时间参考图片中的相邻块和/或协同定位块生成一系列候选预测，并且用信号通知所选择的候选者作为运动向量预测器。除了预测运动向量值之外，还可以预测先前编码/解码的图片的参考索引。通常从时间参考图片中的相邻块和/或协同定位块预测参考索引。通常跨分片边界禁用运动向量的差分编码。
可伸缩视频编码指这样的编码结构：其中一个位流可以包含例如不同比特率、分辨率或帧速率下的内容的多个表示。在这些情况下，接收器可以根据其特性(例如与显示设备最佳匹配的分辨率)提取所需表示。备选地，服务器或网络元件可以例如根据网络特性或接收器的处理能力，提取要传输到接收器的位流的各部分。可以通过仅对可伸缩位流的某些部分进行解码，产生有意义的解码表示。可伸缩位流通常包括“基础层”和一个或多个增强层，基础层提供最低质量的可用视频，增强层与较低层一起在接收视频并对其进行解码时增强视频质量。为了改进增强层的编码效率，该层的编码表示通常取决于较低层。例如，可以从较低层预测增强层的运动和模式信息。同样，较低层的像素数据可以用于产生针对增强层的预测。
在某些可伸缩视频编码方案中，可以将视频信号编码到基础层和一个或多个增强层中。增强层可以例如增强时间分辨率(即，帧率)、空间分辨率，或者仅增强由另一个层或其部分表示的视频内容的质量。每个层连同其所有相关层例如是视频信号在某一空间分辨率、时间分辨率和质量级别的一个表示。在本文档中，将可伸缩层连同其所有相关层称为“可伸缩层表示”。可以提取对应于可伸缩层表示的可伸缩位流部分并且对其进行解码，以便在某一保真度下产生原始信号的表示。
可伸缩性模式或可伸缩性维度可以包括但不限于以下内容：
-质量可伸缩性：基础层图片与增强层图片相比在较低质量下进行编码，增强层图片可以例如在基础层中(与在增强层中相比)使用较大量化参数值(即，用于变换系数量化的较大量化步长)获得。质量可伸缩性可以进一步分类为细粒或细粒度可伸缩性(FGS)、中粒或中粒度可伸缩性(MGS)、和/或粗粒或粗粒度可伸缩性(CGS)，如下所述。
-空间可伸缩性：基础层图片与增强层图片相比在较低分辨率下(即，具有较少样本)进行编码。空间可伸缩性和质量可伸缩性(特别是其粗粒度可伸缩性类型)有时可以被视为相同类型的可伸缩性。
-位深度可伸缩性：基础层图片与增强层图片(例如10或12位)相比在较低位深度(例如8位)下进行编码。
-动态范围可伸缩性：可伸缩层表示使用不同色调映射函数和/或不同光学传递函数获得的不同动态范围和/或图像。
-色度格式可伸缩性：基础层图片与增强层图片(例如4:4:4格式)相比在色度样本阵列(例如以4:2:0色度格式编码)中提供较低空间分辨率。
-色域可伸缩性：增强层图片与基础层图片相比具有较丰富/较广泛的颜色表示范围—例如增强层可能具有UHDTV(ITU-R BT.2020)色域，并且基础层可能具有ITU-R BT.709色域。
-视图可伸缩性，其也可以被称为多视图编码。基础层表示第一视图，而增强层表示第二视图。
-深度可伸缩性，其也可以被称为深度增强编码。位流的某个层或某些层可以表示纹理视图(多个)，而其它一个或多个层可以表示深度视图(多个)。
-感兴趣区域可伸缩性(如下所述)。
-交错式到循序式可伸缩性(也被称为字段到帧可伸缩性)：基础层的编码交错式源内容材料使用增强层进行增强以便表示循序式源内容。基础层中的编码交错式源内容可以包括编码字段、表示字段对的编码帧、或者它们的混合。在交错式到循序式可伸缩性中，可以对基础层图片进行重新采样以使得它变成一个或多个增强层图片的合适参考图片。
-混合编解码器可伸缩性(也被称为编码标准可伸缩性)：在混合编解码器可伸缩性中，以不同视频编码标准指定基础层和增强层的位流句法、语义和解码过程。因此，根据不同于增强层图片的编码标准或格式对基础层图片进行编码。例如，可以使用H.264/AVC对基础层进行编码，并且可以使用HEVC多层扩展对增强层进行编码。
应该理解，许多可伸缩性类型可以同时被组合和应用。例如，可以组合色域可伸缩性与位深度可伸缩性。
SHVC使能针对色域可伸缩性使用加权预测或基于3D查找表(LUT)的颜色映射过程。可以按照以下方式描述3D LUT方法。首先可以将每个颜色分量的样本值范围分成两个范围，形成多达2x2x2个八分区(octant)，并且然后可以将亮度范围进一步分成四个部分，导致多达8x2x2个八分区。在每个八分区内，应用跨颜色分量线性模型以便执行颜色映射。对于每个八分区，将四个顶点编码到位流中和/或从位流解码以便表示八分区内的线性模型。分别针对每个颜色分量将颜色映射表编码到位流中和/或从位流解码。颜色映射可以被视为涉及三个步骤：第一，确定给定参考层样本三重态(Y,Cb,Cr)所属的八分区。第二，可以通过应用颜色分量调整过程来对齐亮度和色度的样本位置。第三，应用针对确定的八分区指定的线性映射。所述映射可能具有跨分量性质，即，一个颜色分量的输入值可能影响另一个颜色分量的映射值。此外，如果还需要层间重新采样，则重新采样过程的输入是已进行颜色映射的图片。颜色映射可以(但不需要)将第一位深度的样本映射到另一个位深度的样本。
术语层可以在任何类型的可伸缩性(包括视图可伸缩性和深度增强)的上下文中使用。增强层可以指任何类型的增强，例如SNR、空间、多视角、深度、位深度、色度格式、和/或色域增强。基础层可以指任何类型的基础视频序列，例如基础视图、用于SNR/空间可伸缩性的基础层、或者用于深度增强视频编码的纹理基础视图。
目前研究和开发了用于提供三维(3D)视频内容的各种技术。可以认为，在立体或双视图视频中，针对左眼呈现一个视频序列或视图，而针对右眼呈现平行视图。对于实现视点切换的应用或者对于自动立体显示器，可能需要多于两个平行视图，自动立体显示可以同时呈现大量视图，并且让观看者从不同视点观察内容。
视图可以被定义为表示一个摄像机或视点的图片序列。表示视图的图片也可以被称为视图分量。换言之，视图分量可以被定义为单个访问单元中的视图的编码表示。在多视图视频编码中，在位流中对多于一个视图进行编码。因为视图通常意欲在立体或多视图自动立体显示器上显示或者用于其它3D布置，所以它们通常表示相同场景并且在内容方面部分重叠(尽管表示对内容的不同视点)。因此，可以在多视图视频编码中使用视图间预测以便利用视图间相关性并且提高压缩效率。实现视图间预测的一种方式是将一个或多个其它视图的一个或多个解码图片包括在第一视图内被编码或解码的图片的参考图片列表(多个)中。视图可伸缩性可以指这样的多视图视频编码或多视图视频位流：它们使能删除或省略一个或多个编码视图，同时产生的位流保持一致并且表示具有比最初数量少的视图的视频。
某些可伸缩视频编码方案可能需要IRAP图片以这样的方式跨层对齐：访问单元中的所有图片都是IRAP图片，或者访问单元中的图片都不是IRAP图片。其它可伸缩视频编码方案(例如HEVC的多层扩展)可以允许不对齐的IRAP图片，即，访问单元中的一个或多个图片是IRAP图片，而访问单元中的一个或多个其它图片不是IRAP图片。具有不跨层对齐的IRAP图片等的可伸缩位流可以例如用于在基础层中提供更频繁的IRAP图片，其中它们可能具有较小的编码大小(例如由于较小的空间分辨率)。用于逐层启动解码的过程或机制可以被包括在视频解码方案中。因此，当基础层包含IRAP图片时，解码器可以开始位流的解码，并且当其它层包含IRAP图片时，逐步开始对其它层进行解码。换言之，在逐层启动解码机制或过程中，随着在解码过程中对来自其它增强层的后续图片进行解码，解码器逐渐增加解码层的数量(其中层可以表示空间分辨率、质量级别、视图、诸如深度之类的其它分量或组合的增强)。解码层数量的逐渐增加可以例如被视为图片质量的逐渐改进(在质量和空间可伸缩性的情况下)。
逐层启动机制可能在特定增强层中按解码顺序针对第一图片的参考图片生成不可用图片。备选地，解码器可以省略按解码顺序在IRAP图片(可以从中开始层的解码)之前的图片的解码。可以被省略的这些图片可以由编码器或位流内的另一个实体明确标记。例如，可以针对它们使用一个或多个特定NAL单元类型。这些图片(无论它们是被明确标记有NAL单元类型还是例如由解码器推断)可以被称为跨层随机访问跳过(CL-RAS)图片。解码器可以省略生成的不可用图片和解码CL-RAS图片的输出。
可以以两种基本方式实现可伸缩性。即，通过引入用于执行来自可伸缩表示的较低层的像素值或句法的预测的新编码模式，或者通过将较低层图片放置到较高层的参考图片缓冲区(例如，解码图片缓冲区，DPB)。第一种方法可以更灵活，并且因此可以在大多数情况下提供更好的编码效率。但是，第二种基于参考帧的可伸缩性方法可以以对单层编解码器的最小变化而有效地实现，同时仍然获得可用编码效率增益的大部分。基本上，可以通过针对所有层使用相同的硬件或软件实现来实现基于参考帧的可伸缩性编解码器，只是通过外部手段来处理DPB管理。
可以按照以下方式实现用于质量可伸缩性(也被称为信噪比或SNR)和/或空间可伸缩性的可伸缩视频编码器。对于基础层，可以使用常规不可伸缩视频编码器和解码器。基础层的重构/解码图片被包括在增强层的参考图片缓冲区和/或参考图片列表中。在空间可伸缩性的情况下，重构/解码的基础层图片可以在其插入到增强层图片的参考图片列表中之前被上采样。基础层解码图片可以被插入到用于增强层图片的编码/解码的参考图片列表(多个)中，类似于增强层的解码参考图片。因此，编码器可以选择基础层参考图片作为帧间预测参考，并且指示其在编码位流中与参考图片索引一起使用。解码器从位流进行解码，例如从基础层图片被用作增强层的帧间预测参考的参考图片索引进行解码。当解码的基础层图片被用作增强层的预测参考时，其被称为层间参考图片。
尽管前一段描述了具有两个可伸缩性层(具有增强层和基础层)的可伸缩视频编解码器，但需要理解，该描述可以被推广到具有两个层以上的可伸缩性层次结构中的任何两个层。在这种情况下，第二增强层可以在编码和/或解码过程中依赖于第一增强层，并且第一增强层因此可以被视为用于第二增强层的编码和/或解码的基础层。此外，需要理解，在增强层的参考图片缓冲区或参考图片列表中可以具有来自多于一个层的层间参考图片，并且这些层间参考图片的每一者可以被视为驻留在正在被编码和/或解码的增强层的基础层或参考层中。此外，需要理解，可以替代地或另外地进行参考层图片上采样之外的其它类型的层间处理。例如，可以将参考层图片的样本的位深度转换为增强层的位深度和/或样本值可以经历从参考层的颜色空间到增强层的颜色空间的映射。
可伸缩视频编码和/或解码方案可以使用多循环编码和/或解码，其可以描述如下。在编码/解码中，基础层图片可以被重构/解码以便用作同一层内按编码/解码顺序的后续图片的运动补偿参考图片，或者用作层间(或视图间或分量间)预测的参考。重构/解码的基础层图片可以被存储在DPB中。增强层图片同样可以被重构/解码以便用作同一层内按编码/解码顺序的后续图片的运动补偿参考图片，或者用作较高增强层(如果有)的层间(或视图间或分量间)预测的参考。除了重构/解码的样本值之外，可以在层间/分量间/视图间预测中使用基础/参考层的句法元素值或者从基础/参考层的句法元素值导出的变量。
直接参考层可以被定义为这样的层：其可以用于另一个层的层间预测，而该层是另一个层的直接参考层。直接预测层可以被定义为这样的层：另一个层是该层的直接参考层。间接参考层可以被定义为这样的层：其不是第二层的直接参考层而是第三层的直接参考层，第三层是第二层的直接参考层的直接参考层或间接参考层，该层是第二层的间接参考层。间接预测层可以被定义为这样的层：另一个层是该层的间接参考层。独立层可以被定义为这样的层：其没有直接参考层。换言之，独立层不使用层间预测进行预测。非基础层可以被定义为基础层之外的任何其它层，并且基础层可以被定义为位流中的最低层。独立非基础层可以被定义为这样的层：其同时为独立层和非基础层。
在某些情况下，增强层中的数据可以在特定位置之后被截断，或者甚至在任意位置处被截断，其中每个截断位置可以包括表示不断增强的视觉质量的其它数据。这种可伸缩性被称为细粒度(粒度)可伸缩性(FGS)。
类似于MVC，在MV-HEVC中，视图间参考图片可以被包括在正在被编码或解码的当前图片的参考图片列表(多个)中。SHVC使用多循环解码操作(不同于H.264/AVC的SVC扩展)。SHVC可以被视为使用基于参考索引的方法，即，层间参考图片可以被包括在正在被编码或解码的当前图片的一个或多个参考图片列表中(如上所述)。
对于增强层编码，可以在SHVC、MV-HEVC等中使用HEVC基础层的概念和编码工具。但是，可以将其它层间预测工具集成到SHVC、MV-HEVC等编解码器，这些层间预测工具采用参考层中已经编码的数据(包括重构的图片样本和运动参数，又称为运动信息)以便有效地对增强层进行编码。
纹理视图指表示普通视频内容(例如已经使用普通摄像机捕获并且通常适合于在显示器上呈现)的视图。纹理视图通常包括具有三个分量(一个亮度分量和两个色度分量)的图片。在下面，纹理图片通常包括其所有分量图片或颜色分量，除非另外例如使用亮度纹理图片和色度纹理图片另外指明。
深度视图指这样的视图：其表示纹理样本与摄像机传感器的距离信息、纹理样本与另一个视图中的相应纹理样本之间的差异或视差信息、或者类似信息。深度视图可以包括具有一个分量的深度图片(又称为深度图)，该分量类似于纹理视图的亮度分量。在某些情况下，还可能存在色度分量或样本阵列，然而可能需要解码后的色度样本阵列具有某一样本值，并且色度样本阵列的解码可能被忽略。深度图是这样的图像：其具有每像素深度信息、两个视图中的各自像素的差异等。例如，深度图中的每个样本表示相应的一个或多个纹理样本与摄像机所在平面之间的距离。换言之，如果z轴沿着摄像机的拍摄轴(并且因此与摄像机所在平面正交)，则深度图中的样本表示z轴上的值。
深度增强视频指具有一个或多个视图的纹理视频，这些视图与具有一个或多个深度视图的深度视频关联。可以使用多种方法表示深度增强视频，包括使用视频加深度(V+D)和多视图视频加深度(MVD)。在视频加深度(V+D)表示中，单个纹理视图和相应深度视图分别被表示为纹理图片和深度图片的序列。MVD表示包含多个纹理视图和相应深度视图。可以在所谓的基于深度图像的呈现中使用深度信息，以便在未由任何编码纹理视图表示的视点处合成纹理视图。
纹理视图分量可以被定义为单个访问单元中的视图的纹理的编码表示。可以以与单视图纹理位流或多视图纹理位流兼容的方式对深度增强视频位流中的纹理视图分量进行编码，以使得单视图或多视图解码器即使没有对深度视图进行解码的能力，也能够对纹理视图进行解码。例如，H.264/AVC解码器可以对来自深度增强H.264/AVC位流的单个纹理视图进行解码。备选地，可以以如下方式对纹理视图分量进行编码：即，能够进行单视图或多视图纹理解码的解码器(例如H.264/AVC或MVC解码器)不能对纹理视图分量进行解码，例如因为该解码器使用基于深度的编码工具。深度视图分量可以被定义为单个访问单元中的视图的深度的编码表示。视图分量对可以被定义为同一访问单元内的同一视图的纹理视图分量和深度视图分量。纹理视图分量也可以被称为纹理视图或层的纹理图片或图片，并且深度视图分量也可以被称为深度视图或层的深度图片或图片。
可以以其中纹理和深度彼此独立地编码的方式对深度增强视频进行编码。例如，纹理视图可以被编码为一个MVC位流，并且深度视图可以被编码为另一个MVC位流。还可以以其中纹理和深度被共同编码的方式对深度增强视频进行编码。以纹理和深度视图的共同编码的形式，从在深度图片的解码过程中获得的深度图片的某些解码样本或数据元素，预测或导出用于纹理图片解码的纹理图片的某些解码样本或数据元素。备选地或此外，从在纹理图片的解码过程中获得的纹理图片的某些解码样本或数据元素，预测或导出用于深度图片解码的深度图片的某些解码样本或数据元素。在另一个选项中，纹理的编码视频数据和深度的编码视频数据不从彼此预测，或者一者不基于另一者进行编码/解码，但编码的纹理和深度视图可以在编码中被多路复用到相同位流中并且在解码中从位流被多路分用。在另一个选项中，尽管例如在分片层下面不从深度的编码视频数据预测纹理的编码视频数据，但纹理视图和深度视图的某些高级编码结构可以彼此共享或者从彼此被预测。例如，可以从编码纹理分片的分片标头预测编码深度分片的分片标头。此外，编码纹理视图和编码深度视图可以使用某些参数集。
深度增强视频格式使得能够在未由任何编码视图表示的摄像机位置处生成虚拟视图或图片。通常，可以使用任何基于深度图像的呈现(DIBR)算法以便合成视图。
3D视频编解码器的输入可以包括例如立体视频和具有立体基线b0的对应深度信息。然后，3D视频编解码器在基线(bi<b0)的两个输入视图之间合成多个虚拟视图。DIBR算法还可以实现在两个输入视图之外而不是它们之间的视图的外推。同样，DIBR算法可以从单个纹理视图和相应深度视图实现视图合成。但是，为了实现基于DIBR的多视图呈现，纹理数据应该与对应深度数据一起可用于解码器侧。
在这种3DV系统中，以纹理视图的深度图片(也被称为深度图)的形式在编码器侧产生深度信息。
可以通过各种手段获得深度信息。例如，可以从通过捕获摄像机或彩色图像传感器记录的差异来计算3D场景的深度。深度估计方法(其也可以被称为立体匹配)采取立体视图作为输入，并且计算视图的两个偏移图像之间的局部差异。因为两个输入视图表示不同的视点或视角，所以视差根据成像平面上的场景点的距离在所述的相对位置之间产生差异。立体匹配的目标是通过找到或检测图像之间的对应点来提取这些差异。存在数种立体匹配方法。例如，在块或模板匹配方法中，在重叠块中逐像素处理每个图像，并且对于每个像素块，执行偏移图像中的匹配块的水平局部化搜索。在计算像素差异之后，可以例如通过等式(1)计算对应深度值z：
Figure BDA0001346634540000471
其中f是摄像机的焦距，并且b是摄像机之间的基线距离。此外，d可以被视为指在两个摄像机之间观察到的差异或者在两个摄像机中的对应像素之间估计的差异。摄像机偏移Δd可以被视为反映两个摄像机的光学中心的可能水平错位或者由于预处理而导致的摄像机帧中的可能水平裁剪。但是，因为算法基于块匹配，所以深度差异估计的质量与内容相关并且通常非常不准确。例如，对于特征为没有纹理或大噪声级别的非常平滑的区域的图像片段，可能没有直接的深度估计解决方案。
备选地或者除了上述立体视图深度估计之外，例如通过使用可以具备用于照明场景的光源(例如红外线发射器)的摄像机，可以使用飞行时间(TOF)原理获得深度值。可以布置这种照明器以便产生强度调制电磁辐射以获得例如10-100MHz之间的频率，这可能需要使用LED或激光二极管。可以使用红外光以使照明不引人注目。可以通过图像传感器检测从场景中的物体反射的光，该图像传感器可以以与照明器相同的频率被同步调制。图像传感器可以具备光学器件；收集反射光的透镜和用于仅传递与照明器具有相同波长的光的光学带通滤光器，因此有助于抑制背景光。图像传感器可以针对每个像素测量光从照明器到物体的往返时间。到物体的距离可以被表示为照明调制中的相移，其可以针对场景中的每个像素同时从采样数据确定。
备选地或者除了上述立体视图深度估计和/或TOF原理深度感测之外，可以使用结构化光方法获得深度值，结构化光方法可以例如大约如下操作。光发射器(例如红外激光发射器或红外LED发射器)可以发射光，这种光可以在3D空间中具有某一方向(例如遵循光栅扫描或伪随机扫描顺序)和/或在光发射器阵列内具有某一位置以及某一模式，例如某一波长和/或振幅模式。发射光被从物体反射回来，并且可以使用诸如红外图像传感器之类的传感器被捕获。可以相对于发射光的方向以及发射光的模式处理由传感器获得的图像/信号，以便例如使用三角测量原理检测接收的信号与发射光的方向/位置以及发射光的模式之间的对应关系。从该对应关系，可以推定像素的距离和位置。
要理解，上述深度估计和感测方法作为非限制性实例而提供，并且可以使用所述或任何其它深度估计和感测方法和装置来实现各实施例。
可以以类似于深度图的方式处理差异或视差图，例如在ISO/IEC国际标准23002-3中指定的视差图。深度和差异具有直接对应关系，并且它们可以通过数学等式从彼此计算。
纹理视图和深度视图可以被编码到单个位流中，其中某些纹理视图可以与诸如H.264/AVC和/或MVC之类的一个或多个视频标准兼容。换言之，解码器可以能够对这种位流的某些纹理视图进行解码，并且可以忽略剩余纹理视图和深度视图。
已针对H.264/AVC指定用于深度图编码的修改。该修改被称为包括深度图的MVC扩展，并且可以被称为MVC+D。MVC+D修改指定以如下方式将纹理视图和深度视图封装到同一位流中：即，纹理视图保持与H.264/AVC和MVC兼容，以使得MVC解码器能够对MVC+D位流的所有纹理视图进行解码，并且H.264/AVC解码器能够对MVC+D位流的基础纹理视图进行解码。此外，深度视图的VCL NAL单元使用与NAL单元标头下面的纹理视图相同的句法、语义和解码过程。
已针对H.264/AVC指定用于增强纹理和深度图编码的另一个修改，其可以被称为3D-AVC。3D-AVC修改包括特定的3D视频编码工具，例如视图合成预测。编码器可以选择以符合MVC+D或3D-AVC的方式对非基础深度视图进行编码。同样，编码器可以选择以符合MVC(并且因此也符合MVC+D)或3D-AVC的方式对非基础纹理视图进行编码。
分量间预测可以被定义为包括句法元素值、样本值、在解码过程中使用的变量值、或者从一种类型的分量图片到另一种类型的分量图片的任何事物等的预测。例如，分量间预测可以包括从深度视图分量预测纹理视图分量，或者从纹理视图分量预测深度视图分量。
诸如MVC+D位流之类的深度增强多视图视频位流可以包含两种类型的操作点：多视图视频操作点(例如MVC+D位流的MVC操作点)和深度增强操作点。多视图视频操作点仅由纹理视图分量组成。
在深度增强视频的纹理和深度的联合编码的情况下，可以在编解码器的循环中使用视图合成等，因此提供视图合成预测(VSP)。在VSP中，利用纹理和深度信息，使用DIBR或视图合成算法来形成诸如VSP参考图片之类的预测信号。例如，可以以类似于在MVC和MV-HEVC中引入视图间参考图片的方式，在参考图片列表中引入合成图片(即，VSP参考图片)。备选地或此外，可以由编码器确定用于某些预测块的特定VSP预测模式，其由编码器在位流中指示，并且在由解码器从位流推断时使用。下面提供VSP的某些实例。作为所描述的VSP实例的一部分，形成预测信号，该部分还可以被视为DIBR或视图合成算法的一个实例。
在MVC和MV-HEVC中，帧间预测和视图间预测都使用类似的运动补偿预测过程。在不同的预测过程中，视图间参考图片基本上被视为长期参考图片。同样，可以以使用与帧间预测和视图间预测基本相同的运动补偿预测过程的方式，实现视图合成预测。可以基于MVD位流中可用的深度信息，部分或全部导出在视图合成预测中应用的运动向量。例如，可以从与正在被编码或解码的当前纹理块并置的深度块获得深度信息，其中深度块属于表示与包含当前纹理块的纹理视图相同的视点的深度视图。在另一个实例中，可以基于从中定位深度基础视图中的深度块的初始视图间运动向量(其可以例如基于空间或时间相邻块的视图间运动向量获得)，细化深度信息。可以从深度块的深度样本中对深度信息进行二次采样，例如可以选择深度块的各角的值的最大值，和/或可以通过深度块的深度样本的其它处理来获得深度信息。
为了针对当前纹理视图分量的编码实现视图合成预测，同一访问单元的先前编码的纹理和深度视图分量可以用于视图合成。使用同一访问单元的先前编码的纹理和深度视图分量的这种视图合成可以被称为前向视图合成或前向投影视图合成，并且同样使用这种视图合成的视图合成预测可以被称为前向视图合成预测或前向投影视图合成预测。
可以按照以下方式执行前向视图合成预测(VSP)。可以利用合成目标图像t(x+D,y)中的新像素位置中的源图片s(x,y)的以下映射像素，通过深度图(d)到差异(D)转换来实现视图合成。
Figure BDA0001346634540000513
Figure BDA0001346634540000511
Figure BDA0001346634540000512
在纹理图片投影的情况下，s(x,y)是纹理图像的样本，并且d(s(x,y))是与s(x,y)关联的深度图值。
在深度图值投影的情况下，s(x,y)＝d(x,y)并且使用其自身值d(s(x,y))＝d(x,y)来投影该样本。
前向视图合成过程可以包括两个概念性步骤：前向扭曲(warping)和孔填充。在前向扭曲中，将参考图像的每个像素映射到合成图像。当将来自参考帧的多个像素映射到合成视图中的同一样本位置时，可以在映射竞争中选择与较大深度值(更靠近摄像机)关联的像素。在扭曲所有像素之后，可能剩下没有从参考帧映射的样本值的某些孔像素，并且这些孔像素可以例如使用基于线的定向孔填充进行填充，其中“孔”被定义为在两个非孔像素之间的水平线中的连续孔像素。孔像素可以由具有较小深度样本值(距离摄像机较远)的两个相邻非孔像素中的一者来填充。
在被称为后向视图合成或后向投影视图合成的方案中，在视图合成过程中使用与合成视图并置的深度图。使用这种后向视图合成的视图合成预测可以被称为后向视图合成预测或后向投影视图合成预测或B-VSP。为了针对当前纹理视图分量的编码实现后向视图合成预测，可能需要当前编码/解码的纹理视图分量的深度视图分量可用。换言之，当深度视图分量的编码/解码顺序在相应纹理视图分量的编码/解码顺序之前时，可以在纹理视图分量的编码/解码中使用后向视图合成预测。备选地或此外，如果例如使用差异导出过程导出合成块的深度或差异，则可以使用后向视图合成。差异导出过程不需要深度视图分量的编码/解码顺序在相应纹理视图分量的编码/解码顺序之前。
使用B-VSP，相依视图的纹理像素不能从合成VSP帧来预测，而是直接从基础或参考视图的纹理像素来预测。可以从相依视图的深度图数据(即，对应于当前正在被编码/解码的纹理视图分量的深度视图分量)产生该过程需要的位移向量。
可以按照以下方式解释B-VSP的概念。假设使用以下编码顺序：(T0、D0、D1、T1)。纹理分量T0是基础视图，并且T1是使用B-VSP作为一个预测工具而编码/解码的相依视图。深度图分量D0和D1是分别与T0和T1关联的相应深度图。在相依视图T1中，可以从由基础视图T0的样本值组成的参考区域R(Cb)预测当前编码块Cb的样本值。可以从与当前编码纹理样本关联的深度图值发现编码样本与参考样本之间的位移向量(运动向量)，作为T1与T0之间的差异。
可以例如使用以下等式执行深度(1/Z)表示到差异的转换过程：
Figure BDA0001346634540000521
其中j和i是Cb内的局部空间坐标，d(Cb(j,i))是视图1的深度图图像中的深度图值，Z是其实际深度值，并且D是与特定视图0的差异。参数f、b、Znear和Zfar是指定摄像机设置的参数；即，使用的焦距(f)、视图1与视图0之间的摄像机间隔(b)以及表示深度图转换参数的深度范围(Znear、Zfar)。
自由视点导航可以指应用或服务，其中最终用户具有在由一组摄像机获得或捕获的场景的周围和内部自由导航的能力。摄像机可能但不需要形成系统摄像机阵列，例如并行1D摄像机阵列。此外，摄像机可能但不需要以适合用于立体或多视图自动立体显示器的内容生成的方式来定位。例如，摄像机可以形成具有多于10个摄像机的稀疏集合，这些摄像机任意布置，具有比通常用于立体显示器的立体视频内容生成更宽的基线。
特定的最终用户设备可以用于自由视点导航应用或服务。例如，可以使用OculusRift或类似的虚拟现实耳机。所述耳机可以跟踪头部和/或眼睛运动并且相应地显示视点。所述耳机可以能够进行立体内容观看。但是，也可以使用常规最终用户设备(例如台式或膝上型计算机、平板计算机或智能电话)实现自由视点导航。
图5示出用于自由视点流的系统的一个实例。多视图视频数据被编码，被存储在服务器处，并且被提供用于客户机设备的使用，这允许用户以交互方式选择呈现哪个或哪些视图。每个客户机根据其显示器的呈现能力从服务器请求一个或多个视图。例如，一组客户机使用常规2D显示器，第二组客户机配备立体显示器，而第三组用户可以在多视图自动立体显示器上一次显示多于两个视图。为了节省传输带宽，所传输的多视图位流以使其仅包括被请求视图和对被请求视图进行解码所需的视图的方式进行稀疏化(thinned)。当用户改变视点时，相应地调整传输的位流。
统一资源标识符(URI)可以被定义为用于标识资源名称的字符串。这种标识能够使用特定协议，通过网络与资源的表示进行交互。通过指定用于URI的具体句法和关联协议的方案来定义URI。统一资源定位符(URL)和统一资源名称(URN)是URI的形式。URL可以被定义为这样的URI：其标识Web资源，并且指定操作或获得资源的表示、指定其主要访问机制和网络位置的手段。URN可以被定义为这样的URI：其在特定命名空间中通过名称标识资源。URN可以用于标识资源而不暗示其位置或如何访问它。
在许多视频通信或传输系统、传输机制和多媒体容器文件格式中，具有独立于同一位流的另一个可伸缩性层而传输或存储可伸缩性层(例如独立于增强层(多个)而传输或存储基础层)的机制。可以认为层被存储在单独逻辑信道中或者通过单独逻辑信道传输。在下面提供实例：
-ISO基础媒体文件格式(ISOBMFF，ISO/IEC国际标准14496-12)：基础层可以被存储为轨道，并且每个增强层可以被存储在另一个轨道中。同样，在混合编解码器可伸缩性的情况下，非HEVC编码的基础层可以被存储为轨道(例如，具有样本条目类型“avc1”)，而增强层(多个)可以被存储为另一个轨道，该轨道使用所谓的轨道参考链接到基础层轨道。
-实时传输协议(RTP)：可以使用RTP流传送一个或多个层，并且因此同一RTP会话的RTP流可以在逻辑上分离不同的层。
-MPEG-2传输流(TS)：每个层可以具有不同的分组标识符(PID)值。
许多视频通信或传输系统、传输机制和多媒体容器文件格式提供将(例如不同轨道或会话的)的单独逻辑信道的编码数据彼此关联的手段。例如，存在将同一访问单元的编码数据关联在一起的手段。例如，可以在容器文件格式或传输机制中提供解码或输出时间，并且可以考虑具有相同解码或输出时间的编码数据以便形成访问单元。
最近，超文本传输协议(HTTP)已广泛用于在因特网上(例如在视频流应用中)传送实时多媒体内容。不同于使用用户数据报协议(UDP)上的实时传输协议(RTP)，HTTP易于配置并且通常允许穿过防火墙和网络地址转换器(NAT)，这使其对多媒体流应用具有吸引力。
已推出用于HTTP上的自适应流的数种商业解决方案，例如
Figure BDA0001346634540000541
SmoothStreaming、
Figure BDA0001346634540000542
Adaptive HTTP Live Streaming和
Figure BDA0001346634540000543
DynamicStreaming，以及已执行标准化项目。在版本9的第3代合作计划(3GPP)分组交换流(PSS)服务(3GPP TS 26.234版本9：“Transparent end-to-end packet-switched streamingservice(PSS)；protocols and codecs(透明端到端分组交换流服务(PSS)；协议和编解码器)”)中，自适应HTTP流(AHS)首先被标准化。MPEG将3GPP AHS版本9作为MPEG DASH标准的起点(ISO/IEC 23009-1：“Dynamic adaptive streaming over HTTP(DASH)-Part 1:Mediapresentation description and segment formats(HTTP动态自适应流(DASH)部分1：媒体呈现描述和段格式)”，国际标准，第2版，2014年)。3GPP继续致力于与MPEG和发布的3GP-DASH通信的自适应HTTP流(HTTP上的动态自适应流；3GPP TS 26.247：“Transparent end-to-end packet-switched streaming Service(PSS)；Progressive download anddynamic adaptive Streaming over HTTP(3GP-DASH)(透明端到端分组交换流服务(PSS)；循序式下载和HTTP动态自适应流(3GP-DASH))”。MPEG DASH和3GP-DASH在技术上彼此靠近，并且因此可以被统称为DASH。下面描述DASH的某些概念、格式和操作作为视频流系统的一个实例，其中可以实现各实施例。本发明的各个方面并不限于DASH，而是针对一个可能的基础提供描述，在该基础之上可以部分或全部实现本发明。
在DASH中，多媒体内容可以存储在HTTP服务器上，并且可以使用HTTP传送。内容可以以两个部分存储在服务器上：介质呈现描述(MPD)，其描述可用内容清单、其各种替代物、其URL地址和其它特性；以及段，其包含单个或多个文件中的大块(chunk)形式的实际多媒体位流。MDP提供客户机建立HTTP上的动态自适应流的必要信息。MPD包含描述媒体呈现的信息，例如每个段的HTTP统一资源定位符(URL)，其用于发出GET段请求。为了播放内容，DASH客户机可以例如通过使用HTTP、电子邮件、拇指驱动器、广播或其它传输方法来获得MPD。通过解析MPD，DASH客户机可以知道程序计时、媒体内容可用性、媒体类型、分辨率、最小和最大带宽、以及存在多媒体分量、可访问特性和所需数字权限管理(DRM)、网络上的媒体分量位置以及其它内容特征的各种编码替代物。使用该信息，DASH客户机可以选择适当的编码替代物，并且通过使用例如HTTP GET请求取回段来开始流化内容。在适当缓冲以便允许网络吞吐量变化之后，客户机可以继续取回后续段并且还监视网络带宽波动。客户机可以通过取回不同替代物(具有较低或较高比特率)的段以维护适当缓冲区来决定如何适应可用带宽。
在DASH中，使用分层数据模型构造媒体呈现，如图6中所示。媒体呈现包括一个或多个周期的序列，每个周期包含一个或多个组，每个组包含一个或多个适应集，每个适应集包含一个或多个表示，每个表示包括一个或多个段。表示是媒体内容或其子集的替代选择之一，其通常由于编码选择(例如由于比特率、分辨率、语言、编解码器等)而有所不同。段包含媒体数据的某一持续时间、以及用于对包括的媒体内容进行解码和呈现的元数据。段由URI标识，并且通常可以通过HTTP GET请求进行请求。段可以被定义为这样的数据单元：其与由MPD指定的HTTP-URL关联，并且可选地与由MPD指定的字节范围关联。
DASH MPD兼容可扩展标记语言(XML)，并且因此通过XML中定义的元素和属性被指定。可以使用以下约定指定MPD：XML文档中的元素可以由大写第一个字母标识，并且可以作为Element(元素)以粗体出现。为了表示元素Element1被包含在另一个元素Element2中，可以写成Element2.Element1。如果元素的名称由两个或更多组合词组成，则可以使用驼峰式大小写，例如ImportantElement。元素可以仅存在一次，或者可以由<minOccurs>...<maxOccurs>定义最小和最大出现次数。XML文档中的属性可以由小写第一个字母标识，并且它们前面可以具有“@”符号，例如@attribute。为了指向元素Element中包含的特定属性@attribute，可以写成Element@attribute。如果元素的名称由两个或更多组合词组成，则可以在第一个词之后使用驼峰式大小写，例如@veryImportantAttribute。属性可能已将XML中的状态指定为强制(M)、可选(O)、可选并具有默认值(OD)和有条件强制(CM)。
在DASH中，所有描述符元素都以相同方式构造，即它们包含提供用于标识模式(scheme)的URI的@schemeIdUri属性、以及可选属性@value和可选属性@id。元素的语义特定于所采用的模式。标识模式的URI可以是URN或URL。某些描述符在MPEG-DASH(ISO/IEC23009-1)中指定，而此外或备选地，描述符可以在其它规范中指定。当在MPEG-DASH之外的规范中指定时，MPD不提供有关如何使用描述符元素的任何特定信息。这取决于采用DASH格式以使用适当模式信息实例化描述元素的应用或规范。使用这些元素之一的应用或规范以URI的形式定义模式标识符(Scheme Identifier)，并且当使用该模式标识符时定义元素的值空间。模式标识符出现在@schemeIdUri属性中。在需要一组简单的枚举值的情况下，可以针对每个值定义文本字符串，并且该字符串可以被包括在@value属性中。如果需要结构化数据，则可以在单独命名空间中定义任何扩展元素或属性。@id值可以用于指唯一描述符或一组描述符。在后一种情况下，具有相同属性@id值的描述符可能需要是同义的，即，处理具有相同@id值的描述符之一便足够。如果元素名称、@schemeIdUri的值和@value属性的值等效，则类型DescriptorType的两个元素等效。如果@schemeIdUri是URN，则等效性可以指RFC2141的条款5中定义的词法等效性。如果@schemeIdUri是URL，则等效性可以指RFC3986的条款6.2.1中定义的基于字符的相等性。如果@value属性不存在，则等效性可以仅由@schemeIdUri的等效性来确定。扩展命名空间中的属性和元素可能不用于确定等效性。对于等效性确定，@id属性可被忽略。
MPEG-DASH指定描述符EssentialProperty和SupplementalProperty。对于元素EssentialProperty，媒体呈现作者表示，描述符的成功处理对于正确使用包含该描述符的父元素中的信息至关重要，除非该元素与另一个EssentialProperty元素共享同一@id。如果EssentialProperty元素共享同一@id，则处理具有相同@id值的EssentialProperty元素之一便足够。预计每个不同@id值的至少一个EssentialProperty元素被处理。如果模式或EssentialProperty描述符的值未被识别，则预计DASH客户机忽略包含该描述符的父元素。MPD中可能存在具有相同@id值和具有不同@id值的多个EssentialProperty元素。
对于元素SupplementalProperty，媒体呈现作者表示，描述符包含可以由DASH客户机用于优化处理的补充信息。如果模式或SupplementalProperty描述符的值未被识别，则预计DASH客户机忽略该描述符。MPD中可存在多个SupplementalProperty元素。
在DASH中，独立表示可以被定义为这样的表示：其可以独立于任何其它表示而被处理。独立表示可以被理解为包括独立位流或位流的独立层。相依表示可以被定义为这样的表示：对于其而言，来自其互补表示的段是包含的媒体内容分量的呈现和/或解码所必需的。相依表示可以被理解为包括例如可伸缩位流的预测层。互补表示可以被定义为这样的表示：其对至少一个相依表示进行互补。互补表示可以是独立表示或相依表示。相依表示可以由包含@dependencyId属性的Representation(表示)元素描述。相依表示可以被视为常规表示，只是它们依赖于用于解码和/或呈现的一组互补表示。@dependencyId包含所有互补表示(即，对该相依表示中包含的媒体内容分量进行呈现和/或解码必需的表示)的@id属性值。
DASH服务可以作为按需服务或实时服务而提供。在前者中，MPD是静态的，并且当内容提供者发布MPD时，媒体呈现的所有段都已经可用。但是，在后者中，MPD可以是静态的或动态的，具体取决于由MPD采用的段URL构造方法，并且当由内容提供者产生内容并将其发布到DASH客户机时连续产生段。段URL构造方法可以是基于模板的段URL构造方法或段列表生成方法。在前者中，在请求段之前，DASH客户机能够构造段URL而不更新MPD。在后者中，DASH客户机必须定期下载更新后的MPD以便获得段URL。对于实时服务，因此，基于模板的段URL构造方法优于段列表生成方法。
在DASH的上下文中，可以使用以下定义：媒体内容分量或媒体分量可以被定义为媒体内容的一个连续分量，其具有可以被单独编码到媒体流中的指定媒体分量类型。媒体内容可以被定义为一个媒体内容周期或媒体内容周期的连续序列。媒体内容分量类型可以被定义为单一类型的媒体内容，例如音频、视频或文本。媒体流可以被定义为编码版本的媒体内容分量。
初始化段可以被定义为这样的段：其包含呈现封装在媒体段中的媒体流必需的元数据。在基于ISOBMFF的段格式中，初始化段可以包括电影盒(“moov”)，其可能不包括任何样本的元数据，即，在“moof”盒中提供样本的任何元数据。
媒体段包含用于以正常速度重放的媒体数据的某一持续时间，这种持续时间被称为媒体段持续时间或段持续时间。内容产生者或服务提供者可以根据服务的期望特性来选择段持续时间。例如，可以在实时服务中使用相对短的段持续时间以便实现短的端到端延时。原因是段持续时间通常是由DASH客户机感知的端到端延时的下限，因为段是生成DASH的媒体数据的分离单元。通常以使媒体数据的整个段可用于服务器的方式完成内容生成。此外，许多客户机实现使用段作为用于GET请求的单元。因此，在实时业务的典型布置中，仅当媒体段的整个持续时间可用并且被编码并封装到段中时，DASH客户机才能够请求段。对于按需服务，可以使用选择段持续时间的不同策略。
段可以进一步划分为子段，例如以便能够以多个部分下载段。可能需要子段以便包含完整的访问单元。可以通过段索引盒对子段进行索引，段索引盒包含用于映射每个子段的呈现时间范围和字节范围的信息。段索引盒还可以描述段中的子段和流访问点，方法是通过用信号通知这些子段和流访问点的持续时间和字节偏移。DASH客户机可以使用从段索引盒(多个)获得的信息，使用字节范围HTTP请求针对特定子段发出HTTP GET请求。如果使用相对长的段持续时间，则可以使用子段来保持HTTP响应的大小对于比特率适应而言是合理和灵活的。段的索引信息可以放在该段的开始处的单个盒中，或者在段中的许多索引框之间传播。不同的传播方法是可能的，例如分层、菊花链和混合。该技术可以避免在段的开始处添加一个大盒，并且因此可以防止可能的初始下载延迟。
段(或相应地，子段)可以按照以下方式被定义为不重叠：假设TE(S,i)是段或子段S的流i中的任何访问单元的最早呈现时间，并且假设TL(S,i)是段或子段S的流i中的任何访问单元的最新呈现时间。可以在以下情况下将两个段(相应地，子段)A和B(它们可能具有或没有不同的表示)定义为非重叠：当对于A和B中的所有媒体流i，TL(A,i)<TE(B,i)，或者如果对于A和B中的所有流i，TL(B,i)<TE(A,i)，其中i指同一媒体分量。
可能需要对于依赖于互补表示Y的任何相依表示X，每当m不等于n时，X的第m个子段和Y的第n个子段将不重叠。可能需要对于相依表示，按照在@dependencyId属性中提供的顺序，将初始化段与相依表示的子段序列串接(每个子段的前面具有每个互补表示的对应子段)应表示一致子段序列，其符合在该相依表示的@mimeType属性中指定的媒体格式。
MPEG-DASH定义ISO基础媒体文件格式和MPEG-2传输流的段-容器格式。其它规范可以指定基于其它容器格式的段格式。例如，已提出基于Matroska容器文件格式的段格式，并且可以总结如下。当Matroska文件作为DASH段等被承载时，DASH单元和Matroska单元的关联可以指定如下。(DASH的)子段可以被定义为Matroska封装的内容的一个或多个连续群集。可能需要DASH的初始化段以便包括EBML标头、(Matroska的)段标头、(Matroska)的段信息和轨道，并且可以可选地包括其它level1元素和填充。DASH的段索引可以包括Matroska的提示元素。
DASH指定不同的时间线，包括媒体呈现时间线和段可用性时间。前者使用映射到全局通用呈现时间线的媒体内容来指示访问单元的呈现时间。媒体呈现时间线使DASH能够无缝同步不同的媒体分量，这些媒体分量使用不同的编码技术进行编码并且共享通用时间线。后者指示挂钟时间，并且用于用信号通知客户机由HTTP URL标识的段的可用性时间。DASH客户机能够通过将挂钟时间与分配给某一段的段可用性时间相比较，标识该段的可用性时间。段可用性时间在媒体段的实时传送(被称为实时服务)中起关键作用。对于实时服务，段可用性时间在段之间有所不同，并且某一段的可用性时间依赖于该段在媒体呈现时间线中的位置。对于按需服务，所有段的段可用性时间通常相同。
DASH通过从适应集内的不同表示动态请求媒体段以与变化的网络带宽匹配来支持速率适应。当DASH客户机向上/向下切换表示时，必须考虑表示内的编码依赖性。表示切换可以仅在随机访问点(RAP)处发生，RAP通常用于诸如H.264/AVC之类的视频编码技术中。在DASH中，引入名为流访问点(SAP)的更通用的概念，以便提供用于访问表示并且在表示之间切换的编解码器无关的解决方案。在DASH中，SAP被指定为表示中的位置，其能够仅使用从该位置开始向前的表示数据(其前面具有初始化段中的初始化数据(如果有))中包含的信息来开始媒体流的重放。因此，可以在SAP中执行表示切换。
已指定数种类型的SAP，包括以下内容。SAP类型1对应于在某些编码模式中被称为“闭合GOP随机访问点”的点(其中按解码顺序的所有图片可以被正确解码，导致没有间隙的正确解码的图片的连续时间序列)，并且此外，按解码顺序的第一图片也是按呈现顺序的第一图片。SAP类型2对应于在某些编码模式中被称为“闭合GOP随机访问点”的点(其中按解码顺序的所有图片可以被正确解码，导致没有间隙的正确解码的图片的连续时间序列)，对于其而言，按解码顺序的第一图片可能不是按呈现顺序的第一图片。SAP类型3对应于在某些编码模式中被称为“开放GOP随机访问点”的点，其中可能具有不能被正确解码的按解码顺序的某些图片，并且具有小于与SAP关联的帧内编码图片的呈现时间。
子段索引盒(“ssix”)提供从级别(由级别分配盒指定)到索引子段的字节范围的映射。换言之，该盒提供紧凑索引，其用于如何根据级别将子段中的数据排序到部分子段中。它使客户机能够通过下载子段中的数据范围来很容易地访问部分子段的数据。当存在子段索引盒时，子段中的每个字节被分配给一个级别。如果范围与级别分配中的任何信息不关联，则可以使用不包括在级别分配中的任何级别。每个段索引盒存在0或1个子段索引盒，其仅对叶子段进行索引，即，仅对子段进行索引而不对段索引进行索引。子段索引盒(如果有)是在关联的段索引盒之后的下一个盒。子段索引盒记录前一个段索引盒中指示的子段。每个级别可以被分配给仅一个部分子段，即，一个级别的字节范围是连续的。通过子段内增加的数量来分配部分子段的级别，即，部分子段的样本可以依赖于同一子段中的之前(而不是之后)部分子段的任何样本。例如，每个部分子段包含具有相同时间子层的样本，并且部分子段在子段内以增加的时间子层顺序出现。当以这种方式访问部分子段时，最终媒体数据盒可能不完整，即，访问的数据少于媒体数据盒指示的长度指示。媒体数据盒的长度可能需要调整，或者可能使用填充。级别分配盒中的padding_flag指示该缺失数据是否可以被0替代。如果否，则分配给未被访问的级别的样本的样本数据不存在，并且应该注意不要尝试处理这种样本。
内容提供者可以以使切换更简单的方式产生多个表示的段和子段。在简单情况下，每个段和子段从SAP开始，并且段和子段的边界跨适应集的表示对齐。在这种情况下，DASH客户机能够通过从原始表示向新表示请求段或子段，切换表示而没有误差漂移。在DASH中，在MPD和段索引中指定构造段和子段的限制，以便促进DASH客户机切换表示而不引入误差漂移。在DASH中指定的简档的一个用法是提供构造段和子段的不同级别的限制。
DASH标准包括能够快速启动媒体会话的机制。例如，MPD可以在适应集中公布具有不同比特率的多于一个的表示。此外，每个段和/或子段可以以流访问点开始，其中段和/或子段内的图片被编码而不参考来自不同段的任何其它图片。这样，DASH客户机可以从较低比特率表示开始，以便快速增加缓冲区占用级别。然后，客户机可以切换到较高比特率表示(其可以例如具有比先前接收的表示更高的空间分辨率)的请求段(多个)和/或子段(多个)。在快速启动期间，客户机可以将目标定为达到某一缓冲区占用级别(例如在媒体持续时间方面)，并且在快速启动阶段之后的操作期间，可以将目标定为保持相同或类似的缓冲区占用级别。在启动媒体流会话之后和/或仅在已缓冲某一数量的媒体之后的随机访问操作之后，客户机可以开始媒体重放。该媒体数量可以等于目标定为在快速启动时达到的缓冲区占用级别，但不需要与该缓冲区占用级别相关。在所有情况下，如果在启动媒体流会话之后和/或在随机访问操作之后仅持续接收较高比特率表示，则快速启动可以使客户机能够比可能的重放更快地开始媒体重放。
如上所述，客户机或播放器可以以类似于可如何确定可伸缩视频位流的传输层和/或子层的方式，请求从不同的表示传输段或子段。术语“表示向下切换”或“位流向下切换”可以指请求或传输比先前(相应地)请求或传输的比特率表示更低的比特率表示。术语“表示向上切换”或“位流向上切换”可以指请求或传输比先前(相应地)请求或传输的比特率表示更高的比特率表示。术语“表示切换”或“位流切换”可以共同指表示或位流向上和向下切换，并且还可以或备选地涵盖不同视点的表示或位流的切换。
类似于MPEG-DASH的流系统例如包括HTTP实时流(又称为HLS)，其在IETFInternet Draft 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)开始。
如上所解释，DASH和其它类似的流系统针对多媒体流应用，特别是针对多视图编码视频位流，提供有吸引力的协议和/或格式。但是，流客户机通常维持相对大的缓冲区占用级别，以便避免由于吞吐量波动而导致的重放中断。对于MVC位流中的视点切换，这意味着将过量视图传输到客户机以便实现立即视点切换。
在DASH上的流ISOBMFF段中的原子单元是独立的电影片段，其通常相对较大。DASH客户机通常接收至少一个完整的独立电影片段,然后对其进行处理，因此DASH客户机中的缓冲区占用级别通常为至少一个电影片段。
例如，如果对视点切换请求的反应缓慢，则自由视点流应用的体验质量可能明显劣化。当视点切换作为对头部和/或视线跟踪的响应发生时，这可能尤其如此。
因此，需要一种方法，其用于在使用DASH获得视图时执行低延时视点切换，但同时保持传输的视频的比特率尽可能低，并且保持在计算和存储器要求方面的解码复杂度尽可能低。
现在为了至少缓解上述问题，在下文中提供一种用于启动视点切换的方法。
在图7中公开的视图切换方法中，客户机请求(700)来自服务器的视频内容分量的独立地编码的第一表示；接收并播放(702)独立地编码的第一表示的第一组数据单元；请求(704)第二表示的第二组数据单元，所述第二组数据单元在第一组数据单元的一个或多个被请求或被缓冲数据单元上被相依地编码；以及请求(706)第三表示的第三组独立地编码的数据单元。
根据一个实施例，独立地编码的第一表示的第一组数据单元包括多视图编码的位流和多视图视频内容分量的第一视图的段或子段，并且第二表示的第二组数据单元包括多视图编码的位流和多视图视频内容分量的第二视图的段或子段，并且第三表示的第三组数据单元包括多视图视频内容分量的第二视图的段或子段。换言之，第二表示和第三表示将表示多视图视频内容中的相同视图。
因此，客户机针对以下访问单元请求切换到(第二)视图的段或子段：这些访问单元已经在客户机缓冲区中，或者对于这些访问单元而言，已经请求切换自(switch from)(第一)视图的数据。与请求单层切换到(switch to)段相比，实现较高的编码效率，因为已经下载切换自视图段，并且如果例如应用视图间预测，则与独立编码的切换到表示相比，切换到(第二)视图的段或子段的大小可以变得更小。
可以通过图8中公开的实例进一步例示该实施例，其中客户机首先请求、接收和播放独立编码的视图A(80；第一视图)。当客户机的用户发起视图切换时，客户机针对第一视图A的当前缓冲的段或子段的剩余部分(80；图8中的下层的暗框)，从服务器请求切换到视图(实例中的第二视图B)的视图间预测表示的一个或多个段或子段(82；图8中的上层的较亮框)。还可以针对第一视图A的已经请求(但尚未缓冲)的段或子段，请求第二视图B的视图间编码的表示。这避免终止已经发送的请求，这种终止可能需要终止TCP连接，这转而导致针对任何后续请求重新建立TCP连接的延迟。然后，客户机请求第二视图B的独立编码的段或子段(84；图8中的上层的暗框)。
因此，仅传输显示的视图，并且追溯发生视点切换，即，在已经被接收和缓冲的时间段内获得新视图的数据，这减少视点切换的延时并且避免重放中断。上述实施例例如优于其中每个视图仅可用作独立编码的表示的情况。在这种情况下，DASH客户机可以从紧接在由已经缓冲或已经请求的当前(切换自)视图表示的媒体时间之后的媒体时间开始请求新视图。这可能导致用户启动视图切换与正在被显示的切换到视图(switch-to view)的第一图片之间的明显延时。备选地，DASH客户机可以从当前重放位置请求新视图并且中断媒体重放，直到已接收新视图的足够数量的数据(以便连续播放)。备选地，DASH客户机可以从当前重放位置与紧接在由已经缓冲或已经请求的当前(切换自)视图表示的媒体时间之后的重放位置之间的位置，请求新视图，通常首先以较低比特率以便实现快速启动。但是，这种方法导致切换自视图(switch-from view)的某些接收的数据的省略和视频质量的波动，因为可能使用较低比特率来快速启动。
根据一个实施例，可以确定第二组数据单元的第一段或子段，以使得它对应于到接收第二组数据单元的所述第一段或子段时为止已经下载并存储在缓冲区中或估计要下载并存储在缓冲区中的第一组数据单元的段或子段。确定下载哪些视图间预测(inter-view-predicted)切换到视图段或子段可以例如基于缓冲区占用和/或估计的下载带宽。
根据一个实施例，可以确定第二组数据单元的第一段或子段，以使得它对应于第二组数据单元中的内部随机访问点(IRAP)图片。逐层启动机制可以用于第二组数据单元的解码。按解码顺序在所述IRAP图片之前的图片可以被确定为未被解码(例如CL-RAS图片)，或者参考生成的不可用图片而被解码但未被输出或显示。与所述IRAP图片关联的RASL图片等可以被忽略(即，未被解码)，或者可以被解码但未被输出或显示。除了CL-RAS图片和所述IRAP的关联RASL图片之外，第二组数据单元的所有图片都可以被解码并且被输出/显示。
在一个实施例中(其可以与其它实施例一起应用或独立于其它实施例而应用)，第三表示可以在MPD中被指示为在表示的视图、图片质量、空间分辨率、位深度、色域和/或动态范围方面与第二表示等效。此外或备选地，第二表示可以在MPD中被指示为与第三表示等效。例如，可以指定SupplementalProperty描述符以便指示所述等效性。描述符元素的@schemeIdUri属性提供URI，其标识指定等效表示的模式。描述符元素的@value属性可以用于提供等效表示在表示的视图、图片质量、空间分辨率、位深度、色域和/或动态范围方面的表示标识符值(即，Representation@id值)的列表。在某些情况下，URI可以指示和/或@value可以包括表示的视图、图片质量、空间分辨率、位深度、色域和/或动态范围中的哪个(哪些)可以被视为等效。
在一个实施例中(其可以与其它实施例一起应用或独立于其它实施例而应用)，第三表示可以从MPD中被解析为在表示的视图、图片质量、空间分辨率、位深度、色域和/或动态范围方面与第二表示等效。此外或备选地，第二表示可以从MPD中被解析为与第三表示等效。例如，可以从MPD中解析指示所述等效性的SupplementalProperty描述符。例如，描述符元素的@value属性可以用于获得等效表示在表示的视图、图片质量、空间分辨率、位深度、色域和/或动态范围方面的表示标识符值(即，Representation@id值)的列表。在另一个实例中，可以从第二和第三表示是同一适应集的部分的事实确定:第二和第三表示将表示相同视图并且因此在表示的视图方面等效。可以例如从@dependencyId进一步获得:第二表示是第一表示的相依表示(即，第一表示是第二表示的互补表示)。基于确定第二和第三表示等效并且第二表示是第一表示的相依表示，DASH客户机可以确定应用基于通过图7描述的方法的实施例，以便例如实现视图切换或快速启动。
根据一个实施例，可以请求播放时间在第二组数据单元的段或子段之后的独立编码的第二视图的段或子段。因此，独立编码的第二视图的段或子段(例如图8中的上层的暗框)的重放紧接在第二视图的视图间预测表示的段或子段(例如图8中的上层的较亮框)的重放之后开始。
根据一个实施例，客户机可以继续请求第一和第二组数据单元的段或子段；即，客户机可以继续请求切换自视图和视图间预测的切换到视图的(子)段。这可以允许更好的网络适应，但可能引起轻微的编码效率损失。
根据一个实施例，客户机可以从服务器请求所述第二组数据单元作为从所述第一组数据单元预测的视图间预测视图。
根据一个备选实施例，客户机可以从服务器请求所述第二组数据单元作为所述第一组数据单元的深度视图；以及应用基于深度图像的呈现(DIBR)或前向视图合成以便生成第二表示。
根据一个实施例，在启动视点切换之前请求切换自视图(switch-from view)的纹理和深度。作为对视点切换的响应，客户机可以针对接下来(即，几乎立即)显示的图片，使用DIBR或前向视图合成生成期望的切换到视点(switch-to viewpoint)。此外，客户机可以请求视图间预测的切换到视图，并且还按照其它实施例中所述以其它方式操作。
根据一个实施例，除了获得深度切换自视图之外，客户机还可以获得切换到视图，该视图可以使用切换自视图的纹理和深度被视图间预测和/或视图合成预测。
根据一个实施例，可以请求/传输切换到视图的深度视图，而不是请求/传输视图间预测的切换到视图。可以在客户机中使用后向视图合成以便生成所需切换到视点。
根据一个实施例，除了获得深度切换到视图之外，客户机还可以获得切换到视图，该视图可以使用纹理切换自视图进行视图间预测和/或视图合成预测，其中视图合成预测可以使用深度切换到视图以便实现后向视图合成。
根据一个实施例，所需视点与服务器中可用的任何视图不匹配。根据上述的一个实施例，客户机可以获得一个或多个纹理和深度视图。此外，客户机可以使用DIBR或前向视图合成生成所需视点。
以在任何时间点显示一个视图的假设描述了各实施例。需要理解，当例如在立体显示器或多视图自动立体显示器上显示多于一个视图时，同样可以实现各实施例。
关于用于布置视图间预测表示的不同实施例，可以例如应用以下选项：
视图间预测的切换到视图的质量可能低于切换自视图的质量。例如，与在切换自视图中相比，可以在视图间预测的切换到视图中使用更高的量化参数。备选地或此外，视图间预测的切换到视图可以具有比切换自视图更低的空间分辨率。以较低质量提供视图间预测的切换到视图的动机是保持其比特率尽可能小，这有助于避免客户机中的缓冲区耗尽，避免超过信道的吞吐量，和/或保持服务器和/或代理服务器(多个)中所需的存储空间较低。
服务器可以针对同一对切换自视图和切换到视图保存数个视图间编码的表示，基于哪些点是潜在切换点(即，包含随机访问点图片等)而加以区分。当相同段持续时间用于独立编码的切换到视图和视图间预测的切换到表示时，视图间预测的表示的数量可以例如与段中的GOP数量成比例(其中GOP是周期性预测结构，不一定以IRAP图片等开始)。例如，如果GOP长度等于8并且图片率是25Hz，则当段包含6个GOP时，获得大约2秒的段。可以维护同一对切换自和切换到视图的六个视图间预测的表示，在第n个GOP的开始处包含IRAP图片等，其中n从1到6。(对于IRAP图片不应用帧间预测，而可以使用视图间预测。)帧间和视图间预测的图片可以用于其它GOP关键图片。
与针对独立编码的表示相比，可以针对视图间预测的切换到表示使用更短的段持续时间。视图间预测的切换到表示的每个段可以从随机访问点开始。MPD信令用于指示视图间预测的切换到表示的段的整数倍与独立编码的表示的整数个段完全匹配。例如，可以将属性“@segAlignment”添加到Representation元素。当@segAlingment是正整数值时，应用以下内容。假设segDur1是适应集中的第一个表示的@segAlignment的值，并且segDur2是同一适应集的第二个表示的@segAlignment的值。假设segPer等于segDur1*segDur2。假设第一个表示的第0个超级段由从时段初开始的segDur2段组成，第一个表示的第1个超级段由第0个超级段之后的后续segDur2段组成，依此类推。假设第一个表示的第0个超级段由从时段初开始的segDur1段组成，第一个表示的第1个超级段由第0个超级段之后的后续segDur1段组成，依此类推。当m不等于n时，第一个表示的第n个超级段和第二个表示的第m个超级段不重叠。
与针对独立编码的表示相比，可以针对视图间预测的切换到表示使用更短的子段持续时间。视图间预测的切换到表示的每个子段可以从随机访问点开始。MPD信令用于指示视图间预测的切换到表示的子段的整数倍与独立编码的表示的整数个子段完全匹配。
因为用户可能在短时间内启动第二或另外的视图切换，所以可以在视图间预测的表示中对多于一个视图进行编码，并且可以使用所谓的级别(例如，如通过先前描述的级别分配盒所公布)按视图预测顺序在段和/或子段中布置编码数据。DASH客户机可以使用关于级别的信息(例如，如从一个或多个子段索引盒所解析)，以便确定与对应于所需视图的级别相对应的段或子段内的字节范围。DASH客户机可以使用HTTP GET字节范围请求以便仅获得用户想要接收的段或子段的那些级别(即，视图)。
在上面，已结合视图切换描述了图7的方法及其相关实施例。但是，图7的方法还可以用于流客户机(特别是DASH客户机)，以便改进流会话的快速启动并且更好地适应不断变化的网络条件。
在视频流应用中，启动时间(在用户例如通过点击播放按钮而启动会话之后，视频开始播放所需的时间)是一个重要问题，并且直接影响用户体验。如果用户在重放开始之前需要等待很长时间进行缓冲，则即使视频质量好，体验也会受到严重影响。除了缩短启动时间之外，视频流系统应该能够对变化的网络条件快速做出反应。例如，如果网络条件改善，则希望视频流系统快速提高流化视频内容的分辨率和/或质量。
当考虑图7的方法及其对流会话的快速启动的适用性时，考虑至少在以下编码版本中提供相同内容：
-低比特率单层流。在DASH的上下文中，低比特率单层流可以是第一表示，并且在图7的上下文中是“独立地编码的第一表示”。
-高比特率单层流。这可以例如表示比低比特率版本高的空间分辨率。在DASH的上下文中，高比特率单层流可以是第二表示，而第二表示可以与第一表示在同一适应集中。在图7的上下文中，这可以指“第三表示”。
-低比特率流的增强可伸缩性层。这可以表示与高比特率单层流类似的质量和/或空间分辨率和/或其它特性。在DASH的上下文中，该增强可伸缩性层可以是第一表示的相依表示，并且相依表示还可以与第一和第二表示在同一适应集中。在图7的上下文中，这可以指“在第一组数据单元上独立地编码的第二表示的第二组数据单元”。
根据估计的吞吐量，客户机可以在其“稳定模式”下请求单层流。考虑DASH流会话，DASH客户机决定切换到较高分辨率。这可能由于不同的原因而发生。例如，视频的下载速度可能已增加，这导致客户机的缓冲区占用逐渐增加。在检测到可用带宽的增加时，客户机可以决定下载较高分辨率的段。备选地，用户可以注意下载进度并且决定切换到较高分辨率。
根据一个实施例，在启动和/或表示向上切换(到较高比特率)的其它情况下，客户机确定请求有限时段的相依表示，以便更快地切换到较高的质量和/或分辨率和/或位深度和/或动态范围和/或更宽的色域，并且因此提供改进的用户体验。
可以通过图9中公开的实例例示客户机的操作。尽管参考不同质量或空间分辨率的表示描述图9，但需要理解，该实例可以另外或备选地应用于任何其它类型的可伸缩性，例如位深度、动态范围和/或色域可伸缩性。在该实例中，客户机请求(1)包含(第一表示的)独立可伸缩性层的编码视频的第一组数据单元。客户机缓冲(2)接收的第一组数据单元。客户机开始对接收的第一组数据单元(90；图9中的第一层的暗框)进行解码和/或播放(3)。在对所有接收的第一组数据单元进行解码和/或播放之前，客户机请求(4)包含依赖于独立可伸缩性层的可伸缩性层的编码视频的第二组数据单元(92；图9中的第二层的较亮框)。第二组数据单元对应于第一组数据单元的尚未被解码和/或播放的子集。客户机请求(5)包含(第二表示的)第二独立可伸缩性层的编码视频的第三组数据单元(94；覆盖图9中的第一和第二层的暗框)，第三组数据单元表示与第二组数据单元相同的视频内容的继续，第三组数据单元表示与第二组数据单元类似的视频质量和/或特性，并且第三组数据单元在重放第二组数据单元之后。除了第二组数据单元所依赖的对应第一组数据单元之外，客户机开始对接收的第二组数据单元进行解码和播放(6)。当第二组的所有数据单元都被解码和播放时，客户机开始对接收的第三组数据单元(第二独立可伸缩性层)进行解码和播放(7)。应该注意，步骤5和6的顺序可以不同。
此外，客户机可以开始针对已经在缓冲区的图片请求高分辨率增强层段，并且切换到高分辨率。与请求单层高分辨率段相比，实现较高的编码效率，因为基础层段已经被下载，并且需要的额外比特率很小。客户机可以在下一个SAP处继续高分辨率单层位流，或者可以继续下载基础和增强层段。
该操作可以被总结如下：
i.请求基础层段，直到决定切换到高分辨率/质量版本的视频。
ii.基于基础层的缓冲区占用和估计的下载带宽，确定从要下载的位置M开始的增强层段。第一增强层段M应该对应于到接收第一增强层段M时为止已经下载并存储在基础层缓冲区中或估计要下载并存储在基础层缓冲区中的基础层段。
iii.在客户机中估计，在解码/重放到达M时，正在请求高分辨率/质量的单层段M+L。
iv.对于M与L之间的段，对基础和增强层段进行解码/显示。
v.对于L之后的段，对高质量/分辨率单层段进行解码/显示。
作为iii.(其中正在请求高分辨率/质量的单层段M+L)的替代方案，客户机可以继续请求基础和增强层段。这将允许更好的网络适应，但将略微引起编码效率损失。
对于ii.，可以计算从位置M开始的增强层段，以使得位置M对应于基础层IRAP图片、增强层IRAP图片或这两者。
在此，可以在单独TCP连接上请求增强层段。
还可以按照以下方式将类似的理念用于快速启动。更具体地说，在流会话的开始，可以在基础层段之前下载增强层段，以使得在开始对其进行解码之前逐渐建立增强层缓冲区。这按照以下方式完成：
i.在其中开始重放之前填充缓冲区的初始时段内，客户机开始请求基础层段(从段0开始)和增强层段(从段M开始)。
ii.当基础层缓冲区充满度达到阈值级别时，开始对基础层段进行解码和显示直到位置M。
iii.在解码/重放到达段M时，正在请求基础层段M+L和增强层段M+L(大约同时)。
iv.在解码/重放到达段M时，开始对基础和增强层段进行解码/重放。
此外，可以在单独TCP连接上请求增强层段。
对于i.，可以计算从位置M开始的增强层段，以使得位置M对应于基础层IRAP图片、增强层IRAP图片或这两者。
关于传输连接和协议的选项，可以使用能够请求段或子段的各种协议来实现各实施例，这些协议包括但不限于HTTP的不同版本(例如HTTP/1.1和HTTP/2.0)、WebSockets和SPDY。
可以使用各种配置来实现各实施例以便建立和使用TCP连接，包括但不限于以下内容。
如上面讨论的，可以使用单独TCP连接下载增强层段。在带宽快速降低并且出现重放暂停危险的情况下，这使能更容易和更快地终止增强层段的接收。
备选地或此外，同一TCP连接可以用于基础层和增强层段。在这种情况下，HTTPGET请求可以被流水线化。客户机可以以更大持续时间的基础层段在客户机中获得缓冲区(与增强层段的缓冲持续时间相比)的方式，选择HTTP GET请求的顺序。客户机还可以将增强层段或子段的持续时间确定为小于基础层段或子段的持续时间，以便能够在吞吐量变化时更快速地做出反应。
可以使用各种类型的接入链路和链路层协议及其用于接入链路的配置来实现各实施例。例如，如果使用由3GPP指定的QoS，则用于增强层段的TCP连接可以以尽力而为(best effort)QoS运行，而基础层段可以具有保证的QoS信道。
图10示出适合于采用本发明实施例的视频解码器的框图。图10示出双层解码器的结构，但将认识到，同样可以在单层解码器中采用解码操作。
视频解码器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初步重构和滤波后的基础视图图像。
在此，解码器应该被解释为覆盖能够执行解码操作的任何操作单元，例如播放器、接收器、网关、多路复用器和/或解码器。
图11是其中可以实现各种实施例的实例多媒体通信系统的图形表示。数据源1510以模拟、未压缩数字或压缩数字格式或这些格式的任何组合提供源信号。编码器1520可以包括预处理或者与预处理关联，预处理例如包括源信号的数据格式转换和/或滤波。编码器1520将源信号编码到编码媒体位流中。应该注意，可以直接或间接从位于几乎任何类型的网络内的远程设备接收要被解码的位流。此外，可以从本地硬件或软件接收位流。编码器1520可以能够对多于一种媒体类型(例如音频和视频)进行编码，或者可能需要多于一个编码器1520对源信号的不同媒体类型进行编码。编码器1520还可以获得合成地产生的输入(例如图形和文本)，或者它可以能够产生合成媒体的编码位流。在下面，仅考虑一种媒体类型的一个编码媒体位流的处理以便简化描述。但是，应该注意，通常实时广播服务包括数个流(通常为至少一个音频、视频和文本副标题流)。还应该注意，系统可以包括许多编码器，但在该图中仅表示一个编码器1510以便简化描述而不失一般性。还应该理解，尽管在此包含的文本和实例可以具体描述编码过程，但所属技术领域的技术人员将理解，相同的概念和原理也适用于对应的解码过程，反之亦然。
可以将编码媒体位流传输到存储装置1530。存储装置1530可以包括用于存储编码媒体位流的任何类型的大容量存储器。存储装置1530中的编码媒体位流的格式可以是基本独立的位流格式，或者一个或多个编码媒体位流可以被封装到容器文件中。如果一个或多个媒体位流被封装在容器文件中，则文件生成器(图中未示出)可以用于将多于一个媒体位流存储在文件中并且产生文件格式元数据，其也可以存储在文件中。编码器1520或存储装置1530可以包括文件生成器，或者文件生成器可操作地附接到编码器1520或存储装置1530。某些系统“实时”操作，即，省略存储装置并且将编码媒体位流从编码器1520直接传输到发送器1540。然后，可以根据需要将编码媒体位流传输到发送器1540(也被称为服务器)。传输中使用的格式可以是基本独立的位流格式、分组流格式，或者一个或多个编码媒体位流可以被封装到容器文件中。编码器1520、存储装置1530和服务器1540可以驻留在同一物理设备中，或者它们可以被包括在单独的设备中。编码器1520和服务器1540可以使用实时内容进行操作，在这种情况下，编码媒体位流通常不被永久存储，而是在内容编码器1520和/或服务器1540中缓冲一小段时间以便平滑处理延迟、传输延迟和编码媒体位流中的变化。
服务器1540使用通信协议栈发送编码媒体位流。该栈可以包括但不限于以下一个或多个：实时传输协议(RTP)、用户数据报协议(UDP)、超文本传输协议(HTTP)、传输控制协议(TCP)、以及网际协议(IP)。当通信协议栈面向分组时，服务器1540将编码媒体位流封装到分组中。例如，当使用RTP时，服务器1540根据RTP有效负载格式将编码媒体位流封装到RTP分组中。通常，每种媒体类型具有专用的RTP有效负载格式。应该再次注意，系统可以包含多于一个服务器1540，但为了简单起见，以下描述仅考虑一个服务器1540。
如果媒体内容被封装在容器文件中以便存储1530或者将数据输入到发送器1540，则发送器1540可以包括或者可操作地附接到“发送文件解析器”(图中未示出)。具体地说，如果容器文件未被如此传输，而是至少一个包含的编码媒体位流被封装以便通过通信协议传输，则发送文件解析器定位编码媒体位流的适当部分以便通过通信协议传送。发送文件解析器还可以有助于针对通信协议产生正确格式，例如分组标头和有效负载。多媒体容器文件可以包含封装指令，例如ISO基础媒体文件格式中的提示轨道，以便在通信协议上封装至少一个包含的媒体位流。
服务器1540可以通过通信网络连接到网关1550，也可以不连接到网关1550。网关也可以或备选地被称为中间盒。注意，系统通常可以包括任何数量的网关等，但为了简单起见，以下描述仅考虑一个网关1550。网关1550可以执行不同类型的功能，例如将根据一个通信协议栈的分组流转换为另一通信协议栈、合并和划分数据流、以及根据下行链路和/或接收器能力操纵数据流，例如根据主要下行链路网络条件来控制转发流的比特率。网关1550的实例包括多点会议控制单元(MCU)、电路交换与分组交换视频电话之间的网关、蜂窝一键通(PoC)服务器、手持数字视频广播(DVB-H)系统中的IP封装器、机顶盒、或者将广播传输本地转发到家庭无线网络的其它设备。当使用RTP时，网关1550可以被称为RTP混合器或RTP转换器，并且可以充当RTP连接的端点。代替网关1550或者除了网关1550之外，系统还可以包括串接视频序列或位流的拼接器。
所述系统包括一个或多个接收器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可以被配置为在不同表示之间执行切换例如以便实现视图切换、比特率适应和/或快速启动，和/或发送器1540和/或网关1550可以被配置为选择传输的表示(多个)。可以由于多个原因发生不同表示之间的切换，例如响应接收器1560的请求或主要条件，例如传送位流所通过的网络的吞吐量。来自接收器的请求可以是例如针对来自与先前不同的表示的段或子段的请求、针对传输的可伸缩性层和/或子层的变化、或者与前一个相比具有不同能力的呈现设备的变化的请求。针对段的请求可以是HTTP GET请求。针对子段的请求可以是具有字节范围的HTTP GET请求。此外或备选地，比特率调整或比特率适应可以用于例如在流服务(其中传输流的比特率在开始或随机访问流之后低于信道比特率)中提供所谓的快速启动，以便立即开始重放并且获得容忍偶尔分组延迟和/或重新传输的缓冲区占用级别。比特率适应可以包括以各种顺序发生的多个表示或层向上切换和表示或层向下切换操作。
解码器1580可以被配置为在不同表示之间执行切换例如以便实现视图切换、比特率适应和/或快速启动，和/或解码器1580可以被配置为选择传输的表示(多个)。可以由于多个原因发生不同表示之间的切换，例如以便实现更快的解码操作或者适应传输位流(例如在比特率方面)或主要条件(例如传送位流所通过的网络的吞吐量)。例如，如果包括解码器1560的设备是多任务的，并且使用计算资源以便实现对可伸缩视频位流进行解码之外的其它目的，则可能需要更快的解码操作。在另一个实例中，当以比正常重放速度更快的速度(例如比常规实时重放速度快两倍或三倍)重放内容时，可能需要更快的解码操作。解码器操作的速度可以在解码或重放期间改变，例如作为对从快进播放变为正常重放速度或者从正常重放速度变为快进播放的响应，并且因此可以以各种顺序发生多个层向上切换和层向下切换操作。
在上文中，已在多层HEVC扩展(例如SHVC和MV-HEVC)的上下文中描述了实例实施例。需要理解，同样可以在任何其它多层编码方案中实现各实施例。
在上文中，已针对DASH或MPEG-DASH描述了某些实施例。需要理解，同样可以使用任何其它类似的流系统、和/或与DASH中所用类似的任何协议、和/或与DASH中所用类似的任何段和/或清单格式、和/或与DASH客户机类似的任何客户机操作来实现各实施例。
在上文中，已针对ISOBMFF描述了某些实施例，例如当涉及段格式时。需要理解，同样可以使用任何其它文件格式(例如Matroska)、与ISOBMFF中类似的能力和/或结构来实现各实施例。
在上文中，已针对图9或图10描述了某些实施例。需要理解，针对图9描述的实施例同样可以实现为与图10相关的实施例。同样，需要理解，针对图10描述的实施例同样可以实现为与图9相关的实施例。此外，针对图9描述的实施例可以与图10相关的实施例相组合。
在上文中，已针对术语“视图”描述了某些实施例。需要理解，同样可以针对术语“层”实现各实施例。反之亦然，在上文中，已针对术语“层”描述了某些实施例，并且需要理解，同样可以针对术语“视图”实现各实施例。
在上文中，在已参考编码器描述了实例实施例的情况下，需要理解，结果位流和解码器可以在其中具有对应元素。同样，在已参考解码器描述了实例实施例的情况下，需要理解，编码器可以具有用于生成要由解码器解码的位流的结构和/或计算机程序。
上面描述的本发明实施例在单独的编码器和解码器装置方面描述了编解码器，以便有助于理解涉及的过程。但是，将认识到，所述装置、结构和操作可以被实现为单个编码器-解码器装置/结构/操作。此外，编码器和解码器可以共享部分或全部公用元件。
尽管上面的实例描述了在电子设备内的编解码器内操作的本发明的实施例，但将理解，权利要求中限定的本发明可以被实现为任何视频编解码器的一部分。因此，例如，本发明的实施例可以在视频编解码器中实现，该视频编解码器可以在固定或有线通信路径上实现视频编码。
因此，用户设备可以包括例如在上面的本发明实施例中描述的视频编解码器。将理解，术语“用户设备”旨在涵盖任何合适类型的无线用户设备，例如移动电话、便携式数据处理设备或便携式Web浏览器。
此外，公共陆地移动网络(PLMN)的元件还可以包括如上所述的视频编解码器。
一般而言，本发明的各种实施例可以以硬件或专用电路、软件、逻辑或其任何组合来实现。例如，某些方面可以以硬件实现，而其它方面可以以可由控制器、微处理器或其它计算设备执行的固件或软件实现，然而本发明并不限于此。尽管本发明的各个方面可以作为框图、流程图或者使用某个其它图形表示而被示出和描述，但可以理解，作为非限制性实例，在此描述的这些方框、装置、系统、技术或方法可以以硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其它计算设备或它们的某种组合来实现。
本发明的实施例可以由计算机软件或软件和硬件的组合实现，所述计算机软件可由移动设备的数据处理器(例如在处理器实体中)或由硬件执行。此外，在这点上，应该注意，图中的逻辑流程的任何方框可以表示程序步骤、或互连逻辑电路、块和功能、或程序步骤以及逻辑电路、块和功能的组合。软件可以存储在以下项上：诸如存储芯片之类的物理介质，或者在处理器中实现的存储块，诸如硬盘或软盘之类的磁介质，以及诸如DVD及其数据变体、CD之类的光介质。
存储器可以具有适合于本地技术环境的任何类型，并且可以使用任何合适的数据存储技术实现，例如基于半导体的存储设备、磁存储设备和系统、光存储设备和系统、固定存储器以及可移动存储器。数据处理器可以具有适合于本地技术环境的任何类型，并且作为非限制性实例，可以包括以下一者或多者：通用计算机、专用计算机、微处理器、数字信号处理器(DSP)以及基于多核处理器架构的处理器。
本发明的实施例可以在诸如集成电路模块之类的各种组件中实现。集成电路的设计是高度自动化的过程。可以使用复杂并且强大的软件工具，将逻辑级别设计转换为可以在半导体衬底上蚀刻和形成的半导体电路设计。
程序(例如，由位于加利福尼亚州山景城的Synopsys,Inc.以及位于加利福尼亚州圣何塞的Cadence Design提供的程序)使用完善的设计规则以及预先存储的设计模块库，在半导体芯片上自动路由导体并且定位组件。在完成半导体电路设计之后，可以将标准化电子格式(例如，Opus、GDSII等)的结果设计传输到半导体制造设施或“工厂(fab)”以便制造。
通过示例性和非限制性实例提供上面的描述，作为本发明的示例性实施例的全面并且信息性的描述。但是，当结合附图和所附权利要求阅读时，鉴于上面的描述，许多修改和变化对于相关技术领域的技术人员来说变得显而易见。但是，对本发明教导的所有这些和类似的修改仍在本发明的范围内。

Claims (21)

1.一种方法，包括：
由客户机请求来自服务器的视频内容分量的独立地编码的第一表示；
接收并播放所述独立地编码的第一表示的第一组数据单元；
请求第二表示的第二组数据单元，所述第二组数据单元在所述第一组数据单元的一个或多个被请求或被缓冲数据单元上被相依地编码；
请求第三表示的第三组独立地编码的数据单元；以及
由所述客户机将所述第三表示解析为在表示的视图、图片质量和空间分辨率方面与所述第二表示等效。
2.根据权利要求1所述的方法，其中所述第一组数据单元包括多视图编码的位流的第一视图的段或子段，并且所述第二和第三组数据单元包括所述多视图编码的位流的第二视图的段或子段。
3.根据权利要求2所述的方法，进一步包括：
确定所述第二组数据单元的第一段或子段，以使得所述第一段或子段对应于到所述第二组数据单元的所述第一段或子段被接收时为止所述第一组数据单元的已被下载或估计将被下载的段或子段。
4.根据权利要求3所述的方法，进一步包括：
确定所述第二组数据单元的所述第一段或子段，以使得所述第一段或子段对应于所述第二组数据单元中的内部随机访问点(IRAP)图片。
5.根据权利要求2-4中的任一项所述的方法，进一步包括：
请求播放时间在所述第二组数据单元的段或子段之后的所述第三表示的段或子段。
6.根据权利要求2-4中的任一项所述的方法，进一步包括：
继续请求所述第一和所述第二表示的段或子段。
7.根据权利要求2-4中的任一项所述的方法，进一步包括：
请求所述第二组数据单元作为从所述第一组数据单元预测的视图间预测视图。
8.根据权利要求2-4中的任一项所述的方法，进一步包括：
请求所述第二组数据单元作为所述第一组数据单元的深度视图；以及
应用基于深度图像的呈现(DIBR)或前向视图合成以便生成所述第二表示。
9.根据权利要求1所述的方法，其中所述第一表示包括所述视频内容分量的低比特率单层流，所述第二表示包括所述视频内容分量的所述低比特率流的增强可伸缩性层，并且所述第三表示包括所述视频内容分量的高比特率单层流。
10.根据权利要求9所述的方法，进一步包括：
请求所述第二表示的所述第二组数据单元作为对接收用户请求或者所述客户机确定切换到所述视频内容分量的高分辨率表示的响应。
11.一种装置，包括
至少一个处理器和至少一个存储器，所述至少一个存储器在其上存储有代码，当由所述至少一个处理器执行时，所述代码导致所述装置至少执行
请求来自服务器的视频内容分量的独立地编码的第一表示；
接收并播放所述独立地编码的第一表示的第一组数据单元；
请求第二表示的第二组数据单元，所述第二组数据单元在所述第一组数据单元的一个或多个被请求或被缓冲数据单元上被相依地编码；
请求第三表示的第三组独立地编码的数据单元；以及
由客户机将所述第三表示解析为在表示的视图、图片质量和空间分辨率方面与所述第二表示等效。
12.根据权利要求11所述的装置，其中所述第一组数据单元包括多视图编码的位流的第一视图的段或子段，并且所述第二和第三组数据单元包括所述多视图编码的位流的第二视图的段或子段。
13.根据权利要求12所述的装置，进一步包括导致所述装置执行以下操作的代码：
确定所述第二组数据单元的第一段或子段，以使得所述第一段或子段对应于到所述第二组数据单元的所述第一段或子段被接收时为止所述第一组数据单元的已被下载或估计将被下载的段或子段。
14.根据权利要求13所述的装置，进一步包括导致所述装置执行以下操作的代码：
确定所述第二组数据单元的所述第一段或子段，以使得所述第一段或子段对应于所述第二组数据单元中的内部随机访问点(IRAP)图片。
15.根据权利要求12-14中的任一项所述的装置，进一步包括导致所述装置执行以下操作的代码：
请求播放时间在所述第二组数据单元的段或子段之后的所述第三表示的段或子段。
16.根据权利要求12-14中的任一项所述的装置，进一步包括导致所述装置执行以下操作的代码：
继续请求所述第一和所述第二表示的段或子段。
17.根据权利要求12-14中的任一项所述的装置，进一步包括导致所述装置执行以下操作的代码：
请求所述第二组数据单元作为从所述第一组数据单元预测的视图间预测视图。
18.根据权利要求12-14中的任一项所述的装置，进一步包括导致所述装置执行以下操作的代码：
请求所述第二组数据单元作为所述第一组数据单元的深度视图；以及
应用基于深度图像的呈现(DIBR)或前向视图合成以便生成所述第二表示。
19.根据权利要求11所述的装置，其中所述第一表示包括所述视频内容分量的低比特率单层流，所述第二表示包括所述视频内容分量的所述低比特率流的增强可伸缩性层，并且所述第三表示包括所述视频内容分量的高比特率单层流。
20.根据权利要求19所述的装置，进一步包括导致所述装置执行以下操作的代码：
请求所述第二表示的所述第二组数据单元作为对接收用户请求或者所述客户机确定切换到所述视频内容分量的高分辨率表示的响应。
21.一种计算机可读存储介质，其上存储有代码以便由装置使用，当由处理器执行时，所述代码导致所述装置执行：
请求来自服务器的视频内容分量的独立地编码的第一表示；
接收并播放所述独立地编码的第一表示的第一组数据单元；
请求第二表示的第二组数据单元，所述第二组数据单元在所述第一组数据单元的一个或多个被请求或被缓冲数据单元上被相依地编码；
请求第三表示的第三组独立地编码的数据单元；以及
由客户机将所述第三表示解析为在表示的视图、图片质量和空间分辨率方面与所述第二表示等效。
CN201580073022.3A 2015-01-12 2015-12-21 用于视频流的方法、装置以及计算机可读存储介质 Active CN107113476B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB1500400.5A GB2534136A (en) 2015-01-12 2015-01-12 An apparatus, a method and a computer program for video coding and decoding
GB1500400.5 2015-01-12
PCT/FI2015/050915 WO2016113458A1 (en) 2015-01-12 2015-12-21 A method, an apparatus and a computer readable storage medium for video streaming

Publications (2)

Publication Number Publication Date
CN107113476A CN107113476A (zh) 2017-08-29
CN107113476B true CN107113476B (zh) 2020-07-24

Family

ID=52597461

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201580073022.3A Active CN107113476B (zh) 2015-01-12 2015-12-21 用于视频流的方法、装置以及计算机可读存储介质

Country Status (5)

Country Link
US (1) US10397618B2 (zh)
EP (2) EP3979659B1 (zh)
CN (1) CN107113476B (zh)
GB (1) GB2534136A (zh)
WO (1) WO2016113458A1 (zh)

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3262523B1 (en) * 2015-02-27 2019-12-04 DivX, LLC System and method for frame duplication and frame extension in live video encoding and streaming
KR101654898B1 (ko) * 2015-04-15 2016-09-07 고려대학교 산학협력단 적응형 스트리밍 서비스를 수신하는 방법
CN108028948B (zh) * 2015-08-07 2021-05-07 联发科技股份有限公司 用于多媒体应用的比特流随机访问与同步的方法及装置
US10623755B2 (en) * 2016-05-23 2020-04-14 Qualcomm Incorporated End of sequence and end of bitstream NAL units in separate file tracks
CN112601072A (zh) * 2016-06-16 2021-04-02 华为技术有限公司 视频业务质量评估的方法及装置
US11089329B1 (en) * 2016-06-28 2021-08-10 Amazon Technologies, Inc Content adaptive encoding
JP2019532597A (ja) * 2016-08-30 2019-11-07 ソニック アイピー， インコーポレイテッド ３６０°ビューコンテンツをエンコードおよび再生するためのシステムおよび方法
EP3510744B1 (en) * 2016-09-09 2022-05-04 Vid Scale, Inc. Methods and apparatus to reduce latency for 360-degree viewport adaptive streaming
EP3510024B1 (en) * 2016-09-09 2021-11-17 Bristol-Myers Squibb Company Pyridyl substituted indole compounds
US10681382B1 (en) * 2016-12-20 2020-06-09 Amazon Technologies, Inc. Enhanced encoding and decoding of video reference frames
EP3560206A1 (en) 2016-12-22 2019-10-30 Fraunhofer Gesellschaft zur Förderung der Angewand Media streaming with fast tuning and fast channel switching
FI20166017A (fi) * 2016-12-22 2018-06-23 Nokia Technologies Oy Laitteisto, menetelmä ja tietokoneohjelma videokoodausta ja videokoodauksen purkua varten
WO2018146376A1 (en) * 2017-02-13 2018-08-16 Nokia Technologies Oy An apparatus, a method and a computer program for video coding and decoding
GB2560953A (en) * 2017-03-30 2018-10-03 Nokia Technologies Oy Video Streaming
WO2018204330A1 (en) * 2017-05-01 2018-11-08 Realnetworks, Inc. Multi-layered video streaming systems and methods
US10284888B2 (en) * 2017-06-03 2019-05-07 Apple Inc. Multiple live HLS streams
US10652166B2 (en) * 2017-06-27 2020-05-12 Cisco Technology, Inc. Non-real time adaptive bitrate recording scheduler
US11665219B2 (en) * 2017-07-10 2023-05-30 Qualcomm Incorporated Processing media data using a generic descriptor for file format boxes
US10911512B2 (en) * 2017-09-05 2021-02-02 Amazon Technologies, Inc. Personalized content streams using aligned encoded content segments
EP3454566B1 (en) * 2017-09-11 2021-05-05 Tiledmedia B.V. Streaming frames of spatial elements to a client device
KR20200095463A (ko) * 2017-11-01 2020-08-10 브이아이디 스케일, 인크. 병합 모드를 위한 서브-블록 모션 도출 및 디코더측 모션 벡터 정교화
US11232532B2 (en) * 2018-05-30 2022-01-25 Sony Interactive Entertainment LLC Multi-server cloud virtual reality (VR) streaming
EP3576413A1 (en) * 2018-05-31 2019-12-04 InterDigital CE Patent Holdings Encoder and method for encoding a tile-based immersive video
CN108900874B (zh) * 2018-08-20 2020-12-22 北京科技大学 一种基于svc-dash框架的流媒体自适应请求方法及其装置
WO2020043003A1 (zh) * 2018-08-29 2020-03-05 浙江大学 处理传输媒体数据和指定参考图像的方法和装置
EP3629585A1 (en) * 2018-09-25 2020-04-01 Koninklijke Philips N.V. Image synthesis
CN109587490B (zh) * 2018-11-05 2022-05-31 深圳威尔视觉传媒有限公司 一种Tile分片填充方法、装置、设备、存储介质和解码方法
JP7247349B2 (ja) * 2018-12-31 2023-03-28 ホアウェイ・テクノロジーズ・カンパニー・リミテッド イントラ予測のための成分間線形モデリングの方法、装置、デコーダ、エンコーダ、およびプログラム
US11290734B2 (en) 2019-01-02 2022-03-29 Tencent America LLC Adaptive picture resolution rescaling for inter-prediction and display
US11670039B2 (en) 2019-03-04 2023-06-06 Dolby Laboratories Licensing Corporation Temporal hole filling for depth image based video rendering
US11012710B2 (en) 2019-03-06 2021-05-18 Tencent America LLC Techniques for intra prediction for 360 image and video coding
US11622164B2 (en) * 2019-07-12 2023-04-04 Carrier Corporation System and method for streaming video/s
US10547915B1 (en) * 2019-07-19 2020-01-28 Look At Me, Inc. System and method for optimizing playlist information for ultra low latency live streaming
US11616822B2 (en) * 2019-09-30 2023-03-28 Tencent America LLC Session-based information for dynamic adaptive streaming over HTTP
KR20220075401A (ko) * 2019-10-15 2022-06-08 인터디지털 씨이 페이튼트 홀딩스, 에스에이에스 비디오를 전송 및 수신하기 위한 방법 및 장치
US11356796B2 (en) * 2019-11-22 2022-06-07 Qualcomm Incorporated Priority-based soundfield coding for virtual reality audio
US11228796B2 (en) * 2020-01-07 2022-01-18 Tencent America LLC Pattern addressing for session-based dash operations
US11632582B2 (en) * 2020-02-13 2023-04-18 Ssimwave, Inc. Distributed measurement of latency and synchronization delay between audio/video streams
CN111726687B (zh) * 2020-06-30 2022-12-27 北京百度网讯科技有限公司 用于生成显示数据的方法和装置
CN114007059A (zh) * 2020-07-28 2022-02-01 阿里巴巴集团控股有限公司 视频压缩方法、解压方法、装置、电子设备及存储介质
US11381855B2 (en) * 2020-11-18 2022-07-05 Roku, Inc. Content-modification system with multiple video buffers feature
KR102589349B1 (ko) * 2020-11-30 2023-10-16 한국전자통신연구원 플렌옵틱 시스템의 영상 송수신 방법 및 장치
US20230162338A1 (en) * 2021-01-25 2023-05-25 Beijing Boe Optoelectronics Technology Co., Ltd. Virtual viewpoint synthesis method, electronic apparatus, and computer readable medium

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101312542A (zh) * 2008-07-07 2008-11-26 浙江大学 一种自然三维电视系统
CN102892004A (zh) * 2012-10-16 2013-01-23 天津大学 一种多视点视频编码码率控制方法
CN103856778A (zh) * 2009-04-14 2014-06-11 华为技术有限公司 用于处理视频文件的系统和方法
CN103907347A (zh) * 2011-08-31 2014-07-02 诺基亚公司 多视图视频编码和解码
CN104115494A (zh) * 2011-11-30 2014-10-22 高通股份有限公司 用于多视图视频译码mvc兼容三维视频译码3dvc的嵌套式sei消息

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI113124B (fi) 1999-04-29 2004-02-27 Nokia Corp Tiedonsiirto
US20100259595A1 (en) 2009-04-10 2010-10-14 Nokia Corporation Methods and Apparatuses for Efficient Streaming of Free View Point Video
US8918533B2 (en) * 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
TW201210325A (en) * 2010-07-21 2012-03-01 Nokia Corp Method and apparatus for indicating switching points in a streaming session
US9602849B2 (en) * 2010-09-17 2017-03-21 Futurewei Technologies, Inc. Method and apparatus for scrub preview services
US9357196B2 (en) * 2011-03-07 2016-05-31 Lg Electronics Inc. Method and device for transmitting/receiving digital broadcast signal
US20130032978A1 (en) * 2011-08-01 2013-02-07 Nu-Core, Inc. Burner Gland For An Electric Arc Furnace
TW201308253A (zh) * 2011-08-04 2013-02-16 Univ Nat Taiwan 運動量分析方法及採用此方法之運動量分析裝置
EP2795919A4 (en) * 2011-12-23 2015-11-11 Nokia Technologies Oy ALIGNMENT OF VARIOUS VIEWS OF VIEWING VIDEOS
US9571827B2 (en) * 2012-06-08 2017-02-14 Apple Inc. Techniques for adaptive video streaming
CN104813669B (zh) * 2012-09-21 2018-05-22 诺基亚技术有限公司 用于视频编码的方法和装置
CA2897152C (en) * 2013-01-07 2019-03-05 Kemal Ugur Inter-layer video encoding and decoding with adaptive resolution change at indicated switching points

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101312542A (zh) * 2008-07-07 2008-11-26 浙江大学 一种自然三维电视系统
CN103856778A (zh) * 2009-04-14 2014-06-11 华为技术有限公司 用于处理视频文件的系统和方法
CN103907347A (zh) * 2011-08-31 2014-07-02 诺基亚公司 多视图视频编码和解码
CN104115494A (zh) * 2011-11-30 2014-10-22 高通股份有限公司 用于多视图视频译码mvc兼容三维视频译码3dvc的嵌套式sei消息
CN102892004A (zh) * 2012-10-16 2013-01-23 天津大学 一种多视点视频编码码率控制方法

Also Published As

Publication number Publication date
EP3245793A1 (en) 2017-11-22
WO2016113458A1 (en) 2016-07-21
EP3245793A4 (en) 2018-08-15
EP3979659A1 (en) 2022-04-06
US20180007395A1 (en) 2018-01-04
CN107113476A (zh) 2017-08-29
EP3245793B1 (en) 2021-12-29
US10397618B2 (en) 2019-08-27
EP3979659B1 (en) 2023-08-02
GB2534136A (en) 2016-07-20
GB201500400D0 (en) 2015-02-25

Similar Documents

Publication Publication Date Title
CN107113476B (zh) 用于视频流的方法、装置以及计算机可读存储介质
US11671588B2 (en) Apparatus, a method and a computer program for video coding and decoding
US10674170B2 (en) Apparatus, a method and a computer program for video coding and decoding
US11095907B2 (en) Apparatus, a method and a computer program for video coding and decoding
CN107431819B (zh) 用于视频解码的方法、装置、计算机可读存储介质及视频解码器
CN108702503B (zh) 用于提供视频比特流的方法及装置
EP3346709B1 (en) An apparatus, a method and a computer program for video coding and decoding
CN112673638B (zh) 处理媒体数据的方法和装置
EP3349467B1 (en) An apparatus, a method and a computer program for video coding and decoding
WO2017093611A1 (en) A method for video encoding/decoding and an apparatus and a computer program product for implementing the method
WO2017140946A1 (en) An apparatus, a method and a computer program for video coding and decoding
WO2017140948A1 (en) An apparatus, a method and a computer program for video coding and decoding
WO2016185090A1 (en) An apparatus, a method and a computer program for video coding and decoding
WO2018115572A2 (en) An apparatus, a method and a computer program for video coding and decoding
US11909983B2 (en) Apparatus, a method and a computer program for video coding and decoding
EP4266690A1 (en) An apparatus, a method and a computer program for video coding and decoding
CN118042095A (zh) 用于视频编码和解码的装置、方法和计算机程序

Legal Events

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