主要介绍了视频集成解决方案，包括视频监控数据流转、音视频传输协议对比、协议接入、主流的流媒体协议、播放协议对比、主流的封装格式、主要视频编码、常见的设备与连接方案、术语解释、业务场景、视频接入平台、流媒体服务选型以及平台选型等方面的内容。通过这篇文章，读者可以了解到视频集成常见的解决方案，并从现有方案中学习总结，以应对日益复杂的业务场景。

1. 目的

随着承接的项目逐渐增多, 且大多数项目都会涉及到视频监管需求, 为了避免重复调研开发, 加快项目上线速度, 这里汇总总结了多种业务场景并提出对应的解决方案, 一方面是作为技术知识积累, 让团队人员了解视频集成常见的解决方案, 二是可以从现有方案中学习总结, 以应对日益复杂的业务场景.

2. 领域知识

2.1 监控数据流

视频监控数据流转主要经过下面 5 个过程:

1. 采集: 通过硬件设备采集音视频数据, 如果硬件设备支持, 还可以对数据进行粗加工, 比如添加水印;
2. 推流: 设备端将音视频数据进`行编码压缩(H.264/H.265)后发送给流媒体服务器, 一般使用 RTSP (延迟最低);
3. 流媒体处理: 负责转码, 传输, 数据分发;
4. 拉流: 客户端请求流媒体服务器音视频资源, 流媒体服务器通过 RTSP, HLS 等流媒体传输协议传输数据;
5. 解码: 设备端在拿到音视频数据后需要通过硬解码或软解码的方式播放音视频流;

2.2 音视频传输协议对比

2.3 协议接入

2.3.1 GB/T28181

GB/T28181 是摄像头主动向上级平台连接注册，摄像头不需要有固定的外网 IP，只要求流媒体服务器有固定的 IP 地址即可

2.3.2 ONVIF

ONVIF 协议是流媒体服务器主动去连接摄像头，然后进行控制或视频调取，因此在组网时需要流媒体服务器能够访问到摄像头的 IP 地址

2.4 主流的流媒体协议

2.5 播放协议对比

RTMP：RTMP 协议比较全能。既可以用来推送又可以用来直播。其核心理念是将大块的视频帧和音频帧拆分，然后以小数据包的形式在互联网上进行传输，而且支持加密，因此隐私性相对比较理想，但拆包组包的过程比较复杂，所以在海量并发时也容易出现一些不可预期的稳定性问题。

FLV：FLV 协议由 Adobe 公司主推，格式极其简单，只是在大块的视频帧和音视频头部加入一些标记头信息，由于这种简洁，在延迟表现和大规模并发方面都很成熟，唯一的不足就是在手机浏览器上的支持非常有限，但是用作手机端
App 直播协议却异常合适。

HLS：苹果推出的解决方案，将视频分 5 秒 - 10 秒的视频小分片，然后用 m3u8 索引表进行管理，由于客户端下载到的视频都是 5 秒 - 10
秒的完整数据，故视频的流畅性很好，但也同样引入了很大的延迟（HLS 的一般延迟在 10 秒 - 30 秒左右）。相比于 FLV，HLS 在 iPhone 和大部分 Android
手机浏览器上的支持都非常好。

2.6 主流的封装格式

2.7 主要视频编码

8. 常见的设备与连接方案

2.8.1 监控系统中常见设备及作用

在监控系统中，我们要使用很多的设备，在此，我们只讲述一些通用的设备。

1. 摄像机：这个是信号源，是视频图像的来源，摄像机也分很多种，比如：高速球、红外枪机等；一般来说摄像机后面接视频分配器（网络高清摄像机需要接解码器后才能接视频分配器）。
2. 视频分配器：是将摄像机出来的视频信号进行分配的，一般是每路摄像机分配为 2 路相同的视频信号，将视频信号进行分配的目的是 1
   路信号给监控矩阵，另一路给硬盘录像机，视频分配器的输入端接摄像机，输出端接硬盘录像机和监控矩阵。
3. 硬盘录像机：将视频信息进行录制的，以备随时的调取视频资料，硬盘录像机的输入端接分配器的输出端，硬盘录像机的输出端一般接显示器。
4. 监控矩阵：这个设备是监控系统中核心设备，是将摄像机过来经过分配器后的视频信号传输至终端显示设备上的，监控矩阵的输入端接分配器的输出端，监控矩阵的输出端接终端显示设备，此外监控矩阵的附带品是控制键盘，是用来控制视频切换的设备，与监控矩阵直接相连即可。
5. 终端显示：是将视频信息展示的设备，终端显示设备一般有显示器、电视墙、LED 显示屏、拼接屏、监视器等，终端显示设备的输入端接监控矩阵的输出端，终端显示设备没有输出端的。

2.8.2 监控系统中常见的连接方案

摄像机的输出端接视频分配器的输入端，视频分配器的输出端分成 2 个部分，第一部分接硬盘录像机，第二部分（视频信号与第一部分完全相同）接监控矩阵的输入端，监控矩阵的输出端接终端显示设备，此外监控矩阵和控制键盘用网线连接。

2.8.3 视频分配器

9. 术语解释

GB/T28181

GB/T28181《安全防范视频监控联网系统信息传输、交换、控制技术要求》是由公安部科技信息化局提出，由全国安全防范报警系统标准化技术委员会、公安部一所等多家单位共同起草的一部国家标准。标准规定了城市监控报警联网系统中信息传输、交换、控制的互联结构、通信协议结构，传输、交换、控制的基本要求和安全性要求，以及控制、传输流程和协议接口等技术要求。该标准适用于安全防范监控报警联网系统的方案设计、系统检测、验收以及与之相关的设备研发、生产，其他信息系统可参考采用。联网系统应对前端设备、监控中心设备、用户终端
ID 进行统一编码，该编码具有全局唯一性。

RTMP

RTMP 是 Real Time Messaging Protocol（实时消息传输协议）的首字母缩写。该协议基于 TCP，是一个协议族，包括 RTMP 基本协议及 RTMPT/RTMPS/RTMPE
等多种变种。RTMP 是一种设计用来进行实时数据通信的网络协议，主要用来在 Flash/AIR 平台和支持 RTMP 协议的流媒体 / 交互服务器之间进行音视频和数据通信。

ONVIF

ONVIF（开放式网络视频接口论坛）是一个全球性的开放式行业论坛，其目标是促进开发和使用基于物理 IP 的安全产品接口的全球开放标准。ONVIF
创建了一个视频监控和其他物理安全领域的 IP 产品如何进行相互通信的标准。ONVIF 是由 Axis Communications，博世安防系统和索尼于 2008 年创立的。

RTSP

RTSP（Real Time Streaming Protocol），RFC2326，实时流传输协议，是 TCP/IP 协议体系中的一个应用层协议，由哥伦比亚大学、网景和 RealNetworks 公司提交的
IETF RFC 标准。该协议定义了一对多应用程序如何有效地通过 IP 网络传送多媒体数据。

GA/T 1400

GA/T 1400 与 GB/T 28181 有共性的地方，比如设备编码规范、信令交互规范等， GB/T28181 定义的是视频联网，GA/TGA/T 1400 定义的是图片传输，应用最多的是
IPC 传输图片及相关信息到后端设备 / 平台，以及视图库平台与平台对接等，比如人脸抓拍机传输人脸图片、人脸特征等到人脸应用平台，车辆抓拍机传输车辆图片、车牌信息到车辆卡口平台。

FLV

FLV 是 FLASH VIDEO 的简称，FLV 流媒体格式是随着 Flash MX 的推出发展而来的视频格式。由于它形成的文件极小、加载速度极快，使得网络观看视频文件成为可能，它的出现有效地解决了视频文件导入
Flash 后，使导出的 SWF 文件体积庞大，不能在网络上很好的使用等问题。

HLS

HLS (HTTP Live Streaming) 是 Apple 的动态码率自适应技术。主要用于 PC 和 Apple 终端的音视频服务。包括一个 m3u (8) 的索引文件，TS 媒体分片文件和
key 加密串文件。

WebRTC

WebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的 API。

IPC

IPC 是网络摄像机（Internet Protocol Camera）的缩写。

NVR

NVR 是网络硬盘录像机（Network Video Recorder）的缩写。

ICC

ICC 是大华推出的一款智能物联综合管理平台, tigong 设备对接, 人员布控, 停车管理, 消费管理, 动环管理动众多功能.

IVSS

IVSS 是大华的一款硬件设备, 将人脸、人体、车辆、周界等众多“边界智能”融合一体的一体机系列, 具备 IPC、球机、DVR、NVR 等 IP 设备管理, 能够进行人脸识别、车辆识别、人脸比对、实时布控等 AI 计算.

IVS

IVS 智能监控系统可以根据用户的需求，在指定时间段内对目标进行实时监控。您还可以使用仪表盘和手动新建自定义告警模板。您可以根据实际情况自定义监控指标，系统会按照设定的指标收集业务数据。系统还可以根据业务需要，对异常事件、告警和事件进行分类统计和告警上报。

视频流

在网络上，视频数据按时间先后次序传输和播放的连续视频数据流。

推流

推流是指利用推流客户端或者推流工具，通过推流地址将 RTMP 协议的视频流推送到客户端。

拉流

拉流是指通过互联网环境，将视频流从指定平台或 IP 地址获取到视频观看客户端或设备。

3. 业务场景

3.1 固定地点

3.1.1 有线接入

​ 1. IPC 和 NVR 在同一个局域网, NVR 有独立的 Web 端用于管理视频和录像;

​ 2. NVR 提供 RTSP 视频流, 供内部系统和外部系统集成;

​ 3. 外网可通过公网 IP 或 VPN 组网访问内部 NVR;

企业自建网络，本地环境有较多的 IPC，本地配置 NVR 设备，提供本地的视频监测。第三方一般不允许从远端访问当地的视频。

针对于 工作现场固定且能够方便布线 的环境, 推荐使用传统方式：由网络摄像机+电源+网络电缆 的方案.

这种方式是最简单的一种方案, 且能够保证流媒体传输的稳定性.

解决方案

因为 IPC 和 NVR 在一个局域网内, 因此只要 NVR 支持的协议的 IPC 都可以对接:

1. 登录 IPC 管理端进行摄像头设置;
2. 登录 NVR 添加 IPC (协议接入可根据 IPC 型号选择);

NVR 还可以替换成具有 AI 识别的具有视频存储功能的硬件设备, 比如 IVSS.

针对于有线接入, 最重要的一点就是通过交换机将 IPC 和 NVR 划分到同一个局域网内, 这样 NVR 才能识别 IPC.

1. 内部系统直接从 NVR 上拉取视频流;
2. 外部系统需要通过 NAT 访问 NVR 拉取视频流;

关键点:

IPC/NVR 在内网, 业务系统在外网, 且业务系统能够通过 NAT 访问 IPC 或 NVR.

3.1.2 无线接入

场景三: 昆仑先锋变电站

针对于 工作现场固定但无法通过有线宽带接入 的环境, 推荐使用 4G 路由器接入方案.

解决方案一:

1. 针对于摄像头数量较少的工作地点可以不部署 NVR, 直接将 IPC 通过交换机和 4G 路由器一起组建一个局域网, 并通过 4G 上传视频流.

2. 因为 4G 物联网卡的 IP 不固定, 因此需要与远端的 NVR 通过 VPN 的方式组建局域网, NVR 才能接入 IPC.

关键地:

IPC 在内网, NVR 在外网, 需要组建 VPN 专网;

解决方案二:

1. 针对摄像头数量较多的工作地点, 建议直接在项目部部署至少一台 NVR, 用于本地存储视频, 避免因为 4G 网络的不稳定性和 IPC 数量较多的原因造成视频延迟的问题;
2. 网络拓扑图与方案一一致, 因为 4G 路由器 没有固定 IP, 为了 NVR 能够识别 IPC, 只能使用 VPN 专网;

关键点:

IPC 在内网, 上级 NVR 在外网, 需要组建 VPN 专网;

解决方案三:

我们可以使用 4G NVR 代替传统的 NVR + 4G 路由器, 其他与方案二一致.

3.2 非固定地点

针对于 工作现场不固定 的移动作业的业务场景, 一般使用 4G 摄像头采集视频, 因为 4G SIM 卡一般没有固定公网 IP, 故无法直接访问 IPC.

不同的厂商可能会有不同的平台用于对接 IPC, 比如海康威视的 海康互联 APP.

解决方案:

通过 GB/T28181 平台直接管理 IPC/NVR

1. 在 4G IPC 上设置 GB/T28181 接入平台相关信息, 主动向平台注册设备信息;
2. 平台管理接入的 IPC/NVR 等支持 GB/T28181 协议的设备;

关键点:

1. 待接入设备需要支持 GB/T28181 协议;
2. 待接入设备能访问平台;

3.2.1 类似解决方案

移动作业的业务场景一般选用带有 4G 网卡的设备接入公网, 不过带来的问题就是 IP 不固定, 这样就不能直接通过远端连接到 IPC. 为了解决这类问题, 需要一种主动注册的方案, 即 4G IPC 设备主动向平台注册设备信息, 其中 GB/T28181 协议就是典型代表, 其底层基于 SIP 和 SUP 协议实现.

一些第三方厂商也会开发符合自身业务需求的其他协议, 下面介绍 2 种比较常用的类似协议.

3.2.1.1 Ehome 协议

EHome 协议是海康威视基于移动监控场景下开发的设备主动注册私有协议，支持实时预览、录像回放、对讲、报警、定位等功能。

EHome 协议不仅实现了 GB/T28181 里所有的功能，并且在海康的不同类型设备上支持了其自定义的场合下的功能特性。包括智能报警、在低功耗场景下的设备控制及公网环境下的语音对讲指挥等场景都比 GB/T28181 协议更完善。

海康 EHome 协议架构包括三个主要部分：编码器、传输网络和监控中心。

1. 编码器：负责将音视频信号进行压缩编码，通过 IP 网络发送至监控中心。编码器支持多种分辨率和码率调整，满足不同场景需求。
2. 传输网络：基于 IP 网络，支持 TCP/IP、UDP 等协议，实现音视频数据的传输与通信。
3. 监控中心：接收来自编码器的音视频数据，进行解码、显示及存储等操作。监控中心支持多级架构，方便集中管理和调度。

特点:

1. 高清画质：采用先进的音视频压缩编码技术，提供高清画质，还原现场真实场景。
2. 低延迟：音视频传输延迟低，满足实时监控需求。
3. 双向通信：支持监控中心与编码器之间的双向通信，实现远程控制及报警通知等功能。
4. 稳定性：具备较高的稳定性和抗干扰能力，保证长时间稳定运行。
5. 安全性：采用加密传输和认证授权机制，确保数据安全和隐私保护。

3.2.1.2 萤石协议

萤石协议是萤石云开发的一种设备主动注册的私有协议, 类似于国标协议和 Ehome 协议, 如果设备同时支持萤石协议和 Ehome 协议, 只能二选一.

3.2.1.3 DAHUA 协议

大华主动注册协议是类似海康 E-home、ISUP 协议，也是前端设备向中心平台和服务注册的一种主动注册协议，对于前端网络无固定 IP 情况下对视频的联网、视频上云等场景应用尤为适用。

3.2.1.5 JTT1078

JT/1078 即<**道路运输车辆卫星定位系统-视频通信协议**>，于 2016 年发布，经过几年的沉淀，逐渐应用于道路两客一危、中高端定制化货运、出租车运输等行业。

3.2.1.4 SDK

海康, 大华, 宇视, 乐橙等厂商的 SDK 都可以完成 shebeui 在互动注册逻辑, 需要进行二次开发.

以上协议都能够解决设备无固定 IP 带来的问题, 但是除了 GB/T28181 协议外, 其他都是厂商的私有协议, 虽然在性能上优于 GB/T28181 协议, 但是需要特定的设备支持, 而 GB/T28181 协议 广泛被各大厂商设备支持, 因此选择使用 GB/T28181 协议 接入监控设备.

4. 视频接入平台

4.1 为什么需要一个视频接入平台

在没有视屏接入平台之前, 每个项目都会根据业务场景选购不同厂商的 IPC/NVR, 流媒体服务器, AI 识别服务器等, 每个项目都需要经历一次视频对接的流程, 如果有了视频接入平台:

1. 根据业务需求选购支持 GB/T28181 协议的 IPC/ NVR, 在局域网内可以使用双方支持的任意协议完成配网与对接, 比如 IPC 通过局域网接入到 NVR/ICC/IVSS;
2. 将 NVR/IVSS 等支持 GB/T28181 协议且能管理多台 IPC 的设备或将 IPC 直接接入 GB/T28181 视频接入平台;
3. 统一在 GB/T28181 视频接入平台 管理各种 IPC/NVR 等设备, 为上层业务系统提供点播, 录像查看, 视频分屏展示等常规功能;

这里的 GB/T28181 视频接入平台 相当与一个中介, 业务系统不再需要与各个设备厂商对接私有的视频接入协议, 而实施团队只需要将 IPC/NVR 等设备进行正确的组网即可, 这样能够大大缩短项目上线时间.

简而言之, 视频接入平台对下能有效屏蔽不同厂商不同协议接入带来的复杂性, 对上能够兼容各种视频查看需求, 减少重复开发成本, 便于在一处统一管理视频设备, 从而加快项目进度.

4.2 什么是 GB/T28181 平台

GB/T28181 协议指的是国家标准 GB/T 28181—2016《公共安全视频监控联网系统信息传输、交换、控制技术要求》1，该标准规定了公共安全视频监控联网系统的互联结构， 传输、交换、控制的基本要求和安全性要求， 以及控制、传输流程和协议接口等技术要求，是视频监控领域的国家标准。GB/T28181 协议信令层面使用的是 SIP（Session Initiation Protocol）协议 2，流媒体传输层面使用的是实时传输协议（Real-time Transport Protocol，RTP）协议 3，因此可以理解为 GB/T28181 是在国际通用标准的基础之上进行了私有化定制以满足视频监控联网系统互联传输的标准化需求。本文旨在说明在 FFmpeg 中增加对 GB/T28181 协议的支持，使其可以与支持 GB/T28181 协议的设备进行通信与控制，实现设备的注册、保活以及流媒体的传输。

因为是国家标准协议, 目前市面上大多数视频设备都已支持 GB/T28181 协议, 比如大华, 海康等主流的监控厂商.

一个完整的 GB/T28181 平台，通常由管理平台、信令服务器、流媒体服务器、监控设备（IPC、NVR）、管理终端等几部分组成:

1. 信令服务器 是与网络中 监控设备 与 管理终端 之间进行通信的代理，也是各级系统之间的代理，信令服务器 要有固定的 IP 地址或域名，如果要面向公网服务，还需要有公网 IP。由于是 监控设备 主动向信令服务器注册，所以 监控设备 不需要有固定的 IP。监控设备 注册到信令服务器上之后，管理者通过向信令服务器发送指令来管理 监控设备。
2. 流媒体服务器 是视频传输的代理，该系统接受监控设备发送的视频流，向视频调取方转发视频。视频调取方可以是监控监控视频的用户、第三方业务系统或者是上下级平台。协议规定监控设备通过 rtp 协议向流媒体服务器发送视频流，但是没有约定流媒体服务器向其他方转发视频的协议，因此在视频转发时具有更大的灵活性，可以根据需要采用合适的协议转发视频。

国标 GB/T28181 接入服务包含设备管理，视频流协议转换，直播监控，录像回放等。

4.3 整体流程

1. IPC/NVR 本地配置 SIP 相关信息, 然后定时向 SIP 信息服务器注册当前的设备信息, 比如 IP, 设备 ID, 设备类型等;
2. SIP 信令服务器会通过管理平台设置的相关信息进行设备验证, 比如 SIP 编号, 密码是否正确等;
3. 设备注册成功后将会展示在管理平台中, 可通过此平台维护设备的通道, 地理位置, 录像文件, 设备分组, 视频墙和流媒体服务器节点等信息;
4. 终端设备需要查看实时视频时, 管理平台会通过流媒体服务器下发拉流动作, 流媒体服务器向设备发送拉流请求后, 设备使用 RTP 协议向流媒体服务器推流;
5. 流媒体服务器在接收到 RTP 视频流后, 根据管理终端的需要可以转换成不同的视频流输出, 比如 FLV, MP4, HLS, TS, RTC ,RTMP, RTSP 等, 因此可以满足绝大多数的业务场景;
6. GB/T28181 规定 SIP 应该包含控制信号和视频信号, 控制信号用于控制球机的移动, 因此只要是支持 GB/T28181 的设备, 不再需要单独对接厂商的 SDK 去控制设备;
7. SIP 信令服务器还能够将设备的消息推送到管理平台, 比如离线, 设备监测到动作, 设备上线等, 而管理平台可以根据这些消息进行自定义业务处理;

5. 流媒体服务选型

5.1 ZLMediaKit

https://docs.zlmediakit.com/zh/

ZLMediaKit 是一套高性能的流媒体服务框架，目前支持 rtmp、rtsp、hls、http-flv 等流媒体协议，支持 linux、macos、windows 三大 PC 平台和 ios、android 两大移动端平台。

主要功能:

1. 基于 C++11 开发，避免使用裸指针，代码稳定可靠，性能优越。
2. 支持多种协议(RTSP/RTMP/HLS/HTTP-FLV/WebSocket-FLV/GB28181/HTTP-TS/WebSocket-TS/HTTP-fMP4/WebSocket-fMP4/MP4),支持协议互转。
3. 使用多路复用/多线程/异步网络 IO 模式开发，并发性能优越，支持海量客户端连接。
4. 代码经过长期大量的稳定性、性能测试，已经在线上商用验证已久。
5. 支持 linux、macos、ios、android、windows 全平台。
6. 支持画面秒开、极低延时(500 毫秒内，最低可达 100 毫秒)。
7. 提供完善的标准 C API,可以作 SDK 用，或供其他语言调用。
8. 提供完整的 MediaServer 服务器，可以免开发直接部署为商用服务器。
9. 提供完善的 restful api 以及 web hook，支持丰富的业务逻辑。
10. 打通了视频监控协议栈与直播协议栈，对 RTSP/RTMP 支持都很完善。
11. 全面支持 H265/H264/AAC/G711/OPUS。

总结: 同时支持 rtsp/rtmp 推拉流，而且支持 h265 的推拉流（推流端要支持 265 的 ffmpeg/拉流播放端也要支持 265 的播放器），支持各种格式拉流，使用者众多

5.2 Monibuca

https://m7s.live/#ui

Monibuca 是一个开源的流媒体服务器开发框架，适用于快速定制化开发流媒体服务器，可以对接 CDN 厂商，作为回源服务器，也可以自己搭建集群部署环境。 丰富的内置插件提供了流媒体服务器的常见功能，例如 rtmp server、http-flv、视频录制、QoS 等。除此以外还内置了后台 web 界面，方便观察服务器运行的状态。 也可以自己开发后台管理界面，通过 api 方式获取服务器的运行信息。 Monibuca 提供了可供定制化开发的插件机制，可以任意扩展其功能。

主要功能:

1. 针对流媒体服务器独特的性质进行的优化，充分利用 Golang 的 goroutine 的性质对大量的连接的读写进行合理的分配计算资源，以及尽可能的减少内存 Copy 操作。使用对象池减少 Golang 的 GC 时间。
2. 专为二次开发而设计，基于 Golang 语言，开发效率更高；独创的插件机制，可以方便用户定制个性化的功能组合，更高效率的利用服务器资源。
3. 功能强大的仪表盘可以直观的看到服务器运行的状态、消耗的资源、以及其他统计信息。用户可以利用控制台对服务器进行配置和控制。点击右上角菜单栏里面的演示，可以看到演示控制台界面。
4. 纯 Go 编写，不依赖 cgo，不依赖 FFMpeg 或者其他运行时，部署极其方便，对服务器的要求极为宽松。

总结: 支持自定义插件, 扩展新功能非常方便, 缺点就是部分插件收费.

5.3 SRS

https://ossrs.net/lts/zh-cn/

SRS(Simple Realtime Server)是一个简单高效的实时视频服务器，支持 RTMP、WebRTC、HLS、HTTP-FLV、SRT 等多种实时流媒体协议。

SRS 作为当前非常普遍的运营级解决方案，具备非常全面的功能，包括集群、协议网关、CDN 功能等，主要功能如下：

1. SRS 定位是运营级的互联网直播服务器集群，追求更好的概念完整性和最简单实现的代码。
2. SRS 提供了丰富的接入方案将 RTMP 流接入 SRS， 包括推送 RTMP 到 SRS、推送 RTSP/UDP/FLV 到 SRS、拉取流到 SRS。 SRS 还支持将接入的 RTMP 流进行各种变换，譬如将 RTMP 流转码、流截图、 转发给其他服务器、转封装成 HTTP-FLV 流、转封装成 HLS、 转封装成 HDS、转封装成 DASH、录制成 FLV/MP4。
3. SRS 包含支大规模集群如 CDN 业务的关键特性， 譬如 RTMP 多级集群、源站集群、VHOST 虚拟服务器 、 无中断服务 Reload、HTTP-FLV 集群。
4. SRS 还提供丰富的应用接口， 包括 HTTP 回调、安全策略 Security、HTTP API 接口、 RTMP 测速。
5. SRS 在源站和 CDN 集群中都得到了广泛的应用 Applications。

总结: 支持 rtmp 推流，早期版本支持 rtsp 推流，不知道为何移除了。支持部分格式拉流，不支持 ws-flv 拉流，使用者众多

5.5 EasyDarwin

https://www.easydarwin.org/

EasyDarwin 是由国内开源流媒体团队维护和迭代的一整套开源流媒体视频平台框架，Golang 开发，从 2012 年 12 月创建并发展至今，包含有单点服务的开源流媒体服务器，和扩展后的流媒体云平台架构的开源框架，开辟了诸多的优质开源项目，能更好地帮助广大流媒体开发者和创业型企业快速构建流媒体服务平台，更快、更简单地实现最新的移动互联网(安卓、iOS、H5、微信)流媒体直播与点播的需求，尤其是安防行业与互联网行业的衔接。

主要功能:

1. 基于 Golang 语言开发维护。
2. 支持 Windows、Linux、macOS 三大系统平台部署。
3. 支持 RTSP 推流分发（推模式转发）。
4. 支持 RTSP 拉流分发（拉模式转发）。
5. 服务端录像、检索、回放。
6. 支持关键帧缓存、秒开画面。
7. Web 后台管理。
8. 分布式负载均衡。

总结: 只支持 rtsp 推拉流，默认端口 5541，不支持其他格式拉流，如果仅仅是监控摄像头使用，非常方便，有个网页管理后台，不会过期可以一直用，缺点是功能单一，只能在他的后台查看视频流，或者用播放器播放.

上述 4 种流媒体服务对比:

5.6 MediaMTX

https://github.com/bluenviron/mediamtx

_MediaMTX_（以前称为rtsp-simple-server）是一个即用型、零依赖的实时媒体服务器和媒体代理，允许发布、读取、代理和记录视频和音频流。它被设想为一种“媒体路由器”，将媒体流从一端路由到另一端。

主要功能:

• 将直播流发布到服务器
• 从服务器读取直播流
• 流自动从一种协议转换为另一种协议
• 在不同的路径中同时提供多个流
• 将流记录到磁盘
• 验证用户身份；使用内部或外部身份验证
• 将读取器重定向到其他 RTSP 服务器（负载平衡）
• 通过 API 查询和控制服务器
• 在不断开现有客户端连接的情况下重新加载配置（热重载）
• 读取 Prometheus 兼容的指标
• 当客户端连接、断开连接、读取或发布流时运行挂钩（外部命令）
• 与 Linux、Windows 和 macOS 兼容，不需要任何依赖项或解释器，它是单个可执行文件

总结: 同时支持 rtsp/rtmp 推拉流，拉流还支持 hls/webrtc 两种方式，最新版本还支持了 srt 方式。推出来的 hls/webrtc 可以直接嵌入个 iframe 网页播放，没有任何依赖，如果希望直接在网页中播放无依赖，强烈推荐用 mediamtx

5.7 Nginx-rtmp-module

https://github.com/arut/nginx-rtmp-module

Nginx 本身是一个非常出色的 HTTP 服务器,FFMPEG 是非常好的音视频解决方案.这两个东西通过一个 nginx 的模块 nginx-rtmp-module,组合在一起即可以搭建一个功能相对比较完善的流媒体服务器. 这个流媒体服务器可以支持 RTMP 和 HLS(Live Http Stream)。

主要特性:

1. 支持 RTMP、HLS、MPEG-DASH
2. 支持 RTMP、HLS 点播
3. 可将直播视频分段存储
4. 支持 H.264 视频编解码、AAC 音频编解码
5. 支持 FFmpeg 命令内嵌
6. 支持回调 HTTP
7. 可使用 HTTP 对直播进行删除、录播等控制
8. 具有强大的缓冲功能，可确保在效率与码率间达到平衡
9. 支持多种操作系统（Linux、MacOS、Windows）

总结: 只支持 rtmp 推拉流，默认端口 1935，不支持其他格式拉流，功能极其单一，不推荐。

6. 平台选型

6.1 WVP

WEB VIDEO PLATFORM 是一个开源的基于 GB28181-2016 标准实现的开箱即用的网络视频平台，负责实现核心信令与设备管理后台部分，支持 NAT 穿透，支持海康、大华、宇视等品牌的 IPC、NVR 接入。支持国标级联，支持将不带国标功能的摄像机/直播流/直播推流转发到其他国标平台。

流媒体服务基于@夏楚 ZLMediaKit https://github.com/ZLMediaKit/ZLMediaKit
播放器使用@dexter jessibuca https://github.com/langhuihui/jessibuca/tree/v3
前端页面基于@Kyle MediaServerUI https://gitee.com/kkkkk5G/MediaServerUI 进行修改.

官网地址： https://github.com/648540858/wv

主要特性:

• 实现标准的 28181 信令，兼容常见的品牌设备，比如海康、大华、宇视等品牌的 IPC、NVR 以及平台。
• 支持将国标设备级联到其他国标平台，也支持将不支持国标的设备的图像或者直播推送到其他国标平台
• 前端完善，自带完整前端页面，无需二次开发可直接部署使用。
• 完全开源，且使用 MIT 许可协议。保留版权的情况下可以用于商业项目。
• 支持多流媒体节点负载均衡。

6.2 LiveGBS

LiveGBS 国标 GB/T28181 流媒体服务器软件，支持设备|平台 GB28181 注册接入、向上级联第三方国标平台， 可视化的 WEB 页面管理(页面源码开源)；支持云台控制、设备录像检索、回放，支持语音对讲，用户管理， 多种协议流输出，实现浏览器无插件直播。

官网地址: https://gbs.liveqing.com/docs/products/LiveGBS.html

主要特性:

1. LiveGBS 国标 (GB28181) 流媒体服务软件
2. 支持各个版本的 GB28181 协议；
3. 提供用户管理及 Web 可视化页面管理；
4. 提供设备状态管理，可实时查看设备是否掉线等信息；
5. 实时流媒体处理，PS（TS）转 ES；
6. 设备状态监测、云台控制、录像检索、回放；
7. 提供 RTSP、RTMP、HTTP-FLV、HLS 等多种协议流输出；
8. 对外提供服务器获取状态、信息，控制等 HTTP API 接口；
9. 企业私有云部署，支持 Linux & Windows;

6.3 AeroGBD

基于 GB/T 28181-2016 协议标准，提供标准接入、标准媒体、标准应用、标准共享的国标服务能力。能够接入符合 GB/T 28181-2016 的视频监控平台、硬盘录像机、摄像机、无人机、机器人等市面各类厂家设备；能够实现按照 GB/T 28181-2016 方式进行国标共享输出，提供实时视频、下级/前端录像、系统管理等应用功能，具有联网能力强、开放兼容、易用便捷等的特点。适用于智慧城市、雪亮工程、行业视频联网等各行业视频标准联网接入场景。

主要特性:

1. 接入性能强：单套支持接入>10 个下级平台，>2 万路设备，可集群扩容；
2. 共享性能强：单套支持>10 个上级共享推送，可集群扩容；
3. 视频并发高：单套支持 500 路视频并发，可集群扩容；
4. 解码性能：客户端最大支持 9 路视频同屏播放，2K 视频不低于 2 路；
5. 视频开流：实时视频开流速度小于 3 秒；前端/下级录像调阅开流小于 3 秒。
6. 录像开流： 下级平台录像开流小于 3 秒；
7. 用户并发： 单套不低于 100 个用户并发使用；
8. 部署安装： 一台起步，一键安装部署，单次标准服务器部署时间小于 10 分钟。

6.4 EasyGBS

EasyGBS 国标视频云服务提供流转发服务，负责将 GB28181 设备/平台推送的 PS 流转成 ES 流，然后提供 RTSP、RTMP、FLV、HLS 多种格式进行分发，实现 web 浏览器、手机浏览器、微信、PC 客户端等各种终端无插件播放。

主要特性:

1. 可视化页面: 提供用户管理及 web 可视化页面管理，及录像检索、回放
2. 设备状态管理: 提供设备状态管理，可实时查看设备是否掉线等信息
3. 实时流处理: 实时流媒体处理，PS（TS）转 ES，提供音视频转码能力
4. 云台控制: 基于动态组网服务创建智能网络，按需选择需要组网的网络成员实现点点互联
5. 多种流输出: 提供 RTSP、RTMP、HTTP-FLV、HLS 等多种协议流输出
6. API 接口: 对外提供服务器获取状态、信息，控制 HTTP API 接口

6.5 NTV GBS

NTV GBS 是一款成熟、功能完善、产品化程度很高的 GB28181 服务平台，从 2022 年推出以来迅速获得各技术平台报道转发，因其界面简洁舒畅、操作简单获得众多大小用户青睐。

NTV GBS 提供云服务和独立部署两种使用模式，云服务方式注册账号就可以使用，而且提供免费流量供使用；独立部署方式需要自己购买设备安装该软件。

官网地址： GB28181 视频监控国标平台 - NTV GBS

主要功能:

1. 视频监控设备远程接入、远程管理、云台控制和视频调阅，云端录像和回看
2. 支持各型号 GB28181 国标摄像头 IPC 和硬盘录像机 NVR/HVR/DVR
3. 支持各类 rtmp/rtsp 支持直播推流摄像机，兼容 ONVIF 协议
4. 视频接入分析服务，用于各种智慧应用场景，重新定义监控视频价值
5. 在网页、小程序、业务平台中无插件播放，提供 rtmp/rtsp/hls/http/websocket 播出地址
6. 支持H265视频编码，更省流量更流畅
7. 多级平台级联对接，实现上下级平台监控视频融合汇聚

6.6 AKStream

AKStream 是一套全功能的软 NVR 接口平台，软 NVR 指的是软件定义的 NVR（Network Video Recoder），AKStream 经过长达一年半的开发，测试与调优，已经具备了一定的使用价值，在可靠性，实用性方面都有着较为不错的表现，同时因为 AKStream 是一套完全开源的软件产品，在众多网友的一起加持下，AKStream 的安全性也得到了验证。

AKStream 集成了 ZLMediaKit 作为其流媒体服务器，AKStream 支持对 ZLMediaKit 的集群管理（通过 AKStreamKeeper-流媒体治理组件），可以将分布在不同服务器的多个 ZLMediaKit 集群起来，统一管理，统一调度。

官网地址：https://github.com/chatop2020/AKStream

主要特性:

1. 控制台（流媒体服务性能监控）
2. 视频广场（多视频）
3. 设备管理
4. 录像计划（本地录制）
5. 录像回放（GB28181 和本地录制）
6. 视频推流
7. 视频拉流
8. 视频本地录制
9. 云台功能

6.7 LiteCVR

LiteCVR 平台支持国标 GB/T28181、RTMP、RTSP/Onvif 协议等，以及海康 SDK、大华 SDK、海康 Ehome 等厂家私有协议，也支持标准的 API 开发接口，可集成至移动端 APP、小程序、其他业务平台播放，并提供分享链接和 iframe 地址，可直接在浏览器播放。

综合对比下来, 最终选择 WVP 平台作为视频接入平台, 主要原因如下:

1. WVP 平台全部开源且开源协议友好;
2. WVP 平台的功能较为完善, 且有整套平台, 包括管理端, SIP 服务和流媒体服务;
3. WVP 流媒体服务使用业内较为流行且社区活跃的 ZLMediaKit;
4. WVP 管理端使用 Spring Boot 开发, 可以快速的进行二次开发;

7. WVP

WEB VIDEO PLATFORM 是一个基于 GB28181-2016 标准实现的开箱即用的网络视频平台，负责实现核心信令与设备管理后台部分，支持 NAT 穿透，支持海康、大华、宇视等品牌的 IPC、NVR 接入。支持国标级联，支持将不带国标功能的摄像机/直播流/直播推流转发到其他国标平台。

项目地址：wvp-GB28181-pro

文档地址

7.1 应用场景

• 支持浏览器无插件播放摄像头视频。
• 支持摄像机、平台、NVR 等设备接入。 支持国标级联。
• 支持 rtsp/rtmp 等视频流转发到国标平台。
• 支持 rtsp/rtmp 等推流转发到国标平台。

7.2 主要特性

• 实现标准的 28181 信令，兼容常见的品牌设备，比如海康、大华、宇视等品牌的 IPC、NVR 以及平台。
• 支持将国标设备级联到其他国标平台，也支持将不支持国标的设备的图像或者直播推送到其他国标平台
• 前端完善，自带完整前端页面，无需二次开发可直接部署使用。
• 完全开源，且使用 MIT 许可协议。保留版权的情况下可以用于商业项目。
• 支持多流媒体节点负载均衡。

7.3 基础功能

1. 视频预览;
2. 云台控制（方向、缩放控制）;
3. 视频设备信息同步;
4. 离在线监控;
5. 录像查询与回放（基于 NVR/DVR，暂不支持快进、seek 操作）;
6. 无人观看自动断流;
7. 支持 UDP 和 TCP 两种国标信令传输模式;
8. 集成 web 界面, 不需要单独部署前端服务, 直接利用 wvp 内置文件服务部署, 随 wvp 一起部署;
9. 支持平台接入, 针对大平台大量设备的情况进行优化;
10. 支持检索,通道筛选;
11. 支持自动配置 ZLM 媒体服务, 减少因配置问题所出现的问题;
12. 支持启用 udp 多端口模式, 提高 udp 模式下媒体传输性能;
13. 支持通道是否含有音频的设置;
14. 支持通道子目录查询;
15. 支持 udp/tcp 国标流传输模式;
16. 支持直接输出 RTSP、RTMP、HTTP-FLV、Websocket-FLV、HLS 多种协议流地址
17. 支持国标网络校时
18. 支持公网部署, 支持 wvp 与 zlm 分开部署
19. 支持播放 h265, g.711 格式的流(需要将 closeWaitRTPInfo 设为 false)
20. 报警信息处理，支持向前端推送报警信息

7.4 部署

WVP 平台由 管理平台, SIP 服务和流媒体服务组成, 关系图如下:

1. 使用 Spring 实现了 SIP 协议, 便于二次开发;
2. 使用 MySQL 存储结构化数据;
3. 使用 Redis 存储注册信息;
4. 流媒体服务器使用开源的高性能 ZLMediaKit 实现;
5. 使用 assist 服务用于存储视频并提供历史视频查看;

WVP 平台部署可是使用 2 种方式, 一是使用源码自行编译部署, 二是使用已有 docker 镜像一键部署, 但是官方 docker 镜像最后更新与 2 年前, 因此最好的方式是使用源码编译部署, 不过为了可移植性和方便快捷的安装部署, 这里考虑使用源码打包为 docker 镜像安装部署, 具体过程后续再完善补充.

数据流向

实时视频流:

1. 业务系统向 WVP 管理平台发起观看实时视频的请求;
2. WVP 接收到请求后, 根据设备编码和通道号查询设备是否存在, 然后将编码成 RTSP 视频流协议并调用流媒体服务器进行视频流转码;
3. 流媒体服务器接收到请求后转换成 H5 能够直接播放的视频流地址, 比如 mp4/FLV 等格式;

历史视频

1. 流媒体服务器会将实时视频全部存储到服务器, 供业务端查询历史视频;
2. 流媒体服务器会将历史视频存储到 NAS;
3. IPC/执法记录仪等支持 FTP 的设备, 可以将本地的历史视频传输到 NAS 的 FTP 服务器;

7.5 使用

目前已在公司内部服务器使用最新的源码安装部署了一套 WVP 平台, 访问地址为: http://10.100.10.135:18080/#/login, 登录账号与密码: admin/admin.

7.5.1 控制台

能够展示服务器主要资源的使用情况以及设备接入数量:

7.5.2 视频墙

自带 1/4/9 个视频窗口, 如果需要更多窗口需要二开

7.5.3 设备管理

目前已接入智慧工地的 IVSS, 公司内部的 NVR 和一个 4G IPC:

实时视频:

在点播视频后, 会将视频存储到服务器:

也可以查看和下载 NVR 或 IPC 存储卡中的历史视频:

云台控制:

另一个有用的功能是电子地图, 不过目前没有页面可以直接设置, 如果后期需要可以进行二开:

7.5.4 拉流代理

可以将不具备 GB/T28181 协议但是又固定 IP 的视频设备接入到此平台:

7.6 设备对接

7.6.1 服务端

设备接入主要是需要在设备上配置 28181 上级也就是 WVP 的信息，只有信息一致的情况才可以注册成功。设备注册成功后打开 WVP->国标设备,可以看到新增加的设备；
主要有以下字段需要配置：

• sip->ip
  本机 IP，不要使用 127.0.0.1/0.0.0.0, 除非你对项目及其熟悉
• sip->port
  28181 服务监听的端口
• sip->domain
  domain 宜采用 ID 统一编码的前十位编码。
• sip->id
  28181 服务 ID
• sip->password
  28181 服务密码
• 配置信息在如下位置

7.6.2 客户端

SIP 客户端设置基本一致, 这里以大华 NVR 为例:

因为 NVR 与 WVP 平台部署在同一个局域网内, 因此 NVR 配置的 SIP 服务器 IP 为局域网 IP, 如果通过公网访问, SIP 服务器 IP 则配置为公网固定 IP.

7.7 业务系统对接

前面已经讲过, WVP 可以作为视频接入层, 负责支持 GB/T28181 协议的视频设备的接入管理, 且能够为上层业务提供多种格式的视屏流, 比如:

业务系统只需要调用 API 获取视频流地址即可接入视频, 避免了对接多家厂商设备的烦恼, 且如果后期更换了不同厂商的视频设备, 业务系统不需要任何修改, 只需要在 WVP 平台中接入即可.

在原有视频设备组网方式不变的情况下, 下面 3 个系统可以根据自身业务情况选择是否将现有视频接口使用 WVP API 替换.

7.7.1 配电监测对接

配电监测目前已使用 ZLMediaKit 代替原来的 ICC 作为流媒体服务器,并将 NVR 中的录像使用 RTSP 推送到流媒体服务器并转换成 mp4 格式, 然后由前端的 EasyPlayer 播放器播放, 目前支持实时预览和历史回看.

因为现在已经将 NVR 接入到 WVP 平台, 因此只需简单的修改即可接入视频:

1. 在配电监测平台将摄像头的设备号与通道号与摄像头绑定 (通道编号 + 设备编号唯一确认可使用的通道);

   

2. 在 WVP 平台中根据摄像头的设备号与通道号获取实时视频流地址;

   

   一次返回所有能使用的 url, 方便前端各种播放器对接

3. 在 WVP 平台中根据摄像头的设备号与通道号获取录像列表;

   

   此接口用于返回 NVR 或 IPC 本地存储卡上的录像列表

4. 使用录像播放接口播放最近的录像:

   根据录像开始时间和结束时间点播录像.

7.7.2 作业管控平台对接

作业管控平台对接同样使用配电监测对接的逻辑, 主要使用以下 3 个接口:

1. 根据设备号和通道号获取实时播放 url;
2. 根据设备号和通道号获取录像列表;
3. 根据设备号, 通道号, 录像开始时间和录像结束时间点播录像;

如果需要对球机进行控制, 还需要额外接入球机控制接口.

7.7.3 大屏对接

大屏对接分为两种情况:

1. 大屏使用业务系统的接口获取实时视频或历史回看;
2. 大屏直接使用 WVP 的接口;

上面 2 种方式可以根据业务需求自行选择, 不过如果需要使用第二种方式, 前端需要确定设备号和通道号是否正确;

7.7.4 小程序对接

小程序对接和大屏对接一样, 2 种方式都支持, 不过推荐使用第一种方式, 因为业务系统会维护设备号和通道号, 小程序只需要使用自身的业务 id 即可获取视频 url, 播放器推荐使用 HLS 协议, 支持 Android 和 iOS.

总的来说, 业务系统接入 WVP 视频接口工作量较小, 且 对现有业务系统影响较小, 新的业务可以直接对接 WVP.

7.8 大屏展示

WVP 平台自带分屏展示功能, 但是最多只支持 9 分屏, 如果需要增加分屏显示, 目前有 2 种方式:

1. 对 WVP 进行二次开发, 增加分屏数量;
2. 在业务大屏是直接开发分屏页面;

因为分屏逻辑相对简单, 无非就是在一个页面上多放几个播放器而已, 因此上述 2 种方式都能够快速实现, 所以可以根据自身业务需求自行选择, 比较推荐的做法:

1. 在调度中心使用 WVP 平台进行分屏展示;
2. 业务大屏使用自己的分屏功能展示多个视频;

8. 规划

1. 接管所有视频监控设备, 在一个平台即可查看所有视频与录像, 各部门领导可通过视频墙实时查看各项目作业情况, 满足安全审计要求;
2. 通过 API 简化业务系统对视频监控需求的集成, 缩短开发时间;

为满足以上 2 个目标, 需要以下前提:

1. 设备需要支持 GB/T28181 协议;
2. 设备能够访问到平台 (通过公网或 VPN 均可);
3. 业务系统能够访问视频流服务器(通过公网或 VPN 均可);

平台架构图:

8.1 资源规划

8.1.2 硬件资源

目前使用 8C 16G 服务器, 在接入 3 个设备, 共计 95 视频通道的情况下, 内存占用 40%, 因为未进行任何点播视频, CPU 占用较低(CPU 主要用于视频编解码), 且因为每次点播后会存储视频, 因此随着时间的推移, 磁盘占用会越来越大, 因此考虑到后期接入的设备数量以及视频保存时间, 在 3 年内的至少满足 100 路视频的接入需求下, 对硬件资源进行如下评估:

8.1.2.1 磁盘

1. 存储方式

云厂商提供的 OSS 服务能够解决诸如视频, 图像等文件的存储和调取服务, 收费以便按照空间大小收费, 因此这里不考虑云存储方案, 一是因为视频文件较大, 存储费用会较高; 二是视频这类文件较为敏感, 使用云存储无法保证数据安全.

2. 容量评估

目前业务上已使用到的监控设备如下:

1. 重庆地铁 15 号线项目, IPC 数量 7 个, 历史录像直接存储到项目部上的 NVR 中;
2. 智慧工地项目, IPC 数量 280 个, 历史录像直接存储到项目部上的 IVSS 中;
3. 雷波矿山项目, IPC 数量在一年后计划安装 100 +, 历史录像直接存储到项目部上的 NVR 中;
4. 变电站, 场站上的 IPC 目前在用的只有昆仑先锋变电站和铁山坡一共 10 台, 历史录像存储到调度中心的 NVR 中;
5. 集团安全监控项目, IPC 数量为 30 台, 历史录像存储在设备的 TF 卡中;
6. 执法记录仪数量 30 台, 历史录像存储在设备的 TF 卡中;
7. 无人机数量 8 个, 历史录像存在设备的 TF 卡中;

接入 WVP 平台的设备录像分为两种模式:

1. 云端录像: 只有主动查看设备实时视频时才会录制, 视频文件存储在 WVP 服务器中;
2. 设备录像: 支持本地录制的设备所存储的录像, 如果是 NVR 则保存在 NVR 服务器中, 如果是 IPC 则保存在 TF 卡中;

设备录像:

因为设备录像都是滚动录制, 所以需要评估一个作业周期内的录像大小, 这里说明一下 IPC 所需要的 TF 卡存储大小评估方式:

1. 作业持续时间, 比如一天只录制 8 个小时视频;
2. 视频流码率: 码率越大所需要的存储空间越大, 比如码率为 1Mbps;
3. 录像存储时间, 比如执法记录仪需要保存至少 7 天的数据;

按照上述要求估算本地存储空间:

1Mbps * 1024Kbps/8 * 60 秒 * 60 分 * 8 小时 * 7 天 * 1 通道/1024/1024≈ 25G, 再加上一些元数据的存储空间, 所以建议至少配置 32G 的 TF 卡.

NVR 自带磁盘阵列且有一套完善的录像存储和扩容机制, 因为不同的项目对视频储存的要求不一样, 所以 NVR 的存储空间最好根据自身业务需求让厂家推荐并配置合理的磁盘阵列, 因为 WVP 对应的都是 云端录像, 所以这里不对 NVR 的本地存储做讨论.

云端录像:

只有在主动点播视频的情况下才会触发云端录像功能, 且录制的文件保存在 WVP 的服务器中, 为了在满足业务需求的前提下减少硬件投入, 这里对 WVP 所需的磁盘阵列进行大小评估:

1. 点播录像:

1. 按照总共 100 个视频通道, 每天查看 10 次, 每次查看存储 10 分钟的录像;
2. 每个视频流码率统一为 1Mbps;
3. 录像至少保存 7 天;

计算公式如下:

1Mbps * 1024Kbps/8 * 60 秒 * 10 分钟 * 10 次 * 7 天 * 100 通道/1024/1024 ≈ 512G

2. 录像备份

像执法记录仪这类具备录像文件上报的设备, 会通过 FTP 将录像文件上传到 WVP 服务器, 这类设备的所需的磁盘大小评估方式为:

1. 从作业管控-作业计划管控-记录仪录像可以看出, 10 分钟的视屏占用 300M;
2. 按照一天工作 8 小时计算;
3. 录像至少保存 7 天;

计算公式如下:

300M * 6 * 8 小时 * 7 天 * 30 个设备/1024/1024 ≈ 3T

结合点播录像和录像备份的场景, 至少应该准备 4T 的磁盘, 且为了保证数据安全, 最少需要 2 块 4T 组成 RAID1, 至少保证在一块磁盘损坏的情况下数据不会丢失.

3. 扩容方式

磁盘阵列首先使用 2 块 4T 磁盘组成 RAID1:

RAID 1: 2 块硬盘或以上，利用镜像技术，在损失不超过一个成员磁盘时提供容错功能。
优势：数据安全性最高，一块坏了，其它硬盘有完整数据，保障运行。
缺点：容量低，硬盘使用率为 50%

可用空间为 4T, 但是能够在一块磁盘损坏的情况下保证数据不丢失, 在后期如果磁盘空间不足, 需要进行无损扩容来保证业务的连续性, 这里给出几种扩容方案:

方案一:

增加一块 4T 磁盘, 使用总共 3 块 4T 磁盘从 RAID1 迁移到 RAID5, 磁盘阵列可用容量从 4T 增加到 8T;

RAID 5: 3 块硬盘或以上，同时使用条带和奇偶校验技术。提供与 RAID0 相似的读取速度，在损失不超过一个成员磁盘时仍能正常运行。
优势：RAID5 兼顾 RAID0 与 RAID1 的优势。RAID5 最少需要三块硬盘，通用是用 4 块硬盘，其中有一块硬盘用来做数据冗余的，换新硬盘，系统会自动进行数据同步。
缺点：只允许单盘故障，一盘出现故障尽快处理。有盘坏情况下，IO/CPU 性能狂跌。

方案二:

增加 2 块 4T 磁盘, 从 RAID1 迁移到 RAID6;

RAID 6：4 块硬盘或以上，类似 RAID5，对数据安全性要求高，性能要求不高的可选择
优势：RAID6 是在 RAID5 基础上为加强数据保护而设计的。可允许损坏 2 块硬盘
缺点：性能提升不明显

8.1.2.2 服务器

服务部署架构:

需要部署的服务列表:

以上服务可以按照功能和所需资源大小部署到 2 台服务器中:

8.1.3 网络资源

假设同时查看 32 路摄像头, 分比率统一为 1080P, 帧率为 25 fps, 视频编码类型为 H.265, 需要的带宽为:

(1920 * 1080 * 24 位色 * 25 * 32)/300压缩率/1024/1024 * 1.3带宽系数 ≈ 127M

为保证更多数量的通道同时查看的需求, 最好使用 200M 的带宽.

硬件清单:

主机: DELL R750XS

CPU: 4310 2 颗
内存: 16G
磁盘: 1.92T * 4
阵列: H755
电源: 800W 一个

26499 * 2 + 1500 * 6 + 4500 * 2 + 11146 = 82144

2023-12-18 今日最新价格, 服务器 2U + 固态硬盘, 单台 37000 元, 因此总价格变更为: 37000 * 2 + 11146 = 85146 元

后期优化方案:

8.1.4 网络拓扑图

方案一:

方案二

使用万兆交换机组万兆局域网

1. 因为视频存储文件较大, 为加快文件访问速度以提升服务体验, 内网使用万兆通讯, 需要分别为服务器和 NAS 添加万兆网卡. 市面上万兆电口的交换器较少, 且电口发热量大, 目前选用万兆光口交换机; NAS 只支持万兆电口网卡, 因此需要增加一个万兆光转电口; 2 台服务器使用万兆光口接入交换机.
2. 其他千兆口用于接入其他客户端;
3. 流媒体服务器通过万兆交换机将视频文件存储到 NAS;

方案三

使用千兆交换机, 小范围组万兆内网

1. 使用 NAS 自带千兆网口和 2 台服务器通过千兆交换机组成局域网, 其他客户端通过交换机与服务器和 NAS 连接;
2. 内部使用万兆网卡直连, 让服务器和 NAS 之间组成内部网络, 加快文件传输速度;

方案二 比 方案三 组网方式简单, 但是价格且多出一个光转电接口, 整体价格较方案二贵.

NAS 视频备份:

群晖 DS923+ 自带 2 个千兆网口, 可再扩展一个万兆网卡.

服务器:

脑图