Did you look at joy4[0] (or now joy5[1])? These wrappers expose a lot of ffmpeg functionality in a Go idiomatic style. You could easily write a GIF generator using them.

[0]: https://github.com/nareix/joy4

[1]: https://github.com/nareix/joy5

No I didn't find it in my search for FFMPEG wrappers.

I’m not familiar with FFMPEG. How hard would it be to reproduce bits of it in Go natively? Why does everyone need to sub process out to this one library.

It packs an awful lot of assembly-optimized codecs and transformations into it.

It would be a huge undertaking to re-write it, let alone keep up with the pace of development.

An awful lot of the video processing on the internet makes it's way through ffmpeg in one way or another.

Yeah, it feels like something I don’t want to replicate all of (because I probably won’t need all of it), but it would also be nice to be able to use the bits I need from Go without depending on C. :/

Side note the image-rs crate in the Rust ecosystem has no external dependencies and can encode and decode animated gifs and a variety of other image formats, 100% rust https://github.com/image-rs/image. At my startup we use this in a lambda to process user-uploaded images, with great success.

The image-rs crate has some serious design flaws and it has put me off trying to do any image processing in Rust at all. It may support many formats, but the basic image type is complete garbage. It’s conceptually a 2D array of some specific pixel type—which means that any pixel value must carry with it colorspace information. I can’t honestly recommend it to anyone.

The issues I’m talking about are acknowledged as design flaws / mistakes if you start browsing the GitHub issues.

Sounds like typical Rust... They're well-meaning people in general, but they usually lack domain knowledge in the particular field they're trying to reinvent in Rust, so the end result often looks like a square-shaped wheel.

In our case this hasn't caused any issues for us, and it has worked great as a general purpose converter

Glad it worked out for you—it seemed like the features are there for basic image conversion, but try to do something a little more sophisticated and you run into some severe design limits. Here is the kind of underlying problem I’m talking about:

https://github.com/image-rs/image/issues/1523

Why would you do something more sophisticated though, versus just using your own pixel data structures and the converting if/when you want to load/save. This is supposed to be a stand-in for image magic, not a panacea for doing image processing in Rust. Maybe start an image-processing crate if that is your interest?