The most important part of GIFs for me is that they behave like images in browsers. They are always auto-playing with no concept of play and pause. You can drag and drop them from a browser to your desktop to save them. You can save an entire page and have all the image files save with it. I've never had this work for webm or other video formats.
You could even argue that GIFs not being a video with no video decoding required is a feature. It may take longer to load, but I can have 100+ GIFs playing at once with no impact to my CPU.
I don't care about video compression or hardware decoding or whatever until they function the same way as GIFs do.
> It may take longer to load, but I can have 100+ GIFs playing at once with no impact to my CPU.
I don't know what you're talking about really... I was just using Google Slides today and both Firefox and Chrome went to 250% CPU usage, only because there was one slide with a 5 seconds full screen recording GIF. I begged to the person who added it to turn that to a video.
Yep, browsing pages laden with too many GIFs is my favorite way to have a hot laptop that sounds like it's getting ready to lift off and get my low battery warning to pop up.
> The most important part of GIFs for me is that they behave like images in browsers. They are always auto-playing with no concept of play and pause. You can drag and drop them from a browser to your desktop to save them. You can save an entire page and have all the image files save with it. I've never had this work for webm or other video formats.
The saving bit is the only part which doesn't work right with videos AFAIK. Sound-less (/muted) videos can autoplay and loop, and there's no controls unless you ask for them (via the `controls` attribute) or bring your own.
The examples in the article (the scenes are videos) autoplay, loop and don't have control in either Firefox or Safari.
There are related problems like embedding. If you upload a video to Slack, say, you can’t control whether it autoplays or loops. If you upload a GIF it just works.
I understand that they can be made to autoplay with no controls, but I don't even want the possibility of them being paused. This way the format has no choice but to behave as expected across everything.
I don't see why we can't use the IMG tag for video and the VIDEO tag for images. They should be unified, with all the same media formats supported.
IMG would autoplay, would not have sound, would loop, and would not have controls.
VIDEO would be the opposite. For something like a plain JPG or PNG file, it just shows the one frame. Animated GIF files would of course benefit from the controls.
The same should go for unification of the VIDEO and AUDIO tags. Play an audio file as video, and you get a black screen with sound. Play a video file as audio, and you just hear the sound.
They don't though. At similar quality and framerate, a video is much smaller than a GIF (so the radios can be shut down faster) and requires less power to playback (because it's offloaded to the hardware acceleration instead of being implemented entirely on the CPU).
Your average smartphone can play 1080p video without breaking a sweat, not so with 1080p gifs. Hell, a laptop will have permanent high-CPU usage on 1080p gifs, as a video it's background noise (https://www.reddit.com/r/osx/comments/43rrf0/pixel_art_gif_a...)
The point is that they are more images than videos. They have no possible way to contain sounds so the annoyingness is limited to having unwanted images in your browser. You can tell your browser to block a particular still image. You can do the same thing to block a GIF. You don't need a pause/play feature on a 2-5 second sequence.
If that 2-5 second animated sequence is smack dab in the middle of an article I'm trying to read, because the author is trying to be "cool" and "in with the internets" by including some popular animated meme macro? You bet your bellybutton that I need to be able to stop it from distracting my eyes from the text.
Human sight has evolved to be attracted to movement.
There's nothing about allowing play/pause that prevents videos from behaving exactly like gifs. I've seen browsers with play/pause options for gifs, even.
The stop button used to stop all gifs on a page in firefox and internet explorer. Not sure if that was a bug or a feature though, since the stop button was generally not available when page load finished.
At least on Firefox, it was indeed stop. I believe it still works too, even though nowadays they hide the button, if you expose the functionality through an addon.
> Just did it on my 2011 MacBook Air. Pushes all four cores up... about 15%.
15% of 4 cores ~ 60% single core capacity. That's distinct from saturating a core both qualitatively and quantitatively, which means the prediction is not a bullseye... but it's on the order of magnitude in impact, which means they're not entirely wrong.
Giphy manages to consume a much larger fraction of my modern desktop's CPU. I think it may have something to do with the small size and multiple copies of the gifs on the page you chose.
Ah, yes, I didn't realize that Slack's platform reimplemented the whole graphics-formats-rendering stack. I naively thought that Electron and Slack inherited that from Chromium, but guess stupid me is way behind the times in this technicky stuff. Of course it's all in Javascript now, what was I thinking!
I don't believe these are actually gifs here. Similar to sites like imgur or twitter they convert it to something else to host for other people. Probably to keep bandwidth down. You can get to the actual gif, but you have to dig for it.
Strong agree. Just as HEIF is a video format adapted to be a still image format, the GIF successor should fit in an img tag and be guaranteed not to have sound. Perhaps it could be a different sort of container with the same compressed bitstreams.
There is an AV1 "image" format too, which supports "image sequences" but not, oddly, animation.
GIFs, in pre-AV1 terms, are simply a video with 100% lossless I-frames and autoloop enabled.
You can express the “lossless frames” aspect of GIFs today in existing video ways supported by MJPEG, H.264, H.265, or AV1 today.
AV1 image sequences are meant for sharing an album of stills, and are not a convenient shortcut for this.
Feeding a sequence of frames into `aomenc --lossless=1` should, assuming everything else is working correctly.
I believe looping is not currently a property that you can readily set at the codec level, which is perhaps the most critical missing feature of AGIF when considering codecs.
Perhaps focusing on the “loop” flag’s presence/absence and whether it’s honored by browsers would most usefully serve the post-GIF world?
Animated gifs are compressed, and do require decoding. Hell, so do non-animated gifs. Since animation was added in the '90s, GIF is basically just a really inefficient (but extremely well-supported) video format.
I agree that there won't be wide adoption of AV1s until it can transparently be interacted with just like gifs are now.
That is true. I suppose even jpegs are compressed and require decoding. I'm pretty sure it is orders of magnitude quicker than video decoding though. I can have 500 gifs playing at once just fine, but if I had 500 equivalently sized webm h264 videos playing my computer would have a stroke.
GIF is super slow to decode, more so than any modern video format!
It doesn't seem like it mostly because browsers (slowly) decode GIF as they (slowly) download it, and cache all uncompressed frames in RAM. They don't do the same for <video> tag, because they assume it's only for high-res, non-looping video.
• GIF data is huge. 15x-20x times larger for the same dimensions & quality than normal video codecs, and sheer amount of bytes to chew through eclipses any savings from it being slightly simpler.
• GIF's compression doesn't support any parallelism. Frames have to be processed bit by bit, frame after frame. Your multi-core CPU can use only a fraction of its speed when decoding. OTOH modern formats support parallelism on all levels - frames, tiles within frames, blocks, transforms. Modern CPUs can process these very effectively.
• In modern systems RAM is ridiculously slow relative to computing power available on the CPU locally. However, GIF's LZW is based on lookups in a dynamic dictionary, so not only you have just one CPU core process it, the core mostly spends time chasing pointers.
• There's no hardware acceleration for GIF. For newer codecs it's quite common and very power-efficient.
There's no technical reason (other than legacy code) stopping browser vendors from treating AV1 just like GIF, with all looping <img> glory. In fact, Safari already supports H.264 in <img>! It's faster in every way.
GIFs are quite expensive to decode, it's all in software and while the encoding is fairly simple the amount of data is huge (especially for high-quality gif in which each frame will be present in full). Gif playback is commonly CPU-bound on the more complex examples.
I can't find it quickly now, but I recall some browser vendor (perhaps Apple?) discussing support for videos in <img> tags, but having them behave like gifs as you describe. Not sure what became of that.
Yep. You can include them in any forum or comment post that supports [ img ] tags. That's one reason why it's so infuriating that Google Image search now returns videos along with images because video-gif sites like Giphy look just like actual gifs in the results but you can't embed them.
>>I can have 100+ GIFs playing at onee with no impact to my CPU
It wasn't that long ago that a page full of emoticons (animated gifs) would bring a computer to it's knees (when posting on vbulletin or something)
> It may take longer to load, but I can have 100+ GIFs playing at once with no impact to my CPU.
I remember this myth, saying that the first moon landing required as much computing power (command central, ship etc.) as rendering a GIF. No mention about the resolution, frame speed and so on, though. Hence I think it's a myth. On the other hand you could probably tune those parameters enough to actually make it a true statement ...
GIF is not very CPU-intensive, but I definitely remember systems slow enough that JPEGs loaded at visible speed over a couple of seconds. I also had a Libretto 30 that could play MP3s, but only with the Fraunhofer decoder and not the Winamp one which couldn't quite keep up with realtime.
You could even argue that GIFs not being a video with no video decoding required is a feature. It may take longer to load, but I can have 100+ GIFs playing at once with no impact to my CPU.
I don't care about video compression or hardware decoding or whatever until they function the same way as GIFs do.