FFmpeg把GIF壓縮玩出花：15幀比30幀省一半空間

你剛寫完一個漂亮的終端演示，錄屏3秒，導出GIF——20MB。扔進GitHub README，加載轉圈5秒。同事私聊你："能不能換個格式？"

這就是開發者的日常困境。視頻太重，靜態圖不夠，GIF卡在中間進退兩難。更煩的是，大多數人只會用錄屏軟件的默認設置，或者打開Photoshop的時間軸面板，像操作航天飛機一樣復雜。

其實GIF是個1989年的老古董。它的技術規格GIF89a定義了一個硬約束：每幀最多256色。這就是為什么照片轉GIF會滿屏色帶和噪點，而終端錄屏卻清晰銳利——顏色簡單，壓縮算法（LZW，一種無損壓縮）能高效工作。

一幀一幀拆解：GIF的底層賬本

GIF不是視頻，是帶時間軸的幻燈片。每幀獨立存儲，附帶三個關鍵屬性：

延遲時間：這幀顯示多久，單位是1/100秒。15 FPS對應約7個單位。

邊界框：這幀實際占用的像素區域，可以比畫布小。

處置方法：下一幀來之前，這幀怎么處理。

處置方法是優化利器。"保留原位（Leave in place）"讓新幀疊在舊幀上，只傳變化像素；"恢復背景（Restore to background）"先擦除再重畫。一個光標閃爍的終端錄屏，用前者可能只有幾十KB，用后者會暴漲——每一幀都在重復傳輸整個黑屏。

理解這個機制，你就能看懂為什么有些GIF工具產出的文件大得離譜：它們在無腦使用"恢復背景"，或者根本不做幀間差分。

兩條命令行路線：FFmpeg vs ImageMagick

FFmpeg是瑞士軍刀，適合視頻轉GIF?；A用法一行：

ffmpeg -i input.mp4 -vf "fps=15,scale=600:-1:flags=lanczos" -c:v gif output.gif

這條命令做了三件事：降采樣到15幀、等比縮放到600像素寬、用lanczos算法重采樣（比默認的bilinear更清晰）。但顏色可能發灰，因為FFmpeg在單趟編碼里臨時生成調色板。

雙趟流程解決色彩問題。第一趟分析全片，生成最優256色調色板：

ffmpeg -i input.mp4 -vf "fps=15,scale=600:-1:flags=lanczos,palettegen" palette.png

第二趟用這張調色板重新編碼：

ffmpeg -i input.mp4 -i palette.png -lavfi "fps=15,scale=600:-1:flags=lanczos [x]; [x][1:v] paletteuse" output.gif

ImageMagick走另一條路：把現有圖片序列組裝成GIF。適合編程生成幀的場景，比如用Python matplotlib畫圖、用Puppeteer截網頁：

convert -delay 8 -loop 0 frame_*.png output.gif

-delay 8對應約12.5 FPS（100/8），-loop 0無限循環。組裝完可以二次優化：

convert output.gif -layers Optimize optimized.gif

這個-layers Optimize會自動選擇最優處置方法，合并靜態背景，裁剪幀邊界框。

四個杠桿：把20MB壓到2MB

文件體積失控通常來自四個可調整參數。按影響程度排序：

幀率：30 FPS降到15 FPS，幀數減半，體積大致減半。UI演示不需要電影流暢度。

分辨率：1920×1080的錄屏縮到600寬，像素數降到1/9。README里顯示多大，就縮到多大。

色深：終端錄屏用64色或128色足夠，調色表從256項減到64項，體積再砍30-50%。

幀差分：用gifsicle做專業優化，只存儲變化像素：

gifsicle -O3 --lossy=80 -o optimized.gif input.gif

-O3是最高優化級別，--lossy=80允許80/100的有損壓縮（人眼幾乎不可見）。一個光標移動的終端錄屏，優化前后可能差10倍。

把這些杠桿組合使用：15 FPS + 600寬 + 128色 + gifsicle優化，20MB的原始錄屏壓到1-2MB是常規操作。

工具鏈選型：什么場景用什么

視頻素材（屏幕錄屏、攝像頭）→ FFmpeg雙趟流程，控制幀率和分辨率后生成調色板。

編程生成幀（數據可視化、網頁截圖）→ ImageMagick序列組裝，再用-layers Optimize或gifsicle二次壓縮。

已有GIF需要瘦身 → 直接上gifsicle，-O3 --lossy組合通常足夠。

需要精確控制每幀延遲（比如做加載動畫的節拍）→ ImageMagick更靈活，-delay可以逐幀指定。

有個細節容易踩坑：FFmpeg的palettegen默認只分析前100幀，長視頻可能后半段顏色失真。加參數palettegen=max_colors=256:stats_mode=full讓全片參與分析。

另一個坑是透明通道。GIF支持1bit透明（要么全透要么不透），但FFmpeg和ImageMagick處理透明背景的方式不同，混合使用可能產生白邊或黑邊。需要透明時，建議全程用同一套工具鏈。

GitHub在2023年把單文件顯示上限從10MB提到25MB，但加載體驗沒變。一個2MB的GIF在移動端README里秒開，20MB的會觸發瀏覽器節流，用戶看到空白占位符直接劃走。文件體積不是技術約束，是注意力經濟的硬通貨。