Hacker News Reader

Comment by jjcm | Hacker News Reader

Rollout looks solid, but I'll probably avoid deploying it to anything live til early next year at the minimum. That'll give time for browser adoption to happen.

Biggest concern I have was the same I had with AVIF a couple years ago, which is hardware acceleration on the server side. I attempted to roll out AVIF only to find out the encoding time was so long that sync calls were timing out due to queuing. It's gotten a lot better, but just know that all of these newer formats really do need more compute. It may not be worth the cost tradeoff vs webp until encoders are baked into chips.

View on HN

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.

How are you generating the frames? Is there a chance you’re looking trough the frames at regular intervals and have to actually “render” the video (I don’t know the proper term for this)? Did you try just extracting the keyframes where an actual full image is stored in the video file instead?

One thing you can try is reducing the encoder effort: libjxl produces something like 5% larger files, but at 3-6x faster encoding speed, if you turn it down from 7 (default) to 4. (The typical compression rate benefit vs. JPEG is 30-60%.)

Shameless plug: if you have GPUs in your server, you can put them to use to make it faster! https://github.com/yunho-c/gjxl (Granted, the speed improvement at lower efforts aren't as pronounced)

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?

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

Thanks! I didn't think of the decoding story but it hints at a possible reason why some sites that have a high "usage to money" ratio might specifically seek to avoid the new formats if they need to process the images, which I suspect most do, even if it is just to create a thumbnail.

This, even the prevalence of hevc (heic) encoded image from phones have caused us 4x the cpu usage.

It sounds like you’re describing decoding rather than encoding, or what am I missing?

Reply on news.ycombinator.com