HTML直播流播放怎么做_HTML直播流实时视频播放方法【最佳实践】

直播流不能直接用<video>标签加src播放，需匹配协议（如Safari原生支持m3u8、Chrome需hls.js）、浏览器能力与加载时机；RTMP/FLV等协议须借助flv.js或MediaSource，且play()必须在用户交互后、媒体就绪事件触发时调用。

直接用 <video> 标签播放直播流，不是“加个 src 就行”，而是必须匹配协议、浏览器能力与加载时机。Safari 能原生播 .m3u8，Chrome 不行；rtmp:// 地址在任何现代浏览器里都必然失败——这不是代码写错了，是协议根本不被支持。

怎么判断你的直播 URL 能不能直接塞进 <video>

看协议前缀和后缀：

• https://xxx.com/live/index.m3u8 → 可能行（但需 Safari / iOS 或配 hls.js）
• http://xxx.com/play/123.flv → 不行（原生不支持 FLV，得用 flv.js）
• rtmp://xxx.com/live/stream → 绝对不行（浏览器已弃用 Flash，无原生 RTMP 支持）
• http://xxx.com/stream/segment-001.fmp4 → 可行（需手动用 MediaSource 接入）

URL 中 ? 后的参数（如 ?token=xxx&User-agent=xxx）不影响协议判断，但必须原样保留；若服务端校验 User-Agent 或要求 HTTPS，而你用 HTTP 加载，会 403 或 CORS 失败。

Chrome / Firefox 播 .m3u8 必须用 hls.js，且不能乱调 play()

hls.js 不是“让 <video> 支持 m3u8”，而是把 HLS 解析成 MSE 可接受的分片流。常见错误是：loadSource() 后立刻 play()，结果静默失败或报 DOMException: play() failed because the user didn't interact with the document first。

立即学习“前端免费学习笔记（深入）”；

• 必须等 Hls.Events.MANIFEST_PARSED 事件触发后再调 video.play()，此时 MediaSource 已 ready
• 不要给 <video> 设 src 属性，hls.attachMedia(video) 才是绑定方式
• Safari 19+ 原生支持 HLS，Hls.isSupported() 返回 false，此时应退回到直接设 video.src = 'xxx.m3u8' 并调 play()
• muted 属性仍要加，否则部分安卓 WebView 会拦截自动播放

低延迟场景别硬啃 HLS，试试 flv.js 或 MediaSource + WebSocket

HLS 默认延迟 10–30 秒，真要 sub-3s 延迟，得换路径：

• flv.js：适合服务端能输出 HTTP-FLV 或 WebSocket-FLV 的场景，Chrome/Firefox/Safari 10+ 全兼容，初始化快，延迟常压在 1–2 秒
• MediaSource + WebSocket：后端推 fMP4 分片（非完整 MP4），前端用 sourceBuffer.appendBuffer() 持续写入；优势是完全可控，劣势是时间戳对齐、随机 Seek、buffer eviction 都得自己处理
• 别碰 RTSP：浏览器无原生支持，所有“RTSP 播放”方案本质都是服务端转封装（如 RTSP → WebRTC 或 RTSP → FLV），前端只是消费结果

video.play() 失败？先查三件事

不是 JS 写错了，是媒体状态没到位：

• video.readyState 是 0（HAVE_NOTHING）？说明还没加载任何数据，play() 必挂
• 是否在用户交互（click/touch）后才调用？移动端尤其严格，无交互 + 有音频 = 直接拒播
• 是否用了 hls.js 却忘了监听 MANIFEST_PARSED？此时 video.src 还是空，play() 对着空气喊

最稳的写法永远是：等库明确告诉你“可以播了”，再播；而不是靠 setTimeout 或轮询 readyState。延迟容忍度低的项目，更要盯紧服务端输出格式和浏览器 MSE 兼容性边界——比如某些旧版 Edge 对 video/mp4; codecs="avc1.64001f" 解码失败，换 avc1.42E01E 就通了。