目前大部分厂家推出的IP视频监控系统都是采用这种模式。这种模式的核心在于利用系统中独立的流媒体服务器或者某个设备中的流媒体功能模块来实现视频流的复制分发，从而实现视频客户端解码播放，视频解码上墙。

　　目前大部分厂家推出的IP视频监控系统都是采用这种模式。这种模式的核心在于利用系统中独立的流媒体服务器或者某个设备中的流媒体功能模块来实现视频流的复制分发，从而实现视频客户端解码播放，视频解码上墙，而系统中的存储服务器或者存储功能模块则获取流媒体服务器转发来的视频，实现视频存储。这种模式本身也经过了一系列的演化和发展。

　　此时的存储服务器和流媒体服务器都是一台高性能的电脑。流媒体服务器从前端摄像机获取视频流，然后将视频流复制，分发至存储服务器。由于IP监控系统中，存储的要求基本上是全天候实时存储，所以，这路分发给录像存储服务器的视频流将是源源不断始终存在的。如果客户端软件或者解码器上墙需要实时视频流，则流媒体服务器再会复制一路或者若干路视频流给客户端和解码器上墙。

　　流媒体服务器从前端摄像机获取视频流，然后将视频流复制，一路肯定会分发至存储服务器。由于IP监控系统中，存储的要求基本上是全天候实时存储，所以，这路分发给录像存储服务器的视频流将是源源不断始终存在的。如果客户端软件或者解码器上墙需要实时视频流，则流媒体服务器再会复制一路或者若干路视频流给客户端和解码器上墙。

　　这种结构中，工作压力主要在流媒体服务器上，一台服务器的转发能力是有限的，如果系统中是高清摄像机，转发数量将有明显下降。再说存储，系统的存储功能主要由存储服务器和磁盘阵列来完成，存储服务器作用在于从流媒体服务器获取视频流，然后将其打包成文件的格式再发送至磁盘阵列保存，这里存储服务器和磁盘阵列将有两种连接方式：一种是通过IDE或者SATA线缆直接连接，即DAS方式;另一种方式就是通过网络方式，即NAS/IPSAN方式。

　　上述结构最大的问题在于系统中服务器的数量将会很多，对于多点数的大型监控系统尤其如此，这显然会增加系统的成本和维护复杂度。同时由于流媒体服务器和存储服务器均为普通PC式服务器，其中运行的程序也基本基于WINDOWS开发，其在稳定性上也存在一定隐患。

　　流媒体模块和存储模块整合的结构

　　改良后的IP视频监控系统结构，主要就是将流媒体服务器和存储服务器作为两个独立的功能模块合二为一安装在一台服务器上，这样做既减少了系统中服务器的数量，而且通过计算机内部的总线将视频流交给存储模块，减少网络带宽压力，同时存储模块获取流媒体模块转发的视频流也更加可靠稳定。但是，存储模块将视频数据处理成文件包后仍将通过网络传送至磁盘阵列存储，这仍然会消耗网络带宽资源。

　　加入嵌入式NVR的结构

　　为提升存储部分的稳定性，嵌入式NVR出现了。嵌入式NVR在结构上将原来的NVR服务器和磁盘阵列整合起来，一般是服务器机头加若干盘位的存储构成，系统内的软件也由以前的基于WINDOWS的存储软件改成嵌入式软件，运行更加稳定可靠，伴随着嵌入式NVR的面世，相当一部分IP监控系统的结构演变成图3描述的形式。

　　由于早期嵌入式NVR只具备存储功能而不具备转发视频的功能，所以系统中的流媒体服务器继续存在，但是存储部分则变成了一体式的嵌入式NVR设备，除了存储运行更加稳定可靠，NVR获取到流媒体转发来的视频流后余下的工作均在本机内完成，不再把视频数据发到网络上转给独立的磁盘阵列，这就降低了网络带宽的压力。

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

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

　　系统中除了管理服务器不可或缺之外，嵌入式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故障。