The problem is 100% ffmpeg, Go has nothing to do with it other than it's being used as a better shell script. Also some errors are checked and not others, and a large amount of files are opened and never closed
I agree that Go is not at fault here. However, I don't think FFmpeg is at fault either. It's just a fact of life that you can't seek in a stream with no buffer. As for the error handling, I purposely leave that out of my articles. Obviously, you shouldn't do this in production code.
In this particular case, it's just combining two tracks though. Could just do this directly in golang without using ffmpeg and not deal with it's shortcomings in such a manner.
ffmpeg has libraries. Why are you forking a separate process to call a single function? This is a very common problem I see in high level languages with poor C interoperability. Although cgo works fine, so what gives? Less code for more problems.
cgo doesn't just work fine, it's still treated very much as a second-class citizen by the Go tooling. It doesn't integrate with the standard build tooling properly and requires additional manual steps. You also can't really have an upstream dep that uses cgo internally, the burden falls onto the end binary to manually set the flags correctly.