HTML5原生不支持RTSP协议，video标签无法直接播放RTSP流；必须通过服务端转封装为WebRTC、HLS或HTTP-FLV等浏览器兼容格式，再由video标签承载并调用其原生全屏API。
HTML5 原生不支持 RTSP 协议，所以 标签无法直接播放 RTSP 流，更谈不上原生全屏。 所有“HTML5 播放 RTSP 并全屏”的方案，本质都是绕过浏览器限制，把 RTSP 转成浏览器能解码的格式（如 WebRTC、HLS 或 MSE-HTTP-FLV），再用标准 HTML5 元素承载——全屏能力来自 自身，而非 RTSP。
为什么
RTSP 是会话控制协议，不定义媒体封装格式，也不含传输层加密/分片逻辑；而 HTML5 只接受 HTTP(S) 上的 MP4/WebM/HLS/MP3 等明确编码+封装的资源。浏览器厂商从未在规范中加入 RTSP 支持，Chromium、Firefox、Safari 全部拒绝解析 rtsp:// URL。
- 尝试
→ 控制台报错DOMException: The element has no supported sources - 即使后端返回 200，
video.readyState始终为 0（HAVE_NOTHING） - 任何“RTSP 插件”或“ActiveX”方案在现代浏览器（尤其 Chrome 88+）中已被彻底禁用
可行路径：WebRTC 是目前最稳定的全屏方案
WebRTC 原生支持低延迟、双向音视频，且 对其完全兼容——全屏 API（requestFullscreen()）、自动旋转、画中画等均可用。关键在于：RTSP 流需经流媒体服务器转封装为 WebRTC 的 SDP/ICE 流。
- 典型链路：
RTSP 摄像头 → SRS / ZLMediaKit / Janus（接收并转 WebRTC） → 前端+RTCPeerConnection -
前端只需调用
video.requestFullscreen()，和播 MP4 完全一致，无额外适配 - 注意：WebRTC 需 HTTPS 页面才能启用摄像头/麦克风权限，但纯播放流在 HTTP 下仍可工作（Chrome 120+ 已放宽）
- 示例片段（使用 SRS 提供的 WebRTC 播放器）：
const pc = new RTCPeerConnection({iceServers: []});
pc.addTransceiver('video', {direction: 'recvonly'});
pc.ontrack = (e) => video.srcObject = e.stream;
pc.setRemoteDescription({type: 'offer', sdp: 'v=0\r\n...'});
// 全屏调用与普通 video 无区别
button.addEventListener('click', () => video.requestFullscreen());
HLS/HTTP-FLV 方案的全屏兼容性陷阱
这类方案依赖 MSE（Media Source Extensions），虽能用 播放，但全屏行为在不同平台差异明显：
立即学习“前端免费学习笔记（深入）”；
- iOS Safari 对 HLS 全屏支持好，但强制进入原生播放器（无法自定义控件、无法捕获
fullscreenchange） - Android Chrome 对 HTTP-FLV（通过
flv.js）全屏需手动触发，且部分机型会降级为窗口播放（video.webkitRequestFullScreen()失效） - 所有 MSE 方案中，
video.videoWidth/video.videoHeight在首帧解码前为 0，直接调requestFullscreen()可能失败，应监听loadedmetadata事件 - 务必检查
document.fullscreenEnabled，旧版 Android WebView 返回false，此时只能模拟全屏（CSS transform + viewport 缩放）
真正决定能否全屏的，从来不是 RTSP，而是你最终喂给 的是什么格式、运行在什么环境。WebRTC 最接近“开箱即用”，但需要服务端支持；HLS/FLV 更轻量，却得为每种终端写 fallback 逻辑——别在前端硬扛 RTSP 解析，那条路早在 2015 年就封死了。
