低成本自建视频监控：RTSP流媒体+本地录像实战

1. 为什么我要自己搭一套视频监控

家里有老人独居、店里想看看晚上的情况、车棚里停着两辆电动车、工位上的设备怕被人乱动，这些需求一说出来，很多人的第一反应是买一套成品监控。我最初也是这么想的，直到把市面上常见的方案认真算了一遍账，发现要么是“贵得没必要”，要么是“被绑定得很难受”。

成品方案的问题集中在三处。第一是硬件溢价，一台带云台的家用摄像头动辄三四百，四路套装轻松上千。第二是存储绑定，录像只能存到厂商的云空间，按月付费，一年下来又是一笔钱，而且数据在别人手里，能不能导出、导出什么格式，全看对方心情。第三是扩展性差，想加一路、想换个角度、想把画面同时推到自己的电脑上，往往没有接口。我真正想要的其实很简单：一路到四路的画面能实时看到、能自己存下来、成本压到最低、数据完全在自己手里。

这套东西说白了就是三个环节：采集与推流、传输与播放、落盘与录像。摄像头把画面编码成流，通过局域网推给一台常年开机的小主机，小主机一边把流分发出去给手机和电脑看，一边把流原样写进硬盘。整条链路上没有云、没有账号、没有订阅费，唯一的持续成本是那台小主机的电费，按十几瓦算，一年也就几十块。

硬件我最后是这么配的：两路网络摄像头，用的是支持标准流媒体协议的那类，单路一百出头；一台闲置的低功耗小主机当服务端，如果手头没有，二手淘一台两三百；一块监控级硬盘或者大容量固态，按存七天的量算，两路 1080p 大概需要 1T 出头。软件全部用开源组件，负责接收推流、转封装、分发和录制的那套组合，社区成熟、文档齐全，踩坑也有人问。整体算下来，一次投入控制在六七百块，之后就是纯白用。

需要说明的是，下文所有配置和参数都是我自己这套环境里跑通过的具体值，但我不会写死某台设备的型号，因为不同人手里的摄像头、主机、硬盘都不一样。你只要把 IP、分辨率、码率这三样对上，剩下的照着改就行。这套方案适合愿意花一个周末折腾、对数据自主权有要求、又不想被月费长期薅的人；如果你完全不想碰命令行，那成品套装确实更省心，这点我实话实说。

2. 整体架构与方案选型：为什么是这套组合

2.1 三个角色，一条数据流

先把整件事的骨架讲清楚，后面所有的配置都是在填这个骨架。系统里只有三个角色：摄像头（源）、服务端（中转+存储）、客户端（观看）。

摄像头负责把光信号变成压缩后的视频流，它内部其实做了三件事：感光、编码、封装。感光不用管，编码通常是 H.264 或 H.265，封装就是把编码后的数据打成一种能在网络上连续传输的格式。绝大多数网络摄像头都支持两种输出方式：一种是私有协议，只能用它自家的客户端看，这是厂商用来绑定用户的；另一种是标准流媒体协议，任何支持该协议的软件都能拉，这就是我们要用的。

服务端是整个系统的中枢，它干三件活。第一件是收流，把摄像头推过来的数据接住；第二件是分发，一路画面可能要同时给手机、电脑、电视盒子看，如果每个客户端都直接去连摄像头，摄像头那点可怜的并发能力立刻就崩了，所以必须由服务端做一对多的转发；第三件是录制，把流不加二次编码地直接写进硬盘，这样对 CPU 的消耗几乎为零。

客户端只做一件事：从服务端拉流并解码显示。电脑上用播放器，手机上用支持流媒体地址的播放 App，电视上装个播放器也行。这里有个关键认知：客户端越多，越说明服务端分发这一层不能省。

2.2 为什么选标准流媒体协议而不是厂商私有协议

这是整个项目里最重要的一个决策，值得单独说。厂商私有协议的特点是“开箱即用但锁死生态”，你只能用它的 App，只能在它的云上回看，一旦厂商停止服务或者你换了网络环境，设备基本就成了摆设。我在早期用过一台这样的设备，换了路由器之后死活连不上，最后只能恢复出厂，录像全丢。

标准流媒体协议的价值在于解耦。摄像头只管按标准吐流，服务端只管按标准收流，客户端只管按标准拉流，三方互不知情，任何一环都可以替换。今天用这个牌子的摄像头，明天想换一个，服务端配置一行不用改；今天用电脑看，明天想在电视上看，加个播放器就行。这种自由度在长期使用中的价值，远超过省下的那点配置时间。

常见的标准流协议有两类。一类是基于 HTTP 的，配置简单，延迟稍高，适合对实时性要求不极致的场景；一类是基于 UDP 的实时流协议，延迟低，但对网络抖动更敏感。我的选择是让摄像头直接输出实时流协议，服务端同时提供两种输出：内部录制走高实时的那路，给手机和电脑观看时按需转成兼容性更好的那路。这样既保证了录像是实时的，又保证了任何客户端都能播。

2.3 服务端软件的角色拆解

很多人第一次接触这套东西会晕，因为服务端不是一个软件，而是几个软件串起来的。我用的是社区里最常见的那套组合，拆开看是四个部分，各管一段：

这个拆法看起来麻烦，但每一层的存在都有理由。流媒体服务器本身不擅长处理 HTTP 的兼容性问题，所以需要转封装工具做适配；录制如果全靠服务器自带功能，灵活度不够，用调度工具能做出“检测到画面变化才录”这种精细策略；反向代理则是为了让外部访问只暴露一个端口，避免把内部服务直接摊在网络上。

提示：不要一开始就追求“全家桶式”的一体化软件。一体化方案初期省事，但一旦某个环节出问题，排查时你会发现自己面对的是一个黑盒。分层的好处是每一层都能单独测、单独换。

2.4 成本与性能的平衡点在哪里

低成本不等于低性能，关键是别把钱花在用不上的地方。我把预算分配的原则总结成三条。

第一，钱花在存储上，不花在算力上。因为整条链路是“不转码”的，服务端几乎不需要 CPU，一台十年前的小主机都能扛四路 1080p。反而是硬盘容量和寿命决定你能存多久。这里有个真实的坑：用普通桌面硬盘 7×24 小时连续写，半年到一年就容易出坏道，一定要用监控级硬盘，它的固件针对连续写入做了优化。

第二，摄像头不用买最贵的，但要买支持标准协议的。分辨率和夜视效果够用就行，1080p 对大多数家庭和店铺场景完全足够，4K 除了让硬盘爆得更快没有任何好处。但“支持标准流媒体协议”这一条不能妥协，这是整套方案能不能成立的前提。买之前一定要在参数页或者问客服确认，别信“支持 ONVIF”这种含糊说法，要明确问“能不能输出标准 RTSP 地址”。

第三，别在网络上省钱。摄像头到服务端这一段，如果走无线，2.4G 频段在晚上邻居都在用的时候会非常不稳，画面卡顿、录像花屏都可能。有条件一定走网线，实在不行至少用 5G 频段，并且把摄像头和服务端放在同一个路由下。

3. 采集端配置：把摄像头调成一个合格的流源

3.1 摄像头到手后必须改的五个设置

新摄像头拆封，默认配置基本都不能直接用。我每次上手都按固定顺序改五处，改完再谈推流。

第一，固定 IP。摄像头默认是动态获取地址，路由器一重启，IP 变了，服务端所有配置全部失效，这是新手最容易踩的坑。进摄像头后台，把网络设置改成静态，地址选一个路由器地址池之外的段，比如路由器是 192.168.1.1，设备就固定在 192.168.1.200 往后。同时把网关和 DNS 填对，否则设备可能连不上外网导致时间同步失败。

第二，关掉一切“智能”功能。移动侦测、人形识别、自动跟踪、宽动态、降噪，这些在摄像头本地跑的功能会消耗它本来就弱的算力，导致编码不稳、码率抖动。我们要的是稳定的原始流，智能分析放到服务端做，或者干脆不做。

第三，锁定编码参数。编码格式选 H.264，别选 H.265。原因很实际：H.265 虽然省一半带宽，但兼容性差，很多播放器和浏览器的解码支持不完整，你会在调试播放环节浪费大量时间。等整条链路跑通之后，再单独测试 H.265 是否可行。分辨率锁 1080p，帧率锁 15 到 20 帧，监控场景不需要 30 帧，帧率低一点码率就低，硬盘就能多存几天。

第四，设好码率上限。这一步决定了你的硬盘能存多久，必须自己算。计算公式是：

单路每天容量(GB) = 码率(Mbps) × 3600 × 24 ÷ 8 ÷ 1024

按 2 Mbps 算，单路一天约 21 GB，两路七天约 300 GB。如果摄像头默认是 4 Mbps，容量直接翻倍。我一般把 1080p 的码率控制在 1.5 到 2.5 Mbps 之间，画质和体积的平衡点大概在这里。设成变码率（VBR）比固定码率更好，静止画面时码率会自动掉下来，实际占用能再省三成。

第五，校时。让摄像头从内网的时间服务同步时间，别用默认的境外服务器。录像文件的时间戳错了，事后回看基本等于废了，找一段关键画面要翻半天。

3.2 拿到 RTSP 地址并验证

改完设置，下一步是拿到那条流的地址。不同厂家的路径格式不一样，常见的形如：

rtsp://用户名:密码@192.168.1.200:554/stream1

有些设备主码流和子码流是两条地址，主码流是 1080p，子码流是 480p 左右。两个都要留着：主码流用于录像，保证回看清晰；子码流用于手机远程看，省带宽、加载快。这个区分很实用，很多人不知道，结果手机上拉 1080p 卡得不行。

拿到地址后先别急着配服务端，用播放器单独验证这条流能不能通。电脑上随便一个支持流媒体地址的播放器，把地址粘进去，能出画面就说明摄像头这端没问题。这一步的意义是隔离故障域：如果后面服务端拉不到流，你可以确定问题不在摄像头。

3.3 一个容易被忽略的细节：并发连接数

大部分消费级摄像头只允许 1 到 4 个客户端同时连它的流。这意味着如果你让手机、电脑、录像程序都直接连摄像头，第四个连接进来时就会随机踢掉一个，表现是“画面时不时黑一下”。这也是为什么必须有服务端做中转——服务端只连摄像头一次，剩下的分发全在服务端完成。

4. 服务端搭建：从收流到落盘的完整实操

4.1 系统与依赖的准备

服务端我用的是一台低功耗小主机，装的轻量 Linux 发行版。选它的理由是资源占用低、软件源齐全、出问题好查日志。如果你只有一台 Windows 机器也完全可以，把下面所有工具换成对应的 Windows 版本即可，思路一模一样。

先把系统更新到最新，然后装三样东西：流媒体服务器、转封装工具、以及一个用来做定时任务的组件。安装方式按发行版的包管理器来，装完先别配，用命令确认版本能正常输出来，确认这几个服务能启动。

有一点必须提醒：所有服务都不要用 root 跑。给每个服务建独立的低权限用户，数据目录的属主也改掉。这不是洁癖，是万一某个服务出漏洞，攻击者拿到的只是一个空权限账号，你的其他数据还是安全的。

4.2 流媒体服务器的核心配置

配置文件是整件事的核心，我把它拆成四块讲，每块的作用和参数含义都说清楚。

第一块是收流入口。要让服务器在某个端口上等待摄像头的推流。有两种接法：一种是摄像头主动推（推流模式），一种是服务器主动去拉（拉流模式）。我推荐拉流模式，因为摄像头大多不支持主动推，而且拉流模式下服务器断线重连的逻辑更可控，摄像头重启后服务器会自动重连，不需要人工干预。

第二块是应用与流名。在服务器里给每路摄像头定义一个应用名和流名，比如应用叫live，流名叫cam1、cam2。这样最终对外暴露的地址就是固定的rtsp://服务器地址:8554/live/cam1，客户端只认这个地址，摄像头换了、IP 变了，客户端完全无感。这就是前面说的“解耦”的具体体现。

第三块是录制策略。常见的做法有三种：一直录、按时间片段录、按事件录。我选的是分段一直录，每段切成 10 分钟一个文件。为什么是 10 分钟？因为文件太小会产生海量小文件，检索和删除都很痛苦；文件太大则单个文件损坏时损失太大，而且不方便回看时拖进度。10 分钟大约 1.5 GB，是个比较舒服的粒度。

录制的触发方式有两种：一种是靠服务器的钩子，在流开始的时候自动启动录制进程；一种是让服务器自己录。我倾向用外部工具录，因为外部工具能做的事更多，比如转成更通用的封装格式、自动清理过期文件。

第四块是访问控制。一定要给流地址加认证，别裸奔。裸奔的地址一旦被扫到，等于你家客厅画面挂在公网上。加认证的方式是在地址里带用户名密码，或者用反向代理挡一层。

下面是我配置文件的关键片段，参数都是实测可用的：

# 流媒体服务器配置（节选，路径按自己的目录改） paths: cam1: # 拉流模式：服务器主动去摄像头取流 source: rtsp://viewer:密码@192.168.1.200:554/stream1 # 断流后自动重连 sourceOnDemand: no # 录制：切成10分钟一段，存到指定目录 record: yes recordPath: /data/records/cam1/%Y-%m-%d_%H-%M-%S.mp4 recordSegment: 600 recordFormat: mp4 # 只保留最近7天 recordDeleteAfter: 168h

这段配置的信息量不小，逐条解释：sourceOnDemand: no表示不管有没有客户端在看，都持续从摄像头拉流——这是录制能持续的前提，如果设成yes，没人看的时候就不拉流，录像也就断了。recordFormat选 mp4 是为了通用性，任何播放器都能开，代价是如果录制进程被强杀，最后一个文件可能损坏，所以要用平滑停止的方式重启服务。recordDeleteAfter让服务器自动清老文件，这一步至关重要，不然硬盘迟早写满，写满之后所有录制静默失败，你还以为在正常录。

注意：recordDeleteAfter是按文件修改时间删的，一定要确保服务端时间准确，并且时区设置正确。时区错了，清理逻辑会把“未来”的文件当成老文件删掉，或者永远不删。

4.3 把实时流转成浏览器和手机都能播的格式

流媒体服务器的原生协议在浏览器里播不了，需要转一层。转封装工具的作用是把实时流重新封装成基于 HTTP 的流，浏览器和手机 App 直接就能播。

这里的技术选择是：只在有人请求时才启动转封装，没人看就停掉。原因很实在——转封装要吃一点 CPU，四路一直转，小主机的风扇就开始叫了。按需启动的配置方式是在转封装工具里配置一个“按需”参数，请求进来才拉起进程，闲置一段时间后自动退出。

转封装过程中有几个参数值得说：

• 关键帧间隔：设成 2 秒左右。间隔太短，文件大、CPU 高；太长，客户端开始播放时要等很久才能出画面。
• 缓冲长度：给客户端留一点缓冲，网络抖动时不会立刻卡。设 1 到 2 秒比较合适。
• 不要二次编码：参数里明确用“直接复制流”的方式，千万别开滤镜或转码，那会让 CPU 占用翻好几倍，低成本的前提就没了。

配置好之后，在浏览器里访问http://服务器地址:8888/live/cam1，能出画面就说明这层通了。手机端同理，用支持该流格式的播放 App 填入这个地址即可。

4.4 让外部访问安全地进来

如果只想在家里局域网看，这一节可以跳过，直接看第 5 节。但只要你想在外面看，就必须处理访问入口的问题。

我的做法是用反向代理把所有服务的入口收拢成一个，只对外开一个端口，加上一层基础认证。这样有几个好处：外部只能看到一个入口，内部的数据库、配置文件都探不到；认证在入口处统一做，不用每个服务单独配；之后想加别的服务，挂到同一个入口下就行。

反向代理的配置要点是不要忘记给流媒体协议单独放行，因为有些流协议走的是 TCP 长连接，反向代理默认的超时时间会把连接掐断，表现是“看几分钟就断”。需要把超时时间调大，并且对这个路径关闭缓冲。

提示：做外部访问之前一定要想清楚暴露的风险。我自己的原则是：入口只对自己开放，认证用足够长的随机密码，能不开的端口一个都不开。这套系统的价值在于数据在自己手里，如果因为配置不当把画面漏出去了，那就本末倒置了。

4.5 用定时任务把“运维”这件事自动化

系统跑起来之后，真正决定它能不能长期稳定的是自动化。我配了三个定时任务：

任务一，每天凌晨检查磁盘。剩余空间低于 20% 就额外清理最老的文件，并把告警写进日志。

任务二，每小时检查各服务的存活。用简单的健康检查请求探测服务端口，连续两次失败就重启对应服务，并记录时间。摄像头挂了、网络闪断这类事一定会发生，关键是它能不能自己恢复。

任务三，每天校验录像完整性。抽查最新几个文件能否正常打开、时长是否接近 10 分钟。我遇到过录制进程还在跑但文件一直是 0 字节的情况，原因是磁盘满了但没告警。这个校验能兜住这类静默失败。

这三条脚本加起来不到一百行，但它们带来的稳定性提升比任何硬件升级都明显。监控系统最怕的不是坏，是坏了你不知道。

5. 播放端：把画面送到该看的地方

5.1 局域网内的几种播放方式

局域网内是最简单的场景，服务端转封装之后，任何能打开网页的设备都能看。电脑浏览器直接访问地址；手机连同一个 Wi-Fi，用播放 App 填地址；电视盒子装个支持网络流的播放器，输地址就行。

真正需要动脑子的是多画面同屏。想在一个页面里同时看四路，最省事的办法是用一个静态页面，里面嵌四个播放窗口，每个窗口指向一路流的地址。这个页面放在服务端上，任何设备打开都是一个地址，不用记四条流地址。这个页面纯静态，几十行代码，不需要后端。

还有个实用技巧：给每路流配上子码流地址做移动端观看。手机上屏小，看 480p 的子码流足够，加载快、流量省、还省电。配置文件里把两套地址都留着，页面做两个入口，“高清”和“流畅”，实际体验差别很大。

5.2 外网观看的延迟与画质取舍

外网观看本质上是带宽问题。1080p 主码流 2 Mbps，上传带宽不够就会卡。这里的取舍逻辑是：外网一律走子码流，牺牲清晰度换流畅度，需要看细节的时候再手动切主码流。

延迟方面，实时流协议的延迟能压到 1 秒以内，基于 HTTP 的流延迟通常在 3 到 10 秒。想低延迟就用实时协议，想要兼容性好、随便什么设备都能播就用 HTTP 流。我的配置是两条路都留着，日常用 HTTP 流看，需要盯实时情况时切到低延迟那条。

这里有个实测发现：延迟不仅取决于协议，还取决于客户端的缓冲策略。有些播放器默认缓冲好几秒，换个播放器延迟立刻降下来。所以如果觉得“怎么这么慢”，先换个客户端试试，别急着改服务端。

5.3 录像回看做得好不好，决定这套系统好不好用

回看是监控系统真正被使用的功能，但也是最容易被做烂的。我踩过的坑是：一开始录像就是一堆按时间命名的文件，找某天下午三点的画面，得在文件列表里翻，翻到了还要拖进度条，体验极差。

后来我做了两个改进。

改进一，目录按日期分层。路径写成年/月/日/，文件名带时分秒。这样用任何文件管理器都能快速定位，不依赖任何专用软件。

改进二，做一个简单的索引页面。服务端每天生成一个列表页，按摄像头和时间列出当天的文件，点一下就能在浏览器里直接播。这个页面用一个脚本扫目录生成静态 HTML 就行，不需要数据库。做了这个之后，回看的体验从“忍受”变成了“可用”。

还有一点：录像的封装格式选 mp4 而不是专用格式。专用格式虽然容错性好，但只能用它自家的播放器开，导出、剪辑、发给别人都麻烦。mp4 双击就能开，接受度最高。代价是录制中断时文件可能损坏，所以服务停止一定要用平滑方式，别直接断电。

6. 常见问题与排查实录

6.1 故障速查表

这套系统跑了一年多，常见故障基本都遇到过了，整理成一张表，出问题时按这个顺序查，能省很多时间：

6.2 三个我踩过的坑，值得单独讲

坑一：硬盘写满导致静默失败。这是我遇到过最阴险的问题。硬盘满了之后，录制进程不会报错退出，它会继续尝试写，只是每次都失败，日志里安静得像什么都没发生。等你发现的时候，可能已经一周没录上了。解决方法是在录像目录之外单独监控磁盘使用率，超过 80% 就清理最老的文件，超过 90% 就主动告警。不要依赖录制软件自带的清理功能，它的触发条件不够及时。

坑二：H.265 的兼容性陷阱。图省带宽把摄像头切成 H.265，结果服务端能收、能录，但浏览器播不出来，手机 App 也有一半不支持。折腾了两个晚上才定位到原因。教训是：任何编码格式的变更都要在全链路验证之后再上线，先在子码流上试，别一上来就改主码流。

坑三：无线摄像头的夜间卡顿。白天好好的，一到晚上就卡。查了半天，原因是邻居家的 Wi-Fi 晚上都开着，2.4G 频段挤成一锅粥。用工具扫了一下信道，把路由器切到最空闲的信道，情况明显好转，但根本解决还是拉了网线。这件事让我彻底放弃在监控链路上用无线。

6.3 长期稳定运行的几条经验

跑了这么久，我总结出几条不成文但很有用的规矩。

规矩一：服务端要能自己起来。断电重启之后，所有服务应该自动拉起，不用人管。每个服务都配开机自启，并且配好启动顺序——先网络、再流媒体服务器、最后录制和转封装。顺序错了会出现“服务起来了但拉流失败”的情况。

规矩二：定期手动看一眼。自动化再完善，也建议每周花两分钟打开播放页看一眼画面。我有一次发现摄像头被蜘蛛网糊住了角落，画面还在、时间也在走，只是有一块一直是灰的，自动检测完全发现不了。

规矩三：配置改完先验证再收工。改任何一个参数，都要走一遍“拉流、播放、录像、回看、清理”五个环节。尤其是清理策略，改错了可能把还在录的文件删掉。

规矩四：日志要留，但别留太多。每个服务都要有日志，出问题第一时间看日志比瞎猜快十倍。但日志本身也会撑满磁盘，配好轮转，保留七天足够。

7. 这套系统的扩展方向与个人体会

整套东西跑通之后，最有意思的部分其实是扩展。因为每一层都是解耦的，想加什么东西都不用动原有结构。

比如加一路摄像头，只需要在配置里复制一段，改个流名和 IP，五分钟的事。比如想做移动侦测，不用在摄像头上开那个耗算力的功能，用服务端定期截一帧和上一帧比对，差异超过阈值就触发一段事件录像，这样平时只存低码率的关键帧，硬盘占用能再降一大截。比如想把画面推到电视上，电视盒子装个播放器填地址就行，不用买任何新硬件。再比如想让录像自动备份到另一台机器上，用文件同步工具把目录单向同步过去，成本极低。

我个人在实际操作中的体会是，这套系统的技术难度其实不高，所有的坑都在“细节有没有想到”上。真正拉开差距的不是用了什么高级软件，而是有没有算过码率、有没有固定 IP、有没有配自动清理、有没有想过磁盘满了会怎样。这些事一件都不做也能跑起来，但跑一个月和跑一年是两回事，跑一年和出事时能拿出录像又是两回事。

如果让我给第一次搭的人一句建议，那就是：先把单路跑通，跑稳一周，再扩到多路。多路的问题往往不是单路的简单叠加，而是并发、带宽、磁盘、CPU 一起较劲。我见过太多人一次性上四路，然后在各种互相干扰的故障里彻底放弃。一路稳了，剩下的都是复制粘贴。