HTML5原生不支持RTSP协议，因浏览器无RTSP解析器和UDP权限，需通过服务器转为HLS、FLV或WebRTC等Web友好格式；常见方案包括FFmpeg转HLS、nginx-rtmp-module、SRS或WebRTC方案，部署时需注意延迟、跨域、HTTPS混合内容及ffmpeg参数调优。
HTML5 原生不支持 RTSP，直接用 标签播放 rtsp:// 地址必然失败——这不是浏览器兼容性问题，而是协议层根本缺失。
为什么 HTML5 无法直接播 RTSP
RTSP 是控制协议（常搭配 RTP 传输音视频），而 HTML5 只支持基于 HTTP 的流协议，如 MP4（HTTP Range）、HLS（.m3u8）、MPEG-DASH（.mpd）。浏览器没有内置 RTSP 解析器和 RTP 组包逻辑，也无权限直接发起 UDP 连接（RTSP 默认依赖 UDP 传媒体数据）。
必须通过服务器转协议：核心是“RTSP → Web 友好格式”
所谓“推流服务”，本质是部署一个中间服务，从摄像头或设备拉取 RTSP 流，解码/转封装为浏览器能播的格式。常见方案有：
- 用
FFmpeg拉流 + 推 HLS：ffmpeg -i rtsp://... -c:v libx264 -c:a aac -f hls -hls_time 2 -hls_list_size 5 stream.m3u8，前端用 - 用
nginx-rtmp-module：接收 RTSP（需配合ffmpeg推送）或直接拉 RTSP，再以 HLS 或 FLV（配合flv.js）输出 - 用专业流媒体服务器如
EasyNVR、SRS、WebRTC-based方案（如mediasoup+ffmpeg转 WebRTC）：更适合低延迟场景
注意：rtsp-simple-server 本身不转协议，只做 RTSP 转发，仍不能被 HTML5 直播；必须搭配转封装或转 WebRTC 的环节。
立即学习“前端免费学习笔记（深入）”；
常见踩坑点：延迟、跨域、HTTPS 混合内容
实际部署时高频出问题的地方：
- HLS 延迟通常 10–30 秒，
hls_time设太小（如 1s）会导致切片过多、加载失败；设太大则卡顿明显 - 前端页面是
https://，但生成的.m3u8或.ts地址是http://，浏览器会拦截混合内容——所有资源必须同协议（推荐全站 HTTPS + 证书有效） - 某些 IPC 厂家 RTSP URL 含特殊字符（如空格、中文、
@），未encodeURIComponent就传给ffmpeg会导致拉流失败 - 用
flv.js播放 FLV 流时，后端必须开启 HTTP long-polling 或 WebSocket 支持，且 FLV header 时间戳要连续，否则花屏或卡死
真正难的不是“有没有服务器”，而是选型时得明确：要低延迟就绕不开 WebRTC 转封装（复杂度高）；要简单稳定就选 HLS（但得接受延迟）；而任何方案里，ffmpeg 参数调优、时间戳对齐、GOP 对齐、跨域头（Access-Control-Allow-Origin）和 HTTPS 证书配置，才是压垮调试进度的关键细节。
