WebCodecs API 在瀏覽器中的極限:350MB 影片壓縮實測

在配備 16GB 記憶體的 M3 Mac 上,使用 WebCodecs API 與 WASM 進行客戶端影片壓縮的真實技術壓力測試。探索為何 350MB 的 YouTube 影片容量反而變大,以及瀏覽器端編碼的真實應用場景。


The Limits of WebCodecs API in the Browser: A 350MB Video Compression Test

網頁多媒體處理正在飛速發展。隨著 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) 的明顯物理證據。

處理架構技術說明: 為了最佳化工具效能,我設計了雙引擎 (Dual-Engine) 處理邏輯。以本次測試的 MP4 影片為例,系統會自動將處理管線導向 WebCodecs 以發揮硬體加速優勢。然而,如果你上傳 WebCodecs 不支援的傳統格式(如 .avi),工具會自動觸發備用機制 (Fallback mechanism),無縫切換到在純 WebAssembly 上運作的 FFmpeg。當此 FFmpeg 管線啟用時,CPU 必須承擔 100% 的運算負載(軟體編碼)。屆時,壓縮時間將顯著拉長,且裝置會變得真正「發燙」而不僅僅是相當燙。

The Limits of WebCodecs API in the Browser: A 350MB Video Compression Test

查看這次 MP4 測試的 DevTools 開發者工具控制台截圖,我們記錄了以下數據:

指標 測量結果
耗時 292.35 秒(約 4.8 分鐘)
原始檔案大小 326.97 MB (327.0MB)
目標大小 ~228.87 MB
實際輸出大小 352.85 MB
最佳化比例 -7.9%(檔案變大了!)

瀏覽器馬不停蹄地運作了不到 5 分鐘來完成編碼任務。但最大的反轉在於輸出大小:儘管演算法的目標檔案大小設定為 228MB,最終產出的檔案卻膨脹了近 8%。


3. 技術分析:為什麼檔案變大了?

從軟體工程的角度來看,這個「自我毀滅」的結果完美印證了一個基本原則:影片壓縮是數學,不是魔法。

這種檔案大小的差異源於兩個核心技術因素:

  • YouTube 卓越的壓縮標準: 輸入的影片是直接從 YouTube 下載的。Google 龐大的伺服器基礎設施利用了最複雜、最先進的編碼標準(如 VP9 或 AV1)來榨乾每一個位元組。原始的 327MB 檔案本質上已經達到了 1080p 內容的絕對最大壓縮極限。
  • 重新編碼的本質: 當 WebCodecs 工具運作時,它必須解碼該高度壓縮的影片串流,然後重新打包並重新編碼為標準的 H.264 格式,以確保普遍的裝置相容性。為了從一個已經被極度壓縮的來源維持同等的視覺品質,編碼器被迫分配比 YouTube 高度最佳化標準更高的位元率 (Bitrate)。不可避免的後果就是檔案變大。

瀏覽器連續進行了 292 秒的運算,只為了證明一個不可否認的事實:你無法使用標準的瀏覽器端編碼器,去縮小一個已經被 Google 價值數十億美元的伺服器極度最佳化過的檔案。


4. 結論:瀏覽器端壓縮的真實應用場景

這項測試成功證實了 WebCodecs API 在直接於瀏覽器中穩定處理相對繁重多媒體檔案的成熟度。然而,它也明確劃定了這項技術的界線。

實際上,瀏覽器端的影片壓縮工具並不是為了重新壓縮從網路上抓取下來的影片而打造的,當然更不是用來處理動輒 GB 級別的相機原始檔(如果你試圖強迫瀏覽器去完成 Premiere 或 Handbrake 等專用桌機軟體的工作,你會等到天荒地老)。

這個工具真正的威力與完美的使用場景,在於它的便利性,能瞬間打破日常的檔案大小限制。

這是為了當你剛用 iPhone 或 Android 拍了一段短片,需要立即傳送給客戶或合作夥伴,卻被 WhatsApp、Line 或標準電子郵件用戶端的微小附件限制給擋下時所準備的。對於這些未經最佳化、簡短且原始的影片,智慧雙引擎架構會在眨眼間將檔案壓縮至安全且可分享的大小。


急需透過 WhatsApp 傳送影片,卻遇到「檔案過大」的錯誤?

試著將你的檔案拖放進我們的工具中。系統會自動分析格式並觸發最佳化的硬體處理管線,在縮小檔案大小的同時保留視覺清晰度。整個編碼過程 100% 就在你的瀏覽器中進行——速度飛快、絕對安全,且完全不需要上傳到伺服器。

👉 點擊這裡使用我們的免費線上影片壓縮工具,瞬間突破檔案限制

J.Julian

J.Julian

J.Julian 是 UploadLess 的創作者兼首席開發者。他擁有深厚的軟體工程與 Web 架構背景,致力於為現代 Web 打造安全、高效能且使用者友善的檔案分享解決方案。