关键是以mediasource为底层管道，搭配fmp4格式、websocket直推、精准缓冲管理及按浏览器能力分级加载：fmp4结构清晰且全平台兼容；websocket替代http轮询降低延迟；需校验updating状态、监听updateend、定期remove旧数据；ios safari 16以下等不支持mse的环境降级至hls或提示跳转。
要在HTML5中用MediaSource接口实现跨平台低延迟直播，关键不是“只靠MediaSource”，而是把它作为底层管道，搭配合适的流格式、传输协议和播放器逻辑。原生MediaSource本身不定义协议，它只负责把二进制媒体块（如fMP4）喂给<video></video>。真正决定延迟和兼容性的，是数据来源格式、分片节奏、缓冲策略和浏览器支持边界。
选对流格式：优先用fMP4而非TS或FLV
fMP4（fragmented MP4）是MediaSource最友好、最稳定支持的格式。它结构清晰、可随机写入、解码启动快，且被所有支持MSE的浏览器（Chrome、Edge、Firefox、Safari 17.1+ via ManagedMediaSource）原生接纳。
- 避免直接喂TS（.ts）或原始FLV——它们需前端转封装，增加JS开销和延迟，还易出同步错
- 服务端应输出CMAF（Common Media Application Format）兼容的fMP4片段，这是LL-HLS和DASH低延迟场景的事实标准
- MIME类型声明必须准确，例如：
video/mp4; codecs="avc1.640028,mp4a.40.2"，编码信息要与实际流一致，否则addSourceBuffer会抛错
传输层适配：WebSocket优于HTTP轮询
HTTP分段拉取（如fetch + setInterval）有固有延迟：DNS、TCP握手、首字节时间、服务端排队。在200–500ms级低延迟目标下，不可靠。
- 改用WebSocket长连接直推fMP4片段，服务端一生成就发，前端一收到就
appendBuffer - 客户端需处理粘包/断帧：每个fMP4片段前加4字节长度头，JS按长度切片，再送入SourceBuffer
- 添加简单心跳与重连机制，WebSocket关闭后3秒内自动重建，并从服务端最新GOP起播，避免追旧数据
缓冲与播放控制：主动管理sourceBuffer状态
默认行为容易卡顿或跳帧——比如appendBuffer时buffer已满、时间戳不连续、或updating未结束就再次调用。
- 每次写入前检查
sourceBuffer.updating === false；写入后监听updateend事件再追加下一段 - 定期调用
sourceBuffer.remove()清理已播放过的旧区间（如remove(0, video.currentTime - 5)），防止内存溢出和缓冲区阻塞 - 设置
video.playbackRate = 1.005微调追赶速度，应对网络抖动导致的短暂卡顿
跨平台兜底策略：按浏览器能力分级加载
不是所有设备都平等支持MSE直播。iOS Safari 16以下不支持MediaSource，Android WebView版本混乱，部分旧版Chrome禁用MSE。
- 先检测
window.MediaSource && MediaSource.isTypeSupported('video/mp4; codecs=...') - 支持则走WebSocket + MSE路径；不支持但能播HLS（如Safari），则降级为
video.src = 'live.m3u8' - 全都不行（如极老安卓WebView），显示静态提示+扫码跳转App，不硬撑JS播放
- 所有路径统一使用同一套流地址路由（如
/live/{streamId}/ws//live/{streamId}/m3u8），便于CDN和鉴权复用
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
