在瀏覽器中於本機將影片重新編碼，即可透過 Video Compressor 將影片壓縮至大約 10 MB；該工具會將單一來源檔案轉換成 WebM，並提供三種預設模式之一，還會回報精確的輸出位元組數，讓你在下載前能先確認檔案大小。10 MB 這個目標之所以受歡迎，是因為它輕鬆低於 Gmail 的 25 MB 附件上限，遠低於一般的表單上傳上限，而且小到足以通過那些會拒絕較大影片的通訊應用程式。此工具完全在目前的分頁中運作：它會將播放中來源的每一幀繪製到一個有界 HTML Canvas 上，使用瀏覽器提供的 WebM 編解碼器錄製該 Canvas，並在來源播放完畢後提供一個可下載的檔案。由於錄製器是在來源播放的同時觀察 Canvas 串流，因此一段兩分鐘的剪輯大約需要兩分鐘才能完成 — 使用這種方式並沒有更快的路徑。你無法直接輸入「10 MB」作為目標並期望得到剛好那個大小；反之，你需要選擇 Small、Balanced 或 Quality，讀取測量出的位元組變化，若結果不符合需求再以不同預設重新執行。
為什麼 10 MB 影片是常見目標
人們將影片壓縮到大約 10 MB，是出於一組實際的小理由。電子郵件附件可保持在 25 MB 的 Gmail 上限之下並保留安全邊際。許多求職申請、工單表單和學校入口網站將上傳上限設為 5–20 MB。WhatsApp、基本的 Slack 方案及免費的 Discord 伺服器等聊天平台會拒絕超過 8–25 MB 的檔案。10 MB 的檔案在訊號不穩的手機數據下也能順暢串流而不會緩衝。這些目的地都不在意容器格式，只要檔案能播放即可，因此小型的 WebM 是可接受的取捨。
問題在於「10 MB」幾乎不是一個設定值；它是透過為你的剪輯長度選擇合適的解析度、影格率和位元率組合來達成的目標。長度較長的影片需要較低的位元率才能落在 10 MB，而位元率是在給定長度下最直接控制檔案大小的因素。如需針對電子郵件的路徑，請參閱 透過電子郵件發送壓縮後的影片 指南，等你準備好 WebM 之後再進行。
為什麼 Video Compressor 適合 10 MB 目標
Video Compressor 正是為這類有界重新編碼而設計。你交給它一個瀏覽器可解碼的影片，選擇一個預設，它就會產生一個可供下載的 WebM。以下三個特點使其特別適合 10 MB 目標：
- 本機處理。解碼、Canvas 繪製、MediaRecorder 編碼與下載全部都在目前的分頁中進行。來源位元組和輸出位元組從不離開你的裝置，因此無需經過上傳量大的服務。
- 有界輸出。每個預設都會限制寬度和影格率。Small 將寬度上限設為 640 px，目標影格率為 24 fps；Balanced 上限為 1280 px 與 30 fps；Quality 上限為 1920 px 與 30 fps。錄製器的位元率本身也限制在 180 kbps 至 8 Mbps 之間。
- 透明的尺寸回報。此工具會印出實際的輸入位元組、輸出位元組以及帶正負號的百分比變化。你不必相信行銷說法 — 你讀取數字並自行判斷檔案是否符合你的目的地。
輸入上限為 500 MiB、5 分鐘、任一邊不超過 4096 像素，以及解碼區域不超過 3840 × 2160 像素。這些限制並非隨意設定；它們限制了瀏覽器必須為解碼後的影格以及 Canvas 繪圖表面配置的記憶體，使即時編碼在長來源下不會崩潰。使這成為可能的 MediaRecorder 與 Canvas capture API 在 MDN 上有文件說明：MediaRecorder 和 HTMLCanvasElement.captureStream()。
三種預設一覽
| 預設 | 最大輸出寬度 | 目標影格率 | 10 MB 目標的典型適用情境 |
|---|---|---|---|
| Small | 640 px | 24 fps | 大多數長達數分鐘的剪輯最佳起點 |
| Balanced | 1280 px | 30 fps | 僅在非常短的剪輯或低動態內容時才能達到 10 MB |
| Quality | 1920 px | 30 fps | 幾乎無法達到 10 MB；為更高大小的目標而設計 |
三種預設都會保留來源長寬比，絕不放大較小的來源，並將輸出尺寸向下取整為偶數像素值，以獲得更廣泛的編解碼器相容性。任何預設的位元率都是由一個有界的每像素位元數啟發式所決定，而該工具並未直接公開此機制，因此即使在同一預設下，實際的位元組總數仍會因內容而異。
如何將影片壓縮至約 10 MB
- 在現行的桌面瀏覽器（例如 Chrome、Edge、Firefox 或 Safari）中開啟 Video Compressor。
- 選擇一個瀏覽器可解碼的來源檔案，大小不超過 500 MiB，長度不超過 5 分鐘，任一邊不超過 4096 像素，且解碼區域不超過 3840 × 2160 像素。副檔名為 MP4、WebM、MOV、M4V 或 Ogg 的檔案可能可以使用，但其中的編解碼器仍須獲得你的瀏覽器支援。
- 先選擇 Small 預設。對於長度超過幾秒的剪輯而言，這是 10 MB 目標最可靠的起點。
- 點擊開始控制項，並在來源播放期間保持分頁開啟且處於焦點狀態。編碼器以即時方式執行，因此兩分鐘的來源大約需要兩分鐘。關閉或重新整理分頁會使進行中的工作失效。
- 來源結束時，工具會回報輸出尺寸、輸入位元組數、輸出位元組數，以及帶正負號的百分比變化。
- 若結果太大，請先縮短來源或選擇更緊的預設 — 同一個適合電子郵件附件的小型 WebM 通常也適用於大多數聊天上傳。若結果太小而你願意接受更多像素，請以 Balanced 重新執行。
- 下載 WebM，在全新的分頁中完整播放以確認影像與音訊都正常，之後再刪除原始檔案。
估算預設是否能接近 10 MB
檔案大小大約等於位元率乘以時長再除以八（這個八用來將位元轉換為位元組）。公式如下：
檔案大小（位元組）≈ 位元率（位元／秒）× 時長（秒）÷ 8
對於一段你想要落在 10 MB 的 60 秒剪輯，計算結果約為平均 1.33 Mbps 的視訊位元率：
10,000,000 位元組 × 8 位元／位元組 ÷ 60 秒 = 1,333,333 位元／秒 ≈ 1.33 Mbps
這表示 30 秒的剪輯平均需要約 2.67 Mbps 才能達到 10 MB，兩分鐘的剪輯需要約 0.67 Mbps，五分鐘的剪輯則需要約 0.27 Mbps — 仍高於工具位元率下限的 180 kbps。若你的預設在長來源上必須降到該下限以下才能達到 10 MB，務實的做法是先縮短時長，而不是期待某種神奇的低位元率。每次執行結束時，工具都會回報實際數字，因此請用公式來規劃，再用回報來驗證。
單次處理無法達到 10 MB 的情況
某些來源確實無法在不產生不可接受損失的情況下，透過單次壓縮就達到 10 MB：
- 剪輯過長。在最低受限位元率下，五分鐘的來源仍遠超過 10 MB。正確的做法是在重新編碼前將其剪短。
- 內容屬高動態或帶雜訊。運動畫面、演唱會影片，以及帶有顆粒感的低光源場景都不易壓縮。編碼器會花費更多位元來保留細節，導致輸出檔案偏大。
- 來源編解碼器已相當有效率。由現代硬體編碼器（低位元率的 H.264 或 HEVC）所產生的剪輯，可能已接近其資訊理論下限。將其重新編碼為 WebM 可能會等於或超過原始大小；工具會誠實地將其回報為正值或接近零的百分比變化。
- 瀏覽器選用了不同的 WebM 編解碼器。錄製器會依目前瀏覽器回報的情況，依次嘗試 VP9、VP8，再退而求其次使用通用的 WebM。因此同一個來源在 Chrome 和 Firefox 上，即便使用相同預設，也可能產生不同的位元組數。
若結果不符合需求，請嘗試不同的預設、縮短來源，或接受對該特定內容而言此目標無法達成。壓縮效果取決於內容，且此工具絕不會將較大的檔案標示為縮減。
Compressor 不會保留的項目
WebM 是唯一的輸出容器，因為瀏覽器的 MediaRecorder 對所產生 MP4 的支援在各瀏覽器之間仍不一致。音訊僅在瀏覽器對來源公開可擷取的音軌時才會被納入 — 請在下載的檔案中同時確認影像與聲音。字幕、章節、附件、旋轉標記、色彩元資料、HDR 訊號，以及許多其他容器特性都不會被帶過。錄製器也不會進行音量標準化、混音或修復損壞的媒體。這些限制都不會影響結果是否能接近 10 MB，但如果你的目的地對元資料或輔助使用功能有特定要求，則這些限制就很重要。
若你需要具備確定性、跨平台輸出、明確的編解碼器設定檔、兩段式速率控制、固定關鍵影格間隔或字幕保留等特性，請使用維護良好的桌面編碼器，例如搭配審核過的指令使用 FFmpeg。當優先考量是快速、本機、無上傳地將檔案縮減至大約 10 MB，以便透過電子郵件、表單或聊天分享時，瀏覽器路徑是正確的選擇。
若想深入了解，請參閱 最佳 YouTube 上傳影片格式：在本機調整大小。