500 MiB 的限制是瀏覽器式影片壓縮工具在單次處理中能接受的最大影片檔案大小，這個限制適用於你載入工具的輸入檔，而非你收到的輸出檔大小。具體來說，500 MiB 等於 524,288,000 位元組，或在十進位標示下約為 524.288 MB。工具會在任何解碼或播放作業開始之前先驗證這個位元組大小，因此只要超過上限一個位元組的檔案就會直接遭到拒絕，不會嘗試進行部分處理。由於這個流程中的編碼是邊在頁面上播放來源影片邊即時進行，因此 500 MiB 這個數字同時也是一項記憶體預算:它大約是典型瀏覽器分頁在已解碼影格的 Canvas 串流旁，還能容納而不會耗盡 RAM 或讓 MediaRecorder 卡住的最大承載量。這個上限是針對輸入內容的硬性約束，目的是讓解碼、影格繪製與錄製作業都能在實際的硬體限制範圍內完成，而且它與使用者心中可能為目標平台設定的 8 MB、25 MB 或 100 MB 等任何輸出大小目標無關。

what does the 500 mib limit mean when using video compression
500 MiB 限制在影片壓縮中代表什麼意義

500 MiB 上限是輸入限制，而非輸出目標

許多搜尋這個詞彙的讀者，想了解的是 500 MiB 是否代表壓縮後最終得到的檔案大小。答案是否定的。500 MiB 這個數字是設在來源檔上的一道關卡:工具會測量你選取檔案的位元組數，並拒絕任何超過 524,288,000 位元組的檔案。你下載的內容則是由你所選預設值與影片實際內容所衍生出的另一套規則所決定。一段短、低動態的動畫，在三種預設中的任何一種下都可能大幅縮小;反之，一段雜訊多、高動態或已經高效編碼的來源，可能產出與輸入大小相近、甚至更大的檔案，因為工具回報的是實際的位元組變化，而不是保證一定會縮小。

這項區別對於規劃工作流程的人來說很重要。如果你的目標是把一段影片透過允許 25 MB 附件的服務寄出，那相關的數字是輸出大小，而不是 500 MiB 的輸入上限。輸入上限只告訴你是否能將某個來源載入工具。只要你的來源不超過 500 MiB、符合下列其他限制，並且能被瀏覽器解碼，就可以進行處理;至於會產出什麼，則是另一個由預設值與內容決定的問題。

為何瀏覽器式壓縮的上限是 500 MiB

瀏覽器式壓縮無法像桌面編碼器那樣從磁碟串流讀取檔案。取而代之的是，頁面會將來源讀入記憶體，請瀏覽器進行解碼，將每個解碼後的影格繪製到一個有界線的 HTML5 Canvas，然後透過 MediaRecorder 將該 Canvas 錄製成 WebM 檔案。三個對記憶體敏感的階段必須同時存在於同一部機器上:解碼後的來源、Canvas 的背緩衝區，以及錄製器的內部緩衝區。500 MiB 的上限會同時限制這三者。

編碼也是即時進行的，因為 MediaRecorder 是在底層影片播放的同時觀察 Canvas 串流。因此，一段兩分鐘的來源大約需要兩分鐘才能完成，而不是不到一秒。如果讓來源檔大小無限成長，瀏覽器就必須同時容納大型的解碼影格、寬廣的 Canvas 表面，以及運作中的錄製串流，而這是多數消費型硬體無法承受的，否則就會發生錄製掉幀、分頁當機，或記憶體不足錯誤。將輸入限制在 500 MiB 是一項刻意的權衡，目的是讓這條處理流程在各式裝置上都能穩定運作，同時仍能接受足以涵蓋一般家庭錄影、螢幕錄製與手機短片的影片大小。

與 500 MiB 上限並行的其他限制

500 MiB 位元組上限是工具在驗證時檢查的四項相互糾結的限制之一。其他三項分別是五分鐘(300 秒)的長度上限、每邊 4096 像素的像素上限，以及 3840 × 2160 像素的解碼面積上限。每個輸入都必須同時滿足這四項，而不只是位元組上限，因為其中任何一項都可能單獨耗盡瀏覽器資源。

舉例來說，一段一分鐘的 8K 母帶在位元組數上可能遠低於 500 MiB，但解碼面積會超過 3840 × 2160，因此工具會以這個理由拒絕。反之，一段半小時、解析度為 640 × 480 的螢幕錄影，大小可能遠低於 500 MiB，卻仍會觸發五分鐘的長度限制。驗證流程會先進行副檔名或 MIME 檢查，接著是位元組上限，然後是長度檢查，最後是每邊與解碼面積的檢查;任何一項失敗都會產生錯誤，不會提供下載。

如何在 500 MiB 限制內使用影片壓縮工具

  1. 在瀏覽器中開啟 影片壓縮工具，並確認要壓縮的檔案位於同一台裝置上，因為不會有任何資料上傳到伺服器。
  2. 選擇一段瀏覽器可解碼的影片，其位元組大小不超過 500 MiB、長度不超過五分鐘、任一邊長不超過 4096 像素，且解碼面積不超過 3840 × 2160 像素。副檔名可以是 MP4、WebM、MOV、M4V 或 Ogg，但實際能否解碼仍取決於你目前瀏覽器中安裝的編解碼器。
  3. 從三種預設中選擇一種。Small 將寬度上限設為 640 像素，目標幀率為 24 fps。Balanced 將寬度上限設為 1280 像素，目標幀率為 30 fps。Quality 將寬度上限設為 1920 像素，目標幀率為 30 fps。每種預設都會保留來源長寬比，絕不會放大來源，並會將輸出尺寸向下取整到偶數像素值。
  4. 開始壓縮，並保持分頁開啟，讓來源即時播放。編碼所需的時間大致與來源本身相同，因此一段三分鐘的影片大約需要三分鐘的分頁關注時間。
  5. 來源播放結束後，檢視回報的輸出尺寸、輸入位元組數、輸出位元組數，以及帶正負號的百分比變化。這個百分比僅根據兩個實際檔案大小計算，正數代表輸出真的比較小。
  6. 下載 WebM 檔，從頭到尾播放一遍以確認影像與聲音，然後再刪除原始檔。

當 500 MiB 限制並非你工作的真正瓶頸時

有時候真正的瓶頸是輸出目標大小，而不是輸入上限。如果你需要的檔案小到足以附加在電子郵件中，或塞得進聊天應用程式的上傳限制，那 500 MiB 的輸入上限基本上與你無關:你仍然會遠低於它。在這種情況下，更有用的是那些說明如何產出特定小檔案的指南，例如如何在不上傳的情況下將影片壓縮到 25MB。只有當你的來源檔太大而無法載入時，500 MiB 限制才會成為具約束力的限制，這種情況通常發生在長時間的螢幕錄影或高位元率 4K 原檔上。在這些情況下，務實的做法是使用本地工具或桌面工作流程預先修剪影片，將長度壓到五分鐘以下，然後再送入壓縮工具。

對於真正大型的檔案、需封存的母帶、需要兩趟速率控制、固定關鍵影格間隔，或需要跨平台一致輸出的情況，合適的工具根本不是瀏覽器處理流程。一套受維護的桌面編碼器，例如搭配審慎指令使用的 FFmpeg，提供瀏覽器 MediaRecorder 無法比擬的控制項，包括 VP9 兩趟編碼、精確的位元率目標，以及可設定的 GOP 結構。

預設參數與輸入限制一覽

下表彙整了官方定義的預設參數與輸入限制，讓你了解 500 MiB 上限在整份工具合約中的位置。

設定 數值 用途
Small 預設 640 px 寬度上限，24 fps 目標 聊天與電子郵件適用的最緊湊 WebM 輸出
Balanced 預設 1280 px 寬度上限，30 fps 目標 720p 等級的通用輸出
Quality 預設 1920 px 寬度上限，30 fps 目標 1080p 等級輸出，以 8 Mbps 為上限
位元率範圍 180 kbps 至 8 Mbps 每像素位元率啟發式演算法可選取的範圍
輸入位元組上限 500 MiB(524,288,000 位元組) 限制記憶體與 Canvas 作業量
輸入長度上限 300 秒(5 分鐘) 限制即時播放編碼
輸入每邊上限 4096 像素 限制解碼後的影格尺寸
輸入解碼面積上限 3840 × 2160 像素 限制解碼後的總像素數

請記住，所有四項輸入上限必須同時滿足。一個 600 MiB 的檔案即使符合其他所有限制，仍會因為位元組上限而被拒絕;而一個 200 MiB、長度為 12 分鐘的檔案，則會因為長度上限而被拒絕。MediaRecorder 本身執行的是 W3C 定義的 MediaStream Recording API，並以 HTMLCanvasElement.captureStream() 作為其來源，因此上述限制反映了該流程在一般硬體上的實際運作範圍。

若想更深入了解，請參閱 影片壓縮應該得到什麼結果。