CN100346602C

CN100346602C - 实现视频质量与发送速率控制的高并发流媒体服务器系统

Info

Publication number: CN100346602C
Application number: CNB2005100270764A
Authority: CN
Inventors: 叶德建; 张佐; 吴秋峰
Original assignee: Fudan University
Current assignee: Fudan University
Priority date: 2005-06-23
Filing date: 2005-06-23
Publication date: 2007-10-31
Anticipated expiration: 2025-06-23
Also published as: CN1731732A

Abstract

本发明属于网络多媒体技术领域，具体公开了一种支持高并发数并实现视频质量与发送速率控制的流媒体服务器系统。该系统采用新颖独特的架构以提高其并发用户数，并将发送速率与视频质量控制有机融合起来，给出统一实现模式，有效地提升了流媒体的服务质量。本系统由：主控进程、RTSP通信进程和媒体数据发送进程组成，各个进程之间采用消息集线器的通信结构，进程间通信都通过主控进程；进程间通信方式为消息队列和套接字，除媒体数据发送进程外，各进程都运行在一个计算机上。媒体数据发送进程的核心是视频质量控制、发送速率控制和RTP打包发送。

Description

实现视频质量与发送速率控制的高并发流媒体服务器系统

技术领域

本发明属网络多媒体技术领域。具体的说，主要涉及一种能够实现视频质量与发送速率控制的高并发流媒体服务器系统。

背景技术

流媒体指在网络中使用流式传输技术传送音频、视频和多媒体文件等。流式传输技术的特点是把连续的音频和视频信息经过压缩后放到网络的服务器上，网络用户一边下载一边进行收听或观看，而不必等到把整个文件下载完毕。目前，越来越多的企业网和校园网上都开展了流媒体应用，同时流媒体技术的兴起也越来越受到了学术界和工业界的高度关注。但是，流媒体的应用费用相对比较高昂，特别是在远程传送流媒体信息方面。鉴于目前多数企业都已经采用了许多通用服务器产品，而且这类产品的成本越来越低，许多厂商纷纷推出以通用服务器产品作为硬件平台的流媒体解决方案，通过在通用服务器上安装流媒体服务器软件，就可以满足企业流媒体应用的需求。国际上使用较多的流媒体服务器软件主要有RealNetworks公司的Helix Server、Microsoft公司的Windows Media Server(以下简称为微软Media Server)和Apple公司的Darwin StreamingServer，它们占据着绝大部分市场份额。而近期微软的Media Server逐渐胜出，成为主流中的主流。

但是这些流媒体服务器普遍没有实现好的缓冲控制和流媒体速率平滑技术，发送速率波动性很大，对瘦客户端的服务质量造成很大影响；另一方面，这些流媒体服务器也不能像机顶盒或无线终端所要求的那样控制客户端缓冲区到给定值范围，容易造成缓冲区溢出。目前国际上较多的流媒体服务器软件系统还存在并发性能不好，可扩展性差，多种客户端并存却互不兼容等问题，例如微软Media Server存在只支持多机松耦合集群、Windows平台、Microsoft类型的播放器等问题，极大地限制了流媒体技术的应用推广。

发明内容

本发明的目的在于提出一种能够实现视频质量和发送速率控制的支持高并发数的流媒体服务器系统，以解决上述主流流媒体服务器可扩展性差、支持平台单一、支持请求类型不够全面的问题。

本发明提出的流媒体服务器系统采用新颖的方法提高其并发用户数，并根据发送速率与视频质量控制的特点将两者有机地融合起来，给出了统一实现模式，使得发送速率与视频质量控制协同工作，有效地提升了流媒体的服务质量。该系统包括三个进程：主控进程、RTSP(实时流协议)通信进程和媒体数据发送进程；其中，主控进程管理和协调其他进程的运行，RTSP通信进程负责与客户端的RTSP交互信息的传输，媒体数据发送进程负责发送媒体数据；各个进程之间的通信结构采用消息集线器结构形式；各进程之间的通信方式采用消息队列方式和套接字方式：主控进程和RTSP通信进程都运行在一个计算机上，相互之间通信采用消息队列的方式，而媒体数据发送进程与主控进程通信采用套接字方式。

本发明中，一个主控进程通过不同通信方式统筹管理其他进程，这种主从式的架构可以方便地添加功能模块，对原先系统影响很小。图1是该体系的总体逻辑架构图。

各个进程之间的通信结构采用消息集线器(Hub)结构形式，即其他所有的进程之间不进行直接通信，所有的进程间通信都通过主进程。与各个进程直接互相通信的方案相比较，消息集中处理方案便于集中控制，实现简单，逻辑清楚；各个进程之间的通信方式采用为消息队列方式和Socket(套接字)方式。除了媒体数据发送进程外，其他各个进程都运行在一个计算机上，所以相互之间采用消息队列的方式进行通信，可以保证通信的高效和可靠。至于媒体数据发送进程，由于其负责实际媒体数据的传输，需要大量的系统资源，可能有若干个运行在不同机器上的媒体数据发送进程协同工作，所以，媒体数据发送进程采用套接字通信方式与主控进程进行通信，可以保证通信的高效和可靠。通过连接多个媒体数据发送进程，可以加大整个流媒体服务器所支持的并发数目，提供一定的冗余保护。

本发明中，各播放板(媒体数据发送进程及其支撑硬件系统合称为播放板)统一由一块主控板(RTSP进程和主控进程两个进程及其硬件系统合在一起记做主控板)管理，所有用户请求都定位到主控板，主控板在各个硬件设备和播放板之间自主进行负载均衡。

RTSP通信进程不负责媒体数据发送，该进程采用单线程派发技术，以提高并发性，一套RTSP进程和主控进程可以带一个或多个媒体数据发送进程，具有良好的可扩展性。

媒体数据发送进程负责视频质量控制、发送速率控制和RTP打包发送。该进程从网络缓冲区中取下一帧(第k帧)数据，根据视频质量控制模块和发送速率控制模块的输出来调制第k帧数据，把调制后的第k帧数据打成RTP(实时传输协议)包发送。视频质量控制模块运用比例积分的方法，根据比例积分系数Kp、Ki来输出视频质量Q。

本发明的这种主从式架构使得一套服务器系统可以配备不同类型的播放板，从而能同时支持Media Player、QuickTime和IPTV机顶盒等多种客户端请求。该系统架构把许多依赖于操作系统实现的调度功能都收归到服务器上层实现，并根据流媒体应用的具体特点做优化。因此该系统不依赖于操作系统的特殊支持，播放板和主控板之间通过网络连接，主控板和播放板可以运行在不同的软硬件平台上，具有跨平台性。

附图说明：

图1是本发明的总体架构图。其中，显示了各个进程之间的通信关系。主控进程管理和协调其他进程的运行；RTSP通信进程负责与客户端的RTSP控制信息的传输；媒体数据发送进程负责发送媒体数据。

图2是媒体数据发送进程的工作流程图。

图3是视频质量控制、发送速率控制和RTP打包发送流程。

图4是视频质量控制策略；其中，Q表示质量控制信号量，K_p为比例积分调节器的比例项系数，K_i为比例积分调节器的积分项系数，Integ为积分器的输出；Ref为接收缓冲区数据量的参考值。

具体实施方式

下面进一步介绍本发明的实施方式。

第一，主控进程(Main Process)负责管理和协调其他进程的运行，由以下几个模块构成：

a.初始化模块；创建主控进程的主数据结构、加载服务器上的媒体文件信息表以及他的一些初始化工作；

b.RTSP(实时流协议)和RTCP(实时传输控制协议)包解析模块，负责RTSP包和RTCP包的解析；

c.响应RTSP信息模块：

建立连接：如果有客户端请求建立连接，首先对用户信息进行认证，然后调用调度信息表进行接纳控制，判断服务器是否有能力再接受一个新的客户端服务请求。若拒绝该连接请求，则直接通知客户端，如果接受该连接请求，则分配给客户端发送数据的服务器端口号等相关信息，并更新服务器上的相应管理信息；

播放：根据文件ID以及RTSP的播放时间信息，发指令给相应的媒体数据发送进程进行播放，更新服务器上的相应管理信息；

暂停或重新定位：更新服务器上的相应管理信息，并通知媒体数据发送进程停止发送数据或通知媒体数据发送进程重新定位发送数据；

关闭连接：更新服务器上的相应管理信息，并通知媒体数据发送进程停止发送媒体数据并清除该连接；

d.响应RTCP信息模块：

其作用是，当主控进程每收到一个RTCP包时，做一次流量控制工作。为适应网络发展的需要，我们按TCP友好流量控制(TCP-Friendly Rate Control)方式进行设计。所不同的是，在TCP的反馈包中，要么是丢包信息，要么是收到包的确认信息；而在RTCP反馈包中，只有丢包率的多少信息，且反馈不及时。因此基于RTCP反馈信息的流量控制方法如下：当相邻几个RTCP反馈包所汇报的丢包率基本恒定或有下降趋势时，缓慢提升服务器对发出该数据包的用户的发送速率(如果发送速率已经达到一个上限值，则不再增加发送速率)；当最近得到的RTCP反馈包所报告的丢包率比以前有所上升时，快速下降发送速率；

e.响应媒体数据发送进程的反馈信息模块：其作用是，当媒体数据发送进程向主控进程汇报媒体数据发送进程的运行状态时，做相应的处理；

f.响应主控服务器上其他进程的信息。

第二，RTSP通信进程(RTSP Communication Process)。RTSP协议是传输交互指令(如建立和释放流媒体连接、暂停播放、拖动播放等控制信息)的协议，为了保证指令信息传输的可靠性，工业标准上RTSP信息利用TCP连接传输。在流媒体服务器的实现里，一般遵循TCP连接的处理习惯，但是每个TCP连接启动一个线程易造成线程资源耗尽(一个进程所能启动的线程数量是很有限的)，所以在硬件资源尚有很大富裕的情况下，由于线程数受限而限制了服务器所支持的并发数。在RTSP通信进程模块中，先建立RTSP监听端口，响应用户的RTSP连接，接收多个用户的RTSP数据包，并把数据包按照规定格式加入主控进程的接收消息队列中，再从主控进程的发送消息队列中读取RTSP数据包，并发往相应用户的RTSP套接字。这样，RTSP通信进程模块就能充分利用了RTSP连接的特点，巧妙地采用套接字轮询的方式，采用单线程批发技术(STD)，避免了线程数受限的问题。

第三，媒体数据发送进程(Media Data Sender Process)。媒体数据发送进程负责按照流媒体标准协议RTP协议发送媒体数据。在媒体数据发送进程模块中，共同维护三个主要数据结构：

a.该媒体数据发送进程负责的会话的一些必要状态信息表，记作SessionInformation。每个Session的状态信息包括该Session的当前状态(state)、客户的IP地址和Port号、媒体文件ID等。

b.每个会话的一级缓存(该缓存用于克服硬盘和网络传输之间的速率不匹配)，记作HardDiskBuffer。

c.每个会话的二级缓存(用于充当网络发送的缓冲区)，记作Network Buffer。

媒体数据发送进程的总体流程如图2所示。媒体数据发送进程设一个定时器，每隔一定时间(如100ms)轮询一遍该媒体数据发送进程所负责的活跃会话(即已经建立连接的会话)的状态，若当前会话的状态为Play，则对该会话的各个缓冲器内的数据进行合理地调度，并按照缓冲区控制和速率平滑技术进行数据发送(见图2的步骤9)。同样的，对各个活跃的会话进行轮询处理的办法可以避免启动大量的线程，在大并发的应用环境下可以节约系统开销。媒体数据发送进程的核心部分是缓冲区控制、速率平滑技术和RTP打包发送，即图2中的步骤9。这部分可参见图3视频质量控制、发送速率控制和RTP打包发送流程。因为视频质量控制时同样需要对视频的数据流进行合理的调度，所以我们可以把发送速率控制看作视频质量控制的一种特殊情况。从而可以把图3作为发送速率控制和视频质量控制的统一实现模式。

第四，发送速率控制算法由帧调度模块实现，而质量控制器的输出始终为1(即为无损传输)。在这种情况下，码率整形器、接收方缓冲区观测器不需做任何工作，拥塞控制模块也被屏蔽掉。图2中的步骤9就是根据这样的思路实现的。其具体流程如图3和图4所示。根据图3的流程，如果当前采样周期内服务器所发送的数据还不到拥塞控制器(或发送速率控制器，也叫速率平滑算法)所决定的当前采样周期内应该发送的数据量，则就进行下一帧数据的处理。这一步的判断相当于实现了图3中的发送缓冲区监视器和数据祯调度的功能。进一步的，对下一帧数据的处理包括三个步骤：

1.从网络缓冲区中里取下一帧(第k帧)数据；

2.根据质量控制器(质量控制器的流程如图4所示) 输出来调制第k帧数据。对数据帧的调制可以用很多方式实现：如果视频数据是分层编码的，那么可以通过从该帧数据中选择合适的层数来达到调制该帧数据的视频质量和发送比特率要求；如果视频数据是可扩展编码的，那么可以直接利用可扩展编码的特性来调制数据：如果视频数据是按MPEG-2或更早的编码标准编码的，那么可以采用动态比特率整形(Dynamical RateShaping)的方法调制该帧数据的视频质量和发送比特率要求。

3.把调制后的第k帧数据打成RTP包发送。图4给出了质量控制器的具体实现流程。在这个实施例子里，我们用比例积分调节器来进行视频质量控制。每到一个采样时刻，质量控制器读入接收缓冲区观测器的输出，并进行比例积分运算，最后输出视频质量。我们也可以用其他的调节器来进行视频质量控制，比如模糊调节器、比例调节器等等。

在图3中的质量控制器里，有一比例积分器，对应图4中的402和404。积分器的输出记做Q。该质量控制器有三个参数：

1.接收缓冲区数据量的参考值，记为Ref，用于设定接收缓冲区数据量的调节目标。

2.比例积分调节器的比例项系数K_p，用于设定比例积分调节器的比例项的调节强度。

3.比例积分调节器的积分项系数K_i，用于设定比例积分调节器的积分项的调节强度。

如图4所示，采用比例积分调节器的质量控制器在一个采样周期里的工作步骤是：

1.读入接收缓冲区观测器的观测值。这里接收缓冲区观测器的观测值用B_r表示。

2.把接收缓冲区观测器的观测值B_r与接收缓冲区数据量的参考值做Ref比较，按照式(6.1)调整积分器的输出

Integ＝Ki*(Br-Ref)+Integ (6.1)

对应图4中的步骤402。

按照式(6.2)计算视频质量Q

Q＝Integ+Kp*(Br-Ref) (6.2)

对应图4中的步骤404。

上述内容公开了本发明的一种最佳模式。应该理解并且认识到，有许多等效于在此公开的示例性实施方式，并且在不脱离本发明的范围和精神的情况下可以进行修改和变形。

Claims

1.一种实现视频质量与发送速率控制的高并发流媒体服务器系统，其特征在于该系统由主控进程、RTSP通信进程和媒体数据发送进程组成，其中，主控进程管理和协调其他进程的运行，RTSP通信进程负责与客户端的RTSP交互信息的传输，媒体数据发送进程负责发送媒体数据；各个进程之间的通信结构采用消息集线器结构形式；各进程之间的通信方式采用消息队列方式和套接字方式：主控进程和RTSP通信进程都运行在一个计算机上，相互之间通信采用消息队列的方式，而媒体数据发送进程与主控进程通信采用套接字方式；由媒体数据发送进程及其支撑硬件系统组成的各播放板统一由一块由RTSP通信进程和主控进程及其硬件系统组成的主控板管理，所有用户请求都定位到主控板，主控板在其各个硬件设备和播放板之间自主进行负载均衡；这里RTSP是指实时流协议。

2.根据权利要求1所述的流媒体服务器系统，其特征在于RTSP通信进程不负责媒体数据发送，该进程采用单线程派发技术来提高并发性，一套RTSP进程和主控进程带一个或多个媒体数据发送进程。

3.根据权利要求1所述的流媒体服务器系统，其特征在于媒体数据发送进程负责视频质量控制、发送速率控制和RTP打包发送；该进程从网络缓冲区中取下一帧，即第k帧数据，根据视频质量控制模块和发送速率控制模块的输出来调制第k帧数据，把调制后的第k帧数据打成RTP包发送；视频质量控制模块运用比例积分的方法，根据比例积分系数来输出视频质量Q。

4.根据权利要求1所述的流媒体服务器系统，其特征在于主控进程由以下模块组成：

a.初始化模块；创建主控进程的主数据结构、加载服务器上的媒体文件信息表以及主控进程的一些初始化工作；

b.RTSP和RTCP包解析模块，负责RTSP包和RTCP包的解析；这里RTCP是指实时传输控制协议；

c.响应RTSP信息模块：

建立连接：如果有客户端请求建立连接，首先对用户信息进行认证，然后调用调度信息表进行接纳控制，判断服务器是否有能力再接受一个新的客户端服务请求；若拒绝该连接请求，则直接通知客户端，如果接受该连接请求，则分配给客户端发送数据的服务器端口号等相关信息，并更新服务器上的相应管理信息；

d.响应RTCP信息模块：

其功能是，当主控进程每收到一个RTCP包时，做一次流量控制工作，其流量控制方法如下：当相邻几个RTCP反馈包所汇报的丢包率基本恒定或有下降趋势时，缓慢提升服务器对发出该数据包的用户的发送速率；当最近得到的RTCP反馈包所报告的丢包率比以前有所上升时，快速下降发送速率；

e.响应媒体数据发送进程的反馈信息模块：其功能是，当媒体数据发送进程向主控进程汇报媒体数据发送进程的运行状态时，做相应的处理。

5.根据权利要求1所述的流媒体服务器系统，其特征在于RTSP通信进程模块中，先建立RTSP监听端口，响应用户的RTSP连接，接收多个用户的RTSP数据包，并把数据包按照规定格式加入主控进程的接收消息队列中，再从主控进程的发送消息队列中读取RTSP数据包，并发往相应用户的RTSP套接字。

6.根据权利要求1所述的流媒体服务器系统，其特征在于媒体数据发送进程模块中，共同维护三个主要数据结构：

a.该媒体数据发送进程负责的会话的一些必要状态信息表，包括该信息的当前状态等；

b.每个会话的一级缓存；

c.每个会话的二级缓存。