HTML5原生不支持RTSP，所谓“兼容”实为依赖WebSocket代理、WebRTC网关或MSE解析层；Chrome 23+、Firefox 42+、Edge 13+可用，Safari和iOS Safari因无MSE及WebSocket二进制限制而不可用。
HTML5 原生不支持 RTSP，所有“支持”都依赖代理或转协议
浏览器的 标签从没原生实现过 RTSP 协议解析。所谓“兼容浏览器”，实际是指：在搭配 WebSocket 代理（如 ws_rtsp）、WebRTC 网关或 MSE 解析层后，哪些浏览器能跑通整套链路。真正起作用的是 JS 库 + 后端服务，不是浏览器本身。
Chrome / Firefox / Edge 可靠运行，但需注意版本底线
主流现代浏览器中，Chrome 23+、Firefox 42+、Edge 13+ 是公认可用的组合——前提是使用 streamedian/html5_rtsp_player 或类似基于 MediaSource Extensions 的方案。它们支持 WebSocket 和 SourceBuffer.appendBuffer()，这是 MSE 方案的硬性门槛。
-
Safari 8+（macOS）理论上支持，但实际常因 WebSocket 缓冲策略或 H.264 Annex B 解析失败卡住，尤其在非libx264编码的 IPC 流上 -
Android Browser 5.0+能跑，但部分旧版 WebView（如 Android 6.0 内置）缺少MediaSource.isTypeSupported('video/mp4; codecs="avc1.42E01E"')返回true，导致初始化直接退出 -
IE 11 / IE Mobile仅靠 ES5 转译版勉强加载，但 MSE 不可用，必须降级走 Flash 或 ActiveX——这两者现在基本不可用
iOS Safari 和新版 Edge（Chromium 内核除外）明确不支持
iOS Safari 从不支持 MSE，也禁用 WebSocket 二进制接收（binaryType = 'arraybuffer' 无效），所有基于 WebSocket + MSE 的 RTSP 播放器在 iPhone/iPad 上必然白屏或报 InvalidStateError: Failed to execute 'appendBuffer' on 'SourceBuffer'。没有绕过办法，只能换协议（如转 HLS）或换终端。
- Chromium 内核的
Edge属于“可用”范围，但旧版EdgeHTML（v18 及以前）和Opera对remuxer时间戳对齐逻辑支持不稳，容易音画不同步 - 即使浏览器列表里写了“支持”，若后端代理未正确剥离 RTP 头、未注入 SPS/PPS、未按 NALU 边界切分，前端照样崩溃——兼容性是端到端的事，不是只看浏览器型号
别只查浏览器列表，先确认你的流是否被正确解封装
很多项目卡在“Chrome 能播，Firefox 播不了”，最后发现是 FFmpeg 推流时用了 -vcodec libx265，而播放器 JS 只认 H.264；或者 RTSP 流带了 Digest 认证，但前端没传 authCallback 函数，代理直接 401 后静默断连。
立即学习“前端免费学习笔记（深入）”；
- 用
ffplay -v debug rtsp://...验证原始流能否解出 H.264 帧 - 用 Chrome DevTools 的
Network → WS面板看 WebSocket 是否持续收包、payload 是否含00 00 00 01起始码 - 检查播放器初始化时传的
socket地址是否可跨域访问（ws://不能跨域，wss://才行）
浏览器兼容性只是拼图一角；流格式、认证方式、传输层健壮性、时间戳精度，缺一不可。漏掉任意一个，写再多 if (isChrome) {...} 都没用。
