不带流媒体转发服务器的结构

　　嵌入式NVR很快变成了IP监控系统中一个非常重要的部分，除了存储功能，更多的功能被添加到嵌入式NVR上，其中最重要的就是视频流转发功能和视频管理功能，原来系统中流媒体转发服务器将不再需要，视频管理功能使嵌入式NVR具备单独构成小型系统的能力，在类似小区，连锁店之类的项目中，嵌入式NVR就是系统的核心，具备IP数字监控系统的一切主要功能，在大型系统中，嵌入式NVR将作为一个基本组成单元融入整个系统。这也是目前主流的IP监控系统结构之一(如图4)。

　　系统中除了管理服务器不可或缺之外，嵌入式NVR成了组成系统的基本单元，其具备视频转发和存储功能。这些NVR单元通过配置，直接从所管辖的前端IP摄像机获取视频流，如果外界没有实时浏览的需求，则直接将这些视频流变成文件包存入本机内的磁盘阵列，如果有来自客户端或者解码器的实时浏览需求，则响应这些需求，复制另一路或者若干路视频流转发至客户端软件或者解码器。整个系统的结构更加简单清晰，网络的带宽压力也有大幅度下降。

　　上述几种结构其实本质相同，都是基于流媒体转发技术来实现浏览和存储。这几种结构存在两个问题：

　　浏览视频流和存储视频流来自同一个源头，应用起来不够灵活

　　具体地说，在这种基于流媒体转发技术的结构中，流媒体部分(不论是功能模块还是独立设备)只会从前端获取一个视频流，然后转发给存储或者浏览设备。如果前端摄像机是高清摄像机，用户存高清视频，那么浏览的也必然是高清视频，一台客户端电脑解码超过9路高清视频可能就吃不消了。再者如果客户的存储空间有限，希望浏览高清视频但是存储标清视频，在这种结构下如果不做特殊处理也很难实现。一个更实际的需求是高清视频需要存储，但是浏览时并不需要始终是高清视频，当客户端上开9画面或者16画面时，单个画面是不是高清的已经分辨不出来了，此时完全可以显示标清或者更小分辨率的视频，客户端电脑解码这些非高清视频时将比较轻松，画面的流畅度也更高，当切回单画面时，才需要再显示高清视频。

　　目前解决这个问题主要有两个方法。

　　一是流媒体部分通过管理服务器侦测客户端的多画面数量，一旦发现客户端设置为9画面以上，则流媒体模块将高清视频流进行裁剪，降为低分辨率的视频转发客户端，一旦侦测到客户端恢复单画面窗口，则重新发送高分辨率的视频流。但是这样做会使流媒体模块的负担进一步增加，在总资源一定的情况下，必然会影响到复制转发视频流的能力，同时，前端摄像机的高清视频流最好也是支持多级别可裁剪的。

　　另一种方法是借助前端摄像机的另一路码流，目前高清摄像机一般都至少支持一个高清码流和一个低分辨率码流输出，当流媒体模块侦测到客户端开多画面窗口后，则重新从前端摄像机获取一个低分辨率的视频流进行转发，同时断开原来转发的高清视频流，这样做有时会造成客户端进行多画面单画面切换时，出现短暂的无视频现象，在采用无线设备传输视频时这个现象可能更明显。

　　NVR存储模式不够灵活

　　在这种结构下，每台NVR都会管理一定数量的前端视频，具体地说，就是每若干路视频往一台NVR设备里存储。虽然嵌入式NVR比以前的PC式NVR要稳定很多，但是若某一台NVR发生故障，被这台NVR管理的若干路前端视频都无法录像了，后来采用N+1的模式使这种问题得到一定程度的解决。N+1模式就是除了必要的若干台NVR之外，系统中再热备一台或者多台(一般为一台)NVR，平时这台NVR不工作，只是处于预备状态，一旦管理服务器检测到某一台NVR故障或离线，则向热备的NVR发出指令，热备的NVR则主动接管受影响的前端摄像机，把视频资料保存在热备的NVR内，同时系统报警，提醒维护人员去检查维修故障设备。一旦原来故障的NVR修好或者重新上线，热备的NVR会把本机内保存的视频通过网络送回给原来的NVR，同时原来的NVR重新接管相关的摄像机，热备NVR在传送完视频资料后继续处于热备状态。但是系统中如果有更多的NVR故障怎么办?到底要热备几台NVR?目前主流的厂商都基本只支持N+1的模式，即只允许一台NVR故障。