And this is a challenge for a "new" format: if AV1 works on 90% of systems, and GIF works on 100%, then in many cases GIF is the clearly correct solution. Why would I throw away 10% of my money? Why would I ignore 10% of my customers? In many businesses, just a few customer calls because of this could seriously hurt profitability.
The article shows how to make a fallback that serves GIF in cases where AV1 is not supported. That saves you 90% of your bandwidth for 90% of your image loads.
I'd love to AV1 to become the standard, but as far as I've seen, it's just not implemented anywhere, and the spec wasn't 100% final. I was messing with ffmpeg a couple months ago, and it didn't look like a straightforward option to convert either. I'd say it's not quite time we replace GIFs with it.
Yah rav1e is a bit faster, only a few weeks ago I tried to transcode large test movie was around 8 gbps of h264. I was using a big 20 core e5 and was doing almost 1/2 a frame per second. I seem to recall working out the estimated time to encode to AV1 was about 3 weeks...
Thanks, it compiling this was a bit of a pain but I got it and do see some performance increase but wow slow. Still though, I know this is outside the scope of the article but I don't see AV1 catching on anytime soon and I half laugh to point out that 2027 when h264's patents expire isn't that far out! Everyone talks about hardware encoding options for h264 being available, let's not forget how crappy the output from h264 hardware encoding is compared to software encoding.
YouTube already has many of its videos encoded in AV1 up to 720p. Try it yourself with Firefox 67 beta, or any other browser which uses the dav1d decoder.
Pick any popular video on YouTube (like a music video) and play it. Check the format with right-click -> Stats for Nerds. If it's AV1 the codec will be "av01".
On my 5-year old laptop, AV1 in Firefox 67 beta is fast enough for 1080p30 and almost fast enough for 1080p60.
It's implemented nearly everywhere (firefox, ffmpeg, edge, chrome, opera, vlc,...) and the spec is 100% final. Problem is that (and now the everywhere gets weak) android didn't implement it yet (afaik) and some packaged versions of the software haven't got it enabled or are just out of date.
What we can get from the article thought is: why isn't gif replaced by webm/vp9 yet? Can be encoded in no time and is actually supported everywhere.
But why is this tolerated, for lack of a better word? There's no barrier to adding support, a decoder ships with ffmpeg. Youtube has been serving webm/vp9 video for years, so does that mean VP9 Youtube is unavailable on Apple platforms?
Well not if users force VP9 using something like youtube-dl and pipe to a compatible player. But I looked it up and the reason Apple refuses to adopt VP9 is not so arbitrary but rather because they're part of MPEG LA, with HEVC being the competitor to VP9. It's unfortunate that there's so much fragmentation with standards simply because of corporate interests.
Because Google Refuse to pay a single dollar for HEVC, even on their Pixel Phones. So there will likely never be HEVC on Google related properties, that is from Chrome, Android, to Youtube.
The code shows the first three video formats being available and prioritized before gif, but the sample videos do not include gifs. It'd be nice to see the quality difference between the format that is being discouraged and the format being encouraged.
I like GIFs too, they do indeed work well on all platforms. But I agree with OP, in that we should be switching over to more sustainable standards. Think about the energy savings we could get across the web if even 25% of GIFs were converted to newer and more efficient formats.
At similar bitrates, they would be barely disinguishable visual garbage. At similar visual qualities, they'd be 10-20x filesize. It would be useful for the author to make this point by example though.
GIFs work with no fuss only for small file sizes. Once you get over a fairly low threshold the size differences have an enormous impact both for network performance — like a GIF takes tens of seconds longer to start — or CPU load because all common browsers even on low-end phones have hardware video decoding but have decode GIFs on the CPU. Since people increasingly use them for video clips I encounter that more than I would have expected 10 years ago.
Aside from the size issue, GIF only support 256 colors per frame, so photos and real-life videos almost always have visible dithering artifacts.
It's a terribly shitty format, but remains popular because it has universal support and so works with no fuss. We need to get the same amount of support for a better format.
Unless you're willing to backport that support to 10+ year old browsers, it will never happen. You need UNIVERSAL support. Edge cases, corner cases, and plain old "bad ideas" included. This is what the incumbent has going for it.
The polyfill principle addresses this. As long as transparent fallbacks exist, there's no reason new technology can't be rolled out for the benefit of the significant userbase that can take advantage of it.
Anyone who cares about their data bill should be asking very serious questions about why we're still stuck with the massively inefficient 32-year-old GIF format as the only widely supported way to display an inline animation, especially as many superior alternatives like FLIF, BPG, etc. have been released over the last several years.
GIFs waste absolutely ungodly quantities of bandwidth. Any semi-modern video codec is at least an order of magnitude more efficient. Any way you slice it, the continued dominance of GIF is, at best, an egregious oversight, and it has a direct dollar impact on anyone with a metered connection (this is your phone, but increasingly likely to be your home connection too).
As a community, we need to make an alternative to GIF a real priority.
The naming is a bit annoying, but they are completely different kinds of thing: AVI is a container format (which can contain a variety of different codecs, e.g. mpeg-4), and AV1 is a codec (which can be put in a variety of different container formats, e.g. mp4). We don't seem to get confused between mpeg-4 and mp4, which have the same kind of similarity.
GIFs are still here because people make art with it, in some form. This is how we got still GIFs around, not because we needed to transfer videos. The idea of replacing everything based on technical superiority is extremely shortsighted. We need more humanists in computing.
1. One of the reasons a kinda secondary feature of GIFs (animations) became so popular is because it's so easy to generate them. 2. A big feature is that they are not lossy compressed so you can do animations of all the kinds. 3. They allow to set very slow FPS settings in a trivial way.
Animated GIFs are not really a video format, they are just a set of non-lossy compressed images shown at a timer interval. Such small details are hugely important when some media is used in a creative way.
If you have an application where you need lossless and optionally low FPS, then GIF is fine (and APNG and webp for smaller filesizes but less compatibility). But the average GIF in the wild these days is a reencoding from a video that doesn't match this description, which is what should be changed to h264, vp8, vp9, or AV1.
AV1 is an open and free format, but if people really wanted to replace GIFs they could've done it with H.264 or VP9 or VP8.
Notwithstanding any issues about video codec support in browsers, GIFs will continue to have value until browser-vendors, spec-writers, and webmasters accidentally or deliberately coalesce around a sane ruleset for embedded motion picture completely devoid of audio.
Today, browser-makers have concerns about which videos to autoplay, webmasters' tools for specifying "muted" videos have been unreliable. GIFs completely sidestep that conversation, because GIFs cannot contain audio, and will always autoplay.
Audio-free videos are often allowed to autoplay (though you may need to flag them as muted as well). TFA'a video autoplay just fine in both Safari and Firefox.
You're right, but I think the purpose of the article is to spread word about AV1 as a comparison with h264 and vp9 through the fun example of GIFs. Most people know that at least h264 should be used for looping movie clips if your service cares about filesize.
I believe that autoplaying videos are allowed in all browsers if no sound channel is included in the video container.
> AV1 is an open and free format, but if people really wanted to replace GIFs they could've done it with H.264 or VP9 or VP8.
They have. The "gifs" on reddit or imgur are generally h.264, even if you upload gifs they'll get converted to video files.
TFA's just saying those should be switched to AV1, or an AV1 source should be provided.
I'm not sure they're right though. h.264 will be larger and of lower quality especially at low bitrates, but clients can offload the decoding to hardware whereas with AV1 most or all will be decoding in software.
... and it is a complete mess. They try to to decide which format you want based on your client. Thus if you hotlink an image directly you don't know anymore if it will load or even if the format the next guy will see has sound.
I've linked "images" purely because of the sound and other viewers got a version without it. And many times it just won't load. This is supposed to be simple...
I as a user can't possibly be expected to know and deal with whatever the recipient of my link uses.
A magnitude or two of data and worse quality is a small price to pay for something that actually works and still loads in realtime, even on mobile, anyway.
Even simple scenarios, like 'show animated preview on mouseover' are borderline impossible to do reliably cross-browser unless you use a GIF. It's really frustrating.
-f - Only used in the first pass. Specifies the format of the output file in the second pass i.e. MP4 in this case
This is not required to be the same as the intended output format. Using `-f null -` will work just as well, as long as the encoder is epxressly set, which it is, in the commands shown.
It was stonewalled by multiple browser vendors for a long time which helped eat away at its momentum. In that time period people tended to give up and just use webm/h264 instead (after all, those work almost everywhere, including old devices that don't have apng)
What I'm saying is, in uses akin to this article, apng is not a meaningful upgrade over gif.
It's a huge upgrade for certain kinds of content, especially animated icons with aliased edges. But that narrowness means there's only a moderately small push toward adoption.
In principle it has the same advantages PNG has over GIF for static images -- 24-bit color and 8-bit alpha, both of which are a big deal.
APNG or something similar should have replaced GIF completely, but the delivery was badly fumbled. Browsers now mostly support it, but authoring tools mostly don’t.
“Sort of useful”?? 8-bit versus 24-bit color is like night and day!
Transparency for video is kind of a niche thing, sure, but when you need it you really need it. A good example would be compositing green-screen footage. (Keying transparency on a specific color is exactly the kind of hack GIF uses, whereas PNG does it properly, with a separate alpha channel.)
Omitting obvious stuff like an alpha channel because you don’t think anyone needs it is exactly the kind of oversight that makes all these “modern” video formats unable to completely replace GIFs. Looping is another example.
For a super compressed video there's really not that much difference. And that's almost all videos as gifs. You don't want it to be 100MB.
And I didn't say transparency isn't needed by "anyone". I said it's very rare for video-ish content.
Apng is better than gif. But its advantages really shine in realms other than video content. They're both pretty bad at video content, even despite looping properly.
> It is 2019 and we need to make a decision about GIFs
I thought "everyone" already agreed on this. Video files are smaller and if you choose the right set of codecs for which clients have hardware acceleration then playback consumes less energy, meaning your visitors don't drain the batteries of their devices as fast.
> replacing GIFs with video has now been common for a few years
Indeed. Which kind of leaves me wondering why author seems to be introducing their article as though it wasn't.
Of course, the article does go on to argue for a specific codec. Still, to me it seems to talk in a way as if not using GIF is "controversial".
Apple is a member of the Alliance for Open Media, the group behind AV1: https://aomedia.org/membership/members/. I'd suspect apple will roll out support at some point.
VP9 is a Google project which competed with the MPEG-developed H.265. It’s not surprising that Apple implemented the format they contributed to and then jumped to the next generation format rather than spending time on an older format which never saw significant adoption.
Do you have a citation for that claim? Apple is in the “Founding Members” section of https://aomedia.org/membership/members/ so “never” seems like a stretch
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.
> 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.
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.
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.
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 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.
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.
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.
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.
> 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.
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.
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?
> 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.
>>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)
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.
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!
> 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.
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.
It's telling that the author doesn't list all of the file sizes. The GIFs are gigantic but the AV1 files are LARGER than either the H.264 or VP9 versions in every example. If we wanted to replace GIFs you'd want to go with something closer to a comparable level of support and at this scale there's no reason to use a format with no hardware support and limited client support in general:
Note also that this is _any_ support at all, including the slow software implementations which boost the VP9 and AV1 numbers but have significant drawbacks if you care about quality, battery life, or the impact on other things running on the same device.
They've also been done in WASM but the comment is correct as written because the idea is that the vast majority of times when you serve a <video> with an MPEG-4 source file it'll be decoded entirely in hardware whereas AV1, H.265, and to a lesser extent, VP-9 will be loading up the CPU.
To put this in perspective, I have a 9 year old MacBook Air at home which I use for testing. If you look at 720/1080p video on YouTube, even that ancient hardware it takes 5-10% CPU to play H.264 content. I have a 2017 desktop at work with 4.2GHz Core i7 which still takes almost 100% of a CPU to play 720p AV-1 and ~60% to play VP9, or ~1% to play H.264. That's a really big difference for something like a GIF successor which will be widely shared, often with multiple visible at the same time, and people will expect to just work even on hardware which is more than a year old while still leaving capacity to do other things.
Do you remember that time [1] when GIFs had a patented algorithm, and suddenly the the patent holder decided to enforce it more strictly? This is how GIFs were massively replaced with PNGs, except for the animated. PNG support sucked at the time, too (see e.g. IE6). By now it's far superior to GIF in every way.
I think there is a bit of a parallel here. H.264 and WebM may be brilliant codecs from the engineering POV, but they are somehow encumbered [2]. This may end up in obvious legal problems; if possible, these should be avoided early on, by not investing the content in them where we can.
I do remember that period well but there’s an interesting wrinkle: almost everyone with a computer already has a licensed implementation from their device/OS vendor. This is a consideration for anyone encoding video for the web who isn’t already producing H.264 and doesn’t have access to a licensed encoder but that can’t be a very large group of people – and even if it was larger, given the history of things like GIFv I’d be very surprised if the license costs outweighed the huge savings in bandwidth.
> but the AV1 files are LARGER than either the H.264 or VP9 versions in every example
If the author aimed for the same quality they would be much smaller, they instead opted for the same bitrate because that would be opening the can of worms of "similar quality is subjective in the eye of the author." If you watch the samples, you can clearly see how more more AV1 gets done with [roughly] the same number of bits; H.264 looks like a complete joke in comparison.
If you massaged the AV1 bitrate until it was the same blurry mess as H.264 (in your eyes), it would likely be much smaller.
Except they didn't achieve quite the same bitrate. For scene 1, for example, H.264 was 209.9 kbps, VP9 was 191.2 kbps, AV1 was 230.1 kbps. Put another way: the AV1 stream had 39 additional kpbs (or 20% more bits) than the VP9 stream. 20% is a pretty big deal (especially at these low bitrates), and undermines the point the author was trying to make.
The increase in quality (and decrease in bitrate) for H.264 → VP9 is really cool. But the increase in quality for VP9 → AV1 isn't as impressive because the bitrate also increased. What would have really driven the author's point home was if the AV1 stream was higher quality and a lower bitrate than the VP9 stream.
You’re right about the bitrates producing similar sizes but “blurry mess” seems like pure hyperbole, especially in the context of replacing GIFs rather than say a theater setup (or we should count AV1s difficulty playing in real-time on all but the latest hardware against it).
I was thinking of the comparison from this angle:
GIF: plays everywhere, horrible quality and giant file sizes, high CPU usage.
H.264: plays everywhere, good quality and file sizes, almost universal hardware acceleration even on cheap devices
VP9: plays many places, competitive size with H.264, hardware acceleration is common but entire popular platforms lack support
AV1: limited support, great file sizes, hardware support has barely started shipping.
If the goal is to replace GIFs I would weight compatibility and ease of playback much greater than bumping the file size savings from 95% to 97%.
The H264, VP9 and AV1 files are all targeting the same file size. The only reason they aren't the exact same size down to the byte is because ratecontrol is somewhat finicky and no one cares enough about that level of precision to make it work.
I've noticed Firefox crashes more often than Chromium based browsers. Most likely a point in time thing as Firefox updates to the latest version of dav1d decoder
This is the one time I am very happy that standards have failed to materialise. Leave me to read in peace with distraction free web pages thank you very much. If I want to see an animation I’m fine with touch or a click for activation.
Aesthetically speaking GIFs have a character that you gotta jump through a lot of hoops to approximate with another format.
In addition to that they function everywhere, always autoplay, can't have annoying audio, and support transparency, these are all important features that nothing else on the 'market' can match.
I'm aware that there is lossless animated WebP with transparency, and I can encode a low-color animation into one of those for something functionally identical to a GIF, excepting the fact that it won't be supported anywhere except a recent Chrome.
If you want a "degraded" aesthetic, nothing is stopping you from encoding a gif, then encoding the gif to a video format. The last stage should be roughly lossless, and the video will still use way less space than the corresponding gif.
Well let's get one thing straight, VP9 does not achieve 50% more compression compared to H.264... Second the demo videos were cherry picked to support their argument - using full motion panning...
My browser (FF66 Win10) lags and hangs when browsing this site. Also, the AV1 videos have frozen and I can't get them to play again without refreshing. I can recreate both of these bugs by simply changing tabs. Despite that, I'm ready to switch to video too.
326 comments
[ 3.9 ms ] story [ 406 ms ] threadedit: I've downloaded first example[1] and video player won't play it neither.
edit2: Firefox 66 works!
[1] https://www.singhkays.com/blog/its-time-replace-gifs-with-av...
Edit: as ataylor pointed out, Mac support was added in 66.0 https://www.mozilla.org/en-US/firefox/66.0/releasenotes/
Firefox 66.0.5 (64-bit)
on Windows 10
And this is a challenge for a "new" format: if AV1 works on 90% of systems, and GIF works on 100%, then in many cases GIF is the clearly correct solution. Why would I throw away 10% of my money? Why would I ignore 10% of my customers? In many businesses, just a few customer calls because of this could seriously hurt profitability.
https://www.phoronix.com/scan.php?page=news_item&px=SVT-AV1-...
https://github.com/OpenVisualCloud/SVT-AV1
YouTube already has many of its videos encoded in AV1 up to 720p. Try it yourself with Firefox 67 beta, or any other browser which uses the dav1d decoder.
Turn on AV1 on YouTube (set it to "Always prefer AV1"): https://www.youtube.com/testtube
Try the AV1 playlist: https://www.youtube.com/playlist?list=PLyqf6gJt7KuHBmeVzZteZ...
Pick any popular video on YouTube (like a music video) and play it. Check the format with right-click -> Stats for Nerds. If it's AV1 the codec will be "av01".
On my 5-year old laptop, AV1 in Firefox 67 beta is fast enough for 1080p30 and almost fast enough for 1080p60.
What we can get from the article thought is: why isn't gif replaced by webm/vp9 yet? Can be encoded in no time and is actually supported everywhere.
Apple has significant market penetration, and you can't get VP9 to easily work in safari/iOS/tvOS
Youtube serves h.264 to Apple platforms.
And yet, things continue to work and continue to progress for the most part, so format wars aren’t necessarily as big a problem as we like to think.
https://webkit.org/blog/8672/on-the-road-to-webrtc-1-0-inclu...
H265 is getting there, but in the meantime you'd be killing a lot of batteries with software decoding.
This page claims 78% supported on iOS and 57% on Android as of last August: https://www.scientiamobile.com/growing-support-of-hevc-or-h-...
I've added a note to the article
I've added a note to the article
Personally, I love gifs. They work with no fuss.
It's a terribly shitty format, but remains popular because it has universal support and so works with no fuss. We need to get the same amount of support for a better format.
Anyone who cares about their data bill should be asking very serious questions about why we're still stuck with the massively inefficient 32-year-old GIF format as the only widely supported way to display an inline animation, especially as many superior alternatives like FLIF, BPG, etc. have been released over the last several years.
GIFs waste absolutely ungodly quantities of bandwidth. Any semi-modern video codec is at least an order of magnitude more efficient. Any way you slice it, the continued dominance of GIF is, at best, an egregious oversight, and it has a direct dollar impact on anyone with a metered connection (this is your phone, but increasingly likely to be your home connection too).
As a community, we need to make an alternative to GIF a real priority.
Judging by most websites I comes across, this must be referring to some other universe.
Animated GIFs are not really a video format, they are just a set of non-lossy compressed images shown at a timer interval. Such small details are hugely important when some media is used in a creative way.
Notwithstanding any issues about video codec support in browsers, GIFs will continue to have value until browser-vendors, spec-writers, and webmasters accidentally or deliberately coalesce around a sane ruleset for embedded motion picture completely devoid of audio.
Today, browser-makers have concerns about which videos to autoplay, webmasters' tools for specifying "muted" videos have been unreliable. GIFs completely sidestep that conversation, because GIFs cannot contain audio, and will always autoplay.
1) Maximum duration of, say, 10 s (with mandatory looping)
2) Maximum display size of, say, 25% viewport area
3) Browsers must enforce "Click to stop" on these "video-img" elements even if there are other DOM elements on top.
I believe that autoplaying videos are allowed in all browsers if no sound channel is included in the video container.
They have. The "gifs" on reddit or imgur are generally h.264, even if you upload gifs they'll get converted to video files.
TFA's just saying those should be switched to AV1, or an AV1 source should be provided.
I'm not sure they're right though. h.264 will be larger and of lower quality especially at low bitrates, but clients can offload the decoding to hardware whereas with AV1 most or all will be decoding in software.
I've linked "images" purely because of the sound and other viewers got a version without it. And many times it just won't load. This is supposed to be simple...
Doing what this article recommends shouldn't cause those problems, though. The only notable risk is linking a format that mobile can't load.
I as a user can't possibly be expected to know and deal with whatever the recipient of my link uses.
A magnitude or two of data and worse quality is a small price to pay for something that actually works and still loads in realtime, even on mobile, anyway.
They can (publicly) now: https://news.ycombinator.com/item?id=19935900
Of course, there's no browser support for the Application Extension, so it requires a Javascript player for now.
The article, in its ffmpeg encoding guide says,
This is not required to be the same as the intended output format. Using `-f null -` will work just as well, as long as the encoder is epxressly set, which it is, in the commands shown.https://en.wikipedia.org/wiki/APNG
[1] https://news.ycombinator.com/item?id=13871809 [2] https://www.chromestatus.com/feature/6691520493125632
It's a huge upgrade for certain kinds of content, especially animated icons with aliased edges. But that narrowness means there's only a moderately small push toward adoption.
APNG or something similar should have replaced GIF completely, but the delivery was badly fumbled. Browsers now mostly support it, but authoring tools mostly don’t.
Transparency for video is kind of a niche thing, sure, but when you need it you really need it. A good example would be compositing green-screen footage. (Keying transparency on a specific color is exactly the kind of hack GIF uses, whereas PNG does it properly, with a separate alpha channel.)
Omitting obvious stuff like an alpha channel because you don’t think anyone needs it is exactly the kind of oversight that makes all these “modern” video formats unable to completely replace GIFs. Looping is another example.
And I didn't say transparency isn't needed by "anyone". I said it's very rare for video-ish content.
Apng is better than gif. But its advantages really shine in realms other than video content. They're both pretty bad at video content, even despite looping properly.
I thought "everyone" already agreed on this. Video files are smaller and if you choose the right set of codecs for which clients have hardware acceleration then playback consumes less energy, meaning your visitors don't drain the batteries of their devices as fast.
> replacing GIFs with video has now been common for a few years
Indeed. Which kind of leaves me wondering why author seems to be introducing their article as though it wasn't.
Of course, the article does go on to argue for a specific codec. Still, to me it seems to talk in a way as if not using GIF is "controversial".
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.
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.
Your opinions are just that, and usually overridable by the client. The client could even strip your media entirely.
And gifs are pausable (used to be ESC though apparently you now need extensions).
> This way the format has no choice but to behave as expected across everything.
I've got bad news for you: once it reaches the client you're not in control anymore, you can only suggest behaviour.
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.
[1] https://calendar.perfplanet.com/2017/animated-gif-without-th... [2] https://bugs.chromium.org/p/chromium/issues/detail?id=791658
Why do you hate my phone battery so much?
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...)
That's downright hostile to the end user…
https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-pause...
If browsers made it such that I couldn't not stop .gif animations (or playing video, or...), I would trash that browser.
Bluntly, you do not get to control my computer.
Human sight has evolved to be attracted to movement.
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 agree that there won't be wide adoption of AV1s until it can transparently be interacted with just like gifs are now.
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.
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 ...
There is an AV1 "image" format too, which supports "image sequences" but not, oddly, animation.
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?
Should AGIF continue to autoplay when in more efficient other formats it may not?
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.
That's... not entirely accurate. What do you think is rendering all those gifs to screen?
https://www.hampsterdance.com/classics/originaldance.htm
Just did it on my 2011 MacBook Air. Pushes all four cores up... about 15%.
edit: such as https://giphy.com/sports/2019-stanley-cup-playoffs which seems to be entirely gifs if you view page resources in the debugger.
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.
Two cores went up 20%. The other two didn't budge. Go figure.
Which is why I can't wait for GIFs to die.
https://caniuse.com/#feat=mpeg4 97.16%
https://caniuse.com/#feat=webm 86.39%
https://caniuse.com/#feat=hevc 16.57%
https://caniuse.com/#feat=av1 35%
Note also that this is _any_ support at all, including the slow software implementations which boost the VP9 and AV1 numbers but have significant drawbacks if you care about quality, battery life, or the impact on other things running on the same device.
https://jsmpeg.com/
http://libwebpjs.appspot.com/vp8/webm-javascript-decoder/
And I think this:
https://developers.google.com/web/updates/2018/08/wasm-av1
So I don't think your "_any_ support at all" comment is correct.
Decoding MPEG4 in Javascript can be done, check out broadway but it uses massive massive CPU and basically sucks.
To put this in perspective, I have a 9 year old MacBook Air at home which I use for testing. If you look at 720/1080p video on YouTube, even that ancient hardware it takes 5-10% CPU to play H.264 content. I have a 2017 desktop at work with 4.2GHz Core i7 which still takes almost 100% of a CPU to play 720p AV-1 and ~60% to play VP9, or ~1% to play H.264. That's a really big difference for something like a GIF successor which will be widely shared, often with multiple visible at the same time, and people will expect to just work even on hardware which is more than a year old while still leaving capacity to do other things.
I think there is a bit of a parallel here. H.264 and WebM may be brilliant codecs from the engineering POV, but they are somehow encumbered [2]. This may end up in obvious legal problems; if possible, these should be avoided early on, by not investing the content in them where we can.
[1]: https://en.wikipedia.org/wiki/GIF#Unisys_and_LZW_patent_enfo...
[2]: https://en.wikipedia.org/wiki/WebM#Licensing
IIRC the stuff which broke in IE6 were features GIFs didn't support at all (translucence and gamma correction).
For GIF replacement you'd use palettes and binary transparency, and it was supported just fine since IE4.
If the author aimed for the same quality they would be much smaller, they instead opted for the same bitrate because that would be opening the can of worms of "similar quality is subjective in the eye of the author." If you watch the samples, you can clearly see how more more AV1 gets done with [roughly] the same number of bits; H.264 looks like a complete joke in comparison.
If you massaged the AV1 bitrate until it was the same blurry mess as H.264 (in your eyes), it would likely be much smaller.
Except they didn't achieve quite the same bitrate. For scene 1, for example, H.264 was 209.9 kbps, VP9 was 191.2 kbps, AV1 was 230.1 kbps. Put another way: the AV1 stream had 39 additional kpbs (or 20% more bits) than the VP9 stream. 20% is a pretty big deal (especially at these low bitrates), and undermines the point the author was trying to make.
The increase in quality (and decrease in bitrate) for H.264 → VP9 is really cool. But the increase in quality for VP9 → AV1 isn't as impressive because the bitrate also increased. What would have really driven the author's point home was if the AV1 stream was higher quality and a lower bitrate than the VP9 stream.
I was thinking of the comparison from this angle:
GIF: plays everywhere, horrible quality and giant file sizes, high CPU usage.
H.264: plays everywhere, good quality and file sizes, almost universal hardware acceleration even on cheap devices
VP9: plays many places, competitive size with H.264, hardware acceleration is common but entire popular platforms lack support
AV1: limited support, great file sizes, hardware support has barely started shipping.
If the goal is to replace GIFs I would weight compatibility and ease of playback much greater than bumping the file size savings from 95% to 97%.
Aesthetically speaking GIFs have a character that you gotta jump through a lot of hoops to approximate with another format.
In addition to that they function everywhere, always autoplay, can't have annoying audio, and support transparency, these are all important features that nothing else on the 'market' can match.
I'm aware that there is lossless animated WebP with transparency, and I can encode a low-color animation into one of those for something functionally identical to a GIF, excepting the fact that it won't be supported anywhere except a recent Chrome.
Good news, they can now: https://news.ycombinator.com/item?id=19935900
https://medium.com/netflix-techblog/optimized-shot-based-enc...
The word “gif” will come to mean “animated image”.