HTML5原生不支持RTSP，需服务端转封装为HLS或WebRTC等浏览器兼容格式；WebSocket仅作控制指令传输或低延迟帧传递通道，并非必需，也不处理解码、时间戳等媒体逻辑。
HTML5 原生不支持 RTSP，必须转封装
浏览器从没原生实现过 rtsp:// 协议， 标签只认 MP4、WebM、HLS、DASH 这类 HTTP 流。RTSP 是基于 TCP/UDP 的会话控制协议，带 SETUP/PLAY/TEARDOWN 等交互，浏览器内核根本不会解析它。
所以所谓“HTML5 播 RTSP”，本质是：用服务端（或边缘网关）把 RTSP 流拉下来，实时转成浏览器能吃的格式——最常用的是 HLS（.m3u8+.ts）或 WebRTC（offer/answer 信令 + SRTP 媒体），WebSocket 只是其中一种传输通道选择，不是必需品。
WebSocket 在 RTSP 转发链路中起什么作用？
WebSocket 不负责解码或转协议，它只是个双向、低延迟的文本/二进制管道。常见用法有两类：
-
传控制指令：前端通过
WebSocket向后端发start/stop，触发 FFmpeg 拉流、转 HLS 或 WebRTC 推流，避免轮询 HTTP -
传原始帧数据（少见）：服务端把 H.264 Annex-B NALU 或 WebRTC 的
EncodedVideoChunk封装成二进制消息，用WebSocket推给前端，再用MediaSource Extensions (MSE)拼接播放——这需要前端完整实现解码逻辑，开发成本高、兼容性差，仅用于极低延迟定制场景
注意：WebSocket 本身不理解视频，也不处理时间戳、关键帧对齐、丢包重传——这些全靠上层协议或服务端补足。
立即学习“前端免费学习笔记（深入）”；
为什么很多人误以为“必须 WebSocket”？
因为几个典型开源方案默认用了它，造成路径依赖：
-
node-rtsp-stream+hls-server：实际走 HTTP 提供.m3u8，但控制面板用WebSocket切换摄像头，让人混淆了“控制面”和“媒体面” -
Janus Gateway或Medooze：用WebSocket传 WebRTC 信令（offer/answer），媒体走UDP，但前端 JS 里new WebSocket()太显眼，被当成“播流入口” - 某些国产 SDK 把
WebSocket封装成“RTSP 播放器”API，内部偷偷做了转码+推流，开发者没看到服务端逻辑，就以为协议绑定死了
真正可选的媒体交付方式包括：HTTP(S)（HLS/DASH）、HTTPS + fetch（渐进式 MP4）、WebRTC over UDP（最佳延迟）、甚至 HTTP/2 Server Push（小众）——WebSocket 只是其中之一，且不是最主流的媒体传输方式。
实际部署时最容易卡在哪？
问题往往不出在前端代码，而在服务端链路断点：
- RTSP 源地址带空格或特殊字符（如
rtsp://192.168.1.100:554/Streaming/Channels/101?transportmode=unicast），没做encodeURIComponent，导致 FFmpeg 拉流失败，日志只报Connection refused - HLS 切片间隔设成
1s，但 RTSP 源关键帧间隔是5s，导致首屏黑几秒，或播放器反复 reload.m3u8 - 用
WebSocket传帧时忘了加binaryType = 'arraybuffer'，JS 收到乱码字符串，MSEappend 失败，控制台报Failed to execute 'appendBuffer' on 'SourceBuffer' - 没配 CORS：HLS 的
.ts文件跨域加载被拦截，但错误藏在 Network 面板里，控制台只显示net::ERR_FAILED
调试时先确认服务端是否真吐出了可用的 .m3u8（直接浏览器访问 URL 看内容），再查前端是否正确设置了 crossOrigin="anonymous" 和 preload="none"——很多“播不出”问题，根源在第一步就没拿到合法媒体描述文件。
