Animated GIFs often burn huge amounts of CPU on my machine. A page full of GIFs can bring a modern computer to its knees. (This is one reason many image sharing sites convert uploated GIFs to proper video files, mp4 or webm or whatever.)
I’ve never quite understood why implementations of GIF viewers in web browsers were so bad. In many cases it seems like they could cache every frame in GPU memory somewhere and very cheaply loop them. Caveat: I haven’t studied this in any detail, and am not an expert on image/video formats.
You have gif with all its quality loss (256 colors and etc.), and then to make matters worse it's getting shoved through webm/mp4 encoding.
And then there's everyone from Imgur to Twitter missing the point of why gif is even a thing. Because it is simple. Because gif is treated as an image and not a video format. Because you can right click it, and save it for later use. Can't do that with "gifv" (seriously, I had to use curl just to get the video file from Imgur), and definitely can't do that with Twitter.
Neither webm nor mp4 can kill gif yet - mp4 is a patent mess, and webm comes closer (4chan for example has a quite big SFW community of people trading videos), but there are issues with Apple refusing to support it, and lack of hardware support.
A small note on a common misconception - the mp4 format is not something that is patented - that's h264.
Broadly speaking video files are first a container (e.g. mp4, avi, mkv, ts, etc). A container is sort of like a zip file. It groups together metadata about the file as well as the audio, video and possibly subtitle streams. In fact if you view an mp4 file at this level it reads like binary XML with 4 byte tag names.
The video streams are encoded using a video codec - e.g. h264, h265 (HEVC), vp8, vp9, ProRes and many others. Audio codecs are similarly varied - e.g. AAC, mp3, vorbis, theora and others. These are the parts of the file that can be patent encumbered.
In theory there is nothing stopping you from making an mp4 with vp8 video and vorbis audio. You can even ask ffmpeg to do it - it will happily oblige (and ffplay will play it). However the reality is that most non-smart video players will freak out at this kind of file.
Most simple players will expect mp4 to contain h264/AAC. This reality is starting to break with h265 encoded video in an mp4 container. Hopefully some of these assumptions will disappear over time. I believe mkv is currently the only reasonably popular container format that can usually play whatever audio/video is inside (mostly because only "advanced" players can even read it).
To add some confusion WebM is actually a hybrid. WebM is a more restricted mkv container with a VP8 OR VP9 video codec and vorbis or opus audio codec.
Try to save a webm if it serves you an mp4, though. Maybe they changed it lately, but I just could not figure it out - .webm and .mp4 both just silently redirected to .gifv last I tried.
Saving a video off imgur works about half the time in firefox, based on ???. There's a bug for it but it hasn't gotten much attention. It's a problem of imgur playing games with headers, embedding a video inside a web page and using the exact same URL for each. I haven't had any issues in chrome.
Twitter's just putting dumb empty divs over the content. And they make it impossible to get the source gif even in cases where the video version is larger and lower quality. Thanks twitter.
Some sites go to quite some length to ensure that users cannot download videos easily (I believe youtube has some javascript that assembles a lot of different video files while playing to ensure you can't get a direct link to the video) but you can go to similar length to protect normal images.
There are certainly many cases where using video instead of GIF makes much more sense. But if you're talking about continuous animation of 10+ elements, then I'm not sure video is a good idea.
We recently optimized electricitymap.org to use GIFs instead of CSS/SVG animations, reducing CPU usage between 50-95 percentage points (depending on setup). In our case, we were animating ~70 arrows causing 100% CPU on many machines, including my own beefed up MBPr from late 2013.
Looks great indeed, there is also the option to dynamically render the SVG animation to a sprited or multiple canvas once, and avoid to reevaluate and render the SVG for all instances on every frame.
There is no reason clients can't encode a GIF or APNG to H.264, cache that, then use the hardware video decoder on the GPU to render it. Whether that would be a win for performance or battery life probably depends on the exact hardware and how many of these things are displayed at the same time.
Using the optimized video code paths for GIF was discussed by the Mozilla graphics team several times. Basically the conclusion is that it's a lot of work when there's a perfectly good alternative which is using a video element. Effort that can be better spent elsewhere.
maybe let Mozilla know that it would be very helpful to their non-profit cause if they spent some time in rust making this work better.
they spend a lot of time adding new milestones, but this is one which could improve the quality of the web.
or they could design an extension which converts gifs to pdfs and we could continue to use their software for what it is:
zero day gateway with attached subscribers to a non profit software engine company which spends a bunch of time doing what they feel could make their impact last any longer than it already has
The frame data is incomplete with no keyframes - if you want to do a fairly typical memory conservation technique where after user switched away from the browser tab, you pause a GIF, unload it from memory, and then need to reload it from the same frame when user switched back - you will need to replay entire GIF to that frame.
At least for pixel graphics with transparency converting gif to apng would be a far better choice than gif to h.264 or vp9.
The thing is that you want 4:4:4 (no chroma subsampling) + alpha + lossless for pixel graphics. While some video standards support that in theory browsers often don't support those advanced profiles.
ffmpeg is not the issue here, it supports several 444/alpha/lossless codecs quite well, proes is not special in that regard.
Browsers only expose a small subset of codecs that ffmpeg supports. gif and apng are now the most compatible format in browsers for this kind of content.
FourCC of ap4x 'just worked' on IE (I might have installed QuickTime codecs), Safari, and gstreamer with Firefox - it just played in the window (though I did not test alpha channel). I was surprised too ;)
I've noticed that gifs are made into videos too. I wonder if apng's will be efficient. I would think a small animated image like a .gif would be more optimized than a full on video file but I guess not.
Once you understand how videos are encoded, it's pretty obvious why gif (and apng) are not and will never be as small as videos. Videos use temporal data. You have one key frame (where the whole image is stored) and the following frames are encoded as delta (difference) from the previous frame. So a still video could basically be the size of a single image.
Animated images aren't that smart, they're just a bunch of images, so you're storing every single frame.
It's not quite that stark. You can have the non changing background solely in the first frame, and have subsequent frames (smaller frames even, placed at offsets) composed solely of "sprite like" things that overlay. And there are tools like imagemagick that can optimize existing animated gifs in that way. It is crude, but it's more than just a plain sequence of unrelated full size frames .
> Animated images aren't that smart, they're just a bunch of images, so you're storing every single frame.
GIF89a has a sort of limited delta encoding via the "do not dispose" option. If you write a frame with "do not dispose" and then write a frame with some transparent pixels, the transparent pixels will retain the colors from the previous frame.
It's rather primitive but it's better than nothing.
Use gifsicle. It's excellent and very fast, I don't think there's anything that produces smaller gifs than it. [0]
You can also use ImageMagick to produce optimised gifs (it has about 4 different options for that, eg -layers OptimizeTransparency). See [1]. But in my own tests, gifsicle always beats it (often by a huge margin) and is vastly faster. That ImageMagick page may be out of date. Also, Tumblr contracted the author of gifsicle, Dr. Eddie Kohler, to make some improvement for them, hopefully that made it back into gifsicle [2].
I think most GIF optimizers would do it, although I haven't tried any. E.g. https://ezgif.com/optimize says they do it ("makes unchanged parts of the following frames transparent").
Kind of an old reply, but I should honestly test that- encoding on a CPU only environment compared to one with a GPU with specialized support takes around 4-5x more, but I didn't test decoding yet on a CPU only environment yet.
I’ve never quite understood why implementations of GIF viewers in web browsers were so bad. In many cases it seems like they could cache every frame in GPU memory somewhere and very cheaply loop them. Caveat: I haven’t studied this in any detail, and am not an expert on image/video formats.