某项目中需要集成视频管理平台，实现分布在各省公司的摄像及接入，对视频进行统一管理。本项目中视频管理平台采用GB/T28181实现的监控设备接入管理平台，支持在开放互联网和局域网对监控设备进行远程接入、远程管理、远程调阅、录像回看等功能。本文对此记录GB/T28181协议的原理和一些问题，以供后续参考，相关错误诚请批评指正。

相关资源：Nginx支持flv和mp4格式文件，同时支持Rtmp协议；同时打开rtmp的hls功能、wvp-GB28181-pro、国内项目地址

2.1、相关术语

1）H265/H264视频编码：

H.265：又称为High Efficiency Video Coding (HEVC)，是H.264的后继者，同样由VCEG和MPEG联合开发。H.265的目标是在H.264的基础上进一步提高压缩效率，理论上可以比H.264节省大约50%的比特率，同时保持相同的视频质量。相对于H.264，它能提供：更大的编码单元（CU）尺寸，从64×64到8×8像素的自适应四叉树结构；改进了运动预测和帧内预测；支持更高效的熵编码方法和更精细的量化参数控制。这些改进使得H.265在处理高清和超高清视频时更加高效，但同时也意味着更高的计算复杂度，可能影响到实时编码和解码的性能。基于H.265的高效性，它更适合在高清和4K视频的流媒体和存储领域；

H.264：全称MPEG-4 Part 10或Advanced Video Coding (AVC)，是由ITU-T的视频编码专家组（VCEG）和ISO/IEC的动态图像专家组（MPEG）联合开发的一种视频编码标准。H.264的主要目标是在与早期标准（如MPEG-2和MPEG-4 Part 2）相同的视频质量下，提供大约两倍的压缩效率。这意味着使用H.264编码的视频文件可以比使用旧标准编码的文件小一半左右，这对于网络传输和存储来说非常重要。通过块运动补偿预测、变换编码、熵编码（如CABAC或CAVLC）等多种技术实现了高效压缩。对于与265的区别，首先H264/H265都是视频压缩标准，但265会比264更先进，一般能将文件大小压缩后比264再降低约50%以上，可在相同质量下使用更低的码率，即H.265在相同码率下可以提供更高的视频质量；而264相对于一些老设备更具兼容性，因H.265是较新的压缩标准，不是所有的设备和平台都支持，相比H.264是更为广泛支持的标准，在包括手机、电视、电脑等多个平台上广泛应用，故一般取H.264即可。NALU（Network Abstraction Layer Unit）是NAL层的基本数据单位，由一个头部（一个字节）和一个负载部分组成，其中头部包含了控制信息，用于指示NAL单元的类型、重要性等级以及其他相关参数；负载部分包含了实际的编码数据，如图像数据、参数集数据等；而负载数据的结构和内容取决于NAL单元的类型。H264结构中，一个视频图像编码后的数据叫做一帧，一帧由一个片(slice)或多个片

组成，一个片由一个或多个宏块(MB)组成，一个宏块由16x16的yuv数据组成。宏块作为

H264编码的基本单位。在H264协议内定义了三种帧，分别是I帧、B帧与P帧。I帧就是一个完整的图像帧，而B、帧与P帧所对应的就是不编码全部图像的帧。P帧与B帧的差别就是P帧是

参考I帧而生成的，而B帧是参考前后图像帧编码生成的。H264采用的核心算法是帧内压缩和帧间压缩，帧内压缩是生成|帧的算法，帧间压缩是生成B帧和P帧的算法。

2）输出HTTP-FLV、HTTP-MP4

HTTP-FLV：将音视频数据封装成 FLV格式文件，然后通过 HTTP 协议传输给客户端。它具有低延迟特定，内容延迟可以做到 2-5 秒；只要浏览器支持 FlashPlayer 就能简易的播放；它的地址是http://开头的，是基于HTTP协议的，可以简单地理解为RTMP的HTTP协议版本，功能和工作原理是相似的，且RTMP切片数据功能，HTTP-FLV也是支持的，但HTTP-FLV协议一般只能用作拉流观看。实际体验中， HTTP-FLV延迟会略高于RTMP，但是HTTP-FLV相对RTMP适配更多的播放场景。Nginx中已经集成 nginx-http-flv-module支持该协议，Nginx的HTTP-FLV插件是包含RTMP功能的，所以一般HTTP-FLV的流媒体服务，推流是以RTMP协议，拉流是用HTTP-FLV协议。综上，目前比较流行的方案是，直播源推流是RTMP协议，直播拉流观看是HTTP-FLV协议。

HTTP-MP4：基于HTTP的MP4协议，将音视频数据封装成封装成mp4格式。MP4 文件的数据都是封装在一个又一个名为 Box 的单元中。一个 MP4 文件由若干个 Box/FullBox 组成，每个 Box 包含了 Header 和 Data。所有的Metadata（媒体描述元数据），包括定义媒体的排列和时间信息的数据都包含在这样的一些结构box中。Metadata 对媒体数据（比如视频帧）引用说明，而媒体数据在这些引用文件中的排列关系全部在第一个主文件中的metadata描述，这样就会导致视频时长越大文件头就会越大、加载越慢。

4K流媒体代表(40962160分辨率)，8K流媒体高清代表(81924320分辨率)

720P(1280*720分辨率) ，1080P(1920 * 1080分辨率)

RTMP（Real-Time Messaging Protocol）：RTMP协议是既可以推流、也可以拉流的协议。RTMP和HTTP-FLV都是建立在FLV封装之上的，RTMP一般用作直播源推流，HTTP-FLV一般用作直播观看；RTMP地址是rtmp://开头的，且推流地址与播放地址是一样的。相对于HTTP方式，很多防火墙会墙掉 RTMP，但是一般不会墙 HTTP，因此 HTTP FLV 出现奇怪问题的概率会很小，FLV 是最简单的流媒体封装，HTTP 是最广泛的协议，这两个组合在一起维护性更高，比 简单很多。RTMP通信是建立在TCP长连接通道上的，在封装音视频数据时会强制切片，限制每个数据包的大小，这在一定程度保证了实时性，有一定的弱网抵抗能力，因为每个数据包都不会太大，所以当某个数据包校验失败时，重新发送的成本不会太大，但也由于合并数据包会加大CPU压力，所以是有一定的性能消耗的。RTMP具备低延迟，内容延迟可以做到 2-5 秒。

WebRTC是一种 点对点的视频/语音通话协议。由于WebRTC是基于UDP的，建立通信后，会不断以流式发送数据，所以延迟会比RTMP还要低。在一些交互性较高的直播场景，如直播带货等场景，会使用WebRTC作为推流和观看协议；WebRTC的延迟理论上可以达到1秒内。WebRTC协议支持推流和拉流，地址一般是以开头的，且推流和拉流地址一般是一样的。WebRTC虽然是点对点的协议，但是应用在直播场景的话，是需要搭建WebRTC服务器作为流媒体服务的，流媒体服务软件可以使用SRS，SRS是国内研发的一个比较流行的开源流媒体服务软件，目前4.0已经囊括了RTMP、HLS、WebRTC、HTTP-FLV等主流协议。

RTSP（（Real-Time Streaming Protocol））/Onvif（国际标准） 协议：一般不用作直播场景，RTSP 是基于文本的协议，采用 ISO10646 字符集，使用 UTF-8 编码方案；RTSP 是应用级协议， 控制实时数据的发送。RTSP（实时流协议）一般用作摄像头、监控等硬件设备的实时视频流观看与推送上。尽管RTSP协议也支持推流/拉流，且支持TCP、UDP切换以及其他诸多优点。但是泛用性不足，特别是现在的浏览器都不支持RTSP的播放。另，RTMP 和 RTSP 都是流媒体传输协议（现场用的是RTP 协议（摄像机主动推流），它们之间的主要区别：1）RTMP 是一种基于 TCP（默认 1935） 的实时传输协议，而 RTSP 是一种基于 UDP （实际：控制走 TCP（默认 554），媒体通常走 RTP/UDP（动态端口））的实时传输协议。2）传输方式：RTMP 是一种单向传输协议，信息只能从服务器端传输到客户端。而 RTSP 支持双向传输，允许服务器端和客户端之间进行实时通信。3）控制协议：RTSP 是一种控制协议（不直接传媒体），它可以用于控制媒体流的播放、暂停、停止等操作，精准流控制、超低延迟、适合监控 / 会议。而 RTMP 不是一种控制协议（但其可同时承载控制信令 + 音视频数据），它只负责媒体流的传输，且低延迟、稳定、适合直播推流。4）安全性：RTMP 提供了较低的安全性，因为它使用 TCP 协议进行传输，容易受到中间人攻击，推流鉴权（Token / 密钥），默认不安全，需依赖上层加固，且需手动加密，比如：RTMPS：RTMP over TLS/SSL（类似 HTTPS)。而 RTSP 提供了较高的安全性，因为它采用：控制 + 媒体分离加密，RTSPS：RTSP over TLS（控制信令加密）+SRTP：RTP 加密（媒体流 AES-128/256独立加密，防窃听 / 篡改），支持Digest/Basic 认证，支持设备级鉴权，更适合安防 / 专网高安全场景，但存在公网穿透难（多端口（554 + 动态 RTP 端口），需端口映射 / UPnP），公网易用性补录RTMPS。5）性能：RTMP延迟：2–5 秒，TCP 保证不丢包、不乱序，公网更稳；RTSP（RTP/UDP）：1–2 秒（无重传，极限低延迟），丢包不重传，适合内网 / 低丢包环境；RTSP（全 TCP）：3–4 秒（接近 RTMP），稳定性同 RTMP ；6）应用场景：RTMP浏览器兼容性方面，因Flash 问题，无原生浏览器支持，需转 HLS/DASH，RTMP → HLS/DASH适配 Web / 移动端播放，主要用于直播和视频点播应用，而 RTSP 主要用于实时视频监控和安防监控等应用。RTSP 是用来控制声音或影像的多媒体串流协议， 并允许同时多个串流需求控制，它也无原生浏览器支持，需插件 / 转码。RTSP 在体系结构上位于 RTP 和 RTCP 之上，它使用 TCP 或 UDP 完成数据传输。HTTP 与 RTSP 相比，HTTP 请求由客户机发出，服务器作出响应；使用 RTSP 时，客户机和服务器都可以发出请求，即 RTSP 可以是双向的。RTSP 提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如 UDP、组播 UDP 与 TCP 提供途径，并为选择基于 RTP 上发送机制提供方法。RTSP 中所有的操作都是通过服务器和客户端的消息应答机制完成的，其中消息包括请求和应答两种，RTSP 是对称的协议，客户机和服务器都可以发送和回应请求。RTSP 作为一个基于文本的协议，它使用 UTF-8 编码（RFC2279） 和 ISO10646 字符序列，采用 RFC882 定义的通用消息格式，每个语句行由 CRLF 结束(

)。RTSP 的消息包括请求和应答两类。

ONVIF(Open Network Video Interface Forum开放的安防行业组织) 相对于GB28181是平台互联的国标信令协议，它是设备发现与配置的控制协议，旨在解决不同厂商网络视频设备（如摄像头、录像机）之间的互联互通问题。onvif为国际主流标准，采用Web Service技术（SOAP + WSDL），基于XML格式进行通信，全球超过80%的IP监控产品都支持ONVIF，意味着用户可在同一系统中混用不同品牌的设备，ONVIF主要用于设备发现和配置，通过WS-Discovery协议自动发现网络中的设备，onvif本身不传输媒体，通过RTSP（实时流协议） 来获取和控制在RTP上传输的视频流，也不能直接播放视频，需要配合RTSP协议来获取实际的视频流地址。它的首要任务是解决“接进来”的问题瓦伦西亚赛事分析。当系统需要接入一个摄像头时，ONVIF负责自动发现它，获取它的能力信息（如分辨率、编码格式），配置它的参数，并最终告诉系统这个摄像头的RTSP视频流地址是什么，主用于局域网内集成不同品牌的摄像头、录像机和视频管理软件。而GB28181的首要任务是解决“连上去”的问题。当需要将整个视频监控系统（可能包含成百上千个摄像头）向上级平台（如公安网）报送时，GB28181负责完成设备注册、目录上报、实时点播、历史回放等复杂的信令交互，实现大规模、标准化的平台级联。最后RTP，作为“搬运工”，无论上层是ONVIF还是GB28181，最终在网络上传输的实时视频数据，其载体几乎都是RTP协议。它负责将H.264/H.265编码的视频数据打包，并保证其在IP网络上的实时传输

3）HLS（拉流）：(HTTP Live Streaming)是Apple的动态码率自适应技术。主要用于PC和Apple终端的音视频服务。包括一个m3u(8)的索引文件，TS媒体分片文件和key加密串文件。HLS协议一般只用作拉流观看，严格来说，HLS其实是一个 文本协议，而并非流媒体协议，它的延迟较高（ts0，segment-time：5，10s）青岛西海岸数据分析。HLS只请求基本的HTTP报文，与实时传输协议（RTP)不同，HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器，它也很容易使用内容分发网络来传输媒体流。HLS一般主用于通过HTTP协议下载静态视频文件，HLS协议的文件由两部分组成：一是多个只有几秒长度的 .ts碎片 视频文件，另一个是记录这些视频文件地址的索引文件；HLS观看地址是以http://开头、结尾的，实际上这个地址就是索引文件的地址，客户端获取到索引文件后，就可以下载对应的碎片视频文件并开始播放了；.m3u8索引文件会记录所有的碎片视频文件地址，HLS在点播的场景下，优势是更加明显的。由于HLS的相关文件是无状态的静态文件，且每个文件的大小是有限的，所以负载均衡、CDN加速的效果更佳明显。另索引文件支持二级索引，就是高清、标清、流畅等多个观看地址可以整合到一个索引文件。播放器可以根据当前带宽自动切换不同的观看地址，大部分网页播放器的“自动”也是因为这个。HLS最大的优点：支持HTML5 就可以直接打开播放，这意味着可以把一个直播链接进行转发分享后用户通过浏览器就能播放，不需要安装任何独立的 APP，HLS协议可以用于点播和直播观看，可适配多种播放场景。采用HLS协议的点播视频，会比.mp4、.flv的视频更快地播放出来，且在加载中跳转视频也会更加顺滑。

采用HLS协议的直播场景，视频流数据每几秒会打包成一个以.ts为后缀的碎片视频文件，每生成一个新的视频文件都会同步更新.m3u8索引文件。且碎片视频文件的个数是有上限的，当达到上限后，默认会将最旧的视频文件删除且更新.m3u8索引文件。所以在直播的场景下，客户端也需要不断定时重新获取.m3u8索引文件；即HLS协议并不适合直播的场景。直播场景下，由于需要生成静态文件，直播延迟很大，大概在5-30秒左右，使用直播CDN的话，由于边缘节点同步等问题，直播延迟甚至可能会达到1分钟左右。

注：由于HLS协议的视频文件、索引文件都是无状态的静态文件，是直接写入磁盘的 ，所以如果长时间且多个直播流同时处理，会造成磁盘写入压力过大，机械磁盘可能会磁道会损坏，固态硬盘的寿命会加速衰减。这种情况下，最好挂载一段内存空间作为HLS相关文件的写入位置，以减轻磁盘写入压力过大的问题。

4）流（stream）：数据在网络上按时间先后次序传输和播放的连续音/视频数据流。之所以可以按照顺序传输和播放连续是因为在类似 RTMP、FLV 协议中，每一个音视频数据都被封装成了包含时间戳信息头的数据包。而当播放器拿到这些数据包解包的时候能够根据时间戳信息把这些音视频数据和之前到达的音视频数据连续起来播放。而像MP4、MKV 等这类封装，必须拿到完整的音视频文件才能播放，因为里面的单个音视频数据块不带有时间戳信息，播放器不能将这些没有时间戳信息数据块连续起来，所以就不能实时的解码播放。

5）RTP（Real-time Transport Protocol）：它是传输音视频数据的媒体协议，是一种网络传输协议，但一般不作为单独应用层协议使用，一般负责音视频数据的封包和传输；RTP（Real-Time Transport Protocol）报文头中有 SSRC和CSRC；其中，同步信源(SSRC)标识符占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。特约信源(CSRC)标识符的每个标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。RTP 本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠 RTCP 提供这些服务。rtp 协议就是提供了时间标签，序列号以及其它的结构用于控制适时数据的流放。RTP 协议和 RTP 控制协议 RTCP通常 一起使用。RTP 被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP 的典型应用建立在 UDP 上，但也可以在 TCP 或 ATM 等其他协议之上工作。

SSRC：同步信源是指产生媒体流的信源，例如麦克风、摄像机、RTP混合器等；它通过RTP报头中的一个32位数字SSRC标识符来标识，而不依赖于网络地址，接收者将根据SSRC标识符来区分不同的信源，进行RTP报文的分组。

CSRC：特约信源是指当混合器接收到一个或多个同步信源的RTP报文后，经过混合处理产生一个新的组合RTP报文，并把混合器作为组合RTP报文的 SSRC，而将原来所有的SSRC都作为CSRC传送给接收者，使接收者知道组成组合报文的各个SSRC。若一个RTP包流的源，对由RTP混频器生成的组合流起了作用，则它就是一个作用源。对特定包的生成起作用的源，其SSRC标识符组成的列表，被混频器插入到包的RTP报头中。这个列表叫做CSRC表。基于以上分组及列表，这样接收者就可以根据CSRC来区分不同的信源；一般的，混合的RTP流中，每隔一段时间，就会有一个RTP报文包含了完整的CSRC表。

流：它的概念中时间标签是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后，就依照时间标签按照正确的速率恢复成原始的适时的数据。rtp 协议和 udp 二者共同完成运输层协议功能。udp 协议只是传输数据包，不管数据包传输的时间顺序。rtp 的协议数据单元是用 udp 分组来承载的。在承载 rtp 数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而 udp 的多路复用让 rtp 协议利用支持显式的多点投递，可以满足多媒体会话的需求。其中， 时间戳有32 位，时间戳反映 RTP 数据包中第一个八进制数的采样时刻，采样时刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时标可以让 receiver 端知道在正确的时间将资料播放出来。

RTCP 负责管理传输质量在当前应用进程之间交换控制信息。在 RTP 会话期间，各参与者周期性地传送 RTCP 包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP 和 RTCP 配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。根据用户间的数据传输反馈信息，可以制定流量控制的策略，而会话用户信息的交互，可以制定会话控制的策略。

RTSP 与 RTP 最大的区别：RTSP 是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如**：回放、快进、倒退等操作。当然，RTSP 可基于 RTP** 来传送数据，还可以选择 TCP、UDP、组播 UDP 等通道来发送数据，具有很好的扩展性，它是一种类似于 http 协议的网络应用层协议。作为一个应用层协议， RTSP 提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。RTP 是实时传输协议，一般不作为单独应用层协议处理；rtsp 可基于 rtp 之上，比如常见的视频流传输过程：视频压缩文件 -> rtp 打包 -> 基于 udp 的 rtsp 网络传输；其中，RTP over UDP 是 RTP 下层使用 udp 传输，RTP over RTSP 是指的用 rtsp 协议建立会话， 然后使用 RTP 协议传输数据，至于下面用 udp 还是 tcp 是不确定的；

6）WebSocket：它是一种在单个TCP连接上进行全双工通信的协议，是HTML5规范提出的一种协议，WebSocket是基于TCP协议的，和HTTP协议是并存的两种协议；目前除了IE浏览器，其他浏览器都基本支持。在HTML5规范中，HTML5 Web Sockets规范定义了Web Sockets API，支持页面使用Web Socket协议与远程主机进行全双工的通信。它引入了WebSocket接口并且定义了一个全双工的通信通道，通过一个单一的套接字在Web上进行操作。HTML5 Web Sockets以最小的开销高效地提供了Web连接。相较于经常需要使用推送实时数据到客户端甚至通过维护两个HTTP连接来模拟全双工连接的旧的轮询或长轮询（Comet）来说，这就极大的减少了不必要的网络流量与延迟。要使用HTML5 Web Sockets从一个Web客户端连接到一个远程端点，需要创建一个新的WebSocket实例并为之提供一个URL来表示你想要连接到的远程端点。该规范定义了ws://以及wss://模式来分别表示WebSocket和安全WebSocket连接；使用WebSocket使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在WebSocket API中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。实际，一个WebSocket连接是在客户端与服务器之间HTTP协议的初始握手阶段将其升级到Web Socket协议来建立的，其底层仍是TCP/IP连接。注：Socket是传输控制层接口，WebSocket是应用层协议。WebSocket是双向通信协议，模拟Socket协议，可以双向发送或接受信息。HTTP是单向的，WebSocket是需要浏览器和服务器握手进行建立连接的；而http是浏览器发起向服务器的连接，服务器预先并不知道这个连接。WebSocket在建立握手时，数据是通过HTTP传输的。但是建立之后，在真正传输时候是不需要HTTP协议的。总之，在WebSocket中，只需要服务器和浏览器通过HTTP协议进行一次握手的动作，然后单独建立一条TCP的通信通道进行数据的传送。客户端发起http请求，经过3次握手后，建立起TCP连接；http请求里存放WebSocket支持的版本号等信息，如：Upgrade、Connection、WebSocket-Version等；之后，在此基础上建立websocket连接。

7）GA/T 1400协议：它是公安视频图像信息应用系统的重要标准，具有灵活性、可扩展性、环保性、兼容性及安全性等特点。它规范了公安通信系统的数据交换格式，协议在公安系统和其他物联网领域得到广泛应用。GA/T 1400协议也被称为视图库标准，全称为 《公安视频图像信息应用系统》。这一标准在公安系统中具有举足轻重的地位，它详细规定了公安视频图像信息应用系统的设计原则、系统结构、视频图像信息对象、统一标识编码、系统功能、系统性能、接口协议结构、安全性、电磁兼容性、环境适应性、电源适应性、可靠性以及运行与维护等方面的通用技术要求。该协议支持ipv6，可以支持大量的物联网设备同时接入网络；协议还具有低功耗特性，采用先进的加密技术，确保视频图像信息在传输过程中不被窃取或篡改。通过该协议，公安部门可以实现对视频图像信息的实时传输、处理和存储。该协议应用在民用领域，可为用户提供更加高效、安全的视频监控服务。

8）数字视频录像机（DVR：Digital Video Recorder）： 它是一套进行图像存储处理的计算机系统，具有对图像/语音进行长时间录像、录音、远程监视和控制的功能，DVR集合了录像机、画面分割器、云台镜头控制、报警控制、网络传输等五种功能于一身，用一台设备就能取代模拟监控系统一大堆设备的功能，该设备也叫PVR（personal video recorder），相对于传统的模拟视频录像机，它采用硬盘录像，故也俗称为硬盘录像机；它的样子就想一台服务器主机一样，DVR将模拟视频进行数字化编码压缩并储存在硬盘上，其“D”字母主要涉及的是编码及储存技术，与网络传输关系不大，因此DVR通常就近安装在模拟摄像机（模拟摄像机采用模拟信号进行传输，距离较短且容易受到干扰）附近的机房内。而NVR从网络上获取经过编码压缩的视频流然后进行存储转发，其字母“N”涉及的网络传输，因此我们在NVR设备上一般看不到视频信号的直接连接，其输入及输出的都是已经编码并添加了网络协议的IP数据。

9）网络视频录像机（NVR:Network Video Recorder）：NVR最主要的功能是通过网络接收IPC（网络摄像机）设备传输的数字视频码流， 并进行存储、管理，从而实现网络化带来的分布式架构优势。 简单来说，通过Nvr，可以同时观看、浏览、回放、管理、存储多个网络摄像机。摆脱了电脑硬件的牵绊，再也不用面临安装软件的繁琐。NVR不可以独立工作、自成系统，NVR需要与前端的IP摄像机或DVS配合使用，实现对前端视频的存储和管理。对于DVR，可以直接连接模拟摄像机进行视频获取、存储和管理，完全可以自成系统独立工作。NVR不受摄像机、编码器及控制中心的物理位置限制，而只要求网络连通就可以了；而DVR由于直接与模拟摄像机链接，因此物理位置受制于现场设备的布局