CN102232298B

CN102232298B - 媒体内容的传输处理方法、装置与系统

Info

Publication number: CN102232298B
Application number: CN201180000434.6A
Authority: CN
Inventors: 袁卫忠; 石腾; 乐培玉; 张仁宙; 吴凌燕
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2011-04-07
Filing date: 2011-04-07
Publication date: 2013-10-09
Anticipated expiration: 2031-04-07
Also published as: WO2011100901A3; EP2685742A2; US20140032777A1; EP2685742A4; CN102232298A; WO2011100901A2

Abstract

一种媒体内容的传输处理方法、装置与系统，所述方法包括：对至少一个媒体采样及其元数据进行封装，生成子媒体分片，多个所述子媒体分片构成一个媒体分片；每生成一个子媒体分片，则将所述一个子媒体分片推送给直播服务器，使得所述直播服务器在接收到所述一个子媒体分片后，将所述一个子媒体分片推送给客户端播放。采用本发明实施例的方案可以降低端到端时延，提高媒体内容处理的实时性。

Description

媒体内容的传输处理方法、装置与系统

技术领域

本发明涉及通信技术领域，尤其涉及一种媒体内容的传输处理方法、装置与系统。

背景技术

用户使用终端设备获取媒体内容并进行播放的方式有多种，典型的有：HTTP(Hypertext Transfer Protocol，超文本传输协议)文件下载或者P2P(Peerto Peer，点对点)文件下载到本地磁盘后播放、传统的流媒体方式、P2P流媒体方式的在线直播/点播、HTTP渐进式下载(HTTP Progressive Download)以及动态HTTP流传输方案等等。其中，动态HTTP流传输方案作为一种流媒体传输方案，需要考虑其所提供的体验质量(Quality ofend-user Experience，QoE)和服务质量(Quality of Service，QoS)。对于直播场景而言，整体解决方案的端到端时延(end-to-end delay/latency)是非常重要的一个衡量因素，一般定义为从真实世界事件的发生到(第一个采样)在客户端上播放出来之间的时延。

目前动态HTTP流传输方案对于直播业务处理和传输的基本单位是媒体分片(Media Segment)，由于一个媒体分片需包括该媒体分片中相应的媒体采样(sample)数据，因此为了生成一个媒体分片，头端编码器至少需要等待一个媒体分片时长，以便获取相应时长的直播事件数据并编码生成相应的sample。客户端按照其可用带宽选择相应码率的媒体分片，下载并获取到该码率的媒体分片，也需要接近于媒体分片时长的时间。对于动态HTTP流传输方案而言，直播的端到端时延涉及的环节包括：摄像机等设备捕获直播事件数据、编码器输出媒体分片、媒体分片从编码器到服务器以及从服务器到客户端的传输时延、服务器缓冲时延、客户端初始缓冲时延以及客户端解码播放。其中摄像机等设备捕获直播事件数据、编码器编码输出媒体分片和客户端解码播放的时延相对比较固定，并且受所采用的媒体传输方案影响也较小，这样缩短端到端时延的可能环节包括缩短媒体分片时长、缩短服务器缓冲和客户端初始缓冲时长。

但是，由于在MPEG(Moving Picture Experts Group，动态图像专家组)的DASH(Dynamic adaptive streaming over HTTP，基于HTTP的动态适配流)委员会草案(the International Organization for Standardization，国际标准化组织/the International Electrotechnical Commission，国际电工委员会，ISO/IEC CD23001-6)中明确指出每个媒体分片中均需要包括至少一个随机访问点(Random Access Point/Representation Access Point，RAP)，因此缩短媒体分片时长将导致如下问题：

(1)播放同样时长的媒体内容，由于每个媒体分片都需要发出一个请求消息去获取，客户端的请求消息增多，增加了客户端和服务器的处理负担，同时降低了HTTP消息有效负载率(媒体内容数据量占传输数据总量的比例)；

(2)由于每个媒体分片都包含随机访问点，缩短媒体分片会导致相邻两个随机访问点之间的时间间隔缩短，降低了编码效率，增加了网络传输负担。

发明内容

本发明实施例提供了一种媒体内容的传输处理方法、装置与系统，用以降低端到端时延，提高媒体内容传输的实时性。

一方面，本发明实施例提供一种媒体内容的传输处理方法，所述方法包括：对至少一个媒体采样及其元数据进行封装，生成子媒体分片，多个所述子媒体分片构成一个媒体分片；每生成一个子媒体分片，则将所述一个子媒体分片推送给直播服务器，使得所述直播服务器在接收到所述一个子媒体分片后，将所述一个子媒体分片推送给客户端播放。

另一方面，本发明实施例还提供一种媒体内容的传输处理方法，所述方法包括：接收直播编码器推送过来的子媒体分片，所述子媒体分片是构成一个媒体分片的多个子媒体分片的其中之一，每个子媒体分片由至少一个媒体采样及其元数据封装而生成；每接收到一个子媒体分片，则将所述子媒体分片推送给客户端播放。

另一方面，本发明实施例还提供一种媒体内容的传输处理方法，所述方法包括：向直播服务器发送媒体分片请求消息；接收所述直播服务器推送过来的子媒体分片，所述子媒体分片是构成与所述请求消息相对应的媒体分片的多个子媒体分片的其中之一，每个子媒体分片由至少一个媒体采样及其元数据封装而生成；每接收到一个子媒体分片，则播放所述子媒体分片。

又一方面，本发明实施例还提供一种直播编码器，所述直播编码器包括：封装单元，用于对至少一个媒体采样及其元数据进行封装，生成子媒体分片，多个所述子媒体分片构成一个媒体分片；推送单元，用于每生成一个子媒体分片，将所述一个子媒体分片推送给直播服务器，使得所述直播服务器在接收到所述一个子媒体分片后，将所述一个子媒体分片推送给客户端播放。

又一方面，本发明实施例提供一种直播服务器，所述直播服务器包括：接收单元，用于接收直播编码器推送过来的子媒体分片，所述子媒体分片是构成一个媒体分片的多个子媒体分片的其中之一，每个子媒体分片由至少一个媒体采样及其元数据封装而生成；推送单元，用于每接收到一个子媒体分片，将所述子媒体分片推送给客户端播放。

又一方面，本发明实施例还提供一种客户端，所述客户端包括：请求单元，用于向直播服务器发送媒体分片请求消息；接收单元，用于接收所述直播服务器推送过来的子媒体分片，所述子媒体分片是构成与所述请求消息相对应的媒体分片的多个子媒体分片的其中之一，每个子媒体分片由至少一个媒体采样及其元数据封装而生成；播放单元，用于每接收到一个子媒体分片，则播放所述子媒体分片。

再一方面，本发明实施例还提供一种媒体内容的传输处理系统，所述系统包括：直播编码器，用于对至少一个媒体采样及其元数据进行封装，生成子媒体分片，多个所述子媒体分片构成一个媒体分片；每生成一个子媒体分片，则将所述子媒体分片推送给直播服务器；直播服务器，用于接收所述直播编码器推送过来的所述子媒体分片；每接收到一个子媒体分片，则将所述子媒体分片推送给客户端；客户端，用于向所述直播服务器发送媒体分片请求消息；接收所述直播服务器推送过来的所述子媒体分片，所述子媒体分片是构成与所述请求消息相对应的媒体分片的多个子媒体分片的其中之一；每接收到一个子媒体分片，则播放所述子媒体分片。

本发明实施例的技术方案中，在直播编码器一侧生成构成每个媒体分片的多个子媒体分片，这样就不需要等待生成一个媒体分片的时间才推送，而是每生成一个子媒体分片就主动推送给直播服务器，并通过直播服务器推送给客户端播放，该方式提高了媒体内容传输的实时性，可解决端到端时延问题，缩短客户端初始播放、拖动和快速频道切换等操作的时延；在不采用较长时长的服务器缓冲/客户端初始缓冲的情况下，也能够对网络状况的急剧变化做出快速及时的响应和调整。

并且，客户端所请求的基本单元仍然是媒体分片，可保持与原来相同的请求消息数，并不会增加客户端和服务器的处理负担，也不会降低HTTP消息有效负载率；由于并不导致相邻两个随机访问点之间的时间间隔缩短，因此也不会降低编码效率和增加网络传输负担。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1为本发明实施例中媒体内容的传输处理方法的流程图之一；

图2为本发明实施例中媒体分片与子媒体分片的对应关系示意图之一；

图3为本发明实施例中媒体分片与子媒体分片的对应关系示意图之二；

图4为本发明实施例中媒体内容的传输处理方法的流程图之二；

图5为本发明实施例中媒体内容的传输处理方法的流程图之三；

图6为本发明实施例中媒体内容的传输处理方法的具体实例的流程图；

图7为本发明实施例中直播服务器的媒体内容处理过程示意图；

图8为本发明实施例中直播服务器对子媒体分片进行动态裁剪的流程图；

图9为本发明实施例中基于帧优先级丢帧以适应实际网络状况的具体实例的示意图；

图10为本发明实施例中引入内容分发网络后对媒体内容进行处理的过程的示意图；

图11为本发明实施例中直播编码器的结构示意图；

图12为本发明实施例中服务器的结构示意图；

图13为本发明实施例中客户端的结构示意图；

图14为本发明实施例中媒体内容的传输处理系统的架构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚明白，下面结合附图对本发明实施例做进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。

为了解决端到端时延问题，缩短客户端初始播放、拖动和快速频道切换等操作的时延，本发明实施例提供一种媒体内容的传输处理方法，该方法生成与媒体分片对应的一系列子媒体分片、并采用实时主动推送子媒体分片的方式，提高了传输媒体内容的实时性。本发明实施例的媒体内容传输处理方法在不采用较长时长的服务器缓冲和客户端初始缓冲的情况下，也能够对网络状况的急剧变化做出快速及时的响应和调整。

如图1所示，本发明实施例中媒体内容的处理方法流程可以包括：

步骤101、对至少一个媒体采样及其元数据进行封装，生成子媒体分片，多个所述子媒体分片构成一个媒体分片；

步骤102、每生成一个子媒体分片，则将所述子媒体分片推送给直播服务器，使得所述直播服务器在接收到所述一个子媒体分片后，将所述一个子媒体分片推送给客户端播放。

图1所示流程可由能够实现其功能的装置进行实施，例如该装置可以是直播编码器等。本发明实施例中将以直播编码器为例进行说明。

具体实施时，生成子媒体分片时可以以媒体采样(sample)作为最小单位，最少可只包括一个sample，或者几个时间上连续的sample，如视频按MPEG规范编码得到的PBB/BBP或者PBBPBB/BBPBBP(具体每两个P帧之间包括几个B帧可取决于直播编码器的编码设置)。这里，对不同视频帧的简介如下：

I帧(intra coded picture，帧内编码帧)：解码时仅用I帧的数据就可重构完整图像，一般可作为随机访问点。由于I帧是一个全帧压缩编码帧，所以I帧所占数据的信息量比较大；

P帧(predictive coded picture，前向预测编码帧)：P帧只参考前面最靠近它的I帧或P帧，由于是差值传送，P帧的压缩比较高；

B帧(bidirectionally predictive coded picture，双向预测内插编码帧)：由前面的I/P帧和后面的P帧来进行预测的，传送的是它与前面的I/P帧和后面的P帧之间的预测误差及运动矢量，因此压缩比最高；

一般平均来说，I帧的压缩率是7，P帧是20，B帧可以达到50；即P帧数据量平均达到I帧的1/3左右，B帧数据量平均达到I帧的1/7左右。

从上述简介可见，虽然使用I帧可以增加随机访问点，但由于其压缩率相对最低，所占数据比较多，因此无法对所有视频帧都采用I帧或I/P帧。故GOP一般仅基础帧(或第一帧)采用I帧，在一个GOP中只有一个I帧，后续则为P帧以及每相邻两个P帧之间的N(N≥0)个B帧，常见帧序列如“IBBPBBP......”，但其传输和解码的顺序却可能是“IPBBPBB......”。

具体实施时，生成构成每个媒体分片的多个子媒体分片，是按子媒体分片的格式对媒体内容的至少一个媒体采样及其元数据进行封装而生成的。对原sample的编码生成并无任何改动，仅对sample及其元数据的封装有所变化(直播编码器无需首先生成原格式的媒体分片才能开始拆分生成子媒体分片，而是对编码产生的一个或几个sample直接按照子媒体分片的格式要求进行封装)。这样的多个子媒体分片，在逻辑意义上完全等同于原先的一个媒体分片，也即本发明所称的构成一个媒体分片。

生成的媒体分片对应的第一个子媒体分片可以包括媒体分片级的元数据；例如，只在第一个子媒体分片中包括媒体分片级的元数据，后续子媒体分片中则无需包括媒体分片级的元数据。

包括随机访问点对应媒体采样的子媒体分片中包括随机访问点；并不要求每个子媒体分片都包括随机访问点。

具体的，可以根据设定的目标时长或目标媒体采样数量，生成构成每个媒体分片的多个子媒体分片。例如，在生成子媒体分片时考虑生成的子媒体分片的目标时长并结合视频流的帧率：设定子媒体分片的目标时长为0.2秒，那么在帧率为29.97帧/秒或30帧/秒时，每个子媒体分片包括6个连续的视频帧，帧率为25帧时，每个子媒体分片包括5个连续的视频帧。这里目标时长也可以是其它值，例如以时间为度量单位的0.1秒、0.3秒或0.5秒等，或者考虑目标媒体采样数量，即以帧数为度量单位的连续的几个视频帧，如3帧、6帧或9帧等。

实施时不要求同一个媒体分片对应的各个子媒体分片在时长上完全相同，彼此允许存在细微的差别，且最后一个子媒体分片时长甚至可与其它子媒体分片时长存在较大不同。如果音频内容和视频内容需包括在不同的子媒体分片中，则生成的包括音频内容的子媒体分片与包括视频内容的子媒体分片的目标时长或目标媒体采样数量也可以不相同。

在生成子媒体分片时也可结合考虑传输层状况，例如由于HTTP底层采用TCP/IP传输协议，可同时结合考虑TCP的最大分节大小(Maximum SegmentSize，MSS)。

为了更清楚说明本发明实施例的具体实施，下面对所涉及的ISO基媒体文件格式(ISO/IEC 14496-12规范)中相关部分简要说明如下：

a)ISO基媒体文件格式以File Type Box(‘ftyp’)来标识文件类型，以MovieBox(‘moov’)来封装描述整个媒体展现的元数据，而Media Data Box(‘mdat’)用于包括相应的媒体数据(即实际的音频/视频等sample的内容)；

b)如果文件内包括了媒体片段(Movie Fragment)，需要在‘moov’Box中包括Movie Extends Box(‘mvex’)以指示文件阅读器(reader)；

c)对于媒体片段，用‘moof’Box来封装该媒体片段相应的元数据，而媒体片段相应的媒体采样仍然用‘mdat’Box来封装。这里在一个文件中可以使用多个‘mdat’Box，每个媒体片段都可在其‘moof’Box后紧跟相应的‘mdat’Box，即每个媒体片段均按照‘moof’+‘mdat’的格式依次存储在文件内。

d)对‘moof’Box所包括的一些重要信息简单介绍如下：

Track Fragment Run Box(‘trun’)：

用tr_flags相关比特位指示是否包括data_offset、first_sample_flags，以及对于每个sample包括哪些描述信息的指示；

所描述sample的数目(sample_count)；

根据tr_flags指示可能出现的data_offset、first_sample_flags；

描述sample的元数据：根据tr_flags指示所包括的sample_duration、sample_size、sample_flags、sample_composition_time_offset其中之一或其任意组合，该元数据数组共有sample_count个成员(即每个sample在数组中都有一个与其直接对应的元数据描述信息成员)；

Independent and Disposable Samples Box(‘sdtp’)：提供sample之间的解码依赖性信息，同样对每个sample都有一个与其直接对应的元数据描述信息。其所起的作用与‘trun’Box中sample_flags类似，即如果在‘trun’Box中已经为每个sample提供了sample_flags信息，则无需再使用‘sdtp’Box；

Track Fragment Header Box(‘tfhd’)：给出所描述轨(Track)的标识(track_ID)，且可包括各sample默认的duration、size、flags值；

‘moof’Box中所包括的其他Box均不再与具体的sample直接相关。

下面对3GPP(3rd Generation Partnership Project，第三代合作伙伴计划)/MPEG的动态HTTP流传输规范中与文件格式相关部分也简要说明如下：

a)对于动态HTTP流传输方案，共有三类不同的分片：可以把与客户端媒体解码器初始化相关的信息(即‘moov’Box)放在专门的初始化分片(Initialisation Segment)内。这样对一组媒体分片(Media Segment)而言无需重复包含相同的初始化信息，但在播放这组媒体分片之前必须首先获取相应的初始化分片。由于这种媒体分片中不再包括‘moov’Box，因此与原来的3GPP文件格式不兼容，为使客户端能正确识别出这种新的文件格式，3GPP/MPEG特意扩展了一个相应的分片类型Segment type Box(‘styp’)。最后还有一类包括了初始化信息的媒体分片，被称作为自初始化媒体分片(Self-Initialising Media Segment)；

b)在一个媒体分片中，可以包括一个或多个完整的自包含(self-contained)的媒体片段。完整的自包含媒体片段定义为：一个‘moof’Box后紧跟着一个‘mdat’Box，在‘mdat’Box中包括了对应‘moof’中‘trun’Box所引用的所有媒体sample；

c)在3GPP/MPEG中，在第一个‘moof’Box之前还可能包括一些媒体分片级的元数据如类型信息‘styp’或‘ftyp’及‘moov’，以及索引信息Segment IndexBox(‘sidx’)，和/或Sender Reference Time Box(‘srft’)。在‘moof’Box中，可能包括一些媒体片段级的元数据如Track Fragment Adjustment Box(‘tfad’)和Track fragment decode time Box(‘tfdt’)。

对于一个包括了2秒时长的GOP(Group of Pictures，图像组)共60帧的媒体分片，下面以符合MPEG的DASH委员会草案(ISO/IEC CD 23001-6)为例，说明产生构成一个媒体分片的一系列目标时长为0.2秒的子媒体分片的具体实例，图2为本例中生成媒体分片对应的子媒体分片的示意图。

本例中，原来应生成的媒体分片中需包括媒体分片级的元数据如‘styp’Box(或‘ftyp’+‘moov’Box，以及可能的‘sidx’/‘srft’Box等)，其‘trun’Box中sample_count值为60，数组中共包括依次描述60个sample的元数据信息(如果包括‘sdtp’Box同样包括描述60个sample解码依赖性的元数据)；

经本例得到媒体分片对应的各个子媒体分片如下：

只有第1个子媒体分片中包括媒体分片级的元数据如‘styp’Box(或‘ftyp’+‘moov’Box，以及可能的‘sidx’/‘srft’Box等)，其‘trun’Box中的sample_count值为6，数组中包括依次描述sample 1～6共6个sample的元数据信息(如果包括‘sdtp’Box同样包括描述前面6个sample解码依赖性的元数据)；

在第2个子媒体分片中，不包括媒体分片级的元数据，直接包括‘moof’+‘mdat’，其‘trun’Box中的sample_count值为6，数组中包括依次描述sample 7～12共6个sample的元数据信息(如果包括‘sdtp’Box同样包括描述7～12共6个sample解码依赖性的元数据)；对于第3～10个子媒体分片的编码与第2个子媒体分片类似；

如果原‘moof’Box中包括媒体片段级的元数据如‘tfad’和/或‘tfdt’Box，则在第一个子媒体分片中的‘moof’Box中仍然需要包括这些元数据信息，但在第2～10个子媒体分片中则不是必须包括，完全可以不包括；

本例中直播编码器不再需要等待编码得到60个sample后才能生成一个媒体分片输出，而是在编码得到最前面6个sample之后即可首先生成第1个子媒体分片并进行推送，在得到第7～12个sample后又可生成第2个子媒体分片并进行推送，一直到生成第10个子媒体分片并进行推送。

上例每个子媒体分片通过‘moof’+‘mdat’Box封装相应的几个连续sample，客户端不用修改即可直接识别并处理。

另一实施例中媒体分片在只包括同一个轨的sample时，可以不使用‘moof’Box，而是直接使用‘trun’Box(及可能的‘sdtp’)来封装与sample相关的元数据，这样可避免重复使用‘moof’Box中所包括的一些Box，但此时需要客户端能识别并支持这种新的封装格式。图3为本例中生成构成媒体分片的多个子媒体分片的另一例的示意图。本例中编码得到各子媒体分片的原理与图2示例基本类似，对本例补充描述如下：

第1个子媒体分片的生成方式与图2示例相同；

在第2个子媒体分片中，直接包括描述sample的元数据‘trun’(以及可能的‘sdtp’)及‘mdat’，其‘trun’Box中的sample_count值为6，数组中包括分别描述sample 7～12共6个sample的元数据信息(如果包括‘sdtp’Box同样包括描述sample 7～12共6个sample解码依赖性的元数据)；对于第3～10个子媒体分片的编码生成与第2个子媒体分片类似。

图2、图3示例只给出符合3GPP/MPEG动态HTTP流传输规范的文件格式而采用的一种子媒体分片的生成方式，对于其他文件格式、实现方案或规范，不用完全按照图2或图3示例来生成子媒体分片，但同样可参照其原理进行处理。例如，对某些实现方案来说，无需在生成的媒体分片的第一个子媒体分片中包括上述媒体分片级的元数据，而是直接输出一个自包含的媒体片段(‘moof’+‘mdat’Box)，除第一个子媒体分片之外的其他子媒体分片封装格式可参考图2或图3示例对子媒体分片的封装方案。图2、图3示例所展示的文件格式为ISO基媒体文件格式，但对于MPEG-2 Transport Stream(TS)文件格式，其拆分原理同样能适用，即把包括了相应几个连续sample的一组TS包(TSPacket)作为一个子媒体分片，从而把原来的每个.ts文件都生成对应的多个子媒体分片(即更小的.ts)。这样的实施例限于篇幅就不再一一枚举。

本发明实施例还提供一种媒体内容的传输处理方法，如图4所示，该方法可以包括：

步骤401、接收直播编码器推送过来的子媒体分片，所述子媒体分片是构成一个媒体分片的多个子媒体分片的其中之一，每个子媒体分片由至少一个媒体采样及其元数据封装而生成；

步骤402、每接收到一个子媒体分片，则将所述子媒体分片推送给客户端播放。

可选地，在将所述子媒体分片推送给客户端播放之前，所述方法还包括：根据网络传输状况，对接收到的子媒体分片进行动态裁剪；或者对所述子媒体分片的推送速率进行动态控制。

可选地，所述动态裁剪包括：基于帧优先级的丢帧处理；和/或，对于采用包括子采样结构的媒体采样，结合其优先级及是否可丢弃指示信息，对子采样进行裁剪处理；和/或，在采用H.264编码时，基于网络抽象层NAL重要性指示信息对NAL单元进行丢弃处理。

可选地，将所述子媒体分片推送给客户端播放包括：如果客户端在请求消息中指示支持HTTP协议的分块编码传输，则使用分块编码传输方式把所述子媒体分片推送给所述客户端。

可选地，当采用内容分发网络时，将所述子媒体分片推送给客户端播放还包括：通过内容分发网络的边缘服务器，将所述子媒体分片推送给客户端播放。

图4所示流程可由能够实现其功能的装置进行实施，例如该装置可以是直播服务器、内容分发网络的边缘服务器等。本发明实施例中先以直播服务器为例进行说明。

本发明实施例还提供一种媒体内容的传输方法，如图5所示，该方法包括：

步骤501、向直播服务器发送媒体分片请求消息；

步骤502、接收所述直播服务器推送过来的子媒体分片，所述子媒体分片是构成与所述请求消息相对应的媒体分片的多个子媒体分片的其中之一，每个子媒体分片由至少一个媒体采样及其元数据封装而生成；

步骤503、每接收到一个子媒体分片，则播放所述子媒体分片。

图5所示流程可由能够实现其功能的装置进行实施，例如该装置可以是客户端等。本发明实施例中将以客户端为例进行说明。

基于上述实施例可以得知，本发明实施例中，客户端所请求的基本单元仍然是媒体分片，即仍沿用原来的MPD(Media Presentation Description，媒体展现描述)及其更新机制，并可保持与原来相同的HTTP请求消息数。直播编码器无需等到生成完整的媒体分片之后才推送给直播服务器(Live StreamingServer)，而是在编码生成至少一个sample之后就率先生成一个子媒体分片并推送给直播服务器，即生成构成一个媒体分片的多个子媒体分片并分多次推送给直播服务器；直播服务器处理直播编码器所推送过来的子媒体分片，一旦有子媒体分片到达，立即主动实时推送给请求了相应媒体分片的客户端；客户端在请求媒体分片之后，分多次接收直播服务器推送过来的构成媒体分片的各子媒体分片，并在收到一个或几个子媒体分片之后，即可开始进行播放，而无需等到接收完构成媒体分片的全部子媒体分片。

下面举一例说明本发明实施例中的媒体内容的传输处理过程。如图6所示，本例中媒体内容的传输方法流程可以包括：

步骤601、直播编码器向直播服务器提供MPD，或者可用于生成MPD的信息例如媒体类型、码率、编码格式、分辨率、帧率、声道、采样频率、解码需要的特定参数等，还可以包括多个所述子媒体分片构成一个媒体分片的指示信息；

步骤602至步骤603、客户端向直播服务器请求MPD；直播服务器返回与请求相对应的MPD；由于MPD可被更新，步骤602和步骤603根据实际需要可重复多次；

步骤604、客户端根据第i个媒体分片的URL(Uniform Resource Locator，统一资源定位符)信息，构造媒体分片请求消息并发送给直播服务器，这里的i可以是与时间相关，或者在某个Representation中与索引号相关。客户端如支持HTTP协议的分块传输编码(Chunked Transfer Coding)，需在请求消息中明确指示支持；

步骤605、直播编码器依次生成构成媒体分片的各个子媒体分片，并将生成的各子媒体分片即时推送给直播服务器；

步骤606、直播服务器在接收到子媒体分片之后，立即推送子媒体分片给请求该媒体分片的客户端；

步骤607、客户端在收到部分子媒体分片(一或几个)后，即可开始播放媒体内容，而无需等到接收完构成媒体分片的所有子媒体分片才能播放。对于客户端开始播放的第一个媒体分片，可能需要满足首先向客户端缓冲区填充指定时长的初始缓冲内容，然后才能开始播放，这个初始缓冲时长可能小于媒体分片时长；对于后续其他媒体分片的播放，可能并不附加额外的限定条件。

上述步骤604至607可根据实际需要重复多次。

具体实施时，直播编码器还可以向直播服务器提供多个所述子媒体分片构成一个媒体分片的指示信息，直播服务器根据该指示信息在识别出直播编码器将输出构成媒体分片的多个子媒体分片，即可在收到每个子媒体分片后立即推送给请求相应媒体分片的客户端。具体的，直播编码器可以在推送子媒体分片之前，提供多个所述子媒体分片构成一个媒体分片的指示信息；例如在上述步骤601中提供的信息中包括该指示信息；直播服务器则可以在接收子媒体分片之前，接收到该指示信息。直播编码器也可以在推送子媒体分片时，在所发送的包括子媒体分片的数据块中包括该指示信息；直播服务器则可以在接收子媒体分片时，从所接收的包括子媒体分片的数据块中获取该指示信息进而进行识别。

具体实施时，直播编码器向直播服务器推送子媒体分片可以有多种方式，例如，可以通过共享文件、内部总线或方法调用的方式推送子媒体分片；也可以通过超文本传输协议的分块编码传输方式推送子媒体分片。

例如，若直播编码器和直播服务器均部署在同一台服务器上，可以通过共享文件的方式依次存储生成的子媒体分片，也可以通过内部总线或方法调用等方式将子媒体分片即时推送给直播服务器；若直播编码器和直播服务器彼此独立部署，可以通过HTTP POST/PUT请求消息，并采用分块传输编码方式将每个子媒体分片作为一个HTTP数据块(chunk)推送给直播服务器。

如果直播编码器原来就采用分块传输编码方式将每个媒体分片都作为一个数据块推送给直播服务器，那么采用如下方式之一(或其任意组合)可使直播服务器识别出哪些数据块中所包括的子媒体分片属于同一个媒体分片：

1)在每个数据块(chunk-extension或者chunk-data中)中添加当前子媒体分片在媒体分片对应的子媒体分片总数目中的序列号，例如由10个子媒体分片构成一个媒体分片，则在各数据块中添加的信息依次为1/10、2/10、...、10/10；

2)对构成媒体分片的多个子媒体分片单独使用一个HTTP POST/PUT消息，服务器把从同一个HTTP POST/PUT消息接收到的所有数据块都关联到同一个媒体分片；

3)如果步骤601中直播编码器向直播服务器提供的信息中没有包括生成媒体分片对应的子媒体分片的指示信息，直播服务器解析处理每个数据块，通过判断子媒体分片是否包括媒体分片级的元数据(如是否包括‘styp’/‘ftyp’+‘moov’Box等)来判断构成不同媒体分片的第一个子媒体分片(并以之作为分隔不同媒体分片的边界)；

4)在包括媒体分片第一个子媒体分片的数据块中包括媒体分片的开始指示信息，例如可在chunk-extension或者chunk-data中携带指示信息(如″FirstChunk＝true″)；同时还可在包括媒体分片最后一个子媒体分片的数据块中包括媒体分片结束指示信息(如″LastChunk＝true″)。

举一例详细说明直播服务器的对子媒体分片的识别和处理过程。如图7所示，处理流程可以包括：

步骤701、直播服务器识别直播编码器是否生成媒体分片对应的多个子媒体分片，例如可以通过判断直播编码器提供的信息是否包括生成媒体分片对应子媒体分片的指示信息，和/或根据所接收的数据块中是否包括由多个子媒体分片构成一个媒体分片的指示信息。若不是由多个子媒体分片构成一个媒体分片则跳转到步骤706，否则继续步骤702；

步骤702、直播服务器判断客户端是否支持分块传输编码，例如可以通过判断客户端发送的媒体分片请求消息中是否包括对分块传输编码的支持信息来实施。如果客户端支持分块传输编码，则继续步骤703，否则跳转到步骤706；

步骤703、直播服务器采用主动推送模式处理构成媒体分片的所有子媒体分片；

步骤704、直播服务器关联客户端发送的媒体分片请求消息中URL和对应的媒体分片(如借助服务器所提供的MPD/Manifest/播放列表等信息)，并确定构成该媒体分片的相应子媒体分片；

步骤705、直播服务器向当前请求了最新媒体分片的客户端主动推送包括了构成媒体分片的各个子媒体分片的数据块(这里最新媒体分片是指服务器所能够提供的、且与直播事件在时间上最为接近的媒体分片，即最为实时的一个媒体分片)。直播服务器在接收到直播编码器推送来的媒体分片i的第1个子媒体分片之后，立即将媒体分片i的第1个子媒体分片用HTTP数据块(chunk)推送给客户端；在接收到直播编码器推送来的媒体分片i的第2个子媒体分片之后，立即将媒体分片i的第2个子媒体分片用HTTP数据块(chunk)推送给客户端；一直持续到将媒体分片i的最后一个即第K个子媒体分片推送给客户端，直播服务器再推送出最后一个数据块(即chunk-size值为0的数据块)通知客户端构成其所请求的媒体分片的全部子媒体分片已经传输完毕；

步骤706、直播服务器仍采用被动方式响应客户端请求消息：即在收到整个媒体分片之后，在HTTP响应消息的消息体中包括完整的媒体分片并返回给客户端。

在因特网(Internet)环境下，由于非管理网络(unmanaged network)并不能确保稳定的服务质量，客户端的可用带宽和/或网络时延会存在一些波动，应对可用带宽和/或网络时延波动的最简单方法是增加客户端缓冲时长，但这将相应增加客户端的启动播放时延。但如果不增加客户端的缓冲时间，在遇到可用带宽急剧变化时，客户端可能经常需要在播放过程中进行中途缓冲，以便获取播放所需的媒体数据，但这将影响用户的体验质量。况且如今移动互联网部署和应用也越来越广泛和普遍，在移动互联网环境中，由于是多用户共享方式，其可用带宽的波动有时甚至比因特网环境更为剧烈。

在上述实施例中，直播服务器在接收到直播编码器推送过来的构成每个媒体分片的子媒体分片之后，立即转推送给了请求该媒体分片的客户端，并不对子媒体分片的内容再进行额外处理。为应对上述网络状况的急剧变化，直播服务器可以根据前面或者当前媒体分片的传输情况，或者其他途径额外获知的传输网络状况等信息，对所传输的子媒体分片进行动态裁剪(tailor)，或者由直播服务器对推送子媒体分片的过程和/或速率进行动态控制。例如，可基于不同视频帧的(解码依赖性)优先级进行丢帧处理；对于采用包括子采样结构(sub-samples)的媒体采样，可结合子采样的优先级(subsample_priority)及是否可丢弃指示(discardable)信息对子采样进行裁剪处理；对H.264编码，还可结合网络抽象层(Network Abstraction Layer，NAL)重要性指示位，对NAL单元进行丢弃处理。

下面举一例说明直播服务器对媒体分片的子媒体分片进行动态裁剪的具体实施，如图8所示，其处理流程简要描述如下：

步骤801至步骤805：与图6中的步骤601至605相同；

步骤806：直播服务器对子媒体分片进行动态裁剪(tailor)，或者对推送子媒体分片的过程和/或速率进行动态控制；

这里，直播服务器的动态裁剪可包括选择性丢帧、选择性丢弃媒体采样的子采样、选择性丢弃H.264编码的NAL单元等方式。选择性丢帧的主要目的是：当待传输的媒体数据比当前可用带宽大时，发送者选择主动丢弃一些帧，以便节省带宽来确保传输其它被选中的帧能够及时达到接收端被播放。对于根据网络状况和帧优先级进行选择性丢帧，所采用的选择性丢帧策略可概括如下：

a)I帧的优先级最高，整个GOP的解码依赖于I帧；P帧的优先级次之，且与其在GOP中的位置相关，位置越靠前则重要性越高；B帧的优先级最低；

b)在选择丢帧时，首先丢弃重要性最低的B帧；其次丢弃在GOP中位置靠后的P帧；最后才考虑丢弃I帧；

c)被丢弃的帧之间的距离尽量保持均衡：例如从每两个B帧中丢弃一个B帧(或每3个B帧中丢弃2个B帧)；

步骤807、直播服务器把裁剪后的子媒体分片给推送给请求该子媒体分片所构成媒体分片的客户端；

步骤808、客户端在收到媒体分片的部分子媒体分片(一个或几个)后，即可开始播放媒体内容，而无需等到接收完构成媒体分片的所有子媒体分片才能播放。对于客户端开始播放的第一个媒体分片，可能需要满足首先向客户端缓冲区填充指定时长的初始缓冲内容，然后才能开始播放，这个初始缓冲时长可能小于媒体分片时长；对于后续其他媒体分片的播放，可能并不附加额外的限定条件。

图9为一个基于帧优先级丢帧以适应实际网络状况的具体实例。对图9中处理流程简要描述如下：

直播服务器可根据媒体分片对应的子媒体分片的传输情况，或者其它途径(如无线基站所提供的相应网络状况查询接口等)额外获知的传输网络状况等信息，并结合选择性丢帧算法来决定具体的裁剪处理。这种裁剪是针对具体的客户端及与其直接相关的网络状况或可用带宽的；

直播服务器在确定了子媒体分片中需要被丢弃的帧之后，对子媒体分片进行裁剪，重新组织Media Data Box(‘mdat’)中所包括的sample，即删除掉需被丢弃的帧的内容，而只保留那些被选中留下的帧；另外，修改‘trun’Box中描述被丢弃的帧的元数据信息，如将其sample_size的值修改为0；

直播服务器将上述经过裁剪后的元数据信息和媒体采样重新封装成新的子媒体分片，并用HTTP数据块推送给请求了与子媒体分片所构成媒体分片对应的媒体分片的客户端。

图9的示例中给出了选择性丢帧的处理，对H.264编码，还可结合NAL重要性指示位和实际网络状况进行动态裁剪，可实施为：

直播服务器的裁剪处理可以不用丢弃整个视频帧，而是根据NAL单元的重要性指示信息丢弃某个视频帧中的一些NAL单元，其处理与选择性丢帧类似，即在Media Data Box(‘mdat’)中仅包括被选中留下的帧和帧中被选中留下的较重要的NAL单元，修改‘trun’Box中被裁剪帧的sample_size值为实际值，即如果整个帧被完全丢弃则修改其sample_size值为0；否则sample_size值修改为经过裁剪后所得到帧的实际大小。对选择性丢弃媒体采样的子采样可类似处理。

在上述的实施例中，都是以直播服务器直接为客户端提供服务为例进行说明。由于目前在实际网络部署中，内容分发网络(Content Delivery Network，CDN)被广泛用于为内容提供商/服务提供商(Content Provider，CP/ServiceProvider，SP)进行内容加速，甚至提供动态内容加速。因此，可以由CDN的边缘服务器(Edge Server)为客户端提供服务，而并不是由直播服务器直接为客户端提供服务。下面举一例说明引入CDN后对媒体内容进行传输处理的过程，如图10所示，该处理流程包括：

步骤1001、与图6中的步骤601相同；

步骤1002、由于采用CDN加速，客户端向边缘服务器发送直播MPD请求；

步骤1003、边缘服务器在收到客户端的直播MPD请求后，如果没有缓存当前最新的有效MPD，则向直播服务器请求最新的MPD；

步骤1004、直播服务器返回当前最新的直播MPD；

步骤1005、边缘服务器返回给客户端与其请求相应的直播MPD。由于直播MPD可被更新，步骤1002至步骤1005根据实际需要可重复多次；

步骤1006、客户端根据媒体分片i的URL信息，构造媒体分片请求消息并发送给边缘服务器，这里的i可以是与时间相关，或者在某个Representation中与索引号相关。客户端如果支持HTTP协议的分块传输编码，需在请求消息中明确指示支持；

步骤1007、边缘服务器如果没有缓存媒体分片i，且没有向直播服务器发出过请求媒体分片i的消息，则向直播服务器请求该媒体分片，且在请求消息中指示能支持分块传输编码；

步骤1008、与图6中的步骤605相同；

步骤1009、与图6中的步骤606类似，不同之处在于接收子媒体分片的实体为边缘服务器；

步骤1010、边缘服务器在收到直播服务器推送来的媒体分片对应的子媒体分片之后，立即转推送给请求了对应媒体分片的客户端；

步骤1011、与图6中的步骤607类似，不同之处在于客户端从边缘服务器接收媒体分片对应的各子媒体分片。

上述步骤1006至1011可根据实际需要重复多次。

在图10示例中，边缘服务器并没有对各子媒体分片进行动态裁剪，结合图8和图9示例，一个由边缘服务器对子媒体分片进行动态裁剪的实施例可以如下：

边缘服务器在收到直播服务器推送来的构成媒体分片的子媒体分片之后，推送给请求对应媒体分片的客户端之前，根据网络状况等对子媒体分片进行动态裁剪；并将裁剪后的子媒体分片封装在HTTP数据块中并推送给客户端。

在上述实施例中，直播编码器、直播服务器和/或边缘服务器都是使用HTTP协议的分块传输编码来支持子媒体分片的即时推送，但本发明实施例不限定于只能使用这种方式，并不排斥其它适合的能支持主动推送的传输协议或机制，例如当前W3C正在制定的HTML 5中的WebSocket规范等后续也可能被用于向客户端和/或服务器推送子媒体分片。

基于同一发明构思，本发明实施例中还提供了一种直播编码器、服务器、客户端和媒体内容的传输处理系统，如下面的实施例所述。由于这些装置、系统解决问题的原理与媒体内容的处理方法相似，因此这些装置、系统的实施可以参见媒体内容的处理方法的实施，重复之处不再赘述。

如图11所示，本发明实施例中的直播编码器可以包括：

封装单元1101，用于对至少一个媒体采样及其元数据进行封装，生成子媒体分片，多个所述子媒体分片构成一个媒体分片；

推送单元1102，用于每生成一个子媒体分片，将所述子媒体分片推送给直播服务器，使得所述直播服务器在接收到每个子媒体分片后，将所述子媒体分片推送给客户端播放。

一个实施例中，封装单元1101具体可以用于：当所述子媒体分片中需要包含媒体分片级元数据时，在生成的第一个子媒体分片中包含所述媒体分片级元数据。

一个实施例中，封装单元1101具体可以用于：将媒体内容的媒体采样和元数据进行封装，生成构成媒体分片的多个子媒体分片。

一个实施例中，封装单元1101具体可以用于：在生成的媒体分片对应的第一个子媒体分片中包括媒体分片级的元数据；和/或，

在生成的构成媒体分片的包括随机访问点对应位置媒体采样的子媒体分片中包括所述随机访问点。

一个实施例中，封装单元1101具体可以包括：分片设置单元，用于设置子媒体分片的目标时长或目标媒体采样数量；以及封装处理单元，用于对媒体采样及其元数据进行封装，生成满足所述目标时长或目标媒体采样数量要求的所述子媒体分片。

一个实施例中，所述分片设置单元具体可以用于：当音频内容和视频内容分别包含在不同的子媒体分片时，对包含音频内容的子媒体分片以及对包含视频内容的子媒体分片可设定不同的目标时长或目标媒体采样数量。

一个实施例中，推送单元1102可以包括：

第一推送单元，用于通过共享文件、内部总线或方法调用的方式推送子媒体分片；

或，第二推送单元，用于通过超文本传输协议的分块编码传输方式推送子媒体分片。

一个实施例中，所述直播编码器还可以包括：指示单元，用于在将所述子媒体分片推送给直播服务器之前，向所述直播服务器提供多个所述子媒体分片构成一个媒体分片的指示信息；或者在推送所述子媒体分片时包含所述指示信息。

如图12所示，本发明实施例中的服务器可以包括：

接收单元1201，用于接收接收直播编码器推送过来的子媒体分片，所述子媒体分片是构成一个媒体分片的多个子媒体分片的其中之一，每个子媒体分片由至少一个媒体采样及其元数据封装而生成；

推送单元1202，用于每接收到一个子媒体分片，将所述子媒体分片推送给客户端播放。

一个实施例中，图12所示的服务器还可以包括：

推送控制单元，用于根据网络传输状况，对接收到的子媒体分片进行动态裁剪；或者对所述子媒体分片的推送速率进行动态控制。

一个实施例中，推送控制单元单元具体可以用于进行如下一项或任意多项处理：

进行基于帧优先级的丢帧处理；

对于采用包括子采样结构的媒体采样，根据子采样的优先级信息及是否可丢弃指示信息，对子采样进行裁剪处理；

基于H.264编码的NAL单元的重要性指示信息，对H.264编码的NAL单元进行丢弃处理。

如图13所示，本发明实施例中的客户端可以包括：

请求单元1301，用于向直播服务器发送媒体分片请求消息；

接收单元1302，用于接收所述直播服务器推送过来的子媒体分片，所述子媒体分片是构成与所述请求消息相对应的媒体分片的多个子媒体分片的其中之一，每个子媒体分片由至少一个媒体采样及其元数据封装而生成；

播放单元1303，用于每接收到一个子媒体分片，则播放所述子媒体分片。

如图14所示，本发明实施例中的媒体内容处理系统可以包括：

直播编码器1401，用于对至少一个媒体采样及其元数据进行封装，生成子媒体分片，多个所述子媒体分片构成一个媒体分片；每生成一个子媒体分片，则将所述子媒体分片推送给直播服务器；

直播服务器1402，用于接收所述直播编码器推送过来的所述子媒体分片；每接收到一个子媒体分片，则将所述子媒体分片推送给客户端；

客户端1403，用于向所述直播服务器发送媒体分片请求消息；接收所述直播服务器推送过来的所述子媒体分片，所述子媒体分片是构成与所述请求消息相对应的媒体分片的多个子媒体分片的其中之一；每接收到一个子媒体分片，则播放所述子媒体分片。

当所述直播编码器和所述直播服务器部署于同一实体时，所述直播编码器通过共享文件、内部总线、方法调用等方式把所述子媒体分片推送给所述直播服务器；

当所述直播编码器和所述直播服务器为两个独立的实体时，所述直播编码器使用HTTP协议的分块编码传输协议或其他支持主动推送的协议，将所述子媒体分片推送给所述直播服务器。

一个实施例中，所述系统还包括：位于所述直播服务器和所述客户端之间的内容分发网络；所述直播服务器通过所述内容分发网络的边缘服务器将所述媒体分片的子媒体分片推送给所述客户端。

具体地，边缘服务器，用于接收客户端发送的媒体分片请求消息，将媒体分片请求消息转发给直播服务器；接收直播服务器推送的子媒体分片，并推送给客户端；直播服务器，用于接收边缘服务器转发的媒体分片请求消息，接收直播编码器推送的客户端请求的媒体分片对应的子媒体分片，并推送给边缘服务器。

一个实施例中，上述边缘服务器具体可以用于在接收到直播服务器推送的子媒体分片后，根据媒体分片的传输情况或获知的传输网络状况，对待推送的子媒体分片进行动态裁剪，将经动态载剪后的子媒体分片推送给客户端。

综上所述，本发明实施例中，通过生成媒体内容的每个媒体分片对应的子媒体分片，并采用主动推送子媒体分片的方式，提高了媒体内容传输的实时性，可解决端到端时延问题，缩短客户端初始播放、拖动和快速频道切换等操作的时延；在不采用较长时长的服务器缓冲/客户端初始缓冲的情况下，也能够对网络状况的急剧变化做出快速及时的响应和调整。

本发明实施例中客户端所请求的基本单元仍然是媒体分片，可保持与原来相同的请求消息数，并不会增加客户端和服务器的处理负担，也不会降低HTTP消息有效负载率；由于并不导致相邻两个随机访问点之间的时间间隔缩短，因此也不会降低编码效率和增加网络传输负担。

另外，本发明实施例中直播服务器(或边缘服务器)能够根据媒体分片传输状况或额外获知的其它信息，对媒体分片对应的子媒体分片经过动态裁剪之后再提供给客户端，从而快速及时应对网络状况的急剧变化。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种媒体内容的传输处理方法，其特征在于，所述方法包括：

对即时编码产生的至少一个媒体采样及其元数据按照子媒体分片的格式要求进行封装，生成子媒体分片，多个所述子媒体分片构成一个媒体分片；

每生成一个子媒体分片，则将所述一个子媒体分片推送给直播服务器，使得所述直播服务器在接收到所述一个子媒体分片后，将所述一个子媒体分片推送给客户端播放。

2.根据权利要求1所述的方法，其特征在于，所述对至少一个媒体采样及其元数据进行封装，生成子媒体分片包括：

如果所述子媒体分片中需要包含媒体分片级元数据，则在生成的第一个子媒体分片中包含所述媒体分片级元数据。

3.根据权利要求1所述的方法，其特征在于，所述对至少一个媒体采样及其元数据进行封装，生成子媒体分片具体包括：

设置子媒体分片的目标时长或目标媒体采样数量；

对至少一个媒体采样及其元数据进行封装，生成满足所述目标时长或目标媒体采样数量要求的所述子媒体分片。

4.根据权利要求3所述的方法，其特征在于，所述设置子媒体分片的目标时长或目标媒体采样数量还包括：

如果音频内容和视频内容分别包含在不同的子媒体分片中，则对包含音频内容的子媒体分片以及对包含视频内容的子媒体分片可设置不同的目标时长或目标媒体采样数量。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在将所述子媒体分片推送给所述直播服务器之前，向所述直播服务器提供多个所述子媒体分片构成一个媒体分片的指示信息；或者在推送所述子媒体分片时包含所述指示信息。

6.一种媒体内容的传输处理方法，其特征在于，所述方法包括：

接收直播编码器推送过来的子媒体分片，所述子媒体分片是构成一个媒体分片的多个子媒体分片的其中之一，每个子媒体分片由即时编码产生的至少一个媒体采样及其元数据按照子媒体分片的格式要求封装而生成；

每接收到一个子媒体分片，则将所述子媒体分片推送给客户端播放。

7.根据权利要求6所述的方法，其特征在于，在将所述子媒体分片推送给客户端播放之前，所述方法还包括：

根据网络传输状况，对接收到的子媒体分片进行动态裁剪；或者对所述子媒体分片的推送速率进行动态控制。

8.根据权利要求7所述的方法，其特征在于，所述动态裁剪包括：

基于帧优先级的丢帧处理；

和/或，对于采用包括子采样结构的媒体采样，结合其优先级及是否可丢弃指示信息，对子采样进行裁剪处理；

和/或，在采用H.264编码时，基于网络抽象层NAL重要性指示信息对NAL单元进行丢弃处理。

9.根据权利要求6所述的方法，其特征在于，将所述子媒体分片推送给客户端播放包括：

如果客户端在请求消息中指示支持HTTP协议的分块编码传输，则使用分块编码传输方式把所述子媒体分片推送给所述客户端。

10.根据权利要求6所述的方法，其特征在于，当采用内容分发网络时，将所述子媒体分片推送给客户端播放还包括：

通过内容分发网络的边缘服务器，将所述子媒体分片推送给客户端播放。

11.一种媒体内容的传输处理方法，其特征在于，所述方法包括：

向直播服务器发送媒体分片请求消息；

接收所述直播服务器推送过来的子媒体分片，所述子媒体分片是构成与所述请求消息相对应的媒体分片的多个子媒体分片的其中之一，每个子媒体分片由即时编码产生的至少一个媒体采样及其元数据按照子媒体分片的格式要求封装而生成；

每接收到一个子媒体分片，则播放所述子媒体分片。

12.一种直播编码器，其特征在于，所述直播编码器包括：

封装单元，用于对即时编码产生的至少一个媒体采样及其元数据按照子媒体分片的格式要求进行封装，生成子媒体分片，多个所述子媒体分片构成一个媒体分片；

推送单元，用于每生成一个子媒体分片，将所述一个子媒体分片推送给直播服务器，使得所述直播服务器在接收到所述一个子媒体分片后，将所述一个子媒体分片推送给客户端播放。

13.根据权利要求12所述的直播编码器，其特征在于，

所述封装单元，具体用于当所述子媒体分片中需要包含媒体分片级元数据时，在生成的第一个子媒体分片中包含所述媒体分片级元数据。

14.根据权利要求12所述的直播编码器，其特征在于，所述封装单元包括：

分片设置单元，用于设置子媒体分片的目标时长或目标媒体采样数量；

封装处理单元，用于对至少一个媒体采样及其元数据进行封装，生成满足所述目标时长或目标媒体采样数量要求的所述子媒体分片。

15.根据权利要求14所述的直播编码器，其特征在于，

所述分片设置单元，具体用于当音频内容和视频内容分别包含在不同的子媒体分片时，对包含音频内容的子媒体分片以及对包含视频内容的子媒体分片可设定不同的目标时长或目标媒体采样数量。

16.根据权利要求12所述的直播编码器，其特征在于，所述装置还包括：

指示单元，用于在将所述子媒体分片推送给直播服务器之前，向所述直播服务器提供多个所述子媒体分片构成一个媒体分片的指示信息；或者在推送所述子媒体分片时包含所述指示信息。

17.一种直播服务器，其特征在于，所述直播服务器包括：

接收单元，用于接收直播编码器推送过来的子媒体分片，所述子媒体分片是构成一个媒体分片的多个子媒体分片的其中之一，每个子媒体分片由即时编码产生的至少一个媒体采样及其元数据按照子媒体分片的格式要求封装而生成；

推送单元，用于每接收到一个子媒体分片，将所述子媒体分片推送给客户端播放。

18.根据权利要求17所述的直播服务器，其特征在于，所述直播服务器还包括：

19.根据权利要求17所述的直播服务器，其特征在于，

所述推送单元，具体用于当客户端在请求消息中指示支持HTTP协议的分块编码传输，则使用分块编码传输方式把所述子媒体分片推送给所述客户端。

20.根据权利要求17所述的直播服务器，其特征在于，当采用内容分发网络时，

所述推送单元，还用于通过内容分发网络的边缘服务器，将所述子媒体分片推送给客户端播放。

21.一种客户端，其特征在于，所述客户端包括：

请求单元，用于向直播服务器发送媒体分片请求消息；

接收单元，用于接收所述直播服务器推送过来的子媒体分片，所述子媒体分片是构成与所述请求消息相对应的媒体分片的多个子媒体分片的其中之一，每个子媒体分片由即时编码产生的至少一个媒体采样及其元数据按照子媒体分片的格式要求封装而生成；

播放单元，用于每接收到一个子媒体分片，则播放所述子媒体分片。

22.一种媒体内容的传输处理系统，其特征在于，所述系统包括：

直播编码器，用于对即时编码产生的至少一个媒体采样及其元数据按照子媒体分片的格式要求进行封装，生成子媒体分片，多个所述子媒体分片构成一个媒体分片；每生成一个子媒体分片，则将所述子媒体分片推送给直播服务器；

直播服务器，用于接收所述直播编码器推送过来的所述子媒体分片；每接收到一个子媒体分片，则将所述子媒体分片推送给客户端；

客户端，用于向所述直播服务器发送媒体分片请求消息；接收所述直播服务器推送过来的所述子媒体分片，所述子媒体分片是构成与所述请求消息相对应的媒体分片的多个子媒体分片的其中之一；每接收到一个子媒体分片，则播放所述子媒体分片。

23.根据权利要求22所述的系统，其特征在于，

24.根据权利要求22所述的系统，其特征在于，所述系统还包括：位于所述直播服务器和所述客户端之间的内容分发网络；

所述直播服务器通过所述内容分发网络的边缘服务器将所述子媒体分片推送给所述客户端。