简介这是一款主打零依赖、零配置启动的摄像机流媒体应用源码项目支持 RTSP、WebRTC、RTMP、HTTP-FLV、HLS、MJPEG、HomeKit 等常见流媒体协议围绕跨平台实时视频流的接入、转换与分发场景展开兼顾协议解析、音视频处理与设备接入适合流媒体开发者、智能家居集成者以及嵌入式调试人员参考。压缩包共 363 个文件仅 779KB主体为 293 个 Go 源码文件辅以 Markdown 说明文档、HTML 示例页面、Dockerfile 与 Shell 部署脚本等目录划分覆盖核心实现、协议测试与容器化部署整体结构清晰、便于按模块查阅。目前已有 86 人学习下载适合入门到进阶的开发者作为实战参考。内容包含 FFmpeg 转码、ONVIF 探测、H.264/H.265 编码处理等关键实现可帮助读者理解零延迟流媒体链路、多路音视频混合以及 HomeKit 摄像头接入机制。随附的测试文件、构建脚本和容器配置也为二次开发和智能家居联动提供了可直接复用的工具与排错思路。1. 摄像机流媒体应用一个 zip 里打包的是一整条协议链刚接手安防项目时我最常被问到的一句话是摄像头 RTSP 地址拿到了怎么让它出现在网页里直接给video标签塞一个rtsp://地址是不行的浏览器根本不认这个协议。这类打包成 zip 发布的“终极摄像机流媒体应用程序”干的正是这件事把摄像机的 RTSP 流拉进来再按你的需要吐成 HLS、HTTP-FLV、WebRTC、MP4 甚至 MJPEG让多端播放器和后端算法都能消费。它解决的从来不是“播放一个问题”而是整套接入协议矩阵的问题。适合谁用经常跟 IPC/NVR 打交道的集成工程师、做 Web 播放器的前端、以及需要把视频流喂给 YOLO 等推理服务的人。下面我就按部署、配置、避坑、验证的顺序把这条链路逐个拆开讲。2. 多协议中转为什么摄像头画面不能直接塞进浏览器2.1 摄像头只认 RTSP浏览器只认 HTTP 系协议先说结论RTSP 是控制协议它负责会话协商、播放暂停、seek 这些动作真正的视频数据走的是 RTP 包。浏览器不实现 RTSP/RTP 栈所以任何“直接在网页里播 RTSP”的做法都是绕路最常见的绕法是装插件而插件这条路早就被现代浏览器堵死了。那 RTMP 呢RTMP 当年是 Flash 时代的直播主力Flash 退出后RTMP 在公网播放端几乎绝迹但它仍然大量存在于“推流”场景里摄像头或 OBS 把流推到流媒体服务器服务器再把 RTMP 转成 HTTP-FLV 给网页消费。所以你看标题里 RTSP、RTMP 是输入侧和转发侧HLS、WebRTC、MSE 才是真正面向浏览器的输出侧。各协议在一套摄像机流媒体应用里的角色我习惯用下面这张表来记协议角色浏览器能否直接播放典型场景端到端延迟RTSP拉流/采集否摄像头、NVR、监控平台取流无标准参照RTMP推流/服务间转发否Flash 已废弃OBS/编码器推流到中间层1-2 秒HTTP-FLV低延迟分发需 flv.js 包装直播、网页低延迟监看1-3 秒HLS兼容性最好的分发原生或 hls.js公网直播、回放、多平台兼容3-10 秒WebRTC实时通信级分发原生支持低延迟对讲、实时预览0.2-1 秒MSE浏览器媒体扩展能力是不是协议为 HLS/fMP4 提供分段播放能力取决于封装来源MP4/MJPEG点播抓图/低端设备分别支持/不支持录像回放、老嵌入式页面秒级到分钟级MSE 单独拿出来说它不是拉流的协议而是浏览器允许网页自己喂数据给video的 API。hls.js 能把 TS 分片转成 fMP4 再喂给 MSE这就是 HLS 不需要播放器插件也能在新版浏览器里跑的原因。只要你想在“网页”里看监控HLS 和 WebRTC 这两条路至少得通一条。2.2 中转层的三步流水线拉流、转封装、分发这类程序不管 ui 长什么样内核都是同一个流水线拉流器把源端数据读进来中间层把数据归一化成内部裸流分发器按输出协议重新打包。这里的“归一化”很关键——摄像头可能给你 H.264也可能给你 H.265可能是 RTSP over UDP也可能是 RTSP over TCP音频可能是 G.711 也可能是 AAC。如果不在中间层统一处理后面接 HLS 就写一套代码接 WebRTC 又写一套维护成本直接爆炸。真正需要理解的是转封装remux和转码transcode的区别。转封装动的是容器不动编码RTSP 里的 H.264 流可以原封不动塞进 HLS 的 TS 分片也能塞进 FLV。转码则是把 H.265 变成 H.264或者把 4K 主码流压成 480p 子码流这需要非常重的计算资源。我见过很多新手的误区是一上来就-c:v libx264硬转码。实际上只要播放端能兼容原始编码直接-c copy才是性价比最高的方案。只有当源是 H.265、浏览器是 Safari/Chrome 新版但老客户端不支持时才必须转 H.264。做监控视频拉流 RTSP 再喂给 YOLO 这类智能分析时也是一样的道理推理进程要的是稳定、低码率、低延迟的视频帧而不是让每路都浪费 CPU 去解 4K 主码流。正确做法是让中间层输出一路低分辨率的子码流或关键帧流再交给算法端。2.3 把 FFmpeg 包进程序而不是依赖系统安装很多类似程序选择内置 FFmpeg 二进制不是因为懒而是为了锁版本。系统里的 FFmpeg 可能被 yum/apt 更新过可能带了不同的编解码库也可能压根没编进 libx264。程序内置一份行为就完全可预期。这里要提醒一个许可证细节FFmpeg 的 GPL 版和 LGPL 版能力差别很大。GPL 版通常带 libx264、libx265 这些编码器而 LGPL 版只带原生编码器你可能连libx264encoder 都找不到。自己用 MSVC 编译 FFmpeg 时会更容易踩这些坑因为 Windows 下缺少 pkg-config 配置漏了库也没提示编出来的二进制黑匣子一样。所以我的原则是这套流媒体程序里带的 FFmpeg 能用就不动确实要换再换同类型的社区构建别自己从零编译。2.4 前端这一侧怎么对接如果你做的是 Vue 网页播放器脑子里不要只想着“RTMP 播放器”这个关键词。浏览器不会给你 RTMP 原生能力Vue 里的“RTMP 播放器”组件本质上是帮你封装了 flv.js 或 websocket-flv 的壳。后端输出 HTTP-FLV前端用 flv.js 解析这是延迟和兼容性平衡最好的做法。HLS 则更简单新版 Safari 原生播放Chrome/Firefox 用 hls.js。带 MSE 的原因就在于 hls.js 要把 TS 分片转成 fMP4这个过程必须通过 MSE 接口灌进 video 标签。WebRTC 输出模式一般由流媒体网关自己生成 SDP前端拿到 SDP 填到RTCPeerConnection里就行不需要你自己处理音视频包。3. 从 zip 到跑通解压即用的最小启动与参数核对3.1 拿到包以后先看这三样东西标题是 zip 包落地第一步就是把包解开看目录结构。虽然不同项目文件组织不一样但这类软件基本逃不出三块可执行文件、配置目录、内置网页。我一般会先确认可执行文件有权限、配置文件格式是 json/yaml/toml以及 www 目录下有没有自带播放器测试页。# 解压进入目录后先做最小检查 cd /opt/camera-streamer ls -la # 观察目录结构别急着运行 # 预期看到 bin/ 或 server、config/、web/ 或 www/ 这样的目录 file bin/* # 再看主程序是否带版本和帮助参数 ./bin/server --help这段操作的逻辑是先搞清楚包里有什么再决定怎么改。file bin/*能告诉你这是 ELF 可执行文件、Windows PE 还是脚本避免在 Linux 上拿到 Windows 版二进制就硬跑。--help通常能列出支持的协议、配置文件路径和默认端口比翻文档快。很多这种 zip 包解压后会有个默认配置能直接跑起来但默认端口有可能是 8080、1935、8554 这些常用端口先和本机已有服务核对一下避免端口冲突。这一步省不了我已经不止一次遇到包内置的 RTSP 服务默认端口和监控平台冲突的情况。3.2 先用一条 ffprobe 探活 RTSP 源改配置之前先把源本身验证一遍。RTSP 源探活我从来不用 VLC 拖拽看而是用 ffprobe 拿结构化信息。这样能看到编码、分辨率、帧率还能确认地址是否真的通。# 用 TCP 拉流探活TCP 比 UDP 稳能避免丢包花屏 ffprobe -rtsp_transport tcp -v error \ -show_entries streamindex,codec_name,width,height,avg_frame_rate \ -show_format -of json \ rtsp://user:pass192.168.1.64:554/Streaming/Channels/101这里要说明两点。第一-rtsp_transport tcp是探活 RTSP 的首选UDP 虽然在局域网延迟低但在弱网环境丢包后画面会碎裂TCP 至少能保证数据完整。第二地址后半截/Streaming/Channels/101是海康摄像头的典型路径101表示第一路主码流102是第一路子码流。主码流通常分辨率高、码率高适合录像子码流分辨率低、码率低适合网页监看和算法分析。很多教程给的 RTSP 测试流、RTMP 测试地址、HLS 测试流地址都在公网上稳定性和编码格式参差不齐我建议你局域网里先拿真实摄像头打通公网测试流只用来做协议兼容性验证。如果 ffprobe 报 401是鉴权问题报 404是路径不对报 timeout多半是网络不通或摄像头主动断了 TCP。这些错误不能靠猜先改传输协议再查账号权限最后换子码流试试。这一步是整个链路里最值得花时间的。3.3 在主配置里写一路源同时开多协议输出源验证通过后把这一路配置写进程序的主配置。下面是一份高度概括的配置示例具体字段每个程序略有差异但逻辑一致{ sources: { gate_live: { type: rtsp, url: rtsp://user:pass192.168.1.64:554/Streaming/Channels/101, transport: tcp, auto_reconnect: true } }, outputs: { hls: { enabled: true, segment_duration: 2, list_size: 6 }, http-flv: { enabled: true }, webrtc: { enabled: true, udp_port_range: 56000-56100 } } }这份配置里值得解释的参数有三个。transport: tcp会直接影响源拉流是否稳定设成 udp 之后在公网很容易出现花屏和断流。auto_reconnect必须开摄像头断电重启或者网络抖动时程序能不能自动恢复就靠它。hls.list_size控制保留多少个切片如果设成 3播放器拖回放最多只能回看 6 秒设成 20延迟会变大但回看窗口更宽。启动命令一般很简单指定配置文件即可# 前台运行看日志 ./bin/server -c config/server.json # 确认监听了哪些端口 ss -lntup | grep server启动后重点看三件事日志里 RTSP 源是否显示 connected、HLS 切片是否在生成、WebRTC 的 UDP 端口是否真的被程序绑定。如果 HLS 切片没生成多半是源编码格式不支持封装如果 WebRTC 端口没监听说明配置没加载成功。3.4 浏览器验证三件事最后打开内置测试页分别验证 HLS、HTTP-FLV、WebRTC 三条路径。不要省这一步命令行日志只能证明流在服务端内部通了证明不了浏览器能播。验证时注意HLS 地址通常是http://ip:port/live/gate.m3u8HTTP-FLV 是.flv结尾WebRTC 需要通过wss或页面 API 获取 SDP。如果在局域网用 http 访问 WebRTC 页面Chrome 会拦摄像头权限但播放不受影响公网部署则必须配 HTTPS否则 WebRTC 在某些浏览器里直接不可用。4. 换一个输出就是换一张 FFmpeg 脸HLS、MSE、MP4、MJPEG 实测参数如果这个程序内置了 FFmpeg那么它界面上所有“输出模式”最终都会翻译成一条条 ffmpeg 命令行。看懂这些参数你就能预判程序在干什么也能在它翻车时手动拿 ffmpeg 验证到底是谁的问题。4.1 RTSP 到 HLS分片时长、列表长度与 GOP 对齐HLS 的原理是把一段连续视频切成很多小文件再用 m3u8 索引文件告诉播放器按顺序拉取。切片时长直接决定起播速度和延迟。这里给一条最小可用的直播级切片命令# -c copy 不做转码前提是源编码能被 TS 容器接受 ffmpeg -rtsp_transport tcp -i rtsp://user:pass192.168.1.64:554/Streaming/Channels/102 \ -c copy \ -f hls \ -hls_time 2 \ -hls_list_size 6 \ -hls_flags delete_segments \ /var/www/live/gate/index.m3u8参数含义逐一说清楚-hls_time 2是每个切片 2 秒切片越短起播越快但会产生大量小文件磁盘 io 压力也大-hls_list_size 6是 m3u8 列表里最多保留 6 个切片也就是 12 秒左右的回看窗口直播场景必须开delete_segments删除过期切片否则磁盘会被堆满。这里必须提 GOP 对齐。H.264 的视频帧序列由 I 帧、P 帧、B 帧构成播放器要等第一个 I 帧才能起播。如果源摄像头的 GOP 是 4 秒你切片设 2 秒那么有约一半的切片里没有 I 帧播放器要么黑屏等待要么花屏。所以切片时长至少要大于等于源 GOP 长度。这个坑我踩过后来养成了先ffprobe查 GOP 间隔再定-hls_time的习惯。如果是公网带宽紧张需要顺带降低码率那就不能-c copy而是加一路转码用 CRF 和 maxrate 双控ffmpeg -rtsp_transport tcp -i rtsp://user:pass192.168.1.64:554/Streaming/Channels/101 \ -c:v libx264 -preset veryfast -tune zerolatency \ -crf 23 -b:v 800k -maxrate 1000k -bufsize 2000k \ -c:a aac -b:a 128k \ -f hls -hls_time 2 -hls_list_size 6 -hls_flags delete_segments \ /var/www/live/gate/index.m3u8-crf 23控制画质恒定-b:v 800k给一个平均码率目标-maxrate 1000k限制峰值避免带宽波动造成卡顿。注意-tune zerolatency在这里的作用是让编码器降低缓存帧数对追求低延迟的直播非常关键。这个组合也是“ffmpeg 降低码率”这个需求最常用的答案。4.2 HTTP-FLV 与 MSEfMP4的参数差异HTTP-FLV 是低延迟网页直播的主力。它本质上是把 FLV 封装的数据包通过 HTTP 分块传输给前端flv.js 在浏览器里解析。命令核心是# 从 RTSP 拉到本地原编码封装成 FLV 推到 RTMP 服务器 ffmpeg -rtsp_transport tcp -i rtsp://user:pass192.168.1.64:554/Streaming/Channels/102 \ -c copy \ -f flv \ rtmp://127.0.0.1:1935/live/gate注意这里你看到的是rtmp://说明中间承转还需要一个支持 RTMP 接入的服务比如 nginx-rtmp 或其他流媒体服务再由它输出 HTTP-FLV。如果这个 zip 程序自带 RTMP 与 HTTP-FLV 能力那它内部做的就是这一步。为什么不直接用 ffmpeg 输出 HTTP-FLV 给网页因为 ffmpeg 不适合长期作为 HTTP 服务运行它推完一路就退出了必须有常驻服务接管。MSE 对应的则是片段化 MP4也就是 fMP4。hls.js 在较新的浏览器里优先请求 fMP4因为 MP4 的元数据可以直接喂给 MSE不需要先转 TSffmpeg -rtsp_transport tcp -i rtsp://user:pass192.168.1.64:554/Streaming/Channels/102 \ -an -c:v copy \ -movflags frag_keyframeempty_moovdefault_base_moof \ -f mp4 \ http://127.0.0.1:8080/gate.mp4frag_keyframe表示在每个关键帧位置切分片段empty_moov表示把 moov 元数据前置让播放器不用等到整个文件下载完就能开始解码。default_base_moof是为了解决部分浏览器对 MP4 片段偏移量的兼容性问题。前端如果你用的是 Vue Rtmp 播放器之类的组件老版本组件的底层可能还依赖 Flash新版本多半是 flv.js。我的建议是直接换成 flv.js 封装后端输出 HTTP-FLV延迟能做到一到三秒比依赖 RTMP 地址靠谱得多。4.3 MP4 点播录像与 MJPEG 低端适配以及硬件加速选型监控回放场景需要 MP4 点播文件。录制回放和直播切片的区别在于回放文件必须能被 seek不能像直播切片那样只留 6 个文件所以faststart参数优先# 录 5 分钟源编码直接封装成可点播的 MP4 ffmpeg -rtsp_transport tcp -i rtsp://user:pass192.168.1.64:554/Streaming/Channels/101 \ -t 300 -c copy \ -movflags faststart \ /data/recordings/daily_20250101.mp4faststart会把 moov 原子从文件尾部移到头部这样网页播放器不用等整个文件下载完加载几秒就能拖进度条。如果后接剪辑服务这个文件形态也最友好。MJPEG 是一帧一帧的 JPEG 图片流每个浏览器都能直接显示不需要任何播放器库。它适合嵌入式老页面、低端设备面板、OpenCV 直接抓帧ffmpeg -rtsp_transport tcp -i rtsp://user:pass192.168.1.64:554/Streaming/Channels/102 \ -c:v mjpeg -q:v 4 -an \ -f mpjpeg \ http://127.0.0.1:8080/gate.mjpeg-q:v 4是 MJPEG 画质范围 2 到 31数值越小画质越好。MJPEG 的缺点也明显带宽消耗极大一帧 1080p JPEG 能到 200KB 以上所以只适合子码流或低分辨率源。硬件加速这块如果你在 Windows 上跑会看到d3d11va和dxva2两个选项。dxva2 是老接口Win7 时代常见兼容性还行但新特性少d3d11va 是 Direct3D 11 的硬件解码接口配合-hwaccel_output_format d3d11可以做到 GPU 零拷贝转码效率更高。实际使用中驱动不对会导致解码失败日志里出现hardware device failed。我的经验是先用软件解码跑通再切硬件加速不要一上来就-hwaccel不然你分不清是源的问题还是显卡驱动的问题。HomeKit 这块我提一句标题里带 HomeKit 意味着它可能支持把普通摄像头桥接给苹果家庭 App。但 HomeKit Secure Video 需要经过苹果的 MFi 认证与加密通道不是随便一个 ffmpeg 命令能搞定的。实际集成时先确认文档里 HomeKit 是完整实现还是仅做“局域网发现”否则你会在 Home App 里看到设备但始终拉不出画面。5. 接入避坑RTSP 主码流子码流、延迟、WebRTC 打不开的排查清单5.1 现象海康/大华 RTSP 地址填进去就是黑屏现象很直接配置没问题日志显示 connected但网页黑屏或一直在加载。原因大概率有两个。第一个是主码流是 H.265浏览器侧的 HLS 或 MSE 对 HEVC 支持支离破碎Safari 能播Chrome 要么黑屏要么只有声音。第二个是路径写错海康旧文档里常见/h264/ch1/main/av_stream而新固件统一走/Streaming/Channels/101两者可能都能连但返回的编码不同。解决先用 ffprobe 确认codec_name如果是hevc拉流地址换102子码流子码流通常还是 H.264或者直接开转码。路径统一按/Streaming/Channels/101和/Streaming/Channels/102试一遍101 是主码流102 是子码流。这个坑几乎每个海康接入项目都会踩一次属于必查项。5.2 现象ffmpeg 推流到流媒体服务延迟越来越高现象刚开始延迟 1 秒运行半小时后延迟涨到 5 秒、10 秒画面和声音越来越不同步。原因播放器拉流速度跟不上推流速度或者服务端缓冲堆积。常见元凶有三个推流端用了默认 GOP 过大导致播放器要等多年关键帧才能起播音视频时间戳没对齐播放器缓存越来越大传输用了 UDP 导致丢包重传积累。解决推流命令加-fflags nobuffer -flags low_delay -tune zerolatency编码端把-g设成帧率的整数倍比如 25fps 就设-g 25并加-bf 0去掉 B 帧降低解码延迟。如果从 FFmpeg 推 RTMP 到流媒体服务还要加-flvflags no_duration_filesize否则部分服务端解析 FLV duration 错误会拖长缓存。这套组合下来延迟能控制在一秒量级。5.3 现象WebRTC 页面连不上黑屏转圈现象localhost 打开测试页能出画面换成局域网 IP 访问就黑屏或者公网部署后始终 connecting。原因WebRTC 的媒体流走 UDP服务端只监听了内网端口浏览器协商出的 ICE candidate 只有内网地址跨网段根本不通。再一个常见原因是页面用的 http 而服务端要求 httpsChrome 对 WebRTC 的安全策略很严。解决先看 WebRTC 日志或 SDP 里的 candidate 类型。如果只有host类型说明没配好外网/中继地址如果 UDP 端口在防火墙里没放通SDP 看起来正常但媒体就是不通。常见做法是显式配置 UDP 端口范围并加入内网 IP 作为 ICE host candidate。排查时我一般会先抓一下服务端日志看有没有收到浏览器的 STUN 请求。另外提一下资源释放页面销毁时必须调用播放器的close()或pc.close()显式关掉 WebRTC 连接否则浏览器会持有一段时间的 UDP 端口服务端以为客户端还在继续推流导致后台日志里全是僵尸连接。这也是“WebRTC 怎么关闭”这个关键词背后真正的需求。5.4 现象安卓端缓存 RTSP 流后回放花屏现象安卓 App 把 RTSP 流缓存到本地网络波动后播放缓存文件画面出现花屏、马赛克拖进度条卡死。原因很多播放器的“缓存 RTSP 流”并不是按帧边界切分文件而是把 RTP 裸流直接落盘。一旦某个包丢失或者线程退出没写完整文件头信息和帧索引就对不上播放器解码时会把错误数据当成视频帧黑匣子一样乱解。解决不要在端侧缓存 RTSP 裸流这是播放器最容易翻车的地方。正确做法是服务端先把 RTSP 转成 HLS 或分段 MP4让播放器缓存的是正常的媒体文件缓存完其实和点播回放没区别。如果一定要缓存裸流就得用 FFmpeg 重编码成mpegts并做好-f segment分片宁可多花一点 CPU也不要省这一步。这条属于踩出来的血泪经验。5.5 现象Windows 下 FFmpeg 报 unknown encoder libx264现象命令写好了跑的时候直接报Unknown encoder libx264或者硬件加速设置后报Device setup failed。原因你下载的 FFmpeg 构建版是 LGPL 协议版本不带 libx264/libx265 这种 GPL 编码器。还有一个常见情况是自己用 MSVC 编译 FFmpeg 时依赖没配全编出来的程序只有原生解码器连 H.264 都只能解不能编。至于 d3d11va 和 dxva2 选错多半是显卡驱动太老或 ffmpeg 版本太新导致接口不兼容。解决直接换成 GPL 版社区构建确认ffmpeg -encoders | grep libx264有输出。硬件加速先把-hwaccel dxva2 -hwaccel_output_format d3d11和d3d11va分别试哪个能出画面用哪个。别在编译 FFmpeg 上死磕Windows 下自己编译 FFmpeg 纯属浪费时间尤其是还要带 libx265、libvpx 这些外部库时除非你有明确的定制需求否则社区构建够用。6. 进阶验证用 ffprobe 和 curl 把整条链路钉死6.1 用 ffprobe 回头看源流的真实参数部署完成不是结束验证链路才是。我最常用的检查方式不是打开页面看有没有画面而是拿 ffprobe 和 curl 对每个输出回验。# 验证 HLS 输出每个分片的帧结构 ffprobe -v error -select_streams v:0 \ -show_entries packetflags,duration \ -of csv http://127.0.0.1:8080/live/gate/index.m3u8这条命令会列出视频包的标记K开头表示关键帧。如果发现关键帧间隔大于 HLS 切片时长说明 GOP 没对齐播放器起播会慢。需要逐帧导出验证时可以用select过滤器单独导出 I 帧# 导出所有 I 帧为 jpg直观确认 GOP 间隔 ffmpeg -i input.m3u8 -vf selecteq(pict_type,PICT_TYPE_I) -vsync vfr frames/frame_%03d.jpg如果导出帧的序号间隔过大回来改摄像头的 GOP 设置比在服务端硬调切片参数更有效。6.2 用 curl 验证 HLS 切片正在更新# 连续抓两次 m3u8对比切片文件名是否滚动 curl -s http://127.0.0.1:8080/live/gate/index.m3u8 # 隔 5 秒再抓一次如果列表末尾文件名没变说明切片卡住 sleep 5 curl -s http://127.0.0.1:8080/live/gate/index.m3u8不推荐用浏览器缓存强制刷新来验证curl 能看到最原始的响应。如果第二次抓取后列表没滚动先说源有没有断再看输出目录的写入权限最后看磁盘是不是被旧切片堆满了。这一步做一次能排除一大半“明明是直播但画面一直卡死”的问题。6.3 把整体延迟压到 1 秒内的三件套真正要上低延迟监控输出侧不要选 HLS 硬扛这是前提。三件套是源侧 RTSP 走 TCP、输出侧选 HTTP-FLV 或 WebRTC、编码侧开zerolatency并限制 GOP。这三个动作分别解决了数据稳定、协议延迟和解码等待问题。WebRTC 是这里面最吃配置的但设置得当延迟能做到 300 毫秒级别网页原生支持不用任何播放器库。我自己现在的习惯是拿到新摄像头第一件事不是开播放页面而是先 ffprobe 主码流和子码流的编码、帧率、GOP把这些参数记在配置文件的注释里再决定哪路进网页、哪路进 YOLO。这个习惯帮我避开了一堆黑屏和花屏的坑。整套流程跑通一次以后换摄像头、换协议、加点位都只是改配置的体力活真正值得花时间的是把源头参数摸清。希望帮到你。本文还有配套的精品资源点击获取