实时数据传输对于视频播放具有非常重要的意义，在各种网络特性中时延参数占有相当的份量。通常认为视频这类应用其时延要求小于20毫秒╩s），抖动限制在4毫左?lt;SUP>[1][3]。尽管提高网络带宽可以改善网络的吞吐量、传输延时等性能，由于视频数据的高容量和视频信源的高比特率特性，对于客户端的服务质量要求来说显得微不足道。目前针对视频服务质量，从传送层协议的使用、数据的压缩/解压、协同计算到单播/组播等多方面提出了许多措施。考虑到网络传输状况的多样性，本文重点讨论服务器端的数据传送调度控制，和并发服务的关键技术，尽可能地降低传输中的时延抖动问题，提高并发服务质量，文中最后给出了关键控制代码和测试结果。

1 信源数据的并发传输模型

并发连接对于网络视频应用来说，有别于以往的WEB页面式服务和FTP服务，每个视频数据流至少需要384kb/s的带宽甚至更高。同时传输服务还需要具有一定的余量，防止并发客户请求数达到峰值、或网络短期过载现象。因此合适的服务模型、良好的服务策略是优质服务的保障。对即时的影像流压缩与传输要求来说，在服务模型中还需要针对网络系统的资源限制条件，即网络带宽采取适应视频传输的策略，以便处理突发性事件。

另一个需要考虑的限制是服务器提供的并发连接数量以及等候处理的发送调用。因为并发连接数量越多，所消耗的未分页内存池也越多；等候处理的发送调用越多，被锁定的内存页面也越多，极易超过系统资源的极限。

1.1 服务器的视频传输服务特点

视频传输需要较宽的网络带宽，其视频的压缩编码、传输信道和网络协议的选择、IP组播技术对传输质量具有重要的影响作用。基于计算机网络连接的视频点播系统，其关键就在于多个站点视频的网络通信问题，要求做到传输时延尽可能小，尽可能少地占用现有的网络带宽，并具有较好的站点数量规模化特性。

视频服务器对于用户的请求，需要在较短的时间间隔内响应并传送所要求的视频数据，同时随时准备响应新的请求。因而视频服务器的性能直接决定系统的总体性能，为了能同时响应多个用户的服务请求，视频服务器需要调度服务。并具备接纳控制、请求处理、数据检索、按流传送等多种功能，提供实时、连续稳定的视频流，以确保用户请求获得有效服务。再者，视频服务器还需要提供交互服务，如快进和快倒等功能，因此视频服务器必须满足视频流特性使用中的各种要求。

1.2 服务器的并发服务技术

通常客户－－服务器间的通信过程首先是建立点到点的直接联系方式，因此服务器的负载能力决定了视频点播的并发容量。在客户机/服务器传输方式中，在面向连接的通信模式下，服务器需要打开监听端口，监听网络上其它客户机向该服务器发出的连接请求，当收到一个请求信号时与该客户机建立一个连接，之后两者进行交互式的通信。这在客户端请求较少，同时数据传输量不大的情况下传输延迟还可以忍受。

对于实时性要求较高的视频应用，一般采用无连接的通信模式。如MPEG-I按照1.5Mb/s传输在满足观看需要的情况下其帧数也要大于10帧以上。另外，当多个用户同时申请服务的时候，服务器建立连接分配资源等都需要产生延迟，也就是说对于用户的响应经过逐渐积累延迟会越来越大。如果请求池不足的话，那么就会产生客户的请求丢失。因此，同一时刻只能处理一个客户请求的循环服务器方式不适合视频点播。

如果采用并发服务方式[2]，在服务器端用主进程去监听客户机的连接请求，当有客户机的连接请求时通过创建线程的方式独立处理客户机通信，提高视频传输的实时性。

视频数据的并发传输，实质依赖于服务器中的传输线程，服务器的操作以建立相应的线程实现服务为目的，这种服务模式非常适合复杂的多任务请求。从计算机操作系统运行的角度来说，在典型的单处理器主机上，任务实际上并不是同时执行的。内核中称为调度程序的部分将工作换进换出，从而让所有工作都获得一轮执行。在同一个时间间隔内，并发模型常常基于事件的编程实现。

通常情况下，线程数量取决于应用程序的特定需要，理想情况下线程数量与处理器数量相当为好，虽然线程数量无法保证传输质量，但线程太少又会造成传输效率低，特别是用户数量较多的情况下更为明显。

从视频应用来说，影响视频传输性能的根本原因在于视频数据的连续传送和用户提交给服务器的请求无法及时响应，超过了网络资源节点容量或服务器的处理能力。这样就造成网络系统的数据包时延增加、丢弃概率增大、上层应用系统性能下降等。主要表现在以下几方面：

⑴ 并发连接数决定系统内存资源的消耗，并与CPU的处理能力密切相关。

⑵ 视频服务要求服务器尽快地把数据通过网络发送，尽量减少对连接请求的处理延迟，以免服务请求的重发和丢失。

⑶ 物理链路的实际承载能力也影响并发连接的处理能力。根据香农信息理论，任何信道带宽最大值即信道容量:

C=Blog2(1+S/N)（N为信道白噪声的平均功率，S为信源节点的平均功率,B为信道带宽）。所有信源节点发送的速率R必须小于或等于信道容量C。如果R>C，则在理论上无差错传输就是不可能的，所以服务器与网络的联结处会形成传输瓶颈。

⑷ 交换机或路由器的处理能力弱：如果路由器的CPU在执行排队缓存、更新路由表等功能时，处理速度无法与高速链路匹配，就会造成服务失效。

随着网络规模的扩大和用户数的激增，数据流传输更趋于频繁，线程数量不可能无限制增加。如果服务器和客户之间没有缓冲余地必然会出现丢弃数据包的情况。当数据包丢弃时，源节点端会超时、重传该包。由于没有得到确认，源节点端只能保留数据包，结果缓存会进一步消耗。因此，采用合理的算法与机制,按需分配传输线程占用的网络资源对于网络传输至关重要。值得指出的是，带宽保证是视频实时传输的基础，带宽如果完全均分，每个站点都得到总带宽的1/n（设存在n个站点），显然不能适应实际的带宽需求；因此，有必要根据重要性、实时性分配带宽使用的优先级，利用“流控技术”达到带宽管理的有效性、确保并发任务的顺利实施。

采用单播、广播和组播可以减轻服务器负担，也能提高并发数。组播的多点投递方式，使所有机器能够接收每个分组的同一拷贝减少了资源浪费。而常规的点对点通信方式下，N个视频站点的视频传输至少要重复发送N-1次相同的数据包，发送时延大，而且随着播放站点数量增长，时延就会迅速增长，这样就不能适应要求短时延的多点视频传输。

1.3 基于实时传输的协议机制

由于TCP需要较多的开销，它的重传机制和拥塞控制机制（Congestion Control Mechanism）不可避免地产生了传输延时和占用了较多的网络带宽，故不适合传输实时视频音频。在视音频的流式传输实现方案中，一般采用HTTP/TCP来传输控制信息，用RTP/UDP来传输实时声音数据。

实时传输协议RTP（Real-time transport protocol）[4]是用于internet上针对多媒体数据流的一种传输协议。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。通常利用低层的UDP协议对实时视音频数据进行组播（Multicast）或单播（Unicast）,从而实现多点或单点视音频数据的传输，当然RTP也可以在TCP或ATM等其他协议之上工作。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，而是依靠RTCP提供这些服务保证实时传输的操作。

实时传输控制协议RTCP(Real-time transport control protocol)和RTP一起提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTCP是RTP的控制协议，RTP和RTCP配合使用能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。

RTCP单独运行在底层协议上监视服务质量并与会话者传递信息，RTCP是由接收方向发送的报文，它负责监视网络的服务质量、通信带宽以及网上传送的信息，并将这些信息反馈给发送端，并提供QoS的检测，提供不同媒体间的同步信息和会话参与者的标识信息。

基于事件处理的多线程多缓冲区机制显得更胜一筹。但是当在广域网中进行视频数据传输时，此时的传输性能极大地取决于可用的带宽，由于TCP是面向连接的传输层协议，它的重传机制和拥塞控制机制，将使网络状况进一步恶化，从而带来灾难性的延时。同时，在这种网络环境下，通过TCP传输的视频数据，在接收端重建、回放时，断点非常明显，体现为明显的断断续续，传输的实时性和传输质量都无法保障。相对而言，采用RTP传输的视频数据的实时性和传输质量就要好得多。

2 并发服务的任务调度策略

面对越来越巨大的流应用需求，系统必须拥有良好的可伸缩性。随着业务的增加和用户的增多，系统需要灵活地增加现场直播流的数量，并通过增加带宽集群和接近最终用户端的边缘流媒体服务器的数量，增加并发用户的数量，不断满足用户对系统的扩展要求。

通常情况下一个视频流的播放准备需要的准备时间是比较长的。按照进程方式提供服务的话，如果不断接收到客户的请求，同时又不断地创建子进程处理，必然会影响客户的接收，其服务器并发数也大打折扣。因此，采用“预创建（prefork）”技术可以缓解这种情况的产生。服务器事先创建一定数目的子进程，每个子进程分别接受连接队列中已建立连接的客户连接。这样，就由子进程快速响应并处理客户请求。

并发与调度密切相关，如何分配任务给 CPU、如何调度任务直接影响到效率和可行性。效率较高的并发方法之一是“多线程”，也就是“线程化”。但线程化并不是唯一的并发构造，它的实现依赖于资源的可用情况并有一定的局限性。文献[5]中提到了多种可行的并发应用模型，除线程化外，还有多处理、协同例程和基于事件的编程，以及连续（continuation）、生成器和其它一些构造。

调度的任务就是合理划分时间片和循环执行各个线程，并能有效地监测线程阻塞和消除。每个线程都占用一部分CPU时间片，每个时间片上一个线程运行，另一个时间片又可能是另外的线程在工作。

根据视频流的传送要求，并发服务的优先级调度方式不适合专用于视频服务的工作，这会造成优先级高的视频流强占低优先级的视频流服务。因此，为了达到每个视频流服务的公平性，采用带有可变加权的循环调度。其循环顺序由申请服务的先后次序决定，以服务的时延最小进行调整控制，实现各个服务的最小允许延迟保证优质服务。

3 实现方案与测试验证

并发操作在同一时刻能够处理多个客户请求，从RTP/RTCP协议使用的角度来说，其实现方法也有多种，如服务器对每个接收到的客户连接创建一个线程处理；或者预先创建多个线程，由这些线程处理请求。

当然，使用多处理硬件更能较好地实现多任务的并发操作，特别是对于Linux使用多个处理器处理不同的线程时，并发效果要好的多。值得注意的是防止多个线程在单个处理器上造成瓶颈，而其它处理器却处于空闲状态，当然其它并发方法有时也会造成类似的问题。这方面有赖于操作系统的性能，对Linux 2.4来说其缺省的“内核线程”可以很好地调度线程，并将这些线程分配给不同的CPU。

3.1 实时传输的信息控制

线程建立通信连接关系后，根据RTP提供的时间信息实现流同步，通过RTCP反馈的信息进行数据流控制并动态调整传输率，保证数据延迟符合预定要求。

服务器监听端口，根据实际客户请求量确定请求队列的允许最大连接数目。

accept(客户请求)

｛ 提取并分析请求队列中的某一任务；

寻找具有相同视频信号标志的任务，使用组播技术设置ip地址由子进程处理播放；否则后置单位时间⊿t。处理时间⊿t的任务(Proc_Client())。｝

while(客户机与服务器成功连接——成功返回通信文件描述符)

{ CreateThread() //创建线程

{ 读出当前时间，并将当前时间写入通信文件描述符；

比较RTCP中资源信息与现有资源的差异，调整数据包发送大小和发送速度；如果子进程的数据传送完，则关闭通信文件描述符；反之，继续传送。}}

UDP层检查其目的端口（如果其UDP套接口已连接，也可能检查源端口），将数据报放到相应套接口的接收队列。如果需要，就唤醒线程，由线程读取这个新接收的数据报。

3.2 线程的调度控制

线程间通过互斥锁，实现循环控制，即在线程处理视频数据前通过互斥变量、信号灯加锁，主要代码如下：

sem_wait();

pthread_mutex_lock();

……

thread_next_flag=true;//设置下一个可执行线程标志

pthread_mutex_unlock();

sem_post();

为了实现有效的服务，需要保证视频数据流的传输具有相对的数据完整性。接收端常根据数据的到达情况通过RTP/RTCP协议的信息反馈，为服务器提供数据包接收情况的质量统计反馈信息和QoS检测的资料；对于接收端而言，数据的存放需要占用一定数量的缓存，以承受网络带宽波动，并在传输中增加一定冗余信息来重建丢失或受损的数据，减少数据重传。

按照上述策略，在Linux 9.0系统下编程实现了数据的传输，服务器的配置赛扬为2.0GHz,网卡为10/100M自适应。接收端为赛扬1.0GHz，网卡同样为10/100M，通过交换机互联。服务器预创建5个传输服务线程，图中为两个接收端的数据接收延迟情况，均传送2000个数据包，从统计的结果图来看，除了起始端出现较大的延迟外，延迟抖动均没有过大的变化。但在没有使用本文提出的调度控制的情况下，常常出现时延的急剧变化，即某一数据流出现了较大时延。

因此，本文的并发传输调度达到了使用要求，效果比较令人满意。

图1 多线程数据传送调度控制测试结果

4 结论

由于视频数据传输需要较大的数据吞吐量，容易出现网络丢包和延迟较大的情况，以致造成接收端视频抖动和明显滞后。视频数据传输时出现频繁抖动，最终影响视频的服务质量。

本文基于流媒体技术和并发调度方式，提出了视频传输的综合方案，利用多线程技术实现多点视频数据并发传输；利用调度控制技术实现以延迟抖动最小的服务。此外结合其它多路复用技术，分布式结构以及组播等方式可支持更多的连接,减少不必要的重叠发送，减轻系统和网络的负担，提高服务器CPU资源和网络带宽的利用率，对改善视频数据传输的实时性、并发性，实现网络视频的多点实时传输、网络多点实时监控等方面具有特别重要的实际意义。

参 考 文 献

[1] 胡道元.《计算机网络（高级）》. 北京：清华大学出版社，1999.8 P107。

[2] 张斌 高波等编着《Linux网络编程》北京：清华大学出版社，2000.1.1 P2-8。

[3] 钟玉琢.向哲.沈洪《流媒体和视频服务器》.清华大学出版社.2003.6.1

[4] RFC 1889,"RTP: A Transport Protocol for Real-Time Applications", 1996.1

[5]http://www-900.cn.ibm.com/developerworks/cn/linux/sdk/rt/part7/indexeng.htm

[6] RunTime: Synchronizing processes and threadshttp://www-900.ibm.com/developerWorks/cn/linux/sdk/rt/part5/index_eng.shtml

[7]http://www.douzhe.com/linux/13code/13067.htm