手机里的视频占了几百兆，想发给朋友，微信提示“文件过大”；想上传到某个平台，提示“时长超限”或“体积超标”，我以前也烦这个，直到我试着用Go语言写了一个小工具，能把一个365MB的视频文件硬生生压到25MB，画质居然还说得过去，你可能会说这不可能，但真的，我做到了，今天我就把这套方法掰开揉碎了讲给你听,保证你看完也能自己动手。
为什么视频文件这么大？
先说个最基础的道理，视频其实就是一堆图片快速播放，再加上声音，一秒钟24帧或者30帧，每一帧就是一张图片，一张1920x1080的图片，不压缩的话大概6MB左右，你算算，一秒钟30帧，那就是180MB，一分钟就是10GB，但你看的电影、短视频，哪有这么大？因为压缩技术在里面起了关键作用。
视频压缩的核心就是两件事：去掉重复信息和用数学方法重新编码，比如你拍一段一个人在说话，背景不动，那背景那一块就可以只存一次，后面的帧直接引用，这就是所谓的“帧间压缩”，再比如，画面里有些颜色人眼根本分不清，那就可以把相近的颜色合并，这就是“颜色子采样”。
我一开始也不懂这些，后来读了一本叫《视频编码基础》的老书，才算入了门，书里讲得很清楚，但代码实现全靠自己摸索，Go语言在视频处理这块其实挺冷门,但它的并发模型和简洁语法让我觉得特别适合做这种计算密集型的任务。
我选的编码器：H.264和H.265
你可能会想，到底用啥能把365MB压成25MB？答案是编码器，常用的有H.264和H.265，H.265也叫HEVC，压缩率比H.264高一倍左右，也就是说同样画质，H.265的文件体积只有H.264的一半，但代价是编码更慢,对CPU要求更高。
我用Go语言调用ffmpeg的C库，具体的库叫goav，这是一个Go绑定FFmpeg的第三方库，虽然文档很坑，但能跑，我把视频分辨率从1080p降到720p，帧率从30降到24，然后用H.265编码，码率控制在500kbps左右，你猜怎么着？一个原来365MB的文件，压完之后只有25MB，我专门对比了一下，动态场景有点糊,但静态画面完全能接受。
下面这张表是我实际测试的几个参数组合：
| 分辨率 | 帧率 | 编码器 | 码率(kbps) | 输出大小 |
|---|---|---|---|---|
| 1080p | 30 | H.264 | 2000 | 68MB |
| 720p | 24 | H.265 | 800 | 33MB |
| 720p | 24 | H.265 | 500 | 25MB |
| 480p | 20 | H.265 | 300 | 14MB |
看到没？从365MB到25MB，压缩比超过14倍,这个结果我自己都吓了一跳。
Go语言的并发威力：把压片变快
但有一个问题：编码太慢了，一个20分钟的视频，用H.265编码，单线程得跑半小时，我心想，Go语言不是有goroutine吗？能不能把一个视频切成几段，同时编码,最后再拼起来？
说干就干，我用ffmpeg的segment功能先把视频切成若干小段，每段大概30秒，然后用sync.WaitGroup同时启动多个goroutine，每个goroutine负责编码一段，等所有段都编码完了，再用一个合并的goroutine把片段拼成完整视频,整个过程就像流水线一样。
代码大概长这样：
func encodeSegment(input string, output string, wg *sync.WaitGroup) {
defer wg.Done()
cmd := exec.Command("ffmpeg", "-i", input, "-c:v", "libx265", "-crf", "28", "-preset", "fast", output)
cmd.Run()
}
当然这只是伪代码，实际处理要复杂得多，还要处理音频流、时间戳对齐、容器格式什么的，但核心思想就是这个，我实测下来，4核CPU的情况下，并行编码比串行快了将近3倍，从半小时压缩到10分钟左右，如果是8核或者16核的机器,基本能做到实时压缩。
有人可能会问，切片再合并会不会导致画质下降？其实只要编码参数一致，合并的时候用concat协议，帧级别的数据不会丢失，我专门用PSNR（峰值信噪比）测了一下,差异可以忽略不计。
音频也压一压：OPUS是个好东西
视频压了，音频也不能放水，原文件里音频是AAC格式，码率192kbps，我把它转成了OPUS格式，码率降到64kbps，OPUS是现在公认的压缩效率最高的有损音频编码，在低码率下音质吊打AAC，64kbps的OPUS听起来跟128kbps的AAC差不多，而且OPUS是开源的，Go里直接有gopus这个库可以用。
这样一来，音频从原来的大约20MB降到了7MB左右,省下的空间又够视频多压一点。
一些坑：不是所有视频都能这么压
这条路也不是一帆风顺的，我踩了几个坑,说出来你以后可能也会遇到。
第一个坑：类型影响压缩率，像演讲、教程这类画面变化少的视频，压缩比特别高，但如果是动作片、体育比赛、或者屏幕录制里频繁滚动的代码，那码率根本压不下来，强行压低码率，画面就会变成“方块雨”，我试过一个50MB的游戏录屏,压到20MB就已经没法看了。
第二个坑：H.265的兼容性，很多老手机、老电视不支持H.265硬解，你要是压好了发给朋友，人家打不开，那就尴尬了，所以我现在一般默认用H.264，压缩率差一点，但兼容性好，真要极致压缩，我才会选H.265，同时备注一句“用VLC或者MPV播放”。
第三个坑：时间戳偏移，并行编码后合并，有时候会出现音画不同步，原因是切片的时候没有严格按关键帧切，解决方法是强制ffmpeg在切片时对齐关键帧，加上-force_key_frames "expr:gte(t,n_forced*2)"这个参数，每两秒一个关键帧,这样切片边缘就不会出现断开的问题。
一些小技巧
用Go做这件事,我发现有几个小技巧特别好用：
- 用
os/exec跑ffmpeg：别想着从头实现解码器，那是造轮子，直接调ffmpeg命令行，Go里面用exec.Command挂参数，既简单又稳定，ffmpeg本身是用C写的,性能比任何Go实现的编码库都好。 - 用
runtime.NumCPU()设置并行度：不要贪心，并行度超过CPU核心数，反而会因为上下文切换变慢,一般设成CPU核心数减一比较稳。 - 用
select监听进度：ffmpeg的进度信息是通过stderr输出的，你可以用管道读取，然后用正则解析出time=字段，实时显示进度条,用户体验会好很多。 - 用
encoding/json保存配置：把参数写成JSON文件，方便不同项目复用，比如{"resolution":"720p","codec":"h265","bitrate":"500k","audio":"opus","audiobitrate":"64k"}。
工具已经放在GitHub
我把自己写的这个工具整理了一下，放到了GitHub上，项目名叫GoVideoCompressor，代码大概400行，依赖只有ffmpeg和Go标准库，你如果感兴趣可以直接拉下来跑，肯定还有不完善的地方，比如GUI界面还没写，批量处理也有bug,但核心功能是能用的。
你可能会问，你花了这么多功夫，就为了省点空间？其实不是，这个过程让我理解了视频压缩的本质：它不是在破坏信息，而是在寻找信息里的冗余，就像你写代码，不是代码越多越好，而是能用更少的表达完成同样的功能，视频压缩也一样，它用更少的比特，承载同样的视觉信息，这是一种艺术,也是一种工程。
好了，不扯远了，如果你也遇到视频太大的问题，不妨试试用Go搭个工具自己压，别怕踩坑，坑踩多了，你就成了专家，就像我一样，一开始连H.264和H.265都分不清，现在也能跟别人吹牛说“我让一个365MB的视频瘦身到了25MB”，嗯,这种感觉还挺爽的。
本文来自作者[kyadmin]投稿，不代表be365立场，如若转载，请注明出处：http://www.hljbesthome.com/keji/432.html
评论列表（4条）
我是be365的签约作者“kyadmin”！
希望本篇文章《365MB压缩成25MB视频文件？我用Go语言手搓了一个魔法》能对你有所帮助！
本站[be365]内容主要涵盖：be365,be365网站,be365网址,ball365体育,Be365排名
本文概览：手机里的视频占了几百兆，想发给朋友，微信提示“文件过大”；想上传到某个平台，提示“时长超限”或“体积超标”，我以前也烦这个，直到我试着用...