简介：面向Windows平台IE浏览器的NetSurveillance DVR插件，是一套通过网络远程访问监控设备的轻量级解决方案，主要针对安防工程人员、运维人员和二次开发者。资源包共61个文件、约1.07MB，核心构成包括ActiveX控件、H.264解码播放库、多语言语言包、界面皮肤图片及设备配置文件：dll文件承担解码与通信，ocx控件提供浏览器交互接口，lang资源支持多语言界面切换，jpg/bmp负责按钮与面板皮肤，ini/xml保存设备、回放和云台等参数，整体结构清晰便于按需调用。插件内置PTZ云台控制、通道切换、回放面板与安装脚本，可快速部署到IE环境并接入监控网络，也方便开发者在自有系统中集成摄像头预览与控制能力。压缩包内按控件、语言、皮肤、配置等类别组织文件，便于对照学习或进行模块级替换。目前已有1051人学习下载，适合需要理解DVR插件组成、进行界面汉化或二次开发的工程师参考。
1. 一台旧电脑就能跑的 NetSurveillance DVR：从录像盒子到开源自建
店里装了 8 个摄像头，买台品牌 DVR 要两千多，云存储年费又是大几百，画质还被平台二次压缩。NetSurveillance 字面上是网络视频监控，配上 DVR（Digital Video Recorder）这个载体，就是一套能接入 IP Camera、能本地存储、能 Web 回放、能按事件检索的录像系统。我自己给仓库做了一套，核心只花了一个旧电脑加一块 4TB 硬盘的成本。这套方案适合小店主、仓库管理、弱电集成工程师，以及任何被商用录像机授权费和私有协议绑住的人。
2. 搭建最小可用系统：硬件底线与一套 Docker Compose
先说结论：别为了省 500 块钱去买二手工控机专用主板，也不建议在树莓派上硬扛 4 路 1080p 录像。按我踩过的坑，一套稳定的 NetSurveillance DVR 硬件选型有明确底线，同时软件栈选型直接决定你未来三个月是在装环境还是在看录像。
2.1 硬件底线： CPU、内存、硬盘与网卡的取舍
NetSurveillance DVR 的核心负载是两件事：把 RTSP 视频流解码出来，再把解码后的画面按帧交给检测器或编码器。4 路 1080p 同时做检测和录像，CPU 占用大头在 FFmpeg 的解码和重编码上。我的实际经验是：CPU 用 i3-4130 以上，内存 8GB 起，系统盘单独上一块 64GB SSD，录像盘用 4TB 紫盘或企业盘。Intel 核显的 Quick Sync（QSV）硬件转码能把 CPU 占用压到软解的 1/3 左右，所以选 CPU 时优先看核心显卡型号，而不是只看主频。
硬盘是整个 DVR 里最不能省的部分。7x24 小时连续写入，普通家用盘跑两三个月就开始冒坏道。监控紫盘（WD Purple / 希捷 SkyHawk）至少能撑三年以上。还有人问我能不能把录像存在 NAS 上，可以，但你要额外处理 NFS/SMB 的并发性能和断线重连问题——刚上手不要碰。我一般把录像目录直接挂载到本机物理盘，系统盘和录像盘分开，Docker 数据也放系统盘。这样系统崩了，录像还在。
网络上，千兆交换机是底线，并且一定要确认网线协商到了千兆。等到了第 5 章你会看到，我至少有一半的"卡顿"排查是在看 ethtool 协商速率。
2.2 软件栈选型：为什么选 Frigate 而不是 ZoneMinder
老牌开源监控方案 ZoneMinder 功能全，但它的录像文件管理非常笨重，Web 界面停留在上一个时代。新项目我基本不推荐。Frigate 是更现代的 NetSurveillance 后端：录像直接分段写 MP4，Web 回放流畅，自带基于 OpenVINO / Coral TPU 的 AI 目标检测，而且整个项目 Docker 化，升级和回滚都很干净。
| 对比项 | ZoneMinder | Frigate |
|---|---|---|
| 录像管理 | 按事件存片，文件多且碎 | 按时间分段 MP4，循环覆盖策略清晰 |
| AI 检测 | 运动检测为主，误报多 | 支持 OpenVINO/Coral，可识别行人车辆 |
| 界面体验 | 老式 Web 控制台，功能多但难看 | 现代 Web UI，支持时间轴拖拽回放 |
| 维护成本 | 依赖多，PHP/MySQL，迁移费劲 | Docker 单容器，配置是 YAML |
| 硬件加速 | 配置繁琐 | 预设了 Intel QSV / VAAPI 加速参数 |
Frigate 的定位是 NVR（Network Video Recorder），但现在的安防场景里 DVR 和 NVR 边界已经模糊：输入源是网络摄像头，输出是本地硬盘录像。所以我说的 NetSurveillance DVR，指的就是这一套基于开源 NVR 的完整录像系统。Frigate 对摄像头的要求是有 RTSP 主码流和子码流，后面接入摄像头的时候我会细讲。
2.3 用 Docker Compose 一步拉起 DVR 服务
我习惯把整个 DVR 服务放在/opt/frigate目录下，用 Docker Compose 管理。下面的docker-compose.yml是我在 Intel 核显平台上稳定跑了一年多的版本：
services: frigate: image: ghcr.io/blakeblackshear/frigate:stable container_name: frigate restart: unless-stopped privileged: true devices: - /dev/dri/renderD128:/dev/dri/renderD128 volumes: - /etc/localtime:/etc/localtime:ro - /opt/frigate/config:/config - /media/recordings:/media/frigate ports: - "8971:8971" # Web 管理界面 - "8554:8554" # 内置 RTSP 服务，供客户端拉流 - "8555:8555" # WebRTC 实时预览 environment: - FRIGATE_RTSP_PASSWORD=custom_password - LIBVA_DRIVER_NAME=iHD启动命令很简单：在/opt/frigate目录下执行sudo docker compose up -d，然后等 30 秒左右，浏览器打开http://<DVR主机IP>:8971就能看到登录页。
几个关键点：/dev/dri/renderD128映射是让容器访问 Intel 核显的 VAAPI 能力；LIBVA_DRIVER_NAME=iHD指定 Intel 核显驱动；privileged: true是为了让容器能读取摄像头时间戳和系统时钟，Frigate 官方文档也建议这样，但注意这台机器不要放公网。没有 Intel 核显的机器可以删掉devices和LIBVA_DRIVER_NAME两行，系统会退回到 CPU 软解，4 路 1080p 也能跑，就是 CPU 占用会到 80% 以上。
启动后先别急着接摄像头，直接看日志验证服务是否正常：
cd /opt/frigate sudo docker compose logs -f --tail 50能刷出Starting Frigate和Camera start up相关日志就说明服务起来了。这一步走通，后面的摄像头接入只是在 YAML 里加几行的问题。
3. 三个必调参数：编码、存储与录像计划
很多 NetSurveillance 新手翻车，不是摄像头没接对，而是参数没有概念地乱填：分辨率拉满、码率选最大、录像保留 30 天，结果硬盘三天就满，回放时画面全是马赛克。这一章我给出一套可以直接抄的参数设定，以及背后的计算逻辑。
3.1 编码参数：H.264 还是 H.265，码率控制与 GOP 怎么设
摄像头端编码，我几乎只用 H.264，不用 H.265。说来话长：H.265 确实省一半存储，但在 FFmpeg 的开源解码链路里兼容性参差不齐，而且 Web 回放时浏览器对 H.265 的硬件解码支持到现在都是玄学。为了录像稳定和回放不折腾，H.264 是当前 NetSurveillance DVR 最不容易翻车的选择。
码率控制一定要设CBR（固定码率），不要用 VBR。VBR 在大范围运动场景下码率会突然飙到设定值的 3-5 倍，造成的直接影响就是网络瞬断、画面花屏。下面是我给摄像头设的基准参数：
- 主码流：1080P，15fps，H.264，CBR 上限 4Mbps
- 子码流：720P，5fps，H.264，CBR 上限 1Mbps
- I 帧间隔（GOP）：30（即 2 倍帧率）
I 帧间隔这里容易被忽略。FFmpeg 在-ss快速定位录像时，靠的是"跳到最近的 I 帧再解码"。GOP 越大，定位越慢、越不准。30 这个值在存储压力和 seek 精度之间比较均衡。帧率 15fps 对监控足够，但如果你的场景是车道或者体育场馆这类快速移动画面，要提到 25fps，否则画面拖影严重。
3.2 存储容量算账：一张 4TB 硬盘能录多久
先记住一个换算公式：单路每小时占用 = 码率（Mbps）÷ 8 × 3600 ÷ 1024（GB）。比如 4Mbps：4 ÷ 8 = 0.5MB/s，0.5 × 3600 = 1800MB/h，约 1.76GB/h。一天 42.2GB，4TB 硬盘实际可用约 3.6TB，单路就能录 85 天。
下面是常见码率的参考表：
| 单路码率 | 每小时占用 | 每天占用 | 4TB 单路可录时长 |
|---|---|---|---|
| 1.5 Mbps | 0.66 GB | 15.8 GB | 约 227 天 |
| 2 Mbps | 0.86 GB | 20.6 GB | 约 174 天 |
| 4 Mbps | 1.76 GB | 42.2 GB | 约 85 天 |
| 8 Mbps | 3.52 GB | 84.5 GB | 约 42 天 |
注意这是单路独占一块 4TB 盘的数字。实际场景是多路共享，比如 4 路 × 4Mbps = 168GB/天，4TB 盘能录 21 天。如果要求录 30 天，要么降低到 3Mbps，要么加一块硬盘。
这套计算方式在 Frigate 里还要考虑事件录像的额外占用。我的建议是连续录像用 4Mbps 主码流，事件录像共享同一份主码流数据，不需要重复计算。真正会多占存储的是"检测分辨率"，也就是子码流，1Mbps 一天才 10GB 左右，可以忽略。
3.3 录像计划：连续录像与事件录像的组合打法
Frigate 的录像策略用 YAML 配置，核心是区分record（连续录）和events（按事件录）。我的配置长这样：
mqtt: enabled: false cameras: shop_entrance: ffmpeg: inputs: - path: rtsp://admin:password@10.0.0.64:554/Streaming/Channels/102 roles: - detect - path: rtsp://admin:password@10.0.0.64:554/Streaming/Channels/101 roles: - record detect: width: 640 height: 360 fps: 5 record: enabled: true retain: days: 7 events: pre_capture: 5 post_capture: 5 retain: default: 30 mode: motion逻辑说明：第一个输入走子码流，只承担检测任务，640×360 的分辨率足够 AI 识别行人和车辆；第二个输入走主码流，负责录制高清画面。检测和录像用不同的流，能把 CPU 占用降一半以上——这是 Frigate 里的标准做法。retain.days: 7表示普通录像保留 7 天，events.retain.default: 30表示带事件标记的片段保留 30 天，pre_capture: 5和post_capture: 5表示事件触发前后各多录 5 秒，避免"人刚好走出画面"的尴尬。
mode: motion这里有个隐蔽坑：Frigate 会用检测结果把连续录像切出事件片段，motion模式会把光线变化、飞虫、树叶晃动都算成事件，长期运行会导致事件片段占满磁盘。我一般配合 AI 检测器后改成active_objects，只保留真正有行人或车辆的片段，事件存储能省一半以上。这个配置项在接完摄像头后可以随时调整，不用重启容器，Frigate 会自动热加载。
4. 接入摄像头与客户端：ONVIF 发现与 RTSP 拉流的落地细节
摄像头接入是最容易劝退新手的一步：不同品牌的 RTSP 路径格式不一样，ONVIF 端口也五花八门。我的工作流是：先用 ONVIF 的 WS-Discovery 协议自动发现设备，拿到设备的服务地址，再逐个验证 RTSP 拉流路径，最后统一写进 Frigate 配置。
4.1 局域网内用 WS-Discovery 脚本自动发现摄像头
ONVIF 规范的设备都会监听 UDP 3702 端口，响应多播探测请求。不需要装任何品牌工具，一个 Python 脚本就能把网段里的摄像头挖出来：
import socket probe_msg = '''<?xml version="1.0" encoding="UTF-8"?> <e:Envelope xmlns:e="http://www.w3.org/2003/05/soap-envelope" xmlns:w="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:dn="http://www.onvif.org/ver10/network/wsdl"> <e:Header> <w:MessageID>uuid:net-surveillance-dvr</w:MessageID> <w:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</w:To> <w:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</w:Action> </e:Header> <e:Body> <d:Probe> <d:Types>dn:NetworkVideoTransmitter</d:Types> </d:Probe> </e:Body> </e:Envelope>''' sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.bind(("", 3702)) sock.settimeout(10) sock.sendto(probe_msg.encode(), ("239.255.255.250", 3702)) while True: try: data, addr = sock.recvfrom(65535) print(f"发现设备: {addr[0]}") # 这里可以进一步解析 XAddr 来获取 RTSP 地址 print(data.decode("utf-8", errors="ignore")[:1500]) except socket.timeout: print("扫描结束") break这段脚本的核心是多播地址239.255.255.250:3702，这是 ONVIF WS-Discovery 的标准地址。脚本跑完会把所有支持 ONVIF 的网络摄像头 IP 列出来。注意：如果摄像头在别的网段，脚本可能发现不了，需要先确认本机和摄像头在同一局域网内。
拿到 IP 后，我一般会再用curl访问摄像头的 HTTP 配置端口确认品牌标识，方便后面拼 RTSP 路径。这一步比盲目在网上搜索某个杂牌摄像头的路径靠谱得多。
4.2 RTSP 拉流 URL 的常见格式与路径表
不同品牌摄像头 RTSP 路径差异很大，但主流厂牌的格式基本固定。下面是公开的标准路径格式，可以直接套用：
| 品牌 | 主码流 RTSP | 子码流 RTSP |
|---|---|---|
| 海康 Hikvision | rtsp://user:pass@ip:554/Streaming/Channels/101 | rtsp://user:pass@ip:554/Streaming/Channels/102 |
| 大华 Dahua | rtsp://user:pass@ip:554/cam/realmonitor?channel=1&subtype=0 | rtsp://user:pass@ip:554/cam/realmonitor?channel=1&subtype=1 |
| 宇视 Uniview | rtsp://user:pass@ip:554/unicast/c4s1/live | rtsp://user:pass@ip:554/unicast/c5s1/live |
| TP-LINK | rtsp://user:pass@ip:554/stream1 | rtsp://user:pass@ip:554/stream2 |
密码里如果包含@、:等特殊字符，需要做 URL 编码，比如admin:test@123要写成admin:test%40123。不然 RTSP 解析会从最后一个@开始分割，直接导致认证失败。我在这上面翻过一次车，花了一个小时排查日志才发现是密码里的@没转义。
验证路径是否正确，不需要先写进 Frigate。用 FFmpeg 直接拉一帧看最直观：
ffprobe -rtsp_transport tcp -i "rtsp://admin:pass@10.0.0.64:554/Streaming/Channels/101" \ -show_streams -format json -loglevel error | head -50-rtsp_transport tcp是关键：很多摄像头默认用 UDP 传输 RTSP，但 UDP 在弱网环境丢包严重。强制 TCP 后，网络抖动时的恢复速度快很多。如果 ffprobe 能输出 video stream 信息，说明路径和认证都对。
4.3 给 Frigate 添加摄像头：从验证到写配置
把验证过的 RTSP 路径填回/opt/frigate/config/config.yml，Frigate 会自动重载配置。我会在cameras下为每个摄像头建一个独立节点，命名规则用"位置+方位"，方便后续检索事件：
cameras: shop_entrance: ffmpeg: inputs: - path: rtsp://admin:pass@10.0.0.64:554/Streaming/Channels/102 roles: - detect - path: rtsp://admin:pass@10.0.0.64:554/Streaming/Channels/101 roles: - record record: enabled: true保存后等 10 秒，Frigate 会热加载配置。如果摄像头里的用户没有 ONVIF 权限，Frigate 也能纯靠 RTSP 拉流，只是没法通过 ONVIF 控制云台等功能。测试时发现画面出不来，第一反应是看日志：
docker compose exec frigate cat /tmp/frigate.log | grep -i error | tail -20日志里的关键错误有三类：401 Unauthorized是密码或认证方式不对，Connection refused是端口不通，Received any packet from the stream is less than expected是码流参数和检测设置不匹配，解决方向是把detect的分辨率帧率调到和子码流一致。
5. 避坑指南：NetSurveillance DVR 最常见的 5 个翻车点
跑运维时，90% 的问题不是配置不会写，而是设备和服务在特定环境下的"小脾气"。下面是 5 个我真实遇到过的故障，按"现象 → 原因 → 解决"拆开写，你在自己的 DVR 上大概率也会碰到。
5.1 摄像头掉线但网络通：并发连接数超限
现象：Frigate 日志出现Cannot connect to camera，但ping 摄像头IP完全通，Web 管理页面也能登录。重启摄像头后恢复，过几小时又掉线。
原因：摄像头自带 RTSP 并发连接数上限，多数家用摄像头默认只允许 4-8 路。如果你同时开着 VLC 预览、手机 App 观看，再加 Frigate 的 detect 和 record 两路拉流，连接数就爆了。摄像头会拒绝新连接，但 Web 管理页面走 HTTP 是另一套逻辑，所以"网络通"给了人错觉。
解决：把并发上限调高，或者约束没必要的实时预览。我在摄像头管理页把 RTSP 最大连接数从 4 调到 16，顺手把 VLC 偶尔开的预览关掉，问题就消失了。如果你的摄像头不支持调整连接数，那就只能减少拉流端：Frigate 只开一路主码流做 record，用子码流做 detect，不要同时在多个页面看实时画面。
5.2 画面卡顿与花屏：VBR 码率失控
现象：平时画面正常，傍晚或者人流量大的时候画面开始马赛克、卡顿，影响持续几分钟后自行恢复。单独测一路时一切正常。
原因：摄像头设置为 VBR 码率控制时，在大范围运动场景下（比如卷帘门升起、多人进出）码率会瞬间飙到设定值的 3-5 倍。如果交换机或网线质量不佳，突发流量会直接导致丢包和花屏。
解决：把摄像头编码改成 CBR，主码流上限锁死。同时要检查网线协商速率：ethtool eth0 | grep Speed，如果显示100Mb/s而不是1000Mb/s，基本可以断定是网线或水晶头问题，直接换线。这两个动作下去，花屏基本会绝迹。
5.3 录像文件损坏：最后一段总是放不出
现象：回放时最后一个时间段的录像文件播放器报错，或者画面卡在最后几秒无法继续。损坏的往往正好是断电停机那一段。
原因：MP4 的文件结构决定了它必须在文件末尾（或通过moov) 记录完整的索引信息。FFmpeg 边录边写的分段 MP4 如果碰到断电、容器强制停止，最后一段文件没有正常 finalize，索引不完整，自然就坏了。
解决：把 Fridge 的分段时长控制短一点，我一般让录像文件按segment大小切，单个文件在 20-30 秒左右。这样断电最多丢最后一段 30 秒录像，风险可接受。已经损坏的文件，用 FFmpeg 可以尝试修复：
ffmpeg -i corrupt.mp4 -c copy -movflags +faststart repaired.mp4-c copy不做重编码，速度快，逻辑是把损坏文件的moov元数据重新整理到文件头部。修复后文件就能正常拖动时间轴了。注意这招对文件完全没写入索引（比如 0 字节）的情况无效，那种只能放弃。
5.4 时间轴错乱：NTP 没同步带来的回放灾难
现象：录像回放的时间轴和实际时间对不上，事件检索出来的片段时间戳差了几个小时，甚至显示 1970 年。
原因：摄像头和 DVR 主机的系统时间不同步。摄像头自带 RTC 电池，时间会越走越偏；DVR 主机如果没配置 NTP，也会漂移。Frigate 的事件时间戳依赖摄像头流里的时间，源头错，事件时间必然错。
解决：DVR 主机必须同步 NTP。Ubuntu 上直接：
sudo apt install chrony -y sudo systemctl enable --now chrony chronyc sources -v然后到每台摄像头管理页，把 NTP 服务器填成 DVR 主机的 IP，同步周期改成 1 小时。摄像头和主机都指向同一时间源，时间轴就不会乱。我这里强调一句：别依赖摄像头自动校时，很多杂牌摄像头的 NTP 实现就是个空壳子。
5.5 硬盘提前写满：事件保留策略没生效
现象：设置了retain.days: 7，但运行 3 天磁盘就满了，事件文件占据了大量空间。
原因：Frigate 的事件保留策略mode: motion会把所有"有像素变化"的片段都算作事件。夜晚的灯光变化、雨滴打在镜头上、飞虫飞过，都会被保留 30 天。我遇到过一套系统，一天的正常录像只有 60GB，但事件片段占了 120GB。
解决：把事件保留模式改成active_objects：
record: events: retain: default: 30 mode: active_objects改完后 Frigate 只会把检测到行人、车辆等具体目标的片段作为事件保留。存量事件的话，直接在 Web 界面的事件列表里全选删除即可，不影响连续录像的历史记录。这个配置改完不需要重启，Frigate 会热加载。不过要注意，active_objects依赖检测器正常工作；如果没接 AI 检测器，事件可能被过滤得一个都不剩，那就还是用motion吧。
6. 进阶：录像快速检索与断流自愈的两个实用技巧
系统跑顺之后，我的下一步习惯是把两个"日常刚需"打磨到顺手：一是想找某段录像时不用对着时间轴一点一点拖；二是服务或者摄像头掉线时，能自动恢复。
6.1 用 FFmpeg 在大录像文件中秒定位关键片段
Frigate 的录像默认按时间分段，但在大时间跨度上回放还是要靠拖动时间轴。如果我要快速截取某个事件前后 30 秒的画面，比如"今天下午 3 点 15 分有人进入仓库"，我直接用 FFmpeg 从事件 API 拿到时间戳，然后定位导出：
ffmpeg -ss 15:15:00 -i /media/frigate/recordings/2025/06/17/15/15/00.mp4 \ -t 30 -c copy -an clip.mp4关键在-ss放在-i之前。FFmpeg 会基于关键帧快速 seek 到指定时间点，再开始输出，速度非常快。如果放在-i后面，它会从头解码该文件的所有帧直到到达指定时间，一个几小时的视频能等到你怀疑人生。
-c copy表示只复制编码数据，不重编码，秒级完成。-an去掉音轨。这个命令同样适用于从任何品牌的 DVR 录像文件里截取片段，是我平时最常用的后悔药。
6.2 崩溃自动拉起：一个 watchdog 脚本加 systemd 定时器
Docker 的restart: unless-stopped只能处理守护进程崩溃，但 Frigate 内部可能出现异常状态：比如检测进程挂掉但容器还活着，或者摄像头长时间拉流导致内存泄漏。我用一个 watchdog 脚本兜底，每 5 分钟检查一次容器状态和录像目录增长，不对就重启容器。
#!/bin/bash # /usr/local/bin/frigate-watchdog.sh # 检查容器是否在运行，不在就拉起；检查录像目录是否在增长，停滞则重启 CONTAINER="frigate" RECORD_DIR="/media/recordings" if ! docker ps --format '{{.Names}}' | grep -q "^${CONTAINER}$"; then cd /opt/frigate && docker compose up -d exit 0 fi SIZE_BEFORE=$(du -sb "$RECORD_DIR" 2>/dev/null | cut -f1) sleep 60 SIZE_AFTER=$(du -sb "$RECORD_DIR" 2>/dev/null | cut -f1) if [ "$SIZE_AFTER" -le "$SIZE_BEFORE" ]; then docker restart "$CONTAINER" fi脚本逻辑分两段：第一段判断容器是否存在，没有就直接拉起；第二段用 60 秒内录像目录的字节数变化判断服务是否在正常写录，如果完全停止增长，说明内部卡死，重启容器。把脚本放进 crontab：
*/5 * * * * /usr/local/bin/frigate-watchdog.sh这套机制上线后，我基本不用再担心半夜摄像头掉线导致的"无人值守黑匣子"状态。故障恢复不是靠人工盯，而是靠自动兜底。我现在的习惯是，任何新部署的 NetSurveillance DVR 站点，开机第一件事就是把 NTP 校时、watchdog 脚本、事件保留策略这三样配置好。前 30 天把系统调到零干预，后面才能睡安稳觉。希望这些落地的参数和坑，能帮你少走我走过的那几圈弯路，一台旧电脑加一块监控盘，完全能把商用 DVR 该干的活稳稳接住。
本文还有配套的精品资源，点击获取
