浏览器视频导出太慢怎么优化？一次 WebCodecs 实践：8 分钟视频耗时降低 31%

做浏览器视频编辑器，短视频跑得顺畅，并不代表长视频也能保持同样的体验。

素材增长到七八分钟，或者换成高码率相机视频后，一些问题才逐渐明显：

• 播放头在移动，预览画面却暂时停住。
• 拖动播放头后，需要等待一段时间才能继续播放。
• 导出前的音频准备耗时增加。
• 视频导出过程中，解码、合成和编码之间存在等待。

这次我们针对开源项目 Timeline Studio 做了性能优化，并取出第一轮优化之前的代码进行对照测试。

结果是：8 分钟视频平均导出总耗时从约 3 分 12 秒降到约 2 分 12 秒，减少约 60 秒，降幅约 31.3%。

源码：Timeline Studio GitHub 仓库 体验：在线打开视频编辑器

一、先明确测试口径

性能指标需要说明输入、输出和计时范围，否则不同测试之间很难比较。

本次使用同一台电脑、同一段约 8 分钟的合成压测素材，设置如下：

计时从音频准备开始，到导出完成结束，包含音频准备和视频导出，不包含素材导入及时间线缩略图准备。

测试按“旧版 → 新版 → 新版 → 旧版”的顺序执行，每轮启动新的浏览器进程。

分阶段看：

按原始数据计算，总耗时降低 31.3%，平均节省 60.1 秒。

每个版本各测试两次，结果仍存在运行波动。这里使用的是合成素材，指标不能直接代表所有相机实拍 Vlog、设备和效果组合。

二、优化点一：避免音频准备阶段先解码整段 WAV

旧版提取视频内嵌音频时，需要先通过 FFmpeg 解码为 WAV，再进行后续处理。

对于长视频，这条路径会带来几项成本：

如果源音轨已经是 AAC，可以在符合条件时直接提取编码包并重新封装，减少准备阶段的工作。

处理流程可以概括为：

旧路径：
视频 → 音频解码 → WAV/PCM 中间数据 → 后续处理

新增路径：
视频 → AAC 编码包提取与封装 → 后续处理

最终输出音频仍按照导出设置编码。这项改动减少的是前置准备成本。

不能忽略 AAC 时间戳

编码包提取并非只复制字节。

AAC 可能包含预滚和负时间戳。如果直接丢弃这些信息，可能造成音画偏移。因此实现中需要保留并补偿源时间偏移，同时区分存储时长与片段逻辑时长。

不符合条件的音频格式继续使用原有路径。

本次测试中，音频准备平均耗时从 9.3 秒降到 0.9 秒。

三、优化点二：减少视频帧的中间转换

视频导出的主要链路是：

解码 → 画面合成 → 编码 → 封装

如果解码得到的帧在进入最终合成器之前，还要经过额外的 Canvas 栅格化，就会增加每帧的处理成本。

对于 8 分钟、30 fps 的输出，需要处理约：

8 × 60 × 30 = 14,400 帧

单帧看起来不大的重复开销，累计到长视频上就值得检查。

新版增加了受条件约束的直接帧路径：符合条件时，将解码得到的 VideoFrame 直接交给共享合成器，省去中间转换。

直接帧路径需要明确边界

本次实现只在原尺寸、无旋转、方形像素，且没有相关变换和效果处理需求等条件满足时启用。

涉及缩放、调色、动画、遮罩等场景，继续使用 Canvas 路径。

验证中发现，缩放场景采用不同栅格化方式可能产生像素差异。因此没有为了覆盖更多场景而放宽条件。

这也是画面性能优化需要注意的一点：先确认什么处理可以省略，再决定走哪条路径。

四、优化点三：用有界流水线减少串行等待

完全串行的处理方式通常是：

解码当前帧
↓
合成当前帧
↓
等待当前帧编码提交
↓
处理下一帧

这种方式容易理解，但会让部分阶段等待其他阶段完成。

新版让有限数量的任务重叠执行：

• 提前准备下一帧解码结果。
• 当前帧提交编码后，在背压允许的范围内合成下一帧。
• 音频编码与视频处理并行推进。
• 已完成的帧及时释放。

为什么必须限制队列？

如果只增加并发，没有限制在途任务数量，长视频可能持续积累帧资源。

因此流水线需要同时控制预取和提交数量，避免把计算等待转化成内存压力。

编码器方面，优先探测支持的硬件编码配置，不支持时回退到默认配置。硬件加速是否实际可用，取决于浏览器、操作系统和设备。

取消导出也要考虑在途任务：停止继续提交，等待有限任务收尾，再释放输出资源，避免异步操作悬挂。

五、播放卡顿：检查预览与后台任务是否争用资源

导出之外，长视频预览还存在另一类问题：当前画面和后台缩略图可能同时消耗解码资源。

本次做了以下调度调整。

1. 播放期间暂停后台缩略图精修

先保证预览画面的解码与显示，暂停非当前必需的后台工作。

2. 拖动期间优先响应播放头

用户持续拖动时，取消后台缩略图任务，优先更新播放头和预览。释放指针后，再恢复可见区域优先的缩略图准备。

3. 优先执行最新跳转请求

连续拖动会产生多个目标位置。开始播放时，应优先处理用户最终选择的位置，避免旧请求继续阻塞恢复。

4. 解码等待时暂停播放时钟

当画面仍在等待解码时，避免时间线持续向前推进，减少“播放头走了，画面没动”的不同步现象。

5. 减少实时缩略帧的编解码往返

对已经确认的解码帧直接绘制，减少反复 JPEG 编码和解码，同时保持源时间戳与时间线采样位置一致。

对于本地导入、在浏览器内处理的素材，排查这类问题时，需要关注用户设备上的解码、绘制和任务调度。

六、如何验证优化没有改变输出行为

本次优化保持了相同的导出分辨率、帧率和目标码率，并进行了针对性检查：

项目也使用了 Sony ZV-1 的原生 4K 相机样片进行兼容性和解码路径检查。

需要区分的是：本文的 31.3% 性能指标来自前述 8 分钟合成素材测试，并非 8 分钟实拍 Vlog 的测量结果。

七、源码与复现入口

此次优化的收益主要来自：

• 减少音频准备中的重复解码和中间数据。
• 在符合条件时省去视频帧中间转换。
• 让解码、合成和编码适度重叠。
• 播放和拖动时优先保障用户正在等待的任务。

相关实现已经公开：

• 项目仓库与使用说明
• 本次优化提交
• 优化前后代码对比
• 在线体验

欢迎使用自己的素材复现。提交性能问题时，建议附上设备配置、浏览器版本、素材编码参数、导出设置和效果组合，并分别记录准备阶段和导出阶段耗时，方便定位瓶颈。