this post was submitted on 11 Jul 2026
218 points (97.8% liked)
Technology
86280 readers
3092 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I just tested this with a 8-second, 35MB mp4 video.
The "don't do this" command made a crappy looking 316MB gif.
The suggested pair of commands, using the palette file, made a 57MB very nice looking gif.
Seems legit to me but I'm not, as you say, an expert.
I am guessing the width and height of the video file are quite large. If you plop it down to a size suitable for gif, say maybe 400px width, you'll see a massive drop in filesize.
I mean, it's still going to have the pants beaten off it by WebM or AVIF for anything originating from a video camera.
GIF was just never intended to be a video format. I have a hard time thinking of something where it's really competitive. Maybe if you had a recorded lossless video of a small-palette video game, like, NES era or earlier, then GIF might be a solid choice. I'd still think that APNG or MNG would probably outperform it.
GIF animations really only got a boost because there was a period of time when it was all that a decent variety of Web browsers could display.
EDIT: Also, if one is using GIF...I dunno if ffmpeg does this by default, but most video formats have I-frames and then frames that depend on those. When seeking, a player will seek to the nearest prior I-frame and then decode from there.
I don't believe that GIF 89a has a formal concept of I-frames, because the format was never intended for real video. But it is possible to create frames in a GIF 89a animation with transparent areas that don't differ from the prior frame, and this achieves some of the efficiency benefits that a video format would get. I know that there have been GIF 89a conpressors that will do this. The downside is that it kills seekability, since after a seek in a player that just starts drawing from the current frame, you'll see only some of an image until the next time that a pixel in a frame is non-transparent and gets redrawn. There may not be any frames wirhout transparent areas nearby, and the player has no way to know where to look for one. But for applications where you don't care about seekability, that may help mitigate some of GIF's limitations for animations.
In all honesty, though, the right answer for video is almost always "use a newer format than GIF".
that's still massive, an animated webm will probably be more useful