Don't use GIFs, use audioless mp4s instead. They can be made to work in the exact same way as GIFs (autoplay, loop or not, etc) but are a fraction of the bandwidth.
Browsers use the presence of an audio track as the trigger to decide whether or not to prevent Windows computers from going to sleep while a video is playing.
I filed a bug on Firefox, but they consider it to be pretty low priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1684718
Apparently these gifs are loaded along with the other assets and lazy loading them is not simple.
We moved to mp4 and the scores have increased quite a bit.
I believe the user can change the setting to "Never Autoplay" instead of "Stop Media with Sound" but the default only affects with sound.
Like, i get that they are the same in effect, but I still believe in the semantics different between a moving picture, and a audio-track-less video.
A gif can never have audio.
A img tag can never have audio.
mp4s, m4as, webm, embeds tags, video tags, etc, can either have or not have audio, its a surprise.
Because they are videos, not moving/animated pictures.
Anywho, apng is a real standard now, so one can just use that instead of gifs.
(I encode as MP4 but i have to say it’s annoying to find it doesn’t work on some version of safari)
Sure, but the number of end users who don't install nonfree codecs on their own must be numbered in the dozens.
I do not think even sites like Dribbble have figured it out. I have a lot of issues there with videos.
It depends on how you configure it. Any option you choose, make sure the first frame is informative.
What matters is what the defaults are.
That's not what the GP saw.
Firefox seems to only render MP4 files that use yuv colorspace and aa3 audio channels, which require specific ffmpeg flags during transcoding. It took me a day of grinding whackamole to find the magic set of arguments to make all recent, popular browsers actually display a video:
https://github.com/photostructure/photostructure-for-servers...
FWIW, if you really want to encode your video in Rec. 2020, you'd almost certainly want a 10-bit encode, and then you're outside what e.g. iOS devices will render again. Rec. 709 is the safe choice.
Some of this is also probably due to using ffmpeg directly, tbh. It's very happy to produce irrational combinations of things that are technically allowed by specs but not implemented anywhere in practice, often exacerbated by it trying to preserve metadata / colorspace / etc where technically possible.
Pretty sure that's how modern video codecs work too. A lot of movies have regions that don't change much between frames (e.g. backgrounds, or some dude's face staring at the camera all dramatically).
What GIF gets you is a lossless video, which is overkill for most applications. Video codecs can achieve a similar perceptual quality at a tiny fraction of the size, which is why services like gyfcat and imgur will often auto-convert gifs to videos for browsers that support it.
Take this 2MB GIF (https://blackmagic.so/assets/sidebar/most-engaging-hours.gif) and put it through an online converter: https://ezgif.com/gif-to-mp4/ezgif-7-68b177ec1944.gif
WebP: 1.64 MB
MP4: 300 kB
AVIF: 274 kB
The original GIF can actually be compressed losslessly down to just 1.4MB with a better compressor like https://gifcompressor.com .
MP4 (and similar codecs) are not typically very good at compressing regions of constant colour, while GIF is very good at that. However I have to admit that the output of that converter is acceptable in MP4, better than I would have expected (though noticeably worse quality).
BTW curiously (likely to better performance on regions of constant colour) the non-lossy WebP does better on this example coming in at just 1.2MB!
If you really want to use GIF, it would make more sense to manually create an animation out of frames you define, switching between highlights of that feature, rather than a screen recording that captures every minor, irrelevant animation and follows the hover popup as it moves around a few pixels. That's just a waste of bandwidth. A manually curated GIF of that size could be like 40 kB or so, not megabytes.
Otherwise, I'd argue MP4 is by far the superior option for this use case given its far smaller size, where visitors just need to know at a rough glance what a feature does, not examine it for pixel perfection. An imperfect video that loads in 20% of the time is preferable than waiting forever for a huge gif to load.
Keep gifs. More gifs, even. Down with videos where gifs would do.
Also, raw size isn't everything. What's memory use look like during playback? CPU use? Higher? Spikier? I know there's hardware decoding for common codecs but wouldn't be surprised if videos still use more CPU than gif, in practice.
I'm the opposite. I wish they'd just deprecate gif everywhere and then we'd see better video support.
CPU usage shouldn't be an issue for small web video clips on any semi-recent device, my phone records 4k 60fps HEVC HDR10+.
We're speaking of animated graphics, right ?
> my phone records 4k 60fps HEVC HDR10+.
Reminds me of the rant of one of the Google camera app devs on a podcast, where they tried to see with the android guys if there was any way to just force kill every other app processes while the camera app if on the foreground to guarantee it would have enough resources upfront to do its job.
Now playback efficiency should mostly rely on the codec and wether it's hardware supported, but I wonder if there would be a pipeline effect when you're trying to play 25 videos at the same time and they all need to go through the hardware decoder.
Hmm, wouldn't proper video codecs be better in any case?
Whatever settings they use for animated cartoons would be good for animated graphics. I can't imagine a modern codec could be less efficient than gif.
>Now playback efficiency should mostly rely on the codec and wether it's hardware supported, but I wonder if there would be a pipeline effect when you're trying to play 25 videos at the same time and they all need to go through the hardware decoder.
Hopefully it would stop playing them when they're not visible. But you're right, that is a good question as I doubt the decoders have really been designed with that usage in mind, rather to optimize for a single aforementioned high-res video.
GIF uses Lempel-Ziv compression, meaning it can encode repeating information efficiently ("the next 10 pixels are the same colour as the last 1"). Efficient if there are a lot of areas of the same colour or repeated patterns.
GIF uses RGB colour space just like your screen, so there is no loss of colour information if there are fewer than 255 distinct colours per frame (typical for text & simple screen graphics!). Video codecs (like H.265) typically use YUV420 colour space, meaning that colour information is encoded at lower resolution than brightness.
Palette based colour encoding (like GIF uses) is quite efficient when there is a small number of distinct colours in an image / video (like in the videos in the article...).
I'd consider that a good trade-off given the universal compatibility of GIFs, and no ringing in the decoded video.
[0] https://developer.mozilla.org/en-US/docs/Web/Media/Formats/V...