[发明专利]媒体流的实时接收方法及客户端

说明书

本发明公开了一种媒体流的实时接收方法及客户端，其中，方法包括：发送媒体段请求至服务器；接收并解析服务器反馈的媒体段，并从媒体段中解析出媒体单元，并生成目标媒体流的第一接收报告；接收并解析至少一路推送的目标媒体流，其中，从推送的目标媒体流中解析出媒体单元，并生成目标媒体流的第二接收报告；根据第一接收报告和第二接收报告生成新媒体段请求，其中，确定新媒体段请求携带的控制参数。根据本发明实施例的接收方法，集成拉取和推送两种方式，支持媒体流的单播/多播/广播传送，提高实时媒体流的传送效率和可靠性。

技术领域

本发明涉及数字信息传送技术领域，特别涉及一种媒体流的实时接收方法及客户端。

背景技术

随着互联网特别是移动互联网的快速发展，通过互联网来实时传送音频、视频、图像等多媒体数据成为许多应用的基本需求，为满足这一需求，人们提出了各种流媒体实时传输技术，目前得到广泛使用的主要包括三类：实时传送协议RTP((Real-time TransportProtocol，实时传输协议)/RTSP(Real Time Streaming Protocol，实时流传输协议))、RTMP(Real Time Messaging Protocol，实时消息传送协议)和HTTP(HyperText TransferProtocol，超文本传输协议)自适应性流传输HAS(HTTPAdaptive 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地址。但是由于清单文件需要经过一段时间才能传输给客户端，因此，客户端得到的清单文件并不能反映当前最新的媒体片段的生成情况，此外，当清单文件遇到阻塞或者传输出错时，将阻塞用户对媒体片段的快速访问，降低实时流媒体的传送性能。