基于关键帧提取技术的网络视频监控系统

应用背景

由于宽带网络近年来在世界各地的高速发展，高品质的音视频压缩技术不断推陈出新，更高的压缩比率加上更宽的带宽，使得互联网用户在互联网上观看高品质电视节目的愿望不再是幻想。美国、意大利、法国、加拿大等国网络视频市场的日渐成熟，国内哈尔滨、泉州、上海等地的小试牛刀，都证明了以更强的互动性作为卖点、基于互联网技术和P2P传输技术的网络视频服务已经渐成气候。

网络视频是对基于互联网技术传播的所谓宽带视频的统称，可以是用户自己制作、在线上传或点播视频节目，自主性和自助性强。各种视频网站和流媒体服务器随着人们对网络视频服务的需求快速增长，民营网络视频企业更是如雨后春笋。

2007年是网络视频用户基数迅速成长的一年。据CNNIC今年1月份发布中国互联网调查报告，76.9%的网络用户使用网络视频，成为继音乐、即时通信之后的第三大互联网应用。这也是网络家庭娱乐应用第一次全面超过了网络商务应用，即邮件、搜索引擎和新闻等传统资讯应用。

但随着网络视频的高速成长，各种黄色、暴力和反动等垃圾信息也掺杂在网络视频中在宽带网络上肆意泛滥，严重影响了人们的正常工作和生活，也对社会精神文明建设和未成年人教育带来了巨大的隐患。

由于宽带视频网络的高速数据包传送，传统的信息安全监控设备在这方面显得力不从心，因此，我们提出应用关键帧提取技术来抽取网络视频中的关键帧，从而减小处理的负载和存储空间，降低设备成本并提高处理效率。建立相应的垃圾视频关键帧匹配库，通过视频关键帧匹配算法和模式，从高速的视频流中监测出垃圾信息。应用此视频监控系统和其他网络安全设备，可以为企业、学校和家庭打造一个高速干净的网络视频环境，让人们轻松尽情享受宽带视频服务。

系统方案

1.视频解码方案论证

方案一：利用Xilinx公司的FPGA产品Spartan 3E实现系统的视频解码。在Spartan 3E支持的MicroBlaze微处理器软核上移植开源视频解码器，由于MicroBlaze最高处理频率为50MHz，远不能满足现在的高速视频数据包的解码;

方案二：通过在最新嵌入式微处理机eBox-4300上移植嵌入式操作系统WinCE来实现开源视频解码器。eBox处理器主频为500MHz，可以满足10/100MHz网络的视频解码，且在eBox上的WinCE操作系统可移植性较好，便于以后在系统中加入更多的视频格式解码器。

2.数据包前端处理方案论证

方案一：利用Xilinx公司FPGA产品系列Spartan 3E来捕获网络中的视频数据包。高速的逻辑结构和并行特性是FPGA的特性，通过FPGA来识别并捕获视频数据包能降低系统的丢包率和漏报率;

方案二：利用eBox-4300自带的以太网接口直接连接到网络上。由于WinCE操作系统下的以太网操作已封装好，为了兼顾可移植性，因此其效率没有直接在FPGA上实现的IP核好。

3.关键帧匹配方案论证

方案一：利用Xilinx公司的FPGA产品系列Spartan 3E来实现视频关键帧标准库的查找和匹配。由于FPGA特有的存储单元结构，便于快速查找。

方案二：利用ADI公司的Blackfin 535数字信号处理器来实现视频帧的匹配算法。DSP特有的快速音视频处理能力能很好满足系统的性能要求。但Blackfin的片上存储空间有限，如果增加外部存储器将降低关键帧查找速率，从而成为整个系统的瓶颈。

综合上述：系统采用Xilinx公司的FPGA产品系列Spartan 3E来作为数据包前端处理，识别并捕获相应格式的网络视频数据包，按序列将视频数据包传送到eBox-4300处理器上的视频解码单元。在eBox-4300处理器上抽取出视频的关键帧后，将视频关键帧传送到在Spartan 3E上实现的关键帧匹配单元中进行匹配模式检验。

图 1 系统示意图

实现原理

1. 视频数据包识别捕获

实时流协议RTSP是一个应用层协议，用于控制具有实时特性的数据如多媒体流的传送。为多媒体数据流提供远程控制功能，如播放、 停止、快进等。该协议支持以下操作：

1. 从媒体服务器上获取媒体;

2. 邀请媒体服务器加入会议;

3. 在一个已存在的演示中加入新的媒体流。

RTSP协议一般与RTP/RTCP和RSVP等底层协议一起协同工作，提供基于Internet的整套的流服务。它可以选择发送通道如UDP、组播UDP和TCP和基于RTP的发送机制。它可以应用于组播和点播。

RTSP协议负责在服务器和客户端之间建立并控制一个或多个时间上同步的连续流媒体，其目标是像HTTP协议为用户提供文字和图形服务那样为用户提供连续媒体服务。因此，RTSP协议的设计在语法和操作上与HTTP协议很相似，这样，对于HTTP的大部分扩展也适用于RTSP。但是RTSP协议和HTTP协议在很多方面有着区别：

1. HTTP是一个无状态协议，而RTSP协议是有状态的。

2. HTTP本质上是一个非对称协议，客户端提出请求而服务器响应;而RTSP是对称的，服务器和客户端都可发送和响应请求。

在RTSP中，每个演示及其所对应的媒体流都由一个RTSP URL标识。整个演示及媒体特性都在一个演示描述文件中定义，该文件可能包括媒体编码方式、语言、RTSP URLs、目标地址、端口及其它参数。用户在向服务器请求某个连续媒体流的服务之前，必须首先从服务器获得该媒体流的演示描述文件以得到必需的参数，演示描述文件的获取可采用HTTP、Email或其他方法。

RTSP中的所有的操作都是通过服务器和客户方的消息应答来完成的，其消息包括请求和响应两种，RTSP正是通过服务器和客户端的消息 应答来完成媒体流的创建、初始化、VCR控制以及拆线等操作的。在基于客服端/服务器结构的分布式视频点播系统中，RTSP协议的操作过程如下所示：

图 2 基于RTSP的流媒体服务器

客户机在向视频服务器请求视频服务之前，首先通过HTTP协议从Web服务器获取所请求视频服务的演示描述文件，利用该文件提供的信息定位视频服务地址包括视频服务器地址和端口号，及视频服务的编码方式等信息。然后客户机根据上述信息向视频服务器请求视频服务。视频服务初始化完毕，视频服务器为该客户建立一个新的视频服务流，客户端与服务器运行实时流控制协议RTCP，以对该流进行各种VCR控制信号的交 换，如播放、暂停、快进、快退等。当服务完毕，客户端提出拆线请求，需要说明的是，服务器使用RTP/UDP协议将媒体数据传输给客户端，一旦数据抵达客户端，客户端应用程序即可播放输出。在流式传输中，使用RTP/RTCP/UDP和RTSP/TCP两种不同的通信协议在客户端和服务器间建立联系。