3 ms·
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
by 38 2y ago
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
- 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.