为什么要搞ONVIF
最近在做一个视频推流的项目，其中去要获取摄像头的视频流，开始什么也不懂，在网上查资料，原来是使用ffmpeg通过一个叫url的东东来拉去视频流，当时一脸懵逼，开始看ffmpeg教程，完全是靠雷神的博客入门，向雷神致敬。但是之后，项目为了做到通用，兼容不同厂家的摄像头，查了一下，各家的rtsp的url都不一样，这怎么搞，又一脸懵逼。查资料吧，找到原来摄像头界有个标准协议，叫ONVIF，刚搞明白ffmpeg，ONVIF又是什么鬼。头疼。继续学啊，都是被逼的。不扯废话了，开始正题
什么是ONVIF
Onvif，即Open Network Video Interface Forum ，可以译为开放型网络视频接口论坛，是安迅士、博世、索尼在2008年共同成立的一个国际性、开发型网络视频产品标准网络接口的开发论坛，后来由于这个技术开发论坛共同制定的开发型行业标准，就用该论坛的大写字母命名，即ONVIF 网络视频标准规范，习惯简称为：ONVIF协议。
Onvif协议的出现，解决了不同厂商之间开发的各类失败不能融合使用的难题，提供了统一的网络视频开发标准，即最终能够通过Onvif这个标准化的平台实现不同产品之间的集成。
那么问题来了，ONVIF到底是什么，怎么工作的，原来ONVIF协议将终端设备（摄像头）提供Web Service服务，将每一个功能看做一个Web Service，比如，我要探测局域网中的网络摄像头，那么向摄像头提供相应的Web Service 的接口发送请求，我不是做网页的，刚开始这个概念没理解清楚，其实就是每个摄像头提供一个网址，比如淘宝网页，我们都知道，要想访问淘宝，就得在浏览器的地址栏输入淘宝的网址，https://www.taobao.com/，获取到主页后，就可以为所欲为了（只要你有钱）。ONVIF也一样，首先获取摄像头的主地址比如（http://10.0.0.47/onvif/device_service），我的摄像头的IP为10.0.0.47，获得这个地址后，我们就可以向这个地址提供的接口来获取相应的功能，每个接口可以认为一个功能，也就是一个Web Service
ONVIF规范的实现机制
Web Service是基于网络的、分布式的模块化组件，执行特定的任务。Web Service 主要利用 HTTP 和 SOAP 协议使数据在 Web 上传输。Web 用户能够使用 SOAP 和 HTTP通过 Web 调用的方法来调用远程对象。
客户端根据 WSDL 描述文档，会生成一个 SOAP 请求消息，该请求会被嵌入在一个HTTP POST请求中，发送到 Web Services 所在的Web 服务器。Web Services 请求处理器解析收到的 SOAP 请求，调用相应的 Web Services。然后再生成相应的 SOAP 应答。Web 服务器得到 SOAP 应答后，会再通过 HTTP应答的方式把信息送回到客户端。
WSDL 描述文档
WSDL 是Web Service的描述语言（Web Service Description Language）的缩写，是一个来描述Web服务器和说明如何与Web 服务器通信的XML语言。为用户提供详细的接口说明书。
构建SOAP消息
SOAP是Simple Object Access Protocol的缩写。是基于XML的一种协议。一条 SOAP 消息就是一个普通的 XML 文档，包含下列元素：
- 必需的 Envelope 元素，可把此 XML 文档标识为一条 SOAP 消息
- 可选的 Header 元素，包含头部信息
- 必需的 Body 元素，包含所有的调用和响应信息
- 可选的 Fault 元素，提供有关在处理此消息所发生错误的信息
下面我们看一个SOAP消息
<?xml version="1.0" encoding="utf-8"?>
<Envelope xmlns="http://www.w3.org/2003/05/soap-envelope" xmlns:tds="http://www.onvif.org/ver10/device/wsdl">
<Header>
<wsa:MessageID xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">uuid:8db8f280-2d52-4955-8c76-fd4a0f1d30ef</wsa:MessageID>
<wsa:To xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">urn:schemas-xmlsoap-org:ws:2005:04:discovery</wsa:To>
<wsa:Action xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</wsa:Action>
</Header>
<Body>
<Probe xmlns="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Types>tds:Device</Types>
<Scopes/>
</Probe>
</Body>
</Envelope>
在向Web Service发送的SOAP请求中，Body元素中的字段需与WSDL中数据类型的相符合。在构建SOAP的过程中，必须从WSDL文件中获取并映射这一种对应关系。然而这样一个对应过程将是充满了重复性和机械性的，为了避免不必要的人工差错以及节约开发时间，一个名为gSOAP的编译工具应运而生。
gSOAP利用编译器技术提供了一组透明化的SOAP API，并将与开发无关的SOAP实现细节相关的内容对用户隐藏起来。通过将WSDL文件解析序列化为C/C++文件，最小化了Web Service的开发过程。
Web Service与视频监控
ONVIF规范向视频监控引入了Web Service的概念。设备的实际功能均被抽象为了Web Service的服务，视频监控系统的控制单元以客户端的身份出现，通过Web请求的形式完成控制操作。
Web Service能为视频监控什么
a) 设备的无关性，任何一个设备接入系统，不会对其他系统造成影响。
b) 设备的独立性，每一个设备只负责对接收到的请求做出反馈，甚至不需要知晓控制端的存在。
c) 管理的集中性，所有的控制由客户端来发起。
ONVIF规范能为视频监控带来什么
a) 抽象了功能的接口。统一了对设备的配置以及操作的方式。
b) 控制端关心的不是设备的型号，而是设备所提供的Web Service。
c) 规范了视频系统中Web Service范围之外的行为。
d) ONVIF提供了各个模块的WSDL，拥有效率非常高的开发方式。
一个流程
客户端（推流盒子）要知道终端设备（摄像头）的拉流地址，那么客户端就向终端设备提供的Web Service地址发送请求，然后终端设备给与回应，一问一答，就把事情做了。
一个流程如下图
ONVIF的功能
按项目需求来说，推流盒子要支持不同厂家的摄像头，但是不同厂家的摄像头的拉流地址又不同，怎么办，我总不能在盒子的Web页面告诉盒子这个摄像头的厂家是哪个，然后程序了写死地址，这样太笨了，如果厂家的推流地址变了，那就羊驼了。所以ONVIF提供了一个标准的接口，来获取摄像头的推流地址，我不需要关心摄像头厂家和型号，这就很方便。这仅仅是我们项目上的一个小小需求。下图罗列了部分ONVIF提供的接口
接下来说说流程
- 发现设备
- 获取能力
- 获取媒体信息
- 获取视频编码配置
- 设置视频编码配置（修改视频流设置信息，码流，分辨率，编码格式）
- 获取URI
- ONVIF完成
- 使用ffmpeg推拉流
over
下面左边图为传统视频监控系统的一个局域网应用场景
- PU设备上线后，向CMU注册，建立连接
- CMU与PU进行信令交互，请求能力集，获取配置
- CU上线，向CMU注册，建立连接
- CMU与CU进行信令交互，传输设备列表
- CU向PU请求码流
右图：
- PU设备上线后，向CMU发送HELLO消息
- CMU需要搜寻设备时，向PU发送PROBE消息
- CMU与PU进行信令交互，请求能力集，获取配置
- CU上线，向CMU注册，建立连接。
- CMU与CU进行信令交互，传输设备列表
- 在CMU的协调下， CU同PU建立连接传输码流
在上述的场景中，通过ONVIF，PU与CMU的交互方式发生了改变；CMU不再与PU保持长连接。遵循ONVIF规范，信令以及消息内容有了统一的标准
名词解释
-
CMU（Center Manager Unit），即中心管理单位。
-
PU（Prefocus Unit），即监控前端单元，负责在CMU的控制下使用摄像机采集视频流、使用麦克风采集音频流、使用控制口采集报警信息、对摄像机云台镜头进行控制。
-
CMU+PU ——服务器(如：安防相机)
-
CU（Client Unit），监控系统的监控客户端单元，负责将PU采集到的视频流、
扫一扫
8452
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
