Web Worker 适合视频切片但无法转码；切片需解析MP4 Box结构并对其IDR帧，转码应交由WebAssembly或服务端完成。

HTML5 中的 Web Worker 无法直接对高清视频进行转码，但可以高效完成切片（splitting）任务；转码必须依赖服务端或 WebAssembly 方案，前端纯 JavaScript 几乎不可行。

Worker 适合做视频切片，原因很实在

切片本质是按时间或字节范围提取视频片段，不改变编码格式，只需解析容器结构（如 MP4 的 moov、mdat），定位并拷贝二进制数据。这属于 CPU 密集型但无状态的操作，正好契合 Worker 的能力边界。

• 主线程不阻塞：切片过程可长达数秒，放在 Worker 里避免页面卡死
• 可复用 ArrayBuffer：通过 postMessage(..., [buffer]) 零拷贝传递视频数据，大幅减少内存开销
• 支持分块读取：结合 File.slice() 或 Response.arrayBuffer()，无需一次性加载整个高清视频文件

MP4 切片的关键是理解 Box 结构

MP4 是基于 Box（原子）的容器格式。切片时不能简单按字节截断，否则会破坏 moov（元数据）或导致 mdat（媒体数据）不完整。Worker 中需解析 Box 层级，识别关键帧位置（如 stss 表）、时间映射（stts、ctts）、样本偏移（stco/co64）等。

• 推荐使用轻量库如 mp4box.js（已适配 Worker 环境），它提供 appendBuffer 和 onReady 回调，可在 Worker 内解析并定位 I 帧起始点
• 切片起点应严格对齐 IDR 帧，否则播放器解码失败；可通过解析 avcC + sample table 获取随机访问点
• 生成新 MP4 片段需重写 moov（精简后保留必要 box）和拼接对应 mdat 数据——这不是“复制粘贴”，而是重构容器

转码？别在 Worker 里硬扛

将 H.264 转为 VP9、或调整分辨率/码率，涉及 DCT、运动估计、量化、熵编码等大量数学运算，JS 执行效率比原生低 10–50 倍。实测 1080p 视频在高端 PC 上 JS 软编也仅达 0.3x 实时速度，且发热严重。

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

• 可行替代路径：WebAssembly + FFmpeg.wasm，它把 C 编写的 ffmpeg 编译为 wasm，在 Worker 中运行，性能提升显著（可达 3–5x JS）
• 注意限制：FFmpeg.wasm 仍受限于浏览器内存（通常 ≤2GB）和单线程 wasm 执行模型，超长视频建议分段转码+合并
• 更稳方案：Worker 负责切片 → 上传分片至服务端 → 后端用 FFmpeg/GPU 加速转码 → 返回结果 URL。这是生产环境主流做法

实际落地要绕过几个坑

真实项目中，光有 Worker 不够，还要协调资源、错误恢复和用户体验。

• 大文件读取：用 ReadableStream + BYOB reader 流式读取视频，避免 file.arrayBuffer() 内存爆炸
• 进度反馈：Worker 通过 postMessage({ type: 'progress', value: 0.6 }) 主动推送进度，主线程更新 UI
• 中断与恢复：保存当前解析 offset 和已产出片段列表，意外终止后可从断点续切（需 IndexedDB 持久化中间状态）
• CORS 与 MIME：确保视频资源支持跨域（crossorigin 属性），且响应头含 Content-Type: video/mp4，否则部分 API 报错