利用VC++实现局域网实时视频传输
2010-07-06 20:43:44 来源:WEB开发网引言
在局域网内部实时传输视频已经得到广泛应用。现在用以传输视频的局域网大多数是有线局域网,因为有线局域网技术成熟,传输速度快,稳定性好。但是视频数据量大,有线网络也会出现工作不稳定,引起数据堵塞,时间久了会导致严重的延迟现象;如果工作的环境不固定,要求移动性,那么就要采用无线网络,如今无线网卡的工作随环境的变化而变得不稳定,这样会导致视频传输的质量大幅度下降,容易引起画面的重影、抖动、花屏等现象。本文针对不同的局域网,提出一种通用的实时视频传输的解决方案,使用VC++自封装的Windows VFW SDK软件开发包进行二次开发,通过Divx编解码,按照制定的传输策略,能够有效地解决由于网络的局部不稳定导致的视频图像重影、抖动、花屏等的问题。
局域网中实时视频传输存在的问题
为了在局域网上有效的、高质量的传输视频流,需要多种技术的支持,包括视频的压缩、编码技术,应用层质量控制技术等等。
网络的带宽是有限的,所以需要压缩传输视频图像,MPEG-4被广泛的应用于网络环境下的实时视频传输,因为MPEG-4具有:可以达到很高的压缩比;具有灵活的编码和解码复杂性;基于对象的编码方式,允许视频、音频对象的交互;具有很强的容错能力等优点。本文采用Divx编解码器对视频进行编码、压缩,实际上Divx=(视频)MPEG-4+(音频)MP3。
应用层质量控制技术现在采用的是RTP/RTCP协议,以确保视频流在网络中低时延、高质量地传输。RTP数据传输协议负责音视频数据的流化和负载,RTCP负责RTP数据报文的传输控制。此协议是通过客户端(接收方)反馈网络的状况,服务器端(发送方)来调整信息采集、发送的速度和压缩率。但是,对于图像采集速度固定,需要软件进行压缩、解压,调整采集的速度会引起采集的数据来不及压缩而直接丢弃,调整编码器的压缩率需要重新设置编码器的参数,重启编码器,相应的解码器也要调整,这个过程中需要很长的时间,达不到实时的要求。所以本文没有采用RTP/RTCP协议,而是从发送端出发,实时判断网络状况,采用“停等”策略进行实时传输。
网络通信有两种协议TCP和UDP,UDP更适合于网络环境下的视频传输,但是它不提供检错和纠错功能,一旦网络出现堵塞时,大量的数据报文会丢失。对于Divx编解码技术,是以帧为单位进行编解码的,分为关键帧和非关键帧。在传输过程中,由于压缩率比较高,只要一帧中错一比特位,将影响其它几百甚至几千的比特位,直接造成图像的模糊、花屏等现象。只有等到下一次关键帧的到来才有可能恢复图像的清晰。为了保证传输的正确性,自己需要在应用层制定协议。如此一来,UDP的优势荡然无存。所以本文选择使用TCP来进行网络通信。综合使用VFW技术、流媒体技术,辅助以“停等”控制策略,较好的解决局域网中实时视频传输容易引起的重影、抖动、花屏的问题。
实时视频传输实现
为了达到视频传输的实时性,总的思想是最少的发送冗余信息,最大程度上发送最新的视频。
局域网实时视频传输采用服务器/客户机模式,利用VC++实现。其工作流程如图1所示。
图1 实时视频传输工作流程
视频采集采用AVICap从视频采集卡捕获视频图像,得到的是位图型式的视频帧,然后用Divx编码器进行压缩,通过Winsock实现压缩后的视频数据在局域网中的实时传输,接收完的数据交给Divx解码器解压,最后实现视频显示。
在VC++中,采用VFW技术,客户端通过capSetCallbackOnFrame()注册回调函数,当采集卡采集到一幅图像后,系统就会自动调用回调函数,然后再回调函数中使用ICSeqCompressFrame()函数进行压缩。然后再通过Winsock将压缩后的数据发送到服务器端。服务器端接收完一帧以后,交给ICDecompress()解压,最后用SetDIBitsToDevice()将图像显示出来。
1、视频帧的组建
视频采集的数据是位图型式的视频帧,Divx编码器压缩以后形成以帧为格式的Mpeg4流。Divx解码器也是以帧的格式解压。所以提出以帧为单位发送视频数据流。为了在接收端能够方便地提取出一帧,提出如图2所示的格式组建帧。
帧开始标志 | 帧大小 | 帧编号 | 帧类型 | 帧数据 |
完整的一帧由5个字段组成,各个字段的意义如下:帧开始标志,标志着一帧地开始,占用4个字节的空间。不妨设为0xffffffff。帧大小,表示整个帧的大小,包括5个字段的大小,占用4个字节的空间。帧编号,表示帧的顺序编号,占用4个字节的空间。帧类型,标志此帧是否是关键帧,占用1个字节的空间。帧数据,存放压缩后一帧的完整数据。
更多精彩
赞助商链接