CN101488871A - 一种互联网环境下流媒体准广播级获取方法及系统 - Google Patents

Abstract

本发明公开了一种多播或广播流媒体播放系统相关领域的媒体数据优化方案，即一种接收实时广播或多播流媒体流的方法，它使用多进程(线程)方式从媒体流发送端接收媒体流，并提供写缓存仲裁器模块，进程(线程)管理模块对多进程(线程)进行管理。通过该方案的使用，提高了从媒体流发送端接收媒体流的效率和整体的稳定性，由于采用模块化设计，其可移植性、可维护性也得到了较大提高。

Description

一种互联网环境下流媒体准广播级获取方法及系统

技术领域

本发明涉及网络多媒体播放及下载领域，尤其涉及实时流媒体广播或多播下载及播放相关技术。

背景技术

随着网络多媒体的流行，在流媒体播放领域出现了多种流媒体播放格式，而在实时流媒体领域，目前业界较有名气的主要是MMS(Microsoft Media Server Protocol)和RTSP(RealTime Streaming Protocol)两种：

MMS协议是由微软公司首先提出，通过MMS协议可以在Internet上实现WindowsMedia服务器中流媒体文件的传送与播放。这些文件包括.asf、.wmv等，可以使用Windows Media Player、Mplayer等媒体播放软件来实时播放。

实时流协议RTSP是由RealNetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。即RTSP可以是双向的，客户机和服务器都可以发出请求。

由于微软对MMS协议内容并未公开，且该协议是单向协议(媒流只能从服务器发送给客户端)，使其应用范围受到了一定的影响，目前很多嵌入式产品或非Microsoft平台流媒体设备生产厂家只能开发基于RTSP协议的产品。

现有技术的缺点：

由于媒体流一般不是一个事先已经保存好的服务器文件，它是实时图像和声音经过流编码器以广播或多播方式恒速由发送端传送到接收端，接收端再将使用对应的解码器将数据解码后播放出来的。

在这样一种模式下，接收端无法采用多线程方式将发送端的媒体流分成多个小块分片传送，而只能使用单进程或单线程从媒体流发送端接受数据，为了防止由于网络因素而引起的数据接收速度波动问题，在接收端一般采用缓存机制缓存一定数量的媒体流后再播放，以尽量保证播放效果的流畅。

而事实上这种方式并不能完全解决上述问题，可能的场景如下：

由于单进程使用单一的Socket与媒体流发送端连接，根据这个Socket在网络上所确定的路由不同，它所获得的网络速率也是不同的，所以若在某一时刻选择的路由是低速路由，则会大大影响多媒体通信效果。

由于网络本身的不稳定性，在某个时刻的某个路由有较好的速率，而在另外时刻由于某些因素导致其性能严重下降，如路由路径中某个路由器转发过多的数据，这时就会影响到媒体流接收速率，并可能影响到播放效果。

发明内容

针对现有技术中存在的不足，本发明公开了一种多播或广播流媒体播放系统相关领域的媒体数据优化方案。通过该方案的使用，提高了从媒体流发送端接收媒体流的效率和整体的稳定性，由于采用模块化设计，其可移植性、可维护性也得到了较大提高。

本发明的技术方案是这样实现的：一种接收实时广播或多播流媒体流的方案，它使用多进程(线程)方式从媒体流发送端接收媒体流，并提供写缓存仲裁器模块，进程(线程)管理模块对多进程(线程)进行管理。系统包括媒体流接收模块、写缓存仲裁器模块、解码器、进程管理器，其中，所述媒体流接收模块：由一组功能相同的进程(线程)组成，它们从通过不同的Socket媒体流发送端获取媒体流数据，并将数据交传递给写缓存仲裁器模块；所述写缓存仲裁器模块：负责分析不同进程(或线程)发来的媒体流，根据特定的处理策略对媒体流进行处理；所述解码器：负责从缓存中获取媒体流，并解码；所述进程管理器：负责对媒体流接收进行组进行管理，其他包括当缓存中的数据降低到一定程度，则会增加进程组中的进程，以寻找更多、更好的路由获取媒体流，对于某些Socket一段时间内获取不到媒体流或吞吐量较低，则会杀死该进程，并试图启用新进程，创建新连接。

本发明的有益效果：

本发明对于整个流媒体播放系统来说，具有以下优点：

1.增加了系统稳定性：当进程组中某个进程对应Socket处于阻塞状态时，其他进程可以代替它完成从媒体流发送端接收数据功能，实现了一定的备份功能。

2.提高了媒体流获取效率：由于有多个相同的进程使用不同的Socket获取媒体流，写缓存仲裁器模块总是使用它们当中效率最高的进程获取到的媒体流，而对于性能始终得不到提升的进程，进程管理器可以将其杀死。

3.模块化结构：整体系统采用模块化方式组织，可以较容易的实现功能移植或使用不同的开发语言实现，同时也提供了清晰的接口，以将其与现有媒体播放终端融合，如Mplayer。

附图说明

图1是本发明实施例的多进程从媒体流发送端接收数据系统框架图；

图2是本发明实施例的媒体流接收模块处理流程图；

图3是本发明实施例的写缓存仲裁模块处理流程图；

图4是本发明实施例的进程管理模块处理流程图。

具体的技术方案

下面结合具体的框图或流程图，对本发明的具体技术方案作进一步描述：

使用多进程技术从媒体流发送端接收数据

系统整体架构如图1所示，多进程从媒体流发送端接收数据系统架构图。

整个系统分成如下几个部分：

1.媒体流接收模块：由一组功能相同的进程(线程)组成，它们从通过不同的Socket媒体流发送端获取媒体流数据，并将数据交传递给写缓存仲裁器模块。

2.写缓存仲裁器模块：负责分析不同进程(或线程)发来的媒体流，根据特定的处理策略对媒体流进行处理(写入缓存/丢弃)。

3.解码器：负责从缓存中获取媒体流，并解码。

4.进程管理器：它负责对媒体流接收进程(线程)组进行管理，其他包括当缓存中的数据降低到一定程度，则会增加进程组中的进程，以寻找更多、更好的路由获取媒体流；对于某些Socket一段时间内获取不到媒体流或吞吐量较低，则会杀死该进程，并试图启用新进程，创建新连接，以提高系统效率。

媒体流接收模块：

本模块负责从媒体流发送端接收媒体流。具体可描述为如下几点：

1.根据媒体流发送端使用的报文发送协议，如TCP、UDP建立与媒体流发送端的网络连接。

2.执行特定的媒体流获取协议，如MMS、RTSP协议，从媒体流发送端获取媒体流。

3.对获取到的媒体流执行必要的协议解包操作，将解包后的报文转送至写缓存仲裁器模块。

它的流程如图2所示，媒体流接收模块处理流程图。

写缓存仲裁模块：

本模块负责对从媒体流接收模块获取到的媒体流报文按特定的策略进行处理，目前的处理策略主要是丢弃和写入缓存两种。具体描述为如下：

1.接收来自媒体流接收模块处理过的媒体流报文。

2.确定报文处理策略，由于多进程(线程)从媒体流发送端获取媒体流，而这些媒体流在播放时间上存在重复，在此处理策略中，确定该媒体流的状态(是否已经写入缓存)。

3.根据报文处理策略进行处理：对于已经写缓存的媒体流，则丢弃，对于未写入缓存的媒体流，则将其写入缓存。

它的执行流程如图3所示，写缓存仲裁模块处理流程图。

进程管理模块：

在系统中，它同时又是一个监控模块，负责管理所有接收媒体流进程(线程)组中的进程。它的技术方案具体可描述为如下几点：

1.扫描进程(线程)组中的每一个进程(线程)。

2.杀死处理能力较弱的进程，这些进程可能是：接收数据较慢的进程；长时间没有接收到数据的进程；与处理能力最强进程差距太大的进程等。

3.检查已缓存媒体流占缓存百分比，若缓存中数据低于定义的阀值，则采用一定的策略提高系统能力，如增加接收媒体流进程数目，减小进程等待时间等。

4.若采用优化处理策略后，仍无法提高系统效率，则告警或记录日志。

本模块处理流程如图4所示，进程管理模块处理流程图。

虽然本发明通过实施例进行了描述，但实施例并非用来限定本发明。本领域技术人员可在本发明的精神的范围内，做出各种变形和改进，因此本发明的保护范围应当以本申请的权利要求保护范围所界定的为准。

Claims (9)

1、一种接收实时广播或多播流媒体流的方法，其特征在于，它使用多进程(线程)方式从媒体流发送端接收媒体流，并提供写缓存仲裁器模块，进程(线程)管理模块对多进程(线程)进行管理。

2、根据权利要求1所述的接收实时广播或多播流媒体流的方法，其特征在于，其多进程(线程)的数目或获取媒体流方式可通过其他模块或函数进行管理或控制。

3、根据权利要求1所述的接收实时广播或多播流媒体流的方法，其特征在于，所述写缓存仲裁器模块：协调多进程(线程)的运行，按特定的处理策略对媒体流接收进程(线程)获取到的媒体流进行处理。

4、根据权利要求1所述的接收实时广播或多播流媒体流的方法，其特征在于，所述进程(线程)管理模块：集中管理接收媒体流进程(线程)组中所有进程(线程)，并在需要时根据一定外部条件，修改对其所管理进程(线程)的管理策略。

5、一种接收实时广播或多播流媒体流的系统，它包括媒体流接收模块、写缓存仲裁器模块、解码器、进程管理器，其特征在于，

所述媒体流接收模块：由一组功能相同的进程(线程)组成，它们从通过不同的Socket媒体流发送端获取媒体流数据，并将数据交传递给写缓存仲裁器模块；

所述写缓存仲裁器模块：负责分析不同进程(或线程)发来的媒体流，根据特定的处理策略对媒体流进行处理；

所述解码器：负责从缓存中获取媒体流，并解码；

所述进程管理器：负责对媒体流接收进行组进行管理，其他包括当缓存中的数据降低到一定程度，则会增加进程组中的进程，以寻找更多、更好的路由获取媒体流，对于某些Socket一段时间内获取不到媒体流或吞吐量较低，则会杀死该进程，并试图启用新进程，创建新连接。

6、根据权利要求5所述的接收实时广播或多播流媒体流的系统，其特征在于，所述媒体流接收模块：

根据媒体流发送端使用的报文发送协议，建立与媒体流发送端的网络连接；

执行特定的媒体流获取协议，从媒体流发送端获取媒体流；

对获取到的媒体流执行必要的协议解包操作，将解包后的报文转送至写缓存仲裁器模块。

7、根据权利要求5所述的接收实时广播或多播流媒体流的系统，其特征在于，所述写缓存仲裁器模块：

接收来自媒体流接收模块处理过的媒体流报文；

确定报文处理策略，由于多进程(线程)从媒体流发送端获取媒体流，而这些媒体流在播放时间上存在重复，在此处理策略中，确定该媒体流的状态；

根据报文处理策略进行处理：对于已经写缓存的媒体流，则丢弃，对于未写入缓存的媒体流，则将其写入缓存。

8、根据权利要求5所述的接收实时广播或多播流媒体流的系统，其特征在于，所述进程管理器：

在系统中，它同时又是一个监控模块，负责管理所有接收媒体流进程(线程)组中的进程。它的技术方案具体可描述为如下几点：

扫描进程(线程)组中的每一个进程(线程)。

杀死处理能力较弱的进程，这些进程可能是：接收数据较慢的进程；长时间没有接收到数据的进程；与处理能力最强进程差距太大的进程等。

检查已缓存媒体流占缓存百分比，若缓存中数据低于定义的阀值，则采用一定的策略提高系统能力。

9、根据权利要求8所述的接收实时广播或多播流媒体流的系统，其特征在于，所述采用一定的策略：增加接收媒体流进程数目，减小进程等待时间。

Images