为什么非要盯上“365天视频”这个需求？
年初翻手机相册，发现过去一年拍了两千多个片段，全堆在云盘里吃灰，想剪个年度回顾视频，打开Premiere那一刻就放弃了——素材排序、转场、配乐、字幕,光是拖拽时间轴就得熬三个通宵。
后来在GitHub上看到一个开源项目，用Python把每天的碎片视频拼成一段延时摄影，我就琢磨：能不能用Go写个更顺手的？ 毕竟Golang的并发处理视频帧,理论上比Python快一个数量级。
从第一天到365天视频，到底卡在哪？
先别急着写代码，我拆解了需求,发现核心难点有三个：
- 日期与文件名的映射：手机导出的视频文件名是
IMG_20240101_083012.mp4这种格式,得解析出拍摄日期。 - 按天分组：同一天可能拍了20个片段，得合并成一天的代表性剪辑（比如取第一个+最后一个）。
- 跨天拼接：最终要输出一个365天连续播放的视频，每天占3-5秒。
我原本想用ffmpeg的concat协议直接拼，但不同分辨率、帧率、编码格式的视频硬拼会花屏,得先统一转码。
用费曼法拆解：给“365天视频”写个流水线
我用费曼技巧给自己讲了一遍流程,像教小学生一样：
“你需要一个厨师（主程序），先把食材（原始视频）洗干净（转码），然后按菜谱顺序（日期）摆好盘（分组拼接），最后大火快炒（合并输出）。”
具体到代码,分为五个阶段：
| 阶段 | 输入 | 输出 | 用到的库 |
|---|---|---|---|
| 扫描 | 文件夹路径 | 视频文件列表+日期标签 | os、path/filepath、regexp |
| 转码 | 原始视频 | 统一分辨率/帧率的临时文件 | os/exec 调用 ffmpeg |
| 分组 | 日期标签 | 每天一个[]string切片 |
map[string][]string |
| 拼接 | 每天切片 | 每天3秒的片段 | ffmpeg concat demuxer |
| 合并 | 365个片段 | 最终年度视频 | ffmpeg concat protocol |
第一步：扫描文件名，提取日期
func extractDate(filename string) string {
re := regexp.MustCompile(`IMG_(\d{4})(\d{2})(\d{2})_`)
match := re.FindStringSubmatch(filename)
if len(match) < 4 {
return "unknown"
}
return fmt.Sprintf("%s-%s-%s", match[1], match[2], match[3])
}
这里有个坑：有些视频是晚上拍的，文件名里带_night后缀，正则得兼容，我干脆用strings.Contains判断,粗暴但有效。
第二步：并发转码，别让CPU闲着
逐条转码3650个片段（假设一天平均10个），单线程得跑6小时，我用sync.WaitGroup起了8个goroutine：
jobs := make(chan string, 64)
var wg sync.WaitGroup
for i := 0; i < 8; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for file := range jobs {
transcode(file) // 内部调ffmpeg
}
}()
}
for _, file := range allFiles {
jobs <- file
}
close(jobs)
wg.Wait()
注意：ffmpeg本身是多线程的，开8个goroutine加上ffmpeg内部线程，直接把16核CPU干到100%，结果转码中途系统死机两次，后来限制每个ffmpeg只能用2线程：-threads 2。
第三步：每天的片段怎么选？
我本来想取“第一个+最后一个”，但发现有些天只有夜间拍摄，画面全黑,于是加了个筛选函数：
- 如果片段时长>10秒,直接截取前3秒；
- 如果时长<3秒，跳过（太碎片化）；
- 每天最多取5个片段,轮换选取。
func selectClips(clips []string) []string {
if len(clips) <= 5 {
return clips
}
step := len(clips) / 5
picked := make([]string, 0, 5)
for i := 0; i < len(clips); i += step {
if len(picked) >= 5 {
break
}
picked = append(picked, clips[i])
}
return picked
}
第四步：合并不了！编码器炸了
前面都顺利，卡在了最后一步，365个3秒的mp4文件，用concat协议直接合：
ffmpeg -f concat -safe 0 -i filelist.txt -c copy output.mp4
结果输出文件有100GB，因为每个片段的原始码率是50Mbps（4K素材）,只能强制统一编码：
ffmpeg -i input.mp4 -c:v libx264 -preset medium -b:v 5M -c:a aac output.mp4
但这样每个片段要转两轮码（第一轮统一中间格式，第二轮最终合并），我优化了下：把转码和合并合并成一个ffmpeg命令,用filter_complex实现：
cmd := exec.Command("ffmpeg",
"-i", clip1, "-i", clip2, ...,
"-filter_complex", "[0:v]trim=0:3,setsar=1[v0];[1:v]trim=0:3[v1];...",
"-map", "[v0]", "-map", "[v1]", ...,
"output.mp4")
这样做内存占用飙升，但速度提升40%。
运行时的意外：日期跨年和闰年
我拿过去两年（2023-2024）的素材测试，发现2023年有365天，2024年是366天，我写的拼接逻辑是按一年365天硬编码的,结果漏了2月29日。
// 错误示范
for day := 1; day <= 365; day++ {
// 拼接第day天
}
后来改成用time.Time遍历：
start := time.Date(2024, 1, 1, 0, 0, 0, 0, time.Local)
for d := start; d.Year() == 2024; d = d.AddDate(0, 0, 1) {
// 处理d
}
最后的效果和一点废话
跑完整个流程用了11小时43分钟（中间包括手动清理了3次磁盘），最终视频时长18分05秒，大小4.2GB,4K分辨率。
虽然麻烦，但看成品时突然觉得值了，尤其是我把每天的第一个镜头单独用粉色标记框标出来,这样能快速跳转到某个特定日期。
写这个工具的过程，比用剪映手拼有意思的多。Golang的channel加goroutine处理视频批处理，思路确实比Python清晰，但调试并发问题也够呛——有一半时间在排查死锁。
如果你也打算写类似的年度视频工具,给你三个忠告：
- 别信文件名日期，用EXIF元数据（有些手机改过时间）。
- 先转码成中间格式（比如MPEG-2）再拼接,别直接concat不同编码的MP4。
- 中途断电丢失进度——建议每转完10天,存一个进度JSON。
（代码放在GitHub了，有需要可以去翻，但别问我要文档，注释都写在函数名里了。）
本文来自作者[kyadmin]投稿，不代表be365立场，如若转载，请注明出处：http://www.hljbesthome.com/keji/2566.html
评论列表（4条）
我是be365的签约作者“kyadmin”！
希望本篇文章《从第一天到365天视频，我用Golang写了个年度影像自动化工具，结果把自己整不会了》能对你有所帮助！
本站[be365]内容主要涵盖：be365,be365网站,be365网址,ball365体育,Be365排名
本文概览：为什么非要盯上“365天视频”这个需求？年初翻手机相册，发现过去一年拍了两千多个片段，全堆在云盘里吃灰，想剪个年度回顾视频，打开Pr...