一位客戶曾經要求我短暫的錯誤螢幕錄製。 捕獲為 212 MB，持續四分鐘，這是視網膜顯示器以每秒 60 幀的費用花費您，他們的郵件伺服器在我計算出錯誤訊息中的 25 MB 限制不是我必須擊敗的號碼之前將其反彈了兩次。 附件是基於 base64 編碼的，因此檔案比左側大大約三分之一。 我需要低於大約 18 MB，而不是 25。 錄音以 6 MB、720p、沒有音訊的速度出現，並且看起來非常清晰，因為錯誤的螢幕錄製主要是一個靜態頁面，其中有游標在其上移動，並且壓縮得很好。 有用的教訓不是一個背景。 就是這些作業中的每一個都是相同的三行計算，一旦你能做到，你就停止猜測。
TL;DR: 品質等級不會給你一個檔案大小，因為恆定速率因素是品質目標，而結果大小取決於鏡頭承載的動作。 要達到硬極限，請從中向後工作：以每秒為單位的千比特目標位元率是大小為 8 的大小，除以秒的持續時間，除以 1000。 然後選擇正常位元率在該數字下的解析度。 將 1080p 降至 720p 比任何優質滑桿節省更多，而丟棄音訊所需的音訊也比人們預期的要多。 那個 視訊壓縮機 在 Toolz.dev 上，透過 ffmpeg 編碼在您自己的瀏覽器標籤中編譯為 webassembly，在它開始之前顯示估計值，並且從不上傳檔案。
為什麼品質設定永遠不會向您承諾尺寸？
因為壓縮影片的兩種最常見的方法回答了不同的問題，而產生更好結果的一種方法是無法提前告訴你大小的一種。
目標比特率 模式說：每秒使用 2 兆位元，不管需要什麼。 然後大小是算術的，完全可以預測，品質會瘋狂地擺動。 一張靜止的標題卡和一張手持的雨水都得到 2 Mbps，所以標題卡浪費了大部分，雨看起來像濕礫石。
常數速率 模式說：保持這種品質，花費任何需要的東西。 簡單的框架得到很少，硬框得到很多，而且畫面在視覺上保持甚至從頭到尾都保持不變。 大小就是這樣。
每個現代編碼器都推薦第二個編碼器用於任何未直播的內容，這是壓縮器在這裡使用的。 成本是按下按鈕之前頁面上的數字是估計值，源自於該解析度和品質的典型位元率，而真實數字會隨著素材移動。 靜態螢幕錄製通常以估計的一半降落。 移動水的手持鏡頭可以落在上面。 五彩紙屑、雪、風和相機顆粒是四件事，超出了任何估計，因為它們都接近隨機噪音，而噪音是壓縮無能為力的一件事。
選擇關卡時選擇什麼是 CRF？
對於 8 位 H.264，比例從 0 到 51，其中 0 是無損的，51 是無法觀看的，並且 FFMPEG H.264 編碼指南 將預設值設為 23，將 sane 工作範圍約為 17 至 28。 值得記住的屬性是比例是對數的：大約 6 個變化大約是比特率的一半或翻倍。 在您嘗試之前，這個單一的事實會告訴您每個關卡的作用。
壓縮機提供三個，而不是滑桿，因為 CRF 26 和 27 之間的差異是不可見的，而 23 和 33 之間的差異是重點。
| 級別 | H.264 CRF | vp9 CRF | 音頻 | 是為了什麼？ |
|---|---|---|---|---|
| 光 | 23 | 31 | 160 kbps | 存檔副本和鏡頭，您將再次編輯。 靠近足夠的視覺無損。 |
| 平衡 | 28 | 36 | 128 kbps | 普通的答案。 大約一半的光速，在筆記型電腦螢幕上，您必須尋找差異。 |
| 強 | 33 | 42 | 96 kbps | 達到硬極限。 人工製品開始顯示在詳細的鏡頭中，沒有人介意上傳聊天。 |
VP9 數字是一個單獨的比例，這就是它們看起來不相關的原因。 光線 31 正是 Google 的 VP9 對視訊點播的建議 列為 1080p 的目標品質，該表的其餘部分值得保留：720p 為 32，480p 為 33 或 34，4k 為 15。
哪個節省了更多空間、品質較低或像素更少？
像素更少，有很大的邊距，而且它並不接近。
解析度是一個二維的量。 從 1080p 到 720p 不是第三次折扣，它減少了 207 萬像素到 92 萬像素，因此編碼器在做出單一品質決定之前，要描述的像素要少 56%。 文件大致如下。 從 4K 到 1080p 會刪除其中的四分之三。
這是一分鐘剪輯的一分鐘，使用工具估計的典型位元率，按來源高度和水平。 包括音訊。
| 來源 | 光 | 平衡 | 強 |
|---|---|---|---|
| 4k (2160p) | 106 兆位元組 | 61 兆位元組 | 35 兆位元組 |
| 1080p | 35 兆位元組 | 20 MB | 11 兆位元組 |
| 720p | 20 MB | 12 兆位元組 | 7 兆位元組 |
| 480p | 10 兆位元組 | 6 兆位元組 | 4 兆位元組 |
讀到它。 向下移動一個步驟 品質列可節省約 43%。 向下移動一步，解析度列也可以節省約 42%，這看起來像是平手，直到您注意到高品質的步驟在三個之後運行並花費您可見的文物，而分辨率步驟在大多數人會觀看的屏幕上根本不花任何錢。 鬆弛訊息中顯示的 1080p 剪輯顯示在大約 400 像素寬的盒子中。
嘗試的順序，然後：將解析度降到觀眾實際使用的任何內容，保持品質平衡，並且只有在您還沒有成功的情況下才能達到強勁的水平。
你如何在 8 MB 這樣的硬限制下著陸？
倒退。 整個計算是一行，是唯一值得學習的視訊算術。
# total bitrate (kbps) = target size (bytes) x 8 / duration (s) / 1000
#
# 8 MB, 45-second clip:
# 8,000,000 x 8 / 45 / 1000 = 1,422 kbps total
# minus 96 kbps of audio = 1,326 kbps for video
#
# 1080p strong is ~1,400 kbps video -> about 8.4 MB. Just over.
# 720p strong is ~800 kbps video -> about 5.0 MB. Comfortable.
#
# the equivalent single pass, if you have ffmpeg installed:
ffmpeg -i input.mp4 -c:v libx264 -crf 33 -preset fast \
-vf scale=-2:720 -c:a aac -b:a 96k \
-movflags +faststart -pix_fmt yuv420p output.mp4
三件事使這在實踐中變得可靠。
- 離開頭部空間。 瞄準 80% 的限制。 CRF 不會達到大小目標，它超過一次是您發送檔案的時間。
- 如果透過電子郵件計算編碼開銷。 Base64 將每 24 位元輸入表示為 4 個字元，by RFC 2045，所以一個附件在電線上膨脹了三分之一。 25 MB 郵箱限制約為實際檔案的 18 MB。
- 不要相信你記得的號碼。 截至 2026 年 8 月，Discord 的免費上傳限制為 8 MB，然後是 25 MB，然後是 10 MB，然後是 20 MB。 Gmail 多年來一直保持在 25 MB。 Whatsapp 會重新壓縮您發送的任何內容。 在你需要的日期檢查限制，然後做算術。
如果夾子比您想要顯示的東西長，更好的方法是剪掉它而不是擠壓它。 將持續時間減半將尺寸減半，這是無法與之匹敵的。 那個 視訊修剪器 當切割落在關鍵影格附近時，將完全不重新編碼，結果是大小一半的字節相同鏡頭。
降低幀速率有幫助嗎？
比你想像的要少，而且看起來比清單上的其他任何東西都要糟糕。
原因是連續的幀已經相互壓縮。 視訊編解碼器儲存一整幀，然後描述差異，因此 60 fps 剪輯中的 31 幀幾乎是免費的，因為它幾乎與第 30 幀相同。 扔掉它並不能保存你想像它節省的位。 在典型的速率下，節省的速度比免費的更接近線性，因此 60 fps 到 30 fps 可能會起飛三分之一而不是一半，而 30 fps 到 15 fps 可以讓您在任何相機移動上都能看到 Judder。
有兩種情況是正確的電話。 大部分靜態內容的螢幕錄製在 15 fps 時不會出現任何清晰的功能，而這正是您通常最努力低於限值的情況。 而你正在轉換為頁面動畫的鏡頭，觀眾沒有看動作，而是注意到它，可以很好地存活 12 到 15 fps。
對於有個人或相機移動的所有東西，請不要單獨使用幀速率並降低解析度。
音訊應該生存嗎？
問音訊是做什麼用的，因為它不是免費的。
以 128 kbps 的音訊錄製 10 分鐘，在圖片獲得一點之前，聲音為 9.6 MB。 如果該音訊是帶有房間嗡嗡聲的靜音螢幕截圖，或者您要更換的音樂，或者您已經轉錄的語音軌道，那麼放棄它是最簡單的可用節省，而且它不會花費觀眾任何費用。 壓縮機有一個開關，它通過 -an 並完全省略音訊串流。
當聲音很重要時，水平會從 160 降到 128 到 96 kbps，這是傳統點。 96 Kbps AAC 足以用於語音和聽得很薄的音樂。 如果您想要單獨的音訊，作為轉錄或編輯的文件， 抽象器 不觸摸影片就拉出軌道， 音頻轉換器 將按照自己的條件重新編碼。
一個細節讓人抓緊。 沒有音訊曲目的影片在大多數播放器中會靜音播放，並且無法在一些期望曲目靜音的舊行動瀏覽器中自動播放。 如果剪輯進入網頁，無聲的 8 KBPS 軌道有時比沒有更安全，儘管今天發貨的每個瀏覽器都正確處理僅視訊的 MP4。
Webm 值得多等待嗎？
這完全取決於誰打開文件。
WebM 容器中的 VP9 以可比的可見品質降落約比 H.264 小四分之一。 這是一個真正的收益，在您自己的網站上，唯一的要求是瀏覽器可以玩它，WebM 通常是更好的檔案。 Chrome、Firefox 和 Edge 已經支援 VP9 十年了，Safari 也支援 14 版。
成本出現了兩次。 VP9 編碼比 X264 慢，在瀏覽器中基本上如此，一個細節讓任何手動執行命令的人都出現了：VP9 只有在位元率明確為零時才會尊重品質目標。 通過 -crf 36 單獨使用它，編碼器悄悄地使用預設位元率並忽略您。 它需要 -crf 36 -b:v 0，這是工具發送的。
第二個成本是所有不是瀏覽器的成本。 聊天應用程式、CMS 上傳欄位、影片編輯器、PowerPoint、檔案管理器中的預覽窗格、您的客戶手機：其中許多可以接受 MP4 並在 WebM 上聳聳肩。如果檔案要發送給一個人，請使用 H.264 發送 MP4。 如果它進入您控制的頁面，WebM。同樣的拆分貫穿整個格式問題，其中 回復指南 轉換方面的覆蓋。
為什麼壓縮的 MP4 有時會拒絕開始播放？
因為索引結束，它是你永遠不應該離開的標誌。
MP4 保留一個描述每個幀開始位置的目錄。 編碼器正常編寫，一邊發現所有這些，並在文件末尾寫入表格。 從磁碟播放，這很好。 透過 HTTP 服務，這意味著播放器無法在擁有整個檔案之前開始，因此聊天應用程式或 CMS 中的 40 MB 影片坐在那裡，下載時無所事事，然後開始。
-movflags +faststart 第二次通過完成的文件並將該表移到前面。 編碼需要更長的時間，影片會在一秒鐘後開始播放。 壓縮機生產的每個 MP4 都有它。
該命令中的另外兩個標誌用於相容性而不是大小。 -pix_fmt yuv420p 強制 4:2:0 色度子採樣，因為 4:2:2 或 4:4:4 MP4 是有效的，並且拒絕在一長串硬體解碼器上播放。 並寫了比例過濾器 scale=-2:720 而不是 scale=-1:720，因為 H.264 需要偶數像素尺寸和 -2 將計算寬度四捨五入到偶數。 要求一個奇數寬度，編碼失敗，其中「寬度不能被 2」整除，而不是縮放到接近的東西。
為什麼壓縮兩次看起來更糟？
發電損失，比人們預期的更陡峭，因為有損壓縮不是顯著的。
第一個編碼丟掉它判斷眼睛不會錯過的細節並留下自己的人工製品：邊緣輕微阻塞，漸變平滑，對比度高響起。 第二個編碼無法知道那些人工製品不是圖片。 它將它們視為值得保存的內容，花費一些描述它們，並在頂部添加自己的內容。 在同一剪輯上進行三輪平衡壓縮看起來比一輪強力更差，文件尺寸更大。
所以實際規則很短。 每次都從原始壓縮，從不從您已經製作的副本中壓縮。 如果您需要輕量級檔案版本和小版本來發送，請從原始碼同時進行。 如果檔案已經透過上傳時重新壓縮的平台，其中大部分是，請將您下載的內容視為第二代。
這是控制的相同算術 圖像壓縮 而 JPEG 反覆保存的原因變成了泥濘，同樣的原因 PDF壓縮機 處理文件中的圖像，而不是整個文件。
文件會離開你的機器嗎？
不，對於改變工具可用的影片。
編碼運行 ffmpeg 編譯為 webassembly，在瀏覽器標籤中執行。 檔案從磁碟讀取到頁面記憶體，在那裡編碼，然後作為下載傳回。 打開 DevTools，切換到網路面板，壓縮某些內容，然後觀看：沒有請求攜帶影片。
三個後果隨之而來。
沒有上傳，所以什麼都不保留。 伺服器上沒有副本等待保留策略刪除它，因為沒有製作副本。 對於未發布的產品演示、NDA 下的鏡頭，或任何不同意第三方上傳的人，這就是可用與不可用的區別。
限制是瀏覽器，而不是計劃。 整個檔案進入 Tab 記憶體，因此頁面最多可接受 500 MB 並在 30 分鐘內單次通過，並且在您選擇檔案時而不是在下載 4 兆位元組的引擎和兩分鐘的編碼後檢查兩者。 沒有隊列，沒有浮水印，沒有帳戶，也沒有要購買的尺寸。
第一次運行速度較慢。 FFMPEG WebAssembly 捆綁包下載一次，需要幾秒鐘，然後會緩存。 該工具在第一次壓縮時而不是在頁面打開時加載它，因此頁面本身保持快速。
什麼時候桌面編碼器是正確的工具？
當上面的數字不再是約束。 瀏覽器標籤是一個合理的編碼器和一個糟糕的視訊管道，值得清楚的是線落在哪裡。
超過 500 MB 的檔案或超過半小時的剪輯，在其中，標籤記憶體是真正的極限。 一批原生，因為 40 個剪輯通過一個 shell 中的一個循環會通過任何介面超過 40 次。 當您需要兩通道編碼才能達到精確的大小時，請使用原生，單 CRF 通行證無法承諾。 並使用原生硬體編碼，GPU 將在 20 秒內完成 WebAssembly 需要四分鐘的時間。
對於需要在接下來的五分鐘內低於限制的剪輯，在筆記型電腦上，無需安裝任何東西或將鏡頭交給陌生人，瀏覽器是更快的路徑。 那是工作 壓縮機 是為 轉換器 用於更改格式和 影像壓縮器 對於同樣的問題，一維下降。
