使用WEBSOCKET子协议来传输媒体数据的制作方法

本申请要求2015年5月13日提交的美国临时申请no.62/160,928的权益，通过引用方式将其全部内容并入本文。

本公开内容涉及编码的视频数据的存储和传输。

背景技术：

数字视频能力能够结合到各种各样的设备当中，包括数字电视、数字直接广播系统、无线广播系统、个人数字助理(pda)、膝上型计算机或台式计算机、数字照相机、数字记录设备、数字媒体播放器、视频游戏设备、视频游戏控制台、蜂窝电话或卫星无线电电话、视频电信会议设备等。数字视频设备实施视频压缩技术，例如，在由mpeg-2、mpeg-4、itu-th.263或itu-th.264/mpeg-4，part10、高级视频编码(avc)以及这些标准的扩展规定的标准中描述的那些技术，来更有效率地发送和接收数字视频信息。

在视频数据编码之后，视频数据可以划分成分组，以进行传输或存储。视频数据可以组装成符合各种标准中的任何标准的视频文件，该标准例如是国际标准化组织(iso)基础媒体文件格式及其扩展，例如avc。

技术实现要素：

概括而言，本申请描述了用于在流媒体环境下处理信道改变事件的技术。具体而言，可以使用文件转换格式，例如，通过单向传输的实时对象传送(route)将媒体数据传送给代理服务器。客户端设备可以包括接收来自代理服务器的媒体数据的流媒体客户端，例如，通过http的动态自适应流媒体(dash)客户端。使用本公开内容的技术，流媒体客户端和代理服务器可以建立websocket会话，特别地，对websocket子协议进行协商。代理服务器可以最初确定调谐信道已经从先前信道改为了当前信道。但是，代理服务器可以在未接收到来自流媒体客户端的对当前信道的媒体数据的请求的情况下，以及在未向流媒体客户端发送针对当前信道的清单文件的情况下(例如，在发送针对当前信道的清单文件之前)使用websocket子协议将当前信道的媒体数据传送至流媒体客户端。

在一个示例中，一种传输媒体数据的方法包括：由用于包括流媒体客户端的客户端设备的代理服务器确定针对客户端设备的调谐信道已经从先前信道改变为当前信道；以及响应于针对客户端设备的调谐信道已经从先前信道改变为当前信道的确定，在未从流媒体客户端接收到针对媒体数据的请求的情况下，根据websocket子协议将当前信道的媒体数据传送给客户端设备的流媒体客户端。

在另一示例中，一种用于传输媒体数据的设备包括被配置为存储媒体数据的存储器以及被配置为执行用于包括流媒体客户端的客户端设备的代理服务器的一个或多个处理器。代理服务器被配置为确定针对客户端设备的调谐信道已经从先前信道改变为当前信道；以及响应于针对客户端设备的调谐信道已经从先前信道改变为当前信道的确定，在未从流媒体客户端接收到针对媒体数据的请求的情况下，根据websocket子协议将当前信道的媒体数据传送给客户端设备的流媒体客户端。

在另一示例中，一种用于传输媒体数据的设备包括：用于确定针对客户端设备的调谐信道已经从先前信道改变为当前信道的单元，该客户端设备执行流媒体客户端；以及用于响应于针对客户端设备的调谐信道已经从先前信道改变为当前信道的确定，在未从流媒体客户端接收到针对媒体数据的请求的情况下，根据websocket子协议将当前信道的媒体数据传送给客户端设备的流媒体客户端的单元。

在另一示例中，一种计算机可读存储介质具有存储于其上的指令，该指令在受到执行时使处理器执行以下操作：确定针对客户端设备的调谐信道已经从先前信道改变为当前信道，该客户端设备执行流媒体客户端，以及响应于针对客户端设备的调谐信道已经从先前信道改变为当前信道的确定，在未从流媒体客户端接收到针对媒体数据的请求的情况下，根据websocket子协议将当前信道的媒体数据传送给客户端设备的流媒体客户端。

在附图和下面的描述当中将阐述一个或多个示例的细节。其它特征、目的和优点将通过描述和附图以及权利要求变得显而易见。

附图说明

图1是示出实现用于通过网络的流媒体数据的技术的示例性系统的方块图。

图2是示出获取单元的示例性组件集合的方块图。

图3是示出示例性多媒体内容的要素的示意图。

图4是示出示例性视频文件的要素的方块图。

图5是示出可以执行本公开内容的技术的示例性系统的方块图。

图6是示出处于系统的组件之间的示例性通信交换的流程图。

具体实施方式

概括而言，本公开内容描述了用于例如使用websocket协议将媒体数据从代理服务器传输至客户端设备的流媒体客户端的技术。代理服务器可以使用多媒体广播/多播服务(mbms)或增强型mbms(embms)，经由诸如空中(ota)广播或者网络广播的广播，接收媒体数据。替代地，代理服务器可以从经由广播接收媒体数据的诸如信道调谐器设备的单独设备，获得媒体数据。代理服务器可以被配置为相对于流媒体客户端充当服务器设备。流媒体客户端可以被配置为使用网络流媒体技术，例如，通过http的动态自适应流媒体(dash)技术，从代理服务器获取媒体数据以及呈现媒体数据。

用户可以在观察媒体数据(例如，听音频和/或看视频)时，与信道调谐器(即信道选择设备)交互。此外，用户可以与信道调谐器交互以改变当前调谐信道。例如，如果用户当前正在一个信道上观看节目，那么用户可以切换到新的信道上观看不同的节目。作为响应，信道调谐器可以切换至新的信道，并开始接收新的信道的媒体数据。同样地，信道调谐器可以将新信道的媒体数据提供给代理服务器。

作为诸如dash的流媒体服务的一部分，流媒体客户端(例如，dash客户端)通常使用诸如媒体呈现描述(mpd)的清单文件，以从服务器设备获取媒体数据。因而，常规流媒体客户端将在能够在信道改变事件之后获取新信道的媒体数据之前，等待清单文件的传送。但是，等待清单文件可能延迟信道改变事件和用户能够观察新信道的媒体数据的时间之间的时间，即使已经接收到了新信道的可播放数据。因而，本公开内容描述了即使在不向流媒体客户端传送与新信道相关联的清单文件的情况下(例如，在向流媒体客户端传送与新信道相关联的清单文件之前)，也能实现将新信道的媒体数据传送给流媒体客户端的技术。

具体而言，如下文将更详细解释的，代理服务器和流媒体客户端可以被配置为根据websocket子协议进行通信。因而，代理服务器可以经由websocket子协议将媒体数据传送至流媒体客户端，而不是等待来自流媒体客户端的针对媒体数据的请求(例如，httpget请求)。在tools.ietf.org/html/rfc6455可获得的，作者为fette等人的,"websocket协议"，因特网工程特别小组，rfc6455,2011年12月中描述了websocket协议。在rfc6455的1.9节中描述了websocket子协议。

本公开内容的技术可以使用，在walker等人的题目为“transportinterfaceformultimediaandfiletransport”的美国申请no.14/958,086中描述的技术中的一些技术或者所有技术，通过引用方式将上述内容的每一内容的全部内容并入本文。这些临时申请描述了媒体数据事件(mde)。可以使用mde缩短信道改变时间，例如，对于广播电视(tv)服务而言。这些技术可以与线性tv有关，尤其与分段(即，基于文件的)传送服务有关。

基于文件的或者基于分段的传送服务连同其它服务可以在例如数据根据dash进行格式化时使用，并且可以用到通过单向传输的实时目标传送(route)协议或者通过单向传输的文件传送(flute)协议当中，如paila等人的,“flute—filedeliveryoverunidirectionaltransport,”网络工作组,rfc6726,2012年11月中所定义的，该文献可以通过tools.ietf.org/html/rfc6726获得。基于分段的传送技术可以看作与http分块类似，在http分块中，较大的有效载荷划分成几个较小的有效载荷。但是，基于分段的传送技术和http分块之间的重要区别在于“分块”(即mde)一般是针对即时消费而提供的。也就是说，mde包括可播放媒体，并且假设接收机已经具有了必要的媒体元数据(编解码器、加密元数据等)来发起mde的播出。

最近，已经提出了dash解决方案，以用于下一代无线视频广播。dash已经成功地与宽带接入结合使用(即，基于计算机网络的广播传送)。这允许混合传送方案。用于dash接收的html和javascript客户端被配置为使用宽带传送。广播技术很少扩展至网页浏览器应用，但是dash客户端(其可以嵌入到网页浏览器应用当中)可以从代理服务器获取媒体数据，该代理服务器可以形成执行网页浏览器应用的同一客户端设备的一部分。

dashjavascript客户端能够利用媒体呈现描述(mpd)或者其它清单文件来确定内容的位置。mpd一般形成为可扩展标记语言(xml)文档。mpd还提供媒体分段的url位置的指示。

dashjavascript客户端可以使用浏览器提供的诸如通过http的xml(xhr)的javascript方法来取得分段。xhr能够用于执行对各分段的分块传送。一般而言，xhr不用于将分块(即，局部分段)释放至javascript，而是释放完整的分段。字节范围请求能够用于实现局部分段请求，但是dash客户端一般不能确定字节范围和mde之间的映射。mpd能够扩展为描述mde和相关联的字节范围，但是这将迫使dash客户端获取针对快速信道改变而特别量身定制的mpd。本公开内容的技术可以避免这一要求。

如上文指出的，本公开内容的技术可以利用websocket和websocket子协议。websocket被引入到了html5当中，以作为在基于网页的客户端和服务器之间建立双路通信的方式。用于websocket的url通常包括“ws:∥”前缀或者用于安全websocket的“wss:∥”。websocket(url)是具有准备状态只读属性(连接、打开、关闭或已关闭)的主接口。在扩展以及协议中还定义了其它只读属性，并且该其它只读属性正在等待进一步的规范。websocket(url)主接口传播三种事件：在打开、发生错误和在关闭。websocket(url)还提供两种方法：发送()和关闭()。发送()能够采取三个自变量：串、滴或阵列缓冲。websocket(url)主接口能够访问只读属性缓冲的量(长)，以作为发送()处理的一部分。在诸如mozilla火狐、谷歌chrome等的各种各样的网页浏览器中，均提供了对websocket的扩展性支持。

下文示出了websocket声明的示例(其中，跟在双斜线“∥”后面的文本表示不执行的注释)：

varconnection＝newwebsocket('ws://qrtcserver.qualcomm.com')；

//‘ws://’以及‘wss://’分别是针对websocket和安全websocket的新url方案

//在连接打开时，将一些数据发送至服务器

connection.onopen＝function(){

connection.send('ping')；//将消息'ping'发送至服务器

}；

//记录错误

connection.onerror＝function(error){

console.log('websocketerror'+error)；

}；

//记录来自服务器的消息

connection.onmessage＝function(e){

console.log('server:'+e.data)；

}；

因特网工程特别小组(ietf)具有在rfc6455中规定的针对websocket的对应规范。ua并不应websocket请求而发起标准http连接。http握手可以通过tcp连接发生。同一连接能够由连接至同一服务器的其它网页应用重复使用。服务器可以服务“ws:∥”类型请求以及“http:∥”类型请求两者。

下面示出了来自rfc6455的1.2节的客户端握手以及服务器响应的示例：

客户端握手：

get/chathttp/1.1

host:server.example.com

upgrade:websocket

connection:upgrade

sec-websocket-key:dghlihnhbxbszsbub25jzq＝＝

origin:http://example.com

sec-websocket-protocol:chat,superchat

sec-websocket-version:13

服务器响应：

http/1.1101switchingprotocols

upgrade:websocket

connection:upgrade

sec-websocket-accept:s3pplmbitxaq9kygzzhzrbk+xoo＝

sec-websocket-protocol:chat

如rfc6455的1.9节中解释的，websocket子协议可以通过使用rfc6455的11.5节注册子协议名称而形成。一般而言，注册涉及注册子协议标识符、子协议通用名以及子协议定义。为了使用子协议，rfc6455的11.3.4节指示，客户端设备应当在针对服务器设备的websocket打开握手当中包括子协议特定的报头。

在http握手中指定扩展或协议是任选的。在握手完成之后，可以使用诸如在rfc6455中定义的帧协议交换数据。也就是说，数据交换可以包括操作码，以定义消息类型(控制、数据等)、掩码(可能要求对客户端到服务器数据进行掩盖，而服务器到客户端数据则可能要求不受掩盖)、有效载荷长度和有效载荷数据。指示将关闭连接的控制帧可以引起“tcpfin”消息，该消息将终止tcp连接。

本公开内容的技术可以应用于符合根据iso基础媒体文件格式、可缩放视频编码(svc)文件格式、高级视频编码(avc)文件格式、第三代合作伙伴计划(3gpp)文件格式、和/或多视图视频编码(mvc)文件格式或者其它类似视频文件格式中的任何格式封装的视频数据的视频文件。

在http流媒体当中，频繁使用的操作包括head、get和局部get。head操作获取与给定的统一资源定位符(url)或者统一资源名称(urn)相关联的文件的报头，而无需获取与url或urn相关联的有效载荷。get操作获取与给定url或urn相关联的整个文件。局部get操作接收字节范围作为输入参数，并获取文件的连续数量的字节，其中，字节数量对应于所接收的字节范围。因而，可以提供电影片段以用于http流媒体，因为局部get操作能够获取一个或多个独立的电影片段。在电影片段当中，可能存在不同轨迹的数个轨迹片段。在http流媒体中，媒体呈现可以是可由客户端访问的结构化的数据集合。客户端可以请求并下载媒体数据信息，以将流媒体服务呈现给用户。

在使用http流媒体对3gpp数据进行流传输的示例中，可能存在多种对多媒体内容的视频和/或音频数据的表示。如下文所解释的，不同的表示可以对应于不同的编码特性(例如，视频编码标准的不同概况或等级)、不同编码标准或各编码标准的扩展(例如，多视图和/或可缩放扩展)或者不同比特率。可以在媒体呈现描述(mpd)数据结构中定义这样的表示的清单。媒体呈现可以对应于http流媒体客户端设备可访问的结构化的数据集合。http流媒体客户端设备可以请求并下载媒体数据信息，从而将流媒体服务呈献给客户端设备的用户。可以在可以包括mpd的更新的mpd数据结构中描述媒体呈现。

媒体呈现可以包含一个或多个时段的序列。可以通过mpd中的时段元素定义时段。每一时段可以具有mpd中的属性开始。mpd可以针对每一时段包括开始属性和可用开始时间属性。对于实况服务而言，时段的开始属性和mpd属性可用开始时间之和可以按照utc格式指定该时段的可用性时间，尤其是对应时段内的每一表示的第一媒体分段。对于按需服务而言，第一时段的开始属性可以是0。对于任何其它时段而言，开始属性可以指定对应时段的起始时间相对于第一时段的起始时间之间的时间偏移量。每一时段可以延展直到下一时段的开始为止或者直到在上一时段的情况中的媒体呈现的结束为止。时段起始时间可以是确切的。它们可以反映由播放所有先前时段的媒体得到的实际定时。

每一时段可以包含对同一媒体内容的一种或多种表示。表示可以是音频或视频数据的多个替代编码版本中的一个编码版本。表示可能因编码类型，例如，因针对视频数据的比特率、分辨率和/或编解码器以及针对音频数据的比特率、语言和/或编解码器而存在差异。术语表示可以用于指代对应于多媒体内容的特定时段并且按照特定方式编码的编码音频或视频数据的一部分。

特定时段的表示可以分配给由mpd中的指示表示所属的适应集的属性所指示的群组。将同一适应集中的表示一般看作是相互的替代方案，因为客户端设备能够动态并且无缝地在这些表示之间进行切换，从而例如执行带宽适应。例如，针对特定时段的视频数据的每一表示可以分配给同一适应集，使得表示中的任何表示都可以被选择为用于解码，以呈现针对对应时段的多媒体内容的媒体数据，例如，视频数据或音频数据。在一些示例中，一个时段内的媒体内容可以由来自群组0的一个表示(如果存在的话)来表示，或者可以由来自每一非零群组的最多一个表示的组合来表示。时段的每一表示的定时数据可以是相对于该时段的起始时间表达的。

表示可以包括一个或多个分段。每一表示可以包括初始化分段，或者表示的每一分段可以是自初始化的。在存在初始化分段时，初始化分段可以包含用于访问表示的初始化信息。一般而言，初始化分段不包含媒体数据。可以由诸如统一资源定位符(url)、统一资源名称(urn)或统一资源标识符(uri)的标识符对分段做出唯一标示。mpd可以为每一分段提供标识符。在一些示例中，mpd还可以提供具有范围属性的形式的字节范围，该字节范围可以对应于针对可由url、urn或uri访问的文件内的分段的数据。

对于针对不同类型的媒体数据基本同时进行获取，可以选择不同的表示。例如，客户端设备可以选择音频表示、视频表示和定时文本表示，从而从中进行分段获取。在一些示例中，客户端设备可以选择用于执行带宽适应的特定适应集。也就是说，客户端设备可以选择包括视频表示的适应集，包括音频表示的适应集和/或包括定时文本的适应集。替代地，客户端设备可以选择针对某些类型的媒体(例如，视频)的适应集，并针对其它类型的媒体(例如，音频和/或定时文本)直接选择表示。

图1是示出实现用于通过网络的流媒体数据的技术的示例性系统10的方块图。在这一示例中，系统10包括内容准备设备20、服务器设备60和客户端设备40。客户端设备40和服务器设备60由网络74通信耦合，网络74可以包括因特网。在一些示例中，内容准备设备20和服务器设备60也可以由网络74或另一网络耦合，或者可以直接通信耦合。在一些示例中，内容准备设备20和服务器设备60可以包括同一设备。

在图1的示例中，内容准备设备20包括音频源22和视频源24。音频源22可以包括，例如产生表示将由音频编码器26编码的俘获音频数据的电信号的麦克风。替代地，音频源22可以包括存储先前记录的音频数据的存储介质、诸如计算机化合成器的音频数据发生器或者任何其它音频数据源。视频源24可以包括产生将由视频编码器28编码的视频数据的摄影机、以先前记录的视频数据编码的存储介质、诸如计算机图形源的视频数据发生单元或者任何其它视频数据源。内容准备设备20不必在所有的示例中都通信耦合至服务器设备60，而是可以将多媒体内容存储到由服务器设备60读取的单独介质。

原始音频和视频数据可以包括模拟或数字数据。模拟数据可以在由音频编码器26和/或视频编码器28编码之前进行数字化。音频源22可以在谈话参与者正在讲话时，获得来自谈话参与者的音频数据，并且视频源24可以同时获得该谈话参与者的视频数据。在其它示例中，音频源22可以包括包含所存储的音频数据的计算机可读存储介质，并且视频源24可以包括包含所存储的视频数据的计算机可读存储介质。通过这种方式，在本公开内容中描述的技术可以应用于实况的流媒体实时音频和视频数据，或者应用于归档的预先记录音频和视频数据。

对应于视频帧的音频帧一般是音频帧，该音频帧包含与由视频源24俘获(或生成)的包含在视频帧内的视频数据同时地由音频源22俘获(或生成)的音频数据。例如，在谈话参与者一般通过讲话产生音频数据的同时，音频源22俘获音频数据，也就是说，在音频源22俘获音频数据的同时，视频源24同时俘获谈话参与者的视频数据。因而，音频帧可以暂时地对应于一个或多个特定视频帧。相应地，对应于视频帧的音频帧一般对应于，音频数据和视频数据同时俘获并且音频帧和视频帧分别包括被同时俘获的音频数据和视频数据的情况。

在一些示例中，音频编码器26可以在每一经过编码的音频帧中编码时间戳，该时间戳表示记录针对经过编码的音频帧的音频数据的时间，并且类似地，视频编码器28可以在每一编码的视频帧中编码时间戳，该时间戳表示记录针对编码的视频帧的视频数据的时间。在这样的示例中，对应于视频帧的音频帧可以包括包含时间戳的音频帧和包含相同时间戳的视频帧。内容准备设备20可以包括内部时钟，音频编码器26和/或视频编码器28可以由该内部时钟生成时间戳，或者音频源22和视频源24可以使用内部时钟，分别使音频数据和视频数据与时间戳相关联。

在一些示例中，音频源22可以向音频编码器26发送对应于记录音频数据的时间的数据，并且视频源24可以向视频编码器28发送对应于记录视频数据的时间的数据。在一些示例中，音频编码器26可以对已经编码的音频数据中的序列标识符编码，以指示已经编码的音频数据的相对时间排序，而不必指示记录音频数据的绝对时间，并且类似地，视频编码器28还可以使用序列标识符以指示编码的视频数据的相对时间排序。类似地，在一些示例中，序列标识符可以映射至时间戳或者以其它方式与时间戳相关联。

音频编码器26一般产生经过编码的音频数据流，而视频编码器28则产生经过编码的视频数据流。每一单独数据流(不管是音频还是视频)都可以称为单元流。单元流是表示的单个数字编码(可能受到压缩的)的组成部分。例如，表示的编码的视频或音频部分能够是单元流。单元流可以转化为分组化的单元流(pes)，而后压缩到视频文件内。在同一表示内，流id可以用于对属于一个单元流的pes分组与其它分组进行区分。单元流的数据的基本单位是分组化的单元流(pes)分组。因而，编码的视频数据一般对应于单元视频流。类似地，音频数据对应于一个或多个相应单元流。

很多视频编码标准，例如，itu-th.264/avc和高效率视频编码(hevc)标准(又称为itu-th.265)定义了用于无误差位流的语法、语义和解码过程，其中的任何项均符合某个概况或等级。视频编码标准通常不指定编码器，但是编码器负有保证所生成的位流对于解码器而言符合标准的任务。在视频解码标准的语境下，“概况”对应于应用于标准的算法、特征或者工具和约束条件的子集。如h.264标准定义的，例如，“概况”是h.264标准指定的全部位流语法的子集。“等级”对应于诸如例如解码器存储和计算的解码器资源消耗的限制，该解码器存储和计算与图像分辨率、比特率和块处理速率有关。可以利用profile_idc(概况指示符)值对概况进行信号指示，而等级可以利用level_idc(等级指示符)值进行信号指示。

例如，h.264标准认识到，在由给定概况的语法施加的界限之内，仍然有可能要求编码器和解码器的性能存在大的变化，该变化取决于位流内的语法元所取的值，例如，解码图像的指定大小。h.264标准还认识到，在很多应用中，实现能够处理特定概况内的语法的所有假想使用的解码器既不实际也不经济。相应地，h.264标准定义了“等级”作为施加到位流中的语法元的值上的指定的约束条件集合。这些约束条件可以是简单的针对值的限制。替代地，这些约束条件可以采取针对值的算数组合(例如，图像宽度乘以图像高度乘以每秒解码的图像的数量)的约束条件的形式。h.264标准还提供了：单个实施方式可以支持针对每一受支持的概况的不同等级。

符合概况的解码器通常支持概况内定义的所有特征。例如，作为编码特征，b图像编码在h.264/avc的基线概况内不受支持，但是在h.264/avc的其它概况中则受到支持。符合等级的解码器应当能够对任何不要求超过该等级定义的限制的资源的位流进行解码。概况和等级的定义可以对可解释性有所帮助。例如，在视频传输期间，可以针对整个传输会话对概况定义和等级定义的对进行协商并达成一致。更具体而言，在h.264/avc中，等级可以定义针对需要处理的宏块的数量、解码图像缓冲器(dpb)大小、编码图像缓冲器(cpb)大小、垂直运动向量范围、每两个相继mb的运动向量的最大数量以及b块是否能够具有小于8×8像素的子宏块分割的限制。通过这种方式，解码器可以确定解码器是否能够适当地对位流解码。

在图1的示例中，内容准备设备20的封装单元30接收来自视频编码器28的包括编码视频数据的单元流以及来自音频编码器26的包括编码音频数据的单元流。在一些示例中，视频编码器28和音频编码器26各可以包括用于形成来自编码数据的pes分组的分组化器。在其它示例中，视频编码器28和音频编码器26各可以与相应的用于形成来自编码数据的pes分组的分组化器连接。在仍另外的示例中，封装单元30可以包括用于形成来自编码音频数据和编码视频数据的pes分组的分组化器。

视频编码器28可以通过各种方式对多媒体内容的视频数据进行编码，以各种比特率并利用各种特性产生多媒体内容的不同表示，例如，该特性为像素分辨率、帧速率、对各种编码标准的符合性、对各种编码标准的各种概况和/或概况的等级的符合性、具有一个或多个视图的表示(例如，对于二维或三维重放而言)或者其它此类特性。如本公开内容中使用的，表示可以包括音频数据、视频数据、文本数据(例如，对于隐藏式字幕)或者其它此类数据中的一种。表示可以包括单元流，例如，音频单元流或视频单元流。每一pes分组可以包括标识该pes分组所属的单元流的stream_id。封装单元30负责将单元流组装到各种表示的视频文件(例如，分段)当中。

封装单元30从音频编码器26和视频编码器28接收用于表示的单元流的pes分组，并从pes分组形成对应的网络提取层(nal)单元。在h.264/avc(高级视频编码)的示例中，将编码视频分段组织成nal单元，该nal单元提供“网络友好”的视频表示寻址应用，例如，视频电话、存储、广播或流媒体。nal单元能够分类为视频编码层(vcl)nal单元和非vclnal单元。vcl单元可以包含核心压缩引擎，并且可以包括块、宏块和/或切片级数据。其它nal单元可以是非vclnal单元。在一些示例中，一个时间实例中的通常呈现为主编码图像的编码图像，可以包含在可以包括一个或多个nal单元的访问单元中。

非vclnal单元可以包括参数集nal单元和seinal单元连同其它单元。参数集可以含包含序列级报头信息(在序列参数集(sps)内)和很少改变的图像级报头信息(在图像参数集(pps)内)。利用参数集(例如，pps和sps)，不必针对每一序列或图像重复很少改变的信息，因而可以提高编码效率。此外，参数集的使用可以实现对重要报头信息的带外传输，从而避免对用于误差复原的冗余传输的需求。在带外传输示例中，参数集nal单元可以在不同于诸如seinal单元的其它nal单元的信道上发送。

补充增强信息(sei)可以包含对于解码来自vclnal单元的编码图像样本而言不需要的信息，但是可以辅助与解码、显示、差错复原以及其它目的有关的过程。sei消息可以包含在非vclnal单元当中。sei消息是一些标准规约的规范部分，因而对于符合标准的解码器实施方式而言并不总是强制性的。sei消息可以是序列级sei消息或者图像级sei消息。一些序列级信息可以包含在sei消息内，例如，svc的示例中的可缩放性信息sei消息以及mvc当中的视图可缩放性信息sei消息内。这些示例性sei消息可以传达有关例如操作点的提取以及操作点的特性的信息。此外，封装单元30可以形成清单文件，例如，描述表示的特性的媒体呈现描述符(mpd)。封装单元30可以根据可扩展标记语言(xml)对mpd格式化。

封装单元30可以将用于多媒体内容的一种或多种表示的数据连同清单文件(例如，mpd)一起提供至输出接口32。输出接口32可以包括网络接口或者用于对存储介质进行写入的接口，例如，通用串行总线(usb)接口、cd或dvd写入器或烧写器、对磁存储介质或闪速存储介质的接口或者其它用于存储或者发送媒体数据的接口。封装单元30可以将多媒体内容的表示中的每种表示的数据提供至输出接口32，该输出接口32可以将数据经由网络传输或存储介质发送至服务器设备60。在图1的示例中，服务器设备60包括存储各种多媒体内容64的存储介质62，该多媒体内容64各包括相应的清单文件66以及一个或多个表示68a-68n(表示68)。在一些示例中，输出接口32还可以将数据直接发送至网络74。

在一些示例中，表示68可以分隔到适应集内。也就是说，表示68的各个子集可以包括各自的公共特性集合，例如，编解码器、概况和等级、分辨率、视图数量、针对分段的文件格式、可以识别要连同表示和/或要解码并且通过例如扬声器呈现的音频数据一起显示的文本的语言或其它特性的文本类型信息、可以描述对于适应集内的表示而言景物的摄像机角度或现实世界摄像机视角的摄像机角度信息、描述对于特定观众而言的内容适合性的评分信息等等。

清单文件66可以包括指示对应于特定适应集的表示68的子集以及对于适应集的公共特性的数据。清单文件66还可以包括表示针对适应集的各个表示的诸如比特率的各项特性的数据。通过这种方式，适应集可以提供简化的网络带宽适应。可以使用清单文件66的适应集元的子元指示适应集中的表示。

服务器设备60包括请求处理单元70和网络接口72。在一些示例中，服务器设备60可以包括多个网络接口。此外，服务器设备60的任何或所有特征都可以在内容传送网络的其它设备上实现，该其它设备例如是路由器、桥、代理设备、交换机或其它设备。在一些示例中，内容传送网络的中间设备可以对多媒体内容64的数据进行高速缓存，并可以包括与服务器设备60的那些组件基本一致的组件。一般而言，网络接口72被配置为经由网络74发送和接收数据。

请求处理单元70被配置为接收来自诸如客户端设备40的客户端设备的针对存储介质62的数据的网络请求。例如，请求处理单元70可以实现超文本传输协议(http)版本1.1，如rfc2616,“hypertexttransferprotocol–http/1.1,”r.fielding等人,网络工作组,ietf,1999年6月中所述的。也就是说，请求处理单元70可以被配置为接收httpget请求或http局部get请求，并响应于请求提供多媒体内容64的数据。请求可以指定表现68中的一个表现的分段，例如，使用该分段的url。在一些示例中，所述请求还可以指定分段的一个或多个字节范围，因而包括局部get请求。请求处理单元70还可以被配置为服务于httphead请求，以提供表示68中的一个表示的分段的报头数据。在任何情况下，请求处理单元70可以被配置为对请求进行处理，以向诸如客户端设备40的请求设备提供所请求的数据。

额外地或者替代地，请求处理单元70可以被配置为经由诸如embms的广播或多播协议，传送媒体数据。内容准备设备20可以按照基本上与所描述的相同的方式，创建dash分段和/或子分段，但是服务器设备60可以使用embms或者另一广播或多播网络传输协议，传送这些分段或子分段。例如，请求处理单元70可以被配置为接收来自客户端设备40的多播群加入请求。也就是说，服务器设备60可以向包括客户端设备40的与特定媒体内容(例如，实况事件的广播)相关联的客户端设备，通知与多播群组相关联的因特网协议(ip)地址。客户端设备40接着可以提交加入该多播群组的请求。这一请求可以是通过诸如路由器构成的网络74的网络74传播的，从而使得路由器将以与多播群组相关联的ip地址为目的地的业务引导至订制客户端设备，例如，客户端设备40。

此外，根据本公开内容的某些技术，服务器设备60可以经由空中(ota)广播将媒体数据发送至客户端设备40。也就是说，服务器设备60可以经由ota广播发送媒体数据，而不是经由网络74传送媒体数据，该ota广播可以经由天线、卫星或者有线电视提供商等发送。

如图1的示例中所示，多媒体内容64包括清单文件66，该清单文件66可以对应于媒体表示描述(mpd)。清单文件66可以包含不同备选表示68(例如，具有不同质量的视频服务)的描述，并且描述可以包括，例如编解码器信息、概况值、等级值、比特率以及表示68的其它描述性特性。客户端设备40可以获取媒体呈现的mpd，以确定如何访问表示68的分段。

具体而言，获取单元52可以获取客户端设备40的配置数据(未示出)，以确定视频解码器48的解码能力和视频输出44的渲染能力。配置数据还可以包括以下各项中的任何项或全部项：客户端设备40的用户选择的语言偏好、对应于由客户端设备40的用户设置的深度偏好的一个或多个摄像机视角和/或由客户端设备40的用户选择的评分偏好。获取单元52可以包括，例如被配置为提交httpget请求和局部get请求的网页浏览器或者媒体客户端。获取单元52可以对应于由客户端设备40的一个或多个处理器或处理单元(未示出)执行的软件指令。在一些示例中，参照获取单元52描述的功能的全部或部分功能可以通过硬件或者硬件、软件和/或固件的组合来实现，其中，可以提供必要的硬件，以执行软件或固件的指令。

获取单元52可以将客户端设备40的解码和渲染能力与清单文件66的信息指示的表示68的特性进行比较。获取单元52可以最初获取清单文件66的至少一部分，以确定表示68的特性。例如，获取单元52可以请求描述一个或多个适应集的特性的清单文件66的一部分。获取单元52可以选择具有能够由客户端设备40的编码和渲染能力满足的特性的表示68的子集(例如，适应集)。之后，获取单元52可以确定适应集中的表示的比特率，确定当前可用的网络带宽的量，并从具有能够由网络带宽满足的比特率的表示中的一个表示中获取分段。

一般而言，较高的比特率表示可以产生较高质量视频重放，而较低比特率的表示则在可用网络带宽下降时，可以提供足够质量的视频重放。相应地，在可用网络带宽相对较高时，获取单元52可以从相对较高比特率的表示中获取数据，而在可用网络带宽低时，获取单元52则可以从相对较低比特率的表示中获取数据。通过这种方式，客户端设备40可以通过网络74进行多媒体数据流传输，同时还适合于网络74的变化的网络带宽可用性。

额外地或者替代地，获取单元52可以被配置为根据诸如embms或ip多播的广播或多播网络协议接收数据。在这样的示例中，获取单元52可以提交加入与特定媒体内容相关联的多播网络群组的请求。在加入多播群之后，获取单元52可以在不向服务器设备60或内容准备设备20发出进一步的请求的情况下，接收多播群组的数据。获取单元52可以在不再需要多播群组的数据时，提交离开多播群组的请求，从而停止重放或者将信道改到不同的多播群。

如上文所指出的，获取单元52，在一些示例中，可以被配置为接收来自服务器设备60的ota广播。在这样的示例中，获取单元52可以包括ota接收单元和流媒体客户端，例如，如下文参照图2更加详细的图示和描述的。一般而言，流媒体客户端(例如，dash客户端)可以被配置为能够实施推送。也就是说，流媒体客户端可以在不首先从代理服务器请求媒体数据的情况下，接收来自代理服务器的媒体数据。因而，代理服务器可以向流媒体客户端推送媒体数据，而不是响应于来自流媒体客户端的对媒体数据的请求而传送媒体数据。

能够实施推送的技术可以在快速的信道变化中提高性能。因而，如果获取单元52确定发生了信道变化事件(也就是说，当前信道已经从先前信道切换到了新信道)，那么代理服务器可以向流媒体客户端推送新信道的媒体数据。获取单元52可以被配置为使用websocket，而不是使用xhr，来实施这一基于推送的传送。因而，可以通过信道调谐器发起的事件结合信道改变事件。例如，本公开内容的用于信道改变和基于推送的传送的技术可以避开javascript，并且代理服务器可以确定发生了信道改变事件。响应于信道改变事件，代理服务器可以立即开始向流媒体客户端传送mde而不是分段。在一些示例中，代理服务器向流媒体客户端提供与媒体数据一起的描述“带内”信道改变的信息，例如，通过websocket连接向流媒体客户端提供该信息。

网络接口54可以接收所选择的表示的分段的数据，并将其提供给获取单元52，该获取单元52接着将分段提供给解封装单元50。解封装单元50可以将视频文件的元解封装成构成pes流，对pes流去分组化，以获取编码数据，并将编码数据发送至音频解码器46或视频解码器48，这取决于编码数据是音频流的一部分还是视频流的一部分，例如，如流的pes分组报头所指示的。音频解码器46对编码音频数据解码，并将解码的音频数据发送至音频输出42，而视频解码器48则对编码视频数据解码，并将可以包括流的多个视图的解码的视频数据发送至视频输出44。

视频编码器28、视频解码器48、音频编码器26、音频解码器46、封装单元30、获取单元52和解封装单元50各可以按照适用情况实现为以下各种适当处理电路中的任何适当处理电路：例如，一个或多个微处理器、数字信号处理器(dsp)、专用集成电路(asic)、现场可编程门阵列(fpga)、分立逻辑电路、软件、硬件、固件或其任何组合。视频编码器28和视频解码器48中的每者可以包括在一个或多个编码器或解码器当中，编码器和解码器中的任一者都可以整合为组合的视频编码器/解码器(codec)的一部分。类似地，音频编码器26和音频解码器46中的每者都可以包括在一个或多个编码器或解码器当中，编码器和解码器中的任一者都可以整合为组合的codec的一部分。包括视频编码器28、视频解码器48、音频编码器26、音频解码器46、封装单元30、获取单元52和/或解封装单元50的装置可以包括集成电路、微处理器和/或诸如蜂窝电话的无线通信设备。

客户端设备40、服务器设备60和/或内容准备设备20可以被配置为根据本公开内容的技术操作。出于示例的目的，本公开内容参照客户端设备40和服务器设备60描述了这些技术。但是，应当理解，代替服务器设备60(或者除了服务器设备60以外)，内容准备设备20可以被配置为执行这些技术。

封装单元30可以形成nal单元，该nal单元包括识别该nal单元所属的节目的报头以及有效载荷，例如，音频数据、视频数据或者描述nal单元对应的传输或节目流的数据。例如，在h.264/avc中，nal单元包括1字节报头和大小变化的有效载荷。包括其有效载荷中的视频数据的nal单元可以包括各种粒度级别的视频数据。例如，nal单元可以包括视频数据块、多个块、视频数据的切片或者视频数据的整个图像。封装单元30可以接收来自视频编码器28的具有单元流的pes分组的形式的编码视频数据。封装单元30可以使每一单元流与对应的节目相关联。

封装单元30还可以从多个nal单元组装访问单元。一般而言，访问单元可以包括用于表示视频数据帧以及当音频数据可用时，对应于该帧的这样的音频数据的一个或多个nal单元。访问单元一般包括针对一个输出时间实例的所有nal单元，例如，针对一个时间实例的所有音频和视频数据。例如，如果每一视图具有每秒20帧(fps)的帧速率，那么每一时间实例可以对应于0.05秒的时间间隔。在这一时间间隔期间，可以同时渲染针对同一访问单元(同一时间实例)的所有视图的具体帧。在一个示例中，访问单元可以包括一个时间实例中的编码图像，该编码图像可以呈现为主编码图像。

相应地，访问单元可以包括公共时间实例的所有音频和视频帧，例如，对应于时间x的所有视图。本公开内容还将特定视图的编码图像称为“视图组成部分”。也就是说，视图组成部分可以包括特定时间上的针对特定视图的编码图像(或帧)。相应地，访问单元可以定义为包括公共时间实例的所有视图组成部分。访问单元的解码顺序不一定需要与输出或显示顺序相同。

媒体呈现可以包括媒体呈现描述(mpd)，该媒体呈现描述(mpd)可以包含对不同替代表示(例如，具有不同质量的视频服务)的描述，并且描述可以包括，例如编解码器信息、概况值和等级值。mpd是清单文件的一个示例，例如，清单文件66。客户端设备40可以获取媒体呈现的mpd，以确定如何访问各种呈现的电影片段。电影片段可以位于视频文件的电影片段盒子(电影片段盒子)当中。

清单文件66(可以包括，例如mpd)可以通知表示68的片段的可用性。也就是说，mpd可以包括指示表示68中的一个表示的第一片段变得可用的挂钟时间的信息，以及指示表示68内的片段的持续时长的信息。通过这种方式，客户端设备40的获取单元52可以基于起始时间确定每一片段何时可用以及在特定片段之前的片段的持续时间。

在封装单元30基于接收到的数据将nal单元和/或访问单元组装成视频文件之后，封装单元30将视频文件传输至输出接口32以供输出。在一些示例中，封装单元30可以对视频文件进行本地存储，或者将视频文件经由输出接口32发送至远程服务器，而不是直接将视频文件发送至客户端设备40。输出接口32可以包括，例如发射机、收发机、用于向计算机可读介质写入数据的设备，例如，光驱动器、磁介质驱动器(例如，软驱)、通用串行总线(usb)端口、网络接口或者其它输出接口。输出接口32将视频文件输出至计算机可读介质，例如，传输信号、磁介质、光学介质、存储器、闪速驱动器或者其它计算机可读介质。

网络接口54可以经由网络74接收nal单元或访问单元，并将nal单元或访问单元经由获取单元52提供给解封装单元50。解封装单元50可以将视频文件的元解封装成构成pes流，对pes流去分组化，以获取编码数据，并将编码数据发送至音频解码器46或视频解码器48，取决于编码数据是音频流的一部分还是视频流的一部分，例如，如流的pes分组报头所指示的。音频解码器46对编码的音频数据解码，并将解码的音频数据发送至音频输出42，而视频解码器48则对编码的视频数据解码，并将可以包括流的多个视图的解码的视频数据发送至视频输出44。

图2是更详细地示出了图1的获取单元52的示例性组件集合的方块图。在这一示例中，获取单元52包括ota中间件单元100、dash客户端110和媒体应用112。

在这一示例中，ota中间件单元100还包括ota接收单元106、高速缓存104和代理服务器102。在这一示例中，ota接收单元106被配置为经由ota接收数据，例如，根据通过单向传输的文件传送(flute)。也就是说，ota接收单元106可以经由广播接收来自，例如服务器设备60的文件，该服务器设备60可以充当bm-sc。

随着ota中间件单元100接收针对文件的数据，ota中间件单元可以将接收到的数据存储到高速缓存104。高速缓存104可以包括计算机可读存储介质，例如，闪速存储器、硬盘、ram或者任何其它适当存储介质。

代理服务器102可以充当针对dash客户端110的代理服务器。例如，代理服务器102可以向dash客户端110提供mpd文件或其它清单文件。代理服务器102可以在mpd文件中通知针对分段的可用性时间以及能够从中获取分段的超级链接。这些超级链接可以包括对应于客户端设备40的本地主机地址前缀(例如，对于ipv4的127.0.0.1)。通过这种方式，dash客户端110可以使用httpget或局部get请求来自代理服务器102的分段。例如，对于可从链接http:∥127.0.0.1/rep1/seg3获得的分段而言，dash客户端110可以构造包括对http:∥127.0.0.1/rep1/seg3的请求的httpget请求并将该请求提交给代理服务器102。代理服务器102可以从高速缓存104获取所请求的数据，并响应于这样的请求将数据提供给dash客户端110。

在一些示例中，代理服务器102在将针对新信道的mpd发送给dash客户端110之前(或者在不进行发送的情况下)，将新信道的媒体数据事件(mde)推送至dash客户端110。因而，在这样的示例中，代理服务器102可以将新信道的媒体数据发送给dash客户端110而不实际接收来自dash客户端110的针对媒体数据的请求。代理服务器102和dash客户端110可以被配置为执行websocket子协议，从而实现这样的媒体数据推送。

一般而言，websocket允许子协议的定义。例如，rfc7395针对websocket定义了可扩展消息及出席协议(xmpp)子协议。本公开内容的技术可以按照类似的方式使用websocket子协议。具体而言，代理服务器102和dash客户端110可以在http握手期间，对websocket子协议进行协商。用于子协议的数据可以在这一http握手期间，包括在sec-websocket-协议报头当中。在一些示例中，能够避免子协议协商，例如，如果在先验已知websocket的两端都使用共同的子协议。

此外，子协议的定义可以保持http1.1/xhr语义的子集。例如，子协议可以包括基于文本的geturl消息的使用。其它方法，例如，push、put和post在子协议中不是必需的。http错误代码也是不必要的，因为websocket错误消息是足够的。但是，在一些示例中，可以将其它方法(例如，push、put和post以及/或者http错误代码)包括在子协议中。

一般而言，子协议可以通过websocket传播mde事件。这样可以允许利用对调谐器事件的直接访问。子协议可以包括客户端到服务器的消息传输，例如，具有指定url的基于文本的消息的形式。服务器(例如，代理服务器102)可以对来自客户端(例如，dash客户端110)的输入文本进行分析。作为响应，代理服务器102可以提供分段作为返还。代理服务器102可以将这样的消息解释为httpget消息。

子协议的服务器到客户端消息传输可以包括基于文本的消息以及基于二元的消息两者。基于文本的消息可以包括“startsegment”和/或“endsegment”，以指示针对分段的数据已经开始或结束。在一些示例中，例如在响应于get或信道改变仅传送分段时，“endsegment”可能足以用于同步传送。在一些示例中，消息还可以包括用于对应的分段的url(例如，具有“end[url]”的形式)。

从代理服务器102到dash客户端110的基于文本的消息还可以包括“channelchange”，以指示已经发生了信道改变，并且新的分段即将来到。“channelchange”消息可以包括用于新分段的分段url，因为dash客户端110可能尚未取得针对新信道的mpd。在一些示例中，基于文本的消息可以包括“mpd”，以指示mpd正在传送给dash客户端110。代理服务器102可以在带内将mpd推送给dash客户端110(也就是说，与对应于mpd的媒体数据一起)，或者dash客户端110可以对mpd进行带外获取。如果在带外获取，那么代理服务器102可以将指示该mpd的url的带内mpdurl消息提供给dash客户端110。

从代理服务器102到dash客户端110的二进制消息可以包括媒体有效载荷。例如，媒体有效载荷可以包括完整分段或mde。如果传送了mde，那么代理服务器102可以被配置为确保mde依次传送给dash客户端110。

图3是示出示例性多媒体内容120的要素的示意图。多媒体内容120可以对应于多媒体内容64(图1)或者存储在存储介质62中的另一多媒体内容。在图3的示例中，多媒体内容120包括媒体呈现描述(mpd)122以及多个表示124a–124n(表示124)。表示124a包括任选的报头数据126和分段128a-128n(分段128)，而表示124n则包括任选的报头数据130和分段132a-132n(分段132)。为方便起见，使用字母n指示表示124中的每一个表示中的最后的电影片段。在一些示例中，在表示124之间可能存在不同数量的电影片段。

mpd122可以包括与表示124a-124n分开的数据结构。mpd122可以对应于图1的清单文件66。类似地，表示124a-124n可以对应于图1的表示68。一般而言，mpd122可以包括对表示124a-124n的特性做出一般描述的数据，对表示124a-124n的特性做出一般描述例如是，编码和渲染特性、适应集、mpd122对应的概况、文本类型信息、摄像机角度信息、评分信息、技巧模式信息(例如，指示包括时间子序列的表示的信息)和/或用于获取远时段的信息(例如，用于重放期间向媒体内容插入针对性广告)。

在存在时，报头数据126可以描述分段128的特性，例如，随机访问点(rap，又称为流访问点(sap)的时间位置、分段128中的哪些分段包括随机访问点、相对于分段128内的随机访问点的字节偏移量、分段128的统一资源定位符(url)或者分段128的其它方面。在存在时，报头数据130可以描述针对分段132的类似特性。额外地或者替代地，这样的特性可以完全包括在mpd122内。

分段128、132包括一个或多个编码视频样本，这些分段中的每个分段可以包括视频数据的帧或切片。分段128的编码视频样本中的每个样本可以具有类似的特性，例如，高度、宽度和带宽要求。这样的特性可以通过mpd122的数据描述，虽然在图3的示例中并未示出这样的数据。mpd122可以包括如由3gpp规约描述的特性，外加本公开内容中描述的任何或者所有信号指示的信息。

分段128、132中的每一个分段可以与唯一统一资源定位符(url)相关联。因而，分段128、132中的每一个分段可以是使用诸如dash的流媒体网络协议而独立获取的。通过这种方式，目的地设备，例如，客户端设备40可以使用httpget请求获取分段128或132。在一些示例中，客户端设备40可以使用http局部get请求获取分段128或132的具体字节范围。

图4是示出可以对应于诸如图3的分段128、132中的一个分段的表示的分段的示例性视频文件150的要素的方块图。分段128、132中的每一个分段可以包括基本符合图4的示例中所示的数据的布置的数据。可以说视频文件150封装分段。如上所述，根据iso基础媒体文件格式及其扩展的视频文件将数据存储到一系列称为“盒子”的对象当中。在图4的示例中，视频文件150包括文件类型(ftyp)盒子152，电影(moov)盒子154、分段索引(sidx)盒子162、电影片段(moof)盒子164以及电影片段随机访问(mfra)盒子166。尽管图4表示了视频文件的示例，但是应当理解，其它媒体文件可以包括根据iso基础媒体文件格式及其扩展的按照与视频文件150的数据类似的方式结构化的其它类型的媒体数据(例如，音频数据或者定时文本数据等)。

文件类型(ftyp)盒子152对视频文件150的文件类型做出一般描述。文件类型盒子152可以包括识别描述视频文件150的最佳使用的规约的数据。或者，文件类型盒子152可以替代地置于moov盒子154、电影片段盒子164和/或mfra盒子166之前。

在一些示例中，诸如视频文件150的分段可以包括处于ftyp盒子152之前的mpd更新盒子(未示出)。mpd更新盒子可以包括指示对应于包括视频文件150的表示的mpd将更新的信息，连同用于更新mpd的信息。例如，mpd更新盒子可以提供针对将使用的资源的uri或url，以更新mpd。作为另一示例，mpd更新盒子可以包括用于更新mpd的数据。在一些示例中，mpd更新盒子可以立即跟在视频文件150的分段类型(styp)盒子(未示出)的后面，其中，styp盒子可以定义针对视频文件150的分段类型。

图4的示例中的moov盒子154包括电影报头(mvhd)盒子156、轨迹(trak)盒子158以及一个或多个电影延续(mvex)盒子160。一般而言，mvhd盒子156可以描述视频文件150的一般特性。例如，mvhd盒子156可以包括描述以下内容的数据：视频文件150最初何时创建、视频文件150何时最后一次修改、针对视频文件150的时标、针对视频文件150的重放的持续时间，或者其它对视频文件150做出一般描述的数据。

trak盒子158可以包括用于视频文件150的轨迹的数据。trak盒子158可以包括描述对应于trak盒子158的轨迹的特性的轨迹报头(tkhd)盒子。在一些示例中，trak盒子158可以包括编码视频图像，而在其它示例中，轨迹的编码视频图像可以包括在电影片段164当中，该电影片段164可以通过trak盒子158和/或sidx盒子162的数据进行指引。

在一些示例中，视频文件150可以包括多于一个的轨迹。相应地，moov盒子154可以包括多个trak盒子，trak盒子的数量与视频文件150内的轨迹的数量相等。trak盒子158可以描述视频文件150的对应轨迹的特性。例如，trak盒子158可以描述针对对应轨迹的时间和/或空间信息。当封装单元30(图3)将参数集轨迹包括在诸如视频文件150的视频文件中时，与moov盒子154的trak盒子158类似的trak盒子可以描述参数集轨迹的特性。封装单元30可以在描述参数集轨迹的trak盒子内以信号指示参数集轨迹中的序列级sei消息的存在性。

mvex盒子160可以描述对应电影片段164的特性，从而例如以信号指示视频文件150除了moov盒子154内包括的视频数据(如果有的话)之外，还包括电影片段164。在对视频数据进行流传输的语境下，编码视频图像可以包括在电影片段164中而不是moov盒子154中。相应地，所有的编码视频样本均可以包括在电影片段164中，而不是moov盒子154中。

moov盒子154可以包括多个mvex盒子160，mvex盒子160的数量等于视频文件150内的电影片段164的数量。mvex盒子160中的每个mvex盒子可以描述电影片段164中的对应的一个电影片段的特性。例如，每一mvex盒子可以包括描述电影片段164中的对应的一个电影片段的时间持续长度的电影延续报头盒子(mehd)盒子。

如上文指出的，封装单元30可以将序列数据集存储在不包括实际编码视频数据的视频样本当中。视频样本一般可以对应于访问单元，该视频样本是具体时间实例上的编码图像的表示。在avc的语境下，编码图像包括一个或多个包含构建访问单元的所有像素的信息的vclnal单元以及其它相关联的非vclnal单元，例如，sei消息。相应地，封装单元30可以包括处于电影片段164中的一个电影片段中的可以包括序列级sei消息的序列数据集。封装单元30还可以以信号指示序列数据集的存在，和/或以信号将序列级sei消息指示为：在对应于电影片段164中的一个电影片段的mvex盒子160中的一个mvex盒子内的电影片段164中的一个电影片段中存在。

sidx盒子162是视频文件150的任选元素。也就是说，符合3gpp文件格式或者其它此类文件格式的视频文件不一定包括sidx盒子162。根据3gpp文件格式的示例，sidx盒子可以用于识别分段(例如，视频文件150内包含的分段)的子分段。3gpp文件格式将子分段定义为“一个或多个具有对应的媒体数据盒子的连续电影片段盒子自包含集合，必须跟随在该电影片段盒子之后，并且在包含关于同一轨迹的信息的下一电影片段盒子之前，其中该媒体数据盒子包含通过电影片段盒子指引的数据”。3gpp文件格式还指示sidx盒子“包含对由该盒子归档的(子)分段的子分段的指引的序列。所指引的子分段在呈现时间内是连续的。类似地，由分段索引盒子所指引的字节在该分段内总是连续的。所指引的大小给出了所指引的资料当中的字节数量的计数。”

sidx盒子162一般提供表示视频文件150内包括的分段的一个或多个子分段的信息。例如，这样的信息可以包括子分段开始和/或结束的重放时间、针对子分段的字节偏移、子分段是否包括(例如，开始于)流访问点(sap)、对于sap的类型(例如，sap是瞬时解码器刷新(idr)图像、清除随机访问(cra)图像、打断链接访问(bla)图像或是其它种类的图像)、sap(就重放时间和/或字节偏移量而言)在子分段当中的位置等等。

电影片段164可以包括一个或多个编码视频图像。在一些示例中，电影片段164可以包括一个或多个图像群组(gop)，该群组中的每一个群组可以包括多个编码视频图像，例如，帧或图像。此外，如上所述，电影片段164在一些示例中可以包括序列数据集。电影片段164中的每一个电影片段可以包括电影片段报头盒子(mfhd，图4中未示出)。mfhd盒子可以描述对应的电影片段的特性，例如，针对电影片段的序列号。电影片段164可以按照序列号的顺序包括在视频文件150当中。

mfra盒子166可以描述视频文件150的电影片段164内的随机访问点。这样可以有助于执行技巧模式，例如，执行对由视频文件150封装的分段内的特定时间位置(即，重放时间)的查找。在一些示例中，mfra盒子166一般是任选的，并且不需要包括在视频文件内。同样地，诸如客户端设备40的客户端设备不必需要指引mfra盒子166正确地对视频文件150的视频数据进行解码和显示。mfra盒子166可以包括多个轨迹片段随机访问(tfra)盒子(未示出)，轨迹片段随机访问(tfra)盒子的数量等于视频文件150的轨迹的数量，或者在一些示例中，轨迹片段随机访问(tfra)盒子的数量等于视频文件150的媒体轨迹(非暗示轨迹)的数量。

在一些示例中，电影片段164可以包括一个或多个流访问点(sap)，例如，idr图像。同样地，mfra盒子166可以提供sap的视频文件150内的位置的指示。相应地，视频文件150的时间子序列可以从视频文件150的sap形成。时间子序列还可以包括其它图像，例如，取决于sap的p帧和/或b帧。时间子序列的帧和/或切片可以布置到分段内，使得时间子序列的依赖于该子序列的其它帧/切片的帧/切片能够正确解码。例如，在数据的分级布置当中，用于预测其它数据的数据也可以包括到时间子序列当中。

图5是示出可以执行本公开内容的技术的示例性系统200的方块图。图5的系统包括遥控器202、信道选择器204、route处理器206、dash客户端208、解码器210、http/ws代理服务器214、存储广播组成部分218的数据存储设备216、宽带组件220以及一个或多个呈现设备212。广播组成部分218可以包括，例如清单文件(例如，媒体呈现描述(mpd))以及媒体数据或媒体传送事件(mde)数据。

图5的要素可以大致对应于客户端设备40的要素(图1)。例如，信道选择器204和宽带组件220可以对应于网络接口54(或者ota接收单元，图1中未示出)，route处理器206、dash客户端208、代理服务器214和数据存储设备216可以对应于获取单元52，解码器210可以对应于音频解码器46和视频解码器48中的任一者或两者，并且呈现设备212可以对应于音频输出42和视频输出44。

一般而言，代理服务器214可以向dash客户端208提供清单文件，例如，mpd。但是，即使不向dash客户端208传送mpd，代理服务器214也可以向dash客户端208推送信道(例如，遵循信道改变事件的新信道)的媒体数据的mde。具体而言，用户可以通过访问遥控器202，请求信道改变事件，该遥控器202向信道选择器204发送信道改变指令。

信道选择器204可以包括，例如空中(ota)信道调谐器、有线机顶盒或者卫星机顶盒等。一般而言，信道选择器204被配置为确定针对经由接收自遥控器202的信号选择的信道的服务标识符(服务id)。信道选择器204还确定针对对应于服务id的服务的传输会话标识符(tsi)。信道选择器204将tsi提供给route处理器206。

route处理器206被配置为根据route协议操作。例如，route处理器206响应于从信道选择器204接收tsi而加入对应的route会话。route处理器206确定针对route会话的分层编码传输(lct)会话，通过该会话接收用于route会话的媒体数据和清单文件。route处理器206还获得针对lct的lct会话实例描述(lsid)。route处理器206从route传送的数据提取媒体数据，并将数据高速缓存至广播组成部分218。

相应地，代理服务器214能够从广播组成部分218获取媒体数据，以供接下来传送给dash客户端208。具体而言，在执行http时，代理服务器214响应于针对媒体数据的具体请求，而将这样的媒体数据(及清单文件)提供给dash客户端208。但是，在执行websocket时，代理服务器214能够将媒体数据(例如，经由宽带组件220接收到的或者从广播组成部分218获取的)“推送”给dash客户端208。也就是说，代理服务器214能够在不接收来自dash客户端208的针对媒体数据的各个请求的情况下，在媒体数据准备好传送之后，传送媒体数据。

dash客户端208仍然能够直接接收来自本地调谐器(即，信道选择器204)的信道改变事件，但是可能无法以及时的方式对其做出动作。因而，通过将新信道的媒体数据的mde推送至dash客户端208，即使没有清单文件，dash客户端208也能够从mde提取可用媒体数据。

dash客户端208和代理服务器214各可以通过硬件或者软件和/或固件与硬件的组合来实现。也就是说，在提供用于dash客户端208或者代理服务器214的软件和/或固件指令时，应当理解，还提供必必要的硬件(例如，存储指令的存储器以及执行指令的一个或多个处理单元)。处理单元可以单独地或者以任何组合的方式包括一个或多个处理器，例如，一个或多个数字信号处理器(dsp)、通用微处理器、专用集成电路(asic)、现场可编程逻辑阵列(fpga)或者其它等价集成或分立逻辑电路。一般而言，“处理单元”应当理解为指代基于硬件的单元，即，包括某种形式的电路的单元，该电路可以包括固定功能的电路和/或可编程电路。

通过这种方式，系统200表示用于传输媒体数据的设备的示例，设备包括被配置为存储媒体数据的存储器，以及被配置为执行用于包括流媒体客户端的客户端设备的代理服务器的一个或多个处理器。代理服务器被配置为确定针对客户端设备的调谐信道已经从先前信道改变为当前信道，并且响应于确定，在未从流媒体客户端接收到针对媒体数据的请求的情况下，根据websocket子协议将当前信道的媒体数据传送给客户端设备的流媒体客户端。

图6是示出图5的系统200的组件之间的示例性通信交换的流程图。尽管参照图5的系统200的组件做出了解释，但是图5的技术也可以由其它设备和系统执行，其它设备和系统例如是，图1的客户端设备40以及图2的获取单元52。具体而言，图6的示例性流程图是参照信道选择器204、代理服务器214和dash客户端208描述的。

在图6的示例中，dash客户端208(在图6中标为“html/js/浏览器广播websocket客户端”)将分段的url发送至代理服务器214(在图6中标为“本地http代理”)(url(ws))(230)。也就是说，如上文解释的，dash客户端208可以使用websocket将基于文本的消息发送至代理服务器214，其中，消息指定分段的url。url可以包括“ws:∥”前缀或者“wss:∥”前缀。作为响应，代理服务器214使用websocket将具有分段形式的媒体数据以及指示分段末尾的基于文本的消息(媒体(ws))(234)发送至dash客户端208(232)。

在这一系列的通信之后，信道选择器204指示信道已经改变(236)(例如，在接收来自遥控器202的信号之后，图6中未示出)。作为响应，在这一示例中，代理服务器214经由websocket向dash客户端208发送指示信道已经改变的基于文本的消息以及新信道的url(238)。此外，代理服务器214将包括新信道的媒体数据的一个或多个媒体数据事件(mde)传送至dash客户端208(240a-240n)。如图6中所示，mde的传送发生在针对新信道的mpd传送至dash客户端(244)之前。但是，在一些示例中，代理服务器214可以从不实际向dash客户端传送mpd。此外，在mpd的传送之后，如果mpd事实上如图所示受到传送，那么代理服务器214可以继续向dash客户端208传送mde。

在经由websocket向dash客户端208传送分段的mde之后，代理服务器214传送指示分段的末尾的基于文本的消息(242)。尽管在图6中仅示出了单个分段，但是应当理解，这一过程可以针对多个分段重复发生。也就是说，代理服务器214可以传送针对多个分段的mde，随后继之以指示分段已经结束的“结束分段”消息或类似消息(例如，类似的基于文本的消息)。在图6的示例中，mde的传送(242)和分段末尾的传送(242)发生在针对新信道的mpd传送至dash客户端(244)之前。

尽管图6未示出，但是在传送分段的数据之后，dash客户端208可以从分段提取媒体数据并将所提取的媒体数据传送至对应的解码器以供呈现。参照图5，例如，dash客户端208可以将所提取的媒体数据传送至解码器210。解码器210接着可以对媒体数据解码，并将解码的媒体数据传送至呈现设备212以供呈现。

通过这种方式，图6的方法表示一种传输媒体数据的方法的示例，该方法包括由用于包括流媒体客户端的客户端设备的代理服务器确定针对客户端设备的调谐信道已经从先前信道改变为当前信道，以及并且响应于确定，在未从流媒体客户端接收到针对媒体数据的请求的情况下，根据websocket子协议将当前信道的媒体数据传送给客户端设备的流媒体客户端。

在一个或多个示例中，所描述的功能可以通过硬件、软件、固件或其任何组合实现。如果通过软件实现，那么功能可以作为一个或多个指令或代码存储在计算机可读介质上或者通过计算机可读介质传输，并由基于硬件的处理单元执行。计算机可读介质可以包括：对应于诸如数据存储介质的有形介质的计算机可读存储介质或者包括促进计算机程序例如根据通信协议从一地到另一地的传输的任何介质的通信介质。通过这种方式，计算机可读介质一般可以对应于(1)非临时性的有形计算机可读存储介质或者(2)诸如信号或载波波形的通信介质。数据存储介质可以是能够由一个或多个计算机或者一个或多个处理器存取以获取用于本公开内容中描述的技术的实施方式的指令、代码和/或数据结构的任何可用介质。计算机程序产品可以包括计算机可读介质。

作为示例而非限制，这样的计算机可读存储介质能够包括ram、rom、eeprom、cd-rom或其它光盘存储器、磁盘存储器或其它磁存储设备、闪速存储器或任何其它能够用于存储具有指令或数据结构的形式的预期程序代码并且能够由计算机存取的介质。而且，任何连接也可以适当地称为计算机可读介质。例如，如果指令是使用同轴电缆、光纤光缆、双绞线、数字用户线(dsl)或者诸如红外线、无线电和微波的无线技术从网站、服务器或者其它远程源发送的，那么同轴电缆、光纤光缆、双绞线、dsl或者诸如红外线、无线电和微波的无线技术包括在介质的定义当中。但是，应当理解，计算机可读存储介质和数据存储介质不包括连接、载波波形、信号或者其它暂时性介质，而是指非临时性的有形存储介质。如本文所使用的，磁盘和光盘包括压缩光盘(cd)、激光光盘、光盘、数字多功能光盘(dvd)、软盘和蓝光光盘，其中磁盘通常以磁性方式再现数据，而光盘利用激光以光学方式再现数据。以上的组合也应当包括在计算机可读介质的范围之内。

指令可以由一个或多个处理器执行，处理器例如是，一个或多个数字信号处理器(dsp)、通用微处理器、专用集成电路(asic)、现场可编程逻辑阵列(fpga)或者其它等价集成或分立逻辑电路。相应地，本文使用的“处理器”一词可以指上述结构中的任何结构或者适于本文描述的技术的实施方式的任何其它结构。此外，在一些方面中，本文描述的功能可以是在被配置为进行编码和解码的或者被并入到合并编解码器中的专用硬件和/或软件模块内提供的。而且，技术能够完全在一个或多个电路或逻辑元件当中实现。

本公开内容的技术可以是在包括无线手机、集成电路(ic)或者ic集合(例如，芯片集合)的各种各样的设备或装置中实现的。在本公开内容当中描述了各种组件、模块或单元，以强调被配置为执行所公开的技术的设备的功能方面，但是不必要求由不同的硬件单元实现这些组件、模块或单元。相反，如上所述，各种单元可以合并到编解码器硬件单元当中或者由包括如上文所述的一个或多个处理器的互操作硬件单元的集合连同适当的软件和/或固件提供。

已经描述了各种示例。这些以及其它示例处于下述权利要求的范围内。