HTML5原生不支持RTSP协议，因RTSP是控制协议且依赖UDP传输，而浏览器禁用UDP套接字；仅支持HTTP-based流如HLS、DASH；所有“HTML5播RTSP”实为服务端转流（如HLS或WebRTC）后播放。
HTML5 原生不支持 RTSP 协议，浏览器无法直接播放 rtsp:// 地址，更谈不上原生投屏到电视 —— 这是根本限制，不是配置或代码能绕过的。
为什么 HTML5 不能直接播 RTSP
RTSP 是一个控制协议（类似遥控器），本身不传输音视频数据；实际媒体流通常走 RTP/UDP，而现代浏览器出于安全和架构原因，禁止 JavaScript 直接访问 UDP 套接字，也无法解析裸 RTP 包。HTML5 的 标签只接受 HTTP(S)-based 流媒体（如 MP4、WebM、HLS、DASH）。
- 所有声称“HTML5 播 RTSP”的方案，本质都是在服务端做了协议转换
- 浏览器里看到的永远是转成 HLS 或 WebRTC 后的地址，不是原始 RTSP
- 直接在前端用
ffmpeg.wasm解码 RTSP？目前不现实：wasm 版本不支持网络拉流（无 socket），且性能扛不住实时解码
可行路径：服务端转流 + 前端播标准格式
真正落地的方案必须依赖中间服务把 RTSP 转成浏览器友好的格式。常见组合：
-
HLS 方案：用
ffmpeg拉取 RTSP，切片生成.m3u8+.ts，前端用播放（需搭配hls.js） -
WebRTC 方案：用
Janus/Mediasoup/EasyRTC接入 RTSP 源，再以RTCPeerConnection推给前端 —— 延迟低（ -
MSE + WebSocket 自定义封装：服务端用
gstreamer或ffmpeg解码 RTSP，H.264 Annex-B 帧通过 WebSocket 推送，前端用MediaSource动态喂帧 —— 灵活但开发成本高
注意：ffplay -i rtsp://... 能播 ≠ 浏览器能播；本地能跑通不代表部署后可用（NAT、防火墙、UDP 被限都会断流）。
立即学习“前端免费学习笔记（深入）”；
投屏到电视的关键障碍
即使前端成功播放了转流后的视频，「投屏」仍不是点一下按钮就能完成的事：
- Chrome 的
Cast按钮只能投整个标签页或桌面，不能只投元素 —— 电视上会显示 UI 控件、地址栏等干扰内容 - 电视端若无对应 Web App（如自建的接收 WebRTC 的页面），仅靠 Miracast/AirPlay 协议无法解析你网页里的流地址
- 用
navigator.mediaDevices.getDisplayMedia()录屏再推流？延迟爆炸，且 iOS 完全不支持 - 真正可控的投屏 = 在电视上运行一个轻量接收端（比如用
WebView打开你的 HLS 页面，或接入你的 WebRTC Signaling Server）
最常被忽略的一点：RTSP 流的编码参数（如 H.264 profile、level、关键帧间隔）必须与目标播放环境匹配。例如，用 ffmpeg -vprofile baseline -level 3.0 输出，才能确保老旧电视或低端盒子上的 WebView 能解码；盲目套用 high profile 会导致黑屏无声。
