It's time to replace GIFs with AV1 video | Hacker News Reader

It's time to replace GIFs with AV1 video

singhkays.com

321 pointssinghkays315 comments

At this point, killing GIF is a UX problem, not a format problem.

I've talked about this before [0], but the big problem for me is that video is just difficult as hell. Compared to a GIF, it is just that much harder to save a video on a phone, and then upload it the same way as an image. Try to save a "GIF" from Twitter or from GIPHY - it's a /huge/ pain.

Whatever the GIF killer is will need to pass the right click test - I need to be able to just right click and save it.

[0]: https://news.ycombinator.com/item?id=14181158

Yes. Just one problem I discovered recently is that no other format does looping properly.

With a GIF, you can right-click and save it, and all the looping info is inside the file. The quality is crappy, but it just works.

With all “proper” video formats, looping info is metadata, stored separately.

You can’t even go for something slightly more modern, animated PNGs, because there are warring formats and very few tools that support them.

wasn't webp supposed to have GIF like animations? As far as i know I have never seen one in the wild, just webm.

I think the problem is that GIFs are images and so displayed as such with little concept of play-control. A video format communicate that you might want to pause for example. I believe a GIF-killer will need to be considered an image as a format.

Yes, agreed. That lack of play-control is both a weakness and a strength of GIF. The strength is misunderstood and underrated by those who think videos should replace all usage of GIFs.

Play control isn't impossible for GIF. I'm using sxiv for viewing images, which is as minimal as it gets, but it does have pause, single step forward and single step backward for GIF.

Who said it was impossible?

> GIFs are images and so displayed as such with little concept of play-control

> A video format communicate that you might want to pause for example.

> I believe a GIF-killer will need to be considered an image as a format.

If we consider animated GIF to be an image, then the distinction between "image" and "video" is pretty arbitrary.

I would say the distinction isn't inherent to the format either. It's inherent to the HTML tag. There's no reason we couldn't support `<img src="foo.av1" />` or `<video src="bar.gif" />` with the appropriate UI for each.

I actually think this is a symptom of something bigger: browsers (and most other applications) shouldn't care about media formats at all; that's a low-level concern of the OS/stdlib. The Datatypes system of AmigaOS (and later BeOS) is an example of how this could be improved.

Looping is up to the video player, not the format or container. What "video formats" have looping as metadata? Gifs only have a loop flag so static images can be displayed instead of looped indefinitely as video.

GIF lets you control the loop count and playback speed. It's baked in when authored and is useful. You can simply save the file and expect it to work everywhere - dead simple.

The Internet has voted in favor of looping, "GIF-like" moving images. Platforms try to emulate this with proprietary video players. Some have sound (wanted or not), some of the video players prohibit copying, and none of the files work as simply as GIF for sharing.

We need something more modern than GIF, but that has playability baked in. Something that browsers treat as a moving image and not a video.

> You can simply save the file and expect it to work everywhere

I don't quite follow. This is because the gif is decoded and played. No different than a video. You don't need a proprietary player to loop a video, you just go back to the start of the video. For streaming, this is only problematic for large videos that can't be cached, but the same applies to large gifs. Browsers can loop video, it's just a right-click setting. HTML5 can loop video, allowing sites to serve video in e.g. a banner, replacing gifs. You can save any video file just like a gif.

> Something that browsers treat as a moving image and not a video.

The entire point of deprecating gifs is because video is superior. Gif as an image format being able to specify frame duration and looping is hardly a noteworthy feature.

Video isn't superior for sharable, loopable images.

Try downloading a video from a popular social network. Can you easily do it without inspecting the source? If it's a two second clip, does it loop on your system? Or does the video player exit / end the stream?

This is absolutely a problem that GIF doesn't have.

> You don't need a proprietary player to loop a video

> You can save any video file just like a gif.

Except social networks force you to use a locked down or DRM'd player. You can get chunks of the video sometimes. Your non-tech friends are out of luck.

> you just go back to the start of the video

"just". Yeah, how many players support that out of the box? Yours might, but there are many more that do not.

> Can you easily do it without inspecting the source?

Yes, I use Page Info (Tools menu -> Page Info) in Firefox. It lists all the media assets on the page and you can download the one you want.

The inability to right-click and save a video is less a problem with the video file itself and more a problem with how the page is structured. You can have the same right-click problem with GIFs depending on where they appear in the page structure.

You can't do this on mobile, though…

... That’s far from what I would call an acceptable ux.

So make an add-on which does the same thing with whatever UX you want. It's a good project for you. I look forward to using it when you're finished.

Alternatively, use one of the media downloading add-ons which already exist.

Mass adoption doesn’t want to use addons or go in to the developer tools. That’s my point. I know how to do it but even for me it is not intuitive.

Your point doesn't address the fact that you can have the same right-click problems with GIFs as with video files. The file type doesn't matter, the page structure does.

The great mass of people don't care about saving media assets from a page. There will never be mass adoption of this, no matter how easy it is.

They do though. For example love to share memes to each other and with phone it’s as simple as pressing the image for a long time. Video formats do need the same kind of actions to compete with the ease of use of gifs.

They don't though. You're in a bubble of a minority use case.

Video formats don't need to compete with GIFs. That competition is already over. GIF files are too big to be practical at scale. Video won the file size war a long time ago, which is precisely why Twitter "GIFs" are videos.

Your complaints about true video formats (vp8/vp9/x264/x265/av1 with html5 video) replacing true gifs are misplaced.

Inability to save videos/gifs isn't a format problem, it's a problem due to javascript obfuscation or DASH/HLS making it difficult because you have to find the video chunk url(s), fetch them, and if there are multiple pieces, piece the full video back together. Campaigning for a return to gif isn't going to make those sites switch back. The only sites that might switch back would be sites that already allow right-click download. They won't switch back either, though, because gifs are vastly less efficient.

Looping is a html5 video tag attribute. If a video isn't looping, it's because the site serving the video didn't add that tag attribute. Many gif-style video upload sites automatically loop videos.

Also, gifs in browsers don't support seeking which is annoying for gifs more than a few seconds long.

HTML5 video is perfectly fine, loops fine, and is easy to save if the site doesn't obfuscate it with javascript or turn it into a chunked HLS or DASH mess.

so you're saying the solution to use as a replacement is harder to use and clunkier? right, i'm sure everyone will rush to adopt it and customers won't care at all

> Try downloading a video from a popular social network.

That's the site's decision. You also cannot easily download images from Twitter if there are more than one in a tweet for example. On Instagram it is blocked all in all.

> That's the site's decision.

No it isn't. UA means user agent, not corporate agent. If the user decides to persist something that is loaded on his machine then it is his choice to make.

You were lost some where in the thread above. I totally agree but that's not what we were discussing here.

Here’s another completely different use case (I came across this while googling unsuccessfully for a way to make videos loop):

You’re setting up a booth at a convention. You want to have a video playing on a TV. It should play forever in a loop.

Apparently, with any normal “smart” TV, that’s very hard to do! You can put a video file on an SD card or something, but you probably can’t persuade the built-in video player to loop it (edit: seamlessly, anyway). You can’t just set a loop flag on the file like you can with a GIF, because proper video formats don’t have any such flag.

I guess you could set up a web page with a looping video on it? That’s more of a hassle than just putting a file on an SD card, and less reliable if the net connection is spotty.

There are companies that will literally sell you a hardware dongle just to loop videos. It’s ludicrous.

What you describe is a software limitation in the TV's video player if it doesn't have an option to loop. Right now, I can open up a video in Firefox, say a VP8 WebM, and there's a right-click option to loop it. Every noteworthy media player (VLC, MPV, etc) supports looping. Websites can tag video to loop. Likewise, you're able to loop a gif even if it doesn't have a loop flag - the loop flag doesn't need to exist, it can be external to the format be it GIF or video.

The point is that if I send you a gif, you currently don't need to tell whatever program you opened it in that it's meant to loop. When I send you a gif, I expect it to be looped on your end. It's part of the gif package that we've come to love. Of course the loop flag doesn't strictly need to exist, but if someone has to perform an extra step to do what gifs were already doing, then no one will use it as a replacement.

> What "video formats" have looping as metadata

QuickTime (MOV/MooV)

> Looping is up to the video player, not the format or container.

Says who? First of all, it really is debatable if animated gif even is a movie. It has no sound, is usually far shorter than the usual video clip, etc. Second, animated gifs are very often created solely for the purpose of displaying them in a short looping fashion. Third, the fact that all this can be done in a single image format makes them ideal for sharing through the web as well as private chat applications. And fifth, and this is what this is of course all about, sharing short animated gifs gives the user the possibility to share rich content not tied to any private business or entity. You can share 'em via Whatsapp, Telegram, e-mail, usb-stick, have a collection of them stored somewhere, without the need for a Facebook/Google/Amazon account and internet connectivity. You can look lovingly at them, even when your phone is in flight mode. Let's keep it that way. Let's not kill one of the nicest image formats around, and make everybody visit your website to see the embedded movie including horrid player that's supposed to be better but just isn't and never will be. Lot's of companies already did this (hi Twitter) and it's really disheartening to know that while I was able to collect a nice bunch of animated gifs over the years, my kids will probably never have that chance because the file format will just be walled off by the internet giants.

Animated PNG support was shipped in Chromium, the last major hold out, two years ago: https://www.chromestatus.com/feature/6691520493125632

This means that once the new Chromium-based Edge ships, all major browsers will have support: https://www.caniuse.com/#feat=apng

For reference, pyAPNG works great for creating animated PNGs. If you have a sequence of static PNGs, you can assemble them with APNG.from_files() [1]. Example looping APNG (346K) [2], with alpha channel (456K) [3].

1. https://pypi.org/project/apng/ 2. https://b.thumbs.redditmedia.com/4Q-yKMEPwm2higaB8Wj1pNII60j... 3. https://a.thumbs.redditmedia.com/kSUouIZtNICOcPf4v9F8fPOrpAe...

The issue is that very often the "good enough" solution is what sticks. Gif are good enough and the world is not in a hurry to adopt a replacement.

To my knowledge you cannot save a gif from twitter. They do not provide the source data, the actual pixel-exact gif file. Only some recompressed video.

Right, in my opinion for this to work, we need an AV1 derivative that acts as a GIF:

1. Similar looping behavior 2. No audio 3. Can be put in an <img> tag

You should be able to save the file like you would a gif, and viewers should also show it as they would a gif (not a video).

Given the current direction of the industry, the most likely candidate for this in the not-so-distant future is HEIF, which has support for an image-sequence [1].

HEIF is an ISOBMFF (aka Quicktime/MP4 container)-derived container format for images, image sequences, and transformations. Its most visible use right now is Apple Live Photos, but various use-cases exist [2]. OS and application support is increasing.

Work is ongoing on defining AV1-encoded frames as a payload in HEIF [3].

[1] https://nokiatech.github.io/heif/technical.html [2] https://nokiatech.github.io/heif/examples.html [2] https://aomediacodec.github.io/av1-avif/#av1-image-sequence

Which, exactly like GIF in its very beginning, is encumbered by an infinite amount of patents. You can't replace an open format with a patented one; killing video patents is the very reason AV1 exists.

Which patents is HEIF itself encumbered by and who runs a patent licensing pool for HEIF?

MPEG tells [1] rightsholders to file Patent Statement and Licensing Declarations to ISO/IEC. ISO/IEC maintains [6] a spreadsheet of received documents and the relevant standards that they concern. Examining that spreadsheet, I found four declarations that concerned the HEIF standard, all four submitted by Nokia Technologies Oy. These documents [2][3][4][5] provide references to patents approved or pending.

The patent or patent application numbers, in order of their appearance in these documents:

AU 2014255577, CA 2909566, CN 201480034418.2, EP 14785343.6, IN 6931/CHENP/2015, KR 2015-7032685, RU 2015146961, US 14/254120, US 14/617266, WO PCT/FI2016/050063, US 14/618650, WO PCT/FI2016/050064, GB 1418114.3, WO PCT/FI2015/050671, WO PCT/FI2014/050582, US 14/583332, PCT/FI2014/051052, PCT PCT/FI2016/050381, US 15/578288

This is where I'd start.

Sources:

[1] https://mpeg.chiariglione.org/patents [2] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770... [3] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770... [4] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770... [5] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770... [6] https://www.iso.org/iso-standards-and-patents.html

Nokia has licensed their HEIF patents under royalty-free terms:

https://github.com/nokiatech/heif/blob/master/LICENSE.TXT

So that solves that problem.

Which other patents is HEIF encumbered by?

Your statement that "Nokia has licensed their HEIF patents under royalty-free terms" is not true, because the license-in-question's [1] grant is "to, use, run, modify (in a way that still complies with the Specification), and copy the Software within the Licensed Field."

Licensed Field is defined to be: "(...) the non-commercial purposes of evaluation, testing and academic research in each non-commercial case to use, run, modify (in a way that still complies with the Specification) and copy the Software to (a) generate, using one or more encoded pictures as inputs, a file complying with the Specification and including the one or more encoded pictures that were given as inputs; and/or (b) read a file complying with the Specification, resulting into one or more encoded pictures included in the file as outputs."

It is pretty clear from this reading that their patent grant is for non-commercial evaluation, testing and academic research only.

[1] https://github.com/nokiatech/heif/blob/master/LICENSE.TXT

The US patent applications in the above list resolve to the following five:

https://patents.google.com/patent/US20160234144A1/ This one seems to be about specifying a Mimetype paramater that tries to describe the cost of image transformations requested in the target file, so that clients who know they can't perform those transformations can pick a different file.

https://patents.google.com/patent/US20160232939A1/ Seems to be about image sequences and specifying such a concept with coherent metadata in the container.

https://patents.google.com/patent/US20150193494A1/ This seems to talk about the myriad ways that ISOBMFF can assert metadata about data elements within, but there aren't always good ways to ensure the metadata points back to a specific data element. This talks about ways of figuring out whether such loosely-floating metadata in the container is still valid for data items; they also propose using checksums to figure out if the data items changed.

https://patents.google.com/patent/US20180146225A1/ This is a fancy restatement of P-frames for still images, leaving open the possibility that later frames also 'enhance' the first image in various ways e.g. upscale resolution and others.

https://patents.google.com/patent/US20140314148A1/ This defines signalling to allow putting all the I-frames at the start, and all the P-frames at the end.

Instead of HEIF one could use AVIF which is patent-unencumbered: https://aomediacodec.github.io/av1-avif/

>killing video patents is the very reason AV1 exists

Again, AV1 is royalty free, not patents free.

Safari 11.1 supports any video in <img> tag and it does all the things you want: https://calendar.perfplanet.com/2017/animated-gif-without-th...

There is a feature request for Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=791658

Gif was killed a long time ago by webm

Last I checked my iPhone can't do webm or webp

You can support a variety of formats in Safari using WebAssembly builds of the decoders. WebAssembly for audio and image formats is more than fast enough. It's even fast enough for VP9 video.

WebP demo: https://webmproject.github.io/libwebp-demo/webp_wasm/index.h...

Theora\VP8\VP9\Opus\Vorbis demo: https://brionv.com/misc/ogv.js/demo/

ogv.js on GitHub: https://github.com/brion/ogv.js

Is it really worth it to ship a decoder to every user of your site rather than encode it once on your server?

Don't get me wrong, it's a super cool demo but anyone who does this is prod is a little nuts. The exception being a service that's write once read maybe like CCTV cameras.

You still encode the file once on the server. The decoder just happens to be implemented in WebAssembly.

Wikipedia uses ogv.js. If you've ever played audio or video on Wikipedia in Safari then you've used ogv.js.

Some Bach on Wikipedia in Safari: https://en.wikipedia.org/wiki/File:Chromatic_Fantasia_(Bach_...

It's all gravy, the javascript WebP decoders, until you convert your 20K high res photo site to WebP, then not realizing for a week, scratching your head about the bounce rate spiking, that you're crashing browsers left and right...

webm killed nothing.

Which is sad because webm in browsers already passes the right click test but websites have started a trend of blocking users from saving content so they choose to share a link instead which brings in more ad views.

When I want to copy an image from Instagram I have to use the dev tools to find it.

You poor soul.

Yes. Add this to the list of problems you can't believe we still have to put up with in 2019.

The UX for saving and sharing videos is the same as for images, including right click to save. You and I don't get that UX, though, because Twitter, Google, Facebook, Netflix, and most websites write code to fight off-site sharing and deploy it on their videos but not their images. They skip images presumably because it's easier to bypass there and because everybody knows you're user-hostile when you break image UX, whereas when you break video UX even HN users blame the browser or operating system.

So it's worse than a UX problem, it's a social problem.

Maybe as-easy-as-screenshots screen recording would go a long way toward solving it, but we've been beat to it: big tech has bent kernels, operating systems, browsers, and even most nations around the world into collaborating to refuse to take moving screenshots of video files, under the label of DRM.

So maybe the root of it all is just timing. Images were added to the web when the web was just a tool, so everybody knew what they were before big tech could set an expectations like that moving an image from memory to disk isn't a normal feature, or that wanting to is controversial, or that doing it might be illegal. Video, though, came at a time when there were big players that knew the stakes and were ready.

> The UX for saving and sharing videos is the same as for images…

Minus drag and drop, in browsers at least.

This comment reminded me of Terry Davis, because that's exactly the kind of feature he would have deemed essential in a browser if he'd ever decided to add networking to TempleOS. RIP brother.

Videos really should be first-class entities, though.

Imagine an OS/browser-level ffmpeg implementation which would allow seamless copy/paste of videos, integrated snipping tools both for cropping and time, color adjustment, etc. with automatic imgur-style hosting of your newly edited video just a button-click away.

The dream of QuickTime back in the 90s

> including right click to save

This only works for video tags that load a single webm/mp4 file. If it's using more complex chunked/streaming/mediasource delivery mode then you can't save the whole video because it's driven by javascript that might only keep a tiny slice of it loaded at any given time and not a single downloadable file. It also auto-negotiate quality and serve you a reduced version, which is probably not what you would want if you're downloading it.

Then you need browser addons or tools like youtube-dl to get the whole thing.

I can right-click and save videos just fine. You can too, try it here: https://thumbs.gfycat.com/GregariousDevotedArachnid-mobile.m...

You just have to write some Greasemonkey script to circumvent all the crap that the video-serving websites do to prevent you from getting the normal video-in-a-browser UI. It's harder when you get this link https://gfycat.com/GregariousDevotedArachnid

On your second link I can directly right click and save, on others (like Twitter) I just have to shift right click to bypass the blocking scripts. (Firefox desktop with multiple privacy extensions)

There's already apng (animated png) which is like GIF, but with the quality of PNG. No one really seems to care, though.

I wonder why, apart from IE not supporting it? Which we just serve gif to IE user.

As if developers weren't actively trying to kill regular images in the web! More and more sites serve me some blobs via some pointless js scripts, forcing me to use developer tools to just save the original image. Combined with lazy loading it results in some frustrating UX.

All of the clips in this article have 'Save Video As...' options for me... ?

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.

Can you tell me of one, please? I'd like to check their implementation, most play/pausable gifs I see are only converted webms.

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.

(Maybe I remembered wrong, someone else mentioned here that it was ESC, not stop)

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 understand that they can be made to autoplay with no controls, but I don't even want the possibility of them being paused.

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.

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.

Agree. Safari has already made moves for this[1], but Chrome seems to be resistant[2].

[1] https://calendar.perfplanet.com/2017/animated-gif-without-th... [2] https://bugs.chromium.org/p/chromium/issues/detail?id=791658

> IMG would autoplay, would not have sound, would loop, and would not have controls.

Why do you hate my phone battery so much?

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...)

> I don't even want the possibility of them being paused

That's downright hostile to the end user…

https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-pause...

A behavior being unchanged for 30 years is hardly user hostile. It's reliable and trustworthy. Like a good tool should be.

You used to be able to press the escape button to stop GIFs on the page. It's not unchanged for 30 years.

Browsers have changed, a lot, in sad and unfortunate ways like you mention here, but the gif format is pretty stable.

Any application that doesn't allow me to stop something from being annoying, will be stopped from being annoying by being uninstalled.

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.

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.

No, the point is control. You have no idea what I need.

Most people require much less.

What is your current solution to autoplaying, unpausable gifs?

Case by case basis ublock origin and permanently remove the gif from showing up in my browser ever again.

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.

I think the saving part is a big deal.

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 doesn't make sense to use GIF for lengthy or large resolutions. For a 16x16 pixel image with 5 frames though...

Note that AV1 has palette-based blocks, so it's even better suited for GIF-like images than GIF.

> 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?

Would looping not make more sense at a container level, not a codec level?

Far more sense, but containers are a disaster zone in video. Is it av1 in webm, mp4,fragmented mp4/cmaf, or ts? Where does the flag go in each?

And for bonus disaster problems:

Should AGIF continue to autoplay when in more efficient other formats it may not?

> 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.

In my experience that's a google slides problem, not a gif problem.

Google problem not gif problem, sites like knowyourmeme embed 10 gifs in a page routinely with no issues(apart from the loading time)

>>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)

> [...]but I can have 100+ GIFs playing at once with no impact to my CPU.

That's... not entirely accurate. What do you think is rendering all those gifs to screen?

The other seven cores that are not being identified as "my CPU".

No "major" impact to the CPU. As insignificant as displaying however many frames exist in the gif as still frame jpegs at the same time.

That's still not accurate. Load up 20-30 gifs on a page and I can pretty much guarantee you'll see your browser saturate a core.

Challenge accepted.

https://www.hampsterdance.com/classics/originaldance.htm

Just did it on my 2011 MacBook Air. Pushes all four cores up... about 15%.

Do things change if each gif is different?

Try again using a gallery page on a site like giphy which is going to be more representative of the use case op was talking about.

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.

Most animated images on giphy are vp8 videos.

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.

For best results, use a Slack channel, or a forum reply page with an array of animated smileys.

Slack doesn't exactly have the most efficiently implemented front-end interface.

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!

To complain about GIF usage saturating your CPU when running an Electron app is to be penny-wise and pound-foolish.

> 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.

True, but it's an eight-year-old computer. And it wasn't exactly a computing powerhouse when it was released.

Try this, http://www.voots.name/

There we go. Try that with video formats.

That one actually did better.

Two cores went up 20%. The other two didn't budge. Go figure.

I had to turn off GIFs and animated emoticons in Slack because it was making my fan spin up and consuming a significant amount of CPU.

That's because of Slack, not because of .gif files.

>They are always auto-playing with no concept of play and pause.

Which is why I can't wait for GIFs to die.

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.

1995: Compuserve/Unisys is becoming obnoxious!

1996: The GIF KILLER is going to be PNG! (We wait for animation. The PNG committee fails to deliver, they had a LZ method not covered by patent, they had the world cheering them on -- and having myself seen some of the listserv emails back then, some of the committee had asshole reasons thinly disguised like someone didn't like blinking banner ads.)

2001: The GIF killer is going to be MNG! (Oh now simple animation is too hardz! We're going to dump a kitchen sink of video features into it! Later! The rest of us have given up on the PNG committee) The GIF KILLER is going to be APNG! (Says Mozilla, not too convincingly but they did deliver something)

[embarrassing span of time passes]

2007: (The world gave up on all that. GIF is still alive)

[Interestingly, within this time the only other embed besides GIF that loops smoothly is Flash, and --- surprise -- it is universally hated by the Beautiful People]

[embarrassing span of time passes]

2016: With stupid player and JS tricks Geniuses loop video files that stutter and jump at the loop point and pretend they're GIFs. We have millions of colors but crappy loop stitches.

2019: GIF is still alive! Who'da thunk it. We have crappy 256 dither barf BUT perfect loop stitches! Because extending the simple concept to 16 million colors waaaay back in 1996 was just too advanced for the human race.

Let's have a round of applause for the PNG committee.

/SARC fuelled by some frustrating web development compromises

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:

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.

um, I think at least mpeg4 and webm decoders have been emscriptemed to run in pure JS.

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.

Incorrect, jsmpeg decodes mpeg1 and mpeg2 (which are basically the same)

Decoding MPEG4 in Javascript can be done, check out broadway but it uses massive massive CPU and basically sucks.

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.

[1]: https://en.wikipedia.org/wiki/GIF#Unisys_and_LZW_patent_enfo...

[2]: https://en.wikipedia.org/wiki/WebM#Licensing

> PNG support sucked at the time, too (see e.g. IE6). By now it's far superior to GIF in every way.

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.

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.

> they instead opted for the same bitrate

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.

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.

Perhaps audio-free videos should be allowed in <img> tags

I'd support that (as if anyone's asking me...) on three conditions:

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.

If none of these conditions apply to gifs, why should they apply to videos in img tags?

Because we can't change the past, but we can improve the future.

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.

I believe that this is the case on Safari, don't know about any other browsers though

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...

Some sites (looking at you, imgur) are really bad about that.

Doing what this article recommends shouldn't cause those problems, though. The only notable risk is linking a format that mobile can't load.

Often you can just load the same url with .gif on the end and it will work, since they make many formats available with the same base filename.

How is that not a complete dealbreaker though?

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.

> because GIFs cannot contain audio

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.

> 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".

You can pry my GIFs from my cold dead hands.

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.

What ever happened to the APNG format? I remember dabbling with it years ago but seems to have never caught on.

https://en.wikipedia.org/wiki/APNG

All browsers except IE/Edge support it, so it "caught on", but I don't see it in the wild, so it hasn't caught on with web publishers.

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)

Chrome didn't support it until 2017 [1], with the release of Chrome 59 [2].

[1] https://news.ycombinator.com/item?id=13871809 [2] https://www.chromestatus.com/feature/6691520493125632

It's fine, but it's lossless so it's not good for most video use cases.

So is animated gif, though.

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.

More color depth is sort of useful for heavily compressed video. Transparency very rarely matters in that use case.

“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.

Hell no, it's not. None of my devices can play HEVC videos filmed with a recent iPhone without severe performance glitches. I fear to imagine how hard it is going to be to play AV1.

MP4 AVC feels like a great replacement for animated GIFs and almost every device in use today plays it nicely yet, sadly, most of the websites that would allow inserting a GIF in a post won't allow an MP4 file instead. For some sites you even have to convert an MP4 to GIF before uploading it just to see it converted back to MP4 on their side for serving.

Perhaps it could be handy if img tags would just be extended to accept video files (of all the video formats the browser supports) below certain size. Or we should better (perhaps) just forget such a category as an "animated picture" and switch to treating them like regular videos, introducing a separate button to insert such alongside to the "insert picture" button.

AV1 has enough support from enough vendors that it has a very high chance of replacing H.264 as the ubiquitous video codec. The headline is a bit click-baity, but proposing new web standard "now" means it would be available everywhere in ~5 years.

AV1 is not enabled by default in Firefox 66 on Linux. You have to flip a switch in about:config to get it to work.

    media.av1.enabled

For what it's worth, AV1 videos play really slowly on my machine. There's probably a reason AV1 is not enabled by default yet.

They use Dav1d in Nightly so it will be fast soon.

As far as I know, dav1d can be enabled even on 66:

    media.av1.use-dav1d = true

It's enabled on Linux on 67+ (currently Beta).

This is fine for real world videos crammed into gifs. But please think of animated pixel art, which is antithetical to many the assumptions that DCT-block based codecs make. Doubly so when you consider that most encoders default to 4:2:0 and ignore transparency.

APNG or similar image formats are better for this purpose

>Doubly so when you consider that most encoders default to 4:2:0

I agree, but I want to add that this has another side effect you don't mention: it makes high quality images impossible. In 2019, it would nice to have something better than cjpeg -q 98 for near lossless (or completely lossless images). I've spent many hours tinkering with the new inter frame based image codecs, and I haven't been able to achieve this because despite their advertised support for better standards, the decoders seem to have only implemented 8 bit 4:2:0 subsampled sRGB images.

I guess I'll go on storing my photography in 150 MB TIFF files...

Good:

- AV1 has a palette predictor designed to improve on pixel art by storing individual pixels as indexes into a palette.

- Chroma from luma helps preserve exact colors in pixel art, assuming color is lonely related to brightness (won't work as well for color-only changes, possibly not when brightness and color vary separately, or multiple colors and brightness are mixed)

Bad:

- AV1 takes seconds to minutes per frame. I let my laptop chug for half to several hours, running Manjaro AUR with bleeding-edge ffmpeg-git, encoding multicore tiled AV1, and it managed to encode under 3 seconds of video. (Did it link to an older libaom-av1 or is it bundled statically with ffmpeg?)

- When chroma subsampling and CfL (chroma from luma) mix, the brightness is subsampled to create a color prediction, instead of being used to add extra color resolution.

- Youtube's sample AV1 encodes have 4:2:0 subsampling (aka color channels have halved width and height resolution).

Rav1e may be faster, but apparently disabling chroma subsampling breaks CfL and inter-frames.

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.

Personally, I love gifs. They work with no fuss.

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.

I have no problem being fed the fad of the month codec, as long as a reliable fallback is available.

Hold up, we have those for codec's now? Gee, what's next? Linux distro flavors?

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.

Why? Getting the major browsers on board going forward has always worked fine before. Most of them update automatically now, anyway.

Author here: I've uploaded the GIFs here https://github.com/singhkays/its-time-replace-gifs-with-av1-...

Calling AV1 something that looks almost exactly like AVI seems like a mistake...

FWIW, I never noticed the connection until now. I guess AVI has been 'gone' for too long, and it's not in most people's minds anymore.

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.

It'll be fixed when AV2 comes out..

The article claims that AV1 works since FF 65 but the examples do not work on FF 66.

Can also confirm does not work on firefox 66 for me; chromium does work though.

I'm running Chromium 73 on Debian 9 and AV1 examples also don't work.

edit: 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...

64-bit Windows users only, according to the release notes. https://www.mozilla.org/en-US/firefox/65.0/releasenotes/

Edit: as ataylor pointed out, Mac support was added in 66.0 https://www.mozilla.org/en-US/firefox/66.0/releasenotes/

Are you on Linux? https://caniuse.com/#feat=av1 says that FF 66 has it enabled by default only for Windows and macOS users.

I'm on Firefox 66 on Mac and the last couple AV1 videos don't play.

Odd, it's working for me:

Firefox 66.0.5 (64-bit)

on Windows 10

Set `media.av1.enabled` to true in about:config.

That worked for me on Linux FF 66. Thank you.

Confirm, doesn't work for me on FF on Windows.

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.

Thier claims about encoding working in ffmpeg are also untrue..

Author here: Can you clarify this?

You can blame both Google and Mozilla for ruining the chance to replace GIFs with APNG and WebP respectively. People were waiting the support of those for years in Chrome/Firefox, but their stubbornness already forced some image hosting sites to use video formats like WebM. At this point I am not sure WebP or APNG would become popular. But using proper image format for animation is a better solution , I think.

The test results in this blog do not function correctly on iOS latest, so while I endorse this as a general future goal, make sure you have a proper fallback solution in place if iPhone users are relevant to you.

Normally, you can specify GIF as a fallback as seen in this article https://www.singhkays.com/blog/detect-rolling-credits-video-...

Even though the first preference is AV1, the 2nd, 3rd & 4th preferences are VP9, H264 and GIF which should play

Just a parenthetical note:

The article, in its ffmpeg encoding guide says,

  -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.

Thank you for the explanation. I'll update the article.

For whatever reason my browser is crashing when trying to read this article, so I guess I'll keep my GIFs.

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

The VP9 and AV1 aren't loading in my browser, (latest Safari on Mojave 10.14.4).

I understand pushing for progress, but with this table, I'm not sure "it's time" just yet.

https://caniuse.com/#feat=av1

Maybe this would incentive Apple into supporting these formats. For vp9, it seems to me there isn't any good excuse for not supporting it.

> For vp9, it seems to me there isn't any good excuse for not supporting it.

Exporting video formats is expensive: there's a lot of optimization work to have a high-quality battery-friendly implementation, decode hardware has to be licensed & updated, and they have to do security hardening and support every time they add a new format. If they're already working on AV1, why double the cost to add support for an older format which is almost never used as the only option?

It’s not like Apple can’t bear this cost. VP9 has existed since 2012, Android has supported the format since version 4.4 released in 2013. AV1 was then unheard of. Surely they weren’t working on it then.

VP9 is still interesting today since there are many devices out there that decode it and will never decode AV1 with hardware.

I think the reason is not technical. Apple has patents for MPEG formats, I think they wanted to push these formats instead. By not supporting VP8/VP9, they force(d) everyone to support their formats.

Now, if I want to make a video call with someone with an Apple device, I'll probably need, if I live in a place where software patents apply, to pay a license to decode/encode an MPEG format where the royalty-free VP9 would have done the job. Worse, I probably indirectly pay these fees (anyway) when I buy devices with support for MPEG formats, even if I live at some place were software patents don't apply.

> It’s not like Apple can’t bear this cost. VP9 has existed since 2012, Android has supported the format since version 4.4 released in 2013. AV1 was then unheard of. Surely they weren’t working on it then.

4.4 shipped with software support, which meant that it was slow and chewed battery like it was going out of style. You had to wait until around 2015-2016 for hardware decoding support and around 2017 for encoding support before it became competitive.

Even then, however, there's a bigger problem: what really matters is the amount of unique video recorded in VP9, which even Google doesn't seem to do. Apple's users almost never run into the situation where they miss out on something because their device doesn't support VP9. Since the entire industry is moving to the newer AV1 format, the question is whether it's worth taking on the long-term security & support commitment of supporting an old-new format or simply putting those resources into something which will actually replace H.264 as a universally-supported format.

> By not supporting VP8/VP9, they force(d) everyone to support their formats.

This is trying too hard to construct a conspiracy theory: VP8 had no advantages over H.264 and arrived years later. VP9 had no significant advantages over H.265 and arrived years later. The only significant source of original content in either one is WebRTC chat, which is a pretty limited hook to justify a major {development,support,security,patent risk} commitment.

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...

Netflix disagrees with you:

https://medium.com/netflix-techblog/optimized-shot-based-enc...

One great thing about GIFs is that they are always silent!

In my ffmpeg AV1 recipe, I exclude the audio

What if I told you that is now (publicly) no longer true: https://news.ycombinator.com/item?id=19935900? :)

As an app developer, whenever I need something animated, I use the baseline MP4 format. My main motivation was that animated GIFs were not supported by Android without third party libraries.

I've had 10-15 seconds of videos (640x480) at 10 fps well under 200 KB. I also compared JPEG with MP4 and decided to use MP4 video (1 frame) instead of JPEG to keep myself from re-implementing a UI again for an image.

Wake me up when the AVI encoder's performance can be measured by Frames Per Second. Currently, it should better be counted by Frames Per Day. Decoder is also slow. We need a high end desktop computer for real-time decoding of AV1 video.

There is no phone/tablet that can afford such performance.

> Wake me up when the AVI encoder's performance can be measured by Frames Per Second.

Okay, I will. Hrm. Intel's AV1 encoder is getting 24 frames per second:

https://www.phoronix.com/scan.php?page=news_item&px=SVT-AV1-...

WAKE UP!

> There is no phone/tablet that can afford such performance.

Isn't there? I wonder how well the top end iPhones are decoding AV1:

https://code.videolan.org/videolan/dav1d/issues/15

Decoding at over 100 frames per second multithreaded two weeks ago. Not bad.

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.

I think it really comes down to use case.

If your intent is to display content that is originally video, then you should use the best and most supported video format.

If your intent is to display some effect through animation, a gif isnt a bad thing.

For example, the ajax loader that we are all familiar with? The size difference is minor. The gif is 16k, an mp4 is 11k. HOWEVER, with the video I have worry about the browser playing it, looping it, and does it handle transparency? (i dunno)

If I wanted one of those full page & full motion backgrounds, it would definitely be a video. The first time I saw a page like that load, load really fast, and be high quality video, I was amazed (leave aside aesthetics)

It seems VP9 and AV1 do not play on macOS Safari.

That is correct. Safari supports neither of these.

Safari recently added VP8 support for WebRTC, so hopefully they also support VP9 in the future.

https://webkit.org/blog/8672/on-the-road-to-webrtc-1-0-inclu...

That's for WebRTC only, though.

Yes, that's what I said, and why I hope they will expand VP* support in the future.

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.

None of his AV1 samples display on my ipad. It kinds of kill the idea in my opinion.

Okay, I'm on board. But what container am I meant to be using for my AV1 content? I see the value of a limited subset of mkv, e.g. webm, but webm is too limited in my opinion. It has no facilities for soft subtitles for instance. How is that an acceptable state of affairs? That's an accessibility issue.

And yes, I know websites can send subtitles separately then render the subtitles over the <video> element, but that's no excuse for an ostensibly modern media container to not support subtitle tracks.

In the article, I embed AV1 in MP4 container. Does that not work for your scenario?

That works, but at the same time I'd like to see webm amended to include optional subtitle tracks.

The limitations of GIFs are part of what makes them great. The constraints sort of lend themselves to forcing a little extra creativity. Finding that perfect loop, finding that great moment that so perfectly works out of context, spoofing text that fits the scene/mood to repurpose those frames for a niche community - it's just fun to make and share GIFs. The problem with video is its a video.

Can I easily record a screencast as a video and paste it into a GitHub issue? If not, it’s useless for my use case and I need to stick with gifs

I predict that users will go on calling AV1 video (or any other formats we use in the future) “gif”s anyway.

The word “gif” will come to mean “animated image”.

I thought that had happened already!

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.

libaom support in ffmpeg is still experimental.

    ffmpeg -i input.mp4 -c:v libaom-av1 -strict experimental out.webm

Encoding on the CPU is less than 1fps now. rav1e is a bit faster. Hardware encoder support might be available on CPUs in 2020.

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...

Use Intel's AV1 encoder for more speed:

https://www.phoronix.com/scan.php?page=news_item&px=SVT-AV1-...

https://github.com/OpenVisualCloud/SVT-AV1

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.

> I don't see AV1 catching on anytime soon

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.

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.

caniuse.com says av1 isn't supported in (all versions of) Safari, which also means it won't work on any iOS device.

> why isn't gif replaced by webm/vp9 yet?

Apple has significant market penetration, and you can't get VP9 to easily work in safari/iOS/tvOS

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?

> Youtube has been serving webm/vp9 video for years, so does that mean VP9 Youtube is unavailable on Apple platforms?

Youtube serves h.264 to 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.

It is unfortunate but it’s been happening forever.

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.

... but uses VP9 exclusively for 4k content, which is the reason why Safari doesn't support 4k Youtube videos.

While investigating if I could actually use this—animated PNG, I found this website and it convinced me it is the new direction I should take: http://littlesvr.ca/apng/gif_apng_webp.html

Animated PNG seems to be the least-bad option that covers every key GIF feature, and most importantly will be supported by every major browser once Edge-Chromium ships: https://www.caniuse.com/#feat=apng

Nobody mentioned so I'll add: the one thing holding me back is the current ability to insert autoplaying gifs into GitHub's markdown.

No <video> type formats are supported and being able to add an animated gif showing what you're creating a pull request for is immensely useful.

Sounds good but my browser (Safari on iOS) shows just white space for the VP9 and AV1 example videos.

In order to truly have a shot at replacing gifs, it has to be as frictionless to use as gifs are. That means being able to refer to it with a single, simply tag.

and, in addition, for as many people as possible to support opening of av1s as they do with gifs.

I don't think it can be killed unless (unordered)

- looping is solved and convenient to configure

- it can be cross media barriers (copied into a text, copied into an e-mail, etc.)

- it pleases the bandwidth gods (are gifs usually smaller? i know that they have a limited color palette)

Your problems 1 & 3 are solved in the article. I compare the size of the GIF to the videos. In one of the scenes it's ~11 MB for GIF and < 500 KB for AV1 video

My bad. I should have read more of the article before "contributing".

That being said, #2 is critical. I often open Safari to get gifs to copy to iMessage because Chrome and Firefox don't properly copy gifs.

AV1 may be a way to make that more "standard" (big hand wave) but adoption is conditional upon this type of common man friendly portability.

GIFs take up a massive amount of space (often multiple megabytes!) and if you’re a web developer, then that’s completely against your ethos!

Judging by most websites I comes across, this must be referring to some other universe.

They usually just blame marketing and wash their hands of the finished product.

Fine, but do it transparently so the file is named .gif and it behaves the same as a gif only better optimized.

I hate opening “gifs” that are actually videos and, for example, interrupt my currently playing music to playback silence.

"The AV1 recipe..."

fifteen ffmpeg commands

Yeah I don't think AV1 is the answer.

That's why it's a recipe and not a command ;) Also it can be easily scripted out, where the only input needs to be a source video

Yep, shelling out to ffmpeg on your production network is probably not particularly scalable nor safe.

But can I put those videos in PowerPoint presentations?

Waiting for end 2020 Macbooks which can decode (and encode?) AV1 on CPU hardware hopefully (and hopefully also solved the keyboard mac problems).

In my unpopular opinion, the first steps that we need to bring AV1 to the web is to stop using HLS and start using DASH

I kind of thought it was pointless until i saw the file size difference. From 11.7 Meg to 330k is pretty good.

These "It's year 20XX, throw out this outdated tech!" arguments get so very old after a while

Well, the videos on this page are empty areas on my browser. But I can see GIFs just fine.

Er, it has only ~35% global support today. I'd hold off.

Anyone know what the movies are in the sample GIFS?

Tears of Steel https://mango.blender.org/

TLDR; article suggests to replace a gif img tag with

  <video style="display:block; margin: 0 auto;" autoplay loop muted playsinline poster="RollingCredits.jpg">
    <source src="media/RollingCredits.av1.mp4" type="video/mp4">
    <source src="media/RollingCredits.vp9.webm" type="video/webm">
    <source src="media/RollingCredits.x264.mp4" type="video/mp4">
    <img src="media/RollingCredits.gif">
  </video>

As long as AV1 works without js, sure.

It sure does

Why no h265? I suspect it's similar to VP9 in quality, but h264 is pretty old at this point (nowhere near as old as GIFs of course).

H264 has the advantage of very widespread decoding hardware.

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 believe the big issue with h265 was the huge licensing cost to bundle the decoder in the browser.

Correct and also lackluster browser support https://caniuse.com/#feat=hevc

I've added a note to the article

Because of lackluster browser support https://caniuse.com/#feat=hevc

I've added a note to the article

Thanks!

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.

Worse is better.

The "We need a gif replacement" discussion isn't quite in xkcd 927 territory yet, but its very close.

And that is what is working against something completely replacing it.

https://xkcd.com/927/

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.

You can make the same art with other formats. I'm not sure exactly what your point is here.

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.

Maybe the movement could and should clarify their goals for world domination do not include dancing baby gifs?

You can write the same algorithm in some other language. I'm not sure what exactly your point is here. /sarc

Reply on news.ycombinator.com