VC在网络实时传输中应用.docVIP

VC在网络实时传输中应用 　　摘要: 针对不同的网络环境,提出一种通用的实时视频传输的解决方案,使用VC++自封装的Windows VFW SDK软件开发包进行二次开发,通过Dive编解码,按照制定的传输策略,能够有效地解决由于网络的局部不稳定导致的视频图像重影、抖动、花屏等的问题。 　　关键词: VC++;实时传输;二次开发 　　中图分类号:TP3文献标识码:A文章编号:1671-7597(2010)0520129-01 　　 　　1 实时视频传输中的问题分析 　　由于我们设计的是实时视频的传输,不像视频文件的传输,考虑到延迟和实时性,在低带宽的网络情况下,需要有效的丢帧算法。在当前的实际应用中,很多的安防产品都是采用专门的DSP芯片来处理压缩视频,通过网络在远程实现对现场的实时监看。DSP本身一般采用实时性比较高的操作系统,如PSOS,VXWORK,嵌入式LINUX等。这些系统本身已经实现TCP/IP协议的库。 　　对于每一个视频压缩后需要实时传输到远程的监控端,必须考虑最小的延时,根据压缩后视频的数据特点,P帧的丢失对监看端的解码显示效果都会有不好的影响,而每一路的视频都有可能有不同的地方在同时监看,每一路监看连接的网络速度又可能各不相同。考虑到效率,数据在编码时放进一个公共的缓冲区,对于每一个发送的连接,都从该缓冲区中取数据,这就形成一个生产者――多个消费者的模型。 　　缓冲区是循环使用的,就是从头写到尾,再从头写入,假如发送过慢,有可能数据还没有发送完,就被新的视频覆盖,即使再申请一段缓冲区把数据保存下来,但假如发送速度小于视频数据的产生速度,那么终究会再产生这个问题,并且远程的监看延迟比较大。对于整个缓冲区,假定在写任务中定义写结束变量来标识写的位置,这样每个读任务都有读起始和读结束来标识。 　　在同一个视频通道上会同时有多个不同的客户连接,每个通道可能采用不同的协议传输。对于UDP和多播的发送方式,由于它们都不会阻塞发送的任务,多播的处理除了需要加入多播组,发送的地址是多播组的地址,其他的处理和UDP传输方式类似,所以每个视频通道只有一个UDP和多播的发送任务,而每个TCP传输,由于他们要阻塞发送的任务,所以每个发送均有一个独立的任务。 　　根据远程的视频请求,采用不同的协议实现视频的传输,在程序的架构上也是我们常说的CS(客户服务器)模式,每个发送的过程相互独立,根据带宽做最大化的发送,以达到客户端监看的最好的视频效果。 　　2 视频帧的发送 　　实时视频传输为了达到实时,要不断地将压缩好的数据发送到接受端。所以在发送端创建一个线程,专门用来发送数据。同时主线程仍然不停的采集数据并进行压缩。 　　不妨假设创建的线程名为sendThread,其核心代码实现如下: 　　while(1) 　　{isOK=true; //准备就绪 　　SuspendThread(sendThread); //挂起线程 　　isOK=false; //线程正在发送数据 　　int length=frameLength; //待发数据长度 　　if(length 50000) {//判断数据是否正常 　　int n=0; 　　int sendCount=0; 　　while(length 0) { 　　n=send(sock,(char*)imageBuf+sendCount,length,0); //发送数据, 　　//imageBuf是指针,指向待发数据帧 　　if(n==SOCKET_ERROR) //网络出现异常,则退出线程 　　break; 　　length-=n; 　　sendCount+=n;}}} 　　线程中发送的数据帧是按照上一节中的方法组建好的数据帧。这种方法能够保证正在发送的当前帧能够完整地到达接收端。 　　3 视频帧的接收 　　接收端最重要的是从接受的数据流中提取出完整的一帧。方法的思想是:首先从数据流中寻找帧开始标志,再从紧挨后面的数据中提取出帧的大小,然后再从接收缓冲区中读入该帧剩余的数据。再寻找下一帧的开始标志,如此往复。 　　同样接收端创建一个线程专门用来执行数据接收。不妨假设线程名为recThread,核心代码实现如下: 　　while(temp!=SOCKET_ERROR) 　　{if(!isStart) {//帧数据是否开始,true表示开始 　　if(endNum3) //endNum纪录当前接收未处理的数据 　　endNum=0; 　　temp=recv(clisock,(char*)(recBuf+endNum),1000,0);//从缓冲区读取数据 　　startPos=serchStr(temp+endNum);