影片壓縮通常會在較低的寬度、定義的幀率以及受限的位元率下產生較小的 WebM 檔案，但大小的變化永遠以實際位元組回報，而不是以保證的縮減比例回報。當可在瀏覽器解碼的來源透過 Video Compressor 在本機重新編碼時，頁面會將每個顯示的影格繪製到 Canvas 上，寬度上限為所選預設的最大寬度，然後以目前瀏覽器所支援的 WebM 編解碼器錄製該串流，並向你顯示輸出的像素尺寸、輸入與輸出的位元組，以及帶正負號的百分比變化。你選擇的預設會設定寬度的硬性上限與目標幀率，絕不會放大來源，並將尺寸向下捨入為偶數值以維持編解碼器相容性。位元率是依據每像素位元數的啟發式所選擇，並限制在 180 kbps 到 8 Mbps 的固定範圍內。這些數字都不代表輸出會小於來源。
影片壓縮後檔案大小如何變化
工具所顯示的百分比僅根據兩個實際 Blob 大小計算，這代表它永遠反映真實的位元組變化，不論方向為何。壓縮取決於內容:低動畫量的動畫可能會大幅縮小，因為相鄰影格看起來很相似;而雜訊多的畫面、嚴重的顆粒或快速的鏡頭晃動可能會抵抗壓縮，產生與輸入相近或更大的輸出。工具並未承諾每個結果都會變小，也不會將較大的檔案標示為縮小。你所看到的帶正負號數字，無論是負數代表縮小或正數代表增大，都是來源位元組與輸出位元組之間的測量差異。沒有為了行銷而做的隱藏捨入，也沒有與假想理想檔案大小的比較。
由於此工具在來源播放時即時運作，它向瀏覽器 MediaRecorder 要求的位元率來自於一個受限的每像素位元數啟發式，並被限制在 180 kbps 到 8 Mbps 之間。如果所選預設在目標解析度與幀率下需要超過 8 Mbps，工具不會超過該上限。如果啟發式低於 180 kbps，則會提高至該下限。無論哪種情況，上限與下限的存在都是為了讓輸出維持在一個範圍內，使產生的 WebM 能廣泛播放，且檔案大小變化保持可預測。根據 MediaRecorder 的 MDN 文件，瀏覽器實際套用至 Canvas 串流的編解碼器與位元率在各家瀏覽器之間並不一致，這也是為什麼兩個不同的瀏覽器使用相同預設處理相同來源，仍可能產生不同大小的原因之一。
你應該將所顯示的百分比視為一項測量值，而不是保證。工具顯示實際數字，讓你在下載或刪除之前判斷這個變化是否符合你的目標。如果結果不如預期，正確的下一步是在相同來源上嘗試另一個預設，並將新的數字與你的目標進行比較，而不是假設第一次嘗試就是最終結果。
每個預設可預期的解析度與幀率
每個預設都是一個透明的產品選擇，而不是對通用最佳值的聲明。三種設定在最大輸出寬度與目標幀率上有所不同，且它們都保留來源長寬比而不放大。尺寸向下捨入為偶數像素值，使產生的 WebM 能與更廣泛的解碼器相容。你選擇的預設是編碼器端唯一會變動的因素;其他一切，包括每像素位元數的啟發式與位元率限制，都保持不變。
| 預設 | 最大輸出寬度 | 目標幀率 | 長寬比處理 | 典型用途 |
|---|---|---|---|---|
| Small | 640 px | 24 fps | 保留，絕不放大 | 快速預覽、低頻寬分享 |
| Balanced | 1280 px | 30 fps | 保留，絕不放大 | 一般分享、螢幕錄影、教學 |
| Quality | 1920 px | 30 fps | 保留，絕不放大 | 細節較高的播放，大小較不重要 |
沒有任何預設會將你的影片升頻。如果你的來源寬度已小於預設的最大寬度，輸出會維持該較窄的寬度。如果你的來源高度超過所選寬度在來源長寬比下對應的高度，輸出會維持對應的高度，並縮減寬度以保持比例。工具不會拉伸、加上 letterbox 或 pillarbox，也不會加上黑邊。寬度與高度皆向下捨入為偶數像素值，使編解碼器能毫無問題地接受該影格。
位元率依據預設的解析度與幀率，透過受限的每像素位元數啟發式得出。由於該啟發式被限制在 180 kbps 到 8 Mbps 之間，非常小的輸出仍會獲得足夠的位元以保持可觀看性，而非常大的輸出則不會超過會使檔案膨脹的上限。輸出的實際測量位元組會在錄製完成後回報，因此位元率與最終檔案大小並非同一數字，即使位元率大幅影響大小。
如何逐步在本機壓縮影片
- 挑選一個瀏覽器可解碼、不大於 500 MiB、長度不超過五分鐘、每邊長度不超過 4096 像素，且解碼後區域不超過 3840 × 2160 像素的影片。檔案可以命名為 MP4、WebM、MOV、M4V 或 Ogg，但能否成功解碼仍取決於目前瀏覽器中安裝的編解碼器;有效的副檔名無法讓不支援的編解碼器變得可解碼。
- 選擇 Small、Balanced 或 Quality 並開始壓縮。在來源即時播放期間保持分頁開啟。編碼以即時方式執行，因為 MediaRecorder 會在來源播放時觀察 Canvas 串流，所以兩分鐘的來源大約需要兩分鐘，而非瞬間完成。
- 檢視工具在錄製完成時回報的實際輸出尺寸與帶正負號的位元組變化。百分比是根據兩個實際 Blob 大小計算，絕非根據目標或猜測，因此正數代表輸出大於輸入。
- 下載產生的 WebM 並在刪除原始檔案之前完整播放。確認影像與聲音、時長，以及與你預計使用目的地的相容性。
如果結果不符合你的需求，請在相同來源上嘗試不同的預設。如果因為不支援的編解碼器、超過限制的時長、超過限制的影格、缺少 Canvas 串流或無法使用的 WebM 錄製器而導致解碼失敗，工具會回傳錯誤且不產生下載，而不是默默地截斷工作。選擇新檔案、更換預設、取消或離開頁面都會使進行中的工作失效，並釋放任何暫時的 Object URL。頁面以預設的節奏繪製，根據來源播放時間追蹤進度，並在錄製後停止串流軌道，因此中途取消是安全的。
為什麼輸出有時會等於或超過來源
已經有效率的來源在重新編碼後可能會產生相近或更大的檔案，因為原始編解碼器已經做得很好，而新的 WebM 編碼無法在每個影格上都勝過它。編解碼器在處理動態估計、預測與熵編碼的方式上有所不同，且工具所要求的位元率可能高於來源在相同可見內容下實際需要的位元率。使用 VP9 以啟發式選擇的位元率編碼的長時間靜止影格，會比使用更有效率的來源編解碼器以較低位元率編碼的相同靜止影格來得大。輸出的測量位元組數在每個情況下都是誠實的答案。
雜訊多的畫面會讓情況更糟。底片顆粒、感測器雜訊，以及高頻細節(例如明亮天空前的樹枝)需要位元來編碼，而每像素位元數的啟發式無法事先知道你的內容有多容易被壓縮。帶有快速鏡頭晃動的手持影片，從影格到影格看起來差異極大，因此編解碼器會花費更多位元在動態向量與殘差上。這些都不是工具的缺陷;而是要求單次即時編碼器在抗拒壓縮的內容上使用固定每像素位元數預算的自然結果。
工具絕不會將較大的檔案重新標示為較小。如果你需要對特定目標大小做出保證的縮減，請使用經維護且審核過兩次編碼指令的桌面編碼器，而非瀏覽器中一次性的啟發式。Video Compressor 是為本機、單次探索重新編碼實際產生的結果而打造，並非為了達到合約交付大小。如需更深入了解該測量與實際內容的互動方式，Video Compressor accuracy and what it actually reports 一文以具體範例說明了相同的帶正負號百分比概念。
輸出 WebM 將會與不會保留的內容
輸出永遠是 WebM，因為 MediaRecorder 對瀏覽器產生的 MP4 支援在各家瀏覽器之間仍不一致。錄製器會先嘗試 VP9，然後是 VP8，再根據目前瀏覽器回報的支援使用通用 WebM，因此相同的來源在不同的瀏覽器中使用相同的預設可能會產生不同的檔案。只有當瀏覽器透過來源元素的 captureStream 公開可擷取的音訊軌道時，才會包含音訊;如果沒有公開軌道，輸出就不會有音訊，你需要自行驗證後才能依賴它進行播放。如 MDN 在 HTMLCanvasElement.captureStream() 中所說明，音訊軌道必須來自可擷取的媒體元素，而不是 Canvas 本身。
字幕、章節、附件、旋轉標記、色彩中繼資料、HDR 訊號以及許多其他容器功能都不會保留。工具不會根據認證標準來正規化音量、混音軌道、移除中繼資料、修復損壞的媒體，或保留每個容器功能。頁面以預設的節奏繪製，根據來源播放時間追蹤進度，並在錄製後停止串流軌道，但編碼後的檔案是一個全新的 WebM，具有錄製器所產生的尺寸、幀率與位元率。如果你的目的地依賴章節標記、字幕軌道或色彩設定檔，這些都需要透過另一個工作流程重新加入。
此工具也不會執行兩次編碼速率控制、強制固定關鍵影格間隔，或以決定性的跨平台輸出為目標。對於歸檔母片、專業交付規格、精確的編解碼器設定檔、字幕保留，或任何需要檔案在不同機器之間逐位元組符合規格的工作流程，請使用經維護且審核過指令的桌面編碼器。對於分享、預覽與快速的本機探索，這些取捨是有意而非偶然的。
\Verifying the Result Before Deleting the Original
Two checks matter before you commit to the new file: play the entire download in a player you trust, and compare the output bytes to the source bytes honestly. The signed percentage change is a measurement, and the only way to confirm that the visual quality matches your goal is to watch the output end-to-end. Browser support and codec combinations vary, so verifying both picture and sound in the downloaded file is part of the workflow, not an extra step.
Source bytes, decoded frames, and output bytes all remain in the current tab. Lizely receives no video, thumbnail, duration, file name, codec, or result, which means the only place the file exists is in your downloads folder and on your disk. Keep the original until you have played the complete output and confirmed that size, duration, picture, sound, and compatibility meet the destination's requirements. If you want to plan the workflow before starting, the guide on how to choose the right approach for video compression walks through decision points that affect which preset to pick and what expectations to set in advance.