张茜
(武汉邮电科学研究院 湖北 武汉 430000)
现在随着网络技术和多媒体技术的不断发展以及网络技术和多媒体技术结合应用的不断深入,在互联网上传播图形、图像、音频、视频已经越来越广泛了。多媒体的应用具有连续性、实时性等特点,普遍对端到端的延迟和延迟变化比较敏感,但容许一定程度数据丢失。流媒体技术就是为适应这种多媒体在网络中的应用和发展而产生的,所谓流媒体就是在网络上流式传输的多媒体。
2008年安讯士、博世、索尼等三家公司共同推出了ONVIF协议。ONVIF网络视频协议的出现,解决了各类设备不能融合使用的难题,提供了统一的网络视频开发标准,即最终能够通过ONVIF这个标准化的平台实现不同产品之间的集成。本论文课题来源于实习过程中一个视频监控系统项目,目的是为了介绍ONVIF协议的是怎样规定和实现网络刻录机(NVR)与网络摄像头(IPC)之间媒体流的传输。在NVR与IPC进行媒体通信的过程主要存在的问题有:
1)NVR与IPC之间如何进行通信;
2)NVR与IPC之间进行媒体数据的传输需要进行什么准备;
3)媒体数据怎样在RTP上面进行传输;
4)RTP上面传输的媒体数据与H264的媒体数据的格式有何区别以及如何进行相互的转换。
Onvif协议由于采用WSDL+XML模式,使的其后续扩展不会遇到太多的麻烦。XML极强的扩展性与SOAP协议开发的便捷性将吸引到更多的人来关注和使用ONVIF规范。NVR的兼容与开放就显得非常迫切和必要了。通过ONVIF协议可以扩张NVR的开放和兼容,因为ONVIF的标准接口可以解决非标准化网络摄像机通过RTSP流媒体协议解决接入问题;ONVIF协议规定的视频编码技术,进一步促进了NVR与前端之间自由无阻的通信。
与此同时,一些基于ONVIF的NVR产品的开放性还开始向深度化管理延伸,从而让NVR与前端摄像机的互通不仅仅只停留在视频接入和浏览这一简单应用上,比如,通过NVR实现对第三方品牌摄像机进行告警、辅助开关、参数的系统设置以及系统升级、视频参数调节、3D定焦等[2]。
1)根据onvif协议确定中NVR与IPC对接的接口。通过接口的描述确定重要参数以及获取的方式,如果在参数获取失败则使用Onvif测试工具对问题进行定位。
2)理解RTSP的建立流程对对其进行实现,从而获取媒体流。
3)将媒体流进行解码,使得网络摄像头的图像可以显示在NVR的界面上。
以上的几个部分的实现都在NETCLIENT协议模块。NETCLIENT协议模块中建立一个ipcamera的单件对象,该对象处理所有与NVR系统相关的核心事件,派生出使用各种协议IPC的子对象负责IPC各事件的具体实现。rtsp_live对象负责调用Live555接口完成传输IPC中接收到的媒体数据。登录每个IPC都是一次完整的处理流程。
主要处理过程如图1所示。
图1 NVR与IPC通信主要流程Fig.1 NVR and IPC communication major processes
流程图如图2所示。
图2 NVR与IPC通信过程Fig.2 NVR and IPC communication process
文中采用gSOAP工具开发的0NVIF协议。接下来的工作是在描述基于gSOAP工具的0NVIF协议基础上,详细分析NVR和IPC之间预览功能的实现。
要实现对ipc的登陆,就需要正确获得ipc的登陆所需要的各项配置例如权限的获取,URL的获取,ipc媒体流的获取,还有ipc的媒体端口号,ip地址,以及时间。这其中较难获取的是ipc的配置以及uri的获取。当我们获取各项之后如果还不能登陆后者是有其他的问题,这时候我们就需要用ONVIF Device Test Tool这个工具来帮忙查看问题的所在。下面简单介绍一下登陆的几个部分[3]。
1)根据IPC的不同其登陆的代码也有所不同主要体现在其是否需要获取权限,无论是否需要获取权限,最重要的部分是:通过onvif协议中的soap_call___tds__GetCapabilities函数我们可以获得gcsr结构体中的信息保存到设备中,其中最主要的是信息如IPC是否支持媒体或者是云台等信息,并且获得媒体的url。
2)在成功获得IPC的各种Capabilities的基础上,可以进行获取配置文件。通过soap_call___trt__GetProfiles函数我们可以得到struct_trt__GetProfilesResponse结构体中的信息数据。
Uri是统一资源标识符(Uniform Resource Identifier)它不仅对于视频的播放很正要,我们还可以通过VLC播放器播放该uri的视频信息,以此确认视频断开的原因来自于哪一方,提高在NVR上面视频传输的可靠性和实时性[4]。
RTSP是基于文本的协议,采用ISO 10646字符集,使用UTF-8编码方案。行以CRLF中断,但接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。
请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护[5]。
1)第一步:查询服务器端可用方法并且建立TCP的socket的连接
设备->IPC:OPTION request
IPC->设备:OPTION response
2)第二步:得到媒体描述信息
设备->IPC:DESCRIBE request
IPC->设备:DESCRIBE response
3)第三步:指定流式媒体的传输机制
设备->IPC:SETUP request
IPC->设备:SETUP response
4)第四步:请求开始传送数据
设备->IPC:PLAY request
IPC->设备:PLAY response
5)第五步:数据传送播放中
IPC->设备:发送流媒体数据
6)第六步:关闭会话,退出
设备->IPC:TEARDOWN request
IPC->设备:TEARDOWN response
上述的过程只是标准的、友好的rtsp流程,但实际的需求中并不一定按此过程。其中第三和第四步是必需的!第一步,只要服务器客户端约定好,有哪些方法可用,则option请求可以不要。第二步,如果我们有其他途径得到媒体初始化描述信息(比如http请求等等),则我们也不需要通过rtsp中的describe请求来完成。
IPC的数据是经过H264进行编码,为了可以在RTP上面进行传输,是需要把编码后的数据放到RTP包中进行传输的也就是将H.264视频中剥离出每个NALU,在每个NALU前添加相应的RTP包头,然后将包含RTP包头和NALU的数据包发送出去。H.264媒体数据通过RTP的发送过程如下,接收过程相反:RTP协议从上层接收流媒体信息码流H.264,封装成RTP数据包通过UDP协议发送到客户端,客户端将RTP数据包中NALU进行解析让后放入解码器中进行解码即可对媒体流进行播放了。
文中是在onvif 2.3.0协议基础上进行架构的,在调试过程中运用onvif测试工具12.12对于NVR和IPC互通中出现的问题进行分析。根据NVR设备最终的显示的图像画面说明了关于NVR和IPC的媒体流传输问题,通过ONVIF协议就可以完成。文中证明了ONVIF协议对于实现NVR和IPC媒体流传输的有效性。
[1]潘熠.视频录像在监控系统的发展趋势[J].中国安防,2009(5):53-55.PAN Yi.Video footage in the monitoring and control system[J].The Development Trend of China′s Security,2009(5):53-55.
[2]杨剑锋.多通道数字硬盘录像机的设计与实现[D].辽宁:大连理工,2009.
[3]杨建全,梁华,王成友.视频监控技术的发展与现状[J].现代电子技术,2006(21):11-13.YANG Jian-quan,lIANG Hua,WANG Cheng-you.Video monitoring technology development and the status quo of[J].Journal of Modern Clectronic Technology,2006(21):11-13.
[4]西刹子.安防天下—智能网络视频监控技术详解与实践[C].北京:清华大学出版社,2010.
[5]王永嘉.监控系统-客户端设计与实现[D].浙江:浙江大学,2009.
[6]尹磊.多媒体终端的设计与实现[J].科学技术与工程,2010(22):33-34.YIN Lei.The design and implementation of multimedia terminal[J].Science,Technology and Engineering,2010(22):33-34.