企业官网建设流程全解析

我这人比较喜欢折腾，家里老笔记本闲置下来，屏幕还行，摄像头也还在，丢着吃灰总觉得可惜。有一次想拿它当临时监控，把摄像头画面接到局域网里，搜了一圈发现最顺手的组合就是FFmpeg + MediaMTX，一个负责采集编码，一个负责对外提供 RTSP 流，配合起来一条命令就能把 Windows 笔记本摄像头变成标准监控源。后面我又试了外接 USB 摄像头，发现这套流程完全通用。这篇我把自己踩过的坑和完整的配置过程整理出来，包括设备排查、推流参数怎么定、局域网拉流怎么调通、常见故障怎么解决，给你做个参考。

先说结论：只要你有一台 Windows 电脑，不管自带的摄像头还是外接 USB 摄像头，都能在十分钟内把它变成一台标准的RTSP 网络摄像机。做好的流可以被 VLC、PotPlayer、NVR、Home Assistant 等任意支持 RTSP 的客户端拉取。下面从方案选型开始一步步讲。

1. 方案选型：为什么是FFmpeg和MediaMTX，而不是别的组合

1.1 RTSP是什么，监控设备为什么都喜欢它

RTSP（Real Time Streaming Protocol，实时流传输协议）是 IP 摄像头、NVR 这类监控设备最常用的传输协议。它本身负责会话控制，像“播放”“暂停”“停止”，真正的音视频数据由 RTP 协议承载。它最实用的地方是天然支持 TCP 和 UDP 双模式，延迟能做到很低，而且绝大多数播放器只要拿到一个rtsp://ip:端口/路径格式的地址，就能直接打开看画面。

你可以把它理解成快递单号：摄像头把画面打包好，RTSP 就是那个通用的“取件地址”，只要给出地址，任何支持协议的客户端都能随时来取走视频流。所以这个方案的核心利用点，就是让普通电脑摄像头得到一个“监控设备标准接口”。

1.2 为什么用MediaMTX来做流媒体服务

市面上做流媒体中转的工具不少，常见有 nginx-rtmp、SRS、ZLMediaKit、MediaMTX 等。我在 Windows 上做轻量场景时优先选 MediaMTX，理由很简单：

• 单文件运行，解压就能用，不用装依赖环境。
• 默认同时支持 RTSP、RTMP、HLS、WebRTC 多种协议，不需要额外配置转发规则。
• 配置用 YAML 文件，逻辑清晰，改路径、改端口、加鉴权都很直接。
• 跨平台，之后如果你想迁移到树莓派或 Linux 小主机，同一个配置思路能继续用。

nginx-rtmp 也不是不行，但它偏重 RTMP 场景，要把流再转成 RTSP 还得加模块；SRS 功能全面，但 Windows 部署相对重。对于“把电脑摄像头变成 RTSP 摄像源”这个需求，MediaMTX 是最轻、最容易跑通的选择。

1.3 整套架构的数据流是怎么走的

先明确一下各个组件扮演的角色：

• FFmpeg：负责从 Windows 摄像头采集原始画面，编码成 H.264 视频流，再推送到流媒体服务器。
• MediaMTX：负责接收 FFmpeg 推上来的流，对外提供 RTSP/RTMP/HLS 等拉流入口。
• 拉流端：VLC、PotPlayer、ffplay、NVR、手机播放器等，用rtsp://地址来取流。

数据流是这样的：摄像头 → FFmpeg采集编码 → RTMP推流至MediaMTX → MediaMTX转发/转封装 → 客户端用RTSP地址拉流。

我习惯走“RTMP推流”这个方式，因为 RTMP 协议在推流端非常成熟，兼容性最好；再由 MediaMTX 对外提供 RTSP 拉流，正好补上 RTMP 不适合直接做监控分发的短板。实际操作时也可以直接用 FFmpeg 推 RTSP 给 MediaMTX，命令上把-f flv rtmp://...换成-f rtsp rtsp://...即可，但默认路径下走 RTMP 更稳，所以本文主要按 RTMP 推流来写。

2. 环境准备：Windows下装好FFmpeg和MediaMTX

2.1 FFmpeg下载与PATH配置

FFmpeg 在 Windows 下没有官方安装包，通常用第三方编译好的二进制文件。你可以在 gyan.dev 下载ffmpeg-release-essentials版本，或者在 BtbN 的 GitHub Releases 页面下载ffmpeg-master-latest-win64-gpl.zip。两个渠道的版本都很新，选哪个都行。下载后解压到比如C:\ffmpeg，然后把C:\ffmpeg\bin这个目录加到系统环境变量 PATH 里。

具体操作：右键“此电脑” → 属性 → 高级系统设置 → 环境变量 → 在“系统变量”里找到 Path → 编辑 → 新建 → 填入C:\ffmpeg\bin→ 确定。配置完以后，重新打开一个终端，输入ffmpeg -version，能看到版本信息就说明装好了。

使用 winget 安装也可以，命令是winget install ffmpeg，它会把 ffmpeg 放到一个目录并自动配好环境变量，只是偶尔需要重启终端才会生效。我更推荐手动解压，因为路径你自己心里有数，后面排查问题方便。

2.2 MediaMTX下载与默认配置解读

去 GitHub 上搜 MediaMTX，或者直接打开它的 Releases 页面，下载mediamtx_windows_amd64.zip这个文件。解压后你会得到两个关键文件：mediamtx.exe和mediamtx.yml。前者是主程序，后者是全部配置。

默认配置已经可以直接用，它会开启这么几个端口：

• RTSP：8554
• RTMP：1935
• HLS：8888
• WebRTC：8889

配置里有一个paths节点，决定哪些流路径被允许。默认all_others允许所有路径发布和订阅，所以你推流到camera，拉流就用rtsp://localhost:8554/camera，推流到live/test，拉流就用rtsp://localhost:8554/live/test。想加鉴权的话，在路径配置里写上readUser、readPass或者publishUser、publishPass就行，这个我们后面不展开，先跑通再说。

paths: camera: source: publisher

这种写法是显式声明camera路径允许外部推流订阅。如果你的配置文件里all_others被注释掉了，那就建议加上这段，否则推流可能被拒。

2.3 先跑通MediaMTX：启动与端口验证

在解压目录下双击mediamtx.exe，或者打开终端进入目录后运行mediamtx.exe，看到类似下面的日志就说明服务起来了：

INF [RTSP] listener opened on :8554 INF [RTMP] listener opened on :1935 INF [HLS] listener opened on :8888

想确认端口真的在监听，可以另开一个终端执行：

netstat -ano | findstr "8554 1935"

能看到LISTENING状态就说明服务没问题。如果是 Windows 防火墙弹窗，记得勾选“允许访问”，否则后面局域网设备拉不到流。走到这里，流媒体服务端已经就绪，接着就要让 FFmpeg 认出现有的摄像头。

3. 让Windows摄像头被FFmpeg认出来：dshow设备排查

3.1 dshow是什么，为什么Windows下必须用它

FFmpeg 在 Windows 上采集摄像头，靠的是 DirectShow（简称 dshow），这是 Windows 上一套历史悠久的音视频采集接口。它统一管理摄像头、麦克风、采集卡这类设备，FFmpeg 只要通过-f dshow就能拿到设备数据。

你可以把 dshow 理解成一根“水管适配器”。摄像头是水龙头，FFmpeg 是水桶，水管两头规格不一样，dshow 就是那个把两者接起来的关键配件。没有这个参数，FFmpeg 不知道去 Windows 哪里找摄像头。

3.2 列出摄像头设备名称的完整命令

很多教程直接写死video="Integrated Camera"，但你的设备名不一定叫这个。所以第一步永远是列出设备真名，命令如下：

ffmpeg -list_devices true -f dshow -i dummy

运行后会输出类似这样的内容：

DirectShow video devices (some may be both video and audio devices) "Integrated Camera" "USB Camera" DirectShow audio devices "Microphone Array"

注意设备名必须原样复制，大小写也要一致。如果设备名里有空格，必须用英文双引号包住，否则 FFmpeg 会把名字截断，报No such device错误。

更进阶的命令是查看摄像头支持哪些分辨率和帧率：

ffmpeg -list_options true -f dshow -i video="Integrated Camera"

输出里能看到pixel_format=yuyv422、min s=640x480、max s=1920x1080这类信息，还有对应的帧率范围。先看这个列表再选分辨率，可以有效避免后面黑屏问题。

3.3 摄像头被占用、设备名带特殊字符的坑

最容易踩的坑就是摄像头被其他软件占用。Windows 自带的“相机”应用、微信视频通话、腾讯会议这类软件一旦开着，FFmpeg 再打开同一设备就会报错，常见提示有Device or resource busy或者video capture failed。我一开始以为是驱动问题，排查半天才发现是“相机”应用没退出。所以遇到无法打开设备的情况，第一个动作就是把摄像头相关软件全部退掉。

第二个坑是设备名是中文或者带括号。有些笔记本显示“集成摄像头”或“USB Camera 2.0”，FFmpeg 在终端里读设备名时可能乱码。稳妥的做法是用设备管理器确认名称，或者直接用下面这个命令做本地预览测试，能弹窗看画面就说明设备名没问题：

ffplay -f dshow -i video="Integrated Camera"

第三个坑是摄像头驱动默认输出格式不理想。老款笔记本摄像头往往走 MJPEG 压缩输出，如果不加-input_format mjpeg，FFmpeg 可能按 yuyv422 无压缩格式采集，分辨率只能到 640x480，而且 CPU 占用飙高。加了这个参数后，很多摄像头能跑到 720p 甚至 1080p，CPU 占用反而更低。

4. 推流与拉流：摄像头秒变RTSP监控源

4.1 推流参数完整讲解

设备识别没问题后，就可以推流了。我用的标准命令是这个：

ffmpeg -f dshow -framerate 30 -video_size 1280x720 -input_format mjpeg -i video="Integrated Camera" -c:v libx264 -preset veryfast -tune zerolatency -b:v 2000k -g 60 -an -f flv rtmp://localhost:1935/camera

这里逐个参数解释一下，方便你按自己情况调整：

• -framerate 30：采集帧率。不要盲目设 30，先确认摄像头支持的最大帧率，多加并不总是好。
• -video_size 1280x720：采集分辨率。要选设备列表里支持的值，强行设置不支持的组合会黑屏。
• -input_format mjpeg：让摄像头输出 MJPEG 压缩帧，对老笔记本CPU友好。如果摄像头不支持，去掉这个参数，让 FFmpeg 走默认 yuyv422。
• -c:v libx264：用软件编码 H.264。兼容性最好，缺点是吃 CPU。如果机器有 Intel 核显可以试h264_qsv，有 NVIDIA 显卡可以试h264_nvenc，但不一定所有驱动都兼容，第一次调通建议先用 libx264。
• -preset veryfast：编码速度优先，延迟更小。ultrafast更快但画质差一点，fast画质好一点但延迟略高。
• -tune zerolatency：针对实时流优化，减少编码缓冲，这是低延迟的胜负手。
• -b:v 2000k：视频码率。720p 建议 1500k 到 3000k，1080p 建议 3000k 到 5000k。码率太低画面会糊，码率太高无线网络容易卡。
• -g 60：关键帧间隔。监控场景把它设成帧率的 2 倍左右比较平衡，比如 30fps 对应 60。GOP 太大会导致客户端起播慢、拖进度条慢。
• -an：不采集音频。如果你确实需要麦克风声音，可以去掉这个参数并加-f dshow -i audio="Microphone Array"，但音频调试会复杂一点，先把视频跑通再说。
• -f flv rtmp://localhost:1935/camera：以 FLV 格式封装，通过 RTMP 推送到 MediaMTX 的 1935 端口，路径是camera。

命令跑起来后，FFmpeg 会持续输出编码日志，看到frame= 12 fps=...这类不断滚动的信息，就说明正在推流。此时再打开一个终端，拉流验证一下就知道了。

4.2 拉流验证：VLC、PotPlayer、ffplay

本机验证最简单的方式是用 ffplay：

ffplay -rtsp_transport tcp rtsp://localhost:8554/camera

-rtsp_transport tcp指定用 TCP 传输，避免 UDP 方式下丢包导致的画面撕裂。也可以用 VLC 或 PotPlayer 直接打开网络串流：

• VLC：媒体 → 打开网络串流 → 输入rtsp://localhost:8554/camera。
• PotPlayer：打开设置 → 打开 URL → 输入同样的地址。

局域网内其他设备要拉流时，把localhost换成笔记本的局域网 IP，比如rtsp://192.168.1.100:8554/camera。手机装个“VLC for Mobile”或“nPlayer”，连同一个 WiFi 也能直接打开。VLC 默认会走 UDP 传输，如果画面花屏或卡顿，在拉流地址前后处理不如 ffplay 直接，所以我在建议里一直说用 TCP 模式。

MediaMTX 默认也开启 HLS，所以你可以顺手验证一下浏览器访问http://localhost:8888/camera，能看到一个播放页面就说明服务端已经把流完整接收进来了。

4.3 加入开机自启动和自动重推

FFmpeg 进程一旦异常退出，摄像头流就断了，而且没人发现。为了让这套方案更接近“真监控”，可以做两件事：自启动 + 断线自动重试。

写一个简单的批处理文件保存成start_camera_stream.bat：

@echo off :loop ffmpeg -f dshow -framerate 30 -video_size 1280x720 -input_format mjpeg -i video="Integrated Camera" -c:v libx264 -preset veryfast -tune zerolatency -b:v 2000k -g 60 -an -f flv rtmp://localhost:1935/camera timeout /t 5 goto loop

批处理会循环执行：FFmpeg 只要退出，就等 5 秒重新拉起。配合开机自启动的话，把批处理文件丢进系统的“启动”文件夹，或者用“任务计划程序”设置登录时运行即可。

这里有一个非常重要的经验：笔记本长期当监控源，合盖会睡眠，睡眠后摄像头自然就没数据了。建议把电源计划改成“从不睡眠”，合盖动作设为“不做任何操作”，否则你远程看画面时会抓狂。电源计划设置路径：控制面板 → 电源选项 → 更改计划设置 → 更改高级电源设置 → 睡眠 → 从不。

5. 常见问题与排查技巧实录

5.1 黑屏或无画面怎么办

黑屏是最常见的问题，绝大多数原因是采集参数和摄像头实际支持能力不匹配。

排查顺序是：先用ffplay -f dshow -video_size 640x480 -i video="设备名"确认本地预览能不能出画面。不能出就先解决设备占用问题和驱动问题；能出画面再逐步提高分辨率、帧率。加了-input_format mjpeg后黑屏，去掉它再试；不加黑屏，加上再试。这一步基本上能排查掉 90% 的黑屏问题。

如果预览正常，但推流后拉流黑屏，大概率是编码器或像素格式问题。可以在推流命令里加一个-vf format=yuv420p，强制输出 YUV420P 颜色格式，避免某些解码器不兼容而导致客户端画面无法显示。这个参数在群晖、甚至有些老 NVR 上非常有效。

5.2 高延迟、卡顿、断流频繁

高延迟优先检查两个点：推流端编码缓冲和拉流端传输模式。推流端已经加-tune zerolatency后延迟仍高，就把-preset从veryfast降到ultrafast，能明显减少编码耗时。拉流端建议统一用 TCP 模式，避免 UDP 丢包造成的画面卡顿和马赛克。

如果你发现 MediaMTX 日志里频繁出现client disconnected，说明网络不稳定或者有设备反复断开连接。很多时候是笔记本连了无线网，信号波动导致推流中断。有条件的话优先用网线，或者换一个信号好的位置，实测下来无线推流 1080p 经常会出现周期性花屏，降到 720p、码率压到 2Mbps 后稳定很多。

5.3 编码器报错和CPU飙高

推流时 FFmpeg 报Unknown encoder 'libx264'，说明你的 FFmpeg 是精简版，没有包含 H.264 编码器。解决方法是换一个完整版，比如 gyan.dev 的 full build 或 BtbN 的 gpl 版本，而不是自己手动安装一堆依赖。

老笔记本跑 1080p 的 libx264 编码，CPU 通常直接 100%，这时候从这几个方向优化：帧率降到 15fps、分辨率降到 720p 或 540p、-preset调到ultrafast、码率降到 1500k 左右。也可以用h264_qsv或h264_nvenc硬编码，Intel 核显或 N 卡都能分担 CPU 压力，但要注意部分驱动老版本兼容性差，可能出现编码画面异常，所以首次调试还是先用 libx264 把链路跑通，再切硬编。

5.4 局域网其他设备拉不到流的排查清单

本地拉流正常，但手机或另一台电脑拉流失败，基本是防火墙或 IP 地址问题。

按这个顺序查一遍：

1. 执行ipconfig，确认笔记本当前的局域网 IP，注意如果同时连着有线网和无线网，要看你实际想走哪个网卡。
2. 执行netstat -ano | findstr "8554"，确认 RTSP 服务确实在监听。
3. 检查 Windows 防火墙，手动添加入站规则，放行 TCP 8554、1935、8888 端口。
4. 在拉流端执行 ping 测试，先确认两台设备网络互通。
5. 拉流地址里不要忘了端口号8554，路径要和你推流时指定的路径完全一致。

防火墙是这里使用频率最高的拦路虎，添加一次入站规则就行，不用每次都关防火墙。关防火墙虽然一了百了，但风险很大，不推荐。

最后再分享一个我自己的体会

这套 FFmpeg + MediaMTX 的组合，我实际拿它当过两天的家庭临时监控看板，用来在阳台盯宠物动向。720p 分辨率、30fps、2Mbps 码率，笔记本 CPU 占用在 20% 上下，推流进程连续跑一下午没崩过。如果你要长时间挂机，建议把帧率降到 15fps、码率压到 1Mbps 左右，发热量和网络占用都会明显下降，画面流畅度其实影响不大。拉流端如果用 VLC，记得在偏好设置里把网络缓存调到 300ms 左右，播放体验会顺滑很多。这套方案成本低、可复制性强，后续你想加本地录像、加 WebRTC 低延迟页面、或者接入 Home Assistant 做联动，都是在这个基础上加一层配置的事，值得试试。