ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

零订阅费监控方案:闲置单板机+乞丐摄像头+夸克网盘搭建可回放系统

零订阅费监控方案:闲置单板机+乞丐摄像头+夸克网盘搭建可回放系统 这两年做监控方案越做越觉得魔幻摄像头厂商把“云存储”做成了按月订阅的生意一年下来比摄像头本身还贵插内存卡倒是省事可普通TF卡在7×24小时连续写入下基本上三个月一坏回看还得拔卡插电脑录了个寂寞。后来我把需求拆成三个零件——一台吃灰的电视盒子或树莓派一台百元出头的乞丐版网络摄像头再加一个平时只用来存资料的夸克网盘居然拼出了一套零订阅费、能存能回放的24×7监控系统。整条链路说穿了就是摄像头走RTSP把视频流交给单板机单板机本地分段录制形成“热缓存”再通过Alist把录像自动同步到夸克网盘最终用手机在任何地方回放。这篇文章把这条链路从头到脚过一遍包括摄像头RTSP取流、本地分段录制、内存卡格式化与避坑、Alist挂载夸克网盘、同步脚本、回放姿势和常见故障排查。适合手里正好有闲置ARM盒子、又不愿意为云存储月付的朋友也适合那些被“云存储还是内存卡”纠结到头秃的新手。1. 方案整体设计与架构拆解1.1 需求拆解监控到底要解决什么问题先想清楚监控系统要满足什么选项对比才不会跑偏。我总结下来家用监控的硬需求只有三条全天候连续录制不能因为网络抖动、停电重启就漏掉关键时段。能回看最好手机随手翻不用拔卡、不用开电脑。成本可接受最好是设备一次性投入后续不按月交保护费。市面上的云存储摄像头为什么让人难受它们往往只保存报警前后十几秒到几十秒的“事件片段”连续回放要开更高档会员免费云存储试用期一过视频就变成只能看缩略图不能拖动回放。内存卡方案为什么也难受卡在高温、持续写入的环境下容易坏坏的时候往往是正好需要回放的时候。而且卡损坏往往没有任何预警等你发现的时候前面几天的录像已经成了空白。所以我的核心思路是不做“云存储”和“内存卡”的二选一而是做一个“本地热缓存 云端冷存储”的叠加架构。本地存最近几天网盘存完整归档两边互为备份单点失效至少还有一份能看。1.2 三大件的选型思考标题里说的“乞丐版摄像头 闲置单板机 夸克网盘”不是随便凑的每一件都有明确分工。零件作用选型标准摄像头采集视频提供RTSP/ONVIF标准流百元级IPC即可支持RTSP、能登录后台改参数单板机拉流、分段录制、上传网盘、提供回放ARM Linux、能跑ffmpeg和Alist有稳定供电夸克网盘云端归档、手机远程回放免费空间够用、有第三方挂载方式、手机端在线播放方便摄像头为什么用“乞丐版”因为监控画质不是越高越好24小时录制更考验存储和码率而不是分辨率。一台1080P的摄像头用主码流录一天就要20GB左右连续存一个月就是600GB。对普通家用场景来说看清谁来过、车牌号是多少就够了真没必要上4K。乞丐版摄像头的优势是便宜、体积小、随便找个墙角落就能装坏了再换一台也不心疼。单板机为什么不用一台正经PC因为正经PC功耗高、噪音大、体积大放弱电箱里不合适。闲置电视盒子、树莓派、瑞芯微开发板这类ARM单板机功耗普遍在5W到10W之间24小时开着一年电费也就是一杯奶茶钱安静、无风扇、能塞进鞋盒完全够用。夸克网盘为什么能用来当监控存储它提供了独立的App和网页端手机看视频体验足够顺滑而且通过Alist这类开源存储网关可以把它挂载成标准的WebDAV接口让单板机像写本地磁盘一样把录像文件传上去。免费空间的额度不同账号会变化但只要能坚持“本地留热、云端留全”的节奏就不至于被额度卡死。1.3 整条数据链路的关键设计把零件串起来之后数据链路是这样一个走向摄像头通过网线或Wi-Fi接入局域网单板机用ffmpeg以RTSP协议拉取视频流按固定时长切成一个个MP4文件存到本地磁盘或内存卡上然后一个定时同步任务把新生成的MP4文件上传到夸克网盘并确认上传成功后才删除本地副本要看回放时局域网内直接访问单板机上的共享目录人在外面就用夸克网盘App播放云端文件。这条链路里最核心的设计决策是“先本地后云端”。很多人一上来就想让摄像头直接推流到网盘省去本地存储但实际跑一遍就会发现网络一抖视频流就断了云端少一段断电期间摄像头数据也上不了云。先落本地再传云端等于给云端加了一道缓冲网络再不稳定本地这份始终在。第二个决策是“分段录制”。不能把摄像头视频录成一个无限长的单文件否则回放没法拖动、传网盘也要等一个文件录完。固定每5分钟切一段文件大小可控同步任务只处理还没上传的片段回放时缺失哪一段就找哪一段体验接近磁带录像机的逐段翻找。第三个决策是“上传成功才删本地”。这个看起来很朴素的规则能救回很多事故。网盘偶尔抽风、账号异常、上传限速本地文件还在至少不丢录像。等网盘恢复了可以补传或者直接在本地回看不慌。2. 底层准备摄像头联通与单板机环境搭建2.1 摄像头接入先让IPC开口说话买回来的摄像头第一件事不是接单板机而是先把画面调出来。大多数乞丐版摄像头默认走DHCP获取IP把网线插到路由器上然后用路由器后台的客户端列表或者手机App扫描就能看到它的IP地址。也有部分摄像头默认固定IP比如常见的192.168.1.64这种就需要手动把电脑改成同网段访问后台改好之后再把摄像头改成DHCP或者设一个保留地址。进入摄像头后台之后要做两件事一是改默认密码这个别偷懒监控流暴露在网络上不是开玩笑的二是找到RTSP取流地址。不同厂商的路径格式不一样但后台页面里通常都有“取流信息”“网络服务”“RTSP设置”之类的入口。以最常见的两类摄像头为例它们的RTSP地址大致长这样海康威视主码流一般是rtsp://用户名:密码IP:554/Streaming/Channels/101子码流是102结尾。宇视摄像头路径在不同固件上有差异常见类似rtsp://用户名:密码IP:554/live1或者/MediaInput/1/1最可靠的方式是登录后台查看“取流地址”页面的完整URL。如果你手里的摄像头后台没有现成的RTSP地址也别慌用ONVIF Device Manager这类工具扫一下它能把支持ONVIF的设备信息、媒体流地址全部列出来。绝大多数低价IPC都会支持ONVIF这是国际标准的设备发现协议。拿到RTSP地址后在电脑上用VLC或者ffprobe验证一下能出画面就说明链路通了一半。验证命令我用的是ffprobe -rtsp_transport tcp -i rtsp://用户名:密码192.168.1.64:554/Streaming/Channels/101这里强调一下-rtsp_transport tcp。默认RTSP走UDPUDP在Wi-Fi或跨路由器场景下容易丢包花屏、无故断流强制走TCP虽然会多一点延迟但稳定得多对24小时录制来说稳定性永远优先。2.2 单板机系统与基础环境我用的闲置单板机是早年淘汰的电视盒子刷了Armbian系统。如果手上的是树莓派直接用Raspberry Pi OS Lite就行。系统装好之后先做三件基础事把机器放到通风、干燥且不会被误碰的地方如果用金属盒装着最好在CPU位置贴个小散热片。24小时运行的ARM设备最怕的不是烧CPU而是高温降频以后ffmpeg出问题。电源一定要选足安数的正规品牌电源。单板机瞬时拉流时电流会有一个小尖峰劣质电源会导致重启监控就断档了。插上网线把IP固定住。摄像头会变IP单板机不能再跟着变否则脚本里写的地址全乱套。接下来装ffmpeg和相关工具sudo apt install ffmpeg sudo timedatectl set-timezone Asia/Shanghai sudo systemctl enable systemd-timesyncd时间同步这一条容易被忽略但它直接影响录像文件名和回放。如果系统时间不对录出来的文件名是错乱的回放时按时间找文件会完全对不上。让系统自动同步时间同时确认时区正确。onsolidate into a keypoint: 如果单板机上直接装了树莓派OV5647这类摄像头模组不走RTSP而是走V4L2接口拉流命令会变成ffmpeg -f v4l2 -input_format mjpeg -framerate 25 -video_size 1280x720 -i /dev/video0 -c:v copy out.mp4但标题场景里用的还是网络摄像头因为乞丐版IPC自带红外、云台和防水壳比直接怼一个摄像头模组省事太多。2.3 内存卡与本地磁盘的格式化准备单板机上的系统盘是内置存储录像文件我单独挂载了一块闲置的小容量TF卡也可以挂一个USB移动硬盘。这里就涉及到搜索热词里高频出现的“内存卡怎么格式化成FAT32”。先说结论如果这张卡只给单板机专职写录像我建议直接格式化成ext4而不是FAT32。ext4是Linux原生文件系统长时间连续写入比FAT32稳定掉电后恢复能力也强。FAT32的优势是跨设备兼容性好插到Windows、行车记录仪、播放器上都能直接读但有一个硬限制单个文件不能超过4GB。我们做5分钟分段一个文件通常不到500MB不会触发这个限制但如果哪天你觉得10分钟一段更好码率高的时候就可能写出4GB以上的文件。如果你的场景必须用FAT32在Linux下一条命令就搞定sudo mkfs.fat -F 32 /dev/sdX1在Windows下32GB及以下的内存卡右键格式化就能直接选FAT3264GB以上的卡Windows的默认格式化工具反而不给FAT32选项需要用fat32format这类第三方小工具或命令行处理。实际操作时我更推荐让孩子格式化成exFAT前者没有4GB文件限制也不会有奇怪的文件系统兼容问题。别忘了格式化之前先做个写速测试这个步骤能淘汰掉绝大多数所谓“扩容卡”和劣质卡dd if/dev/zero of/data/rec/testfile bs1M count500 oflagsync连续写入速度低于10MB/s的卡用于1080P录像会频繁掉帧后面故障排查章节再细说。3. 录制与存储循环本地热缓存的空间管理3.1 ffmpeg分段录制脚本单板机上的核心程序是一个不会自杀的ffmpeg录制脚本。我之前写的第一版就是因为没有自动重启逻辑半夜ffmpeg因为网络抖动一个报错退出去第二天才发现一晚上什么都没录到。现在用的录制脚本长这样#!/bin/bash CAM_IDfrontdoor RTSPrtsp://用户名:密码192.168.1.64:554/Streaming/Channels/101 OUT_DIR/data/rec/${CAM_ID} mkdir -p ${OUT_DIR} while true; do ffmpeg -hide_banner -loglevel warning \ -rtsp_transport tcp -stimeout 5000000 \ -i ${RTSP} \ -c copy -f segment -segment_time 300 -reset_timestamps 1 \ -strftime 1 ${OUT_DIR}/%Y%m%d_%H%M%S.mp4 echo $(date) ffmpeg exited, restarting in 5s /var/log/cam_rec.log sleep 5 done逐行解释几个关键参数-rtsp_transport tcp强制走TCP传输避免UDP断流。-stimeout 5000000RTSP连接超时单位是微秒这里设成5秒。摄像头没响应时ffmpeg能快速退出而不是傻等让外层循环重启。-c copy直接复制摄像头的H.264码流不做转码。这是单板机能24小时稳定运行的关键一旦转码CPU占用立刻上去发热和功耗都失控。-segment_time 300每300秒切一个文件也就是5分钟一段。-strftime 1允许文件名使用时间通配符输出文件名就是20250614_183000.mp4这种带时间戳的格式。用-c copy虽然省CPU但有个小前提MP4文件的分段边界只能落在摄像头编码的关键帧上。如果摄像头关键帧间隔是4秒实际切片可能是4、8、12秒的倍数不一定是精确的300秒这不影响使用文件名时间仍然准确。想让分段更规整也可以考虑改录HLS切片而不是MP4ffmpeg ... -c copy -f hls -hls_time 300 -hls_list_size 0 -hls_segment_filename ${OUT_DIR}/%Y%m%d_%H%M%S.ts index.m3u8HLS的好处是天然支持边录边看文件是TS格式断点续传也更不容易损坏。但MP4格式对普通用户来说更通用手机网盘直接能在线播所以我默认还是MP4方案。3.2 本地存储循环与自动清理本地空间不是无限的所以要把“热缓存”和“冷归档”分开。我的策略是本地只保留最近3天录像超过3天的文件一律删除给新录像腾地方。清理脚本挂在cron里每小时跑一次#!/bin/bash find /data/rec -name *.mp4 -mtime 3 -delete find /data/rec -name *.ts -mtime 3 -delete注意-mtime 3是按文件的修改时间算也就是最后写入时间不是文件名时间。这个逻辑基本正确因为分段文件录制完成后不会再有改动。还有一个容易被忽略的问题磁盘满了之后ffmpeg虽然不会立即退出但写入会失败日志会报“No space left on device”而外层循环还傻乎乎以为录得很正常。所以我加了一个磁盘水位检查USAGE$(df -h /data/rec | awk NR2 {print $5} | sed s/%//) if [ $USAGE -gt 95 ]; then find /data/rec -name *.mp4 -mmin 120 -delete fi3.3 录像文件命名与时间戳规范文件命名必须做到“按文件名就能定位到事件”而不是靠猜。我的命名规则是摄像头ID_YYYYMMDD_HHMMSS.mp4比如frontdoor_20250614_183000.mp4。这个命名方式在云端同步和回放时都很好用排序即时间线。配套要做的是确保系统时间准确。如果你发现某个录像文件的大小对不上或者时间戳和画面内容差了好几个小时优先检查系统时间和时区timedatectl status4. 上传云端用Alist把录像同步到夸克网盘4.1 为什么引入Alist单板机要把录像传到夸克网盘直接走官方客户端是不现实的命令行吞吐也不好控制。Alist这个开源存储网关可以把夸克网盘挂载到本机并提供WebDAV接口这样rclone、curl、文件管理器都能像访问本地文件夹一样访问夸克网盘。我的做法是在单板机上跑一个Alist进程然后在Alist后台添加夸克网盘存储绑定自己的夸克账号拿到刷新令牌。Alist文档里对夸克网盘的接入步骤写得相当细照着操作几分钟就能挂上。这个过程中有一点要提醒Alist后台生成的令牌等同于一个长期有效的网盘访问凭证不要把它贴到公开群聊、Gist或者博客里否则别人拿到令牌就能直接读你网盘里的文件。监控录像属于隐私数据网盘账号本身也建议开启两步验证。挂载完成之后Alist会暴露一个本机WebDAV地址比如http://127.0.0.1:5244/dav/camera单板机上的其他工具就能通过这个地址读写夸克网盘。之所以绕一道WebDAV而不是直接用Alist的命令行API是因为rclone对WebDAV的支持非常成熟断点续传、失败重试、日志都现成比手写HTTP请求稳定太多。4.2 同步脚本设计与失败重试同步任务的核心思路是把本地新生成、且距现在超过几分钟的MP4文件上传到夸克网盘对应日期目录上传成功后删除本地副本。多等几分钟是为了避免ffmpeg还在写当前分段时同步脚本就去抢这个文件导致上传半截文件。我用的是一个带文件锁的脚本挂在cron里每10分钟跑一次#!/bin/bash set -uo pipefail LOCKFILE/tmp/quark_upload.lock exec 9${LOCKFILE} flock -n 9 || exit 0 find /data/rec -name *.mp4 -mmin 2 -type f -print0 | while IFS read -r -d file; do year$(date -d $(basename $file | cut -d_ -f2,3 | sed s/_/-/) %Y%m 2/dev/null || date %Y%m) remotepath监控/frontdoor/${year}/$(basename $file) echo [$(date)] uploading ${file} to ${remotepath} /var/log/quark_upload.log rclone copy $file quarkdav:${remotepath} --log-file/var/log/quark_rclone.log -v if [ $? -eq 0 ]; then rm -f $file fi done几个细节值得展开flock是防止脚本重入。如果上一次同步还没跑完cron又触发了一次脚本直接退出避免两个进程抢同一个文件。-mmin 2的意思是只处理2分钟前就存在的文件给分段录制留出缓冲期。上传成功后删除本地文件。这行逻辑是整个架构里“本地热缓存”和“云端冷归档”分工的关键也是防止网盘空间被重复占用。上传失败时不做任何删除操作本地文件保留下次cron会继续尝试。等到网盘恢复正常积压的录像会慢慢补传。上传时间点的选择上如果网盘在白天高峰时段上传速度不稳定可以把cron改成只在凌晨2点到6点之间同步白天本地先攒着。不过家用监控码率通常不高1080P子码流一天也就4GB左右随时传问题不大。4.3 云端文件组织与容量策略夸克网盘的云端目录结构我按“监控/摄像头ID/年月/日”来组织比如监控/ frontdoor/ 202506/ 20250601/ 20250601_000000.mp4 20250601_000500.mp4按年月分目录的好处是回放时不用在一个几千文件的目录里翻手机端也更容易按月份加载。网盘的列表接口通常只加载当前目录分目录能明显提升加载速度。容量策略上有几个现实问题要说清楚。免费网盘的可用空间是动态的、由服务商决定的不同账号、不同活动时期看到的额度可能完全不一样。网上传的“免费1T变10G”这类现象本质是促销额度过期或规则调整不能作为长期依赖的依据。所以我的原则是重要录像比如涉及安全事件的那几天除了网盘之外再手动下载一份到本地硬盘。鸡蛋不放同一个篮子。本地保留3天热缓存网盘保留理论上无限期的归档但如果网盘额度突然紧张优先保证最近一个月的录像完整更老的瞬间压缩或者删除。上传时尽可能用子码流而非主码流。720P子码流一天的录像量在2GB到4GB一个月也就100GB左右对大部分网盘免费空间来说压力小很多。5. 回放与远程查看的落地姿势5.1 局域网内直接翻本地录像回家之后要看监控回放不需要经过网盘。单板机上的/data/rec目录本身就是录像库最简单的方式是用caddy或者nginx把它发布成一个HTTP目录sudo apt install caddy然后写个简单配置:8080 { root * /data/rec file_server browse }浏览器里打开http://单板机IP:8080就能看到按日期排列的MP4文件点开直接在网页播放。手机上装VLC或nPlayer也可以直接访问这个地址。其实更省事的方案是开SMB共享。Armbian上装samba把/data/rec共享出去电视盒子上的Kodi、电脑的文件资源管理器、手机的文件管理器都能直接访问。SMB的好处是播放器可以边下边播大文件不卡顿快进快退也顺滑。如果不想折腾任何服务也可以直接把内存卡拔下来插电脑读。但这样做次数越多卡槽和卡越容易坏我还是建议让单板机自带Web服务一劳永逸。5.2 手机端远程回放夸克网盘App人在外面想看回放直接打开夸克网盘App进入“监控”目录按年月日逐层点开在线播放对应的MP4文件。这一步体验比想象中好视频文件是本地生成后上传的不存在转码等待点开就是秒播放拖动进度条虽然没本地那么跟手但也能接受。需要注意一个细节5分钟一个分段回放一段关键画面时如果跨越了两个文件你会看到两个列表项需要点两次。这是分段录制方案的固有特征不属于故障。想要减少跨文件次数可以把-segment_time调大比如调到10分钟代价是单个文件更大上传和播放在弱网下会稍慢。折中方案是5分钟别超过10分钟。5.3 需要“几乎实时”查看时怎么补这套系统主打的是连续录制和回放不是实时观看。但真有人想实时看家里画面怎么办呢不需要动架构直接在单板机上加装一个轻量RTSP转发服务就能解决。比如用Mediamtx原RTSP-Simple-Server做转发然后开一个二级ffmpeg进程把摄像头的子码流重新发布到单板机的RTSP端口上ffmpeg -rtsp_transport tcp -i rtsp://摄像头地址 -c copy -f rtsp rtsp://127.0.0.1:8554/live手机在局域网内用VLC播放rtsp://单板机IP:8554/live就能看到接近实时的画面。如果你想在外面也看实时就需要把端口作公网映射或者使用内网穿透类工具这块涉及公网安全和带宽容易踩坑我的建议是别在“实时”上较劲回放才是监控的核心价值。6. 常见问题与排查实录6.1 摄像头拉流失败与断流症状是脚本日志里不断出现ffmpeg报错、退出重启后又能录几分钟又断。这个问题的根源几乎都在RTSP传输上。排查顺序我建议是这样先确认摄像头IP没有变。路由器重启后DHCP可能给摄像头分配了新地址脚本里写的还是旧IP。把摄像头在路由器后台设成保留地址这一步能省掉一半以上的断流问题。确认用户名密码正确。密码变更后RTSP地址里的密码也要跟着改。把rtsp传输改成TCP。UDP在Wi-Fi环境下丢包会导致RTSP会话被服务端踢掉。使用子码流而不是主码流。很多百元摄像头主码流在弱网络下会主动断流子码流相对稳得多。还有一种情况是摄像头固件会对长时间RTSP会话做空闲断开。解决思路不是调摄像头而是让ffmpeg外层循环足够快地重启。前面脚本里5秒重启就能兜住大多数情况。6.2 内存卡写入失败或损坏症状是录像文件突然出现0字节、磁盘只读、写入I/O错误。连续写入是TF卡最残酷的使用场景之一杂牌卡在高温环境下几个月就会走完生命周期。排查和预防手段按重要性排序换用高速卡。至少要A1/A2级别最好是标了行车记录仪或监控专用的卡。写入速度低于20MB/s的卡不要碰。降低写入码率。摄像头后台把主码流码率上限调低或者直接用子码流录制写入量直接降一半以上卡的压力小很多。定期做写速测试。每两周执行一次dd写测试如果速度比新卡时期慢了一半说明卡已经在衰退趁早备份和更换。不要买来路不明的“扩容卡”。有些商家把16GB的卡刷成128GB写入超过真实容量就会丢数据数据全丢再赶工去买卡就晚了。6.3 上传任务卡死、限速和失败重试上传日志里rclone一直报“Too many requests”或者传一半卡住不动大概率是网盘对并发请求做了限制或者账号当天的上传配额用完了。对策也不复杂把rclone的并发传输数降到1用--transfers 1避免同时开多个任务。给两个文件之间加一个随机延时错峰请求。sleep $((RANDOM % 10 2))失败重试不要紧跟着来rclone默认会重试几次如果连续失败下次cron周期再试即可别把网盘接口打爆。检查本地文件有没有被误删。万一你的清理脚本写得太激进比如-mmin 2写成了-mmin 前面的数字不合法导致删除所有文件那网盘没传上去本地也没了就悲剧了。下面是一个能救急的经验建议直接抄在同步脚本里上传成功之后不要立刻删本地文件而是把文件move到/data/rec_uploaded目录等第二天的脚步检查网盘文件大小和本地目录大小一致再真正执行删除。这样多一层双保险代价只是多占一份本地空间。6.4 录像时间戳错乱和回放画面灰绿症状是文件名时间和画面内叠字时间对不上或者录像文件开头有几秒灰绿色画面。时间戳错乱通常是因为单板机系统时钟不对NTP同步没实际生效。执行timedatectl看时间如果偏移超过几分钟检查是不是防火墙挡了123端口或者系统里存在和systemd-timesyncd冲突的其他时间服务。回放开头灰绿几秒多是摄像头红外模式切换或夜晚转黑白时视频流中出现了短暂的无效帧。录像本身没问题回放时拖动跳过前两秒就行。如果每段都这样可以在摄像头后台把“红外切换延时”调大一点或者在ffmpeg录制命令里加-avoid_negative_ts make_zero但这个参数对正在写入的MP4分段没有追溯作用只能对以后的新分段生效。6.5 夸克网盘容量告急或额度变化免费网盘的容量是动态的一个活动期结束、一个促销过期、一个绑定任务没完成都可能导致可用空间大幅缩水。遇到这种情况我的处理顺序是先本地降级把热缓存保留时间从3天降到1天腾出空间。再云端瘦身删除超过两个月的录像至少留下最近一个月的完整归档。最后补一个重要防线的把涉及安全事件的那几天录像单独下载到本地加密硬盘。真正要紧的画面永远不要只存在任何一家网盘上。7. 实操心得与边界认知这套方案从闪念到跑通我大概花了一个下午加两个晚上。第一个晚上全在调RTSP地址发现摄像头后台文档写得不全最后是拿ONVIF工具扫出来的地址第二个晚上在折腾Alist挂载和rclone等真正把第一个MP4传上夸克网盘并手机回放成功的时候那个感觉确实是“一块石头落地了”。有几点心里话想跟正在折腾的人说。第一这套“本地热缓存 云端冷归档”的思路比单独买云存储会员或者单独插内存卡都靠谱它本质上是把消费级网盘的免费空间当成离线磁带在使单板机负责搬运和拎包摄像头还是那个干活的摄像头。第二不要神化“不花一分钱”电费虽然少但不是零一个月七八千瓦时总要的网络也要带宽上传速度慢就直接影响云端延迟。第三也是最想强调的任何免费服务都可能有额度、期限和稳定性变化真正重要的监控数据一定要养成“本地持久保存 云端方便读取”的双份习惯这个习惯比任何脚本都值钱。最后再分享一个小技巧如果你家摄像头有两个不用为每个摄像头都准备一台单板机。一台性能还行的ARM单板机完全能同时跑两个ffmpeg录制进程和同步脚本只要分开目录、分开日志就行。真正的瓶颈从来不是CPU而是你这个月愿不愿意花时间去把脚本参数调顺。希望这篇里的踩坑记录能帮你少走几个我当时绕过的弯路。
返回列表