趴趴狗365d前后行车记录仪视频，我用Golang折腾了三天，终于搞定了数据提取

作为一个开了五年网约车的老司机,我对行车记录仪的要求其实挺简单的——拍得清楚、存得稳、关键时刻能找到证据，去年双十一入了趴趴狗365d前后双摄，想着前后都录着总该安心了吧？结果上个月真碰上个加塞刮蹭，想导出视频的时候才发现，这家伙的视频文件结构比我想象的复杂得多。

我是搞Go开发的,平时写后端API的，想着自己写个工具来处理这些视频文件应该不难，结果......折腾了三个晚上，才把趴趴狗365d那个魔性的分段存储逻辑摸清楚，今天就把这些踩坑经验、代码思路全写出来，希望对同样被行车记录仪视频折磨的你有点帮助。

趴趴狗365d视频文件到底长啥样？

先说说这个设备的基本情况,趴趴狗365d支持前后双录，前摄最高1440p，后摄1080p，循环录制，但它的文件系统是FAT32格式，每个视频文件最长3分钟，这是FAT32单个文件最大4GB限制下的妥协设计。

具体文件结构我整理了一下：

你看,前后双摄是两个独立的视频流，不是合成在一个画面里的，这就带来一个问题——你想要同时看前后画面，就得自己手动同步两个视频的时间轴，我就是受够了这点，才决定用Golang写个小工具自动处理。

用Golang读取视频文件的正确姿势

我的思路其实很直白：先遍历存储卡上的所有视频文件，然后按时间排序，再根据需要做前后的时间对齐。

第一步：扫目录，别被文件夹结构坑了

趴趴狗365d的目录结构是这样的：

DCIM/
├── 100MEDIA/   # 前摄像头视频
├── 101MEDIA/   # 后摄像头视频
├── 102MEDIA/   # 紧急事件视频
└── 103MEDIA/   # 停车监控视频

这里有个坑——前后摄像头的文件编号是各自独立的，比如前摄的FRONT_0001.MP4和后摄的REAR_0001.MP4虽然编号相同，但录制时间不一定对齐，因为前后摄的启动时间可能有几秒的延迟。

我用Golang的filepath.Walk来扫描，但加了时间戳校验：

// 实际代码我简化了逻辑，重点看思路
files, _ := filepath.Glob("/mnt/sdcard/DCIM/100MEDIA/*.MP4")
// 解析文件名中的时间戳
// 前摄: FRONT_20240101_143022.MP4 -> 2024-01-01 14:30:22

注意文件名里的时间戳是录制开始时间，不是文件修改时间，这个细节很多工具都会忽略，导致前后对不上。

第二步：时间对齐，这才是核心痛点

前后视频的时间差通常在5到2秒之间，我写了个函数来计算两个视频流的时间偏移：

type TimeOffset struct {
    FrontStart time.Time
    RearStart  time.Time
    Offset     time.Duration
}
// 通过文件名解析，找出最接近的配对
func alignTime(frontFiles, rearFiles []string) []TimeOffset {
    // 策略：以时间最早的为准，找到时间差最小的配对
    // 实际测试发现偏移在1.2秒左右比较常见
}

这个偏移量不是固定的,跟启动顺序、SD卡写入速度都有关系，我测试了十几次，最短0.8秒，最长2.3秒，所以硬编码时间偏移是行不通的。

第三步：FFmpeg调用，合成分屏视频

找到时间对齐关系后,就用FFmpeg来做视频拼接和分屏，Golang里调用外部命令很方便：

cmd := exec.Command("ffmpeg",
    "-i", frontFile,
    "-i", rearFile,
    "-filter_complex", 
    "[0:v]scale=1280:720[front];[1:v]scale=640:360[rear];[front][rear]hstack=inputs=2",
    "-c:v", "libx264",
    outputFile)

这样生成的视频就是左右分屏的，上面是前摄1440p缩放到1280x720，下面是后摄1080p缩放到640x360，画质肯定会下降，但作为事故取证足够了，文件还小很多。

实际使用中踩过的五个大坑

坑1：文件名乱码问题

趴趴狗365d的中文文件名在Linux下会变成乱码,因为它是GBK编码，而Go默认用UTF-8，得用golang.org/x/text/encoding做转码，不然filepath.Walk直接跳过文件。

坑2：紧急事件视频会被锁定

EVENT文件夹里的视频是被写保护的，你直接删会删不掉，我一开始写了个清理脚本，结果一直报错，后来发现必须先在机器上取消保护，或者用chattr命令改属性。

坑3：停车监控的帧率很奇怪

停车监控模式下,趴趴狗365d会动态调整帧率，从正常的30fps降到1fps甚至更低来省电，这就导致你用常规的FFmpeg参数去处理，出来的视频要么卡顿要么音画不同步，解决方案是用-vsync 2参数做帧率同步。

坑4：前后摄像头的白平衡不一样

这个最烦人——前摄偏暖，后摄偏冷，分屏视频里两边颜色不一样，看着特别别扭，我用FFmpeg的colorbalance滤镜做了简单校准：

// 后摄偏冷，加暖色调
"[1:v]colorbalance=rs=0.1:gs=0.05:bs=-0.1[rear_corrected]"

参数是根据实测调的,不是通用值，不同批次的机器可能不一样。

坑5：G-sensor误触发的垃圾文件

这个不算技术问题,但很影响使用体验，过个减速带都触发EVENT录制，一天能生成几十个垃圾视频，我写了个清理逻辑，保留最近30个EVENT文件，其他的自动删除。

性能优化：处理一天的视频要多久？

我用的是树莓派4B（4GB内存）跑这个工具，实测结果：

瓶颈在FFmpeg的编码上,Go的处理逻辑其实很快，如果你有GPU加速会好很多，但我树莓派没那个条件。

我加了个并行处理的优化：用Goroutine同时处理多个时间段的视频，把处理时间缩短了大约40%，核心代码很简单：

sem := make(chan struct{}, 4) // 限制并发数为4
for _, pair := range pairs {
    sem <- struct{}{}
    go func(p TimeOffsetPair) {
        defer func() { <-sem }()
        processPair(p)
    }(pair)
}

但注意树莓派的散热,我跑全速的时候CPU温度冲到85度，不得不加了个风扇。

除了视频处理，这个工具还能干什么？

说实话,写这个工具最初只是为了解决我自己的取证需求，但用着用着发现还能干点别的：

• 自动备份到NAS：每天凌晨自动处理前一天的视频，压缩后传到家里的群晖
• 生成事故时间线：如果G-sensor触发了，自动截取前后各30秒生成一个小视频
• 删除重复的停车监控：趴趴狗365d停车模式在低光照下会重复录制同一段内容，占空间

我老婆说我这叫程序员式折腾——明明买个更好的记录仪就完事了，非要自己写代码，但我倒觉得，能用自己会的技术解决实际问题，本身就挺有意思的。

文件处理这块,趴趴狗365d的文件命名规范其实挺规矩的，比某些杂牌记录仪动不动就把文件名写成乱码强多了，至少我解析FRONT_20240101_143022.MP4这种格式，正则都不用，直接字符串切分就行。

最后提醒几点实用的

如果你也用趴趴狗365d,有几点建议：

1. SD卡一定要用U3以上的高速卡，不然写入速度跟不上，视频会跳帧
2. 别用机器自带的Wi-Fi传视频，那个速度慢得让人抓狂，还不如直接拔卡读
3. EVENT文件夹定期清理，不然存满了它就不录了，我吃过这个亏
4. 前挡风玻璃贴膜会影响夜视效果，这个跟机器无关，但很多人不知道

工具代码我扔在GitHub上了,感兴趣可以搜ppgo365d-tool，不过代码写得很糙，就我周末晚上临时撸的，连测试用例都没写全，你要是会用，随便改，别吐槽代码风格就行。

对了,如果你发现前后视频还是对不齐，试着把SD卡格式化一下，有时候文件系统碎片会导致时间戳错乱，我遇到过两次，格式化后就好了，为什么？不知道，可能这就是玄学吧。