用Golang把365天熬成一碗视频粥—一周岁视频生成器实战手记

为什么偏偏是365天，偏偏是视频？

我家小闺女满一岁那天，手机里躺着四千多张照片和两百多段零碎视频，翻起来费劲，回忆也断断续续，当时我就想，要是能把这些碎片自动拼成一支365天的成长纪录片，那该多好——每天一帧，从襁褓里的皱巴巴，到扶着墙蹒跚学步,最后定格在吹蜡烛的傻笑上。

但现实是，剪映里手动拖素材能拖到怀疑人生，于是我这个写Go的爹,决定用Golang给自己造个轮子。

一周岁365天视频，不是让你一天拍一段，而是把你已经拍完的365天素材，按时间线自动切片、排序、转场、加字幕，最后渲染成一个连续叙事的视频文件，它本质上是个管道程序：读文件→解析元数据→按天分组→生成特效脚本→调用FFmpeg渲染。

第一铲土：Go的os/io怎么跟视频文件打交道

别一上来就谈什么goroutine并发取帧，先把地基夯实，视频文件在Go眼里就是一堆二进制，我们第一步要做的，是批量读取并提取拍摄日期。

type DailyClip struct {
    Day     time.Time
    Path    string
    Duration float64
    Checksum string
}

我用filepath.Walk递归扫描整个相册目录，对每个视频文件调用os.Stat拿到修改时间（大多数手机视频的EXIF时间跟修改时间误差在可接受范围内），然后按Year-Doy（年+第几天）做key，塞进map[int][]DailyClip里。

这里头有个坑——时区，相机默认是UTC，你家时间可能是东八区，你如果不做time.LoadLocation("Asia/Shanghai")的转换，所有素材会整体偏移8小时，导致跨天剪辑时错位，我当时在这上面卡了半宿,最后打印日志才发现每个文件的Day都差了一天。

中间环节：用sort.Slice把365天码得整整齐齐

拿到散落的素材后，你得把365个分组按日期升序排好，这步简单，sort.Slice加个闭包搞定，但真正麻烦的是同一天多段素材怎么排序——早上拍的应该排在前，晚上拍的在后，这时候就得看文件名的命名规则了，比如华为的VID_20230101_082315.mp4，时间戳就在文件名里,正则可以轻松提出来。

re := regexp.MustCompile(`(\d{4})(\d{2})(\d{2})_(\d{2})(\d{2})(\d{2})`)

如果你有些素材文件名被修改过（比如从微信保存的），就得退回用os.Stat的ModTime，虽然可能不准，但总比没有强，排序算法的稳定性很重要——同一天的素材如果时间排序对了，整个视频的叙事线就顺了。

重头戏：组合视频片段，还得配上生活化的字幕

现在365个分组都排好序了，但你总不能把365段原视频直接接上吧？手机录的竖屏横屏混着来，音量忽大忽小，看着晕，我决定每段取中间1.5秒，做1秒的交叉溶解转场,然后统一分辨率到1080p。

Go语言里干这活，一般用os/exec调用FFmpeg子进程，我不直接生成最终视频，而是先生成一个滤镜图脚本——把每天的素材拼成一个每日小结,然后把365天的小结再串成最终作品。

cmd := exec.Command("ffmpeg",
    "-i", day1.Path,
    "-i", day2.Path,
    "-filter_complex",
    "[0:v]trim=duration=1.5,scale=1920:1080,setpts=PTS-STARTPTS[v0];"+
    "[1:v]trim=duration=1.5,scale=1920:1080,setpts=PTS-STARTPTS[v1];"+
    "[v0][v1]xfade=transition=fade:duration=1:offset=0.5[vout]",
    "-map", "[vout]",
    "-c:v", "libx264",
    daySummaryPath)

这filter_complex写起来真的很要命。offset计算一不小心就错位，导致画面闪烁，我的经验是，宁可多花点时间写个自检函数，去计算总时长是否等于各段时长之和减去转场重叠部分，也不盲目依赖xfade的默认行为。

字幕的话，我直接用drawtext滤镜，在画面上方三分之一处，每3秒切一次日期文本，字体得选个支持中文的，否则全变豆腐块，我Windows机器上用的是C:/Windows/Fonts/msyh.ttc，Linux上就换notosanscjk。

关于性能的几句大实话：并行与内存的赌局

365段视频，每段解码1.5秒，加起来就是9分多钟的素材，FFmpeg单线程跑能把你CPU吃满，但很慢，我试着用Go的sync.WaitGroup同时起4个FFmpeg进程分别渲染4个季度的片段，最后再合并，结果OS文件句柄数差点爆掉，进程间互抢I/O,反而比顺序跑更慢。

真正有效的优化在输入侧，先用-ss参数快速定位到每段的中间点，再-t限制输出时长，这样FFmpeg不用从头解码整个文件，耗时能砍掉六成，还有个骚操作是先把小片转成中间格式（比如无损的ffv1或prores）存硬盘，最后统一压H.265，中间格式体积大，但合并时不用重复解码,速度飞快。

我最后选了四季度中间格式这种折中方案，因为出错了不用从第一天重来，处理到第300天崩了,心理防线直接就塌了。

真正让人头大的：视频元数据里的“时间幽灵”

我之前一直没提，其实最大的坑不是编码，是时长漂移，你拍的时候手机可能认为那天的视频是30fps，但实际录制过程中会因为温度或电量原因掉到29.7fps，你按30fps去切1.5秒，实际上剪切点跟声音素材对不齐,画面卡顿或音画不同步。

解决法子是在每天的临时小片生成后，用ffprobe读取实际时长，然后微调下一个转场的offset，我在Go里写了个小循环，反复对比预期时长和实际时长，累计误差超过0.1秒就触发一次自校准：

for day := 1; day <= 365; day++ {
    actualDur, _ := probeDuration(dayClipPath[day])
    accumulatedErr += expectedDur - actualDur
    if accumulatedErr > 0.1 {
        offset -= accumulatedErr / 2
        accumulatedErr = 0
    }
}

实际效果嘛，从第50天开始就听不到明显的“嗒嗒嗒”的卡顿声了，这个绝对值累积误差不一定总是正数，但交替正负会互相抵消，反正做完这支视频,我家里那台老笔记本风扇转了整整两天两夜。

最后的包装：一键生成，然后全家围着看

现在脚本跑完，当前目录下多了一个birthday_365.mp4，我加了点私货——在开头三秒用白色半透明底黑字打上“致果果的365天”，结尾是“爸爸写代码，妈妈拍视频，你负责长大”。

因为是用Go写的，整个程序编译成单个exe文件，没有Python那些依赖地狱，我老婆不会用命令行，我给她做了个简单的flag参数，双击后她只需要输入相册路径，剩下的自动完成，这事发生在上个月，闺女趴在茶几上，看着屏幕上自己从襁褓里的那个小肉球，变成到处跑的小丫头，看了一遍又一遍,最后还学电视里那样鼓掌。

那一刻我突然觉得，什么goroutine调度、什么视频编解码，都不如她眼睛里那点光来得实在，Go代码只是工具，真正组成这个视频的，是那365天里每一个平凡但再也回不去的瞬间，明天她又要开始第二个365天了，脚本还没改，但我知道,代码里总有一颗糖果等着我去拆。