html5实时流媒体核心是mse，需创建mediasource绑定video、监听sourceopen后addsourcebuffer、用appendbuffer动态注入fmp4/webm分片，并配合协议适配与时间轴管理实现低延迟和abr。
HTML5 多媒体数据流的实时处理，核心在于绕过传统“整文件加载+播放”的模式，转而由 JavaScript 动态控制媒体数据的获取、解析与喂入。它不是简单放一个 <video src="xxx.mp4"></video>，而是把视频拆成小块、按需加载、边收边播——这才是低延迟直播、自适应码率、实时监控等场景的技术根基。
MediaSource Extensions（MSE）是实时流的底层支柱
MSE 是 W3C 标准 API，让 <video></video> 能接受 JavaScript 提供的二进制媒体片段（如 fMP4），而非只认完整 URL。没有 MSE，就无法实现真正可控的实时流。
- 必须先创建
MediaSource实例，并通过URL.createObjectURL()绑定到<video></video>的src - 监听
sourceopen事件后，调用addSourceBuffer()创建缓冲区，MIME 类型要精确匹配（例如"video/mp4; codecs=\"avc1.42E01E\""） - 所有媒体数据（无论来自
fetch、WebSocket还是WebRTC接收）都需转为ArrayBuffer，再用sourceBuffer.appendBuffer()写入 - 写入前需确保
sourceBuffer.updating === false，并注意时间戳对齐和abort()/remove()的清理逻辑
流协议适配决定能否“拉得动”和“跟得上”
浏览器原生不直接支持 RTMP 或 HLS（.m3u8）——它们需要转换层。不同协议对应不同技术路径：
-
HLS 流：依赖第三方库（如
hls.js），它内部将 .m3u8 解析为分片 URL，再用 MSE 加载每个 .ts 或 fMP4 片段 -
DASH 流：类似原理，常用
dash.js，解析 .mpd 描述文件，调度 fMP4 分片 -
WebSocket 直推 fMP4：服务端生成符合 MSE 要求的 fragmented MP4，前端用 WebSocket 持续接收并
appendBuffer，延迟可压至 500ms 内 - RTMP 转 MSE：需服务端（如 Nginx-rtmp + ffmpeg）将 RTMP 转为 fMP4 分片或 HLS/DASH，纯前端无法直解 RTMP
实时性关键：时间控制与错误恢复
真实流媒体不是“写进去就播”，必须主动管理时间轴和健壮性：
- 用
video.currentTime和sourceBuffer.timestampOffset对齐首帧时间，避免黑屏或跳帧 - 监听
sourcebuffer.updateend和error事件，出错时调用sourceBuffer.abort()后重试 - 根据网络状况动态切换分片质量（如 fetch 不同码率的 segment），这就是自适应流（ABS）的基础
- 设置
video.buffered监控已缓存区间，结合video.playbackRate可做追赶/减速播放
与 WebRTC 的分工边界要清楚
WebRTC 和 MSE 解决的是不同层级的问题：
- WebRTC 专用于点对点实时音视频通信（如视频会议），自带编解码、NAT 穿透、丢包重传，延迟极低（
- MSE 是单向广播式流媒体基础，适合直播、点播、监控大屏等，依赖服务端流分发，延迟通常在 1–5 秒，但扩展性强、兼容性好
- 两者可共存：比如用 WebRTC 采集本地流，再通过信令+SFU 推到 CDN，前端用 MSE 播放 CDN 下发的 DASH/HLS 流
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
