HTML5不支持RTSP协议，必须通过服务端转协议（如HLS、WebRTC、WebSocket+MSE），且页面须运行在HTTPS或localhost安全上下文中；所有资源（.m3u8、.ts、wss）均需HTTPS/WSS，CORS与证书链配置也必须合规。
HTML5 本身不支持 RTSP，跟 HTTPS 无关
浏览器原生的 <video> 标签根本不认识 rtsp:// 协议，无论页面是 http:// 还是 https://，直接写 src="rtsp://..." 都会静默失败（控制台可能只报“Media resource failed to load”或无提示）。这不是 HTTPS 限制导致的，是协议层缺失——HTML5 规范里就没定义 RTSP 支持。
想在网页播 RTSP，必须转协议，HTTPS 是强制前提
现代浏览器（Chrome、Edge、Firefox）要求所有涉及摄像头、麦克风、WebRTC 或 MediaSource 的能力，必须运行在安全上下文（secure context）中。这意味着：即使你用 WebSocket + WebAssembly 解码 RTSP 流，再喂给 MediaSource，页面也必须通过 https:// 或 localhost 访问，否则 MediaSource 初始化会直接抛 DOMException: The operation is insecure。
- 自签名证书在开发环境可用，但需手动信任，否则浏览器拦截连接
- HTTP 页面哪怕加了
localhost代理，只要地址栏显示http://，MediaSource和RTCPeerConnection均不可用 - 某些嵌入式 Webview（如 Electron、Qt WebEngine）可绕过此限制，但标准浏览器不行
常见 RTSP 转 Web 可行路径及 HTTPS 注意点
主流方案是服务端将 RTSP 转成浏览器能播的格式，再由前端加载。关键不是“怎么播”，而是“谁转、怎么传、是否加密”：
-
RTSP → HLS（.m3u8）：需服务端拉流并切片；HLS 播放器（如hls.js）依赖fetch加载分片，所有.ts和.m3u8资源必须走 HTTPS，否则被混合内容（mixed-content）策略阻止 -
RTSP → WebRTC（via SFU/MCU）：信令和媒体流均需 TLS 加密；STUN/TURN 服务器地址必须是turn:xxx?transport=tcp或turns:（带 s），纯 UDP 的turn:在 HTTPS 页面下大概率失败 -
RTSP → WebSocket + MSE：服务端用 FFmpeg 解码推裸 H.264 Annex-B 帧到 WebSocket；前端用MediaSource+SourceBuffer组帧；WebSocket 地址必须是wss://，ws://会被浏览器拒绝连接
容易被忽略的安全细节
很多开发者以为配好 HTTPS 就万事大吉，实际还有几处硬性卡点：
立即学习“前端免费学习笔记（深入）”；
- CORS 头必须显式允许：后端返回的
.m3u8、.ts、wss响应头里要有Access-Control-Allow-Origin: https://yourdomain.com（不能是*，因为涉及凭证） - 证书链要完整：Nginx/Apache 必须配置
fullchain.pem而非仅cert.pem，否则 iOS Safari 和部分 Android WebView 会握手失败 - RTSP 拉流端口本身不用 HTTPS，但服务端代理 RTSP 的组件（如 GStreamer、Node-Media-Server）若暴露在公网，其管理接口（如
/control）必须禁用或加 Auth，否则等于白送摄像头控制权
真正卡住项目的往往不是编解码逻辑，而是证书链断裂、CORS 缺失、或者误把 ws:// 当 wss:// 用。先确认浏览器地址栏锁图标亮起，再查控制台 Network 标签页里每个请求的状态码和协议头。
