WebSocket-FLV
WebSocket-FLV 播放测试与 WSS 要求
解释 WS-FLV/WSS-FLV 如何传输 FLV 数据，以及 HTTPS 页面为什么需要 WSS。
网页能否直连
可播放
链路位置
WebSocket 低延迟流
浏览器结论
依赖 WebSocket + MSE 播放器
一句话结论
WebSocket-FLV 是把 FLV 数据通过 WebSocket 推给浏览器的低延迟方案。它依赖前后端约定，不是通用标准视频 URL。
它在视频链路里的位置
它通常用于受控系统里的实时预览：服务端接入源流，再通过 ws/wss 发送 FLV 二进制数据。
在浏览器项目里怎么用
前端需要 WebSocket 接收二进制数据，再交给播放器解析 FLV。HTTPS 页面必须使用 wss://，否则会被浏览器安全策略拦截。
服务端需要做什么
服务端要定义消息格式、首包内容、断线重连、鉴权和心跳。WebSocket 建连成功不代表媒体数据一定可解析。
常见开发场景
- 内网监控、私有控制台、需要主动推送状态和媒体的系统。
排查顺序
- 先看 ws/wss 是否匹配页面协议，再看 WebSocket 返回的是二进制 FLV 还是错误消息。
- 再查消息边界、FLV 头、编码和播放器缓冲策略。
推荐转换路径
- RTSP/RTMP -> WS-FLV 用于私有低延迟预览。
- 公网通用播放优先 HLS 或 WebRTC。
最小可用实现
- 前端：连接 wss://，接收 ArrayBuffer，交给支持 WS-FLV 的播放器。
- 后端：稳定推送 FLV 数据，并给出断线和鉴权错误。
开发者判断标准
WebSocket-FLV 不能只按名字判断是否可播，要看它在链路中承担的是源站输入、网页播放输出、低延迟会话，还是网络辅助能力。当前浏览器结论：依赖 WebSocket + MSE 播放器。落地前需要确认真实源站、是否需要服务端转换、CORS/HTTPS 策略、编码支持和延迟目标。