瀏覽器影片處理效能基準：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 還在 flags 後面）。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：更聰明的媒體偵測 — 加上分塊處理大檔案的那個版本