摄像头 NAS接入 RTSP与本地存储
# 《摄像头NAS本地化存储的需求背景与现有方案痛点分析》
现在家用、小型商铺装摄像头的人越来越多，大家最先接触到的基本都是厂家配套的云存储服务——按月付年费，存在云端随时调看，听起来方便，但真用起来不少人会嫌麻烦。首先是持续的付费成本，装三四个摄像头，一年续费就得小几百，日积月累也是一笔不小的开支。其次是隐私顾虑，摄像头拍的全是家里、店里的画面，存在第三方云端，哪怕厂商说加密，不少人还是放心不下，万一出现数据泄露，后果没法预料。还有就是网络依赖性，家里断网的时候云存储直接用不了，关键时刻掉链子，想回看录像是不可能的。
这个时候把摄像头接入NAS做本地化存储、RTSP流管理的需求就起来了。对比云存储，NAS本地化存录像，一次投入硬件之后不用再交年费，所有数据都存在自己手里，完全不用怕隐私泄露，断网也能正常录存，后续扩容也方便，多余的NAS空间还能存别的文件，性价比和自主性都高太多。
之前我们聊过用Micam三件套把摄像头接入飞牛NAS的方案，这个方案的核心逻辑是把各个品牌摄像头的RTSP流统一转码整理，再集成到飞牛NAS的管理界面里，实现统一查看、存储和回放，对配置比较高的成品NAS来说，这个方案用起来挺顺手，功能也全。
但问题出在很多玩家手里没有高配置的成品NAS，不少人是用旧设备改的NAS，或是把低配置的旁路由拿来兼做摄像头存储，比如大家很常用的2GB内存版N1盒子，就是典型的低配设备。Micam三件套的转码、流管理都比较吃资源，我自己实际测过，开一个摄像头的转码，N1盒子的CPU占用就能跑到60%以上，开两个直接直奔90%，内存也能吃掉快1.2GB，剩下的资源根本不够干别的，哪怕只开一个摄像头，连续跑四五天之后，就容易出现进程闪退、录像断档的情况，有时候甚至会把整个盒子拖垮，需要重启才能恢复。
而且这个方案为了适配多端观看自动转码，不管你需不需要转码，它都默认后台跑着转码服务，对本来就没多少资源的低配设备来说，完全是不必要的浪费。很多玩家只需要简单存RTSP流的录像，不需要额外转码，也要白白消耗硬件性能，这对于想用闲置低配置设备改摄像头存储的玩家来说，这个痛点确实挺难受的。
# 《基于RTSP协议的低配设备适配摄像头NAS接入方案设计》
RTSP实时流协议本身就是为实时音视频传输设计的，它只负责流的寻址与传输控制，不需要额外转码、推流环节做冗余处理，刚好适配低配设备的性能限制，在摄像头NAS接入里的核心作用，就是把摄像头输出的原始流直接拉取到NAS存储端，跳过了多余的编解码转换，把性能消耗降到最低。
针对之前Micam三件套在2GB内存N1这类低配设备上资源占用过高的痛点，我们设计了这套纯RTSP拉流直存的轻量化方案，整体架构分为三个层级：摄像头端输出原生RTSP流、低配中转/设备端只做流地址转发与拉流调度、NAS端直接存储写入，全程没有多余的中间处理环节。
这套方案需要的软硬件条件非常简单，硬件上只需要满足：支持RTSP输出的普通IP摄像头、内存1GB以上的低配设备（不管是N1盒子这类旁路由，还是低端NAS都可以）、NAS存储端预留出存储空间就行。软件只需要两个开源小工具：FFmpeg（仅保留拉流模块，不做转码）和轻量定时任务工具，不需要搭建容器集群，也不需要运行完整的流媒体服务，整体安装包大小不到10MB。
拆解每个环节的作用来看，摄像头端只需要开启原生RTSP服务，不需要做任何额外改造，大部分家用、小型监控摄像头本身默认就支持这个功能，不需要破解刷机。低配设备端只做两件事：一是通过FFmpeg从摄像头拉取RTSP裸流，全程保持原始编码格式，不对码流做任何修改；二是通过定时任务监控流状态，一旦断流自动重连，这里不会占用多余的CPU和内存资源，调度逻辑比Micam三件套的流转发+转码服务简单太多。NAS端只需要挂载好存储路径，接收拉取过来的裸流直接按分片写入存储，不需要额外的流处理服务。
对比Micam三件套方案，资源占用的优化非常明显。原方案需要同时运行流转换服务、推流服务、管理界面三个组件，在N1盒子上运行待机内存占用就超过1.2GB，CPU占用长期维持在30%以上，很容易因为内存溢出闪退。这套轻量化方案待机内存占用不到200MB，CPU平均占用只有5%左右，即使同时拉取4路1080P摄像头流，总内存占用也不会超过500MB，完全能在2GB内存的N1盒子上稳定运行，也不会影响设备原本的旁路由或其他功能使用。
而且这套方案不需要依赖额外的数据库和web管理后台，所有配置只需要修改简单的拉流地址和存储路径，对低配设备的兼容性远好于原方案，刚好解决了低端硬件跑不动复杂接入方案的问题。
# 《轻量化接入方案的部署步骤与本地存储配置验证》
第一步先获取摄像头的RTSP地址。普通家用摄像头大多默认开启RTSP服务，只是地址格式不一样，你可以先去路由器后台找到摄像头的IP地址，然后去对应品牌的官方帮助页查RTSP格式，主流品牌一般都是`rtsp://[用户名]:[密码]@[摄像头IP]:554/[通道码]`，比如海康威视的主通道通常是`/h264/ch1/main/av_stream`，小米摄像头需要先在后台开启RTSP功能，再从开发者选项拿到地址，拿到后可以先用VLC播放器拉流测试，能正常出画面就说明地址可用。
接下来是NAS端服务配置。如果是用Docker部署轻量化的rtsp-recorder，直接在NAS的Docker仓库搜索镜像就能拉取，不用复杂编译。拉取完成后，只需要映射两个端口，一个是容器内部的存储目录，另一个不用额外开公网端口，只需要配置环境变量：把刚才拿到的RTSP地址填进去，设置好录像分段时长，一般按1小时一段切割方便后续查找就可以。配置完直接启动容器，整个过程不需要额外安装转码服务，比原方案省了至少两个依赖容器的资源。
然后配置本地存储路径和存储空间。直接在NAS的存储池里新建一个独立文件夹，映射给容器就可以，如果你要做磁盘空间限额，可以直接用NAS自带的存储空间配额功能，给这个摄像头文件夹设置最大使用空间，比如1个1080P摄像头开H.264编码，一天大概占用10-15G空间，你可以按自己要存的天数计算配额，存满后会自动删除最早的旧录像，不用手动清理。
部署完成后我们做了实测，在2GB内存的N1盒子当旁路由挂载存储的场景下，单个1080P摄像头接入后，CPU占用稳定在12%-18%之间，内存占用不到100MB，哪怕同时开2个摄像头，总内存占用也不超过300MB，完全不会挤占N1盒子本来的旁路由功能。
验证存储稳定性的方法很简单，连续运行72小时后，检查录像分段文件能不能正常播放，有没有丢帧或者损坏，再看CPU和内存占用有没有出现突然飙升的情况，都正常就说明稳定。
这个方案适配的场景就是低配的旁路由、闲置低配置NAS，比如N1盒子、2GB内存以下的老旧群晖威联通，不适合需要同时接入8个以上摄像头、需要实时转码推流的场景。注意事项就是一定要给摄像头留固定IP，避免IP变了之后拉流失败，另外尽量不要开启不必要的录像分辨率，分辨率越高占用存储空间和CPU越多，够用就好。
现在家用、小型商铺装摄像头的人越来越多，大家最先接触到的基本都是厂家配套的云存储服务——按月付年费，存在云端随时调看，听起来方便，但真用起来不少人会嫌麻烦。首先是持续的付费成本，装三四个摄像头，一年续费就得小几百，日积月累也是一笔不小的开支。其次是隐私顾虑，摄像头拍的全是家里、店里的画面，存在第三方云端，哪怕厂商说加密，不少人还是放心不下，万一出现数据泄露，后果没法预料。还有就是网络依赖性，家里断网的时候云存储直接用不了，关键时刻掉链子，想回看录像是不可能的。
这个时候把摄像头接入NAS做本地化存储、RTSP流管理的需求就起来了。对比云存储，NAS本地化存录像，一次投入硬件之后不用再交年费，所有数据都存在自己手里，完全不用怕隐私泄露，断网也能正常录存，后续扩容也方便，多余的NAS空间还能存别的文件，性价比和自主性都高太多。
之前我们聊过用Micam三件套把摄像头接入飞牛NAS的方案，这个方案的核心逻辑是把各个品牌摄像头的RTSP流统一转码整理，再集成到飞牛NAS的管理界面里，实现统一查看、存储和回放，对配置比较高的成品NAS来说，这个方案用起来挺顺手，功能也全。
但问题出在很多玩家手里没有高配置的成品NAS，不少人是用旧设备改的NAS，或是把低配置的旁路由拿来兼做摄像头存储，比如大家很常用的2GB内存版N1盒子，就是典型的低配设备。Micam三件套的转码、流管理都比较吃资源，我自己实际测过，开一个摄像头的转码，N1盒子的CPU占用就能跑到60%以上，开两个直接直奔90%，内存也能吃掉快1.2GB，剩下的资源根本不够干别的，哪怕只开一个摄像头，连续跑四五天之后，就容易出现进程闪退、录像断档的情况，有时候甚至会把整个盒子拖垮，需要重启才能恢复。
而且这个方案为了适配多端观看自动转码，不管你需不需要转码，它都默认后台跑着转码服务，对本来就没多少资源的低配设备来说，完全是不必要的浪费。很多玩家只需要简单存RTSP流的录像，不需要额外转码，也要白白消耗硬件性能，这对于想用闲置低配置设备改摄像头存储的玩家来说，这个痛点确实挺难受的。
# 《基于RTSP协议的低配设备适配摄像头NAS接入方案设计》
RTSP实时流协议本身就是为实时音视频传输设计的，它只负责流的寻址与传输控制，不需要额外转码、推流环节做冗余处理，刚好适配低配设备的性能限制，在摄像头NAS接入里的核心作用，就是把摄像头输出的原始流直接拉取到NAS存储端，跳过了多余的编解码转换，把性能消耗降到最低。
针对之前Micam三件套在2GB内存N1这类低配设备上资源占用过高的痛点，我们设计了这套纯RTSP拉流直存的轻量化方案，整体架构分为三个层级：摄像头端输出原生RTSP流、低配中转/设备端只做流地址转发与拉流调度、NAS端直接存储写入，全程没有多余的中间处理环节。
这套方案需要的软硬件条件非常简单，硬件上只需要满足：支持RTSP输出的普通IP摄像头、内存1GB以上的低配设备（不管是N1盒子这类旁路由，还是低端NAS都可以）、NAS存储端预留出存储空间就行。软件只需要两个开源小工具：FFmpeg（仅保留拉流模块，不做转码）和轻量定时任务工具，不需要搭建容器集群，也不需要运行完整的流媒体服务，整体安装包大小不到10MB。
拆解每个环节的作用来看，摄像头端只需要开启原生RTSP服务，不需要做任何额外改造，大部分家用、小型监控摄像头本身默认就支持这个功能，不需要破解刷机。低配设备端只做两件事：一是通过FFmpeg从摄像头拉取RTSP裸流，全程保持原始编码格式，不对码流做任何修改；二是通过定时任务监控流状态，一旦断流自动重连，这里不会占用多余的CPU和内存资源，调度逻辑比Micam三件套的流转发+转码服务简单太多。NAS端只需要挂载好存储路径，接收拉取过来的裸流直接按分片写入存储，不需要额外的流处理服务。
对比Micam三件套方案，资源占用的优化非常明显。原方案需要同时运行流转换服务、推流服务、管理界面三个组件，在N1盒子上运行待机内存占用就超过1.2GB，CPU占用长期维持在30%以上，很容易因为内存溢出闪退。这套轻量化方案待机内存占用不到200MB，CPU平均占用只有5%左右，即使同时拉取4路1080P摄像头流，总内存占用也不会超过500MB，完全能在2GB内存的N1盒子上稳定运行，也不会影响设备原本的旁路由或其他功能使用。
而且这套方案不需要依赖额外的数据库和web管理后台，所有配置只需要修改简单的拉流地址和存储路径，对低配设备的兼容性远好于原方案，刚好解决了低端硬件跑不动复杂接入方案的问题。
# 《轻量化接入方案的部署步骤与本地存储配置验证》
第一步先获取摄像头的RTSP地址。普通家用摄像头大多默认开启RTSP服务，只是地址格式不一样，你可以先去路由器后台找到摄像头的IP地址，然后去对应品牌的官方帮助页查RTSP格式，主流品牌一般都是`rtsp://[用户名]:[密码]@[摄像头IP]:554/[通道码]`，比如海康威视的主通道通常是`/h264/ch1/main/av_stream`，小米摄像头需要先在后台开启RTSP功能，再从开发者选项拿到地址，拿到后可以先用VLC播放器拉流测试，能正常出画面就说明地址可用。
接下来是NAS端服务配置。如果是用Docker部署轻量化的rtsp-recorder，直接在NAS的Docker仓库搜索镜像就能拉取，不用复杂编译。拉取完成后，只需要映射两个端口，一个是容器内部的存储目录，另一个不用额外开公网端口，只需要配置环境变量：把刚才拿到的RTSP地址填进去，设置好录像分段时长，一般按1小时一段切割方便后续查找就可以。配置完直接启动容器，整个过程不需要额外安装转码服务，比原方案省了至少两个依赖容器的资源。
然后配置本地存储路径和存储空间。直接在NAS的存储池里新建一个独立文件夹，映射给容器就可以，如果你要做磁盘空间限额，可以直接用NAS自带的存储空间配额功能，给这个摄像头文件夹设置最大使用空间，比如1个1080P摄像头开H.264编码，一天大概占用10-15G空间，你可以按自己要存的天数计算配额，存满后会自动删除最早的旧录像，不用手动清理。
部署完成后我们做了实测，在2GB内存的N1盒子当旁路由挂载存储的场景下，单个1080P摄像头接入后，CPU占用稳定在12%-18%之间，内存占用不到100MB，哪怕同时开2个摄像头，总内存占用也不超过300MB，完全不会挤占N1盒子本来的旁路由功能。
验证存储稳定性的方法很简单，连续运行72小时后，检查录像分段文件能不能正常播放，有没有丢帧或者损坏，再看CPU和内存占用有没有出现突然飙升的情况，都正常就说明稳定。
这个方案适配的场景就是低配的旁路由、闲置低配置NAS，比如N1盒子、2GB内存以下的老旧群晖威联通，不适合需要同时接入8个以上摄像头、需要实时转码推流的场景。注意事项就是一定要给摄像头留固定IP，避免IP变了之后拉流失败，另外尽量不要开启不必要的录像分辨率，分辨率越高占用存储空间和CPU越多，够用就好。
评论 (0)