视频管理软件技术分析报告(三)--VMS软件支撑技术分析

1. 通信协议

IP视频监控系统涉及的主要通信协议包括:

  •  UDP:提供面向事务的简单不可靠信息传送服务。
  •  TCP: Transmission Control Protocol 传输控制协议TCP是一种面向连接(连接导向)的、可靠的、基于字节流的传输层(Transport layer)通信协议。
  •  SIP:是应用层的会话控制协议,用于创建、修改和释放一个或多个参与者参加的会话,采用基于文本格式的客户/服务器模式,基本功能包含:用户定位(定位设备、客户端),用户能力协商(了解能力集),用户可用性确定(定位设备、客户端是否在线),会话建立(建立视频流),会话管理(管理视频流)。
  •  SDP:是会话描述协议,用于为SIP、RTSP、HTTP等协议描述会话信息。
  •  RTP:(Real-Time Transport Protocol,实时传输协议)是一个传输层的、基于UDP的协议。被用来为音视频等实时数据提供端到端的网络传输,传输的模型可以是单点传送或是多点传送。
  •  RTCP:RTP并不保证服务质量,也没有提供资源预留。可以通过控制协议RTCP的补充来实现大规模业务时对传输数据的监视功能。并通过RTCP提供一些控制和识别流的功能。RTCP协议规定,源和目的之间需交换多媒体信息的报告报文。报告包含发送包的数目,丢失的数目,抖动间隔时间等信息。用来修正发送者的发送速率以及信息诊断。
  •  iSCSI:是基于IP协议的存储技术标准,是SCSI协议的一种,主要由RFC3720描述。iSCSI 发送端将SCSI命令和数据封装到 TCP/IP 包中再通过网络转发,接收端收到 TCP/IP 包 之后,将其还原为SCSI命令和数据并执行。整个过程在用户看来,使用远端的存储设备就象访问本地的 SCSI设备一样。
  •  RTSP:(Real Time Stream Protocol,实时流媒体协议)是TCP/IP协议体系中的一个应用层协议,定义了如何有效地通过IP网络传送多媒体数据,类似一个多媒体播放设备的网络遥控器。

2. 视频接入方式

2.1. GB28181

GB/T 28181是目前国内安防视频监控联网系统中使用比较广泛的标准,目前最新的标准版本为GB/T 28181-2016。
  GB/T 28181标准定义了公安视频监控系统的系统模型,定义了一个基于SIP监控域的联网模型(互联与级联),如图 1所示。


图1

  GB/T 28181中定义的通信协议结构如图2所示:


图2

  GB/T 28181定义了MANSCDP(SIP信令中包含XML定义的消息体)用于完成对设备,文件,告警等对象的管理。GB/T 28181基于SIP协议实现媒体流的实时点播和历史点播,支持客户端主动发起和第三方呼叫控制两种方式。
  VMS使用GB/T 28181不仅可以接入视频,还可以完成对管理设备的信息查询、配置和控制(如PTZ控制)。GB/T 28181利用SIP协议的注册机制完成接入设备的注册和定位,因而在VMS中SIP服务器实质上是VMS中的CMS。

2.2. ONVIF

2008年5月,由安讯士联合博世及索尼公司三方宣布将携手共同成立一个国际开放型网络视频产品标准网络接口开发论坛,取名为ONVIF(Open Network Video Interface Forum,开放型网络视频接口论坛),并以公开、开放的原则共同制定开放性行业标准。2008年11月,论坛正式发布了ONVIF第一版规范——ONVIF核心规范1.0,截止目前,最新的ONVIF接口定义版本为16.12(2015年12月的版本还是2.61,2016年6月的下一个版本就变为16.06,依此推断ONVIF的版本是用发布的年和月来定义了。) 。商业产品中使用较广泛的是2.0版本。
  ONVIF定义了四种典型设备:NVD(Network Video Display)、NVA(Network Video Analytics)、NVT(Network Video Transmitter)、NVS(Network Video Storage),并对这四种类型典型设备的服务进行了定义。
  ONVIF规范主要由一系列的服务接口定义组成,这些定义基于Web Service标准规范,使用WSDL和XML Schema表示。
  使用ONVIF定义的服务器接口,兼容ONVIF定义的设备能够方便的接入到VMS中。与28181协议相比,ONVIF弱化了监控平台的定义。
  ONVIF使用Profile来定义设备的兼容能力,目前已经发布的Profile有A,Q,C,G,S系列。
  ONVIF的服务定义比较系统地定义了视频监控系统中对于设备的管理与控制,因此使用SOA思想(或microservice)的VMS在设计时可以充分参考ONVIF的服务定义思想。
  ONVIF的规范实现依赖于W3C定义的系列Web Service标准规范,Web Service标准规范在服务发现、事件通知等机制上设计较为复杂,对于实时性要求较高的场景可能在效率上不能满足要求。

2.3. Webrtc

WebRTC,名称源自网页实时通信(Web Real-Time Communication)的缩写,是一个支持网页浏览器进行实时语音对话或视频对话的技术。
  WebRTC最终目的主要是让Web开发者能够基于浏览器(Chrome\FireFox...)轻易快捷开发出丰富的实时多媒体应用,而无需下载安装任何插件,Web开发者也无需关注多媒体的数字信号处理过程,只需编写简单的Javascript程序即可实现,W3C等组织正在制定Javascript 标准API,目前是WebRTC 1.0版本 。
  WebRTC在两个浏览器之间通过交换SDP信息来交换两端的媒体元数据信息,基于Offer/Answer的媒体会话模型 。
  WebRTC的工作模式非常简单,如图 3所示:


图3

  两个浏览器基于同一个Web Server(信息服务器)完成彼此之间媒体会话信息(SDP参数)的交换,就能够建立起媒体会话,完成媒体流的传输交换。
  WebRTC的开发模型如图 4所示:


图4

   WebRTC定义了一套使用JS描述的WebRTC API,开发者使用所支持浏览器提供的这些API完成媒体的获取,媒体会话参数的获取,信息的发送等工作。
   与传统的流媒体开发API相比,WebRTC API屏蔽了更多的细节(如网络端口,地址等信息),做到了开发的简洁性。
  WebRTC的核心技术是网络连接的建立,及ICE技术。每个端点能够根据所处的网段,机器信息生成一个IceCandidate的集合(每个IceCandidate实则是一个媒体流的端点地址),两个端点通过交换彼此的IceCandidate集合,可获知对方的媒体流可达地址,从而建立连接(IceCandidate被划为不同优先级,优先级高的地址先被尝试连接)。WebRTC可以使用STUN和TURN技术实现媒体流的中转。
  虽然WebRTC设计的初衷是想实现在两个浏览器之间交换视频流,不需要流媒体服务器。但在VMS设计中,常实现一个WebRTC服务端作为类流媒体服务器,向浏览器提供采集自前端的实时视频流,这样在浏览器侧可实现无插件的流媒体实时播放。需要注意的是,浏览器支持的视频编码格式是有限的,必要时需要服务端转码。

3. 视频存储

3.1. 存储方式与格式

视频存储使用的存储介质通常为磁盘阵列。在视频监控系统中,主机访问存储的方式有:DAS,NAS,SAN,FC SAN和IP SAN。
  随着VMS软件管理规模的不断扩大化和联网需求的不断增长,FC SAN和IP SAN两种访问存储方式成为目前常用的访问存储方式。
  在视频存储方式上,视频流直写存储(Central Video Recorder ,CVR存储)方式成为视频监控设备厂家常用的方式。
  CVR存储方式下把录像软件嵌入到存储设备中,视频流数据由DVR或IPC通过流媒体协议直接写入存储,降低了客户使用成本,也提高了性能和可靠性,如图 5所示。
  CVR存储无需部署存储服务器,视频数据从前端编码设备直接写入存储设备,数据传输协议支持主流的流媒体协议(如RTSP/ONVIF/PSIA等)和GB/T28181规范;支持VMS直接调取,架构简化而开放,空间自我管理,可独立组网。


图5

  在视频存储格式上,“基于文件的存储”与“基于块的存储”是目前视频存储主要使用的两种格式。
  图 6展示了“基于文件的存储”模型。


图6

  图 7展示了“基于块的存储”的存储模型。
图7

  与“基于文件的存储”模型相比,“基于块的存储”的存储模型具有效率高,查询快等特点。但使用“基于块的存储”的存储模型在海量存储场景下需要配套的数据库系统用以管理数据块索引。

3.2. 云存储

随着分布式存储技术的发展,越来越多的视频监控设备厂商推出了各自的云存储产品。
  视频监控系统中使用云存储设备的一个典型应用场景如图 8所示:


图8

  视频监控平台根据业务需求为各前端摄像机下发录像计划,视频云存储系统根据当前系统内的业务负载情况分配具体的存储空间,前端摄像机推送视频数据流直写到分配的存储设备上。同CVR存储模式一样,视频云存储数据传输协议支持主流的流媒体协议(如RTSP/ONVIF/PSIA等)和GB/T28181规范,支持平台直接调取。
  根据对元数据的管理模型,可以将通用云存储系统分为三种类型,即集中式元数据、分布式元数据和无元数据三种类型的系统。
  集中式元数据云存储系统是一种典型的主从结构系统,在系统中,通常具有一个中央元数据管理服务器,负责元数据的存储和处理查询与修改请求。目前业界采用这种架构的系统主要有HDFS等。
  分布式元数据云存储系统采用多台元数据服务器形成集群工作的方式提供元数据访问服务,集群中的每一台设备都可以提供元数据访问,从而提高整体访问性能,并且规避单点故障问题。
  无元数据云存储系统则彻底抛弃元数据,采用算法来对文件或对象进行定位,并将该算法集成在每一个存储节点上,客户端从任何一个存储节点进行数据访问都会获得同样的结果,云存储系统中的每一个存储节点都可以独立、并行地对外提供服务,从而真正实现性能随节点数增加而线性扩展 。MAPR公司对于HDFS的扩展存储产品号称使用这一架构。

3.3. 分层存储策略

分层存储策略常常能够提升系统操作效率。一个智能的VMS系统需要提供融合多种存储技术和媒体类型的统一方法来提升效率。图 9显示了一个智能的,可伸缩的分层存储架构 。


图9

  智能可伸缩的分层存储架构支持所有视频监控数据的统一访问:

  • Primary disk:存放最近,被频繁访问的数据。
  • Secondary disk:提供较多容量,存放较为频繁访问的数据。
  • File based tape:提供更多的容量,存放系统中不常被访问的数据。
  • Cloud storage:用于离线存储,复制系统内的数据。

3.4. 流媒体分发体系结构

流媒体业务作为视频监控系统的重要一环,流媒体分发是VMS设计时需要考虑的关键技术(本节内容主要引用文献1)。流媒体分发体系结构被分为四类 :

  • C/S分发体系结构:C/S模式由单一服务器提供资源,存在单点失效问题,服务器成为系统的性能瓶颈,无法满足大规模应用的需求。C/S体系结构中流媒体分发的优化目标是减轻服务器的负担,为尽可能多的用户提供尽可能好的流媒体服务。使用的主要优化技术包括网络优化技术、编码技术以及服务器优化技术。
    网络优化技术包括IP组播技术,实时流媒体传输协议、流控协议以及差错控制协议等研究。
    流媒体对传输速率敏感,必须通过流控协议保证媒体的实时需求,流控协议可以分为单播速率控制和组播速率控制两类。
    差错控制协议主要控制数据包丢失对流媒体应用的影响,数据块交错(interleaving)封装是一种差错控制方法,它将数据块交错封装到不同的数据包中,避免一个数据包丢失则连续多个数据块丢失而导致播放质量明显下降的情况。
    服务器优化技术主要包括基于存储的代理缓存技术和基于合并的优化技术。代理缓存把本地最近访问过或最经常访问的内容保存在代理服务器上。合并优化技术的原理是避免为一个请求单独提供下载频道,将多个请求合并到少数频道上。
  • CDN分发体系结构:CDN在网络的边缘部署多个代理(surrogate)服务器,并将源服务器上的内容发布到各代理服务器上,用户对内容的请求被重定向到最近的代理上,从而提高服务响应速度。与C/S相比,CDN能提供稳定可靠的高质量的流媒体分发能力。但从服务容量上看,CDN的服务能力等于部署的代理服务器的服务容量总和,为了满足用户访问需求,往往需要按照访问峰值来设计和部署代理服务器,成本太高;分布式部署方式也增加了网络的管理、运维成本。
  • P2P分发体系结构:P2P是对客户端能力的增强方式。P2P体系结构下节点既是资源请求者也是资源提供者。通过动态地整合节点有限的资源来分担本由服务器独立承担的服务,系统节点规模和服务能力能够同步增长。P2P技术的研究主要集中在下面几个方面:
    拓扑一致性:P2P是构建在物理网络之上的覆盖网络,覆盖网上逻辑相邻的节点在物理网络上可能相隔很远,这种拓扑不一致往往给网络带来大量不必要的带宽消耗。因此,覆盖网构建时必须尽量选择在同一ISP网内的节点作为邻居。
    NAT/防火墙:P2P的扩展能力来自于节点的资源共享。在流媒体分发中普遍采用拉的数据交换方式,NAT/防火墙后面的节点无法建立连接的请求。为解决NAT带来的共享困难问题,大部分的研究集中在适合P2P分发的NAT穿越算法上。
    网络扰动:节点频繁加入或退出覆盖网的现象称为网络扰动。由于节点的自治性和自私行为,扰动成为最严重影响P2P性能的缺陷之一。目前针对网络扰动的有效措施不多,需要继续深入研究。
    激励机制:在流媒体服务中,激励机制是一个开放问题,常见的激励方案包括基于积分、基于名声和基于博弈理论等方法。有研究提出一种激励模型,将节点贡献转化为分数和对应等级,来决定节点选择邻居的优先度,贡献越多的节点能够获得更高的共享资源,得到更高的服务质量。
  • P2P-CDN混合式分发体系结构:P2P与CDN之间存在很大的优势互补空间。很多研究对P2P-CDN混合式分发体系结构寄托了极大的期望,在P2P-CDN混合式分发框架下,P2P能够辅助CDN:对等节点之间共享从服务器获得的数据,减少了服务器的负担;在CDN覆盖不到的区域,P2P可以作为一种网络优化的手段。同样,CDN可以辅助P2P:当P2P网络内部共享服务能力无法满足用户需求时,CDN基于复制的基础框架可以为P2P提供稳定的内容来源;CDN服务器可以充当P2P网络的超级节点,提供一定程度的节点管理和数据流量控制的管理功能。

参考文献:

  1. 郑伟平, 齐德昱, 向军,等. 流媒体分发体系结构演化和关键技术进展综述[J]. 小型微型计算机系统, 2010, 31(1):72-82.
  2. IHS, Video Surveillance Storage: Enabling infrastructure for next generation security systems,2015
  3. 许勇,浅谈云存储技术架构,http://www.asmag.com.cn/tech/201605/75449.html
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,684评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,143评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,214评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,788评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,796评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,665评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,027评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,679评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 41,346评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,664评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,766评论 1 331
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,412评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,015评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,974评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,073评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,501评论 2 343

推荐阅读更多精彩内容