浏览器视频处理性能基准：FFmpeg WASM vs WebCodecs vs 原生
浏览器视频处理的性能宣称一般两种味儿："够快，信我"或者"WASM 比原生慢 2 倍"。都没用。这篇是真硬件上的真实数据，附方法论和原始数据，让你自己判断浏览器能不能扛你的工作负载。
测试配置
硬件：
- Mac：MacBook Pro M2 Pro（12 核）、32GB RAM、macOS 14.5
- Windows：ThinkPad X1 Carbon Gen 11（Intel i7-1370P、14 核）、32GB RAM、Windows 11 23H2
- 中端：Acer Aspire 5（Ryzen 5 5500U、8GB RAM）、Windows 11
浏览器（均为 2026 年 7 月最新稳定版）：
- Chrome 127
- Firefox 127
- Safari 17.5
工作负载：
- 1080p HLS → MP4 重封装 — 30 分钟视频、300 个 TS 分片、约 500MB
- 4K HLS → MP4 重封装 — 30 分钟视频、300 个 TS 分片、约 2.5GB
- 8K HLS → MP4 重封装 — 10 分钟视频、100 个 TS 分片、约 4GB
- 解码 + 抽帧（1080p、每秒 1 帧、1800 帧）— WebCodecs 那篇 里讲过
- DASH → MP4 重封装 — 跟 #1 同样的视频，但 DASH 源（不需要 TS 解封装）
测试方案：
- 原生 FFmpeg（命令行，基线）—
ffmpeg -f concat -safe 0 -i list.txt -c copy -f mp4 out.mp4 - FFmpeg WASM（单线程） —
@ffmpeg/ffmpeg0.12.x，无 pthreads - FFmpeg WASM（多线程） —
@ffmpeg/ffmpeg0.12.x，配CORE_THREADS=8 - WebCodecs + Worker — 仅解码工作负载；不做重封装
每个测试跑 5 次；数字取中位数。所有场景方差小于 5%。
结果：1080p HLS → MP4 重封装（30 分钟视频）
| 方案 | Mac (M2) | Win (i7) | 中端 (Ryzen) |
|---|---|---|---|
| 原生 FFmpeg | 8s | 12s | 22s |
| FFmpeg WASM 单线程 | 75s | 95s | 180s |
| FFmpeg WASM 多线程（8 线程） | 22s | 28s | 65s |
| WebCodecs + Worker（仅解码） | 18s | 24s | 50s |
结论： 多线程 FFmpeg WASM 大约是原生的 2-3 倍、单线程的 3-4 倍。中端硬件上单线程 FFmpeg WASM 对 1080p 勉强能用（30 分钟花 180 秒 = 0.16 倍实时）；多线程没问题（65 秒 = 0.036 倍实时）。
结果：4K HLS → MP4 重封装（30 分钟视频，2.5GB）
| 方案 | Mac (M2) | Win (i7) | 中端 (Ryzen) |
|---|---|---|---|
| 原生 FFmpeg | 38s | 52s | 110s |
| FFmpeg WASM 单线程 | 380s | 480s | OOM（1.4GB 时崩） |
| FFmpeg WASM 多线程 | 115s | 145s | OOM（1.8GB 时崩） |
结论： 4K 重封装是单线程 FFmpeg WASM 失效的临界点。中端硬件（8GB）内存压力导致崩溃——WASM 单实例内存上限 2-4GB，分片缓冲 + 解码状态加起来就过了。多线程在高端硬件上能扛 4K，但比原生慢 2-3 倍。
中端崩溃才是值得看的部分。就算分块处理（一次处理 N 个分片、写 OPFS、释放内存），4K TS 解封装需要大量工作内存。修复在 OPFS 流式模式——别把整个输出装进内存。
结果：8K HLS → MP4 重封装（10 分钟视频，4GB）
| 方案 | Mac (M2) | Win (i7) | 中端 (Ryzen) |
|---|---|---|---|
| 原生 FFmpeg | 42s | 65s | OOM |
| FFmpeg WASM 单线程 | OOM | OOM | OOM |
| FFmpeg WASM 多线程 | OOM（3.1GB 时崩） | OOM（3.4GB 时崩） | OOM |
结论： 2026 年的 FFmpeg WASM 扛不了 8K。4GB 单实例内存上限是硬墙。就算分块流式，8K HEVC TS 解封装需要同时持多个 100MB+ 分片做 PTS 重排。
这是已知限制。提案中的 WASM memory64 规范会把它升到 64 位寻址，但 2026 年还在 Chrome 的 flag 后面，Firefox/Safari 没有。
结果：DASH 重封装（无 TS 解封装）
同样的 1080p/4K 内容但 DASH 源（fMP4 分片，不需要解封装）：
| 方案 | Mac (M2) 1080p | Mac (M2) 4K |
|---|---|---|
| 原生 FFmpeg | 4s | 18s |
| FFmpeg WASM 单线程 | 12s | 70s |
| FFmpeg WASM 多线程 | 6s | 25s |
| 纯 JS 拼接（不用 FFmpeg） | 2s | 12s |
结论： DASH 快得多，因为没有解封装步骤——重封装那篇 讲为什么。纯 JS 拼接（完全不用 FFmpeg）对 DASH 可行，跑到接近内存带宽极限。
这就是为什么 FlowPick 的 DASH 路径比 HLS 路径快——HLS 要解 MPEG-TS，DASH 不用。
结果：解码 + 抽帧（30 分钟 1080p 抽 1800 帧）
| 方案 | Mac (M2) | Win (i7) | 中端 (Ryzen) |
|---|---|---|---|
| 原生 FFmpeg | 18s | 24s | 52s |
| FFmpeg WASM 单线程 | 145s | 180s | 320s |
| FFmpeg WASM 多线程 | 52s | 68s | 130s |
| WebCodecs + Worker | 31s | 38s | 85s |
| WebCodecs + Worker 池（4 worker） | 12s | 16s | 35s |
结论： WebCodecs 加 worker 池是浏览器最快的方案——高端硬件上在原生的 2 倍以内。硬件加速真有差。中端硬件上 FFmpeg WASM 多线程跟 WebCodecs 单 worker 相当，因为 Ryzen 5 5500U 的 GPU 弱。
worker 池的扩展性重要：4 worker 比 1 worker 快约 2.5 倍（亚线性，因 GPU 争用）。8 worker 没多大用——GPU 在 4-6 路并发解码就饱和了。
结果：浏览器对比（Mac M2，1080p 重封装）
| 浏览器 | FFmpeg WASM 单线程 | FFmpeg WASM 多线程 | WebCodecs |
|---|---|---|---|
| Chrome 127 | 75s | 22s | 31s |
| Firefox 127 | 92s | n/a（无 pthreads） | n/a（无 WebCodecs） |
| Safari 17.5 | 88s | n/a（无 pthreads） | 35s（codec 支持有限） |
结论： Chrome 是唯一所有方案都能跑的浏览器。Firefox 同时缺 WASM pthreads 和 WebCodecs（2026 年中 WebCodecs 还在 flag 后面）。Safari 有 WebCodecs 但 codec 支持有限（无 AV1，VP9 有限）。
这就是为什么 FlowPick 推荐 Chrome——见 v1.0.0 发布说明。
内存使用
峰值内存（Chrome 127、Mac M2、1080p 重封装）：
| 方案 | 峰值内存 | 说明 |
|---|---|---|
| 原生 FFmpeg | 80MB | 基线 |
| FFmpeg WASM 单线程 | 220MB | WASM 开销 + 分片缓冲 |
| FFmpeg WASM 多线程（8 线程） | 280MB | + 8 个 worker 上下文 |
| WebCodecs + Worker | 95MB | 硬件加速用 GPU 内存，不占主存 |
4K 重封装峰值内存翻倍到约 500MB（FFmpeg WASM 多线程）——还在浏览器标签页 2GB 软上限内，但够近，可能要关其他标签页。
内存曲线影响体验。4K 重封装让 8GB 机器的标签页崩是糟糕体验。FlowPick 的分块处理（一次处理 50 个分片、写 OPFS、释放内存）让 4K 的峰值内存也压在 300MB 以内。
流式下载基准
分片本身能下多快？这是网络瓶颈部分。
测试：300 个分片、每个约 1.7MB、共 500MB、来自 CloudFront CDN。
| 并发 | 实际耗时 | 有效带宽 |
|---|---|---|
| 1 | 145s | 3.4 MB/s |
| 4 | 38s | 13.2 MB/s |
| 6 | 26s | 19.2 MB/s |
| 8 | 22s | 22.7 MB/s |
| 12 | 21s | 23.8 MB/s |
| 16 | 24s | 20.8 MB/s（更慢——被限速） |
结论： 6-8 个并发连接是甜点。超过这个数 CDN 开始按 IP 限速。FlowPick 默认 6。
"有效带宽"被 CDN 卡，不是被浏览器卡。无限并发也跑不过 CDN 允许的上限。
方法论细节
预热： 每个测试跑两次；第一次丢掉（WASM 编译、JIT 预热等）。
电源： 笔记本插电、性能模式。电池模式 Mac 降频约 30%、Windows 约 50%。
其他标签页： 无。后台标签页抢 CPU/内存。
散热： 所有笔记本放在散热垫上。热降频是真的——没主动散热，持续 4K 重封装 5 分钟后掉 15-20%。
FFmpeg 参数： -c copy -f mp4 -movflags +faststart 做重封装。无滤镜、无转码。
WASM 版本： @ffmpeg/core 0.12.10，多线程版配 CORE_THREADS=8。COEP/COOP 头正确设置以支持 SharedArrayBuffer。
这些数字意味着什么
1080p 内容（最常见）： 浏览器扛得住。FFmpeg WASM 多线程 30 分钟 1080p 在 22-65 秒，看硬件。能用 WebCodecs 更快。原生快 2-3 倍但要安装。
4K 内容： 高端硬件（16GB+ RAM、近期 CPU）上浏览器扛得住。中端硬件挣扎。分块处理是必须的。
8K 内容： 2026 年浏览器扛不住。等 memory64 WASM 或者用原生。
解码密集型（抽帧、分析）： WebCodecs 加 worker 池是明显赢家。好硬件上在原生 2 倍以内。
广泛 codec 支持： FFmpeg WASM。WebCodecs 限于浏览器支持的 codec（H.264、H.265、VP9、AV1——每个浏览器有 caveat）。
我的看法：浏览器对 90% 场景够用
"浏览器做不了真视频处理"这话过时了。1080p 重封装和解码——覆盖绝大多数真实使用——现代硬件跑 Chrome 浏览器视频处理在原生的 2-3 倍以内。够快了，几秒的延迟差（30 分钟视频多等几秒）远不如工作流的差（不装、不配 PATH、不装 FFmpeg）重要。
剩下 10%——中端硬件上的 4K、任何地方的 8K、稀有 codec——还得原生。这没关系。什么活用什么工具。
FlowPick 的赌注：浏览器里优化 90% 场景，剩下 10% 给"用 yt-dlp"的建议。FlowPick vs. yt-dlp 对比 讲什么时候用哪个。
参考资料
- FFmpeg WASM 文档 — 设置和线程配置
- WebCodecs 浏览器支持 — 兼容性表
- Memory64 提案 — 提升 WASM 4GB 内存上限的提案
小结
浏览器视频处理对 1080p 工作负载在任何现代硬件上都可行，4K 在高端硬件上可行。8K 在 WASM 出 memory64 之前不可行。FFmpeg WASM 多线程是最好的通用工具；WebCodecs 加 worker 在解码密集型任务上更快但受 codec 限制。
这里的方法论可复现——测试文件在参考资料里链接，FFmpeg 参数列了，硬件指定了。你的工作负载不同，用同样模式自己跑测试。
支撑这些数字的实现模式，看 WebCodecs 那篇 和 重封装那篇。你能处理什么的法律考量，看 流媒体下载合法性指南。
推荐阅读
- WebCodecs + Web Workers + OPFS：浏览器视频处理实战 — 这里测的实现模式
- 浏览器端视频重封装：fMP4、ISOBMFF 和不转码的理由 — 重封装为什么快、转码为什么不快
- FlowPick 是怎么在浏览器里把几百个视频切片合成 MP4 的 — FlowPick 具体实现
- FlowPick vs. yt-dlp — 浏览器还是原生的选择时机
- HLS 深度：加密、多音轨、值得记住的 EXT-X 标签 — 这里做基准的 HLS 格式
- FlowPick v1.1.0：更聪明的媒体检测 — 加上分块处理大文件的那个版本