開始使用影片壓縮意味著選擇一個瀏覽器可解碼、且不超過 500 MiB、五分鐘或 3840 × 2160 像素的來源，選取一個寬度與幀率預設值，然後讓本機瀏覽器編碼器在來源即時播放的同時，將檔案重新編碼為 WebM。這個迴圈就是全部的起點：選擇瀏覽器確實能解碼的檔案、選擇 Small、Balanced 或 Quality、在來源播放時保持分頁開啟，然後在下載 WebM 之前讀取實際的輸出尺寸與有號位元組變化。來源位元組、解碼後的影格以及編碼輸出都保留在目前分頁中，因此第一次執行不需要帳號、不需要上傳，也不需要伺服器往返。因為編碼以播放速度進行，而非快速的批次作業，所以一段兩分鐘的剪輯大約需要兩分鐘，而非數秒內完成——這個時間點是初次使用者最常感到意外的之處。一旦建立這樣的心智模型，其他所有細節——預設選擇、輸出為何可能變大、要驗證什麼、何時切換工具——都會成為建立在同一個起始迴圈之上的較小決策。
第一次壓縮執行實際上是什麼樣子
初學者通常帶著以下三種背景之一來到這個問題：一段無法用電子郵件寄送的剪輯、一段超過聊天服務或簡報上傳上限的影片，或是一個佔用過多磁碟空間的影片資料夾。這三者都能歸結為同一個第一步——從原始檔案產生較小的檔案——但「最佳」壓縮取決於目的地，因此起始工作流程應優先考慮可視性與可驗證性，而非盡可能最小的輸出。
Video Compressor 圍繞著這個起始工作流程所打造。它在本機將一個瀏覽器可解碼的檔案重新編碼為 WebM，將每個播放的影格繪製到一個有界的 Canvas 上，並在來源播放時使用瀏覽器的 WebM 編解碼器錄製該 Canvas。結果會回報輸出尺寸、輸入位元組、輸出位元組，以及測量所得的百分比變化——僅根據兩個實際的 Blob 大小計算——讓初次使用者能將真實數字與原始檔案比較，而非相信一個含糊的「已減少」標籤。
因為編碼器以播放速度觀察 Canvas 串流，所以頁面也會根據來源播放時間追蹤進度，並在來源結束時停止錄製軌道。這個時間模型正是此工具與桌面編碼器的差別：它受限於瀏覽器的媒體支援、WebM 容器，以及下方列出的輸入限制，但不需要安裝、不需要尋找編解碼器，也不需要等待上傳。
影響第一次執行的限制
在接觸預設值之前，初學者應該了解此工具強制執行的輸入上限，因為驗證要不是通過並進行壓縮，就是失敗並產生錯誤且沒有下載。頁面依序驗證五項輸入事實：
- 副檔名或 MIME 看似媒體檔——接受 MP4、WebM、MOV、M4V 或 Ogg 這類名稱，但有效的副檔名並不表示不支援的編解碼器就能解碼。
- 正整數位元組大小，上限 500 MiB。
- 解碼後的時長大於零，且最多 300 秒。
- 每邊最多 4096 像素，解碼後的區域最多 3840 × 2160 像素。
如果上述任何檢查失敗，工具會回報錯誤，而非默默地截斷輸入。無效的檔案、不支援的解碼器、超過時長限制、超過影格限制、缺少 Canvas 串流，或無法使用的 WebM 錄製器，都會產生錯誤且不下載。事先了解這點，能將「為什麼什麼事都沒發生？」轉化為「我的檔案超過了哪個界限？」——這是一個更容易回答的問題。
同樣的限制也規範了記憶體、Canvas 配置與即時處理，這也是為什麼一段 4K 的五分鐘剪輯是實際上限，而非任意行銷上的限制。檔案可以命名為 MP4、WebM、MOV、M4V 或 Ogg，但成功解碼仍取決於目前瀏覽器中安裝的編解碼器——單純重新命名永遠無法解鎖不支援的編解碼器。
如何在第一次本機執行中使用 Video Compressor
- 在目前的桌面瀏覽器中開啟 Video Compressor 頁面，並選擇一個符合 500 MiB / 5 分鐘 / 3840 × 2160 範圍的檔案。
- 選擇一個預設值——Small 將寬度限制為 640 像素，目標為 24 fps；Balanced 將寬度限制為 1280 像素，目標為 30 fps；Quality 將寬度限制為 1920 像素，目標為 30 fps。
- 開始壓縮並在來源播放時保持分頁開啟；錄製器以播放速度執行，因此兩分鐘的來源大約需要兩分鐘。
- 來源結束時，讀取回報的輸出尺寸、輸入與輸出位元組，以及有號百分比變化。
- 下載 WebM 並在另一個分頁或播放器中完整播放後，再刪除原始檔案。
選擇新檔案、變更預設、取消或在執行中途離開頁面，都會使目前的工作失效並釋放暫時性的物件 URL，因此初學者不需要在每次嘗試之間進行「清理」。編碼器也會使用有界的每像素位元數啟發式，將要求的位元率限制在 180 kbps 至 8 Mbps 之間，但壓縮仍然取決於內容——低動畫的動畫可能會變小很多，而雜訊過多的影片、顆粒感、攝影機晃動、快速變化的細節，或已經有效率的來源，則可能產生大小相近甚至更大的檔案，因此每次執行後都應檢查位元組。
讀取輸出：尺寸、位元組與變化
輸出面板是大多數初學者在第一次執行時會略過的部分，但也是決定結果是否適合目的地的部分。工具回報四個數值：
- 輸出寬度與高度——Canvas 實際產生的尺寸，經長寬比保留與偶數像素四捨五入後，絕不會放大超過來源。
- 輸入位元組——您所選擇檔案的實際大小。
- 輸出位元組——錄製的 Blob 實際大小。
- 有號百分比變化——僅根據這兩個實際的 Blob 大小計算。
最後一個數值需要仔細閱讀。百分比不是行銷說法，工具也不保證每個結果都會變小。壓縮取決於動態、雜訊、來源編解碼器、瀏覽器編碼器以及您選擇的預設，因此一段使用 Small 預設的雜訊動作剪輯，如果來源已經有效率，輸出可能接近甚至大於來源。工具絕不會將較大的檔案標示為減少；數字反映的是實際的差異。
當結果不符合目的地時，第一次執行時的正確做法是嘗試另一個預設並重新檢查面板，而非放棄整個工作流程——請參閱 如何為影片壓縮選擇正確的方法 以了解該切換背後更廣泛的決策邏輯。錄製器依序嘗試 VP9、然後 VP8、再嘗試通用 WebM，因此同一個預設和來源在不同的瀏覽器之間可能產生略有不同的位元組。
在第一次執行時選擇預設值
這三個預設值是透明的產品選擇，並非通用最佳化的保證，它們之間的差異可見於下表。
| Preset | Maximum width | Target frame rate | Bitrate band | What the output will look like |
|---|---|---|---|---|
| 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 | 較高解析度的副本，使用標準幀率 |
三個預設值都會保留來源長寬比，絕不放大來源，並將輸出尺寸向下四捨五入為偶數像素值，以獲得更廣泛的編解碼器相容性。錄製器要求的位元率在每個預設中都是相同的 180 kbps – 8 Mbps 範圍；預設改變的是畫布大小和幀率，這會餵入決定最終位元率的每像素位元數啟發式。因此選擇預設實際上是先選擇解析度和幀率，然後信任啟發式為該組合找到合理的位元率。
在取代原始檔案之前驗證結果
第一次壓縮在出現下載按鈕時還不算完成。該工具刻意不聲稱下載的 WebM 在每個容器特性上都符合來源，因此初學者在刪除原始檔案之前應執行三項檢查：
- 在另一個分頁中從頭到尾播放下載的 WebM，並確認時長、畫面和聲音符合目的地的需求。
- 將回報的輸出位元組與輸入位元組比較——如果檔案較大，請嘗試另一個預設，而非覆寫原始檔案。
- 確認目的地接受 WebM 容器；對於僅支援 MP4 的流程，請使用維護良好的桌面編碼器，例如搭配審核過指令的 FFmpeg。
只有當瀏覽器透過 HTMLMediaElement captureStream 公開可擷取的音訊軌道時，才會包含音訊；因此若某段明顯有聲音的剪輯下載後無聲，這是一個訊號，表示應在能公開該軌道的瀏覽器中重新測試——基礎擷取 API 已記錄於 MDN 的 HTMLCanvasElement.captureStream()。錄製器本身則描述於 MDN MediaRecorder 參考資料，這也是該工具呼叫的同一個 API。
字幕、章節、附件、旋轉標記、色彩中繼資料、HDR 訊號以及許多容器特性皆不會保留——唯一的輸出是 WebM 容器，因為瀏覽器對於瀏覽器產生的 MP4 的 MediaRecorder 支援在各家瀏覽器間仍不一致。不會對音量進行標準化、不會混音，也不會修復損壞的媒體。對於歸檔母片、專業傳遞規格、嚴格的編解碼器設定檔、兩階段速率控制、固定關鍵影格間隔、字幕保留，或確定性的跨平台輸出，這份合約指向使用審核過指令的 FFmpeg，而非此瀏覽器工具。
最後，請保留原始檔案。來源位元組、解碼後的影格與輸出位元組都保留在目前分頁中，且 Lizely 不會收到任何影片、縮圖、時長、檔名、編解碼器或結果——但第一次執行也是一次校正步驟，而原始檔案是您唯一能用來與新檔案比較的產物。
如果您正在權衡選項，在瀏覽器中排解影片壓縮問題 有詳細說明。