外觀不佳的壓縮影片，幾乎都是來源素材的預設選擇錯誤，而非編碼器損壞，最快的修正方法是在本機以不同的預設重新編碼檔案，同時將回報的輸出尺寸與位元組變化與原始檔案進行比對。壓縮是以細節換取大小，瀏覽器型壓縮工具上的每個預設都會在固定範圍內限制寬度、影格率和位元率。當結果看起來不對時，原因通常可縮小到三個之一：預設對來源內容過於激進、瀏覽器的編碼器產生了不同於其他瀏覽器的輸出，或是該檔案在不出現可見損失的前提下確實無法再壓得更小。影片壓縮工具透過在本機重新執行編碼、顯示實際的輸出尺寸、列出輸入與輸出的位元組，並印出兩者之間測得的百分比變化，來處理上述每一種情況。由於沒有任何東西會被上傳，因此你可以依序嘗試每個預設，並在同一個瀏覽器分頁中比較下載的檔案，再決定要保留哪一個。
為什麼壓縮後的結果會看起來錯誤
壓縮過程後，幾乎每個「這看起來不對」的反應都可歸納為三個原因。第一是預設不符：充滿畫面晃動、顆粒或快速動作的影片片段，需要比預設配置更多的位元率，因此編碼器會維持較大的宏區塊，導致畫面變得模糊或出現方塊。第二是瀏覽器編碼器的行為：該工具會根據瀏覽器回報的支援情況，依序嘗試 VP9、VP8，再嘗試通用的 WebM，因此相同的預設套用於相同的來源，在 Chrome、Firefox 與 Safari 中可能會產生明顯不同的位元組大小。第三是來源上限：一個已經有效率的編碼（例如近期的 HEVC 編碼）可能已接近其資訊量的極限，任何重新編碼都會加入封裝額外負擔並採用不同的編碼，這可能會使檔案變大或僅略微變小。
第四個較不明顯的原因會在下載之後、而非壓縮過程中出現。WebM 容器不會保留字幕、章節、附件、旋轉標籤、HDR 訊號，或許多色彩中繼資料欄位。如果你的目標用途需要這些欄位，而輸出檔案能播放但看起來「不對」——方向錯誤、字幕缺失、高光褪色——那麼問題在於缺少中繼資料，而非編碼不良。聲音的可聞性也是類似的陷阱：該工具只有在瀏覽器透過媒體元素擷取方法公開可擷取的音軌時，才會包含音訊，因此當來源有音訊但輸出卻是靜音時，通常代表瀏覽器無法路由該音軌進行擷取，而非編碼器將其捨棄。
影片壓縮工具實際控制的項目
每個預設都是一組有界限的編碼選擇，而非對結果大小或品質的普遍承諾。Small 將寬度上限設為 640 像素，並以 24 fps 為目標。Balanced 將寬度上限設為 1280 像素，並以 30 fps 為目標。Quality 將寬度上限設為 1920 像素，並以 30 fps 為目標。每個預設都會保留來源的長寬比、永不放大來源，並將輸出尺寸向下取整為偶數像素值，以獲得更廣泛的編碼相容性。接著，工具會從每像素位元數的啟發式規則中挑選一個目標位元率，並在交給錄製器之前將該請求限制在 180 kbps 至 8 Mbps 之間。
| 預設 | 最大寬度 | 目標影格率 | 位元率範圍 | 最適合用途 |
|---|---|---|---|---|
| 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（已限制） | 值得盡量保留原始細節的來源 |
每個預設共享同一個已限制的位元率範圍這件事，在結果看起來錯誤時很重要：切換預設改變的是像素預算，而非位元率上限，因此在 Quality 預設下的嘈雜 4K 來源仍會被限制在 8 Mbps，這對該內容而言可能仍然太少。關於預設選擇如何影響品質的完整討論，請參閱壓縮影片時如何選擇品質，而回報百分比的意義則在影片壓縮工具的準確度：它實際回報的內容中說明。
使用影片壓縮工具修正不佳的結果
無論先前的輸出是過於模糊、過小、形狀錯誤，或比來源更大，都可使用以下工作流程。
- 在瀏覽器分頁中開啟影片壓縮工具，並選擇原始來源檔案。該工具接受 MP4、WebM、MOV、M4V 與 Ogg 等副檔名，但實際解碼仍取決於目前瀏覽器中安裝的編碼，因此有效的副檔名無法挽救不支援的編碼。
- 確認來源符合公開的限制——最大 500 MiB、最長 5 分鐘、任一邊最長 4096 像素，解碼區域不超過 3840 × 2160。任何超出這些限制的情況都會產生錯誤且不會下載，這本身就是一個有用的診斷訊號。
- 選擇一個與產生不佳輸出時不同的預設。若 Small 看起來過於模糊，請嘗試 Balanced。若 Balanced 看起來清晰但卡頓，請嘗試 Quality。若 Quality 看起來幾乎與來源相同，但幾乎沒縮小，請嘗試 Balanced。
- 開始壓縮，並在來源以即時速度播放時保持分頁開啟。由於編碼會在影片播放的同時觀察 Canvas 串流，因此兩分鐘的來源大約需要兩分鐘，而非瞬間完成。
- 讀取回報的輸出尺寸、輸入位元組、輸出位元組，以及帶正負號的百分比變化。該百分比僅根據這兩個 Blob 的大小計算，當檔案變大時，絕不會謊稱檔案縮小了。
- 下載 WebM，在瀏覽器分頁以外的播放器中完整播放，並在刪除原始檔之前，先檢查畫面、聲音、持續時間，以及與目標用途的相容性。
下載檔案中應檢查的項目
百分比是起點，而非最終裁決。對於充滿動作的片段，較大的壓縮量仍可能看起來比對談頭部畫面的較小壓縮量更差，因為位元率啟發式規則是根據像素數與影格率回應，而非動作複雜度。在媒體播放器中開啟下載的 WebM，依序確認四件事：畫面對目標用途而言足夠清晰；當來源有音訊時，音訊在整段持續時間內都能播放；該檔案能在將接收它的任何應用程式或平台中開啟；以及持續時間是有限的，而非被回報為未知。該工具會以時間戳刻度刻度插入 Matroska 持續時間值，讓播放器知道長度，但某些播放器在非標準容器上會忽略該欄位，因此請驗證而非輕信。
如果檔案比來源大，這種結果在設計上是允許的：壓縮取決於動作、雜訊、來源編碼、瀏覽器編碼器與預設，該工具會回報實際的位元組，而不會將較大的檔案重新標記為壓縮成功。在這種情況下，下一步是嘗試較小的預設，或接受來源已足夠有效率，重新編碼只會增加額外負擔而非減少。將輸出視為下一個比較點，而非最終答案，就是修正看起來錯誤之結果的核心技巧。
當預設不是正確的修正方式時
某些「錯誤」的結果根本不是預設問題。如果來源包含字幕、章節、附件、旋轉標籤或 HDR 色彩中繼資料，WebM 輸出將不會保留它們，任何預設的變更都無法將其取回。如果你需要具有固定關鍵影格間隔與精確編碼設定檔的確定性雙階段編碼——例如用於歸檔母帶或指定特定 H.264 設定檔的交付規格——那麼瀏覽器重新編碼是錯誤的工具，應該改用受維護的桌面型編碼器，例如搭配審慎指令的 FFmpeg。影片壓縮工具明確地將這種情況讓給更合適的工具，而不是假裝能涵蓋它。
方向問題值得單獨檢查。該工具不會保留旋轉標籤，因此來源中帶有旋轉標記的直立手機影片將以橫向尺寸播放，看起來會被拉伸。請在重新編碼之前，先在播放器中或於來源上修正旋轉，讓編碼從一開始就看到正確的寬度與高度。在來源中能運作但輸出中消失的字幕屬於中繼資料遺失，而非品質損失，正確的修正是將字幕重新封裝或在目標播放器或編輯器中重新製作。
可能使結果看起來錯誤的實際限制
公開的輸入限制——500 MiB、5 分鐘、每邊 4096 像素，以及 3840 × 2160 的解碼區域——的存在是為了限制記憶體、Canvas 配置，以及瀏覽器媒體錄製器的即時工作量。觸及任何一項都會產生錯誤且不會下載，而非產生截斷的檔案，這讓靜默損毀不會發生。由於錄製器會在來源播放的同時觀察 Canvas 串流，因此編碼會以來源播放的節奏執行，所以關閉分頁、選擇新檔案、變更預設或切換頁面，都會取消進行中的工作並釋放暫時性的 Object URL。
由此衍生兩個實際的後果。首先，較長的來源代表較長的等待時間：5 分鐘的影片大約需要 5 分鐘，而且分頁必須保持足夠的焦點以維持播放。其次，瀏覽器公開的編碼器決定了輸出中出乎意料的許多部分。相同的預設與來源在 Chrome、Firefox 與 Safari 中可能會產生明顯不同的結果，因為錄製器會根據瀏覽器回報的情況依序嘗試 VP9、VP8，再嘗試通用的 WebM。如果在某個瀏覽器中結果看起來錯誤，那麼使用相同預設在另一個瀏覽器中開啟相同的來源就是一個合理的診斷步驟。所有的來源位元組、解碼影格與輸出位元組在整個過程中都保留在目前分頁中，Lizely 不會收到任何影片、縮圖、持續時間、檔名、編碼或結果，這代表你可以反覆嘗試各個預設，而無需將檔案傳送到任何地方。