undefined

points

[-]

I had the same problem with AVIF. My platform allows users to “scrub” through a video file they’ve uploaded by hovering over the thumbnail. To achieve this it creates a grid of 100 representative frames, up to 480px in width per frame. So the images are pretty large and take up a lot of space in JPEG format. File size is important because it reduces lag time before the thumbnail is scrubbable.

We tried AVIF and file sizes were much better but it would take multiple minutes just to generate. We also got feedback from our self-hosted customers that it was using way too many of their system resources.

So we’re now using WebP which generates in about 10 secs using much less CPU. I’m open to JPEG XL if it can improve on those metrics.

by xp845 hours ago|

prev|

[-]

To make sure I understand, your concern specifically applies to images that your application server is rendering custom for each visitor?

I'm assuming that for more persistent, cachable types of images, there wouldn't likely be that type of problem, right?

by jjcm5 hours ago|

parent|

[-]

> your concern specifically applies to images that your application server is rendering custom for each visitor?

It's more if you accept image uploads from users in any way. I experienced a ~10-20x increase in processing time when accepting AVIF images, and I found that I couldn't rely on sync functions for that. I had to both change to async and upgrade hardware in order to support it at scale. I run a small reddit-like site that accepts media uploads and the end result was I had to choose between unshipping AVIF or doubling my server costs. I found that the image savings over webp weren't worth it at the time.

The same story is likely true for JXL until there's hardware encoding.