HTML5视频清晰度切换的平滑实现需解决播放状态连续性、时间轴对齐和缓冲管理三大难点：原生video元素修改src会重置状态；不同分辨率视频关键帧与PTS不一致易致解码断层；缓冲水位决定切换时机，低于3秒应优先降码率保流畅。
HTML5 视频清晰度切换看似只是换一个视频地址，但真正实现“平滑”并不容易。核心难点不在界面操作，而在于播放状态连续性、时间轴对齐和底层缓冲管理这三个层面。
播放状态中断是默认行为
原生 <video> 元素不支持运行时修改 src 后继续播放——调用 load() 会重置播放器内部状态，导致 currentTime 归零、缓冲区清空、解码器重启。即使手动恢复时间点，Safari 常跳回开头，Chrome 可能触发黑屏或卡顿。
- 直接改
video.src或替换<source>必须搭配load()+loadedmetadata回调 + 手动currentTime设置 - 但
loadedmetadata不代表视频已解码可播，需监听canplay或canplaythrough才更稳妥 - 移动端尤其敏感：部分 Android 浏览器在
load()后首次play()会被静音策略拦截
时间戳错位引发解码断层
不同分辨率 MP4 文件即使时长相同，其关键帧（GOP）起始位置、PTS 时间基、音频采样对齐方式往往不一致。强行拼接会导致浏览器解码器无法衔接，出现花屏、跳帧或 seek 失败。
- 服务端切片必须统一 GOP 长度与起始 PTS（例如全部从 0 开始，每段 4 秒）
- 前端 append 前应校验新分片的
startTimestamp与当前buffered.end的误差 ≤ 100ms - 200–500ms 小间隙可用黑帧/静音帧填充；超过 500ms 应丢弃并请求邻近段，而非硬塞
缓冲区管理决定是否“感知卡顿”
用户是否察觉切换，取决于缓冲水位是否跌破临界值。单纯“立刻切”不如“选对时机切”。频繁切换还会触发 MSE 内部重初始化，造成卡顿。
立即学习“前端免费学习笔记（深入）”；
- 缓冲低于 3 秒 → 立即降码率，保流畅优先
- 缓冲稳定在 8–12 秒且网络下载耗时比
- 每次成功切换后启用 8 秒滞留窗口，禁止重复操作，防抖动震荡
- 复用同一 SourceBuffer，不新建不 remove —— 频繁增删会触发重初始化
协议与工具链限制现实选择
MP4 是单文件格式，天然不支持动态码率切换；HLS/DASH 才是设计用来做 ABR 的协议。但浏览器原生只支持 HLS（仅限 Safari），DASH 必须依赖 dash.js 或 hls.js 这类库模拟。
- hls.js 提供
hls.currentLevel接口，切换时自动处理时间对齐与缓冲续接 - dash.js 通过
setQualityFor('video', level)控制，但需确保 MPD 中各 Representation 的availabilityTimeOffset和presentationTimeOffset一致 - 所有分片请求必须开启 CORS，否则跨域拦截会导致某档码率加载失败
