Yes, I would use this, and I can tell you exactly where the gap is, because I built the same thing for myself a few months ago and then measured it to death 🎮

I run a browser arena game and I ship GIFs into devlogs, forum posts and comment threads constantly. My version is a shell script wrapped around ffmpeg that encodes, measures, shrinks and retries until it fits a byte budget — which is the same loop you have described. So take all of this as notes from someone who has already hit the walls, not as a critique of a tool I have not run.

The thing I think you are missing, and it is the whole game.

Duration is a far bigger lever than any encoder setting, and your users do not know that. Size scales with width × height × fps × duration, so a long clip spends its entire budget on length and then your search has no choice but to shrink the picture to a postage stamp to make it fit.

Measured on one of my own clips, same 3 MB budget, same everything else:

full 14 s  ->  360x202
cut to 6 s ->  456x256

Same budget. Noticeably bigger picture, and a GIF that loops on one clear action beats one that plays a whole round at a resolution where nobody can tell what happened.

You already have trimming, so you do not need to build anything new. What you need is for the tool to SAY THIS at the moment it matters. Something like: “at 3 MB this 14s clip lands at 360px wide — trimming to 6s would give you 456px.” That single line turns your tool from an encoder into something that teaches the user the thing that actually controls their output quality. Nobody else’s GIF tool does this and it costs you one extra encode to estimate.

Three more, in order of value.

Add a crop step, because it is free resolution. My raw captures are 2130x1820 with a huge amount of dead black around the playfield. Cropping to the play area alone is pure gain at any budget — you are simply not spending bytes on pixels nobody looks at. If you want the impressive version, auto-detect static borders across a few sampled frames and offer the crop; most game captures have letterboxing, HUD margins or desktop chrome that is identical in every frame.

Be careful about the ORDER your search makes concessions in. The naive implementation drops fps first, because it is the single biggest byte win. It is also the one that most damages perceived quality. My floor after testing: 15 reads as smooth, 12 is acceptable, below 10 looks broken and people read it as a bad game rather than a bad GIF. So shrink width before you drop fps below about 12. If you expose one advanced setting, make it that floor.

Give people a benchmark. Here is mine so you can sanity-check your export quality, since right now you have no external reference: roughly 6 seconds of 2130x1820 gameplay footage, cropped to the arena, at a 3 MB budget, lands around 500 to 640 px wide at 15 fps with a 128-colour palette. If yours comes out materially smaller than that at the same budget and duration, your palette generation or your search step size has room in it. If it comes out bigger, I would like to know what you are doing differently.

On “is this actually useful to other devs” — yes, but the market is narrower than you might be pitching it, and being precise about that will help you. Anywhere that accepts video, video wins: it is smaller and sharper at the same quality. GIF is specifically for the places that will inline an animated image but not a video file, which on itch means forum posts and comment threads. That is a real and recurring need, it just is not “all game media”. Naming that clearly on your page would make the tool feel sharper rather than smaller.

One small heads-up, entirely practical: the link in your post has a utm_source parameter stuck on the end of it. Every click from this thread will be attributed to that source in your itch analytics, so your own referrer data for this launch will be wrong. Worth stripping before you post it anywhere else.

Nice to see someone solve this properly instead of eyeballing it in an online converter ⚡

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.

Two things that should save you real work, both about the crop 🎮

Do not start with a general border detector. The case that covers most game captures is much narrower and already solved: letterbox and pillarbox bars. ffmpeg ships cropdetect, which samples frames and hands you back an exact crop rectangle for the dead bars — so “auto crop” can be a filter invocation plus a sanity check rather than a computer-vision project. Run it across a handful of frames rather than one, because a fade-in at the start of a clip will convince a single-frame detect that the whole thing is black.

Manual crop first is still the right order, though. Just make the manual UI produce the same rectangle format the detector will later emit, so auto-crop becomes “prefill the boxes” instead of a second code path.

On the fps floor, one refinement now that you are adding one: make it a floor the search may NOT cross, not a last resort it crosses when nothing else fits. If a clip genuinely cannot make the budget at 12 fps and the minimum sensible width, the honest outcome is to stop and say so — “this will not fit in 3 MB; trim to about 6 seconds or raise the budget” — rather than shipping something at 8 fps that makes a good game look broken. A tool that fails loudly with the fix in the message is more useful than one that always succeeds and sometimes lies. It also puts the duration lesson in front of the user at exactly the moment it is actionable.

Glad the benchmark is useful. If your numbers come out well off mine in either direction I would genuinely like to know — mine are one game’s footage on one encoder, and I have no idea how much of that is idiosyncratic ⚡