Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

Yes, this is useful — the "hit a byte budget without eyeballing it" loop is the annoying part and most online converters just guess. A few things from doing this a lot for itch pages and forum posts:


Palette generation is where most of your quality lives. If you're on ffmpeg, generate a palette per clip rather than using a global/web palette, and use palettegen with stats_mode=diff so colours are weighted toward the moving parts instead of the static background. Then on paletteuse, try dither=bayer:bayer_scale=4 or 5 — for flat/pixel-art footage it's dramatically smaller than the default sierra2_4a dither, because ordered dithering compresses far better than error diffusion. On my own captures that swap alone was often 30-40% off the file size at the same resolution. Worth exposing as a "pixel art / smooth art" toggle rather than a raw dither dropdown.


Drop duplicate frames before encoding. Most gameplay footage has a lot of near-identical frames (menus, idle, pauses), and mpdecimate plus a matching fps filter throws those bytes away with zero visible cost. Cheap win.


For the search itself: file size is close to monotonic in width, so binary-search width at a fixed fps instead of stepping linearly — usually 5-6 encodes instead of 15, which fixes the "does it take too long" question more than any encoder tuning will.


If you want a quality ceiling to compare against, run the same clip through gifski (Rust, lossy GIF encoder, good per-frame palettes) and see how far your ffmpeg output is off it. That gives you a real reference for "is my export quality good enough" rather than vibes.


One scope note: itch's game pages and devlogs accept video, and video will always beat GIF on size and sharpness. The place GIF genuinely wins is animated cover images and inline forum/comment posts. Saying that plainly on your page makes the tool look focused instead of limited.

This is really useful, thanks. Funny enough, I’m already doing per-clip palette generation with stats mode=diff, so that’s reassuring.

I’m currently using sierra_4a though, so the Bayer point is interesting. A simple pixel-art or normal footage mode sounds much better than exposing a bunch of encoder settings to the user.

The binary-search idea is probably the biggest thing I want to test from this. Right now I search through ranked width fps colors combinations, which works, but it can definitely do more encodes than necessary.

I hadn’t considered mpdecimate either. I’ll test it on some gameplay with idle menu sections and make sure it doesn’t mess with timing.

Also you’re the second person to point out that I should be more specific about where gif actually wins over video. I’m going to change the page wording around that.

Thanks for the gifski benchmark idea too. Having an actual quality reference will be much more useful than just looking at my own output and deciding it seems fine.

If you want, I can send you a free key for the current build. I’d be interested to see how it compares with the workflow you already use.

https://rodian1.itch.io/gif/download/y39VApmbxTzglqgGpHcoxvojUPwoeQOF5IYKH7T1;free tester key