2、ONVIF协议介绍和在业务中的应用

1、为什么需要onvif

简单来说，推流盒子要支持不同厂家的摄像头，各家厂商的rtsp的url都不一样，每次接入一个新设备都需要按照各家的规定添加rtsp流地址，很麻烦, 测试、开发同学每次都有吐槽找流地址, 也好麻烦？怎么办？

我总不能在盒子的Web页面告诉盒子这个摄像头的厂家是哪个，然后程序了写死地址，这样太笨了，如果厂家的推流地址变了，那就完蛋了。所以ONVIF提供了一个标准的接口，来获取摄像头的推流地址，我不需要关心摄像头厂家和型号，这就很方便 目前我们重点需要的就是这个特性

2、什么是 onvif

嵌入式设备协议-ONVIF

为了做到通用，摄像头界出了个标准协议 ，取名为ONVIF（Open Network Video Interface Forum）翻译过来就是：开放型网络视频接口论坛。ONVIF标准将为网络视频设备之间的信息交换定义通用协议，包括搜索设备，实时视频，等。。。。。。。。。。

ONVIF规范描述了网络视频的模型、接口、数据类型以及数据交互的模式。对于基于 IP 的监控摄像机的通用通信接口的标准化方法给予了强有力的支持。

ONVIF协议将终端设备（摄像头）提供Web Service服务，将每一个功能看做一个Web Service，

比如，我要探测局域网中的网络摄像头，那么向摄像头提供控制功能相应的Web Service 的接口发送请求

比如，我需要获取流地址，查看网络摄像的的视频， 我的摄像头ip为10.122.101.86，知道这个地址后，我们就可以向这个地址提供的接口来获取相应的功能，每个接口可以认为一个功能，也就是一个Web Service，

3、工作流程

客户端（推流盒子）要知道终端设备（摄像头）的拉流地址，那么客户端就向终端设备提供的Web Service地址发送请求，然后终端设备给与回应，一问一答，就把事情做了，
一个流程如下图

工作起来是这个样子滴

4、技术实现

ONVIF概要设计.pdf

从大的方面来看有两种方案：

1、开源gSOAP实现

使用gSOAP通过ONVIF官网提供的WSDL文件生成框架代码，框架代码已经集成了网络收

发和XML解析，对于用户来说只需要对空的功能接口进行实现。

优点：对研发能力要求更低，开发周期更短。

缺点：gSOAP是针对所有webservice，所以框架代码比较臃肿庞大和复杂；框架代码中的

网络收发和XML解析没有很清晰的分层；ONVIF协议升级或gSOAP的修改合并比较麻烦，

并且开源gSOAP中的bug和安全漏洞会引入到系统中；gSOAP生成的框架代码遵循GPL协

议。

2、自研实现

分别对HTTP server、SOAP解析、组播和HTTP client进行实现即可。

优点：代码更加小巧可控；网络收发和SOAP解析可以清晰的分层，易于维护；ONVIF协

议升级对模块影响较小；

缺点：需要对协议有更加深入的理解，对研发能力要求更高，开发周期更长。

目前对于自研方案深圳的同学已经实现：Mini-Xml+GoAhead，这边对于libxml2+Megconnect前期

验证也已经通过，所以更倾向使用自研方案。Mini-Xml与libxml2相比更加轻量，体积更小，所以

计划实现方案为Mini-Xml+Megconnect(restful server、restful client、net)。对外业务功能接口与

Megconnect保持一致，这样对于已经集成Megconnect的产品稍做修改既可集成ONVIF协议。

5、业务使用

盘古v1.0.2 Onvif设备接入 概要设计评审

盘古v1.2.0 版本新增了onvif功能，理论上智能摄像机和网络摄像机 都支持onvif，但onvif是视频流协议，智能是处理抓拍的，所有目前盘古只有网络摄像机支持选择onvif协议

操作流程：添加设备时如果选择onvif协议，不需要填写rtsp协议，直接新增设备即可， 由aiot侧自己获取，在盘古侧调用aiot添加成功，反查aiot数据库获取rtsp流地址，回填数据库

优点：onvif协议解决了 接入设备是不清楚rtsp地址的问题，选择onvif接入的设备，用户不需要填写rtsp地址， 由aiot层通过 协议提供的接口，自动探测拼装，获取地址，盘古只需要回调填入即可，大大降低了添加设备难度

业务侧：
ip port:80 username password 必填