基於瀏覽器的影片壓縮工具會輸出 WebM,因為底層的 MediaRecorder API 對 WebM 的支援遠比對瀏覽器產生的 MP4 來得穩定。當你選擇來源並挑選例如 Small、Balanced 或 Quality 等預設值時,頁面會把每個顯示的影格繪製到一個有邊界範圍的 HTMLCanvasElement 中,對該畫布呼叫 captureStream(),然後把產生的 MediaStream 交給 MediaRecorder。該錄製器會向瀏覽器要求一種 MIME 類型——先是 VP9,接著是 VP8,再來是通用的 WebM——瀏覽器則回傳它實際支援的組合。MediaRecorder 對 MP4 錄製的支援雖然存在於某些瀏覽器中,但在不同版本與平台間仍不一致,所以一個完全在頁面中執行的工具無法承諾一定可以輸出可用的 MP4。選擇 WebM 能讓整個管線保持可預測:相同的輸入、相同的預設值、相同的頁面,就能在每個現代瀏覽器中產出一個可下載、可播放的檔案,即使容器內實際使用的編解碼器會因引擎而異。

why is the output webm instead of mp4 when i use video compression
為什麼影片壓縮的輸出是 WebM 而不是 MP4

瀏覽器管線如何決定採用 WebM

你每次在不上傳檔案的情況下進行的瀏覽器端重新編碼,都依賴同樣的三個基礎元件:一個已解碼的影片元素、一個負責繪製你所見內容的畫布,以及一個把畫布串流寫入可下載 Blob 的錄製器。第一個元件很單純——你把 HTML video 元素指向一個瀏覽器能解碼並播放的本地檔案。第二個元件是 HTMLCanvasElement.captureStream(),它會把畫布當下正在繪製的內容轉成一個即時的 MediaStream。第三個元件是 MediaRecorder API,它會把該串流編碼,並把結果以 Blob 的形式提供給你儲存。

MP4 會在第三個元件這裡出局。MediaRecorder 會向瀏覽器要求一種 MIME 類型,瀏覽器則以它實際支援的第一組編解碼器與容器組合來回應。VP9 搭配 WebM 已經被廣泛實作;VP8 搭配 WebM 的實作更為廣泛;而使用瀏覽器所提供之任意音訊編解碼器的通用 video/webm,則是最普遍的退路選項。相比之下,由瀏覽器產生的 MP4 錄製功能,直到近期才在某些引擎中出現,即便如此仍仰賴並非隨時可用的硬體編碼器。網頁並沒有任何可攜的方式預先得知哪種組合會成功,因此安全的選擇——也就是能在目前分頁中產出可下載、可播放檔案的那一個——就是 WebM。

實際上的影響是,同一個頁面、同一個來源、同一個預設值,在 Chrome、Firefox 與 Safari 之間可能會產生內部略有不同的檔案,因為每個引擎會挑選它所支援的第一個 MIME。容器名稱仍然是 WebM,但裡面的視訊編解碼器在一部機器上可能是 VP9,在另一部機器上卻是 VP8。這也是為什麼該工具所回報的百分比變化,是根據兩個實際 Blob 大小來計算,而不是根據某個理論上的目標值。

各預設值在 WebM 容器內部產生了什麼

影片壓縮工具上的三個預設值,只是關於解析度、幀率與位元率的透明產品選擇,並非宣稱存在某種通用最佳值。它們僅在編碼開始前所設定的上限有所不同,編碼器會依據來源內容在這些限制內運作。

預設值 最大寬度 目標幀率 位元率行為 典型用途
Small 640 px 24 fps 較低的每像素位元目標,限制在 180 kbps 至 8 Mbps 之間 短片,且絕對檔案大小比細節更重要
Balanced 1280 px 30 fps 中等的每像素位元目標,限制在 180 kbps 至 8 Mbps 之間 分享、預覽,以及大部分網路影片上傳
Quality 1920 px 30 fps 較高的每像素位元目標,限制在 180 kbps 至 8 Mbps 之間 播放用途,細節保留比檔案大小更重要

三種預設值都會保留來源長寬比,絕不放大來源,並把輸出尺寸向下取整到偶數像素值,以獲得更廣泛的編解碼器相容性。若你的來源是 1280 × 720,Balanced 會維持在 1280 × 720,Small 會維持在 640 × 360,而 Quality 會維持在 1280 × 720,因為 1920 比來源更寬,而此工具不會進行升頻。WebM 內部的確切位元率,接著會由一個受限的每像素位元啟發式規則來決定,該規則會同時遵守各預設值的上限,以及 180 kbps 到 8 Mbps 的全域限制。

在本機壓縮影片並下載 WebM

這個管線需要一點準備時間,接著會以即時方式執行,所以請據此安排你的分頁。

  1. 選擇一個瀏覽器可解碼的影片,大小不超過 500 MiB、長度不超過 5 分鐘,或解碼後尺寸不超過 3840 × 2160 像素。頁面在開始之前會驗證檔案、長度與解碼後尺寸;無效的檔案、不支援的編解碼器,或超過限制的長度,會產生錯誤且不會下載任何檔案。
  2. 從預設控制項中選擇 Small、Balanced 或 Quality。預設值會設定解析度上限、目標幀率,以及位元率啟發式規則所使用的每像素位元目標。
  3. 開始壓縮,並在來源以即時速度播放時保持分頁開啟。編碼會以播放速度進行,因為 MediaRecorder 會在畫布串流繪製每個影格時觀察它,因此一個兩分鐘的來源大約需要兩分鐘,而不是瞬間完成。
  4. 當來源結束後,檢視頁面上所顯示的輸出尺寸、輸入位元組數、輸出位元組數,以及帶正負號的百分比變化。該百分比僅根據兩個實際 Blob 大小計算,絕不會把較大的檔案標示為縮減。
  5. 下載產生的 WebM,在你常用的播放器中完整播放,並在刪除原始檔之前確認影像、聲音、尺寸與長度都正確。選擇新檔案、更改預設值、取消,或離開頁面,都會讓目前的工作失效,並釋放暫時的物件 URL。

每個步驟都在目前分頁中執行,不會上傳來源;無論是檔案、縮圖、長度、編解碼器或結果,都不會離開你的裝置。

WebM 輸出適合哪些用途

搭載 VP9 或 VP8 的 WebM 可在每個現代桌面瀏覽器、每個近期的 Android 瀏覽器,以及大多數現代智慧型電視與機上盒中播放。若你的目的地是你自己控制的網站、HTML5 video 元素、Discord 附件、Slack 上傳、Google Drive 預覽,或現代的學習管理系統,那麼從壓縮工具取得的 WebM 通常可以直接播放。這個容器是開放、免授權費,並專為此工具所依賴的瀏覽器內播放情境而設計。

WebM 較為吃力的情境,則是那些仍預期採用 H.264 與 AAC 之 MP4 的目的地:部分較舊的硬體媒體播放器、某些對匯入格式要求嚴格的專業剪輯套裝、少數社群媒體上傳工具,以及一些鎖定舊格式的公司內部網路。你下載的 WebM 也不是最終的交付母片——它不會保留字幕、章節、附件、旋轉標籤、色彩中繼資料,或 HDR 標記,且頁面不會對音量做正規化或混音處理。若你需要的是封存用的母片、專業的交付規範、嚴格的編解碼器設定檔、兩段式速率控制、固定關鍵影格間隔、字幕保留,或跨平台具決定性的輸出,請在 WebM 下載完成後,使用經審閱指令的 FFmpeg 等維護良好的桌面編碼器。

為什麼壓縮後的 WebM 可能比來源還大

執行後所顯示的百分比,是誠實地反映位元組數,而不是相對於某個目標值。壓縮結果取決於動態、雜訊、來源編解碼器、瀏覽器編碼器與預設值,所以一段低動態的動畫可能會大幅縮小,而嘈雜的畫面、嚴重的顆粒、持續的攝影機晃動、快速變化的細節,或已經是高效率的 H.265 來源,則可能產生大小相近甚至更大的檔案。編碼器也受到全域 180 kbps 到 8 Mbps 限制,以及預設值上限的約束,這代表一個已經壓得很緊的來源,沒有空間在不犧牲可見品質的情況下進一步壓縮。當結果不符需求時,請嘗試其他預設值,或先用 影片裁剪工具 裁切掉靜態片段後再壓縮,或在 WebM 下載完成後,以明確的速率控制透過 FFmpeg 處理來源。

在刪除來源之前,應在下載的 WebM 中確認哪些事項

請務必在你最在意的裝置或服務上,完整播放下載的檔案並包含聲音。確認輸出尺寸符合頁面所顯示的數值、長度與來源一致、來源有音訊時輸出也有音訊,以及位元組的變化符合你的實際需求。音訊只有在瀏覽器透過來源元素公開出可擷取軌道時才會被包含,所以無聲的輸出未必是錯誤——它可能代表目前瀏覽器未對該檔案公開音訊 MediaStreamTrack。若 WebM 比來源大,那也不一定是錯誤;它只是編碼器在選定預設值與目前瀏覽器可用編解碼器下所產出結果的誠實測量。解碼、畫布繪製、MediaRecorder 編碼與下載,全都發生在目前的瀏覽器分頁中,而原始檔在裝置上唯一仍未刪除的複本,就是你自己尚未刪除的那一份,因此在刪除任何東西之前,請徹底驗證輸出。

若你正在權衡各種選項,使用影片壓縮後該檢視哪些事項對此有詳細說明。

若你正在權衡各種選項,何時該使用影片裁剪而非手動裁切對此有詳細說明。