<p>Does anyone have a recommendation for an idiomatic Go library for Audio/Video codecs(h.264, vp8 and vp9)?</p>
<hr/>**评论：**<br/><br/>LouisTheBuilder: <pre><p>Your best bet is probably to link to some c implementation. Video encoding is really all about speed. As fast as golang is, it's still not as good as c.</p></pre>SupersonicSpitfire: <pre><p>The profiling tools are really good, though. And Go is better at concurrency, which is arguably more important in order to get better performance.</p>
<p>I think a pure Go implementation would perform adequately. In worst case, perhaps a function or two would have to be rewritten in C or Assembly and be used together with the Go code. </p></pre>anacrolix: <pre><p>Sorry but you're incorrect. AV codecs are highly optimized and make use of intrinsics, vector optimizations and more. C compilers and their optimizers have excellent support for this, as do the existing libraries in this domain. Additionally in these areas, explicit parallelism is far more important than implicit concurrency that Go provides.</p></pre>SupersonicSpitfire: <pre><p>You could write a C function and use OpenMP for just the function(s) that would need extra optimization, then use Go for the rest. I think it could go fast enough with just Go, though. </p></pre>robertmeta: <pre><p>Doing calls per function you would die in the calling overhead. Go makes it easy to call C -- but not fast -- so you gotta batch up work. </p></pre>xkq3: <pre><ol>
<li>Go is only good at concurrency when you need lightweight threads, i.e. many with only a few active and the majority blocking. With encoding/decoding you have a handful of threads doing all the work at full load, so Go won't outshine native threads here.</li>
<li>As anacrolix said, libav/ffmpeg are written in C and assembly and make use of CPU extensions - Go will never come close to their performance.</li>
<li>libav/ffmpeg have 10 years of development, thousands of contributors and are actively maintained - it's pretty naive to think that you'd be better of with someones hobby codec implementation just because it's written in Go.</li>
</ol></pre>SupersonicSpitfire: <pre><p>I respectfully disagree with all three points.
1. Go might perform better. Only a good attempt at implementing this will conclude this.
2. Go can also use the GPU. Assembly can also be combined with Go, without the use of C.
3. Things can always be done better. "Hobby implementation" are your words. </p>
<p>In short: you cannot know this, only attempt to discourage someone from trying.</p></pre>jerf: <pre><blockquote>
<p>Go might perform better. </p>
</blockquote>
<p>Not a chance. libavcodecs is essentially written in custom assembler where it matters.</p>
<blockquote>
<p>you cannot know this</p>
</blockquote>
<p>Yes we can. This is engineering, not magic. You are not going to beat avcodec.</p>
<p>With all due respect, you may not have the necessary knowledge to make this determination, but others of us do. For us, this isn't even a hard question. You're basically claiming a semitruck "might" be able outrace a Formula One car, and we "can't know" the F1 will win unless we try it. Yes, we can in fact know the outcome. We don't need to actually physically race them to find out.</p>
<p>And note how the semi's value to the world is not brought into question by the fact it can't outrace an F1 car. No person has ever failed to buy and use a semi because they sit there, stroke their chin, and go <em>yeah, but it just isn't as fast as an F1 car</em>. It isn't a problem that Go can't do this faster. It would have to be an <em>extremely</em> different language to do so.</p>
<blockquote>
<p>only attempt to discourage someone from trying.</p>
</blockquote>
<p>Yes, absolutely I would discourage someone from trying to beat libavcodec's performance in Go! The <strong><em>absolute best case scenario</em></strong> is that you pour thousands upon thousands of hours into it, and either just tie the performance by writing in assembler or GPU code (i.e., "not Go"), or <em>lose badly</em> by trying to write it in pure Go.</p>
<p>Why would you encourage someone to pour that many thousands of hours into a goal that can't possibly be accomplished? Whatever it is you think you're doing, you're not doing it. You're not doing "advocacy", you're doing blind cheerleading.</p>
<p>As for "what if they just want to learn about video codecs", yeah, sure, great, but they can do that in whatever language they like, then, since performance isn't really an issue.</p></pre>koffiezet: <pre><p>Video decoding does not require concurrency, it requires parallelism,<a href="https://www.youtube.com/watch?v=cN_DpYBzKso" rel="nofollow">which is not the same</a>. Go is very good at scheduling i/o bound threading - not CPU bound stuff.</p>
<p>Go might be faster than your average scripting language, but it still gets beaten for a lot of tasks by a highly optimised and JIT'ed interpreted language like Java, and you don't see video en/decoders being written in Java.</p></pre>pstuart: <pre><p>Maybe this: <a href="https://github.com/jteeuwen/go-vlc">https://github.com/jteeuwen/go-vlc</a></p></pre>mwholt: <pre><p>I've never used it, but there's this one for h.264: <a href="https://github.com/nareix/codec" rel="nofollow">https://github.com/nareix/codec</a></p></pre>stuross: <pre><p>I've been using <a href="https://github.com/3d0c/gmf" rel="nofollow">https://github.com/3d0c/gmf</a> with some success</p></pre>
