WebRTC
WebRTC 播放测试与浏览器兼容说明
解释 WebRTC 为什么适合低延迟网页播放，以及测试 WHEP、STUN、TURN 和 ICE 时应检查什么。
网页能否直连
可播放
链路位置
浏览器实时音视频
浏览器结论
浏览器原生支持，但需要信令
一句话结论
WebRTC 适合做网页里的低延迟实时播放，但它不是一个普通视频地址。开发时要把它当成一套会话建立流程：前端发起连接，服务端返回会话信息，双方协商成功后才有画面。
它在视频链路里的位置
在视频链路里，WebRTC 通常位于“网页播放出口”。RTSP、RTMP 或 SRT 等源流先进入媒体服务器，再由媒体服务器输出 WebRTC 给浏览器。
它解决的是低延迟播放和网络穿透问题，不负责摄像头发现、推流接入或历史录像存储。
在浏览器项目里怎么用
前端不能把 WebRTC 地址直接放进 video src。通常要使用 RTCPeerConnection，并通过 WHEP 或自定义接口交换 SDP。
如果页面只拿到一个 RTSP 地址，浏览器不会自动变成 WebRTC；中间必须有媒体网关完成接入和输出。
服务端需要做什么
服务端需要提供 WHEP endpoint 或信令接口，生成 SDP answer，并配置 STUN/TURN 让不同网络下的用户能连通。
媒体服务器还要决定输出什么编码。网页端最稳的是 H.264 视频，音频常见 Opus 或 AAC，H.265 不能作为全浏览器默认方案。
常见开发场景
- 摄像头实时预览、远程控制、低延迟直播、多人互动和监控大屏。
- 需要低延迟但愿意维护媒体服务器、信令接口和 TURN 带宽的项目。
排查顺序
- 先看信令接口是否返回合法 SDP，再看 ICE 是否连接成功，最后看浏览器是否支持协商出来的编码。
- 信令成功但无画面时，重点查 STUN/TURN、企业防火墙、UDP 被阻断、H.265 协商失败。
推荐转换路径
- RTSP 摄像头要低延迟网页预览，常见路径是 RTSP -> WebRTC/WHEP。
- 如果用户更关心兼容和 CDN 分发，应该同时输出 HLS 作为备用。
最小可用实现
- 前端：创建 RTCPeerConnection，向 WHEP/信令接口提交 offer，把返回的 answer 设置进去。
- 后端：接入源流，输出 WebRTC，会话接口支持 CORS，并配置可用的 STUN/TURN。
开发者判断标准
WebRTC 不能只按名字判断是否可播，要看它在链路中承担的是源站输入、网页播放输出、低延迟会话，还是网络辅助能力。当前浏览器结论：浏览器原生支持，但需要信令。落地前需要确认真实源站、是否需要服务端转换、CORS/HTTPS 策略、编码支持和延迟目标。