[发明专利]媒体流的实时递送方法及服务器

说明书

本发明公开了一种媒体流的实时递送方法及服务器，其中，方法包括：接收客户端发送的媒体段请求，其中，媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数；根据媒体段请求生成媒体段，其中，根据第一类参数确定待传送的目标媒体流，根据第二类参数确定待传送的候选媒体单元，并将待传送的候选媒体单元封装成媒体段；发送媒体段至客户端。该方法根据客户端的请求来实时生成媒体段，并返回给客户端，以实现按客户端需求分段的实时媒体流递送，从而有效降低媒体流传输延时和开销，进一步提高实时媒体流的传输性能。

技术领域

本发明涉及数字信息传送技术领域，特别涉及一种媒体流的实时递送方法及服务器。

背景技术

随着互联网特别是移动互联网的快速发展，通过互联网来实时传送音频、视频、图像等多媒体数据成为许多应用的基本需求，为满足这一需求，人们提出了各种流媒体实时传输技术，目前得到广泛使用的主要包括三类：实时传送协议(RTP(Real-time TransportProtocol，实时传输协议)/RTSP(Real Time Streaming Protocol，实时流传输协议))、RTMP(Real Time Messaging Protocol，实时消息传送协议)和HTTP(HyperText TransferProtocol，超文本传输协议)自适应性流传输HAS(HTTP Adaptive Streaming)。其中，HTTP自适应流传输又包括多种方案：苹果公司提出的HLS(HTTP Live Streaming)、微软提出的平滑流Smooth Streaming、Adobe提出的HDS(HTTP Dynamic Streaming)、MPEG组织提出的DASH(Dynamic Adaptive Streaming over HTTP，基于HTTP的动态自适应流)。

这些HTTP自适应性流传输方案的共同特点是将媒体流切割成短时间(2s～10s)的媒体片段，并同时生成描述这些媒体片段的索引文件或清单文件(例如HLS中的m3u8播放列表和DASH中的MPD文件)，然后将其保存到各Web服务器上，客户端通过访问播放列表或清单文件，获得这些媒体片段的URL(Uniform Resource Locator，统一资源定位符)访问地址，然后可以采用标准的HTTP协议来逐个下载这些媒体片段并进行播放。这些方案的主要区别体现在媒体片段采用的封装格式和清单文件格式的不同。

相对于RTP/RTSP和RTMP来说，HTTP自适应流传输可以充分利用现有的互联网Web缓存设施(如CDN和各种Web缓存服务器)，可以支持大规模的用户访问。同时，通过提供多种码率的媒体片段，还可以支持客户端根据网络条件和终端能力来自行选择合适码率的片段，实现码率自适应。因此，HTTP自适应流传输已成为目前互联网上实时流媒体递送的主流方式。

但是，上述的这些HTTP自适应流传输方案均存在两个问题：

问题1，媒体片段的时长无法适应动态变化的网络传输。目前的HAS方案均采用预分段的方式，即服务器按照预先设置的时长来生成媒体片段及其清单文件并提交给web服务器。当网络传输带宽充足且延时较小时，设置较大的片段时长意味着增加实时传送的延时；当网络传输带宽不足且延时较大时，设置较小的片段时长意味着频繁的文件请求，增加服务器的负担和网络传输开销。由于互联网上的传输带宽和传输延时是动态变化的，采用固定时长的预分段方式无法实现最优传输。

问题2，清单文件增加了传送延时和开销。客户端需要先得到清单文件，才能获得媒体片段的URL地址。但是由于清单文件需要经过一段时间才能传输给客户端，因此，客户端得到的清单文件并不能反映当前最新的媒体片段的生成情况，此外，当清单文件遇到阻塞或者传输出错时，将阻塞用户对媒体片段的快速访问，降低实时流媒体的传送性能。

发明内容

本发明旨在至少在一定程度上解决相关技术中的技术问题之一。