在你使用影片與管之前，最重要的幾件事是了解工具接受哪些輸入、檔案大小、與時間長度和解析度有哪些限制、每個預設值做了哪些取捨，以及輸出檔案是否保留了來源影片的音訊、元資料和其他功能。一個基於瀏覽器且在本機運作的壓縮工具，例如 Video Compressor，完全在當前的分頁中執行，因此在你點擊開始按鈕之前所做的決定，會決定後續所有的結果。你需要一個瀏覽器實際能夠解碼的影片（有效的副檔名並不等同於支援該編解碼器）、一個符合 500 MiB、五分鐘以及 3840 × 2160 像素上限的檔案，並對「壓縮效果取決於內容」抱持合理的期望——並非每次執行都會產生較小的檔案。事先了解這些事實可以避免浪費的執行、避免在預設值無法縮小雜訊多的片段時感到失望，也避免在輸出的 WebM 檔案遺失了來源影片中的字幕、色彩標記或旋轉旗標時感到意外。
輸入限制與格式需求
在你打開 Video Compressor 之前，請確認你的來源檔案符合文件中所記載的上限。瀏覽器在本機解碼影片，因此工具會先檢查以下四項限制：
- 檔案大小：正整數位元組大小，不得超過 500 MiB。
- 與時間長度：至少 1 幀，最多 300 秒（5 分鐘）。
- 解碼後的幀尺寸：任一邊不得超過 4096 像素。
- 解碼後的總面積：總計不得超過 3840 × 2160 像素。
這些上限的存在是為了限制記憶體、Canvas 配置以及後續的即時作業。一個有效的容器副檔名（例如 MP4、WebM、MOV、M4V 或 Ogg）是必要的，但並不充分——該檔案仍必須能夠由當前瀏覽器中已安裝的編解碼器解碼。一個長期存在的混淆點在於：即使檔名可辨識，也無法拯救不支援的編解碼器；重新命名或重新封裝並不會安裝缺少的解碼器。如果你的檔案無法載入，即使副檔名看起來正確，問題通常出在編解碼器，而非工具本身。
若想更深入了解 500 MiB 上限為何以這種方式設計，請參考 影片壓縮中 500 MiB 上限的意義 這篇指南，其中說明了記憶體的計算方式以及日常片段的實際上限。
三種預設值及其實際作用
Video Compressor 提供三種預設值——Small、Balanced 和 Quality——它們對應到具體的像素、幀率和位元率選擇。沒有一種是絕對的保證；每一種都是透明的產品選擇，而非宣稱能達到通用最佳效果。
| 預設值 | 最大輸出寬度 | 目標幀率 | 典型用途 |
|---|---|---|---|
| Small | 640 px（高度由來源長寬比推導） | 24 fps | 電子郵件附件、快速預覽、低頻寬分享 |
| Balanced | 1280 px | 30 fps | 大多數日常片段，在桌面與行動裝置上的社群風格播放 |
| Quality | 1920 px | 30 fps | 較大的螢幕、已有母帶時的第二級歸檔 |
三種預設值都會保留來源長寬比，且絕不會放大來源。輸出尺寸會向下取整為偶數像素值，以獲得更廣泛的解碼器支援。每個預設值所使用的位元率是透過有界限的每像素位元數啟發式決定，再限制在 180 kbps 到 8 Mbps 的範圍內，因此非常寬或非常高幀率的來源仍會落在該範圍內。
選擇預設值部分取決於個人偏好，但以下經驗法則對大多數執行都有幫助：
- 如果不確定，從 Balanced 開始——1280 px 搭配 30 fps 位於位元率範圍的中間，幾乎不會產生意外。
- 當頻寬、上傳上限或附件大小限制是主要考量時，選擇 Small。
- 只有在目標播放器支援 1920 px / 30 fps 的 WebM，且你已接受壓縮仍然是有損的情況下，才選擇 Quality。
若想更深入討論預設值選擇如何對應到結果，請參閱 壓縮影片時如何選擇品質。
如何在瀏覽器中於本機壓縮影片
當你準備好不需上傳來源就能產生 WebM 檔案時，請遵循以下的完整本機作業流程。
- 在瀏覽器分頁中打開 Video Compressor，並選擇一個符合上述 500 MiB、5 分鐘以及 3840 × 2160 上限的來源檔案。
- 根據你的目標用途選擇 Small、Balanced 或 Quality；預設值會決定此次執行的最大寬度、目標幀率以及位元率範圍。
- 開始壓縮並保持分頁開啟。來源影片在本機播放，工具會將每個顯示的幀繪製到一個有界限的 Canvas 上，然後使用當前瀏覽器所回報的 WebM 編解碼器錄製 Canvas 串流。
- 當來源播放完畢時，請讀取實際的尺寸、輸入位元組、輸出位元組以及測量到的百分比變化。顯示的百分比是根據兩個實際的 Blob 大小計算，而非根據某個目標值。
- 下載 WebM 並在你信任的播放器中完整播放一次，再刪除原始檔案。確認影像、聲音、與時間長度和大小符合目標用途的預期。
- 如果結果不符合目標用途，請嘗試不同的預設值並使用相同的來源重新執行。壓縮效果取決於內容，可能縮小某個片段的預設值，反而會讓另一個片段變大。
即時處理與預期耗時
編碼作業以即時方式執行，因為 MediaRecorder 在來源播放的同時觀察 Canvas 串流。因此，2 分鐘的來源大約需要 2 分鐘，而非桌面編碼器在高速 CPU 上可能只需幾毫秒。網頁會以預設值的節奏繪製幀、根據來源播放時間追蹤進度，並在錄製結束後停止串流軌道。此管線背後的瀏覽器實作方式記載於 MDN MediaRecorder 參考文件。
在執行期間，當來源含有音訊時會以可聽見的方式播放，因此請準備好讓揚聲器在整個處理過程中播出你的影片。請使用裝置音量來管理輸出。將網頁靜音並不一定會讓擷取到的音軌變成靜音，因此請在下載的檔案中驗證聲音，而非假設影片皆已移除。如果你替換檔案、切換預設值、取消或關閉分頁，目前的作業會失效，且暫存物件 URL 會被釋放——分頁中不會留下任何孤立的資料。
輸出檔案會保留與不會保留的內容
規劃輸出時一個有用的方式是將「會保留的」與「會移除的」分開，因為執行後大多數的意外都來自遺失的元資料，而非遺失的像素。
| 來源功能 | Video Compressor 的處理方式 |
|---|---|
| 影像幀，繪製至有界限的 Canvas | 保留——以預設值的寬度與幀率重新編碼 |
| 長寬比 | 保留——絕不放大 |
| 音軌 | 僅在瀏覽器透過 HTMLMediaElement captureStream 公開可擷取軌道時才會包含 |
| 字幕、章節、附件 | 不保留 |
| 旋轉標記、色彩元資料、HDR 訊號 | 不保留 |
| 來源編解碼器、來源容器 | 輸出僅限 WebM；錄製工具會先嘗試 VP9，接著 VP8，再使用通用 WebM |
| 來源檔案名稱與原始元資料 | 不保留 |
此工具也不會標準化音量、混音軌道、修復損毀的媒體，或保留所有容器功能。即使預設值和來源相同，不同瀏覽器之間的輸出也可能不同，因為 VP9、VP8 和通用 WebM 會產生不同的位元流。請將下載的 WebM 視為全新的編碼，而非原始位元組的封裝。如果目標用途需要 MP4、精確的編解碼器設定檔、兩段式速率控制、固定關鍵幀間隔、字幕保留，或跨平台的確定性輸出，請將作業交由維護良好的桌面編碼器，例如使用經過審核指令的 FFmpeg。
隱私與本機處理
解碼、Canvas 繪製、MediaRecorder 編碼與下載全部都在當前的瀏覽器分頁中執行。Lizely 不會收到任何影片、任何縮圖、任何與時間長度、檔案名稱、編解碼器或結果相關的資料。整個管線中沒有上傳步驟，這也是限制存在的原因——作業必須容納於分頁的記憶體中，而非遠端伺服器。關閉分頁、開始新檔案或重新整理都會結束工作階段，並釋放所有暫存資料。
結果旁顯示的百分比僅根據兩個實際的 Blob 大小計算。此工具不會將較大的檔案標示為縮小，也不會保證每次結果都會更小。壓縮效果取決於內容，因此低動態的動畫可能會大幅縮小，但含有雜訊、顆粒、攝影機晃動、急劇變化的細節，或本身已經是高效率編碼的來源，則可能產生相近甚至更大的檔案。在將該次執行視為最終結果之前，請自行使用播放器檢查下載的檔案。
瀏覽器壓縮工具不適用的情境
本機瀏覽器壓縮以便利性換取深度。它無法提供歸檔母帶、無法符合專業交付規格，也無法在不同機器之間產生確定性的檔案。以下是值得明確指出的特定不足之處：
- 精確的編解碼器設定檔、兩段式速率控制與固定關鍵幀間隔並未公開。
- 字幕保留、章節標記、附件，以及大多數色彩或 HDR 元資料不會被傳遞。
- 瀏覽器 MediaRecorder 對產生 MP4 的支援仍不一致，因此 WebM 是唯一的輸出容器。
- 即時編碼意味著 5 分鐘的來源大約需要 5 分鐘處理，而非數秒。
若需要歸檔母盤、專業交付，或任何需要跨平台確定性輸出的作業流程，請使用附帶經過審核指令的維護良好的桌面編碼器。對於日常分享、快速預覽、適合電子郵件的 WebM，以及任何將來源保留在裝置上很重要的情況，透過 Video Compressor 執行的瀏覽器作業是正確的起點。
Verify the Result Before Deleting the Original
Keep the original until you have played the complete output and confirmed size, duration, picture, sound, and compatibility with the destination. The single most common cause of regret after compression is deleting the source before noticing that a track was dropped, that the WebM container is rejected by an older player, or that the percentage change looked good but the bitrate was lower than the destination expects. Verification is part of the workflow, not an optional extra.
For example, if your source is 48 MiB and the output is 12 MiB, the displayed change is calculated as (12 − 48) ÷ 48 × 100 = −75.0%, so the tool reports a 75.0% reduction. The numbers come straight from the two Blob sizes the browser produced — there is no smoothing or rounding to a marketing figure.
A simple three-step verification on every run:
- Open the downloaded WebM in your usual player and watch at least thirty seconds past any fast-motion scene.
- Confirm the audio plays through, including any transitions, and that duration matches the source within a frame or two.
- Check that the byte count makes sense relative to the original, and that the destination accepts the file format before you delete anything.
With those checks in place, a browser-based compressor handles the routine work of producing a smaller WebM without sending your video anywhere. That is the central trade-off the tool asks you to accept in advance — and knowing it before you click Start is what separates a successful run from a wasted one.