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