WebAssembly 影片壓縮：瀏覽器端 FFmpeg 編碼技術解析

當我們談論「ffmpeg in browser」時，多數人想到的是能在網頁壓縮影片的便利工具。但從系統架構師的角度，這代表一場典範轉移：WebAssembly（WASM）正在打破瀏覽器與原生應用程式（Native App）之間的效能壁壘。

這篇文章從編譯器原理、記憶體管理模型，以及分散式系統成本結構三個維度，解剖這項技術的工程本質。如果你正在評估「是否該將影片處理流程從伺服器端遷移至瀏覽器端」，這將是一份具備實務參考價值的技術評估報告。

為什麼 JavaScript 無法勝任影片編碼這類重型運算？

在討論 WASM 之前，必須先理解瀏覽器原生語言的限制。

JavaScript 作為一門直譯式語言（Interpreted Language），其執行流程需經過詞法分析（Lexing）、語法解析（Parsing）、生成 AST，再交由 JIT 編譯器轉為機器碼。這個過程對於 DOM 操作、事件處理等輕量級任務游刃有餘，但面對 H.264/H.265 編碼這類需要大量浮點運算與記憶體操作的場景時，JS 的執行效率會呈現指數級衰減。

更具體地說，FFmpeg 這類以 C/C++ 撰寫的編碼器，高度依賴：

指標運算與手動記憶體管理
SIMD 指令集加速（如 SSE、AVX）
多執行緒平行處理（pthread）

這些特性在傳統 JS 執行環境中要不就是無法實現，要不就是透過抽象層模擬後效能大打折扣。

WebAssembly 的架構本質：接近原生的 Bytecode 執行層

WebAssembly 並非「另一種 JavaScript 的替代語言」，而是一個獨立於硬體的虛擬指令集架構（Stack-based Virtual ISA）。

從編譯鏈的角度理解 WASM

當我們將 FFmpeg 的 C 原始碼透過 Emscripten 編譯為 .wasm 模組時，實際上發生的是：

前端編譯：Clang 將 C/C++ 編譯為 LLVM IR（Intermediate Representation）
後端編譯：Emscripten 的 LLVM Backend 將 IR 轉換為 WASM Bytecode（Binary Format）
執行階段：瀏覽器的 WASM VM（如 V8 的 Liftoff / TurboFan 管線）將 Bytecode 編譯為目標架構的機器碼（x86_64 / ARM64）

這個流程的關鍵在於：WASM 在進入瀏覽器前已經是編譯完成的低階中間碼，瀏覽器只需執行「機器碼生成」這最後一哩路，而非從高階語言開始直譯。這使得 WASM 的執行速度能達到原生程式（Native）的 90~95%，遠遠超越 JS 的效能天花板。

線性記憶體模型（Linear Memory）

WASM 採用一個可擴展的 ArrayBuffer 作為其線性記憶體空間。與 JS 的 GC（Garbage Collection）不同，WASM 模組內部可以進行手動的記憶體配置與釋放（透過 malloc / free），這對於 FFmpeg 這種需要精確控制記憶體對齊（Memory Alignment）與緩衝區複用的編碼器至關重要。

技術挑戰：將 FFmpeg 移植到瀏覽器的工程難題

將一個擁有百萬行 C 程式碼、依賴數十個系統函式庫的專案編譯為 WASM，絕非單純的 emmake make 就能解決。以下是實務上必須攻克的核心技術關卡：

1. 系統呼叫的抽象與模擬（System Call Emulation）

FFmpeg 高度依賴 POSIX API（fopen、mmap、pthread_create）。然而瀏覽器的 WASM 執行環境是一個嚴格的沙盒（Sandbox），不允許直接存取檔案系統或作業系統執行緒。

解決方案是透過 Emscripten POSIX Emulation Layer：

檔案系統操作被重新導向至瀏覽器的 MEMFS / IDBFS / WORKERFS 虛擬檔案層
標準輸出入（stdin/stdout）被橋接至 JS 的 console 或自訂的 callback
網路協定（如 http、https）透過 Emscripten Fetch API 代理

這意味著工程師必須仔細設計 C 程式碼與 JS Host Environment 之間的邊界介面（ABI），確保資料封包在跨語言邊界（FFI, Foreign Function Interface）時的序列化開銷最小化。

2. 多執行緒與 SharedArrayBuffer

現代影片編碼（尤其是 H.265/HEVC 與 AV1）幾乎不可能在單執行緒內即時完成。WASM 的多執行緒支援依賴於 SharedArrayBuffer 與 Web Workers 的協作：

主執行緒（Main Thread）：負責 UI 渲染與 WASM 模組的載入
Worker 執行緒：承載實際的 FFmpeg 編碼任務
SharedArrayBuffer：作為跨執行緒的零複製（Zero-copy）記憶體共享區塊

這裡存在一個瀏覽器層級的安全性門檻：由於 Spectre 漏洞的歷史因素，**跨來源隔離（Cross-Origin Isolation）**成為啟用 SharedArrayBuffer 的前提。站點必須正確配置以下 HTTP Response Headers：

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

這是許多「號稱支援瀏覽器端編碼」的服務所忽略的基礎建設細節。

3. 記憶體上限與 32-bit 定址空間

在 32-bit WASM 模式下，線性記憶體的上限為 4GB。對於處理 4K 影片或長時段影片串流的場景，工程師必須實作分段處理（Chunked Processing）或串流式編碼（Stream Encoding），而非一次性將整個影片載入記憶體。

Client-side Encoding 的系統架構優勢

從分散式系統與雲端成本的角度來看，將影片編碼從 Server-side 遷移至 Client-side 並非單純的「技術炫技」，而是一個具備明確 ROI（投資報酬率）的架構決策。

1. 後端運算成本歸零（Zero Backend Compute）

傳統的 SaaS 影片處理流程遵循以下路徑：

使用者上傳原始檔 → 經由 CDN 傳輸至應用伺服器 → 轉發至轉碼叢集（FFmpeg on EC2/GKE）→ 等待編碼完成 → 回寫至物件儲存（S3/GCS）→ 提供下載連結

在這個模型中，無論使用者上傳的是 10MB 還是 1GB 的影片，雲端供應商都會按照「傳輸頻寬 + 運算時間 + 儲存空間」三個維度計費。對於高頻使用的服務，轉碼叢集的 Auto-scaling 成本往往是營運支出的最大黑洞。

Client-side Encoding 將運算圖完全反轉：

使用者選擇本地檔案 → 瀏覽器載入 WASM 模組 → 本地執行編碼 → 直接輸出壓縮後檔案

後端在此流程中的角色僅剩「提供靜態資源（.wasm、.js loader）」，運算負載與記憶體消耗完全由使用者的終端設備承擔。對於新創團隊或獨立開發者而言，這意味著幾乎為零的邊際營運成本（Near-zero Marginal Cost）。

2. 資料隱私的終極解決方案

在 Server-side 模型中，即便服務商宣稱「處理完成後立即刪除檔案」，使用者仍然必須承擔「傳輸過程中的中間人攻擊（MITM）」與「伺服器端資料殘留（Data Residue）」的風險。

WASM-based Client-side Processing 從物理層根除了這個信任假設：

影片位元流（Bitstream）從未離開使用者的記憶體空間
不需要 TLS 傳輸加密（因為沒有網路傳輸）
不需要伺服器的資料處理協議（DPA）合規認證

這對於處理醫療影像、法律證據影片、或企業內部機密訓練教材的場景，具有不可替代的合規價值。

3. 延遲與可用性的質變

Server-side 編碼存在一個無法迴避的排隊延遲（Queueing Delay）。當併發使用者激增時，即使系統具備 Auto-scaling，冷啟動（Cold Start）時間也可能長達數十秒。

相對地，Client-side Encoding 的延遲模型僅取決於：

本地 CPU 的單核心 / 多核心效能
WASM 模組的初始載入時間（可透過 Streaming Compilation 與 Cache 優化至毫秒級）
影片本身的複雜度

一旦模組載入完成，編碼過程是立即（Instant）開始的，不存在網路來回（Round-trip）與伺服器排隊的變因。

技術實現的權衡與邊界

儘管 Client-side Encoding 具備上述優勢，身為架構師必須清楚認知其適用邊界：

評估維度	Server-side Encoding	Client-side WASM Encoding
運算成本	高（隨用量線性增長）	趨近於零（由客戶端承擔）
資料隱私	需信任服務商與傳輸鏈路	最高（檔案不離開本地）
延遲特性	受網路與佇列影響	即時開始，僅受本地硬體限制
支援格式	完整（可掛載任意編解碼器）	受限於 WASM 編譯體積與授權
多檔批次處理	容易擴展	受瀏覽器記憶體與分頁生命週期限制
離線可用性	不可行	可行（PWA + Service Worker）

這張對照表說明了 WASM 編碼並非萬靈丹。對於需要批次處理數百個影片、或必須使用專利編解碼器（如特定授權的 H.265 實作）的企業級場景，混合架構（Hybrid Architecture）—— 即前端預處理（Pre-processing）結合後端精加工（Fine-processing）—— 可能是更務實的選擇。

總結：Web Computing 的下一個紀元

WebAssembly 不僅是一項瀏覽器新技術，它代表著運算範式的去中心化（Decentralization of Computation）。當我們能夠在瀏覽器內以接近原生的效率執行 FFmpeg 這等級的媒體框架時，「Web App」與「Native App」的界線已經實質上被抹除。

對於開發者與產品架構師而言，這意味著：

我們可以重新審視「哪些運算真的必須發生在雲端」
我們可以將資料主權（Data Sovereignty）還給終端使用者
我們可以建構出無伺服器（Serverless）卻非無運算（Not Compute-less）的新一代應用

Squishyfile 的技術選型正是基於這樣的架構信念：透過 WASM + FFmpeg 的組合，在瀏覽器內完成影片壓縮的完整閉環。沒有上傳、沒有等待、沒有隱私疑慮—— 只有純粹的本地運算力被喚醒。

這是 Client-side Encoding 的現在進行式，也是 Web 技術的未來。