用Golang做365天变一年卡点视频，这事儿我琢磨了一整年

说实话,最开始看到“365天变一年卡点视频”这个需求的时候，我脑子里第一个反应是——这不就是每天拍一张照片，然后拼成视频嘛，但真上手做了才发现，卡点才是灵魂，没有卡点，365张照片就是一本翻页快的相册，有了卡点，365天就成了一部有呼吸感的年度纪录片。

我是用Golang写的,原因很简单：处理大量图片、批量命名、调用FFmpeg，Go的并发和标准库太香了，下面我把整个思路和踩过的坑都掰开了说。

卡点视频的核心逻辑：不是“每天一张”，是“每段卡点”

很多人以为365天变一年卡点视频,就是365张照片平均分配到60秒里，错了，真正好看的卡点视频，是按照音乐节拍来切照片，比如一首歌120BPM，每拍0.5秒，那么每张照片的显示时长就要对齐到0.5秒或者它的倍数。

我用Golang写了个结构体来处理这个：

type VideoSegment struct {
    ImagePath string
    Duration  float64 // 秒
    BeatIndex int     // 对应第几个节拍
}

1 第一步：解析音乐节拍点

我用了一个叫beats的Go库（其实就是个BPM检测工具），把MP3文件读进去，输出所有节拍的时间戳。

有了这个表,就能算出每两拍之间的间隔。卡点的本质就是：让照片切换发生在节拍点上。

2 第二步：把365张照片分配到节拍上

这里有个坑——365张照片很难整除，我的做法是：前300张照片用1拍显示，后65张照片用半拍显示，这样节奏会有一个“加速”的段落，反而显得有变化。

func assignImagesToBeats(images []string, beats []float64) []VideoSegment {
    segments := make([]VideoSegment, 0, len(images))
    for i, img := range images {
        beatIndex := i % len(beats)
        duration := 0.5
        if i < 300 {
            duration = 1.0
        }
        segments = append(segments, VideoSegment{
            ImagePath: img,
            Duration:  duration,
            BeatIndex: beatIndex,
        })
    }
    return segments
}

这代码我跑的时候发现,因为len(beats)可能比365小，所以用取模会循环使用节拍点，结果视频后半段的卡点变得很“迷”，因为重复了前面的节奏。

修正方案：把365张照片分成4个乐章，每个乐章用不同的音乐段落，比如前90天用A段，中间90天用B段，再90天用C段，最后95天用D段，每个段落的节拍数独立计算。

图片预处理：别让照片大小不一致毁掉视频

我最早跑出来的视频,照片忽大忽小，切换时画面会跳，Golang的image包帮我解决了这个：

func resizeImage(srcPath, dstPath string, width, height int) error {
    src, err := imaging.Open(srcPath)
    if err != nil {
        return err
    }
    dst := imaging.Fill(src, width, height, imaging.Center, imaging.Lanczos)
    return imaging.Save(dst, dstPath)
}

这里用的imaging库不是标准库，但它是Go生态里最流行的图片处理库。统一分辨率到1920x1080，所有照片居中裁剪，有个小技巧：不要用拉伸（Fit），要用裁切（Fill），这样不会变形，但会丢掉一些边缘内容，不过对于365天的生活记录，中心主体最重要。

1 日期水印：自动把“2024-01-15”打在右下角

很多人做卡点视频会忽略日期水印,但365天变一年卡点视频的精髓就是让观众知道“这是哪一天”，我写了段代码，从文件名里提取日期：

func addDateWatermark(img image.Image, dateStr string) image.Image {
    // 使用freetype或直接写入像素
    // 我最后用了go-font，免费字体
    return img // 示意
}

字体我用了思源黑体（免费可商用），大小控制在图片宽度的3%，位置是右下角，透明度30%，这样不喧宾夺主，但又能看见。

视频合成：FFmpeg是幕后英雄

Golang本身不输出视频,我用os/exec调用了FFmpeg，关键命令长这样：

ffmpeg -r 30 -i frame_%04d.png -i music.mp3 -c:v libx264 -pix_fmt yuv420p -c:a aac -shortest output.mp4

但这里有个问题：-r 30表示每秒30帧，而我的每张照片显示时长是0.5秒或1秒，如果直接这么跑，每张照片只显示1帧（1/30秒）。解决办法：把每张照片复制成多帧。

我在Go里生成一个concat.txt文件：

file 'frame_0001.png'
duration 0.5
file 'frame_0002.png'
duration 1.0
...

然后用FFmpeg的concat协议读取,这个方案的好处是：每张照片的时长可以精确到小数点后两位。

1 性能优化：并发处理

365张图片,每张都要缩放、加水印、写入磁盘，单线程跑要7-8分钟，我用sync.WaitGroup开了8个goroutine：

var wg sync.WaitGroup
sem := make(chan struct{}, 8) // 控制并发数
for _, img := range images {
    wg.Add(1)
    go func(p string) {
        defer wg.Done()
        sem <- struct{}{}
        defer func() { <-sem }()
        // 处理单张图片
    }(img)
}
wg.Wait()

时间缩短到1分20秒左右。注意：磁盘IO是瓶颈，所以并发数不宜太多，8个是经验值。

踩过的坑和教训

1 照片顺序不能按文件名排

一开始我按文件名排序,结果1.jpg, 10.jpg, 11.jpg排在2.jpg前面，正确做法是补零：jpg, 002.jpg, ...，或者用Golang的sort.Slice自定义排序函数。

2 音乐节奏检测不准确

我用的BPM检测库对纯音乐还行,但对人声多的歌，节拍点经常错位，后来我换成了Librosa（Python库）先离线分析出节拍点，存在JSON里，然后让Go读取，两门语言配合，舒服了。

3 视频输出卡顿

首次生成的视频在手机上播放时,每隔几秒就卡一下，排查发现是因为每张图片的分辨率不统一，FFmpeg在缩放时占用了大量CPU，提前统一分辨率后，问题解决。

最终代码结构

project/
├── main.go            # 入口
├── processor/
│   ├── image.go       # 缩放、水印
│   ├── beats.go       # 节拍数据处理
│   └── video.go       # FFmpeg调用
├── config.json        # 照片目录、音乐路径、输出参数
└── beats.json         # 由Python生成的节拍数据

config.json的内容大概这样：

{
    "imageDir": "./photos/",
    "musicPath": "./bgm.mp3",
    "outputPath": "./365days.mp4",
    "resolution": {"width": 1920, "height": 1080},
    "fps": 30,
    "beatsFile": "./beats.json"
}

运行起来是什么感觉

我第一次跑通的时候,盯着屏幕看了三遍，365天的照片，从冬天拍到冬天，踩着音乐的鼓点一张张闪过。那种感觉很奇怪，你明明是在处理代码和文件，但最后出来的东西是记忆本身。

有一张照片是我女儿第一次走路,正好卡在一个重拍上，我没刻意安排，是算法自己匹配的，只能说，好的工具偶尔会给你惊喜。

最后提一句：代码写得不算完美，我用了全局变量，错误处理也没做到位（有些panic直接崩了），但视频输出是好的，如果你要复制这个方案，记得把错误处理补全，不然跑到第200张图片时崩了，前面全白费。

嗯,就这些，365张照片，一年时间，一段视频，用Golang写一遍，比发朋友圈更有仪式感。