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.
It's time to replace GIFs with AV1 video
101–110 of 327 posts
Re: It's time to replace GIFs with AV1 video
#102Earlier quoted context omitted.
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 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…
It doesn't make sense to use GIF for lengthy or large resolutions. For a 16x16 pixel image with 5 frames though...
Re: It's time to replace GIFs with AV1 video
#103Earlier quoted context omitted.
> [...]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?
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.
Re: It's time to replace GIFs with AV1 video
#104Earlier quoted context omitted.
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 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.
Re: It's time to replace GIFs with AV1 video
#105It'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.
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.
Re: It's time to replace GIFs with AV1 video
#106What 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
It's fine, but it's lossless so it's not good for most video use cases.
Re: It's time to replace GIFs with AV1 video
#107Earlier quoted context omitted.
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 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…
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.
Re: It's time to replace GIFs with AV1 video
#108Earlier quoted context omitted.
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%.
Re: It's time to replace GIFs with AV1 video
#109I'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...
Re: It's time to replace GIFs with AV1 video
#110Earlier quoted context omitted.
I understand that they can be made to autoplay with no controls, but I don't even want the possibility of them being paused. This way the format has no choice but to behave as expected across everything.
There's nothing about allowing play/pause that prevents videos from behaving exactly like gifs. I've seen browsers with play/pause options for gifs, even.
The stop button used to stop all gifs on a page in firefox and internet explorer. Not sure if that was a bug or a feature though, since the stop button was generally not available when page load finished.