企业官网建设流程全解析

简介：这款插件面向需要在大华摄像头监控场景中实现浏览器实时预览的开发者与运维人员，解决Chrome最新版无法直接播放RTSP视频流的问题。资源包共2000个文件、约152.6MB，以js、ts等前端代码为主，辅以json配置、md说明文档，并包含Node.js安装程序、jQuery演示源码及可直接运行的插件demo，便于用户快速部署和二次开发。已有3117人学习下载。通过该包可以了解如何借助Node.js与jQuery打通Web页面和RTSP流，掌握Chrome最新版下播放大华摄像头画面的完整技术路径，同时还附带多种配置文件与脚本，适合具备一定Web基础、希望扩展监控系统前端能力的读者。 大华摄像头接入网页播放这事，这几年问的人一直不少。尤其是Chrome更新到新版以后，以前那套基于ActiveX或NPAPI的Web插件方案彻底失效，打开摄像头管理页面直接提示“插件不受支持”或者干脆白屏一块，很多做安防集成、运维监控、甚至只是想在办公室看个车间画面的朋友都被卡在这里。这篇就专门解决这个问题：在Chrome最新版里，怎么稳定、低延迟地把大华摄像头的RTSP视频流转到浏览器页面里播放。

先说结论，这条路是通的，但需要换个思路，不再依赖厂商那套专有插件，而是用一个轻量级网关把RTSP协议转成浏览器能直接消费的协议（WebRTC或者HTTP-FLV），前端页面用原生Web技术播放，顺带解决跨平台、免安装、自动刷新这些衍生需求。整个过程我实操验证过，下面把方案选型、核心配置、踩坑记录全部拆开讲。

1. 问题根源：浏览器和RTSP之间到底隔了什么

1.1 为什么Chrome不能直接打开RTSP地址

要明白为什么非要插件或者网关，得先理解RTSP本身的定位。RTSP是实时流传输协议，本质上是流媒体会话的控制协议，负责协商编码格式、传输端口、播放/暂停/停止这些控制指令，真正的视频数据往往通过RTP协议单独传输，通常走UDP端口，而且默认端口是554。

这里就出了两个层面问题：

第一，Chrome的地址栏对非HTTP(S)协议一律不认。你输入rtsp://192.168.1.64:554/...，Chrome只会把它当成一个未知协议去唤外部关联应用，而不会自己发起RTSP握手，这是浏览器内核的设计决策，短期内没有改变可能。

第二，WebRTC虽然支持音视频传输，但它是基于ICE/STUN/TURN的P2P框架，不直接面对RTP裸流，需要做SDP协商和编码转换，而RTSP流的编码通常是H.264/H.265，浏览器对H.265的支持本身就参差不齐。即便技术上可以用WebRTC直接订阅RTP，也需要一个信令服务器来桥接，这不是前端几行代码能搞定的事。

所以，所有“让浏览器播RTSP”的方案，本质都是“绕过”而非“突破”这些限制。绕过的方式有两大类：一类是转协议，另一类是转封装。

1.2 传统插件方案为什么被淘汰

早期海康、大华提供的Web插件，走的是NPAPI（如Chrome旧版支持）或者ActiveX（IE专属）路线。插件能直接访问本机网络层、解复用RTSP、甚至硬解码渲染，所以延迟可以做到极低，控制也灵活。但问题是：NPAPI在2015年前后被Chrome彻底弃用，ActiveX更是只活在IE里，这两条路都断了。

Chrome现在只认扩展（Extension），但扩展的能力边界被严格限制，不能直接创建TCP/UDP套接字、不能用自定义解码器渲染视频，所以指望Chrome商店里的某个插件来拉RTSP流，基本是死路。凡是号称“RTSP播放插件”的，多数是套壳方案，背后用WebSocket代理或者服务器转码，不是真正的插件能力。

这也是我建议别在“找插件”这个方向上投入太多精力的原因。

2. 方案选型：没有银弹，选最适合自己场景的那条路

现在的通用做法是搭建一个“流媒体网关”，核心思路：接收RTSP推流，统一转为浏览器可播放的格式，同时用HTTP接口给前端拉流。下面把主流的几条路线放在一起对比。

2.1 为什么我主推WebRTC方案

我这里优先推荐WebRTC网关方案，尤其是用Mediamtx（原RTSPtoWeb）这类现成网关来落地。原因有三个：

第一，延迟最可控。WebRTC走UDP传输，不做GOP缓存重传，端到端延迟可以压到500ms以内，监控场景下这个数值很关键。你看着画面里的人走过去，和真实动作几乎同步。

第二，前端零插件。WebRTC是浏览器原生能力，不需要安装任何扩展，也不需要额外引入大型播放器SDK，直接new RTCPeerConnection()就能接流。

第三，网关部署轻量。Mediamtx是Go写的单二进制文件，不依赖Java、不依赖Node，放到服务器上一条命令就能跑起来，配置也简单。

如果你不想用Mediamtx，备选还有ZLMediaKit（C++，功能最全）、SRS（国产开源，文档丰富）、GStreamer配合webrtcbin（折腾成本高一些），都可以实现同样的效果。但新手起步，Mediamtx是最不劝退的。

2.2 方案的边界和代价

也得说清楚方案的代价。WebRTC网关不是万能药，有两个明显的限制。

一是设备编码格式兼容性。如果摄像头输出了H.265编码，而网关没有硬件转码能力，下游浏览器大概率黑屏，因为Chrome对H.265的硬解支持很不稳定，尤其在Windows上依赖GPU驱动。这种情况下需要两招处理：一是摄像头端优先切换成H.264编码；二是网关层面开启转码，但转码很吃CPU，跑4路1080P基本要把一台4核服务器吃满。

二是多路并发时网关吞吐压力大。WebRTC的每路流都独占一条UDP通道，网关必须为每一路维护ICE状态和SRTP加密会话，所以并发20路以上时，建议网关单独部署，别和业务服务混跑。

3. 实操：用Mediamtx把大华RTSP流变成浏览器可播放的WebRTC流

3.1 环境准备和网关安装

我实际操作时的环境是这样的：

• 摄像头：大华IPC-HFW系列，RTSP端口554，主码流H.264，分辨率1080P
• 服务器：Ubuntu 20.04 LTS，2核4G，内网部署
• 浏览器：Chrome 117（最新版）

Mediamtx的安装非常简单，直接去GitHub Release页面下载对应平台的压缩包，解压后开箱即用。

# 下载mediamtx，这里以linux amd64为例 wget https://github.com/bluenviron/mediamtx/releases/download/v1.8.0/mediamtx_v1.8.0_linux_amd64.tar.gz tar -xzf mediamtx_v1.8.0_linux_amd64.tar.gz cd mediamtx_v1.8.0

解压后目录里有一个mediamtx可执行文件和一个mediamtx.yml配置文件。在修改配置前，先直接运行一次默认配置：

./mediamtx

默认会监听127.0.0.1:8554（RTSP入口）和127.0.0.1:8888（WebRTC over HTTP信令口）。看到类似这样的日志就说明启动成功了：

INF [RTSP] listener opened on :8554 INF [WebRTC] listener opened on :8888 (HTTP)

3.2 配置摄像头RTSP拉流地址

这一步是核心。Mediamtx支持两种方式把摄像头流转化为可访问的流，一种是“拉流代理”模式，网关主动从摄像头拉流；另一种是“推流模式”，摄像头主动推给网关。对大华摄像头，我更推荐用拉流代理模式，因为大部分摄像头不支持主动推流到自定义服务器。

打开mediamtx.yml，找到paths区段，内容类似这样：

paths: cam1: source: rtsp://admin:your_password@192.168.1.64:554/cam/realmonitor?channel=1&subtype=0

这里cam1是给这条流起的一个名字，前端访问时要用到。source就是大华摄像头的RTSP取流地址。

大华RTSP地址的常见格式是：

rtsp://用户名:密码@IP地址:端口/cam/realmonitor?channel=通道号&subtype=码流类型

• channel=1表示第一个通道
• subtype=0表示主码流，subtype=1表示子码流，副码流分辨率低但更流畅

调试阶段建议先用子码流，因为网络波动小、失败率低，等验证OK了再切成主码流。

如果摄像头启用了RTSP鉴权，Mediamtx会在拉流时自动完成认证，不需要额外配置。

提示：大华摄像头的默认RTSP端口是554，如果改了端口，source里的端口要同步改，否则拉流失败。另外，如果摄像头IP地址不在同一个网段，记得先把摄像头IP改到能互通的位置。

3.3 开启WebRTC拉流

默认配置下，Mediamtx的WebRTC已经启用了，但你还需要确认几个关键配置项：

webrtc: listenPort: 8189 localUDPPort: 8189 localTCPPort: 8188

• listenPort是HTTP信令监听端口，用于WebRTC协商（不是媒体端口）
• localUDPPort和localTCPPort是媒体数据端口，需要在防火墙里放行

如果你是在同一台服务器上部署网关和页面，那直接用127.0.0.1就行；如果前后端分离或页面部署在其他机器上，需要把webrtc的externalIP设置为服务器的内网/公网IP，否则浏览器拿不到可路由的ICE候选地址，会一直卡在“连接中”状态。

webrtc: externalIP: 192.168.1.100

3.4 前端页面接入播放

网关就绪后，前端接流就变得很纯粹。Mediamtx提供了一套标准的WebRTC播放JavaScript API，可以直接调用。

页面里核心逻辑是：向信令接口发一个POST请求，携带你要播放的流名，拿到SDP之后用WebRTC连接，再把媒体流设置到<video>标签上。

async function playStream(videoElement, streamName) { // 1. 向网关发送WebRTC start请求，获取SDP const response = await fetch(`http://192.168.1.100:8888/${streamName}/whep`, { method: 'POST', headers: { 'Content-Type': 'application/json' } }); const data = await response.json(); // 2. 创建RTCPeerConnection const pc = new RTCPeerConnection({ iceServers: [] }); // 3. 监听远程媒体流并关联到video标签 pc.ontrack = (event) => { videoElement.srcObject = event.streams[0]; }; // 4. 设置远程SDP描述 await pc.setRemoteDescription({ type: 'answer', sdp: data.sdp }); // 5. 发起本地ICE候选收集 await pc.setLocalDescription(await pc.createOffer()); } playStream(document.getElementById('camera'), 'cam1');

这里要注意一点：Mediamtx的WHEP接口是标准的，现在也支持简单的GET方式直接拿SDP，但POST方式更常见。具体请求路径和参数可以看Mediamtx官方文档里的WebRTC章节。

完成后，用Chrome打开这个页面，就能看到摄像头实时画面，延迟体感在几百毫秒以内，画面刷新也很跟手。

3.5 进阶：多通道、密码保护和自动重连

实际项目里往往不是单路摄像头，我这里再补充三个进阶配置。

多通道配置：在paths下继续加条目就行，每路一个名字一个source。

paths: cam1: source: rtsp://admin:password@192.168.1.64:554/cam/realmonitor?channel=1&subtype=0 cam2: source: rtsp://admin:password@192.168.1.65:554/cam/realmonitor?channel=1&subtype=0 cam3: source: rtsp://admin:password@192.168.1.66:554/cam/realmonitor?channel=1&subtype=0

密码保护：Mediamtx支持给play请求加访问控制，在配置里加：

paths: cam1: source: rtsp://admin:password@192.168.1.64:554/cam/realmonitor?channel=1&subtype=0 publishUser: internal_user publishPass: internal_pass readUser: viewer_user readPass: viewer_pass

这样前端拉流时需要用viewer_user和viewer_pass做基础认证，防止网关暴露后任意人拉流。

自动重连：如果摄像头重启或网络震荡导致流断开，Mediamtx默认会自动重建拉流连接，但前端页面需要监听WS连接状态，一旦断开主动重新调用playStream()。

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

4.1 摄像头IP地址怎么修改

这个问题出现频率非常高，因为在做项目调试时摄像头往往不是固定IP，或者和服务器不在同一个网段。大华摄像头改IP有两条常规路径：

路径一：通过浏览器登录摄像头Web管理页面，在“网络设置”里修改IP地址，前提是你能先访问到摄像头。路径二：下载大华的“ConfigTool”设备搜索工具，它可以扫描局域网内所有大华设备，选中设备后直接批量修改IP、网关、端口等信息，比网页操作更快。改完之后记得将摄像头和服务器的网络连通性测试一遍，ping不通就检查网线和VLAN划分。

如果摄像头是全新出厂的，默认IP通常是192.168.1.108，把电脑网卡手动设置成同网段的静态IP再访问。

4.2 Chrome提示“文件可能已被篡改”或“不受支持”

这个提示我在测试旧版的厂商插件时经常碰到。原因很简单：Chrome对下载的可执行文件有安全检查，旧版插件基于NPAPI或ActiveX，既不受支持，签名也可能过期，Chrome会直接拦截。这不是你的网络问题，也不是插件包坏了，而是浏览器安全策略不允许运行这类文件。

解决方向很清晰：别再碰那些老插件了。把播放链路整体迁移到WebRTC网关方案，浏览器端本身不再下载任何可执行文件，自然不会有这类拦截提示。

4.3 画面黑屏但文字控件正常

这种情况基本可以判定是视频编码格式和浏览器解码能力冲突。排查步骤：

1. 用VLC验证一下原始RTSP流是否能正常播放，确认流本身没坏
2. 在摄像头后台把主码流编码从H.265切换成H.264
3. 刷新页面看是否恢复

如果摄像头只支持H.265，而你又没法切换编码，那只能在网关层做转码。Mediamtx可以和FFmpeg联动，把H.265转成H.264输出到WebRTC，配置方法是在paths里给对应流加一个runOnDemand命令，用FFmpeg重新编码后再拉流。这需要安装FFmpeg并且配置相应的转码参数，具体命令示例：

ffmpeg -rtsp_transport tcp -i rtsp://admin:pass@192.168.1.64:554/cam/realmonitor?channel=1&subtype=0 -c:v libx264 -preset ultrafast -tune zerolatency -f rtsp rtsp://127.0.0.1:8554/transcode

4.4 多路播放时首个画面加载慢

如果同一个页面上同时播放多路摄像头，你会发现第一路出现画面的时间明显比后续几路慢。原因是WebRTC协商和ICE打洞需要时间，而首路要建立UDP通道，后续复用网络路径会快很多。

优化手段有三个：第一，页面加载后先预连接一个备用的WebRTC会话，把ICE状态提前热身；第二，把摄像头子码流作为首屏预览，点击放大后再切换到主码流；第三，网关所在服务器的UDP端口范围要放宽，避免同时多路时端口打满。我当时的配置是把Mediamtx的UDP端口范围直接设置成8189-8290，把上百个端口开放出来，问题迎刃而解。

4.5 摄像头RTSP流断流后无法自动恢复

这个问题容易出现。我排查过好几次，根因有两类：一类是摄像头本身的TCP keepalive超时机制，空闲一段时间后主动断开了RTSP会话；另一类是网关侧拉流线程卡死但没有自动重启。

针对这两类，我的做法是组合拳：

1. 在摄像头侧调整“TCP超时时间”和“RTSP keepalive周期”，尽量改短一些，让网关能感知到连接还活着
2. 在Mediamtx的paths里开启runOnDemand并配合重启脚本，如果流在拉取时报错，自动重启进程或者重新发起拉流

具体可以在Mediamtx的配置里加：

paths: cam1: source: rtsp://admin:your_password@192.168.1.64:554/cam/realmonitor?channel=1&subtype=0 runOnDemand: ffmpeg -rtsp_transport tcp -i $RTSP_URL -c copy -f rtsp rtsp://127.0.0.1:8554/backup runOnDemandRestart: yes

配合cron定时任务或supervisor守护进程，整条链路可以做到无人值守。

5. 工具选型解析：除了Mediamtx还有哪些选择

5.1 各方案横向对比

我在做这个项目之前也把市面上的开源方案都过了一遍，列个简短对比：

• Mediamtx：Go语言，单文件，部署最轻，WebRTC和HLS支持好，社区活跃，更新频率高，适合中小项目快速落地
• ZLMediaKit：C++，流媒体协议支持最全，支持GB28181、SRT、WebRTC，性能好，但配置项多，上手成本略高
• SRS 4/5：国产开源，文档友好，集群能力突出，适合做直播分发而不是简单的摄像头接入
• GStreamer自建webrtcbin管道：灵活度最高，但开发量也最大，非必要不建议碰

如果是个人项目或者小团队使用，Mediamtx是最合适的选择。如果企业内部有成熟的运维团队和定制需求，ZLMediaKit的二次开发空间更大。

5.2 WebRTC和HTTP-FLV怎么权衡

这里也补一个常用判断：如果你需要极低延迟且前端能容忍WebRTC的复杂性，选WebRTC；如果你更在意多端兼容、不需要实时对讲和控制，HTTP-FLV配合flv.js会更省心。flv.js的方案是把RTSP转成FLV后通过HTTP分发给浏览器，前端用MSE解码，整体实现更简单，而且在国内的实践案例也更多。

我当时实测过HTTP-FLV和WebRTC两种方案的对比，在良好的内网环境下，WebRTC延迟大约400ms，HTTP-FLV延迟稳定在1.2秒左右。如果只是看画面不操控云台，两者的体感差距不大；但如果要做远程操控、对讲联动，WebRTC是唯一能忍受的选项。

5.3 关于Chrome扩展这条路的补充

还有一个思路值得提一下：Chrome扩展可以做“代理”而不做“解码”。市面上有些RTSP播放扩展，其实是通过内置的chrome.socketsAPI建立TCP/UDP连接，再通过扩展自己的协议解析器和解码器渲染画面，但这个方案需要打包自己的编解码器，而Chrome扩展的权限和API对自定义解码器的支持非常有限，绝大多数这类扩展都只能播放MJPEG或者MP4封装，不能真正解码H.264裸流。

另外很多人不知道的是，Chrome扩展的权限列表里并没有“任意网络访问”这一项，即使通过host_permissions申请了，Chrome对扩展发起的WebSocket和TCP连接也有严格限制。所以别在扩展商店里找RTSP播放方案，这条路不靠谱，浪费的时间不如用来搭个网关。

6. 实操记录：一次完整的内网摄像头接入调试过程

写到这里，分享一次我实际调试的过程，方便大家对齐场景。

当时的项目背景是需要在工厂车间的大屏上实时显示6路大华摄像头的画面，要求无插件、无卡顿、延迟小于1秒，同时支持浏览器全屏展示。我用的方案就是Mediamtx + WebRTC。

第一步，我先用电脑的VLC播放器逐个验证摄像头的RTSP地址，排除了地址写错、密码错误的问题。这步很重要，别一上来就调网关，先确认源是好的。

第二步，在服务器上部署Mediamtx，配置六个paths，指向六路摄像头。每个摄像头的地址末尾的channel参数正确对应了物理通道。

第三步，用浏览器直接访问http://服务器IP:8888/流名，Mediamtx内置了简单的WebRTC播放页面，能直接出画面。这一步天然验证了网关是否正常工作。

第四步，按自己项目的前端框架写播放组件，把RTCPeerConnection逻辑包成一个控件。

第五步，处理并发问题。一开始同时播放六路1080P时，服务器CPU飙升到70%以上，我果断将部分不重要通道切到子码流，CPU降到20%以下，画面依然流畅。

整个调试过程大概花了大半天，最大的坑其实是防火墙没放行UDP端口导致WebRTC一直处于“连接中”，放行后就顺畅了。

7. 项目后续可扩展的三个方向

这个项目成功落地后，往往会有新的需求随之而来，这里给扩展方向留个备忘。

首先是录像回放的接入。WebRTC方案天然只处理实时流，回放需要另行对接NVR或者摄像头SDK，可以将按需回放的能力做成独立页面，通过时间参数拼接VLC能播放的RTSP带时间戳地址，或者走NVR的HTTP API。

其次是音频推送。标准做法是用WebRTC的addTrack加一路麦克风音频采集，再把音频数据推给网关，由网关混流后发给摄像头。这个链路比视频显示复杂，但对讲联动类项目又必不可少。

最后是移动端适配。Android手机上的Chrome和桌面Chrome对WebRTC的支持基本一致，iOS的Safari在较新版本也支持WebRTC了，所以同一套前端代码在手机浏览器上运行问题不大，顺手把页面做一下响应式适配就能覆盖移动监控需求。

我在实际配置里踩过一次比较深的坑，就是一开始直接把摄像头的管理端口（比如80或443）当成RTSP端口来写，结果拉流一直超时。后来才意识到RTSP有独立的554端口，这两个不要混用。另外，如果你在公网访问，记得给WebRTC的UDP端口段做端口转发，否则浏览器拿到的是内网ICE地址，外网完全不通。

本文还有配套的精品资源，点击获取