常見的影片壓縮錯誤，其實都是反覆出現的誤判——關於檔案大小、編解碼器、音訊和元資料——這些誤判會把一個看似成功的重新編碼，搞成品質更差的檔案、壞掉的檔案，甚至搞丟原始檔。最常浮現的錯誤包括：假設每個輸出檔案一定會比來源檔小、把副檔名當成容器內部編解碼器可以解碼的證據、在輸出檔還沒有完整播放過之前就刪除來源檔、忽略音訊與元資料保留的限制，以及期待瀏覽器式的壓縮能瞬間完成。這每一項都有明確的成因與明確的補救方式，而且大多要等新檔案被錄製並檢查過後才會變得明顯。
現代的瀏覽器內壓縮工具，包括 Video Compressor，都是在本地端執行，並依賴瀏覽器所回報的編解碼器支援。這樣的設計消除了上傳時間與隱私顧慮，但也代表這個工具無法修好瀏覽器解不開的來源，也無法承諾固定的壓縮百分比。接下來要談的錯誤，都是在沒預料到這些限制時撞上去所產生的。
最常出現的五個錯誤
不管是螢幕錄影、手機影片，還是下載的剪輯片段，同樣五個錯誤都反覆出現。每一個都是一個小假設，只要檔案一被錄製就會破功。
- 把壓縮當成保證會縮檔。當內容本身就壓縮得很有效率，或容器內部的編解碼器本來就很精簡時，輸出檔的大小可能與來源相近，甚至比來源更大。
- 相信副檔名而不是相信編解碼器。一個命名為 .mp4、.mov、.m4v、.webm 或 .ogg 的檔案，真正解它的是瀏覽器實際支援的那個編解碼器，而不是檔名點後面的那三個字母。
- 在輸出檔還沒有從頭到尾播完之前就刪除來源檔。一個能開啟一秒鐘的檔案，還是有可能在第九十秒時壞掉；音軌不見或掉格的狀況，也只有在完整播放一遍時才會顯現。
- 以為音訊、字幕和元資料會跟著影片一起走。瀏覽器錄製只會保留當前 API 能擷取到的內容；字幕、章節、附件、色彩標記、旋轉資訊和 HDR 訊號通常都會被捨棄。
- 期待壓縮能在瞬間完成。瀏覽器內的重新編碼會在來源播放的同時觀察它，所以一支兩分鐘的影片無論機器多快，都大約需要兩分鐘。
錯誤：以為輸出檔案一定會比較小
最常見的單一錯誤，就是把「壓縮」當成「縮小」的同義詞。它不是。壓縮是位元組與畫質之間的取捨，而這個取捨取決於畫格裡有什麼、來源先前是如何編碼的、以及瀏覽器公開了哪個錄製器。低動態的螢幕錄影可以大幅縮檔。一段帶有顆粒、晃動、快速運鏡的手持夜拍，輸出大小可能跟來源一樣，甚至比來源還大，因為編碼器被迫把位元預算花在原始畫面中本來就充滿雜訊的細節上。Video Compressor 會回報實際的輸入與輸出位元組，以及帶正負號的百分比變化，而不是把一個更大的檔案標示為「縮減」。所以當結果不如預期時，正確的做法是換另一組預設，或者接受「壓縮本來就不是這個剪輯該用的工具」。
錯誤：相信副檔名更甚於相信編解碼器
第二個錯誤是把檔名當成契約。瀏覽器解的不是檔案，而是編解碼器。一個 .mp4 檔案如果用了當前瀏覽器無法解碼的 profile，就會在校驗階段失敗並且不會產生下載。.mov、.m4v 和 .ogg 也一樣。正確的做法是先確認容器裡的編解碼器是瀏覽器能解的，因為有效的副檔名無法讓不支援的編解碼器變得可以解。當驗證失敗時，工具會產生錯誤並且不提供下載，而不是默默截斷檔案。
錯誤：在確認輸出之前就刪除來源檔
代價最高的錯誤，同時也是最容易避免的錯誤。一支能開、能播幾秒、看似正常的壓縮影片，還是有可能在播放深處掉格、失去音軌、或停在錯誤的長度。能一次抓出這些問題的檢查，就是在真正會使用它的裝置上，把下載下來的檔案從頭到尾完整播放一遍。在確認大小、長度、畫面、聲音和相容性都符合目的播放器之前，先保留原始檔，然後再刪除來源。已刪除原始檔的復原路徑不是免費重壓一次，而是檔案已經不見了。
錯誤：忘記音訊與容器元資料
許多壓縮錯誤，其實是對「影片裡面裝了什麼」而不是「影片外面長怎樣」的錯誤。音訊只有在瀏覽器透過 HTMLMediaElement captureStream API 公開出一條可擷取的音軌時才會被包含進去，而這又取決於瀏覽器和來源。字幕、章節、附件、色彩元資料、HDR 訊號和旋轉標籤都不會被瀏覽器錄製保留。若目的端需要上述任何一項，本地的瀏覽器重新編碼就不是對的工具，這時該用的是一套有在維護的桌面編碼器。
如何在本地端壓縮影片而不重蹈這些錯誤
- 選擇一支瀏覽器可解碼、不大於 500 MiB、長度不超過五分鐘、長寬各不超過 4096 像素、解碼後面積不超過 3840 × 2160 像素的影片；若來源超過任何一項限制，請先裁切或調整大小，不要期待壓縮工具自己處理。
- 依據檔案將在哪裡播放來選擇 Small、Balanced 或 Quality 預設，而不是看承諾的百分比節省；預設控制的是最大寬度、幀率，以及一個依內容而定的位元率。
- 啟動壓縮並讓分頁保持開啟，同時讓來源以即時速度播放；關閉分頁、跳到別處、或選了新檔，都會讓目前的工作失效。
- 等待工具回報實際的輸出尺寸、輸入位元組、輸出位元組，以及帶正負號的百分比變化；不要預設結果一定比較小。
- 下載 WebM 檔案，在目的裝置上從頭播完，再來考慮刪除原始檔；同時檢查畫面和聲音，並確認長度是有限的，而不是開放式無窮大。
預設取捨一覽
| 預設 | 最大輸出寬度 | 目標幀率 | 典型用途 |
|---|---|---|---|
| Small | 640 px | 24 fps | 預覽、可寄送的電子郵件附件、頁面內動態縮圖 |
| Balanced | 1280 px | 30 fps | 在聊天平台分享、網頁嵌入、大多數日常播放 |
| Quality | 1920 px | 30 fps | Full-HD 播放、較大的螢幕、重視細節更甚於位元組的場合 |
三組預設都會保留來源長寬比、永遠不會放大來源，並把輸出尺寸向下取整到偶數像素值，以取得更廣泛的編解碼器相容性。用來挑選各請求位元率的「每像素位元數」啟發法被限制在 180 kbps 到 8 Mbps 之間，任何輸出的實際大小仍然取決於畫格裡裝的內容。兩段剪輯在同一組預設、同一個解析度、同一段長度下，可能會得到差異極大的位元組數——因為一段是乾淨的動畫，另一段是充滿雜訊的手持拍攝。
什麼時候瀏覽器工具不是正確選擇
若是為了保存母帶、專業交付規格、精確的編解碼器 profile、兩段式速率控制、固定關鍵影格間隔、跨平台決定性輸出，或是字幕保留，那麼一套有在維護的桌面編碼器——例如帶著審慎指令列的 FFmpeg——才是對的工具。瀏覽器錄製以即時速度執行，輸出永遠是 WebM，而且所選的編解碼器（VP9、VP8 或通用 WebM）會依當前瀏覽器所回報的內容而定，所以同一預設套在同樣的來源上，在不同瀏覽器可能會產生不同的位元組數。這些在日常分享時都不是問題；但當目的端要求特定容器、特定 profile、或跨機器位元組完全一致的結果時，這些都是換工具的理由。
避開上述五個錯誤，大體上就是管理好期待：縮檔不是必然、副檔名不是編解碼器、輸出檔還沒播完之前原始檔都不算安全、音訊和元資料只有瀏覽器擷取得到時才會跟著走、執行時間會鏡像來源長度。把這些當成基本規則，本地的瀏覽器壓縮器就會成為一個快速、私密、用來縮減真正需要縮減之檔案的好方法。
想進一步了解，請參閱 使用影片壓縮時，哪些細節真正重要。
想進一步了解，請參閱 使用影片壓縮時，可能出什麼問題。