HTML5 video 标签原生不支持 RTSP 协议，须经流媒体服务器转封装为 HLS、MSE-HTTP-FLV 或 WebRTC；其中 HLS 兼容性最好但延迟高（10–30秒），flv.js 实现 MSE-HTTP-FLV 延迟中等（3–8秒），WebRTC 延迟最低。
Kenwood 电脑本身不是标准计算设备品牌（Kenwood 主营对讲机、车载音响、专业音频设备），所谓“Kenwood 电脑”极大概率是用户误指——实际可能是：运行 Windows 的工控机/嵌入式主机（贴了 Kenwood 标签）、Kenwood 车载信息终端（如 DMX907S 等带浏览器的型号），或混淆了 Kenwood 设备输出的 RTSP 流与播放端设备。
video.src 直接设为 rtsp:// 地址必然失败
HTML5 原生**完全不支持 RTSP 协议**，这是最常被忽略的根本限制。哪怕你在 Kenwood 设备 Web 界面看到“RTSP URL”，也不能直接丢进 video.src。
- 浏览器会静默失败，
video.error可能为MEDIA_ERR_SRC_NOT_SUPPORTED（错误码 4），但多数情况下连 error 事件都不触发 - Chrome、Edge、Firefox 均无例外；Safari 在 macOS/iOS 上同样不认
rtsp:// - 试图用
fetch()拉 RTSP 握手包会跨域失败，且协议本身不是 HTTP，无法走 Fetch API
必须经服务端转封装：RTSP → HLS / MSE-HTTP-FLV / WebRTC
真正可行的路径只有一条：在中间加一层流媒体服务器，把 Kenwood 设备输出的 RTSP 流（如 rtsp://192.168.1.100:554/stream1）转成浏览器能吃的格式。
-
HLS（.m3u8）：兼容性最好，几乎所有现代浏览器都支持，但延迟高（通常 10–30 秒）；需确保服务器输出的
.ts分片能被正确缓存和访问 -
MSE + HTTP-FLV：延迟中等（3–8 秒），需 JS 解析 FLV 并喂给
MediaSource；推荐用flv.js（Bilibili 开源），它不依赖 Flash，纯 HTML5 -
WebRTC：最低延迟（webrtc-streamer 或
EasyNVR）
Kenwood 设备常见 RTSP 地址格式与验证方式
先确认你拿到的是真实可用的 RTSP 流地址，而非网页上显示的“示例”或占位符。
立即学习“前端免费学习笔记（深入）”；
- 典型格式：
rtsp://admin:password@192.168.1.100:554/cam/realmonitor?channel=1&subtype=0（注意账号密码、端口、参数是否匹配设备手册） - 用 VLC 播放器测试：
媒体 → 打开网络串流 → 输入该 RTSP 地址；能播通，才说明流本身正常 - 若 VLC 也报错（如 “Your input can’t be opened”），问题出在设备侧：密码错误、RTSP 未启用、防火墙拦截、或设备根本不支持 RTSP（部分 Kenwood 车机仅支持 Miracast/AirPlay）
flv.js 最简接入示例（适合调试）
假设你已用 EasyNVR 或 nginx-rtmp 把 RTSP 转成了 HTTP-FLV 流（如 http://192.168.1.200:8000/live/cam1.flv），前端只需：
注意：flv.js 不支持 HTTPS 页面加载 HTTP FLV（混合内容被浏览器阻止），务必保证协议一致；若 Kenwood 设备在内网，播放页也需托管在同域或 HTTPS 下。
真正的难点不在写几行 JS，而在于选对转流方案并调通——很多用户卡在 EasyNVR 的 easynvr.xml 里没改对 1
exec_push 没启动 FFmpeg 拉流。别跳过服务端验证这步。
