必须用Web Worker解码，因其提供线程隔离，避免CPU密集型解码阻塞UI，支持并行处理、精细帧控、非标格式接入及后续DRM/滤镜扩展。
前端音视频播放器全栈自研，核心难点在于把原本依赖浏览器原生 <video></video> 标签的解码与渲染链路，下沉到 JS 层可控范围内。Web Worker 是关键突破口——它让 CPU 密集型的解码任务脱离主线程，避免卡顿，同时为接入自研解码器（如 FFmpeg.wasm、libvpx.js、dav1d.js 等）提供沙箱环境。
为什么必须用 Web Worker 做解码
音视频解码是典型同步计算密集型任务：YUV 转 RGB、帧内预测、熵解码、环路滤波……单帧解码常需数毫秒到数十毫秒。若在主线程执行，会直接阻塞 UI 渲染、事件响应，造成明显卡顿甚至页面无响应。Web Worker 提供独立 JS 执行上下文和线程隔离，解码逻辑可并行运行，主线程专注控制流（seek、play/pause）、时间轴同步、Canvas 渲染调度。
- 解码不阻塞 UI，滚动、点击、弹窗等交互保持流畅
- 可精细控制解码节奏（如按帧率节流、丢帧策略、关键帧强制解码）
- 便于接入非标准格式（AV1/VP9/HEVC 的纯 JS 解码器）或私有封装格式
- 为后续支持 DRM、低延迟推流、自定义滤镜链打下基础
解码器选型与集成要点
纯 JS 解码器性能与体积需权衡。FFmpeg.wasm 通用性强但包体大（~20MB+），适合 MVP 验证；libvpx.js（VP8/VP9）、dav1d.js（AV1）更轻量、解码更快，但格式支持窄。集成时注意：
- 通过
importScripts()或 ES Module 动态导入，在 Worker 内初始化解码器实例，避免主线程加载阻塞 - 使用 Transferable Objects（如
ArrayBuffer）传递原始码流数据，避免结构化克隆开销 - 解码输出建议统一为 Planar YUV420p 或 RGBA ArrayBuffer，便于后续 WebGL/Canvas 渲染
- 处理 B帧依赖、时间戳错乱、DTS/PTS 同步等真实流场景问题，不能只跑 I 帧 demo
主线程与 Worker 协同模型
不是“Worker 解完一帧就扔给 Canvas”，而是建立带状态的双向通信管道：
立即学习“前端免费学习笔记（深入）”；
- 主线程发送指令：加载 URL / 设置分辨率 / seek 到时间点 / 暂停 / 设置解码参数
- Worker 返回结构化消息：解码成功帧数据 + pts + duration + 是否关键帧 + 解码耗时统计
- 引入简单队列与背压机制：Worker 解码过快时缓存帧（限制 2–3 帧），避免内存暴涨；主线程渲染慢则通知 Worker 临时降帧率或丢非关键帧
- 时间同步靠主线程维护播放时钟（
performance.now()+ requestAnimationFrame），Worker 只负责按时序交付帧，不自行计时
渲染层衔接与性能兜底
解码出的帧需高效上屏。优先走 WebGL（用 YUV 转 RGB shader 实现零拷贝渲染），次选用 createImageBitmap() + <canvas></canvas> 2D context（Chrome/Firefox 支持，比 putImageData 快 5–10 倍）。关键细节：
- 复用
ImageBitmap或 WebGL 纹理对象，避免每帧重复分配显存 - Canvas 渲染严格绑定
requestAnimationFrame，跳帧逻辑由主线程根据当前帧 pts 与播放时钟差值决策 - Worker 中预留 fallback：当检测到解码超时（如 >100ms/帧），主动降级（跳过 P/B 帧、切回软解参数）或上报错误
- 首帧加载加 loading 状态与超时中断，防止 Worker 卡死无响应
不复杂但容易忽略：全栈自研不是为了炫技，而是解决原生 <video></video> 不可控的问题——比如需要精确逐帧调试、注入自定义音频处理、对接非 HTTP 协议流（WebSocket/RTP）、或做端侧 AI 增强（超分、降噪）。Web Worker 是那根承重梁，撑起整个自定义媒体管线的地基。
