大多數影片壓縮問題可追溯至下列三種原因之一：瀏覽器無法解碼的輸入、檔案超出工具的硬性輸入限制(目前為 500 MiB、五分鐘，以及 3840 × 2160 像素的解碼區域)，或是來源內容擊敗你所選的預設。在更換工具之前，先改變你衡量的方式:一個本機端的重新編碼器會回報實際輸入位元組、實際輸出位元組以及最終的尺寸，讓你獲得真正的比較結果，而不是行銷標籤。Video Compressor 位於 /video/video-compressor/，正好能做到這件事——它在目前的分頁中解碼瀏覽器相容的來源，將每一幀繪製到有界 Canvas 中，透過瀏覽器的 MediaRecorder 將該串流錄製為 WebM，並回報兩個 Blob 之間的帶正負號位元組變化。因為每個步驟都在本機端執行，沒有任何內容會被上傳，你可以對同一個來源執行多個預設，並排比較數字，在不離開瀏器的情況下找出失敗的真正原因。這種診斷紀律——先測量、再比較、最後改變單一變數——正是將模糊的「影片看起來很糟」抱怨轉化為具體行動的關鍵。
最常見的影片壓縮問題
大多數的失敗可以歸入少數幾個類別，而每個類別都有其特徵性的徵兆。為問題歸類是排解工作的前半段，因為每種類別的解決方式都不同:
- 檔案在編碼開始前就被拒絕，介面上通常沒有明顯的原因。
- 壓縮執行到一半發生錯誤，並未產生下載檔案。
- 下載檔案出現了，但大小與來源相近甚至更大。
- 下載檔案在瀏器中可正常播放，但在目標應用程式中無法播放。
- 下載檔案可播放，但只有無聲影片，或音訊斷斷續續、影音不同步。
- 畫面看起來有方塊感、模糊，或與來源相比有其他畫質劣化。
選對類別最快速的方法，是將你的症狀對應到工具的行為。下表將每個可見的症狀與最可能的根本原因，以及通常能確認或排除原因的第一個檢查項目配對在一起。
| 症狀 | 最可能的根本原因 | 第一個檢查項目 |
|---|---|---|
| 檔案在編碼前就被拒絕 | 副檔名看似正確，但瀏器並未安裝該編解碼器 | 將來源拖曳到新分頁中;若無法播放，表示此處無法解碼該編解碼器 |
| 壓縮過程中出現錯誤且無下載檔案 | 來源超出硬性限制——大小、時長、單邊像素，或解碼區域 | 重新檢查 500 MiB、5 分鐘、單邊 4096 px，以及 3840 × 2160 解碼區域的上限 |
| 輸出大小與來源相近或更大 | 雜訊高、動態大，或內容本身已是高效率編碼，卻套用了不合適的預設 | 讀取工具回報的百分比變化，然後嘗試不同的預設 |
| 下載檔案播放時沒有聲音 | 瀏覽器未透過 HTMLMediaElement captureStream 公開可擷取的音軌 | 在真正的播放器中確認來源確實有音訊，然後嘗試不同的瀏覽器 |
| 下載的檔案無法在其他程式開啟 | 接收端預期使用 MP4 或特定的 H.264 profile，但錄製器產生的是 VP9 或 VP8 的 WebM | 使用 FFmpeg 轉檔，以獲得跨平台且可預測的容器與編解碼器 |
| 畫面看起來有方塊感或模糊 | 預設將寬度調降太多，小於目標裝置的顯示尺寸 | 將輸出尺寸與來源，以及目標裝置的最低需求進行比較 |
執行本機端重新編碼以隔離原因
當症狀不明確時，單一次受控的重新編碼通常能將猜測轉化為資料。重點在於一次只改變一個輸入，並讓工具回報實際的數字，因為數字不會對改變的內容說謊。
- 在目前的分頁中開啟 Video Compressor。
- 選擇一個瀏覽器可解碼的來源，大小不超過 500 MiB、時長不超過五分鐘、解碼區域不超過 3840 × 2160 像素。
- 選擇最接近你目標的預設:Small 為 640 像素最大寬度、24 fps;Balanced 為 1280 像素、30 fps;或 Quality 為 1920 像素、30 fps。
- 開始壓縮，並在來源即時播放時保持分頁開啟。編碼會以播放速度執行，因為 MediaRecorder 是觀察 Canvas 串流的，所以兩分鐘的來源大約需要兩分鐘，而不是瞬間完成。
- 當來源結束時，讀取輸出尺寸、輸入位元組、輸出位元組，以及測量得到的百分比變化。該百分比僅依據兩個實際的 Blob 大小計算。
- 下載 WebM 檔案，並在真正的媒體播放器中完整播放後再刪除原始檔案。
- 若結果不符合你的目標，請精確地變更一個變數——通常是預設——然後再次對來源執行。選擇新檔案、切換預設、取消作業或離開頁面，都會使進行中的工作失效，並釋放暫時性的 Object URL。
這樣的流程能在單一已知來源上為你提供乾淨的前後對比。若第二次執行改變了症狀，你就找到了原因;若沒有改變，則原因存在於目標裝置、編解碼器或來源本身，而非預設的選擇。
優先檢查輸入限制
出乎意料地，有許多「壓縮器壞了」回報，實際上是「壓縮器拒絕了不支援的輸入」。檔案可能帶有 MP4、WebM、MOV、M4V 或 Ogg 等副檔名，但能否成功解碼仍取決於目前覽器中安裝的編解碼器。有效的副檔名無法讓不支援的編解碼器變得可解碼，因此第一個檢查項目是將來源拖曳到新分頁中，確認它能夠播放。若無法播放，則壓縮器回報的是真實的限制，而不是當機。
按下開始前需要驗證的四項硬性限制為:總檔案大小 500 MiB、解碼時長五分鐘、單邊 4096 像素，以及總解碼區域 3840 × 2160 像素。這些限制的目的是約束記憶體、Canvas 配置，以及即時運算的工作量;無效的檔案、不支援的解碼器、超出限制的時長、超出限制的幀、缺少 Canvas 串流，或無法使用的 WebM 錄製器，都會以錯誤呈現，而不是以靜默截斷的方式輸出。內容絕不會被靜默裁剪、截斷或降級以符合限制。
根據你的實際需求比較預設
三個預設並未標示為「好」、「更好」、「最佳」，因為沒有任何單一預設能適用於所有情況。每一個都是透明的產品選擇:寬度上限、畫面速率目標，以及夾在 180 kbps 與 8 Mbps 之間的有界每像素位元率啟發法。三者皆保留來源長寬比、永不放大來源，並將輸出尺寸向下取整為偶數像素值，以提升更廣泛的編解碼器相容性。
| 預設 | 最大輸出寬度 | 畫面速率目標 | 典型用途 |
|---|---|---|---|
| Small | 640 px | 24 fps | 你需要最小的可解碼 WebM，且目標裝置接受 SD |
| Balanced | 1280 px | 30 fps | 你需要通用的 720p 等級成品，適用於大部分手機影片 |
| Quality | 1920 px | 30 fps | 來源為 1080p 或更高，且目標裝置支援 HD |
一個具體的例子能讓權衡變得清楚。一個 1920 × 1080 的來源透過 Small 預設執行時，會取 640 與 1920 中較小的值作為新寬度，即 640。高度依來源比例計算:640 × 1080 ÷ 1920 = 360 像素，已經是偶數，因此輸出尺寸為 640 × 360。這是真實的像素縮減，當目標裝置僅需要 SD 時是正確答案;但當接收端將在 1080p 螢幕上觀看時，這就是錯誤答案。
當輸出比來源更大時
輸出變大並不是 bug。壓縮效果取決於動態、雜訊、來源編解碼器、瀏覽器編碼器以及預設，而該工具並不保證每次結果都會變小。低動態的動畫可能會大幅縮小;而雜訊高的影片、底片顆粒、影機晃動、快速變化的細節，或是本身已高效率編碼的來源，則可能產生相近或更大的檔案。所顯示的百分比僅依據兩個實際的 Blob 大小計算。
正確的回應是精確地變更一個變數。嘗試不同的預設——通常是從 Quality 降到 Balanced，或從 Balanced 降到 Small——然後對同一個來源重新執行。若結果仍不符合需求，瓶頸就不再是預設;瓶頸在於內容，即使是具備兩階段速率控制的不同工具，也無法神奇地克服本身已高效率編碼的內容。訴諸於更重型編碼器，通常意味著以更長的編碼時間換取相同的輸出位元組，這幾乎從來都不是划算的交易。
當輸出無法播放或沒有聲音時
WebM 是唯一的輸出容器，因為覽器的 MediaRecorder 對於產生 MP4 的支援，在各引擎間仍不一致。錄製器會依照目前瀏覽器回報的支援情況，依序嘗試 VP9、VP8，再退回通用 WebM，因此兩個瀏覽器對同一個預設與來源可能產生不同的位元組數。這種差異鮮少是「無法播放」回報的原因;原因通常在於目標端。僅支援 MP4 搭配 H.264 的管線、舊版簡報軟體，以及 WebM 出現前的硬體播放器，無論編碼多乾淨，都會拒絕 VP9 檔案。
只有在瀏覽器透過 HTMLCanvasElement captureStream 為底層 HTMLMediaElement 公開可擷取的音軌時，音訊才會被取。某些瀏覽器與編解碼器的組合，即使存在音軌也不會公開它，而此工具刻意不會對音訊進行正規化、重混、靜音或修復。當來源含有音訊時，即時處理期間可以聽到聲音;如有需要請使用裝置音量，但不要假設將分頁靜音等同於將擷取的音軌靜音。在刪除原始檔案之前，請務必確認下載檔案中的影像與聲音皆正常。
When to Step Outside the Browser
A local re-encode solves a specific class of problem: shrinking a single browser-decodable source to a preset-shaped WebM while reporting honest numbers. It does not normalise volume, mix tracks, remove metadata according to a certified standard, repair corrupt media, or preserve subtitles, chapters, attachments, rotation tags, colour metadata, HDR signalling, or every container feature. None of those omissions is a fault; they are the trade that keeps the tool focused on a single job and keeps every byte on your device.
For archival masters, professional delivery specifications, exact codec profiles, two-pass rate control, fixed keyframe intervals, subtitle preservation, or deterministic cross-platform output, the right answer is a maintained desktop encoder such as FFmpeg with a reviewed command. The result-checking guide walks through the verification steps that decide whether a browser-based run is enough or whether the source needs a heavier tool. Run the compressor first to confirm that the source itself is the issue, then escalate to a desktop encoder only when the compressor's honest output still does not meet the destination.
All source bytes, decoded frames, and output bytes stay in the current tab. Lizely receives no video, thumbnail, duration, file name, codec, or result. Keep the original until you have played the complete output and confirmed that size, duration, picture, sound, and compatibility meet the destination's requirements — that final playback test is the one step no troubleshooting guide can replace.
For a deeper look, see How to Troubleshoot Problems When You Use Video Crop.