监控系统之硬盘录像机(DVR) 之前断断续续的写了几篇文档，时间久了，也不想就这么消失不见，所以合并在一起，在加上一些修饰，再次发布一遍。 前言 经过几年的开发，对硬盘录像机产生了一些厌倦，但是有些东西还是值得纪录的，所以就写了这个技术整理。目的是为了记录一些曾经的经验和教训，聊做纪念。某些不清楚的部分不会抄一些文章过来充数，也不会为了让文字看起来比较丰满而作过多的资料调查，所以如果在阅读的过程中有任何不适或者不满，可自行离场，谢谢。 整个文档会从全局到细节，再从细节返回全局，先对整体设计、环境、行业现状进行描述，列举一些应该深入的方向，然后进行详细的叙述，{zh1}再对整体进行一次勾勒。由于某些部分涉及技术机密，所以描述不会很清楚，还请见谅。 开篇 90年左右，{dy}批涉足视频监控的企业开始在国内出现，比如北京的行者等。这个阶段由于硬件的昂贵价格和硬件能力的约束，以及是软件开发上的约束，很多东西无法实现，所以在这一阶段，视频监控还是以模拟为主，就是架设好摄像头，再将视频线、云台控制线等连接到控制机房，机房内放置对应的监视器(其实就是电视机的改装体，甚至在一些地方，就是直接用老式的黑白电视机来代替)。然后将视频头接入监视器，云台控制线接入云台控制器。这时的云台控制器大多直接从国外进口，其包含的技术含量并不高，但物以稀为贵，价格还是很高的。某些场合下并不需要云台控制，所以只需监视器和录像机即可工作。但用录像带录制有一些天生存在的问题，比如录像时间不够长，磁带保存困难。为了有更长的录制时间，制造商们制造出了超常的录像带，尺寸比较大，给运送和保存造成了一定困难。即便如此，一卷录像带也不过能录制2个小时的影像，就是说每隔2个小时就需要更换一次录像带。由于录像带使用的是感光方式的光学胶卷，所以要长时间保存就对环境有比较高的要求，而且由于尺寸比较大，造成保存空间比较大。同时，由于录像带不可中断的特点，若要临时查看现场录像，只能将正在录制的录像带中断，之后这卷录像带上还未录制的部分就无法再次利用了，一般只能报废，从而产生无法避免的浪费。 不管怎样，模拟的监控系统还是满足了绝大多数的需求，可以很好的工作。在此说句题外话，个人觉得国内的开发人员都有一个通用的问题，就是对美工过度追求，甚至不惜影响到功能的实现。其实大多数的需求里，实用才是{dy}位的，简单而且符合要求的软件才是客户需要的，漂亮和华丽的外观虽然很吸引眼球，但并不是核心内容，xx可以在后期再做改善，不应该一开始就花大力气对其进行考虑。 从2000 年开始，软硬件的发展一日千里，相关技术日益成熟，如视频压缩、显卡的硬件加速、高速CPU等，很多模拟技术在数字化技术面前变得很容易实现，于是数字化监控系统开始发轫和发展。这阶段开始做监控系统的公司大多活的很滋润，因为竞争少，市场又十分巨大。举个例子，全中国有那么多的银行营业所，每个营业所都要更新监控系统，而且是硬性规定，可以想见，这是一个多么巨大的市场，这还只是冰山一角而已。但是好景不长，由于利益关系，在一两年内，很多公司开始涉足这个行业，而且为了抢占市场，互相打压价格，造成市场的分裂和混乱，于是利润空间越来越小。此阶段可谓监控行业的战国时期，群雄逐鹿，天下大乱。所谓分久必和，经过一段时间的混乱，现在的行业现状终于开始呈现秩序和分化。目前的现状就是能者居之，要么软件做的好，要么硬件研究的深。但是时间尚短，还需要一段时间的观察和思考才能有定论。 无论如何，这个行业的技术含量和利益深度还是有挖掘潜力的。特别是今年中央扩大了监控的适用范围，会造成一段时间内的需求上升，但是产品的质量也越来越成为占领市场的杀手锏。 框架 这一篇的主要内容是描述硬盘录像机的内部框架结构，建立基本的鸟瞰图。说到框架，就不能不对硬盘录像机做一个定义。何为硬盘录像机？定义如下： 以视频为中心，结合各种周边软硬件，以监控为目的的系统。 视频的定义很宽泛，包括专业摄像头/usb摄像头/DV/电视卡/web摄像头等设备采集的画面、视频片断、网络视频等。所有的目的就是一个，获取由多幅静态画面组成的动画视频。但是仅仅采集到视频是不够的，必需显示出来才能被人所认知，所以就需要视频显示的功能。同时视频具有一些基本的控制功能，比如亮度、对比度、色度、饱和度、分辨率等。显示和控制是最基本的要求，另外存储和录像播放也是必不可少，同时，系统中还会包括一些附属设备和功能，比如云台控制、开关报警、音频录制、远程观看和控制等。把以上这些功能组合起来，就构成了一套完整的硬盘录像机。 从系统架构上看，一套完整的硬盘录像机包括以下几个方面： 1.原始数据采集和控制。 对于视频采集设备，目前一般分为四种。一种是以BT848/878或7143芯片为核心的软采集卡，主要功能是通过AD转换将模拟信号转换为数字信号，再通过驱动送往应用层。接口有三种方式，一种是比较“原始”的连接库（DLL/lib)方式，通过函数进行调用来获得每一帧画面，这种方式比较原始，但是效率是{zg}的；第二种是通过标准的系统调用来提供数据，比如vfw(video for windows)和v4l(video for linux)，这种方式{zx0}起源于usb摄像头，目的是提供统一的接口以方便用户调用，但是面对越来越多的视频采集设备和日益发展的硬件水平，其接口逐渐变得不那么适合，对于windows而言，正在逐步淘汰vfw，而在linux里,v4l也进化到了v2版本；第三种是windows独有的方式： directshow，复杂，强大，效率相对要低一些，开发比较困难。软卡的优点是数据处理方式很灵活，可以跟随软硬件的不断发展而进化，缺点是在目前的硬件水平下，多路同时处理比较受限，主要表现在多路压缩时占用的CPU过高和PCI带宽不够，但随着CPU的不断进步和PCI-X的逐步实现，这些都是可以解决的。 第二种采集设备是以软卡机制为前端，以dsp芯片为核心的硬采集卡。主要框架是前端依然通过AD将模拟信号数字化，但是后端并不直接将数据送出，而是送往dsp芯片进行压缩，然后将压缩后的数据送出，同时提供overlay方式的显示功能。硬卡的核心就是dsp，dsp的核心就是压缩算法，从最早的mpeg-1、mpeg-2到mpeg4，再到现在满天乱飞的h264，硬卡的进步也是有目共睹。其优点是对系统资源占用小，无论是显示还是存储，都对系统没有什么特殊要求，但是缺点也是很明显，主要是对上层的监控系统限制太多，以及升级成本偏高，升级codec对于软件而言是很容易的，但是对于dsp就不那么现实了。 第三种采集设备是usb摄像头、dv等，采用vfw或dshow方式采集视频数据。由于usb的带宽限制，这种设备一般只用于低端应用，比如家庭娱乐。但是作为硬盘录像机的附加设备，也有其存在的空间。其功能和性能较上面两种要弱，但是应用难度却相对较低。 第四种采集设备是web摄像头，一般使用montionjpeg的方式提供视频，即由webserver提供不断刷新的静态画面。四种设备中这是速度最慢的，控制通过http方式来操作，不太方便。 除了视频，在硬盘录像机中，音频也是一个比较常见的数据源，一般来自于采集设备或line in/microphone。由于监控大多采集的是日常环境中的声音，所以对音源的要求并不高，只要能获取常用频段的数据即可。但是音频数据如何与视频数据整合却是难点之一。 2、压缩 原始的视频和音频数据尺寸都是比较大的，必须通过压缩才能降低尺寸，以便于存储和网络传输。目前的压缩分为无损压缩和有损压缩两种，无损压缩能保证数据的完整性，但是压缩后的尺寸还是相对较大，所以一般在监控里使用有损压缩。有损压缩从mpeg-1、mpeg-2、mpeg-4(h263)到现在逐渐实用化的h264,尺寸不断缩小，已经逐渐接近理论的极限值。mpeg-1和mpeg-2已经逐渐被淘汰，h264对cpu的占用还太高，这是由于它的算法的复杂度决定的，所以目前常用的还是mpeg-4。市面上有一些硬卡厂家号称生产出了h264的卡，但是基本上都是采用了优化后的mpeg-4或者是简化后的h264，并非真正的h264，但是在不远的将来，h264是有可能大行其道的。目前，mpeg-4一般使用microsoft的mpeg-4 V3或xvid，在画面细腻程度上，ms mpeg-4 v3要稍微好一些，在尺寸上，xvid更加的小一些。ms mpeg4 v3基本已不再发展，ms已经逐渐转向media encode系列codec，而xvid还在不断发展，xvid基于GPL协议，居于跨平台、效率高的特点，更适用于硬盘录像机，但是似乎目前使用的不多。 按照某些行业的要求，对存储的保存时间是有硬性规定的，在硬盘价格不断下降、CPU速度不断提升以及压缩算法的不断改进的形势下，保存时间在不断拉长，但是目前所需要的硬盘数目依然很多，这是现状，也是需要对客户进行解释和培训的。 压缩的数据，不管是软件压缩还是硬卡压缩，除了存储，还有一个比较常用的功能，就是网络传输。网络传输的难点在于传输协议，一般常用的标准协议有 rstp 和mms等，但是未必适合硬盘录像机的全部要求，所以一般要做一些改造，甚至是自己设计。首先是协议问题，大多数开发人员考虑到尽量利用带宽，所以一般使用udp协议，但是udp协议有一些根本性的问题，比如局域网内如何连接，包的乱序和纠错造成开发上的困难等。个人建议，还是使用tcp比较适合。同时，现在逐渐流行的p2p协议也是可以考虑的，比如emule和bt的传输协议，不过由于硬盘录像机面向的是实时传输、客户端较少的现状，所以未必适用。 3、移动侦测 一些高级的云台一体机有物体跟踪，甚至是模式识别的功能，但大多数还没有到实用的阶段。所以目前常用的还是以检测指定范围内的图像移动为主，算法上大体差不多，主要区别在于优化和切割粒度上。 4、云台控制 云台的基本原理就是用232/485传输指令给微控制器，然后微控制器控制电机进行工作，从而达到控制摄像机的转动、焦距、景深等功能。每种云台都会有自己的一套控制指令，但{zh1}的作用大同小异，都是为了完成前面说的那些功能，常见的云台控制协议有PELCO_D等。 5、网络传输 现在的网络硬件基础已经相当完备，特别是一些发达地区，覆盖面积和带宽都已经相当可观，所以顺应潮流，在硬盘录像机中也加入了网络的功能，比如异地同步观看，异地查看录像和日志等。但在目前硬件基础还参差不齐的现状下，如何实现比较均衡的传输和较小的系统负载还是一个比较大的挑战，既有参考通用协议(比如rtp/rstp/h323)的，也有自我定义协议的。 6、安全可靠的长效运行 这是一个比较大的题目，其实可以单独抽出来写一篇的，这里只就纯技术范围做一些讨论。 硬盘录像机本身就是一个掌管安全的系统，如果本身无法做到安全可靠，那么如何让客户满意？但要做到这一点又是非常困难的。操作系统的稳定性、代码的健壮性自查能力、硬件的可靠性、环境的稳定性和可靠性、人员的稳定和可靠与否、网络的情况、病毒和木马的抵抗力，等等，这些都是影响整个系统稳定运行的重要因素，可能某一个环节的小问题{zh1}会引起整个系统的崩溃。正所谓千里之堤溃于一蚁，对于这个部分，{zh0}是早预防、早准备、快速反应、及时总结，以免造成损失。 实现 有了框架，接下来自然就是细节的实现，俗话说，细节决定成败。对于一个复杂的系统而言，细节有时候是决定性的。 硬盘录像机涉及到的技术比较的多，而且某些又涉及技术机密，所以这里只能是对我个人认为比较重要和比较关心的部分进行一个大概的列举。 directshow的采集方式下，一般都会需要一个窗口进行preview，但是这样的窗口是无法进行更多处理的，如果只是显示图像，则没有什么影响，但是如果需要对图像做一些处理，则问题就比较多了。比如要在图像上显示注释、对图像的局部遮盖、同一个视频源的多处显示，这些不是不能实现，但在 preview的方式下，基本都是一些捞偏门的方法，并不通用和好看。所以{zh0}的办法是通过samplegrabber获取原始图形，然后自行进行显示和处理，但是在dshow的方式下，一般很难找到不用preview的方式。难并不代表没有，通过查阅msdn，还是可以通过插入null filter进行处理的。 云台控制器有很多种，每套控制指令基本差不多，但是其中微小的差别对开发却造成了麻烦。如何将各种有微小差别的指令集整合起来，是对开发人员的考验。 软压缩在硬盘录像机里是很重要的部分，但是压缩在硬盘录像机里有一些特殊要求，比如变帧率、变分辨率，这对更好的保存录像有帮助，但是对于开发却造成困难。 显示上，如果是软卡，一般需要自己处理，gdi的方式效率实在底下，那么就需要实用一些高效的方法，现在一般使用ddraw或opengl。在显示上有一些要处理的工作，会对开发造成困难，比如如何在画面上贴字，仅仅贴一个字并不难，但是要在不断变化的背景画面上贴一个不会被背景颜色抵消的字就比较见功底了。而且OpenGL在linux下对汉字的支持有问题，贴字更是一个问题。同时某些时候需要对画面的局部进行遮盖，如果不降低效率做到这一点？ ddraw有一个bug，就是开14个对象以上，在某些显卡上会显示失败，OpenGL更直接，打开超过4个rc的情况下，系统会死机。如何处理好这些问题，是对开发人员的考验。 缓存、队列、线程，在硬盘录像机里几乎到处是这些东西，{zh0}的方式是抽象出统一的接口来，否则代码会比较臃肿和难看。如何抽象？这是一个问题。 这样复杂的系统，胶合层是必不可少的，但是胶合层要越薄越好。 效率和层次清晰是两个矛盾体，如何结合？ 面对各种各样的采集设备和采集接口，如何将他们整合在一起？比如软卡＋硬卡，或者再加usb摄像头，接口有lib/overlay/dshow(或者是vfw)，如何整合在一起？ 存储的录像文件是做成通用的格式还是自己定义的格式？ 录像文件需要搜索，日志需要保存、搜索，以及查看，如何在搜索的同时不会对系统造成不必要的负载？ 硬盘录像机涉及的方方面面很多，各部分的关联关系很密切，如何在保证简洁、清晰的前提做好软件分层，这个是对开发人员的{zd0}考验。要么失之清晰，要么失之灵活，一个复杂的系统最难的反而是如何做简单。 结语 以上为目前能想到的认知到的一些内容，如有不足，欢迎指正。 |
