go中调用ffmpeg命令行切片最稳,因其底层适配千种编码格式与时间戳异常,手动解析易出b帧、dts/pts错乱等问题;推荐-c copy加关键帧对齐,配合ffprobe校验元数据与文件完整性。

Go 里用 ffmpeg 命令行切片最稳,别硬写解码逻辑
直接调 ffmpeg 是当前 Go 处理视频切片最可靠的方式。FFmpeg 底层适配了上千种编码格式、容器封装和时间戳异常情况,自己用 gocv 或 goav 手动解析帧,大概率卡在 B-frame 顺序、DTS/PTS 错乱、非关键帧起始点这些细节上。
常见错误现象:output.mp4 播放卡顿、首帧黑屏、时长对不上、音频不同步——基本都是跳过了 ffmpeg 自动做的 stream re-muxing 和 timestamp correction。
- 使用场景:按时间切(如每 10 秒一段)、按关键帧切(
-force_key_frames)、抽帧存图(-vf fps=1) - 推荐命令结构:
ffmpeg -i input.mp4 -ss 00:01:30 -t 10 -c copy -avoid_negative_ts make_zero output_01.mp4 -
-c copy能避免重编码,但要求起始点必须是关键帧;否则加-noaccurate_seek+-c:a aac -c:v libx264回退到转码模式 - Go 中用
exec.Command调用,注意设置cmd.Stderr捕获Invalid data found when processing input这类提示——它往往意味着文件损坏或索引缺失,不是参数错
ffprobe 解析元数据比 Go 原生库快且准
想读视频宽高、码率、时长、编码格式、关键帧间隔?别碰 github.com/3d0c/gmf 或自己解析 MP4 Box,它们对 fragmented MP4、HEVC with HDR meta、QuickTime timecode track 支持极弱。直接跑 ffprobe -v quiet -print_format json -show_format -show_streams input.mp4 最省心。
常见错误现象:Duration: N/A 出现在输出里,说明文件没内建 duration 字段(常见于直播录制未正常结束的 .ts/.mp4),这时得靠解析 streams[0].duration_ts 和 streams[0].time_base 自己算,而不是盲信 format.duration。
立即学习“go语言免费学习笔记(深入)”;
- 关键字段优先级:时长看
streams[0].duration(有值就用),没有则用format.duration;若都空,再算duration_ts * time_base - 判断是否含音频:
len(streams)> 1 且存在codec_type == "audio",不能只看format.nb_streams——有些文件 audio stream 被标记为attached_pic - Go 解析 JSON 时,把
duration字段声明为json.number,避免 float64 精度丢失导致 123.999999999 秒
切片后校验不能只看文件大小和 err == nil
切片成功 ≠ 视频可播。很多脚本跑完 err == nil 就认为 OK,结果发现生成的 part_03.mp4 实际只有 200 字节(ffmpeg 写入中途被 kill 但没报错),或者音视频流时间基不一致导致播放器拒绝加载。
真实使用场景:批量切片后自动上传 CDN,某一段播不出,排查要 2 小时——其实本地加一步校验只要 200ms。
- 必做三件事:
os.Stat()看文件大小是否 > 1KB;ffprobe -v Error -show_entries format=duration input.mp4 -of default=nw=1确保能读出 duration;ffmpeg -v error -i input.mp4 -f NULL -验证能否完整 decode(会吐出frame=XXXX行) - 特别注意
ffmpeg -f null -的退出码:0 = 正常播完,1 = 解码失败(如 missing codec),255 = 文件不可读(权限/路径错) - 如果切片量大,把校验逻辑塞进 goroutine,但限制并发数(比如
sem := make(chan Struct{}, 3)),避免同时起一堆ffprobe把 CPU 打满
windows 下路径空格和中文会让 ffmpeg 静默失败
Go 构造命令行时,input.mp4 路径含空格或中文,exec.Command("ffmpeg", "-i", path, ...) 在 Windows 上大概率失败,且 cmd.Run() 返回 nil 错误——因为 ffmpeg.exe 自己解析参数时崩了,根本没进主逻辑。
这不是 Go 的 bug,是 Windows CreateProcess 对参数分词的限制。linux/macos 下同样路径可能侥幸通过,但别依赖。
- 解决方法只有一个:所有路径参数(
-i、-o、-f后面的)都用双引号包裹,且在 Go 里显式加上,例如:"-i", """ + path + """ - 更稳妥的做法:用
filepath.Abs(path)转成绝对路径,再strings.ReplaceAll(absPath, "", "/")统一斜杠,最后包双引号 - 别信
exec.Command的文档说“自动处理空格”——它只负责把字符串传给系统 API,不负责 ffmpeg 怎么解析
复杂点在于,同一套代码既要跑在 CI 的 Linux docker 里,又要支持运维同学本地 Windows 双击运行。路径处理这一步漏掉,后面所有切片都会“看似成功实则无效”,而且很难复现——因为开发机路径短、无空格,问题只在客户环境爆发。