浏览器不能直连 RTSP。本页会识别 rtsp:// 地址，并建议通过服务端转换为 WebRTC、HLS 或 HTTP-FLV。
使用公网真实媒体流，适合快速验证浏览器播放链路。
随站点发布的标准样本，用于复现 FLV、TS、fMP4、H.265 等浏览器实验能力。
模板用于识别和诊断，需要替换成你的真实服务地址；RTSP/RTMP 不会在浏览器直连播放。
现代浏览器不能直接播放 RTSP，需要服务端代理或转换。
建议转换为：RTSP -> WebRTC、RTSP -> HLS、RTSP -> HTTP-FLV。
浏览器不能直连 RTSP。真实测试需要服务端先拉取 rtsp:// 源，再转成 HLS、HTTP-FLV 或 WHEP/WebRTC。
可接入 server-side proxy：RTSP -> WHEP 用于低延迟，RTSP -> HLS 用于兼容性，RTSP -> HTTP-FLV 用于工程调试。
分享链接或 embed 给其他人后，对方通常无法访问你的内网流。
需要公网可达地址、VPN、同网段访问，或服务端代理。
分享链接会把流地址放进 URL query，请不要分享含私密 token 的地址。
按浏览器播放、源站接入、WebRTC 体系和基础传输梳理常见流媒体协议。这里重点说明能不能直连、需要什么播放器或服务端能力，以及推荐测试路径。
这些协议或容器可以在浏览器内尝试播放，但通常还要看 MSE、播放器库、MIME type、CORS、编码和 HTTPS 策略。
兼容性很稳的网页播放格式之一：Safari 原生，其他浏览器通常用 hls.js + MSE。
适合作为主播放链路，重点检测 playlist、segment、CORS、MIME type 和 codec。
不是原生 video 格式，但可用 mpegts.js/flv.js/Jessibuca 通过 MSE 播放 H.264/AAC FLV。
用 mpegts.js 作为第一播放引擎，并保留 Jessibuca 对比路线。
通过 WebSocket 推 FLV 数据，前端仍需 MSE 播放器；HTTPS 页面生产环境应使用 WSS。
用于低延迟私有链路，优先确认 WSS、FLV tag 边界和播放器接入约定。
这些通常不是浏览器直连播放格式，适合作为服务端接入源，再转换成 HLS、WebRTC、FLV 或其他网页播放输出。
WebRTC 是浏览器实时音视频能力，STUN/TURN 是连通性辅助服务，不是视频文件或直播 URL。
HTTP/HTTPS 只是传输方式，能否播放取决于它承载的具体媒体格式、响应头和浏览器安全策略。
HTTP/HTTPS 是传输，不代表媒体一定可播；关键是它承载的容器和响应头。
先识别扩展名、Content-Type、Range、CORS，再路由到 HLS/MP4/FLV/TS/fMP4。
RTSP 是摄像头和 NVR 常见源站协议，但不是浏览器可直连协议。网页端需要服务端接入 RTSP，再输出 HLS、WebRTC/WHEP、HTTP-FLV 或 WS-FLV。
不能直接播放。浏览器没有原生 RTSP 播放栈，需要服务端代理或转换后再给网页播放。
WebRTC 延迟更低，适合实时监控；HLS 兼容性更好，适合公开分发但延迟通常更高。
这是内网地址，云端服务通常无法访问。需要在同网段部署代理，或提供公网可访问的中转服务。