選擇正確的影片壓縮方法，首先要讓預設對齊目標，而不是追求一個通用的數字。一段 12 秒、要放進電子郵件回覆的螢幕錄影、一段五分鐘、要放進簡報的錄影畫面，以及一段想在 4K 螢幕上保持清晰畫質的假日影片，三者並不共享同一個檔案大小上限，把它們當成有共同上限來處理，正是壓縮嘗試「感覺不對」最常見的原因。正確的方法，是其權衡取捨能對齊檔案下一個去處的方法，而像 Video Compressor 這樣的本地瀏覽器工具，透過明確提供三個預設（而不是一整面滑桿），把這個選擇講清楚。該工具會將來源重新編碼成 WebM 檔案，然後回報實際的輸入與輸出位元組，以及帶正負號的百分比變化，因此決策依據是真實結果，而不是行銷說詞。
把壓縮目標對齊到正確的預設
任何壓縮任務的第一個決定，就是目的地。嚴格的即時通訊和電子郵件附件上限只有個位數 MB；大多數簡報和社群上傳則可接受中等大小、在筆電上看起來仍然清晰的檔案；而個人典藏或大螢幕觀看，則值得用更寬鬆的輸出與更高的影格率。把預設對應到那個目的地，正是把壓縮從憑感覺變成可衡量步驟的關鍵。
Video Compressor 中的每個預設都帶有公開的寬度上限、影格率目標，以及一個有界線的每像素位元數（bpp）啟發式，錄製器會用它來挑選影片位元率，範圍限制在 180 kbps 到 8 Mbps 之間。錄製器會將播放中的來源編碼成 WebM 檔案，並在執行結束時回報實際的位元組數。
| 預設 | 寬度上限 | 影格率 | 位元率策略 | 典型目的地 |
|---|---|---|---|---|
| Small | 640 px（絕不放大） | 24 fps | bpp 啟發式，限制在 180 kbps–8 Mbps | 電子郵件附件、有嚴格上限的即時通訊 |
| Balanced | 1280 px（絕不放大） | 30 fps | bpp 啟發式，限制在 180 kbps–8 Mbps | 一般觀看、簡報、大多數社群上傳 |
| Quality | 1920 px（絕不放大） | 30 fps | bpp 啟發式，限制在 180 kbps–8 Mbps | 可播放的典藏、大螢幕、第二輪觀看 |
每個預設都保留來源長寬比、絕不放大來源，並把輸出尺寸向下取整到偶數像素值，以便編解碼器有更廣的相容性。預設名稱是誠實的產品選擇，而不是保證其中任何一個在所有情境下都是最佳。
先比對來源與硬限制
在挑選預設之前，請先確認來源真的能被解碼。該工具接受副檔名為 MP4、WebM、MOV、M4V 或 Ogg 的檔案，但能否成功解碼仍取決於目前瀏覽器中安裝的編解碼器。一個有效的副檔名無法讓不支援的編解碼器變得可解，因此能在桌面播放器開啟的檔案，到了這裡仍可能被打回票。一旦發生這種情況，工具會產生錯誤且不會提供下載，所以不會有任何東西被悄悄截斷。
輸入本身也受到限制，讓瀏覽器能即時完成執行。有效的來源必須在五分鐘（300 秒）以內解碼完成、檔案大小不超過 500 MiB、任一邊長不超過 4096 像素，且解碼後的總像素不超過 3840 × 2160。這四項限制綁定了記憶體、Canvas 配置，以及驅動錄製器的即時工作量，超出任何一項的檔案會在編碼開始前就被拒絕。
如果來源逼近這些邊界之一，先做裁切通常比硬壓來得合適。Video Trimmer 以同樣的不上傳模式在本地處理一個有界線的片段，因此來源會留在裝置上，而壓縮器在較小的片段上也更有發揮空間。
逐步壓縮本地影片
- 選擇一個可在瀏覽器解碼、符合 500 MiB、解碼長度五分鐘以內、以及解碼後 3840 × 2160 像素限制的影片。
- 依據目的地選擇 Small、Balanced 或 Quality，然後開始壓縮。在來源以即時速度播放期間請保持分頁開啟，因為編碼器觀察的是播放中來源的 Canvas 串流，所以一段兩分鐘的片段大約需要兩分鐘才會跑完，而不是瞬間完成。
- 執行結束時，檢視回報的輸出尺寸、輸入位元組、輸出位元組，以及帶正負號的百分比變化。下載 WebM 並完整播放，在刪除原檔之前確認大小、長度、畫面與聲音都符合需求。
變更預設、選擇新檔案，或在執行中途離開頁面，都會讓目前的工作失效，並釋放工具所建立的暫存 Object URL。新的執行一律從乾淨的狀態開始，而錄製器以來源播放時間為進度依據，而不是用時鐘猜測。
為什麼輸出有時會比輸入大
壓縮效果取決於內容，「較小」的預設是限制條件，而不是保證。低動態的螢幕錄影或純色動畫，在任何預設下通常都能大幅壓縮，因為大部分畫面都保持不變。雜訊高的影片、底片顆粒、劇烈的手震、快速變化的細節，或是本身已經編碼得很有效率的來源，則可能產生與輸入大小相近、或在某些情況下略大於輸入的輸出。
回報的百分比只根據兩個實際 Blob 的大小計算，所以工具絕不會把變大的檔案標示為縮減。當數字不符合目的地時，正確的做法是改試另一個預設，通常是寬度限制更緊、影格率目標更低的那個，再讀取新的位元組數。即使是 Small 預設也無法把檔案壓到目標大小以下時，可能需要先裁切或調整來源尺寸，壓縮才有發揮空間。預設、動態與雜訊之間的關係是定性而非定量的，所以精確的位元組數永遠來自工具本身，而非任何預先計算的估計。
若想了解瀏覽器錄製在不同引擎上的行為，可以參考 MDN MediaRecorder documentation，其中說明了錄製器如何從目前瀏覽器回報的項目中挑選 MIME 類型，這也是為什麼同一個預設在不同瀏覽器可能產生略有不同的檔案。
瀏覽器壓縮器不適用的情境
當目的地是日常播放、分享，或只是快速縮減上傳體積時，本地瀏覽器壓縮是正確的做法。當輸出必須符合精確規格時，它就不適合。典藏母檔、專業交付格式、嚴格的編解碼器設定檔、兩階段速率控制、固定關鍵影格間隔、字幕保留，或可重現的跨平台輸出，這些都需要像 FFmpeg 這樣有維護、且具備審核過指令的桌面編碼器，而不是預設驅動的瀏覽器流程。
有兩個結構性限制讓這項區別無可避免。錄製器會從目前瀏覽器回報的編解碼器中挑選，優先 VP9，其次 VP8，再來是通用的 WebM，因此即使預設和來源相同，輸出容器與編解碼器仍可能因瀏覽器不同而有所差異。WebM 是唯一的輸出容器，因為瀏覽器對 MediaRecorder 產生的 MP4 支援仍然不一致。音訊只有在瀏覽器透過 HTMLMediaElement captureStream 開放可擷取軌道時才會被納入，因此驗證下載檔案的畫面與聲音都是流程的一部分，而不是額外步驟。
本地處理讓每個位元組都留在你的裝置上
壓縮器會在目前分頁內完成所有動作：解碼所選的檔案、將每個顯示的畫面繪製到有界線的 Canvas、以瀏覽器的 MediaRecorder 錄製該串流、解析 Segment Info 與 TimestampScale 以插入以 timestamp-scale 刻度表示的 Matroska Duration 浮點數、計算帶正負號的位元組變化，並提供產生的 Blob 供下載。不會有任何影片位元組、縮圖、長度、檔名、編解碼器中繼資料或結果離開裝置。當來源含有音訊時，在即時處理期間會以可聽見的方式播放，因此可視需要使用裝置音量，但不要以為靜音對擷取軌道沒有影響。
想更深入了解相關的陷阱，可以參考 Video Compressor Tips and Common Mistakes to Skip 指南，其中涵蓋了第一次使用時容易遇到的具體失敗模式。在完整下載並播放、確認大小、長度、畫面、聲音與相容性都符合目的地之前，請先保留原檔。一旦確認完成，正確的方法就是那個第一次就產出可用檔案的方法，而同一個預設可以重複用於下一段要去同一個地方的影片。
延伸閱讀：How to Compare Approaches to Video Compression Locally。