Nope
this post was submitted on 11 Jul 2026
146 points (97.4% liked)
Technology
86251 readers
3772 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
Nobody: zzzzz
Me reading about 256 bit color conversion at 3 am: π€π₯±π€π€·ππ©
Don't get mad at people for using logical command line switches.
Get mad at ffmpeg for trash defaults.
I wish the article had examples. It would be cool.
Please stop making gifs at all. It's a terrible format that creates massive files that look like shit.
Webm is supported almost everywhere now and manages better quality at higher framerates and smaller file sizes.
Counterpoint: GIFs loop by default in basically every app, WEBM doesn't
Can just use avif instead, it holds an AV1 stream and acts like gifs/images do WRT looping β also very broad support (more than AV1 in WebM containers).
Demonstration:
Edit: switched to an example with simpler decode requirements.
an Osman classic
Works great as a static image. Would probably be better if it actually played...
Boost for Lemmy is not a fan.
That's caused by bad regex in the app, it's getting confused about domains.
e: fixed by using an aliased domain.
Your demonstration is a sluggishly loading static image on my end, so I guess support isnt that widespread :P
(Im using the app "Summit")
Static image, Eternity.
I checked that app's source code, and basically they're doing their own avif decode call instead of relying on a browser/webview to handle it. So essentially they forgot/don't know/don't intend to implement animated avif. Looks like they also use the aom reference decoder instead of using something faster like dav1d.
Static image, also Summit.
It's unfortunately not that simple. The AVIF doesn't load at Jerboa, for example :/
(on Arctic on ios) the uploaded image displays as a static image for me. Even clicking on it and waiting, it doesnβt seem to animate :T
Edit: I checked again through the Voyager app, and it did indeed load, though it took around 45-60 seconds* for it to get through the entire animation before it started looping again, albeit at the same speed as the first playthrough.
I chalked it up to the outdated hardware, as you mentioned in your reply. Cheers! :)
Apple has limited support for AV1 streams (yes, even for software decode) unless on very recent hardware. Here's an AV1 stream inside a webm container for comparison, would be interesting to see if that works over the avif container on your stack.
This doesn't work for me but the original one you posted does (Voyager, iPhone 14 pro)
Random Android phone on Voyager; yes.
Ah yeah, that would explain it - my phone is now pretty outdated (Iβm on a 12) - I clicked on the image link in your response but it didnβt load for me, unfortunately.
Iβm not sure if thatβs a result of my outdated hardware or if I perhaps clicked on it before it had a chance to process your upload, but you seem much more knowledgeable than I, so Iβm going to assume itβs my hardware. I appreciate the response and the second attempt, though! :)
It's an intentional behavior by Apple. Basically they just don't support AV1 videostreams unless the hardware you're using has a hardware decoder (read: very new). They could support it using software decode (what browsers typically do for AV1 inside avif containers) but.... for whatever reasons don't.
Haha, ye$, for rea$on$, I'm $ure... :D
I'm not sure demand for AV1 is enough to ship units
Probably either laziness or they want to avoid software decoding in general for performance reasons
Fwiw it works on the desktop's alexandrite ui and on the thunder app
on boost its a little slow but time quality.
better than most moving images in comments!
For the record, this is static in my Lemmy app (Summit).
Webm is supported almost everywhere now and manages better quality at higher framerates and smaller file sizes.
Anybody who has compared animated WebM vs animated JPEG XL?
the same file without visual quality loss could be a 156.79 KiB webp file, saving energy, internet, and storage costs
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 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
Thanks. This is going straight to my 'cool info to never be used' pile.
My folder like that is just named β
Really interesting and useful read, thanks.
I always liked to use Photoshop with the 'save for web (legacy)' export. Gives you a handy preview of how big it will be and lots of options.
ffmpeg <3 good info here, also give Gifsicle a look if you need help getting your gifs smaller
A lot of that is mostly the fault of the technology. But we still like it anyway.
Gif is indeed a shit format for the purpose.
Video codecs are downright magical and everything down to your average toaster packs a hardware decoder for h264, so this is the bare minimum we should actually be using for this use-case.
I know that's hyperbole, but I'll be cold in the ground before a "smart" toaster is allowed in this house.