在你使用影片壓縮之前，請將來源檔案與工具的硬性輸入限制、三個預設檔、工具將回報的實際位元組變化，以及輸出必須符合的目的端需求進行比較——因為壓縮取決於內容，同一個預設可能讓一部影片大幅縮小，卻對另一部影片幾乎沒有作用。Lizely 上的 Video Compressor 會在本地將單一瀏覽器可解碼的來源重新編碼為 WebM 檔案，因此你需要做的比較並非在服務之間，而是在你的來源實際包含的內容、每個預設為其設定的上限，以及執行後記錄的位元組看起來像什麼之間做比較。在你開始之前真正重要的三個問題是：來源是否符合限制、哪個預設符合你的目的端，以及你是否準備好閱讀實際的位元組變化，而不是相信一個承諾的百分比。把這些弄清楚，剩下的就是在分頁中的即時播放。
這項比較實際上決定了什麼
具有低動態且背景乾淨的短影片通常能積極壓縮；具有相機晃動、雜訊或快速變化細節的吵雜片段則通常抗拒壓縮，而一個本身已經很有效率的來源可能會產生與輸入相同大小或更大的 WebM。Video Compressor 並不承諾通用的縮減。它會將播放中的來源繪製到有界限的 Canvas 上，使用目前瀏覽器支援的 WebM 編解碼器擷取該串流，並回報輸入與記錄 Blob 之間的有號位元組變化。這就是為什麼你在壓縮前所做的每一次比較，都必須以實際來源在眼前來回答，而不是以別人片段的平均值來回答。
真正重要的四項比較是：來源與工具限制的比較、預設與你的目的端的比較、記錄的位元組與你的大小預算的比較，以及記錄的 WebM 與你的播放目標的比較。如果其中任何一項失敗，你就有理由以不同的預設、不同的來源或不同的工具重新執行——而 Video Compressor 的設計正是為了讓你快速重複這些比較，因為每次執行都在本地進行，且每個預設都只要點擊一次。
將你的來源與工具的硬性輸入限制進行比較
第一項比較是最具體的：你打算壓縮的檔案是否符合工具記載的邊界？任何超出邊界的項目都會以錯誤被拒絕，且不會產生下載，因此值得在開始前先檢查。以下列出這些限制，並說明實作中每項限制存在的原因。
| 輸入屬性 | 記載的限制 | 為何重要 |
|---|---|---|
| 副檔名或 MIME | MP4、WebM、MOV、M4V 或 Ogg | 僅憑副檔名無法保證可解碼；瀏覽器中安裝的編解碼器決定該檔案是否能播放。 |
| 正數位元組大小 | 最大 500 MiB | 加以限制，使來源 Blob 能在不耗盡分頁記憶體的情況下載入記憶體。 |
| 解碼後的持續時間 | 大於零，最多 300 秒 | 即時編碼表示兩分鐘的來源需要大約兩分鐘；較長的來源會延長實際時間與記憶體使用。 |
| 每邊像素 | 最多 4096 像素 | 加以限制，使 Canvas 配置在不同瀏覽器間保持可預測。 |
| 解碼後的區域 | 最多 3840 × 2160 像素 | 加以限制，使工作中的 Canvas 與 MediaRecorder 流程保持在已測試的範圍內。 |
如果你的來源在該表格的任何一列未通過，比較會在編碼開始前結束。一個檔案可以被命名為 MP4，但若瀏覽器對其內部的編解碼器沒有解碼器，仍會被拒絕，因為有效的副檔名無法讓不支援的編解碼器變得可解碼。編解碼器支援來自瀏覽器，因此在承諾於使用預設前於分頁中檢查實際播放也是比較的一部分。
比較每個預設實際更動的內容
第二項比較是在三個具名預設與你的目的端之間。每個預設都是一個透明的產品選擇，而非對通用最佳值的宣稱，且每個預設都為寬度、影格率與目標位元速率的不同組合設定上限。在它們之間選擇是權衡的比較，而不是尋找最小的檔案。
| 預設 | 最大輸出寬度 | 目標影格率 | 位元速率範圍 | 典型適用情境 |
|---|---|---|---|---|
| Small | 640 像素 | 24 fps | 依每位元像素啟發式，限制在 180 kbps 至 8 Mbps | 快速分享，目的端重視位元組數量勝過解析度的情況。 |
| Balanced | 1280 像素 | 30 fps | 相同的限制 | 一般用途分享、聊天附件以及 720p 已足夠的螢幕錄影。 |
| Quality | 1920 像素 | 30 fps | 相同的限制 | 預覽品質的輸出，以及目的端以完整解析度播放的情況。 |
所有三個預設都保留來源長寬比，絕不放大來源，並將輸出尺寸向下取整為偶數像素值，以獲得更廣泛的編解碼器相容性。要求的位元速率由有界限的每位元像素啟發式選出，接著在配置錄製器前被限制在 180 kbps 至 8 Mbps，因此最差情況的位元速率在三個預設之間相同，即使每影格的像素數不同。錄製器會依據瀏覽器回報的支援依序嘗試 VP9、然後 VP8、然後通用 WebM，因此相同的來源與相同的預設在 Chrome 與 Firefox 中可能產生略有不同的檔案。因此，比較預設意味著比較你的目的端實際播放的內容，而不是比較表格所承諾的內容。
如何在 Video Compressor 中執行並排比較
第三項比較是程序性的：將檔案透過工具執行並檢查實際結果。由於每次執行都在本地進行，執行多個預設的唯一成本就是播放的實際時間，等同於來源持續時間。
- 選擇一個不大於 500 MiB、五分鐘或 3840 × 2160 像素解碼區域、且瀏覽器可解碼的影片，並在開始前確認該檔案能在目前分頁中播放。
- 根據你在前一節所做的目的端比較，選擇 Small、Balanced 或 Quality，然後開始壓縮，並在來源即時播放時保持分頁開啟。
- 等待錄製器在播放結束時停止，然後在結果面板中讀取回報的輸出尺寸、輸入位元組、輸出位元組以及有號百分比變化。
- 下載 WebM 並在支援錄製器所選編解碼器的播放器中完整播放；檢查畫面、聲音，以及持續時間是否播放至結束。
- 如果結果不符合目的端，請選擇另一個預設並再次執行相同來源——沒有上傳步驟，因此每次執行都是全新的本地重新編碼。
- 保留原始檔，直到下載的 WebM 已被完整播放，且你已確認大小、持續時間、畫面、聲音與相容性皆符合目的端的需求。
編碼以即時方式執行，因為 MediaRecorder 在來源播放時觀察 Canvas 串流，且頁面以預設節奏繪製、從來源播放時間追蹤進度，並在錄製後停止串流軌道。選擇新檔案、更改預設、取消或離開頁面都會使進行中的工作失效，並釋放暫時的 Object URL，因此部分執行無法洩漏半完成的檔案。只有當瀏覽器透過 HTMLMediaElement captureStream 公開可擷取軌道時，才會包含音訊，因此視瀏覽器連接軌道的方式而定，將來源靜音可能會減少到達錄製器的內容；如果你需要驗證聲音，請將可聽見播放的下載結果與你信任的目的端進行比較，而不是與來源的螢幕上音量比較。底層機制記載於 W3C MediaStream Recording 規範中，並在 MDN MediaRecorder 參考資料 中說明，Canvas 端則在 HTMLCanvasElement.captureStream() 中說明。
將工具的回報與你的目的端需求進行比較
第四項比較是詮釋性的。執行後，工具會回報實際尺寸、輸入位元組、輸出位元組，以及這兩個 Blob 大小之間的有號百分比變化。該回報是針對此次執行的大小問題唯一誠實的答案，因此應對照目的端而非預期來閱讀。如果輸出較小且目的端接受 WebM，則執行成功。如果輸出大小相同或更大，則執行未達到你想要的結果，下一步是使用不同的預設、不同的來源或不同的工具——該工具絕不會將較大的檔案標示為縮減，且所顯示的百分比僅根據兩個實際的 Blob 大小計算。壓縮取決於內容：低動態的動畫可能變得小很多，而吵雜的素材、雜訊、相機晃動、快速變化的細節或本身已經有效率的來源，則可能產生大小相近或更大的檔案。如果你想要較小的結果，請更改預設並重新執行；如果你想要可預測的結果，則需要一個有記載的指令列編碼器，而非即時瀏覽器流程。配套指南 常見的影片壓縮錯誤及其避免方法 更深入地探討了多個比較陷阱，包括假設任何單一預設總是會勝出的想法。
當比較引導你改用桌面編碼器時
最後一項比較是誠實的範圍：以即時方式錄製 Canvas 串流的瀏覽器工具，並非適用於所有工作的正確工具。Video Compressor 不會正規化音量、混音軌、根據認證標準移除中繼資料、修復損壞的媒體、保留字幕、章節、附件、旋轉標籤、色彩中繼資料、HDR 訊號或每個容器功能。WebM 是唯一的輸出容器，因為瀏覽器對瀏覽器產生的 MP4 的 MediaRecorder 支援仍然不一致。因此，即使預設與來源相同，輸出在瀏覽器之間也可能有所不同，且錄製器會根據目前瀏覽器回報的內容，從 VP9 退而求其次到 VP8，再到通用 WebM。對於歸檔母片、專業交付規格、精確的編解碼器設定檔、兩階段速率控制、固定關鍵影格間隔、字幕保留或確定性的跨平台輸出，正確的比較是在此瀏覽器工具與受維護的桌面編碼器（例如 FFmpeg 加上經審核的指令）之間進行。這些限制都不是錯誤；它們是本地瀏覽器流程能誠實承諾的邊界，而誠實地比較它們，才是「在使用影片壓縮之前我應該比較什麼」這個問題真正在問的事情。
如果你正在權衡選項，無法使用影片壓縮時該怎麼辦 詳細介紹了這部分內容。