1. 为什么我要自己搭一套视频监控家里有老人独居、店里想看看晚上的情况、车棚里停着两辆电动车、工位上的设备怕被人乱动这些需求一说出来很多人的第一反应是买一套成品监控。我最初也是这么想的直到把市面上常见的方案认真算了一遍账发现要么是“贵得没必要”要么是“被绑定得很难受”。成品方案的问题集中在三处。第一是硬件溢价一台带云台的家用摄像头动辄三四百四路套装轻松上千。第二是存储绑定录像只能存到厂商的云空间按月付费一年下来又是一笔钱而且数据在别人手里能不能导出、导出什么格式全看对方心情。第三是扩展性差想加一路、想换个角度、想把画面同时推到自己的电脑上往往没有接口。我真正想要的其实很简单一路到四路的画面能实时看到、能自己存下来、成本压到最低、数据完全在自己手里。这套东西说白了就是三个环节采集与推流、传输与播放、落盘与录像。摄像头把画面编码成流通过局域网推给一台常年开机的小主机小主机一边把流分发出去给手机和电脑看一边把流原样写进硬盘。整条链路上没有云、没有账号、没有订阅费唯一的持续成本是那台小主机的电费按十几瓦算一年也就几十块。硬件我最后是这么配的两路网络摄像头用的是支持标准流媒体协议的那类单路一百出头一台闲置的低功耗小主机当服务端如果手头没有二手淘一台两三百一块监控级硬盘或者大容量固态按存七天的量算两路 1080p 大概需要 1T 出头。软件全部用开源组件负责接收推流、转封装、分发和录制的那套组合社区成熟、文档齐全踩坑也有人问。整体算下来一次投入控制在六七百块之后就是纯白用。需要说明的是下文所有配置和参数都是我自己这套环境里跑通过的具体值但我不会写死某台设备的型号因为不同人手里的摄像头、主机、硬盘都不一样。你只要把 IP、分辨率、码率这三样对上剩下的照着改就行。这套方案适合愿意花一个周末折腾、对数据自主权有要求、又不想被月费长期薅的人如果你完全不想碰命令行那成品套装确实更省心这点我实话实说。2. 整体架构与方案选型为什么是这套组合2.1 三个角色一条数据流先把整件事的骨架讲清楚后面所有的配置都是在填这个骨架。系统里只有三个角色摄像头源、服务端中转存储、客户端观看。摄像头负责把光信号变成压缩后的视频流它内部其实做了三件事感光、编码、封装。感光不用管编码通常是 H.264 或 H.265封装就是把编码后的数据打成一种能在网络上连续传输的格式。绝大多数网络摄像头都支持两种输出方式一种是私有协议只能用它自家的客户端看这是厂商用来绑定用户的另一种是标准流媒体协议任何支持该协议的软件都能拉这就是我们要用的。服务端是整个系统的中枢它干三件活。第一件是收流把摄像头推过来的数据接住第二件是分发一路画面可能要同时给手机、电脑、电视盒子看如果每个客户端都直接去连摄像头摄像头那点可怜的并发能力立刻就崩了所以必须由服务端做一对多的转发第三件是录制把流不加二次编码地直接写进硬盘这样对 CPU 的消耗几乎为零。客户端只做一件事从服务端拉流并解码显示。电脑上用播放器手机上用支持流媒体地址的播放 App电视上装个播放器也行。这里有个关键认知客户端越多越说明服务端分发这一层不能省。2.2 为什么选标准流媒体协议而不是厂商私有协议这是整个项目里最重要的一个决策值得单独说。厂商私有协议的特点是“开箱即用但锁死生态”你只能用它的 App只能在它的云上回看一旦厂商停止服务或者你换了网络环境设备基本就成了摆设。我在早期用过一台这样的设备换了路由器之后死活连不上最后只能恢复出厂录像全丢。标准流媒体协议的价值在于解耦。摄像头只管按标准吐流服务端只管按标准收流客户端只管按标准拉流三方互不知情任何一环都可以替换。今天用这个牌子的摄像头明天想换一个服务端配置一行不用改今天用电脑看明天想在电视上看加个播放器就行。这种自由度在长期使用中的价值远超过省下的那点配置时间。常见的标准流协议有两类。一类是基于 HTTP 的配置简单延迟稍高适合对实时性要求不极致的场景一类是基于 UDP 的实时流协议延迟低但对网络抖动更敏感。我的选择是让摄像头直接输出实时流协议服务端同时提供两种输出内部录制走高实时的那路给手机和电脑观看时按需转成兼容性更好的那路。这样既保证了录像是实时的又保证了任何客户端都能播。2.3 服务端软件的角色拆解很多人第一次接触这套东西会晕因为服务端不是一个软件而是几个软件串起来的。我用的是社区里最常见的那套组合拆开看是四个部分各管一段组件职责类比流媒体服务器接收推流、对外分发、触发录制小区的快递驿站转封装工具把实时流按需转成 HTTP 流驿站里的分拣员录制调度决定何时录、录多久、存哪里驿站的入库登记反向代理统一入口、加一层访问控制小区大门门禁这个拆法看起来麻烦但每一层的存在都有理由。流媒体服务器本身不擅长处理 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 故障速查表这套系统跑了一年多常见故障基本都遇到过了整理成一张表出问题时按这个顺序查能省很多时间现象最可能的原因排查动作服务端拉不到流摄像头 IP 变了 / 密码错 / 编码格式不支持先用播放器直连摄像头地址验证画面偶尔黑屏摄像头并发连接数不够 / Wi-Fi 不稳检查是否有设备在直连摄像头改走网线录像文件 0 字节磁盘写满 / 目录权限不对看磁盘剩余空间和数据目录属主回看时间对不上摄像头或服务端时区错检查两端的时区和时间同步外网看几分钟就断反向代理超时 / 上传带宽不足调大超时降码率或改子码流手机端加载极慢拉的是主码流 / 转封装未按需启动换子码流地址检查转封装配置CPU 占用异常高开了二次编码 / 编码格式是 H.265确认所有环节都是“直接复制流”6.2 三个我踩过的坑值得单独讲坑一硬盘写满导致静默失败。这是我遇到过最阴险的问题。硬盘满了之后录制进程不会报错退出它会继续尝试写只是每次都失败日志里安静得像什么都没发生。等你发现的时候可能已经一周没录上了。解决方法是在录像目录之外单独监控磁盘使用率超过 80% 就清理最老的文件超过 90% 就主动告警。不要依赖录制软件自带的清理功能它的触发条件不够及时。坑二H.265 的兼容性陷阱。图省带宽把摄像头切成 H.265结果服务端能收、能录但浏览器播不出来手机 App 也有一半不支持。折腾了两个晚上才定位到原因。教训是任何编码格式的变更都要在全链路验证之后再上线先在子码流上试别一上来就改主码流。坑三无线摄像头的夜间卡顿。白天好好的一到晚上就卡。查了半天原因是邻居家的 Wi-Fi 晚上都开着2.4G 频段挤成一锅粥。用工具扫了一下信道把路由器切到最空闲的信道情况明显好转但根本解决还是拉了网线。这件事让我彻底放弃在监控链路上用无线。6.3 长期稳定运行的几条经验跑了这么久我总结出几条不成文但很有用的规矩。规矩一服务端要能自己起来。断电重启之后所有服务应该自动拉起不用人管。每个服务都配开机自启并且配好启动顺序——先网络、再流媒体服务器、最后录制和转封装。顺序错了会出现“服务起来了但拉流失败”的情况。规矩二定期手动看一眼。自动化再完善也建议每周花两分钟打开播放页看一眼画面。我有一次发现摄像头被蜘蛛网糊住了角落画面还在、时间也在走只是有一块一直是灰的自动检测完全发现不了。规矩三配置改完先验证再收工。改任何一个参数都要走一遍“拉流、播放、录像、回看、清理”五个环节。尤其是清理策略改错了可能把还在录的文件删掉。规矩四日志要留但别留太多。每个服务都要有日志出问题第一时间看日志比瞎猜快十倍。但日志本身也会撑满磁盘配好轮转保留七天足够。7. 这套系统的扩展方向与个人体会整套东西跑通之后最有意思的部分其实是扩展。因为每一层都是解耦的想加什么东西都不用动原有结构。比如加一路摄像头只需要在配置里复制一段改个流名和 IP五分钟的事。比如想做移动侦测不用在摄像头上开那个耗算力的功能用服务端定期截一帧和上一帧比对差异超过阈值就触发一段事件录像这样平时只存低码率的关键帧硬盘占用能再降一大截。比如想把画面推到电视上电视盒子装个播放器填地址就行不用买任何新硬件。再比如想让录像自动备份到另一台机器上用文件同步工具把目录单向同步过去成本极低。我个人在实际操作中的体会是这套系统的技术难度其实不高所有的坑都在“细节有没有想到”上。真正拉开差距的不是用了什么高级软件而是有没有算过码率、有没有固定 IP、有没有配自动清理、有没有想过磁盘满了会怎样。这些事一件都不做也能跑起来但跑一个月和跑一年是两回事跑一年和出事时能拿出录像又是两回事。如果让我给第一次搭的人一句建议那就是先把单路跑通跑稳一周再扩到多路。多路的问题往往不是单路的简单叠加而是并发、带宽、磁盘、CPU 一起较劲。我见过太多人一次性上四路然后在各种互相干扰的故障里彻底放弃。一路稳了剩下的都是复制粘贴。