365MB压缩成25MB视频文件？我用Golang亲手实现，竟然真的可行

事情是这样的，上周我朋友发了个视频过来，365MB，说让我帮忙处理一下，我一看，好家伙，一个15分钟的会议录像，就一个人对着镜头讲话，居然占了300多兆，我的硬盘当时就发出了“哔哔”的报警声。

我脑子里冒出一个念头：是不是能把这个365MB的视频压缩成25MB？听起来像魔术，但我知道，理论上完全可行，尤其是当我们选对工具的时候，而这一次，我决定用Golang亲手写一个视频压缩工具。

为什么Golang适合做视频压缩？

你可能会有疑问，视频压缩不是应该用FFmpeg或者Python吗？Golang能行？没错，Golang不是万能的，但它的并发模型和可执行文件大小决定了它特别适合做这种工具。

• 并发处理切片：视频压缩可以拆成音频、视频、关键帧提取几个任务,Go的goroutine天然适合并行。
• 跨平台编译：我写完编译成一个二进制文件，丢到Windows、Linux、macOS上都能跑,不用装环境。
• 调用FFmpeg方便：Golang通过os/exec调用FFmpeg,写起逻辑来比bash脚本清晰一万倍。

我说这些不是瞎吹，是真实体验，你如果试过一次用Go调用FFmpeg分片压缩,就会觉得以前写批处理脚本的日子简直像原始人。

压缩的核心思路：365MB → 25MB

先别急着写代码，我问你个问题：视频为什么这么大？

常见的原因就几个：

1. 码率太高——比如原视频是20Mbps，但内容只是固定机位的小窗口讲话
2. 分辨率过剩——4K拍个PPT，完全没必要
3. 编码陈旧——如果还是H.264甚至MPEG-2，换成H.265/HEVC能省一半空间

目标25MB，算下来15分钟的视频，平均码率大概需要控制在 220kbps 左右，什么概念？YouTube上480p视频的码率一般就500-1000kbps，220kbps属于很低了，但对付这种固定场景（背景不动、人脸很少动、画面变化小）完全够用。

我当时的策略是三步走：

理论计算：码率220kbps × 900秒（15分钟） ≈ 24.7MB，加上容器开销，正好25MB左右。数字对上了。

用Golang写压缩脚本——真实踩坑记录

说干就干，我写了一个Golang程序，核心逻辑不复杂，就是调用FFmpeg命令，但是有几个坑，我得说给你听,因为网上教程基本不提。

第一个坑：Golang里调用FFmpeg时，参数拼接容易错。

你想，FFmpeg参数很长，而且不同操作系统路径分隔符不一样，我一开始直接用Sprintf拼接字符串，结果在Windows上路径带了空格，程序直接炸了，解决方案很简单：用exec.Command，把参数拆成切片传进去,而不是拼成一个长字符串。

cmd := exec.Command("ffmpeg",
    "-i", inputFile,
    "-vf", "scale=640:360",
    "-c:v", "libx265",
    "-crf", "28",
    "-c:a", "aac",
    "-b:a", "64k",
    outputFile)

第二个坑：CRF参数不能随便抄别人的。

CRF是画质控制参数，H.265里一般是0到51，越低画质越好，文件越大，我一开始用了网上的CRF 24，压缩完一看，28MB，超过目标了，改成CRF 28后，文件大小刚好掉到25.3MB，画质肉眼几乎看不出来变化——因为视频安静,背景是白墙。

第三个坑：压缩时间比你想象的长。

Golang虽然快，但FFmpeg本身慢，15分钟视频用软件编码H.265，我的笔记本跑了大概 23分钟，别急，这很正常，你可以加-preset ultrafast来加速，但文件会稍微变大,我测试下来大概会从25MB变成31MB。

我最后选择了-preset fast，既不太慢,文件大小也控制住。

实际效果：我真的把365MB压到了25MB

下面是我跑完程序后得到的真实数据：

我播放了一下压缩后的视频，说实话，文字都能看清——因为是PPT录屏，字稍微有点模糊，但完全不影响阅读，人脸的话，肤色过渡稍微有点不自然，但这是HEVC低码率的通病,能接受。

这个工具我后来打包成compress_video.exe，扔给朋友，他双击就运行了，他说：“卧槽，真能压到25MB？”这就是Golang的好处——你根本不需要给用户装环境。

但我要说句实话：不是所有视频都能这么压

这可能是整篇文章里最重要的一句话：我之所以能把365MB压成25MB，是因为原视频符合“低复杂度场景”。

什么叫低复杂度场景？就是画面变化缓慢、背景固定、没有快速运动。

• 会议录像（一个人坐着说话）
• 课程录屏（PPT翻页）
• 监控视频（静止背景）

但如果是这些场景,就别抱太大希望：

• 城市街景、风吹草动、水流 —— 背景一直变，压缩率会骤降
• 动作电影、体育比赛 —— 快速运动场景下，低码率会全是马赛克
• 带透明字幕或复杂特效的视频 —— 编码器很难找到冗余

我当时试过一个30秒的城市风光视频，从80MB压到8MB，结果画面全是块状，根本不能看，所以类型决定压缩极限。

代码改进：我加了几个愚蠢但实用的功能

写完基本压缩后，我觉得不够“Golang味”,于是加了几个小特性：

用通道传递进度条：压缩时FFmpeg默认输出日志到stderr，我写了个管道解析，实时计算百分比，注意FFmpeg输出进度是“time=00:03:21.23”这种格式，解析起来很烦,但可以用正则搞定。

自动检测GPU加速：如果你的电脑有NVIDIA显卡，可以用-c:v h264_nvenc走硬件编码，速度能快接近10倍，Go里写个简单的“探针”函数，用nvidia-smi检测一下,有显卡就切到硬件编码。

多视频批量处理：用filepath.Walk扫目录，然后每个视频开一个goroutine去压缩，注意要控制并发数，我用worker pool模式，同时最多跑3个ffmpeg进程,否则CPU满载电脑就卡死了。

这些代码加起来不到200行，但比网上大部分shell脚本稳定——至少你不会因为路径里有中文就报错。

最后让我说点狼狈的

其实我第一次跑的时候，直接把原文件覆盖了，结果压缩后的25MB文件坏了，原文件也没了，是的，我翻了垃圾桶，没找到，还好是朋友发的,我又让他重传了一次。

后来我加了自动备份逻辑：在压缩之前，用io.Copy把原文件复制到./backup/目录下，这就用到了Golang的os包和io操作，写起来两三行，如果你抄我的代码，记得加这个功能,别像我一样蠢。

还有一个细节：我一开始用fmt.Println打印进度，结果终端里刷成一片，根本看不清，后来改成用\r回车符刷新同一行，配合os.Stdout.Write,才算像个正经工具。

代码现在我放在GitHub上，有需要的可以搜“go-video-compress-25mb”，不过README写得很烂，我还没时间改,实用就好。

写这篇的时候，我电脑上那个压缩视频还在播，25.1MB，画质凑合能看，说真的，如果我把这个工具卖给一些做线上教育的小公司，说不定能换几杯咖啡钱，但算了，免费开放出来，大家拿去玩吧，说不定你也能用Go压出比25MB还小的视频,到时候告诉我一声。