直播流不能直接用

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

想把直播流直接塞进 标签里播放？这事儿可没看上去那么简单。很多人以为加个 src 属性就万事大吉，结果一跑起来，不是黑屏就是报错。问题的核心在于，你必须同时搞定三件事：协议兼容性、浏览器能力差异，以及精准的加载时机。举个例子，Safari 能原生播放 .m3u8 链接，但 Chrome 就不行；至于 rtmp:// 开头的地址，在任何现代浏览器里都注定会失败——这通常不是你的代码写错了，而是浏览器压根就不支持这种协议。

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

其实有个快速判断法：看一眼 URL 的前缀和后缀就明白了。

• https://xxx.com/live/index.m3u8 → 有戏，但前提是在 Safari 或 iOS 环境，否则还得请 hls.js 出马。
• https://xxx.com/play/123.flv → 没戏。浏览器原生不支持 FLV，必须依赖 flv.js 这类库。
• rtmp://xxx.com/live/stream → 绝对不行。Flash 时代早已落幕，现代浏览器已彻底移除了对 RTMP 的原生支持。
• https://xxx.com/stream/segment-001.fmp4 → 可行，但需要手动使用 MediaSource API 来接入流数据。

这里有个细节要注意：URL 中 ? 后面的参数（比如 ?token=xxx&User-agent=xxx）虽然不影响对核心协议的判断，但必须原封不动地保留。如果服务端校验 User-Agent 或者强制要求 HTTPS，而你却用了 HTTP 去加载，那么等待你的很可能是 403 错误或者 CORS 跨域失败。

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

在 Chrome 或 Firefox 里播放 HLS 流，hls.js 几乎是标准答案。但它的工作原理需要理解清楚：它并不是“让 标签突然支持了 m3u8”，而是充当了一个中间层，把 HLS 流实时解析成 Media Source Extensions (MSE) 能够接受的媒体分片。

一个极其常见的坑是：在调用 loadSource() 之后，立刻迫不及待地执行 video.play()。结果就是播放器静默失败，或者控制台抛出 DOMException: play() failed because the user didn't interact with the document first 这样的错误。

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

• 关键时机：必须等待 Hls.Events.MANIFEST_PARSED 事件触发之后，再调用 video.play()。这个时候，背后的 MediaSource 才真正准备就绪。
• 正确绑定：不要直接给 设置 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、缓冲区清理等逻辑都需要开发者自己处理。
• 绕开 RTSP：记住，浏览器没有任何原生支持 RTSP 协议的能力。所有声称能在浏览器播放 RTSP 的方案，本质都是服务端先进行了转封装（例如 RTSP 转 WebRTC，或 RTSP 转 FLV），前端只不过是在消费转换后的结果流。

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

调用 video.play() 失败，很多时候问题不出在 Ja vaScript 语法上，而是媒体的状态还没准备好。下次遇到这个问题，可以按这个清单快速排查：

• 检查 video.readyState 是不是 0（即 HA VE_NOTHING）？这个状态意味着媒体元素还没有加载到任何数据，此时调用 play() 肯定会失败。
• 播放指令是在用户交互（点击、触摸）之后发出的吗？特别是在移动端，自动播放策略非常严格，没有用户交互且包含音频的媒体，会被直接禁止播放。
• 如果用了 hls.js，是不是忘了监听 MANIFEST_PARSED 事件？在这个事件触发前，video.src 很可能还是空的，对着一个空的源调用 play() 自然无效。

最稳健的写法永远是：等待播放库明确告诉你“可以播了”的时候，再启动播放setTimeout 猜测，或者去轮询 readyState。对于延迟容忍度低的项目，更要时刻关注服务端的输出格式和浏览器对 MSE 的兼容性边界——比如，某些旧版本的 Edge 浏览器可能无法解码 video/mp4; codecs="a vc1.64001f" 格式，但换成 a vc1.42E01E 就一切正常了。