3 ms·
A Golang pipeline abomination
- 38 2y agoThe 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
- vrosas 2y agoThe fact that this is on top of HN is absurd.
- Raed667 2y agoi think it reflects how some people feel about go, where every complaint is treated as ‘skill issue’ so things like this bubble up out of frustration
- kermerlerper 2y agoI 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.
- fragmede 2y agoIn 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.
- kermerlerper 2y agoAgree, that would be a much better solution.
- black_13 2y ago[dead]
- C-programmer 2y agoffmpeg 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.
- treyd 2y agocgo 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.