檔案不會離開你的裝置

最近，我花了一些時間開發了一款小工具：這是一個完全在瀏覽器中運作的影片轉檔工具，核心由 FFmpeg 驅動。為了測試它的能耐，我拿了我的 MacBook Air M3（16GB RAM）當作白老鼠，直接在 Google Chrome 上將一個舊的 AVI 檔案轉檔成 MP4。

得到的結果既好笑又在技術層面上相當迷人：計時器停在了精準的 747.44 秒（差不多是 12.5 分鐘多一點），而以低溫聞名的 M3 晶片也讓鋁合金機身摸起來明顯發熱了。

那麼，為什麼一台配備了當今市面上最強大晶片之一的電腦，僅僅為了改變一部影片的格式，就需要「滿頭大汗」地跑上超過 12 分鐘呢？在本文中，我們將剖析這個過程背後的技術邏輯，並回答最終極的問題：如果它這麼慢，為什麼我們還需要基於瀏覽器的處理工具？

1. 第一個瓶頸：Remux 與 Transcode

這次測試花費這麼長時間的最大原因，其實不是機器的問題；而是原始檔案。我選擇的是一個較舊的 AVI 格式檔案，使用的是像是 DivX 或 Xvid 這類傳統的壓縮標準（Codecs）。

在影片處理的世界裡，你必須區分兩個核心概念：

• Remux（複製 - 速度極快）： 如果你的來源影片已經使用了現代的 Codec（例如 H.264），FFmpeg 只要把影像和聲音的「核心」抽出來，然後塞進一個新的 MP4「外殼」裡就好。這個過程基本上就像是把資料從一個資料夾複製到另一個資料夾，只需要幾秒鐘的時間。
• Transcode（解碼與編碼 - 速度極慢）： 因為我的 AVI 檔案使用了與 MP4 不相容的過時標準，FFmpeg 被迫「打掉重練」。它必須先將舊影片的每一個畫格（Frame）進行 Decode（解碼），然後再把這一大堆畫格 Encode（編碼） 成現代的 H.264/H.265 標準。這種逐個像素運算的過程，非常消耗 CPU 效能。

2. 瀏覽器中 WebAssembly (WASM) 的現實面

...

網頁多媒體處理正在飛速發展。隨著 WebCodecs API 結合 WebAssembly (WASM) 的出現，利用專屬硬體在客戶端進行重度影片處理的願景終於化為現實。

但理論是一回事，這項技術在實際應用中表現如何？為了找出答案，我進行了一項高強度的壓力測試：使用一個完全在瀏覽器內運作的自訂影片壓縮工具，處理一個超過 300MB 的 1080p 檔案。測試結果提供了一堂引人入勝的技術課，揭示了現代瀏覽器如何與裝置硬體進行互動。

1. 「真實世界」的測試環境

與其建立一個無菌的基準測試環境（關閉所有應用程式、清除 RAM），我決定完全依照我們多數人日常工作的方式進行測試：

• 測試瀏覽器： Chrome 版本 150.0.7871.187（正式版本）(arm64)。
• 測試裝置： MacBook Air M3，16GB 記憶體（無風扇設計）。
• 多工處理： 瀏覽器同時開啟了 5-6 個工作分頁，並在副螢幕與 Firefox（運行 Slack）同時運作。
• 輸入資料： 來自 Computerphile 頻道的深度學術影片（"How AI 'Understands' Images (CLIP)"）。時長：18 分鐘。格式：MP4 1080p。原始大小：327MB。

這項測試的目的，是觀察當 16GB 的統一記憶體被大量多工負載共享時，WebCodecs API 能多有效且穩定地利用硬體加速 (Hardware Acceleration)。

2. 處理階段：硬體加速的威力

檔案一載入工具並啟動後，處理過程異常順暢，對其他運作中的 Chrome 分頁造成零延遲或卡頓。

這正是 WebCodecs 處理現代格式（如 MP4）的殺手級功能：與其依賴 CPU 透過軟體計算影片編碼（這很容易讓瀏覽器當機），WebCodecs API 直接呼叫電腦專屬的媒體引擎 (Media Engine) 來處理編碼與解碼任務。

由於採用無風扇設計，Mac M3 的整個底部機殼在過程中變得相當燙。這是硬體（特別是媒體引擎）被推向極限，不斷在瀏覽器環境與硬體加速器之間搬運資料緩衝區 (data buffers) 的明顯物理證據。

...