Discord 拒絕免費帳號上傳超過 10MB 的檔案,因此任何超過幾秒鐘的剪輯片段通常都必須重新編碼 — 而不是僅僅修剪 — 才能在聊天或伺服器中發送。
10MB 上限適用於上傳的檔案本身,而不是來源長度,因此一段 30 秒的螢幕錄影或一分鐘的手機影片幾乎一定會超過這個限制。Discord 並未提供聊天內建的壓縮工具,因此讓檔案符合大小的唯一方式,就是以較低的解析度、較低的幀率以及較低的位元率重新錄製,藉此縮減位元組大小而非縮短時長。Lizely 的 Video Compressor 正是為此任務而設計:它會在本地重新編碼單一瀏覽器可解碼的剪輯片段 — 內容不會離開分頁 — 並在結束時回報來源與輸出 WebM 之間精確的位元組變化。由於每個 Discord 剪輯片段本來就必須重新編碼,因此目標是選擇一個能讓檔案大小落在 10MB 或以下的預設,然後在分享前驗證結果,因為 WebM 在 Discord 中的播放表現會依客戶端而異。
為什麼 Discord 將上傳上限設為 10MB
在大多數地區,Discord 免費方案將每個附件的檔案上傳上限設為 10MB;訂閱使用者可獲得更高的上限,但大多數使用者最先遇到的仍是免費上限。這個上限適用於上傳的位元組大小,而非時長,且 Discord 在上傳過程中不會重新編碼。手機拍攝的 1080p 影片每分鐘通常就有數十 MB,而一段 4K 剪輯在短短幾秒的畫面中就可能輕鬆超過 100MB。修剪並無法解決問題,因為每幀的位元組成本大致不變,而 Discord 仍會以整個檔案大小來衡量。真正能產生影響的兩個參數是解析度(寬度越小,每幀像素越少)與位元率(目標值越低,每秒每像素的位元組越少),幀率則是次要的控制桿。這就是在此情境下「壓縮」的真正意義:以更嚴格的預算重新錄製影片,讓最終檔案能符合 Discord 的容量限制。
背景動畫與螢幕錄影通常比實景影片更容易壓縮,因為它們的動態與雜訊都較少。含有相機晃動、顆粒感或快速剪切的實景片段編碼效果不佳 — 這並不代表工具故障,而是代表動態高的內容無論使用何種軟體,都會抗拒積極的壓縮。如果第一個預設無法將檔案壓到 10MB 以下,下一步應改用更嚴格的預設(Small),而非假設工具失敗。
Video Compressor 實際做了什麼
Video Compressor 完全在當前分頁中執行。該頁面會讀取所選的檔案,透過 HTMLMediaElement 播放,將每一幀繪製到一個大小符合所選預設的不透明 Canvas 上,並以瀏覽器所回報的第一個支援 WebM 的編解碼器錄製該 Canvas 串流 — 優先為 VP9(若可用),否則為 VP8,再否則為通用的 WebM,這在 W3C MediaStream Recording 規格說明以及 MDN 的 MediaRecorder 參考文件中均有記載。當來源播放完畢時,工具會回報實際的輸出尺寸、輸入與輸出的位元組數,以及兩者之間帶正負號的百分比變化;它不會猜測省下的容量。
輸出格式一律為 WebM。這是有意為之的設計:瀏覽器對使用 MediaRecorder 產生 MP4 的支援在 Chromium、Firefox 與 Safari 之仍不一致,因此 WebM 是跨瀏覽器時較安全的目標。Discord 接受 WebM 上傳,包括聊天附件,因此對接收端而言,格式的轉換通常感覺不到。如果接收端堅持要 MP4,最乾淨的做法是在本地端以經審核的指令執行 FFmpeg,而非假設任何瀏覽器端的工具能產生一個到處都能播放的 MP4。
該工具在開始前會強制執行一組嚴格的限制:來源必須能解碼(編解碼器已安裝於目前的瀏覽器中)、位元組大小最多 500 MiB、時長最多五分鐘、每邊最多 4096 像素、解碼區域最多 3840 × 2160。任何一項未通過都會產生錯誤訊息且不會提供下載 — 不會有靜默截斷的情況。由於編碼器即時監聽 Canvas 串流,兩分鐘的來源大約需要兩分鐘來處理。頁面會以來源播放時間為基準回報進度,因此可以清楚判斷工作仍在執行或已停滯。
符合 10MB Discord 目標的預設
三個預設決定了輸出的上限。它們是明確的產品選擇,而非通用的最佳值,在檔案大小上有不同的取捨。下表根據已揭露的工具參數,概述每個預設的實際作用:
| 預設 | 寬度上限 | 幀率 | Discord 最佳用途 |
|---|---|---|---|
| Small | 640 px | 24 fps | 較長的剪輯片段與動態高的畫面,在這種情況下能否塞進 10MB 比視覺細節更重要 |
| Balanced | 1280 px | 30 fps | 短剪輯(約 20 秒以內),希望看起來像 HD 播放且在 10MB 以下仍有餘裕 |
| Quality | 1920 px | 30 fps | 短暫的剪輯片段,Discord 的 10MB 並非主要限制,且觀看者希望獲得最高的細節 |
這些預設都不會放大來源;每一個都會保留長寬比,並將寬度與高度向下取整為偶數像素值,以獲得更廣泛的編解碼器相容性。每個預設都套用一個有界限的每像素位元數啟發式來選擇錄製位元率,範圍從 180 kbps 到 8 Mbps。若目標為 10MB 的 Discord 上限,請從 Small 開始。如果輸出遠低於 10MB 且剪輯很短,可改用 Balanced 重試以恢復視覺上的銳利度。在工作中切換預設會使先前的錄製失效,並釋放暫時性的物件 URL。
如何在瀏覽器中為 Discord 壓縮剪輯片段
- 確認來源符合工具的限制:最多 500 MiB、五分鐘、解碼區域 3840 × 2160,且目前的瀏覽器能解碼。僅有有效的 .mp4 或 .mov 副檔名並不足夠;若缺少編解碼器,頁面會在任何重新編碼開始前拒絕該檔案。
- 開啟 Video Compressor 並從您的裝置選擇檔案。該頁面會在本機讀取位元組;不會上傳至任何伺服器。
- 選擇一個預設。若目標為 10MB 的 Discord 上限,請選擇 Small。只有當剪輯夠短、在上限下仍有明顯餘裕時,才改用 Balanced。
- 開始壓縮。來源會以即時速度播放一次,同時 Canvas 進行錄製。請將分頁保持在前景,因為嚴重的背景節流可能會中斷播放。
- 等待頁面回報實際的輸出尺寸、輸入位元組、輸出位元組以及帶正負號的百分比變化。該百分比僅根據這兩個 Blob 的大小計算得出。
- 點擊下載連結,將產生的 WebM 儲存到您的裝置上。
- 在刪除來源之前,將下載的 WebM 從頭到尾播放一次。確認畫面、聲音與總時長;只有在瀏覽器透過 captureStream 公開可擷取的音訊軌時,音訊才會被保留。
- 若輸出仍超過 10MB,不要期望以同一預設重跑會得到不同結果 — 請改用 Small,或是先修剪檔案後再重新編碼修剪後的片段。
發佈前針對 Discord 的專屬檢查清單
檔案儲存到磁碟後,在尚未完整觀看並確認符合 Discord 限制前,請將其視為未經驗證。在 Discord 中分享時,最常見的疏失是那些聊天客戶端不會察覺的靜默問題:一個略大於 10MB、在上傳時靜默失敗的檔案;一個在接收端客戶端中第一幀或最後一幀無法解碼的 WebM;或是一段有影像但沒有聲音的剪輯,因為瀏覽器的 captureStream 並未公開音訊軌。
請以您平常使用的播放器開啟下載的 WebM。透過拖曳到結尾來確認時長。若發送目的地很重要,先將一份副本以私訊傳給自己 — Discord 的 10MB 上限是在伺服器端強制執行的,因此即使本機檢視器能開啟,10.1MB 的檔案仍會被拒絕。若結果超過上限,請改用其他預設或先修剪,而不是抱著僥倖心態以同一預設重跑以期待不同的大小。該工具回報的是實際位元組數而非估計值,因此同一預設執行兩次所產生的檔案大小通常相近。
同樣的方法也適用於任何其他具有 10MB 式附件限制的即時通訊軟體。若需要歸檔保真度、精確的編解碼器設定檔或字幕保留,維護良好的桌面編碼器(如 FFmpeg)是較安全的選擇 — 瀏覽器工具是為快速的本地重新編碼而優化,並非為了符合認證傳遞規格。在接收端確認該剪輯能在他們的客戶端中播放之前,請保留原始檔案。
延伸閱讀:如何在不上傳的情況下將影片壓縮至 25MB。