把影片壓縮到 8MB，意思是產出一個大約相當於六十四 megabits 的 WebM 檔，每秒影片位元率則把該總量除以片段的秒數來設定。30 秒片段大約需要 2.1 Mbps 的平均影片位元率才能落到 8MB，而兩分鐘片段只需要大約 533 kbps，五分鐘片段則最低大約落到 213 kbps 附近。Video Compressor 在 Lizely 上會把瀏覽器可解碼的影片，在你自己的分頁裡重新編碼成 WebM 檔，提供三種透明預設 Small、Balanced 與 Quality，然後回報實際輸入位元組、輸出位元組，以及帶正負號的百分比變化，讓你看出新檔是否真的達到你需要的大小。沒有任何東西會離開你的裝置，編碼以即時執行，而最終 WebM 是你唯一下載的檔。因為此工具從不承諾放諸四海皆準的最佳值，而是公開每個預設背後的解析度與影格率，你可以在開始前判斷，對既定來源來說哪一個最可能落到 8MB 附近。
8MB 如何對應到解析度、時長與位元率
八 MB 聽起來很小，直到你把它換算成影片編碼器實際使用的單位。一個 megabyte 大約是八 megabits，所以 8 MB 總共大約是 64 megabits。總位元預算必須涵蓋片段的每一秒，這就是為什麼同樣的 64 megabits 在 30 秒片段上顯得寬裕，在五分鐘片段上卻很緊。一旦目標大小與時長固定，剩下的唯一旋鈕就是平均影片位元率，而位元率又會與解析度、影格率以及畫面上的動態量互相取捨。事先知道這套數學，能幫你選對起始預設，並判斷某個結果是否合理。
用符合串流所使用位元率尺度的十進位單位，把數學走一遍：8 MB × 8 bits/byte = 64 megabits total。120 秒、以 8 MB 為目標的來源因此需要 64 Mbit ÷ 120 s = 0.533 megabits per second，也就是大約 533 kbps 的平均影片位元率。這遠高於工具箝制的 180 kbps 下限，也留了音訊的空間。以同樣 8 MB 為目標的五分鐘來源只有大約 213 kbps 可用，這正是編碼器最可能達不到目標的區間，也是 Small 預設較緊解析度最關鍵的地方。
Video Compressor 如何瞄準特定輸出大小
Video Compressor 是一套瀏覽器端影片壓縮器，會在目前分頁把單一檔案重新編碼成 WebM，完成時回報實際輸入與輸出位元組。沒有上傳步驟、沒有帳戶、也沒有伺服器端處理：來源會被解碼，依預設的節奏逐格畫進 Canvas，再用瀏覽器目前提供的 WebM 編解碼器錄製。此工具先試 VP9，再 VP8，再通用 WebM，依據 MDN HTMLCanvasElement.captureStream 參考 以及頁面能偵測到的 MediaRecorder 支援。
此工具附三種透明預設，而不是單一隱藏設定檔，因此你做的取捨在按下開始前就看得見。有界的每像素位元數啟發式會依預設的解析度與影格率挑選所請求的影片位元率，結果再箝制在 180 kbps 到 8 Mbps 的範圍。每個預設都會保留來源長寬比、從不放大來源，並把輸出尺寸向下取整為偶數像素值，以求更廣的編解碼器相容性。
| 預設 | 最大輸出寬度 | 目標影格率 | 在 8 MB 取捨中的定位 |
|---|---|---|---|
| Small | 640 px | 24 fps | 最接近緊的 8 MB 目標與短片段 |
| Balanced | 1280 px | 30 fps | 當 8 MB 上限對時長寬裕時的通用分享 |
| Quality | 1920 px | 30 fps | 保真度較高、檔案較大，除非片段非常短，否則較不適合 8 MB |
在瀏覽器把影片壓縮到 8MB
8 MB 目標與 Small 預設最自然對齊，因為該預設較低的寬度、較低的影格率，以及更緊的每像素位元數目標，都會把編碼器推向較小的檔。完整步驟不論你選哪個預設都相同，而且完全在目前分頁執行。
- 選一個瀏覽器可解碼的來源。檔案必須是 500 MiB 或更小、五分鐘或更短、任一邊最多 4096 像素，且解碼面積最多 3840 × 2160。副檔名可以是 MP4、WebM、MOV、M4V 或 Ogg，但編解碼器必須是你目前瀏覽器實際能解碼的，所以光有有效副檔名並不夠。
- 開啟 Video Compressor 並載入檔案。頁面會開始本機解碼，並顯示三種預設選項：Small、Balanced 或 Quality。若目標是 8 MB，請選 Small，把寬度維持在 640 像素、目標節奏維持在 24 fps。
- 開始壓縮並保持分頁開啟。編碼以即時執行，所以兩分鐘來源大約要兩分鐘才完成，五分鐘來源大約要五分鐘。編碼器錄製 Canvas 串流時，來源會繼續有聲播放；若你不想聽，請調低裝置音量，但不要假設靜音對已擷取的軌道沒有影響。
- 等待實際位元組報告。來源結束後，工具會回報輸出尺寸、輸入位元組、輸出位元組，以及帶正負號的百分比變化。該數字只由兩個 Blob 大小計算，因此更大的檔案絕不會被標成縮減。
- 下載 WebM、播放完整檔，然後才刪除原始檔。在丟棄來源前，確認大小、時長、畫面與聲音符合目的端的預期。
為什麼同一來源會產出不同的 8MB 結果
同一來源在不同次執行、不同瀏覽器之間，可以產出明顯不同的輸出大小，因為 WebM 壓縮取決於動態、雜訊、來源編解碼器，以及瀏覽器碰巧附帶的編碼器。低動態動畫往往會大幅縮小，而雜訊畫面、顆粒、相機晃動、快速變化的細節，或已經高效編碼過的來源，則可能大小相近，甚至更大。結尾顯示的百分比變化在這點上是誠實的：它是兩個實際 Blob 之間帶正負號的變化，不會往對你有利的方向進位。
若結果不符合你的 8 MB 目標，最有效的做法是改換預設、把片段剪短，或選雜訊較少的來源。兩分鐘片段要比五分鐘片段容易落到 8 MB，因為每秒位元預算會隨時長下降而上升。輸出容器只有 WebM，因為 MediaRecorder 對瀏覽器產生的 MP4 支援在各瀏覽器間仍不一致，而且錄製器會依目前瀏覽器回報先試 VP9，再 VP8，再通用 WebM，所以兩台機器用同一預設處理同一來源，產出的檔案大小可能略有差異。
8MB WebM 會保留什麼、會丟掉什麼
8 MB WebM 不是來源的完整複本。只有在瀏覽器透過 HTMLMediaElement captureStream 提供可擷取音訊軌道時才會包含音訊，多數瀏覽器會這樣做但不是全部；你應該在下載檔上核對畫面與聲音，而不是假設音訊有被帶上。字幕、章節、附件、旋轉標籤、色彩中繼資料與 HDR 訊號都不會保留，此工具也不會正規化音量、混音、依認證標準移除中繼資料、修復損毀媒體，或轉錄字幕。
輸出尺寸是套用長寬比與偶數像素規則後預設所允許的值，而且來源從不放大：480 像素寬的來源會停在 480，即使在 Quality 預設也一樣。也不會默默截斷，所以無效檔、不支援的解碼器、超限時長、超限畫面、缺少 Canvas 串流，或沒有可用的 WebM 錄製器，都會產生錯誤且沒有下載。結果是乾淨、有限時長、可在任何現代瀏覽器播放的 WebM，而這通常正是 8 MB 目標一開始需要的。
何時 8MB 需要改用別的工具
對要寄電子郵件、聊天上限或表單上傳的日常 8 MB 分享檔，本機 WebM 通常就夠了。針對電子郵件附件上限的逐步說明見 在本機壓縮後以電子郵件傳送大型影片, 而且同一形態的工作流程涵蓋大多數即時通訊應用程式。若交付物是另一種類型，取捨就會改變。典藏母帶、專業交付規格、精確編解碼器設定檔、兩次通過位元率控制、固定關鍵影格間隔、跨平台確定性輸出、字幕保留，或色彩管理的工作流程，都是 Video Compressor 明確不承諾的事，若想用即時瀏覽器編碼器硬做，只會跟你作對。在那些情況下，像 FFmpeg 這類有維護的桌面編碼器，搭配經審核的指令，才能給你真正需要的旋鈕。不過就眼前這個 8 MB 目標而言，本機重新編碼才是對的工具形態：試得快、容易核對，而且關在你已經打開的分頁裡。
若要更深入了解，見 線上影片壓縮器安全嗎？.