Live data from Hacker News

It's time to replace GIFs with AV1 video

singhkays.com

151–160 of 327 posts

Re: It's time to replace GIFs with AV1 video

#151
post #38

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…

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.

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

Re: It's time to replace GIFs with AV1 video

#152
post #73

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…

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?

Re: It's time to replace GIFs with AV1 video

#153
post #126

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 t…

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 too…

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.

Re: It's time to replace GIFs with AV1 video

#154
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

Re: It's time to replace GIFs with AV1 video

#155
post #126

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 t…

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.

Re: It's time to replace GIFs with AV1 video

#156
post #126

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 t…

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 too…

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.

Re: It's time to replace GIFs with AV1 video

#157
post #103

Earlier quoted context omitted.

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

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

Re: It's time to replace GIFs with AV1 video

#158
post #6

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

Because of lackluster browser support https://caniuse.com/#feat=hevc I've added a note to the article

Thanks!

Re: It's time to replace GIFs with AV1 video

#159
post #38

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…

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

Post reply on HN