家里的旧摄像头和一块吃灰的树莓派本来是各自孤独地在角落落灰。直到某天我算了一笔账市面上带云存储的监控摄像头包年至少两三百有的还要按摄像头数量收费本地插内存卡倒是便宜但 24×7 连续写入对卡的寿命是真不友好一年写坏一两张卡是常态。于是我开始琢磨手头这台 720p 的“乞丐版”摄像头还带 RTSP 流那块树莓派跑个 Linux 也毫不过时再加上夸克网盘有免费空间——这三样凑在一起是不是能拼出一套零成本的监控存储与回放系统我花了一个周末把链路打通然后连续跑了二十多天至今没有因为方案本身花过一分钱。这篇文章就把整套思路、踩过的坑、具体命令和回放方案完整写出来给同样闲不住的朋友一个参考。1. 为什么是“乞丐版摄像头 闲置单板机 夸克网盘”这套组合先说清楚这套方案的逻辑否则你后面照搬命令会不知道为什么这么搭。云摄像头厂商的逻辑是“卖硬件再赚月费”硬件本身便宜但云端存储、录像回放、移动侦测提醒全都要订阅。而且摄像头上传的视频是经过厂商服务器转存的哪天服务下线或者厂商改协议你连录像都导不出来。本地 NVR 录像机则是另一个极端机器加硬盘动辄上千块对家里就一两路画面来说属于大炮打蚊子。我这套组合的本质是让三样东西各干各的摄像头负责“采集画面”只做一件事向局域网输出 RTSP 视频流。单板机负责“本地中转”通过 ffmpeg 把 RTSP 流切成一段段小文件落到本地存储再定时上传到云盘。夸克网盘负责“云端存储和回放”充当免费的数据保险箱随时用手机 App 翻看历史录像。为什么这种分工合理因为单板机能做的非常有限但做“流接收器”绰绰有余。720p 的 H.264 流码率一般 2~4Mbps树莓派用-c copy直接复制流而不转码CPU 占用基本可以忽略。我实测整机功耗不到 5W一天电费约一毛钱跑一个月也就三度电这已经可以视为“不花钱”了。更重要的是这套系统把数据主动权留给了自己。摄像头所有的画面先落在本地再上传到夸克网盘。万一网盘哪天不给免费额度了本地录像链路还是完整的你只需要换个上传目标其他都不用动。相比厂商云那种“录像只在别人服务器上”的方案这种架构安全感高得多。适合这套玩法的场景也有限制适合一到两路画面、720p 到 1080p、家里有闲置单板机和宽带。不适合三十天超高清全量保留、多路集中管理、需要毫秒级告警的场合。认清边界才不会冤种式地折腾半天然后骂方案不行。2. 材料清单与选型思路什么才算“乞丐版”哪块单板机最合适2.1 乞丐版摄像头必须要有公认协议而不是真捡垃圾我理解很多人听到“乞丐版”第一反应是拿个几十块的杂牌 WiFi 摄像头。但我要泼一盆冷水太冷门的品牌RTSP 协议可能被阉割或者固件里藏着后门又或者 App 一停更新就只能当摆件。真正的“乞丐版”应该是大品牌的老款、二手、低分辨率型号例如海康威视、宇视早期的简型机、半球机。这类机器虽然当年卖得便宜但底子相当扎实RTSP 和 ONVIF 是标配二手平台上几十块一台画质虽然只有 720p晚上噪点多一点但监控够用。选摄像头时你至少要确认三件事支持 RTSP 输出而不是只有私有 App 协议。没有 RTSP后面所有操作都无从谈起。编码是 H.264 或 H.265尽量避免 MJPEG码率太高单板机和网盘都受不了。供电要稳定PoE 或者 12V 电源都行不要用电池版那玩意根本扛不住 24×7。我用的是一台海康威视老款简型机RTSP 地址长这样rtsp://用户名:密码192.168.1.64:554/Streaming/Channels/101不同厂商路径不一样宇视的一般是/unicast/c2/s0/live老款大华也有自己的路径。如果你不确定摄像头具体地址可以先在局域网里用 ONVIF 客户端扫一下也可以用 ffprobe 直接验证ffprobe rtsp://用户名:密码192.168.1.64:554/Streaming/Channels/101只要它能输出 SDP 信息就说明链路是通的。2.2 单板机端树莓派、香橙派、RK 系都能用这块板子的任务不重但要求很具体能跑 Linux、有 USB 口、有网口、功耗低。最早我用的是一台树莓派 3B1GB 内存吃灰五年刷上 Debian 系统后照样干活。后来我又在一台香橙派 Zero 上试过也同样没问题。核心逻辑是ffmpeg 只要做流复制常用单板机的性能绰绰有余做转码才需要更高配置但我们完全不需要。如果你手头是一台旧手机理论上也能做但我不推荐。手机电池长期浮充容易鼓包断电后缺少自动恢复机制而且 Android 上的 ffmpeg 运维不如 Linux 顺滑。既然标题是“闲置单板机”那就还是老老实实用一块能刷 Linux 的开发板或迷你电脑。单板机最好配一个“专门用来存录像”的闲置 U 盘或 USB 移动硬盘容量 32G 以上。不建议长时间往系统 SD 卡里写录像SD 卡寿命真的顶不住连续写入系统一旦卡死整个监控都会断。把系统盘和录像盘分开是血泪教训后面我会单独展开。2.3 存储容量怎么算先算码率再定保留窗口很多人一上来就问“10G 够不够”这是把问题问反了。正确顺序是先算出本地一天的录像体积再决定保留几天云盘也只是换了一个更大的桶。估算公式很简单体积GB 码率Mbps × 时间秒 ÷ 8 ÷ 1024举个例子如果摄像头码率是 2Mbps那么一小时2 × 3600 ÷ 8 ÷ 1024 ≈ 0.88GB一天24 小时约 21GB一个 64GB 的 U 盘本地保留三天毫无压力夸克免费空间可能只有几个 G 到几十个 G 不等这取决于账号和历史活动。即便只有 10GB配合“本地滚动 云端滚动清理”存最近两三天关键画面也够用。既然标题说“不花一分钱”那就不要把免费额度当无限仓库而是当“滚动保留窗口”。我先按 720p 摄像头约 1.5~2Mbps 码率设置原因很简单二手乞丐版摄像头本身画质天花板就在那里没必要把码率堆到 4Mbps。省下来的带宽和空间远比多出来的几个细节重要。2.4 网络环境准备不需要公网 IP但上行带宽不能太小这套系统有个容易被人忽略的前提摄像头和单板机在同一个局域网摄像头 RTSP 只在内网传输单板机向夸克网盘上传时消耗的是家里的上行带宽。所以你要先测一下上行带宽。很多家庭的宽带下行几百兆上行只有 30Mbps 左右。如果视频总码率是 2Mbps理论上 30Mbps 上行是足够的但家里其他人打游戏、视频会议也会抢带宽。我给 rclone 加了限速参数上传带宽控制在 1Mbps晚上慢慢传完全不干扰日常用网。不需要有公网 IP不需要在路由器上做端口映射因为回放走的是夸克网盘官方 App外面的人访问的是网盘的服务器而不是你的家。这又一次印证了前面说的架构优势。3. 本地录像链路搭建RTSP 取流、分段录制、断线重连3.1 用 ffmpeg 做分段循环录制单板机最核心的本地任务是把 RTSP 流变成“一段段小文件”。为什么要分段而不是录成一个巨大的视频因为分段后上传、回放、删除都极其方便。我在机器上开了三个终端一个跑 ffmpeg 录流一个跑定时清理一个看日志。关键命令是这个ffmpeg -rtsp_transport tcp \ -i rtsp://用户:密码192.168.1.64:554/Streaming/Channels/101 \ -c copy -f segment \ -segment_time 600 -reset_timestamps 1 \ -strftime 1 /mnt/record/cam01/%Y%m%d_%H%M%S.mp4逐项拆解-rtsp_transport tcp强制走 TCP 而不是 UDP避免 UDP 丢包导致的画面花屏。没这一步局域网 WiFi 下很容易断流。-c copy直接拷贝流不转码省 CPU这是单板机能扛住 24×7 的关键。-segment_time 600每 10 分钟切成一个文件。10 分钟是个比较舒服的粒度找某件事时最多偏差 10 分钟文件体积也不大。-reset_timestamps 1每一段都从头开始计时否则播放器会以为视频有四五个小时长。-strftime 1文件名按时间格式化生成如20240530_104500.mp4这样带时间戳的名字。录像文件生成后你会看到类似下面的目录结构/mnt/record/cam01/20240530_104500.mp4 /mnt/record/cam01/20240530_105500.mp4每段都是独立的 MP4直接在电脑上双击也能播放。3.2 自动清理本地旧文件防止磁盘写满分段录制的另一个好处是清理简单。我用 cron 每 5 分钟执行一次把超过 2 天的 mp4 删除find /mnt/record/cam01 -name *.mp4 -mmin 2880 -delete2880就是 48 小时你可以按自己需求调整。这就是一个最简单的滚动录像窗口本地永远只留最近两天的数据。这样一来哪怕 U 盘只有 64GB也绝不会被写满。3.3 断线重连别让一次断网毁掉整个晚上的录像摄像头长时间运行偶尔掉线是最常见的事故。ffmpeg 一旦断流就会退出不会自动重连。如果你只是手动跑一条命令半夜摄像头断一次到早上你看到的可能就是一片空白。我一开始就踩了这个坑摄像头凌晨断了几分钟ffmpeg 退出后没有拉起第二天早上看到目录里少了一堆文件才反应过来。解决办法是套一层循环脚本#!/bin/bash URLrtsp://用户:密码192.168.1.64:554/Streaming/Channels/101 OUT/mnt/record/cam01 while true; do timeout 7200 ffmpeg -rtsp_transport tcp \ -i $URL -c copy -f segment \ -segment_time 600 -reset_timestamps 1 \ -strftime 1 $OUT/%Y%m%d_%H%M%S.mp4 \ /var/log/cam-record.log 21 echo $(date): ffmpeg exited, restarting in 10s /var/log/cam-record.log sleep 10 donetimeout 7200的意思是即使 ffmpeg 没有退出每 2 小时也强制重启一次。为什么强制重启因为长时间运行后即使没断流ffmpeg 也可能在写入时出现诡异问题定时重启可以给链路一个“重新握手”的机会代价只是丢掉几秒钟画面完全可以接受。你还可以把整个脚本放进 systemd 服务加上Restarton-failure这样单板机重启后也能自动拉起录制。不过在实际使用中上面的 while 循环配合开机自启已经足够稳定了。3.4 时间同步时间戳错了回放就废了摄像头和单板机之间的时钟如果不一致文件名时间戳就会乱。我遇到过摄像头本地时间比实际慢了两分钟结果查录像时总是“提前两分钟找不到画面”。解决思路单板机开启 NTP 自动校时。摄像头如果有 NTP 设置就指向同一个时间源。如果摄像头固件太老不支持 NTP那就接受这个系统偏差选一个固定的文件命名基准。我用的是单板机的接收时间作为文件名摄像头的内部时间只影响画面里的 OSD 时间戳两者差一分钟内影响不大。最忌讳的是单板机和摄像头各走各的时间文件名和画面时间完全对不上。4. 夸克网盘挂载与自动上传零成本云存储的核心环节4.1 为什么不让摄像头直接上传到网盘而是绕一圈经过单板机市面上确实有一类摄像头自带 FTP 或 WebDAV 推送功能可以直接把录好的视频传到某个云盘。但实际用下来你会发现这类摄像头要么只支持特定厂商云要么写盘策略简单粗暴、频繁重传要么根本不支持断点续传。让单板机做中转最大的好处是可控性。摄像头只需要做它最擅长的 RTSP 输出上传动作由单板机统一调度。你可以随时换上传目标不用去改摄像头固件可以限速、断点续传、自动清理这些在脚本里都很好实现。4.2 使用 alist 把夸克网盘变成 WebDAV再挂载到本地夸克网盘本身没有官方的 WebDAV 接口所以我们要借助一个开源工具alist。alist 支持把夸克网盘作为存储后端然后对外提供 WebDAV 协议。这样 rclone 就可以像操作本地目录一样操作夸克网盘。步骤大致如下在单板机上安装 alist 二进制执行alist server启动。第一次启动后用alist admin设置管理员账号密码。打开 Web 管理界面在“存储”里添加驱动选择“夸克网盘”。需要填入夸克网盘的 Cookie一般是在浏览器登录夸克网盘后通过开发者工具复制。这一步在 alist 的文档里有详细说明照着做就行。在 alist 的设置里打开 WebDAV 开关记得记录端口默认是 5244。然后是单板机这侧用 rclone 把这个 WebDAV 挂载成系统目录。我的配置大概是这样的rclone config # 选择 WebDAV填写 http://127.0.0.1:5244/dav # 用户名和密码就是 alist 的管理员账号配置完成后可以挂载成一个目录mkdir -p /mnt/quark rclone mount quark: /mnt/quark --daemon --allow-other --vfs-cache-mode writes--vfs-cache-mode writes可以规避部分上传不完整问题。挂载成功之后/mnt/quark就相当于一个本目录往里写文件就等于往夸克网盘上传。4.3 定时上传脚本只传完整文件限制带宽崩溃可恢复本地录像文件每 10 分钟产生一个。上传不能等全部录完再传不然积压会越来越严重。我写了一个 upload 脚本由 cron 每 10 分钟跑一次rclone move /mnt/record/cam01 quark:视频监控/cam01 \ --min-age 10m \ --bwlimit 1M \ --transfers 1 \ --delete-empty-src-dirs \ --local-no-check-updated \ --ignore-existing这里有几个参数很重要--min-age 10m只处理至少存在 10 分钟的文件防止 ffmpeg 正在写入的文件被传成残片。--bwlimit 1M把上传带宽限制在 1Mbps不抢家庭网络。--transfers 1同时只传一个文件避免多文件并发导致网页打不开。--ignore-existing跳过云端已有的同名文件即使重复跑了也不会覆盖已传好的录像。rclone move会在上传成功后自动删除本地原文件。这样本地就永远只保留“还没传上去”的录像相当于一个积压队列。等网络不畅时本地文件会积压但只要网恢复cron 一跑队列自动清空。cron 配置*/10 * * * * /home/pi/upload.sh /var/log/quark-upload.log 21我会在日志里定期看一下有没有NOTICE级别以上的报错基本就能掌握整个上传链路的状态。4.4 网盘容量管理与滚动清理既然是免费空间总会有容量上限。我的策略就是标题里说的“滚动保留”本地保留两天云端保留四五天更早的视频删掉。用 cron 定期清理夸克网盘上超过 4 天的文件rclone delete quark:视频监控/cam01 --min-age 96h --drive-use-trashfalse--min-age 96h会删除修改时间超过 96 小时的文件也就是只保留最近 4 天。这样就算免费额度只有 10GB配合 2Mbps 码率的录像也完全够用10GB 大概能存 16 小时的全量视频但因为我们只在云端保留最近四天、而且实际码率还不到 2Mbps按需调整保留窗口后几乎不会爆。实测下来夸克网盘的上传速度对免费用户还算友好主要限制在下载侧。对监控回放来说下载本来就不是高频操作真到了翻录像的时候用夸克 App 播放清缓存分段加载基本够用。5. 回放体验与文件组织没有 NVR 也能一分钟翻到关键片段5.1 让文件名具备“索引”能力回放的本质就是快速找到某个时间点的画面。这套系统没有 NVR 那样可视化时间轴但通过合理的文件命名和组织查找效率不比 NVR 差。我的目录组织是夸克网盘/视频监控/cam01/2024/05/30/cam01_20240530_104500.mp4这样即使不打开 App你光是按日期一层层点进去就能精确定位到某天某小时。我还刻意在文件名里加了摄像头名cam01因为将来如果加第二路摄像头目录名会自然分开不会混淆。命名里同时包含了“小时分钟”查找逻辑非常直觉我想看今天上午十点半的画面就找cam01_20240530_103000或cam01_20240530_104500播放后拖一下进度条误差不超过 10 分钟。5.2 用夸克 App 直接在手机上回放这是我选择夸克网盘的第二个原因它的手机端播放器对视频格式兼容性较好H.264 的 MP4 基本是秒开。我打开夸克 App进入“视频监控/cam01”目录选一个文件就能在线播放还能倍速、投屏到电视上。如果要回放某一段不需要把整个视频下载下来直接在线播放就行。哪怕家里没人在家人也能用共享链接访问视频目录。当然分享视频时要小心隐私监控目录就别设置成公开分享了自己账号看就好。5.3 没有事件检测也能快速找异常画面整套系统没有运动侦测只靠文件名回放确实会显得笨拙。但有一个旁门左道上传到云端后检查每个文件的大小。正常情况下每段 10 分钟的视频文件大小基本稳定。如果某一段画面里发生了剧烈变化比如有人走动、车辆驶过视频波动会使文件体积明显变大甚至变大好几倍。我写了个简单的 Python 脚本定期扫描云端文件大小把体积超过正常值 1.5 倍的文件单独列出来相当于一个最朴素的“异常画面清单”。这个方法不算复杂但它让零成本方案有了一个近似事件检测的能力。真需要严格的人形识别那就得加 Frigate 这类算法服务了已经超出“不花一分钱”的讨论范围。6. 实测二十多天的坑与对策从摄像头掉线到上传积压6.1 摄像头半夜掉线ffmpeg 录出一堆 0 字节文件第一次启用断线重连脚本时我并没有立刻发现另一个问题摄像头网络闪断后ffmpeg 会尝试重连但重连过程中可能不断输出空的 MP4 文件。结果就是目录里多了好几个 0 字节或几十 KB 的空文件文件名还很规律。这些文件上传到夸克网盘后回放时根本打不开纯占空间。对策分两步在 ffmpeg 命令里把-f segment的输出目录单独设置并在上传脚本里用--min-size 500k过滤掉可疑小文件。上传后不要把本地空文件留着rclone 的move操作会一并处理掉日志里也会多出几十条警告。后来我加了一行检查文件小于 500KB 直接删除眼不见心不烦。find /mnt/record/cam01 -name *.mp4 -size -500k -delete6.2 网盘上传慢导致的积压如何判断是否失控家在晚上用网高峰期1Mbps 限速上传可能赶不上录像生成速度。最典型的表现是本地目录里的文件越来越多上传队列一直排着。我给自己定了一个简单的健康阈值本地文件数量不超过 30 个。如果超过说明上传已经跟不上实时录像这时候我就不再纠结“全量上传”而是优先保证最近时间段的关键画面。具体做法是把上传脚本里的--min-age 10m改成--min-age 30m跳过更老、更不重要的积压文件优先传最新的。这个逻辑的本质是监控回放最重要的是“最近的片段”而不是几十小时前的无关画面。宁可舍弃部分旧录像也要保证随时能看几个小时内发生了什么。6.3 单板机 SD 卡差点挂掉录像盘必须独立树莓派跑了一周后我检查系统日志时发现连续 IO 错误差点把系统盘写穿。原因很简单我一开始把录像目录直接放在系统 SD 卡上7×24 的流写入把 SD 卡 IO 打满了。后来我把录像目录迁到了一个独立的旧 USB 移动硬盘上同时在/etc/fstab里给系统盘加上了noatime参数减少无谓写入。如果你只有一个 U 盘也建议把系统镜像写进 U 盘后再插一个独立的 U 盘做录像盘两者互不干扰。这可能是整套系统里最容易被忽略的硬件问题。我见过有人因为贪方便让树莓派把录像写进 SD 卡结果三天后系统开始频繁卡死还以为单板机性能不足。6.4 摄像头软件时间跳变文件时间戳对不上有一台宇视摄像头每次断电重启后时间会重置到固件默认值导致 OSD 时间戳和文件名时间戳偏了很多。后来我在路由器里给它指定了 NTP 服务器问题消失。如果你的摄像头和单板机时间对不上优先在摄像头后台设置 NTP而不是靠单板机人工校时。实在没有 NTP 的旧设备我建议以单板机的接收时间为准。文件名的时间是单板机打的而画面里的时间戳如果偏了只能在回放时心里加一个固定的偏移量。这虽然不是最优解但不会影响查找录像的准确性。7. 这套系统的边界与扩展方向7.1 哪些场景不适合零成本方案我需要坦诚地说这套方案不是万能的。如果你对监控的需求是“发生事件后立即在手机上收到报警”那么纯网盘的轮询式检测会很弱如果摄像头路数超过四路单板机的网口和 IO 会成为瓶颈如果必须 1080p 全帧率录制且保留三十天那免费网盘的容量和带宽完全不够。所以我的结论是这套方案最理想的场景是一到两路旧摄像头、一块闲置单板机、家里有人需要偶尔翻看一下最近几天的录像预算为零。它解决的是“想有个能回放的监控但不想为云服务付费”的尴尬。7.2 可以继续白嫖的升级方向系统跑通之后往上加功能的空间其实不小。比如把摄像头的事件输出接到单板机收到报警时生成一个“重要片段”文件单独上传到云盘的特殊目录这样回放时直接看关键片段。继续用 alist 挂载其他免费网盘做异地“双云备份”重要录像同时传两份降低单点风险。如果家里有 NAS也可以把本地录像目录直接放到 NAS 上再用同一套 crontab 同步到夸克。我个人在实际操作中最强烈的体会是这套方案的价值不在一分钱没花而在于它把“本地录像、云端回放、单板机调度”这三件事真正解耦了。摄像头坏了可以换单板机卡了可以重刷网盘不行了可以换整套逻辑始终站得住。你现在照着跑一遍将来遇到任何一环出问题都不会被绑定得死去活来。如果你家里刚好也有吃灰的摄像头和树莓派找个晚上就能开搞。不用先问“够不够专业”先让它跑起来比什么都强。